#ubuntu-devel 2005-06-27
<mdz> ogra: oh, I thought youo had tested the package; you just created the symlinks then
<ogra> yep...
<mdz> never mind; I've got it
<ogra> but i can build it, no problem
<ogra> just takes time...
<mdz> ogra: don't worry about it; it's done
<ogra> oki
<dholbach> hi
<mdke> dholbach, hi
<mdke> dholbach, how did you subscribe to the whole wiki? out of curiosity
<dholbach> mdke: hey matt :)
<dholbach> .* :)
<mdke> you clever thing
<mdke> hmm
<mdke> that is what thom said, but i tried it and it didn't work
<mdke> oh well
<dholbach> let me have a 2nd look
<dholbach> i have .* and in the next line * as well
<dholbach> dunno which of them works ;)
<mdke> hmm
<mdke> i tried em both, maybe I wasn't patient enough
<mdke> anyway thanks
<mdke> RecentPages is so good that i won't do it, but I was interested in how you achieved it ;)
<dholbach> mdke: you have them both? .* and * ?
<mdke> nah i tried one at a time
<mdke> dholbach, don't worry 
<mdke> no biggie
<dholbach> good night everyone, i'm off to bed
<mdke> night
<dilinger> jbailey: ping
<jbailey> dilinger: pong
<dilinger> jbailey: differing behavior between posh and bash is driving me insane :(
<jbailey> dilinger: Ugh.  I thought you had generally been hacking with dash, since it was more consistant and leaving me to make posh happy?
<dilinger> jbailey: i don't remember, i thought it was the other way around :)
<dilinger> either way, i think there's enough of a disparty amongst the shells that i'm better off just picking a shell, making it work, and later on we can make other shells work
<dilinger> i'm leaning towards picking posh (or dash).. whichever is better maintained, i suppose
<jbailey> Right.  I think ideally that shell is not bash, since that'll be the worst to reduce from.
<dilinger> should be easier to go from a posix shell to bash, rather than the other way around
<jbailey> =)
<jbailey> Chuck in #d-d is upstream for posh, and is quite willing to fix things that are wrong.
<jbailey> I suspect dash is under maintained.
<jbailey> Err.
<jbailey> Clint
<jbailey> not Chuck
<dilinger> but first, i shall upgrade my sid laptop, and watch how wonderfully things break!
<jbailey> Enjoy! =)
<zul> jbailey: how sweet...you talk about me when im not here :)
<jbailey> zul: Well, almost. =)
<infinity> Riddell : Still around?
<infinity> Hrm... "but yes", "but no"... I wonder if my conversational constructs were heavily influenced by speaking french for the first 14 years of my life...
<infinity> -EWIN
<robertj> infinity: that's why if I have kids I will never allow them to watch the little red balloon
<calc> is xterm deprecated? it depends on libxaw8 which seems to no longer be shipped in breezy
<infinity> It just needs to be broken out and rebuilt against a libxaw that still ships.
<infinity> It looks like the "upload a package" part of "break it out" didn't happen yet, that's all.
<infinity> (This is merely a guess, but a rather plausible one, based on the state of X in breezy currently)
<calc> ok
<calc> also i noticed its a bit strange since apt-cache/dselect still thinks xterm is available
<calc> but it shouldn't be should it?
<calc> since a newer xorg has been uploaded and should be overriding those old -10 packages
<calc> i guess it could be a difference in how the packages file is generated between debian and ubuntu
<calc> istr old packages that should no longer exist being reaped in debian
<infinity> They are reaped in Debian and Ubuntu, but it's a manual process.
<infinity> The reaping script (and human interpretation thereof) needs to be done, that's all.
<robertj> xterm is needed for the gdm session fallback, right?
<bob2> tseng: does the muine in breezy have the pimp cd burning thing?
<fabbione> morning
<sjoeboo> night
* lamont wonders if daniels is anywhere he can inflict pain on him...
<fabbione> lamont: ??
<fabbione> the last 3 x uploads are from mdz :)
<jdub> fabbione: my mirror just loves it! ;)
<lamont> -29 build-conflicts with <25
<lamont> and the last one that hppa built was -24
<fabbione> lamont: hmm didn't see it because i managed to build -28 before that
<fabbione> jdub: so does mine :)
<bob2> why is pike in main, anyway?
<fabbione> bob2: iirc swing build-dep
<lamont> hrm.. I have -27 in the morgue... time to tweak the archive a bit.
<bob2> fabbione: swing the java thing?
<fabbione> bob2: i think so.. it's for an extension of something.. and infinity was going to kill it to push pike back in universe
<bob2> yay
<fabbione> lamont: how can i gather the stats of Installed in the archive?
<bob2> thanks, fabbione 
<fabbione> lamont: last time you did check the % of installed pkgs for hppa/sparc..
<fabbione> bob2: np
* lamont grumbles at fabbione I checked it.
<lamont> fabbione: p.u.c/~lamont/buildLogs/Lists/breezy.all.$ARCH
<fabbione> lamont: thanks :)
<infinity> lamont : Erm, what?
<infinity> lamont : It build-conflicts cause you're supposed to build the modular stuff first. (the new libx11, etc)
<infinity> lamont : If you build in the right order, life is fine.
<Amaranth> is X good?
<Amaranth> i mean, does the latest version break things? :)
<lamont> infinity: ah, duh.
<lamont>  /usr/bin/ld: .libs/libXext_la-DPMS.o: relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
<lamont> .libs/libXext_la-DPMS.o: could not read symbols: Bad value
* lamont still wants to hurt daniels
<lamont> :-)
<lamont> libxklavier_2.0-0.2ubuntu2 is also non-PIC in shared lib
* lamont sleeps
<bob2> hm, he said some static libs were non-pic now
<bob2> which some stuff was unhappy about
<lamont> bob2: yeah, like _X_
<lamont> but really must sleep
<bob2> haha
<bob2> 'night lamont
<pitti> Good morning
<fabbione> hey pitti
<fabbione> pitti: it's time to start tracking 2.6.12 security stuff.
<fabbione> pitti: no need to push me what will come with 2.6.12.X, we will track it automatically
<pitti> hey, did they release the final?
<fabbione> yup
<fabbione> saturday
<pitti> \o/
<fabbione> but battlestar concordia is down
<fabbione> so i couldn't do too much
<pitti> uh
<pitti> weekend mode :-)
<fabbione> ehehhe
<fabbione> well i am enjoying bootstrapping ghc6 :)
<fabbione> hey Kamion 
<jsgotangco> JaneW, hi
<JaneW> hi jsgotangco :)
<jsgotangco> JaneW, its been a while, how are you
<JaneW> jsgotangco, I have been popping in every day as I can, but being on the road, my connectivity is sporadic, also my e-mail laod has sky-rocketted!
<\sh> good morning 
<Treenaks> hey \sh 
<sivang> morning all
<sivang> hey pi	
<sivang> pitti, even 
<fabbione> hi sivang 
<fabbione> sivang: did you ping me during the we?
<sivang> hey fabbione , I looked for you yesterday
<fabbione> ok :)
<fabbione> i was more or less busy
<pitti> Hi sivang 
<pitti> moin carlos 
<carlos> pitti, morning
<pitti> Hey seb128, had a good weekend?
<seb128> pitti: hello. Yep, quite good. You?
<pitti> good one, lots of biking and swimming :-) /me loves summer
<pitti> Morning JaneW
<seb128> summer is nice when it's not too hot :)
* mdke makes seb128 an honorary englishman
<\sh> summer is nice, when u didn't drink the evening before ;)
<chmj> thom, ping 
<cartman|work> daniels: ping ?
<carlos> pitti, you forgot the link to the spec
<pitti> elmo: prelink sync, please
<mdke> wooo http://bugzilla.gnome.org/show_bug.cgi?id=160080 is fixed
<pitti> elmo: libapache2-mod-auth-pgsql sync, please
<pitti> elmo: exim4, php4-pgsql syncs, please
<Keybuk> seb128: morning?
<thom> chmj: ack
<seb128> hey Keybuk 
<ogra> thom, thanks for the orinoco hint.... i tried the 0.15 driver over here.... now even if my card supports scanning, n-m still doesnt like it
<Keybuk> pitti: ok, I'm going nuts
<Keybuk> why does postgresql 7.5.6 provide postgresql 7.4?!
<pitti> Keybuk: erm, it doesn't
<pitti> Keybuk: it depends on p-7.4
<Keybuk> right ...
<Keybuk> but why is it 7.5.6 then and not 7.4 ?
<pitti> Keybuk: it is a transition package that moves the sarge/hoary cluster to the new infrastructure of p-common
<pitti> Keybuk: it must be newer than any 7.4 version, so I just called it 7.5 (which doesn't exist upstream)
<Keybuk> heh
<Keybuk> right
<pitti> Keybuk: the idea of this package is to do the transition from sarge/hoary, it can be deleted afterwards
<pitti> Keybuk: do you import the postgresql stuff into hct ATM?
<Keybuk> it didn't go for hoary
<Keybuk> it may go in the breezy import running atm
<pitti> cool
<pitti> structurally, the breezy packages are much simpler
* fabbione -> food
<Keybuk> right
<Keybuk> maybe they'll just work(tm) then
<|QuaD-_> seb128: you around?
<seb128> pong
<tseng> bob2: not yet
<|QuaD-_> seb128: i got a quick question, if i give you the website with a useful gaim plugin, can you package it with gaim?
<seb128> no
<|QuaD-_> seb128: ok
<seb128> you can package it though
<seb128> and put it for review on the wiki
<|QuaD-_> :)
<seb128> but it's not shipped by gaim, it should not be packaged with gaim
<|QuaD-_> ok, i wasn't sure the policies on that
<seb128> that and I don't like gaim, so don't count on me to package gaim stuff :p
<|QuaD-_> seb128: i thought you packaged gaim?
<seb128> it's packaged by Debian, I only do the syncs and handle the bugs
<|QuaD-_> ohh
<jsgotangco> JaneW, busy in the edubuntu lists, i see :)
<ogra> wow, mjg59 the german LinuxUser magazine has a test of the HP NC4200 with ubuntu, kudos.... it as positive as it could be "...if the ubuntu team makes suspend-to-ram and the MMC cardreader work, you get the perfect linux laptop...."
<jsgotangco> wow
<jsgotangco> oh btw hi ogra 
<ogra> hi jsgotangco :)
<JaneW> jsgotangco: yeah things are picking up nicely there... we have 45 list members now :)
<ogra> JaneW, you pinged ?
* jsgotangco wants to get into some edubuntu action now
* ogra too, but since i want to build a first livecd image i'm a bit lost currently.... we have no breezy-live yet
<jsgotangco> yeah hopefully the pople won't lost steam on their enthusiasm on the project
<HiddenWolf> ogra, neat review
<ogra> HiddenWolf, yeps
<ogra> jsgotangco, lots of them work already professional with linux in their scools
<jsgotangco> yeah, definitely exciting
<jsgotangco> sabdfl, hi
<sabdfl> hi all
<ogra> hi sabdfl 
<pitti> Hi sabdfl 
<sabdfl> pitti!
<ogra> hmm, should edubuntu contain mindmapping software....
<fabbione> hi sabdfl 
<mvo> hi sabdfl 
<jsgotangco> ogra, what a great idea, i didnt notice that
<sabdfl> hey fabbione, michael, wot's rocking in breezy today?
<ogra> X works again :)
<fabbione> sabdfl: 2.6.12 final will be on the way today or tomorrow...
<hunger> fabbione: Great news!
<mvo> sabdfl: netwide-updates taking shape
<fabbione> sabdfl: usual tons of drivers update... thanks to chmj tracking tool :)
<hunger> fabbione: I urgently need that kernel for my new laptop:-)
<sabdfl> v cool
<thom> sabdfl: install network-manager, see how it goes for you
<fabbione> hunger: i am not 100% sure i will make today.. one of the test/build machine is down atm and i can't compile for all the arches.
<ogra> fabbione, could you have a look at the orinoco_cs drivers, there shall be a patch that makes AP scanning work, it is needed to make n-m happy
<fabbione> ogra: can we try 2.6.12 final first?
<fabbione> ogra: and then we look around for bug fixes?
<ogra> fabbione, sure
<fabbione> great
<ogra> just wanted to bring it to your attention.... :)
<fabbione> ogra: if you have a link to the patch, can you send it to me?
<fabbione> ogra: i can already check if it made upstream or not
<hunger> thom: Is the network manager a gui for /etc/network/* ?
<thom> hunger: no: http://people.redhat.com/dcbw/NetworkManager
<Echylo> back
<hunger> thom: So ubuntu is moving toward redhat wrt. network setup?
<thom> hunger: go and read the page
<ogra> fabbione, i only got this url from thom, i'll try to get more info: http://www.livejournal.com/users/kernelslacker/19564.html
<fabbione> ogra: gimme a sec :)
<hunger> thom: I did... and I'll give it a try later.
<ogra> thom, already talked to andyfitz ? the icons are awful
<fabbione> ogra: there is no patch...
<ogra> fabbione, i said, i'll try to get more info.... i'll mail the guy
<thom> hunger: then why the question? it's nothing to do with network setup; it's purely on network _selection_
<fabbione> ogra: ok thanks
<thom> ogra: there's an ongoing thread on NM list about icons currently
<ogra> thom, yay
<jsgotangco> night all
<ogra> night jsgotangco 
<Riddell> might anyone be able to tell me why X has stopped working  muse.19inch.net/~jr/tmp/Xorg.0.log
<Riddell> it can't find fonts
<mdke> i had that one when i tried breezy a couple of weeks back
<mdke> no idea why
<ogra> Riddell, how often did you upgrade in the recent time ? 
<ogra> Riddell, you need to update your fontpaths
<\sh> problem I have right now, I just fixed the links to XKeysymDB and now with KDE I can't type anymore....gnome is working find
<\sh> s/find/fine&
<mdke> i tried setting fonts to /usr/share/etc but that 'fixed' error didn't go away
<\sh>  /usr/share/fonts
<mdke> yeah sorry that's what i meant ;)
<ogra> hmm, both should be solved with the upload mdz did yesterday
<\sh> no
<mdke> ok cool
<\sh> i just did the update
<ogra> \sh, it works here
<ogra> on 3 machines
<ogra> mdz put in the two missing links....
<ogra> look if they are there
<\sh> 6.8.2-30?
<ogra> yep
<ogra> /usr/X11R6/lib/X11/xkb -> /etc/X11/xkb
<ogra> and
<\sh> yeah..this morning there weren't there
<ogra> /usr/lib/X11/XKeysymDB -> /usr/share/X11/XKeysymDB
<ogra> these two should solve the probelm and afaik, mdz put them back into debian/xlibs.links
<\sh> but this is only for getting the right xkb settings...problem now is "i can't type under KDE" ;)
<\sh> but I don't see the error
<ogra> \sh, these links are for X
<ogra> not related to a DE
<\sh> ogra, yes :) I know, and I set them this morning by hand :) 
<Kamion> pitti: could you follow up to your -devel mail with a link to the spec you refer to?
<ogra> i'm just upgrading my 4th machine.... it seems they are set wrong :(
<\sh> aha
<pitti> Kamion: argh, my bad... of course
<chrissturm> ogra: seems so: lrwxrwxrwx  1 root root 29 2005-06-20 11:55 /usr/lib/X11/XKeysymDB -> ../../X11R6/lib/X11/XKeysymDB
<ogra> damned.... looks like i'm doomed to fix it
<\sh> ogra, why? 
<ogra> \sh, because 1.) i worked on it with mdz yesterday and 2.) i need a liveCD image with working X to make my first edubuntu cd
<ogra> \sh, daniels is travelling....
<\sh> ogra, that's bad :( 
* ogra gets xorg source
<doko> pitti: Is BaseSeedProposals still the page of choice? At least it's the only one linked from DeveloperResources
<mdke> hey hypatia!
<hypatia> hey mdke
<pitti> doko: no idea...
<hypatia> how are things in ubuntu land?
<mdke> hypatia, how are you?
<hypatia> OK, busy, just moved house.
<mdke> they are good afaik
<doko> pitti: anyway, I made some proposals on BaseSeedProposals, please process them ;)
<\sh> finally...breezy solved the problems with the font reendering between gnome and kde
<mdke> hypatia, cool, hope its gone well!
<pitti> doko: additions to main should be put into UbuntuMainInclusionQueue first
<doko> pitti: then *please* link this from DeveloperResources :-/
<pitti> doko: we can discuss whether it's appropriate for base if it's in main
<pitti> ok
* trulux wonders about flex++ in Hoary
<ogra> hmm, weird, the links in debian/xlibs-data.links seem correct.....
<ogra>  usr/X11R6/lib/X11/XKeysymDB usr/lib/X11/XKeysymDB
<pitti> doko: I updated https://wiki.ubuntu.com/SeedManagement and put a link to it
<ogra> but the actual link in /usr/lib/X11 points to ../../X11R6/lib/X11/XKeysymDB
<\sh> it's /usr/share/X11/XKeysymDB
<trulux> I can't get compiling some stuff due to flex++
<\sh> not /usr/lib/X11
<ogra> nope
<\sh> yes :)
<\sh> ok...from start
<Riddell> where should /etc/X11/X be pointing to?
<\sh>  /usr/lib/X11/XKeysymDB -> /usr/X11R6/lib/X11/XKeysymDB 
<\sh> ^this is not there
<ogra> Riddell, /usr/bin/X11/Xorg
<\sh>  /usr/X11R6/lib/X11/XKeysymDB should have a link from /usr/share/X11/XKeysymDB
<\sh> this is working...but not correct
<ogra> \sh, nope
<doko> pitti: yes, that looks even better
<\sh> lrwxrwxrwx    1 root root    12 2005-06-20 06:18 xkb -> /etc/X11/xkb
<\sh> lrwxrwxrwx    1 root root    29 2005-06-20 06:18 XKeysymDB -> ../../X11R6/lib/X1 1/XKeysymDB
<\sh> this is what i was getting this morning as update
<ogra> \sh, xorg only uses /usr/lib/X11
<\sh> ogra, yes...thats why it is wrong
<ogra> \sh, so all the links should be in there
<\sh> but
<\sh> drwxr-xr-x   7 root root   176 2005-06-16 13:17 fonts
<\sh> drwxr-xr-x  58 root root  1824 2005-06-17 16:31 locale
<\sh> -rw-r--r--   1 root root 36378 2005-06-16 17:20 XErrorDB
<\sh> -rw-r--r--   1 root root  8298 2005-06-16 17:20 XKeysymDB
<ogra> and weirdly the link points to ../../
* Nafallo waits with updating ;-)
<\sh> this  is what is in /usr/share/X11
<ogra> yes, with two broken links
<ogra> but
<ogra>  usr/X11R6/lib/X11/XKeysymDB usr/lib/X11/XKeysymDB
<ogra> is whats in the .links file in debian/
<ogra> so it should work
<\sh> yeah...link from /usr/lib/X11/... to /usr/X11R6/lib/X11
<Riddell>  /usr/bin/X11/Xorg points to /usr/X11R6/bin/Xorg which points to itself
<\sh> well, actually it doesn't work
<ogra> \sh, yes, but why ? 
* \sh is getting xorg source
<ogra> \sh, (why are the links wrong even if they are specified right in the .links file)
<carlos> doko, around?
<trulux> fixe
<trulux> fixed
<ogra> \me gets the xorg build log
<doko> carlos: sure
<\sh> ogra, it's wrong
<ogra> \sh, what ?
<\sh> etc/X11/xkb usr/lib/X11/xkb
<carlos> doko, hi. How is the status of OO.org 1.4 vs 2.0 for breezy?
<ogra> \sh, thats perfectly right
<\sh> means : links /usr/lib/X11/xkb to /etc/X11/xkb ?
<carlos>  s/1.4/1.1.4/
<ogra> \sh, and thats not te broken one
<doko> carlos: 2.0
<\sh> ogra, but check it
<ogra> yes, its right, i checked it
<carlos> doko, ok
<\sh> the installed way is: /usr/lib/X11/xkb is a link from /etc/X11/xkb
<ogra> \sh, /etc/X11/xkb is a real directory....
<\sh> so it reads: link from -> link to
<ogra> \sh, not anymore
<carlos> doko, will try to take a look to integrate that version with Rosetta then
<\sh> so /usr/lib/X11/XKeysymDB should be a link _FROM_ /usr/X11R6/lib/X11/XKeysymDB
<doko> carlos: be prepared to store the sdf files as well (somewhere)
<\sh> ogra, ?? it's in this file :) xlibs-data.links
<ogra> yeps
<carlos> doko, that will be a problem, will try to do something to 'elude' it
<ogra> \sh, XKeysymDB isnt moved yet
<\sh> ogra, it's sitting in /usr/share/X11
<ogra> \sh, so  /usr/lib/X11/XKeysymDB should be a link _to_ /usr/X11R6/lib/X11/XKeysymDB
<\sh> ogra, which is
<\sh> ogra, but then /usr/X11R6/lib/X11/XKeysymDB is not existing
<ogra> \sh, please dont confiuse me, i know very well where which link has to go.... rather help finding out why the file is processed wrong
<mpt> ogra: Which do you need a design for most urgently: power management prefs, xscreensaver prefs, or TeachersPet?
<ogra> mpt, power-management-perfs is in flux, i just mailed richard huges (upstream), xscreensaver prefs is the lowhanging fruit i guess and TeachersPet has no even a mockup yet
<ogra> so power-prefs would be a bad idea until we have the upstream freeze i guess....
<mpt> ogra: Yah, I saw hughsie in here before, but too late to chat with him ... Is he willing to simplify the prefs for us?
<syndicate> Is there any reason why packages omit the --enable-kerberos5 or --with-krb5 when the package supports it?
<ogra> mpt, i'm not sure if he is, but i am ;)
<ogra> mpt, he just made an awful change (at least for us)
<mpt> ogra: Well, if he is, I could send him mockups instead :-)
<mpt> really?
<Kamion> syndicate: sometimes because the packager is trying to avoid extra library dependencies in the base system, sometimes the packager knows it's not quite ready upstream, sometimes the packager just forgot
<ogra> mpt, he puts shutdown/hibernate/suspend and reboot into the right click menu of the applet...
<mpt> hehehe
<ogra> mpt, so we have them two times now
<mpt> right click is teh aewsome
<ogra> if he isnt willing to cut that out or given an config option, i'll have to patch it away
<mpt> ogra: So when is TeachersPet scheduled for implementation?
<Treenaks> TeachersPet?
<ogra> mpt, a very basic version should be in the first edubuntu release
<mpt> Treenaks: http://edubuntu.org/TeachersPet
<ogra> mpt, but that will only have support for the most essential stuff, no extras yet
<mpt> ogra: So, same time as Breezy
<ogra> mpt, sadly there are no screenshots of TeacherTool....
<mpt> all righty
<ogra> yep
<Riddell> got X working by extracting by hand and using Xorg from there, it replaces /usr/X11R6/bin/Xorg with a symlink to itself otherwise
<mpt> ogra: http://school.qop.org/lmontes/teachertool.png ?
<Treenaks> this will make "hacking the school network" so much more challenging then the "NET LOGIN" I had to do ;)
<mpt> haha
<ogra> heh, mpt yes, enjoy the ugliness
<mpt> ogra: No relation to http://homepage.mac.com/teast/ttool.jpg I assume
<mpt> (though that's also extreme ugliness)
<ogra> mpt, nope and yes :)
* mpt shakes his head in disbelief
<mpt> It must have taken serious, serious effort to alter that window so that it was turqouise and pink rather than standard Aqua
<ogra> mpt, the end version of TeachersPet should visualize as much as possible... i'm thinking about little screenshots of the pupils deskst or something to click on
<`anthony> grump. which genius thought it was a good idea to ship a stripped python binary?
<mpt> ogra: excellent idea
<ogra> `anthony, thats what you get from packagers the watch too much pr0n.... they wat everything stripped ;)
<Treenaks> ogra: that can become quite annoying with 30+ students on a 17" screen
<ogra> mpt, but thats rather breezy+1
<ogra> Treenaks, so i have to solve it ;)
<ogra> Treenaks, but i have plenty of time, atm i just want TeacherTool replaced and as a base for further development
<mpt> ogra: So, just a list to start with
<ogra> mpt, yep
<Treenaks> ogra: matrix interface ;)
<ogra> mpt, btw, we have other ugliness.... your second shot just reminded me... have a look at ggradebook
* ogra has to grab some coffe
<hunger> Anyone got /dev/tpm supported in ubuntu yet?
<Kamion> stripped python binary> *all* binaries are stripped; if there's a non-stripped variant it should go in python2.4-dbg or similar
<doko> `anthony: the genius' name is "debian policy"
<doko> just install python-dbg
<mpt> ogra: Is that gtk 1.x?
<`anthony> might be a nice option to have a python-dbg package that has a python built --with-debug and nonstripped.
<`anthony> would make life much more pleasant for people working with C code extensions
<mpt> must be, their latest news item is from 2001
<doko> `anthony: already there
<Kamion> doko: only in universe; maybe we should put it in main
<`anthony> doko: you rock! please give guido the keys to the timemachine when you're done with them... ;)
<mpt> ogra: http://lists.gnu.org/archive/html/ggradebook-devel/2005-06/threads.html -- it's dead
<`anthony> doko: might be a good idea. a debug build makes hunting down bugs much more pleasant.
<ogra> mpt, its in breezy
<`anthony> (currently I'm fixing the dbus bindings, teaching it about PyGILState_Ensure/Release :-/)
<doko> `anthony: it is a separate build using --with-debug and nonstripped, and contains debugging symbols for the normal python binary
<ogra> mpt, and its the default tool k12ltsp uses... i havent found anything else yet
<mpt> Does anyone use k12ltsp? :-(
<ogra> mpt, yeps
<mpt> We must save them!
<ogra> mpt, skubuntu did obviously some installs the last years in .za
<mpt> skubuntu?
* mpt reads about it
<doko> Kamion: added to UbuntuMainInclusionQueue
<mjg59> ogra: Rock
<ogra> mpt, a .za initiative for bringing linux into the schools
<ogra> mjg59, yay
<doko> roman numbers fun: http://mail.python.org/pipermail/python-dev/2005-June/054292.html
<mpt> ogra: Okay, so, xscreensaver -> TeachersPet -> gnome-power -> ggradebook
<Duck_work> coin
<ogra> mpt, yeps, sounds good... i'm not sure if we have time left for a ggradebook port...
<mpt> Breezy+1 is the answer to all life's thorny questions
<mpt> ogra: btw, did you know about http://teachers-pet.org/ ?
<mpt> Teacher's Pet might need a different name
<ogra> its my work name :)
<mpt> arr, a working title
<ogra> but it would have made a nice name... sad
<ogra> argh
<ogra> You must have Microsoft Word to be able to use this software.
<ogra> If you don't, check out this vast selection of useful websites for teachers.
<ogra> PHEEER
<mpt> It's probably a collection of Word macros
<mpt> viruses optional
<ogra> i guess all they offer is VB
<ogra> yeps *g*
<ogra> Duck_work, there is a guy who wants to become a MOTU, he wanted to package mediawiki, probably you two should talk :)
<thom> does blam actually work currently?
<Duck_work> ogra: he should try to become a DD and push it to Ubuntu then
<Duck_work> ogra: who is he ?
<ogra> Duck_work, but if i got it right, you already packaged it
<ogra> Duck_work, /join #ubuntu-motu, look for GNULinuxer
<Duck_work> ogra: yes, but i'm too busy to maintain it, so it is unofficial packaging, i'm ok to comaintain (mostly because i use it), and ok to sponsor
<Duck_work> oky
<ogra> Duck_work, he is very new and could need a helping hand
<\sh> guys, anybody alive who can force a package into the buildds? only on ppc?
<Duck_work> ogra: my only problem is time, but i'm ok to help of course
<ogra> Duck_work, great :)
<ogra> Duck_work, how rich are you, that you are able to give coins to everybody.... or are they only for the local washcenter ?
<ogra> :)
<Duck_work> ogra: :-)
<mpt> ogra: Are you keeping an eye on gnome-screensaver?
<ogra> mpt, its not feasable.... insecurity everywhere
<ogra> mpt, i'd prefer jdubs idea of a freescreensaver spec at freedesktop.org and work along this one...
<mpt> ogra: Why are people working on it? Do they not know about the insecurity? Or do they know and not care?
<ogra> mpt, the problem is, you cant introduce a widget toolkit in a safe way into the lock code....
<mpt> ogra: So how would a freescreensaver spec help that?
<ogra> mpt, thats why i wrote my patch as it is...
<ogra> mpt, not at all, but you could specify a secure framework where every DE could hook in with its widgets for example... but thats a long process to do it right...
<tseng> you'd have to look at the NSA spec on secure X
<mpt> O.
<ogra> mpt, and i honestly dont know why they are still workig on gnomescreensaver, i thought it was dead
<tseng> policy on a window manager, trusted input and all that
<thom> tseng: does blam work for you?
<tseng> thom: yes
<thom> hrmph
<tseng> thom: fix it on amd64 plzkthxbi
<thom> bah
<thom> lamer :-)
<tseng> well you could send me one
<mpt> ogra: 26 checkins so far this month :-] 
<tseng> and ill start filing bugs and testing for you
<tseng> your choice
<Nafallo> thom: blam --sync works ;-)
<ogra> mpt, rather a question we should ask jdub
<Nafallo> thom: btw, is nm-applet supposed to freeze all the time? :-)
<thom> Nafallo: it doesn't
<thom> obviously. because no-one has filed a bug claiming that, and it doesn't here
<Nafallo> thom: hmm, might be something local then.
<thom> ;-)
<thom> ok, yes, sync works
<Nafallo> thom: hehe, I should file a bug then :-). just want my keyboard back first :-P.
<thom> thanks
<ogra> Nafallo, working on it over here
* lamont -> work
<Nafallo> ogra: ahh, you got that bug to? :-)
<hunger> Did the last X update fix keyboards again for someone? Mine still is broken.
<ogra> hunger, nope, the fix was broken
<hunger> ogra: Too bad. Thanks for the info though.
<chrissturm> ogra: i made the links manually and its still broken. do i need to run anything after creating the links or just restart X?
<Nafallo> ogra: d'oh! you meant Xorg ofcourse :-P
<ogra> chrissturm, only restrt X
<ogra> chrissturm, one has to point from /usr/X11R6/lib/X11/xkb to the dir /etc/X11/xkb
<chrissturm> ogra: is that the correct link: lrwxrwxrwx  1 root root 24 2005-06-20 14:02 /usr/lib/X11/XKeysymDB -> /usr/share/X11/XKeysymDB ?
<ogra> chrissturm, nope, thats completely wrong
<ogra> err, sorry, the last one you showed was right
<ogra> chrissturm, but you need both
<ogra> too many links around me today
* ogra whishes for infinity
<chrissturm> ogra: its still not working for me, but i'm probably making some kind of stupid mistake
* \sh whishes for infinity too, or someone who has access to ppc buildd ;)
<pitti> \sh: I have
<\sh> pitti: wonderful :)
<pitti> \sh: well, not to a buildd, but to a developer dchroot
<ogra> chrissturm, 
<ogra>  ls -l /usr/lib/X11/X*
<ogra> lrwxrwxrwx  1 root root 28 2005-06-20 02:20 /usr/lib/X11/XErrorDB -> ../../X11R6/lib/X11/XErrorDB
<ogra> lrwxrwxrwx  1 root root 29 2005-06-20 02:20 /usr/lib/X11/XKeysymDB -> ../../X11R6/lib/X11/XKeysymDB
<ogra> err...
<ogra> huh ?
<\sh> pitti: no i need to have someone who can throw a package again to a buildd
<Kamion> ("give-back")
<\sh> to our buildds ;)
<pitti> \sh: oh, that's infinity's job
<ogra> chrissturm, erm, the above is wrong
<ogra> argh... this links drive me CRAZY !!
<\sh> it's working..it took it
<ogra> and i still have no idea why debian/xlibs-data.links isnt processed at all
<\sh> Kamion, what does it mean "give back"?
<\sh> ogra, check yellow pages ;)
<Duck_work> ogra: GNULinuxer has some homework to do, he has a lot to learn, if he works well, i would sponsor/comaintain mediawiki into Debian and ask you or someone kind here to sponsor it into Ubuntu
<ogra> Duck_work, sure :)
<ogra> Duck_work, he'll do his homework with us ;)
<\sh> and ogra will review his php package ;-)
<ogra> \sh, never
<\sh> ogra, yes, what do u think mediawiki is ;)
* ogra shudders 
<Duck_work> ogra: php is not harmful
<ogra> Duck_work, php is ugly 
<ogra> Duck_work, ... and insecure
<ogra> i prefe python
<ogra> prefer even
<Duck_work> yea, ruby is quite better, but php works in some ways
<chrissturm> ogra: take a look at ruby on rails
<ogra> and eve a perl cgi is better then php
<Duck_work> ogra: it is just helping a NM, not taking care of php stuff yourself
<karlheg> I think it has more to do with the coding style of many PHP programmers than with PHP itself.  HTML::Mason provides a good framework that PHP programmers could adopt, I thought.  I've seen too many PHP scripts that embed HTML in print statements.
<ogra> Duck_work, i know... i'll look at the packages.... 
<Duck_work> ogra: i'll look too, don't worry
<Kamion> \sh: 14:29 < \sh> pitti: no i need to have someone who can throw a package again to a buildd
<Kamion> \sh: it means that
<Kamion> but it's the technical term for it
<ogra> ARGH, dh_link isnt called _AT ALL_ in the xorg rules file....
<ogra> i'm going crazy 
<ogra> ah, found iz
<Kamion> aargh, gnome-session totally breaks on a fresh installation
<Kamion> maybe it doesn't like xterm being missing or something
<ogra> Kamion, what do you get ? 
<ogra> Kamion, i had a funny X dialog today.... but it went away after i choose a session in gdm
<Kamion> I've rebooted now, sorry; some X dialog with "chooseSessionListDialog" or something like that in it
<ogra> yep, same here
<Kamion> chooseSessionListWidget
<ogra> the gdm default session seems broken
<Kamion> /etc/gdm/Xsession: Cannot find Xclients
<Kamion> ctrl-alt-F1 doesn't work!
<ogra> it works as soon as you select gnome ...
<Treenaks> ogra: ctrl+alt+f1 too?
<ogra> Kamion, thats what i'm working on currently
<Kamion> whoever totally wedgied X, please let go of its underwear
<Kamion> ah
* Treenaks guesses.. thom & daniels ?
<ogra> Kamion, daniels broke it...mdz and i tried to fix it yesterday...mdz introduced the fix, but xorg seems not to read the debian/xlibs-data.links file at all... i have no idea why
<Treenaks> ogra: so that's why xkb is broken as well?
<ogra> Treenaks, yeps
* Treenaks orders some beer on daniels' account
<ogra> Treenaks, missing links to XKeysymDB and xkb
<bob2> daniels' account only allows vodka to be purchased
<Treenaks> bob2: then I buy a case of that
<Treenaks> bob2: want some?
<bob2> but of course
<Kamion> ogra: the symlinks seem to be there
<Kamion> lrwxr-xr-x root/root         0 2005-06-20 00:23:27 ./usr/lib/X11/XErrorDB -> ../../X11R6/lib/X11/XErrorDB
<Kamion> lrwxr-xr-x root/root         0 2005-06-20 00:23:27 ./usr/lib/X11/XKeysymDB -> ../../X11R6/lib/X11/XKeysymDB
<Kamion> lrwxr-xr-x root/root         0 2005-06-20 00:23:27 ./usr/lib/X11/xkb -> /etc/X11/xkb
<ogra> nope
<Kamion> that's from the package on rookery
<ogra> err
<Treenaks> -30 ?
<Kamion> yes
<ogra> they should point to /usr/share/X11
<ogra> ha... thats the bug, great, thanks Kamion 
<ogra> i just got blind in this linkage jungle
<Kamion> np
* Treenaks waits for -31 ;)
* ogra starts a testcompile
* Treenaks cheers on ogra 
* thom wonders how i'm getting blamed
<ogra> heh
<Treenaks> thom: well, it looked like gdm broke to mee
<Treenaks> -e
<thom> well, that's seb
<thom> i'm pretty sure i can't be implicated at all
<maswan> thom: btw, dns update for releases.ubuntu.com, can you do those? 130.239.18.137 has been taken out of ftp.acc.umu.se for a while, and won't be returning back soon either. so perhaps an update to releases.ubuntu.com would be in order?
<thom> maswan: best to ask elmo
<maswan> thom: Ok.
<maswan> elmo?
<Treenaks> thom: that's what seb always says too
<maswan> I haven't had much luck in getting hold of him, but then I've been gone for most of last week anyway.
<Nafallo> maswan: e-mail? :-)
<maswan> Nafallo: oh. neat idea.
<Nafallo> hehe
<torkel> e-mail is so last year :-)
<maswan> Nafallo: I'll take a look at it. I've neglected my email much more than irc the last week though. Slowly working through my inbox now. :)
<Nafallo> maswan: well, that would probably end up in yor _outbox_ ;-)
<ogra> pitti, doko, mvo seen that one ? http://www.sueddeutsche.de/kultur/artikel/826/54772/
<ogra> mostly wrong, but ositive all over      atleast
<pitti> ogra: thanks for the link :-)
<mvo> ogra: sometimes it makes me very worried how inaccurate the media is :/
<doko> ogra: yes
<ogra> mvo, especially from the sueddeutsche i hadnt expected such a bad researched article
<mvo> ogra: exactly
<Lathiat> doh X is totally broken again
<Treenaks> ogra is looking at it, afaik
<infinity> s/again/still/
<infinity> And yes, ogra is the new Xorg slave.
<infinity> daniels's master plan of "break stuff and then run away" is slowly creating a maintenance team, I think. :)
<infinity> (maybe that was his plan all along)
<Lathiat> haha
<Treenaks> infinity: that technique is not described in CatB... it should be added :)
<Lathiat> is there a temp workaround?
<zul> heh...dont restart x
<infinity> EVER.
<Lathiat> too late
<Lathiat> p
<Lathiat> ;p
<zul> works for me
<Lathiat> so whats daniels do
<Lathiat> ing
<Lathiat> conferencing
<Lathiat> ?
<Nafallo> I would tip on LinuxTag ;-)
<Nafallo> with the XOrg meeting and all :-)
<infinity> Indeed, even as we speak, he's probably shoving his modular work down everyone's throats.  In a nice, community-friendly way.
<infinity> (which means, getting them all drunk, committing it all to CVS, changing the timestamps on the archive, then convincing them "it was always like that")
<Nafallo> lol
<Lathiat> i fixed it now
<Lathiat> cd /usr/bin/X11; ln -s ../../X11R6/bin/X .
<ogra> Lathiat, erm, that works ?
<Lathiat> ogra: it does
<Lathiat> basically it wanted /usr/bin/X11/X but it wasin /usr/X11R6/bin/X
<Lathiat> it was in /usr/bin/X11/X yesterday tho
<ogra> Lathiat, the clean ix would be: cd /etc/X11; sudo ln -s /usr/bin/X11/Xorg .
<ogra> s/ix/fix
<Lathiat> oh?
<Lathiat> ok
<ogra> but if the other worksa too.... dont worry
<ogra> :)
<ogra> X is a link maze currently
<hunger> ogra: That fix does not work.
<Mithrandir> ogra: or cleaner: ln -sf /usr/X11R6/bin/Xorg /etc/X11/X so you get the right name of the link in /etc/X11 too. :-P
<hunger> ogra: startx won't work with symlinks.
<ogra> hunger, it does here....
<hunger> ogra: startx or kdm?
<ogra> hunger, oh, startx is something else i dont care about currently
<hunger> ogra: s/kdm/gdm/
<ogra> hunger, what is kdm *g* ?
<ogra> hunger, sure, gdm should work this way
<ogra> hunger, but its likel that all this stuff will change randomly again once daniels took over again
<ogra> likely even
<hunger> ogra: Yeap, I'm heading back to hoary.
<ogra> hunger, i'm just doing temporary fixes because i need a working LiveCD build this week
<hunger> ogra: I am doing temporary fixes as I need a somewhat working computer;-)
<ogra> heh
<hunger> ogra: I prefer spending my time with setting up ubuntu on a encrypted HD with keys stored in the TPM chip to fixing X over and over again.
<ogra> hunger, so its about time you become a MOTU and join daniles X team we just found here *g*
<hunger> ogra: I have no clue how to become a MOTU.
<ogra> hunger become a member first.... (i.e. create a wikipage about you, make some contribution like a howto wikipage, artwork or a bugfix, set yourself on the CC agenda and get approved)
<hunger> ogra: Do updates to howtos count? I did some of those already.
<ogra> hunger, after that, you join #ubuntu-motu an work a bit with the team to show your packaging skills (or to gain them...as you like) put yourself on the TB agenda and get approved as MOTU
<ogra> hunger, it might be enough, depends....
<dholbach> hi
<dholbach> how do i fix X this time? :)
<hunger> ogra: Damn... I need to remember my launchpad login for that... If only I could remember which of my email accounts I used for that... then guessing the password would be way easier;-)
<syndicate> err... I'm messing around with dput, and I think I just uploaded my application's .deb to ubuntu
<dholbach> syndicate, if you're in none of the keyrings, it will be ignored
<syndicate> excellent
<syndicate> I didn't realize the default in /etc/dput.cf was upload.ubuntu.com
<dholbach> syndicate, what did you expect?
<ogra> dholbach, i'm fixing X ... wait 20h until my testcompile is done and i can upload
<ogra> or 30h
<ogra> or 40
<dholbach> ogra, and then another two hours?
<ogra> dholbach, or fix the XKeysymDB links again
<dholbach> ok
<ogra> dholbach, mdz put in the wrong link target
<dholbach> nasty nasty xorg
<ogra> as i said 10 min ago... its a linkage maze
<dholbach> i can imagine
<syndicate> dholbach: I expected nothing
<dholbach> and i don't blame anyone :)
<ogra> dholbach, btw, \sh wants to get a kde package reviewed.... so you could get glom reviewed by him....
<ogra> would give you the second reviewer
<ogra> syndicate, sorry, that was my patch....
<dholbach> ogra, later today, maybe after the MOTU meeting - i really want to work a bit on my thesis (when i got X working again)
<ogra> syndicate, more people in ubuntu are uploading to ubuntu now ;)
<tim_> MOTU meeting?
<ogra> tim_, yes
<tim_> whats that stand for?
<tim_> meeting
<tim_> of
<ogra> tim_, 22:00 UTC in #ubuntu-meeting today
<tim_> the
<dholbach> tim_, wiki.ubuntu.com/MOTU
<tim_> ubuntu
<syndicate> ogra: haha, that's awesome
<syndicate> that's a subversive way to recruit developers :)
<ogra> syndicate, yes, but we had to many complaints from debian *g* 
<ogra> syndicate, if i can get new devs, any way is right :)
<syndicate> hey, whatever works :)
<seb128> thom: firefox patch for epiphany: https://bugzilla.mozilla.org/attachment.cgi?id=172346 (you probably drop it somewhere)
<seb128> thom: if you can use it again for next upload ... :)
<thom> seb128: noted
<seb128> thanks
<thom> ogra: ccache is love
<ogra> thom, you mean it prevents me from overheating ? 
<dholbach> see you in a bit
<ogra> thom, 4GB of ram is love.... at least 2 are ordered....
<ogra> cmpiling x on 512MB is just silly....but i have no bigger machine around currently
<thom> ogra: nod
<ogra> ok, everybody crosses fingers....
<ogra> hmm
<Nafallo> ogra: ?
<ogra> i still get the xkb error message... but it works fine... 
<ogra> on two independent setuos...
<ogra> stups
<ogra> setups MAN !
<ogra> ok, it cant be worse then it is anyway, lets upload....
<Lathiat> yeh xkb error isnt an issue
<Nafallo> :-)
<Nafallo> Lathiat: it is, but a minor compared... ;-)
<ogra> Lathiat, it was gone before with my manual links
<ogra> Lathiat, so i dont really understand why it still shows up.... even if i to the checks mentioned in the dialog, everything is fine...
<ogra> s/to/do
<Keybuk> don't suppose anyone knows what does bluetooth file transfers?
<Keybuk> </random>
<Lathiat> Keybuk: gnome-bluetooth
<Lathiat> Keybuk: then you get the gnome obex stuff
<Lathiat> Keybuk: can sendand recv then
<Lathiat> wfm(tm)
<tseng> livecd question.. is it true that removing something from the fs doesnt zero it and doesnt free all the space?
<tseng> if so, whats the fix.
<ogra> tseng, i could tell you if i had a working liveCD image yet....
<ogra> tseng, but i probably can by the end of the week
<tseng> well im pretty sure its true, a bunch of people experience it
<ogra> depends on xorg
<tseng> jdong said something about rsyncing it to another file
<tseng> but.. he didnt document anything on the wiki
<ogra> meh
<tseng> yeah, big help
<ogra> heh... like backports *g*
<tseng> quite.
<Keybuk> Lathiat: I did a Scan, it said it found it, but I don't "see" anything ?
<Lathiat> go applications->system->bluetoothfilesharing
<Lathiat> actually
<Lathiat> hm
<Lathiat> gnome-obex-send
<Lathiat> <file>
<Lathiat> theres a nautilus send-to patch floating aroudn to suport bluetooth
<chmj> gnome-bluetooth-manager does nothing 
<Lathiat> but i dont think its integrated
<dholbach> Keybuk: the nautilus right-click thingie is broken
<Weems> has anyone texted the colony 1 cd?
<Weems> texted*
<Weems> tested*
<Weems> Sorry I cant type very well.
<Keybuk> dholbach: I'm trying to send from my phone to my computer
<Keybuk> rather than the other way around
<Kamion> Weems: those CDs are always tested before release
<Weems> so it wont bork or anything?
<chmj> Keybuk, is you phone pair with the computer ?
<Lathiat> Keybuk: in taht case open bluetooth file sharing
<Lathiat> Keybuk: from the system menu
<Lathiat> Keybuk: and then send
<Lathiat> Keybuk: you'll also need bluez-utils installed
<Lathiat> then a dialog should popup
<Keybuk> Lathiat: yup, got it
<\sh> re
<ogra> xorg_6.8.2-31_source.changes ACCEPTED
* ogra looks for some place to hide for the rest of the week
<pitti> ogra: you broke X harder? :-)
<ogra> pitti, i hope i didnt :)
<\sh> ogra, dig a hole, jump inside the hole and put something over the hole ;)
<ogra> at least it works, even if i still get the xkb eroor message.... but i'll let this one to daniels
<ogra> \sh, after i filled it with cool water.... its way to warm here today
<\sh> ogra, yeah :)
<\sh> ogra, but when your update is repairing my X, I will hug you ;)
<\sh> s/X/KDE/ ;)
<ogra> \sh, i really didnt test KDE :)
<ogra> \sh, but it works with gnome
<\sh> ogra, i know :) but I will..:)
<\sh> gnome is working just fine here ;)
<ogra> \sh, if you find a fix, tell me... i have sthe surce here anyway
<\sh> ogra, i have the source as well :)
<chrissturm> ogra, you get the xkb error, but your keymap still works?
<ogra> chrissturm, yeps
<ogra> chrissturm, and that is what counts for the moment... i'm not the X maintainer and am not after being it ;)
<ogra> its just a selfish cause that drove me to fix it.... sine i need a Breezy LiveCD this week....
<ogra> since even
<chrissturm> ogra: its strange that it doesnt work for me, i think i have the right links, but i will just wait for your packages
<chrissturm> all keys i need for coding dont work :)
<ogra> chrissturm, please report if they dont work
* ogra is sure he will hundrets of complaints anyway :)
<ogra> s/will/ will get
<\sh> 7topic ogra broke it
<ogra> meh
<\sh> 7topic don't complain about X the next 70 weeks 
<Nafallo> \sh: ey! it will have to be in shape for the release ;-)
<ogra> heh... nope, only until daniels is back 
<\sh> Nafallo, it should be in shape for the release ;)
<Nafallo> \sh: 70 weeks are like... breezy+2 :-P
<Amaranth> Nafallo: at least people won't complain about X for awhile
<Nafallo> Amaranth: hehe
<Amaranth> Nafallo: They'll complain about 70 weeks being too long instead.
<\sh> Nafallo, right ;) so what...breezy without X -> forked debian distribution for geeks ;)
<Nafallo> \sh: lol
<ogra> Amaranth, would you like to help me on a project ? i need someone with decent menu spec knowledge
<Amaranth> err, ok
<Amaranth> does it have anything to do with WINE?
<ogra> Amaranth, http://www.edubuntu.org/TeachersPet
<ogra> nope
<Amaranth> oh, ok
<\sh> Nafallo, anyways...70 weeks it's not much..we well release breezy+2 before etch ;)
<ogra> its smeg on drugs
<Nafallo> \sh: that was almost mean ;-)
<Amaranth> oh, that's why someone requested group settings as a feature for smeg
<Amaranth> afaik you can't do groups, not like you think
<Nafallo> ogra: hehe, is that the description-field? ;-)
<\sh> Nafallo, I know...but when I read all this crap on d-d sometimes u have to be mean ;)
<Nafallo> \sh: indeed, that
<Nafallo> \sh: indeed, that's why I
<Nafallo> \sh: indeed, that's why I'm here instead of debian
<ogra> Amaranth, i can do groups.... if i plug it in the layer above
<Nafallo> STUPID KEYBOARD!
<Amaranth> ogra: true
<Amaranth> ogra: well, the latest PyXDG releases have this class called MenuEditor that does most of the work for me, so there isn't much to it anymore
<ogra> Nafallo, nope, i guess teachers wouldnt like this description synopsis
<ogra> Amaranth, ah
<Nafallo> ogra: hehe :-)
<ogra> Amaranth, i'll come back to you if the time is right
<Kamion> \sh: which is kind of non-fun to deal with when you care about both projects
<ogra> Amaranth, currently TeachersPet is still in planning stage
<Amaranth> ah
<Amaranth> that's what you were hired for? edubuntu work?
<ogra> Amaranth, so if you have cool ideas... drop them at me :)
<ogra> Amaranth, nope.... i was hied for my beautiful face, now they try to fit me in anywhere ;)
<Amaranth> hehe
<ogra> hired even
<\sh> Kamion, well I read all the stuff, sometimes it's just like that, that there is a group of people, who wants to take action, but they can't because the boss doesn't say a word..it's a problem of too much democratic decisions
<Kamion> \sh: sure, but while one of the reasons Ubuntu was created was because we filled a niche created by problems in Debian, that doesn't mean we're a "debian sux0rs" forum
<\sh> Kamion, I'm not a "debian sux0r" but they should see the needs of the user 
<Nafallo> Kamion: I don
<Nafallo> Kamion: I don't think we are :-).
<Kamion> and some Debian people hang out here because they're curious about what we're doing, so we should be polite
<Nafallo> Kamion: we only mentioned one of the problems that seems to be real hard to solve (i.e. all those flamewars).
<\sh> I'm polite :) but let me have a little bit of my personal irony :)
<Nafallo> I do believe etch is out in a year or so though :-)
<Amaranth> Nafallo: Let's hope.
<ogra> \sh, they have policies that simply keep them away from users needs in some places, in favor of policy....
<ogra> \sh, but without these policys we couldnt even build ubuntu on top of debian, so there is nothing wrong with it
<Nafallo> Debian serves a higher purpose than to be on each and everyones desktop IMO :-).
<ogra> yeps
<\sh> well, sometimes someone has to think over the policies and rules and adjust them to the present and future time. 
<Kamion> I see mdz's one of the Debian policy editors now, so perhaps he will help with that
<\sh> that's not mean, that's not unpolite 
<Amaranth> if the computer is trying to read past a HD's end, what should i blame?
<Amaranth> kernel, memory, HD, or program?
<wasabi_> What?
* sladen notes top storey on LWN.  That'd be Kamion as part of the Debian Release Team talking about the next Debian release:  http://lwn.net/Articles/140570/
<Amaranth> [4296494.876000]  attempt to access beyond end of device
<Amaranth> [4296494.876000]  hda1: rw=0, want=19029696640, limit=24219153
<wasabi_> haha
<wasabi_> I've never seen such a thing!
<sladen> ''clearly these scary Ubuntu people are trying to take-over Debian''  ;-)
<Kamion> sladen: er ... I wasn't in that meeting, I was excused
<wasabi_> I wonder if that means a program tried to skip past the end of the block device?
<Amaranth> wasabi_: That's encouraging.
<Kamion> and I'm taking a vacation from the Debian release team at the moment
<Amaranth> i think it happened when i started muine, that's the first app to go bad on me
<Amaranth> and muine uses inotify...
<tseng> no it doesnt
<Amaranth> um
<Amaranth> it does here?
<tseng> elmo is holding that version
<tseng> unless i snuck you one?
<Amaranth> you did
<tseng> oh.
<tseng> nm then :)
<carlos> fabbione, around?
<fabbione> carlos: yes
<carlos> fabbione, hi
<fabbione> hi
<carlos> fabbione, do you remember the PATA vs SATA I told you and that I reported this morning?
<carlos> fabbione, I moved that server to breezy to test with latest kernel
<fabbione> yes, but i didn't look at bugs yet today
<carlos> but I'm not able to boot tha 2.6.12-1-686
<carlos> get a kernel panic because it cannot open dev/console
<Nafallo> tseng: I was about to say something, but remembered I built it from source :-P.
<fabbione> carlos: hmmmmmm that looks more like a mkinitrd problem
<fabbione> carlos: did you upgrade the entire machine to breezy in one shot?
<carlos> fabbione, yes
<carlos> and as I thought the same about mkinitrd
<fabbione> carlos: can you try to just reinstall the kernel?
<carlos> I removed the kernel with --purge
<carlos> and installed it again
<carlos> but still get the error
<Amaranth> *groan*
<Amaranth> system hardlock and broken X on reboot :)
<fabbione> carlos: can you send the generated initrdimage to jbaley please?
<fabbione> carlos: that error is really not kernel related
<carlos> ok
<ogra> doko, you want to conquer the debian release team ?
<fabbione> carlos: /wind goto 6
<fabbione> ops
<carlos> fabbione, thanks
<doko> ?
<ogra> doko, or did you just attend for the fun of it ?
<ogra> http://lwn.net/Articles/140570/
<ogra> further attendends:
<ogra> Ryan (neuro), Joerg (Ganneff), Frans (djp), Matthias (doko), Jeroen (jvw)
<ogra> and further.
<doko> looking at the followups, it was no fun ...
<Kamion> ogra: doko's attendance was relevant due to the C++ transition
<jvw> wtf, lwn copied the minutes?
<ogra> ah
<jvw> Joy
<dholbach> jvw: they even copied the motu report :)
<Kamion> although that's not minuted
<Kamion> jvw: lwn are very very bored
<jvw> yeah
<jvw> instead they should run some conspiracy theories of canonical taking over Debian by employing the chairman of its highest technical board
<fabbione> carlos: thanks for the pictures, but i need to see what few lines above that :(
<fabbione> carlos: there is a line called EIP:
<fabbione> carlos: that's the one we must catch
<bob2> canonical could corrupt all those crucial tech board decisions!
<fabbione> carlos: you can also try to boot using irqpool 
<jvw> bob2: every one of the bi-yearly ones!
<fabbione> carlos: it looks to me a possible irq issue (note the do_IRQ calls)
<bob2> I don't think I want a corporation deciding the output format of 'md5sum'.
<jvw> heh
<carlos> fabbione, the problem is that I cannot get anything else than what you have there
<carlos> fabbione, the keyboard does not let me see the text before that
<fabbione> carlos: i understand.. and my problem is that without EIP i can't debug :)
<carlos> Only Ctrl+Scroll Lock works
<carlos> fabbione, any suggestion to get it?
<carlos> hmm
<fabbione> carlos: not at the moment.. there is a sequence of keys to dump stuff
<fabbione> but as usual i can never remember it
<fabbione> my kernels don't crash on me
<carlos> perhaps a boot with framebuffer so the display gets more lines?
<fabbione> everybody should run on the same hw i have
<fabbione> carlos: that's an idea
<carlos> fabbione, :-)
<zul> fabbione: you know napoleon was italian ;)
<carlos> fabbione, ok, will try to figure a way to do that.
<fabbione> carlos: great thanks
<dholbach> see you
<Nafallo> mdz: morning :-)
<mdz> morning
<fabbione> hey mdz
<mdz> ogra: the xkb thing is not entirely fixed for me yet
<ogra> mdz, wait fo -31
<ogra> for
<mdz> ah
<Kamion> it's built on i386 and powerpc now
<ogra> mdz, your link targets were wrong, you just restored the old ones, but the targets changed obviously
<mdz> ogra: yes, I suspected
<ogra> mdz, took me half the day to even see the error.... thanks to Kamion again...
<carlos> is just my imagination or Breezy's GNOME/X are faster than Hoary's?
<Nafallo> carlos: you're not the first one to say that... so :-)
<carlos> wow, it's a big difference
<ogra> i dont think someone has done any measurements yet
<Nafallo> hehe, I believe I switched to breezy when it was created, so I wouldn't know :-)
<fabbione> Dear Mdz and Ogra, please stop uploading X.org otherwise our poor unsupported buildd will never manage to get one in the archive. kthxbye :P
<thom> dear sparc, compile faster, love ubuntu
<ogra> fabbione, we have a unsupported buildd ?
<fabbione> thom: hppa is affected too :)
<fabbione> ogra: hppa/sparc?
<Kamion> ogra: have done for ages
<fabbione> this time sparc will make breezy
<fabbione> we have 2 buildds!
<ogra> fabbione, it thought it was well supported by pinhead and friends ;)
<fabbione> and we are in front of hppa of a good %
<fabbione> ogra: ehehe
<fabbione> we only have one little tiny problem to solve... the kernel doesn't link properly with the breezy toolchain...
<fabbione> just a minor detail
<fabbione> hoary was due to gcc-4.0
<fabbione> breezy will be to ?? <- we accept bets :P
<mdz> fabbione: it is more important to get keyboards working on our supported architectures than to worry about unsupported ones
<fabbione> mdz: i know man.. hence the ":P"
<fabbione> it seems like you guys are timing uploads...
<fabbione> right before i am signing the packages the new version hit the archive :)
<thom> they're trying to save you from rsi
<fabbione> rsi?
<fabbione> is that a new desease for nerds?
<Kamion> repetitive strain injury
<fabbione> eheheh
<fabbione> let's warm up davis...
<fabbione> thom: should we try to beat concordia's top load?
<fabbione> davis has more ram and should be able to manage :)
<fabbione> Kamion: when would be ok for you to drop power3/power4 kernels?=
<Burgundavia> jdub, can you look at http://bugzilla.gnome.org/show_bug.cgi?id=308148
<elmo> fabbione: dude, if you kill concordia again, lifeless will fly to .dk to teach you alesson
<fabbione> elmo: i didn't even use it friday
<fabbione> i didn't kill it
<elmo> fabbione: hundreds would believe you; not me ;-P
<fabbione> elmo: ahah i am loading davis for real now
<fabbione> that machine is impressive
<fabbione> -j500 and it's not suffering
<Nafallo> lol
* dilinger blinks
<fabbione> it still has 300MB of free ram
<ogra> fabbione, so push it to -800 then :) for the fun of it
<fabbione> that means i could fork more
<fabbione> ogra: -j800 would kill it
<fabbione> and elmo as a consequence will kill me
<ogra> yep
<Nafallo> hehehe
<ogra> fabbione, hey, he could sit longer in the ariconditioned DC then... you do him a favour
<fabbione> elmo: hey consider me a good stress test for when we get new hardware :)
<dilinger> fabbione: it's all about make -j$RANDOM
<ogra> dilinger, wow, thats cool
<fabbione> dilinger: ehehe
<dilinger> or perhaps $((RANDOM/10))
<fabbione> does anybody have the timestamp of when i said that it was spiking?
<dilinger> if you want to see some values below 1000 sometimes :)
<fabbione> and now
<Kamion> fabbione: as long as there's a powerpc64 kernel or whatever replacing them
<Kamion> why oh why does baz spit out *context* diffs in .rej files
<Kamion> ?
<Keybuk> that's traditional
<Kamion> it's the 21st century
<Keybuk> well, yes
<Keybuk> more annoying are the .rej files that contain "Don't look here"
<Keybuk> or somesuch
<Keybuk> for complicated merges, I prefer .rej to 3diff, as emacs has a nice mode for it
<elmo> ok, I think we need to introduce a penalty system for rapid successive uploads of xorg
<Mithrandir> elmo: 2^n lashes with a whip (per 24 hour period)
* ogra digs a deep hole and hides
<Keybuk> Mithrandir: you'd enjoy that too much
<Mithrandir> Keybuk: I don't upload xorg.
<fabbione> elmo++
<cartman> X.org borked again?
<Amaranth> most likely
<Nafallo> cartman: always ;-)
<Amaranth> xkb problems in -30
<cartman> Nafallo: I swear -24 was working
<cartman> Amaranth: startx doesn't work here
<cartman> :/
<bob2> -24 was a like 6 uploads and 3 hours ago
<seb128> -24 works fine, I use thi sone :p
<bob2> get with the times!
<cartman> no /usr/bin/X11/X
<Nafallo> cartman: -10 worked :-)
<cartman> bob2: hehe
<Amaranth> what version did we have last sunday?
<seb128> yesterday?
<Amaranth> no, the one before that
<cartman> is /usr/bin/X11/X thing fixed in -31 ?
<cartman> any ideas?
<cartman> missing symlink?
<cartman> xkb is easy
<cartman> its just a missing symlink
<Amaranth> whatever version that was, it worked great
<seb128> probably -23
<Amaranth> cartman: no, a patch got reverted or something
<Keybuk> cartman: wrong path/missing symlink and not setuid
<cartman> Keybuk: ah ah ah
<Amaranth> ok then, -23 worked great for me :)
<cartman> ok no X rebooting for a few days I guess ;)
* chrissturm tries -31
<Amaranth> i don't think it worked :)
<cartman> lol
<cartman> working startx would be good enough for me ;-)
<Amaranth> cartman: -31 hit the mirrors, or something
<Amaranth> cartman: try it
<cartman> Amaranth: not for amd64 uet
<cartman> yet*
<Amaranth> ah
<Amaranth> i didn't think any of them went out until they all finished
<cartman> I am watching lamont's build logs :)
<cartman> i386 & powerpc done
<cartman> ah amd64 done too
<cartman> lets see
<Amaranth> xorg is a special case then?
<Amaranth> oh, ok
<cartman> http://people.ubuntu.com/~lamont/buildLogs/x/xorg/6.8 :)
<lamont> the binary builds are all independant of one another
<cartman> meh bad link but you figured it out
<lamont> and the log files show up ~20 minutes after the build finishes.  This may or may not be before the bits actually hit the archive, since that happens every 30 minutes
<cartman> btw is there a packages.debian.org like site for ubuntu?
<cartman> that should probably go to #ubuntu
<Nafallo> lamont: ooh, I didn't know there was a delay :-P
<Mithrandir> cartman: yes, packages.ubuntu.com
<Nafallo> cartman: guess? ;-)
<cartman> lol
<lamont> Nafallo: they're (currently) rsync'ed from where they get stored realtime, every 20 minutes
<cartman> I am overlame 
<cartman> never tried that
<lamont> (:[024] 0)
<Nafallo> lamont: good to know :-) thanx
<lamont> sometime soon, they'll be stored realtime on p.u.c.  The hint that that is happening will be the existance of hppa and sparc logs
<Amaranth> chrissturm: good?
<chrissturm> hmm, i still have the same error
<Amaranth> the xkb one?
<chrissturm> xkb error
<chrissturm> and no national characters
<cartman> chrissturm: startx works?
<Nafallo> chrissturm: yea. but does the keyboard work anyway? :-)
<Nafallo> :-/
<chrissturm> my keyboard was always working, but no national chars
<fabbione> Kamion: ok... we do have a ppc64 kernel. would you prefer me to Provides: power3/power4 or should we just play with linux-meta?
<chrissturm> cartman: i dont use startx :)
<Kamion> fabbione: nah, don't bother with provides
<cartman> meh
<fabbione> Kamion:ok
<chrissturm> carman: i can try
<cartman> [~] > startx
<cartman> /usr/X11R6/lib/X11/xinit/xserverrc: line 2: /usr/bin/X11/X: No such file or directory
<Nafallo> chrissturm: that's not working. I don't have pipe when it's broken :-P.
<cartman> chrissturm: do you have a /usr/bin/X11/X ?
<cartman> no luck with -31
<chrissturm> cartman; nope
<cartman> chrissturm: don't restart ;-)
<chrissturm> cartman: gdm is working
<cartman> weird
<chrissturm> cartman: chi% ls /etc/X11/X -l
<chrissturm> lrwxrwxrwx  1 root root 17 2005-06-01 18:25 /etc/X11/X -> /usr/bin/X11/Xorg
<chrissturm> cartman: thats what gdm is using
<cartman> same but startx doesn't work with that
<daniels> chrissturm: infinity will fix all your problems with xorg
<cartman> daniels: any idea about /usr/bin/X11/X ? where did it go? :)
<daniels> mdz: i'm going to grab the sources and check it out; there's been no access at LT and I've been too broke to go to an internet cafe ;)
<daniels> cartman: it should still be there, but it may have dropped out.  heh.
<cartman> daniels: none in -29/-30
<chrissturm> cartman: did you try to create the link manually?
<cartman> -31 still not sure as xserver-xorg didn't hit yet
<Kamion> -31 won't have changed that
<cartman> meh :(
<dilinger> daniels: is infinity the second coming of keithp or something?
<daniels> dilinger: no, he's just my bitch :)
<daniels> cartman: -30?  -31?
<daniels> sweet jesus
<lamont> daniels: THERE YOU ARE
<dilinger> daniels: heh, nice
<lamont> X is ftbfs
<cartman> daniels: -29 & -30 at least
<daniels> lamont: ... what?
<lamont> on any archictecture that does not allow non-PIC in shlibs
<lamont> libxext tries to creat such a shlib
<cartman> lamont: yup
<lamont> xorg then fails to meet build-deps
<lamont> fix that.  kthxbye
<cartman> breaks static linking on amd64 
<daniels> lamont: i don't have enough connectivity to fix it
<lamont> daniels: hppa and ia64 are both architecures that'll die because of that..
<lamont> daniels: is the fix easy?
<lamont> that is, if you want to give me a theological overview, I'll fix it tonight.
<daniels> lamont: i don't know what the fix is, bth
<daniels> er, tbh
<lamont> (build all-PIC, build twice, etc...)
<lamont> there's the -pic.a solution, or delivering a .so as well as a .a for everything
<lamont> then the .so's that depend on other libs, need to link _their_ .so against the other .so, etc.
<lamont> I'll look at it tonight and pester you with a proposal, probably
<daniels> i really haven't had any internet access here at all
<lamont> ouch
<lamont> where you at?
<daniels> and now my BIOS is so badly broken that I can't get any semblance of X
<daniels> linuxtag/european x developers' conference
<lamont> X without X, eh?
<daniels> i hacked the x86 emulator to ignore the invalid code the bios tries to call, and that just results in nothing drawing at all
<daniels> it's all black
<daniels> so I'm text-only, which is kind of limiting in terms of productivity
<lamont> oh yeah.
<daniels> bearing in mind that I can't run a sensible fb either for the same reason
<lamont> but you still get 6 vt's. :-)
<daniels> heh
<daniels> sometimes
<wasabi_> /usr/bin/screen
<daniels> my VTs are currently disappearing
<lamont> anyway, must meet someone for lunch
<daniels> i've lost 5 and 6, they just won't render text
* lamont departs
<daniels> if you email me a fixy thingy, I'll hopefully look at it tomorrow
<daniels> i'm told we'll have access at the main conference, and I just got paid today \o/
<lamont> woot.
<lamont> later
<daniels> later dude, thanks
<daniels> btw, Xext.so should be delivered fo'sho
<daniels> if it's not, something's broken
<daniels> oh, bloody hell
<daniels> 1004 new messages
<Nafallo> LOL
<Nafallo> daniels: don't upload xorg on fridays ;-)
<daniels> Nafallo: it's more that I've been offline for about a day and a half now
<daniels> and, as far as I can tell, the world has fallen down wrt X
<Nafallo> daniels: indeed :-)
<Nafallo> daniels: that's why I use my girlfriends hoary barebone ;-)
<Mithrandir> Nafallo: chicken.
<Nafallo> Mithrandir: baah. I use my lappy when I watch "tv" ;-)
<cartman> real man uses breezy on amd64 so it breaks in all ways
<cartman> :p
<KaiL_> lol
<Nafallo> cartman: that's what my laptop is ;-)
<cartman> Nafallo: lol cool
<Nafallo> cartman: amd64 just hit the archive :-)
<cartman> Nafallo: well doesn't fix my problem according to Kamion 
<Nafallo> cartman: nope :-)
<cartman> :)
<cartman> really amd64+gcc4 is teh broken setup
<cartman> backtraces are like voodo scripts
<lsuactiafner> lol
<doko> ogra: heh, daniels is away, xorg uploads for everybody? ;-)
<ogra> doko, want some ?
<cartman> lol
<ogra> ah, finally amd64 built
<Nafallo> ogra: I let you try first ;-)
<ogra> Nafallo, i'm already running my testbuild
<ogra> @| all keys there....
<Nafallo> ogra: hmm, I'll try it then :-)
<cartman> ogra: you managed to have a /usr/bin/X11/X by any chance? :)
<ogra> cartman, nope, i didnt know about that one....
<ogra> cartman, ... since i use gdm
<cartman> hmm startx refers to that
* cartman kicks kdm
<ogra> cartman, yes, i heard that...
<ogra> cartman, cant you just link ?
<cartman> ogra: X supposed to be a suid link I guess
<cartman> I can try yeah
<ogra> cartman, i would fix it, but elmo kills me if i make another upload today.... we have to collect the issues a bit
<cartman> ogra: yup true
<cartman> X is too big
<ogra> and my neves wont bear another x upload todey ;)
<cartman> :D
<cartman> ogra: you will do a -32 then?
<ogra> cartman, probably....
<cartman> ogra: ok I better wait then
<cartman> cd /usr/X11R6/lib/X11/ && sudo ln -s /etc/X11/xkb/
<cartman> fixes xkb issues
<cartman> even internet keys work :)
<ogra> cartman, which issues ? they should be fixed with -31 thats what the upload was for
<cartman> hmm
<cartman> -31 fixes xkb issues?
<tseng> thats what he said.
<cartman> well lets do a full upgrade then
* bandini checks as well
<cartman> [~] > setxkbmap tr
<cartman> Couldn't find rules file (xorg)
<cartman> thats -31
<ogra> cartman, its still not fully fixed, but should work
<cartman> symlink missing as I said
<cartman> [21:11]  <cartman> cd /usr/X11R6/lib/X11/ && sudo ln -s /etc/X11/xkb/
<ogra> i.e. you should get the keymap thats in your xorg.conf
<cartman> I see
<ogra> xorg shouldnt look in /usr/X11R6/lib/X11/ anymore....
<cartman> it does so :/
<ogra> (it probably still does, but it works over here)
<ogra> which is with gdm and gnome
<cartman> kdm starts fine btw
<ogra> with your sudoed link ?
<cartman> nope without
<cartman> my fault, I only tried startx
<ogra> ah, nice
<mdz> ogra: -31 doesn't fix things for me :-/
<mdz> [pid 24275]  open("/usr/X11R6/lib/X11/xkb/rules/xorg.lst", O_RDONLY) = -1 ENOENT (No such file or directory)
<cartman> mdz: cd /usr/X11R6/lib/X11/ && sudo ln -s /etc/X11/xkb/
<cartman> temp fix
<mdz> cartman: this is #ubuntu-devel :-)
<mdz> our job is to fix it for everyone ;-)
<cartman> ah well hmm
<cartman> true that
* cartman hides
<mdz> ogra: does the current version work for you without any local symlinks?
<mdz> it seems like we need both paths to work for now
<ogra> mdz, yes
<mdz> that's very strange
<mdz> ogra: do you have a /usr/X11R6/lib/X11/xkb ?
<ogra> mdz, it still throws the error on startup, but works
<mdz> ogra: try running setxkbmap in a terminal
<ogra> returns silently
<mdz> interesting
<mdz> ogra: can you send an strace?
<ogra> hmm, but i have a symlink there 
<ogra> /usr/X11R6/lib/X11/xkb
<mdz> ogra: ^^ "without any local symlinks" :-)
<mdz> that's not in the package
<ogra> hrmpf
<ogra> looks like i f*cked it....damned
<ogra> yes, we seem to need both links
<ogra> s/links/paths
<mdz> fixing
<ogra> oh...ok... so fabbione will kill you then, not me, nice, thanks
<ogra> what a mess
<Nafallo> hehe, cartman's startx bug then? :-)
<ogra> oh, yes
<ogra> cartman --> mdz fixes it... can you explain a sane fix for your startx prob ?
<cartman> ok
<cartman> [~] > startx
<cartman> /usr/X11R6/lib/X11/xinit/xserverrc: line 2: /usr/bin/X11/X: No such file or directory
<cartman> since -29/-30/-31
<cartman> my bet is X should be a suid root link to /usr/bin/X11/Xorg
<cartman> not sure though
<popeyeray> helo
<tseng> :(
<ogra> tseng, ?
<tseng> ^ X bugs
<Kamion> cartman: (no such thing as a suid root link - /usr/bin/X11/Xorg itself should be the thing that's suid root)
<mdz> cartman: X should point to Xwrapper
<mdz> which is the only thing which is setuid root
<mdz> the X server should not be setuid
<cartman> mdz: ok
<ogra> tseng, we are near the end ....
<mdz> Xwrapper seems to be missing from the current packages though?
<ogra> tseng, at least until daniels starts to work on it again ;)
<mdz> ah, it's /usr/X11R6/bin/X
<mdz> cartman: sudo ln -s /usr/X11R6/bin/X /usr/bin/X11/X
<mdz> let me know if that fixes it
<cartman> mdz: looks so
<syndicate> what does archive.ubuntu.com use to manage the archive?  I'm using debarchiver, but I can't get the from address to be the person that uploaded it.
<Kamion> dak
<Kamion> you should only use dak for very large archives though
<syndicate> yeah, mine's not so big :)
<Kamion> and, I mean, we have the guy that wrote it to run it ;-)
<mdz> does anyone know what the long-term plan is with regard to /usr vs. /usr/X11R6 vs. /usr/bin/X11?
<mdz> this isn't in the XRoadmap at all
<mdz> my understanding is that X11R6 is going away
<Kamion> I believe /usr/bin/X11 -> /usr/bin, dunno about /usr/X11R6
<ogra> i understood it as mdz...
<mdz> but the current packages still ship a bunch of stuff there, and explicitly turned /usr/bin/X11 into a directory rather than a symlink
* Kamion runs, being late
<Nafallo> mdz: that's my understanding to.
<mdz> in order to place symlinks in /usr/bin/X11
<Amaranth> hrm
<Amaranth> i forgot what logs to read when X is fubar
<cartman> Amaranth: buildd logs *g*
<cartman> and grepping for new X uploads :)
<karlheg> Where do I find that Xorg maintainer?
<karlheg> ;-p
<ogra> Amaranth, just wait... 
<mdke> shhhh
<karlheg> I wonder if he needs a look at the problem on my machine for a compare... it's broken, as expected.
<Amaranth> ogra: will do
<karlheg> ... Or should I just fix it by hand and assume he already knows what the problem is and that it's the same everywhere?
<ogra> Amaranth, -32 should fix all remainig keyboard issues
<Amaranth> only error i have in my logs is that the XKB keymap couldn't be found :)
<Amaranth> but my X doesn't seem to start at all
<Amaranth> well, it starts but i think all GTK things are broken, which means GDM dies
<karlheg> Is /usr/lib/X11 a symlink or real directory?
<\sh> new kde packages nice
<mdz> ok, could firefox not crash when I use the right arrow key in a text area? kthxbye
<karlheg> Mine is a symlink, and in /usr/X11R6/lib/X11, the XkeysymDB is a broken link to itself; it was made expecting to be in a read directory and pointing to where it is now.  So the real file is totally missing.
<karlheg> It cannot find font 'fixed' either, probably due to similar problems.
<sniker> hi, i've got a problem under amd64 when i try to compile the timeout 1.11-6 tarball...
<mdz> karlheg: /usr/lib/X11 is a real directory; if yours isn't then your packages likely aren't up to date
<karlheg> I wonder if I can just rm the bad links and re-install?  Or if those links are part of the system.tar ?
<Amaranth> yep, this is a gtk issue, not an X issue
<Amaranth> :/
<karlheg> IIRC, I made it be a symlink by-hand, attempting to fix Xorg last week when I made the mistake of installing Breezy X.  Downgrade to Hoary got it working, but symlink is still there...  It seems to me that it ought to be a symlink.
<karlheg> I don't get why it would be split across a real directory and symlinks the way it is.
<karlheg> *sigh*
<karlheg> At least this time I knew not to exit my session before testing it with a second login.
<ogra> karlheg, it just gets fixed.... wait a while and upgrade to the next xorg version
<karlheg> I'll fix it later; I've too many buffers on the stack atm.
<mdz> thom,chmj: is there any information I should collect about why NM runs me out of disk space via syslog?
<karlheg> Does it manage those symlinks, I wonder?  Perhaps I will need to purge and reinstall to get it into the canonical state, to where the packages expect things to really be wrt real directories and symlinks.
<mdz> karlheg: no, it oughtn't be a symlink.  if you put one there, you should reverse your changes
<mdz> the packages will not fix it for you if you changed things by hand
<karlheg> That's difficult since I had to move files... and don't have a record of what I moved.
<shaya> is there a reason the Xserver isn't being setuid root?
<shaya> keep on fixing that and it keeps on reverting back
<shaya> on upgrades
<karlheg> Why isn't it a symlink into the /usr/X11R6 tree?
<mdz> seb128: what happened with gstreamer 0.9?
<mdz> seb128: does this mean that video playback will not improve for breezy? that is very important
<mdz> karlheg: /usr/X11R6 is being phased out
<ogra> karlheg, because X11R6 will go
<mdz> especially since it isn't R6 anymore
<karlheg> totem-xine works really well, but totem-gstream lags bigtime.  I have never gotten it to work right.  It cannot thumbnail as well either.
<karlheg> ahuman01, ok.  So everything will go into the main system, rather than as a "side package" kind of thing.
<shaya> karlheg: totem-xine has issues for me, hangs on a regular basis, have to resort to mplayer many times now
<karlheg> Is that new FHS, or just an Xorg devel decision?
<karlheg> "just a"... :-)
<sniker> hi, someone can help me with the timeout 1.11-6 package for amd64, i've some errors when i compile it...
<Amaranth> karlheg: totem isn't used to thumbnail afaik
<karlheg> Maybe I'm confused.
<Amaranth> karlheg: pretty sure that always uses gstreamer
<ogra> sniker, might be the reason why there isnt a binary...
<ogra> sniker, if even our buildd couldnt build it
<Amaranth> anyone else's GTK completely dead?
<hunger> Any chance of getting a upgrade for the wireless utils in hoary?
<hunger> madwifi faq claims that the trouble I am having with that card is due to outdated wireless tools:-(
<ogra> hunger, unlikely.... any dataloss bug ? or security probs ?
<karlheg> /etc/alternatives/gnome-video-thumbnailer -> /usr/bin/totem-video-thumbnailer*
<sniker> ogra: yes, but some other disrtro like gentoo have it for amd64...
<hunger> ogra: No, plain "Dosen't work at all" bug:-(
<ogra> sniker, no MOTU jhad time for it yet... it will be ixed for the release...
<sniker> mmm... ok, so i must wait...
<ogra> sniker, breezy is a development branch, dont expect things to work...
<ogra> sniker, or start to become a MOTU ;)
<karlheg> ... work on things.
<sniker> ogra: what is a MOTU?
<cartman> Masters Of The Universe
<cartman> sniker: http://www.ubuntulinux.org/wiki/MOTU
<sniker> ok.. :-)
<hunger> Damn... hoary even has the latest stable wireless utils:-(
<karlheg> hunger, See if the newer one is in breezy.  If it won't install, get the source and build it yourself.
<karlheg> apt-get install apt-src && apt-src install wireless-utils
<karlheg> hunger, you'll have to do that in two lines; and add breezy to sources.list, apt-get update, get source, comment breezy out again, build it.  If it's not newest, you'll have to update it yourself to newest upstream if you want to use it, until it's maintainer gets to it.
<Amaranth> wow, kubuntu-desktop is installable again
<hunger> karlheg: There isent. I build my own already.
<hunger> karlheg: This damn laptop is just too new for ubuntu...
<Amaranth> ok, this must not be a GTK error, kdm dies the same way
<Amaranth> glad to have that sorted out
<Amaranth> sweet, F1 is A
<Amaranth> F2 is B, etc
<mdz> fabbione: ready to move to 2.6.12 as default soon?
<ogra> mdz, he said so, this morning
<mdz> ogra: he said soon, or now?
<ogra> soon iirc
* chrissturm still uses 2.6.10 because automount doesnt work with 2.6.12
<\sh> hmmm...
<\sh> lintian is broken
<\sh> W: njam: non-standard-dir-perm usr/share/ 0655 != 0755
<\sh> but there is no /usr/share 655 in the deb archive ;)
<ogra> mdz, [12:50]  <fabbione> sabdfl: 2.6.12 final will be on the way today or tomorrow...
<mdz> ok
<ogra> mdz, so rather now :)
<chrissturm> that just means that a package based on final 2.6.12 will be ready tomorrow, and not that it will be default from then
<ogra> chrissturm, that means that you will see it in main very soon.... and then it will be the default
<chrissturm> ah, right
<CarlK> if I promice to do some controled breezy testing with my AP's at home, can I get some help connecting hoary to an AP that is using wep?
<doko> pitti: anything you need from me to get the OOo2 build-deps into main?
<karlheg> CarlK, Ask on #ubuntu; man interfaces, man ifup, apt-get install wpasupplicant; man wpasupplicant; ls /etc/network; explore.
<CarlK> karlheg - I did, didn't get very far.. was hoping to esculate this to a dev issue ;)
<karlheg> It's not a devel issue, it's a support issue.
<karlheg> \join #ubuntu
<karlheg> (oops; wrong slash...)
<CarlK> right, but there is a devel issue somewhere here.  I just havn't gotten around to setting up WEP on my home AP to test and bugzilla it
<karlheg> CarlK, see you on #ubuntu?
<justin> CarlK: didn't I tell you before how to use wep?
<carlos> jbailey, hi, around?
<mdz> daniels: I need for ctrl+alt+Fn vt switching to get fixed; it's crippling LTSP testing
<lu|away> <blink>
* lu|away looks up
<lu|away> (1) you guys are already using LTSP?
<lu|away> (2) you're not using VNC?
<ogra> lu|away, yeps, i want to make a first edubuntu liveCD this week
<lu|away> cool
<ogra> it should run with the new ltsp packages if i get this working 
<lu|away> oh
<lu|away> _oh_
* lu|away is an idiot
<Firetech> What exactly does the ubuntu kernel packages do? In other words, what can go wrong if I install a kernel.org official kernel (2.6.12 for example)?
* Nafallo finds himself looking for </blink> :-P
* lu|away confused his acronyms
<lu|away> I have LDTP on the brain
<lu|away> anyway
<lu|away> that's cool
<lu|away> very cool
<ogra> Firetech, you miss a finegrained set of patches :)
<Firetech> ogra: but what does those patches do?
<ogra> lu|away, heh, nope, its for your mono classes...
<ogra> Firetech, the changelog can tell you
<Firetech> in the linux-pathces-ubuntu-* package?
<Firetech> *...-patches-...
<ogra> /usr/share/doc/linux-amd64-k8/changelog.Debian.gz
<ogra> is it for me
<Firetech> oh
<Firetech> it seems to be mostly security patches.
<mdz> gah, the new gaim has broken ^W
<mdz> ogra: who was lu|away?
<ogra> luis villa
<mdz> oh
<ogra> or luis_ :)
<luis_> me
<mdz> we used to have a different lu around here
<luis_> I was mostly just confused :)
<luis_> I am the man of many lu
<luis_> given that luis is registered by someone else
<seb128> luis_: opinion on pango 1.9/GNOME 2.12?
<luis_> same generic worries as other stuff
<luis_> I'll happily test a package if you want to package it :)
* luis_ is still not running from jhbuild, is a bad boy
<seb128> luis_: I've packaging it atm, but was wondering if that's rather like glib and good for the archive or like gtk and good for my webpage
<seb128> luis_: what do you fear from pango? slowness? crashers ?
<luis_> ah
<luis_> crashers, mostly
<luis_> though you might want to ask owen about the perf implications of the cairo backend?
<seb128> nop, I'll upload to my webpage and keep waiting for discussions on the GNOME lists
<seb128> I really think that 2.12 should have GTK 2.8 and we should push to this direction
<luis_> I agree, but I don't see anyone leading the pushing, I guess
<luis_> except you
<luis_> the fc guys should be pushing it to fc4 users, don't see that happening
<luis_> ditto novell/suse 9.3
<seb128> I'm not sure about gtk but I don't feel pango 1.9 beeing a real issue
<seb128> jdub: around? :)
<luis_> yeah
<luis_> pango is way less likely
<luis_> to be a problem
<luis_> though someone should test the perf
* seb128 kicks the guy was rolled 1.9.0 without the html files
#ubuntu-devel 2005-06-28
* mvo goes to bed
<ogra> motu meeting starts now in #ubuntu-meeting
<lamont> elmo: libgcc2 (hppa) needs to be promoted to main (essential package)
<tseng> how's life lamont?
<lamont> hectic, as usual
<Amaranth> yay, new X
<lamont> Amaranth: -31 or -32?
<Amaranth> -32
<chrissturm> this one has the xkb problems fixed
<Amaranth> whew
<Amaranth> maybe gdm will start in this one too :)
<lamont> tomorrow I will have a machine to burn a few cycles on breezy/hppa.  Of course, setting it up will be later in the week. :-(
<Amaranth> damnit
<Amaranth> still broken
<chrissturm> what does it say?
<Amaranth> it just dies
<Amaranth> startx works, starting gdm doesn't
<chrissturm> /etc/X11/X points to /usr/bin/X11/Xorg ?
<Amaranth> yes
<Amaranth> sudo /etc/init.d/gdm start looks like it's going to work, X starts and everything, but then it just dies with no info and drops back to a tty
<Amaranth> if i try to run anything that uses X it segfaults or has some other error
<chrissturm> i386?
<Amaranth> gnome-session, xterm, blobwars...
<Amaranth> yeah
<Amaranth> i guess i should fire up gdb
<Amaranth> gdb is nothing but 0x00000000, doesn't that mean the stack is corrupt?
<syndicate> should the version number in debian/changelog be the package revision or the <source-version>-ubuntuN?
<Amaranth> i think this RAM i got is dodgy
* Amaranth goes to memtest
<syndicate> I'm building a package for ubuntu and I thought I was doing it right, but dpkg-source -x is bitching about a .tar extension from the .dsc file
* lamont prepares to head home from the office
<Nafallo> yay! xorg works again :-)
<lamont> later all
<thom> mdz: it does /what/?
<mdz> Jun 18 23:20:04 <mdz>   Jun 18 03:10:17 localhost NetworkManager: <information>^IActivation (eth0) failure scheduled...
<mdz> Jun 18 23:20:04 <mdz>   Jun 18 03:10:17 localhost NetworkManager: <information>^IActivation (eth0) Stage 3 (IP Configure Start) complete.
<mdz> Jun 18 23:20:04 <mdz>   Jun 18 03:10:17 localhost NetworkManager: <information>^IActivation (eth0) failed.
<mdz> Jun 18 23:20:23 <mdz>   that sort of thing, repeated a few hundred times per second
<mdz> thom: ^^^
<lifeless> wooooeeee
<thom> mdz: woah.
<thom> mdz: i've never seen that before
<thom> is this on your T4x?
<mdz> thom: T42, yep
<ogra> thom, i have that too, but only in 10 second intervals
<mdz> I got a 3G syslog and 3G daemon.log from it
<thom> mdz: CRACK
<mdz> eth0 is the wired interface, too
<thom> does it have a wire in it?
<mdz> yep
<mdz> with link, and a dhcp server, and all the other amenities
<thom> that's damn strange
<mdz> ifupdown loves it
<thom> i'll see if i can replicate on my X in the morning; if not, i'll have to work out how to debug it ;-)
<thom> ogra: same symptoms, or is this still your wireless card that doesn't show up as such
<ogra> thom, nope, thats my lan card
<ogra> (unconnected
<ogra> Jun 21 01:15:40 localhost kernel: [11497.323302]  r8169: eth0: PHY reset until link up
<thom> ok, i'll look in the morning
<Kamion> mdz: ubuntu-devel rescue thread> *laugh*, snap
<mdz> you beat me
<mdz> Kamion: think we should add rescue to the live CD as well?  it's awfully tiny
<Kamion> I thought I already had, but evidently not
<Kamion> let me just check whether it pulls in scary dependencies
<Kamion> but I think we probably should, yes
<Kamion> it pulls in ext2-modules-*, jfs-modules-*, lvm2-udeb, mdadm-udeb
<Kamion> not a lot
<Kamion> mdz: added
<mdz> Kamion: thanks
<Kamion> mdz: FYI, colin.watson@canonical.com--2005/installer--dists--0 is starting to become useful, although it isn't there yet
<wasabi_> Hmm. If you have two Internet connections on windows, it chooses the fastest, somehow.
* wasabi_ writes down to figure out how to do later.
<grover> well windows knows each connection's link speed, could that be how?
<schweeb> wasabi_: routing metrics and such
<schweeb> probably tests for latency
<wasabi_> yeah. i noticed it when I plugged this laptop in, which was on wifi
<wasabi_> soon as I plugged the ethernet in, the connection switched to it.
<schweeb> oh, I'd bet they just weigh wired over wireless
<wasabi_> nope, because i got the bright idea to try 50mb wifi and 10  mbit ethernet
<wasabi_> it might be raw connection speed.
<wasabi_> like grover suggested. ;)
<wasabi_> me->home
<jdub> mdz: ping
<mdz> jdub: pong
<jdub> morning
<jdub> so, i would like to see the devel releases of cairo, gtk and pango in breezy
<jdub> there is a chance that they will not be appropriate for release, but upstream are pushing very hard for it
<tseng> jdub: hm does seb have it somewhere?
<jdub> i figure this should be one of the things we ought to be comfortable backing out closer to release
<jdub> tseng: seb has it in a repo on people
<tseng> coolness
<jdub> however, we don't have a sane way of doing so at the moment, other than fake current-version-new-version versions and forky-ugly epochs
<jdub> mdz: what do you suggest? :)
<mdz> jdub: I'm not comfortable backing out libraries closer to release
<mdz> backing things out in general is not well-supported by our packaging system
<jdub> yeah
<mdz> they can be packaged external to breezy and brought in if they're going to make it, perhaps
<mdz> and people who use that repository can clean up their own mess
<jdub> ok, that
<jdub> ok, that's what seb's doing atm
<jbailey> jdub: heyhey!
<jdub> morning
<jbailey> jdub: Feeling brave && have a spare moment?
<jdub> oh man, more X
<jdub> jbailey: yeah, maybe ;)
<jdub> not settled yet, so you may as well unsettle me ;)
<jbailey> I might have it so that you don't need to include ide-generic and ide-core in the /etc/mkinitramfs/modules anymore. =)
<jdub> woo
<jbailey> I'm just doing a quick test here, but if you could do a boot test with it, that would be lovely.
<jdub> jbailey: hey, could we have something funky like if you hold down shift at bootup, you get the initramfs prompt?
<tseng> jdub: dude, no problems in a few days since i turned off laptop-mode
<jdub> tseng: hrm
<jbailey> jdub: No, not easily.  If you're holding the key down before the driver is loaded, there won't be a key press event.
<tseng> jdub: it must make the dells go all wacky
<jdub> tseng: i'm going to re-enable it and see what happens
<jbailey> jdub: What I have right now is that if you add 'break' to the kernel command line, it drops you in.
<jdub> not that i'm ever off AC at the moment because X is b0rk
<jdub> ha ha
<jbailey> Thinking of it, I prefer that anyway so that if the bootloader is locked down, you can't break out into the initramfs.
<jdub> yeah, true
* jdub wonders if mdz's xkb changes will fix his keyboard
<jbailey> my keyboard is working right again with compose key and ability to switch terminals as of today's update.
<jdub> mdz: do the ltsp packages work on hoary?
<whiprush> jdub: fridge me!
<tseng> whiprush: BURRR
<Amaranth> this sucks
<Amaranth> bad ram, X apps seem to hit it
<Amaranth> every X app segfaults, X starts fine, cli apps are fine
<mdz> jdub: hmm, hadn't thought about it
<mdz> jdub: you'd need a breezy debootstrap script
<mdz> the client has to be breezy
<lifeless> mdz: how do I go about getting baz 1.4.2 into breezy ?
<mdz> lifeless: upload it?
<lifeless> mdz: I didn't think I was on the uploaders keyrging
<mdz> lifeless: any number of folks here should be willing to sponsor an upload, but I think we should get at least one or two of your team through the Ubuntu maintainer process
<lifeless> mdz: I presume scott is already ?
<mdz> hmm, I think so
<lifeless> mdz: presuming its on the wiki, I'll start on it myself.
<lifeless> does DD status infer automatic Ubuntu status ? (I'm guessing no)
<mdz> lifeless: not automatically, but it's a strong endorsement
<lifeless> well, I'm 9th in the queue now ;)
<lifeless> another 6 months or so and I'll either get rejected or accepted.
<mdz> lifeless: verified, Keybuk is in the maintainer keyring
<lifeless> cool, thanks
<jdub> jbailey: upping to your new initramfs-tools now :)
<robitaille> mako,  have you seen the 3 posts today on the ubuntu-users mailing list about people receiving bad Hoary's CDs?  
<mako> robitaille: no.. thanks for pointing it out to me.. 
<schweeb> mako: poke
<fabbione> morning
<mako> schweeb: hello
<schweeb> mako: did we ever figure out whether I was all good on my CoC
<mako> schweeb: i have a signed coc from you and you're marked.. i think the issue was that your key was unsigned
<mako> schweeb: that's fine for membershipo
<mako> schweeb: not good enough for maintainership
<fabbione> hey mako
<schweeb> mako: whip's key should be fine for that, shouldn't it? his is signed by yours, and mine is signed by his
<mako> schweeb: ok.. let me reimport your key and check
<mdz> jdub: a menu editor is happening upstream, right?
<Amaranth> mdz: GNOME has one, I have one, someone else has one
<brodmann> does anyone have planeshift installed?
<fabbione> daniels: ping?
<fabbione> daniels: x11proto-randr-dev: /usr/include/X11/extensions/randr.h
<fabbione> daniels: libxrandr-dev: /usr/X11R6/include/X11/extensions/Xrandr.h
<fabbione> aren't they supposed to land in the same dir?
<fabbione> (breaks qt-xfree XRandR build check)
<jdub> mdz: nothing has been proposed for inclusion with gnome itself thus far
<Amaranth> jdub: markmc didn't put up gmenu-simple-editor for inclusion?
<jdub> not thus far
<Burgundavia> mdz, who is working on wireless stuff?
<mdz> Burgundavia: http://udu.wiki.ubuntu.com/WirelessNetworkManagement
<mdz> and http://udu.wiki.ubuntu.com/NetworkMagic
<thom> morning!
<drbyte> ok, this is just embarassing. i bought a new laptop hard disk, and don't have fedora core 4 cd's lying around for x86. looks like Ubuntu Hoary wins this time !
<bob2> it was only a matter of time.
<drbyte> bob2: yes, yes, that it was
<mdz> "embarrassing"?  that's an odd way to describe it
<mdz> especialy in the Ubuntu development channel
<mdz> s/ly/lly/
<drbyte> mdz: hi mdz :)
<Burgundavia> mdz, did you have any thoughts on http://www.ubuntuforums.org/showthread.php?t=43147
* drbyte used to be known as cc... maybe now you
<drbyte> 'd remember
<Burgundavia> they are asking for a unstable version of the software
<mdz> drbyte: hehe
<mdz> Burgundavia: kernel-team@lists or #ubuntu-kernel
<mdz> but I doubt the kernel team will want to integrate pre-release versions of the driver unless there is a specific reason
<mdz> (i.e., not "it's newer")
<thom> Burgundavia: when 28 is released, they can have it; till then, suggest patience
<thom> mdz: this is libiw rather than kernel driver
<Burgundavia> thom, ok, just trying to bridge the forums<-->developers communication gap
<mdz> thom: shame on me for taking the post at face value :-P
<thom> mdz: *g*
<jdub> itym chasm thx hand
<Burgundavia> thom, do you think that will make UVF?
<thom> Burgundavia: i think for things like that unless there's a _really_ good reason then we're gonna stick with released software
<thom> Burgundavia: meh, no clue
<mdz> night all
<thom> night dude
<fabbione> night mdz
<fabbione> thom: hey.. you are up early
* fabbione fixes qt-free FTBFS
<Treenaks> \o/
<fabbione> infinity: you around?
<thom> fabbione: yes; going to go watch some more rugby on the tv in a minute :-) damned kiwis and their silly TZ
<fabbione> ehhehe
<jdub> gar gar GAR GAR GAR!
<jdub> i still can't type in X
<jdub> though it worked very momentarily at one point
<fabbione> oh CRAP
<fabbione> we need a new version of udev before i can upload 2.6.12 final
<jdub> daniels: ping
* fabbione puts away the kernel for half day
<fabbione> infinity: ping?
<jdub> mdz: in your xkb investigations, did you see anything like this:
<jdub> The XKEYBOARD keymap compiler (xkbcomp) reports:
<jdub> > Warning:          Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
<jdub> 
<jdub> expected keysym, got XF86_Switch_VT_1: line 51 of pc/pc
<jdub> expected keysym, got XF86_Switch_VT_2: line 55 of pc/pc
<jdub> 
<jdub> ?
<jdub> $ dpkg -S /usr/lib/X11/xkb/README
<jdub> dpkg: /usr/lib/X11/xkb/README not found.
<jdub> $ dpkg -S /usr/lib/X11/xkb/compat/complete
<jdub> dpkg: /usr/lib/X11/xkb/compat/complete not found.
<jdub> boh
<torkel> dpkg -S /etc/X11/xkb/README
<torkel> xlibs: /etc/X11/xkb/README
<jdub> ahr
<jdub> hrm, and the symlinks seem correct
<jdub> this is very annoying
* jdub disables xkb :-)
<Kamion> fabbione: Md seemed actively non-keen on debian-release yesterday to upload the current upstream udev
<fabbione> Kamion: we might be safe actually..
<fabbione> a lot of reports were coming from people using 0.30
<fabbione> some people were ok with 0.56 (that we have)
<fabbione> i need to dig it more
<fabbione> Kamion: i am afraid ppc won't get unionfs
<fabbione> Kamion: it's a gcc ICE with 3.3/3.4/4.0
<Keybuk> . o O { I swear I only upgraded Xorg yesterday }
<fabbione> there... libggi FTBFS fixed...
<pitti> Good morning
<fabbione> hey pitti
<seb128> hello pitti fabbione 
<fabbione> hey Seb
<pitti> Moin seb128 
<mvo> hey pitti, seb128, fabbione :)
<pitti> hi mvo
* pitti calculates the number of greetings if everybody greeted everybody else
<jsgotangco> sabdfl, hi
<HiddenWolf> pitti, try 145^2
<pitti> Moin sabdfl
<fabbione> hey sabdfl 
<pitti> HiddenWolf: no, it should be (145+146)/2
<pitti> HiddenWolf: well, ok, it's symmetric
<Treenaks> pitti: ((145+156)/2) - x (where x = people who said "hi all"
<mvo> hey sabdfl 
<doko> pitti: OOo2 build-deps?
<jdthood> pitti: ping
<jdthood> Just wondering what plans are for syncing the alsa packages with Debian.
<jdthood> Also, how do y'all feel about alsa-tools?  FYI We recently imported Mikael Magnusson's experimental alsa-tools into the pkg-alsa svn archive at alioth.  Is this something that Ubuntu users want?
<pitti> Hi jdthood 
<Lathiat> So, pmount doesn't think my usb hdd is removable, how can find out why
<pitti> jdthood: oh, is some package out of date? I did some merges recently
<trygvebw> hm
<trygvebw> anyone know what's happened to the wiki?
<pitti> Lathiat: you don't use 2.6.12 final by change?
<pitti> chance, even?
<Lathiat> pitti: yeh i do
<Treenaks> trygvebw: it was upgraded?
<pitti> Lathiat: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314985
<jdthood> pitti: We've released ALSA 1.0.9
<jsgotangco> the wiki just died
<jsgotangco> yaahhh
<trygvebw> Treenaks: to MoinMoin, yes, but it's dead now
<jsgotangco> and i was doing stuff on it
<jsgotangco> grr
<pitti> Lathiat: that's actually a libsysfs bug, I'll fix it soon
<jsgotangco> we now get an internal server error
<Lathiat> pitti: ok cool
<Lathiat> pitti: just making sure its a knownj problem
<pitti> jdthood: we synced alsa-lib, and actually I also merged alsa-driver, but it seems that there was a problem
<jsgotangco> trygvebw, wiki still dead on your side?
<jdthood> pitti: /etc/init.d/alsa changed again, but the goal is to reduce the diff with Ubuntu
<trygvebw> jsgotangco: ill check
<pitti> jdthood: I noticed that you left the lsb* stuff commented, thanks for that
<trygvebw> yep
<trygvebw> shows the moin error page
<jsgotangco> that's great i was in the middle of a huge wiki page updateon project status :(
<jdthood> pitti: It's there for your benefit and for our own if it is decided that Debian will implement the lsb functions.
<pitti> jdthood: btw, in postgresql-common's init script, I use the lsb* functions if available, otherwise I use the standard Debian method; this allows me to have the same packages for Ubuntu and Debian
<trygvebw> jsgotangco: :/
<jdthood> pitti: That's something I have considered.  However, I really hate scripts written for multiple distros.  On the other hand, Debian and Ubuntu are cousins, so....
<pitti> jdthood: really odd, I *know* I merged alsa-driver, now I can't find it in the archive...
* pitti investigates
<jdthood> Warning: the new alsa-lib triggers a bug in esd.  The bug is reportedly fixed in the latest esound upstream release; however the Debian esound maintainer is being very silent.
<pitti> jdthood: I know, that's why we kicked esd for now and use gstreamer->alsa directly
<pitti> jdthood: I worked a bit on polypaudio, maybe we'll replace esd entirely
<jdthood> pitti: Are you currently using gstreamer to combine audio streams?
<pitti> jdthood: no, that's done by dmix
<jdthood> pitti: How is dmix working for you?
<jdthood> pitti: dmix doesn't work on my system; I simply get no sound out.  Judging from the ALSA BTS I'd say that dmix isn't fully mature yet.
<pitti> jdthood: pretty fine, and I didn't hear any complaints by now
<pitti> jdthood: right, that's why I'd rather like to stabilize polypaudio
<jdthood> pitti: alsa-lib 1.0.9 engages dmix by default for certain drivers and not for others.  Are you following that?
<pitti> jdthood: yes, but since it seems to work for the majority of people, it's a huge improvement over sarge/hoary
<pitti> jdthood: for those which it doesn't work for, it is no regression (since one stream should always work)
<jdthood> pitti: For me (cs46xx), engaging dmix totally mutes all sound.
<pitti> uh
<jdthood> However, dmix isn't engaged by default for cs46xx (I infer from the fact that without a .asoundrc I do get sound).
<jdthood> pitti: Another thought.  The 1.0.9b-2 release of alsa-driver adds control files for reportbug.  Ubuntu will probably want to modify these.
<pitti> jdthood: silly me, I prepared the upload, but didn't actualyl upload it (my net was down at that moment)
<jdthood> pitti: You might want to sync with 1.0.9b-2 first then.  :)
<pitti> well, I upload this one now
<pitti> and merge the new version, yes
<jdthood> pitti: So, any comments about alsa-tools?
<pitti> I didn't take a look at it yet
<jdthood> Is there any clamour for this package?
<pitti> hm, p.d.o/alsa-tools doesn't exist???
<jdthood> jordi and I need to look the package over.  I am sorta wondering how high on our list of priorities this should be.
<jdthood> pitti: alsa-tools is in svn but we haven't released it yet.
<pitti> ah, ok
<pitti> what is it about?
<jdthood> Description: collection of tools for ALSA:   ac3dec - A free AC-3 stream decoder, as10k1 - An assembler for the EMU10K1 (EMU10K2) DSP chip, sbiload - OPL2/3 FM instrument loader for the ALSA sequencer, us428control - Controller utility for Tascam US-X2Y
<pitti> ah
<pitti> jdthood: would something like Ubuntu's "set-default-soundcard" fit in there? Ubuntu currently ships it in alsa-base
<pitti> jdthood: it is meant and used as a backend for gnome-audio-properties and possibly other UI frontends, but can be used on its own, of course
<pitti> jdthood: the tools sound nice, it is at least something we would want in universe, I guess
<doko> pitti: OOo2 build-deps?
<jdthood> pitti: alsa-tools generates 7 binary packages in all.  All of the "tools" seem to be hardware-specific.
<pitti> doko: ECONTEXT ?
<doko> universe->main
<jdthood> pitti: I don't think that there is anything in there like set-default-soundcard.
<pitti> jdthood: hm, I think it's better suited in -base
<pitti> jdthood: it's easy to do in ubuntu since we have python-minimal as required package
<Kamion> alsa-base isn't in Debian's base system so that doesn't make much difference
<pitti> doko: can you please put the necessary packages on https://www.ubuntulinux.org/wiki/UbuntuMainInclusionQueue ?
<pitti> Kamion: I know, but in Debian we would require a dependency to python (the full suite)
<Kamion> yeah, but that's already in standard
<jdthood> pitti: We'd like to have s-d-s in Debian, but for the reason you just mentioned we'd be reluctant to include it in alsa-base.  I am thinking of adding it to alsa-debian-utils, but am open to suggestions.
<jdthood> (i.e. to a new package called 'alsa-debian-utils')
<Kamion> any default Debian installation will already have it
<pitti> jdthood: I don't know whether we will have p-m in Debian eventually (would be nice for many other purposes, too)
<trygvebw> wiki is re up
<doko> pitti: they are there
<pitti> ok
<seb128> ogra: no code change for almost 2 years, doesn't seems to be a very active project no
<jordi> jdthood: also, I expect to have python-minimal soonish after the c++ transition
<jordi> doko might tell us if he has ideas about this
<ogra> seb128, sad... i think we had something like that on the goals page
<pitti> that would bre great
<ogra> seb128, and i could need a easy backup tool for edubuntu
<jordi> but hopefully in not too much time we'll be able to shit s-d-s in -base
<ogra> seb128, do you know about alternatives ?
<seb128> nop
<ogra> :/
<ogra> seb128, ta
<seb128> np
<jordi> who's going to attend the Edubuntu meeting next month?
<ogra> jordi, me
<jsgotangco> awesome
<jdthood> How small is python-minimal?
<jordi> ogra: my boss asked me if I had plans for that WE
<jdthood> Will anyone with a stipped-down installation be annoyed if alsa-base drags in python-minimal?
<ogra> jordi, so do you have plans ? want t come ?
<ogra> to even
<jordi> jdthood: 2M installed
<jordi> ogra: I'll probably be there yeah
<ogra> yay, great
<elmo> jdthood: python-minimal is (virtually, if not in reality) Essential: yes in Ubuntu
<ogra> jordi, subscribe to edubuntu-devel if you like (very low traffic)
<daniels> jdub: pong
<daniels> fabbione: not necessarily, they're two different components, but I'll be moving libxrandr-dev next week
<jordi> ogra: k
<daniels> mdz: i'll do the best I can.  think I have a good idea of where it is now, but my video BIOS is so catastrophically screwed that I can't even start X -- the BIOS tries to execute totally invalid code.
<daniels> mdz: itmt, sudo chvt 1
<fabbione> daniels: no problem. i fixed the qt-x11-free check to search for the 2 includes in different directories
<daniels> thanks
<jdthood> jordi, pitti: set-default-soundcard actually shouldn't be in alsa-base since it is a utility for setting up the .asoundrc file, which is a libasound2 thing.
<pitti> hm, right
<jordi> point
<jordi> jdthood: that might give us an excuse to move aserver to another binary package :)
<jdthood> Currently alsa-base Depends on alsa-utils which Depends on libasound2 so the point isn't very strong, but it is something we should think about.
<jdthood> libasound2, on the other hand, doesn't Depend on alsa-base.
<jordi> back later, break time
<Kamion> binaries shouldn't be in libasound2 though, unless they're versioned (ugh)
<jdthood> jordi: We could annoy the ftpmasters with another attempt to split libasound2.  :)
<pitti> "alsa-base - ALSA driver configuration files" - that doesn't seem too bad for putting set-default-soundcard into...
<jordi> jdthood: our last attempt was a different one tho :)
<jordi> -rw-r--r--  1 jordi jordi 21524 2004-12-01 18:52 libasound2-data_1.0.7-1_all.deb
<jordi> this was evil :)
<jdthood> Kamion: Right.
<jdthood> jordi: In theory we need to create libasound2-runtime for aserver and libasound2-utils for s-d-s.
<jdthood> The former being Arch: any and the latter being Arch: all.
<pitti> bah
<jdthood> snippety-snip!
<jdthood> In practice it would be better to create one new package, libasound2-utils, with aserver and s-d-s in it and Depending on python or python-minimal.
<pitti> jdthood: btw, the idea of p-minimal was to be a required package, thus you don't need to depend on it.
<jdthood> Oh
<pitti> jdthood: I merged the new alsa-driver, that was pretty easy. thanks for adopting so much :-)
<jdthood> pitti: The diff is smaller now?
<daniels> Kamion: uhm, so I think the thing to do with xterm might be for me to put up modular sources for you
<daniels> Kamion: since my video BIOS is just utterly screwed
<pitti> jdthood: yep, the mixer saving default change went away, now it's only set-default-soundcard and the LSB init script
<jdthood> Given that alsa-base already Depends indirectly on libasound2 and is Arch: all, I think it's reasonable to leave s-d-s there if python-minimal is to become required.  If python-minimal isn't to become required then I'd prefer to add libasound2-utils so that people can have alsa-base without python.
<jdthood> I guess we'll wait a while to see what happens with p-m in Debian.
<Kamion> daniels: ok, I could probably deal with that
<Kamion> daniels: is it just a "test, tweak, test, upload" matter?
<pitti> elmo: please merge exim4, php4-pgsql, libapache2-mod-auth-pgsql, prelink
<fabbione> elmo: do you happen to know how did request libgtk2-perl sync from experimental?
<elmo> fabbione: the breezy-changes archive, should tell you?
<daniels> Kamion: yeah
<elmo> pitti: josie doesn't see anything newer for php4-phsql
<elmo> doing the others
<elmo> pgsql too
<pitti> elmo: thanks; I already asked for that yesterday, maybe you already did it?
<fabbione> seb128: is there any reason why we need libgtk2-perl from experimental?
<seb128> fabbione: why not?
<seb128> fabbione: that's the version that matches the current GNOME API basically
<fabbione> seb128: because it's FTBFS :)
<fabbione> elmo: can you please sync  libglib-perl from experimental (Build-Dep for libgtk2-perl)
<elmo> pitti: AFAICT, I synced it to match Debian, 09/06
<elmo> + on your request
<pitti> ah, thanks
<elmo> fabbione: done
<\sh> hmm...anyone has a pointer to the actual frozenapps list  from aconrad? the link http://lucifer.0c3.net/~adconrad/frozenapps.txt doesn't work anymore ;)
<fabbione> elmo: thanks.
<fabbione> jamesh: ask doko.
<fabbione> ops
<fabbione> \sh
* terrex bye
<\sh> hehee
<ogra> \sh, or ask mr conrad :)
* \sh needs a list of all nicks -> real names *sigh*
<ogra> \sh, he is a bit infinitive sometimes 
<\sh> yeah;)
<infinity> \sh : Oh, crap.  I blew up lucifer's power supply today, hence the URL being nonfunctional.
<infinity> fabbione : Really late pong, see above.
<fabbione> infinity: no problem.. the auto anti dep-waiter did its job
<fabbione> infinity: but if you want to have fun, ghc6 is still FTBFS :)
<\sh> hmmm...that's why I hate xchat...konversation puts the realnames (if they are there), next to the nicks...but xchat doesn't do it by default *grmpf*
<fabbione> infinity: forcing the build-dep brings you one step forward
<fabbione> infinity: but it fails a lot later with some complains about lvalue (all arches)
<seb128> \sh: where?
<infinity> fabbione : Ahh, that can probably be fixed easily enough.
<\sh> seb128, konversation is doing a whois from time to time and if you have your realname provided in your whois information, it puts it in the channeluserlist next to the nick...
<fabbione> infinity: exactly.. but i don't know how
<seb128> \sh: right click on the nickname with xchat and go on the first line
<seb128> \sh: you have the realname here
<\sh> seb128, yeah...but this is one click too many for me :)
<infinity> fabbione : I probably do.  Can you pester me about it tomorrow (say, in 12-16 hours) after I get lucifer back up?
<fabbione> infinity: sure
<martink> \sh: or, if you are scanning the whole users list, 152 too many ;-)
* \sh is a bloody lazy bastard sometimes and information at your fingertips should be default ;)
<seb128> \sh: you want to use the real name instead of the nicknames?
<infinity> seb128 : It's handy for reverse mapping.  In this case, he couldn't remember who "Adam Conrad" was, for instance.
<infinity> (I don't blame him I always forget who that guy is too...)
<fabbione> infinity: i am trying to solve a few tons of FTBFS and merging problems atm.. i need to wait Md to upload a new upstream version of udev before i can actually think to upload 2.6.12 :(
<infinity> s/him/him,/
<daniels> infinity: dunno, but there are photos of him all over the web
<\sh> infinity, right...
<infinity> daniels : I'm trying to remedy that.
<\sh> jdub needs to adjust the feed 
<infinity> \sh : I assume you've figured it out by now. :)
<\sh> infinity, yeah ;) big yellow note: INFINITY == ADAM CONRAD => master of frozenapps ,-> 
<infinity> \sh : Is the missing text file slowing you down in any way right now?
<\sh> infinty: i wanted to clean up the cxx list today, to have a good overview whats missing and what not...(clean up the wiki page as well), but if you have some infos about the dep-waits i don't need the list at all..send it to me via query or mail or IM :)
<infinity> Oh, look. A backup of my homedir.  How handy.
<infinity> \sh : http://jerm.0c3.net/~adconrad/frozenapps.txt
<\sh> infinity, wow thx 
* infinity makes a mental note to put his ~ in revision control soon.
<infinity> I think the last few weeks have finally tipped me over the edge to joeyh's way of thinking.
<infinity> Which scares me.
<daniels> \sh: INFINITY == ADAM CONRAD => THE GUY WHO FIXES XORG WHEN DANIEL'S NOT AROUND
<infinity> daniels : Dear god, no.
<\sh> daniels, no..thats ogra ;-)
<Kamion> ~ in revision control is the One True Way and you know it
<infinity> Kamion : How long have you been doing it?
<Kamion> infinity: about three years
<infinity> Wow.  So, since daniels was, like, 12.
<Kamion> :-)
* daniels kicks infinity.
<chmj> heheh 
<ogra> heh
<daniels> infinity: don't take it out on me, just because you're decrepit
<\sh> daniels, and what about my pictures? I'm a pretty nice 34 year old guy, so best age to marry ;)
<daniels> heh
<thom> mmm, i need to finish ramming all my ~s into version control
<daniels> do any of you guys have a machine with DOS and a floppy handy?
<pitti> Kamion: you do automatic daily commits for your ~ then?
<daniels> i need to run this stupid DOS utility that wants to write an image to a disk
<pitti> daniels: I have a DOS boot disk here
<daniels> pitti: any chance I could convince you to grab an IBM utility, write the update to a disk, and then take a disk image?
<daniels> i think I'm going to have to partition my iAudio and just write the image out raw
<Kamion> pitti: hell no
<daniels> ugh
<infinity> daniels : That's what vmware is for.
<Kamion> pitti: (I just do dotfiles, ~/bin, and random other stuff as it takes my fancy)
<daniels> infinity: yeah, that's a great idea.  let me just fire up X ...
<Kamion> pitti: the importance for me is easy synchronisation across machines, so automatic daily commits would get very confusing
<pitti> Kamion: I have an automatic incremental network backup for my ~, with a conffile that skips certain directories; that works very well, so how is bazaar-~ better?
<pitti> Kamion: ah, ok
<Kamion> pitti: again, it's not backup I care about, it's synchronisation
<Kamion> and it's not bazaar because I value my sanity :-)
<pitti> Kamion: right, that's a different use case then
<Kamion> well, there's some backup as a happy side effect, but it's not really the core purpose
<Kamion> for now, svn is a better model for home directories, I think; I suppose bzr may be there one day
<pitti> Kamion: btw, I use bzr now for pmount, it works pretty well (although I still miss "push" and "merge", but I can live without that for the moment)
<pitti> daniels: what do you mean with "take disk image"?
<pitti> daniels: will that mess up my hd?
<daniels> pitti: it's OK, I got someone else to do it, but thanks :)
<infinity> pitti : dd if=/dev/fd0 of=fordaniels.bin
<daniels> right
<pitti> ah, that's easy
<pitti> daniels: I was scared by "write update to the disk", I thought you meant my hd :-)
<daniels> heh :)
<hunger> fabbione: You are working on the 2.6.12 kernel debs, aren't you?
<fabbione> hunger: yes
<hunger> fabbione: Are you patching the sources or are you using the vanilla kernel?
<fabbione> hunger: vanilla + a few patches
<hunger> fabbione: I found a patch that is supposed to give me a working TPM module (testing it right now) and was wondering whether you would consider adding that.
<hunger> fabbione: If it works that is;-)
<fabbione> hunger: file an enanchement bug on bugzilla please. Package linux
<hunger> fabbione: OK, will do. If the patch really works;-)
<elmo> how do people deal with el-lamo VCS that leave crap in the working tree?  (.svn/{arch}), grep's --exclude isn't working for me, or I'm being particularly spethial
<pitti> elmo: I have a script ~/bin/arch-debuild which tars up {arch} and similar dirs, calls debuild, and untars them again
<elmo> boggle
<pitti> elmo: yes, it's crude, but WFM
<Kamion> er ... isn't it easier to use dpkg-buildpackage's built-in support for excluding that stuff?
<Keybuk> it can only do it for the diff
<Keybuk> doesn't work for natives
<Kamion> Keybuk: not true, use -I
<Kamion> I know it works 'cos I use it all the time
<Keybuk> so doesn't ;)
<Kamion> the entire installer is native
<Kamion> and most of us upload it out of revision-controlled trees
<Keybuk> ah, to dpkg-buildpackage not dpkg-source ?
<Kamion> oh, sorry, yeah, dpkg-source, foo
<Keybuk> yeah
<Keybuk> sorry, I'll put my brain in gear :p
<Kamion> but dpkg-buildpackage passes those args through to dpkg-source
<Keybuk> it does
<pitti> ah, neat
<Keybuk> and dpkg-source to tar
<Kamion> elmo: I have a wcgrep script I borrowed from the subversion upstream repository and modified
<Kamion> elmo: http://svn.collab.net/repos/svn/trunk/contrib/client-side/wcgrep
<Keybuk> (whereas it handles -i itself, but only for the diff)
<Kamion> elmo: I made the fairly obvious modifications to deal with {arch}
<Kamion> -find $pathargs -regex ${WCGREP_IGNORE:-'.*~$\|.*/\.svn\(/\|$\)'} -prune -o \
<Kamion> +find $pathargs -regex ${WCGREP_IGNORE:-'.*~$\|.*/\(\.svn\|\{arch\}\)\(/\|$\)'} -prune -o \
* daniels reboots, crosses fingers.
<fabbione> seb128: ping?
<seb128> pong
<fabbione> seb128: any idea what package has the G_PARAM_PRIVATE definition?
<fabbione> (http://people.ubuntu.com/~lamont/buildLogs/libg/libglib-perl/1:1.091-1/)
<doko> ogra: 10975 ping
<lifeless> fabbione: its gobject isn't it ?
<fabbione> lifeless: no idea.. i am pretty sure the failure is a missing b-d
<ogra> doko, ?
<doko> ogra: b.u.c, the patch is missing from the PR, nothing is uploaded. hope you didn't clean your disk in the meantime
<lifeless> fabbione:  /usr/include/glib-2.0/gobject/gparam.h 
<fabbione> lifeless: thanks
<ogra> doko, i wanst even aware that is mine... i thought \sh grabbed my leftovers... let me have a look
<fabbione> lifeless: are you sure??
<fabbione> # grep G_PARAM_PRIVATE /usr/include/glib-2.0/gobject/gparam.h
<fabbione> root@gordian:/usr/include # 
<lifeless> grep G_PARAM /usr/include/glib-2.0/gobject/gparam.h 
<lifeless> #ifndef __G_PARAM_H__
<lifeless> #define __G_PARAM_H__
<lifeless> #define G_PARAM_SPEC(pspec)             (G_TYPE_CHECK_INSTANCE_CAST ((pspec), G_TYPE_PARAM, GParamSpec))
<lifeless> ...
<\sh> doko, no :)
<\sh> aeh
<fabbione> lifeless: there is no PRIVATE 
<\sh> ogra: no
<lifeless> oh
<lifeless> bah
<lifeless> ,,,
<ogra> \sh, ok
<lifeless>   G_PARAM_PRIVATE             = 1 << 5
<lifeless> #define G_PARAM_READWRITE       (G_PARAM_READABLE | G_PARAM_WRITABLE)
<lifeless> #define G_PARAM_MASK            (0x000000ff)
<lifeless> #define G_PARAM_USER_SHIFT      (8)
<lifeless> same file
<fabbione> lifeless: is that hoary??
<seb128> fabbione: the question is not what file should ship it, but why the current version doesn't
<lifeless> yes
<fabbione> lifeless: i need for breezy
<lifeless> fabbione: ah, I'm guessing an API change
<lifeless> fabbione: not a new package
<fabbione> seb128: or that too.. i assumed that the include was splitted or something
<seb128> fabbione: http://mail.gnome.org/archives/gtk-perl-list/2005-June/msg00052.html
<fabbione> seb128: ok thanks. can you please take a look if it has been re-added and if so upload a new glib2.0 version?
<fabbione> seb128: that stuff is needed for the libglib-perl and libgtk2-perl :)
<seb128> fabbione: I'll fix it in a few min
<fabbione> seb128: i know you rock man
<seb128> thanks :)
<fabbione> on the othersise i need it to fix FTBFS from your sync :P
<fabbione> s/sise/side
<doko> Get:1 http://archive.ubuntu.com breezy/universe freefem 3.5.7-3 (dsc) [697B] 
<doko> Get:2 http://archive.ubuntu.com breezy/universe freefem 3.5.7-3 (tar) [888kB] 
<doko> Fetched 889kB in 3s (274kB/s)
<doko> dpkg-source: error: unrecognised file suffix `.tar'
<doko> Unpack command 'dpkg-source -x freefem_3.5.7-3.dsc' failed.
<doko> E: Child process failed
<doko> Keybuk: any fix/workaround?
<Keybuk> unpack it yourself?
<fabbione> seb128: do you have any pending upload for gksu ?
<Keybuk> I have a fixed version, but no time to test it this week
<Kamion> doko: make a non-broken source package next time :)
<doko> Kamion: not my packages, so upload an .orig instead of the native tarball anyway?
<Kamion> I wouldn't invent an .orig
<Kamion> probably best wait for the dpkg fix, or get the patch off Keybuk and test it
<Keybuk> was that deliberately native, or yet another example of a non-native with a missing .orig for that upload?
<doko> Keybuk: the former
<Keybuk> why did it have a revision# then?
<doko> Keybuk: don't know, last touched in Jan 2004
<Keybuk> I'm still not convinced that should be valid
<Kamion>  doesn't sound valid to me
<Kamion> but dpkg-source needs to keep on supporting it - at best maybe refuse to build new source packages like that
<seb128> fabbione: glib fixed package uploaded
<Keybuk> yeah
<fabbione> seb128: cool
<doko> Kamion: so just wait for the fix
<seb128> fabbione: I've built libglib-perl with it here, works fine now
<Keybuk> the fix is in arch, just not uploaded
<fabbione> seb128: perfect... i will ask infinity/elmo to kick back after glibc is propagated
<fabbione> seb128: gksu is FTBFS.. do you plan an upload or can i do?
<jbailey> fabbione: Eh?
<seb128> fabbione: that's not glibc but glib :)
<fabbione> meh yeah
<fabbione> sorry
<seb128> fabbione: that's mvo's
<fabbione> seb128: ok thanks
<fabbione> mvo: ping?
<fabbione> jbailey-gcc: n0 ph34r :)
<jbailey> My spidey sences were tingling.
<jbailey> fabbione: Hmm, I wonder how to setup extra nick highlights in irssi.
<mvo> fabbione: gksu? I think there is a open merge that I'll attack today
<mvo> I can fix the FTBFS along the way
<seb128> jbailey: hey :) What is the difference between cleanbuilddir:: and clean:: ? :)
<jbailey> I'm trying the trick of running it in screen and checking it when I get tired of the talks.
* fabbione imagines jbailey compiling glibc sitting on a corner of his cieling
<mvo> haha
<fabbione> mvo: ok thanks.
<{Seb}> hey all
<{Seb}> i think i have asked this before but i've forgotten what the answer is
<{Seb}> what is the best route to get realplayer, sun-j2re, w32codecs and libdvdcss onto breezy?
<{Seb}> there are in the marillat repo
<Lathiat> the problem is legality
<{Seb}> they are in the backports hoary-extras repo
<Lathiat> w32codecs is purely illegal
<Lathiat> its codec files ripped out of stuff
<Lathiat> opped in a package
<Lathiat> libdvdcss2 is illegal is most devleoped countries
<Lathiat> as for sun-j2re and realplayer, i haveno idea
<{Seb}> right but what is the best way to install it
<Lathiat> out of hoary-extras i guess
<{Seb}> could i add the hoary-extras backports, install them and then remove it?
<ogra> {Seb}, move to a country where its legal ?
<{Seb}> is that better than marilliat
<ogra> icland comes to mind...
<fabbione> {Seb}: generally these questions should go to #ubuntu
<{Seb}> ogra: i take it you don't like me :-(
<Nafallo> sweden! :-)
<ogra> Nafallo, and norway :)
<{Seb}> fabbione: possibly true but i get flamed because i am using breezy
<Kamion> ginac changelog "Apply patch from the BTS"> to do anything in particular? :-)
<{Seb}> i got my 65 Ubuntu Hoary CDs today!
<{Seb}> only had to wait two months!
<Lathiat> mine havent even shipped and i ordered really early :(
<{Seb}> http://www.evolutioncolt.com/~spayne/gallery/view_photo.php?set_albumName=ubuntucd&id=Overview2
<{Seb}> Lathiat: so did i but they came today!
<{Seb}> Lathiat: i don't remember the warty ones taking so long, must be the popularity of ubuntu
<sivang> {Seb}: that's fast. I've waited nrealy 3 months to get mine hoary ones
<{Seb}> sivang: it could have about about 3 months. i think i order round about march/april time
<{Seb}> Lathiat: is it w32codecs or gstreamer0.8-plugins that provides MP3 support?
<Lathiat> gstreamer0.8-mad
<Lathiat> which is in universe
<Lathiat> (and included in gstreamer0.8-plugins)
<{Seb}> what does w32codecs provide then?
<Lathiat> mostly video codecs
<Lathiat> xvid, windows media, real audio
<{Seb}> right
<Nafallo> hmm, isn't this #ubuntu-questions?
<{Seb}> right, i'll stop
<{Seb}> sorry Nafallo
<Nafallo> np
<{Seb}> i thought mono 1.1.8 was in breezy
<{Seb}> according to this, mono 1.1.8 was accepted http://lists.ubuntu.com/archives/breezy-changes/2005-June/006940.html
<{Seb}> but when i got to packages.ubuntu.com or try and install mono with synaptic, it installs 1.1.7
<Firetech> {Seb}: I also got my CDs today ;) I just got 6 CDs though (5 x86, 1 AMD64)
<Nafallo> {Seb}: checked the buildlogs?
<{Seb}> Firetech: we are the lucky ones!
<Firetech> {Seb}: where do you live?
<{Seb}> UK
<Firetech> <-- Sweden
<{Seb}> Nafallo: sorry but are buildlogs and where are they?
<Lathiat> {Seb}: just cusit wasaccepted meanit didnt ftbfs
* Kamion fixes Lathiat's space bar
<thom> Lathiat: jeez your english is decaying rapidly :-)
<Nafallo> {Seb}: they are linked from packages.u.c
<Lathiat> my space bar is broken :(
<Lathiat> and my ssh is laggy ;p
<{Seb}> Nafallo: do you mean here 
<{Seb}> http://people.ubuntu.com/~lamont/buildLogs/m/mono/1.1.8-0pre3ubuntu2/
<{Seb}> there is a file called: mono_1.1.8-0pre3ubuntu2_20050618-1244-i386-failed.gz 
<Nafallo> yes
<Nafallo> _failed_
<Nafallo> :-)
<{Seb}> what does that mean?
<jordi> {Seb}: surprise, the build failed!
<thom> it means it didn't compile
<{Seb}> jordi: i somehow guessed that
<{Seb}> according to the file, it seems some file could not be found
<Simira> where's the Ubuntu logo that's supposed to be on the UbuntuArtwork wiki page?
<Simira> noone knows?
<Nafallo> Simira: lost in transition would be my guess.
<Lathiat> can i get the hoary install cd not to install the packages from the cd?
<tim__> anyone know if there are any more ubuntu offshoots in development currently (akin to kubuntu, just for different environments)
<lu|away> edubuntu
<lu|away> depending on how you count, the gnome liveCD is one
<lu|away> ditto the new mono live CD
<tseng> guadalinux
<tseng> gnoppix.
<ogra> gnoppix too
<ogra> heh
<tim__> anyone know if there are any plans for an E17-ubuntu? or where I could go to pitch that idea....its just so awesomely fast and beautiful
<tim__> I saw it mentioned it an interview w/ shuttleworth but I wasn't sure if that was just "maybe sometime" or if people were actually thinking about it seriuosly enough to work on it
<chrissturm> tim: will it be stable in the near future?
<tim__> chrissturm, its stable right now :)
<tim__> still in development...but probably the most stable environment I've ever used
<chrissturm> stable == stable release
<ogra> tim__, e17 ? stable ?
<tim__> lol, ummmm nobody knows.....my guess is 3 or 4 months
<chrissturm> tim: like 3 years ago :)
<ogra> tim__, they develop e17 since 4 (!) years
<Kamion> Lathiat: what do you mean?
<ogra> chrissturm, 3 ??
<tim__> lol yea its been a while
<tim__> but so worth the wait
<chrissturm> ogra: its going to be ready in 3 months for 3 years now :)
<Lathiat> Kamion: like, i want to boot off the cd,but install the packages froma network archive (because the end of th ecdis buggered and the install wont ifnish)
<Lathiat> and my network card wont pxe boot
<Kamion> tim__: IIRC somebody asked "could this happen" and Mark said "sure [if somebody does the work] "
<Kamion> Lathiat: does the base system install OK?
<tim__> It was something like Marc saying "theres a lot of opportunity for more offshoots of ubuntu just like kubuntu did....I believe there was even talk of an e17-ubuntu"
<chrissturm> they should release a roadmap to a stable release. that would probably motivate people to work on integrating it
<Lathiat> Kamion: buggers up installing the kernel iomage (bad cde errors)
<ogra> tim__, not at all... breaking with all common developments just to reinvent the wheel is just silly... but we will indeed include packages for e17 if someone does
<Lathiat> i know you can do it in d-i as th enetboot install does it,i just cant convince the cd booted install to do it. :)
<Kamion> Lathiat: ok, easiest way's probably to run in expert mode, and when it asks for extra installer modules tell it to install choose-mirror
<Lathiat> Kamion: ahhhhhhh :)
<Kamion> but hmm
<Lathiat> Kamion: thanks
<ogra> tim__, if someone does build these packages.... in a MOTU friendly way
<Kamion> that won't entirely work, because base-installer.postinst checks for /cdrom first
<Lathiat> is breezy going to support a netinst cd?
<Kamion> Lathiat: 'nano /var/lib/dpkg/info/base-installer.postinst' and clobber the bit that looks for /cdrom/.disk/base_installable in the manner of your choice. :-)
<jdub> ogra: hey, so, is there a place to list universe packages that are blocked from syncing due to merges?
<ogra> tim__, and you are absolutely free to make a derivate with e17 :) it is very appreciated if you do
<Kamion> Lathiat: breezy supports it, they just haven't been built - it's an "if Kamion gets time" kind of thing
<ogra> jdub, MOM and bugzilla ?
<Lathiat> Kamion: ok :)
<tim__> ogra, I wouldn't know where to start :( but it would definitely be a fun project to embark on
<Lathiat> Kamion: have fun with that getting time thing
<jdub> Kamion: is there an installer module for checking passwords with cracklib?
<ogra> tim__, in the wiki there s a very nice guide how to modify liveCDs
<jdub> ogra: for universe packages?
<chrissturm> tim: you could build e17 packages and join #ubuntu-motu
<ogra> tim__, as well in the wiki you can find wiki.ubuntu.com/MOTU 
<ogra> jdub, err... hmm... nope...
<tim__> i'll check it out
<Kamion> jdub: nope
<jdub> ogra: have a look at kismet :|
<jdub> ogra: maybe we should generate a list and check, or file bugs in malone?
<Kamion> jdub: wouldn't it just be a matter of putting the right PAM configuration in place before passwd.config runs?
<Kamion> hmm, although passwd.config might well bypass PAM
<ogra> jdub, yep, malone would be good
<tim__> hrm maybe I'll slap it on the "universe candidates" page
<jdub> Kamion: would the ui do the right thing?
<Kamion> jdub: dunno
<Kamion> jdub: wouldn't be hard to fix if it broke
<Nafallo> jdub: kismet is only over a year old from debian and ftbfs in the cxx transition. is there anything to complain about? :-)
<ogra> Nafallo, yes, we havent recompiled it yet
* Lathiat smirks
<Lathiat> "Choose a mirror of theubuntu archive"
<Lathiat> "You shouldnever see this question'."
<Lathiat> "Ubuntu version to install:"
<Lathiat> warty/hoary/grumpy/perky
<Lathiat> hmm :)
<ogra> Lathiat, what do you do there ?
<Nafallo> ogra: I tried to do that with the version in debian and it's the same builderror.
<Lathiat> ogra: well i selected hoary :)
<Kamion> Lathiat: fixed in breezy I think
<Lathiat> Kamion: :))
<Lathiat> whats perky?
<Kamion> former name for breezy+1
<Lathiat> ah ok
<Lathiat> whyd 
<Nafallo> the version after grumpy? :-)
<Lathiat> whats it now?
<Kamion> unnamed
<Lathiat> nah grumpy is something different
<Lathiat> Kamion: ah, whynotperky?
<Kamion> Lathiat: grumpy used to be what breezy is now
<Kamion> it has *since* become something different
<Nafallo> Lathiat: _now_ yes. grumpy was breezy before :-)
<tseng> he got grumpier
<Kamion> Lathiat: the name hasn't been settled yet, that's all
<Kamion> may still be perky, we'll see
<Lathiat> ah ok :)
<tseng> elmo: are you holding mono 1.1.8 in some way?
<Lathiat> sigh its still installing off the cd
<Lathiat> tseng: its build failed 
<Kamion> you could use the netboot mini.iso
<Kamion> that would probably be easier
<tseng> elmo: 1.1.8-0pre3ubuntu1 has to go to archive before ubuntu2 can build
<tseng> Lathiat: i dont think you understand
<Lathiat> tseng: ok i'll shutup then :)
<Kamion> Lathiat: http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/current/images/netboot/mini.iso
<Lathiat> thanks Kamion 
<Lathiat> i didnt know it existed
<Lathiat> hiding in the archives :)
<Kamion> netinst would be base-system-only, which is slightly different
<elmo> tseng: uh, say what?
<Kamion> I should publish the netboot image better
<elmo> tseng: you can only have one version in the archive at a time
<elmo> tseng: and the buildds will only build the latest source version
<tseng> elmo: well. ubuntu1 needed to build and go to archive for ubuntu2 to build properly, its a bootstrap
<tseng> elmo: so I need to start over?
<tseng> nothing ever entered the archive, it has new binaries
<Kamion> perhaps manual bootstrapping by a buildd maintainer would be better than trying to upload non-working stuff
<Kamion> after all that's how everything else that needs bootstrapping is done
<elmo> tseng: ubuntu1 got built and then rejected because ubuntu2 had been uploaded
<tseng> I expected it to be working in short order, I guess i misunderstood
<elmo> I'm struggling to see how you can have something that can be buildable one debian revision, and then not the next, but if that's the case, you'll need to coordainte very closely with laminity, to make sure it goes through smoothly
<elmo> s/debian/ubuntu/
<tseng> its buildable the second time, but it is depwait or so
<tseng> ill find a laminity later.
<Kamion> tseng: if you build-depend on yourself you should coordinate with the buildd maintainers
<tseng> thanks
<Kamion> always :)
<tseng> Kamion: will do
<tseng> Kamion: the debian maintainer bootstraps with a binary upload, i wasnt sure what to do
<elmo> tseng: that's such an insanely unscalable solution
<elmo> esp. for debian and it's 11 arches
<elmo> not that mono supports many of them
<Kamion> tseng: that's why you need a buildd maintainer, since they can do binary uploads (after making sure they're buildable within the archive etc.)
<tseng> no problem.
<tim__> what is involved in making a package for ubuntu out of source...is there a tutorial anywhere someone can point me to?
<pitti> tim__: http://www.nl.debian.org/doc/maint-guide/ is not bad for a start
<tim__> thx pitti 
<jdub> http://www.gnome.org/~martink/2005/stuff/Screenshot-nautilus-hierarchical.png
<jdub> HELLO!
<tseng> I DONT GET IT
<jdub> macos classic style tree view
<tseng> well, i get that
<tseng> i guess id have to use it
<tseng> to grok why everyone is excited
* Lathiat grumbles
<Lathiat> ubuntu has been 'testing' my security repository for 2 minutes now (and failing)
<Lathiat> why doesnt it fail quicker?
<Lathiat> i mean, if it hasnt connected after a minute, it really isnt going to get anywhere
<tseng> probably a high apt timeout
<chrissturm> what i would love is a popup that shows the parent hierarchy to appear when i drag something to a folder
<ogra> tim__, btw, join #ubuntu-motu ;)
<Keybuk> jdub: I want it
<martink> maybe I should upload the breezy package too...
<jdthood> pitti: http://people.ubuntulinux.org/~scott/patches/alsa-driver/alsa-driver_1.0.9b-2ubuntu1_packaging.patch: diff -pruN alsa-driver_1.0.9b-1/debian/NOTES alsa-driver_1.0.9b-2ubuntu1/debian/NOTES
<jdthood> This is a diff between 1.0.9b-1 and 1.0.9b-2ubuntu1.  Shouldn't it be a diff between 1.0.9b-2 and 1.0.9b-2ubuntu1?
<pitti> jdthood: sure, the patch is out of date since I merged based on -2, but MOM merged based on -1
<jdthood> pitti: So the patch will be back in sync later?
<pitti> jdthood: yes, should
<jdthood> k
<pitti> jdthood: http://people.ubuntu.com/~pitti/alsa-driver_1.0.9b-2ubuntu1.debdiff
<jdthood> (I'm checking to see if there's anything else I should sync.)
<pitti> jdthood: right now there is only s-d-s and the LSB init
<Lathiat> sudo vulnerability? *ouch*
<pitti> Lathiat: hehe :-) well, it's not the end of the world, but pretty serious
<Lathiat> its still ouch :)
<Lathiat> pitti: what specific situation is needed?
<Lathiat> pitti: or urlto details?
<sivang> pitti: do you have an advisory already?
<sivang> pitti: re this specific issue?
<pitti> sivang: it's fixed in warty and hoary, yes
<Lathiat> hm doenst seem to be in hoarys security archives yet
<pitti> Lathiat: it should, I released it
<Nafallo> Lathiat: I've updated my server with it :-)
<pitti> Lathiat: http://www.securityfocus.com/archive/1/402741
<Lathiat> whats the versionofthe security update?
<Lathiat> my ubuntu sec notices always land in somefolder andinever find it again :)
* Lathiat digs
<pitti> Lathiat: http://www.ubuntulinux.org/support/documentation/usn/usn-142-1
<elmo> can someone do me a favour and try torrenting?
<elmo> anything from torrent.ubuntu.com I mean
<elmo> and make sure your DNS has updated to point at .43
<Lathiat> Host torrnet.ubuntu.com not found: 3(NXDOMAIN)
<Lathiat> doh
<tseng> elmo: 143 is wrong?
<Lathiat> torrent.ubuntu.com has address 82.211.81.143
<elmo> tseng: no .143 is right
<tseng> ok
<Lathiat> pitti: hrm interesting, my hoary box doesnt see the update
<Lathiat> what does it mean when apt says 'Ign' ?
<Nafallo> Ignored
<elmo> oh, blah
<Lathiat> Nafallo: right, so why do i get ignored?
<elmo> might work better now
<Nafallo> Lathiat: dunno.
<tseng> elmo: grabbing the dvd
<tseng> elmo: found a bunch of peers and happily chugs along
<elmo> tseng: sweet, thanks
<tseng> nps
<mpt> According to PCWorld, Ubuntu 5.04 is the 26th best product of 2005
<squinn> mpt, lemme grab the issue from the downstairs bathroom
<squinn> i saw firefox as 1 and tiger as like #3
<mpt> Yeah, we've got a way to go yet :-)
<squinn> gmail and flickr made it too, mpt 
<squinn> props to you devels..i just went 20 minutes without a significant problem in breezy
<squinn> after installing xfonts-base [my fault to an extent] 
<jdthood> pitti, mdz: alsa-utils 1.0.9a-2 changelog: Reverse the order of dialog/whiptail dependency to prefer whiptail
<jdthood> Is this something we should do in Debian?
<pitti> no idea about that change...
<pitti> Hi mdz 
<elmo> it's a workaround to make germinate prefer whiptail
<elmo> Debian should have whatever you think is better for users first
<elmo> we think that's whiptail, YMMV
<mvo> hey mdz
<lamont> Kamion: what do you think of uploading the latest debootstrap (with the g++-4.0 fixes) to hoary-updates?
* Lathiat grumbles at incorrect md5sumson security
<pitti> Hi lamont
<wasabi_> Hmmm.
<lamont> Lathiat: it's a feature... should be better in a minute or so, each time it b0rks.
<wasabi_> MS's support does rock.
<lamont> morning pitti
<wasabi_> I mean, it's pricey, but it rocks.
<Lathiat> lamont: ah ok, what causes that?
<wasabi_> Is Ubuntu offering professional support yet?
<ogra> wasabi_, sure
<ogra> wasabi_, look at ubuntu.com, there is also a pricelist afaik
<wasabi_> ahh
<tseng> eh?
<tseng> oh
<wasabi_> How does one actually GET this support? email based? Phone based?
<wasabi_> Oh I see there it is.
<ogra> tseng, http://www.ubuntulinux.org/support/supportoptions/paidsupport/
<Lathiat> whats an 'incident
<Lathiat> '
<wasabi_> Ya'll should have an incident pricing for server.
<Lathiat> wasabi_: it does
<wasabi_> That's how we do it with MS. Works out pretty well. We're compitent, so we only use it when we have a really messed up problem.
<wasabi_> It says NA.
<Lathiat> oh
<Lathiat> i see
<Lathiat> but a package ;p
<Lathiat> *buy
<wasabi_> $$$ and reaccuring. ;)
<wasabi_> MS does 250 per incident, and we're fairly happy with that anyways.
<lamont> Lathiat: every 30 minutes, the Release, Release.gpg, and Packages/Sources files are updated.  If you're unfortunate enough to grab files during the middle of this transition, you get a mixed set.  And the md5sums and/or signatures are different
<lamont> re-fetching cures the problem, unless you wait 30 minutes...
<Lathiat> hrm, i try refetching about 5 times and it still doesnt go :)
<lamont> Lathiat: then either the mirror fetched at a bad point, or (if you're not hitting the mirror), then you should  squawk
<Lathiat> hoary security packages.gz still hasan md5sum error, im hitting archive.u.c
* lamont is introduced to the "goldilocks security model"
<lamont> mvo: btw, could we get apt to quit lying about bz2 files?
<mvo> lamont: lying in what way exactly?
<lamont> claiming it's downloading Packages.gz when it's actually fetching Packages.bz2
<lamont> that is, the messages to the user don't exactly match...
<mvo> oh, yes
* lamont hands mvo a penalty card
<mvo> "failure to play" 
* mvo runs
<mvo> lamont: runing "apt-get update" it tells me that it downloads "Packages" files (without a extension)
<Kamion> Lathiat: the repository testing delay's a known bug, there's been some progress towards fixing it
<Kamion> lamont: hmm, those are fixes for breezy, right?
* Lathiat screams "fucking patents"
<pitti> Lathiat: just read about it :-(
<lamont> Kamion: yeah...  fixes to /usr/lib/debootstrap/scripts/breezy{,.buildd}
<Kamion> lamont: those scripts didn't exist in hoary though
<lamont> Kamion: point.  but they should, dammit. :-)
<Kamion> I think part of the reason I'm reluctant is that once I start offering that in hoary-updates, I have to keep it updated
<Kamion> it'll be easier once I sort out debootstrap 0.3
<maswan> lamont: so, are we in the lead with sparc yet? ;)
* lamont glares at maswan
<lamont> hppa's little gcc-4.0 regression hasn't helped things either...
* lamont wonders if seb128 did his gtk+2.0 upload yet
<seb128> lamont: nop
<lamont> np.  I may just kick the tires here sometime
<mgalvin> are you guys aware that the shipped live cds and some of the install cds do not work, there is a -users thread on this but it doesn't seem to be get much attention
<mgalvin> I just wanted to make sure you guys know
<lamont> Kamion: so how can I tell ssh_config "use a proxy command for this host, but only if this other command (run locally) returns true :-)
<lamont> that is, I want to autodetect when I'm on that specific network, and not proxycommand things when I don't need to
<lamont> hrm.. prolly ECHAN
* mvo goes to play some hockey now
<Kamion> lamont: I know of no way to do that, short of dummy proxycommands
<Kamion> or an ssh alias that swaps in and out different versions of .ssh/config, or an ssh alias that provides -o ProxyCommand options as needed
<Kamion> the last is probably least evil
<lamont> yeah
<maswan> lamont: sorry? unfortunately, we don't have any fast hppas here, so we can't help in that regard.
<maswan> lamont: nor any leet gcc hackers
<lamont> maswan: np.  sparc pulled ahead a couple of days ago
<lamont> and last night i finally started releasing g++ apps on hppa
<maswan> Jun 21 16:08:37 buildd: breezy: total 731 packages to build.
<maswan> all I know is that. :)
<maswan> Hmm.. I wonder if 4500's are supported..
* Kamion -> dinner
<lamont> people.ubuntu.com/~lamont/buildLogs/Lists/breezy.all.$ARCH
<maswan> but then, this seems almost done.
<bob2> mdz: that bzr bug seems ubuntu-specific, but it's fixed in sid now anyway
<lamont> hppa's local buildd thinks it's down to just the blacklisted c++ apps, hence the need to free them.
<lamont> and then there's all the ftbfs issues...
<mdz> bob2: bzr bug?
<maswan> lamont: ah, thanks
<bob2> mdz: the one you filed yesterday
<lamont> maswan: that's the _REAL_ w-b data dump (every 20 min).  Sadly, hppa/sparc can't actually update that, so it's purely 'Needs-Build' and 'Installed
<mdz> bob2: oh, the one I filed in Debian
<bob2> mdz: er, wrong channel, right :)
<mdz> bob2: it's not Ubuntu-specific, but nobody would notice it in Debian
<bob2> or maybe right channel
<mdz> because a) the package maintainer uploads the binaries, and b) python happens to depend on python2.3
<mdz> (until Debian moves to 2.4, which I imagine will happen now that sarge is out)
<maswan> lamont: Well, building stuff is neat, anyway. :)
<jordi> ogra: so who else will be around next week?
<bob2> ah, indeed
<mdz> bob2: the maintainer dissed my bug
<ogra> jordi, Petter Reinholdtsen and Knut Yrvin from skolelinux, a handfull of people from the shuttleworthfoundation, someone from extremadura and some other spanish distro, i have the exact list not available currently
<mdz> bob2: oh, he dissed it and then fixed it
<mdz> bob2: or rather, you fixed it
<bob2> mdz: I'm the fixer, he's the disser
<mdz> bob2: indeed
<jordi> ogra: cool
<jordi> ogra: so not too many people anyway
<ogra> nope :)
<brodmann> hi
<brodmann> i'm trying to extract a .run file, but everytime it extracts to the folder, when it's finished, it deletes that tmp folder
<lsuactiafner> i need a program to take a text file and to intelligently search for expressions/strings that occur most often
<lsuactiafner> ideas?
<lamont> mdz: hppa needs to have libgcc2 seeded in main (essential package and all that) - what's the approval process for that again??
* lamont hangs his head in shame
<brodmann> i'm trying to extract a .run file, but everytime it extracts to the folder, when it's finished, it deletes that tmp folder
<tseng> lsuactiafner: grep | sort for starters
<lsuactiafner> tseng : done that already
<mdke> grep?
<mdke> try #ubuntu tho
<sanpera> can anyone tell me why the firefox package in hoary isn't built with xprint support?
<tseng> lsuactiafner: man grep
<lsuactiafner> wrote a java program also to check stuff out.. but thing is i need a PC to create the expressions itself to check for reoccurance
<lamont> lsuactiafner: still a #ubuntu question, not #ubuntu-devel
<mdz> lamont: seeded?  or just resynced with germinate?
<lsuactiafner> see, i use bannerfilter on the proxy, but the filter list is hand-made and not as effective, need to analyze a squid log to generate possible candidates thats most effective to block
<lamont> mdz: reseeded
<lamont> resynced
<lamont> gah
<mdz> :-)
<lamont> mdz: which is to say, "it's muppet magic, leave him alone"??
<mdz> doesn't show up in anastacia; did this just happen today?
<lsuactiafner> lamont: more a developers question than a ubuntu question, before i try code something in java need to know if the program exists
<lamont> mdz: ah. hrm.
<lamont> second
<mdz> lamont: I think hppa might be special
<mdz> lamont: in which case this is elmo material
<lamont> mdz: it shows up as soon as gcc-4.0>= -8ubuntu3 is in the archive.
<lamont> except that hppa uploaded that to the real archive after -9ubuntu1 source was uploaded
<lamont> and -9ubuntu2 is ftbfs on hppa
* lamont ponders.
<lamont> -8ubuntu3 is in the archive for hppa
<elmo> I don't think we germinate for hppa
<elmo> if it's main complete, we can do
<lamont> arts is ICE, so it's certainly nowhere close to main-complete.  But it should debootstrap
<lamont> well, modulo at least libgcc2
<elmo> germinating a non-main complete architecture introduces PAIN
* lamont will create time to work on the ICE then
<doko> mdz: we do not want to support the python-dbg package in main?
<elmo> if you need just the one lib, we should just promote it and wave our hands vigourously pretending it didn't happen
<mdz> doko: of course we do
<mdz> doko: that's why I seeded it and promoted it
<lamont> elmo: I'm pretty sure it's just the one lib - we could just seed it for now - it's only built on hppa, and if it's ever built on any other architecture, it'll immediately be essential
<doko> mdz: ouch ;) just looked at the wiki changes
<lamont> elmo: as an alternatively even more evil approach - there are signed hoary .changes/.debs on p.u.c that could be used to populate hoary/hppa....  Then we'd be main complete. :)
* lamont ducks hand covers
<lamont> s/h//
<lamont> (no, that wasn't a serious suggestion)
<lamont> elmo: likewise, breezy-autotest is gonna be FTBFS-city, just like hppa,and (to a lesser degree, since it has leftovers from hoary), sparc
<fabbione> lamont: well i can't efford a breezy-autotest on sparc.. even i miss only 700 pkgs to build and 750 to give-back for dep-wait
* lamont has ~800 build failures due to g{cc,++}-4.x, xorg-splitting, and dpkg-dev
<lamont> fabbione: I wasn't suggesting that you should
<fabbione> lamont: i did fix quite a bunch of FTBFS in main today
<lamont> merely, the archive is currently in _MUCH_ worse shape than it appears, since there are >500 FTBFS packages
<fabbione> hppa/sparc will suffer for mono
<elmo> Kamion: can you change the torrent trigger to trigger magellanic rather than orcadas?
<mdz> doko: in general, binary-only promotions don't need review unless they are weird or introduce new dependencies
<fabbione> lamont: but fixing universe for xorg split is going to be fast with breezy-autotest, given that bugs will be received by the MOTU's
<lamont> fabbione: sparc is less-bad-off, since anything unchanged from hoary that is now FTBFS, is still in the archive for you.
<lamont> right
<lamont> logs@buildd.u.c would also help, since the sparc/hppa logs would be a big clue that there is problems
<fabbione> lamont: there is really not much left from hoary in the archive....
<fabbione> that too :)
<mdz> fabbione: ready for .12 as default?
<fabbione> mdz: almost.. i need to upload final tomorrow
<fabbione> mdz: we will have 3 regressions with final
<fabbione> mdz: and i had to investigate one today.. that's why i didn't upload
<mdz> bugs are ok, we need testing
<mdz> especially for initramfs
<mdz> if we are going to switch for breezy, and we should, then we need to get people using initramfs very soon
<fabbione> mdz: a) ipw2100 is still borked, b) 2 scsi drivers are broken upstream (but there is a patch) c) boot will be considerably slower (udev problem)
<mdz> fabbione: ipw2100 is the thom thing?
<fabbione> #c is the main issue atm
<fabbione> mdz: yes 
<fabbione> basically we need a newer version of udev
<mdz> slower boot should not be a blocking issue for .12 as default
<fabbione> that is incompatible with older kernels
<fabbione> mdz: slow to a certain degree of taking a long while to boot :)
<mdz> fabbione: I have no such problems here
<fabbione> mdz: the change has been introduced between rc6 and final
<fabbione> mdz: you cannot have that problem unless you compiled your own kernel
<mdz> fabbione: how much slower is it?
<mdz> it would have to be like a factor of 4 in order to be a blocker
<Amaranth> do ubuntu kernels have the bad ram patch?
<fabbione> mdz: it depends from system to system
<fabbione> mdz: anyway tomorrow final will hit main
<fabbione> mdz: with an ABI change
<mdz> please increment the abi version this time
<fabbione> but i was expecting it between rc6 and final
<fabbione> mdz: yup.. it's in main
<fabbione> mdz: see the changelog for the last upload: 
<fabbione>   Changes by Fabio M. Di Nitto:
<fabbione>   * Re-enable abi check again.
<fabbione> or from the one i have in baz..
<fabbione> the latter..
<fabbione> well it was meant because of hitting main
<mdz> ok
<fabbione> mdz: for the ipw2100 problem.. i migth have a solution, but i will need a tester
<fabbione> i don't have such hardware and i can't test it
<fabbione> and changing it in the main kernel is an ABI change
<fabbione> so i would like to do it once and get over it
<mdz> abi changes are ok
<mdz> this is our development branch
<fabbione> mdz: yes, but they are very expensive for all of ys
<fabbione> us
<fabbione> anyway .. tomorrow is final day
<fabbione> :)
<fabbione> mdz: i am going to drop power3/power4 support after..
<fabbione> given that ppc64 has been tested on at least 2 machines
<maswan> no power3? :(
<maswan> oh, well. there is always AIX. mmmm.. AIX..
<fabbione> maswan: ppc64 supports power3
<maswan> ah, ok. that way around.
<mdz> fabbione: what is expensive about them?  if there is anything other than l-r-m which is expensive (and even that should be minor), we should fix it
<fabbione> maswan: speaking of kernels.. i would love to get a 3.6 kernel on test7 if possible
<maswan> wow. 3.6
<maswan> openbsd kernel then?
<maswan> or?
* maswan ducks
<fabbione> mdz: expensive is: elmo to NEW the packages, seed, l-r-m, d-i
<pitti> Ubuntu - today you can get the packages of the future
<fabbione> maswan: well.. eheh i meant 2.6
<maswan> fabbione: but sure, how about I do that together with an hostname/IP hcnage?
<fabbione> maswan: you tell me what you prefer...
<fabbione> maswan: just gimme like 20 minutes notice that i will stop the buildd
<maswan> fabbione: sure. how about now?
<maswan> do we have a naming convention?
<fabbione> maswan: hmm sure.. let me ssh
<maswan> for ubuntu/buildds or something?
<Amaranth> would it be possible to get the badram patch in ubuntu kernels? http://rick.vanrein.org/linux/badram/download.html
<fabbione> maswan: use the name you want.. it's not an official ubuntu buildd
<Amaranth> the latest they have is 2.6.11 though
<fabbione> sparc != official
<maswan> samn. then we have to come up with something on our own. :)
<maswan> s/s/d/
<Seveas> is Hibernate supposed to be stable?
<maswan> ok. your choice: bubbles, blossom, or buttercup?
<fabbione> maswan: call it wathever you prefer :)
<fabbione> maswan: sparc.is.a.bitch.fabbione.net ? :P
<maswan> bubbles then. :)
<Amaranth> buttercup!
<Amaranth> :D
<maswan> ah, ok. :)
<fabbione> maswan: almost done :)
<maswan> fabbione: buttercup.acc.umu.se has address 130.239.18.171
<maswan> let me know when you are ready
<fabbione> maswan: ok. works for me :)
<fabbione> maswan: i am still stopping the buildd (cleaning the chroot now)
<maswan> fabbione: kernel-image-2.6.8-2-sparc64-smp acceptable?
<fabbione> maswan: yes.
<fabbione> it needs to be anything > 2.6.4
* maswan nods
<maswan> well, that's the one in sarge, so.. :)
<fabbione> that's the same i am using on my buildd :)
<ogra> hmm, sad, gnome-backup is still crap...
<fabbione> modulo -smp
<maswan> fabbione: just give me a nick hilight when you're done and I'll install, fiddle with hostnames/hosts and reboot.
<fabbione> maswan: you are green to go
<fabbione> my adsl just died for 10 seconds while i was logging out
<maswan> fabbione: Ok.
<fabbione> 21 076:13:29:16 ATM        Info       WAN 0 physical layer is down
<fabbione> bah
<mdz> doko: I haven't seen a new oo.o2 with new build-deps; are you talking about something you have locally?
<maswan> fabbione: it is up now
<fabbione> maswan: cool..
<fabbione> maswan: perfect.. i am in.. outgoing emails work too
* fabbione restarts the buildd
<mdz> tseng: how goes the mono->main review?  is there anything else that is ready to move?
<terrex> are there ubuntu kernels 2.6.12 debianized? and where?
<maswan> fabbione: great
<fabbione> terrex: breezy.. but i suggest you wait tomorrow
<pitti> terrex: we have rc6 in universe so far
<fabbione> maswan: we are overtaking hppa big times :)
<fabbione> pitti: main but yes.. rc6
<maswan> fabbione: yeah, I saw. poor gcc sufferers. :)
<tseng> mdz: i could probably do a review of a few more things and push monodevelop + deps over
<fabbione> maswan: actually we still have a big issue for main
<fabbione> maswan: that's the kernel not linking properly due to the new toolchain, and worst is that i don't have a fix yet
<tseng> mdz: im getting less ambitious about moving all the major apps for breezy
<tseng> mdz: as specified
<mdz> tseng: so far, I don't think we have any apps :-)
<tseng> mdz: we didnt move tomboy?
<tseng> right now im thinking of tomboy, beagle, f-spot in main.. as things we dont have from some other app
<ogra> tseng, monodevelop 
<ogra> ?
<tseng> yes.
<fabbione> yay!
<mdz> tseng: yes, but I don't think all of its deps are satisfied
<fabbione> xorg -32 finally built :)
<tseng> mdz: i can move.. evolution-sharp
<tseng> mdz: gmime needs love
<tseng> let me mail myself to review beagle deps + monodevelop tonight
<tseng> mdz: one other question while you are on the subject. mono 1.2 and friends are targetted for Sept. release
<fabbione> maswan: everything is working perfectly... thanks a lot
<tseng> mdz: is it the TB that can approve tracking this past UVF?
<fabbione> maswan: i guess i am off to have some dinner with my wife 
<maswan> fabbione: enjoy!
<fabbione> maswan: thanks a lot!
<fabbione> maswan: where do you live in .se?
<fabbione> maswan: perhaps we could meet somewhere in there for a beer.. given that i am 20 km from .se :)
<maswan> fabbione: Ume
<fabbione> maswan: how far is that from cph?
<fabbione> (Malmo)
<mdz> tseng: currently, release decisions aren't really handled by TB; I'd probably decide that
<maswan> fabbione: hmm.. lets see, stockholm is 600 km away, then malm is another 600km or so, I think
<maswan> fabbione: two 1-hour flights, typically
<fabbione> maswan: argh...
<mdz> tseng: september is quite late, though.  the preview release is out in september.
<maswan> fabbione: yeah, .se stretches away quite a bit up north
<fabbione> maswan: yeah i know :)
<tseng> mdz: hm right
<mdz> it's extremely unlikely that we would allow something like mono 1.2 close to preview, and definitely not after preview
<fabbione> have been to Goteborg and stockholm 
<tseng> mdz: we might get in a beta
<tseng> mdz: we are tracking 1.1.x until freez
<mdz> tseng: 1.1.x are development releases?
<fabbione> oh well
<tseng> yes, but 1.0 is effectively EOL
<fabbione> cya later guys
<mdz> doko: is zopeinterface appropriate for main?
<mdz> fabbione: good evening
<Amaranth> 1.1.x isn't 1.2 yet because of MWF
<Amaranth> at least that's the impression i get
<tseng> Amaranth: well mono winforms is a key feature
<Amaranth> yeah
<fabbione> mdz: thanks! (please don't upload x for the next hour ;))
<Amaranth> but i mean the rest of it is basically stable
<fabbione> mdz: it's building the debs right now :)
<tseng> Amaranth: yeah im pretty happy with what we have atm
<\sh> i'm stucked
<elmo> hey, someone with mad sed skills
<elmo> sed -ne '/LALA SOME SEPARATOR HERE LALA/,$p'
<elmo> what's the inverse of that?
<elmo> i.e stop printting stuff when you se e it
<elmo> ah, nm, got it
<elmo> (add -e '/FOO/q')
<mdz> elmo: if you want LALA..FOO, you can do /LAA/,/FOO/; if you want from the beginning to foo, then yeah, no -n and use /q
<elmo> ah, duh, I see
<\sh> ok...
<ogra> elmo, could you sync ffmpeg please
<\sh> hmm...looks like there is my solution for gnuradio in the CVS
<elmo> ogra: changes ok to override?
<\sh> so backporting from cvs
<ogra> elmo, yeps, i'll merge them if necessary
<elmo> ogra: um.. if you're asking for a sync, you're meant to know if a merge is necessary or not?
<elmo> sync if changes are no longer needed, merge if they are
<ogra> elmo, its a new upstream version...
<elmo> not sync+merge
<elmo> ogra: doesn't matter
<ogra> elmo, ok, i'm sure... changelog says * Sync with debian, no source change other than epoch to override others... as the only ubuntu entry
<mdz> er, an epoch is significant
<ogra> oh, damned, i have to reuse it, right ?
<mdz> why doesn't it show up in MOM?
* ogra looks
<mdz> where is Keybuk, destroyer of worlds?
<elmo> because the epoch makes it look newer than debian
<elmo> so josie/lorraine don't see it as a merge candidate --> neither does MOM
<daniels> mdz: busy breaking dpkg
<mdz> ah
<ogra> elmo, i'll pull the debian package myself and add the epoch then, thanks :)
<elmo> ogra: so in fact, there's no way I can sync it
<daniels> mdz: you got my mail about xorg?  it looks like some bits simply fell out
<ogra> elmo, understood, sorry for the noise
<daniels> mdz: it was probably most of the xlibs-data symlinks; the XKeysymDB and XErrorDB ones should now be in libx11-6 at any rate, as it now ships that stuff
<daniels> mdz: xkb-related symlinks should remain in xlibs-data, for the time being
<mdz> daniels: I got your [VAC]  mail, that's all
<mdz> daniels: was there another one?
<mdz> daniels: did you get my email about /usr/bin/X11?
<daniels> mdz: yeah, and I replied to you about that
<mdz> didn't arrive
<mdz> daniels: the only email I have received from you since 17 Jun is [VAC] 
<daniels> mdz: cock
<daniels> mdz: my laptop isn't on the network now (and non-trivial to do so), so the executive summary is this
<daniels> apps move from /usr/X11R6/bin to /usr/bin as they move into the modular tree
<daniels> /usr/bin/X11 should be a symlinkt o /usr/bin as soon as nothing installs into it and the migration is complete, etc, etc
<daniels> but until that happens, it's kind of hard to rely on /usr/bin/X11/foo, for any specific value of foo
<mdz> daniels: /usr/bin/X11 used to be a symlink to /usr/X11R6/bin, right?
<mdz> but now it's a directory, and it contains symlinks to programs in /usr/X11R6/bin
<mdz> which makes no sense to me
<daniels> you're right, that makes no sense at all
<daniels> if it's mine, it must have been some particularly bad crack
<daniels> if not, I disclaim all responsibility
<mdz>   * Make xserver-xorg Pre-Depend on x-common, since it ships a symlink in
<mdz>     /usr/bin/X11 now.
<mdz>  -- Daniel Stone <daniel.stone@ubuntu.com>  Wed, 25 May 2005 09:37:15 +1000
<daniels> mdz: oh, right
<mdz>   * Add /usr/bin/X11/Xorg -> /usr/X11R6/bin/Xorg symlink in xserver-xorg.
<mdz> etc.
<daniels> mdz: that was because that particular case was unfixable
<mdz> Xorg and xauth are there
<mdz> xauth has been fixed in ssh, I believe
<daniels> mdz: due to kind of a lack of forward planning in October\
<daniels> so yeah, Xorg can't budge, really
<daniels> there's no sensible way to change the server configuration automatically\
<daniels> but, er, yeah, long-term it's a symlink
<daniels> anyway, gotta break out for dinner now
<daniels> in the meantime, if you guys need help on anything specific from me, I should generally be able to get back within 12h now
<daniels> but obviously not during the weekend when I'm on the plane etc
<mdz> daniels: are you SMS-able?
<daniels> yes\
<daniels> gone now for dinner
<mdz> ok, bye
<ogra> :(
<\sh> from one *censored* software to another
<Burgundavia> why sad?
<ogra> because ffmpeg only compiles with gcc-3.4
<ogra> and i have to prepare a new package....
<Burgundavia> ah
<pitti> l
<\sh> ogra, checked the cvs of ffmpeg?
<seb128> sam is probably going to update that for Debian soon
<ogra> \sh, i dont want to overtake debian wtr versioning
<seb128> if you don't want to bother just wait
<ogra> it works fine if compiled with gcc-3.4 and i have to add this damned epoch anyway, you cant autosync it....
<seb128> what epoch? where?
<\sh> ogra, same here with gnuradio-core-2.5 ... the fixes are in cvs..and this i'm trying to compile
<ogra> seb128, in our ffmpeg package
<seb128> why?
<seb128> don't put an epoch ubuntu specific
<ogra> seb128, lamont added it in hoary, no idea why
<ogra> seb128, so i have to live with it *shrug*
<\sh> hello mr. HSI customer ;)
<ogra> hehe
<lamont-away> ogra: I don't add epochs
<lamont> upstream (whereever we sync'ed it from)may have added one??
<ogra> ffmpeg (3:0.cvs20050121-1ubuntu1) hoary; urgency=low
<ogra>   * Sync with debian, no source change other than epoch to override others...
<ogra>  -- LaMont Jones <lamont@ubuntu.com>  Fri,  4 Feb 2005 18:04:28 -0700
<lamont> hrm..
<ogra> ffmpeg (0.cvs20050121-1) unstable; urgency=low
<lamont> nfc
<ogra> was the version before
<lamont> then there's a 2:something in warty, or somewhere during hoary deve.l
<seb128> we probably sync a ffmpeg 2: from marillat's archive
<ogra> huh ? we sync from marillat ??
<lamont> seb128: almost certainly the source of the issue
<lamont> ogra: we did
<seb128> we got mplayer from here
<ogra> ouch
<seb128> and some other stuff
<lamont> Depends: doesn't allow architecture, does it...
<ogra> anyway, i have no prob to touch the package twice in one release process and have it done for now to make the user happy... since we have no choice with this package anyway
<\sh> ogra, take the chance and make it gcc-4 ready
<ogra> \sh, i dont want to fiddle with this package... and i dont want to get ahead of debian....
<ogra> \sh, so i will care about 4.0 if debian has a new version .... else we will at least have a workng package
<\sh> ogra, get it ready and push the patches towards debian
<\sh> for etch they have to do it anyway
<ogra> \sh, fine for them, i'm no ffmpeg programmer and not interested in becoming one.... so i'll grab what i can get i just want to close this bug now...
<ogra> \sh, and fixing it wont be trivial....
<\sh> ogra, which version of ffmpeg?
<\sh> 0.4.9?
<ogra> cvs20050313
<\sh> i could help you :)
<\sh> i have a surprise for you :)
<\sh> jesus...gnuradio build ;) with g++4
<\sh> ogra, dcc is working for u?
<ogra> dcc ? not very often :)
<ogra> try it
<\sh> kannst annehmen?
<\sh> oder doch lieber mail?
<ogra> hab scho
<\sh> hihi
<\sh> shit...english german
<ogra> \sh, from where ? i dug through the debian bts.....
<ogra> redhat ??
<\sh> tschentoo
<ogra> ah
<ogra> heh
<\sh> need more?
<ogra> ergh.... the package compiles fine with 3.4 on amd64 and ppc... but not on i386, thats silly... let me try your patch
<\sh> there is a a52, libdir and missing links patch as well
<\sh> and a sed magic line
<\sh> or i send u the whole ffmpeg gentoo dir
<ogra> \sh, let me see if it compiles with 4.0 now...
<\sh> well...i don't think so
<ogra> \sh, i dont want to do this all again in 2 weeks...
<\sh> or?
<\sh> ffmpeg-0.4.9_pre1-r1.ebuild:            epatch ${FILESDIR}/0.4.8-gcc3.4-magicF2W.patch
<ogra> thats why i wanted to go with the package as it is
<\sh> don't tell them ;)
<ogra> whom ?
<\sh> gentoo ;) 
<\sh> please check the following in your source: libavcodec/liba52/resample_mmx.c
<\sh> if you find this line: static uint64_t __attribute__((used)) __attribute__((aligned(8))) magicF2W= 0x43c0000043c00000LL;
<\sh> or if you have this line: static uint64_t __attribute__((aligned(8))) magicF2W= 0x43c0000043c00000LL;
<ogra> \sh, i have to do all of this again if the debian package gets updated
<\sh> the latter is old one, and has to be patched (more code like these)
<\sh> well, normally, if this is as patch in gentoo, then upstream is informed and should patch their source
<ogra> \sh, i hope the next debian version will have all patches
<ogra> \sh, but if not, i have to do all this again....
<\sh> what should I do now with my nicely build gnuradio-core...it's even a replacement for old gnuradio-0.9 which isn't maintained anymore...
<\sh> and it's completly debian incompatible because newer then everything but g++-4 ready
<ogra> \sh, make it a NEW package and take over maintenance ?
<\sh> forget it
<\sh> we have gnuradio 0.9
<\sh> debian has gnuradio-core 2.5
<\sh> 0.9 is not maintained anymore, gnuradio-core-2.5 is not building with g++-4 and with g++3.4 only with a lot of patches :( and latest CVS HEAD is smooth 
<\sh> anyways I can't try it .. i don't have the hardware for it
<mdz> tseng: if we're not going forward with beagle, we should remove it from the seeds (it's creating a lot of clutter in the anastacia output)
<tseng> mdz: its on my list for tonight (main reports for beagle)
<mdz> tseng: oh, ok.  from your earlier message I thought we were going to back off on our goals
<tseng> mdz: not for beagle
<mdz> ok
<tseng> mdz: i meant muine/blam more specifically
<ogra> yes, blam looks bad
<tseng> muine causes users confusion, and blam is just bad
<ogra> tseng, user confusion ?
<ogra> why that ?
<tseng> yes, it does "intelligent" album discovery, and ignores partial albums
<ogra> whoops
<tseng> this doesnt work for people with inconsistant stolen music collections
<ogra> yep, i can imagine
<tseng> and they get confused/frustrated
<\sh> tseng, well..amarok behaviour
<jlj> why is blam bad?
<tseng> jlj: it doesnt work on amd64, for starters
<tseng> jlj: but i could make a long list.
<ogra> jlj, because the author doesnt manage to stabilze it
<Burgundavia> the beagle backend for it sucks
<Burgundavia> it brings my machine to a halt after about 2 days
<tseng> Burgundavia: are you filing bugs please
<Burgundavia> there is already a bug for the blam issue
<tseng> the beagle blam issue, or the blam blam issue :P
<Burgundavia> the beagle blam issue
<tseng> great
<Burgundavia> the bug "Blam is total crack" doesn't exist yet
<mdz> ogra: have you talked with Kamion about setting up Edubuntu CD builds?
<tseng> i meant more "blam craps on amd64"
<ogra> mdz, i wanted to start with a iso customization....
<ogra> mdz, until i got everything running
<thom> i want blam blam bugs
<melodie> hello everybody :)
<thom> they sound much more exciting than usual bugs
<mdz> ogra: hmm, ok
<mdz> ogra: make sure you maintain seeds, though
<ogra> mdz, i think we should wait with the real builds until after the summit... since we will decide the software collection there
<Burgundavia> thom, is that where you get to shoot the reporter if they are being stupid?
<tseng> Burgundavia: damn, file me some of those
<\sh> well, updating the build-deps to python2.4 thrills...even the python packages from gnuradio are building nicely now..
<lamont> thom: stick to pebbles bugs. :-P
<lamont> or would those be plebbles bugs?
<melodie> do someone know if therer's any project around improving doc for ATAPI drives configuration ? 
<ogra>  ATAPI drives configuration ? 
<melodie> ogra: yes
<ogra> setting jumpers ?
<melodie> no, mostly all
<ogra> or wiring it right ? what do you configure on a ATAPI drive ?
<melodie> ogra: the dma, but also diverse files maybe
<melodie> ogra: the /usr/share/doc/ATAPI... comes from Debian and not adapted
<melodie> I could not find much more on the wiki
<melodie> that's why this question
<ogra> melodie, for dma look at hdparm.... for most of the other possible adustmants too...
<ogra> adjustments
<melodie> I looked for hdparm, in my case no change, no need of that
<chrissturm> why is it that with pango 1.9 firefox doesnt render fonts, and epiphany still works?
<melodie> and all the forums contain no answers about solutions for I/O errors
<ogra> melodie, file a bug ?
<melodie> not even the archives of the ml
<melodie> or I go to the link for the wishes to ask improvment :)
<ogra> whick link ?
* lamont wanders off to get some downtime in
<melodie> there's a link somewhere on the site, for writing suggestions and wishes :)
<\sh> what about atapi and i/o errors.
<\sh> ?
<melodie> \sh: I can't grave datas anymore and could hardly before
<melodie> I tested datas and audio
<ogra> heh, ffmpes has a --with/without-gpl compile switch that moifys the code accordingly ... funny
<melodie> could encode with one
<ogra> ffmpeg even
<melodie> could copy disk to disk with graveman
<melodie> could burn an archive, but is corrupted
<melodie> so couldn't transfer on the laptop
<\sh> melodie, you're really sure, that your hardware is ok? but anyways...I think we're OT here...can we switch to #ubuntu ?
<melodie> and found the save I/O errors on the laptop 
<melodie> I just wanted to know if a new doc project was on... :)
<melodie> I could have brought the precise results from divers tests
<melodie> thanks anyhow :)
<mdke> thesaltydog, hiya
<thesaltydog> ciao
<\sh> melodie, well...if there is no doc project, start one :) 
<ogra> yeah :)
<ogra> melodie, or even better, talk to the docteam, i see mdke is around
<mdke> i'm here!
<melodie> \I agree :)
<mdke> i don't have a lot of good news tho
<melodie> can't lead a project, not enough knowledge
<ogra> melodie, but you can join one ;)
<melodie> hello mdke, you're the doc leader ?
<mdke> melodie, nope
<mdke> melodie, #ubuntu-doc
<melodie> ok ;)
<melodie> thanks
<mdke> :)
<melodie> good evening
<melodie> bye till next :)
<\sh> ogra, i wrote to the deb maintainer of this package...
<ogra> \sh, which one ? ffmpeg ?
<\sh> gnuradio
<ogra> \sh, ah
<ogra> \sh, great :)
<\sh> ogra, just because the changes are really nice...g++-4, python2.4 everything
<ogra> oh yes, he should definately have it for etch :)
<\sh> ogra, question is, should I upload it as replacement for the unmainted0.9
<ogra> \sh, if the changes are necessary for us, sure...
<\sh> ogra, question  between us: do you know somebody here or somewhere who uses ubuntu + some piece of hardware to provide a radiostation?
<ogra> a radiostation ?
<Burgundavia> where I am most likely to find ross burtoni?
<\sh> ogra, what do u think, gnuradio is ;)
<ogra> \sh, you mean a stream....
<ogra> \sh, i'm a bit slow today
<\sh> http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html
<\sh> http://www.gnu.org/software/gnuradio/images/usrp1-small.jpg
<lu|away> Burgundavia: #gnome-hackers, irc.gnome.org, 'ross'
<Burgundavia> ok
<Kamion> elmo: trigger change done
<Burgundavia> tseng, have you seen beagle spawn dozens of mono processes?
* kafeine sleeps
<tseng> Burgundavia: no
<Burgundavia> tseng, must be that blam issue
#ubuntu-devel 2005-06-29
<ogra> eeek
<ogra> the gksudo patches were reverted
<doko> mdz: zopeinterface is ok for main
<mdz> doko: thanks
<ogra> phew, ffmpeg will require some assembler love....
<seb128> hum, we should probably sync splashy from Debian experimental
<ogra> seb128, i thought splshy was discarded in its current form ?
<seb128> why?
<ogra> some framebuffer probs in the implementation iirc
<seb128> I don't say we should use it as default, but having it for universe doesn't hurt imho
<ogra> thats true :)
<seb128> hum, and gnome-alsamixer
<lifeless> daniels: around ?
* terrex taotrodiita
<jdub> mjg59: http://linux.dell.com/blog/2005/06/21/#1639
<jdub> thom: http://linux.dell.com/blog/2005/06/21/#1639
<lamont> Converting ./caution.png
<lamont> /bin/sh: ./caution.png: Permission denied
<lamont> sigh
<mako> jdub: dude
<mako> jdub: something wicked is going on with ubuntu-users
<mako> jdub: i'm getting MANY bounces 
<mako> something like someone tried to subscribe bloglines.. i dunno
<jsgotangco> mako
<jsgotangco> dud
<jsgotangco> dude
<mako> jsgotangco: yessir
<mako> jsgotangco: whats' up
<jsgotangco> mako, nvm we got it figured out, it was because the last docteam was using your p.u.c shell to host the preview pages of docs
<jsgotangco> mako, we'll just put it in our svn since it has https access
<jsgotangco> mako, although we're still not sure if its the best way to go
<Amaranth> wtf
<Amaranth> i don't know how windows does it but it automatically makes bad spots in ram unusable
<Amaranth> i'm supposed to have 512MB, windows says i have 501MB because some is bad
<HrdwrBoB> it does?
<HrdwrBoB> I know you can do it in linux
<HrdwrBoB> I wasn't aware that windows had that functionality
<HrdwrBoB> you're sure you don't have an integrated video which steams ram?
<Amaranth> linux can't do that, can it?
<Amaranth> i thought you had to tell it what parts were bad
<HrdwrBoB> you do, but you tell it by scanning memory
<HrdwrBoB> it's not much of a stretch to integrate it more
<Amaranth> if your kernel has the badram patch
<HrdwrBoB> yeah
<Amaranth> it takes 40 minutes to scan my RAM, windows seemingly does it instantly
<Amaranth> do ubuntu kernels have the badram patch?
<HrdwrBoB> not afaik
<bob2> are you sure windows is ignoring 11MB because it's bad?
<HrdwrBoB> generally I throw out ram that's bad
<Amaranth> bob2: only reason i can think of, it generally reads it all for me
<HrdwrBoB> but as I said before, are you sure it isn't an integrated graphics controller or something?
<Amaranth> and the computer works, so it's doing something
<Amaranth> i have a radeon
<Amaranth> so no
<Amaranth> with a different set of 512MB ram in this machine windows read it as 512MB
<Amaranth> i wish i could get some new ram but it's $$$ and i'm a student
<Amaranth> so i had to switch to windows unless i wanted a CLI with messed up text
<cartel_> candidate ubuntu logo: http://fun.sdinet.de/pics/3ubuntu.jpg
<jdub> mako: yeah, looking at it atm
<jdub> mako: i've already removed most of the bouncing addresses, but there's obviously a whole stack in the queue
<wasabi> i love it.
<cartel_> i want a tshirt
<dilinger> i want one of the models
<bob2> that's so last week
<cartel_> heh
<cartel_> bob2 haha
* netjoined: irc.freenode.net -> orwell.freenode.net
<jnc> cartel_: ...  O_O
<lifeless> daniels: ping
<fabbione> morning
* netjoined: irc.freenode.net -> orwell.freenode.net
<doko> morning all
<fabbione> hey doko
<fabbione> doko: you are a perl expert, aren't you?
<doko> fabbione: not really, that's the reason I'm learning python now
<fabbione> doko: ehehe 
<fabbione> mind to take a look at http://people.ubuntu.com/~lamont/buildLogs/libg/libgtk2-perl/1:1.090-1/ ?
<fabbione> perhaps you have a clue on why it is FTBFS
<fabbione> a test failure and that's clear
<fabbione> but why...
<doko> I'm putting it on the list. somebody wants me to extract preprocessed sources from the kernel source first
<fabbione> thanks
<stuNNed> howdy ho, what's the command to apt-get dist-upgrade and have no config protect i.e. write all new config files pulled from the new version?
<fabbione> mdz: ping?
<Lathiat> stuNNed: -y --force-yes maybe (not sure)
<stuNNed> Lathiat: tseng had the trick, i'll check with him later thanks
<mdz> fabbione: pong
<pitti> Morning
<fabbione> hey pitti
* netjoined: irc.freenode.net -> orwell.freenode.net
<\sh> infinity: pingeling
<sivang> morning all
<pitti> Hi sivang 
<doko> seb128: did cairo break the API between 0.5.0 and 0.5.1 again?
<Kamion> stuNNed: -o DPkg::options::=--force-confnew
<Kamion> stuNNed: but I'd strongly advise using dpkg --force-confnew by hand on individual packages rather than doing that for a whole apt run
<seb128> elmo: drivel sync please
<doko> seb128: was there a gdk_cairo_create symbol in libcairo in the past?
<seb128> doko: read the NEWS, all the new/deprecated functions are listed
<seb128> and 0.5.1 does break the 0.5.0 API/ABI 
<seb128> I've not replied to your mail yet
<seb128> doko: anyway gdk_... seems to be a gtk namescheme
<doko> seb128: this symbol is undefined in lib-gnu-java-awt-peer-gtk.so.6, but this is linked against libcairo 0.5. trying to find out, where I can find the reference. it's not in the libgcj source
<seb128> doko: /usr/include/gtk-2.0/gdk/gdkcairo.h:cairo_t *gdk_cairo_create (GdkDrawable *drawable);
<seb128> doko: that's a new gtk symbol
<seb128> (and I'm not going to upload this gtk to debian unstable)
<seb128> (or to ubuntu)
<Burgundavia> seb128, would you mind looking at a really odd bug
<Burgundavia> https://bugzilla.ubuntu.com/show_bug.cgi?id=12084
<Kamion> daniels: any word on that xterm source?
<seb128> Burgundavia: that's not weird, that's a known bug
<Burgundavia> seb128, ok, shouldn't have bugged you
<seb128> np
<Burgundavia> on another note, did you see my stuff on users&groups?(I will file the new bugs upstream tomorrow)
<seb128> yep I've read my mails yesterday
<seb128> and I'm quite bug flooded for some time, these are upstream and low priority
<seb128> I'll reply today though
<daniels> Kamion: no, sorry, but apparently we have working wireless now, so I'm going to fire up my laptop and check
<daniels> been setting up these two machines all morning, and running around setting up machines for HP (their stand is using Ubuntu on some machines, and we owe them because they lent us two machiens), etc
<daniels> right now I'm IRCing from one of the display amchines.  i'm trying not to do this much. ;)
<Kamion> heh
<daniels> right, bbiab, will try to get wireless on my laptop.
<lifeless> daniels: are you interested in a multi-device patch for xorg ?
<lifeless> ttps://bugs.freedesktop.org/show_bug.cgi?id=3594
<lifeless> courtesy a ubuntu user in #twisted
<thom> lifeless is inventing new protocols again
<lifeless> hom: sure am.
<\sh> argl...jabberd2 s03 is heavily broken when it comes to more then 100 conns
<\sh> updating it
<daniels> hoorah!  i'm now IRCing from something that isn't a 19" LCD
<daniels> a little less obvious
<thom> heh
<daniels> lifeless: um, that's NOTOURBUG
<daniels> lifeless: the nv driver is crap and doesn't do dual head at all
<daniels> not with a Xinerama-like setup, not with a MergedFB-like setup
<lifeless> daniels: ah. but this might help fix it ?
<lifeless> daniels: what should I tell the guy that gave me the patch.
<lifeless> me / you
<daniels> lifeless: tell him that he needs to use the nvidia driver or buy hardware from a vendor who makes better drivers
<mdke> hi all. a friend of mine has told me that he got assigned a bug, although he has nothing to do with the development of Ubuntu ;) does anyone know how this can have happened? its bug 12077
<Kamion> if you type just part of a name, bugzilla auto-completes
<Kamion> somebody probably forgot to check
<mdke> hmm i see
<mdke> that bug is quite oddly reported
<Kamion> I'll reassign it somewhere
<seb128> seems that the submitter has assigned it
<mdke> yeah ok that is what I figured
<Kamion> seb128: you want it? :P
<mdke> my friend has never heard of the submitter, so I guess he just typed in part of a name or something
<seb128> Kamion: pick "reassign to owner/QA" for the component, that will probably go to me anyway :p
* mdke nods
<Kamion> (critical? my arse)
<mdke> thanks guys
<mdke> beautiful detail given in that bug
<Kamion> seb128: yup ;)
<Keybuk> guys ... please don't file bugs on dpkg using the Ubuntu bugzilla, the chances of me seeing them is practically zero.  File them on the Debian BTS.
<\sh> pitti: ping
<pitti> Hi \sh
<\sh> pitti: i'm trying to compile jabberd2...it needs postgresql-dev and is searching for libpq-fe.h 
<\sh> pitti: apt-file says it's in postgresql-dev (or new libpq-dev) but it doesn't find it...
<pitti> \sh: http://lists.ubuntu.com/archives/ubuntu-devel/2005-June/008021.html
<pitti> \sh: libpq-dev is the correct package
<pitti> libpq-dev |    8.0.3-6 | http://archive.ubuntu.com breezy/main Packages
<\sh> pitti: hmmm
<\sh> yes...it doesn't find it
<pitti> \sh: you have to convert it to the new architecture
<pitti> \sh: what do you mean with "find it"?
<pitti> the package is in the archive
<\sh> libpq-fe.h is not found by configure, looking into /usr/include/postgresql and /usr/local/...
<\sh> the package itself is not the problem ;)
<pitti> \sh: ah, you have to use pg_config --includedir
<pitti> \sh: it's now in /usr/include/postgresql/8.0, but you should not hardcode that
<pitti> \sh: <pitti> \sh: http://lists.ubuntu.com/archives/ubuntu-devel/2005-June/008021.html
<\sh> ah thx :)(
<seb128> pitti: gst-plugins0.8 Debian package now builds a musepack package, that requires libmpcdec3 which is universe ... what is the procedure for such case? Should I ping you/somebody to review it for main, or just assume that's fine and upload? :)
<pitti> seb128: it should be reviewed
<pitti> seb128: for packaging, security history, QA, and in particular patents
<pitti> seb128: is that something mp3'ish?
<seb128> musepack is a format
<seb128> which is not mp
<seb128> mp3
<seb128> apt-cache show libmpcdec3
<pitti> seb128: do you know the patent situation?
<seb128> no
<pitti> seb128: please add it to http://wiki.ubuntu.com/UbuntuMainInclusionQueue
<seb128> k
<seb128> thanks pitti 
<pitti> seb128: btw, I still experience polypaudio crashes
<seb128> :(
<pitti> seb128: I'm packaging a new esd now, if that works fine with thew new alsa again, we should keep it for now
<seb128> who put gtkhtml3.0 for main?
<pitti> seb128: I'll try to fix polypaudio, but we should have sth stable ready
<seb128> we have 3.6 and 3.8 ... there is no way to use these?
<seb128> pitti: k
<pitti> seb128: oh right, -> tseng ?
<pitti> bah, the esd package is a mess...
<seb128> pitti: like a lot of changes directly to the .diff.gz? 
<pitti> yes
<pitti> and of course most of them fail to apply to the new orig.tar.gz
<seb128> was the same with gdm ...
* pitti dives into diff.gz...
<seb128> some maitainers really deserve some kicking
<thom> all the ones who use c d b s, for a start ;-)
<pitti> *cough*
* seb128 kicks thom 
* Kamion blocks
<pitti> oh, does thom use cdbs? :-)
<seb128> cdbs is great :)
<pitti> -> 
<pitti> #ubuntu-religiouswars, please
<thom> *giggle
<thom> *
<seb128> thom: can you fix firefox to work with pango/cairo?
<thom> seb128: it doesn't?
<\sh> how can I see from where we did sync a package for hoary or breezy?
<pitti> \sh: "where"?
<pitti> when?
<seb128> thom: no, it assumes than gtk use pangoxft, which is not true with cairo 
<\sh> pitti: yes...jabberd2 is only available from debian experimental ;)
<Kamion> \sh: Origin: line in the mail to *-changes
<thom> seb128: oh lordy
<thom> seb128: k, i'll look
<\sh> Kamion: thx
<seb128> thom: workaround is to edit /usr/bin and to comment the PANGO export :)
<thom> seb128: where are gtk+cairo packages?
<seb128> thom: "deb http://people.ubuntu.com/~seb128/gtk ./" for i386
<daniels> Kamion: who uses xterm, anyway?
<seb128> deb-src at the same place for !i386 :p
<Kamion> daniels: oh, only gnome-session :P
<seb128> thom: that's new pango/gtk
<thom> seb128: cool, k
<daniels> Kamion: wtf?
<thom> seb128: oh; can you add nm-applet to the default session, please? :-) (I assume you can add stuff that won't necessarily be installed yet without difficulty)
<{Seb}> i've gotting a problem with brezzy (as usual)
<quitte> did someone successfully build glibc with gcc-4 already? I tried with the debian version and couldn't get it working even with a lot of patches and with glibc from cvs. but later i found out that the problem might have been the binutils beeing too old. so now im wondering if i should give it another try.
<{Seb}> i keep getting this error while going a dist-upgrade:
<seb128> thom: k
<thom> merci bien
<{Seb}> the error is http://pastebin.com/302434
<seb128> thom: de rien :)
<{Seb}> any way around this?
<seb128> #
<seb128> dpkg: error processing /var/cache/apt/archives/xlibs-data_6.8.2-32_all.deb (--unpack):
<seb128> #
<seb128>  trying to overwrite `/usr/X11R6/lib/X11/xkb', which is also in package libx11-6
<seb128> is your issue
<{Seb}> yep
<daniels> ... why is that in libx11-6?
<{Seb}> seb128: any ideas?
<{Seb}> seb128: i've clered the cache and tried several times
<Kamion> daniels: gnome-session falls over with a viciously ugly error when you don't have xterm installed
<Kamion> says "chooseSessionListWidget"
<Treenaks> Kamion: it says that even with xterm installed for me
<schweeb> Kamion: I've seen tat as well
<Kamion> daniels: at least I assume it's gnome-session, it's something in that arena at least
<schweeb> actually, I think it's to do with GDM's sessions
<daniels> Kamion: what the frig
<{Seb}> has anyone else experienced this problem?
<daniels> Kamion: i think xterm is used in the fallback session
<daniels> so you've already lost if you've fallen back
<schweeb> cause once I selected GNOME as default
<schweeb> it worked fine
<daniels> gnome can fail viciously when it doesn't find apps it wants to
<Kamion> daniels: as schweeb says
<schweeb> but when I actually used "Default Session"
<schweeb> it didn't work
<seb128> Kamion: isn't that #11942 ?
<schweeb> Kamion: so, try using a different session... GNOME preferably
<Treenaks> schweeb: exactly. also, ctrl+alt+f1 doesn't work anymore
<Kamion> seb128: yes
<schweeb> well, that's a vty issue
<daniels> Treenaks: yeah, that's my bug
<seb128> Kamion: iz gdm bug
<{Seb}> has no one else got this error - am i doing something wrong?
<ogra> Treenaks, that was fixed by mdz with -32
<Kamion> schweeb: this isn't an "I want my personal system to work" thing, this is an "I want fresh installs from CD images I'm producing to work" thing :P
<seb128> {Seb}: try #ubuntu
<{Seb}> but this is breezy?
<schweeb> Kamion: haha, sure
<seb128> and?
<seb128> {Seb}: this is not an user chan nor a bug tracker
<Kamion> {Seb}: it's an X bug. the X maintainer already answered:
<Kamion> 12:12 < daniels> ... why is that in libx11-6?
<schweeb> Kamion: but I want my personal system to work :p
<Kamion> {Seb}: please don't repeat "has anyone else seen this?" over and over again
<schweeb> technically, it works fine though, after I choose a session other than "Default"
<quitte> gcc-4 is the default in breezy?
<{Seb}> Kamion: any idea when the bug will be fixed then?
<Kamion> {Seb}: no.
* schweeb takes off for work
<schweeb> later guys
<daniels> {Seb}: i'm on holiday this week, so no idea
<{Seb}> right
<{Seb}> oh well, back to SUSE ;-)
<quitte> do i at least have a voice here?
<daniels> i think there have been like five xorg uploads, one libx11 upload and one libxext upload since I last had the most recent sources of anything on my laptop
<Kamion> quitte: gcc-4.0 is the default, but not necessarily used for all packages (some override it due to compiler bugs)
<schweeb> daniels: yea, mdz's been pretty busy with your xorg :p
<quitte> ok thanks. that's great. you dont know if glibc already used gcc-4?
<daniels> schweeb: i did notice all the xorg uploads, and now all the bugs for stuff that I didn't change that was allegedly fixed by the same person who filed them :P no idea hwat's going on
<schweeb> hahaha
<Kamion> quitte: not offhand, no
<schweeb> daniels: welcome to my life, I never know what's going on at work anymore
<schweeb> if I don't fix it myself, who knows when the hell it'll get fixed (if at all)
* schweeb leaves for real
<thom> seb128: pango from your repo doesn't build-depend on cairo
<seb128> arg
<seb128> thanks
<seb128> jdub: around?
<seb128> {Seb}: force the package install, that's not a big deal
<\sh> ah...now it runs stable
<Duck_Happy> pitti: YES, CDBS IS GREAT !
<pitti> \sh: tamed postgresql?
<\sh> pitti: yeah...jabberd2_2.0s08 runs now ;)
<\sh> but I'm really not sure, what JOSS JabberD server is...it's plain jabber.org jabberd2 server 
<sivang> Duck_Happy: it's sure is :-)
<\sh> and it's not from debian...the experimental package is completly different from that package we have inside
<Duck_Happy> sivang: :-)
<seb128> hey Duck_Happy 
<Duck_Happy> coin seb128 
<seb128> sivang: I've dropped the packages you listed a second time on LaunchpadIntegration (you put 3 GtkUIManager packages already listed)
<seb128> Duck_Happy: why are you happy? :)
<sivang> seb128: ah ok, sorry
<sivang> seb128: which were them?
<Duck_Happy> seb128: because i think i found the ONE
<seb128> sivang: looks on the wiki diff, not sure
<Duck_Happy> so every Duck_<state> is overriden
<sivang> seb128: btw, what about gaim? did I list it under the right catagory??
<pitti> seb128: esd 0.2.26 plays well with alsa again
<seb128> sivang: dunno
<seb128> sivang: but you listed bug-buddy ... is there a bug-buddy menu?
<pitti> seb128: so in the next gstreamer upload, could you please switch back the default sink to esd?
<seb128> pitti: sure
<pitti> seb128: that will work with both esd and polypaudio, direct dmix still breaks for too many people
<sivang> seb128: no there is not. Thanks for correcting me
<seb128> pitti: k
<seb128> pitti: so I should change my alsasink back to esdsink?
<pitti> seb128: as you with
<pitti> seb128: if alsa works fine for you, there is not really a reason to
<seb128> s/with/wish?
<pitti> seb128: erm, yes
<seb128> :)
<pitti> seb128: esd ist just a safer default
<seb128> but we keep dmix?
<pitti> sure
<seb128> hum, I though it doesn't work well with esound
<seb128> esound and dmix I mean
<pitti> seb128: not with 0.2.35 :-)
<seb128> oh, that's fixed?
<pitti> seb128: I upload 0.2.36 shortly
<seb128> rock
<seb128> nice job pitti :)
<pitti> yep, new esd works well
<pitti> \sh: please send the jabberd postgresql patch to Debian
<\sh> pitti: i can't 
<pitti> \sh: Debian has started the transition, too, and if possible we should sync from them
<pitti> why not?
<\sh> pitti: the jabberd2 version which we're using is not the same debian is using...debian has jabberd2 in experimental...and we got it from somewhere else
<\sh> and I don't know from where...
<pitti> ah, ok
<pitti> nevermind, then
<\sh> JOSS Jabberd2 rewrite *whatever it is*
<\sh> is oures
<\sh> ours even
<tseng> pitti: hi!
<tseng> pitti: what can I help you with
<pitti> tseng: http://wiki.ubuntu.com/UbuntuMainInclusionQueue has gtkhtml3.0 for gtk-sharp
<pitti> tseng: any chance that gtk# can do with 3.6 or 3.8 which are already in main?
<tseng> pitti: hm can you double check that, i rebuilt it with 3.6
<pitti> tseng: thanks for the other reports
<tseng> pitti: a few weeks ago
<pitti> that would be cool
<tseng>   Depends: libgtkhtml3.6-18
<tseng> from apt-cache depends libgnome-cil
<tseng> same for libgnome2.0-cil
<tseng> it should be a non-issue now, yes?
<tseng> pitti: should have some more reports tonight.
<pitti> tseng: thanks, then we can remove it from the queue
<tseng> pitti: great, no problem
<pitti> tseng: I review your reports shortly
<pitti> s/shortly/soon/
<tseng> elmo: can you please sync f-spot 0.0.13-3 from unstable, ok to overwrite
<tseng> pitti: thanks
<mako> jdub: must have been something weird, last night i was getting like 10:1 ubuntu-users bounces to everything else.. almost all from bloglines
* fabbione kills power3* power4* kernels
<abelli> s/kills/builds again
<fabbione> no
<fabbione> there is powerpc64-smp for them
<fabbione> power3 and power4 in 32bit are not supported by upstream anymore
<fabbione> so you go 64Bit
<abelli> fabbione: even userspace?
<fabbione> userspace is still 32bit
<fabbione> there is no need of 64bit userland
<abelli> come no?
<abelli> .. ooppss .
<fabbione> no
<fabbione> there is no need to
<fabbione> like sparc
<fabbione> 64 bit kernel -> 32 bit userland
<fabbione> it works perfectly
<jdong> hey, is Breezy gonna have SELinux? I thought it was gonna be Breezy+1, but the WikiPage shows excellent progress already....
<abelli> so if i find a 32 bti kernel .. it should work?
<fabbione> abelli: yes, but i don't see the point in running a 32bit kernel when 64bit run better
<tseng> jdong: do you have time to document what you alluded to the other day about rsyncing the livecd fs to zero removed bits?
<tseng> jdong: it would be very helpful to several people.
<abelli> fabbione: ive got a 32bit cpu running sarge atm.
<Kamion> jdong: stuff like installer support hasn't been specced and I don't have time to do it, so ...
<fabbione> abelli: if it's a power3/power4 cpu than you can run 64bit
<jdong> tseng: it's just dd'ing a 2GB file of zeros, making an ext2fs on it, loop-mounting, and copying over all files to it :)
<tseng> jdong: im sorry, i dont have a really strong grasp on the entire process to just instantly pick up on what you are saying
<tseng> jdong: is there any chance you could put that note in the appropriate place on the LiveCDCustomizationHowot
<tseng> howto*
<abelli> fabbione: sun sparc 5?
<fabbione> abelli: i am talking about powerpc
<fabbione> power3/power4 = powerpc
<jdong> tseng: ok
<tseng> jdong: thanks muchly :)
<abelli> fabbione: ... 
<abelli> yes .. i was .. 
<abelli> i was .. sorry .
<fabbione> so what has that to do with sun sparc?
* fabbione doesn't get it
<abelli> you said your sparc port as 32 bit userland ..
<abelli> so i said "if i get a 32 bit kernel, would it work?"
<pitti> tseng: did you check upstream bug trackers for these packages?
<fabbione> abelli. hoary probably yes.. not breezy
<fabbione> abelli: but all sparc userlands are 32 bit
<Kamion> elmo: I need to get a bunch of Priority fields changed to make debootstrap 0.3 work well with breezy. What's the format you'd prefer to get those changes in?
<tseng> pitti: yes, there are alot of open bugs around
<pitti> tseng: a friend of mine just asks me why breagle is not available for amd64
<tseng> pitti: but nothing major.
<pitti> tseng: any reason for that?
<abelli> fabbione: its my first sparc .. i didnt know that.
<pitti> tseng: thanks; the bug situation should be mentioned in the reports
<tseng> pitti: hm ogra, dholbach, Nafallo all used it
<Kamion>     beagle | 0.0.11.1-0ubuntu1 | breezy/universe | source, amd64, i386, powerpc
<thom> pitti: i'm running beagle on amd64
<abelli> moreover .. it was already installed when i received it .. and i havent even powered it up since then.
<fabbione> abelli: ok :)
<pitti> ok, thanks
<ogra> pitti, doesnt work to well, but runs :)
<tseng> pitti: he will need to install libmono-dev as a work around until 1.1.8.1 packaging is finished. they handled versioning of a .so poorly
<abelli> fabbione: should i make it installing hoary?
<fabbione> abelli: it won't work. installer in hoary is broken
<abelli> any tricks?
<abelli> ...trick
<abelli> .
<fabbione> abelli: hmmm yes
<fabbione> no actually..
<fabbione> no
<abelli> :D
<abelli> :(
<fabbione> you need to debootstrap it manually
<fabbione> chroot and install the 32 bit kernel
<abelli> ahh ok .. linux from scratch.
<fabbione> no
<fabbione> apt-get install debootstrap
<abelli> si :)
* fabbione goes back to give light to 2.6.12 final
<abelli> fabbione: grazie mille, ciao
<fabbione> ciao
<Kamion> elmo: also, would it be possible to enforce that everything in germinate's 'minimal' output (with maybe a few exceptions for kernels and bootloaders and such) has priority >= important, and everything not in that output has priority <= standard?
<jordi> pitti: what's that? did ubuntu get the new upstream version of esound?
<jordi> pitti: hrm, we really need to get neuro to upload that.
<pitti> jordi: yes, just uploaded it
<jordi> pitti: so it fixes the distorted sound so many people were noticing in the bug reports'
<jordi> I'll mail the debian bugs to see if they can test your packages.
<pitti> jordi: I already did that
* jordi relaxes. :)
<jordi> thanks dude :)
<Kamion> elmo: (I've got code to do something along those lines in cdimage)
<jdong> tseng: in the wiki. Also added lots of swap to requirements, along with the cheap swapfile method of making more swap
<jdub> mako: yeah, same here - over 3000
<jdub> mako: i killed the subs, purged the bounce queue, etc.
<tseng> jdong: rock on! thanks alot
<pitti> tseng: do you want monodoc-http in main as well? this is a bit more interesting since it opens a port and such
<tseng> pitti: i dont
<pitti> ok
<jdub> tseng: is there a Good way to get f-spot going on hoary?
<tseng> pitti: but it looks like it would require splitting up packages
<tseng> jdub: hm yes
<pitti> tseng: why?
<pitti> tseng: it's already a separate deb
<jdub> tseng: works with mono 1.0 and old gtk-sharp?
<tseng> pitti: monodoc is the source?
<tseng> jdub: it does
<tseng> jdub: it should be in hoary sanely
<pitti> tseng: yes; but having the source in main does not meant that we must import *all* debs into main
<jdub> ah, tops, thanks :)
<tseng> pitti: ah dude, lets do it like that
<tseng> pitti: it will save us all alot of trouble
<tseng> so we can put monodoc-manual and monodoc-browser into main?
<tseng> and demote monodoc-http
<jdub> tseng: going to see if pia likes it :-)
<pitti> tseng: I updated https://wiki.ubuntu.com/UbuntuMainInclusionQueue and brought your reports into shape (and acked the first three)
<pitti> tseng: thanks for preparing them
<tseng> pitti: thanks for reviewing them
<pitti> tseng: erm, monodevelop is not built on amd64
<KaiL> ah, icons for krita and kugar came up from nowhere...:)
<pitti> tseng: (although your report claims that)
<seb128> jdub: ping (again) :)
<tseng> pitti: hm it should be arch all
<tseng> pitti: i will fix
<pitti> tseng: no, there are shared libs
<tseng> pitti: are you sure?
<tseng> pitti: can you show me one
<pitti> I updated the report at https://wiki.ubuntu.com/MainInclusionReportMonodevelop
<pitti> -rw-r--r-- root/root    166296 2004-10-27 17:59:52 ./usr/lib/monodevelop/bin/libgdldock.so.0.0.0
<tseng> ls: /usr/lib/monodevelop/bin/*.so: No such file or directory
<tseng> could this be a leftover from another install?
<pitti> tseng: that shuold be split off into a separare arch: any package, and the bulk should be in a -common package
<tseng> i have no so
<tseng> from monodevelop.
<pitti> tseng: I looked at the debs in /srv/archive.ubuntu.com/ubuntu/pool/universe/m/monodevelop/monodevelop_0.5.1-3_powerpc.deb
<tseng> pitti: ah
<tseng> pitti: breezy has 0.7, it is all "managed" code
<tseng> can you please review that one
<pitti> tseng: 0.7 is not in the archive
<pitti> uh, wait
<pitti> monodevelop | 0.7-1ubuntu1 | http://archive.ubuntu.com breezy/main Packages
<pitti> hey, who did that?
<tseng> hm that is wrong
<tseng> we didnt move all the deps
<pitti> indeed /srv/archive.ubuntu.com/ubuntu/pool/main/m/monodevelop/monodevelop_0.7-1ubuntu1_all.deb
<tseng> much better.
* pitti updates report *sigh*
<tseng> thats odd
<tseng> thanks alot pitti 
<tseng> pitti: do i need to do anything to get monodoc properly seeded?
<tseng> pitti: so we dont pull monodoc-http to main
<tseng> ok i mentioned it on the wiki
<pitti> monodoc-http | 1.0.6-1ubuntu2 | http://archive.ubuntu.com breezy/main Packages
<pitti> aaaarrgh
<tseng> who is doing this?
<thom> interesting that firefox is broken but ephy isn't
<pitti> tseng: it's in the suported seed :-(
<tseng> pitti: we can fix this, right?
<pitti> sure
<tseng> or just demote -http
<tseng> we'll see when mdz is up.
<seb128> thom: that's the difference between a real browser and a piece of crap :)
<pitti> tseng: I'll talk to mdz
<tseng> pitti: thanks
<tseng> pitti: i am going to lurk again if there are no more troubles?
<pitti> lurk where?
<tseng> i watch here all day, but i have some more work to do :P
<pitti> ah, ok :-)
<thom> seb128: grin
<carlos> fabbione, hi, around?
<fabbione> carlos: yes
<carlos> fabbione, I'm not sure, but the problem I have with 2.6.12 could be related to driver change for my raid controller
<carlos> fabbione, the megaraid driver has been updated 
<carlos> fabbione, and when I boot in verbose mode, the driver is not loaded
<carlos> fabbione, does the list of drivers depends on mkinitrd or the kernel itself?
<fabbione> carlos: interesting...
<fabbione> carlos: it depends on what the drivers tell to depmod -a
<fabbione> carlos: i will check again the bug, but can you add a lspci -n to it please?
<carlos> fabbione, I 2.6.10 initrd works without problems with that version of mkinitrd
<fabbione> carlos: eight now i am extremely busy
<carlos> fabbione, ok
<fabbione> carlos: ok.. i know what to look for now
<fabbione> add me that info and i will fix it not for this release but for the next one
<fabbione> i need to upload .12 final today
<carlos> ok
<carlos> fabbione, thanks
<fabbione> carlos: no problem
<carlos> fabbione, I just want test that driver version just in case fixes the other problem I reported
<fabbione> carlos: tomorrow i will be able to drive you trough a manual test to see if the problem is what i thinkg
<fabbione> right now i don't have enough time sorry
<carlos> ok
<carlos> fabbione, don't worry
<fabbione> i really need to release :)
<carlos> I'm doing my own investigation at the same time, but my knowledge is limited :-)
<fabbione> carlos: if you can send me your initrd image for .12 i will look at it and get it ready for when you will be awake
<carlos> fabbione, it's linked in the bug report, will add you to the CC of that report
<fabbione> carlos: basically the megaraid has been splitted up and i need to see why the correct driver hadn't been included in the initrd
<fabbione> carlos: i think i am already as kernel-team
<fabbione> or just gimme the bug number
<carlos> fabbione, I added the bug report against mkinitrd as you asked me instead of the kernel
<fabbione> it's faeter
<fabbione> ok
<carlos> https://bugzilla.ubuntu.com/show_bug.cgi?id=12040
<fabbione> carlos: ok.. i will look at it tomorrow
<carlos> lspci added.
<carlos> fabbione, ok, thanks
<shawarma> Hi! Can someone check something for me? On a Hoary system, try doing apt-get source samba and then try building that package?
<shawarma> On my system, first some patches fail to apply cleanly
<shawarma> And if I'm not much mistaken it fails to build, too.
<shawarma> I'll know in a few minutes.
<\sh> shawarma: pbuilder?
<thom> fails to apply in my chroot, eayh
<shawarma> \sh: As in: "Did you try in pbuilder?" ?
<fabbione> carlos: sorry.. can you be so kind to add lspci -n <-
<carlos> sure
<fabbione> carlos: it makes it a few eons easier to grab in the kernel code :)
<fabbione> thanks a lot dude
<\sh> shawarma: yes
<carlos> done
<fabbione> uhuh
<fabbione> yes
<shawarma> \sh: No, I haven't, but the system I'm trying it on is a clean install.
<\sh> shawarma: well...danielN did the same...and in a clean pbuilder enviroment it worked...suddenly ;)
<shawarma> \sh: Garh.... So if I'm patching the source, every time I want to test, I need pbuilder?
<\sh> shawarma: well...yes :) it's not a pain, if you have helpers ;) 
<shawarma> \sh: That's partly true. It'd be easier if it just built outside pbuilder.
<shawarma> \sh: Well, what do you know... If I build it as root on the clean box, it failed. With fakeroot, it seems to work. It's done yet, but I think it got farther than before.
<jdub> seb128: pong!
<seb128> jdub: hey :)
<seb128> jdub: pango 1.9 to the archive or not?
<jdub> seb128: nah, think that should be decided with gtk
<mfgalizi> I'm having some package issues, and I was wondering if someone could help me out.  I'm trying to keep a single repository for Debian and Ubuntu.  The problem is that they use different versions of libc6, and if I compile on my debian box (even specifying a version manually), Ubuntu users get failed dependancies.  Any thoughts?  Am I going to have to keep two repositories and two sets of packages?
<seb128> jdub: k, was not sure
<jdub> seb128: i'm using your packages, btw :)
<seb128> that works fine?
<seb128> it doesn't feel slow here
<mfgalizi> Bueller?  Bueller?
<mako> jdub: i sort of monitor my procmail queue.. it was going *insane* yesterday :)
<mdke> heh
<mdke> list bounces?
<bob2> mfgalizi: or concot a custom chroot containing the lower version of each of your dependencies
<jdub> seb128: yeah, that is because we use clearlooks THE ULTIMATE IN GTK ENGINE PERFORMANCE
<seb128> ah ah
<mfgalizi> bob2, thanks, but I think I'd sooner maintain two sets of packages.
<bob2> yup
<bob2> plus that's simple to automate
<mfgalizi> yeah
<mfgalizi> :(
<mfgalizi> bob2, I could just remove the automatic dependancies from the control file and specify them manually, couldn't I?  I know this is a bad thing to do, but it would work, right?
<bob2> not in general
<mfgalizi> oh... why?
<bob2> those dependencies are there for a reason
<bob2> shlibs makes you Deppend on the version of a library you compiled against, in case you used a new symbol from it
<mfgalizi> I understand its probably the worst thing I could do, but it would work, right?
<bob2> not in general
<mfgalizi> ok
<bob2> it may work in your particular situation, for now
<Kamion> it will work until it doesn't; it will break with no warning; at that point you and your users will be left scratching your collective heads wondering what went wrong
<mfgalizi> Right, this is what I figured.\
<Kamion> and it may break even now on other architectures; unless you can thoroughly test on all of them, you have no way to know
<mfgalizi> I'm only compiling for one arch (this isn't in the official distribution)
<Kamion> sure, but somebody else may well take your source package and build it for other architectures
<mfgalizi> Uh, doubt it.  In any case, I think I'll just keep two chroots.
<mfgalizi> thanks for the help, all!
<shawarma> \sh: Ok, I'm back. Weird, the build in the fakeroot environment worked just fine.
<\sh> shawarma: well
<shawarma> \sh: It's great, but strange nevertheless.
<Micksa> is anyone here able to play a DVD or something with AC3 audio in mplayer on breezy or hoary?
<Lathiat> how can i tellifits ac3 audio?
<Lathiat> any dvd?
<Micksa> just about any DVD
<Micksa> at some point in the console output it should mention liba52
<fabbione> Micksa: these are morelikely #ubuntu questions
<fabbione> Lathiat: same ...
<Micksa> graghrgrhghr
<Micksa> fabbione: the response in #ubuntu was "use totem" 8)
<Micksa> whcih would be fine if playing DVDs was what I wanted to do. but I want to encode.  And neither mplayer nor mencoder will work with AC3 audio for me.
<Micksa> so I'm trying to narrow it down.
<Lathiat> Micksa: not in here :)
<Micksa> I know I know. I'm done
<thom> whiprush: man, you rock
<ogra> oh... seb128 YOU BLOG ? WOW !
<fabbione> Kamion: as soon as 12 final is built, you are good to go to switch d-i
<fabbione> Kamion: i still need to clean up nic-* and scsi-* but i guess we can do it in one of the next upload
<Kamion> fabbione: great, thanks
<fabbione> Kamion: i am aware that there are some regressions between rc6 and final
<fabbione> somebody says related to udev, but i not according to my tests
<fabbione> so if we get bug reports on boot being slow we know what's wrong
<fabbione> where slow = boot takes half second more
<Kamion> elmo: does katie support architecture-specific priorities?
<elmo> no
<elmo> mostly 'cos apt-ftparchive doesn't
<elmo> but there's patches floating around
<elmo> tjhat mvo may or may not be integrating
<Kamion> mvo: *nudge*
<elmo> kamion: and err, yeah, should be possible, tho i'd prefer not to do it automatically based on germinate, but  make it an anastacia type system
<elmo> the priorities-for-minimal thing
<Kamion> elmo: jackass:~cjwatson/jessica (name chosen arbitrarily) gets most of it right I think, modulo the arch-specific thing - if you run it with -n it's anastacia-like
<elmo> oh, keano
<Kamion> guess what I've been doing all afternoon
<Kamion> I think I'll need debconf bumped to required as well, which jessica won't tell you
<Kamion> I haven't tested it without -n, for obvious reasons
<Kamion> elmo: it looks at the wrong germinate output file at the moment, really - I think we'll want cron.sync to produce sync/germinate/output/tmp/minimal_${suite}_${arch} files the same way it does for desktop
<elmo> yeah
<elmo> the whole germinate as driven by cron.sync is a bit icky
<Kamion> mm
<Kamion> shame germinate's so slow and fond of filling the cwd with files, or it could just run on the fly
<elmo> yeah
<fabbione> mdz: ping?
<fabbione> Kamion: are you going to stay around for a bit?
<fabbione> i need to go away.. if you can kindly remember mdz to seed 2.6.12 for main and make it the default...
<Kamion> I'll be here for maybe 45 minutes more
<fabbione> elmo: the last upload will need NEW love once it's builded
<fabbione> ok
<fabbione> i really need to go
<Kamion> I'll do the seeding
<fabbione> it has been a marathon today
<fabbione> and i need to run away in 20 minutes from home
<fabbione> Kamion: ok thanks
<fabbione> Kamion: remember that i killed power3/power4
<Kamion> yes, remembered :)
<fabbione> so you can just forget about them :)
<Kamion> no other arch package name changes?
<fabbione> ABI bump?
<fabbione> it's -2-
<Kamion> I know that bit
<Kamion> that's easy
<fabbione> no.. we might have too look at the list of udebs since we added a couple for non-supported arches
<fabbione> but that's nothing that need fixing right now
<Kamion> ok, that can be worried about later
<fabbione> exactly
<fabbione> thanks a lot guys
<fabbione> cya tomorrow
* fabbione &
<Keybuk> fg
<Keybuk> ^Z
<Keybuk> bg
<Keybuk> disown %1
<Keybuk> ^D
<tseng> Keybuk: he respawns
<Kamion> ah, somebody else who uses disown
<Keybuk> hmm?  I didn't kill him
<daniels> disown kicks arse
<Kamion> tseng: ... and you're somebody who doesn't use disown
<tseng> i guess not.
<tseng> No manual entry for disown
<Kamion> help disown
<Kamion> it's a shell builtin
<tseng> oh!
<tseng> thats very useful
<thom> Kamion: foo &| is more my usual style
<thom> but that's a zshism
<Keybuk> it's basically nohup, but after you've run the command
<Kamion> I was about to say "zsh freak", yes :)
<Kamion> fabbione: seed changes done
<daniels> yeah, I use &|, or disown after the fact
* Keybuk does &| too
<daniels> Kamion: zsh is LOVE
<tseng> daniels: fix my home/end keys and ill use it
<daniels> tseng: setopt VI, Esc-0, Esc-$
<Keybuk> actually, that's untrue, I use &!
<thom> what is &!?
<elmo> background and disown in zsh
<Kamion> hmm, I take it Fabio didn't do linux-meta
<thom> so just the same as &|, or is there a difference?
<Kamion> $ dpkg-source -x linux-meta_2.6.10-7.dsc
<Kamion> dpkg-source: error: unrecognised file suffix `.tar'
<Kamion> score
<Kamion> guess I should fix the version number for the next one
<Clint> &| and &! are equivalent
<thom> Clint: righto, thanks
<Keybuk> it's the same
<Keybuk> but I tend to use &| for "pipe stdout AND stderr"
<Keybuk> well, |&
<thom> Keybuk: yes, i know what equivalent means ;P
<thom> heh
<Keybuk> zsh is sex
<Kamion> fabbione: can power3/power4 kernel users upgrade smoothly to powerpc64 kernels?
<Kamion> mdz: [2.6.12 status]  I've got uploads prepared for base-installer, debian-installer, and linux-meta to cope with the switch to 2.6.12 and the powerpc64 changes, plus corresponding seed changes; I'm going out shortly, but I'll upload them later tonight
<Kamion> somebody will need to do 2.6.12-2 l-r-m
<mdz> fabbione: is someone working on l-r-m?
<mdz> Kamion: is it a prerequisite for CD builds?
<Kamion> mdz: it gets confusing if it's not there, but it's not *strictly* a prerequisite
<Kamion> as in people will get linux-image-* installed instead, which will prove interesting for upgrades
<jammcq> mdz: howdie
<mdz> jammcq: good morning
<mdz> Kamion: presumably we could remove the dep from linux-meta
<bob2> mjg59: is https://sourceforge.net/projects/sbs-linux/ crack?
<Kamion> mdz: in desperation, yes
<Kamion> I suppose that might even be short-term correct
<mjg59> bob2: If it's the one I'm thinking of, then yes
<mjg59> It requires hacking DSDTs to get battery support
<bob2> yeah, it requires IASL at build-time
<Kamion> I'd like to generate linux-meta's debian/control from a template at some point, so that editing it isn't so error-prone
<mjg59> The "right" way of doing it is to integrate the smart battery driver and teach hal about it
<bob2> is it dangerous or just hacky?
<jammcq> up
<mjg59> Which?
<jammcq> oops, sorry
<mjg59> The DSDT hacking thing? It's fucking stupid
<bob2> mjg59: using something which hacks the dsdt
<mjg59> Yeah
<bob2> hah
* mjg59 goes home
<mako> mvo: you gonna be at LT?
<mahmoud> hello...I've got a question: if I have the full path of a file, except that the file name itself is incomplete (but is known to identify it uniquely), what's the most efficient way to open the file? (the aim is to minimize scanning & name matching as much as possible)
<justin> append a * and glob?
<bddebian> Hello
<bddebian> Hmm, no Kamion
<ogra> doko, alive ?
<doko> ?
<ogra> doko, how good is your assembler-fu ?
<ogra> error: PIC register '%ebx' clobbered in 'asm'
<ogra> :(
<doko> could be better ...
<ogra> ffmpeg is ftbfs on i386, but on all other arches it works just fine...
<ogra> i found a patch for building it with gcc-4.0 but it still fails with this error....
<chrissturm> ogra: this seems to be a problem a lot of packages have with the new gccs. how can i reproduce it?
<ogra> chrissturm, grab the latest debin ffmpeg package, add the epoch that the ubuntu package has.... apply the gcc-4.0 build patch from gentoo and try to get it compiled on i386
<ogra> chrissturm, its a problem with double used registers in the assembler code if i understood it right... but i'm not enough of a assemble guy to fix it.... also there seem to be no further patches for this prob yet
<chrissturm> ogra: can you paste me the snippet?
<ogra> chrissturm, the patch ? 
<chrissturm> ogra: i think a asm part must tell what parameters it changes, and its not legal to change some of them. so you must save ebx on start and restore it later
<chrissturm> ogra: the part of the source that he is complaining on
<chrissturm> the __asm__ snippet
<ogra> oh, sorry...
<ogra> chrissturm, thats a bit bigger, rather pull the source and look at libavcodec/libpostproc/postprocess_template.c in the source
<chrissturm> ogra: it should be easy to fix
<chrissturm> ogra: point me to the source package tgz and i help you!
<ogra> i'll upload it... wait a moment
<chrissturm> k
<ogra> chrissturm, http://www.grawert.net/ffmpeg/
<chrissturm> ogra: can i reproduce it without applying the patches?
<ogra> chrissturm, thats the stage i stopped with, the patch is contained already
<chrissturm> ogra: http://www.grawert.net/ffmpeg/ffmpeg_0.cvs20050313.orig.tar.gz
<chrissturm> this one?
<ogra> chrissturm, download all three (.dsc .tar.gz and .diff.gz) into the same dir and run dpkg-source -x ffmpeg_0.cvs20050313-2ubuntu1.dsc, it will create the patched source dir
<chrissturm> ok
<chrissturm> then just ./configure && make?
<ogra> nope
<ogra> easiest to see the error will be: fakeroot debian/rules binaryyyyyyy
<ogra> oops
<ogra> m keyboard goes crazy
<ogra> you will need to install fakeroot for that....
<ogra> chrissturm, assuming you run breezy
<chrissturm> ok, building
<chrissturm> sure
<kiko> mdz, ogra: or #ubuntu-bugs?
<ogra> hey kiko 
<mdz> kiko: bugdays
<kiko> ;)
<kiko> did you read my mail?
<mdz> kiko: I actually need a keyboard break right now
<mdz> can we talk about this in 15 minutes?
<kiko> YES
<tseng> heya kiko 
<kiko> heya tseng 
<kiko> I might want a keyboard break too, everybody's doing it
<ogra> use gnome-typing-monitor.... it does that for you :)
<mdz> kiko: ok
<mdz> ogra: workrave >> gnome-typing-monitor
<ogra> ah, yes
<kiko> it's the mdz people
<mdz> kiko: so I'm reading your email
<kiko> I like to be kept informed 
<mdz> kiko: most importantly the list of prereqs
<mdz> do we actually need any bugzilla changes in order to make this work?
<mdz> we can set up a pre-cooked query for likely targets
<tseng> wasabi_: gcjwebplugin < ever heard of this?
<mdz> beyond that, I think the existing tools are sufficient
<ogra> yep
<kiko> mdz, we can have icing -- the homepage change, for instance
<kiko> nothing that's critical to getting it going
<ogra> a stored query would be enough
<kiko> ogra, it needs to be pasteable
<kiko> stored queries don't have that property (they are personal)
<mdz> right, I'm focused on what we need to do before we can make an announcement and have our first bugday
<mdz> the documentation is the biggie
<kiko> I can commit some time to writing documentation
<kiko> at the expense of a healthy sex life
<ogra> heh
<mdz> I'm probably better suited to write that, since I've more or less defined the process for ubuntu bugs
<mdz> it will also probably take me a week to find the time to do it properly
<kiko> I can commit a half-day to bugday participation
<kiko> at the expense of everything else 
<ogra> i can do that too, but am busy with the first edubuntu CD until july 3rd
<kiko> mdz, why don't you write the documentation tonight, I review it tomorrow, we write the announcement on friday and launch a bugday on next tuesday?
<kiko> tuesdays are good days
<kiko> no launchpad meetings
<mdz> kiko: I can't tonight; I have 70 bounty applications to review by friday
<seb128_> speaking about bug howtos?
<ogra> kiko, tuesdays are TB and CC meetings
<mdz> seb128_: yes
<seb128_> I can update GNOME stuff for ubuntu and put that to ubuntu bugzilla if you want:
<ogra> seb128_, you had something there 
<kiko> mdz, why don't we just steal content and polish it later?
<seb128_> http://developer.gnome.org/projects/bugsquad/triage/stock-responses.html
<kiko> that's talking!
<seb128_> stock replies for dups, etc
<seb128_> http://developer.gnome.org/projects/bugsquad/triage/
<seb128_> about triage
<seb128_> basically this page is a good example
<mdz> that looks pretty good
<ogra> yep
<mdz> we just need to extend it to describe our severities and assignment process
<seb128_> yep
<seb128_> and describe the "forwarded upstream" case
<ogra> i could do it after the edubuntu summit, but i doubt i find the time before
<mdz> should we invite bugday participants to forward bugs?
<kiko> sure
<seb128_> they should ask on IRC first
<ogra> yep
<kiko> they will ask everything on IRC first, at first
<mdz> tseng: yes, the issue with gcjwebplugin is that it has no security manager (and is therefore completely unsafe)
<tseng> argh
<mdz> I've added bugday documentation to my todo list
<mdz> hopefully by the end of the week
<kiko> okay
<ogra> mdz, if you cant make it, just forward it to me then
<mdz> ok
<ogra> since then its in my timeframe :)
<mdz> kiko: what shall we do about editbugs?
<kiko> mdz, revoke it before the first bugday and add it back gradually to people that deserve it.
<kiko> listen carefully on #ubuntu-bugs for complaints
<seb128> editbugs, like people setting the milestone to the distrib they use?
<mdz> we should make an announcement and ask people to contact us in order to get it re-added
<kiko> yes
<kiko> well, the policy should be if you deserve it you get it
<mdz> I think I'm the only bugzilla admin at the moment; that is ab ug
<mdz> a bug
<chrissturm> ogra: dunno how to fix this. maybe you want to try a newer cvs snapshot
<mdz> kiko: right, but I don't have a list of everyone who deserves it.  they need to remind us
<kiko> and when you get it, you get to read a page that tells you how to behave
<kiko> mdz, these people usually show up anyway :-)
<ogra> chrissturm, yes, thats my last resort
<chrissturm> ogra: http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/libpostproc/postprocess_template.c.diff?r1=1.93&r2=1.94&cvsroot=FFMpeg
<chrissturm> postprocess_template in cvs is very different from the cvs snapshot you were using
<chrissturm> ogra: sorry that i couldnt help
* chrissturm gotta go
<ogra> chrissturm, you already helped, thanks :)
<ogra> chrissturm, every pair of eyes counts ;)
<mdz> kiko,ogra: how about wednesday 6/29 as the first bugday?
<mdz> 0000-2359 UTC
<ogra> mdz, if we have the docs ready til then....
<mdz> we will
<ogra> ok
<mdz> if it's not done by the end of this week, I will do it over the weekend
<Burgundavia> seb128, I already created  wiki page with those responses, and created a forwarded upstream message
<ogra> then its ok with me...
<kiko> mdz, yes
<kiko> mdz, midnight UTC?!
<Burgundavia> BugResponses
<kiko> oh, the whole day, sorry
<mdz> kiko: a 24-hour UTC day, so everyone gets a piece in their time zone
<kiko> that's great
<kiko> I can handle 12UTC to about 17UTC
<kiko> I need editusers and editbugs
<kiko> k
<kiko> thx
<kiko> bye
<kiko> :)
<mdz> I can do about 0 UTC - 7 UTC, and then 15 UTC on
<mdz> kiko: did you just volunteer to become a bugzilla admin?
<ogra> :)
<kiko> to handle a bugday you need to have editusers and editbugs
<kiko> that's not optional
<kiko> otherwise people come to you and say "I can't do X" and you say uhhh yeah, contact the admin.
<kiko> that's not a very exciting bugday process
<mdz> kiko: how do I make you a bugzilla god?
<kiko> it's more exciting if you say "whoosh here are your privs" and the guy says "oops I just deleted the Ubuntu product"
<mdz> I will do it right now
* kiko shakes head
<kiko> all that power
<seb128> Burgundavia: "If the bug is not GNOME" ... you could have updated
<ogra> hehe
<kiko> mdz, editusers.cgi
<mdz> kiko: done
<kiko> mdz, "k-i-k-o-<enter>"
<kiko> click
<kiko> admin checkbox
<mdz> Added user to group editusers
<kiko> click
<mdz> Added user to group admin
<mdz> Added user to group editbugs
<kiko> update
<seb128> mdz: https://wiki.ubuntu.com/BugResponses to update for the standard replies
<kiko> thanks
<mdz> ogra: I can't find you in editusers.cgi for some reason
<mdz> oh, you changed your email
<mdz> ogra: you've got editbugs and editusers as well now
<ogra> thanks
<Nafallo> seb128: I have a bug for you on malone, but can't find out how to assign it :-P. #1111 for what's it worth :-).
<ogra> sure i changed :)
<mdz> kiko: would be nice if editusers.cgi would search realname as well as login
<kiko> Nafallo, I just commented on it.
<kiko> I need more information before moving it upstream.
* ogra just recognized that the chief editor of the software division of LinuxMagazine has a ubuntu bugzilla account :)
<mdz> Riddell: please update your email address in bugzilla and maintainer fields to @ubuntu.com
<tseng> Nafallo: ah dude, I did a use case on malone assignment
<tseng> Nafallo: they are totally hacking on a fix
<seb128> Nafallo: the bug is quite useless, can you mention the error?
<seb128> and the version/distrib
<mdz> ogra: do you know dholbach's email address in bugzilla?
<Nafallo> kiko: i just commented back :-)
<ogra> mailempfang.de
<Nafallo> tseng: rock on dude! :-)
<ogra> i think dh@
<ogra> yes
<Nafallo> seb128: sure, I'll catch it again...
<seb128> grumpf
<seb128> malone has not NEEDINFO??
<seb128> wtf
<Nafallo> seb128: the error is in swedish ;-)
<seb128> Nafallo: I'll use the .po to get the english one
<Nafallo> oki
<Riddell> mdz: done
<mdz> Riddell: thanks
<mdz> kiko: I'm granting editbugs to everyone I can think of who ought to have it
<mdz> should be a good starting point
<Nafallo> hehe, crossmessaging :-P
<kiko> mdz, have you revoked it?
<Nafallo> seb128: Ubuntu GNOME Team? you and dholbach? :-)
<mdz> kiko: not yet
<mdz> I thought it would be wiser to do it in this order :-P
<seb128> Nafallo: quite of, we don't even have a list to get bugs, so ...
* dilinger notices ichat users w/ currently playing track displayed on aim.  i want that; gaim pulling currently playing track from dbus, populated by totem or rhythmbox or something..
<seb128> mdz: did you change my bugzilla rights?
<mdz> seb128: I think you were already in editbugs
<seb128> mdz: I had edit component stuff, seems to be removed now
<mdz> bu tat any rate I made sure you were
<kiko> Nafallo, commented again
<seb128> I kind of use it :)
<mdz> seb128: why do you edit components?
<tseng> dilinger: muine publishes track info to dbus
<dilinger> nice
<seb128> mdz: because half of GNOME stuff are not assigned to me and you keep reassign bugs
<mdz> seb128: oh, you're setting the default assignee.  ok :-)
<seb128> mdz: and because I've put the desktop-bug list as QA for a desktop stuff too
<tseng> dilinger: there is a little app called muine-shell to script it into things
<tseng> dilinger: if you dont want to connect straight to dbus
<mdz> seb128: fixed
<seb128> s/a desktop stuff/desktop stuff/
<seb128> thanks
<mdz> I was only thinking about editcomponents for adding and removing
<mdz> which should not be necessary since debzilla automates that
<seb128> right
* Nafallo installs grip
<mdz> ok, I think I'm ready to revoke global editbugs
<Nafallo> kiko-afk, seb128: commented.
<kiko-afk> mdz, announce and do it
<mdz> kiko-afk: writing the announcement now
<mdz> kiko-afk,ogra: ok if I mention you guys as points of contact for getting editbugs back?
<ogra> yeps
<mdz> alternatively, I can tell them to just show up to the bug day
<mdz> where editbugs will flow like water
<ogra> hopefully :)
<kiko-afk> right
<kiko-afk> tell them to show up on the bugday
<Nafallo> bugday? find as many as possible and get a prize? :-)
<ogra> Nafallo, nope
<kiko-afk> Nafallo, that too :)
<ogra> Nafallo, find the ones the community decides as the worst and gat famous AND get a prize !! :)
<ogra> s/gat/get
<mdz> announced
<Nafallo> ogra: hehe
<kiko-afk> mdz, you are a phat hacker
<mdz> and removed editbugs from .*
<mdz> kiko-afk: s/hacker/document0r/
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Colony CD 1 released | don't use ppc64 kernels yet. wait for the next release kthxbye. | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko
<kiko-afk> I will only give editbugs back given a bribe, I forewarn people
<Burgundavia> can I have editbugs back?
<kiko-afk> Burgundavia, do you commit to a) not changing target milestone spuriously b) being responsible with existing bug data c) upholding justice truth and liberty
<kiko-afk> Burgundavia, note that a) is the hard requirement 
<Burgundavia> yes
<kiko-afk> yes yes yes?
<Burgundavia> yes yes yes
<ogra> kiko-afk, i think we can give the power back to Burgundavia ;)
<Burgundavia> I don't think I have ever changed a target milestone
<kiko-afk> okay, changing
<kiko-afk> Burgundavia, we're doing this for your good. you need to strive to uphold justice truth and liberty. and love.
<kiko-afk> (and linux)
<ogra> kiko-afk, he does, he was always a helpful bugfighter :)
* Burgundavia has visions of neo-orwellian stuff
<ogra> hehe
<kiko-afk> whoa!
<kiko-afk> who beat me to editusers?
<ogra> kiko-afk, youself ?
<kiko-afk> no, somebody else added him before.
* kiko-afk snifs
<kiko-afk> I'm out for a bit, bbi1hmol
<ogra> have fun
<tseng> if you understood that instantly
<tseng> you are a geek
<Nafallo> lol
* tseng is guilty.
<Nafallo> rhytmbox eat's my cpu :-P
<Burgundavia> I discovered why beagle was eating all my cpu
* Burgundavia hangs his head in shame
* Burgundavia had --fg option set
<tseng> yeah no kidding
<Nafallo> and I deleted the songs it was playing ;-)
<tseng> printf is expensive for some reason
<tseng> or, programs with lots of output run faster when redirected somewhere other than the screen at least
<doko> mdz: please could you turn editbugs for me again, just as long as there are C++ ABI change related bugs reports open?
<ogra> doko, i'll do it
<mdz> doko: I turned it on for you before I even disabled it globally
<ogra> ah
<mdz> Burgundavia: likewise for you, I had already given you editbugs
<Burgundavia> ah
<Burgundavia> thanks
<doko> mdz: thanks
<mdz> the mail was pretty explicit: I've re-added a bunch of people, and contact us only if you find that you _don't_ have privileges :-)
<doko> nitpicking ;-)
<mdz> kiko-afk: how do I create global saved searches?
<whiprush> thom: ? why do I rock?
<ajmitch> morning
<mdz> fabbione: is the unionfs in 2.6.12-2 the newest upstream?
<Amaranth> hrm
<Amaranth> i changed my ram timings and such and memtest no longer reports any errors
<Amaranth> so now i'm just lost as to why X apps all segfault
<Amaranth> something about OpenWindow in gdb, but i can't get a backtrace
<Amaranth> i'll just reinstall hoary
<mdz> Amaranth: perhaps you have corrupted packages from the time when your ram was introducing random errors
<Amaranth> yeah, but that was 300 packages
<Amaranth> touching everything from GTK to X to the kernel
<Amaranth> so i'll just reinstall
<Amaranth> i have /home on it's own partition so it's not like i lose anything
<Amaranth> bbl
<Burgundavia> can someone else with breezy confirm that this bug is fixed? https://bugzilla.ubuntu.com/show_bug.cgi?id=1944
<Nafallo> Burgundavia: how to scroll that one?
<Nafallo> Burgundavia: seems fixed AFAICT
<Burgundavia> I just fixed it
<Burgundavia> s/fixed it/marked it fixed
<mdz> Burgundavia: thanks for your help in bugzilla
<mdz> it's getting a bit out of hand, which is why we're trying to organize more community  involvement
<Burgundavia> np
<Burgundavia> our bz is nothing compared to the gnome one
<mdz> how many people work in the gnome bugzilla?
<Burgundavia> no idea, but the issue is always that of man power
<Burgundavia> s/man/people
<mdz> bugzilla.mozilla.org has many more bugs than we do, but they also have many more people
<\sh> mdz: sorry for being late, but can you shortly explain, what's going wrong, what fields were filled in wrong etc.??
<kiko-afk> \sh, mainly target milestone being misused
<\sh> kiko-afk: means?
<\sh> or did anyone explained it already here and it's in the irclogs? then I'm going to read now ;)
<ogra> \sh, not everybody should be able to change things in bugzilla, we changed it so we can assign write rights to people who kow what they do (and which show up on the bugday)
<ogra> s/things/severity, target milestone, asignee/
<\sh> ogra: thx :) understand...*phew* and I thought, someone pushed all entries to me *sweatbloodandtears*
<ogra> \sh, hmm, good idea....
* ogra fires up firefox
<\sh> *praystothedevilfor666*
<ogra> \sh, already solved https://bugzilla.ubuntu.com/show_bug.cgi?id=666
<ogra> \sh, and you wouldnt have wanted this one ;)
<ajmitch> looks evil
<ogra> yes, 666
<ogra> :)
<\sh> ok...lemme have a look at 1001
<Burgundavia> mdz, for stuff that has moved out of main into universe (ggv), can I mark the old bug as universe and create on in malone?
<kiko-afk> Burgundavia, sounds like a plan
<Burgundavia> bug work is sleep enducing
<bddebian> heh
<Burgundavia> how can you mark something as upstream, and not list a url for an upstream bug?
<seb128> there is no policy saying that upstream == forwarded
<seb128> I use that for GNOME bugs though
<Burgundavia> hmm, ok
<Burgundavia> I filed a malone bug about this
<Burgundavia> stating that upstream == forwarded
#ubuntu-devel 2005-06-30
<seb128> I've some bug set as upstream not forwarded though
<Burgundavia> to me, the point of marking something as upstream is that the upstream has been notified
<seb128> ie: for bugs that are know by upstream even if there is no special bugzilla bug for them
<seb128> yeah, but upstream know stuff out of bugzilla
<Burgundavia> true
<seb128> discussed on the list, on IRC, etc
<Burgundavia> but the advantage of filing a bug is that then non-developers can track what is happening
<Burgundavia> that is, after all, what a bug tracker is also for
<seb128> what is the point to open bugs like https://launchpad.ubuntu.com/malone/bugs/1115 ?
<seb128> bugzilla.ubuntu.com already has this bug
<Burgundavia> kiko-afk Burgundavia, sounds like a plan
<seb128> hum, k, that's an universe bug
<Burgundavia> seb128, I am trying to make your life easier, not harder
<seb128> you should open upstream bugs upstream so :)
<seb128> so I don't have to argue for ages about details with them
<seb128> most of your bugs are small details, need to be discussed and I don't agree with half of them
<Burgundavia> the devil is in the details
<Burgundavia> seb128, I learned a long time ago that we don't agree on a great many points
<kiko-afk> <Burgundavia> I filed a malone bug about this
<kiko-afk> I have a comment on this.
<kiko-afk> The comment is that malone doesn't /need/ an upstream resolution
<TMM> or is that one of those :"if you want it, implement it" things?
<kiko-afk> why?
<Burgundavia> true
<Burgundavia> hmm
<kiko-afk> because it has bugwatches
<kiko-afk> any bug /can/ be upstream
<TMM> hey, just out of curiousity, any chance for a reiser4 install option with breezy?
<seb128> kiko-afk: do you know why, whyyyy, I have to login to malone every single time I start my browser ?
<TMM> sorry, my copy/paste skills really suck :)
<kiko-afk> so you link a task to an upstream bug, and just look at the comments trickle in
<kiko-afk> and then the fix!
<Burgundavia> ok
<ogra> TMM, if linux accepts it in the official kernel
<Burgundavia> .13 is supposed to
<kiko-afk> seb128, yes. it's using a session cookie, not a persistent cookie. if you file a bug I have more firepower to change it.
<ogra> TMM, s/linux/linus
<seb128> kiko-afk: do you know if that's already filled?
<kiko-afk> it's not, IIRC.
<seb128> (so I can be lazy and not search for it)
<seb128> thanks
<TMM> also, I've changed some stuff in the laptop part of ubuntu, where do I go with patches and/or go for discussion?
<TMM> I think it's useful, at least, it is on my hardware :)
<ogra> TMM, ubuntu-devel mailing list
<TMM> okidokie
<TMM> high volume?
<ogra> nope
<TMM> good :)
<seb128> kiko-afk: is https://launchpad.ubuntu.com/malone/bugs/676 about this?
<TMM> isn't reiser4 already in mainline?
<TheMuso> =/cl
<Burgundavia> TMM, no
<TMM> ow... I thought it was
<TMM> well, spank my ass and call me charly :)
<TMM> it's not going to be accepted until it is in linus' tree?
<TMM> there's other stuff in the ubuntu kernel that's not in linus' tree, right?
<kiko-afk> seb128, hmm, that's a terrible summary for it, but yes!
<seb128> kiko-afk: should I put a "me too" on it? :)
<kiko-afk> YES!
<zul> TMM, yes..but reiserfs4 is still not to be included anytime soon
<TMM> too bad
<kiko-afk> mdz, there are no global saved searches.
<TMM> I tried it on a test machine, at the whole system felt a lot faster because of it
<TMM> might be purly perception though
<TMM> I expected it to be faster, so, I guess it's not a good benchmark
<ogra> TMM, speed is not everything.... fast filesystems might loose data fast as well ;)  (especially reiser)
<TMM> yeah... I can remember the early days of reiser3...
<TMM> a friend of mine always says :"reiser has great ideas, and is probably the smartest fs designer out there... don't touch his code with a ten foot pole until it's ver 1.5"
<TMM> I guess there's truth in that :)
<ogra> remove the dot in the version number and i'm with you
<TMM> lol
<tseng> elmo: can we get boo synced from unstable please?
<TMM> reiser3 has been very stable for me since 2.4.15 or something
<ogra> so he has still 11 to go, given we are at 4
<TMM> never had any data loss actually
<TMM> which, in my book, is a good thing when it comes to filesystems :)
<seb128> mdz, kiko-afk: do we have any "easyfix" bugzilla keyword? GNOME guys use that to show where people can contribute
<Burgundavia> hans also has some inter-personal communcation issues, from what I have read of his emails
<ogra> seb128, that was originally in my proposal
<seb128> what proposal?
<zul> Burgundavia: what classic geek doesnt?
<ogra> (something similar at lleast)
<ogra> seb128, bug day proposal
<seb128> ie?
<seb128> do you send that on a list?
<TMM> yeah hans and linus seem to have a lot of 'issues' 
<seb128> wiki?
<ogra> seb128, having an additional bug tag for community people
<ogra> seb128, nope
<TMM> hans always things he is right, and linus... well, kind of thinks the same way :)
<TMM> that usually clashes
<kiko-afk> seb128, we could create one, I'm not against it.
<TMM> I wonder if it's any better now
<seb128> kiko-afk: I could use it for some bugs
<kiko-afk> let me see
<seb128> kiko-afk: ie: https://bugzilla.ubuntu.com/show_bug.cgi?id=6371
<kiko-afk> seb128, trivial or easyfix or helpwanted or lowhangingfruit? :)
<seb128> kiko-afk: but that could be also a forwarded to bugzilla.gnome.org and handled here
<kiko-afk> seb128, true. 
<ogra> lowhangingfruit
<kiko-afk> :)
<seb128> kiko-afk: helpwanted is something else ... just want to point a bug that could be easy to fix for a contributor and useful
<\sh> guys...don't talk about boobs when I want to go to bed
<ogra> or strawberry-bugs ;)
<kiko-afk> seb128, do it or not?
<seb128> kiko-afk: hum
<\sh> lowhangingfruit, strawberry-bugs..what else? bugslikecherries?
<\sh> off I go...good night gentlemen
<seb128> kiko-afk: the issue is that I have some people sending random "this corner of the UI could be better", Burgundavia does that a lot, and that doesn't suit for upstream really and I've too many bug to handle to fix that myself
<kiko-afk> seb128, created easyfix.
<seb128> kiko-afk: that's not good for upstream because I know this is going for stay ignored here for ages too and there is no really interest to flood upstream with that
<seb128> thanks
<kiko-afk> seb128, we can tell people to fix here and then push upstream, perhaps.
<seb128> I'll do that
<seb128> atm I just ignore them
<seb128> but that's not optimal
<kiko-afk> right.
<kiko-afk> I want to be able to use easyfix in bugdays too.
<seb128> these bugs for me are "could be a good start for a contributor looking for an easy task to do"
<seb128> so we can point the easyfix list on a bug days
<Lathiat> seb128: libgtk2.0-dev should depend on libcairo1-dev (in those devel packages)
<Lathiat> seb128: otherwise pkgconfig fails
<seb128> Lathiat: these are non-official packages, but thanks
<seb128> pango should b-d on it too
<seb128> I don't want to bother rebuilding and scping here for that
<Lathiat> seb128: yeh just letting you know for future
<seb128> thanks
<Lathiat> thought you might not have noticed if you had it installed anyway
<thom> whiprush: well, in this instance, the NM blog entry
<whiprush> thom: oh, hey I found out why it's so flakey my X40.
<whiprush> updating the madwifi driver did the trick, works sweet now.
<thom> oh? rocking
<thom> i must get all the vpn stuff packaged
<whiprush> yeah whatever they shipped in Fc4 works nearly perfectly on the x40.
<Nafallo> thom: shtoom is yours to? :-)
<thom> Nafallo: daf's
<Nafallo> thom: ahh, oki.
<whiprush> thom: what kind of vpns does it support? (haven't tried it yet)
<thom> whiprush: currently only vpnc is used, which i think means cisco only
<whiprush> ah
<thom> (which is what redhat's vpn is ;-) )
<Nafallo> hehe
<Nafallo> thom: what will we use in ubuntu? :-)
<whiprush> hopefully eventually it will do pptp, etc. etc.
<thom> what? there is no ubuntu vpn, since there are no offices to vpn into. when i said redhat's vpn, I literally mean "Red Hat, inc"'s VPN 
<Nafallo> ahha. any ideas what vpn-solutions we might expect for breezy main? :-)
<Nafallo> that's what I meant ;-)
<thom> no idea if anyone is looking
<zul> whatabout openswan?
<Nafallo> if we want to be compatible with win we want pptp I suppose...
<whiprush> the ubuntu kernel has pptp support built already. I just set one up a month or two ago.
<Amaranth> that was almost painless
<Amaranth> now to figure out why my fonts look like ass
<seb128> Nafallo: nop, didn't notice for caire, but I've planned to fix such stuff before uploading to Debian/Ubuntu :)
<Nafallo> ... and pptp is in main already. would be nice to have support in network-manager in breezy :-).
<Nafallo> seb128: huh? :-)
<seb128> s/caire/cairo/
<seb128> Nafallo: why "huh"?
<Nafallo> seb128: what was that about? :-)
<seb128> <Lathiat> thought you might not have noticed if you had it installed anyway
<Nafallo> Lathiat != Nafallo ;-)
<seb128> Nafallo: s/Nafallo/Lathiat/
<Nafallo> :-)
<seb128> Nafallo: I fixed you sj bug btw :p
<seb128> s/you/your/
<Nafallo> seb128: I know. waiting for it to hit the archive :-)
<Nafallo> seb128: if it works my plan was to tell you how bloody fast you are ;-)
<Lathiat> heh i wish my unis cisco stuff worked with vpnc
<Nafallo> seb128: and thanx in advance :-)
<Lathiat> the offficial client stops all other traffic on all interfaces working, so breaks uml, bluetooth, vmware, etc
<seb128> Lathiat: nop, didn't notice for caire, but I've planned to fix such stuff before uploading to Debian/Ubuntu :)
<seb128> (with the right nickname this time)
<seb128> s/caire/cairo/
<Lathiat> ok :)
<seb128> Burgundavia: thanks for the bug cleanup and the upstream forwards
<Burgundavia> seb128, np
<Burgundavia> I will do some more tomorrow
<seb128> Amaranth: do you have a smeg place for Debian GNOME 2.10/users ?
<Amaranth> no
<Amaranth> pyxdg needs python 2.4
<seb128> oh, I got a bug about this on the new pyxdg
<Amaranth> sid is moving to python 2.4 soon, aren't they?
<seb128> Amaranth: for what does it require it?
<seb128> Amaranth: gcc4 first
<Amaranth> is uses reversed()
<Amaranth> err, it
<seb128> Amaranth: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315091
<Amaranth> gcc4 before python 2.4?
<seb128> Amaranth: the workaround is 2 lines
<Amaranth> seb128: talk to the pyxdg author, not me :)
<seb128> Amaranth: not an upstream issue
<Amaranth> um
<Amaranth> yes it is
<seb128> why?
<seb128> they require python2.4, good
<seb128> we use 2.3, Debian's issue
<seb128> we workaround it for Debian
<Amaranth> your issue then :P
<Amaranth> you handle pyxdg for debian, right?
<seb128> right
<seb128> and gnome-menus
<seb128> do you require a patched gnome-menus?
<Amaranth> no
<Amaranth> wait, yes
<Amaranth> 2.10.2 isn't out yet, is it?
<seb128> that's a patch from the gnome-2-10 CVS ?
<seb128> it's due today
<Amaranth> either 2.10.2 or pull from the 2.10 branch in cvs
<seb128> k, I'll ping markmc for a 2.10.2 and package that
<seb128> fix pyxdg
<seb128> then smeg is fine?
<Amaranth> should be
<seb128> cool
<Amaranth> i don't have a machine with 2.3 on it but i don't think i used any 2.4 things
<seb128> the menu editor is one of the favorite question from Debian users too
<seb128> anyway Debian has python2.4 even if that's not the default
<seb128> we can depends on it
<Lathiat> sigh
<Lathiat> ubuntu-forums still can post to the mailing list?
<Lathiat> (ubuntu-devel,ml)
<seb128> good question
<Lathiat> cus i just saw a post from dlist@ubuntuforums.org
<seb128> so probably yep
<Lathiat> sigh
<Burgundavia> they can't start threads now
<Lathiat> sigh
<Lathiat> @freedesktop.org has been getting alot of spam lately
<Amaranth> they used to be able to start threads?
<Amaranth> *shudder*
<Lathiat> to avahi,lathiat@,avahi-owner@, etc
<Burgundavia> if the issue gets too bad, the forum mods have said they will take it read-only
<Lathiat> So, thats why this email was in reply to a 3 month old e-mail. :)
<Nafallo> wow!
<Nafallo> free music feels great to listen to :-)
<Lathiat> theres some *really* good free music
<Lathiat> i have a stack of it
<Nafallo> I found Magnatune today *grin*
<Lathiat> what genre?
<Lathiat> purevolume.com has some good stuff too
<Lathiat> ah magnatune is a site
<Lathiat> hadnt seen thatone
<Nafallo> everything except danceband and rap :-)
<Nafallo> .com :-)
* Nafallo heads to purevolume
<Lathiat> nice, 160K/s off that site. :)
<Lathiat> mp3 in 30 seconds! :)
<Lathiat> hey this sounds like good hacking music
<Nafallo> I love that they let you decide the price and stuff :-)
<Nafallo> and format to download, and, and, and ;-)
<Amaranth> hrm
<Amaranth> my root theme won't change
<Lathiat> ubuntu:~/Desktop/Music> for i in `cat ../Alchemy-http.m3u`; do wget $i; done
<Lathiat> :)
<Lathiat> they eve have shuffle playlists, thats cool
<Nafallo> hmm, thomboy-applet crashes gnome-panel
<Nafallo> how nice
<Nafallo> dooh!
<Nafallo> s/thom/tom/
<ogra> Nafallo, not here
<Nafallo> ogra: started today. worked fine here to til then.
<Nafallo> I must have changed something :-P
<ogra> runs through since the last x upgrade
<ogra>  ...here
<Amaranth> doesn't work here either
<Nafallo> odd, I'll check it out later.
<Amaranth> it can't seem to find it's icon when i try to add it, then it says it quit unexpectedly, then it asks if i want to delete it or not
<Lathiat> Nafallo: hah, my dslis now going to be flatlined for thenext couple hours ;)
<Nafallo> Amaranth: exactly
<Nafallo> Lathiat: hehe
<Nafallo> Lathiat: mine is always flat :-)
<Lathiat> unfortunately i can only download 20GB internationally a month
<Lathiat> theres stuffinmy local city i get for free i do alotmoreof tho 
<Nafallo> I got no restrictions what so ever :-)
<Lathiat> heh
<Lathiat> i bet its faster too :)
* Lathiat kicks australian bandwidth costs
<Nafallo> 420/420kbit
<Nafallo> trafficshaped 512/512 ;-)
<Lathiat> hrm, or not
<Lathiat> 1.M/256
<Lathiat> 512 what?
<Nafallo> kbit
<Lathiat> *1.5M/256K(bits)
<Lathiat> how can you be traffic shaped higher than yoru link speed?:)
<Nafallo> no. the speed is 512kbit, trafficshaped to 420kbit
<Lathiat> heh when i get traffic shaped i get 72kbit
<Lathiat> ah right
<Nafallo> my pppoe kept dying :-P
<Nafallo> doesn't anymore ;-)
<Amaranth> eek!
<Lathiat> bram cohensblog is a good read
<Nafallo> Amaranth: ?
<Amaranth> where did seb go?
* Amaranth freaks out majorly
<Nafallo> 01:21 -!- seb128 [~seb128@ANancy-151-1-13-239.w83-194.abo.wanadoo.fr]  has quit
<Nafallo>           ["I like core dumps"] 
* Amaranth screams
<Nafallo> what was the workaround for the hdparm-bug? :-)
<Nafallo> if any...
<tseng> Nafallo: the cdrom one?
<tseng> Nafallo: that bugs the hell out of me
<Nafallo> tseng: yes
<Nafallo> I often forget to turn dma on til the cpuload becomes 100% ;-)
<Nafallo> the I remember :-P
<tseng> yeah it sucks to rip cds w/o dma
<Nafallo> copy stuff from dvds is worse ;-)
<Nafallo> damn
<Nafallo> I'll buy this album later :-)
<Lathiat> try burning
<Lathiat> cus if you turn dma on into the burn it screws it up :) (at least for me)
<Nafallo> Lathiat: hehe, I usally quit the task before turning it on ;-)
<Lathiat> yeh but quitting halfway through a burn is annoying cus you coaster the ddvd/cd :)
<Lathiat> notably annoying when that was your last cd :)
<Nafallo> hehe, indeed
<Nafallo> I usually don't burn stuff ;-)
<Lathiat> grumble, java exam soon
<Nafallo> I'm out of media :-P
<Nafallo> hmm, breezy-live is stable atm?
<Lathiat> Nafallo: http://penguins.squaa.org/waix.ipac/waix.ipac-day.png (ee that big yello wspike on the right? :)
<Nafallo> lol
<Lathiat> sighand its raining and i have to get the bus
<Nafallo> yay!
<Nafallo> seb really fixed the bug :-)
<tseng> jdub: did you ever package ifolder
* ogra sighs about the 21375628th failed ffmpeg build
<jdub> tseng: mmm, long time ago, but it was a hideous messs
<jdub> tseng: todd gave them a 2x4 on how to lay out their software
<jdub> tseng: might be better now, dunno
<tseng> jdub: ok..
<tseng> jdub: it is still alot of work it looks like
<tseng> jdub: 4 packages
* ogra gives up on ffmpeg for today :/
<squinn> Hi, maybe you can help me out with something.
<squinn> Does anyone in here know what burning software is to be shipped with Breezy?
<ogra> squinn, nautilus and serpentine
<jdub> hrm, where is fabio's 2.6.12-2.1 kernel
<jdub> build logs say it built
<ogra> oh, did it fail ?
<ogra> hmm
<jdub> no
<jdub> build logs say it built :)
<ogra> archive script ?
<squinn> Question #2
<squinn> Is there a way to just look at last reported bugs on Bugzilla?
<ogra> squinn, yes....
<ogra> the detailed search offers a time range
<squinn> Didn't notice that, okay, thanks.
<ogra> night all
<tseng> bye ogra 
<bddebian> Gnight ogra 
<squinn> Question.
<squinn> Is it a possibility to have one blanket command to apt-get install every single package in a repository?
<squinn> Like I want to apt-get install every single package in main.
<mxpxpod> squinn: you can't do that because certain packages conflict with others
<mxpxpod> at least, I don't think you can...
<squinn> ah, it's alright..comp borked. yay.
<squinn> reinstall warty, update to either hoary or breezy
<squinn> i'm not sure
<squinn> i may need breezy for devel work, but i could just chroot into it
<squinn> okay, well thanks
<dle> Greetings.  I'm an Ubuntu user.  I'm interested in becoming a package maintainer for an app not yet packaged for either Ubuntu or (afaik) Debian.  I'm wondering if I should begin this via Ubuntu or go upstream and use the debian process.  Any thoughts or recommendations?
<jsgotangco> you can try with the MOTU team
<jsgotangco> #ubuntu-motu
<dle> Okay.
<dle> Universe being the source where the two meet, I guess.
<schweeb> universe being where anything not being part of the ubuntu main distribution goes... the software unsupported by ubuntu/canonical itself
<dle> nod
<fabbione> morning
<bddebian> Hello fabbione 
<fabbione> mdz: ping?
<mdz> fabbione: yes?
<fabbione> mdz: sorry. i couldn't shutdown your machine yesterday
<fabbione> not sure if you read the /msg
<mdz> I did, and I replied to it via /msg
<mdz> my fault of course
<fabbione> oh i think i lost the scrollback
<jdub> yo fabbione 
<fabbione> yo jdub
<jdub> your latest kernel built correctly, but doesn't seem to be in the archive - is that right?
<mdz> presumably it's in queue/new
<fabbione> jdub: dunno.. i woke up 2 minutes ago
<jdub> oh, abi change?
<fabbione> the kernel could be in new
<fabbione> jdub: yes.. i had to force an abi change
<fabbione> because i couldn't verify the abi on all arches for my mistake
<fabbione> and given that it wasn't used for d-i yet
<fabbione> the abi change was relatively cheap
<fabbione> mdz: mind to give it some NEW love?
* jdub hugs /srv
<mdz> fabbione: you were saying before that it was too much trouble to change the ABI version, and now you're doing it when it may not even be necessary?
<jdub> mdz: so that printing stuff ends up being two new packages and a cups patch
<mdz> jdub: if you could attach the details to PrintingRoadmap, that'd be great
<jdub> ok
<fabbione> mdz: it is trouble once the kernel is default and * is using it
<fabbione> mdz: because * needs to be rebuilded
<mdz> there is no *
<fabbione> mdz: that's why when i realized yesterday that the ABI checker was not kicking in because of an error in debian/rules, i did bump the abi
<fabbione> and it still needs NEW love
<fabbione> it was either delay another day or safe upload with NEW love
<fabbione> i opted for the latter given that * is not there
<mdz> fabbione: with the automated ABI checker, there should be no reason to have to guess
<fabbione> mdz: it didn't kick in properly.
<fabbione> the ABI checker relies on some info from the changelog/control to understand if and how needs to kick in
<fabbione> one of this info is polled wrongly
<fabbione> there is a bug that needs fixing
<mdz> so it has never worked?  or it only broke with this version?
<fabbione> only for this version
<fabbione> the error was introduced when we added the ABI num to the deb version
<fabbione> i did fix it in some cases, but i missed a corner case
<fabbione> that showed to be the yesterday situation
<fabbione> basically changing deb version from 2.6.11.94 to 2.6.12
<fabbione> the rule didn't match
<fabbione> even if it is the same major upstream release
<mdz> ok
<fabbione> mdz: really... if i can avoid ABI changes i do.. with all my love
<fabbione> (even if for the kernel side is question of running a debian/rules target ;))
<jdub> mdz: done, probably worth asking pitti to at least review it (being hal/cups foo)
<mdz> jdub: pitti is overloaded already; that's why he's off PrintingRoadmap
<jdub> mdz: 'at least review' :)
<mdz> jdub: how about having someone upstream take a look?\
<jdub> upstream for...?
<jdub> colin is going to propose eggcups for gnome 2.12
<jdub> but the cups/hal/d-bus stuff crosses too many borders to have 'upstream' look at it
<jdub> easy are not co-operative on these things
<mpt> jdub: ping
<jdub> mpt: pong
<mpt> jdub: What's the next step for fixing the help situation? Do I pester shaunm, or do you, or do we pester someone else, or what? :-)
<jdub> i think shaun's wheels are spinning at the moment because he's trying to solve problems further down the stack
<Amaranth> mpt: shaunm might bite you, I'd suggest pestering someone else :)
<mpt> I don't taste *that* good
<mpt> jdub: down as in scrollkeeper?
<jdub> replacing it, yeah
<mpt> o
<jdub> might be worth asking him what his timeframe for document-as-index is
<mpt> ok
* Amaranth hopes hierarchical spatial gets into 2.12
<mpt> Amaranth: the twisty outline?
<Amaranth> http://www.gnome.org/~martink/2005/stuff/Screenshot-nautilus-hierarchical.png
<mpt> yah
<mpt> Mac OS 8.0
<Amaranth> you're a pre-OS X mac fan, you should love it :)
<mpt> haha
<mpt> I'll still push my "View" > "as Browser" idea to anyone who will listen
<Amaranth> that isn't there right now?
<Amaranth> i don't use spatial so i dunno
<Amaranth> *groan*
<Amaranth> i just found my long list of 'things to hack on' for last week
<Amaranth> didn't touch a single one
<mpt> No, to view the current folder in a browser window you have to (1) open the *parent* folder, (2) find the folder you want, (3) right-click on it and choose "Browse"
<mpt> it's ridiculous
<Amaranth> *boggle*
<fabbione> hey pitti
<pitti> Hi again
<pitti> network failed
<pitti> cu later, breakfast
<mpt> People arguing whether spatial or browser is better is like people arguing whether spanners or screwdrivers are better
<cartel_> no its like people arguing blondes or brunettes are better
<cartel_> its whatever works for you
<cartel_> but a silly thing like developers making lockin to spatial because they like it more is retarded
<mpt> It's not locked in, there's a checkbox for it, but it assumes you want to use it all of the time or none of the time
<cartel_> i strongly dislike spatial browsing
<mpt> sometimes you need a spanner and sometimes you need a screwdriver.
<mpt> I'm not surprised, spatial browsing is an oxymoron.
<cartel_> sometimes you need a blonde and sometimes a brunette
<Amaranth> users seem to want browser mode
<Amaranth> i want OS X finder mode :)
<cartel_> death to recycling of osX "usability"
<cartel_> finder is a steaming pile
<mpt> OS X Finder mode = "leave bugs unfixed for years in an attempt to stop people from using the Finder"
<Amaranth> OS X Finder minus bugs of course
<cartel_> mac os usability == "do it this way"
<cartel_> kde usability == "do it your way"
<Amaranth> mpt: it was all a conspiracy to make people really love spotlight
* mpt shudders at the thought of KDE
<Amaranth> cartel_: kde usability == "what's usability?"
<cartel_> mpt: blondes and brunettes...
<Amaranth> KDE gives you a million options and leaves it up to you to figure out what they are and find the best one
<cartel_> Amaranth: cant we just all get along
<Amaranth> i'm sure power users love it
<mpt> cartel_: then KDE is a skinhead wearing a blonde wig and a brunette wig and a redhead wig, on top of each other
<cartel_> Amaranth: i suppose i can be considered a power user, but i find it intuitive
* mpt runs
* cartel_ dccs mpt a blonde gnome for his pleasure
<Zomb> Amaranth: that is okay this way. Better than Gnome fanatics that strip anything away that may be too complicated for "I just wanna print" users.
<cartel_> i just wanna eat pie
<mpt> mmmmm, pie
<Amaranth> Zomb: The application should try to Do The Right Thing, not punt and offer a checkbox.
<Zomb> Amaranth: hahaha, who defines "the right thing"?
<cartel_> Amaranth does
<mpt> Zomb: In theory, stopwatches and electrodes
<mpt> In practice, stopwatches and electrodes are expensive, so people argue about it on IRC and mailing lists instead
<Amaranth> mpt: Usability testing?
<mpt> yup
<Amaranth> novell... :)
<mpt> The other thing that's expensive is implementing the multiple options to test in the first place
<cartel_> novell hooked miguel up to a chair?
<Amaranth> iterative design + usability testing for each iteration == $$$$$$$$$$$$$$$$$$
<cartel_> i knew it!
<mpt> Amaranth: Even iterative design will only get you towards a local maximum on the usability graph, not towards a global one
<Amaranth> ah, the lovely *whoosh* sound of something going over my head
<cartel_> z00000m
<cartel_> mpt: have you seen kde plasma project?
<Amaranth> cartel_: vaporware
<cartel_> Amaranth: top kde hackers are working on it
<mpt> Amaranth: Well, imagining doing iterative improvement on something with a really non-standard interface, like (afaik) Lotus Notes or Quark XPress
<Amaranth> cartel_: If it isn't available in usable form you can't use it in comparisons
<cartel_> Amaranth: plasma is ~kde4
<cartel_> Amaranth: ok, given
* Amaranth hates it when people talk about how cool longhorn is
<mpt> Amaranth: you'd improve it somewhat, but you wouldn't improve it nearly as much as starting off with a much better design.
<cartel_> Amaranth: sorry
<Amaranth> it doesn't even exist yet
<cartel_> good point
<mpt> cartel_: no, I haven't
<Amaranth> mpt: ok, i sort of understand
<mpt> Amaranth: You'd have to get worse before you got better.
<cartel_> well as amaranth said, its vaporware at this stage
<cartel_> is usability testing what causes osX to mutate between versions?
<mpt> Like descending K2 before you can climb Everest
<cartel_> rendering documentation useless?
<mpt> cartel_: afaik, Apple disbanded their usability testing team about 2002 or so
<Amaranth> OS X seems to be on a downward spiral
<cartel_> mpt: k2 is significantly more difficult to climb than everest. everest is just taller
<cartel_> (just so you know)
<mpt> cartel_: We're talking about altitude, not difficulty :-)
<cartel_> mpt: people climb everest and go "woohoo!" then they go to k2 and die.
<Amaranth> they ignore their own guidelines and keep churning out weird new interfaces
<Amaranth> like brushed metal
<Amaranth> and now plastic
<mpt> Yes, Apple's been on a downward spiral since about 1998
<cartel_> but the problem was their interface has always been crap
<cartel_> they just say its the best
<mpt> Most geeks haven't noticed that much because they've been all "ooh, Aqua, shiny"
<cartel_> and people buy into it
<mpt> cartel_: Both statements are true :-)
<Amaranth> btw, i never knew you could drag Classic finder windows to the bottom of the screen and dock them
<cartel_> apple is 99.99% product
<cartel_> er
<cartel_> 99.99% marketing hype
<cartel_> and 0.01% product
<mpt> Amaranth: since OS 8.0, yeah
<cartel_> is what i tell my customers
<Amaranth> i wish i would have known that, that sounded like an awesome feature
<mpt> Mac OS interface design jumped the shark about 8.5
<mpt> (imho)
<Amaranth> <--started on an Apple II, then whatever the first powerpc was
<cartel_> its like they take everything good about freebsd out
<cartel_> then get a bunch of developers to shit in a barrel
<Amaranth> you can't deny that OS X is far ahead of anything we have though
<cartel_> then they put the shit in a pretty box and people go "ooh, aah"
<cartel_> Amaranth: in terms of what? eyecandy?
<mpt> "In Dec. 1996, Steve Jobs returned to Apple. In 1997 Apple's Human Interface Group was disbanded. By mid 1999 the Quicktime 4.0 Player was the first Apple product to be inducted into the now defunct Interface Hall of Shame by Isys Information Architecture."
<Treenaks> I remember the first time I used a mac classic... I suddenly knew where MS had stolen W95
<Amaranth> mpt: qt 4 was the 'real stereo' one, wasn't it?
<Amaranth> with the wheel volume control and all that crap?
<HrdwrBoB> yes
<HrdwrBoB> it's homo
<mpt> Amaranth: yeah, the wheel volume control and the first appearance of brushed metal
<Amaranth> btw, does anyone know is apps can still go behind the dock in the latest OS X releases?
<cartel_> mpt: do you work in linux?
<Amaranth> err, if apps
<cartel_> mpt: i notice you are .nz
<mpt> Treenaks: On the other hand, OS 8~9's 3-D appearance was copied from Win95
<cartel_> mpt: asterisk?
<Treenaks> mpt: yes, and gnome and kde copy bits of both :)
<mpt> cartel_: I work for Canonical, but the stuff I do for Ubuntu is voluntary
<Amaranth> KDE is mostly windows, gnome is mostly classic Mac OS :)
* mpt waits for his Launchpad tree to finish updating
<Amaranth> that's why i started using gnome, it was more like a mac
<cartel_> mpt: ahh cool
<cartel_> Amaranth: kde is windows-esque by default
<cartel_> Amaranth: but the reality is, it is whatever you want :)
<mpt> It's somewhat ironic that KDE is the only one that lets you have a global menu bar
* mpt pouts
<Amaranth> cartel_: as soon as kicker stops looking like ass i might use it from time to time :)
<Amaranth> mpt: heh, but their implementation is horrid
<Amaranth> plus it only works for QT apps
<cartel_> Amaranth: kicker rip. slicker is the new black
<Lathiat> i wonder if kde works yet
<Amaranth> Lathiat: I successfully installed kubuntu-desktop 2 days ago
<Lathiat> last timei tried it, i ended up with a volume down onscren stuck on my display
<cartel_> breezy?
<Lathiat> because for some reason it thought mjy volume down key/action was being triggered
<Amaranth> yeah
<Lathiat> and i couldnt do anything about it
<Lathiat> (hoary)
<Amaranth> hey, cool
<cartel_> yeah im loathe to upgrade even though i can help
<Amaranth> my volume up is paste
<Lathiat> so, i gave up even bothering to try kde
<cartel_> (im using kubuntu here)
<Lathiat> granted the kubuntu livecd worked
<Lathiat> but installing kubuntu-desktopdidnt
<Amaranth> cartel_: I successfully went from hoary to breezy with no extra hacks
<Amaranth> today
<Lathiat> and i also couldnt find anywhere to turn this OSD thing off
<Lathiat> or anywhere to setup keyboard shortcuts
<Lathiat> oranything
<Lathiat> and it was a hard on top window, so it made it useless:)
<Amaranth> Lathiat: all buried in kcontrol or something
<cartel_> Amaranth: heh, im using kubuntu as my main work machine now, i cant really afford to have downtime. i can set up a breezy NX server for testing tho
* Lathiat downloads kubuntu-desktop again
<Lathiat> cartel_: BREEZY HAS NO BUGS
<Lathiat> LA LA LA
<cartel_> speaking of which
* cartel_ goes back to trying to work out how ubuntu winbind is so broken
<mpt> zarro boogs
<Lathiat> it just has rather annoying features. :)
* cartel_ makes the "hear no evil" sign at Lathiat
* Amaranth beats ubuntu
<Amaranth> damnit, take my root user theme so synaptic doesn't look like ass!
<cartel_> oh yeah
<cartel_> the no root paradigm has thrown a few people i tried to get into ubuntu
<cartel_> the installer should have an option to set up a root account
<mpt> why?
<jdub> Amaranth: that should work seamlessly as long as you are not using a user-installed theme
<cartel_> for purists
<Lathiat> cartel_: its not needed
<cartel_> the first thing i did was add a root user
<Lathiat> all they have to do is sudo passwd root
<Amaranth> jdub: i install clearlooks from source
<jdub> cartel_: if someone knows they need a root account, they'll know enough to set it up
<Amaranth> err, installed
<jdub> Amaranth: there you go
<cartel_> Lathiat: tell that to my coworker who totally owned a major isp here by hijacking sudo
* kafeine marilyn manson - the fight song
<Lathiat> cartel_: bad admin :)
<Lathiat> cartel_: they can disable it if they like
* Lathiat conveniently ignores the recent sudo vuln
<cartel_> lol
<Amaranth> wait, i deleted that install
<Amaranth> because i wiped /
<cartel_> if this wasnt so geeky that would be bashable
<Lathiat> heh
<cartel_> jdub: this is true, but a "classic root" option is nice
<cartel_> "Do you want to create a root user now?" 
<Amaranth> yay, synaptic doesn't look like ass anymore
<Lathiat> bad
<jdub> cartel_: that question would mean absolutely nothing to 99% of users
<Lathiat> read what jdub said earlier :)
<cartel_> because in a way you are treating your users like dell does
<cartel_> they are too stupid to be trusted with an administrator account on their own pc
<Lathiat> wrong
<cartel_> just my thoughts
<HrdwrBoB> correct and also incorrect
<jdub> cartel_: if someone knows they need root, they can easily find out how to re-enable it
<Lathiat> 'sudo' replaces that
<HrdwrBoB> the users don't need another account, and they have full access via sudo
<Amaranth> dell gives their users root by default
<cartel_> remember also, many users are used to the administrator paradigm from windows
<Amaranth> well, Administrator
<Amaranth> windows has sudo too
<Amaranth> they call it Run As
<cartel_> "huh? no admin account?"
<cartel_> its also not clear in the installer that you sudo to get root
<jdub> it's very clear
<jdub> it's stated very, very clearly
<HrdwrBoB> cartel_: you mean aside from the message that explicitly states it
<HrdwrBoB> that you didn't read
<jdub> in the installer
<cartel_> ive had a few people i gave the cd to install and think they skipped the part for setting root password
<cartel_> then reinstall
<jdub> they didn't read
<cartel_> then tell me the installer was broke
<jdub> that's fine
<cartel_> HrdwrBoB: no, ive read d-i enough for one lifetime unfortunately :p
<Amaranth> tseng: could i get the inotify'ed muine goodness from you again?
<Lathiat> the installer does tell you
<jdub> there's no point muddying it up for everyone else because a small percentage of people don't read and care about using root directly
<Lathiat> so its their fault for not reading
<cartel_> admittedly i dont read it anymore i do it by feel :p
<cartel_> neither do my coworkers
<cartel_> hehe
<cartel_> but we are all hardcore debian vets
<cartel_> perhaps a notice: "to enable classic root functionality, type: sudo passwd"
<jdub> dude
<jdub> we make it clear how to use sudo
<jdub> there's no point encouraging people to re-enable root, however
<Treenaks> cartel_: a) it's on the wiki; b) your coworkers should read
<jsgotangco> +1
<jdub> those who need it know it
<cartel_> heh
<jdub> those who don't, don't care
<cartel_> hmm
* cartel_ tests something
<torkel> and everyone else does sudo su :-)
<Amaranth> eww
<jdub> sudo -i in hoary :-)
<cartel_> yeah question
<cartel_> if there is no root at all
<Amaranth> sudo -i?
<cartel_> why have /root?
<Amaranth> i always do sudo -s -H
<jdub> there is a root account
* Amaranth reads the man page
<jdub> it is locked
<jdub> when you sudo -i, you are switching to the root account
<jdub> you need /root
<cartel_> so no changes made to roots environment via sudo or whatever alter /root?
<jdub> when you boot with single, you are using the root account
<jdub> you need /root
<cartel_> but you dont
<cartel_> you've removed the root paradigm and replaced it with sudo
<jdub> dude
<jdub> there is no paradigm here
<jdub> there is no replacement
<cartel_> and you're saying that people in the know should know
<jdub> the root account exists, but it is locked
<jdub> "enabling" root is merely a matter of setting the password (thus unlocking it)
<jdub> you can't say "root doesn't exist" - that isn't true
<cartel_> at the very least, load the profile from the current user when doing -i
<jdub> ah, dude, read the man page
<jdub> that's almost entirely what -i intends to avoid
<cartel_> but you dont want people using /root
<infinity> Letting your environment leak to root processes is a rather bad idea.
<cartel_> i dont get it
<jdub> cartel_: /root has nothing to do with it
<cartel_> roots profile is in /root yes
<jdub> we lock the root account so you can't directly log in to it - it has no password
<jdub> when you type "sudo blah", you are running blah *as root*
<cartel_> i know this 
<jdub> it's not magic privilege land
<Amaranth> should i consider http://dev.realistanew.com/aboutubuntu.png to be a bug?
<Amaranth> (there is no title for the selected topic)
<jdub> Amaranth: yeah
<Amaranth> hmm
<Amaranth> now to figure out if i should file it under yelp or gnome-panel
<cartel_> so its not that ubuntu doesnt use root, its just that the installer configures sudoers
<jdub> Amaranth: ubuntu-docs
<cartel_> and doesnt set root pw
<cartel_> thats the only difference other than init is patched to allow logins via sudo
<cartel_> for single user mode
<cartel_> correct?
<jdub> that's sulogin, nowt to do with sudo
<HrdwrBoB> but yes
<cartel_> sorry sulogin
<HrdwrBoB> basically
<Amaranth> https://bugzilla.ubuntu.com/show_bug.cgi?id=7454
<Amaranth> that's odd
* Amaranth doesn't have editbugs priv so he can't reopen it
* Amaranth looks for mdz, ogra, or kiko
<whiprush> jdub: fridge!
<torkel> jdub: did we (maswan and I) ever get any response to our kerberos, ldap, afs (and lustre) requests?
<cartel_> ooh
<cartel_> what requests?
<cartel_> kerberising ubuntu?
<whiprush> jdub: hey did you respond to that guy that mailed us about an ubuntu newsletter? If not I can do so now.
<jsgotangco> sabdfl, hi
<whiprush> hi sabdfl 
<sabdfl> morning all
<Treenaks> hi sabdfl 
<Amaranth> hi
<fabbione> hey sabdfl 
<pitti> Morning sabdfl 
<Amaranth> um, was I the first member to ever be accepted without actually being at the CC meeting? :)
<Lathiat> now why doesn't everyone greet me like that
* Lathiat sulks
<whiprush> hi Lathiat!
<cartel_> you're not important enough
<pitti> Good monring Lathiat, how are you?
<cartel_> whois sabdfl?
* Lathiat laughs
<cartel_> upl?
<cartel_> ada?
<Lathiat> pitti, whiprush :)
<sabdfl> cartel_: me ;-)
<fabbione> cartel_: god of ubuntu?
<cartel_> kekeke?
<cartel_> s/?/!
<whiprush> cartel_: self appointed dictator for life.
<sabdfl> fabbione: that would be mdz
<pitti> benevolent!
<whiprush> oops, missed that part. :)
<sabdfl> whiprush: it comes and goes
<cartel_> mws? (it is w isnt it?)
<fabbione> sabdfl: right :) do you prefer God of Ubuntu's Gods ;)
<whiprush> geg
<whiprush> heh, even.
<sabdfl> r, sadly
<sabdfl> for Wichard
<cartel_> lol
<jsgotangco> ?
<cartel_> file a bug report on your name
<crimsun> bugzilla tied to a councillor? I dare not think of the ramifications.
<Amaranth> MOTU sounds cooler than sabdfl :)
<cartel_> torkel: im genuinely interested in ubuntus direction considering kerberos/ldap
<cartel_> torkel: please elaborate
<whiprush> torkel: have you had a chance to go over the specs on udu.wiki.ubuntu.com?
<whiprush> er, I mean cartel_ 
<cartel_> torkel: since i wanted to make a strike force with the goal of single signon for debian
<cartel_> whiprush: cant find
<cartel_> whiprush: im grepping for ldap
<whiprush> sec
<whiprush> http://udu.wiki.ubuntu.com/WindowsInteroperability
<whiprush> probably a good place to start
<cartel_> oh
<cartel_> pff
<Amaranth> why do people troll uncontrollably whenever mono is mentioned?
<whiprush> http://udu.wiki.ubuntu.com/NetworkAuthentication also
<cartel_> whiprush: samba 3 already participates completely in active directory
<infinity> cartel_ : As a client.
<cartel_> whiprush: most of this stuff is doable immediately no need for samba 4
<infinity> cartel_ : Not as a server.
<cartel_> infinity: yes participate implies client
<torkel> cartel_: basically we were asking if it is possible to get kerberos, ldap _and_ AFS supported i ubuntu main (and hopefully at least the kernel part of Lustre)
<cartel_> why the hell do you want afs
<whiprush> heh, I was about to say "hang out until infinity is around".
<cartel_> have you ever experienced the hellish world of afs?
<cartel_> skip afs and go to gfs
<torkel> cartel_: what else do you want to run as a distributed filesystem?
<whiprush> gfs is in breezy already
<torkel> cartel_: yes. We are running it since some years (and DFS before that)
<cartel_> afs is insufferably slow and has very large shortcomings
<infinity> whiprush, cartel_ : I'm about to kick WindowsInterop into high gear in the next week.  It's a LowPrio task for me, but I intend to squeeze as much hacking/testing into my gap times as possible, so we'll see where this spec goes pretty soon.
<infinity> whiprush, cartel_ : Some stuff is stuff I see as "must have" for breezy, but a lot of other things probably won't happen without community hacking/input.
<cartel_> infinity, torkel, whiprush: i was hoping you were going to package the recently released netscape ds 
<cartel_> because if you want an ldap server, you want multi master replication if you can get it right
<Amaranth> ha
<Amaranth> does it even build?
<cartel_> and exop schema updates
* infinity hasn't been looking at the Netscape DS at all..
<cartel_> Amaranth: on fedora
<cartel_> :/
<cartel_> Amaranth: actually i havent given it a shot yet
<whiprush> infinity: cool. NetworkManager has support for the cisco vpn stuff according to thom (he hasn't built it yet though), maybe they'll get around to doing pptp for it.
<cartel_> Amaranth: if i did, i would want to debianise it from scratch
<cartel_> Amaranth: which is likely a very masochistic thing to do
<Amaranth> it'll probably be completely rewritten over 5 years as NuServer then have the name changed to something else
<whiprush> infinity: that friend of mine I've been meaning to get ahold of you has built the Fedora DS. 
<cartel_> its fedora directory server
<whiprush> it's not trivial unfortunately.
<cartel_> whiprush: good news!
<cartel_> whiprush: bad news!
<infinity> whiprush : Yeah, I cought that in scrollback.  I happen to have a Cisco VPN here to test with, so I'll play with it shortly.  Doing PPTP should be simple, since we can support it as a PPP-type connection.
<Amaranth> cartel_: I was making fun of the last dump of code from netscape.
<cartel_> anyway, hacking up some kind of ldap/kerberos infrastructure that you can automagically promote (sorry using windows server terminology) to would be ++cool
<Amaranth> doublepluscool
<cartel_> Amaranth knows newspeak
* Amaranth can't remember any more newspeak
<Amaranth> minlove?
<infinity> cartel_ : I have some ambitious plans for that sort of thing and more.  I need to make some time to sit down and write more detailed specs, I think, so people can contribute in areas I just plain don't have time for.
<cartel_> mini
<whiprush> our LocoTeam has started working on a gnome kerberos ticket manager if anyone is interested: https://anthracite.aca.oakland.edu/websvn/listing.php?repname=Kerberos%20Ticket%20Manager&path=%2F&rev=0&sc=0
<cartel_> infinity: cool, thats something i am into. well i dunno for how long, im sure once i get into hardcore identity management ill want out fast
<infinity> Man, if Microsoft marketing knew what I did with my Partner status, they'd cry.
<Treenaks> infinity: what do you do with it? :)
<pitti> sjoerd: ping
<cartel_> i can already do single sign on ads clients
<infinity> Treenaks : Short term, make competing OSs work better with Windows, Long term, make them replace Windows.
<infinity> Treenaks : I can't see how they're keen on either of those. :)
<cartel_> but a server... 
<Treenaks> infinity: ;)
<torkel> whiprush: re NetworkAuthentication, maybe a note that Kerberos 4 should be dropped as it is unsecure at design level
<cartel_> ;)
<whiprush> torkel: the spec is public, add/change what you need, I'm pretty kerberos stupid so I have no idea what you mean. :)
<cartel_> infinity: did you eventually get keysigned?
<infinity> cartel_ : By whom?
<cartel_> infinity: a dd
<torkel> whiprush: http://www.kb.cert.org/vuls/id/623217
<cartel_> infinity: i see the fingerprint in your whois
<infinity> cartel_ : ...
<infinity> cartel_ : I got my key signed by a DD about 4 years ago... Then become one shortly thereafter...
<cartel_> infinity: then i see back in 2002 you were having problems getting signed
<infinity> cartel_ : Are you confusing me with someone else? :)
<torkel> whiprush: so you mean I have to remeber if I ever created a wiki account? :-)
<cartel_> ahh :)
<cartel_> getting signed is one of my goals for this year
<whiprush> torkel: heh, well, things like that go with the territory. :)
<infinity> cartel_ : Well, come visit me in Melbourne for a beer, and I'll sign yours.
<cartel_> tho i think i might have problems because vorlon thinks i am a bot 
<pitti> Hi carlos
<carlos> morning
<cartel_> alright, time to get some kai and head home after another 10 hour day
<torkel> whiprush: KTM looks interesting
<cartel_> later
<whiprush> torkel: currently three students are working on it, so if you've got expertise in the area, we'd appreciate it. :)
<torkel> whiprush: well, I can probably come up some ideas to give them more work :-)
<Amaranth> wow, i almost got redhat's system-config-services running
<whiprush> Good Enough(tm)
<Amaranth> i got a flash of GUI this time at least :)
<Amaranth> http://www.cs.man.ac.uk/~brejc8/temp/sevices.png
<Amaranth> would you guys be interested in something like this?
<whiprush> infinity: is there anything in the interop spec that you would like me to research?
<Amaranth> (i can do some deuglify work on it)
<whiprush> some of them are kind of impossible:  "Find a GUI that allows management of samba server features, like promotion / demotion of Domain Controllers."
<infinity> whiprush : A lot of it is kinda hand-wavey... It was just people babbling at a table and jbailey furiously taking notes, afterall. :)
* netjoined: irc.freenode.net -> orwell.freenode.net
<infinity> whiprush : And since it was LowPrio, it didn't get a lot of love afterward.
<infinity> whiprush : I'll try to go over it in the next week or so and spruce it up.
<infinity> whiprush : If you want to pester me via mail/IRC next week as a reminder, I won't mind terribly much. :)
<whiprush> okey
<whiprush> I have this strange feeling that for all the samba stuff you're just going to get more "here's my script for setting it up".
<Amaranth> wait, this is what BUM does
<infinity> whiprush : <shrug>... Some stuff can be handled fine by weird scripts.  Some stuff is going to need some real development time (that won't be done by me, -ENOTIME)
<infinity> whiprush : And some stuff is just a matter of someone taking the already working pieces and making them work together.  That's the stuff that's more realistic for breezy.
<torkel> whiprush: from where can I check out KTM? instead of fetching it via websvn
<whiprush> well, I think the vpn stuff will make it into NetworkManager, I don't think there's much value in moving to MS-native formats as a default, and the samba stuff we're in the same boat as everyone else, waiting for for 4.
<whiprush> torkel: we just started two weeks ago, mail me at jorge@whiprush.org and I can link you up with the guys working on it. For now I must sleep though
<whiprush> nite everyone
<torkel> whiprush: sure. And nite!
<\sh> morning
<sivang> morning all
<pitti> Hi sivang, hi \sh
<sivang> pitti: Hi martin, what's up?
<pitti> nothing really exciting by now
<\sh> to early
<\sh> but actually i solved my connection problems with my jabber server
<pitti> infinity: mind if I take #9884 (cupsys merge) from you?
<infinity> pitti : I never uploaded that?  I suck.
<pitti> infinity: oh, you already merged?
<infinity> pitti : Take it if you want it.  He changed patch systems, and the merge is hideously broken, so watch out for that. :)
<pitti> infinity: Kenshi applied many of our patches and I want to do a bug fix
<infinity> pitti : I think I have it mostly-done lying on my hard drive here.
<pitti> infinity: I want to merge manually
<pitti> infinity: there's no point in taking MOM outut (most outputs with a _debian.dropped are worthless)
<pitti> infinity: can I get your version for a start?
<infinity> pitti : Looks like I just got as far as filtering the worthless diff from MOM into something more manageable, then got distracted by something shinier.
<infinity> pitti : So you may as well go ahead and start clean, if you were doing it by hand anyway.
<pitti> infinity: ok, then I merge manually
<infinity> pitti : I just recall filtering out 3MB worth of uuencoded scariness. :)
<pitti> hehe
<thom> morning
<pitti> Hi thom!
<daniels> morning mr may
<infinity> thom : I need to go out tomorrow and take a picture for you.  There's a restaurant 3 blocks from my house called "Thomay"
<thom> infinity: rock! my fame is widening
<daniels> thom: they've always been a little bit weird in armadale
<\sh> ??? what's up now
<\sh> dpkg-source: error: unrecognised file suffix `.tar'
<\sh> Entpack-Befehl dpkg-source -x gdome2-xslt_0.0.6-7.dsc fehlgeschlagen.
<thom> you're trying to use a native package with a debian/ubuntu revision
<\sh> no
<\sh> it's in our tree
<\sh> http://archive.ubuntu.com/ubuntu/pool/universe/g/gdome2-xslt/
<daniels> \sh: yes, and it's broken
<daniels> \sh: if it has a non-native version (i.e. 1.2.3-4, x.y.z-a), it needs to have a .orig.tar.gz
<daniels> the only case where you can't have a .orig.tar.gz is where it's Debian-native, so you just have 1.2.3 or x.y.z
<daniels> i don't know how this package got in anyway
<\sh> daniels: the dsc files mentions the native file ... and the other versions are looking the same
<thom> \sh: it used to allowed, although it was nearly always a mistake
<thom> no it's not
<\sh> well, i don't mind a native package or whatever, problem is, i have to work with this package...if it's not working with me, well, then I have a coffee and a cigarette first :)
<\sh> brb
<pitti> Hi Keybuk 
<Keybuk> mornin
<daniels> sup scotty
<pitti> Keybuk: in MOM, would it be feasible to always prefer Debian changes over Ubuntu changes?
<Keybuk> only apply the patch one-way?
<Keybuk> or do you mean something else?
<pitti> Keybuk: in most cases where there is a large debian_dropped it makes the output rather useless and requires manual merging
<Keybuk> right
<pitti> Keybuk: yes, only try to apply the Ubuntu changes to the new debian package, and not the other way round
<Keybuk> it tries it both ways
<Keybuk> and gives you the smallest dropped
<pitti> Keybuk: although the Debian dropped might be smaller, it should always be a goal to prefer the Debian solution
<pitti> if it does the same thing in a different way
<pitti> (IMHO)
<pitti> other folks might have different experiences, though
<Keybuk> nah, it varies on a source-by-source basis which works best
<elmo> PEOPLE
<pitti> elmo!
<elmo> uploads named 1buntu1 DO NOT STOP THE AUTOSYNCer
<elmo> OUR NAME IS 'ubuntu'.  THAT IS ALL
<Keybuk> onebuntu ... that's a great derivative name
<infinity> Keybuk : "smallest" is relative... In some cases (*cough*cupsys*cough*), #MB versus 3.1MB is both "really big".
<daniels> elmo: what about -1ubunto1?
<Keybuk> infinity: patches welcome ;)
<daniels> o/~ you can't stop the autosync
<Lathiat> heh i have a friend that keeps saying ubunto
<infinity> s/#MB/3MB/
<fabbione> elmo: morning dude..
<pitti> infinity: in fact the big difference is the result of moving a big uuencoded file into debian/local
<infinity> pitti : Yeah, I noticed.
<pitti> infinity: I think I will just leave the Debian location for now, otherwise this will never end
<pitti> elmo: which package was that?
<infinity> pitti : Well, if you hand-merge your changes to the new Debian version, our patch becomes... Tiny.
<pitti> right :-)
<infinity> pitti : Since he incorporated mst of your stuff, just not all of it.
<pitti> infinity: well, not tiny, but manageable
<infinity> Pretty dang small.
<infinity> (The switching of patch systems between merges also messes with one's head in a seriously nasty ways)
<pitti> infinity: according to the changelog, Debian wants to deroot it soon, too, *then* it will become small
<infinity> s/in a/in/
<infinity> pitti : Ping him about it.  He'll probably deroot it right now, if you remind him.
<infinity> pitti : I'm sure he just didn't want to do it pre-Sarge.
<pitti> "User 'cupsys' feature and Browsing feature aren't applied at this time.
<pitti>      They are post-Sarge things"
<pitti> right
<elmo> pitti: devilspie
<pitti> ok
<mpt> ffs, who decided that Ctrl+Z in Gaim should be Minimize rather than Undo
<torkel> someone used to emacs?
<mpt> This is why Gnome should have decided on Alt rather than Ctrl for its keyboard commands
<mpt> then the emacs people could happily use their Ctrl+ combos without getting in the way of the other 99.8%
<mpt> anyway
<daniels> mpt: well-argued
<Lathiat> mpt: ^W not being delete-word in most things (being close window) is also extremely irritating
<mpt> (not to mention that Alt+whatever is a lot easier to reach than Ctrl+whatever for the sort of people who don't know how to switch Ctrl and Caps Lock)
<mpt> Amaranth: If bug 7454 is the same as the bug you see, attach your screenshot to the bug report, and I'll nag kiko to reopen it when he's awake
<infinity> I have my pinkie trained to live on the Ctrl key...
<mpt> Lathiat: I can imagine
<Lathiat> this is part of the reason why i dont use x-chat :)
<fabbione> maswan: ping?
<Lathiat> -h
<Amaranth> mpt: done
<mpt> ta
* Amaranth goes back to his movie
<maswan> fabbione: pong?
<pitti> infinity: after cleanup and throwing out everything Kenshi already applied, we are down to 1392 patch lines; still not "tiny" :-)
<pitti> Hi seb128 
<seb128> hey pitti 
<infinity> pitti : I thought I had it smaller than that, but maybe not..
<pitti> infinity: still. 58 kB vs. 3 MB is an improvement :-)
<mpt> infinity: Were there were some spare bounty hunters wanting to work on GraphicalConfigTools? Perhaps they could be put to work on the domain controller and VPN stuff
<infinity> mpt : I think the VPN stuff will be mostly covered by NM, if we can get all the magic right.
<infinity> mpt : DC guis probably need someone to spec out requirement before I let loose the bounty hunters on them.
<fabbione> maswan: is buttercup down?
<fabbione> maswan: i can't ssh to ti
<fabbione> it even
<mpt> infinity: I'd love to do that, but first I'd need to understand the problem :-)
<maswan> fabbione: it seems to apparently have died for some reason
<fabbione> maswan: ah ok
<fabbione> can you resurrect it?
<infinity> mpt : As I stated up there <points>, I intend to give WindowsInterop some TLC next week, so I'll see about speccing some stuff and getting bounty approval for some things.
<maswan> hmm.. the console doesn't respond either
<fabbione> that's bad...
<maswan> ok, so some keyturning later on, then it'll hopefully boot ok
<infinity> mpt : Anything that's in the "stuff to mangle samba 3 configs" realm will probably just get ignored, cause I don't want to bounty that sort of work when we'd end up throwing a bunch of it out for samba 4...
<mpt> fairy nuff
<fabbione> maswan: no hurry please :)
<fabbione> maswan: we are in really good shape :)
<maswan> fabbione: :)
<infinity> mpt : But I might consider speccing some bounties for samba4 tools.  I could package the current devel branches so people can play with them.
<fabbione> maswan: yesterday buildd'
<fabbione> maswan: yesterday buildd's where idling for the first time in a year or so
<maswan> fabbione: neat :)
<fabbione> yeah so i gave back the 800 pkgs in dep-wait/FTBFS :P
<fabbione> we don't want them to cool down.. do we? :P
<Keybuk> mdz: can I have editbugs privilege, or can we get an account just for mom? :p
<maswan> heh. of course not. :)
<infinity> Keybuk : An account just for MOM would be nice anyway, to separate you from the tool.
<fabbione> infinity: why? 
<fabbione> do we really care when Keybuk files a bug? :P
<infinity> fabbione : Just cause? :0
* fabbione hides
<Keybuk> actually, it may be ok
<Keybuk> it looks like I can still change aliases
<doko> Keybuk: does [hurd-any, netbsd-any]  work in build deps?
<Keybuk> actually
<Keybuk> I can change any alias I added
<Keybuk> which is probably enough for mom
<Keybuk> doko: no, not yet
<Keybuk> it will do
<infinity> doko : And even when dpkg likes it, sbuild won't.  (But I can implement it in a jiffy, once I know the spec)
<infinity> Keybuk : Will the inverse also be implemented? (arm-any, mips-any)?
<Mithrandir> infinity: [any-any] ? ;-)
<Keybuk> yes
<doko> well, []  would be interesting as well
<Keybuk> Mithrandir: any-any would probably "work", but just means the same as "any" does't it :p
<infinity> Keybuk : When you get dpkg-dev supporting these features, can you ping me via mail, so I can make sure sbuild is happy with them as well?
<Keybuk> infinity: sure
<infinity> Keybuk : And probably smack mvo to make sure apt likes them.
<doko> Keybuk: are negations planned in architecture fields? i.e. Architecture: !s390
<Keybuk> doko: architecture fields are interesting
<Keybuk> they don't really do anything right now
<infinity> (which is one of the reasons for Packages-arch-specific existing)
<Keybuk> I thought that was more just elmo being a control freak :p
<infinity> Keybuk : Well, there are a few reasons.  But ANAIS (architecture not allowed in source) is one of them.
<Keybuk> so I'm not really sure what to do about the architecture field
<Keybuk> maybe I should harass buildd admins and get them to tell me what they want from it
<infinity> I sure know how much we love harassment.
<infinity> I'm not even sure what can be done at this point.  If you have dpkg-deb --build error out when the arch doesn't match, then you break higher level packaging tools calling it.
<infinity> So the best you can do is just print a warning "not building package foo for arch bar", and exit 0.
<Keybuk> well, right now it's used by dpkg-gencontrol to do that warning
<Keybuk> "expected to see X in this changes file" vs "didn't expect to see X in this changes file"
<trulux> tseng: ping
<tseng> trulux: pong.
<Nafallo> tseng: morning :-)
<tseng> heya Nafallo 
<trulux> tseng: just talked to nohar and decided to put the SSP "poc" at http://pearls.tuxedo-es.org/poc-nox/ssp-poc-2005.tar.gz
<Nafallo> tseng: does muine work for you since yesterdays dbus update? :-)
<tseng> trulux: ah hah
<tseng> Nafallo: didnt try this, no
<tseng> trulux: what does etoh have to say?
<trulux> tseng: as everytime, nothing
<trulux> tseng: nohar didn't receive anything from him
<tseng> hm of course
<tseng> "double-injection"
<tseng> pappy always thought you could just brute-force a canary on one pass
<tseng> thanks trulux.
<trulux> pappy- is on Malibu most of the time and well, I don't care on what he says 'cos it makes sense in a reall random percentage of the times
<trulux> tseng: I have notices about a non published subversion poc that bypasses SSP
<fabbione> elmo: dpkg-checkbuilddeps: Unmet build dependencies: libc6-dev-ppc64
<fabbione> can you please install it in davis/breezy chroot?
<jdub> http://blogs.sun.com/roller/page/cmar?entry=ubuntu
<jdub> http://dunnage.blogspot.com/2005/06/ubuntu-on-freenode.html
<jdub> ^ heh
<Nafallo> wonderful :-)
<Lathiat> heh
<fabbione> maswan: if you can't repower the machine within the next hour, just leave it turned off until monday...
<fabbione> maswan: i am going soon to leave for the weened
<fabbione> weekend
<zul> but its only thursday 
<zul> slacker!
<fabbione> zul: tsk! i took one day off
<zul> hehe
<torkel> zul: it's holiday tomorrow :-)
<zul> oh....slackers!
<maswan> fabbione: sure, I'll actually go over and repower it.. oh. wait! it's a sun! I forgot, since it was running debian.
* maswan tries sending a break on the serial consoel..
<maswan> huh? no response? this is really broken then. :/
<fabbione> maswan: i have seen that here too
<fabbione> i think it's a kernel bug :(
<fabbione> (the serial thing)
<fabbione> but without 2.6 i can't build
<jordi> jdub: is that BOF from UDU regarding IRC still being "developed"? :)
<maswan> fabbione: Oh, well. I'm going over now anyway.
<fabbione> maswan: thanks
<maswan> jdub: hey, answer torkel? :)
<jdub> maswan: hrm?
<torkel> jdub: kerberos, afs, ldap (lustre)...
<jdub> torkel: yo
<torkel> jdub: you never got back to us
<jdub> torkel: yes, jbailey-gcc (gcc?) was talking to you guys about that
<jdub> torkel: i'll catch up with jbailey about it, see where it's at
<torkel> jdub: yeah, and we sent a mail with more details, but nothing happened after that
<torkel> jdub: great
<jsgotangco> night all
<Nafallo> night jsgotangco 
<maswan> fabbione:  13:04:10 up 15 min,  1 user,  load average: 0.00, 0.01, 0.00
<fabbione> maswan: great thanks
<jdub> fabbione: cluster SWEEET! :)
<Lathiat> hehe just saw that
<Lathiat> whats ocfs2 like?
<torkel> cluster nah, unless it is on Top500 it is not a cluster... :-)
<fabbione> jdub: dude.. i told you i won a big battle :)
<jdub> /usr/src/linux-headers-2.6.12-2-686/scripts/gcc-version.sh: line 11: gcc-3.4: command not found
<jdub> fabbione: ^
<fabbione> jdub: apt-get update && apt-get install kernel-package gcc-3.4
<fabbione> you should check the build-deps once in a while and not just run make build :)
* Nafallo hugs pbuilder
<jdub> i'm building Random Module :)
<ogra> torkel, fabbione _is_ in the top 500
<ogra> (even if its only the top 500 best italian cooks in denmark ;) )
<Nafallo> hehe
<fabbione> ahahha
<ogra> :)
<Lathiat> hmm, gnome-cups-manager isborked
<Lathiat> all columns of a print job come up as "Printing: job-printing"
<doko> elmo: please sync ccache from unstable
<torkel> ogra: :-)
<pitti> Lathiat: can you please file a bug? assign it to me, please
<Lathiat> pitti: okie
<Lathiat> hrm, now it wont print at all
<Lathiat> (from epiphany, test page works)
<Kamion> fabbione: is anyone doing l-r-m for 2.6.12?
<Kamion> fabbione: i.e. should I temporarily drop it from linux-meta?
<fabbione> Kamion: i am not doing it.. that's daniels' toy :P
<fabbione> Kamion: and i am leaving for VAC pretty soon
<fabbione> also .. .12 wasn't newed till this morning .. so we couldn't really do much to build l-r-m
<fabbione> i think you can safely drop it from linux-meta for a few days
<Kamion> ok, that's probably best
<Kamion> so I'll just drop the linux-restricted-modules-<flavour> deps from linux-<flavour>
<fabbione> Kamion: i guess so.. i did never touch linux-meta
<fabbione> if you want i can look at it in details
<ups> hi ogra 
<fabbione> but that sounds about right
<ogra> hey ups 
<Kamion> fabbione: s'ok, I'm happy to do it
<ups> ogra, what do i need to do to get editbugs?
<ogra> tell me who you are :)
<ups> i am ups!!!
<ups> :p
<ogra> haha
<ups> euphaar@gmail.com
<Kamion> we should probably put linux-meta in the kernel-team arch archive at some point
<ups> ogra, are there any details as to what people are doing wrong in bugzilla?
<Kamion> setting fields that are for scheduling, in an attempt to get their problem looked at sooner, or just because they misunderstood what the fields were for
<ogra> ups, its not the people, it was the setup.... people have set target milestones or assigned bugs without clue, so we want only people who understand the process doing that now
<Kamion> assigning bugs arbitrarily to the wrong people
<Kamion> filing bugs at critical/blocker when they aren't
<ogra> ups, we plan a bugday so we can see what people are actually doing and assign them editbugs rights
<tseng> any reason we are investing time into bugzilla when malone is moving over in a few weeks
<fabbione> Kamion: yes that can be done...
<ups> ok, i get it
<ogra> tseng, yes... bugzilla is what we have _now_ :)
<ups> ogra, when is the bugday coming up?
* Nafallo already started using malone ;-)
<ogra> ups, see ubuntu-devel
<ogra> ups, (the mailing list)
<Nafallo> kiko: hi kiko.
<ogra> ups, we hopewe can do the first one on 29th
<ogra> hey kiko 
<ups> ogra, yes, i'm subscribed to it
<kiko> hey ya
<Kamion> elmo: did jessica look sane to you?
<ogra> ups, i cant find any bugs you are involved with yet
<ups> ogra, there aren't many, but i did report some, and closed a very few
<kiko> how's it hanging
<ups> ogra, i just started doing it from this week
<Kamion> elmo: and do you mind if I start doing some manually-reviewed priority editing with alicia?
<ogra> kiko, downwards (except in .au) ?
<kiko> it's in full swing here
<ogra> heh
<ups> ogra, can i /msg you a (long) url for that?
<ogra> sure
* fabbione heads off for the weekend
<fabbione> Kamion: if you need anything i have my mobilephone with me
<Kamion> ok, thanks
<fabbione> cya on monday
<fabbione> and keep in mind there is a sparc around, when you are going to upload :P
<Kamion> daniels: xterm?
<daniels> Kamion: er, yeah
<daniels> sorry, I've been fixing the modular server
<ogra> ups, i added editbugs back for your account, use it sensible and wise ;)
<ups> sure, and thanks :)
<seb128> is somebody going to package pitfdll?
<ogra> seb128, what is it ?
<tseng> ogra: w32codecs loader for gstreamer
<ogra> uhh
<tseng> er... "dll loader"
<ogra> tseng, didnt you wantto package nonfree gstreamer stuff ?
<tseng> i did
<tseng> but i need to clean up the package
<tseng> for lintian
<seb128> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308101
<tseng> lame and faad/faac
<seb128> a guy packaged it for debian too
<ogra> then lets just grab it
<ogra> (if its sane)
<tseng> ill look
<seb128> thanks
<tseng> http://mentors.debian.net/debian/pool/contrib/p/pitfdll/
<jordi> looks pretty sane here
<tseng> it looks pretty sane
<tseng> yes.
<Kamion> is there a developer-use i386 hoary chroot around anywhere?
<pitti> Kamion: on concordia
<pitti> Kamion: dchroot -c hoary-i386
<tseng> hm perhaps it should not link to w32codecs
<tseng> in the README
<tseng> did we ever get legal advice on this?
<Kamion> pitti: thanks
<jordi> tseng: pointing at w32codecs is just that, a pointer.
<tseng> jordi: we talked a small bit about whether or not we should be even documenting subverting patents
<tseng> jordi: it gets pretty ugly in the US at least
<tseng> 2600 got into legal hot water for linking to DeCSS iirc
<tseng> right now we have a chunk of info about the stuff sitting on the wiki
<jordi> tseng: woa
<sivang> does anybody know if ubuntu has merchendise for sell in LinuxTag ?
<tseng> sivang: ask Simira about merch
<Treenaks> Ubuntu mechs?
<sivang> Treenaks: yes
* jordi tickles Treenaks 
<sivang> I have a coworker there that can bring me some
* pitti has an urgent meeting with a lasagne
<Treenaks> hi jordi 
<tseng> pitti: yum!
<Treenaks> sivang: no I mean battle-mechs :)
<ogra> pitti, i know her, send greetings from here :)
<sivang> ogra: hey oliver
<ogra> hey sivang 
<doko> pitti: ruby1.8 FTBFS
<tseng> seb128: that package ftbfs on breezy pbuilder
<tseng> seb128: gcc4 kind of stuff
<seb128> lemme try
<Kamion> elmo: torrent@magellanic.ubuntu.com wants a password, so the trigger fails
<Kamion> elmo: I've commented it out for now
* ogra curses ffmpe (the 100000th time)
<ogra> ffmpeg
<mvo> elmo: please merge nasm from debian (override ok)
<seb128> tseng: http://cvs.sourceforge.net/viewcvs.py/pitfdll/pitfdll/gst-libs/ext/loader/wine/ext.c?r1=1.1&r2=1.2 and http://cvs.sourceforge.net/viewcvs.py/pitfdll/pitfdll/gst-libs/ext/loader/wine/win32.c?r1=1.1&r2=1.2 fix the issue
<tseng> seb128: nice find
<tseng> seb128: do you want the package, or I shoul dmail all that to myself for when I get home
<mvo> elmo: please sync bzip2 (debian took our changes)
<seb128> tseng: I would like to get that packaged for ubuntu but no hurry, I'm doing bug triage today 
<tseng> seb128: ok I will test it and give it back to you
<seb128> thanks
<ogra> error: can't find a register in class `GENERAL_REGS' while reloading `asm'
* ogra cries
<mpt> The Breezy upstream freeze is on July 7, 14 weeks before the Breezy release. Gnome 2.10 was accepted into Hoary about 1~2 days before the Hoary release. There's something obvious I'm missing. What is it?
<mvo> elmo: please sync tar (debian took our changes)
<tseng> mvo: gnome is exempt from freeze
<Nafallo> mpt: the override-function? ;-)
<tseng> mpt, rather
<mpt> tseng: ok, that's good news from my p.o.v., thanks
<ddaa> mdz: is there an uptream VCS for apt-listchanges?
<mvo> ddaa: AFAIK there is only mdz's private svn repository
<ddaa> so, there's upstream VCS but not publicly accessible, yet
<Lathiat> pitti: did that libsysfs upload fix the removable stuff
<pitti> Lathiat: yes
<Lathiat> pitti: woo :)
<ddaa> Kamion: where is the VCS for archive-copier? (if there is one)
<bob2> it's not on d-i svn?
<bob2> er, in
<ddaa> nah
<ddaa> first place I looked
<ddaa> bob2: btw, what's the rule for aspell modules?
<bob2> aspell-blah?
<ddaa> yeah
<Kamion> ddaa: it's in arch
<ddaa> hu...
<Lathiat> is it possible to configure X with a fallback driver?
<Kamion> ddaa: colin.watson@canonical.com--2004/archive-copier--mainline--0
<Lathiat> e.g. if nvidia fails, try nv?
<ddaa> I guess I should peg it in "unsupported" then :)
<ddaa> Kamion: thanks for the details
<Kamion> ddaa: you can't do arch-to-arch imports? or you aren't bothering 'cos it's silly? :-)
<pitti> doko: d'oh, that FTBFS is a tricky one
<pitti> Keybuk: here?
<ddaa> Kamion: there's some infrastructure for that (it's really just mirorring) but there's no web UI, at least.
<Keybuk> pitti: yup?
<daniels> Lathiat: nope
<ddaa> Keybuk: do you think it's correct to stuff all the aspell-blah imports in the "ftp" category, aka no upstream VCS?
<daniels> jdub: I JUST GOT THE BEST IDEA
<Lathiat> daniels: bugger
<Keybuk> ddaa: do they have an upstream RCS?
<Lathiat> daniels: im sure i saw something like that once
<daniels> Lathiat: i just realised how to do it
<ddaa> not as far as I can tell... but maybe I just missed it...
<daniels> because I'm really awesome
<Lathiat> go daniels
<Lathiat> daniels: how? :)
<Lathiat> nvidia->nv->vesa? :)
<Lathiat> ->vga?:P
<Zomb> .oO( >> EGA >> CGA >> Mono )
<Lathiat> aalib? :)
<Lathiat> over 9600 serial!
<daniels> Lathiat: when you write out the config file, put different ServerLayouts in there for the different fallbacks
<daniels> and just start the server with different layouts from gdm until you get something that works
<Lathiat> sounds good
<Lathiat> breezy? :)
<Lathiat> then we can be like windows!
<daniels> heh
<daniels> maybe breezyable
<daniels> we'll see
<Lathiat> great, evolution crashes when selecting imap4rev1 in new account
<Lathiat> doh
<Lathiat> and imap
<Lathiat> blah
<\sh> damn
* Lathiat installs thunderbird,, again.
<Lathiat> i should really move to maildir and use zapmail anda local mutt
<Lathiat> but that requires effort and probably break all my mail
<pitti> jbailey-gcc: any reason why @cdbs@ build dep expands to an unversioned build-essential?
<vuntz> mako: ping?
<bddebian> Kamion: ping?
<Kamion> bddebian: yes?
<Kamion> daniels: I'm making one small change to xterm/debian/rules: needs to be CFLAGS="$(CFLAGS)" ./configure rather than ./configure CFLAGS="$(CFLAGS)"
<bddebian> Kamion: ogra said that you might be the person to ask about the framework for "derivative" distros?
<daniels> Kamion: 'kay, that sounds about right, but that's how Keybuk had it in his d/r, and he's never wrong :P
<Kamion> daniels: haha
<Kamion> bddebian: uh, I'd be surprised ... maybe he meant Kinnison?
<Keybuk> Kamion: uh, why?
<Keybuk> (because that's wrong)
<Kamion> bddebian: but you'd have to be more specific
<Keybuk> unless xterm is using ancient autoconf, of course
<Kamion> ../configure --prefix=/usr --mandir=\${prefix}/share/man \
<Kamion>              --infodir=\${prefix}/share/info --enable-wide-chars --enable-luit --build=powerpc-linux-gnu \
<Kamion>              CFLAGS="-Wall -g -O2"
<Kamion> configure: warning: CFLAGS=-Wall -g -O2: invalid host type
<Kamion> creating cache ./config.cache
<Kamion> checking host system type... config.sub: too many arguments
<bddebian> Kamion: Well somewhere I saw mention of a document about a framework for creating "Ubuntu based" distros.
<Kamion> Try `config.sub --help' for more information.
<Keybuk> that looks like ancient configure
<Kamion> bddebian: -> Kinnison
<bddebian> Kamion: Essentially what I am considering is an Ubuntu GNU/Hurd
<bddebian> Ahh, OK, thanks
<Keybuk> in which case, you're right
<Kamion> I'm not sure what you'd gain from that relative to Debian GNU/Hurd to be honest
<Kamion> I mean, not to send you away or anything, it's just not clear to me what you get :-)
<bddebian> Kamion: Because I don't know how long Debian will let GNU live
<Keybuk> well, Hurd doesn't have trademark issues </topical>
<Kamion> curious, I'd've thought the Hurd had a better chance in Debian than in Ubuntu :-)
<bddebian> Plus, I'd like to have more of the "Univervse" concept of development rather than maintainers for specific packages
<Kamion> anyhow, sure, the launchpad stuff is still in development but it should be able to support that kind of derivative when it's ready
<bddebian> And I imagine it would not be an "Ubuntu sponsored" distro anyway
<Kamion> yeah, we expect to be supporting a number of things which don't carry the Ubuntu name but which derive from us
<Keybuk> . o O { would a Hurd port of Ubuntu be called Moobuntu? }
<bddebian> I was thinking Ubunturd.. ;-P
<Kamion> bddebian: anything special you expect to need beyond a new architecture and an archive to upload to?
<Kamion> daniels: hmm, and installing to debian/xterm rather than debian/tmp might be a plan ;-)
* Kamion looks at the purty empty xterm package
<mvo> Keybuk: MoM seems to not know about system-tools-backends. is there a way I can check that?
<bddebian> Kamion: I don't really know, hence why I was looking for a guideline.. :-)  I was hoping to be able to build a buildd
<daniels> Kamion: *cough*
<Kamion> oh, hmm, it's using dh_install --sourcedir=debian/tmp
<Kamion> daniels: should I have a debian/xterm.install?
<daniels> Kamion: yeah, probably
<daniels> i just transitioned it from using cdbs :P
<Kamion> actually, maybe just install direct into debian/xterm - I don't see much gain from using debian/tmp as an intermediate
<Kamion> bddebian: Kinnison's only in this channel very occasionally - you could /msg him
<daniels> Kamion: *shrug*, none really
<daniels> Kamion: more out of convention from my other packages than anything else
<bddebian> Well I may be premature anyway, I was just hoping to get some insight.  I'm gonna start with some help with Universe packages first, I hope..
<Kamion> well, I'll do it this way for the moment, I wouldn't trust myself to write a correct xterm.install. :-)
<mdz> morning
<mdz> ddaa: yes, the upstream VCS for apt-listchanges is my local CVS
<mdz> ddaa: I have no particular desire to make it public, though I would like to have it imported into arch so that I can start using arch as the primary repository without abandoning my history
<mdz> Keybuk: you can have both editbugs AND a separate account for MOM
<Keybuk> gosh, but that'd mean I'd be able to do things to bugs
<ddaa> mdz: I've stashed into "do late" bucket. In time we can coordinate with you to make you an import and turn it into an Arch upstream.
<Keybuk> wish seems unfitting of a member of the launchpad team who's supposed to champion malone
<mdz> Keybuk: yes, and having a separate account for MOM would mean less excuse to ignore bugzilla mail ;-)
<Keybuk> but I'm not distro team :)  it's not part of my job to read bugzilla mail
<Mithrandir> Keybuk: that's easily remedied. ;-P
<Keybuk> which definition of "easily" are you using ?!
* Lathiat haxx0rz and gives keybuk a "promotion"
<Mithrandir> Keybuk: I'm sure mdz can drag you into our merry little family.
<Keybuk> I thought he'd already tried and failed
<pitti> mdz: would you mind demoting monodoc-http into universe?
<pitti> mdz: yesterday I half-approved the package, but all debs are already in main
<pitti> (seeded)
<mdz> pitti: that depends on what it will break
<pitti> mdz: it's a standalone http server to view mono docs
<pitti> mdz: but using monodevelop or the gui is probably enough
<pitti> (monodoc-browser)
<mdz> pitti: ah, ok, I was confusing it with something else
<pitti> mdz: I talked with tseng about it, and he agreed
<mdke> hey ogra you around?
<pitti> mdz: ok, I remove it from the seeds then
<ogra> mdke, moment, on the phone
<mdke> ogra, sure thanks
<mdz> pitti: already doing it
<pitti> mdz: ah, ok; just got a revision lock error
<tseng> thanks pitti, mdz 
<pitti> mdz: you don't get it? seems to be an umask problem again
<mdz> pitti: no, it's the same old baz bug where if you SIGINT gpg it breaks the tree
<mdz> pitti: I've finished committing now, should be fine
<pitti> thanks
<mdz> Kamion: so the next set of CD builds will be the first with 2.6.12, right?
<ogra> and with a working xsession ?
<ogra> mdke, back now :)
<mdke> ogra, cool thanks
<mdke> ogra, i just wanted to ask, I saw that you are doing an edubuntu conference, even if I'm not involved, is it possible for me to come along to listen?
<ogra> mdke, hmm, we are limited on space, but one person should do no harm
<mdke> ogra, that's why I asked, if space is limited its no problem, i don't mind!
<ogra> mdke, let me talk to someone who knows the location... i'll come back to you later
<bddebian> Heya ogra
<mdke> ogra, sure thing, thanks
<Kamion> mdz: assuming d-i is byhanded before then, yes
<Kamion> mdz: my network access is liable to be very spotty for a bit; seems the magic smoke escaped from my ADSL router
<Kamion> mdz: I'm working from Kinnison's today, but if I can't get it fixed tomorrow morning then I will just have to do offline development for a while - I have an Ubuntu installer talk to finish writing for Saturday anyway
<mdz> Kamion: yep, got your email.  have you found an alternate means of getting online?
<mdz> ah
<mdz> what's Saturday?
<Kamion> lugradio live
<mdz> they do talks?
<Kamion> lugradio live is a conference-style thing - first time they've run one
<Kamion> attempts to work around the problem with my old ADSL modem this morning were unsuccessful, so there may be more than one problem at work
<Kamion> daniels: ok, xterm uploading
<ogra> great, so we'll have a working gdm again :)
<pitti> ogra: what's wrong with the current one?
<ogra> pitti, it breaks if there is no xterm installed....
<pitti> ah
<Kamion> I think seb128 implied that might be a distinct gdm bug
<Kamion> but we'll see
<seb128> ii  xterm          6.8.2-10       X terminal emulator
<seb128> and I've the bug
<pitti> My gdm works perfectly
<ogra> hmm
<pitti> shall I try to nuke xterm? (I don't use it anyway)
* HiddenWolf hands daniels some insecticide
<ogra> pitti, mine didnt .... it drops you into a strange xdialog
<tseng> ogra: oh dude
<seb128> default session does that
<tseng> ogra: you just need to pick a gnome session
<seb128> gnome one works fine
<ogra> tseng, i know...
<ogra> tseng, but if you have "last" selected, or "default" it doesnt work
<Kamion> any idea how long that might take to fix? it's a colony cd blocker
<seb128> the gdm bug?
<Kamion> whatever it is that breaks the default session, yeah
<Kamion> oh damn, I said I'd be home like 15 minutes ago, and I'm 25 minutes' drive from home
<seb128> oh, I've put it on the bottom of my list of bug since picking GNOME works fine
<ogra> and a edubuntu CD blocker too... (i can live with it, but its not nice for a showroom release i'm planning currently)
<Kamion> seb128: I can't release CD images that way I'm afraid
<seb128> k, I'll work on it
<Kamion> or at least I'd really hate to :)
<Kamion> thanks
<seb128> np
<Keybuk> Kamion: did you see that you're scheduled against Ian Bell? :-/
<pitti> Keybuk: who is that?
<Keybuk> he wrote a little game called Elite
<ogra> oh
<ogra> _this_ ian
* ogra spent a lot of his youth in front of this game
<Kamion> Keybuk: good, smaller audience ;-)
<Kamion> unaccustomed as I am to public speaking, etc.
<Keybuk> it'll be interesting to see how many people attend
<Keybuk> (in general)
<Keybuk> it's either going to be a small, totally local affair
<Keybuk> or it's going to be far too big for its venue
<Keybuk> I'm not sure which
<Kamion> ok, I'm off - mail me if you need me, I'll try to get online somewhere
<Kamion> somehow
<bob2> thom: any idea where acpi-support svn is?
<wasabi_> Hmm. This is an interesting screenshot.
<jnc> Ian Bell.  *swoon*
<hunger> Would it be possible to have a centrino-kernel image? Most laptops are based on it these days and they tend to have somewhat more limited resources than desktops, so having all the stuff that is not seen in laptops is costing them a bit.
<bob2> how so?
<bob2> I really doubt the extra modules on disk is a significant issue on a centrino laptop
<justin> bob2: gentooitis? :-)
<hunger> bob2: The infrastructure for all kinds of stuff is in the kernel. Most drivers are not, agreed.
<bob2> hunger: and which of that consumes a significant amount of memory if not used?
<hunger> bob2: And I'd like to have a pentium-M build kernel;-)
<hunger> bob2: Yeah, you are probably right.
<mdz> Keybuk: if you create a new bugzilla user for MOM, I'll give it appropriate permissions
<Keybuk> mdz: I'd need the password to be grabbed out of the database
<Keybuk> or elmo to create an e-mail address for it
<mdz> Keybuk: I can just set a password of your choosing
<mdz> or set a random one and give it to you
<Keybuk> either works, mom@ubuntu.com
<bddebian> I can e-mail my mom at ubuntu?? :-)
<Keybuk> pick a password
<Keybuk> (and mail it to me, I'm off now)
* mvo goes to play hockey now
<bob2> so
<bob2> if I upload urlgrabber to sid, it'll get picked up into breezy universe tommorow, right?
<mdz> bob2: if the Ubuntu version is identical to the Debian version, and it's not a new package, yes
<bob2> it's a new package
<bddebian> Ubuntu is not at LinuxTag??
<justin> speaking of new software, I need to figure out how to do one of them RPF's for http://onegeek.org/~tom/software/delay/ .. building .debs for it gets old after the 10th time
<bob2> "RPF"? RFP?
<justin> ah yes, typo :-)
<daniels> bddebian: it is
<justin> 'delay' is a hard word to search for to see if someone had filed one in the past
<bddebian> daniels: Do you know where?  A friend of mine just said he hadn't seen them?
<Mithrandir> it's stupid to use common words as program names
<daniels> bddebian: they're sharing booth space with gnome
<bddebian> Ahh
<daniels> mako's wandering around but will probably settle on an FSF booth
<daniels> and I'm here in the X.Org booth
<bddebian> Well I'm in the US so.. :'-(
<bddebian> :-)
<mdz> bob2: new packages get processed manually, so it may not be tomorrow
<mdz> bob2: if it's new in Debian as well, it will almost certainly take several days before it is accepted in Debian, and it won't even go into Ubuntu's new queue until then
<bob2> mdz: ok, I'll just ask around on the weekend then, thanks
<bob2> right, totally not in a hurry :)
<toresbe> vel, ja :P
<toresbe> whoa, ewindow
<toresbe> that's strange.
<bob2> doko: ping
<doko> bob2: pong
<lamont__> elmo?
<bob2> doko: ah, just wanted to ask for some help packaging a python module
<bob2> but I'm going to sleep now, might see if you're around tommorow :)
<doko> ok
* lamont__ lunches
<pitti> Hi lamont__ 
<ska-fan> pitti: Hi. Where can I get updated pg80 packages for hoary? The ones in debian unstable want to upgrade libc..
<pitti> ska-fan: fetch the source from sid/breezy and build them on your own
<pitti> ska-fan: I don't do hoary backports myself
<ska-fan> can you give me short step-by-step on how to build my own packages?
<pitti> I /msg
<ska-fan> thanks
<jbailey-gcc> pitti: re: @cdbs@, because Robert Millan did some drugs and wasn't sharing.
<jbailey-gcc> pitti: It's clearly wrong.  I haven't taken the time to change it yet.
<Mithrandir> jbailey-gcc: so if he'd been sharing you'd want to keep @cdbs@? :-)
<pitti> jbailey-gcc: ah, ok. if it's known, that's fine :-)
<bddebian> jbailey-gcc!!!
<jbailey-gcc> Mithrandir: Well, I don't fundamnetally disagree with the whole @cdbs@ thing.  There are some things that need to be different about it though.
<jbailey-gcc> pitti: It is.  Feel free to fix it if it's annoying you a lot - I won't do it this week.  (I'm at the GCC Summit)
<jbailey-gcc> bddebian: Heya Barry.
<Duck_Happy> coin jbailey-gcc 
<bddebian> Duck_Happy: What're you doing here?? ;-)
<jbailey-gcc> Heyhey, Duck.
<pitti> jbailey-gcc: oh, it's not urgent, I just noticed (I don't automatically regenerate control)
<jbailey-gcc> Right.
<jbailey-gcc> That's the biggest fix that needs to happen.
<jbailey-gcc> (That control needs to not auto generate)
<Duck_Happy> bddebian: i'm watching if you are not doing BAD(tm) things ;-)
<bddebian> Duck_Happy: YOu mean like Ubuntu GNU/Hurd?? ;-P
<Duck_Happy> for example, yes
<Duck_Happy> bddebian: go back to Hurd homework n,aughty boy
<bddebian> Duck_Happy: I am.  I'm forking it to a distro that might actually get some work done / care about the system.. ;-)
<Duck_Happy> bddebian: more seriously i'm here to foloow CDBS discussions
<bddebian> Ahhh
<Duck_Happy> bddebian: because CDBS like Hurd is the future
<bddebian> Aye
<Mithrandir> Duck_Happy: I doubt both statements. :-)
<bddebian> Mithrandir: Bah, shows what YOU know.. ;-)
<Mithrandir> bddebian: I don't believe in "one size fits all".
<Mithrandir> bddebian: and I don't like cdbs in a lot of cases because it makes too much implicit.
<bddebian> Mithrandir: I was kidding man. :-)
<Mithrandir> bddebian: hard to tell on IRC :-)
<bddebian> Hence the wink.. ;-)
<Duck_Happy> Mithrandir: i never felt loosing control on my packages when using CDBS1
<Mithrandir> Duck_Happy: I had to resort to reading source on multiple occasions.  That hasn't happened often with just debhelper, for instance.
<Duck_Happy> Mithrandir: you should read the documentation, which was long to come, i agree
<Duck_Happy> CDBS2 is not gonna be in the same situation
<Mithrandir> Duck_Happy: UTSL was the doc last time I did something which wasn't C&P.
<Duck_Happy> Mithrandir: when was it ?
<Mithrandir> Duck_Happy: some time ago, I don't remember.
<Duck_Happy> hum
<tseng> thom: feel like fixing blam?
<mdz> doko: are we going to need to do an oo.o2-amd64, or is upstream 64-bit happening?
<doko> mdz: it's likeley we need it. I'm currently working on m111. If that's working on powerpc and ix86, then I'll start a compile for amd64. The other option to try is to use gcc -m32 on amd64
<mdz> doko: it would be very nice if we could merge the source packages
<mdz> but we still need more ia32-libs, right?
<doko> mdz: yes, but currently I just install the libs needed, I think it's too early to start the packaging now
<zzzsleepy> A new NVIDIA driver (1.0-7667) was released yesterday. Any plans on backporting this? (http://www.nvidia.com/object/linux_display_ia32_1.0-7667.html) brief list of changes with the latest NVIDIA driver: http://www.linux-gamers.net/modules/news/article.php?storyid=850 
<zzzsleepy> I believe this (may) resolve an issue which held back the previous new version from being backported
<zzzsleepy> pardon me if this is offtopic, I was told this was the place to mention this, thanks for reading.
<ogra> zzzsleepy, we dont backport things
<kiko> zzzsleepy, ask daniels as he is the man to be on such things.
<kiko> ogra, you should have been in yesterday's mgmt meeting :)
<zzzsleepy> ogra, then I was misinformed, my apologies. :/
<zzzsleepy> ogra, thanks, I will do that.
<kiko> zzzsleepy, you mean backporting to hoary, yes?
<zzzsleepy> kiko, yes! :)
<kiko> yeah, hate to say I don't think this backport will make it
<zzzsleepy> kiko, darn :)
<kiko> but tell you what
<kiko> you can package it and I will let you publish in our wiki your apt repository at no extra charge!
<kiko> this is a one-time offer :)
<\sh> rotfl
<ogra> heh
<zzzsleepy> heh. I have dialup, I cannot possibly backport ;(
<zzzsleepy> but thank you both for your kind answers, I appreciate it.
<kiko> I'm sorry I don't have good news
<kiko> actually, I do!
<kiko> breezy's around the corner
<zzzsleepy> :)
<kiko> we need bug triage love to make the corner closer
<kiko> if you pop up on wednesday we can make your little modem squeal with glee at all the bugpages it may ship
<zzzsleepy> lol
<kiko> think about this amazing opportunity
<zzzsleepy> will you make it go WEEEEE like a piggy?
<kiko> did I say we may be offering bribes too?
<zzzsleepy> hah
<kiko> so put down wednesday in your calendar as "the day I skipped work to help out in the ubuntu bugday"
<zzzsleepy> ;)
<zzzsleepy> you know what this distro needs, a community/monastic like setting where a bunch of coders give up everything and live off the land to beta test future versions of ubuntu! Not only would it be something no other distro has, it would also make for good world news :)
<kiko> you'd need naked waitresses
<zzzsleepy> !
<Nafallo> kiko: what? where!? GIMME! :-)
<kiko> Nafallo, only when you fix enough bugs
<Nafallo> kiko: hehe.
<zzzsleepy> is that the linux version of enlightenment? :D
<Nafallo> kiko: not til I've got proper ccache love in my pbuilders ;-)
<mdz> ogra,kiko: https://wiki.ubuntu.com/HelpingWithBugs
<mdz> initial brain dump
* kiko looks
<ogra> mdz, wow, fast :)
<tseng> it would be great to pick up a few regular triagers
<bddebian> Ohh, I have to read that tonight
<mdz> kiko,ogra: blank space at the bottom for bug day instructions :-)
<bddebian> After upgrading to Breezy of course.. :-)
<mdz> I need to run an errand; I'll be back in an hour or so
<kiko> mdz, I'll make a magical effort tonight
<mdz> kiko: it's probably worth duplicating some of the GNOME stuff about completeness directly on that page, and customizing it for Ubuntu
<kiko> k
<mdz> since we need different information than they do
<mdz> I'll try to work on it more later
* ogra ponders about the voting mechanism for the community
<tseng> ogra: voting on?
<ogra> tseng, the BFOM 
<ogra> tseng, bugfixer of the month
<bddebian> Oops, I shouldn't be talking in here huh??
<bddebian> Yeah tseng!
<tseng> ogra: shouldnt that be scripted?
<ogra> tseng, nope
<tseng> most bugs closed, no brainer
<ogra> tseng, thats just boring
<ogra> tseng, most bugs is not a intresting criteria for the community
<ogra> tseng, most annoying bugs is !
<tseng> ok that doesnt seem to have any practical value to me
<tseng> but have fun :)
<ogra> tseng, the community shall vote for the best bugfixer... that gets more eyes on the bugs ;)
<tseng> er, you might want to fix your wording then
<ogra> tseng, they have to look at the bugs and care for them to vote, even if they cant fix ;)
<tseng> "best bugfixer" to me sounds like someone who fixed the bug
<tseng> not a bug you want to fix
<ogra> the "best" in the eyes of the community.... not driven by quantity
<tseng> well dont call it a bugfixer
<ogra> the idea is to attract "non bugfixers" to have a look at the bugs.... 
<tseng> now thats a good idea
<ogra> tseng, you dont call a person who fixes a bug a bugfixer ?
<tseng> yes, i do
<ogra> so do i
<ogra> :)
<tseng> i dont call the bug i want to get fixed a "best bugfixer"
<ogra> noo... if you vote, you look at fixed bugs...
<tseng> and voting after the fact for the person who fixed the most annoying bug is stupid
<tseng> no no
<tseng> vote on open bugs to get moved up a list
<tseng> top 10 most annoying bugs
<tseng> ranking them after the fact is pointless imho
<ogra> no, you can in prizes if you get voted...
<ogra> win even
<tseng> eh
<ogra> so the community has to vote for you...
<tseng> i still think you have it backwards
<tseng> but its your project
<ogra> it is 1. bringing together the users and hackers more, 2. attracting people to look at bugs they would never look at... and 3. have a lot of fun  :)
<tseng> and prizes.. meh
<ogra> whats wrong with that ? 
<tseng> most of the top bugfixers are doing this for a living
<tseng> atm
<ogra> what are the top bugfixers ?
<tseng> seems stupid to give them a prize
<tseng> seb, you?
<ogra> i'm not a _top_ bugfixer....
<ogra> tseng indeed people working directly on the distro are not included
<tseng> why dont we get people involved in bug tracker by having them select the top 10 most annoying bugs
<tseng> which get more attention
<ogra> tseng, we'll have bugdays... its all inside this frame... so bugs introduced on bugdays count
<tseng> by getting spammed around on bugdays
<tseng> and show up first on bugzilla
<tseng> its harder to work backwards and see who fixed the most popular bugs
<tseng> and makes less sense to me
<tseng> where do you start to select this person?
<ogra> tseng, i want the fixers to be free to choose... i want the users to decide what helped them most and vote for that
<tseng> if i am an average user
<ogra> then you read the ubuntu-users ml.... and probably drop by in #ubuntu-bugs
<tseng> other than voting for the guy that fixed my pet bug
<tseng> or watched on bug day
<tseng> i have no idea who fixed what
<tseng> w/o looking at every bug closed that day
<ogra> thats not important....
<tseng> gosh
<ogra> why, if you have your pet bug
<tseng> so people who arent involved directly in bug day
<tseng> dont get to vote?
<ogra> no, bugs that are not touched on bugdays
<ogra> if you fix a bug that was handles on a bugday, thats votable 
<ogra> handled
<ogra> bu if you fix one in your area (mono) that never showed up on a bugday... who should vote for it ?
<bddebian> If I start looking at bugs, how do I know I'm not looking at a bug that someone else is already working on??
<ogra> its assigned ?
<bddebian> I see that a lot of them aren't
<tseng> ogra: so if i fix all my bugs before bug day im not a participant?
<ogra> you see it right :)
<tseng> none of this makes sense to me
<ogra> tseng, who should notice your bugs ?
<tseng> people who want beagle and are annoyed at some bug that keeps them from using it?
<ogra> if they are not brought up 
<tseng> thats what i was saying before, there is no way for the average user to participate in voting
<ogra> yes, and they look in bugzilla on a bugday, and thereis no bug
<ogra> tseng, yes, thats why they should show up on bugdays.... if ou want to get a vote, show up too :) 
<bddebian> ogra: Are you saying that no one is working on them? :-)
<ogra> bddebian, or they are not verified etc... look at the status
<tseng> its stupid
<tseng> to confine incentives to one day
<ogra> tseng, bringing people together is stupid ?
<tseng> why should I fix bugs any other day?
<tseng> no, bug day in general is not stupid at all
<ogra> because you claimed it on bugday ?
<tseng> recognizing people for fixing bugs only on bugday is stupid
<ogra> not for fixing
<ogra> for grabbing
<tseng> for grabbing?
<tseng> whats grabbing
<ogra> sure
<ogra> claiming a bug to fix it...
<tseng> buh
* tseng cries
<ogra> i dont expect people to fix the bugs on bugday
<ogra> but you have to coordinate it ....
<tseng> grabbing a bug would seem to discourage other people from fixing it
<ogra> there might also be a mailing list for that... so its not bound to the day... but currently i think the concept to bring people together that would never work together this way is a very important aspect...
<ogra> tseng, who cares, as long as you fix it...
<tseng> because someone else marked it
<tseng> and you gave them a prize
<tseng> 1) there should be no more reason to fix bugs on bugday than any other day
<tseng> it should be about getting people involved and meeting the developers
<tseng> they should stay involved
<tseng> whenever is convenient
<ogra> sure
<ogra> the bugday is to get them innvolved
<tseng> yes
<tseng> but not just on bug day
<ogra> ope
<ogra> nope
<ogra> but if they want a prize (merchandize or a weekend with you) they should show up on bugday....
<Nafallo> yay!
<tseng> and triage bugs
<tseng> and do their best to fix..
<ogra> yep
<tseng> so
<tseng> "grabbing bugs" is broken
<Nafallo> ogra: weekend with tseng ? :-)
<tseng> Nafallo: they wouldnt survive it
<ogra> but still i want the community to be the judge 
<ogra> not a statistic drawn from bugzilla
<tseng> thats the part I think is broken :P
<Nafallo> tseng: tss tss tss. almost like I should give it a shot ;-)
<tseng> you are limiting 
<tseng> "the community" to "people who are at bugday"
<ogra> tseng, nope... they can discuss it on the mailing list etc
<tseng> which says, we value the people who are here on a given day more than people who fixed bugs every other day
<tseng> who might have been better contributors
<tseng> maybe seb fixed 50 bugs this month, and wasnt at bug day.. we give lots of fanfare to Nafallo who fixed 2 bugs on bugday
<ogra> tseng, probably we shouldnt limit it to the day, but still the community shall vote, thats the important part
<tseng> i want the community to vote on the top 5/10 bugs for bugday
<tseng> and we recognize the fixers of the most popular bugs
<ogra> tseng, seb gets money for fixing bugs... Nafallo does it in his sparetime... i think all distro team guys are excluded by default
<tseng> ogra: well, \sh then
<tseng> fixed 50 vs Nafallo's 2
<Nafallo> hilights dudes :-P
<tseng> its just an example of why I think its silly
<seb128_> community has no real clue of what bugs are easy or not to fix and who do job imho
<bddebian> aye
<ogra> tseng, if \sh is after a ubuntu t-shirt, he will show up
<tseng> bwar
<ogra> else he will just go on fixing bugs as he does now
<tseng> i want to recognize his steady contributions on other days of the week
<ogra> (or a dinner with you)
<tseng> over someone else who came for 1 day
<ogra> tseng, but thats not the target
<tseng> thats part of people *staying* involved
<ogra> tseng, getting _more_ people in is the target...
<tseng> i am going to walk away, i am being an asshole
<ogra> tseng, so how many packages do you review for MOTU in one day ?
<tseng> bbiaf
<\sh> what?
<tseng> ogra: hm i dont really care about myself, others fix alot more bugs
<ogra> i guess not more then me....
<ogra> tseng, but i bet you will be around on review day to review one or two
<tseng> ogra: sure.
<ogra> see
<\sh> what are you talking about me in my coding time?
<tseng> \sh: hi sh :)
<ogra> \sh, we dont, you hallucinate
<ogra> \sh, go back coding ;)
<\sh> hey, I  turn around my back, and everything beeps here ;)
<ogra> hehe
<\sh> need to finish python kde torrent client...
<seb128> why do you want to have community people voting for that?
<Nafallo> \sh: know the feeling ;-)
* Amaranth hugs you guys
<Amaranth> that's the fastest this computer has ever booted up
<Amaranth> the only way to beat it would be to use windows 95 :)
<Nafallo> Amaranth: ? :-)
<bddebian> DOS 3.3 ?
<Amaranth> heh
<bddebian> :-)
<Amaranth> i meant something with a GUI
<Amaranth> that would work on this computer
<bddebian> MS DOS 3.3 with Norton COmmander? ;-P
<Nafallo> Amaranth: what did you do? install the new kernel? :-)
<Amaranth> 2.6.12, yeah
<Amaranth> but i just wiped my old install and went hoary->breezy with no hacks too
<\sh> gentlemen, I'm not behind a ubuntu shirt, my trolltech shirt is enough, and my redhat fedora and baseball cap as well...I'm feeling sometimes like a PR machine without revenue ;)
<Amaranth> so that might be part of it
<ogra> \sh, as i said.... you fix them anyway :)
<Amaranth> my old install was warty+hoary+breezy+hacks to make hoary and breezy work when they were broken
<\sh> ogra: most of the stuff for cxx was/is finger tricks for me...the really interessting stuff was only in a couple of them
<ogra> Amaranth, your X upgrade worked fine ?
<Amaranth> yep
<Amaranth> no problems at all
<ogra> Amaranth, no clash with xsreensaver ?
<Amaranth> wait, i did have one problem
<\sh> ogra: and I would like to even more when danielN is ready to join us
<Amaranth> xlibs-data and libx11 both had xkb iirc
<ogra> \sh, he will...
<Amaranth> but that wasn't anything major
<\sh> to see 
<Amaranth> no problems with xscreensaver, no
<ogra> Amaranth, great :-D
<\sh> ogra: i know :) 
* ogra goes to close a bug
<\sh> ogra: ffmpeg *run*
<ogra> GRRR
<ogra> \sh, it looks like its not solvable
<\sh> yeah I love u too :)
<ogra> (ffmpeg)
<doko> ohh, the IBM wireless drivers are restricted?
<ogra> i tried all combinations of cvs snapshots and patches ....
<\sh> so, transcode will never reach ubuntu ;)
<ogra> heh... transcode
<HiddenWolf> if the ibm drivers are restricted, we won't see ibm laptop support fully?
<seb128> what a waste of work on ffmpeg
<ogra> \sh, i guess waiting for a new upstream version is the only thing i can do
<ogra> seb128, absolutely
<\sh> ogra: same here for some *censored* soft
<seb128> why trying to work on this for days?
<ogra> seb128, i spent about 3x2h
<ogra> seb128, to solve it ?
<tseng> \sh: you can have my mono and ubuntu shirts
<seb128> Debian is switching to gcc4 soon
<seb128> sam is an excellent maintainer and will fix it for sure
<ogra> seb128, ok
<seb128> why not using gcc-3.n for now
<seb128> and stop working for hours for nothing
<ogra> seb128, because it doesnt work
<\sh> tseng: no :) I don't need :) 
<seb128> that's not a gcc issue?
<ogra> seb128, i can compile it on amd64 without probs
<tseng> \sh: k. you cant have my mono monkey
<tseng> \sh: he sits on my desk.
<ogra> seb128, i cant compile it on ppc with other things then gcc-3.4
<\sh> tseng: hehe :) greetings then :)
<seb128> so built it with this gcc
<seb128> and wait for Debian
<ogra> seb128, i cant compile it on i386 at all because of a lot of assembler code that doesnt work (probably caused through our glibc)
<ogra> seb128, with neither gcc...
<\sh> G'evening hsi customer ;)
<ogra> heh
<\sh> (good god, that he's not in the 1411 ring)
<ogra> \sh, DO isnt 1411 :)
<\sh> as I said
<\sh> 1411 is a pain in da ass nowadays
<ogra> \sh, i helped building it ;) i know ....
<\sh> ogra: ask mahmud(sp?) and coral about it...they love 1411 ;) 
<ogra> :)
<Amaranth> seb128: gnome 2.10 in debian is using gnome-*.menu, right?
<Burgundavia> seb128, can I close https://bugzilla.ubuntu.com/show_bug.cgi?id=11303 ?
<seb128> Amaranth: correct
<Amaranth> seb128: any ETA for breezy getting it?
<seb128> Burgundavia: nop, I've not closed it because I've planned to maybe do an hoary-updates upload
<seb128> Amaranth: getting what?
<Burgundavia> seb128, that is what I figured. Ok, will leave alone
<Amaranth> gnome-*.menu
<seb128> Amaranth: that's not planned
<seb128> Amaranth: GNOME is default for Ubuntu we don't change it
<Amaranth> ah, ok
<Amaranth> i thought you had it like it is because you were still planning on doing the XDG_CONFIG_DIRS tricks
<seb128> nop
<seb128> kde is already renamed for hoary
<seb128> GNOME is default and don't get renamed
<seb128> we will rename xfce files if required
* Riddell is still bitter about that
<seb128> why?
<Amaranth> doesn't xfce just use gnome's menus?
<Amaranth> in ubuntu, i mean
<seb128> Amaranth: maybe, I don't use xfce :)
<Riddell> don't see why kde should have to rename and gnome not grumble grumble
<Amaranth> i can't find where it provides that file
<seb128> ah ah
<Amaranth> i figure it's in a postinst script or something
<seb128> because GNOME rocks :)
<Burgundavia> where does the system store mime types?
<Amaranth> in .desktop files?
<Riddell> yeah well KDE is special
<Amaranth> wait, no
<Burgundavia> nah, system wide stuff
<seb128> /usr/share/mime/
<seb128> /etc/mime.types
<seb128> /etc/mailcap
<seb128> depending on what mimesystem you want
<lamont__> Riddell: there's at least one th in special. :0)
<seb128> there is different ones
<Burgundavia> the freedesktop one
<Burgundavia> and I found what I was looking for
<ogra> Riddell, ah, and i thought its a bug that KDE stores theme data in .desktop files... but special... well...then thats something else :)
<tseng> ogra: its a feature
<ogra> yep :)
<Burgundavia> seb128, https://bugzilla.ubuntu.com/show_bug.cgi?id=7264 is marked as upstream fixed, but I don't have all the techincal knowledge to see if it is fixed or not
<Burgundavia> a bug that is fixed upstream, but not yet in Ubuntu should be marked as Pending Upload, no? How do I do that?
<seb128> Burgundavia: thanks for pointing it. The fix is not packaged yet
<seb128> I'm changing this one
<seb128> bugzilla.ubuntu.com is bugged
<seb128> you need to change to ACCEPTED then you can change to PENDINGUPLOAD
<Burgundavia> ah
<Burgundavia> ok
<pitti> seb128: no, you can switch even from UNCONFIRMED to pending
<seb128> pitti: we talk about UPSTREAM bugs
<pitti> ah, sorry
<seb128> no worry :)
* pitti just saw the bz.ubuntu.com URL
<\sh> btw bugs ;)
<\sh> can someone give a small comment on this bug: https://bugzilla.ubuntu.com/show_bug.cgi?id=11456
<Burgundavia> I seem have a great deal of upstream bugs
<cartel_> weird
<cartel_> pam doesnt act like debian pam on ubuntu
<cartel_> openssh-client bugged
<cartel_> heh
<cartel_> oh for fucks sake this is stupid
<hub> do I need to do something special to upload a new package ?
<hub> I'm packaging hugin, and I'd love to see it in universe for breezy
<cartel_> what a steaming pile
<bddebian> Damn cartel_, and crimsun thinks I'm a potty mouth. :-)
<cartel_> oic, ssh-krb5 is in universe.
<cartel_> therefore it is unusable. great!
<cartel_> bddebian: i have crazy unsolvable winbind errors, so im trying krb5. which wont work either
* hub dig back to the huge pile of documentation
<bddebian> bddebian: I don't mind, I'm just joking around. :-)
<cartel_> i think im gonna have to ditch ubuntu to get this out of the way and install sarge :/
<ogra> cartel_, huh ?
<cartel_> at least it works :/
<ogra> cartel_, could you file a bug ?
<cartel_> ogra: already done : already done
<cartel_>     http://bugzilla.ubuntu.com/show_bug.cgi?id=12123
<ogra> hub, become a MOTU 
* cartel_ is getting tired of crappy ubuntu vs universe issues
<bddebian> ubuntu vs univers??
<ogra> cartel_, what makes you think that there is a ubuntu vs universe issue ?
<cartel_> ogra: read the bug
<ogra> i see it
<cartel_> ogra: openssh-client thinks its da bomb
<ogra> cartel_, so file the bug in the right BTS and it will get fixed... there is no ubuntu vs. universe
<cartel_> it will get fixed IN BREEZY
<ajmitch> cartel_: openssh-* should have conflicts with ssh-krb5 now anyway
<ogra> The following packages will be REMOVED:
<ogra>   openssh-client openssh-server ssh ubuntu-base ubuntu-standard
<ogra> The following NEW packages will be installed:
<ogra>   ssh-krb5
<ajmitch> ogra: coincidentally I just had the ssh changelog open
<ogra> looks like there is a missing Conflicts: in hoary
<ogra> cartel_, remove the above listed packages and you are fine
<hub> ogra: ok
<cartel_>   kdessh kdeutils kubuntu-desktop openssh-client openssh-server ssh
<cartel_>   ssh-askpass-gnome ubuntu-base ubuntu-desktop
<cartel_> i dont really want to remove kdeutils
<cartel_> (yes this system has gnome and kde)
<ogra> hmm, cartel_ talk to Riddell i have no clue about KDE 
<cartel_> also bugged ssh-krb5 does not replace or prompt for replacement on sshd_config
<cartel_> but does replace ssh_config
<ajmitch> cartel_: 'apt-get install openssh-client- openssh-server- ssh-krb5 ' to remove those 2 & replace with ssh-krb5 then..
<ajmitch> more of an #ubuntu issue, since it's been known & fixed in debian & breezy
<pitti> Hi ajmitch 
<pitti> ajmitch: any news about the SELinux packages?
#ubuntu-devel 2005-07-01
<ajmitch> pitti: which ones do you want updates on? patches are now in ssh, dpkg, manoj is updating pam to 0.79, reviewing the 50 debian patches that 0.76 carries :)
<pitti> ajmitch: hey, that sounds pretty good
<pitti> ajmitch: however, IIRC there were more (logcheck and so on)
<ajmitch> so we'll probably use 0.79 synced from debian, since manoj will get it in there
<ajmitch> logrotate?
<cartel_> sorry all, i dont mean to be angry, it is early in the morning and ive been fighting with this all night
<cartel_> and i dont understand why what works on debian doesnt work on ubuntu
<cartel_> heh
<ogra> cartel_, because sarge released after hoary...
<ogra> cartel_, so the fix is in there, but not in hoary ....
<cartel_> hoary is checkpointed against sid not sarge isnt it
<ajmitch> pitti: sorry, logrotate should be built, just needs 1 change to the rules file to turn on the selinux support 
<cartel_> or do you take sarge and try and merge in lots of stuff from sid (suicide)
<ogra> cartel_, nope
<ogra> cartel_, but sarge recieved bugfixes after hoary was released
<ajmitch> cartel_: the split package was in experimental until 6th June, but had been in hoary. the bug was fixed on the 17th
<cartel_> too much double handling if you ask me
<ogra> ??
<ogra> cartel_, the fix was discovered after hoary was released and already is in breezy, where is the double handling... 
<cartel_> the double handling is in divergent branches
<cartel_> since ubuntu is effectively a branch of sarge as you say
<cartel_> much work wasted on people merging others patches
<ajmitch> cartel_: the debian & ubuntu maintainer is the same person
<cartel_> ian was right you make life difficult for yourselves
<ogra> cartel_, when did i say _that_ ?
<ogra> cartel_, you said that
<pitti> night everybody
<mdz> pitti: night
<seb128> 'night pitti 
<ajmitch> night pitti 
<ogra> cartel_, ubuntu is a snapshot of sid, gets constantly updated until we freeze to stabilize
<cartel_> you're trying to take sid and stabilise it, not even 1000 dds can do that so how can ~50 ubuntu people do it
<tseng> cartel_: can you please take it down a notch
<tseng> cartel_: we aim to stabilize a very small portion of sid
<cartel_> tseng: huh?
<tseng> cartel_: "universe" is best effort
<ajmitch> because ubuntu freezes, sid doesn't
<tseng> huh? we spend our lives on this stuff and you are coming of as very critical without much understanding
<tseng> id just prefer you ask w/o the tone that you know we are doomed
<cartel_> tseng: im saying you are making life difficult for yourselves
<tseng> you know
<cartel_> ok
<tseng> its largely automatic, actually
<cartel_> until there is a bug
<tseng> yes, non-critical bugs in released products dont get fixed
<tseng> you are right
<cartel_> then you have to wait 6 months for it to get fixed in $(debian_version)+1
<ogra> cartel_, we can do it with (actually less then 30 ppl) because we have a sensible software selection for main
<cartel_> debatable
<tseng> cartel_: universe is unsupported
<ogra> cartel_, MOTU who cares for universe just starts to exist
<cartel_> and everything outside of a tiny enduser focus is ignored
<ogra> cartel_, in hoary 10 ppl cared for 15000 universe packages...
<tseng> $ apt-cache show ssh-krb5 | grep Section 
<tseng> Section: universe/net
<ogra> cartel_, so there i admit that we might have lots of bugs left
<tseng> this is a community maintained package
<tseng> if no one in debian or ubuntu fixes the bug within the 6 month cycle
<cartel_> tseng we have gone far past ssh-krb5
<tseng> you are quite right, it has to wait
<tseng> im making it into an example
<ogra> cartel_, which should change with every additional MOTU
<tseng> you are free to care for that package
<cartel_> i thought about becoming a motu
<tseng> and?
<ogra> cartel_, go ahead... 
<cartel_> but then i realised its better for me to put my work into debian
<tseng> we are very nice when you dont put us on defense :)
<cartel_> and have a trickle down
<cartel_> im sorry guys
<ogra> cartel_, who says your work doesnt go into debian
<cartel_> ive just been fighting this prob all night
<seb128> cartel_: fixes go both ways all the time
<tseng> well, you didnt find it while we were working on hoary for 6 months
<cartel_> trying to show my clients how good ubuntu is for a desktop
<tseng> so we didnt have a chance to fix it
<cartel_> it just wont talk to their ads realm properly
<cartel_> when their 6 woody/sarge boxes dont have issue
<seb128> cartel_: send a bug if you want an issue fixed, that works like that for every distro
<cartel_> perhaps you can understand this small frustration
<cartel_> i dont mean to take it out on you all
<seb128> bugs happens? right
<cartel_> i genuinely love (k)ubuntu
<seb128> point them so they can be fixed
<cartel_> but when stuff doesnt work that is trivial in debian i get upset
<ajmitch> 10am now, and been up all night?
<seb128> cartel_: Debian has bugs too ...
<cartel_> ajmitch: i gave up at 11pm and im back at it at 8:30
<seb128> cartel_: and if Debian fixes an issue it gets fixed for Ubuntu too
<cartel_> ajmitch: thought a sleep on it would help
<ogra> seb128, that bug was fixed some weeks ago
<ogra> seb128, its just not fixed in hoary unoverse
<cartel_> but that ssh-krb5 was just the straw on the camels back
<ogra> universe
<ajmitch> cartel_: sleep usually does help
<cartel_> i apologise for putting you all on defense
<cartel_> you are all doing a great job
<cartel_> commendable effort
<cartel_> i hope improvements to desktop experience gained through ubuntus work flow back to debian too
<Riddell> lifeless: do you know why kexi is dep-wait on mysql-dev when it's build-dep is mysql12-dev?
<ogra> cartel_, sure... seb128 maintains them in both worlds....the only prob are the different release schedules and debians longer stabilizing time here.... so its likely to be outdated, since they support 11 arches and we only 3 and they have a way bigger main component
<lifeless> Riddell: nope. You do know that I am not in the distro team ?
<tseng> lifeless: i think he confused you with infinity :)
<lifeless> tseng: could be ;)
<ogra> heh... hard to confuse these two
<lifeless> Riddell: but ask me about version control foo ;0
<cartel_> now i am going to go and make a green tea to calm my nerve :)
<ogra> :)
<Riddell> man, all these abstract IRC nicks
<Riddell> infinity: do you know why kexi is dep-wait on mysql-dev when it's build-dep is mysql12-dev?
<ogra> *g*
<cartel_> abstact?
<cartel_> +r
<cartel_> question
<cartel_> why did ubuntu opt for bugzilla over debian bts?
<cartel_> when reportbug is so convenient?
<cartel_> i know you are transitioning to malone
<cartel_> once it reaches OnePointZero
<seb128> cartel_: bugzilla is much better than the BTS imho
<cartel_> but in the interim?
<ogra> seb128++
<cartel_> you think?
<cartel_> from maintainer perspective or user perspective?
<seb128> cartel_: I use both a lot
<seb128> both
<cartel_> really?
<seb128> you have not Cc: on a bug with the BTS
<cartel_> that is trivial to implement
<seb128> ou have no search, which makes search for a duplicate ... hum ... long
<cartel_> but bts shows you bugs when you do a reportbug
<seb128> a lot of users like to use a webform than the BTS has not
<cartel_> you can see if there is a dupe before you file
<cartel_> really?
<seb128> sure
<cartel_> i hates the webform
<seb128> people are not happy to use the command line ...
<cartel_> who is this people?
<seb128> and sending a bug to submit@b.d.o is not trivial
<cartel_> lusers?
<seb128> users
<ogra> cartel_, my mother
<cartel_> ic...
<seb128> cartel_: anybody than you can put on front of a desktop and which is not a computer guy
<\sh> ogra: greetings to your mother :)
<cartel_> well bugzilla does not collect the information bts does like installed dependency versions
<cartel_> s/bts/reportbug
<cartel_> at least not automatically
<cartel_> which makes life as a maintainer more difficult
<seb128> cartel_: not, but have a some bug-buddy hack for this
<seb128> s/a//
<cartel_> ok
<mdz> elmo: is us.archive permanently gone?
<hub> whate does a "c2" means in the package name ?
<hub> gcc4?
<seb128> correct
<hub> crap
<ogra> nope g++4
<hub> because gcc4 reject what i'm building
<cartel_> from the sounds of it i must be one of fthe few who prefer bts to bugzilla
<ogra> ;)
<ajmitch> change in c++ ABI for g++ 3.4/4.0
<cartel_> -f
<hub> yesh g++4
<hub> it is wxWin :-/
<seb128> cartel_: just because of the mail command?
<ajmitch> hub: is there a problem?
<ogra> hub we get 2.6 soon
<cartel_> seb128: i expect reportbug to connect to bugzilla but it doesnt
<cartel_> seb128: i am debian since hamm :)
<hub> ajmitch: building the program I'm trying to package, yes
<seb128> cartel_: you are not forced to like the BTS if you use Debian you know .. 
<ajmitch> hub: aha :)
<cartel_> seb128: but i am used to it
<hub> ajmitch: and I build in Breezy :-/
<ajmitch> hub: broken/non-compliant source then?
<hub> ajmitch: as far as I know, it is not an error
<hub> ajmitch: but who knows
<\sh> hub: something was with wxwin
<hub> was ?
<hub> so I should wait for wxWin2.6 ?
<\sh> https://wiki.ubuntu.com//CxxLibraryList
<\sh> and search for wxwindows2.4
<\sh> it's already build for g++4
<\sh> https://bugzilla.ubuntu.com/show_bug.cgi?id=10826
<\sh> http://archive.ubuntu.com/ubuntu/pool/universe/w/wxwindows2.4/ i think
<\sh> if this is it what you want
<hub> sh: I have it
<hub> ii  libwxgtk2.4c2                     2.4.3.1ubuntu2                    wxWindows Cross-platform C++ GUI toolkit (GTK+ runtime)
<hub> I got an answer
<hub> I have to fix the codef i'm building
<\sh> hub: helped?
<hub> trying to rebuild
<hub> to see where the link error occurs
<\sh> hub: but this is what you wanted
<hub> what ? the packages ? I had them already
<hub> it is not a package problem. It is a gcc4 problem
<hub> or source code
<hub> whichever is your point of view :-/
<hub> I have to patch 
<\sh> ah ok
<hub> and my machine is slow
<hub> thanks I don't build on the laptop
<\sh> hub: i do :)
<hub> but your laptop is probably faster than mine
<\sh> dunno :)
<karlheg> Is there ro access to revision controlled Ubuntu versions of packages?
<hub> sh: Powerbook G3/400
<karlheg> I would like to suggest a few changes, and would prefer to submit them to the maintainer in patch format.
<karlheg> I'm wondering if you keep a central repository?
<jdub> karlheg: other than the source package repositories, not yet. that will be changing pretty soon, though.
<karlheg> baz or tla, I hope?
<karlheg> I've just begun to learn to use 'xtla', in GNU Emacs.  It's a very nicely done interface to 'tla'.  I don't know if it works with 'baz'; I've just begun learning about them.
<cartel_> hmm, wikipage says winbind in ubuntu hoary is 3.0.14 but i dont have it
<cartel_> i have 3.0.10
<cartel_> oh, its in breezy
<cartel_> crap i dont want to use breezy
<ogra> cartel_, recompile the package, apt-get {build-dep,source -b} is your friend
<cartel_> ogra: thats what im doing ;)
<cartel_> ogra: but once again it is a pain to not update hoary with bugfixes
<ogra> cartel_, debian does the same
<ogra> only security and dataloss fixes
<cartel_> ogra: i know
<cartel_> ogra: it pisses me off actually
<cartel_> ogra: at least in debian you can subscribe to proposed-updates
<azeem> cartel_: not that proposed-update is any good
<azeem> it's either crack or 'security and dataloss fixes'
<karlheg> Wow, xtla makes pcl-cvs look like a toy.
<cartel_> something should be done
<cartel_> create a bugfix team ;)
<ogra> cartel_, we actually think about a backports team... so you can use these from a controlled source
<azeem> cartel_: "something" is called "6-month release cycle"
<cartel_> azeem: 6 months with broken functionality not good
<cartel_> azeem: sorry client that doesnt work. wait 6 months
<cartel_> and it MAY work
<azeem> cartel_: is that a package in main?
<cartel_> azeem: its a package which is in main and has a component in universe
<cartel_> azeem: which will get promoted to main for breezy
<azeem> cartel_: so it should work then :)
<cartel_> azeem: but it doesnt :)
<azeem> or else keep helping on it till it rocks
<cartel_> azeem: because hoary froze before the bugfix was in
<ogra> cartel_, these are two different source packages
<cartel_> ogra: no they arent
<ogra> openssh-krb5 and openssh 
<azeem> cartel_: I mean for breezy
<cartel_> ogra: not talking about that any more
<cartel_> ogra: on to samba :)
<cartel_> azeem: fixed in breezy
<Burgundavia> jdub, ping
<azeem> cool!
<jdub> Burgundavia: pong
<jdub> yo azeem 
<jdub> azeem: good summary :)
<Burgundavia> jdub, there wasa 3.0 mockup on d-d, which a change menu. Do you have that link?
<azeem> jdub: I tried to pass it by mako, but he was on a plane or something :-/
<ajmitch> hey azeem 
<azeem> hey andrew
<Burgundavia> jdub, nev mind
<azeem> jdub: so if you think there's errors or omissions, please let me know :)
<hub> gcc4 piss me off
<hub> I can't package this software on breezy
<azeem> just Build-Depend on gcc-3.4 :)
<hub> azeem: but the C++ it link against ?
<hub> wxwin
<azeem> oh...
<hub> boost
<hub> that's why I have to rebuild it
<hub> it got de-installed by the whole upgrade
<hub> so I'm trying to make a clean packaging
<bddebian> Anyone home?
<cartel_> yahoo
* cartel_ patches ActiveDirectoryWinbindHowto with his finding
<bddebian> cartel_: Do you know another mirror for Breezy?
<cartel_> bddebian: nz.archive.ubuntu.org? 
<cartel_> should i tell users how to build/install samba from breezy for hoary in the wiki?
<cartel_> or is that considered harmful?
<cartel_> ogra? anyone?
<cartel_> wtf
<cartel_> weird wiki syntax
<infinity> cartel_ : Encouraging users to backport packages themselves is considered harmful, yes, because they lose security updates.
<cartel_> infinity: well the wiki has broken info as it stands, reccomending them to install the package from breezy, but providing no instructions
<infinity> cartel_ : And samba has had its fair share of security problems over the years.  Leaving users vulnerable is not nice.
<cartel_> infinity: but they ARE vulnerable. we're still running 3.0.10 in hoary
<infinity> Vulnerable to...?
<cartel_> bugs? ;)
<cartel_> i thought there was another security issue between 3.0.10 and 3.0.14 but evidently not
<infinity> If there's a security vuln, we'll backport the patch to 3.0.10.
<cartel_> interesting... ibm guys commiting to samba
<infinity> But if users have 3.0.14a installed, they won't get the update.
<infinity> Which sucks.
<cartel_> infinity: ouch
<cartel_> infinity: as it stands you cant auth to win2003 sp1 with versions <3.0.14a
<infinity> If you want to make that VERY clear in those directions, then fine.
<cartel_> as you say it will cause more problems than it fixes
<infinity> If you can find me a patch to apply to 3.0.10 to fix the specific bug and none other, I may be able to push it unto hoary-updates.
<cartel_> i will need to trawl through the svn history
<infinity> But telling users (many of whom dont' really think of the consequences) to install unsupported packages can be catastrophic.
<infinity> There have been many worms in the past that spread through vulnerable samba installations, so it's not just hand waving on my part.
<cartel_> fair enough
<cartel_> those poor users :p
<bob2> tseng: http://kirby.insanegenius.net/postfix.html
<cartel_> kirby looking for dox on postfix?
<hub> okay, found a gcc4 bug
<Lathiat> join  the club :)
<hub> yep
<hub> hugin chokes on an inlined virtual destructor
<hub> putting it in the .cpp works :-/
<hub> but now the stupid debian packager believe this is a debian native
<hub> bah
<bob2> who's the person who packaged it?
<hub> bob2: me
<hub> bob2: it si not an ubuntu package
<hub> bob2: I was talking about the software, not the person :-)
<hub> but I probably messed up
<bob2> do you know the difference between native and non-native?
<hub> yeah
<hub> but I probably messed up in creating the package
<hub> because I did re-extract the tarball and did put my debian in it
<hub> :-/
<hub> so he probably believes it came with
<bob2> why did you do that?
<hub> because I messed up with the previous tarball while attempting to fix the gcc4 problem
<hub> I'll try a third time
<hub> ok
<hub> should work this time
<hub> now I need to apply to be a MOTU
<zul> you might want to poeple in #ubuntu-motu
<hub> I was reading the wiki
<jsgotangco> JaneW, hi
<jsgotangco> ooppss brb
<pitti> Morning folks
<JaneW> morning pitti
<pitti> Hey JaneW 
<dholbach> morning
<pitti> Hi dholbach 
<karlheg> I'm looking at the udu.wiki and am wondering what does "BOF" stand for?  (dictd says "Birds of a Feather")
<mdke> it means brainstorming session
<jsgotangco> yeah
<dholbach> hey pitti
<mvo> morning all
<dholbach> hey mvo :)
<mvo> hey dholbach!
<dholbach> karlheg: https://wiki.ubuntu.com/BOFs :)
<jdub> hi dholbach 
<dholbach> jdub: hey jeff! how are you?
<jdub> ok
<jdub> how's your thesis going?
<jdub> haven't seen you around so much :)
<dholbach> slowly evolving :)
<dholbach> and if i find somebody who does my networking code^H^H^Herm ... gives me some input on ... 
<dholbach> in 8 weeks it's over
<dholbach> the hardest thing for me is staying away from all of you guys
<jdub> heh
<dholbach> the thesis itself is just fine ;)
<dholbach> jdub: but the desktop team would better get going, as well as the bugsquad, maybe we could do another ubuntu-love day to recruit people for the teams :)
* robitaille thinks #ubuntu-love is most underutilized irc channel in the Ubuntu universe
<mdke> yeah that's a decent point
<davyd> ok, I might have to do something creative, what is the atheros driver? and does it ship in the Hoary installer?
<dholbach> rock, we're in the german news (with the breezy bounties): http://www.heise.de/newsticker/meldung/60996
<martink> davyd: linux-restricted-modules comes with madwifi, the driver for atheros wlan chips
<davyd> martink: which isn't in the installer?
* davyd suspects he is not going to get a painless install
<martink> oh, the question was about the installer. Sorry. Don't know.
* davyd might try netbooting breezy
<davyd> otherwise I might have to send a new kernel in my netboot image
<davyd> or try to boot off USB
<davyd> ok, perhaps breezy ships the same kernel
<davyd> also, the hoary installer segfaults if you plug in a usb device
<Lathiat> breezy has a 2.6.12 kernel but not in theinstaller yet i think
<davyd> yeah
<Lathiat> why not install hoary and l-r-m post-install ?
<dholbach> hey seb128 
<seb128> daniel :)))
<pitti> Hi seb128!
<seb128> hey pitti 
<pitti> seb128: I got the gdm error this morning, and I do have xterm installed
<davyd> Lathiat: first I have to install hoary
<seb128> pitti: I've just fixed that and the autologin
<seb128> before IRCing
<davyd> I suppose I can install the first stage
* davyd ponders a PCMCIA card
<seb128> pitti: that's not really an error, the upstream stuff tries to start Xclients, then xsm (which is this ugly stuff)
<seb128> pitti: the Debian package has a change to that, I've zapped it when switching to cdbs, that's fixed now
<pitti> cool
<Lathiat> davyd: why cant you just install?
<davyd> Lathiat: I can do the first stage install
<Lathiat> davyd: so why arent you?:)
<davyd> then I might be able to use usb2 prism
<Lathiat> davyd: whats theproblem of just doing a whole hoary install?
<davyd> Lathiat: no packages to do it with
<davyd> hmm
<davyd> back to square one, I still need packages
<Lathiat> why dont you just get the iso
<davyd> Lathiat: no CD-Rom
<Lathiat> because your going to download it all anyway
<Lathiat> ohhhh
<Lathiat> now it makes sense
<Lathiat> get the iso
<Lathiat> mount loopback on your desktop
<davyd> Lathiat: and USB devices crash it
<Lathiat> and network install
<Lathiat> (thats what i do)
<Lathiat> oh, no network
<Lathiat> hah
<davyd> Lathiat: no network drivers
* Lathiat laughs
<Lathiat> davyd: are you going to have a windows partition?
<davyd> I'm not 100% an idiot
<davyd> Lathiat: yes
<Lathiat> davyd: put the iso on your windows partition and use expert mode and load the iso loopback off your windows partition
<davyd> you're suggesting I loopback mount that?
<Lathiat> (the installer has a mode for it, its not even hacky)
<davyd> are you sure this is something you can do?
<Lathiat> i feel dirty, im using kde
<seb128> pitti: have you planned to review libmpc this week?
<pitti> I can do that today if it's urgent
<hunger> Is there a list of changes ubuntu did to vanilla gnome?
<seb128> pitti: no hurry, we just can sync with Debian when this is ok
<seb128> pitti: but sync next week is fine too :)
<pitti> hunger: cat debian/patches/* of all gnome packages :-)
<seb128> or read the debian/changelog (if that's no a mvo's sync :p)
<hunger> pitti: Thanks!
<seb128> usually patches are listed by the changelog
<hunger> kubuntu used to have a wiki page listing the mayor changes they wanted to do. I thought maybe there is something similar for gnome.
<seb128> pitti: funny "g-v-m opens my trash" bug BTW :)
<Lathiat> seb128: url?
<pitti> seb128: indeed :)
<seb128> hunger: we don't plan to make a lot of distro specific changes
<seb128> Lathiat: just a bugzilla bug, trash:// being open due to an USB mouse moving and clicking when plugged
<Lathiat> heh
<hunger> seb128: Gnome does almost feel nice in ubuntu... Damn, if you didn't do many changes then I might end up having to readjust my perception that gnome sucks;-)
<seb128> ah ah
<davyd> woot
<davyd> PCMCIA for the win
<jdub> hunger: there is a page of branding related changes that covers a few other things - search for branding in the wiki
<jdub> hunger: but in general, it's very similar to stock gnome, with skin deep changes (theme, etc)
<hunger> jdub: OK, thanks!
<dsevilla> hi, anybody knows when linux-restricted-modules-2.6.12 are expected?
<Lathiat> dsevilla: when they arrive
<dsevilla> Lathiat, yeah, wow, I must have suspected it :)
<dholbach>  /query jdub
<dholbach> now you all know it :)
<mako> azeem: i'm in your country now if it's not too late for me to look it over
<jsgotangco> hey mako!
<mako> i'm putting together my own talk(s) now but it's fine
* mako has popped up in another part of the world :)
<seb128> jdub, mako: did vuntz contact you about CD for the RMLL?
<jdub> seb128: vuntz asked me, i directed him to mako/jane
<seb128> k
<mako> seb128: are you going to be at RMLL?
<seb128> no
<mako> :(
<jsgotangco> hmm adi sent an email about the certification thing and posted it on the wiki..
<Treenaks> http://www.ubuntulinux.org/support/documentation/faq/betaTesting is a bit outdated...
* Amaranth wonders about http://no-name-yet.com/
<daniels> Amaranth: awesome
<dholbach> brb
<guim> hi all
<guim> is there any people from the original company Canonical here?
<pitti> "original"?
<guim> euh
<guim> working for the company, i wanted to mean
<guim> sorry
<pitti> sure
<Keybuk> plenty of us
<pitti> the part that works on the distribution is here at least
<guim> nice!
<guim> ok, i have some question/suggestion i 'd like to report to some of you guys them,
<guim> but do you mind if i do so in private first?
<Lathiat> daniels: is it possible to deactivate a screen on the fly
<Lathiat> daniels: or at least stop the mouse wandering into it
<Keybuk> guim: we're a pretty public company, why not just speak here?
<guim> ok
<guim> no problem
<guim> let me present myself first then :
<guim> i am a developer in the following opensrouce project www.claroline.net
<guim> this is a LMS (Learning Management System) in  PHP/Mysql
<daniels> Lathiat: nope
<guim> I don't know if some of you knows a bit about our project?
<Amaranth> ogra might
<Amaranth> he seems to be doing a lot of work on the edubuntu project
<guim> the thing is that i wonder if there could be an "arrangment" between our project and the ubuntu comunity 
<guim> but i have to tell that i am only starting with ubuntu, and for now, I don't much already about the organisation of the community
<ogra> guim, subscribe to edubuntu-devel (low traffic) and ask there ;)
<guim> ok thanks
<infinity> guim : Speaking of your project...
<guim> yes?
<ogra> http://lists.ubuntu.com/mailman/listinfo/edubuntu-devel
<infinity> guim : I don't suppose you guys would mind rewriting your code to not require register_globals?
<guim> it is done
<guim> for next version
<infinity> guim : Ah,, then can you update your docs? :)
<guim> well, not released yet
<infinity> guim : Asking users to turn it on opens a pretyt big can of worms.
<guim> but it will be soon for an alpha 1.7
<infinity> guim : Right, cool.  Thanks.
<guim> no problem
<carlos> fabbione, hi, will you have some time today to help me fixing my kernel issue?
<ogra> carlos, he is on holiday (long weekend)
<carlos> oh!, right
<carlos> :-(
<carlos> too late...
<carlos> ogra, anyway, thanks
<Lathiat> does breezy enable the thing like dmix for recording in alsa?
<pitti> Lathiat: I didn't check that
<pitti> Lathiat: so far it does enable dmix for playback
<pitti> didn't check dsnoo
<Lathiat> ok
<pitti> dsnoop, even
<Lathiat> tats the one
<ups> there is a bug report on "skype" in bugzilla - what can be done to that? skype isn't in the ubuntu repositories right?
<dholbach> ups: no it isn't - it's non-free
<Lathiat> nope its not
<Lathiat> (they provide ubuntu packages tho)
<ups> so i should close the bug?
<Lathiat> (which is probably why they are filing it here)
<Lathiat> not sure
<Lathiat> i assume
<Lathiat> forwarding it upstream to be nice?
<ups> does that mean that i should file a bug upstream too? or just make a comment?
<JanC> Lathiat : skype isn't nice to others (no open protocol), so why should we be nice to them?  ;-)
<Lathiat> you have to give them some credit
<tseng> they built a linux client
<Lathiat> they use dbus, they have good packages
<tseng> we should have more non-free linux clients
<Lathiat> they dont use 0.3x yet tho
<tseng> not chase away the people that give us some
<Lathiat> tseng: are you being sarcastic or serious?
<tseng> serious
* Lathiat nods
<JanC> I have no problem with them being non-free
<Lathiat> JanC: theres a good reason they dont use an open protocol
<JanC> but I care about open communication
<Lathiat> i just wish theyd interface with open protocols
<Lathiat> JanC: basically, because of the way it works
<Lathiat> p2p, nat traversal etc
<Lathiat> what they need is a sip gateway
<JanC> or just open their protocol   :)
<Lathiat> and their problem is they dont want to open it up becaause the network relies on people doing other peoples phone call traffic
<tseng> JanC: they have a product to sell
<Lathiat> and then they'll get clients that wont and then fuck the network
<Lathiat> (from their point of view)
<tseng> JanC: i go to work every day and write code I have no intentions of showing you. i need a paycheck like everyone else here
<JanC> well, they could provide a closed source lib maybe ?
<tseng> eh, theyd need a very thorough API doc at that point
<tseng> api + sniffer -> easy reversal
<Lathiat> JanC: they have an api ;)
<Lathiat> heh
<tseng> JanC: we should be supporting commercial ISV's bringing their products to linux as much as we can
<JanC> tseng : I have no problem with commercial / closed source companies
<JanC> but I have a problem with closed protocols / file formats
<tseng> well the protocol is the key piece of skype
<tseng> anyone can make a nice interface on top of SIP
* tseng > shower
<ups> bug #11785 is marked as Blocker, priority P1 - is it ok to change it to more like Normal, P2?
* ups is asking too many questions ;)
<`anthony> just a heads-up - there's a critical bug in dbus-python, with a patch attached to https://bugs.freedesktop.org/show_bug.cgi?id=1844. Any time a python app has more than one thread, dbus python will segfault. 
<Nafallo> livecds seems borked :-P
<Lathiat> <surprised>
<doko> `anthony: yes, that's https://bugzilla.ubuntu.com/show_bug.cgi?id=7292
<davyd> is the reason that there is no atheros driver for 2.6.12 the fact that it's actually uncompilable?
<davyd> or am I simply an idiot?
<davyd> also, is there a reason there is no sk98lin driver in the 2.6.12 kernels?
<ogra> davyd, i guess the atheros driver is in linux-restricted-modules..... which is nonexistent currently
<davyd> ogra: right
<ogra> davyd, so stay with 2.6.10 or wait....
<davyd> I was trying to compile the source, so far with no joy... it might be a gcc-4.0 hating-ism
<davyd> ogra: at the moment, I have no supported network cards
<Lathiat> davyd: you need to compile with gcc-3.4
<ogra> davyd, the kernel doesnt compile with gcc-4.0 
<Lathiat> davyd: (cus the kernel is built with gcc-3.4 at the moment)
<davyd> the version of madwifi in the Ubuntu 2.6.10 is not so working
<davyd> Lathiat: yep. realise this
<Lathiat> yeh it sucks apparently
<davyd> I think madwifi might have been ignoring my request to use 3.4
<davyd> I'll play with this some more in a bit
<Lathiat> change the symlink
<Lathiat> thats what i do
* davyd smirks
<Lathiat> tho nvidia suspend CC=
<Lathiat> so i dontneedto atm
<davyd> I would have update-alternatives'd
<Lathiat> supports
<Lathiat> i swear my brain just fucks withw ords sometimes
<davyd> but it seems there is to be no joy from that division
<Lathiat> davyd: no imean like, rm /usr/bin/gcc ; l n -s /usr/bin/gcc-3.4 /usr/bin/gcc ;)
<davyd> Lathiat: yeah, I could
<davyd> I'm currently building a 2.6.12 with the module I think I need for my wired network
<davyd> we'll see how that goes
<Lathiat> interesting, sk98lin was in .10
<davyd> yeah
<Lathiat> and not in l-r-m
<davyd> there is an skfp, which probes... but does nothing
<davyd> so I'm trying rebuilding with it in .12
<davyd> since it didn't work in .10
<Lathiat> bought the wrong laptop :)
<davyd> heh
<Lathiat> you should replace the atheros minipci with an intel :)
<davyd> I knew it couldn't be 100% painless
<Lathiat> and ebay the atheros :)
* davyd smirks
<davyd> perhaps replace it with my orinoco gold
<Lathiat> (im serious :)
<Lathiat> davyd: thats minipci?
<davyd> yeah
<Lathiat> davyd: cool, no g love tho
<Nafallo> rt2500 works, a bit :-)
<`anthony> doko: cool - have added a note to that bug, too.
<davyd> you can't buy a brand new, top of the range laptop and expect everything to be supported in released linux
<davyd> unless the vendor loves you
<davyd> or it's a boring machine :(
<Nafallo> there is a major rewrite of the drivers for rt2x00 and it's included in the main kernel :-=
<Lathiat> i dunno, my dell worked pretty good
<Nafallo> in ubuntu
<Lathiat> it had been around for a wee while tho
<Lathiat> but it was pretty highly specced
<davyd> Lathiat: yeah, most stuff on this thing just works
<davyd> just no network cards
<davyd> which is strange
<Lathiat> davyd: but like, my wireless is centrino
<Lathiat> and my ethernet is broadcom
<davyd> since network cards are usually the most boring thing on the machine
<Lathiat> which have been around for quitea while
<Lathiat> i wish this had gigE
<davyd> I was surprised not to have the Intel GigE chip
<Lathiat> only thing thats annoying
<davyd> it's interesting that only a few people use it
<Lathiat> davyd: most onboard stuff is yukon
<davyd> I wonder if it's expensive
<Lathiat> most motherboards with onboard gig have marvell yukons too
<davyd> worse comes to worse, I'll just have to ndiswrapper them
<Lathiat> some broadcom
<davyd> I should have set my kernel building on here
<davyd> oh well
* davyd has cold hands
<Lathiat> hows the 10mbit xircom pcmcia? :)
<Lathiat> davyd: so was this davyd-funded or work-funded?
<davyd> I start a new job Monday
<davyd> this will be davyd funded
<Keybuk> GAH!  Now I'm getting Cc'd on the mom "further changes have been made" comments
<ogra> heh
<davyd> but I have established a payment plan with (old-)work to do it
<Lathiat> davyd: ooh what job?
<Lathiat> davyd: the gtk coding one?
<Lathiat> hm global keybd shortcuts dont work accross X screens
<Lathiat> thats mildly annoying
<davyd> Lathiat: yep
<davyd> we'll see how that goes
<davyd> if I hate it, I'll go back to systems programing
<Lathiat> cool
<Keybuk> hmm, does bugzilla not let you change the reporter e-mail address?
<davyd> Keybuk: unlikely
<Keybuk> meh
<Keybuk> how stupid
<davyd> it's not often that you need to change the reporter I would guess
<Nafallo> damn!
<Nafallo> I'm locked out from launchpad :-(
<Nafallo> seems it can't handle passwords generated with pwgen -cnys 72 :-(
<Mithrandir> you could consider passwords less than 72 characters long. :-P
<Nafallo> Mithrandir: only when they are not supported ;-)
<Nafallo> I like those systems where you get warned that the password won't work while changing it ;-)
<HWolf> Nafallo, you are seriously able to remember such an insane password? :P
<Nafallo> HWolf: nope, but Firefox will :-)
<Nafallo> HWolf: and so will my .txt on the really small cf-card and the print-out from that .txt when I'm done with it :-).
<HWolf> Nafallo, sounds like very very dangerous behavior. :P
<Nafallo> hihi
<HWolf> What's the use of a password if you'll print it out, and carry it around.
<Nafallo> _BUT_, it will get hard for people to bruteforce that one ;-)
<Nafallo> only locked me out from 3-4 sites yet ;-)
<HWolf> Yeah, but anyone who is smart, would just try to hack your firefox. :P
<Nafallo> I won't carry it around.
<Nafallo> I will follow Mithrandir's advice about bankvalves :-)
<Nafallo> HWolf: hehe
<HWolf> For the record, I have no right to speak, I just gave my bank-pass and PIN to my mother. :)
<Nafallo> firefox has less then 30 chars :-/
<HWolf> Nafallo, so what if your pc gets robbed of you? :P
<Nafallo> HWolf: yea, I have to teach the bios to ignore ESC or something :-/
<Mithrandir> Nafallo: you can try to just cut down the password to 64 chars or other similar "magic" limits
<Nafallo> Mithrandir: worked :-9
<Nafallo> Mithrandir: thanx. you deserve another hug or something :-)
<Mithrandir> you can buy me beer when you get around
<Nafallo> hehe, if I find a way to have more money than 1,91SEK after the bills... :-P
<Mithrandir> heh
<Nafallo> i.e. current condition :-/
<Nafallo> hmm
<Nafallo> bugzilla supports 16 chars passwd :-P
<dholbach> see you later
<ddaa> Hey guys.
<ddaa> Is there some sort of official bulgarian loco guy for ubuntu?
<ddaa> I need help for making a good description of https://launchpad.ubuntu.com/products/bgoffice
<ddaa> homepage: http://bgoffice.sourceforge.net/
<JaneW> I just got an e-mail saying 'Please integrate Speedtouch USB 330(and other models) support in the next release of Ubuntu.' Is that doable, or is that one of those proprietary driver ones..?
<kiko> hey uberhackers
<kiko> countdown to bugday
<Nafallo> hi kiko :-)
<Mithrandir> JaneW: I think it's doable.  They have firmware, but the driver is free, afaik.
<seb128> elmo: drivel sync please
<JaneW> Mithrandir: thanks
<ogra> Mithrandir, isnt that already in ?
<Mithrandir> ogra: I don't know, but if not, it should be doable.
<ogra> sure, but i think its already contained
<Mithrandir> seems like there's a driver there, but I couldn't see any firmware
<Mithrandir> and the module has request_firmware in it
<Lathiat> seb128: yay drivel
<Lathiat> seb128: 2.0 i assume?
<nictuku> hi. I'm stuck in a bug that is something like debian's #266591
<martinhj> I got an idea conserning network-admin: (1) I think it should update dhclient.conf to send the current hostname to DNS/DHCP (send host-name in dhclient.conf)
<martinhj> anybody here working with the gnome-system-tools package?
<seb128> Lathiat: whatever Debian has, that doesn't matter, why?
<seb128> Lathiat: 2.0.1 atm
<Lathiat> seb128: funk (we had 1.x before, 2.0 is a *big* improvement :)
<ogra> martinhj, network-admin is likely to dissapear from our desktop since we got network-manager which will become the default for breezy
<martinhj> ogra: the one from redhat / suse rlove is working on?
<ogra> martinhj, yep, but with some adjustments and modicfications to fit into ubuntu
<martinhj> like support for the debian config files (networking/interfaces)?
<martinhj> I like that in network-admin:-)
<tseng> it uses networking/interfaces
<martinhj> tseng: sorry, I ment /etc/network/interfaces-file
<martinhj> the ...-file
<pitti> Hi mdz
<mdz> pitti: morning
<mdz> jbailey-gcc: I think we should probably do a backport of https://bugzilla.ubuntu.com/show_bug.cgi?id=11730 to Hoary; it seems to have pretty broad impact and the fix is simple and isolated
<jbailey-gcc> mdz: Okay.  It's close enough to when the Hoary snapshot was taken that if there's other patches that it depends on they'll likely be pretty small.
<mdz> jbailey-gcc: will you prepare an update?
<mdz> kiko: you are moving in on my territory, replying to months-old messages
<kiko> mdz, I'm sorry, I need to clear them out and I still have 450 unread :-(
<mdz> doko: thanks for the oo.o2 update; what's the status of the 64-bit work?
<bddebian> Hello
<mdz> bddebian: hi
<mdz> has Kamion been around today?  he was having problems with his Internet connection
<mdz> elmo: what's the word on backports?
<bddebian> Hello mdz
<lamont__> mdz: how does hoary-backports differ from hoary-updates?
<mdz> lamont__: different use case, different process
<mdz> hoary-updates policy remains unchanged, but hoary-backports will be similar to what the backports team is already doing
<pitti> Hi lamont__ 
<lamont__> mdz: ok
<lamont__> mdz: fwiw, buildd's are just waiting for w-b to believe that the suite exists
<sabdfl> mdz: i see gmail is being translated. if its in po files they might want to consider rosetta
<mdz> sabdfl: just the UI, or more than that?
<sabdfl> ui only i think
<sabdfl> not sure how they do the back end page generation, it may not involve po files
<sabdfl> but if it does, rosetta would be perfect for them
<mdz> sabdfl: I'll see if I can make contact with somebody
<mdz> interesting use case, translating web applications
<\sh> re
<jbailey-gcc> mdz: Yup.  (lagging for lunch)
<pitti> GTK BUG!
<pitti> seb128: installing the control-center build deps fails currently... for you too?
* seb128 KICKS pitti 
<seb128> pitti: which one?
<pitti> ouch
<pitti>   libgnome-desktop-dev: Depends: libgnomeui-dev (>= 2.6.0) but it is not installable
<pitti>   libnautilus-extension-dev: Depends: libeel2-dev (>= 2.9.91) but it is not installable
<pitti>                              Depends: libbonoboui2-dev (>= 2.5.4) but it is not installable
<seb128> please find the broken one with some apt-get install :)
<seb128> what arch are you using?
<pitti> i386
<pitti> seb128: how can I debug that again?
<seb128> apt-get install libbonoboui2-dev
<pitti>   libbonoboui2-dev: Hngt ab: libesd0-dev soll aber nicht installiert werden
<pitti> ah, that rings a bell
<seb128> so you screwed :)
<pitti> seb128: just uploaded a new esound...
<pitti> seb128: sorry to bother you, I owe you a beer
<ogra> pitti, _you_ create gtk bugs ?
<seb128> np :)
<seb128> fresh beer, aaaah
<pitti> ogra: sure, h4cking control-center now
<seb128> I want it NOW 
<ogra> hehe
<bddebian> jbailey-gcc!!
<pitti> ogra: I taught esound to reconnect to the sound device after changing alsa conf
<ogra> yay
<\sh> seb128: prost
<pitti> ogra: now I have to kick esd when doing that in g-sound-props
* pitti tries to pour beer through the wireless to seb128
<pitti> brzbrbzbzzzzzz
<ogra> i thought it should disappear anyway
<\sh> well...u try I drink ;)
<ogra> (not the beer though)
<pitti> ogra: I'd like to, but polypaudio still crashes too often
<seb128> pitti: do you have a public pmount revision control?
<seb128> pitti: a GNOME guy is asking on IRC
<pitti> ogra: so I want a working esound as a fallback
<ogra> ah, ok
<pitti> seb128: sure, http://people.ubuntu.com/~pitti/bzr/pmount/
<pitti> seb128: it's bazaar-ng though
<seb128> k
<pitti> seb128: I recently converted from baz to test it
<seb128> thanks
<pitti> that's also mentioned in the upstream changelog
* terrex dice: ahora s que s, me ausento. taluego
<kiko> mdz, bradb asked for monday meeting on LPI for Malone, good day or bad day?
<mdz> kiko: bad for me
<kiko> why don't you say so in the email then
<mdz> but I don't necessarily need to be there
<mdz> kiko: I'll get there ;-)
<kiko> if you don't go I won't either!
<bddebian> ANyone here work on the Live CDs?
<mdz> yes
<bddebian> How do you folks do video driver detection for X ?
<mdz> the same way that the xserver-xorg package does it (discover1)
<bddebian> Ah, we don't have xorg.. :-(
<bddebian> Do you know how knoppix does it?
<mdz> xserver-xfree86 does the same thing
<bddebian> Oh, thanks
<bddebian> mdz: Sorry to keep bugging you but does discover work in userland or Linux kernel drivers?
<mdz> bddebian: apt-get source discover1
<mdz> it is a userland program
<bddebian> Awesome, thanks
<bddebian> Most likely we don't have it in GNU/Hurd.. ;-)
<mdz> the part of it that X uses just looks up strings in a text file
<mdz> that's all it does, really (look up Linux kernel modules and X drivers in a text file)
<bddebian> So then do you folks modify XF86COnfig-4?
<mdz> no, we use X.org
* davyd twiddles his thumbs while he builds his second 2.6.12 for the night
<bddebian> Oh yeah, sorry
<Kamion> yay, finally
<pitti> Kamion: you have network again?
<bddebian> Hello Kamion
<daniels> Kamion: yo
<Kamion> pitti: yes, eventually
<bddebian> Ahh, /me just reliazed who Kamion is
<pitti> cool
<Kamion> today was basically a dead loss though
<pitti> 'lo smurfix
<smurfix> Damn power failures, even if only for 1/5th second or so :-/
<Lathiat> thats what my ups with a 10 secondbattery is for :)
<ddaa> Hey kamion
<ddaa> Kamion: some VCS questions...
<ddaa> Kamion: do you know where are the VCSes for bf-utf (boot-floopies fonts) and cdbs?
<thom> cdbs is on alioth, afaik
<pitti> GNUer: hey, what happened to your kernel? :-)
<ogra> smurfix, time to get more UPSes in your house....
<GNUer> pitti> lol
<GNUer> pitti> I shifted to Hurd
<ddaa> thom: which svn/cvs repo?
<smurfix> ogra: No. Time to use the laptop more. ;-)
<ogra> heh :)
<thom> ddaa: http://alioth.debian.org/scm/?group_id=30012
<bddebian> GNUer: Awesome ;-)
<mdz> heh, lost Kamion again
<GNUer> bddebian> :)
<davyd> so, if I sent you dudes a really creepy kernel patch, that I don't quite understand; what would you do with it?
<bddebian> GNUer: So you gonna help us with L4? ;-)
<GNUer> bddebian> I hope it's just a joke
<bddebian> Hey, what's just a joke?
<GNUer> bddebian> what you just said
<ddaa> thom: you are saying that cdbs = build-common, right?
<mdz> Kamion: welcome back
<thom> ddaa: yes
<bddebian> GNUer: What, L4?
<GNUer> bddebian> is it true that there are only a few devels working on Hurd?
<Kamion> oh my god, my IRC client is horribly confused, one sec
<mdz> Kamion: will you be able to stay awhile? ;-)
<thom> it being called the common debian build system
<bddebian> GNUer: I suppose that depends on your definition
<Kamion> it's displaying everything in one window, 1997-stylee
<ddaa> thom: it's not like the gforge page is of any help, but I already noticed build-common on svn.debian.org
<ddaa> thanks
<GNUer> bddebian> definition of ?
<Kamion> mdz: uh, maybe, gonna have to quit just now :-)
<bddebian> "only a few"
<GNUer> bddebian> compared to Linux?
<bddebian> GNUer: There are very few working on L4 yes
<GNUer> bddebian> otherwise why is its development so slow?
<bddebian> GNUer: Yes, we have "few" compared to Linux
<GNUer> bddebian> it's very sad
<bddebian> Yes it is
<GNUer> bddebian> and people are dubbing it as vaporware, bloatware, etc.
<Kamion> that's better
<Kamion> ddaa: if nobody said - cdbs has nothing to do with me, despite popular misconceptions
<GNUer> bddebian> I'd love to see a competing kernel to Linux :(
<Kamion> ddaa: I doubt bf-utf is in version control at all
<ddaa> Kamion: http://packages.ubuntu.com/hoary/devel/cdbs
<ddaa> that says "CDBS Hackers, Colin Walters, Jeff Bailey, Jonas Smedegaard, Chris Cheney and Stefan Gybas are responsible for this Debian package."
<bddebian> GNUer: I don't think the Mach iteration would ever be.  If we could get L4 going, there might be a chance
<Kamion> ddaa: *Walters*, not Watson
<mdz> Kamion: so I've gotten to the interesting part of ubuntu-express
<ddaa> ho... right.
<GNUer> bddebian> what's RMS saying about that?
<bddebian> GNUer: Who cares. :-)
<GNUer> bddebian> :)
<Kamion> ddaa: I'm extremely familiar with the confusion
<thom> it'd have been so much funnier had canonical hired walters
<mdz> Kamion: it's time to interface with grub-installer
<bddebian> thom: Hehe
<Kamion> ok, so we're going to need to pull grub-installer.postinst apart at last then
<ddaa> Here's James, and James. Daniel, and Daniel. Colin and Colin. And no, they do not all quite do the same thing, but almost :)
<Mithrandir> thom: we'd have some variety from the Janes at least. ;-)
<Kamion> mdz: sorry, this connection is just hopelessly flaky, I don't know what's wrong - it keeps randomly dropping out
<Kamion> mdz: last thing I saw was:
<Kamion> 17:52 -!- dato_ [~adeodato@84-120-79-57.onocable.ono.com]  has joined #ubuntu-devel
<mdz> Kamion: I've successfully ignored the partman stuff so far; did anything happen wrt upstream and merging partman-* into one?
<Kamion> mdz: some people liked the idea, but Anton (the primary author) was really quite against it
<mdz> Kamion: was there a thread on -boot I can look at?
<Kamion> there was, I'll see if my connection lasts long enough to dig it out
<mdz> http://lists.debian.org/debian-boot/2005/05/msg00298.html
<Kamion> you beat me to it
<mdz> Kamion: I don't find Anton's argument very convincing
<mdz> merging the existing components shouldn't make it harder to create new partman-* source packages if that's desirable
<Kamion> nor did I - I'm belatedly replying now
<\sh> who can push octave2.1 again into the buildds? :)
<mdz> \sh: infinity or lamont
<\sh> ok weekend...so we w8t :)
<mahmoud> hello...I'm recompiling the kernel to add support to the "perfctr" module...it builds and installs fine, but when it boots it complains about a missing "/lib/modules/2.6.10/modules.dep" although it's there...any idea?
<\sh> initrd kernel?
<mahmoud> hmm...what do you mean exactly?
<\sh> the first the kernel is taking is the initrd with a modules directory....or are you compiling without initrd support?
<ogra> mahmoud, why do you recompile the whole kernel for one module ? 
<ogra> mahmoud, it should be possible to just compile this module if you have the linux-heasers package installed
<ogra> linux-headers even
<mahmoud> \sh, the logs did specify the correct module path, so i don't think that's the issue
<davyd> ok, this silly
<davyd> one breezy machine has a working Tomboy
<davyd> one does not
<mahmoud> ogra, because the kernel has to be patched to support the module
<ogra> mahmoud, ah, ok... thats sad
<schweeb> davyd: blame tseng
<davyd> schweeb: can do... it feels like it must be a missing dependancy
<davyd> it appears to be looking for dbus
<schweeb> hehe, most likely
<schweeb> install libdbus-cil and libdbus-1-cil and see if that fixes it
<davyd> I have libdbus-1-cil
<davyd> neither machine has libdbus-cil
<mahmoud> guys, if you can't help me , do you have any idea where I should ask?
<davyd> also, why does restricted come up with MD5Sum mismatch?
<davyd> that sounds... unpleasant
<schweeb> some of the sources were messed up a couple weeks ago I guess
<\sh> mahmoud: take a vanilla kernel and compile it from hand
<\sh> s/from/by/
<mdz> mahmoud: http://www.ubuntulinux.org/support/supportoptions/
<mahmoud> \sh, I'm using debian kernel source packages, so do you mean i should try a kernel.org one instead?
<mdz> mahmoud: if you're using debian kernel source packages, then a Debian support channel would be the place to ask
<mahmoud> ok, thanks
<davyd> is the synaptics driver meant to do all of the scroll region jazz automatically?
<davyd> or do I need to turn that on?
<Lathiat> iirc there are options for it
<Lathiat> assuming your pad is actuallya synaptics
<kiko> yeah
<Lathiat> and not an alps
<Lathiat> theres some tool for configuring it on the fly if you have shm config on 
<davyd> it appeared to load the synaptics driver
<Nafallo> it does that automatically yes.
<Nafallo> atleast wfm ;-)
<davyd> I'll spend more time on that in a bit
<davyd> I wanted to get this machine suspending with the atheros driver
<davyd> I think it is an Alps touchpad
<davyd> I see something in dmesg about it
<Lathiat> ahh,your options are limited then
<Lathiat> Is someone able to approve a non-member post by trs80@ucc.asn.au to ubuntu-users ?
<Lathiat> jdub ?
* #ubuntu-devel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
<thierry> mmmm.... can't even install the daily build of breezy...
<Kamion> thierry: that's unsurprising
<Kamion> daily builds are often uninstallable
<thierry> is colony one possible to install?
<Kamion> should be, that's the point of it
<Kamion> thierry: what went wrong with the daily build?
<thierry> k thanks
<thierry> Kamion, well it didn't recognize any ethernet card and it didn't wanted to partition anything...
<ogra> hey azeem 
<ogra> azeem, did you pick up mako ? he didnt know if he would spend this week here or at your place....
<carstenh> yesterday, he was at the linuxtag in karlsruhe/germany
<ogra> carstenh, yes, i know....
<carstenh> ah, now i understand your question :)
<ogra> :)
<mdke> is anyone familiar with smeg? seems the version on the website for hoary is not compatible with hoary's python-xdg
<Lathiat> iirc you needed a new xdg package too
<Lathiat> ask amaranth, he wrote it i think
<mdke> yes he did
<mdke> but he's not here
<Lathiat> ah
<Lathiat> yeh iirc he had an xdg package 
<mdke> ok yeah i see it now
<mdke> thanks Lathiat 
<Kamion> thierry: oh, the installer initrds haven't been byhanded, that explains that
<Kamion> thierry: (don't worry if that made no sense)
<bddebian> Kamion / sivang: We actually have a live-cd !! :-)
* Kamion wonders if he can figure out how to do a d-i byhand
<Kamion> ah, there are the instructions
* ogra looks very astonished at Kamion
<Kamion> ogra: ?
<ogra> Kamion, i just cant belive that there are things you have to look up about d-i
<Kamion> ogra: the archive side
<ogra> ah, ok :)
<Kamion> elmo: I've byhanded debian-installer_20050317ubuntu{6,7} so that I can build working CDs with 2.6.12 (but not the dailies, and I haven't removed the old installer-* dirs because doing 'sudo -u katie rm -rf blah' scares me)
<Kamion> elmo: I used the old d-i-images instructions, updated to breezy
<mdz> mvo: ping?
<bddebian> mdz: Does discover use /proc ?
<mvo> mdz: pong
<mvo> mdz: just send you a mail 
<mdz> mvo: I am having problems merging daf's archive as well, and wanted to see if you had the same trouble
<mdz> but I think daf and I just figured out that problem
<mvo> mdz: I merged apt--mvo--0 into apt--main--0 without problems
<mdz> mvo: yes, that is very strange
<mvo> mdz: do you use the same version of baz than I do? 1.4.2?
<mdz> mvo: yes
<mdz> latest breezy
<mvo> yes, same here
<mvo> odd ...
<mvo> is your version of apt--main--0 patch-92 too? and apt--mvo--0 at patch-32?
<mdz> mvo: your mirror only has patch-30
<mdz> heh, both this problem and the one with daf were the result of outdated mirrors apparently :-)
<mvo> I did a archive-mirror
<mvo> and it tells me there is nothing to mirror (/me checks again)
<mdz> I'll try again
<mvo> there is a patch-32 dir on p.u.c:~/mvo/arch/ubuntu
<mvo> all is very odd ...
<mdz> mvo: works now
<mdz> zsh: segmentation fault  baz merge apt--main--0
<mdz> lifeless: ^^
<hub> daniels: you blog software is over buggy
<daniels> hub: no, planet is crap
<daniels> hub: my articles all have the same publication date as they did to begin with
<daniels> hub: keybuk removed the pubDate checking on his branch because people kept screwing up their pubDates
<daniels> hub: notice how p.fd.o isn't affected
<hub> then it planet ubuntu that is crap ?
<Yann2> daniel > I'm just coding a planet for ubuntu-fr
<Yann2> might it interest you?
<daniels> hub: it's scott's branch of planet (which is used on p.d.o and p.u.c) which is broken
<Yann2> it's based on dotclear ( a very well known french blog system) and magpie
<daniels> Yann2: not really.  i only really maintain one planet (p.fd.o), and that works fine.
<Yann2> ok :)
<hub> Yann2: oh no
<hub> Yann2: pla.nit.ca has lot for fix because it i
<hub> use magpie
<Yann2> magpie seems to work quite fine
<mdz> mvo: works now
<hub> Yann2: magpie has issues with dotclear :-)
<Yann2> really? :|
<Yann2> can't be, I already saw a rss reader for dotclear using magpie
<Yann2> seemed to work good
<Yann2> well, I'll see ^^
<Yann2> began this afternoon, should be ready tomorrow =)
<Yann2> hub > wait wait wait you already did a planet with dotclear?
<daniels> Keybuk: fix planet, dude
<Keybuk> daniels: fuck off
* daniels basks in the love.
<bddebian> Keybuk!
<hub> Yann2: no. my boss did a planet in PHP using magpie, and I use dotclear for my blog and that caused a lot of problems
<hub> Yann2: http://pla.nit.ca/
<Yann2> what kind of pbs?
<mehrfachstecker> hi
<bddebian> Hello mehrfachstecker 
<mehrfachstecker> does anybody know what the format of the initrd is in hoary?
<Keybuk> daniels: get Jeff to fix it
<mehrfachstecker> hi bddebian
<daniels> Keybuk: i thought his branch was dead?
<Keybuk> daniels: my branch is dead too
<daniels> Keybuk: bonus
<littlepaul> mehrfachstecker, it is cramfs http://ubuntuforums.org/archive/index.php/t-21104.html
<Keybuk> daniels: I don't run a Planet, so have no use for the code
<mehrfachstecker> thank in advance
<mdz> mvo: why did your tree have a modified po/he.po?
<mdz> mvo: it conflicts with the one in bubulle's tree
<daniels> Keybuk: any idea if anyone else has taken up a branch?
<Keybuk> none
<daniels> 'kay
<mvo> mdz: I didn't modifiy that he.po file deliberately. please just undo it
<mvo> mdz: good to hear that it works now
<mdz> mvo: 0.6.38ubuntu1 uploaded
<StylusEater> hello
<StylusEater> who can I talk to about helping with "XFCE-buntu??"
<mvo> mdz: cool! I'll merge with your trees now
<crimsun> StylusEater: me.
<mdz> mvo: I have merged your tree and daf's into mainline, and am working on merging bubulle's now
<StylusEater> crimsun: may I pm you?
<mdz> StylusEater: it would be better to discuss it here; there are others who are involved and interested
<StylusEater> great
<StylusEater> well...where do we start? I don't want to interupt any prior discussions
<crimsun> StylusEater: just speak what's on your mind presently
<StylusEater> well...let me give you a brief synopsis of who I am first?
<tseng> sure, you might want to make yourself a page on the wiki also
<StylusEater> my background isn't really programming...I've done a fair share of "web programming," some basic, and some perl and bash scripting...
<crimsun> StylusEater: (it'd be more efficient to just add yourself to wiki/MOTUXfce)
<StylusEater> k
<StylusEater> lemme go check
<tseng> yep make a page of YourName, fill out your deails and make a link https://wiki.ubuntu.com/MOTUXfce
<tseng> that will be very helpful to use if you want to pursue member/maintainership status later
<bddebian> It ain't helping me. ;-P
<tseng> huh?
<ogra> is anything wrong with the archive scripts ? the source of libsigcx's ubuntu1 version is here, http://archive.ubuntu.com/ubuntu/pool/universe/libs/libsigcx/, according to the build logs it was built last week, but doesnt show up in the archive....
<StylusEater> https://wiki.ubuntu.com/UserPreferences <-- Ok I went there and I don't see a "sign-up" page
<StylusEater> I also tried https://wiki.ubuntu.com/StyluEater and was unable to edit the page
<bddebian> StylusEater: You have to create an account on Launchpad first
<StylusEater> I am looking for that link
<mdke> the account can be created at wiki.ubuntu.com
<bddebian> It can?
<mdke> sure
<StylusEater> should be able to
<mdke> click login
<StylusEater> it's a "wiki"
<StylusEater> mdke I did
<bddebian> I was never able to without creating my lauchpad account first
<mdke> perhaps i'm wrong
<mdke> ok StylusEater http://launchpad.ubuntu.com
<mdke> will report that as a bug
<bddebian> mdke: Well most likely I am incorrect.  I don't know if I have been right yet here :-)
<mdke> no i think you're right bddebian 
<mdke> just looking now, there is a paragraph on how to sign up, but the dialogue is wrong
<StylusEater> yup
<StylusEater> it's hard to find how to sign up
<StylusEater> there isn't a "sign-up" link on the front page of the wiki
<tseng> signing up will get more obvious at some point
<tseng> there are plans to continue single sign on to other ubuntu services
<mdke> yes
<StylusEater> tseng: please don't think I am criticizing just noting
<mdke> the wiki thing is a pretty bad hack
<mdke> to reconcile the Ubuntu auth with the moin login dialogue
<tseng> just saying, it should greatly improve at some point
<Simira> for those interested: I will bring some Ubuntu t-shirts to Debconf. More information and price will be on the -user mailinglist as soon as I figured out the price
<crimsun> StylusEater: please contact me via email (crimsun at fungus dot sh dot nu), I have family plans this afternoon and have to leave in a few minutes. Thanks for your interest.
<mdke> Simira, awesome :)
<mdke> Simira, do you ship them at all?
<StylusEater> crimsun: what would you like me to say?
<Simira> mdke: it's coming... we've ordered 250 for a start. There will be a webshop in time...
<mdke> fantastic
<bddebian> Bah, why go to Debconf when there seems to be such tension with Debian? :-)
<Simira> I'll ship to Europe only, probably
<crimsun> StylusEater: any ideas you have regarding it from the bottom up
<StylusEater> okie doke
<mdke> Simira, that's cool, i am in europe :D
<Simira> bddebian: there are reasons for and against... I've been encouraged to ignore the conflict
<mdke> i think that is the best approach
<mdke> love heals any wounds
<crimsun> StylusEater: for instance, live cd only or install? what sort of infrastructure?
<bddebian> Aye, I was being somewhat fecisous
<bddebian> whoops, didn't spell that right
* Simira will pour lots of Ubuntu-love onto DebConf :D
<crimsun> StylusEater: (do we go minimal or install most of ubuntu's base so that things like automounting removable devices works?)
<mdke> where is this debconf?
<ogra> mdke, helsinki
<daniels> PITTI
<crimsun> StylusEater: cya 'round.
<mdke> ogra, ah nice
* daniels weeps.
<daniels> dear martin,
<daniels> please don't upload a new version of a library package that has an incompatible abi
<ogra> what did he break ?
<daniels> especially if I'm the one that gets to clean up after it
<daniels> cheers,
<daniels> daniels
<bddebian> So is #ubuntu-love only active on "love days" ?
* ogra is confused....
<tseng> ogra: dbus 0.34
<ogra> how did debian Bug#315891 end up in my mailbox ?? strange things happen...
<ogra> tseng, ah
* tseng kicks his pbuilder
<ogra> gah, why does the debian bugtracking system send BCC mails.... grr
<StylusEater> crimsun: tata for now
<StylusEater> dohh...what was crimsun's e-mail addy again?
<bddebian>  crimsun at fungus dot sh dot nu I think 
<lifeless> mdz: backtrace ?
<daniels> lifeless: go back to sleep.  freak.
<Simira> smurfix: ping
<smurfix> Simira: 
<lifeless> daniels: touche
<StylusEater> cool thx bddebian
<StylusEater> I haven't figured out how to "backtrace" in irssi yet
<ajmitch> morning
<daniels> lifeless: real people aren't awake this early
<daniels> lifeless: only cyborgs.  and street sweepers.  and cyborg street sweepers.
<lifeless> daniels: which are you ?
<daniels> lifeless: jetlagged and still awake
<lifeless> ahh
<HrdwrBoB> daniels: and some people with Real Jobs
<lifeless> HrdwrBoB: no such thing
<daniels> HrdwrBoB: if you have time to be on IRC before you go to work, you have time to still be asleep
<HrdwrBoB> daniels: I'm making coffee
<daniels> HrdwrBoB: i would still be awake if sydney wasn't so stupid
<StylusEater> ok...so my page is up
<daniels> turns out my flight from bangkok to melbourne went through sydney
<daniels> so I'm there for an hour, sweet, get Krispy Kreme
<StylusEater> if y'all would like to read it:  https://wiki.ubuntu.com/StylusEater
<daniels> but no, that's on the outer side of immigration
<daniels> which I Must Not Pass for various reasons
<daniels> so I don't have anything to sugar-rush on for hours
<pitti> infinity: already up?
<daniels> ah, pitti!
<daniels> pitti: please don't upload new versions of dbus which change the abi kthx
<pitti> daniels: erm, 0.34 did?
<daniels> i believe so, yes
<pitti> hrm, sorry...
<mdz> lifeless: unreproducible
<pitti> daniels: major changes?
<daniels> pitti: no worries.  don't think it's caused any actual damage, just surprised me when I saw it.
<daniels> pitti: nah, tiny little ABI tweaks.  they rarely make any worthwhile ABI breaks ;)
<pitti> ok, good to hear; I just merged the Debian version
<mdz> lifeless: I've actually got everything merged now, which is good (for apt) but bad (for reproducing the baz crash)
<pitti> daniels: I hope they won't do again by 1.0...
<daniels> pitti: they will
<mdz> lifeless: I went looking for "baz missing --diffs".  is there something which actually exists which does what I want?
<mdke> smurfix, piiing
<smurfix> mdke: ?
<mdke> smurfix, just to report, we have two bots on #ubuntu-it-meeting
<mdke> http://ubuntu-de.org/logs/freenode/2005/06/26/%23ubuntu-it-meeting.html
<smurfix> gah. I'll go check
<lifeless> mdz: what do you want ?
<dholbach> hey!
<ogra> mdke, ubuntu-it-meeting ? why dont you just use ubuntu-meeting ?
<ogra> hi dholbach 
<mdke> ogra, i guess cos it might cause clashes
<mdke> -fr has one too
<ogra> oh, really ? 
<mdke> we have been having lots of meeting recently so we just made a separate chan
<mdke> also the language of meeting isn't english, so it might annoy people who idle in that chan
<mdke> dunno
<ogra> mdke, yes, sounds sane .... i was just wondering... :)
<mdke> :)
* siretart updated https://wiki.ubuntu.com/REVU with all questions (and answers) I got today
<siretart> argl. sorry, wrong channel
<ogra> siretart, probably not ;)
<siretart> ;)
<mdz> lifeless: I want approximately "show me the diffs for the patches in tree foo which are not in tree bar"
<mdz> lifeless: though "show me the diff which would result from this merge" would also suffice
<pitti> mdz: merge - diff - undo?
<Mithrandir> mdz: baz diff $anothertree or isn't that what you mean?
<mdz> Mithrandir: depends; what does that do?
<mdz> pitti: yes, that is similar to the functionality I am looking for in a single command
<Mithrandir> mdz: I _think_ it does exactly what you want.
<mdz> Mithrandir: I think it does the reverse of what I want, but I can make that work
<mdz> hmm
<mdz> baz diff <tree foo> from within tree bar gives me something which is sort of the reverse of what I want
<mdz> baz diff <tree bar> from tree foo blows up
<mdz>     arch_valid_package_name (name, arch_maybe_archive, arch_req_package, 1)
<mdz> baz: uncaught exception: -1:(exiting on botched invariant)
<mdz>   please report this as a bug to bazaar@lists.canonical.com
#ubuntu-devel 2005-07-02
<lifeless> mdz: hmm
<lifeless> baz diff $other-tree gives you the manner in which this tree has diverged from the last merge of the two
<lifeless> so get bar, diff foo should work
<lifeless> what exact command line are you using ?
<Mez> mako: ping
<Mithrandir> lifeless: I suspect he's doing baz diff /home/mdz/whatever.
<lifeless> Mithrandir: so do I ;0
<mdz> Mithrandir: I was doing baz diff fully@qualified/branch--name
<mdz> which works in one direction and blows up in the other
<lifeless> mdz: --version on there ?
<mdz> yes
<lifeless> mdz: mmmm, does baz missing fully@qualified/branch--name from there show the base-0 ?
<mdz> mizar:[~/src/deb/mine/arch/apt/ubuntu]  baz diff michael.vogt@ubuntu.com--2005/apt--ubuntu--0
<lifeless> i.e. has it never been merged ?
<mdz> ^^ works
<mdz> mizar:[~/src/deb/mine/arch/apt/ubuntu]  cd ../mvo-ubuntu mizar:[...eb/mine/arch/apt/mvo-ubuntu]  baz diff apt@packages.debian.org/apt--ubuntu--0
<mdz> ^^ doesn't
<mdz> lifeless: hmm, good question
<mdz> I wonder whether mvo created his ubuntu branch based on main, rather than based on my ubuntu branch
<mdz> baz missing does show the base-0
<lifeless> if so, congrats, thats a bug
<lifeless> ok, nice find three.
<mdz> in both cases
<lifeless> so
<lifeless> enough info gathering
<lifeless> there are three different scenarios here
<lifeless> the actual content of the patches is usually not interesting : its the aggregate *without merges from you* that is interesting.
<mdz> the question I'm trying to answer in this instance is "what sort of stuff has he got in this branch?"
<lifeless> right.
<lifeless> the way I would usually answer that is to merge his branch, and then run diff
<lifeless> because that gets rid of noise created by merges from mutual peers even if he hasn't merged from yuu
<mdz> yes, I've done that in the past
<Mithrandir> I think diff $branch should do the same thing as merge + diff.
<mdz> and I would very much like to be able to do it a) in one step, b) without modifying my working directory (or even having one at all)
<lifeless> if you want to see a plain rollup of his patches, you can do this in one step:
<mdz> baz diff <rev> <rev> would be eawesome
<lifeless> baz delta --diffs <rev> <rev>
<mdz> but that's not the same; that's just a straight "how is this different from that", isn't it?
<lifeless> right
<lifeless> baz diff is just a straight how is this different from that - with a hueristic on what to call 'this'
<mdz> "dump all the diffs from the revisions in `baz missing <foo>`" is approximately the right semantic
<lifeless> so - 
<mdz> this ties into my earlier craving for a way to do get-changeset && show-changeset --diffs in one step
<lifeless> perhaps baz delta --diffs $(baz missing foo | head -n1) $(baz missing foo | tail -n 1)
<mdz> that sounds about right
<lifeless> show-changeset needs to take a revision and get it out for you - absolutely agree
<mdz> I'm not sure whether I would prefer to have the diffs rolled up or separate
<mdz> probably rolled up most of the time
<lifeless> 'baz mdz foo' ;0
<Mithrandir> lifeless: no, that won't work in all cases, since you might have done a sync-tree from a tla user and so not have all your own (or somebody elses) patches.
<Mithrandir> which is kinda funky.
<lifeless> Mithrandir: this is why merge is the right way
<Mithrandir> lifeless: yup
<lifeless> but merge is different because it involves resolving conflicts etc
<Mithrandir> lifeless: so I think diff $tree should be merge + diff the trees.
<mdz> lifeless++
<lifeless> mmm
<lifeless> diff tree says 'how is my tree different to that tree'
<lifeless> 'diff' on its own says 'how is my tree different to what I checked out'
<lifeless> I don't think adding merge to 'diff' is right from a UI or behavioural point of view
<lifeless> merge requires human intervention for starters
<lifeless> that said, there should be something fairly simple to do what you want
<lifeless> mdz: so what about merge + diff, or get + diff frustrates ?
<lifeless> i.e. what do I need to shave off to make it a reasonable answer ?
<mdz> lifeless: merge+diff, for one, gives me conflicts
<lifeless> thats what I mean by human intervention
<lifeless> I guess the question I'm asking is :
<mdz> both merge+diff and get+diff require that I store some stuff on disk just for the purpose of asking the question, and then clean it up afterward
<lifeless> 'Do you want to see what they have put in their branch', or 'Do you want to see what you would be merging'
<mdz> I want to be able to ask both of those questions
<lifeless> from your working tree.
<mdz> the latter makes sense in a working tree
<mdz> the former seems like a reasonable question to ask without having a working tree
<mdz> mako: around?
<carstenh>  I received a approval from google for my application ("Ubuntu Firewall Managing Tool"). do you already know who will be my mentor or whom i should contact?
<mdz> carstenh: we'll contact you via email soon
<mdz> after the weekend
<carstenh> mdz: ok, thanks :)
<mdz> carstenh: congratulations and welcome :-)
<ogra> carstenh, hey, you are in trier ?
<carstenh> thanks
<carstenh> ogra: yes
<dholbach> carstenh: HEY!
<dholbach> :)
<carstenh> ogra: and you are from?
<dholbach> i'm from trier!
* ogra grets from blankenheim....
<ogra> greets even
<dholbach> (originally)
<dholbach> where do you live there?
<dholbach> the world is SO small :)
<carstenh> dholbach: martinskloster, i study at the university of applied science
<dholbach> ROCK cool :)
<carstenh> yes, it is :)
<dholbach> this is funny :)
<carstenh> ogra: where is blankenheim?
<dholbach> "in der eifel" :)
<ogra> beginning of eifel... 
<carstenh> ah, not far away :)
<ogra> yeps :)
<ogra> carstenh, nice to have you aboard :)
<dholbach> absolutely
<pitti> night guys
<ogra> night pitti 
<carstenh> ogra: dholbach: were anyone of you at the ksp yesterday?
<ogra> carstenh, which one ?
<carstenh> linuxtag, organized by weasel
<ogra> nope, i wasnt at linuxtag
<carstenh> this was my  my first lt this year :)
* ogra wasnt at _any_ linuxtag yet....
<dholbach> me neither
<ogra> i should probably have been there
<mdke> question: is kubuntu and ubuntu intended to be installable on the same system with no issues?
<mdke> is/are
<ogra> mdke, only space issues
<mdke> ogra, so its worth filing bugs when they don't live happily as a family?
<ogra> mdke, yeps... they should play nicely together
<mdke> ok
<mdke> in bugzilla?
<mdke> kubuntu is handled in bugzilla too still?
<ogra> mdke, if you wanna file against a -desktop metapackage....
<mdke> yeah probably a good idea
<mdke> i guess most of the issues are well known
<carstenh> does kubuntu count as an extra debian derivat?
<carstenh> (is was not on makos list)
<ogra> carstenh, rather as a ubuntu derivative
<carstenh> ah, ok.
<mdke> hmm
<ogra> mdke, ?
<mdke> i've heard lots of people report issues with their .ICEauthority file when running both kde and gnome, but a search in bugzilla for ICEauthority shows nothing
<ogra> mdke, but ts a known issue that kde changes permissions of that file
<ogra> i had such a case today in #ubuntu-de
<mdke> yeah well known
<mdke> strange that there is no bug open on it
<ogra> yep
<ogra> but i guess you had to change quite essential bits in KDE to make it work right
<Seveas> ah, so that is it!
<Seveas> Does that cause gnome to freeze when trying to log in?
<mdke> yeah you can't log in
<ogra> Seveas, exactly
<Seveas> I've seen a ZILLION cases of that on #ubuntu
<mdke> yep
<ogra> yep
<mdke> answer is to delete the file
<ogra> lol
<Seveas> Never knew what it was :)
<robitaille> mdke: https://bugzilla.ubuntu.com/show_bug.cgi?id=2053  (maybe?)
<Seveas> Another thing to add to my FAQ database :)
<mdke> robitaille, saw that yeah but i think it is dated now, kde IS supported
<ogra> hmm, robitaille ....
<mdke> the bug was closed due to kde not being supported
<mdke> maybe it could be reopened, or a new bug filed
<robitaille> yes, that old bug was pre-kubuntu
<ogra> robitaille, wouldnt you like to take a central role in our upcoming bugday ? you are really the best bugzilla guy i know outside the main team :) 
<mdke> oooh
<mdke> Burgundavia will be upset
<mdke> :)
<robitaille> ogra:  when is it going to be?
<ogra> heh, they can share the load mdke :)
<mdke> yup
<ogra> robitaille, we planned it for the 29th
<robitaille> but it is true I have done little bit less of bugzilla right when Burgundavia started doing more. Strange timing :)
<ogra> :)
<ogra> smells like a bugzilla team :)
<robitaille> ogra:  but sure, I can help.  Not sure I would qualify it as a "central role" since most of that day I'll be at work, but I can help
* mdke holds his nose
<ogra> robitaille, think about it... i'll write a cross post announcement tomorrow ...
<mdke> mdz, do you think it is worth reopening #2053? or opening a new bug? probably hundreds have that error
<karlheg> Why doesn't highlight then middle-click to paste work right anymore?  I've used the X Window System since 1995, and it has always worked until recently.  Firefox highlight to emacs middle click is not doing what it should.  Any ideas?
<karlheg> I wish that Firefox had the middle-click paste of a URL opens a tab and gets the page like it used to also.
<karlheg> And it really ought to have the long-standard C-a, C-e, C-k bindings in text fields too.
<tseng> support questions are in #ubuntu
<lsuactiafner> karlheg : press shift while you paste
<tseng> or even better, to firefox
<karlheg> Ah.  I have to press a key now?
<karlheg> tseng, Sorry... I viewed it as a devel question since it used to Just Work but something has changed.
<mdke> highlight middle click works here
<mdke> this is def. a #ubuntu question imo
<tseng> its a devel question if you want to talk about fixing a bug, basically
<tseng> it not really a bug at all, it "works as designed"
<tseng> and is not specific to ubuntu
<karlheg> I can't get it to work unless I use C-c in Firefox, then middle-click in Emacs.
<karlheg> Annoying itch, but livable for now.
<lsuactiafner> highlight middle also works here.
<mdke> yep
<sladen> karlheg: we disabled the middle-click paste in the main window.  It confused people who didn't expect.  You can enable it by typing 'about:config' in the browser URL bar and searching for 'middle'
<karlheg> tseng, It's "broken as designed".  You are supposed to be able to highlight, then middle-click to paste anywhere and everywhere in X.
<karlheg> It's annoying enough to have to use CUA bindings everywhere, and then they insist I push C-c to get a pasteable copy.
<mdke> karlheg, two people have told you that it works for them
<ogra> karlheg, Apache/2.1.3 (Ubuntu) Server at people.ubuntu.com Port 80
<ogra> karlheg, just pasted as you described
<ogra> mark and middle click
<mdke> three people
<karlheg> So I guess if I really want to change that I have to develop a key-mapping library everything can use or something... so not every program has to implment re-bindable keymaps to support both traditional and CUA bindings.
<karlheg> Huh.  Peerhaps it's an emacs setting then.
<karlheg> I'll check that.
<ogra> might be, i'm a vim user
<karlheg> sladen, ! Thank you.  Is that a FAQ?  It really ought to be an option in the main configuration dialog.
<ajmitch> perhaps it it an issue as to which clipboard selection is being used, too
<karlheg> I just highlighted from xchat and pasted with middle click to emacs.  It's some kind of interaction between the URL location bar in Firefox and Emacs that's not right.
<karlheg> Perhaps it's a Firefox setting or missed line in it's programming?  I don't know enough about X programming to know what the cause could be.  Enough said; no bug; I'll quit flooding.
<sladen> karlheg: if you know enough to miss it, you know enough to use about:config
<sladen> karlheg: you can paste in the URL bar with middle-click.  that works as expected.
<karlheg> sladen, I've never heard of about:config until just now.
<karlheg> But the URL bar already has text in it.
<sladen> karlheg: it's the middle-pasteing in the middle a window that confuses people.  Especially when they use my thinkpad and can't tell what caused the page to "randomly" change
<sladen> karlheg: I agree, I use the feature all the time
<sladen> precisely because the URL bar has text in it
<karlheg> sladen, We should wishlist that it ought to be a visible configuration option in the main preferences dialogs.
<sladen> karlheg: go for it
<karlheg> Where should I file that?  Firefox, or Ubuntu?
<ogra> Firetech, 
<ogra> err firefox
<sladen> karlheg: Ubuntu (we turned it off from the default) IdeasPool on the wiki
<ogra> sladen, for a config option ?
<karlheg> I suppose Firefox, unless the Ubuntu maintainer knows the internals well enough and can code it, otherwise, he'll just proxy the bug rep.  I may as well save him some work.
<sladen> karlheg/ogra: good point
<karlheg> sladen, Off by default is Ok, it's that it's not in preferences.  Adding it to that will require coding.
<karlheg> There's a 'clipboard.autocopy' option that's set to 'true' by default.  No matter what it's setting, Firefox highlight in page does not middle-click paste in Emacs.
<karlheg> *sigh*
<karlheg> All of the other apps on my desktop work as I would expect, so it's something to do with how Firefox is programmed or configured.
<ogra> karlheg, but since firefox highlight->middleclick paste works everywhere else i'd rather call it an emacs bug
<karlheg> 26-Jun-2005 23:19  273
<karlheg> Ah.  I can highlight/paste from Firefox to xchat.
<karlheg> It's something to do with how they interact.  I'll not file a bug until I understand X clipboard more.
<karlheg> Maybe there's some reason it's supposed to work the way it does?
* karlheg adds another item to his reading stack...
<karlheg> Wow.  I just restarted Firefox, and now it works right.  I did not change the 'clipboard.autocopy' setting; I toggled it, but then back to default.
<karlheg> I give up.
<karlheg> You win, Firefox.
<mdz> mdke: if the problem still exists, yes
<mdke> mdz, thanks. I'm not an expert because I haven't tested it, but we get loads of people on the mailing lists and irc about that problem, which it seems isn't caused by k3b only, but kde in general
<mdz> mdke: yes, I expect it affects most any KDE program run with root privileges and HOME still set to the user's home directory
<ogra> mdz, this prob will exist eternally unless KDE fixes its handling of ICEAuthority
<ogra> AndyFitz !!
<mdz> ogra: we are arguably doing the wrong thing by running it with this environment, but it could be more robust, certainly
<jp> I just restarted my pc, and there was a partition verification, now when I go to home/jp/x  there's not the most important stuff for me, I lost 500 mbs of pics and some videos cool im happy :)
<mdke> mdz, so you think that bug or new bug?
<mdz> mdke: might as well reuse the bug
<ogra> a evil hack would be to change the permissions before/during login...
<stuNNed> can i ask ques about applying a patch?
<jp> I wanna cry 
<ogra> stuNNed, sure
<mdz> ogra: better would be to fix it so that the ownership is preserved
<ogra> mdz, yep
<stuNNed> ogra: so i can 'apt-get source package' in a dir, then tar zxvf original_package, cd
<ogra> mdz, but that would require a lot of KDE changes i guess
<stuNNed>                  to that dir, apply a patch, then run 'dpkg-buildpackage' within that dir and
<stuNNed>                  all is well and dandy?
<mdke> jp, sorry to hear that, if you try #ubuntu they might be able to help you with data recovery
<stuNNed> dang sorry lol
* stuNNed can't do nothing right :(
<mdz> ogra: I wouldn't expect so, but I haven't looked
<jp> thanks mdke ! i go to there now :)
<mdke> mdz, actually I can't reopen that bug
<mdke> guess permissions
<ogra> mdz, i'm no KDE expert either, but thats the way i know KDE to work
<mdz> mdke: have you read and understood the bug handling guidelines in HelpingWithBugs?
<stuNNed> ogra: sorry, my ques is i can 'apt-get source package' then 'tar zxvf orig_package', apply a patch, then from within that dir run dpkg-buildpackage and all is well and dandy?
<mdke> mdz, no
<mdz> mdke: if you would, I'd be delighted to give you editbugs
<mdke> mdz, i will do so and let you know when I do
<ogra> stuNNed, something like that, yes... you can omit the tar step
<mdke> in the meantime perhaps someone else can reopen #2053
<AndyFitz> g'day ogra
<ogra> stuNNed, apt-get source will unpack everything for you...
<mdke> --> bed
<ogra> AndyFitz, we need to talk abuout icons :)
<ogra> AndyFitz, i'm supposed to package them :)
<stuNNed> ogra: trying the publish to calendar patch, see if it works against current Hoary evo, latest, the patch applied cleanly
<AndyFitz> ogra, excellent !!! :D
<ogra> stuNNed, see the PbuilderHowto on the wiki, if you can build it there, itsfine
<stuNNed> ok thanks, ogra 
<jp> I want to die I lost the most important stuff for me, only for restart by power button, that never happened to me on windows xp, that's why I did it on linux, trsting on linux
<jp> i'm just crying
<carstenh> jp: which filesystem do you use
<jp> carstenh etx3 dood
<jp> ext3 sorry
<carstenh> hmm, no undelete :(
<jp> yep
<ogra> but probably a lost&found
<jp> what filesystem is the most secure?
<jp> reiser?
<ogra> nope
<jp> no ogra jp@shawn:/lost+found $ du -sh >> 48K     . >> jp@shawn:/lost+found 
<ogra> sad
<jp> ogra nope <- so what? ext3?
<carstenh> jp: did you already fsck it?
<jp> carstenh yep, it's clean
<ogra> ext2/3 ist the most reliable/mature ... 
<carstenh> jp: all are more secure than reisser
<jp> ops :)
<carstenh> s/ss/s/
<ogra> carstenh, s/s/ss ;)
<ogra> (only for germans)
<carstenh> ogra: substitute ss with s
<jp> huh im chilean
<ogra> carstenh, yes, but he is very "reisserisch" about it :)
<ogra> (i mean has reiser)
<carstenh> ogra: ah, ok. didn't get it the first time
<ogra> s/has/hans
<carstenh> .oO(reisswolf-fs)
<ogra> hehe
<ogra> jp, that was a german joke, sorry, i can understand youre not in a joking mood...
<jp> oh ok
<ogra> jp, this is a rather advanced task but you could try this one http://www.tldp.org/HOWTO/Ext2fs-Undeletion.html
<ogra> oh
<Mez> ogra: ping
<ogra> Mez, poooong
<Mez> Just as an FYI - I'm rebuilding the latest version of k3b for breezy
<Mez> 0.12-1ubuntu1
<Mez> (or at leat it will be when it's finsihed building and being fixed etc
<ogra> Mez, nice, coordinate with Riddell 
<Mez> Already am ogra ;)
<Mez> one of the conditions of my ubuntu membership was to keep you in the loop with the KDE stuff :P
<ogra> great :)
<Mez> hence why I'm telling you :P
<Mez> (plus i may need your help in a mo)
<Mez> I added libxi to the Build-Depends as it was moaning that ld -lXi wasnt working... 
<Mez> libxi-dev * 
<ogra> ok
<dholbach> i'll call it the day
<dholbach> have a nice evening
<tseng> cya dholbach 
<ogra> night dholbach 
<stuNNed> ogra: so i'm assuming with pbuilder i want to set up a chroot'd breezy?
<dholbach> stuNNed: it does it for you
<Mez> stuNNed, that's what I ahev
<dholbach> stuNNed: pbuilder is LOVE
<ogra> stuNNed, just follow the howto
<Mez> lol :D yeah follow the howto
<Mez> It's confusing as hell iof uyou're using 2 differnt base tgz's though
* Mez has nice sed commands linked up to change from one to another
* stuNNed follows the howto :D
<ogra> Mez, why would you use two different base tgz's ?
<ogra> Mez, we only compile for breezy
<Mez> ogra - one for breezy, one for backports ;)_
* Mez is also a backports developer
<ogra> ah
<stuNNed> ogra: yeah cuz even though the patch to publish calendar applied cleanly to hoary evo it crashes, ack
<bob2___> why would the upstream tarball differ?
<Mez> ogra - sdo we wnat the new HAL stuff in k3b or not ?
<tseng> dude
<tseng>        --basetgz [basetgz-location] 
<tseng>               Specifies the location of base.tgz
<bob2> ah
<Mez> yeah tseng... I know
<Mez> b ut I cant be arse dto type that everytime where i cna type
<ogra> Mez, what does Riddell say ? 
<Mez> buildbreezy
<tseng> so make an alias
<Mez> or buildhaory
<Mez> and it'll change the pbuilder
<Mez> he's AFK
<Mez> well... asleep
<Mez> he mentioned that it was there... didnt say whether to nable it
<ogra> Mez, but you really should coordinate with him
<Mez> tseng... those are aliases :D
<Mez> fair enoug h:D
<Mez> I'll ask him when he wakes up then
<ogra> Mez, since he is the KDE guy here, i really cant give you a hint on using HAL in KDE...
<ogra> since i dont know the status of HAL in KDE :)
<Mez> hmm
<Mez> If I remember what he said propelry... they're trying to shove it into 3.5 properly...
<Mez> or makling improvements on it
<ogra> Mez, you really want to talk to Riddell ... i know HAL support is planned...
<Mez> I was too busy laughing at how scared he loked
* Mez shoulda payed attention
<Mez> lol ... I swear he left bricks all over the stage :D
<Mez> is ffmpeg a Restricted format?
<ogra> nope
<ogra> (its in uni, not multiverse)
<Mez> ah
<Mez> FFMpeg decoder plugin (decodes wma and others):
<Mez> that would be restricted
<ogra> Mez, yep, but its very broken currently, i'm in charge of it, but waiting on a new upstream release
<Mez> fair enough
<Mez> I'll leave that option OFF :S
<Mez> Hmm... riddell's replacement for KControl = sexy
<tseng> oh man, planet stoner
<tseng> this is the worst flood ive ever seen
<Mez> ogra, cna you give me a slap when that's fixed then ?
<ogra> Mez, sure
<Mez> then cna decide whether to rebuild k3b with it (though i doubt we will)
<ogra> Mez, but i can only wait for a version that cmpiles at least with gcc-3.4 ...
<Mez> ?
<ogra> Mez, the current prob with ffmpeg is, that it doesnt compile with any of the ubuntu provided compilers...
<Mez> lol - why not ?
<ogra> Mez, ask upstream :)
<Mez> I mena what comile errors? (or completely built for random compilers?)
<Mez> Is it like redhat brekaing the world?
<ogra> yep, something like that
<lsuactiafner> while on the topic of wmv.. 64bit ubuntu need a static 32bit binary for wmv files and a normal 64bit binary for other files
<Mez> ah I remember redhat breaking the world
<Mez> that was fun
<lsuactiafner> maybe not static since there are 32bit libs in 64bit ubuntu, but definatly a 32bit binary and yes i did mail the maintainer ect
<ogra> anyway, its 3am (nearly) and GF is moaning i should go to bed...
<Mez> lol - lucky you ogra
<ogra> so night everybody...
<Mez> mine noirmally moans around 1sam
<Mez> shame she aint really ehre now...
<Mez> aint here now really *
<ogra> heh
<Mez> could do with someone to cuddle up to
<karlheg> Why does 'dpkg-source -x' tell me that the .tar file suffix is unrecognized?
<karlheg> There's a tar.gz and that's listed in the .dsc.
<Mez> karlheg, are you passing it the .dec file?
<karlheg> Yes.
<karlheg> dpkg-source -x hotplug-light_0.0-1.dsc
<karlheg> dpkg-source: error: unrecognised file suffix `.tar'
<Mez> weird
<bob2> so, look at the .dsc
<bob2> is it a native package with a non-native version?
<karlheg> Native; and looking in there was the first thing I did when it did not work.
<bob2> er
<bob2> that version is non-native
<bob2> so, fix the source so it's a .orig.tar.gz + .diff.gz
<stuNNed> hmmm so with pbuilder now i can get evo from breezy, patch it, and build it?
<karlheg> Huh.  There's no diff.gz listed in the .dsc, and not one on his DL site either.
<bob2> yes, of course
<karlheg> It certainly is a non-native version number, I see that now that you point it out.
<bob2> if you're packaging it, you make the .diff.gz yourself
<infinity> bob2 : Erm, but '-x' should only warn, not error.  Making it impossible to UNPACK old broken native/non-native packages is wrong.
<bob2> infinity: haven't people been complaining to scott all week a bout that?
* infinity summons keybuk.
<karlheg> \infty I agree.
<infinity> karlheg : Anyhow, there's nothing stopping you from unpacking it manually.
<karlheg> The voices in my head won't let me.  They say it's unclean and sinful.
<karlheg> ;-p
<bob2> but you do need to fix this
* karlheg is doing it despite their warnings...
<bob2> that package shouldn't be native
<infinity> The voices in your head are silly, then.  Since "dpkg-source -x" on a native package is identical to "tar -xzf foo.tar.gx"
<karlheg> Ok; will network with maintainer, md.
<Mez> infinity, keybuk is probably still drunk from LRL
<karlheg> I wonder if this is hotplug-ng or a different thing... (haven't looked yet)
<karlheg> Was there discussion wrt hotplug-ng, udev, initramfs, etc that was recorded where I can read it; anyone know off hand, or should I search?
<stuNNed> i'm assuming i need to 'pbuilder login' to build breezy builds on hoary system?
<Mez> stuNNed, read the howto
<Mez> https://wiki.ubuntu.com/PbuilderHowtohttp://wiki.ubuntu.com/PBuilderHowto
<Mez> https://wiki.ubuntu.com/PbuilderHowto *
<stuNNed> yes but the example there says 'apt-get source bc' which grabs from hoary, is there way to 'apt-get source bc' from breezy?
* stuNNed is still reading
<carstenh> -t
<carstenh> night
<lifeless> stuNNed: if you have breezy src-deb lines, you can (IIRC) go apt-get source breezy/bc
<stuNNed> lifeless: ah ok thanks
<stuNNed> doh thanks
<Mez> any C++ coders here cna help me out a lil - fix this k3b probelm
<lifeless> Mez: whats the problem ?
<Mez> can i /query you lifeless?
<Mez> there may be a lot f files tuff
<Mez> ../../../../plugins/decoder/flac/k3bflacdecoder.cpp: In member function 'virtual QString K3bFLACDecoder::technicalInfo(const QString&) const':
<Mez> ../../../../plugins/decoder/flac/k3bflacdecoder.cpp:320: error: request for member 'get_field' in '((K3bFLACDecoder::Private*)((const K3bFLACDecoder*)this)->K3bFLACDecoder::d)->K3bFLACDecoder::Private::comments-> FLAC::Metadata::VorbisComment::get_vendor_string()', which is of non-class type 'const FLAC__byte*'
<Mez> is how it's bombing out
<Burgundavia> ogra, bugday
<Burgundavia> ogra, I can make myself free the whole day if needed
<lifeless> Mez: that probably means that someone changed the type of get_vendor_string()'s type
<Mez> lifeless... it's a bit confusing
<Mez> ifdef FLAC_NEWER_THAN_1_1_1
<Mez>       return QString::fromUtf8((char*)d->comments->get_vendor_string());
<Mez> #else
<Mez>       return QString::fromUtf8(d->comments->get_vendor_string().get_field());
<Mez> #endif
<lifeless> well there you go
<lifeless> you probably have a flac that is newer than 1.1.1
<lifeless> but that define isn't set
<Mez> I've no idea how to find that
<lifeless> check configure ;0
<Mez> o ffs
<sladen> flac -v
<sladen> or `pwd` ...
<Mez> yeah breezy uses 1.1.2
<Mez> actually it looks like it is getting the newer version of flac... but.... not having it properly
<Mez> Changed the signature of FLAC::Metadata::VorbisComment::get_vendor_string() and FLAC::Metadata::VorbisComment::set_vendor_string() to use a UTF-8, NUL-terminated string const FLAC__byte * for the vendor string instead of FLAC::Metadata::VorbisComment::Entry.
<Mez> I thik the .get_field is an error
* Mez crosses gfingers
<stuNNed> how to apply a .patch to a tar.gz file?
<bob2> er
<bob2> presumably you want to apply it to the source within, right?
<stuNNed> yes
<bob2> and the .tar.gz is the .orig.tar.gz, right?
<stuNNed> yes
<bob2> so include the changes in your .diff.gz
<bob2> or use dpatch and put the patch in a seperate file in debian/patches/whater
<stuNNed> ok let me try
<stuNNed> the 1st method
* Mez can never remember how to use dpatch properly
<Mez> so i build one as if i'd just done it manually
<Mez> then extract the package and grab the changes from the change file in there
<lifeless> hctness
<fabbione> morning
* Lathiat laughs at tseng
<Lathiat> "Rebuild for this weeks d-bus API"
<pitti> Morning
<fabbione> hey pitti
<pitti> infinity: what's the status of the amd64 buildds?
<pitti> infinity: if that is still broken, any chance to do an exceptional binary upload for the amd64 ruby security update?
<fabbione> all the amd64 buildd are down?
<pitti> fabbione: well, the ruby build killed two of them
<fabbione> ah
<fabbione> so it was YOU killing the buildd!
<fabbione> :P
<fabbione> crimsun: ping?
<crimsun> fabbione: pong
<fabbione> crimsun: how safe is alsa 0.9.0+ that has been pushed to Linus for .13 inclusion?
<infinity> pitti : Yeah, If we're going to do a by-hand build, I'd have to do it at home.  I don't feel the urge to kill yet another buildd.
<crimsun> fabbione: 1.0.9+?
<fabbione> meh yeah
<fabbione> that one
<crimsun> fabbione: do you have link to the log handy?
<fabbione>   ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-git-2005-06-22.patch.gz
<crimsun> oh, that's safe
<crimsun> that includes the 1.0.9a (and 1.0.9b, which Thomas and Jordi already applied)
<fabbione> ok
<pitti> infinity: depends on what the ETA for fixing that is...
<infinity> pitti : -ENOELMO
<pitti> infinity: since it is remote arbitrary code exection, I'd like to fix that ASAP
<pitti> hm
<pitti> infinity: can I build it on concordia? or will that kill concordia as well?
<infinity> concordia runs the same kernel as the buildds, so you could end up blowing it up too...
<fabbione> pitti: concordia will die like all the others
<pitti> hm :-(
<infinity> concodia's chroots may also be a bit unclean.
<pitti> fabbione: it crashes during a debhelper call (dh_shlibdeps or so)
<infinity> If we're going to bypass the buildds (ugh), I'd rather have some control over the build environment.
<fabbione> pitti: i saw that.. the dmesg output is rather scary
<fabbione> [ANNOUNCE]  ndevfs - a "nano" devfs
* fabbione sighs
<fabbione> not another dynamic /dev implementation :/
<pitti> the famous last words of the petunia bowl
<pitti> Hey dholbach 
<dholbach> hi
<dholbach> hey pitti
* dilinger attempts to not think about what fabio just pasted
<infinity> dilinger : THinking is bad for your health.
<fabbione> dilinger: dude.. that's on LKML... and it already gave me headacke for being monday :P
<fabbione> who is part of the dbus team?
* dholbach points blindly at daniels :)
<fabbione> daniels: dude?
<fabbione> elmo:
<fabbione> dpkg-checkbuilddeps: Unmet build dependencies: libncurses5-dev libc6-dev-ppc64
<fabbione> can you please install the above on davis/breezy chroot?
* infinity wonders about elmo's 91 idle hours on IRC.
<fabbione> infinity: well just queued the request :)
<pitti> german guys: did you see the HP/Ubuntu article in the c't? :-)
<dholbach> no, not yet
<siretart> moin
<pitti> Hi siretart 
<siretart> infinity: do you happen to have access to the universe uploaders keyring?
<siretart> I'd like to import it to the uploaders keyring of http://siretart.tauware.de/revu/index.py
<pitti> hi jordi
<dholbach> hey jordi  :)
<hunger> When will the new linux-restricted-modules for breezy become available?
<pitti> Hi carlos
<pitti> hunger: before that we want the final version
<pitti> (of 2.6.12)
<hunger> pirr
<hunger> pirr
<carlos> morning
<hunger> pitti Arg... typing is broken today:-)
* pitti has to relogin, brb
<jordi> hi pitti, daniel
<dholbach> so who of you joins the review day? :)
<hunger> dholbach: review day?
<dholbach> hey mvo 
<dholbach> hunger: yeah, we're trying to regain control on wiki.ubuntu.com/MOTUToReview and wiki.ubuntu.com/MOTUNewPackages
<mvo> hey dholbach, morning all!
<hunger> dholbach: Ah, ok. So it is nothing I can help with.
<dholbach> hunger: hope to see you there soon ;)
<hunger> dholbach: Nice of you to say so, but you do not want me there... I tend to break everything I touch:-(
<dholbach> hunger: that's a good start :)
<dholbach> morning sabdfl, morning ivoks :)
<sabdfl> hey guys
<pitti> Hi sabdfl
<dholbach> how is it going?
<hunger> dholbach: ... and I am even too stupid to register properly on the ubuntu pages, so I guess I failed the MOTU intelligence test;-)
<dholbach> hunger: if you keep on trying, ... :)
<jsgotangco> morning
<dholbach> jsgotangco: hey jerome! :)
<hunger> dholbach: Well... I keep on thinking of switching to gentoo... as I have to build so much stuff on my own anyway:-(
<pitti> dholbach: is today the mega-review day?
<dholbach> hunger: erm? why is that?
<hunger> dholbach: My laptop is too new for breezy:-(
<dholbach> pitti: yeah, we desperately needed it
<hunger> dholbach: Well, actually gentoo has way older packages, so that is not an option either... looks like I am stuck with you;-)
<dholbach> hunger: you should get in touch with the guys fixing this kind of stuff and help them fix it
<jsgotangco> dholbach, hey! how was your weekend?
<dholbach> jsgotangco: busy :)
<hunger> dholbach: Yeap... I probably should do that.
<dholbach> jsgotangco: i took a break from thesis/learning for the REVIEW DAY! :)
<dholbach> hunger: absolutely
<dholbach> morning doko
<dholbach> jsgotangco: how are you?
<hunger> dholbach: But there seems to be little interesst into exotic stuff like getting my TPM working (and the prerequisits are not even there in ubuntu yet).
* Amaranth tries to remember who is doing the laptop stuff
<jsgotangco> dholbach, not bad, actually my week started with a delivery of a new rack server at home for a client project for Oracle
<dholbach> hunger: if nobody knows about the problems, it's unlikely to happen
<jsgotangco> dholbach, strange thing is that Ubuntu runs perfectly on the system while RH AS 3.0 won't
<Amaranth> isn't RH AS up to 4.0?
* dholbach hugs his Ubuntu... it behaves so well
<jsgotangco> ES rather
<jsgotangco> Amaranth, yeah, its already 4.0 but some Oracle applications still want 3.0
<jsgotangco> sometimes 2.1
<jsgotangco> (RapidStart for instance)
<hunger> dholbach: I might end up making some noise about the TPM stuff once the 2.6.12 kernel is in breezy.
<dholbach> does anybody else get "wrong password" in the wiki?
<jsgotangco> it would have been great if the RapidStart people in Thailand actually get the thing to run in Ubuntu
<Amaranth> hunger: It's in.
* dholbach points at ivoks_reviewer - watch that dedication :)
<hunger> Amaranth: Yeap, but the restricted modules are still missing... which stops net from working on my laptop. No fun;-)
<Amaranth> ah, fun
<ivoks_reviewer> dholbach: :))
<Lathiat> hunger: the restricted modules is nto the problem
<Lathiat> hunger: the problem is you have the wrong laptop ;p
<dholbach> i hope we won't end up in so big lists next time, but i'm confident with http://siretart.tauware.de/revu/index.py around
<opi> morning
<hunger> Lathiat: It is not the laptop, that works fine. It's the OS!
<dholbach> hey opi, it's review day - i just had a look at your acpitool
<opi> dholbach: bah! I need to fix two things at least
<opi> dholbach: remove hard deps (GCC and stuff)
<opi> dholbach: and.. add better description
<opi> dholbach: I was flooded with work lately :-(
<dholbach> don't worry
<daniels> fabbione: er
<fabbione> daniels: if you can, would you be so kind to remove mono support in dbus for sparc?
<daniels> fabbione: yeah, will do
<fabbione> daniels: thanks a lot dude
<daniels> np
<\sh_reviewtime> wasabi: ping
<mae> Hrm, does ubuntu plan to include NetworkManager into breezy?
<bob2> udu.wiki.ubuntu.com/NetworkMagic
<dholbach> hey bob2
<bob2> hey dholbach 
<bob2> oh crap
<dholbach> i wasnt going to complain
<mae> what about native eclipse.. does ubuntu plan to pick that up too? :)
<dholbach> :)
<bob2> :)
<dholbach> mae: udu.wiki.ubuntu.com/JavaRoadmap
<\sh_reviewtime> wasabi: eclipse is broken :) the /etc/jvm.d/eclipse is missing...u don't install it anywhere ;)
<dholbach> morning sbastien
<seb128> hey dholbach :)
<mae> hehe
<pitti> Hey seb128 
<seb128> hello pitti
<mdke> can you guys log into the wiki? I can't right now
<dholbach> mdke: no, me neither
<dholbach> mdke: i'm making notes - this feels so 1980 ;)
<\sh_reviewtime> i can :)
<\sh_reviewtime> i actually logged in
<mdke> ok \sh_reviewtime gets to do all the work
<dholbach> hahaha
<mae> udu some sort of acronym?
<mdke> mae, yes, see the frontpage of that wiki
<dholbach> mae: ubuntu down under
<dholbach> mae: which was the codename of the last conference - should be all on the wiki itself :)
<mdke> yes it is
<mae> heh
<mdke> elmo, dholbach and I can't log into the wiki and are getting withdrawal symptoms, is there anything you can do?
* dholbach hugs mdke :)
<mae> well i've been messing around with network manager on fc4 and it looks pretty promising.. it works perfectly with wired connections but it gets messed up when i unplug the wire and it goes to the wireless connection :)
<mdke> dholbach, you're delirious
<bob2> the best bit is how it oopses the ipw2100 driver
<dholbach> mdke: and you're soooo funny :)
<mdke> ;)
<mae> hehe well i'm running a broadcom chip through ndiswrapper and its screwing up.. pretty sure its NM and not ndiswrapper tho
<fabbione> carlos: so.. i am looking at the initrd
<fabbione> both the drivers are there...
<fabbione> but you say that none of them is loaded?
<carlos> fabbione, not sure with the final 2.6.12, previous one didn't load anyone
<dholbach> bbl
<carlos> fabbione, at least, the verbose boot didn't show me anything about megaraid
<carlos> fabbione, with my home made kernel that includes the new driver inside the kernel I get the old one loaded too so perhaps it's a problem of both drivers being in conflict
<fabbione> carlos: yes.. i think i found why
<fabbione> no the problem is that none of them is claiming directly the LSI Logic / Symbios Logic MegaRAID vendor ID
<fabbione> so basically both of them are probed or none
<carlos> hmm, the new driver documentation lists my card as supported
<carlos> so they forgot to add the ID?
<fabbione> carlos: either they missed the ID or i did a wrong split.. but i am checking now
<fabbione> the next upload should have the proper fix
<fabbione> -       {PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_AMI_MEGARAID3,
<fabbione> -               PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
<fabbione> this is from the old driver
<fabbione> but there is no equivalent in the new one apparently
<fabbione> so that's an easy fix :)
<fabbione> or should be
<fabbione> carlos: i will have a test kernel for you as soon as you wake up again
<carlos> fabbione, cool. thank you
<carlos> fabbione, btw, my card is an Intel SRCS16
<fabbione> carlos: that's why i asked for lspci -n
<fabbione> carlos: the 1000:1960 match is only in the old driver
<fabbione> carlos: it's much easier to track ;)
<fabbione> as you can see from the normal lspci, it shows up as LSI
<carlos> fabbione, yeah, it also says LSI when I boot the computer
<carlos> so not sure if it's correct or not
<fabbione> the LSI is the vendor (1000)
<fabbione> the Symbios Logic MegaRAID (1960) shows an AMI Megaraid 3 chipset
<fabbione> Intel probably only assembled the overall
<fabbione> and sold it as its own card
<carlos> fabbione, ok
<Kamion> pitti: don't we already have the final 2.6.12?
<pitti> no :-(
<pitti> linux-image-2.6.12-1-k7 | 2.6.11.94-1.2 | http://archive.ubuntu.com breezy/main Packages
<pitti> linux-source-2.6.12 | 2.6.12-2.1 | http://archive.ubuntu.com breezy/main Packages
<pitti> linux-source-2.6.12 | 2.6.12-2.1 | http://archive.ubuntu.com breezy/main Sources
<pitti> martin@donald:~$
<fabbione> Kamion: yes we do
<pitti> Kamion: the source, yes, but no debs
<fabbione> carlos: can you please add the last info for me ?
<fabbione> carlos: lspci -vvv
<fabbione> carlos: i need to see some subsystem info
* Amaranth could have sworn his k7 image was 2.6.12-2
<Kamion> linux-image-2.6.12-2-k7 | 2.6.12-2.1 |        breezy | i386
<Kamion> pitti: ^
<pitti> argh, new ABI
<pitti> thanks
<fabbione> carlos: nevermind :) i found it
<carlos> fabbione, too late, I added it already :-P
<fabbione> #define PCI_DEVICE_ID_INTEL_RAID_SRCS16                 0x1960
<fabbione> #define PCI_SUBSYS_ID_INTEL_RAID_SRCS16                 0x0523
<mpt> seb128: Is "Go to font folder" Ubuntu-specific?
<seb128> no
<mpt> ta
<seb128> np
<fabbione> HMMM
<mae> anaconda sucks
<mae> so does yum and up2date
<Amaranth> mae: iow you hate everything that isn't debian?
<mae> well, no, just based on my experience.
<bob2> fabbione: 2.6.12 from breezy won't boot on hoary, right?
<mae> yum by itself is a very elegant piece of software, it makes rpm *alot* nicer.. but the fact that rpm dependency information is traditionally stored only in the headers of the packages themselves, it is painfully slow. :( yum search takes at least 30 seconds
<fabbione> bob2: you can't install 2.6.12 in hoary without a few other packages
<bob2> hrm
<fabbione> bob2: and please don't even suggest that to people
<bob2> fabbione: oh, I won't, this is for me :)
<bob2> I want 2.6.12 for the x40 IRDA love
<fabbione> the dependecies can't be satisfied without some stuff
<mae> hehe
<Amaranth> bob2: Use breezy? :)
<fabbione> bob2: well you know what to do than :)
<fabbione> bob2: i think it can boot... let me know :P
<bob2> hahaha
<bob2> thanks fabio :P
<fabbione> brb
<mae> Amaranth, I don't hate everything thats non-debian :) aside from those three qualities RH is a very polished distro, right down to the very cursor and icon themes.
<Amaranth> ugh, bluecurve
<mae> and the nice graphical tools to configure servers
<bob2> Amaranth: was planning to hold out until X stays working for 2 days in a row ;p
<Amaranth> it's worked for weeks for me (more or less)
<ivoks_reviewer> mae: and you don't have to download whole Packages.gz just for one changed packag
<ivoks_reviewer> mae: one downloads only new headers of that package...
<mae> ivoks_reviewer, yes, and when you want to download that 1 package yum proceeds to download every header of every dependency and the depencies of those depencies and so on and so on if you want to install it :)
<ivoks_reviewer> :)
<mae> debian you dl it up front, redhat just toys with you
<mae> i mean, i dont mind d/l'ing one packages.gz .. the dependency calculation is so much faster
<ogra> happy review day everybody
<ivoks_reviewer> wouldn't it be better if packages.gz would be devided per package?
<ivoks_reviewer> ogra: you too :)
<pitti> Hey ogra
<dholbach> hey ogra :)
<bob2> ivoks_reviewer: that would add more delays
<bob2> unless you pipelined
<mae> I'm on a satellite connection so "yum search" takes literally 1-2 minutes sometimes. because of the many connections it has to establish.  doing any yum operation is pure torture
<bob2> ivoks_reviewer: a better solution would be storing diffs between Packages files on the server, so you only need to download the changes
<ivoks_reviewer> bob2: even better
<ivoks_reviewer> pitti: hi! i'm bit confused with CUPS in ubuntu, could you help me figure it out? :)
<pitti> sure
<mae> ivoks_reviewer, I am not trying to be a pundit, but I just tried out an rpm distro a few days ago and I got so mad..  I mean I don't even understand why RH still uses it, its awful
<ivoks_reviewer> pitti: lpadmin group has every right to do with CUPS, right?
<pitti> yes
<ivoks_reviewer> pitti: and lp doesn't have any rights... basicly, unused group?
<pitti> ivoks_reviewer: no, group lp has the privilege to access printer devices directly
<ivoks_reviewer> ok
<pitti> ivoks_reviewer: /dev/lp* and so on
<pitti> ivoks_reviewer: no user should be in that group
<ivoks_reviewer> but user, not in groups lp or lpadmin can print
<pitti> yes
<ivoks_reviewer> but can't delete it's print jobs
<pitti> but only through cups
<pitti> yes, I have a bug about that
<ivoks_reviewer> i submited it :)
<pitti> ah, ok :-)
<ivoks_reviewer> ok, so there is no way to create user that will be unable to print? :)
<pitti> ivoks_reviewer: that should be discussed
<pitti> we could introduce a group that has printing privileges
<ivoks_reviewer> i tought so, yes
<pitti> but of course that will lock out all existing users out there
<ivoks_reviewer> i just suggested wrong group
<ivoks_reviewer> pitti: true
<pitti> ivoks_reviewer: well, it's not so bad, lpadmin should be allowed to print anyway
<ivoks_reviewer> but having all users able to print... makes hard creating print server
<pitti> ivoks_reviewer: and on upgrade it will be necessary to put other users into the "printing" group if appropriate
<ivoks_reviewer> that would be easy
<ivoks_reviewer> check out who is in lpadmin
<ivoks_reviewer> and add it to printing
<ivoks_reviewer> that would requiere changing users-admin tool, too
<mdke> can anyone else fix wiki login?
<mako> Mez, mdke: yes yes
* ogreview shakes his head about the repository thread .... people in #ubuntu are not average users ???
<ivoks_reviewer> :)
<ogreview> hey marilize :)
<mdke> mako, is that a yes, you can fix it?
<ivoks_reviewer> mae: rpm has lots of disadvantages, true (sorry for late reply)
<mae> ivoks_reviewer, hehe np :)
<mae> hey what do most of you guys use for a development env.. i haven't been able to get used anything but vi.
<mae> but vi doesn't have code-completion or any other of those nifty time-savers :)
<Lathiat> yes it does, your just not using it properly :)
<mae> Lathiat, enlighten me?
<Lathiat> im not sure of the secifics i dont use it much
<Lathiat> ^x-
<Lathiat> <blah> stuff
<Lathiat> can complete function names, other words in the files, etc
<daniels> mdz: ping
<fabbione> carlos: still awake?
<Kamion> mae: ctrl-n, ctrl-p
<Kamion> mae: assuming you're using vim, as you probably should be if you want a development editor
<mako> mdke: i think that was a nick completion error :)
<ogreview> Kamion++
<ogreview> :)
<Kamion> oh, just my luck, fabbione's hammering concordia
<fabbione> Kamion: i can stop immediatly
<Kamion> nah, it's ok, I can cope with a bit of latency once I know why it's there
<fabbione> Kamion: done.. all your
<daniels> Kamion: XORG BUILD O'CLOCK
<fabbione> no problem.. i was only doing a test build
<fabbione> nothing important
* pitti starts to sing "How many builds must an X.org package go down..."
<Kamion> fabbione: all yours again
<iwj> Hello people.
<fabbione> Kamion: danke
<Kamion> morning Ian
<daniels> pitti: about one for every day I'm away, AFAICT :P
<daniels> iwj: good morning
<dholbach> morning iwj 
<pitti> Hello iwj, welcome 
<iwj> Just popping in for half an hour at the moment, to say hello.
<lifeless> welcome iwj 
<mdke> mako, ah k
<fabbione> hey iwj 
<Kamion> mjg59: new CD image for HP building now, should be ready within fifteen minutes or so
<fabbione> YAY for ABI changes!
<iwj> What kind of hours does mdz keep ?
<pitti> ogreview: D'oh, what's the point in beagle if I only get exceptions, and the daemon immediately crashes if I start it manually? :-(
<dholbach> pitti: enjoy brandnew software :)
<daniels> iwj: late West Coast
<iwj> Right.
<Kamion> iwj: typically turns up around 4 or 5pm London time, and continues until well after I go to bed
<pitti> dholbach: yes, but... "FATAL: Could not set extended attributes on a file in your home directory."
<daniels> iwj: typically seems to sleep around 1000 UTC, wake up at about 1800 or thereabouts
<pitti> dholbach: that's just *stupid*
<dholbach> pitti: ah yes... you have to change something to your filesystem's mount options :)
<seb128> pitti: do you use user_xattr ?
<dholbach> pitti: add user_xattr
<pitti> no, I don't use that stuff
<seb128> you should
<ogreview> pitti, defaults,user_xattr
<pitti> that thing is supposed to read my files, not mess up my ~...
<pitti> yes, I read it on the wiki page
<seb128> ah ah
<seb128> just don't use beagle :)
* pitti reconsiders grep -r
<pitti> well, I'll give it a try at some day
<Treenaks> I've tried beagle... but I just don't seem to need it
<ogreview> Treenaks, hey, its hip to use it :)
<dholbach> i reviewed kat (kde's equivalent) and after spitting out 20mbs of sqlite file it stopped dead :)
<dholbach> fancy desktop search has still some child diseases it seems
<seb128> beagle sucks atm imho
<Treenaks> ogreview: oh sure, it looks nice
<dholbach> seb128: my french harry potter books arrived - i'll bug you with silly questions soon ;-)
<Treenaks> ogreview: but I just don't need it :)
<seb128> dholbach: cool :)
<ogreview> Treenaks, nobody needs it, but you have to have it  ;)
<seb128> people working on ffmpeg, Debian has a new snapshot of the CVS :p
<ogra> seb128, thanks
<\sh_reviewtime> seb128: u said the wrong word ;-)
<ogra> seb128, but i doubt it will compile
* ogra goes trying
<Treenaks> ogra: it's mono. it eats too much memory. and my ~ layout is sane :)
<ogra> Treenaks, yes, but youre out of fashion then.... only using grep isnt zeitgeisty
<Treenaks> ogra: I don't really care :)
* ogra is always happy to use this word :)
<Treenaks> ogra: weird German words :)
<ogra> Treenaks, its english :) thats why its so funny
<Treenaks> ogra: where do you think they stole it? :P
<ogra> hehe
<carlos> fabbione, hi
<ogra> infinity, could you have a look at libsigcx ? it was uploaded last thursday, according to the build log it built, but the ubuntu1 binaries didnt get copied to the archive
<fabbione> carlos: yo dude.. http://people.ubuntu.com/~fabbione/ get initrd.img-2.6.12-2-686.new
<fabbione> carlos: replace the one in /boot created by the installer and let me know if that one work :)
<carlos> fabbione, dude, we are in the same time zone. I was sleepy because I just woke up when you pinged me :-)
<carlos> fabbione, ok
<fabbione> carlos: ehhehe thanks
<seb128> elmo: gnome-terminal drivel sync please
<carlos> fabbione, it boots now. Thanks!
<fabbione> carlos: cool.... now please don't upgrade the kernel for the next release if i don't tell you to do so
<fabbione> the driver is ok
<carlos> ok
<fabbione> it's the initrd creation that needs fix
<fabbione> basically when the initrd is created, it still sees the old module loaded for that controller
<fabbione> and it assumes that the module will be the same
<fabbione> i need to add a one line hack in it
<fabbione> so that it will load both of them
<fabbione> there is no conflict.. it was simply not loaded at all
<infinity> ogra : Did it contain NEW binaries?
<carlos> hmm, it does not looks like it has an easy solution
<ogra> infinity, nope its CXX transition stuff
<ogra> infinity, and it holds up other packages :/
<carlos> unless I create it without that module loaded
<dholbach> ogra: the   *c2  stuff is a new binary package
<infinity> ogra : If it's CXX transition stuff, then it must have had new binary packages.
<fabbione> carlos: nah i can just fix it.. don't worry.. 
<ogra> infinity, dholbach err, yes, right
<dholbach> ogra: so it'll need manual review
<carlos> ok
<infinity> ogra : So, yeah.  It's waiting on someone to push it through the NEW queue.
<fabbione> carlos: i need to make an initrd-tools upload with that fix BEFORE the next kernel :)
<carlos> fabbione, thank you for your time
<infinity> Kamion : ping.
<fabbione> carlos: no, thanks to you for helping hunting down the bug
<carlos> fabbione, btw, I have another one about the network card, in case you are bored and taskless :-)
<fabbione> carlos: is that a sk98lin?
<carlos> but I'm not sure it's a kernel problem (althought it came with 2.6.12)
<carlos> no
<fabbione> 8139cp ?
<carlos> yes
<carlos> 8139cp
<fabbione> known upstream bug
<fabbione> i read the thread this morning
<carlos> It works, but I need to turn on the network by hand
<carlos> every time
<carlos> becasue hotplug gets confused
<carlos> is that the problem?
<fabbione> carlos: it's not just hotplug
<infinity> Kamion : libsigcx needs some NEW love for it's binaries, if you could be so kind.
* infinity -> leaving work.
<carlos> fabbione, will wait for the fix then, in the mean time, an 'ifup eth0' fixes it
<fabbione> carlos: according to the report, it cannot send traffic at all
<Kamion> infinity: OK, will do shortly, just catching up on activity reports
<carlos> I can
<carlos> fabbione, so perhaps is not the same problem...
<fabbione> carlos: hmmm .... i think i know what it is... 
<carlos> fabbione, the problem I get here is that I see an error about being unable to map eth0
<carlos> and the network is not loaded, but an 'ifup eth0' fixes it
<fabbione> carlos: that's a grepmap issue i think.. it's not kernel related. i see tthat one too here with other cards
<fabbione> ifup eth0 doesn't modprobe the driver
<fabbione> the driver is already loaded at that point
<carlos> but it came with 2.6.12
<carlos> 2.6.10 does not have that problem
<fabbione> carlos: it did come with breezy
<fabbione> i could see that with 2.6.10 too
<carlos> fabbione, breezy + 2.6.10 works
<carlos> here
<fabbione> and iface configured via dhcp
<fabbione> if i switch to static ip it works fine
<fabbione> but i had really no time to look at that
<carlos> well, I can wait, it's my home server so I don't reboot it too often
<fabbione> carlos: ok.. 
<bob2> hrm, is it possible to add to the pci ids a driver recognises at runtime?
<Lathiat> bob2: why on earth would you want to do that
<Mithrandir> uhm, why on earth are the host entries in my ssh known_hosts file base64 encoded?
<Mithrandir> Kamion: ^^
<daniels> Mithrandir: it's new and shiny.
<daniels> you can disable it if you like
<Mithrandir> base64 is old and crufty.
<Kamion> Mithrandir: see the changelog and/or the NEWS file
<tseng> Mithrandir: 64 > 32
<tseng> :)
<Mithrandir> it's terrible, I don't have base64grep.
<Kamion> Mithrandir: use ssh-keygen to manage known_hosts
<daniels> HashKnownHosts
<Kamion> Mithrandir: it has new options to do it
<Mithrandir> Kamion: that's such a wrong tool to do that. :-)
<Kamion> Mithrandir: blame upstream :-)
<Mithrandir> Kamion: blaming openssh upstream sounds like the right thing, yes.
<bob2> Lathiat: because the x40 ir port is supported by the nsc-ircc driver, but the id wasn't added until 2.6.12-rc1
<Mithrandir> bob2: ah, that's right, but it's a trivial patch.
<bob2> yeah
<Mithrandir> bob2: or you could get my nsc-ircc which works, iirc.
<Kamion> Mithrandir: but the exact location of the functionality is not all that relevant; in any case, the point was to slow down attacks that discover other hosts to attack by browsing through known_hosts
<bob2> but it still requires a rebuild :)
<Mithrandir> bob2: I have the module if you trust me.
<hunger> Damn, the tpm fix I need did not make it into 2.6.12.1.
<Kamion> Mithrandir: also, base64 is only the armouring; it's actually a SHA-1 hash
<Mithrandir> Kamion: it sounds utterly unuseful, but I digress.
<Kamion> I disagree; I thought about it before enabling it (it's not the upstream default yet, although they want testing)
<ogra> seb128, no go for ffmpeg :(
<azeem> Sheesh, look at how Canonical is treating its employees:
<azeem> http://people.debian.org/~mbanck/photos/lt2005/img038.jpeg
<seb128> what's wrong with this one?
<daniels> haha
<daniels> he looks like mother teresa for some reason
<ogra> azeem, yes, we dont even can buy shoes :)
<Mithrandir> I wonder how many miles that water bottle has traveled.
<daniels> ogra: speak for yo'self
<Kamion> infinity: libsigcx NEWed
<ogra> seb128, the same.... it breaks with a ton of assembler errors on i386.... at least it builds unpatched on amd64 now ...
<ogra> so its a step further...
<ogra> but only a small one
<mdke> anyone awake who can fix the wiki yet?
<ogra> Kamion, thanks a lot , that held up a bunch of other packages
<ogra> seb128,  error: PIC register '%ebx' clobbered in 'asm'
<Kamion> fabbione: will you kill me if sparc stops being debootstrappable for a bit? I haven't quite worked out what to do with lib64gcc1's priority
<fabbione> Kamion: no problem at all
<fabbione> Kamion: if you need access to the sparc to work out stuff, or need me to check something, just tell me ok?
<Kamion> sure - I'm trying to juggle all the architectures at the moment though :)
<daniels> Kamion: by the way, I'm going to switch to the libdl-based loader tomorrow, so most architectures should be broken
<daniels> Kamion: and also split xserver-xorg up into one package per driver and remove xlibs-dev
<daniels> Kamion: but seriously.  if I do the xserver-xorg thing, and have xserver-xorg Recommend each driver package, will dist-upgrades bpull the Recommends in?
<Kamion> I think my trollmeter just went off
<daniels> Kamion: having xserver-xorg Depend on each driver seems to defeat the point a little.
<Kamion> daniels: no
<daniels> Kamion: (i'm serious about the xserver-xorg one-package-per-driver thing)
<daniels> Kamion: hm.  shit.
<Kamion> daniels: aptitude can be configured to do that, but apt-get won't
<Kamion> why one package per driver? the facility to have third-party driver packages, sure, but it seems a little bit for-the-sake-of-it
<daniels> preparing for what will happen when we drop the modular server into breezy
<daniels> whereby every driver is built externally, for obvious reasons
<daniels> also makes driver fixes a *lot* easier
<Kamion> the only way to make upgrades work, that I can think of, is to make xserver-xorg a metapackage and move the actual server somewhere else
<daniels> hm
<daniels> i was thinking of that, but there are lots of xserver-xorg | xserver-xfree86 depends I'd need to chnage
* fabbione food
<daniels> although xserver-xorg-core and xserver-xorg-driver-* sounds appealing
<daniels> (later to become libxserver-dix and xserver-xorg-core)
<HiddenWolf> daniels, should we keep our fingers crossed?
<daniels> i'm still working out exactly what's happened to xorg
<fabbione> carlos: is there any way i can get ssh access to your box?
<carlos> fabbione, sure
<fabbione> carlos: cool
<carlos> fabbione, you should have the login information in your mailbox
<fabbione> carlos: thanks
<carlos> fabbione, do you need extra priviledges?
<fabbione> not sure yet
<carlos> ok
<fabbione> carlos: it doesn't like the passwd
<carlos> fabbione, that's because I'm so stupid that closed the user and admin dialog without saving the changes...
* carlos creates the account :-P
<fabbione> ahaha
<carlos> fabbione, try again now.
<fabbione> carlos: much better :)
<fabbione> carlos: i need sudo mkinitrd privileges
<daniels> mdz: unless you have any objections, -33 will change autodetect_* behaviour
<daniels> mdz: they'll all become temporary flags (i.e. need to be set every time before you run it), and dpkg-reconfigure will automatically set them all to true
<daniels> mdz: actually, bugger that
<daniels> mdz: nevermind me
<mdke> are the changelogs for security updates available somewhere?
<Treenaks> mdke: in the packages ?
<mdke> apart from that
<Lathiat> and on changelogs.u.c, if you use update manager you can look at them when you update
<jordi> JaneW: ping
<mdke> Lathiat, ok thanks that's what I wanted
<mdke> Lathiat, i can't find the security changelog for the kernel update on that site, do you know where it might be?
<mdke> Lathiat, nm
<opi> morning sabdfl 
<sabdfl> hiya
<pitti> moin sabdfl 
<ajmitch> hi
<ivoks> hi
<mdke> sabdfl, hi! are you able to resolve the wiki login being down?
<jbailey> Kamion: No, ppc64 systems do not require libc6-ppc64 to work.  I tihnk for now it can safely be pulled in as a dependancy. 
<JaneW> jordi: pong
<daniels> mdz: heads-up: force_keyboard_detection is being renamed to autodetect_keyboard in -33
<Kamion> jbailey: dependency of what?
<jbailey> Kamion: ANything that eventually needs it.  svenl suggested that procps might be happiest compiled as ppc64 for that arch (I haven't needed it yet, it's on my to-look-at- list)
<fabbione> carlos: i have done for now. I will probably ssh back in if jbailey has a fix to test for it
<carlos> fabbione, ok
<elmo> Kamion: pls try triggering archvsync@magellanic ?
<Kamion> jbailey: strace maybe?
<carlos> fabbione, will remove the admin permissions now, please ask for tehm again when you need them. I will leave the normal account until you finish.
<Kamion> jbailey: (it depends on libc6-sparc64 on sparc)
<fabbione> carlos: that's perfect! thanks
<Kamion> elmo: bash: /home/archvsync/torrent-sync: Permission denied
<elmo> score
<elmo> and once more, for muppets the world over?
<jbailey> Kamion: Right, might be useful there too.
<jbailey> Kamion: But even so, I suspect it can be just pulled in as a dependancy of strace.
<fabbione> elmo: hey dude
<elmo> fabbione: hey, I fixed davis/breezy - sorry about that
<fabbione> elmo: no problem.. thanks :)
<fabbione> dpkg-checkbuilddeps: Unmet build dependencies: libc6-dev-ppc64
<fabbione> elmo... hmmmm
<fabbione> it still claims it's not there...
<sabdfl> mdke: not personally, but i'll ask about it if it's still an issue
<Lathiat> Anyone know if the python apt bindings can work on an external cache/archive set to that of the running system ?
<elmo> fabbione: err, whoops - that was && after the dist-upgrade which failed - fixed
<Kamion> elmo: triggered, did it work?
<Kamion> jbailey: sure, it would be - I was really just wondering whether it should/could be promoted to priority required/important
<fabbione> eeheh thanks elmo
<Kamion> jbailey: (along with everything else pulled in by dependencies of base system stuff)
<elmo> Kamion: yeah, it's pulsing now
<jbailey> Kamion: I don't know yet, sorry.
<sabdfl> mdke: seems to be working fine
<Kamion> elmo: righto, automated
<elmo> Kamion: cheers, sorry about that
<jordi> did JaneW reply before I lost my link?
<JaneW> jordi: yes I said pong
<Kamion> elmo: np
<jordi> JaneW: sorry, power outage where my server is :)
<mdke> sabdfl, neither myself nor dholbach could log in earlier. here I still can't login
<sabdfl> mdke: can you diagnose that with elmo please?
<mdke> sabdfl, sure thing
<mdke> elmo, we can't login to the wiki
<mdke> launchpad login is working fine
<elmo> mdke: when did you last try to login?
<mdke> right now
<mdke> elmo ^
<elmo> mdke: what IP are you coming from?
<mdke> erm
<mdke> lemme look
<mdke> 81.178.109.10
<mdke> elmo ^
<mdke> so can others log in?
<mdke> dholbach said earlier it was down for him too
<elmo> I did without any problem, yes
<mdke> hmm
<mdke> was working fine for me last night, this morning, it has not been working since I got up
<mdke> also jsgotangco said he couldn't login
<elmo> mdke: what's your username for launchpad?
<mdke> matthew.east@breathe.com
<tseng> infinity: alive?
<elmo> I'm sure there was something that would auto-decrypt https traffic given the relevant cert - does anyone remember what it is?
<tseng> ssldump?
<elmo> aha, that looks like it, thanks tseng
<elmo> mdke: please try again now?
<tseng> nps
<jbailey> "The only result can be that nobody gives a damn about ppc." - Ulrich Drepper.
<ogra> wow, the new gnome-power improved a lot :)
<mdke> elmo, works now!
<mdke> elmo, thanks a lot. what was up?
<jbailey> Anyone feel like showing up at his door with axes and torches with me?
<elmo> mdke: ok, cool.  the authserver had a code roll out that broke some wiki logins.  it's been rolled back until the developers can diagnose and fix
<pitti> jbailey: I'd rather club him with my ibook
<elmo> pitti: I wouldn't, they're a precious/rare commmodity these days :-P
<pitti> hm, right
<pitti> elmo: what about a wooden iBook imitate? :-)
<Mithrandir> elmo: well, real laptops take hitting people just fine.
<jbailey> pitti: I have  G5 here that I"m pretty certain would survive. =)
<pitti> heh
<mdke> elmo, ok thanks for sorting it
<bob2> haha
<jbailey> bob2: Hey. =)
<tseng> elmo: im hoping muine looks better to you today, unstable accepted it with a bit less splitting
<jbailey> bob2: Oops, ECHAN. =)
<elmo> tseng: I'm not overly thrilled about the split in debian unstable, but I processed the ubuntu new one since it got in there
<tseng> elmo: thanks.
<Kamion> fabbione: what happened to sk98lin in nic-extra-modules?
<Kamion> fabbione: or come to that at all
<fabbione> Kamion: it's missing. we removed sk98lin to include skge, it's in the pending queue for the nic-* cleanup
<Kamion> fabbione: oh, ok, please do that ASAP so that my primary d-i test machine works again :P
<fabbione> Kamion: i am going to finish the cleanup tomorrow and upload the new kernel
<fabbione> Kamion: we habe another abi change to deal with :)
<Kamion> aargh
<fabbione> brought to you by alsa 1.0.9 and ocfs
<Kamion> and tomorrow daniels is going to rearrange xorg, so CDs are hosed for another week
<fabbione> i could revert all the changes and upload 2.2 with only that fix
<fabbione> but it's kind of a pain
<fabbione> daniels: can you give me tomorrow before rearranging X?
<fabbione> Kamion: if i upload tomorrow by 12:00 UTC, i think we can get the abi change in pretty fast...
<fabbione> Kamion: specially if the kernel hit buildds with the latest ccache
<fabbione> actually.. much earlier than that
<daniels> fabbione: -33 won't feature any rearrangements
<fabbione> Kamion: ^^
<daniels> i'm thinking I might separate my 'fixes for painful bugs' and 'break more shit out' uploads
<fabbione> is that ok for you?
<Kamion> fabbione: yes
<fabbione> ok perfect... 
<ogra> Kamion, what is the plan ith UbuntuExpress now ?
<ogra> with even
<fabbione> we can prepare all the other stuff before hands
<Kamion> ogra: mdz's doing a framework
<fabbione> so it won't be too painful
<fabbione> jbailey: do you think you can give the initrd-tools fix for that before tomorrow?
<ogra> Kamion, yes i saw it, but what about the other guys that wanted to do it
<Kamion> ogra: as far as I know, we're going to implement the framework first and then have the other guys flesh it out
<Kamion> ogra: because having inexperienced people try to do the framework didn't work out well
<ogra> ah, ok, i thought they already dropped it
<jbailey> fabbione: Define 'tomorrow' =)
<Kamion> I don't know, I've been buried in other things
<fabbione> jbailey: within your working day
<ogra> Kamion, me too, thats why i ask :)
<ogra> Kamion, thanks for the info
<jbailey> fabbione: Yes, I have 8 items or so to do today, this will be one of them.
<fabbione> jbailey: so that when i start tomorrow morning i can test it
<jbailey> fabbione: Yes, should be no problem.
<fabbione> jbailey: perfect.. i count on that
* fabbione goes offline
<Mithrandir> jamesh: around?
<Kamion> pitti: grep: usr/share/locale/af/LC_TIME/coreutils.mo: No such file or directory
<Kamion> pitti: it's a dangling symlink. Is that a pkgstriptranslations bug?
<pitti> /usr/share/locale/af/LC_TIME/coreutils.mo -> ../LC_MESSAGES/coreutils.mo
<pitti> WTH?
<pitti> Kamion: well, pkgstriptranslations of course strips away LC_MESSAGES/*.mo
<pitti> I didn't think about symlinking from LC_* to LC_MESSAGES
<daniels> so, I'm going to create a cute little race tonight or tomorrow in which /usr/bin/X11/Xorg and /usr/bin/X11/X will disappear
<daniels> dist-upgrade and get the new xserver-common and xserver-xorg (6.8.2-33) when it arrives, then dist-upgrade again to get x-common 1.01
<daniels> and life should be peachy
<pitti> Kamion: does such a symlink make sense in the first place?
<Kamion> pitti: dunno, I haven't looked at the code
<pitti> ok
<Kamion> I suppose it could do
<pitti> Kamion: thanks for the hint, I'll look at it
<Kamion> I am totally mystified by #11787
<Kamion> netcfg has no code that can do that, as far as I can see, so something else must be munging /etc/network/interfaces
<daniels> Kamion: fwiw, with x-common 1.01, /usr/bin/X11 becomes a symlink to /usr/bin
<Kamion> hooray
<doko> Mithrandir: the multiarch-include patch for gcc doesn't honor -m32/-m64. if you use -m32 on amd64, /usr/include/x86_64 is in the include path, not /usr/include/i486-linux. that's not the way we want it.
<mdke> dholbach, get your wiki hits now! 
<Mithrandir> doko: jbailey discovered that a bit ago, and yes, I'm aware of it but I haven't looked at it and fixed it.
<dholbach> mdke: already did some changes :)
<mdke> :)
<dholbach> did anybody else experience an inexplicable disturbance in the buildds' force?
<dholbach> resulting in random segfaults?
<Kamion> any particular architecture?
<dholbach> powerpc
<dholbach> glom's build didn't succeed and the nasm build looks strange too
<dholbach> both segfaulted at some stage
<Kamion> powerpc has been randomly SIGILLing for a long tim
<Kamion> e
<Kamion> though I'd thought the 64-bit kernel fixed that
<dholbach> hrm
<infinity> Kamion : We don't have new kernels on the buildds yet.  Heopfully, that's a "this week" thing.
<Kamion> aha
<dholbach> oh cool
<dholbach> good to know
<infinity> dholbach : given back.
<dholbach> *fingers crossed* ;)
<dholbach> infinity: thank you
<tseng> infinity: hey, could you maybe explain another buildd bugger?
<tseng> infinity: gtk-sharp2-unstable has lots of segfaults on x86 buildd, not not in my pbuilder
<infinity> dholbach : glom succeeded, nasm failed in the same place, looks like ps2pdf is buggy.
<pitti> dholbach: btw, does glom run any better now with the current psql packages?
<infinity> dholbach : I'm off to bed right now, can you check if ps2pdf currently has a bug open about SEGVs on PPC, and if not, open one?  (assign it to me, if you're feeling adventurous)
<infinity> tseng : Want to bug me about it in ~9 hours? (or mail me... adconrad@u.c)
<tseng> infinity: hm sure
<infinity> tseng : Danke.
* infinity -> Bed.
<daniels> infinity: night.  slacker.
<dholbach> pitti: you have go through the same configuration "pain" but at least it's explained on glom's wiki
<pitti> dholbach: it should work out of the box over the unix socket
<dholbach> infinity: thanks a lot
<pitti> dholbach: can you please try to bug me about it from time to time?
<dholbach> pitti: that's a libgda thing
<pitti> elmo: quota sync, please
<mpt> sabdfl: What do I need to do to get http://udu.wiki.ubuntu.com/MigratingToUbuntu approved?
<mpt> hi AndyFitz
<AndyFitz> g'day mpt
<tseng> AndyFitz: bloody rippah
<daniels> awhyeahripper!
<AndyFitz> tseng, struth mate.  today was s-house.   how was yours ?
<mpt> rats
<Kamion> mpt: erk, that's the first time I've ever seen that spec and it requires non-trivial installer work
<tseng> AndyFitz: rockin
<mpt> Kamion: I don't think Step 2 would be a BreezyGoal :-)
<mpt> Stage 2, rather
<mpt> Stage 1 at most
<Kamion> mpt: ok, that's not mentioned
<Kamion> it should be, for avoidance of panic among those with distro schedules :)
<Kamion> p.s. what does "current OS" mean? it's often very hard to tell
<daniels> mpt: i hope you're planning to implement #13
<Kamion> for dual-boot, sure, but triple-boot or more are common
<mpt> daniels: haha
<Kamion> (e.g. win95, winxp, linux)
<tseng> thom: why does nm run its own nameserver?
<daniels> mpt: seriously.
<silbs> AndyFitz: ping
<Kamion> the language choice one is not possible without serious installer reengineering
<AndyFitz> slibs: pong
<daniels> tseng: i assume because kicking all apps to re-read resolv.conf (*cough*FIREFOX*cough*) is a pain in the arse
<AndyFitz> silbs, pong
<Kamion> (because the language is chosen before the disks are readable)
<Kamion> although UbuntuExpress might help with that
<mpt> daniels: That would require learning to program
<daniels> mpt: oh well
<mpt> I'm all about the Stage 1
<daniels> i'm not about the stage 2, in this case
<mpt> naturally
<hunger> Is it really necessary for network-manager to install bind9?
<thom> tseng: work around the fact you can't reload libc's resolver sensibly, and tell apps that they need to do it too
<daniels> mpt: if you're seriously proposing #13, you need to find someone to do it
<seb128> daniels: same for the other points too :p
<Kamion> really those things ought to be separate specs
<thom> hunger: for the moment, yes; see my answer to tseng
<daniels> Kamion: yet it must be approved yesterday
<hunger> thom: resolveconf doesen't do it well enough?
<thom> hunger: no.
<hunger> thom: Damn:-)
<hunger> thom: So resolvconf can go when installing nm?
<hunger> thom: How about using some simpler thing as bind like dnsmasq?
<hunger> s/as/than/
<thom> no, resolvconf is still useful
<thom> hunger: and no, nm directly controls bind, so something else would need aditional code
<Lathiat> it should bind to 127.0.0.1 only by default tho :\
<Lathiat> not sure hwo to do that conditionally
<thom> Lathiat: the config does that
<Lathiat> it does?
<Lathiat> mine wasnt
<thom> listen-on  { 127.0.0.1; };
<Lathiat> well mine wasnt doing that
<Lathiat> and i added that line myself
<thom> to /var/lib/NetworkManager/NetworkManager-named.conf?
<thom> that's a generated file
<Lathiat> no to named.conf.local
<Lathiat> or whateveritis
<thom> that's not used by NM's bind
<Lathiat> hrm
<Lathiat> so why was itlistening before
<Lathiat> nm starts its own bind?
<Lathiat> maybe my system was starting a global bind too....
<thom> possibly so
<Lathiat> right
<Lathiat> so why does NM use bind
<Lathiat> and not just resolvconf ?
<bob2> 23:43:59           thom |  hunger: and no, nm directly controls bind, so something else would need aditional code
<daniels> Lathiat: that was explained above
<Lathiat> oh sorry *reads up*
<Lathiat> ah i see
<hunger> Is there a reason for not listing the NM applet in the applet list? Or did I just miss it?
<Lathiat> its not an applet
<Lathiat> its a nofication icon
<Lathiat> (that confused me too, bad name)
<hunger> Lathiat: nm-applet is no applet? Wow, nice!
<Lathiat> hunger: so you run nm-applet directly, heh
<hunger> Lathiat: So how do I get the notification icon?
<Lathiat> hunger: run nma--applet
<Lathiat> nm-applet, rather
<hunger> Lathiat: There is no GUI way to do that?
<Lathiat> alt+f2 nm-applet? :)
<Lathiat> i think th eidea is it shoudl be started by your session
<Lathiat> i added it to my session
<hunger> Lathiat: I thought this was supposed to be simpler than editing /etc/network/interfaces.
<tseng> i added it to mine
<tseng> i am thinking i should change it to respawn in the session
<tseng> the applet dies on dbus reload
<Lathiat> hunger: dude
<Lathiat> hunger: development
<Lathiat> hunger: think, default breezy install -> in by default
<hunger> Lathiat: Then add it;-)
<Lathiat> :)
<hunger> Lathiat: What about /etc/network/interfaces? Will that get replaced by NM?
<Lathiat> well it doesnt exactly replace it
<hunger> Lathiat: Or will we have two places to configure the network now?
<Lathiat> it handles mobile networking
<tseng> nm uses interfaces as a "hint"
<Lathiat> for most people you probably wouldnt touch your interfaces file
<Lathiat> others would *shrug*
<hunger> Lathiat: That sucks... I'll never be able to figure out which config overwrites which!
* Lathiat blah
* Lathiat continues work
<bddebian> Heya
<daniels> .win 39
<Treenaks> 39?!!!
<Treenaks> dude
* Mithrandir is at 74.
<tseng> i try to keep it under 20
<Treenaks> I start closing windows when I'm >20
<tseng> yep
<Mithrandir> I've given up that
<maswan> that's the reason why I run 3 clients
<tseng> i merged some channels into the same window also
<tseng> low traffic
<maswan> I end up not reading the ones >20, usually
<Mithrandir> maswan: M-a, dude, M-a :-)
<maswan> Mithrandir: yes, but some are boring channels that I don't want to see all the time.
<maswan> Mithrandir: especially work channels, when I'm supposed to be on vacation. ;)
<Mithrandir> maswan: ignore activity in them, then
<maswan> Mithrandir: well, I guess
<terrex> repositories are too slowly for me today
<terrex> terrex Is there any wikipage or anywhere see the agenda of the month for all teams?
<terrex> terrex It's really nice to make an integration with evolution and make a "shared agenda" server, dont you think?
<SleepyEye> Having trouble getting hands-off network based installation working.  Apt configuration failing.  Can anyone offer pointers/help?
<carstenh> SleepyEye: only if you describe your problem :)
<carstenh> .oO(is *-devel the right place for such questions?)
<SleepyEye> I dunno, is it?  Came here because archived transcripts pointed me here.
<ivoks> mako: thanks :)
<mjg59> Kamion: That CD is good
<SleepyEye> carstenh:  When Apt configuration happens I just get a failed message with "continue" highlighted.  Nothing other than fail indication on console 3 or 4 (don't recall which).
<SleepyEye> carstenh:  No indication of why apt configuration failed.
<mako> ivoks: no problem
<carstenh> SleepyEye: can you please put your /etc/apt/sources.list on a webserver or on paste.debian.net?
<bddebian> mjg59: Please don't take offense, but I am surprised to see you here.
<mjg59> bddebian: Why?
<bddebian> mjg59: I dunno, I just would have thought you would have been one of the Ubuntu "haters".
<SleepyEye> carstenh:  Ok, it's on paste.debian.net.  It's only one line because I'm using a local mirror of the archive.  I created the mirror using "debmirror".
<mdke> lol
<mjg59> bddebian: Why?
<mjg59> bddebian: (I've been here since before Warty was released)
<mdke> bddebian, he is a central dev for Ubuntu
<dilinger> mjg59: "'cause you hate *everything*"
<mjg59> Haha
<^rob^> is there a list of all the accepted proposals for the Summer of Code for Ubuntu?
<bob2> presumably people will be emailed about it
<carstenh> SleepyEye: and the error apt gives you is?
<bddebian> mjg59: Honestly I don't know.  I honestly don't mean it as an insult, I was just surprised.
<ogra> AndyFitz, pingeling
<daniels> dilinger: he only hates our freedom
<bob2> daniels: and our burger kings
<bddebian> mdke: I'm glad, I was just surprised for some reason.
<AndyFitz> ogra, pongalong
<daniels> bob2: no, stansted's burger kings.  or lack thereof.
<mjg59> Damn them
<mdke> hmm
<SleepyEye> carstenh:  Apt isn't giving me an error.  It's apt-setup during installation that's giving the error.
<daniels> bob2: we don't have any burger kings, either, except in the international terminal of tulla.
<mdke> who needs burger king when you have pret a manger
<bob2> sometimes you don't want a 10 quid sandwich
<bob2> tho sometimes you do
<carstenh> SleepyEye: ok, just skip apt-setup
<mjg59> mdke: When you have a hangover and no sleep, you want grease
<mdke> bob2, burger king is not cheap either ;)
<carstenh> SleepyEye: apt-get update works?
<mjg59> Not sandwiches hand-made by virgins with gold-plated knives
<mdke> lol
<mdke> you can taste it tho
<^rob^> burger king is just a Checkers wannabe
<SleepyEye> carstenh:  Yes, apt-get update works.  How do I skip apt-setup using a preseed installation (this is what I was hoping could be done)?
<bddebian> The best hangover food is greasy/spicy Mexican food!!
<mdke> curry
<carstenh> SleepyEye: i try to avoid using the debian/ubuntu-installer and use debootstrap instead, sorry
<bddebian> Too spicy.  That just makes ya burn the porcelin. :-)
<daniels> mjg59: but they do make a wicked blt
<daniels> mjg59: boots is a passable imitation
<mjg59> Hngh.
<SleepyEye> carstenh:  I'd be willing to try debstrap if it will do what I need.  Can you point me at a web site or documentation?
<carstenh> SleepyEye: do you want to install one computer or more (maybe automatically)?
<SleepyEye> carstenh:  Many machines via network
<SleepyEye> carstenh:  Oh, yes, automatic
<carstenh> SleepyEye: i don't think debootstrap is the right tool for this job
<SleepyEye> carstenh:  Bummer.  The weird thing is if I us interactive install, it works.
<SleepyEye> carstenh:  I even used debconf-get-selections and copied the apt-setup preseed stuff it generated and the automated apt-setup failed in the same way.
<carstenh> SleepyEye: i never used preseeding, maybe http://d-i.alioth.debian.org/manual/en.i386/apcs01.html helpd you. i'm sorry i can't.
<carstenh> s/helpd/helps/
<SleepyEye> carstenh:  Yep...been there, done that.  Thanks for tryin anyway.  I guess I'll just keep playing around with it and searching the web.  Maybe I'll get lucky and stumble across something.
<carstenh> i hope so :)
<^rob^> if anyone is in the Southeast of the US, Checkers is the heart-clogging fast-food of choice for most fat people, the people who know fast food.
<daniels> even worse than wendy's?
<^rob^> daniels: by far
<^rob^> you can get 2 1/2 lb burgers for $3.00
<^rob^> with Bacon, Cheese, and Special Sauce
<^rob^> mmmm...fattning
<Kamion> meh, too late to investigate SleepyEye's problem
<daniels> eh, that's not that big
<^rob^> daniels: it is for $3.00
<daniels> point
<ogra> thom/mjg59, could you guys have a look at gnome power ? it has gconf keys for calling acpi scripts now ...
<bob2> Kamion: he/she's in #ubuntu now
<thom> ogra: if it can have arguments too, just have it call pmi
<Kamion> I've used /msg
<ogra> thom, that works with user rights ?
<thom> aaahr
<ogra> thom, redhat uses some suid magic afaik
<thom> meh, k
<thom> i'll look later
<ogra> great, thanks
* thom hopes that hal will get the suspend/resume hooks sooner rather than later
<ogra> i'll have a handfull commandline options in the next version, to omit or modify stuff...
<ogra> thom, i doubt we'll see it before breezy
<pef_aw> hello
<Riddell> infinity: do you know why kexi is dep-wait on libmysqlclient-dev when it build-deps on libmysqlclient12-dev
<pitti> hello again
<solomarv> hello
<\sh> hey pitti
<ogra> yo pitti 
<SloMo> hi... anybody here interested in xmms-musepack and bmp-musepack packages for breezy? they are currently in backports/extras and seem to work fine there
<solomarv> SloMo, what do you mean by "interested in"?
<bob2> SloMo: are they in Debian?
<SloMo> ehm, is someone interested to get them into breezy? would be the first user of libmpcdec which currently is in breezy
<SloMo> bob2: no
<\sh> SloMo: http://wiki.ubuntu.com/MOTUNewPackages
<SloMo> thanks
<Kamion> yay, debootstrap successfully resolved a missing base system dependency
<Kamion> boo, it exited 1 for no apparent reason (suspect that's the busybox sh bug reported in Debian)
<mdz> morning
<ogra> hey mdz 
<mdz> daniels: I very nearly renamed it to autodetect_keyboard when I was messing with that code, but it seemed gratuitous, given that we can't actually autodetect anything
<daniels> mdz: autoguess_keyboard?
<mdz> daniels: infer_keyboard? ;-)
<mvo> morning mdz 
<daniels> mdz: unless you have any strong concerns with autodetect, i think it's best we leave it there for consistency
<ogra> mvo, will we have to live with the ugly fading in gksudo ? 
<mdz> daniels: I have no strong feelings about it
<mvo> ogra: don't know. it's a upstream thing. we can remove it again
<daniels> mdz: word
<ogra> mvo, would be nice... but we'd have to discuss it in a bigger round i guess
<ogra> meh, ffmpeg compiled....
<ogra> with gcc-2.95 :(
<bddebian> Heh
<daniels> guten nacht
<ogra> bddebian, its not really funny.... i have a bug open and cant compile it at all...only gcc-2.95 seems to work .... the fun stuff is, thi only happens on i386
<ogra> daniels, schlaf gut
<mvo> daniels: gute nach! (did you had german leasons at linuxtag?)
<bddebian> ogra: Oh, :-(
<ogra> mvo, +t ;)
<mdz> daniels: regarding those bugs I filed about the preseed-for-reconfiguration stuff, those were all filed after my changes (and therefore are still valid)
<pitti> daniels: Gutte Nacht
<mdz> daniels: I think the culprit is all that weird-ass "auto_answer" stuff
<ogra> mdz, we still should talk about edubuntu live vs install CD, poor performance doesnt outweight the promotional benefits in my eyes, i'm not convinced yet :)
<ogra> mdz, indeed your word counts in the end :)
<bddebian> ogra: What fails?
<ivoks> wierd gksudo, really wierd :(
<ogra> bddebian, ffmpeg ? 
<bddebian> ogra: Whatever isn't compiling, yes
<ivoks> gksudo in gnome doesn't read /etc/sudoers like it should :/
<ogra> bddebian, assembler errors, gcc-4.0 is more strict about the code....
<ivoks> ogra: uberstrict would be better to say :)
<bddebian> Heh
<ogra> heh
<bddebian> But it won't build with gcc-3.4 either?
<elmo> pitti: nothing to sync
<ogra> bddebian, nope
<ogra> bddebian,  error: PIC register '%ebx' clobbered in 'asm'
<bddebian> eeks
<pitti> elmo: ah, sorry, it's still in incoming, I guess. I just read the closed bug report
<ogra> i knoe the error, i know the solution, but i dont know enough assembler to fix the code :(
<mvo> ivoks: gksudo is just a frontend to sudo. it execute it 
<ivoks> mvo: but, gksudo -S /some/app works fine
<ivoks> mvo: but if executed from menu, it asks for password
<ivoks> mvo: despite NOPASSWD in sudoers
<ivoks> that's wierd
<mvo> ivoks: do you run breezy? or hoary?
<ivoks> breezy
<ivoks> first I tought my .desktop was broken, but no...
<ivoks> same think if you put xterm -e gksudo /some/app
<ivoks> thing
<thom> pitti: how's bzr working out for you with pmount?
<pitti> thom: many features are still missing (like branch, but that's supposed to work now in bzr head)
<pitti> thom: but for pmount's size it works quite well
<pitti> thom: I wouldn't entrust it my postgresql stuff yet, though
<mdz> ogra: you'll be in London this weekend, yes?
<ogra> mdz, yep
<mdz> we can talk about it then
<ogra> mdz, you come ?
<mdz> ogra: yes
<ogra> hooray :) really looking forward to it then :)
<fabbione> hey mdz
<thom> pitti: right
<thom> i was pondering it for acpi-support
<thom> which should be fine
<pitti> thom: I really need branch handling for postgres, but not for pmount, so testing it on pmount is fine for me
<pitti> thom: currently I emulate the "push" command with a small shell wrapper which calls rsync after commit
<thom> right
<thom> ok, i'll have a look and see how it goes
<pitti> I hope that push and hooks will be integrated soon 
<daniels> mdz: auto_answer is f**king crack
<mdz> daniels: yes, let's kill it
<mvo> ivoks: please file a bug and assign it to me (michael.vogt@ubuntu.com) with a description how it can be reproduced
<ivoks> mvo: ok
<mvo> ivoks: thanks
<daniels> mdz: not tonight I won't
<bddebian> ogra: Are you using the source from Debian or is it in the archive?
<ogra> bddebian, from debian, there was a new version yesterday...
<bddebian> Oh :-(
<ogra> it fixes amd64 and ppc builds with gcc-4.0 (i had to patch the last source) but not the i386 prob
<thom> hrm, how come we have no bzr packageS?
<mdz> thom: FTBFS last I checked
<mdz> now it's failing in a different way
<mdz> thom,bob2: http://people.ubuntu.com/~lamont/buildLogs/b/bzr/0.0.5-2/bzr_0.0.5-2_20050622-0954-i386-failed.gz
<bob2> bah
<bob2> missing build-dep on python2.3-dev
<ogra> 2.3 ?
<mdz> ogra: Debian
<tseng> ogra: looks like it uses both
<ogra> ah, ok
<ogra> mdz, what about moving gnome-power to main ? any objections from your side ? (it has no universe dependencys)
<mdz> ogra: have you done an inclusion report for it?
<ogra> mdz, not yet
<ogra> doing it now
<ddaa> Hey, do you know where I can put a hook on Yann Dirson? Does he IRC?
<thom> mdz: ah, k
<bddebian> So bzr needs to be updated to depend python 2.4 instead of 2.3?
<tseng> bddebian: no
<thom> bddebian: no, it uses both
<bddebian> Oh
<bddebian> Sorry, I'm on a Winblows machine so the output is a little unreadable.. :-(
* bddebian just saw the comment above. Doh. :-(
<RzR> hi
<RzR> how to add packages to ubuntu
<bddebian> Hello RzR
<RzR> I mean submit new software
<bddebian> RzR: Put it on the NewPackages wiki page
<mdz> RzR: the best way is to talk to the MOTU team (they hang out on #ubuntu-motu)
<daniels> or get it into debian first, and watch it filter through
<RzR> i tried to put connect in debian .. but pple are to busy for it 
<daniels> which is probably the best option
<RzR> see http://rzr.online.fr/q/Proxy
<RzR> bddebian: https://wiki.ubuntu.com//NewPackages ?
<bddebian> RzR: Sorry, here: https://wiki.ubuntu.com/MOTUNewPackages  I think
<thom> mjg59: acpi-support is now in bzr; http://people.ubuntu.com/~thom/bzr/acpi-support/
<rade> hello everyone, first, does anyone know why when i install the kernel source with synaptic, it just puts a tarball into /usr/src and doesn't even make a link to it in /lib/modules/? second, why i don't have irq_vectors.h in /include/asm in my kernal source directory? i don#t even have an asm directory, just asm-*
<daniels> rade: a) this is more of an #ubuntu question, b) linux-headers-* will probably satisfy your concerns better
<dholbach> re
<rade> daniels: thanks, but i've already spent a while chatting in #ubuntu, and still no luck... i installed the headers as well, but they're not in my kernel source directory, but in linux-headers-*
<daniels> it seems you're sort of missing the point about how linux-headers-* works
<lamont__> rdade: have you looked at /usr/share/doc/linux-source-2.6.10/README.gz
<lamont__> ?
<lamont__> linux-source includes the full source for a kernel, linux-headers is just what you need to build modules - see /lib/modules/*/build
<lamont__> that is, if you're building a kernel, you want linux-source-<vers>, if you are building modules, you want linux-headers-<vers>
<lamont__> but like daniels said, that's more of a #ubuntu issue (clarifying the existing situation), than #ubuntu-devel (which would be a place to discuss your proposed changes to fix a bug you've found)
<madduck> is martin pitt here?
<tseng> madduck: no.
<madduck> mh, anyone else involved with ubuntu-cve?
<tseng> Nafallo, a bit
<madduck> Nafallo: ping?
<madduck> who is Nafallo ? real name, i mean...
<Nafallo> madduck: pong :-)
<Nafallo> madduck: Christian Bjlevik :-)
<madduck> Nafallo: so, debian security is up shitcreek without a paddle, and i just saw ubuntu-cve
<madduck> that should be pretty easy to amend to debian stable, right?
<Nafallo> madduck: some of them sure could. for the moment my view is that only ubuntu's main has proper security-updates. but sure. you might aswell dig in and take those who are done :-).
<Nafallo> even for universe/multiverse
<madduck> Nafallo: for the moment, i only want an overview.
<madduck> i don't have any time, but noone else seems to be doing anything.
<madduck> do i have to start delegating.
<madduck> s/do/so/
<Kamion> pitti said earlier today that he'd sent mail volunteering to help out
<madduck> Kamion: excellent.
<Nafallo> madduck: it's probably best to find pitti. he's the one that often has an overview on things :-).
<madduck> but he's not coming back till tomorrow?
* madduck thinks that if pitti saved debian as an ubuntu person, that would rock!
<Nafallo> dunno, I've just come back myself :-). but... there is always e-mail ;-).
<madduck> mpitt@ubuntu.com ?
<madduck> and he *is* german, right?
<Nafallo> martin.pitt@ubuntu.com
<Nafallo> yepp, german :-)
<rade> does anyone here know where hub.h is supposed to be? which package it's in?
<dholbach> use dlocate or apt-file
<dholbach> or packages.ubuntu.com
<madduck> Nafallo: mh, don't tell everyone (outside this channel), but it seems that things are already under control.
<Nafallo> madduck: oki :-). not even my girlfriend? ;-)
<madduck> Nafallo: of course not. She's a spy, didn't you know?
<madduck> when is the next tech board meeting?
<madduck> ah. Tuesday 28 June 2005 at 2000 UTC
<Nafallo> hehe...
<madduck> shit. shit. shit. shit.
<madduck> i've been invited four times now, and four times *something* just came in between.
<madduck> nobody will ever forgive me.
* madduck cries.
* madduck is going to unite Ubuntu and Debian. uh, in the long run. not alone...
<bddebian> Heh. Heya madduck
<madduck> howdy. you are quoted in my book. :)
<dholbach> madduck: do you mean technical board or community council meeting?
<madduck> tech board
<mdke> he wants TB
<dholbach> ok
<madduck> i am writing an apologetic email to pitti now.
<madduck> or is there a tech board list?
<ogra> madduck, you want to unite debian and ubuntu so your second name is sysyphus ? 
<mdke> you can write to the -devel list and link to it on the Tech Board agenda maybe?
<madduck> ogra: rotfl.
<mdke> http://wiki.ubuntu.com/TechnicalBoardAgenda
<madduck> mdke: it's not of everyone's concern really.
<bddebian> madduck: Yeah, you told me.  That's frightening. :-)
<madduck> i'll just tell pitti and let him do what he wants with it.
<madduck> bddebian: and it's a good quote too. :)
<bddebian> madduck: When is the book going to be finished?
<madduck> it's done. http://debiansystem.info
<madduck> availability: http://debiansystem.info/order
<bddebian> madduck: Sweet, I'm ordering!!
<madduck> Cool. Watch out though since I don't know about shipping costs if you order in Europe.
<madduck> I have inquiries going, so I'll update those pages. 
<madduck> Maybe you want to subscribe to the RSS feed or mailinglist?
<bddebian> NP, I don't mind paying
<madduck> let me know how much it totals, okay?
<bddebian> Sure
* madduck is really proud of that book
<bddebian> madduck: That link says Amazon has it but I don't see it on Amazon.. :-(
<madduck> because you are on amazon.com, not amazon.de
<madduck> amazon.com does not have it yet because they are fucking assholes.
<madduck> so far, all american publishers are totally incapable of working with overseas publishers.
<bddebian> :-(
<bddebian> I'll get it from bookzilla then
<mgalvin> hi madduck, congrats on the book rolling out :), can't wait to grab a copy when it comes to the US, seems like i have to wait a bit though :(
<madduck> bddebian: i can order it for you though if you are willing to go for an experiment, and you'd entrust your credit card number to me for this transaction.
<madduck> mgalvin: yeah, and it SUCKS and i went around and kicked and screamed at everything i could find,.
<madduck> mgalvin: bug your book store, send me a mail as if we hadn't met and ask impatiently, then i'll forward that to the publisher to make sure they know that demand exists.
<ogra> bddebian, oh, yes, post it right here :_P
<bddebian> 1234-56-... ;-P
<ogra> heh
<madduck> ogra: i would give my credit card to bddebian for such a transaction, btw.
<bddebian> madduck: Ack, bookzilla is in German
<mgalvin> madduck, i certainly will do
<ogra> madduck, i wouldnt give it to anyone through the net...
<madduck> the publisher has a fucked up policy: 45 days of demand assessment. fuck them. we sold 1500 copies in three days!
<ogra> (call me paranoid)
<dholbach> bookzilla ROCKS
<madduck> ogra: sure, but i know bddebian, albeit virtually, for a while now, and there is encryption.
<bddebian> madduck: I'll send it signed once I get home maybe
<madduck> bddebian: ecnrypted.
<bddebian> Aye
<ogra> madduck, true, i forgot about gpg...
<madduck> ogra: DOH!. :)
<bddebian> Hell Citibank probably already got the number out there somewhere anyway.. ;-)
<madduck> rotfl
<ogra> madduck, like i forget that my car has a cludge, but i switch gears anyway ;)
<bddebian> cludge?? Hahaha
<bddebian> Sorry, don't mean to laugh, that just seemed freudian
<ogra> bddebian, european cars have such things :)
<bddebian> clutch
<ogra> ch ?
<bddebian> Aye
<ogra> whoops
<bddebian> :-)
<ogra> i have to work on my vocabulary...
<bddebian> Nah
<ogra> sure
<bddebian> You work on your vocab, I'll work on getting a brain to try to help out.. :-)
* Kamion -> karate
<dholbach> brb
<mxpxpod> is there something for ubuntu that will allow users to plug in an ethernet cable and if there's a dhcp server around, it will "Just Work"?
<Nafallo> mxpxpod: network-manager
<Mithrandir> mxpxpod: ifplugd?
<mxpxpod> Nafallo: does nm work?
<Nafallo> mxpxpod: for me it does ;-)
<mxpxpod> Nafallo: breezy?
<thom> mxpxpod: yes
<mxpxpod> ok, how stable is breezy?
<thom> works fine here
<mxpxpod> thom: oh, I have a cool addition to pmi
<thom> um?
<mxpxpod> thom: I modified it to work with both pmud and pbbuttonsd
<thom> not particularly interesting, tbh, but sure, send the patch
<mxpxpod> that way people don't have to have pbbuttonsd installed since the newest versions seem to like to lock up
<thom> in ubuntu we'll always have pbbuttonsd installed until hal can do the job, or unless lots of "pbbuttonsd locks up and eats my laptop" bugs get filed
<mxpxpod> ok
<mxpxpod> well, here's the thing
<mxpxpod> pbbuttons 0.6.6 (what's in ubuntu) doesn't work well with 2.6.12 and 0.6.10 locks up all the time
<mxpxpod> thom: oh, also... pbbuttonsd and pmud need to start up before gdm starts
<thom> i see precisely zero bugs to that effect
<mxpxpod> because if pbbuttonsd isn't started up before gdm, you don't get the suspend menu item in the gnome logout menu
<mxpxpod> s/logout menu/logout dialog/
<Nafallo> mxpxpod: what thom means is that you should file a bug about it, not complain here :-).
<mxpxpod> ahhhh
<mxpxpod> sorry
<thom> not being psychic, if you're seeing crashes and hangs and don't tell anyone, we can't do much to fix it
<mxpxpod> :)
<mxpxpod> I need to upgrade to breezy one of these days as well so I can start testing some of the new stuff like gnome-power
<ogra> yes, bugzilla is underestimated in te user world :)
<ogra> mxpxpod, gnome-power is no fun yet... we need to integrate it more... but i'm happy about every bug i get ;)
<uniq> in the installer - is there a keyboard shortcut to jump to the list of tasks? 
<Nafallo> ogra: baah, I already use malone for everything ;-)
<mxpxpod> ogra: I'm actually pretty excited about gnome-power
<mxpxpod> Nafallo: malone?
<Nafallo> mxpxpod: launchpad.ubuntu.com
<ogra> mxpxpod, it will rock if it is nicely playing with pmi :) and with dpms etc....
<ogra> mxpxpod, but that will still take its time :)
<mxpxpod> ogra: well, of course
<ogra> but go ahead, be my guineapig *g*
<mxpxpod> I'm kind of nervous to go to breezy since I have my laptop set up pretty much how I like it, but in order to file bugs against it...
<mxpxpod> thom: https://bugzilla.ubuntu.com/show_bug.cgi?id=12198
<thom> mxpxpod: i don't care about that; i still see no bug about pbb crashing or hanging
<mxpxpod> thom: I'll install breezy this week and test it out, ok?
<thom> thanks
<mxpxpod> no problem
<elmo> would it be completely crackful to suggest sudo is either essential: yes or depended on by something like base-files?
<siretart> elmo: ah, good to see you here. I'd like to allow all uploaders for universe to upload to revu. could you give me a copy of the universe uploaders keyring?
<dholbach> *advertise* http://siretart.tauware.de/revu/ :)
<siretart> :)
<elmo> siretart: people.ubuntu.com/~james/tmp/upload-keys.gpg
<siretart> elmo: thank you very much :)
<ogra> seb128, any idea why evo always opens a second instance if i click a mailto link ?
<Mez> elmo ping
<tseng> mako: was that a happy hacking keyboard that you had plugged into your laptop?
<GheRivero> if a package is taken as it is from debian, who is the ubuntu "maintainer" for it?
<ogra> GheRivero, depends, if its universe then MOTU
<GheRivero> main
<ogra> GheRivero, which means we have no personalized packages
<ogra> GheRivero, which package in main ?
<GheRivero> acl
<ogra> GheRivero, thats the main team... no special maintainer here
<GheRivero> ok, thanks, i will try
<ogra> GheRivero, you can look it up on breezy-changes, if nobody touched it, its the whole team, else poke the last uploader, he will at least know who works mainly on it
<ogra> GheRivero, is anythig broken in acl ?
<GheRivero> no, nothing, i'm just working on nfsv4 support and there are a couple of patches that i will like to discuss to include them on breezy
<ogra> GheRivero, afaik nfsv4 is already brought in by jbailey 
<ogra> GheRivero, so you should talk to him
* jbailey scrolls back a bit.
<jbailey> jbailey: I don't think I've done anything with nfsv4.  The only bits I've touched were initramfs related.
<ogra> jbailey, there is not much to scroll :)
<jbailey> Well, I was trying to pfind a package name. =)
<ogra> acl
<GheRivero> acl for the moment... a couple more in the following days...
<bddebian> Jeff!
<jbailey> Hi Barry.
<seb128> ogra: no
<ogra> seb128, thnks
<seb128> ogra: it should open a composer window
<ogra> seb128, it does, but with a second instance of evo
<ogra> which is kinda odd with about 70000 mails :) (takes quite a while to start and close)
<seb128> what have you configured with the preferred applications capplet?
<seb128> hum
<ogra> seb128, nothing iirc... let me look
<ogra> seb128, evo is selected in the top pulldown 
<ogra> so its default i guess
<seb128> maybe restart evo
<seb128> the detection of the running instance may be screwed somewhere
<ogra> yep, might be... as i said, takes a while to close :)
<Treenaks> ogra: does gnome-power handle smart batteries yet?
<ogra> Treenaks, gnome-power only handles what hal sees
<Treenaks> ogra: ok.. so no :)
<bddebian> jbailey: Do you have a Hurd box at all?
<ogra> Treenaks, but hugsie told me he wants to introduce it
<Treenaks> ogra: hug him for me ;)
<jbailey> bddebian: My laptop might still have a Hurd partition on it.
<ogra> Treenaks, so it will go in eventually, but i dounbt it will be before breezy
<bddebian> Bah. :-)
<ogra> seb128, works now, thanks
<seb128> np
<lamont__> jbailey: that's a correctable affliction, you know... :-)
<Treenaks> ogra: should gnome-power-daemon display an icon or something?
<ogra> Treenaks, gnome-power-manager should run in your session, you can enable the trayicon in the settings
<Treenaks> ogra: coolness
<ogra> (found in System->Settings)
<Treenaks> ogra: I ran it command-line ;)
<ogra> yep gnome-power is quite cool, but still needs some integration love :)
<jbailey> lamont__: True.  The install on there has certainly decayed in the year or two since I've used it.
<jbailey> I think I showed it off to someone last in Oslo.
<bddebian> ??
<thom> ogra: presumably the applet will be on by default?
<ogra> thom, i wanted to either write a little script that calls pmi query or add it through laptop mode to the user session if possible
<thom> ogra: see my comment on the main proposal
<seb128> lamont__: around?
<ogra> thom, ah yes, you are right....
<lamont__> seb128: yeah
<seb128> lamont__: what would that take to get a debug archive? have you read pitti's spec about changes for such stuff?
<seb128> lamont__: getting debug backtraces is like 50% of the bug triage action, tackling that would rock
<lamont__> seb128: truthfully haven't read the spec yet... adding another suite to the pile is trivial from the buildd's perspective
<lifeless> morning all
<thom> ogra: i think a mittelweg is required; if you just have UPS/mouse/... then perhaps just do notifications for battery full, low etc
<bddebian> Hello lifeless
<ogra> thom, by default it only does notification, no icon is shown
<thom> ok
<ogra> thom, probably the laptop-mode/pmi query could switch on the battery icon then :)
<thom> yeah
<thom> (laptop-mode is the correct test)
<ogra> yeah... and the icon is switched on in gconf...
<ogra> easy, hehe
<lamont__> seb128: personally, I lean to just dropping them in the .changes file and having the archive scripts automatically drop them wherever (as in, probably not somewhere mirrored).  But then, that just reduces the work that Kinnison/I have to do in modifying the build process, and heaps it on elmo/launchpad and the archive instead.
<lamont__> so I'm not sure it's really what we want to do from a practical standpoint
<ogra> thom, did you check the right click options ? i think we should disable them...
<sivang> seb128: hi, any news about lp integration ?
<ogra> thom, since they double the logout dialog
<seb128> sivang: jamesh has done a bunch of work (the python picker) and should have a look on how easy it would be to patch gtkuimanager
<sivang> seb128: ok, so is it going to be only patching gtkui manager?
<seb128> lamont__: k, so somebody would just have to modify dpkg/dh_strip to make a dbg listed by the .changes basically and then the other changes should be easy
<seb128> sivang: other are not really used
<sivang> seb128: eh I see, others are basically hand patching since are using glade/glade xml files right?
<seb128> not only glade files, that's listed on the wiki
<seb128> there is 5 methods, gtkuimanager is 1
<seb128> glade is 1
<sivang> seb128: ok
<lamont__> seb128: iz pretty much what pitti proposes
<lamont__> I think
<seb128> lamont__: yeah, that's the idea of the spec
<seb128> just making sure that's alright since nobody has commentend on the spec
<sivang> seb128: so , there's need to also patch BonnoboUI and gtkItemFactory as per centerlized patching ?
<seb128> no
<seb128> patching 2-3 apps is faster
<ogra> hey hughsie !!
<sivang> seb128: ok cool, should I talk with jamesh for further work or just start patching the ones not under the catagory of uimanager?
<hughsie> ogra: hey!
<ogra> great, finally we meet 
<seb128> sivang: let ping jamesh first
<hughsie> ogra: Sweet. Give me lots of lovely feedback
<ogra> hughsie, i already have a bug report for you.... in the schema file, there is an integer instead of int
<hughsie> ogra: fixed in cvs
<sivang> seb128: ok, do you recall what is his timezone?
<hughsie> or are you using cvs?
<ogra> ah, ok... i took the 0.0.5 package this time
<hughsie> ogra: yes, sorry, a bug :-)
<ogra> hughsie, so that explains why the --no-actions doesnt work for me yet ? 
<hughsie> yup: sorry!
<ogra> n problem :) 
<ogra> no even
<hughsie> I'll do a 0.0.6 soon - theres a few other bugs for ppl with multiple batteries (that icouldn;t test)
<ogra> i expect to do more packages before breezy :) i just thought sticking with the release would be better for a sane version number
<hughsie> and also I've renamed/reorgansied the fires a bit
<ogra> yep, i saw you dropped the icons dir
<hughsie> ogra: can you do 0.0.5 + cvs?
<hughsie> and lots more:
<hughsie> now all prefixed gpm- except the system stuff
<ogra> sure, but i can also wait for 0.0.6 i'm not in a hurry
<hughsie> ogra, how's this week?
<hughsie> let me get some feedback on the latest changes in cvs, and I'll make a release
<ogra> hughsie, rather next, i'm preparing for a summit on the weekend.... and have to sort my flight to london etc....
<hughsie> no problem. I'm a bit busy too, I'm moving house this weekend. Got any ubuntu (or general) comments?
<lamont__> seb128: actually paying attention to the spec is on Kinnison's list for july
<ogra> hughsie, a lot excited users in here ;) Treenaks, mxpxpod to name two.... btw, do you have an ETA for smart battery support in HAL ? Treenaks would be very interested
<seb128> lamont__: cool. Still I'm trying to push that so we can get it working soon
<hughsie> ogra, got a smart battery specification? HAL's very easy to hack on - it's just f you don;t have the hardware it's a bugger to test!
* lamont__ disappears in about 5 min for several hours
<ogra> hughsie, i know how easy HAL is, i learned most of it with your acpi patches ;) 
<hughsie> ogra: don't trust my code, I'm a beginner!
<hughsie> Getting better every day
<ogra> hughsie, my code (based on yours) was good enough to get accepted in our HAL by the reviewers ;)
<hughsie> ahh, i see :-)
<ogra> and its not easy to pass a review from pitti :)
<hughsie> got any comments about the code in g-p-m? 
<ogra> nope, not yet
<hughsie> I've learnt glib/gtk/gnome in about 4 months and so I'm sure i do stupid things
<sivang> ogra, hughsie : I can also support that, it's hard to pass pitti's review on the 3rd time even :-)
<ogra> hughsie, https://wiki.ubuntu.com/MainInclusionReportGnomePower
<hughsie> thanks guys, apreciated
<ogra> hughsie, but we will ship it in october :)
<hughsie> ogra: then efforts must double
<ogra> hughsie, its pretty easy to integrate, since we already have the backend and several detection mechanisms... its perfect as it is already...
<hughsie> (blasphemy mode) I use fedora, so is there anything (other than the new gconf stuff) that I can do to better suit ubuntu?
* mvo goes to bed now
<ogra> hughsie, the messaging stuff should get sorted.... thats my main concern curently... how do you plan it for RH ?
<hughsie> the DBUS stuff, yes, that's on my todo
<ogra> mvo, a big big thank you for ffmpeg help 
<ogra> hughsie, great :)
<hughsie> whats the ubuntu take on the services issue.? DBUS daemon rather than init.d daemon
<ogra> we have a session daemon running
* sivang is trying to catch yest a few last bits of development discussion before having to go to sleep...work tommorow..
<ogra> hughsie, so everything should happen in the user session
<hughsie> at the moment, yes.
<hughsie> but there's the debate about what happend at the gdm login screen
<ogra> but we could even wave it in to dbus' startup script
<hughsie> sure, that would be ace
<ogra> like network-manager for example
<ogra> i have to look at the NM code but it should be easy to implement...
<hughsie> Sure, thanks.
<hughsie> Okay, if you guys come up with any patches ideas etc, then please email me, or join the list:
<ogra> hughsie, ah, and i agree, the powermanagement stuff should get dropped from xscreensaver.... i think i'll add a button there to run your preferences
<hughsie> https://lists.sourceforge.net/lists/listinfo/gnome-power-devel
* ogra subscribes
<hughsie> ogra: yes, agreed, but my screensaver timeout does nothing at the moment, other than setting a gconf value!
<hughsie> I'm pretty receptive to new ideas and stuff, so I welcome patches!
<ogra> hughsie, ok, i'll look what i can do... unfortunately i havent the time before breezy to add gconf to xscreensaver which would be the best to do
<ogra> (and is on my list since quite some time)
<Nafallo> ogra: breezy+1 ;-)
<ogra> yeah
<hughsie> No problem, nice one
<ogra> and gdm integration love for the lock screen ... vuntz will do that for us in breezy+1 (hopefully)
<hughsie> I need to get the DBUS interface sorted, i.e. so totem can tell g-p-m not to click in the screensaver when watching a video fullscreen.
<ogra> yeah
<hughsie> and we can do a (I'mAboutToSuspend) warning for applications
<ogra> great !
<mako> tseng: yes
<mako> tseng: it was a happy hacking lite2 USB
<mako> tseng: it has half-height arrow keys which was controversial but important
<mako> and these days, usb works anywhere so it's all you really need
<mako> tseng: it's not cheap but i would recommend it highly.. i am traveling with mine now
<hughsie> ogra: gpm and lock? I hadn;t thought of that
<mxpxpod> mako: what's that?
* sivang waves sadly good night to all, maybe see you tommorow or in the weekend.
<ogra> hughsie, i hacked the lock screen for the last version... but jwz started to change the code, included his own xpm functions etc, so its a PITA to patch it again...
<ogra> hughsie, and i'm not after doing it a third time :) so a final solution should be found, gdm just seems right
<hughsie> ogra: good for me.
<mako> mxpxpod: google for it.. it's a suprising small full-sized unix friendly keyboard
<hughsie> I want to get the dbus api fleshed out this month, so make sure you pipe up!
<ogra> i will :)
<mako> mxpxpod: it's good for posture on laptops if the whole bending over thingg doesn't do it fo ryou
<hughsie> ogra: do you kow about the http://archive.ubuntu.com/ubuntu/pool/universe/g/gnome-power/gnome-power_0.0.5-1.diff.gz ?
<hughsie> any of that belong upstreeam?
<mxpxpod> ogra: is gnome-power in ubuntu hooked up to pmi?
<ogra> hughsie, thats my package 
<ogra> mxpxpod, not yet
<hughsie> ogra: oops :-)#
<ogra> mxpxpod, we're working on that
<mxpxpod> ogra: oh, right
<ogra> hughsie, fresh from this afternoon :)
<hughsie> sorry guys, what's pmi? is that the ubuntu power stuff?
<mxpxpod> hughsie: power management interface
<hughsie> gotcha, googled
<ogra> hughsie, as i mailer pmi suspend and pmi hibernate :)
<hughsie> ahh yes. cool.
<ogra> hughsie, as well as pmi query
<tseng> mako: man yeah im really tempted
<ogra> which gives you the enabled capabilities
<tseng> mako: what about no home/end/pgup/down?
<tseng> mako: i think i might miss those
<hughsie> (phone)
<hughsie> ogra: so does any of the debian bits belong upstream?
<ogra> hughsie, only the integer fix you already did
<mxpxpod> ogra: will gnome-power still need pbbuttonsd? or will it totally control powermanagement?
<mxpxpod> also, will it control cpu scaling?
<ogra> hughsie, and thanks for pointing me to it, i forgot to rip out the uuencoded icon i had added for the last cvs version :)
<hughsie> mxpxpod: not cpu scaling, thats on the todo, but I want to get the battery stuff don first
<mxpxpod> ah, cool
<mxpxpod> alright, I'm going to go download breezy... I'll talk to you guys later tonight
<ogra> mxpxpod, cpu scaling is done by powernowd automatically, i doubt we'll change that
<ogra> hrm
<Burgundavia> ogra, did you need help with bugday?
<shaya> ogra: powernowd dies after hibernation
<ogra> shaya, on hoary ?
<shaya> it keeps machine in slow state always until stopped and restarted
<shaya> breezy at least
<ogra> shaya, bug # ?
<ogra> Burgundavia, sorry, i was very busy with other stuff today
<Burgundavia> ogra, np
<hughsie> ogra: gnome-power-manager.sgml is that a man page?
<ogra> Burgundavia, but indeed we need every helping hand, especially form people who know bugzilla as good as you do ;)
<Burgundavia> ogra, ok
<ogra> hughsie, yep
<ogra> hughsie, but it needs an update
<shaya> bugzilla search isn't working
<shaya> but I'm pretty sure I filed a bug
<ogra> hughsie, i'll mail you the next version if you want it
<shaya> hibernation also breaks vmware as ifconfig down's vmware virtual adapters on the host
<shaya> so cant connect from host to vm
<hughsie> ogra: go for it, richard at hughsie.com
<hughsie> I'll add it to the CVS
<ogra> shaya, if you file bugs we'll likely solve it for breezy :)
<ogra> hughsie, ok...
<ogra> hughsie, let me build that new package next week with al new options... then i'll rewrite the manpage
<hughsie> ogra, no problem
<ddaa> Anybody knows if dash has a public VCS?
<hughsie> ogra: I love patches!
<ddaa> Alternatively...
<shaya> I filed bugs
<ddaa> Does anyone think that dash has _no_ public VCS?
<shaya> woops
<ogra> ddaa, VCS ? Video Connection System ?
<shaya> searching mozilla bugzilla
<shaya> duh
<ogra> heh
<ddaa> ogra: version control system, dude...
<ogra> ddaa, *g* 
<shaya> ogra: https://bugzilla.ubuntu.com/show_bug.cgi?id=11681
<thom> ddaa: clue for you. on any debian system, /usr/share/doc/foo/copyright
<ddaa> thom: makes sense
<thom> it'll tell you where to download from, and may very well give you enough detail to work it out
<shaya> ah, thom who closed my vmware bug!
<shaya> https://bugzilla.ubuntu.com/show_bug.cgi?id=11899
<thom> ddaa: it appears to be in bk, fwiw
<thom> shaya: whatever
* ogra has a pizzawiting that slowly cools down....
<ogra> waiting even...
<ddaa> thom: somebody put rcs details from some netbsd repo (that apparently does not work right)...
<thom> ddaa: i'm sure you can snag it out of netbsd's repo, yes
<ddaa> thom: well, since the idea is to get _upstream_, I'm not sure that using netbsd as an intermediate is a good idea...
<Kamion> ddaa: the netbsd repo is probably actually upstream
<Kamion> ddaa: well, upstream for ash
<Kamion> ddaa: Herbert forked ash to create dash
<ddaa> Kamion: this page suggest dash forked off ash a loooooong time ago http://gondor.apana.org.au/~herbert/dash/
<Kamion> I didn't realise it had forked so long ago; I was thinking of when it was renamed
<Kamion> but OK
* ddaa uses launchpad_prod superpowers to wipe rcs details for dash, and move it into the "unsupported" bucket.
<hughsie> anyone: how does ubuntu control it's hard disk spindown? using hdparm like fedora?
<thom> hughsie: yes
<ddaa> thanks for the hint thom, but do not hope that will keep me quiet, I'm not going to install all the packages in main just to get to the details :)
<tseng> hughsie: laptop-mode modifies hdparm values
<hughsie> thom, tseng: so if i wanted to modify the value to, say 2 minutes on ubuntu what would i type?
<thom> ddaa: by way of another clue, packages.ubuntu.com links to teh changelog for every *single* package
<tseng> hughsie: er, man hdparm
<hughsie> tseng: same as fedora, thanks
<tseng> hughsie: yep.
<hughsie> tseng: i wondered if you had a fancy script!
<ddaa> thom: I'm using p.u.c all the time, I did not realise that the changelog had useful information for me.
<Kamion> it links to the copyright file too
<ddaa> I see... I can find some hints there "apply patch from upstream bk".
<thom> hughsie: sadly not configurable right now
<hughsie> thom, okay, thanks
<thom> (well, without hacking the stuff in /etc/acpi directly)
<tseng> thom: make my cdrom use dma in boot, kthxbi
<thom> ddaa: uh, s/changelog/copyright/ sorry
<thom> tseng: is your hdparm config right?
<tseng> thom: yes
<tseng>  /dev/hdc {
<tseng>          dma = on      
<thom> hrrrrms
<tseng> iirc the bug is cdrom modules get loaded after hdparm starts
<thom> hahah
<thom> hm, no. that should be fine
<thom> since hdparm is also run by hotplug/udev
<tseng> hm
<tseng> i think its fixed now
<tseng> when did hotplug start running it?
<thom> yonks ago
<tseng> hm, silly me
<tseng> ive still been setting it by hand
* Nafallo adds himself to the list of silly people tseng started
<ogra> thom, but why is the bug still open ?
<ogra> (i didnt see a FIXED notice)
<tseng> Nafallo: i did no such thing
<thom> jbailey and i had tag teamed it into working by Mon, 21 Mar 2005
<thom> ogra: prolly cos we forgot to close the bug? ;-)
<ogra> heh
<Nafallo> tseng: well, I sign you up on it then ;-)
<bddebian> jbailey actually did something?? Wow!
* bddebian runs away
<mako> tseng: thoe keys are there
<mako> tseng: they are function keys though
<mako> tseng: it's super conveniently set up though
<tseng> mako: ah, rock
<mako> tseng: same with the f-keys
<tseng> mako: the one im looking at has blank keyfaces actually
<Kamion> tseng: you said "silly me" => list of one silly person
<tseng> Kamion: ah, lappend :)
<thom> ogra: 4356 is closed
<mako> tseng: control-alt-f1 is a bit tricky because it's 3 modifiers instead of two :)
<mako> tseng: but nothing else really feels awkward ever
<tseng> mako: i dont bind that combination to anything :D
<tseng> Kamion: im chronically dumb
<dholbach> tseng: come one, you're not :)
* dholbach hugs tseng 
<tseng> mako: back in the day i had every function key bound to some action with every modifier, pretty wack stuff
<ogra> thom, ahh, i looked at 3672... thats a duplicate
<mako> tseng: i still do.. ion3
<tseng> openbox here
* ogra slaps himself for looking in evolution instead of bugzilla
<thom> ogra: that's a totally different problem
<tseng> i just use bindings alot less heavily now
<tseng> i acutally run gnome-panel and such
<ogra> thom, huh ? why did mdz mark it as a duplicate for 4356 then ?
<thom> ogra: 3672 is "work out that my cdrom is dma capable, and turn it on for me", not "i added my cdrom to hdparm.conf and nothing happened"
<thom> ogra: 3672 isn't a dup of anything
* ogra finally looks in bugzilla
<thom> ogra: go to bed :P
<ogra> heh, yes, i should....
<Nafallo> yay!
<mdz> ogra: 4356 is "hdparm starts before all hardware detection has been done"
<mdz> which is part of "hardware detection should happen earlier" (5204)
<ogra> mdz, yeps, i mixed them up....
* Nafallo subscribes to 3672 :-)
<mako> alright.. dinner time
#ubuntu-devel 2005-07-03
<tseng> mdz: do you have a handy list for outstanding mono->main reports?
<mdz> tseng: just what anastacia tells me
<mdz> elmo: speaking of which, what would be the best way to set up an automated anastaciai run and publish the result?
<mdz> s/iai/ia/
<tseng> mdz: just dug up your last list from devel and subtracted what ive done since. thanks
<mdz> tseng: is there anything which is ready to move which has not yet been moved?
<ddaa> Usual question. This time for debiandoc-sgml (oh, yes, I did find the page on alioth, but it's useless, and I could not find it in the debian cvs and svn repos, and the copyright file is useless too).
<tseng> mdz: when pitti and I looked at the last batch we were suprised to find some stuff was already moved
<tseng> mdz: ill try and check on outstanding stuff
<tseng> mdz: the last batch looks to be all settled.
<lsuactiafner> tseng : do you get paid to develop?
<tseng> lsuactiafner: not for ubuntu :)
<mdz> tseng: if I recall our last conversation, you said pnet and treecc would go away; that leaves us with only xsp and gmime2.1
<tseng> mdz: xsp should be gone
<tseng> mdz: we seeded monodoc-http to universe
<tseng> i see evolution-sharp, beagle, gmime2.1, libgmime-cil
<tseng> ah evolution-sharp is done
<mdz> right, libgmime-cil and libgmime2.1 are from the same source
<tseng> ah, right.
<tseng> mdz: great, exactly what I expected
<tseng> mdz: do you have any idea how to knock the pnet stuff out of the seed?
<mdz> tseng: I forget what the situation was with that
<tseng> mdz: they supply virtuals
<mdz> ah, right
<tseng> mdz: mono itself can fill them, so germinate over looks it (same source)
<mdz> so the thing to do would be to replace any deps on virtual-package with concrete-package | virtual-package
<tseng> hm i think its like that
<tseng> mono-mcs | cli-compiler
<tseng> one second
<mdz> check the rdepends and see if there's another package with a different dep
<tseng> nothing is jumping out at me
<tseng> does apt-cache depends show only the first virtual option?
<mdz> tseng: sorry, I meant the germinate rdepends
<tseng> rdepends for pnet-interpreter and treecc has nothing mono-ish
<tseng> certainly not mono-mcs
<tseng> the only thing i see atm is mono-mcs conflicts with pnet-compiler
<mdz> so mono-mcs is the one that we want, right?
<tseng> in some packages we have mono-mcs (>= 1.1.6) | c-sharp-compiler, mcs itself is certainly not one of those
<tseng> mdz: yep.
<mdz> I'll seed mono-mcs, then; that should take care of it
<tseng> thatd be perfect
<tseng> ill look into gmime, its schweeb's package and beagle reports early this week
<tseng> one less breezy goal to bother mdz :)
<ogra> tseng, dont forget to change your status ;)
<tseng> ogra: ok jane
<mdz> completed goals make mdz happy
<ogra> hehe
<mdz> goals completed early make mdz extra happy
<dholbach> with REVU we got closer to ExpandingUniverse :)
<mdz> ogra: speaking of which, would you update the status of your various goals (and include a date so we can see when it was last updated)?
<ogra> mdz, btw, what do we do about UbuntuExpress ... i looked at the package today
<mdz> dholbach: REVU?
<dholbach> mdz: http://siretart.tauware.de/revu/index.py
<tseng> ogra: ill make mono light green
<mdz> ogra: UbuntuExpress needs for me and Kamion to spend some time together
<ogra> mdz, the frontend to elma ;)
<dholbach> mdz: it will hopefully speed up our review process
<tseng> dholbach: im not sure speed it up is right
<mdz> ah, I've seen this.  I didn't realize it had a name
<tseng> but its easier to keep track
<tseng> of what is ready to go
<tseng> and what needs more work
<ogra> mdz, i already talked to sabdfl about a vserver or something along this line for it
<dholbach> tseng: not in terms of just giving signatures for packages
<tseng> ogra: i think smurfix is mostly in charge of those, mainly for loco use
<ogra> tseng, yes, bu if sbuild doesnt work in a vserver we need to find another solutin
<tseng> ogra: oh are they really a vserver?
<tseng> we were talking about linode at udu, which is uml or xen
<ogra> tseng, dunno, i never saw one
<tseng> (xen is in beta)
<ogra> yes, i happen to remember something about linode....
<smurfix> I will be once the stuff is operational. Coming Soon (for some value of "soon", anyway).
<tseng> smurfix: is it a vserver setup?
* ogra wonders if he can switch PowerManagementConfiguration to green already...
<tseng> they are still on the udu wiki right?
<ogra> yep
<KaiL> ogra: all except the KDE frontend fone?
<KaiL> done..
<ogra> KaiL, yes, but gnome-power is waiting to go to main... and i'm wondering if i can already switch status or should wait
<tseng> RAGE
<tseng> if you go to https://udu.wiki
<ogra> tseng, ?
<tseng> it takes you to the main page
<tseng> so i cannot put in my password securely
<tseng> ah.. i can login to the main page https and go back
<tseng> somehow
<KaiL> battery critical = <20%? a bit high, or?
<dholbach> i'll call it the day, if somebody of you has some minutes to spare, review day is still going on in some timezones *hint*
<ogra> KaiL, turn it down then :)
<tseng> g'night dholbach 
<ogra> night dholbach 
<KaiL> ...and gnome-power-manager seams to need a running gnome :)
<KaiL> ah, no - it dislikes, that hal doesn't want to start here
<ogra> KaiL, nope, a notification area and a running HAL 0.5
<KaiL> am I the only one with broken hal on breezy?
<ogra> KaiL, might be... here they all work....
<KaiL> run-parts: /etc/dbus-1/event.d/20hal exited with return code 1
<KaiL> ..I hate such helpfull messages...
<KaiL> this time returns 2.,..
* ogra is off to bed
<ogra> night all
<KaiL> n8 ogra 
<tseng> bye ogra.
<ajmitch> night ogra 
<lsuactiafner> anyone here got a static 32bit mplayer binary that supports -vo x11?
<ddaa> Hey fellow ubuntite. Anyone knows about a potential debmake VCS?
<Kamion> ddaa: debmake is frighteningly obsolete
<ddaa> Kamion: I gathered from the copyright notice
<Kamion> if it isn't in a VCS already, I doubt anyone will be motivated to rectify that :-)
<ddaa> that's the "is it in a VCS already" bit I'm asking about ;)
<ddaa> Anyway... I sort of guess that all the active development is taking place in the form of deb patches...
* ddaa considers that Kamion not knowing about it is a sufficient clue that it does not exists ;)
<mdz> ick, we have stuff in main which uses debmake?
<lifeless> mdz: debmake is in main
<lifeless> mdz: if you don't want it there, just say so ;)
<mdz> 5 of them
<Kamion> it's not seeded so stuff must use it
<mdz> lifeless: well, I sort of want main to build ;-)
<mdz> * Reverse Build-Depends:
<mdz>  +- acl
<mdz>  +- attr
<mdz>  +- dmapi
<mdz>  +- libcompface
<mdz>  +- xfsdump
<lifeless> really ?
<lifeless> damn, you've thought of everything :)
<lifeless> I had a hard lockup playing a video :[
<lifeless> complete change of topic ;0
<mdz> reproducible?
<ddaa> mdz: there's plenty of "questionable" stuff in main...
<mdz> free drivers or binary?
<lifeless> mdz: too busy to try to repeoduce, free drivers
<lifeless> vlc-gnome
<tseng> lifeless: on a laptop by any chance?
<lifeless> tseng: yes
<tseng> lifeless: on battery?
<mdz> ogra: don't forget that BreezyGoals update
<ddaa> mdz: like this "bonobo" package, whose difference with "libbonobo" is entirely unclear (and that nobody has clarified for me).
<lifeless> vlc showed a blue square, then x bounced, bounced, bounced, stopped cold
<lifeless> tseng: no
<tseng> lifeless: nm then :)
<mdz> ddaa: did you ask seb128?
<tseng> i get hardlocks from laptop-mode
<ddaa> at some point, he did not answer...
<lifeless> ddaa: bonobo == libbonobo from a vcs pov
<ogra> mdz, is it enough if i do it tomorrow morning ? 
<lifeless> ddaa: established that a year ago ;)
<ddaa> I'm making a small stash of weird, obscure, hopelessly obsolete, or otherwise mysterious stuff I had no answer about when I first asked :)
<mdz> ogra: certainly, just don't forget :-)
<ogra> mdz, surely not :)
<ogra> thanks
<mdz> ogra: good night
<ddaa> like... debiandoc-sgml?
<ogra> and night :)
<ddaa> lifeless: ack, moving bonobo to alreadydone
<lifeless> bonobo-ui is different though
<ddaa> yeah, I know
<ddaa> it's just a collection of random deprecated stuff :)
<ddaa> the discussions with jdub and bob2 about it were a bit funny to read... 
<mdz> ddaa: debiandoc-sgml is legacy, but it's not going away until documentation using it is converted to something else
<ddaa> mdz: this kind of information is interesting
<Kamion> documentation packages are the sort of things that never really go away
<Kamion> documentation support packages, I mean
<ddaa> but it does not help the very narrow focus that motivated my question, is there any public "upstream" vcs for it.
<mdz> ddaa: if you were to create a page in the Ubuntu wiki with your list and notes, that would be interesting
<Kamion> because everyone has their own favourite doc format and it requires effort to which over
<Kamion> s/which/switch/
<ddaa> mdz: we actually have an arch archive were we do that
<mdz> ddaa: iwj would probably know if it ever had a vcs
<Burgundavia> elmo, ping
<ddaa> it's not very detailed, when it's in launchpad, we just record the name of the corresponding product and series. We only keep notes for the weird cases about which we were not able to establish existence (or lack) of a VCS and for some of unsupported (bk, arch) ones.
<ddaa> sadly a lot of the previous research work was not recorded anywhere :(
<ddaa> mdz: does iwj usuall hang on this chan?
<ddaa> ha...
* ddaa clicks in
<ddaa> new employee :)
<ddaa> mhhh...
<StylusEater> hello
<StylusEater> is crimsun around?
<Kamion> mjg59: http://people.ubuntu.com/~cjwatson/hoary-hp-laptop/ # apt archive of the stuff you've given me
<Kamion> lamont: ^--
<lsuactiafner> asking here since #ubuntu doesnt seem to know, how do i apt-get xmms-mplayer without apt-get installin mplayer as a dependancy?
<lsuactiafner> i got mplayer already installed.. i compile it myself.
<Kamion> use equivs
<Kamion> it can generate a fake package for you
<lsuactiafner> tar
<lsuactiafner> hehe this is going to be fun
<lsuactiafner> heh what woudld the command be to bypass the dependancy mplayer-amd64?
<lsuactiafner> i see thanks
<Kamion> it comes with documentation
<lsuactiafner> actually are you sure this util can be used for this?
<Kamion> yes
<Kamion> gaaaaaaaaaah, why is gnome-terminal uninstallable
<Kamion> ah, gnome-terminal-data universe->main, doing
<wasabi_> Hmm. Interesting. Working on a package. I want to create a symlink from $(variable1)/file1 to $(variable2)/file2.
<wasabi_> Basically within debian/tmp.
<wasabi_> I can't fully qualify the second, because then the symlink is wrong.
<Kamion> wasabi_: use dh_link
<Kamion> daniels: are you doing l-r-m for 2.6.12? (if not, is it trivial to do?)
<wasabi_> will dh_link operate inside debian/tmp?
<wasabi_> newp.
<Kamion> its man page is pretty clear ...
<wasabi_> I can't use .links.
<Kamion> you don't have to
<Kamion> it takes source/target paths as arguments
<mdz> Kamion: do you know where cron.sync gets its seeds from?
<mdz> it seems to be looking at old seeds
<mdz> oh, I bet it's kubuntu
<Kamion> mdz: it'll be germinate's default, i.e. http://people.ubuntu.com/~cjwatson/seeds/
<mdz> Kamion: once we have edubuntu in the mix, I think we'll need to have some sort of merged germinate output in order to be able to tell what's going on
<Kamion> I could create aggregate seeds to avoid having to modify germinate
<Kamion> current daily CD build works fine with the exception of archive-copier and gnome-terminal (both fixed)
<Kamion> hmm, and "Error" "failed to initialize HAL!" at desktop start
<mdz> grrr
<mdz> I can't fix kubuntu because the seed archive is broken again
<mdz> Riddell: ping
<mdz> drwxr-sr-x  3 jriddell warthogs 4096 Jun  8 22:17 /home/warthogs/archives/kubuntu-devel@lists.ubuntu.com/seeds/seeds--breezy/seeds--breezy--0/patch-8/++revision-lock/
<KaiL> mdz: you expect him to be still awake? ;)
<mdz> KaiL: it's worth checking, because this is blocking something I need to do
<mdz> lifeless: is this something which could be fixed in baz?
<mdz> lifeless: e.g., force consistent permissions on new directories created in the archive?
<lifeless> mdz: yes
<lifeless> mdz: we need to figure out how to set permissions via sftp.
<lifeless> or you can use the team-archives on the supermirror, which sets umask automatically
* Clint coughs and it sounds like "ACLs"
<StylusEater> mdz: you seen crimsun?
<KaiL> mdz: little bit OT, do you know, what's going on with debian-security? (you are listed as being in the team..)
<mdz> lifeless: where can I find more information on team-archives?
<mdz> KaiL: very OT for this channel
<mdz> StylusEater: not recently
<StylusEater> mdz: thanks...been looking for him/her
* KaiL tries to create an on-topic-question of it...
<KaiL> how many of that 5 are now working for ubuntu?
<mdz> KaiL: assuming you mean Canonical, rather than Ubuntu (nobody works for Ubuntu), one
<lifeless> mdz: chat with spiv - I don't know if we've rolled out that speicfic code yet
<KaiL> as I expected.. because some people talk rubbish about this like "they are now payed to work on ubuntu and so don't have the time to work on debian any more"
<mdz> KaiL: it's exactly that, rubbish
<mdz> especially if it came from rene engelhard
<KaiL> who's that?
<mdz> someone who has been spreading similar rumours
<StylusEater> people are upset over the PERCEIVED "brain drain"
<StylusEater> but work for ubuntu helps debian IMHO
<KaiL> http://lists.debian.org/debian-user-german/2005/06/msg03342.html and there we have him saying more or less this :)
<StylusEater> KaiL: why add fuel to the fire? this is a dev channel
<mdke> i was gonna say that
<mdke> perhaps make a #bitching channel
<KaiL> StylusEater: I was only collecting arguments, if there are again questions in #ubuntu-de
<mdz> someone created a stir at linuxtag, I gather
<StylusEater> das ist goot
<mdke> shame
<Kamion> long off-topic discussions in this channel make it difficult for developers to find useful information in scrollback when they return from a period of not paying attention to IRC
<StylusEater> :-)
<carstenh> goot?
<KaiL> mdke: this might interest you, as he's calling you directly there: http://lists.debian.org/debian-user-german/2005/06/msg03346.html
<mdke> completion error
<mdke> not me guv
<KaiL> in short [to prevent Kamions mousewheel from overheating ;-)] , you are blocking packages in debian not to be updated and doing nothing there any more...
<carstenh> "doing nothing there anymore" is not correct
<carstenh> he did not say that, he talks about apt 0.6 security etc. but not about "doing nothing"
<KaiL> carstenh: second line
<carstenh> hmm, i think this means doing noting in/for security
<carstenh> nothing
<StylusEater> I am out y'all...
<carstenh> KaiL: but maybe you are right and i misinterpreted that
<KaiL> I mean debian-security with "there" ;)
<mdke> KaiL, check out the thread on debian-security, it has some information for you, but surely enough in this channel now?
<carstenh> KaiL: oh, sorry. :)
<KaiL> and now EOT for that - back to real problems ;))
<mdke> phew
<tseng> i wonder if this new sun opteron workstation runs ubutnu nicely
<tseng> you can get it with JDS
<tseng> (on linux)
* luis_ wants one with solaris for a gnome tinderbox
<tseng> luis_: i want one for ubuntu/mono love
<tseng> luis_: i am the auto-tinderbox
<tseng> sebuild-lite
* schweeb shudders about Solaris
<schweeb> you guys are scaring me here
<bddebian> OpenSolaris?
<schweeb> well, luis_ is :p
<schweeb> a dog and pony show.
<tseng> schweeb: its a nice looking box
<tseng> schweeb: if it runs a nice os
<schweeb> tseng: yea, I do admit, the opteron hardware is nice
<tseng> sata disks
<tseng> gige
<tseng> pcie.. its loaded
<luis_> schweeb: my only motivation is to get sun hacking on HEAD again, or close to it
<schweeb> that is a good motivation, I suppose
<luis_> they can shove the CDDL up their ass for all I care
<schweeb> :)
<jdub> http://primates.ximian.com/~fejj/blog/archives/000031.html
<jdub> bah, no pitti
<luis_> but they currently assume HEAD is crap
<tseng> jdub: yeah dude
<luis_> partially because, well, it doesn't necessarily build on solaris :)
<tseng> jdub: working with snorp and CO on ipod stuff
<schweeb> luis_: I work w/ Solaris all day long, and I'm not a fan
<tseng> jdub: those lamers are all on submoutn
<luis_> schweeb: I had to work with it during the GNOME 2.0 cycle, and... well, we weren't very excited by it either ;)
<jdub> fejj is angry mans
<tseng> i hope in the next release they tell submount to piss off
<tseng> its so bad
<jdub> luis_: so i downloaded sexpressb16 for sparc to install on my u5 and 220R
<schweeb> luis_: I even have JDS, and am not particularly impressed... I'm removing it in favor of gnome 2.8 from blastwave
<schweeb> I wanna try netinstalling from fabbione's images again to my Blade 100
<jdub> luis_: if i can find a way to leave the 220R on for a useful period of time without clawing my ears off, i'll give you access
<tseng> does solaris at least have a nice base of gnu tools now?
<schweeb> tseng: not by default
<jdub> tseng: not by default
<schweeb> tseng: blastwave
<jdub> heh
<tseng> man i hate that
<tseng> aix too
<schweeb> aix 5.1 I despise
<schweeb> 5.2 is a bit better
<jdub> raaaaiin
<tseng> schweeb: i had to use aix 4 several times
<jdub> pia saw steve ballmer speak yesterday
<tseng> schweeb: </3
<jdub> she came home very angry
<schweeb> tseng: I had an AIX box with a load of 1200 today
<tseng> holy crap
<schweeb> and it was still climbing when I logged off
<tseng> did you run vi?
<luis_> schweeb: from my perspective, JDS sucking is bad for GNOME
<jdub> "he was LYING about INTEROPERABILITY!"
<luis_> schweeb: so I want to help make it not suck
<tseng> jdub: blog it!
<jdub> "he was TALKING about INTEROPERABILITY?!"
<luis_> jdub: yeah, seriously, blog that, or make her do it
* luis_ does not know why he doesn't read piablog yet
<jdub> i think she might
<tseng> put her on puc
<schweeb> tseng: that's 1200... on an 8way 1.2Ghz power4 box, with 32GB of RAM
<jdub> she is not a member :)
<schweeb> I was like, holy crap
<tseng> schweeb: eh.
<schweeb> oracle totally demolished that box
<jdub> and having to live with canonical staff is not yet member-worthy :)
<tseng> haha oracle
<tseng> what a scam
<luis_> jdub: someone at ucc offered me a crazy eight-way sun box today
<luis_> but only by way of buildbot
<tseng> jdub: want to hear about my dillema?
<luis_> and AFAICS buildbot just Ain't Going To Cut It for gnome
<jdub> hfsnw
<jdub> "Norwegian Minister of Modernization"
<luis_> yeah
<jdub> tseng: your bad spelling?
<luis_> great title
<tseng> jdub: at work I have a totally random mixture of redhat/fedora/rhel boxes
<schweeb> jdub: <3
<schweeb> jdub: another spelling nazi, I see
<tseng> jdub: i told my boss they should all run the same version so we can actually maintain that crap
<tseng> jdub: so his boss is like zomgbbquackrhel
<tseng> its hard to sell ubuntu support when it doesnt cover the stuff we are using
<tseng> php4-mysql and etheral come to mind instantly
<jdub> tseng: what stuff? we can sort that out.
<jdub> php4-mysql was a fuckup
<tseng> ah tcl is supported
<ajmitch> putting ethereal in main would probably make pitti annoyed
<tseng> ajmitch: yes
<jdub> ethereal would get mdz and pitti riled up
<jdub> but it's doable
<tseng> we use it internally to debug network issues
<tseng> im not saying it should move
<jdub> tseng: if you have specs, or things that may help you, please mail me :)
<tseng> but would it be possible..
<tseng> to get support contracts based on certain "extra" packages?
<tseng> within reason
<jdub> yes
<tseng> clever
<tseng> who takes support calls?
<jdub> tseng: and probably some bonuses, given that your company employs an ubuntu maintainer :)
<jdub> tseng: our Support Team
<jdub> (read: jbailey)
<tseng> ah!
<tseng> totally rad.
<jdub> totally rad laptop support :)
<tseng> yeah the whole support scene is so bogus
<tseng> i feel dirty looking at RHEL pricing
<jdub> we need a minister for modernisation
<tseng> you need to pimp the support page harder :)
<wasabi> Slight alternitives problem. I am running update-alternatives in postinst, the alternative is being created... but hte link to the alternative isn't...
<tseng> i just got a spam that started with { Spam? }
<carstenh> tseng: maybe your isp did add this for you ;)
<tseng> carstenh: i own the mailserver, its direct to a backbone in a data center
<bddebian> Dumb gpg question:  Why would gpg -se -r foo@bar.com test.txt fail with public key not found, when gpg --search-keys foo@bar.com succeeds?
<tseng> carstenh: an isp doesnt touch my mail :)
<carstenh> hmm
<mdz> jdub: ethereal GRRR
<wasabi> Finally. Eclipse 3.1 looks done.
<wasabi> Now with native GCJ goodnes.s
<jdub> mdz: :)
<mdz> daniels: will you be preparing l-r-m-2.6.12, or is someone else working on it?
<wasabi> Buh. I'm doing something simple and wrong.
<wasabi> update-alternatives --quiet --install /usr/bin/ecj ecj /usr/bin/ecj-bootstrap 3          in my postinst.
<wasabi> Yet /usr/bin/ecj is not showing up.
<infinity> wasabi : Does it work manually?
<wasabi> Well, the alternatives look installed... the link isn't created though.
<wasabi> I didn't think I was supposed to create it on my own, am I?
* wasabi read
<infinity> No.
<infinity> What happens if you remove the installed alternative, then add it?
<wasabi> Heh. Just removing it created it.
<infinity> Do you have another ecj alternative?
<infinity> Or just the one?
<wasabi> Yup
<mdz> tseng: thanks for taking care of those mono bugs in bugzilla
<wasabi> Any cdbs wizards available? Trying to figure out how to make a make target in rules that is applied once per package, after install.
<dilinger> $(patsubst %,build/%,$(DEB_ARCH_PACKAGES))::
<daniels> god, xserver-xorg.{config,postinst}.in are a mess
<dilinger> use install instead of build
<daniels> dilinger: wow, cdbs makes everything so easy!
<dilinger> daniels: there's a reason it's being rewritten :P
<doko> wasabi: please choose a higher priority for the ecj-eclipse package
<infinity> daniels : Oh, that reminds me, over the weekend I repackages xorg to use cdbs, I'm uploading right now.
<infinity> s/repackages/repackaged/
<daniels> infinity: great!  you get to keep both pieces.
<infinity> Only two?... That's surely an improvement. :)
<calc> btw 2254 still seems to affect users and apparently it works on fedora and gentoo
* Lathiat grins at infinity 
<calc> is there a way to cc: an email to buzilla bug number?
* Lathiat envisages spam in bugzilla reports
* calc envisages lack of data in bugreports since he can't cc: email to someone not subscribed to the bug about the issue :)
<Lathiat> sigh, almost no applications deal with the system tray going away
<fabbione> morning
<mdz> fabbione: morning
<mdz> fabbione: what was the reason for not doing a 'linux' metapackage as I originally proposed?  I don't remember it
<fabbione> mdz: it's there for all arches that can have it
<mdz> fabbione: I said metapackage
<fabbione> mdz: it's missing on hppa/ppc only iirc
<fabbione> oh i added it as provides in the kernel package
<mdz> right, which does not have quite the same effect
<fabbione> ok, we can move it today without any problem
<mdz> and I do not remember why you wanted to do a virtual package instead of a metapackage
<mdz> you had a reason for it
<fabbione> i don't recall having a reason for that...
<fabbione> other than we can do it but not for all arches....
<fabbione> mdz: i need to upload a kernel today for Kamion, so we can easily move it out of the kernel and add it to linux-meta
<mdz> fabbione: ok
<mdz> it is useful to have the metapackage so that it can track new versions
* fabbione tries to remember...
<fabbione> ok
<fabbione> sure
<mdz> with a virtual package we would have to remove the provides from the old version
<fabbione> works for me :)
<wasabi> Interesting. debuild -S doesn't enforce deps?
<mdz> fabbione: this is very convenient for ltsp, which needs to install a generic kernel in its chroot
<fabbione> mdz: that's fine.. i really don't recall any reason for not making the metapackage....
<infinity> wasabi : They're "build-depends", not "clean-depends".. :)
<wasabi> My package requires them for clean. ;)
<wasabi> (there isn't a Clean-Depends is there?)
<infinity> wasabi : Realistically, people shouldn't use anything outside build-essential in clean (IMO), but that's certainly not followed by everyone.
<wasabi> It's not neccassarily possible with, for instance, Java.
<wasabi> Where the package's clean routine is build into the ANt scripts, which requires a full JVM> ;)
<infinity> wasabi : In the end, it's no big deal, since buildds will always have build-deps installed, and individual users can do a "dpkg-checkbuilddeps" before fiddling, if they care.
<wasabi> Yeah I know I just found it interesting.
<infinity> wasabi : Sure, but if there was no build run, then it's okay for clean to fail, since there's nothing to clean (so call you clean with "-"), if there was a build run, then the build-deps are installed, right? :)
<wasabi> oooh. Smarty pants.
<wasabi> I don't suppose buildds follow Recommends in Build-Deps
<infinity> Of course not.
<wasabi> Just slightly unfortunate. The Eclipse build could be sped up *2 if they did. ;)
<infinity> How so?
<wasabi> Well, we have two ecj-bootstrap packages now. ecj-bootstrap and ecj-bootstrap-gcj
<wasabi> The -gcj one contains native versions.
<wasabi> They are significantly faster.
<wasabi> the main package recommends teh -gcj package.
<wasabi> I guess I could dep on -gcj, but I don't really want to restrict it to that.
<infinity> You can build-dep on ecj-bootstrap-gcj | ecj-bootstrap
<doko> wasabi: you know that ecj is miscompiled by gcj?
<wasabi> doko, is it?
<wasabi> Seems to be working.
<doko> wasabi: according to man-di, the native build
<wasabi> I know there is one Jar in Eclipse that GCJ miscompiles, but it's not ecj that I'm aware of.
<wasabi> Looks like fedora is using gcj to compile ecj.
<doko> see PR java/21540
<mae> Hi, with anjuta I am getting "config.status: error: cannot find input file: test.in" when i try to do a make autogen... what package do i need to install? (I already installed all the reccomended and suggest packages)
<mdz> mae: that sounds more like a bug in the makefile than a missing package
<mdz> s/makefile/configure script/
<mae> gotcha
<wasabi> doko, http://kyoto.larvalstage.net/~wasabi/ubuntu
<wasabi> Starting what I believe is the final full eclipse build right now. When this is done and confirmed working, I will stick it up too.
<doko> wasabi: what am I supposed to do? ;-)
<wasabi> I just want somebody to review those packages.
<wasabi> I don't want to bust something.
<doko> ahh, ok
<wasabi> Since OO now rests on them.
<mae> do you guys think that a system like scons will ever displace an old crusty system like make? :)
<Lathiat> scons replaces mroe than just make
<mdz> fabbione: is the ppc64 comment in the topic still accurate?
<mae> Lathiat, make/automake etc :)
<wasabi> I think the only remaining issue with this Eclipse is that it probably doesn't work on ~i386.
<wasabi> !i386... but I don't know for sure, as I can't test it. ;)
<womble> wasabi: If you think about it, ~i386 is actually probably more accurate... bitwise negation, rather than logical negation
<mae> Lathiat, hmm
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Colony CD 1 released | | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko
<fabbione> mdz: which comment? ;)
<fabbione> it was leftover...
<mae> Actually wouldnt bitwise & be more appropriate? i.e. i386 & i686 :) eclipse will not work with the minimal i386 "flags" :)
<fabbione> ppc64 is teh rock now
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko
<pitti> Good morning!
<fabbione> mdz: ever tried it on davis?
<mdz> pitti: morning
<fabbione> hey pitti
<mdz> fabbione: no
<mdz> I don't think I even have an account
<fabbione> mdz: you should... davis is faster than concordia now
<fabbione> mdz: i think everybody do.. it's a porting box
<pitti> cool
<mdz> yes, I do
<mdz> tried what on davis?
<fabbione> mdz: concordia starts to slowdown on make -j200
<fabbione> davis: starts at -j500
<fabbione> compiling the kernel for example ;)
<mdz> how long does it take?
<fabbione> and no random segfaults
<fabbione> around 8 minutes per image iirc
<fabbione> with -j200
<fabbione> i usually don't push it too much
* fabbione hides
<fabbione> mdz: do you want linux to Depends: on linux-image-386 or linux-386 ?
<mdz> fabbione: the latter
<fabbione> ok
<fabbione> that will make it landing in restricted...
<mdz> thanks
<doko> wasabi: java-common is not synced with unstable
<fabbione> mdz: see /msg
<fabbione> (i am going to add the other arches if that's ok with you)
<mdz> yep, thanks
<fabbione> mdz: welcome :)
<fabbione> mdz: you will get kernel and linux-meta pretty soon. Kamion needs an urgent change for d-i
<fabbione> so it should be there for when you will wake up later
<doko> elmo: please sync python-numeric and python-numarray from unstable
<daniels> mdz: fwiw, autodetect_monitor seems to be working in -33
<daniels> mdz: also, do you know if preseeding sets the seen flag to true?
<daniels> mdz: if not, making it so would probably be the answer to all your troubles
<doko> wasabi: same with ecj-bootstrap, but that's a minor sync
<wasabi> doko, I'm not too worried about either of those right now. I'd prefer to get my patches well tested before interacting with Debian.
<wasabi> I do know about it though, yes.
<wasabi> Priority: Eclipse 3.1 in Breezy, packaged properly and cleanly.
<doko> wasabi: ant is missing a versioned dep on java-common?
<wasabi> Is it? You are right.
<netdur> it is possible to mail ubuntu-devel asking for tech help about developing stuff for ubuntu?
<wasabi> Err, no it isn't.
<wasabi> Oh, dow there.
<wasabi> down. =)
<doko> wasabi: mail: sure, there is no other place.
<wasabi> Thanks. That's why I asked. ;)
<wasabi> I did the same with ecj-bootstrap.
<wasabi> Notice the new /etc/jvm file? I was thinking, new JVM packages should add themselves to that.
<wasabi> Or maybe not. I dunno. ;)
<wasabi> I'm trying to provide an easy way for users to choose which JVM should be used for what program.
<wasabi> Haha. Eclipse compiles like, 4 times faster with a native Ecj.
<wasabi> Rock on.
<bob2> netdur: sure, if youve exhausted the documentation etc
<netdur> bob2, thanks :)
<daniels> mdz: i suppose it would also make sense, depending on your interpretation of the seen flag
<daniels> mdz: mine would be 'user has consciously answered this question'
<daniels> Kamion: can we add a note to the errata for hoary or such that people running with isa vga should use boot with multiseat-udeb/force_multiseat=false?
<doko> wasabi: we currently do have alternative, we have pseudo java homes, why another mechanism like /etc/jvm?
<wasabi> Because it's important for a real Java developer to be able to set certain specific programs to open with certain VMs
<wasabi> even per-user.
<wasabi> For instance, I use a whole host of Eclipse plugins which are propriatary.
<wasabi> And only work on Sun's VM.
<wasabi> But I want most of my other programs to use gcj.
<wasabi> Except tomcat, which I need to use Sun's for, also.
<wasabi> (I require a security manager)
<doko> so, it's not the jvm that is registered, but a hint, which program uses which JVM?
<wasabi> Basically, until we can guarentee 100% compatibility, something even IBM can't really do with their VM, I need to be able to change.
<wasabi> Yeah.
<wasabi> /etc/jvm, /etc/jvm.d/$programname, ~/.jvm ~/.jvm.d/$programname.
<wasabi> Basically lets any user on the system (shared office workstation, imporant stuff) to set any program to open with any VM.
<wasabi> Someday I want to make a GUI for it.
<bob2> that seems like massive overkill for something that will hopeuflly be unneccessary soon
<wasabi> It won't ever be.
<bob2> ie when kaffe/whatever can run everything
<wasabi> Take CNI for instance. Sun's VM doesn't support that.
<bob2> I've never heard of CNI
<bob2> is it so common that it's unreasonable to make a wrapper for it?
<wasabi> It's a replacement for JNI.
<wasabi> Well, if you think it'll be unneccassary soon, you're too hopeful. Classpath will never implement the com.sun classes.
<wasabi> They are undocumented.
<bob2> people write java code that uses undocumented classes?
<wasabi> Sure.
<wasabi> All the time.
<wasabi> That's OO's problem right now.
<wasabi> But I can rattle off a half dozen apps I use during hte course of my work day that are similar.
<wasabi> Or home day: azureus.
<wasabi> Tomcat 4 uses com.sun classes. ;)
<wasabi> And I still need to test apps against that.
<bob2> what on earth are these people thinking?
<Burgundavia> wasabi, sorry to bug you, but I have user asking after tomcat. It is currently in debian but not ubuntu.
<wasabi> Classic Java stuff.
<wasabi> Burgundavia, correct.
<wasabi> Burgundavia, Tomcat4 uses com.sun classes and thus is in contrib in Debian.
<wasabi> And unpackagable for Ubuntu.
<Burgundavia> ok
<wasabi> Tomcat5 removes the need for those classes, and will be in Debian shortly from what I understand.
<wasabi> ANd then Ubuntu shortly after that.
<lifeless> wasabi: what does II have to do with idiot programmers ?
<lifeless> bah
<lifeless> OO. or did you mean open office ?
<wasabi> Yes.
<lifeless> ah.
<lifeless> java & OO in the same paragraph to me says 'object orientated'
<Burgundavia> wasabi, thank you for that info
<pitti> elmo: quota sync, please
<elmo> pitti: already done
<pitti> thanks
<Duck_Happy> wasabi: install/<pkg>::
<Duck_Happy> wasabi: look at the doc for more info
<Duck_Happy> wasabi: <ad>https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml</ad>
<Burgundavia> elmo, doc svn access
<elmo> Burgundavia: oh, right, sorry
<Burgundavia> elmo, np
<Burgundavia> elmo, whenever is good
<pitti> elmo: wget sync, please
<fabbione> doko: can i spin up davis?
<fabbione> doko: i am kinda in a hurry to test a fix
<fabbione> (it won't take long.. i promise)
<doko> $ w
<doko>  09:37:28 up 19 days, 15:37,  3 users,  load average: 114.67, 32.98, 16.50
<doko> looks like you don't stress it ;-P
<fabbione> doko: i am only at -j200
<fabbione> want me to push more?
<fabbione> it's all I/O
<Lathiat> what machines that?
<fabbione> doko: 25% done already :)
<fabbione> doko: 60% :)
<doko> fabbione: you're flagging, load goes down to 80
<fabbione> doko: that happens at link time.. it's not forkable
<fabbione> doko: it's basically done with the load.. have fun
<fabbione> Kamion: ping?
<Q-FUNK> does ubuntu happen to have a fixed debootstrap that patches Debian#314858?
<chmj> Kamion: ping 
<carstenh> thom: hi mentor :)
<fabbione> Kamion: i won't manage to upload the kernel today
<fabbione> there is some extra breakage that needs love too with the changes we pulled in
<fabbione> hmm probably...
<fabbione> ahhh simple fix
<Reza_M> is there any ubuntu office in vancouver?
<mdke> Reza_M, there is a canadian local team, made up of ubuntu users and volunteers
<mdke> Reza_M, you will find them at #ubuntu-ca
<Reza_M> Thanks!
<carstenh> Reza_M: are you Saba. if yes, did you read the mail from jane weideman?
<tseng> mdz: no problem :)
<doko> chmj: please sync packages from Debian, if you apply changes (i.e. wget)
<subjectdenied> hi
<subjectdenied> coudl anyone help me with x-keyboard in breezy
<subjectdenied> did some symlinks two weeks ago
<subjectdenied> and still my german umlauts are not working
<subjectdenied> switching terminals from X isn't working too
<Lathiat> subjectdenied: have you upgraded to the latest version?
<subjectdenied> Lathiat: yes
<subjectdenied> Lathiat, however i created some symlinks before, i think on version 30 or something because pressing any key resulted in switching dsiplay resolution
<fabbione> Kamion: never mind.. i might manage to get it in today
<Kamion> daniels: I have no idea how to do errata for hoary
<Kamion> fabbione: let me know when you decide ... :-)
<Kamion> Q-FUNK: no, that's not something I've (knowingly) fixed
<Kamion> chmj: pong
<pitti> argh, the "doko rave" again
<ogra> grmbl
<ogra> spammer :)
<Mez> omfg
<Mez> I can tbeleive someone just requested portage as a backport
<Treenaks> Mez: WTF?
<mdke> good idea
<Mez> yeah thats what I thought
<Mez> so I told them it wasnt in debain or breezy, so speak to MOTU :P
<doko> pitti, ogra: heh, I'm not yet finished ...
<Treenaks> Mez: you should have told him about apt
<Mez> http://ubuntuforums.org/showthread.php?t=44904
<mdke> i think its a cool idea
<mdke> might be fun
<Lathiat> Whos responsible for the sparc/hppa ports?
<mdke> but yeah, its in the wrong section of the forum
<Mez> mdke ... If you wanna make portage work in ubuntu - go for it....
* Mez shiudders
* Lathiat laughs
<mdke> i can't do that
<mdke> but it would be fun
<Mez> put it forward to MOTU then
<Mez> I'm sure ogra would do it for you
<Mez> if you ask him nicely
<ogra> haha
<mdke> Mez, you seem confused about what MOTU does
<mdke> packaging portage is only a fun idea
<mdke> nothing more
<Mez> MOTU maintins new packages to go into universe right?
<Mez> portage would be a new pakcge
<Lathiat> hrm, gnome-terminal breaks on upgrade cus the .glade was moved from g-t to g-t- data but g-t-data gets install first
<ogra> would be fun to have a package called portage, that installs gentoo (the filemanager)
<Lathiat> works the second time obviously
<chmj> Kamion: dpkg-source: error: unrecognised file suffix `.tar'
<chmj> Kamion: any idea
<ogra_> chmj, you built a native package by accident ?
<fabbione> Kamion: yes :) rerunning the test build right now.. unfortunatly i hitted 3 problems in a raw.. if this build is ok, i will upload shortly
<chmj> ogra_: no, I just did : bash$ apt-get source lsb-base 
<ogra_> oh
<chmj> does it on all packages, not lsb-base alone 
<JaneW> ogra: ping
<JaneW> pogra: I need a line or 2 of descriptions for your edubuntu summit talk topics asap please.
<JaneW> ogra (even): I need a line or 2 of descriptions for your edubuntu summit talk topics asap please.
<ogra_> JaneW, will do...
<JaneW> ogra: Technical Track: Deployment Architecture & Technical Track: Menu Structure
<JaneW> I MUST send it out today
<ogra_> JaneW, ok
<Zomb> which version of d-i was used for Hoary?
<Zomb> I found few bugs there...
<Zomb> is there any preview of the Breezy installer available, anywhere?
<madduck> Kamion: please come to #debian-devel for a second.
<tseng> Zomb: you'll want to catch Kamion 
<madduck> Kamion: unping. sorry.
<pitti> Hi madduck 
* madduck ecstatically waves to pitti 
* pitti feels overwhelmed and waves back
<madduck> lol
<madduck> i am just high on coffee, that's all.
<mvo> hey madduck! how was linuxtag?
<fabbione> carlos: ping?
<carlos> fabbione, pong
<fabbione> carlos: did you test the new initrd script from the bug?
<fabbione> carlos: otherwise if you can reopen my account, i can create an initrd images for testing
<carlos> sorry, I didn't see the email notifications....
<carlos> sure
<carlos> fabbione, done
<fabbione> carlos: thanks
<carlos> about the PATA vs. SATA problem, will test it tonight to know if it still happens
<ogra> JaneW, legal issues ? 
<fabbione> carlos: ok
<ogra> JaneW, do you want me to write that too? or is it a typo in the spreadsheet ?
<JaneW> ogra: damn... you are too sharp - I was hoping you wouldn't notice ;)
<JaneW> ogra: who do you think should handle that - I was excited to hear that mdz will be there, so now we can give him tasks ;)
<ogra> JaneW, i can write a sentence or two for that, but i'm not sure if mdz or sabdfl will really mean what i write there
<Q-FUNK> re
<ogra> JaneW, yes, i'm excited about that oo :-D
<ogra> too even
<JaneW> ogra: I think leave that one, I'll ask mdz or sabdfl to give me a line or so..
<Q-FUNK> Kamion: allright.  any ETA on fixing it? :)
<ogra> oki
<fabbione> carlos: you should be ok to upgrade the kernel later this evening or tomorrow.. the new initrd script will take care of the megaraid stuff (thanks to jbailey )
<Q-FUNK> Kamion: alternately, can I join in on the package's maintenance and help close at least a fe of those bugs?
<pitti> Kamion: FYI, the coreutils LC_TIME symlinks are utterly useless; I notified the Debian maintainer and asked for removing them. If that lasts too long, we can also do it only in Ubuntu of course
<carlos> fabbione, do we have it in breezy already?
<carlos> fabbione, or will it work because you installed a modified version in my computer?
<fabbione> carlos: it will work from later today
<fabbione> in approx 6 hours
<fabbione> i tested on your box...
<fabbione> carlos: and btw.. you can remove my account 100%
<carlos> ok
<carlos> fabbione, thank you 
<fabbione> no thanks to you!
<fabbione> it's nice once in a while to be able to debug stuff on the machines :P
<carlos> :-)
<fabbione> Kamion: kernel + linux-meta on the way in 10 minutes
<fabbione> Kamion: it might be a good idea to preseed them due to the abi change
<fabbione> (and they will need NEW love)
<TheMuso> .cl
<ogra> JaneW, erm, and the sentence you have for "Menu Structure" is just fine, leave it like it is :)
<JaneW> ogra: cool thanks
<ogra> JaneW, Deployment: "What can we inherit directly from ubuntu, what do we do additionally"
<\sh> mdz: ping
<HiddenWolf> fabbione, do I have to build a custom kernel to support lirc?
<ogra> \sh, LA time -> 5:49am
<\sh> ogra: doesn't matter...at least his client is blinking ;)
<ogra> heh, true
<Kamion> chmj: no, doesn't do it on all packages, just those that were packaged native-style with non-native version numbers; I think Keybuk's going to fix dpkg-source
<ogra> \sh, did you already start with powermanagement stuff ?
<\sh> well i need asap a clean machine...for testing hoary to breezy updates
<Keybuk> yes, I just need to talk to you about a small detail before I do ;)
<\sh> ogra: no...i was waiting for u
<Kamion> Zomb: it's hard to state a single version for d-i ... today's daily build of breezy should be usable for testing
<Kamion> Q-FUNK: you'd need to talk to aj about that, preferably; I think he maintains debootstrap in darcs
<ogra> \sh, your architecture will be different, so you could start right away...
<Kamion> Q-FUNK: debootstrap is in an unstable phase at the moment, lots of new features but a fair few new bugs :)
<Kamion> pitti: ok, thanks
<\sh> ogra: k...
<Keybuk> Kamion: just gonna grab a coffee then /msg ;)
<ogra> \sh, probably interesting stuff: https://lists.sourceforge.net/lists/listinfo/gnome-power-devel
<Kamion> fabbione: ok, I'll get working on those
<ogra> \sh, and http://gnome-power.sourceforge.net/index.php ... for details, feel free t bug me
<ogra> to even
<JaneW> ogra: ok, thanks
<fabbione> HiddenWolf: not that i know off
<fabbione> Kamion: the kernel is up.. i only miss linux-meta atm
<\sh> ogra: which kernel 2.6.12?
<ogra> \sh, yep
<fabbione> Kamion: readding the skge was a pain :P
<ogra> \sh, but the kernel is not the intresting point for us, hal is... and all te acpi patches hughsie has introduced are there already
<\sh> ogra: k..what about special libs for python and hal?
<ogra> \sh, so you can request all kind of stuff from hal
<ogra> \sh, gnome-power is c
<Kamion> fabbione: I'd have put orinoco and hermes in nic-shared-modules, myself
<fabbione> Kamion: i didn't get around to clean nic-* and scsi-* yet
<Q-FUNK> Kamion: allright then.  I'll ask him.  thanks
* fabbione needs to remember how to do substvar
<chmj> Kamion: is there a workaround ?
<\sh> JaneW: hi btw :) 
<ogra> \sh, there is python2.4-dbus and the hal page has some examples http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD
<\sh> ogra: u r my man :)
<ogra> \sh, dbus-monitor is also a very interesting tool... but sems broken currently
<Lathiat> yeh i think it is
<JaneW> hi \sh
<Kamion> chmj: to unpack, use tar xzvf foo_bar.tar.gz; chmod +x foo-bar/debian/rules
<Kamion> chmj: when creating a new version, use a proper version number
<Kamion> chmj: but if you're tweaking an existing package in the archive, best just leave it for now
<chmj> Kamion: willl leave is for now then
<chmj> Kamion: i will leave it for now 
<chmj> damn I can't type 
<doko> pitti: I want to split java-gcj-compat in java-gcj-compat and java-gcj-compat-dev. what's the best time that the -dev package lands in main with a very short delay?
<pitti> doko: that would be a time when elmo is available to NEW and promote it
<pitti> doko: this doesn't require seed changes as it looks, right?
<seb128> pitti: is libmpcdec somewhere on your list for this week?
<Lathiat> wow 
<Lathiat> 'host' is broken, it prints out '<name> is an alias' 3 times over for each one, hrm
<doko> pitti: no
<cogumbreiro> lo all
<cogumbreiro> i would like to get CC'ed of every bug reports of the package "serpentine" is this possible?
<ogra> cogumbreiro, i'll do :)
<pitti> seb128: yes, it is
<ogra> cogumbreiro, thanks for the offer
<wasabi> Heh. STill not in the main keyring.
<cogumbreiro> ogra: do you know who is packaging it?
<ogra> cogumbreiro, seb128, but i care for the bugs
<seb128> cogumbreiro: are you upstream for it ?
<ogra> seb128, yep
<cogumbreiro> seb128: "upstream"?
<seb128> you should be set as QA for the package so
<ogra> seb128, can you do that ?
<seb128> sure
<ogra> when pitti filed the bug, serpentine wasnt in main
<seb128> cogumbreiro: upstream == who makes the applications
<cogumbreiro> seb128: then yes :)
<seb128> cogumbreiro: do you have a bugzilla.ubuntu.com account?
<cogumbreiro> yes
<cogumbreiro> cogumbreiro@users.sf.net
<ogra> cogumbreiro, its a wondeful piece of softeare, i really like it :)
<seb128> give me the email, I'll set you as QA for the package
<seb128> thanks
<cogumbreiro> i just found out tonight that serpentine was packaged on breezy, thx guys
<mvo> ping do
<mvo> ping doko 
<seb128> cogumbreiro: hum, communication issue, we should have mailed you to say it ... 
<cogumbreiro> one thing though, python-gnome2-extras has a broken module, "nautilusburn", which i am also the maintainer
<ogra> cogumbreiro, i would have had to contact you anyway before breezy release
<seb128> cogumbreiro: it's planned to be the default audio cd software for the current version
<cogumbreiro> those are great news :)
<seb128> cogumbreiro: what is broken with it ?
<cogumbreiro> seb128: https://developer.berlios.de/bugs/?func=detailbug&bug_id=4356&group_id=3081
<seb128> cogumbreiro: you don't use bugzilla.gnome.org ?
<cogumbreiro> seb128: no :|
<seb128> you should
<bddebian> Hello
<cogumbreiro> seb128: where should i ask for one?
<seb128> gnome-python has it bugzilla on bugzilla.gnome.org
<cogumbreiro> seb128: yeah, i know
<seb128> cogumbreiro: speaking about nautilus bindings or serpentine?
<cogumbreiro> seb128: nautilus-cd-burner bindings
<doko> ping m
<doko> ping mv
<doko> ping mvo
<bob2___> thom: laptop-detect has no vcs either, right?
<Keybuk> hmm...  doko's been running Perl scripts over the archive again
<cogumbreiro> also, i0ve just found some unmet dependencies in some gnome-python-extras2 and python-gtk2-dev
<seb128> cogumbreiro: try on #bugs @ irc.gnome.org, ask for a gnome-python-extras component for it
<seb128> oh? which ones?
<lu|sleep> better to email bugmaster@gnome.org
<thom> bob2___: in baz
<cogumbreiro> g-p-e should depend on python-gtk2-dev and python-gnome2-dev
<bob2___> thom: is there somewhere where  Icould find tarballs of it?
<cogumbreiro> python-gtk2-dev should depend on: libglib2.0-dev libgtk2.0-dev python-dev
<fabbione> Kamion: linux-meta uploaded
<fabbione> Kamion: we only need the kernel to build, move to main and d-i
<fabbione> Kamion: from now on there is nothing i can do...
<thom> bob2___: only the ones in ubuntu
<seb128> cogumbreiro: bugzilla.ubuntu.com knows about serpentine now and you are the QA so you will get mails about bugs
<cogumbreiro> seb128: cool, thx :)
<bob2___> thom: only released ones, then, I gues...unless the morgue is public?
<cogumbreiro> seb128: which modules are installed by default in g-p-e? under ubuntu?
<seb128> cogumbreiro: thanks for noticing the packages bug, I'll fix them
<seb128> cogumbreiro: every upstream ones
<seb128> hum, maybe not gdl because we don't have the lib to build it atm
<Kamion> fabbione: seeds changed over
<cogumbreiro> seb128: do you want me to bug report these? i'm creating a list with them and it will only finish once i am able to successfully compile them
<seb128> cogumbreiro: list of what?
<cogumbreiro> seb128: missing dependencies
<seb128> what do you try to build to notice that?
<seb128> the package build correctly ...
<cogumbreiro> seb128: i have a fresh system, with almost no -dev packages installed
<cogumbreiro> seb128: because of those broken deps i can't install g-p-e from source
<ogra> cogumbreiro, a ubuntu system ?
<ogra> cogumbreiro, did you run apt-get build-dep for the package you want to build ?
<seb128> cogumbreiro: k, right
<ogra> it should resolve cleanly
<cogumbreiro> ogra: breezy, no
<retrix> hi all, wondering if theres any google summer of code participants or mentors in here?
<pitti> retrix: yes, should
<bddebian> Summer of Code?
<cogumbreiro> ogra: ok, the deps are getting fetched
<mdke> bddebian, see the Ubuntu homepage
<cogumbreiro> ogra: i thought a apt-get install would suffice
<ogra> cogumbreiro, even better is to use a pbuilder, it tells you about all missing dependencys
<seb128> that's not a build-dep issue
<cogumbreiro> pbuilder?
<ogra> cogumbreiro, https://wiki.ubuntu.com/PbuilderHowto
<seb128> that's a Depends issue, and a part of it has been fixed for Debian, I'll fix that for Ubuntu soon
<seb128> don't bother with a pbuilder
<retrix> pitti: what do you mean?
<seb128> you can put a bug though, so that's listed to do
<pitti> retrix: I saw some participants here, and some of the developers in here are mentors
<bddebian> mdke: I don't see it?
<cogumbreiro> seb128: me?
<seb128> yep
<seb128> I'll fix that, but with a bug that's listed on bugzilla
<retrix> pitti: ah k thanks
<retrix> apparently ive been assigned to oliver grawert ... is he around in here?
<mdke> bddebian, ok yeah it has been removed, try google for "summer of code"
<mdke> retrix, he is called ogra
<ogra> retrix, heya, welcome :)
<retrix> thanks mdke
<retrix> hi there ogra
<bddebian> That is very cool
* bddebian wishes he wasn't such an old fart and could be a student :-)
<ogra> bddebian, if you'd hurry up with your MOTUness, you could be in my position ;) and at least work with the cool students ;)
<ogra> *hint*
<bddebian> ogra: I have been trying.  I don't know what to work on
<bddebian> ogra: I was looking at the Cxx transition list just last night and it seems that they are already all patched at Debian!?
<ogra> bddebian, UniverseCandidates ?
<seb128> speaking about motu, a guy mailed about anjuta2 packages on the list today
<ogra> seb128, i saw it, i'll answer
<seb128> you guys should try to contact him to get that packaged for ubuntu
<seb128> that's asked by GNOME people
<ogra> yep
<bddebian> ogra: Hmm, how did I miss that page??  Eeks
<cogumbreiro> seb128: it says there's no python-gnome2-extras ...
<jordi> pitti: ping
<seb128> cogumbreiro: put one common bug for both package on python-gnome2
<seb128> thanks
<cogumbreiro> seb128: ok, i'll post it under python-gnome2
<bddebian> Oh oh, I wanna do XPde :-)
<pitti> hey jordi
<jordi> pitti: I did a pg_dump and now try to restore it
<jordi> jordi@pusa:~$ pg_restore -U triatlo -C bd-triatlo-20050627.4.5.0
<jordi> pg_restore: [archiver]  input file does not appear to be a valid archive
<jordi> why am I getting this?
<Mithrandir> jordi: try psql databasename < $file ?
<pitti> jordi: yes, as Mithrandir says
<jordi> not yet
<jordi> I was going to cat |psql though :)
<Mithrandir> jordi: well, that's the same except you're showing your love of cats.
<jordi> I love them
<jordi> I someties do cat |less
<cogumbreiro> seb128: done https://bugzilla.ubuntu.com/show_bug.cgi?id=12221+
<cogumbreiro> (ignore the +)
<jordi> ERROR:  permission denied to set session authorization
<jordi> ERROR:  must be owner of schema public
<jordi> is this bad?
<pitti> jordi: did you use pg_dump or pg_dump all (as postgres)?
<pitti> pg_dumpall, even
<seb128> cogumbreiro: thanks
<jordi> pg_dump
<pitti> hm, that should work fine
<pitti> pg_dump mydb | psql mydb.new should copy a db
<pitti> jordi: can you please file a debian bug or just mail me the exact commands you issued?
<jordi> yes
<pitti> jordi: together with "psql -l" output
<jordi> it could be that the perms in this database are a bit fucked.
<jordi> address?
<jordi> got it
<pitti> jordi: martin@piware.de
<pitti> jordi: could be
<jordi> pitti: I did createdb -O triatlo triatlo 
<jordi> might that -O be a problem?
<pitti> looks fine
<jordi> k
<chrissturm> guys, i have a problem getting pbuilder running. i followed this howto: https://wiki.ubuntu.com/PbuilderHowto, but always used breezy instead of hoary
<chrissturm> and i got this: I: Configuring dpkg-dev...
<chrissturm> W: Failure while configuring base packages.  This will be attempted 5 times.
<pitti> jordi: ah, the old and new db have different owners?
<ogra> chrissturm, you have to set up a hoary chroot first, then update (as described in the howto)
<jordi> pitti: could be, because the owners in the db were a bit fucked up
<jordi> pitti: sent
<pitti> jordi: if you think that should work in general, feel free to write a bug
<chrissturm> ahhh. ok
<pitti> jordi: if that is a rather special problem, you can always edit the dump :-)
<jordi> pitti: I actually don't know. I would suispect PEBKAC quite easily :)
<Kamion> fabbione: d-i upload ready, I'll wait for the kernels actually to be there
<fabbione> Kamion: uhuhu cool
<fabbione> it will build..
<fabbione> i did test on all 4 arches..
<pitti> jordi: if you change the owner, I'd try with "pd_dump -O yourolddb | psql newdb"
<ogra> Kamion, does that mean w get a Colony this weekend ? 
<ogra> we even
<fabbione> Kamion: i am going off for the day.. as usual i have my mobil phone with me
<fabbione> Kamion: call/sms me if needed
<jordi> pitti: the owner should always be "triatlo", but I think a few tables were a bit fucked up
<jordi> pitti: for example, some look like this:
<jordi>  public | watchdog_wid_seq              | {triatlo=a*r*w*d*R*x*t*/triatlo}
<jordi> others:
<jordi>  public | watchdog                      | {triatlo=a*r*w*d*R*x*t*/triatlo,jordi=a*r*w*d*R*x*t*/triatlo}
<jordi> but I can't tell if this is bad
<jordi>  public | vocabulary_node_types         |
<jordi> others haqve nothing in the privileges field
<pitti> jordi: just to get a clear idea, did you issue all the commands as normal user or as "postgres"?
<jordi> as my own ser
<jordi> user 
<pitti> ok
<jordi> but in the past, who knows. Probably as postgres too
<jordi> this is an old db
<jordi> It'd be cool to fixup the mess
<pitti> jordi: do you have half an hour? then I could finish the thing I'm currently workign on
<jordi> I know I modified stuff as the psql user "jordi" too in the past.
<jordi> pitti: sure, I can cycle home while you're at it
<jordi> pitti: ttyl
<pitti> cu
<jordi> and thanks
<Kamion> ogra: if I can get it out the door today I will - we'll see
<ogra> wow :-D
<Kamion> fabbione: ok, thanks
<Kamion> almost forgotten how to do them, it's been so long :P
<JaneW> is there a tech board tonight?
<Kamion> JaneW: 20:00 UTC
<JaneW> Kamion: thanks... I'll try to be there (but I can't promise...)
<Kamion> JaneW: likewise ;)
<JaneW> :)
<JaneW> bye
<bob2___> so, how do I use an IPP printer to print a pdf?
<Mithrandir> bob2___: I use lp -d $printer file.pdf
<Mithrandir> which works if you've set up CUPS for $printer
<pitti> bob2___: print it in evince? or lpr? or lp?
<pitti> bob2___: do you see the IPP printer?
<bob2___> $printer is a windows machine
<pitti> hm, is that really IPP then?
<Mithrandir> bob2___: so?  Just add it using gnome-cups-admin.
<bob2___> I gather so
<pitti> bob2___: if you enable "Detect LAN printers" in gnome-cups-manager, IPP printers should appear automagically
<pitti> not SMB printers, of course
<bob2___> ah, it's a cups print server, it seems
<bob2___> ah, and it works
<bob2___> thanks folks
<pitti> bob2___: enabling the LAN browse option helped?
<sladen> daniels: your RSS feed has eaten the wiki
<mdz> \sh: pong
<\sh> mdz: regarding https://bugzilla.ubuntu.com/show_bug.cgi?id=11907 
<mvo> good morning mdz 
<\sh> mdz: i can't give u the old interfaces anymore, but I changed it on hoary, and after breezy dist-upgrade there was the default interfaces file back...with hotplug stuff inside
<ogra> hey mdz, goals updated :)
<mdz> ogra: thanks
<pitti> mvo: right now it should be afternoon for him as well :-)
<mvo> pitti: oh, he is already in london?
<ogra> pitti, oh, its 01 already ?
<pitti> oh, right
<ogra> ah, i just thought i missed the plane, phew *g*
<jordi> pitti: I'm back.
<pitti> jordi: I /msg you
<jordi> Does anyone know if Claire has a PGP key she uses?
<jordi> pitti: ok
<mdz> pitti: hmm, I should have mentioned in the email to announce the changed meeting time :-)
<jordi> or, does Claire IRC?
<pitti> mdz: so we do have the meeting at 1700? 
<pitti> mdz: if so, we should change the topic in #u-m
<Kamion> oh
<Kamion> I can't make 1700 at all, I have a prior engagement. oh well
<cvd> jordi: ping
<jordi> ah, the magic of IRC
<jordi> cvd: pong :)
<mdz> Kamion: sorry about that, I had an engagement myself that I forgot about
<ogra> whoops
<mdz> pitti: would you update the topic and send a note to the mailing list?
<Kamion> mdz: well, you're a TB member and I'm not, so you win ;)
<pitti> mdz: I'd like to have Kamion's opinion about the langpacks, too, but I just ask him beforehand
<pitti> mdz: I do that, yes
* mvo may not make 17:00UTC as well :(
<mdz> pitti: well, we could always discuss this on the mailing list.  is there a reason it has to go before the tech board?
<pitti> mdz: the main reason is that it's easier to get an opinion from the key folks in TB meeting than on the ML
<pitti> mdz: and the decision has a pretty big impact
<pitti> mdz: however, nothing that intrinsically requires TB, I just need a decision and a consensus
<pitti> mdz: see #u-m, there seem to be many people who can't attend at 17000
<pitti> s/0$//
<pitti> Kamion: if you have a minute, could you please write a short comment about the "Preparing tomorrow's language pack TB topic" mail?
<Kamion> pitti: I thought we talked about this before
<pitti> Kamion: did we?
* pitti can't remember
<pitti> Kamion: I only remember talking about not splitting -support and instead installing kde-i18n-foo in d-i
<Kamion> ok, give me a minute to clear up the other thing I'm talking about at the moment
<pitti> sure, it's not that urgent
<Riddell> I can make any time
<Riddell> mdz: do I still need to fix seeds repository permissions?
<pitti> mdz: mail sent
* tseng looks up 1700 in UTC
<pitti> tseng: in 90 minutes
<tseng> est rather
<tseng> in 90 minutes i think ill just be getting back from lunch
<tseng> i only need to be there for the first bit
<tseng> (maintainer candidates)
<tseng> ill try.
<mdz> Riddell: I mv'd ++revision-lock out of the way and created a new one by hand, seemed to work
<mdz> Riddell: but it would seem to imply that your umask is still masking off group writability
<Kamion> Riddell: put 'umask 002' at the top of ~/.bashrc (above the PS1 check)
<daniels> sladen: yes, I know
<Riddell> seems like a bug if baz doesn't work right with the default ubuntu umask (0022 here)
<Kamion> pitti: anything in particular you want from me?
<Kamion> Riddell: "bug in baz" shocker. :-)
<Kamion> Riddell: (but it's a bit tricky to fix properly apparently - I remember having a long discussion with lifeless about sftp ages ago)
<pitti> Kamion: I just like to collect some opinions whether or not the current udu spec is sane
<Kamion> pitti: basically any of those options is possible to implement in the installer
<pitti> Kamion: adding 400 more packages is much overhead and will cause elmo pains (and pains in the upgrading, too)
<Kamion> pitti: so the concerns ought to be (a) archive maintenance (b) upgrades
<pitti> right
<Kamion> pitti: and I think I agree that having both KDE and GNOME translations in aggregated langpacks won't work
<Kamion> we're running pretty short on space as it is
<Kamion> pitti: you might also like to consider a variant of option (3): language-pack-xx for GNOME, language-pack-kde-xx for KDE
<Kamion> pitti: it's asymmetrical I know, but it would help with upgrade issues
<wasabi_> I assume you all have elmo locked in a closet?
<pitti> Kamion: so KDE users would get Gnome translations, too?
<Kamion> pitti: it would be possible to put the {other} category in both sets of langpacks
<Mithrandir> wasabi_: we call it "the data centre".
<Kamion> ?
<pitti> Kamion: that helps for the Ubuntu CDs, but not for the KDE cds
<Kamion> pitti: not if you put shared translations in both
<pitti> Kamion: ah, if they replace each other, that would be possible
<wasabi_> is there anybody else who can add my key to the main keyring?
<Kamion> pitti: however, that's really nasty :-)
<pitti> Kamion: but then they should rather be called -ubuntu and -kubuntu
<pitti> Kamion: if Kubuntu was a real derivative, that would not be an issue in the first place
<Kamion> pitti: perhaps that variant is best avoided, on further reflection
<Kamion> wasabi_: only elmo
<pitti> Kamion: but I didn't want to split packages per derivative
<Riddell> pitti: what do you mean by real derivative?
<Kamion> Riddell: different archive
<pitti> Riddell: with it's own archive, seeds, and so on
<Riddell> right
<pitti> Riddell: then langpack-o-matic can DTRT for the particular derivative
<Kamion> Riddell: i.e. so that you could have different language-pack-xx packages
<mvo> mdz: do you mind if I upload a new python-apt to unstable? 
<wasabi_> Okay then, so Elmo is locked in the data center... and he's the only one who can add keys.
<wasabi_> So what is the recourse? Just wait?
<Kamion> pitti: would the base/update separation still be needed for language-pack-xx with option (3)? presumably it would get a lot smaller
<mdz> mvo: certainly not
<pitti> Kamion: I think this is rather orthogonal
<Kamion> pitti: sure, but it would decrease the problem from 400 to 300 at least ...
<pitti> Kamion: the base/update split was originally intended for surviving with daily updates
<mvo> mdz: can I base it on python-apt--mvo--0? or would you rather like to see a more conservative approach (then I would just rebuild the version from experimental and upload a new version into experimental based on python-apt--mvo--0)
<pitti> Kamion: but since it was decived to update only once per month, we could actually drop it if that is an issue
<Kamion> pitti: if elmo's happy with that, so am I
<pitti> ok, fine; thanks for your input
<Kamion> P.S. would it be possible for apt uploads in the future to say *what* they changed, rather than just "merged from branch x"?
<Kamion> pretty please
<Kamion> I have no idea what features 0.6.38ubuntu1 introduced
<mdz> mvo: is --mvo-- the same as breezy?
<mdz> Kamion: they did
<mvo> mdz: that and a bit more (like support for the pkgProblemResolver) and improved native python interface
<mdz> Kamion: it's all in the changelog, exactly as with merging from Debian
<Kamion> mdz: oh, I see, it's in the older changelog entries but not in the .changes file, ok
<Kamion> -v :-)
<mdz> ah, yes, I should have used -
<mdz> -v
<mdz> I did remember to use -v for Debian
<mdz> which resulted in a fairly enormous .changes
<Kamion> mm, I can imagine
<mdz> hmm, no debbugs reports about the new apt yet, strange
<mdz> is debbugs working? :-P
<mvo> mdz: dburrows complained already :)
<mvo> (on deity)
<Kamion> yes :-)
<mdz> hmm, I just read deity and didn't see mail from him
<mdz> in fact I don't see anything since June 13th on deity
<Kamion>  225 Ns  Jun 28 Daniel Burrows  (  39) Unannounced library transitions CONSIDERED HARMFUL
<mdz> unread
<mdz> perhaps it hasn't reached me yet
<mvo> I posted some stuff to deity since 13 ... 
<mdz> yes, but I've probably read them already
<jordi> bad, bad mdz :)
<mdz> jordi: give me a break, it's unstable
<mdz> people forget what it was like before the freeze :-P
<Kamion> hmm, I had better make sure all the apt 0.6 stuff in d-i is merged
<mvo> jordi: everyone was screaming for apt-0.6, now they have it :)
<mdz> I pre-announced this months ago, that I would upload it after sarge released :-P
<mdz> so dburrows had plenty of advance notice
<Kamion> mvo: Debian are going to need the trust-cdrom stuff pretty soon, I'm betting
<jordi> mdz: hey, I'm happy with the upload.
<jordi> *very*
<jordi> mvo: yeah. But you, YOU: don't touch my strings.
<mdz> fortunately bubulle has helped get translators focused on 0.6
<mvo> Kamion: if it isn't merged already it's in mdz's queue (I can check now if you if it's urgent)
<mvo> jordi: I uploaded a whole bunch of new, fresh and shiny strings for you into rosetta. all of the ubuntu package descriptions
<mdz> mvo: oh, nice
<jordi> mvo: and I found out some utf-8 was fucked up in them!
<mvo> jordi: yes, a problem with the Packages file, it contains some invalid utf-8 and that confused my tools pretty badly
<jordi> mvo: yeah
<mvo> mdz: yes, we have a set of tools to import export package files and translations from/to rosetta. the result is compatible with apt--ddtp (that should *fingers-crossed* work pretty well)
<jordi> strangely enough, apt-cache show myspell-nb does show it ok
<jordi> does apt6 have the ddtp patch?
<mdz> mvo: but perhaps we should fix the terrible English descriptions before asking for them to be translated ;-)
<mdz> jordi: not yet
<jordi> mdz: yeah
<mvo> jordi: yes, I hope to fix that tomorrow and upload a new pot file (unfortunately rosetta does not allow me to upload anything right now, noone seems to know why)
<jordi> some descriptions are not so good :)
<mvo> mdz: you mean we should have a translation into Packages->english too :P
<mdz> l10n-en
<jordi> hah
<mvo> jordi: apt0.6 does not have it right now, but the baz branch for it is up-to-date and I fixed some bugs with otavio. I think it's in pretty good share, it needs more testing of course
<mvo> and the fronends needs patching, but that's easy (and I have patches somewhere for aptitude and synaptic)
<jordi> mvo: sweet
<mvo> arrrgg, s/share/shape/
* mvo curses his fingers
<jordi> I'm buying apt shares
<mvo> heh :)
<Kamion> 17:06 < waldi> apt needs to use the correct keyring first, cdebootstrap chokes with the new version because of uncheckable Release files
<Kamion> has that been reported?
<mdz> Kamion: not to me
<jordi> pitti: sent
<mdz> Kamion: does cdebootstrap run apt unconfigured or something?
<Kamion> mdz: entirely possible
<mdz> it copies the keyring into place in postinst
<mvo> Kamion: I just upgrade 5 minutes ago and I don't got the correct key. but that might be because my install is "interessting" because of the various test versions of apt that I had installed 
<fabbione> Kamion: amd64 is built.. i expect the others to follow pretty soon
<mdz> ogra: in the future, please put the date of the status update at the very beginning of the column (prefixed)
<ogra> oki
<fabbione> mdz: linux changed to linux-meta..
<fabbione> mdz: we only need to ge the kernel and all the other goodies in place
<fabbione> and i am offline again for the night
<fabbione> cya tomorrow
<mdz> fabbione: ok, thanks
<mvo> bye fabbione 
<pitti> ogra: I installed gnome-power, I don't have anything new in the menu
<ogra> pitti, hmm, gamin bug ? 
<pitti> ogra: so I just started gnome-power-preferences, which displays a dialog
<ogra> pitti, it should be in System->settings
<pitti> ogra: I can change something, but it isn't preserved when closing
<pitti> ah, there
<pitti> ogra: so that doesn't require any root stuff?
<ogra> pitti, gnome-power-manager must be added either to your session (or we add it to dbus like NM)
<pitti> I can't believe that
* pitti started g-p-manager
<ogra> pitti, it will need something in the backend, but thats not gnome-power itself... gnome-power only sets gconf keys currently.... pmi shoudl care about the rest
<ogra> pitti, look in gconf editor
<pitti> ogra: ah, so this just modifies gconf, no /etc files? easy then
<pitti> ogra: ah, and g-p-manager reads out gconf and talks to pmi over dbus/socket/whatever?
<ogra> the redhat way is to just call echo "disk" > /sys/power/state, we should have pmi here
<ogra> (look in gconf editor in the scripts section of gnome-power, i havent adjusted the default yet)
<pitti> ogra: you cant to that without root
<ogra> pitti, but please in pmi, not in the gui tool ;)
<daniels> ogra: dbus!
<ogra> pitti, the same way its solved in gnome-session
<pitti> ogra: alright
<ogra> daniels, this part of gnome-power isnt dbus
<pitti> thanks
<pitti> ogra: so what's the purpose of g-p-manager then?
<pitti> ogra: the manpage does not tell anything about it
<Lathiat> to be a frontend to a backend?
<ogra> pitti, also if you enable the main icon in the prefs and right click it, there are shutdown suspend etc options, this will disappear in the next release
<pitti> Lathiat: well, storage is done by gconf, and there is no dbus, so what's left?
<ogra> pitti, i'm waiting for the new release next week, there the apps will have options, worth writing a real manpage
<ogra> pitti, the purpose of gnome-power is to hibernate/shutdown your box if battery gets low etc... 
<pitti> ogra: that's obvious
<ogra> like all the options say
<Lathiat> pitti: wellfor example ,gnome-power-manager puts a battery for my laptop in the system tray...
<Lathiat> and does for UPS,mice, etc, apparently
<pitti> ogra: I mean, does pmi read the options over -manager? or directly from gconf=
<ogra> gnome-power calls the scripts currently
<pitti> Lathiat: ah, so it's an applet-ish thing?
<pitti> ok, that makes more sense
<ogra> pitti, eable the main icon in the second tab
<ogra> it putts the battery status in the tray
<pitti> ogra: it's on by default, but I don't get an icon
<ogra> and gives you acces to the options in the right click menu
<pitti> well, I don't have a battery for that matter
<Lathiat> pitti: are you ona laptop?
<Lathiat> right
<ogra> pitti, haha
<ogra> pitti, get a battery then ;)
<pitti> ogra: no wires to attach it to
<ogra> a wireless mouse would do ;)
<ogra> or keyboard or a UPS :)
<pitti> ogra: ok, I think I have an idea about -manager now, thanks
<Lathiat> or write a fake driver ;p
<ogra> pitti, oki
<Lathiat> maybe a life meter :)
<Lathiat> takes your DoB and estimated date of death :)
<ogra> Lathiat, pitti is the HAL maintainer, he could patch in a virtual battery there ;)
<Lathiat> would be as reliable as most laptop batteries :)
<ogra> heh
<pitti> Lathiat: to resemble a battery it shuold display the time until the next meal
<Lathiat> pitti: hm, that could work :)
<mvo> mdz: just FYI, I uploaded the version from experimental of python-apt for now (I'll update a new version later when I have a bit more time)
<mdz> mvo: ok
<mvo> (into debian/unstable that is)
<niran> speaking of python-apt, is there any documentation for it somewhere?
<mvo> niran: there is doc/examples 
<mvo> and irc :P
<mvo> it's really a weak point
<mvo> niran: what bits are you interessted in? 
<niran> mvo, ok, i'll poke around
<niran> i'm trying to search
<mvo> niran: in the package name? in the description? you may want to checkout the python-apt--mvo--0 branch. it contains a filteredcache object that can be used as a search interface (depending on your needs of course)
<mvo> niran: oh, you are the GSoC FindingPackages person :)
<niran> mvo, yeah :)
<niran> mvo, i'm trying to make this search box actually do something: http://niran.org/gai.png
<niran> mvo, both the name and description
<mvo> niran: can we talk about the FindingPackages stuff in a bit (e.g. ~20:00UTC)? I'm your "mentor" and I'm happy to help 
<niran> mvo, sure
* mvo checks
<mvo> niran: your screenshot looks sexy!
<niran> mvo, that's what i'm aiming for :)
<niran> i never knew that gnome-panel-screenshot added in drop shadows... if only those actually existed when running the program
<mvo> niran: let's make it 20:00UTC and we can see how much we can get out of python-apt
<mvo> :)
<niran> mvo, sounds good
<\sh> mvo: something against one more? ,-)
<mvo> \sh: you are welcome too of course :)
<mdz> technical board meeting in 10 minutes on #ubuntu-meeting
<mdke> meeting time has changed?
<pitti> yes, TB meeting in 8 minutes
* mode/#ubuntu-devel [+o thom]  by ChanServ
* mode/#ubuntu-devel [-b CarlFK!*@*]  by thom
<mdz> Keybuk, sabdfl-afk #ubuntu-meeting
* ^rob^ goes into planet.gnome.org withdraw
<Kamion> infinity: how far along is the linux-source-2.6.12 i386 build?
* Kamion needs to schedule his evening around it
<elmo> judging by nagios, it's finished
<elmo> only weddell is left yellow-lining
<elmo> (ia64)
<thom> elmo's hi-tech monitoring solutions, inc
<daniels> he is, after all, the human nagios
* mode/#ubuntu-devel [-o thom]  by thom
<elmo> well I haven't figured out a "ignore-fabbione-proving-he's-the-man" plugin for nagios' monitoring of the buildds yet :-P
<Treenaks> elmo: install this for him: http://www.hadess.net/files/stuff/vpenis.c
<Mithrandir> elmo: just hack the load plugin to ignore fabio's processes? :-)
<Kamion> elmo: ah, yes, I see it uploaded now
<CarlFK> according to https://wiki.ubuntu.com/LAMPForHoary universe is needed to build a LAMP box - is this true?
<Nafallo> CarlFK: yes
<CarlFK> thanks - im supprised, but such is life. universe it is
<chrissturm> carlfk: why dont you ask in #ubuntu?
<Nafallo> CarlFK: I use LAPP ;-) postgresql instead of mysql. that's in main :-).
<CarlFK> chrissturm - I did
<thom> i don't see which bits of linux, apache, mysql and php4 aren't in main
<chrissturm> they are all in main
<CarlFK> php4-mysql
<Lathiat> yeh php4-mysql
<thom> ah
<thom> sucks to be php4
<Lathiat> be ncie if that was rectified
<Lathiat> why is it not in main?
<Amaranth> weren't they some license issues with php and mysql?
<Lathiat> there are?
<Lathiat> it has to be one of the most popular things to use on linux
<Lathiat> i wouldnt have thought
<Amaranth> Lathiat: MySQL is GPL and PHP isn't
<Amaranth> or something like that
<Amaranth> i know php.net stopped shipping php4 with mysql
<CarlFK> Amaranth - but both of those are in main, just not the glue
<chrissturm> how do i propose something thats in universe for main? i would really love to have ruby in main
<Amaranth> with the mysql extension, rather
<Amaranth> CarlFK: Just because they are in main doesn't mean you can use them together.
<CarlFK> Amaranth - because of licencing?
<Amaranth> yeah
<Amaranth> MySQL is GPL, PHP is PHP License
<Amaranth> i think they got it all sorted out for php5, but php4 didn't ship with the mysql extension
<chrissturm> amaranth: if it has licensing problems, why is it in universe and not in multiverse?
<CarlFK> oh yeah, the umbrella effect...
<Amaranth> chrissturm: Either it was resolved or someone forgot.
<Lathiat> well, these kind of problems isnt raeally a multiverse problem
<Lathiat> its more a "this shouldnt exist" kinda problem
<Lathiat> aiui
<Amaranth> debian-legal probably has something about it in the archives
<Lathiat> haha
<Lathiat> wrong channel
<Amaranth> ?
<Amaranth> no, i know where i am :P
<Amaranth> i'm saying read d-l to see what they decided
<Amaranth> really php4-mysql is either completely legal or shouldn't be there at all, so i have a feeling they figured something out
<Lathiat> Amaranth: no ;p
<Lathiat> i mean that 'haha' was in the wrong channel ;p
<Amaranth> oh
<CarlFK> should I buzilla the "php4-mysql is either completely legal or..." issue?
<tseng> php4-universe isnt about legality
<tseng> its about supportability
<tseng> that said mysql in there is supposedly a mistake
<CarlFK> mysql and php4 are in main, php4-mysql is in universe
<Amaranth> oh, php4-mysql is legal
<Amaranth> they added an exception for Free licenses
<Mitario> hello everyone
<Amaranth> so yeah, put that sucker in main :)
<CarlFK> woo!  4 of kind!  https://bugzilla.ubuntu.com/show_bug.cgi?id=12222
<elmo> Kamion: do you need this stuff in main?
<elmo> or are you already dealing with that?
<Amaranth> CarlFK: I'll be with you in a couple hours, when bugzilla finishes loading
<Amaranth> malone may look like crap but at least it loads fast :/
<Amaranth> CarlFK: ack, don't quote me in the bug! i don't know what i'm talking about
<CarlFK> no hurries - this is just one of a few test runs...
<CarlFK> lol
<CarlFK> but you spoke with shuch conviction
<CarlFK> I would hope there is a bit more checks and balances than "someone in IRC said it was OK"
<Kamion> elmo: which stuff?
<elmo> Kamion: new 2.6.12
<Kamion> elmo: er, yes :-)
<carstenh> pitti: hi, i just read that you are my new mentor :)
<pitti> Hey carstenh, right
<Kamion> elmo: are debian-installer's dep-waits going to auto-clear?
<elmo> Kamion: should do, I'm just teri-ing + anastacia-ing now
<elmo> I REALLY need to rip that second CPU out of jackass
<Lathiat> elmo: whys that?
<elmo> it's made cron.daily about 5x slower
<maswan> up/smp issue? booting an smp kernel might be quicker than opening the box?
<elmo> maswan: heh, good point
<elmo> clearly I need MORE CAFFIENE
<maswan> elmo: we have (had) a few two-way fileservers booting up kernels due to performance
<elmo> maswan: something in apt-ftparchive on this box does NOT like SMP - it's weird
<maswan> hmm.. since I suggested booting an smp kernel when I meant a non-smp kernel. :)
* maswan probably needs something too
<maswan> elmo: Weird. Btw, the disk issue is finally moving. So soon<tm> we can setup some more mirroring. :)
<elmo> yay
<Lathiat> maswan: ooh whats happening?
<maswan> Lathiat: a cdimage mirror too over here, not just release+archive. :)
<Lathiat> maswan: i meant disk wise
<Lathiat> like whatching getting :)
<maswan> Lathiat: some more in the ftp.acc.umu.se cluster. :)
<Lathiat> heh, DONT YOU HAVE ENOUGH ALREADY ? :)
<maswan> Lathiat: of course not, if we had enough, we would have mirrored cdimage earlier. ;)
<Lathiat> maswan: whats the brand of that fiberstuf you use
<Lathiat> miranet or something
<elmo> upload.ubuntu.com is going down for a reboot
<maswan> Lathiat: at work, we use myrinet and dolphinics sci as interconnect in the two computaitonal clusters. myrinet is the fiber stuff.
<maswan> Lathiat: at the computer club the SP switch is copper, not fiber. :)
<Lathiat> maswan: yeh i think i more meant that opteron cluster you were talkign about
<maswan> Lathiat: ah, the opteron cluster uses myrinet
<Lathiat> right
<Lathiat> thansk
<Lathiat> knewit was something like that
<elmo> whee, glad I didn't try THAT from Leeds
<mdz> kamion: I totally don't see that mail from dburrows
<mdz> and I've received subsequent mail on deity
<mdz> mizar:[~/src/deb/mine/arch/apt/ubuntu]  grep -i harmful ~/mail/procmail.log*
<mdz> zsh: exit 1     grep -i harmful ~/mail/procmail.log*
<elmo> okay, so #2650 is alive and well and still as deadly as ever
<elmo> Mid-air collision detected!
* elmo scowls at mdz
<mdz> haha
<Lathiat> elmo: that, leeds ?
<elmo> Lathiat: rebooting a machine 200 miles away that subsequently didn't come back
<Lathiat> elmo: ah, thought so
<ogra> mdz, did you want me to merge ffmpeg in hoary for #10534 ? (i havent any data to test it yet, but after days of work and a lot o fiddling it compiles clean on all arches at least)
<mxpxpod> I'm trying to upgrade to breezy and I get a bunch of conflicts
<mxpxpod> and I can't seem to fix it by doing apt-get -f install
<CarlFK> mxpxpod - did you want your box fixed, or help posting bug reports?
<mxpxpod> CarlFK: I can do bug reports... but I'd like my box fixed ;)
<JanC> pitti : during the meeting you said: "... not that OO.o wouldn't be scary on any but the latest and greatest number crunching hardware"
<JanC> I use OOo 1.x on a P3 @ 666MHz (Win2k & breezy) & on a K6-2 @ 500 MHz without problems (it's just slow to start up)
<tseng> JanC, eh, michael meeks is hacking hard on it
<mdz> can someone translate from baz into english?
<mdz>   CHECKSUM FILE(S) DISAGREE WITH
<mdz>   DIRECTORY LISTING ABOUT WHAT
<mdz>   FILES SHOULD BE PRESENT IN
<mdz>   REVISION DIR OF ARCHIVE
<JanC> tseng : I have no complaints, pitti seems to have  :)
<Lathiat> "You broke it" -- baz
<ogra> why does baz shout at you ?
<ogra> looks angry
<Lathiat> we're all so helpful
<pitti> JanC: OO.o 1 is still bearable, although it already sucks compared to gnumeric and vim
<pitti> JanC: but OO.o 2 is unbearable on my iBook G4
<mdz> hmm, apparently that translates to "there was a full tree tarball in the patch-11 dir and I didn't expect there to be one"
<mdz> moving it out of the way fixes things
<mdz> of course, baz itself put it there
<lamont__> mdz: one possiblility is that your keyring lacks a key you need to verify things
<ogra> mdz, lol
<Lathiat> pitti: gnumeric+abiword is like 10 billion times faster
<Lathiat> pitti: abiword will load in 1 secondon my altpop where as openoffice takes 8
<lamont__> mdz: another is that there is cruft.  tagging something twice has broken things for me in the past
<Lathiat> pitti: the 5400rpm doesnthelp
<pitti> Lathiat: no need to convince me :-)
<pitti> Lathiat: I'm a LaTeX dude
<JanC> 15 seconds to start OOo2 Writer on my P3 @ 666 MHz
<JanC> that's not unbearable...
<mxpxpod> CarlFK: so, any help getting my box to a useable state?
<KaiL> JanC: from ramdisk? ;)
<JanC> no, a Seagate Barracuda that's 5 years old
<JanC> 7200rpm I think
<CarlFK> mxpxpod - doubt it - once I am to that point, I post whatever seems usefull and then start over
<JanC> in fact, OOo1 writer is slower to start up... 
<CarlFK> mxpxpod - did you try to upgrade a "working" box?
<mxpxpod> CarlFK: yup
<KaiL> JanC: strange, it's 20sec here (Sempron 3100+, Samsung SP1214N)
<Lathiat> yeh i found OO2 is no worse if not slightly better
<Lathiat> i guess thatmeans thatnew stuff is up to pace with performance improements
<Lathiat> heh
<Lathiat> oo.o2 still look sugly when integrated with gtk too
<tseng> the recent shots ive seen are not that bad
<Lathiat> lathiat->sleep();
<CarlFK> mxpxpod - um... post the bug reports and hope that the solutions help you?
<JanC> KaiL : I have 512 MiB RAM / 36% in use before I started OOo
<JanC> that might make a difference...
<JanC> Lathiat : OOo2 is ugly, yes, but it's ugly on Windows too  :-(
<KaiL> also 512MiB here - maybe it's the KDE-Integration
<JanC> ah, Ubuntu here, no Kubuntu  :)
<mxpxpod> CarlFK: got it.. I found a bug report with a workaround that fit my problem
<CarlFK> mxpxpod - luck you -make a backup quick ;)
<JanC> anyway, I just wanted to tell OOo isn't _that_ bad, even if Abiword is a lot faster
<KaiL> JanC: but Abiword doesn't have all the features
<JanC> KaiL : that's why I use OOo Writer  :)
<JanC> I regularly get Word & Excel files from members of a non-profit I work for  :-/
<pitti> JanC: gnumeric opens excel just fine :-)
<JanC> s/work/volunteer/
<JanC> pitti : most of the files are .doc
<ivoks> pitti: yeah, but where did non-profit get money for office? :)
<KaiL> I always wonder, why there are more non-profit the comercial companies with MS products
<ogra> ivoks, it was preinstalled ?
<JanC> ivoks : we have not much money, so I use OOo  :)
<ivoks> ogra: office? i don't think so...
<CarlFK> KaiL - thats why they arn't profitable 
<ivoks> JanC: heh, for me money is irrelevant when it comes to office - i use LaTeX :)
<JanC> this is customer group with clients from my ISP
<JanC> so most of them even don't know the difference between Word & Windows...
<ivoks> heh, most of them don't know that maximized and non-maximized word is the same app :)
<JanC> :)
* JanC continues reading the meeting log
<SEBest> JanC : where is this meeting log?
<JanC> on my hard disk & in my X-Chat window  :)
<tseng> meeting logs are announce to ubuntu-devel
<SEBest> can we download it somewhere?
<Burgundavia> SEBest, see the topic from #ubuntu-meeting
<SEBest> thx
<CarlFK> https://wiki.ubuntu.com/UserPreferences says "Please use Launchpad's forgotten password page instead." at the top and " If you forgot your password, provide your email address and click on Mail me my account data." in the middle.  is the top temporay?
<mdke> CarlFK, the top is right
<mdz> there ought to be a direct link
<mdke> yeah
<mdke> i put in a request
<mdke> mdz, you may find /wiki/FeatureRequests and /wiki/BugReports useful ;)
<mdz> mdke: does hno73 monitor those?
<mdke> mdz, yes he writes most of them, and is subscribed to the pages
<mdz> ah, good
<carstenh> sabdfl: hi, who will be the copyright-holder of code written for summer-of-code?
<JanC> the author, I guess ?
<HiddenWolf> JanC, or the organisation that pays the author, or the organisation that recieves the code, ubuntu. :P
<JanC> or both  :)
<CarlFK> at lest for mambo: "All of the code submitted must be contributed under the terms of the GPL license and is subject to the standard Mambo copyright terms"
<sabdfl> carstenh: the author, in general
<carstenh> sabdfl: ok, thanks
<CarlFK> carstenh - "You or your mentoring organization must license your code under a license palatable to your mentoring organization. Some organizations will require you to assign copyright to them, but many will allow you to retain copyright. If Google is your sponsoring organization, then you keep the copyright to your code." http://code.google.com/summfaq.html
<\sh> hmm...I hope the actual cvs head version of jabberd2 is much more stable then jabberd2-2.0s8
<\sh> stupid characterset problems
<carstenh> CarlFK: thanks, i already knew this :) i wanted to know how ubuntu handels this
<sabdfl> carstenh: if it's a project which currnelty requires copyright assignment, then that will still apply (Gnu, for example)
<sabdfl> GNU, sorry
<sabdfl> currently, even
<carstenh> sabdfl: ok, thanks. i don't think it requires copyright assignment. maybe i can use my project for university too, but that would probably require double licensing (GPL and "do what you want with it for educational stuff" for my university)
<carstenh> and if i would be the copyright-holder this wouldn't be a problem ;)
<ivoks> gpl is do what you want
<sabdfl> carstenh: should be fine
<carstenh> sure, but i don't know (and even they don't know) if they would like only gpl
<carstenh> ok, thanks for your time :)
<HiddenWolf> sabdfl, if I where ubuntu, I'd put some work into the bounties page that's linked to from the frontpage. It looks half-completed and uninviting, without status' etc
<HiddenWolf> just my 2cents
<sabdfl> HiddenWolf: which page exactly?
<HiddenWolf> sabdfl, can't find the link now, it was the list with bounty candicates for the summer of code, a yellow box on the frontpage linked to it... still browsing.
<Burgundavia> there is a page on the udu wiki
<pitti> seb128: here?
<Burgundavia> http://udu.wiki.ubuntu.com/GoogleSocApplications
<HiddenWolf> Burgundavia, no, it was on the main site, can't find it now, nm
<seb128> pitti: pong
<pitti> seb128: did the latest X broke my graphics driver and made it slooow, or is it a new feature of gdm that the screen builds up block-wise?
<sabdfl> HiddenWolf: this one? http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<seb128> pitti: I would blame xorg
<seb128> pitti: how new is that?
<JanC> HiddenWolf : or http://www.ubuntulinux.org/community/bounties  :)
<HiddenWolf> neither
<pitti> seb128: two or three days maybe
<pitti> seb128: all apps are fine, video playing works, too, it's just gdm
<HiddenWolf> sabdfl, can't seem to find it now, but it was a page on the main wiki, in the ubuntu style, not the udu-wiki bounty possibilities for google code applicants
<seb128> pitti: gdm is not slow here and 2.8.0.0 has been uploaded like 10 days ago ... I would blame xorg
<pitti> seb128: ok :-)
<JanC> http://udu.wiki.ubuntu.com/BreezyBounties
<JanC> that one is linked fro mthe google SoC site
<pitti> $ ldd  /usr/sbin/gdm|grep gtk
<pitti>         libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7c65000)
<pitti> ^ ah, GTK bug then...
<HiddenWolf> JanC, ah, yeah, sorry. :S
<seb128> pitti: I still have a xorg 6.8.2-2 weeks ago though
<HiddenWolf> sabdfl, ^^
<JanC> and this https://wiki.ubuntu.com//BountyProposals is linked from there
<seb128> pitti: ah ah :p
<JanC> lit seems like there are too many bounty sites  :)
<JanC> s/lit/it/
<sabdfl> HiddenWolf: https://wiki.ubuntu.com//BountyProposals ?
<sabdfl> that's totally community driven, i think
<HiddenWolf> sabdfl, http://udu.wiki.ubuntu.com/BreezyBounties
<HiddenWolf> I was mistaken, probably
<sabdfl> HiddenWolf: happens to me all the time too :-)
<sivang> seb128: hi seb, did you talk to jamesh?
<HiddenWolf> sabdfl, you probably have a better excuse ;)
<niran> sabdfl, the BountyProposals page isn't the accurate list of accepted proposals
<niran> sabdfl, I can wikify the spreadsheet that JaneW sent out if you want
<HiddenWolf> niran, is wikify a word? :P
<niran> HiddenWolf, probably not, but it should be :)
<sabdfl> niran: i think BountyProposals is supposed to be an open community "make your suggestion here" list
<sabdfl> what would be good is to highlight the Google accepted bounties in BreezyBounties
<niran> sabdfl, oops, I meant http://udu.wiki.ubuntu.com/GoogleSocApplications
<niran> sabdfl, that page has some of the accepted apps, and some that were rejected
<sabdfl> niran: well, let's just add an accepted / declined marker there
<sabdfl> what would really be cool is to have a nice Google image for that
<sabdfl> and to use that on http://udu.wiki.ubuntu.com/BreezyBounties too... next to anything which is being sponsored by google
<seb128> sivang: no
<sivang> seb128: ah ok, then I will email him, that would be probably a better way to reach him due to the different time zones
<mxpxpod> ok, I got hoary upgraded from breezy on my ibook, but when I start xorg, it tells me it can't find the fixed font
<Mez> mxpxpod, It's a known problem,, look on the forusm in the breezy section, there's an answer there (I'm just yrting to find a link)
<Mez> http://www.ubuntuforums.org/showthread.php?p=232047
<mxpxpod> ok
<sabdfl> night all
<\sh> g'night sabdfl and thx again
<Mez> hehe
<Mez> sabdfl looks like the nbarman at my local nightclub
<bddebian> heh
<Burgundavia> elmo, ping
<Mez> hmm
<Mez> weird error
<Mez> when my PC boots... it wontm mount my hard disk properly, but if i do sudo mount -a it will
<Mez> any ideas anyone
<mdke> #ubuntu?
<Mez> ^_^ whoops
#ubuntu-devel 2006-06-26
<TheMuso> Hey all.
<antinobody> hello
<antinobody> The Muso
<_TomB> I have linux-kernel-headers installed, and they are not in /usr/src
<desrt> ask in #ubuntu
<crimsun> [you're probably looking for linux-headers-$(uname -r) anyway] 
<desrt> tseng says "and eat a dick, *munch*"
<_TomB> thansk
<tseng> I definately said no such thing
<tseng> there is sangria involved for the record
<desrt> you are so sober now... that doesn't even count
<bddebian> tseng: Sangria?
<_TomB> what is the way to create a deb package after you've modified the apt-get source of it?
<LaserJock> _TomB: dpkg-buildpackage, check out the Packaging Guide at help.ubuntu.com
<dieman> everyone make it back home ok?
<TheMuso> Indeed I did.
<troy_s> most of us did i believe.
<neuralis> lamont: ping
<_TomB> When I rebuild casper, where do I put the casper.conf file?
<pitti> Good morning
<shawarma> Hi pitti!
* fabbione yawns
<pitti> hi shawarma 
<bluefoxicy> hi pitti
<bluefoxicy> pitti:  I am getting conflicting information here.
<bluefoxicy> neuralis said that Edgy will have SSP everywhere and pie in a few places; tseng said SSP in a few places and pie nowhere
<bluefoxicy> pitti:  what's going on?  :)
<Hobbsee> hi all
<pitti> hi bluefoxicy 
<pitti> bluefoxicy: the former is right, see the spec
<pitti> hi Hobbsee 
<Hobbsee> hi pitti 
<bluefoxicy> pitti:  nice.  Is it still killing python-egenix so postgre fails?
<bluefoxicy> (a problem I had way back in Gentoo)
<pitti> bluefoxicy: I only tested the packages on https://wiki.ubuntu.com/GccSsp so far
<bluefoxicy> pitti:  nod.  Are you using a hacked spec file or environment flags?
<pitti> bluefoxicy: see discussion in the spec, we'll change gcc's default
<bluefoxicy> err.  Environment
<bluefoxicy> compiler flags :P
<pitti> bluefoxicy: (i. e. gcc spec file)
<bluefoxicy> pitti:  alright.  You know the hardened team on Gentoo tends to have one of those laying around for pie/ssp right?
<bluefoxicy> don't know how useful that is to you
<pitti> bluefoxicy: yes, sure
<bluefoxicy> but maybe you can avoid some work ;)
<bluefoxicy> theirs emits PIE binaries too though so I dunno.
<pitti> bluefoxicy: btw, the gcc patch is already done, doko will upload it soon
<bluefoxicy> cool.
<pitti> bluefoxicy: I think PIE should be treated with more care
<pitti> it'll break way more stuff
<pitti> and as long as we don't have ASLR, it doesn't make much sense, right?
<bluefoxicy> it'll break... eh.  I'm not sure what PIE breaks.
<bluefoxicy> true, it doesn't do jack on the kernel's default ASLR, and we don't have PaX's code
<shadeofgrey> hello
<shadeofgrey> i have a question about ubuntu that is not support related and haventr thesluightest idea where to ask this question so ill try here and see what happens
<shadeofgrey> im toying with the idea of creating a blogged based help center for new users of ubuntu and advanced users that have really high end questions they cant get answers to without help
<shadeofgrey> and i was wondering if i hgave to pay the people who own the trademark ubuntu name to start a help websitye with ubuntu in the title
<bluefoxicy> pitti:  do you know wtf time zone doko is in btw?
<raphink> shadeofgrey: why not use the existing tools for that?
<raphink> shadeofgrey: the wiki, the ticket system on LP, planet, the forums
<pitti> bluefoxicy: CEST (+2)
<bluefoxicy> pitti:  so me + 6 hours... it's almost 8am there.
<shadeofgrey> raphink:  because the wiki and everything hasnt ever created a set of step by step set of instructions for handlking all of the most common installation usage problems
<bluefoxicy> (I'm at -4 right now)
<raphink> shadeofgrey: why don't _you_ do it ?
<raphink> shadeofgrey: without creating another tool
<shadeofgrey> and ive very meticulouysly been keeping a database of the problems ivcehad that i couldnt get answerrs to without hrelp from folks in the support channel
<raphink> you could use the existing tools to create the doc you want
<raphink> the wiki is made for what you describe
<shadeofgrey> yeah this is true
<raphink> multiplying the sources is the best way to get users lost
<bluefoxicy> https://wiki.ubuntu.com/HardenedHacking  <-- me using the wiki as a scratch pad
<shadeofgrey> but if i create a whole other repossitory for my stuff i can organise it the way i wnt
<bluefoxicy> raphink:  using a disorganized wiki was a pretty good way too ;)
<raphink> shadeofgrey: if eveverybody who writes doc does that, can you imagine what a mess the ubuntu doc will be?
<raphink> bluefoxicy: hehe
<shadeofgrey> kind of like ubuntuguide.org only way better
<bluefoxicy> fortunately a lot of stuff has been moved about.. but we need a table of contents
<raphink> shadeofgrey: you could also join the ubuntu-doc team
<raphink> so you can write doc in docbook and publish it in ubuntu
<shadeofgrey> yeah butsee i have my own writing style that doesnt realy fit the wiki at all.
<raphink> which is much better imo
<shadeofgrey> and i hated being part of the doc team because there were so many prerequisites to meet before i coiuld actually start making a difference
<raphink> http://doc.ubuntu.com/
<shadeofgrey> and i could have a decent amount of stuff online and blog worthy in less than 24 hours
<bluefoxicy> pitti:  you think I should rip off the http://www.gentoo.org/proj/en/hardened/gnu-stack.xml and stick it in Ubuntu's wiki somewhere?  And where... :)
<raphink> ok well 
<raphink> you do what you want
<raphink> I just find it too bad to do such things
<raphink> it's like each dev creating his own repository
<shadeofgrey> are you talking to me?
<raphink> instead of contributing directly to the official ones
<shadeofgrey> ah yeah you arre
<raphink> yep shadeofgrey
<pitti> bluefoxicy: I know that page (very useful!) but as long as it's not part of a particular spec, it does not make too much sense in the wiki
<bluefoxicy> pitti: nod.  Nobody much cares about removing the executable stacks from stuff at this point?
<pitti> bluefoxicy: I'd love to get rid of executable stacks in Ubuntu as well, but one step at a time :)
<shadeofgrey> so whats the next betra release for ubuntu called?
<pitti> bluefoxicy: i. e. as long as we do not introduce techniques like W^X, few people will care
<bluefoxicy> pitti: I did find a few of them that can be removed easy enough
<shadeofgrey> and are there alpha builds yet?
<bluefoxicy> pitti: remember, gaim has an executable stack because of #49192 :)
<raphink> what I see shadeofgrey is also that doing your things on your side with your own rights and so on is not really in the open-source spirit. If you stop keeping your doc up-to-date, who will keep it ?
<pitti> bluefoxicy: if you know concrete packages, then bug reports are appreciated
<pitti> bluefoxicy: (there are already some reports AFAIR)
<bluefoxicy> pitti:  on AMD64 it even has an executable stack, and on x86 with a real NX bits
<bluefoxicy> (yes, I submitted most if not all of those)
<shadeofgrey> id have to stop keeping it up to date before that argumenty woukld bvecome valid
<raphink> hmm
<shadeofgrey> and i wouldnt start something i wasnt positive i had the motivation to keep going
<raphink> ok 
<shadeofgrey> i mean, granted, it would probably be alot for one person to handle.
<bluefoxicy> pitti:  either of the solutions in the last two comments on #49192 will work; my first few bug reports were pretty much "Turn off assembly" while I figured out htf to fix them :)
<shadeofgrey> i guess  on the whiole its a bad idea
<bluefoxicy> I think most of those have comments that tell what to do to fix it without removing the hand-optimized assembly now
<shadeofgrey> i just      really wnt to give back because ubuntu has dione so much forme
<shadeofgrey> and i never felt like i goit anywhere trying to help thedocteam
<raphink> :)
<raphink> ok well
* raphink is heading to work :)
<raphink> laters
<Hobbsee> bye raphink!
<shadeofgrey> ill depart now.  i know i dont belong here
<bluefoxicy> shadeofgrey:  wow, that's admirable
<bluefoxicy> shadeofgrey:  I more want to lash out at Redhat than give back to Ubuntu ;)
<shadeofgrey> id vertainly join you in lashing out at redhat
<shadeofgrey> they sold out the opensource community something awful
* fabbione upgrades OBP/ALOM
<bluefoxicy> heh
<bluefoxicy> they give a lot back
<shadeofgrey> by the way since im here... does the x86 version of ubuntu run on the intel baswd mac's?
<shadeofgrey> i couldnt get an answer to that in the regular support channel
<Seveas> shadeofgrey, only with a nice bit of hackery
<bluefoxicy> pitti:  fun with prelink, I'm negotiating with LWN about an article I wrote describing prelink ;)
<bluefoxicy> pitti:  it started as an article pointing out an information leak to show why it's a BAD idea to prelink on servers where users have local access (i.e. any web hosting company, anywhere you give your users access to, sourceforge.net, etc)
<Treenaks> didn't the prelink hype die months ago?
<bluefoxicy> Of course, that only works if you assume 1) the machine relies on address space layout randomization as a security feature (the Linux kernel does have mmap() randomization); and 2) /proc/PID/maps is locked from local users
<bluefoxicy> Treenaks:  hype?
<bluefoxicy> Treenaks: prelink does a bit of nice stuff, but I haven't really noticed substantial load time reductions.  I'm actually more interested in Meeks' stuff.... (and looking at an idea I had as well)
<Treenaks> bluefoxicy: yeah.. when every gentoo-user was prelinking all his binaries
<bluefoxicy> Treenaks:  I'm hoping Meeks' enhancements stabilize by Edgy+1
* Treenaks off to work
<bluefoxicy> Treenaks:  I never prelinked on gentoo, it didn't do anything since I had a PaX kernel ;)
<bluefoxicy> the hardened team doesn't prelink, and I was siphoning all the information I could off them
<bluefoxicy> later
<bluefoxicy> I should sleep
<bluefoxicy> I'm making too much noise in here
<fabbione> bluefoxicy: that's why we have /ignore
<fabbione> :)
<Hobbsee> fabbione: shh, dont tell him :P
<Hobbsee> dont give away our secret
<fabbione> Hobbsee: hahaha
<Hobbsee> :P
<fabbione> Hobbsee: you miss the bofh point in that..
<Hobbsee> fabbione: only sort of.
<fabbione> confirm anawful truth using something that looks like a joke in the first place
<fabbione> normal mind will stop at the joke
<fabbione> somebody paying more attention would notice 
<crimsun> hmm. When I'm using bzr push [..]  as described at https://wiki.ubuntu.com/BzrMaintainerHowto , am I supposed to be pushing from the root of the extracted source package or a directory containing the orig.tar.gz+dsc+diff.gz+source.changes?
<pitti> crimsun: push doesn't mind which subdir you are in, it'll always push the whole tree
<pitti> crimsun: and the orig.tar.gz/diff/etc files should *not* be versioned
<crimsun> pitti: ok, so the extracted source then (which I'm using). I'm trying to debug why bzr push [..]  spins and returns "0 revision(s) pushed."
<pitti> crimsun: it always does that on initial push, cosmetic bug
<crimsun> pitti: ok, so I shouldn't expect to see the created branch until after the next publisher run?
<pitti> crimsun: the branch should be visible immediately
<bluefoxicy> oh my god  that was bad.
* bluefoxicy had to kill a process to get control of X >:|
<Hobbsee> hi BenC 
<bluefoxicy> https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/50977  There you go
<Ubugtu> Malone bug 50977 in nautilus "Nautilus-X hardlock with drag and drop over SSH" [Untriaged,Unconfirmed]  
<bluefoxicy> Have fun, I'm going to sleep.
<highvoltage> hey marilize. how goes?
<marilize> Hi highvoltage
<tseng> bluefoxicy: and who is neuralis ?
<bluefoxicy> tseng:  I have no idea, that's why I asked
<tseng> bluefoxicy: i have heard of him, but i dont see why he would know better than me (or the sepc)
<tseng> spec
<bluefoxicy> that's why I asked pitti
<tseng> and?
<bluefoxicy> see backlog and the spec
<fabbione> neuralis is part of the -server team.
<bluefoxicy> I think he said it's going everywhere
<fabbione> very clueful guy
<bluefoxicy> assuming I understand what "the former" means
<tseng> it is too early to parse that
<tseng> and read in between you making a fuss about redhat
<tseng> if the plan changed, fair enough
<Pharaoh_Atem> hello, just a quick question
<Pharaoh_Atem> when redhat tools are converted to ubuntu, does any tweaking need to be done?
<Pharaoh_Atem> or can the rpms be converted and then just installed?
<Pharaoh_Atem> im trying to get my soundcard to work
<Lathiat> #ubuntu would be the best place for those questions, Pharaoh_Atem 
<fabbione> Pharaoh_Atem: wrong channel. you want -> #ubuntu for general support
<Pharaoh_Atem> oh..
<Pharaoh_Atem> well, then i suggest that you guys add a soundcard configuration tool to the repositories
<crimsun> that's planned in some fashion
<Pharaoh_Atem> i have been working on this problem for 10 hours straight
<crimsun> ask me in #ubuntu
<Pharaoh_Atem> because i have no tool that can allow me to force detection of ISA
<nchip>  :)
<nchip> I mean hi
<hunger> ho
<dts> i know this might not be the right place but where can i go to debug a preseed file i wrote because it doesn't execute properly and i don't know why
<kane_> is there a channel for OOo issues/development ?
<Keybuk> pitti: any other syncs you have queued up?
<pitti> Keybuk: not so far, but assume I'll have more requests in the future :)
<pitti> Keybuk: right now I'm still doing security review and report syncs that fall off that, but I'll go over the list of packages I touched / the MoM bugs you'll file soon and ask for more
<Keybuk> *nods*
<slomo> Keybuk: thanks for the syncs :)
<Keybuk> I shall tip these into incoming then
<slomo> Keybuk: will you also work on NEW today? or could at least accept mono from binary NEW for me? ;)
<Keybuk> there will be three of us working on NEW for the next couple of weeks
<Keybuk> *sigh*
<Keybuk> o/~ 1484 binaries in NEW
<Keybuk> o/~ 1484 binaries
<Keybuk> o/~ You take one down, accept it and then
<Keybuk> o/~ 1568 binaries in NEW
<Lathiat> heh
<lucas> how many source packages ?
<Keybuk> lucas: at least one
<lucas> :-)
<TheMuso> Hey all.
<TheMuso> Does anybody happen to know how Henrik is?
<Keybuk> he's back in the UK
<Keybuk> and seems to be better
<TheMuso> Keybuk: Thanks.
<Keybuk> TheMuso: did you get home ok?  flight not too bad?
<TheMuso> Keybuk: Yeah it wasn't too bad. Got a ultra-dry throat from the dry air on the 13 hour flight, but am mostly over that now.
<TheMuso> And managed to sleep on the flights which was good.
<Keybuk> that's not so bad then
<TheMuso> Yeah.
<TheMuso> Keybuk: Was the final dinner and night enjoyable? I am kinda annoyed that I missed that.
<Keybuk> yeah, as much of it as I remember was enjoyable
<TheMuso> Uh... ok. Should I take that to mean anything in particular?
<Keybuk> very drunk
<Keybuk> slightly regretted booking a morning flight the next day
<TheMuso> I thought as much. :p
<Keybuk> especially when I was having to arrange an alternate route home
<TheMuso> Heh
<Keybuk> still, the Eurostar was nice
<TheMuso> I heard the food was better than what we got at the hotel.
<Keybuk> it was
<pitti> Keybuk: when will you start to file MoM bugs?
<Keybuk> pitti: by the end of today I hope
<Keybuk> just going through it all step-by-step to make sure it's working
* pitti hugs Keybuk 
<iwj> asac, jmg: pong
<Kamion> oh my god it's full of NEW
<asac> iwj: i sent you a mail :)
<Kamion> TheMuso: unfortunately my initial at-spi approach didn't work, at least not in the form I was hoping; now getting lots of errors of the form "/tmp/orbit-root has wrong owner" or something like that
<Kamion> TheMuso: I'm not out of ideas yet though, so I'll keep banging on it in spare moments
<Keybuk> Kamion: morning
<Kamion> hiya
<Kamion> I do so love having to spend a full two hours catching up on two weeks of IRC backlog :-/
<Keybuk> see, this is why I just don't bother <g>
<Kinnison> Kamion: it only took two hours?
<Keybuk> I've done the sources and everything < OPTIONAL in NEW this morning
<Keybuk> I suspect infinity may have done something too
<iwj> asac: Oh, good :-).
<crimsun> when I ``bzr push --create-prefix sftp://crimsun@bazaar.launchpad.net/[..] '', is an sftp: directory supposed to be created in my cwd?
<Keybuk> crimsun: install paramiko
<Keybuk> apt-get install python-paramiko
<Kamion> Keybuk: I'm starting on a NEW rampage now
<Kamion> Kinnison: I'd done some of it during the conference, just not this channel
<Kinnison> Aah
<crimsun> Keybuk: thanks
<\sh> moins
<jsgotangco> hello \sh
<pitti> hi Kamion 
<jsgotangco> hi pitti =)
<pitti> hi jsgotangco 
<jsgotangco> hi ogra
<ogra> hey
<\sh> hey ogra...
<ogra> hey \sh 
<sivang> hi everybody
<sivang> boy it's good to feel sober again ;-)
<\sh> hehe
<Treenaks> sober? on a Monday?
<\sh> you missed the after paris show party on Saturday/Sunday in St. Augustin, Germany ;) 
<Treenaks> ;)
<Kamion> Keybuk: u () { for x; do echo override $x binary universe//; done | q -f /dev/fd/0; }
<sivang> Treenaks: It's been a while since I got drunk. The french wine and champagne together with a hotel breakfast after 3 hours sleep (mostly scrumbled eggs) added to the mayham ;-)
<Kamion> ^-- time-saver
<Kamion> er providing that you've also done alias q=queue
<Keybuk> Kamion: cute
<pitti> Kamion: what does 'for x; do foo; done' do?
<Kamion> pitti: iterates over $@, i.e. all function args
<pitti> oh, cute
<pitti> Kamion: thanks
<sivang> hey Kamion , Keybuk 
<Keybuk> heyhey
<Riddell> how do we request a debian sync overwriting ubuntu changes?
<Kamion> Riddell: file bug on package, subscribe ubuntu-archive
<Kinnison> Umm, there's a procedure isn't there
<Kamion> it's certainly on the wiki somewhere
<Riddell> Kamion: ok, thanks
<pitti> Riddell: http://people.ubuntu.com/~pitti/scripts/requestsync might be useful for you
<pitti> Riddell: (requires up to date edgy sources in apt and working local MTA; if no MTA, insert your relay host into the script
<pitti> G0SUB: ping
<Keybuk> Kamion: I have a more evil piece of shell
<Keybuk> for FILE in $(<missing.txt); do PKG=${FILE%%_*}; if [ ${PKG%${PKG#???}} = "lib" ] ; then HASH=${PKG%${PKG#????}}; else HASH=${PKG%${PKG#?}}; fi; wget -q -O- http://snapshot.debian.net/archive/pool/$HASH/$PKG/source/Sources.gz | gunzip -c | sed -n -e "/^Directory:/{s/^Directory: *//;h};/^ [0-9a-f] * [0-9] * /{s/^ [0-9a-f] * [0-9] * //;G;y/\n/ /;p}" | while read SRC DIR; do if [ $SRC = $FILE ] ; then wget -q -O- http://snapshot.debian.net/archive/$DIR/$S
<Keybuk> RC; fi; done; done
<Keybuk> :p
<Keybuk> "download named files from snapshot.db"
* Kamion prefers 'if [ "${PKG#lib}" != "$PKG" ] '
<Keybuk> that'd work I guess :)
<Kamion> scary monsters
<Keybuk> I think that qualifies for the "if you ever need to use sed's 'hold space' feature, you should not be doing this in sed" though
<Kamion> Accepting ubuntu/edgy (NEW) 4/1285
<Kamion> getting there ...
<zul> hey
<G0SUB> pitti: pong!
<sivang> Kinnison: Make sure you post the lymmricks for the sake of mankind :-)
<pitti> hello G0SUB, how's it going?
<G0SUB> pitti: it's going great. I have quite a lot to discuss. please come to #synaptic
<sivang> Kinnison: (somewhere public)
<neuralis> tseng: there are a few things up in the air here. if we can get pax's aslr into our kernel without too much hassle, the plan is to turn on pie for as many of the -server packages as possible without breaking anything.
<pitti> hi neuralis 
<Kinnison> sivang: due to the sensitive nature of some of them, they'll likely not be public
<sivang> Kinnison: ah
<sivang> Kinnison: k, then never mind.
<pitti> Nuffing: hello Jane, how are you?
<neuralis> pitti: hey there
<jsgotangco> heh
* jsgotangco starts uploading pics
<neuralis> pitti: brad responded, but dropped you from cc for some reason
<Nuffing> hey pitti
<neuralis> pitti: i'll forward his reply, but it's not looking hopeful at the moment
<pitti> neuralis: :(
<sivang> doko: ping
<doko> sivang: pong
<sivang> doko: just another proposal for another field in UbuntuPackagingChanges , I think something should be in place to have a brief description of how th echange manifests, so for LPI "Makes all applications with a menu bar have extra 2 items under 'Help'"
<sivang> doko: otherwise we have described everything, but nothing abut what  a change entails
<sivang> (I just filled the LPI part)
<doko> sivang: hmm, that should go into "description", at least I don't know what to put else there ...
<sivang> doko: take it back. since we now have specs for everything like this,
<sivang> doko: we should only have a link to the spec
<sivang> doko: so we could add a link to the spec in description , or should that be another field ?
<doko> sivang: well, no, the idea of the list to have a *short* description of it in one place
<sivang> doko: okay 
* sivang fixes
<tseng> neuralis: sounds great.
<mvo> doko: ping
<mvo> doko: is the profile module not included in our edgy python? or am I just blind?
<ogra> isnt profile multiverse ? 
<Kamion> yes
<ogra> and it has its own source package ;)
* mvo scratches his head and wonders why multiverse is missing in his sources.list
<sivang> hye mvo 
<simira> hi mvo :) a lot to do with update-manager lately? It seems to work pretty randomly to me 
<mvo> hello sivang! did you had a good trip back?
<mvo> simira: oh, randomly in what way?
<sivang> mvo: yes, indeed. and you ?
<simira> mvo: before last update, the "Install update" button only reloaded the updates-list
<Hobbsee> hi mvo and sivang 
<simira> mvo: still does. A bit tiresome.
<sivang> hey Hobbsee 
<mvo> simira: on dapper? or edgy?
<simira> mvo: on dapper. Is edgy running at all yet?
<mvo> simira: *ick* that sounds evil. can you please run it in a terminal and /msg me the output of the terminal?
<ogra> simira, we didnt start breaking edgy yet ... 
<Keybuk> ogra: we SO did
<simira> ogra: that's what I thought
<ogra> Keybuk, pfft ... waaay more to come :)
<Keybuk> http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html
<sivang> Keybuk: how do you produce that list?
<Hobbsee> Keybuk: is that *really* all the problems, or is there another more comprehensive i386 list somewhere?
* Hobbsee is really greatful not to own an amd64 right now.
<sladen> Hobbsee: just package independancies
<ogra> hey sladen !
<Hobbsee> sladen: right
<sivang> ogra, sladen : how was the driving back to germany ?
<sladen> ogra: rocking ogra.  I brought a Belgian GoPass and went Leige->Gent, then Gent->Brussels yesterday
<ogra> nice ... very hot ...
<Keybuk> sivang: it's produced by a tool called "britney"
<Keybuk> Hobbsee: those are the packages in main that are uninstallable
<sladen> sivang: low-down and fast.
<Hobbsee> Keybuk: right, got it
<sivang> sladen: cool :-)
<sivang> Keybuk: ah, on the dak suite of tools?
<Kamion> sivang: sort of
<Hobbsee> didnt think there were enough packages there to warrant reports of being "extremely broken"
<sivang> Kamion: thx
<Kamion> it's not a core part of dak, but it is part of the Debian archive maintenance systems
<sivang> ah
<Kamion> we use it in an extremely cut-down way
<neuralis> Keybuk: is there any documentation about apt.conf.d actions around?
<sivang> Kamion: I see.
<Keybuk> neuralis: no idea, ask mvo/mdz
<neuralis> mvo: --^
<mvo> neuralis: there is some docu in /usr/share/doc/apt/examples/configuration-index
<neuralis> mvo: let me ask a more specific question. i'd like to add a hook that gets called for each newly installed package, and obtains a list of the newly installed conffiles. i can do that either via the new package name, or the direct contents of /var/lib/dpkg/info/<pkg>.conffiles being passed.
<neuralis> mvo: what's the nicest way to go about it?
<mvo> neuralis: there is DPkg::{Pre,Post}-Install-Pkgs {} that will feed you the package names, but beside that you will be on your own (i.e. you will have to figure out about the configfiles yourself)
<neuralis> mvo: got it. is /var/lib/dpkg/info a path that's hardcodeable, or do i need to obtain it in some other way? it seems like checking for /var/lib/dpkg/info/$PKG.conffiles and taking its contents is all i need to do, no?
<mvo> neuralis: you can find out about dpkg/info via the apt config variable "Dir::State::status". look for the code in /usr/bin/unattended-upgrades for a example
<neuralis> mvo: cheers.
<mvo> neuralis: yes, that should be basicly be what you need. if you need the information before the install you will have to look inside the package (via "import apt_inst" in pyhton), but I guess that is not required
<neuralis> mvo: nope, post-install only
<mvo> neuralis: np :) will it be python-based?
<neuralis> mvo: indeed.
<mvo> neuralis: nice :) 
<neuralis> mvo: this is just for a proof of concept on versioning /etc in bzr for -server; it'd be nice to get conf files automatically added and removed from versioning on package installation
<neuralis> my gut feeling is that we shouldn't just version all of /etc, but perhaps i'm wrong
<fabbione> neuralis: you still want all of /etc
<mvo> neuralis: interessting idea, is there a spec/wiki/repository that I can supscribe to to be kept upgraded?
<fabbione> neuralis: otherwise config files generated by maintainer scripts will not be under RCS
<neuralis> mvo: the safest bet is to subscribe to edgy-server-candy for now; etc-in-svn exists, but is being worked on by someone else
<neuralis> fabbione: yeah, i was thinking about that
<mvo> iwj: around?
<Lathiat> also user created files
<neuralis> fabbione: but there's a pile of crap under /etc that it doesn't make much sense to version
<Kamion> IMO the answer to that is "less crap in /etc"
<Lathiat> better safer than sorry
<Lathiat> and that
<fabbione> neuralis: there is a pile crap only in desktop ;)
<fabbione> neuralis: the server doesn't have 2TB of gconf stuff
* Lathiat grins
<neuralis> fabbione: :-D
<fabbione> :)
<neuralis> yeah, not that bad on -server
<neuralis> some tarballs in alternatives/, but those can be skipped
<neuralis> looks like ssl/certs and alternatives/ can be skipped, and the rest is fine
<neuralis> we don't have any crackheaded packages that install important conf files outside of /etc, do we?
<fabbione> neuralis: if they do, they are not policy compliant.. = we need to fix the packages
<neuralis> right.
<iwj> mvo: Hi.  What can I do for you ?
* iwj reads scrool.
<iwj> neuralis: The status file has conffile information in it.
<iwj> You want to get it from dpkg --status or equivalent.
<iwj> Interestingly there isn't a dpkg rune to print the output of dpkg --status <every package>.
<iwj> /var/lib/dpkg status isn't quite the same for various reasons.
<iwj> Isn't there a python lib for this kind of thing ?
<Mithrandir> for p in $(dpkg-query --showformat '${Package}\n' -W \*); do dpkg -s $p ; done, but that's quite slow an inefficient.
<Mithrandir> it also gives you uninstalled packages
<neuralis> Mithrandir, iwj: it looks like a blacklist approach to versioning (all of /etc except ...) makes more sense anyway, so it probably won't be needed
<madduck> Mithrandir: dpkg --get-selections | sed -nre 's,([^[space] ] +)[[:space:] ] *install$,\1,p'
<madduck>   | xargs dpkg -s
<madduck> (anyway, you knew that)
<bddebian> Heya folks
<ompaul> fabbione, sorry to be a offtopic - got a pointer to ubuntu on sparc - I want to (A) make a factoid of same and (B) point someone on a non ubuntu mailing list to same
<iwj> neuralis: all of etc> Yes, dpkg conffiles are only the smallest simplest part of configuration files.
<neuralis> ompaul: what do you want to know?
<neuralis> iwj: right.
<iwj> Putting the whole lot in an rcs will be an interesting experiment.  It might work very well.
<ompaul> I want to point someone on a non ubuntu list to some kind of docs - he was suggesting he had a scsi issue, and secondly if someone asks on irc I would like to point them to the same resouce (of course I am assuming one exists - not always the best policy ;))
<ompaul> neuralis, ^^ sorry forgot to address it
<iwj> The whole configuration arrangements are designed to cope with sysadmins editing things and you can think of the rcs as being the sysadmin's overdeveloped text editor, so you might well be lucky.
<iwj> Make sure your rcs is one which doesn't trash ownerships.
<neuralis> iwj: well, there's a very strong push to use bzr if we plan on shipping this
<iwj> neuralis: I don't know what bzr's behaviour with ownerships is.  I just mentioned it as a thing to check.
<neuralis> iwj: aye.
<iwj> This reminds me of Kamion (I think it was Kamion) telling us about having some directory which was both a cvs working tree and an svn working tree.
<lamont> neuralis: ack
<Keybuk> iwj: that's not uncommon
<Kamion> iwj: yeah, that was me
<bddebian> Hi Keybuk, Kamion, lamont
<lamont> morning bddebian 
<tseng> bddebian: hi
<bddebian> I see a lot of ubuntu1 versions coming in Edgy-changes.  Have merges started already or are people doing them manually?
<Kamion> merges are always manual
<tseng> er, ubuntu1 is never automated
<Keybuk> bddebian: it looks like GNOME so far, which we package separately
<Kamion> if you mean "without MOM", though, some people have been doing them without its aid yes
<tseng> most of the automatic merges dont show up in edgy-changes anyway
<Kamion> in particular if you've got bzr imports for the package then it's straightforward
<Kamion> tseng: YM automatic syncs
<tseng> yes.
<tseng> I do :)
<bddebian> Ack, folks, I know.  What I am asking is if MoM has been started yet? :-)
<tseng> i think there is new stuff in /patches
<tseng> but not in /ongoing-merge
<Kamion> bddebian: Scott's been working on it pretty hard over the last week; should be soon
<tseng> I don't use it anyway
<bddebian> Kamion: Ah, OK, thanks
* bddebian is just waiting for something to 'help' with :-)
<Kamion> but feel free to start on merges in advance if you have stuff you know about
<Keybuk> should be today sometime
<Keybuk> the expiry tool was a little over-enthusiastic over the weekend, so I'm sanity-checking things today :-/
<bddebian> Kamion: Well I really can't do any main stuff unless it's on LP I suppose
<Keybuk> when I'm happy it's not going to output "potato vs. edgy" merges, it'll be go
<bddebian> Unless I post elsewhere I guess
<Keybuk> bddebian: there's PLENTY of universe stuff coming
<bddebian> Potato.. Hehe
<bddebian> Keybuk: Trying to keep me away from main are you? ;-P
<Keybuk> universe needs love too
<Keybuk> in fact, universe needs a lot more than main given it diverged wildly
<Kamion> NEW down to < 500
<Kamion> I guess I should do something else other than archive maintenance today :-/
<zul> heh
<bddebian> Fine, I'll stick to my lowly Universe.. :-)
<tseng> hah
* bddebian gets no love
<tseng> or it is overcast by self-deprecation
* Hobbsee prods bddebian into writing us a comprehensive guide on how to merge, and doing more merging.
<Keybuk> Kamion: it's either NEW, merges or specs :)
<bddebian> tseng: ?
<bddebian> Hobbsee: Didn't I write a wiki for merges during Breezy?
<Keybuk> that will need updating somewhat :-/
<Hobbsee> bddebian: you might have, i'm not sure.  especially not at this time of night
<Hobbsee> yeah
* desrt glares at the non-guadec attenders
* Hobbsee is glared at, and glares back, as she's a rebel.
<bddebian> heh
<desrt> right.  rebels always copy the behaviour of others.
<desrt> :)
* sivang -> out
<Kamion> doko: can zope-cmf1.4 come back into the archive now? it was removed because it was only for zope2.7, but it seems to be for zope2.8 as well now
<elmo> hey, can someone do a trivial seedchange and promote emacs21-nox to main?  it's in universe for no readily apparent reason (same source package as emacs21, no additional depends)
<Kamion> elmo: sure, let me just get rid of my own backed-up seed changes
<elmo> Kamion: gracias
<zul> elmo: i was wondering if you have added my key to security?
<elmo> zul: meh
<zul> elmo: i take it as a no :)
<antinobody> Hobbsee I think bddebian's talking about this page --> https://wiki.ubuntu.com/MOTU/Packages/Merging
<antinobody> tis where raphink pointed me a few days back anyway
<Hobbsee> yeah, likely
* Hobbsee cant consider that tonight.
<Kamion> elmo: seeded, will promote after this publisher run finishes
<elmo> zul: done - pending propagation
<zul> elmo: thank you
<Keybuk> Kamion: should probably seed/promote emacs-nox instead
<Kamion> Keybuk: we should pull all of emacs-meta into main in fact, I think
<Kamion> Keybuk: shouldn't emacs-meta have an emacs-el too?
<Keybuk> yeah, was just thinking the same (emacs-el)
<ogra> doko, ping
<Kamion> Keybuk: will you do that, and I'll do s/emacs21/emacs/ on the seeds?
<Keybuk> yup, uploading now
<Kamion> Keybuk: FYI there are several packages in the NEW queue that were removed from dapper and snuck back in - I've been investigating and adding them to the sync blacklist if appropriate
<Kamion> probably worth being careful if you decide to process zope* binaries
<Keybuk> *nods* is entirely likely
<doko> Kamion: I'll talk with Fabio (zope maintainer), I want zope2.8 be removed from the archive as well
<doko> ogra: pong
<ogra> doko, i have a bunch of probs with ltsp changes from debian ... they change all strings from $"string" to `eval_gettext "string"` is bash in debian supposed to know about eval_gettext ?
<ogra> (or to know about ignoring it)
<fabbione> ompaul: ??? i don't understand what do you need..
<Kamion> doko: ok, shall I remove those packages again then?
<Kamion> ogra: that smells like a function definition somewhere else, not a builtin
<ogra> Kamion, 
<ogra> <ogra> ogra@edubuntu:/mnt/devel/bazaar/devel$ xgettext --language=Shell -o po/ltsp.pot.test /usr/sbin/ltsp-build-client
<ogra> <ogra> /usr/sbin/ltsp-build-client:107: warning: the syntax $"..." is deprecated due to security reasons; use eval_gettext instead
<doko> Kamion: I'll try to get in contact with Fabio first, I didn't follow how stable plone with zope2.9/zope2.10 is
<fabbione> ompaul: anyway i am offline now.. -> soccer
<ogra> its a xgettext builtin it seems
<ompaul> okay
<Kamion> ogra: you need to source gettext.sh for those builtins to be available
<Kamion> ogra: see 'info gettext'
<ogra> gah ...
<ogra> Kamion, TA!
<Kamion> np
<bddebian> do be do be dooo
<tseng> bddebian: ?
<bddebian> Sorry, just hating my life right now :-)
<Keybuk> why?
<tseng> because he lives in Philadelphia
<tseng> the city of filth
<bddebian> RL job sucks, don't know what to do for Edgy, blah, blah.. :_)
<bddebian> tseng: I don't live in Philly, I WORK in Philly :-)
<tseng> you live close enough to catch a wiff
<LaserJock> bddebian: I've got some things for you to do for edgy ;-)
<bddebian> tseng: ;-)
<bddebian> LaserJock: I thought you said I don't belong here? :-)
<LaserJock> bddebian: bah, that's only when I don't want something from you ;-)
<bddebian> hah
<highvoltage> tseng: if you want to see filth, go to paris :)
<LaserJock> ouch ;-)
<highvoltage> well, it's the dirtiest city i've ever seen. i've never seen so many cigarette butts before.
* ogra felt pretty confotable ...
<ogra> s/n/m/
* bddebian goes to have a cigarette ;-)
* ogra too
<mdz> zul: morninig
<bddebian> Just zul?  What about the rest of us? ;-)
<_ion> Well, it's evening in here. :-)
<bddebian> And afternoon here so I guess that explains it :)
<pitti> hi mdz
<ogra> hmm, since whenn do we default to aks the resolution question on xserver install ? seems i have no autoprobing anymore if i build an ltsp chroot
<pitti> ogra: we always did
<pitti> ogra: if the resolution could not be detected automatically
<ogra> pitti, nope
<ogra> pitti, we used to run dccprobe or something and fell back to ask only if that failed
<pitti> ogra: I got this question since at least hoary (before autodetection worked due to another cable)
<pitti> ogra: right, that's what still happening
<ogra> and it always worked reliable with the dapper packages
<pitti> ogra: well, I didn't check edgy's installation yet, though
<ogra> my screen flashed once and it went on building the chroot ...
<ogra> now it doesnt flash and i get the resolution question directly
<glatzor> ping sivang
<fabbione> ompaul: ping?
<ompaul> fabbione, pong
<lool> I can't grab piti, isn't he on IRC nowadays?
<ompaul> lool, he is on a regular enough basis
<fabbione> ompaul: can you tell me what you need exactly? i didn't understand a word of what you wrote before (i only have 2 minutes left)
<ogra> lool, he's off doing sports
<lool> (ok, it's been a couple of times I /lastlog piti and whowas doesn't yeld anything)
<ompaul> okay, I am looking for an "introduction to Ubuntu on the sparc"
<ogra> lool, also its pitti with two t
<ompaul> fabbione, ^^ any gotchas 
<lool> hmm that's why :)
<fabbione> ompaul: what kind of introduction?
<ompaul> fabbione, something that if someone comes into #ubuntu and says "how do I do ubuntu on sparc" I can point them at
<fabbione> ompaul: the same way as any other architecture
<fabbione> there are also the installer docs on doc.ubuntu.com
<fabbione> KnownIssues and TODO are on the wiki
<ompaul> fabbione,  that would be a good point to start them from, thanks
<fabbione> np
<ompaul> fabbione, most people don't start there, but that is a different issue, thank you for the pointers
<fabbione> ompaul: people that have sparcs and don't know how to install, they don't deserve that kind of metal :P
<fabbione> anyway i am off
<ompaul> hehe sssshhhhh don't say that too loudly
<ompaul> enjoy your evening
<bluefoxicy> http://rafb.net/paste/results/pwXEni73.html  Do I need to file individual bugs for each package these are in?
<Keybuk> bluefoxicy: -ECONTEXT
<bluefoxicy> Keybuk:  duplicate, identical files from the same package, ranging from a k and a half to a full meg
<bluefoxicy> (I saved 232K space by symlinking identical files to eachother in gzip; and a meg by doing same with perl 5.8.2)
<Keybuk> bluefoxicy: are you sure they're not hard links to the same file?
<bluefoxicy> Keybuk:  wow I didn't even think about that
<bluefoxicy> Keybuk:  apparently they are.
<bluefoxicy> well I feel dumb now :)
<Keybuk> ...
* bluefoxicy modifies his script slightly.
<Ckenyon> ping : mjg59
<Ckenyon> mjg59 : ping
<duck--> hello
<bddebian> Hello duck--
<duck--> hiya
<highvoltage> anyone seen heno around?
<bluefoxicy> well.
<bluefoxicy> tseng:  ping
<bluefoxicy> doko: or if you're around...
#ubuntu-devel 2006-06-27
<visik7> hi
<visik7> why there is no restricted for 2.6.17-1 ?
<bddebian> Heya
<nickrud> exit
<nickrud> erm, try
* Starting logfile irclogs/ubuntu-devel.log
<stub> Launchpad will be going down in 15 minutes time. Estimated downtime is 10 mins. This is for the regular code update.
<stub> I've had to abort the update. Another attempt will be made later today.
<pitti> meh @ edgy udev
<pitti> hi marilize, hey mvo
<mvo> hey pitti!
<Hobbsee> hi pitti and mvo 
<jsgotangco> hey pitti, mvo
<jsgotangco> did you see the group photo already from kwwii??
<marilize> hey pitti
* pitti feels at home in edgy: doesn't boot any more, xchat loks ugly, gtimelog looks much more fancy
<pitti> jsgotangco: no, I didn't, where is it?
<jsgotangco> http://bootsplash.org/14_3.jpg
<slomo_> pitti: regarding xchat looking ugly... you mean the entry where you type everything in? ;) it's only this weird now because it's a multi-line entry... try pasting more than one line in there
<slomo_> pitti: but it's ugly nonetheless
<pitti> slomo_: indeed
<pitti> slomo_: the height should adapt to the font size, as usual
<pitti> slomo_: right now it wastes too much space for my screen layout
<stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime is 10 minutes.
* Starting logfile irclogs/ubuntu-devel.log
<seb128> pitti: alter
<seb128> around?
<pitti> seb128: duderino!
<seb128>  /usr/bin/fakeroot debian/rules clean
<seb128> /usr/share/cdbs/1/rules/langpack.mk:23: *** missing separator.  Stop.
<seb128> that's how rhythmbox didn't build
<seb128> do you know about that?
<seb128> http://librarian.launchpad.net/3158171/buildlog_ubuntu-edgy-i386.rhythmbox_0.9.5-1ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> what???
<pitti> seb128: no, I didn't
<seb128> k
<pitti> seb128: and line 23 of that file is
<seb128> so now you know
<pitti> ifndef _cdbs_bootstrap
<pitti> _cdbs_scripts_path ?= /usr/lib/cdbs
<pitti> which looks sane to me...
<seb128> hum
<seb128> to me too
* seb128 wonders how many packages are not building due to that
<pitti> seb128: I try a local build
<seb128> local build works fine for me
<pitti> seb128: hmm. wtf???
<seb128> what?
<seb128> my cdbs might have been outdated when I built it
<pitti> seb128: did you notice the same in other packages?
<seb128> no
<pitti> seb128: I'm on current edgy, lemme try a build here
<seb128> but i didn't upload anything else yesterday
<seb128> I'm on edgy too
<pitti> seb128: oh, rb is still the dapper version
<seb128> pitti: on my cdbs version l23 is @PATH_RULES@
<pitti> huh?
<seb128> ifndef _cdbs_bootstrap
<seb128> @PATH_RULES@
<seb128> endif
<pitti> that looks like the .in file
<seb128> ii  cdbs                              0.4.41ubuntu3                     common build system for Debian packages
<pitti> hm, works fine here
<seb128> is l23 @PATH_RULES@ for you?
<pitti> no, as I said, it's " _cdbs_scripts_path ?= /usr/lib/cdbs"
<pitti> (without the first space)
<pitti> seb128: lemme reinstall cdbs
<seb128> what version do you have?
<seb128> is that a local build?
<pitti> seb128: someone else touched cdbs after me, so I doubt it
<pitti> anyway, now I have the latest version
<pitti> seb128: ah, indeed, fucked langpacks.mk
* pitti larts Riddell 
<pitti> seb128: ok, I'll fix that
<seb128> pitti: thank you
* seb128 hugs pitti
<pitti> Riddell: sorry for larting, that should have gone to siretart 
<Riddell> pitti: no problem :)
<Riddell> pitti: siretart is keeping cdbs in a bzr archive
<pitti> Riddell: oh, thanks for the hint
<Riddell> bzr checkout sftp://bazaar.launchpad.net/~ubuntu-core-dev/cdbs/ubuntu
<pitti> Riddell: hm, apparently the bzr only has ubuntu1, but the archive has ubuntu3; did you push your changes?
<pitti> right now, the checked out tree is a total wreck, missing files, failing test suites, etc.
<KaiL> new ati driver - but not worth an upgrade (neigher X1900 support nor fixed libGL for R200)
<pitti> Riddell: anyway, I'm going to fix up the bzr now
<Riddell> pitti: no, I've not had time to look at the bzr stuff, I didn't know about it until after I uploaded
<KaiL> and new nvidia-legacy drivers - yes, nvidia really did it :)
<pitti> Riddell: why did you remove the ant.sh test?
<pitti> ant-1.sh, rather
<Riddell> pitti: don't we have ant disabled in our cdbs?
<pitti> Riddell: I changed the test to silently succeed if ant isn't isntalled (since some dependencies are in universe)
<dibblego> I have opened a bug because libgtk2.0 is causing a segmentation fault, but since I'm a noob, I'm not sure if I have provided all the required information - can anyone please confirm anything more that need to provide? I'm pretty keen to see it fixed :) https://launchpad.net/distros/ubuntu/+bug/50836
<Ubugtu> Malone bug 50836 in Ubuntu "gdk-pixbuf-query-loaders segmentation fault" [Medium,Needs info]  
<crimsun> hmm, I wonder if my key is acting up again.
<Kamion> jdub: could you put the CC meeting on the fridge calendar? today at 1400 UTC
<siretart> pitti: btw, any reason to not remerge cdbs yet? (only changes in python-distutils.mk.in)
<pitti> siretart: no, this morning I just fixed the FTBFS of the majority of the archive, that was a bit urgent
<pitti> siretart: I also repaired the bzr and brought it up to date
<pitti> siretart: feel free to remerge :)
<siretart> pitti: allright. I merged cdbs that time because I hope this would make fix many ftbfs in python packages. and it did built in my chroot that time. however the buildds seem to have been disabled at time of uploading, and the archive has changed since my upload
<ogra> pitti, i just had someon complaining about missing translations in tuxpaint, where are translations of sdl games supposed to be in ? 
<pitti> $ dpkg -L language-pack-de-base |grep tuxpaint
<pitti> /usr/share/locale-langpack/de/LC_MESSAGES/tuxpaint.mo
<pitti> /usr/share/locale-langpack/de/LC_MESSAGES/tuxpaint-stamps.mo
<pitti> ogra: ^
<ogra> ah, base :)
<ogra> thanks !
<pitti> ogra: yes, if the update package does not have it, then there are no new translations since the dapper release
<ogra> he said he had installed the language-support-fr package ... 
<ogra> i 
<pitti> ogra: yes, -support does not have any translations
<ogra> i'd expect that to pull -bas in
<ogra> *base
<pitti> ogra: it recommends -pack, but not depend on it
<ogra> or isnt that a metapackage
<pitti> since that wouldn't make sense
<ogra> aah !
<ogra> ok :)
<pitti> since usually you only need a subset of supported languages as desktop translations
<iwj> Joy.  coreutils is FTBFS
<iwj> Oh, no, my libc is hosed.
<hunger> iwj: That's the fun you get for living on the edge:-)
<Kamion>          | * libmaypole-plugin-authentication-usersessioncookie-perl/1.8-2/i386 Component: main Section: perl Priority: EXTRA
<Kamion> contender for longest package name
<Kamion> although probably not a winner
<Mithrandir> there are some other perl modules which are pretty bad.
<Keybuk> ah, conflag caught up with me this morning it appears
<Kamion> conflag?
<zul> hey
<Kamion> Keybuk: I forcibly synced a few of the things in syncs/problems.txt and removed them from that file (bison-doc, make-dfsg, realpath)
<Keybuk> ok, cool
<pitti> Kamion: at least it's longer than the current champion linux-restricted-modules-2.6.15-23-amd64-generic
<Keybuk> that was everything that failed and I didn't want to investigate just yet
<Keybuk> Kamion: like jetlag, but for conferences ... when you get home and your body goes "SLEEEEEP!"
<Kamion> ah yes
* Kamion had lexed it as conf-lag
<Kamion> er, con-flag
<Mithrandir> Keybuk: did you just rm -rf patches.u.c?
<Keybuk> Mithrandir: yes :)
<Keybuk> well
<Keybuk> merge@casey:/srv/patches.ubuntu.com/published$ touch REBUILDING-AGAIN-PLEASE-STAND-BY; rm -rf *
<Mithrandir> that's not a very useful ordering. :-P
<Kamion> haha
<_ion> :-)
<Keybuk> Mithrandir: that only occurred to be *after* I pushed enter
<Mithrandir> heh
<Keybuk> just doing a final flush and rebuild for mom
* ogra vomits over his airport extreme
* Treenaks calls airport security
<Keybuk> Kamion: at some point this week I'm going to go through sync-blacklist and make sure it's all still sane
<pitti> ogra: still b0rked?
<Keybuk> heh, ... "I am working on a project that maintains a list of active hardware on a machine and we want to make it hotplug "aware"."
<Keybuk> ... so that would be "HAL" then ?
<ogra> Treenaks, well, they'll go away as well during one of the 20 reboots i have to do every day 
<ogra> pitti, yes, dmesg shows some irq problems
<Keybuk> pitti: bug #51083, talk to me
<Ubugtu> Malone bug 51083 in udev "does not create most of the harddisk devices" [Critical,Unconfirmed]  http://launchpad.net/bugs/51083
<pitti> Keybuk: so, how can I debug this?
<pitti> Keybuk: I can install the new udev again and boot, and collect info
<Keybuk> ok, so first we need to identify what is actually going wrong; there shouldn't be any significant difference between the two udevs
<Keybuk> so install the new udev again
<pitti> Keybuk: ok, let me boot my ibook to have a stable IRC, then I'll screw up my desktop
<Keybuk> and make sure the install is sane -- the init script should call udevtrigger and udevsettle -- not udevplug
<Keybuk> (I suspect the bug is because we use PHYSDEVBUS in a few places where we shouldn't and I haven't fixed those rules yet)
<Keybuk> though that should only break permissions, I thought
<pitti> ok, package upgraded, init script is the pristine one from the 093 package
<pitti> Keybuk: hm, I just saw something during install
<pitti> cpio: ./lib/udev/path_id: No such file or directory
<robertj> is there a spec for no-auth security updates? I hear it's goin to be standard in Vista.
<Keybuk> that's ok, it's just a minor thing
<pitti> ok
<Keybuk> actually, can you do gunzip -c /boot/initrd.img$VER | cpio -t | grep ide
<_ion> robertj: It already exists, just turn it on.
<Keybuk> pitti: the last thing should be lib/udev/ide_media
<pitti> Keybuk: it's the first thing for me
<Keybuk> ok
<Keybuk> as long as it's in there :)
<robertj> _ion: Automatic updates option?
<pitti_> 'k, should I reboot now?
<Keybuk> yup
<pitti_> Keybuk: goddamn, of course it boots now
<Keybuk> heh
<pitti> Keybuk: if your mere aura fixed it, so much the better ;)
<Keybuk> I'm not aware of anything that could actually prevent a device being created within udev
<Keybuk> usually that means the kernel burped, not udev
<Keybuk> though it can mean that udev failed to load the module the kernel needed
<zul> is there a cc meeting today?
<Kamion> does anyone feel their edgy system is working too well and want to test a new busybox-initramfs?
<Kamion> zul: see CommunityCouncilAgenda
<Hobbsee> i take it that means no.
<Kamion> Hobbsee: see CommunityCouncilAgenda
<zul> Hobbsee: according to the wiki there is
<mdke> Kamion: I can't make the meeting, hopefully my agenda item is self explanatory enough to be discussed anyway...
<Hobbsee> ah, hey, there you go!  i'm sure that wasnt there when i looked last time
<Kamion> mdke: probably yes
<Kamion> Hobbsee: I imagine not, I only put it there a couple of hours ago
<Hobbsee> Kamion: right, okay, cool :)
<mdke> Kamion:great, thanks
* Hobbsee will stay up for it, being interested in the IRC network choice.
<zul> same here
<zul> except for the the staying up part :)
<Hobbsee> hehe
<TheMuso> Ah. So someone has decided to put that up for discussion.
* TheMuso looks.
<ogra_> Keybuk, !
<Keybuk> ogra: ?
<ogra_> my ibook doesnt find its roofs anymore after upgrading to -25
<zul> eh?
<ogra_> it drops me out of usplash at "mounting root filesystem"
<Hobbsee> er...your ibook has roofs?
<Keybuk> to what -25 ?
<ogra_> linux image 2.6.16-25-powerpc
<Keybuk> edgy?
<ogra_> nope
<Keybuk> kernel bug, then
<ogra_> well ...
<ogra_> it drops me to a console
<ogra_> IP-Config: eth0 hardware address .....
<ogra_> i've never seen that 
<Keybuk> hmm?
<Keybuk> sounds like you've set your initramfs to be in BOOT=nfs mode :p
<Keybuk> was ogra playing with ltsp in Paris? :p
<ogra_> looks like its attempting to netboot
<ogra_> nope
<Keybuk> bet you 10 ?
<ogra_> i wasnt playing with anything on the powerpc
<Keybuk> at the console ... grep BOOT conf/initramfs.conf
<ogra_> thats why i had my ltsp server amd64 lappie with me ... powerpc isnt really helpful for ltsp stuff
<ogra_> i have no prompt
<Keybuk> liesx
<ogra_> it just hangs there
<Keybuk> boot the older kernel and initramfs
<ogra_> i cant, there is no entry for int in yaboot
* ogra_ gets a ppc livecd
<Keybuk> boot with break=top then
<ogra_> oki
<ogra_> shudder, its indeed set to nfs ... but i know i never touched it
<Keybuk> boot with boot=local then
<Keybuk> and fix it
<ogra_> actually it looks like a complete ltsp initramfs.conf ... how did that get there
<Keybuk> I accept Paypal
<ogra_> doesnt work, since no ide modules are loaded in ltsp netboot initramfs :P
<ogra_> i suspect i need the livecd
<ogra_> thats just mad ... i know for sure i never touched it ... and ltsp doesnt touch the servers initramfs.conf ...
<ogra_> Keybuk, i'll pay in beer on the distro sprint
<ogra_> thanks for helping :)
<Keybuk> never blame udev for that which can be ascribed to pure stupidity
<Keybuk> no worries :p
<Keybuk> I've made the same mistake before, installed something on my desktop without noticing that it was in a window ssh'd into my laptop
<ogra_> well, i guess my tests with the debian ltsp patches have somehow touched it without me noticing ..
<ogra_> woah, breezy livecds boot slooooooow
<Mithrandir> the eft ones will be faster than the dapper ones again
<jsgotangco> wow
<ogra_> well i just see the cd (which is a pressed one) seems borked .... got a lot of seek errors 
<rodarvus> live cds need to be burned in a very slow speed (so that iso9660 correction algorithms are not called much)
<ogra_> rodarvus, tell that to the people shipping our pressed cds :) *i* know it ;)
<rodarvus> :)
<ogra_> i'm using a pressed breezy cd over here, since i have a box with some 100s lying around :)
<ogra_> but indeed i forgot to run ybin after regenerating the initramfs *sigh*
<Kamion> ogra_: if it's a pressed CD, then either it's scratched or you need to clean your CD drive's lens
<ogra_> looks like i'll have an advererous day
<ogra_> *adventureous
<ogra_> gah, cant type on that keyboard
<Kamion> (or you have a weirder problem such as a kernel driver bug, but you'd probably know about that already)
<ogra_> well, the appletouch doesnt work either with breezy ... i guess my HW is just to new for it
<TheMuso> Kamion: When you have a minute, could you point me to that bonobo/orbit/whatever patch you came up with at Paris so I can test it? If it works, I dare say it would be a likely candidate for dapper-updates.
<Kamion> TheMuso: I thought I'd already replied to you about that - it doesn't work yet, but I'm not out of ideas and will keep trying
<TheMuso> Oh ok.
<Kamion> my initial attempt caused lots of "/tmp/orbit-root has wrong owner" errors or something along those lines
<TheMuso> Oh ok.
<Keybuk> INFO:root:eel2: ubuntu is 2.14.1-0ubuntu2
<Keybuk> DEBUG:root:Allowing comparison of -1 against -0ubuntuX
<Keybuk> ... that's BETTER
<G0SUB> pitti: hello :)
<pitti> hello G0SUB!
<G0SUB> pitti: it's UTC 14:00 now I guess :)
<pitti> yep
<_ion> 02
<Seveas> \sh_away_away, are you really away?
<ogra_ibook> no, he is away away
* ogra_ibook wonders if the second one negates the first :)
<hanspeter> heya! is the libc6 package in edgy already fixed somehow?
<_ion> "away from being away"
<Kamion> wow, upgrade to edgy worked without dpkg errors. wonder if it boots
<hanspeter> Kamion: it has a libc6 issue at the moment.
<pitti> Kamion: good luck!
<_ion> kamion: Don't be greedy now. ;-)
<Keybuk> hanspeter: which issue?
<Keybuk> the locales issue appears fixed
<Kamion> hanspeter: (a) I can survive with LANG=C, (b) I can probably help fix that if I see the breakage
<hanspeter> it's not the locale issue
<hanspeter> malloc() throws around with memory-corruption-errors
<hanspeter> i cant find a solution for that. even downgrading libc6 seems not to solve it
<iwj> Kamion: mine is hosed; I'm fighting with it.
<Kamion> hanspeter: what application?
<hanspeter> Kamion: well, most applications... kde, firefox, some gnome stuff, xfce...
<Kamion> because malloc issues that appear to be in libc are often just application bugs
<Kamion> you trash the malloc arena by widdling over memory, malloc will fail later in obscure ways. use valgrind to help track that sort of thing down
<hanspeter> well, but it would be strange if they suddenly appear after an upgrade. or am i wrong?
<elmo> if they don't go away after a downgrade, I suggest you try memtest
<hanspeter> you mean it could be my hardware? well, let's see
<hanspeter> ahh, i could imagine that it's the new qt version which came today.
<elmo> firefox and gnome don't use qt
<hanspeter> yeah, i know. but how about the gtk2-qt-engine?
<ogra_ibook> gtk2-qt-engine should just die or get someone who really cares for it ...
* ogra_ibook is still bitter we shipped it in dapper
<Hobbsee> ogra_ibook: it cant die.  you will get outraged kde users if it does not ship.
<hanspeter> yeah i think qt's the problem.
<ogra_ibook> Hobbsee, then it should be fixed to not break gnome
<Hobbsee> ogra_ibook: that is true.
<hanspeter> anyone knows the exact version of the qt version before the newest? it's no longer in my archive-cache...
<ogra_ibook> the problem is that it breaks nearly all gnome apps and upstrem shows no interest in fixing it at all since two ubuntu releases
<Hobbsee> ouch
<hanspeter> never gonna install it again :)
<hanspeter> i was just too lazy to remove it in the past...
<Kamion> ok, does anyone want to test new busybox-initramfs with regard to bootability, or shall I just upload it? it works for me
<Kamion> hanspeter: launchpad.net/distros/ubuntu/+source/SOURCEPACKAGENAME should get you to the publication history for the package
<ogra_ibook> Kamion, its edgy, no ? ;)
<Kamion> I sort of like machines to keep booting even so
<ogra_ibook> well, sure, but at least yours boots, so you can fix it if we all fail :)
<hanspeter> okay, that fixed it. so libqt is broken for sure...
<Hobbsee> ogra_ibook: did you figure out that screensaver thing?
<ogra_ibook> Hobbsee, nope, not yet, i was busy with paris and afterwards i had to get ltsp in shape ... its on my list
<Hobbsee> ogra_ibook: cool :)  ping me if you want help testing it
<Hobbsee> hi bddebian 
<Hobbsee> being one of those crazy kde users, and all...
<ogra_ibook> did you file a bug about it btw ? 
<bddebian> Heya folks
<bddebian> Hi Hobbsee
<Hobbsee> ogra_ibook: about the rss-glx screensavers?  i believe there was one, yes
<_ion> What kind of problem is there with rss-glx?
<ogra_ibook> hmm, its not assigned to me ...
<Hobbsee> _ion: kde problems - you need kscreensaver-xsavers to be installed if you're running them from kde, but not from anywhere else
<Hobbsee> ogra_ibook: i'll try to find it
<ogra_ibook> please assign it to me 
<Hobbsee> ogra_ibook: lovely, dupes which i hadnt found before :)
<ogra_ibook> cool :)
<Hobbsee> ogra_ibook: they were hiding under kdeartwork, which i hadnt looked at.  will figure them out
<Hobbsee> ogra_ibook: subscribe you as hostmaster@grawert.net?
<Hobbsee> looks like there are about 4 things listed there to choose from.
<ogra_ibook> under ogra ?
<ogra_ibook> well, yes, hostmaster@grawert.net should work
<Hobbsee> ogra_ibook: right...
<Hobbsee> bug assigned to you - if you're the screensaver man, you should probably just assign yourself to that entire package, and the rss-glx too.
<ogra_ibook> well ...
<ogra_ibook> i'm subscribed to all screensaver bugs usually ...
<ogra_ibook> but if people file against kdeartwork i cant help much :)
<Hobbsee> ogra_ibook: kdeartwork is the source package for kscreensaver, and they seem to think that the bugs belong there
<Hobbsee> ogra_ibook: looking at those bugs, it seems like there's something really evil going on there that needs time and brains and testers to deal with - to make it sane.
<ogra_ibook> urgh, kdeartwork is the source for kscreensaver ? that seems pretty wrong
<Hobbsee> ogra_ibook: looks like the deps we discussed earlier would be the hacky way around it
<Hobbsee> yeah, it is.
<ogra_ibook> yep, it needs some thinking
<Hobbsee> in fact, the only kdeartwork bugs there are are for screensavers
<izm99> hey all.  Is there some way to search for project/developer by geographic location?
<Kamion> to aid in aiming the ICBMs? :)
<izm99> no no.  :P  I'm interested in collecting information on projects/developers in Vancouver, canada.
<MagnusR> .se
<iwj> root@anarres:~ # apt-get upgrade -f
<iwj> ....
<iwj> E: Internal Error, Could not perform immediate configuration (2) on libc6
<troy_s> Wasserschutzpolizei?
<ogra> troy_s, what about them ?
<troy_s> it was an ongoing source of good chuckles with the german folk at paris.
<ogra> heh
<iwj> I'm tempted to run dpkg -iGROEB on pool/main but I suspect it would be a bad idea.
<KaiL> ...some X-Server-Hackers here?
<pitti> KaiL: set({})
<ivoks> pitti: hi
<pitti> hey ivoks 
<pitti> ivoks: I didn't forget about your cups mail, btw, will deal with it soon
<KaiL> somebody should really port xorg.conf to something XML based 
<pitti> ivoks: however, I don't think we can enable browsing by default -- no open ports
<ivoks> pitti: but what open port is that?
<KaiL> this md5sum fun is really awefull
<pitti> ivoks: UDP 631
<ivoks> pitti: but dhclient opens UDP port too
<ivoks> pitti: otoh, maybe we could/should skip snmp auto discovery
<pitti> ivoks: well, dhcp only if you use dhcp
<iwj> KaiL: what md5sum fun ?
<pitti> but I agree that this has to be discussed
<iwj> Mind you I think I'm winning.
<ivoks> pitti: i don't see it as a security issue :/
<ogra> KaiL, carefull :) dont mess with iwj 
<ivoks> pitti: but i understand if other do :)
<iwj> ogra: I'm nice, really :-)
<ogra> heh, i didnt mean it that way :)
<KaiL> iwj, nvidia-glx-config seams to check the md5sum for xorg.conf - and I had now 5 people today having problems with nvidia-glx - 3 of them got a message, that the md5sum was wrong...
<KaiL> as always all of them where shure, hey "never" editied that file...
<iwj> That sounds quite insane.  But I'm afraid I don't know any of the answers.
<KaiL> well, if xorg.conf would be XML-based, setting the driver *should* be a lot easier and possible without any md5 fun
<ogra> xfree used to block dpkg-reconfigure if the md5sum didnt match for xorg.conf
<KaiL> (even better would be, if xorg would autoselect it's driver ;)
<ogra> i thought daniels worked around that
<Kamion> oh for goodness' sake XML is just a transport, saying XML-based makes as much sense as saying ASCII-based or binary-based
<Kamion> it is not difficult to parse xorg.conf in other ways
<ogra> well, the real improvement would be to have no file at all but have xorg detect everything on startup ...
<Kamion> which I'm told is not that far off
<ogra> and have it detect changes dynamically as well
<KaiL> Kamion, ok, then the other solution is to write a good parser for that file to set the values easiely seperated
<ogra> well, i once was told dexconf is the future of x 
<KaiL> ogra, ohm, yes - as more or less the whole other system does...
<Kamion> upstream's moving towards a dumb server and a configuration client
<ogra> yeah
<_ion> kail: If xorg were to use libelektra instead of XML, it would be very easy to change the settings programmatically. Oh, xorg already has been elektrified. :-) http://www.libelektra.org/Xorg
<ogra> intrestingly i doubt many users know they can have a custom xorg.conf in their homedir for example :)
<KaiL> _ion, that's what I was searching for
<ogra> our xorg already has somme nifty features ;)
<KaiL> ogra, I guess, most of them only imagine this possibility while trying a backup and wondering, why the wrong file is used ;)
<ogra> KaiL, yeah 
<ogra> thats the usual way to discover that feature *g*
<KaiL> but is it really so difficult, to get xorg to do some runtime-autodetection?
<ogra> KaiL, nope, in fact merging xorg with xresprobe would be the solution and as Kamion said there is already being stuff in the works
<wasabi__> X needs to be more dynamic At Runtime.
<wasabi__> I'd like to plug in a new card and have a new screen defined and appear.;)
<ogra> what for ? do you replace cards in running systems ? 
<wasabi__> Yes.,
<wasabi__> USB TV tuners.
<wasabi__> USB video out cards.
<ogra> and they dont work for you ? 
<wasabi__> Not a bit.
<ogra> my tv tuner card is running without setup in xine here
<wasabi__> You plug them in, sure, but X doesn't know about them until you edit a file and kill the server.
<ogra> (usb dvb-t)
<ogra> i'm not aware of any usb based graphics cards yet ... 
<ogra> and i doubt usb is fast enough
<wasabi__> http://www.xbitlabs.com/news/video/display/20040607023341.html
<wasabi__> Firewire too.
<ogra> heh, funny
<wasabi__> Notebooks with projector attachments.
<wasabi__> Same thing.
<wasabi__> http://reviews.cnet.com/VT_Book_32_MB_Graphics_Card_for_notebooks/4505-8902_7-30893185.html?tag=pdtl-list
<wasabi__> http://reviews.cnet.com/Port_Authority_2_graphics_adapter/4505-8902_7-31215806.html?tag=pdtl-list
<wasabi__> There's tons. ;)
<KaiL> ogra, very good to hear
<ogra> but still autodetection on startup would already be a major improvement beyond having a root owned config file
<ogra> for input devices and other stuff the kernel and udev take care for it already works quite well
<wasabi__> At boot, X should just ask HAL for all the display devices, and attempt to create screens on them.
<wasabi__> And basically just watch hal events.
<ogra> ++
<ogra> thats what i say since months :)
<ogra> hal is the thing !
<_ion> Well, X should just let the kernel's framebuffer interface handle the screens.
<ogra> but having a cool idea and implementing it in such a big thing as X are two different things
<iwj> Urr.  /work/Coreutils-md5sum/test-build/coreutils-5.93/build-tree/coreutils-5.93/src/touch: setting times of `d/dd': Function not implemented
<iwj> Ah, it means `you forgot to mount /proc'
<iwj> This install is still in a bad way.
<Riddell> Kamion: could you promote libavahi-compat-libdnssd-dev and libavahi-compat-libdnssd1 to main?
<Kamion> Riddell: is something about to build-depend on them?
<Riddell> Kamion: kdebase
<KaiL> ogra, any ideas, if we can have some visible results on that for edgy?
<Kamion> Riddell: done
<KaiL> at least the driver should be set automatically imho
<ogra> KaiL, ask freedesktop.org ... thats something upstream has to care for
<Riddell> thanks Kamion 
<ogra> urgh
<ogra> isnt libavahi-compat the one that was supposed to go away asap ?
<fabbione> KaiL: you clearly don't know that X does already a lot of autodetection and you clearly don't know how difficult is to set the driver right. I suggest you go and look in all bugzilla's and bug reports before asking for so simple "features"
<ogra> (at least that was what i was told when i wanted it in main for gobby)
<Kamion> ogra: that was compat-howl IIRC
<ogra> ah, yes, mixed that up, right
<KaiL> fabbione, I know, that it's quite difficult
<Keybuk> fabbione: just because it is hard, does not mean that we should not try
<KaiL> but having this code in xorg itself (and not in some config-tool makes things a lot easier, as normally nobody knows better, which driver works with which chip, as the driver authors
<ogra> fabbione, well, it *is* a simple feature if you rewrite the whole of X to use hal :)
<ogra> it just has this small drawback of rewiting X
<pitti> ogra: indeed, rewriting the whole X code appears trivially simple :-P
<zul> ogra: better start then ;)
<ogra> zul, :P
<KaiL> the most problems currently are "driver should work with this card (and so is selected by the installer), but doesn't" afaik
<ogra> the installer dosnt select graphics drivers
<ogra> xorg does that on its own through dexconf and its own postinst script
<ogra> thats why dpkg-reconfigure works to change it 
<KaiL> at least this fails rather often compared with udev selecting the right kernel module for a network card ;)
<fabbione> Keybuk: X already does that without us doing it. Try to remove xorg.conf and start X :)
<fabbione> ogra: hal would suffer the exact same issues. like pci id wants driver vesa while this other pci id wants radeon when the both cards are ati
<ogra> fabbione, well, it mostly shows the HW pretty reliable ....
<ogra> i'd point you to the hwdb to prove my words ... if there were one ...
<KaiL> fabbione, kernel modules have a list of all PCI-IDs, they support
<KaiL> why shouldn't this be possible for X-drivers too?
<fabbione> ogra: so does lspci.. it will tell you that both are ati cards.. it doesn't know about exceptions.. same reason why you need to poke manually
<fabbione> ^^ KaiL for you too
<Riddell> if infinity_ is still travelling is there anyone around who can give pack a package to the buildds?
<ogra> yeah, especially since ati just doesnt provine one driver but many
<ogra> *provide
<fabbione> ogra: i did chose ati, but can be anything
<ogra> yeah
<fabbione> that vesa <-> real driver battle applies to everything
<Kamion> Riddell: (a) infinity's not still travelling, (b) I believe Keybuk can but I'm not sure
<fabbione> like nv claims to support card foo:bar
<fabbione> but it's buggy
<fabbione> so you default to vesa
<KaiL> ATI is good example, as there are some cards with up to 4 drivers (R200-Series!)
<ogra> KaiL, but fabbione is right ... and there is nobody in this channel who is as familiar with X as he is
<KaiL> ok, fglrx is currenly not really usefull for that ;)
<ogra> so trust his words :)
<ogra> you need soe kind of AI here :)
<Kamion> the difficult bit will probably be going through all changes to dexconf etc. that have ever been made, figuring out *why* they were made, checking whether they're still relevant, and porting those changes to the drivers
<ogra> *some
<bluefoxicy> doko:  ping
<Kamion> I don't think anyone really disagrees that that should be done, but you can say "it should be done" until you're blue in the face and it will have absolutely no effect; somebody who knows X well needs to do the work
<fabbione> Kamion: not really.. most of them are still valid for X7.1
<KaiL> for the first doing one thing would solve the most problems: some tool, which sets the driver value afaik, based upon the information from dexconf on each boot - with some easy to find config option to force some driver...
<Kamion> fabbione: "not really" what? still relevant?
<fabbione> Kamion: yeah most of the dexconf stuff is still required
<ogra> KaiL, like the liveCD or ltsp do you mean ? 
<Kamion> fabbione: right, I know
<KaiL> ogra, yes
<Kamion> but it needs to be checked anyway
<bluefoxicy> gcc is doko's right?
<ogra> KaiL, that slows donw booting by several seconds
<ogra> but would be possible 
<fabbione> Kamion: yes agreed, but for 99.9% of the stuff in there, there is no way to check without hw
<KaiL> but additionally with some force-driver-option (to force "nv" even if "nvidia" is installed or to work arround buggy drivers)
<Kamion> fabbione: indeed, which doesn't make the task any easier
<fabbione> KaiL: nvidia is a buggy as nv..
<Kamion> KaiL: it's getting solved by serious X hackers upstream. I don't think inventing random tools will help us in the least ...
<KaiL> ogra, maybe it could cache it's information somehow, to shorten the time (means: if the PCI-ID didn#t change, it doesn't change the file..)
<ogra> KaiL, they are identical apart from nv having the GL stuff disabled
<fabbione> KaiL: if you are so keen to suggest a solution join #xorg-devel here on freenode
<KaiL> ogra, and having a different internal card database, afaik?
<fabbione> KaiL: all X real 3-ballz 31337 sk1llz h4x0r5 are there
<ogra> KaiL, no idea about that, i cant xray the binary blob nvidia or nv are
* KaiL hates "h4x0r5" ;)
<fabbione> KaiL: whatever.. there is where you discuss X stuff with upstream
<KaiL> at least there where times in dapper development, where "nv" failed, but "nvidia" worked (afaik "nv" has also some vesa-fallback or so?)
<KaiL> fabbione, the question is, if there shouldn't be some "helper-tool", if this problem won't get fixed in some near future upstream
<fabbione> KaiL: why don't you talk to upstream directly? what other helper tools do you want that are not there already?
<ogra> KaiL, we dont do hacks here ... if the solution takes several releases but is the right one, we'll take that path
<KaiL> currently fighting with xorg.conf is arround 90%, if not more, of the driver related problems in support chats - and if you ask people, why they don't switch from Windows, it's the xorg.conf-fun :/
<Kamion> it is being worked on upstream kthxbye
<Kamion> seriously, what's hard about this
<Kamion> hacking it even more in the distro will make the migration to a sane solution in the medium term even harder
<wasabi__> I'd be curious to read some about how upstream is working on it.
<KaiL> other topic - something positive: recent c't has compared fedora core 5, suse 10.1 and ubuntu 6.06 LTS
<ogra> wasabi__, freedesktop.org is your friend :)
<Kamion> I'm told that ajax will be giving a talk at the next x.org developer conference entitled "rm -f /etc/X11/xorg.conf" which is about this
<bddebian> w00t
<ogra> KaiL, how do we look like ? 
* ogra stopped reading c't 10 years ago
<KaiL> very interesting is the hardware detection
<KaiL> suspend to Disk worked everywhere (compared to 1/4 on fedora)
<KaiL> suspend to RAM 1/4 (fedora 1+1 with manuall changes, suse 2 with manual changes)
<KaiL> some ATI RD580 board needs "noapic"
<Kamion> the last can be dealt with if reported as a kernel bug with dmidecode output
<KaiL> except that, everything eigher worked, or was not expected to work (somebody might explain, what's so difficult in installing linux-686)
<Keybuk> Kamion: I don't seem to be able to give packages back, just rescore them
<Keybuk> giving back is an LP admin task, allegedly
<Kamion> Keybuk: ah
<Kamion> KaiL: thanks for passing those one
<Kamion> er, on
<KaiL> Kamion, you expect a usefull bugreport from somebody, who calles the missing firewall one of the biggest problems with ubuntu? ;)
<ogra> KaiL, you do that ? 
<KaiL> bzw. fedora and suse both have an SMP kernel as default...
<Kamion> KaiL: I expect it if somebody posts a comment explicitly asking them for it, yes
<Kamion> I didn't expect them to telepathically know
<KaiL> ogra, I an happy, that they found out, that LTS stands for "long term support", not "long time", so don't expect too much from them ;)
<KaiL> also interesting: suse seams to autoinstall 915resolution, if needed - maybe edgy should do that too? fabbione? ;)
<ogra> KaiL, i live around the corner of the c't tv studio now, feel free to write them a letter, i'll happily do question and answer games with them about missig firewalls :P
<KaiL> ogra, *g*
<bddebian> Loudmouth?  Some of these package names crack me up..
<hunger> ogra: They do have a point though: A packetfilter is one line of defense that ubuntu does not have (whether it is needed is a different question).
<ogra> hunger, what for if you dont have opne ports ?
<fabbione> KaiL: you are becoming highly offtopic and you are not even attempting to document yourself on what you are saying in here
<fabbione> KaiL: most of which are FAQ
<KaiL> fabbione, maybe you should find  a way, to get those authors to read the faq :)
<Keybuk> Kamion, Riddell: actually, I may be able to
<Keybuk> Riddell: what package do you need giving back?
* Keybuk notices a new "Reset build" option
<Riddell> Keybuk: kdebase please
<Keybuk> Riddell: ok, it would appear to be now "Needs Building"
<Riddell> Keybuk: great, thanks
<Kamion> it should have automatically dep-waited on the packages I promoted
<Kamion> and automatically cleared on promotion ...
<Kamion> unless that doesn't work with ogre-model problems
<Keybuk> I don't think it notices promotion
<KaiL> oh, finally something to laugh: on suse 10.1 you need 2 and a half minute (!) to search for a package (ubuntu took 2seconds ;)
<mvo> KaiL: haha :)
<Keybuk> Riddell: now "Currently building"
<Keybuk> (woohoo, I HAVE THE POWAH!)
<Riddell> you rock Keybuk 
<bddebian> heh
<Riddell> Keybuk: are your super powahs also able to get libtunepimp3 and libtunepimp3-dev through NEW into main?
<Keybuk> Riddell: yes, but I'm not processing NEW just now
<slomo> Riddell: err, libtunepimp needs mad in main again... didn't we want to leave it in universe?
<Riddell> slomo: it looks like it's in main
<slomo> right... hrm, i wonder why i thought it was in universe :) ok, then nevermind
<ogra> slomo, because we try to get mad to universe since warty, but there is always something holing it up ...
<slomo> something beeing k3b, akode and libtunepimp...
<crimsun> (which makes me wonder why xmms is still in main)
<jjesse> `but isn'txmms what people default to?
<jjesse> see the post to sounder
<ogra> crimsun, thats really strange since all gtk1 apps should be gone 
<ogra> pitti, ?
<ogra> wasnt that demoted ? 
<slomo> ogra: there's still some stuff depending on it in main
<slomo> xmms, libdv, flac, smpeg, libiodbc2
<ogra> well, i remember pitti doing a major cleanup
<crimsun> Keybuk: do you have a sec to check why my earlier upload, mplayerplug-in (circa 0930 UTC today), was blackholed?
<Keybuk> are you still having uploader troubles?
<pitti> hm?
<ogra> pitti, xmms is still in main ? 
<pitti> ogra: yes, we didn't get rid of gtk 1.2 for dapper
<crimsun> Keybuk: I haven't tried uploading again since that package
<ogra> and lots of other gtk1 
<ogra> ah, k
<slomo> and gtk1.2
<ogra> pfft and i had to drop glife 
<ogra> *the* killerapp for edubuntu 
<ogra> :)
<pitti> ogra: that was for gnome 1
<ogra> no
<pitti> ogra: and indeed we could throw out all the gdk-pixbuf, gnome1, etc. 
<ogra> that was for gtk1 and i dropped it in montreal 
<ogra> at least thats what you guys shouted at me from your BOF table while i passed by :)
<pitti> ogra: Depends: gdk-imlib1, libgnomesupport0, libgnome32, libgnomeui32, ...
<ogra> oh
* ogra shuts up ...
<pitti> imlib1 is particularly painful since dead and vulnerability prone
* pitti hugs ogra
<ogra> yeah
<ogra> thanks :)
<Keybuk> crimsun: it's in failed again
<bddebian> doh
<Keybuk> gpg: Signature made Tue Jun 27 10:17:57 2006 BST using DSA key ID C88ABDA3
<Keybuk> *sigh*
<damned> hi all
<bddebian> Hello damned
<slomo> Keybuk: do you have some time to approve my gtk2 upload to dapper-updates? mdz approved it already last friday before the upload was done
<Keybuk> slomo: please bounce the approval mail to ubuntu-archive
<Keybuk> (@lists.ubuntu.com)
<mdz> Keybuk: I think I CCed you on my reply, let me check
<slomo> Keybuk: done (and noted for the future ;) )
<mdz> yep, I did
<mdz> forwarded to -archive now
<gepatino> maybe this is not the place to ask.. but i need to modify the default initrd.gz in desktop cd and for some reason I cant make it boot after modifying it
<crimsun> Keybuk: thanks for your time.
<vdepizzol> why ubuntu don't come with banshee as default music player?
<_ion> Or ion3 as the default window manager? Or Hurd as the default kernel? Or netcat as the default web browser?
<Keybuk> why don't the Ubuntu CD packs come with a slice of cheese?
<zul> mmm...cheese
<Keybuk> A: Because nobody's proposed it yet or because the proposal was turned down.
<pitti> _ion: be my friend for s/firefox/nc/. Far, far fewer vulns :-P
<gepatino> i need to know how to properly package a new initrd.gz to make a custom ubuntu live cd
<gepatino> but cant find someone who knows the details 
<Keybuk> gepatino: what do you want to do to the poor thing?
<gepatino> move the default user ot of sudoes
<gepatino> sudoers
<Keybuk> modify the appropriate part of casper, and update-initramfs
<gepatino> the problem is that i had to modify initrd.gz by hand (unpackaging it) but cant package it in a format that the kernel could read at bootup
<Keybuk> what format are you trying to produce?
<Keybuk> it's just a gzip'd cpio file
<gepatino> i know that, but i must be missing some parameter, since it doesnt work
<gepatino> im doing: find . | cpio -cov | gzip -9 > initrd.gz
* epx is away: 10 minutinhos
<gepatino> Keybuk: do you know where i could find some info about how to package a initrd?
<_ion> epx: Thanks a lot for the information. I really appreciate that.
<Keybuk> gepatino: search the wiki for initramfs or EarlyUserspace
<Keybuk> man mkinitramfs
<Keybuk> etc.
<gepatino> Keybuk: i'll search the wikis
<gepatino> Keybuk: thanks
<bluefoxicy> pitti:  ping
<bluefoxicy> <Keybuk> why don't the Ubuntu CD packs come with a slice of cheese?
<bddebian> hehe
<bluefoxicy> Keybuk:  I'd like a CD pack with Xubuntu/Ubuntu/Kubuntu mixed :)
<bluefoxicy> (even though I hate KDE)
<Keybuk> bluefoxicy: that may be possible if we ship a DVD
<ogra> Keybuk, Kamion and infinity_ had this nice conversation about shipping ubuntu on punchcards in london ... it would be cool to have a release printed out on them and to add one to each cd :)
<Keybuk> hmm, getting used to a new mouse is damned hard
* damned wakes up each time anybody curse anything.
<Seveas> heh
<bluefoxicy> does anybody know if the current Edgy gcc 4.1 is supposed to enable stack smash protection by default?
<bluefoxicy> https://wiki.ubuntu.com/GccSsp says it will, but I don't know if it's been set up that way yet (my regression tests say it doesn't, so I just want to make sure)
<pitti> bluefoxicy: it hasn't been enabled yet
<bluefoxicy> pitti:  nod.  It'll show up in the changelog when it is right?
<pitti> bluefoxicy: yes; we need to sort out glibc for sparc before we can enable it
<bluefoxicy> ah-- wait what?
<bluefoxicy> since when does ubuntu have a sparc distribution
<Keybuk> dapper
<Keybuk> keep up ;)
<jcole> Keybuk: it's possible with a mini.iso netinstall... i've made one :)
* epx is back (gone 01:07:43)
<sivang> re all
<bddebian> Heya sivang
<bddebian> Kamion: You around?
<sivang> hi bddebian , how you been?
<bddebian> OK thanks.  You?
<sivang> bddebian: very good :-)
* sivang searches for some UDS photos links
* epx is away: novela!
<Kamion> slomo_: FYI libtunepimp3 has a separate libtunepimp3-mp3 binary split off for the libmad dependency
<Kamion> I've newed it now
<Kamion> bddebian: no - being called off to bed
<Kamion> let me know what it is and I'll deal with it in the morning
<bluefoxicy> bddebian:  hi
<slomo_> Kamion: i noticed... but it's still another package build-depending on mad and keeping it in main... and we only have 3 with this one ;)
<bddebian> Kamion: Just wondered what you meant here:  Bug #5393
<Ubugtu> Malone bug 5393 in hula "hula: merge new debian version" [Medium,Confirmed]  http://launchpad.net/bugs/5393
<Kamion> oh, build-dep, sure
<bddebian> Heya bluefoxicy
<bluefoxicy> bddebian: were you the one asking on snort-inline support and its ramifications?
<bddebian> Aye
<Kamion> bddebian: any other core-dev member should be able to explain that one
<bddebian> OK, sorry to bother you then
<bluefoxicy> bddebian:  nods.  In a few when you're not busy we can talk if you want
<Kamion> the new package ships a totally different set of binaries to the old one
<Kamion> and makes no effort whatsoever to handle upgrades
<bddebian> Ah, OK
<bddebian> bluefoxicy: Shoot
<bluefoxicy> bddebian:  I'd like to see snort with inline support because it lets the signatures be used to actually STOP attacks instead of just detect them.  There's enough work in edgy; but that would be attractive for Edgy+1
<bluefoxicy> bddebian:  i don't know the detriments of inline support, besides that 2.3 depends on some library we don't have, that's long since deprecated, to interface with iptables' "QUEUE" target; also it takes a special set of drop rules that tell it what attacks to drop
<bluefoxicy> Really I'd like to see snort 2.6 hit Debian Unstable with a fresh package based on cdbs (have you seen the snort package?  omg); as for worrying about what to do with it, well.  Everyone's busy with Edgy, so let it alone for now.
<bluefoxicy> That's about... all I know really :)
<bddebian> bluefoxicy: I guess what I am getting at is does adding --enable-inline affect binary functionality ?
<bluefoxicy> bddebian:  Besides depending on a lib we don't have?  I believe not.  lemme take a look real quick.
<bluefoxicy> (yeah, I noticed we CAN'T add --enable-inline because of that)
<bluefoxicy> http://www.snort.org/docs/snort_manual/node7.html
<bddebian> Does 2.6 have the same issue?
<bluefoxicy> I don't know.  We don't even have a 2.6 (or 2.4 for that matter) snort anyway.
* bluefoxicy reads the source tarball's build system
<bluefoxicy>   --enable-inline          Use the libipq interface for inline snort
<bluefoxicy> yeah.. and libipq is still deprecated.. wikipedia says it will be replaced by libnetfilter_queue
<bluefoxicy> bddebian:  we should probably just leave that bug open for now.  It's not pressing, it's wishlist.
<bddebian> Gah
<bddebian> OK, thanks
<bddebian> bluefoxicy: Bug #50058  :-)
<Ubugtu> Malone bug 50058 in oinkmaster "The Snort rules is no longer FREE! (Oinkmaster can't get the rules)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50058
<bluefoxicy> bddebian:  what damn!  :(
<bluefoxicy> bddebian:  oinkmaster should be able to get the registered rules... "Registered users can access rule updates 5 days after release to subscription users."  http://snort.org/rules/
<bluefoxicy> bddebian:  you do need to register to get them ;)
<bddebian> Later folks
<doko> bluefoxicy: what's your question about gcc?
<bluefoxicy> doko:  pitti got it already, I wanted to know if stack smash protection was on by default yet
<Keybuk> bluefoxicy: you were told it wasn't already
<Keybuk> and you were told why
<bluefoxicy> Keybuk:  yes that's what I said, pitti got it already.
<Keybuk> ah, sorry, misread your statement as a question :)
<Keybuk> my bad
<bluefoxicy> Keybuk:  besides, you know I have to be told more than once ;)
#ubuntu-devel 2006-06-28
<Keybuk> yes, you do love a good spanking
<dieman> screen #0:
<dieman>   dimensions:    2400x1920 pixels (655x530 millimeters)
<dieman> mmmmm
<_ion> Ooooo
<dieman> 2 24in screens rotated, and gnome isn't horking on the xinerama hints from nvidia, which is an improvement from hoary
<dieman> to dapper
<dieman> well, it was probally metacity
<HiddenWolf> dieman: man, you've got two?
<HiddenWolf> dieman: I have one of those, and I already lose my mouse pointer when I'm tired...
<dieman> heh
<dieman> yeah
<dieman> upgraded from a single core 3.4 to a dual 3.2
<dieman> too
<dieman> which is obscenely fast
<dieman> i couldn't believe how fast gnome loaded
<HiddenWolf> heh, I wait for the core2. :)
<dieman> yeah
<dieman> i actually agree with you on that, but we just do planned upgrades of labs
<dieman> so its whatever the labs are getting
<Keybuk> dieman: how long does it take to compile OpenOffice?
<dieman> thats a good question
<Keybuk> if it's < 5 hours, tell doko; he goes a wonderful shade of green
<dieman> its 'only' got 2gb of memory
<dieman> if it had like 8
<dieman> then i bet it would do openoffice quite quickly
<dieman> does OO.o build parallelise at all?
<dieman> i thought they used their own build tool
<Keybuk> yeah, it does
<dieman> awesome
<dieman> i did it once on a previous machine
<dieman> it was like 12 hours
<dieman> i think that was only a 2.8 though
<Keybuk> this did it in just over 2 hours, which I was quite pleased with
<dieman> nice
<dieman> what is it?
<Keybuk> a reasonably high-spec X2
<dieman> ahh
<dieman> nice
<dieman> we've got boxes with dual opteron dual core procs
<dieman> that could probally do it in some obscene amount of time
<dieman> with 4gb of memory
<Keybuk> the memory helps a lot
<dieman> yah
<Keybuk> dual core vs. dual proc actually appears a benefit for large compiles too
<dieman> ive got a box with 32gb of memory
<dieman> and 8 procs
<dieman> but its not up right now
<dieman> but its older opteron procs
<dieman> still, you can do it in memory then
<dieman> the wikipedia db in mysql in ram works quite well
<HiddenWolf> haha, yeah, that's a league of it's own
<Keybuk> hmm
<doko> Keybuk: you must be color-blind ;-P
<BenC> so does libc6-i386 supercede ia32-libs on amd64?
<Keybuk> doko: green with envy
<Keybuk> it's a UKish thing I guess
<LaserJock> it's not "green with envy" other places?
<doko> BenC: ia32-libs does have some extra libs, but if you only need glibc, yes
<BenC> ia32-libs is uninstallable for me on amd64 right now, so I hope it's ok :)
<Keybuk> mdz: re teardown
<Keybuk> I did it all in the BOF where we discussed it
<Keybuk> I only have to type dupload *.changes <g>
<mdz> well ok then
<mdz> fire away
<Keybuk> getting mom fed with sufficient kittens first
<Keybuk> (and should merge those first, in reality)
<jvw> Keybuk: did I understand correctly you're already bcc'ing some launchpad/ubuntu mails to the PTS's 'derivates' interface?
<Keybuk> yes
<Keybuk> the changes files of ubuntu uploads, iirc
<jvw> ah, then I must be looking at the wrong bit of the PTS 
<Keybuk> under the "derivatives" keyword, apparently
<jvw> yeah, but logging of the PTS isn't sorted by keyword, but by incoming interface :)
<Keybuk> http://wiki.debian.org/qa.debian.org/Reports/Draft
<jvw> hm, did you encounter any succesful instance of a message thusly relayed via the PTS? I might really be blind, but I can't find any instance
<Keybuk> I haven't actually, honestly, asked yet
<Keybuk> at some point I'll track down a Debian guy and get them to try it out :)
<jvw> well, I'm one of the PTS maintainers :)
<jvw> and I really do appreciate your efforts on this and like to assist getting it to work :)
<Keybuk> LP is definitely trying to send them, whether or not they're getting anywhere is another matter though
<Keybuk> they'll be coming from drescher.ubuntu.com
<zul> hey
<jvw> it does like like they're not reaching the PTS -- unfortunately I don't have access to the actual mail logs, but I do have access to the mbox getting a copy of all incoming PTS mail
<Keybuk> I don't have the mail logs either
<Keybuk> yay paranoid sysadmins <g>
<Keybuk> want me to try sending one?
<HrdwrBoB> paranoia is one of the staple food groups
<jvw> heh, partially same sysadmins as Debian :)
<jvw> sure, go ahead
<Keybuk> pick a source package
<jvw> any you like and have a patch for
<Keybuk> ok
<Keybuk> should be a mail on its way to dpkg_derivatives@packages.qa.debian.org
<jvw> got like 50 spams in the meanwhile, but not your mail yet -- sent a mail myself there, maybe master is just slow (high load, and deals with tons of mail)
<jvw> anyway, before I asked, I grepped the incoming mail for 'derivatives', and didn't find anything except you mentioning it in some bug that also got via the PTS
<Keybuk> <Znarl> 2006-06-28 00:24:09 1FvMu9-000744-P2 => dpkg_derivatives@packages.qa.debian.org R=lookuphost T=remote_smtp H=master.debian.org [70.103.162.30] 
<Keybuk> <Znarl> 2006-06-28 00:24:09 1FvMu9-000744-P2 Completed
<jvw> ok, so it's on debian's side
<Keybuk> yeah, it looks like it's going out of our smarthost (adelie.ubuntu.com)
<Keybuk> and master accepted it
<jvw> packages.qa.d.o's mail is getting processed slowly to not blow up master, so I'll wait a bit and see whether this mail did arrive
<Keybuk> I could also believe that the changes mailer isn't processing Bcc
<Keybuk> I got lost when the twisty evil code reached zope
<Keybuk> (that mail I sent by hand on the command-line, just to be sure)
<bddebian> Howdy folks
<LaserJock> hiya bddebian 
<jvw> From lp_archive@drescher.ubuntu.com Tue Jun 27 18:44:37 2006
<Keybuk> ok, so that one got through
<Keybuk> did it go to the right place?
<jvw> cool, so this worked -- and through grepping I verified I really only found this one, and no previous mail of this kind
<jvw> well, didn't check yet, but if it didn't, I can fix it
<Keybuk> right
<Keybuk> so there's definitely an e-mail channel
<jvw> fwiw, having some introductionary paragraph stating what this diff is about would be cool -- but a cosmetic thingy, getting it to work is more interesting :)
<jvw> ew, debian-dpkg@l.d.o is subscribed to that one, oh well
<jvw> (so yes, it worked)
<Keybuk> right
<Keybuk> so LP is clearly not sending them out -- but that's ok, because they're going to get sent from the mom/patches system soon anyway
<Keybuk> cause that can produce better mails
<jvw> For most people, having just a notification there was an ubuntu-upload in the first place is 90% of the interesting information already, and would be good to have at some point
<Keybuk> I'll tickle the soyuz guys when they get up to work out why those aren't getting out though
<Keybuk> right, that was the theory behind sending our changes announcements -- it was a good first step
<jvw> yup
<jvw> the mail you sent was a diff instead
<Keybuk> right, that's because I sent it with the stuff I had in front of me -- which is the stuff that will actually be able to send ubuntu3 -> ubuntu4 diffs and attach them to the bottom of the changes mail
<Keybuk> and that file was right in front of me :)
<jvw> :) -- ok, so the PTS side of things seems to work, good to know that -- feel free to ping me or buxy whenever you're ready on the ubuntu side of things
<Keybuk> will do
<Keybuk> btw, https://patches.ubuntu.com/
<Keybuk> is almost, but not quite, ready now
<jvw> woah, with spiff site layout this time :)
<jvw> https://patches.ubuntu.com/3/3ddesktop/ -> apache.conf, IndexOptions namelength=*
<Keybuk> fsvo "spiff" ... HTML is not my forte
<jvw> for values of 'spiff' equalling "not the apache default index page'
<Keybuk> yeah
<Keybuk> I've an outstanding admin request for that
<jvw> anyway, the PTS already uses that new URL, thanks to buxy, I'm not sure yet where else in debian's QA to present that info to maintainers
<Keybuk> oh, man
<Keybuk> so distracted by shiny thing in NEW
<zul> what shiny thing?
<Keybuk> libtelepathy
<Keybuk> it's a shame I have to REJECT it :'(
<zul> heh
<Keybuk> *cries*
<LaserJock> Keybuk: you mean shininess alone doesn't get a package into the archives? ;-)
<bddebian> heh
<Keybuk> LaserJock: it can do, providing the packager bothers to read the COPYING file and put the right damned licence in debian/copyright
<Keybuk> which dholbach failed to do :-/
<bddebian> Doh
<LaserJock> ouch
<Lathiat> Riddell: why is kdebase going to depend on the libdnssd stuff?
<pitti> Good morning
<Hobbsee> hi pitti 
<pitti> Hi Hobbsee 
<fabbione> morning
<Hobbsee> hi fabbione :)
<fabbione> hey Hobbsee 
<jsgotangco> morning pitti, fabbione
<Hobbsee> hi jsgotangco 
<jsgotangco> hi!
<crimsun> For MoM -- if Ubuntu changes can be dropped, I presume we follow the same protocol for requesting syncs?
<Mithrandir> crimsun: yes, if the ubuntu changes can be dropped, you request a sync.
<crimsun> Mithrandir: nifty, thanks
<fabbione> pitti: since you are into dovecot
<fabbione> pitti: want to take care of bug #51038 ?
<Ubugtu> Malone bug 51038 in dovecot "sub-folders disappear on upgrade from breezy to dapper" [High,Confirmed]  http://launchpad.net/bugs/51038
<pitti> fabbione: meh, the 'touched it last' assignment method :)
<pitti> sounds pretty upstream'ish, but I can forward it upstream 
<fabbione> pitti: no, i assigned it to me, but it seems you have been playing with dovecot quite a lot
<fabbione> so i rather prefer somebody that already know the code to touch it
<pitti> I use it on my server, right
<fabbione> so do i
<pitti> I don't know the code, though
<fabbione> but i am still at breezy
<pitti> my server is sarge :)
<fabbione> i so much had no time to upgrade my main server
<pitti> fabbione: oh, elmo's reply explains a lot
<fabbione> pitti: well it's simple..
<fabbione> breezy Maildir uses .subscription
<fabbione> dapper uses subscription
<fabbione> for no reason
<pitti> that sounds easily fixable at least
<fabbione> so we need to fix dapper in such a way that upgrade from breezy and new install from dapper will work
<pitti> looking at both sounds right
<fabbione> yes, but we need to consider some upgrade paths
<fabbione> the dovecot you uploaded in edgy.. what does it use?
<fabbione> is that .subscription change still upstream or was it a bad release?
<fabbione> somehow we need to converge with upstream on that
<pitti> hm, grab-merge.sh already wiped the source, so I'll wait until it's in the archive
<pitti> but since we do not have any patches wrt that, it's an upstream change
<fabbione> pitti: yeps thanks
<pitti> meh, why does my X crash when I try to load http://people.ubuntu.com/~mdz/anastacia.txt in firefox???
<mdke> I've heard some people have odd crashes from loading webpages using the nvidia driver
<robitaille> pitti:  that text file has a very long line of text... after getting it with wget, vi also has problem reading it...
<robitaille> oopps...forget the vi comment...user mistake :)
<pitti> yeah, I noticed; all the kernel stuff from 2.6.17
<Mithrandir> worksforme, amd64.
<pitti> Mithrandir: in firefox? I'm on amd64+nvidia drivers
<pitti> robitaille: but that wrapping you see in vim is normal
<Mithrandir> pitti: yes, in firefox.  I kinda need to reboot to get -25 in, but otherwise up-to-date
<robitaille> pitti:  I did a bad cut and paste...and did a vi on the http url :)
<lifeless> does anyone know how to tell X that resolv.conf has changed ?
<lifeless> I'm getting all X clients timeing out reading for the ICE auth socket
<hunger> lifeless: a sighup might work... dunno.
<lifeless> is it gnome-session that answers queries on it ?
<hunger> lifeless: IIRC ICE is not gnome specific.
<lifeless> sure, but that does not mean that gnome does not implement that component
<hunger> lifeless: iceauth was written by the x consortium.
<hunger> lifeless: So I guess gnome has nothing to do with it.
<lifeless> hunger: I know that to. It still does not have the imllication you are assigning to it.
<Mithrandir> pitti: reproduced with latest kernel.  Joy.
<pitti> Mithrandir: nvidia? or other driver?
<pitti> Mithrandir: bug 51180, in case you have any news (or want to confirm it)
<Ubugtu> Malone bug 51180 in xorg "X crashes when viewing a file with long lines in firefox" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51180
* pitti tries it again as LP bug attachment; brb
<Mithrandir> pitti: -23 works for me.
<Mithrandir> pitti: and yes, nvidia driver.
<Hobbsee> pitti: not sure if this helps, but i'm using the upstream firefox binaries, everything updated in dapper, and no nvidia driver, and it works here
<ivoks> it didn't crash here
<ivoks> nvidia + -25 (not amd64)
<TheMuso> np here, i386, with -25 kernel, and xorg open ATI driver.
<pitti> joy
<pitti> ivoks, TheMuso, Hobbsee: can you please add your configurations to the bug, so that we can see a pattern?
<TheMuso> Ok.
<ivoks> of xorg?
<pitti> ivoks: bug 51180
<Ubugtu> Malone bug 51180 in xorg "X crashes when viewing a file with long lines in firefox" [Untriaged,Confirmed]  http://launchpad.net/bugs/51180
<Hobbsee> added :)
<Hobbsee> that /sysinfo script is sure useful.
<ivoks> i forgot to mention that it doesn't crash :)
<Hobbsee> haha
<Hobbsee> great
<TheMuso> ?
<TheMuso> Hobbsee: sysinfo?
<Hobbsee> Sysinfo for 'sarah': Linux 2.6.15-25-686 running KDE 3.5.3, CPU: Mobile Intel(R) Celeron(R) CPU 2.40GHz at 2394 MHz (4793 bogomips), HD: 14/36GB, RAM: 643/993MB, 97 proc's, 47.22min up
<Hobbsee> TheMuso: ^ konversation script
<TheMuso> oh ok
<Kamion> hmm, anastacia output was wedgied
<Kamion> have corrected that, hopefully
<Kamion> helps if I read my drescher cronmail
<Fujitsu> Guys, I've seen that bug before.
<Fujitsu> It's around somewhere, let me find it.
<Fujitsu> It was the Nvidia driver last time as well.
<Kamion> somebody might like to take a copy of anastacia.txt if you need it to reproduce that bug#
<Kamion> since that long line should disappear in about ten minutes
<Fujitsu> There's an attached version, isn't there?
<Kamion> yep
<Hobbsee> yep
<Kamion> ok, good
<Fujitsu> Hmm.
<Fujitsu> LP just went down for me.
<Fujitsu> Everything else is fine.
<TheMuso> Fine here.
<pitti> Kamion: yes, I attacked it
<pitti> Kamion: erm, attached
<Fujitsu> Heheh.
<Hobbsee> hehehe
* Hobbsee pokes pitti with her long pointy stick.  dont attack things! :P
* pitti stands in the corner, being ashamed
* Fujitsu agrees with Hobbsee.
<Hobbsee> hehe, seems to be a lot of that going on lately.  should i scream at you next?
<Hobbsee> s/scream/get mad
<Fujitsu> Evening, Seveas.
<Hobbsee> hi Seveas 
<Seveas> mornin'
<Fujitsu> I think I found the bug that's the same as this:
<Fujitsu> 49407.
<mvo> jdub: hi! for the popcon support (sort by popcon rating) in gnome-app-install we need more popcon data. do you think we could write something on the fridge to get more users to install it?
<Mithrandir> mvo: most users have it installed, but not enabled.
<Fujitsu> 46034 is also similar.
<Mithrandir> mvo: it's part of *ubuntu-standard
<Hobbsee> bug 49407
<Ubugtu> Malone bug 49407 in xorg "Crashes Xorg server when visiting a launchpad.net page" [Untriaged,Needs info]  http://launchpad.net/bugs/49407
<jsgotangco> its already installed isn't not?
<Fujitsu> bug 46034
<Ubugtu> Malone bug 46034 in nvidia-glx "Page crashes X" [High,Confirmed]  http://launchpad.net/bugs/46034
<Fujitsu> They all involve CoC signatures (which are ultra-long lines), X crashes, and Nvidia drivers.
<mvo> Mithrandir: even better, so we just need to advertise to enable it
<Mithrandir> mvo: yup
<mvo> Mithrandir: is it just a matter of dpkg-reconfigure popcon?
<Kamion> popularity-contest, but yes
<Mithrandir> mvo: yes.  And answering "yes" to enabling it, obviously.
<Hobbsee> Fujitsu: i'd say there all the same bug, but someone like pitti should probably try the same files to check
<Fujitsu> I would assume they were all identical.
<Hobbsee> Fujitsu: i'm not an X person, but i'd probably mark them as a dupe of  bug 49407 - seems that there's a solution there too
<Ubugtu> Malone bug 49407 in xorg "Crashes Xorg server when visiting a launchpad.net page" [Untriaged,Needs info]  http://launchpad.net/bugs/49407
<Fujitsu> No.
<Fujitsu> Mark as a dupe of 46034, as it's the earliest.
<Fujitsu> I just tested the test's in some of the bugs with a friend. It crashes.
* Fujitsu marks as dupes.
<Fujitsu> *tests
<Fujitsu> Where did that apostrophe come from...
<Hobbsee> whichever - i'd mark it as a dupe of whichever had the fix or whichever was the most coherant, although they both seem to
<Riddell> Lathiat: kdebase depends on libdnssd because it includes the code for avahi support (via our patch)
<sivang> morning
<pitti> hi sivang 
* sivang hugs pitti 
<jsgotangco> sivang!
<sivang> hey jsgotangco , what's up? :-)
<jsgotangco> about to go home =)
<sivang> jsgotangco: from work?
<jsgotangco> yeah
* jsgotangco still has a 9-5 job
<Mez> infinity, ping
<Mez> or mdz, ping
<mvo> Kamion: could you please sync directfb from debian/unstable? overwrite is ok
<heno> Kamion: is gfxboot generally 640x480? 
<heno> Kamion: would the high viz menu have the standard boot prompt below it as well?
<heno> (I'm working on the graphics for that)
<Mithrandir> heno: 640x400, probably.
<heno> Mithrandir: right. And should I make separate images for the highlighted menu items? (with a box around, say)
<Mithrandir> heno: I don't think you need to, no.
<heno> ok thanks. It will look something like: https://wiki.ubuntu.com/Accessibility/Specs/LiveCdAccess?action=AttachFile&do=get&target=NewBootMenu2.png
<sivang> heno: Looks Kool
<Kamion> mvo: please file a bug on directfb and subscribe ubuntu-archive
<Kamion> heno: currently 640x480 but it will change to 640x400, as Mithrandir says
<Kamion> heno: dunno about the high viz menu yet
<mvo> Kamion: I did that yesterday, sorry for pushing, but the new cairo/gtk depends on it
<Kamion> ok, I'll do a sync run now then
<heno> Kamion: ok, thanks. if I stick to 640x400 I should be ok I guess
<mvo> thanks
<Kamion> mvo: please *subscribe* ubuntu-archive, not assign
<Kamion> mvo: if you assign, it doesn't show up on the list we use
<mvo> Kamion: *ick* I was not aware of this
<Kamion> oh, you did subscribe as well, that's ok then
<chuck> heylo
<pitti> hi zul, hey chuck :)
<Mithrandir> Seveas: you're the guy doing the -changes RSS feeds, right?
<Mithrandir> Seveas: it seems like the parser get _really_ confused with Manoj-style changelogs.
<Seveas> Mithrandir, give me a for-instance
<Mithrandir> Seveas: make-dfsg ; http://launchpad.net/distros/ubuntu/edgy/+source/make-dfsg/3.81-2 is the link.
<Seveas> Mithrandir, hmmm funky
<Seveas> Mithrandir, yes, it gets quite confused about that...
<Seveas> not too hard to fix though
<ogra> hmm, am i forced to merge a package that we always packaged from the upstream tarball directly ?
<Kamion> mvo: done
<mvo> thanks
<doko> pitti: is your change in binutils_2.16.1cvs20060117-1ubuntu2.1 still needed for 2.17?
* Mithrandir shaves a good 40 seconds off the live cd boot time.
<tseng> Mithrandir++
* pitti praises Mithrandir 
<Mithrandir> http://err.no/tmp/b/ for a couple of graphs.
<pitti> doko: hm, I cannot tell without looking
<pitti> Mithrandir: so you removed X? :-P
<_ion> mithrandir: \/
<Mithrandir> pitti: I sorted the file system. :-P
<Mithrandir> I think we should be able to get off a bunch more too.
<Mithrandir> uh, shave off some more time.
<TheMuso> Cool!
<Riddell> Kamion: I've fixed the sentence you marked on +spec/kubuntu-hwdb, I don't know if you get notification of changes the specs you've revieved
<Kamion> Riddell: thanks, bumped to pending-approval
<mdz> Mez: yes?
<tseng> morn mdz 
<mdz> morning
<sivang> morning mdz 
<ogra>        * src/gs-monitor.c: (listener_simulate_user_activity_cb),
<ogra>         (disconnect_listener_signals), (connect_listener_signals):
<ogra>         Rename Poke to SimulateUserActivity since that seems to be
<ogra>         preferred from feedback on XDG list.  How boring.
* ogra cries badly
<ogra> all apps that dont have dbus support use gnome-screensaver-command --poke in ubuntu :(
* HiddenWolf hugs ogra
<mdz> mgalvin: I just noticed that your last two UWN messages were waiting in the moderation queue for ubuntu-news
<mdz> mgalvin: mako apologizes for that
<ogra> well, they were on planet at least
<Kamion> ogra: so add an alias for that option for a while, until the callers are converted
<ogra> Kamion, i havent built it yet, not sure if that only means the dbus backend ...
<ogra> but changing that would do much harm to us ... in any case we'd have to youch all these packages again at some point
<ogra> *touch
<fabbione> Setting up dpkg (1.13.21ubuntu1) ...
<fabbione> touch: setting times of `/var/log/dpkg.log': Function not implemented
<fabbione> dpkg: error processing dpkg (--configure):
<fabbione> doh!
<ogra> mount -t proc proc /proc ?
<fabbione> righ
<fabbione> point
<ogra> :)
<fabbione> ogra: sometimes you are not completely useless :P
<ogra> haha
<fabbione> :)
<sivang> fabbione: you
<sivang> fabbione: err, you're using a chroot?
<fabbione> sivang: yes
<mdke> heno: ping?
<HiddenWolf> mdke, is there any way to get a breadcrum trail above the community docs at help.ubuntu.com?
<mdke> HiddenWolf: of pages visited? not at the moment
<HiddenWolf> too bad
<bddebian> Morning folks
<Keybuk> pitti: holy crap, that's damned weird
<pitti> Keybuk: udev or MoM?
<Keybuk> udev
<Keybuk> MoM is being weird?
<pitti> Keybuk: I mailed you about not generating a proper orig.tar.gz/diff.gz for the merged result
<Keybuk> ah, I've not read my canonical inbox yet ... I'll look into that in a moment
<Keybuk> did the merged result have conflicts?
<pitti> Keybuk: no
<pitti> Keybuk: for the ones having conflicts the behaviour seems ok to me (having the package in a single tarball)
<Keybuk> hmm, yes, I see that isn't right
<Keybuk> it hasn't given you "-sa" in the genchanges suggestion either
<pitti> I saw more examples of that, so it wasn't just a single glitch
<Keybuk> I'll debug that momentarily
<Keybuk> just as soon as I have more coffee
<Keybuk> how do you find the new format in general btw?
<pitti> Keybuk: TBH, the << == >> conflict files are somethimes confusing, since I do not see the base revision
<pitti> Keybuk: a three-way diff would sometimes help
<pitti> Keybuk: in general I prefer separate .rej files (bonus: in unidiff format :) )
<pitti> but that might just be me
<pitti> in general, today's merges went very fine with the current format
<Mithrandir> pitti: you get those if you just apply one of the .patches by hand.
<pitti> sure, but there is no 'merged' patch
<pitti> and it's not possible to generate one if there are conflicts
<Keybuk> pitti: the << || == >> thing seemed to confuse every editor I tried it in
<mako> mgalvin: about stuff on -news
<sivang> hmm, group photo went out nice
* sivang -> reboot
<jsgotangco> yes very nice indeed
<Keybuk> aha!  found the cause of pitti's mom bug
<Keybuk> I was using ${without_epoch}.orig.tar.gz  not ${upstream}.orig.tar.gz
<Keybuk> heh
<Kamion> mdke: could you update the installation guides on doc.ubuntu.com to the current version in dapper?
<Kamion> mdke: it might also be nice to add the installation guide to help.ubuntu.com
<mgalvin> mdz, mako: no worries, i blogged about them so they got some exposure
<mgalvin> mako: whats up
<mdz> mgalvin: I added your address to the whitelist, but could you post future editions using your @ubuntu.com address so that they look more official?
<mgalvin> mdz: cool, i don't have an @ubuntu :(
<mdz> mgalvin: !  why not?
<jsgotangco> ?
<jjesse> how do you get a @ubuntu.com email? just being a member right?
<Kamion> mgalvin: you should do, you're in ubuntumembers
<Kamion> mgalvin at ubuntu.com
<Kamion> jjesse: right
<mdz> Kamion: I revived seed-cleanup as non-informational considering the changes to germinate that we discussed
<Kamion> mdz: ok
<mgalvin> is it a forwarder address?
<Kamion> yes, to your preferred e-mail address as listed in launchpad
<mako> mgalvin: no, i can still send them out
<mako> or do you want to resend it w/ a message
<mako> or have me do so
<mako> it's up to you
<Kamion> yea verily choose-mirror merges are tedious unto death
<Keybuk> heh
<Keybuk> I just wrote down a list of all of the packages I touched in dapper, so I can merge them
<Keybuk> and had to get more paper
<bddebian> heh
<Hobbsee> hehe
<mgalvin> mako: i can send them out, I will do it in a moment
<mgalvin> mdz: oh, and thanks for adding me to the whitelist
<mdz> mgalvin: np
<mdz> mgalvin: ping me when you send a message from @ubuntu.com to ubuntu-news and I'll do the same for that address
<zul> mdz: ill be updating my quiet grub patch with ideas from the spec tonight
<mdz> mgalvin: I sent a test email to mgalvin@ubuntu.com
<mdz> zul: should I hand that off to you?  I'm currently the assignee but you've beat me to it
<zul> mdz: no problem
<zul> im going to be syncing grub tonight anyways..
<mdz> zul: ok, that's another I'll remove from my todo list then ;-) thanks
<zul> your welcome
<mgalvin> mdz: thanks, i got it, now i know that it actually works :)
<mgalvin> mdz: alright if i just send a test message to -news so you can set it?
<mgalvin> mdz: well, i just sent a test to ubuntu-news with my @ubuntu address and it works, thanks
<Hobbsee> mgalvin: test passed
<Hobbsee> @ the ubuntu news mailing list
<mgalvin> Hobbsee: yea thanks :)
* Hobbsee was wondering who this strange mgalvin was, and why he was emailing her.
<fabbione> Keybuk: ping?
<Keybuk> fabbione: pong
<fabbione> Keybuk: yo.. when and if you have time could you please get openais out of NEW?
<mdz> fabbione: ubuntu-cluster is already approved, and ubuntu-edgy-cluster just points to ubuntu-cluster
<mdz> fabbione: there is no need to approve it again
<fabbione> mdz: i did talk with Mithrandir for a review. I am going to cleanup the spec so that's more clear what's dapper and what's edgy
<mdz> fabbione: unless you want to split out the incomplete parts into a new spec, which might be a good idea
<Keybuk> fabbione: sure, there's a few things in NEW waiting review; I tend to do that in an hour or two
<fabbione> mdz: we did agree in having an History session or something like that..
<fabbione> Keybuk: that's fine for me.
<fabbione> Keybuk: i am in no hurry to get it in the archive, but i would prefer to avoid to have to build it manually on 6 arches for testing :)
<bluefoxicy> ubuntu's policy with screwing with the toolchain and glibc is no right?
<bluefoxicy> (eyeing up -hashvals and -dynsort .... -Bdirect has implication that can be rough on the maintainers for now)
<fabbione> bluefoxicy: toolchain changes for release foo needs to be discussed and approved during foo -1
<fabbione> bluefoxicy: approved implies also tested
<fabbione> toolchain needs to be ready for when foo opens up
<bluefoxicy> ah ok.
<fabbione> and they are the first packages to be built
<fabbione> so basically toolchain changes for edgy are already too late
<bluefoxicy> that's fine
<mdz> fabbione: that sounds fine; I made a similar comment on sparc64
<fabbione> and they have been discussed in dapper timeframe
<fabbione> mdz: thanks a lot
<bluefoxicy> it'll give meeks time to stabilize some stuff, maybe get it into actual binutils mainline, and get some inter-optimization optimizations going
<fabbione> bluefoxicy: mainline > *
<bluefoxicy> (they gave him a cvs branch AFAIK :)
<fabbione> bluefoxicy: remember one very very important detail of diverging from upstream is that makes support for us more difficult
<bluefoxicy> I know.
<fabbione> an entire CVS branch for you?? crazy..
<bluefoxicy> no not for me XD for Michael Meeks
<bluefoxicy> He's been trying to get OpenOffice.org to load faster
<bluefoxicy> along the way he's done some sort of subset of direct binding; precomputed ELF hash values of symbols (reduces L2 cache misses and avoids a big mathematical operation); and sorted symbol and relocation sections (reduces L1/L2 cache misses)
<bluefoxicy> which makes symbol binding a lot faster (this is a good thing)
<bluefoxicy> I guess Edgy+1
<Keybuk> I like the way he spends all this time trying to fix the link-loader, and doesn't fix the fact OpenOffice's build system is fucking stupid
<Keybuk> it doesn't need 300 .so files, it could have one statically linked binary
<bluefoxicy> heh
<bluefoxicy> if it had one giant library, it'd have has buckets with even more entries per bucket
<bluefoxicy> and would load even slower :P
<Keybuk> not one library
<Keybuk> one binary
<Keybuk> as in /usr/bin/openoffice
<bluefoxicy> oh
<Keybuk> no stupid .so files that nothing else uses
<bluefoxicy> that'd break address space randomization
<bluefoxicy> http://people.redhat.com/drepper/no_static_linking.html
<Keybuk> they don't _NEED_ to be .so files
<Keybuk> there's only one openoffice process anyway
<bluefoxicy> bullet point 2 :P
<bluefoxicy> heh
<bluefoxicy> It'd still be slower anyway methinks.
<azeem> Keybuk: maybe it's easier to get a branch in binutils than in OOo
<Keybuk> it's MUCH MUCH MUCH faster
<bluefoxicy> Why would it be faster
<fabbione> azeem: that's because it's easier to hack binutils than OOo :)
<Keybuk> because it doesn't need to perform any relocation (other than libc, etc.) to load openoffice itself
<bluefoxicy> oh right
<Keybuk> it doesn't need to jump through the PLT for every internal function call
<bluefoxicy> I keep thinking it'll still need to run around resolving symbols
<azeem> I didn't even know openoffice itself had loads of libraries, I assumed he was fighting the GNOME stack
<Keybuk> don't get me wrong, DSOs are a good thing when you consider an application stack like GNOME
<Keybuk> because they're actually shared between multiple applications
<bluefoxicy> yeah
<bluefoxicy> also openoffice.org doesn't really load everything at startup
<Keybuk> but building a single application, with a single binary, by splitting it into 100s of .so files and linking them all together through the link-loader and dlopen() is just MADNESS
<bluefoxicy> Meeks actually said he'd split OOo into twice as many libraries if it were feasible so he could load less stuff at startup :P
<Keybuk> that's the way Windows programs are written ("the entire application is in DLLs") not the way UNIX programs are written
<bluefoxicy> (some of the stuff is not needed immediately)
<Keybuk> which is silly
<Keybuk> if he joined it into one binary, it would be loaded optimally *anyway*
<Keybuk> as the kernel would only map the used pages into physical memory from disk
<Keybuk> unused bits of code would stay on disk
<mdz> linux incorporates 1960s technology known as 'demand paging'
<fabbione> azeem: try to do a OOo build and you will suddenly change your mind and probably reinstall from scratch because not even rm -rf / can get rid of all build-deps
<mdz> fabbione: hmm?
<bluefoxicy> fabbione:  and you start using the 'f' word yelling at doko *glances at Keybuk*
<bluefoxicy> a lot :)
<Keybuk> heh, I scared everyone in the room with that
<bddebian> heh
<fabbione> mdz: i was answering azeem about the tons of .so libs in OOo
<fabbione> Keybuk: nah.. i used to build OOo over nfs for breezy :)
<fabbione> Keybuk: 48 hours with ccache
<Keybuk> fabbione: it was just my great amusement really
<bluefoxicy> Keybuk:  besides, the advantage of what Meeks is doing is that the whole damn system gets faster.
<fabbione> Keybuk: oh yeah...
<Keybuk> I'd made a fresh i386 chroot for it on quest
<Keybuk> and did apt-get build-dep openoffice
<mdz> Keybuk: can MOM give us a status report of what has been merged in edgy and what hasn't yet?
<Keybuk> and there was a cry of "A FUCKING GIGABYTE?!  THAT'S THE ENTIRE FUCKING ARCHIVE!  DOKO!!!"
<fabbione> Keybuk: that was an rsync of archive into /var/cache/apt/archives..
<Keybuk> mdz: yes; it will be able to by the end of today
<mdz> Keybuk: you are my hero
* bddebian covers his eyes
<Keybuk> bluefoxicy: redesigning ELF so it doesn't require strcmp() would be a start :p
<bluefoxicy> Keybuk:  direct binding, precomputerd elf hashes, and dynamic symbol sorting are all in gentoo; certain gentoo users have become really attached to "ultra-fast systems" because they stopped using CFLAGS="-O99 -march=k7_stepping3_revision2 -fomit-everything -ffast-math -ffaster-math -feverything-else" and started using CFLAGS="-O2 -pipe" LDFLAGS="-Wl,-O1,-Bdirect,-hashvals,-dynsort" :P
<bluefoxicy> (nothing you do to gcc optimizations is going to make the system "ultra uber fast")
<bluefoxicy> Keybuk:  that's what -hashvals does ;)
<bluefoxicy> Keybuk:  well, not really.  It replaces a hash computation (that reads a string) with a precomputed hash value.. I guess -Wl,-O1 reduces the number of strcmp()s, and -Bdirect reduces it massively by not walking you through every library loaded
<Keybuk> neither -Bdirect -hashvals or -dynsort is in upstream binutils yet though, no?
<bluefoxicy> (direct binding binds a symbol to a DT_NEEDED entry, so the linker doesn't have to go find the library with the symbol)
<doko> Keybuk: desparately crying for OOo maintainership? ;-P
<bluefoxicy> Keybuk:  not yet, and I would be wary about using -Bdirect for a while because it has rough edges.  Meeks hasn't finished up a method to handle interposing yet
<Keybuk> doko: as I said in the team meeting, I'll happily take over OOo -- provided nobody minds my first (and last) act as maintainer being "remove-package -m '(keybuk) GET OUT OF MY ARCHIVE' openoffice.org" :p
<Hobbsee> Keybuk: haha do it :P
<Hobbsee> Keybuk: easier to get koffice in that way :P
<bluefoxicy> it seems that a lot of our programs seem to rely on interposers... i.e. 3 libs have the same symbols, the linker links you to the first lib with the symbol
<Keybuk> bluefoxicy: I know what they do :p
<fabbione> Keybuk: i think with to add a -fremove-bugs to gcc first, but the problem is that gcc upstream wants a test case for that.. i am not sure how to prove my patch work since i can't break it
<Keybuk> I follow ELF/ld stuff pretty closely ... side-effect of being the libtool maintainer for years
<bluefoxicy> ah
<Keybuk> Hobbsee: koffice is also not compliant with my vision of how an office suite should work
<Hobbsee> Keybuk: actually, that sounds rational.  who needs more than a text editor anyway?
<lifeless> fabbione: write a test that is a bug, then your patch will fix it
<Keybuk> sadly I've not yet had time to NIH my own office, so meh
<Hobbsee> keep kate and gedit, kill off the office suites!
<epx> is koffice still alive? :)
<fabbione> lifeless: that doesn't work... becuase the resulting code will be working :)
<Hobbsee> epx: i believe so
<fabbione> lifeless: and you can't prove the code was broken in the beginning
<lifeless> fabbione: he resulting code is meant to work ;)
<lifeless> fabbione: sure you can, write it faultily.
<bluefoxicy> Keybuk: I had an idea to use patricia tries for the hash buckets for symbol tables but not sure if that'll work that great.  The theory is sound (you only compare common prefixes ONCE, not once per symbol in the bucket with that prefix preceeding the symbol you need; basically the best case becomes the worst case)
<bluefoxicy> Keybuk:  the state machine to search the tree is sound, it's light weight, it's fast; building it I have not figured out (it'd be recursive), but it's possible.  The only issues I have are I'm not sure about the nature of a hash bucket; can the total data in it grow bigger than 64k, particularly
<mdz> mvo: is there an existing spec for the g-a-i improvements we discussed? specifically the .desktop file cache and the popcon sorting
<bluefoxicy> popcorn?
* bluefoxicy sorts a bag of kettle corn for mdz
<lifeless> bluefoxicy: look into (IIRC) perfect tries
<lifeless> bluefoxicy: ah right, gperf is what  I am thinking of.
<bluefoxicy> lifeless: patricia tries follow a string until two keys differ, then branches; how is that not perfect ;)
<lifeless> bluefoxicy: I know what a patricia is. Have you read up on what I referenced ? If not, I think youare just arguing for arguments sake.
<bluefoxicy> gperf is perfect hashes
<bluefoxicy> doesn't that generate hash functions?  (which can become annoyingly not perfect when you're dynamic linking, because they rely on the exact data set not to change)
<mvo> mdz: no, both are discussed in the filetypes spec, but not done seperately
<bluefoxicy> lifeless:  you could do it, but you'd need a hash function per library loaded; and then, since the linker runs through every library, you'd need to rehash each symbol you look up over and over again with each idfferent hash function
<bluefoxicy> lifeless:  which is already more CPU time than we're using now.
<lifeless> for some reason I thought it generated a variation of trie, I've just re-read its guts myself.
<lifeless> so ignore my reference.
<bluefoxicy> kay.
<lifeless> however I have another useful reference for you - hash-tries.
<lifeless> let me dig up citseseer for it
<bluefoxicy> "An ordinary trie used to store hash values"
<lifeless> I think http://citeseer.ist.psu.edu/459691.html is what I am thinking of, but I'll need to quickly read it to be sure.
<mdz> lifeless: are you happy with easy-codec-installation apart from your comment? (which was trivially addressed)
<lifeless> mdz: let me check.
<lifeless> mdz - yes it looks reasonable to me
<mdz> lifeless: thanks
<bluefoxicy> lifeless:  looks like a hash table of hash tables of tries
<mdz> Keybuk: I've set you as approver on https://launchpad.net/distros/ubuntu/+spec/easy-codec-installation since I wrote it; it's now pending approval
<Keybuk> mdz: ok, I'll look in a bit
<mdz> common-customizations also needs review
<lifeless> bluefoxicy: the HAMT structure? if you wanted a buzzword description, sure. I suggest reading the paper though, as its extremely likely to give better results than patricias tries for linker tables.
<bluefoxicy> lifeless:  any particular reason?  I'm trying to reduce the lookup time from O(s*n) to O(n) once the hash bucket is fallen into during a search; I believe (am guessing) that the hash tables themselves are simply hashed and then reduced (i.e. masked, modulused, etc) to a search space, which is turned into an array index, so the lookup of the actual hash table entry should be O(1)
<lifeless> in something like this, the golden rule is do not guess
<bluefoxicy> well I'd have to do a separate section so I could very well do it that way if I want anyway ;)
<bluefoxicy> Keybuk:  how's the elf hash table work :) (when you get a chance)
<Keybuk> how do you mean?
<bluefoxicy> <bluefoxicy> ....I believe (am guessing) that the hash tables themselves are simply hashed and then reduced (i.e. masked, modulused, etc) to a search space, which is turned into an array index, so the lookup of the actual hash table entry should be O(1)
<bluefoxicy> Keybuk:  do they generate a hash and iterate a sparse table (O(n) style) or turn it into an array index (O(1) style)
<Keybuk> O(1)
<bluefoxicy> lifeless:  :)
<bluefoxicy> Keybuk:  thanks.
<lifeless> bluefoxicy: if I can suggest, read that paper closely. from memory it is designed with processor cache size and prefetch concepts considered.
<lifeless> bluefoxicy: just twiddling the current system is often an unrewarding optimisation technique - you need to go right back and question the core algorithms. Sun wrote a nice paper on this.
<bluefoxicy> lifeless:  I have a degree to go pick up, i'll look when I get back; skimmed the paper but it looks like the search is compute hash and make a linear search (which is what we do right now)
<lifeless> bluefoxicy: then you dont understand it at all
<bluefoxicy> lifeless:  I did consider processor cache size  -->  http://sourceware.org/ml/binutils/2006-06/msg00399.html
<bluefoxicy> "To nd a given record, rst compute the keys hash. [...]  and then making a linear search to nd the correct record." page 11, 4.1.  Searching is the only operation I'm concerned with
<bluefoxicy> oh wait.  Wow I scrolled through too fast huh.  There's a lot of algorithms described here.
<Keybuk> HEALTH AND SAFETY WARNING: Do not do a Google Images search for "mom" with SafeSearch turned OFF
<bluefoxicy> XD
<bddebian> Can anyone tell me why I can apt-get update and install x11proto-gl-dev inside of pbuilder login but pbuilder build foo.dsc fails for build-dep x11proto-gl-dev?
<bddebian> Heya ivoks
<glatzor> ping wasabi
<slomo> Riddell: avahi in debian will have an /etc/defaults file soon... it's already implemented, only waits for an upload now... i'll merge back everything after it was uploaded
<Riddell> slomo: excellent
<dieman> funny, theres a dapper/multiverse/debian-installer, but not a dapper-updates/multiverse/debian-installer :)
<Kamion> dieman: neither will ever be used ...
<Kamion> well, not in dapper anyway
<dieman> Kamion: yah, i figured :0
<dieman> :)
<bluefoxicy> dapper-updates?
<dieman> i ended up writing a perl script to add a couple packages to main for myself and add a new task based on ubuntu-desktop with some packages added/removed
<dieman> its much faster than rewriting the override files and allowing apt-ftparchive crunch the entire archive :)
<Kamion> dieman: definitely
<siretart> are there only packages from 'main' on 'http://merges.ubuntu.com'?
<Kamion> I tend to use apt-ftparchive on individual packages
<dieman> yah
<dieman> im just feeding it an file list and override files for the small amount of stuff we modify that needs to be there for debootstrap
<dieman> and then it will also be handling our own dapper-local archive
<dieman> in both cases the files are kept in a seperate pool that im currently sorting out by hand
<sivang> re
<fabbione> hey guys
<fabbione> so i have heard rumors of the new X guy that will take care of edgy
<bddebian> zakame? :-)
<zul> new x guy?
<rodarvus> O_o
* fabbione packs the sodomotron for shipment to the new lucky winner
<fabbione> i will tell only under heavy payment in local beer
<bddebian> Gah, darn foreigners, too expensive to pay in beer :-)
<HiddenWolf> new x guy?
* HiddenWolf perks his ears
<zul> heh...will find out when we read the changelog
<fabbione> zul: exactly :)
<HiddenWolf> fabbione, what kind of beer do you prefer? :)
<fabbione> HiddenWolf: well i live in dk and here they produce Tuborg and Carlsberg..
<zul> isnt carlberg german?
<HiddenWolf> I thought so
<fabbione> nope.. it's danish
<fabbione> it's acutally the same company as tuborg
<fabbione> it has been bought not too long ago
<fabbione> anyway 
<rodarvus> danish beer is great stuff
<rodarvus> contrast it with the non-alcoholic brazilian beer I'm allowed to drink :)
<fabbione> why non-alcoholic?
<bddebian> Damn I hate autoconf some times
<HiddenWolf> I prefer belgian beer, really. :)
<fabbione> last time i was in .br they had alchool
* ogra makes a note to bring some bottles of german beer for rodarvus to the sprint
* sivang notes this has to be someone from the debian project , anybody know guys doing X in debian? just guess off that list :p
<bddebian> Aye, Belgium had some good beers
<bddebian> Ooohh, we are getting Overfiend?? ;-P
<rodarvus> fabbione, we do - I can't drink alcoholic beer for other reasons (had a surgery two months ago)
<zul> anything but american swill
<fabbione> rodarvus: oh well make sense :)
<HiddenWolf> sivang, the most masochistic debian-x-team member most probably. ;)
<glatzor> ping sivang
<rodarvus> it is better than no-beer-at-all, but just barely :D
<sivang> glatzor: pong
<fabbione> bddebian: don't kid too much about OF..
<bddebian> fabbione: ?  I know he was a little miffed at Debian
<fabbione> bddebian: he is a very good friend of mine
<glatzor> how are you? arrived in Israel fine?
<sivang> glatzor: yeah, sure, been a bit bumpy but otherwise cool :-)
<fabbione> bddebian: X maintainers are miffed at everything by definition...
<bddebian> fabbione: That was no slam.  Why do you seem to take everything I say negatively?  I like him.
<glatzor> sivang: I talked with mpt and we made some minor changes to the ui. but nothing drastic.
<Mithrandir> fabbione: but X is so much love!
<fabbione> bddebian: same reason i just told you :)
<glatzor> sivang: and I once again forget your repo url :)
<fabbione> Mithrandir: no, it's pure BDSM
<dieman> heh
<bddebian> fabbione: Ah :-)
<dieman> X isn't so bad
<sivang> glatzor: heh, I should put it on bazarr.l.n :-)
<dieman> after you read a few drivers worth of code
<dieman> to insert some small patch
<glatzor> sivang: let's switch over to ddesktop? it is not so crowded :)
<dieman> its all just lots of reading and thinking
<fabbione> you guys should really try to maintain X for like a year 
<dieman> yeah, no thanks :)
<sivang> glatzor: sure
<fabbione> and then i will come and visit you at the mental hospital
<dieman> heh
<dieman> i dont even want to spend the time to figure out why 945gm locks up or does other weird stuff when you try to crt/lcd
<dieman> ive never looked at x multiplatform issues either
<dieman> which i guess is a huge chunk of what nailed debian for a while
<fabbione> so how can you say that X is not that bad if you didn't look at 99.9% of its problems?
<dieman> heh
<dieman> i didn't know thats 99.9% :)
<dieman> ignorance is bliss?
<Mithrandir> fabbione: I've hacked XKB stuff.  According to at least some X people, it's the worst of the worst.
<fabbione> Mithrandir: oh yeah you have my deepest and biggest respect for that. The Family will always protect you
<fabbione> Mithrandir: but you have seen only one corner of X
<Mithrandir> fabbione: And I haven't got mad yet! :-)
<fabbione> Mithrandir: eheheh that's how it feels in the beginning..
<Mithrandir> s/got/gone/
<fabbione> see.. already the first signs of itaglish..
<fabbione> you are addicted now
<ogra> Mithrandir, in the beginning you just dont notice :P
<Mithrandir> ogra: at least I haven't started losing my apostrophes. :-P
<Mithrandir> fabbione: good thing we have fresh blood for X, then.
<dieman> yeah, i guess when I'm thinking about X its just the server and drivers, much less the rest of the system.
<dieman> and thats not very much of it
<fabbione> Mithrandir: yeah :)
* fabbione -> dinner time
<zul> mdz: ping
<slomo> Kamion: can you move nunit2.2 to main and move nunit to universe (and accept nunit from binary NEW)?
<zul> mdz: unping
<Kamion> slomo: I did the binary NEW a while back
<Kamion> slomo: for the rest, sure, is it going to be a (build-)dependency of something?
<Keybuk> mdz: errr, isn't that team meeting time somewhat off-schedule
<Keybuk> tomorrow's meeting should be in ~8 hours according to my calendar :P
<slomo> Kamion: it is already... of mono-tools (my merge from debian uploaded some seconds ago) and nant (on dep-wait because of that)
<Kamion> slomo: oh, ok, but I'm about to have friends round for dinner and the publisher is still running so I can't change overrides
<Kamion> Keybuk: can you deal with slomo's request after the publisher finishes?
<slomo> Kamion: np :) i can also send you a mail or remind you tomorrow... it's not that urgent
<sivang> hey slomo !
<Keybuk> yup, slomo: ping me in ~15 mins
<slomo> hi sivang :)
<slomo> Keybuk: ok, will do... thanks
<sivang> slomo: how was your trip home?
<slomo> sivang: nice... although i left really late for the flight i had to wait 40 minutes or something and then everything was on time :)
<slomo> sivang: and your's? how long did it take btw? :)
<mdz> Keybuk: how does your calendar work?
<slomo> infinity: please give-back banshee on i386... last try was a bit too early and a dependency wasn't there yet :) thanks
<mdz> Keybuk: when we skipped the previous meetings, we picked up the rotation where we left off, rather than skipping steps in the pattern
<Keybuk> mdz: ah, that would explain why I was out of sync then
<ogra> Keybuk, you dont use the fridge calendar in evo ? it shows the right time
<Keybuk> it's just evolution 4-weekly things
<Keybuk> ogra: the fridge calendar has too much other crap on it
<ogra> well, i cant see it anyway anymore since i use the release schedule :P
<Keybuk> ogra: you can't have _just_ the technical board meetings
<ogra> couldnt we have an additional version with only the milestone dates ? 
<ogra> i have to switch it off to see *something* in my panel calendar now 
<ogra> else the days until edgy release are simply all bold :)
<ogra> (yes i know i'm moaning)
<Keybuk> ogra: you can make your own :p
<Keybuk> I must admit, I tend to use the list at the bottom of the applet rather than the bold/not-bold bit
<ogra> i think thats what i will d, but then i'll miss changes
<Keybuk> ogra: subscribe to the wiki page?
<ogra> well, i use to look up dates for the week on monday ... 
<ogra> there the bold days come in handy
<ogra> i actually never use the evo calendar itself ...
<sivang> slomo: was good, I Liked the food on the aircraft :-)
<sivang> slomo: about 4:30 hours
<Keybuk> I've actually been _trying_ to use the evo calendar :p
<sivang> Keybuk: I had trouble setting it up
<ogra> well, i did that several times, but it never convinced me to do my day to day work
<sivang> so anyway, when is the development meeting taking place? :-)
<Keybuk> sivang: 1400 UTC ... whatever the announcement says :p
<ogra> and my todo list is still the TODO.txt file on my desktop which i edit with vim :)
<slomo> sivang: the food i got on the aircraft was rather bad ;)
<slomo> Keybuk: ping :)
<Keybuk> slomo: right, yes
<Keybuk> slomo: what can I do for you?
<slomo> Keybuk: move nunit to universe and nunit2.2 to main. some parts of main are already depending on libnunit2.2-cil and FTBFS because it's only in universe currently
<slomo> Keybuk: and nunit is a newer, incompatible version of nunit that nobody uses yet
<Keybuk> define "nunit" and "nunint2.2"
<Keybuk> which binary and source packages would you like changed?
<slomo> nunit source package to universe and nunit2.2 source package and libnunit2.2-cil binary package to main
<Keybuk> ok, done
<slomo> thanks :)
<azazello> there's a regression in acpi-support, acpi_fakekey no longer works... does anyone know about a possible fix?
<Keybuk> azazello: please file a bug
<azazello> there is one
<azazello> https://launchpad.net/distros/ubuntu/+source/kubuntu-meta/+bug/46948
<Ubugtu> Malone bug 46948 in kubuntu-meta "[Laptop Regression]  Kubuntu doesn't honour Fn Key request" [High,Confirmed]  
<azazello> and a corresponding one in debian
<Keybuk> then the bug will be soon to in time
<azazello> basically acpid no longer gets events from keypresses sent to /dev/input/event*
<azazello> seems to be a kernel change...
<azazello> or a udev change, or something
<Keybuk> *shrug*
<Keybuk> this isn't a support channel
<ogra> its likely moved into hal
<azazello> *shrug*
<azazello> I'm not asking for support. I'm actually porting this to gentoo
<Keybuk> porting to gentoo is also off-topic here
<azazello> and getting stuck because of this regression
<ogra> Keybuk, congrats for implementing the first spec :)
<Keybuk> heh
<ogra> its one i was really looking forward to ... ltsp will gain a lot of it :)
<HiddenWolf> keybuk did one already?
<fabbione> Keybuk: can you please reject openais from NEW?
<fabbione> Keybuk: i think i did something badly wrong with the packaging that not even -0ubuntu0 should ever hit archive
<fabbione> Kamion or mdz: ^^
<fabbione> thanks guys
<Keybuk> fabbione: yes, but not right now
<Keybuk> actually, you only want a reject, yes I can do that now
<fabbione> Keybuk: yes reject please
<Keybuk> fabbione: gone
<fabbione> Keybuk: sorry to be a pain but it was better gone than in
<lifeless> bluefoxicy: oh, BTW, a radix tree (trie) is -not- a Patricia - they are not synonyms. See http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/PATRICIA/ for instance.
<lifeless> a Patricia can be considered a PC trie (path compressed) trie.
<bluefoxicy> lifeless:  wikipedia said they're the same
* bluefoxicy shrugs
<bluefoxicy> http://en.wikipedia.org/wiki/Patricia_trie
<bluefoxicy> heh, Practical Algorithm To Retrieve Information Coded In Alphanumeric.  Interesting.
<lifeless> wikipedia is wrong, nuff said.
<lifeless> a patricia is a variation on the general pattern that is tries. Its true to say that 'a patricia is a trie', its not true to say that 'a trie is a patricia'.
<lifeless> The first sentence in the wikipedia article under 'overview' is in fact wrong. It says radix tree when it means patricia.
<lifeless> if you want to stick with a regular trie, you can look into LPC tries too, which IIRC are referenced from the HAMT paper.
<setuid> I'm finding it more difficult to build packages these days on Dapper, because everything is 6 months ahead. No updates to Dapper in many moons. Is Edgy stable enough to function without making my entire development machine break? 
<setuid> Or is it so much eye-candy that I'll go blind and not be able to work? 
<Keybuk> "6 months ahead" ?
<Keybuk> dapper only released three weeks ago
<setuid> I've been doing daily apt-get updates and there haven't been updates in several months now
<setuid> So it probably froze before release
<bluefoxicy> lifeless:  radix tries are?
<Keybuk> setuid: do you have dapper-updates in your sources.list ?
<Keybuk> there have certainly been updates right up until June 1st
<Keybuk> and since then in dapper-updates
<setuid> deb http://archive.ubuntu.com/ubuntu dapper-updates main restricted
<bluefoxicy> lifeless:  that link you gave me doesn't mention what a radix trie is.
<lifeless> a radix tree is a trie.
<wasabi_> Hmm. locales still broken.
<lifeless> a radix trie is not a meaningful things AFAIK
<bluefoxicy> lifeless:  yes, a radix trie is a trie in which the nodes with only single children are collapsed into their children, so "a - s - d" -> "asd", one node not 3
<lifeless> erm, radix trie means 'radix radix tree'
<lifeless> Its not meaningfull
<lifeless> what you just described is a level-compressed trie.
<bluefoxicy> http://www.ug.cs.usyd.edu.au/~cs2/dds/trie.html
<zul> later
<lifeless> bluefoxicy: dont believe everything you read. I can check TAoCP when I return home.
<lifeless> which I think is sufficiently authoritative.
<bluefoxicy> kay
<lifeless> http://en.wikipedia.org/wiki/Trie is sane, for instance. Tries are radix trees by definition.
<lifeless> (because the value of the item is the key itself)
<lifeless> in fact, that http://www.ug.cs.usyd.edu.au/~cs2/dds/trie.html link is faulty in another way, it describes a patricia, not a random trie, which is annoying if the plan is to teach people accurate terms
<bluefoxicy> every reference I've seen describes patricia/radix and trie different
<Keybuk> siretart: I wanted to make sure MoM could do multiple passes on main before it started on universe
<Keybuk> as there's pretty much a corner case in every package anyway
<lifeless> night all
<jjesse> night lifeless
<bddebian> Gah, I thought TomeRaider was a TombRaider knock-off and I was getting excited :-)
<HiddenWolf> bddebian, you like babes with guns and oversized boobs, don't you? ;)
<bddebian> moi?
* bddebian would never cop to such a thing ;-)
<HiddenWolf> what else is tomb raider about? :)
<Keybuk> Lara Croft is a Drag Queen
<bddebian> What?
<HiddenWolf> she is?
<Keybuk> yes
* bddebian 's world is shattered..
<HiddenWolf> I think that's an insult to the average drag queen. :)
<ChipX86> pfft, Lara Croft is a fictional character. Therefore, she can be anything you want her to be.. and more. But not too much more.
<HiddenWolf> lol
<Keybuk> ChipX86: oh, c'mon, you're telling me you've ever seen a real woman swing their hips like she does?
<ChipX86> I have. Have you?
* HiddenWolf sends ChipX86 a copy of leasure suit larry
<bddebian> haha
<ChipX86> that's probably the last thing I should play at work :)
<bddebian> What determines when/if you need makefile.mk?
<shawarma> bddebian: I think you only really need it if you're using a straight makefile (ie. no autotools stuff)
<bddebian> Ah, thanks shawarma
<shawarma> bddebian: np
#ubuntu-devel 2006-06-29
<theCore> which version of gstreamer will be in Edgy? any plans yet?
<HiddenWolf> theCore, probably the latest upstream stable version at that time
<theCore> ah ok, it's what I was thinking
<theCore> HiddenWolf: thanks
<Keybuk> mdz: https://merges.ubuntu.com/main.html
<Keybuk> siretart: ping
<siretart> Keybuk: pong
<Keybuk> siretart: universe merges now up
<Keybuk> mdz: https://merges.ubuntu.com/universe.html
<siretart> Keybuk: w00t! :)
<siretart> gn8
<ogra> will edgy still have gcc-4.0 available in main ?
<Keybuk> ogra: doubtful
<Keybuk> I think it's already in universe :p
<ogra> ok
* ogra prays xaos builds with 4.1 then
<zul> hey
<Evaso2> hi guys how could be debugged acpi s3 sleep mode that doesn't wake up on a fujitsu notebook for help ubuntu developping?
<ogra> mdz, ping ? 
<mdz> ogra: pong
<otavio> ogra: hi
<ogra> mdz, otavio is poking me about upstream status in ltsp and package versioning
<jsgotangco> eh? still awake?
<ogra> jsgotangco, i just megred gcompris ... uploading it takes ~2h ;)
<jsgotangco> yeah i saw the -changes list
<ogra> otavio, probably outline your idea to mdz ...
<mdz> otavio: yes?
<otavio> mdz: current way that ltsp source is now allow us to unify the development between Debian and Ubuntu
<ogra> which happens on a bzr level anyway
<otavio> mdz: I was asking ogra if we could upload to Debian and Ubuntu sync with Debian to get the versions since Ubuntu has a way to get it easily then us.
<otavio> mdz: and then we can all work on same codebase
<ogra> which again happens on a bzr level anyway ...
<mdz> otavio: it's a good idea to have a single mainline where we can all work
<otavio> yes
<otavio> mdz: that's what I want to have
<mdz> otavio: where and when it gets uploaded to distributions should be a separate issue
<otavio> mdz: since Debian doesn't allow different suite names in changes files might make our life easy
<mdz> the way this will work in the future is that the LTSP project will roll official tarballs and they will be packaged for Debian and Ubuntu independently
<mdz> however, the migration to the new codebase is not complete yet
<otavio> mdz: but currently the source is unique for both
<otavio> mdz: there's few changes on it
<mdz> so meanwhile, I suggest that ogra roll official tarballs for you
<otavio> mdz: basically debian/control only
<ogra> otavio, thats because we didnt start feature development yet
<mdz> the packaging should be kept separate from the mainline
<ogra> otavio, after the merge phase is done there will be daily changes to the source
<otavio> ogra: well but since all will be done in plugins, basically, we can follow it easier, no?
<mdz> otavio: make sense?
<otavio> mdz: so you mean that we both (Ubuntu and Debian) might use an "official" tarball as base and this to be the mainline?
<mdz> otavio: yes.  soon that tarball will be used by other projects as well
<mdz> and so we should have a separation between upstream development and packaging
<otavio> mdz: so we both change to 0.XX-Y version format?
<ogra> otavio, i mailed pkg-ltsp-devel about it 
<mdz> otavio: yes
<ogra> with links to all the specs 
<otavio> mdz: is ok to me
<otavio> ogra: I saw it
<ogra> including the tarball stuff :)
<mdz> we should start to migrate away from native packaging
<otavio> ogra: but then we both might start an upstream branch now
<ogra> otavio, no
<otavio> ogra: why?
<ogra> otavio, we both start distro branches
<mdz> it causes unnecessary complications and isn't appropriate for a project which is used elsewhere
<ogra> and have an additional upstream branch we base on
<otavio> where's the baes branch now?
<ogra> which also might contain gentoo or redhat stuff we both dont use
<otavio> is it your devel?
<ogra> yep
<otavio> ogra: please, rename it :P
<otavio> ogra: make it clear :P
<otavio> hehe
<ogra> ok, no problem
<ogra> mane suggestions ? 
<ogra> *name 
<otavio> upstream?
<ogra> fine ...
<otavio> to make it very clear :P
<otavio> and I, in Debian side, can make an upstream-fixes
<ogra> it will be "ltsp mainline" in launchpad anyway :)
<otavio> so use mainline
<otavio> so to people used in launchpad is clear
<ogra> yep
<otavio> where you'll make tarballs available?
<ogra> thats wh its not registered yet (i mentioned that in the mail as well)
<otavio> humm
<ogra> i think i'll start off on people.ubuntu.com/~ogra
<ogra> if we see everything works as expected it should move somewhere else
<ogra> humm ?
<otavio> well, do it as soon as possible so I can add a watch file to get it in an automated way
<ogra> yep
<ogra> i have 13 packages on my merge list atm ... if i'm done with these and sbalneav is up to speed with bzr (we have a crash curse tomorrow) i'll make it work
<ogra> *course
<otavio> crash course? what's it?
<ogra> an intorduction into bzr 
<mdz> ogra: just call it 'main' or 'mainline'
<otavio> will it be online and open? or will it be closed?
<ogra> well, we had an intorduction already ... rather the advanced part :)
<ogra> mdz, mainline is fine
<otavio> mdz: mainline looks better
<mdz> fine
<mdz> just not upstream :-)
<ogra> otavio, he wanted to do it via teamspeak or some voice media ... we agreed to meet in #edubuntu ~13:00 UTC
<otavio> ogra: will the course be open?
<ogra> i guess we can also do it via irc
<mdz> ogra: have you invited someone from the bazaar team?
<ogra> otavio, well i dont think i'll teach anything you dont know already, but we can hold it in a public irc channel if sbalneav doesnt mind irc
<ogra> mdz, its about the basics ...
<mdz> ogra: please ask for someone to be there
<ogra> oki
<otavio> ogra: ah ok
<otavio> ogra: i'm interested  to learn more about bzr :-D
<otavio> ogra: is always good to learn ;-)
<ogra> otavio, yeah, thats true :)
<bddebian> Heya folks
<otavio> ogra: how the branch merging in launchpad side works? 
<otavio> ogra: how the fixes and other branches will be merged there?
<ogra> otavio, i guess i'm not the best to ask about that yet i didnt use the merge stuff there yet ... #launchapd will be able to tell you
<otavio> ogra: right
<pitti> Good morning
<Hobbsee> hi pitti 
<pitti> Hi Hobbsee 
<ajmitch> hi pitti 
* pitti waves to New Zealand
<ajmitch> heh
* ajmitch is in Australia this week :)
<Hobbsee> ogra: ping?
<fabbione> morning
<Hobbsee> hi fabbione :)
<fabbione> hello there :)
<nomed> hi all
<nomed> Mithrandir, around
<Mithrandir> nomed: hi
<nomed> hi Mithrandir 
<nomed> i was reading the new specs for edgy
<nomed> LiveCDStackedFileSystem
<nomed> in particular
<nomed> i ported my initramfs scripts to use casper a while ago ..
<nomed> and they works nicely ..
<nomed> for dapper i needed to recompile the squashfs module
<nomed> as there is a critical bug 
<nomed> it doesn't support unified squashfs "layers" 
<nomed> mainly i'd like to help if possible
<Mithrandir> we're going to use unionfs, so that should still just work.
<nomed> have you already some code ?
<nomed> Mithrandir, not if u use unionfs + squashfs from dapper
<infinity> Which we won't.
<infinity> Since the spec is for edgy.
<nomed> anyway .. this is edgy  stuff
<Mithrandir> nomed: I've tested it and it worked fine for me, at least.
<nomed> infinity, yep
<nomed> Mithrandir, the issue appears randomly
<nomed> it should be explained in squashfs log
<nomed> (cvs)
<Mithrandir> well, if it's fixed it shouldn't be a problem, then
<infinity> Anyhow, tell me more about this "squashfs layers" thing?  Is that part of the squashfs driver itself?
<nomed> infinity, yes
<infinity> That may be more stable than stacking 5 unionfses...
<Mithrandir> infinity: we'd still need unionfs, though.  But yeah, we should investigate it.
<Mithrandir> nomed: care to add relevant information to the end of the spec, preferably including a link to some page explaining layered squashfs-es sans unionfs?
<infinity> Mithrandir: Yeah, given our past experiences, one union sounds less scary to me than several, that's all. :)
<nomed> infinity, http://squashfs.cvs.sourceforge.net/squashfs/squashfs/kernel/fs/squashfs/
<nomed> it seems fixed .. and i'm testing it .. 
<nomed> Mithrandir, anyway .. what i'd love to know is:
<nomed> how do u use the apt db file when u have n layers ?
<infinity> The layers have to be used in order.
<infinity> We aren't doing arbitrary mixing and matching.
<infinity> (Not in this spec, anyway.. That will take way more thought and effort)
<nomed> infinity, k
<infinity> So, on the buildds, I'll build the base layer, then mount it and build the desktop layers on top, then mount those and build the live layers on top.
<nomed> so i can continue playing with it :)
<infinity> Then mount THOSE and do the langpack layer for the DVD.
<nomed> infinity, yep .. that's what i'm doing to ..
<nomed> but i split the apt db file in many pkge.status
<Mithrandir> the dpkg db is more important than the apt lists.
<nomed> Mithrandir, yes .. i mean /var/lib/dpkg/status
<infinity> I *think* we could pull some merge-avail tricks to mix arbitrary layers, so long as we're careful not have stuff in Layer 07 dpkg-diverting files from Layer 04 and such.
<infinity> That's where it would get really messy.
<infinity> (merge-avail isn't meant to be used to merge status files, but it could be mangled a bit to do so, I'm sure)
<infinity> Anyhow, unless someone has copious free time to hack on that, I think arbitrary mixing is out of scope for edgy, and shooting for pre-ordered stacked filesystems is sufficiently cool to keep us happy until edgy+1.
<Mithrandir> infinity: unless somebody gives me a load of well-tested, reviewed code which does arbitrary mixing, we won't do it, no.
<infinity> Mithrandir: I have a general idea about how I'd do it, but I doubt I have the time to do it in work hours or the motivation to do it in my spare time.
<nomed> infinity, Mithrandir i was using layers since breezy devel version
<nomed> i was using yuch + deliver .. something similiar to casper
<Mithrandir> infinity: dpkg is just one application which would be affected, though.  Think about some crazy people making exim.squashfs and postfix.squashfs.  Those'd need to conflict.  Joy!
<nomed> now that casper exists .. and makes the job 
<nomed> i guess that's were i'd like to focus
<nomed> so if u have a guideline .. i guess i could play with it
<infinity> Mithrandir: Well, that's easy enough to deal with, really.
<Mithrandir> infinity: "don't"?
<infinity> Mithrandir: It'd have to be a two-step process anyway, since you need to read into the squash to get the status files, before you overlay them (leaving only one visible)
<infinity> Mithrandir: So, in the process of reading into the status files to merge them, you evaluate conflicts and disallow mounting those two together.
<Mithrandir> aiee.
<Mithrandir> painful.
<infinity> I knew you'd like that.
<Mithrandir> reimplement dpkg in shell.  Mmmm.
<Mithrandir> that'll be.. fast.
<infinity> Nah, this is the Killer Feature that will finally push someone to break out libdpkg. :)
<infinity> (What are you doing on the weekend?)
<fabbione> lol
<Mithrandir> Celebrating Karianne's birthday. :-P
<infinity> Well, that does sound a bit more fun...
<sivang> morning everybody!
<Hobbsee> hi sivang 
* sivang notices he still has the computer's clock on Paris time and sets it one hour forward
<sivang> hi Hobbsee !
<lucas> somebody has a script to file a "request sync" bug ?
<fabbione> sivang: luckly you still have a computer.. and a gpg key
<Hobbsee> fabbione: whatever happened to your computer?
<sivang> fabbione: my dear fabbione, what happend to your machina ?
<fabbione> Hobbsee: to my computer? nothing..
<fabbione> sivang: machina = car :) nothing yet...
<pitti> lucas: yes, I have
<fabbione> Hobbsee: sivang has a long story about gpg keys.... ;)
<pitti> lucas: http://people.ubuntu.com/~pitti/scripts/requestsync
<Hobbsee> fabbione: ahhh...right...
<pitti> lucas: it needs a local MTA, otherwise you have to change the smtp call to add a host name
<lucas> thanks
<sivang> fabbione: and the gpg key? :)
<infinity> sivang: He's referring to YOU leaving your laptop and GPG key unprotected in Montreal.
<infinity> sivang: Short memory? :)
<fabbione> infinity: so it seems :)
<sivang> infinity: nah, I recall that quite strongly. I don't think I will ever forget it :-) However, I did not create the association between what he said and this incident :p
<fabbione> infinity: to be fair...
<fabbione> "He's referring to YOU leaving your laptop and GPG key unprotected in Montreal" + and a bastard like him passing by
<infinity> fabbione: A bastard?  You?  That seems unfai-- Wait, no, that's fair. :P
<fabbione> right.. bastard inside and outside :D
<Hobbsee> haha
<ghee22> anyone familiar with mono's read & write with ubuntu?  I'm getting a very strange compile error
<Hobbsee> sivang: um, stupid question, but you didnt leave the passphrase there as well did you?
<infinity> Hobbsee: "What's a passphrase?"
<fabbione> Hobbsee: don't turn the knife in the wound... it hurt ;)
<pitti> warning to all: if you dist-upgrade edgy, make sure you do not upgrade sudo
<Hobbsee> infinity: oh holy sugar.
<sivang> pitti: interesting :)
<Hobbsee> that is shocking.
<fabbione> pitti: hem.. halt.. is it ok if i have a root passwd?
<pitti> fabbione: yes
* fabbione just finished distupgrading
<fabbione> ok
<fabbione> thanks
<Hobbsee> fabbione: sudo's broke, i believe
<pitti> fabbione: sudo is broken; I wanted to fix the merge today, but Scott uploaded the merge already
<fabbione> Hobbsee: you may never know HOW broken it is
<Hobbsee> fabbione: that's why i havent dist-upgraded yet
* pitti pats his /usr/bin/sudo.orig
<Hobbsee> i'm not sure i want to
<sivang> Hobbsee: I did not leave the passphrase anywhere near. But I suspect it was not strong enough. In either way, fabbione did not find it out IIRC, but just leaving the machine unlocked with access to gpg --edit-keys is enough to let an attacker try and break it if it's not strong enough
<Hobbsee> sivang: ah.  ouch. true.
<StevenK> Hobbsee: hold sudo, then
* Hobbsee notes that she should probably change her passphrase to something stronger.
* Hobbsee has absolutely no clue what in hell that should be though.
<fabbione> sivang: hem.. well how did i add the "You are 0wn3d" comment in your key without a passphrase?
* fabbione needs to get a short walk
<fabbione> brb
<Hobbsee> hehe - i think we scared him.
<sivang> heh
<sivang> anyway, back to productive things :-)
<jsgotangco> lol
<pitti> infinity: yay, Debian has gnutls13 and 12 doesn't build all packages any more. happy transition...
<infinity> pitti: Does everything build against 13?  I recall talking to vorlon about it a month or two ago, and they weren't going to move on 13 until the archive was happy with it.l
<pitti> infinity: no idea
<pitti> infinity: I just saw the current merge diffs and wasn't quite happy
<pitti> infinity: in fact, Debian seems to have reverted the libtasn security fix
<pitti> so we shouldn't touch our libtasn1-2 and gnutls12 packages for now
<infinity> pitti: Joy.
<pitti> (tasn broke the abi in the security fix, and gnutls12 needed a patch to cope with that)
<pitti> I need to investigate this more closely, but my feeling is that we should just wait until Debian sorted that out
<elmo> dpkg-divert: rename involves overwriting `/usr/bin/ldd' with different file `/usr/bin/ldd.amd64', not allowed
<elmo> anyone seen that during a dapper amd64 upgrade?
<jamesh> yeah
<jamesh> I think I ended up manually renaming /usr/bin/ldd.amd64 to /usr/bin/ldd
<jamesh> or deleting ldd.amd64 (whichever one was newer)
<elmo> jamesh: did you file a bug or was there already one?
<jamesh> elmo: I think there was already a bug open about it
* jamesh checks
<doko> never seen that, dapper->edgy, or breezy->dapper upgrade
<elmo> god why do we not sort distributions by popularity
<elmo> https://launchpad.net/distros/ubuntu/+source/ia32-libs/+bug/48299
<Ubugtu> Malone bug 48299 in ia32-libs "Upgrade from ia32-libs ubuntu17  to ubuntu19 fails" [High,Confirmed]  
<elmo> doko: anything I can usefully do while I still have the machine in this state?
<jamesh> elmo: https://launchpad.net/distros/ubuntu/+source/ia32-libs/+bug/45705 <- see infinity's comment
<Ubugtu> Malone bug 45705 in ia32-libs "Error in Dist-upgrade on Dapper" [Medium,Rejected]  
<elmo> which is nice, except completely untrue
<elmo> this machine is and always has been breezy only
<elmo> (or at least <= breezy)
<elmo> and always using released suites
<jamesh> seems that I deleted /usr/bin/ldd which let the thing upgrade
<doko> ia32-libs tries to remove the diversion in the preinst: dpkg-divert --quiet --rename --divert /usr/bin/ldd.amd64 --package ia32-libs --remove /usr/bin/ldd
<doko> so how does the diversion look like?
<elmo> diversion of /usr/bin/ldd to /usr/bin/ldd.amd64 by ia32-libs
<elmo> james@asuka:~$ dpkg -S /usr/bin/ldd
<elmo> diversion by ia32-libs from: /usr/bin/ldd
<elmo> diversion by ia32-libs to: /usr/bin/ldd.amd64
<pitti> Keybuk: btw, what do the different colours mean on the merging status page?
<elmo> -rwxr-xr-x 1 root root 5158 Jul 21  2005 /usr/bin/ldd
<elmo> -rwxr-xr-x 1 root root 5972 May 21 18:22 /usr/bin/ldd.amd64
<Keybuk> pitti: package priority
<pitti> ah
<infinity> elmo: Feh.  I couldn't reproduce it in a breezy chroot, doing breezy->dapper.  I'm positive the package IS still buggy, but I was fairly sure it wouldn't trip in that case.
<tseng> infinity: can you please kick muine on i386/ppc?
<infinity> elmo: Err, wait.  You have a /usr/bin/ldd owned by nothing?  That's kinda special.
<tseng> infinity: or is that more automated now
<elmo> and I am being particularly stupid, or what?   how is ldd not the diverted version?
<infinity> tseng: I'll look at 'em.
<tseng> infinity: thanks.
<Keybuk> pitti: it seemed an arbitrary way to sort and break up the table ;)
<tseng> amd64 says "chroot problem", I am asuming that is known
<elmo> infinity: oh, no it's "owned" by libc6
<elmo> but that's a lie AFAICT
<elmo> libc6: /usr/bin/ldd
<elmo> but the md5sum doesn't match the ldd of the nominally installed libc6 package
<infinity> elmo: ldd.amd64 should, I suspect.
<TheMuso> Keybuk: Are you aware that the grab-merge script doesn't work properly when attempting to unpack package sources with colons in their version number?
<elmo> infinity: ah, duh, right
<infinity> elmo: Anyhow, I think this probably warrants a release to -updates with a more correct fix (I handed one to mdz pre-release, but he deemed it too intrusive)
<elmo> infinity: ok, so you know what the fix is?
<infinity> elmo: If you can dump yout dpkg -l output to the bug log before you fix it manually (just delete /usr/bin/ldd, then continue the upgrade), that would be appreciated.
<infinity> s/yout/your/
<Keybuk> TheMuso: yes
<infinity> s/dpkg -l/dpkg -S/
<elmo> the rejected bug or the new one?
<infinity> elmo: Yeah, I know how to do it more correctly, but amunition in the form of a "me too" from you will help push the update in.
<infinity> elmo: Whichever.  Reopen the rejected one and dupe the new onr against it, if you're feeling Maloney.  Otherwise, do whatever you want. :)
<TheMuso> Keybuk: Ok.
<infinity> Ahh, good, I still have my proposed pre-release diff.
<infinity> elmo: I'll push it in to updates before I go VAC, if I get approval.
<elmo> infinity: cool, thanks
<infinity> elmo: Thanks for reminding me.  Outstanding bugs get flushed from my cache post-release.
<sivang> hi ogra 
<elmo> "There are other bugs already marked as duplicates of Bug 48299. These bugs should be changed to be duplicates of another bug if you are certain you would like to perform this change."
<Ubugtu> Malone bug 48299 in ia32-libs "Upgrade from ia32-libs ubuntu17  to ubuntu19 fails" [High,Confirmed]  http://launchpad.net/bugs/48299
* elmo stares at maone
<thom> elmo: was that english?
<Hobbsee> hey ogra. ping?
<elmo> thom: launchpadese
<jsgotangco> lol
<sivang> heh
<infinity> elmo: Yeah, Malone doesn't allow dupe chains, and I have NO idea why.
<Hobbsee> infinity: because dupe chains are evil?
<infinity> Hobbsee: Not inherently.
<infinity> Hobbsee: Assuming the UI can follow the chains, it's all the same to the end user.
<Hobbsee> infinity: that's true. 
<Hobbsee> i think.
<slomo_> hrm, my /etc/sudoers was broken by the sudo upgrade yesterday =)
<sivang> slomo_: pitti noted to not upagrade sudo some time ago. If you have a root password it's also okay IIRC
<sivang> slomo_: (that is , to hold it back)
<slomo_> sivang: i don't have one... i'll boot from a livecd now and fix it ;) brb
<sivang> slomo_: using edgy right ?
<thom> slomo_: just boot in rescue mode
<slomo_> thom: is this also possible without using the livecd? how?
<tseng> slomo_: go to grub
<tseng> slomo_: go to Your Kernel (Rescue Mode)
<tseng> it will put you in single user
<tseng> root shell
<slomo_> tseng: i use lilo because of xfs... hm, i wonder if i have an entry for that in lilo :)
<tseng> oh..
<tseng> oops
<tseng> well
<tseng> can you edit the kernel command line in lilo?
<tseng> at boot time
<StevenK> Yes.
<tseng> so add "single" to the end
<slomo_> ok, thanks
<slomo_> brb
<Kamion> woo, working anastacia
<infinity> Do I even want to look?
<infinity> Oh, that's not bad.
<tseng> I cant figure out how to unstuff sudo
<infinity> Kamion: I suspect it'll get scarier if/when hppa catches up...
<Kamion> nod
<Kamion> any updated ETA for that?
<infinity> I prodded jbailey, who's prodded upstream, who claims to have patches more or less ready, but we need some time to eyeball and run them through a test cycle.
<infinity> If I had to guess, I'd say we'd have glibc on hppa good to go in ~2 weeks.
<infinity> (But Jeff's guess would be better than mine, since I'm not directly involved in Linux/PARISC upstream)
<Kamion> The way type-handling is being pulled into main is freaky.
<Kamion> Apparently it Provides: linux ...
<infinity> It always has, though.. Hasn't it?
<infinity> Yeah, it has.
<Keybuk> is it not blacklisted?
<Kamion> nop
<Kamion> nope
<Keybuk> iirc. blacklisting was invented in germinate for type-handling
<Kamion> the version in dapper did provide linux though
<Keybuk> it kept showing up when I didn't want it to
<Kamion> (breezy's didn't)
<Kamion> never been blacklisted as far as I'm aware
<elmo> I should hack drescher's kernel to oops if it sees a file with a path of pool/main/t/type-handling
<pitti> Riddell: ping
<Kamion> as far as I can see germinate doesn't actually do anything useful with the blacklist other than reporting on it
<Kamion> could be I broke that although I don't remember doing so
<fabbione> elmo: LOL
<Kamion>             if src in self.blacklist and src not in self.blacklisted:
<Kamion>                 self.blacklisted.append(src)
<infinity> Kamion: The more bizarre thing, though, is that germinate should prefer the real "linux" package over the virtual one, no?
<Hobbsee> pitti: FYI he's speaking somewhere or other? UKUUG?
<Kamion> that's the only bit that actually cares, and it doesn't stop the package being processed
<infinity> Kamion: Is it dropping "linux" because it's uninstallable?
<pitti> Hobbsee: ah
<infinity> Kamion: Cause that's an easy fix. :)
<Kamion> oh, I suppose that could be
<Hobbsee> pitti: he said it was too bad if kde wasnt fixed by the time he left - that we couldnt have a fix :P
<mvo> Riddell: does the kde screensaver has a similar command as xscreensaver-command ? I need a way to stop it
<Hobbsee> mvo: see my note to pitti 
<Hobbsee> mvo: if you tell me what the xscreensaver-command is , i can check it for you
<mvo> Hobbsee: xscreensaver-command is a way to tell the screensaver what to do. there is e.g. -exit to stop it or -activate to make it active
<mvo> I wonder if something like this is available for kde screensaver as well
<Hobbsee> mvo: i'm not sure, nto found one, but havent looked.  screensaver fixing is on my to do list, if i can understand the stuff.
<Hobbsee> mvo: ogra's the man for screensavers i'm told
<mvo> Hobbsee: well, he is the man, but not for kde :)
<Hobbsee> mvo: true
<Mithrandir> infinity: if I give you a file which should be passed to mksquashfs -sort, can you fix that for me?
<infinity> Kamion: Hrm, no, "linux" appears to be installable in my edgy chroot...
<Hobbsee> mvo: dont think you'll find kde experts at teh moment :P
<infinity> Mithrandir: You're just going to give me a static file for now?
<Hobbsee> come on...build you stupid thing!  i have to go out!
<infinity> Mithrandir: I guess that's saner than attempting to do something dynamic.
<Hobbsee> ah ha!
<infinity> Mithrandir: Yeah, if you give it to me, I can add it to the livefs mojo.
<infinity> Mithrandir: Though you may as well TODO it and poke me on the 10th, since I don't intend to make the livefses build until I get back anyway.
<Hobbsee> good, it built
<Hobbsee> bye all!
* mvo tries kubuntu-devel
<Mithrandir> infinity: ok, sure.
<Mithrandir> infinity: it needs to be a static list.  I can generate it easily enough, but one does need to boot a live cd to make it.
<Hobbsee> mvo: good luck, it's pretty quiet there
<Kamion> ? Unknown supported package: linux-restricted-modules-386
<Kamion> I have a feeling it's forgotten about restricted somehow
<Kamion> I think I'll just ignore it for a bit and hope it goes away
<Kamion> also I'm going to exclude hppa from anastacia until it catches up
<infinity> That might make hppa require manual bootstrapping to catch up...
<Kamion> it will do anyway, I suspect
<Kamion> I've done removal passes on things that may have affected hppa
<infinity> If you start demoting stuff now, based on "nothing depends on it anymore", then build-deps will be uninstallable.
<infinity> Oh, meh.  Fair enough.
<Kamion> I wasn't planning to demote much stuff yet though
<Kamion> just promote
<infinity> I'm prepared to do some hackery.
<Kamion> we can make edgy less fat later; now it just needs to work
<infinity> Worst case, I'll need to build against dapper for a bit.
<infinity> Poor little hppa.
<Fujitsu> :(
<slomo> infinity: will you give-back all the stuff that failed on amd64 yesterday because of chroot error?
<infinity> slomo: Yes.
<infinity> slomo: I'm doing a mass give-bakc later today, just for kicks, after elmo's done upgrading the buildds to dapper.
<infinity> (which is what cause some amd64 builds to have a conniption fit)
* pitti uploads vim 7.0 and is impressed by the list of new features
<TheMuso> Mithrandir: At what stage in ubiquity do the casper ubiquity hooks get executed? I am assuming that the majority, if not all the system has been installed?
<fabbione> isn't it up already?
<fabbione> ii  vim            7.0-017+8ubunt Vi IMproved - enhanced vi editor
<Mithrandir> TheMuso: at the end, when it's been copied and all
<TheMuso> Ok.
<slomo> pitti: i already merged it yesterday evening
<slomo> pitti: sorry :(
<TheMuso> The hook script for accessibility would be almost a complete copy, except for removing some bits, and changing others.
<TheMuso> The only thing I am unsure of, is how we would get the username of the created user during the install, so we can set the gconf values for that user.
<pitti> slomo: erm? oh
<TheMuso> Is such information retrievable from a file or a variable somewhere?
<pitti> slomo: d'oh, this costed me 1.5 hours -- I should have read -changes before
<pitti> slomo: I did a lot of diff cleanp
<pitti> slomo: I'll grab yours and compare
<slomo> pitti: i merged our changes by hand into the debian package and cleaned up too... but it took me 0.5 hours longer than you ;)
<pitti> bah, we should really return to bugs for merges
<fabbione> pitti: you can merge X if you want to be the c00l k1d :)
* pitti just greps for his name on the page
<Kamion> fabbione: did you happen to keep the partman log anywhere corresponding to the fix you did in parted 1.6.25.1-1ubuntu1?
<Kamion> or file a bug or anything?
<fabbione> Kamion: let me check
<Kamion> TheMuso: db_get passwd/username
<Kamion> assuming you've done '. /usr/share/debconf/confmodule' somewhere above
<Kamion> fabbione: s/fix/workaround/ - I'd like to ditch that patch and do it properly in parted_server
<TheMuso> Kamion: Ah thanks. So I guess I should source debconf as well?
<Kamion> TheMuso: yes
<TheMuso> Yeah thought so.
<TheMuso> thanks
<fabbione> Kamion: oh the fix is 3 lines..
<fabbione> workaround i mean
<Kamion> fabbione: you said that it fails "while writing a new label", but as far as I can see that check is only performed when reading an existing label
<Kamion> I know the workaround is small, but I want to ditch it
<Kamion> it's the one remaining delta versus Debian - they incorporated your RAID patch
<Kamion> and since it should be fixable in partman, given a log ...
<fabbione> ok it's kind of tricky
<fabbione> libparted does read if the existing label is valid before writing the new one
<Kamion> nah, it's just exception handling, partman does that already all over the place
<fabbione> nah the underlaying is tricky :)
<fabbione> so what libparted does is read:
<fabbione> if valid label compare it with the one we are writing -> (where it fails)
<fabbione> and other cases..
<fabbione> no valid lable -> just write
<fabbione> so yes you can ditch the workaround and propagate the error up in the stack
<Kamion> are you absolutely sure that that is in libparted? 'cos I'm looking at ped_disk_new_fresh etc. right now and can't see any such thing
<fabbione> +++ parted-1.6.25.1/libparted/disk_sun.c        2006-02-28 10:17:29.000000000 +0100
<fabbione> this is where the patch/workaround is
<Kamion> yes, I know
<fabbione> yes
<Kamion> that code is only called when reading an existing label, and is not called when writing a new label
<fabbione> Kamion: yes and read above...
<fabbione> the code does first read
<Kamion> I did read, and it does not match the code
<fabbione> compare to what we want to write
<Kamion> which is why I asked if you were sure that that was in libparted as opposed to say parted_server or somewhere else in partman
<fabbione> let me recheck it
<fabbione> Kamion: the check is right there
<fabbione>         if (PED_BE16_TO_CPU(label->nsect) != dev->bios_geom.sectors ||
<fabbione>             PED_BE16_TO_CPU(label->ntrks) != dev->bios_geom.heads) {
<fabbione> in libparted
* Kamion bangs head against wall
<fabbione> if we trigger that condition, libparted sends an error to whatever is up in the stack
<Kamion> I see that code
<fabbione> right
<Kamion> it is in _check_geometry_sanity, which is called from sun_read
<fabbione> i don't remember what's up in the stack..
<Kamion> sun_read is ONLY called when reading an EXISTING label
<Kamion> it is NOT called when writing a NEW label
<fabbione> well the error was happening when writing
<Kamion> which is why I'm asking if you have a log
<Kamion> because the partman log should help me actually fix this
<fabbione> no i don't have a log handy
<fabbione> i can make one
<Kamion> do you still have a machine where the problem can be reproduced?
<Kamion> ok
<fabbione> i think i can reproduce it
<Kamion> thanks, that would be very helpful
<fabbione> ok
<fabbione> but i remember 2 things for sure
<Kamion> presumably with dapper you'd need to rebuild parted to switch off that workaround though
<fabbione> yeah 
<fabbione> i remember how i did test it
<Kamion> I believe you that it happens while writing a new label, but I want to know where in the stack it's failing, because as far as I can see it's not while *libparted* is writing the new label
<Kamion> so something in partman is doing the check, and I need to know what
<fabbione> Kamion: libparted sends the error to $something (parted_server??) -> $something doesn't understand the exception -> UI doesn't know what to show
* Kamion bangs head against wall again
<fabbione> Kamion: yeps.. i will get you the logs
<fabbione> that's what i remember and i am just telling you...
<Kamion> the question is what is calling the function in libparted that generates the exception
<fabbione> no need to bang your head on a wall
<Kamion> I know how libparted->partman exception handling works, there's no need to explain it :)
<fabbione> in this case it doesn't because partman doesn't understand this exception
<fabbione> or at least not in full
<Kamion> indeed
<fabbione> but i will get you the log and everybody will be happy
<Kamion> that's what I want to fix
<fabbione> perfect
<Kamion> since your changelog indicated that it should be fixed once we were out of deep freeze
<Kamion> so I hear and obey :)
<fabbione> yes and you are right :)
<fabbione> davem was just considering a full rewrite of libparted
<fabbione> for sparc at least
<fabbione> since "sucks" can't describe it in full
<mjg59> libparted needs "fixing" for Apples
<fabbione> Kamion: how urgent is this thing?
<Keybuk> I've often wondered whether Intel's new name for the Pentium was influenced by Apple
<Kamion> mjg59: isn't that just the HFS+ journal byte-swapping business?
<Kamion> fabbione: not very, just not to be forgotten
<Kamion> I may be able to zen it
<Keybuk> "Apple Core" is just too perfect to be a coincidence
<Treenaks> Keybuk: if that's true, the 'iTanium' was meant for apple too ;)
<fabbione> Kamion: ok, i have my machine busy today to test a gcc fix that should allow doko to unleash ssp in edgy. i will try to get to it sometimes tomorrow
<Kamion> fabbione: oh, cool, thanks
<fabbione> Kamion: also because i need to powerup the SAN to get to the solaris partition layout that trigger the problem
<Kamion> fabbione: I'll sync parted and deal with the ABI change uploads following that then
<fabbione> Kamion: ok perfect
<sivang> Keybuk: what is Apple Core?
<Treenaks> sivang: the thing that's in the middle, the part that most people don't eat.. with the seeds in it
<sivang> heheh
<sivang> Treenaks: better not eat the seeds, their full of Cyanid, and frequent dosage of those can cause raspatory blocks
<mjg59> Kamion: That, plus it needs to sync MBR and GPT partition tables
<mjg59> (Which breaks the GPT spec)
<Kamion> fabbione: filed bug 51289 about this and targeted it to edgy since it'd be a regression otherwise
<Kamion> fabbione: if you could attach your log to that once you have it, that'd be perfect
<infinity> pitti: Is there an ETA on that "sudo that doesn't suck" upload?
<infinity> pitti: (Not that I care, I'm still running dapper, but others seem to care more)
<pitti> infinity: I'm on it, but it's a fairly tricky one. I'm currently in the depths of yacc code and processing to find out what goes wrong
<pitti> infinity: expect a fix by the meeting
<infinity> pitti: Thanks, dude.
* pitti bites in the table and hits bison over the head
<sivang> bah, deptch of yacc..
* sivang hugs pitti 
<pitti> yay, it works now
<pitti> hi ivoks 
<jsgotangco> hey
<ivoks> hi all
<ivoks> what works? :)
<pitti> ivoks: sudo
<ivoks> oh...
<ajmitch> pitti: yay! :)
<Fujitsu> How long until it's uploaded?
* pitti uploads now to calm the crowds, and decides to clean up environment handling later.
<ivoks> it didn't work before? :)
* Fujitsu applauds pitti.
<Fujitsu> ivoks, not in edgy, no.
<ivoks> ah, /me is too busy with exams on faculty, so i didn't upgrade edgy for couple of days
<zul> hey
<pygi> ivoks, morning :)
<fabbione> Kamion: ok thanks
<ivoks> pitti: what's with hplip in dapper?
<pitti> ivoks: -v please
<ivoks> pitti: well, hplip in dapper was release almost a year ago
<ivoks> pitti: there were newer version, but we didn't include them
<Keybuk> do you mean "why hasn't hplip in dapper been updated?"
<ivoks> yes
<Keybuk> http://merges.ubuntu.com/h/hplip/REPORT
<ivoks> thanks
<Keybuk> ^ Feel free to grab the files there and do the merge for somebody
<ivoks> will do
* Keybuk wonders why that has "C " for png files
<StevenK> Keybuk: How often does MoM peer at the archive? IE: will it notice the stack of syncs and dump them out of the list?
<Keybuk> StevenK: yes.
<Keybuk> it peers at the archive whenever I run it :p
<Keybuk> if there is no "merge" for a package (which is true if it is syncd) then it cleans up the merge directory so it doesn't appear in the list anymore
* StevenK nods.
<StevenK> Keybuk: How long does it take to run?
<Keybuk> I don't know yet
<Keybuk> I've not done a "pulse run" yet
<Keybuk> it takes about 6 hours to do a rebuild run
<StevenK> Ah. You've only the "ohmigod it hurts" first run?
<Keybuk> I've done a first run, and a couple of "redo everything again" runs
<StevenK> MoM is all Python?
<tseng> mom was just rewriten
<Keybuk> yes
<StevenK> I know that.
<Keybuk> I've been thinking what to call it
<Keybuk> there's a lot of jokes available with the term "new mom"
<Keybuk> "she loves you just as much as your old mom"
<StevenK> Heh
<StevenK> Keybuk: Well, you can't call it Britney. :-P
<tseng> is there a Stepahie?
<Keybuk> I haven't been able to backronym "step-mom" yet
<StevenK> Keybuk: Julia
<tseng> we could buy a book of "names for baby girls" to name new infra projects
<Keybuk> tseng: we've been abandoning that
<StevenK> Awwww.
<StevenK> elmo stopped loving girl celebs?
<Keybuk> amusingly, the first set of "new mom" tools had boys names just as a rebellion against the katie suite
<tseng> oh, they are celebs?
<StevenK> Keybuk: Please tell me one of them wasn't called justin or kevin?
<_ion> justin time
* StevenK glares at _ion
<_ion> i.e. almost late
<Keybuk> StevenK: one was called justin, yes
<StevenK> Eek
<Keybuk> I got bored with that though, because I forgot what each one did when there were just three of them
<StevenK> Hah
<pitti> Keybuk: can I please have http://patches.ubuntu.com/patches back?
<Keybuk> pitti: where did it go?
<pitti> I don't know :)
<Keybuk> merge@casey:/srv/patches.ubuntu.com/published$ cat .htaccess
<Keybuk> # Patches manually attached to the BTS
<Keybuk> Redirect /patches/ http://people.ubuntu.com/patches/
<Keybuk> hmm
<Keybuk> oh, I know
<Keybuk> nope, that didn't work either
<Keybuk> bet someone disabled redirects
<StevenK> Keybuk: RewriteEngine On? :-)
<Keybuk> StevenK: no idea, it worked the other day
<infinity> You don't need mod_rewrite for Redirect{,Match}
<StevenK> Not sure if that even works in .htaccess
<Keybuk> one of the admins must have been fiddling
<infinity> If the FileInfo override has been disabled in that directory, it won't work.
<infinity> Or if mod_alias is disabled (seems unlikely)
<mvo> iwj: here? I'm pondering about your comment in AlwaysEnableUniverseMultiverse about making apt-get show something about the unsupported nature of the install
<infinity> Anyhow, better to have the Redirect in the vhost config anyway, not in .htaccess, so I'd just RT it and ask elmo to put it in the Right Place.
<Keybuk> infinity: mod_alias has been disabled
<infinity> Keybuk: Oh, hah.
<infinity> Keybuk: A great argument for asking elmo to put it in the vhost conf for you, since apachectl will SCREAM if you start with an unsupported directive in the conf. :)
* Kamion notes that soyuz doesn't have katie's check for "Changed-By field mentions YOUR MOM"
<StevenK> Heh
<Kamion> who uploaded the cyrus21-imapd merge?
<Keybuk> \o/  my VoIP hard-phone arrived
<mjr> SIP?
<Keybuk> aye
<infinity> signature from "Martin Pitt <martin@piware.de>
<mjr> good on you
<infinity> Tsk, tsk.
* StevenK ponders borrowing a SIP phone from work.
<infinity> pitti: Naughty.
<pitti> infinity: ?
* StevenK peddles faster so that xemacs21 can build faster.
<ogra> pitti, you pretend to be our mom
<Keybuk> and this is now the second device I've got where the presentation of the power supply is a USB-2 plug
<ogra> pitti, Von: 	Ongoing Merge Process <mom@ubuntu.com>
<ogra> Betreff: 	Accepted cyrus21-imapd 2.1.18-3ubuntu1 (source)
<pitti> ooh, that
<Keybuk> maybe, at last, we're starting to see a standard connector?  (hopes)
<pitti> yes, sorry for that
<StevenK> Keybuk: Nah!
<ogra> pitti, nah, i'm always happy to get mail from mommy ;)
* StevenK wishes he could set his primary mail address in LP to his @u.c address.
<tseng> I wish that also, but as it is a forward
<tseng> based on the primary field
<tseng> tricky problem.
<StevenK> Oh crap, I haven't prelink'd ooo on this machine.
<TheMuso> Keybuk: Is there a reason Mom doesn't use packages from dapper-updates?
<Keybuk> because those packages are not in edgy
<Keybuk> this should hopefully force people to realise that uploads to dapper-updates _do_not_affect_edgy_
<TheMuso> hmm ok
<TheMuso> I knew that re dapper-updates packages not effecting edgy.
<G0SUB> jsgotangco: hello!
<TheMuso> I ask because I patched a package in universe for dapper-updates, and noticed that those changes weren't included in the merge files.
<jsgotangco> G0SUB: hey dude
<G0SUB> jsgotangco: how are you?
<G0SUB> jsgotangco: can I PM you?
<jsgotangco> G0SUB: go ahead
<iwj> mvo: Hi.
<iwj> (sorry, I was eating)
<iwj> mvo: You mean my comment about command-line users ?
<mvo> iwj: yeah, I'm pondering how to do it without permanently annoying them with a nag-line like "the following packages are unsupport, do you want to continue"
<ajmitch> mvo: <blink> tags :)
<iwj> You could treat it like the dependency resolution prompt perhaps ?
<iwj> Ie, mention it as   The following UNSUPPORTED packages    or some such and then say [Y/n] .
<iwj> But I'm not sure how easy that would be to do.
<mvo> coding it shouldn't be hard, I guess that is the way to go
<iwj> Or you could ask a question on the first run of commandline apt-get.
<Keybuk> TheMuso: the easiest way to get them included would be to patch the edgy package as well
<Keybuk> interestingly, new-mom is sufficiently generic that I could do a dapper-updates/edgy merge <g>
<Keybuk> it might be a fun attempt
<TheMuso> Keybuk: thats what I am going to do. Was just wondering.
<StevenK> Can some kind soul remove my aborted upload attempt of xemacs21?
<infinity> No need to remove it.
<infinity> If you uploaded an incomplete upload it'll just fail and carry on.
* StevenK notes his link to upload.u.c is suffering from 30% packet loss and sighs.
<sivang> mdz: thanks for setting my specs back to reivew, I confused and set them to pending approval..
<sivang> mdz: (to request more review)
<Hobbsee> infinity: a life?  what's that crazy thing you speak of?  :P
<Mithrandir> Hobbsee: it's pink with blue spots.
<Mithrandir> moves quite quickly and is hard to catch
<ajmitch> ah
<Hobbsee> Mithrandir: ah right
<ajmitch> sounds rather elusive
* ajmitch had better get a bit of stuff cleaned up this week & next
* Hobbsee pokes ajmitch into doing some merging.
<ajmitch> Hobbsee: none of that, thanks
<Hobbsee> no?
<Hobbsee> ajmitch: who'd that get assigned to instead?
<ajmitch> no
<ajmitch> the other MOTUs handle all the merging
<Hobbsee> ah, right, so you just sit and be lazy, or boss them around, fixing REVU at times when it breaks.
<ajmitch> except for stuff I care about, need, or have time for :)
<ajmitch> no, I do coding & other packaging
<ajmitch> stuff that's not uploaded yet
<Hobbsee> right
<pitti> Keybuk: do you expect any problems if dash gets the default for < breezy dist-upgrades? it's working fine here for ages
<Keybuk> how do you mean?
<Keybuk> (discuss after)
<pitti> Keybuk: since mdz seemed to worry about getting that change on upgrades
<Keybuk> I thought mdz was oppositely worried; in that people with dash already installed _wouldn't_ get the /bin/sh change?
<mdz> Keybuk: correct
<pitti> oh, ok; well that would break even less...
<mdz> (meaning it will get less testing)
<mdz> the sorts of people who are running edgy probably already had it installed
<Keybuk> right ... it needs me to get out "Debconf for Dummies" and change the value of the existing default :)
<Keybuk> do I anticipate any problems with it being /bin/sh in general?  no, because almost everyone I spoke to had already done it themselves anyway :p
<Mithrandir> Keybuk: DfD, aka debconf-devel(7) :-P
<Keybuk> and Nokia have provided hundreds, if not more, patches to Debian
<Keybuk> Mithrandir: Kamion was amazed that, in all my years in Debian, I'd managed to completely avoid touching debconf :p
<pitti> Keybuk: I did some debconf hacking (including db_set), feel free to ping me for questions
* Kamion doesn't particularly like hammering over the existing value set in debconf
<Kamion> there's no way to tell whether it's been explicitly set
<Kamion> however, if you do, make sure it's in an upgrade clause guarded by dpkg --compare-versions
<Keybuk> Kamion: that was the reason I didn't change it ... I didn't realise we'd ever shipped dash ourselves
<Kamion> BenC: re libata-for-all-ata-disks, I'd very much like partman-target to use uuids before you go ahead with the kernel change
<Kamion> otherwise the upgrade is more complicated
<BenC> Kamion: ok, so upgrade needs base-files, boot loaders, and partman?
<Kamion> right
<Kamion> er
<Kamion> fresh install needs partman
<Kamion> but don't want to do the upgrade handling until fresh installs are right, otherwise there's no sane version to pick to key the upgrade off
<Kamion> Keybuk: ^--
<Keybuk> right
<Keybuk> we'll keep them blacklisted until the migration stuff is in place
<BenC> yeah, atleast then ppl can manually enable them for testing
<BenC> and I might actually send out an email requesting that, see if we can spot some problems in advance
<BenC> Keybuk: I am going to send a list of libpata modules I am enabling, and each one will show the matching IDE module
<BenC> so you can create the blacklist like:
<BenC> blacklist pata-foo
<BenC> # blacklist ide-foo
<BenC> or similar
<Keybuk> indeed
<Keybuk> real    34m44.593s
<Keybuk> hmm
<Keybuk> that's encouraging
<Keybuk> we could run mom every hour :p
<pitti> Keybuk: running it more than once a day would indeed be helpful, given the current merge pace
<Keybuk> I've set it to every 6 hours at the moment
<pitti> yay
<Keybuk> I'm completely unconvinced cron is running on casey though <g>
<pitti> ogra: oh, dhcp3 is currently on my merge list; if you want to merge it, I'll ignore it
<ogra> pitti, as you like just dont forget to supress next-server :)
<infinity> ARGH.
<infinity> Who merged cpio?
<Hobbsee> infinity: whoever did broke it, and that's why visudo is also failing.
<infinity> Oh, wait, that's not a merge, it's a sync.
<infinity> Awesome.
<Kamion> "cpio" != "sudo"
<infinity> cpio broke my chroots.  All of them.
<infinity> I'm so thrilled.
<Kamion> how did cpio break visudo?
<Hobbsee> Kamion: according to the build logs, that's what it failed on, from what i can see
<pitti> ogra: no idea what's that about
<Kamion> Hobbsee: oh that'll just be breaking everything, not sudo in particular
<infinity> Keybuk: Please merge cpio/2.6-15 ASAP, I may need to manually bootstrap it.
<Hobbsee> Kamion: ah great - that's the only one that i was looking out for :P
<ogra> pitti, debian forces usage of the next-server option, we patched that out because it breaks existing ltsp setups
<Kamion> infinity: I'll do netcfg, although you have the touched-it-last bit
<Kamion> I have it in bzr and stuff
<pitti> ogra: since I did a fair bit of hacking in DHCP, I propose that I do the initial merge and then give you the package for testing and polishing
<pitti> ogra: (that said, I'd be happy if you did the merge yourself, I just stick to the default assignee in the merge list :) )
<infinity> Keybuk: s/merge/sync/
<ogra> pitti, fine with me, just make sure to not upload something with next-server in it, it resulted inn a ton of howtos in dapper i still have to fight
<pitti> heh, ok :)
<Keybuk> infinity: *confused*
<Keybuk> there is no sync?
<infinity> Keybuk: incoming, perhaps.
<Keybuk> will look
<infinity> Yeah, it's in incoming.
<infinity> -14 has a broken preinst.
<infinity> I'm going to work around it in the chroot tarballs so the world stops breaking.
<infinity> But we need that sync to not break everyone else.
<Keybuk> infinity: I think that _may_ have just made the publisher run
<pitti> btw, archive admins: thanks for the fast responses to sync bugs!
<tseng> pitti: yes seriously
<tseng> they are rocking
<tseng> Kamion rocks on NEW also
* Kamion bows
* ajmitch should file his syncs now while he has a chance
* Keybuk feels meek and under-performing in the might of Kamion's shadow
<pitti> ajmitch: you know the requestsync script, right?
<ajmitch> pitti: yep
<ajmitch> pitti: I need to check which ones need the sync first
<bddebian> Heya
<infinity> Okay, buildd chroots rescued, mass-give-back pending the next queuebuilder run at :50
* fabbione sighs at gcc testuite
<zul> hey fabbione 
<fabbione> hey zulligno
<infinity> And that's my last good deed for the day.
<infinity> 'Night, folks.
<Hobbsee> night infinity.  thanks for fixing the world.
<sivang> infinity: night dude
<bddebian> gnight infinity
<ariel> enrico?
<fabbione> infinity: night dude
<fabbione> yeahhh gcc is building the binaries
<fabbione> doko: do you want a debdiff?
<infinity> fabbione: Going to upload it in time for the next publisher run, so it has a hope of finishing by the time I wake up? :)
<fabbione> infinity: as soon as i have the debs i need to fire up glibc
<fabbione> i assume in one hour or so 
<fabbione> infinity: it should be done by the time you wake up hopefully
<enrico> ariel: yes
<enrico> ariel: at your service
<ariel> enrico: you were looking for some help with scheme / festival
<enrico> ariel: yes.  Most of it I think i solved
<enrico> ariel: although, I could use some review
<ariel> yes I just saw your last email
<ariel> :>
<enrico> ariel: :)
<enrico> ok
<ariel> anyway, if in the future you need some scheme help ping me
<enrico> ariel: sure.  But at least, do you think that my patch makes sense, festival-wise?  That is, did I add the element with the right name and in the right position?
<enrico> (btw, thanks!)
<sivang> yo enrico !
<enrico> sivang: hi
<ariel> enrico: maybe you should put coding befor description
<enrico> ariel: I fear breaking things if I append.  gnome-speech was reading things positionally instead of by name
<ariel> well yes you ar right
<ariel> in an ideal word something like current-voice should be an object or an structure
<enrico> well... we're far from an ideal world there
<ariel> I can't understand why they SIOD as their scheme interpreter
<enrico> ariel: maybe it just happened to be handy
<ariel> enrico: and Iam a guile guy so...
<Kamion> Keybuk: would you expect /dev/cciss/* devices to have a 'device' symlink in /sys/block/?
<enrico> ariel: first LISP I've written is for this festival incident
<ariel> enrico: :) welcome to this lisp world!
<sivang> question to the review team: should I nag you so my spec will get reviewed , or just sit quitely wait for the status to change on LP? :)
<doko> fabbione: just email it please
<bddebian> Is there a sane way to make a cdbs package build everything in debian/tmp/foo and then parse out after the fact?
<fabbione> doko: yeps.. almost done
<fabbione> doko: glibc is building right now.
* bddebian feels the love as usual
<CarlFK> nice timing - this just in from a mail list: "I also second Carl's comments about Ubuntu as an organization. Lots of warm fuzzies there. "  
* mdke hugs bddebian
<Kamion> bddebian: I'm afraid I can't work out what you mean, much less answer it. "parse out after the fact"?
<Kamion> also, a whole six minutes, oh no
<bddebian> :)
<bddebian> As near as I can tell scilab-3.0 uses DEB_MAKE_INSTALL_TARGET := install DESTDIR=`pwd`/debian/tmp/usr  to "build" in debian/tmp.  Then in the .install files for the three binary packages they split out the files into the appropriate dirs
<bddebian> For scilab-4.0, using a very similar rules file it doesn't not work
<Kamion> try building with DH_VERBOSE=1 to see what debhelper is doing under the covers
<bddebian> Of course I'm not sure I understand why this is three binary packages anyway but that's a different issue :-)
<Kamion> and dig down further than "doesn't work" - find out where files are going, whether they're not getting installed correctly into debian/tmp or whether they're not getting copied out of there properly, at minimum
<Hobbsee> 
<Hobbsee> crud, sorry, this irssi on the live cd is weird!
<bddebian> Kamion: They are going to debian/$package/foo but it's not all there
<Hobbsee> 
<Hobbsee> argh!
<desrt> 
<Kamion> bddebian: then start with the package's Makefile
<Hobbsee> someone help!  how do you switch windows on irssi?  this thing is weird and bizarre and the normal shortcuts arent working!
<Kamion> DESTDIR support sometimes has to be hacked in
<Kamion> Hobbsee: Escape <window number>
<Kamion> or /window <number>
<infinity> Hobbsee: Alt-#, Esc-#, or /win #
<Hobbsee> Kamion: infinity: thanks so much!  i kept trying alt, as that's the version that works in konsole
<Hobbsee> would have asked in a more appropriate place, but i couldnt switch windows :P
<bddebian> Kamion: Thank you.  What would the approprate place for DESTDIR be?  SHould it be in DEB_MAKE_INSTALL_TARGET?
<Kamion> bddebian: I guess, I don't really know cdbs, but what that's probably doing is calling 'make install DESTDIR=`pwd`/debian/tmp/usr'
<Kamion> bddebian: so run that by hand and see what it does
<Kamion> usual debugging practice is to drill down one step at a time
<Kamion> use grep etc. to find out what implements the stuff that's causing you problems
<bddebian> Aye, but I don't know cdbs well enough to know what runs when..  I will shut up now
<Hobbsee> bddebian: check other cdbs stuff?
<bddebian> Hobbsee: I have :-)
* Hobbsee squints
<Hobbsee> right
<bddebian> And read usr/share/docs/cdbs/examples, etc
<bddebian> And LaserJocks packaging guide
* iwj gives up on the homebrew Xen install.
<Hobbsee> hmmm
<Kamion> bddebian: (this is why I avoid using cdbs personally, but that's no help to you)
<sivang> cdbs is evil! :-)
<Kamion> it's fine as long as you like your rules files to take the prolog approach :P
<sivang> hehe
<Kamion> but then when it goes wrong it says "no" and you don't know why
<Kamion> bddebian: anyway, if all else fails you can 'fakeroot strace -f -etrace=execve debuild -b' to see what subprocesses it's spawning
<raphink> is it only me or is sudo badly broken in edgy ?
<raphink> >>> sudoers file: syntax error, line 2 <<<
<raphink> >>> sudoers file: syntax error, line 21 <<<
<raphink> etc ....
<raphink> on a file that's perfectly correct
<raphink> :s
<Hobbsee> raphink: it's broken, fix was uploaded, but failed due to a broken cpio
<Kamion> known, fixes are working their way through the queue
<Hobbsee> bleh
* ..[topic/#ubuntu-devel:Kamion] : 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 | HAPPY DAPPER DAY! | Edgy is Open | yes, sudo is broken in edgy, will be fixed soon
<raphink> yes, cpio is broken, too
* ..[topic/#ubuntu-devel:Kamion] : 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 | HAPPY DAPPER DAY! | Edgy is Open | yes, sudo and cpio are broken in edgy, will be fixed soon
<raphink> :)
<raphink> I wonder how to fix it now, since sudo is broken ;)
<raphink> hehe
<Kamion> boot into recovery mode
<raphink> Kamion: it's in my chroot
<raphink> I havent' upgraded my machine yet :)
<raphink> I guess I just have to sudo -i and then chroot
<Kamion> that makes the task rather easy; exit the chroot and chroot in as root
<Kamion> sudo chroot /blah
<raphink> yep that works :)
<raphink> yes
<bddebian> Kamion: Can I bug you for something else? :)  (BTW, I'm only using cdbs because the current Debian maintainer, who is orphaning the package, won't sponsor if not cdbs)
<Kamion> bddebian: just say it on channel rather than to me personally
<Kamion> for all you know I might have no idea about whatever it is
<Kamion> also, please don't ask to ask, just ask :)
<bddebian> But you know everything :)
<Kamion> if I get *asked* about everything, I'll /quit
* Hobbsee kicks bddebian - just ask dammit.
<Kamion> there are other clever people on this channel
<bddebian> Anyway, in my edgy pbuilder, if I do a pbuilder login and apt-get update && apt-get install x11proto-gl-dev, no problem
<bddebian> However, pbuilder update and pbuilder build foo.dsc which build-deps x11proto-gl-dev says it can't satisfy x11proto-gl-dev build dep
<bddebian> Kamion: Yeah but they hate me too :-)
* Hobbsee suspects bddebian's pbuilder hates him.
<Kamion> bddebian: I'm afraid I do not know the cause of that problem.
<Kamion> so no, I don't know everything :P
<Hobbsee> Kamion: shameful!!!
* Hobbsee has Kamion hung, drawn, and quartered.
<Kamion> perhaps people are reticent to answer you because whoever answers one of your questions gets all the subsequent questions too? just a thought :)
<pitti> wb mdz
<mdz> kernel upgrade + sudo downgrade
<infinity> But the new sudo was so much FUN.
<infinity> Like a distro team video game.
<pitti> speaking of the kernel -- BenC, when do you think it is time to switch linux-meta to .17?
<BenC> pitti: in about 1 hour
<infinity> pitti: When LRM clears NEW.
<pitti> infinity: I regarded it as 'edgy user base count tool'
<Hobbsee> (infinity: didnt you go to bed?)
<pitti> oh, wow, that's fast :)
<infinity> Hobbsee: Yes.
<pitti> Hobbsee: that's the InfinityBot you are speaking to
<Hobbsee> hehe
<BenC> infinity: go to bed :P
<Hobbsee> heya um...pitti?
<pitti> infinity.sleep(8*3600)
* Hobbsee is guessing everything here.
<BenC> pitti: sent update email for kernel vulns
<fabbione> BenC: do you want to take of new silo for edgy? or should I?
<bddebian> Kamion: :-(
<Kamion> bddebian: genuinely trying to help. I find that repeatedly asking the same person for help when I don't know that it's their field leads to the help drying up rapidly
<BenC> fabbione: have at it
<bddebian> Kamion: OK, fair enough
<Kamion> bddebian: again, though, my approach would be to find out what pbuilder's calling, run that by hand, see what breaks, drill down, etc.
<Kamion> most problems are soluble by drilling down a step at a time.
<fabbione> BenC: ok
<zul> BenC,pitti: i should have breezy/hoary done this weekend
<sshrdp>  /join #ubuntu
<jsgotangco> goodnight
<jjesse> night
<Keybuk> Kamion: sorry, was at lunch -- and took a bit longer to get home than I hoped
<Keybuk> I do not believe /dev/cciss is currently covered by the persistent disk rules
<Keybuk> but then I don't know which subsystem they come from
<elmo> our standard kernels support root raid, right?
<elmo> 'cos I just switched a box from monolithic to standard kernel and it spassed out during initramfs claiming it couldn't find /dev/md0
<fabbione> elmo: yes it does 
<fabbione> i blame udev for that
<fabbione> elmo: can you modprobe raid1 and do a mdrun -a?
<fabbione> that should start the raid
<fabbione> (i assume you used raid1)
<Keybuk> fabbione: udev has nothing to do with /dev/md
<Keybuk> the idiot kernel md stuff doesn't support driver core
<fabbione> Keybuk: if udev didn't load the controller modules... yes :)
<Keybuk> fabbione: why would udev load the controller module?  it's not bound to any particular hardware
<elmo> fabbione: there's no mdrun in the initramfs system
<Keybuk> elmo: should be scripts/local-top/md
<elmo> ah, right
<elmo> I'm back in monolithic, lemme reboot
<fabbione> . /usr/share/initramfs-tools/hook-functions
<fabbione> copy_exec /sbin/mdadm /sbin
<fabbione> copy_exec /sbin/mdrun /sbin
<fabbione> it should be therre
<fabbione> elmo: i assume you have mdadm installed on the system
<elmo> I assume so - monolithic boots ;-)
<fabbione> elmo: raid doesn't really need userland to work if compiled in. there is a magic to autostart raid in the kernel
<Keybuk> fabbione: won't that die with the klibc patch>
<fabbione> Keybuk: ?
<Keybuk> not following lkml?
<fabbione> no
<Keybuk> the patch to add klibc to the kernel tree proper, and expel the last of the bits of the kernel that deal with mounting the root, etc.
<Keybuk> so even a monolithic kernel would have an initramfs in it
<fabbione> the raid autostart is done by magic superblocks
<fabbione> but yeah it might.. dunno what future will say
<elmo> ok, ACPI Debug + 9600 Serial Console ==> very effective boot DOS
<fabbione> elmo: that's ia64, isn't it? :P
<elmo> yes :-P
<elmo> mptscsih: Unknown symbol scsi_remove_host
<elmo> mptscsih: Unknown symbol scsi_host_put
<elmo> mptscsih: Unknown symbol scsi_print_command
* fabbione unleashes elmo towards lamont
<elmo> hmm
<fabbione> oh hmm
<fabbione> oh yeah
<fabbione> there is a bug open for that
<fabbione> it's binutils miscompiling a kernel module
<fabbione> something benc knows about
<fabbione> (in details)
<elmo> Begin: Waiting for root file system... ...
<elmo> how long will it do that for?
<BenC> up to 3 minutes
<BenC> I think
<elmo> is there someway to reboot in the initramfs environment?
<fabbione> on ia64... hmm
<fabbione> yes
<fabbione> you can do a ctrl+a+f to send a break and it will show the other options
<elmo> yeah, ok so the md0 stuff is a red herring - it's not got /dev/sd* which is much more relevant
<fabbione> iirc it's ctrl+a+r to reboot
<fabbione> elmo: i still blame udev for that ;)
<elmo> hmm, minicom has that key bound :/
<elmo> fabbione: not the mpt driver fuckage?
<fabbione> elmo: yeah it's mpt.. i was just kidding :)
<fabbione> elmo: not here.. i use minicom
<fabbione> elmo: do a crtl+a+space
<fabbione> it should show the help
<fabbione> or ctrl+a+f+space.. hell i can never remember
<fabbione> let me power on my ia64
<fabbione> i can be more useful that way
<elmo> ah, C-a-f b
<elmo> fabbione: got it, thanks
<fabbione> elmo: no problem..
* fabbione -> dinner
<fabbione> later
<Keybuk> sip debug
<Keybuk> meh
<Tonio_> hello
* bddebian gives Kamion a big hug :-)
<bddebian> Hi Keybuk
<Keybuk> hi
<elmo> BenC: do you know if there's a launchpad bug for  that mpt binutils symbol lossage, offhand?
<BenC> yeah, there is
<BenC> not sure if the bug report, but I recall it
<BenC> err, not sure of the bug number, but... :)
<BenC> uhg, gcc/binutils...one of them will be the death of me
<BenC> l-r-m is failing to build on i386 because of binutil 2.17, but it worked with 2.16 :/
<bddebian> whee
<elmo> Keybuk: do you know how to turn off buildds?
<Keybuk> elmo: yes
<BenC> well, I can't really say that
<Keybuk> well, I know how to put them into MANUAL
<BenC> strip is failing on pre-built nvidia libraries
<elmo> Keybuk: what's the URL?
<elmo> BenC: ah, yeah,t here's a bug in Debian about that
<elmo> I've been meaning to forward it upstream
<Keybuk> elmo: /+builds/$BUILDD/+mode
<BenC> I guess I can just ignore the nvidia libs
<elmo> "+builds" not "+buildds" ?
<elmo> BenC: not stripping themwould be the short term fix, yeah
<elmo> Keybuk: that's afe to do while it's building, right?
<Keybuk> elmo: absolutely no idea!
<elmo> oh well, we'll find out now I guess
<Keybuk> definitely +builds
<fabbione> elmo: please don't stop artigas
<fabbione> we really need gcc in asap for sparc
<elmo> fabbione: I've put it into manual, if that breaks the current build, it's too late to do anything about it
<elmo> and it's a hideous LP bug anyway
<elmo> if it doesn't break the current build, I'll be waiting for it to finish before I reboot anyway
<fabbione> ok thanks
<fabbione> i can tell you sejong willFTBFS
<fabbione> it needs gcc on artigas to build ;)
<BenC> ok, new vim default syntax stuff is really freaking me out
<BenC> collapsed debian/changelog sections by default, hihglighting open/close of parens in makefile vars, etc
<bluefoxicy> uh
<bluefoxicy> is there a way to get root besides sudo?
<bddebian> boot in recovery mode?
<bluefoxicy> figured that was it :/
<bluefoxicy> /etc/sudoers is fragged on edgy
<Amaranth> no it's not
<Keybuk> it's just sudo that's fragged <g>
<bluefoxicy> heh, yeah
<Keybuk> oh look, it even says that in the /topic :p
<bluefoxicy> remind me to put public keys for root on both my machines so I can ssh in remotely.
<Kamion> Keybuk: cciss> sorry, not familiar with the connection between having a device symlink in /sys/block and being in the persistent disk rules
<pitti> hm, since both cpio and sudo are fixed and in the archive now, we can certainly change the title
* ..[topic/#ubuntu-devel:pitti] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | Edgy is Open
<crimsun> pitti: don't join #ubuntu
<pitti> WTH is going on with my ISP???
<crimsun> trolls are using dcc send exploits
<pitti> crimsun: thanks, I left the channel
<Keybuk> crimsun: can we not kick them?
<bddebian> pitti: Why didn't you remove 'HAPPY DAPPER DAY' too? :-)
<crimsun> they're being kicked/k-lined whatnot, but they keep rejoining on different hosts
<pitti> bddebian: s/day/5 years/? :)
<bddebian> :-)
<wasabi_> Sure wish the gov cared about people's compromised computers being used to attack others.
<Keybuk> whose gov?
<bddebian> The government?
<pitti> Keybuk: Is there any doc/spec about the 'Config-Version:' field in dpkg -s?
<Keybuk> the what field?
<pitti> Keybuk: in short, is this guaranteed to only show up on removed, but not purged packages?
* Keybuk doesn't know that one
<pitti> oh, ok
<wasabi_> ya know, any of em.
<wasabi_> the one where the zombies are at. :0
<pitti> well, I'll just use the Version: then and grep for 'config-files' in Status: then to be on the safe side
<Seveas> pitti, you should upgrade your router firmware, /msg ubotu dcc for the CVE link
<pitti> Seveas: hm, that's not under my control
<Seveas> pitti, workaround: connect to freenode on port 8001
<Seveas> that exploit is going on on all big irc networks :/
<mdz> tseng: do you intend to expand beagle-integration and make it a proper edgy goal?
<pitti> Seveas: thank you! I'll forward this to my ISP
<Seveas> pitti, isp can't do much about it
<pitti> Seveas: our house router (ISP WiFi <-> house ethernet) is an old P60 running woody :)
<Seveas> hmmm
<sivang> Seveas: what is the exploit symptoms ?
<Seveas> that is odd - the bug that is causing this according to the CVE is a bug in stateful packet inspection in netgear home-routers
<Seveas> sivang, someone sends a a malformed DCC request and the router barfs
<Seveas> and disconnects you
<sivang> Seveas: I see, luckily, I'm using a remote machine for IRC
<sivang> (that should be heavily protected IIRC)
<HiddenWolf> mdz, there was a thread on the mailing list about integrating tracker, does that stand any chance?
<mdz> HiddenWolf: it seems both less mature and less complete than beagle
<HiddenWolf> mdz, I guess, but upstream gnome seems to be going to start using it, it doesn't require mono and a heap of ram, and jamiecc is very interested in promoting tracker
<mdz> HiddenWolf: jamiemcc is the maintainer of tracker, so yes, I imagine he would be :-)
<mdz> we'll likely ship mono in the desktop anyway for f-spot and tomboy
<HiddenWolf> on the cd?
<Keybuk> mdz: ping?
<mdz> Keybuk: pong
<Keybuk> https://merges.ubuntu.com/main.html
<Keybuk> ^ the ones without a red dot have already seen at least one upload to edgy
<mdz> Keybuk: hmm, but we can't tell whether that upload was a merge or not, I suppose
<Keybuk> right, there's no easy way to tell that sadly
<mdz> I think we can live with that
<Keybuk> but for the most part, it's probably true
<mdz> Keybuk: can we sort those to the bottom?
<slomo> hm is there any reason for type-handling not beeing in main other than that nobody has written a report yet? otherwise i would write one now ;)
<Keybuk> slomo: we explicitly keep it out of main with all our effort and power available to us
<pitti> slomo: it is generally regarded as crackful
<Keybuk> mdz: bottom of each priority band, or bottom in general?
<pitti> slomo: rewriting debian/control on the fly --> baaad things happen
<slomo> ok, fine... i'll continue to patch it out of everything then :)
<mdz> Keybuk: if it were more precise I'd say bottom in general; browsing over it I'm not sure
* pitti hands slomo the patch axe
<Keybuk> mdz: let's leave them in order for now, and then decide in a few days
<Keybuk> it's a trivial enough script to change
<mdz> Keybuk: seem to be too many false positives
<Keybuk> I suspect right now they're largely false positives, by next week, they'll be mostly true
<mdz> Keybuk: pychecker has not been uploaded to edgy that I can see
<Keybuk> mdz: right ... and it has a red dot :p
<mdz> Keybuk: oh, *without* a red dot
<Keybuk> red dot = needs doing :)
<mdz> Keybuk: in that case, it looks much more reasonable :-)
<mdz> I think it'd be best to have two tables, with the red dots in the first table and the rest in a second
<mdz> both in priority order
<mdz> and eventually the top list will go away
<Keybuk> okies
<mdz> a low-priority package which is untouched is more important than a high-priority one which has been merged already
<mdz> at least until we've gotten through the first round
* mdz wonders what we should do about initramfs-tools
<Keybuk> I think there was a spec about that
<Keybuk> basically make sure we at least look at what Debian did
<slomo> pitti: i'll merge gnutls12 if you don't mind :)
<pitti> argh, argh, no
<pitti> slomo: please do not touch gnutls and libtasn1-2 for now
<slomo> ok, np
<pitti> these are pretty messy in Debian now
<pitti> slomo: they seem to be in the middle of the gnutls13 transition, libtasn1-2 security patch was reverted, and the gnutls12 package doesn't build all packages any mroe (and misses the libtasn1-2 api change patch)
<slomo> pitti: no idea, i didn't look at it yet... i just selected a random package and saw that you were the last uploader ;) is sdl fine with you or do you want to care for it? :)
<pitti> slomo: yes and no
<mdz> the conflict markers are nice
<pitti> slomo: thanks for your help
<slomo> pitti: np :) i wonder why almost all the packages i randomly choose were previously uploaded by you :P
<pitti> slomo: I'd like to do g-v-m and cupsys myself (the latter because it's in svn), the rest is fair game
<pitti> slomo: I touched a lot of packages due to POT file building stuff and such :)
<slomo> pitti: i won't touch printing stuff anyway... i hate printers and they usually hate me too ;)
<Keybuk> mdz: https://merges.ubuntu.com/main.html   better?
<pitti> slomo: likewise :)
<sivang> pitti, slomo : hehe
<mdz> Keybuk: no
<mdz> Keybuk: not better
<mdz> Keybuk: ROCKING
<Keybuk> mdz: no?
<Keybuk> heh
<mdz> Keybuk: I think we can lose the red dots
<mdz> unless you're really attached to them
<pitti> now they have reversed semantics
<Keybuk> mdz: I was just trying to lose those
<Keybuk> only managed half of them
<mdz>    - add -D_LARGEFILE64_SOURCE on top of $(getconf LFS_CFLAGS)'s output
<mdz>      to fix lfs  support (closes: #13647)
<mdz> now why in the world would that work?
<Keybuk> gone now
<Keybuk> mdz: syslog? :)
<mdz> Keybuk: yes
<Keybuk> mdz: chmj? :)
<mdz> Keybuk: yes
<Keybuk> mdz: broken? :)
<mdz> just happened to notice it because it caused a conflict
<mdz> doesn't look right
<Keybuk> it doesn't work
<mdz> oh, I see what happened
<mdz> it was a Debian bug, and the person filing it suggested that as a fix
<mdz> people who knew better rejected it in Debian
<mdz> http://bugzilla.ubuntu.com/show_bug.cgi?id=13647
<Ubugtu> Ubuntu bug 13647 in sysklogd "sysklogd: Large file support is broken in the sarge version" [Major,Resolved: fixed]  
<mdz> The packet loss hits!  The packet loss hits!  You feel slower.
* Kamion hands mdz a pair of speed boots
<mdz> `bsdmainutils_6.1.3.tar.gz' at 16384 (9%) 2.1K/s eta:72s [Receiving data] 
<pitti> mdz: be glad that you weren't the last one touching OO.o :-P
<Keybuk> A GIGABYTE!!!OJIKJSFJAF
* Keybuk gets flashbacks and gibbers
<mdz> it would take the same amount of time to download oo.o over a properly functioning path
<mdz> lftp apparently gives up displaying the transfer rate as it approaches zero
<Keybuk> mdz: oh, in case you didn't catch earlier; that status page now updates hourly
<Keybuk> so it should pretty much be up to date with publisher runs
<sivang> pitti: where do I set up locales to use "C" until locales are fixed?
<Keybuk>   C* debian/patches/00list
<Keybuk> *blink*  yeah, because that's SO binary
<pitti> sivang: hm? they have been fixed for days
<mdz> Keybuk: next you will tell me a graph will appear at the top showing the merge progress
<Keybuk> mdz: I thought of that, but Riddell would give a DivideByZero exception
<mdz> Keybuk: yeah, I saw one of those with 00list too
<mdz> that is, noticed in passing in a REPORT, didn't look at it
<pitti> Keybuk: don't forget the merge Karma
<Keybuk> mdz: that probably means the entire thing was one big conflict
<Keybuk> (which is how I detect binary files <g>)
<sivang> pitti: hmm, maybe I need to reboot?
<mdz> ha
<pitti> sivang: restarting X should suffice
<mdz> so the maintainer renamed all of the patches or something
<mdz> 700542 bytes transferred in 356 seconds (1.9K/s)
<mdz> I'm getting nostalgic
<Keybuk> mdz: exactly
<pitti> mdz: maybe s/patch/dpatch/ or so? happens
<Keybuk> debian/patches/ubuntu_testsuite_tcl8.3.dpatch => debian/patches/10_tcl8.3_testsuite_failure.dpatch
<Keybuk> I have noticed one mom bug ... it sometimes drops the bottom of _really_old_ changelogs
<mdz> Keybuk: does it try to parse them?
<Keybuk> mdz: yup, parses, then version sorts
<Keybuk> oh, figured the bug, wasn't appending any trailing non-changelog junk
<Keybuk> fixed
<mdz> right
<mdz> changelogs are not very compliant
<Keybuk> mdz: it was more sane than previously ... which involved randomly stripping and wiggling patch hunks until they fitted
<Keybuk> usually this resulted in mom getting the changelog entirely backwards
<mdz> I wonder what would happen if I submitted my ubuntu calendar patch to bsdmainutils to debbugs
<Keybuk> "ubuntu calendar patch"? :)
#ubuntu-devel 2006-06-30
<sivang> hmm, wiki takes slow to commit
* mdz idly wonders why bsdmainutils is packaged debian-native now
<mdz> Keybuk: not THAT calendar
<Keybuk> mdz: in Debian or Ubuntu
<Keybuk> mdz: mmm, ascii art of naked people
* sivang misses the calander
<pitti> \00/  :)
<Keybuk> sivang: LP is being slow doing username lookups for me atm
<sivang> Keybuk: I wonder if the moin/LP-Integ. bits are slowing the wiki due to LP being slow. too many folks getting notified on a wiki page change also seems to do that
<ajmitch> morning all
<pitti> hi ajmitch 
<mdz> doh, I forgot -v
<Keybuk> mdz: ../merge-buildpackage is your friend
<mdz> I should add that check to my script
<Keybuk> (if you use grab-merge)
<ajmitch> mm lovely, I see I last touched e2fsprogs
<LaserJock> I saw that too :-)
<pitti> Keybuk: btw, can you fix grab-merge to use 'tar tz < $TARBALL'?
<pitti> Keybuk: erm, tar xz of course
<Keybuk> pitti: any particular reason?
<pitti> Keybuk: 'tar xf $TARBALL' fails for epochs
<sivang> hmm, ajmitch getting up means I need to go to sleep, soon :)
<pitti> Keybuk: it tries to access an rsh host, or so
<Keybuk> pitti: epochs shouldn't have been in the tarball filename <g>  I fixed that bug instead
<mdz> I thought that was why we didn't put epochs in filenames
<mdz> of course, tar does suck for breaking
<pitti> Keybuk: I encountered it this morning; ok, if it's fixed now that way, thanks
<Keybuk> pitti: yeah, I fixed it around lunchtime
<ajmitch> sivang: it's not like I ever get up at the same time twice :)
<Keybuk> or, at least, when any normal person would have got lunch
<sivang> ajmitch: still, it suggest that I may start to cross time zones..:)
<mdz> Keybuk: where are those?  perhaps REPORT should mention them
<Keybuk> mdz: where are which?
<mdz> Keybuk: merge-buildpackage, grab-merge
<Keybuk> grab-merge?
<Keybuk> it's in the top-level of merges.ubuntu.com
<mdz> I need to start attaching sequence numbers to my IRC replies
<Keybuk> https://merges.ubuntu.com/grab-merge.sh
<Keybuk> and mentioned in the blurb at the top of that page
<ajmitch> sivang: besides, I'm not in NZ at the moment :)
<Keybuk> it generates merge-buildpackage for you :)
<mdz> oh, I've been looking at main.html
<sivang> ajmitch: ah, in EU-like timezone?
<Keybuk> mdz: is just a script to parse REPORT, download all the files, and makes a couple of "useful" scripts that call dpkg-genchanges or dpkg-buildpackage with the right combination of -S/-sa/-v
<ajmitch> sivang: no, just australia
<mdz> Keybuk: why does it need to clobber cwd?
<Keybuk> mdz: it doesn't _need_ to I guess, it'd just clobber REPORT and merge-* otherwise
<Keybuk> modify it to taste :p
<Keybuk> I always do merges in their own directory, just to keep things clean
<mdz> Keybuk: or it could drop everything into a subdir
<mdz> Keybuk: didn't we determine in Paris that syncs could be scripted to require less manual fiddling?
<mdz> has that script been written yet?
<mdz> Keybuk: if you're in sync mode, hostname can go too
<Keybuk> "scripted" ?
<Keybuk> I don't remember being in that conversation
<Keybuk> (which is not to say that I wasn't, of course ... there were a *lot* of conversations :p)
* sivang reads Keybuk 's "the world under bzr" docs.
<Keybuk> tbh, I don't really notice the manual fiddling
<Keybuk> but yes, we could have something automatically tip syncs into incoming at some appropriate point
<pitti> good night
<Keybuk>                 if test -e ./configure.ac || test -e ./configure.in ; then cd . && `which autoconf1.7 || which autoconf` ; fi ; \
<Keybuk> autoconf 1.7 eh? :p
<Keybuk> s/conf/make/ I feel
<mdz> Keybuk: you don't notice copying the files around across sudo?
<mdz> it's a sequence of like 5 commands where it should be one
<Keybuk> copying the files around?
<Keybuk> oh, right
<Keybuk> no
<Keybuk> I go into screen 1, press the up arrow, change the name of the user and source package and press enter
<Keybuk> then I go into screen 2, press the up arrow, and press enter
<Keybuk> :p
<Keybuk> it got easier when we made ~lp_archive/syncs writable by lp_queue
<Keybuk> so now it can actually move the buggers out, rather than copy and have to delete later
<mdz> printing is busted for me
<Keybuk> I'm more vaguely concerned that those wacky Soyuz guys want to make things EVEN BETTER!
<mdz> smells like an fd being inherited somewhere
<mdz> in the cups pipeline of DOOM
<Keybuk> so instead of just "sync-source foo", we have to type "sync debian/unstable/foo/1.0-1 edgy" etc.
<mdz> ha...nope, it's just a permissions problem on /dev/usblp0
* mdz hugs cups for responding to any error condition by hanging forever
<mdz> Keybuk: any guesses why I ended up with a root:root /dev/usblp0 when udev.permissions says root:lp?
<Keybuk> bug
<Keybuk> needs a " in there :p
<Keybuk> well, in 40-permissions.rules
<Keybuk> which proves nobody ever tried printing anything in dapper
<Keybuk> we inherited that one from upstream
<Keybuk> and I only found out about it the other day
<mdz> needs one where?
<mdz> SUBSYSTEM=="usb", KERNEL="lp[0-9] *",    GROUP="lp"
<Keybuk> Typo in permissions.rules KERNEL==lp not =="lp
<mdz> in what version of udev?  I don't see that in edgy
<Keybuk> oh, hmm
<Keybuk> edgy needs == there
<mdz> is udev.permissions obsolete?  I still have it around
<Keybuk> yeah, very obsolete
<mdz> it's ignored?
<Keybuk> totally ignored
<Keybuk> since probably hoary
<mdz> Keybuk: you need a bug for the edgy KERNEL=" issue?
<sivang> hrm
<Keybuk> mdz: there is one I believe
<sivang> is there a way to clean up partially pushed branch from b.l.n ?
<sivang> bzr: ERROR: File exists: '/~ubuntu-dev/hubackup/ubuntu': mkdir failed: unable to mkdir
<Keybuk> mdz: can't see it though, so file if you like
<mdz> don't see one
<mdz> will do
<sivang> (I aborted the first one, and created a new branch clean and without too many commits over the last development cycle)
<Keybuk> oh, it was in bug #50447
<Ubugtu> Malone bug 50447 in udev "For SCSI CD/DVD writer, scsi_generic device needs to be owned by cdrom" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50447
<Keybuk> though the patch is wrong, obviosuly
<mdz> no bug then?
<tseng> mdz: i do but unfortunately i havent had a chance yet to get a livecd built with all the bits and hacked on it
<tseng> md	to have any idea what is feasible
<sivang> anyway, good night all
<tseng> there is a beagle bof tommorow, incidentally
<tseng> cant talk now sorry, the lag is inasne
<Keybuk> ya know, I swear dholbach has had an attack of the shiny while at guadec
<Keybuk> jesus fucking christ
<Keybuk> seriously, nobody has bothered reading the licences for these files
<Fujitsu> Which files?
<Keybuk> telepathy, cohoba, and friends
<shackan> what's wrong there?
<Fujitsu> What does libtelepathy do, anyway?
<infinity> Whatever you want it to.
<Chipzz> "what the user wants" ;P
<Chipzz> which is what every fscking application should do
<Chipzz> obviously
<Chipzz> ;)
<mjr> "The aim of this project is to provide a D-Bus-based framework that unifies all forms of real time conversations, including, but not limited to, instant messaging, IRC and voice and video over IP."
<Fujitsu> Ah.
<Keybuk> Fujitsu: it's the Nokia 770 v2 chat thing
<Fujitsu> OK.
<mjr> "it's not just for Nokia anymore" - it's a freedesktop.org project
<Keybuk> yeah, the interchangeable robs always intended it to be a general framework
<bddebian> Heya
<shackan> lol for 'the interchangeable robs'
<gnomefreak> is it possible to pull libeel2-2 update or ateast hold back?
<gnomefreak> s/atreast/atleast
<Fujitsu> You can lock the version on your system...
<Fujitsu> Is it killing nautilus deps as the bug says?
<gnomefreak> yes its remove nautilus
<gnomefreak> i tried pinning it but i guess the wiki is wrong because it didnt work
<Fujitsu> Pinning won't do it.
<Fujitsu> You need to lock it...
<shenki> "Ubuntu, an ancient African word meaning cant install Debian"
<shenki> opps, wrong channel, sorry
<shaya> is it documented anywhere that one needs to change their grub from hdx to sdx w/ an pata drive?
<shaya> was wondering why my 2.6.17 edgy box was hanging on boot w/ new kernel
<Fujitsu> They fully switched to using libata?
<shaya> it seems that way
<shaya> just upgraded to 2.6.17, rebooted and it just hung there
<Fujitsu> I saw your bug.
<shaya> went to "recovery mode" noticed "hey, why is it detecting it as sda!"
<shaya> rebooted, went to grub changed it and its all good now
<shaya> anyways, time for me to sleep
<shaya> you australians can work through the night :)
<pitti> Good morning
<Hobbsee> hey pitti!
<Hobbsee> this irssi is actually *readable* today, unlike the one off the live cd!  :P
<ajmitch> morning pitti 
<Hobbsee> hi ajmitch 
<ajmitch> hi
<pitti> hello Hobbsee, hi ajmitch 
<fabbione> morning
<ajmitch> morning fabbione 
<Hobbsee> hey fabbione 
<fabbione> infinity: how is gcc/glibc doing?
* pitti is still amazed how MoM blows up a trivial 1.3 kB patch into a 3.8 MB monster
<fabbione> lol
<Fujitsu> Heheh
<Hobbsee> hehe
* Hobbsee is amazed at how bz2'ifying a pbuilder seemed to do the same thing.
<pitti> Hobbsee: bz2ify?
<Hobbsee> pitti: compress as a tar.bz2?
<pitti> and that increases the tarball size?
<Hobbsee> i think so - i didnt think my home directory was that big!
<mman> hi all
<slomo> infinity: please give-back nautilus everywhere... thanks :)
<pitti> slomo: hm, did you already merge sdl? (I hope I didn't miss it from -changes)
<Pharaoh_Atem> umm, noticed that the standard kernel in breezy does not have a kernel header or source package on the apt repository
<Fujitsu> Pharaoh_Atem, you sure?
<Pharaoh_Atem> yep
<Pharaoh_Atem> positive
<StevenK> What did you search for?
* StevenK looks for a breezy box.
<Fujitsu> Try linux-source... It has to be there.
<Pharaoh_Atem> kernel-headers-2.6.12-9
<Fujitsu> No.
<Fujitsu> linux-headers.
<Fujitsu> Not kernel-headers.
<Pharaoh_Atem> why are there packages that are named kernel headers then?
<Amaranth> debian
<imbrandon_> linux-headers-`uname -r`
<Amaranth> although i believe debian switched to linux-* too since they have freebsd and such kernels as well
<Pharaoh_Atem> also, it seems the gcc packages retrieve the wrong headers
<Pharaoh_Atem> when using apt
<Amaranth> you mean build-essential?
<thom> this is so not the right channel
<Amaranth> thom: Yeah.
<Amaranth> Pharaoh_Atem: Please file a bug in launchpad.
<StevenK> Or ask your question in #ubuntu
<Pharaoh_Atem> ill file a bugreport
<Pharaoh_Atem> bye
<StevenK> File a bug so we can close it quickly.
<imbrandon_> heh
<sivang> morning
<jsgotangco> sivang!
<sivang> yo jsgotangco , what's cracking?
* jsgotangco just busy looking at bugs
<sivang> nice
<jsgotangco> does homuserbackup have a bzr mainline?
<sivang> jsgotangco: yes, it does , I will also follow scott's instructions to make it commitable by universe uploaders, as soon as I sort the partially pushed branch issue on b.l.n
<jsgotangco> ok please ping me when its avaialble for branching =)
<sivang> jsgotangco: for the mean while, you can check out https://launchpad.net/people/sivan/+branch/hubackup/devel-main
<jsgotangco> thanks
<sivang> jsgotangco: this should work as the bzr url to branch off of - http://bazaar.launchpad.net/~sivan/hubackup/devel-main
* jsgotangco subscribes
<elmo> *.ubuntu.com, *.launchpad.net and anything else in the Canonical Data Centre is going away for 5 mintes
<Fujitsu> :(
<mvo> fabbione: in what way broke libselinux-dev devmapper? (I'm doing the merge right now). should it still be disabled?
<neuralis> elmo: gah, in the middle of a server dist-upgrade.
<jsgotangco> doh! im branching
<pitti> hi neuralis 
<Fujitsu> elmo, any particularly good reason?
<pitti> neuralis: 'Use the mirror, Luke' :)
<Fujitsu> Or do they just want to have a snooze? :P
<neuralis> hey pitti
<neuralis> pitti: yeah, i'm switching to a mirror now, i was just amused at the timing
<azeem> Fujitsu: let's assume there is a good reason
<Fujitsu> azeem, I'd assume so.
<neuralis> three cheers for a 100mbit/s link.
<Fujitsu> Oooh. Where?
<neuralis> Fujitsu: .edu
<Fujitsu> AH.
<neuralis> pitti: no reply from spender after that last e-mail i sent (you were cc'd)
<neuralis> pitti: i'll wait a couple more days, and then poke him again
<pitti> neuralis: yep, I read it; TBH, I don't have much hope
<neuralis> yeah, same here
<neuralis> pitti: i have a long flight tomorrow, and will be looking closely at the grsec patch. 
<neuralis> it might be possible to extract the invariants we're interested in without his cooperation, and still not make it a support burden for us.
<neuralis> i'll finish the spec and include my findings.
<pitti> neuralis: yes, as long as it's a small and contained patch, it should be no problem
<neuralis> pitti: yeah, that's what i intend to look at.
<pitti> neuralis: the /tmp symlink race protection is an excellent example for this
<neuralis> honestly, there should be a *ton* of useful things that we can extract and that doesn't change much between kernel versions
<neuralis> i'll verify that that's the case, but i expect a bunch of the /proc strengthening, extended jails, tcp/ip stack features, aslr, capability stuff, etc to all be relatively invariant
<\sh> ogra: ping
<sivang> hey \sh 
<\sh> moins sivang
<elmo> sorry, but once again *.ubuntu.com, *.launchpad.net and anything else in the Canonical Data Centre is going away for 5 mintes
<doko> Kamion: how to go on with promotions of packages, which already have been in main (like db4.4)?
<pitti> Kamion: (db4.4 is fine for me, as long as we schedule a large-scale transition to it)
<Kamion> doko: promoted
<doko> Kamion: thanks; pitti: it's just that the db module is broken on hppa with db4.3. maybe we should setup a document on UVF which library versions we want to target.
<pitti> doko: oh, 4.4 will work?
<doko> pitti: on hppa for the dbm module, yes
<pitti> doko: if we get it into main, then we should transition everything to 4.4, apart from the packages which use on-disk transition logs
<pitti> doko: but that's something for later
<doko> pitti: do we have a list of packages, where we know that transition logs are used?
<Kamion> YM transaction logs?
<doko> Kamion: do you want to have an explicit main inclusion report for python-central/python-support?
<pitti> Kamion: erm, yes, sorry
<doko> who should be asked about dapper-proposed-updates?
<Kamion> doko: yes please
<Kamion> (central/support)
* Kamion tries to bend his brain around the pcmciautils merge
<Kamion> I'll do pcmcia-cs as well - they really need to go together
<Znarl> Is there a good doc on how to set up a package repository, focussed on Ubuntu, kind of current, that goes into signing Release files?
<ogra> mvo, hey
<ogra> mvo, why did you request a sync for atomix ?
<mvo> ogra: hi, I looked over our changes and (what I could see) it was only a new upstream version that was different from the debian version
<mvo> ogra: have I overlooked something?
<NekoXP> meow
<Kamion> doko: proposed-updates> what about it?
<doko> Kamion: we discussed that we need a staging area before uploading things to dapper-updates
<ogra> mvo, we'll loose 7 language translations and a change i still try to find out what dholbach meant with
<pitti> ogra: atomix doesn't use gettext?
<mvo> ogra: sure? the language translations where done upstream according to the changelog
<ogra> mvo, thats why i posted my list of merges i plan in the meeting yesterday
<ogra> well, if you think it fits, i'm fine, take it
<mvo> ogra: sorry, if you feel strong about it I will close my sync request
<ogra> mvo, i dont
<ogra> its just odd to discover after half an hour of fiddling that someone requested a sync already
<mvo> ogra: ok. it would be good to have a "I claim this" system :/
<ogra> mvo, yes, thats why i made the list yesterday
<mvo> ogra: and I overlooked it :(
<ogra> no problem :)
<pitti> mvo: don't have enough merges? :)
<ogra> but do you have any idea what dholbach meant with "  - Include formulas of all compounds in the interface" ?
<mvo> pitti: well, it was dholbachs but he is in spain ... so I thought
<ogra> and   * Resynchronized with Debian. (Ubuntu: #21107)
<mvo> ogra: I'm pretty sure that this is quoted from the upstream changelog
<ogra> 21107 is an ati driver bug
<mvo> haha
<ogra> he must have been very tired :)
<Kamion> doko: AFAIK dapper-proposed exists and works saving perhaps for buildd chroots
<doko> Kamion: will check that
<doko> Kamion: are binutils binaries still in NEW?
<Kamion> doko: if the buildd chroots don't work, that will have to wait until Adam gets back from vacation, but it should be possible to try a source upload
<Kamion> doko: no, I did those yesterday
<Kamion> the only things in NEW are some exiv2 binaries which I'll process in a moment, and that zope stuff
<mvo> ogra: yeah. sorry again for getting in your way 
<ogra> mvo, dont worry, i saw the bug early enough
<ogra> we should probably just all mail a list of packages we plan to work on to -devel
<mvo> ogra: the "funny" thing is that I wrote a mail to daniel telling him that I requested the sync
<doko> Kamion: it looks like we can get rid of the python2.3 based zope stuff in debian as well, so it's not worth to process these now
<pitti> Mithrandir: can I cowtrade the mailman merge with you? You might want to just apply the fixes in Debian and sync
<Kamion> doko: I need to do something with them. Should I remove and sync-blacklist those packages?
<pitti> ogra: hm, too clumsy (mail to -devel)
<mvo> ogra: yeah, we need to discuss this. my favorite workflow would be to have a button on the main.html page with "I claim this" - but I guess that would be a bit overkill to implement :)
<ogra> mvo, well, its an edubuntu package :)
<pitti> ogra: sticking to the names on main.html and IRC pings should work fine, or not?
<mvo> ogra: *cough* ... ok
<pitti> ok, this case showed that it doesn't...
<doko> Kamion: please do what it less work for you
<Kamion> doko: the list is zope-cmf1.4, zope-portaltransport, zope-zattachmentattribute, zope-zaaplugins, zope-i18nlayer, zope-i18nfolder, zope-cmfactionicons
<Kamion> can you confirm that those are all going to go away?
* Kamion hereby claims all installer merges, in case that was in any doubt
<doko> Kamion: have to look. zope-cmf1.4 yes, don't know of the others
<pitti> Mithrandir: I offer to do flac and gnuchess in return
<Mithrandir> pitti: they're already done.
<pitti> oh, ok
<pitti> Mithrandir: 'they' includes mailman?
<mvo> ogra: I will keep away from edubuntu merges from now on, promissed :)
<Mithrandir> pitti: nope, flac and gnuchess are done.  Haven't looked at mailman yet.
<ogra> mvo, not all packages on my list are edubuntu specific :P
<ogra> but thanks :)
* mvo looks up the irc logs 
<ogra> mvo, dhcp3, fuse, iptraf, kdeedu, kino, nessus-plugins, pwgen, rss-glx, tuxmath, tuxpaint, xfonts-terminus, xscreensaver
<ogra> while pitti already claimed dhcp3 :)
<pitti> well,I asked ;)
<mvo> ogra: thanks! I was about to merge iptraf, but it is yours now
<ogra> and is said ok, didnt i ? :)
<ogra> s/is/i/
<pitti> ogra: ok, fine for me
<ogra> mvo, only if you didnt start on it yet
<ogra> lets not do work twice
<mvo> ogra: no, I have not :)
<ogra> ok
<NekoXP> so if I go into synaptic and completely remove bluez-pcmcia-support, pcmcia-cs and pcmciautils, it says it will remove ubuntu-desktop and ubuntu-minimal but that WON'T trash my system, right? I am not going to lose 1000 packages or any real files apart from the pcmcia ones?
<Kamion> that's correct, although you'll lose neat upgrade handling when we add new packages to minimal and desktop
<Kamion> I'm curious though - why are you desperate to remove those packages?
<NekoXP> I'm not desperate to remove them, but they do take up like 2MB of disk space (along with a lot of other stuff I want to remove) and we're trying to fit a preinstall image (oem) onto a CD
<NekoXP> our hardware doesn't have a pcmcia slot.. so it's pretty pointless having it just for it to go FAILED on the boot screen
<Kamion> pcmciautils is tiny
<Kamion> but ok
<Kamion> do you expect that users of these images will ever want to upgrade?
<NekoXP> upgrade to a pcmcia slot?
<NekoXP> :D
<Kamion> no, upgrade to a later version of Ubuntu (or whatever)
<NekoXP> yeah I suspect they will, but they won't use pcmcia utils, or vga graphics driver (or 5 others), or powerbook buttons daemon or the mac and pmac-fdisk tools (it will fuck their disk)
<NekoXP> even after the upgrade
<NekoXP> it's just wasting space, making the boot take longer (it hangs at pcmcia startup for 3 seconds..), blah blah.
<Kamion> basically once you remove ubuntu-minimal upgrades are unsupported
<Kamion> if you don't mind that, then fine
<Kamion> note that you can also just hack the init script ...
<NekoXP> this is what I am trying to avoid. It needs to be a fairly working usable system...
<NekoXP> yeah and the next time someone gets a pcmcia utils update from Synaptic the hack is removed.
<Kamion> stick "exit 0" at the top of the init script, no more hang
<Kamion> incorrect
<Kamion> init scripts are conffiles
<Kamion> they may have to resolve file conflicts though
<Kamion> but by default, it keeps the current version
<Kamion> IIRC synaptic does that unless you open the terminal widget
<NekoXP> mrf...
<Kamion> also I believe that's the pcmcia-cs init script hanging, not pcmciautils
<Kamion> though you'd have to try it to be sure - but pcmciautils is pretty small and harmless
<NekoXP> well remove one and it removes the other
<Kamion> that's not true - pcmciautils does not depend on pcmcia-cs
<NekoXP> this whole thing is a big fat mess if you ask me :] 
<Kamion> you can remove pcmcia-cs without removing pcmciautils
* Kamion <- pcmciautils maintainer
<NekoXP> okay
<NekoXP> but it's still gonna nuke ubuntu-minimal
<Kamion> no, it's not
<Kamion> pcmcia-cs is not in minimal
<NekoXP> or ubuntu-desktop then
<Kamion> it will only remove ubuntu-desktop
<Kamion> upgrades are still sort of unsupported if you remove ubuntu-desktop but less hideous-run-away unsupported
<NekoXP> yeah but... I don't want that
<glatzor> ping mdz
<Kamion> well, uh, you can't have it both ways :)
<NekoXP> I don't see why I should have all these drivers and services I can guarantee will never ever be supported hardware on this platform, just because you want a generic do-all thingy for everyone. I know laptop support is nice and so on, but this isn't a laptop. How come you can't remove pcmcia, or individual X graphics drivers, or even a disk tool (that is fundamentally broken) without nuking the upgrade process?
<Kamion> if you remove ubuntu-desktop, then what we ask is that you shoulder the support burden for upgraders
<NekoXP> I would rather mac-fdisk was not installed on the system simply because people think they can use it if it's there and it *will* completely nuke our partition table
<Kamion> we'd prefer not to have pcmcia-cs in desktop, and it will be gone in edgy
<NekoXP> the same for pbbuttonsd
* NekoXP gets a hankering for Gentoo again.. quick... get the gun.. :(
<Kamion> it's unfortunate that powerpc has multiple incompatible subarchitectures, but I think the right answer is to make *-fdisk notice that it can't handle the partition table and bomb out rather than trashing it
<NekoXP> like that'll ever happen
<ogra> file a bug and it will at some point :)
<NekoXP> it takes about 2 years to get a 1 line patch into parted
<Kamion> *-fdisk != parted
<NekoXP> we still don't have pegasos support in the kernel properly because the ubuntu kernel guys aren't exactly the most on-the-ball bunch in the world
<Kamion> is this pegasos?
<NekoXP> yes :D
<Kamion> due respect, but the conduit for many pegasos patches doesn't do the platform any favours
<NekoXP> sven?
<Kamion> though I'm sure you've only heard one side of that argument
<Kamion> yes
<NekoXP> nah I saw both sides
<NekoXP> I think both are pretty childish
<Kamion> most people don't find getting patches into parted so incredibly difficult
<NekoXP> well Sven is the debian maintainer for parted
<ogra> he's not for ubuntu though :)
<Kamion> not since mid-2005 according to the changelog
<NekoXP> he submitted a patch... and it finally got rolled in something like 18 months later. Then it took longer for Debian to pick the package up into a decent tree
<NekoXP> well I dunno
<Kamion> Otavio has been doing it since then, mostly
<NekoXP> this was a long time ago. He drops projects when people reject his patches or sit on them for 18 months for no reason.
<Kamion> also, that was while parted upstream was pretty dormant, and it's active now
<NekoXP> it still sucks
<Kamion> anyway, I killfile Sven because I can't deal with him without wanting to smash things, so let's not continue this
<Kamion> otherwise I will want to smash things again
* NekoXP curses
<NekoXP> remove pcmcia-cs -> remove bluez-pcmcia-support -> remove ubuntu-desktop
<NekoXP> dependency hell
<Kamion> I'm happy to take pegasos patches from somebody I can deal with reasonably :)
<NekoXP> it'll probably end up being me knowing my luck
<Kamion> yes, that's correct, in dapper. if you don't want all of the Ubuntu desktop, then removing ubuntu-desktop is correct
<NekoXP> after I prise them from Nico's cold dead hands
<Kamion> I have a Pegasos here; once I get round to buying a KVM switch I can power it up again and make *-fdisk not be so destructive easily enough
<Kamion> I'd appreciate a bug to remind me though
<NekoXP> who are you again?
<Kamion> Colin Watson
<NekoXP> oh ho
<Kamion> (/whois)
<NekoXP> yeah I don't like whois it's kind of rude. I could ctcp version you too.
<NekoXP> it's like pulling down your pants to read the nametag
<Kamion> um /whois is invisible to the whoisee
<NekoXP> hey you're colin! nice boxers!!
<Kamion> it just queries the server
<NekoXP> it's still obnoxious :)
<NekoXP> whatever happened to conversation
<_ion> nekoxp: You're joking, right? :-)
<NekoXP> ur joking lol I fink mebbe ok.. ye
* NekoXP sobs at the state of internet chat
* Kamion works his way through the pcmcia-cs merge; hopefully now we won't need pcmcia-cs to handle upgrades
<NekoXP> okay I guess exit 0; is the best way then
<NekoXP> I dunno how I am gonna clean space off, I can get rid of like the x.org drivers and that's it
<NekoXP> safely..
<Kamion> if you wanted to avoid removing *-fdisk, you could dpkg-divert them instead
<Kamion> how much space have you got, total?
<NekoXP> about 640MB
<Kamion> and what way are you compressing the image on the CD?
<NekoXP> the first image I made from a clean OEM install was 670MB. That fits but it's a bit tight since I still need to brand the desktop and who knows what oem-blah does
<NekoXP> partimage image, gzip
<Kamion> might be worth considering squashfs; that's what we use on our live CDs
<Kamion> it saved a lot of space when we switched to it
<NekoXP> well we want to partimage it onto a disk, that's the point
<Kamion> oh, cp -a won't do? ok
<NekoXP> get rid of the dumb "it has 4 Linuxes on it" installation thing
<NekoXP> I dunno if cp -a would work.. from squashfs? doesn't it trash permissions and timestamps and stuff?
<Kamion> it's essentially what we do for our live installer ...
<ogra> NekoXP, no way to use 700MB media ? 
<NekoXP> every time I boot a livecd all the files are set to today's date
<Kamion> although as it happens I do it by hand in python instead to get better progress reporting, but shrug
<Kamion> you know, to be honest I haven't noticed
<NekoXP> ogra, I am using 700MB media but we need a 16mb initrd kernel, partimage, plus the support partition, tools etc. to fit on the same disk
<ogra> ouch, ok
<NekoXP> it's a "boot it and it installs Ubuntu and then reboots in 5 minutes flat" CD
<Kamion> I'm certain it doesn't trash permissions though, maybe timestamps
<Eons> hello there
<Eons> will Edgy have pycairo 1.1 and above?
<NekoXP> GNNN
<NekoXP> synaptics touchpad driver part of the desktop
* NekoXP cries
<Kamion> the chief problem is that detecting that in such a way that it gets installed on just the correct machines both on fresh installs and on upgrades is not at all easy
<slomo> pitti: not yet... i was a bit too tired yesterday... so if you want to do it do it... otherwise i'll try to find some time for it later :)
<Kamion> hopefully in the future though we'll be able to let you say "I want to keep ubuntu-desktop installed except for these packages"
<pitti> slomo: I'll leave it alone for now
<Kamion> probably in the brave new smartpm world
<slomo> pitti: is it an important merge? i think it would also make sense to wait for directfb to enter main (which needs to happen for gtk anyway) and don't drop the udeb that is created for libsdl with directfb support then... or what do you think?
<ogra> NekoXP, you are working off a ubuntu iso ? if so, did you remove build-essential and its revers deps ? 
<pitti> slomo: sounds sensible
<ogra> *reverse
<NekoXP> ogra, no?
<NekoXP> I used umm... powerpc-alternative 6.06
<ogra> ugh, what has ridden me to claim the fuse merge ... 
<ogra> NekoXP, dropping gcc and linux-heareds etc should gain a bit of space
<NekoXP> it's installed on the disk now in oem mode I am making changes and then running the oem-config script thing and making an image...
<slomo> pitti: ok, i'll wait then :) this will make our delta much smaller
<NekoXP> ogra, but it's a developer workstation :D
<Kamion> ogra: those aren't installed by default
<NekoXP> if it has no gcc they watsted $800
<ogra> ok
<ogra> thats bad then ... no gain here 
<NekoXP> or at least, they didn't, but they have to download it
<NekoXP> it seems installed here anyway, 3.4.5 or so?
<jsgotangco> have a good friday all
<jsgotangco> brb
<NekoXP> by fefault
<ogra> ciao jsgotangco 
<NekoXP> anyway I gotta go get lunchypoos
<NekoXP> doesn't apt/dpkg support hard dependencies and soft dependencies?
<Mithrandir> it does.
<NekoXP> so is ubuntu-desktop depending on pcmcia-cs a hard or soft dependency?
<Mithrandir> ubuntu-desktop only has depends, not recommends or suggests.
<zul> mvo: ping
<Kamion> apt/dpkg supports recommends/suggests but they don't have the upgrade behaviour we want
<Kamion> suggests is only shown informationally by certain frontends
<Kamion> recommends may make sense to use in the future
<mvo> zul: pong
<zul> mvo: did you have a look at the debdiff for grub?
<mvo> zul: sorry, not yet. I do this in a couple of minutes, I need to finish some other task first
<zul> sure...im heading off to work but ill be available when i get there
<mvo> zul: great, thanks!
<sivang> re
<simira> mvo: I just assigned a bug to you on the update-manager issue. Still doesn't work :-/
<mvo> simira: thanks, I will have a look. what bugnummber is it?
<sivang> hey mvo 
<simira> mvo: #51419
<mvo> simira: thanks
<Eons> wtf?! sudo doesn't work, gksudo does
<Eons> how's that possible?!
<doko> Kamion: all zope packages you listed are obsolete and marked for removal in unstable
<NekoXP_> Kamion, that explains it then
<Kamion> doko: great, thanks
* Mithrandir tries to decide what to do about x-ttcidfont-conf.  We _could_ sync it, but I'm not entirely happy about it using /usr/X11R6/ fontpaths.
<Kamion> Mithrandir: I tend to think we should be bringing the core of X into sync before doing stuff on top of it
<ogra> does debian use /usr/X11R6/ still ? 
<Mithrandir> ogra: no, but there are some legacy symlinks there.
<ogra> ah, k
<Mithrandir> Kamion: yeah, that's what I'm coming to too.  Won't make sense to sync it and then break it.  Better break and then fix it.
<doko> heh, he didn't say goodbye, seems like he's late ;-)
<Keybuk> SIGSO
<Keybuk> (the other signal you can't ignore)
<thom> does that mean you can't handle an SO?
<Mithrandir> not when being signalled, no.
<Mithrandir> ;-)
<_ion> My system doesn't have SIGSO.
<thom> _ion: SO == Significant Other
<Mithrandir> thom: he could still be lacking SIGSO due to lacking a SO..
<_ion> thom: Yes.
<thom> Mithrandir: true. i realised that just as i hit return, as ever
<lifeless> the best time to realise tuff
<lifeless> s/tuff/s&/
<pitti> Keybuk: btw, do you know why MoM wants lynx merged? we have a newer version than Debian has
<Kamion> Keybuk: argh I wish you hadn't done netcfg
<Kamion> Keybuk: I have that in bzr
<pitti> Keybuk: it's a bit special, unstable has a sarge security version
<Keybuk> Kamion: oops, sorry!  forgot that was in bzr now
<Kamion> I'll attempt to import it
<Keybuk> the merge was an "easy" one iirc
* pitti forgot this once, too; we should have an apt-get source hack to check that...
<Keybuk> I did that because I thought it was the one that wasn't
<Kamion> please ignore all installer packages :-)
<Keybuk> and is the one I tend to touch most
<Kamion> it wasn't until relatively recently
<Keybuk> pitti: 
<Keybuk> DEBUG:root:lynx: ubuntu is 2.8.5-2ubuntu1
<Keybuk> DEBUG:root:lynx: debian is 2.8.5-2sarge1
<Keybuk> DEBUG:root:lynx: base is 2.8.5-2 (2.8.5-2 wanted)
<pitti> funny that dholbach has so many KDE packages to sync :)
<Keybuk> interesting case that
<pitti> Keybuk: so, 'u' >> 's' certainly?
<Keybuk> pitti: yes, but both are > the base :p
<pitti> ah, yes
<Keybuk> so the Ubuntu package should be 2.8.5-2sarge1ubuntu1 to "acknowledge the sync"
<pitti> Keybuk: probably due to Debian's 'automatically import sarge-security into sid' trick I heard about
<pitti> Keybuk: hm, I can do a no-change upload with a that newer version number to quieten it :)
<pitti> Keybuk: well, I'll do it after doko uploaded our gcc with ssp fu, then it has at least a purpose :)
<Keybuk> do we have all of those changes?
<Keybuk> if it doesn't need a merge, just ignore it!
<pitti> Keybuk: yes, it's just the sarge1 upload which is already incorporated in our pacakge
<zul> hey
<mvo> hello zul! you have mail :)
<zul> wheee! :)
<mvo> anyone working on the bittornado merge?
<Kamion> Keybuk: yes, well, netcfg is an example of MOM *thinking* it can handle .po files ...
<ajmitch> hey zul 
<zul> hey ajmitch 
<Kamion> the choices splitting in there didn't work out so well
<Keybuk> Kamion: heh, you came up with the po handling :p
<Kamion> I know
<Keybuk> "po is hard, let's go shopping"
<Kamion> hence why I expected that breakage ;)
<Kamion> I'll clobber a different resolution over the top of your upload I think
<Keybuk> fair enough
<Kamion> 'cos otherwise the next merge will be painful
<pitti> Keybuk: indeed, whenever the merge touched .po files, I generally merged manually to avoid cluttered deltas
<Kamion> actually, it might just be a relatively small tweak, looking at the Debian diff ...
<Kamion> er, the new diff versus Debian
<Keybuk> yeah, I did do some manual tweaking of that one myself
<pitti> Keybuk: maybe we can just ignore Ubuntu .po changes in MoM?
<Kamion> pitti: !
<Keybuk> libtasn1-3 |    0.3.4-2 |          edgy | amd64, i386, ia64, powerpc, sparc
<Keybuk> libtasn1-3 |    0.3.4-2 | edgy/universe | source
<Keybuk> eh?
<pitti> Keybuk: no, don't say someone synced that????
<pitti> oh, 1-3
<Keybuk> pitti: hmm?
<Keybuk> there's no ubuntu changes there
<pitti> Keybuk: gnutls12 and libtasn1-2 are b0rked in Debian now, let's not touch them
<pitti> Keybuk: yes, I mixed it up with libtasn1-2
<pitti> so, why is the package in main and the source in universe?
<Fujitsu> !?
<Keybuk> override bug
* pitti looks up to the ftp masters
<pitti> ah
<Keybuk> explains why sync-source was bitching
<pitti> Keybuk: po files> I thik we generally benefit from taking Debian's idea of PO files instead of trying to proliferate ubuntu diffs; Rosetta has them all anyway
<Keybuk> pitti: I'll put you in a little room with Kamion :p
* pitti grabs the asbesto pants
<pitti> Kamion: you think it's a good idea to try to merge them?
<pitti> Kamion: I'm not sure whether the current MoM implementation or our actual package diffs suck, but when I compare the original diff and the new proposed one, I lean towards MoM
<Kamion> pitti: installer
<pitti> Kamion: ah, true
<Kamion> pitti: for non-pkgstriptranslations-blacklisted packages, I agree with you
<mvo> doko: will we get python-support >= 0.3.0 soon (apparently bittornado build-deps on it)
<Kamion> Keybuk: ok, I'll import yours after all and then debconf-updatepo it into submission
* Kamion likes the way it's possible to shunt .bzr directories around between unpacked source trees and commit at each step
<doko> mvo: inclusion reports are ready for review
<pitti> doko: saw them
* pitti goes to ack them right now
<mvo> doko: cool, thanks
<doko> mvo: but you have to sync it, it least in the old versions the supported python versions were hardcoded
<doko> s/sync/merge/
<mvo> doko: yeah, I'm doing that right now
<irvin> Keybuk, can i pm you?
<Kamion> Hobbsee: in case nobody's said already, could you use the -v<last_version_in_Ubuntu> option to debuild when building merged uploads
<Kamion> ?
<Kamion> looking at ksudoku 0.3-4ubuntu1
<Keybuk> irvin: that's an awfully personal question
<Keybuk> what about?
<Kamion> the effect of that is to produce .changes files that include all the changes since the last version in our archive
<Hobbsee> Kamion: ah, right.  no one told me that.
<Hobbsee> will do in future
<Kamion> the MOM report does mention it at the bottom although perhaps not very obviously
<Hobbsee> the MOM report?
<StevenK> grab-merge
<Keybuk> Hobbsee: uh, how are you doing merges?
<irvin> thanks a lot Keybuk !
<pitti> doko, Kamion: python-{central,support} approved
<Keybuk> Hobbsee: you know about http://merges.ubuntu.com/universe.html - yes?
<Hobbsee> Keybuk: um, grabbing source from debian, from ubuntu, comparing them, seeing if the changes are still needed.
<Keybuk> I had a feeling that's what you were doing <g>
<Keybuk> so, we have this system called Merge-o-Matic, or MoM
<Hobbsee> why do i get the feeling that whatever i say here is going to be wrong?
<Hobbsee> yep, right
<Keybuk> it does all that for you, and gives you either a merged source package, or a source with some conflicts that need resolving
<Hobbsee> Keybuk: oh nice.
<Keybuk> so let's pick a package randomly, kdbg -- that's one you last changed in Ubuntu
<StevenK> Or a source that doesn't build, but MoM can't do anything about that. :-)
<Whoopie> mdz: thanks for commiting the fix for #38272. Has it to be acknowledged by someone else? I don't find it in the dapper-changes mailinglist.
<Keybuk> you can find it (or your name) on the web page above, or just go directly to it
<Keybuk> http://merges.ubuntu.com/k/kdbg/REPORT
<Hobbsee> haha, one of many, yes
<jjesse> what does MoM stand for?
<Kamion> merge-o-matic
<Hobbsee> jjesse: merge-o-matic
<Keybuk> that tells you the version in Debian and Ubuntu, a base version that was selected, and what happened when the system tried to do something about it
<jjesse> ah
<Keybuk> in the above case, you just end up with a conflict on po/cs.gmo that needs resolving
<Keybuk> in that same directory, you find all the bits you need
<StevenK> Or, use the leet grab-merge script
<Keybuk> and at the bottom of that file, it tells you the arguments you need to give to dpkg-genchanges/buildpackage/debuild/etc.
<Keybuk> right, https://merges.ubuntu.com/grab-merge.sh
* StevenK hugs grab-merge
<Keybuk> in a temp directory, "grab-merge kdbg" ... then you have it all in front of you
<StevenK> Along with a script to fix up the changes file.
<Kamion> promoted python-{central,support}
<Hobbsee> right...yep...
<Keybuk> sometimes, like with kcemirror, there are no conflicts!
<Keybuk> http://merges.ubuntu.com/k/kcemirror/REPORT
<Keybuk> there it's generated you a complete source package, that you just need to check over
<jjesse> wow seems like you guys make it pretty easy
<Keybuk> http://merges.ubuntu.com/k/kcemirror/kcemirror_0.1.5-1ubuntu1.patch
<Keybuk> ^ and there's the "updated patch"
<Kamion> Whoopie: somebody needs to actually upload it, and then it needs a manual ack by an archive admin
* Hobbsee isnt even going to try that.
<Kamion> crimsun: are you going to upload your fix for bug 38272?
<Ubugtu> Malone bug 38272 in xserver-xorg-input-mouse "option EmulateWheelTimeout not working" [Medium,Fix committed]  http://launchpad.net/bugs/38272
<Keybuk> using mom is much easier than doing it all by hand, mostly
<Hobbsee> hehe true
<Keybuk> I'd been suspicious for a short while that universe people hadn't heard of mom
<Keybuk> or were at least not using it
<Hobbsee> Keybuk: it's not on the link for merging, yes.
<Whoopie> Kamion: ok, thanks for the explanation.
<ajmitch> the news hadn't got out well enough
<ajmitch> to those not following -devel
<Keybuk> Hobbsee: would you like to be the universe ambassador, and help the MOTU use it?
<ogra> hmm
<Hobbsee> um
<Kamion> it annoys me slightly that some of my local merge tools require CVS gettext
<Hobbsee> Keybuk: once i understood it, maybe?
* Hobbsee still has a system to fix!
<Keybuk> http://article.gmane.org/gmane.linux.kernel.commits.head/82801
<Keybuk> \o/
<Keybuk> PAAAAARTY!
<ajmitch> yay
<pitti> Keybuk: huh, clean up rave? :)
<zul> Keybuk: yeah saw that this morning...whee!
<Keybuk> pitti: "ding, dong, the witch is dead"
* Kinnison bounces around
<Hobbsee> Keybuk: from what i understand, universe people have heard of this mysterious MoM, often knows what it stands for, but have no clue in hell how to use it.
<ajmitch> Hobbsee: teach them 
<Hobbsee> ajmitch: 
<Hobbsee> ajmitch: i cant teach them if i havent figured it out :P
<ajmitch> that's part of teaching :)
<Keybuk> I'll be happy to help out anywhere along the way
<Hobbsee> Keybuk: right.  so if we have said diff above, what do we actually do with it?  (for kdbg)
<Hobbsee> check it for sanity, and then upload it, or what?
<Keybuk> so, if I were going to do kdbg, I'd first have downloaded the http://merges.ubuntu.com/grab-merge.sh script
<Keybuk> then, in an empty directory, I'd do "grab-merge.sh kdbg"
<Hobbsee> yep
<Keybuk> it just downloads everything in k/kdbg for you
<Keybuk> so in your working directory you now have the version of kdbg in Ubuntu
<Keybuk> the version of kdbg in Debian
<Keybuk> and the version of kdbg from Debian that the one Ubuntu was based off
<Keybuk> you also have two patches
<Keybuk> one which is "the Ubuntu changes to kdbg"
<Keybuk> and the other which is "the Debian changes to kdbg"
<Keybuk> finally you have a .src.tar.gz and a list of conflicts -- this is unpacked by grab-merge automatically
<Keybuk> if you go into that directory, for each file listed, you'll either find a .DEBIAN and .UBUNTU version -- or one file with diff3 conflict markers (<<<<</=====/>>>>>) in it
<Keybuk> for the .DEBIAN and .UBUNTU case, you need to pick one of them, or merge them together by hand, rename it to the proper filename, and delete the other
<Keybuk> for the diff3 conflict marker case, edit the file, and pick one side, the other side, or a combination of both for each block
<Keybuk> you can then update debian/changelog to include your name
<Keybuk> and do ../merge-buildpackage -rfakeroot to generate a source with the right details
<Keybuk> Hobbsee_: heh, how much of that did you get?
* Hobbsee kicks freenode!!!!
<Hobbsee> bloody thing.
<Hobbsee> [23:05]  <Keybuk> the version of kdbg in Debian
<Hobbsee> was the last thing i got
<Keybuk> http://rafb.net/paste/results/3i8dGe51.html
<Hobbsee> thanks
<Keybuk> once you've got the new source, you can debdiff that with the current Debian one and compare that patch to the base->ubuntu one ... and thus see whether anything's gone wrong
<Hobbsee> that was my *eth0* going down, not my wlan0 - wow!
<Keybuk> and you can also generally mooch around the diff, etc. to make sure it's all looking ok
<Keybuk> if you're happy, upload it
* Hobbsee looks, reads, and tries.
<Keybuk> for the kcemirror case, it's even easier; there's no conflicts, so instead of a src.tar.gz you get a third source package and a third patch
<Keybuk> so you just need to do the last step -- compare the source and patch to the previous ones, see if you're happy, and upload it
<Keybuk> http://rafb.net/paste/results/aFfBi141.html  <-  all of the above in one
<mvo> anyone working on the "blt" merge?
<Hobbsee> ffs.  work you stupid thing!
<Keybuk> mvo: go for it
<pitti> what does 'ffs' mean?
* Hobbsee has had it with badly behaved technology for tonight.
<Keybuk> pitti: "for fuck's sake"
<Hobbsee> pitti: you dont want to know.
* mvo hugs Keybuk
<pitti> ah
* mvo learned something new today and will use 'ffs' from now on
<Hobbsee> haha oh dear.  i taught the dev channel something.
* pitti joins mvo
* Hobbsee shakes her head.
<pitti> mvo: let's see whether we need it in today's game
<Hobbsee> this is what endless crashes, freezes, and 3 BSoD's in one night gives you.
<mvo> pitti: haha, right - I bet people will look puzlled if I suddenly cry: 'ffs'
<pitti> Hobbsee: we have BSoDs in Ubuntu now???
<Hobbsee> plus a crashing akgreator.
<Hobbsee> +g
<_ion> FFS means Fast File System. :-)
<Hobbsee> pitti: no, i had to use an XP machine for recording tonight.
<Hobbsee> it.  was.  shocking.
<mvo> Facial Feminizing Surgery <- according to google
<Hobbsee> pitti: actually, i think we do.  the screensaver.
<pitti> Hobbsee: wow, I thought XP was generally quite stable nowadays
<Hobbsee> pitti: it's not.  well, if you try to connect a mixing desk via firewire cable.
<pitti> Hobbsee: hah, yes! the FBSoD :)
<Hobbsee> hehe
<StevenK> Hobbsee: That would be the driver for the mixing desk, or the USB stack.
<Hobbsee> recording/mixing desk
<Hobbsee> <Keybuk> for the diff3 conflict marker case, edit the file, and pick one side, the other side, or a combination of both for each block <-- i got up to there.  what does this mean?
<StevenK> Hobbsee: Microsoft like to claim otherwise, but a crap driver can and will still bring XP down.
<StevenK> Hobbsee: You'll see a file with <<<<<< text ==== text >>>>>>
<_ion> pitti: When they say XP is "stable", they actually mean it has horsecrap all over the floor.
<Hobbsee> hehe
<StevenK> Hobbsee: With newlines inserted, of course.
<StevenK> Hobbsee: That means both Ubuntu and Debian have made a change, and a different one at that.
<Hobbsee> StevenK: not sure which file you're talking about
<StevenK> It could be any file, but the most common I've seen is debian/control.
<StevenK> Hobbsee: I'm talking in the general case.
<StevenK> Hobbsee: You're see that if the report contains a line like "       C debian/control"
<StevenK> Er, You'll
* Hobbsee taps her fingers on the table.
<Hobbsee> hmmm.  i'm utterly and totally lost, and not understanding what you're saying.
<StevenK> Right. Are you looking at a report at the moment?
<StevenK> (If so, which?)
<Hobbsee> StevenK: kdbg
<pitti> fabbione: is there a spec about the snakeoil SSL cert that I can point to in Debian bug reports?
<StevenK> Keybuk: Oh yeah, I've noticed that grab-merge sometimes downloads the orig twice.
* mvo takes bluez-libs next
* mvo wonders if there are any objectsions
<Keybuk> StevenK: yeah, it will if it's listed twice *shrug*
<StevenK> Keybuk: Usually it's fine, except if the orig is for xemacs21...
<pitti> mvo: I guess noone is looking at Charles' syncs yet
<mvo> pitti: yeah, that is why I'm looking, we can sync bluez-libs directly - I love it when I can do this :-D
<pitti> mvo: yeah, me too :) I'm sending easy diffs to Debian right now, hoping that we can sync even more in the future
* mvo hugs pitti
<pitti> mvo: Joey Hess applied my patch within some hours, so that we could already sync analog :)
<pitti> mvo: Marco d'Itri is a little ... tougher
<mvo> haha
<Keybuk> heh, I get along with Marco just fine
<Keybuk> the trick is just to make sure he can get all of the patches, and let him pick and choose them as he likes
<StevenK> Keybuk: And make it sound like his idea? ;_)
<StevenK> Ow, my nose.
<Keybuk> StevenK: fixed version of grab-merge for you
<Keybuk> nah, he's quite easy to deal with if you just say "more patches for you, take your pick"
<Keybuk> in fact, he's one of the better Debian maintainers; because if he doesn't like the patch, he just doesn't take it -- he doesn't feel the need to bitch about it ad infinitum
<Hobbsee> hehe.  useful
<StevenK> Keybuk: Oh, thank thee
<pitti> Keybuk: I sent him a minimal patch (1 line), even as attachment, with a detailled explanation
<pitti> anyway, /me goes on
* mvo claims the whole bluez-* stack
<ogra> greedy man you
<ogra> :)
<Hobbsee> hehe
<mvo> says the man who claimed all of edubuntu ;)
<ogra> heh
<ogra> i just merged fuse ... thats only indirectly edubuntu :P
<Keybuk> pitti: yup, I usually stick it on people and /msg him -- but the theory is sound
* pitti hugs doko
<pitti> let the breakage begin! :)
<zul> mmm...breakage
<Keybuk> mmm...breakfast
<Hobbsee> pitti: heh, well, i'm not sure my current edgy actually boots tonight, so you might have got what you were looking for.
<ajmitch> pitti: ah good, the pain starts :)
* ajmitch wonders how many ssp orner cases will show up in universe
<Hobbsee> aaaarrrrrgggghhhhhhh!
* pitti hands ajmitch a 'c'
<Hobbsee> part of my backup's still on the other computer.
<ajmitch> pitti: I blame my laptop keyboard
<ogra> Keybuk, 
<ogra> dh_testdir
<ogra> ./configure --prefix=/usr --mandir=/usr/share/man
<ogra> make: execvp: ./configure: Permission denied
<ogra> make: *** [build-stamp]  Error 127
<ogra> pbuilder: Failed autobuilding of package
<ogra> is it intentional that mom removes execute bits ? 
<pitti> ogra: chmod 755 configure debian/rules :)
<pitti> ogra: that was fixed recently
<ivoks> hi all
<ogra> pitti, no, its actually configure thats not executable
<pitti> hey ivoks 
<pitti> ogra: see my chmod command :)
<ogra> rules is fine 
<Keybuk> ogra: no, it's not intentional
<Mithrandir> ogra: patch doesn't preserve file permission bits.
<Keybuk> what's the source package?
<pitti> ogra: to be sure, I build the source package and unpack it again
<ogra> pwgen
<Keybuk> Mithrandir: mom doesn't use patch
<ogra> pitti, i testbuild all my packages before upload :)
<pitti> ogra: yes, me too, that's why I delete/re-unpack the source to make sure that permissions, timestamps, etc. are fine
<Keybuk> ogra: yes, I see your point, it's not copied the permissions across
<ogra> yep
<Keybuk> oh, arse
<ogra> i fixed that, but wanted to notify you
<Keybuk> it's not much of a problem, because it'll get "fixed" by uploading it anyway
<Keybuk> but it's annoying :p
<Hobbsee> hi bddebian 
<ogra> its the first package where i see that though
<Keybuk> it'll show up wherever there's a +x file that isn't conflicted
<Keybuk> but there's a conflict elsewhere
<ogra> ah
<bddebian> Hi Hobbsee
<bddebian> and everyone else
<Keybuk> right, fixed
<ajmitch> night all
<Keybuk> return merge_file(...)  needed to be if merge_file(...): return True
<Keybuk> otherwise it didn't fix the attributes afterwards
<bddebian> Gnight ajmitch
<Hobbsee> night ajmitch 
<zul> c ya ajmitch 
<iwj> Keybuk: The ff mom output has marked some files as C but the file is actually empty.
<Keybuk> iwj: ignore the empty file, look at the .DEBIAN and .UBUNTU next to it
<Keybuk> known bug, already fixed
<iwj> Ah, so treat them as C*.
<Keybuk> yup
<iwj> In fact they're all files which I don't care about and I'm not sure why they're different anyway but it doesn't matter.
<Keybuk> gmo files usually
<iwj> No, random other crap.  ff is full of it.
<jsgotangco> good evening
<Keybuk> heh
<bddebian> Heya jsgotangco
<bddebian> What does the color scheme represent on the Merges pages?
<iwj> It's a shame MoM can't automatically figure out the changelog :-).
<Keybuk> iwj: what did it break?  it has a changelog handler
<Keybuk> bddebian: package's priority
<iwj> Well, it doesn't know what to remove and anyway I like to have the ubuntu changes at the top.
<iwj> I mean, changes that Debian have taken still appear in the changelog (in general the changelog entries aren't identical between Ubuntu and Debian).
<bddebian> Keybuk: Green being high or low? :-)
<Hobbsee> Keybuk: MOM is cool :P
<Keybuk> bddebian: green would be optional or extra
<Keybuk> extra is more blueish
<bddebian> Hey, everything in Universe is blue or green.. WTF?? ;-)
<Hobbsee> hehe
<Keybuk> bddebian: everything in universe is either priority optional or extra
* mvo grumbles about the bluez-utils merge
<Hobbsee> Keybuk: did you want to check my kdbg, to check that i'm doing it right now?
<bddebian> Keybuk: I was joking. :-)
<Keybuk> Hobbsee: shouldn't need to, you almost certainly have got it right
<Hobbsee> Keybuk: then you should be fine to upload it?  :P
<Keybuk> it's a universe package, no?
<Hobbsee> Keybuk: and what happened to ksudoku after that?  why isnt it on MoM?
<bddebian> Wow Hobbsee, you have brass ones :-)
<Hobbsee> bddebian: i do?
<Keybuk> Hobbsee: bddebian uploaded ksudoko for you
<bddebian> Hobbsee: Make Keybuk be your bitch ;-P
<Keybuk> so there's no outstanding merge for it now
<Hobbsee> Keybuk: right, cool, just checking
<Keybuk> if another version appears in Debian. it'll appear in the "updated merges" list at the bottom
<Hobbsee> bddebian: dont worry, you'll be next :P
<Hobbsee> Keybuk: right
<bddebian> Hobbsee: I'm already ashamed that my first Edgy upload was your and not mine :-)
<Hobbsee> bddebian: as is the case with the dh_iconcache fixes - there was no lack of packages waiting to be uploaded :P
<Hobbsee> bddebian: shame, shame.  remind me to never go for MOTU so that it may always be like that.
<bddebian> Heh
<Hobbsee> bddebian: where were the brass ones?
<bddebian> Hobbsee: Uhm, err, never mind since you don't have 'ones' :-)
* Hobbsee is lost.
* Hobbsee suspect she's missing some joke somewhere.
<Hobbsee> Keybuk: it's universe, yes
<Keybuk> Hobbsee: so a MOTU member should check and upload that for you
<bddebian> Fine, fine, where is it?
<Hobbsee> Keybuk: and core devs are not included in MOTU, right :P
<Hobbsee> bddebian: on revu, i'll grab you a link
<Hobbsee> bddebian: http://revu.tauware.de/details.py?upid=2556
* bddebian won't do any uploads for himself for Edgy, just Hobbsee
<Hobbsee> hehe
<Hobbsee> thanks bddebian :)
<bddebian> Hobbsee: Sorry, you have specified an invalid distribution.. ;-P
* Hobbsee thinks there should be a bddebian distro.  maybe bddebian mashed, codename mashed?
<fabbione> mvo: there was a problem with lvm2 udeb <- being linked with libselinux and you don't want that
<fabbione> mvo: that was only on ppc iirc
<bddebian> Hobbsee: Yeah :)
<fabbione> pitti: yes you can use the old server spec
<mvo> fabbione: ok, I did the merge and left it out 
<fabbione> mvo: left it out as in skipped the hunk?
<fabbione> mvo: it would good to see if that linking issue is gone
<bddebian> Hobbsee: Uhm, where is the tarball?
* Hobbsee shoots bddebian 
<mvo> fabbione: left it out as in: removed libselinux build-dep and build it with --disable-selinux (to play it safe)
<bddebian> Hobbsee: Ack, you shot me in the uploading hand.. ;-P
<Hobbsee> bddebian: um.  indeed.  
<Hobbsee> crud.
<Hobbsee> bddebian: it's in ubuntu source :P
<Hobbsee> obviously it didnt get uploaded
<mvo> fabbione: but we definietely should check that again, I just couldn't figure from the changelog in what way it broke
<fabbione> mvo: ok. do you have a ppc to test?
<fabbione> mvo: otherwise i can do it locally but not today
<Hobbsee> bddebian: it's at http://merges.ubuntu.com/k/kdbg/kdbg_2.0.4.orig.tar.gz <-- but that doesnt solve the fact that it didnt get uploaded automatically
<mvo> fabbione: no, only the ppc porter machines, but its unlikely that I will manage today
<fabbione> mvo: it's not urgent
<bddebian> Hobbsee: Aye, I'm getting it
<fabbione> mvo: we need to build devmapper and then lvm2
<fabbione> mvo: to verify it links correctly...
<iwj> Joy of Thai word breaking patch.
<Hobbsee> bddebian: i just ran the dput revu *.changes
<fabbione> mvo: and there no other consequences like the world needs to be rebuilt in 20 minutes kind of thingy
<fabbione> mvo: it's just those 2 pkgs
<mvo> iwj: 80 million thai people love you for it
<mvo> fabbione: ok, thanks :)
<fabbione> mvo: no problem.. i was actually going to suggest that i would these merges.. but i come too late
<jsgotangco> mvo: 65Million rather =)
<mvo> fabbione: no worries
<mvo> jsgotangco: right :) lets make it "millions and millions of thai people"
<sivang> re
<bddebian> wb sivang
<sivang> hey bddebian 
<fabbione> Keybuk: i am going to reboot my main workstation with multiple ide controllers stuff in edgy in a few minutes.. mind to stay around if something explodes badly?
<Keybuk> sure
<Keybuk> it'll break :p
<fabbione> Keybuk: any idea how?
<Hobbsee> Keybuk: hey this is much easier!
<Keybuk> I'd expect your controllers to be reversed
<Keybuk> hda -> hde, hde -> hda, etc.
<fabbione> Keybuk: hmmmmm interesting.. how so?
<Keybuk> fabbione: IDE drivers will be loaded in the opposite order to what they were in dapper
<fabbione> Keybuk: ok, if that happens, how can i re-order them?
<Keybuk> you can't, currently
<fabbione> (asking before rebooting since the ws is where i am IRC'ing from)
<Keybuk> you could switch to mount-by-uuid
<fabbione> hmm ok
<bddebian> Gah, where's the Standards Version information on Debian?
<fabbione> let's hope the RAID won't explode
<slomo> bddebian: depends on what you want to know :) but the policy is a good start
<bddebian> slomo: I want to know the latest Standards Version and what changed
<slomo> fabbione: seems like there's a null pointer exception somewhere in the kernel currently when using sata drives... see bug #51308http://athlon64.fsij.org/archive/2006/03/20/debian/pool/main/t/tomboy/tomboy_0.3.5-1.diff.gz
<Ubugtu> Malone bug 51308 in linux-source-2.6.17 "linux-image-2.6.17-3-686 doesn't boot, libata error" [Untriaged,Confirmed]  http://launchpad.net/bugs/51308
<fabbione> slomo:  i don't have SATA....
<fabbione> slomo: i wrote IDE
<sivang> slomo: I wonder if that's the same what I got
* sivang moves to -kernel
<slomo> bddebian: latest is 3.7.2 (.1)... look here for the changelog: http://packages.debian.org/changelogs/pool/main/d/debian-policy/current/changelog
<bddebian> slomo: THx
<Keybuk> fabbione: IDE uses libata in edgy
<Keybuk> (or, at least, will)
* mvo is away for a bit
<Keybuk> but that's not the bug
<Keybuk> the ide ordering bug is just that I haven't written sorting code for udevtrigger yet
<Keybuk> so we're using the upstream stuff, which is (imo) wrong
<sivang> Keybuk: do you expect that stuff to break things on sata laptops? :)
<Hobbsee> Keybuk: did you upload your updated grab-merges script, to fix the permissions?
<Keybuk> which stuff?
<Keybuk> Hobbsee: which permissions fix?
<Hobbsee> Keybuk: thought you mentioned something above.  anyway, everything's owned by root, making you use sudo dch etc...
<Hobbsee> Keybuk: for the stuff that's downloaded with the script
<fabbione> Keybuk: yes i know about the libata plans. that will break a lot on my system but i will also be happy to lart with bugs :P
<Keybuk> Hobbsee: hmm?  nothing should be owned by root... unless you ran it as root?
<Keybuk> did you do "sudo grab-merge" ?
<Hobbsee> Keybuk: oh darn it.  guilty as charged.
<Hobbsee> i was having trouble making the script execute - that was the cursing earlier, where i taught the dev channel somethign :P
<Hobbsee> Keybuk: this list gets updated every 6 hours, right?
<Keybuk> every hour, normally
<Hobbsee> right, nice :)
<Hobbsee> this is way easier!
<Keybuk> I'm doing some manual fixing up of the merges at the moment -- to get rid of the buggy ones -- so it 
<Keybuk> won't be quite hourly atm
<Hobbsee> fair enough :)
<\sh> hmmm...which script creates /var/run/network?
<\sh> I installed ubuntu-minimal and /etc/init.d/networking doesn't come up, because /var/run/network/ifstate is missing, but /var/run/ exists
<fabbione>  /var/lib/dpkg/info/portmap.postinst: line 51: db_get: command not found
<fabbione> ^^ for who did the merge
<fabbione> it's missing the include to debconf stuff
<\sh> and I don't understand where /var/run is mounted...because it's missing in tmpfs, but mtab says something else
<\sh> ok /etc/init.d/mountvirtfs is doing the mount
<Keybuk> \sh: S01mountvirtfs does the mount, S08loopback creates the directory
<Keybuk> and it's first used by S10udev and later by S40networking
<Hobbsee> Keybuk: got a problem.  with using the ../merge-genchanges script, why doesnt it upload the .orig.tar.gz as well (to revu, with dput revu *.changes)?  it has parameters -S -sa...
<Keybuk> Hobbsee: no idea, paste the changes file and merge-genchanges script somewhere
<Hobbsee> Keybuk: http://pastebin.ca/75760
<Hobbsee> (argh, no i do *not* want to paste 57 lines into the middle of the channel thanks!)
<Keybuk> changes file includes the orig.tar.gz ... must be dput bug
<Hobbsee> Keybuk: how to fix?  upload it manually or something?  or just point to where the .orig.tar.gz is?
<Keybuk> no idea, I've never used dput
<\sh> Keybuk: in what runlevel? I don't find it in rc2.d
<Keybuk> \sh: rcS
<sivang> Keybuk: how do you upload packages then?
<Hobbsee> Keybuk: it usually works, with my revubuild script!  :P
<sivang> (manual ftp??)
<Hobbsee> ie dpkg-buildpackage -S -sa -rfakeroot -k98B2D4F0
<Keybuk> sivang: dupload
<fabbione> Keybuk: it does work as it is
* sivang installs
<Keybuk> fabbione: cool
<fabbione> Keybuk: except a few tons of that "open $something: failed"
<fabbione> but i guess that was usplash because i started in nosplash showmeallthecrack
<\sh> Keybuk: hmm...what could it be, that mountvirtfs is not started somehow? 
<Keybuk> \sh: buggered if I know
<\sh> Keybuk: booting normal amd64-generic kernel from dapper...
<Keybuk> dapper or edgy?
<\sh> dapper
<Keybuk> works fine here
<\sh> Keybuk: sure, normal install works fine...but it looks like that I'm missing a piece in my FAI installation..everything is installed, ubuntu-minimal installed
<Hobbsee> Keybuk: okay, so it was just being tempramental with the last package - this is uploading fine.
<\sh> well, anyways...I'm stopping now with my work here...
* Hobbsee wonders who looks like a nice victim.
<Hobbsee> oh good :)
* ..[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 | It's Merge Time! http://merges.ubuntu.com/
<mdz> Whoopie: 'fix committed' means a fix is available, but not uploaded yet
<bddebian> Aye
* mdke thought it was "uploaded but not published"
<bddebian> Oh, hmm, me to
* Hobbsee contemplates.  dinner, or sleep?  it's almost 2am.
<Yagisan> Hobbsee: only almost
<Hobbsee> yeah
* Hobbsee sorta had dinner at the golden arches.
<Yagisan> you poor thing
<Hobbsee> hehe
<Hobbsee> it was either that or no dinner.
<LaserJock> the golden arches were a blessed sign in Paris ;-)
<jsgotangco> haha
<lifeless> you didn't!
<jsgotangco> yes he did
<Hobbsee> hehe
<Hobbsee> he?
<lifeless> OMG
<jsgotangco> le big mac
<LaserJock> that, and a Subway across the streat from Notre Dame
* Hobbsee wonders who lifeless is referring to.
<lifeless> Hobbsee: LaserJock 
<Hobbsee> oh right
<Hobbsee> i thought i was missing something there!
<lifeless> maccas in sydney is one thing
<lifeless> maccas in paris is a whole nother ball game
<jsgotangco> he went all the way to paris to eat something that originated from brazil
<jsgotangco> heh
<LaserJock> :-)
<sivang> lifeless: what is maccas ?
<lifeless> mcdonalds
<fabbione> sivang: the aussie equivalent of McDonald?
<Hobbsee> oh no, i'm about to get yelled at!
<LaserJock> well, the hotel food made me a little wary of Parisan cooking, despite what I've heard all these years ;-)
<jsgotangco> raw beef scared ya
<LaserJock> yep
<jsgotangco> next time i will join the LTSP guys for dinner
<LaserJock> but right after Subway highvoltage and I found the LTSP guys in a cafe, we missed out
<ghee22> hi i'm working on a program for ubuntu, and am stuck at a mono error.  anyone interested?
<sivang> LaserJock: raw beef had become a delight aftr that week :p
<sivang> or what ever delight is spelled
<sivang> :-)
<LaserJock> yikes, the McDonalds and Subway keep me from becoming that desperate ;-)
<fabbione> i have in .fr different times.. never been able to eat decent food there != $big_fat_well_known_world_wide_chain
<jsgotangco> lol
* jsgotangco was guilty of eating angus burger at burger king in amsterdam though
<Yagisan> I've considered many times the choice of McDonalds, or starving. Considering 3 of the last 4 times I went to maccas I got food poisoning, I choose starving now
<sivang> LaserJock: still,the beef and chicken were quite good, and as someone liking cheese, it was an experimental experieince :)
<jsgotangco> el!
<Hobbsee> ouch.  i'm getting rm and mv confused.
<bddebian> Guilty?  I would eat a hamburger or steak for Breakfast, Lunch, and Dinner if I could :-)
<bddebian> Hobbsee: That's not good :-)
<Hobbsee> lucky i didnt preface those with sudo, or use wildcards!
<Yagisan> At least Burger King usually cooks the burger when you order it, not 30 minutes prior. anyway thats enough of me being off topic
* Hobbsee plays with sudo -s *very* carefully
* fabbione doesn't use sudo at all
<LaserJock> Yagisan: I was trying to find a Wendy's but I'd have taken Burger King over McDonalds for sure
<Hobbsee> fabbione: logging in as root?
<fabbione> Hobbsee: rarely but yeah
<LaserJock> Hobbsee: he just uses his awesome brain power to force the computer to use super user privileges
<Hobbsee> hehe
* fabbione was tempts to say that he hacks his own machine with kernel exploits to install debs
<fabbione> LaserJock: that's a good answer too
<bddebian> Wendy's Rocks
<LaserJock> heck yeah
* Yagisan liked MOS Burger
<Hobbsee> haha
* Hobbsee throws a few ice cubes at fabbione.
* fabbione starts the 24 hours countdown for the ice cubes travel from .au to .dk
<jsgotangco> lol
<Hobbsee> hehe
<LaserJock> oh wait, they melted over the Indian ocean ;-)
<fabbione> LaserJock: actually no
<fabbione> they won't melt
<Hobbsee> LaserJock: these are *special* icecubes
<fabbione> once you get around 39000 feet you are at about -50 C
<LaserJock> ah, I see
* Yagisan watches them come down as hail instead
<fabbione> so the problem is to find the right speed to push them at that height
<LaserJock> right, I recently found that out (nice monitors on the plane over to France)
<fabbione> too fast and they would melt for friction
<fabbione> too slow and they would melt before the atmosphere temp is 0 or below
<Hobbsee> oh no, dont remind me of physics...
* Hobbsee cowers in a corner
<fabbione> of we assume that once they are 39K feet there is nothing to slow them down
<bddebian> fabbione: Do we have our X guy yet? :-)
<fabbione> otherwise i guess they won't cross the road outside your house :)
<fabbione> bddebian: yes you do have one
<jsgotangco> hehe
* jsgotangco grins
<zul> bddebian: its Mr. X
<Hobbsee> gah!  darned thing
<bddebian> zul: Congratulations and thanks! ;-P
<LaserJock> or was that "bddebian is Mr. X"? ;-)
<fabbione> ok...
<fabbione> so
<fabbione> our new Mr X is...
<bddebian> LaserJock: No, fabbione didn't want me :-)
* Hobbsee isnt.
<fabbione> Hobbsee: that would Mrs
<fabbione> ;)
<LaserJock> Miss
<Hobbsee> bddebian: no, we need you to upload all of our fixes
<LaserJock> or Ms.
<Hobbsee> fabbione: heh.  you'd be surprised at how many people refer to me as a male :P
<Hobbsee> even when i'm there in person DRESSED IN A SKIRT AND TOP!
<fabbione> Hobbsee: i understand i am getting old.. but i can still make the diff...
<Hobbsee> a skirt i tell you!  and still the guy got it wrong!
<bddebian> Maybe they think it's a kilt? ;-P
<jsgotangco> lol
<Hobbsee> no, that was winter uniform, not summer :P
<Hobbsee> and guys dont wear kilts over here
<fabbione> "Doctor, I am 90 years old and i keep running behind young girls!" "and is it bad? you should be happy about it!" "Yeah but i don't remember why!"
<fabbione> ok
<fabbione> so
<fabbione> Mr X
<Hobbsee> after that lovely tangent, yes
* Hobbsee drumrolls for the announcement of who Mr X is...
<fabbione> i am told is from a fantastic country.. full of italians
<fabbione> but it's not italy
<jsgotangco> eh?
<Yagisan> Sounds like here
<fabbione> wonderful land
<fabbione> exceptionally good food
<fabbione> and wine 
<jsgotangco> france?
<fabbione> sorry.. did ever have good wine in france?
* jsgotangco thinks this is like some "Where in the World is Mr. X game"
<bddebian> hehe
<jsgotangco> well we did on the last day
<fabbione> jsgotangco: it was imported from Italy mostlikely :P
<jsgotangco> haha
<fabbione> anyway
<LaserJock> jsgotangco: yeah, I was able to make more than 1 glass of that stuff
<fabbione> so please welcome R*****o  as our new MrX
<fabbione> ops..
<fabbione> i meant.. *od*ri**
<jsgotangco> hahaha
<LaserJock> I like there beef, yum yum
<fabbione> no that doesn't work either
<LaserJock> their
<jsgotangco> fabbione: he denies it vehemently
<fabbione> oh well
<fabbione> rodarvus: !
<fabbione> ^ him
<jsgotangco> :D
<fabbione> he is Mr X
* fabbione claps hands
<LaserJock> \o/
<jsgotangco> welcome the new xorg overlord
<rodarvus> O_O
<Hobbsee> night all
<Yagisan> next up. "Where in the World is Mr. Y game" ;)
<Hobbsee> it's gone 2am
<rodarvus> hi :)
<Hobbsee> hehe
* Hobbsee immediately assigns all bugs to rodarvus in greeting.
<Hobbsee> (all bugs in the ubuntu world)
<iwj> The trouble with a merge is that the ccache priming approach doesn't work.
* rodarvus makes sure LP email points to somewhere with hugh disk space
<rodarvus> huge even
* Yagisan suggests /dev/null It never fills up ;)
<fabbione> rodarvus: no, you just want to forward them back to the (l)users..
<Hobbsee> hehehe
<Hobbsee> mark them all as "need info" then close due to lack of info.
<rodarvus> heh
<fabbione> rodarvus: congratulation and good luck anyway
<fabbione> you are going to do fine
<rodarvus> fabbione, thanks :)
* Hobbsee waves to rodarvus - a much better greeting
<jsgotangco> yes he needs the exercise =D
* Yagisan waves hello to rodarvus. See you also in #edubuntu
* fabbione hands over the X sodomotron remote control
<fabbione> ogra: how does it feel?
<fabbione> ogra: was it painful?
<ogra> what ?
<fabbione> ogra: the goal argentina did :)
<rodarvus> "sodomotron" is [tm]  fabbione ;)
<rodarvus> ogra doesn't likes football
<ogra> ah ...
<fabbione> rodarvus: no, it's older than me :)
* ogra switches oin the tv
<jsgotangco> heh
<fabbione> rodarvus: it comes from XFS
<rodarvus> ahn :)
<jsgotangco> it doesn't look good heh
<Kamion> fabbione: XSF surely :)
<fabbione> Kamion: that too..
<iwj> OK, I give up, what's a gmo file ?
<iwj> Apart from some hideous thing to do with gettext.
<bddebian> Wow, welcome rodarvus :-)
<bddebian> Now, fix xmkmf will ya? ;-P
<Kamion> iwj: compiled .po file
<iwj> Why oh why oh why is it in the `source' then ?
<Kamion> because some upstreams want to avoid requiring a dependency on gettext
<Kamion> usual answer is to just remove the buggers on clean
<Kamion> and rely on dpkg-source to not care
<iwj> Nice.
<Kamion> msgfmt/msgunfmt convert back and forward between .po and .gmo
<rodarvus> bddebian, thanks - problem is I'll still have lots of merging work to do even before thinking of fixing stuff :)
<fabbione> bddebian: that will come natural with the first merge
<bddebian> fabbione: Ah, OK
<bddebian> rodarvus: I don't know a great deal but if I can help in any way, please let me know
<sivan> Riddell: everything's alright with muse?
<Hobbsee> sivan: havent seen him around yet 
<sivan> Riddell: I can ssh in anymore
<sivan> ah,
<sivan> sladen: ping
<Hobbsee> anyway, night all
<sivan> sladen: muse responds to pings, however SSH seems to be down
<rodarvus> bddebian, sure, thanks!
<sivan> sladen: back here, ping me if there's any change.
<jsgotangco> doh
<iwj> What's the current procedure for sync requests ?
<NekoXP_> stand on one leg
<NekoXP_> bark like a dog
<NekoXP_> and flap your arms like a chicken
<bddebian> Hah
<LaserJock> iwj: I believe file a bug and subscribe ubuntu-archive
<Kamion> LaserJock is correct
<iwj> Is this documented somewhere ?
<Kamion> yes, DeveloperResources
<Kamion> under "Syncs"
<iwj> Ah, fool me, I was looking for `sync' in page titles only.
<LaserJock> Kamion: what about people who aren't core-dev or MOTUs? are they ok to file sync bugs?
<Kamion> LaserJock: (when we remember to check) we'll only take sync requests from people who would ordinarily be able to perform the same upload themselves
<Kamion> others can file them if they like, but it's probably not worth the effort, as we'll get somebody in ubuntu-core-dev or ubuntu-dev as appropriate to confirm
<Kamion> and confirming is usually just as much effort as filing it yourself
<sivan> right
<LaserJock> k, thanks for the clarification, I had somebody ask yesterday and I wasn't sure since there isn't really anything that stops them from filing the bug
<LaserJock> but I thought perhaps you guys would look ;-)
<Kamion> I do check, I don't know if Keybuk does
<Keybuk> yeah, I always check
* bddebian starts filing sync requests "just for fun".. :-)
<Keybuk> if my brain can't automatically map a user's ordinary name into their LP id, I tend to first find out who they are :)
<Kamion> right :)
<sivan> Kamion: was you asking me to vertify the wide-dhcpd6 sync yesterday such a case? (a sync bug filed by a non uploader)
<Kamion> sivan: yes
<Kamion> in fact the only such case I've seen for edgy so far
<sivan> interesting. I wonder if there will be more to come :)
<Keybuk> Kamion: I saw a couple in dapper
<Keybuk> my usual first reaction is just to see whether the sync is sane anyway (given they come from a trusted source, and not from code attached to the bug)
<Keybuk> otherwise I've asked somebody more appropriate to confirm
* iwj writes a script for generating sync requests.
<LaserJock> via email? ;-)
<iwj> Well, how else ?
<Kamion> pitti has one of those already ...
<Kamion> http://people.ubuntu.com/~pitti/scripts/requestsync
<LaserJock> we could sure use like an Ubuntu dev script repository somewhere
<Kamion> perhaps I should link to it from DeveloperResources
* Kamion does so.
<iwj> pitti's seems to do stuff with the changelog that mine doesn't.  OTOH mine is a mere 28 lines of sh of which more than half is the template.
<Kamion> The changelog stuff is a bit unnecessary TBH. It's not as if we read it ...
<Kamion> It might be useful to print it for the requestor's information
<Kamion> but it's not necessary in the bug report
<Kamion> anyway, feel free to update DR if you reckon yours is better :)
<NekoXP_> anyone got a definitive document on changing the usplash logo etc.?
<NekoXP_> I found a forum post which says "the png must be 640x400 16 colours" then offers 640x480 24bit pngs for download
<Kamion> iwj: your version's output is quite
<Kamion> poetically metered
<iwj> No, the first one you saw I did by hand.
<Kamion> ah, so you did
<iwj> Kamion: mine on DR> what, and watch it grow into a thousand-line monstrosity ?
<iwj> 51448 is the output from my script.
<Kamion> heh
<iwj> It would have to grow a command line parser and a usage message and about three safety catches and ...
<iwj> Oh, bugger, the ff build has just imploded.
<sivang> iwj: Are you waiting for me to do more editing on HomeUserBackup before you give it another review, or has it just not reached 'current' in your review queu?
<sivang> iwj: (I've done some more as you proposed since paris, also tried to fix sentences some more)
<sivang> iwj: also made sure every use case has an implemetation/design item matching.
<iwj> sivang: Err, I don't think I had it down as a todo list item for me specifically.
<sivang> iwj: ah, okay, no issue then - then I just need to wait for someone from TB to go over it.
<iwj> sivang: Do you want me to pick it up again ?  Probably not until Monday now.
<sivang> iwj: Please do, if you can.
<iwj> sivang: OK.  Nag me if I don't seem to produce any output on Monday.
<iwj> Oh, the bastards:  -DBUILD_ID=2006063018   just to screw up my ccache.
<sivang> iwj: I will, tuesday is spec approval dead line, I should get the other one approved as well by then..
<bddebian> So what is the process for merges that can be syncs now, just file a sync request?
<Kamion> bddebian: yes
<sivang> bddebian: so it seems. This has also worked for me during dapper :)
* bddebian starts flooding LP :-)
<sivang> hmm, portmap's postinst fails to go
<fabbione> sivang: see scrollback
* sivang scrolls
<sivang> bah, I don't have the scrollback :-/ , the server I use for IRC is hosed
<fabbione> sivang: postinst doesn't include the debconf stuff
<fabbione> so it fails
<bddebian> <Hobbsee mode>Kamion, sync that achilles</Hobbsee mode>
<sivang> ah, is anybody working on fixing it already?
<Kamion> I'll do it in a moment
<bddebian> Kamion: I'm only joking, no rush
<Kamion> it's not a problem
<ogra> fabbione, so ?
<Kamion> portmap breakage fix uploaded
<fabbione> ogra: do you call that a victory? ;)
<sivang> Kamion: how do you make db_get work from the postinst script? was an environment variable for debconf's bins missing for that to work?
<ogra> fabbione, well ... semi final is semi final :)
<sivang> Kamion: and thanks for the fix ;)
<sivang> ogra , fabbione : is it germeny against italy or something ? :)
<ogra> sivang, italy has to survive first :)
<LaserJock> mdz: https://launchpad.net/distros/ubuntu/+spec/edubuntu-dynamic-menus has been ready to be reviewed since last Friday, anything I can do on this end to move it along?
<HiddenWolf> LaserJock: you could grovel. ;)
<LaserJock> that's sort of what I was trying to do ;-)
<HiddenWolf> I figured. ;-)
<mdz> LaserJock: as you can see on +specs, there's a backlog of reviews right now.  https://launchpad.net/people/ubuntu-reviewers are the folks who volunteered to do reviews
<LaserJock> mdz: k, just wanted to make sure it wasn't something I'd done
<fabbione> sivang: if we survive this evening, yes..
<fabbione> ogra: that 's not what german news paper said when we *cough*won*cough* with Australia :P
<fabbione> anyway. i need to try to cook and eat something
<fabbione> i am starving and tooth starts to wake up from anestacia
* bddebian hands fabbione some novicaine
<Kamion> sivang: '. /usr/share/debconf/confmodule' is required before using db_*; see the debconf-devel(7) man page
<Kamion> should generally go at the very top of the script, just below #! etc.
<sivang> Kamion: thanks, /me looks at the man page
<crimsun> Kamion: RE: #38272, I'll do that now if no one has uploaded it
* NekoGone is away: trying not to listen to partying Germans and crying Argentinians
<crimsun> err, crap, please reject xserver-xorg-core
* sivang -> away for some time
<dieman> Kamion: prod
#ubuntu-devel 2006-07-01
<bddebian> Heya
<anibal> mdz: ping
<zul> heh...i like the new usplash in edgy
<_ion> Very pretty. :-)
<zul> well at least the new grub works 
<troy_s> is scott usplash man?
<jsgotangco> good morning
<zul> evening
<Hobbsee> morning all
<Who_> What is this 'morning' you talk of :P I see only darkness out my window
<jsgotangco> Who_: don't blame us if we live in the future :P
<bddebian> heh
<Hobbsee> hehe
<Hobbsee> @time sydney
<Ubugtu> Current time in Australia/Sydney: July 01 2006, 12:18:03
<Hobbsee> almost morning :P ^
<bddebian> @time Philadelphia
<bddebian> hehe
<bddebian> @time Eastern
<Ubugtu> Current time in Canada/Eastern: June 30 2006, 22:18:41
<Hobbsee> you've still got plenty of time to stay up!
<LaserJock> hmm, somethings fishy there bddebian ;-)
<Who_> troy_s: what do you think of the brown monstrosity I just posted to the list?
<Hobbsee> Who_: hehe, link?
<profoX`> @time Brussels
<Ubugtu> Current time in Europe/Brussels: July 01 2006, 04:26:03
<Who_> Hobbsee: If you really want to see it, it's here - https://wiki.ubuntu.com/Artwork/Incoming/BrownBubbles - I actually meant to post it to troy in ubuntu-artwork :S
<Hobbsee> hehe oh dear
<_ion> Noooooooo (fade)
<_ion> Not the "crystal" balls, or whatever they're called.
<RadiantFire> lol, i vastly prefer the blue version :-)
<anibal> @time bogota
<Ubugtu> Current time in America/Bogota: June 30 2006, 21:32:47
<anibal> @time miami
<Hobbsee> hi anibal 
<anibal> Hobbsee: hello
<anibal> @time caracas
<Ubugtu> Current time in America/Caracas: June 30 2006, 22:34:05
<anibal> @time buenos aires
<LaserJock> hmm, so bogota and caracas are under America and Philly is under Canada? :-)
<anibal> @time buenos_aires
<Ubugtu> Current time in America/Argentina/Buenos_Aires: June 30 2006, 23:37:09
<anibal> LaserJock: america is from tierra del fuego to alaska :)
<bddebian> Ack, Nooo, we've been invaded by Canukistan..
<anibal> LaserJock: the USA is just one of many countries in the continent calle america :)
<LaserJock> well sure
<LaserJock> but Philly isn't in Canada so I was thinking maybe Caracas would be in Anatartica or something ;-)
<zul> we dont want philly you can have her
<anibal> LaserJock: I see your point now :)
<Hobbsee> ogra: ping?
<Hobbsee> ogra: i've just commented a bug report about those screensavers - will try to fix them once and for all later.  seeing as i reformatted yesterday, it seemed like a good time to test :P
<Hobbsee> and it's annoying me, and i want it fixed.
<azeem> W 31
<azeem> sorry
<sivang> re all
<sivang> hmm, good to have the muse back
<sivang> wops, forgot to run screen, bbl
<sivang> hey raphink , what's cracking? :)
<raphink> hi sivang
<Kamion> dieman: pong
<thuglife> hi
<thuglife> is here anyone working on the ia64 port? it seems that lamont is quiet idle
<pitti> Hello
<Kamion> zul: thanks for the grub merge, but please use the -v<last_version_in_Ubuntu> option to debuild
<Kamion> so that the .changes file is more useful
<zul> no problem
<zul> ...now to enjoy canada day
<sivang> Kamion: I am going to try culmus, okay?
<sivang> (merge)
<Kamion> sivang: sure, though I'd expect it to be a sync. If it isn't a sync yet, then perhaps you should leave it until after the X merge has happened and then it will be a sync
<sivang> Kamion: I see, so you assume that if it
<sivang> crap, CR in error
<sivang> Kamion: so you assume it conflicted due to changes in X font conf , and after X merge from debian will be over, then we could just sync up the package without hassle?
<Kamion> sivang: yes
<Kamion> well, I don't assume, I checked
<pygi> sivang, , poke? :)
<sivang> Kamion: ah :) okay, I'll se e other packages where I can help
<sivang> pygi: hi :)
<pygi> sivang, hey, hey :)
<pygi> sivang, do we want py bindings against trunk or stable release of "Dar" stuff?
<pygi> I suppose stable one?
<sivang> pygi: against the version in sid
<sivang> pygi: since this is going to be synced everntually, if not already so
* sivang checks
<pygi> sivang, oki, that's the most important work for Edgy
<sivang> pygi: are you working on them ?
<pygi> sivang, not yet, but will do :)
<pygi> sivang, if you agree :P
<sivang> pygi: ofcourse I do :p
<sivang> pygi: does it seem complicatd to achieve ?
<pygi> sivang, haven't looked really yet, but it shouldn't be
<pygi> Even if it is, it's better if we do it then use that SWIG stuff :P
<sivang> pygi: we need to pay attention to propogate nicely the complex C++ exception system it has
<pygi> sivang, ofcourse, no worries :)
<sivang> pygi: If you are going to do it, it's gonna need to be completed quickly for edgy. So we could give it proper testing. If not, then we'd better concentrate on making the current support (that uses spawning dar as a subprocss) more robust and give it as much testing as we can before release.
* sivang checks the release schedule
<pygi> sivang, it can be done in let's say a month? (given my current free time allocation :P)
<pygi_> sivang, sorry, dc 
<pygi_> so what do you think?
<sivang> pygi: let see :) Feature Freeze is in September 7th , and I see there almost 2 months to the release from there
<pygi> sivang, that should be good I believe
<\sh> moins
<pygi> hey \sh
<sivang> pygi: yes, if you need only one month to come up with it, it seems alright :) would give us enough time for testing hopefully.
<pygi> sivang, I can be sure next week, Wednesday
<pygi> then all should crystalize :P
<sivang> pygi: however, We'll need to agree on an "interface" between the backend and the front end, since right now there is some ugly hack I am using to make sure the front end can monitor the progress of the backend...
<sivang> pygi: this involves passing the pty fd where dar is runnign to gnome.io_watch 
<pygi> sivang, agreed, write it on TODO :P
<sivang> pygi: It basically breaks the seperation between the backend and the front end, but if we have python dar bindings then this should change and we need to adjust the front ends.
<sivang> pygi: I think I have it there somewhere in the TODO
<pygi> sivang, oki, care to mail me?
<sivang> pygi: btw, the branch is now public and member of ubuntu-dev team, so any universe uploader can commit changs
<pygi> sivang, you do understand I am not a universe uploader? :P
<pygi> sivang, but you can commit changes, that's good :)
<sivang> pygi: right :)
<sivang> I will merge from you then
<pygi> Dar bindings should be packaged, so you can sponsor that upload as well :P
<pygi> (if package is good :P)
<sivang> pygi: sure
<sivang> pygi: I will also check about the dar bindings
<pygi> sivang, doki oki
<china> :)
<china> i want to learn network programming in linux ,can some on tell me what i should to learn? is any good resource for learn it? thanks 
<azeem> china: please ask somewhere else
<china> azeem : why?
<bSON> hi
<sivang> hmmm
<sivang> cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl
<bSON> what do the ubuntu developers think about tighter integration of beagle into the ubuntu desktop?
<bSON> (e.g., adding beagle and mono to the ubuntu desktop core)
<bSON> nothing?
<jsgotangco> hey BenC
<BenC> hello
<neuralis> bSON: it's been in the works for a while
<bSON> neuralis: is there a spec about that?
<neuralis> bSON: not one i remember off the top of my head; check the list on lp
<neuralis> bSON: wouldn't be for edgy, if there was one
<bSON> but i thought edgy would be a bleeding-edge build, open for new features and experiments
<dieman> Kamion: around?
<neuralis> bSON: then better get a spec written. you have until jul 6 to get it approved.
<dieman> whats the best way to get more input on a spec if you didn't get a chance at uds?
<dieman> uds-p, rather
<bSON> neuralis: oh...
<dieman> just email -devel asking for comments?
<neuralis> dieman: that works.
<dieman> ok
<Kamion> dieman: briefly
<Kamion> sorry about the bugmail spam I caused by subscribing ubuntu-dev to bug 51347 for a short period; I'm apparently not really awake yet despite it being mid-afternoon
<Ubugtu> Malone bug 51347 in librpcsecgss "[Edgy MoM]  Please sync librpcsecgss 0.13-1from Debian sid" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51347
<dieman> Kamion: i was wondering, i looked briefly but didn't want to shoot you a duplicate bug, is there already a bug for cases when a usb-storage device grabs sda,sdb,etc before ahci or another sata driver gets loaded in d-i?
<Kamion> dieman: yeah
<dieman> ok
<dieman> hit that one yesterday 
<dieman> i was like 'sdc'?!
<Kamion> don't know the bug number offhand but I've certainly had discussions about it
<dieman> ok
<Kamion> module load order in hw-detect is wrong
<dieman> yah
<dieman> that was it, thanks :0
<dieman> :)
<bSON> neuralis: must I let someone else write a spec, or can I directly add a spec?
* Chipzz wonders... are there any guidelines as wrt -Wl,--as-needed ?
<Chipzz> why doesn't ubuntu use it as a default?
<neuralis> bSON: you can definitely write it yourself
<danny> where I find a clear and simple guide to make a deb file from a normal source tarball
<neuralis> danny: try http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
<Chipzz> danny: I don't think there is such a thing as "an easy way to create a deb"
<Chipzz> but the help system of ubuntu provides some pointers
<neuralis> danny: that said, as with any packaging system, creating a debian package is not a matter of following a list of bullet-point steps.
<Chipzz> danny: start help, and click on ""
<Chipzz>     Ubuntu Packaging Guide
<sivang> danny: the ubuntu packaging guide is a good start, it rather tries to bring in all info into one source
<danny> ok... this guide I know allready... thanks.... 
<Chipzz> danny: there are also multiple choices to make packaging either
<Chipzz> danny: there is dh_make, which will generate a basic debian/rules for you, which you can then edit
<Chipzz> there is dbs, and cdbs, which rely on makefile snippets to make stuff easier (but they do add an extra build-dependency)
<neuralis> cdbs is evil.
<Chipzz> neuralis: I try to avoid it to, but why do you think it's evil?
<danny> there is a package version 1.2.5 from libdvdcss, the stable sources are 1.2.9. I have problems with this lib, so I thought about building a verion 1.2.9 deb file, so apt i able to keep tracking my system changes...
<neuralis> Chipzz: http://lists.debian.org/debian-devel/2006/06/msg00467.html
<bSON> neuralis: but which status should i select? braindump?
<neuralis> drafting while you're working on it
<neuralis> when you're finished drafting, set it to 'review' to ask for a review
<bSON> ok
<bSON> neuralis: there is already a very shortly described spec beagle-integration marked as braindump. can i extend the wiki page and ask for review again?
<neuralis> bSON: sure, go for it
<bSON> good
<neuralis> bSON: but it might make most sense to grab one of the mono guys and just ask what the status is
<bSON> good idea
<neuralis> bSON: the developers are picking their own targets for this release cycle, so unless you're prepared to do whatever work is necessary..
<bSON> yeah... but many things are already implemented, the first issue is if we are willing to make beagle (and thus mono) part of ubuntu-desktop, so the beagle search capabilities are usable by default
<bSON> and i'm ready to do some work if necessary
<lifeless> I think this is something upstream need to move on
<giftnudel> bSON: it might be that it gets dropped because of the size mono + beagle will take on the install cd
<neuralis> giftnudel: getting beagle in is something that's been discussed for a long time; i believe we were blocking on beagle maturing
<bSON> yeah, I already thought about that too...
<giftnudel> of course, I still think size matters
<bSON> and i think some people don't like the idea of mono being in the ubuntu gnome desktop by default
<bSON> because mono apps need more ram and stuff
<_ion> In a way it i wouldn't like it, but if some killer apps use it, it would be acceptable. E.g. tomboy rules (i use it myself) and so will beagle, as soon as it matures enough. I've also heard good things about f-sport, but i don't own a camera.
<_ion> s/sport/spot/
<_ion> Sigh, s/it // :-)
<neuralis> _ion: you don't need a camera for f-spot; it'll just manage a bunch of pictures you throw at it
<_ion> neuralis: Yeah, but i don't have a bunch of pictures to manage. :-)
<bSON> i think that's a reason why one proposed soc2006 project was "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 the same for a "f-spot like application"
<neuralis> bSON: there's a thread right now on -devel about using tracker.
<neuralis> bSON: see also https://wiki.ubuntu.com/IntegratedDesktopSearch
<_ion> On the other hand, if mono were installed but _not loaded_ by default, it wouldn't hurt at all. 
<bSON> _ion: normally mono is only loaded if you call up a mono app
<_ion> Although then users would have to add things like tomboy to their panels manually.
<bSON> there's no mono daemon or such, afaik
<_ion> (I was thinking hypothetically that maybe tomboy would be a part of the default desktop.)
<bSON> anyway, i would find beagle in ubuntu great, a much better desktop experience - windows can't beat that (i've seen no similair feature in my installed windows vista beta 2)
<_ion> As long as it doesn't make the whole system crawl by eating all the available memory and then some. :-)
* _ion has hard time finding information about the "tracker" software.
<bSON> _ion: :) well it has been done in SLED 10, so i guess it isn't too much of a deal
<bSON> (though i didn't test the distro)
<phanatic> mdz: ping
<KaiL> hmm
<KaiL> Stunde gepennt, aber kein Tor verpennt
<KaiL> ops, wrong window
<bSON> KaiL: falsche sprache ;)
<KaiL> that too
<sladen> mjg59: what changes went in between -23 and -25 that are likely to have killed Resume?
<sladen> Kamion: thanks for xara
<jsgotangco> nice!
<sivang> sladen: hey Paul
<sladen> hello sivang, riddell is just talking about Kubuntu and KDE 4
<sivang> sladen: where are you guys?
<sivang> laters folks
#ubuntu-devel 2006-07-02
<sladen> asdf
<Fujitsu> ghjkl;
<bddebian> Howdy
<bddebian> Any idea why gdl wasn't merged/synced?
<irvin> hello! is there a command line equivalent of Synaptic's `generate download script` ?
<sivang> re all
<ajmitch> hi sivang 
<sivang> hey ajmitch 
* sivang is making his two specs are in shape for hopefully final review tomorrow
<sivang> hey lfittl :)
<lfittl> hi sivang :)
* sivang expreimented dist-upgrading including ubuntu-desktop on his edgy chroot, all is good, so going to do this on the laptop now
<jsgotangco> hi
* lfittl is also doing this right now, it's nice that there are no big transitions for edgy
<Hobbsee> hi all
<sivang> lfittl: not YET :-)
<lfittl> sivang: right :D
<sivang> hey Hobbsee 
<Hobbsee> hi sivang 
* sivang dist-upgrades
<slomo> doko_: what happened to python-gdbm?
<slomo> doko_: oh nevermind... it's just python-stdlib-extensions that is missing in ubuntu, probably in NEW ;)
<bddebian> Hello
<Whoopie> Hi, who could acknowledge crimsun's upload to dapper-updates for bug 38272? Thanks a lot!
<Ubugtu> Malone bug 38272 in xserver-xorg-input-mouse "option EmulateWheelTimeout not working" [Medium,Fix released]  http://launchpad.net/bugs/38272
<sivang> slomo: I also noticed these packages were missing dependencies :)
<asac> iwj: ping ... I need a patch :)
<shadeofgrey> hi guys..  i have a non supportr related question...
<shadeofgrey> has anybody addressed the fact that theres a new version of openoffice that updates the entire thing from ver 2.0.2 to 2.0.3? i ask because the update is huge -- it addresses a lot oif critical problems and needs to be added to the update system ASAP.  whos the best person to talk to about an official request?
<BenC> shadeofgrey: Saying the update "is huge" is a sure way of keeping out of updates :)
<shadeofgrey> BenC:  whats the most effective means of getting the new version installed?
<fabbione> shadeofgrey: in edgy it will probably be a natural update
<BenC> in dapper, it probably wont happen
<fabbione> in dapper, it needs a lot of work. 
<fabbione> as BenC says
<shadeofgrey> BenC:  the rewason its so important to me is because im physically handicapped and the new versionm adds some really key accessibility options notr available in any of the older versions and finally allows for external use of other accessibility applications that would increase my overall productivity
<bddebian> Doesn't ltmain.sh determine the libtool libraries?
<shadeofgrey> see this is something i dont understand. why do i have to wait for an entirely new version of ubuntu before upgrades of key applications are made possible?
<fabbione> shadeofgrey: the correct procedure is to file a bug in LP.
<gnomefreak> build it ;)
<BenC> shadeofgrey: because if we didn't have such restrictions there would never be a "released" ubuntu
<fabbione> shadeofgrey: because a stable release is not developed anylonger.
<shadeofgrey> certainly it cant be that hard to build debs that update the version by a single revision numberr
<fabbione> shadeofgrey: otherwise it wouldn't be stable
<fabbione> shadeofgrey: it involves much more work than you think
<fabbione> shadeofgrey: anyway do as i said and file a bug asking for backport
<gnomefreak> shadeofgrey: i think the biggest thing is aadding something unstable to a stable release
<fabbione> shadeofgrey: otherwise absolutely nothing will happen
<BenC> shadeofgrey: the version number isn't an issue, it's the amount of testing that needs to be done to make sure we don't break things for everybody
<shadeofgrey> aleight then how about this...  what if i volunteered to be a dedicated tester of the new release by offering my machine up for the necessary tresting.  when i find bugs then i report them to you guys...
<shadeofgrey> id actually really like to do that if its possible.  it'd be a great way for me to give back to the ubuntu community as a whole
<shadeofgrey> is there siomeone here that would be able to talk me through how to manually do the update ifd i download the appropriate archives and decompress them?
<gnomefreak> shadeofgrey: i would say id build it but i cant build it against dapper
<fabbione> shadeofgrey: the point is you will never be able to cover all test cases that a large userbse does. In any case the problem remain. IF you need a new version (independently from the reason) you need to start filing a bug in LP
<shadeofgrey> what is LP by the way?
<gnomefreak> launchpad
<gnomefreak> launchpad.net
<shadeofgrey> okay..  how does one file a bug through launchpad?
<fabbione> shadeofgrey: open LP and follow the links
<gnomefreak> shadeofgrey: in systemtools ther eis a bug report tool
<mdke> https://help.ubuntu.com/community/ReportingBugs
<mdke> that should have everything
<shadeofgrey> okay and by the way...
<shadeofgrey> i wasnt kidding when i said that im willing to be a guinea pig for new versions of the applications i use most.
<shadeofgrey> and im very anal retentive and meticulolus with documenting problems...  
<fabbione> shadeofgrey: we do understand and appreciate. The problem doesn't change. You just can't cover all test cases.
<gnomefreak> shadeofgrey: easiest way to do that is in a few weeks test edgy ;)
<fabbione> shadeofgrey: including testing the suite on all supported architectures
<shadeofgrey> okay that was  ging to be my next questiuon
<shadeofgrey> i have a 3rd harddisk that i was using to test dapper
<shadeofgrey> and when my primary drive with winxp on it got majorlyt fubared by a trojan i threw the newest version of dapper into my CD drive and created a new installation on my primary disk - wiping out windows...  how do i completely dump the test version of dapper i have on that thirdf disk and replace it with edgy?
<shadeofgrey> because wheni installed dapper on my porimary disk grub failed to create a listing for the other installation of the tesst releSE of dapper onm my third disk
<gnomefreak> shadeofgrey: upgrade it by changign the sources.list to point to edgy and upgrade
<shadeofgrey> but  i cant boot into the version of dapper onm my third disk becausde grub didnt create a link to it in the bootloader i put into the mbr of my primary disk
<shadeofgrey> can i just download an iso of edgy and install it via CD?
<gnomefreak> not yet
<gnomefreak> unless ben is hiding them ;)
<shadeofgrey> okay then  i guess ill wait until the first ISO comes out
<shadeofgrey> well then heres my next question..  when i go to install edgy how do i keep it from creating another version of grub in the mbr of the third diskj where i intend to install the test release of edgy when its available?
<gnomefreak> thats better asked in #ubuntu
<gnomefreak> or ubuntu+1
<shadeofgrey> okay well
<shadeofgrey> i guess the answer doesnt matter until theres sdomething to install... though i suppose i could just install dapper AGAIN on the third disk and then just ereplace the sources.list file with edgy sources
<shadeofgrey> thats probably the easiest way huh
<shadeofgrey> ...yeah
<shadeofgrey> okayt thanks for your time guys
<shadeofgrey> ill get the hell out of youre way now
<Gman> anyone know how i can easily debug a sound problem on dapper?
<sivang> Gman: https://help.ubuntu.com/community/DebuggingSoundProblems
<Gman> thanks
<sivang> Gman: hope this helps :)
<Gman> i'm sure it will
<Gman> just need a rough idea of where i need to go
<sivang> cool
<Gman> sivang, sweet, works now, thanks heaps
<Rinchen> Greetings Devs:  New spec in the wild: Enable CFQ by Default.  Details here:  https://launchpad.net/distros/ubuntu/+spec/cfq-by-default
<Gman> was the master surround that needed to be unmuted
<licio> I have one question, ubuntu resize ntfs partition?
<mjg59> Yes
<licio> right
<sivang> Gman: cool!
<licio> mjg59, desktop-cd?
<licio> or alternate? 
<licio> both?
<licio> :)
<robitaille> both should do it  (but I have only done it with the alternate)
<mjg59> Both
<sivang> licio: I have done it over a T43p with the desktop-cd
<sivang> licio: worked nicely, only stopping the Access IBM stuff from working, and for this as well there is a bug report and a workaround somewhere
<sivang> anyway, going off for some time
<sivang> latersall
<sivang> laters all, eve
<sivang> even
<sivang> err
<sivang> :-)
<licio> sivang, yes.. :)
<licio> I'm write one article for linux-magazine brazil
<licio> :)
<hunger> licio: nick.
<hunger> s/nick/nice/.
<sivang> licio: oh cool!
<sivang> licio: You can always mentione there were a bunch of nice people on #ubuntu-devel willing to help you on your questions :)
<sivang> anyway, I'm really off now.
<hunger> sivang: Now that is nice: "people will help you... aehm... I got to run";-)
* hunger grins at sivang.
<sivang> hunger: hehe, sorry
<sivang> hunger: workrave is already shouting at me for having too much machine time :)
* sivang hugs hunger 
* sivang hugs licio 
<licio> sivang, right.. but I had just one question.. I don't have partitions ntfs... :)
<licio> sivang, hugs
<licio> and thanks ;)
<Chipzz> hrrrm I know this is probably more of a #ubuntu kind of question, but can I install ubuntu-server with the ubuntu-desktop install (not live) cd too?
<neuralis> Chipzz: yes.
<Chipzz> neuralis: thx
<tseng> pitti: can you please re-review MainInclusionReportXsp?
<tseng> pitti: ReportXSP that is
#ubuntu-devel 2007-06-25
<JanC> http://www.fosdem.org/2007/node/81
<pitti> LongPointyStick, Riddell: any idea about bug #121456?
<ubotu> Launchpad bug 121456 in adept "Adept couldn't open APT database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
<pitti> LongPointyStick, Riddell: can you please set an assignee for this? Thank you
* Riddell sets it to mvo
<Kmos> Riddell: bug 104848
<ubotu> Launchpad bug 104848 in hwdb-client "Bad english translation on hwdb-client" [Undecided,Confirmed]  https://launchpad.net/bugs/104848
<Kmos> check this one
<Kmos> i've attached a debdiff
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<keescook> realist: general public security discussions have been moved to the motu mailing list.  If you have a patch upstream won't take, that's a concern -- if it's a "real" problem, we should find a way to convince upstream why it's important.  If that's not possible, carrying the patch in Debian is next best, and finally Ubuntu.
<LaserJock> anybody got a gutsy machine and are willing to do a quick application test for me?
<sbalneav> LaserJock: I'm heading home in a few minutes, where my gutsy box is, what do you need?
<LaserJock> I need an xaos test
<LaserJock> just open it up and try to get to a help/tutorial
<sbalneav> Gonna be around tonight?
<LaserJock> yeah, later is fine
<sbalneav> ok, I'll be home in less than an hour.
<sbalneav> I'll do it for you then.
<LaserJock> np
<sbalneav> see you all later.
<johanbr> LaserJock: Seems to work for me, with xaos version 3.2-4ubuntu1
<LaserJock> johanbr: did you run xaos from the menu or command line?
<johanbr> Command line
<LaserJock> can you try it from the menu?
<ajmitch> hi LaserJock 
<LaserJock> hi ajmitch 
<LaserJock> johanbr: did you get into the actual help or just the help menu?
<johanbr> LaserJock: Oh, sorry I wasn't paying attention. I'll try it from the menu. And I used the help menu to get into one of the tutorials.
<johanbr> LaserJock: It also works running from the menu, going into the help system. The only problem I noticed is that the window has some weird transparency when running under Xgl.
<LaserJock> for some reason in Feisty ${prefix} wasn't getting expanded so it was looking for the help literally in "${prefix}/usr/share/"
<LaserJock> johanbr: ah, is it really light?
<johanbr> yes
<LaserJock> there is a bug report about using xaos and beryl causing that
<johanbr> Alright.
<LaserJock> bug #109406 if you care to add to it
<ubotu> Launchpad bug 109406 in xaos "beryl makes xaos impossible (almost ) to use" [Undecided,New]  https://launchpad.net/bugs/109406
<LaserJock> johanbr: thank you very much for testing that
<johanbr> You're welcome. Glad I could be of help. :)
<lousygarua> how can i reopen a bug which was marked invalid? bug 121995
<ubotu> Launchpad bug 121995 in Ubuntu "Ubuntu logo cropped on launchpad page entry" [Undecided,Invalid]  https://launchpad.net/bugs/121995
<ScottK> lousygarua: Change the status to something other than invald.
<lousygarua> ScottK: i don't have that kind of option. was it blocked by some kind of ultra administrator?
<ajmitch> bugs are generally marked as invalid as a reason
<ajmitch> in this case I'd presume from the title that the bug is in launchpad, not in ubuntu
<lousygarua> ajmitch: not really in launchpad, it's more like a human-error they made
<ajmitch> the first reply also says where to file the bug
<lousygarua> ajmitch: it says "there", i have no idea where is it. i'd put it there in the first place coz it also seems not logical to me to file it under ubuntu
<ScottK> lousygarua: Look at the bug again.
<lousygarua> ScottK: launchpad... hmm.
<LaserJock> hmm, interesting, I hadn't noticed that before
<ScottK> Yep.  That's what the bug is in (and I see it too).
<lousygarua> ScottK: well i still think it's a human-error and not a bug in launchpad but i'll file it there anyway
<LaserJock> shouldn't it just be retargeted to Launchpad
<ScottK> LaserJock: Maybe you know LP ju ju better than I do.  That's the best I could do...
<LaserJock> lousygarua: but the bug is about something in launchpad, not in Ubuntu
<lousygarua> LaserJock: they made it invalid so i guess the bug is dead
<LaserJock> lousygarua: no it's not
<LaserJock> lousygarua: they made that task invalid
<ScottK> It's invaild in Ubuntu, but not Launchpad now.
<ScottK> LaserJock: I just added the LP task.
<lousygarua> ScottK: LaserJock: hmm so how do i add an affected package besides distribution and upstream?
<LaserJock> those are the options
<LaserJock> in this case I think upstream works
<lousygarua> ScottK: LaserJock: hmm i think i'm stupid
<LaserJock> lousygarua: I doubt it
<LaserJock> it takes some getting used to
<lousygarua> ScottK: LaserJock: oh well i'll just file it under launchpad and link to the invalid bug thing
<lousygarua> ScottK: LaserJock: thanks
<LaserJock> lousygarua: no, it's already taken care of
<lousygarua> LaserJock: stealing my karma, are you?
<LaserJock> ScottK just added a task against Launchpad, have another look
<LaserJock> heh, no
<LaserJock> I don't need to steal people's karma
<ajmitch> you're a deity all by yourself without other peoples' karma
<lousygarua> LaserJock: :) j/k
<LaserJock> ajmitch: exactly ;-)
<lousygarua> LaserJock: well, thanks again anyway
* Hobbsee waves
<LaserJock> hi Hobbsee 
<Hobbsee> :)
<ajmitch> Hobbsee!
<Hobbsee> ajmitch!
* Starting logfile irclogs/ubuntu-devel.log
<fabbione_> morning guys
<LaserJock> hi fabbione 
<dholbach> good morning
<LaserJock> morning dholbach 
<dholbach> heya LaserJock
<pygi> morning dholbach and LaserJock 
<dholbach> hi pygi
<pitti> Good morning
<fabbione> hey pitti
<pitti> hi fabbione 
<pitti> fabbione: could you please do me a favour?
<fabbione> pitti: i guess so
<pitti> fabbione: http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html has some sparc-isms; do you have a clean gutsy chroot with only 'main' enabled?
<fabbione> pitti: i can make one for sure...
<pitti> fabbione: and could you try to apt-get install those packages and see what we need to fix to make them installable?
<fabbione> pitti: on it
<pitti> fabbione: thank you
<fabbione> no problem at all
<pitti> fabbione: so, language-selector fails due to adept, and kubuntu-desktop due to language-selector (I hope there's no other reason)
<pitti> fabbione: I guess it comes down to libept FTBFSing on sparc (http://launchpadlibrarian.net/8161201/buildlog_ubuntu-gutsy-sparc.libept_0.5.7_FAILEDTOBUILD.txt.gz)
<fabbione> pitti: i am bootstrapping the chroot right now
<fabbione> sorry this machine is not the fastest i have at the moment
<pitti> fabbione: no problem, just thinking loud
<fabbione> eheh ok
<fabbione> pitti: ept_apt_version: ......Bus error
<fabbione> ^^ non-64bit allignment memory access
<pitti> hm, 0.4.7ubuntu2 still built on sparc
<fabbione> it might build.. sure.. but not run
<fabbione> gcc doesn't detect that at build time
<pitti> fabbione: no, that's an old version; maybe it didn't have a test suite yet
<fabbione> i will look into it.. it might be something totally unrelated that's crashing
<pitti> so it's a runtime failure, but the test suite is run during build
<fabbione> yeah it's all good
<fabbione> i will at least pinpont what fails
<fabbione> but i am not going to patch it...
<fabbione> there is faure to do that
<fabbione> how is ept maintainer anyway?
<pitti> Maintainer: Enrico Zini <enrico@debian.org>
<fabbione> oh boys
<fabbione> enrico: ping?
<pitti> in Debian, it's still depwait on sparc
<StevenK> pitti: I've been looking at merging the new version of ept.
<pitti> StevenK: 'new version'? not from Debian then?
<StevenK> pitti: Sorry, yes from Debian. 
<pitti> Burgundavia: I dont' see a new version in Debian
<pitti> erm, StevenK ^
<pitti> we synced 0.5.7
<StevenK> Ah.
<StevenK> I didn't know that bit.
<pitti> Burgundavia: do you think the marketing team will have time for the tribe2 news wiki page? or shall I prepare for elaborating in the release notes?
<Burgundavia> I will do it
<pitti> Burgundavia: great, thank you
<StevenK> pitti: In terms of stuff I'm qualified to talk about, 3 out of the 4 jasper rebuilds were uploaded last night, leaving rss-glx and graphicsmagick. rss-glx is waiting on the two MIRs, and graphicsmagick blows up fairly spectacularly during a test build.
<Burgundavia> pitti: can you fire an email to -marketing?
<pitti> ogra: edubuntu server/i386 is 14 MB oversized, btw
<pitti> Burgundavia: hm, I did last Friday
<pitti> two, actually
<StevenK> Hurray, someone else filed a bug on packagesearch saying it doesn't work with the new libept.
<pitti> https://lists.ubuntu.com/archives/ubuntu-marketing/2007-June/002085.html
<Burgundavia> pitti: ok
<fabbione> pitti: 
<fabbione>   debtags: Depends: libapt-pkg-libc6.4-6-3.53 but it is not installable
<fabbione> E: Package libapt-pkg-libc6.4-6-3.53 has no installation candidate
<fabbione> that would solve also adept
<pitti> fabbione: ok, so that's really the only reason?
<fabbione> seems like
<StevenK> debtags and adept need a rebuild?
<pitti> fabbione: ok, so it all comes down to the libept FTBFS
<fabbione>   ltsp-client: Depends: usplash-theme-ubuntu but it is not installable
<fabbione> pitti: checking the others
<fabbione> E: Package usplash-theme-ubuntu has no installation candidate
<fabbione> ?
<pitti> StevenK: debtags is DEPWAIT for libept, it'll autorebuild once libept gets fixed
<pitti> usplash-theme-ubuntu |       0.14 |         gutsy | source, amd64, i386, powerpc
<StevenK> Ahhh
<pitti> fabbione: apparently no usplash on sparc?
<fabbione> pitti: but why?
<fabbione> it used to build
<pitti> latest version still does
<fabbione> LP lost the binaries?
<fabbione> ltspfsd -> ltsp-client
<pitti> fabbione: usplash_0.5.2_sparc.deb is on drescher
<fabbione> checking if it is here
<StevenK> But usplash-theme-ubuntu is a seperate source package.
<pitti> fabbione: it's not in PaS
<fabbione> it's not in my local archive
<fabbione> fabbione@gordian:/mirrors/ubuntu/pool/main/u/usplash-theme-ubuntu$ ls *.deb
<fabbione> usplash-theme-ubuntu_0.14_amd64.deb  usplash-theme-ubuntu_0.6_amd64.deb
<fabbione> usplash-theme-ubuntu_0.14_i386.deb   usplash-theme-ubuntu_0.6_i386.deb
<Mithrandir> there's no build for u-t-u on sparc.
<pitti> fabbione: so, drescher's Package.gz does have it
<Mithrandir> that is, for the latest version
<StevenK> Or powerpc
<pitti> Package: usplash-theme-ubuntu
<pitti> Architecture: i386 powerpc amd64
<StevenK> usplash-theme-ubuntu-0.14% grep Arch debian/control
<StevenK> Architecture: i386 powerpc amd64
<pitti> that's explainable
<StevenK> pitti: Bah! :-)
<fabbione> somebody should fix that
<fabbione> usplash works on sparc
<fabbione> or used to
<StevenK> I'm happy to upload 0.15 that sets Architecture to any
* pygi could give debdiff if really needed for u-t-u for sparc
<pitti> fabbione: will do
<pygi> oh well, StevenK can do it :P
<fabbione> oh well
<pitti> StevenK: handing over to you then :)
<fabbione> anybody can do it :)
* pitti goes back worrying about 20 MB of alternate overflow
<pitti> fabbione: thanks for the investigations
<fabbione> pitti: i am going to look into ept failure in a few minutes. i am debugging something worst atm
<fabbione> pitti: libept building now
<StevenK> pitti, fabbione: Just about to upload u-t-u with Arch: any
<fabbione> StevenK: cool thanks
<StevenK> pitti: gutenprint on gutsy_probs looks to be a rebuild, want me to handle it?
<pitti> StevenK: I mailed Till, but if a rebuild really solves is, please go ahead
<pitti> StevenK: I just uploaded a new version maybe four days ago, that's why I had some doubts
<StevenK> Ah, okay. I'm just to leave to go home. I'll look in roughly an hour if Till hasn't already.
* fabbione grrrrs at libept
<dholbach> StevenK: pitti: a rebuild fixes it
* dholbach does an upload
<pitti> dholbach: thank you
* pitti hands fabbione an axe
<fabbione> pitti: so the test suite executed manually works
<fabbione> it BusHorror when executed from the script that does some crazy relink stuff
<fabbione> tests summary: exceptions:4 failures:24 ok:49
<fabbione> root@vultus5:~/libept-0.5.7# echo $?
<fabbione> 0
<pitti> fabbione: so it's just a test suite problem?
<fabbione> pitti: seems so
<pitti> fabbione: in that case, "./run-tests || [ `uname -m` = sparc ]  " might be an appropriate workaround until Debian fixes it :)
<fabbione> pitti: i am ok with whatever solution you prefer
<fabbione> this is C++ and some crazy gcc/ld stuff that i am not sure i want to start digging atm
<fabbione> i am working on some more important and urgent stuff at the moment
<fabbione> like SUN disk label corruption
<pitti> running the test suite on the other arches is still good, but I'm fine with silencing it on sparc; enrico will encounter it on Debian anyway
<fabbione> yeah
<fabbione> worst case i can give sparc access to enrico
<fabbione> that's not an issue
<pitti> fabbione: maybe s/uname -m/dpkg --print-architecture/
<fabbione> pitti: whatever you prefer :)
<pitti> fabbione: could you do that workaround?
<fabbione> pitti: perhaps we want to make it build1 instead of ubuntu1?
<pitti> fabbione: well, it's a modification, so ubuntu1 is necessary AFAICS
<pitti> ... so we should blame it all on Sebastien
<fabbione> pitti: i agree...
<pitti> oh, good morning seb128
<seb128> hey pitti
<fabbione> pitti: anyway i am on it since seb128 it's not even awake yet.. slacker
<pitti> seb128: (just ignore us)
<seb128> oh, people doing my job, cool
<seb128> I can get some extra sleep then ;)
<pitti> seb128: can we do something about downsizing gnome-user-guide? maybe using bzip2 will give us some space back?
<pitti> we need to chop off 20 MB from the alternates somehow
<seb128> didn't you do this previous cycle?
<pitti> seb128: that was ubuntu-user-guide
<seb128> ah
<pitti> (or similar)
<seb128> well, probably yes
<seb128> I'll give it a try
<superm1> Mithrandir, good morning, ping
<pitti> seb128: just as a reminder, please don't forget the Pre-Depends: dpkg (>= 1.10.24)
<seb128> pitti: right
<superm1> ah pitti i wanted to ask you something too.  When composite by default goes live, how are things going to be handled about nvidia prop driver?  Is it going to be preinstalled with restricted manager just notifying immediately in the live env, or just the same as waiting until the reboot to activate them?
<pitti> superm1: we won't enable binary drivers by default yet; ATM compiz will only be enabled on known-good drivers/cards
<pitti> like intel
<superm1> okay thats what i was thinking the case would be
<pitti> other users will end up with metacity
<superm1> pitti, is there any chance that restricted manager could ever get a text frontend so that it can easily be used in things like ubiquity though?
<pitti> superm1: there is already --enable and --disable
<pitti> superm1: I'm fine with implementing other stuff, whatever is necessary
<superm1> pitti, doesn't that still use X though because it calls synaptic to do the package install?
<pitti> superm1: right
<pitti> but ubiquity does, too :)
<pitti> (use X)
<pitti> but we could teach it to work with apt-get, too, when there is no $DISPLAY
<superm1> well reason i'm bringing any of this up, i was attempting to adapt it to the mythbuntu frontend that ubiquity will be getting, and i was wondering if a command line installer such as apt-get could be an option instead
<superm1> because its already in a chroot at the point its getting installed
<superm1> the other problem too though is displaying the license when no $DISPLAY is available.
<pitti> seb128: hm, gnome-user-guide with bzip2 only saves 400 KB
<pitti> darn
<seb128> pitti: not worth doing it then
<dholbach> pitti: do you know why libgnomedb is in main?
<pitti> dholbach: not really, it seems to only depend on itself
<dholbach> ok, we can throw it out then :)
<dholbach> gtk-sharp is the last problem before we can move gda2 to universe
<pitti> ah, build dep of glade, which was in main until recently
<pitti> dholbach: gtk-sharp is in universe
<dholbach> oh?
<pitti> I wonder why anastacia doesn't show libgnomedb then
<dholbach> oh great
<pitti> supported: * libgnomedb2-bin
<pitti> ah
* pitti kicks
<pitti> dholbach: only libgda2 rdep left is planner
<dholbach> I'll drop the build-dep, so we don't have the database exporter plugin until it is ported to gda3
<fabbione> pitti: libept uploaded
<pitti> fabbione: yay, thanks
<fabbione> no problem
<Fujitsu> pitti: Is apport meant to be giving useless bugs like #121710?
<Fujitsu> bug #121710
<ubotu> Launchpad bug 121710 in glabels "glabels crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/121710
<pitti> Fujitsu: not meant to, of course, but it's due to bug 119267
<ubotu> Launchpad bug 119267 in linux-source-2.6.22 "apport patches for CORE_REAL_RLIM and limit overriding do not work any more" [High,Fix committed]  https://launchpad.net/bugs/119267
<pitti> Fujitsu: when you encounter them, please just reject them
<pitti> Fujitsu: well, 'invalid' in the new Malone world now
<dholbach> pitti: planner uploaded
<Fujitsu> pitti: Right, will do.
<dholbach> pitti: once it has built, we can dump gda2
<Fujitsu> Thanks.
<pitti> dholbach: rock
<pitti> oh, we ship python2.4 on the alternates; that seems like a good candiate for kicking
<pitti> doko: ^ do we actually need that for anything?
<Fujitsu> Is there any particular reason that the dist-upgrader error reporting doesn't give the version of the package?
<Mithrandir> superm1: please don't just contentless ping me, it's useless; I respond if I'm around and not if I'm not.
<pitti> bryce, seb128: do we really need both xfonts-75dpi and xfonts-100dpi by default?
* seb128 does know enough about fonts to reply
<dholbach> pitti: due to the fixed glib abi change, lots of g*mm packages have to be rebuilt - expect lots of uploads in a bit
* pitti really misses gutsy-changes@ *sob*
<StevenK> dholbach: If you need a hand, let me know.
<Fujitsu> pitti: Is it coming back at any point in the foreseeable future?
<StevenK> pitti: Oh, now I remember what I wanted to talk you about.
<dholbach> thanks StevenK, I think I'll simply script
<pitti> Fujitsu: I hope today, I'll poke cprov again
<Fujitsu> I would have thought it was fairly urgent.
<pitti> Fujitsu: the problem and solution are clear, it just needs rollout
<Fujitsu> Ah.
<pitti> Fujitsu: it is, absolutely; lack of -changes really sucks
<StevenK> Are the mails that didn't hit there lost forever?
<Fujitsu> I suspect they're easy to regenerate.
<StevenK> pitti: Two or three (I haven't looked deeply) of the packages listed under universe for libwnck are Beryl or Beryl related. Are they going to be killed, or should I fix them?
* Fujitsu likes the idea of killing off beryl
* StevenK does, as well.
<Fujitsu> And is there any reason to keep desktop-effects around?
<pitti> Fujitsu: d-e is in universe now
<pitti> StevenK, mvo: dunno, can we remove the beryl packages for good? have they been merged completely?
<Fujitsu> pitti: Right. As in, does it want to exist at all?
<crimsun> pitti: does http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu/gutsy/daily-20070625.log correspond to daily?
<pitti> Fujitsu: I don't see much reason for it any more
<pitti> crimsun: not sure what you mean exactly
<Fujitsu> pitti: I presume it was demoted because the new Appearance tab replaces it... so it should probably cease to exist, along with all its lovely bugs.
<crimsun> pitti: meaning are those the actual binary packages ending up on daily?  If so, I can cut ~2 MB from alt. for libasound2-plugins
<gicmo> seb128: ALTER
<seb128> gicmo: Alter!
<pitti> crimsun: the ones mentioned in the logs, yes
<pitti> mvo, seb128: do you see any reason to keep desktop-effects even in universe?
<seb128> no
<Fujitsu> Yay :)
<crimsun> pitti: ok, I'll upload a new libasound2-plugins with the ffmpeg bit disabled to buy 2 MB more for alternate.
<Fujitsu> Do we need a removal request bug?
<StevenK> pitti: And I can name roughly 6 people who want to see Beryl dead. :-)
<pitti> seb128: can gnome-control-center C/R/P: desktop-effects then, for clean upgrades?
<pitti> Fujitsu: I'll do it now once we sort out the migration with seb128
* pitti summons carlos
<seb128> pitti: they don't really conflicts, is using C,R,P correct?
<pitti> seb128: right, they don't conflict file-wise, but this is the 'package a now provides the functionality of b, and b is obsolete' case, right?
<pitti> lifeless: ship: * cvs [i386 amd64]     # RobertCollins
<seb128> pitti: well, C,R,P doesn't provide an upgrade path, it just make gnome-control-center installed when you "apt-get install desktop-effects"
<pitti> lifeless: would you be really worried if we moved this from ship to supported? :)
<lifeless> DoIt
<seb128> if it was not installed
<pitti> lifeless: it would save us 1.6 MB from the CD
<pitti> seb128: well, but for people who have control-center installed it would remove d-e on upgrade
<seb128> right
<pygi> hey seb128, how is it going?
<seb128> hi pygi
<pitti> does anyone know something else that we could kick off the alternate CDs?
<seb128> good, slightly busy though
<pitti> hm, we could kick nvidia-glx
<pygi> seb128, k, then I'll bug about GB later on
<lifeless> would it be evil for svn to suggest bzr-svn ?
<Mithrandir> as long as it's a suggests, I don't see why
<pitti> Mithrandir: do you see an imperative reason to keep nvidia-glx in ship?
<thom> hrm, shouldn't bzr-svn Enhances: svn?
<thom> and not touch svn
<lifeless> thom: ah yes, true.
<Fujitsu> thom: Has there actually been a use of Enhances before?
<Mithrandir> thom: except nothing uses enhances, afaik
<thom> Fujitsu: no idea. this seems like a good point to start, though
<lifeless> nothing stops us doing both
<shawarma> pitti: It's "ship" in the seeds that control what ends up on the alternate CD, right?
<pygi> Fujitsu, probably, but neither apt or synaptic use it :P
<lifeless> Enhances for correctness, suggests to make it work
<pitti> shawarma: right, on top of ubuntu-desktop
<Mithrandir> pitti: hardware support? :-P I think we should have it in ship.
<pitti> Mithrandir: so we prefer nvidia over ati? :-)
<Mithrandir> pitti: their driver is less bad, afaik
<pitti> Mithrandir: AFAICS it would be one of the lesser evils for amputation candidates
<Mithrandir> oh well
<pitti> I'm not really sure what accounts for the 20 MB the alternates grew since tribe-1
<pitti> I diffed the file lists, and there were no significant additiosn
<pitti>  * mutt                # ThomMay; we need a basic mail client, this is the best-smallest
<pitti> hmmm
<seb128> pygi: GB?
<thom> pitti: mutt is tiny!
<pitti> thom: 1.3 MB
<pygi> seb128, Gnomebaker
<seb128> pygi: just ask
<pitti> thom: well, 1.1, but it's a start
<fabbione> pitti: what about checking file size of packages from tribe-1 cd and see if one of them exploded in -2 ?
<pygi> seb128, it's not urgent, just do your work now
<pitti> thom: it's my MUA as well, but we have to kick something
<thom> true
<fabbione> pitti: perhaps it's just a packaging error
<pitti> fabbione: something like that, yes; last time it was ubuntu-docs
<pitti> but that's not it
<seb128> pygi: I'm almost busy all the time, you better ask now if you want something :p
<shawarma> Do we really need an MTA on the alternate CD?
<pitti> shawarma: we have evolution
<pitti> oh, MTA
<shawarma> MTA. not MUA
<shawarma> Postfix is in ship.
<pygi> seb128, don't want anything :) Just wanted to see what can we do about insane amount of bugs which GB has, and it's not maintained upstream right now for a long time AFAIK
<pitti> shawarma: well, there is a server mode, but now that we have a server CD, I'm inclined to kick samba and postfix
<fabbione> hmmm no we don't but make sure it won't kill it from the server cd
<shawarma> We have a server CD and if someone wants an MTA, they probably have an internet connection..
<pitti> shawarma: and server is now called 'CLI'
<seb128> pygi: well, triage them or take over upstream ;)
<pitti> fabbione: no, just from ship
<shawarma> pitti: No, I think we should leave samba.
<seb128> pygi: we can't remove it, it has an userbase
<fabbione> IIRC there are a bunch of gnome stuff that use samba
<pitti> shawarma: we have the client stuff anyway, why do we need the server on the alternate so urgently?
<pygi> seb128, it's easy to triage, but we can't create too many patches --> imho, useless when brasero works pretty good. And "haha" on the b) option
<pitti> fabbione: client only
<pygi> seb128, yea, I understand that.
<pygi> seb128, some time in the future (when we can get some sane replacement) I also want to move xfburn (main) to universe, because it's *broken* and *can't* burn a cd
<shawarma> pitti: I think it's commonly used to share files, that's all.
<pygi> but that's pending discussion with Jani
<seb128> pygi: that's from xfce, I can't speak about this one
<pygi> seb128, right, but about GB you can ^_^
<seb128> well, it's being used so we can't remove it
<seb128> and there is no better replacement anyway
<shawarma> pitti: I'm not that passionate about it, I just don't think its removal be as easily justified as postfix'.
<pitti> shawarma: I agree
<pygi> seb128, how come? Brasero isn't better?
<hunger> How can I stop that damn xdg-user-dirs from spamming my homedir with directories?
<seb128> pygi: is brasero working?
<pygi> seb128, what kind of question would that be? xD
<seb128> pygi: I don't burn CDs out of nautilus-cd-burner, I didn't use gnomebacker nor brasero yet
<pygi> seb128, do try. It uses libburn & libisofs
<pygi> I made the packages, it gotta work :P
<seb128> I had the impression that brasero was being actively worked but not stable and ready for mass usage yet
<shawarma> hunger: See $HOME/.config/user-dirs.dirs
<shawarma> hunger: Just set them all to point directly to your $HOME or whereever you want things to land.
<pygi> seb128, do try, you'll change your opinion ;)
<seb128> hunger: no need to be agressive
<pygi> seb128, it doesn't however build on sparc and ppc, I'm after upstream for that
<seb128> pygi: should we promote it to desktop and start shipping it on the CD then?
<pygi> bugs that brasero has right now, and most of them I could solve:
<pygi> https://bugs.launchpad.net/ubuntu/+source/brasero/
<pygi> see bug: https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/91043
<ubotu> Launchpad bug 91043 in brasero "Install Brasero by default" [Wishlist,New]  
<pygi> for my opinion on shipping on cd & installing by default
<hunger> seb128: Sorry. I have to appologize.
<pygi> however yes, indeed ... in the future (be it for gutsy or a gutsy+1) we will have to push a gtk+ cdrecording application forward
<hunger> shawarma: Thanks! and sorry for being so rude.
<shawarma> hunger: Actually, I did not even notice the "that damn" part and then it wasn't so bad at all :)
<seb128> pygi: well, "Brasero doesn't burn audio cd" for example is something which make me tell it's not ready
<pitti> ah, evolution-common alone grew by 4 MB
<pygi> seb128, as I said ... not yet :P
<pygi> seb128, read my comment on that bug =)
<pygi> it can't be pushed to main anyway as sparc and ppc don't build
<pygi> and I have no intention to seriously overhaul upstream code to make it work
<pygi> (might not be like that, but still ... it's still scsi issues, with new parts of the code introduced in 0.5.90)
<pygi> seb128, we'll see, I know =)
<pygi> patience ^_^
<pygi> there are some new things in the works, let's see how it works out
<seb128> right
<doko> pitti: yes, for zope2.x
<pitti> doko: I mean on the alternate CD; AFAICS that was only bzr, and I just fixed that
<doko> pitti: python2.4 shouldn't land on any CD ...
<pitti> doko: right; fixing bzr should save us some 3.5 MB
<hunger> shawarma: I get pretty easily annoyed when my computer suddenly behaves differently:-(
<doko> pitti: but we have to keep it in main
<shawarma> hunger: If that's the case, you shouldn't be running Gutsy :)
<pitti> doko: of course; I'm just worried about the CD overflow ATM
<mvo_> pitti: beryl can go, its now all in compiz-fusion and its considered legacy now. desktop-effects can go too II think, the only reason we may want to keep it is e.g. for xubuntu
<mvo_> pitti:  for people who do not want to install the gnome-control-center depends, but do want desktop-effects :)
<pitti> mvo_: ok; I would be happy about a C/R/P: desktop-effects in gnome-control-center; I'll leave it in universe for now until the xubuntu guys say that they don't want it
<mvo_> pitti: but then, someone needs to fix it a bit harder, its currently working but not great
<Mithrandir> hm, why does ~/.config/user-dirs.locale claim nb_NO?  I haven't used that locale for years.
<pitti> dholbach: libgtkmm-2.4 is new on the CDs (1.2 MB), hmm
<ogra> pitti, yes, i noticed its oversized, the nbd breakage held me back from looking at it
<mvo_> pitti: I'm not sure about the C/R/P, its technically correct, but g-c-c is installed on pretty much every ubuntu system anyway and people who do not have it (e.g. xubuntu) will probably not want it
<pitti> dholbach: oh, gnome-system-monitor uses it now
<pitti> mvo_: I actually intend that for automatically removing d-e on upgrades, when we remove the package from the archive
<pitti> mvo_: i. e. g-c-c should c/r/p to d-e, not the other way round
<seb128> pitti: uses what?
<pitti> seb128: gnome-system-monitor uses gtkmm2.4 now
<seb128> dholbach: BTW, gtkmm2.4 is b0rked, ABI change without soname change it looks like
<seb128> pitti: right
<seb128> pitti: upstream decided that C++ is good
<dholbach> seb128: that was due to the glib change
<dholbach> seb128: I'm doing a mass rebuild now
<seb128> dholbach: new version didn't build since saturday?
<seb128> dholbach: no need to do a mass rebuild, ask pitti to trigger rebuilds
<dholbach> seb128: rebuilds of all packages that depend on the *mm stack
<pitti> seb128: ?
<dholbach> seb128: not rebuilds of ftbfs packages
<seb128> ah
<seb128> pitti: I though dholbach was needed a buildd retry
<pitti> mvo_: ok, thanks; I'll kill beryl then for now
<pitti> ah, ok
<seb128> dholbach: all the packages which built with the broken version you mean?
<dholbach> no, unfortunately all packages
<crimsun> no, all packages.
<pitti> now is the very best time to do intrusive stuff in the archive without getting caught by me :)
<dholbach> pitti: hehe
<iwj> Morning everyone.
<seb128> dholbach: why?
<pitti> hi iwj
<seb128> dholbach: gnome-system-monitor works again since the new gtkmm update without a rebuild for example
<dholbach> seb128: that's one of the few then - try workrave
<dholbach> seb128: it didn't get uploaded during the new glib
<dholbach> and it's what murrayc said
<pitti> ogra: do we really need ltsp on the ubuntu alternates? in particular, ldm is really big and new since tribe-1
<seb128> dholbach: so there is a mm stack breakage and rebuilding apps is not the way to go
<seb128> that means the mm libs broke ABI
<Fujitsu> workrave, paprefs... Anything in `apt-cache rdepends libgconfmm-2.6-1c2`
<dholbach> seb128: it broke because of the glib change
<dholbach> seb128: so there's nothing that broke in g*mm
<seb128> glib changes have reverted
<dholbach> no it was not reverted
<seb128> it should be back to original state
<dholbach> it got changed differently
<ogra> pitti, big ?
<pitti> ogra: 2.2 MB
<ogra> i actually never checked the package size 
<pitti> ogra: ltsp-client and -server are tiny, I don't care, but ldm is heavy
<ogra> pitti, ergh, right thats all the themes, we have kubuntu and xubuntu in now
<ogra> pitti, i think we can drop it for one tribe ...
<pitti> ogra: hm, ldm depends on ldm | sdm-terminal | x-display-manager, so gdm should work as a dependency as well
<Fujitsu> pitti: ldm depends on itself?
<seb128> dholbach: 
<pitti> ogra: I might just be able to blacklist ldm for ubuntu then :)
<ogra> pitti, that breaks ltsp
<pitti> ogra: huh?
<ogra> drop it for tribe 2
<ogra> i'll split out theme packages
<pitti> ogra: if ltsp-client *only* works with ldm and not with gdm, then the dependencies are wrong
<ogra> so you only need to ship the ubuntu theme
<ogra> pitti, it breaks *our* setup 
<pitti> ogra: I mean "blacklist from getting on the ubuntu alternate CD", not "blacklist from getting anywyere"
<ogra> well, its useless on any other CD 
<ogra> its not on the desktop CD
<ogra> and it wont be of any use on the server CD unless we add desktop packages to it
<pitti> ogra: argh
<pitti> ogra: any chance to remove the libgl1-mesa-dri dependency from ltsp-client?
<pitti> ogra: that's a recent addition, and pulls in that 14 MB package
<pitti> ogra: if we fix that, we, by and large, fixed the overflow problem for this round
<ogra> oki
<pitti> ogra: do you really need it? or is maybe a Recommends: the right thing?
<ogra> i have one other fix waiting as well ...
<ogra> i dont think we need it at all
<pitti> yay
<ogra> pitti, i dont think we need it at all
<pitti> ogra: I still got that
<pitti> ogra: that would be awesome; should fix the edubuntu CD as well, I figure
<ogra> lets drop it then, but give me 2h after the package built to do a test bootstrap ...
<ogra> iirc ther e was a dependency problem thats why i added it ...
<pitti> ogra: yup, no problem
<pitti> ogra: we need new langpacks as well, so I might not even build another set of dailies today
<ogra> good
<pitti> hm, where's carlos today?
<ogra> that gives me the necessary testing time
* pitti cowboys the gutsy-changes@ fix into soyuz production
<pitti> someone please upload something to test this :)
<StevenK> Hrm. I don't think I have something ready to upload.
<seb128> pitti: I uploaded something some minutes ago
<pitti> StevenK: ah, gutenprint built everywhere, splendid
<StevenK> pitti: That was dholbach's doing.
<pitti> dholbach: thanks to you then :)
<StevenK> But I said it first. :-P
<ogra> pitti, oooh, that was a merge error, i had already dropped libgl1-mesa-dri before ...
<ogra> timestamp: Tue 2007-06-05 14:23:24 +0200
<ogra> message:
<ogra>   drop uneccesary libgl1-mesa-dri from EARLY_PACKAGES, libgl1-mesa-glx replaces it
<seb128> pitti: I just did an upload
<ogra> :)
<pitti> ogra: cool
<pitti> mvo: what's the current word on bug #121456?
<ubotu> Launchpad bug 121456 in adept "Adept couldn't open APT database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
<pitti> yay -changes@!!
<pitti> ogra: hm, I take it it was actually you and not mdz who uploaded ltsp? the From: is from Matt
<pitti> gpg is from ogra at least
<mvo> pitti: looking
<ogra> pitti, he owns the maintainer field still
* pitti celebrates his first live soyuz hacking
<pitti> ogra: right, but From: should be from Changed-By:, not Maintainer:
<ogra> yeah
<pitti> ogra: has that always been like that?
<ogra> nope
<ogra> just now
<seb128> pitti: you are a launchpad hacker now then? ;)
<pitti> seb128: erm, no :)
<pitti> heh, and seb128's totem upload is From: Ubuntu Desktop Team <ubuntu-desktop@lists.ubuntu.com> now
<pitti> but that's better than nothing
<ogra> fun :)
<seb128> heh
* shawarma -> lunch
<mdz> ogra: I haven't touched the package in ages; maintainer should be updated
<Fujitsu> pitti: It has been sending from Maintainer for some days now... I've seen a few rejected emails to various lists.
<pitti> soyuz bug filed
<pitti> https://bugs.launchpad.net/soyuz/+bug/122086 FYI
<ubotu> Launchpad bug 122086 in soyuz "From: header in -changes@ mails are wrong" [Undecided,New]  
<Fujitsu> What broke everything?
<Fujitsu> Thanks pitti.
<ogra> mdz, oki, i'll update it in the next upload
* pitti discusses with Julian now
<pygi> morning sivang 
<sivang> hey pygi 
<sivang> anybody managed to talk / chat / etc to smurf  ?
<pitti> asac: bug 119814 is marked for tribe-2, but I wouldn't call it a release blocker; do you plan a  firefox upload anyway for tribe-2 or shall we move this?
<ubotu> Launchpad bug 119814 in firefox "/usr/share/doc/firefox/MPL missing in gutsy package" [Critical,Fix committed]  https://launchpad.net/bugs/119814
<sivang> I need either him or someone else for some DNS changes for the ubuntu-il site
<sivang> (I think the DNS the provides us services is somewhat related to the EU cluster of loco teams)
<asac> pitti: i already prepared a cherry-picked upload that for tribe-2 that fixes 2 important issues and adds an apport hook :)
<asac> pitti: one of the important issues is MPL
<pitti> asac: yay apport hook
<asac> pitti: so yes ... will upload as soon as i verified that the build is good
<pitti> asac: I have this on my TODO list:
<pygi> o no, apport again xD
<asac> pitti: we have a pretty cool apport hook
<pitti> add firefox apport hook to suppress crash reports when restart is
<pitti> necessary, and to not file crashes with flash installed
<asac> hilario wrote one that gathers lots of information from firefox profile
<asac> about plugins/extensions
* sivang goes to look for the loco contacts irc channel
<pitti> asac: sounds great
<pitti> pygi: it's not yet enabled by default (kernel is still broken)
<pygi> as long as it's not enabled xD
<Fujitsu> sivang: #ubuntu-locoteams?
<sivang> Fujitsu: why thank you
<asac> pitti: hehe ... i think we should just refuse all crash reports .)
<pitti> asac: I do like the idea of setting UnsupportableReason: when the flash plugin is installed
<pitti> asac: did you implement this as well?
<asac> pitti: i saw that you managed to auto-dupe a gnash crash ... when will auto-dupe detection be enabled for ffox?
<pitti> asac: dupe detection is not restricted to particular packages
<pitti> asac: it runs for all newly filed signal and Python crashes
<asac> pitti: ah cool
<asac> pitti: so can we turn crash submission on again?
<pitti> asac: the macromedia flash plugin of course, not the gnash one
<Fujitsu> Does it file them privately, retrace automatically, etc?
<pitti> asac: no, due to bug 119267; we need a new kernel first
<ubotu> Launchpad bug 119267 in linux-source-2.6.22 "apport patches for CORE_REAL_RLIM and limit overriding do not work any more" [High,Fix committed]  https://launchpad.net/bugs/119267
<asac> pitti: what is this Unsupportable feature about? ... adding a report called 'UnsupportableReason' ?
<pitti> asac: also, I'd like to find some time to implement https://wiki.ubuntu.com/CrashReporting; we now have the LP infrastructure for that
<pitti> asac: see /usr/share/doc/apport/package-hooks.txt
<asac> pitti: will look thanks
<pitti> asac: /usr/share/apport/package-hooks/usplash.py is an example for UnreportableReason:, that works similarly
<asac> pitti: how RCritical do you consider the network-manager bugs ... i have looked into what latest merge did ... and Tonio_ apparently dropped lots of patches ... not only those that are now in patches-not-applied.
<pitti> asac: if we can fix at least some of them, that would be nice
* pygi thinks n-m has always been a problem
<coNP> Hey, Mithrandir can you please have a look at my Openbox / Obconf packages?  (http://revu.tauware.de/details.py?upid=5589, http://revu.tauware.de/details.py?upid=5569)
<pitti> asac: I don't have an internet connection after booting right now, and it breaks people's WEP/WPA with keyring (bug 121605)
<ubotu> Launchpad bug 121605 in network-manager-applet "(gutsy]  segfault on joining secure network" [High,New]  https://launchpad.net/bugs/121605
* Fujitsu +1s that.
<pitti> asac: the patch which makes n-m ignore statically configured devices is really important IMHO
<asac> pitti: i will resurrect as much patches as possible ... from what i see there should be hardly anything working at all
<ogra> err, yes, thats somewhat essential for edubutu
<asac> pitti: for instance 05-debian_backend.patch was completely dropped just because the first hunk was applied upstream
<Mithrandir> coNP: no, sorry, I don't have the time for it right now.  I'm fine with you finding a MOTU and getting the upload through a regular sponsor
<pitti> asac: right, it's pretty much back to the "I grab eeeeeverything" upstream state
<pitti> asac: erk
<pitti> Tooonioooo
<coNP> Mithrandir: okay, thanks
<pitti> asac: if you could look into that, it would be great; I don't dare to throw this at people
<asac> pitti: yeah ... i will see how far i get ... i am now at resurrecting 13-rml-wpa-workarounds.patch
<Fujitsu> seb128: Was that glib2.0 change fixing the *mm breakage? The changelog looks rather truncated.
<seb128> Fujitsu: what is truncated?
<Fujitsu>    * Update the serie
<seb128> Fujitsu: the patch added to 2.13.5-0ubuntu2 fixes the ABI breakage
<Fujitsu> That's all that's there.
<seb128> right, the patch serie was not updated so the patch was not used
<seb128> this upload makes the patch being applied
<Keybuk> you mean "serial" or "series", right?
<seb128> Keybuk: debian/patches/series
<Fujitsu> Keybuk: 'tis what I presume.
<Fujitsu> Aha, series. Not serie
<seb128> serie, series
<Fujitsu> series is the singular. I love English.
<seb128> well, that's a typo
<mvo_> seb128: what upload (sorry, missed the first bit got disconnected - but I have not given up hope *yet* that my connection might get fixed today)
<seb128> I just wanted to upload the change, not to discuss the changelog entry on IRC for half an hour
<seb128> shame that -changes is fixed :p
<mvo_> lol
<StevenK> Heh. Ask the Launchpad guys, they could unfix it. :-P
<seb128> mvo_: glib2.0, I made a typo when writting "series" which seems to confuse Fujitsu ;)
* sivang hugs seb128 and cheers him up
<Fujitsu> seb128: Well, I hadn't seen the previous change, so it seemed pretty random.
<seb128> Fujitsu: read the changelog first, ping people on IRC then is usually a good way to do thing ;)
<seb128> things
<seb128> though I admit the changelog entry is not really verbose
<seb128> mvo_: let me know when you try the new gnome-session if it activates compiz by default correctly for you
<Keybuk> seb128: \o/
<mvo_> seb128: its not in the archive yet, but when it is, I will
<seb128> cool
<seb128> k, lunch time then, bbl
<pitti> mmm, lunch, me too
<fabbione> pitti: libept did build fine all around... i guess we just need to wait the next update for gutsy_probs
<fabbione> OR there is something more blowing up now
<pygi> dholbach, should we get andvare packaged? :)
<Keybuk> I think -changes has broken again
<dholbach> pygi: you said in the blog comment, that you'd do it, no?
<pygi> dholbach, right :)
<dholbach> do it :)
<pygi> understood sir :)
<pygi> ergh, you're tracking me
<pygi> bad sign :P
<dholbach> no, not at all
<dholbach> I just did a comment on that page too
<pygi> I saw, yes :P
<pygi> oki, well, this week then ^_^
<awk> hello, just wondering out of intrest the situation with asterisk (bristuff) I see that on Feisty it's using version 1.2.16, and I know of BoF and DoS vulnerabilities with this version i'm wondering what way would I know if it has been patched or not?
<awk> I do not know of any current patches for older version but yet only later releases to rectify this issue
<Keybuk> mvo: animations plugin doesn't seem to be doing much
<mvo> Keybuk: let me look at it
<pygi> hey jsgotangco 
<jsgotangco> hi pygi
<ogra> uhmm, desktop-effects is bound into a capplet now ?
<ogra> so i cant have a desktop without the option ?
<Keybuk> mvo: I get an "Error: Couldn't load plugin 'animation'" in xsession errors
<Keybuk> ogra: ?
<ogra> Keybuk, enabling desktop-effects breaks on 99% of thin clients ... before i could just remove the desktop-effects package to prevent them shooting both of their feet
<Keybuk> ogra: compiz would be a huge performance improvement for thin clients that have 3D-capable hardware
<ogra> but if the UI element is inside a capplet i cqant easily remove the optiojn
<Keybuk> since window moves, desktop changes, etc. wouldn't result in network traffic
<ogra> Keybuk, yes
<ogra> we prove that in sevilla on the classmate
<ogra> its awesome
<Keybuk> I don't see why the option is a problem
<ogra> but 99% of thin clients dont have 3D capable cards
<ogra> or are not supported by our drivers out of the boox i.e. vfia
<ogra> *via
<Keybuk> I still don't see why the option is a problem
<Keybuk> they'll click the button and nothing will happen
<ogra> not if they log in on the server inbetween and enable it there
<Keybuk> (it shouldn't be a button anyway)
<ogra> (if the server has a capable card)
<Keybuk> it's enabled by default
<ogra> if you log in afterwards on a thin client the system just locks up
<ogra> or if i enable it with a classmate as client and switch over to another one ....
<Keybuk> shouldn't lock up at all; clicking the button will disable compiz, so metacity will be used immediatley
<Keybuk> rather than being used after a hardware test
<ogra> you cant click any button anymore
<ogra> it locks up if it starts compiz at login
<Keybuk> why does it lock up?
<ogra> no idea
<Keybuk> on what range of PCs?
<ogra> i usually doont care about compiz
<ogra> on all my clients i have 
<Keybuk> test tribe 2 on them
<ogra> ~20 different models
<ogra> i wwwwwwill
<mjg59> So fix the bug
<ogra> oops
<mjg59> "This option breaks, so I would prefer to remove this option" isn't the development model we tend to follow :)
<Keybuk> compiz is our default window manager
<Keybuk> if it locks up on all your clients, you're going to have a dull release ;)
<ogra> mjg59, for me the bug is that i asked on every conference we had to not enable any composite stuff by default and was always promised we wouldnt or at least have an oiption to prevent it ... sadly i didnt ask in sevilla again ad was to busy to grasp that you doomed me
<ogra> s/you/the effects team/
<mjg59> ogra: You're not doomed.
<mjg59> Just fix the bug.
<seb128> mvo: small bug, if you enable compiz and it fallbacks to metacity the desktop effects tab indicates that compiz is being used which is wrong
<Keybuk> ogra: if there are bugs, please help fix them
<ogra> i dont want to see an option to enable composite at all 
<Keybuk> ogra: it's an option to disable composite
<mvo> ogra: it should not anymore, we added a bunch of additonal tests. if you could test that with current comiz I would appreciate that
<seb128> ogra: the compiz wrapper makes test to know if compiz should be used or not, you could make it run metacity if LTSP_CLIENT is defined
<ogra> mvo, i'll upgrade everything here as soon as i got the new ltsp packages to test
<mvo> seb128: aha, ok. I will check that out
<Keybuk> ogra: your argument if flawed
<Keybuk> if compiz breaks on some hardware, we should fix that
<mvo> ogra: great, please do that. as I said, the wrapper script should be much better about detecting 
<ogra> seb128, thats what i thought first, but then it wouldnt even be optional anymore ... 
<Keybuk> this is not a justification for removing the option to use, or not use, compositing
<Keybuk> especially on something global like LTSP, given the massive performance improvements of *using* composite
<Keybuk> compiz is *ideal* for LTSP, where the client hardware supports it
<seb128> ogra: well, let's see how badly it breaks first, the wrapper only runs compiz now if all the required xorg options are detected as supported
<ogra> i suspect more and more composite capable clients in the future but they are simply not there yet
<ogra> so it should stay optional ...
<seb128> ogra: it'll not run if your card doesn't do 3d, or has no composite, etc
<Keybuk> ogra: where the client isn't capable, it should fallback to metacity automatically
<ogra> Keybuk, i'll test that
<Keybuk> ogra: where that doesn't work, it is a bug that should be fixed
<ogra> oki
<mvo> ogra: if you could test that before tribe-2, that would greatly appreciated :) sorry, I can't do that myself as I don't have e.g. a via based machine
<ogra> its a charm on supported HW :) 
<ogra> mvo, yep, i have to do a lot of ltsp testing anyway, its on the list
<seb128> grrr, apport bugs being b0rked due to linux
<seb128> pitti: is a new linux package planned for tribe-2?
<pitti> seb128: planned yes, it was promised for last weekend
<seb128> ok, cool
<pitti> fabbione: yeah, I already gave back debtags, and now http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html is clean
<pitti> fabbione: thanks for your help
<seb128> pitti: do you want me to change libgnome to force the dpi to 96?
<pitti> seb128: I'm not sure about this any more
<seb128> k
<pitti> seb128: however, if DPI detection works correctly now, how come that the fonts are so small on 130 dpi? (last bug comment)
<pitti> seb128: as I understood it, fonts should now be the same size on every DPI, shouldn't they?
<seb128> I'm not sure, all that is pretty confusing
<seb128> right
<pitti> so if you think that there's still something broken, we can do the 'fix 96 dpi' hack for tribe, but that's certainly not the final solution
<seb128> right
<shawarma> https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/122090 is marked as a security issue. How can I get to see it?
<seb128> I'll have an another look
<shawarma> At 130 dpi fonts a likely to look smaller than people are used to.
<mdz> shawarma: only the security team can see them (ubuntu-security)
<shawarma> mdz: Ah, well. I suppose they'll fix it then :)
<mdz> shawarma: kees and pitti
<mdz> shawarma: in this case, it's not a security vulnerability, so they should unflag it when they review it
<pitti> shawarma: I removed the private flag, you can see it now
<shawarma> pitti: ta
<mdz> pitti: you didn't remove the security flag, though I wouldn't classify this as a vulnerability
<pitti> shawarma: to be precise, it's the private flag that confines the bug to the subscribers; security just triggers ubuntu-security subscription and is useful for searching
<pitti> mdz: I left it because a non-functioning iptables is sort of security related
<mdz> pitti: your call, but to me, sort-of doesn't count :-)
<shawarma> pitti: Er.. Ok. I don't remember seeing two different check boxes..
<mdz> if a bug in vi causes someone to mangle their firewall config and break their firewall, that isn't a security vulnerability either
<pygi> haha
<pitti> right, but if someone upgrades to gutsy and suddenly loses the firewall, possibly even without noticing, that's our fault, not the one from the admin using vi
<shawarma> 13:56 < crummygummy_> I didn't reallise it but shorewall didn't work for a whole weekend. I figure thats reason enough to call it a  security problem.
<seb128> Mithrandir: your comment about xdg-user-dirs is not really constructive, if you have documents not stored in random directories no default will ever suit you anyway
<seb128> Mithrandir: the fileselector, libraries, etc have to point to one directory
<Mithrandir> seb128: my point is the model is wrong.
<seb128> well, there is no "model"
<seb128> at the moment those applications open an hardcoded location
<seb128> or your user directory
<Mithrandir> sure there is, there's a model of storing all your images together, all your downloads together, etc.
<seb128> xdg-user-dirs just allow you do customize that if you want
<seb128> well, it's nothing new nor due to xdg-user-dirs
<Mithrandir> and not working in that model is a pain.
<Mithrandir> sure there is, since stuff could easily default to where you are currently working, for instance.
<Mithrandir> seb128: and my point about not creating the directories until they are asked for still holds.
<seb128> that's a chicken-egg problem
<seb128> users don't know about Templates if they have no location for them
<seb128> but we should not create the directory before they start using it
<pitti> at least rmdir'ing the unused ones does the right thing
<seb128> Mithrandir: and the locations don't mean your fileselector will not open on the current location
<Rumba> how do i get a list of _all_ packages that are _marked_ as autoremovable (i.e. not just those ones that are _currently_ removable)?
<seb128> but it means that the rhythmbox library option default to Music which you can customize
<pitti> /home/martin/Videos was removed, reassigning VIDEOS to homedir
<pitti> at least it doesn't keep creating the directories :)
<seb128> and that you have a Video bookmark in the totem file selector
<seb128> pitti: right, it's easy enough to remove them if you want
<seb128> and it doesn't create them for existant users
<pitti> seb128: it did create the directory for me
<pitti> directories
<pitti> just on upgrade, with existing user
<seb128> hum, it didn't do it for me
<seb128> it didn't add the bookmarks though, did it?
<pitti> no, it didn't
<seb128> oh, another topic
* Mithrandir ponders solving the problem by just rm-ing the Xsession script.
<seb128> evolution can use bogofilter now
<seb128> what people think about adding bogofilter to the default installation?
<pitti> seb128: small enough
<seb128> pitti: want to do it for tribe-2 or after that?
<pitti> seb128: if it doesn't completely break evolution, we can do it today, but that requires another seed change and ubuntu-meta upload
<seb128> it should not break anything but there is no hurry neither
<pitti> seb128: it's not critical path in any way, so if you want, go ahead
<seb128> k, doing it then
<seb128> let's get some cool testing with tribe-2 ;)
<pitti> critical path is still kernel, but if we don't get one today, we'll go with -6.13
<Mithrandir> seb128: oh, and it doesn't respect the Desktop setting I've already done in Nautilus.
<pitti> oh, indeed, it created another Desktop folder for me, too
* pitti has Desktop == ~, too
<seb128> Mithrandir: how so?
<Mithrandir> seb128: my ~ is my Desktop, so it should have picked that up.
<seb128> ah, right
<seb128> where do you notice the bug?
<seb128> app have special code to handle the desktop case
<Mithrandir> I get a Desktop directory in ~ when I log in, which I used not to have
<seb128> Mithrandir: please open a bug on xdg-user-dirs-gtk about this one
<Rumba> how do i get a list of _all_ packages that are _marked_ as autoremovable (i.e. not just those ones that are _currently_ removable)?
<seb128> Rumba: what do you mean "currently"?
<seb128> apt-get autoremove
<pygi> \
<pitti> Rumba: question for mvo
<pitti> seb128: that doesn't list all packages which are 'auto-installed'
<seb128> ah, ok
<seb128> I didn't understand the question
<Rumba> seb128: there is a set of packages that are marked as auto-uninstallable (or auto-installed), a part of which are "currently" non-uninstallable (because they are needed by other packages). how do i get their list?
<Rumba> mvo: you there?
<Mithrandir> seb128: do you know why user-dirs.locale refers to locale I haven't used in years on this machine?
<mvo> Rumba: you can setup a custom filter in synaptic to do this
<Rumba> seb128: is my question clearer now?
<pitti> mvo: compiz & friends are now in anastacia, because desktop-effects is not in desktop any more; they need to be seeded explicitly now, and put into desktop
<mvo> Rumba: go to settings/filters, create a new one and select "automatic install" in the status tab
<seb128> Rumba: yes
<pitti> mvo: the current CDs don't even ship compiz any more because of that
<StevenK> Does gnome-c-c deal and not show the Appearance tab if compiz and friends are not installed?
<mvo> pitti: ok, will update the seeds now
<Rumba> mvo: i already tried that.... :(
<seb128> Mithrandir: what do you use for LC_MESSAGES?
<Mithrandir> nb_NO.UTF-8
<Mithrandir> the file refers to nb_NO
<mvo> Rumba: and that does not work for you?
<mvo> Rumba: works nicely for me here
<seb128> Mithrandir: right, it strips UTF-8, the encoding is specific in  /etc/xdg/user-dirs.conf
<seb128> Mithrandir: or ~/.config/users-dirs.conf
<Rumba> mvo: so i checked "automatic install" (with or without "installed" at the same time) and i also see uninstalled packages in the custom filter
<Mithrandir> seb128: so what would it say if I actually used nb_NO?
<Treenaks> BenC: I think thinkgeek are selling a "voip phone" like the one I gave you now: http://www.thinkgeek.com/computing/avcards/8837/
<Rumba> mvo: which boxes did you check?
<mvo> Rumba: seeing uninstalled ones is ok, that is not a bug, more of a undesired side-effect. I have a patch ready for this, but it will do no harm
<seb128> Mithrandir: I'm not sure that the non-UTF8 case is handled correctly, I'll have to check
<seb128> Mithrandir: it should write that you use an ISO-8859-something encoding
<seb128> not sure if it does, I didn't try
<Rumba> mvo: now, is there any way to produce this exact list in the console?
<Mithrandir> seb128: well, the nb_NO locale is latin1, so that's kinda implied by the locale.  Wouldn't it then be better to write out nb_NO.UTF-8 and have filename_encoding=locale in /etc/xdg/user-dirs.conf ?
<Rumba> mvo: or, alternatively, is it possible to get a list of manually installed packages only?
<pygi> hya Hobbsee 
<pygi> Hobbsee, closed like 6 k3b bugs more, but we've got some serious problems with that package :(
<mvo> Rumba: the information is stored in /var/lib/apt/extended_states, you should be able to get it from there 
<Rumba> mvo: also, any idea why a "manually installed" checkbox isn't available for custom filters?
<mvo> Rumba: what do you plan to do with it? is there some bug hiding somewhere that you chase?
<pitti> mvo: will you do an ubuntu-meta upload? or shall I?
<seb128> Mithrandir: I'm not sure if would be better, if the current way work .... I'll check with alex why he did it this way
<BenC> Treenaks: ah, cool
<mvo> Rumba: most likely because it was not written
<Rumba> mvo: well, rather some feature missing
<Rumba> mvo: read my last question for that
<Mithrandir> seb128: not if you use legacy encodings.
<mvo> pitti: I don't mind, but I haven't touched the seeds yet
<Rumba> mvo: is it hard to write it?
<mvo> Rumba: no
<Hobbsee> hey all
<Hobbsee> pygi: yay.  oh, how so?
<seb128> Mithrandir: if the encoding is correctly specific what is the problem?
<seb128> you just have to have the locale, encoding combinaison correctly set
<pygi> Hobbsee, most patches in there don't work (i.e. broken or stuff) and I don't like the packaging
<Mithrandir> seb128: it's not.  It just happens to be correct since I am the only user on this system.
<Hobbsee> pygi: are these patches from us, or debian?
<Hobbsee> mvo: please see the critical bug assigned to you, if you havent already done so.  it's blocking kubuntu tribe 2
<Hobbsee> mvo: (adept breaking)
<seb128> Mithrandir: well, you can have a ~/.config/users-dirs.conf with an encoding for your user
<pygi> Hobbsee, it says "kubuntu", but they are almost 99% sure merged from debian packages
<pygi> Hobbsee, that doesn't change the fact that they don't work :P
<Rumba> mvo: COOL! and aptitude must use /var/lib/apt/extended_states too
<pygi> Hobbsee, lemme forward you a mail I sent to tonio and sealne yesterday
<pygi> Hobbsee, sent, please read ^_^
<mvo> Rumba: that is not yet merged, but aptitude upstream said its ready, I will have a look very soon, but help is very welcome :) just check the latest debian packages or the darcs repository of apitutde
<mvo> pitti: seed updated
<Hobbsee> pygi: oh of cousre - but if they're debian's patches, then we should ensure that we tell them that they're stuffed.
* Hobbsee cheers.  NO MORE EXAMS THIS SEMESTER!
<mvo> Hobbsee: I have seen it, but haven't done anything about it yet
<pygi> Hobbsee, sure, but read the mail ^_^
<pitti> Hobbsee: congratulations!
<Hobbsee> mvo: okay
* mvo goes and installs adept
<Rumba> mvo: any chance we got it in gutsy if really ready, as they say?
<Hobbsee> pitti: thanks.  all i learned about electronics was a) how much of it i dont understand, b) how much i hate it.
<pitti> Hobbsee: red is blue and plus is minus
<Hobbsee> pitti: of course.
<Mithrandir> seb128: I think that's a wrong approach to the problem, but there are limits to how much I'm caring to discuss the problem.  I've fixed it for me and hopefully won't see more of it.
<mvo> Rumba: yes, a very good chance
<pygi> Hobbsee, there are patches to most of the problems that users encounter (read: most) but they just don't seem to work
<seb128> Mithrandir: I keep it on my list of things to look at before gutsy
<Hobbsee> pygi: bah.  just change it to cdbs
<Hobbsee> pygi: right, yeah.
<pygi> Hobbsee, I wanted to change entire package, yes :)
<Hobbsee> pygi: it's a main package, so it's not going to get forgottena bout
<pygi> Hobbsee, but dunno how much people will hate me, because we'd diverge from debian a lot then
<Mithrandir> seb128: I'll be happy to give inputs on it if you want it, but it feels like I'm not coming across well, so I don't see a big point of it.
<StevenK> It's still expensive to maintain a large diff.
<seb128> Mithrandir: I didn't wrote the thing, it has been done by alex for FC7 and started being used by GNOME
<pygi> Hobbsee, xfburn is main package as well, so it doesn't work :P
<Mithrandir> seb128: oh sure, nothing personal. :-)
<Hobbsee> pygi: i'd prefer a working package, rather than a small diff.
<pygi> StevenK, true ... but if it gets us a nice and maintainable package ...
<StevenK> There a tradeoff.
<Hobbsee> pygi: if anything, we can just never sync it, and just take debian's patches.
<StevenK> There is, sigh
<fabbione> pitti: no problem at all
<pygi> Hobbsee, that was my intention
<Hobbsee> pygi: then again, maybe debian is open to changing their package
<pygi> Hobbsee, that's less likely, but ...
<Hobbsee> pygi: worht trying
<Hobbsee> pygi: if they say "no" to our fork of the packaging, then thye cant really go "but they didnt tell us!"
<pygi> Hobbsee, lemme see if they have 1.0.2
<seb128> Mithrandir: that's not that "you are not coming across well", I just didn't look at the code much so I've no good reply on why the locale is stored this way yet ;)
<seb128> Mithrandir: I agree that flooding the user dir with new directories is not nice
<pygi> Hobbsee, if they have 1.0.2 lets sync debian packaging, and see what can we do out of it
<Mithrandir> seb128: ok. :-)
<pygi> if it still remains un-maintainable at that state, we could just "fork"
<seb128> adding bookmarks and using it for default libraries location, etc should be fine though
<pygi> Hobbsee, I completely took over brasero for ubuntu, debian packages are bad
<StevenK> pygi: No bug reports in the Debian BTS about that?
<pygi> StevenK, I'm gonna look over it now
<seb128> mvo: are you going to merge your change to other seeds? ;)
<seb128> mvo: just to know if I can be lazy and let you merge the bogofilter change as well :p
<pygi> Hobbsee, no new upstream version in debian yet
<pygi> StevenK, no reports in Debian BTS
<pygi> which is weird
<pitti> seb128: don't push too much stuff on mvo, he's still my slave for bug 121456 :)
<ubotu> Launchpad bug 121456 in adept "Adept couldn't open APT database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
<mvo> seb128: hm, I think only edubuntu would need merging for my compiz change, no?
* mvo is the slave of too many people currently
<seb128> mvo: you need to do merge on all seeds to keep them "uptodate"
<StevenK> mvo: Heh
<seb128> even if there is nothing to merge
<pitti> mvo: it eventually needs to be merged to all seeds (resulting in empty changeset for kubuntu and xubuntu, of course)
<pygi> StevenK, Hobbsee : lemme fetch the debian source package
<Hobbsee> pygi: right.  cool
<mvo> right, it used to be the derived distro people that did that (at least that was my understanding)
<pygi> this k3b will make me insane :-D
<Hobbsee> pygi: heh.  all burning makes you insane.
<pygi> Hobbsee, not true
<pygi> although it could be argued whetever I'm the right person to say that :P
<Hobbsee> haha
<Hobbsee> ah yes, i should do seed-stuff, now that exams are over.
<seb128> mvo: if you update ubuntu-meta makes sure you have the bogofilter change also
<pygi> Hobbsee, great, debian doesn't even have patches/
* pygi hopes it's not a native package, and checks
<StevenK> pygi: I just did a rebuild of k3b. It scares me.
<pygi> StevenK, ubuntu package? I knoow
<pygi> know*
<pygi> I'm trying to fix that mess :-/
<StevenK> My mess?
<StevenK> I didn't think I caused any.
<mvo> Keybuk: animation plugin breakage should be fixed now (just uploaded)
<pygi> StevenK, I didn't say it was your mess
<pygi> StevenK, where did you saw me stating that? :P
<Hobbsee> pygi: haha.  mess must be fixed, then.
<pygi> Hobbsee, debian seems to ship 0 patches
<Hobbsee> pygi: yummy.  then throw all of our bad ones out, and fix the package :)
<pygi> we ship thousands, and most don't work
<Hobbsee> excellent...
<pygi> right, debian does use native packaging
<pygi> they have patches in .diff.gz it seems
<StevenK> That's native patching, not packaging.
<pygi> yes, that one :P
<StevenK> Native packaging involves no .diff.gz.
<Hobbsee> where is bdmurray?
<pygi> found one patch so far inside, and that one is working :)
<pygi> StevenK, yea, sorry
<pygi> StevenK, I messed up the naming ^_^
<pygi> Hobbsee, debian also patched k3b source to look  for cdrskin
<pygi> that's second patch I can find
<Hobbsee> pygi: right
<pygi> Hobbsee, yay, much less patching, and works better
<pygi> rock on!
<pygi> still not pretty packaging, and I don't like that way of patching but meh ...
<Hobbsee> pygi: heh.  fix it :)
<Hobbsee> pygi: if it's dodgy...
<pygi> Hobbsee, but how? I can't do anything without tonio and sealne approval
<pygi> they are the last folks who touched the package
<pygi> and not sure how good is the idea to change entire package so late in the process
<pygi> i.e. it can't be ready before tribe 3 at least
<Hobbsee> pygi: there's no reason it needs to be done by herd 2.   i'm not sure what sealne will say, but i dont think tonio_ will mind.  especially if you're proposing to add a proper patch system, adn clena it up.  they're not stupid
<pygi> Hobbsee, our (ubuntu) package has proper patch system, but packaging is mostly from debian (with minor improvements), and patches don't seem to work
<Hobbsee> pygi: right
<pygi> oh well, I'll just create a new package, so people can argue if they want
<pygi> we can see about uploading it or not later
<Hobbsee> i'd appreciate that, thanks
<Hobbsee> pygi: poek me when you want someone to look it over, and sponsor
<Mithrandir> pitti: any idea why there doesn't appear to be any xserver-xephyr debug symbols available?
<pygi> Hobbsee, yes, after exams
<Hobbsee> pygi: no problem
<pygi> mmhm, I hate when we have to do such stuff, but oh well
<pygi> we did it with brasero, we can do it with this as well
<Hobbsee> :)
<pygi> Hobbsee, for example you remember that normalize thingy, and that cdrecord suid thingy?
<pygi> we have patches for both in the package. go figure
<Hobbsee> pygi: heh.  oookay
* lamont would rather that postfix stayed in ship-seed
<mvo> Hobbsee: debtags breakage seems to be the reason for the error
<mvo> Hobbsee: not the new apt
<pygi> mvo, I thought we rebuilded proper debtags?
<Hobbsee> mvo: yummy.
<pygi> o well
<Hobbsee> mvo: which seems to be a Riddell thing?
<mvo> enrico: http://paste.ubuntu-nl.org/27118/ <- any idea what causes this? we get it when adept_manager is run 
<persia> Archive Admins: there is currently a discussion on ubuntu-motu@l.u.c about the xinetd license.  In summary, the COPYRIGHT file requires that authors of modified versions have their name noted in the COPYRIGHT file for distribution.  Is this a known dead issue, or should there be a patch to /COPYRIGHT in the packaging to comply with this requirement?
<mvo> Hobbsee: well, it looks like the new debtags changed some bits, see http://paste.ubuntu-nl.org/27118/ for the error message
<mvo> seb128, pitti: if a ubuntu-meta upload is still required, I can do that now
<Hobbsee> mvo: right.  will poke Riddell over it.
<pitti> mvo: please go ahead, thanks
<mvo> Hobbsee: Riddell and enrico know best about debtags (especially enrico, he is the mastermind behind it :)
<Riddell> well, I don't know all that much about it
<Hobbsee> mvo: right.  i dont know enrico, but it doesnt look like he's around.
<Riddell> mvo: how do you get that error?
<mvo> Riddell: I used gdb and changed the exception thing so that it has no catch-all at the end
<pitti> Mithrandir: hm, curious; it must have gotten lost in the cronjobs which fetch the dbgsyms from the buildds; way too often, rookery cannot connect to them, and I get cron mails
<mvo> Riddell: lets wait a bit for the input of enrico
<Riddell> mvo: gdb on adept or debtags?
<Mithrandir> pitti: any way to recover or should I just build it myself?
<pitti> Mithrandir: when it was built less than 7 days ago, I can recover
<mvo> Riddell: gdb on adept_manager. I suspect strongly that the new debtags is incompatible with the old copy of the code in libaptfront that adept uses :/
<Mithrandir> pitti: it wasn't.  Oh well, I'll just rebuild
<mvo> pitti, cjwatson: ubuntu-meta gives me lots of removals from minimal (e.g. bash, bsdutils, ... full list at: http://paste.ubuntu-nl.org/27126/). is that expected? (generated with germinate 0.27)
<pitti> mvo: minimal was recently split, there is essential now
<pitti> mvo: erm, not essential, I mean 'required'
<StevenK> pitti: So now there's eight seeds?
<pitti> mvo: so I *think* those removals are ok, since they are bootstrapped and its hard to remove them anyway
<pitti> mvo: cjwatson is not available today, btw
<mvo> pitti: ok, happy to upload then
<pitti> mvo: wait
<pitti> mvo: please don't upload ubuntu1 versions, that looks weird
<mvo> pitti: too late :(
<pitti> bah
<pitti> well, nevermind
<pitti> BenC: just for coordinating tribe-2, is there an upload in the pipe now? if not, then we should just go with the current kernel, I figure
<BenC> pitti: Not yet, but will be in a few hours
<BenC> pitti: should have plenty of time
<pitti> BenC: plenty of time> that only applies to the case of not having to do another upload to fix regressions :)
<BenC> pitti: this upload is pretty tight, plus it fixes apport among other things :)
<BenC> pitti: really need this in, unless we want tribe-2 to have the same kernel as tribe-1
<pitti> BenC: tight> ah, just cherrypicks?
<BenC> pitti: mostly just update to latest, -rc5
<fabbione> we want rc5
<fabbione> badly
<pitti> I don't really want the current one for tribe2 either, but anything that isn't in the archive today can't make it
<seb128> and we want apport working also
<Hobbsee> pitti: that's dependent on your definition of today.
<mvo> seb128: gnome-session change works nicely here for me :)
<seb128> mvo: good ;)
<BenC> pitti: 2.6.22-7.14 uploaded, so may need processing soon (ABI bump)
<pitti> BenC: ah, thanks; I'll watch out for it
<pitti> hey cjwatson_ 
* pitti waves to sabdfl
<sabdfl> hey pitti
<Hobbsee> morning london-type people
<tkamppeter> pitti, ping
<pitti> hi tkamppeter 
<tkamppeter> hi pitti
<tkamppeter> I have a problem with the Tribe 2 build of foo2zjs. It builds on all except 64-bit
<tkamppeter> On 64-bit it breaks on groff segfaulting when trying to make a PDF of all man pages.
<tkamppeter> Go to http://launchpadlibrarian.net/8186699/buildlog_ubuntu-gutsy-ia64.foo2zjs_20061224-3ubuntu1_FAILEDTOBUILD.txt.gz
<tkamppeter> and search for "Segmentation Fault".
<pitti> tkamppeter: that doesn't tell us why it segfaulted, so no idea
<tkamppeter> What to do in such a case? The package has built on 64-bit before and it build on Debian. Therefore I do not want to exclude the manual.pdf from the package.
<dholbach> best to try to reproduce the crash locally and debug it :-/
<pitti> tkamppeter: I gave back the package on ia64, maybe it was just a temporary glitch (no reason to believe that, bug let's try :) )
<pitti> tkamppeter: if it fails again, this needs to be examined on an actual ia64 machine
<pitti> tkamppeter: for now, the world won't end if foo2zjs isn't current on an unsupported architecture :)
<nxvl_> hi all
<nxvl_> pitti: hi!
<pitti> hi nxvl
<pitti> dholbach: oh dear, rebuilding the world?
<pitti> dholbach: I thought that was confined to gtkmm, not to everything linking to glib??
<Hobbsee> pitti: just the world.   not the universe.
<dholbach> pitti: no, not everything linking to glib
<dholbach> pitti: but the ABI breakage was due to glib
<seb128> pitti: only whatever has been built during the glib breakage needs to be rebuilt
<dholbach> pitti: I rebuilt all the c++ packages that have been built since the broken glib
<pitti> ok
<seb128> pitti: the think is that dholbach did a round of non required rebuilds this morning when the glib fix was not working
* pitti hugs dholbach 
<seb128> so an another round is required to undo this one now ;)
* dholbach hugs pitti and seb128 back
* seb128 hugs dholbach pitti
<pitti> I see; I didn't see the first wave, we didn't have -changes then yet
<nxvl_> is there any way in launchpad to filter bugs/proyects by lenguage as in "programs writen in ruby"
<tkamppeter> pitti, the 64-bit build of foo2zjs failed again. So there is a definitive bug.
<BenC> anyone else start getting this with latest gutsy and vmware ws6:
<BenC> /usr/lib/vmware/bin/vmware: symbol lookup error: /usr/lib/vmware/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol: _ZN4Glib9ValueBase4initEm
<siretart> BenC: translation to c++: undefined symbol: Glib::ValueBase::init(unsigned long)
<seb128> BenC: that should be fixed when the gtkmm stack is rebuilt
<BenC> seb128: any idea when that will be or if I can get pre deb of it?
<seb128> BenC: that's the rebuilds we were just speaking about
<seb128> BenC: I think dholbach already uploaded the packages that need a rebuild
<seb128> so like 1 hour
<BenC> seb128: sweet, thanks
<seb128> np
<evand> seb128: can you take a look at 122141 when you have a chance?
<seb128> bug #122141
<ubotu> Launchpad bug 122141 in gtk+2.0 "SIGSEGV in gtk.Button.set_image" [Undecided,New]  https://launchpad.net/bugs/122141
<seb128> evand: having a small code example would be nice
<evand> will do
<seb128> thanks
<seb128> does it happen every time?
<evand> yeah
<evand> with the feisty version as well
<evand> it started recently, within a week or so
<evand> (by feisty version I mean installing the feisty version in a gutsy environment, not using feisty's gtk)
<seb128> evand: that's like due to http://bugzilla.gnome.org/show_bug.cgi?id=437281
<ubotu> Gnome bug 437281 in gtk "gtk_button_set_image destroyes the old image" [Normal,Unconfirmed]  
<pitti> mdz, Keybuk: can one of you please ack the addition of ubuntu-core-dev to the ubuntu-crashes-main team, and ubuntu-dev to ubuntu-crashes-universe? this is for https://wiki.ubuntu.com/CrashReporting
<seb128> evand: is that a tribe-2 ubiquity blocker?
<Keybuk> pitti: that team won't be subscribed to any bugs, or report any bugs, etc.?
<Keybuk> (or have any assigned to it?)
<Keybuk> and s/ubuntu-dev/motu/
<pitti> Keybuk: it will be subscribed to all crash bugs, but not get bug mail
<evand> seb128: yeah, it wont start without it
<Keybuk> pitti: why won't it get bug mail?
<pitti> Keybuk: I set a bogus contact address (does@not.exist)
<mdz> pitti: we have nobody@ubuntu.com for that
<Keybuk> pitti: will that prevent members of that team getting bug mail?
<pitti> Keybuk: according to BjornT, yes
<Keybuk> (even if subscribed separately)
<pitti> mdz: I'm happy to use that as well
<Keybuk> afaik, this will prevent bug mail to any developer for these bugs
<Keybuk> even if it's assigned to them, etc.
<mdz> Keybuk: that's not my understanding
<pitti> that would be weird
<mdz> it's just used in place of (set of member email addresses) for mail to the team
<pitti> it's just yet another subscriber to a bug
<Keybuk> right, but malone dedups bug mails if you're a member of a team subscribed, no?
* pitti asks Bjorn
<mvo_> pitti: if ubuntu-meta is in and compiz is on the CD again, could you roll images?
<mvo_> I would love to do a test of it tonight on various machines
<pitti> Keybuk: I'll try this out once the team is added, just to be sure
<pitti> mvo_: I can do that, yes
<mvo_> pitti: thanks, that would rock!
<Keybuk> mvo_, infinity: why is compiz-fusion-plugins-main in dep-wait?
<pitti> mvo_: erk, ubuntu-meta is in depwait
<pitti> Missing Dependencies:  	germinate (>= 0.28)
<pitti> mvo_: did you change that dependency?
<mvo_> pitti: no, I did not
<Keybuk> pitti: I'm seeing all sorts of strange "does not exist" reports from the buildd
<Keybuk> none of them make sense
<pitti> we only have germinate 0.27 in the archive
<Keybuk> (that one may make sense :p)
<mvo_> pitti: compiz-fusion-plugins is depwait on compiz-bcop (that one is not prompted to main yet it seems)
<mvo_> ^--- Keybuk
<pitti> <BjornT> pitti: yes, other subscribers will get bug mail.  <= mdz, Keybuk; anyway, I'll test this thoroughly before I flip this switch
<mvo_> pitti: this must be colins upload from saturday then, let me check that theory
<Keybuk> http://patches.ubuntu.com/by-release/atomic/ubuntu/u/ubuntu-meta/ubuntu-meta_1.47.patch
<Keybuk> ^ Colin changed the version
<mvo_> unfortunately 0.28 is not in bzr too :/
<mvo_> at least in the launchpad published branch
<pitti> mvo_: 'upload from Saturday'?
<Keybuk> pitti: 1.47, see url
<pitti> ah, of ubuntu-meta, not germiante
<pitti> argh, so it's probably on Colin's local laptop branch or so, and he's still travelling
<Keybuk> has he escaped Edinburgh now?
<pitti> mvo_: you reverted the ubuntu-minimal changes?
<mvo_> pitti: yes
<pitti> mvo_: to work around the germinate requirement?
<mvo_> pitti: yes
<pitti> Hobbsee: ^ FYI, I think that might affect kubuntu-meta, too
<mvo_> pitti: but I did not change the b-d (didn't noticed that chnage)
<pitti> mvo_: so if you upload again anyway, can you please un-ubuntu the version number?
<ogra> mvo_, hmm, no compiy at all anzmore on thin clients, not even on the intel HW
<Keybuk> dch -U is your friend :p
<Riddell> pitti, Hobbsee: merging
<Hobbsee> ok
<pitti> Keybuk: right, but that needs to be put into germinate-update-metapackage
* ogra curses broken keymaps
<pitti> Riddell: merging what?
<mvo_> ogra: ok, but no crashes/hangs too ?
<Hobbsee> pitti: kubuntu seeds, i expect
<ogra> mvo_, nope
<Riddell> pitti: if there was a change to minimal?
<pitti> Riddell: hm, they have been merged only some hours ago
<pitti> Riddell: cjwatson split off 'required' from minimal
<pitti> but removing those from the metapackages shuold be fine
<ogra> mvo_, i'D like to find out why it stopped working though ... but that can happen after tribe2
<pitti> after all, essential and prio: reuqired packages cannot easily be uninstalled anyway
<pitti> bbl, dinner
<mvo_> ogra: sure. if you could put the .xsession-errors file somewhere I can have a look. its quite verbose currently
<nxvl_> again my irc client closes up :S
<ogra> mvo_, well, i rather think its X 
<ogra> glxgears stopped working as well
<nxvl_> is there any way in LP to filter programas, bugs or proyects by language? as in "bugs of apps writen in ruby"
<superm1_> Mithrandir, i wanted to ping you about a few things stuck in NEW yet.
* ..[topic/#ubuntu-devel:[PSyKo] ] : Im a noob
<superm1_> Mithrandir, in edgy, mythtv (source) has been in it since 2007-05-03, and in gutsy libhdhomeun (source)
<superm1_> er actually in edgy its a binary it looks like, because ppc and amd64 made it partly through
* ..[topic/#ubuntu-devel:ion_] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Tribe-1 released
<enrico> mvo_: I've read the backlog.  Oh, damn!  I changed the index file format and I totally forgot about adept
<Keybuk> pitti: err, ok, I'm confused
<Keybuk> you've made ubuntu-core-dev a member of ubuntu-crashes-main
<Keybuk> didn't you want that the other way around?
<Keybuk> oh, maybe not
<Keybuk> I can't see how to allow that though
<Keybuk> and you don't want ubuntu-dev, you want motu, no?
* Keybuk can't remember how that team structure is supposed to work
<Hobbsee> er....where are the binaries for https://launchpad.net/ubuntu/+source/apt-setup/1:0.21ubuntu1 - it doesnt seem to be stuck in the NEW queue, but doesnt seem to be in the archive either.
<pygi> Keybuk, isn't ubuntu-dev = ubuntu-motu or something? o.o
<Hobbsee> pygi: no, ubuntu-dev == motu + core
<pygi> right
<Keybuk> ahh, maybe you do want ubuntu-dev then to include ubuntu-core-dev
<Hobbsee> oh wait.  maybe it is just motu
<Hobbsee> Keybuk: it does
<Keybuk> pitti: why do you need me to do anything about it?  I can only approve new members to ubuntu-core-dev no?  you approve new members to ubuntu-crashes-main
<mvo_> enrico: changed the format means that its very incompatible? so the easiest solbution for tribe-2 (thursday) maybe to revert back to the old debtags?
<Keybuk> pitti: ah, found the "show pending invitations" thing, and done
<Hobbsee> hooray, mail saying as such
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:[PSyKo] ] : noob
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* ..[topic/#ubuntu-devel:E|ite] : d(-_-)b
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@so.good.powerserv35.net]  by Hobbsee
* E|ite was kicked off #ubuntu-devel by Hobbsee (Hobbsee)
<Hobbsee> dude...what?
<[PSyKo] > owned
* ..[topic/#ubuntu-devel:persia] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Tribe-1 released
<gnomefreak> Hobbsee: +t maybe?
<Hobbsee> [PSyKo] : that'd be your bot, wouldnt it?
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
<[PSyKo] > Uuuuh
* mode/#ubuntu-devel [+b *!*@i.love.powerserv35.net]  by Hobbsee
* [PSyKo]  was kicked off #ubuntu-devel by Hobbsee (Hobbsee)
<sladen> oh wow, what fun we're having
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<Hobbsee> sladen: of course :)
<sladen> is it coincidence that SEOmoz just pinged out then?
<Hobbsee> sladen: not sure.
<SEOmoz> hi
<SEOmoz> ?
<Hobbsee> bah.  psyko, you're a moron
<Hobbsee> why should i unban you, if you think that bringing bots in is an acceptible practice, just to emphasise that there's a +t functionality.
<nxvl_> is there any way in LP to filter programas, bugs or proyects by language? as in "bugs of apps writen in ruby"
* Hobbsee shakes her head.
<nxvl_> :(
<Hobbsee> nxvl_: no idea
<ScottK> nxvl_: For Python programs we have two teams for Main and Universe subscribed to all the Python programs.  I think that's the only approach that'd work right now.
<SEOmoz> sladen, , what ?
<persia> nxvl: Not at this time (packages do not have a language tag).
<Hobbsee> sladen: i dont think SEOmoz is related.  the guy didnt get thrown off the network, anyway
<nxvl_> ScottK: so in some way, i can only filter the python packages?
<SEOmoz> well, if you are not sure of something just do not talk about in general, because that is not an ethical behavior. i would think that you blow down the gemel towers, and you do not have brain
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@*.powerserv35.net!#ubuntu-ops]  by Hobbsee
* mode/#ubuntu-devel [-b *!*@so.good.powerserv35.net]  by Hobbsee
* mode/#ubuntu-devel [-b *!*@i.love.powerserv35.net]  by Hobbsee
<ion_> hobbsee: !#ubuntu-ops?
<Hobbsee> SEOmoz: it was a query, not an accusation.  calm down
* netjoined: irc.freenode.net -> kubrick.freenode.net
<Hobbsee> ion_: banforward
<ScottK> nxvl_: Not exactly.  If you are a member of the teams you get bugmail on all the packages.  Dunno if you can do it or not, but if you can get LP to tell show bugs only from packages to which pythoneers is subcribed that'd give you all the Python package bugs in Man.
<SEOmoz> Hobbsee, ok, just my point of view, sorry
<ion_> hobbsee: Ah, ok. I wasnt familiar with that Freenode feature.
<nxvl_> ScottK: ok i will see
<Hobbsee> ion_: :) it's usfeul
<ion_> hobbsee: Yeah
<sladen> SEOmoz: don't worry, if you scroll up you'll see the /topic change.  We were wondering what the root of it was;  and looked at the other people that popped off the network when the +b ban was put in place
<nxvl_> (and do something like that for ruby :P
<Hobbsee> sladen: but a +b is not the same as a +k anyway
<Hobbsee> i'm no staffer
<enrico> mvo_: I think support for the new format can be easyly hacked into libapt-front at a cost of a small performance loss
<ScottK> nxvl_: You'd have to establish a team and the grovel through all the packages to find the Ruby ones.
<sladen> SEOmoz: eg. being banned and then magically popping up from another host.  (Though not in your case).
<Riddell> enrico: what would need to be done for that?
<LaserJock> nxvl_: actually, you might be interested in http://tiber.tauware.de/~lucas/versions/ruby.html
<SEOmoz> i do not say about me, it could happens to another person and that is not correct anyway. So just think what you want, i just do not want to tell yes about that with my silence, and i dont mind of what you think, its nonsense, and because i did not do anything bad and im not a lamer, you can even have all the information by my ISP , i never did something bad, so, i dont care, but you still talking with nonsense, just because something is magic 
<SEOmoz> for you. well, what can i say if you believe that
<ion_> seomoz: Nobody is blaming you for anything.
<Hobbsee> SEOmoz: it was a simple question.  if you want to talk ops stuff, here is not the place.  these guys are not ops, in most cases.  #ubuntu-ops is that place.
<Hobbsee> SEOmoz: "i wonder if" is not the same as an accusation
<Hobbsee> if it were an accusation, then your complaints would be warranted.
<enrico> Riddell: change the debtags index access code and the debtags serializer 
<SEOmoz> Hobbsee, ok, thats right, but if that person insists in talking about that i have to answer, i think, come on, if you analize what was said, you know what i wrote, the end for me, thanks anyway
<enrico> Riddell: it should require me two or three hours of work
<enrico> Riddell: I can't guarantee I can do it before thursday, though
<Hobbsee> SEOmoz: he's not accusing you of anything...you're the one thinking that it's an accusal, where it isnt.  However, this is not the purpose of this channel - it's for ubuntu development
<Riddell> enrico: it would be lovely if you could do that.  I can just upload an old libept/debtags in the mean time
<enrico> Riddell: the new debtags index adds a string table and generates package IDs internally, so that it doesn't need to have the IDs in sync with libapt
<nxvl_> LaserJock: that's a list of the packages in ruby for debian and ubuntu?
<enrico> Riddell: but the result is that you have to look it up using package names and not numbers
<nxvl_> nxvl: and his bugs
<enrico> Riddell: wait until tomorrow morning: if  by tomorrow morning I haven't fixed it, revert
<LaserJock> nxvl_: yep, lucas is a Debian maintainer for Ruby apps and also works in Ubuntu. If you are interested in Ruby he is a good person to talk too
<nxvl_> LaserJock: i will write to him, thnx for the help :D
<enrico> Riddell: OTOH, wrt adept, I have the feeling that either someone who is not mornfall adopts it and ports it to the new libept (helping me to add a few missing apt-related features in libept during the process), or it's going to die of bitrot
<LaserJock> nxvl_: np
<Riddell> enrico: yes, I agree there
<Hobbsee> Riddell: which raises an interesting questoina bout what will happen then
<enrico> Riddell: unfortunately, I've never programmed with QT
<Riddell> enrico: it needs to be maintained/scrapped anyway due to need for KDE 4 port before long
<Riddell> Hobbsee: re-writing in python is tempting
<nxvl_> anothre think i don't really undestand, is, what are those tribes thing?
<enrico> Riddell: this one libept should be easily portable to Python
<pitti> mvo_: compiz-bcop promoted
<mvo_> pitti: cool, thanks
<ion_> gimp-resynthesizer probably needs a rebuild for the new gimp. Should i file a bug report, or is someone who takes care of that kind of stuff online and not busy? :-)
<pitti> what is the difference between ubuntu-dev and motu again?
<LaserJock> ubuntu-dev is motu+core-dev
<pitti> mvo_: hm, so ubuntu-meta still needs to get published
<LaserJock> nixternal: the Tribe releases are like alpha releases as we go along during the development cycle
<pitti> mvo_: it won't make it into the archive before I leave to Taekwondo, so maybe Mithrandir can trigger images
<nixternal> LaserJock: I know that
<nixternal> ;p
<pitti> mvo_: otherwise I'll trigger them at 23:00 CEST when I return
<LaserJock> nxvl_: sorry ^^ was for you
<nixternal> hehe
<pitti> mvo_: but that's going to be a night shift for you then; maybe just test the dailies from tomorrow?
<Hobbsee> heh.  this is where people from multiple TZ's would come in handy
<mvo_> pitti: yeah, guess that is the best option (waiting for tomorrow)
<pitti> Hobbsee: indeed :)
<mvo_> looks like my network interface got swapped when updating to the latest ubuntu kernel. interessing
<pitti> Riddell: with your current libept/debtags uploads, can we move bug 121456 to tribe-3? or does that address something else?
<nxvl_> LaserJock: ok, thnx :D
<ubotu> Launchpad bug 121456 in adept "Adept couldn't open APT database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
<Hobbsee> pitti: should be fine, assuming the old lot works.
<pitti> Hobbsee: ok; can you move this over, please, once it has been confirmed?
<Hobbsee> pitti: will do
<pitti> let's move it to tribe-3, so that we won't forget about this ugliness
* Hobbsee is going to bed soonish, though
<Hobbsee> yeah
* pitti hugs Hobbsee 
* Hobbsee hugs pitti :)
<Hobbsee> see, i do sleep occasionally!
<pitti> well (now + 8 hours) is perfectly sufficient :)
<Hobbsee> hehe
<calc> Hobbsee: wow you are +15 from me
<Hobbsee> calc: yes...catch up! no pont living in the past
<calc> so what is it like to live in tomorrow? ;)
<Hobbsee> well, it means that my exams are over :)
<pygi> good for you
<pygi> I have too much of them
* calc is glad to be done with school
<Hobbsee> :)
<gpocentek> pitti: gnumeric was waiting for goffice B-D, does it need a manual intervention to start building?
<pitti> gpocentek: no, it should happen automatically
<gpocentek> ok,thanks
<pygi> hey glatzor 
<glatzor> hey pygi
<pitti> BenC: I bumped the buildd prios of the kernel, it's building on all arches now
<BenC> pitti: thanks
<BenC> should take 3 hours max on major 4 architectures
<pitti> BenC: I'll NEW them after returning from Taekdonwo (in about 3.5 hours)
<BenC> pitti: germans taking taekwondo...scarry :)
<pitti> BenC: I guess you will still be there at that time for uploading lrm, backports-modules, and ubuntu-modules?
<pitti> Riddell: btw, do you want to test strigi in herd-2?
<pitti> Riddell: I thought you already promoted strigi, clucene, and xapian
<pitti> but they are still in universe
<BenC> pitti: yeah
<pitti> evand: in case cjwatson does not come back in time, do you already know how to rebuild d-i against a new kernel ABI?
<pitti> fabbione: ^ well, you know, right?
<calc> BenC: i learned about HDA over the weekend, fun stuff, heh
<BenC> calc: it's only fun if you like dozens of quirks for dozens of different codecs :)
<BenC> and seems every new HDA audio chipset has a new quirk
<BenC> you'd figure as popular as it is, they would do something interesting like being able to programatically pull the pinouts and stuff from the chip
<calc> BenC: yea
* calc hears a noise, brb
<BenC> just a few bytes of firmware, that's all I ask
<evand> pitti: negative :(
<pitti> evand: ok, no problem
<calc> hmm was nothing
* Hobbsee --> bed.  4am
<Hobbsee> if the world blows up, i didnt do it.
<fabbione> pitti: yes i do
<fabbione> evand: ^^
<tkamppeter> pitti, I have solved the foo2zjs problem (biff)
<fabbione> mdz: any specific reason why ubuntu-meta has ubuntu1 now?
<tkamppeter> I simply ignore the error of manual.pdf not getting built and leave the package without manual.pdf if such an error happens. manual.pdf is a PDF with a copy of all man pages, not very important.
<tkamppeter> pitti, and once doing a change on the package I have also updated to the current upstream version of foo2zjs.
<fabbione> he is not here
<evand> fabbione: ok, good
<dmb> i have a couple of questions
<mdz> fabbione: likely just that dch does it automatically now
<fabbione> mdz: heh
<dmb> how does the debian installer bootstrap the core utilities?
<dmb> does it use debootstrap?
<mdz> dmb: yes
<dmb> mdz: awsom
<dmb> is there a place where I can find development docs for ubuntu advanced installer?
<pygi> dmb, it's mostly d-i
<evand> dmb: https://wiki.ubuntu.com/InstallerDevelopment
<mikmorg> Hello.
<mikmorg> Could someone tell me what the canonical way is to determine if the current OS uses initrd, vs initramfs?
<pygi> who wanna upload stuff? :)
<pygi> ha fabbione! wake up pls ^_^
<pygi> oh well, I'll just wait
<pygi> seb128, you was lucky you weren't here :P
<seb128> when?
<pygi> just a few secs ago :)
<pygi> Otherwise I'd have to bug you :)
<pygi> But oh well ^^
<seb128> what was the bug about? who is going to fix it? ;)
<pygi> seb128, I fixed it, about brasero failing to build on sparc and ppc
<pygi> I wanted a sponsor :)
<seb128> ah, k
<pygi> mr_pouit is supposed to handle that now :p
<pygi> if I could just make him wake up :P
* pygi kicks mr_pouit 
<superm1_> does that mean I could bug seb128..... :)?
<pygi> superm1, nop, I have some things in preparation for him :P
<seb128> you can try, not sure it's going to work though
<superm1_> seb128, i've got a few things that have been sitting in NEW for a while
<superm1_> wanted to see if you could take a gander
<seb128> a while being?
<superm1_> well 05-01-07 on some stuff in edgy
<seb128> edgy?
<superm1_> (backports)
<seb128> I don't do stable
<seb128> did you subscribe ubuntu-archive?
<seb128> I did a round of backport some days ago
<superm1_> well the weird thing is the amd64 and ppc stuff cleared
<superm1_> its just the i386 binaries that didn't 
<seb128> what package is that?
<superm1_> mythtv
<superm1_> http://launchpadlibrarian.net/7544963/mythtv_0.20-svn20070122-0.0ubuntu6%7Eedgy1_i386.changes
<superm1_> that was the upload
<seb128> do you think that edgy still has users? ;)
<seb128> looking
<superm1_> well this came to my attention because of a forums post from someone on edgy
<superm1_> so maybe 1 or 2 .... :)
<seb128> superm1_: mythtv i386 accepted
<superm1_> great seb128 .  one more.
<superm1_> in gutsy, libhdhomerun (source) was uploaded 2007-06-01 and there have been new source packages after it cleared
<superm1_> so i wasnt sure if there was troubles with it or anything
<ion_> amaranth: * debian/patches/01-animation-defaults.patch: - setup animation defaults as specified in the spec  what spec is that? :-)
<seb128> ion_: https://wiki.ubuntu.com/CompositeByDefault
<mikmorg> cjwatson: Hello
<mikmorg> cjwatson: Are you online?
<ion_> seb128: Ah, right. Thanks.
<seb128> ion_: np
<ion_> Yay, Emerald is going to be used.
<seb128> superm1_: why all the libhdhomerun source files +x?
<superm1_> they were distributed that way from what i remember
<superm1_> in the upstream archive
<seb128> superm1_: libhdhomerun accept now
<superm1_> great seb128 thanks
<seb128> you're welcome
<ScottK> seb128: Riddell said I should ping you to discuss possible changes in the default gnupg config for Gutsy.  Would this be a good time to discuss it?
<seb128> ScottK: not really no, I'm about to restart my session to test some compiz changes and it's starting being late, better tomorrow, though I'm not sure I'm the right guy to speak about those, I don't know a lot about gnupg
<geser> ScottK: what will you change in gnupg?
<ScottK> OK.  Any suggestions on who would be the best person to talk to?  We may need a change to support or S/MIME by default in Kmail goal.
<ScottK> geser: Tell it to "use-agent"
<ScottK> or/our S/MIME - oops
<ScottK> seb128: ^^^?
<seb128> ScottK: not sure, you can try cjwatson or Mithrandir or pitti or keescook
<seb128> or Keybuk
<ScottK> seb128: OK.  Thanks.
<seb128> you're welcome
<geser> ScottK: I've looked at but you would probably need gpgsm and gpg-agent moved from universe to main
<geser> the source (gnupg2) is already in main
<geser> gpgsm is already in main
<ScottK> geser: I think they both are, but I may have missed it.  I've got a pending MIR for pinentry which is also needed.
<geser> gnupg-agent is in universe but the source is already in main
<ScottK> geser: You're right about agent.  Looks like another MIR I need to write.  Thanks for pointing that out.
* ScottK wanders off to update his spec....
<geser> ScottK: have you tested what happens if the seahorse-agent and the gnupg-agent are both started?
<ScottK> geser: I haven't (I use Kubuntu).  I gather it's not good?
* ion_ loves keychain.
<geser> I don't know. I only remember that seahorse acts also as a gnupg-agent
<ScottK> geser: I guess I'll add that to my list of things to look into.
<geser> but that shouldn't stop the inclusion to main
<ScottK> Yes.  The config issue is separate from promotion to main.
<pitti> BenC: kernel ia64 NEWed as well (will be published in 80 minutes; I can get it down to 50 if necessary)
<pitti> BenC: so the path is free for l-r-m/ubuntu-modules/backport-modules now
<tkamppeter> pitti, I have solved the foo2zjs problem (biff)
<tkamppeter> I simply ignore the error of manual.pdf not getting built and leave the package without manual.pdf if such an error happens. manual.pdf is a PDF with a copy of all man pages, not very important.
<tkamppeter> pitti, and once doing a change on the package I have also updated to the current upstream version of foo2zjs.
<pitti> tkamppeter: ah, good
<pygi> pitti, you around for a sec?
<pygi> (yes, I know it's very late)
<pitti> one second is fine
<pygi> build on ppc/sparc is behaving
<pygi> http://launchpadlibrarian.net/8190074/buildlog_ubuntu-gutsy-powerpc.brasero_0.5.90-0ubuntu4_FAILEDTOBUILD.txt.gz
<pygi> it complains about something I've solved by a patch
<pygi> (at least I think)
<pitti> pygi: did you check twice? :)
<pygi> pitti, yes :P But might be that something else causes the problem now, although it's the same line
<pygi> just checking again
<pitti> Trying patch debian/patches/ubuntu_02_fix_sparc_ppc_build.patch at level 1 ... success.
<pitti> looks good at least
<pygi> might be that "uchar op_chge_event	:1" lacks ";" at the end :P
<pygi> but that's ergh again upstream issue
<enrico> Riddell: please wait until tomorrow evening (or wednesday morning, just to be on the safe side with timezones and local understandings of 'evening': tomorrow I'll be traveling by trains and planes, so I'll have time to hack
<pygi> pitti, if I change that this sec, could you upload pls? ^_^
<pitti> pygi: I can, please send me a debdiff
<pygi> pitti, yay, thanks
<pitti> pygi: (and a diff.gz/dsc/source.changes, please)
<pitti> tkamppeter: erk @ perl -p -i -e 's/(install.*manual\.pdf)/-\1/' Makefile
<pitti> tkamppeter: can you please re-do this change as a proper patch?
<pitti> tkamppeter: otherwise this will keep changing the Makefile with every build, and it's very non-common practice
* pygi quickly works on it
#ubuntu-devel 2007-06-26
<tkamppeter> pitti, will do so and reupload under the same file names.
<pitti> tkamppeter: thanks
<pygi> pitti, sending now
* pygi hopes it'll work now
<pygi> pitti, you got it, thanks once again
<pygi> ergh, upstream!
<tkamppeter> pitti, foo2zjs source files on my server are replaced now.
<pygi> if this won't work, I'll just bug upstream
<pygi> this scsi stuff has big endian problems
<pitti> tkamppeter: hmm, file date is still 15:18
<pitti> s/date/time/
<enrico> Riddell: tomorrow == tuesday
<Riddell> enrico: great
<tkamppeter> pitti, can you click on "Reload"?
<tkamppeter> pitti, and note that the server is on the west coast of the US.
<pitti> tkamppeter: ah, heh
<pitti> tkamppeter: fine, uploading
<pitti> BenC: \o/ test-apport kernel passes
<BenC> pitti: sweet
<BenC> pitti: lum, ldm, lrm and linux-meta being prepared
<pitti> ldm?
<pitti> lbm?
<tkamppeter> Thanks pitti, so the Tribe 2 users will get some more ugly winprinters supported.
<pitti> tkamppeter: heh
<pygi> pitti, got it?
<pitti> pygi: ah, got it now
<tkamppeter> Rick Richardson is not very distro friendly, but he is very effective in decoding winprinter protocols.
<pygi> pitti, k, great
<pitti> pygi: your changelogs should be a bit more concrete, btw
<pitti> pygi: 'create patch', 'improve patch' is not very useful for readers
<pygi> pitti, got it, sorry about that
<pygi> will improve in the future
<pygi> :)
<pitti> pygi: also, the debdiff you sent is for some feisty package
<pygi> ergh!
<pitti> pygi: ah, you need to s/feisty/gutsy/
<pygi> yes
<pitti> pygi: don't worry, I do it now
<pygi> meh :-/
<pitti> easier than another email round trpi
<pygi> pitti, very sorry
* pygi kicks himself
<pygi> guess I need some sleep, k3b ate me a lot today
<pitti> pygi: uploaded
<pygi> pitti, thanks, hope it'll work
<pygi> if not I'll request point release from upstream or something
<pitti> tkamppeter: uploaded
<pitti> ah, I told that already
<tkamppeter> pitti, thanks.
<pygi> bdmurray, you know ... you should accept me in -qa really :p
<Rumba> mvo: i found a bug: i uninstalled some packages in synaptic but they are still shown as "Auto-Installed: 1" in /var/lib/extended_states! (not sure if "Auto-Installed: 0" packages are still shown, but i don't see why not, so i won't test that.)
<pitti> Riddell: still around by chance?
<Riddell> hi pitti 
<Riddell> I don't smell that much!
<pygi> Riddell, hehe
<pitti> Riddell: can you please test the English and French KDE langpacks on "deb http://people.ubuntu.com/~pitti/langpacks/daily/gutsy/ ./"?
<Riddell> ok
<pygi> pitti, working with upstream now in case this fials
<pitti> Riddell: thanks; German and English Gnome ones look good here
<Riddell> pitti: french and english language packs good here
<Riddell> (in KDE)
<pitti> Riddell: great, thanks; I'll upload the lot then
<pygi> s/fials/fails*
<pygi> ergh
<calc> have a question if i add more uid's to my gpg key and send them to the mit keyserver do they propagate to launchpad eventually?
<crimsun> that is the hope, though I always upload to keyserver.ubuntu.com directly.
<pygi> crimsun, they do propagate
<pygi> ergh, 3:05AM
<calc> crimsun: does it take a while for the web interface to update?
<crimsun> yes, although I've experienced problems with the propagation in the previous release cycles
<pygi> calc, some time, yes
<pygi> crimsun, true
<crimsun> it should not take two and a half weeks to propagate
<pygi> haha, true
<pygi> usually it's few hours
<calc> ah its there now, i sent it directly to k.u.c
<wasabi> hmm. i remember some talk (4 years ago) about buffered dpkg postinst scripts.
<wasabi> what ever happened to that?
<wasabi> (executing update-initramfs once)
<LaserJock> I thought iwj did some work on that
<LaserJock> but I could be wrong
<Hobbsee> hiya
<wasabi> hiya
<RAOF> That was dpkg triggers, right?
<wasabi> i forget.
<wasabi> It was a long time ago. I just know update-initramfs just ran 4 times in a row on my system. ;)
<LaserJock> try TeX or emacs packages ;-)
<RAOF> Heh.
<wasabi> http://lists.debian.org/debian-dpkg/2007/01/msg00047.html
<wasabi> Oh that's recent.
<wasabi> By Debian's time schedule anyways.
<RAOF> Yeah, that's what I was thinking of.
<TheMuso> Update-initramfs/doc caching/etc running only once would be great, especially on older machines.
<bryce> has tribe2 frozen?  I have some new xorg bits to upload if there's still time
<StevenK> bryce: I don't think it has yet.
<Hobbsee> bryce: it hasnt frozen yet
<crimsun> bryce: the topic is normally updated when it is; I'm guessing you have ~3 hrs
<Hobbsee> bryce: pitti hasnt woken up yet, and i cant freeze it
<Hobbsee> no distro team meeting to link it to, this time around
<bryce> crimsun: thanks
<bryce> ok 3 hrs is a bit tight, I'll wait 'til later to get them in
<bryce> hmm, maybe I can at least get the new mesa in, that's fairly important
<StevenK> bryce: If you want/need a hand, I'm happy to help.
<bryce> thanks, I would! 
<StevenK> Okay, point me at stuff, and I'll try. :-)
<Hobbsee> bryce: try - if it's not accepted, it can sit in the unapproved.
<bryce> ok here are the mesa packages:  http://people.ubuntu.com/~bryce/Uploads/
<bryce> unfortunately I wasn't able to get some people to test it out, which I was hoping for since it's a major version number jump.  However, the packaging was quite straightforward and the changes are fairly modest (mostly bugfixes)
<StevenK> bryce: Build, test and install?
<Hobbsee> bryce: what's the difference?
<StevenK> Er, I can't test it, actually.
<bryce> hmm
<Hobbsee> bryce: looking
<Hobbsee> erk....
<ajmitch> hm?
<Hobbsee> bryce: http://rafb.net/p/9Kf55S64.html
<ajmitch> suddenly lost any 3d functionality? :)
<Hobbsee> no, no
<bryce> o_O
<ajmitch> ah, no libgl1-mesa-swx11-i686 package exists?
<Hobbsee> only for -1ubuntu1
<bryce> here are the debs that are created by this mesa package:
<bryce> libgl1-mesa-dev_7.0.0-0ubuntu1_all.deb         libgl1-mesa-swx11-i686_7.0.0-0ubuntu1_i386.deb
<bryce> libgl1-mesa-dri_7.0.0-0ubuntu1_i386.deb        libglu1-mesa_7.0.0-0ubuntu1_i386.deb
<bryce> libgl1-mesa-dri-dbg_7.0.0-0ubuntu1_i386.deb    libglu1-mesa-dev_7.0.0-0ubuntu1_i386.deb
<bryce> libgl1-mesa-glx_7.0.0-0ubuntu1_i386.deb        libosmesa6_7.0.0-0ubuntu1_i386.deb
<bryce> libgl1-mesa-glx-dbg_7.0.0-0ubuntu1_i386.deb    libosmesa6-dev_7.0.0-0ubuntu1_i386.deb
<bryce> libgl1-mesa-swx11_7.0.0-0ubuntu1_i386.deb      mesa-common-dev_7.0.0-0ubuntu1_all.deb
<bryce> libgl1-mesa-swx11-dbg_7.0.0-0ubuntu1_i386.deb  mesa-swx11-source_7.0.0-0ubuntu1_all.deb
<bryce> libgl1-mesa-swx11-dev_7.0.0-0ubuntu1_i386.deb  mesa-utils_7.0.0-0ubuntu1_i386.deb
<bryce> I'm iffy on the order of installation though
<Hobbsee> bryce: mesa-utils seems to be what's depending on libgl1-mesa-swx11-i686
<StevenK> Those libgl packages aren't on people.u.c, though
<calc> sorry for the really stupid question but where are the cd images of ubuntu for 6.06 6.10, they aren't on cdimage.ubuntu.com afaict
<calc> cdimage only holds dvd images, imagine that ;)
<StevenK> cacaupt: releases.u.c
<StevenK> Er, calc: ^
<calc> ah thanks :)
<dmb> using the advanced installer, is there a way to make a graphical installer just like it is on the livecd?
* calc is working on his first security release :)
<calc> Hobbsee: i don't think reminding people about that helps things, heh
* calc notes he is referring to her email to m-c
<Hobbsee> calc: hmm?  oh.  right.  *shrugs*
<fabbione> morning
<ajmitch> calc: what, that the MC is obliged to approve you?
<ajmitch> morning fabbione 
<calc> ajmitch: yea
<calc> ajmitch: even if it is true its not in good taste
* calc isn't sure it is
<calc> Hobbsee: btw your myspace page is sick
<Hobbsee> calc: *grin*
<Hobbsee> calc: but it's a lovely background!
<calc> Hobbsee: it could cause seizures ;)
<Hobbsee> calc: the rationale for it is on the page
<ajmitch> causing seizures?
<calc> i forgot the url
<StevenK> It has, I daresay.
<ajmitch> "I wanted to see how many people were epileptic"
<Hobbsee> www.myspace.com/creamier_oak
<calc> ah yea
* calc shows it to his gf
<Hobbsee> calc: it's just there to prove that myspace is evil.
<Hobbsee> haha
<wasabi> that background is terrible.
<Hobbsee> calc: some of my friends from another online community demanded that i get one.  so i did, secretly, and hyped it up enough that they all went crazy seraching for it.  and then found it, and went "arrrrrghhhh!!!!"
<Hobbsee> it's a *lovely* background!
<calc> i love it, one ups the html blink tag ;)
<Hobbsee> ness is right.
<bryce> Hobbsee: I posted a README listing the order of .debs I installed, and some test results
<Hobbsee> The longer you look at it, the less it bothers you... seriously!
<calc> my gf's reaction was ugh, heh
<bryce> I'm not super familiar with mesa so am not 100% sure I have everything configured right, but it seems to work 
<Hobbsee> haha
<Hobbsee> i like the reactiosn of "OMG, MY EYES!!!  MY EYES!!!" and similar
<calc> yea that is what she said too :)
* calc needs a much faster connection than this 400KB/s one
<Hobbsee> i should really have put a counter on there - just to see how many people's eyes have been burned by it
<Hobbsee> calc: pft.  you must be in au
* calc is downloading ooo for edgy to rebuild while downloading dapper and edgy isos
<calc> Hobbsee: need lots of bandwidth for this ooo stuff :)
<ajmitch> Hobbsee: if he were in .au he'd be at 64Kbps by now
<StevenK> If he was lucky,
<calc> i had 128Kbps in 1998, lol
<Hobbsee> hehe
<calc> hmm i have to be up in 9hr for the CC meeting, ugh
<Hobbsee> awww
<Hobbsee> calc: that's still ages away
<ccm> *moan*
<ccm> hug day, today?
<calc> Hobbsee: but i've been up for like 16hr already :P
<Hobbsee> hehe
<calc> Hobbsee: i think i am going to finish up the security stuff tomorrow
<calc> these downloads won't be done for another 1.5hr in any case
<StevenK> Do you have an edgy build environment?
<calc> StevenK: yea, but its just a chroot not a full runtime environment to test in
<StevenK> Hence the ISO downloading. *nods*
<calc> yea
<Hobbsee> bryce: er...where did you put that readme?
<calc> i wrote some scripts to do chroot builds for any release of debian/ubuntu with ccache setup, etc
<bryce> oops, sorry, it's here:  http://people.ubuntu.com/~bryce/Testing/mesa_7.0.0/README
<Hobbsee> bryce: even at http://people.ubuntu.com/~bryce/Testing/mesa_7.0.0/ there arent all the libgl bits
<desrt> for some reason i have an open /query window with [LongPointyStick] 
<bryce> ah, true, hang on let me upload all of them
<Hobbsee> bryce: therea re more?
<Hobbsee> dpkg: dependency problems prevent configuration of libgl1-mesa-dev:
<Hobbsee>  libgl1-mesa-dev depends on libgl1-mesa-glx (>= 7.0.0-0ubuntu1); however:
<Hobbsee>   Version of libgl1-mesa-glx on system is 6.5.3-1ubuntu1.
<Hobbsee>  libgl1-mesa-dev depends on libgl1-mesa-dri (>= 7.0.0-0ubuntu1); however:
<Hobbsee>   Version of libgl1-mesa-dri on system is 6.5.3-1ubuntu1.
<bryce> Hobbsee: yeah sorry there's about 16 debs total.  I'm uploading.  The DRI ones will take a bit of time to get uploaded but I'll do them last.
<Hobbsee> bryce: ah right, so it's unfinished.  no problem, i understand really well about slow uploads
<wasabi> Hmm. A bit frightening to see ntfsresize in top while upgrading ubuntu.
<Amaranth> Hobbsee: isn't your upspeed slower than dialup?
<Hobbsee> Amaranth: not exactly sure.
<Amaranth> someone was telling me that
<Amaranth> maybe it wasn't you
<Hobbsee> i think it uploads at up to 64K, or 128K
<Hobbsee> i think ours is 128K
<ajmitch> ouch
<Amaranth> i only get 512
<Hobbsee> it's a bit nasty, yes.
<hansin321> I have a triple-boot system, and would like to upgrade my Feisty install to Gusty Tribe/Testing to help find bugs etc.  Can I do this via a dist-upgrade command or do I need to do a fresh install from CD?  Thanks.
<hansin321> Gutsy*
<Hobbsee> that's why i'll usually try to transfer to a US host, or not build on thsi machine
<Hobbsee> hansin321: #ubuntu+1 - you can do either.
<Hobbsee> hansin321: there's cds to test in hte next day or so, though
<hansin321> Hobbsee: Ok, thanks.  I'll move to that channel for this.
<wasabi> heh. initramfs being generated for the 11th time now
<Hobbsee> hansin321: so, if you want to wait for a day or so, and test out a cd for us, that would be supercool
<StevenK> wasabi: I am so looking forward to that being fixed.
<hansin321> Hobbsee: Ok, so it would be better for you guys to have me do a fresh install.  Do you think I would be relatively safe in regards to my other partions?  My plan was to remove those from my current fstab then update.  But I suppose I can choose in the installer to not mount these.
<hansin321> I would be more than happy to help out with testing an install.
<wasabi> Why would one do a fresh install of Ubuntu?
<Hobbsee> hansin321: well, it's a test cd - so backups are good.  ie, the tests are done to check that the cd doesnt kill your dog.
<wasabi> I think massive file system corruption is hte only reason I can think of . ;)
<Hobbsee> or your hard drive, or whatever...
<Hobbsee> wasabi: i found stacks of cruft from my edgy --> feisty + beryl --> gutsy install.
<wasabi> ... so fix them.
<wasabi> They're all just files or packages.
<wasabi> There is no registry. :)
<wasabi> I've been running the same install ... since woody.
<wasabi> And I'm on gutsy. ;)
<wasabi> And yes, I mean Woody. The Debian release.
<Fujitsu> Impressive.
<hansin321> When there is a major architectual change between versions (not just package upgrades, but a major change).  How does the upgrade process know how to apply these?
<Hobbsee> wasabi: and i wanted to download a cd, so then i could rsync it
<wasabi> hansin321: Every thing on the system is in a package.
<wasabi> Everything.
<wasabi> There is nothing outside of them.
<wasabi> Except for your own documents, anyways.
<desrt> wasabi; -almost- true
<wasabi> What have I missed? :_)
<desrt> wasabi; the installer is responsible for some stuff
<wasabi> heh. dpkg comes in a package last I checked. =)
<desrt> desrt@moonpix:~$ dpkg -S /etc/fstab
<desrt> dpkg: /etc/fstab not found.
<desrt> for example...
<wasabi> oh that's true.
<Fujitsu> Not much stuff, but a fair bit.
<Fujitsu> Like that.
<wasabi> fstab, initial passwd entry.
<Fujitsu> Enough to be painful to do manually, as I found.
<hansin321> wasabi: So if there is a new package to a system (or one that is not longer needed), say Upstart vs. old init system, is there some sort of metapackage that indicates what MUST be istalled (since for example there was now Upstart in the previous version)?
<wasabi> I've reformatted my file system 3 times... switched hard disks and complete machines too.
<wasabi> I usually jsut tar up my / and untar it on the new system.
* Fujitsu hits the Feisty installer dieing when he played with LVM too much.
<Hobbsee> hansin321: yes
<bryce> Hobbsee: ok .debs are up.  
<wasabi> hansin321: Unless there's a bug, yes, that's how it works.
<Hobbsee> bryce: woot :)
<wasabi> hansin321: upstart declares that it conflicts and replaces with the old init system. And it is programmed to handle that transition.
<bryce> there's one dri-dbg deb left to upload, but you won't need that, and it'll take 30 min to upload
<hansin321> Thanks.  I had wondered about that in the past.
<wasabi> Any failure to take a upgrade path into account is a bug.
<wasabi> So, you should file a bug on it. :)
<wasabi> And desrt is right. There are a slight few files. fstab... ... resolv.conf technically.
<wasabi> hmm what do I usually do when debootstrapping.
<wasabi> I think that's actually about it.
<Fujitsu> hostname as well.
<wasabi> oh yeah, /etc/hostname
<Fujitsu> /etc/network/interfaces, if you're counting resolv.conf.
<wasabi> oh yes yes 
<wasabi> Anyways, every few years I run a little script that scans for files on my system taht AREN"T in a package, and I identify and delete them. ;)
<Hobbsee> wasabi: that'd help.  
<Fujitsu> And the special stuff in /var on the root partition which took me ages to work out. I wondered why lo wasn't coming up on boot :(
<wasabi> dpkg -S is your friend.
<wasabi> There's not much in /var except some directories themselves which need to be created.
<wasabi> Like var itself.
<wasabi> actually I guess lock and run are done by scripts now too, since they're tmpfs
<StevenK> wasabi: Ignore things like /home?
<wasabi> StevenK: yeah.
<Fujitsu> wasabi: /var/{lock,run} need to be on the root filesystem, not a mounted /var, or things explode on bootup.
<wasabi> Oh really?
<StevenK> But /var/{lock,run} are tmpfs'es
<Fujitsu> Otherwise network interfaces can't come up, and various other things.
<Fujitsu> StevenK: But the mountpoints need to exist.
<wasabi> I basically just grab every file on the system, filter out the obvious paths, /home, my few custom directories, some bits of var, then run them all through dpkg -S. Sort the output and figure out what I should nuke.
<wasabi> debfoster is nice too.
<StevenK> Fujitsu: That just involves directories existing in /var.
<Fujitsu> StevenK: I guess my statement was ambiguous. I meant the directories.
<wasabi> Anyways, unix is nice like that. There's no magic. Everything is a file. If you break something, you can just fix it.
<wasabi> s/unix/linux/
<wasabi> And in doing so, learn how it works.
<Hobbsee> bryce: er...i think you've broken this
<Hobbsee> sarah@LongPointyStick:~/Desktop$ sudo dpkg -i libgl1-mesa-swx11*.deb
<Hobbsee> dpkg: regarding libgl1-mesa-swx11-i686_7.0.0-0ubuntu1_i386.deb containing libgl1-mesa-swx11-i686, pre-dependency problem:
<Hobbsee>  libgl1-mesa-swx11-i686 pre-depends on libgl1-mesa-swx11
<Hobbsee>   libgl1-mesa-swx11 is not installed.
<Hobbsee> dpkg: error processing libgl1-mesa-swx11-i686_7.0.0-0ubuntu1_i386.deb (--install):
<Hobbsee>  pre-dependency problem - not installing libgl1-mesa-swx11-i686
<Hobbsee> Errors were encountered while processing:
<Hobbsee>  libgl1-mesa-swx11-i686_7.0.0-0ubuntu1_i386.deb
<kylem> probably me who broke it.
<StevenK> Hobbsee: Does libgl1-mesa-swx11_*deb exist?
* Hobbsee blames kylem 
<Hobbsee> oh, wait.  dammit.
<Hobbsee> thought i got them all.  missed one
<bryce> hrm
<Hobbsee> dpkg: regarding libgl1-mesa-swx11_7.0.0-0ubuntu1_i386.deb containing libgl1-mesa-swx11:
<Hobbsee>  libgl1-mesa-swx11 conflicts with libgl1
<kylem> oh. wait. i did mesa 6.5.3, not mesa 7.0.0
<kylem> nevermind me.
<Hobbsee> oh wait, that one is right
<bryce> I had to do apt-get -f install a few times to force everything in there (and there was one package I could never get installed)
<Hobbsee>  libgl1-mesa-swx11 conflicts with libgl1
<Hobbsee>   libgl1-mesa-glx provides libgl1 and is unpacked but not configured.
<ajmitch> sounds like a painful upgrade path
<bryce> I assume there's a correct installation order I just fumbled though
<ajmitch> can apt-get/aptitude sort out a sane upgrade if you create a repository for it?
<StevenK> bryce: I'm having second thoughts. :-)
<Hobbsee> bryce: it appears you have 2 packages providing libgl1
<Hobbsee> bryce: which means they conflict each other, and it all dies.
<StevenK> Maybe only one of them should be installed?
<bryce> yeah I assume you would install only one set or the other
<Hobbsee> bryce: then you should have conflicts of one set against the other, surely?
* Hobbsee seems to have had both lots installed, before this testing
<bryce> hrm, ok well back to the drawing board.  thanks for giving it a shot
<Hobbsee> bryce: which one do i want, btw?
<Hobbsee> intel 945
<Hobbsee> bryce: what you *should* do is upload it to a repo somewhere, so that apt can deal with the breakage, adn test it that way - then the predepends stuff is covered.
<StevenK> Or run dpkg-scanpackages on that directory.
<StevenK> bryce: If you want to do that, I can type out a comand line for it.
<bryce> ok
<StevenK> dpkg-scanpackages . /dev/null | tee Packages | gzip -9c > Packages.gz
<StevenK> Then the deb line is "deb http://people.ubuntu.com/~bryce/Testing/mesa_7.0.0 ./"
<bryce>  ** Packages in archive but missing from override file: **
<bryce>   libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-dri-dbg libgl1-mesa-glx
<bryce>   libgl1-mesa-glx-dbg libgl1-mesa-swx11 libgl1-mesa-swx11-dbg libgl1-
<bryce>   mesa-swx11-dev libgl1-mesa-swx11-i686 libglu1-mesa libglu1-mesa-dev
<bryce>   libosmesa6 libosmesa6-dev mesa-common-dev mesa-swx11-source mesa-
<bryce>   utils
<bryce> is that normal?
<StevenK> Yes.
<Hobbsee> bryce: could you tell me which lot i want, please?
<StevenK> Because /dev/null in that argument list is what dpkg-scanpackages wants for the override file. :-)
<Hobbsee> bryce: swx11 or glx?
<bryce> Hobbsee: I don't know.  I installed swc11 on my -nv box
<Hobbsee> you're supposed to know, arent you?
<Hobbsee> bryce: you're supposed to know everything X, dammit!  :P
<bryce> yeah... :-(
<bryce> StevenK, ok Packages.gz uploaded
* ajmitch wants a working nouveau driver
<StevenK> bryce: Way cool.
* kylem wants a pony.
<ajmitch> you can't have a pony!
* RAOF wants what ajmitch is having.
<StevenK> Hobbsee: Add that deb line to apt sources and wave apt-get install, say swx11 over it?
* StevenK installs ubuntu-desktop in a chroot.
<Hobbsee> oh wait.  i didnt have swx11 installed before.  
<mjg59> swx11 is the software rasteriser, IIRC
<StevenK> In that case, choose glx
<mjg59> You probably don't want it
<Hobbsee> bryce:  mesa-utils depends on libgl1-mesa-swx11-i686; however: - surely that needs a swx11 | glx?
<Hobbsee> mjg59: thanks.
<Hobbsee> @pony kylem 
* mjg59 goes back to bed
* Hobbsee hands mjg59 some coffee
* Hobbsee kicks ubotu 
<Hobbsee> hrm.  it appears i dont want to throw out libglu1-mesa
<StevenK> bryce: I'll try and see if apt will upgrade in a chroot.
<Hobbsee> nor mesa-utils
<Hobbsee> bryce: afaics, the libglu1-mesa and mesa-utils depending on swx11 only, and not either that or glx, and the lack of conflict between libgl1-mesa-swx11 and libgl1-mesa-glx seem the only problems.  the rest looks fine.
<Hobbsee> of course, whether it'll work with the other dependancy, i have no idea :)
<bryce> ok
<Hobbsee> morning dholbach!
<dholbach> good morning
<dholbach> hiya Hobbsee
<bryce> nite all, thanks for the help, sorry it didn't work out.
<Hobbsee> bryce: oh drat.  if you're going to bed, then my system will probably stay in limbo :P
<dholbach> night bryce - whatever it was - good luck getting it fixed tomorrow!
<Hobbsee> dholbach: X fun
<bryce> Hobbsee: oh, thought you said it finally worked?  I must be getting tired
<Hobbsee> bryce: no, i still cant install mesa-utils nor libglu1-mesa
<Hobbsee> bryce: due to the swx11 dependancy, not a swx11 
<Hobbsee> bryce: due to the swx11 dependancy, not a glx | swx11 dependancy
<Hobbsee> nor can i remove them, as various other stuff depends on them - like, kdesktop
<bryce> have you tried doing apt-get -f install ?
<Hobbsee> bryce: of course.
<Hobbsee> bryce: it wont work unless i remove all the -glx stuff, and add all the swx11 stuff, which mjg59 suggested that i didtn really want to do
<persia> Hobbsee: Try force installing the previous versions.
<bryce> hrm, this is sounding beyond my dpkg-fu
<Hobbsee> bryce: i can probably fix it from here, actually - but have no place to upload it, etc.
<Hobbsee> as in, fix the dpkg foo, then you can build it.
<Hobbsee> or tell you how to
<Hobbsee> persia: i'm trying to avoid doing that - but i will, if i have to shut down this machine before bryce fixes the problem
* Hobbsee grabs source, and such
<TheMuso> dholbach: Heya. Thanks for the gnome-mag upload.
<Hobbsee> StevenK: do i need only a conflicts, or a conflicts/replaces?
<StevenK> Hobbsee: More information, sorry?
<Hobbsee> StevenK: on the -swx11 / -glx
<Hobbsee> StevenK: as in, they're not coinstallable - but the user should be able to choose between whichever they want
<dholbach> TheMuso: anytime :)
<crimsun> they should be Conflicts.
<crimsun> neither C & R the other
<ccm> just wondering if i drop a mail for the guys of http://linuxmint.com/ suggesting them to use launchpad and freenode
<crimsun> ccm: a friendly suggestion?  Wouldn't hurt, I think.
<ccm> yes friendly of course
<ccm> no flame :)=
<ccm> "hey, bastards, you should %&$! use launchpad"!
<ccm> :)
<Hobbsee> zomg wtf is going on here?
<Hobbsee> i *knew* i didnt want to touch X.
<StevenK> Heh
<Hobbsee> wait, no, it's not that crackful - it's just me reading it wrong
* Hobbsee thought package A was conflicting, replacing AND depending on package B.
<Hobbsee> hi sabdfl 
<StevenK> Hobbsee: Cute.
<Hobbsee> hehe
<sabdfl> hey Hobbsee
<Hobbsee> it's not, thank goodness.
* Hobbsee wonders where mesa-utils gets it's shlib depends from.
<StevenK> mesa-utils's Depends is only ${shlibs:Depends} ?
<Hobbsee> yep
<Hobbsee> which picks up libgl1, which seems to only be found from -swx11
<StevenK> Then it's getting libgl1-mesa-swx11-i686 because it links against it.
<Hobbsee> StevenK: where does it link against it, sorry?
<StevenK> One of the binaries in mesa-utils links against a shared library in libgl1-mesa-swx11-i686.
<StevenK> Which is probably libGL directly, just thinking about it.
<StevenK> Which means the shlibs.local is wrong.
<Hobbsee> riiight.
<StevenK> Interesting. libgl1-mesa-swx11-i686 doesn't provide shlibs.
<Hobbsee> libgl1-mesa-swx11.shlibs does, though
<StevenK> Yes, but it's .shlibs looks correct.
<Hobbsee> (why cant the second half of the bug be as easy to fix as the first?)
<StevenK> dpkg-shlibdeps is using libgl1-mesa-swx11-i686 for some reason, we just need to figure out what.
<Hobbsee> when you find out, do tell how :)
* StevenK grins.
* StevenK is still digging.
<Hobbsee> StevenK: current source, with the first half fixed, is in /home/sarah/mesa/mesa-7.0.0/debian
<Hobbsee> on liquified
<StevenK> If you dpkg-source -b that directory, I can grab it and sbuild it.
<StevenK> In ~sarah/mesa, dpkg-source -b mesa-7.0.0
<Hobbsee> StevenK: source, presumably?
<StevenK> Sorry?
<Hobbsee> StevenK: ie, you want the source package built, so you can throw it at sbuild?
<StevenK> Hobbsee: Actually, I don't, since I want to keep the build environment.
<StevenK> Hobbsee: It's building now.
* Hobbsee hasnt used dpkg-source -b - read it as dpkg-buildpackage -b
<Hobbsee> cool
<StevenK> dpkg-source -b is the first thing pdebuild does.
<Hobbsee> so it seems
<calc> ScottK: sistpoty sent me a link to interesting irc log :)
<dholbach> can somebody please give back gtkmm2.4?
<dholbach> infinity2: ^
<dholbach> Mithrandir: already awake?
<dholbach> if so, it'd be nice if you'd use your super powahs to give back gtkmm2.4 :)
<Hobbsee> bryce: your build was on crack.
<Mithrandir> dholbach: hiya
* dholbach hugs Mithrandir
<dholbach> hey amitk
<dholbach> how's it going?
<Hobbsee> morning Mithrandir, dholbach 
* Hobbsee ponders whether to get this X stuff uploaded
<dholbach> Hobbsee: I've been here for a while already :-)
* dholbach hugs Hobbsee
<Hobbsee> dholbach: i realise that :)
* Hobbsee hugs dholbach 
<dholbach> hehe
<TheMuso> dholbach: Heya. Thanks for the gnome-mag upload.
<dholbach> TheMuso: anytime :-)
<dholbach> I see... you all want to make me crazy with dj-vu experiences :)
<amitk> morning dholbach
<Amaranth> morning dholbach ;)
<Hobbsee> dholbach: hrm?
* Hobbsee --> restarting X
<ajmitch> Hobbsee: you haven't broken it all then?
<Hobbsee> right.  X doesnt break.
<Hobbsee> ajmitch: correct.
<Hobbsee> ajmitch: i added the conflicts, and the other problem seemed to be due to a frankenstinean build.
<Amaranth> Lack of pbuilder
<Hobbsee> dunno
* Hobbsee ponders whether to upload it
<ajmitch> right before tribe-2 freeze?
<desrt> my X breaks :(
<Hobbsee> ajmitch: that's why i'm pondering, rather than doign.  bryce says it's a new upstream, mostly bug fixes.  he hasnt had people test it, apart from him and me testing it here
<Hobbsee> although his still had broken bits, so i dont know how his got tested
<crimsun> I'd side with his original CFT.
<crimsun> post-Tribe 2 upload)
<Hobbsee> crimsun: CFT?
<StevenK> Call For testers
<Hobbsee> right
* ajmitch is just a user, not a release person, so can't give much input
<Hobbsee> as in, here is the repo, please test it
<StevenK> Hobbsee: Right.
<Hobbsee> ajmitch: i'm one of the release people, it appears.  i just dont touch X normally :P
<Hobbsee> but i'd be happy for it to wait until post-tribe 2
<ajmitch> exactly, you get to decide
* tfheen sighs at file systems dying.
<Hobbsee> tfheen: it wasnt reiser, was it?
<dholbach> tfheen: urg :/
<tfheen> Hobbsee: no, ext3.
<Hobbsee> bah.
<tfheen> it's a largish one, though
<StevenK> How large?
<tfheen> 2.5TB
<StevenK> Ah ha
<StevenK> My largest is only (... only) 740Gb
<TheMuso> tfheen: Please tell me that that was in a RAID setup.
<tfheen> TheMuso: yes, it is.
<TheMuso> phew
<StevenK> On top of how many disks? 8?
<tfheen> none of the devices have failed, though
<tfheen> yeah, 8 + hotspare
<infinity2> dholbach: Done.
<dholbach> infinity: thanks a lot - once it has built, a lot of other *mm stuff will build again
* dholbach hugs infinity
<pitti> Good morning
<Hobbsee> morning pitti!
* Hobbsee hugs pitti 
* pitti hugs Hobbsee 
<Hobbsee> :)
<StevenK> pitti: Morning!
<pitti> hi StevenK 
<dholbach> somebody please give back gconfmm2.6 and gnome-vfsmm2.6 too 
<pitti> dholbach: done
<fabbione> pitti:  i saw you got the installer in... good good
<pitti> fabbione: erm, I didn't?
<fabbione> pitti: i also explained to evand how to make it
<fabbione> pitti: well he did it for you :)
<pitti> cool
<pitti> except that it FTBFSed everywhere
<fabbione> pitti: but it's worth checking with cjwatson_ again before publishing images. i dunno if he had changes in the queue. i could only do the ABI bump
<fabbione> uh?
<fabbione> let me check
<fabbione> oh iu think we need ubuntu-modules
<fabbione> E: Couldn't find package ubuntu-modules-2.6.22-7-generic-di
<fabbione> yes
<fabbione> that's it
<fabbione> pitti: just give it back once ubuntu-modules are built
<fabbione> i forgot about this change when mentioning upload timing to evand
<pitti> still building, yes, I just bumped their priority
<pitti> fabbione: yep, good
<fabbione> my bad sorry
<pitti> fabbione: NP, I rather have the source published already :)
<fabbione> ehhe
<pitti> fabbione: did you change the seeds for this already, too?
<fabbione> no
<fabbione> it was late in the evening
<pitti> fabbione: ok, I'll do it, I need to touch them now anyway
<fabbione> ok
<pitti> so, I need to figure out now how to do an ABI bump of linux-backports-modules
<fabbione> do we need that?
<fabbione> AFAIK it's just a var in debian/rules
<pitti> fabbione: well, not really, I just don't like stuff in Maintainer: Ubuntu Core Developers <ubuntu-devel@lists.ubuntu.com>
<pitti> erk
<pitti> http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
<pitti> sorry
<fabbione> ehhe
<fabbione> pitti: do you want me to look at it?
<pitti> fabbione: if you want to, sure
<fabbione> no i don't but i would it for you :)
* pitti hugs fabbione 
<fabbione> pitti: linux-backports-modules-geric comes from linux-meta
<fabbione> well all of them
<pitti> fabbione: right, linux-backports-modules-2.6.22 doesn't even exist yet
<fabbione> so i guess as soon as you new linux-meta it will work
<pitti> fabbione: no, meta just depends on the -2.6.22-7 packages
<pitti> linux-backports-modules-2.6.20 | 2.6.20-15.10 |        feisty | source
<pitti> that's the corresponding source for gutsy
<fabbione> oh ok
<fabbione> hmm
<pitti> fabbione: but, we can leave that to the kernel team, too, it's just a nice-to-have
<fabbione> ok we don't need it for tribe-2 anyway
<pitti> ogra: do you actually want compiz in the desktop seed for edubuntu?
<LaserJock> heh, he got compiz working on a Intel ClassmatePC running as a thinclient at Sevilla
<LaserJock> that was kinda nifty
<pitti> ogra: I merged that change from the seeds now; if you don't want it, can you please throw it out?
<pitti> fabbione: all seeds changed for new d-i kernel
<pitti> hey mvo
<mvo> hey pitti
* ..[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-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main frozen for tribe-2
<StevenK> Yay!
<LaserJock> hmm, already
<LaserJock> I guess it is already almost 1:00am tuesday here
<pitti> LaserJock: almost 10:00 am here, and I'd rather have an overview about what goes in now
<fabbione> pitti: coolness
<stgraber> morning
<dholbach> somebody also give back  libgdamm3.0  - it should build now
<tfheen> backgegebt.
<dholbach> hehehe :)
<dholbach> backgegeben would be wrong too, but maybe a bit more right ;-)
* dholbach hugs tfheen
<ogra> pitti, as long as you dont drop metacity all is fine ... i have no composite support at all in ltsp atm, dunno why but i suspect its an X issue
<ogra> so having compiz wont do any harm i tested that
<Keybuk> ogra: we need metacity for those without 3D cards, it won't be dropped
<seb128_> Keybuk: can we not use the animations for compiz? ;)
<ogra> Keybuk, yes, i was expecting that :)
<seb128_> those are really crack
<Keybuk> seb128: why not?  the subtle ones look really nice
<seb128> the current ones are not subtle
<seb128> the zoom thing when opening or closing a window is really intrusive
<Keybuk> zoom thing?
<ogra> if you minimize/maximize
<seb128> it does fade in and out with the window shrinking or expending
<Keybuk> we can fiddle with animations later
<Keybuk> Mark will almost certainly want to be highly involved in that process
<seb128> we can't use the GNOME menu atm because the "zoom out and show workspaces" kick in as soon as you go in the corner
<Keybuk> that's a bug then, we shouldn't have any active corners enabled by default
<Keybuk> prefs are easy to tweak - just ask mvo
<seb128> mvo: ^ we can disable that then ;)
<mvo> sure
<seb128> Keybuk: yeah, but he said to have you to validate the change first to know disable things which should be enabled
<seb128> that's why I'm asking what we can disable ;)
<Keybuk> things like that, we can disable
<Keybuk> animations we should leave on for now
<seb128> good
<seb128> can we disable the bouncing when maximising a window?
<seb128> it's not smooth at all on my box and looks ugly
<Keybuk> leave things like that for now, and we'll worry about them later
<seb128> ok
<Keybuk> what animation setting causes the bounce?  have you fiddled in ccsm to get something more to your liking?
* Keybuk doesn't seem to have a maximise bounce
<StevenK> I thought that caused by wobbly windows?
<Keybuk> so it is
<Keybuk> mvo: wobbly should be disabled by default, no?
<mvo> Keybuk: yes, that is disabled by default
<Keybuk> it's on for seb because he's played in the past?
<seb128> I've no wobble
<Keybuk> btw, what does the "enable extra animations" checkbox do?
<seb128> and I've no ccsm installed
<seb128> hum, let me try with a new user
<Fujitsu> Keybuk: It enables wobbliness at least, AFAIK.
<jtmoulia> ls
<ogra> "[: 99: ==: unexpected operator"
<mvo> seb128: on the livecd I have no wobble on maximize
<ogra> is anyone else seeing that in his .xsession-errors ?
<mvo> ogra: me
<ogra> hmm
<ogra> the Xsession.d scripts look ok
<mvo> ogra: I suspect gnome-volume-manager (but that is just a theory)
<seb128> mvo: do we have an uptodate desktopCD to try?
<mvo> maybe the name compiz wrapper
<mvo> seb128: yes, currently daily
<mvo> seb128: interesstingly the worksspace seems to work very nicely on it too
<seb128> mvo: well, there is no user setting to respect
<mvo> still, 4 workspaces, nicely displayed in the panel applet. I like that 
<seb128> ;)
<seb128> nicely?
<seb128> there is separators displayed between them?
<mvo> no seperator
<Keybuk> s/workspaces/viewports/ no?
<mvo> indeed
* mvo needs to remember the correct terminology 
<seb128> I'm downloading the CD
<seb128> I'll try if totem works with it
<seb128> it doesn't on my desktop
<seb128> the video are is not refreshed
<seb128> area
<pitti> ogra: that depends on what mvo did with the auto-enabling of compiz, I figure :) but since it checks whether X supports it, it should be fine
<ogra> yeah
<pitti> mvo: how does compiz things look like?
<ogra> it didnt do any harm on an up to date system here
<pitti> asac: how bad does n-m look? can we at least get the debian_backend patch?
<Keybuk> N-M is convinced I'm on a wired network
<Keybuk> which is nice, since there's no network cable plugged in
<mvo> pitti: not bad currently, I tested in on a nvidia machine just now and it correctly loads metacity with "nv" and can be enabled with the apperance-capplet and restricted-manager (still some UI glitches, but nothing really serious). next is ati r300 and ati r500 on the list to test
<pitti> N-M regularly tears down all my interfaces on boot
<Amaranth> it also doesn't work with wpa
<tfheen> NM makes it just about impossible for me to log in, since I don't have networking when I boot the machine..
<tfheen> this doesn't go too well with Kerberos
<pitti> Riddell: does adept work now with the reverted debtags/libept? if so, can we move bug 121456 to tribe3?
<ubotu> Launchpad bug 121456 in adept "Adept couldn't open debtags database" [Critical,Confirmed]  https://launchpad.net/bugs/121456
<Keybuk> tfheen: NM doesn't handle your use case; let's just focus on the regressions from feisty please
<tfheen> Keybuk: uh, it worked fine in feisty.
<Keybuk> ok, that's interesting then :)
<tfheen> if it hadn't, I wouldn't have had NM installed.
<StevenK> libept | 0.5.7ubuntu1really0.4.7ubuntu2 ... whoa!
<tfheen> it seems like the default policy doesn't hit, and it doesn't enable eth1
<Rumba> mvo: i found a bug: i uninstalled some packages in synaptic but they are still shown as "Auto-Installed: 1" in /var/lib/extended_states! (not sure if "Auto-Installed: 0" packages are still shown, but i don't see why not, so i won't test that.)
<StevenK> What was so offensive about libept 0.5.7?
<Rumba> mvo: are you familiar to this issue?
<pitti> StevenK: doesn't work with the current debtags, it needs porting
<StevenK> Ahhh
<pitti> StevenK: well, debtags needs to be ported to new libept, that is
* StevenK nods.
<pitti> fabbione: bug 119057 wasn't mentioned in the -7 changelog; was that fixed upstream?
<ubotu> Launchpad bug 119057 in linux-source-2.6.22 "[SPARC]  not all PCI resources are initialized" [Critical,Fix committed]  https://launchpad.net/bugs/119057
<fabbione> pitti: yes it's fixed in -7
<asac> pitti: i managed to reapply almost all patches .... no idea how to test all those features, but from how the patches apply now it looks good
<pitti> asac: can you put the source somewhere? I'm happy to give it some testing, maybe tfheen as well
<asac> pitti: bzr
<Fujitsu> Amaranth: I'm using WPA fine, and I upgraded about 20 minutes ago. nm-applet does segfault if I let it use the keyring, though.
<asac> pitti: wait a second
<mvo> Rumba: that is known and harmless because when they are installed next the state will be corrected (if that is needed). it clutters the file though and I plan to fix it for gutsy
<pitti> asac: ah, orig.tar.gz plus bzr? or do you maintian the entire code in bzr now?
<fabbione> pitti:    * [SPARC64] : Handle PCI bridges without 'ranges' property.
<asac> https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x
<fabbione> pitti: (from the changelog)
<asac> pitti: its all in
<Amaranth> Fujitsu: well, i guess it might have something to do with the fact that my laptop is broken but it works with wpa_supplicant
<asac> pitti: if you wnt orig i can push it somewhere
<pitti> asac: ah, cool
<pitti> asac: nevermind, bzr is fine
<asac> pitti: applet is coming in a minute
<asac> will push it there as well
<seb128> pitti: can we enable apport by default now?
<pitti> asac: but when building the source package, you'll still use the upstream orig.tar.gz?
<pitti> seb128: we could, we just don't yet have the privacy thing
<Rumba> mvo: can/will you fix it upstream?
<pitti> seb128: I didn't manage to finish that yesterday
<mvo> Rumba: yes, that is my plan
<pitti> seb128: hm, if we want that, let me upload a new one with some bug fixes
<seb128> pitti: having crach stacktrace now would be nice, upstream freeze is coming
<pitti> seb128: right, ok; let's flip the privacy thing on post-tribe then
<asac> pitti: yes ... i use tarballs/ directory
<Rumba> mvo: oh, and do you plan to add a "_manually_ installed" checkbox in synaptic's custom filters?
<seb128> thanks
* seb128 hugs pitti
<mvo> Rumba: not at this time, but I would be happy about a patch :)
<pitti> mvo: do you plan to upload update-notifier? if not, I would like to flip apport on and upload
<Rumba> :)
<mvo> pitti: go ahead
<asac> pitti: ok for applet tarball: http://people.ubuntu.com/~asac/network-manager-applet_0.6.5.orig.tar.gz
<asac> pitti: debian only bzr here: https://code.launchpad.net/~ubuntu-core-dev/network-manager/gnome.ubuntu.0.6.x
<Rumba> mvo: so let me get this clear: you are a dev of synaptic or aptitude?
<pitti> tfheen: ^ can you give this some testing as well?
<pitti> asac: it works for you so far?
<Rumba> mvo: i mean, is it synaptic or is it aptitude that you are a dev of?
<mvo> Rumba: I maintain apt and synaptic. aptitude is done by daniel burrows
<asac> pitti: can't really tell because my vm license has expired and my other system is currently installing.
<asac> ... gutsy
<tfheen> asac: my problems does not have anything to do with the applet, they're in the core code.
<tfheen> (since the applet hasn't started at gdm time)
<asac> tfheen: i redid the merge for core code
<tfheen> asac: where is it, then?
<asac> read 20 lines above :)
<pitti> tfheen: <asac> https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x
<asac> wait a second
<Keybuk> tfheen: tbh, I'm not sure why NM ever brought the network interface up before login
<Keybuk> tfheen it was never supposed to, or deliberately patched to do that
<Keybuk> tfheen: you may have been relying on a bug
<tfheen> Keybuk: it didn't, but it failed to kill dhclient.
<stgraber> Who is the secretary for this afternoon CC ? It used to be Seveas but I understood it's taken a month off
<stgraber> s/it's/he's/
<pitti> asac: why does the -core package build-depend on libpanel-applet2-dev? I thought the core should be gtk free?
<asac> tfheen: Keybuk tonio dropped debian_backend and lots of other patches during 0.6.5 merge ... so current version should be more or less completely broken 
<asac> pitti: probably left over ... can fix it.
<Keybuk> asac: yes, I saw that
<asac> pitti: i concentrated to reapply all patches for now
* pitti hugs asac
<pitti> asac: are you ready for enabling apport on tribe-2, too?
<asac> i am fine with it ... at best we can figure a way out how my precious helper hjmf can still process crash reports :)
<asac> actually i want crash reports yesterday
<mvo> hm, it looks like libgl1-mesa-dri is missing from the livecd
<pitti> mvo: we deliberately kicked it
<pitti> mvo: it's 14 MB and we didn't have it before
<pitti> well, from alternate at least
<mvo> its kind of essential to get compiz working
<Amaranth> yeah....
<Amaranth> or 3d of any kind
<ogra> ah, thats why i didnt get compiz going on ltsp ... indeed :)
<pitti> mvo: hm, then something should have a dependency on it, and we need to kick off 14 MB of stuff from the CDs
* mvo waves to Amaranth
<ogra> libgl1-mesa-glx has a replaces though
<ogra> Replaces: libgl1, libgl1-mesa-dri (<< 6.4.0)
<ogra> Conflicts: libgl1, libgl1-mesa-dri (<< 6.4.0)
<pitti> asac: did you change anything in the API of network-manager? the applet currently b-deps on network-manager-dev (>= 0.6.5), i. e. will also build against the current n-m in the archive
<pitti> asac: if there is no API change, that's fine, then we can get it published faster, but it should be double-checked
<asac> pitti: i started with tonios debinization
<Amaranth> pitti: the problem is compiz can work with libgl1-mesa-dri, nvidia-glx, or any sort of driver that does 3d + xgl
<Amaranth> i suppose compiz could do an OR depend on those three
<ogra> what about libgl1-mesa-glx ?
<Amaranth>  This package does not include the modules themselves: these can be found
<Amaranth>  in the libgl1-mesa-dri package.
<asac> pitti: so ... i have to verify ... but i hope that we don't change api in nm at all ... do we?
<pitti> Amaranth, mvo: ok, then we need to put it into desktop-recommends
<pitti> asac: I don't know
<pitti> anyway, let me reboot for testing new kernel and n-m
<Amaranth> ogra: and libgl1-mesa-dri is 6.5.3
<Amaranth> that's an old replaces
<ogra> ah, right
<ogra> and -dri depends on -glx
<ogra> ok
<Amaranth> right, they were split
<ogra> where do we get 14M ???
<Amaranth> :/
<Amaranth> kick tomboy and fspot out? ;)
<seb128> Amaranth: edubuntu already does no?
<ogra> yes
<ogra> edubuntu isnt the problem :)
<Amaranth> oh, this is for edubuntu?
<ogra> i can easily drop a language
<Amaranth> i thought we were talking about ubuntu desktop
<ogra> the prob is ubuntu atm
<ogra> and the livefses
<seb128> Amaranth: no way to drop those from the ubuntu desktop
<Amaranth> what was added to suddenly make this not fit?
<Keybuk> Amaranth: we've been at 100% for a few releases now
<Amaranth> right but this was on the CD before
<dholbach> i386 gtkmm2.4 build faster!
<Keybuk> so every time we add something, something else needs to be taken awy
<Keybuk> openoffice probably swelled another few megabytes, etc.
<Amaranth> ah yes, the beast
<Amaranth> I don't even know what goes on the CD so I wouldn't know what to remove
<seb128> dholbach: faster than what?
<Amaranth> obvious choice would be a language pack but i think you already dropped all those
<Keybuk> there's still half a dozen language packs
<dholbach> seb128: just faster, so I can ask for give-backs of all the other *mm stuff, so everything's good again :-)
<asac> pitti: back?
<pitti> asac: yes
<seb128> Amaranth: some depends have been added I think, like gnome-system-monitor uses gtkmm now
<pitti> asac: well, it sucks a tad less
<pitti> asac: it didn't touch eth1 any more (my static interface)
<Amaranth> ah, right, GNOME decided C++ bindings could be used in desktop modules
<asac> pitti: hmm
<seb128> dholbach: faster is compared to something, you are faster than ... before, something else, etc ;)
<pitti> asac: but it still tears down eth0 (standard auto/dchp) and doesn't connect to it at start
<Amaranth> and C++ is bloated
<Keybuk> at some point, we are just going to have to bite the bullet, and accept that we don't fit on a single CD anymore
<pitti> asac: when I log in, it just says 'manual configuration', so I have to sudo ifdown/ifup; I cannot even click
<Amaranth> Keybuk: hopefully that can be a year from now
<Keybuk> Amaranth: why a year?  I've been arguing for DVD-as-default-image for a year already :p
<dholbach> we had gtkmm on there before
<seb128> let's switch to 7z ;)
<Amaranth> 7z would help a lot too
<seb128> dholbach: on the CD?
<Amaranth> it'd give us that year :)
<pitti> Keybuk: there's still quite a bit of air (lzma for alternates, better squashfs for desktop), I think
<seb128> dholbach: why?
<Amaranth> Keybuk: well, computers made in 2003 didn't all have DVD drives
<asac> pitti: does this behaviour remind you of something (e.g. was that tackled once with a patch?) 
<Amaranth> Keybuk: it'd be nice if a 4 year old computer could use our stuff
<pitti> Amaranth: one of Ubuntu's key goals is good i18n support; we cannot just drop *all* langpacks to fit new crack, we have to get rid of old crack, too
<dholbach> seb128: hm, maybe not - I thought of inkscape and workrave - they're both in supported though
<pitti> asac: not really, I'm not intimately familiar with the patches
<dholbach> pitti: did you drop gnomedb and gda2 already?
<Amaranth> don't we still have gphoto along side f-spot?
<pitti> asac: and I never saw that one
<seb128> dholbach: ah, gparted
<dholbach> ah right, gparted too
<dholbach> :-)
<Amaranth> gthumb, rather
<pitti> asac: it has always torn down my eth0 from /etc/init.d/networking, but at least it brought it up again on login
<seb128> Amaranth: yes, not the same usecase
<pitti> Amaranth: yes, we have; eog, gthumb, f-spot
<seb128> Amaranth: f-spot works fine when you want to handle your photos based on exif tag
<Amaranth> eog makes sense, it's one of those 'spatial' things
<seb128> but some people classify by hand and want gthumb to browse the directories
<asac> pitti: do you have logs?
<pitti> asac: TBH, at this point I'm even inclined to roll back to the feisty versions
<Amaranth> i mean, it's just "here is your photo" and not "here is my app with your photo in it"
<seb128> eog is a simple viewer
<ogra> Amaranth, edubuntu has gthumb we never had space for mono
<bhale> f-spot --view does directories now, no?
<seb128> ogra: you have 2 CDs now though, no? ;)
<seb128> bhale: it's not good enough atm
<seb128> bhale: the idea is there but it still sucks
<Treenaks> seb128: eog has a nice multi-picture mode too now
<asac> pitti: ... can we do that?
<ogra> seb128, yeah, all mono stuff is on the second one since feisty :)
<Amaranth> f-spot --view seems to be an eog replacement
<asac> pitti: e.g. without going for epoch and other hacks :)
<pitti> asac: 0.6.5+really0.6.4foo :)
<ogra> seb128, and i still only have one livecd
<asac> pitti: oh :)
<Amaranth> yeah, eog is getting pretty powerful
<Amaranth> i'd say it's a nice replacement for gthumb
<seb128> asac, pitti: are you downgrading to nm 0.6.4?!
<pitti> asac: logs> very helpful :/
<bhale> seb128: it seems pretty nice to me, but i was never an eog user. sorry
<pitti> Jun 26 11:26:01 localhost NetworkManager: <info>  Now managing wired Ethernet (802.3) device 'eth0'. 
<pitti> Jun 26 11:26:01 localhost NetworkManager: <info>  Deactivating device eth0. 
<Amaranth> err, feisty didn't have the separate tarball for the applet
<pitti> Amaranth: so what? the binary name is the same
<Amaranth> anyway, on the photo thing, we have 3 applications that overlap all over each other
<Amaranth> one of them can go away
<bhale> gthumb should go first imo
<Amaranth> which one, i particularly care but gthumb is the one getting squeezed in the middle
<asac> pitti: lets see if i somehow get this virtualbox thing going
<Amaranth> err, don't particularly care
<bhale> gthumb looks a lot like nautilus with some extra buttons/menus
<Amaranth> yeah, even nautilus is squeezing out gthumb
<seb128> bhale: it seems to work better than previous time I tried it
<pitti> Amaranth: photo import is the only important thing of gthumb
<Amaranth> it's just begging to be killed off
<ogra> bhale, make mono small enough to fit on the edubuntu livecd, then i can drop gthumb :)
<bhale> seb128: i like the sidebar with previews
<bhale> ogra: heh, oh.
<Amaranth> pitti: we have nothing else that can do photo import?
<seb128> bhale: eog has that too ;)
<seb128> I thing we should drop gthumb
<Keybuk> pitti: isn't f-spot the default photo import tool anyway?
<Amaranth> no
<seb128> Keybuk: no
<pitti> Amaranth: f-spot's still sucked hard the last time I tried it
<Amaranth> gthumb offers to import my photos
<pitti> Keybuk: not yet
<Amaranth> then i close it and point f-spot at the mounted sd card
<Keybuk> odd, it is for me; and I don't remember changing that
<dholbach> does f-spot have something to get rid of 24697246 of duplicates in the mean time?
<Amaranth> eh?
<bhale> no, its on the roadmap
<bhale> Amaranth: he doesnt empty his camera, keeps importing over and over
<dholbach> or I import from ~/my_pictures
<Amaranth> bhale: wouldn't the camera get full? :)
<dholbach> because I had them copied on another machine already
<Amaranth> btw, not even iPhoto handles that case well
<Treenaks> I never understood this 'import into database' thing.. just like rhythmbox..
<dholbach> that's why I like gthumb, it doesn't get in my way
<dholbach> I can just take a look at my sorted pictures
<Treenaks> Something always happens, it gets out of sync.. the database breaks..
* ogra likes and uses f7spot
<Ng> f-spot is so much better than gthumb, but you have to work with its way of doing things
<ogra> err
<ogra> f-spot
<Ng> in that gthumb is really simple and stupid and f-spot is a photo manager :)
<dholbach> oh, f-spot just crashed, hrm ... well
<Amaranth> i thought we were supposed to pick the 'best' app as a default instead of offering them all :)
<Fujitsu> F-Spot's default configuration of storing metadata in its own DB is just deranged, however.
<Keybuk> Amaranth: it gets difficult to pick the best when developers prefer different ones
<Ng> Fujitsu: it stores metadata in EXIF tags afaics, all of my comments from it are in the photos themselves
<Fujitsu> Ng: It has an option to, but that wasn't the default when I last tried.
<Amaranth> Keybuk: Needs a vote or something :)
<seb128> dholbach: what do you have with gthumb than eog doesn't have (out of photos import that can be done with f-spot even if you don't use it)?
<ogra> Amaranth, apart from what Keybuk said, its a technical issue, mono doesnt fint on the edubuntu liveCd 
<Ng> Fujitsu: *shrug* WFM since edgy
<Amaranth> ogra: right, but i'm talking about ubuntu :)
<Keybuk> Amaranth: technical board is the body to resolve disputes
<ogra> Amaranth, so we have to resort to either no photo app or gthumb there
<pitti> asac: so, if this works on a default install with just one eth, we should just take your version, but if it doesn't even auto-connect there, we should revert
<ccm> *giggle* I thought hug day is today and wondered why nobody is hugging around
* Fujitsu hugs ccm
* ccm hugs you
<ccm> thank you Fujitsu ;)
<seb128> ccm: hug day is tomorrow :)
<ccm> seb128: i should check my calender more often
<dholbach> seb128: just small features I know my sister uses - like photo web album, small effects like red-eye-removal and color adjustment
<ogra> ccm, feel free to hug in advance though :)
<seb128> dholbach: k, you really want to use f-spot then :p
<pitti> asac: it might really just be the two dhclients fighting each other; hell, we should really fix bug 90267
<ubotu> Launchpad bug 90267 in network-manager "network-manager stops and restarts already ifup'ed interfaces" [Critical,Confirmed]  https://launchpad.net/bugs/90267
<dholbach> I don't - I don't like the 'management' thing about it - it doesn't work for me - if you remove it from main, I'm happy to use eog
<seb128> dholbach: you know about f-spot --view, right?
* ccm comes from the future and drops a hug bomb
* Amaranth fires back with a Hug of Doom(tm)
<dholbach> seb128: does the 'folder' thing on the left hand side work for you?
<ogra> pitti, so any idea where we get the 14M from now ?
<seb128> dholbach: no
<dholbach> for me neither
<seb128> but opening a folder with it from nautilus should work fine ;)
<pitti> ogra: for getting -dri in? no, not really
<asac> pitti: so you are struck by bug 90267 ... but you haven't been before?
<ubotu> Launchpad bug 90267 in network-manager "network-manager stops and restarts already ifup'ed interfaces" [Critical,Confirmed]  https://launchpad.net/bugs/90267
<dholbach> I'll keep trying to use it every now and then
<pitti> asac: I have always seen that
<seb128> cool
<dholbach> but until now I don't feel it makes my life a better place
<seb128> dholbach: if there is bugs we should try to fix them rather than relying on an another software as a workaround
<pitti> asac: however, so far n-m daemon tore down eth0, and then nm-applet brought it up again
<ogra> pitti, i think i still have some langs to drop from the server CD but no idea what to do about live
<carlos> pitti: I guess gutsy language pack was correct, wasn't it?
<Amaranth> without -dri you might as well remove compiz, it's just taking up space doing nothing
<pitti> asac: but now nm-applet starts with a 'only manual configuration' state and doesn't bring up anything
<asac> pitti: ah ok ... so applet might be the problem for you
<dholbach> seb128: for me gthumb is not a workaround, it's the software I use
<pitti> carlos: worked fine so far; seb128, how do the current langpacks look for you?
<pitti> asac: it's in the daemon, I think
<asac> pitti: did you use the new applet?
<dholbach> and my sister won't type in 'f-spot --view'
<pitti> asac: the applet itself is really harmless
<Keybuk> dholbach: removing it from the CD doesn't prevent you from continuing to use it
<pitti> asac: yes, of course; bzr head
<dholbach> Keybuk: sure not
<ogra> dholbach, you could use the edubuntu addon cd as well its on there ;)
<mvo> pitti: I will change the seed to recommend libgl1-mesa-dri in ubuntu-desktop and make compiz a recommend  as well (currently its a depend). ok with you?
<pitti> mvo: no, it's not
<carlos> ok
<pitti> mvo: you have to drop 14 MB of stuff in exchange
<pitti> mvo: well, 6 MB on i386 and 10 MB on amd64
<dholbach> infinity gave back gtkmm2.4 3 hours ago - shouldn't if have built on i386 already?
<pitti> dholbach: let me look
<dholbach> s/if/it
<mvo> pitti: that is installed size? or package size?
<pitti> mvo: package size
<pitti> mvo: (roughly)
<pitti> dholbach: I bumped the build score
<dholbach> thanks a lot pitti
<pitti> dholbach: the i386 buildds are *still* busy with langpacks (gosh, I uploaded them 11 hours ago)
<seb128> dholbach: it's not about f-spot making your life better, it's about not having too much duplication when the CD needs space
<dholbach> seb128: I'm not going to stop you 
<seb128> pitti: there is new gutsy languagepack availables? I didn't update yet this morning
<ajmitch> seb128: so which one sucks less?
<ogra> pitti, we should restrict the translation teams to not translate so much :P
<seb128> ajmitch: I think we should have eog and f-spot on the CD
<pitti> seb128: yes, in the archive
<seb128> ajmitch: eog as a simple viewer and an image browser and f-spot has a photo manager
<seb128> pitti: I've to go out to buy some food now, I'll test in 20 minutes if that's ok with you
<pitti> seb128: sure
<seb128> k, bbl then ;)
<pitti> dholbach: building now
<Amaranth> well, gthumb gives us about 1M
* dholbach hugs pitti
<ogra> 1
<siretart> 2
<axxo> 3
<ogra> heh
<pygi> fabbione, poke?
<fabbione> yeah?
<pygi> fabbione, got a sec with your sparc?
<fabbione> yup
<pygi> fabbione, thanks, will send you mail
<fabbione> ok
<pygi> fabbione, sent
<fabbione> got it
<pitti> ogra: can we easily drop rss-glx and xscreensaver-gl? or will something freak out when we remove it?
<pygi> great
<fabbione> i assume that's against what's in the archive.. right?
<pygi> fabbione, ergh ... yes, but the package failed to build ofcourse
<fabbione> i could guess that ... :)
<pygi> hehe
<pitti> Keybuk: are you ok with me dropping the rss-glx and xscreensaver-gl from desktop? 4.9 MB together
<Ng> win 42
<Ng> bah
<fabbione> pygi: building
<pygi> fabbione, great, fingers crossed that so it works =)
<pitti> cjwatson: do you know whether we can drop one of ttf-kochi-{mincho,gothic}? Both are Japanese fonts, and both are huge
<pitti> cjwatson: same question for ttf-arphic-{ukai,uming}; dropping one of them would basically solve the libgl1-mesa-dri problem
<cjwatson> my memory is that mincho and gothic are like roman and italic
<cjwatson> or something like that
<persia> Rather Serif / Sans-Serif (for gothic/mincho)
<cjwatson> ah
<cjwatson> I knew it was something like that
<cjwatson> if you're going to drop one, it would be better to drop both
<cjwatson> (and make sure language-support-whatever depends on them)
<pitti> yeah, I would do the latter anyway, of course, but still a bit nasty to drop the fonts completely?
<cjwatson> all choices for finding 14MB of space are nasty
<cjwatson> and will make some people unhappy
<cjwatson> on pure number-of-speakers criteria kochi is probably the rational choice
<pitti> that'll give us 8.4 MB
<minghua_> pitti: uming/ukai difference is more like serif/script, rather than serif/sans-serif
<minghua_> pitti: IMO ukai can be safely dropped.  But probably it's just me.
<ogra> pitti, fine with me, to sad i dont ship either in edubuntu 
<pitti> minghua_: does the desktop reasonably work without one of them? and the other one is pulled with language-support-zh?
<ogra> ouch
<ogra> debootsrap failed here
<cjwatson> ogra: details?
<minghua_> pitti: desktop definitely works fine without -ukai, and IMO lang-s-zh shouldn't pull in -ukai
<ogra> cant mount proc
<minghua_> pitti: on the other hand, without -uming the Chinese desktop would be rather ugly
<pitti> minghua_: so -ukai is the 'script' variant? not really for day-to-day desktop texts?
<ogra> (i'm installing to a usb drive, but that shouldnt matter, should it?)
<minghua_> pitti: again, just my personal opinion
<pitti> minghua_: thanks a lot; that's much better than everything I could have figured out :)
<cjwatson> ogra: you're in the best position to debug it
<minghua_> pitti: you can still use it for day-to-day desktop, it's not like "zapf" script, just that more people will be comfortable with -uming
<minghua_> pitti: if it is decided to drop -ukai, I suggest an announcement (to ubuntu-zh list, perhaps)
<pitti> minghua_: I'll add it to language-support-zh then at least
* cjwatson tries debootstrap here just in case
<cjwatson> I did test it with both Debian and Ubuntu before uploading 1.0.0
<ogra> Jun 26 18:19:21 debootstrap: chroot: 
<ogra> Jun 26 18:19:21 debootstrap: cannot execute mount
<ogra> Jun 26 18:19:21 debootstrap: : No such file or directory
<cjwatson> look further up in the log and see if mount didn't get extracted for some reason
<ogra> well, it mounts the disks above
<ogra> Jun 26 18:18:15 kernel: [  296.776000]  EXT3-fs: mounted filesystem with ordered data mode.
<ogra> Jun 26 18:18:15 50mounted-tests: debug: mounted as ext3 filesystem
<ogra> Jun 26 18:18:15 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/10freedos
<minghua_> so which package is going to use the space left by ttf-arphic-ukai?  libgl-mesa-dri?
<cjwatson> ogra: that is not done in the chroot
<pitti> minghua_: right
<cjwatson> ogra: i.e. different mount binary
<ogra> ah, right
<ogra> but there is nothing above
<seb128> pitti: there is no -base language pack updates available
<ogra> Jun 26 18:18:36 main-menu[3053] : INFO: Falling back to the package description for console-setup-udeb 
<ogra> Jun 26 18:18:36 main-menu[3053] : INFO: Menu item 'base-installer' selected 
<ogra> Jun 26 18:18:37 apt-install: Queueing package console-setup for later installation
<ogra> Jun 26 18:19:21 debootstrap: chroot: 
<ogra> Jun 26 18:19:21 debootstrap: cannot execute mount
<ogra> 9
<ogra> oops
<ogra> thats how the log looks like
<seb128> pitti: and language-pack-fr and language-pack-gnome-fr are empty
<pitti> seb128: that's fine, it's a fresh -base update
<seb128> pitti: well, there is no -base update available
<cjwatson> ogra: there should be a debootstrap.log around somewhere
<seb128> pitti: 
<seb128> *** 1:7.10+20070603 0
<seb128>         500 http://archive.ubuntu.com gutsy/main Packages
<seb128>         100 /var/lib/dpkg/status
<seb128> [seb128 : ~] $ 
<cjwatson> perhaps in /target/debootstrap/
<pitti> seb128: right, it's not built yet
<ogra> http://people.ubuntu.com/~ogra/tribe2-syslog
<ogra> i'll get the deboostrap one as well, one moment
<seb128> pitti: k, I'll test when they will be available then
<pitti> seb128: I wonder why it takes so long; in previous times, new langpacks were built in three hours or so
<seb128> https://launchpad.net/ubuntu/+source/language-pack-gnome-fr-base/1:7.10+20070625/+build/353138
<seb128> "took two minutes"
<seb128> just waiting to get it published now then
<pitti> right
<seb128> not sure why the buildd were busy
<pitti> seb128: well, we had a kernel update, too
<seb128> I suspect it's because dholbach rebuilt twice the gtkmm world
<pitti> and that :)
<ogra> cjwatson, nothing in /target ... :/
<ogra> cjwatson, seems it didnt run at all
<cjwatson> it may have been moved elsewhere, e.g. /var/log
<cjwatson> please hunt around
<ogra> cjwatson, i have a pile of packages in /target/var/cache... but no /bin or anything yet
<ogra> only cdrom deboostrap etc lost+found media and var in /target
<cjwatson> might be /target/var/log/bootstrap.log
<cjwatson> ogra: /target/debootstrap/debootstrap.log?
<ogra> nope
<cjwatson> neither of those?
<ogra> nope
<cjwatson> what is in /target/debootstrap ?
<ogra> debpaths
<ogra> nothing else
<ogra> unless its hidden
<cjwatson> can you apply some initiative and look around?
<ogra> nothing hidden either
<ogra> there is no log in /target, i promise
<cjwatson> it is very difficult to do this at a distance, and your replies are pretty brief
<pitti> ogra: hm, so do you want libgl1-mesa-dri back in edubuntu as well? I'm just merging seed changes
<ogra> pitti, i think i'll wait until tribe3 no idea where to get 14M on the liveCD that quickly
<pitti> ogra: ok
<cjwatson> debootstrap works fine in a normal system here
<ogra> yeah, i built a, ltsp client yesterday as well
<cjwatson> I saw somebody else complaining over the last week about debootstrap breaking, but I'm not sure if that was before or after debootstrap 1.0.0
<ogra> well, the error i see on console one is definately right, there is no /target/proc yet
<cjwatson> ogra: what's the context of this breakage? i.e. what CD image?
<ogra> i'll try to run it manually, lets see where it goes
<cjwatson> it's usually not wise to debug the most recent error
<ogra> cjwatson, current daily edubuntu server iso
<cjwatson> you need to find the first error and debug that
<ogra> indeed
<cjwatson> the symptoms are consistent with debootstrap bailing out for some reason before managing to extract required packages
<ogra> yeah
<cjwatson> (/proc is part of base-files)
<ogra> my manual run stops after validating zlib
<cjwatson> stops in what way?
<ogra> i'll -x it
<ogra> W: Failure trying to run: chroot /target mount -t proc proc /proc
<ogra> last line after Validating zlib1g
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/jessica.txt eek, I need to fix that script
<cjwatson> no Extracting?
<ogra> nope
<ogra> and a good load additional deps are found as well
<ogra> the list is usually shorter
<cjwatson> hmm, I wonder
<ogra> base-files is in there btw
<cjwatson> I bet debian-cd's Priority generation is broken
<ogra> hmm
<ogra> all packages are in there now that i look closer
<cjwatson> sounds like fallout from the required/minimal split; if so, my fault
<ogra> strange that it works in non installer mode
<cjwatson> not at all
<pitti> I'm just rebuilding *-meta for seed changes; shall I hold off?
<cjwatson> pitti: no, go ahead
<pitti> i. e. will fixing that require seed/meta changes in any way?
<pitti> ok, thanks
<cjwatson> purely a cdimage bug
* StevenK raises an eyebrow.
<StevenK> Hrm, because I touched ipvsadm last, I'm somehow qualified to answer questions about it...
<pitti> BenC, kylem: I cleaned some kernel bugs from https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=469, but I'm not sure whether -7 fixes any of the remaining ones; can you please have a look?
<pitti> asac: does n-m get you connected if you just have one ethernet interface with the standard dhcp configuration?
<StevenK> pitti: Is archive-cruft-checker fixed? Or should I look at fixing bugs instead?
<pitti> asac: I currently collect the last sources which need to go to the candidate CD images
<pitti> StevenK: it's fixed now
<pitti> StevenK: let me clean up some cruft and then regenerate the lists
<StevenK> pitti: Ah, thanks.
<pochu> pitti: for bug 121441 (which is milestoned for tribe-2), syncing 5.0.41a-1 from debian will fix it.
<ubotu> Launchpad bug 121441 in mysql-dfsg-5.0 "Mysql man pages are non-free" [Critical,In progress]  https://launchpad.net/bugs/121441
<pitti> pochu: oh, cool
<pochu> Since you have sync-powers... ;)
<ogra> pochu, so was a doc package split out ? 
<ogra> i know mathiaz wanted to work on it to not loose the manpage
<pitti> no, manpages removed
<pochu> ogra: no, they removed it from the tarball.
<pochu>    * Removed all manpages from the source (therefore the "41a") as they
<pochu>      are not licensed under the GPL and redistribution is not permitted
<pochu>      (thanks to Mathias Gug). Closes: #430018
<ogra> ah, ok, he said he wanted to keep it in multiverse
<pitti> ogra: that needs a separate source package anyway
<mjg59> ogra: Can't do that if there's no permission to redistribute
<pitti> mjg59: redistribution is fine
<pitti> mjg59: but not modification
<pitti> (AFAIUI)
<tfheen> pitti: "fine".  If you distribute it with the mysql binaries
<tfheen> at least from my skimming of the licence
<Fujitsu> Binaries and manpages have to be on the same medium, it seems.
<Fujitsu> If they really wanted to, I'm sure they could say another component violated that.
<asac> pitti: i will test asap (a few hours) ... i still have to install gutsy ... backup is still running.
<cjwatson> pitti: just waiting for bzr to configure in this upgrade pass before I can get the cdimage thing fixed
<pitti> tfheen: how does asac's n-m perform for you? any better?
<pitti> pochu: synced, thanks for pointing out
<tfheen> pitti: oh, sorry, I completely forgot, I'll test now.
<pitti> tfheen: with my two network cards, it's a tad less broken, but not nearly as smooth as feisty
<fabbione> now i see why my ipv6 address is gone again
<pochu> pitti: cool
<pitti> (RC bugs)-- :)
<fabbione> BZZZT
<fabbione>   * Dropped obsolete
<fabbione>     20_do_not_take_over_dhcpv4iface_when_v6_is_configured.patch
* fabbione starts an hunting session
<pitti> fabbione: please check asac's bzr branch
<fabbione> asac: where is your branch?
<pitti> fabbione: http://bazaar.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x/
<asac> fabbione: use the applet branch as well
<asac> fabbione: https://code.launchpad.net/~ubuntu-core-dev/network-manager/gnome.ubuntu.0.6.x
<fabbione> asac: do you have i386 packages anywhere?
<asac> fabbione: orig is here: http://people.ubuntu.com/~asac/network-manager-applet_0.6.5.orig.tar.gz
<asac> fabbione: no i only have amd64
<asac> atm
<fabbione> ok
<seb128> pitti: any reason the base package stop shipping gdebi.mo
<pitti> seb128: hm, no idea
<fabbione> asac: do you know why Tonio did kill all these patches?
<fabbione> (specially without a reason)
<seb128> fabbione: he moved some patches to an another directory because he doesn't know n-m well enough to rewrite them and they didn't apply to the new code
<seb128> fabbione: 
<seb128> $ ls network-manager-0.6.5/debian/patches-non-applied
<seb128> 19_interfaces_can_have_more_than_one_instance.patch          21_manual_means_always_online.diff
<seb128> 20_do_not_take_over_dhcpv4iface_when_v6_is_configured.patch
<cjwatson> pitti: CDs should be happier now if you rebuild them
<fabbione> seb128: ok
<fabbione> seb128: thanks
<seb128> np
* ogra will be happy as long as interfaces in /e/n/i stay untouched
<seb128> fabbione: he was supposed to ping you and Keybuk about them ...
<asac> fabbione: yes i know
<fabbione> seb128: he didn't.... but ok
<asac> fabbione: he drops patches if the any hunk fails
<fabbione> asac: building your branch... btw.. i don't really need the applet to test if it works. i just need to get NM to ignore my ipv6 interfaces
<asac> fabbione: that patch should be back in
<fabbione> asac: ok... but as core-dev that's not exactly the kind of behaviour i like to see because it introduces a lot of regressions between releases
<asac> fabbione: for instance debian_backend patch ... the first hunk was applied upstream ... thus tonio dropped the complete patch without looking if the rest works
<fabbione> asac: yeah it is.. i am building and testing..
<fabbione> i need to reboot to complete the test
<asac> ... and that lead to followup problems with other patches that diden't apply anymore
<asac> so the card-house broke :)
<cjwatson> asking for help when you get stuck is one of the behaviours we try to test for (and ask about) in core-dev applicants, so somebody should have a quiet word and remind him of it
<cjwatson> of course everyone makes mistakes once in a while
<asac> yes ... i think the mistake was really not to ask for help 
<fabbione> yeps.... it's not a tragedy...
<fabbione> brb.. testing
<pitti> seb128: can you please file a tribe-3 bug about that? against language-pack-fr, and assign it to me?
<seb128> pitti: sure
<pitti> cjwatson: thanks, good timing; I wanted to trigger new ones after that publisher run
<pitti> ogra: untouched> that works(-ish) with asac's branch again, but *not* with the version in the archive
* ogra takes a break
<ogra> pitti, well i havent tried it at all yet ...  i'll drop it from desktop and keep it in live i think if it makes probs ...
<ogra> its still only tribe2 we're building here
<pitti> ogra: what about that nbd bug? do you want to release tribe-2 at all?
<ogra> we fixed it 
<pitti> ah, cool
<ogra> it turned out to be easier than i thought
<ogra> upstream already took the patch :)
<pitti> ogra: I'll build new images soonish; they won't be final yet, but I need them for verifying compiz stuff and sizes
<pitti> ogra: and they should fix the debootstrap issue
<ogra> pitti, i need them toi verify ltsp builds :)
<ogra> the new mksquashfs stuff is still untested in d-i 
<pitti> fine
<ogra> and will be very unresponsive ... 
<pitti> ?
<ogra> pitti, the installer part doesnt tell you it runs mksquashfs ... and squashing up the chroot csn take 10 mins
<ogra> *can
<pitti> ah, ok
<ogra> so it will look very odd to users
<seb128> pitti: the english language pack has no gdebi neither, so it's not specific to the -fr languagepack
<seb128> pitti: bug #122277 BTW
<ubotu> Launchpad bug 122277 in language-pack-fr-base "gutsy language pack doesn't ship the gdebi translation" [Undecided,New]  https://launchpad.net/bugs/122277
<pitti> seb128: right, probably a bug in langpack-o-matic, or it hasn't been part of the rosetta export; I'll have a look later
<pitti> seb128: thanks; as long as it's milestoned and assigned to me, I'll get to it no matter what the source package is
<seb128> k
* pitti hugs seb128, thanks
* seb128 hugs pitti back
<EtienneG> pitti, re #120659, that's perfectly ok with me as I was just going to sit on it until fixed in upstream (hopefully next release)
<EtienneG> so I do not mind at all
<pitti> EtienneG: ok; I needed it quickly to kick out python2.4
<sladen> afternoon in Europe, or evening in Asia?
<Keybuk> oops, got a bit punchy with the shutdown dialog there
<Keybuk> I only meant to logout the experimental user session I had
<pitti> heh, so I'm not the only one who occasionally hits the wrong button :)
<pitti> too many choices
<Keybuk> not only that, but *should* shutdown work if there are other users still logged in?
<ogra> the debian-gtk-gnome list is just discussing that :)
<pitti> StevenK: http://people.ubuntu.com/~pitti/tmp/cruft/ updated
<StevenK> pitti: Ah, thanks.
<mpt> A simpler shutdown alert would have room for a warning about other people being logged in
<StevenK> pitti: Ah, I like that page much better now that I've refreshed it. :-)
<cjwatson> even leaving that aside, there should be room in the one that's there; at worst some icons might need to be shrunk
<pitti> StevenK: heh
<mpt> cjwatson, true, I misstated the problem
<mpt> A simpler shutdown/restart alert would know that you were about to choose an option that would inconvenience other logged-in people
<mpt> and therefore be able to warn you
<asac> pitti: -granparadiso are still in queue?
<pitti> asac: I newed it last night
<mpt> as opposed to an alert that also contains actions like Lock and Log Out that are safe for other users
<asac> pitti: they are still there :)
<mpt> s/alert/dialog/
<asac> pitti: https://launchpad.net/ubuntu/gutsy/+queue?start=20
<pitti> asac: hm, weird
<asac> i noticed because forum users complained ;)
<pitti> accepted now
<pitti> Hobbsee!
<asac> pitti: thx
* ajmitch waves to Hobbsee 
<Hobbsee> pitti!
* Hobbsee hugs pitti 
<Hobbsee> hiya ajmitch 
<dholbach> somebody please give back gconfmm2.6
<pitti> dholbach: again?
<pitti> dholbach: odne
<pitti> done, too
<dholbach> thanks pitti
<fabbione> asac: your branch looks good here
<pitti> fabbione: \o/
<asac> cool :)
<asac> fabbione: i hope that my backup finishes in 10 min so i can finally get a gutsy install on a real system :/
<asac> why the hell do hard-disks always fill up with a ridiculous amount of data?
<cjwatson> sigh, qemu in a chroot on an under-memoried machine over ssh X forwarding is not the fastest thing ever
<asac> cjwatson: hehe :) ... i tried to build netbsd kernel once in qemu
<asac> but gave up
<fabbione> asac: stop the torrents :)
<asac> fabbione: can you try if the applet works somehow as well?
<asac> fabbione: what kind of network setup do you have btw?
<fabbione> asac: one thing at a time
<tfheen> asac: "complex" would probably be the first letter of describing fabbione's setup. :-P
<fabbione> tfheen: ahahha no no
<fabbione> asac: this machine is one and only one wired ethernet card.. dhcp ipv4 and static ipv6
<fabbione> asac: problem is that nm doesn't know how to handle ipv6 at all
<fabbione> asac: so it needs to ignore the interfaces with such setup, and that's what my patch does
<pitti> mvo: http://cdimage.ubuntu.com/daily/current/ -> nice shot, fits precisely :)
<pitti> mvo: can you give this a quick test wrt. compiz?
<asac> tfheen: could you test nm?
<StevenK> pitti: I think archive-cruft-checker is telling lies.
<mvo> pitti: rsyncing
<pitti> StevenK: is it?
<fabbione> asac: ok.. i installed the applet package.. how do i kick the applet?
<asac> kick? 
<asac> restart?
<StevenK> pitti: libk3b2 is listed in libflac++5, but I've uploaded a rebuild and the build logs show the package depending on libflac++6
<StevenK> rmadison shows the right version in the archive.
<pitti> hmm
<pitti> StevenK: might not yet have been published
<pitti> (at the time I ran it)
<tfheen> asac: it seems to do the right thing here
<StevenK> pitti: I don't think so, I uploaded it 2 days ago.
<asac> tfheen: what stup?
<asac> setup
<pitti> hm
<fabbione> asac: yeah whatever.. make it appear or what do you need me to check
<asac> kilall nm-applet
<asac> then start nm-applet --sm-disable 
<StevenK> steven@infected:/srv/mirror/ubuntu/pool/main/k/k3b$ dpkg -I libk3b2_1.0.1-1ubuntu2_amd64.deb | grep Depends | cut -d, -f11-12
<StevenK>  libflac++6, libflac8
<StevenK> pitti: ^
<pitti> StevenK: hm, then just ignore it for now; I'll investigate later
<fabbione> asac: looks ok
<StevenK> pitti: Aye, doing so.
<asac> fabbione: thanks a lot
<pitti> yay, vmware 6 native amd64
<fabbione> no problem
<StevenK> pitti: Same thing with audacity.
<ogra> gah
<ogra> 1M oversized ...
* ogra curses
<doko> pitti: would you be ok with gcc-4.X uploads to introduce lpia support and fix some libstdc++ locale regressions?
<pitti> ogra: ? http://cdimage.ubuntu.com/edubuntu/daily/20070626/ seems fine?
<ogra> 20070626.1 ?
<ogra> :)
<StevenK> ogra: Kill the ISO9660 lead-in? Like you need it anyway. :-P
<ogra> heh
<pitti> ogra: ah, right, sorry
<pygi> StevenK, don't you touch ECMA standards :)
<StevenK> pygi: :-P
<ogra> StevenK, well, i personally use DVD-RW for testing so it doesnt really matter for me ... 
<pitti> doko: hm, that'll take ages to build
<ogra> but our users might care :)
<StevenK> Heh
<pitti> asac: so, did you hear anything bad about your branch? if not, then about *now* is the right time to upload them :)
* pygi implements a special argument in libisofs public api called "StevenK"
<TheMuso> Is documentation being put together about tribe 2 yet? If so, I would like to add a small accessibility/speech tidbit.
<pitti> TheMuso: it's supposed to get on https://wiki.ubuntu.com/GutsyGibbon/Tribe2; Corey wanted to work on it, but hasn't yet
<TheMuso> pitti: Ok.
<TheMuso> I'll send him an email.
<pitti> TheMuso: appreciated, cheers
<asac> pitti: ok ... i will upload then :)
<pitti> asac: please :)
* pitti hugs asac
<StevenK> pitti: :-P
<StevenK> Er, pygi 
<StevenK> Sorry, pitti 
<pitti> StevenK: I don't feel terribly annoyed when getting an erroneous smiley :)
<StevenK> pitti: I didn't think so, but still. :-)
<StevenK> FlacCodecPlugin.cpp:46: error: cannot allocate an object of abstract type 'FlacEncoder' because the following virtual functions are pure within 'FlacEncoder'
<asac> pitti: network-manager pushed ... i wait a bit with applet as i tightened applet build-depends
* StevenK feels his C++ knowledge run out.
<pitti> asac: if b-deps are correct, please upload it now
<asac> k
<pitti> asac: or, rather, please upload it now and make sure the build deps are correct :)
<Fujitsu> How would that be failing on just !i386?
<asac> pitti: done ... build-deps should be ok now (e.g. network-manager-dev >= 0.6.5-0ubuntu3)
<pitti> asac: I'll drive the publisher manually again to speed this up, I guess
<mvo> holly cow, I got a noticiation from alsa that something changed and I need to refresh my presets on a terminal
<mvo> that message is really cryptic
<mvo> and why would I want to change my default sound card if I have only one?
<thom> speaking of cryptic errors, apt has some really good ones
<Keybuk> the best bit about apt's errors is that they're not pastable on IRC
<Hobbsee> Keybuk: um, why not?
<StevenK> mvo: Just in case you want to change it for a better one? :-)
* mvo pretends that his connection dropped
<Keybuk> Hobbsee: they begin "E:" or "W:"
<thom> if you have dodgy nick expansion, no
<thom> mvo__: hah
<Hobbsee> Keybuk: ahhh
<Keybuk> Hobbsee: so they become EtienneG: or Watersevenub: ... :p
<Hobbsee> Keybuk: only if you have a crappy client :P
<mvo__> lol
<Hobbsee> xchat.  exactly.
<StevenK> E: foo
<StevenK> Ah ha
<Watersevenub> Keybuk, hey! :-p
<thom> W: Bizarre Error - File size is not what the server reported 3678 1839
<Keybuk> Hobbsee: xchat requires you press tab, so it doesn't count for me :p
<Hobbsee> irssi and konversation handle it correctly
<evand> It makes me feel needed.
<thom> is my current favourite
<thom> _which_ file?
<Keybuk> evand: careful, someone might give you more work to do :p
<evand> haha
<StevenK> thom: Heheh. You have to guess, which is part of the fun.
* Hobbsee makes Keybuk fix every bug in ubuntu.
* Keybuk assigns the bugs to members of his team to fix
<simira> Hobbsee: ++!
<Keybuk> yay management
<Hobbsee> Keybuk: having to press tab is a good thing
<Hobbsee> hey simira!
<Hobbsee> Keybuk: that works too :)
<mvo__> thom: *cough* yes *cough*
* Hobbsee hugs simira 
<simira> :)
<thom> mind you, i know why i get lots of them from apt-transport-https now, so i might actually fix it soon
<StevenK> thom: Neat non-HTTPS assumptions in the code?
<thom> nah, seems like it's a missing callback
<seb128> ogra: about bug #121447, is having "about ubuntu" on edubuntu really a problem?
<ubotu> Launchpad bug 121447 in gnome-panel "Both About Ubuntu and About Edubuntu show up in menu" [Undecided,New]  https://launchpad.net/bugs/121447
<ogra> seb128, well, it would be nice to have them with different icons 
<seb128> ogra: I'm not sure than installing edubuntu-docs on Ubuntu should make "about ubuntu" be not listed
<ogra> i'm fine with having them both, but they both show the edubuntu icon indeed
<ogra> since they are hardcoded to use the distributor-icon
<seb128> hum
<seb128> we should change the about-ubuntu to always use an ubuntu icon then
<seb128> and about-edubuntu to always use the edubuntu icon
<ogra> probably
<ogra> the would indeed need new icons
<pitti> mvo: fuck, libgl1-mesa-dri isn't on the fresh Ubuntu live; apparently it missed one more publisher run to refresh germinate
<ogra> or do we have the logo anywhere else ?
<ogra> pitti, rebuilt the livefs ?
<pitti> ogra: yeah, sure
<seb128> ogra: we should add icons
<pitti> mvo: the alternate has it, though, so testing that should be fine for now
<ogra> seb128, yeah
<ogra> lets look into that after tribe2
<seb128> k
<mvo> pitti: rsyncing
<Hobbsee> mvo: how much is it actually pulling down when you're rsyncing?
<Hobbsee> mvo: should it be ~600mb, from going to tribe 1 to current?
<mvo> Hobbsee: its usually much smaller, even when feisty is used as the starting point
<Hobbsee> rsync -zhhP rsync://cdimage.ubuntu.com/cdi                                                          mage/kubuntu/daily-live/current/gutsy-desktop-i386.iso kubuntu-gutsy-desktop-i38                                                          6.iso
<Hobbsee> gutsy-desktop-i386.iso
<Hobbsee>      249.65M  37%  103.07kB/s    1:10:07
<pitti> Hobbsee: it was some 30 MB for me, since jigdo scanned /var/cache/apt/archives/ :)
<Hobbsee> that looks odd.
<pitti> Hobbsee: ah, -desktop
<asac> pitti: both wait for approval
<asac> pitti: according to mail
<asac> pitti: nm ... received accepted
<pitti> asac: I accepted them already, waiting for the publisher to finish, so that I can start another publisher run
<Hobbsee> pitti: as in, rsync doesnt work for desktop?
<pitti> Hobbsee: no, jigdo doesn't
<Hobbsee> ahh
<Hobbsee> right
<StevenK> I wish there was a way to jigdo -desktop images.
<pitti> StevenK: in theory you can, but since it is, by and large, one large file and a bit of plumbing, it doesn't make much sense
<StevenK> Yes.
* Hobbsee hopes that it doesnt mean that any changes to the one large file require you downloading said file again.
<Hobbsee> rather, only parts of it
<pitti> Hobbsee: no, that'll be rsynced
<Hobbsee> good
<Hobbsee> that's what i thought....but looking at this...
<pitti> Hobbsee: might just be a part which changed heavily
<Hobbsee> pitti: indeed.
<Hobbsee> pitti: good thing it's the 26th, then
<StevenK> That's a point.
* StevenK checks his usage.
<StevenK> Hmph. Not even half way
<Hobbsee> lucky you.
<pitti> hi heno
<heno> Hi pitti
* Hobbsee waves to heno 
<pitti> heno: btw, the current set of images should at least boot and install; they are still missing a fixed network-manager and the lives are missing libgl1-mesa-dri, but for an initial test they should be good
<heno> pitti: ok, I'll start posting Tribe-2 in the tracker and solicit testing help
* heno waves to Hobbsee
<Hobbsee> :)
<pygi> o no, Hobbsee is back :P
<Hobbsee> pygi: indeed.  cue lots of DOOM!!!!!!!!!11
<pygi> Hobbsee, not on me :)
<Hobbsee> i dont know about that...
<pygi> you do
* Hobbsee wonders if it's a realistic goal to get all of the kde bugs triaged, and forwarded upstream as necessary, by kde4 beta freeze.
<pygi> I don't think so
<Hobbsee> pity
<calc> Hobbsee: good luck with that, heh
<Hobbsee> yes......
<calc> Hobbsee: i want to do something similar with OOo but i think KDE has even more bugs than that
<Hobbsee> calc: looks like you may not get your membership today, either
<calc> Hobbsee: hmm?
<Hobbsee> calc: with them taking so long
<calc> Hobbsee: heh perhaps, serbia took > 30m
<Hobbsee> calc: indeed.  i wish taht wasnt normal for CC meetings
<calc> they should just +1 brazil already, heh
<Hobbsee> i thought they were going to do Loco's elsewhere, so tehy didnt block the rest of the CC.  
<Hobbsee> weird.
<elkbuntu> Hobbsee, you note how we dont have jono's input on the irc council... similar reason i believe
<cjwatson> pitti: you might be running into that bug where the task overrides don't get refreshed unless there's something to publish
<cjwatson> (which we haven't fixed yet)
<cjwatson> pitti: publishing some random universe package from the queue usually works around it, if you have one handy
<Hobbsee> elkbuntu: ah great.  i love how one person can block absolutely everything.  for weeks.
<StevenK> I think I uploaded one.
<StevenK> Oh, I did, ufraw.
<elkbuntu> Hobbsee, the problem is that he is only one person
<pygi> calc, you going for member today?
<elkbuntu> and planes dont have internet
<Hobbsee> elkbuntu: this is true.  and travelling a lot
<StevenK> pitti: ^
<pitti> cjwatson: I'm currently publishing network-manager etc. anyway, so it should work
<Hobbsee> pitti: i'm rsync-illiterate, it only downloaded 166.46M, at final count
<pitti> cjwatson: it's the same trap I ran into before when trying to downsize the edubuntu images for tribe-1, I think
<calc> pygi: if there is time in the meeting, yea
<ogra> bah
<pitti> cjwatson: I guess we'll move bug 120107 to tribe-3?
<ubotu> Launchpad bug 120107 in debian-installer "[gutsy]  Ubuntu Live CD memory requirements need updating" [Low,Confirmed]  https://launchpad.net/bugs/120107
<pitti> mvo: I move bug 121770 to tribe3, FYI
<ubotu> Launchpad bug 121770 in apt "apt-source should ignore X-Vcs-Browser" [Low,Confirmed]  https://launchpad.net/bugs/121770
* ogra just spent 20 min to try to get the autohiding (which wasnt enabled) of the top panel away ...
<ScottK> keescook: Are you around and do you have a few minutes for a discussion about gnupg configuration?
<ogra> then i noticed the display was just off 
<ogra> sigh
<pitti> mvo: in fact, I'll drop the milestone altogether, it's not really tied to release-criticalness
<pitti> ogra: lol
<keescook> ScottK: I'm here, but I'm not an gnupg expert; what's up?
<cjwatson> pitti: unless you want me to do it now
<mvo> pitti: ok
<ScottK> keescook: OK.  I trying to find the right person to discuss the idea of having gnupg use gpg-agent by default.  It would clear up a bunch of trouble (along with other stuff I'm doing) with both PGP and S/MIME in kmail.
<pitti> cjwatson: I'd rather have it later, I try to avoid any further uploads to the archive now
<pitti> well, for things that affect CDs, that is
<keescook> by default?  hmm.  I'm not sure if it's ready for that -- I had a ton of problems with it myself.
<pitti> hi keescook
* keescook hugs pitti
<ScottK> keescook: Really.
<keescook> ScottK: yeah, but it could be that I don't know what I'm doing.
<keescook> ScottK: are there any ubuntu-specific docs about it?
<ScottK> keescook: OK.  Well it's necessary for both S/MIME signing/encryption and PGP in kmail.
<keescook> a good first step might be documenting how it all fits together
<keescook> i.e. a wiki page with "here are the steps to make it work"
<ScottK> Right
<pitti> mvo: hmm, not good. standard amd64/alternate vmware install, and I cannot login; It quickly starts the session, then kills and restarts X
<keescook> and from there, if it seems extensible, we can try to move to have it be the default configuration.
<ScottK> Part of the Gutsy plan for KDE is to have S/MIME by default and I know it's needed for that.
<cjwatson> pitti: ok
<ScottK> I haven't figured a clean way to have gnupg use gpg-agent if and only if kmail is installed.
<ScottK> keescook: Thanks.  I'll work on writing something up.
<keescook> ScottK: cool!  I'm looking forward to it; I'd use it myself.  :)
<mvo> pitti: I know, I'm currently debugging it
<mvo> pitti: happens only in vmware it seems
<pitti> mvo: checking for texture_from_bitmap: fail / then it tries again with indirect rendering, checks, and kills X
<Fujitsu> Isn't S/MIME completely separate from OpenGPG?
<Fujitsu> *OpenPGP
<pitti> mvo: same on the live system
<ScottK> Fujitsu: Technically, yes, but it's all managed by different bits of gnupg programs (gpgsm for S/MIME).
<mvo> pitti: another oddity (at least on the live system) is that /proc/$foo/maps is not readable
<pitti> mvo: that's deliberate on the new kernel
<pitti> keescook: ^ right?
<pitti> you need to ptrace a process before you can read maps
<mvo> pitti: oh? that is bad for me(tm) as it seems to be the only reliable way test what driver X is currently using
<keescook> mvo, pitti: maps is unreadable, yes.  ptrace, however, is not needed.
<keescook> mvo: can you explain the situation?
<pitti> mvo: ah, nice trick; I'm still looking for a way in restricted-manager to determine the currently running X driver
<pitti> mvo: for manual checks you can look into /var/log/Xorg.0.log
<keescook> mvo: basically "maps" is treated like "mem" now, but without the ptracing requirement
<mvo> keescook: essentially there is a bug with vga, vesa driver that makes glxinfo kill the session when glxinfo is called (most likely on vmware driver too). so to work around this I check /proc/`pidof X`/maps 
<mvo> if that no longer works, that would explain the breakage
<mvo> pitti: yes, but that one is hard to parse :/
<keescook> and the process doing that is not running as root?
<mvo> keescook: yes, its the compiz wrapper script that run as the regular user
<mjg59> mvo: I suspect we ought to fix those drivers :)
<pitti> keescook: weird: -r--r--r-- 1 root root 0 2007-06-26 16:06 /proc/1/maps is world readable, but cat'ing it as user fails
<keescook> mvo: hm, I wonder if we can work around this by having X spit out the needed info to a file in /var/run or similar?
<mvo> mjg59: indeed
<pitti> keescook: this new restriction should be reflected in the permissions (440)
<keescook> pitti: correct; it's an in-kernel check.
<pitti> current driver in var/run> yay, me too!
<keescook> pitti: i cannot be reflected in the perms -- I had a very long discussion about this on lkml.
<pitti> keescook: hm, if only the owner can read it, what's worse with 440 instead of the current 444?
<keescook> to disable it system-wide,   echo "0" > /proc/sys/kernel/maps_protect
<keescook> pitti: setuid programs won't be able to read their own maps file.
<pitti> mvo: ah, so it's glxinfo that causes the X crash; makes sense then
<pitti> mvo: I'll try with keescook's workaround
<mvo> https://bugs.launchpad.net/xorg-server/+bug/119341
<ubotu> Launchpad bug 119341 in xorg-server "glxinfo command causes Xorg to abort on Dimension E520" [Unknown,Confirmed]  
<keescook> the setting is coming from procps (/etc/sysctl.conf)
<mvo> there seems to be multiple reports about the breakage
<mvo> pitti: vmware (the driver) is not yet blacklisted so just enabling maps again may not help
<heno> === Tribe 2 candidates available for testing. see: https://isotesting.stgraber.org ===
<mvo> keescook: what is the thing that needs to be protected? the exact memory location? if so, could we get a mode where we see what is mapped but not where?
<mjg59> Hm.
<mjg59> Ok, it segfaults rather than aborting
<pitti> mvo: yes, the idea is to hide the addresses, to avoid circumventing address randomization
<pitti> mvo: merely showing the loaded libraries is fine AFAICS
<pitti> keescook: ^ do you agree?
<keescook> mvo: this was also discussed, it's also considered a privacy leak (i.e. I can see what files someone else has mapped, not just libraries)
<pitti> mvo: not something we could fix for tribe-2, though :/
<mjg59> mvo: Does running /any/ GL app cause the crash, or is it just glxinfo?
<keescook> pitti: generally, yes, but since mmap'd files are not easily distinguishable from mmap'd libraries, there's no good way to handle it.
<keescook> there were people on lkml who actually wanted the reverse too
<mvo> mjg59: not sure, I can check that, but I need to change my x-session for this
<keescook> i.e. don't show file names, just show mappings.
<mjg59> mvo: It'd be a good sanity check
<pitti> mvo: indeed, that didn't help
<pitti> mvo: is the blacklist somewhere in ASCII, where I could add vmware in-place?
<pitti> mvo: ah, so if I s/vmware/vesa/ in xorg.conf and disable maps protection it works
<pitti> seb128, mvo: the session splash screen stays around forever for me; did you see that already?
<mvo> pitti, keescook: what kernel upload enabled maps protection?
<seb128> pitti: only when using compiz?
<keescook> mvo: the very first 2.6.22
<seb128> pitti: does clicking on it make it go away?
<keescook> well, that one contained it, but the procps upload enabled it
<pitti> seb128: yes
<keescook> mvo: 10 May 2007  procps (1:3.2.7-3ubuntu3) gutsy
<bryce> hi
<seb128> that's usually due to software not registering correctly
<seb128> it goes away after a minute or so, there is a timeout
<pitti> hm, and the shutdown menu doesn't appear when I use the menu entry
<pitti> hey bryce
<keescook> bryce: do you know of a reliable way to detect the current X.org driver without reading the /proc/$(pidof X)/maps file or the logs?
<seb128> pitti: usually same reason, session management waiting on a buggy app
<pitti> seb128: do you get that, too? (I just did a normal alternate vmware install)
<seb128> no
<seb128> and we got no recent bug about it
<pitti> hm, I'll boot the live CD on my real hw to test this
<seb128> might also been due to lo not correctly configured
<bryce> keescook: I talked with the xorg folks about that, and unfortunately no, the only ways are maps / smaps, or reading the xorg log
<keescook> mvo: sorry about the breakage.  :(  I tried to get the maps change in as early as possible in gutsy.
<pitti> seb128: lo is fine
<ogra> pitti, seb128 we have these lo probs often ... shouldnt we just hardcode it anywhere ?
<ulaas> does gutsy have issues with network manager?
<pitti> ulaas: lots
<keescook> bryce: okay.  Sounds like we'll need some kind of X wrapper to spit out the needed info then.
<pitti> ogra: but that wasn't it this time
<ulaas> pitti, cool
<pitti> ulaas: cool, rather
<ogra> pitti, well *this time* :)
<bryce> keescook: can you explain the issue?  skimming the backlog sounds like something about the kernel randomizing the maps now?
<ulaas> pitti, knowing that its not me is cool
<seb128> ogra: what do you want to hardcode?
<ogra> seb128, lo creation and setup
<seb128> ah
<ogra> i have seen users taht deleted /e/n/i because they thought it wouldnt be needed with NM
<ogra> for example ...
<ogra> so just hardcoiding it would be a safer way imho 
<keescook> bryce: the issue is that mvo's compiz wrapper needs to know which driver is being used by X so it can know if it's on the blacklist or not.  it was using /proc/$(pidof X)/maps to find this info, but with recent privacy/security changes maps files from other user's processes are not readable.
<ogra> we need it anyway all the time
<keescook> bryce: since compiz is running as a regular user, and X is running as root, the maps file is not readable.
<keescook> besides totally disabling maps protection system-wide, I was suggesting that some root-running tool tied to X should spit out the driver it is using to some file in /var/run or a similar location.
<pitti> mvo, bryce: would grep -q /usr/lib/xorg/modules/drivers/${BLACKLISTED_DRIVER}_drv /var/log/Xorg.0.log be an acceptable workaround for tribe-2?
<iwj> Phew, IBM have agreed my laptop (which broke at Debconf) is under warranty and they'll fix it.
<pitti> mvo: or simply parsing it out of xorg.conf?
<iwj> But I have to hurry and send it to them so as to have it at the sprint.
<bryce> I like the idea of some root-level tool generating the driver list
<pitti> mvo: i. e. egrep -q "Driver[[:space:] ] *\"${BLACKLISTED_DRIVER}\"" /etc/X11/xorg.conf ?
<mvo> pitti: there may be a alternative xorg.conf in use (also that coudl be figured out with xsset )
<bryce> btw, this driver info is also going to be needed for bulletproof-x and maybe other things
<Hobbsee> morning bryce 
<bryce> hi Hobbsee
<pitti> mvo: hm, but parsing the log? it doesn't need to be a 100% accurate for tribe-2, I guess
<dholbach> could somebody give back gparted and inkscape please?
<keescook> grep -q /usr/lib/xorg/modules/drivers/+${BLACKLISTED_DRIVER}_drv /var/log/Xorg.0.log
<Hobbsee> bryce: fixed packages are at www.wedontsleep.org/~sarah/mesa, btw
<pitti> dholbach: yes
<bryce> Hobbsee: ah thanks
<dholbach> thanks pitti
<keescook> there are extra /'s in my log, for some reason: (II) Loading /usr/lib/xorg/modules/drivers//nv_drv.so
<johanbr> What about X servers not on display 0 ?
<pitti> dholbach: done
<pitti> johanbr: that falls under the 'not 100% accurate' clause, I think
<Hobbsee> bryce: dunno what you built with, but a rebuild fixed the mesa-utils, and libgl stuff
<bryce> it would be ideal if the solution did not require use of Xorg.0.log since for bulletproof-x we want to know the driver *before* xorg starts up
<pitti> eventually something like an easy xset call is necessary which gets the driver from the X it runs under
<bryce> Hobbsee: I used pbuilder; what did you use?
<mvo> I will prepare something that does not rely on maps and see how well that goes
<Hobbsee> bryce: pbuilder.
<Hobbsee> bryce: but yours came up with weird shlibdeps.  *shrugs*
<Hobbsee> bryce: added the conflict too, so it should be all installable - but i iddnt test the swx11* stuff
<pitti>   233792 | S- | libcompizconfig      | 0.0+git20070626-0ubu | eight minutes
<pitti> mvo: ^ do we want that?
<bryce> Hobbsee: thanks, too bad it didn't make the tribe2 freeze.  I'll review and work on getting it uploaded
<Hobbsee> bryce: well, i did consider shoving it...
<pitti> mvo: the 'do not bind top-left edge to expo plugin' was something you cared about, right?
<mvo> pitti: yes, it makes seb128 happy
<seb128> pitti: it fixes compiz conflictings with the GNOME menu
<StevenK> bryce: I'm worried about the mesa-utils shlibs your build showed. Do you mind trying to rebuild and seeing if the same broken shlibs are used?
<pitti> asac: http://launchpadlibrarian.net/8198306/buildlog_ubuntu-gutsy-i386.network-manager_0.6.5-0ubuntu3_FAILEDTOBUILD.txt.gz
<pitti> asac: seems it needs an iproute2 build dep; can you please fix that quickly?
<bryce> StevenK: sure, what did you do to determine the shlibs were broken?
<asac> pitti: yes
* calc will be up in ubuntu-meeting in ~ 10m :)
<pitti> asac: hm, tonio already did that in -0ubuntu2, but he added iproute, not iproute2
<pitti> asac: hm, weird; WTH?
<StevenK> bryce: A dpkg -I of mesa-utils didn't correspond to any of the shlibs in debian/*.shlibs
<StevenK> bryce: (dpkg -I is "print control information for specified .deb)
<pitti> asac: that didn't happen at my local build
<bryce> ok thanks
<StevenK> bryce: dpkg-shlibdeps can slip up, but it's rare, so I'm quite curious.
<pitti> asac: it checks for /sbin/ip
<pitti> asac: which is in iproute *boggle*
<asac> yeah ... i have added iproute
* asac wonders why i lost it this modification in the first place :/
<pitti> asac: the build log doesn't mention installing it
<ogra> cjwatson, ah, that base install looks a lot more familiar :)
<pitti> asac: hm, indeed 0.6.5-0ubuntu3 dropped it
<pitti> asac: it seems it is in bzr, but not in the package
<asac> pitti: its in bzr?
<asac> no 
<dholbach> also please give back libglademm2.4 libgnomecanvasmm2.6 hardware-monitor libgtksourceviewmm
<cjwatson> ogra: good stuff
<asac> pitti: i will upload now.
<pitti> asac: ah, crap, it's only a binary depends, no b-dep
<pitti> asac: please; thanks
<asac> yeah ;)
<pitti> asac: 50 seconds until next uploader run :)
<asac> ok its up
<asac> did it get this run?
<evand> pitti: The version of ubiquity on the current CDs crashes due to bug #122141.  I've added a small workaround for the time being and released 1.5.4, which cjwatson will upload.
<ubotu> Launchpad bug 122141 in gtk+2.0 "SIGSEGV in gtk.Button.set_image" [High,Triaged]  https://launchpad.net/bugs/122141
<asac> i have a phone conference in 15 min. so if there are problems i cannot fix it till about 1800 Europe/Berlin
<asac> pitti: ^^^
* pitti ^5s asac; accepted
<asac> cool :)
<pitti> evand: fine for me; can it be uploaded right now? I'm about to run the publisher
<evand> cjwatson?
<keescook> evand: is it online somewhere where someone else can sponsor it from?
<cjwatson> give me a minute
<mvo> pitti: whatever it is that kills the login in vmware, its not compiz releated it seems. I changed gconf and linked metacity to compiz and the login still fails 
<cjwatson> it's in progress
<pitti> mvo: weird
<dholbach> also please give back libglademm2.4 libgnomecanvasmm2.6 hardware-monitor libgtksourceviewmm
<mvo> indeed
<pitti> mvo: disabling maps and changing driver to vesa worked
<mvo> especially since I do not see it on real hardware
<pitti> dholbach: yep
<dholbach> thanks
<ogra> mvo, remove the pieces from /etc/xdg/autostart one by one ;)
<mvo> maybe its vmware driver releated (vmware X driver)
<cjwatson> oh, whee, there's a bunch of other stuff in 1.5.4 that wasn't uploaded pre-freeze
<cjwatson> pitti: http://people.ubuntu.com/~evand/upload/ubiquity_1.5.4_source.changes <- your call
<pitti> cjwatson: the bug fixes look good, have the .ui/.glade file moves been tested?
<evand> yes
<evand> well, I've tested it lightly
<mvo> ogra: switching from vmware -> vesa in xorg fixed it
<cjwatson> .glade is just source rearrangement, .ui actually affects the binaries
<ogra> mvo, oh
<cjwatson> oh, well, Mario's glade rearrangements affect the binaries of course
<pitti> evand: i. e. someone actually ran an Ubuntu and Kubuntu install with it?
<pygi> cjwatson, what about me? o.O
<mvo> bryce: current X vmware driver seems to break under vmware. have you seen this too? happens on the current gutsy livecd for me
<cjwatson> pygi: the other Mario
<pygi> cjwatson, oki
<bryce> mvo, I heard there were problems with the vmware mouse driver, but not the video driver
<evand> pitti: I can run through the former really quick, to test all of 1.5.4.  But prior to now I've only tested the glade changes and crash fix.
<pitti> evand: ok, so you think the glade changes themselves don't break?
<evand> I'm certain of it
<pitti> evand: we'll still have time to do another upload if we need (we are blocked on the compiz fixes anyway)
<bryce> mvo, is there a bug in on it?  I'll take a look at it once I have a suitable vmware environment set up
<pitti> evand: ok, so let's give this a try
<pitti> cjwatson: please upload then
<evand> pitti: ok, I'll continue testing just to be safe
<pitti> evand: thanks, appreciated; it's easier to reupload ubiquity before building new live images
<mvo> bryce: not yet, I can report one now
<bryce> cool thanks
<cjwatson> the partial fix for bug 95619 is pretty important to have in anyway
<ubotu> Launchpad bug 95619 in ubiquity "Feisty-Beta installer: mountpoint change needs partition size change!" [Undecided,Confirmed]  https://launchpad.net/bugs/95619
<cjwatson> sorry, I'd forgotten we hadn't uploaded that earlier
<cjwatson> evand,pitti: uploaded
<pitti> heno: xubuntu CDs are 26, not 26.1
<pitti> dholbach: oh, btw, I gave back that bunch
<pitti> cjwatson: cheers
<heno> pitti: ok, will fix
<dholbach> pitti: thanks a lot
<wasabi> So... I remember some talk, years ago, about delivering diff's of .deb files.
<wasabi> Instead of the full deb itself. Did that go anywhere?
<ion_> I grabbed the bzr tree, intending to do something with it, but never got around to it. :-(
<wasabi> Oddly enough a simple xdelta between two package versions seems to do pretty good.
<persia> wasabi: There are works in progress, but nothing is complete yet.  http://sianka.free.fr/ is the most mature of which I am aware, but not necessarily the best.
<robertj> wasabi: I think there was some experimental work done on a dpkg fork that support that and some alternate compression types at the dpkg level
<wasabi> Wonder why such a construct can't be nothing more than a little apt patch.
<wasabi> "oh, I have a package in /var/cache? And tehre's a diff from that to X, grab that, apply, continue as normal"
<ion_> wasabi: IIRC it uses zsync. I could remember incorrectly, though.
<ion_> wasabi: Perhaps zsync was actually used for both control.tar.gz and data.tar.gz separately, or something like that.
<wasabi> Oh, apt-torrent is interesting too.
<wasabi> I think a consistantly ordered .tar.gz seems to do a xdelta just fine.
<wasabi> And since .ar is just a container, I don't see why xdelta isn't good enough.
<ion_> I think mvo was developing the stuff i pulled from bzr.
<wasabi> apt-torrent is really neat though. That's a completely different angle however.
<pitti> I'll go offline for some minutes to test the current live CD on real HW; brb
<wasabi> ahh, take that back, xdelta does suck.
<persia> wasabi: It's partially an archive size issue - does one keep differences to the latest version, or for several previous versions?  Alternately, if can be an archive CPU issue, if differences are calculated at request time.
<wasabi> Weird because I got great results on one 
<wasabi> persia, how big is the full archive?
<elmo> 174Gb
<mvo> wasabi: zsync is working, try http://people.ubuntu.com/~mvo/bzr/apt-sync--mvo/ - but there is currently no archive hosting the .aptsync files
* persia is unsure - http://www.ubuntu.com/getubuntu/mirror suggests around 170GB.
<wasabi> 174GB is... nothing.
<wasabi> I mean, it was, 5 years ago.
<wasabi> But now a 500GB HD is $100.
<elmo> that's silly
<pygi> wasabi, yup, true
<wasabi> I have 8 sitting right here. Want a few? haha
* pygi wants one :p
<elmo> a 500GB HD for a server is not $100 and that doesn't take into account limitations like physical size, existing RAID setups, etc.
<pygi> elkbuntu, right, SCSI stuff =)
<ion_> persia: With zsync, the archives only need to have the latest versions of the packages.
<wasabi> Hmm. I built my high storage raid out of SATA
<wasabi> SCSI for performance. High storage out of SATA.
<wasabi> Works great.
<elmo> good for you - mirrors, rather sensibly, don't
<wasabi> Drives die more, but they cost 4th as much.
<elkbuntu> pygi, eh?
<pygi> elkbuntu, ups, sorry :)
<elmo> you're also assuming that these mirrors are only mirroring ubuntu, which 90% of the time, they're not
<wasabi> That is true. You are considering the mirrors themselves.
<wasabi> I forget the distribution network of mirrors that are involved. It's not just one server.
<wasabi> And you don't own or control most of them.
<elmo> we don't own 99.99% of them
<elmo> and Ubuntu is entirely reliant on it's network of mirrors to get the software to it's users - not even Canonical could support the bandwidth required to support all Ubuntu users without mirrors
<wasabi> Well, it'd be an interesting experiment, maybe to set up the diff infrastructure, get a server going, and see what the real conditions are.
<persia> ion_: Nifty.  Thanks for the pointer.
<wasabi> There's no doubt I alone am responsible for many gigs of needless transfer from the mirrso.
<wasabi> Since I update gutsy daily.
<ion_> Well, i dont consider it needless, since you probably report and fix bugs just like most of us who upgrade gutsy periodically.
<wasabi> I mean in terms of actual changes I'm downloading.
<ion_> (Or did you mean needless transfer as the amount of data transfered would be lot less if apt-sync were used?)
<wasabi> It's not often more than a single line of code changed and an entry to changelog.
<wasabi> And boom, 30MB firefox download.
<ion_> Yeah
<ion_> Indeed.
<cjwatson> not to take away your hyperbole, but:
<cjwatson> Package: firefox
<cjwatson> Size: 10277218
<cjwatson> I think a factor-3 overstatement is a bit much ;)
<ion_> :-)
<wasabi> firefox-dbg.
<wasabi> Size: 49845600
<wasabi> Probably my fault for having debug symbols, but still.
<bryce> ok, this xorg tester needs to make sure he's ctrl-alt-bksp'ing on the right test machine.... doh
<wasabi> I last updated two days ago. apt tells me I need to download 214MB of archives.
<wasabi> Hmm. 4 days ago.
<wasabi> Still. That's just me.
<cjwatson> I think in some ways Ubuntu is more liable to this than Debian
<cjwatson> because we work more across the distribution than package-at-a-time, you get more smaller uploads
<wasabi> Yeah.
<cjwatson> smaller as in fewer-changes
<cjwatson> also due to tighter schedules and faster archive cycles
* Hobbsee sighs at the debian/ubuntu hatred.
<pitti> mvo: darn, the amd64 live just hangs for me when starting the desktop session
<cjwatson> Hobbsee: hmm? that was an objective comment, no hatred implied
<Hobbsee> cjwatson: no, not here, sorry.
<cjwatson> ah
<pitti> mvo: and I cannot tell why, switching consoles works, but I cannot run any command
<Riddell> PriceChild: has anyone spoken to you about gizmod licencing?
<mvo> pitti: could you please try to edit /usr/share/compizconfig/globals.xml and search for "expo" and disable the "autoenable" bit?
<ion_> Hehe, Remove bigiron target, see if anyone complains
<mvo> pitti: what do you see  ? only a colored background? or a desktop with icons etc?
<pitti> mvo: when? on the live CD?
<pitti> mvo: color background, white stripes where the panels will go, and a mouse pointer
<wasabi> Has anybody actually taken a look and come up with any figure about how much actual real data changes in the distro on a weekly or other basis?
<wasabi> If optimal diffs were in place, etc.
<mvo> pitti: go to the console on the live-cd, edit the file and kill gdm and start it again. I wonder if that helps
<pitti> mvo: well, but as I said, I cannot run any commands; they just hang
<mvo> pitti: I have seen that here on my regular session too and I *think* its releated to the expo plugin
<pitti> mvo: I probably need to be very quick or so
<pitti> mvo: just for planning and having a fallback: what would we need to do to entirely disable compiz-by-default for tribe-2?
<mvo> pitti: oh, yes. I had that before and was suspecting a bad burn :/
<mvo> pitti: revert the last gnome-session upload should be enough
<pitti> mvo: ok; I think we should do this tonight when everything else fails, so that we have testable CDs tomorrow
<mvo> unfortunately we have quite a few problems currently
<pitti> mvo: ok, I'll try to disable the expo plugin before it hangs X; bbl
<seb128> pitti: you are the only one to have an hanging CD atm though, no?
<pitti> mvo: ^ didn't you have that, too?
<pitti> <mvo> pitti: oh, yes. I had that before and was suspecting a bad burn :/
<mvo> yes, I had that
<mvo> no commands
<seb128> "had"
<seb128> is it fixed now?
<mvo> and I had a hang on login but commands worked fine
<mvo> no
<mvo> I suspected a bad burn
<mvo> but no commands anymore sounds a bit like a kernel issue IMO
<seb128> right
<pitti> mvo: yeah, probably some 'X driver goes crazy blocks everything else'
<zul> w/in 12
<pitti> mvo: ok, trying; brb
<ogra> yay, mksquashfs seems to work in d-i mode :)
* ogra dances
<ogra> even the percentage output looks horrible in the syslog output
<ogra> pkl_, is there any way to quiten that ? ^^^^
<pkl_> yes, add the -no-progress option to mksquashfs.
<ogra> ah, cool, thanks 
<ogra> i'll add that in the next ltsp upload
<ogra> squashfs via nbd is a really cool thing :)
<cjwatson> or process the progress output somehow into debconf progress commands
<cjwatson> I don't know if there's a version of the output that's sufficiently machine-readable to allow that
<pkl_> ogra: yes, I'm interested in what the performance is like over nbd.
<ogra> a lot better than plain uncompressed nfs indeed
<ogra> but i dotn have numbers yet
<ogra> i'll make up some comparisons for the release notes for ltsp 
<pkl_> ogra: nbd appears to be more reliable than Squashfs loopback mounted on an exported NFS filesystem.  I've noticed some issues where loopback appears to timeout getting backs off NFS.
<pkl_> s/backs/blocks/
<ogra> well, i cant tell, since we need a unionfs on top which just breaks over nfs
<pkl_> even Squashfs loopback mounted on a file, which is in an NFS mounted filesystem?
<ogra> hmm, never tried that
<ion_> Hehe, i got ten separate sorry, foo closed unexpectedly reports for old crashes from apport. compiz, beryl, zsh-beta, xfce-terminal, firefox, f-spot and some others. :-)
<pkl_> ogra:  I wouldn't, that's where I've read about the above issues.
<ogra> sh
<ogra> err
<ogra> ah
<ogra> well, i'm happy as it is now ... :) its the fastes ltsp ever :)
<pkl_> ogra: do you use the readahead module in ltsp?
<ogra> nope
<wasabi> I seriously doubt I'm supposed to see this:
<wasabi> New Advanced Linux Sound Architecture (ALSA) configuration presets have been added.  Please execute the asoundconf(1) set-default-card macro in a Terminal now to refresh your user's configuration presets.
<cjwatson> mvo commented on that earlier too
<wasabi> Doesn't somebody have to go out of their way to add messages to that?
<pkl_> ogra: OK.  Just thinking about ways to reduce network latency on start-up.  The liveCD uses the readahead module, but it probably doesn't do much for network latency.
<ogra> afaik the liveCD disables readahead
<ion_> - user-must-execute-asoundconf-set-default-card.update-notifier: Add this update-notifier hook so that the user is informed that he/she needs to execute the asoundconf(1) set-default-card macro, because new ALSA configuration presets have been added (LP: #120691).
<ion_> It would be nice if ubugtu reacted to that format, too. Please give the URL for bug #120691 for the lazy ones among us, thank you.
<ubotu> Launchpad bug 120691 in alsa-lib "heaps of ALSA warnings in console" [Medium,Fix released]  https://launchpad.net/bugs/120691
<ion_> Oh, it was ubotu. :-)
<cjwatson> wasabi: if by "out of their way" you mean "run echo in a postinst", I suppose so
<pitti> mvo: ok, the reason for the hang was simply that the live CD tried to start compiz for me
<pkl_> ogra: hmm, really? I thought the readahead module was added to read the initial list of files off CD-ROM into page cache.  Maybe it is disabled due to RAM limits... 
<pitti> mvo: after disabling the kernel maps protection, it worked; I got metacity and a working desktop
<ogra> pkl_, i think we had kernel oopses with that in the past
<pitti> mvo: that's fine, nv is known not to work with composite
<mvo> pitti: ok, good to hear. I'm preparing a new compiz upload
<pitti> seb128: live system detects 68 DPI for me, which is why fonts are so tiny
<pitti> seb128: after I manually set it to 86, fonts looked fine again
<mvo> pitti: can I get the output of glxinfo from a "nv" system on some pastebin please?
<pitti> seb128: so DPI detection still seems to be broken at times
<ogra> ogra@laptop:~/packages/casper-1.91$ grep readahead scripts/casper-bottom/25configure_init
<mvo> pitti: and can you please accept my current gnome-session upload?
<ogra> # Disable readahead since it doesn't play well with squashfs + unionfs
<ogra> if [ -e /root/sbin/readahead-list ] ; then
<ogra>     chmod -x /root/sbin/readahead-list
<ogra> pkl_, ^^^^
<pitti> mvo: I can, I need to restart X for that again; do you need nvidia as well?
<pitti> mvo: what does it do?
<mvo> pitti: for now only nv
<mvo> pitti: it fixes the way compiz is called and unbreaks runing the session in vmware
<pkl_> ogra: OK.  I was thinking about adding some readahead support in Squashfs.  This should work a lot better than the readhead module, and should also be good for ltsp.
<pitti> ah, yay
<cjwatson> wasabi: it's only hard if you're also using debconf (but even then echoing to stderr would do the job)
<ogra> pitti, apart from oversizedness and 20min unresponsiveness the edubuntu i386 server CD installs fine
<ogra> pkl_, sounds great :)
<pitti> mvo: ok, accepted; I wait with the next publisher run until ubiquity and network-manager finished building (shouldn't take long)
<pitti> ogra: cool
<pkl_> ogra: Good :)  If/when I finish it (it's one of my TODO things, I'll ask you about doing some tests on ltsp....
<mvo> pitti: I will most likely need at least one other upload to fix the compiz wrapper
<pitti> seb128: so, it seems that bug 118745 is still an issue; do you get a similar effect on the live system?
<ubotu> Launchpad bug 118745 in libgnome "default desktop/panel menu font sizes too small" [Medium,In progress]  https://launchpad.net/bugs/118745
<pitti> mvo: yeah, for fixing the running driver detection?
<pitti> mvo: what will you use, grepping the Xorg.0.log?
<evand> pitti: tested ubiquity 1.5.4 installs for kubuntu and ubuntu, both worked.
<ogra> pkl_, appreciated, thanks :)
<wasabi> cjwatson, translations are not considered?
<pkl_> ogra: np
<pitti> evand: yay
<mvo> pitti: yes, will grep the Xorg.$nr.log file
<bryce> mvo, will you be doing greps foreach video driver?  The Xorg.0.log does not appear to specifically highlight "this is the video driver" apart from other drivers
<cjwatson> wasabi: no
<ogra> hmm
<mvo> bryce: but it will not load e.g. vesa and radeon at the same time, right?
<ogra> the NM applet looks weird here
<ogra> its flashing
<cjwatson> wasabi: not typically, anyway. One or two maintainer scripts might bother to use the gettext shell command but it's not been common practice. Maintainer scripts that need translated messages typically use debconf nowadays.
<ogra> ah, if i click on manual configuration it suddenly does autoconfig ...
<bryce> mvo, right
<bryce> mvo, btw I wrote a perl script to parse the xorg.0.log to extract driver and other info.  I don't know if you care to do it in perl, but I'd be happy to share if so.
<mvo> bryce: perl is not exactly my favorite language, but if you make it part of the xorg packages somehow (and if you also use "xset q" to find out what logfile is current used) and I will be a happy user of it
<bryce> okie doke
<pitti> bryce: would it be very hard to invent a new xset call that reads the current video driver directly from X?
<pitti> bryce: especially with multiple running X servers it's a pain to figure out the corresponding log file etc.
<bryce> pitti: it's on my todo list to look into, but I don't know at this point
* bryce nods
<pitti> bryce: right, I just mean, wouldn't this make more sense in the long term?
<bryce> yes, the grep-driver-from-log approach seems very hackish to me.  But if we need something right now, and can't use maps, then it doesn't give many options
<pitti> right, I fully agree about a quick tribe-2 solution
<mvo> I think I have something that is good enough(tm) in the compiz wrapper script for now (hackish but ...)
<pitti> mvo: erk, I launched the publisher 10 seconds ago :)
<mvo> if someone could post a glxinfo output from the "nv" driver to a pastebin, that would be appreciated
<mvo> pitti: no problem I have some other tasks on my list
<mvo> like why the splash screen keeps staying on top etc
<pitti> mvo: right, I'll do that now; we have 35 minutes now, no reason to upload earlier
<bryce> pitti: I did this xlogparser script primarily for xorg testing purposes, so I can automate verification of drivers loaded, check their versions, etc.
<mvo> bryce: is it available somewhere to look at?
<ogra> oh crap
<ogra> mksquashfs compresses the mounted CD inside teh chroot eeek ...
<bryce> mvo, one sec
<bryce> http://people.ubuntu.com/~bryce/scripts/xlogparse - note the docs aren't finished yet
<mvo> bryce: thanks!
* mvo looks and tries to remember some perl
<bryce> you run it like "xlogparse /var/log/Xorg.0.log [--modules|--driver|--summary] "
<bryce> er, you run it like "xlogparse /var/log/Xorg.0.log [--modules|--drivers|--summary] "
<ogra> mrrm ...
<pitti> mvo: http://people.ubuntu.com/~pitti/tmp/
<pitti> mvo: glxinfo.nvidia.txt and glxinfo.nv.txt  
<pitti> seb128: so, I'm really unsure again about bug 118745; is a wrong DPI detection X' fault?
<ubotu> Launchpad bug 118745 in libgnome "default desktop/panel menu font sizes too small" [Medium,In progress]  https://launchpad.net/bugs/118745
<mvo> pitti: great, thanks!
<pygi> cypherbios, poke
<cypherbios> hi pygi
<pygi> cypherbios, I see you haven't updated your site for 0.2 yet :)
<pygi> (the sf one ^_^)
<pygi> cypherbios, but I rather wanted to talk about the way how you record packages to cd/dvd
<cypherbios> pygi: It isn't released yet
<cypherbios> pygi: sure. shoot
<pygi> cypherbios, you use wodim/growisofs right now, true?
<cypherbios> pygi: actually mkisofs/genisofs to create the iso image
<cypherbios> *genisoimage
<pygi> cypherbios, right, and what about burning?
<pitti> kylem: what's the status of those two discover-data tribe-2 bugs?
<kylem> ?
<cypherbios> pygi: aptoncd dont burn the image, gust call the preferred application to do so
<pitti> kylem: bug 119362 and bug 119370
<ubotu> Launchpad bug 119362 in discover-data "Unknown Intel graphics controller on Intel D63578-200 motherboard" [Undecided,New]  https://launchpad.net/bugs/119362
<ubotu> Launchpad bug 119370 in discover-data "Intel Xorg driver not detected when installing Gutsy Tribe-1 on an Intel GMCHB0ICHB0 motherboard" [Undecided,In progress]  https://launchpad.net/bugs/119370
<pygi> cypherbios, ok, got it
<kylem> sigh.
<cypherbios> pygi: it checks the available applications and them offer the user a combo to choose what he wants to use
<kylem> i need less to do.
<pygi> cypherbios, would you be interested in replacing mkisofs/genisofs?
<cypherbios> pygi: replacing by what?
<pygi> cypherbios, by a library called libisofs
<kylem> pitti, clearly i utterly failed at fixing this for tribe2. will upload today.
<cypherbios> pygi: I heard about.
<pygi> cypherbios, we would have to write bindings ... but there are a lot of benefits in the long term
<pitti> kylem: if they aren't crucial for some customer or important machines, then 'move off to tribe-3' is a valid answer :)
<kylem> yeah. that's fine.
<kylem> neither appear targetted at tribe2.
<pitti> kylem: I didn't milestone them, so someone must have had a reason
<cypherbios> pygi: benefits like what?
<pitti> the are
<pitti> Keybuk: s/the/they/
<kylem> whoever has a reason can hire me a minion. :)
<pygi> cypherbios, like active upstream and support, proper  handling of errors and such? ^_^
<pitti> kylem: ok, so tribe3?
<cypherbios> pygi: sounds like a good reason :)
<kylem> pitti, yeah.
<kylem> no sense delaying the tribe cd over it when they'll be another in 3 weeks.
<pygi> cypherbios, ^^
<cypherbios> pygi: does it has python bindings ?
<pygi> cypherbios, nop, not yet
<pitti> asac: are you the official n-m bitch^Wmaintainer now? do you think you can take on bug 90267? or rather not?
<ubotu> Launchpad bug 90267 in network-manager "network-manager stops and restarts already ifup'ed interfaces" [Critical,Confirmed]  https://launchpad.net/bugs/90267
<cypherbios> pygi: mkisofs works fine, I dont have any problems with it. But if you are telling me libisofs would work better...
<pygi> cypherbios, we'd have to work on those
<pitti> asac: I milestone this for tribe-3; this is one of the n-m bugs that suck and break most and should be relatively easy to fix
<pygi> cypherbios, right, I believe for operations you need it, it works fine
<asac> pitti: i am still a student for nm ... but yes :/
<pitti> asac: well, let's look into it together after tribe-2, shall we?
<pitti> asac: maybe two n-m amateurs can do something about it :)
<asac> pitti: sure ... would be a pleasure
<asac> pitti: your comment sounds professional though :)
<cypherbios> pygi: command = ['mkisofs','-iso-level', '4' ,'-pad', '-l','-r', '-J', '-joliet-long', '-v', '-V', 'APTonCD', '-hide-rr-moved', '-o', finalDestiny.replace(' ','\ '),  destination.replace(' ','\ ')] 
<asac> pitti: like you know exactly where to hook this in :)
<pitti> asac: well, I have an idea *what* do do, but not yet *where*
<pygi> cypherbios, right :)
<cypherbios> pygi: if libisofs is capable to do it and give me back the progress (%) is enough
<pitti> asac: right now, n-m starts off with shutting down everything and initializing all devices to 'down'
<pitti> asac: we have to make it use ifconfig (or an ioctl) to check whether an interface is up, and initialize its internal world model accordingly
<pygi> cypherbios, it should be able, but we'd have to check ofcourse
<asac> pitti: have you verified this in code?
<asac> pitti: or is it just something someone told you?
<asac> (at uds)
<pitti> asac: not in the code, but that's its obvious behaviour
<pygi> cypherbios, but hey, don't listen to me. If you really think this works, I'm fine with you using it.
<pitti> asac: hm, wasn't it me who proposed that? :)
<asac> pitti: no idea ... i have not been in the bof :)
<cypherbios> pygi: heheh, it's fine. actually we don't have reasons to do that, but if you want to test something I'd be glad to help you testing
<asac> pitti: what kind of hardware setup do i need to test all stuff ... i assume at least two network cards and a wifi stick, right?
<pitti> asac: an unencrypted and a wep/wpa network are very helpful, too
<Riddell> doko: I'm afraid I need to reject simdmath since it has no licence file
<pitti> asac: I have two eth (one dhcp, one static) and one unencrypted wifi here
<pitti> asac: i. e. desktop with two eth, laptop with one eth and one wifi
<cypherbios> pygi: you are behind brasero too, aren't you?
<Burgundavia> asac: if you want to test the NM crasher bug, you need a wifi connection with WPA/WEP and use gnome-keyring
<ScottK> Riddell: Would you have a moment to kick python-fam (1.1.1-2.1ubuntu1) out the door.  I just uploaded it for Gutsy.  Lack of it uploaded to Gutsy is currently blocking a Feisty SRU.
<asac> Burgundavia: huh?
<Riddell> ScottK: new source or binary?  in universe?
<pygi> cypherbios, I want to: a)get python bindings b)get people use them c)test and exterminate possible bugs :)
<pygi> cypherbios, kindof, but not really
<Burgundavia> asac: there is an NM crasher bug that kind of makes it useless currently, as the applet dies if it contacts gnome-keyring
<pygi> not a developer
<ScottK> Riddell: New source in universe.
<pygi> cypherbios, not a developer
<cypherbios> pygi: but a packager?
<asac> Burgundavia: version?
<pygi> cypherbios, yup
<cypherbios> pygi: :)
<pygi> cypherbios, I did however help here and there in the past
<pygi> past being like two years or so :P
<Burgundavia> asac: 0.6.5-0ubuntu2 (the last version before yours just went up)
<cypherbios> pygi: aptoncd offers the option to burn the iso using brasero (as well nautilus-cd-burner and k3b)
<pygi> cypherbios, libburnia is more important these days
<asac> Burgundavia: ok is there a bug?
<pygi> cypherbios, I have strong reasons to believe that genisoimage will completely stop it's development in the future (however there'll be a replacement, but developers will be advised to use libisofs)
<Burgundavia> yep, just a sec
<Riddell> ScottK: it's not in NEW, we already have python-fam in the archive
<Burgundavia> asac: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/121605
<ubotu> Launchpad bug 121605 in network-manager-applet "[gutsy]  segfault on joining secure network" [High,New]  
<ScottK> Riddell: Right, but I got a waiting approval message I assume because the archive (Main) is frozen for Tribe 2.
<doko> Riddell: please keep it in the queue
<doko> pitti: gcc-4.1 and gcc-4.2 uploaded
<asac> Burgundavia: can you get a reasonable backtrace?
<pygi> cypherbios, alive? :)
<Riddell> doko: what for?
<asac> Burgundavia: ok ... maybe the one attached is good enough
<cypherbios> pygi: sorry, was on the telephone
<pitti> bdmurray, Burgundavia, asac: hm, are bug 121654, bug 121605 and bug 121228 in fact all duplicates?
<ubotu> Launchpad bug 121654 in network-manager "[gutsy]  nm-applet core dumps" [Medium,Confirmed]  https://launchpad.net/bugs/121654
<ubotu> Launchpad bug 121605 in network-manager-applet "[gutsy]  segfault on joining secure network" [High,New]  https://launchpad.net/bugs/121605
<ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [Undecided,Confirmed]  https://launchpad.net/bugs/121228
<cjwatson> heno: would you update https://wiki.ubuntu.com/ReleaseValidationProcess to match the current ISO test tracker, please?
<cypherbios> pygi: mkisofs seems to be discontinued already
<bdmurray> pitti: it seems possible
<cypherbios> pygi: as it's just a link for genisoimage
<heno> cjwatson: will do
<bdmurray> bug 121228 didn't seem very "clean" to me
<ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [Undecided,Confirmed]  https://launchpad.net/bugs/121228
<pygi> cypherbios, mkisofs  is being developed, but not packaged anymore for debian distros (and most other)
<pygi> cypherbios, but as I said (read again :P) I was telling you about genisoimage :)
<Riddell> ScottK: done
<pitti> bdmurray: 121654 and 121228 have the very same workaround and characteristics at least
<Burgundavia> pitti: I would say so
<cypherbios> pygi: does libisofs has a binary to create a iso image already?
<asac> Burgundavia: are new packages already on archives?
<asac> Burgundavia: if so please test if crash still exists
<Burgundavia> asac: let me check
<pygi> cypherbios, just a tiny little test one
<Burgundavia> asac: not yet, afaics
<ScottK> Riddell: Thank you.
<pygi> cypherbios, well, I bugged too much already
<pygi> sorry :)
<cypherbios> pygi: what applications are using libisofs already?
<cypherbios> pygi: not at all
<pygi> cypherbios, just brasero and a I know of two that are being developed for some uni's 
<Burgundavia> pitti: it looks like 121228 has a good detailed description of the problem. I will mark stuff dupicate of that bug, if that works for you
<pitti> Burgundavia: it does, I'm already at it
<asac> Burgundavia: result=GNOME_KEYRING_RESULT_OK, found_list=0x0
<asac> --> crash
<asac> hmmm gnome keyring bug?
<Burgundavia> looks like it
<Burgundavia> 121228 reporter was using vanilla nm
<asac> or completely trashed process
<asac> bug 121228
<ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [High,Confirmed]  https://launchpad.net/bugs/121228
<pitti> Burgundavia: done
<asac> pitti: for me it looks like a gnome keyring bug
<asac> i mean it returns result OK ... but found_list = 0x0
<pitti> asac: well, but the attached patch with checking for NULL makes sense to me
<asac> why? ... i mean why RESULT_OK + found_list == 0x0
<pitti> asac: still a bug, of course
<asac> its a cure for the crash, but this should never happen
<pitti> asac: just defensiveness
<asac> hmmm ... better add an assertion then
<pygi> cypherbios, tbh I'd also wonder who was this guy, what he wants out of me ... and why does he want me to do a lot of work (i.e. writing bindings, testing, etc), using experimental tech and such stuff when this works just fine
<pygi> cypherbios, so I understand where you're coming from :P
<pitti> asac: can you please add a gnome-keyring task then?
<asac> yes ... we should get a trace that has symbolized gnome-keyring as well
<asac> maybe nm already sends stupid stuff in :)
<pitti> asac: heh, GIGO :)
<pitti> asac: we have apport in tribe-2 now, so that might help
<pygi> o no
<pygi> :P
<asac> pitti: then lets wait a till friday :)
<asac> pitti: we should have plenty of crashes then
<cypherbios> pygi: hehehe :)
<pitti> asac: and hope for the best wrt. automatic dup detection :)
<pitti> mvo: publisher is finished, so we can crank another run; what's the word in the compiz world?
<asac> pitti: good test :) ... any idea how we can keep this bug report still the MASTER?
<pitti> asac: hm, not without gross hacking
<cypherbios> pygi: I'll not touch in something that is working fine, but if it would improve in some way we can consider to think about ;)
<asac> maybe we can just upload a crash report from some dupe to it?
<pitti> asac: TBH it seems easier to transfer the relevant information to the first apport than to attach core dump, packaging info etc. to the current but
<pitti> s/t$/g/
<pygi> cypherbios, it would surely help you in the future
<pygi> so consider it an investment in the future
<asac> pitti: hmm ... ok ... maybe Burgundavia can attach a crash report to that bug?
<pitti> asac: you have to do manual attachments; LP currently doesn't allow us to augment an existing report with a blob
<asac> ah ok
<Burgundavia> asac: do I need a debug package of g-keyring?
<asac> then ... lets wait and migrate the info
<cypherbios> pygi: if libisofs has a python binding I probably would use it to replace mkisofs
<asac> Burgundavia: if you want to provide a better backtrace, then yes
<asac> install the dbgsym package
<pitti> asac: so, of course you can attach CoreDump.gz, Dependencies.txt etc. manually and fix the description to contain the other fields, but that's harder I think
<asac> pitti: agree.
<Burgundavia> ok, just a sec
<pitti> mvo: wb
<asac> pitti: do you still provide dbgsym packages for public?
<pygi> cypherbios, help me write those :)
<pitti> asac: of course
<pitti> mvo: publisher is finished, so we can crank another run; what's the word in the compiz world?
<Burgundavia> pitti: are those still on your people.u.c page?
<pitti> Burgundavia: yes, it hasn't ever changed
<cypherbios> pygi: I'd really appreciate but I don't think I can. actually I don't have enough time even to do my own stuffs
<alex-weej_> does anyone know if NATs have any way of communicating with local peers that the WAN connection is up?
<pygi> cypherbios, aha :)
<alex-weej_> NetworkManager's "online" notification is a little misleading in home NAT situations
<pitti> BenC: you (likely) milestoned bug 119052 for tribe-2; shall it be postponed for tribe3? or is there an existing fix?
<ubotu> Launchpad bug 119052 in initramfs-tools "[gutsy] ibm-acpi -> now thinkpad_acpi possibly causing problems" [High,Confirmed]  https://launchpad.net/bugs/119052
<Burgundavia> pitti: your dbgsym package for keyring is out of date
<ScottK> alex-weej_: No, you really can't do that with NAT.  NM is telling you your box is on the network.  There really isn't much else it can do.
<Burgundavia> asac: do you want me to wait for your latest package to hit the archives? I am still running the 0ubuntu2 stuff
<BenC> pitti: yeah
<pitti> Burgundavia: they should have been published by now
<alex-weej_> ScottK: OK, in that case I think applications should be programmed with this in mind. Too many Ubuntu apps are throwing a wobbler when you're "online" but you're not "on the Internet".
<pitti> BenC: 'yeah' for what? :)
<asac> Burgundavia: they are already build ... should not take that long till they get distributed
<Burgundavia> asac: just got them now
<BenC> pitti: bug 119052 -> tribe-3
<ubotu> Launchpad bug 119052 in initramfs-tools "[gutsy] ibm-acpi -> now thinkpad_acpi possibly causing problems" [High,Confirmed]  https://launchpad.net/bugs/119052
<pitti> BenC: 'k
<pitti> BenC: https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=469 has three kernel bugs left; are any of them fixed in -7?
<jdstrand> seb128: what do you think of the workaround patch for https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/27014 ?
<ubotu> Launchpad bug 27014 in evolution "evolution bug, "Summary and folder mismatch, even after a sync"" [High,Confirmed]  
<iwj> Hmm.  Is 1401563c85a6cf45a8464a1444e1b339 *gutsy-alternate-i386.iso  known not to work ?
<pitti> iwj: which timestamp is that? does it abourt with a mount /proc bug?
<iwj> Tue Jun 26 12:26:03 UTC 2007
<asac> Burgundavia: still see it?
<iwj> I don't think so.
<iwj> I'm just trying again paying better attention.
<pitti> iwj: hm, I installed the amd64 alternate, and it just failed to log into the session
<pitti> iwj: what is it for you?
<iwj> It got as far as letting me log in and then it presents that login progress screen.
<iwj> After that disappears I just get a blank beige backdrop.
<pitti> iwj: ah, that's again mvo's compiz magic; I *think* that's fixed with the new gnome-session
<BenC> pitti: closed 2, deferred 1
<mvo> iwj: that is real HW? or vmware?
<pitti> BenC: that's a good ratio :) cheers
<geser> BenC: Hi, any idea when bug #114855 will get fixed? I assume it won't make it for tribe-2.
<ubotu> Launchpad bug 114855 in linux-ubuntu-modules-2.6.22 "prism54 and other wlan drivers missing in kernel 2.6.22" [High,In progress]  https://launchpad.net/bugs/114855
<iwj> mvo: Real hardware.
<mvo> iwj: could you please go to a console and strace compiz.real ?
<iwj> SIGSEGV
<iwj> (run as me from a normal tty session, with the X thing still hung)
<pitti> asac: can you please have a quick look at bug 121439?
<ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Confirmed]  https://launchpad.net/bugs/121439
<Hobbsee> night all
<keescook> pitti: whoops, sorry, I knee-jerk uploaded some fixes for apparmor -- it can be ignored until after the freeze
<iwj> mvo: Yes, whatever I do it segfaults.
<pitti> keescook: no problem at all, it's universe
<pitti> keescook: also, it's never a problem to just upload stuff; I ignore the packages which don't look relevant
<mvo> iwj: can you please strace the runing (hanging one)?
<iwj> OIC
<iwj> All this VC switching has made X go strange.
* iwj reboots.  Dammit why can't you ever have only one bug at a time ?
<asac> pitti: its hard to say if this issue was caused by upstream upgrade or caused by dropp of patches. 
<pitti> asac: ok, so tribe3/needsinfo/tryagainwithlatestversion?
<asac> pitti: sure ... maybe its just gone
<pitti> asac: it looks a bit hw specific, since it should work in general, right?
<asac> pitti: for now we can just hope
<enrico> Riddell: I made it with the porting!
<enrico> Riddell: adept works without the old libtagcoll
<pitti> asac: I'll test again with the latest packages on my ibook (open wifi as well here), whether it's generally broken
<enrico> Riddell: apt-front uses libept for all the debtags things
<enrico> Riddell: so it uses the new index
<asac> pitti: thanks
<enrico> Riddell: it's *done*!
<enrico> Riddell: I'll now proceed to committing and uploading into Debina
<asac> do you have ipw driver?
<enrico> Debian, even
<asac> pitti: ^^`
<pitti> asac: no, bcm43xx
<enrico> pitti: according to backlog, the above might be interesting for you as well
<pitti> enrico: cool! so we'll merge/sync right after tribe2
* pitti hugs enrico 
<iwj> mvo: futex(0xb7d8d120, FUTEX_WAIT, 2, NULL ...
<mvo> iwj: could you please edit /usr/share/compizconfig/global.xml and go to "expo" and remove the "autoenabled" bit there? and see if that helps?
<mvo> iwj: then please run "gconftool --recursive-unset /apps/compiz " and you will have to reboot after that 
<mvo> pitti: new compiz uploaded, that should fix some more issues
<pitti> mvo: are there any known ones left that we must fix?
<iwj> mvo: deleted that autoenabled, killed the stuck compiz, C-A-B'd the X server, and logged in again and now it's fine.
<ogra> pitti, i'll need one fix for ltsp (just testing taht one) and one -meta upload for edubuntu (to drop one langpack)
<agoliveira> pitti: It starts X but freezes right after. I can't update becuse I was trying the live CD :)
<iwj> mvo: That gconftool rune produces a hideous warning from GLib about g_thread_init not being called early enough.
<mvo> pitti: nv detection was not good enough
<pitti> agoliveira: ok, sounds pretty much like the bug mvo is about to fix
<mvo> iwj: please reboot, just killing the xserver is not enough
<iwj> Doing so.
<mvo> and don't ask me why it is not, I have no idea
<iwj> That is, I'm doing the things you told me to do in the order you told me to do them.
<pitti> ogra: ok; publisher is still running ATM, so I'll wait some minutes to collect mvo's and your packages
<ogra> pitti, i have to test that first
<iwj> mvo: editing that file and restarting the X server was enough to make it WFM but I'm carrying on with your instructions.
<mvo> agoliveira: could you please do the same? reboot and see if that behaviour persists? if it does, removing the expo plugin from the autoenable list, reboot and see if that fixes it?
<ogra> pitti, its a bug with teh installer i'm waiting for it to finish, dont wait for me for that one
<mvo> agoliveira: details are some lines back in the buffer for iwj
<pitti> ogra: ok; right, it only affects the edubuntu CDs, it's not blocking the other ones
<mvo> iwj: right, that is what I meant. killing the session and login in again seems to cure the problem regardless what is done
<ogra> pitti, if you dropped ltsp it wont 
<pitti> ogra: shall I do an edubuntu-meta upload for you? did you already change the seeds?
<ogra> i didnt yet
<pitti> ogra: I didn't drop ltsp; you told me it was important and shiny and such
<ogra> i thought about dropping xhosa for now, that should give me the 1M i need
<iwj> mvo: OIC
<ogra> pitti, well, you dropped ldm, didnt you ? 
<pitti> ogra: no, you asked me not to
<pitti> ogra: Xhose gnome+kde+base is 670 kB
<ogra> pitti, i said drop it for tribe2 and i'll sort the theme stuff until tribe3
<pitti> ogra: we have the space now
<ogra> ok
<pitti> ogra: so dropping Xhosa might not be sufficient
<ogra> well, but since you dont use the installer part for ltsp in ubuntu i dont think thats to critical 
<mvo> iwj, agoliveira: I will do a quick dinner break now, but I will read scrollback
<iwj> mvo: OK
<iwj> mvo: Just logging in now ...
<iwj> mvo: ... Seems to work.
<mvo> iwj: ok, cool. thanks a lot for testing!
<Burgundavia> pitti: regarding retracing
<pitti> mvo: new git snapshot? did you review the changes?
<Burgundavia> pitti: I don't seem to be able to get a coredump
<Burgundavia> https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/122364
<ubotu> Launchpad bug 122364 in network-manager-applet "nm-applet crashed with SIGSEGV" [Undecided,New]  
<pitti> Burgundavia: do you run kernel -7?
<pitti> Burgundavia: -6 is broken with apport
<Burgundavia> nope
<asac> maybe the coredump has been embargoed?
<Burgundavia> could be
<pitti> asac: that's not possible with attachments
<iwj> mvo: NP, thanks for fixing it for me :-).
<asac> interesting ... Burgundavia you looked at the crash file right?
<Burgundavia> I did
<asac> there was a CoreDump: field, right?
<Burgundavia> there is
<iwj> Now I should report (a) the X server and (b) compiz.real SIGSEGV.
<pitti> Burgundavia: Linux corey-laptop 2.6.22-6-generic
<pitti> Burgundavia: please upgrade to kerenl 2.6.22-7 and try again
<Burgundavia> ahh, right, ok
<pitti> Burgundavia: you can reject this bug, it's pretty useless
<asac> Burgundavia: reboot i reject :)
<Burgundavia> just got to pull down the latest kernel
<pitti> Burgundavia: it says 'CoreDump:' which means it is zero byte
<agoliveira> mvo: I tried other times and the freezes is random tough it just appears after X starts. I'm checking the backlog while trying to boot in safe mode to see what happens.
<pitti> Burgundavia: thanks, sorry for the trouble
<Burgundavia> no worries
<Burgundavia> now we hope NM doesn't spontaneously fail halfway through my download
<seb128> jdstrand: I don't know the evolution code good enough to have an opinion
<ogra> pitti, i'll drop Czech then :)
<ogra> -cs seems to be big enough to gain soemthing
<jdstrand> seb128: well, frankly neither do I, but all it does is comment out a line when evo starts up to keep it from getting mail on startup
<ddaa> Hello
<pitti> ogra: 4.82 MB
<pitti> ogra: (gnome+kde)
<ddaa> Can someone please triage https://bugs.launchpad.net/ubuntu/+source/neon26/+bug/96700
<ogra> yeah
<ubotu> Launchpad bug 96700 in neon26 "neon-config --la-file points to non-existent file" [Undecided,New]  
<jdstrand> seb128: I have been using it for months with no problems, and have re-compiled evo for my users since then.  Works well.
<ddaa> reported on March 27th and confirmed by two independent users since then.
<jdstrand> seb128: it is not a fix-- but will be good enough for end users until upstream fixes it (won't be in the next release)
<agoliveira> Gahhh... rebooting the live cd gives me a core dump.
<jdstrand> seb128: it will of course get mail automatically after however many minutes the user specified, it just doesn't do it on startup.
<geser> shawarma: pbuilder build-depends on rootstrap which isn't in Ubuntu.
<pitti> asac: current n-m works good enough on my laptop (with the usual warts we have for ages)
<shawarma> geser: hard b-d?
<asac> pitti: good
<shawarma> geser: Or conditional? (I'm to lazy to check)
<shawarma> :p
<pitti> asac: ok, I mangled bug 121439
<ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Incomplete]  https://launchpad.net/bugs/121439
<geser> shawarma: only for i386 and amd64
<shawarma> geser: Oh, those.
<geser> shawarma: but i386 builds also all packages so there is no build of the last version
<geser> shawarma: pbuilder-uml needs it
<shawarma> geser: I wonder why... It sounds more like a runtime dep..
<asac> pitti: thanks
<jdstrand> seb128: I would propose it go into dapper-updates too-- maybe I am too close to the bug to have perspective, but it is extrememly annoying and many are turning away from evo, from what I can tell.
<geser> shawarma: there are two bugs about it: bug #122340 and bug #106949
<ubotu> Launchpad bug 122340 in pbuilder "[gutsy]  pbuilder (0.169ubuntu1) b-depends on virtual package rootstrap" [Undecided,New]  https://launchpad.net/bugs/122340
<ubotu> Launchpad bug 106949 in pbuilder "pbuilder-uml (0.161ubuntu2) depends on rootstrap(>= 0.3.9-1) and user-mode-linux which are notr installable in feisty" [Undecided,Confirmed]  https://launchpad.net/bugs/106949
<jdstrand> seb128: the patch I attached in launchpad can be dropped into debian/patches on dapper (probably others too)
<shawarma> geser: Hmm... I wonder why I didn't get a mail about it not building properly..
<geser> it's in dep-wait
<geser> you get no mail for dep-wait (even if it sits there for months)
<shawarma> We're supposed to notice that on our own? Evil.
<agoliveira> mvo: Just to update, rebooting does not do any good, it still freezes at random times, aways after X starts so it looks very much like what you told me before. Can't do anything on it tough as I'm running the live CD and, despite I'm able to switch to a console, any command I do just freezes.
<pitti> keescook: btw, I just noticed that firefox forgot all but one of my stock replies again
<keescook> pitti: I wish I could reproduce this!
<pitti> agoliveira: there's something
<shawarma> geser: I'll look into it soon-ish.
<ogra> meh, why does my germinate break on -meta updates :/
<geser> pitti: do you know if there is a notification if packages are sitting for a long time in dep-wait?
<ogra> oh, its outdated
<shawarma> pitti: Can we have rootstrap pulled in from Debian, please?
<pitti> agoliveira: while the live CD boots, switch to VT2 and wait until you get a login; then execute 'sudo killall gdm' repeatedly until you actually kill it
<keescook> pitti: is there anything special about your .mozilla directory or your firefox extensions?
<pitti> geser: you should get an FTBFS mail, don't you?
<keescook> pitti: neither bdmurray nor I have seen this :(
<pitti> agoliveira: then you can modify your system and manually start gdm again with sudo /etc/init.d/gdm restart
<geser> pitti: also for packages which are in dep-wait?
<pitti> keescook: I have some other scripts, maybe they fight each other or so
<pitti> geser: I'm not sure
<agoliveira> pitti: Anything I try to esxecute just does nothing, the console just stops responding too.
<pitti> agoliveira: right, but that only happens after gdm started up
<shawarma> pitti: I expect it's on the sync blacklist because it depends on user-mode-linux which used to be in the blacklist as well..
<pitti> agoliveira: that's why you have to immediately kill it
<cjwatson> ogra: you need germinate 0.28 and you need to add 'required' to the seeds: line in update.cfg
<agoliveira> pitti: Oh, ok. Got it. Let me try.
<shawarma> Aw, heck.. Uml is in universe.
<cjwatson> ogra: I can fix it up for you now if you like; I have another change to make anyway
<pitti> shawarma: can you please mail me about it?
<shawarma> pitti: Sure.
<pitti> shawarma: sure, it would land in universe
<ogra> cjwatson, yes please
<geser> shawarma: you would need to get rootstrap in main as it is a b-d of pbuilder (main)
<shawarma> pitti: Right, I just want it to fulfill a pbuilder b-d, but that's not going to fly..
<shawarma> geser: Precisely. Hence my "aw, heck" :)
<Burgundavia> pitti: alright got a core dump. Can I just cut it out of the crash report and attach it to 121228 and tag it for retracing?
<pitti> Bur...
<shawarma> *G*
<pitti> Burgundavia: just file the bug as it is, it'll get autoretraced and everything
<pitti> Burgundavia: cutting the core dump alone is not sufficient
<Burgundavia> pitti: alright got a core dump. Can I just cut it out of the crash report and attach it to 121228 and tag it for retracing?
<Burgundavia> pitti: or is there a way to tell apport to send a specific report?
<Burgundavia> ok
<Burgundavia> the apport auto thingy has not yet triggered, so I wondered if I could run it manually
<pitti> Burgundavia: no, unfortunately Malone doesn't (yet?) allow us to send additional info to an existing bug
<pitti> Burgundavia: oh, right, I need to enable it again, sorry
* pitti does
<asac> 
<Burgundavia> sorry, lost anything you said
<asac> pitti: ok for single eth card dhcp network manager works
<Burgundavia> bloody NM is dying on me now
<pitti> <pitti> Burgundavia: no, unfortunately Malone doesn't (yet?) allow us to send additional info to an existing bug
<pitti> <pitti> Burgundavia: oh, right, I need to enable it again, sorry
<pitti> * pitti does
<pitti> Burgundavia: ^
<asac> however desktop effects prevents me from resizing any window :)
<Burgundavia> pitti: ok
* pitti summons mvo
<Burgundavia> pitti: can I just send you the crash file? are you able to deal with it?
<pitti> Burgundavia: it's in a bug now?
<pitti> Burgundavia: just tell me the number, I'll supervise the auto-retracer
<Burgundavia> I can file a bug and attach the raw, unbroken out crash report
<geser> shawarma: looks like you have only the option do disable the pbuilder-uml package so you can remove the rootstrap b-d
* pitti just noticed that the retracer chroots fail to auto-upgrade and does it manually
<pitti> Burgundavia: no, please don't, they are a pain; why not just let apport file the crash?
<asac> pitti: look bug 122350 ... it has been filed with -7 but still has not core
<ubotu> Launchpad bug 122350 in firefox "firefox-bin crashed with SIGSEGV" [Undecided,Incomplete]  https://launchpad.net/bugs/122350
<pitti> asac: hm, weird; it works again with -7 here on my two machines
<ogra> gar gar gar
<asac> pitti: interesting ... maybe his system is messy because apport hook data from firefox is missing as well.
<agoliveira> pitti: Well, done what you said. I was able to start gdm and everything seens to be working but the installer. It crashes badly. I already sent the automated crash report. Perhaps you wanted anything else?
<Burgundavia> pitti: ok, finally got apport to cooperate
<pitti> agoliveira: oh, so you worked around the X hang (compiz bug)?
<agoliveira> pitti: Yes, diasbling the expo plugin seens to do the trick.
<pitti> agoliveira: installer is evand's area
<pitti> mvo: <agoliveira> pitti: Yes, diasbling the expo plugin seens to do the trick. -> did you already fix that?
<agoliveira> pitti: Ok, let me poke him ;)
<pitti> agoliveira: hm, the currently pending compiz upload doesn't disable it, but it might be in a different package
<pitti> agoliveira: I guess we have to wait until he gets back from dinner
<Burgundavia> pitti, asac: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/122385
<ubotu> Launchpad bug 122385 in network-manager-applet "nm-applet crashed with SIGSEGV in nmi_dbus_get_network_key_callback()" [Undecided,New]  
<pitti> speaking of that, I could use some dinner, too; I skipped breakfast and lunch already
<Amaranth> agoliveira: what was the problem?
<agoliveira> pitti: Go for it.
<Burgundavia> pitti: I have to run, can you make certain that is what you need?
<Amaranth> expo is one of the major features we want compiz for :)
<pitti> Burgundavia: retracer will get to it soon, I'll check it
<Burgundavia> ok, rocking
<agoliveira> Amaranth: I was testing Tribe 2 in my macbook. Expo freezes the live cd badly. After disabling it I was able to make it run nicelly except for the installing that's crashing all the way.
<agoliveira> Right now I have it running and all the programs I tested - but installer - worked fine.
<pitti> agoliveira: wrt installer
<Amaranth> does the installer work if you disable compiz? :)
<asac> Burgundavia: when you see retracer results, ping me please
<pitti> agoliveira: can you please dist-upgrade ubiquity on the live CD and try again?
<mvo> pitti: no, I wanted to be sure that this is actually the reason first I prepare a upload now
<Burgundavia> asac: will the retracer email me?
<Amaranth> Burgundavia: yes
<pitti> Burgundavia: yes
<asac> Burgundavia: should be a bugmail
<Burgundavia> wow, so many people so sure :)
* Amaranth was first
<shawarma> geser: /Win 5
<pitti> Burgundavia: retracer is grinding through a pretty large backlog
<cjwatson> agoliveira: what pitti said; the most recent version fixes a commonly-occurring crash
<Burgundavia> been using Ubuntu so long, I am not used to these new-fangled "au-to-mated" things
<shawarma> geser: um.. no.
<mvo> agoliveira: so after rebooting the expo plugin you managed to reboot/login a couple of times without hangs? 
<Amaranth> mvo: should have my computer fixed in about a week, then i can go back to helping make compiz rock :)
<pitti> mvo: reboot> bad on a live CD :)
<mvo> pitti: good point .)
<agoliveira> Amaranth: No, it does not work at all. I'll try to dist-upgrade as sugegsted.
<pitti> mvo: I kept hammering 'sudo killall gdm' like mad on VT2 while booting, that works
<Amaranth> pitti: why not just stop the gdm service?
<pitti> Burgundavia: yay, it's getting to it
<Amaranth> or does it freeze when X loads?
<pitti> Amaranth: because it will start in the init sequence
<Amaranth> if it does, i fail to see how anything in compiz is responsible :)
<Amaranth> oh, right, auto-login
<pitti> Amaranth: gdm is not the problem, but live system has autologin and thus autocompiz
<agoliveira> agoliveira: No, I just did it once. Didn't enable the plugin again.
<pitti> asac, Burgundavia: retrace is there
<asac> pitti: bon appetit now
<asac> pitti: hurry
<asac> :)
* pitti runs like hell
<Amaranth> apport's dupe checker doesn't seem to work very well with python
<pitti> Amaranth: hm, I just saw one case where it worked
<pitti> Amaranth: if it doesn't, plesae file a bug against apport
<sladen> pitti: surely just letting all the autodetection fail and then capping the result between two bounds (eg. 96dpi and 200dpi) for sanity checking would do it
<pitti> Amaranth: NB that it only works for bugs which have been filed *after* June 22(ish)
<Burgundavia> asac: that what you need for a traceback?
<Amaranth> pitti: well, bug 122311 is pretty obviously a dupe of bug 84060
<ubotu> Launchpad bug 122311 in alacarte "alacarte crashed with AttributeError in __getPath()" [Undecided,New]  https://launchpad.net/bugs/122311
<ubotu> Launchpad bug 84060 in alacarte "[apport]  alacarte crashed with AttributeError in __getPath()" [Low,Confirmed]  https://launchpad.net/bugs/84060
<asac> Burgundavia: unfortunately it appears to be completely asynchronous ... so we don't see how network-manager invoked keyring
<Amaranth> or do both bugs need to be newer than june 22?
<pitti> Amaranth: 84060 was filed too early
<pitti> Amaranth: right
<pitti> Amaranth: the first new bug initializes the dup database, the next one will match then
<Amaranth> lame, all alacarte bugs filed are going to be dupes of older bugs
<Burgundavia> asac: ugh. I am going to be gone for a few hours, but if you want me to get a trace off anything else, fire me an email
<pitti> Amaranth: I cannot search the entire Malone every time, I have to use a local db
<asac> Burgundavia: can you merge this bug to the original bug please
<Amaranth> you couldn't search entire malone once? :)
<asac> Burgundavia: and drop hint that there is a retrace in the bug XXXX
<Burgundavia> will do
<Amaranth> i mean, to create your index
<asac> Burgundavia: gratias
<pitti> Amaranth: that would take ages
<pitti> Amaranth: I can still do it, but I didn't yet
<evand> agoliveira: let me know if dist-upgrading doesn't fix the installer crashing.
<agoliveira> evand: actually a dist-upgrading just froze the machine :(
<pitti> asac: we should keep bug 122385 unduped (will become the apport master bug for this) and just link it to #121228 with a comment; or transfer the useful info from 121288 to the new one; what do you prefer?
<ubotu> Launchpad bug 122385 in network-manager-applet "nm-applet crashed with SIGSEGV in nmi_dbus_get_network_key_callback()" [Undecided,New]  https://launchpad.net/bugs/122385
<evand> agoliveira: it should be suitible to just apt-get install ubiquity
<pitti> evand: not ubiquity-frontend-gtk?
<asac> pitti: right ... i will add that info for now
<pitti> evand: wasn't it a fix in some GTK buttons, after all?
<agoliveira> evand: Yeah, something like that just stroke me...
<agoliveira> I'll start over.
<Burgundavia> asac: done and I left a note on the other 4 sigsev nm bugs asking them if they are using g-keyring and wpa/wep to see if it is the same crash
<evand> pitti: good point
* pitti runs for dinner for real now
<thom> fnar, apt's source makes me cry
<shawarma> ubiquity fails to start in my amd64 vmware on today's daily livecd.. Known issue?
<pitti> shawarma: please try apt-get install ubiquity-frontend-gtk and try again
<shawarma> pitti: Go to dinner!
<cjwatson> pitti: 'apt-get install ubiquity' forces newer versions of everything; you don't want them getting out of sync anyway
<shawarma> cjwatson: noted.
<cjwatson> the virtual dependencies on ubiquity-frontend-1.5.4 etc. should mean picking any one of the binaries is equivalent, though
<agoliveira> evand, pitti: Ok, if,  in sequence, I kill gdm after compiz kicks in, just upgrade ubiquity-frontend-gtk and start gdm, it works. I'll try to install now and may God have mercy on my soul ;)
<agoliveira> s/after/before
<evand> agoliveira: best of luck
<mvo> agoliveira: do you still have the session with the hanging compiz? one of the upstream guys is interessted in the strace and I can currently not reproduce it for some reason
<freepenguin> hello everybody
<agoliveira> mvo: If I boot the live CD it hangs. Disabling expo plugin it works. I just can't install now because the manual partition hangs as well :-(
<mvo> agoliveira: I see :/
<robertj> shawarma: can you take a look at https://bugs.launchpad.net/ubuntu/+source/pam/+bug/116846 ?
<ubotu> Launchpad bug 116846 in pam "patch to add directory inclusion for pam config file" [Undecided,New]  
<seb128> jdstrand: not that many users get this bug, I didn't get it here in months (years?) of evolution use 
<seb128> jdstrand: I'm not going to do a stable upload with a workaround, it's either a real fix or no change, if you can trigger the bug easily the best is to try to work with upstream which doesn't know how to trigger it
<shawarma> robertj: I'm aware. I discussed it with pitti already. We decided to postpone it until we've had a wider discussion of it.
<shawarma> robertj: The attendance of the bof at uds was.. not very impressive :)
<robertj> later = post-gutsy?
<jdstrand> seb128: I have submitted all this to upstream, and they claim to be working on a proper fix, but it won't be for a while (can't remember the url offhand).
<seb128> jdstrand: I'm subscribed to the bug, I'm reading comments there
<cjwatson> I talked briefly with vorlon at debconf about PAM maintenance
<seb128> jdstrand: it's not easy for them to work on because they don't get the bug apparently and nobody determined what to do to trigger it
<jdstrand> seb128: it happens with a lot of mail on a slowish drive (eg laptop)-- if the download of email completes before the indexes-- boom.
<cjwatson> he basically said "I've got plenty of offers of help, but ultimately I need to sit down for a couple of days and go through both all the scary Debian patches and all the scary upstream changes"
<evand> agoliveira: manual partitioning isn't working for you?
<jdstrand> seb128: right. well, thought I'd go to you to see if you want to include it-- guess I'll keep my own evo packages for my users...
<seb128> jdstrand: I would rather not use a workaround
<robertj> cjwatson: so does the spec need to be retargeted?
<jdstrand> seb128: I understand.  It actually was based on the default evo 1.4 behavior, which was how I found the workaround in the first place.
<agoliveira> evand: No. It freezes when I select the partition I want to use as /
<jdstrand> seb128: the patch is available for people to use if desired, so that's fine.  Seems odd so many of my users hit it though...
<seb128> you might have something specific in your configs
<seb128> my laptop disk is not that fast
<seb128> and I never run into the problem with it I think
<agoliveira> evand: BTW, it worked nicelly on Tribe 1.
<jdstrand> seb128: I have a ton of filters-- maybe that's it.  shrug
<jdstrand> seb128: http://www.go-evolution.org/Camel.Local is the link I was talking about with discussion of the real fix.
<RainCT> Hi, is any REVU admin there?
<jdstrand> seb128: could be mine and my users slowish connection.  agin, shrug
<jdstrand> seb128: I am basically happy-- I can use the workaround, just thought I'd spread the love.  :)
<cjwatson> robertj: I just meant PAM maintenance in general in terms of upgrading to current upstream
<cjwatson> since people were asking about that
<cjwatson> agoliveira: if you could start the installer with 'ubiquity --debug', reproduce the hang, and attach /var/log/syslog, /var/log/partman, and /var/log/installer/debug to a new bug report, that ought to help
<agoliveira> cjwatson: Sure, I'll try.
<robertj> cjwatson: ahh
<agoliveira> cjwatson: Now it worked flawlessly. Go figure.. I'll try again from scratch.
<cjwatson> agoliveira: heh, always the way
* agoliveira is starting again, kill gdm, disable expo, update ubiquity, etc etc etc and remembers why he never liked Q&A jobs...
<keescook> cjwatson: PAM> yeah, heard the same from vorlon.  Since I'm in no rush, I don't think it's a big deal.  it'd be nice if we get it in before gutsy freezes, though, just so we can work out any bugs prior to gutsy+1.
<ogra> pitti, testing done: http://people.ubuntu.com/~ogra/19to20.debdiff (sorry for the .po and autoconf noise, cant avoid it on bzr export with that tree)
<ogra> cjwatson, did you mean you wanted ot fix edubuntu-meta's update.cfg before ? or did i misunderstand ? 
<shawarma> Slightly off topic: What is "VMWare paravirtual kernel support"?
<shawarma> Do I want it?
<agoliveira> cjwatson: believe or not, it just worked now (it's already copying the files) but I have a this crazy idea that it may be related to the crazy partition scheme I have in this HD because I have NTFS, AFS and EFI on it (macbook with tripple boot).
<pitti> agoliveira: thanks for the (painful) testing; it seems that the next CD images should be good for you then :)
<agoliveira> pitti: Glad to help. I just hope I have a usable notebook to take with me to the sprint in July ;)
<pitti> ogra: please go ahead and upload ltsp
<agoliveira> I'll finish the instalation to see if any more quirks show up.
<ogra> pitti, oki
<pitti> ogra: is the new edubuntu-meta ready as well? I don't see it in the queue 
<pitti> ogra: I'd like to get mvo's and your two fixes into the queue now and run the publisher, then we can finally respin CDs
<ogra> no, it doesnt work 
<ogra> i added required to the update.cgf seeds line but it still fails
<pitti> ogra: oh, ./update fails?
<pitti> ogra: do you have the current germinate?
<seb128> pitti: are standalone applications, ie: rhythmbox also frozen?
<Riddell> enrico: you are a genius
<ogra> yep
<Riddell> enrico: many thanks
<ogra> 0.28 as cjwatson said
<pitti> seb128: everything is frozen by default; if there's an upload with innocent fixes, please ping me
* mvo hugs enrico for the adept fix
<pitti> seb128: rhythmbox            | 0.11.1-0ubuntu1      | 4 hours 50 minutes <= that one?
<pitti> seb128: new upstream version, hmmmmmm
<seb128> pitti: well, new rhythmbox should not break the worl has would be cool
<seb128> world
<seb128> but that's your call
<seb128> yes, that one ;)
<pitti> seb128: does it fix any OMGponies bug?
<seb128> no
<seb128> it fixes some regular bugs
<pitti> we currently have so many troubles that I'd rather avoid introducing more 
<pitti> seb128: let's postpone it then, people can still upgrade their tribe installation afterwards
<seb128> k
<pitti> seb128: I listened to RB the entire day, worked fine *evil grin*
<seb128> I'm ready to close the "new version available" bugs we will get in the next bugs then :p
<seb128> good ;)
<pitti> ogra: what's the exact problem? I recently updated kubuntu and ubuntu seeds with the same change, worked fine
<seb128> I like the new rhythmbox icons on gutsy ;)
<pitti> indeed, me too
<ogra> Traceback (most recent call last):
<ogra>   File "/usr/bin/germinate-update-metapackage", line 209, in <module>
<ogra>     list(seed_inherit[seed_name] ))
<ogra>   File "/usr/lib/germinate/Germinate/germinator.py", line 443, in plantSeed
<ogra>     if self.alreadySeeded(seedname, pkg):
<ogra>   File "/usr/lib/germinate/Germinate/germinator.py", line 335, in alreadySeeded
<ogra>     if (pkg in self.seed[seed]  or
<ogra> KeyError: 'required'
<pitti> ogra: ah, very same bug that we had with kubuntu and ubuntu
<pitti> ogra: seeds: required minimal standard desktop
<pitti> ogra: NB that 'required' has to come first
<ogra> ah, k
* pitti accepts the ltsp upload
<mvo> pitti: testing the expo fix as we speak, should be ready in ~5-10min
<pitti> mvo: so you have an actual fix now instead of disabling it? neat
<mvo> pitti: I hope, works for me, but it was random before for me, so I can not gurantee anything (but even disabling expo would not have guranteed anything as it is just the most likely cause of the hang juding from the diff between 0622-0625)
<mvo> its just very very hard to debug
<pitti> mvo: iwj and agoliveira got it too, no?
<agoliveira> pitti: I was able to finish the instalation but didn't try to enable compiz if this is what you're talking about.
<pitti> agoliveira: (CC: mvo) I think the hang only occured if compiz tried to enable it self
<mvo> pitti: compiz-fusion-plugins-main uploaded with the fix for the expo thing 
* pitti hugs mvo
<mvo> well, the 80-95% fix
<mvo> lets hope for the best
* mvo crosses fingers
<pitti> mvo: what's the 20 to 5%?
<mvo> pitti: that is the remaining uncertaintiy
<pitti> mvo: ah, 'k
<mvo> but I'm confident
<mvo> :)
<pitti> mvo: so, let's get new images out ASAP for more testing then
<agoliveira> mvo: heisenberg principle? :)
<mvo> agoliveira: heh :-D
<mvo> pitti: yep
<mvo> pitti: the new image should fix the nv issue you have seen as well 
<pitti> -       es->expoMode = !es->expoMode;
<pitti> +       es->expoMode = !es->expoMode;   
* pitti tries *really* hard to see the difference
<pitti> ah, the three trailing spaces :)
<pitti> mvo: ok, the real diff looks unintelligible, but small enough, thanks
<agoliveira> Hmmm... from time to time the icon "thingy" that shows the current LCD brightness pops. Did anyone see this?
<pitti> ogra: better now?
<ogra> yes, i'm just checking
<okaratas> hello
<ogra> i'm not sure all deps of compiz are fulfilled currently, might be that i'm oversized again
<ogra> that merge wasnt in yet
<ogra> pitti, uploaded, should hit the queue in a sec
<pitti> ogra: ok, accepted; now I'll sort out the publisher problem with the soyuz guys, then we are in the game again
<pitti> ogra: thanks
<ogra> ok
<ogra> the -meta upload wouldnt have been necessary for ship anyway iirc
<ogra> (i dropped the lang from ship)
<lionel> pitti: could you please give back gobby on i386, sparc and powerpc. It should build now. Thanks!
<pitti> lionel: done
<lionel> pitti: great, thanks!
<ogra> crimsun, you somehow missed to merge my esd samplesize patch from our current pulseaudio package
<pitti> lionel: did you include StevenK's 0.11-1ubuntu3 fixes of ufraw in your upload?
<pitti> lionel: there were 2 versions in unapproved at the same time
<lionel> I've seen. Yes, I've included StevenK fixes
<ogra> crimsun, its half the size of what it needs to be to play the login sound over network ... (funnily the logout sound is small enough)
<pitti> lionel: good, thanks
<lionel> np :)
<crimsun> ogra: please upload.  I'm certain I tested, but I do have multiple unpacked source trees here, so I'll write a hook to test more thoroughly.
<crimsun> ogra: sorry for the inconvenience.
<lifeless> anyone interested in a huge evolution memory footprint?>
<seb128> no
<seb128> or maybe upstream
<seb128> the desktop team basically send evolution bugs upstream anyway
<lifeless> yah
<lifeless> I'm asking up streamish nw
<lifeless> *now*
<pitti> StevenK: can you please use the current MIR template for openal and freealut? they are very thin ATM (no bugs research, etc.)
<pitti> zul: FYI, the binary/NEW packages xen-hypervisor-3.1-amd64 and libxen3.1-dev (on amd64) are still empty
<pitti> zul: I leave them in the queue for now
<crimsun> Has there been discussion regarding whether login graphical environment sounds should be muted by default on new gutsy installs?
<crimsun> The impetus for the above question is bug 122417.
<ubotu> Launchpad bug 122417 in alsa-utils "[Gutsy]  Volume is too high in new install on HP Pavilion dv8220" [Wishlist,Triaged]  https://launchpad.net/bugs/122417
<cjwatson> ogra: whoops, sorry, I forgot to do edubuntu-meta earlier
<cjwatson> I'll go through everything after tribe-2 and make sure it's all consistent
<cjwatson> all *-meta I mean
<seb128> pitti: are some dbgsym known to be not available on gutsy?
<pitti> seb128: not deliberately
<pitti> seb128: some might get dropped if rookery cannot connect to LP
<pitti> seb128: I can rescue stuff from the last seven days
<seb128> #122009 indicates thant vino-dbgsym is not available
<pitti> seb128: well, just let me re-fetch the stuff from the last week and rebuild the incices
<pitti> seb128: in five minutes, when I got the last publisher run started
<seb128> k
<seb128> pitti: don't bother too much, that can wait after tribe-2
<gnomefreak> pitti: we dont need your repo for -dbgsym packages anymore as of gutsy?
<pitti> gnomefreak: erm, why not? the apport retracer relies on it
<gnomefreak> oh ok
<pitti> gnomefreak: well, 'we' in the sense of bug triagers, right
<gnomefreak> ok ty
<heno> seb128, pitti, evand: stgraber attached some apport logs to bug 122141 (gtk bug crashing ubiquity) I've milestoned it
<ubotu> Launchpad bug 122141 in gtk+2.0 "SIGSEGV in gtk.Button.set_image" [High,Confirmed]  https://launchpad.net/bugs/122141
<pitti> heno: I thought that's the bug evand circumvented in the latest ubiquity?
<pitti> evand: can you please have a look and duplicate it if appropriate?
<heno> pitti: that's from 20070626.1
<pitti> heno: right, we have a new one since then
<heno> should the fix be there?
<seb128> heno: bug is workarounded and known upstream and has a testcase
<pitti> heno: apt-get install ubiquity on the live system
<pitti> heno: FYI, I just started another publisher run
<pitti> heno: after that we should finally have the necessary bits together for new CD images
<heno> stgraber: ^
<pitti> heno: quite a lot of compiz/ubiquity/network-manager fixes
<evand> pitti: will do
<stgraber> heno: good
<heno> pitti: ok, cool
<seb128> heno: I've removed the milestone, it's already workarounded in ubiquity
<heno> seb128: sure, thanks
* mvo is happy to report compiz-by-default does not break on a s3virge system with 4mb video ram
<pitti> seb128: doesn't it affect other pygtk apps?
<seb128> pitti: it affects any GTK+ app using set_image on a button apparently
<evand> set_image on a button when using glade
<pitti> seb128: that sounds pretty important?
<seb128> pitti: but we didn't get other complain about it so I guess there is no other desktop application doing it
<pitti> seb128: hm, funny :)
<seb128> pitti: well, most apps use stock icons
<seb128> I think it can be fixed after tribe-2
<pitti> seb128: right; I mean tribe3
<seb128> it'll be fixed quickly most likely
<pitti> true that
<seb128> feel free to milestone it if you prefer
<seb128> it's high importance so it'll stay on my list of things to get fixed quickly
* pitti trusts you with that
* seb128 hugs pitti
* pitti hugs the Sebmaster
<pitti> seb128, gnomefreak: I re-fetched all ddebs from June 18th until today; that's everything we can rescue
<pitti> rebuilding indices now
<gnomefreak> pitti: ok using your repo is no problem i just wasnt sure if it was needed
<pitti> gnomefreak: the common way nowadays is to have apport file bugs and let the auto-retracer do its job
<seb128> pitti: thank you
<gnomefreak> pitti: ok cool thank you.
<pitti> !usn | pitti
<seb128> pitti: wrong window? ;)
<pitti> seb128: no, testing ompaul's new factoid
<seb128> ah
<pitti> but it replied with a strange PM
<ompaul> !usn > pitti
<pitti> <ubotu> ompaul wants you to know: usn is Please see http://www.ubuntu.com/usn for information about Ubuntu security updates.
<ompaul> did that work better
<pitti> ompaul: why isn't that pasted into the channel any more?
<pitti> !ask | ompaul
<ompaul> !usn | pitti 
<pitti> hm, that still worked a few days back
<ompaul> hmm 
<ubotu> ompaul: Don't ask to ask a question. Just ask your question :)
<ubotu> pitti: usn is Please see http://www.ubuntu.com/usn for information about Ubuntu security updates.
<pitti> aaah
<ompaul> the lagging interweb
<pitti> what did we do different this time?
<ompaul>  | from me to you 
<ompaul> the > was send a message
<ompaul> | is public
<pitti> "!recursion is !recursion"; "!recursion | ubotu"
* pitti grins evily
* ompaul kills pitti with a stare
<mc44> pitti: ubotu is too smart for that :)
<pitti> I quoted it to not make it pick that up
* ompaul wonders if ubuntu will ever go on tour in dublin (uds kind of a tour)
<mc44> it wouldn't work anyway
<pitti> yay, publisher finally finished
* pitti works the cdimage crank
<doko> pitti: gcc-4.2 built; please accept gcc-4.1
<pitti> doko: that won't break our default compiler? :)
<doko> pitti: no, I did build the package locally on i386 without regressions
<pitti> doko: is 4.1 necessary for lpia, too?
<doko> pitti: yes; well, not if we make 4.2 the default for lpia from the start
<pitti> doko: I'm just afraid of 'we need to fix package foo quickly; oops, FTBFSes with current gcc nwo' type of thing
* pitti actually takes a look at the debdiff
<pitti> doko: ah, looks harmless enough; accepting
<tfheen> doko: I'm happy to make 4.2 default for lpia from the beginning if you think that's sane
<doko> pitti: but just using gcc-4.2 as the lpia default, would require a gcc-defaults upload 
<doko> tfheen: I was still unable to switch a i386 chroot to lpia, with our changes to dpkg and gcc-4.1
<tfheen> doko: ok; your call
<tfheen> I'm off to bed.
<lifeless> noight
<pitti> mvo, heno, *: new ubuntu alternates are up, please test
<heno> pitti: will do
* pitti tests amd64 alternate
<mvo> pitti: rsyncing
* mvo has another cups of tea
* pitti grabs another cherry muffin
<pitti> mvo: organic multivitamine juice, dude! :)
<pitti> mvo: "Bioborn Multi-Frucht - 6 Frchte plus Mhre" keeps me alive here
<mvo> haha
<tarzeau> what would be the easiest way to get all changelogs of all packages of gutsy?
<mvo> that sounds way too healthy for me
* mvo pats his green tea
<mvo> tarzeau: try changelogs.ubuntu.com
<pitti> tarzeau: you can look them all up on changelogs.ubuntu.com
<tarzeau> thanks
<pitti> heno: how long do you estimate will you be still online for today?
<heno> pitti: had planned another hour, can be longer if needed
<pitti> heno: I build new images for all derivatives now (live+alternate), can you update the tracker? all images + 0.1
<heno> pitti: sure, ETA?
<heno> pitti: with the build script output we talked about it would happen automagically ;)
<tarzeau> could i get http://changelogs.ubuntu.com/changelogs/pool/ by rsync?
<tarzeau> or would someone create a tarball of it all?
<pitti> heno: should be fine; I'll give the ubuntu live a quick test to see that all the n-m/compiz madness is good now
<pitti> heno: hm, 3 hours for the last live, I think (xubuntu)
<pitti> heno: maybe 35 minutes for ubuntu live
<pitti> heno: yeah :/
<pitti> heno: hm, it's a bit tricky to foresee which images will end up as 26.2 and which as 27
<heno> pitti: ok, we may have some tracker admins in #ubuntu-iso
<heno> pitti: right, just have to look at cdimage.u.c
<tarzeau> is it okay to http mirror http://changelogs.ubuntu.com/changelogs/pool/ (i plan to do this weekly, maybe more). but it'll cause pretty much load on the webserver. i'd prefer a tarball or rsync... no chance?
<pitti> LongPointyStick, Riddell, *: new kubuntu alternates up for testing
<pitti> hi Burgundavia 
<pitti> Burgundavia: btw, do you have time for the tribe2 wiki page or do you need help with that?
<pitti> ogra, heno, LaserJock: new edubuntu alternates up (20070626.2), please test; no oversizedness any more \o/
#ubuntu-devel 2007-06-27
<mvo> pitti: any eta for -desktop yet?
<pitti> mvo: 10 minutes, I'd say
<mvo> pitti: ROCK!
<pitti> mvo: live image finished building 30 seconds ago, building iso now
<gnomefreak> is compiz enabled by default in gutsy with nvidia drivers?
<Kmos> i think it is
<pitti> mvo: ^ good question: what happens now if I enable nvidia after installing with nv? will it switch over to compiz or keep metacity?
<mvo> gnomefreak: we currently try to archive this, but nvidia will not be the default, it will be "nv" 
<gnomefreak> that would explain the crash than
<mvo> pitti: it will switch to compiz (that is our default wm)
<Kmos> gnomefreak :)
<pitti> mvo: ah, ok
<mvo> gnomefreak: oh?
<gnomefreak> its hard to diagnose a freezing issue with it enabled.
<pitti> gnomefreak: please test the new images, they should have that fixed
<mvo> gnomefreak: you use the nvidia driver and it freezes for you? do you have the latest (~10 minutes ago) packages for compiz and plugins-main?
<gnomefreak> i sent a crash to gnome-appearance-properties and it crashed compiz
<mvo> gnomefreak: can you give me the bugnumber please?
<gnomefreak> pitti: i have newest in repos
<gnomefreak> mvo: apport is lazy tonight it didnt file one said it couldnt
<gnomefreak> error was This problem report is damaged and cannot be processed
<gnomefreak> i will try again
<mvo> the very latest is really very fresh :) 
<gnomefreak> as of maybe an hour ago
<gnomefreak> 1:0.5.1+git20070621-0ubuntu3?
<Kmos> mvo: bug 122330
<ubotu> Launchpad bug 122330 in gnome-control-center "[Gutsy]  Gnome Appearance windows freezes and fails to finish loading " [Medium,Incomplete]  https://launchpad.net/bugs/122330
<heno> pitti: is that 'server' for edubuntu?
<pitti> heno, mvo, all: new ubuntu live images are up (20070626.2), please test
<mvo> gnomefreak:  then please try again, I think it was made available ~15min ago
<gnomefreak> k
<pitti> heno: which server?
<mvo> Kmos: thanks!
<heno> pitti: http://cdimage.ubuntu.com/edubuntu/daily/20070626.2/ Edubuntu doesn't have an 'alternate'
<pitti> heno: ah, right; yes, that's the server install CD
<mvo> Kmos, gnomefreak: that freeze in #122330 is with the "nv" driver? or the "nvidia" one?
<heno> pitti: ok, thanks
<gnomefreak> nvidia
<mvo> oh :/
<mvo> hrm
<mjg59> So, uh, why is hal-device-manager in system/preferences?
<mjg59> It can't actually change anything
<gnomefreak> mvo: i sent kill sig to it again compiz didnt crash this time :( but apport is working now
<gnomefreak> mvo: just got newest ones updating now ty
<pitti> mjg59: right, it should be somewhere else, or not installed at all
<mvo> gnomefreak: cool, thanks. lets see how that goes :)
<mjg59> pitti: Ok, not just me then:)
<gnomefreak> mvo: will let you know ty
<pitti> mjg59: it has been there since warty, though
<pitti> mjg59: at least there is hope, h-d-m has been dropped upstream, and replaced by gnome-device-manager which can actually *do* stuff :)
<mvo> pitti: alternative install works at least in vmware, testing -desktop on real hw now
<pitti> Xubuntu freaks, heno: new xubuntu alternates are up (20070626.1), please test
<mvo> pitti: that means the previous crash on login is fixed 
<pitti> mvo: hm, my alternate is at 71%; I want your fast hard disks :)
<mvo> heh :)
<Riddell> heno: seen this ubuntu windows installer? http://wubi-installer.org/
<heno> Riddell: yes, it's a gutsy goal
<evand> Riddell: https://wiki.ubuntu.com/InstallerForWindows
<Riddell> heno: who's doing it?
<heno> Riddell: community members in the forums
<Riddell> impressive
<heno> pitti: please include bdmurray in your build pings. He's got tracker admin powers now
<heno> Riddell: yeah it could rock if it matures in time
<mvo> pitti: tribe-2 with compiz on ati r200 works here very nicely
<pitti> heno: will do
<pitti> mvo: live session in vmware is good here
<bdmurray> pitti: thanks
<pygi> bdmurray, could we discuss my application to -qa pls? :)
<Kmos> how about to delete http://cdimage.ubuntu.com/daily/20070624/
<Kmos> and 25
<pygi> I solved thousand of bugs already :P
<pitti> heno, bdmurray, fabbione, *: new ubuntu server images up (20070626)
<pitti> heno, bdmurray: that covers the alternates; I'll build the ports now
<bdmurray> pygi: a bit busy at the moment
<heno> pitti: looks like I've goofed the ubuntu alternate .2 postings
<heno> posted them under the wrong milestone and there is no way to recover from that in the tracker :(
<pitti> heno: how so? wrong number for xubuntu and server?
<heno> pitti: correct number 20070626.2 for ubuntu alt, but wrong milestone. now I'm blocked from posting another 20070626.2 ubuntu alt
<pitti> heno: erk; so stgraber needs to poke an UPDATE sql at the right spot now?
<pitti> evand: hm, ubiquity translations are a lot worse than they used to be
<mvo> pitti: -desktop works on nvidia based system here too  (uses metacity unless I enable nvidia the apperance capplet - that has some glitches though)
<heno> pitti: except he seems to have gone off to sleep
<heno> (wisely)
<pitti> heno: for ubuntu I only see 'server' ones; is that what you mean by 'goofed'? alternates not showing up?
<heno> pitti: yes. I can make them appear as 20070626-2 (with a - instead of a .)to allow for test results to be posted, but the download links won't work
<evand> hrm
<pitti> heno, bdmurray, Riddell, LongPointyStick: kubuntu lives are up (20070626.2)
<evand> pitti: can you elaborate on that?
<pitti> heno: hm, I don't see download links anywhere anyway?
<pygi> heno, manual sql intervention?
<pitti> evand: just that a lot of strings appear in English now which used to be in German (like the user name/login/password mask)
<heno> pitti: click the ISO icon
<pitti> aah, I see
<evand> odd, I don't remember that changing, but then again I didn't do the user-setup merge.  I'll look into it after dinner.
<Riddell> pitti: thanks
<pitti> heno: hm, let's do the 26-2 trick then, so that they at least appear; I'll try to add symlinks on cdimage
<pitti> heno: that affects ubuntu alternate? ubuntu desktop and kubuntu alt/live as well?
* gnomefreak stays confused filed bug for pitti on apport-gtk crash traceback is OSerror about '/var/crash/_usr_bin_compiz.real.1000.crash'
<pitti> heno: I guess it's better if you do the change first, and then I'll do the necessary symlinks
<pitti> gnomefreak: hmm, apport crashing on reporting a compiz crash? great
<gnomefreak> lol
<gnomefreak> there is no compiz crash file
<gnomefreak> but no such file or dir for the above
<mvo> gnomefreak: so the upgrade did not fix the crash?
<gnomefreak> mvo: hard to tell since there is no crash for compiz
<mvo> gnomefreak: I mean, when you enable it, do you get a working compiz? or does it not work or hang?
<gnomefreak> mvo: i didnt enable it i just logged in
<gnomefreak> what would session name be for it?
<gnomefreak> ill see if its enabled
<mvo> gnomefreak: please go to system/preferences/appreance and there to the desktop effects tab
<gnomefreak> mvo: yeah that again
<gnomefreak> if it works now ill let you know
<gnomefreak> otherwise nothing i can do
<mvo> 'k
<gnomefreak> its still freezing
<heno> pitti: never mind bdmurray saved the day by figuring out how to fix it :)
* heno hugs bdmurray
<mvo> gnomefreak: hm, no good :/
<pitti> bdmurray: *big hug*
<heno> the tracker actually has the functionality to fix it, it's just a bit awkward 
<gnomefreak> mvo: agreed i was looking to disable it so maybe gnome-appearance-properties wouldnt freeze
* mvo needs to reboot to test the new -desktop on his laptop
<pitti> heno, bdmurray: kubuntu doesn't have any images, is that a tracker bug? or haven't they been added so far?
<bdmurray> pitti: haven't been added yet we were sorting out the other issue
<bdmurray> I'm on it though
<pitti> ah, ok
<bdmurray> pitti: done
<gnomefreak> we need another way to get into desktop-effects settings :(
<pitti> ah, I see the kdesktops now (no kalternates yet)
<pitti> so, amd64 ubuntu alternate+desktop work fine now in vmware
<pitti> gnomefreak: that's in Preferences -> Appearance now
<pitti> I'll try the live CD on real hardware now, brb
<gnomefreak> its freezing
<gnomefreak> i cant get in it
<pitti> gnomefreak: hm, even with the current CDs?
<pitti> gnomefreak: ah, nevermind, that's in an installed system, right?
<gnomefreak> yes
<pitti> bummer
<pitti> anyway, brb
<gnomefreak> yay i managed to crash compiz
<shawarma> Is Creative Commons Attribution 2.0 free enough for us?
* heno gets some sleep
<tarzeau> shawarma: which one exactly?
<shawarma> http://creativecommons.org/licenses/by/2.0/
<shawarma> http://people.debian.org/~evan/ccsummary.html says no :(
<tarzeau> shawarma: do you want to use this license?
<shawarma> tarzeau: No, I want to distribute something that is already under it.
<elmo> shawarma: cc-by-sa is free enough for us
<tarzeau> shawarma: talk to whoever used the license
<shawarma> elmo: Cool. Then why not for Debian?
<pitti> mvo: how does things look for you?
<pitti> mvo: I managed to enable nvidia in the live system (on real hw now); vmware installs went fine for me
<elmo> oh, that's by, not by-sa
<mvo> pitti: pretty good, I got two random crashes but that might be HW (CD disc) - but nothing that looks like compiz breakage
<shawarma> elmo: So it's a no-go after all?
<shawarma> elmo: (the docs I'm looking at are just by)
<mvo> pitti: tested on ati r200 (working compiz), nvidia (works, but appreance capplet has some glitches), and r500 ati (vesa, no breakage, metacity is used then)
<elmo> shawarma: by is no good for us either
<mvo> oh, and a s3virge :)
<pitti> mvo: sounds good
<Burgundavia> shawarma: we already distribute CC stuff in main. ubuntu-doc is dual licensed GFDL and CC by sa
<elmo> shawarma: and we're not Debian - we don't always follow their license choices
<shawarma> elmo: Alright. If I can convince them to use cc-by-sa instead, it's all good?
<elmo> Burgundavia: we distribute by-sa, plain by is not ok
<elmo> shawarma: yes
<pitti> evand: hm, when I select 'manual partitioning' I get eternal hang
<shawarma> elmo: Wicked. Thanks.
<Burgundavia> elmo: right
<mvo> pitti: yes, quite encouraging so far
<pitti> mvo: even n-m worked reasonably \o/
<pitti> if ubiquity would actually work now (with manual), that would be uber-cool
<Kmos> good night
<mjr> elmo, umm, why not plain by if by-sa is ok?
<elmo> mjr: because by doesn't give permission to modify?
<mjr> elmo, you're thinking by-nd
<shawarma> elmo: http://people.debian.org/~evan/ccsummary.html says cc-by-sa is not ok for Debian for the same reasons that cc-by isn't. 
<elmo> mjr: that's possible, the CC license rabbit like proliferation gives me a headache
<shawarma> :)
<elmo> ok, so having actually read the license, mjr's right and I'm on crack
<elmo> shawarma: so both cc-by and cc-by-sa are fine, and I'm going away now
<shawarma> ..so I'm supposed to try and convince them to use.. what? cc-by-nd?
<mc44> no!
<mc44> :)
<shawarma> Ah, the other way around?
* shawarma has no idea
<mjr> shawarma, either by or by-sa. nd or nc are no-nos
<shawarma> Is there anything in particular that makes it alright for us but not for Debian, or is it just debian-legal being overly pedantic?
<LaserJock> by is attribution, sa is share alike (copyleft), nd is no derivative
<LaserJock> nc is non-commercial
<shawarma> Ah. nd sounds bad :)
<mjr> shawarma, it is a somewhat pedantic issue; overly is a matter of taste
<mjr> it's _good_ that d-l is pedantic
<mjr> somebody needs to be
<shawarma> True that.
<elmo> bear in mind that debian-legal don't actually represent the decision making body when it comes to making license choices for Debian
<pygi> it mostly gives advices
<pygi> afaik
<shawarma> I see.
<LaserJock> elmo: who is? do GRs like in the case of GFDL represent a decision?
<elmo> LaserJock: certainly
<elmo> LaserJock: but day to day it's the ftp-masters processing packages through NEW that actually matter - debian-legal is just a mailing list
<pitti> evand: hm, I tried it a second time now, with reformatting my test ntfs with ext3; still hangs at manual
<elmo> LaserJock: (disclaimer: I'm not exactly unbiased ;-)
<LaserJock> elmo: of course
<StevenK> pitti: MIR for OpenAL updated, FreeAlut getting done now.
<LaserJock> elmo: but I found it odd when you were essentially ftp-master in both Debian and Ubuntu, did you pretty much view things the same, or did you use different criteria
<pitti> evand: dang -- when I start it with "UBIQUITY_DEBUG=1 sudo ubiquity", it works; yay heisenbug
<pitti> StevenK: cheers
<elmo> LaserJock: different critteria - Ubuntu has it's license policies which I applied when processing it's NEW, and I applied Debian's when processing Debian NEW
<LaserJock> but who makes the Ubuntu license policy?
<elmo> LaserJock: I've no idea anymore? :)
<lifeless> TB
<LaserJock> I've never seen anything written.
<elmo> there use to be some stuff on the old website
<LaserJock> I just wonder if it's sort of historical/traditional
<elmo> not sure if it survived the crackpalization
<LaserJock> perhaps not
<elmo> LaserJock: some of it certainly was - discussed at Oxford type stuff
<LaserJock> I've searched around for it
<LaserJock> the only real differences I've see where GFDL and CC
<LaserJock> *were
<elmo> yes, that's the principal difference, Ubuntu's more liberal approach to non-source code type stuff
<elmo> documentation, fonts, firmware, images, sounds, etc.
<LaserJock> right
<Pici> RobNyc: I believe its called "Main Menu" in the panel add dialog, and does not have the ubuntu icon
<pitti> bdmurray, ogra: edubuntu live is up (20070627)
<Pici> Sorry about that, switched windows in the middle of typing.
<StevenK> pitti: freealut also done.
<pitti> bdmurray: btw, ubuntu doesn't have desktops on isotesting yet 
<bdmurray> pitti: should be all set now
<StevenK> pitti: Let me know if the two MIRs are now suitable, if you're still looking at them.
<pitti> bdmurray: yay; ETA for xubuntu is ~ 15 minutes (will be 20070627, too)
<bdmurray> pitti: strange future numbers
* shawarma calls it a day
<pitti> bdmurray:  BST :)
<gnomefreak> i found the cause of gnome-appearance-properties freezing
<gnomefreak> its freezing due to gnome-themes-extras
<gnomefreak> if i uninstall it appearance crashes
<LaserJock> pitti: I'm testing 20070627 Edubuntu live in vmware now
<pitti> LaserJock: thanks; please report the results on isotesting
* pitti reboots into installed system again, brb
* mvo leaves for the evening
<pitti> bdmurray: http://cdimage.ubuntu.com/xubuntu/daily-live/20070627/ is finally there
<LaserJock> ok, I"m having the same problem as with 20070626.1
<LaserJock> it won't login in vmware
<LaserJock> it just has this endless cycle or reloading gdm
<LaserJock> s/or/of/
<StevenK> LaserJock: Does it kill X?
<LaserJock> I think so
<LaserJock> it kicks it back to console
<LaserJock> then it tries to login, then dies
<LaserJock> and it'll do it indefinately until I turn it off
<pitti> LaserJock: which graphics card?
<LaserJock> well, it's vmware on an intel imac with an ATI card
<bdmurray> pitti: what does that leave?
<pitti> bdmurray: supported arches and all derivatives are done
<pitti> bdmurray: ports alternates are built, too, DVDs are running over (my) night, will build the ports/lives later
<pitti> bdmurray: my live install on real hw was quite mixed: hanging ubiquity when doing manual partitioning, hanging splash screen, no logout dialog, hmm
<LaserJock> StevenK, pitti: is this a known issue? ogra thought it was
<pitti> LaserJock: it was actually be supposed to be fixed on latest images
<pitti> LaserJock: I had the same and it worked for me now
<pitti> LaserJock: can you please file a bug against compiz, assign to mvo, and milestone it for tribe-2?
<LaserJock> hmm, I'll rsync again just to make sure I'm actually updated
<pitti> LaserJock: please include your setup and milestone versoin
<LaserJock> pitti: compiz???
<pitti> LaserJock: yes, it shouldn't enable itself on the vmware driver
<StevenK> LaserJock: Yes, compiz checks for GL, glxinfo segvs and the server dies.
<pitti> LaserJock: on some drivers, glxinfo causes X to crash, and those are blacklisted
<wasabi> Hmm. So compiz is going to be on by defalt on some select cards?
<LaserJock> hmm, when I login with ubuntu (not let it automatically login) I see a flash of a "Could not load gnome-settings-daemon" error
<pitti> bdmurray: I need to get some sleep :/ can you have an eye on critical stuff and milestone those bugs?
<Fujitsu> wasabi: By default except for those that are blacklisted.;
<wasabi> Eww. Is ati blacklisted? :)
<Fujitsu> (or just don't support composite)
<pitti> wasabi: ati isn't; that uses glxinfo capability detection
<wasabi> I can't think of any drivers except maybe the intels in a state where I'd enable something like that by default. =/
<wasabi> My ATI, with the closed source drivers, is not stable for more than a day with it.
<wasabi> err, with teh OPEN source drivers.
<wasabi> The closed ones barely last 5 minutes. ;)
<wasabi> Where is said list?
<bdmurray> pitti: milestone for tribe 3?
<pitti> bdmurray: the real blockers for tribe2
<bdmurray> pitti: yeah, I thought out it harder. ;) Yes, I'll keep an eye out this evening
<pitti> bdmurray: thanks
<pitti> good night everyone
<bdmurray> pitti: night
<pitti> bdmurray: I'll file bugs for my installation issues tomorrow and will discuss them with Seb and evand; just cannot keep my eyes open any more
<LaserJock> bdmurray: ok, I reported my Edubuntu LiveCD issue as bug #122459 . I'm not sure if any more is needed
<ubotu> Launchpad bug 122459 in compiz "[gutsy]  cannot log in on edubuntu DesktopCD" [Undecided,New]  https://launchpad.net/bugs/122459
<TheMuso> /c
<TheMuso> uuugh
<bdmurray> LaserJock: looking
<bdmurray> LaserJock: is that amd64 or i386?
<LaserJock> oh, sorry, I was using i386 CD
<bdmurray> LaserJock: no problem I updated it
<LaserJock> thanks
<LaserJock> anything else?
<LaserJock> I'm about to head home, I'll try it there too
<bdmurray> not that I can think of I'm going to try and recreate it 
<LaserJock> ok, bbiab
* desrt enjoys hotel candy
<desrt> mmm hoteles silken
<bdmurray> LaserJock: I'm unable to reproduce that bug
<sbalneav> evening 
<ajmitch> hello sbalneav 
<someone2005> I've got evolution installed and seems my mail go's into the outbox instead of sent...Any Ideas ?
<wasabi> oh cool so im going to this live thing
<LaserJock> bdmurray: same things happens on my Ubuntu vmware :(
<LaserJock> bdmurray: did you try it in vmware?
<bdmurray> LaserJock: yes, I did
<bdmurray> LaserJock: Do you know if vmware video drivers change?
<LaserJock> bdmurray: I have no idea
<LaserJock> but the two systems I tried on where completely different
<Hobbsee> morning all
<sbalneav> Morning Hobbsee
<Hobbsee> :)
<LaserJock> one was intel iMac with ATI video, second was Ubuntu PC with nvidia video
<LaserJock> different versions of vmware (vmware fusion on the mac and vmware server on Ubuntu)
<LaserJock> different .isos
<LaserJock> unless I totally messed up the rsync
<LaserJock> but I'm pretty sure I got the right one
<bryce> heya Hobbsee
<Hobbsee> :)
<Hobbsee> bryce: how goes X?
<bryce> Hobbsee: I have a theory on what happened.  I notice the xorg package causes generation of libgl* debs when pbuilding it.  I was doing pbuilds of xorg and mesa around the same time, so suspect the build of the former got mixed with the build of the latter
<Hobbsee> bryce: ahhh.....
<Hobbsee> bryce: but they still shouldnt be producing the same binaries
<bryce> anyway, I decided to do one thing at a time.  ;-)  I got the xorg stuff done today, and will focus on mesa tomorrow
<Hobbsee> :)
<Hobbsee> bryce: that versoin that i had is working, if you wanted to upload it anyway
<Hobbsee> or if you wanted me to
<bryce> yes, that would be great!
<Hobbsee> bryce: you dont want more changes?
<bryce> ok, I've been at this since 6 this morning and my brain is mush
<Hobbsee> bryce: btw - did you look at what my changes even were?  :)
<bryce> you mean the +Conflicts?
<bryce> I looked at the diff but haven't had a chance to test them on my own system
<Hobbsee> yeah
<bdmurray> LaserJock: did you verify the md5sum ?
<Hobbsee> bryce: uploading
<bdmurray> LaserJock: Which version of VMWare is it?
<fabbione> morning guys
* StevenK waves to fabbione
<Hobbsee> morning fabbione!  you're up early!
<fabbione> yeah i couldn't sleep today
<ajmitch> mornign fabbione 
<Hobbsee> :(
* fabbione isn't very happy about that
<StevenK> fabbione: Oh, I assumed it was your walking/crawling alarm clock.
<fabbione> StevenK: i am one hour earlier than usual
<mneptok> fabbione: please try not to wake me when you get out of bed early. :/
<mneptok> now come back here and let's snuggle.
* StevenK smirks.
<fabbione> mneptok: yeah i wish... i can't fall back to sleep once i wake up in the morning
<StevenK> fabbione: Try harder, I can. :-)
<mneptok> fabbione: the thorazine is on the second shelf of the medicine cabinet.
<fabbione> StevenK: it did never work
<fabbione> mneptok: ehe
<StevenK> Thorazine doesn't help you sleep, though...
<mneptok> StevenK: you're doing it wrong.
<ScottK> Ativan injections will have you asleep in less than a minute, guaranteed.
<StevenK> mneptok: Based on wikipedia, Thorazine is used for schizophrenia and 
<StevenK> short term management of severe anxiety.
<mneptok> StevenK: the voices in my head disagree
<StevenK> Hah
<Hobbsee> keescook: seriously, you rock.
* ScottK agrees, but is curious why now particularly?
<Hobbsee> ScottK: he wrote a greasemonkey script, so you can add whichever predefined responses you like, and it'll change statuses, etc, on launchpad
<shadeofgrey> Greetings.  I know I font belong here - i just have one question -- is their optomism that the next version will be easier to install on macbookpro's with ati video cards?  thus far i havent been able to get       definitive answers  as to how one goes about installing edgy on previously stated hardware
<ScottK> Ah.
<ScottK> shadeofgrey: You do know there is a newer release than Edgy, right?
<shadeofgrey> ScottK, no i didnt
<shadeofgrey> ScottK, is it easier to install onb intel macs with ati video cards?
<shadeofgrey> if so we should probably speak in private.  im probably already in trouble with the channel bosses for showing up here in the first place
<ScottK> shadeofgrey: Since I have neither an intel mac, nor an ati video card I have no idea.  I'd suggest give it a try.
<shadeofgrey> where do i acquiure what you speak of?
<ScottK> shadeofgrey: http://www.ubuntu.com/getubuntu/download
<shadeofgrey> all i see is 6.06 and 7.04
<StevenK> shadeofgrey: Edgy is 6.10, which isn't there. That should be a hint.
<StevenK> shadeofgrey: You'd want to try 7.04
<shadeofgrey> oh
<shadeofgrey> ive already tried 7.04 --  wont work
<shadeofgrey> thanks anyhow
<shadeofgrey> sorry to disturb you guys
<TheMuso> I've seen him in #ubuntu-accessibility before.
<StevenK> No bug, no reason, no nothing. Sigh.
<Hobbsee> iirc he used to be a dev.  or at least in here.
<Hobbsee> he's not new, for a start.
<superm1> TheMuso, ping. 
<TheMuso> superm1: Hey.
<TheMuso> superm1: Sorry, I got sidetracked. I may get a chance to look in a bi.
<TheMuso> bit
<superm1> TheMuso, ah okay :)
<keescook> Hobbsee: heheh. thanks! I blame it all on Mithrandir, though; he wrote the original stuff -- I just felt like hurting myself and learning some more javascript.  :)
<fabbione> does anybody remember the url for isotesting?
<Hobbsee> oh well, thanks to tfheen too
<Hobbsee> fabbione: isotester.stgrabber.org, offhand
<fabbione> nope....
<Hobbsee> https://isotesting.stgraber.org/
<Hobbsee> The first Tribe-2 candidates are now available for testing. You can find 
<Hobbsee> download links, md5 sums and report results on the ISO tracker: 
<Hobbsee> https://isotesting.stgraber.org
<Hobbsee> Please help us find the nasty bugs early in the cycle so we can focus on 
<Hobbsee> polish closer to release  :)  For alpha releases we recommend the short 
<fabbione> yeps.. i already have test results
<Hobbsee> testing procedure: https://wiki.ubuntu.com/Testing/Short
<fabbione> thanks :)
<Hobbsee> Also see:
<Hobbsee> https://wiki.ubuntu.com/Testing/Community/Procedures
<Hobbsee> https://wiki.ubuntu.com/Testing/Community/ReportingResults
<Hobbsee> Thanks!
<Hobbsee> Henrik
<Hobbsee> are we actually testing these, for final?  i havent read backscroll
<Hobbsee> as in, do these have network mangler fixes?
<fabbione> Hobbsee: not sure.. i am only testing -server iso's
<Hobbsee> .2...they probably are.  will look later
<KrakensDen> so I just started testing gutsy, and it's constantly accessing my cdrom drive
<KrakensDen> any ideas for what is responsible?
<KrakensDen> kernel? hal?
<stgraber> asac: ping
<Amaranth> KrakensDen: probably hal-addon-storage
<Amaranth> KrakensDen: but this really isn't the right place for this discussion
<KrakensDen> Amaranth, where then?
<KrakensDen> Amaranth, I hate filing bugs without a target
<Amaranth> #ubuntu+1 or a bug on launchpad
<KrakensDen> Amaranth, ok, thank you
<Amaranth> I would say it's hal-addon-storage poking to see if you put a CD in
<KrakensDen> indeed: hald-addon-storage: polling /dev/scd0 (every 2 sec)
<Amaranth> sounds about right
<dholbach> good morning
<stgraber> morning dholbach 
<Hobbsee> hiya stgraber 
<dholbach> hi stgraber
<stgraber> Looks like henrik had some problems moving a build from one Milestone to another :), we really should write a doc ... (but it seems he finally found how to do so)
<stgraber> oh, funny the isolist isn't sorted correctly on the tracker, it's sorted by version instead of the distribution ...
<stgraber> fixed :)
<shenki> is 20070626.2 known to fail at install (desktop, i386)?
<stgraber> nobody tested the install (at least no results were posted on the tracker)
<shenki> stgraber: ok. that's the best place to report a failed install these days, or is opening a bug a better idea?
<fabbione> shenki: file a bug.. 
<shenki> ok
<fabbione> and make sure the iso tracker will reflect that
<stgraber> shenki: the right way is to file a bug, put a FAIL result on the tracker with the bugnumber and set it to critical (as you can't install)
<shenki> thanks
<stgraber> argh, it's time for me to leave you and go to this really useful school day :) (doing pretty much nothing than watching DVDs ...)
<stgraber> see you all later
* fabbione does an attempt to clean up his bug mailbox
<shenki> ahh, i love you too launchpad
<shenki> timeouts :( no bug report for me
<enrico> Riddell: I need help with adept's build system: I'm trying a clean rebuild with the patched version (using http://www.enricozini.org/store/adept.patch.gz) but the build system isn't building the .moc files anymore
<enrico> Riddell: I just can't find out why
<fabbione> hi enrico 
<enrico> Riddell: there's a few more minimal patches on top of that (some leftover LIBTAGCOLL_DEFS to remove)
<fabbione> enrico: we had some issues libept on sparc. the testsuite BusError 
<fabbione> enrico: strange thing is that if you run it manually works.. but from within the test script no.
<fabbione> enrico: if you want i can provide you with access to sparc
<enrico> Riddell: and it builds with libapt-front at svn://svn.debian.org/libapt-front/0.3.11 (forget about the name, it contains 0.4.0)
<enrico> fabbione: hi
<enrico> fabbione: thanks, vorlon pointed that out to me as well.  It bus errors on hppa and ia64 as well.
<enrico> fabbione: this evening I'll look into it.  If the normal DD accessible machines won't do it for me, I'll ask you about access
<fabbione> enrico: ok cool. i did temporary disabled the test suite for ubuntu but if you need any help just drop an email with your ssh key and i will setup access
<enrico> fabbione: ok, thanks
<fabbione> enrico: i also have hppa and ia64 toys around if you need...
<enrico> cool
* Hobbsee wonders how long it will be before pitti comes online
<enrico> Riddell: argh!
<enrico> *** YOU'RE USING automake (GNU automake) 1.10.
<enrico> *** KDE requires automake 1.6.1 or newer
<Hobbsee> enrico: appropriate http://kubuntu.org/~jriddell/kubuntu_00_autoconf2.60.diff i suspect
<StevenK> Hobbsee: He didn't go to bed until 2:30am his local time.
<Hobbsee> oh wait
<Hobbsee> enrico: dont mind me, i cant read.
<Hobbsee> StevenK: ouch.  by the logs, i can tell it must be something like that
<enrico> Hobbsee: :)
<enrico> Riddell: mornfall hinted me at make -f admin/Makefile.common cvs  and now the build has managed to start
* Hobbsee decides to test a cd anyway
* Hobbsee hugs rsycn
* LaserJock kicks rsync
<dholbach> HAPPY HUG DAY
<Hobbsee> dholbach: it's been hug day for ages, and i've been closing bugs!  :D
<dholbach> hehe
<pygi> lol
<Admiral_Chicago> grr i cant get started yet
* LaserJock gives Hobbsee a hug
<pygi> Hobbsee, I'd say we closed 50 burning bugs in two days
<pygi> which is nice :)
<Hobbsee> there's ~30 closed kdebase bugs, and about the same for kdemultimedia.  which is good!
<Hobbsee> :D
* Hobbsee  gives LaserJock a hug back :)
<pygi> and I'll close some tomorrow hopefully
<Hobbsee> hiya MithrandirWithWorkingSystem
<Admiral_Chicago> better
<Mithrandir> hiya Hobbsee
<Hobbsee> :)
<LaserJock> well crap, it seems rsync didn't really rsync my .iso
<Hobbsee> :(
* Admiral_Chicago hugs room
<LaserJock> well shoot, now I can't even confirm my own bug :/
<shawarma> Good morning, everyone. Happy hug day!
<Hobbsee> LaserJock: why not?
<Hobbsee> hiya shawarma!
<Hobbsee> shawarma: you asked something odd last night.  did you get an asnwer?
<shawarma> Hi, Hobbsee!
<shawarma> Hobbsee: Which one of my odd questions are you referring to?
<Hobbsee> dont remember.  i'll have to lastlog
<LaserJock> Hobbsee: well, I tried the Edubuntu Desktop CD at work and it wouldn't login
<LaserJock> so I went home and tried it at home, same thing
<LaserJock> now I figure out that the .iso at home didn't really rsync
<LaserJock> so when I *do* rsync it the bug goes away
<Hobbsee> ahhh
<fabbione> shawarma: server iso's are up for testing FYI
<shawarma> fabbione: Today's daily images?
<fabbione> shawarma: yes
<fabbione> 20070626
<shawarma> Great. I'm on it.
<fabbione> shawarma: i guess you also want to tell to the other -server guys
<fabbione> shawarma: i already did sparc for you
<shawarma> \0/
<shawarma> fabbione: They're all asleep. Slackers.
<fabbione> shawarma: then you win :)
* LongPointyStick pokes them all
<shawarma> fabbione: Uhuh..
<shawarma> fabbione: :p
<fabbione> shawarma: remember to play Lotto this week.. ~54M DKK on saturday
<shawarma> fabbione: Man, testing this is going to be so much nicer than Tribe 1. I've got a new kickass machine for it.
<fabbione> shawarma: good.. 
<shawarma> fabbione: Meh.. Playing the lottery is just an extra tax on lack of math skills.
<StevenK> Meh. There's no math skills to it.
<fabbione> shawarma: i won last week too...
<shawarma> fabbione: Big bucks?
<fabbione> shawarma: enough for a box of cigarettes and to pay off the play
<shawarma> StevenK: You'd think so.
<fabbione> shawarma: do you truely believe i was gonna test sparc today if i won big bucks? :P
<shawarma> fabbione: Um... yes?
<shawarma> fabbione: You like it, and you know it.
<fabbione> shawarma: Um no.. i would command somebody to do it for me :)
<StevenK> fabbione: Sure, because you would have ordered a few 96 CPU UltraSPARC IV monsters? :-)
<fabbione> ahaha
<leagris> hile, anyone could have a look at this one https://bugs.launchpad.net/bugs/118310 and have an idea for a workaround?
<ubotu> Launchpad bug 118310 in linux-source-2.6.20 "pktcdvd bound device limit the size readable from attached device when mounting ISO9660 or UDF dual layer DVD-ROM." [Undecided,Confirmed]  
<Hobbsee> pitti!!!!!!!!!!!!
* Hobbsee hugs pitti 
<pitti> good morning
* pitti yawns
* pitti hugs Hobbsee 
* StevenK waves to pitti, and runs off home.
<pitti> hi StevenK 
<Hobbsee> pitti: that's what happens when you go to bed at 2.30am :P
<pitti> Hobbsee: well, after 18 hours of sitting in front of that damn machine I just had to :/
<Hobbsee> hehe
<Hobbsee> understandable
<pitti> hm, no ubuntu desktop/alternate iso tests at all during the night :/
<Hobbsee> did you call for testers?
<Hobbsee> or did anyone else?
<Hobbsee> on irc?
<enrico> Riddell: uploaded in Debian
<dholbach> please give back nemiver prefixsuffix libgnomeuimm2.6
<pitti> Hobbsee: heno did on the mailing list yesterday
<Hobbsee> yeah, i just remmebered, hence added the IRC
<Hobbsee> pitti: those are the final images, as far as you know?
<pitti> Hobbsee: I did test installs yesterday and there were quite a lot of bugs; I need to talk to mvo and cjwatson_
<pitti> Hobbsee: so for Ubuntu we might need an update at least
<Hobbsee> pitti: right.  kubuntu seems OK, so far.
<Hobbsee> desktop
<Hobbsee> what bugs?
<enrico> Riddell: if you don't want to wait for a debian archive run, you can get them from http://www.enricozini.org/store/aptfront.tar and http://www.enricozini.org/store/adept.tar
<Hobbsee> enrico: we're in freeze at the moment anyway
<pitti> Hobbsee: ubiquity hanging eternally on manual partitioning, hanging session splash, no shutdown dialog, and other people had lots and lots of crashes with compiz
<Hobbsee> pitti: right.  
<pitti> kylem: still awake by chance?
* Hobbsee didnt think that "OK" and "cancel" are german.
<pitti> shawarma: thanks for doing some server tests; can you do the other i386 tests as well? and maybe an amd64 one?
<Hobbsee> erk.  my german isnt that good, to understand teh error messages.  *puts it back in english*
<pitti> Hobbsee: what did it say?
<Hobbsee> pitti: NFI :)
<Hobbsee> pitti: er, did you want more testers for the ubuntu cds?
<Hobbsee> if you know about those bugs already?
* pygi is worried what might happen if pitti says yes, and he will
<pitti> that would be great
<Hobbsee> pitti: preferance for desktop or alternate?
<pitti> we need a lot of testing for the compiz stuff, to cover lots of hardware
<pitti> Hobbsee: desktop; that's quicker
<shawarma> pitti: I'm on it. :)
<shawarma> pitti: Both i386 and amd64. I'll do all 6.
<pitti> Hobbsee: and booting the live system will already test the compiz stuff we're interested in; ubiquity tests cannot hurt, too
* pitti is going to look into his bugs from yesterday in more detail
<Hobbsee> pitti: yeah
<Hobbsee> pitti: i see what you mean about the checking the file system taking an eternity, it happens with the auto-resize too.
<Hobbsee> (kubuntu desktop i386)
<pitti> StevenK: cruft list updated, btw
<pitti> Hobbsee: oh, does it eventually get on?
<pitti> shawarma: great!
<Hobbsee> pitti: ahhh...yeah...now it is.  well, it's showing 50%, as opposed to 0
<Hobbsee> pitti: seems that not everything actually changes back to english, if you hit back repeatedly, and change the language in the installer
<pitti> Hobbsee: 50% of what?
<Hobbsee> pitti: of resizing
<pitti> Hobbsee: the 'reading partition table' dialog disappeared quite quickly, but then nothing happened any more
<pitti> ah, resizing
<shawarma> I know we've been over it numerous times over the last week... What's the difference between confirmed and triaged again?
<Hobbsee> pitti: Riddell's listed manual partition as a PASS.  so i havent tested it.
<Hobbsee> and catnn really, in a VM.
<Hobbsee> shawarma: anyone can confirm - but that doesnt mean its got enough info to fix it
<shawarma> Hobbsee: So triaged is more complete?
<pitti> Hobbsee: that's just weird; if it needs more info, it should be 'incomplete'
<Hobbsee> pitti: i never said it made sense.
<Hobbsee> shawarma: yes
<Hobbsee> triaged is no longer a closed state, too
<shawarma> Hobbsee: SUper. Thanks.
<shawarma> Hobbsee: So confirmed is basically a "me too"?
<Hobbsee> yeah
<shawarma> Excellent.
<cjwatson> pitti: is there a bug about the ubiquity hang?
<Hobbsee> morning cjwatson 
<cjwatson> morning
<Hobbsee> cjwatson: resize seems to take forever too.  not sure who's department that is
<cjwatson> Hobbsee: timed as longer than feisty?
<cjwatson> resizing is often Just Slow
<Hobbsee> cjwatson: i wasnt running a VM in feisty :)
<Hobbsee> cjwatson: it took ~5 mins?
<Hobbsee> or longer?
<cjwatson> that doesn't bother me too much
<cjwatson> I doubt it's changed - parted's basically the same
<Hobbsee> cjwatson: fair enough.  i havent reported it.  only reported the kubuntu mount one
<Hobbsee> and i've got a suspicion that that's a fairly simple one to fix
<cjwatson> I have not seen it
<Hobbsee> i only just reported it
<Hobbsee> https://launchpad.net/bugs/122500
<ubotu> Launchpad bug 122500 in ubiquity "Kubuntu - Mount dialog always gets shown when the disk is mounted, in the middle of the install" [Undecided,New]  
<cjwatson> I'm sure that used to work in Kubuntu
<pitti> hello cjwatson
* pitti hugs mvo
<pitti> cjwatson: I didn't yet dive into the manual partitioning hang; running with UBIQUITY_DEBUG=1 fixed it...
<mvo> hey pitti
<pitti> cjwatson: and the normal log didn't say anything
<mvo> pitti: how do the images look so far?
<pitti> mvo: my test install from yesterday was pretty bad :/
<pitti> mvo: compiz itself worked, but something in your new gnome-session makes the splash screen not go away and causes the shutdown dialog to not appear
<pitti> mvo: seb128 said it's due to something in the session startup which doesn't terminate properly
<mvo> pitti: yeah, I noticed that too
<cjwatson> pitti: I don't recommend UBIQUITY_DEBUG=1 any more, by the way - ubiquity --debug is easier
<pitti> cjwatson: ah, ok; I'll first try whether I can reproduce it in vmware
<shawarma> What do we actually do when we "Check CD for defects"? Check that the info in Packages correspond to the .debs? Anything else?
<cjwatson> shawarma: md5sum -c
<cjwatson> there's a big md5sum list on the CD
<shawarma> Ah
<shawarma> Clever :)
<asac> stgraber: pong
<pitti> cjwatson: I just reopened bug 114296, btw; is apt-install restricted to packages which are already on the live system?
<ubotu> Launchpad bug 114296 in restricted-manager "running restricted-manager before installation can break system" [High,In progress]  https://launchpad.net/bugs/114296
<pitti> cjwatson: when I uploaded r-m, I only ran the script to see that the executed apt-install commands are correct; however, yesterday I wasn't able to check whether the script was not ran in the first place, or apt-install didn't do anything
<pitti> mvo: session splash hang happens in vmware for me; can you reproduce that/
<pitti> ?
<cjwatson> pitti: it's not supposed to be, but ubiquity may be buggy there *shrug*
<StevenK> pitti: Ah, right. Thanks.
<cjwatson> pitti: I'd suggest closing the restricted-manager task and reopening the ubiquity task
<pitti> mvo: also, there were a lot of people yesterday who still suffered eternal login loops due to crashing session
<pitti> cjwatson: ok
<shawarma> pitti: I saw the eternal login loop thing on a daily image from a few days ago. The daily from yesterday worked fine.
<pitti> mvo: it seems that the blacklist is still not big enough
<mvo> hey seb128
<seb128> hi mvo pitti
<pitti> mvo: but we have to do something about it, we shouldn't ship a broken tribe-2 to 1/3 of testers
<pitti> mvo: can we turn this into a driver whitelist for now?
<cjwatson> Hobbsee: you know that ubiquity already does attempt to disable automounting, right?
<cjwatson> Hobbsee: so chances are KDE broke that ...
<Hobbsee> cjwatson: i didnt, but oK.
<Hobbsee> cjwatson: kde just offers the chance to mount the drive and such
<mvo> pitti: are their more details on the crashes/hangs?
<cjwatson> it may be it doesn't disable it for long enough
<Hobbsee> so i guess what you really want to do is to go "do nothing", and do it all the time.
<cjwatson> ubiquity calls 'dcop kded kded unloadModule medianotifier' before partitioning
<pitti> mvo: unfortunately not; I asked LaserJock to file bugs on it
<cjwatson> I suspect it loads it again too soon
<cjwatson> how about I adjust that and we'll see if that helps
<pitti> mvo: and milestone them, but there are no new milestone bugs ATM
<Hobbsee> cjwatson: worht trying
<pitti> mvo: I heard it from about three different people on IRC
<pitti> cjwatson: so, ubiquity manual hang didn't happen in vmware, so I guess it's specific to my disk layout; if noone else complains, we can just leave it like that for the tribe
<Hobbsee> okay, kubuntu was all good until it actually runs from the hard drive.
<pitti> hey seb128
<Hobbsee> a) it doesnt start X, b) i get "bash: /dev/null  Permission Denied"
<shawarma> Eek.
<Hobbsee> which may be VM specific, i'm nto sure
<cjwatson> Hobbsee: I bet some loony maintainer script replaced /dev/null with a regular file
<cjwatson> happens from time to time and we have to go and beat things
<Hobbsee> cjwatson: this si a clean install?
<cjwatson> sure?
<cjwatson> I mean, that doesn't exclude the possibility
<Hobbsee> well, they were both clean installs, in a VM.  one took the entire disk, and the other auto-resized.
<Hobbsee> right, true
<Hobbsee> is a virtual pc 2007 setup is considered a valid system spec?
<pitti> mvo: I have a running '/bin/sh /usr/bin/compiz' here in vmware; could that be the reason for the hang? the script that doesn't terminate?
<mvo> pitti: I'm looking into it now
<pitti> mvo: hm, killing that doesn't help at least
<cjwatson> Hobbsee: the problem you describe (assuming that /dev/null is really a regular file rather than a character device; please check) is unlikely to be truly hardware-dependent
<Hobbsee> cjwatson: that question is unrelated, sorry.
<cjwatson> ok
<pitti> mvo: ah, it hanged on gnome-wm
<pitti> seb128: ^
<pitti> that takes a minute to 'connect to the session' until the other programs in the session are called and logout dialog etc. work
<pitti> (I was watching gnome-session-properties)
<seb128> pitti: do you have the new gnome-session where mvo removed the gtk-window-decorator call?
<pitti> seb128: I have the latest CDs, which have the latest packages
<pitti> 2.19.4-0ubuntu3
<seb128> k, so I don't know, mvo tracked that bug yesterday and he said it was due to the gtk-window-decorator call
<pitti> yep, changelog says so
<seb128> I didn't get the bug when I tried the CD yesterday
<seb128> I'm rsync the CD update atm
<pitti> seb128: did you try it on hardware which has compiz by default?
<seb128> yes
<pitti> ah, that might be it then
<seb128> I've no hardware where compiz doesn't work
<pitti> vmare doesn't, and on my nvidia system it doesn't eitehr
<pitti> seb128: vmware :)
<seb128> I need to install that one day ;)
<seb128> I've no real use for it though
* mvo can reproduce it now
<seb128> can we boot an iso with the vmware-player package?
<pygi> seb128, not a regular iso
<pygi> there needs to be some additional files afaik
<pygi> vmx and stuff
<seb128> need a real vmware for that then?
<pitti> seb128: yes, workstation
<pygi> pitti, could he try with virtualbox?
<pygi> Should serve same purpose
<pitti> sure
<pygi> seb128, use virtualbox
<mvo> seb128: I think server can do it to, we have packages for it
<pitti> seb128: player can only start already existing machines
<pygi> seb128, it's open source, and you can start iso
<pygi> mvo, indeed, but virtualbox might be easier 
<pygi> seb128, http://www.virtualbox.org/download/1.4.0/virtualbox_1.4.0-21864_Ubuntu_feisty_i386.deb
<seb128> pygi: thanks
* pygi should package that for gutsy
<Hobbsee> pygi: the virtualbox people want to submit it themselves
<pygi> Hobbsee, o well.
<pygi> let them do it then 
<pygi> seb128, yw
<Admiral_Chicago> that would be good to have it in the repos, I distrust webpage's packages as a rule
<pygi> Admiral_Chicago, ^_^
<asac> pitti: can you reproduce bug 121228  ?
<ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [High,Confirmed]  https://launchpad.net/bugs/121228
<pygi> asac, wasn't that the guy using vanilla n-m?
<pitti> asac: I don't have an encrypted wifi here
<asac> pygi: yes but he could verifiy with our package as well ... and there are already lots of dupes
<pitti> pygi: no, we have so many dups about that that I don't believe that
<asac> pitti: i found something in gnome-keyring which might be related: bug 122502
<ubotu> Launchpad bug 122502 in gnome-keyring "[PATCH]  memory leak + error handling glitch in gnome-keyring-proto.c:gnome_keyring_proto_decode_find_reply" [Undecided,New]  https://launchpad.net/bugs/122502
<pitti> asac: well, there are some encrypted wifis from some neighbour; can I test it without knowing the passphrase?
<pitti> asac: I just had a try on a wpa2 network and entered a bogus passphrase, it doesn't crash here
<pitti> asac: and the dialog doesn't offer me to save it in the keyring (it probably wants to validate it first)
<stgraber> asac: You are the one working on compiz right ?
* Hobbsee wants a big "nuke $user from every ubuntu channel on freenode" button
<mvo> morning dholbach!
<Hobbsee> hi dholbach!
<dholbach> re
<dholbach> hi mvo :)
* dholbach hugs Hobbsee
* dholbach hugs thekorn_ too
* pitti hugs Keybuk 
* Hobbsee hugs dholbach :)
<pitti> mvo: so, what do you blacklist ATM? just vga|vesa|nv?
<pitti> mvo: ... |vmware?
* thekorn_ hugs dholbach
<mvo> pitti: vga|vesa|nv
<mvo> pitti: vmware does not make it through the glxinfo test
<asac_> sorry ... dsl hick-ups
<pitti> mvo: ah, cool
<stgraber> asac_: sorry, I didn't ping the right person it seems :)
<asac_> k
* Keybuk hugs pitti 
<pitti> mvo: ok, so we need to talk to LaserJock and wasabi about their failures
<Hobbsee> hiya Keybuk 
<mvo> pitti: that is why I'm so interested in people with failures, to know what glxinfo, xdpyinfo etc they have
<pitti> mvo: so, we probably have to confine it a lot in the future and just live with the fact that tribe2 is screwed for many people
<pitti> mvo: so the only thing that still worries me RC-wise on my list is that session hang
<pitti> dholbach: (for catching up): I watched gnome-session-properties while starting, and it needs a minute to connect to the session; that's what's blocking the splash screen and the logout dialog
<pitti> dholbach: (and blocking all subsequent programs which also want to be started in the session)
<mvo> clicking on the splash makes it go away for me
<dholbach> does reverting to the last gnome-session version help?
* mvo has a GSM_VERBOSE_DEBUG print is anyone is interessted
<pitti> mvo: right, but it doesn't fix the session connection hang of gnome-wm
<seb128> dholbach: not likely, usually those bugs are due to a program not registering correctly and making the session wait
<dholbach> seb128: ah ok
<pitti> mvo: ah, the '/bin/sh /usr/bin/compiz' process is due to /usr/bin/compiz forgetting to use 'exec' for running metacity
* Admiral_Chicago waits for his hugs.
<pitti> mvo: I just added that; it doesn't help the hang, though
<mvo> pitti: yeah, I noticed that too 
<Admiral_Chicago> oops, chanaged the background on the wrong bug report....
* LongPointyStick pokes in greeting
* LongPointyStick is BAAAACK!!!
* shawarma hugs Admiral_Chicago 
<shawarma> \0/
<pitti> mvo, seb128: is this reasoning correct: while gnome-wm is shown as connecting in gnome-session-properties, there is no gnome-wm process, thus /usr/bin/gnome-wm already finished and exec'ed compiz; there is no compiz process (after fixing the exec line from above), so it already exec'ed metacity
<seb128> I think it is
<pitti> mvo, seb128: metacity process is running, but it doesn't have a --sm-client-id argument
<seb128> not good
<pitti> can that be the fault? doesn't /usr/bin/compiz need to pass the session ID to metacity or so?
<seb128> could be yes
* pitti pokes
<Admiral_Chicago> thanks for the hug shawarma
<Admiral_Chicago> now I can sleep easy
<pitti> hm, "exec 2>/tmp/out; set -x" should work, right?
* asac hugs Admiral_Chicago too
<StevenK> Hum, doesn't that reexec the current script?
<Admiral_Chicago> hehe, asac i've got a clean install of kubuntu and ubunt feisty.
<Admiral_Chicago> 2 days old each so if you need testing, on a clean build ler mt know
<pitti> seb128: does "--sm-client-id default0" look like a valid SID?
<asac> Admiral_Chicago: if you can, upgrade to gutsy and see if gnome-applet crashes for your wifi setup ;)
<pitti> StevenK: ho, why?
<pitti> no, even
<StevenK> pitti: I thought it did, is all.
<Admiral_Chicago> its not my computer, its my sister's laptop. also, still not connecting very well to the internet
<seb128> pitti: yes
<pitti> seb128: cause in my production system they have names like 117f000001000118252706300000156690007
<pitti> so /usr/bin/gnome-wm passes it correctly to /usr/bin/compiz
<seb128> pitti: /usr/share/gnome/default.session uses "gnome-wm --sm-client-id default0"
* seb128 hugs pitti
<seb128> bug #122519
<ubotu> Launchpad bug 122519 in deluge-torrent "deluge cra shed with ImportError in find_class()" (dup-of: 121836)" [Undecided,New]  https://launchpad.net/bugs/122519
<ubotu> Launchpad bug 121836 in deluge-torrent "deluge crashed with ImportError in find_class()" [Undecided,New]  https://launchpad.net/bugs/121836
<seb128> " 	 Apport retracing service (275)  	marked as duplicate  	 	121836"
<seb128> autoduping in action ;)
<Hobbsee> woot!
<mvo> pitti: I have the fix, its indeed the missing argument passing :/
<pitti> mvo: oh, I am this --><-- close to it as well; it forgot to pass "$@" in two places
<mvo> pitti: you gave me all the good clues :) but two places? where is the other one?
<mvo> pitti: FALLBACKWM_OPTIONS misses it
<pitti> mvo: ah, that would work, too :) I explicitly added it to the two places which call it
<mvo> pitti: want me to upload it right away or wait for reports on falures so that the blacklist/whitelist can be improved?
<pitti> mvo: please upload
<pitti> mvo: two uploads are cheap; it's CD respins which are expensive
<fabbione> cjwatson, evand: is parted maintained in bzr?
<pitti> mvo: so, adding $@ after the "--replace helped here
<mvo> pitti: cool, uploading the fix now
<shawarma> I have a really weird problem on the amd64 LAMP install..
<pitti> mvo: can you also add the three missing exec calls
<pitti> mvo: ?
<pitti> mvo: two on the last line and one in abort_with_fallback_wm()?
<mvo> pitti: sure, just reject my last upload then
<shawarma> libapache2-mod-php5 is not installed(!). apt-cache show libapache2-mod-php5 clearly says "Task: lamp-server". "apt-get isntall lamp-server^" says that all its packages are installed (but libapache2-mod-php5 is not on that list). wtf?
<pitti> mvo: rejected
* heno sees this bug in vbox too, but it installs fine apart from that
<mvo> pitti: the last line "compiz.real || metacity" would not work when I "exec compiz || metacity" AFAICS, only "compiz || exec metacity"
<StevenK> exec compiz || exec metacity ?
<shawarma> Won't work.
<mvo> I don't think that will work as intended
<pitti> mvo: "compiz.real || exec metacity"?
<mvo> the first "compiz" needs to stay
<mvo> yeah
<mvo> pitti: yes
<pitti> probably, yes
<pitti> ugly, but not the default case anyway
<mvo> pitti: I added the other two though, thanks!
<cjwatson> fabbione: no, just plain source packages
<pitti> darn, I missed to disable the publisher
<fabbione> cjwatson: ok thanks
<shawarma> Can someone with a clue lend me a hand with that libapache2-mod-php5 thing?
<pitti> mvo: wrt. blacklist, let's keep it that way for tribe-2 and put something into the release notes how to report errors
<pitti> shawarma: is it on the CD at all?
<mvo> pitti: ok, that sounds good. I will draft something
<pitti> mvo: do we have an easy way to disable compiz? (easier than hammering killall gdm?)
<shawarma> pitti: Yup.
<mvo> pitti: seb128 asked me to disable expose on click on the top-right corner. fix is trivial, do you want a upload for this too?
<pitti> mvo: what does it break?
<mvo> pitti: currently not :/ save graphics mode as it would use vesa and that makes compiz not run
<pitti> (except for being absolutely undiscoverable :) )
<shawarma> pitti: regardless, if apt-get install lamp-server^ says everything is installed, and apt-cache show libapache-mod-php5 says it's part of lamp-server, but it's not installed, by head blows up.
<seb128> pitti: go to the top-right, corner and click, instead of activating the session dialog you get this weird zoom
<mvo> pitti: people might get confused when trying to click on the logout button in the top-right. but it can wait after tribe-2 too
<pitti> seb128: ah, I see
<seb128> pitti: it just conflicts with the button
<pitti> seb128, mvo: fine for me
<pitti> mvo: is this in compiz as well?
<pitti> or another package?
<mvo> pitti: compizconfig0
<mvo> libcompizconfig
<mvo> :)
<pitti> mvo: ok, please get it in
<pitti> mvo: I cannot start another publisher before 11:40 anyway
<pitti> we have another window open for getting urgent fixes into the ubuntu CDs; if you have something, please speak up *now*
<shawarma> pitti: Well.. 
<shawarma> pitti: Not having libapache2-mod-php5 in a LAMP install is rather unfortunate.
<pitti> shawarma: I agree
<pitti> cjwatson: any idea about that tasks issue? ^
<shawarma> I have *no* clue why it doesn't work though.
<shawarma> cjwatson: Short version. libapache2-mod-php5 is not installed when choosing LAMP server on amd64 server CD. apt-cache show libapache2-mod-php5 says "Task: lamp-server", but "apt-get install lamp-server^" says all packages are installed (and it doesn't list libapache2-mod-php5)
<Mithrandir> shawarma: check the task headers on the CD?
<pitti> asac: the gnome-keyring fix doesn't happen to fix n-m by any chance? :)
<shawarma> Mithrandir: I assume you mean the Packages file on the CD.. It looks fine. It's got Task: lamp-server for libapache2-mod-php5.
<Mithrandir> shawarma: hm, ok, weird.
<shawarma> Mithrandir: Very much so.
<shawarma> Mithrandir: It worked fine on the i386 install.
<cjwatson> shawarma: I blame apt
<shawarma> cjwatson: That's even worse..
<asac> pitti: i hope it does ... because i found it when following the codepath in keyring ... howveer i don't have a tester atm :/
<cjwatson> libapache2-mod-php5 has Task: lamp-server in the archive too
<asac> anyone with encrypted wifi setup who sees nm applet crash ... step up :)
<pitti> does anyone have an encrypted wifi?
<cjwatson> mvo: help
<mvo> hello cjwatson, what is wrong?
<pitti> mvo: that's your tribe release From HELL
* pitti hugs mvo
<cjwatson> mvo: see shawarma's task comment above
* mvo goes back to bed
<asac> pitti: i will ask on -motu as well 
<shawarma> mvo: Short version: libapache2-mod-php5 is not installed when choosing LAMP server on amd64 server CD. apt-cache show libapache2-mod-php5 says "Task: lamp-server", but "apt-get install lamp-server^" says all packages are installed (and it doesn't list libapache2-mod-php5)
<fabbione> shawarma: hmm i am checking sparc. i have a LAMP server install just done.. but i might not have noticed that
<pitti> seb128: can you do the libcompizconfig change as well? mvo is a bit busy
<cjwatson> tasksel just calls apt-get install TASK^, BTW
<mvo> shawarma: ok, I can debug this, I need a current server CD? it seems to work on my regular system
<seb128> pitti: looking at it
<shawarma> fabbione: Alright. I just tossed a .php file with '<? phpinfo(); ?>' in /var/www.
<shawarma> mvo: amd64.
<shawarma> mvo: Works fine on i386.
<shawarma> mvo: Thaaat's right. 
<fabbione> shawarma: yeah.. i will just check the config files..
<mvo> shawarma: downloading a image then, it seems to be working on my amdt64 workstation
<pitti> hm, sudo apt-get install lamp-server^ fetches libapache2-mod-php5 here, too; something CD specific then
<mvo> seb128: please bzr update, I commited the changes, just did not test them .) and was wondering if ctrl-f9 will still invoke scale and why compiz has a different default key thatn my installed system
<shawarma> pitti: It still doesn't work after apt-get update..
<fabbione> shawarma, mvo: sparc looks good
<fabbione> ii  libapache2-mod 5.2.3-1ubuntu1 server-side, HTML-embedded scripting languag  
<fabbione> (and checked also config files)
<mvo> shawarma: downloading, no worries - we will hunt that one down :)
<shawarma> It looks fine on my workstation as well.
<pitti> shawarma: s/LAMP/LAM/ in the description? :)
<mvo> HAHA
<pitti> or just devote it to Perl
<shawarma> pitti: or passwd
<shawarma> :)
<pitti> "Tribe 2 now greatly improves the security of the default LAMP install"
<StevenK> Bwahahaha
<fabbione> pitti: ROFL
* mvo grumbles that InstallTask is about the only thing in apt that you can't pass -o DebugMeHarder
* pygi quickly hacks it in for mvo 
<pitti> asac: hm, now I wonder whether I should build compiz and then new CDs right now, or wait a little on that bug fix
<asac> pitti: maybe i have found a tester
<pitti> asac: do you have a rough ETA? did you test the fix with other gnome-keyring applications to check for regressions? like gnome-gpg and mounting encrypted file sytems?
<asac> pitti: please wait a few ... if have testers that definitly see the crash
<asac> dholbach for instance :)
<pitti> asac: ok; this is highly important, so delaying for an hour is justified
<asac> pitti: i don't use encrypted fs here ... gnome-gpg I can test ... but what do i do with that?
<dholbach> asac: I can't test it right now
<asac> dholbach: yeah ... but you will go home soon :)
<pitti> asac: do you have amd64 packages somewhere? I can test both here
<asac> pitti: i can push in a minute
<pitti> asac: or debdiff, or patch; anything
<asac> debiff is in bug
<pitti> ah, right
<pitti> asac: I'll build it here then
<asac> pitti: do you have bug number
<asac> ?
<pitti> asac: yes, got it from backscroll
<asac> its out of my clipboard :/
<asac> great
<pitti> bug 122502
<ubotu> Launchpad bug 122502 in gnome-keyring "[PATCH]  memory leak + error handling glitch in gnome-keyring-proto.c:gnome_keyring_proto_decode_find_reply" [Undecided,New]  https://launchpad.net/bugs/122502
<ogra> OMG
<pitti> hey ogra
<ogra> 20070626.2 has 22M free
<pitti> asac: I'll clean it up to be a proper patch
<ogra> GAH
<pitti> ogra: is that a catastrophe?
<ogra> i could have included the -dri stuff
<pitti> ogra: NB that I need to rebuild the edubuntu CDs
<asac> pitti: ?
<ogra> well, after tribe2
<pitti> ogra: your debdiff patches it inline
<ogra> ??
<pitti> ogra: we have an updated compiz and libcompizconfig which affects edubuntu, too
<asac> pitti: what is the problem with that patch?
<ogra> ah, ok
<pitti> ogra: hanging splash screen and broken logout dialog
<pitti> ogra: so if you want to change edubuntu-meta for -dri, please do it right now
<pitti> asac: it should be a debian/patches/ thing
<asac> pitti: keyring has no patch system afaik
<asac> pitti: which is why i did it that way
<ogra> well, if thats still an option i'll re-add ist to ldm ....
<pitti> asac: include /usr/share/cdbs/1/rules/simple-patchsys.mk
<pitti> asac: it just doesn't have patches ATM :)
<ogra> err. ltsp-client sorry
<asac> yeah ... take the patch from upstream bug ... or just strip the changelog
<pitti> ogra: hm, I'd really prefer if you added it to desktop-recommends
<pitti> ogra: see the corresponding change in the ubuntu seeds
<ogra> pitti, then it doesnt get installed on thin clients ... hmm, ok i'll find a workaround for that later
<pitti> ogra: oh, I see
<pitti> ogra: you don't have a metapackage with Recommends: for thin clients, do you?
<ogra> i could make one ... 
<ogra> note thats not urgent for tribe2 or something
<pitti> ogra: adding it to ldm is a bit bad since then you cannot uninstall it any more if you don't need it
<pitti> ogra: ok; maybe fill them with langpacks instead then :)
<ogra> no, it was a dep of ltsp-client .... 
<ogra> which means you install it only in thin client chroots
<ogra> ltsp-client inst installable on normal systems
<ogra> *isnt
<ogra> i'll add -dri to have it on the cd ... it just doesnt help the ltsp case this way atm
<ogra> s/add -dri/add -dri to desktop.recommends/
<ogra> hmm
<ogra> does anyone else see a directory here ?
<ogra> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.gutsy/
<pitti> asac: that patch looks straightforward at least
<ogra> (i know there is a typo in the url, but i dont think i should see a dir)
<pitti> ogra: no, it's 'desktop'
<pitti> ogra: recommends come from packages in parentheses
<pitti> ogra: look into the ubuntu seeds
<ogra> i know
<ogra> sorry, my fault
<pitti> ogra: that dir just has a .bzr in it, no working tree
<ogra> still, i should likely rather see a launchpad page or so ...
<ogra> not a plain apache dir listing
<pitti> ogra: use codebrowse then :)
<cjwatson> ogra: it's always been like that. maybe you're thinking of code.launchpad.net
<ogra> cjwatson, yes. thats where i came from ... and thought i could just change the url to get to the LP page of the branch
<ogra> which then got me to that page
<txwikinger2> Which package takes care of setting the env variables for the shell ?
<cjwatson> you can, s/bazaar/code/
<cjwatson> txwikinger2: the shell itself
<txwikinger2> so bash for bash?
<cjwatson> oh and libpam-runtime does a couple of them
<cjwatson> but as a general rule packages shouldn't require environment variables to set in order to work properly, so there isn't a need for too much fancy stuff there
<cjwatson> s/to set/to be set/
<asac> pitti: yeah the patch definitly fixes bugs ... maybe i have a tester in -motu ... so stay tuned
<pitti> asac: building package now, and giving it some tests
<pitti> mvo, seb128: is either of you tackling the libcompizconfig change?
<seb128> pitti: I'm looking at it
<seb128> the change made by mvo seems to be not working, investigating why
<mvo> seb128: did you restarted compiz? it seems to be needed 
<seb128> mvo: yes, I restarted the session and removed .gconf/apps also
<StevenK> Sigh.
<mvo> hrm :/
<StevenK> Neither VirtualBox or VMware seem to support long mode.
<pitti> seb128: new gnome-keyring works fine for gnome-gpg and encrypted gnome-mount here
<pitti> erm, I mean asac ^
<pitti> seb128: sorry, autofingers for m/gnome/ :)
<asac> pitti: ok lets wait for feedback on nm applet crash ... thanks
<fabbione> pitti: the tracker doesn't allow me to add an extra entry for stuff already tested but Niagara is good too
<asac> pitti: motu is testing atm :)
<pitti> fabbione: you can change it in the comment field; but thanks
<pitti> asac: \o/
<Mirv> carlos: could you check bug 106756, ie. feisty translation template problem? it'd be nice to get translations for the next update.
<ubotu> Launchpad bug 106756 in gnome-app-install ""Search for suitable codec" dialog not translated/translatable" [Undecided,Fix committed]  https://launchpad.net/bugs/106756
<pitti> asac: mind if I just upload the package myself? I gave you full credit in the changelog :)
<pitti> asac: but I rather have it properly patchified and such
<asac> pitti: go ahead ... i am not a credits whore
<asac> pitti: close the LP bug :)
<asac> in changelog
<pitti> asac: ok, I uploaded it and just keep it in the unapproved queue, to reduce the response time
<pitti> asac: I did
<pitti> asac: well, I closed #122502, let's close the other one manually
<shawarma> mvo: Crap, it's reproducable.
<carlos> Mirv: let me see...
<pitti> shawarma, mvo: I wonder why this only affects amd64 then; is there something different on the CD itself?
<mvo> shawarma: I can reproduce it here too, look at it now
<shawarma> mvo: If I remove the cdrom from sources.list, and do apt-get install lamp-server^ it wants to pull in libapache2-mod-php5... Interesting.
<mvo> shawarma: oh? that is indeed interessting
<shawarma> mvo: And if I put it back in, it goes back to not wanting to install it. It's definitely a CD-related issue.
<carlos> Mirv: bug updated
<Mirv> carlos: thanks.
<asac_> pitti: tester says it doesn't cure him :/
<pitti> asac_: bah
<asac_> unfortunate :)
<seb128> mvo, pitti: I figured what was the compiz problem, testing change now
<pitti> asac_: so, what would be so wrong about checking for NULL in the applet?
<asac_> pitti: i think it would cure the crash ... but it will hide the real problem (if there is any)
<pitti> asac_: that is easy and straightforward and at least avoids the crash; question is whether it actually makes those wifis work, of course
<mvo> seb128: what exactly was the problem (just curious)
<asac_> pitti: right ... let me check if the code in applet has changed
<pitti> asac_: hiding problem> right, but if it makes n-m work for tribe-2, it's more than good enough :)
<mvo> seb128: or was it local to your install only?
<asac_> pitti: maybe its really an applet regression
<pitti> asac_: can you ask your tester to give this a whirl?
<seb128> mvo: compiz-0.5.1+git20070618/debian/compiz-gnome.gconf-defaults
<pitti> asac_: we don't have time to fix the real problem in the keyring now
<seb128> mvo: 
<seb128> /apps/compiz/plugins/scale/allscreens/options/initiate_edgebutton       1
<asac_> pitti: yes ... have to provide packages though as he cannot build without net ... so he is on sid atm
<asac_> :)
<seb128> /apps/compiz/plugins/scale/allscreens/options/initiate_key              <Control>F9
<pitti> asac_: he needs i386?
<asac_> pitti: let me look at the applet code of 0.6.4 ... then i fix and build package for him
<asac_> pitti: no amd64
<asac_> fortunately :)
<pitti> asac_: ah, fine; I can help out with building then, too
<pitti> asac: want me to build test packages with that patch?
<asac> pitti: its not a regression in applet.c ... old code just dereferences without NULL check as well
<shawarma> mvo: You're on the lamp-server bug? If so, I'll try to get some work done. :)
<asac> pitti: you do your rm stuff ... i build
<pitti> asac: ok, appreciated
<mvo> shawarma: yes, I have a fix here, but I currently trying to understand why its triggered in this situation
<shawarma> mvo: What's the fix?
<mvo> shawarma: it looks its a bug in the regexp that scans the pkgRecords for the task, but I wonder why it is triggered for exactly *this* package
<mvo> and only on amd64
<pitti> mvo: are you sure that the patch fixes the bug?
<pitti> mvo: I need to hurry up a little, upload to new CDs takes 2 hours
<mvo> pitti: I'm pretty confident, but give me 10-15 min to be sure
<pitti> mvo: alright, thanks
<seb128> mvo: could you help me with bzr,
<seb128> ?
<seb128> mvo: I've the changes ready for compiz but commit doesn't work, cf query :/
<pitti> seb128: can I help you?
<pitti> hey jono
<yetanothername> /exit
<pitti> ogra: so, you don't want another edubuntu-meta after all?
<jono> heya pitti
<ogra> pitti, right
<asac_> pitti: pushed to bzr and uploaded
<asac_> pitti: its verified to fix our issues
<asac_> and wireless works
<pitti> asac_: yay, does it work? he can connect to the wep wifi?
<asac_> sorry was offline again :(
* pitti gives asac_ a big hug
<asac_> pitti: yes 
<asac_> pitti: previously it crashed ... not it works
<asac_> pitti: package is already uploaded 
<pitti> asac_: so, I propose to add an open gnome-keyring task to that bug, just to not forget about the root cause
<pitti> and close the applet one with the upload
<asac_> pitti: right ... how can i refer to the existing gnome-keyring bug?
<pitti> asac_: is there one?
<asac_> ah right
<asac_> :)
<asac_> of course there isn't
<asac_> sorry
<asac_> :)
<pitti> asac_: accepted; so we'll close the apport one manually then
<asac_> pitti: yes
<seb128> pitti: that's ok, thanks, mvo replied in query
<asac_> pitti: btw, can we change auto-dupe detection like this: search for dupe in database ... if there is a bug either use that as master ... or if that bug is already marked as dupe use the original one?
<iwj> seb128: When we did that disk full testing at uds, did you fill the disk as a normal user or as root ?
<pitti> asac_: does it need that gnome-keyring fix, too? I wonder whether I should accept it now
<seb128> iwj: root
<asac_> pitti: in this way we can just merge in the first crash report into existing reports
<StevenK> pitti: Are we still in that window?
<asac_> without e.g. needing to redupe 190 bugs for some firefox crashes
<pitti> asac_: yes, I think that's possible; can you please create an apport bug about that?
<asac_> pitti: will do
<iwj> seb128: I think that something must get removed during reboot then.
<asac_> pitti: just apport?
<pitti> StevenK: closing rapidly, as soon as seb128 uploads the compiz fix, I'll start the publisher
<seb128> iwj: why?
<pitti> asac_: yes, that's fine
<iwj> I just did a similar test (but with the tmpfs on /tmp fix) and it's pretty badly broken.
<StevenK> pitti: Ah. RAOF_ mentioned getting kvm fixed for tribe-2
<StevenK> RAOF_: How long to get it ready for upload?
<pitti> StevenK: if you have an existing tested patch, please show it to me and get it uploaded ASAP
* RAOF_ was just about to say that.  The bug in question is #122113
<pitti> looking
<RAOF_> StevenK: It's done, just needs pushing.
<StevenK> RAOF_: Point me at the source.
<RAOF_> bug #122113
<ubotu> Launchpad bug 122113 in kvm "[Merge]  Please merge kvm-28-4 from Debian Unstable" [Wishlist,Confirmed]  https://launchpad.net/bugs/122113
<pitti> RAOF_, StevenK: oh, that's universe and not subject to freeze; please go ahead and upload
<StevenK> Ask a stupid question...
<StevenK> pitti: Aye, will do in a few seconds.
<RAOF_> StevenK: That's what you're after, yes?  If you wanted to be super thorough, you might want to test it on i386 :)
<iwj> seb128: Indeed, my tests confirm: if you fill the disk up with the system booted and then reboot, it works fine.
<StevenK> RAOF_: I don't have a i386 that has hardware virt.
<pitti> asac: not sure whether you saw this: <pitti> asac_: does it need that gnome-keyring fix, too? I wonder whether I should accept it now
<StevenK> Even my amd64 doesn't, sadly.
<iwj> But if you shut down, and then mount the fs from another install and fill it, and then boot, it breaks badly.
<pitti> asac: i. e. did your tester check it with the updated gnome-keyring or with the archive one?
<RAOF_> pitti: I was the (at least one of the) tester.  I tried it with both, and it doesn't seem to need the updated gnome-keyring
<pitti> RAOF_: ah, thanks
<RAOF_> asac's probably lost somewhere in the labarynth of his isp :/
<StevenK> Heh
<pitti> seb128: so bzr is not blocking you any more? :) good
<StevenK> RAOF_: Closes: -> LP:
<seb128> pitti: no, I was trying to checkout from code.launchpad.net which doesn't work
<StevenK> RAOF_: Want me to fix that? The rest looks okay.
<RAOF_> StevenK: What?  It closes #122113, 119254.
<StevenK> RAOF_: (Closes: #bug) is a Debian-ism. It's (LP: #bug)
<seb128> pitti, mvo: compiz uploaded
<RAOF_> StevenK: Aaargh.  Yes.  Please fix that!
<mvo> seb128: thanks
<seb128> mvo: you're welcome
<RAOF_> StevenK: You should probably also add (LP: #122113)
* pitti hugs seb128 
<mvo> pitti: apt is test-building here, should be ready for upload RSN
* StevenK nods.
<pitti> mvo: ok; do you want to have it on the ubuntu CDs as well? If it's just for the server CDs, I'd rather start a publisher now
<pitti> mvo: then you can have more time for tests
<mvo> pitti: its a bit of a corner case, so server should be fine
<pitti> mvo: ok, putting it only on server then
<pitti> seb128: the empty line in debian/compiz-gnome.gconf-defaults doesn't hurt, no?
<seb128> pitti: no, it doesn't, it was already there
<seb128> lunch time
<pitti> seb128: enjoy!
<cjwatson> seb128: checkout from code.launchpad.net is supposed to work, I think
<cjwatson> might want to check with the LP team
<pitti> cjwatson: it does
<StevenK> pitti: kvm uploaded, accept at your leisure.
<jwendell> dholbach, a doubt:
<jwendell> dholbach, i'm writing a vnc client well integrated to gnome, which i guess will not get in time to 2.20
<jwendell> dholbach, maybe it'll be as part of vino, maybe not
<dholbach> if not, we could package it and have it in universe, so people can test it and play with it
<dholbach> what do you think?
<jwendell> dholbach, yep, that's my doubt ;)
<dholbach> what doubt do you have?
<jwendell> dholbach, if it could be packaged into universe
<dholbach> no problem
<dholbach> once you have a release tarball, file a needs-packaging request and maybe ask on ubuntu-motu@ to find somebody to package it - if you don't want to do it on your own
<dholbach> https://wiki.ubuntu.com/MOTU/Packages/Candidates for more info on 'needs-packaging'
<jwendell> dholbach, i prefer to concentrate in development
<dholbach> right-o
<jwendell> dholbach, upload a new package is boring :(
<dholbach> alright, well then file a bug and ask people on ubuntu-motu@ for help with that
<jwendell> dholbach, ok, thanks!
<mvo> pitti: apt is uploaded, I got for lunch now
<seb128> pitti: does "bzr checkout sftp://$YOUR_LP_ID@code.launchpad.net/~compiz/compiz/ubuntu/" work for you?
<asac> seb128: should it? pitti isn't in compiz team
<seb128> asac: well, I'm in the compiz team and that timeout, using bazaar.launchpad.net for the checkout works fine though
<shawarma> cjwatson: Why do we stick with openssh 4.3?
<asac> seb128: ah ... yes code.lp.net never worked for me iirc
<shawarma> cjwatson: I'm an idiot. Never mind.
* Hobbsee waves
<shawarma> Hi, Hobbsee!
<asac> hi Hobbsee 
<cjwatson> shawarma: we don't ;-)
<Hobbsee> :)
* shawarma hugs himself
<fabbione> hmmmm
<fabbione> something has changed behavior...
<shawarma> It's Hobbsee. She's been here for ten minutes and haven't poked anyone with her scary stick yet.
<pitti> seb128: ah, I usually use 'bzr get http://code....', that works fine
<Mithrandir> she's not scary, she just pretends to be. :-P
<seb128> pitti: you can't commit then though
<pitti> mvo: thanks!
<pitti> seb128: right, you need to use bzr push with an URL then; I'm not sure if I ever tried to push to code.lp.net
<pitti> seb128: hm, my branches have 'publish to branch: sftp://bazaar'
<seb128> pitti: use bazaar.launchpad.net I can checkout and then commit
* Hobbsee pokes Mithrandir repeatedly
<Hobbsee> shawarma: that's because i was grabbing dinner as well, and am dealing in release stuff.
<seb128> pitti: I don't want to branch
* Hobbsee attacks shawarma with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!  so he doesnt feel left out
* pygi eats Hobbsee 
<pitti> seb128: I usually do, so that I can commit offline and push in one chunk; but that's entirely up to your preference
<shawarma> Um... yay? :/
<shawarma> :)
* Hobbsee shrugs off pygi's attempt
<Hobbsee> Mithrandir: you're just disappointed that you dditn get bashed up at UDS.
<pygi> Hobbsee, ;)
<seb128> pitti: well, I wanted to do a 3 lines changes on compiz
<pitti> seb128: right, checkout might be more comfortable then
<shawarma> cjwatson: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/31969 ..  Why would we even consider this for openssh? Surely denying users with short passwords access is PAM's job?
<ubotu> Launchpad bug 31969 in openssh "Small password should not log in" [Wishlist,New]  
<asac> pitti: i saw that some packages use code.lp.n in control as bzr reference ... i use bazaar.lp.net in my packages (or better of those of my motu student) ... which way to go
<asac> (i assume we should use the url that you can run bzr branch with)
<Hobbsee> shawarma: :P
<Mithrandir> Hobbsee: ;-)
<pitti> asac: bzr branch/get works perfectly with http://code, and it's more convenient for clicking on and watching in firefox
<fabbione> Keybuk: do you happen to remember if you did change behavior of 91-skip-whole-disk.patch when merging?
<fabbione> Keybuk: AFAIR we did it so that the wholedisk decive was always hidden
<fabbione> Keybuk: but it seems like they are there again
<asac> pitti: hmmm ok ... thought it never worked for me ... but maybe i didn't try hard enough :)
<Keybuk> fabbione: I should not have changed the behaviour ... I left your patch intact
<cjwatson> shawarma: openssh-server ships the PAM configuration used by sshd; and sshd might reasonably want to have different authentication requirements from e.g. login since it's exposed to the network
<Keybuk> (and it's since been merged upstream)
<Keybuk> is the sysfs attribute there as expected
<Keybuk> it may be that kernel behaviour changed, or udev behaviour changed, in the interpretation on that rule
<shawarma> cjwatson: True. So it's a discussion of whether we should do so by default?
<cjwatson> shawarma: mostly I just reopened it because I object to the meme that wishlist bugs should be closed in favour of specifications
<fabbione> Keybuk: i don't recall if we were hiding the entire partition from the system (i am pretty sure we did) or just the uuid symlink
<shawarma> cjwatson: I see.
<Keybuk> just the uuid symlink
<fabbione> hmm ok
<shawarma> cjwatson: I can put a comment in the pam conf saying how to limit access for users with short passwords...
<Keybuk> the modification was to the persistent storage file
<fabbione> then it's os-prober being more anal...
<fabbione> yeps..
<fabbione> all good
<ion_> I found out why beryl was very smooth but compiz was jerky (low framerate, pauses in movement): i needed to run compiz --indirect-rendering. It might only be subjective, but it almost feels like the fresh version of compiz is even smoother than beryl.
<ion_> I guess i should take a closer look at the compiz wrapper to see why it doesnt pass --indirect-rendering automatically.
<shawarma> meh
* shawarma -> lunch
<ion_> I reported it as bug #122562.
<ubotu> Launchpad bug 122562 in compiz "The frame rate is low, unless using --indirect-rendering" [Undecided,New]  https://launchpad.net/bugs/122562
<asac> pitti: on bug 122393 the auto-retracers failed miserably. it was ment as a testbug for apport hooks test and is a dupe of bug 72018
<ubotu> Launchpad bug 122393 in firefox "firefox-bin crashed with SIGSEGV in raise()" [Undecided,Invalid]  https://launchpad.net/bugs/122393
<ubotu> Launchpad bug 72018 in firefox "MASTER Firefox Crash [@gtk_style_realize]  [@nsFilePicker::Show] " [High,In progress]  https://launchpad.net/bugs/72018
<asac> pitti: i will ask hjmf to retrace this manually ... to see if we get different results
<mvo> ion_: let me check
<mvo> ion_: do you have numbers? can you please install compiz-fusion-plugins-extra and enable the "benchmark" plugin with compiconfig-settings-maanager? 
<computa_Mike> Having problems compiling a device driver - is this the right place?
<mvo> ion_: and then compare the performance with and without the option set?
<ion_> mvo: Will do.
<mvo> ion_: you can enable the benachmark plugin with super (windows) - f12
<computa_Mike> Am I in the wrong forum?
<dendrobates-bbl> shawarma: I'll be covering from 14:00 to 23:00 gmt.  That should give us some good tz coverage.
<Pici> computa_Mike: This isnt really a support channel.
<ScottK> computa_Mike: Try #ubuntu
<pitti> asac: only new bugs will be considered as a duplicate; 72018 is way too old
<computa_Mike> ok - thanks
<asac> pitti: no
<asac> pitti: look at the backtrace
<ion_> mvo: --indirect-rendering: 59.9 FPS when idle, 55  59 when typing to this terminal, as well as when switching between workspaces rapidly. The benchmark plugin itself seems to slow everything down quite a bit. My screens refresh rate is 60 Hz. Without --indirect-rendering: about 27  28 FPS when idle, 23  27 when typing. Down to 15 when switching between workspaces rapidly.
<asac> pitti: (btw, this bug is an example why i want the auto-dupe improvement) :)
<mvo> ion_: that sounds good, could you please put that into the bugreport? and what driver you are using and what gfxcard
<ion_> mvo: Will do. I already mentioned the driver and the card in the report.
<asac> pitti: the backtrace is just garbage
<mvo> ion_: right, sorry
<asac> pitti: same for bug 122525
<ubotu> Launchpad bug 122525 in firefox-granparadiso "firefox-granparadiso-bin crashed with SIGSEGV in __kernel_vsyscall()" [High,Incomplete]  https://launchpad.net/bugs/122525
<pitti> asac: oh, I see
<pitti> asac: WARNING: /lib/tls/i686/cmov/libc-2.5.so is needed, but cannot be mapped to a package
<pitti> asac: and lots of similar stuff
<asac> why?
<pitti> asac: WARNING: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so is needed, but cannot be mapped to a package
<pitti> asac: that looks relevant as well
<pitti> asac: I don't know
<asac> pitti: lets see what hjmf gets
<asac> pitti: i have the feeling that his retrace looks good
<asac> ... as always
<asac> :)
<pitti> asac: something broken in the Contents.gz parsing, I need to investigate this more closely
<asac> pitti: anything i can do to boost the improvement in auto-dupe detection?
<mvo> heno: how do the iso-testing reports with regard to compiz-by-default look so far?
<asac> i really have a bad feeling about un/re-duping
<asac> later
<pitti> asac: it would require to scan all existing apport bugs, get their stack traces, and feed them through the dup checker; quite a lot of effort (entirely doable, though)
<asac> pitti: no
<asac> pitti: i say: just do as now ... but before you mark as dupe you look if the bug found in crash db has a duplicate marked
<asac> pitti: in that case use that bug
<asac> s/has a duplicate marked/has been marked as duplicate/
<pitti> asac: ah, right, that's much easier; as I said, please file an apport bug about this, I'll see to it after tribe
<mvo> ion_: if you haven't hacked on the compiz.wrapper script already, I can give it a go now to add --indirect-rendering
<asac> pitti: ok ... i filed a bug already
<luisbg> what's the difference betwen trying this https://isotesting.stgraber.org/ and tomorrow's official release of tribe 2?
<asac> pitti: just thought i might help ... or hilario (as he likes to do python stuff)
<heno> mvo: seems to have improved after yesterday's fixes; works for me on vbox now for example
<ion_> mvo: I havent modified it.
<ion_> mvo: Comment posted to the report.
<pitti> luisbg: difference is that we can still change the CDs (and will) for fixing critical bugs
<pitti> luisbg: but we depend on people testing the candidates and telling us about errors
<StevenK> ... interesting.
<pitti> luisbg: you can use rsync to upgrade today's images to the final ones tomorrow
<StevenK> The alt installer shouldn't prompt where to install grub to, right?
<pitti> asac: oh, sure, if you feel like playing with the code, please go ahead :)
<heno> we really need to make that distinction more clear somewhere
<pitti> StevenK: hm, only in expert mode normally
<asac> pitti: will let you know ;)
<heno> the mirrors were asking for their tribe2 ISOs too :)
<luisbg> pitti, ok cool, do you know anything about a network manager bug I've heard?
<StevenK> pitti: Not expert mode.
<pitti> luisbg: crash on connecting to WEP/WPA networks?
* ogra pokes d-i
<cjwatson> StevenK: it can do, depending
<StevenK> cjwatson: Worth a bug report?
<pitti> ogra, heno, *: FYI, I trigger new ubuntu and edubuntu CDs now
<cjwatson> StevenK: not typically
<luisbg> pitti, yeap
<cjwatson> it's a legitimate case
<ogra> tsk, i installed to a USB disk but had a grub error on the USB port it was plugged in after install ... i only could boot after changing the port
<pitti> luisbg: that should be fixed on the CDs I'll build now
<StevenK> cjwatson: Okay, cool.
<luisbg> pitti, let me know when they are built =)
<luisbg> pitti, so I can test them today
<luisbg> hello _MMA_ =)
<pitti> luisbg: will do
<_MMA_> Hola
<cjwatson> StevenK: if it can't figure out how to create boot stanzas for everything on the disk, it'll jump straight to the manual prompt for a boot device
<mvo> ion_: --indirect-rendering should be working now, I just commited a fix for it to bzr
<luisbg> pitti, will open a new page in the laptoptesting wiki page for my laptop and gutsy... cool?
<StevenK> cjwatson: Right, fair enough.
<pitti> luisbg: sounds good (I'm not familiar with the structure of those pages, though)
<luisbg> ok ok
<luisbg> dholbach, ping
<dholbach> luisbg: pong
<luisbg> dholbach, that was fast! LOL
<dholbach> was that all? :)
<luisbg> dholbach, you didn't attend the derivatives meeting on sunday
<dholbach> luisbg: I know - I said so by mail, that I wouldn't have time on sunday - but I read the minutes
<iwj> Oh dear, I need to wait for glibc to build again.
<luisbg> dholbach, ahhh ok cool then
<luisbg> dholbach, you have read we created an irc channel then
<iwj> So much for getting that trace data today.
<davmor2> hi devs.  Just doing iso-testing 26.2 nm-applet is crashing out horribly I have an apport trace and am about to report the bug is there any other info you need for it?
<dholbach> luisbg: yeah, I did - I was just busy with all the other irc channels I'm in already
<seb128> davmor2: I think there is already a stack of duplicates of nm crashers
<luisbg> dholbach, I understand, don't expect you to be in it 
<iwj> pitti: FAOD, my sysvinit upload, just done, does not need to go into Tribe 2.
<pitti> davmor2: with 90% probability it's the bug that is fixed in the archive now
<luisbg> dholbach, just wanted to know if you have seen the small progress =)
<pitti> davmor2: can you please dist-upgrade and check again?
<seb128> davmor2: is that bug #121228?
<ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [High,Confirmed]  https://launchpad.net/bugs/121228
<pitti> iwj: noted
<dholbach> luisbg: alright - but I'm very happy the meeting went all right
<luisbg> dholbach, there was more attendance than I expected, to be sincere
<pitti> davmor2: you can dist-upgrade on the live CD as well, FYI
<dholbach> luisbg: I'm sure the next one will be even better
<luisbg> dholbach, yeah, got to decide when is that happening, will send an email this sunday for that, we have to decide the frequency of the meetings
<davmor2> pitti:  works on the cd fails after install
<davmor2> I think it is an issue with nm connecting to keyring
<pitti> davmor2: dist-upgrade on the installed system and restart your session -> does that help?
<dholbach> luisbg: maybe we should make a call for agenda items before we decide on the meeting
<pitti> davmor2: please note that you need to have archive.u.c. in apt sources; a mirror won't work
<pitti> davmor2: that's the bug we just fixed
<luisbg> dholbach, yeah true
<davmor2> pitti: okay I'll get back to you
<pitti> asac: hm, I wonder why that n-m upload didn't close the bug
<seb128> pitti: because the upload is network-manager-applet and the task is on network-manager
<pitti> asac: ah, did you close #121228 or #122385?
<seb128> the components don't match
<pitti> seb128: so he probably closed #121228
<seb128> yes
<seb128>    * debian/patches/01_static_network-admin.patch: fix by Peter
<seb128>      Clifton; adding NULL check to stop nm-applet from crashing
<seb128>      and make encrypted wifi work. (LP: #121228)
<dholbach> luisbg: I think firstly we should update the wiki and only have items in it, we're actively following
<dholbach> luisbg: and then go from there - lay out a structure for the knowledge base and ask people to help us filling the gaps
<luisbg> dholbach, OK, I finish my last exam on saturday
<dholbach> take your time with that :-)
<luisbg> dholbach, I will day a major wiki clean up and organization on sunday
<dholbach> and luisbg: all the best!
<dholbach> rock on :-)
<luisbg> dholbach, thanks =)
<pitti> seb128: I mangled the bugs accordingly; I also added a gnome-keyring task
<seb128> pitti: k
<pitti> heno, luisbg, bdmurray, mvo, all: new ubuntu alternates are up for testing: http://cdimage.ubuntu.com/daily/20070627/
<luisbg> pitti, cool, will give it a try in like 2 hours
<ion_> mvo: When the script reaches build_args, $INDIRECT is 1.
<pitti> luisbg: you might want to wait for the new live CDs
<naufraghi> hello!, some hint to debug a qt4 app using libqt4-debug package?
<davmor2> pitti: just downloaded a nm-gnome update is that the right one
<pitti> davmor2: yes
<pitti> erk, since when do we ship xterm by default? and, much more importantly, why does it appear in apps -> system tools?
<luisbg> pitti, oops, when are the live ones coming?
<pitti> luisbg: maybe 30 minutes
<luisbg> pitti, awesome
<pitti> luisbg: testing live is easier wrt. testing network-manager and compiz, but testing alternates is appreciated, too, of course
<davmor2> pitti: 0.6.5-0ubuntu4 correct
<mvo> ion_: oh? check_tfp() should set that INDIRECT=0 if LIBGL_ALWAY_INDIRECT is set
<pitti> davmor2: confirmed
<heno> pitti: posted
<luisbg> pitti, I understand
<davmor2> pitti: working but I'll just try one more reboot to make sure
<pitti> mvo: ah, apt has built, publishing binaries now
<ion_> mvo: glxinfo | grep GLX_EXT_texture_from_pixmap succeeds, so check_tfp doesnt touch INDIRECT.
<pitti> ogra, heno, LaserJock: new edubuntu alternates up for testing: http://cdimage.ubuntu.com/edubuntu/daily/20070627/
<seb128> pitti: have autosyncs stopped already?
<pitti> seb128: well, they need to be driven by hand anyway
<seb128> pitti: that I know, but we have sync request about non ubuntu versions
<seb128> I'm wondering if I should sync them manually
<pitti> seb128: ISTR that we previously stopped them at UVF, but we have a DebianImportFreeze on the schedule now, which is already past; Keybuk?
<seb128> if that's the case mailing ubuntu-devel-announce would be a good diea
<seb128> idea
<ogra> pitti, ergh
<ogra> 709M ??
<pitti> seb128: ah, right, I guess DebianImportFreeze is the autosync, UVF the time until which manual syncs can be done without fuss
<pitti> ogra: weird; only new versions of compiz and n-m
<davmor2> pitti:  seem to work although I am having to type in my password for the connection each time rather than the keyring
<ogra> gah
<seb128> it's early to stop autosyncs :/
<ogra>  /pool/main/m/mesa/libgl1-mesa-dri_6.5.3-1ubuntu1_i386.deb
<ogra> when did i merge that, damned
<pitti> ogra: if it's only the alternates, they are cheap to rebuild
<ogra> well, i need to get rid of -dri for now
<pitti> ogra: I already queued live rebuilds, I'll try to kill them
<ogra> i dont understand how it got in, thats my prob
<ogra> i just added it to the seeds 2h ago and didnt rebuild -meta
<ogra> it shouldnt be there
<pitti> ogra: hm, indeed
<ogra> is it a dep of anthing suddenly ? 
<pitti> not according to apt-cache rdepends libgl1-mesa-dri
<ogra> hmm
<pitti> ogra: it's on the amd64 one as well, it just doesn't overflow there
<ogra> yeah
<ogra> well, i left it deliberately out
<ogra> are the recommands read during cd buildtime or something ? 
<pitti> ogra: I am not entirely sure whether cdimage only uses ubuntu-meta or also considers the bzr seeds for building imagees
<ogra> yeah, thats what i suspected, even though its the meta package ... 
<ogra> it shouldnt be affected by cdimage
<pitti> cjwatson, Mithrandir: does cdimage consider committed seed changes which haven't been manifested in -meta?
* ogra reverts the seeds 
<cjwatson> pitti: for building images, it considers the seeds - though note that removals that haven't been committed to -meta won't take effect because the metapackages will still pull them in
<pitti> ah, that explains it
<pitti> cjwatson: thanks
<cjwatson> seeds and -meta should really be consistent for releases though
<cjwatson> I wouldn't like to guarantee exactly what uses Task headers
<ogra> cjwatson, it was no removal, it wasnt added to the seeds before the last meta build
<ogra> i added it afterwards to not forget about it after tribe2
<Keybuk> pitti: DebianImportFreeze is the date to stop the manual autosyncs
<ogra> meta has never seen it ...
<pitti> Keybuk: right, thanks
<cjwatson> ogra: the image build process should pull it in then
<ogra> ah
<ogra> pitti, seeds changed back ... can you trigger an alternate build ?
<pitti> ogra: I think I need a publisher run first; still remember the last time we wondered about that? :)
<ogra> ah, right
<pitti> cjwatson: ^ actually, manually running cron.germinate might even be sufficient?
<pitti> ogra: oh, you are lucky, the current publisher didn't run cron.germinate yet
<pitti> so it'll come to that soon
<ogra> take your time :)
<cjwatson> pitti: an actual package needs to be published
<pitti> ok, will do that then
* pitti notes this down to not forget again
<cjwatson> running cron.germinate isn't sufficient - the problem is getting the distroarchseries to be marked dirty so that apt-ftparchive is run
<pitti> ogra: erk, sorry, edubuntu live fs are just triggered; apparently pressing ^C in bash only kills the current command in a chain, not the entire chain
<ogra> well
<pitti> ogra: but *shrug*, I'll build new ones after that and a publisher run
<ogra> just wasted DC time ...
* ogra doesnt care much about wasted bytes :)
<pitti> heno, mvo, luisbg, all: new ubuntu live CDs up for testing: http://cdimage.ubuntu.com/daily-live/20070627/
<luisbg> pitti, awesome! will try in a short bit
<mvo> pitti: rsyncing
<agoliveira> pitti: I'll give it a shot in my macbook later.
<heno> pitti: posted
<pitti> heno: cheers
<heno> (and syncing :) )
<pitti> heno: can you please invalidate the edubuntu server ones?
<pitti> heno: they need another rebuild to kick libgl1-mesa-dri (overflow)
<heno> yep
<heno> oh, I actually refrained from ever posting those when I saw that mentioned here
<ogra> yeah they are still in rebuild state ...
<pitti> ah, I see
<ogra> even though 06.2 was fine
<pitti> they don't even appear at all here
<ogra> select edubuntu at the top :)
<cjwatson> lamont: any luck on getting livecd-rootfs changes merged up?
<cjwatson> lamont: I don't see anything in the branch on LP
<pitti> heno, shawarma, mathiaz, fabbione: new ubuntu server images up for testing: http://cdimage.ubuntu.com/ubuntu-server/daily/20070627/
<pitti> this time, hopefully, with 'P' in LAMP for 'PHP' :)
<dendrobates> pitti: don't forget about me :0
<pitti> dendrobates: oh, indeed :) if you have some time for testing, that would be appreciated
* pitti puts the 'official server test coordinator' badge on dendrobates' chest
<pitti> mathiaz is already booting them, I hope :-P
* mvo rsync the server images
<evand> pitti: I see bug #122518, but are there any other issues you experienced with the installer?  Are you still having the partitioner issues?
<ubotu> Launchpad bug 122518 in ubiquity "canceling the language support download gives confusing error message" [Undecided,New]  https://launchpad.net/bugs/122518
<pitti> mvo: how do the desktops look like?
<shawarma> mvo: Did you find out what triggered the task bug?
<pitti> evand: #122518 is low-prio, of course
<pitti> evand: the manual partitioner hang doesn't happen in vmware, only on my real system, I didn't hear any other reports about it, and I wasn't able to track it down
<pitti> evand: UBIQUITY_DEBUG=1 made it disappear, next time I'll try with --debug (as recommended by Colin)
<evand> hrm, I did hear one other report of it, but they were unable to reproduce it. (Not sure if it's even the same issue)
<evand> ok
<mvo> pitti: still burning
<pitti> evand: however, I still need some time before I can try the current daily on real hw
<agoliveira> pitti: It happened to me yesterday but the second time I tried to see if I could catch what happened, it just wnet by nicelly.
<evand> fair enough
<mvo> shawarma: yes, the pkgRecord had a missing \n at the end, but not sure why this happend
<nxvl> today is the hug day, isn't it?
<shawarma> pkgRecord?
<pitti> mvo: ah, that explains the \n -> $
<mvo> yes
<shawarma> Ah, I get it.
<shawarma> Not why it fails, but what you mean, that is.
<ion_> mvo: Did you notice what i said about check_tfp? The texture_from_pixmap test succeeds, so INDIRECT isnt touched at all.
<mvo> its still a bit mysterious
<mvo> ion_: sorry. hm, it is set for me on my r200 ati system. you do not happen to run xgl, do you?
<ion_> mvo: Nope, no Xgl.
<mvo> ion_: LIBGL_ALWAY_INDIRECT somewhere in the environment (maybe as a leftover from a earlier run?)
<ion_> mvo: The output of sh -x compiz is attached to the bug report.
<ion_> mvo: Nope.
<mvo> ion_: hm, I will have to look closer at this then
<dendrobates> has https://bugs.launchpad.net/ubuntu/+source/openldap2/+bug/58487 been discussed?  This only applies to the version of openldap in dapper.  what is the policy on upgrading packages in the LTS .
<ubotu> Launchpad bug 58487 in php5 "php5-ldap fails with official (chained) certificate" [Undecided,New]  
<dendrobates> ha.
<dendrobates> I love that bot.
<ScottK> dendrobates: Look on wiki.ubuntu.com for policies on backports (new versions) and SRU (fixes to stable releases).
<dendrobates> thx.
<pitti> dendrobates: https://wiki.ubuntu.com/StableReleaseUpdates, in particular
<pitti> dendrobates: there is /Motu/SRU, too, for universe packages
<pitti> evand: do you have an idea what I could do when I encounter this?
<pitti> evand: well, if you want, I'll hop on IRC while being on the live CD and get this error, to talk to you
<heno> pitti: both i386 and amd64 desktops are installing nicely here
<pitti> yay
<pitti> heno: I currently run amd64 alt/desktop tests in vmware, will do an amd64/live on real iron soon
<heno> (i386 in vbox amd on hw)
<pitti> rock
<evand> pitti: encounter the partitioning issue?  Running the installer with --debug and attaching /var/log/installer/debug, /var/log/syslog, and /var/log/partman should be a reasonable start.
<pitti> evand: right, if the hang doesn't disappear again with debugging enabled :)
<evand> heh
<pitti> heno: no more troubles with hanging splash, compiz, or network-manager?
<heno> pitti: no hanging splash, n-m only tested with wired networks, compiz not expected to work on vbox (what about amd64,should it work there?)
<pitti> heno: right, the fact that compiz does *not* enable on a box that doesn't support composite is the key here :)
<heno> ok, then we are good
<pitti> heno: in general, compiz works on amd64, too, same hw/driver situation as on i386
* pitti bounces
<pitti> finally some light at the end of the tunnel
<heno> I did have all the boot loop problems yesterday on this vbox setup
<pitti> me too here (vmware and real hw)
<dendrobates> ScottK: I just updated #58487.
<ScottK> OK.  Bug triage should be discussed in #ubuntu-bugs.  I am there too.
<mvo> pitti: desktop-i386 on nvidia success here too
* pitti hugs mvo
* mvo hugs pitti back
* mvo looks at the word ordering and wonder if that actually made sense
<pitti> mvo: me not much mind at now time
<mvo> yoda!
<pitti> "Dark the other side is!"
<mvo> "little endian we hate"
<pitti> "Be quiet, Yoda, and eat your toast!"
<cjwatson> mvo: is bug 122518 an apt bug? surely failed fetch shouldn't imply package in broken state
* ogra always wondred about pittis ears and teint
<ubotu> Launchpad bug 122518 in ubiquity "canceling the language support download gives confusing error message" [Undecided,New]  https://launchpad.net/bugs/122518
<kylem> haha.
<mvo> cjwatson: let me check
<mvo> pitti: LOL
<gicmo> my network-manager + keyring problem is still there ;-/
<pitti> gicmo: <Jedi wave>no, it's not</Jedi wave>
<pitti> gicmo: which CD version?
<gicmo> cd version? I am gutsy here
<gicmo> wants to access password for " in (null)
<pitti> gicmo: ah; which network-manager-gnome version?
<gicmo> "Allow always" -> crash
<gicmo> 0.6.5-0ubuntu3
<ulaas> pitti, was there yesterday night it is....
<gicmo> (I just updated and rebooted, still there)
<pitti> gicmo: right, that's the crashing one; you want 0.6.5-0ubuntu4
<Keybuk> "upgrade you must, hmm?"
<gicmo> pitti, where do I get it?
<pitti> dark the old version is
<gicmo> ;-)
<gicmo> I gues its totally fresh and hot
<gicmo> guess
<pitti> gicmo: yes, careful you need to be
<mvo> cjwatson: is scritps/install.py responsible for installing the additional languages? (re #122518)
<pitti> gicmo: you need archive.ubuntu.com in apt sources, mirrors are too old
<ulaas> pitti, cant wait to go home then master...
<Keybuk> Rosetta is sorely let down by its inability to let us translate Ubuntu into en_Yoda
<gicmo> i c
<kylem> Keybuk, *HA*
<pitti> ulaas, gicmo: http://archive.ubuntu.com/ubuntu/pool/main/n/network-manager-applet/
<gicmo> ohh, brightness control also stopped working and I get tons of crash reports, fun, fun, fun
<pitti> gicmo: just click on the right package there and let gdebi do its magic
<gicmo> pitti: thanks
<Hobbsee> Keybuk: *grin*
<ulaas> pitti, i thought that it was the keyring. no?
<gicmo> ulaas: it looks like keyring + nm interaction here
<pitti> ulaas: it still is, but circumventing the crash in n-m-applet was much easier (and possible for tribe-2 in the first place)
<cjwatson> mvo: yes, install_language_packs()
<ulaas> pitti, one last question.. how will the conservative approach to licenses will affect us? (ordinary people not jedi...)
<Hobbsee> heno: which bits are you testing?
<heno> Hobbsee: which ISOs or which functionality?
<cjwatson> ulaas: I don't expect the standard Ubuntu distribution will change in any particularly visible way
<Hobbsee> heno: er.  well, with hte ubuntu desktop i386, which tests are you doing?
<cjwatson> ulaas: the proposal is for a more conservative variant
<heno> Hobbsee: live CD, erase disk, check cd
<Hobbsee> heno: right.  so you're VBing then, and it's worth testing on a installed system?
<ulaas> cjwatson, ah it is a variant. not gutsy itself....
<ulaas> cjwatson, ok with me then. u shall proceed.... :)
<heno> Hobbsee: yes please (I was just getting to that as well)
<Hobbsee> okay
<heno> but some extra testing is always good
<Hobbsee> hmmm...
<shawarma> pitti: Done testing server images on i386 and amd64. Everything seems to be good now.
<pitti> shawarma: finally
<pitti> ulaas: what do you mean?
<pitti> shawarma: thanks
<shawarma> pitti: np
<hunger> Will vmware be part of gutsy again?
<pitti> hunger: 'again'?
<hunger> pitti: apt-get install vmware-player used to work on feisty:-)
<hunger> pitti: That is support enough for me;-)
<pitti> heno, ogra, bdmurray, LaserJock: new edubuntu server ISOs up for testing, this time without overflow: http://cdimage.ubuntu.com/edubuntu/daily/20070627.1/
<pitti> hunger: ah, I see
<hunger> pitti: Currently the modules are not up to date or so it seems.
<ulaas> pitti, cjwatson replied. thanks for thinking....
* siretart is currently testing gutsy's alternate installer via pxe netboot.
<pitti> ulaas: ah, reading backscroll now
<ogra> yay
<ogra> pitti, thanks :)
<pitti> ogra: ETA 15 minutes for the lives
* siretart can confirm success on tribe-2 pxe netinstall on a Thinkpad X60s with Root on LVM! yay! :)
<dholbach> congratulations nixternal
<dholbach> congratulations calc
<mvo> pitti: feisty->tribe-2 upgrade works fine
<pitti> mvo: yay
<pitti> does anyone feel like creating a tribe-2 testing wiki page?
<Hobbsee> what for?
<pitti> for ubuntu
<pitti> similar to https://wiki.ubuntu.com/GutsyGibbon/Tribe1
<Hobbsee> oh right
<pitti> heno, ogra, LaserJock: new edubuntu live CDs for testing: http://cdimage.ubuntu.com/edubuntu/daily-live/20070627.1/
<pitti> heno: that's the last set of images, we have a complete set again
<heno> pitti: ok, let me go through the tracker and make sure it matches reality :)
<ogra> pitti, that should be 27.2
<ogra> 27.1 is from this afternoon
<pitti> ogra: erm?
<ogra> and i dont see .2 yet
<pitti> ogra: I stopped building it
<ogra> hmm, it created the dir 
<ogra>  gutsy-desktop-i386.iso          27-Jun-2007 14:45  690M
<pitti> ogra: well, it doesn't have libgl1-mesa-dri, isn't oversized, so it should be good :)
<pitti> ogra: and I don't remember seeing the dir before
<ogra> well, indeed *g*
<ogra> you built the live iso after the server iso, didnt you ? 
<ogra> the server iso has a timpestamp for 15:45
<pitti> ogra: f***, it has an outdated network-manager-gnome
<pitti> ogra: right
<iwj> mvo: That bug that we thought was related to the expo compiz plugin seems to have come back for me.
<iwj> On the same system where we fixed it on Monday.
<mvo> iwj: hm, no good. same symptoms?
<iwj> I haven't updated the machine since Monday but I have installed a couple of packages and messed with the libc.
<iwj> Yes.
<iwj> C-A-B and then log in again fixes it for one go, as previously.
<mvo> strace futex hang?
<pitti> ogra: ah, silly me, nevermind
<iwj> I've checked the global.xml and it still has expo disabled.
<pitti> ogra: I built the live CD image, but didn't run cron.daily_live yet
<mvo> iwj: you have the latest compiz and plugin packages?
<iwj> No.
<ogra> pitti, ... happens :)
<iwj> Well, I don't have anything you uploaded since we last talked about this.
<mvo> iwj: could you please try to upgrade to those?
<iwj> OK, I can do that right now if no-one has updated libc since ...
<mlind2> hiya, could someone of the core-devs poke a buildd farm to rebuild libcairo 1.4.8-1.
<mlind2> The FTBFS issue because of libdirectfb-dev was fixed by pitti with a recent directfb upload. thanks in advance.
<pitti> mlind2: done
<mlind2> cheers!
<alex-weej> how do i build a source package that i've hacked up
<alex-weej> i tried debuild but it whinged that i wasn't sebastian bacher
<alex-weej> (i don't have his secret key to sign the package)
<Mithrandir> alex-weej: that's fine, it built the package fine
<alex-weej> Mithrandir: so it did. thanks.
<iwj> pitti: Hmm, it's not doing it now.  It has the feel of something intermittent so I'll keep an eye out.
<iwj> (now = after getting the new compiz packages)
<pitti> iwj: let's hope for the best then
<pitti> heno, ogra, LaserJock: new edubuntu live CDs for testing: http://cdimage.ubuntu.com/edubuntu/daily-live/20070627.2/ (for real this time)
<ogra> :)
<pitti> this time with the unscrewed n-m applet
<ogra> and they behave in size ... nice, thanks :)
<bethko> Hello
<bethko> Where should I be to talk about web cam plug in play support for Ubuntu? It is really needed.
<pitti> asac: congrats, your keyring patch was applied upstream already
<asac> pitti: oh ... that was quick
<mvo> hm, about ubuntu still says 7.04
<nixternal> dholbach: thank you!
<seb128> asac: I told you, upstream is active ;)
<seb128> usually GNOME guys are quick
<pitti> mvo: sounds like a good tribe-3 bug
<dholbach> nixternal: :-)
<seb128> pitti: is 2.6.22-7 the version supposed to fix apport?
<bethko> Has the 7.10 About page even been written?
<pitti> seb128: in theory, yes; at least it passes the test suites again on powerpc and amd64
<Hobbsee> bethko: unlikely...why would it have?
<seb128> pitti: https://bugs.launchpad.net/ubuntu/+source/xfce4-mixer/+bug/122608
<ubotu> Launchpad bug 122608 in xfce4-mixer "xfce4-mixer-plugin crashed with signal 5" [Undecided,New]  
<seb128> pitti: is signal5 supposed to get a crashdump also?
<asac> seb128: hehe ... i can only dream of that for mozilla devs :)
<bethko> Well that would explain it mvo
<pitti> seb128: indeed I saw a few bugs with broken core dumps on -7; NFC
<seb128> "NFC"?
<pitti> seb128: I don't know
<seb128> k
<bethko> Still best to put it in a bug anyways so it is not forgotten about
<pitti> seb128: hmm, signal 5 is a SIGTRAP
<pitti> seb128: No f*** clue
<bethko> I'm an editor, the only code I do is html and basic
<Hobbsee> ie, NFI
<seb128> pitti: ah ;)
<bethko> like gw basic
<Hobbsee> mvo: 7.10 doesnt exist yet.
<Treenaks> bethko: that's SO 20th century! :)
<bethko> lol
<bethko> I've been using computers since I was 2 year old. And that was back in 84
<bethko> Ok, so who do I talk to about webcams?
<bethko> You know with youtube and all I would think someone would be on top of this.
<Hobbsee> bethko: likely you should be that someone.  dont know who specifically to talk to
<Hobbsee> besides, youtube is flash.
<aquo> hi
<aquo> i have a question refering to http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/bin/cron.daily
<aquo> there is a line
<aquo> PATH="$CDIMAGE_ROOT/bin:${PATH:+:$PATH}"
<aquo> what is this parameter substitution for?
<aquo> i don't understand the usage of the +
<kitche> + might be for concat?
<aquo> bash manual says        ${parameter:+word}
<aquo>               Use  Alternate Value.  If parameter is null or unset, nothing is
<aquo>               substituted, otherwise the expansion of word is substituted.
<kitche> I never really looked at bash to closely
<aquo> if $path is null or unset --> PATH="$CDIMAGE_ROOT/bin::"
<aquo> aehm ...
<Treenaks> aquo: no, if $path is null or unset PATH="$CDIMAGE_ROOT/bin:"
<aquo> aehm, yes
<aquo> you are right
<nxvl> is someone working on openssh bugs so i can join them?
<aquo> but if path is not empty the result is $CDIMAGE_ROOT::$PATH
<nxvl> in the wiki are marked in green the resolved bug or the ones someone is working on?
<bethko> Youtube being flash does not help if you want to put up a video and all you have is a webcam and a computer running ubuntu
<bethko> I work with the Deaf, they use sign language
<bethko> Hell the webcams don't even work with the Ekiga phone software that is installed by DEFAULT!
<kitche> well considering he linux kernel has support for 389 webcams your webcam is probably one of the few that doesn't have drivers
<cjwatson> alex-weej: you can use 'debuild -b -uc -us' to avoid that message
<alex-weej> what do those flags mean?
<cjwatson> I've resolved aquo's bug above
<cjwatson> alex-weej: man dpkg-buildpackage
<bethko> It's a logitech
<bethko> And I've tryed onther cams
<ogra> alex-weej, or if you own a key you could also -k<your_mail_address> and sign with your own one
<alex-weej> i don't do any of that yet
<alex-weej> way too complicated
<mvo> cjwatson: I updated #122518 
<geser> alex-weej: -uc = don't sign the .changes file, -us = don't sign the .dsc file 
<alex-weej> ta
<cjwatson> mvo: oh, right, I see
<cjwatson> mvo: is IOError raised for anything other than fetch exceptions?
<mvo> cjwatson: no, only then
<cjwatson> I could just silently ignore that
<mvo> cjwatson: but I'm happy to add something for user-cancelt here too if you want it
<cjwatson> maybe that would be cleaner
<cjwatson> can it be a subclass of IOError so that old code keeps on working?
<mvo> cjwatson:sure, I will do that tomorrow then
<cjwatson> great, thanks
<mvo> np
<mvo> iwj: did new compiz-love helped you?
<iwj> mvo: Yes, it seemed to help.  It still feels like an intermittent problem.  I wasn't writing down everything that happened and it's confused by a separate X server bug.
<iwj> I'll keep an eye on it and let you know if it does anything else wrong.
<aquo> hi
<aquo> another question for http://people.ubuntu.com/~cjwatson/bzr/cdimage/
<pochu> pitti: apport seems to be uploading bug crashes without coredumps. Are you aware of it?
<aquo> the scripts use a program with the name lockfile
<pitti> pochu: aware yes, but I don't know why it still happens on the 2.6.22-7 kernel
<aquo> it is not installed on my system, where do i get this?
<pitti> aquo: apt-cache search lockfile
<Mithrandir> or even better, apt-file search lockfile
<pitti> aquo: lockfile-progs or procmail (depending on which lockfile program it uses)
<pitti> Mithrandir: command-not-found is nice as well :)
<pochu> pitti: ok, I'll just reject them ;)
<aquo> pitti: it is not in lockfile-progs, already had a try on this.
<pitti> aquo: then it might indeed be procmail's :)
<nxvl> where can i find the source of cp?
<aquo> so i need to install procmail for building ubunut cd images ...
<cjwatson> nxvl: coreutils
<aquo> grmpf
<cjwatson> yes
<pitti> nxvl: apt-get source `dpkg -S /bin/cp`
<cjwatson> aquo: ^--
<cjwatson> procmail isn't an arduous dependency
<aquo> k, no problem
<geser> seb128: is the missing Debian removal bug a showstopper for bug #122344?
<ubotu> Launchpad bug 122344 in sylpheed-claws-gtk2-extra-plugins "[Remove]  Please remove sylpheed-claws-gtk2 and sylpheed-claws-gtk2-extra-plugins from gutsy" [Undecided,New]  https://launchpad.net/bugs/122344
<ion_> http://www.alex-smith.me.uk/files/bootchart-ud.png :-)
<pygi> ion_, frugalware dude? :)
<ion_> pygi: Yeah
* lamont glares at https://launchpad.net/ubuntu/+source/perl/5.8.8-7ubuntu1
<pitti> agoliveira: do you have that hanging ubiquity running ATM?
<agoliveira> ATM?
<asac> agoliveira: at the moment
<agoliveira> pitti: At this moment?
<asac> yes
<asac> :)
<agoliveira> Sorry, too many TLA's :-D
<geser> pitti: does Ubuntu also drop apache 1.3 from gutsy? Debian did it already 
<agoliveira> pitti: Yes, it's right in front of me.
<pitti> geser: I'd love to, if the reverse depends allow us
<pitti> agoliveira: ok, so evand might be able to help you
<seb128> geser: no, not a blocker, it's just easier when they clean things also
<agoliveira> evand: Pitti told me to poke your about parted_server problem during instalation.
<seb128> geser: and I'm wondering if there is a reason they didn't ask for the removal
<agoliveira> pitti: Thnaks.
<geser> pitti: will check the rdepends and file removal bugs where needed
<geser> seb128: I guess the maintainer forgot to file a bug yet
<LaserJock> anybody else here run Vmware Fusion?
<pitti> geser: not that bad actually; two tons of libapache-mod-* and twiki
<pitti> LaserJock: fusion?
<pygi> pitti, they mac thingy
<LaserJock> pitti: yeah, VMware for macs
<pygi> where you could get windows out of the VM window
<pitti> ah, no
<LaserJock> I *still* can't get the Tribe 2 candidate to boot in it
<lamont> pitti: do you know if anyone is working on the perl FTBFS?
<LaserJock> I think it must be my VMware or something
<pitti> lamont: I don't know anyone who is working on it; are you currently doing a rebuild test?
<lamont> pitti: uh... well, fortunately? it was still ftbfs on i386 last night when I retried it without thinking
<lamont> the failure on amd64 is from may...
<lamont> once tribe2 is out, I figured I'd give it back everywhere, but I expect that it'll still fail
<lamont> amusingly, it builds on hppa
<pitti> lamont: "You haven't done a "make depend" yet!" a-haa
<lamont> do you want an upload for tribe 2, or should I wait for it to be out before I upload?
<pitti> lamont: I'd prefer waiting with giving-back, just in case we need to respin the CDs
<lamont> right
<pitti> lamont: normal source uploads are fine, though, they will just sit in the queue
<evand> agoliveira: can you run the installer with --debug and attach /var/log/installer/debug, /var/log/syslog, and /var/log/partman to a new bug report?
<pitti> lamont: so if you have a fix, uploading it is fine
<lamont> looking at the clock this may be something I work on on the plane tomorrow
<lamont> haven't even looked at it
<cjwatson> agoliveira: I'd suggest saving /var/log/syslog and /var/log/partman first just in case --debug makes it go away
<cjwatson> they might still be useful somehow
<lamont> although the funny part is that it actually built on hppa
<evand> ah, good point
<agoliveira> evand: Sure, unless the same as yesterday happens. The first time I tried, I got the error, the second (when I used --debug) made the error go away :-/
<evand> yikes
<pitti> agoliveira: same here
<pitti> yay heisenbugs
<farcl0ud> ubunto is pretty schweeeeeet
<farcl0ud> heh
<farcl0ud> how do i make windows transparent?
<evand> farcl0ud: this is not a support channel.  /join #ubuntu
<farcl0ud> ok
<agoliveira> evand, pitti: This might be something related to the saved configurations as if I start the instalation again, even without the --debug, it does work.
<pitti> agoliveira: maybe reboot and try with --debug right away?
<agoliveira> pitti: Yes, I'm doing this right now.
<pitti> I'll do the same once my vmware test installs finish and I'll get to the real-metal tests
<pitti> ok, I'll go offline for a bit for CD testing, bbl
<azeem> /W/ 5
<azeem> oops
<agoliveira> pitti, evand: I started again from scratch, running ubiquity --debug and guess what? It just freaking works...
<evand> haha
<ogra> the new ubiquity partitioner ui is beautiful ...
<ogra> hmm, even though it hangs now ... 
<agoliveira> evand: I would be weeping not laughing :-D
* ogra gives it some more time and goes fo rdinner
<evand> agoliveira: try it without --debug and just attach the other logs?
<pitti> cjwatson:  "You are running in debugging mode. Do not use a valuable password!" -> Thanks a lot for this!
<agoliveira> evand: I'll already started the instalation. I'll try that again as soon as it ends.
<evand> ok
<pitti> agoliveira: ah, did you get any further with that bug?
<agoliveira> pitti: Which one?
<cjwatson> pitti: I got fed up of having to tell people that by hand every time :)
<pitti> agoliveira: hanging manual partitioner
<cjwatson> I'm going to have to see if I can reproduce this myself, I guess
<agoliveira> pitti: When you go over the normal process, parted_server hangs. If you start ubiquity with --debug it goes nicelly... go figure...
<cjwatson> and braindump my thought processes on evand along the way :)
<evand> heh
<cjwatson> I wonder if something is colliding with the file descriptor the log file is initially opened on
<pitti> agoliveira: it's just the computer's way of telling you that it wants to talk to you more
<cjwatson> agoliveira: can you get an strace of what parted_server is doing when it hangs?
<agoliveira> pitti: This is cute :-P
<pitti> cjwatson: curious why it doesn't happen in vmware, though
<cjwatson> mm, hard to say as yet
<pitti> agoliveira: which kind of file systems do you use?
* pitti has ext3, reiserfs, xfs, a crypted partition, and an ntfs test partition
<agoliveira> cjwatson: I'm installing right now but I'll see what I can get of it later.
<pitti> but I already killed the ntfs one, that wasn't it
<agoliveira> pitti: It's a tripple boot macboot so it has efi, afs, ntfs.
<polopolo> Is it today bugday?
<agoliveira> pitti: and ext3 and swap
<pitti> agoliveira: it doesn't happen with ext3 and swap in vmware, and otherwise we have entirely differnent fs'es, so it might not be that either
<bdmurray> polopolo: Yes it is
<polopolo> bdmurray: ok
<agoliveira> Gosh... now it hung just before shut down X when I told to reboot. And hung badly, I had to power it down.
<bdmurray> We have a list of bugs we are working on at https://wiki.ubuntu.com/UbuntuBugDay/20070627
<nxvl> pitti: thnx
<nxvl> pitti: i have just see your answer about cp
<pitti> nxvl: mp
<pitti> no problem
* pitti reboots back into the freshly installed system, brb
<nxvl> pitti: the comand has a bug!
<nxvl> dpkg -S /bin/cp returns "coreutils:"
<cjwatson> nxvl: I think you get the general idea though
<cjwatson> run dpkg -S /bin/cp and then inspect the package that returns
<nxvl> cjwatson: heh, yes, i did
<nxvl> cjwatson: it was a joke
<nxvl> :P
<pitti> agoliveira: is there already a bug report about the manual partitioning hang?
<agoliveira> pitti: Not from me. I'll try to make it happen again in a few minutes;
<pitti> agoliveira: ok; I'll create one, so that I have something to attach to my isotesting report; I don't have any logs, though
<agoliveira> pitti: As soon as I can get some I'll sen to you then.
<ulaas> pitti, network manager has still the same issue..
<pitti> agoliveira: right, send it to that bug then, please
<pitti> ulaas: darn; can you please talk to asac to debug this further
<pitti> ?
<Evolution2> i would like to know what third party repositories i need to have in adept package manager. and i also iam wondering why the "full upgrade" button is shaded
<ulaas> pitti, sure.
<agoliveira> pitti: sure. Can you give me a pointer for it?
<agoliveira> pitti: Oh, isotracker?
<ulaas> asac, yo! how can i be of service
<pitti> agoliveira: I didn't file it yet, in a minute
<pitti> agoliveira: yes, iso-tracker allows you to put bug numbers into it
<agoliveira> pitti: Ok.
<Evolution2> anyone?
<sn0> Evolution2 this isn't really the channel for support, please try #ubuntu
<Evolution2> thanks
<pitti> agoliveira: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/122645
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitively" [Undecided,New]  
<agoliveira> pitti: Got it.
<ulaas> asac, u there?
<asac_> ulaas: sure
<ulaas> asac_, ah wanna hear about network-manager issue..
<asac_> ulaas: though expect me to go problem as my connection is really unstable today
<asac_> ulaas: which one?
<ulaas> asac_, endless wep key questionnaire..
<ulaas> asac, sorry wpa
<ulaas> asac_, i have the latest packages of course
<pitti> LaserJock: do you still have problems with compiz with latest packages/on current CDs?
<asac> ulaas: so how does it look like?
<LaserJock> pitti: I do on VMware Fusion on my intel iMac
<pitti> mvo: ^
<paul_d> I would expect a QA member to update 'Managing Status' of https://wiki.ubuntu.com/Bugs/CommonTasks
<LaserJock> pitti: but at home in VMware Server on my Ubuntu box it's fine
<pitti> LaserJock: at the current point we won't re-roll CDs, but bug reports with hw details are heavily appreciated
<LaserJock> I'm wondering if it's a VMware Fusion problem
<LaserJock> although I'm not sure why that would be'
<pitti> LaserJock: particular graphics driver, presumably
<asac> ulaas: ?
<ulaas> asac, sec
<ulaas> asac, typing in the key. wait for a few moments. and there comes the dialog again.
<LaserJock> pitti: oh wait, is composite/compiz enabled by default then?
<LaserJock> I assume so
<LaserJock> in vmware, specifically
<pitti> LaserJock: not in vmware, because the driver doesn't support it
<asac> ulaas: so you are using nm-applet...ubuntu4 ?
<pitti> LaserJock: in general it's the default, but session startup uses some tests which disable it if the driver isn't good enough
<ulaas> asac, i am a man of doubl check. a sec please
<bdmurray> pitti: what are the tests?
<LaserJock> pitti: well, I've updated the bug I filed, I'll add more if mvo needs it
<ulaas> asac, thats the one.
<LaserJock> it'd be nice to find somebody else using vmware fusion though and see if they can confirm
<mvo> LaserJock: what bugnumber is that
<ulaas> asac, i have cleaned my user. so gconf is fresh as new...
<ogra> does ubiquity hang foa anybody else in teh patiotioner ? 
* ogra glares at his fingers
<LaserJock> mvo: bug #122459
<ubotu> Launchpad bug 122459 in compiz "[gutsy]  cannot log in on edubuntu DesktopCD" [Undecided,Incomplete]  https://launchpad.net/bugs/122459
<LaserJock> ogra: at least you can easily blame it on the ClassmatePC keyboard ;-)
<asac> ulaas: hmmm probably a regression from the patch we applied today
<ogra> well, i'm on my main lappie :)
<pitti> bdmurray: what do you mean?
<LaserJock> ogra: but we don't know that ;-)
<ulaas> asac, whatever you say bro. i ama s
<asac> ulaas: did nm-applet crash for you before today?
<pitti> ogra: yes, for manual partitioning?
<pitti> ogra: bug 122645?
<ogra> pitti: yup
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitively" [Undecided,New]  https://launchpad.net/bugs/122645
<ulaas> asac, yap i got the whole shebang starting from yesterday
<bdmurray> pitti: I was curious if it looked at the videocard pci id or something else.
<mvo> LaserJock: oh? and this is still a problem? can you attach .xsession-errors from a failed login please?
<LaserJock> mvo: hmm, I can try
<pitti> bdmurray: ah, those tests; there's a driver blacklist (vesa and nv) and then it does some checks on the glxinfo output
<asac> ulaas: and before yesterday all worked fine for you?
<ulaas> asac, well that was feisty..
<ogra> pitti: i confirmed it
<cjwatson> ogra: I'd like an strace of what parted_server is doing, if you can
<ogra> it happens definately on three different systems ... 
<ogra> cjwatson: trying :)
<cjwatson> I imagine it's hanging in just one syscall, but knowing which would be helpful ...
<cjwatson> or even attach gdb to it and get a backtrace, though you'd have to fiddle about to get symbols
<mvo> bdmurray: currently it does feature testing based on glxinfo and xpdyinfo and blacklisting of some drivers
<cjwatson> evand: have you managed to reproduce this hang?
<asac> ulaas: ok so you upgraded to gutsy yesterday got crashes and now you get password dialog popping up endlessly?
<nxvl> i have already patch bug #89945 can someone please check if the patch is correct?
<ubotu> Launchpad bug 89945 in openssh "scp doesn't report correct filenames with spaces in verbose mode" [Undecided,New]  https://launchpad.net/bugs/89945
<asac> ulaas: please post that info to bug 121228
<ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [High,Fix released]  https://launchpad.net/bugs/121228
<ulaas> asac, yap. previous versions than ubuntu4 was crashing. ubuntu4 is asking for key forever.
<ulaas> asac, you bet.. ;)
<evand> cjwatson: negative, but I've only been using vmware
<asac> ulaas: or no ... please open a new bug and add a hint that this 
<evand> which I hear nullifies it
<asac> ulaas: popped up since ubuntu4  and link the bug above to the new bug
<asac> ulaas: thanks
<cjwatson> nxvl: incorrect as what if the filename contains single quotes?
<evand> still trying though
<ulaas> asac, lemme first investigate a bit more. i am suspicious of keyring...
<cjwatson> it needs to be escaped properly rather than just surrounding it with ''
<asac> ulaas: feel free ... but i will be out soonish
<cjwatson> in any case, that bug should go upstream
<nxvl> cjwatson: can a file name hace?
<nxvl> have*
<cjwatson> http://bugzilla.mindrot.org/
<cjwatson> nxvl: yes
<pitti> asac, ulaas: maybe that's the part where that gnome-keyring fix comes into play?
<cjwatson> a filename can contain any character except \0
<ulaas> asac, no problem. i will file thebug anyway.
<nxvl> mmm
<pitti> nxvl: (except \0 and /)
<ulaas> pitti, is there fix for that?
<cjwatson> (though \n will probably break in a number of places ...)
<nxvl> ok, i will check another way to do it
<asac> pitti: might be ... is the fix already in gutsy?
<asac> ulaas: what version of gnome-keyring do you have?
<ulaas> asac, 2.19.4.1-0ubuntu1
<asac> ulaas: are you on amd64?
<ulaas> asac, nope i386
<asac> hmmm
<asac> ulaas: ok please file the new bug and don't forget to reference the original bug i mentioned above in the summary
<ulaas> asac, surely.
<asac> ulaas: i will come back to you with packages you might test ... probably tomorrow morning
<LaserJock> mvo: I attached .xsession-errors to the bug report
<LaserJock> tons of alsa stuff
<ulaas> asac, have a good one.
<ogra> cjwatson: http://people.ubuntu.com/~ogra/strace-parted_server-tribe2.out
<cjwatson> ogra: hmm, when did you start that?
<cjwatson> after it appeared to have hung?
<cjwatson> perhaps slightly before?
<ogra> before clicking anything in the "manual/guided partitioning" selection dialog
<cjwatson> ok
<sladen> nixternal: /proc/sys/net/ipv6    and  'unset'
<ogra> the hanging ubiquity win is still there ... so it ran until it died
<cjwatson> nothing obvious in there, looks more subtle than just confused fds
<nxvl> where can i see what initialize_main does, i'm searching, but i don't find it
<cjwatson> nxvl: (I'm not sure this bug report is worth lots of effort, to be honest)
<mvo> LaserJock: what X driver is this system using 
<LaserJock> mvo: the host?
<cjwatson> nxvl: there is no initialize_main function in openssh
<LaserJock> or the livecd?
<cjwatson> at least not in the current version; perhaps you're looking at an old one
<mvo> LaserJock: the thing that fails :)
<mvo> LaserJock: could you please try to login into a fail-safe session and run glxinfo in a terminal? 
<LaserJock> k
<LaserJock> I also collected an .xsession-errors with the sound turned off, is that of use?
<mvo> LaserJock: yes, less clutter sounds good
<nxvl> cjwatson: no, but it is on cp
<nxvl> cjwatson: im looking how cp does it to make something like that in scp
<ogra> huh ? 
<ogra> why do i have xterm and uxterm in my menu ?
<nxvl> uxterm is xterm with unicode
<nxvl> somethimes both are installed
<ulaas_> asac, recreated a new user. and now it works...
<ogra> i know what it is, it just has nothing lost in my liveCD menu :)
<LaserJock> mvo: safe mode won't start X
<mvo> LaserJock: oh? 
<LaserJock> Failed to load vbe
<asac> ulaas_: ok so probably gnome-keyring broke compatibility with legacy settings somehow
<asac> ulaas_: please drop that info to bug as well
<mvo> LaserJock: what driver is the thing using that fails?
<LaserJock> vesa
<LaserJock> dlopen: /usr/lib/xorg/modules//libvbe.so: invallid ELF header
<nxvl> cjwatson: can u maybe recomend me a simple bug so i can fix it and learn?
<LaserJock> mvo: ^^ seems to be the source of the problem
<nxvl> cjwatson: i really want to help, but as you can see i'm new on this
<mvo> LaserJock: but that would only explain the failsafe failure, not the regular one? or is vesa used in regular mode too?
<ogra> invallid ELF header sounds bad though
<LaserJock> I don't know, I'll reboot in regular mode and look at the xorg log
<mvo> thanks!
<LaserJock> although X at least starts in regular mode
<cjwatson> nxvl: cp and scp don't share source code, so it might not be trivial
<cjwatson> nxvl: I don't mean to discourage you; it's just that I recently did a pass through openssh and fixed most of the simple bugs I could find ;-)
<asac> ulaas_: btw, please keep the broken user
<cjwatson> nxvl: I believe there's a "bitesize" tag that's intended to be for this sort of thing, and you can query on that
<ulaas_> asac, ooooops
<nxvl> cjwatson: i don't undestand the "bitesize" thing
<asac> ulaas_: thats bad :/
<LaserJock> mvo: well, it's using the vmware driver in regular mode
<ulaas_> asac, my bad. :(
<asac> ulaas_: yeah close bug again then
<asac> ulaas_: if someone else sees it we will get a new one
<cjwatson> nxvl: see https://wiki.ubuntu.com/BugSquad/Tags
<evand> nxvl: https://launchpad.net/ubuntu/+bugs?field.tag=bitesize
<asac> ulaas_: np ... remember that its important to keep broken things in future ... if you want to help :)
<mvo> LaserJock: thanks! out of curiosity (and only if you have it available), does the regular ubuntu-desktop CD crash for you as well?
<LaserJock> I haven't tried it yet, I was thinking the same thing
<ulaas_> asac, will keep that in mind.
<LaserJock> mvo: let me rsync one up and I'll try it out
<nxvl> thnx
<nxvl> i will try that
<nxvl> :D
<nxvl> i whink i will start with ubuntulove
<doko> seb128: I did remove the Hidden attribute from  a menu entry, but I don't see the item appear in the menu, even alacarte doesn't show me the disabled entry. any hints?
<seb128> doko: what menu entry?
<seb128> doko: is there a TryExec? Is the corresponding binary available?
<doko> seb128: ooo-draw, packages from deb http://people.ubuntu.com/~doko/tmp/ooo-feisty/ ./   
<doko> i386 only
<luisbg> pitti, I'm having a major bug with the gutsy tribe 2 test iso
<luisbg> live i386 one
<pitti> luisbg: what's up?
<pitti> luisbg: (sorry, I'm just about to leave for 30 minutes, bbl)
<luisbg> when installing, I choose manual partitioning, then next, and the install program freezes there
<luisbg> tried 3 tiems
<luisbg> times*
* pygi thinks that's a known probolem :)
<luisbg> pygi, seams like a big one to me ;)
<ogra> luisbg: you mean bug #122645  i guess
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitively" [Undecided,Confirmed]  https://launchpad.net/bugs/122645
<luisbg> ogra, yes
<seb128> doko: seems to be listed correctly under "Graphics" on my desktop
<doko> seb128: hrm, yeah, I remember now having removed the entry in the office menu :-/
<evand> luisbg: does it occur when you pass --debug to the installer?
<doko> sorry
<seb128> that's alright
<luisbg> evand, didn't check
<LaserJock> mvo: same thing with Ubuntu Desktop CD i386
<ogra> evand: called as sudo ubiquity --debug it seems to work fine here 
<evand> ogra: so that stops it from hanging for you?
<ogra> right
<evand> hrm ok
<ogra> i wonder if that also happens if i call it with gksu 
<alex-weej> seb128: did you write ubuntulooks?
<ScottK> Is there an archive admin around that might approve clamav 0.90.3-1ubuntu2 (source).  It fixes a common postinst failure, so it'd be nice to have it out along with Tribe 2.
<ogra> evand: gksudo ubiquity --debug hangs
<pitti> evand: I wonder whether it actually works for anyone then...
<pitti> well, davmor2 successfully tested it on xubuntu at least
<cjwatson> ogra: (you never need to run gksudo/sudo; ubiquity does that itself)
<seb128> alex-weej: no, it has been written by the clearlooks upstreams
<cjwatson> ogra: if you get a hang in debug mode, /var/log/installer/debug + /var/log/syslog + /var/log/partman please
<ogra> oki
<seb128> alex-weej: why?
<mvo> LaserJock: what kind of vmware is it? workstation, server, player?
<mvo> LaserJock: what version?
* mvo tries to reproduce
<alex-weej> seb128: gonna try and tackle an old bug that was introduced in edgy
<LaserJock> mvo: it's VMware Fusion
<alex-weej> tab colour highlights
<alex-weej> fails to work in terminal, gedit, ephy's TDI UIs
<LaserJock> hence why I'm suspecting it could be an issue specific to it as I don't know if there are many people using it
<mvo> LaserJock: if there is a way to get into a failsafe terminal  I would be interessted in the output of glxinfo
<ogra> cjwatson: hmm ubiquity doesnt truncate the old log on a new start, right ? 
<ogra> seems my debug log is some MB big ... 
<evand> ogra: it appends
<cjwatson> ogra: nope, intentionally
<LaserJock> mvo: heh, no go. If I start up failsafe terminal and then run glxinfo it kills X immediately
<ogra> while i collect teh stuff and move it around, here a traceback from ym syslog ...
<ogra> http://paste.ubuntu-nl.org/27470/
<ogra> evand, cjwatson ^^
<mvo> LaserJock: ok, I will backlist the vmware driver than. the same happens on vesa_drv.so
<LaserJock> mvo: it's odd that other people using VMware player or server aren't having the issue
<LaserJock> this VMware Fusion is still beta I think so who knows ..
<seb128> BenC, pitti: many apport crashes have still no stacktrace using the new linux version
<BenC> seb128: according to pitti, his test cases passed...I need more info if possible
<seb128> BenC: I'll speak to pitti, I don't know how to debug that, bug most of the bugs we are getting have no Coredump and users are running 2.6.22-7
<ogra> evand, cjwatson, all three logs attached to bug #122645
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitively" [Undecided,Confirmed]  https://launchpad.net/bugs/122645
<evand> thanks ogra 
<pitti> seb128, BenC: it's a miracle to me
<seb128> pitti: that it doesn't work for eveyrbody?
<pitti> seb128: yes
<pitti> seb128: I'll ask in the bug to run the apport test suite, maybe that reveals the problem
<seb128> you want a list of bugs?
<pitti> seb128: that would be nice
<pitti> seb128: and I should really teach apport to not send those in the first place; too bad that we noticed it so late
<seb128> bug #122470
<ubotu> Launchpad bug 122470 in gnome-panel "gnome-panel crashed with SIGSEGV" [Low,Incomplete]  https://launchpad.net/bugs/122470
<seb128> bug #122511
<ubotu> Launchpad bug 122511 in rhythmbox "rhythmbox crashed with SIGSEGV" [Medium,Incomplete]  https://launchpad.net/bugs/122511
<pitti> seb128: do you get the effect yourself?
<seb128> let me send a SIGSEGV to something
<bdmurray> bug 122641
<ubotu> Launchpad bug 122641 in compiz "compiz.real crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/122641
<pitti> seb128: just run /usr/share/apport/testsuite/run-tests
<pitti> seb128: that does plenty of SIGSEGVing
<pitti> seb128: you need to empty /var/crash first, though
<seb128> Test add_gdb_info() with a script. ... Failed to read a valid object file image from memory.
<seb128> warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000.
<seb128> FAIL
<seb128> FAIL: Test add_gdb_info() with a script.
<seb128> ----------------------------------------------------------------------
<seb128> Traceback (most recent call last):
<seb128>   File "/usr/share/python-support/python-apport/apport/report.py", line 1179, in test_add_gdb_info_script
<seb128>     self.assert_('libc.so' in pr['Stacktrace'] )
<seb128> AssertionError
<pitti> seb128: ah-haa
<Admiral_Chicago> pitti: the release notes should be finished for xubuntu as well, the wiki does not have content but we are fleshing things out in a meeting
<pitti> Admiral_Chicago: thanks
<Admiral_Chicago> i'll mail you when i'm happy with them. thanks
<pitti> seb128: if you run '/usr/share/apport/testsuite/test-apport kernel', how far does it get?
<seb128> * Check test process creation/killing with apport
<seb128> Traceback (most recent call last):
<seb128>   File "/usr/share/apport/testsuite/test-apport", line 165, in <module>
<seb128>     check_crash()
<seb128>   File "/usr/share/apport/testsuite/test-apport", line 60, in check_crash
<seb128>     assert not os.path.exists('core'), 'no core dump in current directory'
<seb128> AssertionError: no core dump in current directory
<pitti> seb128: did you have a core file in . before?
<seb128> no
<pitti> seb128: hm, so something is really broken here
<pitti> seb128: do you have something interesting in /var/log/apport.log?
<seb128> $ /usr/share/apport/testsuite/test-apport kernel
<seb128> Traceback (most recent call last):
<seb128>   File "/usr/share/apport/testsuite/test-apport", line 147, in <module>
<seb128>     assert apport.fileutils.get_all_reports() == [] , 'no reports already present'
<seb128> AssertionError: no reports already present
<seb128> 
<seb128> that's with a _usr_share_apport_testsuite_test-apport.1000.crash in the directory
<pitti> seb128: right, that's expected
<pitti> seb128: the test suite requires /var/crash to be empty for useful checks
<seb128> if I rm the crash I get the "AssertionError: no core dump in current directory" again
<pitti> seb128: oh, btw, please killall update-notifier before starting the test
<pitti> weird
<ogra> pitti: so do you plan to wait for a fix to bug #122645 ? looks quite critical 
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitively" [Undecided,Confirmed]  https://launchpad.net/bugs/122645
<seb128> no difference without update-notifier
<pitti> seb128: the description is a bit misleading, it means that there is a core file which shouldn't be there
<pitti> ogra: if we get one today still, then I might reconsider
<pitti> ogra: testing everything is expensive, but doable on one day
<ogra> well, its a typical tester thing to use manual partitioning i guess
<seb128> pitti: there is only a _usr_share_apport_testsuite_test-apport.1000.crash created when running the testsuite
<ogra> at least if i watch my testing behavior :)
<pitti> seb128: can you please rm /var/crash again and that core file, and /var/log/apport.log, then run test-apport, and then send me the log file?
<pitti> seb128: but you are on 2.6.22-7, right?
<seb128> pitti: there is no apport.log created
<seb128> $ uname -r
<seb128> 2.6.22-7-generic
<seb128> ah, test-apport
<seb128> sorry, I tried the kernel thingy
<pitti> seb128: right, 'test-apport kernel'
<seb128> k, no log then
<pitti> seb128: there is another mode 'lib' which doesn't work in the installed system
<evand> of course I'm the only one who cannot reproduce the bug on real hardware
<pitti> seb128: can you please have a look at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/119267 ?
<ubotu> Launchpad bug 119267 in linux-source-2.6.22 "apport patches for CORE_REAL_RLIM and limit overriding do not work any more" [High,Fix released]  
<seb128> pitti: trying that
<pitti> seb128: in the description I describe some basic tests (without apport) to check the kernel behaviour
<pitti> seb128: and describe behaviour on -6 and the expected one
<seb128> pitti: 
<seb128> $ ls -l /tmp/env /tmp/crash
<seb128> -rw-r--r-- 1 root root 831488 2007-06-27 22:35 /tmp/crash
<seb128> -rw-r--r-- 1 root root    151 2007-06-27 22:35 /tmp/
<seb128> $ grep RLIM /tmp/env
<seb128> CORE_REAL_RLIM=0
<pitti> seb128: ulimit -c is 0?
<seb128> yes
<seb128> I followed the bug
<seb128> the "In this case, CORE_REAL_RLIM should be 0 (since -1 means 'unlimited') and /tmp/crash should have the entire core dump (but is empty)."
<pitti> right, your output looks fine
<seb128> seems to be the correct then
<pitti> seb128: ok; I have some more ideas, let's do this in /msg to not spam the channel
<seb128> k
<ajmitch> morning
<hunger> Did somebody already succeed in getting vmware to run on gutsy?
<pitti> o/
<pitti> hunger: vmware 6 runs nicely (even amd64), but requires BenC's fixed vmnet.tar
<hunger> Where can I get that?
<pitti> BenC: ^ is this on any public place? or the diff?
<Daviey> Oh goody, i would like that file aswell :)
<stgraber> I've found a fixed vmnet.tar somewhere on the forum working just fine with 2.6.22-7 but would also like something more "official" :)
<hunger> stgraber: You still got the URL?
<stgraber> let me check
* hunger would be sooo happy if vmware got into the restricted modules... but that is probably impossible.
<hunger> There are vmware-player debs in aptitude... too bad that those are terribly out of date:-(
<stgraber> http://npw.net/~phbaer/vmnet.tar
<stgraber> found in : http://ubuntuforums.org/showthread.php?t=478611
<hunger> stgraber: THANKS!
<Daviey> stgraber: ty
<stgraber> np
<superm1> cjwatson, ping.  I wanted to see what your thoughts would be on bug #122040
<ubotu> Launchpad bug 122040 in casper "Casper should depend on discover1" [Undecided,New]  https://launchpad.net/bugs/122040
<cjwatson> superm1: I think that's wrong, really; it's up to xserver-xorg to install what it needs
<cjwatson> casper shouldn't have the dependency because xserver-xorg might (quite realistically!) change what it needs to discover hardware
<superm1> ah i see
<cjwatson> xserver-xorg Recommends: discover1 | discover as it is
<cjwatson> so I think honestly this is just a bug in the construction of the third-party disks
<superm1> okay i'll kill the bug then.  Wish I saw the recommends: discover1 in the first place :)
<RadiantFire> ftopic
<RadiantFire> oops :-(
<bdmurray> pitti: have you found anything more out about apport crash reports?
<pitti> bdmurray: no, I debugged something with seb128 for an hour, but no result; he doesn't get the effect
<pitti> bdmurray: I filed https://bugs.launchpad.net/ubuntu/+source/apport/+bug/122688 now, it has a list of affected bugs
<ubotu> Launchpad bug 122688 in apport "produces empty core dumps" [High,Incomplete]  
<pitti> bdmurray: in those bugs I ask the reporters about diagnosing apport itself
<pitti> bdmurray: if you find more of those, maybe you can copy&paste that comment
<bdmurray> pitti: sounds good
<pitti> bdmurray: I'll think about it again tomorrow
<pitti> bdmurray: at least the tags are right, so we can automatically traverse the bugs and reject the broken ones
<pitti> I'll care about that once the issue is fixed
* pitti falls into bed, cu tomorrow
<pitti> bdmurray: did you see anything else OMGbug apart from apport and ubiquity partitioner?
<ajmitch> bye pitti 
<bdmurray> pitti: nope
<pitti> bdmurray: ok, fine
<pitti> bdmurray: we have to live with those warts, I'm afraid
<pitti> I'll release-note them
#ubuntu-devel 2007-06-28
<paul_d> wish bug status is gone?
<gnomefreak> paul_d: no
<gnomefreak> i just marked one as a wishlist like 10 minutes ago
<paul_d> maybe inaccessible to bug squad?
<gnomefreak> paul_d: you have to be part of the qa team please continue this in #ubuntu-bugs
<bdmurray> paul_d: yes, you need to be in ubuntu-qa to set bug importance
<sladen> pitti: there's broken issues with gdb at the moment on 2.6.?? kernels
<sladen> pitti: google for "Failed to read a valid object file image from memory."
<bdmurray> sladen: what is the status of bug 32150?
<ubotu> Launchpad bug 32150 in acpi-support "/etc/acpi/hibernate.sh should bail out if /sys/power/resume is 0:0" [Medium,Incomplete]  https://launchpad.net/bugs/32150
<sladen> bdmurray: I've assigned it to me, I suspect it might actually want to go into pmi instead
<sladen> or even both
<bdmurray> sladen: okay thanks!
<bdmurray> it ended up on the list of hug day bugs
<sladen> bdmurray: oooh, funky.  It is a year old
<bdmurray> well, I / we've been trying to do some cleanup
<bathym> hi gang
<rproenca> hi mpt, I just replied by email your comment at my blog
* mpt wonders which Weblog is rproenca's :-/
<mpt> oh wait, he/she replied by e-mail
<enrico> fabbione: I've uploaded in Debian a new libept that should work on sparc as well as ia64 and hppa
<pygi> mpt, he
<mpt> yes, found it :-)
<Detron> Hi. I'm a software engineer, and I'd like to help Ubuntu out. Any pointers?
<crimsun> https://wiki.ubuntu.com/MOTU/Contributing
<RAOF> Detron: Depends on what you want to do.  Just helping out an upstream project (Gnome, KDE, whatever) helps us.
<RAOF> Or you can listen to crimsun :)
<Detron> hmm.
<RAOF> Basically, if you want to code, find (or found) a project that interests you and start contributing (patches to fix bugs, new features, etc).
<Detron> Probably would be best to help out an upstream project. I've had my eye on Network Manager. Wireless support is the only thing holding me back laptop wise.
<Detron> Ideally I'd like to switch back to linux entirely once my 3 year update cycle hits again.
<RAOF> Go for network manager :).  Although what it does now, it does pretty well (and support now seems limited by wireless drivers rather than n-m bugs), but there's some cool stuff to work on there (connection sharing, multiple active devices, networking-before-login).
<Detron> I'll probably try to work on a variety of projects. Unfortunately I'm interning this summer and the apartment the company provided doesn't offer internet (and it's silly to try to get broadband set up for a month).
<crimsun> http://www.gnome.org/projects/NetworkManager/developers/
<Detron> It's painful using linux without apt-get...lol.
<Detron> yup, there now.
<crimsun> you'll also want to speak with Lure, asac, and giskard.
<crimsun> they've touched it recently in Ubuntu.
<Detron> Alright.
<Detron> Do you know if they've decided to drop PPC support or what? I'm grabbing an iso now that's fiesty ppc.
<Detron> Or is it community supported now?
<RAOF> Community supported.
<Detron> bummer.
<Detron> Guess it makes sense though.
<vlowther> /who BenC
<mjg59> iwj_: Have you confused glx and xgl?
<pdenapo> Hi, I would like to attract your atention
<pdenapo> to an issue that has been reported a long time ago
<pdenapo> that ubuntu cannot detect a serial mouse
<RAOF> bug #?
<pdenapo> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/9068
<ubotu> Launchpad bug 9068 in xorg "Serial mice are not autodetected" [Medium,Confirmed]  
<pdenapo> I think this issue is very important for usability
<pdenapo> Advanced user like myself can edit the xorg.conf file by hand
<pdenapo> and kill the X server process
<pdenapo> but we cannot ask this to newbbies
<pdenapo> it is not acceptable in a distribution intended to be user-friendly for non-technical users
<pdenapo> I would suggest to add an option to use a serial mouse
<pdenapo> at boot time
<pdenapo> Otherwise, if autodection fails, the live CD is useless
<pdenapo> computers with serial mouse are still common in undeveloped countries I think
<pdenapo> and Ubuntu is supposed to suport them
<RAOF> So, (as someone who's not even a MOTU) it seems that what that bug is waiting for is for someone to offer a full solution.  So, the problem seems to be "autodetection cannot work"
<pdenapo> I really don't know, Knoppix for example works fine with serial mouse. I don't know how they do that
<pdenapo> seems to be an mdetect problem
<pdenapo> But I think that autodetection is great when it work
<pdenapo> but it is catastofic when it fails
<pdenapo> so it is not good to depend on it at 100% for something critical
<pdenapo> that results in imposibility to use the system
<pdenapo> so I suggest to provide a way to by pass it
<RAOF> There already is, right?  There's manually editing xorg.conf, and I think that dpkg-reconfigure will offer mouse options.
<Chipzz> pdenapo: serial mice were uncommon 8 or 9 years ago ;)
<Chipzz> pdenapo: everything above 486, and some 486's use ps/2 instead of serial
<Chipzz> and you really don't want to run ubuntu on that kind of hardware I think ;)
<Chipzz> (Xubuntu maybe; big maybe though)
<RAOF> I think the reason why that bug isn't fixed is that its not obvious how to fix it.  The best solution offered seems to be "check whether any mice are detected, and if not assume serial", but it seems that there are different variants of serial-protocols, and it's not possible to autodetect them.
<pdenapo> I'm runnig an AMD athlon K7 with serial mouse!
<pdenapo> (My PS/2 port is broken)
<pdenapo> I insist, if no autodection is possible,
<pdenapo> just offer an option to select at boot time
<pdenapo> like you do with other special hardware
<RAOF> Um, do we?
* RAOF hasn't had to try.
<RAOF> So what exactly is your solution?  You start the LiveCD and... ?
<evand> pdenapo: Are you suggesting a new line in isolinux ("Start with serial mouse support"), or a kernel parameter?
<LaserJock> I'm guessing kernel parameter
<pdenapo> a kernel parameter would be enougth
<pdenapo> to pass to the init scripts
<LaserJock> although I don't know if that really accomplishes much
<pdenapo> I thik this is already done for some hardware
<RAOF> It doesn't sound much easier than editing xorg.conf
<pdenapo> for some laptops for example
<LaserJock> yeah
<RAOF> pdenapo: You're thinking of the "noapci", etc, yes?
<pdenapo> I'm not sure
<pdenapo> I think there are options for some toshiba laptops
<pdenapo> for example
<pdenapo> but I see this is perhaps not intuitive for end-users
<pdenapo> anyhow seems to be easier than editing xorg.conf and killing a process
<pdenapo> specially if you have to do that every time you boot the live CD
<LaserJock> but you have to set the kernel paramater everytime
<LaserJock> seems like documenting using dpkg-reconfigure would be the best way
<pdenapo> perhaps
<Chipzz> pdenapo: actually I think your case of a blown up ps2 port is extremely uncommon; also, there's a difference between an isolinux option to work around broken chipsets, and an option to work around broken hardare (ie, you broke the hardware, we're not expected to supported that, ergo it is not unreasonable for you to edit Xorg.conf and kill the relevant processes)
<Chipzz> but that's just my 2 cents
<Chipzz> the problem is
<Chipzz> serial does not provide any way at all to probe what hardware is behind it
<Chipzz> USB does
<pdenapo> Chipzz: So your idea is that serial mouse is something out of date, even if modern computers still can work with them?
<Chipzz> and PS2 only has mice and keyboards
<Chipzz> pdenapo: not only my idea; most current motherboards do not even *have* a serial port anymore
<pdenapo> I think that an SO should support all the hardware available
<Chipzz> pdenapo: and you have to look real hard to even *find* a serial mouse
<Chipzz> let me tell you, I actually looked for a serial mouse 8 years ago; the only thing I could find were ps/2 mice with a ps/2 -> serial convertor
<pdenapo> I'm really disapointed with ubuntu
<pdenapo> I should say, because of this issue
<Chipzz> pdenapo: but again, I'm not a developer, and it's just my 2 cents
<pdenapo> I cannot pass it to a friend and tell him for sure
<pdenapo> that it will work for him
<LaserJock> pdenapo: well, you can ask him if he has a serial mouse
<RAOF> But you never can.  Theres a bunch of hardware that we don't support well.
<LaserJock> and if so point him in the right direction anyway
<pdenapo> but believe me, here in Argentina, are still common
<pdenapo> ok, we still have many old computers
<LaserJock> pdenapo: I'm not saying we shouldn't support serial mice, I'm just saying that all is not lost
<LaserJock> there doesn't seem to be a straightforward way to fix the issue
<Chipzz> anyway, the issue at hand is that you *cannot* probe serial mice; you have to try all protocols, some of which conflict with each other, and there's no way to tell if the protocol you're testing actually works apart from moving the mouse and not see it jump around on the screen
<LaserJock> as it is inherently difficult to automatically detect hardware that doesn't have automatic detection
<pdenapo> There would be no problem
<pdenapo> if anyhow you had an usable desktop
<LaserJock> well, the point is that we can't necessarily give a person that
<pdenapo> but the mouse seems to be critical in order to be able to use the desktop
<LaserJock> from what it sounds
<Chipzz> pdenapo: anyway, for the sake of argument, lets say an option to ""detect"" serial mice was included; your friend would still have to pick a protocol from a list of over 10 different protocols, and he wouldn't know what to pick. How is that any better?
<pdenapo> I don't know, I just wanted to rause your attention on this issue because I thimk that it is important
<pdenapo> but I really don't know the optimal solution
<RAOF> Which is why it hasn't been fixed yet :)
<pdenapo> perpaps in the mean-time, documenting how to use dpkg
<pdenapo> -reconfigure
<pdenapo> in the release notes would be the more reasonable thing to do
<Chipzz> the only alternative show a dialog on X startup among the lines of: you specified you have a serial mouse; we cannot autodetect this, but this is the list of protocols we already tried, and we're currently testing protocol X. Try moving your mouse around, and if it moves around correctly, press Yes, or press esc if it jumps around.
<Chipzz> and if the user presses esc restart X and try with next protocol
<LaserJock> pdenapo: something like https://help.ubuntu.com/community/SerialMouseHowto
<StevenK> Chipzz: That sounds like an awful lot of work.
<Chipzz> StevenK: I didn't say we should implement that; but I think it's the "most userfriendly" option available at all ;)
<pdenapo> another question: why there is no section "how to install Ubuntu" in the oficial docmentation https://help.ubuntu.com/
<pdenapo> ?
<Chipzz> that is, if the user only has one serial port (because you don't know which serial port the mouse is attached to otherwise, and again, there is no way to tell...)
<LaserJock> pdenapo: the idea is there shouldn't need to be one
<pdenapo> I think it is the first thing that the user will search gor..
<pdenapo> for...
<pdenapo> (sorry)
<pdenapo> But issues like this shows that might be necesary...
<pdenapo> if the user has some hardware that won't be autodetected
<Chipzz> the only alternative I guess is to hope X can make better guesses wrt serial mice in the future, and just rely on that
<pdenapo> he needs to be aware of
<pdenapo> Another minor usability issue: I've seen that for ADSL conections
<pdenapo> there is the ppoeconf utility
<pdenapo> that works fine, but knoppix has a similar utility with a nicer GUI
<pdenapo> perhaps you want to take a look
<poningru> whats the name?
<pdenapo> Sorry I don't know the name
<pdenapo> I was searching in google
<pdenapo> is the same utility but with a Qt based GUI
<pdenapo> it would be nicer to have something like this in Ubuntu
<wolfeon> argh.
<wolfeon> well I gues I should ask motu first :)
<pdenapo> well everybody thank you very much for your listening, good bye
<fabbione> enrico: ok cool
<dholbach> good morning
<pygi> morning dholbach 
* poningru wonders who martin pitt is
<poningru> as in what his nick is
<StevenK> pitti
<poningru> grr guess he isnt here
<Hobbsee> correct
<Hobbsee> he does sleep occasionally
<Hobbsee> poningru: what did you need?
<pygi> Hobbsee, correct
* pygi gives Hobbsee a "Correct answer" medal :)
<pygi> good morning
<poningru> well to the release people: almost done with release notes, will finish up kernel stuff tomorrow after bugging them
<poningru> Hobbsee: just needed extra eyes over https://wiki.ubuntu.com/GutsyGibbon/Testing/Tribe2
<Hobbsee> poningru: right.  looking
<poningru> Hobbsee: havent finished kernel stuff
<Hobbsee> poningru: please dont refer to it as malone
<Hobbsee> Gutsy Gibbon has bugs! (I bet you're not surprised). Your comments, bug reports, patches and suggestions will help fix bugs and improve future releases. Please report bugs through [WWW]  Malone
<Hobbsee> poningru: please use "the ubuntu bugtracker"
<poningru> k
<pygi> Hobbsee, let's first bug we know of :)
<pygi> there's enough of those :)
<Hobbsee> hehe
<pygi> ;)
<Hobbsee> poningru: s/by gnu just/by the GNU project/
<poningru> Hobbsee: err I was instructed to use that... by the gnu people
<StevenK> It auto detects if the system is capable of runing compiz and if not the "metacity" window manager is used. -> "It auto detects if the system is capable of runing compiz and if not, falls back to using the "metacity" window manager." ?
<Hobbsee> poningru: ahhh okay
<Hobbsee> poningru: i just checked their website, and saw the other version
<poningru> yeah I asked them specifically because of that
<Hobbsee> poningru: neat.  taht's fine :)
<poningru> though the capitalization is something I didnt ask
<poningru> StevenK: k
<poningru> sounds better
<poningru> ok going to sleep nn and please continue editing
* TheMuso should make sure that compiz is not enabled when accessibility is, but I think it may be.
<StevenK> Yeah, Bart found that Compiz doesn't talk when you Alt-Tab between windows.
<TheMuso> StevenK: Ah ok, so it does get enabled.
<TheMuso> Will have to work on a fix for that post tribe 2.
<fabbione> hmmmm
<fabbione> i wonder why "Move to another workspace" doesn't work properly anymore
<Hobbsee> poningru: s/Allowing the users /Allows the users/ .  Or fix the other tenses, etc.
<fabbione> it works once and then stop
<StevenK> TheMuso: Oh sorry, that was for Feisty. Not sure if it's the case for Gutsy.
<TheMuso> StevenK: Ah ok. Will have a look in a while.
<fabbione> cjwatson_, evand: i would like to upload os-prober after tribe2 to fix a stupid bug on sparc that would spawn (only in certain partition layouts) an extra entry (see #122756). The fix is already in bzr.
<pitti> Good morning
<fabbione> hey pitti
<fabbione> pitti: sparc-server 27 tested.
<fabbione> pitti: all good.. 2 minor bugs tho
<fabbione> pitti: one sparc, one generic
<dholbach> hey pitti!
<pitti> fabbione: yay, any problems?
<fabbione> pitti: nothing major. and one has a fix in bzr already. waiting main to open to upload
<pitti> fabbione: good to hear that the kernel issue is fixed at least :)
<Hobbsee> morning pitti!
* pitti hugs Hobbsee 
* Hobbsee hugs pitti 
<Hobbsee> pitti: i've just discovered the most gorgeous set of icons in the world :)
<fabbione> pitti: yeah that too.. 
<pitti> Hobbsee: :)
<Hobbsee> pitti: http://everaldo.com/crystal/?action=preview :)
* StevenK waves to pitti 
* pitti grumbles; now all fonts are too big, and the DPI setting in Appearance doesn't have any effect any more
<pitti> hello StevenK!
<pitti> Hobbsee: schweeeeet
<Hobbsee> pitti: oh yes.  oh yes.  this is kubuntu-default material, when a package is made :)
* Hobbsee hugs mvo 
* mvo hugs Hobbsee
<Hobbsee> :)
* pitti gives mvo a big hug
<mvo> hey pitti :)
<gnomefreak> mvo and pitti the bugs i filied i may close in next few days since i reinstalled and nothing has crashed nor has frozen so something on my system was messed up
<fabbione> dholbach: ping?
<pitti> gnomefreak: the ones about crashing compiz?
<gnomefreak> pitti: yes and gnome-appearance and apport-gtk crash
<pitti> gnomefreak: sweet
<pygi> dholbach, you're spamming me :P
<pitti> LaserJock, ogra: can you, or do you know someone who can give edubuntu server/i386 some testing?
<pygi> hey phoenix24 
<phoenix24> hey pygi 
<stgraber> pitti: I'll once at home, if 11:30 CEST isn't too late for you
<pitti> stgraber: no, that's fine; thank you!
<pitti> stgraber: maybe ogra already tested them and just didn't report the results yet, let's wait for him as well
<stgraber> pitti: Last time I checked we had 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
<stgraber> (debian-installer had some problem with the new squashfs ltsp image)
<pitti> stgraber: erk; that sounds, like, RC?
<StevenK> pitti: No fair listing cruft if the replacement hasn't cleared NEW yet. :-P
<pitti> StevenK: heh :)
<dholbach> fabbione: pong
<nixternal> I am creating a package for an icon them, the root dir has no license file, the website the package is from states it is lgpl. how do I go about packaging this correctly/legally? put the LICENSE file in the debian/ dir and add it to the debian/docs file, create a patch to add the LGPL file to the root dir?
<dholbach> pygi: you could have set those bugs to 'incomplete' yourself ;-)
<pygi> dholbach, that's not an excuse :) Just leave the cd-recording bugs to me if you want, I can handle mostly :) Also, I'll take some time next week to look over telepathy bugs
<StevenK> nixternal: Sounds like what Hobbsee was talking about.
<pygi> perhaps I can sort something out ... not as knowledgable in that area, but ...
<nixternal> hehe
<dholbach> pygi: thanks - that nice of you
<nixternal> I asked her first and she said ask here :)
<pygi> dholbach, if you don't mind ofcourse ^_^
<dholbach> pygi: just mark them as 'incomplete' if you ask for more info
<pygi> dholbach, ofcourse :) Sorry, closed 50 bugs in two days, that was too much :)
<pygi> well, fixed some, and stuff =)
<dholbach> no problem :)
<dholbach> good work
<pygi> heh, don't tell me good work
<pygi> tell it to yourself and every else here :)
* pygi hides now
<fabbione> dholbach: hey dude.. i am having a problem with gnome i think.. just wondering if it's known already.. basically any window i open, the "Move to anotehr workspace -> Desk N" doesn't work
<fabbione> dholbach: this is gutsy very latest bla bla bla
<dholbach> fabbione: is that with compiz?
<fabbione> dholbach: how can i help to look into this?
<fabbione> dholbach: i didn't enable compiz myself.. let me check
<dholbach> ps afxvw | grep compiz
<pygi> fabbione, compiz is auto-enabled
<fabbione> dholbach: no compiz
<pygi> if hardware supports it AFAIK
<fabbione> dholbach: the "Desktop effects" confirm that it is not enabled
<fabbione> pygi: i already had compiz before the switch and manually switched it off..
<dholbach> alright, because compiz has lots of known issues with workspaces/viewports
<fabbione> pygi: if my settings have been changed, that'd be another serious bug
<dholbach> does it work with a new user? (you could test in gdmflexiserver --xnest)
<pitti> fabbione: confirmed (with metacity)
<pitti> dholbach: ^
<fabbione> pitti: ok thanks.
<dholbach> pitti: weird - it works nicely for me
<dholbach> pitti: do you know the bug number? if not, I'll look it up myself
<pitti> dholbach: it stopped working a few days ago, but I didn't find the time to report it yet
<fabbione> pitti: i noticed only yesterday with a few windows.. after a logout/login all of them
<fabbione> so i want to believe it's some library that did change
<pitti> dholbach: 'move one workspace right' works, but not 'move to nth workspace'
<fabbione> dholbach: i didn't report it either.. wanted to check with you first to spare you a dupe
<fabbione> pitti: confirmed that too
<dholbach> pitti: move to workspace n works for me
<dholbach> I just tried xchat-gnome and gnome-terminal
<fabbione> dholbach: even more than once?
<pitti> dholbach: I want the fix, too
<pitti> dholbach: do you use compiz?
<fabbione> dholbach: sometimes it did work the first time and stopped at the second
<dholbach> pitti: no
<dholbach> fabbione: yes
<dholbach> it's broken with compiz
<pitti> well, compiz breaks *everything* wrt. workspaces, that one is the least of all evils :)
<dholbach> no ubuntu bug filed yet - I'll look for upstream bugs
<dholbach> hrm... b.g.o seems down
<Admiral_Chicago> pitti: release notes are done to a level i am satistied with
<pitti> Admiral_Chicago: thanks for putting this together!
<Admiral_Chicago> no problem. good luck on the release. i need sleep now
<pitti> seb128: did you see something like this in yesterday's apport tests: "warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000." ?
<seb128> pitti: "<seb128>	Test add_gdb_info() with a script. ... Failed to read a valid object file image from memory."
<seb128> pitti: "<seb128>	warning: Memory read failed for corefile section, 4096 bytes at 0xffffe000."
<seb128> "<seb128>	FAIL: Test add_gdb_info() with a script."
<seb128> 
<seb128> that's from yesterday evening
<pitti> seb128: that very; was this on a live CD or your production system? IOW, did you have build-essential installed?
<seb128> on my desktop
<seb128> and it has everything required to build the GNOME stack
<pitti> seb128: ok, so that's not it; I got some logs to bug 122688, and one didn't have libc6-dev installed, but that memory read error was on all of them
<ubotu> Launchpad bug 122688 in gnome-speech "produces empty core dumps" [Undecided,New]  https://launchpad.net/bugs/122688
<pitti> seb128: something is fundamentally wrong on i386; I guess I just have to do an i386 installation to figure this out
<pitti> seb128: at least I perfectly reproduced the symptoms of the bug reports; it's really from 0-byte core dumps (as opposed to some wrapping/formatting bugs in apport)
<pitti> seb128: so I'll (1) make apport not create reports for those, and (2) install i386 to find out why that happens 
<seb128> pitti: I can do remote debugging for you if you want or try to make some forwarding and create you an account if that's easier than doing an install
<pitti> seb128: install should be fine
<_spin> how difficult is it to join the team and start fixing bugs?
<pitti> _spin: not at all; we specifically maintain a list of bugs which are easy to fix, for new contributors
<pitti> _spin: in principle, you can always attach patches to bugs; this is heavily appreciated
<_spin> how does the integration process work?
<pitti> _spin: after patching a bug you should contact a developer about applying it; you can mail the maintainer (if there is one), or generally just ask in #ubuntu-motu
<pitti> _spin: people in #ubuntu-motu should be able to direct you to the appropriate person, or just upload it themselves
<pitti> _spin: and when you learned the Ubuntu specific processes, you can become a developer yourself
<pitti> _spin: https://wiki.ubuntu.com/HelpingWithBugs and https://wiki.ubuntu.com/UbuntuDevelopment are good entry points for learning more
<cjwatson> fabbione: sure, though please commit it upstream as well if you haven't already
<fabbione> cjwatson: sure i can do that, but silo-installer in Debian doesn't use os-prober yet.. 
<_spin> pitti: thanks for the help
<pitti> you're wel... disappeared already
<cjwatson> fabbione: you could commit that too while you're at it ;-)
<fabbione> cjwatson: ok.. i guess i will need to show up on #debian-installer again
<cjwatson> (that's #debian-boot)
<fabbione> yeah noticed :)
<geser> pitti: Hi. I started looking at the rdepends for apache. The order of alternatives doesn't matter, right? So something like "Depends: ..., apache-common | apache2-common | apache2.2-common, ..." is no problem?
<pitti> geser: right
<pitti> geser: it's not ideal, but works
<pitti> geser: and they'll eventually be fixed in Debian
<geser> that's my hope too
<geser> the first blocker I found is slash, Debian bug #429071
<ubotu> Debian bug 429071 in slash "please update/request removal of your package" [Serious,Open]  http://bugs.debian.org/429071
<iwj> mjg59: Yes.
<Keybuk> Nafallo: "start" :-)
<Nafallo> Keybuk: something like that.
<Nafallo> :-)
<ajmitch> geser: yes, there are plenty of bugs filed in debian, I've found a few that can just be synced
<ajmitch> see the rc bugs list that I generated, a few of them are apache-related
<stgraber> pitti: starting edubuntu i386 server testing now, you should have the result in something like 30 minutes
<pitti> stgraber: great! wow, that's fast
<iwj> Hmm.  I wonder if I'm just unlucky with this i810-based board, or whether VC switching is generally not reliable nowadays.
<sladen> iwj: i810-based board with an ATI video chip sitting on it?
<pitti> iwj: I have problems when using composite (switchign back to X -> black screen and hang), but not with metacity
<pitti> seb128: I might have an idea about apport: I just use a single read() call for reading the core from stdin; if the kernel isn't fast enough, this delivers 0 bytes and I stop reading
<iwj> sladen: Err, no, the i810's built in graphics.  I assume it's actually intel; at least none of the logs etc. say anything about ATI.
<pitti> seb128: this has never actually caused any trouble with 2.6.20, but maybe some internal stuff changed in .22 to make it more prone to race conditions
<iwj> pitti: Hmm.  Maybe I should turn off compositing and see if that helps.
<seb128> pitti: ah
<pitti> seb128: I just committed some patches which ignore 0-byte core dumps as a bandaid
<seb128> ok, good
<pitti> seb128: after tribe-2 I'll write a test case for delayed stdio feeding, fix problem_report accordingly and upload
* seb128 hugs pitti
<pitti> seb128: of course we'll don't see empty cores any more anyway, but it might help
<pitti> seb128: but I don't want to rebuild CDs for that TBH; let's rather clean up the broken bugs automatically (I'll write a script); do you agree?
<seb128> pitti: yeah, no need to roll new CD, I want to unfreeze so we can work again now :p
<pitti> seb128: feel free to upload stuff, it'll pile up in the queue
<stgraber> heno: didn't you see a bug with the "You are here" path on the tracker ? it seems it doesn't show the testcase part when you are on the test results list ...
<seb128> pitti: right, I don't like to pile too many changes though, I prefer progressive testing ;)
<stgraber> heno: this function will definitely need a big rewrite :), it was ugly but at least it worked which seems to be no longer the case :)
<heno> stgraber: indeed, I've been making a list :)
<stgraber> I've also the "milestone report" drop-down menu which should show the current milestone by default rather than the first (sorted by name), will add the _getpath function in my need a quick fix todolist :)
<pitti> ogra: here?
<ogra> pitti, i tested all former isos, but not the current one, thats currently running
<pitti> ogra: ah, ok; you are testing edubuntu/i386?
<pitti> ogra: server, I mean?
<ogra> yep
<sladen> iwj: actually, I was looking at a machine yesterday with Intel graphics and VC switching issue.  The solution was to C-M-F7 C-M-KP- C-M-KP+  to flip the mode and back again
<pitti> ogra: stgraber does as well, maybe you can coordinate
<ogra> sure
<pitti> ogra: well, autoresize etc. is already covered by the other ISOs, so I guess there's no need to test every variant
<pitti> ogra: thanks *hug*
<ogra> :)
<stgraber> ogra: It's currently installing the desktop packages on an "erase all" install
<pitti> asac: https://wiki.ubuntu.com/GutsyGibbon/Testing/Tribe2 calls the ffox 3 alpha 'Minefield'; I thought this was 'Gran Paradiso'?
<ogra> stgraber, there is one ltsp bug i didnt file yet, you need to comment next-server in the dhcpd.conf (fixed in my local branch already) debian cant do without it it seems :)
<stgraber> ok :)
<pitti> ogra: WDYT about bug 121547? does it affect everyone?
<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> pitti, yes, every server install
<pitti> ogra: ah, that's the "unresponsive" issue
<pitti> ?
<ogra> (...of edubuntu)
<ogra> yeps
<asac> pitti: yes thats granparadiso
<pitti> ogra: that sounds worth mentioning in the release notes
<ogra> it takes 8min here for me for the mksquashfs run ... during that time you dont have disk activity or so as you usually have once in a while in d-i
<ogra> yeah
<pitti> asac: ok, I'll change that
<pitti> ogra: can this be fixed (progress bar or so) for tribe-3?
<ogra> yep
<ogra> planned
<asac> pitti: thanks ... is freeze lifted?
<pitti> asac: no, we haven't released yet
<asac> ok
<stgraber> davmor2: hi, you spoke about bug 121547 on your edubuntu "erase disk" test but not with "manual partitioning", you also had it with this one 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
<davmor2> stgraber:  yes but it was so late by the time I finished that I was going to look for it today.
<pitti> can some interested people and also native English speakers please have a look at https://wiki.ubuntu.com/GutsyGibbon/Testing/Tribe2 and point out missing things and typos?
<stgraber> davmor2: I've updated your test result adding the bugnumber
<iwj> sladen: Hmm.  I'm not really looking for a workaround.  It's related to UnifiedLoginUnlock which will involve a lot more VC switching.
<davmor2> Yes I noticed ta I was about to
<iwj> pitti: The section on GNOME 2.19.4 uses the word `release' too many times.
<iwj> pitti: The `,' after `easier to install' in the Gnash section should be a colon or full stop.
<iwj> pitti: Do you want me to edit it ?
<iwj> Urgh!  `utilize'!
<iwj> Excuse me.
<pitti> iwj: I'm at it
<pitti> iwj: apparently this was written at late night by Corey :)
<iwj> pitti: OK :-).
<iwj> pitti: Punctuation in the Gnash section is generally a bit odd.
<pitti> iwj: I fixed your first two issues, but I won't save the page for every small change
<iwj> OK
<iwj> pitti: Change `utilize' to `use'.  (in XDG)
<pitti> iwj: I saved the page now, so if you have more changes, it might indeed be easier if you edit them, right
<iwj> OK
<iwj> Is there some house style that prefers `_The_ Gutsy Gibbon Tribe 2' ?  It reads oddly to me.
<davmor2> pitti: barreling looks wrong shouldn't it be double l
<iwj> davmor2: Fixing.
<pitti> sladen: ah, thanks for your mail re gdb on 2.6.22; I'll have a look
<pitti> iwj: I'm not picky about the article :)
<wolfeon> you guys are stuck with me ;) I'll keep fixing bugs when I see them until bug #1 is done. 
<ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
<davmor2> pitti: what extra effects are enabled when you tick the box I see no difference?
<iwj> pitti: I've edited it a bit.  I think it's improved but someone other than me should do a final proofread.
<stgraber> davmor2: mainly wobbly windows
<pitti> davmor2: the only thing I see is wobbling wins
<pitti> iwj: thanks a lot
<pitti> seb128, dholbach, asac, mvo: any other features you'd like to see mentioned on https://wiki.ubuntu.com/GutsyGibbon/Testing/Tribe2?
<seb128> pitti: no, that's ok for me
<dholbach> for me too
<asac> seb128: me too
<asac> pitti: me too
<asac> :)
<gicmo> seb128: ALTER
<dholbach> gicmo: ALTER
<gicmo> seb128: dude, which products is the file selector in?
<seb128> gicmo: Alter!
* gicmo needs to file bugs
<gicmo> dholbach: ALTER!
* dholbach hugs gicmo
<seb128> gicmo: gtk+2.0
<gicmo> dholbach: dude, long time no see, how is stuff going?
<dholbach> gicmo: very well - how are you?
<seb128> gicmo: or libgnomeui for the vfs backend
<davmor2> query then how do you enable the water effects?  Do you need to use gconf-editor?  if so what do I need to put in
<gicmo> dholbach: a little headache .. had to give 3 lectures this monday and tuesday so a bit "burned out"
<dholbach> ouch :-(
<gicmo> seb128: hmm I guess libgnomeui then
<dholbach> hope you have time to relax on the weekend
<seb128> gicmo: what is the bug?
<mathiaz> pitti: isn't tribe2 the second alpha release of Ubuntu 7.10 ?
<gicmo> seb128: 2 things, first I have two Desktop entries there (seems like a xdg-folder thingy) but the bug indeed is that clicking on recently used stuff blocks
<gicmo> I mean not really blocking but if you then click away from form recently used to another folder it wont refresh instantly but still populating recently used
<gicmo> (did I get the point through now?)
<stgraber> ogra: ouch, mksquashfs is flooding tty4 :), you didn't add this -no-progress option finally ?
<pitti> mathiaz: it is
<mathiaz> pitti: the wiki page says it's the first alpha release
<pitti> iwj: I added two stanzas about restricted-manager and apport, can you please have a quick proofread?
<pitti> mathiaz: good catch, thank you!
<pitti> fixed
<seb128> gicmo: we already have a bug about the duplicate Desktop entry
<seb128> gicmo: recently used works fine for me
<gicmo> seb128: maybe my list is much biggern then yours
<gicmo> seb128: here it populates the list and while it is populating you cant switch to another folder
<iwj> pitti: Sure.
<mathiaz> pitti: in "Reporting Bugs" section, "a copy for /var/log/Xorg.0.log" should be "a copy of /var/log/Xorg.0.log" ?
<gicmo> seb128: a propos, is there any ui planed to set the folders for the xdg folder stuff
<pitti> mathiaz: right, fixing
<gicmo> since I have Movies here instead of Videos and Pix instead of Pictures
<seb128> gicmo: not that I know but it's likely somebody will write one ;)
<seb128> gicmo: for now gedit .config/user-dirs.dirs
<mathiaz> pitti: and may be not put too many "and" in the sentence.
<mathiaz> pitti: ~/.xsession-errors, /var/log/Xorg.0.log
<pitti> mathiaz: I cleaned up, please have a look
<gicmo> seb128: ohh, I also have Photos != Pictures
<gicmo> hmm
<gicmo> isnt there a place with all folders mentioned that can be set?
<iwj> pitti: Edited, but again you'll want a seperate proofreader perhaps.
<stgraber> ogra: apport also report a nbd-server crash (something tried to start it the incorrect way ?) but it seems to be working fine (LTSP boots)
<ogra> stgraber, i guess we need to supress starting by initscript 
<seb128> gicmo: .config/user-dirs.dirs
<seb128> gicmo: /etc/xdg/user-dirs.defaults
<pitti> iwj: weird, I don't see another edit from you
<gicmo> seb128: so thats all that are available?
<ogra> with an /etc/default setting ...
<gicmo> seb128: thnaks
<seb128> np
<stgraber> ogra: Unable to log in, I see ldm, enter my login/pass, then blackscreen with a waiting cursor ... (May that be related that I'm using an external DHCP and different IPs (172.16.0.0/255.255.255.248) ?)
<iwj> Oh, edit conflict and the wiki has just come back to me.
<iwj> pitti: Fixed now.
<ogra> stgraber, check .xsession-errors
<pitti> iwj: cheers, appreciated
<stgraber> ogra: no ssh connection received on the server ...
<ogra> hmm
<ajmitch> does merges.ubuntu.com still update the suggested merges for packages?
<stgraber> ogra: ok, directly connected to the server I've a different result, I see gnome starting, then the gnome splash for 2s and no more Xorg ...
<pitti> ajmitch: yes, it's usually not taken down at all
<ajmitch> ok
<ogra> that sounds like a crasher ... any traces in .xsession-errors there ? 
<stgraber> ***MEMORY-WARNING***: metacity[20351] : GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon...
* ajmitch will wait until tomorrow to see if the samba merge is updated on there
<stgraber> Window manager error: Unable to open X display localhost:11.0
<ogra> ugh
<ajmitch> each time I go back to it, there's a new version
<gicmo> stgraber: the memory warning is a know issue
<stgraber> ogra: I'm boot a real client to check if it's not a vmware issue
<ogra> why isnt the display set ... thats pretty weird
<ogra> s/set/accessible/
<mathiaz> pitti: in the compiz fusion section, there is a repetition of "going to". Should I update the wiki page ?
<ogra> stgraber, oh, vmware ... indeed, that could be an issue
<pitti> mathiaz: please do, thanks
<ogra> stgraber, LaserJock had display issues in the liveCD with vmware where he couldnt log in ... not sure thats the same issue though
<stgraber> ogra: working on a real thin client (even if I still have the GSlice error in the .xsession-errors)
<ogra> good
<stgraber> so there is an issue with having an external DHCP server (or a different IP class) and a vmware bug
<ogra> so lets blame vmware for now :P
<stgraber> ogra: what's exactly the problem with this next-server thing ?
<ogra> stgraber, we dont need it and its ignored if its unset .... if you set it, tftp will only work wih the set ip
<stgraber> ok, I'm trying to understand why I can boot the client, see LDM but not login with an external DHCP/different IP
<ogra> debians dhcpd needs that option to work at all ... so they added a line with hardcoded ip to the defailt config (which they dnt even use)
<stgraber> ogra: SSH key thing I think
<pitti> ogra: do you happen to know if 'sudo ubiquity' avoids the manual partition hang as well? I don't want to propose --debug in the release notes for password exposure
<pitti> ogra: nevermind, I'll just try it here
<ogra> pitti, i'D have to test that, but currently there is still a manual partitioning install of server running
<ogra> stgraber, very likely, yes
<ogra> stgraber, you could create an lts.conf in your tftp dir  ... and set SERVER as well as SCREEN_02=shell and SCREEN_07=ldm ... that way you get a commandline to check the client logs
<ogra> (/var/lib/tftpboot/ltsp/i386/lts.conf)
<stgraber> ogra: ok, will do
<ogra> also check whats in /opt/ltsp/i386/etc/ssh/ssh_known_hosts
<stgraber> ogra: Can I put the server ISOs as looking good ?
* ogra wonders if our new infrastructure would make fixing bug #122094 possible
<ubotu> Launchpad bug 122094 in gnome-power-manager "Disable compiz/beryl on switch to battery" [Undecided,New]  https://launchpad.net/bugs/122094
<stgraber> pitti: report for edubuntu i386 server is on the tracker
<ogra> stgraber, yep, with the errata for the progress hang and the next-server thing it should be fine
<pitti> StevenK: great
<mjg59> ogra: I'd disagree that it's a bug
<pitti> ogra: what's the bug for the next-server thing?
<stgraber> has anyone tested edubuntu server add-on ? (the WinFOSS part has been done and is ok)
<pitti> ogra: do you want the serveraddons be released at all?
<stgraber> pitti: hehe, yes that's the first question :)
<ogra> pitti, sure
<ogra> even though ...
<siretart> keescook: around? what do you currently use for additional bind mounts in schroot? your patch in debian bug #395062, or have you edited /etc/schroot/*?
<ubotu> Debian bug 395062 in schroot "add additional bind mount points to chroot" [Wishlist,Open]  http://bugs.debian.org/395062
<pitti> ogra: we didn't release them for tribe1 AFAIR, because there hadn't been any changes
<ogra> pitti, well ... i know LaserJoc is working on changes that arent in anyway yet, so we can even skip them this time
<pitti> ogra: I'd like to have a bug about the next-server thing, for referring to in the release notes
<ogra> right, there are no other changes yet
<ogra> pitti, i just hit enter on bug #122796 :)
<ubotu> Launchpad bug 122796 in ltsp "dhcpd.conf broken on tribe2 installs" [Undecided,New]  https://launchpad.net/bugs/122796
<ogra> hmm ... 
<pitti> ogra: splendid, thanks
* ogra changes the title
<ogra> that looks better :)
<pitti> ogra: so the next-server option needs to be commented out? I'd like to have some understandable recipe in the bug for people wanting to fix it
<ogra> pitti, i'll add that, yes it needs to be commented
<ogra> (i'd love it to be not there at all, but then debian moans for months)
<pitti> ogra: is this serious enough for the release notes? I. e. will it break for all people who install it?
<ogra> for all ltsp people
<ogra> it breaks client booting unless you occasionally use 192.168.0.1 as IP 
<ogra> (for the server)
<pitti> ok
<pitti> ogra: so, what do people have to do to fix this?
<ogra> comment the line in /etc/ltsp/dhcpd.conf
<ogra> and restart the dhcp server
<ogra> indeed
<pitti> ogra: restart -> "sudo /etc/init.d/dhcp3-server restart" ?
<ogra> pitti, added the info to the bug
<pitti> Mithrandir, iwj, mvo, ogra: can you please take a look at http://people.ubuntu.com/~pitti/tmp/tribe2-announcement.txt and proofread/verify the known issues and their workarounds?
<ogra> pitti, fine
<Mithrandir> somehow, pointing people to gutsy-changes doesn't really seem very useful?
<pitti> Mithrandir: it says what it is for
<pitti> and it's aimed for developers (u-devel-announce)
<Mithrandir> still, it's like pointing people at a firehose
<ogra> you should notice that its high traffic
<pitti> updated
<ogra> better
<cjwatson> pitti: xpdyinfo -> xdpyinfo
<cjwatson> pitti: wide-scale -> large-scale
<pitti> cjwatson: thanks; that's wrong on the wiki as well then, fixing
<pitti> updates
<pitti> updated, even
<ogra> doko, running oowriter starts a openoffice shel as well for me every time ...
<ogra> *shell
<ogra> is that intentional ?
<ogra> or known
<doko> ogra: on the live CD?
<ogra> no, on a fresh tribe2 install
<doko> ogra: anyway, calc is your man =)
<ogra> oh, right, i forgot :)
<pitti> nixternal: ping
<enrico> fabbione: uploading now to debian a new libept which fixed yet another alignment problem
<enrico> fabbione: with this one, it should be all
<jab00> Hi, I'm running 64bit edgy and I need to run a 32bit binary that depends on some 32bit libraries which only exist in 64bit form. Is there a magic combination of options I can pass to apt-get to get it to download the sources to the libraries and build 32bit versions for use on my local machine?
<realist_> jab00: I wouldn't have thought 32bit binaries would run on a 64bit system, without some sort of 'compatibility mode', how difficult this is to do, I wouldn't know, unfortunately.
<jab00> they run fine when the libraries are there
<jab00> unfortunately by default there are only a few pre-compiled 32bit libraries in the 64bit disutribution
<jab00> unless i have missed something...
<ijuz_> realist_: lots of people are running 32bit userspace on a 64 bit kernel
<ijuz_> jab00: probably you should just try to debootstrap a chroot, but this is not a -devel problem
<realist_> ijuz_: I'm sure they are, but as I said, I wouldn't know how
<jab00> i know but deboostrap chroot is overkill and this question really would be best answered by a developer
<jab00> sorry
<pitti> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-June/000311.html
* ..[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-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Tribe 2 released
<Mithrandir> jab00: no, just use a chroot for it.
<pitti> *phew* :)
<Mithrandir> pitti: \o/
<realist> So a 32bit chroot, would run fine on a vanilla 64bit kernel?
<realist> And, for what architectures?
<cjwatson> realist: Yes. We don't have another good answer right now.
<cjwatson> I'm assuming you're on a PC, so i386 is 32-bit and amd64 is 64-bit
<Hobbsee> yay, pitti!
<realist> So a 64bit kernel will run on an Intel 32bit CPU?
<Mithrandir> realist: no
<Mithrandir> but the reverse is true
<realist> So we're talking IA64, and AMD64?
<ijuz_> a 32 bit CPU will run on a 64bit kernel? ;-))
<ijuz_> realist: why don't you real wikipedia or something? intel IA64 is some dead legacy arch (itanic) that is or was able to run i386 code (also from a chroot possible); AMD64 can run 64 bit kernels for AMD64 and i386 kernels; AMD64 has nothing to do with IA64
<JanDM_> can I ask questions here about the website too? www.ubuntu.com/testing, the link to tribe 2 does not work
<doko> pitti: the queue is still in manual mode?
<pitti> doko: not since 5 seconds ago any more
<doko> pitti: dpkg seems to be stuck?
* Hobbsee gets an accepted mail for mesa.  eep.
<pitti> doko: accepted now, it came between flushing the queue and thawing gutsy
<mjg59> ijuz_: IA64 is (sadly) far from dead
<cjwatson> shawarma: re your question in last week's distro team meeting, I have no objection to kbd-chooser being removed from the archive
<cjwatson> though it would also need to be blacklisted since Debian haven't yet switched to console-setup
<shawarma> cjwatson: Alright. It's been at the top of the universe merge list (in red even) bugging me for a loong time now. I'll be glad to see it go. :)
<TheMuso> [4~/c
<Hobbsee> TheMuso: 42.
<TheMuso> ugh
<Hobbsee> heh
<TheMuso> Damn evil soft/hardware combination.
<Hobbsee> :)
<stgraber> heno: How do you want to proceed with Tribe-2 release on the tracker ? Add a new ISO set called Tribe-2 and swizch Tribe-2 from testing to released (+setting daily CDs as default milestone) ?
<shawarma> cjwatson: Will you take care of having it removed? I have no clue where to start.
<pitti> shawarma: I can kill it from the archive if you want
<pitti> (and blacklist as well)
<shawarma> Yes, please. Only ubuntu-archive can do that, right?
<pitti> right
<pitti> shawarma: what's the rationale for it? it's only a universe pacakge
<pitti> shawarma: no reverse dependencies at all, good
<shawarma> pitti: It's completely useless.
<shawarma> pitti: It's for the installer and we don't use it there anymore.
<shawarma> pitti: It's just cruft now.
<pitti> shawarma: ok, fine for me
<pitti> shawarma: *flush*
<shawarma> \o/
<shawarma> pitti: Thanks.
<hunger> pitti: I think you can flush the vmware-player stuff as well. Its terribly outdated.
<pitti> hunger: hm, but wouldn't it be better to update it rather than kill it?
<hunger> pitti: No need to blacklist it:-)
<hunger> pitti: But I'm probably wrong, I have no clue about all the archives and how you manage them.
<hunger> I just find it confusing to find stuff that won't install.
<ogra> hunger, well, its gutsy :)
<pitti> hunger: right, but still I think it would be nice to update it :)
<hunger> pitti: I do agree.
<hunger> ogra: That's no excuse for having stale stuff... that could get filtered out by scripts.
<ogra> hunger, well, i rather like to put time into fixing stuff instead of investing into working around the breakage ... its a fact that things break for a while if you update code in an OS
<hunger> ogra: sure. I just assumed you'd have scripts that try to fix the broken stuff or draw develop attention to it. That does not seem to be the case as everybody seems to be surprised when I ask about some broken package or another after a couple of days where they won't work.
<ogra> hunger, we call these scripts bugs.launchpad.net ;)
<hunger> ogra: Anyway, you guys are doing a great distro. I'll better just shut up and let you work your magic.
<Hobbsee> hunger: apt-cache unmet -i | less
<Hobbsee> hunger: that's the main script
<hunger> Hobbsee: And there is nothing trying to rebuild the broken stuff, etc.?
<Hobbsee> hunger: depends how it's broken.
<Hobbsee> hunger: the fixing is not automatic, no
<hunger> Hobbsee: Like some deb gets updated with some namechange and there is nothing rebuilding it?
<hunger> Hobbsee: Wow, you guys are better than I thought! Keeping up with all that manually...
<fabbione> enrico: cool thanks
<Hobbsee> hunger: i didnt say that.  i said "depending on how it's broken"
<ogra> woah, not rebooting after na upgrade if you have the3 reboot sign in the systray can make apport really angry it seems 
<hunger>  Hobbsee: Oh, I see.
* ogra gets spammed wildly with carsh meassages)
<pitti> ogra: why apport?
<ogra> pitti, isnt apport the thing that makes the little orange start with crach messages appear ?
<ogra> *star
<pitti> ogra: ah, just because there are actually so many crashes? :)
<pitti> ogra: yep
<ogra> yeah
<ogra> atd seems not to run very stable ...
<hunger> pitti: I guess you can nuke: xen-restricted-modules-2.6.17-6-generic-xen0 from gutsy. One item less in the apt-cache unmet list:-)
<ogra> and gnome-mount crashes every several minutes ... as well as gnome panel ... 
<ogra> funny is that actually nothing of these really crashed ...
<Enola_Gay> hi all
<seb128> ogra: do you use nautilus?
<ogra> seb128, yup
<seb128> there is a known gnome-mount crash when closing the properties of a non local drive
<ogra> well, i didnt touch anything :)
<Enola_Gay> ntfs-3g still seems to be universe in Gutsy. Are there no plans to ship Ubuntu Gutsy with ntfs write support?
<ogra> it just sent several crash messages ... gnome-panel as well, but it works fine and didnt crash
<ogra> i should just reboot :)
<pitti> seb128: darn; my suspicion about not waiting hard enough for stdin flushing was wrong apparently
<seb128> pitti: oh, how do you know?
<pitti> seb128: I wrote a test case
<heno> stgraber: let's mark it released and keep Tribe-2 as the active release for a few days
<pitti> seb128: (http://paste.stgraber.org/1920 FYI)
<evand> Enola_Gay: https://blueprints.launchpad.net/ubuntu/+spec/write-support-for-ntfs
<stgraber> heno: ok, and do we keep the current build for Tribe-2 or add an empty one called Tribe-2 ?
<Enola_Gay> evand: Thanks. How can I search this specs. Is there a special page for this. Launchpad is very huge :)
<heno> stgraber: ok, to separate out the test stats. agree
<Enola_Gay> thx
<RainCT> hi, can some main sponsor check bug 49443? I attached a debdiff I month ago there and have not heard anything about it..
<ubotu> Launchpad bug 49443 in defoma "dfontmgr ships no .desktop" [Wishlist,Confirmed]  https://launchpad.net/bugs/49443
<pitti> BenC: is it possible in theory that apport reading from stdin can hit a EOF, although not all data has been written yet?
<asac> any opinions on whether we want a single flashplugin-alternative for all nsplugin-host applications ... or one alternative for each nsplugin-host application?
<asac> fwiw, nsplugin-host application == firefox, mozilla, et al
<BenC> pitti: shouldn't be, that's what my pipe changes were for
<BenC> we had that problem in Oslo and I fixed it in feisty, and that patch is in gutsy
<pitti> BenC: ok, thanks; I'm still baffled why I sometimes get 0-byte cores
<BenC> pitti: could be something screwy in the logic for resetting the core size for the pipe action
<BenC> maybe check there
<BenC> I remember we had that problem before as well
<BenC> depends if the user had core size set themselves
<pitti> BenC: neither seb128 nor I can reproduce this, it's just the bug reports we get
<BenC> pitti: the case I fixed in Oslo showed as short core sizes too, not zero-size
<pitti> right
<cjwatson> shawarma: for how to get packages removed, see https://wiki.ubuntu.com/UbuntuDevelopment#head-def358a3275878d6188c3daabb36cd868c1f2c49
<cjwatson> Enola_Gay: see https://blueprints.launchpad.net/ubuntu/gutsy
<Enola_Gay> cjwatson: thx
<nixternal> pitti: pong?
<pitti> nixternal: I wanted to ask you whether you were fine with the Kubuntu tribe-2 page
<pitti> nixternal: it's released now in the meantime, though :) ; thanks for it
<nixternal> hehe, no problem the release page should be good, unless someone added something :)
<Riddell> as usual nixternal's page is a work of perfection
<nixternal> why thank you, actually I see a booboo, didn't close a '' tag
<nixternal> and of course I hadn't realised, after looking 2 or 3 times, that today is the 28th :)
<pitti> seb128: can you still reproduce bug 74691 on current kernel?
<ubotu> Launchpad bug 74691 in linux-source-2.6.20 "Unable to debug under 2.6.19: Failed to read a valid object file image from memory" [High,Fix released]  https://launchpad.net/bugs/74691
<stgraber> ogra: argh, my thin client problem isn't related to the ssh key, it's correct in /opt/ltsp/i386/etc/ssh/ and a : chroot /opt/ltsp/i386 then ssh root@172.16.1.2 just work fine ...
<seb128> pitti: yes
<pitti> seb128: oooh, yay regressions
<seb128> pitti: well, not sure what should happen since non-debug backtrace seems to be broken since Oslo sprint
<seb128> "Failed to read a valid object file image from memory." is printed
<seb128> Program received signal SIGINT, Interrupt.
<seb128> 0xffffe410 in ?? ()
<seb128> (gdb) bt
<seb128> #0  0xffffe410 in ?? ()
<seb128> #1  0xbffe9ef8 in ?? ()
<seb128> #2  0xb7dbe68c in ?? ()
<seb128> #3  0x00000000 in ?? ()
<seb128> also
<pitti> seb128: right, but "Failed to read a valid object file image from memory." shouldn't be there
<pitti> seb128: and on amd64, I have nanosleep() and __libc_start_main() in the trace
<seb128> ah
<seb128> lucky you ;)
<pitti> seb128: so, I guess it's time to reopen that bug
<pitti> seb128: fortunately the retracers run on a stable kernel :)
<seb128> ;)
<shawarma> cjwatson: Thanks. I actually meant the act of removing it, not requesting the removal, but clearly that's not my conern. :)
<pitti> BenC: so I opened a gutsy task for bug 74691
<ubotu> Launchpad bug 74691 in linux-source-2.6.20 "Unable to debug under 2.6.19: Failed to read a valid object file image from memory" [High,Fix released]  https://launchpad.net/bugs/74691
<pitti> BenC: it's not the reason for the 0-byte core dumps, but still important
<pitti> BenC: well, gutsy task -> task for 2.6.22
<Nicke_> Speaking of broken packages earlier. The recent security updates for kerberos in feisty broke krb5-user (dependency problems)
<Nicke_> (possible other too).. Any fix in sight? :O
<pitti> Nicke_: shot in the dark: you don't have feisty-security enabled for universe?
<stgraber> ogra: when I try ssh from the thin client I got : 2x "Permission denied, please try again." and 1x "Permission denied (publickey,password)."
<stgraber> ogra: any idea ?
<pitti> Nicke_: (it's not that dark, that's the most common problem)
<Nicke_> pitti: Ah, true.. that fixed it yes
<Nicke_> tu
<Nicke_> ty*
<Nicke_> I should remember to check that next time.
<ion_> keybuk: Youre still using the compiz wallpaper plugin, right? Is it packaged?
<cjwatson> shawarma: indeed, you can't
<cjwatson> stgraber: what version of openssh-server on the server?
<stgraber> 4.6p1-2
<cjwatson> should be ok
<stgraber> cjwatson: yes, I doubt it's openssh related as it works if I'm directly connected to the server (with its DHCP server and on the 192.168.0.0 net), it just doesn't work when I connect from the outside (172.16.0.0) ...
<asac> crimsun: http://paste.ubuntu-nl.org/27622/ ... will go up
<asac> crimsun: please take a quick look ... if you want check debdiff first, i can provide it too
<ogra> stgraber, run ltsp-update-sshkeys and ltsp-update-image (in that order)
<ogra> then reboot the client 
<Mithrandir> bryce: and chance you could do an xorg-server upload in the not-too-distant future?  I'd like to have debug symbols for xephyr. :-)
<bryce> sure, in fact I have xorg-server ready to go now, but was waiting for tribe2 freeze to be over + need a sponsor to upload
* Hobbsee ponders uploading more X.
<bryce> also I have new xorg, xauth, xinit and hopefully today xrandr
<Hobbsee> :P
<Hobbsee> wow
<Mithrandir> see, both of those sorted now.
<Mithrandir> Hobbsee just volunteered to sponsor you
<Mithrandir> :-)
<Hobbsee> hey now, i never said that
<bryce> Mithrandir: I got a patch for xephyr yesterday
<ogra> you are voluntold 
<Hobbsee> ogra: no, it doesnt work like that.
<Hobbsee> ogra: i'm Hobbsee, remember?  :P
<Mithrandir> Hobbsee: sure you did.
<Hobbsee> Mithrandir: nono i'm sure i didnt
<ogra> Hobbsee, it always worked like that ... :)
<Hobbsee> ogra: voluntold doesnt work for people with Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<Hobbsee> 's
<Mithrandir> Hobbsee: I have it here, in grey on black.
<Hobbsee> Mithrandir: i was pondering.  not offering :P
* Hobbsee throws ogra at Mithrandir 
<ogra> pondering loud is half the offer :P
<Hobbsee> heh
<Hobbsee> yes, but only half
<Hobbsee> the problem with sponsoring it is that i wouldnt really understand *what* i was sponsoring, on a code-level.
<bryce> yesterday I found a small but serious bug that debian introduced to dexconfig in xorg, so I'm thinking these packages need to be tested a good bit before uploading
<Hobbsee> bryce: got a repository somewhere?
<bryce> not yet, I need to rebuild packages
<ogra> Hobbsee, being voluntold is the other half here indeed :)
<Hobbsee> heh
<bryce> Hobbsee: but I do have installing/reverting instructions this time :-)
<Hobbsee> bryce: the dpkg shouldnt be buggered up enough to need them :P
<Hobbsee> bryce: it should all "just work"
<kylem> ogra, ping?
<ogra> kylem, pong
<bryce> well then I may need some advice on better ways to revert back to feisty
<bryce> er, gutsy
<Hobbsee> bryce: you're not suddenly running another release due to an updated X.  i'm presuming you mean back to the previous X packages?
<Hobbsee> bryce: sudo dpkg -i <list of debs>.deb
<Hobbsee> usually sudo dpkg -i /var/cache/apt/archives/<listofdebs*version*>.deb
<bryce> right.  here's my instructions so far -- http://people.ubuntu.com/~bryce/Testing/xorg-server/
<bryce> (that is the xorg-server before adding the composite-no-clipping patch for xephyr; the latter I'm building now and will get up to Testing shortly)
<bryce> (this time I'm *not* building mesa at the same time ^o^)
<Hobbsee> haha
<Mithrandir> just get a real machine and you won't feel the pain. ;-)
<Hobbsee> i hear building in the DC is also effective
<bryce> Mithrandir: the problem wasn't performance but debs getting mixed up with each other (I think...)
<bryce> yeah I need to experiment around with faster ways of doing builds (and getting them onto rookery)
<bryce> btw, here's the current state of X packages.  http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<pitti> mvo: btw, I guess bug 115959 can be closed now? the wart about -Browser has a separate bug after all
<ubotu> Launchpad bug 115959 in apt "apt-get source should check the Vcs-Bzr field" [Medium,Fix committed]  https://launchpad.net/bugs/115959
<kylem> bryce, dput is a pretty useful way of getting things into the dc for building
<bryce> my hope is to get all the reds and yellows in the right column turned to green before things freeze up
<mvo> pitti: oh yes, closed. thanks
<kylem> i use dput + rsync to blat stuff into the dc (so the .orig.tar.gz only gets rsync once)
<bryce> kylem: ah cool
* bryce needs to learn more from the master :-)
<kylem> as soon as i figure out which machine has that config, i'll send you the dput.cf snippet
<bryce> great, thanks!
<bryce> are there directions somewhere for logging into / using the DC?
<cjwatson> bryce: you already put stuff on rookery, don't you?
<cjwatson> there's https://wiki.canonical.com/MachineOverview, but I'm sure you must be doing that already
<bryce> cjwatson: yup, yup
<cjwatson> bryce: (you correctly expanded DC to "datacentre", right?)
<bryce> ah, no, thanks, I was guessing Development something
<cjwatson> I thought that might have been it
<pitti> mvo: ergh, the i386 desktop CD fails to start the session in vmware (the usual compiz crash); I didn't have that on amd64
<mvo> pitti: *sigh* I will upload a new compiz now that blacklist vmware too, I had hoped to get along with little blacklisting but if glxinfo kills the session (could you please check that with failsafe?) then I guess there is no choice. or is that a different version of vmware?
<pitti> mvo: no, very same one. vmware 6 x86, with the amd64 and i386 live CDs as guests
<pitti> mvo: I just downloaded it now to finally debug the apport/gdb brokenness on (only) i386
<pitti> mvo: checking what on failsafe?
<pitti> mvo: btw, no hurry to upload for just this change
<mvo> pitti: sorry, could you please log into a failsafe session and run "glxinfo" ?
<mvo> pitti: failsafe X terminal
<pitti> mvo: ah, sure
<mvo> seb128, pitti: what do you think about making "failsafe gnome" not run compiz but metacity?
<mvo> seb128: how hard would that be?
<pitti> mvo: well, that would make sense
<seb128> mvo: seems to be a good idea, open a bug and I'll look at doing it
<mvo> seb128: cool, will do that
<seb128> danke
<bryce> mvo, btw, I have been poking around more looking for ways to get a listing of loaded drivers from X
<bryce> I've found the data structure where the info is kept, but so far haven't found an api that'd let us retrieve it
<bryce> so adding it to xset would probably require first adding an api to X for it.  don't know how involved that'd be...  I'd be very interested in your opinion on how good/bad the parse-from-Xorg.0.log approach is working
<pitti> mvo: failsave gnome or failsave terminal? 
<mvo> pitti: please failsafe terminal
<pitti> mvo: meh, failsafe terminal only brings a black box and hangs X; I guess I'll go with hackign /usr/bin/compiz again to make it start metaity and run glxinfo then
<mvo> bryce: I poked a bit too and my impression is that xf86misc is responsible for it (the extension) and that it would require that the extension grows some more data members and a new protocol version
<pitti> mvo: btw, does the gfxboot option 'start in failsafe graphics mode' influence this? it shouldn't start compiz either
<bryce> mvo, yup, that's where I found it too
<mvo> bryce: look like it something that should first be discussed with upstream, the log reading approach seems reasonsable for now
<mvo> pitti: yes, it will run with vesa and that means that compiz will not run
<pitti> mvo: ok, blacklisting vmware in /u/b/compiz works, and glxinfo reliably kills X
<mvo> pitti: thanks! 
<pitti> mvo: hmm, I'm a bit confused
<pitti> mvo: xorg.conf doesn't have a Modules section, but Xorg.0.log shows that the glx module gets loaded
<pitti> bryce: ^ should that actually happen for drivers which don't support glx? like vga/vesa/vmware?
<pitti> bryce: or will that make mesa software rendering work usually? (but cause glxinfo to crash)
<Treenaks> pitti: x shouldn't crash in it, surely?
<Treenaks> in=because of
<pitti> Treenaks: true, but I'm looking for some details :)
<mjg59> pitti: No, it shouldn't happen
<mjg59> glxinfo should work fine
<bryce> pitti, yes it should; the new xorg is able to autoload modules
<mjg59> pitti: Oh, sorry, I see what you mean
<bryce> pitti, xorg seems to be moving rapidly towards hotplugging everything.  I suspect one day here soon our xorg.conf's are going to be empty except for overrides
<pitti> bryce: right
<bryce> oops, sorry misread
<pygi> bryce, true that
<pitti> bryce: what I meant is, is 'glx' actually supposed to autoload on vesa/vga/vmware?
<bryce> re, loading glx for drivers that don't support glx... that I'm not sure.  I'll investigate today
<bryce> I would guess that is a bug in the module hotplugger
<pitti> bryce: I'd be interested in whether loading glx is the bug or is ok, and glxinfo just triggers a bug in mesa softrendering
<pitti> bryce: if I add a manual Module section without glx, it won't autoload, I figure?
* pitti tries
<bryce> pitti, btw a new mesa 7.0.0 is in gutsy (thanks hobbsee!)  It would be interesting to see if it has the same bug
<Hobbsee> :)
<pitti> bryce: indeed
<pitti> bryce: hm, if I supply a Module section, glx is still autoloaded
<pitti> bryce: is there a way to tell X not to load a module?
<bryce> ah, I suspected as much
<bryce> I will find out
<pitti> well, sudo rm I guess :)
<pitti> it's just a live CD after all
<mvo> bryce: did you tested the current tribe-2 live CD on your amazing range of hardware ? any problems with compiz-by-default that you noticed?
<pitti> bryce, mvo: heh, rm libglx.so was blunt, but effective; glxinfo doesn't crash any more, but glxgears doesn't work, so this breaks mesa softrendering 
<bryce> mvo, don't know about amazing...  ;-)  I tested tribe1, but not tribe2
<bryce> pitti, mailed Q to xorg list
<bryce> mvo, is testing just the desktop x86 cd sufficient?
<mvo> bryce: yes, it should enable compiz automatically if the HW supports it (radeon, intel, ..) or fallback to metacity if the HW is not capable of runing compiz
<bryce> ok
<pitti> bryce: right, so if I leave glx turned on, glxgears works on vesa/vmware without crashing; it's just glxinfo that crashes
<pitti> bryce: so, I'll try this with the new mesa once it's in the archive
<pitti> bryce: and apparently glx loading is correct then
<pitti> (might still be a bug in libglx.so itself, of course)
<tkamppeter> Is there no devel team meeting currently? Noone is talking on #ubuntu-meeting.
<pitti> tkamppeter: it was 1.5 hours ago
<bryce> ok cool
<tkamppeter> Sorry.
<bryce> pitti: this is the same glxinfo bug we bumped from tribe2, right?  I should do more digging into this.
<pitti> bryce: ooh, it's built everywhere
<pitti> bryce: the one mentioning a particular graphics card? yes, I think so
<pitti> bryce: I left a comment there saying 'me too on my hw ...'
<bryce> I seem to recall I was able to replicate it on at least one of my machines
<pitti> meh, tribe2 is two hours old, and already 20 MB of stuff to upgrade
<kylem> pitti, the eternal sound of progress.
<bryce> heh, I suppose a goodly chunk of that must be mesa
<pitti> yes
<pitti> -mesa-dri is 12 MB alone
<ogra> mesa is da evil ... (size wise)
<pitti> well, but -dri actually got SMALLER by 2 MB; nice
<Amaranth> pitti: compared to what?
<ogra> still leaves me 10M oversized :P
<Amaranth> feisty?
<ogra> Amaranth, last package
<pitti> Amaranth: to the previous version
<Amaranth> graphics drivers are pretty big :P
<pitti> Amaranth: still, I guess all the intel ones have a good deal of common code in their 2 MB driver blob
<Amaranth> whoa, what'd you remove?
<pitti> bryce: nope, still crashes with new mesa
<bryce> rats
<pitti> mvo: so maybe you can blacklist vmware as well for now, to allow us poor testers some sanity :)
<mvo> pitti: done
<pitti> mvo: I just wonder why it works on amd64
<pitti> mvo: ah, because glxinfo doesn't crash the X server, but just crashes itself :)
<mvo> haha
<pitti> bryce: http://people.ubuntu.com/~pitti/tmp/glxinfo-vmware-crash-amd64.png
<pitti> bryce: the same command crashes on i386 in the very same environment
<pitti> bryce: is that error message on amd64 helpful in any way?
<pitti> mvo: however, just pure luck I guess; it did crash on the previous CD
<pitti> bryce: 'BadAlloc' -> does that sound like a bug calculating a buffer size? int wrapping or so?
<bryce> ahh, I saw a bunch of reports of that
<mvo> pitti: right, I had this one too
<mvo> pitti: and I have seen it on LP a couple of times
<bryce> I'll see if I can find one matching the opcode
<bryce> pitti, what video card are you using?
<iwj> BadAlloc is an X protocol error which is nothing to do with memory management.
<iwj> It's for stuff like `you can't allocate a colourmap like that' or whatever.
<iwj> Semantic errors.
<iwj> pitti: ^
<pitti> bryce: host: radeon 5200 with nvidia proprietary driver; vmware guest: vmware X driver
<mjg59> pitti: So it doesn't take down the server?
<pitti> iwj: ah, ok
<mjg59> How weird
<pitti> mjg59: not on amd64, no; just on i386
<mjg59> pitti: It's certainly the X_GLXCreateContext that's the issue, if I remember the backtrace properly
<bryce> hmm, sounds like this bug:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364233
<ubotu> Debian bug 364233 in xorg-server "mesa-swx11-source: indirect rendering broken on 64-bit platforms" [Important,Open]  
<pitti> mjg59: well, to be precise: for my particular vmware and the tribe-2 desktop CDs
<pitti> bryce: hm, but our crash affects i386, too, and that one was fixed long ago
<bryce> hmm
<davmor2> pitti:  I am still having issues with the way nm-applet is working
<davmor2> but I actually am wondering if it is gnome-keyring rather than nm-applet  is there a way to tell?
<pitti> davmor2: depends on the behaviour that you see; asac?
<pitti> hi sabdfl
<sabdfl> howdy
<davmor2> asac?
<Hobbsee> morning sabdfl 
<Hobbsee> er...3am is morning, isnt it?
* bryce waves to sabdfl
<xxxxx1> join #ubuntu-bugs
<xxxxx1> oops
<davmor2> asac:  In tribe 1.  You selected your network typed in the passphrase then created a password for gnome-keyring then when you restart the machine you type in the keyring password.  Now however I get a thing that says allow nm-applet to conect to keyring then nm-applet puts up the network passphrase window again.
<pitti> davmor2: sounds like the same bug asac and seb128 have already discussed in #u-desktop
<pitti> davmor2: essentially 'g-keyring never remembers any password'
<Hobbsee> bryce: i was about to offer to test X.  on the other hand...if this is my only linux partition, on my only machine, perhpas that's not so wise
<pitti> davmor2: gicmo and seb128, actually, but nevermind
<pitti> Hobbsee: live CDs rock :)
<Hobbsee> pitti: that they do
<gicmo> davmor2: yep, I have that bug here ;-)
<davmor2> gicmo:  Thank god I thought I was going mad
<gicmo> pitti: and the latest keyring update doesnt help either ;-/
<bryce> Hobbsee: yeah I make sure to do X testing on my non-main box just in case
<Hobbsee> heh :)
<bryce> Hobbsee: although so far I've been lucky
<bryce> Hobbsee: but I know from experience that won't last ;-)
<Hobbsee> bryce: haha
<Hobbsee> bryce: i dont remember an X breakage since dapper.  so i think i've been lucky here too
<Hobbsee> maybe it was edgy
<Hobbsee> yes, i think it was.  dapper was just well known for apt segfaulting.
<LaserJock> dapper-updates was the infamous one
<Hobbsee> i stopped running dapper when -updates were being pushed thru
<Hobbsee> LaserJock: i was meaning during development
<Hobbsee> and feisty was known for the ZOMG My kernel doesnt boot breakage
<Amaranth> and non-working cdrom drives
<Hobbsee> i never heard much of that one
<mlots> What tool(s) was(/were) used to create start.exe?
<ulaas> asac, living?
<geser> Mithrandir: which debian-mirror is used when packages are synced from Debian?
<mikmorg> hello.
<pygi> geser, just archive.debian.org ?
<keescook> hunh.  network manager is spawning "ifconfig" as fast as it can...
<geser> pygi: archive.debian.org aka ftp.debian.org is missing the package I want to sync but e.g. ftp.de.debian.org has it
<pygi> geser, aha :-/
<keescook> ah, root filled up and freaked NM out.  odd
<LaserJock> geser: like completely removed?
<LaserJock> or just that version/
<geser> LaserJock: only the last version
<LaserJock> geser: is .de newer? as in, are they just in the middle of a sync?
<geser> the package was uploaded 4 days ago
<Amaranth> i love how every bug that mentions 'compiz' in the name is automatically reassigned to compiz when someone looks at it
<Amaranth> s/name/description/
<LaserJock> why not?
<LaserJock> it's the weak link ;-)
<crimsun> asac: yes, of course.  In the future, please go ahead.  I'm moving presently.
<glatzor> how can I find all packages that have got a build dependency on python-distutils-extra? The latest version includes some api breaks and I would like to provide fixes for every package.
<glatzor> I only now only of the packages that I converted myself to python-distutils-extra
<LaserJock> glatzor: apt-cache rdepends ?
<glatzor> LaserJock: this only returns binary packages, but I need build dependencies.
<LaserJock> oh, sorry
<LaserJock> apt-cache showsrc python-distutils-extra | grep Build-Depends
<seb128> glatzor: http://people.ubuntu.com/~ubuntu-archive/germinate-output/gutsy/rdepends/python-distutils-extra/python-distutils-extra
<bryce> heya glatzor!  welcome back :-)
<geser> LaserJock: he looks for rbuilddepends
<asac> crimsun: already done
<geser> glatzor: http://damianv.com.ar/downloads/rbuildepend
<LaserJock> geser: blah, I need no glasses or something, or maybe not waking up at 6:00am anymore
<LaserJock> s/no/new/
<seb128> geser: what is that?
<seb128> geser: have you seen the url I copied ? ;)
<glatzor> seb128: thanks
<seb128> you're welcome
<glatzor> you are my personal hero :)
<geser> seb128: does it also work for universe packages?
<geser> seb128: that url is a small script around grep-dctrl to find packages which build-depend on the argument(s)
<seb128> geser: no, I think it's main only
<geser> seb128: do you know which debian mirror is used for syncing packages?
<seb128> geser: ftp.debian.org I think, but we stopped autosync now
<seb128> geser: why?
<geser> I want to file a sync request for libapache-mod-jk but the last version is missing on ftp.debian.org (but ftp.de.debian.org has it)
<seb128> there is some syncs open already about which are in this case
<seb128> open them anyway and let archive team deal with it
<seb128> we will sync from an another mirror if required
<davmor2> quick query.  I think I have an issue with synaptic but I'm not sure if it is synaptic or compiz causing the issue.  When you select a package and want to "mark recommended packages"  it doesn't.  so my question is it compiz or synaptic or a mixture of the 2
<sn-> davmor2 this channel isn't really for support, please ask in #ubuntu
<davmor2> sn-: I'm trying to track which so I can bug report it
<sn-> davmor2 have you seen http://www.ubuntu.com/community/reportproblem ?
<asac> any idea why my upload of flashplugin-nonfree hasn't been tried to build on amd64?
<asac> https://launchpad.net/ubuntu/gutsy/+source/flashplugin-nonfree
<asac> ?
<asac> its Architecture: i386 amd64 now
<sn-> asac i would assume because there is no 64bit flash currently
<asac> haha
<sn-> maybe gnash? im not sure
<asac> no sorry ... i uploaded it in order to build it on amd64 :)
<asac> look at .dsc file
<asac> Architecture: i386 amd64
<ajmitch> asac: maybe P-a-s?
<ajmitch> I think there's an equivalent ubuntu blacklist
<asac> ?
<ajmitch> packages-arch-specific
<ajmitch> asac: I think an archive admin needs to change it in soyuz, you'll have to dig one up :)
<asac> ajmitch: ok ... will figure out. thanks
<pygi> seb128, poke
<seb128> pygi: hi
<pygi> seb128, more questions for you if you have some time?
<seb128> depend of the question, just ask ;)
<pygi> what's the chance of dropping graveman and such completely unmaintained apps from the repos?
<pygi> unmaintained = upstream unmaintained
<seb128> what is the interest?
<pygi> (and yes, I know you'll probably say they have the user base, and we can't drop, and such)
<seb128> if they have no security bugs we have no workload
<pygi> seb128, well, to stop explaining on all those countless bugs :-/
<seb128> and some users might be using those
<seb128> well, you can ignore bugs
<pygi> seb128, as I said above, I knew you'd say that :P
<pygi> oh wel, oki
* pygi understands
<seb128> maybe mail ubuntu-devel-discuss or ask on an user list if there is somebody using it
<seb128> and if they would complain loud if we remove it
<seb128> and make sure they have something to use in replacement covering all their usecases
<pygi> seb128, let's just leave it for gutsy, and don't make such changes
<pygi> for gutsy+1 we'll see what to do
<seb128> k
* pygi is so sad about the cd-recording situation :-/
<seb128> what situation? lot of softwares, none so good?
<seb128> nautilus-cd-burner works fine for what I've to do ;)
<pygi> seb128, it works for you, but it doesn't for many others :)
<seb128> we get very few complains about n-c-b nor working
<seb128> it just lacks features for some usecases
<pygi> seb128, do we have all those "features it's lacking" on malone?
<seb128> not sure
<seb128> upstream rejected some ideas, they want to keep it simple
<seb128> not start adding option for multi-session, etc
<pygi> meh, upstream isn't even responding :-/
<pygi> right, right
<seb128> it's a "right click on an iso and record it"
<seb128> and "dnd your datas and record"
<pygi> yes, mostly
* pygi makes more notes
<seb128> graveman doesn't get that many bugs it looks like
<pygi> that's a lot of notes that I have :-/
<pygi> seb128, true, but probably mostly due to fact that it's not used much
<pygi> no idea tho, as I said ... it's fine for now
<pygi> I'll need to see what (if anything) I can do for gnome cd-recording software for gutsy+1 or so
<seb128> are you trying to keep only on CD burning software in the archive? ;)
<pygi> seb128, no, I have my plans for the future in other areas as well. 
<pygi> seb128, but this is where currently I have most influence and I can solve this mess :)
<seb128> the easy way to solve it is to write a rocking software
<seb128> so people stop using old unmaintained one
<pygi> well, what do you think I've been doing all this time? :)
<seb128> and we can clean everything
<seb128> don't bother too much about cleaning other ones
<seb128> just get yours on the default desktop
<seb128> and have user happily using it
<seb128> and then other ones will be easy to clean
<pygi> seb128, hehe, well I'm working on gtk cd-recording app :)
<pygi> patience tho :)
<pygi> seb128, any other area you need solved/fixed? ^_^
<pygi> I think we'll be able to package redesigned-nautilus for gutsy+1 as well :)
* pygi hides because he isn't supposed to be talking about that :P
<seb128> pygi: "we" being?
<seb128> pygi: gvfs will be nice ;)
<pygi> seb128, the ubuntu folks? :)
<seb128> pygi: you can try to solve the windows network integration
<seb128> easy samba sharing and browsing
<pygi> seb128, ergh, gvfs is still amoving target :-/
<pygi> seb128, that's no fun. How to test it without windows? :)
<pygi> a moving*
<geser> pygi: have you seen Debian bug #427064?
<ubotu> Debian bug 427064 in ftp.debian.org "RM: graveman -- RoM; abandoned upstream; unmaintained; has alternatives" [Wishlist,Open]  http://bugs.debian.org/427064
* pygi looks
<pygi> geser, no, thank you
<pygi> geser, oh well, we can leave for gutsy as far as I'm concerned
<pygi> for gutsy+1 we'll push forward something else as desktop's default
<ScottLij> How does one get involved with Ubuntu development?
<geser> What's the policy for packages removed from Debian? I usually file remove requests when I find such packages
<pygi> ScottLij, http://www.ubuntu.com/contribute
<seb128> geser: we tend to remove them when Debian do
<pygi> or something :)
<geser> ScottLij: see https://wiki.ubuntu.com/MOTU and join #ubuntu-motu
<ScottLij> pygi, thanks, I was reading that but I can't find a page on how to get a "sponsor"
<pygi> ScottLij, http://www.ubuntu.com/community/participate
<persia> seb128: Is that automated in some way?
<pygi> ScottLij, go to #ubuntu-motu
<ScottLij> Thanks
<seb128> persia: no
<persia> seb128: Thanks.
<seb128> you're welcome
<pygi> persia, he gets too many "thanks" :P
<pygi> seb128, I'll work next week to help dholbach with telepathy bits a bit
<geser> pygi: if you want to get graveman removed you have with the Debian bug a good argument for it
<pygi> geser, it's not about the argument here. It's about users.
<seb128> pygi: excellent ;)
<geser> pygi: does it help our users if we ship abandoned software in gutsy?
<seb128> geser: if there is no better alternative, yes
<geser> we probably won't be able to fix any reported bugs in it
<pygi> geser, not probably, but surely
<pygi> seb128, Brasero is supposed to be that (a better alternative) but they messed up big time with newest version
<seb128> pygi: I'm not convinced many people use brasero yet
<seb128> that's why I said that having a mail on an user list would be nice ;)
<pygi> seb128, I kindof am, but I do agree it's not ready for default
<seb128> just to know what users are doing
<pygi> seb128, sure, I'll send a mail, don't worry :)
<pygi> seb128, https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/91043
<ubotu> Launchpad bug 91043 in brasero "Install Brasero by default" [Wishlist,New]  
<pygi> I do assume you saw this?
<seb128> pygi: yes, bugs are not the right place for such requests though
<seb128> pygi: better to mail ubuntu-devel ;)
<pygi> geser, graveman is unmaintained. *I* won't take care of it's bugs.
<pygi> geser, good enough? :)
<pygi> seb128, hehe, right :)
<pygi> Well, I'll mail the users list tomorrow
<seb128> the comments are not nice though
<seb128> "Right now brasero isn't really maintained "
<pygi> seb128, that's what I said :P
<pygi> read who said it :)
<seb128> yeah
<pygi> seb128, don't worry, when I have something I believe is worth of main ... I'll have strong reasons :)
<seb128> ;)
<pygi> seb128, for example, xfburn is not worth of main currently, although it is in it
<pygi> it's not even worth of universe in such state
<pygi> i.e. it can't really burn a cd
<seb128> pygi: it's a xubuntu decision ...
<pygi> seb128, yea, I talked with Jani :-/
<pygi> he wanted me to propose a replacement, but ergh ... no real lightweight solution for them :(
<Aladin> Why is the package for the netbeans application named "netbeans5.5"? I think it has to be named just "netbeans". Like firefox, etc...
<pygi> Tonio_, hey!
<pygi> you got my mail about k3b?
<Tonio_> yop pygi :)
<Tonio_> pygi: yeah, that's on my todo for tomorrow
<Tonio_> pygi: but I have other emergencies to work one unfortunatelly...
<Tonio_> pygi: I'm very very late on my kubuntu work
<pygi> Tonio_, don't worry, really
<LaserJock> Aladin: some things are named that way when there could be multiple versions in the archive
<pygi> I'll be happy if you could get time any day to answer my mail
<pygi> Tonio_, I'd really like to get that rocking :)
* pygi is bugging everyone, sorry about that folks :(
<LaserJock> Aladin: for instance sun-java5 and sun-java6
<Tonio_> pygi: will do tomorrow, no pb :
<Tonio_> :)
<pygi> Tonio_, yay, fantastic :)
<pygi> Tonio_, then we can discuss and work on that :)
<Tonio_> yup :)
<Tonio_> pygi: but I prefer to be honnest, that'll not be the priority
<pygi> Tonio_, look ... it'll be my priority :)
<Tonio_> pygi: I have work on network-manager, I have to repackage kdepim, including opensync/syncml support, and then also finish the kdesudo integration to kubuntu
<pygi> Tonio_, basically I wanted ack's to work on it :)
<Tonio_> pygi: all of that is very important stuff :)
<pygi> Tonio_, do look what I just said :p
<Tonio_> pygi: but I'm perfectly fine following you and helping you on this
<Tonio_> pygi: read it don't mind
<pygi> Tonio_, ok, but I just need the way how to do it
<pygi> Tonio_, would you agree on completely repackaging and diverging from debian?
<pygi> and you did saw in my mail where I state that patches aren't working, although they're supposed to :-/
<Tonio_> pygi: I'd say no, sorry....
<pygi> Tonio_, ah :(
<pygi> Tonio_, so I gotta fix the current package to make it work?
<Tonio_> pygi: best would be to take contact with debian and try to get your changes synced with debian
<Tonio_> pygi: no problem to change the all packaging as long as you do the required stuff to get it merge with debian :)
<pygi> Tonio_, ubuntu package diverges a lot from debian already
<pygi> Tonio_, haha, ok, I'll mail k3b maintainer :)
<pygi> that's what I did when I wanted cdrskin support built directly into k3b ^_^
<pygi> Tonio_, afaik I'm not sure our patches get applied at all :-/
<pygi> perhaps the patching procedure is bad since that's what we added
<pygi> (i.e. no idea who specifically but ...)
<Tonio_> pygi: no problem concerning the patches as long as you propose them
<Tonio_> pygi: they can have their own reasons to reject
<Tonio_> pygi: but it is important to keep the same packaging style and structure
<Tonio_> pygi: means, don't change the packages naming/splitting, don't change the patch system used etc....
<Tonio_> pygi: there is no problem having our own patches, but we should at least propose them to the debian maintainer, for less work on package maintaining in the future :)
<pygi> Tonio_, ergh, you don't get it
<pygi> Tonio_, a)we already diverge in a lot of stuff regarding packaging methods (i.e. patching methods)
<pygi> b)we ship tons of packages, none seem to work (i.e. I assume they don't applied at all due to buggy patching methods)
<pygi> that's the state how I got k3b. Did not touch it at all before, so didn't knew that
<pygi> but it's messy :P
<Tonio_> pygi: hum interesting.....
<Tonio_> pygi: lemme have a look at the package...
<pygi> Tonio_, ergh, the b) was supposed to state that we ship a lot of patches, not packages :p
<Tonio_> pygi: is the packaging cdbs based ?
<pygi> Tonio_, debhelper
<Tonio_> pygi: I switched the packaging to cdbs a long time ago
<pygi> Tonio_, ergh?
* pygi is not sure about that
<Tonio_> pygi: argh.... that's due to the sync with debian for the 1.0 version....
<Tonio_> pygi: I didn't do that one....
<pygi> Tonio_, meh!
<pygi> Tonio_, this k3b package is *broken*
<pygi> and afaik, we should just blacklist k3b
<pygi> same thing I did for brasero
<Tonio_> pygi: best thing would be to first switch the packagint to cdbs then, and propose that to debian
<Tonio_> pygi: the way the patches are applied is just ugly....
<pygi> Tonio_, yay, you agree with me!!!
<Tonio_> pygi: I'm not even sure all the patches are level 1 by the way
<pygi> Tonio_, well, they don't get applied :P
<Tonio_> pygi: there is absolutly no reason to package with debhelper only nowaday
<Tonio_> cdbs is much better
<pygi> Tonio_, see? We agree then ^_^
<pygi> Tonio_, what was the package where you introduced cdbs?
<Tonio_> pygi: apt-get source k3b
<Tonio_> then go in the sources root, and do a fakeroot debian/rules configure
<pygi> Tonio_, I'll see what I can do to it next week, fix, upgrade, and such ... temporary blacklist, and talk with debian
<Tonio_> pygi: you'll see why the patches don't apply, that's not a problem with the rules file, it's a problem with the patches, they need to be rewritten
<Tonio_> pygi: okay I don't want to waste my time on this
<pygi> Tonio_, hehe, ok
<Tonio_> pygi: I have an hour, do you want me to switch to cdbs, fix the patches and let you finish that ?
<pygi> don't worry :)
<pygi> Tonio_, if you want, sure
<Tonio_> let's go :)
<pygi> great :)
<Tonio_> pygi: just one thing I don't understand.... how can the package build if the patches fail to apply ?
<Tonio_> pygi: the package should ftbfs on the buildd
<pygi> Tonio_, I'm not *officially* sure that they fail to apply, but the effect is missing
<pygi> for example the patch which removes cdrecord suid stuff ... it's still shown on gutsy
<pygi> and it shouldn't be due to that patch
<pygi> Tonio_, looking at the patch reveals that it should work since those lines are commented out
<Tonio_> pygi: I can confirm they fail to apply
<pygi> Tonio_, well, as I said ... messy debian/rules?
<Tonio_> http://paste.tonio.homelinux.org/120
* pygi looks
<Tonio_> pygi: strange btw, the build should fail.... let's go with a modern packaging.... I'm sick of seeing modern apps using such an obsolete packaging structure :)
<pygi> Tonio_, o and yes ... that normalize stuff effect is missing as well
<pygi> Tonio_, great :)
<Tonio_> pygi: that's a patch right ?
<pygi> Tonio_, yes
<Tonio_> i they don't apply, no reason for that to work :)
<pygi> #
<pygi> APPLYING PATCH: kubuntu_101_rename_normalize.diff
<pygi> #
<pygi> patching file libk3b/core/k3bdefaultexternalprograms.cpp
<pygi> #
<pygi> Hunk #1 succeeded at 702 (offset -13 lines).
<pygi> #
<pygi> Hunk #2 succeeded at 717 (offset -13 lines).
<pygi> #
<pygi> Hunk #3 succeeded at 731 (offset -13 lines).
<pygi> that patch does apply, but it's wrong IMHO
<pygi> I think I have a sane solution
<pygi> Tonio_, switch to cdbs, clean it up, rewrite some patches if you can, and lemme handle the rest then
<pygi> I'll additionally clean it up, rewrite/fix some patches, add new ones I think should be there, talk with debian and such
<Tonio_> pygi: will do
<Tonio_> pygi: I think we are in freeze atm right ? so I'll have to wait a bit for uploading :)
<pygi> Tonio_, don't worry about upload
<pygi> you'll just mail me all the files I need :)
<pygi> i.e. debdiff will do just fine :)
<Tonio_> pygi: I'll probably create a packaging branch on code.launchpad.net/~kubutu-members then
<Tonio_> pygi: just watch there what happens
<pygi> k
* pygi still doesn't like that bzr-builddeb :P
#ubuntu-devel 2007-06-29
<alex-weej> is there some guide to the categories i should use when packaging software?
<gnomefreak> alex-weej: see #ubuntu-motu
<alex-weej> ok
<funman> hello
<funman> i'm looking for the apt repository which has the debug symbols
<AndyP> funman: it's listed on https://wiki.ubuntu.com/DebuggingProgramCrash
<funman> thanks
<RAOF> Amaranth: Ping
<Amaranth> RAOF: pong
<Amaranth> xserver-xgl is basically a black hole wrt to bugs
<RAOF> I was thinking of adding a wishlist bug to get xgl to ship ?dm session files.
<RAOF> (I would, of course, do the work)
<Amaranth> sure, why not
<Amaranth> but gdm is used in xubuntu
<RAOF> Cool.  Just wanted to run that by you first.
<RAOF> Aren't the sessions common to kdm, gdm, etc?
<RAOF> So why would that matter?
<mikmorg> does anyone know of a linux dist. contained entirely in the initrd, for recovery?
<Hobbsee> morning all
<TheMuso> Hobbsee: Considered using good ${Time_Of_Day}
<Hobbsee> heh
<Hobbsee> but it's always morning on irc!
<ajmitch> universal greeting time
<TheMuso> ajmitch: heh
<elpargo> hi could someone tell me the location of the installed packages metadata?
<elpargo> basically I need to know where is the data dpkg-query is reading
<TheMuso> /var/lib/dpkg is where you will find a lot of stuff I think.
<elpargo> I need to run that from a liveCD into an installed system
<elpargo> ok thanks TheMuso
* Hobbsee waves
<lifeless> coming to slug?
<Hobbsee> lifeless: see -motu :)
<Hobbsee> geser: that script you mentioned earlier - any idea what licence it's under?
<Hobbsee> the rbuilddepends one
<dholbach> good morning
* Hobbsee hugs dholbach 
* dholbach hugs Hobbsee back
<Hobbsee> :)
<dholbach> Hobbsee: can you please kubuntumembers as a bug contact of adept?
<dholbach> erm ... remove
<Hobbsee> dholbach: er..who added that?
<dholbach> no idea
<dholbach> I just got a bunch of mails about adept bugs
<Hobbsee> erk
<dholbach> and I'm no direct member of the team, so I couldn't remove the bug contact
<Hobbsee> fair enough
<Hobbsee> have removed it
<dholbach> gracias
<Hobbsee> i wonder about putting a contact address of nobody@ubuntu.com there though
<Hobbsee> but then, it wouldnt help, as i cant actually verify that address
<pitti> Good morning
<dholbach> hey pitti
* dholbach hugs pitti
* pitti hugs dholbach, guten Morgen!
<Burgundavia> pitti: rocking release. Sorry about not getting the tribe2 page done, life got in teh way
<pitti> Burgundavia: oh, there was quite a good page, we pimped it a little
<pitti> Burgundavia: thanks for the good start
* Hobbsee hugs pitti!
<Hobbsee> morgen pitti!
<pitti> hey Hobbsee 
<Hobbsee> pitti: 
<Hobbsee> [Fri Jun 29 2007]  [12:55:38]  <Hobbsee> does pitti know that one of the links is broken, on http://www.ubuntu.com/testing ?
<Hobbsee> [Fri Jun 29 2007]  [12:55:49]  <Hobbsee> in fact, both of them?
<pitti> Hobbsee: no, I don't; they worked just fine yesterday
<Hobbsee> pitti: they're pointing to https://www-admin.ubuntu.com/testing/tribe1
<Hobbsee> not https://ubuntu.com/testing/tribe1
<pitti> erk, that wasn't so yesterday; I'll talk to Matthew about that
<pitti> let me fix it
<pitti> fixed; it should propagate to www.u.c. in some minutes
<Mithrandir> geser: ftp.debian.org, iirc
<Hobbsee> pitti: :)
<Hobbsee> morning Mithrandir 
<Mithrandir> morning Hobbsee
* Hobbsee ponders installing ubuntu on a spare partition
* Hobbsee wants the shiny
<dholbach> oh Riddell is an archive admin now too - NICE :-)
<dholbach> somebody I can pester now too ;-)
<Hobbsee> heh
<Hobbsee> dholbach: he might just ignore you, though :P
<dholbach> right
<TheMuso> haha
<Hobbsee> dholbach: MOTU meeting in 4 hours.  do you plan to attend?
<ajmitch> dholbach: you'll probably end up as an archive admin soon
<ajmitch> then we can pester you
<ajmitch> I think I still have your phone number somewhere :)
<Hobbsee> seems that everyone cool is an archive admin, nowadays.
<Hobbsee> we're just mere mortal, green aliens
<ajmitch> yess miss release team person
<Hobbsee> ajmitch: i have no access to the DC.  so you can still do as much as i can :P
<ajmitch> no I can't
<ajmitch> I don't hold people's lives in my hands like you
<Hobbsee> heh
<Hobbsee> ajmitch: i can ask them to accept crack, but i cant force them to.  so i technically dont either
<ajmitch> until you start poking
<Hobbsee> well...
<Hobbsee> there is that
<TheMuso> heh
<dholbach> Hobbsee: yes
<dholbach> ajmitch: I don't think so :)
<dholbach> pitti: do you want me to file a bug for removing human-cursors-theme from the archive?
<pitti> dholbach: no need to, I can do it on the spot
<asac> pitti: if you have a minute, can you add amd64 to valid architectures for flashplugin-nonfree please?
<dholbach> pitti: thanks a lot
<pitti> dholbach: 
<pitti> -- gutsy/main amd64 deps on human-cursors-theme:
<pitti> edubuntu-artwork
<pitti> ltsp-client
<dholbach> pitti: thanks
<pitti> dholbach: (same for all other arches)
<dholbach> ogra: can you change from human-cursors-theme to dmz-cursor-theme? it's what we use in ubuntu now
<pitti> dholbach: I won't remove it for now
<dholbach> pitti: alright, I'll check with ogra
<pitti> asac: what do you mean? uploading a new version with a different Architecture: field?
<asac> i did that
<asac> its apparently in p-a-s exception list
<pitti> aah
<ajmitch> (at a random guess) :)
<ajmitch> hi pitti 
<ajmitch> still no samba 3.0.25b on merges.u.c, I guess I should stop being lazy & do it manually
<pitti> flashplugin: i386
<pitti> flashplugin-nonfree: i386
<pitti> indeed
<ajmitch> yay I wasn't on crack
<pitti> cjwatson, Mithrandir: can I just edit that file, or does it require some special magic?
<asac> pitti: great ... can you also make sure that the build is retried when done?
<pitti> cjwatson, Mithrandir: "that file" -> P-a-s
<Mithrandir> pitti: you need to get it updated in Debian.
<Mithrandir> pitti: which means, ask elmo, infinity or lamont to do it.
<pitti> Mithrandir: ah, ok; so we don't have our own?
<pitti> asac: ^ can you please mail them?
<asac> so we have to obey p-a-s list of debian ... doesn't sound really smart.
<asac> hmm
<asac> ok
<pitti> Mithrandir: thanks
<Mithrandir> asac: *shrug*; it works.  We don't "have to", it just works fine.
<asac> if it really worked, flashplugin-nonfree would have been build by now :-P ... but ok.
<asac> Mithrandir: ok i pinged them in irc for now to see if they want a mail or ticket or what. Thanks for the hint.
<pitti> asac: btw, lamont is on holiday for the next week (or two)
<asac> pitti: thanks for the info
<gpocentek> pitti, seb128, could you give back criawips 0.0.12-0ubuntu2 on all arches please?
<pitti> gpocentek: seb128 can't; I'll do it
<gpocentek> ok
<gpocentek> thanks
<pitti> gpocentek: done
<seb128> gpocentek: you need a buildd admin for that, ie tfheen or pitti
<seb128> hey pitti ;)
<pitti> morning Seb!
<gpocentek> seb128: ok, Ithought you were a buildd admin too
<seb128> nop, archive admin is enough ;)
<gpocentek> hehe
<seb128> I would not say no to buildd kicking power though, that can be handy :p
<gpocentek> :)
<gpocentek> seb128: gnumeric FTBFS and I think that it's related to glib changes, could you confirm that (or not) ? http://launchpadlibrarian.net/8228754/buildlog_ubuntu-gutsy-i386.gnumeric_1.7.10-1ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> gpocentek: "../../../src/widgets/gnumeric-expr-entry.c:180: error: 'gtk_widget_unref' undeclared (first use in this function)"
<gpocentek> seb128: gtk/gtk.h is included
<seb128> gpocentek: looks like src/widgets/gnumeric-expr-entry.c missing an include
<gpocentek> seb128: the same package doesn't fail to build on feisty
<seb128> with the new goffice?
<gpocentek> yes
<seb128> k, still that's the only build failure looking like that
<seb128> so I doubt it's GTK+ being broken
<seb128> I'll have a look
<gpocentek> ok, I'll continue my investigations
<gpocentek> thanks
<seb128> you're welcome
<tulga> my Asus A6Va's earphone not working. speaker working well. howto solve it?
<pitti> gpocentek: btw, libgoffice-0-4 is in the archive now, so the transition can happen
<gpocentek> pitti: yep, criawips is one of the package B-D on it
<seb128> gpocentek: I'll fix the gnumeric bug
<gpocentek> seb128: thanks very much
<ogra> dholbach, thanks for the ping, will update the deps
<LongPointyStick> compiz has calmed down a lot
<LongPointyStick> wha'ts the name of the manager?
<geser> LongPointyStick: sorry, I don't know the licence for the rbuildepend script. I'm quite sure I got it from some other location but I don't know anymore which one.
<LongPointyStick> geser: might be worht adding to devscripts, or the bzr stuff
<LongPointyStick> there's a developer package in bzr about it
<dholbach> ogra: tell me once they're built with the new deps
<ogra> hrm, why did pulse FTBFS on ppc ...
<ogra> dholbach, will do
<dholbach> thanks ogra
<LongPointyStick> dude, what?  the wired network drops if you kill the wifi with the kill switch
<Hobbsee> cjwatson: ping
<pygi> Tonio_, poke :)
<pygi> good morning folks
<Tonio_> pygi: yup ?
<Tonio_> pygi: k3b is beeing built here
<pygi> Tonio_, did you commit that thingy anywhere?
<Tonio_> pygi: I had to change wuite a ffew things to the packaging
<Tonio_> pygi: nope I'll upload when the packaging is nice
<pygi> Tonio_, ah, ok. Tell me when you do, then I'll do extra modifications.
<Tonio_> pygi: sure
<Nafallo> sabdfl, mdz: hi guys.
<pygi> Tonio_, thanks :)
<cjwatson> Hobbsee: pong
<sabdfl> hi Nafallo
<Nafallo> sabdfl, mdz: I just got a mail from LP saying that I will expire from ubuntu-dev in 6 days. Seems ~motu wasn't enough :-P.
<mdz> Nafallo: the warning is spurious
<sabdfl> Hobbsee: we have published all those internal process documents, now it's up to you to show it's worth it ;-)
<Hobbsee> cjwatson: about bug 122645 - are you aware that the manual partitioner has *not* hung?  it's actually that the window is hidden behind something else, perhaps due to compiz.  if you attempt to kill it, it bounces up.
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [High,Confirmed]  https://launchpad.net/bugs/122645
<sabdfl> Nafallo: let it expire
<Nafallo> hehe. oki.
<Tonio_> pitti: hey ;)
<Nafallo> sabdfl, mdz: thanks :-)
<Amaranth> Hobbsee: yay focus problems
<Tonio_> pitti: I've been pretty busy this week, but I'll send the message on the ML concerning network-manager in a few minutes
<Hobbsee> cjwatson: about bug 122645 - are you aware that the manual partitioner has *not* hung?  it's actually that the window is hidden behind something else, perhaps due to compiz.  if you attempt to kill it, it bounces up.
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [High,Confirmed]  https://launchpad.net/bugs/122645
<Hobbsee> erk, sorry
<Tonio_> little technical question, is there a good syncml client/integration on the gnome desktop ?
<Hobbsee> sabdfl: thankyou :)
<Tonio_> this is something we really, really get done on the default install, as everyone has a new modern mobile device nowadays....
<Mithrandir> Tonio_: not really.  Opensync is slowly, slowly, slowly getting there
* Hobbsee *loves* working via a cable connection, then pulling out the cable
<Tonio_> Mithrandir: interesting.... I saw that kontact had everything to get it to work in its code, but the packaging ignores that part, I'll investigate...
<Tonio_> Mithrandir: is the limitation in opensync, or is the problem is integration with the mail clients ?
<Mithrandir> opensync tries to sync all to all which is a hard problem
<Tonio_> Mithrandir: indeed, if that cannot be configured, that's an issue :)
<Tonio_> Mithrandir: I'll still investigate, thanks for the infos
<Mithrandir> uh, it's more the fact that trying to sync Evo, a palm and a mobile phone when you've done changes on all of them is hard, since they have items in the info that none of the others have.
<Tonio_> ho, you were talking about devices, I thought you were talking about items :) no way to configure what's to be synced
<cjwatson> Hobbsee: which window is hidden?
<Mithrandir> Tonio_: sure there is
<cjwatson> Hobbsee: you mean some kind of dialog? I wouldn't have thought there'd be one at that point
<cjwatson> (but it's possible, remind me)
<Hobbsee> cjwatson: the partitioning window with the partitions listed
<Hobbsee> for a manual partition
<Hobbsee> giving you the option to edit, format, etc
<Tonio_> Mithrandir: well local config is not what is interesting to me, but using a sync service, like memotoo, mobical, or your own server, with funambol
<cjwatson> Hobbsee: that should be just part of the main window?
<cjwatson> Hobbsee: I'm not sure I understand what's going on here - would it be possible for you to take screenshots at the apparent hang, and after raising the window?
<Tonio_> basic sync between a mail client and a syncml server, would already be cool, as mobile devices are already ready for this...
<Tonio_> Mithrandir: sadly, only outlook seems to do the job perfectly atm....
<Hobbsee> cjwatson: sure.  it's where you hit "prepare disk space", and hit manual partition.  it brings up a window saying that it's scanning the disks, then removes that one, and "hangs".  grabbing a screenshot, if i can work gnome to my will.
<Mithrandir> Tonio_: Outlook doesn't handle multiple devices well at all.
<Tonio_> Mithrandir: nope, because the goal on that point is not local sync, everything is based on a server
<Tonio_> Mithrandir: so you just have one sync enabled on each device....
<cjwatson> Hobbsee: certainly I'd be very happy to hear that it isn't ubiquity's fault ;-)
<Hobbsee> hrm. maybe it is a crash.
<Mithrandir> Tonio_: that's hard to do when your device doesn't have a network connection.
<Hobbsee> seeing as that time it actually killed the process.
<cjwatson> Hobbsee: would also explain why it doesn't happen in vmware (no compiz) and perhaps why it doesn't happen under sudo
<Tonio_> Mithrandir: true, but probably all modern devices have so :)
<Tonio_> Mithrandir: that's the future I mean :)
<Tonio_> local sync is the old way to think :)
<Hobbsee> cjwatson: i killed ubuntu    6023  0.0  0.3  13892  5044 ?        S    09:29   0:00 gksudo --desktop file:///home/ubuntu/Desktop/ubiquity-gtkui.desktop -- /usr/lib/ubiquity/bin/ubiquity gtk-ui
<Mithrandir> Tonio_: local sync is also interesting if you pay per byte you transfer over the network, which you probably do from your phone.
<cjwatson> Hobbsee: I would suggest not killing the process, and trying to raise it some other way
<Hobbsee> cjwatson: got suggestions as to how to raise it another way?
* Amaranth hides
<Hobbsee> i'm not terribly familiar with ubiquity debugging
<Tonio_> Mithrandir: then I'd say funambol is the trick, with a wireless capable device, which will be a standard soon
<Tonio_> Mithrandir: but of course, not everyone has a wireless access point at home
<cjwatson> Hobbsee: it shouldn't be about ubiquity debugging, it should be about manipulating the window manager, from the sound of things
<Tonio_> Mithrandir: have you tried funambol ? it is terribly easy to configure, no gprs required then :)
<Hobbsee> cjwatson: ooh!  metacity!
<Hobbsee> right.
<Mithrandir> Tonio_: I've looked at it and decided I don't like it, since it's a big java beast, iirc.
<cjwatson> wonder if my desktop can be persuaded to do compiz
<Tonio_> Mithrandir: yeah, that's java, but that works, does the job and is so easy to use..... :)
<Hobbsee> cjwatson: when going back to metacity, the hidden window immediately pops up
<cjwatson> ah
<Tonio_> Mithrandir: btw I don't pay per bit, but per second
<Mithrandir> Tonio_: for GPRS or 3G too?
<Tonio_> Mithrandir: no, I just use wap, works nicelly for me, and I don't need more :)
<Tonio_> Mithrandir: all I need is an ip address, I'm not interested in video calls, especially after a all night packaging with the eyes in front of a computer :)
<mjr> wap, that three-letter monster from hell
<mjr> I do wonder if you don't just mean gsm-data instead
<Tonio_> Mithrandir: here is france, gprs is to pay per size too I guess
<Hobbsee> cjwatson: erm.  this is weird.  with metacity, the entire installer just freezes up after it scans disks, after the manual partitioner.  
<Hobbsee> i have no idea what the heck is going on, then.
<cjwatson> Hobbsee: does alt-tab help, or minimising windows?
<Hobbsee> cjwatson: nope
<Hobbsee> cjwatson: not sure a) if you want to debug this or b) how
<Hobbsee> where this == compiz, ubiquity, and how they all die.
<pitti> Hobbsee: sounds like bug 122645?
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [High,Confirmed]  https://launchpad.net/bugs/122645
<pitti> Hobbsee: does running 'sudo ubiquity' in a terminal help?
<pitti> Hobbsee: or do you already see the setup screen for partitions?
<cjwatson> pitti: we already know it's that bug
<pitti> ah, 'k
<cjwatson> pitti: Hobbsee reckons it may be window manager interaction rather than a ubiquity bug as such - in that ubiquity is blocking on input from a hidden window
<_StefanS_> anyone know the state of sata and port multiplier in the current gutsy kernel ? (2.6.22)
<Hobbsee> cjwatson: yet, running it via sudo ubiquity on the command line brings up the window straight away
<Amaranth> cjwatson: but didn't Hobbsee say it broke with metacity too?
<_StefanS_> I have a 5disk array that doesnt work :(
<Hobbsee> Amaranth: it freezes completely there.  which is just weird.
<cjwatson> Hobbsee: ubiquity normally uses gksudo for itself
<pitti> Hobbsee: the funny thing is that it freezes with gksudo, but works with sudo
<cjwatson> which suggests that it's one of the things that's forwarded by gksudo but not by sudo
<cjwatson> a bit like the way kdesu forwards DCOP
<Hobbsee> pitti: exactly
<Hobbsee> ooh.  cool water :)
<cjwatson> whoa, after upgrading gutsy it spams the console relentlessly with "device-mapper: table: 254:0: linear: dm-linear: Device lookup failed"
<cjwatson> ah, bug 115616
<ubotu> Launchpad bug 115616 in evms "Device-mapper errors: dm-linear, lookup failed" [High,In progress]  https://launchpad.net/bugs/115616
<pitti> carlos: got a minute?
<carlos> pitti: sure
<pitti> carlos: would it be possible to strip out some additional files like /usr/share/gnome/help/<lang>/*.xml in pkgstriptranslations and ship that verbatim in the exported rosetta tarballs?
<pitti> carlos: those are currently not handled by PO files at runtime, but it would still be nice to split those out into langpacks, to save space on CDs
<carlos> pitti: do you mean whether Launchpad would complain?
<carlos> pitti: Launchpad will not complain, it will be ignored
<pitti> carlos: well, it probably ignores stuff it doesn't know about, but doesn't feed it back to me
<carlos> right, we don't feed it to you...
<carlos> pitti: I guess what you need is a way to import .xml files and export them again
<pitti> carlos: it's not just XML files, there are PNGs etc.
<carlos> and in the mean time, allow people to translate it
<carlos> pitti: right now, we are not able to do it, but I'm going to do a modification that would allow you to get the original tarball buildd provided to Launchpad
<pitti> seb128: ah, is /var/lib/gconf/defaults/%gconf-tree-<lang>.xml created at package installation time?
<pitti> carlos: it would be sufficient to have a directory 'extra-files/<package>/...' in the tarball which is just copied verbatim from the buildd tarballs
<pitti> carlos: we probably don't need special translation magic in Rosetta, since these files are handled with PO files at build time
<seb128> pitti: yes
<pitti> carlos: (from help/po/ or so)
<seb128> pitti: why?
<LongPointyStick> pitti: presumably i can do no more if it's a gksudo bug?
<pitti> seb128: it's one of the biggest directories of the live CD, and I wonder whether we can downsize it a bit
<seb128> pitti: it's written by gconftool call on the .schemas
<carlos> pitti: in fact, if we integrate intltool in Launchpad, we could provide such updates for documentation too
<pitti> LongPointyStick: I don't know yet who's at fault here
<carlos> so we regenerate the .xml files from those .po files
<pitti> carlos: certainly not (yet) for the translated screenshots? :)
<pitti> carlos: yeah, for the xml files this would be nice
<pitti> carlos: but certainly requires some more thought
<carlos> pitti: adding screenshot support is also something that shouldn't be too difficult
<carlos> pitti: indeed
<carlos> next month, we have a sprint about Launchpad Translations in Alicante
<carlos> were we will talk about the different workflows 
<carlos> I will add this topic to that discussion
<pitti> carlos: copying files verbatim might be useful for other cases
<pitti> carlos: shall I open a wishlist bug about this or so?
<carlos> pitti: yeah, please
<StevenK> cjwatson: Any opinion one way or the other about bug 78165 ?
<ubotu> Launchpad bug 78165 in devscripts "debuild fails to use seahorse-agent or gpg-agent" [Unknown,Confirmed]  https://launchpad.net/bugs/78165
<pitti> carlos: ok, will do; thanks
<carlos> pitti: I'm not discarding such idea, it's just I would prefer to do a proper implementation for what you need :-)
<pitti> StevenK: I guess it's due to filtering environment variables?
<pitti> StevenK: e. g. I have: alias debuild='debuild --preserve-envvar PATH --preserve-envvar DISPLAY --preserve-envvar GNOME_KEYRING_SOCKET --preserve-envvar XAUTHORITY -i -I.bzr -I.svn'
<pitti> StevenK: PATH for ccache, and the rest for gnome-gpg
<pitti> carlos: right, agreed :)
<persia> StevenK: As a shorter  version, it works for me with "DEBUILD_PRESERVE_ENVVARS=DISPLAY" in ~/.devscripts
<LongPointyStick> pitti: i'd definetly look at the gksudo vs sudo thing. it dies with gksudo, no matter what window manager, and works with sudo.  Reproducibly
<pitti> seb128: where does gconftool take the translations from? I don't have langpacks for all those languages installed
<seb128> pitti: the .schemas
<seb128> pitti: editor /usr/share/gconf/schemas/nautilus-cd-burner.schemas for example
<pitti> seb128: ah, I see
<pitti> seb128: would be nice to drop all those static translations and have gconf call gettext at runtime...
<pitti> seb128: this would give us a lot of space back on the live CD
<StevenK> pitti: Yeah, the point is to not contaminate the build environment. Apparently.
<seb128> pitti: right
<StevenK> pitti: I'm not sure how hard it is, but I was thinking of grabbing DISPLAY, GNOME_KEYRING_SOCKET and XAUTHORITY, stuffing them somewhere, and then setting them just before we invoke the signer.
<pitti> StevenK: debuild could call dpkg-buildpackage without those and -us -uc, and then call debsign
<Hobbsee> ooh, nice KDE...
<pitti> seb128: would we need to touch many packages for dropping /usr/share/gconf/schemas/ translations, or is that handled centrally?
<cjwatson> StevenK: no opinion; I use pinentry-curses so it doesn't affect me ...
<pitti> carlos: bug 123020, FYI
<ubotu> Launchpad bug 123020 in pkgbinarymangler "support shipping verbatim files in the exported tarballs" [Wishlist,New]  https://launchpad.net/bugs/123020
<seb128> pitti: every single package shipping a schemas, which means hundred of packages
<carlos> pitti: thanks
<cjwatson> I'm a little concerned that preserving DISPLAY by default would hide breakage in the odd package that tries to get at an X display during the build
<pitti> seb128: I mean, can we change this in a cdbs rule and just rebuild packages over time, or do we actually need to touch rules?
<StevenK> cjwatson: My plan at this point is to take DISPLAY, GNOME_KEYRING_SOCKET and XAUTHORITY, and put them somewhere, clean out the environment, run dpkg-buildpackage with -uc -us, add the three back and invoke debsign.
<seb128> pitti: we can probably hack that to cdbs, the schemas are generated from a .schemas.in at build time
<pitti> seb128: so similar to .desktop and .server files: we drop the translations and instead stick in the gettext domain
<seb128> right
<cjwatson> StevenK: sounds reasonable
<pitti> seb128: the standard .mo files seem to have the translations at least
<pitti> seb128: ok, I'll file a wishlist bug about this
<seb128> pitti: yes, there are to the .mo
<pitti> seb128: hm, I guess we cannot do entirely without the %gconf-tree-<lang>.xml files?
<pitti> if we could, that would be rad
<seb128> pitti: not sure, I need to do some testing, but it's likely than %gconf-tree.xml is enough if you don't want the translations
<pitti> seb128: right, it's a cache to look up i18n'ed descriptions for a key without knowing the package or translation domain
<pitti> seb128: so it's very fast
<seb128> right
<pitti> seb128: but for langpack setup, we instead need mapping key name -> translation domain
<pitti> that would be much smaller, since we don't need it per-language
<seb128> right
<Hobbsee> Keybuk: are you around?
<Keybuk> Hobbsee: yup, what's up?
<Hobbsee> Keybuk: there's an impending discussion about MoM and DaD in -meeting.  perhaps, being the brains behind MoM, you'd like to attend?
<Hobbsee> Keybuk: at least that's what they *said* they were abotu to discuss
<pitti> seb128: I noted down my ideas in bug 123025; does that make sense?
<ubotu> Launchpad bug 123025 in gconf2 "stop shipping static gconf translations, use gettext at runtime" [Wishlist,New]  https://launchpad.net/bugs/123025
<Hobbsee> Keybuk: right.  discussion is on now. (#ubuntu-meeting) if you were interested
<seb128> pitti: yes, the action plan makes sense, I've confirmed the bug
<pitti> seb128: thanks, *hug*
* seb128 hugs pitti
<pitti> seb128: something for our CFT :)
<pitti> seb128: but maybe we can convince upstream about this
<pitti> it's not specific to ubuntu, after all
<seb128> right
<seb128> pitti: around?
<pitti> seb128: yes
<seb128> pitti: do you have an idea why gdb doesn't display abort() and raise() in stackstaces in gutsy?
<seb128> we get quite some crashers to g_logv
<seb128> which are in fact assertions
<pitti> seb128: erk, no
<seb128> ie, https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/66860
<ubotu> Launchpad bug 66860 in evolution "evolution-alarm-notify crashes on startup" [High,Confirmed]  
<pitti> seb128: maybe it's related to the general gdb problem?
<seb128> pitti: can you "gdb /usr/lib/evolution/2.12/evolution-alarm-notify" and "run"?
<seb128> on feisty it was doing
<seb128> #5 0xb72c0770 in raise () from /lib/tls/i686/cmov/libc.so.6
<seb128> #6 0xb72c1ef3 in abort () from /lib/tls/i686/cmov/libc.so.6
<seb128> #7 0xb7492122 in g_logv () from /usr/lib/libglib-2.0.so.0
<pitti> seb128: this bug does have abort() though
<seb128> now the backtraces starts with g_logv
<seb128> hum?
<pitti> Program received signal SIGTRAP, Trace/breakpoint trap.
<pitti> [Switching to Thread 47709005862368 (LWP 14359)] 
<pitti> 0x00002b6419a5c4e3 in g_logv () from /usr/lib/libglib-2.0.so.0
<pitti> (gdb) bt
<pitti> #0  0x00002b6419a5c4e3 in g_logv () from /usr/lib/libglib-2.0.so.0
<pitti> #1  0x00002b6419a5c693 in g_log () from /usr/lib/libglib-2.0.so.0
<pitti> #2  0x000000000041744d in main ()
<seb128> hum, k
<pitti> seb128: SIGTRAP != SIGABRT
<seb128> yeah
<pitti> there doesn't seem to be an assertio yet?
<seb128> but look at the bug I pointed
<pitti> seb128: heh, 'cont' actually works
<pitti> let me look, this thing crashes so often for me, I should have a .crash
<pitti> seb128: right, the one in /var/crash is SIGTRAP as well
<seb128> I'm wondering why
<seb128> it should be an abort like it used to be on feisty
<seb128> https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/122858
<ubotu> Launchpad bug 122858 in glib2.0 "[gutsy]  glib2.0 applications crash with signal 5 in g_logv()" [Medium,New]  
<seb128> if you look at http://launchpadlibrarian.net/8226372/Stacktrace.txt
<seb128> the error is actually
<seb128> #2  0xb7977b94 in gdk_x_error (display=0x8081cf0, error=0xbfc2ad88) at /build/buildd/gtk+2.0-2.11.4/gdk/x11/gdkmain-x11.c:641
<seb128> k, I'll investigate
<seb128> thanks anyway
<seb128> that's slightly annoying because it makes bug title being "crash with signal 5 in g_logv()"
<pitti> seb128: hm, I don't know off-hand when SIGTRAP is used, let me look
<seb128> when that's acutally a gdk_x_error
<pitti> right
<pitti> at least it's in StacktraceTop, so dup detection should still work?
<pitti> seb128: <shot into the dark>might this be bug-buddy trying to attach to the failing process?
<pitti> seb128: the only usage of sigtrap that I know are debugger breakpoints
<seb128> pitti: well, https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/122637 has 13 dups and I added a bugpattern now but no dup has been auto detected
<ubotu> Launchpad bug 122637 in notification-daemon "notification-daemon crashed with signal 5 in g_logv()" [Medium,Incomplete]  
<pitti> seb128: hmm, removing bug-buddy doesn't change it
<seb128> pitti: it looks like there is no retrace nor dup detection tag when there is a SIGTRAP
<pitti> evolution-alarm-notify-ERROR **: Could not create the alarm notify service factory
<pitti> aborting...
<pitti> Trace/breakpoint trap (core dumped)
<seb128> pitti: bug-buddy didn't change since feisty anyway
<pitti> seb128: uh, no retrace tag? strange
<pitti> I don't look at the signal number for setting that
<seb128> pitti: do you use them for SIGSEGV only?
<seb128> hum
<seb128> "** Tags: apport-crash"
<seb128> that's the only tag on those bugs
<seb128> from the first mail
<pitti> seb128: hm, and it wasn't just removed from the retracer?
<seb128> no, the Tags line is from the "new bug" mail I got
<seb128> the submission one
<pitti> https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/122988/+activity
<ubotu> Launchpad bug 122988 in notification-daemon "notification-daemon crashed with signal 5 in g_logv() (dup-of: 122637)" [Undecided,New]  
<seb128> and it's the same for all the dups
<ubotu> Launchpad bug 122637 in notification-daemon "notification-daemon crashed with signal 5 in g_logv()" [Medium,Incomplete]  
<pitti> seb128: ^ that seems to have automatic dup detection?
<pitti> https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/122985/+activity this as well
<ubotu> Launchpad bug 122985 in notification-daemon "notification-daemon crashed with signal 5 in g_logv() (dup-of: 122637)" [Undecided,New]  
* ogra wonders if there is something like an "lsprinters" command that can drop out a list of configured printers 
<pitti> ogra: lpstat -p
<seb128> pitti: him, k
<seb128> hum, k
<ogra> pitti, wow, thanks
<seb128> pitti: so malone mails are misleading
<pitti> seb128: maybe because they tend to fold several changes into one mail
<seb128> ok, so autodup is working, great; )
* seb128 hugs pitti
<pitti> seb128: so the tag is removed so quickly that it doesn't mention it in the mail
<seb128> right
<pitti> seb128: but you should get followup emails from the retracing service for duplication etc.?
<pitti> don't you?
* pitti needs to find some time for CrashReporting, to silence down this madness
<seb128> pitti: the first mail I got already has "*** This bug is a duplicate of bug 122637 ***"
<ubotu> Launchpad bug 122637 in notification-daemon "notification-daemon crashed with signal 5 in g_logv()" [Medium,Incomplete]  https://launchpad.net/bugs/122637
<seb128> pitti: and there is no indication in mail of who marked it a dup
<seb128> and since the mail had only "** Tags: apport-crash"
<pitti> seb128: ah, so Malone really just compiles several steps into one mail
<seb128> right
<seb128> the retrace is too quick ;)
<pitti> seb128: with CrashReporting you won't see them any more at all
<seb128> it has time to modify the bug before the first mail
<pitti> seb128: I can make it slower if you need :)
<pitti> but I'm actually quite happy with the recent performance improvements, it keeps up ATM
<StevenK> pitti: Litter a few 'sleep(1000); # shush up seb128'  around the place? :-)
<StevenK> Oh, wait, even better.
<StevenK> sleep(1000) if $pkg_name =~ /^gnome/;
<evand> I'm not sure Ubiquity is off the hook yet wrt bug 122645.  I just tried to reproduce it using compiz but was unable to.
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [High,Confirmed]  https://launchpad.net/bugs/122645
<evand> of course I've never been able to reproduce the bug in the first place
<ScottK> pitti: Now that Tribe 2 is out the door I was wondering if I might bug you into having a look at https://wiki.kubuntu.org/MainInclusionReportPinentry
<pitti> ScottK: can you please poke me again next week?
<ScottK> pitti: Sure.  No problem.
* Hobbsee drops an Australian spider down pitti's back, instead of poking him.
<ScottK> Hobbsee: He needs to be alive and out of hospital to approve stuff.  Please ...
<pitti> Hobbsee: eeeeerrk
<Hobbsee> ScottK: we have Mithrandir for that.
<Hobbsee> pitti: *grin*
<pitti> Hobbsee: approving MIRs is my job (iwj can do it too, though)
<Hobbsee> pitti: it's very poisonous.  we have the 10 most poisonous spiders in the world, iirc.
<ScottK> Right.  "If you can't be a good example, then at least you can serve as a horrible warning."
* pitti is astonished by the amount of love Hobbsee gives to him
<Hobbsee> pitti: awww.
* Hobbsee hugs pitti 
* pitti hugs Hobbsee back and tickles her side
<Hobbsee> hey!!!
* Hobbsee stomps on pitti's feet
<geser> Hobbsee: we'll soon run out of archive admins if you eat or hurt each one
<Hobbsee> geser: heh.  then it's your turn?
* geser hides fast from Hobbsee
<Hobbsee> heh
<pitti> keescook: meh, now my bug responses were forgotten within two minutes (same browser session); seems that greasemonkey doesn't love me :(
<keescook> pitti: <stupid questions>do you have the latest GM?  do you click "Save Stock Replies"?</stupid questions>
<keescook> do they all show up in about:config for a while?
<pitti> keescook: 'save' > yes, sure
<keescook> once you have a bunch of replies, can you screen-cap it for me, so I can reproduce your config, to see if there is something buggy in the "save" routine?
<pitti> keescook: latest: 0.7.20070607.0
<pitti> keescook: I reordered the scripts now to have that one at the top; maybe that helps
<keescook> yeah, that's what I've got installed.
<keescook> I haven't been able to find any google-mention of this behavior, either.  :(
<Hobbsee> what's the process for renewing ubuntu memberships?
<pitti> Hobbsee: I mailed techboard
* iwj_ tries gutsy's debootstrap on etch.
<Hobbsee> cool, ok
<glatzor> Hobbsee: hi, there is an automatix product on launchpad that you can assign bugs too if you think that a problem was caused by it.
<Hobbsee> glatzor: twitch.  OK
<glatzor> Hobbsee: Since it is not part of Ubuntu you have to use the upstream bug feature
<gnomefreak> glatzor: they have thier own bug tracker afaik
<glatzor> gnomefreak: right. but they use a forum.
<Hobbsee> are they going to look at their automatix bugs?
<gnomefreak> glatzor: and? its not supported by ubuntu nor recommended to be used in ubuntu so send the bug or hte person that filed it to #automatix and let them handle it
<Amaranth> or just send it to the launchpad 'product' and forget it existed
<iwj> Well, that worked except that for some reason my eth0 has become eth1.
<glatzor> Hobbsee: Arnav Ghosh responded on every bug that I subscribed him to.
<Hobbsee> okay, cool
<gudegnaw> Have asked this in the main room and also posted on the forums with no luck, am trying my luck here and hope it won't offend anyone **I am running an edgy LAMP desktop and while trying to upgrade to Feisty through the update manager, I see that all the LAMP components are marked for removal and not marked for re-installation... why is that??,has anyone had trouble upgrading to Fesity while running LAMP?** 
<glatzor> gnomefreak: I don't know why we should "close" your infrastructure, only because some don't like automatix
<glatzor> gnomefreak: why should we make cooperation more difficult?
<gnomefreak> glatzor: this isnt the channel for this topic
* iwj finds the udev rules responsible.  Thanks, guys.
<glatzor> gnomefreak: I don't want to force you to discuss this.
<Keybuk> I  Dovecot
<Hobbsee> Keybuk: thanks for earlier, btw
<Hobbsee> Keybuk: i thought you'd avoid us mere mortal MOTU's like the plague :P
<Keybuk> heh, why?
<ion_> Yeah, dovecot ftw.
<ion_> keybuk: Btw, are you still running the compiz wallpaper plugin? Is it packaged somewhere?
<Hobbsee> Keybuk: because they were going to grill over MoM?
<Hobbsee> Keybuk: and because you're big and scary, and can kill their systems :P
<Keybuk> ion_: I'm not at the moment, need to bug racarr about some performance issues
<geser> Hobbsee: you aren't a mere MOTU anymore so he has no excuse to ignore you :p
<Hobbsee> geser: *grin*
<Hobbsee> geser: i meant the rest of hte people, actually.  but yeah
<agoliveira> Weird... I'm quite sure I didn't download the alternate Tribe 2 but that's what I got. I'll do it again, just in case.
<Hobbsee> aha
<Hobbsee> haha
<Hobbsee> not so helpful
<siretart> strange. openoffice is immediately exiting gracefully right after opening an (empty or new, doesn't matter) document
<siretart> apt-get install java-gcj-compat fixes that, now I try to reproduce this, but the crash doesn't reappear?!
<siretart> what's going on here?
<nixternal> mako: yay! peter brown just said congrats! and I am saying it too...Congrats!
<Keybuk> GPL 3 doesn't really interest me; all of the so-called "three-quels" released this year have been terrible
<Keybuk> oh, wait, I meant *Shrek 3*
<tri_> hi
<thom> hah
<bdmurray> I'm looking at bug 111081 regarding a desktop file not being translated.  Does that belong in Malone?
<ubotu> Launchpad bug 111081 in celestia "Celestia menu entry is in a bad place" [Undecided,Incomplete]  https://launchpad.net/bugs/111081
<Hobbsee> launchpad doesnt do universe translations does it?
<polopolo> Hobbsee, no, as far as I know, no
<polopolo> mwah
<polopolo> wait Hobbsee
<polopolo> Hobbsee: https://wiki.ubuntu.com/MOTU/Packages/Packaging/Kubuntu#head-f3515f500c9344cd9c3977017e074d4eab4ded82
<polopolo> I think not
<polopolo> I mean, yes
<tri_> what is the status of the elbuntu projekt ?
<polopolo> ah, Hobbsee leaves :D
<iwj> Excellent, etch + backports.org have dug me out of my Xen hole.
<zul> iwj: still waiting on xen kernel bits
<iwj> zul: Mmmmm.  At least I'm not blocking on it any more.
<zul> good
<zul> im just blocked now
<ion_> Funny. Logging in to gandi.net or slashdot.org from this machine fails on firefox (my normal profile as well as a fresh profile), konqueror, opera and w3m on this gutsy box. After logging in, zero to one pages can be loaded successfully until it just shows the login form again. My ntpd is working correctly, so it cant be a cookie time problem. Logging in works on an edgy box. All other websites seem to work on this box.
<mikmorg> hello
<mikmorg> Does anyone know what could be automatically load a module in /lib/modules, even though it is not instanced in modprobe configs?
<mikmorg> cjwatson_: Hello.
<mikmorg> cjwatson_: Have you ever booted casper with PXE?
<Nafallo> mjg59: hi. know any good, less than 2kg, laptop with an RS232? :-)
<bdmurray> bryce: https://help.ubuntu.com/community/DebuggingXAutoconfiguration is up to date right?
<stgraber> Nafallo: Look at HP, they still have laptops with parallel + rs232 ports
<Skiessi> compiling with pthread doesn't work for some reason (in gutsy) :P
<Nafallo> stgraber: kewl. thanks.
<ijuz__> Nafallo: latitude D620/D630 are like 2.1kg and have serial, the smaller ones not
<bryce> bdmurray: I just added a new item to it
<bryce> bdmurray: I'll doublecheck the other items
<bdmurray> bryce: cool, thanks
<Nafallo> ijuz__: thanks :-)
* Nafallo checks
<bdmurray> I wanted to make sure I am pointing people to the one you are working on. :)
<bryce> bdmurray:  btw, there are a number of bug reports with error messages such as described in that item - they all probably should be encouraged to try kylem's -intel 2.0.0 driver
<ijuz__> Nafallo: i have some problems with the GMA X3100 and gutsy... so i'm not so sure about the D630 :)
<Nafallo> ijuz__: sounds fun. I'll probably run gutsy virtualised anyway :-)
<bryce> bdmurray: yup those are all still valid.  I'll keep adding to the known-issues list as I run into good ones to put there
<ijuz__> Nafallo: everything else seems to work (i have a D830, i guess it's about the same as the D630 despite the size); feisty has the problem of course too
<Nafallo> hmm
<Nafallo> virtual AND multiboot :-)
<bdmurray> I wonder about subscribing BugSquad to debugging wiki pages
<bryce> bdmurray, if you do, this one might be good to add too:  https://wiki.ubuntu.com/XorgRecentChanges
<bryce> I'm maintaining that one just for you guys :-)
<sbeards> So spikebike and I are working on a project
<sbeards> calling it checksums done right (CDR)
<bdmurray> bryce: the I830WaitLpRing item?
<bryce> yeah
<sbeards> acts like tripwire but verifies against checksums in .debs and .rpms
<bdmurray> bryce: Does that show up in '/var/log/Xorg.0.log'?
<sbeards> goal is to verify what you have installed is what also on the mirror/media
<sbeards> also doesn't trust the client machine (probably do this through lvm snapshots)
<bryce> bdmurray: yes it does, at the end
<bryce> bdmurray: or Xorg.0.log.old
<sbeards> so far I've found around 5000 deb packages without a md5sums file in it
<bdmurray> so you have seen these bug reports against the xorg package?
<sbeards> out of 85000
<sbeards> not bad actually but it'd be better if every package had "official" md5sums
<sbeards> from searching the mailing lists it's an age old issue I know
<bryce> bdmurray: against the xorg-xserver-video-i810 package only
<bryce> they might be in xorg or xserver too, I didn't check
<evand> sbeards: that's probably a better topic for the ubuntu-devel-discuss mailing list, rather than IRC.
<evand> erm, it's probably better to post that topic to the*
<sbeards> evand: or a ubuntu security mailing list perhaps?
<sbeards> it's more of a security design issue
* sbeards joins ubuntu-devel-discuss after not finding an appropriate security list
<sbeards> evand: thx
<evand> sbeards: no problem
<bryce> bdmurray: I just posted the bug fixes that are added with mesa 7.0.0 and -intel 2.0.0 to XorgRecentChanges
<yveslu> hello, question: will gutsy have libc6 2.6 ?
#ubuntu-devel 2007-06-30
<wasabi> anybody want to leave commentary on bug #120051
<ubotu> Launchpad bug 120051 in adduser "does not canonicalize username before editing /etc/group" [Undecided,Incomplete]  https://launchpad.net/bugs/120051
<_MMA_> I posted to the -devel ML. Who do I tap to get it pushed through?
<bdmurray> bryce: I think I found one of those I830 bugs
<madmetal_spyros> is here the place to discuss about gutsy's bugs? (not asking for solution)
<persia> madmetal_spyros: #ubuntu-bugs is the best place for that.
<madmetal_spyros> oke :) although its gutsy's ;) 
<madmetal_spyros> thanks persia 
<deuce868> anyone on the laptop team might be able to give me a hand with a new T61?
<ijuz__> unsharp X with gma x3100?
<deuce868> no, I get funky resolution
<deuce868> http://www.mitechie.com/uploads/images/t61/00002.jpg
<ijuz__> damn, looks like i'm the only idiot with that specific problem
<deuce868> the unsharp X was noted in thinkwiki
<deuce868> had to recompile with a specific change
<deuce868> I haven't gotten that far yet
<deuce868> http://thinkwiki.org/wiki/Installing_Ubuntu_7.04_%28Feisty_Fawn%29_on_a_ThinkPad_T61
<ijuz__> deuce868: http://debian.christian-leber.de/d830/DSCF7379.JPG i have this too, when i connect an external screen, have you tried to set the screen res again with xrandr?
<deuce868> no, I've only set the res in the xorg.conf
<deuce868> I haven't tried out any xrandr stuff
<deuce868> oh wow, ok...so ubuntu thinks my laptop display is the tv out
<deuce868> no wonder I can't get above 30hz
<deuce868> so how does this xrandr work? I see the modes
<deuce868> and I see a * on the right one
<deuce868> but when i try to set it to 1440x900 I get not a valid type
<deuce868> "Size 1440x900 not found in available modes"
<ijuz__> already the 2.0.0 driver?
<ijuz__> deuce868: thank you very much, the thinkwiki link allows me to not get crazy on this sharpness issue, now i have beautiful KDE at 1920x1200 :)
<ProN00b> uh, is there a gui/automatic way to regenerate /etc/fstab ?
<deuce868> ijuz__: yea, it's 2.0.0 driver
<deuce868> glad that trick worked out for you ijuz__ 
<minghua> ProN00b: This is not a support channel.  Please try #ubuntu.
<deuce868> hopefully we can get these machines running
<ijuz__> deuce868: does X detect the lcd panel?
<deuce868> just default monitor
<deuce868> http://paste.avwsystems.com/paste/9
<deuce868> that's my xrandr output
<ijuz__> can't you switch the TV off?
<deuce868> with xrandr?
<ijuz__> xrandr --output=TV --off something like that
<deuce868> or you mean a bios setting?
<ijuz__> when you have xrandr 1.3
<deuce868> bingo, you're my hero
<deuce868> gnome menu's just went full screen
<ijuz__> does beryl work for you? :)
<deuce868> so now the question, should I submit a bug to gutsy or anything?
<deuce868> I turned off the desktop effects
<deuce868> one sec, I'll try to re-enable
<ijuz__> my X hangs when i start beryl
<ijuz__> (as in dead)
<wasabi> so who should i petition to get the fade out animation removed for gksu?
<wasabi> like, it's really obnoxious. And doubly so if you have compiz running.
<bhale> wasabi: i blame seb
<deuce868> ijuz__: no, I seem to be able to enable desktop effects ok
<deuce868> I can't see how to disable the tv though
<deuce868> I have to do it on each boot
<ijuz__> i think you can set output in the xorg.conf
<ijuz__> damn, here it dies (it's a Dell D830 and not a T61)
<deuce868> that's ok, it's all nuts. 
<deuce868> can't set the brightness unplugged
<deuce868> it even jumps around on its own lol
<wasabi> it should be `if (compiz) doPrettyCompositeEnabledFade();`, and that's it.
<wasabi> I tjust looks like utter crap otherwise. Every program redraws in some random order. Slowely.
<wasabi> And the fade out is a giant window wiper moving from the top to the bottom three times.
<deuce868> ijuz__: hey, how did you get the blur trick to work?
<deuce868> I can't get the package to build
<deuce868> dh command not found?
<wasabi> so are ya'll being smashed with crash reports since introducing apport?
<wasabi> like, i'm about to submit ... 9 various crash reports. 
<wasabi> n/m launchpad dead. ;)
<deuce868> you find launchpad not letting you submit as well?
<wasabi> yeah
<wasabi> It's working now intermittently.
<deuce868> '
<Hobbsee> why are there *never* any members here of the CC when i want them?
<Hobbsee> (and active)
<persia> Hobbsee: Weekend?  Europe?
<Hobbsee> true that
<Hobbsee> was just hoping regardless
<okaratas> hello
<Burgundavia> hello okaratas
<okaratas> Burgundavia, how are you ?
<Burgundavia> not bad
<okaratas> okey
<okaratas> hmmm
<okaratas> what is te bug?
<okaratas> "Jun 30 08:15:31 ozgur kernel: [ 2011.209277]  SKB BUG: Invalid truesize (304) len=1440, sizeof(sk_buff)=176"
<okaratas> what in interest SKB BUG?
<mikmorg> hello
<mikmorg> I'm trying to work a bit with Ubiquity, but am having a hard time understanding exactly where it is pulling from. Does ubiquity copy casper's live root to the harddrive? Does it create a new initrd, or copy casper's as well?
<superm1> mikmorg, it doesn't copy the live root
<superm1> it only copies the unmodified version
<superm1> you can see whats copied in /rofs on a live disk
<superm1> i believe it does however generate a new initrd
<superm1> after everything is copied over
<superm1> and casper is removed
<mikmorg> superm1: perfect..
<mikmorg> thanks
<superm1> mikmorg, are you looking to modify it, or adapt existing towards a live disk your making?
<mikmorg> superm1: actually, I'm not sure what I can and cannot discuss at the moment.
<mikmorg> superm1: sorry.
<superm1> mikmorg, pm?
<superm1> or just can't period
<mikmorg> superm1: pm is..?
<superm1> private message 
<mikmorg> superm1: ah, no sorry.. not yet :(
<superm1> well if this is for a derivative distro, I can work with you a bit on adapting ubiquity towards it.  i've been working on a fairly large patch for mythbuntu
<mikmorg> superm1: Do you work at Canonical?
<superm1> mikmorg, no
<superm1> do you?
<mikmorg> No, I'm working at Dell.
<superm1> ah okay
<superm1> that would make more sense as to not being sure what can and cant be discussed
<mikmorg> superm1: Precisely :)
<superm1> okay well feel free to ping me with any other questions, and likely you should join #ubuntu-installer.  the main installer guys, including the ones working for canonical are found there most of the time
<mikmorg> superm1: Ah, they've been hiding from me in there all this time?
<superm1> hehe
<mikmorg> superm1: Thanks a lot - I didn't notice that room.
<mikmorg> superm1: You wouldn't happen to know if the /cdrom/casper/initrd.gz is generated inside of the same casper image as what is on the CD, would you?
<superm1> evand and cjwatson will be the two main guys to talk to in there
<mikmorg> superm1: I've been discussing quite a few things with cj.
<superm1> i dont know too much about how the official process for generating that file is (i haven't seen canonical's live cd build process).  For our mythbuntu disks, we have been using the same initrd.gz for /cdrom/casper/ as well as the one sitting in the root of the disk
<superm1> best way to determine for sure if you can't catch one of those guys is just md5sum the two of them
<superm1> and compare
<mikmorg> superm1: Good point. I didn't notice that the one in the root of the disk ever gets called.. am I wrong about that?
<mikmorg> Nevermind,
<superm1> mikmorg, i can't think of any reason it would be called, other than since its a symlink to /boot
<mikmorg> I don't see one at all
<superm1> so when the system is copied over
<superm1> oh.
<superm1> :)
<mikmorg> ah yes, in casper..
<mikmorg> superm1: It seems that I'm lucky
<superm1> mikmorg, why is that?
<mikmorg> superm1: /cdrom/casper/initrd.gz is indeed generated by (or at least, can be) the casper FS on the CD
<mikmorg> a diff -r returns clean
<superm1> ah :)
<Hobbsee> hiya LaserJock 
<LaserJock> hi Hobbsee 
<Hobbsee> how's it goign?
<ajmitch> hey LaserJock 
<LaserJock> it's, you know ... going
<LaserJock> I'm hackin' on some Edubuntu stuff
<Hobbsee> heh
<LaserJock> it's always fun being the first to do things :/
<ajmitch> it certainly is
<Fujitsu> LaserJock: What are you trying to do?
* Fujitsu waves.
<LaserJock> this 2nd CD we introduced in Feisty has caused all kinds of interesting things
<Hobbsee> hiya Fujitsu 
<Fujitsu> Hi Hobbsee.
<LaserJock> Fujitsu: currently I'm playing around with the .iso build process to end up with a customized gnome-app-install window when you pop in the 2nd Cd
<Fujitsu> Ah. Sounds fun.
<LaserJock> luckily mvo, et. al did a good job when they wrote g-a-i :-)
<jsgotangco> LaserJock: i remember something similar to what Xandros does with their 2nd CD
<jsgotangco> put the CD in, and a selection window pops out
<LaserJock> jsgotangco: in Feisty, you get a window that lets you go to either synaptic (with the CD added to sources.list) or g-a-i showing just the contents of the CD
<LaserJock> but most all the apps end up in Education with a lot of other empty menus
<LaserJock> boy, I think gutsy almost ate a hard drive today
<ajmitch> how?
<LaserJock> I have an old computer at work that I have running gutsy, and I did my usual dist-upgrade
<LaserJock> and I rebooted the other day and kinda forgot about it
<LaserJock> but today I went to do something with it and noticed it was reeeealy slow
<LaserJock> and I got all kinds of "not-so-nice" messages in console
<LaserJock> bunches of udev stuff
<ajmitch> heh
<ajmitch> ah, ignore those :)
<ajmitch> udev & devmapper?
<LaserJock> so I googled around and found a launchpad bug
<LaserJock> apparently it was driving my hard drive into the ground
<ajmitch> yay
<LaserJock> so I got rid of evms and it seems ok
<LaserJock> but the drive is old and I got a few IO errors
<LaserJock> so I made backups today :-)
* ajmitch had to reset earlier, after loading a video in mplayer killed X & locked up the whole system
* ajmitch blames nvidia drivers
<jsgotangco> it must be the video
<jsgotangco> :)
<LaserJock> of course
<LaserJock> darn those binary blobs ;-)
<ajmitch> given that the last I saw before I killed X, was X taking 100% CPU time
<ajmitch> after I killed X I lost network access
<ajmitch> generally happens when the kernel goes into la-la-land
<LaserJock> heh, that's why I use ancient video cards that only work with vesa :-)
<ajmitch> I need my gaming fix
<LaserJock> although I so want to try out the new "desktop effects by default"
<ajmitch> though I originally went for an nvidia card because there was a spare dual-head card
<ajmitch> and I really miss dual-head now :(
<LaserJock> heh
<LaserJock> I could do a dual-head setup, 17" CRT and air ;-)
<ajmitch> hah
<LaserJock> although there is actually a whiteboard right beside it
<ajmitch> I was spoilt - now a 20" LCD feels small
<LaserJock> I could draw a screen
<LaserJock> and call that my bling monitor
<ajmitch> ooh, cubes!
<LaserJock> hmm, my 3D wet-erase art isn't the best
<ajmitch> aha, found that box of blank DVDs
<ajmitch> time to start with backups
<ion_> I used to have two 17 CRTs, now i have a single 22 TFT. I prefer this one. Two 22s would be nice, but also expensive.
* Mithrandir ponders getting a 20" in addition to his two 17" screens.
<Mithrandir> problem is, my desk is getting too small
* persia suggests goggles
<Mithrandir> goggles with a virtual 10k by 10k screen?
<Hobbsee> Mithrandir: then get a bigger desk.
<Hobbsee> problem solved.
<Mithrandir> Hobbsee: that would entail getting a new apartment, since it's quite crowded in here already.
<Mithrandir> and that's just too much hassle
<persia> Umm..  That'd be really nice, but I was thinking something actually on the market (like 800x600 or 1024x768), the point being that they provide more pixels without using desk space.
<Hobbsee> Mithrandir: over a computer monitor, yes.
<ajmitch> Hobbsee: monitors are *important*
<Hobbsee> ajmitch: hence 2x 17 inch ones should be sufficient.
<LaserJock> ajmitch: they are?
<LaserJock> well, one is at least
<Mithrandir> hmm
<Mithrandir> I could just replace one of them with a 20" instead.  There might be room for that.
<LaserJock> but the reason I haven't gotten a flat panel for my dekstop is I'm always just ssh'd into it anyway
<persia> Mithrandir: You could get the rotating kind, and switch the aspect.
* Fujitsu is using a state-of-the-art 15" CRT.
* Fujitsu kicks Dell AC adapters.
<LaserJock> I wonder what would happen if I took a bunch of those 7" displays on the intel classmatepc and glued them to the wall
<LaserJock> seems like that would be a bit of a disaster
<Kmos> Fujitsu: that's for museum :)
<Mithrandir> I saw HP had done something cool with projectors; by some nice use of software, you just pointed a bunch of projectors at a wall, told them to calibrate and then had a huge screen
<Fujitsu> Kmos: Unfortunately it's all I have other than my laptop LCD.
<Fujitsu> Mithrandir: Mmm... sounds expensive.
<Hobbsee> Fujitsu: projector bulbs are, yes.
<Mithrandir> Fujitsu: not when you can use cheap projectors.
<Mithrandir> you get 800x600 projectors here for about 500
<Fujitsu> Still rather expensive.
<Hobbsee> then you have to manhandle the projector to work, too
<Hobbsee> which is fine, assuming you know what you're doing
<ion_> DIY projector, http://inventgeek.com/Projects/HomeTheater/overview.aspx :-)
<StevenK> Hobbsee: The projector we have at $WORK came with a padded bag that neatly fits the projector and all cables.
<Hobbsee> StevenK: that's not the problem
<StevenK> I misunderstood "manhandle the projector to work" then. Okay.
<Hobbsee> StevenK: if that were the problem, i would never have gotten called out of class countless times from other classes trying to make their projector work, because the students would often say "oh, go get sarah, she can fix this"
<ajmitch> hah
<Hobbsee> usually with a combination of power, and function+f8.
<StevenK> Hah
<ion_> Hehe
<Hobbsee> and occasoinally having to cycle the projector so it was getting the right input.
* Hobbsee seems to be an expert in projectors, radio mics, and a fwe other sound-type bits, and fairly good in the rest of them.
<Hobbsee> of course, it gets really interesting when you just walk into someone else's classroom, where the teacher has never met you before, and saying "here, i'll fix the projector" - or telling your own teacher "i'll be back in a minute"  "where are you going?" "fixing things"  "but where are you going?"
<Hobbsee> mentally going: stop asking me these questions, you really dont need to know, and it's disrupting the class.
* Hobbsee shrugs
<Kmos> http://people.ubuntu-in.org/~carthik/bugstats/
<Kmos> not working
<ijuz_> deuce868: apt-get build-dep xserver-xorg-video-intel
<Fujitsu> Kmos: It's due to the unannounced LP change last week.
<Fujitsu> Kmos: I haven't seen carthik around lately.
<Kmos> i'll mail him
* pitti jumps at Hobbsee and tickles her feet
<pygi> pitti, you're supposed to eat her :)
<pitti> nah, I'm a semi-vegetarian
<Kmos> lol
<ajmitch> pitti: you eat semi-vegetables?
<pitti> ajmitch: yeah, only one half of an apple at a time
<StevenK> pitti: Is libspandsp* in binary NEW still?
* StevenK is glancing at cruft stuff.
<pitti> StevenK: no, nothing in new
<pitti> StevenK: shall I update it for you again?
<pitti> StevenK: next week I'll look into automating this, but it's not really trivial
<StevenK> pitti: I haven't done anything, so I don't see the point.
<StevenK> I did however, see spandsp FTBFS on amd64, so I'm chasing that, first.
* pitti just does it, can't hurt
<StevenK> pitti: And jackass says, "That's what you think" ? :-P
<pitti> StevenK: you mean drescher?
<StevenK> people.u.c is jackass, or does jackass only host?
<pitti> StevenK: ah, people is rookery
<pitti> StevenK: jackass is the old archive.u.c., still used for security uploads and processing
<StevenK> Ahh.
* StevenK figures out why spandsp dies, and tries to fix it.
<pygi> morning Zdra 
<Zdra> hello pygi
<StevenK> Gah.
* StevenK kicks it up a notch, and starts doing build time munging of .install files.
<Fujitsu> StevenK: That sounds a little evil.
<StevenK> Fujitsu: Files are installed into /usr/lib for every arch except amd64 where it's /usr/lib64.
<Fujitsu> Ah.
<Fujitsu> StevenK: /usr/lib64 is a symlink here.
<LaserJock> does bzr get faster at pushing after the initial one?
<Fujitsu> LaserJock: It doesn't have to push the whole lot, so yes.
<Fujitsu> Much, much quicker if it's a large tree like mplayer.
<StevenK> cp: cannot stat `./debian/tmp/usr/lib/libspandsp.so.0': No such file or directory
<LaserJock> well, I just discovered my last branch on LP is 55 weeks old
<LaserJock> which seems rather pathetic
<pitti> StevenK: I cleaned up some cruft and updated the lists
<StevenK> pitti: Great, thanks.
<StevenK> I'm still twitching over curl*.
<StevenK> Fujitsu: /usr/lib64 being a symlink has nothing to do with $(CURDIR)/debian/tmp/usr/lib64
<Fujitsu> StevenK: Noted, but I failed to realise that is what you meant.
<zer> Gutsy contains new default directories in $HOME: Documents, Music, Pictures, Videos. Will there be any plans to support a localized version?
<persia> zer: Yes.  The default folders should have localised names at release time.
<ion_> Capital letters in directory names for the lose.
<zer> persia: ok, good news. Because i know that if i create a directory "Dokumente", no Bookmark gets created. But if i create "Documents", a new bookmark for this directory appears automatically.
<ion_> ...as long as we use case-sensitive filesystems. :-)
<zer> nautilus-sendto only contains Evolution in Gutsy, no Pidgin-support anymore?
<minghua> persia: Are the xdg-user-dirs folders ubuntu specific?
<persia> minghua: Not to my knowledge.
<minghua> persia: Good, then most likely they are going to be translated in time.  Otherwise I have my doubts.
<persia> minghua: A fair amount seems to be done upstream (see http://www.freedesktop.org/wiki/Software/xdg-user-dirs).  None for JA though :(
<minghua> persia: It's still a long way until string freeze, don't worry.
<minghua> persia: BTW do you use a ja desktop?
<persia> minghua: I usually use English, but sometimes ja or ru for testing l10n issues.
* Hobbsee stomps on pitti's fingers
<ajmitch> that's unnecessarily cruel & vicious
<pygi> ajmitch, it's not
<pygi> :)
<Hobbsee> ajmitch: no it's not
<Hobbsee> ajmitch: not if he's jumping at me and tickling my feet :P
<pygi> Hobbsee, don't steal my words!
* Hobbsee eats the words.  yummy!
<ajmitch> Hobbsee: and when did he do such things?
<Hobbsee> [19:25]  * pitti jumps at Hobbsee and tickles her feet
* minghua feels a bit more guilty for not using zh desktop.
<ajmitch> Hobbsee: nothing wrong with that :)
<persia> minghua: Is there enough translation?  ru is usually pretty solid, but ja still has lots of English scattered about.
<minghua> persia: GNOME should be okay, which is what I use
<Fujitsu> persia: How many languages do you speak?
<persia> Fujitsu: Um.  Zero?  I can say at least a few words in many, handle taxis in restaurants for most majors, have once held conversations in five or six, and am no longer confident in my ability to be correct in any.
<minghua> texis in restaurants?
<Mithrandir> big restaurants; you have to take a taxi around in it.
<mpt> What's Japanese for "What the hell is that taxi doing in my restaurant"
<minghua> poor waiters
<Fujitsu> Mithrandir: Heh.
<persia> minghua: Case in point :)  Should have been taxis and restaurants (but not for arabic or farsi, sadly).
<Mithrandir> mpt: "idling" would be a good response.
<ion_> The fi desktop is awful. The most annoying thing is that theyve translated MB to Mt, as if standard units were somehow translatable. Not only that, but t is already taken by tonne. :-)
<pygi> ion_, didn't you said that already?
<pygi> deja vu!
<ion_> Yes, i did.
<Fujitsu> Those are some damn heavy files.
<mpt> I would like to see a grading of Ubuntu translation quality done by people fluent in each language
<pygi> :)
<minghua> I imagine qualification of the graders is going to be a problem :-)
<mpt> because otherwise it's very difficult to tell how well Ubuntu's translation effort is goin
<mpt> -g
<mpt> Yeah, it's a bit of a catch-11
<Fujitsu> Um, catch-22?
<persia> mpt: I think that as interest in each country grows, the translations naturally get better.  pt is really strong, for example.
<mpt> Fujitsu, no, not as bad as a catch-22, it goes only in one direction
<persia> Fujitsu: No.  We're all mad - but nobody is trying to leave.
<Mithrandir> you could just have a simple majority vote and do some analysis based on the mean and the median (and maybe the standard deviation).
<mpt> Similar to the problem of grading Wikipedia articles
<Fujitsu> mpt: Ah.
<Mithrandir> it wouldn't be perfect, but it should give you a reasonable number, I would think.
<mpt> or grading Free Software usability
<ion_> Or the naming of free software. ;-)
<ion_> Case in point: qtpfsgui
<mpt> haha
<mpt> or gimp
<mpt> or iceweasel
<Mithrandir> ion_: it's a qt program, doing stuff with PFS and it's a gui app.  I don't see what's weird with that.
<persia> mpt: I like my graphical image manipulation program!
<minghua> hmm, I think ubuntu's code names are worth mentioning as well
<ajmitch> minghua: isn't the gutsy gibbon descriptive enough?
<mpt> minghua, and the version numbers
<Mithrandir> I'd rather have names be unique than descriptive.
<persia> minghua: They get real version numbers at release.  It's not that different than other environments.
<minghua> ajmitch: yeah, very descriptive, especially translated to Chinese
<mpt> http://www.google.com/search?q=intext:%22ubuntu%207.4%22
<persia> minghua: Why do we need to translate internal code names, when development is done in a single language?
<Mithrandir> names such as "evolution", "tasks" or "excel" are horrible names, they are all common words which makes searching for them hard and with the exception of tasks doesn't say what the app does at all.
<mpt> http://www.google.com/search?q=intext:%22ubuntu%206.1%22
<minghua> persia: I have no idea, but I see those translations on Chinese forums, some of which makes me frown
<mpt> Mithrandir, that's true too, but that Microsoft gives things crappy names is not an excuse for us to do so as well :-)
<Mithrandir> mpt: two of my three examples were free software projects.
* persia wonders about the adjective animal model when translated into super-concise and implication-rich chinese languages
<mpt> oh?
* mpt hadn't heard of Tasks
<Mithrandir> mpt: you can try searching for it. :-P
<mpt> har har
<Mithrandir> http://pimlico-project.org/tasks.html
<Mithrandir> (oh, and they have "contacts", "dates" and "sync" too.)
<mpt> So compounds are an easy way of generating searchable names
<mpt> Firefox, OneNote, OpenOffice, Dreamweaver, Photoshop, Thunderbird
<Mithrandir> half of which doesn't say what the application actually does.
<persia> mpt: Yes, but how do you translate compounds into languages with no common phonetic representation?
<mpt> Right, searchability is desirable but not sufficient
<mpt> Photoshop and OneNote are vaguely reminiscent, the others of those are not
<Mithrandir> firefox?  That's an animal.  OneNote?  Note-taking program?  Word processor?  Bibliography manager?  Dreamweaver?  Uh, program for controlling weaving machines?  Animation package?  Thunderbird?  Just a mythical animal.
<mpt> exactly
<minghua> persia: actually when it comes to animals, Chinese is far less concise than English
<Mithrandir> openoffice.org isn't all bad, since people know what an office program is (even if the term is incorrect).
* persia goes to look at a Mandarin dictionary
<minghua> I don't know how often English speaking people use "gibbon" in daily conversations, but I think most Chinese just call them "monkeys"
<mpt> persia, by "no common phonetic representation" do you mean no equivalent of hiragana/katakana?
<minghua> we do have a term for zoologists, but I doubt everyone knows it
<minghua> so firefox is a real animal?
<persia> mpt: Or, more generally no phonetic alphabet (Roman, Hangul, kana, Arabic, etc. are all fine).  I've most frequently seen this issue with Chinese environments.
<Fujitsu> minghua: I've not heard of it.
<persia> mpt: Specifically, if it can be pronounced, but has no meaning, it's easy to substitute some characters to make a similar sound (and it's obviously a foreign word), if it is a compond, there may be a tendency to translate the meaning of the individual sections, rather than the sound, which can be confusing.
<mpt> persia, dunno. How did Google China end up as Gu Ge?
<minghua> persia: I don't quite understand your comment about Chinese and compounds
<minghua> mpt: Alas, that was a interesting story
<persia> mpt: Phonetic similarity to a nonsense word (obviously foreign).
<minghua> Fujitsu: you haven't heard of "council greyskull" either, you don't count. :-P
<mpt> Maybe the answer to translating things like that is "don't"
<persia> minghua: My IME is not working today, but essentially the difference between (fi)(re)(fo)(ksi) and (fire)(fox).
<mpt> Even though Ubuntu has a meaning, I wouldn't expect that to be translated
<mpt> Same for other brand names
<persia> mpt: Use Roman characters then?
<minghua> persia: Oh I see.  That's fine, as we can do phonetic translations (as mpt just pointed out, google -> gu ge), but it's not as common as in Japanese
<mpt> persia, I don't know.
* mpt compares with http://www.apple.com/jp/macosx/leopard/
<persia> minghua: That's because you don't have kana :)  Anyway, I'm thinking about translator confusion, rather than anything else.
<minghua> in the case of firefox, we translate literally as fire (huo) + fox(hu)
<persia> minghua: Right.  That's an example of something that makes componds dangerous.  As pointed out before, DreamWeaver would be a good name for an automated loom control system.
<minghua> yes, I agree, a lot of compounds translate to quite hilarious words in Chinese
<persia> I like either mpt's idea of not translating, or documenting that translators should use phonetic equivalents when translating names.
<mpt> and http://www.microsoft.com/japan/windows/products/windowsvista/default.mspx
<minghua> take our google example, before they decide on a Chinese name themselves, it is affectionately called "ancient dog" due to phonetic similarity
<minghua> google is not exactly compounds, but that's on top of my head
<persia> mpt: Japanese is a poor example, as most Japanese are familiar with three phonetic systems.
<mpt> So ideally their new name should have been a translation of "new tricks" :-P
<persia> Mixing is very common, and not mixing is considered poor use of the language.
<mpt> persia, you mean most of them know Romaji?
<persia> mpt: Standard Education requires 10 years of English.
<minghua> persia: why three?
<mpt> ok, http://www.microsoft.com/china/windows/default.mspx
<mpt> same thing
<minghua> windows is a bad example, you just can't translate it, too confusing
<persia> minghua: hiragana for native words, katakana for borrowed words or emphasis (often used like italics), and Romaji for style (often used for foreign words (not always correctly), proper names, or for even more emphasis).
<minghua> office is another bad example
<mpt> and http://www.apple.com.cn/macosx/leopard/index.html
<mpt> There are leopards in China, right? :-)
<persia> There's at least  
<minghua> persia: oh, I see.  I mistakenly thought "three pronunciation systems".
<minghua> probably not
<minghua> leopards are translated "American ", I think
<minghua> let me check on wikipedia
<mpt> minghua, is it *more* confusing in Chinese than it is in English?
<persia> That's more Roman characters than I usually see on Chinese pages.
<mpt> ("We run a Microsoft office" vs. "We run Microsoft Office")
<minghua> mpt: I don't know, I use Chinese and English in too different occasions
<persia> minghua: I think that's panther.
<persia> mpt: Where is "We run a Microsoft office"?  Is that a machine translation?
<minghua> persia: It seems either of us is right.  leopard is indeed the Asian one, jaguar is the American one.
<minghua> neither*
<persia> Hmmm.  I liked either better :)
<mpt> persia, in English the phrase "Microsoft shop" is far more common to refer to an office or department that uses Microsoft software exclusively or nearly exclusively
<mpt> even when they're not shops
<persia> minghua: Still, it's " ", no?
<mpt> and that *might* be because of the existence of Microsoft Office making "office" confusing, but there's no real way to tell now.
<persia> mpt: That's just jargon.
<minghua> persia: I suppose so, although I doubt there are many leopards left in China, as we don't talk much about it.
<mpt> We should resolve this by using numbers for product names *as well as* for versions
<persia> minghua: Probably not :)  Maybe in the far northwest (unless that's too dry for them).
<minghua> persia: In Chinese culture tiger is the typical big, wild and carnival animal.
<mpt> Ubuntu Gutsy shall henceforth be 7471108.7.10
<minghua> "King of all beasts" and that.
<persia> minghua: Amusingly, in English, the "King of all beasts" is the lion.
<minghua> yeah I realize that.
<minghua> most likely because there are tiger in China (or *were*).
* persia doubts there were ever wild lions in England
<mpt> There wer 125000 years ago
<mpt> were
<persia> mpt: Why 7471108?
<mpt> chosen at random
<leleobhz> someone can explain me how the restricted-modules package works?
<leleobhz> because i want to update the fglrx but a simple uupdate will not work
<sivang> hi folks
<sivang> does someone know of a reliable way to compare two dirs and make sure they are identical? or is 'diff -r dir1 dir2' the way to go? (I copied a bunch of gigs from ext3 to xfs FS and size differ in about 4G so I want to make sure it's all there)
<geser> sivang: do you only want to compare the file list or also the file contents?
<Mithrandir> sivang: I'd use md5sum or sha1sum rather than just diff.
* Hobbsee stomps on Mithrandir's toes too
<sivang> geser, Mithrandir : thanks guys, but it appears I found the culprit - permission problem that prevented true calculation of sizes
* pygi eats Hobbsee 
* Hobbsee is inedible
<Mithrandir> you can still be eaten
<Mithrandir> just not digested.
* sivang high fives Mithrandir 
* Hobbsee can not be eaten, nor digested.
<pygi> Hobbsee, but you already are eaten ... which kindof makes your theory false
<Hobbsee> no i'm not
<pygi> yup, you are
<sivang> Mithrandir, geser : diff seemed to be enough for this purpose, as I did want to only compare file list and not contents
<pygi> Hobbsee, ^^
<evand> Wow, gnash leaks like a sieve.
<Hobbsee> hiya evand 
<Hobbsee> evand: i tentatively triaged a few ubiquity bugs
<evand> hello Hobbsee 
<evand> great!
<Hobbsee> evand: basically dupes of the sudo/gksudo problem.
<evand> good, perhaps the additional logs will give a clearer picture, though as cjwatson has suggested it's probably the interaction with gksudo
<Hobbsee> evand: i dont use gnome normally, so dont know about gksudo itself.  but yeah.
<Hobbsee> at least, that's what the cause of it seemed to be, to me.  *shrugs*.  it's not WM related - although the symptoms change dependant on the WM
<evand> 'tis a very odd bug
<Hobbsee> indeed.
<RageMax> I'm seeing the busybox "can't access tty; job control turned off" error in both feisty and gutsy
<RageMax> the machine works fine with knoppix
<ijuz_> RageMax: when trying to boot the desktop cd?
<RageMax> ijuz_: right, I see a lot of other people are having the problem as well
<ijuz_> that is some new hardware?
<RageMax> yeah, it's a newish gateway laptop
<ijuz_> i thought gateway is dead... bu tok
<RageMax> nah, their laptops are better than dell ;)
<ijuz_> use the alternate cd
<ijuz_> it will load the generic-ide module
<RageMax> the laptop is SATA
<ijuz_> well, no idea what it is in my laptop... but it worked there, you can in the meantime try modprobe generic-ide from the console you get when booting the desktop cd fails
<ijuz_> cat /proc/kmsg will show you if it was found
<ijuz_> no idea if there is someway to start the boot script again
<RageMax> ijuz_: thanks, you pointed me in the right direction, I got it to boot
<RageMax> need the generic.all_generic_ide option set to 1 upon boot
<ijuz_> as boot parameter?
<RageMax> yeah
<RageMax> this has to be a huge frickin hack
<ijuz_> no idea if there is already a bug report for this, basically the script should try to load ide-generic before giving up
<RageMax> found another bug with the intel driver, but it looks like someone reported that already
<RageMax> xdriver that is
<Kmos> etank: bug 46135 , not fixed yet ?
<ubotu> Launchpad bug 46135 in ubiquity "Failed to create file system (with 'erase entire disk')" [Medium,Confirmed]  https://launchpad.net/bugs/46135
<etank> Kmos: i dont know
<etank> i haven't seen that bug before
<Kmos> etank: still from 2006
<Chipzz> Kmos: that looks like a bug which has a reasonable explanation and work-around
<Kmos> yeah, maybe
<Chipzz> so: Kmos haven't created a patch for bug 46135 yet? ;P
<ubotu> Launchpad bug 46135 in ubiquity "Failed to create file system (with 'erase entire disk')" [Medium,Confirmed]  https://launchpad.net/bugs/46135
<Kmos> Chipzz: isn't attached
<Chipzz> (subtile or less subtile way to point out that this isn't the best place to come complain about your favorite bugs ;) ;) )
<Kmos> or someone reproduce it at new ubiquity version to see if it's fixed
<Chipzz> (Kmos: or at least try to use a few more words; in hindsight your question could be interpreted as "is this bug aleady fixed or not?", but the way you put it sounded an awefull lot like "why hasn't this been fixed yet? hurry!" ;P)
#ubuntu-devel 2007-07-01
<lamont> pitti: checking email some... just really really laggy
<Hobbsee> hi all
<ajmitch> hi Hobbsee 
<Hobbsee> :)
<ajmitch> how are you?
<Hobbsee> i'm vaguely attempting to clean up the mess here, etc.  i'm not reallyw inning.
<Hobbsee> mum keeps having a go at me.  the regular stuff :P
<Hobbsee> ajmitch: ^
<ajmitch> aha
<ajmitch> nothing new then :)
<Hobbsee> exactly :)
<Hobbsee> ajmitch: then again, they have given up on blasting me for being up at all hours of the night now, which is good.
<ajmitch> and you don't have to be home before 12?
<Hobbsee> er...i think i still have that limitation
<Hobbsee> havent really tried, tbh.
<ajmitch> a shame
<Hobbsee> ajmitch: usually i'll just crash at a friend's place, if i'm going out, so...
<ajmitch> oh well, enjoy your day, I'm going out for a bit :)
<Hobbsee> have fun :)
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
#ubuntu-devel 2008-06-23
<lifeless> ok,thats amusing:
<lifeless> robertc@lifelessgwy:/etc/ppp/ip-up.d$ sudo sudo do-release-upgrade
<lifeless> Checking for a new ubuntu release
<lifeless> No new release found
<lifeless> robertc@lifelessgwy:/etc/ppp/ip-up.d$ less /etc/issue
<lifeless> Ubuntu 6.06.2 LTS \n \l
<wgrant> lifeless: That's correct.
<wgrant> lifeless: Dapper upgrades won't be activated until 8.04.1.
<lifeless> wgrant: not according to https://help.ubuntu.com/community/HardyUpgrades
<lifeless> it claims it should work now
<lifeless> wgrant: I appreciate you may be right; but the docs out there disagree
<wgrant> http://changelogs.ubuntu.com/meta-release-lts says that the docs are wrong.
<wgrant> You might want to add a -p
<lifeless> (because its pointing at dapper ? )
<wgrant> Because there's no Hardy in there.
<wgrant> Whereas meta-release-lts-proposed does have it.
<lifeless> k; I've not actually dug around the meta-release internals before
<lifeless> thanks; I'll documentt his
<lifeless> *this*
<wgrant> They're what the upgrade tool uses to work out what's new.
<lifeless> yes, I'm aware of the principle
<lifeless> just hadn't looked at the details
<wgrant> Ah.
<wgrant> Documentation is good.
<lifeless> time to see how the upgrade goes
<lifeless> (this machine has 96MB of memory)
<wgrant> Heh.
<lifeless> P133, firewall/cache for my home network. LOTS of disk - a whole 2.7GB
<lifeless> sorry, 3.9GB, 2.7GB of which is used.
<wgrant> I don't think I've run Ubuntu on anything that old.
<lifeless> digital obselescence is vastly exaggerated
<cody-somerville> grr... I hate how Firefox opens your homepage when you open a new window.
 * cody-somerville has his homepage set to 30 or so tabs.
<johanbr> cody-somerville: Why not keep those 30 tabs as bookmarks or as a saved session instead?
<cody-somerville> thats what I'll end up doing.
<chubs_> cody-somerville: I feel sorry for your bandwidth
 * cody-somerville has only used 5GB this month :P.... he spends too much time at work :(
<Tyrone_man> Hey everyone, I was wondering if there is a way to get an iso of intrepid, or do I have to work up from an existing system by a dist-upgrade to a given repo? Thanks
<RAOF> Tyrone_man: http://iso.qa.ubuntu.com/ ?
<persia> Tyrone_man: There's no livecd yet, but the alternate CD has testing images from http://iso.qa.ubuntu.com/ : report success/failure please.
<Tyrone_man> oh, thanks.
 * persia loses the race to RAOF again: maybe glue is the answer
<Tyrone_man> I will see about a virtual install, but I'd like to let you all know of a little bug in hardy (for your safety). Sometimes, when deleting big (1gb+) files, the userfs will just go psycho and swell up the ram and swap, even after deletion, resulting in a HUGE slowdown, and misstypes at a terminal, such as messing a keystroke, along the lines of rm -R ./* to rm -R /* ... thus forcing you to type this from fedora..
<pwnguin> userfs?
<lifeless> whats an rfs, that you use it?
<Tyrone_man> yea, the new gfs. Ya know, the big shiny upgrade that everyone was waiting for
<pwnguin> oh that
<Tyrone_man> I meant userspace fs
<Tyrone_man> sorry, my bad
<pwnguin> so this is a network mount?
<Tyrone_man> It was just a local partition on my disk, was doing some video editing, sent something to trash can while I was cleaning another dir, and bam... I figured it out when i hit 'ls' and got 'cannot locate /bin/ls' .. i was like :<
<Tyrone_man> I'm sorry, did I mess that up again? It's gvfs isn't it? Or was that the old one... gfs is a network fs?
<pwnguin> the new gnome stuff is supposed to be a FUSE thing
<pwnguin> normally you shouldnt need that for a local partition...
<pwnguin> my suspicion is that deleting your large file triggered a copy
<Tyrone_man> Hmm, weird,
<pwnguin> or maybe forced some actual deletions
<Tyrone_man> Yea, I never read up its spec more than it was outside the kernel
<pwnguin> anyways, i know of a few people having performance problems in hardy with disk
<wgrant> GVFS is the GNOME-VFS replacement.
<Tyrone_man> yea, probably a copy, it went from a 200mb ram usage to 999mb in 5 secons, then in 1 minute it flooded my swap
<wgrant> GFS is a different filesystem altogether.
<pwnguin> i believe gvfs is what this topic is about ;)
<Tyrone_man> I see, that makes sense, thanks for the correction. It makes sense, I remember something from the kernel config on fs's
<wgrant> There kernel knows nothing of GVFS.
<pwnguin> well
<wgrant> But GVFS uses FUSE, which the kernel does know about.
<pwnguin> FUSE
<Tyrone_man> Ah, so FUSE is a new generic api for userspace?
<pwnguin> but a performance problem who knows
<RAOF> Well, gvfs doesn't really use fuse.
<pwnguin> FUSE aint new
<wgrant> RAOF: For non-GVFS apps it does.
<pwnguin> RAOF: waa?
<RAOF> wgrant: Right.
<RAOF> But anything using gvfs itself won't be touching fuse.
<wgrant> Hopefully.
<Tyrone_man> I see
<Tyrone_man> But FUSE is just an api, correct?
<pwnguin> that statement seems wrong but i dont know where
<RAOF> Kinda. It's also a kernel module.
<Tyrone_man> So it's a modular module api.
<Tyrone_man> ...hmm
<Tyrone_man> I see
<pwnguin> plus some processes
<RAOF> Yup.  The fuse module farms out the actual filesystem access to external processes.
<pwnguin> its sorta a microkernel approach to filesystems
<RAOF> ya
<wgrant> That's a fairly good way of putting it, pwnguin.
<Tyrone_man> I recall that implies lag from call to action
<Tyrone_man> yes?
<wgrant> Of such an incredibly small amount it's probably not noticable, but sure.
<RAOF> There's _always_ lag from call to action?
<Tyrone_man> Right, I was looking into microkerns when reading up on Hurd
<wgrant> FUSE will introduce a tiny bit more.
<lifeless> its called clock cycles :P
<wgrant> But nothing at all significant.
<RAOF> Right.  But not of a qualitatively different kind.  You'll still block on a blocking write, etc.
<pwnguin> fuse will introduce copy problems etc
<lifeless> so its a bug in pqm/bzrlib
<RAOF> pwnguin: Really?  In what way?
<pwnguin> but for stuff that isn't disk, its invaluable
<lifeless> meh echannel
<RAOF> lifeless: :)
<RAOF> pwnguin: Oh, you mean needing to copy data from userspace to kernelspace?
<pwnguin> RAOF: correct me if im wrong, but with sshfs, incoming data is written to the ssh process, then to the destination, etc
<RAOF> Dunno about the specifics.  It would of course be perfectly possible.
<pwnguin> thats the traditional microkernel argument
<pwnguin> extra copying to move data around, extra context switches
<RAOF> Right.
<Tyrone_man> extra possibilities to toast your drive??
<Tyrone_man> or, rather, your mem?
<lifeless> well
<lifeless> copying is orthogonal, thats what the MMU allows us to prevent
<pwnguin> if swap went through the roof it was an application
<pwnguin> Tyrone_man: its going to be very hard to diagnose your problem with the OS blown out of the way etc =(
<RAOF> lifeless: Mapping parts of someone else's address space to your own?
<pwnguin> right
<Tyrone_man> Hey, nothing was writting to the file, it was dead. Its done this many times, in various ways, but yea. Always when trashing it, not doing RM. Well, I still saved my /home and /root
<lifeless> RAOF: handing off data via zero-copy
<pwnguin> 0 copy messaging
<Tyrone_man> maybe a dumb question, but is the trashing function handled by a script or an actual compiled app? I never really noticed either way.
<pitti> Good morning
 * slangasek waves
 * bliZZardz smiles
 * StevenK waves to pitti 
<StevenK> pitti: Would you mind casting your gaze over bug #195260?
<ubottu> Launchpad bug 195260 in mailscanner "MailScanner won't start due to variable $FIELD_NAME" [Undecided,Fix committed] https://launchpad.net/bugs/195260
<pitti> StevenK: right, looks like v-done
<StevenK> pitti: So it gets slammed into -updates and the Hardy task closed?
<pitti> StevenK: yes
<StevenK> Cool
<StevenK> pitti: Make it so, when you have a chance :-)
<pitti> done
<StevenK> pitti: Thanks :-)
 * StevenK checks intrepid's NEW queue
 * StevenK wonders how libhildonthumbnail-dev is in testing and unstable and not intrepid
<geser> Good morning pitti
<StevenK> pitti: Could you be convinced to pull that over?
<pitti> hey geser
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back
<pitti> StevenK: weird, no idea why the autosync scripts don't pick that up
<StevenK> pitti: Me neither
<StevenK> pitti: It seems to be a perfect candidate
<pitti> E: libhildonthumbnail-dev: not found
<pitti> eh?
<StevenK> pitti: That's a binary package name
<pitti> oh, hildon-thumbnail
<pitti> https://edge.launchpad.net/ubuntu/+source/hildon-thumbnail
<StevenK> Maybe it failed to build
 * StevenK digs
<pitti> StevenK: we have a much newer version
<pitti> s/newer/greater/
<StevenK> Oh, hildon-thumbnail-dev
 * StevenK will stop being thick soon. Hopefully.
<Tyrone_man> exit
<fabbione> superm1: ping?
<pitti> hey fabbione, good morning!
<pitti> fabbione: sorry, dude, for not winning the championship this time :)
<fabbione> pitti: hey man...
<fabbione> it's ok.. Spain did play much better than Italy
<fabbione> they for sure deserve to go further more than we do :)
<superm1> fabbione, pong, but only on the condition that it's quick. i'm headed to bed in a few minutes
<fabbione> superm1: yeps. very..
<fabbione> dpkg: error processing /var/cache/apt/archives/libmyth-0.21_0.21.svn20080607-0.0_amd64.deb (--unpack): trying to overwrite `/usr/lib/libmythlivemedia-0.21.so.0.21.0', which is also in package libmyth-0.21-0
<fabbione> i know this is happening becuase i have a mixed archives
<superm1> that looks like weekly builds
<superm1> or something
<fabbione> ubuntu + debianmultimeida
<superm1> oh yuck
<superm1> why did you do that?
<pitti> \o/ different package names
<fabbione> because there are a couple of packages i need from there
<fabbione> and i am pretty sure i am not the only one
<fabbione> can we either sync package names
<fabbione> or perhaps be smart and nice to fools like me and add a C/R/P into our packages?
<superm1> well honestly anything that we "need" from debian multimedia should be pulled into ubuntu multiverse at minimum
<fabbione> i am pretty sure you can't pull everything...
<superm1> but i'll talk to marillat about syncing up to our package naming standards
<superm1> its a little nicer the way we do it
<fabbione> that would be sort of nice
<fabbione> it's really nothing urgent for me
<fabbione> let's get this straight.. just very nice to have
<superm1> well remember that d-m is not necessarily binary compatible
<superm1> so if there are packages that you need, lets try to at least get those in ubuntu?
<fabbione> right..
<fabbione> ok
<fabbione> get some sleep.. i will try to remember what i need from there :)
<fabbione> this installation is somehow X years old :)
<superm1> there is a filter in synaptic that shows you where stuff comes from
<superm1> it might be useful to you
<superm1> g'night
<fabbione> night
 * fabbione doesn't even have synaptic installed...
<persia> fabbione: apt-cache policy?
<fabbione> yeah.. no worries.. i just need to remember the packages first
<persia> Ah.  I was thinking of some pipe that fed the results of grep-dctrl on your debian-multimedia packages.gz into apt-cache policy to make you a handy list.
 * fabbione ponders a much simpler solution with apt pinning
* slangasek changed the topic of #ubuntu-devel to: frozen: Ubuntu 8.04.1 | 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
<seb128> is launchpad working correctly for other people?
<seb128> it sorts of work for me but I've to retry several times on some pages because it's being slow or something
<seb128> I don't get errors but pages just don't load
<slangasek> seems too be working for me
<seb128> hum, ok
<cody-somerville> slangasek, please accept bug #232364 as release critical.
<ubottu> Launchpad bug 232364 in xfce4-utils "dbus-launch hangs at session start waiting on socket output in libxcb" [Critical,In progress] https://launchpad.net/bugs/232364
<slangasek> cody-somerville: from what I read in scrollback over the weekend, we don't have a confirmed fix for that yet?
<cody-somerville> slangasek, I believe I have a fix so that Xubuntu logins won't freeze.
<cody-somerville> slangasek, It doesn't fix the libxcb issues, just avoids them
<cody-somerville> slangasek, I'm working very hard to get it tested and will be doing uploads today.
<slangasek> ok, I'm happy to include that if you can get it SRUed today
<slangasek> (or tomorrow, even, but today is better :)
<persia> Be nicer to fix the xcb issues.  Might also help with bug #87947
<ubottu> Launchpad bug 87947 in libxcb "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [High,Fix released] https://launchpad.net/bugs/87947
<persia> (which is broken for multiverse non-free java, so can't be fixed there)
<cody-somerville> Well, we could recompile without libxcb
<cody-somerville> but I don't think we have time for the point release
<slangasek> yeah, I haven't responded to the email thread yet, but I'm not keen on "completely change how we're building libX11" as a last-minute SRU for .1
<slangasek> to be accurate, I'm not keen on it as an SRU at all :)
<cody-somerville> slangasek, it is either that or wait 4-6 weeks for the next stable release of libxcb
<cody-somerville> Which will introduce massive changes
<cody-somerville> Massive, untested, changes
<slangasek> I'm going to go with option C
<cody-somerville> is that all of the above?
<slangasek> I don't know what it is yet, but I'm assuming it's better than the other two ;)
 * persia removes the Java considerations from any influence on SRU: that's only interesting for intrepid.
<cody-somerville> I thought Java stuff was fixed in hardy?
<persia> cody-somerville: For some JREs (the ones for which we have source).
<persia> slangasek: Is there a handy tool that generates the list of CD-inclusive packages, or is it just the union of the various seeds for the various derivatives?
<slangasek> persia: the latter
<persia> slangasek: Ah.  Thanks in advance for your difficult and patient processing of the hardy-proposed queue :)
<slangasek> heh :-)
<cody-somerville> slangasek, fyi, upstream thought disabling xcb in Hardy was the best way to go.
<mvo> BenC: removing-old-kernels looks really excellent!
<ion_> https://blueprints.launchpad.net/ubuntu/+spec/removing-old-kernels
<wgrant> Thanks ionbotu.
<ion_> (Read: âitâs not here, so URL pleaseâ)
 * mvo was reading https://wiki.ubuntu.com/KernelTeam/removing-old-kernels
<ion_> Thanks
<ion_> mvo, benc: I suggest making hardlinks instead of copying.
<persia> ion_: Can you guarantee it's the same filesystem?
<ion_> persia: do_cp() { cp -al "$@" || cp -a "$@"; }
<persia> ion_: That works :)
<wgrant> It's only copying within /boot and /lib, so it shouldn't be a problem.
<ion_> Better make sure to fall back to copying anyway.
 * persia has /boot and /lib on different partitions
<wgrant> persia: Right, but it's copying within those two, not between them.
<persia> Ah.  "within" :)
<wgrant> If you have subdirectories of both on different filesystems, you've probably got bigger problems.
<ion_> Heh
<ogra> rmbl
<ogra> did anyone here ever try to use gnome bugzilla through https  ?
<ogra> their cert seems *really* boked ... FF complains all the time with popups
<TheMuso> cjwatson: With my community hat on, I'm happy to take care of yaboot-installer if you don't have time for it, and if you are ok with me doing it.
<cjwatson> TheMuso: I think kirkland was doing it; the first time round his merge was a bit busted, but I need to look at it again
<TheMuso> cjwatson: oh ok.
 * cjwatson has another look
<cjwatson> liw: you might want to look at https://wiki.ubuntu.com/KernelTeam/removing-old-kernels too and see how it relates to your plans
<cjwatson> kirkland: how are things going with yaboot-installer, anyway?
<doko> asac, pitti: bug #211309: I don't see how the code requires the xulrunner -dev package.
<ubottu> Launchpad bug 211309 in icedtea-gcjwebplugin "[hardy] Java plugin not registered in Firefox 2" [Undecided,Confirmed] https://launchpad.net/bugs/211309
<asac> doko: do we really want to support ffox 2?
<asac> doko: how do you link? do you use pkg-config?
<doko> asac: sure, using xulrunner-1.9
<asac> doko: how?
<doko> asac: http://launchpadlibrarian.net/15062865/buildlog_ubuntu-hardy-i386.icedtea-gcjwebplugin_1.0-0ubuntu7_FULLYBUILT.txt.gz
<asac> doko: how is the MOZILLA check done?
<doko> asac: using pkg-config
<asac> how?
<asac> what .pc file is used?
<doko> PKG_CHECK_MODULES(MOZILLA, mozilla-plugin libxul-unstable, [MOZILLA_FOUND=yes], \
<doko>   [MOZILLA_FOUND=no])
<asac> doko: does it build without libxul-unstable?
<doko> asac: no, we had this discussion last year ...
<asac> cant remember
<asac> and using firefox-2-dev doesnt work either?
<doko> asac: for both firefox2 and firefox3?
<asac> doko: ah right. since its xpcom and we dont have the glue files in firefox 2, we cannot build it for both at the same time
<asac> doko: i would just invalidate that bug if i was you
<asac> otherwise we might need a SRU for firefox-2 to provide the complete sdk
<doko> hurray for sane packaging ;-p ok, will do that
<asac> doko: well. i didnt't put much work into that for obvious reasons
<asac> and iirc we already discussed that we cannot do it :)
<liw> cjwatson, yeah, that page is on my todo list
<ogra> asac, https://bugs.gnome.org/show_bug.cgi?id=359592 is there a way to avoid getting a popup about the ssl cert on *every* action ?
<ubottu> Gnome bug 359592 in general "don't use OpenGL savers if no hardware support" [Normal,Unconfirmed]
<ogra> i even get it if i switch to a differnt tab
<asac> ogra: i dont get a ssl cert popup except for the first time
<ogra> i get a sec_error_untrusted_issuer error every time i switch towards or away from the tab
<asac> ogra: ok. thats != every action :)=
 * asac tries
<asac> ogra: nope
<asac> ogra: accept cert. stop browser
<asac> maybe you never close it (as usual) and some settings need to be safed?
<ogra> http://people.ubuntu.com/~ogra/ff-ssl.png
<ogra> thats what i get in my face all the time
<ogra> and i restarted the browser etc
<asac> ogra: yeah. i see that dialog too, but just one time per session
<asac> ogra: i think its a bug, but its not as bad as you see it
<ogra_> http://people.ubuntu.com/~ogra/ff-ssl.png
<ogra_> thats what i get in my face all the time
<ogra_> and i restarted the browser etc
<asac> ogra: got that
<asac> 14:00 < asac> ogra: yeah. i see that dialog too, but just one time per session
<asac> 14:00 < asac> ogra: i think its a bug, but its not as bad as you see it
<ogra_> good, i wasnt sure
<ogra_> well, i'll switch to non https for gnome in the future ... its just so heavily in your face
<asac> I have to do something else today. remind me tomorrow and I'll try to figure figure whats going on.
<ogra_> it wont make 8.04.1 anyway, i guess we have time to look at it :)
<asac> ogra_: yeah. if it re-pops up everytime its pretty annoying i presume
<asac> ogra_: most likely not. but you never know :)
<ogra_> right, as i said no prob to switch to http instead ...
<ogra_> i rarely put confidential data in public bugtrackers anyway, no real need for https
<ogra_> :)
<ogra_> and i mean, in the end gnome should just fix their cert :)
 * asac applaudes
 * ogra scratches head about the tuxtype package ... the only diff i have are two translations there, no code or packaging diffs ... 
<mvo> ogra: then sync it :P
<ogra> well, i dont want to lose the translations (and dont want to upset translators), i guess i'll file a debian bug and attach them so holger can pull them in
<cjwatson> anyone want to take my netbase merge?
<cjwatson> oh, hey, Reinhard already caused himself to be assigned to it :-)
<ogra> is it big ? apart from ltsp i'm nearly done
<cjwatson> shouldn't be too bad
<ogra> tedg, how about xscreensaver ?
<ogra> its idling on MOM since a while :)
<mvo> ogra: yes
<mvo> ogra: I'm poking it right now
<ogra> mvo, xss ?
<mvo> should be good again
<ogra> good
<mvo> oh, sorry
<mvo> I mean mom was ideling for a day or so
<mvo> now its updated again
<ogra> ah
<siretart> cjwatson: wh00ps. I guess I need to do it then ;)
<tedg> tedg: ?
<tedg> ogra: ?
<tedg> (wow, that was funny)
<ogra> tedg, http://merges.ubuntu.com/x/xscreensaver/REPORT
<tedg> ogra: Would you sponsor it from my PPA?
<ogra> sure, got something there already ? else ping me if its ready for upload
<tedg> tedg: Yeah, it's there already.
<ogra> oh, https://launchpad.net/~tedg isnt you it seems :)
<tedg> ogra: https://edge.launchpad.net/~ted-gould/+archive
<tedg> ogra: Can one get an alias in LP?
<ogra> yup, there now
<mvo> there is a sponsoring request for xss in dholbach page too
<mvo> (just fyi)
<tedg> Yeah, I'm trying to figure out how that guy didn't have problems with the Debian and Ubuntu URL patch.
<ogra> mvo, right, but without having bene assigned to ted for a while, i am (and want to be) just the upload bitch :)
<ogra> *been
<seb128> ogra: GNOME doesn't use broken certs?
<ogra> seb128, bugzilla tells me so, see the screenshot ...
<seb128> never had a such issue and I use bugzilla daily
<ogra> seb128, with https or http ?
<Ng> it's a self-sign cert
<ogra> right
<ogra> you have to approve it first anyway
<seb128> ogra: dunno, whatever is the default
<ogra> but usually it doesnt show any further error messages ... here i get a popup every time i change tabs
<seb128> I don't think I ever got a such error messages, but I'm using epiphany-browser and not firefox
 * ogra sighs about packages using quilt in the clean target 
<cjwatson> ogra: just wanted to draw your attention to bug 242315 - sorry about the mess there
<ubottu> Launchpad bug 242315 in tuxpaint-stamps "please sync tuxpaint-stamps 2008.03.01-1 from debian unstable" [Undecided,Fix released] https://launchpad.net/bugs/242315
<ogra> cjwatson, i commented, the op fixes seem to be in debin
<ogra> *po
<ogra> *debian
<ogra> *sigh*
<MacSlow> in a package I've to merge I've in the ubuntu-variant: (= ${Source-Version}) and in the debian-variant: (= ${binary:Version})
<cjwatson> ogra: I didn't see them in the new debian/rules; were they done in the upstream source instead?
<cjwatson> MacSlow: the Debian variant is superior
<ogra> hmm, i saw them in rules, wrid
<MacSlow> cjwatson, ah ok thanks
<ogra> *weird
 * ogra checks again
<cjwatson> definitely not there
<ogra> hum
<ogra> (sorry my line is maxed out with the xss upload ... takes a min)
<MacSlow> Does each dpatch-based patch have to start with a unique ordinal number?
<cjwatson> MacSlow: (further information in the deb-substvars(5) manual page)
<cjwatson> (for Source-Version et al)
<doko> pitti: what does your comment for the bonnie++ sync mean? it's not yet synced
<cjwatson> doko: looks like the start of an abortive sync run; i.e. something went wrong with the bot
<cjwatson> doko: oh, I know. the Debian version is less than the current Ubuntu version
<cjwatson> 1.03c+nmu1 < 1.03ubuntu1 - so we can't sync, you have to invent a version number and merge. I think the nearest we have to best practice is 1.03ubuntu2, merge the changelog, and explanatory comment
<doko> argh ... yeah for a "debian native" tarball
<cjwatson> doko: looks like your merge in hardy should have been 1.03bubuntu1, not 1.03ubuntu1
<doko> cjwatson: hmm, no, it was 1.03aubuntu1
<cjwatson> doko: no, that was the gutsy merge
<cjwatson> I'm looking at the changelog right now ;-)
<cjwatson> bonnie++ (1.03ubuntu1) hardy; urgency=low
<cjwatson> bonnie++ (1.03b) unstable; urgency=low
<cjwatson> bonnie++ (1.03aubuntu1) gutsy; urgency=low
<doko> hmm, mom doesn't show this version ...
<cjwatson> mom may be confused due to Ubuntu being newer
<cjwatson> but that's what's in the archive
 * doko merges ...
<cjwatson> (cf. https://launchpad.net/ubuntu/+source/bonnie++)
<cjwatson> soren: mind if I merge console-tools?
<soren> Not at all.
<soren> In fact, I'd appreciate it if you did :)
<soren> Thanks.
<cjwatson> it's a clean merge anyhow
<asac> ogra: intrepid or hardy?
<ogra> asac, hardy
<Ng> top
<Ng> bah
 * Ng curses thinkpad trackpoints for their wandering pointer syndrome
<ion_> I have had no problems with them.
<Ng> both of mine will just wander off in a straight line for a few seconds every now and then
<Ng> which is great when you have sloppy focus and don't realise ;)
<ion_> Funny. I have never encountered that.
<Spads> I've run into it pretty often
<ogra> Ng, that only gets intresting at password input :)
<Spads> that's why I stick to the touchpad for switching focus
<Ng> ogra: I'm pretty paranoid about that, thankfully :)
<tedg> Spads: How do you have the touchpad change focus independent of the trackpointer?
<mvo> mine too
<Spads> tedg: I don't.  I just don't move the trackpointer because it will wander after
 * tedg is trying to come up with some mischief based on this new information... I need a blowgun...
<asac> ogra: give the latest nss a try from my ppa
<asac> ogra: https://edge.launchpad.net/~asac/+archive
<asac> (hardy)
<ogra> will do
<BenC> ion_: It already is making hard links :)
<ion_> benc: Alright, good.
<BenC> ion_: And the good thing is, depmod and update-initramfs unlink before updating, so there's no chance of modifying what's in last-good-boot
<ion_> benc: Wouldnât it be better to write to a temporary file and then move it over the old one instead of unlinking and then writing?
<BenC> ion_: If depmod did that, it would taint the files I've saved in last-good-boot
<BenC> So no, that would not be better
<BenC> But I assume you meant, write a tmp file, unlink and rename, which is what happens
<ion_> benc: Ah, i misunderstood.
<BenC> but the point was that with hardlinks, I had to make sure programs that modified the files I saved away didn't overwrite them
<ion_> Yeah
<dholbach> seb128: is your stock-reply script the 'newest one' or is somebody maintaining their version of it more actively?
<seb128> dholbach: mine is all but the newest one, I didn't change it since the oslo sprint
<dholbach> OK :)
<seb128> dholbach: kees wrote a nice one where you can add entries directly in the webbrowser, etc but when I tried it was not working under epiphany-browser so I stayed on my version
<dholbach> seb128: right now it's the only one I can find
<seb128> james_w: hi, will you do the gnome-system-tools merge or should I look at it?
<kirkland> TheMuso: yeah, i started yaboot-installer, but didn't finish it...  cjwatson gave me some great feedback, but I hadn't gotten a chance to pick it back up
<TheMuso> kirkland: Ok.
<james_w> seb128: hi, I started to take a look the other day, but it was a bit larger than I had time for then. I'm happy to look again if you are busy with other things.
<kirkland> TheMuso: I'll forward you cjwatson's review, if you'd like
<seb128> james_w: let's say that I'm not looking for extra work at the moment so if you want to look at it you are really welcome ;-)
<TheMuso> kirkland: If you don't have time to go through with finishing it, sure I'll have a poke, that might be useful, in case there is something I need to be aware of.
<james_w> seb128: sure, I'll get to it once I've finished my current task, hopefully today.
<mvo> doko: do you mind if I take the opensp merge?
<seb128> thanks
<seb128> james_w: there is no hurry, any time this week will be alright
<cjwatson> TheMuso: feel free to just upload once you're done
<kirkland> TheMuso: sent
<TheMuso> cjwatson: Ok, it won't e tonight now, but I'll get to it tomorrow evening. :)
<TheMuso> kirkland: Thanks.
<doko> mvo: please go ahead, working through my outstanding merges from the bottom of the list
<mvo> doko: thanks
<mvo> doko: you can remove "recode" from your list too, its a sync (I just filed a request)
<kirkland> TheMuso: hey, if you won't be offended, I'll take another crack at the yaboot-installer merge and run it by you.  That's the only merge I've attempted using bzr rather than deb, and cjwatson pointed out a few fundamental things I did wrong.
<TheMuso> kirkland: I'm easy. I don't remember seeing a bzr branch for it anywhere...
<seb128> mvo: what syncs are you looking at?
<pitti> Riddell: does KDE use PolicyKit anywhere?
<seb128> doko: you can remove scim-anthy from your list too
<mvo> seb128: I can not do syncs myself, but I just requested one for recode (not urgent at all)
<cjwatson> already processed
<mvo> woah, thanks :)
<Riddell> pitti: no :(
<pitti> Riddell: oh, hm; I'm just changing jockey to use PK
<wgrant> Package, Policy, or somethingelse, Kit?
<pitti> Riddell: however, if jockey-kde just continues to run as root, that will be transparent
<pitti> wgrant: both actually eventually, but PolicyKit for now
<pitti> I moved the backend bits into a D-BUS service
<wgrant> Right, I thought both would be applicable.
<pitti> since with the current version some bits are really awkward
<Riddell> pitti: so ideally it would use some kde policykit thing and work properly?
<pitti> re (sorry, doorbell)
<pitti> Riddell: the only thing which is really necessary is the "authentication agent"
<pitti> Riddell: i. e. the thing which presents which auth is requested and asks for your password
<pitti> Riddell: http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html has some screenshots
<pitti> Riddell: the rest is UI independent (all just D-BUS services)
<pitti> Riddell: but if the frontend continues to run as root for now, the dialog is not necessary
<pitti> since root already has all possible PK privileges implicitly
<pitti> Riddell: (policykit-kde would be a nice bounty or GSoc project, I think)
<pitti> back in 30 mins
<dholbach> bryce, soren: did you get any weird bug reports about the mouse cursor just moving in the top left 50x20 pixels in an intrepid KVM guest?
<asac> ogra: could you test?
<dholbach> it feels like the map of mouse movement is scaled from 1024x800 (or whatever it is) to 50x20 (or whatever it is)
<dholbach> it sucks :)
<soren> dholbach: Not that I've noticed. That doesn't mean they aren't there, though. I'm still way behind on LP bug mail.
<ogra> asorry had a long phonecall and some other cleanup to do afterwards, i'll test it right now, gimme a min to update
<ogra> asac, ^^^
<dholbach> soren: do you think it'd make sense to compare an intrepid xorg.log of a working guest with my broken one?
<tkamppeter> Someone here who knows about svn-buildpackage and the Perl infrastructure?
<asac> ogra: thx
<jclinton> does Ubuntu have an equivalent of the NMU process?
<jclinton> i'm Gnome Games upstream maintainer and we're drowning under duplicates generated from a bug in Ubuntu's version of python-support
<jclinton> debian's copy was patched this morning
<jclinton> hoping someone in Ubuntu can get the fix in today
<seb128> jclinton: the intrepid ubuntu version has been fixed by mvo too I think
<ogra> asac, hmm, it forgot about the cert completely now, i have to re-allow it
<dholbach> jclinton: https://wiki.ubuntu.com/SponsorshipProcess explains how to get a fix uploaded
<jclinton> seb128: the drowning is coming from hardy users
<jclinton> dholbach: i'm not an ubuntu dev
<asac> jclinton: we dont need a term for that as we are not maintainer focussed, we work in teams and its considered an exceptional procedure to upload a package you havent touched before
<ogra> asac, and the popup is gone :)
<asac> ogra: funny
<asac> ogra: can you please file a bug so we can get this "crash" fix into 8.04.1?
<seb128> jclinton: that is not going to be fixed quickly, hardy updates are frozen for 8.04.1 and it usually take a least one week for an update to be tested, etc before being actually moved to hardy-updates
<Lightkey> jclinton!
<ogra> asac, will do
 * Lightkey goes to play another round of GNOME Mines :-D
<dholbach> jclinton: right - it explains how to get a fix uploaded if you're not part of the ubuntu-dev team
<asac> ogra: let me know
<jclinton> alright, i'll just have gnome bugzilla maintainers blacklist the bug reports from ubuntu then
<seb128> jclinton: what are the upstream and ubuntu bug numbers for the issue?
<jclinton> seb128: i'll grab, a moment
<seb128> jclinton: you can still try, I doubt they will do that ;-)
<wgrant> It was a pretty impressively long bug when I saw it a few hours ago.
<seb128> well, as always when bug-buddy send duplicates
<seb128> we stop it for C program but nobody adapted the python code to do that
<jclinton> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=524665 and http://bugs.debian.org/486516
<ubottu> Gnome bug 524665 in glchess "Unable to import 'main' on startup" [Critical,Resolved: fixed]
<jclinton> seb128: we have an autoreject policy for bugbuddy
<jclinton> seb128: it's a pain to do it and its not perfered but this kind of case is why its there
<seb128> jclinton: right, I know how the GNOME bugzilla works, you can add bugs to the autoreject list
<seb128> jclinton: but the criterious is on the bug content, not the distribution
<cjwatson> is this a regression from hardy in hardy-updates?
<jclinton> seb128: right
<jclinton> cjwatson: yes
<cjwatson> how can that be? glchess and python-support are not in hardy-updates
<seb128> cjwatson: not likely, python-support didn't change there
<jclinton> cjwatson: sorry i mean to say that python-support's unstable version is in hardy
<cjwatson> although gnome-games is newer in hardy-updates
<seb128> wgrant: oh, 100 duplicates is a small count
<cjwatson> jclinton: the bug appears to have been introduced by python-support's triggers support, which is not in hardy
<ogra> asac, bug 242379 for you
<ubottu> Launchpad bug 242379 in nss "constantly shows popups with certification errors on some pages" [Undecided,New] https://launchpad.net/bugs/242379
<seb128> I doubt that's the same bug
<cjwatson> python-support | 0.7.5ubuntu1 |         hardy | source, all
<seb128> what cjwatson said
<cjwatson> if there is a regression from hardy to hardy-updates, it should be fixed regardless of the freeze
<jclinton> there are two ubuntu users there confirm that it is in hardy
<cjwatson> bear in mind that Ubuntu users may have deliberately chosen to upgrade parts of their system to intrepid but not said so
<cjwatson> the version of Ubuntu they supply in bug reports basically only confirms the version of base-files
<jclinton> hrm... and bugbuddy can't collect that information...
<seb128> the bug has been opened upstream on 2008-03-27
<seb128> so I doubt that's a regression
<seb128> and there is not an increase in the duplicates
<seb128> in the duplicates rate rather
<jclinton> so, since i'm not an ubuntu user, what does someone have to do to install glchess right now? (which should have been removed from the repos two years ago)
<jclinton> do they have to install parts of intrepid?
<seb128> jclinton: and we don't package glchess out of gnome-games
<jclinton> seb128: it was standalone before it was part of gnome-games
<wgrant> seb128: We do...
<wgrant> !info glchess hardy
<ubottu> glchess (source: glchess): 2D/3D chess interface. In component universe, is optional. Version 1.0+debian-1 (hardy), package size 191 kB, installed size 1800 kB
<stgraber> synced from debian, same version in the archive since gutsy it seems
<seb128> wgrant: we don't split the gnome-games version out I meant
<cjwatson> glchess is still in Debian unstable too
<jclinton> yea, working on that one in those channels, also
<jclinton> but in any event, it should cause the insanity with python-support even if they are both in the repos
<jclinton> shouldn't*
<seb128> glchess and gnome-games have packaging conflicts
<seb128> you can't install glchess if you have gnome-games installed
<jclinton> seb128: right
<seb128> so I doubt those users are using the glchess universe package
<jclinton> seb128: the problem is when glchess is uninstalled and gnome-games is installed in the same apt transaction
<jclinton> seb128: they are
<seb128> are you sure?
<jclinton> seb128: yes
<jclinton> i've recreated the same thing in debian unstable and have two confirmations from ubuntu hardy users
<seb128> I'm not sure why so many users would like to install glchess when it's already installed as part of gnome-games
<doko> seb128: will we demote scrollkeeper for intrepid?
<seb128> doko: likely yes
<jclinton> seb128: because our 3d is broken because of an xorg driver fuckery
<jclinton> seb128: they are almost certainly trying to get 3d to work
<seb128>   File "/usr/sbin/update-python-modules", line 125, in install_modules_func
<seb128>     raise "Trying to overwrite %s which is already provided by %s"%(os.path.join(dir,file),otherdir)
<seb128> Trying to overwrite glchess/game.py which is already provided by /usr/share/python-support/gnome-games-data
<seb128> urg
<jclinton> yep
<seb128> glchess doesn't install on hardy for me
<jclinton> you have to do it manually to go TO glchess
 * ogra hugs seb128 frantically, reading that scrollkeeper answer 
<jclinton> but doing it in reverse works
<seb128> ogra: ;-)
<seb128> jclinton: I've tried to sudo apt-get install glchess and I run into this issue
<jclinton> seb128: i'm getting exhausted defending my claim that this really is a bug in ubuntu; if you don't want to believe me i'll just resort to the blacklisting method
<seb128> jclinton: heh, calm down, I don't deny anything, I'm just trying to understand the issue
<jclinton> seb128: i am happy to provide you with any information that i have
<seb128> jclinton: you come here, say that the has to be fixed today or you will reject ubuntu bugs and point to a python-support bug which doesn't concern the hardy version
<seb128> jclinton: I can understand you are frustrated by the issue but let's try to be constructive
<jclinton> seb128: hold and i'll show you why it does
<jclinton> seb128: a moment
<siretart> cjwatson: netbase merged, ifupdown has had an "cleanup" NMU upload only, so I don't plan to work on that
<seb128> jclinton: having a testcase would be nice
<seb128> jclinton: I don't get why the standalone glchess bugs would go to bugzilla.gnome.org
<seb128> if those users are really installing the glchess package you should get no bug
<jclinton> seb128: still getting you the info but the bug happens after they install glchess and discover that its worse and decide to go back to gnome-games
<dholbach> can anybody give me their Xorg.0.log of a working KVM intrepid guest?
<seb128> jclinton: I did install glchess and gnome-games back on my hardy system and I didn't get the bug, maybe there is some extra steps required ...
<jclinton> seb128: so perhaps these people really do have parts of intrepid installed?
<seb128> no
<seb128> the bugzilla bug has been opened before hardy
<seb128> and there is most like a python-support issue somewhere, but not sure how to trigger it
<jclinton> seb128: the first half of the bug was our own stupidity
<seb128> ah
<jclinton> seb128: that was fixed in ubuntu's upload of 2.22.2.1
<seb128> looking at some recents duplicates now
<jclinton> seb128: i /think/ this is the root cause: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446730
<ubottu> Debian bug 446730 in bittornado "bittornado: fails to start: ImportError: No module named BitTornado" [Grave,Closed]
<jclinton> seb128: the 'fix' was uploaded to debian in 0.7.5
<jclinton> seb128: which may or may not be part of the ubuntu version
<seb128> hardy has 0.7.5 yes
<jclinton> seb128: either way the fix points to a more fundamental problem with python module overwrites
<seb128> ok, I managed to get the bug
<seb128> that's a corner case
<jclinton> for my own edification, what did you have to do?
<seb128> have gnome-games installed
<seb128> sudo apt-get install glchess
<seb128> there is a file conflict between this one and gnome-games-data but gnome-games-data doesn't get remove because the packaging conflict is only on gnome-games
<seb128> so you are in a broken installation state
<jclinton> seb128: ah; someone doing this via synaptic would have no idea?
<seb128> on the first try I remove gnome-games-data to have the packaging system in a consitant state
<seb128> and reinstalled gnome-games
<seb128> if you reinstall gnome-games directly you are screwed
<seb128> right
<jclinton> seb128: ok i can file a bug against gnome-games in launchpad for the conflict
<seb128> or they would get an installation error but can revert to gnome-games
<seb128> jclinton: would be nice, I'll do a sru adding the conflict
 * mvo hugs seb128 for finding this error
<jclinton> seb128: but really glchess should not be in the repos
<seb128> sru = stable update
<jclinton> ok awesome
<seb128> jclinton: well, it's there because some people might want it and not the whole gnome-games, it's coming from debian
<seb128> you can try to convince them they should not have it
<seb128> but everybody is not a GNOME user ;-)
<jclinton> seb128: looks like theres already a few dups of this in your LP
<jclinton> seb128: i'll get you the oldest
<seb128> jclinton: thanks
<jclinton> seb128: https://bugs.launchpad.net/ubuntu/+source/glchess/+bug/138509
<ubottu> Launchpad bug 138509 in glchess "package glchess None [modified: /var/lib/dpkg/info/glchess.list] failed to install/upgrade: trying to overwrite `/usr/share/applications/glchess.desktop', which is also in package gnome-games" [Low,Confirmed]
<jclinton> seb128: i see 6 other dups; i'll marks then as such
<seb128> jclinton: this one is fixed in fact
<seb128> jclinton: gnome-games Conflicts on glchess
<seb128> the issue is gnome-games-data now
<seb128> (the .desktop are in gnome-games)
<jclinton> seb128: but glchess should conflict with gnome-games-data dont we agree?
<seb128> jclinton: yes
<seb128> jclinton: in fact I'll change gnome-games-data rather
<seb128> to make it conflict on glchess
<jclinton> seb128: ok
<MacSlow> I've a merge-related question...
<seb128> jclinton: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-games/+bug/234865
<ubottu> Launchpad bug 234865 in gnome-games "Package glchess fails to install and ask removal of gnome-games" [Unknown,Confirmed]
<seb128> jclinton: I'll use this bug
<MacSlow> in the REPORT for planner files debian/control and debian/control.in are marked to need work
<MacSlow> but <something>.in is the template from  which <something> is generated
<seb128> MacSlow: control is autogenerated when doing clean
<ogra> usually
<MacSlow> do I really have to touch both?
<jclinton> seb128: ok
<seb128> MacSlow: no, just the control.in
<ogra> MacSlow, i usualy only change .in
<MacSlow> seb128, ok... just needed assurance
<ogra> but do a testbuild to confirnm its really used
 * ogra had packages with ,in files that werent in the past
<seb128> jclinton: thanks for your help on the issue, the fix will be uploaded today
<MacSlow> ogra, I've a pbuilder environment setup by now and tend to use that before I "upload" (read: ask you folks for sponsorship)
<jclinton> seb128: and thank you as well, especially for your patience
<jclinton> seb128: much appreciated
<seb128> always happy to work with upstream and fix issues ;-)
<seb128> doko: ups, I synced scim-hangul a bit quickly, there was still an ubuntu change, you might want to do the merge still ;-) (or I'll fix it later but I've to go for sport soon)
<doko> seb128: I did ask ArneGoet1e to merge the scim-* packages, I'm not doing those today
<seb128> doko: ok, thanks
<seb128> ArneGoet1e: ^
<ogra> Keybuk, do i understand right that 70-persistent-net.rules replaces iftab nowadays ?
<ogra> (i have an edubuntu user where the devices seem to flip around on every boot)
<ion_> ogra: AFAIK yes.
<zul> jcastro: ping
<jcastro> zul: pong
<zul> jcastro: can you register bugs.mysql.com into launchpad?
<jcastro> zul: certainly
<zul> jcastro: thank you
 * ogra thoguht they switched to LP
<ogra> why didnt they switch the bugtracker as well ?
<jcastro> hmm, what kind of bugtracker is it?
<zul> jcastro: its based on the php.net one
<jcastro> does lp support it?
<zul> I dunno :)
<jcastro> https://bugs.edge.launchpad.net/malone/+bug/74449
<ubottu> Launchpad bug 74449 in malone "Add support for MySql and PHP bugtracker." [Medium,In progress]
<zul> merci buckets
<Tyrone_man> Hey everyone, just checking in to let you know that virtual machine install from yesterdays alt-i386 iso was a no go. Missing the generic restricted kernel package
<kirkland> soren: one other weakness in the regexes is that they both require that the path is double-quoted
<kirkland> soren: is that a big deal to you?
<soren> kirkland: Only a bit.
<kirkland> soren: this works better: echo PATH=\"~/bin:blah\" | grep "^PATH=.*[:\"]~/bin[:\"]"
<kirkland> soren: well, see the regex at the end of that cut-n-pastable test
<kirkland> soren: actually, I could strip the quotes out with a first sed
<kirkland> soren: and put them back in with a second one
<kirkland> soren: hmm, but i don't like that...  makes the sed -i inline bit wierd
<kirkland> soren: so are you still in favor of prepending, or are you comfortable with appending in both new installs and upgrades?
<soren> "^PATH="?(~/bin|.*:~/bin)[:$\"]\"?" perhaps?
<soren> kirkland: Well, I would have said prepend, but Jamie has a good point in the ~/bin/ls attack. It's a long shot, but that's the case for most vulnerabilities.
<kirkland> soren: right
<jdstrand> not to mention, people can use 'alias' if the want to override a system command
<kirkland> soren: ~/bin/ls was my reasoning for the safe/conservative approach
<soren> Hehh.
<soren> Although, .bashrc prepends it.
<slangasek> I think it's fairly typical to want to prepend
<jdstrand> hmm, I don't like it
<slangasek> having the system directories listed first to prevent a command being overridden doesn't buy you any security - who has write access to your ~/bin directory that doesn't also have write access to your .bashrc
<jdstrand> but I setup my PATH on my own, and wasn't aware that there was precedent for prepending
<slangasek> ?
<sbeattie> even without security considerations, if you have buggy scripts that don't fully list pathnames, you can get weird errors due to name collisions with scripts in ~/bin/
<slangasek> true, but that's a "so don't write buggy scripts then" :)
<sbeattie> Uh, yeah, "don't write buggy software" is working so well for our underworked security team. :-)
<slangasek> hey, the security team doesn't have to support anything users put in ~/bin >:)
<jdstrand> heh
<jdstrand> slangasek: while technically you are correct regarding writable .bashrc vs prepended ~/bin, I think certain attacks may find ~/bin more interesting or easier to implement than .bashrc edits, but that gets us into an even less likely scenario
<jdstrand> slangasek: not to mention that .bashrc already does it, so if we don't in /etc/environment, that is inconsistent
<kees> .bashrc already does it?
<sbeattie> slangasek: sure, but you can waste a lot of time figuring out that something is broken due to that issue, even if in the end you get to say "not my problem". Not that I'm speaking from experience here.
<jdstrand> kees: soren said yes
<jdstrand> I'm looking into it
<kees> jdstrand: where?
<kees> or rather
<kees> soren: where does ~/bin go into bashrc on a default system?
<kees> I don't see it in /etc/skell or /etc/bash.bashrc
<jdstrand> kees: .profile
<jdstrand> ./.profile:    PATH="$HOME/bin:$PATH"
<jdstrand> that's in /etc/skel
<kees> yeowza
<kees> kirkaldn actually... would that work better than ~ ($HOME)
<kees> hm
<kees> kirkland: ^^ (I can't type)
<kees> yay I have my ~bin in two places in my path.
<sbeattie> kees: since you're underemployed, do you think someday /etc/skel/ could contain tmp/ ?
<kirkland> kees: hmm, i ran into a couple of issues in my testing, when using $HOME/bin in /etc/environment
<sbeattie> kees: hah! I have /opt/wabi/bin in my path, I haven't used wabi in a good 10 years.
<kees> sbeattie: afaik, it's been a xdg (or maybe just fedora?) plan to have per-user tmp dirs
<soren> kirkland: Sorry, I have a few things around the house I need to handle....
<jdstrand> heh-- apparently I noticed this at some point-- I commented it out of my ~/.profile
<kirkland> soren: okay, i couldn't get your suggested regex to work correctly
 * kees holds his head
<kees> argh path
<kees> this is pretty goofy
<kees> should we _remove_ the .profile prepending?  This really smells like it needs a full spec
<kirkland> sorry to stir up another pooh storm :-)
<jdstrand> well, I certainly am n favor of it
<kirkland> automatically prepending ~/bin seems all around dangerous
<kirkland> willing and knowledgable users can certainly do so
<kirkland> but if we're going to set this up automatically for users (as I am in favor of), I'd think appending would be the safest way to go
<slangasek> I believe the difference between safest and unsafest here is trivial
<slangasek> whereas the difference in convenience may be substantial
<jdstrand> honestly, from a usability point of view, I think that we must be consistent
<kirkland> jdstrand: what does that mean?
<jdstrand> it looks like it happened way back in 2.04-6 or so
<jdstrand> kirkland: it means we should be consistent with .profile, otherwise the patch doesn't work right (ie you still don't get the same environment you are striving for)
<kirkland> jdstrand: okay
<jdstrand> debian bug #67714 references it as recently changing
<ubottu> Debian bug 67714 in bash "/etc/skel/.bash_profile: the ~/bin setup of PATH is not ok." [Wishlist,Closed] http://bugs.debian.org/67714
<jdstrand> that was back in 2000 :)
<jdstrand> perhaps that is when I noticed it, and changed it in my own .profile ;)
<jdstrand> hey, that was on the beloved woody
<kirkland> jdstrand: i agree with your comment for consistency
<kirkland> jdstrand: at least between ~/.profile and /etc/environment
 * jdstrand nods
<slangasek> superm1: preliminary mythbuntu CDs are available for 8.04.1 at http://cdimage.ubuntu.com/mythbuntu/hardy/current/, if you would care to give them a smoke test
<mario_limonciell> laga, ^ if you've got a few cycles.  otherwise i'll give a run tonight or tomorrow night
<kirkland> slangasek: mario_limonciell: I have a new mythbuntu box to install... i'll give them a go too....
<laga> mario_limonciell: ugh, not tonight, sorry
<mario_limonciell> laga, did you update the kernel version in the base seeds?
<mario_limonciell> laga, or have you lately?
<laga> no
<kirkland> slangasek: your url wasn't quite right.... http://cdimage.ubuntu.com/mythbuntu/hardy/daily/current/
<mario_limonciell> then most definitely those are broke right now
<mario_limonciell> laga, could you commit a fix to the branch for that?
<laga> i haven't been doing stuff on the alternate disks since the release. which is a shame.
<laga> ya, will do.
 * laga hangs his head in shame
<slangasek> kirkland: ah yes, sorry
<slangasek> I should delegate all URL composition to my browser :)
<mario_limonciell> and then kirkland pull tomorrow's disk if you can
<mario_limonciell> laga, do you know if Daviey has rolled the new live's yet on hardy?
<slangasek> tomorrow's disk?
<mario_limonciell> slangasek, they're not dailieis?
<kirkland> mario_limonciell: ah, okay
<laga> mario_limonciell: -19 is the current kernel, right?
<mario_limonciell> yeah
<laga> mario_limonciell: no clue about daviey
 * kirkland cancels his current download at 40%
<slangasek> mario_limonciell: they're not being built on a daily basis, no
<mario_limonciell> slangasek, oh.  well after laga commits the change for the kernel bump, can you queue up one more?
<slangasek> mario_limonciell: sure
<mario_limonciell> thanks
<kirkland> mario_limonciell: ping/remind me when new iso's go up and i'll test them out
<mario_limonciell> okay great.  Thanks!
<laga> mario_limonciell, slangasek: okay, i've just pushed rev 1183
<laga> i think you need to merge it?
 * slangasek watches gvfsd-smb-browse suddenly decide not to do Kerberos authentication, and pulls out his hair
<slangasek> laga: pushed it to where, please?
<Daviey> !test
<ubottu> Failed!
<laga> slangasek: heh, sorry! http://bazaar.launchpad.net/%7Emythbuntu/ubuntu-seeds/platform.hardy/
<slangasek> laga: hrm?  what needs to be changed in platform?
<slangasek> well, I guess I'll see if I try to merge it :)
<laga> slangasek: ah. i guess now comes the part mario_limonciell warned me about.
<kirkland> slangasek: jdstrand: soren: kees: so is the consensus then to have the libpam-modules.postinst script *prepend* ~/bin, in order to be consistent with ~/.profile?  And, at the point in which we decide *appending* is better, we'll change both at the same time?
<laga> slangasek: we have our own platform.hardy.
<laga> slangasek: because we need a different set of packages. or something like that.
<jdstrand> kirkland: unfortunately, I think we need to do that for consistency, unless we are prepared to change bash now
<slangasek> laga: ummm.  that defeats the purpose of the "platform" seed
<kees> I would prefer to start with it correct (appended).
<jdstrand> I'd rather change both
<slangasek> which is to have a common seed for shared components
<mario_limonciell> a problem came up that the platform seed wasn't working when updating the metas
<mario_limonciell> and there were extra components in it that weren't desirable afaik
<laga> slangasek: yes. i'll let mario_limonciell explain it. he also warned me that you were going to yell at me  ;)
<mario_limonciell> haha
<slangasek> mario_limonciell: is something already implemented to make the CD building scripts look at this platform seed?
<Daviey> and it was leaving crap behind, wasn't it?
<jdstrand> kees: that defeats the purpose of kirkland's patch though
<mario_limonciell> somehow it gets pulled correctly during build yes slangasek
<jdstrand> kees: the problem is ultimately that the enviroments are different-- granted, appending gets it closer, but not the same
<mario_limonciell> Daviey, i dont know that it was leaving stuff behind, but a lot of extra stuff got pulled in via it
<slangasek> mario_limonciell: because AFAICS, the right way to do this would be to keep a single mythbuntu.$dist repo and just have it not inherit from the platform seeds <shrug>
<mario_limonciell> yeah i agree
<mario_limonciell> someone had suggested to adopt the platform seed since everyone else was doing it
<slangasek> mario_limonciell, laga: anyway, if debian-cd is already looking at this seed, then I shouldn't need to do anything wrt merging
<mario_limonciell> and then things started to break
<laga> so no merging needs to be done.
<jdstrand> kees: I'd like to change bash *and* append in pam
<laga> yeah, sorry for the confusion
<Daviey> mario_limonciell: ahh, didn't we try and remove the extra stuff or something.. and that was the problem. Geez it was so long ago, i can barely remember
<kees> jdstrand: I think that's good
 * laga hands out cookies to anyone involved
<jdstrand> kees: which is good?
<sbeattie> jdstrand: I concur with changing both to append, despite my below zero influence in this matter.
<kirkland> jdstrand: kees: okay, so i'll need to form two patches....
<jdstrand> sbeattie:
<jdstrand>  5
<jdstrand> o/
<kees> :)
<kirkland> jdstrand: kees: an updated one for pam, that APPENDS ~/bin in both the "new install" and "update" case (with the exceptions that soren mentioned)
<kirkland> jdstrand: kees: plus a patch to bash that creates a .profile wthat APPENDS ~/bin
<jdstrand> kirkland: that is a hearty +1
<kees> yeah, sounds right.
<jdstrand> I *might* even go 1.5
 * kirkland is ready to put this issue to bed and get back to ecryptfs :-)
<jdstrand> heh
<jdstrand> it always nice getting *everyone* to weigh in on a 4 line patch
<jdstrand> it's
 * kees mutters about 1 line patches
<kirkland> jdstrand: kees: does this need a new LP bug, or shall I continue to use 64064 ?
<jdstrand> kirkland: bash needs a new bug
<kirkland> jdstrand: okey doke, doing that now
<kirkland> kees: one more question...  I see the one-line to be changed in skel.profile ... but again are we concerned about "fixing" this for upgrading users?
<jdstrand> kirkland: while you didn't ask me, sed'ing user's .profiles makes me feel a little nauseated
<jdstrand> just a little
<kirkland> jdstrand: agreed!
<jdstrand> kirkland: though it is a good question :)
<kirkland> jdstrand: sorry for not addressing you on that one :-)  no offense
<kirkland> kees raised it last time
<jdstrand> kirkland: none taken
<kees> kirkland: er, well, we shouldn't change users's .profiles, but we should deal with /etc/skel/profile in a fashion similar to the pam patch
 * jdstrand may have misinterpreted kirkland's question based on kees' response
<kees> I saw a few questions, so maybe I'm confused too
<kirkland> kees: jdstrand: i think i understand....
<kirkland> kees: jdstrand: don't "fix" user's .profiles (I wasn't planning on) ... but do "fix" /etc/skel/profile (which was my question)
 * jdstrand feels considerably less nauseated now
<kees> right, good.  heh
<emgent> congrats ember
<emgent> welcome in ubuntu family.
<ember> thanks emgent
<slangasek> mario_limonciell, laga: new mythbuntu hardy image up
<laga> great! kirkland ^^
<kirkland> laga: sweet!
<mario_limonciell> that was fast
<kirkland> no kidding, mario_limonciell
<slangasek> well, hopefully I wasn't too fast for seed propagation ;)
<mario_limonciell> according to http://cdimages.ubuntu.com/mythbuntu/hardy/daily/20080623.2/hardy-alternate-i386.list looks good to me
<mario_limonciell> er why did that show up in bold?
<laga> didnt do that here
<Caesar> Is there a known issue with the Hardy alternative installer?
<Caesar> We're seeing problems downloading installer components
<slangasek> the alternate installer should not normally need to download any installer components, it should be self-contained on the CD?
<Caesar> PXE boot man
<slangasek> ah
<Caesar> Today it's complaining about apt-mirror-setup
<Caesar> On Friday it was a different udeb
<Caesar> We updated the installer today, because I saw someone had respun it
<slangasek> apt-mirror-setup has a newer version in hardy-updates; could be a mirror sync issue of some kind?
<Caesar> Could be
<Caesar> On Friday it was kickseed-common
<kirkland> kees: jdstrand: http://pastebin.ubuntu.com/22434/
 * kirkland notes that the grep/sed regex is very tight, will only match if the sysadmin has not modified the default value of PATH in /etc/skel/.profile ...  kirkland calls this a "feature".
<Tyrone_man> Sorry for interupting, I just tried today's iso for alt-i386, linux-generic doesn't work still, only the specific 2.6.26 kern entry, due to lack of restricted modules, and then pkgselect will not initiate. I can get a booting root shell, but as of yet, no applications
<jdstrand> kirkland: so you are only changing it on upgrade if the path is $HOME/bin:$PATH. I like it
<jdstrand> kirkland: should the compared bash version be 3.2-0ubuntu18?
<jdstrand> dpkg --compare-versions "$2" le 3.2-0ubuntu19
<jdstrand> +bash (3.2-0ubuntu19) intrepid; urgency=low
<jdstrand> kirkland: or use lt-- I like lt better personally
<kirkland> jdstrand: good catch, agreed on lt
<Caesar> Is there a way to get more information out of anna about why a udeb retrieval failed?
<Caesar> "Loading apt-mirror-setup failed for unknown reasons. Aborting" doesn't really tell you much...
<jdstrand> kirkland: stylistic point-- I generally like to separate out the files modified. I think it makes it slightly more clear
<jdstrand> kirkland: eg:
<kirkland> jdstrand: sure, in the changelog, okay
<slangasek> Caesar: I think there should be more information in the logs, which are normally on ttys 3 and 4?
<jdstrand> debian/skel.profile: put $HOME/bin at end of path
<jdstrand> debian/bash.postinst: <something fairly specific>
<jdstrand> kirkland: not that you need to change it now-- but maybe it makes sense to you. I think it makes it easier when merging
<Caesar> slangasek: negative
<Caesar> It just mentions it's queuing it for download
<Caesar> It's quite unhelpful
<kirkland> jdstrand: sure... i'll rev another one right now
<jdstrand> kirkland: note, when outside of debian/, it is often not required, but in debian/, I think it makes it easier
<kirkland> jdstrand: would I mention the (LP: #242479) on both, one, neither?  the first or the second?
<kirkland> jdstrand: obviously not "neither" :-P
<jdstrand> kirkland: what is the original bug again?
<jdstrand> kirkland: (the pam one)
<kirkland> jdstrand: https://bugs.edge.launchpad.net/ubuntu/+source/pam/+bug/64064
<ubottu> Launchpad bug 64064 in pam "would be nice to add ~/bin to the default PATH" [Wishlist,Fix released]
<jdstrand> kirkland: yeah, just the bash one
<kirkland> jdstrand: sorry, my question is whether I put it on both lines?  now that there is one for each file I touched?
<jdstrand> kirkland: oh, can do:
<jdstrand> * References
<jdstrand>   LP: #NNNNNN
<jdstrand> kirkland: in this case, it's clear cause it's just the one
<jdstrand> kirkland: othertimes you can do:
<jdstrand> just on the first one
<jdstrand> first listed
<jdstrand> kirkland: it isn't a hard and fast rule, mind you :)
<kirkland> jdstrand: patch updated: http://pastebin.ubuntu.com/22436/
<kirkland> jdstrand: if that's good, i'll attach to the bug and perhaps you can sponsor
<jdstrand> kirkland: sure no problem
<jdstrand> kirkland: I like the text, it's very clear
<kirkland> jdstrand: patch attached to https://bugs.edge.launchpad.net/ubuntu/+source/bash/+bug/242479
<ubottu> Launchpad bug 242479 in bash "~/.profile should append, rather than prepend $HOME/bin" [Low,In progress]
<kirkland> jdstrand: I'll subscribe you
 * jdstrand nods
<cjwatson> Caesar: you have to use the installer image in hardy-updates
<cjwatson> Caesar: the one in dists/hardy became bust once stuff started to be duplicated in hardy-security/updates
<kirkland> cjwatson: hey, good news... i floated your idea of a "root_squash" to mhalcrow (kernel ecryptfs maintainer) and he's working on a patch, says it's relatively trivial
<cjwatson> ok, great
<kirkland> cjwatson: jdstrand and I talked about something similar this weekend
<cjwatson> bad news is I hate your ~/bin munging
<cjwatson> it's totally pointless and a waste of effort, no security relevant
<cjwatson> relevance
<cjwatson> just leave it the way it is, it's just fine!
<cjwatson> Tyrone_man: I processed the relevant linux-restricted-modules binaries this morning, so tomorrow's should be better, thanks
<kirkland> cjwatson: at this point, tis mainly a consistency-thing...  i have a separate patch for /etc/environment in PAM
<kirkland> cjwatson: there seems to be some back/and/forth about whether we prepend or append
<cjwatson> consistency with what we've done so far is far more important
<kirkland> cjwatson: i think we all agreed that it should be the same in both /etc/skel/.profile and /etc/environment (wrt to prepending/appending)
<cjwatson> people hate distros changing defaults back and forward on this kind of thing
<cjwatson> I agree that it should be the same in different login modes, yes
<kirkland> kees and jdstrand both leaned toward appending in both cases
<cjwatson> I think the security arguments are completely specious
<kees> for note, my opinion was based on utility, not security.  it seemed like a bad idea to override system tools with things in ~/bin, but I'm sure that's a matter of opinion.  :)
<cjwatson> the situation this will break is as follows:
<kirkland> i thought it was something a user should do "consciously"
<kirkland> (ie, override system tools)
<cjwatson> user has been maintaining ~/bin for years across a variety of Ubuntu installations
<cjwatson> user installs a new Ubuntu system, and copies over their ~/bin like they always did
<cjwatson> some time later, user notices that some random script doesn't work, and gets horribly confused
<kees> okay.  so, in the case of the /etc/environment change, it should also prepend?
<cjwatson> it may well have been a conscious decision at some point, but now we're requiring them to make it again, long after they've forgotten making it
<cjwatson> it should be a consistent rule across the system that user customisations override the system by default
<cjwatson> and that we don't mess around with user customisations
<cjwatson> sorry to be blunt, and I know I'm coming late to this, but I feel quite strongly about the general principle
<Caesar> cjwatson: that's just awesome
<Caesar> Thanks
<seb128> slangasek: hey, could you consider the gnome-games upload I just did for 8.04.1? It adds a gnome-games-data conflicts on glchess, the non conflict leads to a broken gnome-games installation and upstream seems to get quite some duplicates from users running into the issue
<kirkland> cjwatson: kees: okay, i can drop the bash patch, and mark "invalid" ....  but the pam /etc/environment should probably prepend ~/bin to be consistent.  would this be acceptable?
<jdstrand> cjwatson: I take your point about user customizations. I did mention that the risk was low, but I don't think it's completely specious
<pwnguin> seb128: on a related note, is it really a good idea to have bug reports go directly to upstream?
<jdstrand> cjwatson: I am not arguing against you for leaving it as is either
<seb128> pwnguin: if the issue is an upstream one, yes
<cjwatson> jdstrand: ok, we may have to agree to disagree on that (low vs. specious) :-)
<jdstrand> cjwatson: I can accept that :)
<kirkland> jdstrand: are you willing to concede the point, and are we back to prepending?
<cjwatson> I think that road leads to things like writing C code where scripts would be more appropriate because otherwise it's easier to modify the code
<seb128> pwnguin: we often just forward the bug and act as a gateway between bug trackers, which is not really efficient, if you are able to open the bug upstream directly that's better
<cjwatson> kirkland: /etc/environment makes sense if $HOME expansion is possible there and if PAM clients actually handle that properly (i.e. have set $HOME when they run pam_env)
<pwnguin> seb128: that has to generate some amount of friction in the cases where its not an upstream problem
<seb128> if the bug is something we should consider for the current ubuntu version you might want to open the bug in launchpad too and add a watch on the upstream bug
<jdstrand> kirkland: to me, cjwatson's point outweighs the risk, and I'm glad he weighed in
<seb128> pwnguin: well, I said "if the issue is an upstream one"
<pwnguin> seb128: as far as i know, none of our tools can place blame correctly ;)
<seb128> ?
<seb128> none of the tool open bugs automatically either
<kirkland> cjwatson: i have tested extensively....  all of the major window managers (Gnome, KDE, XFCE) handle it properly, and the Bourne-compatible shells do (bash, ash, dash, ksh)
<seb128> you always have an user confirming the action
<seb128> pwnguin: I'm not sure to get the question now
<cjwatson> kirkland: well, the shells don't deal with /etc/environment, normally
<pwnguin> when glchess crashes, a bug-buddy window opens up
<cjwatson> I was thinking more login, sshd, etc.
<kirkland> cjwatson: and to be precisely, "~/bin" works with more shells than "$HOME/bin" does, and so my pam patches have used "~/bin"
<seb128> pwnguin: if you know the issue is an upstream one you can open it directly in their bug tracker, if you don't know open it in launchpad and we will do the work for you
<seb128> pwnguin: that's bug #88227, patches are welcome
<ubottu> Launchpad bug 88227 in gnome-python "should not run when apport is used" [Low,Confirmed] https://launchpad.net/bugs/88227
<cjwatson> kirkland: hmm, so you're saying that literally '~/bin' ends up in getenv("PATH")? That sounds a bit sketchy - doesn't the libc need to support that in order for that to be reliable?
<kirkland> cjwatson: right, so I've tried login, ssh, and gdm/kdm
<cjwatson> kirkland: I was thinking it would be much more appropriate to actually expand $HOME in getenv("PATH")
<cjwatson> it should be /home/cjwatson/bin:... not ~/bin:...
<seb128> pwnguin: we disable bug-buddy for crashers
<seb128> pwnguin: there is just not so many programs using gnome-python and bug-buddy integration and nobody did the work to disable that code when apport is used yet
<kirkland> cjwatson: yes, if ~/bin is in PATH in /etc/environment, then yes, ~/bin ends up in getenv("PATH").  same goes for $HOME/bin.
<kirkland> cjwatson: it seemed to me that the bourne-compatible shells eval $PATH, and other shells do not
<cjwatson> kirkland: if ~/bin is in getenv("PATH"), execlp does not wok
<cjwatson> work
<cjwatson> it has to actually be expanded to work reliably
<cjwatson> shells might get this right, but other programs that use execvp or execlp directly will fail
<cjwatson> kirkland: demonstration: http://paste.ubuntu.com/22449/
<kirkland> cjwatson: okay, so in the bug i was originally fixing, a user wants to hit "alt-f2" in Ubuntu/Gnome, and type "ff"--their firefox wrapper they put in /home/user/bin/ff and it just "work"
<cjwatson> kirkland: this may need to be fixed by having pam_env expand something in /etc/environment
<cjwatson> rather than just using the value verbatim
<cjwatson> kirkland: try ${HOME}/bin:...
<kirkland> cjwatson: k
<cjwatson> /usr/share/doc/libpam-doc/html/sag-pam_env.html documents that as the proper method
<cjwatson> however, that may only work in pam_env.conf
<kirkland> cjwatson: no difference if I put ${HOME}/bin in /etc/environment
<cjwatson> worth a try, though, and would seem like the best thing to support if a PAM extension is needed
<pwnguin> seb128: thanks for the explaination. I wondered why they were going immediately to GNOME, now it makes more sense
<cjwatson> OK, I think that you need to extend pam_env to expand that, then
<cjwatson> I absolutely agree this ought to be fixed, but we can't rely on shell expansion
<seb128> pwnguin: writting the patch to not use bug-buddy there should not be too hard, it's somewhat on my todo list
<seb128> pwnguin: you are welcome to work on it if you want though ;-)
<pwnguin> at the moment I don't know enough python to make it happen any time soon
<kirkland> cjwatson: the expansion needs to be in pam_env, then?
<cjwatson> yeah, the PATH environment variable must be expanded
<cjwatson> pre-expanded I mean
<kirkland> cjwatson: is that the only variable i should worry about expanding?
<kirkland> cjwatson: or should it be a full eval?
<kirkland> cjwatson: sorry, I meant $HOME
<cjwatson> the semantics of environment variables depends on what uses them
<cjwatson> but I think it would be generally appropriate to apply ${...} expansion to everything in /etc/environment, even though it's technically a behaviour change; however slangasek should have a say there
<cjwatson> it would definitely be confusing to expand PATH but not others
<kirkland> cjwatson: okay, i've marked 242479 invalid.
<cjwatson> thanks
<kirkland> cjwatson: i'm looking at pam_env.c to see how painful env variable expansion will be
<kirkland> cjwatson: this patch http://halcrow.us/~mhalcrow/patches/ecryptfs-excl-access-20080623.txt (untested) would allow a mount-time option, ecryptfs_exclusive_access_uid=1000, that the kernel would respect by not serving read/write requests to any other uid (even root).
<cjwatson> sounds reasonable
<slangasek> seb128: gnome-games> glchess is in universe; SRU yes, 8.04.1 no, sorry
<slangasek> kirkland, cjwatson: if we're going to start expanding variables in /etc/environment (which I agree is the right way to do it), we should be consistent about it rather than special-casing $HOME
<kirkland> slangasek: yessir...
<kirkland> slangasek: i'm still digging into the problem...  looking at pam_env.c, the code does try to expand env variables
<kirkland> slangasek: but it's not doing so on /etc/environment
<slangasek> kirkland: right, the variable expansion is only done on pam_env.conf; I don't know why this is
<slangasek> if possible, please run any patches you come up with past upstream, since we'll want to avoid diverging here and my pam patch load is already up to my chin
<kirkland> slangasek: okay, i'm not going to spend much more time on this....
<slangasek> ok
<kirkland> slangasek: this was a 5-minute fix that I've devoted > 2 days on now :-/
<slangasek> oh, I could've told you it wasn't a 5-minute fix from the beginning... :)
<slangasek> wait, that didn't get tagged bitesize, did it?
<kirkland> slangasek: "Nothing to see here, move along, move along..."  :-)
<kirkland> slangasek: yes, it was
<slangasek> yah, madness
<kirkland> slangasek: I removed the tag after about hour 6
<slangasek> good, thanks :)
 * jdstrand is back for just a moment
<jdstrand> cjwatson: here is why I believe it's low, rather than specious-- group or other writable ~/bin
<jdstrand> I happen to have access to one of those, on a machine where I am not the admin, and didn't setup that directory
<jdstrand> plus, I just reviewed a perl vuln that accidentally followed symlinks and made things 777
<jdstrand> so, obviousy, there is an amount of trust in group writable, but accidents happen
<jdstrand> anyhoo, I'm off again
<kirkland> cjwatson: slangasek: argh....  # Note that many environment variables that you would like to use
<kirkland> # may not be set by the time the module is called.
<kirkland> # For example, HOME is used below several times, but
<kirkland> # many PAM applications don't make it available by the time you need it.
<kirkland> slangasek: that's exactly what I'm seeing with login and /etc/security/pam_env.conf
<slangasek> right, that's a potential concern
<kirkland> slangasek: cjwatson: Okay, then I don't even think this is solvable with pam_env, sadly.
<slangasek> well, it's less of an issue for login because login spawns a shell which reads .profile, surely?
<slangasek> the problematic use case is gdm which runs lots of things that aren't under a login shell
<kirkland> slangasek: right.  well, the simple, non-expanded ~/bin in /etc/environment works well in my simple tests worked well with Gnome/KDE/XFCE, as for allowing for running scripts in ~/bin
<slangasek> hrm, I'm not sure how it manages to do that given cjwatson's counterexample
<kirkland> slangasek: cjwatson has a test c program in a pastebin above where he shows, however, that a non-expanded PATH is not good for c programs
<kirkland> slangasek: my test consisted of "alt-f2"
<kirkland>  slangasek: which was the user issue described in the original bug
<slangasek> right
<slangasek> I wonder why that works :)
#ubuntu-devel 2008-06-24
<cjwatson> Alt-F2 probably runs things through a shell so that you can do pipes and suchlike
<cjwatson> jdstrand: ack, though I'm sure there must be cases where that goes along with other ability to insert shell configuration; being able to set aliases is just as good
<kirkland> slangasek: wrt to your point about .profile, we could easily add a line to: eval PATH="$PATH"
<Tyrone_man> *sigh*, can anyone get this kernel to boot up? Ubuntu keeps spiting it out. It swears profusely
<cjwatson> jdstrand: all you need to do is write a program in ~/bin that, when called, writes some shell configuration to ~/.bashrc and then rewrites itself to erase its trail. This is standard, crackers have been doing that kind of trick since practically the dawn of Unix
<kirkland> Tyrone_man: i've been trying Intrepid's kernel's in KVM's, no success yet, seems it's a known issue (at least on KVM at the moment)
<cjwatson> and then just wait for it to be called
<cjwatson> intrepid's kernel works in qemu but not kvm
<Tyrone_man> virtualbox here
<cjwatson> eval PATH="$PATH"> urgh
<slangasek> :-)
<kirkland> cjwatson: i thought you'd say that :-)
<Tyrone_man> I actualy got it going, but the system only installed part ways, not up to pkg select. So then I manualy rebuilt it from cd, and it seemed fine, killed it to reboot, and bam. can't handle it, not synching
<cjwatson> I suspect this swamp might be why nobody has done this properly yet ;-)
<slangasek> yep!
<kirkland> cjwatson: yeah, you noticed the bit above where pam_env documentation says stuff like $HOME probably won't be set yet, huh?
<kirkland> cjwatson: that sort of knocked me off the horse (again)
<cjwatson> kirkland: yeah
<cjwatson> I alluded to that earlier, as a wild-ass guess ;-)
<cjwatson> 22:55 <cjwatson> kirkland: /etc/environment makes sense if $HOME expansion is possible there and if PAM clients actually handle that properly (i.e. have set $HOME when they run pam_env)
<kirkland> cjwatson: ah, so you did ...  :-/
<cjwatson> I don't suppose you could draw a diagram of all the possible routes into the system?
<cjwatson> annotated with the configuration files read at each step
<cjwatson> then we might at least be able to look at it and figure out something better than we have now
<kirkland> cjwatson: by routes into the system, you mean, login/ssh/etc?
<cjwatson> right, each thing that reads a configuration file and sets environment variables
<cjwatson> so sshd -> pam_env -> bash, that kind of thing
<cjwatson> if that makes sense
<kirkland> cjwatson: and the eval PATH="$PATH" is completely unacceptable?
 * kirkland saw cjwatson redirect stdout to "urgh"  :-)
<kirkland> which wasn't quite /dev/null :-p
<slangasek> augh, gvfsd-smb-browse is going to be the death of me
<cjwatson> kirkland: I'd be worried that the potential behaviour change is rather worse. wanting a literal ${...} is pretty unlikely, but I can imagine somebody putting an environment variable containing (say) ` in /etc/environment ...
<cjwatson> or indeed "
<cjwatson> kirkland: also, doing that in .profile takes you right back to where you started; now the environment variables are only properly expanded for things that descend from .profile
<cjwatson> -> might as well not have bothered
<kirkland> cjwatson: hmm, except that the desktop managers handle this properly somehow
<cjwatson> like I say I bet Alt-F2 goes through the shell
<cjwatson> stuff actually execlped by a program straight from the desktop not through a shell probably goes wrong
<kirkland> cjwatson: agree with the latter
<cjwatson> shoving command lines through shells is so common that you may have to look reasonably carefully to find real counterexamples, but I'm confident they'll exist and they'll be basically unfixable
<kirkland> cjwatson: okay, well, i suppose I'm going to need to politely concede this bug outside of my present fu :-(
<kirkland> cjwatson: the change adding ~/bin to the end of PATH is present in Intrepid's PAM, 0.99.7.1-6ubuntu1 ... That change was sponsored on Friday.  You may want to back that out, and bug 64064 needs to be reopened
<ubottu> Launchpad bug 64064 in pam "would be nice to add ~/bin to the default PATH" [Wishlist,Fix released] https://launchpad.net/bugs/64064
<jdstrand> cjwatson: certainly-- that is what I am talking about. ~/bin first in the path makes that easier
<jdstrand> cjwatson: oh sorry, I only caught your 2nd comment
<jdstrand> cjwatson: anyway, I am not advocating many users' scripts to protect the few with an open ~/bin
<jdstrand> s/many/potentially breaking many/
<cjwatson> jdstrand: (I meant a typo-squatting script more than anything else, really)
<cjwatson> sl is probably a good candidate ;)
<jdstrand> heh
<jdstrand> cjwatson: that would work too of course
<jdstrand> cjwatson: so I guess, really, the best thing to do is nix ~/bin from the PATH completely :P
<cjwatson> ah, now you're twisting my words ;-)
<jdstrand> that wouldn't break anything
<jdstrand> heh-- only teasing
<kirkland> cjwatson: i took a look at documenting entry points to the system, i jotted down some notes.  it'll need to be a wiki document with contributions by others, in that my pam understanding is somewhat limited compared to a few others
<cjwatson> aye
<cjwatson> (er, confirmed; not meaning to slur your PAM understanding :-) )
<kirkland> "jotted down" = pen and paper ... i'll have to move them to the wiki
 * kirkland didn't take offense ;-)
<kirkland> and by "a few others" i mean "lots of others" :-)
<cjwatson> hmm, now why is http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html broken
<jdstrand> cjwatson: how so? (I've never looked at it, but it popped right up here)
 * TheMuso noticed that it was out of date yesterday but wasn't sure how regularly it was supposed to run.
<jdstrand> ah Jun 19
<cjwatson> right, out of date, it's supposed to run hourly
<jdstrand> gotcha
<cjwatson> fails with no output :-(
<jdstrand> cjwatson: probably a PATH problem :P
<kirkland> jdstrand: LoL
<cjwatson> TheMuso: did you get as far as merging initramfs-tools? it's in the updated merges section, but only because I had to fix it up a bit for the new busybox and some others touched it in intrepid too
<TheMuso> cjwatson: I hadn't looked at it, as I wasn't the last one who touched it in hardy, but I can have a look if you'd like.
<cjwatson> just because IIRC you did some Debian bug forwarding for it
<TheMuso> Yes thats right, some of which got into Debian.
<cjwatson> if you could have a go, it would be very helpful
<TheMuso> Ok I'll take a look today at some point.
<cjwatson> ooh, a new parted upstream too
<slangasek> fwiw, I've gotten a private inquiry from a member of the Debian kernel team (maks) about initramfs-tools resyncing, he was interested in seeing that get done
<slangasek> TheMuso: so I'm happy to hook you two up on this if you do take it
<TheMuso> slangasek: I've already had some contact with an initramfs-tools maintainer in the past when I filed bugs in Debian to get some of our changes back to Debian.
<slangasek> ok :)
<slangasek> probably the same one then
<slangasek> I don't think anyone besides maks is taking care of it in Debian right now
<Twigathy> If you're fixing initramfs-tools stuff, could you poke at the NFS boot stuff in 8.04? :)
<Twigathy> ipconfig or something is broken, so getting IP by DHCP for NFS boot is full of fail
<TheMuso> slangasek: Right, he's the one.
<TheMuso> slangasek: I've also noticed that alsa-lib/plugins 1.0.16 is still in proposed...
<slangasek> yah, I'll pull it today yet
<slangasek> TheMuso: how are you coming with targeted fixes?  Any progress with bisecting?
<TheMuso> Np, was just wondering whether something else came up that I didn't know about.
<TheMuso> slangasek: I have to work out a way that won't take too much time, yet allow users to test revisoins. Note that I don't experience any issues myself, so I need affected users to test revisions taken from the upstream git repo...
<slangasek> right
<slangasek> well, the nice thing about a binary search is that it reduces the number of iterations you have to go through to find the fix log2(n)
<slangasek> how many commits are there between 1.0.15 and 1.0.16 upstream?
<TheMuso> Yeah I know. The fun bit is running a bisection test for several kinds of bugs, both of which will likely be fixed by different revisions
<TheMuso> Just a sec I'll check.
<TheMuso> slangasek: 74, so when I start the bisect, it starts off cutting that down to 36.
<TheMuso> to deal with after the first bisection.
<slangasek> TheMuso: well, log2(74) < 6, so 7 is the maximum number of builds you'd have to get any one user to try in order to pinpoint their bug fix
<slangasek> uh, < 7 I mean
<TheMuso> slangasek: Yeah I figured. What I am thinking is to publish one package, get several users to test, and keep two trees, so I can track bisection for different issues, so I can mark one as bad and the other vise versa if I have to... Unless a better idea is forthcoming.
<slangasek> that sounds like the right track to me
 * cjwatson bets the problem with testing/intrepid_probs is that that timestamp was about when drescher was upgraded to hardy
<crimsun_> TheMuso: which symptoms?  The ones in 221673 or 191027?
<cjwatson> I've rebuilt its Python extension and with any luck it'll work now
<cjwatson> next run will probably be in 40 minutes or so
<crimsun_> TheMuso: note that 1.0.16 is insufficient for at least one comment in the former.  That's a dmix issue fixed in -lib hg.
<TheMuso> crimsun_: We are not going 1.0.16 wholesale any more.
<crimsun_> yes, I advised that doing so would be a bad idea some time ago.
<crimsun_> which specific bugs will you attempt to address in alsa-lib?
<TheMuso> crimsun_: Well bug 191027 is known to have a fix in 1.0.16 at least for some users.
<ubottu> Launchpad bug 191027 in totem ""Failed to connect stream: Invalid argument"" [High,Confirmed] https://launchpad.net/bugs/191027
<TheMuso> As for bug 221673 I actually prepared an SRU which is shown in that bug with diffs against plugins and lib.
<ubottu> Launchpad bug 221673 in alsa-plugins "ALSA failing with PulseAudio in Hardy" [Undecided,Fix committed] https://launchpad.net/bugs/221673
<crimsun_> TheMuso: wrt 191027, which comments?  There are too many unrelated comments cluttering the report.
<crimsun_> for instance, the maudio one(s) are not alsa-lib; they're pulseaudio not handling channel mapping.  Difficult issue that can't really be addressed aside from altering /etc/pulse/default.pa
<TheMuso> crimsun_: From https://bugs.edge.launchpad.net/ubuntu/+source/totem/+bug/191027/comments/75 downwards.
<ubottu> Launchpad bug 191027 in totem ""Failed to connect stream: Invalid argument"" [High,Confirmed]
<TheMuso> crimsun_: Yeah I'm aware of the m-audio stuff.
<crimsun_> sigh, again, nastiness with snd-hda-intel
<crimsun_> that's not alsa-lib; that's l-u-m-2.6.24
<TheMuso> right
<crimsun_> (referring to comment 88)
<TheMuso> The more I work/look at this stuff, the more of a pile of dung I consider alsa to be...
<TheMuso> oh ok
<StevenK> It's not audio, it's computed gotos!
<gnomefreak> Dont we have skype in repos? all i can find is skytools but im not sure if that is full skype type package
<gnomefreak> oops wrong channel
<TheMuso> crimsun_: So, do you think 191027 is not worth pursuing in a manner I described above?
<crimsun_> TheMuso: afraid I can't answer ATM, haven't finished reading all the comments and possibly related commits
<TheMuso> crimsun_: ok
<bryce> wow, this is sweet - a color blindness extension http://kaioa.com/node/75
<pwnguin> heh
<pwnguin> bryce
<pwnguin> we had a SoC that did that in compiz
<pwnguin> I mean, its a display only affect (unlike inkscape?) but its' been there for ages =/
<pwnguin> https://bugs.edge.launchpad.net/ubuntu/+source/compiz-fusion-plugins-main/+bug/237848
<ubottu> Launchpad bug 237848 in compiz-fusion-plugins-main "colorfilter colorblind simulations not accessible in CCSM" [Undecided,Confirmed]
<bryce> pwnguin: well cool regardless :-)
<pwnguin> its even cooler to try out games / webpages / presentations with
<pwnguin> "does my graphic work for colorblind students?"
<gnomefreak> bryce: have you heard of an issue with Intrepid nvidia drivers not working after the update of the restricted kernal package? For me i had to re write my xorg.conf to get it to work and others have stated they had issues?
<gnomefreak> -?
<pwnguin> gnomefreak: you mean besides xen stuff?
<gnomefreak> yep
<gnomefreak> atleast for me
<pwnguin> i wasnt aware xen was fixed =/
<gnomefreak> i dont use xen
<pwnguin> me either
<pwnguin> but its in -generic now?
<gnomefreak> oh it is?
<bryce> gnomefreak: hmm, not with intrepid so far (a couple reports with hardy, but were probably just mixed installs)
<bryce> gnomefreak: is it a kernel ABI mismatch perhaps?
<pwnguin> i dont think you'll get many nvidia broken reports until alpha1
<gnomefreak> bryce: i didnt have issue in Hardy
<gnomefreak> bryce: not sure bug i will look at logs tomorrow and see if anything in there helps
<bryce> ok
<crimsun_> bryce: (for hardy-*, I've heard of people missing l-r-m deps for linux-image-* dist-upgrades)
 * bryce nods
<kirkland> TheMuso: ping
<kirkland> TheMuso: hey, I have another round of the yaboot-installer merge
<TheMuso> kirkland: Ok I'm around.
<kirkland> TheMuso: okay, let me push
<kirkland> TheMuso: okay, pushed, waiting for LP to catch up ;-)
<TheMuso> kirkland: ok
<TheMuso> kirkland: kirkland I see it, I'll pull it down and have a look in a bit.
<kirkland> TheMuso: i'm not sure it's clean yet
<kirkland> TheMuso: i'm very bothered by an error 500 on: http://bazaar.launchpad.net/~kirkland/yaboot-installer/intrepid2/revision/259
<TheMuso> Aye. I get it also.
<ScottK> slangasek: I have an SRU regression I need to report.  Are you around?
 * ScottK guesses the tech board is sleeping.
<TheMuso> kirkland: However, I have managed to branch it to my machine here.
<kirkland> TheMuso: interesting, okay...  maybe there's a stray character in the changelog or something?
<TheMuso> kirkland: Did you consider getting MoN's help to do this merge?
<kirkland> TheMuso: you mean MoM?
<pwnguin> ScottK: which package?
<kirkland> TheMuso: I did it that way originally, but cjwatson asked me to use the bzr merge method.  This is the first time I have used bzr for Ubuntu package merging.
 * pwnguin isn't on the tech board or anything like that, but if it's about glchess / gnome-games, I think slasgsek knows about it
<ScottK> aptoncd.
<TheMuso> kirkland: Right.
<pwnguin> ScottK: i think you're supposed to highlight trigger everyone on the TB if its important
 * ScottK is writing mail currently.
<pwnguin> that too
<kirkland> TheMuso: i'm up for about another 45 minutes or so before I call it a night
<kirkland> TheMuso: if you review, and figure out what's wrong, I'm all ears :-)
<TheMuso> kirkland: Whats the current problem with it?
<kirkland> TheMuso: oh, just the wierdness with the changelog not being visible
<kirkland> TheMuso: the error 500 problem, i meant
<TheMuso> What do you mean not being visible?
<TheMuso> oh right.
<slangasek> ScottK: mmm, moderately around
<TheMuso> kirkland: Whats with the empty commit?
<ScottK> slangasek: bug 242554
<ubottu> Launchpad bug 242554 in aptoncd "hardy-proposed packages built against python-central uninstallable in hardy-updates" [Critical,Confirmed] https://launchpad.net/bugs/242554
<kirkland> TheMuso: thought that might solve the 500 error
<kirkland> TheMuso: I can uncommit that if necessary
<ScottK> Just sent mail to the tech board, devel-discuss, etc.
<TheMuso> kirkland: Right.
<kirkland> TheMuso: not that I have extensive bzr experience, but i've never seen this sort of thing
<TheMuso> kirkland: It may have something to do with that revision being a merge.
<TheMuso> at a guess
<ScottK> pocket copies aren't so great when the pockets have different versions of the build-depends.
<slangasek> ScottK: ok; I'll see if I can't get python-central verified and copied over tonight
<ScottK> slangasek: Thanks.
<kirkland> TheMuso: okay, i just uncommitted the empty message
<TheMuso> kirkland: One thing that you should do is document the maintainer field change.
 * ScottK ponders if he should add 'ping the archive admin who is most likely to be awake' to the SRU regression procedure.
<TheMuso> kirkland: in the changelog.
<kirkland> TheMuso: right, okay
<kirkland> TheMuso: committed/pushed
<TheMuso> kirkland: Ok.
<TheMuso> kirkland: It looks ok to me, I'm just pulling your previous branch to see what Colin was getting at with his comments.
<kirkland> TheMuso: sorry, i usually use "update-maintainer", which fixes the maintainer and adds a changelog entry
<kirkland> TheMuso: the last one was a mess... i misunderstood his instructions, and did totally the wrong thing
<TheMuso> kirkland: Thats fine, but in this case it would not work as the maintainer is already changed.
<TheMuso> kirkland: Oh right.
<kirkland> TheMuso: right
<TheMuso> So its just as easy to put the entry in by hand.
<TheMuso> dch -a
<TheMuso> Type text
<TheMuso> save, exit.
<kirkland> TheMuso: I'll add that to my list of things to do differently between a deb/bzr merge
<TheMuso> kirkland: Its not a matter of doing things differently. Even when doing a merge, the changing of the maintainer field should be documented in the changelog entry for the merge.
<TheMuso> Regardless whether its a deb only, or involves a vcs branch of some sort.
<kirkland> TheMuso: understood.
<TheMuso> kirkland: I see what you mean, that original branch is quite big. :)
<TheMuso> kirkland: Anyway, it looks fine to me, bar that entry in the changelog.
<kirkland> TheMuso: pull revision 260
<kirkland> TheMuso: I reverted the empty commit, and added the changelog entry you requested
<TheMuso> kirkland: gotcha.
<TheMuso> kirkland: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<TheMuso> kirkland: I suggest you push --overwrite
<TheMuso> since you reverted a commit that was pushed
<kirkland> TheMuso: "No new revisions to push." ...  this was why I made an empty commit earlier
<TheMuso> kirkland: hrm ok.
<wgrant> TheMuso: YOu'll have to recheck it out.
<wgrant> Or remove some revisions from your branch.
<TheMuso> wgrant: Yeah thats my thought.
<TheMuso> ok pulled the empty commit locally and now it pulls successfully.
<TheMuso> kirkland: Ok that looks fine to me.
<kirkland> TheMuso: cool, what's next?  you merge into main?
<kirkland> the main branch i mean?
<TheMuso> kirkland: The next thing is for you to update the changelog from UNRELEASED to hardy, then I'll merge it into the core-dev branch and upload.
<TheMuso> s/hardy/intrepid/
<kirkland> TheMuso: hmm, okay...  at what point do I do that?  cjwatson asked me to set it to UNRELEASED...  was that just long enough to get it vetted by you guys?
<TheMuso> kirkland: Hrm ok. He told me to upload once I was done, so I guess me merging and doing that myself makes sense.
<kirkland> TheMuso: okay, so you pull my branch, fix the target release, and you'll push to the main branch?
<TheMuso> kirkland: Yes.
<kirkland> TheMuso: awesome, thanks for the lesson
<TheMuso> kirkland: You're welcome.
<kirkland> slangasek: superm1: laga: mythbuntu amd64 8.04.1 installed fine for me ;-)
<superm1> great
<superm1> thanks kirkland
<superm1> just need to generate our live disks then and make sure those are still good too
<kirkland> superm1: no prob
<superm1> kirkland, hows the ppc build working?
<superm1> does your ppc have altivec?
<kirkland> superm1: the ppc frontend is working for the first time in months!
<kirkland> superm1: how do i tell?  is it in /proc/cpuinfo?
<superm1> should be i believe
<superm1> what generation of PPC is it?
<kirkland> superm1: mac mini, g4, i believe
<superm1> oh yeah that'll have altivec
<kirkland> superm1: i'm checking
<superm1> its the earlier ones that didn't
<superm1> w/o altivec, i believe video is practically unplayable on there
<TheMuso> G3 == no altivec, G4-G5 == altivec.
<superm1> there's the info i was looking for
<TheMuso> kirkland: Note that the Minis, even the 1.42 model can't play HD video, since the CPU just can't hack it.
<kirkland> TheMuso: yeah, sadly i know
<kirkland> superm1: yeah, it does have altivec
<superm1> kirkland, i was actually considering an apple tv for a frontend until i heard the obscene specs that are going to be necessary for HD-PVR support
<superm1> oh well
<TheMuso> superm1: Obscene? What do you mean exactly?
<kirkland> superm1: yeah, the form factor is just so attactive
<superm1> TheMuso, well people are saying AMD64 5000+ minimum, and high end geforce 9xxx cards w/ hardware assistance
<superm1> to be able to handle decoding
<RAOF> That seems to be substantially above what I've read.
<pwnguin> depends on the quality
<kirkland> superm1: i have an amd64 3800 that renders HD just fine
<superm1> HD-PVR files are x264 spit out
<pwnguin> the super high res stuff i wouldnt doubt
<superm1> that's reassuring to me to hear RAOF.  i've not kept up the last week or two
<RAOF> I seem to recall benchmarks of the 8xxx/9xxx hardware assistance taking some 10% CPU on a not-too-super core2 with h.264 1080p
<pwnguin> RAOF: i wonder how much that falls with say a 6xxx
<RAOF> Totally.
 * TheMuso is thinking of using an intel mini for his frontend when he moves, as long as his server will have a tv port nearby.
<RAOF> There just isn't any hardware assist there.
<superm1> i'll look for some more accurate benchmarks as the hardware becomes  more prevalent
<kirkland> do the new mini's have digital sound out?
<TheMuso> kirkland: Yes.
<TheMuso> Shared with headphone/line out.
<RAOF> superm1: Also, these were Windows benchmarks; it's likely that you'll see close to no hardware assist on linux.
<pwnguin> RAOF: my x2 4000+ with a 6600gt does okay, but drops frames / stutters
<kirkland> TheMuso: 5.1 coax or optical?
<TheMuso> kirkland: Optical.
<TheMuso> Amd 5.1 afaik yes.
<kirkland> TheMuso: nice!
<pwnguin> RAOF: and that's just on 720 =(
<TheMuso> kirkland: As I said, only if I don't need to have the tuner card in the frontend.
<RAOF> superm1: Unless you'd like to hack on the gallium video decoder state tracker :)
<TheMuso> I don't trust USB for anything but keyboard/mouse.
<superm1> RAOF, oh! yeah linux requirements are much higher unfortunately
<RAOF> pwnguin: Right.  dual-core isn't very useful for decoding, so you're better off with really fast single threaded performance, which is expensive.
<TheMuso> I would also get a mini only if they were updated with better GPU chips, even a higher/more recent intel chip.
<TheMuso> kirkland: heh won't be uploading it just yet, need to set up a PowerPC build environment for intrepid, something I've been meaning to do for a while now. :p
<TheMuso> So I can test build.
<kirkland> TheMuso: so that's another question i have for you...
<kirkland> TheMuso: if this was deb merge, i would have debuild'ed ...
<kirkland> TheMuso: what's the build process for this?
<TheMuso> kirkland: IMO its better to always build in a chroot, unless you need to step through a package's build process step by step to find an FTBF.
<TheMuso> kirkland: What I'm doing for this, is fixing the branch up appropriately, i.e UNRELEASED to intrepid, and committing. Then I use the bzr-buildpackage ocmmand to export to a source package format, i.e .dsc file and .tar.gz file.
<TheMuso> The exact command I'm using is 'bzr-buildpackage -S --native'
<kirkland> TheMuso: ah, cool!  that's the part I was missing....
<TheMuso> kirkland: Ok build environment set up, test building.
<TheMuso> kirkland: Uploaded.
<kirkland> TheMuso: cool, thanks for working me through this one
<TheMuso> kirkland: np
<kirkland> TheMuso: I'm calling it a night ;-)
<TheMuso> kirkland: Good night then.
<orbisvicis> why suddenly so many kernel updates ?
<RAOF> orbisvicis: Because 8.04.1 is nearly done? :)
<orbisvicis> oh. 8.0.4.1 ?
<pwnguin> the "now its really stable" release ;)
<bluefoxicy> ok, evolution just erased my calendar.
<orbisvicis> heh thanks
<bluefoxicy> good job
<bluefoxicy> so will 8.0.4.1 have a feature in it to prevent anything from STEALING FOCUS ever?
<RAOF> bluefoxicy: Evolution isn't capable of doing that to me; it's google-calendar support doesn't work well enough for me :)
<bluefoxicy> RAOF:  I tried to type a note and the keyboard stopped working, then pasted a date field.  I hit ctrl+alt+arrows and couldn't switch desktops.  I couldn't click other windows.  I hammered around on alt/ctrl/shift/etc to see if a key was stuck, no such luck
<orbisvicis> is there a roadmap ?
<bluefoxicy> evolution then closed, said it couldn't access my "memo" until it restarted, and then came up with a blank calendar.
<bluefoxicy> blank as in tasks from 3 days ago were gone even.
<RAOF> bluefoxicy: That sucks a lot.
<bluefoxicy> you're telling me?
<bluefoxicy> I've had numerous incidents where some application locks up my mouse and keyboard and I can't do anything in X
<bluefoxicy> win!
<bluefoxicy> I added one new appointment and it ressurected all lost data by magic.
<RAOF> Huzzah!
<bluefoxicy> I have no way to reproduce this or describe the original bug, or provide explanation for WHY it happened
<RAOF> You probably could have rescued it with a magic-sysreq combination;  Whatever it is that switches the keyboard back to "raw" mode would probably have let you VT switch.  Where you could have made a guess as to what was holding things hostage.
<Amaranth> RAOF: I thought it switched it _out_ of raw mode
<Amaranth> bluefoxicy: Do you use compiz? If so, did it happen during a focus change?
<bluefoxicy> no compiz
<RAOF> Amaranth: It's a _magic_ sysrq key.  Maybe it swiches me to raw, and you out of raw? :)  I'm really not sure, though.
<bluefoxicy> I can vt switch
<bluefoxicy> and when I switch back to X i'm stuck again
<Amaranth> eep, my sysrq is a prtsc
<bluefoxicy> the problem is having 20-30 windows and effectively killing random ones and/or X, depending.  If you kill a holding program it might not return control to X; Qemu for example does this (hence why I don't run it anymore)
<bluefoxicy> for the misfortunate soul who kills qemu when it freezes, you have to run 'DISPLAY=0 qemu <something>' in a real terminal to start a new one to get your mouse back <_<
<bluefoxicy> imagine losing it to something that doesn't normally grab, and thus won't be nice and reset control for you
<Amaranth> X grabs are broken
<pitti> Good morning
<bluefoxicy> Amaranth:  is there a program I can run to tell X to reclaim?
<Amaranth> bluefoxicy: I don't think so
<Amaranth> Otherwise they wouldn't be quite as broken :P
<bluefoxicy> heh I was going to suggest watching the event device but whether it's /proc or /dev or actually works anymore i can't tell
<bluefoxicy> you used to be able to read raw keyboard (console) events from some interface, and so pick up key combinations like alt+sysrq+x ;)
<DasKreecH> Hallo
<DasKreecH> Is there a public list of Canonical Paid Devs?
<dholbach> good morning
<DasKreecH> morning
<slangasek> Canonical employment records are not public information, no
<DasKreecH> ok
<DasKreecH> Is there a number?
<DasKreecH> We employ 28 People?
<slangasek> Canonical employs more people than that, but I'm not aware of any public head count, either
<DasKreecH> It's not a public company is it?
<slangasek> nope
<DasKreecH> Would have been fun to own a bit of history ^_^
<pwnguin> there are some LP teams that might suggest some status of employment
<pwnguin> but there's likely a few other groups that dont need LP etc.
<Amaranth> pwnguin: Not really
<pwnguin> webmasters? sysadmins? lawyers?
<slangasek> well, there's at least one LP team whose members consist entirely of Canonical employees (canonical-kernel-team), but that doesn't give you a very good overview of the on-staff developers :)
<pwnguin> there's also canonical-qa
<pwnguin> but i dont think it would be healthy for canonical to publish a list of "people to hire away to cripple our company"
<DasKreecH> pwnguin: Or  how many people you would have to attempt at doing so
<pwnguin> heh
<wgrant> slangasek: Can you please look at bug #206912 and convince Soyuz that vlc really should be in multiverse?
<ubottu> Launchpad bug 206912 in vlc "Demote vlc and rdepends to multiverse" [Medium,Fix released] https://launchpad.net/bugs/206912
<wgrant> It didn't go anywhere.
<wgrant> Much like nagios2.
<wgrant> Ah.
<wgrant> It did get demoted.
<wgrant> But then bounced.
<slangasek> "bounced"?
<wgrant> Yes.
<wgrant> The next upload decided to go into universe.
<wgrant> (some 12 hours after it was demoted)
<DasKreecH> repos are considered demotions? :)
<wgrant> Huh.
<slangasek> DasKreecH: well, being relegated to the archive for non-free software is definitely considered a demotion...
<RAOF> Universe->Multiverse is considered a demotion, yes.
<wgrant> Only the source changed.
<pwnguin> well multiverse is ;)
<wgrant> The binaries are still multiverse.
<persia> DasKreecH: There's a concept of mutiverse -> universe -> main being "promotion", and the reverse "demotion".
<slangasek> wgrant: yeah, source and hppa... nice :)
<wgrant> This is interesting:
<wgrant> 2008-04-15 01:02:03 INFO Override Component to: 'multiverse'
<wgrant> 2008-04-15 01:02:03 INFO 'vlc - 0.8.6.release.e+x264svn20071224+faad2.6.1-0ubuntu2/multiverse/graphics' source overridden
<wgrant> The source looks like it was multiverse initially.
<wgrant> So it got overriden to the same place, and then forgot about it 12 hours later.
<slangasek> 2008-06-24 06:21:02 WARNING 'vlc' has no binaries published in intrepid
<slangasek> <ahem>
<wgrant> I did just upload a new one which depwaited.
<slangasek> is 0.8.6.release.e+zdebian-2.3ubuntu1 yours?
<wgrant> That's why I noticed that the source was in universe.
<wgrant> It is.
<slangasek> ok
<slangasek> well, I think the source override has been fixed now, which should unstick the dep-wait (?)
<wgrant> Thanks.
<wgrant> I'll throw it back now.
<wgrant> Hopefully it will work.
<wgrant> I suppose this deserves a Soyuz bug.
<wgrant> I wonder if the binaries will go into the right place now (particularly hppa).
<slangasek> they might have to be kicked again once they're up-to-date, given the above warning
<slangasek> I don't think the "source+binaries" override took effect on the binaries because soyuz couldn't see that they were related, I guess
<wgrant> Right.
<wgrant> Hmmm.
<wgrant> The hppa binaries that existed when you overrode it all last time are odd.
<wgrant> There are only two of them.
<wgrant> When they should be a dozen or so.
<slangasek> I see the full set here
<wgrant> Oh.
<wgrant> Right, those are only the arch: all ones (the names confused me), as hppa failed.
<wgrant> Shall I file a bug about the source promoting itself?
<slangasek> by all means; I don't have a clue how to track that bug down, but it certainly appears to be a bug
<wgrant> Right, will do.
<wgrant> slangasek: Thanks. It's building fine now, and I've filed the bug.
<dholbach> hi mvo
<wgrant> Urgh, of course it all failed to upload. Forgot about that bug.
<mvo> hi dholbach
<slangasek> bryce: I wonder if you might be familiar with a bug which, when closing the lid on a laptop with a monitor hooked up to the VGA port of the 945GM, causes the machine to hard-lock... :)
<bryce> slangasek: ah you mean the pipe-a quirk bug?
<bryce> one sec
<slangasek> heh
<slangasek> so is that what that pipe-a quirk thing is about
<bryce> yep
<bryce> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/138256
<ubottu> Launchpad bug 138256 in xserver-xorg-video-intel "laptop hangs on lid close unless ForceEnablePipeA option enabled" [Undecided,Confirmed]
<pwnguin> heh, i saw that on LP and wondered what on earth it meant :)
<slangasek> bryce: ok; so I should test out the option, and if it fixes the problem for me, file a new bug with all my details for quirking?
<bryce> slangasek: yepamundo
<dholbach> thekorn: woah! activity log reading in pylpbugs! :)
<thekorn> dholbach, worked for ages, but was not documented ;)
<dholbach> thekorn: I didn't know! :)
 * wgrant notes that it might be more useful if the activity log itself was actually a proper log of the activity.
<thekorn> wgrant, I agree, it is unfortunate that not all events are listed there
<wgrant> thekorn: I suppose we'll see some happenings there post-2.0... for the moment one has to check archives on ubuntu-bugs@l.u.c if one wants to work out what happened to a bug.
<szonek> how can i get SHARE tab in properties of folder (nautilus) i know it's in ubuntu.. i wan't to get have this on Gentoo..
<szonek> i know it's not support channel but can't find this package
<wgrant> szonek: By talking to the Gentoo people, I would presume.
<szonek> wgrant: right, but i'm looking for a package/project(or something) name and that's universal i think..
<wgrant> szonek: You might be looking for nautilus-share.
<szonek> wgrant: okay, thanks
<sebner> seb128: are you uploading ipe or waiting? Because at least the colormap change was refused several times by the debian maintainer
<wgrant> Hmm, I see that nagios2 was promoted to main and then removed fairly soon after - should nagios3 be promoted in its place?
<seb128> sebner: I just commented on some of the bugs, I didn't mean to upload those
<seb128> sebner: any reason why we need this change if debian refuses it? I'm just trying to reduce the useless deltas
<jdstrand> cjwatson, kirkland: fyi, I reverted the patch for bug #64064 , and adjusted the bug accordingly. Please add additional comments as necessary.
<ubottu> Launchpad bug 64064 in pam "would be nice to add ~/bin to the default PATH" [Wishlist,Confirmed] https://launchpad.net/bugs/64064
<jdstrand> cjwatson: hi btw! :)
<sebner> seb128: ah ok, because you uploaded lasso (maintainer already responed =)). To behonest I have no idea why the maintainer refuses it. Some time ago we sent an ubuntu patch for icon,desktop file and this colormap and in the changelog he mentioned: "   * debian/rules: Install desktop file and icon.  Note that I'm not applying the stylesheet part of the patch.
<CR17> lu
<siretart> sebner: is there a corresponding bug about that in the debian bts?
<sebner> siretart: debian ##451022
<sebner> siretart: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451022
<ubottu> Debian bug 451022 in ipe "ipe: missing icon and desktop file, standard color palette quite limited" [Wishlist,Closed]
<mvo> is someone looking at powernowd?
<mvo> (the merge)
<siretart> intersteing
<mvo> if not, I will take it
<sebner> siretart: yep ^^, you may want to upload my merge then or anything else todo?
<james_w> seb128, asac: any opinion on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460691
<ubottu> Debian bug 460691 in gnome-system-tools "network-admin incompatible with network-manager" [Important,Closed]
<ogra_cmpc> james_w, not sure we care in intrepid with NM7
<asac> james_w: we have worked around that bug
<asac> james_w: err, cant really identify how the upload fixes it (at least from changelog)
<ogra_cmpc> well, he talks about the etch version of NM
<ogra_cmpc> thast years old
<ogra_cmpc> asac, you culd just ask lool who made that upload ;)
<asac> ogra_cmpc: the upload closing that bug happened in may
<asac> ogra_cmpc: i didnt ask about that bug ;)
<doko> heh, somebody must have an alarm set for sync requests ;)
<cjwatson> doko: just reloading the page after doing the last lot ;-)
<cjwatson> soren: vgabios looks syncable?
<soren> cjwatson: Let me check..
<soren> cjwatson: Yup, looks like it.
<soren> Oh..
 * soren just realises he never finished the iptables merge
<soren> How odd.
<cjwatson> vgabios done
<soren> cjwatson: Thanks very much.
<emgent> morning
<seb128> james_w: the split should be no issue for ubuntu, we were speaking about deprecating network-admin if network-manager 0.7 does every required anyway
<dholbach> bryce, soren: Laney could confirm the "mouse-cursor-only-moving-in-the-top-left-corner" problem in intrepid
<james_w> seb128: hi, so I should not take that change from Debian?
<soren> dholbach: Mkay.
 * Laney nods
 * ogra wonders if pitti and Q-Funk shouldnt better talk by IRC that geode bug explodes :)
<pitti> ogra: we do, on jabber
<pitti> but I think it's sorted out now
<ogra> heh
<ogra> yay
<ogra> that'd be cool
<ogra> we have so many unhappy ltsp users
<pitti> just waiting for slangasek's sru freeze exception yay or nay now
<seb128> james_w: either way, that doesn't make a big difference
<seb128> james_w: the split doesn't create an issue, we just need to install the new package if we want it
<seb128> james_w: I would take the change for ubuntu
<james_w> seb128: ok, thanks.
<seb128> zul: hi
<zul> seb128: hi there
<seb128> zul: you did this socks4-server upload right?
<zul> seb128: yep
<seb128> zul: did you consider bug #241012 before uploading?
<ubottu> Launchpad bug 241012 in socks4-server "Please sync socks4-server 4.3.beta2-16 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/241012
<zul> seb128: no I didnt
<seb128> zul: the bug states it could have been synced because the shlibs already adds the depends
<zul> seb128: sorry about that
<seb128> zul: would be a good idea to look at open bugs before uploading something ;-)
<seb128> zul: no problem, could you comment on the bug and close it now?
<zul> sure..
<seb128> maybe verify if the package can really be synced next time
<seb128> thanks!
<dholbach> bryce: just drop our patch on xserver-xorg-input-vmmouse (a similar fix was applied upstream already)
<dholbach> soren, Laney: ^
<soren> dholbach: Oh, cool.
<dholbach> Laney: so building just the debian version of it and using that should make it work again
<jcastro> slangasek or pitti: wrt. SRU discussion at UDS, at the time it was pending approval by the TB or something, has that been resolved?
<pitti> jcastro: hm, which discussion in particular?
<jcastro> pitti: the one we had with murray, the glom maintainer
<jcastro> basically, the new policy meets all his needs but it hadn't gone official yet
<pitti> AFAIK, the current wiki page is fully TB-ack'ed
<jcastro> ok
<pitti> admittedly we have been pretty liberal in the interpretation of "non-critical fixes which do not have the potential to ruin your system" for hardy so far
<pitti> jcastro: since we had so many people to throw at hardy SRUs
 * jcastro nods
<Laney> dholbach: That seems to work well, nice one!
<dholbach> ROCK
<ogra> pitti, are you playing the NEW queue jockey today ? i just split ldm into binary and theme package, the theme package will need NEWing (once built) and main promotion
<pitti> ogra: not normally, only when being asked nicely :) (my archive day is Friday)
<ogra> ah, k
<pitti> sounds easy, though
<pitti> is it already in NEW?
<ogra> just uploaded i only wanted to check my opportunities ;)
<ogra> its binary NEW ... source is still ldm
<ogra> but ldm depends on it and i want to avoid uninstallability
<cocoa117> hello, any idea how to contact ubuntu backports developer in IRC?
<cocoa117> to asking questions about the issue
<jdstrand> pitti: hi!
<pitti> hey jdstrand
<jdstrand> pitti: pam-pgsql needs to be sync'd from debian in intrepid. however, the base version is 0.6.3, but the orig.tar.gz is different in intrepid and debian. is the proper procedure to update the orig.tar.gz then use a build1?
<jdstrand> pitti: well, just rebuild the source pacakge using build1, use -sa and upload
<wgrant> jdstrand: You want to grab the Debian source package, extract that, replace the Debian upstream tarball with the Ubuntu one, create a build1 fakesync changelog entry, and build the new source package.
<wgrant> Do not use -sa.
<pitti> jdstrand: exactly
<jdstrand> asac: ok cool
<pitti> jdstrand: right, -sa won't help; you can't overwrite the one in the archive
<pitti> jdstrand: I usually unpack the Ubuntu orig.tar.gz, apply the debian diff.gz (zcat ../diff.gz | patch -p1), debuild
<pitti> jdstrand: but wgrant's approach works as well
<asac> jdstrand: huh?
<pitti> jdstrand: oh, before debuild, of course dch with a build1 changelog
<jdstrand> asac: sorry
<asac> k
<jdstrand> s/asac/pitti and wgrant/
<jdstrand> Koon: ^
<asac> yep
<jdstrand> pitti: right
<Koon> jdstrand: we'd do that even if the Ubuntu 0.6.3 orig.tar.gz is badly done ?
<cjwatson> Koon: Launchpad (rightly) won't let you overwrite it with the same file name, no matter what
<Koon> (includes a whole debian/ dir)
<pitti> Koon: unfortunately we have some broken stuff like that, yeah
<pitti> weird, I had that two or three times when doing merges
<cjwatson> there are some edge cases where you might want to change the upstream version number (0.6.3fixed or something), but bear in mind that that will mean you won't get the benefit of merge-o-matic any more
<cjwatson> so that should be reserved for when you have no other choice
<pitti> jdstrand: in this case, wgrant's approach is definitively more robust
 * wgrant had to do that this evening.
<Koon> cjwatson/pitti: ok, thx
<wgrant> (rename the upstream tarball)
 * ogra scratches head about LPs interpretation of long changeogs like https://launchpad.net/ubuntu/intrepid/+source/ldm/2:2.0.6-1ubuntu1
<ogra> seems it wipes all contributor names and just attaches my name at the bottom ?
<ogra> that seems wrong
<cjwatson> ogra: is that bug 55795?
<ubottu> Launchpad bug 55795 in soyuz "+changelog includes misleading information related to package versions and authors" [Medium,Confirmed] https://launchpad.net/bugs/55795
<ogra> yeah, looks like it, thanks
<ogra> i was just about to file a duplicate :)
<ogra> wow, thats old
<Keybuk> bryce: can't update -intel due to conflict on -i810 (dep of -all)
<ogra> sholdnt that be a recommends ?
<ogra> nice, only 68 merges left
<ogra> (main)
<cjwatson> we're getting there ..
<cjwatson> ArneGoet1e: are you already part-way through your fontconfig merge?
 * ogra wonders if tedg will do rss-glx (its tagged with slangasek's name though)
<ArneGoet1e> cjwatson: let's say I have it on my plate right now
<Keybuk> hmm
<Keybuk> quite annoying
<Keybuk> after an upgrade, my laptop panel no longer works
<cjwatson> ArneGoet1e: ok, cool
<SEJeff> How are seperate distributions created? In porting oVirt (http://ovirt.org) to Ubuntu we need a livecd-creator ish command for Ubuntu
<cjwatson> the livecd-rootfs package in Ubuntu is what we use to build our live filesystems
<cjwatson> though of course you need to wrap an ISO round it too
<SEJeff> Sure
<cjwatson> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ (and the stuff in configs/devel having checked that out) is our CD creation software
<SEJeff> cjwatson, Is that packaged?
<SEJeff> Because I'm porting scripts over to create oVirt appliances so they can run on Ubuntu. Having them apt-get a package would be nice
<cjwatson> SEJeff: no, I'm afraid it isn't
<cjwatson> 'bzr get' it for the meanteim
<cjwatson> meantime
<cjwatson> it's not really in packageable form at the moment (hardcoded paths) and the obvious ways to fix that would make other things awkward, so it's not made it very high up the to-do list ...
<siretart> one might want to give 'live-helper' a shot. I was told it at least used to produce working live cds.
<cjwatson> ArneGoetje: (m17n-db is also on your list)
<ArneGoetje> cjwatson: yep
<cjwatson> siretart: I'd just like to completely disclaim any interest in supporting people building Ubuntu CDs with live-helper; they can sort themselves out
<cjwatson> (simply because I haven't looked at it, I expect it's missing lots of little bits and pieces that will cause subtle issues simply because it's not actively used by Ubuntu)
<doko> seb128: how familiar are you with scrollkeeper? The unmodified package from hardy ftbfs in intrepid
<siretart> cjwatson: right, ok
<Koon> pitti: for a fake sync do you keep the combined changelog ? the Ubuntu Original-Maintainer ?
<seb128> doko: not so much, what is the issue?
<seb128> doko: let me try
<seb128> doko: weird, no idea about this one
<MacSlow> dholbach, so from https://bugs.edge.launchpad.net/ubuntu/+source/planner/+bug/219109 I take that debian suggests to have gda/database-support enabled again?!
<ubottu> Launchpad bug 219109 in planner "please sync planner (main) from Debian (main)" [Wishlist,Incomplete]
<doko> seb128: yeah, will look at it tomorrow again
<dholbach> MacSlow: yes, the trouble is that it does not build right now in the pure debian form
<MacSlow> dholbach, there's a fix in in place (in Ubuntu now) due to the merge that makes it compile
<dholbach> MacSlow: nice
<MacSlow> dholbach, the cdbs-based patch for that is tiny
<MacSlow> it belongs upstream so I'll send it right there instead of debian?!
<dholbach> best to both
<MacSlow> so soon we should be able to just drop it and debian will add --enable-database=yes to their debian/rules again too
<MacSlow> dholbach, ok then
<dholbach> ROCK
<Daviey> ON
 * dholbach hugs Daviey
<Daviey> :)
<bliZZardz> got a quick Q on python : is it possible to encrypt the py files(modules) and load them dynamically(and hence decrypt at run time)
<bliZZardz> (am not sure about the relevance of the Q with the forum, but would be interested to know as there are many devs around)
<ion_> The topicâs got a quick A.
<cjwatson> Koon: I wouldn't bother keeping the combined changelog, and keeping Original-Maintainer isn't necessary (dpkg-source only enforces it if the changelog contains 'ubuntu')
<Koon> cjwatson: yes, and pitti did it this way with an openvpm fakesync.
<Koon> cjwatson: thx for the advice.
<cjwatson> no problem
<kirkland> pitti: ping
<jdstrand> kirkland: pitti left a little while ago
<kirkland> jdstrand: ah, okay, thanks.  i'll catch him later.
<kees> slangasek: heads-up, we need to get bug 219914 fixed before 8.04.1 goes out
<ubottu> Launchpad bug 219914 in apache2 "mod_disk_cache enabled globally by default" [Undecided,Confirmed] https://launchpad.net/bugs/219914
<ogra> gone dancing :)
<kirkland> pitti is a regular Patrick Swayze :-)
<ogra> haha
<tedg> Okay, so why doesn't apt know the number of files it's going to get on an update?  Why can't it cache that value?
<seb128> tedg: does it matter?
<seb128> tedg: what do you call files? the packages content? or the number of updates to download?
<tedg> I don't know, I'm guessing they're indexes.  I know when I click update manager it starts with "1 to 55" and changes to "154 of 154" when complete.
<seb128> ah, right, that's a well known issue
<seb128> dunno why it's hard to get the correct count
<seb128> but I've been bugging mvo about it almost every cycles ;-)
<tedg> Heh, good.
<tedg> :)
<mvo> *cough*
<mvo> seb128: that reminds me, have you seen anything like: bug #240806 yet? it seems to make gconf crash and that in turn makes update-manager crash :/
<ubottu> Launchpad bug 240806 in gconf "Upgrading Dapper Server to Hardy Server crashes" [High,Triaged] https://launchpad.net/bugs/240806
<seb128> mvo: no, that seems to be local corruption or something
 * mvo nods
<slangasek> kees: mm, tagging 219914 for .1; who's taking responsibility for the update?
<kees> slangasek: I'm volunteering zul or mathiaz for the moment, but I can do it later today if they don't have time.
<kees> slangasek: when is freeze again?
<slangasek> kees: in the past?
<slangasek> i.e., anything you ask me for is an exception here
<kees> slangasek: that's what I feared.  :P
<kees> slangasek: we'll get something cranked out before EOD.
<kees> slangasek: the reason it's important to get in is that it's really only triggered by dapper->hardy upgrades, and there isn't a good way to automatically fix the problem afterwards.
<kees> anyway, I'm out for a few errands, back in a bit.
<slangasek> kees: right, understood, that's why I'm marking it for .1 without further quizzing ;)
<bryce> Keybuk: I've got a change pending for xorg that I think will fix those -all settings.
<cjwatson> siretart: can you confirm your ack on bug 242711?
<ubottu> Launchpad bug 242711 in ubuntu "Please sync pam-fprint (0.2-3) from Debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/242711
<cjwatson> the activity log doesn't currently allow me to verify emgent's comment
<slangasek> kees: gar why is that bug marked as a security vuln
<mathiaz> slangasek: is there any alpha1 iso required to do iso testing ?
<mathiaz> zul: are you working on bug 219914 ?
<slangasek> mathiaz: I'm going to be sorting through the alpha1 ISO status today, so I don't know the answer to that yet
<ubottu> Launchpad bug 219914 in apache2 "mod_disk_cache enabled globally by default" [Undecided,Confirmed] https://launchpad.net/bugs/219914
<mathiaz> slangasek: ok - I'm writing up the server minutes, and I mentionned there that we're doing iso testing for alpha1
<slangasek> mathiaz: last I saw there were some uninstallability problems in general yet, which may not affect -server but in any case need to be resolved before we go for widespread ISO testing for alpha1
<mathiaz> slangasek: ok - so there is no point in asking for alpha1 testing now ?
<mathiaz> slangasek: better focus on 8.04.1 testing ?
<slangasek> there are no candidate ISOs posted currently...
<slangasek> aside from the alternate CDs, but I don't know who posted those or how usable they actually are
<slangasek> 8.04.1 testing is a good focus for today; tomorrow would be good for focusing on alpha1, if everything goes well :)
<cjwatson> I've been working on alpha-1 installability; we're mostly there, but there are one or two open issues
<cjwatson> I wouldn't object to testing so that we don't have to serialise it all
<slangasek> ok
<cjwatson> xserver-xorg-video-all being uninstallable ain't gonna help
 * slangasek nods
<cjwatson> but I think that's a trivial archive issue and I'll fix it now
<ogra> Mithrandir, do you plan to do the matchbox merge ? (seems easy and small, i could quickly do it)
<cjwatson> oh yes, waiting on NEW
<cjwatson> ogra: hmm, I looked at it briefly and it looked enormous, but maybe I misread
<ogra> cjwatson, well, tollefs changes got cleanly carried over, all that changed in debian is the dep on xsettings ... the merge is actually only to clean up control and add a changelog entry
<cjwatson> ah
<cjwatson> right, accepted xserver-xorg-video-intel, so I think that should leave us with no uninstallables that cause ISO problems
<ogra> i can cleanly unapply the 1.2-1ubuntu1 patch apart from these two files :)
<ogra> but i dont want to just grab it in case tollef wanted to do it
<cjwatson> desktop CDs are, I think, unlikely to be ready for alpha-1
<cjwatson> ogra: at this point, I suggest just doing it
<ogra> oki
 * ogra does
<cjwatson> the mobile team can clean it up afterwards if they want/need to
<cjwatson> I think Tollef was doing that in his capacity as mobile tech lead rather than out of personal interest
<ogra> yeah, thought so
<slangasek> cjwatson: what are the problems with the desktop CDs right now (so we make sure we're on track to resolve those for alpha2)?
<cjwatson> slangasek: ubiquity, ubiquity, and ubiquity
<slangasek> ok :)
<cjwatson> slangasek: evand is working on updating it for the major state machine rework in localechooser, but isn't done yet
 * slangasek nods
<cjwatson> slangasek: that's the only major problem I'm aware of so far, though it's not impossible that there are others
<pitti> kirkland: pong
<kirkland> pitti: hiya...  you had a bit of feedback on mount.ecryptfs_private.c, asking me to use fputs() rather than fprintf()
<kirkland> pitti: i think you had suggested fputs() such that I would have to append '\n
<kirkland> pitti: which is somehow troublesome for i18n
<kirkland> pitti: but in my testing, fputs() doesn't not append a newline character, (though puts() does, strangely)
<pitti> kirkland: right, I mixed that up, sorry
<pitti> kirkland: but another reason is that fputs() runs much less code than fprintf(), thus it's faster and less prone to injection of % macros
<kirkland> pitti: okay, so i left the fputs(), but I did have to append the '\n', for readability
<kirkland> pitti: fair enough, i left the fputs()
<mathiaz> kees: re bug 219914 - I agree with you - the best option is to not enable any caching by default
<ubottu> Launchpad bug 219914 in apache2 "mod_disk_cache enabled globally by default" [Undecided,Confirmed] https://launchpad.net/bugs/219914
<mathiaz> kees: I don't think we should fix the upgrade code - the mod_disk_cache module still has to be enabled (as mentionned in the debian bug)
<mathiaz> kees: we should remove the CacheEnable directive in disk_cache.conf and mem_cache.conf
 * slangasek solicits a second opinion on bug #99489
<ubottu> Launchpad bug 99489 in avahi "avahi-autoipd gives me an useless default route" [Medium,Confirmed] https://launchpad.net/bugs/99489
<SEJeff> slangasek, Maybe a avahi-autoipd should have a special case?
<SEJeff> To not add a route when no other ones exist?
<ScottK> slangasek: I don't suppose just nuking avahi is an option?
<SEJeff> That doesn't help a mobile user, but would fix one case
<slangasek> SEJeff: the route in question is added *only* when there are no other routes on the interface
<ScottK> Personally I don't consider my computer hunting around for other computers to talk to a feature.
<slangasek> so I agree, it should not add a route when no other ones exist :)
<ScottK> slangasek: I agree.
<slangasek> "just nuking avahi" - that's not a very satisfying solution, given that it's a recommends of ubuntu-desktop
<slangasek> and I am in favor of the ad-hoc functionality in general, just not this particular feature
<slangasek> ScottK: agree enough that, as core-dev, you think we should deviate from upstream's (Trent's) opinion here?
<ScottK> I guess I don't see the point of adding an infinite route when there is no one to talk to.
<ScottK> If it's interfering with other packages, I think it should go.
<slangasek> the point is that it means you can magically reach any host on the local segment, regardless of its IP address
<slangasek> but not without its down-side
<ScottK> Right.
<SEJeff> magic is bad
<ScottK> Since almost everything these days seems to have link-local, I think it's OK.
<slangasek> well, I have older Linux hosts that don't
<ScottK> How old?
<ScottK> The one Windows 2000 box we still have will do it.
<slangasek> 3- to 4-year-old installs; server installs without avahi
<slangasek> yes, Windows has actually been doing link-local for yonks
<ScottK> I don't think it's unreasonable to assume that anyone not doing link-local doesn't really care to talk that way.
<slangasek> well, that doesn't help sorting out this bug
<slangasek> note that it's only the hosts that *do* have link-local turned on that are reachable by this method
<slangasek> since hosts without link-local addresses will return their packets via their default route, not to the host that sent them
<slangasek> hrm - except, the host that Patty was IRCing from doesn't have avahi, so now I'm confused :)
<[Relic]> Hello :)
<[Relic]> Anyone know if they will add the coretemp.c from the 2.6.25 kernel to the 2.6.24 one ubuntu uses in the very near future (next kernel update) so we 45nm users can watch our coretemp and use very heavy load programs w/o worrying about burning out our cpus?
<joaopinto> [Relic], have you checked for bug reports about it ?
<kees> run avahi config defaults past lennart -- he's the one that originally specified them.
<mathiaz> kees: what's the reason to not enable cache on / ?
<kees> mathiaz: because it saves all kind of things like cookies, etc without additional tweaks, AIUI.  elmo might be able to speak more to this
<elmo> mathiaz: wtf - seriously?
<mathiaz> kees: one of the debian maintainer commented on bug 219914 and suggested another approach
<ubottu> Launchpad bug 219914 in apache2 "mod_disk_cache enabled globally by default" [Undecided,Confirmed] https://launchpad.net/bugs/219914
<mathiaz> kees: https://bugs.launchpad.net/debian/+source/apache2/+bug/219914/comments/8
<ubottu> Launchpad bug 219914 in apache2 "mod_disk_cache enabled globally by default" [Undecided,Confirmed]
<elmo> mathiaz: a2enmod cache should not start caching all my sites
<elmo> mathiaz: the fact that it does so currently is insane
<elmo> mathiaz: apache has a very powerful vhost-based config system for a reason
<elmo> mathiaz: (have you got a single counter-example of 'a2enmod' that globally changes behaviour?)
<elmo> (and FTR, Debian #407171 doesn't require CacheEnable /, it simply requires that the module be available
<elmo> )
<ubottu> Debian bug 407171 in apache2 "proxy stops working after upgrading from sarge" [Important,Closed] http://bugs.debian.org/407171
<mathiaz> elmo: right - I still think that we should *not* enable the cache by default
<mathiaz> elmo: just trying to figure out why it's so bad
<mathiaz> elmo: most of the modules enable things globally - such as negociation, etc...
<mathiaz> elmo: but this highly depends on the type of modules
<elmo> hmm, ok true
<mathiaz> OTOH the proxy.conf disables proxy requests by default
<elmo> right, for similar reasons
<mathiaz> for security reasons IIUC
<elmo> the reason it's so bad to enable caching is because it has security implications
<YokoZar> Why is http://cdimage.ubuntu.com/daily/current/ empty with broken links but http://cdimage.ubuntu.com/daily/20080624/ has isos for download?
<mathiaz> elmo: right - that would is the main point then - disk_cache should treated as mod_proxy because of the security implications
<mathiaz> kees: what do you think about the debdiff: http://people.ubuntu.com/~mathiaz/apache2_2.2.9-2ubuntu1.debdiff ?
<kees> mathiaz: I like it.  Good changelog.  :)
<mathiaz> kees: ok - I'll upload a new version of apache2 in intrepid
<kees> mathiaz: okay, great.  From there, SRU for slangasek?
<mathiaz> kees: yop
 * kees hugs mathiaz
<elmo> FWIW, in intreprid, it'd might be nice to do what sf suggested
<elmo> simply because enabling (in the mods-enabled/ symlink sense) disk cache means htcacheclean gets run
<elmo> which is surprising for folks who used proxy but not disk cache (the majority of folks coming from dapper where mod cache was essentially useless)
<elmo> but maybe sf will do that in Debian and so it's moot
<norsetto> kees: do you know why debian bug 374568 has been marked as won't fix?
<ubottu> Debian bug 374568 in eggdrop "eggdrop: SSL support" [Wishlist,Open] http://bugs.debian.org/374568
<kees> norsetto: openssl isn't compatible with GPL.  code needs exceptions, and eggdrop author doesn't want it.
<kees> norsetto: if it could get ported to gnutls we'd be golden.
<kees> norsetto: I haven't had time to do that, so I just compile it myself every release.  one of these days I'll get fed up with it.  ;)
<norsetto> kees: yes, I was wondering about that :-)
<norsetto> kees: I guess having two flavours of eggdrop doesn't make any sense then (one with and one without ssl support)
<slangasek> kees: how do I reach lennart to run this by him?  Another member of upstream is tracking that bug, but I don't see that Lennart subscribes to the ubuntu bugmail
<pitti> slangasek: mezcalero in #avahi
<slangasek> ok
<slangasek> when's a good time to catch him?
<pitti> slangasek: he just seems to do some commits, so I think he might still be awake
<slangasek> hmm, I'm on my way out the door in just a minute, though :)
<slangasek> I'll try tomorrow
<emgent> cjwatson: i think that Reinhard confused bug to ACK, see Bug #242550
<ubottu> Launchpad bug 242550 in ubuntu-flybook-support "Flybook V5 Fingerprint Drivers not avaiable (now) in Ubuntu." [Wishlist,Fix released] https://launchpad.net/bugs/242550
<cjwatson> emgent: look, I'm sorry, but some MOTU needs to put an ack in the actual sync bug itself or else we have to review it ourselves and personally I don't have time
<cjwatson> siretart: would help if you used full sentences rather than "ack" :-)
<emgent> sure np :)
<cjwatson> emgent: I'm more than happy for us to process properly-formed bugs, but the thing is that dealing with ones that aren't properly-formed takes time away from the others and I don't think that's fair
<mathiaz> kees: here is a debdiff for hardy-proposed - http://people.ubuntu.com/~mathiaz/apache2_2.2.8-1ubuntu0.3.debdiff
<mathiaz> kees: this one includes sf suggestion to not enable disk_cache on upgrade if it's not used in the configuration
<mathiaz> kees: as suggested by elmo, even if we disable / caching by default, htcacheclean would still be started every time
<mathiaz> kees: I'm not sure if it's acceptable for an SRU
<cjwatson> pitti: if you're still around, apparently chiark is having problems with piware.de's slave NS arrangements
<cjwatson> pitti: I'm told piware hasn't responded correctly since 24 May
<kees> mathiaz: I'd like to slangasek's input on it, but if it's tested, I'm happy.
<mathiaz> kees: ok - I'll attach the debdiff to the bug and ask for review by the SRU team
<kees> mathiaz: thanks :)
<mathiaz> slangasek: pitti: could you have a look at bug 219914 and comment on whether the changes in the debdiff are acceptable for an SRU ?
<ubottu> Launchpad bug 219914 in apache2 "mod_disk_cache enabled globally by default" [Undecided,Confirmed] https://launchpad.net/bugs/219914
<mathiaz> kees: I'm about to leave for the day - do you plan to finish the apache2 sru today ?
<mathiaz> kees: or this is work from tomorrow ?
<kees> mathiaz: I can work with slangasek to finish it up -- thanks for getting it prep'd
#ubuntu-devel 2008-06-25
<zul> im back as well
<zul> kees: ill upload it and do the testcase if you want
<zul> slangasek: sorry I wasnt available I was getting some dental work done and was at the dentist
<zul> slangasek: um dental work done and family commitments
<kees> zul: that'd be great, thanks.
<emgent> Hi ember
<ember> hey emgent, sup
<slangasek> zul: ah, so kees volunteered you sight-unseen, ok then... :)
<zul> slangasek: im trying to test the debdiff now after I get this dapper vm setup
<Rudd-O> guys
<kees> slangasek: well, I'd volunteered zul and mathiaz since they've had the most apache-touching recently and I was already swamped with equally time-critical things.  :)
<[Relic]> how long does it take between a report and the time someone actually looks at fixing something?
<StevenK> [Relic]: It depends, usually. What's the bug number, I'll have a quick look.
<[Relic]> basically it is snatching a c file from a newer kernel module and inserting to bring ubuntu 45nm core temp support  ->  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/235119
<ubottu> Launchpad bug 235119 in linux "Coretemp outdated / can't show 45nm core temps" [Undecided,New]
<StevenK> Ahhhh.
<[Relic]> I run blender which is CPU rendering so I really want to know my core temp.  I know multiple people have verified it can work if lm-sensors 3.0.2 sensors detect and the new coretemp.c with the model x17s are brought in
<[Relic]> I need a bigger back buffer when they do that  :(
<Rudd-O> can I float this idea guys? http://software-libre.rudd-o.com/Streams_vs._documents
<ScottK> Seems a bit OT here.  More of an upstream thing.
 * davidm is away: 
<pwnguin> Rudd-O: ever heard of plan9?
<RAOF> Rudd-O: Is that in response to bryce's blog post?
<calc> heh i got a bug report about openoffice from the head of osnews
<calc> the name sounded familar so i googled it and found out it was her
<StevenK> calc: In Launchpad?
<calc> StevenK: yea
<StevenK> calc: Bug number? :-)
<pwnguin> Eugenia?
<calc> 242557
<calc> yea
<pwnguin> bug #242557
<ubottu> Launchpad bug 242557 in openoffice.org "I can't uninstall openoffice without destroying my system" [Undecided,Invalid] https://launchpad.net/bugs/242557
<calc> probably should just find the original bug where it is filed and merge it rather than invalid
<pwnguin> calc: im not sure if it counts as invasion of privacy, but I found knuth's LP account
<persia> Polling it for activity is maybe an invasion of pricacy, but LP accounts have become part of our public faces.
<lamont> so... lets say that I have a raid 6 device that I want to do an install on, and an up-and-running hardy box to plug it into...  is there a wubi-like thing, or do I get to reboot the machine and do the install from there?
<emgent> morning people
<persia> lamont: debootstrap?
<lamont> well, yeah.
<lamont> I want all the rest of it to turn it into a hardy desktop machine
<lamont> preferrably without doing all those steps manually
<lamont> (because that sucks)
<lamont> (all 6  or 7 times I've done it before...)
<persia> OK.  debootstrap target; chroot target /bin/bash; apt-get install ubuntu-desktop
<lamont> that's about 16 steps short of clueful
<persia> Well, yes.  It could use a pretty GUI python wrapper, and misses a few bits.
<persia> How about booting the ISO in a VM attached to the device?
<lamont> "few".  heh
<persia> lamont: What?  Do you really want such niceties as a locale, or host definitions?
<lamont> default first user, partitioner, etc
<persia> Right.  `kvm -hdc /dev/sdq ubuntu-hardy.iso`
<RAOF> Or virt-manager.  I've found that nice.
<persia> Err `kvm -hdc /dev/sdq -cdrom ubuntu-hardy.iso`
<persia> RAOF: For installing Ubuntu Desktop on a bare RAID device?
<RAOF> Start the interface as root and I'm pretty sure you can use a raw device as the target.
<RAOF> kvm also works, of course, and may be more obvious given a browse of the man page ;)
 * pwnguin should try out kvm now that ubuntu-mobile is offering an image
<lamont> does the -generic kernel have kvm support, or does that require the kvm kernel?
<RAOF> -generic has kvm support.  Is there a kvm kernel?  Do you mean -xen, or -openvt, or something?
<persia> -generic supports kvm as a guest, and runs within kvm
<pwnguin> hmm
<pwnguin> Daniel T Chen 2005-08-07 Expired on 2007-08-16
<persia> Your hardware must support kvm though.  Otherwise virtualbox and kqemu are alternates (but you have to build your own kqemu modules from source)
<lamont> hrm... 3TB ext3 FS on RAID5 takes a while to create... :-(
<lifeless> win 20
<wgrant> It's such a badly named command.
<RAOF> Nah.  It's awesome.
<RAOF> lifeless: Can I win 30? :)
<lifeless> that would #squeak
 * StevenK wonders about Unicode code points for small caps
<dholbach> good morning
<dholbach> bryce: still there? :)
<pitti> Good morning
<StevenK> Morning pitti
<nxvl> good $TZ_TIME_OF_DAY
<pitti> cjwatson_: chiark> my server moved to a new IP, could that gbe it?
<pitti> cjwatson_: s/gbe/be/
<dholbach> tjaalton: do you keep X packages in bzr/git/something?
<dholbach> tjaalton: if not, I'm going to drop our patch on xserver-xorg-input-vmmouse (as the scaling was fixed in the new upstream release too and fixing the scaling twice broke the mouse in kvm for me)
<nxvl> pitti: oh, btw, i already upload the debdiff for openvpn
<pitti> nxvl: debdiff?
<pitti> it's a (fake)sync, isn't it? not much of a diff
<nxvl> Bug #242537
<ubott2> Launchpad bug 242537 in openvpn "Please sync openvpn 2.1~rc7-5 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/242537
<nxvl> pitti: yep, but i don't have any other way to upload my work
<nxvl> pitti: the diff is the debian changes aplied to our old package
<pitti> nxvl: ah, I see; heh, I could just have done it myself, but thanks
<nxvl> :D
 * pitti uploads
<nxvl> it was just a bitsize fix
<nxvl> just one line
<pitti> nxvl: uploaded
<nxvl> :D
<nxvl> thanks
<dholbach> hi seb128
<seb128> hello dholbach
<bryce> dholbach: yeah
<dholbach> bryce: did the xserver-xorg-input-vmmouse upload myself - hope that was OK
 * pitti hugs dholbach for the vmmouse fix -- the previous version drove me mad in intrepid :)
<bryce> dholbach: sure that's probably fine.  I was just looking at that bug earlier
<pitti> hey seb128, bonjour
<seb128> guten tag pitti
<DarKnesS_WolF> i'm trying to build a gdal package with gdal support but i am getting this error in hardy , feisty gutsy it did work fine
<DarKnesS_WolF> http://pastebin.ca/1055587
<DarKnesS_WolF> i'm building using that command dpkg-buildpacka
<DarKnesS_WolF> ge -rfakeroot
<DarKnesS_WolF> i'm building using that command dpkg-buildpackage -rfakeroot
<pitti> Riddell: oooh! https://svn.pardus.org.tr/uludag/trunk/PolicyKit-kde/
<pitti> Riddell: just read a mail on hal@ that it is near completion
 * ogra wonders why Keybuk set bug 98955 to fix committed ...
<ubott2> Launchpad bug 98955 in upstart "logd not running" [Medium,In progress] https://launchpad.net/bugs/98955
<berzerka> sorry for question not strictly related to ubuntu development, but i think you devs might be the only ones able to answer: how is the CAP_SYS_RAWIO capability handled in ubuntu? i am developing a userspace USB driver and read with ioctl from /dev/bus/usb/*/*. on my gentoo machine, no problem. on ubuntu i get "Operation not permitted" and the only thing i can imagine is that the RAWIO capability is disabled. on the other hand, it doesn't even
<berzerka> work using sudo. any ideas?
<dholbach> berzerka: you could try in #ubuntu-kernel
<berzerka> dholbach: oh, right. thank you!
<dholbach> np :)
<dholbach> thekorn: bug.activity is GREAT - thanks
<seb128> dholbach: what is that?
<dholbach> >>> import launchpadbugs.connector as Connector
<dholbach> >>> Bug = Connector.ConnectBug()
<dholbach> >>> bug = Bug(242667)
<dholbach> >>> print bug.activity
<dholbach> [<hito 2008-06-24 14:06:00 UTC 'bug'>, <ikuya-fruitsbasket 2008-06-24 14:24:00 UTC 'bug'>, <ikuya-fruitsbasket 2008-06-24 14:55:00 UTC 'bug'>, <arnegoetje 2008-06-25 07:17:00 UTC 'scim-anthy: status'>]
<dholbach> >>>
<seb128> dholbach: ah, nice ;-)
<thekorn> dholbach, oh, good to hear it's working and you like it
<thekorn> but this shows me that I have to update the wiki more often
<dholbach> :)
<cjwatson> pitti: could be - what's the new IP, and I'll pass it on?
<pitti> cjwatson: 213.9.93.70
<pitti> cjwatson: (host piware.de)
<cjwatson> pitti: ah yes, doesn't match slave0.ns.chiark.greenend.org.uk
<StevenK> Heh, wasn't piware moved like a week ago? :-)
<cjwatson> can take a little while to notice slave NS misconfiguration
<cjwatson> the cron job that whines about it on that system is weekly, I think
<StevenK> Ah.
<pitti> which reminds me, I should set the DNS TTL back to a day (currently an hour)
<Keybuk> ogra: because a "fix" has been committed ?
 * StevenK checks what his TTL is, since he recently moved his domain too
<dholbach> ArneGoetje: does the anthy patch apply for you? it doesn't for me
<ArneGoetje> dholbach: against the hardy version?
<ArneGoetje> dholbach: works for me
<ogra> Keybuk, well, removing the code is not actually what i would call a fix :)
<ogra> (unless i understood the upstream commit wrong)
<dholbach> ArneGoetje: sorry - my mistake, I'll update it to be "intrepid" instead of "hardy
<ArneGoetje> dholbach: ?
<dholbach> ArneGoetje: the changelog says 'hardy'
<dholbach> ArneGoetje: ah - we have a newer version in intrepid - that why it does not apply
<ArneGoetje> dholbach: correct
<dholbach> the patch needs a bit of updating then
<ArneGoetje> dholbach: in that case, I'll test if the bug still applies for intrepid
<dholbach> well, we can't upload to hardy any more (or it needs to follow StableReleaseUpdates)
<ArneGoetje> dholbach: bug fix?
<dholbach> still it'd be hardy-proposed instead of hardy and it needs to go into intrepid first anyway
<dholbach> https://wiki.ubuntu.com/StableReleaseUpdates
<ogra> MacSlow, 01_fix_missing_semicolon.patch ? thats sweet :)
<ArneGoetje> dholbach: my guess is that the issue has been fixed in intrepid already... but I'll check that
<MacSlow> ogra, mvo found that one actually
<Keybuk> ogra: it closes the bug
<dholbach> ArneGoetje: gracias
<ogra> Keybuk, it doesnt fix logging, so i'd disagree
<Keybuk> ogra: where "Fix Committed" means that the bug will be made invalid
<MacSlow> ogra, I didn't even see this failing initially with all the tons of output pbuilder creates
<Keybuk> since there's no "Something that will make this bug Invalid Committed" status ;)
<ogra> well, isnt it to be fixed in upstart in the end ? and isnt the final fix to have a proper boot log ?
<Keybuk> no
<MacSlow> ogra, Keybuk: I informed the debian maintainer and also filed a bug upstream with the patch attached... as it was still not fixed in trunk... odd isn't it... in over four months nobody ran into that
 * ogra doesnt get the logic
<ogra> MacSlow, well, i poked on that package quite often in the past and slangasek as well ... seems nobody of us ever spotted it
<MacSlow> are we meant to keep confflags-gnome and confflags-gtk in debian/rules for goffice? debian only uses confflags and does not make a distinction between gtk- and gnome-related flags.
<ogra> MacSlow, xubuntu :)
<ogra> they dont want gnome libs
<MacSlow> mvo, sorry for implicitly stealing your credit regarding the semicolon-patch regarding planner!
<MacSlow> ogra, so how should I go about merging that? just put everything in confflags?
<ogra> MacSlow, ask one of the xubuntu people i'd say, they likely have touched that before and created that diff
<mvo> MacSlow: no worries
<seb128> you likely want to keep the ubuntu changes the way they are
<ogra> not sure if there is more involved than confflags
<seb128> debian doesn't build a gtk variant
<ogra> there might be additional patches
<MacSlow> hm... ok... gnumeric is a tougher beast than anticipated... goffice (newer version needed for gnumeric) looks nasty to me merge-wise
<mvo> ogra, MacSlow: it seems to be releated/triggered by the new glib
<Keybuk> ogra: I don't really have any solution for logging yet
<MacSlow> mvo, yes... dependencies of goffice introduced the need for a newer glib
<Keybuk> removing the claim of the feature is the best fix for now
<ogra> Keybuk, yeah understood, i just didnt get the logic first place
<MacSlow> seb128, hm... debian enables static libraries for goffice... do we want that too?
 * MacSlow assumes not
<seb128> usually we want what debian do if we don't have strong reason to not take the changes
<ogra> there might be an entry in the changelog explaining it ;)
<Keybuk> ogra: Fix Committed is a silly status really
<Keybuk> at least, according to the LP model
<ogra> yeah
<Keybuk> you should be able to add bug tasks for a branch
<Keybuk> then that branch could be marked Invalid/Wont Fix or something
<ogra> well, cant you just mark it Invalid and make it hishlist for a new app ?
<ogra> *whishlist
<Keybuk> then when I make a release on that branch, the bug status should be automatically copied to the task for the upstream package
<seb128> Keybuk: it's not when you have the packaging in bzr and if launchpad was updated automatically on commit
<Keybuk> seb128: err, ?
<Keybuk> seb128: that doesn't make what I said invalid
<seb128> <Keybuk> ogra: Fix Committed is a silly status really
<seb128> that was a reply to that
<Keybuk> seb128: the next line is more important ;)
<seb128> right, but I was typing then ;-)
<Keybuk> in your use, and my model, committing would set the branch bug task to "Fix Released"
<seb128> right
<Keybuk> releasing would set the upstream bug task to "Fix Released"
<Keybuk> packaging would set the distro bug task to "Fix Released"
<seb128> hum, not really
<Keybuk> Fix Committed is silly because you can do more than commit Fixes :p
<seb128> fix released is when the update is pushed in the distribution
<Keybuk> right, that's what I mean - couldn't think of a good word :P
<MacSlow> what does the -i option in dh_<command> in debian/rules?
<cjwatson> man debhelper
<cjwatson> MacSlow: ^-
<cjwatson> Keybuk: "fixed" would do it ...
<MacSlow> cjwatson, ah thanks
<Keybuk> cjwatson: ?
<MacSlow> seb128, for goffice we still don't want -dbg pakcages?! that's currently stated in a comment in goffice's debian/rules
<cjwatson> Keybuk: for a branch status, "fixed" would be sufficient and clearer, and would avoid seb's "is when the update is pushed in the distribution" objection which I guess is due to the "released" word
<Keybuk> cjwatson: ogra disagrees that "fixed" is clear
<cjwatson> ogra: oh?
<Keybuk> cjwatson: an upstream upstart bug is marked "Fix Committed"
<cjwatson> Keybuk: oh, I'm not objecting to "invalid" also being an option
<Keybuk> because trunk no longer has any code relevant to the bug, so will make it Invalid
<Keybuk> ah
<Keybuk> got you
<cjwatson> ogra: (never mind)
<Keybuk> yeah if you get rid of "Fix Committed" then you can rename "Fix Released" to just "Fixed"
<cjwatson> right, that's what I mean
<Keybuk> which is a much better name without any nasty overtones of "go get it now, pull, pull"
<seb128> MacSlow: not sure, I've no real opinion either way
<seb128> MacSlow: we have dbgsym so we don't need those, and since the ubuntu version builds several variants the dbg build might require changes
<MacSlow> ok
<ArneGoetje> dholbach: the bug still exists in intrepid
<dholbach> so in any case it needs fixing in intrepid first and the patch needs some changes
<wgrant> pitti: You said in bug #228969 that libcairo was gone from Intrepid, but it survives to this day.
<ubott2> Launchpad bug 228969 in libcairo "Remove libcairo from Ubuntu" [Wishlist,Fix released] https://launchpad.net/bugs/228969
<pitti> wgrant: weird; I was sure I saw it in process-removals, hmm
<pitti> wgrant: doing again then
<wgrant> pitti: Soyuz does seem to often have issues with overrides, removals or syncs not sticking...
<wgrant> Thanks.
<pitti> done
<munckfish> TheMuso: hi, did you see mail about the PS3 kernel yesterday?
<ArneGoetje> dholbach: the patch itself (debian/patches/06_fix_vu_dpatch.dpatch) also works against the intrepid version and fixes the issue
<dholbach> ArneGoetje: right... the debdiff needs updating
<ArneGoetje> dholbach: I will make a new debdiff for intrepid
<seb128> ArneGoetje: I think I synced scim-hangul a bit too quickly the other day and some changes were still required, could you have a look and maybe reapply those if that's the case since you probably know better about those
<ArneGoetje> seb128: err... ok, I'll try
<dholbach> ArneGoetje: ROCK
<ArneGoetje> dholbach: ?
<dholbach> ArneGoetje: "great" :)
<ArneGoetje> dholbach: ah :D
 * ArneGoetje -> dinner, bbl
 * pitti arghs at Python's optparse, which suddenly yields a "UnicodeDecodeError: 'ascii' codec can't decode byte" blabla exception
<pitti> (suddenly -> after .mo files got installed)
<ogra> blabla exception ? oh, thats an evil error :)
<pitti> after some googling it seems I need to do some black magic with setting sys.stdout to a codecs wrapper, or something
<pitti> but heck -- why should I even care???
<DarKnesS_WolF> i'm building using that command dpkg-buildpackage -rfakeroot
<DarKnesS_WolF> http://pastebin.ca/1055587
<DarKnesS_WolF> any idea ?
<DarKnesS_WolF> this is gdal package from apt-get source gdal
<dholbach> .
<ogra> ;
<ion_> Ø
<cjwatson> DarKnesS_WolF: seems like a bug, if you're building it on the version of Ubuntu it was released for with all the build-dependencies installed
<geser> DarKnesS_WolF: you have a lib in /usr/local/lib which gdal links against
<cjwatson> oh yes, I can't read
<cjwatson> pitti: see e.g. http://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu/annotate/cjwatson%40canonical.com-20080620095615-rf3zpj1maa556ro1?file_id=helptogfxboot.py-20071128181623-fb6n7sukjr5u2r1p-4
<pitti> cjwatson: I saw some similar recipes, but those were all hacks which hardcoded a particular encoding
<pitti> cjwatson: I think it is http://bugs.python.org/issue2931
<pitti> I haven't tried the patch yet
<pitti> (hm, that wasn't it)
<pitti> cjwatson: thanks for the pointer, anyway!
<pitti> cjwatson: I don't see why I should even care in my Python programs (from a 10,000 m perspective)
<pitti> the output encoding is determined by the locale, and the input encoding is given in the .mo files and thus by gettext
<cjwatson> pitti: replacing 'UTF-8' with locale.getpreferredencoding() should deal with the hardcoding objection (not tested though)
<cjwatson> pitti: and I certainly agree the current situation is hopeless
<pitti> oh, good idea
<cjwatson> pitti: see also http://ewx.livejournal.com/457086.html for the last time I remember discussing this
<zul> monining
<pitti> cjwatson: hm, it still fails even with your recipe; *gnargh*; anyway, I'll try again after lunch
<ogra> could someone poke MOM to get a fresh overview ?
<Keybuk> ogra: ? mom is running fine
<Keybuk> last update was 11 minutes ago
<ogra> Keybuk, how often ? would be good to raise the frequency
<Keybuk> hourly
<ogra> at least on days before import freeze that makes the overview easier
<ogra> hmm
<ogra> k
<Keybuk> the frequency is not limited by malaise
<ogra> well, i still see ltsp and moodle on there
<Keybuk> how long ago did you upload the merged packages?
<Keybuk> moodle has not yet been published
<ogra> moodle was 15mins ago, ltsp 1h
<Keybuk> ltsp was only published 20 minutes ago
<cjwatson> MoM can't really run faster than the publisher ;-)
<ogra> bah, add a time machine :P
<Keybuk> when MoM runs at 1105Z, it will see ltsp in the archive (assuming the mirror happens by then)
<ogra> right
<ogra> thats enough then
<Keybuk> it will pick up moodle once that has been published and mirrored, which may be as early as 1105Z, but may not
<ogra> yeah
<Keybuk> the average MoM run takes between 50 and 70 minutes right now
<Keybuk> so it really can't go any faster
<ogra> i'm just lazy and dont want to compare changes with MoM all the time to find what to grab and whats gone
<ogra> *-changes
<Keybuk> actually, the 1105Z was cancelled due to lock
<Keybuk> so the next run will be 1205Z (the 1005Z only just finished)
<Keybuk> ogra: surely you have a vague idea which source packages you've touched in the last couple of hours? ;-)
<ogra> Keybuk, mine are done, i'm starting to grab others
<kwwii> mvo: erm, there seems to be a problem with the changelog of the ubuntu-artwork package (dch complains that the maintainer field is empty)
<kwwii> mvo: as you were the last one to update it, I thought I should ask you ;-)
<mvo> kwwii: let me check
<kwwii> mvo:  just look at the last two changelog entries and you'll see the problems
<Keybuk> bryce: so, err, around/
<Keybuk> I'm having a little X problem
<mvo> kwwii: please update, I fixed it in bzr
<mvo> kwwii: the " -- author ..." line was empty, emacs is less picky about it, I guess this is why I forgot about it
<kwwii> mvo: excellent, thanks for the help :-)
<kwwii> how in the hell is one supposed to use bzr with launchpad these days? the crappy lp:~path stuff is simply confusing and shitty
<kwwii> boah, sorry for going off but this is silliness
<Keybuk> ?
<Keybuk> bzr branch lp:upstart
<kwwii> how is it that when I do a pull, make changes, commit and then try to push and it gives me grief about using http?
<Keybuk> saves remembering a URL
<kwwii> the lp stuff is exactly what is messing it up it seems
<Keybuk> because you don't have permission to push to that branch?
<Keybuk> what's the branch?
<kwwii> no, I do
<Keybuk> did you at the point you branched?
<kwwii>  lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu
<kwwii> yepp
<Keybuk> bzr info says?
<james_w> kwwii: you need to run "bzr lp-login <lp user id>" I expect
<kwwii> kwwii@clive:~/bzr/test/u-art$ bzr push lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu
<kwwii> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-art-pkg/ubuntu-artwork/ubuntu/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<james_w> kwwii: and then "bzr push --remember lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu"
<lifeless> kwwii: bzr launchpad-login
<james_w> newer bzr gives you a hint about this.
<kwwii> I just pushed another branch under ~ubuntu-art-pkg and it worked fine
<Keybuk> lifeless: doesn't it use $USER if not set?
<lifeless> Keybuk: no
<Keybuk> lifeless: isn't that a bit silly?
<lifeless> Keybuk: root cause - because it doesn't fallback to http on ssh login failure
<lifeless> Keybuk: hey, $code-I-didn't-writely-urs
<lifeless> Keybuk: or a better answer - incremental improvements
<lifeless> Keybuk: if the non-fallback bug is fixed, using $USER becomes plausible
<wgrant> But wouldn't that mean it would ask all conceivable key passphrases even if you didn't have an LP account?
<ogra> kwwii, do you have  launchpad_username set in ~/.bazaar/bazaar.conf ?
<Keybuk> random bug of the day
<Keybuk> bootchart still runs in recovery mode
<ogra> hey, then you can see how fast you get to the rootshell ... thats a feature :P
<Keybuk> ogra: and you see how long you were in the root shell
<Keybuk> and you see what you did while there, and how long that took
<Keybuk> and then you see how long the rest of the boot took after you resume
<ogra> hehe
<Keybuk> and then you see your disk full with a massive svg
<cjwatson> kwwii: you can continue to use the old-style bzr+ssh:// URLs
<cjwatson> kwwii: replace lp: with bzr+ssh:// in the above and it should work (as a means of getting you past the immediate problem)
<cjwatson> Keybuk: stop viewing your porn in recovery mode
<ogra> lol
<Keybuk> cjwatson: I'm trying to get X to work :-/
<ogra> and get a bigger disk ...
<Keybuk> maybe usplash related
<donri> is there any interest in making luks accessible to the masses in ubuntu?
<donri> seems rather quiet on launchpad, https://blueprints.launchpad.net/ubuntu/+spec/ubiquity-luks-support
<cjwatson> donri: that's blocked on general support in ubiquity for other than plain block devices
<cjwatson> donri: we do need to do that anyway, e.g. for dmraid-support, but it's hard to give much attention to ubiquity-luks-support until that's in place
<donri> cjwatson: sorry, what? I don't understand.
<cjwatson> donri: plain block devices == /dev/sda1 and such
<cjwatson> as in ordinary hard disks
<cjwatson> in order to support luks, ubiquity needs to have support for more complicated block devices in general
<donri> ok...
<cjwatson> which is a fair amount of work to put in place, although it is on the plan
<donri> i see, that's good.
<SEJeff> soren, ping from yesterday. I misread the patch for libvirt. Please ignore the comment in #ovirt
<wgrant> cjwatson: Hasn't that been targetted to every release greater than or equal to Edgy?
<ogra> wgrant, and you still didnt send a patch :(
<soren> SEJeff: Alright, cool :)
 * soren goes to lunch
<SEJeff> soren, FYI: I'm trying to get ovirt wui running in Ubuntu. We'll see
<ogra> is anyone doing hotkey-setup  ?
<wgrant> ogra: I wasn't exactly complaining. Just wondering if it really was still coming RSN.
<ogra> wgrant, sure, it will if someone sends a patch (hint hint) ;)
<ogra> wgrant, its not that we dont want to do it, its a manpower issue
<donri> cjwatson: in which upcoming ubuntu release do you estimate it might be included?
<lool> lamont: Could you please add virtualbox-ose in Pas to lpia?
<lamont> lool: "# Please email comments, corrections to james@nocrew.org, lamont@debian.org and/or adconrad@debian.org.  See ChangeLog for history."
<lamont> for tracking purposes and all that
<lool> Okay
 * lamont finds himself annoyed at the encrypted filesystem stuff
<lool> lamont: Mailed
<cjwatson> wgrant: *cough*
<lamont> "/boot/grub/stage1 not read correctly"
<cjwatson> wgrant: actually not so much for edgy because we knew it was blocked on the partitioner reimplementation
<cjwatson> donri: hard to say at present, sorry; I think intrepid+1 would probably be a decent guess
<lamont> lool: updated
<lool> lamont: Thanks; when do Ubuntu buildds notice?
<lamont> lool: that'd be an infinity question (in about 3.5 hours when he should be around)
<lamont> the answer for debian is "generally within 24-48 hours"
<lamont> not sure how quickly ubuntu will notice
<lool> lamont: Ok; as long as it's automatic, I don't care
<lamont> entirely
<jdstrand> lucas: hi. I am doing the ruby1.9 merge for ubuntu, and was doing a schroot amd64 intrepid build before upload, and found that it hangs at test_copy_stream_rbuf(TestIO). Have you seen this before? (I saw your name in the changelog of the Debian package)
<jdstrand> \sh: ^ have you seen this in your previous merges?
<donri> cjwatson: so 9.04? that's good, it's in october 2009 scary things start happening in sweden.
<cjwatson> donri: this isn't a commitment, just my guess as to when we'll have available time
<lucas> jdstrand: no, I never saw that
 * jdstrand scratches head
<jdstrand> lucas: ok thanks
<donri> cjwatson: of course, it isn't an obligation. I just think it would be very good, for sake of others. I personally already have a LUKS setup, but less technical people are likely scared away by lengthy technical guides.
<wgrant> donri: The alternate installer isn't too terrible, and does LUKS.
<donri> I see lots of windows survivors trying out Ubuntu, and I think security is important. Especially in these days, especially here in sweden.
<donri> wgrant: from what I understood from the wiki, it does dm-crypt and not luks/cryptsetup?
<wgrant> donri: It does LUKS.
<wgrant> Though it does support dm-crypt for random swap keys, IIRC.
<donri> cool. still, windows survivors who "just surf and chat" likely think it is "too terrible"? I haven't tried the alternate installer though, admittedly.
<donri> Does the boot process of ubuntu itself support luks or does it only work for non-root partitions?
<wgrant> donri: I run LVM on LUKS for everything but /boot.
<donri> Yea, encrypting /boot isn't easy ;)
<siretart> it is: boot from USB
<donri> but can you have the stick encrypted then?
<donri> anything something has to be non-encrypted, eh?
<ogra> donri, as i said to wgrant above, every helping hand will speed it up ;)
<siretart> donri: no, the stick is removable, so no need to encrypt it
<donri> then you have to guard it 24/7 ... if you're paranoid. :P
<\sh> jdstrand: nope..
<donri> ogra: what could I do?
<ogra> donri, talk to the ubiquity maintainer, he might know ... even if people dont work directly on the luks implementation but help out with other stuff that means he can get his hands free earlier :)
<ogra> donri, evand is the ubiquity master ...
<donri> evand: ping :)
<evand> donri: tbh, help would require a understanding of partman internals, though anyone with that knowledge is welcome to take a shot at the ubiquity portion of https://wiki.ubuntu.com/EncryptedFilesystems, and if they're successful I'll merge the branch.
<cjwatson> ah yes, that ubiquity-luks-support spec probably ought to be marked as superseded by encrypted-filesystems ...
<wgrant> Who has the power to alter blueprints like that?
<cjwatson> ubuntu-drivers
<cjwatson> and the blueprint assignee/drafter/approver
<slangasek> ogra: what package am I supposed to have poked at? planner?  I don't think I've ever poked very deep at that one. :)
<cjwatson> I don't want to Just Do It though, the wiki page should be checked for useful things that could be in the EncryptedFilesystems wiki page
<cjwatson> (but preferably not random implementation guesses from somebody who doesn't know the current implementation)
<ogra> slangasek, i didnt say deep :)
<jdstrand> kees: I don't suppose ruby1.9 was in the list of packages that FTBFS with your compiler hardening, was it?
<wgrant> cjwatson: So bugs are very publicly editable but specs are ridiculously restrict beyond even the development team?
<cjwatson> wgrant: not my idea
<ogra> slangasek, but many people have touched it and nobody noticed the build error ever :)
<ogra> slangasek, i stole moodle from you if you noticed
<cjwatson> wgrant: IMO the practical solution is to stop this pernicious meme of telling people who file wishlist bugs to write specs instead ...
<wgrant> Blueprint does seem to be pretty much dead these days.
<cjwatson> which I have been complaining about for years
<wgrant> cjwatson: I've only seen some novice triagers doing that recently.
<cjwatson> maybe my complaints found some ears
<wgrant> Hopefully.
<wgrant> And hopefully Blueprint will see some development post-2.0...
<Rudd-O> guys
<Rudd-O> can I interest you in a speculative development direction?
<Rudd-O> http://software-libre.rudd-o.com/Streams_vs._documents
<wgrant> Didn't bryce blog about that a few hours ago?
<ogra> yep
<ogra> its on planet.ubuntu.com
<pitti> cjwatson: hah! I didn't get it to work with your recipe, but finally I found something simple: http://bazaar.launchpad.net/~pitti/jockey/dbus-backend/revision/348
<SEJeff> soren: ping. When you get back from lunch can you hop in #ovirt for a q & a with some redhat guys?
<slangasek> kees: I thought there was supposed to already be a fix for bug #219914 in intrepid, did I misinterpret comments yesterday?
<ubottu> Launchpad bug 219914 in apache2 "mod_disk_cache enabled globally by default" [Undecided,Confirmed] https://launchpad.net/bugs/219914
<slangasek> (the bug is still marked "confirmed" for intrepid)
 * ogra WOAHs loudly seeing https://lists.ubuntu.com/archives/ubuntu-users/2008-June/151143.html
<ion_> ogra: :-D
<Rudd-O> wgrant: yes, bryce blogged about it.  bryce's blog post sparked my article.
<Rudd-O> wgrant: in fact, it's the starting point
<wgrant> Rudd-O: So I noticed when I read your article.
<wgrant> ogra: Nice. Very very nice.
<fta> stgraber, i'm having troubles with pastebinit in intrepid: http://paste.ubuntu.com/22865/
<stgraber> fta: known bug, we have a potential fix in our bzr branch
<stgraber> fta: If you would like to test it, just download it from : https://code.launchpad.net/~pastebinit-developers/pastebinit/trunk
<fta> stgraber, when is the next upload planed ?
<stgraber> pastebinit is now packaged and maintained in Debian, so I'll see with the Debian maintainer
<stgraber> it'll be in Intrepid for sure, I don't know when though
<fta> ok
<pitti> kirkland: would you mind marking https://code.edge.launchpad.net/~kirkland/jockey/kirkland.214914 as merged or obsolete?
<cjwatson> pitti: ah, yes, that would work as long as all your output is via _
<kirkland> pitti: yeah, sure
<kirkland> pitti: it's obsolete, i think you solved that problem differently than the patch i suggested
<kirkland> pitti: branch "deleted"
<wgrant> ogra: Look what you've got yourself into now with that XFree86 guy...
<Koon> wgrant: I've posted an hardy debdiff for bug 242690
<ubottu> Launchpad bug 242690 in pam-pgsql "<Ctrl+C> might allow to bypass authentication" [Unknown,Fix released] https://launchpad.net/bugs/242690
<Koon> wgrant: do you need a specific update for gutsy or will this one do ?
<Koon> (though the FTBFS patch I had to apply for hardy is hopefully superfluous for gutsy)
<ogra> wgrant, well, i have some desease we call the "helper syndrome" in germany :) i feel pity for him :)
<wgrant> ogra: Well, yes, but this is particularly nasty...
<wgrant> Koon: You'll need to supply a separate debdiff for each, in general. Make sure you give each a unique version number.
<Koon> wgrant: ok, will do.
<wgrant> Koon: Because we have the same version in multiple releases, the Hardy version should be 0.6.3-0ubuntu1.8.04.1, Gutsy 0.6.3-0ubuntu1.1.7.10.1, etc.
<wgrant> Er, I put an extra .1 in the Gutsy version.
<wgrant> 0.6.3-0ubuntu1.7.10.1
<ogra> wgrant, well, but not unsolvable, see my last mail ;) who knows, probably that works
<Koon> wgrant: got it :)
<wgrant> ogra: We can hope.
<pitti> kirkland: ah, or that; cheers
<slangasek> seb128: so do you have any more insight wrt my last comment on bug #207072?  is there some way to make gnome-panel happy here, while still making do_mount DTRT?
<ubottu> Launchpad bug 207072 in gvfs "nautilus does not display samba shares for machines inside an ADS network." [High,In progress] https://launchpad.net/bugs/207072
<slangasek> btw, I think I've found another regression, in at least the latest version of my patch; browsing workgroups seems to no longer work
<seb128> slangasek: I've to run now, but nothing trivial that I know, the right way would be to use the async api
<seb128> and libgnomeui has a similar issue
<seb128> the fileselector widget
<slangasek> seb128: so those are fixes that would have to be made to gnome-panel and libgnomeui, ok :/
<seb128> yes
<slangasek> then I guess we'll have to scrap this for .1
<seb128> I guess so :-(
<seb128> or use your first version
<seb128> which doesn't do the libsmclient call and try password before anonymous
<slangasek> I think that "my" first version still has the same problem
<seb128> if that doesn't trigger password prompts for bookmarks, I didn't try
<seb128> alright, so no easy fix before 8.04.1
<slangasek> because it does the smbc_opendir() on mount
 * slangasek nods
<seb128> anyway I've to run, see you later
<Lrrr> cjwatson: ping?
<Lrrr> nvm...
<slangasek> bryce: I realize that we haven't had any sort of official freeze announcement for intrepid alpha-1 because we've been so scattered, so not to pick on you at all, but please don't change any more X dependencies in the next couple of days; it makes it hard to get releasable alternate CDs when xserver-xorg-video-all picks up new dependencies on drivers that haven't been promoted out of universe yet :)
<bryce> slangasek: oh, sorry about that
<slangasek> n/p, just means iterating the CDs again after the next publisher run
<bryce> slangasek: the xorg change was the only remaining big piece I wanted to get in for alpha-1
<slangasek> sure
<slangasek> so actually, to amend the above - if yo have any other X dependencies that need changing, please let me know when you upload :-)
<bryce> for some reason based on last week's meeting, I thought we had until Thursday
<bryce> ok will do.  I also have a libx11 xcb change, but that'll be for hardy not intrepid
<slangasek> I'm hoping to be able to /release/ alpha-1 this thursday
<slangasek> since otherwise we run up against the 8.04.1 release itself
<bryce> okie doke.  I was planning on mainly focusing on bugs for a bit anyway.  I'll keep in mind not to hold uploads for a bit.
<kees> jdstrand: it wasn't in gcc 4.2 -- is it blockeded on a FTBFS in intrepid now?
<kees> slan	I thought mathiaz uploaded the fix to intrepid?
<kees> slangasek: ^^  (irssi lag fail)
<slangasek> kees: well, apparently he has done so now, I just got a bug closure mail :)
<kees> slangasek: ah-ha, excellent.
<stgraber> Riddell: bug 238839, any idea what's causing it ?
<ubottu> Launchpad bug 238839 in italc "ICA process started multiple time in KDE" [Undecided,New] https://launchpad.net/bugs/238839
<Riddell> stgraber: sounds like ICA should be intelligent enough to quit when it is started and other instance is already running
<stgraber> Riddell: it shows a warning message so that's not good
<Riddell> replace the warning with a quit then
<stgraber> and I don't see why KDE's session restore thing starts ica when it's originally been started from an autostart ...
<stgraber> things autostarted shouldn't be stored in the list of applications to restore at next login
<Riddell> other apps don't have any problems with it
<jdstrand> kees: well, my schroot ruby1.9 build doesn't work right, but the dchroot on ronne seems ok
<jdstrand> kees: the ronne build just finished btw, so that's info hot off the press
<exodos> In some situations it is needed to run 32bit userland with 64bit kernel (we're running hardy under xen like this). Now you have to download deb packages and manually issue dpkg -i --force-architecture *.deb. In debian, in 32bit repositories they have package called linux-image-2.6-amd64, which is installing the latest 64bit kernel. Would it be possible to add similar funcionality to ubuntu?
<kees> jdstrand: what failures are you seeing there?
<exodos> with Apt Super Cow Power life is much easier....
<kees> (in your chroot, I mean)
<joaopinto> exodos, if you need a 32 bits userland on a 64 bits system, you do a full 64 bits install, and do a chrooted 32 bits install
<jdstrand> kees: it actually builds fine, but one of the tests fails. it is an innocuous looking little thing
 * jdstrand goess and gets it
<kees> jdstrand: arch-sensitive?
<kees> jdstrand: how long is the build/test cycle?
<jdstrand> kees: well, amd64 schroot, and amd64 dchroot (ronne) act different, so I dare say no
<kees> fortify has been known to cause runtime issues for unusual code.
<jdstrand> kees: I'm kinda leaning toward my schroot not being right
<jdstrand> kees: interesting, but I should have seen that in dchroot with dpkg-buildpackage-- correct?
<kees> I can kick one off to check too -- anything special I need to do, or just build what's in the archive?
<kees> jdstrand: I'd think so -- is the chroot up to date?
<jdstrand> kees: try building the sid version on intrepid
<jdstrand> (I was doing a merge)
<jdstrand> it has the security fixes in it, and import freeze is tomorrow
<jdstrand> kees: oh, and it doesn't take too terribly long to build
<kees> jdstrand: okay, I'll kick it of
<kees> ruby1.9 1.9.0.2-1 ?
<jdstrand> kees: yes
<kees> jdstrand: kicked.
<jdstrand> kees: the test that just hangs is test_copy_stream_strio_rbuf in test/ruby/test_io.rb
<jdstrand> kees: http://paste.ubuntu.com/22893/
<kees> while it's probably not related, I've had to set things like virtmem limits to get some builds from eating my system alive (gcc-4.3, I'm looking at you).
<jdstrand> kees: oops, I meant test_copy_stream_rbuf
<jdstrand> kees: http://paste.ubuntu.com/22894/
<jdstrand> kees: anyway, it certainly doesn't look like it should hang, but it does...
<jdstrand> kees: my ruby foo is amazingly low (but growing as of late), so I'm still working through it
 * jdstrand wonders if the dchroot is up to date
<liw> this is a bit embarrassing... but what am I doing wrong? I took a package that uses dpatch, modified debian/rules and a few other files (none of the patch files), and now I can't run dpkg-buildpackage, because dpkg-source complains that the debian/patches/*.patch files change permissions and this is unrepresentable in a diff
<liw> dpkg-buildpackage calls debian/rules clean, which calls dpatch, which changes the permissions, but how do I handle this?
<ion_> That should not be a problem, just a warning. #ubuntu-motu is the correct channel for continuing this discussion, btw.
<cjwatson> liw: what's the error?
<cjwatson> literally, I mean
<liw> oh, oops, sorry, I should start reading errors from the top
<liw> I had a binary file change in there, too
<liw> works now, thanks
<saftsack> http://rafb.net/p/guZU8e56.html
<cjwatson> saftsack: #ubuntu-kernel, or a bug report
<saftsack> cjwatson, kk thank you
<kees> jdstrand: that test hangs for me too.  :(
<geser> mathiaz: Hi, I've seen that you uploaded apache2 to hardy-proposed. Please do also a rebuild-only SRU of apache2-mpm-itk (universe) so it gets rebuild with apache2 from -proposed.
<mathiaz> geser: that needs to be acked by the motu-sru team IIRC
<mathiaz> geser: could you file a bug for it (so that it doesn't get lost ?)
<geser> mathiaz: can do
<jdstrand> kees: ok, is is updating the dchroot (it had 555 updates)
<jdstrand> s/is is/IS is/
<jdstrand> kees: I'm going to try it on hardy, and in the dchroot on ronne (when it gets done updating)
<geser> mathiaz: bug #243012
<ubottu> Launchpad bug 243012 in apache2-mpm-itk "[SRU] apache2-mpm-itk uninstallable with apache2.2-common from hardy-proposed" [Undecided,New] https://launchpad.net/bugs/243012
<jdstrand> kees: 1.9.0.2 built fine on hardy
<jdstrand> kees: here is the list of packages that were updated http://pastebin.ubuntu.com/22928/ (gcc is among them)
<kirkland> slangasek: pitti: hiya, pam+debian_policy question for you......
 * slangasek hides under a pile of SRU paperwork
<kirkland> :-)
<kirkland> slangasek: shall i just email you and you can respond in due time?
<slangasek> depends, how deep of a question is it? :)
<kirkland> slangasek: i think it's the typical one where i say, "hey i have a way to do $foo", and you say, "nope, that way to do $foo is highly illegal" and you bop me over the head with a whack-a-mole padded bat
<slangasek> oh, ok - we can do that on IRC then :-)
<kirkland> slangasek: i'd like to know the best way to echo "auth required pam_ecryptfs.so unwrap" >> /etc/pam.d/common-auth && echo "password required pam_ecryptfs.so" >> /etc/pam.d/common-password
<slangasek> kirkland: ... by not doing so ;)
<kirkland> slangasek: i think that debian policy would forbid me from modifying those files in the ecryptfs pam package
<slangasek> yes
<slangasek> jdstrand has a package that lets users enable particular pre-formed pam profiles
<kirkland> slangasek: interesting, okay, so it absolutely has to be a manual operation by the administrator?
<slangasek> I have a plot to reorganize how /etc/pam.d/common-* are managed, which I hope to implement in time for intrepid but this is still up in the air
<mathiaz> kirkland: slangasek is refering to the auth-client-config package
<slangasek> also, the trivial >> here may not work as expected
<kirkland> slangasek: sure, that was for irc-simplicity only
<slangasek> ok :)
<kirkland> slangasek: the shell script i have greps and seds things around to make sure it gets put in the right place in the stack, that there aren't more than one, etc.
<kirkland> slangasek: but it's no where close to being acceptable
<slangasek> right, to know what the right place is in an arbitrary stack, you basically need all the information you don't have yet because I haven't done my config rewrite
<slangasek> hmm, maybe I could get the design for this fleshed out to where I could pawn the implementation off on you? :)
<kirkland> slangasek: :-)  perhaps.........
<slangasek> since you seem to have a fetis^W affinity for hard PAM problems ;)
<kirkland> slangasek: ugh, yeah, seems that way lately, doesn't it?
<ion_> Ew, my fonts became blurry after a fontconfig update. It doesnât seem to recognize lcdfilterlegacy anymore. :-(
<kirkland> mathiaz: okay, thanks for the pointer, i'll go look at auth-client-config
<ogra> slangasek, not getting -nsc and -geod in will cost us a lot LTSP users
<ogra> (we are the leading distro here, and slowly lose out on others due to not supporting the most commonly used X server since gutsy)
<slangasek> ogra: and therefore I should compromise the integrity of the SRU process to shoehorn in a last-minute, badly-done update with no justification given for part of the changes?
<ogra> slangasek, a lot of people have tested the packages from Q-Funks PPA and i doubt you can introduce a regression for something that didnt work at all before
<slangasek> where does it say that the nsc package didn't work before?
<slangasek> that's not written in the SRU bug log, in the changelog, or in the patch header
<ogra> slangasek, well, i was hoping it would turn out good in the end, i have a good bunch of users waiting for the 8.04.1 CD for building their new LTSP
<slangasek> it says that there's one particular PCI ID that nsc wrongly claims to support
<slangasek> I'd be fine if dropping that ID was the only change being made
<ogra> geode was completely borkesd since mid of the gutsy cycle
<slangasek> I'm not talking about geode.
<ogra> nsc and amd as well afaik
<slangasek> I still need to review the geode SRU; this one is already in -proposed, and is well on its way - if there are any issues with it, we're better off fixing those now and following through on that SRU
<ogra> anyway i just wanted to raise that to your attention ... the decision is yours indeed and i largely agree with you but still am sitting between the chairs here
<slangasek> but the nsc upload is not ok to shove in at the last minute
<slangasek> not without a more substantial justification, and more substantial evidence that it doesn't regress anything
<sbeattie> ogra: it'd be useful if your users could try out the packages and report feedback on the bugs.
<sbeattie> (packages in -proposed, that is)
<ogra> sbeattie, well, they have systems in production ... people with ltsp test envs are very rare
<ogra> and most of them still run feisty because of that breakage
<sbeattie> yet they're willing to run a PPA?
<slangasek> sbeattie: the package at issue here is one I'm not accepting into -proposed, because it's been uploaded well after the 8.04.1 freeze
<slangasek> the -geode package is fine - it looks like it just needs a minor review, another short round of verification, and then a push into -updates; it's the -nsc driver package that's the problem
<sbeattie> oh, okay, I'll shut my mis-informed mouth, I assumed this was about bug 219630
<ubottu> Launchpad bug 219630 in xserver-xorg-video-nsc "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Undecided,In progress] https://launchpad.net/bugs/219630
<slangasek> bug #214119
<ogra> sbeattie, it is
<ubottu> Launchpad bug 214119 in xserver-xorg-video-geode "[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600" [High,Fix committed] https://launchpad.net/bugs/214119
<ogra> they are both related
<slangasek> er, no - you're right, bug #219630 :)
<ogra> its pretty much the same
<slangasek> 219630 is the one requesting the nsc SRU
<ogra> but Koolu is even worse, they ship ubuntu by default and already had probs in gutsy
<ogra> and they used to promote us loudly
<ogra> not anymore though (even though they still ship with ubuntu afaik)
<slangasek> and the fix for that is already in -proposed and on track for inclusion in -updates, so I don't see that there's a problem there
<ogra> yeah, thats geode ...
<jdstrand> kees: interesting, updated dchroot on ronne worked fine
<sbeattie> ogra: feedback for the -geode would still help it get out the door.
<ogra> sbeattie, i thought geode was ok already ?
<slangasek> I see that the -geode one is already verification-done, and was planning to copy it toda
<sbeattie> Oh, okay
 * sbeattie wishes tags could be applied to individual tasks rather than only just to bugs as a whole.
<kees> jdstrand: hmpf :(
<jdstrand> kees: yeah, bit of a head scratcher
<jdstrand> kees: feels like a schroot thing
<Q-FUNK> slangasek: please see my comments to bug #219630.  I'm really sorry that the fix got so complex, but it involved fixing 3 packages at the same time, plus packaging a new upstream to fix hardware issues.  not an easy task for anyone to handle.
<ubottu> Launchpad bug 219630 in xserver-xorg-video-nsc "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Undecided,In progress] https://launchpad.net/bugs/219630
<slangasek> Q-FUNK: "avoid PCI ID conflicts in X.org at all cost" - why?  does X crash horribly when it encounters this situation, or does it just pick one of the drivers?
<Q-FUNK> slangasek: so far, it seems to simply fail to launch.
<slangasek> mm, yuck
<Q-FUNK> whether this is because it unfortunately picks the wrong driver at random is beyond me.  I tried investigating this as much as I could and could not come up with a conclusive answer.
<slangasek> which PCI IDs are conflicted over, by which sets of drivers?
<slangasek> bryce: ^^ do you know the answer to the above, regarding Xorg's behavior when more than one driver tries to claim the same PCI ID?
<Q-FUNK> slangasek: it mainly is xserver-xorg-video-nsc that claims ID numbers for hardware covered by -cyrix and -geode
<slangasek> ok, but only one of these PCI IDs that you're fixing up in NSC is the -geode ID, right?
<slangasek> and the others are covered by cyrix, which so far has had no discussion in the bug log of regression testing
<Q-FUNK> to make a long story short, the hardware changed owner 3 times and some legacy (unused) code remains from cyrix time in both -nsc and -geode.  my package of -geode skipped these right from the start, but -nsc kept them.
<slangasek> I accept that dropping those PCI IDs from nsc is correct for intrepid, but there are a whole swath of problems with dropping them in an SRU that I don't think have been addressed yet
<Q-FUNK> right, because cyrix is presumed to correctly handle cyrix hardware already.
<slangasek> which packages support the chips with the 0x1078 vendor ID?
<bryce> heya
<Q-FUNK> cyrix
<slangasek> ok
<Q-FUNK> but nsc laso has them, though unused
<slangasek> see, "presumed" is why this is a problem, when it would have to be pushed on such short notice that there's no real opportunity for testing
<Lightkey> cyrix 686, yay!
<Q-FUNK> the main issue is with debian's point and shoot way of generating PCI ID lists.  matching every PCI vendor with every PCI device found in the source code generates false positives.
<Q-FUNK>   this is why -nsc needs to be fixed, tlo clear the room for cyrix and geode to claim their hardware.
<slangasek> if you updated the nsc SRU to /just/ change the geode ID, I would be willing to accept that
<bryce> slangasek: I believe that the behavior with multiple drivers claiming the same id is undefined
<slangasek> bryce: well - should it use a random driver, or just fall flat on its face...?
<Q-FUNK> I have access to nsc and geode (amd) hardware.  removing the conflicts fixes the behavior. I get X.  without removing those conflicts, I don't.
<ogra> i just heard in fedora it does the latter
<slangasek> if the answer is "use a random driver", then we've got a fair amount of regression potential with this SRU
<slangasek> if the answer is "fall flat on its face", we have a much more critical bug to weigh that against
<bryce> slangasek: I would expect that it uses a random driver, but this isn't something I've experimented with so I don't know for certain
<slangasek> Q-FUNK: yes, and I'm ok with getting that fixed, for the hardware where it's been tested
<slangasek> it's the change in behavior for hardware that hasn't been tested that bothers me
 * bryce nods
<Q-FUNK> slangasek: in that case, it mostly involves moving one claimed ID from the -nsc to the -geode driver.  versioned conflict needed in -geode against older -nsc packages.
<slangasek> among other things, consider the case of a user with a trimmed-down set of packages installed - they know they're using -nsc (even though their chip is Cyrix), so they only have -nsc installed, not -all.  Now they upgrade, and their chip is no loner supported.
<slangasek> s/loner/longer/
<Q-FUNK> I agree that lack of testing for cyrix hardware could be a gamble. however, most thin client hardware out there uses either nsc or geode(amd) Geodes.
<slangasek> Q-FUNK: ok.  Can we try the -nsc NMU again, with only the change for the geode PCI ID?
<slangasek> er, s/NMU/SRU/
<slangasek> the cyrix stuff, from what I'm hearing, can reasonably be postponed until after 8.04.1, when we can get proper regression testing
<Q-FUNK> slangasek: do you also want us to revert debian's build script changes, on aspects where it doesn't involve shipping a fixed static nsc.ids list?
<slangasek> Q-FUNK: that is definitely my /preference/
<slangasek> since it means less time that I have to spend trying to understand those changes
<Q-FUNK> it could be done if needed, but I'm the wrong guy to do it, as I cannot make ends or tails of the XSF scripts. that's how I ended up choosing CDBS to package -geode, way back.
<Q-FUNK> bryce: do you think you could look at my last debdiff and skim it into just shipping a different nsc.ids then?
<calc> slangasek: do we have a meeting today at normal time
<calc> slangasek: i didn't see an email about it this week
<bryce> calc: afaik we do
<calc> bryce: ok
<bryce> calc: it may be a short one though
<calc> ok
<bryce> Q-FUNK: ok I can do that for you - link me to the debdiff again plz?
<Q-FUNK> slangasek: so, beyond the trimmed down delta for -nsc, are my latest debdiffs for -geode and -all suitable for SRU for 8.04.1 ?
<Q-FUNK> bryce: starting at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/219630  grab http://launchpadlibrarian.net/15556613/debdiff_2.8.3-2_to_2.8.3-2ubuntu1.txt
<ubottu> Launchpad bug 219630 in xserver-xorg-video-nsc "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Undecided,In progress]
<slangasek> Q-FUNK: I believe that the only debian/ changes that need to be kept are the ones to debian/control; everything else should be cosmetic with respect to this particular patch
<Q-FUNK> slangasek: adding the Conflicts I had forgotten in -geode against -amd, that is.
<Q-FUNK> slangasek: ok, fair enough.
<slangasek> the geode/all stuff looks good to me, but I'm still digesting parts of it
<Q-FUNK> bryce: can I count on you and tjaalton sanity-chekcing all 3 debdiffs -just to be on the safe side?
<bryce> tjaalton is on vacation
<Q-FUNK> slangasek: the -all part is just to make xserver-xorg-video-all Depends on xserver-xorg-video-geode instead of ï»¿ï»¿ xserver-xorg-video-amd.  this should have already been done in 8.04.0, but we forgot to do it on time.
<slangasek> right.  -amd is currently a transitional package, correct?
<Q-FUNK> it mostly exists to allow orphaners to drop the transitional package, including possible symbolic links included in older -amd transitional packages that were meant to provide backward-compatiblity for people wiht a static xorg-conf containing "amd" as the driver, but which don't work on debian derivative.s
<Q-FUNK> yup
<slangasek> I thinkk I'm also confused by the changelog for xserver-xorg-video-geode 2.9.0-1ubuntu2.1
<Q-FUNK> 2.1 or 2.2 ?
<slangasek> "Removed the GX model's PCI ID from geode.ids to fix LTSP usage case." - is that the same PCI ID that's now being dropped from nsc?
<slangasek> or a different one?
<Q-FUNK> same
<slangasek> so... it's being dropped in both places?
<Q-FUNK> we had to temporarily drop it, until -snc was fixed
<Q-FUNK> it's back in 2.2
<slangasek> ah
<slangasek> the 2.2 changelog doesn't mention this
<Q-FUNK> hence the versioned conflicts in -geode
<Q-FUNK> no?
<slangasek> +xserver-xorg-video-geode (2.9.0-1ubuntu2.2) hardy-proposed; urgency=high
<slangasek> +
<slangasek> +  * Removed the transitional symbolic links for amd_drv.so (LP: #219630).
<slangasek> that's the whole changelog
<Q-FUNK> argh
<Q-FUNK> forgot to mention that
<Q-FUNK> the whole cherry-picking method involved in making an SRU has been a hard one on me
<Q-FUNK> my debian packages have the whole story, rather than one single line refering to an LP bug as used in SRU
<slangasek> if you have time to prepare a 2.2 with a fixed changelog, that would definitely be appreciated too; changelogs are important so users know what's changed, not just so the SRU team does
<bryce> (and do de-confusify fellow packagers)
<Q-FUNK> slangasek: I initially had that.  pitti suggested that having a multiple-line changelog was unacceptable for an SRU.  he suggested that I should instead rewrite this into a sigle line that closes an LP bug.
<slangasek> actually, that's not what pitti meant
<Q-FUNK> no?
<slangasek> I know that's what he seemed to say :)
<Q-FUNK> :(
<Q-FUNK> well, ok. misunderstandings do happen
<slangasek> what he meant was that the SRU should condense the changes into an entry for a single version
<Q-FUNK> especially when trying to make sense of changes in 3 packages, plus a new upstream, to fix one single issue, handled by a part-time maintianer.
<slangasek> instead of incorporating, verbatim, the changelog entries for other versions that aren't being uploaded in an SRU
<Q-FUNK> ah
 * Q-FUNK bangs head
<ogra> forcing a single line changelog would be insane :)
<Q-FUNK> ok, that's a bit more clear now.
<Q-FUNK> heh :)
<ogra> my ltsp SRU fixed ten bugs ... that would have been a looong line :)
<bryce> ogra, well if you omit spaces and vowels maybe?
<Q-FUNK> :D
<ogra> heh
<Q-FUNK> guys, I appreciate everyone's sense of humor, especially in moments like these
<Q-FUNK> this has been a though bug to tackle
<bryce> yeah
<Q-FUNK> it at least lightens the mood :)
<stgraber> ogra: "Fix LTSP (LP: xxx, LP: xxx, LP: xxx, ...). You see, it's not that hard :)
<stgraber> ok, not likely to be accepted :)
<ogra> yeah :)
<Q-FUNK> slangasek: anyhow, if it's ok with you, starting with approving that -all change to drop the transitional package would be a good start.
<slangasek> yes, that one is straightforward
<Q-FUNK> slangasek: then, with bryce's help, we'll skim -nsc and re-submit.
<slangasek> ok
<slangasek> will you have time to redo the changelog for -geode?
<Q-FUNK> as for -geode, was it ok as such (adding the forgotten Conflicts) ?
<Q-FUNK> Ã¶Ã¶Ã¶... i might get around it tonight.  it's already  23:00 here, mind you.
<slangasek> the changelog at present is definitely misleading, but if you won't have time to fix it then I'd rather accept it today as-is than wait another day on this
<Q-FUNK> thankfully, it's only a one-line addition
<slangasek> OTOH, I can afford to wait until you fall asleep to see if you get it done :)
<Q-FUNK> ok, then let's get it in. as long as both -nsc and -geode get in at the same time, we'll at least fix the PCI ID conflicts and send -amd into oblivion for good.  that would already be something good.
<slangasek> hrm; the transitional symlink is dropped from -geode, but not added to -amd
<Q-FUNK> slangasek: can I review the resulting packages from hardy-proposed tomorrow morning and let you know if I notice anythign fishy, before they get pushed into hardy-updates?
<slangasek> that means the package description is also wrong, because it says "If you are using a static xorg.conf, edit the Device section and change the Driver value from "amd" to "geode" before purging this package"
<slangasek> apparently it should say, edit the Device section before /installing/ this package. ;)
<slangasek> Q-FUNK: oh, yes, the packages certainly wouldn't be pushed to -updates that soon
<Q-FUNK> slangasek: right. it initially migrated to -amd, but was dropped entirely,  because it creates a whole mess on debian derivatives.  I replaced that with a notice in -amd's Description, advising people to upgrade their static xorg.conf if they have any to use "geode".
<Q-FUNK> sync :)
<slangasek> Q-FUNK: then perhaps s/ before purging this package// ?
<slangasek> since it's not the purging that will break their static xorg.conf
<Q-FUNK> "before" rather than "after" sounds good,
<slangasek> ok
<Q-FUNK> indeed. it's the fact that calling "amd" will produce a dead screen, since there's no such driver anymore.
 * Q-FUNK writes himself a TODO
<slangasek> it does seem to me that it would be better to include this symlink in the transitional package
<Q-FUNK> I used to have it, but it disrupts operation in LTSP
<slangasek> if 8.04.1 doesn't install the -amd package (by fixing -all), then it shouldn't disrupt anything
<slangasek> whereas the users who have it installed presumably would like things to actually be compatible...
<Q-FUNK> if you look at -geode's changelog at debian, I initially moved the symbolic link from -geode to -amd, to make it purgeable. that wasn't enough.  in practice, for as long as two drivers (because of the symbolic link, I guess) claim the hardware, X barfs.
<slangasek> ah :/
<slangasek> ok
<Q-FUNK> that's how i ended up entirely removing the symbolic link.
<Q-FUNK> I don't think that there's any ideal way to get people upgrading from << hardy to get their static xorg.conf (if any is used) fixed automagically upon upgrade.
<Q-FUNK> or well... I supposed that some postinst sed script could do it, but I find this too scary to rely upon.
<Q-FUNK> not being a 'sed' guru, i didn't dare attempt it.
<slangasek> yeah... I would dare
<slangasek> half the sed evil in the xorg package is my handiwork
<slangasek> but it's a little late for that now
<bryce> aha!!
<bryce> ;-)
<bryce> slangasek: I run into your name in the randomest places :-)
<slangasek> yeah, funny that
<bryce> once I got sick of the silly default names in the game Pioneers, so I patched it to use the names from AUTHORS
<slangasek> hahaha
<bryce> lo and behold, I fire it up and there I'm playing against you!
<Q-FUNK> this being said, patches are welcome.  besides, this would be double-useful as, later this autumn, -geode is supposed to merge back GX1 support and supersede -cyrix and -nsc.
<Q-FUNK> it could be fun to parse xorg.conf for either one and upgrade it for the user.
<Q-FUNK> however, this would break dexconf configuralibty, since it becomes a manually hacked xorg.conf too.
<Q-FUNK> typos r us
<bryce> hmm, next time I volunteer for an autoconf cleanup task, someone shoot me first ;-)
<Q-FUNK> does a vintage soviet AK47 from a military surplus store suit you? :-P
<Q-FUNK> ok, I better head home here.
<bryce> that'd be great
<ogra> Q-FUNK, well, by authmn this year we shouldnt have any xorg.conf anymore
<ogra> *autumn
<Q-FUNK> slangasek: thanks for the SRU run-trough.  hopefully, we'll have this fixed within the next few hours.
<Q-FUNK> bryce: and thanks for helping out.  it's immensely appreciated.
<slangasek> Q-FUNK: sure; thanks for persevering :)
<ion_> ogra: Yay
<Q-FUNK> it's been an... interesting ride.  I never got around doing any security release at debian for any of my packages, so this SRU is the closest thing I've ever seen to live fire.
<Q-FUNK> and trying to keep track of changes in 3 packages was a nice peice of mental  gymnastics.
<Q-FUNK> anyhow, 'night everyone :)
<bryce> cya
<bryce> autoconf is one project I'd actually like to see slow *down*.  some of these changes are fairly gratuitous
<slangasek> calc: <popping the stack> yes, I believe we are to have a meeting today at the normal time :)
<slangasek> mumble, previous unverified xorg SRU sitting in -proposed for a month
<bryce> I think cjwatson's just been uber busy catching up on administrivia
<tjaalton> bryce, slangasek: howdy! IIRC the xserver will pick the first driver to support the ID in alphabetical order
<bryce> tjaalton: heya!  ok thanks, I wondered if that might be the case
<slangasek> tjaalton: hmm, then I wonder why nsc gives problems, g < n :)
<bryce> although it makes me wonder why nsc would mess things up, since amd and geode are alphabetically higher
<tjaalton> hum, right
<tjaalton> actually, by looking at the patch 03_auto_load_driver.diff, IIUI, the _last_ driver to support it would end up being used
<slangasek> ah, that makes sense then :)
<bryce> reverse alpha.  good to know
<bryce> cd /usr/share/xserver-xorg/pci/ ; cat *.ids >> voodoo.ids ; echo "Bwahahahaha"
<tjaalton> hehe
<tjaalton> *boom*
<bryce> slangasek: hum, this is weird, the -nsc package in hardy includes a patch that doesn't actually seem to apply
<slangasek> awesomesauce
<slangasek> it doesn't seem to /be/ applied, or it tries to apply it and fails...?
<bryce> it tries to apply it, but it's already been applied to src
<slangasek> whee
<bryce> er, something like that.
<bryce> anyway, this makes the debdiff finally make sense, I'll get it fixed up.
 * ogra hugs bryce 
<ogra> ths issue has gone on far to long for that little set of changes thats actually needed
<bryce> ogra, it's certainly been a learning experience all around
 * ogra hopes so 
<cjwatson> bryce: correct; if it's a short meeting tonight, I shall be happy :)
<bryce> slangasek: am I correct in that since -nsc is 1:2.8.3-2 in hardy currently, this new upload should be versioned as 1:2.8.3-2ubuntu0.1 ?
<bryce> slangasek: anyway I'm guessing yes.  I've finished the packaging
<bryce> one last time doublechecking everythign and then I'll upload to hardy-proposed
<bryce> slangasek: uploaded
 * ogra appluds
<ogra> or so
<bryce> ogra if you have means to test, it would be mucho appreciated
<ogra> i need to dig up the DBE60 thincan i got from martin and set that up for testing, not tonight anymore, but i can give it a go tomorrow
<bryce> that'd be great
<ogra> should we ping cr3 to trigger someone to test it on koolu ?
<liw> does anything in Ubuntu care about Standards-Version in debian/control?
<bryce> ogra yeah good idea
<bryce> liw not afaik
<slangasek> bryce: xserver-xorg-video-nsc/1:2.8.3-2ubuntu1, yes please :)
<ogra> liw, the developer after you who has to merge mnually just for the standards change ...
<ogra> but nothing apart from that :)
<ogra> oh, and lintian
<cr3> ogra: what's up dude? xserver-xorg-video-nsc? what would you like me to test exactly?
<liw> ogra, well, I'm asking to decide whether to merge the Standards-Version from Debian or to keep the one in Ubuntu :)
<ogra> cr3, hardy-proposed
<ogra> liw, if its only for the sake of updating the standards i wouldnt ... if its one change among others i would
<ogra> generally if its standards only that should be done in debian and be synced imho
<liw> ogra, of course
<bryce> slangasek: ok well you got 2ubuntu0.1 in there, I hope that's ok
<liw> this is part of a larger set of changes; I didn't want to bump the S-V in Ubuntu if Ubuntu follows an older version of policy
<ogra> cr3, bottom line is "shuld all work"
<bryce> cr3: I've just uploaded a fix to make hardy installable and functional on geode hardware
<bryce> cr3: so we would encourage re-running your tests on any geode hardware you have and verify that X now works on them.
<cr3> ogra: should it be tested in both desktop and ltsp mode?
<ogra> indeed :)
<ogra> do you have a thincan ?
<cr3> ogra: yep
<ogra> ah, well then there too
<ogra> i'll test it myself tomorrow on ltsp
<cr3> I'll have to test it tomorrow as well
<cjwatson> liw: I'd second ogra, just sync S-V with Debian; I'd go so far as to say that S-V should never be changed in Ubuntu unless you are completely repackaging from scratch
<liw> yep
<cjwatson> liw: the notion of following a version of policy has always been a bit sketchy in Debian anyway - it's really more for the maintainer to say "yup, I've checked up to here"
<cjwatson> so it's kind of a bizarre thing to bump :)
<liw> yeah, that's what Debian uses it for; I find it useful for myself, to verify against the upgrading list
<slangasek> bryce: 0.1 is probably more proper anyway; ubuntu1 was just what had been in the -proposed queue before
<bryce> oh, I didn't spot that
<cjwatson> liw: *nod*
<slangasek> bryce: um, ok; on this 0.1 you've uploaded for nsc, you're still disabling the cyrix PCI IDs, which I explicitly requested not be done in this round due to timing relative to the point release
<bryce> slangasek: er, guess I didn't catch that.
<bryce> I gathered Q-FUNK simply wanted all the autoconf junk straightened out
<bryce> are there any other changes?
<slangasek> bryce: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/219630/comments/50
<ubottu> Launchpad bug 219630 in xserver-xorg-video-geode "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Undecided,In progress]
<slangasek> straightening the autoconf junk is appreciated, but it's the cyrix change that I consider the blocker due to our inability to regression-test here
<slangasek> ScottK: do you have any interest in taking care of the libselinux/libsepol merges, by change?
<slangasek> s/change/chance/
<ScottK> slangasek: No.  I thought tresys and manoj were going to work so sort stuff out.
<ScottK> Without help from them, I'd be tempted to sync and go from there.
<slangasek> oh, is that not done yet? :/
<bryce> slangasek: ok I see, Q-FUNK had said he was uncomfortable doing the cleanup of the XSF scripts and asked if I would "skim it just shipping a different nsc.ids then" which is what I did.  I assumed the debdiff he gave me was correct other than that.
<bryce> *sigh* this is like the sru from hell.  one sec I'll fix it.
<ScottK> slangasek: I've ping'ed them a couple of times on #ubuntu-hardened and gotten nods, but no action.
<ogra> bryce, well, its intresting to see how it melts down to a handfull of lines once *you* touched it
<slangasek> ScottK: well, I'm aware that Manoj has integrated at least some of their changes; maybe a sync wouldn't be the worst outcome
<ScottK> It would at least get us rebased from Debian and then we can adjust from there.
<bryce> ogra, yeah well it would help if I'd learn to read
<ogra> ah, come on you fixed the probelm in 1h while th ebug goes back and forth since 3 months or so
<bryce> slangasek: so should this be ubuntu0.2 or ubuntu2?
<ogra> without any proper outcome ...
<slangasek> bryce: ubuntu0.1
<slangasek> bryce: you get to reuse the number because I'm not letting this other one into the light of day ;)
<bryce> aw
<bryce> ok, so I just need to figure out what the cyrix pciid is.  hmm
<slangasek> bryce: it's the line that's been commented out in Makefile.am in the patch
<slangasek> this patch disables registration for all devices with cyrix as the vendor ID
<bryce> so is the change just uncommenting that line?
<slangasek> I believe so
<bryce> ok that should be trivial
<bryce> however I notice they also reshuffled the ordering
<bryce> I'll check if that's significant
<calc> bryce: ping
<calc> bryce: Benjamin Drung seems to have tested the various methods and it didn't work for him, so he sounds like a good candidate for the new debs
<calc> https://bugs.launchpad.net/~bdrung
<bryce> ok cool, would you like to ask him to test with that libx11 patch (since you've been the contact on that bug so far), or shall I?
<calc> bryce: it would probably be better if you did so if he has questions it would be to the person who has a clue ;-)
<calc> i still don't have any idea why it seems that users that have this problem don't have the problem under a new user account, even removing .openoffice.org2 dir doesn't help them
<calc> but hopefully removing xcb will help out
<calc> they mention removing gtk/gnome ooo addon helps fix the problem so maybe there is a messed up file somewhere in gtk/gnome settings
<calc> but i have no idea where to even begin looking in there
<bryce> calc, ok will do - hang on a bit though I'm multitasking on a few things
<calc> ok np
<bryce> yeah the xcb issue seems to be one that gets exposed via race conditions with multiple things trying to get a lock
<bryce> that sort of thing can exhibit itself and then go away under very oddball conditions
<bryce> like cody found that just delaying when gnome-screensaver starts up suppressed the issue
<cody-somerville> bryce, I think it was the two dbus-launch processes attempting to launch session buses at roughly the same time.
<cody-somerville> gnome-screensaver uses dbus and would make a dbus call resulting in dbus-launch --autolaunch because we xfce4 (whom use xscreensaver by default) has dbus-launch --sh-syntax --exit-with-session after the launch of the screensaver (and ssh-agent)
#ubuntu-devel 2008-06-26
<TheMuso> slangasek: BTW alsa-plugins/libasound2-plugins also needs to be pulled from hardy-proposed, as when users install plugins, things will break as it needs 1.0.16 or later of alsa-lib.
<bryce> weird, I don't think the uncommented pci id patch would actually do what it looks like it wants to do
<bryce> +       awk '/^#define.*PCI_CHIP/ {print $$3}' ${srcdir}/nsc_driver.c | sort -u | grep -v 0030 | sed -e 's/0x/100B/' > nsc.ids
<bryce> +       awk '/^#define.*PCI_CHIP/ {print $$3}' ${srcdir}/nsc_driver.c | sort -u | grep -v 0030 | sed -e 's/0x/1078/' >> nsc.ids
<bryce> ohhh I get it
<slangasek> TheMuso: oh, I didn't realize that we had an alsa-plugins upload in there... I'll yank it out
<bryce> slangasek: ok new ubuntu0.1 uploaded with just that line uncommented
<bryce> (I finally fully understand how the patch works)
<slangasek> ok :)
<bryce> calc: ok libx11 time
<bryce> calc, ok I've emailed ben
<slangasek> bryce: in your latest upload, doesn't 02_fix_geode_pciid.patch need to be refreshed to reflect your changes to 01_gen_pci_ids.diff?
<slangasek> bryce: it looks to me like the Makefile.am and Makefile.in are out of sync, with the Makefile.in being incorrect
<slangasek> (i.e., still commenting out the cyrix line)
<bryce> slangasek: hrm, ok I'll take a look
<bryce> ahh, no one hooked up the patch system in -nsc.
<bryce> *boggle* ok
<slangasek> ah, maybe that's part of what the massive xsfbs patch that got pulled in was about?
<bryce> surprisingly no; despite all that, debian didn't set up the patch system either
<bryce> which is why I didn't catch it when reviewing the debdiffs...  didn't even think to look
<slangasek> heh
<bryce> but it became obvious when I went looking for why none of my prior uploads had failed to build
<bryce> ahhhh and it explains why the sync had gone through when that patch clearly couldn't apply.
<persia> calc: My apologies for not taking care of it earlier: I'm reading the platform minutes, and discover that you were assigning taking a look at openoffice.org-en-au: it's a sync, and I've filed the sync request.
<emgent> someone can stop Michael Garrido planet.u.c climbing ?
<nxvl> emgent: ?
<ScottK> bryce: I wasn't actually at the platform meeting.  My 'shot' at selinux packages will be to file sync requests.
<emgent> n8k99:
<emgent> nxvl: Him update the date of his post to stay in the first news planet.uc pathetic.
<emgent> my feedrss reader see it ...
<nxvl> emgent: mm i don't think he did, it must be a random error
<n8k99> emgent?
<emgent> nxvl: impossible.. him use *.wordpress.com and more other planet user use it. but only him have this "problem"
<emgent> n8k99: sorry, wrong tab :)
<n8k99> oh haha
<nxvl> emgent: i have noticed it this time, but just once
<nxvl> or have you noticed it many times?
<emgent> many times.
<nxvl> mmm
<nxvl> strange
<nxvl> i have just noted on his last post
<nxvl> i will talk to him
<emgent> ok thanks
<nxvl> emgent: you can talk to him, he's connected
<emgent> liferea dont log all, update the date hour post, argh.
<nxvl> emgent: xander21c in freenode
<emgent> ok nxvl i will do. Thanks
<nxvl> emgent: i have just talked to him
<emgent> dont reply to me now :\
<nxvl> emgent: he said he's going to check the settings @ wordpres
<emgent> ok cool.
<nxvl> maybe he's not registred
<emgent> ?
<nxvl> on freenode you can't reply to private messages if you are not registred and loged in
<emgent> oh ok
<wgrant> nxvl: I think new services removed that limitation, actually.
<wgrant> 'SET UNFILTERED has been removed and the global block on messages from users that have not identified to NickServ has been removed.'
<nxvl> wgrant: are you sure?
<wgrant> http://blog.freenode.net/?p=80
<nxvl> \o/
<Hobbsee> wow!  my wifi has a light now!
<Hobbsee> any music sounds like someone's torturing a cat, though
<ajmitch> haha
 * Hobbsee wonders why the light keeps flashing every once in a while
 * ajmitch calls the SPCA around to Hobbsee's place
<wgrant> ajmitch: Yours isn't royal?
<wgrant> Hobbsee: Is there meant to be a 2.6.26 LUM?
<ajmitch> it may be officially, but it's usually called the SPCA
<wgrant> My audio sounds awful as well, and headphones don't mute speakers.
<ScottK> Hobbsee: The music people heard about your myspace page and thought you'd like it.
<wgrant> We have the RSPCA here.
<wgrant> ScottK: That's gone now :(
<Hobbsee> wgrant: apparently not?
<ScottK> But the legend lives on.
<Hobbsee> ScottK: hahhahahahha
<Hobbsee> ScottK: i don't suppose you know if facebook will let you embed html in it, to change the background?  :P
 * StevenK gets that flashy swirly thing happening to his retinas again
<Hobbsee> it's a *lovely* background.
 * ajmitch twitches
<ajmitch> don't make me run for the medication again
<Hobbsee> i would have thought you'd learned by now to keep it with you.
<Hobbsee> argh.  what's the pcspkr module called now, in 2.6.26?
<wgrant> Hobbsee: snd_pcsp
<wgrant> I encountered the same problem.
<Hobbsee> wgrant: and how do i force it not to be in use?
<wgrant> Hobbsee: By blacklisting and rebooting, or removing the whole stack of audio modules, I guess.
<persia> Hobbsee: You can rmmod it, blacklist it, or pass module arguments to cause it to load later in the sequence.
<wgrant> I gave up on 2.6.26 because I presumed that my audio depended on LUM.
<wgrant> Which seems to no longer be around.
<Hobbsee> persia: rmmod gives the same thing.
 * Hobbsee updates the blacklist though, for the next reboot
<Hobbsee> was hoping to fix it without a reboot
<wgrant> Hobbsee: WOrk out what depends on it.
<wgrant> lsmod should help.
<persia> Hobbsee: You can't rmmod it?  Please pastebin your lsmod
<Hobbsee> sarah@saturn:~% lsmod  | grep pcsp                                       2:06PM
<Hobbsee> snd_pcsp               17312  1
<persia> Hobbsee: Also, check /proc/asound/cards to make sure you have another working device present.
<Hobbsee> snd_pcm                82180  3 snd_pcsp,snd_hda_intel,snd_pcm_oss
<Hobbsee> snd                    61988  16 snd_pcsp,snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
<Hobbsee> yeah, i do.
<Hobbsee> wgrant: thanks, that's the command i wanted, but had forgotten.
<Hobbsee> persia: is that enough, or do you want the entire thing?
<persia> That says nothing depends on snd_pcsp.  You get am error from rmmod?
<persia> s/am/an/
<Hobbsee> sarah@saturn:~% sudo rmmod snd_pcsp                                      2:08PM
<Hobbsee> ERROR: Module snd_pcsp is in use
<Hobbsee> yup
 * ajmitch blames userspace 
<persia> Hobbsee: OK.  lsof | grep /dev/snd to find the offending process.
<persia> Convince that process to use a different device.
<persia> rmmod it.
<Hobbsee> persia: no offending process.  go figure.
 * ajmitch wonders if it'll be pulseaudio hogging it
<persia> Likely.
 * Hobbsee puts it down to intrepid weirdness.
<persia> Hobbsee: Have you run the ALSA set-default macro since you changed kernels?
<Hobbsee> persia: no?
 * Hobbsee has no idea what that even is - never needed it before
<superm1> those sound applets that live in panels are good candidates for killing if you cant rmmod
<persia> Hobbsee: That would do it.  You likely altered the indecies for your cards as a result of the PC speaking getting ALSA support and loading first.
<Hobbsee> superm1: don't have one of them, but good idea.
<Hobbsee> persia: ah, right.  which is why the sound sounds strange.
<persia> Hobbsee: Check your card names in /proc/asound/cards, then run `asoundconf set-default-card $(NAME)`
<persia> Actually, `asoundconf list` might give you a better list of names than /proc/asound/cards
<Hobbsee> persia: that's fixed it, thanks.  although i still can't rmmod the other, for some reason.
<persia> With that done, you oughtn't need to worry about rmmod or blacklisting.
 * Hobbsee had forgotten just how crap the default speakers sound.
<persia> OOps!
<TheMuso> Hrm grub seems to fail on the intrepid alternate i386 daily.
<slangasek> TheMuso: fail how?
<dholbach> good morning
<vozniakBR> too
<TheMuso> slangasek: Something to do with the package not being able to be installed...
<slangasek> ok
<TheMuso> slangasek: "The package 'grub' cannot be installed into /target or some such.
<nxvl> slangasek: did you get chance to check Bug #225005?
<ubottu> Launchpad bug 225005 in gnupg "Please merge gnupg 1.4.6-2.1 from debian sid" [Undecided,Confirmed] https://launchpad.net/bugs/225005
<Hobbsee> morning dholbach
<slangasek> nxvl: no, sorry; that will have to be tomorrow for me
<dholbach> hi Hobbsee
<nxvl> slangasek: ok, because i merged it before intrepid were open and we are 1 day away from DIF
<nxvl> slangasek: but, no problem, take a look when you have some time :D
<slangasek> TheMuso: mm, is there any more specific error in the log?
<slangasek> I see there are new versions of grub in intrepid that aren't in the bzr repo, doh
<slangasek> TheMuso: I don't see anything wrong with the latest grub diff in intrepid; an exact error message from the log would be helpful
<TheMuso> slangasek: Ok I'll see what I can dig up.
<TheMuso> slangasek: Ok not much there that says why, I may have to run again with the verbocity cranked up somewhat.
<slangasek> I think that any maintainer script errors should be registered in the log, somewhere?
<slangasek> but I'm off to bed now, so not much help I'm afraid
<TheMuso> slangasek: no problem, will keep digging.
<pitti> Good mornin
<nxvl> pitti: hello!
<andrew_sayers> Is there a list somewhere of the packages installed by default in the various *buntu?
<andrew_sayers> I've been going by the popularity contest, but that's not broken down by variant.
<nxvl> yes, there is
<nxvl> i just don;t remember where
<persia> andrew_sayers: It's a close match to the dependencies of the various -meta packages.
<persia> (and the recursive dependencies thereof)
<andrew_sayers> persia: you mean there's a xubuntu-meta package out there?
<andrew_sayers> persia: never mind, I get it :)
<persia> andrew_sayers: Yep.  xubuntu-desktop is likely the one that would provide the interesting list.
<andrew_sayers> I see - so basically xubuntu == xubuntu-desktop + dependencies?
<nxvl> andrew_sayers: and + ubuntu-base
<andrew_sayers> Thanks, that's all I need to know :)
<nxvl> s/base/minimal
<persia> nxvl: Is it?  I thought when seeds had dependencies those were expressed in the resulting metapackages.
<kahrytan> Hello
<Q-FUNK> slangasek: were we missing anything to get bryce's updated -nsc package in? I wanted to test this, but it doesn't show up in Sources either, yet.
<seb128> mvo: hey
<seb128> mvo: do you plan to reply to this mailing thread about main packages having recommends in universe?
<mvo> seb128: can do, I'm (even more) behind my mail than usually because I finally switched to a new provider and that is causing a bit of transition pain
<seb128> mvo: alright, I was just wondering because you probably know how the packaging tools handle the situation and what are the plan for that
<seb128> dunno if that has been discussed before though
<mvo> I need to read the thread but I see no problems with recommending on universe. people with universe enabled get the packages, people without don't
<seb128> my understanding is that CD are already at the limit so we will not have changes there
<seb128> and then recommends will be installed in functions of the sources available
<seb128> mvo: right, the thread is "should we promote all recommends to main or not" basically
 * mvo nods
<mvo> I guess its a matter of policy, but I don't see a reason why we should
<mvo> we should check them out and decide on a case-by-case basis and maybe demote some to suggests
<persia> I think it will cause QA confusion to have different sets of packages installed for people who install off the livecd (with package copy) and the alternate CD (with possible network access).
<mvo> did someone do a analysis on this? i.e. how many packages have those and what recommends those are?
<mvo> persia: oh, I agree on this of course, we should make sure this is consistent
<persia> I don't think a full analysis has been done, and certainly not widely published.
 * mvo was thinking about the general case
<persia> mvo: In general case, I think you7re right.  I'm mostly worried about the impact on the installation case.
<mvo> persia: ok, I will put it on my todo for today and check the scope on this
<persia> mvo: Thanks :)
<seb128> mvo: btw
<cjwatson> mvo: I have to say I think different behaviour depending on apt configuration will be very confusing. I had been planning to make germinate treat Recommends like Depends so that we get flagged to promote things from universe that are Recommended.
<seb128> mvo: sudo apt-get install --fix-policy --install-recommends
<cjwatson> mvo: which doesn't of course mean promoting everything en masse, it means a case-by-case review
<seb128> 17 upgraded, 173 newly installed, 3 to remove and 99 not upgraded.
<seb128> Need to get 237MB of archives.
<seb128> After this operation, 515MB of additional disk space will be used.
<seb128> mvo: that's on my intrepid machine and I've no many universe things installed
<cjwatson> seb128: I suspect that that's due to a handful of actual Recommends arcs that then pull it lots of further dependencies
<seb128> urg
<seb128> Installing mailx as dep of logrotate
<seb128> Installing bsd-mailx as dep of mailx
<seb128> Installing exim4 as dep of bsd-mailx
<cjwatson> I think what I'll do is add it to germinate with a --no-recommends command-line option, so you can still do a comparison
 * cjwatson runs the (I suppose) last autosync
<mvo> cjwatson: sounds good to me as well, the confusion a valid point
<mvo> seb128: yeah, especially the "recommends mail-transport-agent" need to be demoted
<mvo> that is currently quite anyoing
<wgrant> mvo: It brings exim into a basic debootstrap, I note.
<tkamppeter> I am trying to compile a Qt/KDE application (KDE4) and "cmake" produces the following errors:
<tkamppeter> CMake Error at CMakeLists.txt:5 (find_package):
<tkamppeter>   find_package could not find module FindPoppler.cmake or a configuration
<tkamppeter>   file for package Poppler.
<tkamppeter> [...]
<tkamppeter> CMake Error at CMakeLists.txt:6 (PKGCONFIG):
<tkamppeter>   Unknown CMake command "PKGCONFIG".
<tkamppeter> Which packages do I have to install on Intrepid
<seb128> what are you trying to build?
<tkamppeter> seb128: The Common Printing Dialog. The GSoC student has started on it with a KDE4 interface. Riddell is mentoring him. Riddell, are you here?
<MacSlow> tkamppeter, I would guess you're missing libpoppler-dev and/or pkg-config perhaps?
<tkamppeter> MacSlow, these two are in place. I have even installed  libpoppler-qt4-dev
<MacSlow> tkamppeter, the I don't know.
<MacSlow> hi njpatel, MagnusR
<njpatel> morning MacSlow
<tkamppeter> Riddell, ping
<asac> err, stupid question, but how do i tell gpg  to use a specific key to --clearsign?
<persia> asac: -k
<asac> hmm
<asac> --default-key worked now
<Riddell> tkamppeter: hi
<asac> persia: -k doesnt work here
<asac> "conflicting command" :)
<asac> --default-key was it
<tkamppeter> Riddell, I am trying to build Alex' Common Printing Dialog on Intrepid. Which packages do I need to installl?
<tkamppeter> Riddell, or should I better do it on Hardy?
<Riddell> tkamppeter: what's the bzr command to check it out?  I'll try it in intrepid
<tkamppeter> bzr branch http://bzr.openprinting.org/devel/common-printing-dialog
<tkamppeter> On Intrepid I get
<tkamppeter> CMake Error at CMakeLists.txt:5 (find_package):
<tkamppeter>   find_package could not find module FindPoppler.cmake or a configuration
<tkamppeter>   file for package Poppler.
<tkamppeter> [...]
<tkamppeter> CMake Error at CMakeLists.txt:6 (PKGCONFIG):
<tkamppeter>   Unknown CMake command "PKGCONFIG".
<tkamppeter> On Hardy cmake complains about missing kde4-config and I have no idea in which package kde4-config is.
<Riddell> -- Performing Test HAVE_POPPLER_0_6 - Success
<Riddell> tkamppeter: works for me in intrepid after installing libpoppler-qt4-dev and libpoppler-dev
<Riddell> tkamppeter: also kdelibs5-dev
<Riddell> tkamppeter: but with you cmake isn't finding FindPoppler.cmake
<Riddell> tkamppeter: what cmake command are you running and where are you running it?
<tkamppeter> The packages you mention are all installed.
<tkamppeter> In the source dir I do
<tkamppeter> mkdir build
<tkamppeter> cd build
<tkamppeter> cmake ..
<tkamppeter> to not mix the built files with the source files ...
<Riddell> tkamppeter: and presumably you have this in the top level CMakeLists.txt?  "set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")"
<tkamppeter> Riddell, yes I have.
<Riddell> hmm, no that's wrong.  it's kde4-dialog/CMakeLists.txt  "set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules")"  which is important
<Riddell> and also cmake/modules/FindPoppler.cmake
<tkamppeter> Yes, I am in kde4-dialog/build and the file is kde4-dialog/CMakeLists.txt
<Riddell> tkamppeter: ah, you are building from the wrong directory
<Riddell> tkamppeter: start your build a directory up
<Riddell> in common-printing-dialog   mkdir build; cd build; cmake ..
<tkamppeter> Riddell, thank you very much. Now I got the Makefile.
<tkamppeter> Riddell, now I could compile it and start it in the background ...
<Riddell> yay
<tkamppeter> ... but I do not get it visible.
<tkamppeter> Ridell I am starting kde4-dialog/cups-dialog.shell and nothing happens.
<Riddell> tkamppeter: same here
<cjwatson> pitti: are you planning to merge belocs-locales-bin?
<tkamppeter> Riddell, do you know by the way in which package kde4-config is on Hardy?
<Riddell> tkamppeter: kde4libs-bin but it is in a non-standard prefix so you will need to use -DCMAKE_INSTALL_PREFIX=/usr/lib/kde4 with cmake
<Riddell> tkamppeter: looking at the code I don't see anything which shows any widgets
<tkamppeter> Riddell, which code? cups-dialog or cups-dialog.shell?
<Riddell> the code that makes cups-dialog, dialog-test.cpp and printdialogmanager.cpp
<tkamppeter> Riddell, you have already shown me a start of Alex' dialog on your laptop. Which code did you use for that?
<Riddell> tkamppeter: that was cups-dialog
<tkamppeter> ls
<Riddell> tkamppeter: but that version had a dlg->show() line, this version does not
<Riddell> a KCPDialog gets made (in printdialogmanager.cpp) but doesn't actually get shown
<tkamppeter> Riddell, so we have a non-working interim version here?
<Riddell> I expect it just needs a show() somewhere
<tkamppeter> Riddell, I can build it also on Hardy, following your instructions.
<tkamppeter> Riddell, as you are more a KDE/Qt expert, can you tell me where to insert the show() or post a patch? Thanks.
 * ogra wonders if his evo got wonky or if others get "Could someone repackage git-core with curl dependency ?" resent about once a week on ubuntu-devel-discuss
<Riddell> tkamppeter: looks like the intention is for the dialog to be run through dbus
<lool> cjwatson: I'm forking the mobile seeds and metas to their own source package (mobile-meta) and bzr branches; I plan to upload mobile-meta, then remove the mobile metas from ubuntu-meta when it comes out of NEW, then removing mobile seeds from the main bzr branch; anything else I should do inbetween?
<tkamppeter> Riddell, I think so, too. The changelog tells that the DBUS interface was introduced.
<tkamppeter> Therefore I have also tried to run cups-dialog in the background and then cups-dialog.shell, but this way nothing happens, too.
<Riddell> tkamppeter: got it http://muse.19inch.net/~jr/tmp/printing-dialogue.png
<Riddell> tkamppeter: 1) in cpd_preview.cpp change QString filename = to a PDF file you actually have
<Riddell> tkamppeter: 2) in printdialogmanager.cpp add "dialog->show();" in PrintDialogManager::CreatePrintDialog() above the "return" line
<Riddell> tkamppeter: 3) compile and run cups-dialog.shell
<cjwatson> lool: does anything of yours rely on Task fields in the Packages files in the archive?
<lool> cjwatson: Not that I know of right now
<Riddell> 4) in qdbusviewer (or whatever the gnome equivalent is) run CreatePrintDialog as in that screenshot
<lool> or ever came across until now
<cjwatson> lool: then I think you should be OK; what is the access control on the new mobile seed branches?
<lool> cjwatson: ~ubuntu-mobile
<cjwatson> and it inherits from the platform seeds?
<cjwatson> I'd be happy to have a look over the seed branch for you when you have it done
<lool> platform.intrepid has been forked as well because germinate was pulling it from the same base
<cjwatson> urgh!
<cjwatson> no please don't do that
<cjwatson> you can pass germinate multiple seed sources
<lool> cjwatson: I didn't think too much about it as it was done like this for hardy and you validated this with StevenK
<cjwatson> platform.intrepid wasn't forked for hardy
<cjwatson> err, platform.hardy wasn't :-)
<cjwatson> at least if it was I didn't validate that bit
<Keybuk> isn't the whole point of the layered seeds precisely so you don't *have* to fork them? :-)
<lool> cjwatson: lp:~ubuntu-mobile/ubuntu-seeds/platform.hardy exists
<cjwatson> exactly
<Keybuk> indeed, doing so could get you into a very fine mess
<cjwatson> lool: that's a bug
<lool> I'm happy to fix this
<cjwatson> lool: please use -S http://bazaar.launchpad.net/~mobile-dev/ubuntu-seeds/,http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/
<lool> Alternatively, I could move the seeds back to ~ubuntu-core-dev
<cjwatson> superm1: you too, please stop having a forked version of the platform seeds, it's bad
<lool> After all StevenK, persia and myself all are
<cjwatson> lool: no, there should be no need to do that
<lool> It might actually be safer
<cjwatson> I'd rather that there be separate access control, even if it isn't mobile-dev
<lool> Seeds might be pulled from other places than the meta packages builds
<cjwatson> but it's up to you; however, whatever you do, don't do it because of this non-problem
<cjwatson> for update.cfg, use:
<lool> So they might directly impact a random cron jobs and I'm not sure I want to give access to everybody in ~ubuntu-mobile to that
<cjwatson> seed_base: bzr+ssh://bazaar.launchpad.net/~mobile-dev/ubuntu-seeds/ bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/
<cjwatson> or similar
<cjwatson> err s/mobile-dev/whatever/g
<lool> cjwatson: I understand I could add it to seed_base
<lool> It's just that it made me realize that perhaps using ubuntu-core-dev made the most sense
<lool> But right, I could use ~mobile-dev
<cjwatson> lool: generally, I'm pushing to have separate products have separate development teams, even if they include ubuntu-core-dev
<lool> Ok; I think this is a good idea too
<cjwatson> I'm not necessarily saying ~ubuntu-mobile as it stands now is right
<cjwatson> but I think you're going to want to add new people without necessarily having time to get them through the ubuntu-core-dev process
<lool> One problem I'll immediately face with a new team is admitting that not everybody in ~ubuntu-mobile belongs there
<cjwatson> mm, that might be a political problem I agree
<Keybuk> ubuntu-mobile-dev ;)
<cjwatson> well, up to you, you at least have a fix to stop you needing platform.* forkage
<lool> It's the same problem :)
<Keybuk> I was going to make a joke about having the same problem with ubuntu-core-dev, but decided that would be very very mean ;)
<lool> I think I'll opt for the easy core-dev solution for now and use the opportunity to not renew some ubuntu-mobile memberships when the times comes
<lool> Keybuk: haha
<lool> Keybuk: Nice way to still make the joke and avoid being mean :)
<lool> Perhaps at some point ubuntu-mobile will reflect a more conservative set of people
<lool> (I didn't mind while the packages were QA-ed before upload, the seeds are different though)
<Keybuk> you can rename teams
<persia> lool: as seeds become more important to archive management, we probably want to change the team membership, as it has a different meaning.  I suspect most current members won't complain if there remains an appropriate place for them to push things.
<Keybuk> I don't see that it'd be politically that difficult to introduce a dev team for people who need upload rights
<Keybuk> and only put those people who are also core-dev into it at first
<Keybuk> since the archive reorg will require everyone to do that, and be careful about their -dev team membership
<Keybuk> since irresponsibility with -dev team membership will make the TB very very angry
<persia> Keybuk: Must it be restricted to core-dev?  There's at least one member of ubuntu-mobile who is not core-dev, but who is likely to modify seeds or otherwise work "critical" ubuntu-mobile packages.
<mvo> soren: I have some trouble here with loadvm/savevm in kvm in intrepid, is this known?
<soren> mvo: With qcow images?
<soren> I belive it broke some time during the hardy cycle due to a security fix.. I patched it in Debian a month ago or so, so we should have the fix in Ubuntu now, too.
<soren> I can check, though.
<Keybuk> persia: no, it need not be, but I'd suggest that the exceptions be carefully considered, since those people would gain upload privileges in the near future
<persia> Keybuk: Very much expected, and understood.  Thanks for the clarification.
<ogra> yeah, lets rather see that we quickly get this person into core-dev :)
<persia> ogra: See, that defeats the point of archive-reorg.  One oughtn't need to be core-dev to work on most things, only if one needs to work on true core applications, shared by many flavours.
<ogra> well, depends how you define "most things"
<ogra> i'D consider seeds for example not to be a common "thing" :)
<persia> ogra: Perhaps, although there are currently several sets of seeds managed in some cases by people who are not ubuntu-dev.  It all depends on what the seeds are expected to grow.
<ogra> ineed
<ogra> and indeed its all bzr, you can maintain your own seed branch and have a privileged person merging it for example
<ogra> thats what xubuntu does atm afaik
<cjwatson> seeds shouldn't need to be a common super-core kind of thing
<cjwatson> and the xubuntu situation is a hassle and is being fixed
<cjwatson> s/a common/an uncommon/
<ogra> no, but there are easy ways to maintain them even without everyone having commit access
<cjwatson> but it's even easier if they do
<ogra> indeed
<cjwatson> w.r.t. getting people into core-dev, yes, that is a useful goal, but we have seen a lot of problems in practice due to assuming that this is feasible in all cases
<pitti> cjwatson: see my activity report; it's essentially a no-op, so I'd do it only for the sake of getting it off MoM
<cjwatson> in practice what this does is block a lot of people from contributing effectively when they have relatively narrow interests
<cjwatson> pitti: ok, well, I wouldn't object to getting another one off MoM, but I realise you have a lot to do
<pitti> oh, I'm on the top of the list now
<pitti> cjwatson: ah, I do it right now for the sake of a clean record; it's a two-minute job, after all
<soren> mvo: Are you suggesting that it used to work, but now doesn't?
<mvo> soren: I'm not sure if it ever worked, but it would be nice if it did :)
<mvo> soren: do you have any information about this, i.e. should it work or is it known that it does not work etc?
<soren> mvo: Are you using qcow{,2} images?
<mvo> soren: yes
<soren> mvo: Ok, due to a security patch we applied at some point in the hardy cycle, savevm with resizing images fails quite horribly.
<soren> Resizing images are qcow, qcow2 and vmdk, AFAIR.
<mvo> hm, ok
<soren> Let me check if my patch from Debian got applied here, too.
<mvo> what can be done about this? switching the imageformat as a workaound?
<soren> mvo: Well, I wrote a patch that fixes it, so we should be fine.
 * soren is still checking if it's applied in intrepid.
<soren> mvo: At least the changelog claims I did. :)
<soren> mvo: What exactly fails for you?
<mvo> soren: aha, I'm just testing the hardy kvm and loadvm seems to be much happier there
<mvo> soren: no keyboard in the guest anymore, segfaults in the guest and sometimes "could not load vm, error -22 or error -1" (intrepid/amd64)
 * mvo does some further testing
<rzr> cjwatson: thx for importing Tuxguitar
<tkamppeter> Riddell, thank you. It works now.
<cjwatson> rzr: no problem
<carlos> hi
<carlos> lamont: around?
<soren> mvo: Really? Would expect hardy's kvm's load/savevm to be rather broken, actually.
<mvo> soren: well, it survived three loadvm, I give it a bit more testing now
<lamont> carlos: yeah
<carlos> lamont: hi. I just send you an email
<lamont> ok
<TheMuso> Keybuk: While working on the initramfs-tools merge, I've noticed that Debian is using /lib/udev/firmware.agent, whereas Ubuntu has /lib/udev/firmware_helper. Are they functionally the same?
<Keybuk> we use firmware_helper
<mvo> soren: hm, hardy/i386 seems to be pretty happy with savevm/restorevm, it survied a bunch of those now (~20?) without trouble, might be a i386<->amd64 problem of course too
<TheMuso> Keybuk: I know. But are they both functionally the same?
<Keybuk> TheMuso: why are you asking?
<TheMuso> Keybuk: Because Debian's initramfs-tools copies firmware.agent into the initramfs.
<Keybuk> we should copy firmware_helper
<TheMuso> Ok I'll check up on that tomorrow. Thanks.
<Keybuk> TheMuso: but initramfs-tools should not do that
<Keybuk> (udev's initramfs hook does that)
<TheMuso> Keybuk: Right, I didn't think so.
<Keybuk> in fact, initramfs-tools should have no references to anything shipped by udev
<soren> mvo: It's possible, but I wouldn't have thought so at all.
<soren> mvo: It problem is that the security fix was written to prevent malicious guests to write outside the boundaries of the disk..
<mvo> soren: I keep you updated, I'm exploring this new and interessting kvm feature right now :)
<soren> mvo: But the way savevm works is that it writes the state in the end of the disk image (so outside the emulated block device boundaries).
<soren> For some reason, this error is never caught, so it's just ignored. You don't notice the breakage until you try to loadvm again at which point it blows up.
<mvo> soren: can a savevm be triggered from inside a guest?
<soren> The fix I wrote just circumvents the boundary check when we're doing savevm (sort of).
<mvo> soren: or how has this become a security issue?
<soren> No, the guest can't trigger a savevm.
<soren> Oh, the security problem is that if you just told the ide controller to write outside the boundary of the disk, qemu didn't prevent it.
<soren> ..which is bad.
<mvo> heh :) now I see
<bimberi> cjwatson: Thanks again for pointing me to 'dpkg --compare-versions' the other day.  It's been ex-sede-ingly useful ;)
<lool> cjwatson: (BTW, fixed platform.{hardy,intrepid} forks)
<cjwatson> lool: great, thanks
<cjwatson> bimberi: you're welcome
<robertknight2> Is there someone here who can look at the possible fix for bug #203016?
<ubottu> Launchpad bug 203016 in network-manager "Memory Leak in NetworkManager" [Undecided,Confirmed] https://launchpad.net/bugs/203016
<mvo> soren: http://paste.ubuntu.com/23088 is what I get when I try a "loadvm" in kvm after I created a snapshot, exited kvm and started it again. as long as keep being in the kvm instance start the snapshot was created with, loadvm seems to work
<robertknight2> network-manager is consumes a hefty amount of memory after a few days uptime.  The patch is trivial so I'm wondering if it could be included in an SRU?
<james_w> robertknight: asac is the person to speak to
<cr3> ogra: to follow up on yesterday, komputes says that he tested the nsc driver upon request from q-funk and it works!
<ogra> yay
<Q-FUNK> cr3: where did he find it and in which version?
<ogra> can he comment on the bug ?
<ogra> Bug 219630
<ubottu> Launchpad bug 219630 in xserver-xorg-video-geode "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Undecided,In progress] https://launchpad.net/bugs/219630
<ogra> thats the SRU
<cr3> Q-FUNK: not sure, I'll have him provide this information in the bug report
<mouz> (sorry if wrong channel: no answer in #ubuntu-testing) Is it OK if tests 2.3 through 2.9 on https://wiki.ubuntu.com/Testing/Cases/ServerInstall are combined (combining the software selection steps)? It would make ISO server testing faster.
<stgraber> mouz: those testcases were written by the server team, it might be better to ask in #ubuntu-server
<mouz> :) ok stgraber thanks
<stgraber> mouz: I often do that kind of combined tests myself for Ubuntu alternates but that's more to get more bugs by creating package conflicts than to do less testing time :)
<soren> mvo: Oh, that might very well have an impact, yes.
<soren> mvo: I always assumed that the procedure was start->do stuff->savevm->quit->other stuff->start again with the snapshot.
<mouz> stgraber: that implies it is better to not combine
<mvo> soren: kvm -loadvm snapshot gives me the same message
<mouz> stgraber: (for me, doing iso testing)
<mvo> soren: or is there a different command to use?
<alex-weej> why is mlocate raping my notebook disk when i'm on battery?
<soren> mvo: No, that's the right one.
<alex-weej> in fact, why do we even have it on the Desktop installation at all?
<alex-weej> if i open a bug for removing it, will i be laughed at?
<soren> Good question.
<soren> Both of them :)
<alex-weej> :P
<wgrant> alex-weej: We only just got rid of slocate.
<wgrant> mlocate was a compromise, IIRC.
<alex-weej> what's the difference?
<soren> One could make the argument that now that there's a server-install seed, it makes sense to remove it from standard.
<wgrant> mlocate doesn't reread the whole disk each time.
<alex-weej> right, timestamps
<alex-weej> i will open a bug against ubuntu-standard
<wgrant> You probably want to reread the discussions from Hardy.
<cjwatson> alex-weej: are you sure it's mlocate? do you have dlocate installed?
<cjwatson> alex-weej: because dlocate can't yet work with mlocate and needs findutils installed, so that set of cron jobs will still run
<cjwatson> alex-weej: I would resist removing mlocate; it's a lot better and it's worthwhile, even if you personally don't use it. Also, it's only a Recommends so you can remove it without removing ubuntu-standard if you choose. We can always make it better-behaved on battery
<alex-weej> cjwatson: i'm just worrying about energy efficiency
<alex-weej> and unnecessary disk thrashing
<alex-weej> granted, it IS a lot better
<alex-weej> but it's still useless for the vast, vast majority
<alex-weej> If anyone has any business in a) using CLI tools, b) looking outside their home folder, c) looking at raw file system hierarchy and d) requiring to find a file based on filename alone, they are definitely in an extreme minority
<cjwatson> I have difficulty believing that it is in fact significant unless something is going wrong
<alex-weej> yes, it is causing climate change.
<cjwatson> sigh. /ignore time I guess
<cjwatson> sorry, I'm not having a conversation on these terms
<alex-weej> oh... CC denier... :P
<cjwatson> using a computer causes climate change
<cjwatson> so I expect this channel to vacate immediately
<alex-weej> lighten up
<cjwatson> personally, I prefer to be able to use my computer efficiently when I need it, and spending a little time on mlocate every so often is much more efficient than having to run whole-filesystem find tools when looking for something
<alex-weej> cjwatson: but dpkg -S already searches package installed files
<cjwatson> and I don't buy arguments based on most users being naive and never looking outside /home, myself
<alex-weej> and we already have Tracker
<alex-weej> anywhere outside /home isn't even writeable for default users...
<cjwatson> you're claiming that tracker is more efficient than mlocate? :-) We turned it off for a reason!
<cjwatson> most users in fact do name their files something vaguely meaningful
<alex-weej> like DSC419535.jpg ?
<cjwatson> now, I think we should make the locate database easier to get at from the desktop
<cjwatson> not throw it out
<ogra> ++
<ScottK> alex-weej: We've had this arguement like at least 5 times and where we are now is a reasonable compromise.
<Ng> +9999999
<alex-weej> ScottK: fair enough. we should at least make it obvious that you can remove it if you want to know why your disk is going tickticktickticktick when you're on battery
<cjwatson> it shouldn't run while on battery, as I said above
<cjwatson> that's a bug
<alex-weej> or even at all... FDO notification icon
<alex-weej> i can just about deal with stuff installed on the default seed that is used by a small portion of users that does nothing but take up disk space when not in use (HPLIP, Palm OS stuff, etc.)
<seb128> alex-weej: or drivers for the hardware you don't have, etc too
<seb128> alex-weej: or rhythmbox support for ipods
<ogra> pitti, i.e. i find the comments and ideas of the pardus guys on the hal list scary but still they might have something etc ...
<pitti> ogra: pardus is pretty new, isn't it? I haven't seen it yet
<ogra> pitti, the thing is that we seem to not even look around anymore (i'm including me here) due to time constraints
<ogra> which probably makes us lose good opportunities
<alex-weej> seb128: none of that code runs once a day to make a stale filesystem database slightly less stale
<pitti> ogra: *nod*
<seb128> alex-weej: neither does hplip, palm os, etc
<alex-weej> exactly! that's why i can accept it! :P
<seb128> oh, I misread your comment
<cjwatson> mlocate (0.20-2ubuntu1) intrepid; urgency=low
<cjwatson>   * Skip cron job if on battery power.
<cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Thu, 26 Jun 2008 15:19:06 +0100
<alex-weej> show off
<seb128> alex-weej: anyway you might want to read the ubuntu-devel archives for the discussion about the locate tools
<seb128> there is some users using those a lot
<alex-weej> seb128: nothing could be less exciting tbh, i just got angry and caught up in the moment
<persia> cjwatson: Is that a raw skip, or will it retry if later on mains power?
<cjwatson> persia: raw skip. it'll catch up the next day
<seb128> and the gnome search tools dialog do too for example, etc
<cjwatson> I was applying KISS
<wgrant> cjwatson: Is your clock really fast?
<persia> cjwatson: Makes sense.  I was asking in hopes of seeing the magic required to catch up on mains power,
<cjwatson> wgrant: it is a few minutes fast, yeah
 * persia anticipates devices that are never both powered on and on mains
<cjwatson> persia: afraid I don't know such magic offhand ...
<cjwatson> you could possibly cobble it together with anacron
<persia> cjwatson: That seems to be a common state :)
<ogra> well, you could surely add a switch to it
<cjwatson> I could have done, but like I say, KISS
<ogra> if you know you are on such a device you cn change behavior
<persia> ogra: Some sort of trigger that caught the appropriate ACPI signals, and caught up on missing actions at that time?
<alex-weej> can you not defer the job and use acpi.d to ask it to catch up?
<alex-weej> like make it so the job does not get marked off as complete
<alex-weej> can you do that with anacron?
<cjwatson> patches welcome; I had five minutes and did a five-minute hack
<ogra> persia, well something like a config option you can set on devices that never are on mains for exmple (or rarely being swithced on in this situation)
<cjwatson> in fact, /etc/acpi/ac.d/85-anacron.sh already starts anacron when power is plugged back in
<cjwatson> so I expect that either this already works out of the box or can easily be made to
<alex-weej> cunning
<cjwatson> at most, it might need to rerun jobs that exited non-zero, or something like that
<persia> cjwatson: It's "can easily be made to": we'd need to wrap stuff.  It's just a matter of appropriate use case construction.
<cjwatson> although admittedly anacron runs cron.daily not individual jobs so that's a little harder
<persia> Well, anacron could be convinced to act differently, but that impacts cron, etc.
<asac> robertknight2: looking at it now
<mvo> evand: this python-apt crash you mentioned, is there a bugreport about that yet?
<superm1> cjwatson, yeah i know :( didnt expect the breakage during hardy and couldnt sort it out quickly so it was a hack to make things get out the door
<cjwatson> superm1: I filed a bug with a patch attached
<superm1> cjwatson, oh wonderful.  thanks
<evand> mvo: https://bugs.edge.launchpad.net/wubi/+bug/243105
<ubottu> Launchpad bug 243105 in wubi "When Wubi is installed from CD, ubiquity crashes at the end of the installation" [High,In progress]
<MacSlow> seb128, regarding order of task... first I'll goffice/gnumeric... once I've that nailed down gdm?
<seb128> MacSlow: alright
<asac> robertknight2: fix committed. for now
<asac> to intrepid
<MacSlow> seb128, any hints for goffice you can give me right away off the top of your head?
<mvo> evand: thanks! does the diff of cjwatson fixes the problem?
<laga> cjwatson: thanks for the fixed branch.
<kirkland> why does Synaptic sometimes report "The list of changes is not available yet." ?
<evand> mvo: not in my first try, but I'm going to give it another go just to be sure.
<seb128> MacSlow: I need to look at it, will do that in a minute
<MacSlow> seb128, cool thanks
<mvo> kirkland: it gets it from a cron job that is run only every 4h
<mvo> evand: ok
<kirkland> mvo: "it" being my client worstation, or "it" being something on the ubuntu server side?
<kirkland> mvo: why would it not just pull that down, too, when it decides that changes are available?
<mvo> kirkland: the ubuntu server side. we have "changelogs.ubuntu.com" that has static copies of the changelog files
<mvo> kirkland: those get updated every 4h as it has to crawl over all of the (new) deb packages
<cjwatson> evand: it was just a guess, of course
<kirkland> mvo: hmm, could it pull it from Launchpad?  This seems to be updated almost immediately: https://edge.launchpad.net/ubuntu/hardy/+source/openssl/0.9.8g-4ubuntu3.3
<kirkland> mvo: or at least print a link to that in Synaptic, if it hasn't been cached yet
<mvo> kirkland: there are potentially a lot of requests, not sure how well launchpad would cope
<mvo> kirkland: having a fallback link is a very good idea
<evand> cjwatson: understood, I just want to be sure that I didn't make a mistake in applying the patch before moving on to the next idea.
<mvo> kirkland: the whole extraction code is currently not very clever, it could certainly be much faster, but it is not currently
<mvo> kirkland: (the extraction code on the server)
<kirkland> mvo: gotcha
<kirkland> mvo: i'm just bothered sometimes when Synaptic knows that an update is available, but can't tell me what it's going to (try to) fix
<mvo> kirkland: I think I will add the fallback link right away (easy)
<kirkland> mvo: cool!  thanks
<mvo> kirkland: a LP export to a static file or a much faster extractor is probably the right answer, I should really look into that code again
<kirkland> mvo: yeah, totally
<kirkland> mvo: all the headers and LP fluff is totally extraneous
<cjwatson> evand: a giant strace dump is probably the next requirement
<evand> ok
<cjwatson> o gst-plugins-ugly0.10: gstreamer0.10-plugins-ugly-dbg gstreamer0.10-plugins-ugly-doc
<cjwatson>    [Reverse-Depends: Rescued from gst-plugins-ugly0.10]
<cjwatson> thanks, component-mismatches, that's really helpful. WHY?
<cjwatson> ah, <- gstreamer-dbus-media-service <- moblin-media
<cjwatson> mvo: can you help me with bug 242815? I can't see anything to do with base-passwd in the detailed log
<ubottu> Launchpad bug 242815 in base-passwd "package base-passwd 3.5.17 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/242815
<mvo> cjwatson: hm, the attached log looks corrupted?
<cjwatson> mvo: I'm not sure what it's supposed to be like, I must confess
<mvo> cjwatson: it should be a log of the dpkg terminal output to make pinpointing the problem a bit easier
<mvo> cjwatson: I added a needinfo and asked for the /var/log/apt/term.log file
<cjwatson> thanks
<james_w> mvo: we ask for that and ../dist-upgrade/... a lot, is there any way they could be included automatically?
<mvo> james_w: the current version in hardy-updates should add it automatically, there was a bug in stock hardy that prevented this for a  lot of cases
<james_w> mvo: great, thanks!
<geser> pitti: thanks for the apache2-mpm-itk upload
<cjwatson> superm1: also, I think you may need to actually *remove* the old platform.intrepid branch if possible (or else switch the order of base URLs in seed_base) in order for that change to be effective
<mvo> kirkland: the fallback link is now in bzr, thanks for the idea
<kirkland> mvo: no problem!
<superm1> cjwatson, i reordered it in that update.cfg and removed the branch afterward
<superm1> thanks
<cjwatson> ok, cool
<kirkland> mvo: the "complaint" came from timrc in another channel, and I kinda said, "Yeah, that annoys me too..."  :-)
<mathiaz> james_w: I'm trying to figure out how to use bzr looms to handle the patches between debian and ubuntu for the openldap package.
<mathiaz> james_w: how would you recommend to handle the changelog ?
<james_w> these are patches in debian/patches/ or directly to the source, or just debian/ changes?
<james_w> or all three?
<mathiaz> james_w: there is a whole bunch of patches related to adding apparmor support which I plan to track in one thread
<mathiaz> james_w: only in debian/
<mathiaz> james_w: to give you more background, all of openldap upstream code is in the debian svn repository
<mathiaz> james_w: http://svn.debian.org/viewsvn/pkg-openldap/openldap/trunk/
<james_w> yeah, changelog is not easy to handle this way
<mathiaz> james_w: so I've branch the debian svn repository from the last debian upload
<james_w> perhaps the best is just to have a "changelog" thread at the top and only modify the changelog in that.
<mathiaz> james_w: right - that's what I thought doing
<mathiaz> james_w: maintaining relevant changelog bits in each thread seems to complicated
<james_w> yeah, it kind of makes sense to have them there, so you can tweak them as you make changes, but you will get conflicts galore.
<james_w> and the threads will live across versions, so that maybe makes it not such a great idea.
<cjwatson> RAOF: is it OK to sync gnome-do-plugins from Debian? it replaces your do-plugins package
<mathiaz> james_w: right - I'll use a unique thread for the changelog then
<mathiaz> james_w: may be one day dch will support loom threads and change to the changelog automatically :)
<james_w> mathiaz: cool, let me know how it goes, I'm interested to see how it works.
<james_w> mathiaz: heh, one day :-)
<cjwatson> RAOF: I guess it probably is since you're in Uploaders on the Debian side too - but one obvious problem is that the new gnome-do-plugins needs to declare Replaces on gnome-do-plugin-amarok and gnome-do-plugin-rhythmbox, surely?
<pitti> Riddell: ISTR that someone asked me to stop using guidance-backends in Jockey (currently discussing this with tseliot); is it obsolete? dead upstream? what's the replacement in KDE?
<Riddell> pitti: it's pretty obsolete, xorg.conf has changed a lot and it makes lots of assumptions which are no longer true
<Riddell> pitti: the replacement is just to use xrandr
<pitti> Riddell: ah, so it entirely stops changing xorg.conf and thus the parser/writer won't be shipped at all any more?
<pitti> Riddell: tseliot currently creates a library and some backends for doing xorg.conf changes, such as configuring the virtual screen resolution (necessary for configuring dual-head)
<Riddell> pitti: guidance displayconfig is going away, replaced by a new xrandr tool
<pitti> Riddell: ok, thanks for the heads-up
<pitti> I'll see to replace it in Jockey then
<pitti> asac: oh, still working on NM 0.6? I thought we'd switch to 0.7 in intrepid?
<asac> pitti: we will. but since i received a patch which might be suitable for hardy SRU, i thought I'd let it bake in intrepid while 0.7 is not yet there :)
<asac> pitti: probably the last upload of 0.6 to intrepid
<asac> ;)
<pitti> ah, good to know
<asac> i just wanted to close an opened changelog ;)
<soren> So... Does anyone feel like merging initramfs-tools?
<Tm_T> hi sladen :)
<calc> anyone know if nvidia resumes better from sleep than nv driver?
<calc> i put my system to sleep last night and the video won't come back i think it is using the nv driver
<calc> yea it was using 'NV"
<mathiaz> james_w: hm - I'm lost now with bzr looms. I've created an apparmor thread and put all the the bits related to apparmor in it. After that I realized that the other patches I wanted to applied needed to be in threads below the apparmor thread. So I created threads below and add the relevant patches to them.
<mathiaz> james_w: now I've realized that there is one missing bit in the apparmor thread - I go up to the apparmor thread to add it. But now I see all the previous merges in the apparmor thread.
<mathiaz> james_w: ie merges == threads that I created below.
<mathiaz> james_w: what should I do now ?
<james_w> I'm not sure I understand.
<mathiaz> james_w: http://paste.ubuntu.com/23156/
<james_w> you have just done "up-thread" to the apparmor thread, and now you see merges in "bzr log" of each of the threads that you added underneath?
<mathiaz> james_w: I see pending merges in the apparmor thread.
<mathiaz> james_w: and all the merges are related to the threads below.
<james_w> yeah, when you do "up-thread" it does a merge to make sure that everything will still fit together.
<mathiaz> james_w: so now I have to commit the merge in the apparmor thread
<mathiaz> james_w: this is like "refresh patches for new upstream version"
<james_w> yeah, it's like when using quilt. If you change a patch in the middle of a quilt stack you should refresh that patch, and then push all the way to the top, fixing up conflicts and refreshing where needed.
<james_w> what loom does is analogous to this, but it uses merges to make sure that there are no conflicts.
<mathiaz> james_w: cool - thanks :)
<james_w> no problem.
<pitti> calc: on my desktop, nv resumes from disk nicely (for ages, since hoary or so); nvidia never *ever* worked
<cjwatson> soren: TheMuso is working on it
<calc> pitti: ah ok
 * calc thinks his machine just won't resume in that case :-\
<calc> it is amd64 instead of i386, so maybe its not uncommon for that not to work
<soren> cjwatson: Excellent, thanks!
<zul> slangasek: ping, whats up with the samba changes due to the gvfs stuff?
<mouz> TheMuso: grub fails to install with the server iso also. I just saw you encountered it with the alternate ISO.
<cjwatson> yeah, I'm debugging it now
<cjwatson> it's an apt-setup bug
<cjwatson> little bit of a slow process because I have to get through base-installer before it goes wrong
<cjwatson> wow! that's such a cool bug
<cjwatson> it breaks because it uses a local variable 'file' but doesn't initialise it; file=/cdrom/preseed/ubuntu.seed is passed on the kernel command line and this gets exported to an environment variable 'file' along the way
<ScottK> pitti: I'm reading http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/122-Migrating-Emdebian-changes-into-Debian,-not-Ubuntu.html and thinking the package should be removed/blacklisted.  What do you think?
<bryce> calc: you're right that Benjamin Drung is a good tester
<bryce> calc: so he's finding that yes, disabling xcb makes the problem go away, however as a side effect, it also prevents compiz from working.
<bryce> calc, so given that, I won't be pushing the noxcb change, and we'll need to identify a different way to fix this bug.
<bryce> (although I should doublecheck Ben's conclusion that compiz depends on libx11 w/ xcb)
<slangasek> zul: the samba changes due to the gvfs stuff are sitting in -proposed, waiting to be copied over to -updates
<zul> ok any other regressions (just curious)
<calc> bryce: can compiz be rebuilt against the new libs and not need xcb?
<calc> bryce: it might have just been an overly aggressive linking
<bryce> calc: I had assumed so, but Ben investigated that and found compiz doesn't provide a way to easily disable its xcb dependency.
<calc> bryce: oh
<calc> so how did we get by before x11 linked to xcb?
<bryce> calc: and even if we could fix that, it makes me apprehensive at what other things might now be depending on xcb...   which would make SRU'ing this to hardy quite hard
<calc> wasn't that just added ~ 2 months ago?
<bryce> calc: thus my surprise
<bryce> calc: http://pastebin.osuosl.org/8778
<calc> bryce: i don't know how this works in detail, but couldn't compiz just rebuild against libxcb1-dev also?
 * calc will download the source and take a look at it
<bryce> calc, well looking at Ben's crash error, compiz seems to be directly linking to XGetXCBConnection
<bryce> perhaps there is a non-xcb version of that routine, or perhaps the call can be ifdef'd out
<bryce> I'm curious about ben's suggestions on fixing the bug in openoffice.org-gtk or openoffice.org-core
<calc> well xcb existed before x11-xcb patches in ~ april of this year, right?
<calc> iirc it has existed for ~ 4-5 years
<calc> well if we could even determine what is causing the crash in ooo-gtk then maybe it could be fixed
<bryce> yeah it's been around for quite some time, but I don't think many distros have shipped it, at least not until recently
<calc> but it isn't reproducible so it would be hard to verify if it was fixed as well
<bryce> agreed - given the non-triviality of fixing it in compiz, and the chance that other apps may surprise us with sudden new xcb dependencies, if we can work around it in OOo, that'd probably make the easiest SRU to justify
<bryce> in any case, the fact that it is definitely due to something in xcb gives us a strong hint
<calc> well that is the thing i have no idea how to fix it in OOo as I can't even get the problem to occur
<calc> i have been trying for a week or various systems and archs
<calc> even the users who have the problem create a new account and it is fixed for them as well
<calc> but deleting their openoffice.org config files doesn't help
<calc> so its outside of the ooo settings that is causing the problem (i guess?)
<bryce> calc, have backtraces been collected?
<calc> maybe, i'll have to see if i can find a good backtrace out of the dupes
<calc> hmm x11-xcb didn't exist in gutsy, so i guess compiz added requirement for it since then
 * bryce nods
<calc> bryce: maybe we need to get him to submit a full apport crash bug
<bryce> mvo could probably give us some background there if we need it
<bryce> yeah
<calc> the ones i have seen have backtrace but with just hex addresses
<bryce> calc, ben sent me a strace of it, let me forward to you...  calc@ubuntu.com?
<calc> ccheney@ubuntu.com
<mathiaz> james_w: \o/ - I've finished imported ubuntu openldap version in a loom based bzr repository. Looks like this now: http://paste.ubuntu.com/23178/
<mathiaz> james_w: I've used bzr record to record the last upload to intrepid - 2.4.9-1ubuntu3.
<mathiaz> james_w: is there a way to see the list of records ?
<calc> bryce: i wonder if this bug is related to another Xrandr bug i found that causes crashes
<calc> bryce: apparently Xrandr sometimes is getting mapped in twice
<bryce> hmm
<calc> i can update the build to current ooo-build and have him test it and see if it fixes his problems :)
<calc> it definitely looks like the updates fix some of the non xcb backtrace crashes i have seen reported recently
<calc> not certain if it fixes those as well though
<bryce> possibly, but I don't think there's a huge overlap between xrandr and xcb.  They probably do interact at some level, but xrandr issues I'd expect to look differently than this
<calc> it might end up that users that have -gtk installed see xcb crashes and users with -kde see the other crashes i am getting
<bryce> oh that'd be interesting
<calc> might be a different bug entirely though
<calc> but it would be good to get the one that affects -kde users in any case
<bryce> calc: do you have a changelog entry in the latest updates that mentions anything that might be related to this issue?
<calc> and if it fixes the -gtk issue as well then great ;-)
<calc> https://bugzilla.novell.com/show_bug.cgi?id=398244
<bryce> (maybe we could dig in and see if we could extract a patch)
<ubottu> calc: Error: Could not parse XML returned by bugzilla.novell.com: not well-formed (invalid token): line 54, column 0 (https://bugzilla.novell.com/xml.cgi?id=398244)
<calc> this is the bug report that i found a report of in ooo-build
<bryce> ok
<calc> and it specifically references an upstream bug report about crashing on 64bit
<calc> which most (all?) the users with this bug seem to be 64bit users (iirc)
<bryce> mmm, bad file descriptor
<bryce> xcb locking issues can produce "bad fd" errors
<bryce> calc, did you see this?  https://bugzilla.novell.com/show_bug.cgi?id=398244#c17
<ubottu> bryce: Error: Could not parse XML returned by bugzilla.novell.com: not well-formed (invalid token): line 54, column 0 (https://bugzilla.novell.com/xml.cgi?id=398244)
<bryce> calc, it's interesting that in ben's strace it shows a crash in libvclplug_gtk680lx.so
<calc> bryce: yea very similar to the gtk one
<bryce> so I think you're maybe right that this bug report is related
<calc> which was why i was thinking it might just look different between the two libs
<calc> they both crash in the vclplug but with different backtraces :)
 * bryce nods
<calc> i'll try to get a build going here within a few hours to have him test tomorrow (takes around 4hr or so to build)
<bryce> are these managed in a public VCS somewhere?  might be useful to look at their changelogs
<calc> if you want to email him back let him know i am creating new test ooo debs to see if it resolves the issue
<calc> yea
<calc> svn.gnome.org ooo-build
 * calc finds the full url
<calc> svn+ssh://svn.gnome.org/svn/ooo-build/branches/ooo-build-2-4-1
 * calc hopes the ooo-build diff is small
<bryce> ah, re: the multiple-xrandr mapping issue I see in comment #23 it mentions this; however you can see they fixed that issue in #24, and then a user says in #25 the issue still exists.  So sounds unrelated
<bryce> #25 has a nice backtrace with symbols
<calc> it sounds like even thought it was fixed it wasn't in the official build the user was using at the time yet
<bryce> looks like the crash is occuring within destructors - does that make sense with your understanding of the problem?  that it occurs when shutting things down?
<calc> on the kde crashes that sounds right, not sure about the gtk side
<calc> users have mentioned it crashes on exit under kde
<bryce> ahh, you're right - #31 that user confirms it's fixed
<bryce> so maybe it *is* xrandr being double mapped into the app
<calc> 11KB of patches since our last upload
<calc> so not too bad
<bryce> mm, I can imagine that such a thing could potentially result in xcb requested to do two locks, thus resulting in a locking error
<calc> i probably can get slangasek to approve that if it fixes the issue :)
<bryce> awesome
<bryce> ok, I'll email ben this info
<slangasek> bryce: bah ... -nsc accepted, but you left out the LP bug # in the changelog. :)
<calc> i also have two meetings tomorrow to prepare for so i will do my best to get this ready for him to test
<bryce> doh
<calc> it shouldn't take more than an hour to setup
<calc> i'm creating a new chroot for it at the moment
<bryce> mail away (cc'd you too)
<slangasek> bryce: also, did Q-FUNK mention anything to you about fixing up -geode wrt https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-nsc/+bug/219630/comments/50?  I guess I was expecting some feedback from him about whether this would happen; I'll push the currently-available upload through if necessary due to the severity of the issue and the timing, but would really like to see those buglets fixed
<ubottu> Launchpad bug 219630 in xserver-xorg-video-geode "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Undecided,In progress]
<bryce> slangasek: indeed yes, we were discussing that last night.  I asked if he needed my help on that too, but it sounded like he felt he had it under control, let me dig up the exact discussion...
<mkrufky> mario_limonciell: ping
<mkrufky> oops
<bryce> <bryce> Q-FUNK: ok.  you may want to update the state for the -geode/hardy task
<bryce> <Q-FUNK> geode/hrady is still to be done
<bryce>  I'd need to clena up the chnagelog as steve suggested
<bryce>  geode/intrepid is what's done (transition in -all, plus latest upstream package via debian)
<bryce> * bryce nods
<bryce> earlier in the discussion, "I think that -geode was the only one where he'd rather have me finetune the changelog, before we'd move ahead."
<slangasek> bryce: well, he doesn't seem to be around, so I'm not thinking it's under control given that I had asked for that upload to happen last night
<bryce> slangasek: I can take care of it right now, if you point me at what needs fixed
<slangasek> bryce: let me extract this upload and dump it to chinstrap
<slangasek> er, I mean rookery :)
<slangasek> bryce: http://people.ubuntu.com/~vorlon/xserver-xorg-video-geode_2.9.0-1ubuntu2.2.dsc , just needs the two fixes I mentioned in that bug log
<bryce> great, on it.
<mitsarionas> hi all... does anyone know when intrepid alpha 1 is gonna be released?
<calc> mitsarionas: sometime this year :)
<mitsarionas> lol good to know :)
<calc> mitsarionas: i think the hope was for friday(?)
 * calc points to slangasek
<mitsarionas> i'm getting bored without those dozens of daily updates
<slangasek> the hope was "today", but the time machine that normally lets us release images before we fix the installation problems is on the fritz
<zul> slangasek: is there 8.04.1 for ubuntu-server cdimages?
<calc> lol :)
<slangasek> zul: posted at http://iso.qa.ubuntu.com/qatracker/build/all/all
<mitsarionas> lol :) glad it's getting out these day though
<zul> slangasek: thanks
<Gadi> Hi, all.  I have an interesting trident video driver issue, perhaps someone has run into?
<Gadi> trident driver + Xorg 1.3.  Everything works fine, except after a period of time, the USB controller dies completely and the USB mouse stops working
<Gadi>  its as if the driver is writing over the USB controller's memory space
<Gadi> I only ask the question here, because I am not sure where to go upstream with this
<Gadi> and I was hoping maybe an Ubuntu Xorg guru may have seen this or know a workaround to limit the memory space the server will use
<bryce> Gadi: how are you determining it's a video driver issue?  If it's a USB controller failing, my first guess would be it's a kernel issue...?
<Gadi> because it affects only trident driver hardware and the same hardware is unaffected if it uses vesa driver
<Gadi> also, it happens after extended use of the xserver (over a period of days)
<slangasek> hrrrm, looks like we have some packages now being auto-synced that build-dep on a newer debhelper than what we have in intrepid
<Gadi> it is very repeatable on the same trident-driver hw platform
<Gadi> (VIA EPIA-5000 mini-itx mobo)
<bryce> Gadi, it's not something I've seen, but trident is not a very common driver
<bryce> Gadi: usually it's better to make bug reports like these to Launchpad than here on IRC
<Gadi> fair enuff
<Gadi> thanks
<bryce> also, just because it works with -vesa does not necessarily mean it's not a kernel issue, but that's a good data point
<ogra> Gadi, is that any disklessworkstation machine ?
<ogra> i could probably verify
<Gadi> i dont know if they have one that uses that mobo
<Gadi> I can ask Jim
<ogra> well, you said scott has it too
<Gadi> thx, ogra
<Gadi> yeah
<bryce> I think you'd want more evidence that it was definitely an X issue before going upstream to freedesktop... perhaps take a look at the debugging handbook at wiki.ubuntu.com/X as a start
<ogra> he only has DW i think
<slangasek> kirkland: -server images published now that have the right apt-setup; I'll post them to the ISO tracker shortly, but you can grab them already from current
<kirkland> slangasek: thanks, downloading...
<bryce> slangasek: does this description look right now?  https://bugs.launchpad.net/ubuntu/+bug/219630/comments/65
<ubottu> Launchpad bug 219630 in xserver-xorg-video-geode "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Undecided,In progress]
<slangasek> bryce: I would s/static xorg.conf's/your configuration/
<bryce> ok
<slangasek> to avoid the nastiness of trying to pluralize a filename :)
<bryce> yeah that reads better
<bryce> slangasek: ok uploaded
<slangasek> bryce: thanks, wll watch for it in the queue
<bryce> slangasek: I'm not sure I fully grok how this is going to affect people using "amd" in their xorg.conf's, but I'll trust you and martin here; I'm probably just not correctly understanding it
<slangasek> bryce: well, previously there was an 'amd' symlink, which has gone away for $obscure_ltsp_reason; now it's not there, so anyone whose xorg.conf references amd will definitely find themselves without a driver
<slangasek> so the xserver-xorg-video-amd transitional package is solely for dependency purposes, at this point; it doesn't provide backwards-compat for xorg.conf
<mitsarionas> when it says that the kubuntu intrepid isos are rebuilding, does it mean like right now?
<bryce> slangasek: ok, that's sort of how I interpreted it...  I guess I'm not understanding how this won't anger users who now have to modify xorg.conf?
<slangasek> bryce: I'm not sure that it won't.  Do you have time today to implement a better fix, perhaps one that updates xorg.conf?
<slangasek> bryce: or do you want me to sit on this upload (in -proposed, perhaps) until you can talk to Q-FUNK about why this is needed?
<bryce> hmm
<bryce> ogra: do you have any insights/opinions here?
<bryce> slangasek: well, I'm curious what exactly breaks in LTSP when the symlink is present, and if we could allow that to remain and perhaps just handle it better
<bryce> slangasek: however I know we're pressed to get 8.04.1 done and q-funk really wants this change included.
<slangasek> bryce: yes, I share that concern.  pitti did question that change in the bug log, and in the end approved it, I wasn't intending to second-guess him on that
<bryce> if I understand this changeset correctly, the symlink change is separate from the pci id change
<slangasek> it is, yes
<slangasek> hrm, why does xserver-xorg-video-amd Conflicts/Replaces xserver-xorg-video-geode?  that's... backwards
<slangasek> I didn't notice this in the previous upload, hrm
<slangasek> right, sure enough, it was there
<ScottK> pitti: I am hoping you have some time for MIR processing on your archive day tomorrow.  I added a bunch onto the stack.
<kirkland> slangasek: cjwatson: nice, that one installed!
<slangasek> \o/
<slangasek> pitti: do you mind if I do an updated debhelper merge?  there are some packages coming in with a versioned build-dep on the newest debhelper
<james_w> mathiaz: no idea if you can get the list of records easily. I'm sure there's a way with python, but I couldn't tell you it.
<james_w> mathiaz: you might want to file a bug on bzr-loom.
<bryce> slangasek: yeah I think this upload needs a bit more thought.  unfortunately I think this may require more packaging-fu than I have at hand
<slangasek> bryce: hmm, ok
<mathiaz> james_w: IIUC, record is the way to say "this is 3ubuntu2."
<mathiaz> james_w: right ?
<james_w> record is a way to make loom do it's thing so that someone else can branch/pull/merge the loom sensibly I think
<james_w> I don't know if it's also used for recording interesting points
<james_w> I've never fully grabbed it.
<james_w> s/grabbed/grasped/
<slangasek> bryce: if I can find time to work up some maintainer script magic for this in the next day or so, I will; but no guarantees on that front
<bryce> slangasek: ok; I'm going to spend the next couple hours studying it myself
<bryce> slangasek: I also want to compare with what was done in the -i810/-intel transition, since that seems very analogous to this
<slangasek> ok
<bryce> I'd also like to look into what that ltsp issue was
<slangasek> kirkland: are you also going to be testing server amd64, or does someone else have that task?
<kirkland> slangasek: i'm doing it now ;-)
<slangasek> ok
<liw> so what's the status of alpha1 ISO image testing?
<kirkland> slangasek: which just succeeded ;-)
<liw> really nobody has tested the alternate images?
<slangasek> liw: apt-setup was found broken yesterday so we had to get an updated package in and respin ISOs; I don't have any results reported yet for ubuntu alternate yet
<slangasek> since those images just became available in the past 2h
<liw> ah, ok, I'll update and test, then (assuming qemu is still OK)
<slangasek> yes, definitely
<liw> I found the apt-setup problem also
<kirkland> slangasek: i'll do the LVM & encrypted LVM now
<mitsarionas> any idea when the new kubuntu isos will be available?
<slangasek> kirkland: not required for alpha 1 (i.e., any failures you find there won't prompt me to respin), but feel free
<kirkland> slangasek: oh, well then :-)
<kirkland> slangasek: i've plenty else to do!
<mathiaz> slangasek: which tests are required for alpha1 ?
<slangasek> mitsarionas: kubuntu has some metapackage issues that the kubuntu team haven't sorted out yet; as such, kubuntu will probably miss out on alpha1
<slangasek> mathiaz: "it installs, ship it!"
<mitsarionas> :((((
<Better_than_you> Will Kubuntu 8.10 LTS ship KDE3 or 4?
<liw> slangasek, what test coverage are you interested in? all test cases for the alternate images? any one? should I aim to do all of one arch and then start on the other?
<slangasek> Better_than_you: a) 8.10 will not be an LTS release; b) 4
<liw> slangasek, given that I can do two or three at a time
<slangasek> liw: one good install for each image is all we require at this stage
<Better_than_you> I thought Kubuntu 8.10 was LTS since they delayed it for 8.04
<slangasek> liw: if you have spare resources, a test of edubuntu would also be good
<liw> slangasek, my main restriction is my brain
<liw> 20080626 is the version to concentrate on?
<slangasek> liw: the versions posted at http://iso.qa.ubuntu.com/qatracker/build/all/all
<slangasek> mm, except edubuntu was respun but the version number not updated there, sec
 * liw starts on alternate i386 and amd64
<slangasek> there, that's better
<pwnguin> bryce: isn't syncronization and IPC fun?
<bryce> pwnguin: :-)
 * liw remembers that it's not a good idea to share the same qemu image file between different instances
<cjwatson> kirkland: woo
 * liw introduces head and desk
<pwnguin> this probably is why locking should let processes who own locks through :(
<lifeless> liw: you 'testing' again ? :)
<liw> lifeless, ISO images for intrepid alpha1, yes
<lifeless> well I was referring to dual-mounting disk images :)
<lifeless> that would count as cluster fs testing surely :)
<liw> that was just a mistake :)
<liw> lifeless, I did, however, have the pleasure of import .git into bzr yesterday :)
<lifeless> lol
<liw> lifeless, I was looking at packages to merge from Debian, and using bzr to keep track of what I do to them, and one of the packages had a .git directory
<liw> (which _I_ think should be cause for rejecting an upload into Debian, but hey...)
<lifeless> hmm
<lifeless> bzr should default-ignore that perhaps
<liw> lifeless, since it works, I'm fine with bzr doing that; if .git gets default-ignored, then so should the others: .svn, .hg, CVS, *,v, RCS, {arch}, and whatnot
<lifeless> liw: we do default ignore some :)
<kirkland> slangasek: okay, i completely lied......
<liw> lifeless, incidentally, my life would sometimes be easier if I could do "bzr add --ignore-nothing"
<kirkland> slangasek: I did end up testing amd64 server + LVM/encryption, and it works fine ;-)
<kirkland> Keybuk: there's some errors about not being able to find /sbin/udevsettle, FWIW
<kirkland> Keybuk: but the boot happens okay
<lifeless> liw: cat << EOF >> ~/.bazaar/ignore
<lifeless> liw: or python
<lifeless> liw: and then you could make it into a plugin
<cjwatson> lifeless: ('>~/.bazaar/ignore')
<liw> lifeless, that's more than one line of code, and less suitable for a temporary operation
<lifeless> cjwatson: ECAFFEINE
<kirkland> Keybuk: looks to me like there's a call to /sbin/udevsettle BEFORE the encrypted-lvm-mount has succeeded
<lifeless> kirkland: we do need to bring up enough devices to find the luks partition :O
<liw> cvs has -I options to allow ignores to happen for one invocation only, which is sort of what I want, I guess
<liw> lifeless, however, since my most common need for that option is for my unpack-debian-sources script, and I've already written that, I don't think I'll bother even filing a wishlist bug
<beDrung> hi
<lifeless> liw: fair enough
<beDrung> hi bryce
<beDrung> calc: how far are you with the oo.org patch?
<kirkland> lifeless: hmm, should i open a bug on that one?
<lifeless> kirkland: uhm, only file bugs you see/create :)
<lifeless> kirkland: luks stuf works fine for me modulo not-using-uuids and having to unlock it twice
<bryce> beDrung: heya
<beDrung> bryce: irc is faster than mail
<bryce> beDrung: indeed :-)
<beDrung> bryce: is there a patch i can test?
<bryce> beDrung: calc got the patch and is building deb's - it'll take hiim a few more hours
<bryce> I've not seen the patch myself, but if calc is abouts maybe he can give a pointer to it
<bryce> here's the bug report https://bugzilla.novell.com/show_bug.cgi?id=398244
<ubottu> bryce: Error: Could not parse XML returned by bugzilla.novell.com: not well-formed (invalid token): line 54, column 0 (https://bugzilla.novell.com/xml.cgi?id=398244)
<bryce> ubottu: shush
<ubottu> Factoid shush not found
<calc> beDrung: priming ccache right now
<calc> beDrung: then will build it with the new patches
<calc> beDrung: depending on how fast a machine you have it can take upwards of 16hr for a single build
<calc> i'm just going to be pulling ooo-build-2-4-1 to do the build
<beDrung> calc: my desktop pc ( http://www.sysprofile.de/id33138 ) is fast (Core2Duo E6750).
<liw> slangasek, oops, coreutils fails to build :(
<beDrung> calc: here in germany it's 23:39. so time is running.
<calc> beDrung: sounds slightly slower than what i build on, you could build it, but make sure you use DEB_BUILD_OPTIONS=nogsi or it will take you at least 6hr or more (i would imagine)
<slangasek> liw: aw man, we have to make it *build*, too?
<calc> beDrung: you just need to get current ooo-build-2-4-1 from svn.gnome.org and replace the version in ooo source with it then run the autotools stuff on it and then build
<calc> beDrung: it definitely will take longer than you are awake tonight to finish though
<liw> slangasek, hm, I tested it before asking for the upload, but it turns out that I did that in a hardy pbuilder, not an intrepid one (and my hardy debootstrap doesn't know about intrepid, so I can't even create an intrepid pbuilder tgz)
<slangasek> liw: you can create an intrepid chroot by telling debootstrap to use the hardy script
<calc> even a ccache primed build on my machine takes over 100m to build
<cjwatson> liw: there's also a version of debootstrap that knows about intrepid in hardy-backports
<slangasek> liw: i.e., debootstrap intrepid /chroots/intrepid http://mylocalmirror/ubuntu hardy
<liw> cjwatson, I'll get that one
<beDrung> calc: does the build use more than one core?
<calc> beDrung: yes
<liw> slangasek, yeah, I'd have to get pbuilder do that for me, but there's an option for it
 * calc wishes intel would release a 8core desktop chip
<liw> oops, my mirror doesn't do hardy-backports
<calc> beDrung: some of the more time intensive stuff can't be easily parallelized like the dh_shlibdeps stuff
<calc> that part alone takes over 20m iirc
 * beDrung wishes intel or amd would release a 16core desktop chip with a maximum tdp of 65W for my passic cooled tower.
<calc> heh
<liw> 65W is about 64 too many :)
<calc> even poor little atom uses more than 1w
<beDrung> 1w would be cool. but 140W maximum for my whole pc is ok and my tower ( http://www.zalman.co.kr/ENG/product/Product_Read.asp?idx=186 ) has no problem to cool this.
<calc> my system under load is ~ 150W at the wall
<calc> under load
<calc> er i already said that, doh
<beDrung> what graphic card do you use?
<liw> slangasek, ok, I reproduce this under an intrepid pbuilder, I'll see if I can fix it
<calc> beDrung: nvidia 7600GT
<slangasek> liw: cheers
<calc> got it before amd bought out ati
<calc> doesn't have a fan :)
<liw> slangasek, even if it uses an unspeakable build system
<beDrung> 30 - 40 W
<calc> my next system will probably just have a intel igp
<calc> that will save a lot of power
<calc> also if my cpu wasn't o/c it wouldn't use nearly as much power
<beDrung> i have upgraded to a radeon hd3650, but i think it is too early. ati and radeonhd driver currently do not support xv and fglrx has some problems.
<calc> oh
<calc> well its probably better than using nvidia (gag)
<ion_> âsomeâ :-D
<calc> i can't even resume from suspend
 * calc will eat a hat when nvidia finally writes an open source driver and releases full docs for all their hardware like AMD/ATI
<calc> i only got the nvidia card because it was the better of the two crappy non-oss friendly brands at the time :-\
<alex-weej> nvidia is still way better than ati
<alex-weej> my nvidia in my macbook pro is a treat
<bryce> calc, during these builds have you checked that your CPU's are all averaging at 100%?
<alex-weej> i get redirected 3D acceleration
<beDrung> while watching movies some stripes run through the picture (may be a sync problem) and compiz + video in window is flickering, so i deactivated compiz.
<calc> bryce: yea, i think it is running 4 threads
<beDrung> but: suspend with fglrx works.
<calc> bryce: its 100% most of the time anyway, until it gets into debian stuff that isn't parallelized (i am assuming)
 * bryce nods
<slangasek> liw: that seems like a rather strange build failure
<bryce> calc: have you tried seeing if ccache helps?
<calc> bryce: afaict things like dpkg-shlibdeps are REALLY resource intensive and don't work parallelized
<calc> bryce: already do that to get it down to only ~ 2h build
<slangasek> liw: strange in that it didn't also fail in Debian, I mean
<bryce> calc: *nod*
<calc> bryce: eg ia64 buildd takes > 16h to build
<calc> also turn off all the language export stuff as well
<liw> slangasek, interestingly, if I run the build on hardy from an unpacked source tree, it succeeds
<beDrung> calc: on which platform do you compile it?
<slangasek> liw: getopt changes?
<calc> beDrung: amd64
<liw> slangasek, I don't know, the build just finished
<calc> beDrung: takes about the same amount of time on i386 as well
<calc> beDrung: at least on the same system
<beDrung> yes, but i only need amd64 to test it. ;)
<slangasek> liw: I'm guessing it's a change in the glibc getopt behavior
<bryce> calc, I'd experimented with optimizing xorg builds via ccache and putting everything on a ramdisk, using a local cache for pulling deps, etc.  ccache made the biggest difference, the rest was just nickels and dimes
<slangasek> and therefore fixing it is a one-way trap, @yay
 * liw sees this in coreutils code: /* FIXME: comment */
 * liw wonders why factor is in coreutils in the first place
<bryce> calc: I found that the way xserver is packaged, it wasn't using all the cpu's (-j flag couldn't be set).  So the next step was to look at fixing the packaging, but I don't build xserver all that frequently, and with it down to below 15 min that's not too bad
<beDrung> calc: what is the checkout http address?
<calc> http://svn.gnome.org/svn/ooo-build/branches/ooo-build-2-4-1
<calc> i think that will work
<calc> i use it with svn+ssh://
<beDrung> why is oo.org on gnome.org?
<beDrung> calc: checkout works
<sbeattie> asac: ping
<calc> beDrung: because someone put it there :)
<calc> beDrung: its go-oo not openoffice.org
<calc> beDrung: novell (go-oo) and sun (openoffice.org) don't get along especially well
<calc> so that is why it isn't hosted somewhere on openoffice.org
<beDrung> where is the difference between those two?
<calc> go-oo is a large set of patches on top of openoffice.org
<slangasek> is the maintenance team for go-oo called the "go-oo power rangers"?
<liw> slangasek, yeah, indeed: it's a difference in the output of getopt(3), the hardy version of libc6 uses %c and the intrepid version uses '%c'
<slangasek> liw: right; so we can patch the testsuite, or complain to doko about the behavior change in libc6?
<liw> slangasek, I'd say the behavior change is for the better, so I'd rather patch the test suite
<liw> there's a bunch of other such changes in getopt... `%s' changed to '%s' for example
 * slangasek stares at top.  No, I don't think that process was actually using 935% of my processor...
<liw> slangasek, what's the correct procedure for fixing this? should we revert the sync request and do a merge instead or what?
<mathiaz> slangasek: what's the point of supporting hdb and bdb in the slapd package ?
<slangasek> liw: the sync is already done; the next stage is to file a bug in LP about the build problem, provide a patch (debdiff), and subscribe ubuntu-main-sponsors
<mathiaz> slangasek: why not just setup hdb ?
<slangasek> mathiaz: "both are good", vaguely
<liw> slangasek, I'll do that then
<slangasek> mathiaz: bearing in mind that the package has had somewhat irregular maintenance, and hdb has only become a preferred backend relatively recently
<mathiaz> slangasek: right - but that was preferred over ldbm
<slangasek> liw: also, subscribing me directly in this case since I'm well-poised under the circumstances to sponsor with a minimum of extra hassle
<mathiaz> slangasek: or bdb was the default before hdb ?
<slangasek> mathiaz: bdb was the default before hdb, I believe
<slangasek> hdb was considered "new and untested" at the time we made bdb the default
<LaserJock> bryce: around?
<bryce> LaserJock: heya
<mathiaz> slangasek: ok.
<slangasek> mathiaz: how important is it to change the default for this cycle?
<LaserJock> bryce: got a question on the xcb/x11 issue
<slangasek> I think we would have some migration code for the ldbm->bdb switch that we should resurrect, if we're going to change
<bryce> LaserJock: shoot
<slangasek> and we should definitely discuss whether bdb should be considered obsolete wrt the packaging, or if there are still cases where it should be preferred
<LaserJock> bryce: I've got a guy who's trying to install a Java app on hardy, but it crashes with something about locking and spits out a backtrace with libxcb and libx11
<bryce> LaserJock: *nod*
<LaserJock> bryce: I'm wondering if you have any pointers on how to debug it
<mathiaz> slangasek: I've started to look into cn=config migration
<slangasek> mathiaz: does that rely on hdb as the backend?
<bryce> LaserJock: sure
<LaserJock> I have another colleague who's also running hardy and he doesn't seem to have the issue. I'm having them compare notes on installed updates (I didn't know if you'd done anything yet)
<mathiaz> slangasek: and when creating a database configuration from an ldiff file, you need to set an objectclass to olcBdbConfig or olcHdbConfig depending on the backend you want to use
<bryce> LaserJock: java and xcb haven't had a history of getting along, although afaik the issues had been worked out
<mathiaz> slangasek: currently this is done by substitution of @BACKEND@, which is either bdb or hdb
<bryce> LaserJock: no we haven't made any changes which would affect java one way or the other
<LaserJock> bryce: well, I'm not sure if we're using Ubuntu's Java
<LaserJock> would that make a difference?
<mathiaz> slangasek: properly generating the ldif entry for the db config means more logic to set the olc{BH}dbConfig
<mathiaz> slangasek: the config backend doesn't rely on bdb
<mathiaz> slangasek: it's stored as a bunch of ldif files in /etc/ldap/slapd.d/
<bryce> LaserJock: however in the cases we've troubleshot so far, the issue is very, very irregular - often dependent on timing issues and such.  So reproducing the issues can be quite tricky, even if you have roughly similar systems
<mathiaz> slangasek: my question has more to do with simplifying the code to get read of the backend support - and just provide hdb by default in the debian scripts.
<bryce> LaserJock: 86103 may be of interest
<slangasek> mathiaz: ok.  I would suggest checking with Howard about whether there are any cases where we *need* to continue supporting bdb, or if we should go ahead and migrate everything over at the same time; though, I'm not entirely certain that the migration code is going to be simpler in the short term than supporting both backends
<bryce> LaserJock: esp. if you're using a non-Ubuntu java
<LaserJock> ok
<slangasek> mathiaz: also, even if the package only supported automatically setting up one of hdb or bdb, does not mean that users wouldn't set up additional databases on their own using backends of their choice
<bryce> LaserJock: for troubleshooting, getting backtraces are useful to identify what code paths are involved.  And then look for irregularities
<bryce> in both the two cases we have so far, the issue was double-running code that should only be run once
<slangasek> mathiaz: i.e., consider that there are things like the sql backend, which while never configured for the user in the package, are certainly expected to work if set up manually...
<mathiaz> slangasek: sure - I don't think wich drop bdb as backend - I'm just asking if we should drop bdb support for the maintainer scripts
<bryce> so I would keep an eye out for that pattern, particularly with code that makes X calls
<slangasek> mathiaz: right, I don't know the answer to that, we should get upstream's opinion :)
<mathiaz> slangasek: ok - I'll ask upstream then.
<bryce> LaserJock: also, I posted a noxcb version of libx11 to people.ubuntu.com/~bryceharrington/Testing/libx11 that you're welcome to grab for testing
<bryce> LaserJock: like I mentioned, it's too risky to consider putting into hardy, but it oculd be handy for isolating if it is indeed an xcb-related issue
<calc> grr i can't remember the word i am looking for
<calc> what is the name for code that has no license
<calc> ah i am thinking of public domain
<beDrung> in germany it is not possible to declare code as public domain
<LaserJock> bryce: ah cool, thanks. I'd be happy if I can just isolate it. The install is pretty single-use so if we get the app working we'd be happy
<calc> beDrung: yea i thought so
#ubuntu-devel 2008-06-27
<asac_> sbeattie: ?
<sbeattie> asac_: sorry, was just wondering about the nss and nspr tasks of the firefox3 tracking bug 237690
<ubottu> Launchpad bug 237690 in xulrunner-1.9 "[New Upstream] Firefox 3 RC2 is available" [Undecided,Fix released] https://launchpad.net/bugs/237690
<sbeattie> was wondering if they should be marked invalid or fixed-released since they've gone out the door, I think.
<sbeattie> (at least for hardy)
 * calc is going to get dinner
 * beDrung is going to bed
<beDrung> calc: i am back in 9 hours for testing
<calc> beDrung: ok
<liw> slangasek, https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/243375
<ubottu> Launchpad bug 243375 in coreutils "coreutils 6.10-6 fails to build from source" [Undecided,New]
<slangasek> liw: <yoink>
<slangasek> liw: I don't suppose there are any bugs on https://bugs.launchpad.net/ubuntu/+source/coreutils we could triage out while we're at it? :)
<slangasek> liw: the patch needs to change the maintainer field of the package, in line with https://wiki.ubuntu.com/DebianMaintainerField; care to spin me an updated patch quickly, with this change and also adding the bug number to the changelog?
<liw> slangasek, sloppy of me, just a minute
<liw> slangasek, updated debdiff in LP
<liw> slangasek, wrt triaging: do you mean also fixing them, or just juggling bug states in LP?
<slangasek> does someone want to flick the ears of the mysql maintainers for creating metapackages that depend on packages with versioned names which contain executables without versions in their names, that then fail to conflict/replace one another?
<slangasek> liw: thanks, grabbing.  As far as triaging, I just meant juggling bug states - it's clear to me by looking at the bug list that no one has been over this page in some time, I already found one invalid bug about a user who wanted ls to not honor LC_COLLATE
<slangasek> (bug #201302, that)
<ubottu> Launchpad bug 201302 in coreutils "/bin/ls in es_ES.UTF-8 don't show ordered files correctly" [Undecided,Invalid] https://launchpad.net/bugs/201302
<slangasek> liw: I understand if you have more high-priority things to do, anyway; I'm just mentioning it in passing because there are always more high-priority things to do, which is how the bug lists get long in the first place :)
<liw> slangasek, indeed
<liw> I'll stick to doing other things for now, though
<liw> slangasek, my two install tests under qemu are still running, by the way
<slangasek> pff, slow
<liw> (boy qemu is slower than kvm)
<liw> actually, I'm going to have dinner before I fall asleep... let's hope the tests finish in the mean time
<zul> slangasek: whats wrong with mysql?
<slangasek> zul: well, bug #208695
<ubottu> Launchpad bug 208695 in mysql-dfsg-5.0 "Cannot upgrade to mysql-server-5.0" [Undecided,In progress] https://launchpad.net/bugs/208695
<slangasek> zul: which is, basically, a design failure of the packages
<slangasek> "yes, we'll have mysql-client-4.1 and mysql-server-4.1 in the archive at the same time, so you can pick between them, and we'll have mysql-client as a metapackage to depend on the default version for you, and then we'll cause upgrade failures when you try to switch mmmkay"
<slangasek> heh, s/mysql-server-4.1/mysql-client-5.0/
<slangasek> ok, the build-deps for coreutils are disturbing
<zul> slangasek: ah yes I remember that one
<zul> slangasek: they should kicked in the shins
<slangasek> I was opting for something a little less violent, because I never know when he'll decide to get me back at a conference :)
<zul> slangasek: heh :)
<liw> slangasek, coreutils' build-deps? how are they disturbing?
<slangasek> liw: lots of X libs
<slangasek> (pulled in indirectly)
<liw> oh, indirectly
<mitsarionas> hi... could i ask something about autoconf/automake here?
 * slangasek eews at 202642
<bryce> mitsarionas: this channel isn't the right place for that, unless it's specifically related to ubuntu packaging issues
<mitsarionas> bryce: where could i get such an answer?
<bryce> mitsarionas: depends on the aspect of your question, but look for a channel/forum devoted to providing software development assistance
<mitsarionas> ok, thanx :)
<emgent> night
<bryce> slangasek: ok I think I'm done looking at -geode for today.  I still can't fathom why the symlink would break LTSP.  I've proposed dropping that change and deploying the remainder, and require the LTSP folks to file a bug explaining what the problem is.
<slangasek> bryce: ack, g'night then :)
<bryce> slangasek: the "ltsp needs the symlink dropped" is at the level of a rumor as far as I'm concerned
 * slangasek nods
<bryce> slangasek: anyway I just put a new -geode without that into hardy-proposed which I think you can deploy for 8.04.1
<bryce> er, s/I think/I recommend/
<slangasek> ok
<bryce> trading off "possibly maybe leaving ltsp still broken" against "definitely break people currently configured to use 'amd' and make them rightfully angry" doesn't seem like a good enough trade.
<slangasek> yes, the way in which it was presented to me suggested that the presence of the symlink itself might break things because of X trying to grab the driver twice or something; but in that case, we should still be able to stow the symlink in the transitional package for the benefit of those users with static xorg.conf, maybe?
<bryce> even there, I don't quite understand how that could happen
<bryce> maybe I'm dumb, but I'd really like to see the actual issue documented in a bug report before we put an sru'd change out for it
<slangasek> I agree, especially in light of the reservations you've expressed as someone who knows X far better than I
<bryce> who knows, maybe there's some other way whatever the issue is can be worked around
<slangasek> oh, that reminds me, I owe you a pipe-a quirks bug report :)
<bryce> ah yes
<bryce> hey I've got two others pending, if you send yours, I can do all three together
<slangasek> woohoo
<RAOF> cjwatson: You're right about the gnome-do-plugins needing to Replaces gnome-do-plugin-{amarok,rhythmbox}.  I haven't done it yet, in part because there'll be a new gnome-do 0.5 package in Debian soon, and the plugins package will need to change.
<slangasek> filed as bug #243405
<ubottu> Launchpad bug 243405 in xserver-xorg-video-intel "Need a Pipe-A quirk for 8086:27a2" [Undecided,New] https://launchpad.net/bugs/243405
<slangasek> bryce: ^^
<bryce> excellent
<asobi> question
<asobi> is there any plans to have second life in the repo?
<Hobbsee> not unless someoen packages ti?
<RAOF> Is it actually redistributable?
<StevenK> I didn't think it was.
<persia> Last I heard there were still remaining issues.
<asobi> does anyone like to see it or should i not hope
<persia> asobi: It's been discussed several times before.  If you are willing to investigate the licensing, and open a bug reporting that it ought be packaged if the license is indeed free, that would be the best way to proceed.  Note that the existence of this bug will not automatically lead to it being packaged, but it will be the first step in the process.
<asobi> oh. i was not aware it had been brought up previously
<persia> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages may be helpful if you pursue that route.
<bliZZardz> persia : what is the general method to be followed to package a new lib/tool...?
<bliZZardz> persia : wow..you answered it :)
 * persia tries to anticipate
 * bliZZardz bows :)
<asobi> i guess there's not enough demand for it
<asobi> besides licensing issues
<asobi> thanks^^
<TheMuso> yay for lost changelog entries. :S
<pitti> ScottK: I'm on vac today and off in 10 minutes, so I'm afraid I don't today; doko might
<pitti> slangasek: debhelper> of course I don't mind, please go ahead
 * Hobbsee throws pitti a gummybear
<pitti> slangasek: ugh, backwards C:/R:? might have slipped my attention, but I thought the original patch was correct
<pitti> Hobbsee: yay, thanks
<calc> gah ppa's only allow release pocket uploads
 * calc wishes it would work for any standard pocket name
<calc> eg hardy-proposed should work along with hardy
<calc> http://www.engadget.com/2008/06/27/celebrate-bill-gates-day-with-us/ <- :-)
<slangasek> pitti: yeah, I think we both missed the backwards C:/R:, I looked at the earlier upload and it was there :)
<calc> btw the video is very funny if you haven't seen it yet ;-)
 * calc wonders how long before /. picks it up
<bryce> calc, :-)
<calc> bryce: uploading to my ppa now, i had uploaded earlier but it rejected it
<calc> bryce: my first upload to a ppa actually, i found out it only accepts release pockets
<bryce> yeah ppa's are surprisingly limited
<calc> i thought it would be better to upload it there than to a p.d.o directory
<calc> er p.u.c
<calc> much better than uploading it to p.d.o obviously ;-)
<bryce> heh
<bryce> yeah I set up some ppa's for xorg stuff, but really I find it a lot easier to use people.u.c
<slangasek> liw: did you ever get any results back from those qemu installs?
<dholbach> good morning
<bryce> heya dholbach
<dholbach> hi bryce
<bryce> slangasek: btw your quirk is in intrepid, sent upstream, and just now in hardy-proposed.
 * calc headed to bed
<dholbach> hi seb128
<seb128> hey dholbach
<slangasek> bryce: thanks :)
<slangasek> bryce: hmm, I don't actually see it in the hardy-proposed queue
<slangasek> (not that it would go anywhere until after .1, but)
<bryce> oops, build system rejected it
<bryce> hrmm
<slangasek> ... build system?
<bryce> well, whatever it's called
<bryce> Rejected:
<bryce> MD5 sum of uploaded file does not match existing file in archive
<bryce> Files specified in DSC are broken or missing, skipping package unpack verification.
<slangasek> ah
<dholbach> hi mvo
<mvo> hey dholbach
 * bryce tries again
<ion_> Oh noes, a painful new Gtk theme. :-(
<ogra> ion_, ?
<ion_> ogra: White text on a grey background.
<ogra> ah, cool !
<ogra> in intrepid ?
 * ogra still has to run hardy
<ion_> Yes
<ogra> nice
<ion_> Not that nice. :-)
<ogra> i saw a pre-version in prague
<bryce> ion_: primer gray?
<gnomefreak> yeah i got that as well
<gnomefreak> also gajim dont work since the update ;)
<gnomefreak> :(
<Nafallo> gnomefreak: what update?
<gnomefreak> for some reason appearance got changed to custom thats why its like that
<gnomefreak> Nafallo: the merge yesterday
<gnomefreak> Nafallo: you were in #-mozillateam during this topic
<Nafallo> gnomefreak: someone merged it? :-(
<Nafallo> gnomefreak: just because I am on a channel doesn't mean I'm actively reading it.
<gnomefreak> Nafallo: fta said see doko it seems he dropped patches
<gnomefreak> one of them fits the error im getting
 * Nafallo headdesks
<Nafallo> gnomefreak: ehrm. launchpad know nothing of such a merge...
<gnomefreak> Nafallo: fontconfig was merged yesterday
<ion_> http://heh.fi/tmp/theme
<Nafallo> aha. context helps :-)
<gnomefreak> Nafallo: https://edge.launchpad.net/ubuntu/intrepid/+source/fontconfig/2.6.0-1ubuntu1
<Nafallo> gnomefreak: oki. I'll look in to it later. thanks for telling me.
<seb128> bug #243130
<ubottu> Launchpad bug 243130 in fontconfig ""/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdfilterlegacy" [Undecided,Confirmed] https://launchpad.net/bugs/243130
<gnomefreak> Nafallo: np i think we found issue in it
<gnomefreak> seb128: thanks
<seb128> there is a patch waiting for sponsoring
<Nafallo> thought it would not be gajim's fault :-)
<gnomefreak> Nafallo: well so far its the only app that is affected from what i can see
<gnomefreak> im sure there is more but i havent found them yet
<cjwatson> RAOF: so should I sync gnome-do-plugins or not? if I do, somebody needs to make sure the Replaces is added in intrepid fairly soon; alternatively, feel free to just upload 0.4.0-1ubuntu1 to intrepid with that directly, or we could leave the whole thing until intrepid+1
<RAOF> Is there any reason we can't wait for gnome-do-plugins 0.5 to be sorted out in Debian and then sync that?
<RAOF> A: Yes.  Because we'll still need to do the Replaces: dance.  I'll upload a 0.4.0-1ubuntu1.
<liw> slangasek, the amd64 qemu install is _still_ running, the i386 just finished (was waiting for me to press a key while I slept)
<gnomefreak> Seeker`: i was just informed that patch on the fontconfig bug but i didnt personally look at it
<MacSlow> If I have make-targets named like "confflags-gnome" in a debian/rules file... does this imply I need to have additional maintainer-scripts for these to properly work?
<dholbach> soren: what do I do if I see only "parallel0 console" in KVM?
<dholbach> did I press some funky button somewhere?
<liw> I have "ATQ0 V1 E1" on qemu's serial0 console
<dholbach> I had a desktop some seconds before, now a black screen that just says "parallel0 console"
<dholbach> "Send 'ctrl-alt-f<n>'" seems to do nothing
<liw> dholbach, ctrl-alt-3 (not f3) takems me to that console in qemu, try ctrl-alt-1
<dholbach> ahhhhh!
<dholbach> liw: thanks!
<liw> these are qemu/kvm consoles, not linux virtual consoles, thus 123 not f1f2f3
<liw> dholbach, you're welcome, I was majorly confused by them myself :)
<dholbach> yeah
<liw> cjwatson, my alpha1 amd64 installation has "You shouldn't call /sbin/grub-install. Please call /usr/sbin/grub-install instead!" on tty4
<liw> cjwatson, it's also probing devices and searching for the GRUB installation directory (find /boot/grub), so I guess that was just a warning... but it hasn't finished the grub installation in 12 hours since
<cjwatson> RAOF: because we're past the normal merge deadline
<cjwatson> RAOF: there's no reason why the Replaces couldn't be added in Debian, FWIW
<cjwatson> liw: that warning in itself is definitely a no-op, because it then execs /usr/sbin/grub-install
<liw> cjwatson, yeah, I see that from ps output; strace to /usr/sbin/grub isn't showing any output
<cjwatson> liw: did i386 work?
<liw> cjwatson, I did an encrypted install with i386, and it worked, but I don't know if it uses grub
<liw> yes it does
<liw> syslog does not indicate that anything interesting has happened since grub found its installation directory... dhclient did a DHCPREQUEST and got an ack
<cjwatson> not sure I know what to do, I'm not in a position to do an amd64 test myself I don't think
<liw> anything I can do extract more data?
<liw> I'll start another test on amd64 in the mean time
<cjwatson> an strace -f -s 1024 of the whole of grub-installer wouldn't hurt
<cjwatson> easiest way to do that is to go back at the user/password prompt, set the debconf priority to low, and then go on from there, which will let you work through step by step; when you get to just before grub-installer, attach strace to the main-menu process
<cjwatson> I'm groping in the dark though, it could be that grub is just busted on amd64 right now ...
<liw> no output from that strace either
<liw> ah, going back, just a moment
<liw> hm, I killed the grub-install process and the installer is now happily finishing the installation
<cjwatson> it may well fail to boot
<liw> since the process died, shouldn't it have noticed that and treated it as an error?
<liw> indeed, boot seems to fail, does not seem to load grub from bios
<cjwatson> I'm rather surprised it didn't
<cjwatson> I don't see anything obviously wrong in main-menu or di_exec_mangle_status
<cjwatson> oh, I suppose it goes through udpkg
<liw> it was running from a postinst script, yes
<cjwatson> even so, ought to work
<cjwatson> unless busybox sh eats the exit status or something
<liw> that would be weird of it, but it wouldn't the first time busybox was weird
<liw> (I had to create a tail-recursive shell script once, on a box where busybox's while was broken)
<cjwatson> anyway, main-menu bug if you like, I'm not going to investigate right now :)
<liw> hm, my second attempt at amd64 resulted in an error at the partitioning stage
<liw> "EXT3-fs: group descriptors corrupted"
<liw> I'm beginning to suspect qemu
<liw> and I get that again on another qemu instance, so it's repeatable
<davidedmundson> hey, I have a launchpad question, do I ask here or is there a specific launchpad channel?
<sistpoty|work> davidedmundson: #launchpad ;)
<jpds> davidedmundson: maybe: #launchpad
<davidedmundson> probably should have guessed that..
<davidedmundson> ta
<liw> slangasek, I had to mark the amd64 qemu test install as a failure :(
<james_w> is "sambashare" a group that only Ubuntu would care about?
<james_w> (i.e. not Debian?)
<james_w> also "lpadmin"
<liw> debian has lpadmin
<liw> probably created by cups
<\sh> bryce: do you happen to know if this gnome screen resolution tool also works with an ATI Fire GL graphics adapator? It has only one dvi output but a bridge to attach two screens
<\sh> bryce: it detects both screens but doesn't switch to dual screen mode
<wgrant> \sh: Sounds like a bug in fglrx...
<\sh> wgrant: I just installed fglrx-envy...
<\sh> wgrant: failsafe session works...I think it's more compiz
<\sh> wgrant: well, not with dual screen
<wgrant> \sh: I don't think Compiz interacts at such a low level. It may be that it won't support DRI over such a large area.
<\sh> wgrant: ubuntu fglrx driver doesn't support the firegl...
<\sh> let's see for envy
<ogra> Keybuk, ping
<tseliot> ï»¿\sh: ï»¿the gnome screen resolution tool won't work with the fglrx driver if you're trying to set up multiple screens. The fglrx driver doesn't support RandR 1.2 yet.
<\sh> tseliot: I managed to get it with envy drivers...and the amdcccle
<tseliot> ï»¿\sh: yes, that's the only tool which should work with the fglrx driver.
<\sh> well...it worked..after a reboot it doesn't come up anymore :(
<emgent> heya tseliot
<tseliot> ï»¿emgent: hi
<tseliot> ï»¿\sh: sorry but I'm not an expert with the fglrx driver and multiple screens.
<emgent> "pizza? nah.. this is an italian resturant"
<tseliot> ï»¿emgent: hehe
<\sh> tseliot: well, xorg.conf was zero byte ;) because of a crash...praise beta software ;)
<tseliot> ï»¿\sh: maybe amdcccle should be launched as root (with sudo) in order to write to your xorg.conf
<\sh> tseliot: well, yes..but it's crashing when you are in 3d mode on kde4.1beta2 ;)
<tseliot> ï»¿\sh: heh
<ogra> hmm, since scott doesnt seem to be around, and pitti being on vacation today, does anyone know if with dropping the multiuser argument from update-rc.d the versioned dependency on sysv-rc is still needed ?
<penfold_99>  is anyone here working on kvm?
<dholbach> penfold_99: try #ubuntu-virt
<penfold_99> dholbach: -virt look like a ghost town at the mo so i though i would try here
<persia> penfold_99: You may find that even the quietest of Ubuntu channels may spark to life with the posting of an interesting question.
<Hobbsee> persia: an interesting, *on topic* question
<jdstrand> seb128: hi! is there a way to tell gvfs to rescan the network for samba servers? maybe a HUP or something?
<seb128> jdstrand: hey, I don't think so, stop gvfs-smb-browse and it'll respawn automatically?
<jdstrand> seb128: ok. I'm new to gvfs, and did just discover gvfs-ls too. I'll play around. thanks!
<seb128> jdstrand: is that still about this "playing video on smb shares doesn't work correctly"?
<jdstrand> seb128: yes
<jdstrand> seb128: so far, I can't reproduce it
<seb128> jdstrand: hey me neither, I've a NAS and playing videos on it over smb stills work correctly
<jdstrand> seb128: does that NAS use vfat?
<seb128> jdstrand: I guess so, not sure how to verify though
<jdstrand> seb128: it is something off-the-shelf?
<jdstrand> seb128: zul tried a bunch of combinations too, and couldn't reproduce it
<beDrung> calc & bryce: wohoo! first test show: ooo 1:2.4.1-1ubuntu2~ppa1 works. I will do more testing and report if there are any regressions.
<jdstrand> seb128: I did see, tucked away in one of the attached smb.conf files, that a share had a comment of 'vfat hd'
<seb128> jdstrand: yes, that's a landrive network disk doing smb and ftp which we have for some years
<jdstrand> seb128: so I'm am going to try that too in the off chance it's a filesystem thing
<cjwatson> jcastro: would it be possible to get some packages that are really Ubuntu-specific excluded from the upstream report?
<cjwatson> jcastro: for example, for ubiquity and ubuntu-meta it usually doesn't make sense to forward bugs upstream because we *are* upstream
<jdstrand> seb128: hey sweet, killing gvfsd-smb-browse worked
<jcastro> cjwatson: yes that's on the todo
<jcastro> cjwatson: same thing with removing all the redundant kernel ones
<cjwatson> jcastro: ok, cool - is it just a hardcoded list right now?
<jcastro> yeah it's just autogenerated from launchpad and sorted by open bugs
<cjwatson> I mean the list of packages that are checked there
<cjwatson> oh, right, you mean you just pick the top n packages?
<jcastro> right
<cjwatson> gotcha
 * ogra restates his quesion since there are now more people in the channel ...
<cjwatson> jcastro: I would have looked at the Help tab to answer these questions as the page indicates, but there isn't one ;-)
<ogra> does anyone know if with dropping the multiuser argument from update-rc.d the versioned dependency on sysv-rc is still needed ?
<jcastro> cjwatson: I am in the middle of putting together a list of improvements for improving the report to send to kiko as we speak actually.
<jcastro> cjwatson: yeah that's weird, because it used to be there
<cjwatson> ogra: I don't believe so, not if the corresponding Debian version doesn't have it
<ogra> cjwatson, thanks then i think i'm through with hotkey-setup and we can just sync ...
<ogra> (that was a pita ... not synced since ages and tons of changes)
<jcastro> cjwatson: feel free to send any more feedback on the report, I've already gotten ideas from asac/seb128 that will make it more useful
<seb128> jdstrand: I get the issue now here playing a video on my etch debian gateway over samba
<seb128> jdstrand: downgrading libsmbclient 3.0.28a-1ubuntu4.3 to  3.0.28a-1ubuntu4 make it work correclty
<calc> beDrung: great :)
<seb128> jdstrand: I can get you details if you need some, the server is a running etch and the disk is an ext3
<seb128> jdstrand: hum, it still plays fine after upgrading again, weird
<seb128> jdstrand: seems to be an authentification issue
<jdstrand> seb128: on phone...
<seb128> it was still playing correctly after upgrading because it has the authentification still active
<seb128> but login doesn't work using the new libsmbclient
<seb128> jdstrand: alright, I'm around if you need informations after your call
<MacSlow> Keybuk, I just looked at gimp and GTK+... there seems to be no need to merge anything... already done
<seb128> MacSlow: I just updated GTK to 2.13 and we are mostly in sync on debian usually, what did you want to change?
<MacSlow> seb128, nothing... I just remember Keybuk's comment from yesterdays meeting where he stated that I should also work on merging gimp and gtk... which has obviously happened already before yesterday
<seb128> hum, I didn't read a such comment during the meeting
<MacSlow> seb128, like you said... you worked on GTK yourself
<seb128> right
<MacSlow> seb128, ah... found it... it was from the meeting last week... -> https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-06-19
<MacSlow> seb128, the exact list of apps I should merge wasn't stated... for some reason I still had that in the back of my head.
<superm1> lamont, elmo , infinity : I have a package that needs to be overridden in p-a-s.  I was referred to one of you to handle it when you get a moment.  The package is coreavc, and it should only build on i386, lpia, and amd64.
<lamont> superm1: email is the right way to request that
<superm1> lamont, okay.  sorry, wasn't aware of proper procedure
<lamont> no worries - finding the file is generally the challenge people have :-)
<ion_> Wow. system-config-printer in Intrepid is neat.
<geser> mvo: I'm looking why my pbuilder with gdebi tries to install recommends, have you an idea how to get gdebi --apt-line --root ... not list the recommends?
<zul> jcastro: ping can you add openldap's its (http://www.openldap.org/its) to your upstream bug list for launchpad. It uses a hacked version of jitterbug
<mvo> geser: there is currently no direct support for this, easiest is problably to add "APT::Install-Recommends "false"; to /etc/apt/apt.conf in the pbuilder chroot
 * mvo needs to fix that
<geser> mvo: I've already tried that
<geser> mvo: have you an idea why I get different output depending if I call gdebi from outside the pbuilder (with --root) and from inside? see http://paste.ubuntu.com/23318/
<geser> hmm, looks like gdebi takes the apt config from the "host" if called with --root and not the one from the chroot
<jdstrand> seb128: hey (long call)-- how is the etch share setup in smb.conf? is there a way to get gvfs to forget it authentication (like the gvfs-samba-browse thing you told me about before)?
<mvo> geser: yeah, that sounds like it - that is a bug, could you please file it?
<jdstrand> mvo: hi! so I see that apt.conf has the ability to do https, can it also do http basic auth?
<seb128> jdstrand: totem is not using gvfs
<seb128> jdstrand: not sure, maybe restart gnome-keyring, though if you don't select the option to use this one it should not do it
<seb128> jdstrand: the samba server is using security = user and a classic share
<seb128> [share]
<seb128> comment =
<seb128> path = somedir
<seb128> guest ok = no
<seb128> and I'm using my user login and password to connect
<jdstrand> seb128: cool, I check it at and let you know
<jdstrand> s/I/I'll/
<geser> mvo: filed as bug #243550
<ubottu> Launchpad bug 243550 in gdebi "gdebi --root doesn't use the apt config from the chroot but the one from the "host"" [Undecided,New] https://launchpad.net/bugs/243550
<mvo> geser: thanks!
<jcastro> zul: I don't think lp supports that bug tracker.
<zul> jcastro: is there a way to get support added?
<jcastro> yeah, I'll need to file a bug with the lp team
<jcastro> zul: there's a few projects where we don't have bugtracker support, like CUPS(!) and some other not-so-pupular bug trackers.
<zul> jcastro: hmm ok thanks
<jcastro> zul: I'll bug someone about adding support. :D
<jcastro> zul: looks like a fix was commited for mysql/php bugtracker though
<zul> jcastro: sweet :)
<jcastro> MacSlow: thanks for your report, I got it all in!
<seb128> jdstrand: I can do debugging on the samba issue if required
<jdstrand> seb128: thanks. I really want to see if it was a -security update, or the -updates package. -updates came out right before I started on the -security update, so it isn't clear what introduced the problem
<jdstrand> (I patched -updates for -security, as per our policy)
<beDrung> calc: your ooo version works without any problems on all machines i have tested it. so thumbs up. ooo can go to -proposed
<hmuller> Why is it that -lm is not necessary on the gcc command line, when functions from math.h are included?  I've tried ##c and #gcc to no avail.
<jdstrand> seb128, zul: well, I still can't reproduce it with a gutsy server, using security = user and the 'classic share'
<jdstrand> this is with gutsy and hardy clients
<zul> jdstrand: the original bug report was for dapper wasnt it?
<jdstrand> zul: dapper server, hardy client. but people have said dapper, gutsy, hardy servers and gutsy and hardy clients
<jdstrand> zul: it's just all over the place
<zul> jdstrand: yeah that bug report is a mess
<jdstrand> zul, I'm going to start focusing on hardy server and clients. I've posted more info in the bug, maybe I'll get more details
<zul> jdong: cool
<zul> jdstrand: cool
<seb128> jdstrand: I rebuilt without the security change, installed the libsmbclient only and that fixes the issue
<jdstrand> seb128: so you removed *just* security-CVE-2008-1105.patch and it works?
<seb128> yes
<jdstrand> seb128: ok, that helps, but I still can't reproduce it locally. can you paste your smb.conf file?
<jdstrand> seb128: and are you just using a location of smb://foo/share/file from totem?
<jdstrand> s/from/in/
<seb128> yes
<seb128> I'm calling "totem smb://...." on the command line rather
<jdstrand> seb128: are the perms on the file 744 for the file you are accessing (owned by same user as one accessing the share)?
<jdstrand> btw, totem smb://... works just fine
<seb128> jdstrand: the file 744 owned by an another user
<jdstrand> seb128: ok, both work here
<seb128> changing the owner to the user makes no difference
<jdstrand> seb128: no, here either, just trying to make sure we have the same environment
<jdstrand> seb128: do you have the smb.conf file handy?
<seb128> jdstrand: sec
<pwnguin> ok this is wierd. firefox wants to save a php file when i post a comment on sabdfl's blog =(
<kees> seb128: can I pick your brain about tracing a signal connect callback?  I'm not clear where an argument is coming from...
<seb128> kees: I've to run in a few minutes but if that's quick I can have a look, tell me about it ;-)
<kees> seb128: it's between rhythmbox and totem-pl-parser.  let me paste context
<kees> seb128: http://pastebin.osuosl.org/8792
<kees> where does "metadata" come from?
<kees> I don't see it in the g_signal_connect_object, and the signal definition seems to think it only takes a string?
<kees> seb128: oh, nevermind.  I think this is a straight up crasher -- I can't even load _valid_ .pls files.
<seb128> kees: ok, didn't look yet, I'm busy on this samba thing and I've to run
<calc> beDrung: thanks! :)
<calc> slangasek: i have an update for OOo for hardy
<calc> slangasek: is it safe to stick it in -proposed or do i need to hold it off a bit
<calc> it fixes a crasher bug on gnome/kde
<slangasek> calc: doesn't hurt (me) to upload and have it sit in the queue
<slangasek> calc: how about bug #220817 along the way?
<ubottu> Launchpad bug 220817 in openoffice.org "Xubuntu Hardy: ubiquity installs Open Office during installation" [High,Triaged] https://launchpad.net/bugs/220817
<calc> slangasek: ah yea i should fix that too :)
<calc> slangasek: looks like the updates to ooo-build fix at least 3 crashes and fixes amd64 plugin (not sure if we should actually enable building that for a update though)
<calc> both the gnome/kde crashes and a svg crash as well
<slangasek> no, you shouldn't enable building something in an update that wasn't being built before
<calc> ok i'll leave that turned off then
<sbeattie> is it intended for post 8.04.1 release?
<ogra> cr3, you said your testing of the nsc/geode changes was successfull, didnt you ?
<ogra> (we need a comment on the SRU bug)
<calc> sbeattie: i guess, it is important but doesn't have to be on the disks
<calc> sbeattie: a large number of users (other than myself) under gnome and kde have OOo crash on them, i never was able to reproduce it but i found a patch for it in ooo-build and got an affected user to test it and it works
<cr3> ogra: crap, komputes didn't append to the bug? I'll do it for him, one moment...
<sbeattie> calc: okay, when it comes through, I'll try to prioritze verifying it.
<calc> how do you escape a space using scp?
<calc> i'm trying to copy with a space in the filename across the network using scp
<ogra> cr3, bug 219630
<ubottu> Launchpad bug 219630 in xorg "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Medium,Fix committed] https://launchpad.net/bugs/219630
<calc> ah you have to quote and \\ escape it
<calc> thats just weird
<cr3> ogra: done
<ogra> erci
<ogra> *merci even
 * ogra hugs cr3 
<cr3> ogra: right back at ya!
<calc> sbeattie: i'll try to get it uploaded by tomorrow
<calc> i need to track down the bugs to mark and update the changelog entries, etc
<calc> and need to fix and verify the language support bug is actually fixed
<slangasek> cr3: bug #219630 - you mentioned using xserver-xorg-video-nsc 1:2.8.3-2ubuntu3.3 successfully, which I guess was an intrepid-only upload - so that comment was just for comparison?
<ubottu> Launchpad bug 219630 in xorg "please add "geode" to driver list in hw/xfree86/common/xf86AutoConfig.c" [Medium,Fix committed] https://launchpad.net/bugs/219630
<cr3> slangasek: yes, I believe q-funk had provided that driver for testing purposes a little while ago before updates made their way to hardy-proposed
<slangasek> cr3: right; only minimally germane to the SRU validation, for which we need tests with the actual hardy-proposed packages (which you've also done, thank you :)
<pgib> Hello.  I am a developer for the program LMMS.  (Which is already included in universe)  we are about to release an alpha of the next major release.
<pgib> how do I get in touch with the MOTU maintainer for LMMS?
<Pici> pgib: #ubuntu-motu
<pgib> OK. thanks.
<Pici> Which I why I asked what you were looking for ;)
<pgib> hm?
<Pici> Before, in #ubuntu, but nevermind.
<pgib> ah ok - I missed it
<pgib> tha channel is _very_ busy
<jdstrand> hi slangasek! Would you mind peeking at #241448 and letting me know if I missed anything. seb128 was able to reproduce it with an etch server and hardy client, but I cannot with many different combinations.
<slangasek> jdstrand: I think I already tried to reproduce that myself and failed to do so
<jdstrand> slangasek: interestingly, seb128 was able to reproduce it with an etch server and hardy client
<slangasek> mmmmkay
<jdstrand> slangasek: he gave me his smb.conf-- nothing out of the ordinary, except 'security = user'
<slangasek> that's not out of the ordinary either, it's the default
<jdstrand> I tried with it (well, with path adjustments) and it works fine (on feisty server-- same version as etch)
<jdstrand> slangasek: people mentioned DivX 4/5-- tried with different ones, no problems
<slangasek> I can't imagine how the codec should make any difference
<jdstrand> slangasek: I don't have a large (ie movie length) DivX around, but wonder why file size would be an issue (1 1.7GB MPEG-2 worked fine btw)
<jdstrand> slangasek: he did say removing the CVE-2008-1105 from samba and just installing libsmbclient from that build seemed to fix it...
<jdstrand> s/CVE-2008-1105/patch for CVE-2008-1105/
<jdstrand> anyhoo, it's a mystery to me
<slangasek> jdstrand: er, very strange
<jdstrand> totally. well, I pushed it back on the user's asking for more info. hopefully something useful will come up
<jdstrand> slangasek: thanks
<jdstrand> s/user's/users/
<slangasek> cody-somerville: hi, have you or anyone else on the xubuntu team had a chance to test out the alpha-1 candidate images?
<calc> wow this was easy to fix
<calc> it was actually already supposed to be fixed but i managed to break it with the ubuntu changes
<sistpoty> slangasek: should bug #184218 still be fixed in hardy? (if so I might make use of my new core-dev powers, or criticize the debdiff *g*()
<ubottu> Launchpad bug 184218 in pbuilder "FTBFS in latest archive rebuild test" [Low,Fix released] https://launchpad.net/bugs/184218
<slangasek> sistpoty: I think that's below the threshold of bugs worth bothering about
<sistpoty> slangasek: ok, thanks... could you decline the nomination then?
<slangasek> sistpoty: once a nomination's been accepted, "decline the nomination" == "mark the hardy task 'wontfix'"
<slangasek> sistpoty: so you're welcome to do this yourself :)
<cody-somerville> slangasek, some people are testing right now but I didn't get a chance to upload that SRU we discussed earlier this week
<slangasek> cody-somerville: SRU's aren't relevant to alpha-1
<cody-somerville> slangasek, oh, alpha-1
<slangasek> cody-somerville: is anyone testing alpha-1, or just 8.04.1?
<cody-somerville> slangasek, I'm downloading alpha-1 right now
<slangasek> ok, cool
<sistpoty> slangasek: ah... I thought you'd have the option to reject it (iirc I'm seeing this for nominations of universe)
<slangasek> sistpoty: you can only reject a nomination before it's been accepted; this is a UI blemish that we discussed with kiko in Prague
<sistpoty> slangasek: ah, thanks for the info
<jdstrand> kirkland: so thinking about sessions counters and pam_ecryptfs, if a user logs in and the counter is incremented, then hits ctrl+alt+backspace, what happens? either it works right, or the counter doesn't decrement and we can never get the auto unmount until reboot
<jdstrand> I'm just thinking OTOH here
<kirkland> jdstrand: i would hope that ctrl-alt-backspace would trigger a session close
<kirkland> jdstrand: a generic pam session close, in which case my decrement counter code would run
<kirkland> jdstrand: i haven't tested that yet, of course
<jdstrand> kirkland: I would hope so too, but it illustrates my line of thinking that the counters, if implemented, would have to be very robust
<jdstrand> not that you wouldn't make it robust mind ;)
<kirkland> jdstrand: tbh, i've been testing login/ssh heavily in my kvms.... not yet gotten to anything graphical
<jdstrand> kirkland: btw, how does it handle multiple logins?
<kirkland> jdstrand: mount.ecryptfs_private notices that it's already mounted and exits gracefully
 * jdstrand nods
<jdstrand> kirkland: could have a little daemon that polls
<kirkland> jdstrand: hmm, i think i have an interim solution.........
<jdstrand> ecryptfsd
<kirkland> jdstrand: there is an ecryptfsd already, but i'm trying to avoid using it
<kirkland> jdstrand: here's what i think i'm going to implement for now....
<jdstrand> kirkland: does it server this function?
<jdstrand> serve
<kirkland> jdstrand: no, it's for advanced key management
<kirkland> jdstrand: stuff we're not yet using, openssl, public keys, TPM chips
 * jdstrand nods
<kirkland> okay, so here's what i'm going to do by end of day, so that I can leave this in a functional state.....
<kirkland> jdstrand: pam_session_close will unmount the ~/Private directory
<kirkland> jdstrand: which might potentially unmount it while other instances of the user are still logged on
<kirkland> jdstrand: perhaps inconvenient, but erring on the side of protecting the user's encrypted data....
<kirkland> jdstrand: okay, so the UNMOUNTed mountpoint, ~/Private is currently permed 500 (to keep from inadvertently writing data to it)
<jdstrand> kirkland: you may run into errors if the user is accessing it at the time of unmount
<kirkland> jdstrand: and there's a file in there called....
<kirkland> "NOT MOUNTED - Run mount.ecryptfs_private to mount this directory"
<kirkland> jdstrand: i'm going to make that a symlink to "mount.ecryptfs_private"
<jdstrand> kirkland: a side-step is not to support console or ssh at all yet, and add the pam stuff to gdm
<kirkland> jdstrand: ooh, bad.... then i get even more questions as to "why are you working on this?  aren't you on the server team?"
<kirkland> jdstrand: nah, it really, really, really belongs in PAM
<jdstrand> heh-- well, yes
<kirkland> jdstrand: i think i can convince you of that
<kirkland> jdstrand: any way.....
<jdstrand> kirkland: no, /etc/pam.d/gdm
<kirkland> jdstrand: oh,
<kirkland> jdstrand: hmm, perhaps....
<jdstrand> not *in* gdm, but in the pam stuff for gdm
<kirkland> jdstrand: anyway, doing what I described above 1) unmounts, erring on the side of protecting user data, 2) provides an easy mechanism to re-mount (the instructional symlink) for users still logged in
<jdstrand> anyhoo-- point taken on server-- I was just thinking of an easy way to get you out of here before your vacation
<kirkland> jdstrand: actually, i'm pretty happy with that (1) (2) punch for now.
<calc> slangasek: i have a update ready, just working on getting the changelog in shape
<calc> slangasek: i have to leave in a bit to help my father build his new pc, but should be able to get the upload done by the end of the night
 * slangasek nods
<jdstrand> kirkland: sure, it woks fine for the next week or so. it's less than user-friendly in the long run, but you obviously know that :)
<kirkland> jdstrand: yup
<kirkland> jdstrand: i'm afraid i'm going to need some user accounting gurus to help out here
<slangasek> calc: ok.  I'll plan to do a full ISO run before accepting OOo in any case, so that we have as current as possible of images if it fails validation.
<kirkland> jdstrand: after i'm back
<calc> slangasek: ok sounds good
<jdstrand> kirkland: actually, this instructional filename is interesting. I'm not sure how it will fly with platform (eg cjwatson), but if you define your entry points as anything using common-auth, then if people are doing something outside of that, and it's not mounted, then they get the helpful message
<jdstrand> kirkland: of course, it kinda blows up if the user removes the file
<kirkland> jdstrand: that dir is permed 500
<calc> if i want to reference a bug that i am explicitly not fixing in the upload if i just do something like Bug: #foo that won't mark it fixed right?
<calc> only if i do LP: #foo does it close it?
<kirkland> jdstrand: so it would take a very conscious effort to blow away that file
<kirkland> jdstrand: ie, you'd have to +w it, then rm it
<jdstrand> kirkland: I *might* be able to swing that, personally ;)
<ScottK> calc: To the extent Launchpad's actual behavior matches the documentation, yes.
 * calc is referencing that a patch will fix the firefox plugin when rebuilt for intrepid
<jdstrand> kirkland: sure
<sistpoty> calc: I'm usually using LP: <number> (instead of LP: #<number>) when doing so
<kirkland> jdstrand: what i like about symlinking it to the executable is that a user can just double-click in a Nautilus/GUI environment
<kirkland> jdstrand: or run it in a CLI
<jdstrand> kirkland: it's an interesting idea
 * calc is having a hard time tracking down the bug number in any case
<sistpoty> poor calc
<jdstrand> kirkland: there is the problem of if they click it that way, it is no longer 'counted', but it is 'mounted'
<kirkland> jdstrand: i'm ditching the counting all together for now
<jdstrand> kirkland: and if you did increment there, which is easy enough, how will you decrement?
<kirkland> jdstrand: i have to think that out "robustly"
 * calc might have done something dumb like accidentally close the bug
<kirkland> jdstrand: there's some code in libpam-mount that sort of does this
<kirkland> jdstrand: badly, in my experience, i might add
<jdstrand> kirkland: yeah, clearly your current path is good for the short term
<kirkland> jdstrand: it uses something called pmvarrun
<kirkland> jdstrand: i could make the file name even more descriptive...  "This directory has been unmounted in order to protect your data.  Yadda yadda"  :-)
<jdstrand> kirkland: getting back to my daemon idea-- it could be setup to automatically unmount after a while. this coupled with your symlink idea (or maybe something else) might be interesting.
 * jdstrand notes that it is surprising how complicated this little problem is
<kirkland> jdstrand: yeah, that's a good idea
<kirkland> jdstrand: i like the idea of a timeout
<calc> is anyone else having timeout problems to bugs.l.n
<gpocentek> calc: yes
<kirkland> jdstrand: like a screensaver, but for your encrypted data
<jdstrand> kirkland: oh nice analogy
<calc> gpocentek: glad it isn't just me :)
<jdstrand> calc: awfully slow here
<jdstrand> calc: it did make it though
<calc> jdstrand: it realized i am preparing a ooo upload and went down :)
<jdstrand> calc: it is bracing itself
<jdstrand> lp takes a deep breath, then... 'ok go!'
<ScottK> calc: Your route to launchpad.net doesn't happen to go through iad8.alter.net does it?
<kirkland> jdstrand: ln -s /sbin/mount.ecryptfs_private "$MOUNTPOINT"/"THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA --  Run mount.ecryptfs_private to mount again"
<kirkland> jdstrand: that'll hold for now ;-)
<slangasek> liw, cjwatson, soren: so if we're having issues with intrepid not booting as a guest in KVM, does it make sense to include jeos in alpha-1?  I guess VMWare is also a target for this, so if we tested it there it'd be good to inclued?
<slangasek> include
<calc> ScottK: no level3 the whole way
<calc> ScottK: well once it leaves att anyway
<ScottK> OK.  I'm having trouble reaching launchpad too, but it seems packets are getting eaten in there.
<calc> its working for me again
<liw> slangasek, I don't know what the intrepid/KVM issues are (soren?), but if it doesn't work, then it's not really useful to include jeos, imho
<slangasek> liw, cjwatson, soren: oh, it looks like linux-image-virtual is also still a casualty of the kernel reorg, right; ignore me, marking jeos off as "not-for-us"
<mpt> kirkland, the instructional filename thing reminds me of "Where are all the files?", which is a small text file that appears if an HFS+ volume is mounted as HFS
 * ScottK too.
<kirkland> mpt: is that a good think or a bad thing?
<slangasek> liw: well, we don't even have the JeOS kernel in intrepid right now, so. :)
 * kirkland ducks and covers?
<liw> instructional filename?
<mpt> kirkland, neither, just a possibly useful precedent
<liw> slangasek, kernels are overrated
<kirkland> mpt: ah, cool, good to know....
<kirkland> mpt: what about symlinking such a file to a script/program that can solve the problem for you?
<slangasek> liw: kernels in general, or the Linux kernel in particular :)
<kirkland> mpt: that's the one step farther I'm trying to go with this (as a short term, stop gap solution, until we get the rest of the interface business in place)
<slangasek> ?
<bryce> slangasek: hey, I've got a patch ready for testing on the amd issue
<ogra> liw, hmm ? how would you modprobe gnome without a kernel
<liw> slangasek, any kernel, we could reduce _so_ much bloat if we had custom-written I/O routines in ASM for each application
<slangasek> bryce: am I going to claw my eyes out when I see it? :)
 * liw needs to go to bed soon, /me thinks
<ogra> slangasek, its pretty sweet ...
<mpt> kirkland, that seems like a grand idea to me. Bonus points if you can avoid using the words "mount" or "unmount" :-)
<bryce> slangasek: I posed the patch itself to #219630, and am uploading x86 debs for testing here:  http://people.ubuntu.com/~bryce/Testing/geode/
<kirkland> mpt: :-)  let me see what I can do!
<slangasek> liw: ah yes, TorvalDOS
<bryce> slangasek: actually there was very similar code for dealing with ati/atimisc conflicts
<slangasek> bryce: hmm, then couldn't this have been done in the same for loop? :)
<bryce> slangasek: I tried that initially, but notice that it returns rather than breaks, since it assumes there's only one driver
<bryce> if I were to commit this upstream, yeah I'd want to rework that loop so both things can be taken into account
<bryce> however keeping it separate I figure makes the patch easier to review/understand
<ion_> linux-...-generic in intrepid fails to boot on my 586 laptop because itâs missing cmov. (Will report a bit later.)
<slangasek> bryce: well, I don't notice that because the diff doesn't provide that much context :-)
<slangasek> ion_: is this a new development? I would have expected cmov to be the baseline for -generic already, and cmovless 586 would need -386
<ion_> slangasek: I wouldnât mind installing -386 if it existed. ;-) I assumed it had been merged to -generic or something. Anyway, iâve been using hardy -generic without any problem whatsoever in the past.
<ion_> If a -386 kernelâs going to be built in the future, iâll manage with the hardy kernel until that time.
<ogra> iirc rtg's plan was to move 386 to universe
<ogra> which makes it indeed hard if you need it in the installer
<ion_> Heh, indeed.
 * ogra just remembers the issue because he was asked about ltsp .... where it doesnt matter if the kernel comes from universe since its netbooting 
<ogra> ion_, so, the easy fix is to make your laptop a thin client ... and yu will even have a spare disk then
<ion_> ogra: Heh, i wouldnât mind doing that if i had something to use as a server for said thin client. My desktop box barely handles a single session. :-) I could consider stopping using Gnome, of course...
<ogra> well, ltsp runs the session on the server :)
<ion_> Thatâs what i meant, my desktop box isnât fit to run two sessions simultaneously, unless i make the session more lightweight. I might do that.
<ogra> ah, well, gnome cant handle that anyway ... you would have to log out the local user
<ion_> Yeah, that, too. :-\
<ogra> (at least two times with the same user doesnt work)
<ion_> Yeah, iâd want to use the same user and the same session both locally and remotely.
<ion_> Read: identical session
<ion_> Oh, and firefox doesnât handle that very well either, unless thatâs been fixed. :-\
<ogra> yep
<ogra> same for openoffice
<ion_> For âOfficeâ purposes, i mostly use LyX and Gnumeric.
 * ogra doesnt have such "purposes" .... only mail attachments he need to open :)
<ion_> Oh well, i could just run xlinks2 in the remote session, thatâs what iâm doing on the laptop anyway. It would choke with Firefox. :-)
<hunger> Is debian import freeze in effect or was it postponed?
<ScottK> Autosync has been run for that last time.  Other than that it really has no effect.
<hunger> ScottK: Thanks for the info. I was getting afraid that git-core will not get updated this release cycle:-)
<bryce> hunger: I'm sure an exception would be allowed for that
<ScottK> All it takes is a developer to deal with it.
<ScottK> I'm fairly certain I don't want to be touched it last on Git.
<hunger> ScottK: Well, it is not compatible with svn 1.5, so it will probably take a new git release to make both updates possible.
<hunger> ... at least I could not build git-core with the subversion backport I have installed.
<slangasek> bryce: so this xorg -configure fix is only in your people repo now?
<slangasek> bryce: I think we should go ahead with pushing it to -proposed, both to move up the timeline and to make it easier for users to test
<bryce> slangasek: alright, I'll put it in hardy-proposed
<bryce> slangasek: ok uploading now
<slangasek> thx
<slangasek> cody-somerville: alpha-1 downloaded ok, or still downloading?
<cody-somerville> slangasek, I'm finishing some stuff up for work atm. When do you need it tested by? I thought Alpha 1 was not until July 10th.
<slangasek> no, that's alpha 2...
<slangasek> alpha 1 is today, with whatever we can manage to get out
#ubuntu-devel 2008-06-28
<MetaMorfoziS> hi all
<MetaMorfoziS> http://packages.ubuntu.com/source/intrepid/cryptsetup
<MetaMorfoziS> here the diff (and probably other links ) 404
<MetaMorfoziS> and the binary download page ony has 2-3 proper link, the others 404
<MetaMorfoziS> Any idea?
<MetaMorfoziS> How can i get that src?
<sistpoty> MetaMorfoziS: probably packages.u.c. wasn't synced yet... you might try https://launchpad.net/ubuntu/+source/cryptsetup
<sistpoty> MetaMorfoziS: (and in case you have a patch or s.th. you could also ask siretart) ;)
<MetaMorfoziS> thank you
<sistpoty> np
<MetaMorfoziS> cool
<MetaMorfoziS> no, i haven't got any patch
<MetaMorfoziS> i jsut want to get it work better
<MetaMorfoziS> :)
<sistpoty> heh
<MetaMorfoziS> so i try to build it (I'm on hardy)
<MetaMorfoziS> but that version is khm...:)
<daskreech> Hallo
<MetaMorfoziS> so thats why:)
<MetaMorfoziS> hy:)
<daskreech> is there an approved way to install VBox in hardy?
<sistpoty> daskreech: you mean virtualbox or s.th. else?
<MetaMorfoziS> daskreech > first, this isn't the better place
<MetaMorfoziS> anyways there are debs for ubuntu
<MetaMorfoziS> on vbox's site
<daskreech> Virtual box sorry
<daskreech> MetaMorfoziS: Not for the ose
<daskreech> Open source edition.
<sistpoty> daskreech: s.th. like apt-get install virtualbox-ose ;)
<daskreech> will that ever be supplied for hardy by Ubuntu ?
<sistpoty> daskreech: it should be there imo
<daskreech> 1.6 ?
<daskreech> Oh sorry should have mentioned 1.6 ;)
<pochu> you can request a backport
<pochu> but as MetaMorfoziS said, this isn't the best place for that kind of questions...
<daskreech> motu ?
<MetaMorfoziS> #ubuntu?
<daskreech> That's support isn't it not packaging?
<pochu> yes, #ubuntu-motu would be the right place
<daskreech> thanks!!
<MetaMorfoziS> http://www.virtualbox.org/wiki/Downloads
<MetaMorfoziS> but this is why don't enough for you?
<MetaMorfoziS> i don't udnerstand what is the problem with it...
<MetaMorfoziS> download, select ubuntu and that's all
<daskreech> MetaMorfoziS: I'd prefer the open source edition is all
<MetaMorfoziS> but this is the opensource edition imho
<daskreech> I'll do that if I need to but just exploring
<daskreech> no the have a page on the wiki saying there is a difference
<daskreech> thanks though
<MetaMorfoziS> I'm googling for it (the problem is don'T know what exactly i need diff or patch) but if somebody knows, please tell me how can i apply something.diff.gz
<MetaMorfoziS> that contains a directory tree with a lot of files
<MetaMorfoziS> so some batch-patch way needed:)
<pochu> zcat ../something.diff.gz | patch -p1
<ion_> sejeff: Thanks for the information!
<MetaMorfoziS> pochu > thanks, but i don't exactly understand what happened. I have extracted the cryptsetup orig source
<MetaMorfoziS> and did what you said
<MetaMorfoziS> then it created a new dir named debian
<pochu> MetaMorfoziS: do that inside cryptsetup-*/
<MetaMorfoziS> oh! okay, i try again
<MetaMorfoziS> but it again created a debian folder
<MetaMorfoziS> and didn't touched any other files
<MetaMorfoziS> i get the stuffs from here: https://launchpad.net/ubuntu/intrepid/+source/cryptsetup/2:1.0.6-2ubuntu7
<pochu> MetaMorfoziS: if you have the .orig.tar.gz, .diff.gz and .dsc, it's easier to 'dpkg-source -x *.dsc'
<MetaMorfoziS> hmm i try that too
<MetaMorfoziS> thanks
<emgent> night.
<slangasek> cody-somerville: well, xcfe4-dict is uninstallable on amd64 still which breaks the install on that arch, but otherwise the install went clean; I assume you're testing i386?
<cody-somerville> slangasek, yup
<cody-somerville> slangasek, can you manually drop xfce4-dict for this build to fix amd64?
<slangasek> cody-somerville: something has to be fixed to not try to install it, surely?
<cody-somerville> slangasek, I'm pretty sure it is just seeded. One second.
<slangasek> cody-somerville: well, the installer didn't like that it was uninstallable; I assume it wouldn't like that it's removed from the image either
<slangasek> fwiw, I've just uploaded the merge of debhelper that will make xfce4-dict buildable again
<slangasek> cody-somerville: I have to run out right now anyway, and by the time I get back debhelper should be built, so I'll just plan to fix the xfce4-dict installability that way
<cody-somerville> slangasek, awesome :)
<slangasek> cody-somerville: please test the current i386 build all the same, because if there are any other issues we'll need to make sure they get fixed in the same pass
 * cody-somerville nods.
<cody-somerville> Working on it right now.
<kees> slangasek: before DIF, is there some way to get a list of all the FTBFS auto-sync'd packages in the archive without screen-scraping the build logs?  (for me to find hardening option fall-out)
<wgrant> kees: http://qa.ubuntuwire.com/ftbfs might be helpful.
<wgrant> That will list all FTBFSes.
<wgrant> And I could probably whip up one with just syncs in a couple of minutes.
<wgrant> kees: And didn't we pass DIF a couple of days back?
<kees> wgrant: oh, whoops, heh, it was yesterday.
<kees> wgrant: cool.  how is that website generated, out of curiosity?
<wgrant> kees: It scrapes LP failed build lists, and works out which of those are for the latest SPR.
<wgrant> (the source should be linked down the bottom, as long as I haven't restricted my ~ too much...)
<kees> cool, cool.
<kees> do you download the logfiles?
<wgrant> No, but they're all directly linked there, and it would be easy enough to.
<kees> right, I was just curious if there was a single blob or rsync I could do.  :)
<kees> I'll use this to pull all the fail logs and look for hardening option failures.
<wgrant> If you want, I'll alter it to grab any logs it doesn't already have each time it runs. Probably useful for other things too.
<kees> it might be useful.  actually... is that code published anywhere?  I could add a set of key phrases to look for, and then add a flag for "possible hardneing option failure" or something like that.
<kees> wait, actually, never mind
<kees> I'm going to need to pull all the build log to search for the -Wformat warnings (which don't cause build failures) anyway.
<wgrant> kees: The code is all linked down the bottom of that page.
<kees> oh! hah, so it it.  I didn't notice the little 'source' link.  ;)
<nxvl> kees: around?
<kees> nxvl: hola
 * kees is in suspense
<nxvl> :p
<nxvl> kees: sorry, i was in other tab
<nxvl> kees: i hvae uploaded some other versions of augeas (same version with fixes)
<kees> hehe, no problem:)
<nxvl> also i replied to your mail
<kees> nxvl: everything in my first email was addressed?
<bliZZardz> wgrant : can you share the link once more (came in late) .. am also thinking of building a 'wrapper' on top of LP
<nxvl> (like a week ago :P)
<nxvl> kees: yep
<kees> nxvl: \o/  I will go take a look.
<nxvl> kees: at least i think it is
<kees> you wrote the 2nd man page?
<nxvl> kees: also some soren and siretart suggestions
<nxvl> oh no
<nxvl> that's the only think missing
<nxvl> i'm waiting for upstream to do it (they say they will we this weekend on the worst scenario)
<kees> okay, cool.
<nxvl> but i haven't check
<nxvl> i have had a busy week
<kees> nxvl: with augeus, or generally?
<nxvl> kees: i replied to your mail
<kees> nxvl: okay, thanks
<nxvl> like a week ago
<nxvl> no, i have had a busy week at work
<nxvl> i was in an internal course
 * kees nods
<nxvl> also i'm on the deadline of univerity works
<nxvl> and examsn
<nxvl> so have been busy
<nxvl> and also giving augeas some time daily
<nxvl> (you can tell by the daily uploads on revu :D)
<kees> :)
<kees> do you have the revu url handy?
<nxvl> yep
<nxvl> http://revu.ubuntuwire.com/details.py?package=augeas
<nxvl> btw
<nxvl> how did you checked the rpath issue? i can make lintian tell me anything
<nxvl> just the man page missing thing
<kees> nxvl: if you've got a few minutes, go ahead and file the ITP in Debian for it, that was on my list too.
<nxvl> kees: i have
<nxvl> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487896
<ubottu> Debian bug 487896 in wnpp "ITP: augeas -- A library for programmatically editing configuration files" [Wishlist,Open]
<nxvl> it's on the new debian version
<kees> ah! okay, sorry, I didn't see it in the revu changelog, no worries
<nxvl> (on mentors)
<kees> cool
<nxvl> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=augeas
<kees> mentors doesn't have a browseable expanded directory, so I was poking at revu for the moemnt.  ;)
<nxvl> yep
<nxvl> i know taht
<nxvl> :D
<nxvl> also it doesn't have the nice diff's
<nxvl> :D
<kees> nxvl: do you have lintian installed when you do builds?  I'm still seeing augtool needing rpath fixes (says lintian)
<slangasek> kees: I don't know of a good way to identify those packages as a class, no
<slangasek> cody-somerville: any news on the i386 install test?
<cody-somerville> slangasek, so far so good
<slangasek> ok
<slangasek> xfce4-dict is building now on amd64
<cody-somerville> splendid.
<kees> 000
<kees> gah, cat.
<slangasek> useless keypress of cat
<cody-somerville> slangasek, appears good
<slangasek> cody-somerville: please document this in the ISO tracker
<slangasek> oh, you did alerady :)
<slangasek> cody-somerville: ok, so xfce4-dict amd64 missed this publishing run, which means I get to wait another hour before I can have a fixed amd64 CD, and then after that we still need rsyncing and testing of both architectures
<slangasek> cody-somerville: what do you think about pushing out the existing i386 build, and then I can test amd64 a little bit later and push out the updated image if it looks ok?
<slangasek> (I would in that case go ahead with announcing the alpha before the amd64 build is up, as well)
<wgrant> kees: That easteregg is unfortunately buggy in Compiz :(
<kees> wgrant: hehe, yeah, I'd noticed that too.  :P
<slangasek> cody-somerville: ok, making an executive decision to do the thing I said above; I'll be available for kicking in an hour or two if you disagree :)
* slangasek changed the topic of #ubuntu-devel to: intrepid alpha-1 released, archive open | frozen: Ubuntu 8.04.1 | 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
<slangasek> calc: still hammering away at OOo?
<cody-somerville> slangasek, ok.
<slangasek> cody-somerville: ah, still up? :)
<slangasek> publisher is taking tooo looooong, I'm still waiting for xfce4-dict/amd64 to be out
<cody-somerville> slangasek, aye. I was at the other computer doing dirty, proprietary work stuff :(
<slangasek> heh :)
 * cody-somerville doesn't understand the hyper about Macs - he hates the one has to use for his current project at work.
<calc> slangasek: uploading it now
<calc> slangasek: will take an hour or so
<calc> i'm not at home so once it finishes uploading to chinstrap i have to dput from there
<calc> i'll be heading home soon, and can do it when i get there
 * calc bbl
<calc> slangasek: uploaded to the queue
<slangasek> thanks
<calc> slangasek: the code has already been tested on amd64/i386/lpia for building at least
<calc> slangasek: i uploaded a ppa of it thursday night
<calc> i just upped the version number and added the changelog entry
<calc> my dad's new Core2Quad Q9300 (2.5GHz) uses less power (at idle anyway) than his old athlon xp 1800
<calc> ~ 90W at the wall vs ~ 140W
 * calc is now headed to bed, bbl
<calc> slangasek: oh yea assuming this one passes inspection it will need to be copied into intrepid as well
<slangasek> ok
<slangasek> g'night then
<calc> have fun :)
<kahrytan> What kernel is in ibex?
<StevenK> kahrytan: At the moment, Intrepid has the same kernel as Hardy. It's planned to be 2.6.26.
<slangasek> StevenK: actually, we're already at 2.6.26(pre) in intrepid
<slangasek> not on lpia, mind
<StevenK> Ah.
 * StevenK is out of date.
<wgrant> StevenK: I think even linux-meta is 2.6.26 now.
<StevenK> I see that.
<kahrytan> slangasek,  whats in first alpha?
<slangasek> 2.6.26pre.
<kahrytan> basicly, beta kernel
<slangasek> mentioned in the technical overview page.
<kahrytan> RC5 oops
<kahrytan> ill put in vbox
<kahrytan> Quiet place
<geser> !weekend
<ubottu> 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.
<kahrytan> oh hello heser
<kahrytan> geser
<kahrytan> geser,  are you developer?
<geser> I'm a MOTU
<kahrytan> Busy person eh
<geser> yes, as universe isn't small
<nxvl> universe rocks
<kahrytan> Does vbox/vmware testing even matter to ubuntu?
<nxvl> yep
<kahrytan> Mattered most for Hardy though
<nxvl> (if you mean test alphas/betas using vbox/vmware)
<kahrytan> nxvl,  why does it matter?
<nxvl> because we don't care only for hw testing, also for procedure/packages/instalation
<slangasek> nxvl: I sense a spin-off of a spin-off in the making.  "I love the whole universe // and all its unpacked source <boom de ah da>"
<nxvl> which are hw independt
<nxvl> slangasek:
<nxvl> slangasek: :D
<nxvl> slangasek: is just that MOTU is fun
<kahrytan> nxvl,  software bugs show up in both environments?
<nxvl> yup
<kahrytan> well, vbox hangs on python-gnome2
<nxvl> for example, if it fails to install ubuntu-minimal it will fail using real HW or VM
<nxvl> kahrytan: or that
<nxvl> :D
<kahrytan> i plan to setup tiny partition for ibex. I gotta lil hw issue in hardy and wonder if 2.6.26 fixes it.
<kahrytan> I know hunger is a developer
<emgent> morning
<nxvl> emgent: night :D
<kahrytan> Aloha, emgent
<emgent> nxvl: lol night :)
<nxvl> well, almost morning
<kahrytan> its 11pm here
<bheekling> Hello!
<bheekling> I just have a little question
<bheekling> Do you guys use -Wl,O1 for building the debs?
<bheekling> LDFLAGS ie
<nxvl> kahrytan: 4 am here
<kahrytan> nxvl,  did you stay up all night or wake up early?
<nxvl> bheekling: if you need to yes, if not, don't
<nxvl> kahrytan: it's saturday i have just come back home
<bheekling> nxvl, I just need to know if that's the default setting you guys use -- I believe that's the safest LDFLAG
<nxvl> bheekling: well it depends on the packager
<nxvl> bheekling: and the package
<bheekling> nxvl, so you leave it completely to the discretion of the maintainer?
<bheekling> With no guidelines?
<nxvl> bheekling: there are some guidelines
<nxvl> bheekling: take a look at the debian policy
<nxvl> but yes, it's completely to the discretion of the maintainer
<nxvl> and the ackers
<nxvl> or archive managers
<bheekling> nxvl, okay, I'll grok the debian policy :)
<bheekling> Thanks!
<kahrytan> nxvl,  Why does Ubuntu force people to install openoffice?
<nxvl> kahrytan: you can remove it
<kahrytan> I always do. Most of it at least.
<Hobbsee> because most people actually want an office suite.
<kahrytan> Hobbsee,  Just those who need spreedsheet/presentation app
<Hobbsee> which, last i checked, is still an awful lot of people.
<kahrytan> If people just need Word, then Abiword better.
<Hobbsee> yes, but people don't tend to just need word.  there are a heck of a lot of spreadsheets around.  case closed.
<nxvl> btw
<nxvl> people doesn't need word
<nxvl> and they can't have it on linux
<nxvl> they need text procesors with is a different thing
 * Tm_T pokes nxvl 
<Tm_T> you do need word, Kword ;-P
<nxvl> kword is still a text procesor
<Tm_T> it is, but it's more than that ;)
<nxvl> ok
<Tm_T> really, you are right, I was just making stupid joke
<kahrytan> Tm_T,  Never used it. I like Abiword.
<nxvl> it's text procesor on steroids
<nxvl> but a text procesor
<Tm_T> yup
 * nxvl hates abiword
<kahrytan> nxvl,  why?
<Tm_T> kahrytan: I like Kate, should I say people doesn't need OpenOffice, just Kate ?
<nxvl> because it's unstable, ugly and lacks of LOTS of features
<nxvl> time to sleep
<nxvl> see you!
<Tm_T> nxvl: sleep well
<kahrytan> I always thought Oo Word is ugly.
<kahrytan> Abiword reminds me of Office 97
<wgrant> kahrytan: And OOo reminds me of Office 2000. What's your point?
<wgrant> (disclaimer: I hate OOo)
<kahrytan> 84% complete on ibex
<wgrant> kahrytan: Intrepid Alpha 1, you mean?
<wgrant> Unless you have servers running Heron or Drake.
<wgrant> I don't know anybody who does.
<kahrytan> Im using vbox
<wgrant> I see the relevance.
<kahrytan> wgrant, I plan to hdd test.
<wgrant> I continue to see it.
<kahrytan> wgrant,  to what?
<wgrant> kahrytan: I'm failing to see how using VirtualBox makes you use an irregular name for Intrepid.
<kahrytan> wgrant,  Ibex is faster to type then Intrepid.
<kahrytan> I've been trying to remember what I remember you from, wgrant
<kahrytan> wgrant,  didnt i contact you via email about totem-mozilla?
<wgrant> kahrytan: There was that Firefox plugin finder bug.
<wgrant> Which you managed to get me to look at and fix.
<kahrytan> Thats why i remember you
<wgrant> I would hope so.
<kahrytan> INtrepid installed just find
<kahrytan> fine*
<kahrytan> wgrant,  Whats with people and dark color themes?
<wgrant> kahrytan: It's the new thing, I guess. Vista does it, so we must.
<wgrant> I used one for a while last year, and now again since Intrepid has one...
<kahrytan> wgrant, uh. Vista doesnt.
 * Hobbsee requests all vista talk heads to #ubuntu-offtopic.
<kahrytan> Vista uses light blue color by default
<wgrant> The taskbar is black, no?
<wgrant> I've not seen blue in Vista, other than the background.
<kahrytan> wgrant,  if you count taskbar then you have to remember XP
<wgrant> Which was blue, like the rest of it.
<Hobbsee> second warning.
 * wgrant drops Windows ME on Hobbsee
<wgrant> Or is it Me? I forget.
<kahrytan> wgrant, There is new proposal in forums for Intrepid. It looks better
<kahrytan> I do know onething, Icons and NewHuman dont go together
<wgrant> kahrytan: The Human iconset was meant to be replaced for Hardy, so I presume it will be for Intrepid.
<kahrytan> wgrant, I didnt want to say it but .. please do.
<wgrant> Do what?
<kahrytan> change human icons
 * wgrant is a mere (primarily security) MOTU.
<kahrytan> wgrant,  Human look to Elementary icon theme
<wgrant> The most desktopy thing I've done is fixing your bug.
<kahrytan> wgrant,  Why did you  fix that bug?
<kahrytan> There is so many people on freenode who dont realize that getting cloak is easy as 1-2-3
<wgrant> kahrytan: Because not many bugs unfixably destroy the packaging system.
<kahrytan> wgrant,  which that bug did
<wgrant> kahrytan: Correct.
<wgrant> So it was in everyone's interests to get it fixed ASAP, and I felt it to be within my grasp.
<kahrytan> wgrant,  you ever figure out how to fix effected people?
<cjwatson> kahrytan: don't confuse not being interested in a cloak with not knowing how to get a cloak
 * cjwatson for one is not interested
<kahrytan> cjwatson,  my bad.
<kahrytan> cjwatson,  you work on the installer?
<Hobbsee> kahrytan: no, evand does, like i told you yesterday (or was it the day before?)
<Hobbsee> although he does some work on it
<kahrytan> yesterday.. darn. i forgot.
<cjwatson> I do too, yes
<cjwatson> kahrytan: ^-
<kahrytan> cjwatson,  I figured you might do some work.. hence the reason for that channel
<cjwatson> less so of late, but will hopefully increase again later this cycle
 * cjwatson -> out
<aldolat> Hi to all... I was updating my freshly-installed Hardy Heron when I received this alert: http://www.aldolat.it/download/tmp/screenshot3.png
<aldolat> What do you think?
<kahrytan> aldolat,  goto #ubuntu
<chrisj> Is there some general channel for application developers?
<ogra> siretart, around ?
<ogra> siretart, seems you uploaded libopenal-dev, its missing the .la file which breaks rss-xgl builds (http://launchpadlibrarian.net/15646475/buildlog_ubuntu-intrepid-i386.rss-glx_0.8.1-10ubuntu1_FAILEDTOBUILD.txt.gz)
 * Hobbsee scratches head.
<Hobbsee> come on apt, behave!
<Tm_T> Hobbsee: scratch also trunk and branches
<fta> anyone could try to reproduce bug 243717 please ?
<ubottu> Launchpad bug 243717 in grep "case sensitive grep broken with UTF8 in intrepid, breaking scripts" [Undecided,New] https://launchpad.net/bugs/243717
<Hobbsee> whoa!  new artwork!
<ion_> You mean the painful Gtk theme? :-)
<Hobbsee> yeah...
<Hobbsee> all i can say is, "it'll stop people complaining about the orange"
 * ogra really likes it 
<ion_> This seems to be a normal phase in the development versions of Ubuntu: a painful, experimantal new theme is uploaded, everyone complains, itâs reverted or fixed. ;-)
<Hobbsee> ogra: it seems that only parts are actually in the new colours - do you get that?
<siretart> ogra: please file a bug and assign it to me, I'll get to it either this weekend or early next week
<ogra> i dont run intrepid, i only watched kwwii developing the new theme
<Hobbsee> ogra: i'm getting the whole "part of the desktop is dark and brown, yet the other part is white and grey" thing.
<ogra> siretart, fine with me, rss-glx isnt critical, but i dont know what else might break ...
<ogra> Hobbsee, yeah, sounds like not all apps are updated yet etc .... there are some app specific fixes needed where things like nautilus dont respect a new background color or firefox shows ll the pulldown links in the input matching in green text
<Hobbsee> ogra: yeah, i guess konversation, firefox, and thunderbird arent' good testing apps
<Hobbsee> ooh, i see.
<Hobbsee> gedit shows up better.
<wgrant> Hobbsee: Restart some apps.
<wgrant> Hobbsee: All of mine have been dark for a few days, but I needed to restart some.
<ogra> siretart, bug 243719 is yours :)
<ubottu> Launchpad bug 243719 in openal "libopenal-dev is missing the .la file" [Undecided,New] https://launchpad.net/bugs/243719
<ion_> The biggest problem i had was most of the webpages being really bright compared to the theme. The second biggest was that i just prefer to read black text on a light grey background.
<wgrant> ion_: Then change to the light version of the theme.
<ion_> I did.
<Hobbsee> ion_: ++
<wgrant> I quite like it, as it means my dark terminals blend in.
<ion_> And since most users will, perhaps it should be the default. ;-)
<wgrant> It is a bit of a default change. I know a lot of people who run dark themes anyway, but it's probably not a good sample.
<Hobbsee> wgrant: yeah, the terminals look very nice.
<Hobbsee> except for the fact that it's partly translucent, and there's lots of text behind said terminal.
<ion_> Ouch
<wgrant> Hobbsee: The actual terminal bit isn't transparent, right?
<wgrant> (unless you've told it to be...)
<Hobbsee> wgrant: no, just the lighter colour around it
<Hobbsee> where the file menu is, and such
<wgrant> The widgets are meant to be transparent - gnome-terminal looks to set them to be RGBA, and this Murrine supports translucency.
<wgrant> It looks very good when you have blur on, but that's unusable on Intel chips.
<Hobbsee> hmm.  no fire.
<Hobbsee> ah, fire!
<_max_> anyone happen to be an ace on GPT partition table and how ubuntu seems to use it differently from Debian ?
<Chipzz> ogra: that's not a bug, that's a feature ;)
<chrisj> Has the murrine with translucency support been released?
<costi> hi all
<costi> is my last prject appropriate for multiverse?:
<costi> https://savannah.nongnu.org/projects/gooload
<fbond> Hi, I may file a bug, but I wanted to make sure I wasn't missing something.  In Hardy, /etc/acpi/power.sh enables and disables laptop mode where appropriate, but also mucks around with hdparm -B and -S itself, even though laptop mode manages those things.  Is this a bug?
<fbond> Interestingly, when going on battery, it overrides laptop mode's settings, but when going on AC, laptop mode takes precedence...
<fbond> (And -B 1 seems a bit excessive to me...)
<Yud_Zroc> what programming languages will work with all operating systems (like making a program for ubuntu windows and mac)
<selckin> java
<Yud_Zroc> what about c++
<hippu> it works too
<Yud_Zroc> ok
<ScottK> Perl and Python as well.
<Yud_Zroc> cause my school teached c++ and i want to join the comunity in destroying windows (evil smirks)
<ScottK> It's probably easiest to write cross-platform code in Perl and Python.
<Yud_Zroc> is c++ easy
<jpds> Yud_Zroc: It's like everything, takes time and practise.
<Yud_Zroc> i mean for customizability
<Yud_Zroc> can anyone 1 on 1 with me about compiling code
<Yud_Zroc> its like greek to me :(
<jpds> !build-essential > Yud_Zroc
<ubottu> Yud_Zroc, please see my private message
<Yud_Zroc> i did
<Yud_Zroc> jpds whats that supposed to mean :(
<jpds> Yud_Zroc: See the link it gave you.
<Yud_Zroc> ya
<fbond> Any ACPI-aware developers have a second to consider my question (above)?
<ScottK> !weekend | fbond
<ubottu> fbond: 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.
<Yud_Zroc> ok how about some jokes then to keep pople buzy :)
<jussi01> no
<jussi01> we are busy enough as it is
<Yud_Zroc> ok
<\sh> hmm..who can post on the fridge?
<jpds> \sh: I'd try #ubuntu-news
<jpds> \sh: But I think the list is: https://edge.launchpad.net/~ubuntu-fridge
<Dekans> hello all
<Dekans> how can I suggest a new app to integrate in next release ?
<orbisvicis> was (x)vnc updated recently
<sistpoty> hm... can anoyne enlighten me, why apt bails out for perl, even if there's a replaces against libarchive-tar-perl? (cf. bug #235454)
<ubottu> Launchpad bug 235454 in perl "perl 5.10 file conflict with libarchive-tar-perl" [Undecided,Confirmed] https://launchpad.net/bugs/235454
<sistpoty> I mean, shouldn't it just replace /usr/bin/ptar instead of saying there's a conflict?
#ubuntu-devel 2008-06-29
<pwnguin> hmm. it's never good when the first page of google search for an idea contains a patent hit
<ion_> A software patent? Just ignore it. :-P
<pwnguin> i wasn't planning on implementing it anyways
<pwnguin> i could see a future where software patents exist
<pwnguin> 3 year terms and working source code
<pwnguin> fortunately, it looks like they're all taking my small idea and building something bigger with it, rather than claiming the small idea as their own
<pwnguin> just lookin to see if there's a standard way of doing DAGs in XML
<Hobbsee> Keybuk: ping?
<Iulian> G'morning
<LCID_Fire> Hi
<LCID_Fire> Does anyone know how to properly package a autotools build app?
<RAOF> LCID_Fire: Almost everyone here, I'd wager.
<persia> LCID_Fire: In fact, it's the default, for any packaging guide you might find.
<LCID_Fire> the guides I found till now are not very clear about this :(
<persia> LCID_Fire: Which guide?
<brt> HI All how to sync wm6 smatphone in linux ?
<ion_> brt: The first step is to read the topic.
<persia> brt: You'll want to ask that question on #ubuntu, or if there is no response, post it on questions.launchpad.net/ubuntu
<brt> ah thx
<RAOF> LCID_Fire: Oh, is this writing the autofoo to _build_ said app, or doing the Debian packaging?
<LCID_Fire> RAOF: Autotools chain is running fine - but packaging the whole thing for debian is confusing me pretty much
<persia> LCID_Fire: In short, just make sure that debian/rules build contains everything required to build the package, including any autotools stuff.
<LCID_Fire> I have - but now it complains about the autocreated files
<persia> When does it complain?
<LCID_Fire> e.g.:
<LCID_Fire> dpkg-source: cannot represent change to INSTALL:
<LCID_Fire> dpkg-source:  new version is plain file
<LCID_Fire> dpkg-source:  old version is something else
<persia> You also need to make sure debian/rules clean restores the directory to the state it had prior to debian/rules $(anything else)
<LCID_Fire> That would mean I'd have to remove all autocreated files!?
<persia> Yes.
<LCID_Fire> I just hope there is some call to do this easily
<LCID_Fire> Did not really help. I now added ./autogen.sh and ./configure before doing 'make distclean' but it still complains
<RAOF> Is there not already a nice clean upstream tarball?  (Presumably not)
<ion_> Itâs better to run the auto* stuff yourself and let it stay in the diff.
<LCID_Fire> No it's my own app ;)
<RAOF> LCID_Fire: Then why don't you release a tarball with "make dist"?
<RAOF> Nice and easy.
<LCID_Fire> Because I don't know shit about debian packaging!?
<ion_> Thatâs not related to Debian at all.
<LCID_Fire> Where is the difference between make dist and make install?
<Robot101> one makes a dist tarball of the source, the other installs the compiled program to your system
<LCID_Fire> k, but I still need to compile & package the tarball since I have users that are presumably not experienced enough to compile for themselfs
<persia> LCID_Fire: Sure, but you'll find it easiest if you get the upstream tarball all perfect first, and then package it.  Less confusing that way.
<RAOF> Traditionally, the way to distribute a release is with a tarball made by make dist (note: for added bonus marks, ensure that make distcheck works)
<RAOF> That way, people don't need to mess with the autofoo; they just run ./configure
<LCID_Fire> Does anyone have a good tutorial on make dist? Google is not very good for such topics
<RAOF> Its an automagic target created by autotools.
<RAOF> It basically tar-s up everything that's needed to build the package.
<LCID_Fire> Ok, I fixed it. I had an error in a configuration switch I usually never compile - which 'make dist' chocked on
<emgent> morning
<LCID_Fire> more like good afternoon :)
<persia> Depends on one's location.  It's even night some places :p
<LCID_Fire> Not to mention one's getting up habits :)
<LCID_Fire> k, I give up - not in the mood fore more headache anymore. Thanks for now though
<brandonperry_> nixternal: ping
<nixternal> brandonperry_: pong?
<brandonperry_> uh, I had a question about install KDE4.1-beta 2 for leonov, but I was tol dto go to #leonov
<brandonperry_> but thanks for responding :-)
<nixternal> np
<BenC> pitti, doko: Any chance one of you is around?
<BenC> cjwatson: ?
<eric_medintux> hello
<eric_medintux> I need some help to create a paquet debian for ubuntu
<eric_medintux> need to transfert ini files into $home dir of user
<eric_medintux> in the structure /etc/skel do this ?
<BenC> eric_medintux: there's better channels than this for packaging questions
<Chipzz> eric_medintux: 1) #ubuntu-motu 2) what you're trying to do is against debian policy
<eric_medintux> BenC : which ones ?
<Chipzz> eric_medintux: #ubuntu-motu
<eric_medintux> Chipzz : ok thanks. against debian policy ? Lots of apps put things into $home/.***
<eric_medintux> this is not recommanded ?
<BenC> eric_medintux: they create them in $HOME when the app is run, not when it is installed
<BenC> eric_medintux: You cannot install config files in every $HOME when the package is installed :)
<Chipzz> eric_medintux: let me clarify: you are allowed to put files in /etc/skel . You are (for obvious reasons) NOT allowed to touch any file in users homedirs
<eric_medintux> BenC : Ok my app need to install not the package
<BenC> eric_medintux: ok, then that's not a packaging question at all
<BenC> eric_medintux: and /etc/skel is the wrong place
<eric_medintux> what is the right place ?
<BenC> eric_medintux: if your app needs to copy it from somewhere when it is started up, then the best place is /usr/share/<pkgname>/base.config or something
<Chipzz> eric_medintux: the reason is very simple: by creating or changing files in the users homedir, you are altering the behaviour of applications, which the user didn't ask for
<eric_medintux> ok but this is a supplementary step into getting app working
<BenC> Chipzz: your confusing this, applications are allowed to modify their own config files in a users homedir
<Chipzz> anyway -> #ubuntu-motu
<BenC> Chipzz: that has nothing to do with packaging
<eric_medintux> my files does contain only user parameters
<Chipzz> BenC: no I'm not confused. just trying to explain him why packages can't alter files in the users' homedir
<BenC> Chipzz: he's not asking for the package to change it, his app is
<eric_medintux> Benc, Chippzz : I'm french so... I wish my package to install *.ini of my app into $home. Maybe creating a group named <myapp> ?
<eric_medintux> then user tells i want to be a myapp user and get the ini files
<BenC> eric_medintux: Uh, now you're way off base...go to #ubuntu-motu
<eric_medintux> K bye and thank you for all.
<Yud_Zroc> any people on to help me with something real quick on a definition
<wgrant> !ask
<ubottu> Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
<Yud_Zroc> what is this error mean "svn: Malformed network data"
<wgrant> Yud_Zroc: You want to ask in a Subversion channel, I believe.
<wgrant> As it's not Ubuntu development, and it's not really Ubuntu at all.
<Yud_Zroc> ok tyvm for the tip
<Yud_Zroc> do u know what the channel is called
#ubuntu-devel 2009-06-22
<rgreening> dtchen: hey
<dtchen> rgreening: hi.
<rgreening> I should be soon done with my current project. I can help with pulse/gstreamer then.. dtchen
<dtchen> rgreening: great
<rgreening> np.
<rgreening> hopefuly by end of this week.
<Vantrax> anyone here good with pulling information out of gnome?
<Vantrax> im trying to work out how to pull the value for the gnome power manager idle timer via dbus-send. It should look something like dbus-send --session --dest=org.gnome.PowerManager --type=method_call --print-reply --reply-timeout=2000 /org/gnome/PowerManager org.gnome.PowerManager.<something to do with idle timer> I just cant find the end bit
<RAOF> Vantrax: You're probably better off in #gnome-hackers on irc.gimp.org for questions like that.  Having said that, the d-feet dbus browser will be your friend.
<Vantrax> thanks for that RAOF, ill check into both
<Vantrax> RAOF: d-feet doesnt show buses existing that are listed in the gnome docs, has ubuntu changed things? org.gnome.PowerManager doesnt even exist
<RAOF> As far as I know, org.gnome.PowerManager has been gone for a release or two; it changed to org.freedesktop.PowerManager, and now most if it seems to have been subsumed with org.freedesktop.DeviceKit.Power on the system bus.
<Vantrax> ahh
<Vantrax> old doco
<Vantrax> im not showing devicekit, only consolekit, but im seeing what im after there i think
<RAOF> Vantrax: It's changed in Karmic.
<RAOF> New gnome-power-manager, new DBus API.
<Vantrax> ahh
<Vantrax> so its consolkit now, but changing to devicekit
<RAOF> No, it's still ConsoleKit, but DeviceKit has joined it.
<RAOF> There's a big proliferation of Kits.  And not the cool car, sadly.
<lifeless> its freaking annoying
<lifeless> consolekit devicekit realtimekit sillynamekit
<Vantrax> no wonder im getting confused
<Vantrax> so, im 90% of the way there.
<Vantrax> im getting an error from this command: dbus-send --system --dest=org.freedesktop.ConsoleKit --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.GetSystemIdleSinceHint string:iso8601_datetime
<lifeless> should make a smileyfacelibrary called 'sadkit'
<Vantrax> Error org.freedesktop.DBus.Error.UnknownMethod: Method "GetSystemIdleSinceHint" with signature "s" on interface "org.freedesktop.ConsoleKit.Manager" doesn't exist
<Vantrax> i dont know what the signature "s" means
<lifeless> string
 * Vantrax is creating an idle shutdown timer
<Vantrax> so the error is likely with 'string:iso8601_datetime'
<Vantrax> thats what d-feet is showing the value as tho...
 * Vantrax is now very confused
<Vantrax> RAOF any ideas where the error is in that command, it should be fine based on what d-feet is spitting out
<RAOF> Vantrax: No idea whatsoever, sorry.
<RAOF> #gnome-hackers :)
<Vantrax> lol
<Vantrax> thanks again
<RAOF> Or possibly #I-Hate-*Kit
<Vantrax> now to find my way to irg.gimp.org
<Vantrax> i live there:P
<StevenK> #I-Hate-*Kit actually exists? :-)
<Vantrax> RAOF you still floating aroudn?
<RAOF> Yeah, but not for long.
<Vantrax> dbus-send --system --dest=org.freedesktop.ConsoleKit --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.GetSystemIdelSinceHint is now working, but not returning anything but and empty stromg
<Vantrax> string
<Vantrax> and empty string
<Vantrax> from what i gather, its supposed to return the date/time that the system has been idle for
<RAOF> I'm blank.  I've got no better idea than d-feet gives me.
<Vantrax> he he he
<Vantrax> #gnome-hackers:P
<TheMuso> cat Spads
<TheMuso> woops wrong window, and damn tab completion. Sorry Spads.
<bgamari> Where is the debug info package for gnome-settings-daemon
<RAOF> gnome-settings-daemon-dbgsym
<RAOF> bgamari: Specifically: https://wiki.ubuntu.com/DebuggingProgramCrash
<bgamari> RAOF, that package doesn't seem to be available for karmic
<bgamari> I don't think debugging symbols are generated for this package
<bgamari> could it be a packaging mistake?
<RAOF> No.  They're there, but if you follow that link you'll see you need to add the dbgsym repository.
<bgamari> ahh, yep
<bgamari> my bad, sorry. new to debian-esque distros
<RAOF> Well, this is something Ubuntu-specific.  As a part of our build process we automatically strip all the debug symbols out into -dbgsym packages.
<bgamari> RAOF, sure
<bgamari> RAOF, What exactly are the -dbg packages in that case?
<cjwatson> geser: pdftk> I'd be inclined to say that unless the copyright holder is demanding it then we should just fix it in Karmic. It would take heroic measures to remove those files from stable releases in a meaningful way, and I'm not sure it's worth it unless we have to
<slangasek> morning
<pitti> Good morning
<Hobbsee> orning pitti!
<pitti> slangasek: ugh, please file a bug, yes
<pitti> hey Hobbsee
<slangasek> pitti: yep, will file it later today
<StevenK> Morning pitti
 * Hobbsee throws pitti a few gummy bears
 * pitti munches
<slangasek> pitti: so where is pkgbinarymangler getting hooked in that's causing this?  I thought it used to only hook into dh_strip?
<pitti> slangasek: right, and it still does
<pitti> slangasek: argh, sorry; that was pkg-create-dbgsym
<pitti> pkgbinarymangler is dpkg-deb
<slangasek> ok
<pitti> slangasek: it needs to update the md5sums of *.desktop
<slangasek> darn, there's no way to hook it earlier?  fixing up the md5sums file after invalidating it feels dirty to me
<pitti> slangasek: we could do it earlier, of course
<pitti> but more diversions
 * slangasek nods
<slangasek> (dh_desktop? :)
<pitti> very few programs use that
<pitti> dh_install is too early, misses a lot of them
<slangasek> waah
<slangasek> ok
<pitti> dh_md5sums :)
<slangasek> heh
<StevenK> Hasn't dh_desktop been mostly killed anyway?
<slangasek> StevenK: yah, manpage says it's obsolete
<StevenK> I thought so
<pitti> slangasek: that could only be an alternative route, though, since again packages might not actually use it
<slangasek> pitti: right
<\sh> moins
<dholbach> good morning
<ak4d7>  hi everyone i need help recovering a ubuntu installation after crashing it with a compiz configuration now it won't login or start
<Hobbsee> (please don't cross post, and #ubuntu for support questions)
<lifeless> TheMuso: ping; dmraid
<geser> good morning
<The_Warlock> i made a quirk for my intel graphics cared as the resolution was very low. but upon restart my resolution falls back to very low resolution unless i restart xserver.
<The_Warlock> how do i fix this?
<The_Warlock> this is 9.04
<TheMuso> lifeless: Yeah I have been neglecting it somewhat. Re the dmraid-activate problem, I really don't know, as I've been unable to reproduce it here, although Ihaven't tried with karmic. As for your lba patch, I'll push it to debian and do an Ubuntu upload with it included.
<lifeless> cool
<lifeless> my patched version boots fine with libata.ignore_hpa=1, so I'm sure I haven't borked anything
<TheMuso> ok
<asanchez> Hi everybody, I would ask for someone with a Toshiba Dynabook UX netbook
<asanchez> I ask in this channel because I remember to see one guy from Canonical with this netbook
<asanchez> We are planning to buy hundreds of units of this model but we aren't able to make sound work under 9.04 but it works under 8.10
<mok0> Hm, sound
<mok0> asanchez: you might have better luck asking in ubuntuforums
<asanchez> mok0, i have just reported a bug
<asanchez> but there is a very few people with this model and there is no info in any forum jet
<mok0> asanchez: that's fine, but ubuntuforums has hundreds of thousands of users and your luck there may be better. You can also try asking a question on LP instead of a bug
<asanchez> I'll do, thanks
<mok0> asanchez: did you try the trivial things such as turning up the volume on the mixer?
<asanchez> of course
<mok0> asanchez: sorry, I had to ask :-) It's the most common problem, I've had it myself
<asanchez> mok0, :-) We are working together with Toshiba engineers but something has changed between alsa versions of intrepid and jaunty
<mok0> asanchez: Interesting... well it's pretty quiet around here just now, you may be able to reach a -dev that can help you later
<mok0> asanchez: you can also try sending a message to ubuntu-dev-discuss ML
<The_Warlock> can somebody tell me how to fix my low resolution issue on upgrading to 9.04
<asanchez> mok0, ok I'll try later, thanks
<The_Warlock> i use 00:02.1 Display controller: Intel Corporation 82Q33 Express Integrated Graphics Controller (rev 02)
<bigon> autosync from debian still active for main pkg too?
<slangasek> bigon: yes
<pitti> mvo: is compiz still blacklisted on 965 in karmic?
<ogra_> shouldnt be anymore
<pitti> bryce: good feedback with jaunty-proposed -intel, I copy the stuff across now
<ogra_> (i know it was changed in bzr a while ago)
<pitti> the bug task is still open, I wonder whether I should close it
<pitti> mvo: nevermind, saw the changelog
 * Hobbsee cheers at pitti for attempting to fix the intel graphics borkage
<pitti> Hobbsee: does it work for you now?
<Hobbsee> pitti: no :(
<Hobbsee> pitti: i've had X die and make the machine unresponsive 3 times today.  two of those times werer in 10 minutes of each other
<Hobbsee> pitti: however, under metacity, it appears to work fine.  No screen blankings, no X server suiciding, or anything
<pitti> hm, since today, one of my CPUs is constantly at 100%, and top shows nothign (just 10% gconf); does that happen to anyone else?
<pitti> might be xorg-edgers breakage
<ogra_> not here
<ogra_> even my swap seems calm (system was running over the weekend and upgraded yesterday the last time)
<Hobbsee> pitti: i don't see it, fwiw
<pitti> hah
<pitti> killall metacity did it
<pitti> cprov, al-maisan: hm, why does https://edge.launchpad.net/ubuntu/+source/sg3-utils/1.27~repack-0ubuntu1 not show any more that the binaries are NEW
<pitti> ?
<StevenK> pitti: There's a bug about that
<pitti> ah, ok
 * al-maisan looks
<al-maisan> pitti: it says "PENDING: Karmic  pocket Release  in component main  and section admin"
<pitti> al-maisan: right, I overwrote it to main in the NEW queue, but didn't accept them
<pitti> (since I uploaded them)
<pitti> so they should be stuck in NEW until some archive admin reviews them
<al-maisan> pitti: did you observe that expected behaviour in previous similar cases?
<pitti> al-maisan: yes, it always said the queue after the build status before
<pitti> like (ACCEPTED), or (NEW), or (DONE)
<pitti> al-maisan: check non-edge: https://launchpad.net/ubuntu/+source/sg3-utils/1.27~repack-0ubuntu1
<al-maisan> pitti: it got published in the mean time
<pitti> right, the source, but not the binaries
<al-maisan> pitti: right, I see now.
<al-maisan> pitti: sorry, I would not know the reason; it was changed only recently (edge vs. non-edge)
<al-maisan> pitti: I am sure cprov will comment on it though.
<pitti> al-maisan: thanks
 * StevenK digs up the bug number
<StevenK> pitti, al-maisan: Bug 388690
<ubottu> Launchpad bug 388690 in soyuz "status ACCEPTED/NEW not shown anymore" [High,In progress] https://launchpad.net/bugs/388690
<al-maisan> StevenK, pitti: "status: Triaged â In Progress"; so it looks cprov is already working on it.
<pitti> ok, so it seems this wasn't intended then
<al-maisan> yep
<mok0> I am getting a libtool (internal?) error in netcdf:  ../libtool: line 847: X--mode=compile: command not found
<mok0> hrmph, trying libtoolize -fc
<seb128> mok0: try autoreconf rather
<mok0> seb128: libtoolize works...
<mok0> seb128: I plan to let the new ltmain.sh etc. come via diff.gz, you agree it's ok to do it like that?
<mok0> seb128: the .diff.gz is pretty dirty already
<seb128> I don't know this package enough to comment
<seb128> I tend to put autotools changes in a patch in the debian directory
<mok0> seb128: me too, but for a rebuild I'd rather not mess with patches
<seb128> a rebuild should not break this way
<seb128> if it does that's because you have a bug
<mok0> seb128: the bug is that upstream is distributing an age-old version of libtool files
<seb128> which is fine if you don't run autotools at build time
<mok0> seb128: it's not run
<mok0> seb128: ... and it's also not fine :-)
<seb128> it's probably run because of a timestamp issue or something
<seb128> there is no reason why it should break otherwise
<mok0> seb128: oh, ltmain.sh is always run, to make libraries
<mok0> seb128: that's why it helps to use a newer one
<seb128> it's rather some autotools which are run there or you would not have the error
<seb128> "line 847: X--mode=compile: command not found"
<seb128> you usually get that when running autotools not correct
<seb128> ie missing some update commands
<mok0> seb128: that disappears after running libtoolize -fc in srcdir
<seb128> right
<seb128> as said the bug is there when you don't run all the required commands
<mok0> seb128: it IS doing something strange in the build...
<mok0> seb128: damn, he's patching acinclude.m4
<mok0> ... and configure .ac
<mok0> http://launchpadlibrarian.net/28195811/buildlog_ubuntu-karmic-i386.netcdf_1%3A3.6.2-3.1build1_FAILEDTOBUILD.txt.gz
<seb128> pedro_: ola!
<pedro_> bonjour seb128!
<apw> mvo, you just uploaded a grub fix, do you know if the same issues appear in grub2?
<cjwatson> grub2 doesn't handle the crashkernel stuff right now
<mvo> apw: as cjwatson said, the whole crashfile stuff needs to be ported to grub2
<mvo> apw: I'm struggling with "crash" right now, it does not want to give me something useful, even with linux-image-debug-`uname -r` installed
<apw> cjwatson, mvo, thanks for the info
<apw> mvo sound like a bit of a mare
<mvo> apw: btw, do you plan to merge kexec-tools? or should I do it? its something that the linux-crashfile stuff needs too
<mvo> apw: it is :) its my first contact with the spec and I already feel like making more tea is required to cope
<apw> mvo, it isn't on my radar right now, so feel free to do it.  not something i really know how to do yet
<mok0> Hrmph, /me is annoyed -- most Debian packages I look at have sucky sucky packaging
<mvo> apw: ok, thanks
<ogra_> mvo, oh, have fun :P
<mvo> ogra_: "thanks"
<ogra_> there is no common ancestor anymore after last merge
<mvo> *wiiieee*
 * mvo mubbles that it will be all good, all good
<StevenK> And there we see mvo running for the kettle
<ogra_> lieb just rolled a new upstream, newer than debian
<ogra_> :)
<cjwatson> mvo: really, grub2's legacy update-grub script should be a copy of grub's; but since we haven't merged grub in ages there's a bit of work required to get there
<cjwatson> mvo: I have a half-completed merge on my disk
<mvo> cjwatson: thanks, so best is to just wait for this merge to be completed?
<mvo> cjwatson: there is tons of other stuff to look at before and grub1 is fine for testing, so I guess that should be fine
<cjwatson> mvo: yeah, I think so
<mvo> ok, thanks
<slangasek> asac: bug #321442> no!  there's *no reason* that network-manager should be second-guessing the file permissions - if I leak the secret by making the file world-readable, then it's already leaked, and this is no reason to not use the config info
<ubott2> Launchpad bug 321442 in network-manager ""system"-level connection doesn't start up until nm-applet is launched" [Medium,Triaged] https://launchpad.net/bugs/321442
 * ogra wonders where his indicator applet went in karmic
<ogra> ogra@osiris:~$ ps ax|grep indicator
<ogra>  4961 ?        S      0:03 /usr/lib/indicator-applet/indicator-applet --oaf-activate-iid=OAFIID:GNOME_IndicatorApplet_Factory --oaf-ior-fd=32
<ogra> its not visible on the panel ...
<alkisg> ogra, `gconftool-2  -a /apps/panel/applets/indicator_applet_screen0` ?
<ogra> nothing
<alkisg> gconftool-2  --all-dirs /apps/panel/applets ?
<alkisg> No indicator at all?
<ogra> ah, its applet_10
<alkisg> Look at the position and the right_stick value..
<ogra> panel_right_stick = false and position = 1466 seems ok to me
<alkisg> No, position is #applet
<alkisg> Not in pixels
<alkisg> So it should be somewhere betwee 5-10 or so...
<ogra> oh, since when ?
<ogra> "The position of this panel object. The position is specified by the number of pixels from the left (or top if vertical) panel edge. "
<alkisg> Ooops... looking
<ogra> thats what gconf-editor tells me
<alkisg> Well, all my applets use an index, not pixels
<ogra> i think its rather a bug in the applet code in karmic
<alkisg> Try to put the same settings as in jaunty: panel_right_stick=true, position=4
<ogra> no change
<alkisg> OK
 * alkisg is installing karmic, will see first-handed soon :)
<ogra> tedg, is there a known bug with the indicator applet not being visible ?
<ogra> (in karmic)
<tedg> ogra, Not known by me :)
<ogra> weird
<tedg> ogra, you can look at /usr/lib/indicator-applet/listen-and-print and see if it shows anyone on the bus.
<ogra> it must have vamished with one of the recent upgrades here
<ogra> just execute ?
<tgpraveen> ogra: it must be due to empathy becoming default
<tedg> ogra, Yeah, it's a listener.  If it doesn't print anything, that means no one is indicating anything.
<tgpraveen> from pidgin so maybe it is getting upgraded to support empathy
<ogra> tedg, yeah, it stays quiet
 * ogra waits for a mail 
<tedg> ogra, Okay, so no one is indicating.  So its either a evolution/pidgin/gwibber/etc. bug depending on what you expect to be indicating.
<ogra> tedg, but there is nothing in my panel either
<tedg> ogra, it should be virtually invisible unless someone is indicating something.  That's changing after the discussion at UDS, but I haven't fixed it yet :)
<ogra> shouldnt i at least have the mail envelope ?
<ogra> hmm, ok, might be evo then
<alkisg> Hi asac, ogra told me you're the nm maintainer. I'm having this bug both in Jaunty and Karmic: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/367227 - can I somehow help debugging it?
<ubott2> Launchpad bug 367227 in network-manager "network manager connection editor adding wired connections does not work" [Undecided,New]
<stgraber> pitti: Hey, did you get my mail about cups ? I talked with the Debian maintainer for LTSP and he says that the future would be appreciated by his users too.
<pitti> stgraber: I got it, just didn't find time to answer yet, sorry
<stgraber> np
<ScottK> mterry: When you're around I have a comment on the syslog migration spec ....
<mterry> ScottK: OK, shoot!
<ScottK> mterry: There were a couple of packages that had package specific functionality to support starting chrooted in the old sysklogd package.  Are you migrating those too?
<ScottK> I added stuff for unbound and I think ltsp had something too.
<ScottK> I didn't see it mentioned in the spec, so I thought I'd ask.
<mterry> ScottK: The spec talks about that -- says it's out of scope for the spec, but an email should be sent saying how to do it in rsyslog
<mterry> ScottK: Under "Other packages"
<mterry> ScottK: Unless I'm misreading you
<ScottK> mterry: OK.  I missed that.  It seems to me it's a regression not to migrate that stuff.
<mterry> ScottK: Yeah, migration would be good.  I just think we wanted to consider it not a blocker
<ScottK> mterry: I just re-read that bit.  You are misreading me I think.
<ScottK> These are Ubuntu unique bits that are in the ksyslogd package.
<ScottK> It's stuff to help other packages, but shipped in our default syslog.
 * mterry looks a bit more
<mterry> ScottK: No, I think I'm still reading you right.  For example, with unbound, you can now instead drop a config file in /etc/rsyslog.d that contains a line like "$AddUnixListenSocket /var/lib/unbound/dev/log".  This would be done in unbound pkg, not rsyslog
<ScottK> mterry: In sysklogd there's also an update to the rc script needed.  Is such a thing not needed with rsyslog?
<mterry> ScottK: No, the default config file includes all files in /etc/rsyslog.d that end in '.conf'
<ScottK> OK.
<ScottK> So it looks like I have to install the package specific conf file and then restart rsyslog
<mterry> ScottK: postfix has an example of doing just that -- adding a socket
<mterry> ScottK: Uh, yeah, sounds right
<ScottK> mterry: Thanks.  I'll look at that.
<ScottK> stgraber: ^^^ affects you too for ltsp I believe.
<lool> cjwatson: Hey, I'd like to push that sudo patch for /etc/environment parsing; are you ok with this?
<cjwatson> lool: I haven't had time to review it, I'm afraid, but go for it
<lool> Ok, thanks
<stgraber> ScottK: I'll need to check, AFAIK the only thing LTSP does with syslog is redirecting everything to a remote syslog server (usually on the LTSP server) so I'll need to check what happens to the config file for that
<ScottK> stgraber: I didn't look into details, just that you had some package specific magic that would need to be considered.
<ogra> stgraber, no, it doesnt
<ogra> stgraber, by default ltsp doesnt log at all
<stgraber> ogra: right, but the only use we have for syslog is to do remote logging right ?
<ogra> but the syslog initscript has an override so you can put ltsp specific defaults into /etc/ltsp
<stgraber> ah, that I didn't know :) will need to look at that then
<ogra> thats the only change thats applied to syslog related to ltsp
<ogra> but not overly important to keep imho
<stgraber> thought we only generated a syslog.conf, didn't know we had a patch on syslog
<ogra> we dont touch syslog.conf
<ogra> its a conffile :)
<ogra> # allow ltsp to override
<ogra> test ! -r /etc/ltsp/syslogd || . /etc/ltsp/syslogd
<ogra> thats the patch
<ogra> meh, wheer is my approx initscript gone
<ogra> *where
<ogra> argh
<ogra> * Change approx to run under inetd (closes: #517217, #479493)
<ogra> how silly
<ScottK> mterry: In the postfix example, how does rsyslog get restarted?
<mterry> ScottK: Let me see.  Maybe it doesn't
 * ScottK eyeballs lamont.
<mok0> Requesting a give-back on gdal for arch armel https://edge.launchpad.net/ubuntu/+source/gdal/1.5.4-4/+build/1051957
<ScottK> mok0: I'll do it.
<mok0> ScottK, thanks a lot
<mterry> ScottK: Yeah, don't think it does.  Comment in .conf file says "when rsyslog is restarted."  Probably should restart
<ScottK> mok0: It's already retried.  Also since it's in Universe you could do it yourself.
<mok0> ScottK, Hm, I don't have the link to rebuild...
<ScottK> mok0: It's already needs-building.
<mok0> ScottK, ah,  that's why, I see
<mok0> ScottK, thx
<lamont> ScottK: I was just acking the debian NMU
<ScottK> No problem.
<ScottK> lamont: OK.  Well if I understand it right, rsyslog won't know about the socket until after it's restarted.  That doesn't seem right to me.
<ScottK> Install package and some indeterminate time later logging works ....
<ScottK> mterry: What's the preferred solution here?
<mterry> ScottK: It should be harmless to restart rsyslog.  I've never done that before (restart a service when installing a different package), so I'm not clear on most-recommended way of doing it
<mterry> ScottK: But seems like it's worth doing
<ScottK> mterry: OK.  I think it's reasonable as part of the "Other packages" part of the spec for the spec to recommend the appropriate solution.
<ScottK> I'll implement it for unbound and (if lamont doesn't first) postfix, but I'd like to be following a standard approach.
<mterry> ScottK: Agreed.  I was going to work on that section when it came time to send the email out
<ScottK> mterry: OK.  What's your timeline for that?
<lool> libsgutils1 and 2 recommend sg3-utils since dapper with no rationale; I see sg3-utils only contains doc and binaries and libsgutil* don't reference any exec symbols, so it seems like this dep could be dropped and we could save space on the CD; any reason not to demote it?
<mterry> ScottK: Wanted to get my changes committed at least.  But they don't affect this part of rsyslog.  No reason it can't be done sooner rather than later.  I'll look at it
<ScottK> mterry: Thanks.
<mterry> ScottK: Certainly could do it this week
 * ScottK sits back and waits for the mail.
<mterry> :)
<cjwatson> or you could have rsyslog use inotify for its configuration directory
<mterry> True, but I'd rather not patch it like that if possible
<ScottK> It might be simpler and more reliable that making every package that uses a chroot restart syslog.
 * ScottK resumes sitting.
<cjwatson> mterry: I meant ask upstream for that feature :)
<mterry> cjwatson: Yar
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> pitti, about bug 382379
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix committed] https://launchpad.net/bugs/382379
<tkamppeter> pitti, I have found a problem in my fix in Poppler. Duplex does not work any more with it. I ahve fixed it already and I am adding debdiffs for Karmic and Jaunty to the bug. Can you upload the new package versions as soon as the debdiffs are there? Thanks.
<pitti> tkamppeter: can do
<mterry> ScottK: https://wiki.ubuntu.com/FoundationsTeam/Specs/Rsyslogd#Other%20packages has example code now.  Not quite ready to send out email, but there ya go if you're anxious
 * ScottK looks
<ScottK> mterry: Wouldn't that be on purge, not remove?
<ScottK> (for the postrm)
<mterry> ScottK: Yes!  duh
<mterry> ScottK: fixed
<ScottK> Great.
<mterry> ScottK: And I suppose, if you were feeling very fancy, the postinst restart would be only run when the package changes the config file...
<tkamppeter> pitti, Karmic debdiff is ready.
<ogra> hmm, using grub2 to boot from SD makes it hang for about 5minutes
<ogra> on the same HW booting from hdd works as expected
<tkamppeter> pitti, Jaunty debdiff is in place.
<pitti> tkamppeter: can you please send the updated patch to upstream/Debian BTS as well, to avoid them uploading broken packages?
<tkamppeter> pitti, I have already sent the patch to upstream: https://bugs.freedesktop.org/show_bug.cgi?id=19777
<ubottu> Freedesktop bug 19777 in general "pdftops command line utility does not convert multiple-page-size documents correctly" [Normal,Reopened]
<pitti> tkamppeter: cool, thanks; jaunty and karmic uploaded
<tkamppeter> pitti, the Karmic task is now "Fix Released", the Jaunty package is in the Approval queue.
<pitti> tkamppeter: processed
<alkisg> Hi asac, ogra told me you're the nm maintainer. I'm having this bug both in Jaunty and Karmic: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/367227 - can I somehow help debugging it?
<ubottu> Ubuntu bug 367227 in network-manager "network manager connection editor adding wired connections does not work" [Undecided,New]
<tkamppeter> pitti, thank you very much.
<tkamppeter> pitti, Debian bug 530731 is also updated now.
<ubottu> Debian bug 530731 in poppler "Please update Poppler to 0.11.0 in unstable" [Unknown,Open] http://bugs.debian.org/530731
<ogra> tedg, oh ... Jun 22 18:00:01 osiris dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.59" (uid=1000 pid=4961 comm="/usr/lib/indicator-applet/indicator-applet --oaf-a") interface="org.freedesktop.DBus.Properties"
<ogra> tedg, thats why i dont get any indications since i upgraded to karmic
<ogra> (from auth.log)
<karmictest2> hello there
<karmictest2> i have found a small bug, ( i am not an technical person, but try to convey it any way ) , and am trying to track it down
<karmictest2> its the devkit deamon that keeps on polling and trying to mount a floppy drive..
<ogra> known
<karmictest2> and makes an terrible noise doing it..
<karmictest2> like its killing the thing, this is on karmic 2
<ogra> bug 384469
<karmictest2> fresh install
<ubottu> Launchpad bug 384469 in devicekit-disks "constantly polls floppy drive" [Medium,Fix committed] https://launchpad.net/bugs/384469
<karmictest2> yes thats the one, now i try to find an nice solution, here is the same bug that fedora users run into :
<karmictest2> https://bugzilla.redhat.com/show_bug.cgi?id=489083
<ubottu> bugzilla.redhat.com bug 489083 in DeviceKit-disks "devkit-disk tortures my good old floppy drive" [Medium,New]
<ogra> well, there is a workaround posted in the LP bug
<karmictest2> yes i just posted the work around
<ogra> devkit-disks --inhibit-polling /dev/fd0 &
<ogra> but as you can see its fixed upstream already
<karmictest2> that was my next question...
<ogra> so it will show up with the next update of the package
<ogra> https://bugs.freedesktop.org/show_bug.cgi?id=22149 is the upstream bug (as you can see on the launchpad bug)
<karmictest2> its upstream meaning its not in the updates yet?
<ubottu> Freedesktop bug 22149 in detection "Do not poll floppy drives" [Normal,Resolved: fixed]
<karmictest2> ok, very good, i lay my head at rest... :)
<ogra> the ubuntu task is in "fix committed" status
<ogra> so its in the bzr branch already, just not uploaded yet
<karmictest2> thanks for your time, and good directing, its sure to be fixed in the next cycle of release, so ok, good!
<ogra> but will show up with the next upload of the devicekit-disks package
<karmictest2> :)
<ogra> should be fixed within the next days ... whenever pitti finds the time ;)
<karmictest2> hmm, great, great!
<karmictest2> ok, going to do the dishes, yes this too has to be done...
<karmictest2> :P
<karmictest2> bye
 * karmictest2 doing dishes
<pitti> karmictest2: it's known/fixed upstream
<pitti> karmictest2: and I uploaded the latest devkit-disks into https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa today
<pitti> karmictest2: so, if you want to test that, appreciated
 * pitti eyes 'New "libc" project libposix started' -- YALI?
<tedg> ogra, no that's an error because of (in my opinion) is a misconfig of DBus System bus.  It shouldn't effect things on the session bus though.
<ScottK> pitti: Ought to be done is a few weeks, so we can switch for Karmic, right?
<ogra> hmm, k
<ScottK> ;-)
<ogra> ScottK, only if you promise to backport it to jaunty and intrepid too
<ScottK> If it gets into Karmic, I'll be glad to backport it.
<directhex> nothing says "eligible for backports" like a new libc
<karmictest2> pitti : this package https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa/+files/devicekit-disks_005-0ubuntu1~ppa2_i386.deb , right?
<karmictest2> hmm
<karmictest2> its not that easy, seems to need : libpolkit-backend-1-0
<pitti> karmictest2: right, you need the entire PPA
<pitti> it has a load of dependencies
<karmictest2> ah...
<pitti> karmictest2: and conversely, I suppose you need the new libgdu* bits as wel
<pitti> karmictest2: this is just a staging area for what will go into karmic in the next time anyway, so feel free to just dist-upgrade with the ppa
<pitti> all the versions are running on my machine, and it's not very broken
<karmictest2> sure
<pitti> some minor bits, like "doesn't remember privileges within the session", but nothing serious
<karmictest2> i dont mind breaking it,
<karmictest2> its an full install for testing , so nproblem
<karmictest2> seems to depend on : libpolkit-gobject-1-0
<karmictest2> libpolkit-backend-1-0
<karmictest2> pitti , did no go well, the installation spits out an error about Package status and progres file descriptor , that it could not read...
<karmictest2> ok
<karmictest2> better now
<karmictest2> installed from synaptic
<karmictest2> going for the reboot, to see if it is fixed...
<karmictest2> pitti , yes it is fixed now
<pitti> karmictest2: thanks \o/
<bryce> pitti, thanks for copying the -intel bits into jaunty
<pitti> bryce: I'm glad that we can (hopefully) close this chapter now :)
<karmictest2> pitti , shall i add the fix to the bugtracker?..
<karmictest2> like this : This bug will be fixed in the next release, but you can do this :
<karmictest2> add to your repositories :
<karmictest2> deb http://ppa.launchpad.net/ubuntu-desktop/ppa/ubuntu karmic main
<karmictest2> then install the package :  devicekit ( search with synaptic ) and install any dependecies as well, reboot , fixed....
<pitti> karmictest2: sure, if you want
<karmictest2> ok..
<pitti> good night everyone
<karmictest2> night , and thanks
<karmictest2> :)\
<karmictest2> ok bye
<janisozaur> do the -dbg packages provide profiling information?
<joaopinto> janisozaur, no, they provide debug information
<tjaalton> joaopinto, janisozaur: the profiler tools need debugging symbols, so yes
<joaopinto> hum, debugging symbols does not mean profiling information :)
<janisozaur> tjaalton, according to http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html (for gnu gprof) they require additional info to just -g, as in -pg
<janisozaur> tjaalton, but your statement is of course correct, they *need* debugging symbols, just it's not  enough
<tjaalton> ok
<janisozaur> actually it kind of makes sense - as compiling an app for profiling generates lots of output into a file and all the additional calls to handle that make an app run slower, so it would be useless for day-to-day use after installing -dbg
<NCommander> Is the wiki lagging for anyone else?
<janisozaur> it's fine here (PL)
<magcius> Is Canonical planning to do anything with freedesktop.org's projects, like PackageKit, ConsoleKit, DeviceKit, PolicyKit?
<tgpraveen1> magcius: devicekit,policykit
<tgpraveen1> are used in ubuntu
<tgpraveen1> already
<magcius> DeviceKit is used?
<magcius> PolicyKit isn't used nearly at all... I can only think of a couple applications that use them.
<tgpraveen1> magcius: devicekit will be actively used from karmic
<Riddell> kees: poke on bug 374973
<ubottu> Launchpad bug 374973 in enca "main inclusion report enca" [Undecided,New] https://launchpad.net/bugs/374973
<NCommander> directhex, ping, is there known issues with mono on ARM?
<wjblack> Hello!
<wjblack> I recently backported the r8169 driver from 2.6.30 to 2.6.28 (big missing interrupt fix) and was wondering what the "blessed" way to make a package of just this driver is.  I've made .debs before and am interested in possibly doing a PPA.  Anyone have a doc link handy (I couldn't find anything terribly obvious)?
<wjblack> ...or am I better off asking in #ubuntu-kernel?
<kees> Riddell: thanks for the reminder!
<kees> Riddell: approved and noted.
<andrew_sayers> wjblack: I worked out how to put packages in a PPA by reading through the Ubuntu Packaging Guide (https://wiki.ubuntu.com/PackagingGuide).  It's probably not the quickest solution, and I'm probably not the best person to ask, but it worked for me.
<andrew_sayers> (and scraps from half a dozen other places, IIRC)
<wjblack> Okie-dokie.  That's a start.  (Was looking for a pointer more than a handout anyway ;-) ).
<wjblack> I suppose the whole "How do I package?" question is nearly orthogonal to the "what should I call it?" question, too.  Perhaps the latter is a question best suited for the kernel folks.
 * wjblack joins another channel :-)
<statik> jdstrand: i just got your message regarding python-testtools, thanks and sorry for the trouble. I'll look at fixing that now. It was uploaded by a sponsor via the REVU queue, so whats the right process to go about getting a new upload - go through REVU again with an explanation of what happened, or contact the last sponsor directly?
<jdstrand> statik: np. it isn't clear based on https://wiki.ubuntu.com/MOTU/Packages/REVU, but I would talk to the upload sponsor. I wouldn't think just adding the LICENSE would constitute it having to be rereviewed by everyone
<ScottK> statik: Usually after an archive admin rejection you just need one MOTU to re-ack and upload.
<statik> scottK: thanks!
<magcius> tgpraveen1, what about PackageKit and ConsoleKit?
<tgpraveen1> magcius: package kit is mostly not going to be used
<magcius> tgpraveen1, why not?
<tgpraveen1> not sure about console kit
<tgpraveen1> magcius: go to karmic koala section of ubuntu forums there is a thread named package kit thread
<tgpraveen1> with a LOOONG discussion
<tgpraveen1> magcius: and this # is not best for this type of discussion
<magcius> tgpraveen1, would #ayatana be better for this?
<tgpraveen1> magcius: no that # is for usability and design team and all.
<tgpraveen1> magcius: maybe #ubuntu / #ubuntu+1
<tgpraveen1> also use the forum for that post that I mentioned
<magcius> tgpraveen1, I'm trying to find it.
<magcius> Ah, found it.
<magcius> tgpraveen1, I would think it would be a dream for developers not to have to worry about packaging systems and things like this, and have PackageKit abstract the entire thing.
<magcius> What's the primary motivation for Ubuntu *NOT* to adopt it? I haven't seen one in the thread.
<ScottK> magcius: Magical theoretical package systems don't usually pan out in real life.
<ScottK> Since virtually no developers inhabit the forums, forums threads are generally a good source of developer opinions on stuff.
<magcius> PackageKit is far from "magical"
<magcius> And it's not even a package system.
<magcius> It's an API that abstracts the interface to the lower-level package management system.
<ScottK> Right which is why it's completely orthogonal to not having to worry about packaging
<magcius> What do you mean?
<ScottK> I mean "Use packagekit" doesn't mean "developers don't have to worry about packaging systems"
<ScottK> Also packagekit does not completely abstract the Debian system anyway.
<ScottK> We switched to using KPackageKit in Kubuntu and are missing features as a result.
<magcius> Hmmph.
<magcius> What about ConsoleKit?
<ScottK> magcius: One example is we don't have a way to let users know about configuration file conflicts and resolve them.
 * ScottK knows less about that.
<magcius> ScottK, shouldn't it be the apps'
<magcius> app's job to handle migration?
<ScottK> magcius: No.  It's the package's job.  The app may not even be running when the upgrade happens.
<magcius> Yeah... an app breaking backwards-compatibility with old configuration files and not migrating them is not the sign of a good app.
<ScottK> In Debian/Ubuntu it's the package manager's job.
<magcius> Most users don't see or want to see configuration files... how can you expect them to know how to merge conflicts?
<ScottK> That was the argument for moving to kpackagekit.
<ScottK> It's a regression from what we had before.
<magcius> Can't Canonical work on the front-ends?
<magcius> I know gnome-package-kit sucks, but aren't Red Hat and Canonical working on that?
<ScottK> If one wants to arbitrarily redefine package management to be what packagekit supports, then it's great.
 * ScottK has no idea.
<magcius> Canonical's position of this one huge AppCenter makes less sense to me.
<magcius> It's like they want to ignore standards and proprietarize the Linux app market.
<ScottK> packagekit also lacks the ability to let the user select from different ways to resolve dependencies.
<magcius> ScottK, I have never needed to select that. Ever.
 * ScottK has.
 * Sarvatt has too, MANY times
<magcius> ScottK, isn't it fairly easy to resolve dependencies?
<ScottK> Usually
<magcius> Just look at the Depends metadata, and traverse down each package, hoping nothing will conflict.
<ScottK> It's what happens when hope fails that gets complex.
<ScottK> Have a look at Aptitude's dependency resovler code for some idea how complex.
<magcius> What about smart?
<magcius> PackageKit can be used on top of smart.
<Sarvatt> packagekit-gnome is in the repos now, whats the problem?
<magcius> Sarvatt, yeah, but it doesn't provide the integration like Fedora has.
<magcius> And it's also the outdated 0.3 branch
<magcius> Sarvatt, http://fedoraproject.org/wiki/Features/AutoFontsAndMimeInstaller
<Sarvatt> speaking of which, are there any plans to package polkit-gobject alot of things are starting to need?
<magcius> I would love to see PolicyKit be used instead of gksu/gksudo :(
<ScottK> That's a goal for Ubuntu for Karmic
<magcius> Are they going to provide patches to GNOME upstream or patch downstream?
<magcius> How far along is Karmic right now?
<evanrmurphy> magcius: Here's the Karmic release schedule: https://wiki.ubuntu.com/KarmicReleaseSchedule
<ScottK> slangasek: Are you doing archive stuff today?
<magcius> Also... would the broken hibernate be considered a papercut?
<evanrmurphy> magcius: IMO hibernate would be nontrivial to fix, so I don't think it's a papercut. But it's certainly a serious bug.
<magcius> evanrmurphy, do you know what the cause is?
<magcius> Also... is Upstart still a dream or is there actually some concrete progress?
<evanrmurphy> magcius: Unfortunately I'm not certain, but my impression is it has to do with the headaches of interfacing with hardware. Perhaps less-than-great drivers are a contributing factor... anyone else wanna chime in here?
<magcius> evanrmurphy, supposedly people have fixed it with s2disk and s2ram
<magcius> ScottK, #gnome says that GNOME has used PolicyKit for some time now (for the Administration menu items), and that Debian is patching it.
 * ScottK is a KDE guy, so doesn't really keep track.
<jpds> magcius: Yes, we use PolicyKit for some bits and pieces, don't know the details myself.
<magcius> jpds, #gnome said that Debian was the one that did the integration with gksu/gksudo, and that GNOME has had a dependency on PolicyKit for some time now.
<onexused> I see there are screenshots for some programs in synaptic, but not all.  Where could I contribute screenshots for the programs that I use? (Is this the correct place to ask?)
<mathiaz> kees: should a MIR for mysql-dfsg-5.1 be written in order to move 5.1 to main and 5.0 to universe?
<kees> mathiaz: yes, with coverage of why we're using 5.1 instead of maria, to maybe?
<mathiaz> kees: you mean mariadb?
<mathiaz> kees: AFAICT there isn't mariadb package available
<kees> mathiaz: ah, dang.  should poke mneptok about it
<ajmitch> how mature is that now?
<kees> no idea
<ajmitch> website says a release of mariadb 5.1 in august, at least
<mathiaz> ajmitch: right
<kees> *snore*
<mathiaz> ajmitch: maria is basically the maria storage engine with some community patches that have been around for some time and that haven't been integrated in mysql yet
<mathiaz> ajmitch: some of the community patches are probably the ones from percona
<mathiaz> ajmitch: the thing is that I haven't seen any debian packages
<ajmitch> probably because the debian mysql maintainer has been fairly overloaded
<mathiaz> ajmitch: yeah - totally - norbert is doing an amazing job as he is the only one actively maintaining mysql packages
<mathiaz> ajmitch: 5.1 is available from experimental
<ajmitch> yeah, I've got it installed here on a sid install
<mathiaz> and I think we should move 5.1 to main for the next LTS
<ajmitch> since we use mysql a lot at work
<mathiaz> otherwise kees is going to cry for the next 5 years
<mathiaz> ajmitch: are you using 5.0 or 5.1?
<ajmitch> 5.0 for production, on lenny at the moment
<mathiaz> kees: should I write up a MIR for 5.1 before uploading the new 5.1 package that will do the switch to the archive?
<mrooney> pitti: if an mp3 player is missing from the hal list of audio devices, should a bug go against hal or devicekit, or somewhere up stream?
<ajmitch> mathiaz: I'll take a quick look at getting some mariadb packages working, I'd like to try it out & see how it goes
<mathiaz> ajmitch: awesome - thanks.
<mathiaz> ajmitch: once you get something working, let mneptok know about it
<mathiaz> ajmitch: he should greatly appreciate it
<directhex> NCommander, current issues: nothing worth noting. with the 2.4+dfsg-4 upload, we now include unit testing as part of the build, so we have an easy way to notice arch issues. older arches may contain bugs, but in the absence of test kit, hard for us as packagers to isolate
<NCommander> directhex, yeah, I discovered for some reason my board didn't upgrade with dist-upgrade, so karmic is ok, but jaunty/mono is very very hosed
<directhex> NCommander, hosed at what point - runtime? compile? app execution? etc
<directhex> NCommander, best bet is to quiz vargaz on #mono on gimpnet - if anyone can think of specific commits relating to specific runtime problems, it's him
<NCommander> directhex, runtime
<NCommander> directhex, care to introduce me?
<NCommander> directhex, he responded BTW
#ubuntu-devel 2009-06-23
<mathiaz> Riddell: do you still need a mysql-server-core-5.1 for akonadi?
<mathiaz> Riddell: IIRC mysql-server-core-5.0 was introduced to support akonadi
<djsiegel1> pitti: check it out: https://edge.launchpad.net/hundredpapercuts/karmic
<torkiano> hello, I'd like to request the package of a new version of autotools (1.11)
<torkiano> How is the process? The same as new packages?
<torkiano> The problem is that version of autotools is not in debian
<torkiano> 1.11 is important because a very usefull macro: AM_SILENT_RULES
<torkiano> more info: http://bugzilla.gnome.org/show_bug.cgi?id=580062 and  http://live.gnome.org/GnomeGoals/NicerBuilds
<ubottu> Gnome bug 580062 in general "Add shave support to gnome-common" [Normal,Unconfirmed]
<torkiano> Do you know a PPA with automake1.11 ?
<ianloic> hey, quick Q
<ianloic> I've done some deb packaging before but I can't work out how to make a *_source.changes for uploading to a PPA
<ianloic> I can easily get my *_i386.changes
<ianloic> nm, worked it out
<ScottK> ianloic: PPA question are best in #launchpad.
<ianloic> ScottK: ok, I'll go over there
<wjblack> Hi all!  I think I have my nifty new PPA set up correctly, but keep getting "Could not find PPA named 'r8169-2.6.30-backport' for 'bblack'".  I've tried various other iterations of the PPA name and userid with no luck.  Every invocation of dput seems to succeed.  And I'm stuck.  Anyone have an idea of where I might've gone wrong?
<TheMuso> /c/c
<ScottK> wjblack: PPA questions are best asked in #launchpad.
<wjblack> Okie-dokie.  Thanks!
<candrews> https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/277556
<ubottu> Ubuntu bug 277556 in open-vm-tools "should build kernel modules with dkms" [Undecided,Confirmed]
<candrews> the bug contains a new version of open-vm-tools
<candrews> Unlike the version currently in Jaunty or Karmic, this version compiles and works.
<candrews> And it introduces dkms support, which makes using open-vm-tools much easier.
<candrews> The package needs a sponsor to upload to karmic... any takers?
<pitti> Good morning
<\sh> guten morgen pitti :)
<pitti> djsiegel1: great work!
<pitti> hey \sh, wie gehts?
<\sh> pitti: regarding the time of the day...I'm fine :)
<\sh> http://www.infoq.com/presentations/katz-couchdb-and-me <- very nice talk about why someone would work on something cool and why someone would spend his/her savings to work on FOSS
<mneptok> pitti: morgen
<pitti> hey mneptok!
<StevenK> Morning pitti
<mneptok> pitti: greetings from Finland :)
<pitti> mneptok: taking revenge on Linus?
<StevenK> pitti: Do you have time to source NEW something I'm planning to upload in about an hour? It's a little meta package.
<pitti> StevenK: sure
<mneptok> pitti: that depends on when i can connect with liw ;)
<StevenK> pitti: mobile-meta is exploding out to mobile-meta and unr-meta
<StevenK> mneptok: Haha
 * mneptok is hoping to go to Helsinki tomorrow for lunch
<mneptok> now is breakfast with a crazy Trukish German from Stuttgart
<mneptok> *Turkish
<\sh> gnarf...if developer_brain is None: print("Please ask SysAdmin...they know what to do and how to do your job")
<dholbach> good morning
<\sh> pitti: back to your question: My mood just changed from "what a wonderful day" to "I have to go home, fast"...
<pitti> \sh: children are so demanding :)
<\sh> pitti: children are not the problem...our developers are
<amitk> so how does one update the readahead list on an upgraded system?
<\sh> and they are really demanding...especially when they screwed up
<\sh> brb coffee and some other drugs
 * dholbach does some sponsoring and takes a look at bluez-gnome and glade-3
<Chipzz> \sh: mv developer killfile :P
<\sh> Chipzz: cluebat -> dev head -> works
<Chipzz> \sh: first cluebat, then killfile in that case :)
<mneptok> dev | beer > bed
 * dholbach takes a look at cpio and gimp too
 * dholbach takes a look at newt and pyopenssl too
 * dholbach takes a look at libsepol too
<alkisg> asac: Hi, ogra told me you're the nm maintainer. I'm having this bug in the default alternate cd/LTSP installation both in Jaunty and Karmic: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/367227 - can I somehow help debugging it?
<ubottu> Ubuntu bug 367227 in network-manager "network manager connection editor adding wired connections does not work" [Undecided,New]
<robert_ancell> Does anyone know why I get a "readonly transport" error when following the instructions to add me to Planet Ubuntu? https://wiki.ubuntu.com/PlanetUbuntu
<RAOF__> robert_ancell: Because you haven't run 'bzr launchpad-login $YOUR_LP_NICK', and so lp: branches are resolved as http:// rather than bzr+ssh://?
<slangasek> ScottK: out of town on a sprint, so I'm afraid I wasn't really able to
<robert_ancell> RAOF__: Didn't help. All my other branches work fine
<robert_ancell> Full error: bzr: ERROR: Cannot lock LockDir(lp-140615476490448:///~planet-ubuntu/config/main/.bzr/branchlock): Transport operation not possible: readonly transport
<dholbach> robert_ancell: bzr break-lock lp-140615476490448:///~planet-ubuntu/config/main/.bzr/branchlock
<tkamppeter> seb128, hi
<robert_ancell> bzr: ERROR: Unsupported protocol for url "lp-140615476490448:///~planet-ubuntu/config/main/.bzr/branchlock"
<dholbach> hum
<dholbach> just "bzr break-lock"?
<tkamppeter> seb128: In the last days a new patch for evince was attached to bug 258421.
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,Fix released] https://launchpad.net/bugs/258421
<robert_ancell> dholbach: break-lock completed but didn't print anything.  Retrying the commit still not working :(
<seb128> tkamppeter, hi, I noticed, I'm waiting for upstream comments
<dholbach> robert_ancell: does it give you another URL for it?
<dholbach> robert_ancell: which branch did you check out?
<tkamppeter> seb128: I have tested it and it works perfectly.
<robert_ancell> I checked out what the Wiki page linked to: bzr+ssh://bazaar.launchpad.net/%7Eplanet-ubuntu/config/main/
<seb128> tkamppeter, noted
<dholbach> robert_ancell: you're not in ~ubuntumembers that's probably why you can't write to it
<robert_ancell> dholbach: Aha, another group :)  How do I get into that?
<dholbach> https://wiki.ubuntu.com/Membership
<dholbach> could it be that mono is somehow broken in karmic right now?
<RAOF> dholbach: Seems to be working here?
<directhex> some stuff is in NEW afaik
<dholbach> ah ok
<dholbach> I'm in the middle of some kind of transition then
<dholbach> (on amd64 if that's relevant)
<dholbach> oh well
<directhex> or was
<RAOF> I think that's finished?  My mono stack updated today; previously it was held up by packages in NEW.
<directhex> slow mirror?
<dholbach> it wants to remove mono-common and mono-jit here, not sure if that's correct :)
<directhex> dholbach, yes, that's correct
<directhex> dholbach, there's been some unsplitting in cases where it served no purpose. and moar splitting in other places to make up for it
<Hobbsee> come on karmic graphics.  it's time to freeze like you usually do.
<Hobbsee> No murphy's law today, please!
<NCommander> Hobbsee, murphy was an optimist
<Hobbsee> NCommander: yeah, well
<NCommander> Hobbsee, of course, Finagle made him pale in comparsion
<seb128> how often is merges.ubuntu.com updated?
<directhex> dholbach, should be a performance bump in karmic mono fwiw, and a good <=25% ram consumption drop in apps
<seb128> slangasek, did you run an autosync yesterday?
<slangasek> seb128: no
<seb128> slangasek, ok thanks, I will do one then ;-)
<slangasek> yes, please :)
<geser> seb128: could you please also sync new packages from Debian? thanks
<seb128> geser, will do
<asac> alkisg: if you have eth0 configured in /etc/network/interfaces, this means that NM will not manage that device (by default). So its a feature from what I can tell.
<alkisg> asac: yes, that's fine. The problem is that I can't create system connections for the other NIC, eth1
<alkisg> Or, better, I *can* create system connections (I can see them in /etc/NetworkManager/system-connections), but they're not displayed in nm-connection-editor.
<alkisg> So when eth0 is in /etc/network/interfaces, I can't manage eth1 with network manager and _system_ connections
<alkisg> I'm able to manage eth1 with _user_ connections (not checking the [ ] Available to all users), though.
<alkisg> I've reproduced it in 4 out of 4 test installations in Jaunty and Karmic
<alkisg> asac: so, if I can send anything to help debug it, please tell me to.
<asac> alkisg: please file a separate bug using ubuntu-bug network-manager ... the reporter of your bug does not have any eth1 or so
<asac> alkisg: or are you seeing the same polkit error?
<alkisg> asac: he does have eth0 and wlan0
<alkisg> It's not specific for wired interfaces, any two NICs will do, if one is in /e/n/i then NM can't manage the other with system connections
<alkisg> asac: I've been seeing three or four different error messages because of this. Yes, polkit was one of them.
<asac> alkisg: yes, but he complaings about not beinga ble to add a wired connection
<alkisg> asac: ok, I'll file a different bug, but I think it's the same one.
<alkisg> Thanks :)
<asac> alkisg: we can dupe it then
<asac> alkisg: gimme the bug id when you have it
<alkisg> asac: Do you prefer that I do it from a Karmic PC experiencing the problem, or a Jaunty one?
<alkisg> (vbox)
<asac> alkisg: please do it on the same system where you experience the problem
<alkisg> (or I can use my real jaunty laptop with eth0 and wlan0)
<asac> alkisg: if you see it on jaunty thats ok too
<alkisg> asac: ok, reporting now... (I think it was present since at least hardy)
<asac> hardy didnt have 0.7. so that would be odd
<alkisg> Yes, I think it was there in 0.6
<ogra> could that be related to the "permissions on /etc/NetworkManager/system-connections/" bug ?
<alkisg> ogra, I tried chmod'ing the connections to 777, they still didn't show up
<ogra> ah, k
<alkisg> asac, ogra: 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" [Undecided,New]
<asac> alkisg: thanks
<asac> alkisg: how did you configure your system connection? you get quite a few errors
<asac> Invalid Setting ... and so on.
<sjokkis> hi. any of you know what the timeline on getting plymouth into ubuntu is?
<bigon> dholbach, I've posted a new patch for bug #388590
<ubottu> Launchpad bug 388590 in empathy "Update empathy to 2.27.3" [Wishlist,In progress] https://launchpad.net/bugs/388590
<slangasek> kirkland: do you recall if putting the service manpage in section 8, but the binary in /usr/bin, was an explicit decision?
<slangasek> kirkland: normally the mapping is bin -> 1, sbin -> 8; I think the util probably belongs in /usr/sbin
<alkisg> asac: The "Invalid Setting" is displayed every time I press a digit or letter in the dns server box. So, for 10.160.31.1 it's displayed 10 times... No big deal there, I guess a validation function is called "on keypress" instead of "on exit"...
<alkisg> (possibly for the "Apply" button to be automatically enabled)
<lifeless> pitti: bug 391015 - could you read the last 3-4 comments there.
<ubottu> Launchpad bug 391015 in bzr "apport package hook for Bazaar" [Wishlist,New] https://launchpad.net/bugs/391015
<kblin> hi folks
<kblin> what's the most appropriate channel to discuss missing packages?
<slangasek> ... missing?
<slangasek> as in, software that's not yet packaged?
<kblin> ubuntu has libwbclient, but not libwbclient-dev
<kblin> if you're trying to develop against libwbclient, that's kind of sucky :)
<slangasek> kblin: oh, that's easy; #samba-technical, tell bubulle what you want in it. ;)
<kblin> fair enough
<slangasek> I wasn't aware there were any public headers available for wbclient
<kblin> slangasek: "it's a debian issue"?
<kblin> slangasek: well, libwbclient.h is the public one
<kblin> wbclient.h is the internal one
<kblin> of course I can easily fix this locally
<kblin> just wanted to check who to complain at.. :)
<pitti> lifeless: done
<lifeless> danke
<ogra> cjwatson, i get strange xauth messages with a ssh -X login in karmic, is that on purpose ?
<ogra> /usr/bin/X11/xauth:  creating new authority file /home/ogra/.Xauthority
<ogra> /usr/bin/X11/xauth:  unable to link authority file /home/ogra/.Xauthority, use /home/ogra/.Xauthority-n
<cjwatson> ogra: err, no idea, I don't believe that ssh has changed in any relevant way
<cjwatson> ogra: you sure you don't have ~/.Xauthority owned by root, or something?
<ogra> i have an ubuntu-desktop session running on that machine ... one sec
<ogra> ok, ignore me :P
<ogra> ogra@babbage2:~$ ls -lh .Xauthority
<ogra> ls: cannot access .Xauthority: Stale NFS file handle
<ogra> not properly unmounting Sd cards is evil
<ogra> at least if you run the whole system from it
<ogra> though that error annoys me since a while ... should be more informative
 * ogra tries to find where that text comes from to file a bug
<slangasek> kblin: there's no reason to diverge from Debian on this, and we'll happily pick up the fix from Debian - so it's simplest to just fix it once there, especially since bubulle has more time to work on Samba packaging than anyone else right now :)
<kblin> slangasek: sure. just kidding :)
 * ogra sighs failing to find where the text for the error is actually defined
<ogra> ah
<torkiano> Hello, reading https://blueprints.launchpad.net/ubuntu/+spec/desktop-karmic-gnome-3 I think that would be helpful for you this link: http://www.gnome.org/~fpeters/299.html
<torkiano> Can I add that link to the blueprint page?
<pitti> torkiano: it's already linked from the spec
<torkiano> pitti, oh, great, I did't see it
<torkiano> pitti, you can also link to http://live.gnome.org/GnomeGoals . There are more documentation to help cleaning, for example: http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder
<torkiano> on the other hand, I think that you can be interesed in bug #390909
<ubottu> Launchpad bug 390909 in automake "[needs-packaging] automake1.11" [Undecided,New] https://launchpad.net/bugs/390909
 * ogra files bug 391094
<ubottu> Launchpad bug 391094 in glibc "the "stale NFS file handle" error should be reworded" [Undecided,New] https://launchpad.net/bugs/391094
<ncopa> could someone please help me find the build script source for linux-headers-*-generic package?
<ncopa> want to look how they make that nice symvers, .config and symlinks to header dirs
<Pici> ncopa: Have you asked in #ubuntu-kernel?
<ncopa> thanks!
<Pici> np
<kirkland> slangasek: i don't think it was conscious
<kirkland> slangasek: fwiw, f11 has /sbin/service and service.8
<kirkland> slangasek: would you like me to update the package to match that?
<slangasek> kirkland: don't bother, the change is committed now to Debian so you can pick it up on merge :)
<slangasek> kirkland: fwiw, /sbin is wrong because this tool has nothing to do with system recovery :)
<kirkland> slangasek: heh
<kirkland> slangasek: k
<kirkland> slangasek: did you pick up these changes from debian?
<slangasek> I tweaked it when submitting the patch to the maintainers sitting next to me
<kirkland> slangasek: heh, cool
<slangasek> kirkland: btw, we're discussing (intermittently) extending the 'service' command to also be the authoritative runlevel editing interface; some background material here if you happen to be interested: http://lists.debian.org/debian-devel/2009/04/msg00058.html http://lists.debian.org/debian-devel/2009/04/msg00056.html
<pitti> cjwatson: BTW, does the "detect KMS" usplash change actually work for you? for me, usplash still starts in the initramfs
<kirkland> slangasek: awesome :-)
<kirkland> slangasek: any chance we'll ever support chkconfig?  :-)
 * kirkland ducks
<mdz> ara_: I checked out mago, but the tests in it seem to depend on a python module 'desktoptesting' which is not in mago or python-ldtp. where do I get it?
<pitti> cjwatson: oh, hang on, you didn't actually change that
<pitti> cjwatson: ignore me, please
<kirkland> slangasek: let me know when the dust settles and i'll merge the package
<ara_> mdz: weird, did you get the last from lp:mago ?
<slangasek> kirkland: no, because chkconfig is crazy
<slangasek> :)
<kirkland> slangasek: hehe
<slangasek> it's a goofy name, and not a very relevant interface
<ara_> mdz: it looks like a bad merge. Let me fix it
<kirkland> slangasek: did you maintain the --status-all option when you sent to debian?
<kirkland> slangasek: that was an enhancement i made on the red hat one
<slangasek> kirkland: sure - I took the Ubuntu patch, un-dpatchified it, moved the executable to the right dir, and submitted
<slangasek> kirkland: Debian bug #534300
<ubottu> Debian bug 534300 in sysvinit-utils "Please add /usr/sbin/service to sysvinit-utils" [Wishlist,Open] http://bugs.debian.org/534300
<kirkland> slangasek: it's a little flimsy since debian/ubuntu init scripts are notoriously bad at having status options :-)
<kirkland> slangasek: cool, i never did really like that it was a dpatch
<slangasek> yeah, we've run that test today :-)
<slangasek> "what's all the question marks?" "ohhhh."
<kirkland> slangasek: service --status-all 2>/dev/null
<kirkland> slangasek: i dump those to &2 so that they're easily filtered
<kirkland> slangasek: ^ is more elegant, imho
 * slangasek nods
<slangasek> well, soon enough we'll be moving everything to upstart jobs :)
<slangasek> so then we don't have to worry about implementing status commands \o/
<kirkland> slangasek: your patch -> +VERSION="`basename $0` ver. 0.91-ubuntu1"
<kirkland> slangasek: dunno if that matters to you
<kirkland> slangasek: i know you don't need my +1, but otherwise, the patch looks good, i agree with /usr/sbin/service
<andrew_sayers> evand, evand1: I've written a blueprint for the migration assistant (https://wiki.ubuntu.com/InstallProgramsFromMigrationAssistant) that I'd be willing to do some work on.  Could you have a look and tell me what you think?
<sladen> pitti: any chance of getting the update-manager whack-a-mole fix past it's 3 months awaiting SRU?  https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/369198
<ubottu> Ubuntu bug 369198 in update-notifier "update-manager auto-opened after each apt use when security updates available" [Medium,Fix committed]
<cjwatson> pitti: the point was to make it work properly when started in the initramfs, not to remove it from the initramfs :-)
<cjwatson> pitti: I expect the latter will be done later but I didn't get that far
<pitti> cjwatson: I just don't understand the change then
<cjwatson> pitti: if KMS is available, it's stupid for usplash to try to change the screen size
<pitti> right
<mvo> sladen: I just asked aobut it on #ubuntu-testing
<cjwatson> pitti: it should just use the native resolution
<mvo> sladen: it needs a sru-verficiation
<pitti> but if KMS is available, it shouldn't start at all, no?
<cjwatson> it should be able to
<cjwatson> we may not want to do that *by default* in karmic
<pitti> cjwatson: ok, I see
<ogra> pitti, there might be slow booting ARM boards that want usplash
<pitti> sladen: well, we need some people giving testing feedback
<pitti> sladen: did you test it? does it work for you?
<evand1> andrew_sayers: I'm happy to look it over and get back to you.  What's your preferred method of contact?
<ogra> (not sure we'll ever have KMS for the graphics there though, but if we have it it should work)
<cjwatson> pitti: but that isn't governed by whether you have KMS available - it's governed by whether you have dm-crypt, or whatever
<cjwatson> or a slow system, all the corner cases, blah blah blah
<andrew_sayers> evand1: How about andrew-evand@pileofstuff.org?
<andrew_sayers> evand1: And thanks :)
<ara_> mdz: done, get the latest from trunk and it should be fixed
<evand1> andrew_sayers: works for me, I'll shoot you an email as soon as I've had a chance to look it over.  I'm about to go on holiday, so unfortunately I may not be able to get back to you until next week.
<evand1> andrew_sayers: thanks for looking into it.
<andrew_sayers> evand1: no hurry... where's the best place to pull migration-assistant code from, so I can be familiarising myself while I'm waiting?
<mdz> ara_: thanks
<evand1> andrew_sayers: it's going through a rewrite at the moment.  I haven't pushed a branch yet as it's currently a bit of a mess of random bits of code.  I've documented a bit in the spec wiki page: https://wiki.ubuntu.com/MigrationAssistant/Karmic and https://wiki.ubuntu.com/MigrationAssistant/Karmic/DBusService
<evand1> I have a bit to add to that dbus page, I'll try to sort that today.
<evand1> andrew_sayers: perhaps give some thought as to how application suggestions fits in at the dbus api level
<andrew_sayers> evand1: Yeah, making it part of the normal install changes things quite a bit.  If there's a big rewrite going on, I'd be interested in getting more involved.  How about you e-mail me when you get back from holiday, and we'll talk about how I can help out?
<evand1> andrew_sayers: absolutely!  That sounds great.
<andrew_sayers> :)
<ogra> directhex, whats the mono debugger called (i knew that once but forgot)
<Laney> ogra: mdb
<ogra> ah, thanks
<paulliu> How to version a native package from Debian if I want to change it? Add "+nmu0ubuntu1"?
<mok0> paulliu: append "ubuntu1"
<paulliu> mok0: But if there are Debian NMUs, append "ubuntu1" seems get into trouble?
<mok0> paulliu: what is the full release string?
<paulliu> mok0: "1.11.1"
<paulliu> mok0: Debian NMU will be "1.11.1+nmu1" if there's NMU in the future.
<mok0> paulliu: so "1.11.1ubuntu1" ?
<paulliu> mok0: If we use "1.11.1ubuntu1", then Debian NMU will not be auto-sync.
<ogra> if you made ubuntu changes (which ubuntu1 indicates) it should not be autosynced
<mok0> Hmm
<ogra> becuse your cnahes might need a manual merge
<ogra> *changes
<mok0> exactly
<ogra> so what mok0 says is right
<paulliu> ogra: ok. I see. Thanks.
<ogra> instead of blindly autosyncing the packagfe will then automatically show up on merges.ubuntu.com
<ogra> where you can inspect it
<maxb> The important thing here is that as far as dpkg is concerned, "u" < "+", so "ubuntu1" < "+nmu1" which is as it should be
<rtg_> NCommander: do you have time to look at makedumpfile ? Its got some install problem with Karmic.
<NCommander> rtg_, on which architecture? ARM?
<rtg_> amd64
<rtg_> NCommander: I think its related to initramfs-hooks
<NCommander> rtg_, sure, let me take a look
<maxb> The "/bin" issue is fixed already
<rtg_> maxb: thats the one
<NCommander> makedumpfile installs fine here on amd64
<NCommander> (version 1.3.3-0ubuntu3)
<NCommander> (on karmic)
<rtg_> NCommander: my mirror update must have just missed it. I now see the upload
 * maxb hugs gb.archive.ubuntu.com
<NCommander> rtg_, ah well, if you want me to look at anything, feel free to ping me :-)
<rtg_> NCommander: no problem, sorry for the noise.
<NCommander> rtg_, no problem
<Sarvatt> cjwatson: no change at all in usplash under KMS for me when its built into the kernel incase that was supposed to change any. same segfault 3 seconds into the boot and it leaves the graphic up after it dies in an inteldrmfb
<cjwatson> Sarvatt: I was unaware of your segfault so it wasn't intended to fix that ;-)
<cjwatson> Sarvatt: the purpose of my change was to cause usplash to use the native screen size under KMS, nothing more
<cjwatson> my changelog must have really sucked - you're the second person to completely misunderstand the purpose of that change today
 * ogra wonders what "KMS built into the kernel" means though
<amitk> ogra: CONFIG_KMS=y or something similar
<ogra> amitk, ah, well, for me there is still a module switch i need to flip to make my driver use it
<cjwatson> it's enabled on i915 with the current kernel
<ogra> i thought it meant the driver is compiled in, into a custom kernel
<cjwatson> "works for me" is all I can say :)
<ogra> ah, so i can drop my /etc/modprobe.d entry
<cjwatson> though it didn't work until my most recent initramfs-tools upload
 * ogra didnt follow so closely, i'm drowning in "mono on ARM" 
<nixternal> bryce: hey, issues with intel and kernel 2.6.30-10.12 that has KMS enabled...fyi if you didn't know already
<Sarvatt> it means its not a module and you get the high resolution framebuffer from the start of the boot process instead of it switching about 15 seconds or so in otherwise :D
<cjwatson> Sarvatt: I suggest you revert that and use the initramfs-tools I just uploaded instead
<cjwatson> which modprobes it in early userspace
<ogra> cjwatson, did you see my grub2 issues with booting from SD recently ?
<cjwatson> the way I've dealt with AGP modules is not really ideal
<cjwatson> ogra: no
<ogra> i have an old cmpc here where i did a fresh install ... booting from HD grub2 switches to decompress the kernel immediately, booting on the same HW from SD it sits about 5 min before it starts decompressing the kernel
<Sarvatt> cjwatson: you arent putting drm into the initrd too? it needs to be loaded before i915 and after intel_agp
<ogra> (identical systems, kernels and indeed the same grub2)
<ogra> cjwatson, i was wondering if it was worth a bug or if its to much of a corner case
<nixternal> bryce: disregard my last statement :)
<Sarvatt> well usplash segfaults 5 seconds in on the ubuntu kernel with i915 in the initrd, graphic stuck on the screen and no throbber/progress bar, same deal
<cjwatson> Sarvatt: ok, at least it's clearly nothing to do with the changes I made ;)
<maco> is this why nixternal is in #kubuntu-devel warning us not to update our kernels if we use intel?
<cjwatson> Sarvatt: I suggested trying to get a core dump out of it
<nixternal> what I find interesting is that in dmesg I see "[drm] Initialized drm 1.1.0 20060810"
<nixternal> and "[drm] Initialized i915 1.6.0 20080730 for 000:00:02.0 on minor 0"
<nixternal> only way I can boot up with 2.6.30-10.12 is by setting nomodeset in grub
<nixternal> and xorg telling me it can't open drm
<cjwatson> did you ensure to load the appropriate agp module before i915 gets loaded?
<cjwatson> that bit me the other day
<Sarvatt> i've been asking him for a dmesg of it failing for the past 20 minutes to try to help #ubuntu+1
<maco> any archive admins about?
<cjwatson> yes
<maco> apachelogger's looking for someone to accept libqinfinity
<nixternal> Sarvatt: d'oh, let me pastbin that for you..s.orry didn't see that request
<Sarvatt> thats why i said something about drm in the initrd thinking that might be the problem but its fine on my machine as is
<maco> (if you're confused, yeah he just had libqinfinity rejected a few minutes ago. that was a broken one. this is the fixed one)
<nixternal> Sarvatt: http://paste.ubuntu.com/202244
<Sarvatt> you're booting with nomodeset there
<nixternal> ok, let me try something for you
<nixternal> will have to ssh in to grab it for you
<billybigrigger> when did firefox-3.5 show up in the repos?
<ogra__> billybigrigger, in jaunyt i think
<billybigrigger> hmm
<billybigrigger> still no flash sound in it :P
<nixternal> Sarvatt: http://paste.ubuntu.com/202247/
<ogra__> billybigrigger, what has flash sound to do with firefox ?
<billybigrigger> any word on that guys? i remember dtchen saying something about getting sound in flash, but was waiting on an ia32libs update or something, that i haven't seen
<billybigrigger> ogra::: nothing
<billybigrigger> ogra::: i was just sayin :P
 * ogra__ has sound in flash with ff 3.5 
<billybigrigger> 32bit or 64bit?
<ogra__> 32 indeed
<billybigrigger> ya
<maco> he had an explanation in a bug comment somewhere, on how to make 64bit flash work well...but i think it was deemed too involved a process when adobe 64bit is just around the corner
<billybigrigger> must be nice :P
 * maco uses swfdec
<ogra__> "billybigrigger> still no flash sound in it :P"
<ogra__> that didnt really indicate you use 64
<billybigrigger> true
<Sarvatt> nixternal: dont see any problems there
<Sarvatt> nixternal: what happens?
<nixternal> Sarvatt: when it would go to boot into X/KDM like normal, it just locks up, I have lighter than normal _ in the top left corner
<nixternal> not blinking, but I can ssh into the box
<Sarvatt> do you have an /etc/X11/xorg.conf?
<nixternal> Fatal server error:
<nixternal> Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
<Sarvatt> yep fbdev problem
<nixternal> no
<Sarvatt> xserver needs the patch in karmic
 * ogra__ sells nixternal a new framebuffer 
<Sarvatt> what you need to do is add this to /etc/X11/xorg.conf
 * nixternal steals the framebuffer from ogra__ and runs
<Sarvatt> Section "Device"
<Sarvatt>         Identifier "intel"
<Sarvatt>         Driver "intel"
<Sarvatt> EndSection
<ogra__> Nicke_, pfft, i got enough framebuffers around ... but you will have to pay for that one, mind you !
<ogra__> err s/Nicke_/nixternal/
<nixternal> hehe
<Sarvatt> nixternal: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508476   https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/383407   if you want more info on it
<ubottu> Debian bug 508476 in xserver-xorg-core "xserver-xorg-core: Cannot run in framebuffer mode. Please specify" [Grave,Open]
<nixternal> Sarvatt: groovy, thanks
<candrews_> https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/277556
<ubottu> Ubuntu bug 277556 in open-vm-tools "should build kernel modules with dkms" [Undecided,Confirmed]
<candrews_> could someone sponsor that bug fix and get it into karmic?
<candrews_> (That link includes the fix, just a package review and upload are required)
<cjwatson> ryanakca: do I want to know why libqinfinity has both .so.0.* and .so.1?
<cjwatson> maco,ryanakca: sorry, I think this has exceeded my available mental bandwidth right now. It would probably be best if the same archive admin reviewed it who rejected it previously
<ryanakca> cjwatson: because upstream has broken sonames, and thanks :)
<Riddell> mathiaz: akonadi needs mysql-server-core-5.0 (or 5.1).  amarok needs mysql 5.1
<mathiaz> Riddell: ok - I'm working on updating 5.1 so that it can move to main
<mathiaz> Riddell: so I'll keep the -core package structure for 5.1
<mathiaz> Riddell: there will be a mysql-server-core-5.1 and mysql-server-5.1
<Riddell> mathiaz: great.  is 5.0 being demoted then?
<mathiaz> Riddell: that's the plan
<\sh> mathiaz: what about the missing mysql-cluster support in 5.1 packages , as mentioned by nobse?
<mathiaz> \sh: nothing for now - I think he's working on packaging it separatly
<mathiaz> \sh: not sure though.
<mathiaz> \sh: I'm not aware of his whole plan though.
<\sh> mathiaz: yes...but hopefully demoting 5.0 to universe and pushing 5.1 to main doesn't upgrade mysql 5.0 installations...
<mathiaz> \sh: well - the proposal is to have mysql-server depend on 5.1
<\sh> mathiaz: he..that's my problem with this transition
<mathiaz> \sh: well - what would be the other option?
<mathiaz> \sh: move mysql-server to universe?
<\sh> mathiaz: pinging nobse and trying to push mysql-cluster somehow into ubuntu/debian (or vice versa)
<\sh> mathiaz: or working on our own for mysql-cluster (7.2 is the latest version imho)
<mathiaz> \sh: ok - so your concern is that moving from 5.0 to 5.1 in main means dropping support for mysql-cluster?
<\sh> mathiaz: yes
<\sh> mathiaz: or mysql-server depends on mysql-server-5.0 | mysql-server-5.1 which could mean: new installations will install 5.1 and older installations won't be botherd (if I'm correct here)
<mathiaz> \sh: hm - that's a good idea
<mathiaz> \sh: however I think you need something like "real-package | virtual-package"
<mathiaz> \sh: ex mailx control: depends: postfix | mail-transport-agent
<lamont> mathiaz: the current program is Depends: default-mta | mail-transport-agent
<lamont> though that's just mailer evil
<mathiaz> lamont: and default-mta is a virtual or real package?
<lamont> it's provided by one of exim4 (debian) or postfix (ubuntu)
<mathiaz> lamont: ok.
<lamont> after much discussion about the difference between a metapacakge and a provides.
<lamont> provides was slightly less horrible
<lamont> though probably not adequately reflected in policy
<\sh> mathiaz: whatever the solution will be, but we need to take care about those issues...
 * dupondje needs somebody that can release a new busybox version into karmic
<dupondje> as the current is broken :x
<dupondje> somebody awake that can push a new busybox version ?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/391299
<ubottu> Ubuntu bug 391299 in busybox "Sleep of Float broken! (Enable SLEEP_FANCY & FLOAT)" [Undecided,New]
<dupondje> can somebody put it as High priority ?
<dupondje> cause it breaks booting in Karmic :(
<mathiaz> stgraber: what's the url of the PPA where the asterisk packages can be found?
 * dupondje tickles cjwatson 
<dupondje> nobody awake? :(
<stgraber> mathiaz: https://edge.launchpad.net/~revolution-linux/+archive/asterisk
<mathiaz> stgraber: merci
<stgraber> mathiaz: np
<dupondje> badly need cjwatson  :(
<Nafallo> dupondje: hmm. so it's not worth just asking the question and see if anyone knows the answer? :-)
<dupondje> well busybox needs to gets fixed asap
<dupondje> its broken, and makes Karmic unbootable :x
<dupondje> https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/391299
<ubottu> Ubuntu bug 391299 in busybox "Sleep of Float broken! (Enable SLEEP_FANCY & FLOAT)" [Undecided,New]
<dupondje> the bug
<dupondje> and patch :P
<dupondje> fixed it, just needs to get into repo's
<dupondje> Nafallo: see :) nobody answers ;)
<Nafallo> dupondje: sure. but I can't see how the issue is blocked on a single developer :-)
<dupondje> can't see somebody else commiting new versions of busybox then cjwatson  :p
<Nafallo> dupondje: that doesn't mean no one else CAN do it. I see Scott have done uploads in the past for example :-)
<Nafallo> anyway. that's not the issue :-)
<dupondje> :) well somebody needs to do it then :D
<mdz> grub-pc seems to be asking a lot of questions when it upgrades
<slangasek> kirkland: sorry, think I failed to parse your earlier comment -- "+VERSION=" ?
<chrisccoulson> mdke - you there?
<kirkland> slangasek: hiya
<kirkland> slangasek: yeah, in the patch you sent to Debian, the service script sets a VERSION variable
<kirkland> slangasek: which was something-ubuntu1
<kirkland> slangasek: just a nit, that Debian might want to prune that, perhaps
<nixternal> a bit late there kees, but it is nice knowing I don't have to bug you all of the time now :)
<ajmitch> nixternal: I thought KDE wasn't meant to have any of those problems
<nixternal> we don't, but just in case
#ubuntu-devel 2009-06-24
<slangasek> kirkland: ah - if he cares, I guess he probably already pruned it when committing :)
<mdz> booting the latest karmic only blew up a little for me (grub.cfg/MBR mismatch)
<TheMuso> Is there an easy way to search for ITP bugs in bugs.debian.org?
<ajmitch> the only way I know of is looking at bugs.debian.org/wnpp
<TheMuso> ajmitch: thanks
<TheMuso> dtchen: Lennart really pushes the boundary. We will not be able to offer pulse 0.9.16 for testing till we have kernel 2.6.31. :S
 * TheMuso goes and fumes in the corner.
<ScottK> That'll teach dtchen to promise we're dropping our diff from upstream.
<TheMuso> ScottK: Well its not really a diff. Its having to wait till we move onto the newer kernel version.
<ajmitch> TheMuso: we'll be getting 2.6.31 for karmic?
<TheMuso> ajmitch: I believe so.
<TheMuso> Its even mentioned in the #ubuntu-kernel channel topic.
<ajmitch> ok
 * ajmitch doesn't visit there :)
<TheMuso> At one point I would have said that thats pushing things a bit far, but now that Pulse needs it, I await it eagerly.
<TheMuso> Pulse development is still moving very rapidly.
<ion> Why does it need 2.6.31?
<ScottK> So it's a 3 kernel version release agaon.
<ScottK> again ....
<TheMuso> ion: Pulse specifically doesn't, but pulse now depends on rtkit which needs 2.6.31.
<ScottK> That worked out soooo well last time.
<TheMuso> ScottK: I tend to agree.
<ajmitch> ScottK: hopefully with a few more people working on it this time it'll be a bit less problematic
<ion> rtkit, huh. /me looks it up. Probably not as bad as it sounds. ;-)
<TheMuso> ion: its a new Lennart creation.
<ScottK> ajmitch: What makes you think there will be more people working on the kernel in Karmic than Intrepid?
<ajmitch> ScottK: I thought that the team had grown a little in the last year or so
<TheMuso> I believe it has.
<ScottK> OK.  Well I hope so.
<ScottK> Intrepid was the first time I had systems I couldn't upgrade due to kernel problems.
<ajmitch> I don't recall too many people saying that intrepid's kernel was buggier than previous releases
<ScottK> My personal experience was pretty awful, but of course everyone has different stuff, so see it differently.
<lifeless> yay karmic
<lifeless> $ python
<lifeless> Python 2.6.2+ (release26-maint, Jun 19 2009, 15:16:33)
<lifeless> [GCC 4.4.0] on linux2
<lifeless> Type "help", "copyright", "credits" or "license" for more information.
<lifeless> >>> import qt
<lifeless> Segmentation fault
<NCommander> lifeless, by some definitions, that's a feature
<mrooney> haha, truly
<dholbach> good morning
<pitti> Good morning
<directhex> microsoft-sponsored party this evening. i feel it is my duty to wear my uds crew shirt
<pitti> didrocks: lol! have fun
<enrico> directhex: and to eat and drink as much as possible, so that as much as possible of their money gets spent on free software people!
<pitti> (with drinking not necessarily into free software _quality_ :-P)
<Chipzz> NCommander: rofl :)
<pitti> tkamppeter_: when you merge, please use debuild -S -v<previous version in Ubuntu>, so that the .changes gets the merged changelogs from Debian as well; thanks!
<tkamppeter> pitti, sorry.
<pitti> tkamppeter: no problem, just a reminder for the future; nicer to read on karmic-changes@
<tkamppeter> pitti, now my only missing merge is Gutenprint, but I will wait for the 5.2.4 release which will come in the next days.
<pitti> tkamppeter: that'll go into Debian soon?
<tkamppeter> pitti, depends on the Debian maintainer.
<tkamppeter> I want to have it in Karmic anyway.
<tkamppeter> pitti, by the way, Poppler 0.11.0 did not make it into Debian yet.
<pitti> tkamppeter: ah, I thought you wanted to wait with the merge until .4 is in Debian
<pitti> tkamppeter: poppler> they'll wait for 0.12 to get the stable series; Seb said it should get released in a few weeks
<tkamppeter> pitti, if the Debian maintainer quickly updates I can get gutenprint 5.2.4 in by merge, if not I will take it directly to get it in before FF.
<tkamppeter> pitti, OK if 0.12 gets into Debian before our FF, we simply reactivate pdftoopvp in the cups package, if it comes too late, we need to reactivate pdftoopvp in a Ubuntu-only way.
<pitti> tkamppeter: gutenprint> sure; but if that will still take a while, don't hesitate to merge it now (also to get our remaining patches to Debian), then the next merge will be easier, and Debian can also apply patches to their 5.2.4 upload
<pitti> tkamppeter: poppler> right, that will be a little tricky in the cups package, but doable
<dholbach> does anybody else have held mono packages in karmic? (amd64?)
<TheMuso> dholbach: Yeah when I upgraded earlier today I did.
<dholbach> does anybody know what the hold up is there?
 * dholbach wants his gnome-do to work again
<pitti> works fine here; only held back package here is libgdl-1-common
<pitti> (I guess due to amd64/i386 build skew)
<persia> dholbach, Likely arch-all vs. arch-any and a publisher run, try refreshing your cache.
<dholbach> persia: it's stuck since yesterday
<persia> dholbach, Erg.  That's too long.  What's at the bottom of the stack?
 * persia doesn't currently have any working amd64 hw, and can't check.
<persia> Alternately, if you don't want to chase the stack, just feed rmadison a *really* long line including all the packages you have held back, and see if there is any skew.
<dholbach> The following packages will be REMOVED:
<dholbach>   mono-2.0-runtime mono-common mono-jit ubuntu-desktop update-manager
<dholbach>   update-notifier
<dholbach> The following NEW packages will be installed:
<dholbach>   binfmt-support libmono-i18n-west2.0-cil
<dholbach> The following packages will be upgraded:
<dholbach>   libmono-corlib2.0-cil libmono-data-tds2.0-cil libmono-data2.0-cil
<dholbach>   libmono-getoptions2.0-cil libmono-posix2.0-cil libmono-security2.0-cil
<dholbach>   libmono-sharpzip2.84-cil libmono-sqlite2.0-cil libmono-system-data2.0-cil
<dholbach>   libmono-system-web2.0-cil libmono-system2.0-cil libmono2.0-cil mono-2.0-g
<dholbach>   mono-gac mono-gmcs mono-runtime update-manager-core
<dholbach> hi mvo :)
<pitti> dholbach: oh, I think I had that yesterday, and I just had it remove them
<mvo> hey dholbach
<pitti> dholbach: it looked like -runtime got split into several smaller libs or so
<pitti> dholbach: I didn't really care
<persia> It did.  Part of the continued effort to make mono take less space on the CD.
<pitti> dholbach: (btw, that's not "held back", that's usual conflicts/replaces:)
<dholbach> hum
<directhex> it had better be! if it was held back i'd be sad
<dholbach> ok, looks like gnome-do works again :)
<Hobbsee> yay, gnome-do!
<dholbach> gracias
 * dupondje waiting for busybox to get fixed :P
<hyperair> is anyone else besides me noticing update-manager-core having a newer version, but update-manager not?
 * hyperair scratches his head
<pitti> update-manager-core |    1:0.122 |        karmic | i386
<pitti> update-manager-core |    1:0.123 |        karmic | amd64
<pitti> update-manager |    1:0.122 |        karmic | all
<pitti> I'd say that i386 FTBFSed
<mvo> its waiting in binary NEW
<mvo> well, auto-upgrade-tester is waiting there I would guess
<dupondje> hyperair: same here indeed :p
<StevenK> pitti: So, I suck, and didn't upload last night.
<hyperair> ah i see
<dupondje> https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/391299
<ubottu> Ubuntu bug 391299 in busybox "Sleep of Float broken! (Enable SLEEP_FANCY & FLOAT)" [Undecided,Confirmed]
<dupondje> fixxor plz :)
<pitti> ah, is that why I'm thrown into a busybox shell now?
<pitti> (just ctrl-d'ing helps)
<seb128> same here
<dupondje> yep pitti
<dupondje> I have a fixed version in my ppa
<pitti> I'd wait for cjwatson to comment, though
<dupondje> well the previous versions had a patch included
<dupondje> custom
<dupondje> to support sleep 0.1
<dupondje> the newest version (used in karmic) has sleep for floats built in, so no more patch included. But its a configuration option that needs to be enabled. If its not enabled ofc, it will not work :P
<dupondje> should be pushed into repo's imo :) nothing fancy changed ;)
<pitti> dupondje: I expect cjwatson to turn up in about 30 minutes, I'll confirm with him and then upload
<pitti> dupondje: thanks for your investigations!
<directhex> anyway, yays @ mono 2.4 in karmic
<directhex> should mean a little saving on the cd (possibly a couple of apps need to be rebuilt to pick up on lighter dep tree)
<pitti> directhex: \o/ rock
<directhex> and a <=25% drop in RAM consumption
<directhex> pitti, when (not if, when!) the latest tomboy goes into Experimental & gets requestsynced, that gives you 5 meg
<dupondje> pitti: np :) at least its working here again with the changes :)
<pitti> directhex: wow! *hug*
 * pitti sheds a tear
<pitti> directhex: admittedly, _every_ upload has a <= 25% drop in RAM consumption :)
<pitti> erm, at least almost all
<directhex> pitti, it's thanks to a snippet of debian/rules wizardry which symlinks gnome doc images with matching md5sums, since stupid gnome help requires a full set of images for every translation (even though the images are usually dupes)
<pitti> directhex: ah, we have that in cdbs for quite a whilw
<pitti> I wasn't aware that tomboy didn't catch that
<pitti> nice air to be squeezed out indeed
<directhex> pitti, well, the theory is 25% drop in mono's runtime overhead in the new jitter - but real-world in apps, much of the memory consumption comes from the underlying gtk+ and mono's not to blame, so real-world gui apps will give less than 25%
<hyperair> directhex: does 25% drop mean a 25% decrease in startup time then? =D
<hyperair> oh RAM consumption only =(
<directhex> hyperair, tomboy in karmic is <=50% faster to start up due to changes in the way it works with mono-addins
<hyperair> cool
<hyperair> but it doesn't help my incredibly long login time
<hyperair> it takes longer to log in than to boot
<hyperair> =(
<hyperair> in fact, i think i can take a shit faster than it can log in
<StevenK> !ohmy
<ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
 * hyperair facepalms
<hyperair> shit is now a swear word eh
<directhex> i run no mono apps on login, and login is slow
<directhex> hyperair, always has been
<StevenK> hyperair: The image is ... not attractive, hm?
<hyperair> fine. i take a shorter time to defecate than it takes for my notebook to log in
<StevenK> That doesn't help!
<Hobbsee> hyperair: dude...
<Hobbsee> hyperair: besides, if you want a faster boot time, switch to metacity, adn don't use copiz
<hyperair> i know, damnit.
<directhex> or dump gnome and use twm
<directhex> erm, wait, don't use the word "dump" there. um...
<hyperair> but why can't we put some effort into speeding up the login process instead of the bootup process?
<hyperair> it's so fast already!
 * Hobbsee throws both hyperair and directhex into the gutter
<Hobbsee> hyperair: who's to say that they aren't?
<directhex> hyperair, such things ARE being worked on. there was a talk about it at UDS
<hyperair> oh there was?
<hyperair> it seemed that bootup time got more attention
<StevenK> Boot time means BOTH
<directhex> hyperair, the 10 second boot time being talked about for lurid lemur is grub->desktop not grub->login
<pitti> hyperair: we will
<hyperair> heh okay
<hyperair> lurid lemur..
<hyperair> nice name
<pitti> hyperair: seb128 wants to work on nautilus, I'll look into speeding  up the panel
<hyperair> cool =D
<pitti> maybe robert_ancell and mvo can make the compiz startup faster, this is dreadful right now
<directhex> the panel occasionally wants to delete half my widgets on login. i wish i knew why
<pitti> those are the three main offenders, the rest is pretty negligible
<hyperair> the applets crashed
<hyperair> that's why
<directhex> pitti, those specifically, or their deps? e.g. does gconf take time to behave?
<mvo> we did ~30% faster startup last cycle :)
<mvo> (with compiz)
<pitti> directhex: those specifically; well, with panel you have bonobo and all the applets, which are deps in some way
<hyperair> that's 30%?
<seb128> mvo, still 70% to go ;-)
<pitti> lol
 * mvo hugs seb
<pitti> yeah, must take zero time!
<Hobbsee> agreed!
<pitti> mvo: we so much need KCWM
<directhex> seb128, sorry btw, my fault tomboy 0.15.1 is late. i went for beer with meebey on monday so he couldn't sponsor it
 * hyperair read that compiz took a lot of time to just read configuration
<seb128> directhex, this "waiting on debian" doesn't really make sense why don't we upload to ubuntu and sync when they wake up in some weeks?
<seb128> it's blocked for debian for almost 2 weeks now
<seb128> on debian
<directhex> seb128, poke Laney about it - i think he's been using git in a sufficiently sensible way that it should be safe to do so
<seb128> he tell me every day that it will be uiploaded to debian today
<seb128> but apparently that's not happening
<directhex> well, yes, there's a bottleneck there.
<directhex> if only we had more than one DD in that team (http://lists.debian.org/debian-newmaint/2009/06/msg00037.html)
* spm changed the topic of #ubuntu-devel to: LP in R/O 0900-1000 UTC | Archive: open | karmic alpha-2 released | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> dupondje: ok, thanks, looking
<cjwatson> pitti: I don't think the patch as attached is quite right so please don't sponsor it directly
<pitti> cjwatson: good morning
<pitti> cjwatson: right, I had a feeling it was better to wait for you :)
<dupondje> cjwatson: did my best ;) it works here anyway ;)
<pitti> cjwatson: like, you might not need it in the udeb, etc.
<directhex> seb128, i think Laney is using pristine-tar so there shouldn't (!) be any problems with mismatched origs from a 0ubuntu1
<cjwatson> exactly
<pitti> dupondje: nothing to worry about; tracking it down was the hardest part here
<cjwatson> definitely my fault though, I knew about the new config option and it obviously just slipped my mind
<dupondje> quit the drugs :)
<cjwatson> I don't think we need FANCY_SLEEP
<dupondje> yep u need it
<dupondje> FLOAT depends on it
<cjwatson> oh, but yes you're right
<dupondje> if u don't enable FANCY then FLOAT doesn't work
<cjwatson> u => you please
<pitti> cjwatson: so, that patch with static and udeb dropped?
<cjwatson> anyway, I'm on it :)
<pitti> okay
<pitti> thanks
 * directhex blames twitter for making txt spk fashionable again
<cjwatson> I just want to think briefly about whether we actually do need it in the udeb
<cjwatson> we didn't have FANCY_SLEEP turned on there before, but the prior patch didn't require FANCY_SLEEP for fractional sleep
<cjwatson> uploaded, anyway
<dupondje> cjwatson: your computer was to fast, so it didn't need to sleep :) Looks like some people fixed it by replacing UUID by /dev/sd* etc. Cause everything worked, but if it really needed to sleep a bit, it wasn't
<cjwatson> probably
<cjwatson> ah well, sorry about that anyway :-/
<dupondje> bugs happen :)
<maxb_> Ah, I just filed a bug about that sleep issue
<maxb_> Anyway, on the trail of *another* bug, where does hal keep its device information these days? I need to find whatever rules it's applying for synaptics touchpads and apply them to another device name
<cjwatson> maxb_: you already duped it?
<maxb> I filed mine on initramfs-tools
<cjwatson> ah, I'll dup it now
<maxb> ok, I was just hunting scrollback for the number to dupe it to
<MTecknology> pitti: you around?
<pitti> MTecknology: hi
<MTecknology> pitti: I have a question about a bug report
<MTecknology> You think this is still valid? https://bugs.edge.launchpad.net/ubuntu/+source/swfdec-gnome/+bug/188150
<ubottu> Ubuntu bug 188150 in swfdec0.5 "promote to main (swfdec-gnome)" [Undecided,Invalid]
<cjwatson> maxb: oh, note that you'll need to run 'sudo update-initramfs -u' by hand after the upgrade
<maxb> ah, thanks
<cjwatson> busybox-initramfs is a dependency of initramfs-tools, so can't itself run update-initramfs ...
<cjwatson> annoying, but there it is
 * maxb scratches head on why for one boot only, synaptics device was called 'PS/2 Synaptics TouchPad' not 'SynPS/2 Synaptics TouchPad'
<pitti> MTecknology: nobody followed up on it recently, so right now I don't consider it valid
<MTecknology> pitti: care if I close it?
<pitti> MTecknology: I'm fine with that
<MTecknology> pitti: you think you have enough open bugs?
<pitti> heh, yes :)
<dupondje> what should I do when I find bugs of Ibex Beta ... mark as Invalid ? cause no need to keep them open ?
<cjwatson> err, that depends on whether they are still bugs in karmic
<cjwatson> bugs are not automatically invalid just because they were filed on intrepid!
<cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-02-27-bug-triage-rants.html
<dupondje> https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/278434 <- this for example :)
<ubottu> Ubuntu bug 278434 in busybox "Busy Box 1.10.2 error while installing Ibex beta version" [Undecided,New]
<cjwatson> the correct procedure is to figure out what the problem was
<cjwatson> if that problem is fixed, fix released
<cjwatson> if that problem is not fixed, leave it open
<cjwatson> I've reassigned that bug to linux, where it likely belongs
<cjwatson> it should definitely not be summarily marked invalid
<MTecknology> pitti: what is your job at canonical?
<cjwatson> not without further investigation
<dupondje> ok :)
<pitti> MTecknology: see https://launchpad.net/~pitti
<MTecknology> pitti: i just saw you're karma score too. It makes me feel like my 30k look like I don't do a single thing in lp :P
<MTecknology> convert that to decent english in your head.. I must be tired
<pitti> MTecknology: well, I do quite a lot, but admittedly most of my karma is a bug (see bug 373772)
<ubottu> Launchpad bug 373772 in launchpad-foundations "pitti gets karma for language pack uploads" [Undecided,New] https://launchpad.net/bugs/373772
<MTecknology> wow
<MTecknology> I thought soyuz was for packaging ppa
<cjwatson> soyuz does the Ubuntu archive
<MTecknology> I think I'd need to learn too much to understand all that
<MTecknology> maybe
<cjwatson> briefly, Soyuz is the component of Launchpad that accepts uploads, publishes them in archives, etc.
<StevenK> pitti: If I upload this package now, can you review it soonish?
<pitti> StevenK: yes, I can
<StevenK> pitti: Uploaded, unr-meta. If you can put it into universe for the moment, I'll look at getting it thrown to main when all of its depends are.
<cjwatson> TheMuso: was the 386 kernel flavour not meant to have been merged along with the rest of ports?
<dupondje> Launchpad will be going offline for maintenance in 13 minutes.
<dupondje> eeek :)
<pitti> StevenK: not in the queue yet
<StevenK> pitti: I just checked, I did at least target karmic
<cjwatson> I do wish people would NEW kernel udebs properly :-/
<cjwatson> and not just casually dump stuff into universe
<pitti> cjwatson: hm, kernel-overrides should catch them, doesn't it?
<cjwatson> only if they match a previously existing package
<pitti> ah, so "real" NEW
<pitti> StevenK: still not in the queue; did you get a reject mail?
<cjwatson> you're supposed to check the results of kernel-overrides, not just go kernel-overrides; q accept :)
<cjwatson> I've cleaned up the overrides now
<StevenK> pitti: Lemme check
<mvo> cjwatson: do you mind if I upload grub2 with the following patch http://paste.ubuntu.com/202725/ to support crashkernel= in it?
<StevenK> pitti: Seems like I didn't get a mail about it at all
<TheMuso> cjwatson: apw, rtg and I were discussing this the other day. I didn't merge 386 thinking there was a chance that Ubuntu would move to 586 only. There is also the issue of the 386 kernel possibly breaking kernel builds, since it has kernels that are supported. I await their decision as to whether it gets put back in for now.
<cjwatson> mvo: spell "crashkernel" correctly in the patch name :)
<robbiew> lol
<cjwatson> mvo: um, it's OK for upload now, but that file is mainly maintained by upstream and we'd like to stay close to them. Could you please send it to grub-devel@gnu.org as well to discuss what a good upstreamable solution would be?
<cjwatson> TheMuso: I was under the impression we were planning to *tune* for 586 (-mtune vs. -march), but could be misremembering
<cjwatson> actually it's possible I am misremembering since 586 isn't a good tune target :)
<mvo> cjwatson: *cough* sorry for the typo - I will fix that and send the patch to the devel list as well
<cjwatson> mvo: (you might need to give grub-devel some background, of course ...)
<mvo> cjwatson: thanks , I will add that info too
<freinhard> hi!
* spm changed the topic of #ubuntu-devel to: LP rollout blues, back ASAP | Archive: open | karmic alpha-2 released | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ogra> cjwatson, do we have a udeb that sets up a serial console ?
<cjwatson> does it need a separate udeb?
<cjwatson> I thought rootskel did that if you followed the directions in the installation guide
<ogra> well, we're just discussing a) debootstrapped systems  and b) the possible need to set up a serial console later in an installed system
<cjwatson> debootstrapped systems get to configure some stuff themselves. I'm uninterested in "fixing" that
<cjwatson> finish-install does serial console setup in that case
<ogra> i'm in the camp that we should just have a serial-console package that has preseedable options for device speed etc
<cjwatson> err, let me rephrase that. "now that I understand what you mean, finish-install is where the code lives"
<ogra> and drops the /etc/event.d file in place
<cjwatson> it really doesn't need a separate udeb
<ogra> ok, well, i was hoping if there is a udeb we could just make an easy change to make the source spit out an additional deb :)
<cjwatson> no point in it being preseedable, we just fish the options out of the serial console on which the installer is already presumptively running by means of stty
<ogra> right, in case of the installer
<cjwatson> sounds like overengineering. just tell people how to set it up; debootstrapped systems already require quite a bit of manual setup after debootstrapping.
<ogra> in case of me using debootstrap inside qemu i wont have the actual device string the target HW will use
<cjwatson> serial console is just one tiny piece of that.
<ogra> well, my original prob is that plenty of people use my arm-rootfs-builder script ... i drown in requests from people not being able to set up the serial parts after rolling the rootfs.tgz ... i would like to add an option to my script ... and i dont want to addd anything self hacked but something we all benefit from :)
<ogra> specifically i'D like to obsolete https://help.ubuntu.com/community/SerialConsoleHowto
<freinhard> anyone else with broken wlan on karmic? http://paste.ubuntu.com/202401/
<cjwatson> ogra: for the moment, I think you should just extend your script
<ogra> ok ...
<cjwatson> I don't see a purpose in creating a deb that solves just this one piece of the configure-after-debootstrap problem, and not the whole thing
<ogra> indeed and the deb would only be a postinst dropping 7etc/event.d/serial (or some such) in place
<lifeless> slangasek: getting there before d-d does; 'Why do you hate freedom?'
<dupondje> python-xml is renamed to python-xmlbase in karmic ?
<maxb> dupondje: I'd suggest you check the removal reason... but LP is down for maintenance.
<maxb> But I'd guiess that python-xml is removed in karmic
<dupondje> yea indeed, seems so
<maxb> Yup, it's on the sync-blacklist
<dupondje> its now for default in python or so ?
<dupondje> damn launchpad :) when its down you realise you use it ALOT :)
<StevenK> pitti: Is it there now? *whine*
<pitti> StevenK: as you can check yourself with "q info unr", no :/
<StevenK> pitti: Hmmm.
<StevenK> :-(
<pitti> perhaps because LP is read-only ATM?
* spm changed the topic of #ubuntu-devel to: LP rollout blues: Mostly Back | Archive: open | karmic alpha-2 released | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<StevenK> pitti: I uploaded it before that, but hopefully it hasn't disappeared
<maxb> Could someone giveback dia/i386? Looks like some kind of weird transient problem (CHROOTWAIT / Resource temporarily unavailable) - https://launchpad.net/ubuntu/+source/dia/0.97-2/+build/1087621
* spm changed the topic of #ubuntu-devel to: Archive: open | karmic alpha-2 released | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<StevenK> pitti: Just got the e-mail, please NEW it
<pitti> StevenK: so apparently it was stuck by the LP rollout
<pitti> StevenK: "Copyright 2004, Canonical Ltd." -- please fix in bzr
<pitti> StevenK: also, debhelper 4 is deprecated, please use at least 5
<pitti> (and S-V 3.8.2 while you are at it)
<pitti> StevenK: accepted
<cjwatson> maxb: done
<StevenK> pitti: Thanks!
<bigon> https://edge.launchpad.net/ubuntu/+source/empathy/2.27.3-1ubuntu1/+build/1091194 failed to upload
<bigon> :/
<cjwatson> bigon: no idea what happened there, but I've retried everything in the failed-to-upload state
<cjwatson> if it happens again, let me know and we'll investigate
<wgrant> cjwatson: It was demoted during the build.
<wgrant> Known bug.
<wgrant> Well, not during, but before a publisher.
<cjwatson> ah
<wgrant> So, due to the demotion plus the downtime, there were two non-superseded publishings, so it got confused.
<bigon> mmm and why empathy has been demoted?
<seb128> bigon, to get it to build I though the previous build failed because of universe build-depends
<seb128> bigon, could have been wrong, I will promote it again once it has build
<StevenK> seb128: Won't promoting it to main also rebuild it?
<seb128> StevenK, no
<seb128> why would a component change trigger a rebuild?
<seb128> we don't have bin-nmu anyway
<ScottK> pitti: I have an SRU question.  In amavisd-new, we have an issue in Jaunty where the secondary virus scanner function doesn't successfully call clamav.  Would that be SRU material do you think or should I just backport the new version from Karmic?  The fix itself is quite small.
<Kano> hi, why is a ? in the console-setup/layoutcode?=xx option in karmic iso images?
<Kano> when you check with: cat /proc/cmdline
<Kano> that must be wrong
<juanje1> Kano: hummm... it seems so to me...
<cjwatson> Kano: no, it's correct
<Kano> define correct
<Kano> it is definitely not german when i boot it
<cjwatson> Kano: ?= means "set value, but don't mark as seen"
<cjwatson> if it isn't working, it's not because of the ?=
<cjwatson> (see scripts/casper-bottom/24preseed)
<cjwatson> (or indeed scripts/casper-bottom/19keyboard)
<Kano> btw. you should set de-latin1-nodeadkeys for install-keymap
<Kano> in case of german
<cjwatson> no we shouldn't. That's for console-data which we haven't used since edgy.
<Kano> and do you really think that karmic works correctly
<cjwatson> I didn't say karmic worked correctly. I said that the ?= is not the problem.
<cjwatson> nodeadkeys: I'm not going to change the default variant on the word of a single person - file a bug and get consensus from German users
<cjwatson> since I don't use German layouts myself, it would be inappropriate for me to be deciding on what's best, and inappropriate to flip-flop in response to single bug reports
<freinhard> Kano: please post the bug id, i'll vote for nodeadkeys ;)
<cjwatson> I get a German layout in X when booting with the German layout
<cjwatson> it's just the console that's broken
<cjwatson> and I think it's broken for everyone, not just German
<cjwatson> it'll be some horrible initramfsy thing
<ogra> beyond that there was a vote on the forums and german mailing list to keep deadkeys
<kenvandine_wk> cjwatson, is there a work around?
<ogra> we touched that topic end of jaunty/start of karmic
<cjwatson> kenvandine_wk: for broken console? run 'sudo setupcon' after boot
<kenvandine_wk> ok
<Kano> cjwatson: and you like brokin console,do you
<cjwatson> Kano: huh? of course I don't
<cjwatson> Kano: if you're just going to abuse me, please go away
<cjwatson> it's clearly a bug at present
<cjwatson> and in fact I noticed it myself on my normal system with a UK layout earlier today, but hadn't got round to doing anything about it yet
<Kano> fine
<Kano> will check it next week again
<ogra> ah, damned, he's gone ... http://forum.ubuntuusers.de/topic/welches-deutsche-tastaturlayout-benutzt-du/ ...
<ogra> freinhard, you missed the vote :)
<freinhard> that vote asks the wrong question! shouldn't be "which keyboard layout do you use" but rather "which keyboard layout should be default"
<ogra> well, the according mail i wrote made the issue pretty clear, i admit the poll question isnt perfect :)
<freinhard> i use deadkeys as well, but that's because i'm to lazy to change it
<ogra> i hate deatkeys and switch it during install ... but the thread and forum discussion brought up way to valid reasons to keep deadkeys as default
<ogra> so it wont be switched
<ogra> https://lists.ubuntu.com/archives/ubuntu-de/2009-April/016569.html is the thread
<bigon> seb128: so you've planned to put empathy back to main?
<seb128> yes, why not?
<seb128> I just wanted to get the new version to build and I though the issue was universe requirements
<pgraner> asac: what the plan for ff 3.5 for Karmic, still a ppa or will it become the default?
<bigon> ok no problem do you know if some ppl have asked a mir for the needed packages?
<seb128> issues are being worked yes
<kenvandine> seb128, btw... fedora has a patch that moves the gst plugins empathy needs to -good
<asac> pgraner: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-firefox-3.5
<kenvandine> so that is their fix
<seb128> cool
<kenvandine> doesn't mean upstream agrees yet
<kenvandine> but maybe we should follow suit
<pgraner> asac: show off.... I must have missed it... I even looked... *sigh*
<asac> pgraner: its in universe
<asac> pgraner: go ahead and start using it ;)
<asac> (its just not yet officially branded)
<asac> pgraner: apt-get install firefox-3.5 :)
<pgraner> asac: I have been for months now from your ppa
<pgraner> asac: thats why I was asking
<asac> pgraner: ah ok. so yeah. things are moving; its quite a lot of work though ;)
<bigon> seb128: don't forget to put geoloc stuff (libchamplain and geoclue) in main too :)
<seb128> we are not likely to use those by default
<pgraner> asac: I use the weave extension and it only works with that version...
<pgraner> asac: thanks for the info
<robbiew> pgraner: I didn't know you wore a weave extension :P
<pgraner> robbiew: trying to keep hip and all :-/
<pitti> ScottK: is it a regression from intrepid?
<pitti> ScottK: OTOH it almost sounds like a -security issue, is it?
<mvo> hm, could someone please check/binary-NEW auto-upgrade-tester from my latest update-manager upoad?
<mdz> cjwatson: Keybuk: do you recall  which TB meeting it was where we outlined the patent policy?  I have an overdue action to write it up
<Keybuk> mdz: off hand, about three
<Keybuk> Jono's drafts were Apr 07 and Apr 15
<Keybuk> in which he said "a few weeks back"
<Keybuk> so Mar-Apr sometime ;)
<mdz> Keybuk: I'm looking for the one where Mark turned up
<Keybuk> Feb 18 minutes say "assigned to Jono"
<mdz> Keybuk: hmm, that's right, it's coming back to me now
<Keybuk> it appeared on the agenda from about Jan 4 through to March by the looks it
<mdz> and then jono wrote something up, and emailed asking for feedback
<mdz> and then I lost the plot
<cjwatson> mdz: the TB meeting action gives the date
<cjwatson> 15:19 <cjwatson> [ACTION] mdz to write up patent policy minutes from 2009-03-24 meeting
<Keybuk> I used Jono's draft text for the position statement
<cjwatson> http://irclogs.ubuntu.com/2009/03/24/%23ubuntu-meeting.html
<mdz> cjwatson: was that before or after jono was involved?
<Keybuk> after
<mdz> so I have the ball
<cjwatson> the meeting log suggests it was after
<mdz> but I'm not sure what I need to do
<mdz> I'm about to just copy Jono's draft to the tb list and add my commentary
<cjwatson> what I intended by that action was simply a write-up of the discussion in that meeting
<Keybuk> that seems like a good idea
<cjwatson> but if there's already a draft policy to amend with it, all the better
<mdz> cjwatson: Keybuk: sent to t-b@
<cjwatson> ta
<StevenK> pitti:   * Removed udev-extras from standard
<StevenK> pitti: From a germinate on ubuntu.karmic ...
<pitti> StevenK: that depends on Keybuk uploading udev 143
<superm1> StevenK, all of udev-extras got pulled into udev for udev 143
<pitti> don't upload that yet, please
<ScottK> pitti: It's a regression in that clamav changed (we have 0.95 in Jaunty) and the new clamav works slightly differently.  I think it's not security since it's a functional failure, not any kind of access issue.
<StevenK> pitti: Right, I'll wait until my tomorrow.
<pitti> ScottK: I meant in the sense of "bypassing viruses to the scanner"?
<pitti> ScottK: anyway, if that worked in intrepid, fine to SRU
<ScottK> pitti: OK.  Thanks.
<superm1> pitti, do you think you'll get some time this week to look at the jockey-text frontend I proposed?
<ScottK> pitti: With the clamav stuff if I really look at it hard almost everything could be a security issue.  It's hard to know.
<pitti> superm1: sorry, that seems to have slipped my attention?
<seb128> hum
<seb128> james_w, is that normal that I get emails about code imports failing?
<james_w> seb128: shouldn't get them from me
<james_w> seb128: forward me the email and I'll take a look
<seb128> james_w, those are not from you, I just figured you might know ;-)
<james_w> heh
<seb128> "Subject: Code import gvfs/trunk status: Failed
<seb128> Hello,
<seb128> The import has been marked as failing.
<seb128> https://code.launchpad.net/~vcs-imports/gvfs/trunk
<seb128> You are receiving this email as you are subscribed to the branch."
<seb128> basically
<seb128> same for nautilus and gnome-control-center
<seb128> I guess that's rather a launchpad question than a bzr one
<cjwatson> well, you *are* subscribed to the branch
<cjwatson> I assume https://code.launchpad.net/~vcs-imports/gvfs/trunk will let you unsubscribe
<seb128> cjwatson, I was rather wondering about the failure than the email ;-)
<cjwatson> it seems to be having trouble due to (perhaps?) a git rebase
<cjwatson> but yes, it's a launchpad-bazaar question
<seb128> yeah sorry I first though that was due to the packages import in bzr
<seb128> I pinged too quickly
<ttx> cjwatson: thx for sponsoring the ecj thing. I'll file a bug with update-maintainer, it doesn't comply with new DebianMaintainerField.
<seb128> cjwatson, james_w: thanks
<james_w> seb128: no problem, just glad it wasn't me for once :-)
<cjwatson> ttx: don't bother, I'll fix it in bzr now. I thought it was fixed already but apparently now
<cjwatson> not
<ttx> cjwatson: ok
<cjwatson> ttx: uh ... I do apologise. I misremembered what DebianMaintainerField said ...
<cjwatson> I'll fix it properly this time. The e-mail address was fine but the name was wrong (and the latter is fixed in bzr)
<ttx> cjwatson: heh :)
<ttx> cjwatson: about the other part of that GCJ email, would you find the "any" trick still valid if it covers 7-10 packages ?
<ttx> cjwatson: the overhead will be more significant but I'm not sure we can find a better solution in the karmic timeframe
<amitk> Keybuk: how does one update the readahead list on an upgraded system (jaunty->karmic)?
<Keybuk> amitk: boot with "profile" on the kernel command line
<amitk> nice... and easy
<Keybuk> it's easier with sreadahead
<Keybuk> it just does it itself once a month ;)
<dholbach> a bunch of packages have ubuntu-devel@lists.ubuntu.com as their maintainer address and the list gets lots of archive@ubuntu.com mails due to that
<dholbach> can you please use ubuntu-devel-discuss@lists.ubuntu.com (what 'update-maintainer' from the ubuntu-dev-tools package will do for you)?
<amitk> Keybuk: is sreadahead a drop-in replacement for readahead?
<Keybuk> on SSD, yes
<Keybuk> though use the one from the ubuntu-boot PPA, since that doesn't uninstall ubuntu-desktop <g>
<amitk> so it is not recommended on platters?
<Keybuk> it'll be quite pessimal on platters
<amitk> or its benefits are only seen on SSDs
<amitk> ?
<superm1> pitti, ah i had thought it might have (last time i sent a merge request on jockey it got lost in filters for a while too) : https://code.edge.launchpad.net/~superm1/jockey/jockey-text/+merge/7781
<cjwatson> ttx: I'm not that bothered ...
<cjwatson> StevenK: are you guys planning to merge libhildon? it should not be my merge
<ogra> cjwatson, i doubt we care in the mobile team, there is a new MID community team that casers for moving MID to mer ... (yay for confusing abbreviations)
<ogra> *cares
<ogra> YokoZar1, ^^^ do you guys need libhildon ?
<JohnTeddy> yahoo broke for all pidgin users of Jaunty's version of pidgin. the problem/solution is located here: http://theflamingbanker.blogspot.com/2009/06/some-clarification-on-yahoo-issues.html ... I updated my pidgin and it works. I think this should go into jaunty repositories. this is an fyi if anyone cares.
<YokoZar1> persia: ^^ ~ ogra
<JohnTeddy> This is for 2.5.5 update to 2.5.7, not many changes except mostly yahoo authentication stuff to fix yahoo. binaries located here: http://pidgin.im/download/ubuntu/
<kees> is anyone available to test bug 336554 in -proposed and comment on the bug?  I'd do it, but I was the fixer.  :)
<ubottu> Launchpad bug 336554 in awstats "Use of uninitialized value $_[0] in pattern match (m//) at /usr/share/perl5/Geo/IPfree.pm line 80." [Low,Fix committed] https://launchpad.net/bugs/336554
<mac9416> Can someone point me to some documentation explaining how apt-get dist-upgrade works?
<ScottK> mac9416: Did you already read man apt-get?
<mac9416> ScottK, unfortunately, I'm on a Windoze machine ATM.
<cjwatson> mac9416: manpages.ubuntu.com
<YokoZar1> If foo-1 and foo-2 both Provides: foo and Conflicts: foo, will installing foo-2 uninstall foo-1?
<cjwatson> type 'apt-get' into the search box, hit "Title"
<cjwatson> YokoZar1: you might need a Replaces: as well, possibly, but yes
<YokoZar1> cjwatson: thanks
<YokoZar1> cjwatson: you mean Replaces: foo I assume
<cjwatson> yes
<cjwatson> YokoZar1: lots of packages use this pattern with mail-transport-agent
<YokoZar1> Thanks, that's exactly what I want then
<cjwatson> lool: I don't suppose you could merge cairo? I don't really know what I'm doing there, but am TIL due to a no-change rebuild
<cjwatson> fta: or you maybe?
<lool> cjwatson: TIL?
<kirkland> james_w: around?
<cjwatson> lool: touched it last
<lool> I'm looking into it
<cjwatson> thanks
<james_w> kirkland: hey
<kirkland> james_w: hey, i've been struggling for several weeks now with vcs-imports
<james_w> of git?
<kirkland> james_w: i'm giving up on LP for the moment and trying to get it working locally, and i'll just cronjob an import/push until LP gets straightened out
<kirkland> james_w: yes
<kirkland> james_w: i'm trying to chase down all the bzr, plugins, dulwich, and such necessary to get this to work
<kirkland> james_w: i'm simply trying to: bzr branch git://git.savannah.nongnu.org/qemu.git
<kirkland> james_w: or bzr git-import git://git.savannah.nongnu.org/qemu.git
<kirkland> james_w: at this point, i think i'm stuck with a version of dulwich that is too old
<kirkland> james_w: i installed from https://edge.launchpad.net/~dulwich/+archive/ppa
<kirkland> james_w: bzr: ERROR: exceptions.ImportError: bzr-git: Dulwich is too old; at least 0.3.1 is required
<cjwatson> I used to have that kind of problem, but my problems went away upon upgrading to karmic
<james_w> I guess you have to install from lp:dulwich
<kirkland> cjwatson: is that directed at me, or lool?
<cjwatson> you
<kirkland> james_w: where do i install that to?
<james_w> setup.py install should do it
<james_w> or just grab the branch and use PYTHONPATH
<kirkland> james_w: okay, i'll try that
<kirkland> james_w: cool, thanks, that gets me a bit further
<genii> Hello. Is there some place .deb pre/postinst pre/postrm scripts get cached and used other than perhaps /var/lib/dpkg/info/packagename.scriptname  ? I had an error in the postrm, manually fixed it there (/var/lib...postrm) which allowed removal. But then after install of the new package with the fix, it seems to be using the old version for some reason.
<cjwatson> no, only /var/lib/dpkg/info
<cjwatson> of course if you installed a new version then dpkg will likely have overwritten that
<genii> Weird.
<genii> cjwatson: I required an -f on an update-rc.d line... made the fix (on another box), rebuilt the deb, scp'd it over and installed... then the postrm somehow reverts to the previous one in /var/lib even after a rm'd it. Maybe scp is caching??
<cjwatson> genii: scp doesn't cache
<cjwatson> I think you almost certainly just made a mistake somewhere
<YokoZar1> pitti: ~ Karmic Wine Integration: were you referring to slower startup by starting clamd at login or slower startup by starting clamd upon opening executable-handler?  clamd takes about 5 seconds to start, but it takes very little memory to leave running and can be started in parallel (eg at login).
<ScottK> Virtually all of the time is spent reading in virus definitions, so the time wil be related to HD speed.
<ScottK>  ... and how much else is going on at the same time.
<YokoZar1> ScottK: would making it a low priority task that ran at login be reasonable?
<ScottK> YokoZar1: I don't know enough about the boot process to know, but since it's reading from the HD the entire time it'll slow other stuff down if one is IO bound.
<YokoZar1> ScottK: also is there a way to tell if clamd is starting up but isn't yet started yet?  We could have it run as the very last thing after the user logs in, and then if they happen to open an executable in the first 5 seconds the script could just wait till it's started
<ScottK> YokoZar1: I think if you call it while it's reading in the signatures it'll just block until it's finished.  I'd test this.
<YokoZar1> ScottK: hmm that sounds like exactly what we want
<ScottK> YokoZar1: Yes, but as I said, I'd test it and make sure.
<genii> cjwatson: Weird. When I have the deb on box1, open and examine the postinst there, is correct. On box2 after I scp it over, timestamp is same as original but extracting the postinst shows it is the previous one.
<pochu> pitti: hi! pkg-create-dbgsym's dh_strip is missing "-k" for the "--keep-debug" option handling
<pochu> pitti: that is, it should be "-k|--keep-debug)"
<pochu> pitti: oh, there's a bzr branch... I'll create my own and request a merge if I have further changes :-)
<pochu> pitti: just started looking at the ddebs project
<pochu> pitti: same for --exclude= and -X
<pochu> pitti: I'll look at creating a branch and requesting a merge ;)
<genii> OK, found the issue. box1 deb is on an NFS mount which hadn't synced
<pochu> huh, are there still packages with debhelper compat 1?
<chrisccoulson> mdke - is there a reason that ubuntu-docs no longer ships a /usr/share/omf/about-ubuntu/about-ubuntu-C.omf file anymore in karmic, or is that a mistake?
<chrisccoulson> cjwatson - just looking at your gnome-session issue. do you see the same issue with the dialog flicker if you logout instead of rebooting?
<ebroder> Any SRU-types around? I have a few bugs that I've been trying to get someone to look at for a few weeks now
 * beuno nudges cody-somerville and runs away
<slangasek> lifeless: I hate freedom because it makes people lazy and stupid, of course :)
<ScottK> slangasek: Would you mind having a look at kubuntu-meta in binary New?  I'm working on getting ready for kubuntu-netbook images early.
<nixternal> pitti: just used ubuntu-bug from the command line for the first time, I think I like it better than the GUI :)
<slangasek> ScottK: I'm traveling today, don't really have the bandwidth to look at that currently
<ScottK> slangasek: OK.  Thanks for lettting me know.
 * ScottK shops for archive admins ....
<ScottK> jdstrand: Could you  have a look at kubuntu-meta for binary New?
 * ScottK notices the time and runs off ....
<jdstrand> ScottK: sure
<ScottK> jdstrand: Thanks.
<jdstrand> ScottK: I'm going to accept it, but kubuntu-netbook doesn't seem to do anything...
<Sarvatt> speaking of metapackages, someone was having a problem with netbook remix not pulling in udev-extras (ubuntu-standard?) so they werent getting permissions set right for dri in karmic
<Sarvatt> https://bugs.launchpad.net/bugs/384934
<ubottu> Ubuntu bug 384934 in xserver-xorg-video-intel "[i945gme] Xorg very slow after upgrade" [Undecided,New]
<ebroder> Is anyone from motu-sru around?
<micahg> will there be another round of importing before the freeze tomorrow or do I need to file a requiest at this point?
<ripps> Hey, can anybody here give me some help, I'm trying to help Qball, the developer for gmpc, to fix his libnotify plugin to properly display album images in his libnotify plugin.
<kirkland> hrm
<kirkland> up-to-date karmic
<kirkland> gdm login, then kicks me out immediately
<kirkland> known issue?
<maxb> kirkland: Intel graphics?
<maxb> try rolling back the latest mesa update
<bryce> kirkland, I've got a fix in my ppa -  mesa - 7.4.1-1ubuntu4
<Chipzz> ripps: pls read the topic
<bryce> kirkland, once it's finished building and someone can verify, I'll be uploading
<kirkland> bryce: thanks
<kirkland> maxb: yes, intel
<bryce> kirkland, people were complaining about how boringly stable X.org had been so far in karmic
<kirkland> bryce: great, thanks for shaking it up some
<kirkland> sheesh
<bryce> hehe
<mathiaz> kees: jdstrand: is it know that apparmor init script fails to reload properly in karmic?
<mathiaz> *known*
<jdstrand> mathiaz: yes-- apparmor hasn't been forward ported to the karmic kernel yet
<kirkland> bryce: ping me if you notice it's done building and i'll test for you
<kirkland> on an unrelated note...
<mathiaz> jdstrand: ok - should I file a bug for it?
<kirkland> karmic seems to be running *very* hot on my thinkpad
<dtchen> existing bug, mathiaz
<kirkland> 60+ degrees hotter
<ajmitch> bryce: are the nvidia 185.x drivers in the PPA liable to make my system crash & burn then, since X.org is so boring? :)
<jdstrand> mathiaz: no, it is well known: bug #375422
<ubottu> Launchpad bug 375422 in linux "apparmor fails to load at startup" [High,In progress] https://launchpad.net/bugs/375422
<dtchen> mathiaz: 375422
<jdstrand> it is being actively worked on
<bryce> ajmitch, sadly no, they should be mind numbingly boring.  We believe they actually make some well loved bugs go away.
<ajmitch> I noticed that the package name was still referring to 180, so wasn't sure if it was wise to upgrade
<bryce> ajmitch, should be fine.  I'm not sure if we're going to s/180/185/ for consistency; need to chat with tseliot about that
<bryce> ajmitch, I'm just waiting on some positive user testing cases and will upload
<ajmitch> bryce: alright, I'll try it out
<NCommander> Is there a good trick to getting USB modules available in the initramfs?
<NCommander> I'm trying to do some debugging in it on ia64, and I find my keyboard is useless there :-/
<bryce> kirkland, amd64 and lpia builds ready.  i386 still in progress.  https://edge.launchpad.net/~bryceharrington/+archive/ppa
<ScottK> jdstrand: I think that's inevitable the first time through since it's recurseive.
 * ScottK prepared to find out I'm wrong.
<dtchen> NCommander: /etc/initramfs-tools/modules
<dtchen> NCommander: regenerate (update) the initramfs afterward
<ebroder> Any motu-sru types around to look at a few bugs? I've had a few waiting for motu-sru review for a few weeks now
<NCommander> dtchen, now, you won't happen to know what voodoo is needed to get /dev/fb0 working on ia64 now would you ;-)?
<dtchen> NCommander: not offhand, no
<maco> ebroder, i think there are only 3 people on the motu-sru team, so that could be why
<maco> dtchen, that team you were supposed to start...did ya?
<dtchen> maco: no
<ebroder> maco: Sounds like they should expand the team, not let bugs fester for weeks/months at a time
<dtchen> it's fairly ineffective without seeding the group with people who actually have upload privileges
<NCommander> ebroder, maco there's been two open slots for ages
<ebroder> I'm kind of frustrated at the moment because I've been practically unable to get anybody to touch my bugs for both SRUs or just normal sponsorship for the last 2 months or so
<maco> NCommander, oh, so we need to convince a random motu to go apply for it?
<dtchen> ebroder: yes, i know well the feeling. that's the idea behind the "ubuntu-reviewers" (name not set) LP team.
<maco> ah! that's the channel missing from my buffer list
<maco> (must find a better name than "buffer" for that in quassel. suggestions?)
<RAOF> Channel?
<maco> motu
<RAOF> I meant: maybe "channel" is a better name than "buffer" :)
<maco> oh :P well they use it for PMs too
<Fenix|work> Greetings...
<Fenix|work> TheMuso, Would you happen to be around?
 * maxb  installs bryce's mesa
<Fenix|work> Does anyone have TheMuso's email address?
<maco> Fenix|work, i'd guess he'd be on in about 12 hours
<maco> thats when i usually see folk from his area on IRC
<DktrKranz> Fenix|work, look at ~themuso on LP
<Fenix|work> yeah, I just thought of that... themuso@ubuntu.com
<ajmitch> maco: closer to 2 hours, it's just past 8am there
<bryce> maxb, possibly there is still one crash (which there is also a patch for, just not enabled in the ppa build yet)
<maco> ajmitch, oh yeah, im still not accustomed to this "awake before noon" idea ;)
<dtchen> bryce: 185.18.14-0ubuntu1~xup~1 WFM on C67/GeForce 7150M
<maco> (slightly kidding...i get up before dawn...which i contend is still night)
<ajmitch> maco: it's a hard life...
<bryce> dtchen, thanks
<maxb> bryce: It's working fine for me. I can't crash it by doing what I could reliably crash 1ubuntu3 by doing
<Fenix|work> Just sent him an email.  We'll see if I get a response. :)
<Fenix|work> Thanks all.  Have a good night.
<bryce> maxb, aha excellent
<kirkland> bryce: installing
<cjwatson> chrisccoulson: I didn't see one with m.Logout(dbus.UInt32(2))
<chrisccoulson> cjwatson - hmmm, that is strange, as it activates the same code path i think. i'll try and recreate this tomorrow when i get the chance
<chrisccoulson> the other thing that can cause the inhibit dialog to appear is a client not responding to the QueryEndSession fast enough
<cjwatson> chrisccoulson: should be pretty easy to recreate with the python snippet I posted and a karmic desktop cd
<kirkland> bryce: fixed
<cjwatson> unless I'm totally on crack of course :)
<bryce> kirkland, sweet, thanks.  Upload coming
<cjwatson> chrisccoulson: (and thanks for looking at it)
<chrisccoulson> cjwatson - i'll have another look at it tomorrow when i finish work
<cjwatson> it's not especially urgent, just seems likely to be a bit ugly at the end of installations
<cjwatson> although even with the ugliness it's well worth killing off the old code
<cjwatson>  23 files changed, 5119 insertions(+), 16381 deletions(-)
<maco> why does http://package-import.ubuntu.com/ not include karmic packages yet?
<james_w> maco: we are transferring over to LP, and trying to keep two imports going at the same time was too much
<maco> oh
<james_w> sorry if that confused you
<maco> james_w, is nothing going into import or is it that stuff-on-lp isnt in import?
<james_w> stuff-on-lp is new branches
<james_w> which will include Debian as well, so they don't share revision history
<james_w> so it wasn't just a case of pushing to two places
<mathiaz> james_w: what's the state of the branches actually?
<james_w> the LP ones are starting to appear
<mathiaz> james_w: where can I find them?
<james_w> we've got what is apparently an LP problem to try and diagnose, but we're pretty much at the point where it's just a case of churning through the packages to import them
<james_w> https://code.launchpad.net/~ubuntu-branches houses them all
<james_w> you can also get to branches from a package from https://code.launchpad.net/<distro>/<distroseries>/+source/<sourcepackagename>
<james_w> the other overview pages are coming
<redvamp128> Okay developers- I have a rather strange issue that involves enlightenment(opengeu) and gnome- I have looked for a room on this and there is none (this is a default 8.04 install)
<redvamp128> I can sign into the window manger just fine-- and then sign back into my gnome-- and it put shortcuts to drives on my default desktop
<redvamp128> It uses thunar-- but why does it not do that when I use the XFCE but does that with that D-E (window manger) any clues?
#ubuntu-devel 2009-06-25
<redvamp128> Or if anyone knows of a room on Enlightenment that might help too.
<\sh> james_w: are you importing the orig.tar.gz sources of our packages in <release>-upstream or do you rely really on upstream tarballs?
<james_w> \sh: the LP branches use pristine-tar, so you don't need to download the upstream tarball in addition
<directhex> NCommander, i have never touched hppa, and my last SPARC was evicted with the help of a crowbar
<jcastro> cjwatson: the grub2 article on LWN was highly informative.
<NCommander> directhex, O_O;;;;;;;;;;;;;
<NCommander> directhex, 1. WTF 2. Huh?
<nixternal> bryce: fyi, your ppa fixes my issues concerning the one bug report I filed a bit earlier today
<bryce> nixternal, uh, which ppa and which bug?  (juggling fixes for bunch of different issues today)
<nixternal> lol
<nixternal> intel, crashing back to gdm after the kernel updates in karmic
<nixternal> bryce: bug #391797
<ubottu> Launchpad bug 391797 in xorg "[Karmic] Crashes after login - kernel 2.6.30-10.12 (dup-of: 391808)" [Undecided,New] https://launchpad.net/bugs/391797
<ubottu> Launchpad bug 391808 in mesa "[i945] Xorg crash in intel_renderbuffer_set_region() on Dell XPS 1330" [High,Fix released] https://launchpad.net/bugs/391808
<nixternal> ya, couldn't tell if it was a dup as browsing LP with w3m isn't fun :)
<bryce> oh yeah, that fix is uploaded to karmic earlier today
<nixternal> the mesa packages?
<nixternal> after upgrading those packages my machine went bonkers
<nixternal> 7.4.1-1ubuntu3 killed me, 7.4.1-1ubuntu4 from your PPA seems solid
<bryce> nixternal, heh, we're up to mesa_7.4.1-1ubuntu6 now
<nixternal> hahha, groovy
<ajmitch> it's hard to keep up with all this development
<nixternal> maybe I should actually read my karmic-changes messages from time-to-time :)
<ajmitch> it's often helpful to read that list
<nixternal> OK, America's Got Talent is on, time to go laugh at silly Americans
 * ajmitch won't comment on that :)
<bryce> nixternal, oh you could do that by reading the mesa change log too, it turns out ;-)
<ScottK> cjwatson: I've made (I think) the needed changes to tasksel for Kubuntu Netbook Edition.  I'd appreciate it if you could have a look over it in bzr before it's uploaded.  http://bazaar.launchpad.net/~ubuntu-core-dev/tasksel/ubuntu/revision/1413
<YokoZar> what package is the KDE menu editor?
<twb> I'm creating a (private) package that assumes the target host is hardy.
<twb> Can I add a dependency on a particular version of base-files or something, so that my package will not be installable on newer/older LTS systems?
<dholbach> good morning
<amitk> morning everyone, dholbach
<dholbach> hiya amitk
<pitti> Good morning
<pitti> YokoZar: erm, you want to start clamd at login? that seems unappropriate to me, can't we start it on demand when its needed the first time?
<YokoZar> pitti: if we do that, then we have to wait the 5 seconds when that app is starting up
<pitti> YokoZar: do you need the system daemon, or can you just invoke it as an user without the daemon?
<pitti> YokoZar: that's not too bad, since you won't start it anyway, right? you just say "checking for viruses" and then give the lecture about why you can't start it? or did I misunderstand something?
<YokoZar> well either way it's got to load the virus definitions
<pitti> sure, but only for a newly downloaded program?
<pitti> clamd isn't something which we need running all the time on a desktop
<Hobbsee> morning pitti!
<YokoZar> pitti: this is true, if it takes 5 seconds to read the dialog then we might as well be loading clamd then and have a little spinning "scanning for viruses" thingy
<pitti> pochu: p-c-d's dh_strip does handle -X
<pitti> pochu: and also --keep-debug
<pitti> YokoZar: you could certainly start the dialog first, display the progress bar, and then start clamav?
<pitti> YokoZar: I suppose the actual virus check will also take a fair while, so you'd need a progress bar anyway?
<YokoZar> pitti: the actual check is very fast once clam is running
<pitti> pochu: dh compat 1> yes, a few :(
<YokoZar> as in, so fast we could do it before showing the dialog
<pitti> YokoZar: I suppose that again depends on the size of what you are checking?
<YokoZar> probably, I guess I haven't tested 400 megabyte installers...
<pitti> nixternal: ubuntu-bug just brings up apport-{gtk,kde,cli} as well; you mean you used apport-cli?
<YokoZar> pitti: how about leaving clamd running after the dialog is closed?
<pitti> YokoZar: why would you?
<pitti> it's just wasting memory, and you probably won't need it again anytime soon?
<pitti> YokoZar: can you please add some work items to the blueprint as well?
<YokoZar> pitti: I did, at the bottom of the wiki page
<pitti> YokoZar: they shold be a little more granular, these two that I added were just examples
<StevenK> pitti: Can you check if I'm good to upload ubuntu-meta?
<YokoZar> pitti: my thought about needing it again was if we had a clamav integration with Wine and it then wanted to scan more files (eg a whole CD), but I guess if it's for downloaded things then it's a one shot deal
<pitti> YokoZar: can it time out after N minutes of being unused?
<YokoZar> oh, that's a good question, I'll ask ScottK
<pitti> StevenK: hm, apparently udev 143 is stalled; if you need to update urgently, we could revert the seed change for now
<StevenK> pitti: No, it's okay.
<StevenK> pitti: It isn't urgent, it's just on my plate to do.
<YokoZar> pitti: I'll add more work items, note that clam starts when dialog starts (and ends when dialog closes or some timeout thereafter).  Was there anything else?
<pitti> YokoZar: there were some other questions in my previous review, but you might already have addressed them
<Peaker> Hey - I wanted to discuss the issue of sudo.  I think the association of a pseudo-tty with a remembered password (ala sudo's strategy) is OK for remote ssh connections and for local/physical tty's.  But I think its silly that an X server (representing a real screen/keyboard, probably a user) does not also have its own "remembered sudo".
<ebroder> Isn't there a blueprint about that...?
<ebroder> https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-no-sudo
<Peaker> well, that's about removing sudo altogether. I have a less radical idea, perhaps a temporary solution:
<Peaker> I think maybe there should be a gnome/KDE applet for the panel or such that lets you type in the password once globally for all of X (or un-type it, if you leave the computer) - and then all gnome-terminals or anyone who wants root access can "sudo" without needing a password
<Peaker> Perhaps "sudo" shall launch an X application to perform its deed - which can check with X or the applet whether you're allowed to do it
<Peaker> its really silly for me to type in my password 5 times in the same minute, to prove to 5 different terminals on the same physical screen that I know the password
<Peaker> on the other side of the coin, its also kind of silly that if two terminals end up on the same pseudo-tty by accident, they also don't need a password!  I think sudo should only remember physical tty's and X screens
<soren>    /win 21
<soren> Whoops
<dholbach> Laney, bigon, seb128: if empathy is in main now and built with webkit, would it make sense to build gimp with webkit (like debian) again?
<dholbach> also if clutter0.8 and champlain are in main now, would it make sense to build eog and gnome-games with the new options?
<dholbach> bigon: did the indicate patch not apply any more?
<pitti> dholbach: both are in universe still
<dholbach> oh ok
<dholbach> excusez-moi :)
<dholbach> I thought empathy had already moved to main
<seb128> dholbach, empathy is in universe, and we don't plan to use champlain
<pitti> empathy still needs some gstreamer bits sorted out, and there's no MIR for champlain
<dholbach> seb128: why not? :)
 * dholbach isn't up-to-date on the desktop world
<seb128> dholbach, because ENOCDSPACEFORITANDCLUTTERSTACK
<dholbach> boohooooooo :-((((
<seb128> I'm open to suggestions
<seb128> but we have an explosion of depends there
<seb128> and CD are still the same
<pitti> seb128: you mean there's hope that we don't need to put webkit on the CDs?
<seb128> not sure how we will add couchdb, clutter, webkit, etc
<seb128> pitti, webkit we will, clutter maybe not
<pitti> yeah, the entire empathy stack is quite large, plus the planned new online services packages
<seb128> though gnome-games will require it
<seb128> at least for some games
<seb128> time to stop putting openoffice on the CD? ;-)
<dholbach> will we manage to drop some of the old libraries?
<dholbach> like the old sourceview, gnomeprint and stuff?
<seb128> nothing which take space
<seb128> yes, those cumulated will give some 700k each
<dholbach> woohoo!
<wgrant> How big is Erlang+CouchDB going to be?
<seb128> dholbach, ie we spare 3*700k and add several 3meg libraries instead
<dholbach> still it'd be worth to dump that stuff :)
<pitti> wgrant: erlang was recently built without debug symbols, so erlang-base is "down" to 3.5 MB
<seb128> right!
<wgrant> pitti: Ah, not too terrible.
<pitti> wgrant: slightly better than the original 25 MB of dependency chain :)
<pitti> it still has a couple of extra dependencies, though
<wgrant> pitti: Right, that's around what I'd remembered it being.
<wgrant> I was scared a
<pitti> 5.2 MB right now
<wgrant> .. about what was going to have to be cut to fit it.
<pitti> it at least moved from the "scaary, no way" into the "ugh, but possible" range
<pitti> I hope we can trim it some more still
<pitti> so far, the biggest potential space savings are: split out gnome help into langpacks (some 50 MB?), drop gimp help from CD (20 MB), recent tomboy with identical file symlinking (5 MB)
<bigon> dholbach: I've dropped it for now because of cassidy review of the patch
<wgrant> pitti: That's an awful lot of space you've got, then.
<pitti> the first depends on a LP feature, though
<wgrant> Right, so I saw.
<pitti> gimp help takes some serious reorganization of language-support-*, but that's on the plan
<pitti> robert_ancell, seb128: do you know if it's possible to have gimp start the online help if it isn't locally installed? it already opens an external browser anyway
<dholbach> ArneGoetje: are there any plans around scim / ibus this cycle?
<robert_ancell> pitti, no, sorry
<seb128> pitti, no idea about this one
<dholbach> bigon: ok
 * pitti purges gimp help and tries
<pochu> pitti: good morning. this is what I mean: http://pastebin.com/f70d9d462
<pitti> robert_ancell, seb128: well, it almost works OOTB; it does open the help, just not in firefox, but in (ugh) w3m
<seb128> lol
<pitti> but that should be fixable?
<seb128> pitti, what issue are you trying to solve?
<pitti> pochu: aah; that makes sense
<seb128> pitti, I though you already made it open the webbrowser in jaunty to avoid webkit on CD
<pitti> seb128: having an option to not have gimp-help-common installed by default
<seb128> pitti, should be easy to change the called URL to be the web one
<pitti> seb128: I'm not saying that I'd particularly like it, but it's always good to have some fallback optinos at hand, especially for alphas
<pitti> seb128: as I said, it already falls back to the online documentaiton if it isn't locally installed
<pitti> it just opens w3m instead of firefox
<seb128> ok, should be easy enough to fix
<seb128> we need a way to put contributors tasks on a todolist ;-)
<pitti> both xdg-open and gnome-open DTRT here, so I'm not sure what gimp uses
<pitti> could anyone please try to open gimp help and check whether it's ffox or w3m?
<seb128> pitti, firefox on karmic
<seb128> but I do have the local help installed
<pitti> hm, so it might be local misconfiguration here
<seb128> opening firefox is wrong though since I use epiphany-browser
<wgrant> Using Karmic, with local help installed, it complains that it doesn't have the help viewer, and then opens the help in epiphany-gecko.
<wgrant> Which isn't my default; firefox-3.5 is.
<pitti> lol
<pitti> so, there does seem to be a strange browser problem here
<wgrant> There does.
<pitti> I don't think it's related to having the help installed or not
<chrisccoulson> it isn't getting it from /etc/alternatives/x-www-browser is it?
<pitti> since it needs a browser either way
<geser> gimp opens firefox for me too (but first complains that the gimp help browser isn't installed)
<pitti> aaah
<pitti> lrwxrwxrwx 1 root root 20 2009-06-15 13:08 /etc/alternatives/x-www-browser -> /usr/bin/firefox-3.5
<pitti> I have that purged again
<pitti> yay alternatives
<wgrant> pitti: x-www-browser matches for me too.
<seb128> lrwxrwxrwx 1 root root 17 2009-06-15 22:16 /etc/alternatives/x-www-browser -> /usr/bin/epiphany
<wgrant> Damn.
<pitti> shouldn't it just use xdg-open?
<seb128> pitti, gvfs-open rather
<pitti> and only fall back to sensible-browser if it's not available?
<pitti> seb128: I thought GIMP was gtk-only, not GNOME? or is it?
<pitti> well, either way
<seb128> pitti, gvfs-open is gio which is glib
<seb128> pitti, well it use the same mechanism than gvfs-open, ie gio
<seb128> not the actual gvfs-open command
<seb128> but that should open the same thing that gvfs-open do
<chrisccoulson> should it not use xdg-open? xdg-open should be modified to wrap gvfs-open on gnome rather than gnome-open perhaps
<pitti> seb128: ok, after fixing my broken alternatives link, it works fine again
<pitti> so wrt. having help installed, if we just dropped it, it would be bearable
<seb128> it opens http://docs.gimp.org/2.6/fr/index.html by default there
<seb128> I don't have the local documentation installed
<pitti> right, here as well (just the German variant)
<pitti> yay gimp
<lesshaste> hi
<lesshaste> I have been told to enable boot logging and post the output ( https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/389930 ) but this feature has not worked for ages and does nothing in jaunty.  Do they just mean /var/log/dmesg ?
<ubottu> Ubuntu bug 389930 in grub "grub menu skipped after shutdown" [Low,New]
<lesshaste> because if so I can't see how that could help as it never says anything about grub
<cjwatson> jcastro: oh, it was published? good
<lesshaste> any help much appreciated
<seb128> RainCT, hi
<RainCT> Hey seb128
<seb128> RainCT, what is the current status on zeitgeist packaging for karmic?
<RainCT> seb128: Zeitgeist has undergone a complete database rewrite since UDS, and now we plan to release 0.1 Friday next week. I'll start pushing snapshots to the PPAs on ~zeitgeist (engine) and ~gnome-zeitgeist (GUI) within the next days and push the package into Debian/Ubuntu once 0.1 is out
<seb128> RainCT, ok thanks, looks like we should wait a bit before trying to get it in karmic then
<seb128> RainCT, let me know when it's ready if you need review to get in universe
<RainCT> Yes, a week ago the engine was completely unstable and yesterday we finished an API change, so there wasn't much point in getting it in yet.
<seb128> ok
<RainCT> Okay, I'll keep you offer in mind. Thanks :).
<geser> I've an executable (pdftk) that is linked against /usr/lib/gcj/itext-2.1.5.jar.so. Is there a better way to get dh_shlibdeps get this library found than passing "-l/" as an option?
<geser> it looks a little bit ugly to me
<\sh> MOINS
<\sh> argl..caps no good
<trip0-nb> who's the right guy to talk to about maximus in UNR ?
<trip0-nb> I've got 2 screens and maximus only seems to be running on one of them
<dholbach> trip0-nb: njpatel I guess
<cjwatson> ScottK: your Kubuntu netbook stuff now names a "netbook-ship" seed in STRUCTURE which doesn't exist, which causes Kubuntu CD builds to fall over
<trip0-nb> njpatel ping
<ScottK> cjwatson: Ouch.
 * ScottK looks
<ScottK> cjwatson: It exists now.  Sorry about that.
<trip0-nb> hmmm... looks lime maximus only respects the :0.0 display
<trip0-nb> you need to launch a second instance for any other display
<trip0-nb> I can do that with the command line, but I can't via this startup script: http://pastebin.com/m4968d092
<cjwatson> ScottK: thanks
<trip0-nb> for some unknown reason...
<ScottK> pitti: Yesterday I created a kubuntu-netbook metapackage.  It needs to get promoted to Main (It's built out of the same source as kubuntu-desktop).  I was wondering if you would just promote it or if you want a bug on that?
<nixternal> pitti: ya, used apport-cli, it was nice, refreshing, lovely :)
<janmejay> i have a jaunty box running chroot jail, when i try to start mysql server (using /etc/init.d/mysql start) it waits for about 10 seconds and then exits after failing to start it
<janmejay> is anyone aware of such problems
<janmejay> ?
<janmejay> when i try mysqld_safe start, i get Starting mysqld daemon with databases from /var/lib/mysql
<janmejay> mysqld_safe[21012]: started
<janmejay> STOPPING server from pid file /var/run/mysqld/mysqld.pid
<janmejay> mysqld_safe[21018]: ended
<janmejay> any ideas? (it works brilliantly on lenny (debian 5.0.1)
<Chipzz> janmejay: this is not a bug-reporting channel
<Chipzz> file a bug on launchpad
<janmejay> sure, just wondering if anyone has seen a similar issue
<Chipzz> also
<Chipzz> #ubuntu-server would probably be a better place to ask
<Chipzz> and it most likely is due to some filesystem (like /proc) not being mounted
<mvo> Keybuk, zul: i take the rsync merge (if you don't mind)
<zul> mvo: fine with me
<Ampelbein> mvo: hi, would you mind if i merge python-adodb from debian?
<mterry> cjwatson, what's the preferred solution for oem-config (if built out of ubiquity source) having a lower version than it used to?  bump ubiquity's version?  epoch?  a custom binary version (never done that before, but assume it's possible)?
<mvo> Ampelbein: fine with me, go ahead
<Ampelbein> ok, thanks.
<Keybuk> mvo: sure
<mvo> Ampelbein: and let me know if you need sponsoring for it
 * mvo forwards the rsync teardown changes to debian as well
<pitti> ScottK: promoted
<pitti> nixternal: yeah, all that desktop crap :)
<pitti> meh, something in Karmic broke USB yesterday
<pitti> and I already wasted two hours suspecting my hardware and hassling the Dell support line about a broken docking station (internal USB works fine)
<cjwatson> mterry: maybe bump ubiquity's version to 1.99, with the expectation of making it 2.0 for karmic
<cjwatson> 1.99.0 rather
<pitti> and now I found out that something during boot messes up USB
<mterry> cjwatson, Sure
<cjwatson> the others are possible but less preferable IMO
<pitti> does that sound familiar to anyone?
<cjwatson> mterry: BTW I expect that oem-config can have the old timezone map removed too, just as I recently did in ubiquity. Would you like me to do that in the oem-config tree?
<mterry> cjwatson, eh, don't bother.  I'm pretty far along.  You can see a rough version of the merge at ~mterry/ubiquity/oem-config-merge
<ArneGoetje> dholbach: we will use ibus as default IME for Karmic
<cjwatson> mterry: filesystem layout looks fairly reasonable, haven't looked in depth though
<cjwatson> mterry: you'll want to merge with ubiquity trunk sooner rather than later, as the removal of src/ and resulting autotools changes is a big delta
<mterry> cjwatson, basically it's just ubiquity exact and if we're running with the script name 'oem-config' we set an environment variable that controls a few knobs (but as few as possible)
<dholbach> ArneGoetje: maybe we'll save some space by dropping the other stuff to universe? :)
<mterry> cjwatson, removal of src?  whoops, did I do that?
<cjwatson> no, I did :-)
<mterry> cjwatson, ah
<cjwatson> mterry: environment> makes sense, if you've figured out how to merge the UI ...
<ArneGoetje> dholbach: I'm not so sure about that
<cjwatson> mterry: I was fed up of ubiquity-frontend-gtk being architecture-dependent
<cjwatson> and there's really no excuse for it now
<mterry> cjwatson, Yeah, the UI is mostly the same.  Only big change was the language screen was different.  I still have yet to hide a few options when in oem-config mode
<cjwatson> yeah, I saw you had a separate glade file for that
<cjwatson> what about the cases where component/script logic is different?
<cjwatson> did you just deal with that using that environment variable?
<mterry> cjwatson, there are a few cases where I call a different script from the component based on the env var
<mterry> cjwatson, but by and large, not too many differences
<cjwatson> yeah, just a few painful ones but I agree not many
<cjwatson> tzsetup-wrapper is intentionally a bit different, IIRC
<mterry> cjwatson, there's upstream work to reduce that delta (like allowing passing a $ROOT var to scripts)
<cjwatson> console-setup-apply is entirely different
<mterry> cjwatson, but I'm deferring that obviously until we nail this down
<cjwatson> yeah, one thing at a time :)
<mterry> cjwatson, but yah, agree that this is best merged soon.  asides from oem stuff, this is all I'm focusing on
<dpm> ArneGoetje: I had missed the fact that scim was going to be replaced by ibus in Karmic. Is this the associated blueprint/spec ? -> https://blueprints.edge.launchpad.net/ubuntu/+spec/ibus-improvement/
<mterry> cjwatson, oh, I see, you were saying best for me to merge with trunk, not other way
<cjwatson> right
<cjwatson> since I see you have diffs to various bits of autotoolsery and most of that can probably vanish
<mterry> cjwatson, well, as long as you keep changing the layout, I want to merge with trunk asap.  ;)
<ArneGoetje> dpm: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-input-methods
<cjwatson> mterry: I'm done for the moment. :-)
<cjwatson> just had a burst of enthusiasm
<mterry> cjwatson, I'm sure we can dampen that with some more specs
<dpm> ArneGoetje: thanks, subscribing
<cjwatson> mterry: hey, the online help work I had scheduled for d-i took me a whole half a day
<cjwatson> (modulo whatever feedback I get, the GTK frontend, actually writing the help text ...)
<cjwatson> ttx: regarding the Java-related uploads I did yesterday; is there anything else I can do to help you get Eucalyptus sorted out for main and the CD?
<mterry> cjwatson, (btw, I used the bzr-merge-into script to save history of imported files and not change the bzr format;  pretty hot)
<cjwatson> mterry: I heard you mention that; not something I'm familiar with directly, but it sounds cool
<ttx> cjwatson: at that point, no. We are very much waiting on Eucalyptus to give us a more precise idea of what buildtime and runtime deps will be on the upcoming release
<mterry> cjwatson, I was too dumb to figure out bzr join.  :)  Kept giving me an error, so I looked elsewhere
 * mterry heads back to oem-config land
<cjwatson> mterry: so you merged into a subdirectory and then renamed stuff back out of the subdirectory?
<mterry> cjwatson, yah
<ttx> cjwatson: the work that was done so far is based on reasonable assumptions on what they will require in all cases
<cjwatson> mterry: makes sense - and you checked that 'bzr log <filename>' showed the history?
<mterry> cjwatson, yeah, if you add --include-merges (and without it, it prompts you to use it if you want merge info)
<cjwatson> ttx: basically I'm trying to figure out if there's any way I can unblock myself on my cloud installer spec
<cjwatson> ttx: or if I should switch it to a later milestone and pull something else forward
<cjwatson> mterry: sounds very cool
<dpm> ArneGoetje: I'm having a look at the upstream ibus code at http://github.com/phuang/. Which is the default UI frontend which will be used in Karmic? I'm trying to see if it's translatable.
<al-maisan> who should be listed as the maintainer of the 'pycairo' package?
<seb128> ubuntu core dev?
<seb128> there is a sponsoring request waiting for it
<al-maisan> thanks seb128!
<seb128> before you start on an update if you want plan to do one
<al-maisan> doko: do you mind if I take a stab at 'python-geoip'?
<doko> al-maisan: no, please go ahead, I'm staying away from syncs and merges for this cycle
<al-maisan> doko: thanks.
<ArneGoetje> dpm: client/gtk2/
<dpm> ArneGoetje: thanks, yes, I see it now
<cjwatson> ScottK: you added kubuntu-netbook as a flavour to tasksel, but that seems a bit odd since the netbook stuff is part of the main Kubuntu seeds, isn't it? the UFLAVOURS list is a list of seed collections ...
<jcastro> hyperair: are you working on getting lp:385801 upstream?
<hyperair> hmm?
<hyperair> er.. lemme see what that is.
<seb128> bug #385801
<ubottu> Launchpad bug 385801 in hundredpapercuts ""Write in this folder" is confusing terminology" [Low,Fix released] https://launchpad.net/bugs/385801
<hyperair> oh that!
<hyperair> i need to hijack the upstream project =\
<hyperair> but i haven't really figured out how i should go about it
<hyperair> upstream devels have gone missing
<cjwatson> ScottK: it causes ubuntu-seeds.pl to fail, so I'm going to adjust it
<pitti> arrgh
<pitti> superm1: I found out what "broke" my docking station yesterday
<pitti> superm1: two hours of debugging and pestering the Dell support line about a docking station replacement helped :)
<pitti> superm1: hid2hci -> b0rkage
<pitti> superm1: do you have some minutes to debug this?
<seb128> pitti, how did it break?
<pitti> as soon as that udev rule becomes active, it breaks _all_ USB ports on the docking station
<pitti> i. e. keyboard, mouse, etc. stop to work
<pitti> it "just happened" during normal work yesterday, thus I suspected hw failure
<pitti> but it seems I had a dist-upgrade running in the background which pulled in the new udev-extras
<seb128> pitti, you called support before trying a jaunty CD to make sure it was not the distro? ;-)
<pitti> the internal ports work fine
<pitti> and the external didn't
<pitti> so I suspected the docking station
<seb128> ok I see
<seb128> I don't get the issue there
<pitti> I'll have to apologize tomorrow when they call back
<pitti> seb128: dockign station as well?
<seb128> yes
<seb128> and usb mouse and keyboard
<seb128> dist-upgraded during lunch today
<pitti> -KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
<pitti> +ATTR{bInterfaceProtocol}=="02", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
<pitti>      RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
<pitti> I'm pretty sure that's it
<pitti> anyway, will file a bug with details
<pitti> superm1: bug 392144
<ubottu> Launchpad bug 392144 in udev-extras "[Dell Latitude D430] recent hid2hci upgrade breaks docking station USB input devices" [High,New] https://launchpad.net/bugs/392144
<cjwatson> StevenK: I've committed Task-Name support to tasksel, along with UNR seed support
<pitti> superm1: ok, I added a comprehensive analysis and proposed patch, but I need you to verify the intention and test the new rules
<kees> mornin!
<kees> slangasek: so, re: 391761, can't we just pass-through the NPROC setting like before?
<tseliot> pitti: the fix in jaunty-proposed for bug 373711 works well
<ubottu> Launchpad bug 373711 in libxi "_XiGetDevicePresenceNotifyEvent can't be used from C++" [Undecided,Fix committed] https://launchpad.net/bugs/373711
<ogra> seb128, every seen something like that ? http://94.209.196.70/Screenshot.png
<ogra> (it seems to happen only after login, the login manager is teh right way round)
<seb128> ogra: no, seems a decorator bug
<ogra> ah, compiz ?
<ogra> i'll try to get him checking
<ogra> seb128, hmm, that would influence the panel icons too ?
<seb128> no
<ogra> (beyond flipping all fonts etc)
<seb128> is that locale specific?
<ogra> he's gone in #ltsp anyway now ... cant ask him to test stuff ... but it looks weird, especially since the login manager is proper
<mterry> slangasek, heyo, at some point can you give an opinion on bug 385949?  In particular the appropriate place to run pm-powersave
<ubottu> Launchpad bug 385949 in pm-utils "ACPI Cleanup: Remove ac.d and battery.d" [Undecided,New] https://launchpad.net/bugs/385949
<billybigrigger> is sound in flash still being worked on does anyone know?
<billybigrigger> a few weeks ago i was told it would be fixed when a new ia32libs was updated
<pitti> hey kees
<kees> hi pitti!
<slangasek> kees: the purpose of this patch is to reset limits on every session, to avoid inheriting lower-than-intended limits when doing something like su; we could pass them through, but that would still leave the NPROC value clobbered in some cases
<kees> slangasek: hrm, so you it sounds like there is no way to get the kernel-set limits then?
<kees> s/you/
<kees> does grub2 not support triggers correctly?
<cjwatson> kees: s/correctly/at all/. It's on the list
<kees> cjwatson: heh, okay.
 * zSoilworker o/
<slytherin> kenvandine: ping. Do you plan to do a rebuild of ekiga? there are lot of NBS (http://people.ubuntu.com/~ubuntu-archive/NBS/) dependencies of ekiga
<kenvandine> slytherin, haven't thought about it
<kenvandine> slytherin, for karmic?
<slytherin> kenvandine: yes
<kenvandine> so it just needs a rebuild?
<slytherin> kenvandine: I haven't checked. Do you want me to check?
<superm1> pitti, wow, great work with that debugging.  i'll be sure to take a look at the proposed rules as soon as I can nab that hardware once more.
<slytherin> can anyone please give back pygtk2 on sparc?
<slytherin> oops, it is pygtk
<slangasek> kenvandine: correct; the "default" limits have long since been discarded from the process state in the case we care about
<slangasek> kees: ^^
<slangasek> kenvandine: oops
<slangasek> mterry: I think we want pitti to comment on that part; mine is not an expert opinion
<mterry> slangasek, OK.  pitti, can you look at bug 385949 when you get a chance?  In particular, the decision of where and when to call pm-powersave?
<ubottu> Launchpad bug 385949 in pm-utils "ACPI Cleanup: Remove ac.d and battery.d" [Undecided,New] https://launchpad.net/bugs/385949
<slytherin> can anyone please give back pygtk on sparc?
<cjwatson> slytherin: done
<slytherin> cjwatson: thanks
<ScottK> cjwatson: Thanks for fixing tasksel.
<ScottK> pitti: Thanks for taking care of kubuntu-netbook promotion.
<NCommander> ScottK, we have kubuntu-netbook now?
<kees> slangasek: so it seems reasonable to emulate the kernel's estimations for the dynamic limits?
<slangasek> kees: yes, we already have to do this type of shadowing for other limits :(
<pam> Hi. Is there a wiki page describing the build process of the distro (build framework)?
<cjwatson> pam: err. not really in its entirety (it's rather complex, and the distro is not just built all in one piece, but incrementally over time). https://wiki.ubuntu.com/UbuntuArchitecture may help
<cjwatson> could an archive admin binary-NEW parted for me?
<cjwatson> libparted1.8-12 belongs in main
<pam> Thanks cjwatson, I will look into it. I am currently building a distro (roughly debootstrap + come customization) using a set of Makefile but it is a pain to maintain. Wondering if there are better ways to do that (scons? shell scripts? ...).
<cjwatson> pam: not sure I can really help you, maintaining a distro on a rolling basis for years the way we do is very different from doing customisation work
<pam> Right, my job is more integration rather building the packages
<cjwatson> stuff like https://help.ubuntu.com/community/InstallCDCustomization and https://help.ubuntu.com/community/LiveCDCustomization is the best I'm aware of, but you're probably ahead of that already in terms of automation
<cjwatson> make, scons, and shell are equivalent in terms of expressive power when it comes to automation; in fact I'd consider make rather superior if any dependencies are involved. My only awareness of scons is that some of my fellow developers complain that build failures that involve it are all but impossible to debug :)
<cjwatson> if substantial dependencies aren't involved, make (or scons) is probably the wrong tool for the job
<pam> heh
<pam> Well, they are some dependencies to resolve (if I am updating the kernel, the build needs to rebuild the squash for instance). But most of my Makefile are phony targets and do a bunch of `cp -fau'.
<pam> I am not really leveraging the power of Make besides dependencies checking, really.
<pam> Make does a poor job of updating the base distro too. If I update my list of packages, I roughly need to make clean && make squash again (chrooting and dpkg -i would be an option but I would like to avoid being root on the build nodes).
<cjwatson> slangasek: ^- parted NEW, if you're available? I have a dependency chain hanging off this that I'd like to be able to upload before going on holiday :)
 * cjwatson naughtily NEWs libparted1.8-12 for himself in the cause of getting to bed at a reasonable hour. It's pretty obvious and I've checked that it seems sane ...
<ScottK> NCommander: We do (sort of).  Currently it looks identical to regular Kubuntu, but that will change.
<ebroder> How unusual is it for somebody to be appointed to MOTU without going through ubuntu-contributors first?
<ScottK> ebroder: Quite common.
<slangasek> cjwatson: ah, sorry - just blame any bugs in the NEWed package on me, then :)
<cjwatson> slangasek: heh
<cjwatson> I already caught the worst bug (debian/patches not applied!) as a result of an amd64 build failure
<ion> USERID=`id | cut -f2 -d= | cut -f1 -d\(`; PIDS=`ps -eo pid,ruid,args | grep $USERID | egrep "mouseTrap[.]mouseTrap" | grep -v grep | awk '{print $1}'`
<ion> *shiver
<cjwatson> dtchen: can xfonts-scalable just be synced? the only change is for smooth upgrades from 6.06, which doesn't seem likely to be needed any more
<kirkland> bryce: so is kms the sweetness that gives me 128 columns on my tty's now?
 * kirkland 's wife just read that last sentence over his shoulder and thinks he was talking dirty
<Laney> haha
 * bryce winks at kirkland
<RAOF> Nice big terminals, you know what I mean?
<bryce> kirkland, yes and the toad dances the little lady, day after tomorrow
<ajmitch> now what was that system load monitor which was slightly controversial in debian?
<kirkland> bryce: heh
 * bryce fixes aspell and hunspell to accept "Ubuntu" as correct
 * kirkland hugs bryce 
<kirkland> that's only 5 years too late
<directhex> ajmitch, hot-babe
<kirkland> bryce: soren has an old bug on that one
<ajmitch> bryce: didn't you upload that a day or two ago?
<bryce> kirkland, yeah I built off of that
<kirkland> bryce: nice
<bryce> ajmitch, I did aspell the other day, and hunspell today
<ajmitch> ah right
 * ajmitch sponsored maco's upload of aspell earlier which added blogs & blogger to the list you added :)
<bryce> soren had the aspell stuff pretty much done, dunno why that didn't get uploaded, but I expanded on it a bit with Kubuntu, Shuttleworth, etc.
<bryce> ajmitch, ahh cool
<bryce> ajmitch, maco could hit hunspell too with those
<kirkland> bryce: was that a 100-paper-cuts bug?
<kirkland> bryce: if not, it should have been, imho
<ajmitch> it is a little bit funny typing away in firefox & not having words like Ubuntu recognised on jaunty :)
<bryce> kirkland, yeah, noticed it on the list, but it's one that's bothered me before
<bryce> kirkland, what's a bit amazing is that there wasn't the infrastructure in place for us to add more words to the dictionaries easily
<kirkland> bryce: odd ... is there now?
<bryce> yep (actually that was most of the work)
<bryce> I didn't want to do it as a patch to the dictionary because for aspell the wordlist is compressed so a patch wouldn't work
<bryce> for hunspell, you also have to update the first line, which is a count of total words in the dictionary
<bryce> so in both cases patching would just be recipe for patch bitrot
<lifeless> so you wrote a dict updater?
<bryce> so instead there's now a simple extrawords.txt file you can toss more words into, and the build process regenerates the dictionary appropriately
<bryce> lifeless, I'm sure it could be improved on a lot, but it seems to do the job
<lifeless> bryce: nice
#ubuntu-devel 2009-06-26
<ebroder> Does anybody have any recommendations for docs on writing PolicyKit-aware apps?
<dtchen> cjwatson: yes, xfonts-scalable can be synced.
<wip> hello everyone, i really just need to know if a new rt-kernel is coming out soon. (or maybe i have to recompile it myself, cause there's no plan for rt release)
<wip> i just need a quick reply on this matter...
<dtchen> wip: #ubuntu-ports or #ubuntustudio-devel. also, quite likely.
<wip> dtchen: thank you!
<lifeless> doko: https://bugs.edge.launchpad.net/bzr/+bug/392355
<ubottu> Ubuntu bug 392355 in bzr "C extensions placed in wrong directory" [Critical,Triaged]
<lifeless> doko: any thoughts?
<TheMuso> dtchen: I assume you are aware of why I can't do a test release of pulse 0.9.16-test1?
<bjsnider> how can i stop dh_shlibdeps from adding a specific dependency?
<StevenK> Stop linking against that library
<bjsnider> it's not that simple
<bjsnider> i need it as a build-dep
<lifeless> bjsnider: thats orthogonal
<bjsnider> but it is then automatically being added as a dependent package when in fact it isn't
<lifeless> test via ldd
<lifeless> I bet it is linked against
<bjsnider> how would i do that?
<lifeless> ldd <binary>
<bjsnider> well, i don't have the binary
<bjsnider> but are you saying the source code itself is asking for that file?
<lifeless> what are you building?
<ebroder> bjsnider: dh_shlibdeps looks through the resulting package for all binaries in that package, finds all libraries they link against, and adds those libraries as automatic dependencies
<bjsnider> but when you say libraries they link against, that's int he source code, is that right?
<bjsnider> in other words, it's not because of anything i put in the control file
<lifeless> bjsnider: *what are you building* - a binary or a library, or both?
<bjsnider> both
<lifeless> so, use ldd on the binary
<lifeless> or the library
<bjsnider> i don't have them
<lifeless> how can you not have them?
<lifeless> you're building them in your debs
<bjsnider> yeah
 * ajmitch doesn't understand why this dependency shouldn't be added
<bjsnider> it isn't a dependency
<bjsnider> the program doesn't need it to run
<StevenK> According to ldd, it does
<Pici> Are you sure?
<bjsnider> it should be a suggests
<bjsnider> wrong. i know better than ldd
<lifeless> then unpack the deb, and check with ldd
 * ebroder disbelieves
<lifeless> its very simple
<bjsnider> i think this thing is just too...what's the word
<lifeless> 'correct'
<bjsnider> immature
<StevenK> Haha
<bjsnider> unpolished
<bjsnider> alpha
<StevenK> I call bullshit
<lifeless> bjsnider: have you checked with ldd, or are you just speculating?
<lifeless> bjsnider: and do you know what ldd actually does?
<bjsnider> well, let me download the thing...
<bjsnider> of course not
<bjsnider> if i knew that it did i wouldn't be in here
<lifeless> man ldd gives a reasonable description
<lifeless> note that the *docs* are 8 years old. God knows how old ldd itself is :)
<ajmitch> probably about 30+
<StevenK> Instead you come in here and accuse our tools of being immature and unpolished
<lifeless> ajmitch: Actually, I suspect its from when a.out was superceded
<ebroder> Sounds like a bad Western in the making. "For as long as there have been shared libraries, there's been an ldd..."
<lifeless> ajmitch: but I don't recall the yar
<ajmitch> lifeless: probably, I wouldn't expect it to go all the way back to prehistory
<ajmitch> if the application is mistakenly linking against a shared library but uses none of its symbols, then that app needs fixed (iirc)
<lifeless> thats right
<persia> Right.  That's a build system issue,
<lifeless> libtool can cause this
<lifeless> as can scons
<lifeless> and $homebrew
<lifeless> but the first thing to do is to gather data
<lifeless> find out which of the binaries||libraries are dragging in the dependency. Thus ldd
 * lifeless goes off to write code
<ajmitch> dpkg-shlibdeps throws up warnings in that case
<bjsnider> what would such a warning look like?
<RAOF> "useless dependency on $LIB could be dropped if $BINARY didn't needlessly link against it"
<lifeless> its entertaining when dpkg throws that up and is wrong
<bjsnider> ah, yes i recall seeing those when i was running debuild
<lifeless> (because typedefs)
<bjsnider> i don't think this is my problem
<lifeless> bjsnider: well, do the ldd test, gather data and report back; I'm sure we can provide more hints
<bjsnider> i can't do the ldd test
<ebroder> bjsnider: Then we can't help you
<persia> bjsnider, Why can't you do the ldd test?
<bjsnider> i uninstalled these packages
<bjsnider> bringing them back in would break my system
<bjsnider> i could build them here but that would take awhile
<ebroder> Do you have the .debs?
<bjsnider> yes
<persia> So?  Download it (as a file).  unpack it (man dpkg-deb).  run ldd on the files.
 * ajmitch would like to know what the package is & what the unneeded dependency is
<maco> ajmitch, i dont see bryce's modified hunspell...
<bjsnider> i'm talking to the developer here and i found out the problem
<ajmitch> maco: sorry, hunspell-en-us was the one he uploaded
<maco> ajmitch, ah ok
<bjsnider> i talked the developer out of linking to that library.
<bjsnider> thank you for all of your guidances
<maco> ajmitch, alright, attached a hunspell-en-us debdiff to that bug as well now. feel like another upload?
<ajmitch> maco: to the same bug, which was closed already? :)
<maco> ajmitch, marked it as affecting both packages
<ajmitch> ah good
<ajmitch> let me fetch the source
<dtchen> TheMuso: yes, i've spent the last few hours getting 2.6.31-rc1 running on my systems to fix rtkit packaging
<TheMuso> dtchen: Oh ok cool.
<cjwatson> dtchen: synced, then, thanks
<vkfwb> I am looking for someone who can help me facilitate an update to Ubuntu package of fwbuilder; I am the author and project lead, our upstream package has been updated and we'd like to see Ubuntu packages updated too
<dholbach> good morning
<ScottK> vkfwb: Since we generally get fwbuilder from Debian, our preferred method would be to get the package updated in Debian and then ask someone in #ubuntu-motu about a sync from Debian once that's done.
<ScottK> cjwatson: I've taken a shot at updating livecd-rootfs (in bzr, not uploaded).  Given the hash I made of tasksel, I'd particularly appreciate it if you'd take a look at it.
<StevenK> ScottK: I tried to update tasksel at one point and ran screaming, if I recall.
<ScottK> I didn't run and I should have.
<ScottK> cjwatson straightened it out.
<cjwatson> ScottK: can't say offhand whether it will work :-), but it looks OK
<StevenK> cjwatson: I note UNR has disappeared completly from the tasks, I need to wait for cron.germinate to land?
<cjwatson> tasksel is easy to update, but perhaps only once you know how. Make the changes you want (whether in the seeds or in ubuntu-seeds.pl), then 'rm -rf ubuntu-tasks && make ubuntu-tasks'
<cjwatson> StevenK: oh, err, yeah, I guess you do
<cjwatson> sorry
<StevenK> ScottK: I have a livecd-rootfs change waiting, I can upload it along with your changes?
<cjwatson> maybe that was a slightly premature update
<ScottK> StevenK: Yes.  Please.
<StevenK> Waiting for cron.germinate, anyway
<cjwatson> well, that sounded like it'd happen today
<StevenK> Oh well, UNR dailies have probably been broken for a few days anyway
<cjwatson> feel free to temporarily revert the relevant bits of tasksel if you urgently need to
<cjwatson> I'm on holiday today, just stopping in while the baby's feeding
<StevenK> cjwatson: No, I just need patience. :-)
 * StevenK mangles the livecd-rootfs changelog
<StevenK> ScottK: Leave your distro in the changelog set as UNRELEASED, too
<ScottK> StevenK: Didn't I?
<cjwatson> he did, second commit
<vkfwb> ScottK: the package has been updated in Debian
<StevenK> Oh, right
<vkfwb> ScottK: should I ask on ubuntu-motu then ?
<ScottK> vkfwb: Yes.
<cjwatson> hmm, did anyone do an autosync yesterday?
<vkfwb> ScottK: ok, thanks
<StevenK> cjwatson: It was my archive day, and I didn't, since yesterday was effectively DIF
<StevenK> cjwatson: I can handwave and run one now ...
<cjwatson> vkfwb: has it? I don't see anything newer than 3.0.5-2 in Debian unstable
<cjwatson> which is what we have in karmic
<cjwatson> StevenK: still Thursday in your timezone :-)
<ScottK> Still Thursday some places.
<StevenK> cjwatson: Actually, it's 3pm Friday in my timezone
<cjwatson> oh
<cjwatson> sorry, mixed up then
<StevenK> +10
<cjwatson> but I don't think it matters all that much ...
<ebroder> Oh - random question. How can I find out why zephyr 3.0~beta.2483-2 was autosynced? It's only in unstable, not testing. Not that I'm complaining - older versions didn't build without krb v4
<StevenK> ebroder: We pull from unstable
<ebroder> Oh, right. I was confusing unstable and experimental
<StevenK> cjwatson: I have my finger hovering over Enter, now is the time to object to an autosyncer run
<StevenK> And I can't see that Scott did two commits to livecd-rootfs
<ScottK> StevenK: The 2nd one was only several tens of minutes ago.  Dunno if that's relevant
 * StevenK runs bzr up
<cjwatson> StevenK: run it, then we can check the .changes files before you press enter on flush-syncs :)
<StevenK> cjwatson: Or selectively dump a few things before flushing :-)
<cjwatson> indeed
<StevenK> cjwatson: Done, there doesn't look to be anything evil
<StevenK> cjwatson: But a second opinion is appreciated.
<cjwatson> StevenK: could you do contrib and non-free for completeness?
<ajmitch> StevenK: so you proved me wrong when I told someone that it was DIF already :)
<StevenK> ajmitch: I can't help it if cjwatson overrules what I decided :-)
<ajmitch> heh
<ajmitch> TGIF, now I can get some stuff done :)
<pitti> Good morning
<ajmitch> hey pitti
<StevenK> Morning pitti
 * pitti waves to downunder
<ajmitch> that's a long way to wave
<cjwatson> well, it *is* DIF, but we should do an autosync as close to the end as possible, IMO
<cjwatson> StevenK: everything there looks OK
<StevenK> cjwatson: -C contrib pulled in nothing
<pitti> FYI, I did one yesterday
<cjwatson> kernel-package is the only remotely scary one, but we don't use it for our kernel builds anyway
<pitti> including non-free and contrib
<cjwatson> oh, you did?
<pitti> yeah, it was DIF, so I had the same thought as you :)
<cjwatson> in that case maybe we *shouldn't* do an autosync now. I was working on the assumption that it hadn't been done yesterday.
<cjwatson> StevenK: cancel my overruling :-)
<StevenK> cjwatson: I'm happy to clear them out, and then whistle that we did nothing
<pitti> I guess by now we need another new-binary-debian-universe run
<pitti> StevenK: if you could do some NEW today, that would be appreciated; there's some stuff like policykit-1 which we need soon
<pitti> (I'm the uploader, so I can't review myself)
<StevenK> pitti: I spent an hour doing NEW yesterday during my archive day :-)
<StevenK> pitti: But I'll happily review policykit-1 for you.
<cjwatson> StevenK: yeah, pretend I never said anything I guess ;-)
 * ScottK looks a bit at debian-cd and decides it's bedtime.
<StevenK> ScottK: debian-cd is scary, yes :-)
<ScottK> Yep.  I'll save that step for when I'm not way short on sleep (it's nearly 2 am here).
<StevenK> pitti: There looks to be some wierd control chars in your debian/changelog that less doesn't like
<pitti> StevenK: no locale installed on cocoplum, I guess?
<pitti> might have been a â
<pitti> I often see that corruption for maintainers with accents in the name
<StevenK> Ahhh, then I'll deal
<pitti> it's policy compliant :)
<StevenK> pitti: Given it's a version bump, it looks good.
 * StevenK pushes the shiny accept button
<pitti> it's by and large a new upstream version only
<pitti> StevenK: thanks! (and now perhaps policykit-1-gnome? :-) )
<pitti> same story
<StevenK> pitti: I don't know ... you already owe me beer :-P
<slangasek> pitti: "less -r"; has less to do with locales being installed than with charset configuration
<pitti> heh
<StevenK> pitti: -gnome also accepted
<pitti> \o/ thanks
<StevenK> pitti: I'm look at the list for stuff in universe that UNR wants -- libmono-i18n-west2.0-cil is a little suprising, since tomboy pulls that in
<StevenK> pitti: And hwtest-gtk -- should UNR be using something else?
<slangasek> tomboy pulls it in how?
<StevenK> i   tomboy                Depends    libmono-corlib2.0-cil (>= 1.2.2.1)
<StevenK> i A libmono-corlib2.0-cil Recommends libmono-i18n-west2.0-cil
<StevenK> Indirectly
<slangasek> ah; so it's an existing components-mismatches issue?
<StevenK> It looks to be in components-mismatches, yes
<pitti> StevenK: mono was recently split into several smaller libraries
<pitti> well possible that some of them got NEWed to universe
<StevenK> pitti: Happy to promote libmono-i18n-west2.0-cil
<pitti> StevenK: hwtest-gtk> please use checkbox-gtk
<StevenK> pitti: Okay
<StevenK> pitti: gnome-themes (the source) is in main, but gnome-themes (the binary) is in universe
<pitti> superm1: ok, got the rules working now; thanks for testing
<pitti> StevenK: known, and intended
<pitti> we only want gnome-themes-selected
<pitti> does somethign pull it in?
<StevenK> Yeah, UNR directly
<StevenK> I'll change the seed there too
<pitti> ah, thanks
<StevenK> pitti: app-install-data-commercial ?
<cjwatson> -partner
<StevenK> Right, I thought so
<cjwatson> wow, you have some ancient stuff there
<cjwatson> -partner was renamed in like gutsy
<slangasek> anyone else seeing launchpad problems at the moment?
<cjwatson> not I
<pitti> WFM
<StevenK> pitti: Last one, if I'm allowed to promote libmono-i18n-west2.0-cil is hplip-cups
<pitti> StevenK: promotion> sure, splitout
<pitti> StevenK: binary-only promotion is generally fine
<cjwatson> ... except gnome-themes ;-)
<pitti> should be checked for sensibility, of course, but doesn't need MIR stuff
 * cjwatson goes back to bed
<pitti> cjwatson: "back"? are you in the US?
<cjwatson> no, just got woken by baby feeding
<pitti> aah
<pitti> see you later then!
<StevenK> pitti: Promoted, thanks
<cjwatson> and decided to come and do a couple of uploads I ran out of time for last night
<cjwatson> not today you won't, I'm on holiday :)
<pitti> ah, enjoy
<dholbach> cjwatson: enjoy :)
<StevenK> pitti: In regards to hplip-cups:
<StevenK> i   ubuntu-netbook-remix Recommends hplip
<StevenK> i A hplip                Recommends hplip-cups (>= 3.9.6)
<pitti> seems fine to me
<StevenK> pitti: But hplip is in main, and hplip-cups is in universe
<pitti> looks like a recent and intended splitout to me
<pitti> StevenK: "looks fine" -> I meant "for promotion"
<StevenK> Oh
<StevenK> Right, then let me do that
<StevenK> pitti: Also done, thanks!
 * StevenK peers at tix in component-mismatches and his list
<sianis> hi
<sianis> fta: could you please look at this? https://answers.launchpad.net/gwibber/+question/75068
<soren> bryce: My aspell changes from way back didn't get uploaded because I wasn't core-dev at the time (probably not even MOTU either), and noone else cared enough to sponsor it.
<lifeless> kirkland: still aroun?
<chrisccoulson> cjwatson - i'm struggling to recreate this issue you're seeing on the live CD. when i restart, i don't see the inhibit dialog flash up briefly.
<chrisccoulson> i don't know if its possible for you to start a failsafe xterm session from the live CD, then manually start "gnome-session --debug", with the output saved to some permanent storage
<chrisccoulson> if that's possible, then it might be worth trying to recreate it like that as there should be some indication in the log why it happens
<lifeless> pitti: is your laptop fan running slower/not at all in karmic?
<pitti> lifeless: no noticeable difference
<pitti> it is running pretty often, the 430 tends to heat up a lot
<lifeless> pitti: mine isn't, machine is thermal-tripping I think
<pitti> StevenK: could I ask you to bin-NEW policykit-1?
<pitti> lifeless: hm, if only I knew which bit was responsible for controlling the fan (shouldn't the computer do that itself?)
<lifeless> acpi_fan I thought
<lifeless> whats
<lifeless> cat /proc/acpi/thermal_zone/THM/temperature
<lifeless> for you
<lifeless> its odd, trip_points for me is 99C
<lifeless> I'm going to start watching it
<pitti> $ cat /proc/acpi/thermal_zone/THM/temperature
<pitti> temperature:             68 C
<pitti> and fan is running
<soren> Mine's 53 C
<pitti> $ cat /proc/acpi/thermal_zone/THM/trip_points
<pitti> critical (S5):           99 C
<lifeless> soren: is your fan running, and do you have a D430 ?
<soren> ...but "acpi -V" says: Thermal 0: ok, 58.5 degrees C
<soren> lifeless: Fan running. D430, yes.
<lifeless> ok, my fan is either _super_ quiet or fucked
<lifeless> I can't feel a breeze
<lifeless> Thermal 0: ok, 51.5 degrees C
<soren> lifeless: My fan is virtually always running, and I can both hear and feel it.
<soren> Well, that's not too bad.
<lifeless> do you have anything in /proc/acpi/fan/?
<soren> I don't know when the fan usually kicks in.
<soren> Nope.
<pitti> lifeless: it's empty here as well
<lifeless> thanks
<pitti> hm, did edge just go down?
<soren> pitti: Works for me.
 * pitti shrugs and disables redirection
<nellery> would any of you mind posting your full output of acpi -V?
<nellery> or just acpi -c
<hyperair> http://pastebin.com/f36ef454e
<nellery> thanks.
<hyperair> hmm i wonder if my CPU can really hit 105 degrees and not burn
<hyperair> as of now, it overheats and hard powers down at ~80
<nellery> mine has heating problems as of Jaunty...
<nellery> regularly about 55 degrees and goes up to 81ish degrees when I do things such as build packages
<hyperair> mine's always been ~55 idling
<hyperair> and 75-80 when compiling
<hyperair> make -j2 can cause a hard shutdown
<apw> can anyone elighten me as to the meaning of an CHROOTWAIT on a PPA build?
<apw> cjwatson, i wonder if you could look at this failed PPA build, if i am reading it right i suspect it may be affecting all builds: http://launchpadlibrarian.net/28408818/buildlog_ubuntu-karmic-amd64.linux_2.6.31-1.13apw1_CHROOTWAIT.txt.gz
<apw> it appears that two common build deps are colliding
<apw> ahhh i see the problem, its not general at least ... panic  over
<soren> How do I specify a base revision during a merge?
<soren> Whoops
<soren> Wrong channel.
<soren> (How did I end up in here?)
<directhex> soren, you turned left at Albuquerque?
<soren> I didn't.
<soren> Should I have?
<ogra> cprov, if the project cant be renamed or deleted, i'll just leave it idling and create a new one, thats fine with me ... i just didnt want to leave a mess in LP
 * ogra wonders why we dont have some --help to man converter ... i.e. calling "cmd --help | helptoman > cmd.manpage" that creates a skeleton manpage with all the options and descriptions --help spits out for cmd
<hyperair> ogra: help2man
<ion> :-P
<hyperair> ogra: Laney generated banshee's manpage that way =p
<ogra> hyperair, that works for sucha case ?
 * ogra goes and tries
<hyperair> it's not exactly like that
<ogra> i always thought that converts files
<hyperair> but essentially it takes the output of --help and generates a manpage
<hyperair> i think you give it a command, and it runs command --help, grabs output from that, and dumps a manpage
<hyperair> you can even specify another argument to use in place of --help
<Laney> it gives you a good starting point
<hyperair> mmhmm
<ogra> yeah, looks ok
<ogra> thanks !
 * ogra wishes KVM would recognize his external display on boot
<ogra> err
<ogra> s/KVM/KMS/
<ogra> damned abreviations
<geser> does somebody know how I can figure out, why I'm missing the ACLs e.g. on the sound device files in karmic? it's getting nasty to issue a setfacl when I want to use my smart card reader or hear music
<ion> Wait, what? https://wiki.ubuntu.com/KernelTeam/Specs/KarmicSSD?action=diff&rev1=11&rev2=12 âUsing the most appropriate log structured file system, such as ext4.â
<hyperair> ext4 is log structured now?
 * ogra points ion to cking_, 
<cking_> call it a typo.
<hyperair> heh'
<Ng> can I run apport for a single process rather than enabling it system-wide?
<Ng> nm
<pitti> Ng: not that easily, I'm afraid, since it hooks into the kernel
<Ng> pitti: yeah
<pitti> Ng: you don't need to enable it in /etc, though, you can do sudo force_start=1 /etc/init.d/apport start
<Ng> oh nice
<kirkland> lifeless: hi there, i'm back now
<kirkland> lifeless: sorry i missed earlier, was away for the evening
<lool> Geez empathy pulls the whole geoclue stuff
<ogra> cprov, "The name 'rootstock' has been blocked by the Launchpad administrators."
<cprov> ogra: let me check
<ogra> thanks
<cprov> ogra: anything matching '^root' is blacklisted.
<ogra> gah
<ogra> lool, ^^^^ :P
<ogra> cprov, any way around that ?
<ogra> it took us two weeks of discussion to find the name ...
<cprov> ogra: no, unfortunately
<ogra> sigh, ok
<cprov> ogra: you can always use 'project-rootstock' :-/
<ogra> yeah, i'll do that
<cjwatson> apw: chrootwait on linux> looks bad; check the two packages to see if there really is a file conflict. I'm on holiday today though. I suggest looking for infinity or somebody else on #is if it needs manual recovery.
<apw> cjwatson, panic was avoided, it was from my own previous package, but luckil;y prevented that being uploaded into the archive and getting the problem for real!
<Keybuk> heh, I just found the wiki page that explained all of the silly release names I gave dpkg
<cjwatson> apw: oh, that was your PPA - OK
<apw> what was odd, was i had deleted those packages so didn't expect them to be usable, so i thought it had to be main archive packages.  keybuk disabused me of that notion and it got fixed in time
<apw> it was a lot of luck though, as that might have gotten uploaded to the real archive if i'd not had that overlap, so a bit of luck on our side for a change
<pitti> mterry: \o/
<mterry> pitti, that was easier than I thought
<pitti> mterry: so, instead of adding this to acpi-support, we should just grab that patch into dk-p right away
<pitti> (IMHO)
<pitti> and clean up acpi-support further instead
<mterry> pitti, Yeah, I'm patching my acpi branch now
<pitti> mterry: want me to upload new dk-p?
<mterry> pitti, yeah, please.  Thanks
<pitti> mterry: uploaded
<mterry> pitti, cool
<asac> anyone has a bridge setup in /etc/network/interfaces and could post it?
<asac> thx
<soren> asac: What do you want it to do? I have several.
<soren> asac: Should it be connected to a real interface, or is it for virtual networking only?
<asac> soren: paste all with a quick explanation
<ogra> soren, dont ! else NM will grow bridge support quickly !!!
<asac> yay
<ogra> :)
<asac> no chance to keeping it out of server soon ;)
<ogra> haha
<ogra> and soren is at fault :P
<soren> asac: http://paste.ubuntu.com/204307/
<soren> asac: Apologies for typos, if any. It's not copied from anywhere, I just typed it in.
<soren> ogra: I've been shouting for bridge support in network-manager for a long time.
<lool> asac: http://paste.ubuntu.com/204308/
<lool> soren: NM upstream blogged about that coming up soon
<lool> (briding and ipv6)
<soren> lool: About time :)
<soren> asac: Is that useful, or do you need more explanation?
<asac> soren: in that example, what sets the IP address of extbr0?
<asac> soren: oh its dhcp
<asac> so thanks. all fine.
<slangasek> mterry: hopefully I'll catch up on bug #385949 today
<ubottu> Launchpad bug 385949 in pm-utils "ACPI Cleanup: Remove ac.d and battery.d" [Undecided,Fix released] https://launchpad.net/bugs/385949
<mterry> slangasek, cool.  things fell into place today, so everything's ready, but there's no rush
<slangasek> mterry: btw, your DEP5 conversion is incorrect - Thom May is not a copyright holder on this package
<slangasek> yep - I was more or less waiting for the pm-fwibble part to be addressed before changing acpi-support, now I have no excuse not to finish the merge :)
<mterry> slangasek, ah, whoops on the DEP5.  I thought I just ported the old copyright notices, but adjust as you see fit
<slangasek> mterry: the old line said 'Author', not 'copyright' :)
<soren> asac: Any time.
<mterry> slangasek, so either he assigned his copyright or it should have said "inspired by" not "author", eh?  cause if he was an author, it's automatic copyright
<mterry> slangasek, but I don't know his involvement; that's just why I put him down
<slangasek> mterry: no, it's work-for-hire
<slangasek> he worked for Canonical
<slangasek> as the email address suggests
<mterry> slangasek, ah, k.  my bad
<slangasek> bryce: do we have the new intel-gpu-tools jbarnes mentions in https://bugs.freedesktop.org/show_bug.cgi?id=22359 ?  I have a fresh crash here
<ubottu> Freedesktop bug 22359 in Driver/intel "[i945GM] freeze in karmic (no kms)" [Major,New]
<pitti> nixternal, Riddell: jockey currently uses pykdeuic to build *.ui into *.py and ship the latter, while apport currently ships *.ui and loads them directly; what approach is more standard and recommended in KDE nowadays?
 * ScottK wonders if agateau knows?  ^^
<agateau> ScottK: pitti: using uic to build *.ui into *.cpp :/
<ScottK> Thanks.
<agateau> I am not sure there is a recommended way for Python ATM
<agateau> there aren't that much Python code in kdesvn for now
<agateau> I for one always turn the ui into py
<pitti> agateau: ... and for Python? :-)
<pitti> agateau: so, loading them at runtime is discouraged?
<pitti> ok, thanks
<agateau> but that maybe my C++ background
<pitti> nixternal's apport KDE port loads them directly, so I wondered
<agateau> I believe we can say using pyuic or uic is more common
<agateau> since even C++ app could load them directly
<agateau> and very few kde apps do so
<pitti> slangasek: I meant that most of the event scripts in acpi-support are probably redundant nowadays, since all other distros have these fixed in the kernel?
<slangasek> pitti: yes, *most* of them are, but I'm not going to go ripping them all out when it's possible to tell which ones are redundant by reading what they do
<slangasek> i.e., I'm not going to have my wireless toggle pulled out from under me
<pkt> what is the deal with konq-plugins?
<pkt> the konq-plugins source package produces both konq-plugins and a number of standalone plugins
<ScottK> pkt: #kubuntu-devel is a better channel for that question.
<pkt> now e.g., konq-plugins and konqueror-plugin-searchbar conflict with eachother
<pkt> oh, there is a kubuntu-devel? sorry :)
<Fenix|work> Greetings and salutations!
<slangasek> kirkland: give me a design that lets us separate critical auth logs from non-critical ones...?
<lool> kirkland: Why not do a freshness check on update-motd data on login and refresh it if needs be?
<lool> Would that be too slow?
<kirkland> lool: depends on the consumers of update-motd
<kirkland> slangasek: Jun 26 10:10:01 t61p /USR/SBIN/CRON[14584]: (root) CMD ([ -x /usr/sbin/update-motd ] && /usr/sbin/update-motd 2>/dev/null)
<kirkland> slangasek: that seems more appropriate to log in a cron log
<kirkland> slangasek: rather than /var/log/syslog
<kirkland> slangasek: and /var/log/cronlog could be asynch
<slangasek> kirkland: that's not the PAM log in question
<kirkland> slangasek: oh?
<kirkland> slangasek: which one?
<slangasek> Jun 26 09:10:01 dario CRON[6777]: pam_unix(cron:session): session opened for user root by (uid=0)
<slangasek> Jun 26 09:10:06 dario CRON[6777]: pam_unix(cron:session): session closed for user root
<kirkland> slangasek: okay, question for you ...
<Fenix|work> is anyone involved with dmraid here?
<kirkland> slangasek: what if i added update-motd [--enable-cron|--disable-cron|--enable-inotify|--disable-inotify] options, where the cron ones would add/remove a symlink at /etc/cron.d/update-motd which pointed to the configuration in /usr/share/update-motd
<kirkland> slangasek: and something similar for the inotify bits
<kirkland> slangasek: would that sort of modification of /etc by a utility be acceptable?
<kirkland> slangasek: you could tweak your config with:  update-motd --disable-cron --enable-inotify
<slangasek> kirkland: acceptable, but feels kinda rube goldberg, and I would never run that command by hand on my system
<kirkland> slangasek: which might tell you "iwatch: command not found;  sudo apt-get install iwatch"
<kirkland> slangasek: that would only be there until we had an inotifyd in main that update-motd could depend on
<kirkland> slangasek: at which point, the default becomes inotify
<kirkland> slangasek: we could alternatively have a config file and an init script
<kirkland> slangasek: /etc/update-motd.config has METHOD=cron|inotify
<slangasek> kirkland: I just don't think any of that is worth the effort, because it's only the default behavior that interests me.
<slangasek> if I'm going to deviate from the defaults, I don't need a command to do that - I can just rip out the package and/or the cronjob
<kirkland> slangasek: true
<bryce> slangasek, yep they're in karmic now (in universe)
<kirkland> slangasek: i could make update-motd a proper daemon
<kirkland> slangasek: and kill the cronjob
<slangasek> bryce: ok; what's the relevant version number?
<slangasek> kirkland: again, why is that worth doing when the proper solution is 6 months away?
<kirkland> slangasek: what do you suggest, then for karmic?
<slangasek> kirkland: accept that I'm going to continue to be cranky about it? :-)
 * kirkland tries waaaaay to hard to please users
<bryce> intel-gpu-tools | 1.0.1-0ubuntu1 | http://archive.ubuntu.com karmic/universe Packages
<bryce> there's apparently a new version but I've not pulled that in yet
<slangasek> bryce: right, the new version is what jbarnes mentioned
<Keybuk> kirkland: maybe I'm missing something, but this really doesn't seem like it's something that _has_ to land for karmic?
<kirkland> Keybuk: no, not at all
<Keybuk> are there genuinely omg-critical problems caused by update-motd not being as quite up-to-date as it could be?
<kirkland> Keybuk: i don't think that's the issue
<Keybuk> what's the issue?
<kirkland> Keybuk: i think the issue is the cronjob that wakes up the disk to write the pam log
<Keybuk> how's that any different to anything else?
<Keybuk> an inotify daemon is going to wake the disk up <g>
<Keybuk> if people don't want their disk woken up for writes, they can turn laptop-mode on
<Keybuk> or disable syslog
<slangasek> "disable syslog" - meh
<slangasek> Keybuk: the issue is that when you have the cronjob, you have a guaranteed disk wake-up once every 10 minutes just to write the synchronous log entry to /var/log/auth.log, whether or not update-motd has anything to do
<slangasek> I am not asserting this is omg-critical
<Keybuk> Upstart will have exactly the same issue though
<slangasek> upstart is going to call pam_open_session() once every 10 minutes?
<Keybuk> slangasek: it'll call pam_open_session() whenever it needs to run something as a specific user
<Keybuk> so if update-motd is running as non-root, it'll still do it
<slangasek> er, but the idea is that update-motd should only be called when there's something to update?
<Keybuk> right
<slangasek> so that should be less frequently than the current 10-minute cycle
<Keybuk> sure
<slangasek> then that satisfies my need for beauty :)
<Keybuk> please tell me cron isn't doing pam_open_session() for things in /etc/cron.d _just_ to source /etc/environment
<Fenix|work> Has anything changed in dmraid in the last couple of months?  Ubuntu now sees my ASR array with a different name that's padded with lots of spaces and won't mount the partitions.
<kirkland> Fenix|work: possible TheMuso could help, but he's likely gone for the weekend
<slangasek> Keybuk: no, it's doing it because that's the right thing to do when starting a session of any sort as another user
<slangasek> it also calls it for pam_limits... :)
<Keybuk> slangasek: shall we debate whether things in /etc/cron.d are the root user's cronjobs, or system cron jobs
<Keybuk> where root user cronjobs should obviously be run under a PAM session
<Fenix|work> kirkland, I sent him an email but received no response.  I don't want to file a bug in launchpad because I don't think it's a bug... but my home server is kinda screwed now as it won't boot.  My array went from being 'asr', 'asr_1 and 'asr_5' to 'asr_OS             ', 'asr_OS             1' and 'asr_OS             5'.  It's really wierd.
<Keybuk> while system cron jobs arguably shouldn't be? :p
<slangasek> Keybuk: cron.d/ follows the crontab syntax that includes specifying a username, and root isn't special-cased
<slangasek> (yes, we shall debate this :-)
<kirkland> Fenix|work: it's probably okay to just file a bug;  he'll mark it invalid if it is
<Keybuk> slangasek: do you think it should behave that way?
<Fenix|work> kirkland, dumb question here, but I haven't been able to find an answer to it.  Is there any way to rename a dmraid array? :)
<Fenix|work> if I can rename it, then I can leav TheMuso alone... when he's awake, I'm sleeping. :)
<Keybuk> slangasek: Upstart makes a distinction between things that are "system" and things that are "user's"
<slangasek> Keybuk: I'm uncertain.  Conceivably, pam_open_session() could be used to apply settings (such as ulimits) to root cronjobs that aren't meant to apply to the cron daemon itself
<Keybuk> since it wouldn't make any sense to call pam_open_session() when starting apache, for example
<hyperair> hmm so i hear that a Scott was singing eye of the tiger O_o
<Keybuk> then again, Upstart also allows things like limits to be specified in the job
<slangasek> blech :)
<Keybuk> blech?
<ogra> hyperair, the other scott
<hyperair> which Scott?
 * Keybuk doesn't sing
<slangasek> Keybuk: as if pam_limits wasn't confusing enough, without the possibility of interaction with upstart job settings
<Keybuk> slangasek: oh, that's easy ;)
<Keybuk> slangasek: pam settings override upstart if the job calls for a pam session
<slangasek> there's nothing easy about pam_limits :(
<Keybuk> the idea is that you specify the default sane environment in init
<slangasek> anyway, I think I'd be ok with a cron implementation that skipped PAM sessioning for root jobs, as long as we got the Debian maintainer on board as well so behavior isn't gratuitously different between the two
<Keybuk> and PAM thus applies policy
<slangasek> well, ok
<slangasek> note that one of the things our pam_limits does is reset all limits to the kernel default, though
<Keybuk> slangasek: probably a better way would be just to have upstart open pam sessions for cronjobs from /etc/crontab and /etc/cron.d
<slangasek> before applying any other settings from /etc/security/limits.conf
<Keybuk> and not open pam sessions for temporal jobs specified in /etc/init
<Keybuk> slangasek: how does it know what the kernel default is?
<slangasek> it encodes it :P
<Keybuk> because one thing I found quite quicky is that the kernel default is not the same as what you get when you reset the settings ;)
<slangasek> and then every few months I get bug reports telling me the kernel has changed :P
<Keybuk> ahh :p
<slangasek> "reset"?
 * Keybuk decides not to worry about PAM interaction for now
<cjwatson> pitti: thanks, fixing that ubiquity bug now
 * cjwatson contemplates running py_compilefiles on everything at build time
<kees> slangasek: what about having some crackful early-start process write ot /var/run with kernel RLIMIT defaults it will read?
<fta> doko, is binutils-gold usable on lpia? seems broken here
<fta> doko, dpkg-divert: `diversion of /usr/bin/ld to /usr/bin/ld.single by binutils-gold' clashes with `diversion of /usr/bin/ld to /usr/bin/ld.real by lpia-wrapper'
<fta> doko, from http://launchpadlibrarian.net/28419299/buildlog_ubuntu-karmic-lpia.chromium-browser_3.0.191.0~svn20090626r19361-0ubuntu1~ucd1_FAILEDTOBUILD.txt.gz
<slangasek> kees: would be simpler than the current behavior, but adds a dependency on an external process for correct operation of pam_limits; I'm ambivalent
<kees> slangasek: yeah; I like the idea of it working with whatever the kernel decides to do, making PAM kernel-version-agnostic (at least in this regard), and it could maybe be just a quick init-script.  perhaps PAM could fall-back when the file doesn't exist?  hrm.
<kees>  /var/run/no,really...limits.conf
<slangasek> kees: I'm operating on the theory that where limits differ between kernel versions this is due to bugfixes, so tracking the latest kernel behavior is preferred
<kees> slangasek: hmm, okay, I can accept that.  the trouble is noticing when it changes.
<Sarvatt> whats the proper way to adjust module parameters and add/remove them upon plugging in or going on battery power if ac.d and battery.d are removed from acpi-support? i've been adjusting the txpower and enabling power save for wifi and removing webcam/nic modules through scripts in there
<nhandler> cjwatson: When you get a chance, could you update http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ ? It is still for version 3.8.0.1ubuntu4
<brainsonfire> hi, i hope someone here might have an idea on this issue. my usb mouse doesnt work in jaunty (tried 2 different laptops), but it works in gutsy
<brainsonfire> here my Xorg.0.log        http://pastebin.com/m39d73628
<brainsonfire> xinput recognizes 2 devices when i plug it in, first one being a mouse, second one a keyboard (?)
<brainsonfire> the mouse works for a split second then stops but the light keeps glowing
<brainsonfire> mouse shows up in lsusb
<brainsonfire> hal-devices shows 3 devices
<brainsonfire> i have no clue how to debug/influence this behaviour
<brainsonfire> ill try installing xserver-xorg-input-evdev and -mouse from karmic
<slangasek> mterry: did you forget a bzr push?  I still see pm-powersave in your acpi-support branch
<slangasek> mterry: I'll merge up what you have so far, but wait for confirmation before uploading
<mterry> slangasek, acpi-support still calls pm-powersave in the no-power-manager case
<mterry> slangasek, just a fallback
<slangasek> ok
<slangasek> mterry: btw, svn revision 54 of DEP5 includes arbitrary changes that were not publicly discussed, and have been reverted
<slangasek> mterry: please use a better one :)
<slangasek> s/better/newer/
<mterry> slangasek, ah, will re-examine the spec
<James_P> hey guys
<mterry> slangasek, trying to be helpful with that dep5 conversion, didn't mean to make so much work  :)
<slangasek> mterry: well, these are precisely the issues that have held up the dep5 stuff generally :/
<mterry> slangasek, man, it's weird that the recentchanges feed is for all DEPs; doesn't seem scalable
<ScottK> mterry: It might more productive to not bother with conversion until there is a stable format to convert to.
<mterry> ScottK: Yeah...  didn't want to wait for fossilized spec, but thought it was more stable than it was
<James_P> I *know* this channel specifically isn't for support, but I have a strange problem, and you're welcome to tell me to leave. I'm quite comfortable with a command line though, and I thought it may be a kernel upgrade causing it
<James_P> It's just, my mouse doesn't work. It's a USB mouse, lsusb identifies it, and catting /dev/psaux shows nothing - any hints?
<mterry> James_P, try #ubuntu
<mterry> James_P, that is the official support channel
<James_P> it is indeed, i've helped out a fair few people there in the past with various things. however, i was just hoping for some hints as to how the kernel detects the mouse and maps it to /dev/psaux
<mterry> James_P, I don't know, myself.  best I have to is to look at /dev/input/* stuff too
<James_P> mterry, thanks, i'll check that. thank you :)
<fta> doko, apparently, i can't build ffmpeg with ld gold, it fails in configure when trying gcc, the binaries are created in 644 mode (without x)
<slangasek> Keybuk: I thought the new upstart was going to be out before I got home? :)
<ScottK-desktop> Does generating a new readaheadlist profile subtantially slow down the boot process?
<ScottK-desktop> Either it does or something has gone horribly wrong here ....
<soren> ScottK-desktop: It does.
<ScottK-desktop> soren: Thanks (first time I've tried it).
<glick> excuse me, is it a bug, people tell me to change my hostname to go to system>administration>networking
<glick> but thre is no such tab
<glick> i have "network tools" but it has no "general" tab
<ebroder> glick: Use #ubuntu for support
<glick> ebroder, yeah they keep telling me about an option i dont have, so i was wondering if its a bug or something
<ebroder> glick: Did you try mentioning that you don't have it?
 * glick sigh, yeah
<glick> its okay, thanks
<ebroder> glick: Network tools isn't the right application
<ebroder> It could be that you're just running an older version of Ubuntu or something
<glick> im running jaunty
<ajmitch> win 21
 * ebroder switches to a jaunty machine
<ebroder> glick: I don't really use graphical Ubuntu, so I'm not sure what the right way to do this is. If you want to get a networking pref app, you can install gnome-network-admin. I'm not sure if it's intentionally not installed or if something's supposed to take it's place or what
#ubuntu-devel 2009-06-27
<cjwatson> nhandler: err, that's odd, I thought I updated it days ago
<cjwatson> nhandler: I don't know what was wrong, but it's fixed now. Thanks.
<nhandler> No, thank you cjwatson for updating it ;)
 * ebroder is sad that dput ppa:broder/ppa doesn't work on Hardy
<ebroder> Oh, is it just config? I guess I can go grab the config from a current version
<pkt> ca-certificates-java is FTBS because COMODO's cert wants to use a non-existant algorithm
<pkt> I guess I can just remove COMODO's certificates from ca-certificates locally to get things to work
<pkt> breaking the whole java stack just for a stupid certificate seems a little insane
<tgpraveen> orange
<tgpraveen> brown
<BUGabundo> guud morning everyone
<BUGabundo> pitti: ping. around ?
<BUGabundo> $ apport-cli -c susres.2009-06-24_14\:39\:24.683568.crash
<BUGabundo> *** Error: Invalid problem report
<BUGabundo> You are not allowed to access this problem report.
<BUGabundo> let me guess, I need to sudo it ?
<geser> BUGabundo: check the permissions and try sudo if needed
<BUGabundo> its root
<BUGabundo> should I _sudo_ apport??
<geser> probably
<BUGabundo> won't it open Firefox as root ??
<BUGabundo> I don't trust FF that much :)
<BUGabundo> better chown the .crash
<BUGabundo> ehe
<BUGabundo> and file a bug on apport to learn to deal with those corner cases
<geser> BUGabundo: you can do that too (if you trust your own user :)
<BUGabundo> ahahaah
<BUGabundo> at least it can't/shouldn't harm my system
<tgpraveen> BUGabundo: do u know what MIR means i have heard in the ubuntu-devel
<tgpraveen> room
<tgpraveen> searching for it didnt help much
<geser> !mir
<ubottu> mir is Main Inclusion Report - see https://wiki.ubuntu.com/MainInclusionProcess for more information.
<geser> tgpraveen: ^^
<tgpraveen> thx
<BUGabundo> tgpraveen: next time, try the bot :P
<BUGabundo> geser: are all of this "late resume failure [non-free: nvidia]" bugs dupes?
<geser> I don't know, didn't hear about this till now
<BUGabundo> I see a bunch of them on LP
<BUGabundo> better file separedly since its Kernel
<BUGabundo> you know how the kernel team likes them separated so they can trigger HW bugs
<BUGabundo> geser: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/392866
<ubottu> Ubuntu bug 392866 in linux "late resume failure [non-free: nvidia]" [Undecided,New]
<BUGabundo> geser: : " hibernate failing (presumably due to space" ahhh that's me!!!
<miik> why karmic have only bash 3.2, not bash 4?
<Vantrax> when was 4 released as stable?
<pkt> vantrax: it's been at least a month iirc
<pkt> but debian doesn't use bash 4
<pkt> (as stable) so ubuntu probably won't either
<Vantrax> doesnt mean ubuntu wont, makes it less likely tho
<pkt> I think it does. Diverging from debian in such a core package could be pretty bad
<directhex> it won't happen for karmic
<directhex> decisions as to the core stack are made early in the release cycle
<directhex> and bash is too core to be easily changed without spending AGES on regression testing
<miik> then someoen should make a bash4 ppa
<pecisk> hi people, is it itentional that daily livecds are not built yet for karmic or there is some problems with it?
<Sarvatt> anyone else having problems with gnome-power-manager not working right since the devicekit-power update yesterday?
<bucky> will openvz packages be available in jaunty someday?
<bucky> specifically the kernel patch
<hyperair> what's openvz?
<bucky> hyperair: virtualization
<hyperair> ah i see
<hyperair> well it won't enter jaunty, definitely
<hyperair> jaunty's been released, and is closed to new packages, so only security/serious bugfixes can get in
<bucky> ic
<hyperair> if you want the packages to enter the upcoming release, then package them =) and if you want the kernel patches in, poke the ubutnu-kernel team and see
 * hyperair is off to test his freshly compiled kernel
<slangasek> hmmmm, reproducible crash in firefox when I try to browse to attach a file to a bug report
<chrisccoulson> hi slangasek - it seems that bug 299328 is already resolved in karmic. would you mind adding a jaunty task to it if you want me to fix it as a SRU?
<ubottu> Launchpad bug 299328 in hwinfo "libhd15 wrongly claims to Provide libhd14" [High,In progress] https://launchpad.net/bugs/299328
<slangasek> chrisccoulson: I'm not worried about it for SRU, since apparently this library has had this kind of problem for some time - I just happened to be reviewing my reported bugs list and saw it :)
<chrisccoulson> no problem. i saw it'd already been reported and fixed in debian, and that version was recently sync'd in karmic
<slangasek> cool
<chrisccoulson> slangasek - just looking at your comments on bug 390504. i've implemented your first point now (the dialog has a checkbox to disable the notifications), but I'm not sure if your second point is that easy to implement
<ubottu> Launchpad bug 390504 in gnome-settings-daemon "gnome-settings-daemon should keep its opinions about my disk management to itself" [Low,Confirmed] https://launchpad.net/bugs/390504
<slangasek> chrisccoulson: probably not as easy, no; if the first point is done, I guess the second is much less of an issue, though :)
<slangasek> (that reduces it from "an unlimited number of dialogs I should never see" to "one dialog I should never see")
<chrisccoulson> yeah, hopefully. i need to try and get this patch accepted upstream now
#ubuntu-devel 2009-06-28
<mcasadevall> directhex, your on Slashdot!
<ScottK> You say that like it's a good thing.
<mcasadevall> ScottK, I was on /. recently, my spam levels still haven't returned to nromal :-/
<sebner> ScottK: 15 minutes of fame ;)
<mcasadevall> wow
<mcasadevall> RMS doesn't use a webbrowser?
 * mcasadevall stares
<emgent> mcasadevall: ? url ?
<NCommander> emgent, http://lwn.net/Articles/262570/ - he uses wget ...
<emgent> NCommander: LOL!Ã¹
<slangasek> waah, why has the printing dialog in firefox completely changed?
<slangasek> ... and why is the printing itself screwed up
<directhex> mcasadevall, you mean "again" i think
<directhex> mcasadevall, problem is, i'm still recovering from june's shared hosting bill
<mcasadevall> directhex, ow
<directhex> mcasadevall, i get 3.6 gig a month, and i was up to about 7 last week
<Laney> rar
<mcasadevall> directhex, you need a better plan.
<directhex> mcasadevall, yes, i do. i suspect i'll be forced into a decision when my current hosts give me the push
<directhex> Summary for June 2009
<directhex> Total bandwidth used 	8662 MB
<directhex> Total allowed 	3600 MB
<directhex> well, bollocks
 * hyperair pokes fta about ia32-libs =\
<AnAnt> Hello, is Rick Spencer here ?
<Nafallo> !ask | AnAnt
<ubottu> AnAnt: Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<AnAnt> Nafallo: I didn't ask to ask
<Nafallo> oh well. it's still a weekend :-)
<wgrant> He's not here.
<Nafallo> kind of sent the wrong bot thingie :-P
<wgrant> Nafallo: Did you mean !weekend?
<Nafallo> wgrant: yes. but I use !ask hell of a lot more than I use weekend, so brainfail on my part.
<AnAnt> anyways, does anyone know about the  parental control software ?
<AnAnt> it was a blueprint filed by Rick
<Nafallo> hmm. !ask wasn't so bad after all then :-)
<AnAnt> will there be parental control in karmic ?
<AnAnt> Nafallo: sorta ;)
<wgrant> Priority is Low, so it might well slip.
<wgrant> But I know nothing more than is on the blueprint page.
<wgrant> You'd do much better to ask during the week, and when the relevant people aren't asleep.
<Nafallo> the US should be asleep this time even during weeks actually :-)
<wgrant> Nafallo: Yep.
<AnAnt> I did't know that he's american
<wgrant> AnAnt: Launchpads knows everything.
<AnAnt> oh, yes
<AnAnt> my bad, I only searched for his nick on LP !
<AnAnt> ok, thanks
<slangasek> Nafallo: I didn't get that memo
<Nafallo> slangasek: you're probably still hiding in London somewhere. undercover.
<slangasek> this is an interesting theory
<Nafallo> anyway. I've eaten and had something to drink. time to go to bed.
<wgrant> Nafallo: Isn't it like 9am...?
<Nafallo> wgrant: 10
<tgpraveen> !weekend
<ubottu> 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.
<garyvdm> stefanlsd: ping
<garyvdm> Hi - I'm trying to test a package with pbuilder
<garyvdm> When I run sudo pbuilder create - it does nothing
<garyvdm> http://paste.ubuntu.com/205525/
<garyvdm> stephenlsd was helping me yesterday - He did something to make try make a karmic pbuilder
<garyvdm> We had to cancel it because I had to go.
<garyvdm> I'm now trying to get going aging - but I can't get pbuilder working :-(
<Hobbsee> garyvdm: just be patient.  Also, how good is you rintenet connection?
<garyvdm> poor
<Hobbsee> then it's going to take ages - it's downloading a minimal ubuntu system
<garyvdm> But it's not download anything according to System Monitor
<Hobbsee> hm, then that's odd
<garyvdm> The other thing stephenlsd did was set it to use a proxy server at his work
<garyvdm> I've changed my apt sources to not use the proxy server - but he did something else regarding the proxy server when we got to the pbuilder bit
<garyvdm> Hobbsee - can I get pbuilder to use a ubuntu cd?
<garyvdm> to do a jaunty enviroment?
<Hobbsee> garyvdm: err.  Yes, you probably could, with an alternate cd, setting up a mirror based on it, and then using the --othermirror option in pbuilder to point to it.  I don't have the time to step you through it, though, and i've not done it myself
<garyvdm> Ok
<garyvdm> I think I will mail stefenlsd to get some help from him.
<Chipzz> garyvdm: don't. just join #ubuntu-motu and ask there
<garyvdm> Ok
<Chipzz> you'll 1) have a faster answer and 2) not bother one individual developer with your problem
<Hobbsee> oh, and thee probably aren't many people aound on a sunday
<garyvdm> Chipzz: It's just stefenlsd was doing some stuff on my system, and I'm not sure what he did (see http://blog.glock.co.za/packagejam-2009-south-africa)
<Chipzz> garyvdm: point still stands
<Chipzz> garyvdm: anyway, like I said, pls use #ubuntu-motu in the future for these kind of questions :)
<garyvdm> Ok
<Chipzz> (stefanlsd probably wasn't the only one organising the PackageJam - and even if he were, he's not the only one with those skills :))
<garyvdm> But he is the only one who knows what he did on my system :-0
<nuggetsradio> hey
<taavikko> how would one go on to set timeout for guest-session? tried editin guest-session-launch.sh but that got me so far, that the terminal opened were closed :)
<fta> hyperair, what about ia32-libs?
<YokoZar> jcastro: where are the plenary videos?
<YokoZar> (not at http://videos.ubuntu.com/uds/) and your message from the 10th said they'd be available "next week"
<hyperair> fta: outdated stuff, which doesn't work with pulseaudio.
<hyperair> fta: and crackly video with skype if it actually works
<jcastro> YokoZar: I sent the message like, this past thursday
<jcastro> YokoZar: next week as in this week coming up
<YokoZar> jcastro: hmm I might have misread the email
<YokoZar> thanks then
<jcastro> no worries
<jcastro> YokoZar: the IS team is on it for next week, there were some complications getting the right server to the right place or something
<fta> hyperair, my up-to-date package breaks plugins in firefox, including flash so i'm quite reluctant to push it
<tgpraveen> i was just reading this list of papercuts solved this week and the also some of the future cuts and from this report itself and also from the comments section of many of the future milestone bugs i can see majority of bugs falling into 2 categories
<tgpraveen> 22:53http://blog.davebsd.com/2009/06/28/first-paper-cut-milestone-reached/
<tgpraveen> either 1. fixed upstream independent of help from ubuntu team/papercut proj
<tgpraveen> 22:54 2. just some changes to naming eg. clean up by name->arrange by name
<tgpraveen> 22:54 what do u guys think?
<tgpraveen> 22:54 are these observations true or are they actually doing better.
<tgpraveen> 22:54 and i do know that papercut means minor bug but still there could
<tgpraveen> 22:54 be more types of bugs like of type
<tgpraveen> 22:55 Width of notifications seem arbitrarily small
<tgpraveen> 22:55 or the bug about having a notification for all drive unmounts
<dupondje> pitti: u there ?
<geser> dupondje: you might have better chances in around 12 hours
<dupondje> :)
<dupondje> there is some crappor bug in Karmic atm
<dupondje> mounting usb disks broken :(
<lesshaste> hi... it seems that shutdown -h is using kexec
<lesshaste> which means that it skips the boot loader when it restartws
<lesshaste> how can I fix this?
<chrisccoulson> lesshaste - edit /etc/default/kexec?
<chrisccoulson> change LOAD_KEXEC to false
<lesshaste> chrisccoulson, no such file
<chrisccoulson> :-/
<chrisccoulson> no idea then ;)
<lesshaste> this is a weird bug really
<lesshaste> it means that selecting OS/kernel is a pain
<lesshaste> as I have to boot, then restart !
<hyperair> shutdown -h or shutdown -r?
<hyperair> i thoguht -h was supposed to halt?
<lesshaste> shutdown -h halts
<lesshaste> when I start again it skips grub
<lesshaste> as it seems to have used kexec
<lesshaste> shutdown -r does what you expect
<lesshaste> and loads grub on restart
<hyperair> er i wasn't aware that kexec could cause that
<lesshaste> hyperair, it seems it does/./
<hyperair> are you sure it is kexec?
<hyperair> i  mean kexec is supposed to replace the kernel *immediately*
<lesshaste> there is a different bug here hmm https://lists.ubuntu.com/archives/universe-bugs/2009-May/089055.html that seems related
<hyperair> not sit around in an off state until your computer starts up again
<lesshaste> hyperair, no I am not sure but it does boot fast
<hyperair> hmm =\
 * hyperair doesn't know
<hyperair> i don't bother with kexec
<hyperair> my bootloader and bios are pretty quick
<lesshaste> hyperair, well.. I don't know what it is then
<lesshaste> I am not sure
<lesshaste> any other ideas gratefully received
<lesshaste> hyperair, I think the kexec part comes when it starts up again
<hyperair> hmm
<lesshaste> hyperair, it's not the shutdown part
<hyperair> interesting eh.. =\
 * hyperair is confused
<lesshaste> hyperair, the question is... how can I debug this?  dmesg seems useless
 * hyperair doesn't know
<hyperair> i'd just not use kexec and have done with it =p
<hyperair> s/have/be/
<lesshaste> I am not trying to use it!
<lesshaste> this is a default jaunty install
<hyperair> but kexec-tools shouldn't be installed in jaunty by default =\
#ubuntu-devel 2010-06-28
<directhex> asac, ping
<achiang> ping humphreybc
<achiang> argh fat fingers
<sabgenton> cjwatson: is the website admin about?
<sabgenton> I don't know his nick
<cjwatson> sabgenton: no
<sabgenton> yes I knowticed  I found his nick :)
<sabgenton> newz2000
<cjwatson> I don't like giving out personal contact info when there are plenty of advertised ways to contact webmaster which don't rely on it being that one person
<cjwatson> (the ubuntu-website project in LP, webmaster@)
<sabgenton> ?
<sabgenton> LP
<cjwatson> Launchpad
<sabgenton> sorry
<sabgenton> I have since found that to install ubuntu server with usb-creator is now possbile but not with The out of the box instructions given on the website
<nigelb> sabgenton: why don't you open a bug against the ubuntu-website project?
<nigelb> I'm sure the concerned folks will take a look at it when they come online :)
<cjwatson> nigelb: I suggested that to sabgenton several days ago too
<cjwatson> I don't think stalking the webmaster on IRC is a good way to get things done, generally
<sabgenton> meah ok
<sabgenton> I posted the bug
<sabgenton> cjwatson: is the any proper way to bump a bug?
<nigelb> sabgenton: you don't have to, they get a mail automatically
<nigelb> cjwatson: agreed there
<sabgenton> ok I'll just leave the bug
<dholbach> good morning
<pitti> Good morning
<dholbach> hey pitti
<asac> directhex: ?
<lifeless> the 'share this network' stuff in NM is really pretty neat.
<RAOF> NM is really pretty neat.
<directhex> asac, i'm tracking down ARM problems with mono. it looks like our current 2.6.3-2 package in experimental, which includes the previous ubuntu ARM changes, doesn't build on the debian arm porterbox ("illegal instruction")
<lifeless> RAOF: the adjective I had in mind was a tad different.
<lifeless> I like this bit ;)
<directhex> asac, getting ARM working well is a blocker on pulling it into maverick
<asac> directhex: hmm
<asac> directhex: i can see what happenes on our porter box
<asac> give me the .dsc ;)
<directhex> http://ftp.de.debian.org/debian/pool/main/m/mono/mono_2.6.3-2.dsc
<directhex> on agricola, it fails about a third of the way through the build, i.e. when bootstrapping the class library, after building the C-based runtime
<pitti> asac: I prepared the dpkg filtering patch for maverick, FYI; but didn't you say that there was a WI for that?
<asac> pitti: one second. let me give you an item ;)
<pitti> oh, I was just wondernig whether I should close something
<asac> pitti: you said you also needed to upload apt?
<pitti> do I?
<pitti> asac: depends on what you want to do; these are quite independent
<pitti> but I'd like mvo to have a look at my MP first before I put it into the official distro
<asac> kk
<asac> pitti: added that work item to arm-m-on-disk-footprint and set it to DONE for you. also added an apt item there
<pitti> ok, thanks
<Chipzz> sabgenton: and FWIW, "bumping" a bug is hardly ever an appropriate thing to do in my personal opinion
<Chipzz> personally I find "bumping" a bug obnoxious behaviour
<sabgenton> Chipzz: so if no one answers just leave it ?
<Chipzz> sabgenton: they'll get to when they get to it
<Chipzz> you don't know what else they have on their plate
<Chipzz> that's the whole point of a bug tracking system
<sabgenton> mm
<directhex> 372 test(s) passed. 7 test(s) did not pass.
<sabgenton> I'm just trying to understand the ettiquett
<sabgenton> Chipzz: do all bugs get read eventually
<Chipzz> yes
<sabgenton> or do some get disgarded
<asac> Riddell: please fix 512146
<Chipzz> like cjwatson pointed out above, the person responsable will get an email about it
<asac> that clearly had open MIR points when you promoted ;)
<sabgenton> if It say there for like 9 months or something should I take action
<sabgenton>  / raise awarness
<jibel> mvo, chrisccoulson, hey, latest flashplugin-nonfree in lucid-proposed introduces a regression. Could you please have a look at 429841 again.
<sabgenton> or does that not happen
<asac> Riddell: same for 512148
<sabgenton> (it was barrly yesterday :)  )
<directhex> 7 fails is a HUGE improvement on what's in lucid
<sabgenton> Chipzz: with the understanding of time u just gave me I will leave it at thatt :)
<chrisccoulson> bug 429841
<ubottu> Launchpad bug 429841 in flashplugin-nonfree (Ubuntu Lucid) "broken packaging: package flashplugin-nonfree failed to install/upgrade: (breaks upgrade)" [Critical,In progress] https://launchpad.net/bugs/429841
<chrisccoulson> :)
<Chipzz> sabgenton: raising awareness is sth which is often done
<sabgenton> sth?
<Chipzz> I disagree with the whole sentiment of "raising awareness", but that is again, my very personnal opinion
<Chipzz> sth -> something
<Riddell> asac: both opengtl and plotutils have .symbols files
<sabgenton> Chipzz: do you believe someone should submit and then trust the system?
<sabgenton> no matter the time
<Chipzz> if say one year passes you may consider bumping it
<asac> Riddell: right. but plotutils the warnings still left
<asac> at least one "definitly fix"
<Chipzz> but it's not like bugs get deleted from the BTS
<Riddell> asac: right enough.  what's up with opengtl?
<sabgenton> Chipzz: ok I think I agree with that
<Chipzz> it may just not be a high priority for the person involved
<mvo> thanks jibel, I check it out
<asac> Riddell: now looking at the comments, its fine. thx
<sabgenton> :)
<asac> Riddell: so just plotutils ;)
<asac> Riddell: also bug 512159 has still a few issues
<ubottu> Launchpad bug 512159 in libqtgtl (Ubuntu) "[MIR] libqtgtl" [Undecided,New] https://launchpad.net/bugs/512159
<seb128> hum, do we really need tk8.4 in the default installation?
<seb128> it seems only recommended by some of the printing stack components right now
<pitti> I'd like to get rid of it, indeed
<pitti> we have had 8.5 in main for quite some time now
<BlackZ> could someone look at bug #598874 ? this situation should be solved BTW
<ubottu> Launchpad bug 598874 in libmpc (Ubuntu) "Please sync libmpc 2:0.1~r459-1 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/598874
<BlackZ> (libmpcdec is in main)
<seb128> pitti, but do we need any tk at all on the default installation?
<pitti> seb128: not sure what still needs it; would be nice to get rid of it, of course
<directhex> purging it doesn't seem to remove anything else
<hrw> cjwatson: can you link xdeb page there: https://edge.launchpad.net/ubuntu/+source/xdeb ?
<cjwatson> hrw: urgh, cross-channel stuff, let's keep this on #linaro?
<hrw> cjwatson: ok
<vaul1> Hello people. Could someone please give me guidance? I want to know where to post a request for a mono icon for an application in Launchpad.
<lifeless> what do you mean?
<vaul1> I want designers of a standard Ubuntu icon theme to draw an icon for an application that I use.
<lifeless> hmm
<vaul1> And I want to know where on Launchpad to post a request about that.
<lifeless> possibly the ubuntu artwork list
<vaul1> Concearning?
<lifeless> I'm not sure a bug is the best way to get the attention of artwork folk
<vaul1> Bug, feature request â what is a better way to get an attention of some developer?
<vaul1> There is a Â«HumanityÂ» team, maybe it is a place?
<vaul1> There are similar reports here, so I am opening a report.
<vaul1> It seems there is not much life here, though.
<vaul1> Oh, Â«ubuntu-monoÂ» seems an exact match for that, in case anyone else is interested.
<lamont> cjwatson: how would you feel about ltsp-server [i386] for a depends?
<cjwatson> lamont: seems too heavyweight really.  we often advise people to install livecd-rootfs when they're doing customisation
<lamont> cjwatson: ok.  I'll fix make-chroot.sh to install it then.
<lamont> cjwatson: all fix0red. enjoy
<cjwatson> thanks
<cjwatson> I shall enjoy two fewer mails per day, hopefully
<lamont> sounds like a drop in the bucket
<lamont> cjwatson: on a different note, do you happen to remember which architecture was throwing random SIGILLs back when?  I'm thinking of dropping that auto-retry, since we've found at least one solid SIGILL on arm
<cjwatson> I don't, sadly
<lamont> I'm fairly certain it was either hppa or ppc, just can't remember for sure which
<directhex> is there an ARM porterbox available to non-canonical staff?
<lamont> not that I know of
<directhex> how vexatious
<siretart> asac: what's the problem with libva? it does provide a shlibs file: "libva 1 libva1"
<asac> siretart: hmm. did i miss that?
<asac> siretart: you do that manually?
<siretart> asac: I've just downloaded the .deb from launchpad and checked with 'dpkg-deb -I libva1_1.0.1-3_i386.deb shlibs'
<asac> siretart: thats the auto generated file, yes. having that maintained explicitly in rules gives more confidence
<asac> that someone is actually caring about that ;)
<siretart> asac: which is perfectly fine until upstream actually does a change that is not.
<siretart> asac: so you require some special action from the maintainer to indicate "I promise that I will check on the next upload?"
<siretart> sorry?
<asac> siretart: actually i want .symbols files
<asac> so i dont need to hope that debian maintainer knows how to do that and does it right
<siretart> asac: uff? is that a new ubuntu policy? since when do all libraries in main need to have .symbols files?
<asac> siretart: as i said. i want .symbols files
<asac> but its not required. i just want confidence that abi is properly tracked
<seb128> siretart, hey
<asac> having no explicit makeshlibs doesnt give that to me
<siretart> hi seb128
<seb128> siretart, did you talk with sirestart about ffmpeg 49 and 50 binaries overwritting files issues?
<seb128> ups
<siretart> asac: in the pkg-multimedia team, we do maintain quite some libraries and we do care about ABI/API issues
<asac> siretart has two owners now?
<asac> siretart: how do you track them?
<seb128> siretart, with Sarvatt I meant
<siretart> with objdump?
<siretart> seb128: no, he didn't contact me. what's the lp bug number you're talking about?
<asac> siretart: so you double check for every upstream pick that nothing changed and do the right thing?
<siretart> I do, yes.
<seb128> siretart,
<seb128> juin 25 00:36:58 <Sarvatt>	gstreamer0.10-ffmpeg should just be built against libavutil50 anyway though shouldn't it?
<seb128> juin 25 00:38:17 <Sarvatt>	other junk is still using libavutil49 though like vlc and thats screwed up also if you have extra installed :(
<seb128> juin 25 00:40:02 <Sarvatt>	yeah libavutil49 isn't even built in ffmpeg-extra anymore so the screwed up empty package is just hanging around in the archive
<asac> siretart: you do ... but how about the others ;) ... what i think is that its hard to see that a team i dont know cares about this in a way that we can rely on it here
<siretart> asac: if there is a rule that all libs in main are required to have .symbols file, please show it to me
<asac> but i can approve it if you say its not going to be a problem ;)
<asac> siretart: as i said. there is no rule. and i didnt ask for that
<siretart> you said something else at 13:35
<asac> 13:35 < asac> siretart: as i said. i want .symbols files
<asac> 13:36 < asac> but its not required. i just want confidence that abi is properly tracked
<asac> no ... thats what i said ;)
<siretart> I see
<siretart> seb128: he seems pretty confused
<asac> the easiest way to convince is .symbols ... not sure why thats a problem for anyone doing lib maintenance though
<siretart> seb128: libavutil49 is NBS, packages will drop that dependency as they are rebuilt
<seb128> siretart, dunno, but we got quite some bugs about avi playing not working in maverick, not sure if that's because we still use the wrong one
<seb128> siretart, well, then we need to rebuild things to pick the new soname?
<siretart> seb128: having libavutil49 and libavutil50 loaded at the same time shouldn't be a problem anymore, as I've introduced symbol versioning upstream
<siretart> seb128: if there is an undeclared file conflict, please file a bug and tell me the bug number. I'll take care of that
<siretart> if there is a crash, I'd need a backtrace
<seb128> juin 25 00:33:24 <Sarvatt>	libavutil49 is correct, its libavutil-extra-49 that is screwed up and that replaces libavutil49
<seb128> siretart, I will check what's going on
<seb128> siretart, I think he said he managed to get files overwritten and then not there after an upgrade
<siretart> of course libavutil-extra-49 is supposed to replace libavutil49. same for the 50 variant
<siretart> we are doing that game for a couple of releases
<siretart> is he on amd64?
<siretart> the amd64 build arrived only this weekend, because of the vdpau trouble
<seb128> could be
<siretart> that I fixed this weekend by disabling the 32bit libs
<seb128> siretart, I was just checking if you knew anything before spending time on that
<seb128> siretart, I will try to figure what the issues are now and ping you back later if needed, thanks
<siretart> seb128: as said, I'm not aware of a problem related to that
<siretart> ok
<siretart> asac: .symbol files are still a huge pain for c++ libraries. We've tried for libjack, but it's pretty pointless there
<asac> siretart: we have a lot of crack libs in main even. some have loads of symbols exported that should never have been exported (e.g. _xxx symbols that were not properly hidden upstream). i just want to ensure that folks get reminded about this topic whenever upstream changes their abi/api and .symbols is the easiest way i can currently see that will ensure that such a reminder will take place
<siretart> IIRC libva is plain c, so adding .symbol files should be rather easy
<asac> siretart: yeah i see your point
<asac> but libva is C ;)
<siretart> as said
<asac> yep
<siretart> btw, for ffmpeg, these libs also don't provide .symbols files, and won't in the forseable future
<asac> in the end i trust you to do the right thing. but in general i am looking at a package without knowing its origin etc.
<siretart> I play rather dirty tricks with the shlibs file so that the ffmpeg-extra trick works
<asac> sad enough ;)
<siretart> or other way round, I cannot implement that trick with symbol files
<siretart> oh, I'd also love to get rid of that trick
<siretart> but that would require to promote liblame, x264 and xvidcore to main
<siretart> would you be more comfortable with that? ;-)
<asac> but does that mean that all other libs shouldnt use symbols ;)?
<asac> siretart: i didnt talk about ffmpeg here
<asac> anyway. you can choosed: a) add .symbols \o/ ... b) add explicit makeshlibs o/ c) keep it as is and state the process you have in place in the multimedia team that will ensure that abi/api will be properly tracked
<asac> all three are good enough to get approval
<siretart> no, I just wanted to point out that I do care about ABI/API issues, and that I feel your decision to make a .symbol file a requirement for libva's promotion to main overexaggerated
<siretart> I choose c) for now, but feel free to propose a symbol file as bug in debian with attachment ;-)
<asac> siretart: can you post your process to the bug then?
<asac> thanks
<siretart> err
<siretart> that the normal sponsoring review process
<siretart> but fair enough
<pitti> !regression-alert is cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<pitti> hm, that's what https://wiki.ubuntu.com/UbuntuBots documents..
<pitti> sorry all for the noise; seems I'm not able to update this, will contact Jussi
<jussi> !regression-alert is <reply>cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<ubottu> I'll remember that, jussi
<jussi> :)
<pitti> jussi: erm, wow -- that was fast :)
<pitti> jussi: many thanks
<jussi> although, lets just check
<jussi> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<pitti> \o/
<jussi> it works!
<smb> miraculous
<jussi> pitti: the bot sometimes doesnt like long calls, not sure whats up with it. you did it correct, although it makes things easier if you include the <reply>
 * pitti grabs megaphone "This was just a drill. Don't panic. As you were."
 * ogra_cmpc shades his ears
<seb128> pitti, way to stress me to start the week :p
<smb> ogra_cmpc, Back to the classmate again? :)
<ogra_cmpc> smb, my living room machine :)
 * ogra_cmpc is having lunch
<smb> :)
<pitti> seb128: need to clean up my GTG list a bit :)
<hyperair> dholbach: ping
<dholbach> hyperair: pong
<hyperair> dholbach: i'm going to be conducting a bug jam tomorrow, and was wondering if you had the template (or at least the background of) the "Ubuntu in 50 minutes" presentation around?
 * hyperair needs to do some introduction slides
<dholbach> you mean the text for the presentation?
<hyperair> https://wiki.ubuntu.com/Presentations <-- the first link here
<hyperair> no, the template
<hyperair> like the background/formatting
<dholbach> oh, I got that from henninge
<dholbach> maybe he still has it
<hyperair> hmm so i should contact him for the template?
<dholbach> yeah
<dholbach> https://wiki.ubuntu.com/Jams/Bugs?action=AttachFile&do=view&target=bug_report_triage_feb09.odp might be helpful too
<hyperair> hmm let's see.
<hyperair> dholbach: ah that's the glossyubuntu template. i was actually hoping for something that suits ubuntu's colour scheme post-branding-refresh
<dholbach> hyperair: I meant the actual content
<dholbach> :)
<hyperair> ah!
<dholbach> :-D
<hyperair> yes, that helps very much =P
<hyperair> thanks
<dholbach> rock on!
<dholbach> and enjoy the jam - will you post some pictures of it later on?
<hyperair> dholbach: er where? =p
<hyperair> er nevermind, i'll go register a flickr or picasa account or something
<hyperair> dholbach: by the way, http://people.canonical.com/~dholbach/talks/Bugfixing%20in%20Ubuntu%20-%20German.odp <-- this gets 403.
<dholbach> hyperair: sorry, fixed
<hyperair> \o/ thanks
<vish> hyperair: hey.. how big an event?
<cnd> pitti: I see that linux-firmware-1.34.1 has been sitting in lucid-proposed for three weeks
<cnd> is there something that needs to be done to push it out to release?
<pitti> it has 2/4 verified
<pitti> I guess it's "good enough"
<pitti> the jaunty-proposed one is there for > 3 months already with zero feedback
<cjwatson> pitti,slangasek: could one of you review the dpkg SRU in lucid-proposed, please?
<ScottK> pitti: Would you please rescore kdepimlibs.
<ScottK>  ... or cjwatson ^^^
<pitti> ScottK: done
<pitti> cjwatson: looking
<ScottK> pitti: Thanks.
<cnd> pitti: maybe the jaunty one could just be dropped
<pitti> cjwatson: so this calls sync() once per package instead of fsync() once per file?
<cjwatson> right, it turns out that's synchronous on Linux
<cjwatson> and on many filesystems fsync() ends up nearly equivalent to sync() due to having to catch up with the journal anyway, as I (naively) understand it
<cjwatson> so rather than write-sync-write-sync-write-sync, it's better to do write-write-write-sync
<ion> http://fox.naurunappula.com/nn/1/096/359/s_607533.jpg
<ion> Crap. Sorry, wrong channel
<cjwatson> pitti: the -23 kernel looks not too bad regarding verification; what does your threshold normally tend to be for this stuff?
<ogasawara> pitti: cnd pointed out that amd64 ddebs aren't getting published for recent kernels  - http://ddebs.ubuntu.com/pool/main/l/linux/ .  I'm not familiar with what needs to be done to fix that, any ideas?
<smoser> we are in a freeze right now, right ?
<cjwatson> smoser: no
<smoser> i've not seen any announcements, but guessing based on alpha2 on thursday. wondering if there is somewhere i missed an announcemnt.
<smoser> oh. ok.
<cjwatson> guess I should send a warning
<ogra> smoser, "soft freeze" its expected that you upload "carefully"
<cjwatson> ogra: if we were in a soft freeze, there would have been a mail to ubuntu-devel-announce
<ogra> cjwatson, hmm, i though we have soft freezes by default before every milestone
 * micahg thought it would be tomorrow
<cjwatson> ogra: well, I just said "smoser: no" above, didn't I? :P
<ogra> indeed you did :)
<cjwatson> we normally soft-freeze basically last thing Monday / first thing Tuesday before alphas
<hyperair> vish: 2h 30m, the last event of tomorrow during the mosc 2010 (http://conf.oss.my)
<bgamari> Should -work of hald-addon-cpufreq. After removing the file 10-cpufreq.fdi from /usr/share/hal/... it wasn't loaded anymore and my issue was done with.
<bgamari> Scratch that; Should hald-addon-cpufreq be present in Maverick?
<bgamari> It may very well be the reason why my cpufreq maximum frequency is 800 MHz
<bgamari> There's definitely some major fail here either way
<bgamari> I was under the impression, however, that we finally broke away from hal under 10.10
<vish> oh.
<JontheEchidna> bgamari: that package is no longer available in 10.10
<JontheEchidna> from what I can see, anyhow
<pitti> cjwatson: hmm, "gut feeling and talking to smb about regression reports", but I'd say something like #verified >= min(10, #bugs/2)
<pitti> erm, "max"
<pitti> if it's been in proposed for three weeks and we haven't heard about problems, then it can't be too bad
<smb> Did I hear my name?
<pitti> ogasawara: I'll check tomorrow morning (sorry, just finished a phone interview and need to run now)
<pitti> smb: boo!
<ogasawara> pitti: no hurry, thanks!
<JontheEchidna> ah, its part of hal. If you have apps that still need hal, it'll be there, but the default Ubuntu install shouldn't have hal by default
<cjwatson> kirkland: present for you, debian-installer 20100211ubuntu11
 * kirkland hugs cjwatson 
<kirkland> and goes look at his present
<ogra> coudl some buildd admin bump livecd-rootfs so it starts in less than 5h ?
<ogra> (i tried to get NCommander to do it but he doesnt seem to be around)
<cjwatson> ogra: doing
<ogra> merci
 * kees just spent 30 seconds trying to figure out what regressed.  ;)
<cjwatson> kees: hmm?
<cjwatson> oh :-)
<kees> cjwatson: :)
<cjwatson> ogra: it's built now
<bgamari> JontheEchidna: It's been uninstalled
<bgamari> looks like banshee pulled it through the upgrade
<bgamari> Anyone know of a way to determine which process is writing to a sysfs file?
<JontheEchidna> yeah, looks like banshee depends on hal
<bgamari> ftrace syscall_enter_open doesn't seem to catch it
<ccheney> anyone know why i would have trouble sending keys to the ubuntu key server? it seems to hang for me
<ccheney> or is the keyserver just broken?
<geser> might be that the ubuntu key server has issues again
<hyperair> jcastro: ping.
<jcastro> pong
<hyperair> jcastro: when conducting a bug jam, how do you usually avoid stepping on each others' feet?
<kirkland> cjwatson: thank you thank you thank you!
<hyperair> jcastro: like person X changes bug A, person Y performs a redundant action on bug A at the same time
<jcastro> hyperair: section off groups of bugs to each group, so like, either by package, or by status
 * vish had just set up hyperair for unassigned bugs and jcastro messed that up :p
<hyperair> hehh
<hyperair> jcastro: yeah, so like vish said, i was planning to work on unassigned bugs, since there are quite a lot of them, and we don't have much time.
<cjwatson> kirkland: thought you'd like it
<kirkland> cjwatson: very much so, can't wait to try it out
<mdz> SpamapS, re: your memcached branch, the code in debian/preinst needs a test for the arguments to preinst
<mdz> I see it was copied from gearman, and it looks like gearman is buggy in this respect also
<SpamapS> mdz: does seem like this would be a useful addition to debhelper so we stop making these mistakes .. since gearman copied it from mysql... ;)
<mdz> SpamapS, indeed
<cjwatson> it's being added to dpkg, if this is what I think you mean
<cjwatson> conffile handling?
<mdz> cjwatson, adding a user
<cjwatson> ah ok
<mdz> but this is a general issue with maintainer scripts, forgetting the tests
<mdz> the mysql one even has the comment at the top "summary of how this script can be called" but ignores it ;-)
<SpamapS> mdz: another thing that would be awesome would be if pbuilder simulated failures to test the abort states of the maintainer scripts.
<mdz> SpamapS, sounds like the sort of thing which would fit into piuparts if it isn't there already
<leonpegg> Hello all I know this is not the place to ask but ubuntu-app-devel were unable to help, could anyone here help me with packaging some sourcecode ? Situation (attempting to package the php-gtk2 source into a source package except need it to output multipul binary packages from the one source tree)
<leonpegg> would be happy to be pointed to the direction of a tut on it (but cant find one myself)
<directhex> leonpegg, try #ubuntu-motu for more beginner packaging help
<lifeless> and/or #ubuntu-packagng
<leonpegg> Thanks guys :DF
<geser> #ubuntu-packaging
<Laney> what's that channel for?
<Laney> Is -motu no longer the place?
<leonpegg> seems as if both rooms have people in :D
<leonpegg> looks like motu is for offical packages and packaging is for ppa's and the likes
<directhex> asac, any idea when you'll be able to look at the downstream mono arm breakage? i completely give up on getting a build environment going without real hardware, it's just not happening, and i've spent about 2 days on this so far with reality fighting against me. best i can do is reverting whichever ubuntu patches broke building in debian
<ogra_cmpc> directhex, sudo apt-get install qemu-arm-static && sudo qemu-debootstrap --arch armel maverick maverick-chroot && sudo chroot maverick-chroot
<ogra_cmpc> directhex, oh, wait, you do mono, the above works for everything but mono thanks to boehm gc
<TylerGalt> Hello everyone, while browsing https://help.ubuntu.com/community/HowToMD5SUM , I stumbled on this sentence: "However this almost always NOT be the same hash as the iso image that was burned to the disk"
<TylerGalt> While english is my second language, I feel like a verb is missing, but I'm not sure how best to correct this (I just created an account on the wiki). Would "However this *will* almost always NOT be the same hash as the iso image that was burned to the disk" work better in your opinion? Or should we revamp the whole sentence?
<JontheEchidna> "However this will almost always..."
<JontheEchidna> yes
<TylerGalt> cool, thanks :)
<JontheEchidna> (sorry, lag)
<TylerGalt> (no problem :) I wanted to double-check: it would have been dumb to correct the sentence to introduce a grammatical error. Goodbye everyone, and thanks for working on Ubuntu (love it) )
<Rinsmaster> Just getting an opinion here: Is it a bug that nautilus freezes when clicking properties on an infinite loop postscript file?
<achiang> anyone know the best forum for casper questions?
<ccheney> can someone promote bugs 589993 and 589995
<ubottu> Launchpad bug 589993 in mdds (Ubuntu) "[MIR] mdds" [Undecided,Incomplete] https://launchpad.net/bugs/589993
<ubottu> Launchpad bug 589995 in mysql-connector-c++ (Ubuntu) "[MIR] mysql-connector-c++" [Undecided,In progress] https://launchpad.net/bugs/589995
<ccheney> doko__, do you happen to be awake to promote the above mentioned MIRs ?
<ScottK> pitti or cjwatson: Would you please rescore kdebindings and kdebase-workspace.
<kblin> er, durn, wrong #
<ScottK> Thanks whoever bumped them.
<cjwatson> ScottK: done
<cjwatson> ScottK: do they need retried on amd64/armel?
<ScottK> cjwatson: I just retried amd64.  Would you please bump that one?
<ScottK> cjwatson: armel would fail now because kdepimlibs isn't done.  I'll retry them later for armel.
<ScottK> Sorry about that one.
<ScottK> https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph is the rosetta stone for KDE package building if you ever wondered the sequence.
<geser> looks simplier than the haskell ones
<ScottK> Yes.  Definitely.
<ScottK> Those are totally insane.
<Laney> :)
<vish> bdrung: audacity or audacious?  audacious has the icon
<bdrung> vish: audacity - it has the icon
<vish> hmm , odd ,audacity doesnt show icon for me too
<bdrung> i am on amd64
<vish> i386 here
<zyga> where can I find older ubuntu releases?
<soren> How old?
<zyga> hardy+
<soren> Right next to the current ones.
<zyga> I tried checking cdimage.ubuntu.com but it seems /releases/ keeps going nowhere
<soren> For really old releases, see http://old-releases.ubuntu.com/
<zyga> http://cdimage.ubuntu.com/releases/hardy/release/
<soren> Try http://releases.ubuntu.com
<soren> That's where we put releases.
<zyga> oh, thanks
<ScottK> cjwatson: Would you please rescore kdebindings kdebase-workspace again (to pick up armel).
<TheMuso> c
<TheMuso> gah wrong tab
#ubuntu-devel 2010-06-29
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<un214> what would it take to bring back sysvinit?
<joshmuffin> can anyone help me, im using ubuntu 10.04 and I compiled gnome-shell from source, when i gnome-shell --replace it flickers and is unusable for about 30secs before it crashes, terminal output: http://paste.ubuntu.com/456343/
<joshmuffin> Think its a problem with my ati graphics card
<iulian> joshmuffin: Please see /topic.
 * achiang wonders if anyone's ever tried building gir1.0-atk-1.0
<TheMuso> achiang: Thats not a package...
<achiang> TheMuso: oh, i suppose atk1.0 is the actual package
<TheMuso> achiang: Yes.
<achiang> maybe that's where i'm going wrong
<dholbach> good morning
<TheMuso> 8/c
<pitti> Good morning
<sebner> huhu pitti :)
<slangasek> dholbach: there's a merge of cryptsetup staged already in the bzr branch listed in vcs-bzr... :)
<dholbach> slangasek: sorry, I didn't check that
<slangasek> no worries
<dholbach> apachelogger, seb128, slangasek, dpm, Riddell, Laney, nigelb, jcastro, beuno_, warp10: can you please go and check https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep and see if you're happy with your session title/description and update it if necessary?
<seb128> oh right, doh
<nigelb> interesting response :p
<seb128> I still don't know what I want to talk about there
<warp10> dholbach: yeah, perfect description :)
<dholbach> warp10: great, thanks
<dpm> dholbach, mine looks great, thanks!
<nigelb> dholbach: mine looks great too :)
<dholbach> thanks nigelb and dpm
<nigelb> seb128: perhaps on "how to help desktop team" or "how to be a desktop developer"?
<dholbach> this UDW will kick arse!
<asac> directhex: i asked slangasek and his crew to take a look. i dont get why you say that ubuntu patches broke debian though
<directhex> asac, i can't build 2.6.3-2, which includes the ubuntu patches, on the debian porterbox. but as i've stressed, access to hardware makes this whole thing immensely difficult to coordinate
<asac> directhex: what ubuntu patches are in there?
<directhex> http://git.debian.org/?p=pkg-mono/packages/mono.git;a=shortlog;h=refs/heads/debian/patches/arm_cpuinfo_parsing, http://git.debian.org/?p=pkg-mono/packages/mono.git;a=shortlog;h=refs/heads/debian/patches/arm_thumb2_support and http://git.debian.org/?p=pkg-mono/packages/mono.git;a=shortlog;h=refs/heads/debian/patches/armel_fix_configure_fpu_check
<dholbach> seb128: I'll update it in the timetable too
<dholbach> seb128: oh, you're still editing
<seb128> dholbach, commited, is the current description ok?
<dholbach> seb128: looks great
<dholbach> seb128: shall I got and update in the timetable?
<seb128> dholbach, could you change the "is work on" to "is working on"
<seb128> dholbach, while you edit
<seb128> dholbach, yes please, thanks
<seb128> sorry I forgot about this one
<dholbach> seb128: fixed
<seb128> dholbach, danke
<dholbach> de rien mon ami
<dholbach> didrocks: can you please go and check https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep and see if you're happy with your session title/description and update it if necessary?
<didrocks> dholbach: I'm happy about it, that's why I didn't shout at your email ;) danke!
<dholbach> didrocks: great, thanks
<directhex> asac, i don't know if 2.6.3-2 builds on an ubuntu ARM box - this is impossible for me to test. i know 2.6.3 upstream, without any arm-related patches, builds on debian
<Laney> directhex: #ubuntu-arm is probably a good place to find people
<Laney> (think that's right)
<directhex> Laney, good place to ask questions, not such a good place for receiving replies
<Laney> I thought that was The Place for Arm Related Stuff
* cjwatson changed the topic of #ubuntu-devel to: Main frozen for Alpha 2 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> Riddell: any idea why koffice wants to go to universe?
 * Riddell checks
<Riddell> pitti: fixed in seeds
<pitti> Riddell: thanks
<pitti> I cleaned up component-mismatches a bit, which should reduce http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html
<pitti> but this will require some more iterations
<bdrung> sbeattie: ping
<Kano> hi, why is maverick still not hybrid?
<Kano> look at suse, they patched syslinux and you just need to update it
<Kano> i even wrote a launchpad bug last year about it
<Kano> https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/524803
<ubottu> Launchpad bug 524803 in syslinux (Ubuntu) "isolinux hybrid mode should be used - all other major distributions do so since last year" [Undecided,New]
<cjwatson> Kano: it's on my list and will happen
<Kano> cjwatson: cant wait for it... i have got a script for your kind of iso images but i prefer hybrid ones
<Kano> with hybrid mode the script does not need to be root
<zul> can i get someone from the foundations team to review the upstart script in bug #574554 please?
<ubottu> Launchpad bug 574554 in tgt (Ubuntu Maverick) "tgtd needs init script or upstart job" [Medium,Triaged] https://launchpad.net/bugs/574554
<cjwatson> Keybuk: ^- would you have time to review the tgt bug above?
<cjwatson> I looked at it but was not sufficiently sure of the semantics of 'start on (filesystem and net-device-up IFACE=lo)' to comment
<Keybuk> it'll block lo from coming up until the filesystem does
<cjwatson> zul: this is by no means a complete review, but you're missing 'runlevel' after 'stop on'
<zul> cjwatson: thanks
<Keybuk> which will have an interesting repercussion for the rc-sysinit/rc scripts
<Keybuk> so I would avoid doing that if possible
<Keybuk> zul: followed up on the bug with a suggested alternate line
<mdz> SpamapS: packages listed in Depends are not guaranteed to be present/configured when preinst runs (only Pre-Depends packages are), Debian policy 7.2
<mdz> SpamapS: usually adduser is invoked from postinst, rather than preinst
<cjwatson> mvo: I've got a LOT of grub2 bugs that amount to the debconf frontend reporting that it lost its X connection, and then exiting 1.  Do you know what might be going on?
<mvo> cjwatson: let me check one of them. is this during a normal update or a dist-upgrade? maverick I assume? if maverick it could be the switch in update-manager to aptdaemon as default backend
<mvo> cjwatson: it does support debconf, but there may still be bugs
<cjwatson> mvo: lucid
<cjwatson> mvo: bug 576716 for example, I typically don't get more information than that
<ubottu> Launchpad bug 576716 in grub2 (Ubuntu) "package grub-pc 1.98-1ubuntu6 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saÃ­da de erro 1" [Undecided,New] https://launchpad.net/bugs/576716
<cjwatson> mvo: I was wondering if it could also be a pop-under dialog, and eventually the user got frustrated and closed the window
<mvo> cjwatson: checking
<cjwatson> but it's hard to tell
<jibel> cjwatson, most of the time this error occurs on wubi setup
<jibel> cjwatson, in the bug you mentioned there is loop=/ubuntu/disks/root.disk in the kernel boot command
<cjwatson> jibel: are you sure?  they typically look like upgrade logs.
<jibel> cjwatson, the pattern seems to be as follow
<Riddell> asac: uxlaunch accepted but I filed bug 599772
<ubottu> Launchpad bug 599772 in uxlaunch (Ubuntu) "lintian warnings" [Undecided,New] https://launchpad.net/bugs/599772
<jibel> install ubuntu with wubi
<jibel> then update the system.
<jibel> It's not reproducible or I haven't found a user able to reproduce
<cjwatson> jibel: while I know there are problems with wubi upgrades, I'm at a loss for why that would result in this particular error.
<cjwatson> as in, the technical mechanism.
<asac> Riddell: thx
<cjwatson> there should be no way for an individual package to be able to trigger that
<jibel> reporters describe a system hang and  kill the upgrade thus the display error
<cjwatson> right, if they kill it by hand then that's certainly one thing
<cjwatson> it's not clear to me that every hang is necessarily due to wubi!
<jibel> I seen 1 report where the reporter was able to catch a hang due to a "device busy" on an ntfs partition.
<jibel> cjwatson, but I don't known if it's the general issue.
<cjwatson> bug 574852: here's one that isn't wubi
<ubottu> Launchpad bug 574852 in grub2 (Ubuntu) "package grub-pc 1.98-1ubuntu5 failed to install/upgrade: underprocess installerade post-installation-skript gav felkod 1" [Undecided,New] https://launchpad.net/bugs/574852
<cjwatson> of course I imagine bug 576724 is contributing to all this
<ubottu> Launchpad bug 576724 in grub2 (Ubuntu Maverick) "Ubuntu Lucid grub2 dist-upgrades result in confusion" [High,Triaged] https://launchpad.net/bugs/576724
<cjwatson> if there are hangs when attempting grub-install to particular types of partitions, then that could explain part of it.  I'm hesitant to generalise here, though
<jibel> cjwatson, bug 561374, not wubi but the "device busy" thing
<ubottu> Launchpad bug 561374 in grub2 (Ubuntu) "package grub-pc 1.98-1ubuntu4 failed to upgrade: grub-setup hangs on fs sync - device or resource busy" [Medium,Triaged] https://launchpad.net/bugs/561374
<cjwatson> hm, right, I'm not convinced that's a grub2 bug
<cjwatson> let's not generalise from that one case
<cjwatson> seems like hardware error -> the ntfs-3g mount fell over -> os-prober couldn't unmount -> grub-setup got stuck; I'm not sure which userspace components could have done anything about this
<jibel> cjwatson, I agree, that's why I didn't duplicate them all
<cjwatson> jibel: BTW is there a reason you keep asking reporters about BIOS virus protection?  it's pretty unlikely to be relevant to hangs
<cjwatson> it might be relevant to problems that occur at boot time, but that's different
<jibel> cjwatson, I seen some cases where the bios prevent grub to install on the mbr. But it's not relevant in the case of an upgrade since the boot loader is already installed.
<mvo> cjwatson: hrm, that bug is odd, in lucid we still use synaptic as the backend, its the normal debconf frontend code used. let me play with it a bit
<cjwatson> jibel: do you have links?  I can't see how the BIOS is even in a position to prevent ATA writes
 * mvo waves to jibel
<pitti> tkamppeter: our ghostscript package recently balooned from 0.8 MB to 2.8 MB, due to the /usr/share/ghostscript/8.71/Resource/CMap/ files
<jibel> cjwatson, I'll check for links. I experienced this problem on dell gx desktops , where you had to disable bios virus protection in order to allow the installation of the boot loader
<pitti> tkamppeter: Debian strips them out, "shipped separately, registered with DeFoMa).
<pitti> "
<pitti> tkamppeter: can we do the same?
<ogra> cjwatson, MBR virus protection
<pitti> we need to claim back 20 MB of CD space
<ogra> cjwatson, some BIOSes have such an option that prevents you from accessing the MBR
<pitti> tkamppeter: we already have a set of cmap-adobe-* packages which ship them
<jibel> Hey mvo
<cjwatson> ogra: reference please
<mvo> jibel: just wanted to say thanks again for the flashplugin-nonfree sru verification! you rock
<jibel> mvo, no prob, that's what SRU verification is done for.
<jibel> mvo, btw I pushed this morning a fix for synaptic to build against latest libept 1.0 otherwise it FTBFS in maverick since last week.
<mvo> jibel: thanks a lot, I merge it
<ogra> cjwatson, cant give you one, but i know that even fdisk /mbr fails under windows if such an option is set, i doubt BIOS manufacturers make the details public about that feature
<ogra> cjwatson, i'm pretty sure it only works if the system uses an onboard controller the BIOS manages though
<jibel> cjwatson, about the apport hook for grub2, bug 591753, I don't know how passwords are stored in /etc/default/grub, any doc or reference ?
<ubottu> Launchpad bug 591753 in grub2 (Ubuntu) "Add apport hook to collect configuration information" [Undecided,Triaged] https://launchpad.net/bugs/591753
<jibel> cjwatson, do I simply filter the string .*password.* ?
<cjwatson> grep -v '^password'
<jibel> cjwatson, thanks, I'll update the apport hook.
<mpt> directhex, hi, would you be able to fix bug 546936 sometime this cycle? It's a one-line fix and would make life easier for potential developers
<ubottu> Launchpad bug 546936 in software-center (Ubuntu) "Monodevelop missing from Ubuntu Software Center's "Mono/CLI" subsection" [Undecided,New] https://launchpad.net/bugs/546936
<ttx> cjwatson: looking at https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/576066 ... I'm not sure it's categorized correctly. Are the kernel modules available to the Server installer really decided by seeds ?
<ubottu> Launchpad bug 576066 in ubuntu-meta (Ubuntu) "ums_cypress missing from lucid server cd" [Undecided,New]
<Riddell> chrisccoulson: you uploaded a fix to bug 429841 but didn't comment on the bug?
<ubottu> Launchpad bug 429841 in flashplugin-nonfree (Ubuntu) "broken packaging: package flashplugin-nonfree failed to install/upgrade: (breaks upgrade)" [Critical,Triaged] https://launchpad.net/bugs/429841
<tkamppeter> pitti, where are the cmap-adobe-* files located? Are they part of main, standard installation, or CDs? Note also that we are phasing out defoma.
<Riddell> and mvo also uploaded a fix
<mvo> Riddell: the fix is pretty trivial, the debdiff should be obvious
<mvo> Riddell: sorry for the double upload
<chrisccoulson_> Riddell - sorry, i forgot to comment
<chrisccoulson_> i did mention to mvo that i would fix it though ;)
<cjwatson> ttx: no, the kernel packaging decides that
<ttx> cjwatson: so I should reassign to "linux" with a comment
<cjwatson> yes
<ttx> cjwatson: ok, thx for the confirmation
<mvo> cjwatson: I tried to reproduce the grub-pc failure, but the only way I was able to trigger the io error 11 was a xkill. when killing the session I got a different io error. really odd
<cjwatson> it's all very strange
<cjwatson> I need to find some time to do some organised testing of wubi upgrades
<bdrung> DktrKranz: ping
<DktrKranz> hey bdrung
<tkamppeter> pitti, where are the cmap-adobe-* files located? Are they part of main, standard installation, or CDs? Note also that we are phasing out defoma.
<bdrung> DktrKranz: you worked on ubuntu-dev-tools, but andrew did some work too: https://code.launchpad.net/~andrewsomething/ubuntu-dev-tools/man-pages/+merge/28566
<bdrung> DktrKranz: can i revert your last commit?
<DktrKranz> bdrung: sure thing, I didn't spot that branch, feel free to do so
<DktrKranz> just, if you can save (closes: #xxxxxx), that would be awesome :)
<bdrung> DktrKranz: k, will add that to andrews branch
<LucidFox> Once in a while, I get a drive to review some packages on REVU.
<LucidFox> Like I did before. Then I look at the pile of unreviewed packages stretching back to May 2009, and...
<dholbach> cody-somerville: I can't find charlie-tca - can you have a look at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep and see if the description of the session is OK?
<cody-somerville> dholbach, Looks adequate to me :)
<dholbach> thanks cody-somerville
<LucidFox> Would it make sense to archive REVU packages for karmic (and maybe lucid) with a single like like "Wrong target Ubuntu release"?
<LucidFox> (Sadly, REVU still seems broken in regards to 3.0 (quilt) packages)
<pitti> tkamppeter: they are separately packaged; if they are useful, we can integrate them into language-selector
<pitti> tkamppeter: but we didn't ship them at all until now
<micahg> was libstdc++5 supposed to get back into the archive?
<pitti> eek, no; did it?
<micahg> pitti: yep, it was uploaded recently
<micahg> pitti: might not have been approved though...
<pitti> hm, madison says that it disappeared in karmic
<micahg> pitti: ah, it's in NEW :)
<pitti> it should be in OLD_AND_CRAPPY
<cjwatson> sync from gcc-3.3 in Debian, wasn't it?
 * micahg got worried when it was on the maverick-changes list :)
<cjwatson> he says, guessing
<pitti> might have been a wrong autosync
 * micahg thinks someone did it by accident
<pitti> I'm happy to axe it again
<pitti> it's cheap to bring back if needed, after all
<directhex> ISV apps still need it on occasion
<pitti> we did without it for two releases, and it's unmaintained
<pitti> and in that case we could put it into partner, or the ISV include it
<pitti> these tend to come with bundled libs anyway
<micahg> pitti: bug 598854
<ubottu> Launchpad bug 598854 in gcc-3.3 (Ubuntu) "Sync gcc-3.3 1:3.3.6ds1-20 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/598854
<pitti> ok, that was ack'ed by a MOTU
<pitti> IMHO it doesn't exactly help to encourage ISVs to bother with rebuilding their stuff against a slightly less ancient toolchain, but *shrug*
 * pitti accepts the binary then
<pitti> there, NEW down to 3
<micahg> pitti: why?  perhaps the MOTU didn't see all the previous discussion about it?
<pitti> because binary-only rejection doesn't really make sense
<pitti> if we remove the package again, the binary will just die with it
<micahg> pitti: k, I was jsut wondering why not nuke it again?
<pitti> that should be discussed on the ML or in a bug first, instead of just igoring our processes and the approved sync request
<micahg> pitti: I was just wondering if a process was skipped to reintroduce something like this.  Is that a MOTUs call whether or not to reintroduce anything into universe?
<pitti> I think so
<pitti> archive admins have a certain say in that, of course
<pitti> but someone synced it, so that happened
<micahg> pitti: k
<micahg> pitti: thanks :) I still have more to learn I guess
<pitti> micahg: but please do feel free to bring it up on the ML
<micahg> pitti: I just checked the removal bug and the reason cited is not maintained in debian, not OLD_AND_CRAPPY, so I guess there isn't an issue
<tkamppeter> pitti, they help for example to make msttcorefonts working with Ghostscript, see bug 321932. Probably there are more fonts (or input files with embedded fonts) which work better with these files present by default.
<ubottu> Launchpad bug 321932 in msttcorefonts (Ubuntu) "Ghostscript does not render when ttf-mscorefonts-installer is installed" [High,In progress] https://launchpad.net/bugs/321932
<pitti> tkamppeter: could ttf-mscorefonts-installer then depend on or recommend those cmap files instead?
<tkamppeter> pitti, I did not know that they were already part of the non-CD part of the distro and as Ghostscript upstream developers told me that Adobe has changed the license of these files aand also after I heard that Defoma gets deprecated I have added them, also in the hope of getting less bug reports of "PDF file XYZ" does not print.
<smoser> cjwatson, are you going to tell me "go fly a kite" on bug 599840 ?
<ubottu> Launchpad bug 599840 in grub2 (Ubuntu) "grub2 does not special case xen domU kernels" [Undecided,New] https://launchpad.net/bugs/599840
<cjwatson> smoser: shouldn't think so, although I'll probably push it upstream
<tkamppeter> pitti, the cmap-adobe-* packages are only for CJK (Chinese, Japanese, Korean), the files I added are only for no-CJK (Latin, Russian, ...) so with my addition we should have a complete set now.
<tkamppeter> pitti, -cns1 is Simplified Chinese, -GB1 is Traditional Chinese, -japan1/2 is Japanese, -korea1 is Korean.
<pitti> tkamppeter: so how were we able to do without those maps until lucid?
<pitti> tkamppeter: I'm trying to find out whether we can identify the cases where we do need them and handle them on demand
<tkamppeter> pitti, probably with many files not rendering and us no knowing why.
<tkamppeter> pitti, note also that Defoma is deprecated, Defoma can perhaps have replaced a part of the functionality of CMaps.
<Chipzz> tkamppeter: what is defoma being replaced with?
<pitti> tkamppeter: ok, thanks
<pitti> tkamppeter: btw, I'm updating cups to 1.4.4
<pitti> I need to rebuild it anyway against the new poppler
<hallyn> stupid question
<hallyn> what is the trigger to make sbuild apply quilt patches under debian/patches ?
<Daviey> hallyn: Is this for Maverick or SRU?
<hallyn> maverick
<hallyn> so far the seabios package didn't have any patches
<Daviey> hallyn: Consider changing to DEB source 3, the you get it for free.
<hallyn> how do i do that?
<Daviey> hallyn: one moment
<SpamapS> mkdir debian/source && echo '3.0 (quilt)' > debian/source/format
<SpamapS> I think
<Daviey> yup
<hallyn> ok, i looked at the qemu package and didn't see anything there so assumed it woudl jsut do it fo rme :)
<Daviey> hallyn: traditionally it's done with one of the quilt debhelpers (assuming it's quilt)
<hallyn> Daviey: SpamapS: trying, thanks
<hallyn> success!  thanks!
<Daviey> cool!
<Daviey> hallyn: Make sure you comment in the debian/changelog that you switched to dpkg-source 3.0 (quilt) format
<hallyn> Daviey: yup, done, thanks
<Daviey> hallyn: awesome
<Laney> woah, I wouldn't change source format of a package that's in Debian
<Laney> is it?
<hallyn> Laney: well this package isn't taken from debian
<hallyn> (though there is a version in debian)
<pitti> seb128: thanks for the g-i-t fix! how much smaller is it now?
<hallyn> alas it has to be closely tied - and hacked up - to match the qemu version, which also is different from the debian versions.  hopefully we can work on that after 0.13
<pitti> seb128: I'll upload a new cups to drop the old libpoppler5, FYI
<cjwatson> hallyn: FYI, in the cause of understanding the model - sbuild isn't responsible for applying patches
<Daviey> Laney: *everthing* hallyn is working on is seperate from Debian :(
<seb128> pitti, some 2.4meg
<pitti> seb128: cheers
<pitti> so with that and new cups, 3 down, 17 to go..
<cjwatson> hallyn: sbuild extracts the package with 'dpkg-source -x', and calls dpkg-buildpackage (or an equivalent interface), which ends up basically doing 'debian/rules build && fakeroot debian/rules binary'
<cjwatson> hallyn: the old model is that you have debian/rules apply the patches somewhere; the 3.0 (quilt) model is that dpkg-source -x applies the patche
<cjwatson> *patches
<cjwatson> (not meaning this to come across as pedantry, but sometimes it helps to know what calls what)
 * Daviey has never known a geek that is a pedant.
<hallyn> cjwatson: thanks.  yeah i never use dpkg-buildpackage by hand, and dunno how it works, but was aware that sbuild uses them :)
<hallyn> so dpkg-source applies that patches now.  that makes sense
<hallyn> thanks
<pitti> seb128: oh, and I'll upload a new anthy with a dependency fix, another 3 MB :)
<seb128> pitti, nice, still some way to go though
<ogra> Daviey, i know some greeks that are pedants :)
<Daviey> heh.
<tkamppeter> Chipzz, I do not know, are there any font experts around?
<smoser> hi. i'm building uec image and hitting a bug in pycentral or pyyaml
<smoser> http://uec-images.ubuntu.com/maverick/20100629.1/log.stdout.stderr
<smoser> pycentral pkgremove: package python-yaml is not installed
<smoser> is that known and in progress of being fixed ?
<slangasek> directhex: hi, do you have a build log for the current mono armel failure in experimental?
<Daviey> smoser: I guess you've seen it's newly built, ScottK might be the best person to speak to.
<directhex> slangasek, no, the lack of experimental arm buildd gets in the way. i can fire off a build on agricola though
<slangasek> directhex: ah. I thought it was reported to FTBFS on armel in Debian?
<directhex> slangasek, not formally. we're evaluating using it for squeeze, so i started experimenting. and i'll get it in the neck if i upload something to maverick which breaks on ubuntu's ARM
<slangasek> heh, I thought mono was already broken on armel in Ubuntu?
<directhex> slangasek, it's just crap. that's a primary motivator - 2.6.3 drops from 43 test suite failures to 7. and i'm trying to extract promises of a 2.6.6 in time for feature freeze
<directhex> (versus lucid's 2.4 branch snapshot, this is)
<slangasek> directhex: do you have a merge of 2.6.3 for Ubuntu that would be useful as a starting point for testing?
<directhex> slangasek, i stopped plans to prepare one when i ran into the ARM trouble. the only ubuntu changes these days are depends/recommends/suggests fiddles, afaik
<slangasek> ok
<directhex> slangasek, oh, i uploaded the debian package to my PPA, if it's any easier to work with from there
<smoser> Daviey, what is newly built? https://launchpad.net/ubuntu/+source/pyyaml is 7 days old
<directhex> https://launchpad.net/~directhex/+archive/monoxide?field.series_filter=maverick
<directhex> slangasek, actually, i think i *might* have a build log. hang on
<directhex> no, bugger, that's amd64. wonder why i saved THAT
<pitti> Riddell: hm, http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html says that koffice is uninstallable, do you already know why?
<Riddell> pitti: koffice is build dep waiting on pstoedit which I had moved to main but seems to have slipped back into universe
 * Riddell moves it to main again
<pitti> Riddell: that would be a binary dep then, I guess?
<pitti> Riddell: might have fell victim to a c-m cleanup during the time koffice wanted to go to universe
<pitti> if that was me, sorry about taht
<pitti> but pstoedit makes much more sense as a runtime dependency
<Riddell> pitti: yes it's a runtime dep (although we keep it as a build time dep too to keep the build log cleaner)
<pitti> Riddell: right, understood
<pitti> Riddell: also seems to pull in a new package create-resources
 * pitti promotes back the other bits
<directhex> for reference, agricola.debian.org is slow. i could do with a quad-core 2.26ghz arm bof to test this stuff
<pitti> Riddell: and libspnav and librcps
<cjwatson> ogasawara: FYI, I've moved the kernel upload permissions to be attached to the ubuntu-kernel-uploaders team.  If this breaks anything (either upload permissions for the four of you, or the ability to target bugs to releases), then please let me know
<ogasawara> cjwatson: will do, thanks
<sbeattie> bdrung: pong?
<SpamapS> so this MIR is in status "In Progress" but unassigned : https://bugs.launchpad.net/ubuntu/+source/libmemcached/+bug/586638
<ubottu> Launchpad bug 586638 in libmemcached (Ubuntu) "[MIR] libmemcached" [Undecided,In progress]
<SpamapS> does that mean it needs to be added to a seed next?
<Daviey> smoser: Does it, where?
<Daviey> smoser: I'm seeing the build as 6 hours old.
<pitti> RAOF: can we please drop /usr/share/doc/xserver-common/changelog.gz? it's almost a MB, and we are despearate for CD space
<pitti> RAOF: it's a simple fix in debian/rules, and I'm happy to upload it, but I can't commit to git
<Z-RAY_> after amateur tries to update MLT to 0.5.6 i have left without ffmpeg modules and even ffpmeg is installed, kdenlive says that some not installed at all. also it says that some sound module is not installed. i spent all day to make "lines and dots" bug dissappear (white lines and dots - was promised to be fixed in MLT 0.5.5) and i couldn't make it, even worse - now modules "avformat module", "Quimage module", "Title module" are missing and reinstalling
<Z-RAY_>  of the program and ffmpeg does not helping.
<Z-RAY_> help me please to make this thing work correctly. my skype is "woanerges", or write me here. please, bro's, come on, i need some support here!
<Z-RAY_> white dots and lines examples:
<Z-RAY_> http://kdenlive.org/sites/default/files/shot1_0.png
<Z-RAY_> http://www.youtube.com/watch?v=nrFXr_bx2a0
<ogra_cmpc> NCommander, grmbl
<smoser> Daviey, you were right. i was looking at "seven days ago".  The timestamp on the changelog. the build is fresh.
<bdrung_> sbeattie: ping
<sbeattie> bdrung_: what's up?
<bdrung_> sbeattie: is the replaces in bash-completion still required (bug #389633)?
<ubottu> Launchpad bug 389633 in bash-completion (Ubuntu Karmic) "package svk (not installed) failed to install/upgrade: trying to overwrite `/etc/bash_completion.d/svk', which is also in package bash-completion" [Medium,In progress] https://launchpad.net/bugs/389633
<bdrung_> sbeattie: the conflicting version was only available in the development release.
<sbeattie> bdrung_: hrm? svk 2.2.1-0ubuntu1 was available for jaunty; I don't know offhand anymore if svk 2.0.1-1ubuntu3 in hardy contained it. However, for maverick, it should be okay to drop, as people upgrading should have come from lucid.
<sbeattie> (and thus should have the updated version of svk that doesn't contain the bash completion file)
<bdrung_> sbeattie: i looked at the history - svk was removed from lucid
<sbeattie> bdrung_: hah, so it was.
<bdrung_> sbeattie: so we just need to add the replaces to bash-completion in karmic, right?
<sbeattie> bdrung_: for karmic, I *think* both replaces and conflicts are needed to ensure that on upgrades from jaunty, svk gets upgraded first.
<ogra_cmpc> lamont, somehow i end up with the subarch attached to the project name in the livefs filename, i'm glaring at the code but dont get why
<lamont> ogra_cmpc: because it hates you?
<ogra_cmpc> i.e. i suddenly get livecd.ubuntu-netbook-omap.ext3
<lamont> I mean, I'm not sure.
<Kano> hi, why does my cpu run with lowest speed with maverick
<ogra_cmpc> which makes debian-cd or rather find-live_filesystem fail indeed
<lamont> prolly from fixing the subarch - that is, you might have not actually been the one to introduce this
<lamont> ogra: what should it say?
<ogra_cmpc> well, i only reverted to code that was there in luciod
<ogra_cmpc> lamont, nothing, i'm looking for ideas, i dont see the issue
<lamont> looking
<ogra_cmpc> i see FSS="$FS${SUBARCH:+-$SUBARCH}" in livecd.sh
<ogra_cmpc> but that line wasnt touched since lucid
<Kano> which livecd.sh?
<ogra_cmpc> so i dont get why FSS would be mangled while it wasnt before
<ogra_cmpc> Kano, the one from livecd-rootfs
<lamont> ogra: so...  in the past, SUBARCHARG only got set if you said -s.. now it unconditionally gets set
<lamont> no, my bad
<ogra_cmpc> your bad ?
 * ogra_cmpc cant imagine
<lamont> no
<ogra_cmpc> the subarcharg stuff in buildlivecd is fine, its definately somewhere in livecd.sh
<lamont> I misread when it got set
<lamont> no clue
<lamont> I suppose we could do a -x run for giggles
<lamont> ogra_cmpc: say the word and I'll tweak it on acron
<lamont> acorn, even
<ogra_cmpc> phew that might produce a 500M log
<lamont> not all that bad, really
<lamont> there aren't all that  many commands in livecd.sh
<ogra_cmpc> well, i'm pretty sure its the abive line that mangles FSS but that was added by infinity ages ago
<ogra_cmpc> so i dont get why its changing just now
<lamont> in rev 116, for that matter
<lamont> brb
<ogra_cmpc> yep
<ogra_cmpc> i wonder if FSS was chnaged in a later line before and that reformatting was dropped
<lamont> how many images are you handing it?
<ogra_cmpc> only omap3 and 4 (for A2 even only omap3)
<lamont> hrmpf
<ogra_cmpc> for me it looks like FSS=$FS would be fine but why would that not have caused issues in lucid
<ogra_cmpc> lamont, 28.2 was correct (it didnt have SUBARCH set at all)
<ogra_cmpc> sadly the missing subarch made us miss a kernel/initrd
 * lamont has to run off for a while
<ogra_cmpc> lamont, i dont get the FSS line and i think i'll just change it to FSS=$FS for now, apart from armel noboduy is using subarches yet anyway
<BlackZ> seb128: could you re-try the build of bug-buddy ? the bug has been fixed by didrocks
<seb128> BlackZ, we will yes
<ogra> lamont, so i guess initially the FSS mangling was added for the ps3 build but looking at cdimage and debian-cd i dont get how that would ever have worked
<cjwatson> ogra: it certainly worked at one point
<ogra_cmpc> cjwatson, thats very weird since i see no code that uses a livefs thats named livefs.ubuntu-ps3.squashfs, there is certainly no special casing in find-live_filesystem
<ogra_cmpc> what bothers me more though is that livecd.sh seems to suddenly produce these filesystems for armel while it didnt for lucid builds
<ogra_cmpc> i have worked around that for now but i still do get why behavior changed at all
<ogra_cmpc> s/do/dont/
#ubuntu-devel 2010-06-30
<directhex> slangasek, i got the error!
<directhex> it's "illegal instruction" ^_^
<slangasek> oh?
<slangasek> reproduced in what context?
<directhex> slangasek, building 2.6.3-2 on the debian armel porterbox
<directhex> http://retro.apebox.org/log.txt
<slangasek> ok
<slangasek> that may be a Debian-specific failure, then, since the target instruction set on Ubuntu armel is different
<directhex> (the error is misleading - it says the monolite (bootstrap compiler) install it out of date, as a result of the illegal instruction)
 * ogra would suggest doing a testbuild in an armel PPA of that same package 
<directhex> slangasek, it's debian-specific in that it happens on debian - but it doesn't happen with the upstream 2.6.3 tarball, only once the diff is applied. so it's a regression introduced by the ubuntu patches. plus i can't verify whether it works on ubuntu, since i have no access to ubuntu porter resources
 * slangasek nods
<directhex> ogra, i don't have access to an armel ppa, but feel free to copy in the source package from https://launchpad.net/~directhex/+archive/monoxide?field.series_filter=maverick
<ogra> directhex, i'm sadl very busy with other stuff, but i guess someone from the linaro team shoudl be able to help you with a ppa upload, alternatively you need to wait until after A2
<slangasek> directhex: a test build here gets past that point, failing only later building docs when it runs my box out of memory
<RAOF> pitti: Sure, I'll drop the changelog.  The recent upload should have helped - that changelog used to be in *all* the xserver packages.
<slangasek> directhex: what's the CPU of the Debian armel porterbox?
<directhex> slangasek, oh? that's valuable info. sounds like it's the arch detection stuff that's borked then
<slangasek> yeah
<directhex> slangasek, looks like arm5
<directhex> directhex@agricola:~$ uname -m
<directhex> armv5tel
 * slangasek nods
<ogra> thats arm'v'5 :)
<ogra> dont forget the v ;)
<directhex> what's the v?
<ogra> version ... arm5 points to a core while v5 points to a spec
<directhex> /proc/cpuinfo says thumb, i don't know if thumb2 is something else
<ogra> arm5 is significantly older than anything you can use today :)
<ogra> thumb2 is the newer implementation
<directhex> is it reported differently on hardware where it's available?
<slangasek> thumb2 is different than thumb, but I don't know that it shows differently in /proc/cpuinfo
<slangasek> apparently not
<ogra> it does
<slangasek> ogra: how is it different?
<RAOF> ls
<RAOF> *sad face*
<directhex> i've looked at this code lately more than i'd like, i know mono parses /proc/cpuinfo to detect cpu abilities, including thumb... but i don't think the ubuntu patch accounts for thumb versus thumb2
<ogra> ogra@babbage2:~$ cat /proc/cpuinfo |grep Features
<ogra> Features	: swp half thumb fastmult vfp edsp thumbee vfpv3
<ogra> hmm, no, i lied
<ogra> i thought it was exposed
<slangasek> what's 'thumbee'?
<ogra> embedded thumb iirc
<ogra> not relevant here
<directhex> it'll take me another age to test the theory, but i guess http://git.debian.org/?p=pkg-mono/packages/mono.git;a=commitdiff;h=c8243c343373c8bfbf10f037eb6ac8a5e1649db3 is the problem commit
<ogra> the thumb2 instructions are definately available in all v7 cpus so a check against armv7 should suffice to enable thumb2
 * slangasek nods
 * ogra assumes you read https://wiki.ubuntu.com/ARM/Thumb2
<slangasek> directhex: does /proc/cpuinfo show 'swp' there?
<directhex> slangasek, yes
<directhex> Features        : swp half thumb fastmult edsp
<slangasek> oh, that's in the existing code anyway
<ogra> and also https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
<directhex> i'm in the wrong timezone to work on this stuff, i think -_-
<slangasek> directhex: I'd be surprised if that commit causded it, the GCC builtins shouldn't be outputting non-armv5 code on Debian
<slangasek> -d
<directhex> slangasek, i'll have to try with that branch reverted, then. there are only three ubuntu arm patches, that one looked most suspicious
<ogra> i think that one was supposed to fix the thumb porting issues
<ogra> and i assume it comes from asac
<directhex> yes
<slangasek> oh, that commit also includes the changes to tramp-arm.c
<directhex> i really doubt http://git.debian.org/?p=pkg-mono/packages/mono.git;a=commitdiff;h=b0c83ce0cf237768475d0c683f192ce2b3941af0 is the bad one
<slangasek> that's a more likely culprit than the GCC builtins
<slangasek> directhex: don't suppose you have a disassembly of the illegal insn?
<directhex> slangasek, let me try something...
<ogra> your first commit is definatley to fix the use of the swp asm instructions in the code
<ogra> your second commit just enables vfp
<ogra> i'm pretty usre neither will break the code with the right compiler settings
<ogra> *sure
<ogra> directhex, i would try to buiuld with -marm that should disable thumb and should use the old code path
<ogra> and find out what fpu settings debian arm code should use and set that explicitly
<ogra> that way you should exclude both patches
<slangasek> the Debian package passes --with-fpu=NONE
<ogra> so that already disables the second commit that was pasted here
<ogra> -marm should switch off all thumb usage
<directhex> would you believe i just lost access to the debian arm porterbox, at the very moment where i worked out how to get mono to give me the asm instructions it wants to use?
<ogra> and use the former code path that was patched in the first commit
<directhex> ssh: connect to host agricola.debian.org port 22: Network is unreachable
<directhex> i think $DEITY is telling me to go to bed
 * slangasek is logged in still
<directhex> aha, just came back
<directhex> Program received signal SIGILL, Illegal instruction.
<directhex> 0x406b50c0 in ?? ()
<directhex> sigh, that's not very helpful
<directhex> i'm going to bed, i should have gone to bed an hour ago
<directhex> tomorrow i can bug the debian arm guys to verify which cpu i'm supposed to be building for precisely
<ogra> directhex, did you look at the wikipages i posted above ?
<ogra> the second one has a nice table
<cjwatson> ogra: find-live-filesystem lack of special-casing - um, what's this bit then?
<cjwatson> case $ARCH in
<cjwatson>         *+*)
<cjwatson>                 LIVEPROJECT="$LIVEPROJECT-$SUBARCH"
<cjwatson>                 ;;
<cjwatson> esac
<slangasek> directhex: armv4t is the minimum CPU supported in Debian: http://wiki.debian.org/ArmEabiPort#ChoiceofminimumCPU
<cjwatson> argh, that's only in the public branch, not in the deployment branch!
<ogra> cjwatson, heh, thats why i didnt find it
<cjwatson> ogra: it's in a different place now, but it should still work
<cjwatson>                                 echo "$LIVECD/$DIST/$LIVEPROJECT${SUBARCH:+-$SUBARCH}/current/livecd.$LIVEPROJECT.$ITEM"
<cjwatson> ah, wait, there's no subarch in the basename now
<ogra> right
<ogra> thats been my prob
<cjwatson> ogra: r1079 in the deployment branch
<cjwatson> message:
<cjwatson>   drop the dupliacte reference to  in the url, to match current filenames
<cjwatson>   on the livefs buildds
<ogra> livecd.$LIVEPROJECT${SUBARCH:+-$SUBARCH}.$ITEM is what livecd.sh produces
<ogra> cjwatson, the paths are correct, i have issues with the filenames
<ogra> and more so with the sudden change in livecd.sh behavior than with cdimage or debian-cd
<ogra> since i cant explain why it started doing that
<cjwatson> well, go back to say gutsy, find the relevant code, and then bisect
<ogra> well, i added a workaround for now to suppress mangling of $PROJECT with teh subarch under armel
<ogra> the thing is that it didnt behave like that in lucid ... sadly we didnt build images in maverick until now so i cant exactly pinpoint when it changed behavior
<ogra> no need to go back that far
<slangasek> er, I think that change came from NCommander
<ogra> he didnt touch anything that could have caused this
 * ogra spent his whole evening looking through that
<cjwatson> ogra: oh, I understand
<cjwatson> wait, do I
<ogra> slangasek, FSS="$FS${SUBARCH:+-$SUBARCH}" is the offending code ... and that was added when we started to support powerpc-ps3
<cjwatson> but that isn't offending
<ogra> well, thats what mangles the filename
<cjwatson> IMO, cdimage is wrong if it's failing to download subarch-aware names
<ogra> but apparently it never took effect until now
<cjwatson> unmangling it for just one architecture was a distinctly unhelpful workaround
<cjwatson> now we have to special-case an architecture
<cjwatson> please undo that, and let's fix it properly
<ogra> hrm
<ogra> i really see no point in subarch aware names in the first place with the current livecd build structure
<cjwatson> changing it for ONE ARCHITECTURE is unhelpful
<ogra> since subarches are divided by subdir on the build machine
<cjwatson> I don't care what the result is, but it has to be consistent across architectures
<ogra> well, then we should drop it for all perhaps
<ogra> i didnt have the balls to do that at the dawn of an alpha
<slangasek> no, what we *should* do is get rid of the subarch name in the directory path
<ogra> why ?
<slangasek> because that's gratuitously different
<ogra> that will make us end up with one huge dir that contains a ton of filesystems and logs
<cjwatson> also, I think the different filenames may actually be necessary
<ogra> on the livefs builder
<cjwatson> livecd-rootfs builds different subarches in the same directory, on its side - they get copied off to separate places later
<ogra> slangasek, take a look at acorn.buildd
<slangasek> ogra: you mean like we do for all the other archs except for armel and ps3 on http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ ?
<slangasek> yes, I'm familiar with the structure
<cjwatson> I think that getting rid of the different basenames would introduce bugs in special cases
<cjwatson> and I believe I agree with slangasek
<cjwatson> tacking subarch onto the *project* name is just weird
<cjwatson> doing that in the basename is ugly but not that intrusive; having it in the directory name is really, really odd
<slangasek> lool tried to remedy this once before, but ran into timing constraints; I'm not saying we should make this change before a2 either, just that it's where we should end up
<cjwatson> in future, though, please do not introduce architecture-specific naming structures
<ogra> that will surely require a ton of changes in different places
<cjwatson> ogra: I will take care of it
<ogra> ok
<cjwatson> different places: two, possibly three
<ogra> mainly find-live-filesystem i guess
<cjwatson> slangasek: well, I think it was put in the directory because each subarch is built independently, and so needs separate datestamps
<ogra> cjwatson, i didnt introduce anything, i reverted to old behavior
<cjwatson> livecd-rootfs (1.128) maverick; urgency=low
<cjwatson>   * do not mangle the project name by attaching the subarch to it on armel,
<ogra> i agree with a bad hack
<cjwatson>     this results in livefs names that confuse find-live_filesystem
<cjwatson>  -- Oliver Grawert <ogra@ubuntu.com>  Tue, 29 Jun 2010 23:04:10 +0200
<cjwatson> +    case $TARGETARCH in
<cjwatson> +        armel)
<slangasek> cjwatson: that's already the case for ports vs. main, which nevertheless share a directory tree :)
<cjwatson> slangasek: that's true
<cjwatson> ogra: now either armel+* is broken, or powerpc+ps3
<ogra> cjwatson, right, as i said, i agree it was a hack, but target was to get back the behavior i has through the last 4 releases
<cjwatson> but don't say you didn't introduce something when you did
<cjwatson> that's really annoying
<cjwatson> I will see if it's fixable tomorrow before starting CD builds
<ogra> i only tried to make livecd.sh behave as it did three months ago
<ogra> since *something* changed it's behavior and i still dont know what that was
<cjwatson> I don't object to fixing things for alphas by way of hacks; I've done that often enough myself.  My point, which I've made but which I seem not to be making effectively, is that those hacks need to not be architecture-specific like this.
<cjwatson> there is no way that the architecture-specific-ness of this hack could have helped
<ogra> i agree, it was kind of a last resort thing
<slangasek> cjwatson: do you want me to have a poke at this this evening?
<cjwatson> slangasek: if you like; I have to wait for ubiquity in the morning anyway
<slangasek> well, one less thing for you to worry about in the morning
<ogra> cjwatson, i muchly would have preferred to find out *why* it changed at all
<cjwatson> what worries me is that we will build up a pile of these architecture-specific hacks, and then the logic to deal with them on the cdimage side will become completely incomprehensible instead of mostly incomprehensible.
<ogra> but either i'm blind or dumb, i cant see a code change that causes that change in behavior
<ogra> i wouldnt have done an arch specific hack at all if i could have found the root cause
<slangasek> ogra: yeah, I don't see the change either. :/
<cjwatson> nor I, but I also don't see why it was failing to include the subarch in the first place and so as I say I consider the new behaviour better
<cjwatson> I wonder if there was a stale version of BuildLiveCD in use
<ogra_cmpc> it definatley used the subarch var during builds
<ogra_cmpc> the armel kernel selection fully depends on it
<ogra_cmpc> cjwatson, you mean it mangled the naming post build for armel ?
<cjwatson> I don't know
<ogra_cmpc> thats a possibility i didnt take into account
<cjwatson> I don't think that's what I said though
<cjwatson> I wasn't that specific :)
<ogra_cmpc> no but its a possibility
<slangasek> does BuildLiveCD also get updated on every build?
<ogra_cmpc> nope
<slangasek> ok
<ogra_cmpc> lamont wanted to have some control over it
<ogra_cmpc> argh
 * ogra_cmpc reverts his change completely 
<slangasek> ogra_cmpc: I already did so and am about to upload... ?
<ogra_cmpc> oh, ok
<slangasek> and then will get cdimage sorted
<ogra_cmpc> i just started a testbuild and noticed that TARGETARCH is undefined at the point where i introduced the change :(
<ogra_cmpc> so it wouldnt have worked anyway
<RAOF> Speaking of cdimages - would anyone like to sponsor an xorg-server upload to shave ~1MB off xserver-common by dropping the upstream changelog as per pitti's request?
<cjwatson> RAOF: fire me a source package
<cjwatson> or a branch
<RAOF> cooperteam.net/Packages/xorg-server_1.8.1.902-0ubuntu2_source.changes
<cjwatson> can't connect
<TheMuso> me neither.
<RAOF> Failing that, debcheckout xorg-server and grab the ubuntu branch.
<cjwatson> HEAD says 500 Can't connect to cooperteam.net:80 (connect: Connection refused)
 * ogra_cmpc wonders if we couldnt drop OO.o in favour of zoho-weboffice at some point and win 100MB
 * RAOF is IRCing from cooperteam.net, so I wonder what's wrong.
<cjwatson> debcheckout will take a while
<TheMuso> Weboffice = accessibility pain, at least for me.
<ogra_cmpc> TheMuso, ah, thats a valid point
 * TheMuso is somewhat opposed to a lot of things that are done on the web, that could just as easily be done in client apps running on the desktop.
<TheMuso> I.e, IMO the web is not the be all and end all.
<cjwatson> RAOF: dump it on people.c.c for me?
<ogra_cmpc> we're using it on armel quite successfully but i dont think anyone focused on a11y
<TheMuso> ogra_cmpc: Considering lots of those devices are touch screen based anyway, a11y is going to need a lot more work than just web office etc.
<ogra_cmpc> TheMuso, surely not but there are usecases where it makes sense to put the load on an extrenal server
<TheMuso> ogra_cmpc: I agree to a point.
<ogra_cmpc> TheMuso, well, there are these arm netbooks that will *come soon*
<ogra_cmpc> they wont be touch based
<TheMuso> ogra_cmpc: Ah ok, interesting.
<ogra_cmpc> though they come "soon" since two years
<ogra_cmpc> :)
<TheMuso> ogra_cmpc: heh
<TheMuso> In terms of touchscreen based accessibility, currently Apple is the only one who has it done right
<RAOF> cjwatson: http://cooperteam.net/Packages/xorg-server_1.8.1.902-0ubuntu2_source.changes should work now.
<ogra_cmpc> we'll get there
<ogra_cmpc> currently ubuntu isnt great on touchscreens anyway, it can only get better
<cjwatson> RAOF: uploaded, thanks
<TheMuso> ogra_cmpc: ah ok
<Meep> Hi - is there any way that you can track an RSS feed for PPA builds?
<micahg> Meep: #launchpad would be a more appropriate place to ask
<Meep> Thanks
<ScottK> cjwatson: We've now got our first member of kubuntu-dev who wasn't MOTU first, which caused me to notice that kubuntu-dev isn't a member of ubuntu-dev.  I assume this is just an oversight ...
<ScottK> cjwatson: Nevermind.  It's there, I just can't read late at night.
<SpamapS> wow.. buildd's on launchpad seem crazy busy... 21+ hours
<pitti> Good morning
<pitti> RAOF: right, I saw the Debian changelog for that; but it's another easy MB :)
<pitti> RAOF: thanks!
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back :)
<dholbach> how's life?
<pitti> pretty good! yay summer
<dholbach> yeah :-)
<dholbach> finally
<pitti> ccheney: is that oo.o armel segfault something new?
<pitti> ogra_cmpc: is the OO.o armel failure blocking armel alpha-2 images, or did we unseed it there?
<pitti> ccheney: (the segfault during build, I mean)
<dholbach> apachelogger: can you please update https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep?
<dholbach> Riddell: ^ or maybe you can write something for apachelogger? I have no clue what widgetcraft is
<dholbach> and I want to announced UDW today
<pitti> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<pitti> yesterday's firefox update fails if firefox-2 is installed, see bug 600022
<ubottu> Launchpad bug 600022 in firefox-3.0 (Ubuntu Hardy) "package firefox 3.0.19 nobinonly-0ubuntu0.8.04.1 failed to install/upgrade: trying to overwrite `/usr/share/bug/firefox/presubj', which is also in package firefox-2" [High,In progress] https://launchpad.net/bugs/600022
<pitti> and due to the newly split out -branding package, it doesn't fail gracefully enough, firefox-3 is rather broken after apt fails over
<micahg> firefox (3, the default) not firefox-3
<pitti> ok, so discussion in #u-desktop confirms the "high" importance, not "critical"; affected people have firefox-2 as a temporary fallback, and only few people have that installed in the first place
<pitti> and we can push out a fix in some two hours
<cjwatson> pitti: agreed
<apachelogger> dholbach: described
<dholbach> thanks apachelogger
<dupondje> http://ubuntu.dupondje.be/opal.debdiff => does this look ok, would like to get it merged asap, to get newer Ekiga into Maverick :)
<geser> dupondje: do you have an idea where from that non-Ubuntu changelog entries come from?
<geser> dupondje: minor note: we use "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" as maintainer now for main and universe
<geser> dupondje: and libcelt-dev and libpt-dev are in universe
<geser> dupondje: forget the last comment; I just saw that that opal is in universe too, so the other build-dependecies from universe are not a problem and opal could even by synced instead of merged
<dupondje> https://launchpad.net/ubuntu/+source/opal
<dupondje> here it says main ? :p
<Laney> not for Maverick
<geser> dupondje: don't look at the "Component" as it set from the last upload but look at the table below. At the point of upload opal was in main but got demoted (moved to universe) later
<dupondje> ah I see :) didn't notice
<dupondje> could you sync it ?
<seb128> pitti, we should maybe move the sdl discussion there
<seb128> pitti, I don't know about libsdl1.2debian-udeb
<seb128> but maybe cjwatson can reply to whether it's required or not nowadays
<seb128> cjwatson, we were discussing stopping building libsdl with directfb since that's the only thing in maverick bringing directfb on the CD
<cjwatson> we don't need anything to do with directfb in udebs any more
<pitti> nice
<pitti> looking at that then
<cjwatson> libsdl1.2debian-udeb itself is still in Debian unstable so I guess something is using it
<cjwatson> but anything directfb-ish can go
<pitti> seb128: I prepare/test that now and upload after alpha-2; for a2 we have to resort to dropping langpacks, I think
<pitti> (I already dropped some, with that and yesterday's fixes we should be back in size I think)
<seb128> pitti, ok
<lifeless> klingon can probably go
<lifeless> and latin
 * lifeless is teasing and knows they aren't on the CD already
<pitti> unfortunately we had to drop languages which are even more popular than Klingon
<lifeless> pitti: there are more popular languages? Oh Noes.
<pitti> lifeless: I wonder what "core dump" menas in Latin
<pitti> "means"
<lifeless> probably something about going to the toilet in the forest.
<jml> si haec verba legere potes, tibi nimium eruditio est
<bilalakhtar> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<bilalakhtar> bug #595265
<ubottu> Launchpad bug 595265 in gwibber (Ubuntu) "Can not add Facebook account as add button not displayed after authorisation." [Critical,Triaged] https://launchpad.net/bugs/595265
<pitti> bilalakhtar: did that happen in a post-lucid upgrade?
<bilalakhtar> pitti: yes
<bilalakhtar> pitti: an update pushed on 2010-05-03 to maverick
<pitti> oh, maverick
<bilalakhtar> pitti: and 2010-05-03 on lucid
<pitti> bilalakhtar: that isn't an update to lucid then, though
<pitti> oh, ok
<bilalakhtar> pitti: https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/gwibber/lucid-updates
<bilalakhtar> revision 38 ^^
<pitti> bilalakhtar: thanks
<pitti> bilalakhtar: I'll assign it to the appropriate developer and milestone it accordingly; thanks for pointing out!
<bilalakhtar> pitti: you're welcome. I have always been hearing about you, having the highest karma on lp. talking to you for the first time!
<pitti> "Don't allow people to click "Add" before we have enough information
<pitti>       from facebook to add the account"
<pitti> so this is very likely a regression from that indeed
<pitti> bilalakhtar: nice to get to know you :)
<BlackZ> pitti: could you look at bug #598874 when you have time ? libmpcdec is in main and it would be great to get fixed
<ubottu> Launchpad bug 598874 in libmpc (Ubuntu) "Please sync libmpc 2:0.1~r459-1 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/598874
<pitti> seb128: new sdl working great here \o/
<seb128> pitti, nice!
<ogra_cmpc> pitti, we have weboffice by default on arm images, OOo only needs to be installable by release day
<ogra_cmpc> pitti, so dont worry
<pitti> ogra_cmpc: ok, thanks; I dropped OO.o from armel
<pitti> http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html looks quite okay now
<ogra_cmpc> pitti, you dropped ?
<ogra_cmpc> it shouldnt be pulled in at all
<ogra_cmpc> since lucid
<pitti> ogra_cmpc: I dropped it from ubuntu-desktop [armel], yes
<pitti> ogra_cmpc: perhaps you mean netbook?
<ogra_cmpc> oh, desktop
<ogra_cmpc> yeah, i dont care for desktop
<ogra_cmpc> nobody build it
<ogra_cmpc> *builds
<pitti> right
<ogra_cmpc> we should have a working metapackage on release day that doesnt differ from x86, but .nothing to worry about atm
<pitti> Riddell: hm, koreport is uninstallable because koffice-libs Conflicts/Replaces: it (without version); should the binary just go then?
<pitti> I don't think it breaks actual images, since it's not seeded
<Riddell> pitti: yes that binary can go
<Riddell> files now in koffice-libs
<dholbach> can somebody shove my mail through ubuntu-devel-announce?
<pitti> Riddell: oh, it's already NBS, great
<pitti> dholbach: will do
<dholbach> thanks pitti
<pitti> oh, there was more interesting stuff indeed
<pitti> geser: please prod someone to moderate u-d-a stuff if you send minutes
<Iraq> How install file.tar.zg but learn me step by step please and thank
<tsimpson> Iraq: not here
<Iraq> not your channel
<Iraq> leave me
<Iraq> jealos
<pitti> ogasawara: kernel ddebs> ah, retrieval from crested (amd64 buildd) was disabled since it hanged forever last time I tried it
<pitti> ogasawara: I'm retrieving the last weeks' ddebs and now convert to urllib2 to avoid those hacks in the first place
<pitti> ogasawara: argh, except that python is too old on macquarie, so I can't add a timeout
<pitti> ogasawara: but missing ddebs are trickling in now
<Daviey> jdong / cjwatson / slangasek: I know you probably have your hands full atm with A2 prep, but at some point today; do you think you could ack the SRU of Bug 566792 ; As i really want to make sure it gets through verfication prior to 10.04.1.
<ubottu> Launchpad bug 566792 in eucalyptus (Ubuntu Lucid) "metadata service returns empty data with 200 OK" [High,Confirmed] https://launchpad.net/bugs/566792
<cjwatson> I'll look
<Daviey> cjwatson: super, thanks!
 * cjwatson has a similarly positioned SRU of his own on its way so needs the karma
<cjwatson> in the non-LP sense
<Daviey> heh.
<cjwatson> Daviey: I guess this will trickle into maverick via an upstream merge?
<cjwatson> Daviey: accepted
<Daviey> cjwatson: Yeah, that is great thanks
<Daviey> cjwatson: I intentionally *haven't* pushed this to maverick, as the current version in maverick is a stop gap -waiting on upstream to fix there latest devel branch so we can push it into maverick.  The area that has been fixed in this upload, has had a major rewrite in the upstream devel branch - and i don't want to introduce a false sense of fixedness.
<Daviey> Hopefully upstream will have addressed this in their latest devel branch, but i want the issue there until they drop it to us.
 * cjwatson nods
<pitti> smb: I'm about to release the lot of linux packages for lucid, they look ok from here; did you hear any problems?
<smb> pitti, Not to my knowledge. I haven't heard/or do remember definite feedback on the topic branch packages but I asked twice and anything happening to them is imo their own problem then
<pitti> smb: if you don't fell sure about some of them I can skip them
<pitti> but I'd like to push out at least the main linux and perhaps ec2
<smb> pitti, No push them all. Even if there is anything broken there (which I do not think) it will educate :-P
<pitti> ok
<Tim> This might be a silly question but I've Googled and come up with nothing, how do I flush whatever is caching /usr/lib/bonobo/server/ files.
<Tim> Or at least have the bonobo-activation-server reread the configuration
<micahg> pitti: was the Firefox upgrade stopped on mirrors for all releases or just Hardy?
<pitti> micahg: we didn't actually stop it; it was expected to land much earlier
<micahg> pitti: k :)
<chrisccoulson> pitti - i've uploaded the new version to the PPA now
<pitti> and since affected people have firefox-2 as a fallback, it's not the end of the world perhaps
<pitti> chrisccoulson: yay you!
<chrisccoulson> i'm going to plan some test cases whilst it's building to make sure all the possible upgrade paths still work
<chrisccoulson> but, i must eat first :)
<ccheney> pitti, sorry didn't notice my xchat crashed :(
<ccheney> pitti, i bet the armel crash is due to the removal doko requested
<ccheney> pitti, er code removal
 * ccheney examining the crash now to see if it looks likely
<ccheney> pitti, armel build failed because the buildd couldn't install the depends, or the current log is that way
<ccheney> pitti, if it segfaulted it might be a problem i can fix but the current attempt couldn't install the depends
<ogra> ccheney, dont bother i'm pretty sure we need a working openjdk first, the segfaults are during installation fo cacert's
<ogra> s/fo/of/
<ccheney> ogra: ok
 * ccheney goes back to testing server images
<ogra> doko_, will you take care of openjdk on armel or do i need to poke linaro now ?
<doko_> ogra: please poke linaro, won't have time for this for a while. and linaro does have a work item to update the linaro armel bits
<doko_> openjdk I mean
<ogra> ok
<seb128> kees, hi, did you ever upstream your gdm patch to use login.defs value for getting the uid limit?
<seb128> kees, it doesn't apply to the current version, I've disabled it for now, the work in progress for the next upload but if you want to have a go at updating it that would be nice
<kees> seb128: can't you forward port it?
<kees> seb128: dropping that patch will cause regressions for people...
<seb128> kees, I could yes, they just rewrote this code to be async and the structure you used is not available now
<kees> seb128: which version of gdm are you working on?
<seb128> kees, right, well right now I've no further time to spend on it so I guess I will let the gdm update sit in the vcs until somebody has time for it
<seb128> kees, 2.30.4 but they did quite some refactoring in the stable serie
<seb128> kees, anyway if you have some time and want to do it I would appreciate, otherwise I will see if robert_ancell can do it or delay the update to next week
<kees> seb128: where in vcs is it?
<seb128> kees, debcheckout gdm?
<seb128> lp:~ubuntu-desktop/gdm/ubuntu
<kees> (main is frozen atm anyway, so a delay should be okay)
<seb128> kees, right, it's just that we have a zillion patches to gdm and I spent 3 hours on it today now updating those, so right now I'm in a state where I'm grumpy about people doing changes and not sending those upstream ;-)
<seb128> (not that upstream applied the ones we sent...)
<seb128> kees, anyway if you want to update it that would be nice otherwise I will do it another day
<kees> seb128: right, sorry about that.  I'll update the patch and get it sent upstream.
<seb128> kees, don't feel forced to do it, I just figured I would ask in case ;-)
<kees> seb128: well, since it affects me, it's easy for me to test.  :)
<kees> seb128: vcs says "gdm (2.30.2.is.2.30.0-0ubuntu2) lucid-proposed" ?
<seb128> kees, hum?
<seb128> kees, https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu
<seb128> kees, oh, lucid-proposed is newer than maverick so if you used debcheckout it might have grabbed the lucid serie
<kees> weird, debcheckout did not pull that repo.  anyway, looks good from lp:~ubuntu-desktop/gdm/ubuntu
<kees> ah- yeah, that's why
<kees> seb128: er, you said the patch didn't apply any more?
<seb128> kees, no sorry, it doesn't build anymore rather
<seb128> kees, gui/simple-greeter/gdm-user-manager.c
<seb128> kees, the manager variable is not available to do manager->priv->minimal_uid
<seb128> kees, they changed the code to be async and they don't give the manager to new function now
<kees> seb128: ah-ha! okay, I will continue poking at it.
<seb128> thanks
<seb128> re
<seb128> kees, thanks for the updating the patch ;-)
<kees> oh! sure thing.  :)
 * shadeslayer pokes his head in
<shadeslayer> hi,im working on bug 264752
<ubottu> Launchpad bug 264752 in meanwhile (Ubuntu) "Meanwhile user status detection broken" [Undecided,Confirmed] https://launchpad.net/bugs/264752
<shadeslayer> need a small amount of help tho,the packages debian/rules file has dh_* stuff
<shadeslayer> can i mix it woth cdbs? or is there a simpler way to patch it?
<ari-tczew> Dear developers, as we are after DebianImportFreeze, I appeal to more frequently move syncs from ~ubuntu-archive bug-list.  Thanks.
<cjwatson> well, syncs certainly ought not to be processed preferentially today, as we're in soft freeze for alpha-2.
<cjwatson> we can perhaps do some universe ones
<cjwatson> oldest sync request seems about five days old
<SpamapS> curious, have many people here had success using mentors.debian.net ?
<ari-tczew> cjwatson: I'd like to see global use of syncpackage script, which reduce 100% of work archive admins.
<cjwatson> I'm not going to get into that again, but in short I want to see LP having a sync operation built-in, which reduces archive admin work in the same way but doesn't have the shortcoming of possible inconsistencies due to work being done on the client size
<cjwatson> *client side
<cjwatson> ... actually apparently I am going to get into that again.  whatever.
<kfogel> jcastro: ping
<jcastro> kfogel: hi
<kfogel> jcastro: hey!  A rather exciting project I know, the Decapod / Fluid book scanner software (decapod-project.org) is going to need help getting their client-side software packaged for Ubuntu / Debian sometime in the relatively near future.  What's the best way for them to do that?  They don't know much about packaging themselves; they're developers.
<shadeslayer> kfogel: ask for it to be packaged by debian ? :P
<kfogel> jcastro: (this may well be an FAQ, but there are so many FAQ sheets out there I couldn't find the right one, at least not quickly)
<shadeslayer> kfogel: or #ubuntu-motu maybe
<jcastro> kfogel: ubuntu-motu mailing list might be a good place to start
<kfogel> shadeslayer: yes, thanks.  I have ascertained that mailing debian-mentors@lists.d.o is the way to start on that, but that doesn't guarantee that an Ubuntu package will be rolled, does it?
<kfogel> jcastro: thank you
<shadeslayer> kfogel: it does actually
<jcastro> kfogel: after it's in debian it gets synced back
<shadeslayer> kfogel: all ubuntu software is sourced from debian
<shadeslayer> !sync | kfogel
<ubottu> kfogel: Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
<shadeslayer> has info about syncs as well
<jcastro> kfogel: long term that's what they'll want to do
<kfogel> shadeslayer, jcastro: sorry, I should have said "does not guarantee an Ubuntu package will be rolled quickly", but maybe that doesn't matter so much in this case.
<kfogel> Anyway, above is enough information to get me pointed in the right direction.  Thanks much!
<jcastro> kfogel: https://wiki.ubuntu.com/Upstream <-look uunder "how to get into ubuntu"
<kfogel> jcastro: you rock
 * shadeslayer is all for sleep right now 
<Drakeson> could you please check the package openjdk-6-doc? it is almost empty here (no API documentation unlike what the package description suggests)
<seb128> re
<seb128> cjwatson, do you know if there is any maverick grub bug about unaligned pointer errors after upgrade?
<seb128> cjwatson, I dist-upgrade a box running maverick but which didn't get updated for some weeks and now I get that error instead of grub
<seb128> cjwatson, ignore that, I realized that was the error the issues mentioned in your recent blog post were about...
<SpamapS> even though its after debian import freeze, we can still request new packages to be synced manually from debian, right?
<james_w> SpamapS: indeed
<cjwatson> seb128: right, was about to point you at my blog :) what was it, wrong device.map or just needed dpkg-reconfigure grub-pc?
<seb128> cjwatson, dunno yet, the box doesn't start and I'm a rsync alpha2 isos, I figured I would use it as an opportunity to try alpha2 livecd
<seb128> but I've 2 lucid installs on that box, one that I use regularly and one which is a test install partition
<cjwatson> probably just weren't booting from the grub installation that grub-pc/install_devices thought you were booting from then
<IdleOne> what package handles the auto login?
<kees> SpamapS: the memcached change looks good.  do you need sponsoring of that package?
<pitti> ccheney: hm, it was very far into the build, but it called some java program which crashed; it's not a dependency failure
<pitti> ccheney: anyway, we worked around the problem for now
<SpamapS> kees: I do if you don't mind. :)
<SpamapS> kees: forwarding patch to debian right now btw. :)
<kees> SpamapS: uploaded!  thanks.  :)
<SpamapS> kees: ^5
<kees>      5
<kees>     o/
<ccheney> pitti, yea someone mentioned that earlier today, sorry for my slow response to your comment, i was helping my wife, she is very sick at the moment
 * ccheney is making up missed time while away from the computer at night
#ubuntu-devel 2010-07-01
<Andphe> Hi, anyone can help?, I'm upgrading PHP 5.2 to 5.2.13 for myself and as an excercise
<Andphe> launchpad build the amd64 but not the i386 package
<Andphe> http://launchpadlibrarian.net/51213960/buildlog_ubuntu-lucid-i386.php5_5.2.13.dfsg.1-0ubuntu0~andpheppa1_FAILEDTOBUILD.txt.gz
<Andphe> configure: error: recode extension can not be configured together with: mysql
<Andphe> this is the error message ââ
<Andphe> for what I've research, it's because the config file gets rebuild and the patches are loose
<micahg> Andphe: please try #ubuntu-packaging
<Andphe> micahg:oh, ok, sorry
<micahg> Andphe: np
<un214> you have managed to annoy people [no not just me] pretty thoroughly with plymouth
<un214> I'm trying to take some drastic action to get rid of it -- in my mind there can be no justification for it
<un214> but you managed to wire mountall to plymouth pretty thoroughly so mountall must go as well
<un214> and brings a good chunk of /etc/init with it
<RAOF> Something like plymouth is fundamentally necessary for parallel init to work properly.  You don't have to have the splash enabled.
<un214> I'm about to prove that wrong
<RAOF> For the special-case of not having more than one thing ask for input during boot, I presume.
<un214> what's the second thing that asks during early boot?
<RAOF> fsck, 1 passphrase input per encrypted device, etc.
<un214> easy fix for that one -- attach all encrypted devices before fsck of nonroot
<RAOF> fsck of multiple drives running in parallel?
<un214> my old slackware system handled that pretty darn good
<un214> [in the rare case where fsck needed to ask something it reran it in serial mode]
<RAOF> I guess it comes down to: are you going to enumerate all the things which could possibly ask for input before login, and work around each of them separately?
<un214> I'm actually going to say there should not be any more for any reason
<un214> by the time anything has to ask a boot question except for efs you have a sick system
<un214> and if you want to ask at boot time then it cannot be fixed remotely anymore
<RAOF> (Unless you extend something like plymouth ;))
<un214> it is my judgement the better move is to try to bring up console login, networking, and sshd and wait unless you can't even go multiuser
<un214> [can't mount /usr = fatal]
<RAOF> Yeah, but wouldn't it be cool if it was fatal in a remotely-resolvable fashion? :)
<un214> well if you moved sshd off /usr it would be
<un214> I retooled a system I was using for development once so it could start sshd even if it couldn't remount / rw.
<RAOF> Anyway, you're welcome to work at removing Plymouth from the startup sequence.  I don't think it's a huge issue, though.
<un214> I like your attitude.
<RAOF> And it's solving real problems, so you'll need to re-implement solutions for them.
<un214> it just managed to wrankle a lot of people because for most people it doesn't solve anything interesting
<RAOF> I'm not sure about âa lotâ, but for many people it won't be solving anything interesting, no.  From a distro point of view, though, we need to care about the more general cases.
<un214> I actually worked this problem years ago, and cut about a third off of boot time by bolting a parallel init system on top of inittab
<un214> everything after mount -a can be done in parallel no problem, everything before is not really parallelizable anyway
<RAOF> Except that's not true - it's entirely possible to parallelise things before mount -a (although some of this is in the kernel), and there's dependencies after mount -a.
<un214> I'm really curious how plymouth would handle /dev/console -> /dev/ttyS1
<un214> You see, I'm really concerned as neither plymouth nor mountall have demonstrated the rock solidness I've come to expect from Linux systems.
<dholbach> good morning
<pitti> Good morning
<dholbach> hey pitti
<pitti> ccheney: oh, please don't worry, your wife is much more important :)
<pitti> hey dholbach
<tkamppeter> Can someone tell me which is the default scanning tool in Kubuntu?
<raphink> tkamppeter: I think that would be skanlite
<pitti> tkamppeter: simple-scan
<tkamppeter> pitti, is simple-scan not a GTK application?
<pitti> tkamppeter: argh, sorry, misread
<pitti> tkamppeter: trust raphink, not me :)
<pitti> tkamppeter: (unlucky line break just before "in Kubuntu" in my IRC client :) )
<tkamppeter> pitti, raphink, thanks. I have put xsane | simple-scan | skanlite instead of xsane into the Recommends of hplip-gui now, should avoid unneeded GTK installation for Kubuntu users.
<pitti> tkamppeter: shouldn't that be a suggests rather?
<pitti> tkamppeter: oh, and as for bug 600504, should python-notify be a dependency of hplip-gui then, instead of hplip itself?
<ubottu> Launchpad bug 600504 in hplip (Ubuntu Maverick) "Dependency on python-notify makes hplip unsuitable for servers" [High,Confirmed] https://launchpad.net/bugs/600504
<tkamppeter> pitti, xsane was already in Recommends:, so I added the other there.
<pitti> tkamppeter: hmkay
<tkamppeter> pitti, one would need to check whether hplip-gui works without python-notify. Now I have python-notify also in the Recommends: of hplip-gui.
<pitti> tkamppeter: hplip-gui is fine; the problem was that hplip itself pulled in python-notify, which caused half the desktop to appear in the server isos
<tkamppeter> pitti, this I understand. There were tons of small changes done by the Debian maintainer, he was probably not aware of hplip being used on servers or python-notify pulling so many GUI libraries. Therefore I have introduced hplip-gui earlier.
<Iraqi> Who know APT line for ubuntu please? thanks:)
<Iraqi> and i invite you all to new channel #ubuntu-iq is support all things  :)
<seb128> didrocks, let's move there
<seb128> so current maverick CDs have notify-osd and notification-daemon installed
<seb128> does anybody has a clue why notification-daemon get installed?
<seb128> knowing that notify-osd provides notification-daemon
<didrocks> notify-osd is providing notification-daemon and only notify-osd is in the seeds
<seb128> I've no found any versioned depends on it either that would explain it being pulled in
<smb> pitti, Would you be able to rescue ddebs from the last update? ddebs.ubuntu.com is again stripped of any Lucid
<pitti> smb: I rescued everything yesterday, and fixed the problem of disappearing amd64 ddebs
<smb> pitti, Hm, was I blind this morning then?...
<pitti> no, you aren't
<pitti> smb: the maverick ddebs are back
<pitti> but the lucid ones not
<pitti> smb: but the lucid ones were built ealier than a week ago, so there's nothing to rescue
<pitti> but something on them must be wrong still, since they keep disappearing
<smb> pitti, Right. I feared that would be related to the build time of proposed
<smb> pitti, So I should get together with you right after the next proposed upload to Lucid
<pitti> well, we need to find out why they disappear in the first place; currently RTFS
<pitti> smb: ah, I still have the "-image-debug" hack in place
<pitti> smb: which I should remove now, since the lucid/maverick ones are properly named now?
<smb> Right they are
<pitti> done
<pitti> so the maverick ones should stay now
<pitti> and the next lucid round as well
<smb> Hm, one would hope the hack would be a either or hack and not a one xor the other. :)
<pitti> hm, but now the karmic ones will disappear..
<seb128> cjwatson, pitti: do you have any clue about notification-daemon?
<pitti> seb128: what about it?
<seb128> cjwatson, pitti: or rather about why it's on the current iso, cf backlog half an hour ago or so
<pitti> seb128: will look in a bit, still messing with ddebs
<seb128> pitti, thanks
<smb> pitti, Depends on whether the rebuild of debian would get accepted. ;-) But then this would still leave hardy and jaunty out. Not to mention dapper, though I cannot remember anyone asking for _those_
<pitti> smb: the one-liner to rename the packages certainly would :)
<smb> pitti, I guess I cannot win against that argument. :)
<pitti> so as for the "or" hack, I could change the hack to never clean linux ddebs at all
<cjwatson> seb128: looking
<pitti> but they'd pile up quickly
<seb128> cjwatson, thanks
<smb> Yeah, I think that would soon make is the sworn enemy of IS
 * pitti ponders
<cjwatson> seb128: recommends from libnotify1
<smb> pitti, I would have guessed the hack would be something like if packagename modufied from old way has a matching package in archive or moified the new way has one, then it can stay
<cjwatson> which comes in from python-notify and gnome-settings-daemon (at least)
<seb128> cjwatson, but it's not versioned?
<smb> pitti, But I might think in a too simple way
<seb128> cjwatson, and notify-osd provides notification-daemon
<seb128> cjwatson, that worked in lucid, I don't see what changed...
<cjwatson> "not versioned"?
<cjwatson> oh
<seb128> cjwatson, well the provides should work if the depends is not versioned
<cjwatson> I'll look in more detail
<seb128> thanks
<cjwatson> ah yes, I see
<pitti> smb: ah, I'll just special-case the versions < 2.32
<cjwatson> the thing is, libnotify1 is coming in through a package in the desktop-common seed (python-notify)
<smb> pitti, That sounds simple and reasonable
<cjwatson> notify-osd is seeded in desktop, not desktop-common
<cjwatson> so when germinate is processing desktop-common, it doesn't yet know that notify-osd is to be preferred
<cjwatson> (or, put another way, what handles notification-daemon in flavours other than Ubuntu?)
<smb> pitti, And if we ever get Karmic to the other side, we can lower that barrier
<cjwatson> changing the ddeb names for karmic is a much smaller proposition than rewriting the whole packaging, and does not depend on the latter in any way
<cjwatson> I would have no problem with changing the ddeb names being part of an SRU
<cjwatson> that change on its own would be effectively reviewable
 * smb covers
<smb> I don't want to start over on that thread. I am awaiting whatever comes from above
<seb128> cjwatson, hum ok, thanks, what would be the best way to solve that then? having notify-osd in desktop-common could be an issue for other desktops?
<seb128> didrocks, ^
<cjwatson> seb128: maybe avoid using python-notify in stuff that's in desktop-common
<didrocks> seb128: thanks, saw that, so it's an install order issue as we inferred. thanks cjwatson :)
<cjwatson> so either rip the python-notify dep out of hplip, or move hplip to the various desktop seeds rather than having it in desktop-common
<seb128> I think I've read pitti talking about that earlier today
 * seb128 reads backlog
<cjwatson> because effectively, this is happening because desktop-common isn't sufficiently self-contained
<pitti> I'm on the phone, but I dealt with that this morning
<pitti> brb
<seb128> juil. 01 09:57:43 <pitti>	tkamppeter: hplip-gui is fine; the problem was that hplip itself pulled in python-notify, which caused half the desktop to appear in the server isos
<seb128> ok, so another case of pitti fixing the bug before having it reported ;-)
<seb128> cjwatson, thanks a lot
<seb128> "hplip (3.10.5-3ubuntu2) maverick; urgency=low
<seb128>   * debian/control: Drop python-notify to suggests, it's pulling half of
<seb128>     the desktop into server images."
<seb128> didrocks, ^ that's fixing it for the record
<didrocks> oh nice :-)
<tkamppeter> pitti, why did you set bug 600504 to "Fix Committed" when you have uploaded the fix already hours ago?
<ubottu> Launchpad bug 600504 in hplip (Ubuntu Maverick) "Dependency on python-notify makes hplip unsuitable for servers" [High,Fix committed] https://launchpad.net/bugs/600504
<pitti> re
<pitti> tkamppeter: since it wasn't quite correct; adding the recommends to -gui is better
<pitti> tkamppeter: and you said that you committed that to debian/bzr
<seb128> pitti, just for the record that breaks notify-osd on une
<seb128> well broke
<pitti> seb128: hplip? hardly..
<seb128> but the bug is in alpha2 une isos
<pitti> seb128: oh, I see what you mean
<pitti> seb128: because hplip only got that dependency yesterday
<seb128> pitti, it does, it brings notification-daemon in which is prefered to notify-osd
<pitti> seb128: ok, understood; thanks for figuring out
<tkamppeter> pitti, I have both currently both Recommends: of hplip-gui and Suggests: of hplip. I did not upload it to Ubuntu yet.
<pitti> seb128: so this is essentially "fix committed", the next daily will have it
<didrocks> (I have added une session to notify-osd dbus service startup so that even if it does reproduce, we won't have that later on)
<pitti> tkamppeter: sounds fine; thanks!
<seb128> pitti, right, and didrocks fixed notify-osd to include "une" in the list of sessions which prefer notify-osd over notification-daemon
<pitti> splendid
<tkamppeter> pitti, should I upload the current version into Ubuntu, so that this gets the one of a2?
<pitti> tkamppeter: no hurry; it won't get into a2 any more anyway
<pitti> tkamppeter: the server ISOs got respun, and their size is fine again
<pitti> tkamppeter: and it's not a real issue for desktops, just a minor inconvenience for UNE; but it's only alpha-2
<pitti> smb: ddeb-retriever h4ck adapted; should DTRT for jaunty/karmic/lucid/maverick now
<smb> pitti, PHP (probably help paying) :)
<pitti> smb: :)
<smb> (should have meant probably helps praying, but i seem too weak to hit the keys)
<pitti> smb: Freudian typo, eh?
<smb> pitti, Heh, maybe. Who knows.
<smb> Doesn't help to switch between two keyboards
<pitti> smb: you got a new shiny ergonomic one?
<smb> pitti, Nah, just the other one and the Thinkpad on which irc is running
<apw> pitti, when do you do your magic for a milestone 'start' for a-3 ?
<pitti> apw: I don't have to
<pitti> apw: it's built into the code
<pitti> as soon as the previous milestone ended, it's considered the start of the current one
<pitti> so tomorrow all charts will be "clean" and trend line will be correct
<apw> pitti, oh so it will happen automatically then, the 'clear out' for the later milestones
<apw> awsome ...
<pitti> this works well as long as you do the planning before the milestone starts
<apw> pitti, yep indeed
<pitti> apw: yes, it rewards planning which happens on time :-P
<directhex> so when does main unfreeze?
<directhex> i want to finish one last test-build of mono 2.6.3-3 before sending it to experimental, and merging from that
<pitti> directhex: go ahead
<directhex> pitti, few hours left of my test-build on agricola before it's an issue, I just wanted to check
<directhex> ARM test-builds are slow
<chrisccoulson> doko - do you know what creates /usr/lib/jvm/java-6-sun-1.6.0.20/jre/plugin/i386/ns7/libjavaplugin_oji.so as an alternative for mozilla-javaplugin.so on hardy? i don't see it created on my machine with all the sun-java6 packages installed
<chrisccoulson> but some users have that selected as an alternative, which is causing some problems
<doko> chrisccoulson: I think this is the old sun plugin, maybe we need to remove the old alternative on upgrade
<doko> but I'm afk now
<chrisccoulson> doko - yeah, that's what i'm thinking. do you think we should do a sun-java6 upload to remove the old alternative, and increase the priority of the libnpjp2.so plugin?
<chrisccoulson> that's the one they should be using really
<chrisccoulson> anyway, thanks
* pitti changed the topic of #ubuntu-devel to: Alpha-2 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
 * ogra grumbles about weird cups udev rules 
<ogra> it forcefully loads parport and lp on my ARM board
<pitti> ogra: that's in the init script now
<pitti> it's not really how it's meant to work indeed
<pitti> parport_pc and parport ought to be loaded automatically via modaliases
<ogra> pitti, well, it produces oopses on my beagleboard
<ogra> and its pretty unlikely you will ever find a parport on arm HW :(
<ogra> err
<ogra> :)
<Daenyth|Work> Hi. I'm trying to split one of the packages I maintain and the docs are a little bit confusing because they expect a handrolled debian/rules file where I have one using cdbs. I have more details posted here: http://superuser.com/questions/158689/how-to-create-a-debian-split-package-when-using-debhelper
<Daenyth|Work> How do I need to change my rules file to get both packages built?
<Daenyth|Work> Are there any examples of packages that are split and use cdbs like that?
<cnd> I see that the xorg-server source package bzr branch hasn't been auto-updating right: https://launchpad.net/ubuntu/+source/xorg-server
<cnd> does anyone know who handles these issues?
<pitti> cnd: james_w mostly
<cnd> pitti: ok, thanks
<ricotz> pitti, hello
<pitti> hello ricotz
<ricotz> pitti, i just want to kindly remind you of docky, perhaps you can let is pass despite the lack of verifications
<pitti> for an update of this size we should get more than just one or two "works for me"
<ricotz> i release the new upstream version today which will be in debian/maverick soon
<ricotz> there are a least a verfication which isnt noticed for the most serious bug https://bugs.edge.launchpad.net/docky/+bug/555562
<ubottu> Launchpad bug 555562 in docky (Ubuntu Lucid) "crash accessing Gnome keyring in Lucid" [Critical,Triaged]
<pitti> ricotz: do you know some folks who are using docky and can confirm that the proposed version still works for them?
<Laney> Me!
<Laney> Did I verify it already?
<Kano> hi, when will the webfrontend give results for maverick
<Kano> i really need that info
<ricotz> pitti, most people we are in contact with using the development or stable ppa
<pitti> Laney: seems not
<Laney> pitti: which is the master bug?
<pitti> Laney: see http://people.canonical.com/~ubuntu-archive/pending-sru.html, pick one :)
<Laney> ok then
 * Laney blinks, that's a lot
<ricotz> pitti, if there are regressions i think they are overweighted by bugfixes multiple times
<pitti> small regressions perhaps, but if it stops working for someone else, it's worse
<pitti> known bugs are better then breaking existing functionality
<ricotz> yes, for now the keyring bug is stopping 2.0.2 from working very often
<Kano> also could you update libdrm to 2.6.21, thats critical for libva
<pitti> mathiaz: are you usually sponsoring landscape-client? There are two versions in -proposed, and it would be good if you could upload the current one with -v to include both changelog records; or alternatively condense them into one record
<Kano> no git version needed, just tested the debian experimental release
<ricotz> a
<pitti> good night
<ricotz> pitti, good night
<ricotz> Laney, the next sru proposal will have 24 connected bugs
<Laney> this is a lot of work for SRU verification
<Laney> it'd be good if you could organise testing
<ricotz> Laney, it is unlikely to verify all of them in a normal timeframe
<Laney> it's not really on to subjugate the process though
<Laney> I verified a few of the bugs
<shadeslayer> Laney: hi
<Laney> hello
<shadeslayer> Laney: can you do a SRU
<shadeslayer> https://bugs.launchpad.net/ubuntu/+source/desktopcouch/+bug/565376
<ubottu> Launchpad bug 565376 in desktopcouch (Ubuntu) "bughugger does not work in kubuntu lucid" [Undecided,New]
<shadeslayer> patch is attached
<Laney> I can't upload that package :(
<shadeslayer> :(
<Laney> that's not a properly formatted SRU anyway
<ricotz> Laney, of course i could through these bugs myself but this wont be real testing this should be done by real users ;-)
<Laney> your diff should be targetted to lucid-proposed and the version should be ...3.1
<Laney> and you need a test case
<shadeslayer> Laney: ahh
<ricotz> Laney, thanks for testing some of these bugs
<Laney> ricotz: You just need to get a couple of users to test the bugs for you
<Laney> If you call for this then I'm sure you'd get it
<Laney> it's easier if the bugs have decent steps to reproduce in the description
<ricotz> yeah, but i like to invest my spare time in really developing docky ;-)
<ricotz> Laney, who is supposed to change the tag to verfication-done?
<Laney> I'm actually not sure
<sebner> ricotz: I've seen normal users and/or archive admin doing this
<ricotz> ScottK, hello, can you answer this question about sru bugs? ^
<ricotz> sebner, yeah, i have seen this, but i thought there might be a rule
<sebner> ricotz: first come first serve maybe? ^_^
<ricotz> Laney, sebner, i will change the tag myself for the verified ones
<Laney> I don't know if more than one verification should happen
 * sebner agrees with Laney 
<ricotz> Laney, https://bugs.edge.launchpad.net/docky/+bug/582212
<ubottu> Launchpad bug 582212 in Docky "GMail docklet opens wrong "compose mail" page when using Google Apps" [Low,Fix released]
<Laney> ok then
<jdong> Hmph does Ubiquity ignore the http mirror hostname preseeded?
<jdong> It seems to remember the directory on the server but look on CC.archive.u.c
<jdong> hmmmm *scratches head* so what do I have to preseed to manually set the mirror?
<dupondje> https://launchpad.net/ubuntu/+archivemirrors => who maintains this list ? there seems to be an small error in it :)
<jdong> cjwatson: maybe dumb question, but does ubiquity not support preseeding mirror/http/hostname? It seems to always set it back to CC.archive.ubuntu.com...
<cjwatson> jdong: you'll at least need mirror/country set to "manual" as well, but it should support it
 * cjwatson -> bed
<jdong> cjwatson: hmm I've got d-i mirror/country string manual set
<jdong> and d-i mirror/http/hostname string my_host...
<jdong> it seems to ignore mirror/http/hostname, but accept mirror/http/directory
<jdong> (10.04)
#ubuntu-devel 2010-07-02
<cjwatson> jdong: don't know, please try with ubiquity --debug and send me /var/log/syslog and /var/log/installer/debug (before rebooting)
<jdong> ok, will do
<Bsims> Is there a way to automaticaly tell apt/synaptic to automatically download all -dev packages for all libraries?
<robert_ancell> does anyone know the safe way to compile with warning flags (-Wall etc) in automake.  i.e. that will work with other compilers?
<cjwatson> robert_ancell: see man-db/m4/man-gcc-warning.m4 for one possible approach
<robert_ancell> cjwatson, thanks
<cjwatson> robert_ancell: actually, there's a more polished version in gnulib, gl_WARN_ADD
<cjwatson> m4/warnings.m4
<Bsims> Is there a way to automaticaly tell apt/synaptic to automatically download all -dev packages for all libraries? I build some things from source and it would save the ./configure, growl, apt-get, repeat dance
<RAOF> Bsims: There is not, but have you tried âaptitude build-dep $PACKAGEâ?  For packages in the archive that will get you all the necessary dependencies.
<johanbr> Bsims, you could try "sudo apt-get install $(dpkg -l |awk '$2 ~ /.*-dev$/{print $2}')"
<RAOF> It would be a relatively easy thing to script if you really wanted to, though. johanbr's one liner is a good start.
<Bsims> RAOF: its not in the archive is the problem
<Bsims> johanbr: Yeah I thought something like that
 * Bsims grins now what I'd love to bluesky is a metapackage or option to synaptic/Ubuntu Software Center for that
<Bsims> Thanks
 * hallyn needs an ubuntu install cd to install on his 10 year old laptop that won't boot usb :)  drat, cds are so 5 years ago that i have no blanks
<mathiaz> smoser: hey!
<mathiaz> smoser: I looked at the landscape-client SRU - it's already been uploaded to -proposed
<smoser> ugh
<smoser> sorry to have wasted your time
<smoser> when was it uploaded ?
<mathiaz> smoser: however it still sits in the queue because one of the bug is not a proper SRU
<smoser> ugh.  it would have been nice if someone would have mentioned that in the bug rather than just ignoring
<mathiaz> smoser: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
<mathiaz> smoser: it actually is mentioned in the bug 597000
<ubottu> Launchpad bug 597000 in landscape-client (Ubuntu Karmic) "get_active_interfaces reports duplicated interfaces" [High,New] https://launchpad.net/bugs/597000
<mathiaz> smoser: https://bugs.launchpad.net/landscape-client/+bug/597000/comments/4
<ubottu> Launchpad bug 597000 in landscape-client (Ubuntu Karmic) "get_active_interfaces reports duplicated interfaces" [High,New]
<mathiaz> smoser: so I've assigned free from the landscape team to look at that
<mathiaz> smoser: and turn the bug into a proper SRU
<mathiaz> smoser: the issue comes from the fact there were 2 uploads to -proposed
<smoser> yeah.
<smoser> sorry.
<smoser> i was just sheparding :-(
<mathiaz> smoser: which always makes things a little bit more complicated
<mathiaz> smoser: I understand - no worries ;)
<ScottK> Laney: Anyone can set verification done.  To the extent you find the wiki confusing on this point, please fix it.
<poolie> that would make us doll-wigglers
<lifeless> QA is hard, lets drink beer.
<RAOF> They're actually absolute imports; simply dropping the leading â.â works fine.
<RAOF> poolie: I'm OK with that, as long as they're daemonic dolls.
<poolie> i think there should be no dot there
<RAOF> It *does* work without the dot, yes.
<poolie> wow it's all over the place
 * RAOF didn't find an upstream bug before moving on to other things.
<RAOF> Yeah.  All the imports are faux-relative.
<RAOF> I should probably have documented that on the bug. :)
<poolie> perhaps upstream tested it from inside a source directory so it found a different module
<poolie> though that still doesn't seem like it would work
<poolie> oh, perhaps i duped your bug?
<poolie> i just filed this one
<poolie> i also filed https://bugs.edge.launchpad.net/ubuntu/+source/hamster-applet/+bug/600855 but it may have the same root cause
<ubottu> Launchpad bug 600855 in hamster-applet (Ubuntu) "no panel icon for hamster applet" [Undecided,New]
<RAOF> Yup.  They'll have the same root cause, and are both duplicates ofâ¦
<poolie> what's worse is without hamster i can't track how much time i'm spending on this yak :-)
<RAOF> :)
<RAOF> Ah.  Of bug #599654, which apport has helpfully marked private.
<ubottu> Bug 599654 on http://launchpad.net/bugs/599654 is private
<RAOF> Hm.  According to bug #596072 it works in git master?
<ubottu> Launchpad bug 596072 in hamster-applet (Ubuntu) "hamster-applet crashed with ImportError in <module>()" [Undecided,New] https://launchpad.net/bugs/596072
<poolie> i wonder if we have an import branch
<RAOF> Shall I leave you to work out what's what?  I can upload if you need a fix sponsored.
<poolie> ok
<poolie> those import statements still seem to be present in our branch of it
<lifeless> merge-upstream time probably
<poolie> i mean in our import branch of their master branch, which seems to be up to date
<lifeless> oh
<lifeless> http://www.python.org/dev/peps/pep-0366/
<lifeless> http://www.python.org/dev/peps/pep-0328/ is the main relative import PEP
<poolie> yay, fixed
<RAOF> Huzzah!
<poolie> raof can you take it from here? sponsor an upload or something
<RAOF> poolie: Absolutely.  Where's the fix?
<poolie> https://code.edge.launchpad.net/~mbp/ubuntu/maverick/hamster-applet/600857-imports/+merge/29046
<pitti> Good morning
<dholbach> good morning
<ajmitch> hi
<poolie> hi there
<ricotz> pitti, good morning, please don't care about if i am opening this bug again this isnt an ubuntu bug and slipped into the changelog https://bugs.edge.launchpad.net/docky/+bug/504486
<ubottu> Launchpad bug 504486 in Docky "Writer in the dock is calc " [Low,Fix released]
<pitti> ricotz: ah, ok; no problem
<pitti> I just thought it was an oversight, since "incomplete" for a fixed bug seems strange
<ricotz> pitti, yes and this bug is a bit strange, thanks for accepting docky
<pitti> thanks for all the testing
<dupondje> Some archive admin that can accept https://bugs.launchpad.net/ubuntu/+source/opal/+bug/600121 ?
<ubottu> Launchpad bug 600121 in opal (Ubuntu) "Sync opal 3.6.8~dfsg-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<mvo> cjwatson: I had a "unaligned pointer 0xxxxx" error this morning in maverick at boot, I fixed it via grub-install /dev/sda. I don't boot the system often so I can not say with 100% certainty what version may have caused it. let me know if I should provide more info or a bugreport please
<pitti> lool: (reading liblauncher-0.1 changelog); we don't need a quilt b-dep for 3.0 packages
<lool> pitti: Oh right
<lool> pitti: Pushed to lp:ubuntu branch
<pitti> not a biggie, but merci
<dupondje> dholbach: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569077
<ubottu> Debian bug 569077 in linuxtv-dvb-apps "dvb-apps: missing channel for es-Sevilla" [Normal,Open]
<dholbach> dupondje: is debian upstream for that package?
<dholbach> dupondje: or who is the author of it?
<dupondje> linuxtv itself
<dupondje> going to check to make a bugreport there
<dholbach> thanks a bunch dupondje
<cjwatson> mvo: debconf-show grub-pc | grep install_devices
<mvo> cjwatson: http://paste.ubuntu.com/458198/
<cjwatson> mvo: and no dialog on upgrade or anything?
<cjwatson> mvo: that's very odd, it ought to have run grub-install for you
<mvo> cjwatson: let me check my log, I don't reboot the machine much, its quite likely that this happend a couple of days ago, I did however upgrade to the latest grub-pc this morning (before grub-install /dev/sda) and got no dialog and no fix
<mvo> cjwatson: let me check the apt/term.log
<mvo> cjwatson: here is what I have in the logs related to grub http://paste.ubuntu.com/458201/ - I can upload the full logs too if that is helpful
<cjwatson> mvo: ah, this is Debian #586143 then
<ubottu> Debian bug 586143 in grub-pc "Doesn't boot: Unaligned pointer 4c191bea" [Critical,Fixed] http://bugs.debian.org/586143
<cjwatson> mvo: as in, same cause - you have leftovers of a GRUB Legacy upgrade still around
<cjwatson> mvo: next upload will fix it, so just don't do anything for now and you can test that process :-)
<cjwatson> mvo: mind you, having lupin-support installed probably isn't helping either - is this a Wubi install?
<mvo> cjwatson: ok, I will not touch it and wait for the next upload :) the lupin thing is a leftover from a hardy->lucid upgrade issue triggered by lupin (the infinite loop bug)
<mvo> cjwatson: I installed it then to check it out but forgot to remove it again
<cjwatson> mvo: lupin-support is harmless, actually, looking at it
<cjwatson> it does divert grub-install, but the diversion just chains through to the real one if wubildr doesn't exist
<ogra> does anyone know from the top of their head where udevd writes its queue file ?
 * ogra would suspect in /dev 
<ogra> ah, seems like /dev/.udev/
<apw> do i detect a rebuild test in progress (from the length of the PPA queues) ?
<geser> apw: yes, a test-rebuild is in progress (https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20100628/)
<ogra> cjwatson, could you promote the linux-ti-omap4 metapackage to main ? seems it landed in universe
<ogra> (though i'm not really happy with the naming, should rather be just linux-omap4)
<cjwatson> ogra: done
<cjwatson> need to sort out omap4 seeds, mind you
<ogra> we have subarch specific seeds ?
<ogra> you nean it needs to be added to the installer seed etc ?
<ogra> *mane
<ogra> gah
<ogra> *mean
<cjwatson> that wasn't what I meant, although the versions in the installer seed need to be updated
<cjwatson> how about I take care of it, since I know what I mean :)
<cjwatson> easier to do than to explain
<ogra> yeah
<cjwatson> ogra: do you know why there are no udebs for the new linux-ti-omap4 package?
 * ogra fixes livecd-rootfs ... i went with the wrong assumption the metapackage would follow our naming scheme 
<cjwatson> uh, maybe that's wrong
<cjwatson> linux-ti-omap4 | 2.6.34-901.2 |      maverick | source
<cjwatson> linux-meta-ti-omap4 | 2.6.35.900.1 | maverick/universe | source
<cjwatson> is something out of sync?
<pitti> mr_pouit: uploaded xfce4-session to xubuntu-dev PPA with another piece of halsectomy, FTR
<ogra> i dont think so, there was only one upload
 * ogra checks deps
<cjwatson> linux-meta-ti-omap4 (2.6.35.900.1) maverick; urgency=low
<cjwatson>   * Maverick ABI 900 (2.6.34-900.1)
<cjwatson> this is, to say the least, odd
<cjwatson> and the autogenerated dependencies are of course on 2.6.35
 * cjwatson suspects a difficult-to-fix foul-up
<ogra> hmm, yeah
<cjwatson> if I'm understanding this correctly, and you want to change the package names anyway, now would be a good time to do it. :-)
<cjwatson> that'll be easier than trying to roll back the version
<ogra> yeah
<ogra> the binary should really be linux-omap4
<ogra> to match with all other packages
<mr_pouit> "Monkey-patch" huhu pitti, nice. I'll test that this evening ;)
 * apw notes that these packages were uploaded 10 days ago, and you are checking them after the freeze ... 
<ogra> the versioning might have been done with a view on the future
<ogra> since the omap4 branch will end up at 2.6.35 before kernel freeze
<apw> ogra, normally we'd not do that, i suspect its a typo
<apw> typo
<ogra> apw, ok
<apw> as 34 is < .35 anyhow
<ogra> apw, could i get a fix for both issues ? :)
<pitti> mr_pouit: in the sense that I only changed as little as necessary
<pitti> mr_pouit: i. e. error messages will still talk about "HAL" :)
<pitti> mr_pouit: but it works great here, tested suspend, reboot, and shutdown; hibernate properly says "not enough swap space" (I don't have swap in that project)
<ogra> apw, which freeze are you referring to ?
<apw> alpha-2 ?
<ogra> we dont even have omap4 images :)
<ogra> so A2 didnt matter
<apw> ahh tahts ok then
<ogra> i'm just starting to roll the first set
<ogra> or planned to start when i found the odd stuff :)
<m4t> hey, i've been working for a few hrs to get plymouth working on a custom kernel, and i got it finally working with KMS enabled on radeon...but now GDM doesn't appear. it just stays at the ubuntu logo, though gdm and X are supposedly running. is this a simple fix?
<pitti> mr_pouit: updated https://wiki.ubuntu.com/Halsectomy, too
<cjwatson> apw: alpha-2 was released yesterday :)
<ogra> yeah, that too :)
<m4t> i killed it and now its accessible
<apw> cjwatson, although there the binary packages are the wrong name, the source package is actually correct, so to 'fix' this i'd be wanting to upload an older version ... is that even possible ?
<cjwatson> apw: it's not possible
<ogra> smeels like epoch
<cjwatson> apw: either epoch, or rename the source package
<cjwatson> (and check that your scripts work with an epoch, if the former)
 * apw whines
<ogra> apw, i'd go with a new source package, just frop the ti
<ogra> *drop even
<cjwatson> apw: if you can't rename, then this is what epochs are for
<apw> cjwatson, yeah ... but they are evil
<ogra> there is not really a reason to point to the vendor in the package name ... there wont be other manufacturers producing OMAP
<apw> ogra, well we have a standard naming scheme for our source packages
<apw> and only this odd naming scheme for the binaries cause the installer was difficult
<apw> so to be inconsistent would be annoying
<cjwatson> apw: no they're not
<ogra> linux-meta-ec2 ?
<cjwatson> apw: they're evil if Debian doesn't have an epoch
<cjwatson> apw: in that case, we're dooming ourselves to unsyncability forever
<cjwatson> apw: but that's not relevant here, so an epoch is the right technical tool for the job
<ogra> linux-lpia-meta ...
 * apw cannot see the last one :)
<ogra> heh
<apw> all our vendor branches are named the same, and the source packages match them
<ogra> well, then go with epoch
<ogra> was just a suggestion to easily avoid adding one
<ogra> though i dont know what an epoch imples for the M+1 release where omap4 is supposed to end up in the mainline branch
<apw> ogra, yeah ... i really don't want to find out all the nastyness that an epoch would produce either
<apw> if we know we are definatly going to be getting a .35 based before release we can probabally just 'fix' the meta packages for the moment
<ogra> it might force you to add an epoch linux-meta for upgradeability reasons
 * apw will talk to tim, and get a plan together ... what a pain
<ogra> though linux-meta seems to break your naming scheme :)
 * ogra giggles
<ogra> there is linux-omap
<apw> yeah the binary packages should be linux-flavour
<ogra> yeah
<apw> that is a bug also
<ogra> thats the one i'm more intrested in actually
<apw> well the version not pointing to the right place isn't going to win us awards
<cjwatson> an epoch in linux-meta would hardly be the end of the world
<ogra> linux-meta-ti-omap4 | 2.6.35.900.1 ... you could just keep bumping the minor version there until the actual image is at .35
<ogra> but indeed thats extra work to maintain it
<cjwatson> certainly you could sed s/2\.6\.35/2\.6\.34/ in debian/rules for a while
<apw> ogra, indeed, but it might be the easiest course
<cjwatson> er fix syntax to work
<apw> cjwatson, exactly my thought
<ogra> yeah
<apw> as we know it will be .35 in the end
<m4t> okay that was happening i guess because of the dkms enable parameter i passed to radeon.ko
<apw> bah humbug ... ogra thanks for the heads up
<ogra> apw, thanks for taking care :)
<m4t> i only have one other question. i applied 0001-trace-add-trace-events-for-open-exec-an.patch and enabled CONFIG_FTRACE=y and CONFIG_ENABLE_DEFAULT_TRACERS=y. ureadahead will write to /var/lib/ureadahead if i run it after say, doing 'find /'
<m4t> but at boot it writes nothing. is there some way to debug it? perhaps have it log to a file?
<apw> m4t, you have to remove the pack to triger it to make a new one
<m4t> yep there is no pack, and i even tried creating a 0 length one with a > 1mo timestamp
<m4t> i also tried changing /etc/init/ureadahead.conf to also use '--force-trace'
<apw> as this is a personal kernel have you tested ftrace works even?
<m4t> pretty sure it works because i ran ureadahead -v after stat()ing a whole bunch of files with find
<m4t> and i got flooded with messages about things that came up in /proc not being regular files
<apw> then its a little odd its not working on boot for you then
<apw> nothing other than the kernel is be-spoke ?
<m4t> nope
<m4t> only reason i'm running a newer kernel is for pax patch
<m4t> newer/custom
<m4t> and i've got pax disabled on the ureadahead binary
<m4t> if i do ureadahead -v, run find /usr, and then ^C it definitely appears to work, and write to /var/lib/ureadahead
<m4t> see 'pack' itself and various *.pack files for my partitions
<apw> m4t, and have you confirmed it is even run on boot ?
<m4t> apw ;-)
<apw> is that a yes?
<m4t> i see it in boot.log
<m4t> well i mean i haven't truely confirmed
<m4t> but it does have messages there
<apw> i would be tempted to move it to ureadahead.real and add  a wrapper that records it being run
<apw> and see hwat params it gets
<m4t> i will try that
<m4t> it definitely does run
<m4t> i was in single user. the only thing i thought might be happening is ureadahead opening a file on ROOT/var rather than my separate var partition
<m4t> i wasn't able to unmount var to investigate though
<m4t> no thats definitely not whats happening, i checked
<m4t> about all i found out is that ureadahead runs, and returns 0 to the shell
<m4t> oh duh, well https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/523484
<ubottu> Launchpad bug 523484 in ureadahead (Ubuntu) "ureadahead requires /var on root filesystem" [Medium,Triaged]
<directhex> Subject: 	libgdiplus_2.6.4-1_source.changes rejected
<directhex> libgdiplus is a mono package, can i please have upload rights on it?
<m4t> maybe i can create the directories manually on /
<Laney> directhex: ping cjwatson to get it added to the set
<m4t> ah i see a great solution actually
<Laney> (I guess that just did it)
<directhex> cjwatson is conveniently awake
<m4t> have '/'var/lib/ureadahead be a symlink to '/'.ureadahead
<cjwatson> sure
<m4t> yes the smlinks work, i definitely have the pack files in /.ureadahead now
<m4t> apw thanks
<m4t> im going to update that to make sure that /.ureadahead/debugfs is created, else it won't work
<apw> cjwatson, which meta package does the installer use?  or is it a direct linkage
<cjwatson> apw: normally the top-level one if it can, i.e. linux-<flavour>
<cjwatson> though it falls back to linux-image-<flavour>
<apw> so does that mean its important that the linux-<flavour> matches the linux-image-*-<flavour> ?
<cjwatson> you mean whether the two <flavour>s are textually the same?
<apw> yeah do they need to be the same ?
<cjwatson> no, the installer doesn't care
<cjwatson> linux-<flavour> can depend on apw-is-god-let-all-earth-adore-him for all it cares
<cjwatson> (though you might have a slight archive admin issue there)
<apw> heheh i bet
<directhex> cjwatson, is there an email address or something i should ping to formally request a change to the cli-mono package set?
<cjwatson> directhex: no need, I just got distracted - done now
<directhex> ta
<directhex> Subject: 	[ubuntu/maverick] libgdiplus 2.6.4-1 (Accepted)
<directhex> woo
<apw> ogra, ok its in the queue, but the buildd's claim it won't start until the 5th
<apw> ogra, not that that makes much sense as the queue is only 8 hours long
<hallyn> james_w: hi - could you port the seabios package into bzr?
<james_w> hallyn: it's already done: https://code.launchpad.net/ubuntu/+source/seabios
<hallyn> james_w: dude!
<hallyn> thanks :)
<hallyn> (i swear i checked that!)
<cnd> james_w: would you be able to take a look into why xorg-server package releases for maverick are not getting pushed into the bzr branch?
<hallyn> kirkland: so i guess i'll do a merge request through bzr instead
<ogra> apw, all fine, it built
<apw> ogra, how did that happen, those estimates are all mad
<ogra> the queue doesnt know how long a package actually builds so it assumes worst case if all builders are occupied i think
<ogra> apw, if you have such a case you can ask a buildd admin to bump priority btw
<apw> ogra, hrm, i thought it built an average time for each package
<pitti> I think it does know (roughly) how long a package will need
<pitti> I guess it looks at the build time of the previous version
<apw> pitti, seems to be all out of wack today, was saying 3days, yet it built in minutes
<pitti> maybe that's broken for PPAs
<apw> Can't open average time db /var/debbuild/avg-build-times
<apw> Can't open average space db /var/debbuild/avg-build-space
<apw> pitti, this was a main buildd build, going into maverick
<apw> but i suspect that they may be broken
<pitti> apw: hm, where does it say 8 hours?
<pitti> main buildds are rather empty, except doorstopper archs
<apw> pitti, when i submitted the upload, it said it was going to start on the 5th, so i looked at the queue /builders/ and it said 8 hours, and then the job itself ran about 20 mins later
<pitti> fun
<apw> something isn't quite right with its head
<pitti> apw: it's just too hot outside
<apw> cirtainly is here :)
 * pitti looks forward to the weekend, which he will spend with tenting, swimming, reading, idling, BBQ, and watching the soccer game
<apw> pitti, sounds like a dream
<apw> i am seeing builds failing "failed to upload" in the rebuild test
<apw> is that normal, or something i should report
<apw> ogra, are those new meta packages looking a bit better?
<apw> cjwatson, did the linux-meta-omap dissappear from maverick in the end ?
<mvo> DktrKranz: hi, just wanted to let you know that I updated gdebi to use python-apts debfile and python-apt now has all the features that were missing (kiwinote did a good chunk of this porting)
<mvo> DktrKranz: I'm pretty happy about this :)
<DktrKranz> mvo: a-ha! cool :)
<mvo> plus improved testsuit for debfile.py as a added bonus (the gdebi test-debs) :)
 * mvo feels like after a spring cleanup
<DktrKranz> some older code has already been dropped, gdebi's lifting \o/
<mvo> yeah :)
<mvo>  11 files changed, 42 insertions(+), 238 deletions(-)
<cjwatson> apw: linux-meta-omap is gone, although there's still a linux-meta-ti-omap source package building no binaries
<cjwatson> apw: I could use a bug report with ubuntu-archive subscribed to it explaining what the desired state is
<apw> cjwatson, yep can do that
<cjwatson> thanks
<ogra> jdstrand, could you let linux-omap4 oput of NEW ?
<ogra> *out
<ogra> (it changed its binary name)
<apw> cjwatson, i've assigned ubuntu-archive to bug #595949 which was the bug under which we fixed the linkage in linux-meta, i've added a full descrtiption of the change and what I think is required in the last comment
<ubottu> Launchpad bug 595949 in linux-meta-ti-omap (Ubuntu Maverick) "linux-meta-ti-omap depends on the wrong binary kernel in maverick" [Low,In progress] https://launchpad.net/bugs/595949
<apw> s/assigned/subscribed
<mdeslaur> ogra: jdstrand is on vacation
<ogra> mdeslaur, hmm, you dont happen to know who does his archive admin duties on fridays ?
<mdeslaur> ogra: no, sorry
<ogra> so since jdstrand is on vac. could some other archive admin please let linux-omap4 out of NEW ?
<ari-tczew> kirkland: ping
<kirkland> ari-tczew: hi
<ari-tczew> hi kirkland, is it possible contribute to Debian first for byobu and syncs to Ubuntu then?
<kirkland> ari-tczew: i'm the upstream for byobu, and an Ubuntu developer;  i generally release byobu upstream, and upload to Ubuntu at the same time
<kirkland> ari-tczew: i'd like to be a Debian maintainer of the package, and upload to Debian too, simultaneously
<kirkland> ari-tczew: i need to jump through the DM hoops, though, and i haven't gotten around to that
<ari-tczew> kirkland: http://packages.qa.debian.org/b/byobu.html shows: maint    Dustin Kirkland
<kirkland> ari-tczew: i saw that and asked;  it just means that i have had uploads sponsored
<kirkland> ari-tczew: if you fancy sponsoring my packages, i would be glad
<ari-tczew> kirkland: hehe, I'm not Debian Developer
<kirkland> ari-tczew: okay
<kirkland> ari-tczew: so what exactly are you trying to accomplish?
<kirkland> ari-tczew: you want byobu uploaded to ubuntu and debian at the same time, right at release?
<ari-tczew> kirkland: yea, I'd be glad to see packages Ubuntu = Debian (synced)
<kirkland> ari-tczew: even if that means that debian is a downstream of ubuntu in this case (as long as they're in sync)?
<Laney> you can infact upload the same exact package simultaneously
<Laney> using syncpackage
<kirkland> Laney: i assume that requires DD or DM privs?
<ziggystar> I'm fighting with a bug with nm-applet. For a second user it seems it's lacking permissions. Running it with sudo works fine for that user. Can someone tell me how nm-applet gets started by gnome?
<james_w> cnd: fixed
<cnd> james_w: awesome!
<cnd> thanks!
<mathiaz> pitti: hi!
<mathiaz> pitti: re landscape-client SRU - there are two of them in the queue for now
<mathiaz> pitti: what should we do with them?
<mathiaz> pitti: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
<shadeslayer> hey! any desktopcouch maintainers around?
<Laney> kirkland: Right, I'm thinking that you build your package for unstable and then syncpackage gives you a changesfile for M or whatever
<kirkland> Laney: what provides syncpackage?
<Laney> FWIW getting DM for your package should be easy
<Laney> ubuntu-dev-tools
<cr3> in general, if a storage device fails to automount, against which package should the bug be reported?
<cr3> if gvfsd, what would be the corresponding package on kubuntu?
<cjwatson> use 'ubuntu-bug storage', I believe
<cjwatson> which works it out
<cjwatson> (it uses gvfs on GNOME and kdelibs5 on KDE, but it's still best to go through the automatic thing)
<cr3> cjwatson: thanks for reminding me about that :)
<Laney> ah, yes I have one of those bugs to file
<ccheney> is there  a way to disable ipv6 in maverick?
<ccheney> i'm testing some code and i think its having issues on using ipv6
<ccheney> ah i finally found out the correct syntax
<lex79> cjwatson: I can't upload kdebase-workspace, meta-kde and pkg-kde-tools, are not in the set of packages for a kubuntu-developer. Is it possible fix that? :)
<cr3> anyone know about a firewire device which seems to have started appearing with vendor id 0xd00d1e (looks suspicious, "doodle")
<cr3> hm, seems to come up as: FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04). weird how the vendor id detected > 0xFFFF
<cr3> the weird thing is that /sys//devices/pci0000:00/0000:00:1e.0/0000:05:0b.1/fw0/vendor is returning the id 0xd00d1e whereas lspci is returning another vendor id
<shadeslayer> hi,can someone look at https://bugs.launchpad.net/ubuntu/+source/desktopcouch/+bug/565376
<ubottu> Launchpad bug 565376 in desktopcouch (Ubuntu) "bughugger does not work in kubuntu lucid" [Undecided,New]
<shadeslayer> seems ubuntu dev is the maintainer of the package
<shadeslayer> and it needs a SRU
 * shadeslayer knows no Ubuntu Devs
<arand> shadeslayer: Go through the !sru process, and wait patiently. Is the normal procedure in those cases.
<shadeslayer> arand: have gone through it
<shadeslayer> arand: ive attached a debdiff to the package
<shadeslayer> uh... s/package/bug report
<shadeslayer> just needs some love :)
<arand> shadeslayer: Is it fixed in maverick?
<shadeslayer> arand: no,should i attach a debdiff for it too?
<shadeslayer> needs the same change to maverick too...
<arand> shadeslayer: https://wiki.ubuntu.com/StableReleaseUpdates : 1. Check that the bug is fixed in the current development release, and that its bug report task is "Fix released". It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch. ...
<shadeslayer> arand: basically.. gnome keyring needs to be installed along with python-desktopcouch for the gui authentication stuff
<shadeslayer> arand: oh my..
<shadeslayer> arand: will post a debdiff for maverick,will you look into it?
<arand> shadeslayer: I'm no dev either, so I'm afraid no.
<shadeslayer> arand: i actually posted the kubuntu devs the debdiff for maverick,but they told me to poke package maintainers
<shadeslayer> arand: no problem :)
<cr3> cyphermox: when you have a moment, please confirm bug #601161. thanks!
<ubottu> Launchpad bug 601161 in linux (Ubuntu) "sysfs reports invalid vendor id for firewire device" [Undecided,New] https://launchpad.net/bugs/601161
<arand> shadeslayer: Also, for SRU there is some formatting of the bug report to be done as well (test case, etc.), but that's all mentioned in the process which you've already read ;Ã¾
<arand> shadeslayer: If you don't have upload right you basically stop halfway at step 3. nominating it.
<shadeslayer> arand: got it
<shadeslayer> arand: anyways need to get it fixed in maverick first :P
<njin> Someone remember if past years was possible to have SO on one disk and swap on another ?
<directhex> SO?
<jono> TheMuso, ping?
<shadeslayer> any idea where apturl stores its desktop file?
<micahg> shadeslayer: it doesn't have one
<shadeslayer> micahg: really?
<shadeslayer> i thought i saw one
 * micahg doesn't see one in the file list
<shadeslayer> micahg: what about apturl-kde ? or apturl-common?
<shadeslayer> hmm.. your right
<cjwatson> lex79: fixed
<directhex> oh yes, the NEW queue. i forgot about that thing
<lex79> cjwatson: thanks :)
#ubuntu-devel 2010-07-03
<Laney> what does -proposed build against?
<YokoZar> ScottK: is it time for an ia32-libs SRU for Lucid?  Some of the component libraries have been updated
<ScottK> YokoZar: Could be.  I'm not on the SRU team, so my opinion doesn't count any more than yours.
<YokoZar> ScottK: was more asking if you remember seeing any libraries pass by the archive
<ScottK> I don't recall.
<YokoZar> openal I can definitely think of as one of em
<jdong> YokoZar: you mean just to pick up all the SRU'ed libraries?
<YokoZar> jdong: Yeah
<jdong> hmm, how many SRU's related to stuff in ia32libs have we done?
<YokoZar> jdong: possibly a security update or two is in there as well
<jdong> YokoZar: oh if that's the case I'm definitely receptive to the idea
<YokoZar> jdong: I don't know, but I do know there was a pretty important one for openal-soft (affects wine apps that use openal)
<jdong> the challenge is, what's the testing procedure? :)
<jdong> ok that sounds like a good rationale too
<YokoZar> well, run apps that use ia32-libs (Wine and a few others) and make sure nothing breaks too
<YokoZar> all I can think of really
<jdong> haha yeah it's the 2nd half of the sentence that I'm scratching my head about :)
<YokoZar> me too
<jdong> but yeah I've got no big objections :)
<jdong> it definitely sounds worthwhile to me
<jdong> and given that it's only propagating already approved SRU/-security updates to 32-bit apps on amd64, that sounds quite reasonable
<YokoZar> Yeah it's a very simple update
<YokoZar> albeit a very large in filesize one
<jdong> right
<YokoZar> I'll file the bug when I get home, and try to upload something into proposed tomorrow when I can mooch some good internet
<jdong> ok sweet
 * samiz is away: Away
<zyga> hello guys
<zyga> it seems that recent OO.org build is broken
<zyga> $ dpkg-query -S /@OOBASISDIR@
<zyga> openoffice.org-filter-binfilter: /@OOBASISDIR@
<zyga> the directory '@OOBASISDIR@' is in my / directory
<zyga> Installed: 1:3.2.1~rc2-2ubuntu1
<akshayb> I am getting kernel error while installing maverick alpha 2 on notebook. Any suggestions ?
<akshayb> and after error I get redirected to kernel shell prompt
<ansgar> akshayb: Wrong channel. I think #ubuntu+1 might be the right one.
<ansgar> *argh* ECHAN myself :/
<nailora> are there some problems with the ubuntu keyserver? i get lots of timeouts
#ubuntu-devel 2010-07-04
<unomi> Where can I find the script that ubiquity uses for install?
<jpds> unomi: apt-get source ubiquity and look at scripts/install.py?
<unomi> thanks, jpds there wouldn't be a way to modify it from a usb-stick install medium?
<jpds> unomi: ubiquity: /usr/share/ubiquity/install.py
<unomi> cheers
<unomi> unfortunately I am not seeing any references to parted in there
<YokoZar> jdong: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/601499
<ubottu> Launchpad bug 601499 in ia32-libs (Ubuntu) "[lucid] ia32-libs stable release update" [Undecided,New]
<philsf> what's the proper channel to ask about packages from the canonical DX team PPA?
<hunger> Any idea why schroot no longer works in maverick with encrypted homedirs? Used to work fine in lucid:-(
<hunger> Replacing bind with rbind in the line mounting /home in /etc/schroot/default/fstab fixes schroot for me:-)
<arand> debian-installer takes 1h+, whereas ubiquity takes ~20min, to install an equivalent standard desktop install. Is this how things are and should be? Or should this be brought up as a bug report?
<njin> Alternate version is extudied to work on pc with low ram
<arand> njin: re. ubiquity / d-i ... So the adaptation for low memory usage comes at the toll of d-i not using system resources even if they exist? I was under the impression that d-i was meant for far more than just lowmem installs..?
<njin> arand: i'm not an expert, the only things that i can see is D.I. is used in alternate versions, Ubiquity in others, and effectively on the same machine is slower than ubiquity
<arand> njin: Yep, I just did an equivalent desktop install on the same machine using both the liveCD and the alternate installer, at the diff in time was at least 40min. Which does seem a bit odd.
<arand> s/at/and/
<njin> no, i'm an iso-tester and the difference isn't about 40 min, it can be about 10-15
<jdong> hmm
<jdong> do other SRU team members have an opinion on the massive Banshee diff sitting in lucid unapproved?
<Laney> bugfix uploads have generally been accepted so far
<Carb0n> does anyone know which part of ubuntu 10.04 is responsible for drawing/loading the desktop wallpaper by default? like is it nautilus?
<micahg> Carb0n: execute this and then click on the desktop: xprop | grep CLASS
<Carb0n> cool thanks
<jussi> Is anyone here familiar with #ubuntu-toolchain and whether it is still used or needed?
<abhi_nav> i want to know why evolution is preferd over thunderbird? I am just a regular user. want to know
<micahg> abhi_nav: it's personal preference
<abhi_nav> micahg, no. I want to know reason why evolution is default. is it best? if yes then tell me so
<micahg> abhi_nav: probably because it integrates better into the desktop
<abhi_nav> micahg, ok. thanks :)
<micahg> abhi_nav: but you're free to use whatever client you like
<abhi_nav> micahg, yah I know. I just wanted to know whic is the best? its ok
<micahg> abhi_nav: it depends on the person
<abhi_nav> micahg, you mean persons likes or you mean persons requirements?
<micahg> abhi_nav: both :)
<abhi_nav> micahg, hmm
<abhi_nav> micahg, I am a comp engg student. I do little contributin using laucnpad etc. and no prefessional work still now. so which one you wll recommend for me?
<micahg> abhi_nav: I can't be impartial as I'm one of the Mozilla maintainers :), try both if you don't have a preference and keep using the one you like more
<abhi_nav> micahg, :( ok. btw thanks.
<abhi_nav> :)
<cjwatson> arand: that's how things are and should be.  unpacking .debs is more flexible, but is intrinsically slower than copying a filesystem
<cjwatson> arand: (although there is an existing open bug that we should be telling dpkg to use unsafe I/O during installation, which would make d-i faster)
<lifeless> cjwatson: has anyone looked into the dpkg safe IO implementation - reading the db doesn't seem like it should be writing, and reading shows up as slow
<arand> cjwatson: Okay, right, I wasn't aware of a major diff in the way they installed the system, but then it makes quite a lot of sense I guess, thanks for the info!
<cjwatson> lifeless: that's orthogonal
<cjwatson> arand: completely different installation method
<lifeless> cjwatson: ok, different cause for that slowdown?
<cjwatson> lifeless: the unsafe I/O thing is specifically and only due to the recent sync changes - I don't want to scope-creep into speeding up db reading
<cjwatson> lifeless: (which, if it were to be optimised, could be done generically and wouldn't need to be specific to installation)
<lifeless> cjwatson: for clarity, it seemed to me that db reading took a nosedive at the same time safe-IO arrived.
<lifeless> cjwatson: I had thought they were thus related
<cjwatson> it can't be related
<cjwatson> it actually should have speeded up around that time, though!
<cjwatson>     - Use FIEMAP when available (on Linux based systems) to sort the .list
<cjwatson>       files loading order. With a cold cache it improves up to a 70%.
<cjwatson>       Thanks to Morten Hustveit <morten@debian.org>. LP: #442114
<lifeless> interesting
<cjwatson> (dpkg 1.15.5.6ubuntu2)
<cjwatson> and it did improve things for me, IIRC, I seem to remember testing that
<cjwatson> so maybe somewhat system-specific, though I don't know how - if it's reproducible in a Debian chroot, maybe take it upstream?
<lifeless> cjwatson: when I get some spare cycles I'll have a fiddle. No promises - more than slightly frenetic at the moment.
<Booca_Juniiiors> holaaas
<cherva> What part of ubuntu is responsible for the laptops Fn+F1-12 shortcuts ?
#ubuntu-devel 2011-06-27
<soreau> Guys, I have no idea what happened but all of the sudden, evince fails with "evince: error while loading shared libraries: libX11.so.6: failed to map segment from shared object: Permission denied"
<soreau> Can someone give me a hint as to what might be wrong?
<soreau> Also I can't seem to start 'gksu software-properties-gtk'. It just gives a busy cursor for a few seconds, returns and gives no additional output
<ScottK> pitti: I'd appreciate it if you could arrange for qt4-x11 to get out of binary New.  AIUI didrocks needs this for work at the sprint this week and it's my upload, so I shouldn't do it.
<pitti> ScottK: oh, sure
<pitti> doing now
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, are you in Dublin now?
<pitti> yes
<tkamppeter> pitti, it is about AirPrint. we could ask the people on the Sprint to test.
<tkamppeter> pitti, first you should pass the SRU of bug 801306 to -updates (it is already verified) and upload CUPS for Oneiric, so that everyone gets the fixed AirPrint support by a simple update.
<ubottu> Launchpad bug 801306 in cups (Ubuntu Natty) "AirPrint only works with "ServerAlias *" in /etc/cups/cupsd.conf" [Undecided,Fix committed] https://launchpad.net/bugs/801306
<tkamppeter> pitti, then make a call for testing on the Sprint, for example during today's plenaries.
<pitti> tkamppeter: with cups I was going to wait until the current unstable version goes to testing, but if it's helpful, I can upload the current bzr head to oneiric, yes
<tkamppeter> pitti, would be great.
<pitti> tkamppeter: or do it on Friday, when most people want to print their your boarding passes anyway :)
<tkamppeter> pitti, I by myself will be on the Sprint on Thu and Fri, but doing the testing through the whole Sprint would be much better.
<tkamppeter> pitti, is there a printer on the Sprint, or does the testing only work as I described on the list, with a file printer?
<pitti> I haven't seen a printer yet, need to ask around
<tkamppeter> pitti, can you have a look at bug 799064?
<ubottu> Launchpad bug 799064 in foo2zjs (Ubuntu) "package foo2zjs 20110210dfsg-1ubuntu2.1 failed to install/upgrade: Fehler beim Schreiben von Â»<Standardausgabe>Â«: Datei oder Verzeichnis nicht gefunden" [Undecided,New] https://launchpad.net/bugs/799064
<tkamppeter> pitti, what is going wrong there?
<pitti> tkamppeter: (in plenaries, looking later)
<evfool> tkamppeter, pitti : that's an interesting bug, I saw quite a few bur reports related to that, aka unable to find standard output to write to
<SpamapS> jhunt: hey lets get together some time before lunch to chat about some stuff to collaborate on this week
<tkamppeter> evfool, so it is not specific to this package?
<tkamppeter> evfool, if this is a general problem, it most probably needs to get reassigned to another package. Which one?
<evfool> tkamppeter: i saw problems similar in docbook-xml, libcap2, gthumb, compiz-plugins-main, aso...
<evfool> tkamppeter: i'm not sure, as it happens while installing/upgrading either it's a problem in dpkg, or the package install scripts do something ugly for many packages
<evfool> tkamppeter: but that's just a guess
<evfool> tkamppeter: found that, its dpkg, bug 545790
<ubottu> Launchpad bug 545790 in dpkg (Ubuntu) "package PACKAGE failed to install/upgrade: error writing to '<standard output>': Success" [High,Confirmed] https://launchpad.net/bugs/545790
<tkamppeter> evfool, will mark my bug as duplicate of this one. Thanks.
<jhunt> SpamapS: sure. do you want to get together in 5?
<SpamapS> we won't be able to break out of here for a bit.. mor elike 90
<tkamppeter> evfool, never seen such a long duplicate list.
<evfool> tkamppeter: yep, it's interesting, and I see many which are not yet marked as dupes
<kirkland> slangasek: could you fairly urguently look at https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/802197 ?
<ubottu> Ubuntu bug 802197 in util-linux (Ubuntu) "no sysfs entry in /etc/mtab breaks encrypted-home" [Critical,Triaged]
<kirkland> slangasek: the recent util-linux update is locking oneiric users out of their encrypted-home directories because util-linux is not writing an /etc/mtab entry for sysfs
<slangasek> kirkland: we should ask lamont the question of whether this behavior change is intended
<slangasek> lamont: ^^
<kirkland> slangasek: sure... lamont?
<kirkland> slangasek: is lamont here in Dublin?
<slangasek> kirkland: I don't think so
<slangasek> I haven't heard loud and dry from IS so far, only loud and cackling
<kirkland> slangasek: :-D
<kirkland> slangasek: i'll subscribe him to that bug and ask for a comment
<slangasek> ok
<evfool> mvo:ping
<mvo> hey evfool
<evfool> mvo: how bad is an aptdaemon api change? to fix bug 771678, had to change the space and download transaction props from int32 to int64
<ubottu> Launchpad bug 771678 in aptdaemon (Ubuntu) "<type 'exceptions.OverflowError'>: Value -1608156160 out of range for Int32 while installing" [Medium,In progress] https://launchpad.net/bugs/771678
<evfool> mvo: could you please check the branch attached, as that bug's starting to have lots of dupes
<em> hey what is to prevent ubuntu devs/security team from stealing people's bitcoins?
<glatzor_> evfool, since there are currently only python clients the change should not do any harm
<directhex> em, nothing. muahahahaha, etc.
<em> hehe
<evfool> thanks glatzor, thats good
<em> I better keep my bitcoin wallet.dat on a usb flash drive separate from my computer.
<Laney> how would that help?
<cjwatson> if you don't trust your operating system, you shouldn't run it
<mvo> evfool: thanks, I will do that
<evfool> thanks mvo, glatzor
<cjwatson> there's really not much way around that
<em> well i believe the only way that someone can get my coins is if they have the keys that are in wallet.dat
<mvo> hey glatzor_!
<cjwatson> it's hardly new to bitcoins; an evil browser maintainer could snoop on all traditional e-commerce transactions conducted through a web browser, too
<em> cjwatson: true but somehow i think if a person successfully steals bitcoins it is very likely and much easier for them to get away scott free.
<slangasek> this is merely evidence of why bitcoins are a naive system
<Laney> luckily you're running a Free OS, so can inspect the code running on your computer
<cjwatson> it's a fundamental trust issue either way
<Laney> but... how far can you trust that? http://cm.bell-labs.com/who/ken/trust.html
<ion> em: To which operating systems would you attach the drive?
<directhex> em, have you ever audited the *upstream* bitcoin code?
<em> im not too paranoid about the code in Ubuntu/Linux. I surely trust that more than the propreitary ones. But I am a little nervous about the Ubuntu Security team and what they (can) see with updates or bug fixes to certain aps.
<cjwatson> if you are nervous about the Ubuntu security team, I don't think you can safely run Ubuntu at all
<em> Also I don't know who the Ubuntu Security team is on a personal level so don't feel insulted.
<cjwatson> I think it's more likely that the Ubuntu security team has zero interest in stealing people's bitcoins
<directhex> mostly former kgb agents, why does that have any bearing?
<ion> Simply donât run Ubuntu at all, run the operating system whose security team you do trust instead. Problem solved.
<glatzor_> hey mvo!
<em> I think everyone would agree that they are probably basically very upstanding people but wouldn't everyone also agree that the finest of people could break if they had a chance to get away with 400 thousand dollars without a trace?
<jdstrand> what is the specific problem here? that dpkg runs maintainer scripts as root?
<cjwatson> I can only repeat that if this is a genuine concern then you shouldn't run Ubuntu (or shouldn't use bitcoins in conjunction with it)
<em> Well then I think that it's just an interesting thing to consider how bitcoins make security even more interesting and important than it ever was before. Now that many people have really valuable stuff on their computers.
<cjwatson> there is no way to reassure you
<StevenK> em: I disagree.
<em> how come?
<cjwatson> bitcoins are hardly more "really valuable" than all the credit card transactions people have been doing on their computers for over a decade
<jdstrand> ah, bitcoins
<StevenK> em: People have been storing usernames and passwords for things that give access to *real money* for years.
<StevenK> Pretty much what cjwatson said.
<em> cjwatson: Well the reason I disagree with that is that if you have my credit card number, sure enough you could steal from me, but (1) It's much more difficult for you to get away with it, and (2) It's pretty easy for me to undo the damage to myself.  Neither of those are true with bitcoins.
<cjwatson> if you log into my online banking facility and make a non-CC transfer of some kind, it would be difficult for me to undo the damage
<barry> if you steal enough bitcoins can you buy a cache of stolen credit card numbers?
<cjwatson> it would certainly cause me a good deal of work
<directhex> em, you seem to be under the mistaken belief that the security team is anonymous. let's follow your supposition, that someone in the security team uploads a bitcoind which sends keys someplace, or sends coins to some address, or somesuch.
<StevenK> em: Then the flaw is with bitcoins, not the OS you run?
<ion> em: Given your assertion that any person is likely to choose to steal the 400k dollars given a chance i donât see how the issue affects Ubuntu any differently than the alternatives.
<directhex> em, now, what happens when the first guy notices a missing balance? then the next guy? the issue is isolated to ubuntu, the rogue update is found, the person who uploaded it is named and sued
<cjwatson> directhex: (and fired, in all probability)
<jdstrand> and arrested
<em> StevenK: no I don't think that's fair to say. I'm not here to cast dispersions on anyone or say there is any flaw in any OS. It's just the nature of bitcoins. And I think bitcoins create a new level of interest in security.
<directhex> cjwatson, i think that's implicit?
<cjwatson> yeah, but just to make it explicit.  anyone trying this has a lot to lose.
<directhex> jdstrand, afaik you can't be arrested in the uk for stealing bitcoins. they're considered a virtual good, so have no value until traded for something material
<em> ion: yeah this is not about Ubuntu really.
<jdstrand> I would be surprised if I couldn't get arrested in the US for it. but I don't know. let's just say it sounds incredibly risky :)
<kees> SECURITY UPDATE: your bitcoins were not part of my balance. This has been fixed.
<directhex> kees++
<StevenK> Hahaha
<cjwatson> directhex: I expect you could be arrested; whether it would be wrongful is a different matter ;-)
<jdstrand> CVE-2011-$$$$
<em> ion: I dont know that I'm asserting "any" person is likely to steal 400K.  That 400K was a made up number and Im sure that many (most?) people would resist the temptation. But I think it is human nature that given the chance to commit a 'perfect crime' most people have some price.
<cjwatson> em: the notion that such a thing would be untraceable is not accurate, I think
<cjwatson> all changes to the Ubuntu archive are traceable
<directhex> em, your belief that it's a perfect crime is based upon several veriufiably false premises
<em> directhex: could be you are right about your senario but bitcoins make a certain sort of anonymity pretty easy for someone who knows what they are doing. No one could say for sure who actually has the bitcoins once they are gone.
<cjwatson> sure, it would likely take time to trace, but *shrug*
<Laney> you can say for sure who pushed out the malicious piece of software though
<Laney> unless they manipulated the archive ...
<cjwatson> a security update that turned out on inspection to include 'mail evildoer@ubuntu.com </home/em/wallet.dat' would be a bit of a smoking gun
<em> do you guys know a lot about bitcoins? Im not claiming to be an expert but, as a cursory understanding, I think that if you manage to send my bitcoins to an address of your chosing, we will never catch you if you are clever enough.
<directhex> em, now you're deliberately ignoring what people are telling you.
<cjwatson> em: there would have to be some software that mailed it to an address of one's choosing
<cjwatson> em: that software and that address could be traced
<em> directhex: no no there's just a lot of people telling me things. Let me try to catch up.
<cjwatson> unless it was a security update that gave a particular security team member a shell on your system, and then *that* would be traceable and probably even more easily prosecuted
<cjwatson> (since there are plenty of established computer misuse laws in most jurisdictions)
<em> Oh yeah you are saying that it will be possible to figure out who put the trojan/backdoor/malicious code in.
<Laney> Launchpad is a better place to do this really
<directhex> em, not possible: trivial.
<em> I guess the attack could either be that you somehow get a copy of my wallet.dat or else that you actually hijack my bitcoin client and use it to send yourself my coins.
<cjwatson> this is no more fundamentally interesting than any of many other possible attacks that people with upload privileges to the Ubuntu archive might perform (and similarly be traced for)
<em> anyway i didn't mean to disrupt things here and i'm not trolling you guys. I am just not usually awake right now :)
<cjwatson> don't get distracted by the anonymity provided by bitcoins; that's only one level
<jpds> http://www.economist.com/node/18836780
<em> I think the advent and growth of bitcoins increases the incentives for people to attack ordinary people's computers, and the incentive for ordinary users to be paranoid VERY significantly.
<em> But this last comment I made here has nothing to do with ubuntu or ubuntu security in particular.
<directhex> yet people trust their wallets to mtgox. look how that turned out
<em> people do not trust their wallets to mtgox.
<em> they do trust however many bitcoins they have there though and USD.
<em> mtgox is a weird case because, like most things in the 'bitcoin economy' it's an ad hoc project slapped together by some ambitious kids and now it's making thousands of dollars a day.
<em> but it's true, i dont think anyone that runs mtgox is any kind of professional or really knows what they are doing.
<barry> cr3: hey man, are you around and if so, what room?  can we chat about checkbox?
<cr3> barry: hey dude, I'm around but kinda busy right now. lets plan to merge chad's branch this week
<barry> cr3: cool.  any chance we can do that earlier in the week?  i'd love to close out the conversion task as early as possible.  i'm happy to help in any way
<barry> cr3: thanks!
<cr3> barry: sure, I'm all for it
<barry> cr3: awesome, thanks man
<slangasek> doko: the avahi pointer-from-integer failure is due to changed gtk headers, actually :)
<cjwatson> pitti: do you know why http://people.canonical.com/~ubuntu-archive/pending-sru.html doesn't list bug 56679 for netcfg?
<ubottu> Launchpad bug 56679 in checkbox-satellite "provide a method to use a specified MAC-address as the installation device" [Undecided,New] https://launchpad.net/bugs/56679
<slangasek> maybe it doesn't know what to do with 5-digit bugs ;P
<pitti> cjwatson: hmm, looking
<pitti> slangasek, cjwatson: the bug number is in http://launchpadlibrarian.net/73636370/netcfg_1.51ubuntu3_source.changes, so until there it worked
<pitti> (it parses Launchpad-Bugs-Fixed:)
<cjwatson> right
<pitti> ah, drat
<pitti> slangasek: you were right after all :)
<slangasek> hahaha
<pitti> re.compile('lp:?\s*#(\d{6,7})', re.I)
<slangasek> :-)
<pitti> I think I added that after getting too many false positives by other garbled changelogs
<pitti> {'56679': [u'patch', u'verification-done']}
<pitti> there we go
<pitti> cjwatson: fixed; and congrats for fixing a five-digit bug :)
 * pitti will fix it more properly now, though
<cjwatson> that doesn't merit congratulations, all I did was ignore it for some years ;-)
<pitti> tkamppeter: I asked on the bug for debugging; no immediate idea either, there's not much information there
<pitti> tkamppeter: oh, someone duped it in the meantime
<pitti> tkamppeter: seems it's quite an old dpkg bug inded
<pitti> indeed
<pitti> ScottK, any KDE expert: is pkgkde-debs2symbols and/or pkgkde-gensymbols a magic solution to the per-architecture .symbols files somehow?
<pitti> IOW, when I want to add symbols files for a C++ library, can I get them any other way than just upload, grab the diffs from the buildd logs, and upload again?
<cjwatson> pitti: having to use per-architecture symbols files normally means that you're failing to use dpkg-gensymbols' facilities for C++ symbols properly
<cjwatson> for example, using mangled names
<cjwatson> see the "Using symbol patterns" section in dpkg-gensymbols(1)
<slangasek> cjwatson: except for functions which use a different int type on 32- vs. 64-bit systems, where counterintuitively things wind up using 'int' on 32-bit and 'long' on 64-bit
<pitti> cjwatson: I'll read that then; but manually creating patterns for 537 symbols sounds painful
<cjwatson> slangasek: yes; you could use (c++|regex) though
 * slangasek nods
<doko> gcc -v -E - < /dev/null 2>&1 | awk '/^#include/,/^End of search/ {i=1} i==1 && /^ / {print}'
<stgraber> barry: http://paste.ubuntu.com/633583/
<tkamppeter> pitti, I was the one who duped the bug, after evfool helped me with it.
<ScottK> pitti: Thanks (on qt4-x11) and AIUI yes on pkgkde-gensymbols.  http://pkg-kde.alioth.debian.org/symbolfiles.html has additional information on it.
<tkamppeter> pitti, any news about possibilities of AirPrint testing on the sprint?
<mvo> evfool: your branch looks fine, did glatzor give you any feedback ? if he is fine as well, I'm happy to merge it right away
<evfool> mvo: glatzor only wrote that as aptdaemon has only python clients, changing from int32 to int64 shouldn't affect them
<mvo> evfool: sounds like agreement to me ;)
<sconklin> pitti: Do you think you'll be able to publish our kernels today?
<slangasek> stgraber: the umount manpage (even in natty) says that umount takes a '-d' option to handle loop device removal... were you using that option?
<cjwatson> slangasek: I must say I don't ever recall having to do so; and I don't see why umount couldn't detect that
<cjwatson> the man page says "The umount command will free the loop device (if any) associated with the mount, in case it finds the option `loop=...' in /etc/mtab, or when the -d option was given."
<cjwatson> hm, a test loop mount/umount here does free the loop device though
<slangasek> ah, so maybe it's a bug in the mtab writing, rather
<pitti> does that depend on uevents in any way?
<slangasek> shouldn't
<pitti> because I noticed that umount doesn't remove the loop devices in a way that udev picks up
<pitti> i. e. umount() fails to generate a remove event for them (which losetup -d does)
<pitti> ok
<slangasek> odd
<psusi> pitti: did the device actually get removed?
<pitti> psusi: yes, but silently
<psusi> whoa... that shouldn't be possible
<pitti> which causes bugs like bug 548546
<ubottu> Launchpad bug 548546 in linux (Ubuntu) "Nautilus does not remove usb drive made with USB-Creator after unmounting it" [Undecided,Triaged] https://launchpad.net/bugs/548546
<pitti> psusi: well, mount as in the program doesn't do this; it's the mount() syscall which is cleaning up the loop mount, and the kernel just forgets to send the uevent
<psusi> pitti: what?  no... it's the umount program that does it when it sees the loop option in mtab
<pitti> last time I looked, umount() didn't actually have any code for the loop cleanup
<pitti> kees: released linux linux-meta linux-ports-meta linux-backports-modules-2.6.35 to maverick-security
<apw> cjwatson: am i right in thinking that if i replace caspers initrd.lz with an initrd.gz it will just work without change?
<kees> pitti: thanks!
<cjwatson> apw: should do, yes, as long as you adjust the boot loader configuration too
<psusi> pitti: wait a second... loop devices don't actually get deleted... they are precreated when the module is loaded...
<psusi> pitti: ohh boy... I think I just found it... it seems there's a flag you can set to have the kernel auto clear the loop when the last reference to it is dropped, so I guess that is what mount uses instead of having umount clear it.
<pitti> psusi: right, but they shold still generate a change event, like losetup -d does
<pitti> psusi: right
<psusi> pitti: when it auto clears in loop.c:1525, it passes NULL for the bdev to loop_clr_fd, which causes it to not emit the uevent
<pitti> I think I even reported that to bz.k.o, checking
<pitti> https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/548546/comments/44
<ubottu> Ubuntu bug 548546 in linux (Ubuntu) "Nautilus does not remove usb drive made with USB-Creator after unmounting it" [Undecided,Triaged]
<pitti> had my findings back then
<pitti> hmm; seems I meant to report it, but didn't
<pitti> bdmurray: filed as bug 802589, FYI
<ubottu> Launchpad bug 802589 in xkeyboard-config (Ubuntu) "KEY_CYCLEWINDOWS invalidly mapped to XF86RotateWindows" [Undecided,New] https://launchpad.net/bugs/802589
<bdmurray> pitti: thanks
<debfx> superm1: could you please have a look at my dkms patches on bug #802617 and bug #766150
<ubottu> Launchpad bug 802617 in dkms (Ubuntu) "module build error fails package installations" [Medium,New] https://launchpad.net/bugs/802617
<ubottu> Launchpad bug 766150 in dkms (Ubuntu) "apport hook should only generate reports about supported kernel versions" [High,Triaged] https://launchpad.net/bugs/766150
<debfx> tjaalton: ^ you might be interested in them as well
<tjaalton> debfx: thanks, looking
<tjaalton> debfx: thanks, they make a great deal of sense :)
<loganaden> hi
<NewbieToKernel> where can i find ubuntu source code including the kernel?
<holstein> NewbieToKernel: https://help.ubuntu.com/community/Kernel/Compile#Get the kernel source
<holstein> http://ubuntuforums.org/archive/index.php/t-14756.html might be helpful as well
<NewbieToKernel> the linux kernel is same accross all distributions rite?
<hallyn> NewbieToKernel: no
<hallyn> NewbieToKernel: different distros use (a) different versions with (b) different patches and (c) different configs
<NewbieToKernel> so there is a seperate ubuntu kernel?
<hallyn> but the heart of it is the same
<NewbieToKernel> oic
<NewbieToKernel> so what are the other packages that constitute the ubuntu distro?
<hallyn> you can look at http://kernel.ubuntu.com/git/ for the source used in ubuntu
<hallyn> i'm not sure i understand the question, but if you have an ubuntu system running you can do 'dpkg -l' to look at all the packages installed
<hallyn> then 'apt-get source <packagesourcename>' to download the source
<hallyn> (where packagesourcename is what you get from 'apt-cache show <package> | grep Source')
<hallyn> that should get you going enough to look around
<hallyn> btw, the current development kernel is at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=summary
<NewbieToKernel> so that is just the kernel or the other packages that come along with ubuntu as well?
<hallyn> dpkg -l shows them all
<hallyn> all that are installed that is
<NewbieToKernel> so i has all the packages along with the ubuntu specific kernel?
<NewbieToKernel> hallyn?
<hallyn> hm?
<hallyn> i don't understand your question.  do you have a running system?
<hallyn> a running ubuntu system?
<NewbieToKernel> no
<NewbieToKernel> i want to build the ubuntu kernel
<NewbieToKernel> for x86 although it has already been built
<NewbieToKernel> the i want to include the packages one by one that constitute ubuntu
<NewbieToKernel> and build them from sources
<NewbieToKernel> the link that you gave me has a lot of git repos
<hallyn> the next link i gave you has exactly one
<hallyn> you can get clone that and build it as any other kernel
<NewbieToKernel> ok. cool
<hallyn> 'make defconfig; make -j16 > log 2>&1'
<NewbieToKernel> so after that how do i know what other packages are included as part of the standard uuntu distro?
<hallyn> now, if you want to build the kernel exactly as it would be built for ubuntu,
<hallyn> i.e., same configs,
<hallyn> there's more to it.  jump to #ubuntu-kernel for such info
<NewbieToKernel> ok...cool
<NewbieToKernel> so after the kernel is built ... how do i build packages?
<NewbieToKernel> and how do i know what packages are part of ubuntu distro?
<hallyn> not sure what the easiest way would be to do that.  TO build, just apt-get source like i said before, then do 'fakeroot debian/rules build'
<hallyn> biaw
<NewbieToKernel> thx!!
<superm1> debfx, yeah i'll look.  do they apply to trunk?
<debfx> superm1: I'm not sure
<superm1> debfx, well trunk is significantly different
<superm1> hopefully it will be pulled into debian and merged for ubuntu
<debfx> trunk as in master or 2.2.0.0?
<superm1> 2.2.0.0 was just released so it's same as master, but the version in ubuntu is about a year old
<superm1> so if the patches are relative to the version in ubuntu they might need rework
<debfx> superm1: looks like master hasn't been updated. 2.2.0.0 is more recent than master
<superm1> hm, i wonder if forgot to push the tag
<superm1> debfx, no the tag is out on master
<superm1> http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=dkms.git;a=summary
<psusi> pitti: it looks like since kernel 2.6.37, mount sets the autoclear flag instead of recording the loop device in mtab.  The previous behavior was to just record the device name in mtab and umount will properly clear it.  A simple fix should be to simply cut that line of code and force the old behavior
<psusi> pitti: mount.c:1270 in util-linux checks the kernel rev and enables SETLOOP_AUTOCLEAR... one snip there should take care of it
<hallyn> bug 802538
<ubottu> Launchpad bug 802538 in udev (Ubuntu) "/etc/udev/rules.d/70-persistent-net.rules not automatically generated" [Medium,Confirmed] https://launchpad.net/bugs/802538
<hallyn> does anyone here know whether/why it was assumed that not creating persistent /etc/udev/rules.d/ net entry for vmware net devices would not impact guests?
<hallyn> (re bug 802538)
<ubottu> Launchpad bug 802538 in udev (Ubuntu) "/etc/udev/rules.d/70-persistent-net.rules not automatically generated" [Medium,Confirmed] https://launchpad.net/bugs/802538
<broder> hallyn: presumably it was an attempt to avoid situations where the mac address of the guest changed each time the guest was started
<broder> xen used to do that in its default configuration
<broder> and so you'd end up with eth0, then you'd reboot and get eth1, then eth2, etc
<hallyn> hm, does vmware do that?  if so that makes sense
<hallyn> lunaphyte_: is there something you need that file for?  or was this curiosity?
<hallyn> ie do you actually have two NICs (not in the logs) you want to keep straight?
<lunaphyte_> i have a vmware guest, running ubuntu - that i use as a template.  when i deploy a new guest from that template, the mac address changes.  i have a little deployment utility i wrote to address this item [along with a few other items], which deletes that file.  then, when a new guest is deployed, a new file is created, with the new mac address.
<lunaphyte_> just one nic
<hallyn> but not having the file created doesn't actually cuase trouble right?
<lunaphyte_> i have not seen vmware change the mac address of a guest between reboots.  that would potentially break things quite heavily.
<lunaphyte_> i haven't tried with the file, so i'm not certain what would happen.
<lunaphyte_> err - *without the file, rather.
<lunaphyte_> i can test that, if it would help.
<hallyn> well i'm just wondering how much we should care and what lengths to go to to document this.  like i say, i think vm's with multiple nics are the ones who might be negatively impacted.
<hallyn> do you know if, evne if you restart vmware (and maybe reboot the host), does the vm still maintain the same MAC?
<hallyn> biab
<lunaphyte_> well, i can't restart vmware or reboot the host - there are many other guests on it, but i can just about guarantee you that it will not change.
<lunaphyte_> bbiab myself :)
<hallyn> mdeslaur: was able to create an oneiric vm with the new vm-new.  It doesn't boot, but I *assume* that's unrleated :)
<mdeslaur> desktop or server?
<mdeslaur> hallyn: ^
<hallyn> server
<mdeslaur> ah, I did test oneiric desktop, but I just added server support, and may not have tested oneiric
<hallyn> ok i'll try out desktop tomorrow.  Just need to find the right iso :)
<hallyn> do you plan to add support for vm-new automatically rsync'ing?
<mdeslaur> last oneiric desktop daily iso I tried was 20110622
<mdeslaur> and it worked
<mdeslaur> rsyncing the isos?
<hallyn> yeah
<mdeslaur> I hadn't thought about it, but it seems like a good idea
<hallyn> just bc i had downloaded the -alternate cd before realizing i couldn't use that :)
<mdeslaur> oh, yeah, sorry :)
<mdeslaur> I should add support for that as well
<mdeslaur> hallyn: confirmed, I tested with hardy-natty server, but had not tested with oneiric...I'll look at it tomorrow if I have a minute
<lunaphyte> hallyn: my particular environment is vmware esx, with 10 hosts, housing ~120 guests - this is just one of the guests.  guests are always being rebooted, shut down, moved from host to host [automatically sometimes even], and in the years we've been using this, i've never seen the mac address of a guest change - aside from as intended/desired when a template is deployed.
<hallyn> lunaphyte_: can you comment that on the bug?  I don't know if that change came from udev upstream, from debian, or from us...  we should find out who filed the bug that was being addressed
<lunaphyte> yeah, i'll do that.
<bdrung> kirkland: does anything speak against upstreaming the changes from lintian 2.4.3ubuntu3?
#ubuntu-devel 2011-06-28
<kees> pitti: I've added you to the recipient list of the kernel abi checking tool (it runs hourly now)
<pitti> kees: oh, that's even better; thanks!
<kees> np :)
<kees> pitti: oh, btw, I have a demo of bug 726814 for you, if you need. it's very exciting. I was hoping you might have some insight into it.
<ubottu> Launchpad bug 726814 in linux (Fedora) "udisks-daemon uses a ton of CPU after inserting a SanDisk U3 Cruzer Micro usb stick" [Undecided,Confirmed] https://launchpad.net/bugs/726814
<pitti> cjwatson: for the defaults builder, would /usr/share/pkgname/locale.txt with a single default locale be enough to derive a sensible default keyboard layout, or do we always need to specify that explicitly?
<barry> cr3: daily nag: checkbox :)
<Laney> pitti or cjwatson: please moderate my t-b@ mail :-)
 * Laney seeks guidance from the elders
<pitti> Laney: done
<Laney> ty
<cjwatson> pitti: I think it would be better to have people who are preparing defaults packages specify the keyboard layout they want
<cjwatson> pitti: since there certainly isn't a universally correct mapping from locale to keyboard layout
<pitti> cjwatson: right, they should be able to, but do they need to?
<pitti> ISTR that if I select a language in gfxboot, it automatically selects a reasonable layout, too
<sidd_mak> how to integrate a media player in gnome sound panel...??
<cjwatson> pitti: reasonable for you :-)
<cjwatson> pitti: but I guarantee you that somebody's going to be unhappy with some entry in that giant mapping table
<cjwatson> pitti: German is a pretty uncontroversial case, but not all locales are so easy
<pitti> cjwatson: oh, absolutely
<pitti> cjwatson: I was just asking whether it should require specifying a layout if you specify a locale
<cjwatson> we could use a default as long as there's some way to override it
<pitti> and my gut feeling is that we shouldn't
<cjwatson> ok
<lifeless> bryceh: ping
<kirkland> lamont: ping
<lamont> ?
<lamont> don't ping, ask
<nigelb> woah, internet went off in dublin?
<StevenK> It did?
<nigelb> Almost everyone with a conference host seems to have disconnected
<StevenK> That's because it's lunch time!
<nigelb> Ah, that explains that :)
<slangasek> lamont: kirkland is pinging about util-linux regression in handling /sys in /etc/mtab
<slangasek> lamont: have you seen the bug, by chance?
<pitti> cjwatson: oh, I've been meaning to ask you: what would be a pallatable form of specifying the keyboard layout in a defaults package? the four XKB* variables that /etc/default/keyboard
<pitti> ... sets?
<pitti> or only a single value which maps to gfxboot?
<cjwatson> pitti: I'd go for the format that our loadkeys command accepts: e.g. "de" or "de:dvorak"
<cjwatson> layout or layout:variant
 * cjwatson checks what gfxboot likes
<cjwatson> oh, hm, one moment
<cjwatson> actually, I think layout or layout_variant would be easiest to process
<StevenK> cjwatson: O hai -- are you attached to Dapper or Karmic, or can we obsolete them?
<cjwatson> skaet: ^- StevenK above
<skaet> StevenK, Dapper is ok to obsolete,  we have to give an overlap on Karmic.
<pitti> cjwatson: ok, layout{,_variant} it is then; is there a list of all available ones somewhere, which the documentation could refer to?
<StevenK> skaet: Hasn't Karmic been EOL'd for months, though?
<pitti> cjwatson: oh, nevermind; sohuld be in loadkeys, I'll have a look
<skaet> SteveK,  OEM wants a 6 month buffer
<StevenK> skaet: Right, so when does that get reached?
<cjwatson> pitti: xkb-data
<cjwatson> pitti: loadkeys just uses that (indirectly)
<cjwatson> pitti: don't, whatever you do, refer to any of the old Linux-console-only keyboard maps you might find lying around :)
<highvoltage> imo there should really be a revisiting of the ubuntu release/support cycle at some point
<skaet> SteveK,  Karmic EOL'd on 4/30,  10/30 we can move off.
<pitti> cjwatson: so /usr/share/X11/xkb/rules/xorg.lst looks very close already; at least it's easy enough to parse to be able to check if the user specified a valid one
<skaet> StevenK, ^^
<pitti> cjwatson: thanks!
<StevenK> skaet: Ah, thank you.
<StevenK> skaet: I'm working on obsoleting Dapper.
<skaet> StevenK, thank you.  :)
<cjwatson> pitti: yes; there's also xorg.xml if that's easier
<davidboy> ohai.  I know this isn't quite the right place, but can someone please tell me what I'm doing wrong with this code?  http://pastie.org/2134172
<davidboy> I've sat in ayatana all day last week and noone knew anything
<davidboy> Dammit.  This is such a tiny problem ... should be easy, but I can't figure out anything I'm doing wrong
<RoAkSoAx> cjwatson: ping
<cjwatson> RoAkSoAx: content please
<RoAkSoAx> cjwatson: I seek your advice with something. koan, a tool that comes with cobbler has a feature "--replace-self" where basically downloads a kernel/initrd to replace the installation of the local machien
<RoAkSoAx> cjwatson: it uses grubby at the moment, but that's only working for grub1 obviosly
<RoAkSoAx> cjwatson: so I'm working on getting grub2 supported. So I was wondering what's the best approach to do this
<RoAkSoAx> cjwatson: I'm doing something similar to doign this: http://pastebin.ubuntu.com/634324/ (in Python, just hardcoding stuff atm)
<RoAkSoAx> cjwatson: once creating the file, running update-grub to add the entry to grub, so on next reboot, I can select that and get Ubuntu reinstalled...
<RoAkSoAx> cjwatson: is that a good approach to handle things with grub, in this case? (Just creating a file for the entry everytime I want to replace the current installation?)
<TheMuso> diwic: Is that jack detection meeting still going ahead? if so I'll be down in 15 minutes or so for it.
<diwic> TheMuso, it should start in 15 min. Currently there is another meeting in this room and I'm not sure it'll finish in time.
<tkamppeter> pitti, hi
<pitti> tkamppeter: hello Till
<tkamppeter> pitt, can you pass the Natty SRU of CUPS to -updates
<tkamppeter> pitti, and upload CUPS with my last cups-avahi.dpatch update to Oneiric, so that people can test on the sprint? Thanks.
<pitti> tkamppeter: natty SRU is only 3 days old, needs 7 days
<pitti> doing oneiric now
<pitti> see #u-desktop, cups only moved to testing today, and I was waiting for that
<tkamppeter> pitti, the SRU is already verified.
<pitti> yes, but it needs to mature in proposed for 7 days to catch regressions
<pitti> see https://wiki.ubuntu.com/StableReleaseUpdates
<tkamppeter> pitti, OK, so do it on your first SRU day of next week, for the Sprint the Oneiric upload is more important. People hhave Oneiric there.
<pitti> you could send a call for testing to ubuntu-devel@
<pitti> with instructions how to test it
<tkamppeter> pitti, is there a printer on the Sprint?
<pitti> tkamppeter: just asked; there is one broken one which we can borrow
<tkamppeter> pitti, I have already sent one to ubuntu-devel-discuss@ last week. should I simply repeat it on ubuntu-devel@?
<pitti> tkamppeter: we need to connect it to an oneiric box, and then try to print something from an iphone?
<pitti> (FWIW, most folks have android here, but we ought to find an iphone here)
<tkamppeter> pitti, if it is good enough for testing (one can set up a queue and recognize the input file on the paper) then it is OK.
<tkamppeter> pitti, that's it.
<tkamppeter> pitti, what about the call for testing? Should I repeat it on ubuntu-devel@?
<pitti> tkamppeter: you can try
<tkamppeter> pitti, will do.
 * TheMuso has an iphone.
<tkamppeter> pitti, done.
<apw> pitti: hi, i am looking at lp:ubuntu/oneiric/udev and it seems to be majorly out of date compared to the archive
<cjwatson> apw: try lp:~ubuntu-core-dev/ubuntu/oneiric/udev/ubuntu, which is where the work's actually done
 * cjwatson goes to update the Vcs-Bzr field
<apw> cjwatson: i am confused how the importer branches can be out of date tho.
<cjwatson> bug
<cjwatson> (bugs.launchpad.net/udd)
<cjwatson> maxb has been nuking vast numbers of importer failures recently; I assume he hasn't got round to this one yet ...
<maxb> Hello
<cjwatson> RoAkSoAx: I'm failing to understand, and will come round.  Are you in the server room?
<maxb> Ah, that's one of the NoFinalPath ones
<maxb> I had a quick look at those, and decided I need to get some support for someone knowing bzrlib internals better than I for that.
<maxb> apw: Because the importer threw an exception whilst importing
<maxb> Although annoyingly, it only broke in the bit where it tries to generate a preview merge diff, which I'm not sure really get used much
<slangasek> jelmer: ^^ maxb is asking for you to help put him to work :-)
<maxb> hah
 * jelmer ducks
<jelmer> maxb: hi
<slangasek> lamont: ribbit
<RoAkSoAx> cjwatson: I'm doing this (maybe my code explains itself better :) ): http://paste.ubuntu.com/634419/
<cjwatson> RoAkSoAx: it would be easier to see the (grub legacy) original
<cjwatson> I don't really understand what this is trying to do, right now
<RoAkSoAx> cjwatson: this looks better: http://paste.ubuntu.com/634428/
<cjwatson> RoAkSoAx: please just tell me where I can see the original?
<cjwatson> I don't want to read a diff right now, I want to study the original code to understand what it's doing
<RoAkSoAx> cjwatson: bzr branch lp:ubuntu/cobbler , file is under koan/app.py
<cjwatson> thanks, I'll look at that
<RoAkSoAx> cjwatson: function starting in line line 937
<pitti> apw: right, please don't use the udd branch for udev
 * pitti waves good night
<RobOakes> Howdy, is this a good place to ask package questions or is there a more appropriate channel for that?
<maxb> RobOakes: It's a good place for questions about packages in Ubuntu itself, especially packages in main. For universe packages, #ubuntu-motu perhaps, though I don't think people will mind asking here. For non-Ubuntu packaging, e.g. PPAs, #ubuntu-packaging.
<RobOakes> Okay, thanks.
<RobOakes> I'm a complete noob to packaging, but am trying to configure a daily build. Does anyone know what is meant by "source field" in respect to a debian package build?
<m4n1sh> RobOakes: where did you encounter that? Please tell the exact place
<RobOakes> During a build of a daily LyX package I'm trying to create (using a recipe).  My build fails because of this error error: "first block lacks a source build."
<RobOakes> Here is the build log: https://launchpadlibrarian.net/74251271/buildlog.txt.gz
<RobOakes> Ugh. Nevermind. I misspelled the first line "Source"
<lamont> slangasek: sorry - what was the question?
<lamont> slangasek: util-linux /sys thing - no, I haven't looked at that bug yet
<lamont> slangasek: otoh, I'm also pretty sure I didn't do the merge for oneiric
<broder> hmm...have sync runs not happened recently, or do i need to start harassing the AAs to run backport-helper when they run sync-helper?
<micahg> broder: first one in about a week I think was today
<cjwatson> broder: I got a bit put off by the size of the backports queue today, but I will do it today/tomorrow
<broder> cjwatson: no worries - just wanted to make sure it hadn't been forgotten about
<slangasek> lamont: no, I did the merge for oneiric... there was no mention of this bug in the BTS, and we were trying to work out if it's even an intended behavior change
<lamont> oh.  nfc
<lamont> what specifically is the behavior?
<slangasek> lamont: it seems that for some reason, /sys is no longer written to mtab
<slangasek> lamont: generalizing, it seems to be any filesystem with 'none' as a mount source
<broder> that...seems like a terrible idea
<lamont> that is likely intended behavior
<lamont> might be related to the push to ln -sf /proc/mounts /etc/mtab
<lamont> dunno
<lamont> so after I accidentally manage to get uxterm into anthy input mode, how the *&%)*&%)* do I turn that off?
<hallyn> cjwatson: if you're around, can you take a look at bug 803159 (and tell me if there is a reason the fix shouldn't be SRUd)?
<ubottu> Launchpad bug 803159 in eglibc (Ubuntu) "debootstrap fails trying to install libc6" [Undecided,New] https://launchpad.net/bugs/803159
<hallyn> how many times am i going to hose a vm by forgetting to set bridge_ports on the bridge
<cjwatson> hallyn: dup of bug 802985; I explained the problem there
<ubottu> Launchpad bug 802985 in debootstrap (Ubuntu) "[lucid] /var/lib/dpkg/tmp.ci/preinst: 399: arithmetic expression: expecting EOF: "3.0-0-generic"" [High,Triaged] https://launchpad.net/bugs/802985
<hallyn> cjwatson: ok, thanks - i looked through the buglist but couldn't find that one...
<cjwatson> I agree it's a serious problem but the fix is ... not as trivial as it looks
<cjwatson> it was the most recent bug filed on eglibc
 * cjwatson fiddles bug status
<hallyn> cjwatson: I see
<hallyn> (just read your explanation of why sru isn't particularly helpful :)
<cjwatson> necessary but not sufficient
<hallyn> any suggestion for best workaround?
<cjwatson> uname LD_PRELOAD
<cjwatson> lie about utsname.release and pretend it's 3.0.0 rather than 3.0
<cjwatson> not a one-liner but shouldn't be too hard
<hallyn> cjwatson: assuming it's mostly scripts, would it be easier to just have debootstrap, early on, bind
<hallyn> ok,
<cjwatson> debootstrap ought to be fixed, but it will be fairly involved
<hallyn> to do LD_PRELOAD we'll have to ship and build the .so though right?
<slangasek> wouldn't a dpkg-divert of /bin/uname be simpler yet (wrapping it with a shell script)?
<cjwatson> hallyn: no, I mean just set that environment variable when running debootstrap
<cjwatson> oh, but it will probably interact messily with chrooting
<hallyn> slangasek: that sounds good...
<cjwatson> slangasek: inserting such a dpkg-divert into debootstrap would be fiddly too
<cjwatson> there really isn't a good straightforward workaround for this
<slangasek> yes, but doesn't require writing a custom .so
<cjwatson> sure
<hallyn> cjwatson: but you can't LD_PRELOAD a script, so it's arch-dependent, that's where I"m not sure how we woudl handle it
<cjwatson> hallyn: I'm absolutely not suggesting shipping such a workaround
<hallyn> writing th e.so, probably easy, but
<hallyn> oh
<cjwatson> we shouldn't ship something that isn't a fix, for this
<hallyn> haha, ok.  that's just to get us limping along in the meantime.  makes sense
<cjwatson> it's strictly more difficult than multiple components (which we've done in debootstrap) because you have to deal with the same package being in both lucid and lucid-updates at different versions, and only using the newer one
<cjwatson> in shell
<hallyn> but someone's working on it?
<cjwatson> well, if it's in the pkgdetails interface then it's in perl (normally) or C (in d-i)
<cjwatson> hallyn: not yet
<cjwatson> but I probably will
#ubuntu-devel 2011-06-29
<slangasek> lamont: poking at the libmount code, I'm reasonably convinced it's a bug rather than a feature given the amount of code related to the mtab that *does* get called
<slangasek> lamont: but I've yet to find the actual bug :P
<lifeless> bryceh: ping
<bryceh> lifeless, yes
<lifeless> bryceh: hi
<lifeless> bryceh: can you join #launchpad-ops (internal) for a bit ?
<jelmer> doko, slangasek: making some progress on the one-time import; 14k out of 26k left at the moment
<\sh> hmm...why is the global menu bar missing from gvim now since the last unity update on natty...strange
<slangasek> jelmer: whee :)
<geser> \sh: are you perhaps affected by bug 776499?
<ubottu> Launchpad bug 776499 in vim (Ubuntu) "gvim gets no global menu, timeout warning on the console" [Undecided,Confirmed] https://launchpad.net/bugs/776499
<\sh> geser, dunno, because I don't see any menubar on gvim anymore...before the last unity update this was working
<\sh> and no...I don't even get the console message the people are talking about
<\sh> but gvim -f helps
<slangasek> jelmer: is there a bzr-svn package update pending for oneiric?
<jelmer> slangasek: Yes, but it's blocked by a strange interaction with libapr/iconv that makes the testsuite segfault
<slangasek> jelmer: do you have a log?
<slangasek> jelmer: or, a pointer to the package currently failing?
<jelmer> slangasek: It should be reproducable by building http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable in a sid chroot
<jelmer> slangasek, I'll see about filing a bug about it, so the rest of the world is also aware of it.
<slangasek> jelmer: got it, cheers
<jelmer> slangasek, https://bugs.launchpad.net/subvertpy/+bug/803353
<ubottu> Ubuntu bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged]
<slangasek> jelmer: btw, I think there's a missing breaks: bzr-builddeb or something in the latest bzr, because natty->oneiric upgrade warned me about bzr-svn, but let bzrlib get upgraded out from underneath, breaking things
<jelmer> slangasek, unlike bzr-svn, which relies more on bzr internals, bzr-builddeb should work with multiple bzr series
<pitti> kees, jdstrand: published linux-meta-mvl-dove linux-mvl-dove to lucid-u/s, for bug 802554
<slangasek> jelmer: well... it didn't :-)
<ubottu> Launchpad bug 802554 in linux (Ubuntu) "linux: 2.6.32-33.69 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/802554
<jelmer> slangasek: that's the theory though, if something's breaking it should be fixed :)
<slangasek> jelmer: natty bzr + oneiric bzrlib + oneiric bzr-builddeb, and bzr bd fails with an internal error
<pitti> kees, jdstrand: with the automated emails being sent now, and me changing te status on the tracker bug, do you actually need/want me to ping you on IRC about this?
<slangasek> jelmer: where should I file the bug?
<pitti> kees, jdstrand: sorry, bug 794695
<ubottu> Launchpad bug 794695 in Kernel SRU Workflow "linux-mvl-dove: 2.6.32-217.34 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/794695
<kees> pitti: it's nice to get the ping, but I don't think it's required any more. if you happen to remember, that's fine
<jelmer> slangasek: ubuntu/bzr I think
<slangasek> jelmer: bug #803362
<ubottu> Launchpad bug 803362 in bzr (Ubuntu) "partial upgrade to oneiric (to keep bzr-svn installed) bails with bzr bd -S" [Undecided,New] https://launchpad.net/bugs/803362
<jelmer> slangasek: thanks
<jelmer> slangasek: Ah, sorry - I misunderstood. You're right, this is indeed a missing Breaks
<RAOF> kees: Is security looking at bug #657598 ? It's proposed as an sru but looks like a security fix.
<ubottu> Launchpad bug 657598 in g15daemon (Ubuntu Natty) "g15macro crashes with buffer overflow" [Undecided,Confirmed] https://launchpad.net/bugs/657598
<micahg> RAOF: it's not a security issue per say since it crashes on startup
<micahg> *per se
<RAOF> micahg: So we'll accept that as an SRU then?
<micahg> RAOF: if the SRU team thinks it's worth it, why not?
<RAOF> Right.
<kees> RAOF: right, what micahg said :) I've added a note to the bug now just to clarify
<siretart> Laney: please consider merging http://bazaar.launchpad.net/~siretart/+junk/transition-tracker.libav/revision/106, I had to bump libswscale's soname again very close before the final 0.7 release
<siretart> or anyone else with access to the branch
 * micahg congratulates RAOF on becoming a member of the SRU team
<cjwatson> zul: well, er, thanks for uploading image-store-proxy, but you didn't fix the test failure that was the reason I didn't just upload it myself ...
<zul> cjwatson: damn it sorry about that
<barry> zul, cjwatson i set bug 802402 back to confirmed state
<ubottu> Launchpad bug 802402 in image-store-proxy (Ubuntu) "convert to dh_python2" [Undecided,Confirmed] https://launchpad.net/bugs/802402
<Laney> siretart: not easily since my PC is offline due to a house move
<Laney> someone else can though
<doko> RAOF: mesa/llvm ping
<barry> cr3: you will hate me now: checkbox :)
<barry> cr3: it's the last desktop cd package that needs conversion from python-central (bug 788514)
<ubottu> Launchpad bug 788514 in Ubuntu Oneiric "python packages on the CDs not using dh_python2" [Medium,Confirmed] https://launchpad.net/bugs/788514
<slangasek> wendar, barry, ScottK: wrt python2.7 in Debian and the transition tracking: for ignorable issues on packages not in testing (only in stable, unstable), is it preferred to remove the dex usertag, or to remove it from the 'blocks' list?
<kees> pitti: can you check the components for linux-mvl-dove lucid? it seems to have gone into universe instead of main
<pitti> *sigh*
<kees> pitti: e.g. http://ports.ubuntu.com/pool/universe/l/linux-mvl-dove/ vs http://ports.ubuntu.com/pool/main/l/linux-mvl-dove/
<pitti> kees: I'll promote it
<kees> pitti: well, can you double-check?
<kees> pitti: I *think* it hsould be in main. the others have been, but perhaps all of those are mistakes too?
<pitti> they were in main in the final release
<kees> I see a history of 2.6.32-2xx in main, but we should make sure
<pitti> hmm
<pitti> that's for lucid or maverick?
<pitti> I see some -di modules in universe
<pitti> https://launchpad.net/ubuntu/+source/linux-mvl-dove/+publishinghistory says "main", too
<kees> I'm looking at lucid linux-mvl-dove. whatever the components were for release is what it should be for -security
<cjwatson> there's a nascent pocket-mismatches script in ~lp_archive/dak/ that you can use to analyse this kind of thing
<cjwatson> observe the hideous pile of output
<pitti> ah, right; so these -di modules were in main for the release, but aren't any more
<pitti> so that was apparently mis-binNEWed
<pitti> kees: fixed
<kees> pitti: thanks!
<cjwatson> at the risk of being a broken record: people need to use kernel-overrides when binNEWing kernel packages
<cjwatson> pitti: language-pack-ky-base seems to be out of date: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/edubuntu-dvd/latest/livecd-20110629-i386.out
<evfool> what's the difference between a debian ITP and RFP?
<pitti> language-pack-kde-ky | 1:11.10+20110627 |       oneiric | source, all
<pitti> cjwatson: ^ hmm
<StevenK> ITP == Intent To Package -- I will do it.
<pitti> language-pack-kde-ky-base | 1:11.10+20110623 |       oneiric | source, all
<StevenK> RFP == Request For Package -- someone else, please do it.
<pitti> cjwatson: oh, indeed -- madison on cocoplum has the new one, but rmadison doesn't
<pitti> according to LP it was published 3 days ago
<seb128> janimo, ogra_: could somebody look at the json-glib armel ftbfs?
<seb128> it's make the new libdbusmenu depwait on armel and the new indicator stack picked depends on the old libdbusmenu soname
<janimo> seb128, will check
<seb128> thanks
<evfool> thanks StevenK, the debian site description doesn't define them that nice :)
<sveinse> How can I create a debian package without any content (but with dependencies)? I know how to do that for a normal package, but I dont know how to build it without having any software to put into it. Any pointers please?
<tsimpson> just create an empty <project>/ dir and create <project>/debian/
<sveinse> Thanks. Obvious really
<cjwatson> pitti: huh, ok
<ScottK> slangasek: Unless it's an RC issue in and of itself (so we can be sure the package will stay out of Testing) I think just drop the DEX tag.
<slangasek> ScottK: these are all RC issues that I'm referring to
<ScottK> slangasek: Then I think they don't need to block.
<sveinse> Is it possible to configure dpkg-buildpackage/debuild to use other file than Makefile for building the upstream source?
<slangasek> ScottK: righty-o.  do you have the transition bug # handy? (bts being slow)
<ScottK> No.  Sorry.
<slangasek> k
<ScottK> sveinse: debian/rules is the make file that is used.  It may call an upstream make file, it may not.  Depends on what's in it.
<sveinse> ScottK: I'm using the default %:   dh $@, so dh must be assuming a Makefile in ../ (relative to the debian dir)
<ScottK> Yes, but you can override this.
<sveinse> How? I couldn't find any mention of it in man dh
<ScottK> These examples are very Perl specific, but ought to give you an idea: http://pkg-perl.alioth.debian.org/debhelper.html
<sveinse> excellent, thanks
<sveinse> A bit more tedious than I hoped for, but I get the idea
<Laney> if you want to build from a different directory then there's -D to the various dh_auto tools
<cjwatson> sveinse: dh won't use a Makefile if there isn't one
<cjwatson> sveinse: if all you need to do is install some files, it's more usual to use debian/*.install files (see 'man dh_install')
<siretart> cjwatson: please consider merging http://bazaar.launchpad.net/~siretart/+junk/transition-tracker.libav/revision/106, I had to bump libswscale's soname again very close before the final 0.7 release
<sveinse> cjwatson: Yes. In my case, the top level Makefile is autogenerated, and thus I can't change it to do make install into $DESTDIR, so I planned on writing a small Makefile.debian to wrap the build & install process. But when I come to think of it, I can do this wrapping within debian/rules
<cjwatson> siretart: done
<cjwatson> override_dh_auto_install:
<cjwatson>        # either just a comment, or do what you need instead
<cjwatson> sveinse: ^-
<sveinse> thanks
<siretart> cjwatson: thanks
<sconklin> pitti: could you please copy natty from the kernel ppa to -proposed when you can? Sorry to nudge you, but this should fix the problems that a lot of people are seeing here at the rally
<cjwatson> Makefile.debian would not usually be an idiomatic thing to do, no
<pitti> sconklin: oh, sure; I noticed it on pending-sru, but there was no workflow task assigned, so I wasn't sure I was supposed to
<sconklin> The workflow bot should have just ticked the tasks over about 5 mins ago
<pitti> sconklin: oh, actually there is now
<sconklin> pitti: thanks!
<pitti> sconklin: done
<pitti> tseliot: I committed your nvidia multiarch patch, seems to work fine on my fake intel testing; thanks!
<pitti> tseliot: I get a crash in NvidiaDetector/alternatives.py set_alternative(), looking into that now; but enabled() now gives the correct results
<tseliot> pitti: np. I can do the same for fglrx
<tseliot> pitti: if you show me the crash I can fix it
<pitti> tseliot: http://paste.ubuntu.com/635026/ -> happens when I enable or disable nvidia
<pitti> 2011-06-29 14:26:43,099 DEBUG: NVidia(nvidia_current).enabled(): target_alt None current_alt /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf other target alt None other current alt /usr/lib/nvidia-current/alt_ld.so.conf
<pitti> tseliot: prsumably it tries to pass None as an argument?
<tseliot> pitti: that None looks suspicious, I'll check the code
<pitti> tseliot: I'll add a debugging line for other_open_drivers
<tseliot> thanks
<pitti> tseliot: right, as I suspected
<pitti> 2011-06-29 14:35:34,609 DEBUG: NVidia.disable(nvidia_current): open_drivers: /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf
<pitti> 2011-06-29 14:35:34,938 DEBUG: NVidia.disable(nvidia_current): other_open_drivers: None
<pitti> tseliot: should the nvidia driver just not call self._other_alternatives.set_alternative(other_open_drivers) if it's none?
<simon-o> Hi, I tried to build a oneiric package for natty using a build recipe: https://code.launchpad.net/~simono/+recipe/scala-natty but this didn't work: https://code.launchpad.net/~simono/+archive/personal/+recipebuild/55045 Any ideas why it failed?
<pitti> tseliot: or should set_alternative be robust with that?
<micahg> simon-o: I think you want #ubuntu-packaging
<pitti> tseliot: I'll add a None test for now
<simon-o> micahg, right, thanks
<RAOF> doko: Pong re: mesa/llvm.  Are you in the foundations room?
<slangasek> RAOF: he's next door w/ me at the moment, but we'll be over there soon
<RAOF> slangasek: Over here in the desktop room?
<RAOF> Or over there in the foundations room?
<slangasek> RAOF: over there in the foundations room
<seb128> RAOF, they are the ones having issues, they should be the one moving to us :p
<pitti> well, disk space is not really an one-team problem
<seb128> pitti, see the ":p"
<seb128> ;-)
<pitti> tseliot: ok, working fine now; I'll commit the None check
<doko> RAOF: in 5min
<tseliot> pitti: right other_open_drivers can be None, that's what I forgot to handle. Good catch
<cr3> barry: guess what I'm doing?
<cr3> barry: question for you: the new package contains python files under ./usr/lib/python2.6/dist-packages/ and ./usr/lib/python2.7/dist-packages/ in addition to ./usr/share/pyshared/ whereas the old package only contains files under the latter directory.
<cr3> oddly, this doesn't seem to affect the resulting size of the package much... viva compression
<ScottK> cr3: Did you just switch it to use dh_python2?
<cr3> ScottK: yes, is that expected behavior?
<ScottK> The /usr/lib ... are symlinks.
<cr3> ScottK: ah, my mistake, I was looking at the output of dpkg -c | awk '{print $6}'... thanks!
<ScottK> This is expected.
<ScottK> pysupport/central would generate these symlinks at install time.
<ScottK> Including them in the package is better.
<jelmer> doko, slangasek: lp:~jelmer/gcc/gcc-4.6-import is up now
<cr3> pitti: I'm planning to increase the size of the checkbox deb by 169Kb, is that alright?
<cr3> bladernr: ^^^ thought you might be interested
<cr3> barry: checkbox-gtk depends on gir1.2-gtk-3.0; however: Package gir1.2-gtk-3.0 is not installed.
<cr3> barry: I'm not sure I understand why though, the depends and recommends line look the same
<slangasek> jelmer: and can that be pushed to lp:gcc?
<barry> cr3: hi.  hmm, i'm not sure why either, since i didn't touch those parts
<barry> cr3: what room are you in?  maybe i can come down and pair with you?
<cr3> barry: my mistake, I'll get back to you shortly
<barry> cr3: cool!
<cr3> barry: give me a moment before running around, I wouldn't want you to see me screw up in person :)
<pitti> cr3: shold be okay; but thanks muchly for caring!
<cr3> pitti: awesome, thanks for the confirmation :)
<BenC> Any good ubuntu coders looking for work (fulltime/telecommute/mpeg/rtsp/little bit of kernel/mpeg4/h264/alsa/v4l2/packaging/daemon/sql/php)?
<nigelb> wow, you've gone from kernel all the way to php+sql
<BenC> I'm looking to replace myself with my last employer
<BenC> big shoes :)
<BenC> The kernel isn't important, but you need to understand v4l2 and alsa API
<nigelb> You could post the planet for a wider audience
<jelmer> slangasek, I can fix lp:gcc but by pointing it at a different branch for the moment ("bzr branch lp:gcc" would still do the right thing)
<slangasek> jelmer: and would continue to do the right thing later, not give us branch divergence? :)
<jelmer> slangasek: yes, that would not cause divergence later
<slangasek> jelmer: that would be great then :)
<cr3> barry: checkbox done!
<janimo> anyone else seeing issues with latest apt? apt-get changelog segfaults on oneiric. dist-upgrade does nothing. x86
<pitti> tseliot: hm, so I'm confused -- "modinfo nvidia" doesn't exit, "modinfo nvidia_current" does; but once you load it, "lsmod" will show "nvidia", but not "nvidia_current"; is that supposed to be that way?
<tseliot> pitti: yes but you can resolve the alias and find the real name in nvidia-common, IIRC
<pitti> tseliot: ah, it already seems to do that, it overrides used()
<pitti> so I'll debug that then
<tseliot> right
<pitti> 2011-06-30 02:00:53,876 DEBUG: Nvidia.used: module nvidia_current, module_alias nvidia, resolved alias:
<pitti> tseliot: ^
<pitti> tseliot: so the module_alias seems correct (it's calling module_loaded() on that)
<pitti> tseliot: but it seems that resolve_module_alias("nvidia") is returning nothing, instead of "nvidia_current"
<pitti> tseliot: this seems to be a bug in MultiArchUtils
<tseliot> pitti: I don't know if it works in both directions
<pitti> tseliot: what's the direction it's supposed to work in?
<pitti> tseliot: right now it expects resolve_module_alias("nvidia") == "nvidia_current"
<pitti> i. e. translate the name in "lsmod" to the actual kmod file name
<tseliot> pitti: all the library does is call modprobe --resolve-alias $alias
<pitti> modprobe --resolve-alias nvidia -> ""
<pitti> so is that the bug?
<pitti> tseliot: how is that alias defined?
<pitti> /etc/modprobe.d/nvidia-graphics-drivers.conf just has a couple of blacklist s
<barry> cr3: hey man, how's checkbox going?  anything i can do to help?
<tseliot> pitti: dkms does it
<tseliot> pitti: in dkms.conf
<barry> jelmer: ping
<jelmer> barry, hello
<tseliot> pitti: you can find more about it in dkms' man page
<barry> jelmer: hi.  i'm starting to work on gnome-orca but it's got import failures.  was just wondering if this was one i could fix manually, and if so, how? :)
<jelmer> barry: I'm not entirely sure, it seems like a bzr bug of some sort but I haven't looked into this one
<jelmer> barry: vila or maxb might be able to say more about it
 * maxb checks that one
<barry> maxb: if it's not easy i can always import-dsc to unblock
<maxb> Oh, that's one of the NoFinalPath ones
<barry> maxb: what does that mean?
<maxb> It means we need someone who understands bzrlib's preview transform merge code to figure out why it's throwing that exception
<barry> maxb: ;)  okay, no worries.  i'll import-dsc
<barry> maxb, jelmer thanks!
<elmo> what happened to the parseable copyright file stuff - did that get stalled/not happen?
<tumbleweed> it's going to be in the next debian policy release
<slangasek> that's a bit of an overstatement
<slangasek> there are still bugs in the spec that need fixin'
<tumbleweed> well, as an appendix, IIRC. Not a MUST by any means :)
<slangasek> elmo: http://dep.debian.net/deps/dep5/
<elmo> slangasek: yeah, thanks, I found that - but the ubuntu packaging guide's initial example doesn't use it, but i see now the more detailed example does
<micahg> any archive admin around for a PPA -> archive copy?
<slangasek> elmo: ah; well I don't consider the spec to have the kinks worked out yet to the point of recommending adoption, but I think I'm being more conservative than average
<slangasek> micahg: if we can do it quickly :)
<micahg> slangasek: yep, ubuntu-mozilla-security PPA, lucid firefox -> lucid-security
<slangasek> micahg: a little less brevity and a little more cutnpasterity? :)
<micahg> oh, hmm, let me see if I can find the commands...
<slangasek> I don't have it in my command buffer, sadly
<slangasek> ah, here it is
<micahg> slangasek: copy-package.py -b --ppa=ubuntu-mozilla-security -s lucid --to-suite lucid-security -e 3.6.18+build2+nobinonly-0ubuntu0.10.04.2  firefox
<slangasek> micahg: ack - done
<micahg> slangasek: thanks :)
<jochensp> Hi, my PPA doesn't want to install libvtk5.6 in oneiric, is that known?
<tumbleweed> jochensp: we are half way through a VTK transition (mostly stalled, the remaining packages all fail to build): http://people.canonical.com/~ubuntu-archive/transitions/vtk.html (does that help at all?)
<dtchen> there's also the versioned conflict for libavutil51.
<dtchen> (rather, the versioned dep prevents its installation)
<tumbleweed> oh, right, I think vtk needs a rebuild
<tumbleweed> indeed: http://people.canonical.com/~ubuntu-archive/transitions/libav.html
<jochensp> tumbleweed: thx, will try it again later
<tumbleweed> jochensp: if it only needs a no-change rebuild, I'll upload it soon
 * Chipzz sighs @ http://lkubuntu.wordpress.com/
<broder> â/var/lib/dpkg/tmp.ci//.svnâ: Is a directory> i don't even want to speculate on how your system ends up like that
<Chipzz> "A listing of useful software, tips, tweaks and hacks for Ubuntu". I've only read about 6 articles from there, but all of them were crap
<Chipzz> deb-extract. really??
 * Chipzz facepalms
<Chipzz> broder: http://lkubuntu.wordpress.com/2011/06/29/extract-fully-a-deb-archive-with-deb-extract/
<broder> Ugh. I didn't actually realize all of those articles were coming from the same site
<Chipzz> next one:
<Chipzz> cat << EOF | sudo tee /etc/ld.so.preload /dev/null
<Chipzz> /usr/lib/libv4l/v4l1compat.so
<Chipzz> EOF
<Chipzz> more facepalm :(
<Chipzz> actually 2 facepalms for the price of one
<Chipzz> actually 3 if you count the unnecessary use of cat
<tumbleweed> jochensp: vtk rebuild uploaded
#ubuntu-devel 2011-06-30
<maxb> Would anyone happen to know why mdadm installs udev rules which create /dev/md/* symlinks ?
<maxb> Why the extra names, instead of just using /dev/md* ?
<nobuto> SpamapS, pitti: Hi. "pkgsel" package for Lucid-SRU(Bug #797985) is still in unapproved queue. Could you take a look to push lucid-proposed? Thanks in advance.
<ubottu> Launchpad bug 797985 in pkgsel (Ubuntu Lucid) "Please export Japanese translation from Launchpad" [Medium,In progress] https://launchpad.net/bugs/797985
<elmo> Daviey: your cloud thing is losing it's mind again and spamming us with failure mails
<pitti> nobuto: we'll get to it; I'll probably ask our latest SRU team member RAOF to review it :)
<sveinse> I have a package which has only static files which shall be installed, and I've put the list of the files into debian/install. However, I need to pass --sourcedir to dh_install. How do I do that when I'm using the default %:   dh $@   rules?
<RAOF> sveinse: You can write an override_dh_install: target that will be called instead of dh_install.  That target would call dh_install --sourcedir=whatever.
<sveinse> Are there any variables available for the root of the sources?
<RAOF> The root of the sources?  debian/rules is guaranteed (by dh_test) to be called from the root of the sources (or at least the directory containing debian/), so CURDIR will be what you want.
<sveinse> Excellent. Thanks
<RAOF> pitti: What is the SRU policy WRT translations?  The package for Bug #797985 appears to contain a full export of launchpad translations, so has a bunch of translation changes unrelated to the specific bug, but we probably want them all.
<ubottu> Launchpad bug 797985 in pkgsel (Ubuntu Lucid) "Please export Japanese translation from Launchpad" [Medium,In progress] https://launchpad.net/bugs/797985
<cjwatson> RAOF: I can cut it down if you like, but there didn't seem a strong reason to do so
<RAOF> cjwatson: I agree.  As the newest SRU team member I'm just checking that everyone *else* agrees, too :)
<zyga> https://launchpad.net/~linaro-validation/+archive/ppa
<sveinse> Is it possible to rename the installed file when using the listing in debian/install?
<cjwatson> sveinse: no, sorry, that's a documented limitation (in dh_install(1))
<cjwatson> sveinse: if you need that, create the containing directory in debian/dirs, and then have an override_dh_install rule that does 'install -m0755 source-file-name debian/packagename/usr/bin/target-file-name' or whatever
<sveinse> yes, thanks
<sveinse> Is it considered bad to do 'install -D ...'? (instead of using debian/dirs I mean)
<sveinse> cjwatson: ^
<cjwatson> sveinse: doesn't matter much
<DktrKranz> mvo: hi! vte 2.90 is in unstable now, I think next gdebi upload could be targeted unstable as well.
<mvo> DktrKranz: awsome news!
<pitti> cjwatson, kees: just sent a tb@ mail about moving the meeting today
<mdeslaur> pitti: are you available?
<pitti> mdeslaur: yes, I am; I can come over to the security room
<pitti> ok?
<mdeslaur> pitti: sure, cool
<pitti> your chairs are a lot better than our's :)
<mdeslaur> pitti: yes, they are :P
<kees> pitti: some of our chairs were stolen though
<mdeslaur> kees: Dude! Don't tell him, he won't come
<sveinse> What are the options in the section line in debian/control ?  I thought I could put universe here, but lintian refuses to accept it
<Laney> ha at the security team being a victim of chair theft :-)
<TheMuso> sveinse: The universe keyword is added by the archive software, and does not get put into actual package control files.
<geser> Laney: bad security I'd say :)
 * Laney expects a USN post haste
 * micahg sends USN-CHAI-R
<sveinse> TheMuso, what can be put into the section keyword?
<brendand> anyone know which package contains GtkFileChooserDialog in Oneiric?
<geser> sveinse: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
<sveinse> ok, so the debian sections also applies for ubuntu. Thanks
<evfool> brendand: that'd be probably the gtk package
<evfool> brendand: https://launchpad.net/gtk
<brendand> evfool - not possible to assign a bug to it though. i think that's a project page anyway, not necessarily a package
<brendand> i guess it may be https://launchpad.net/ubuntu/+source/gtk+3.0 ?
<evfool> brendand:yep, that's it
<kees> Laney: you mentioned it were interested in the TB meeting? we're moving it 2 hours earlier, fyi
<Laney> kees: righto. I'm just interested in hearing the outcome to my mail really :-)
<Laney> thanks for letting me know
<kees> okay :)
<pitti> james_w: do you know whether status.u.c. publishes the db files anywhere? I need the current one for debugging
<pitti> james_w: I can't access viburnum.canonical.com
<james_w> pitti, I didn't change that code, so it does
<pitti> http://status.ubuntu.com/ubuntu-oneiric/oneiric.db doesn't exist
<james_w> http://status.ubuntu.com/ubuntu-oneiric/ubuntu-oneiric.db
<pitti> oh, ubuntu-oneiric.db
<pitti> *headdesk*, sorry
<pitti> thanks!
<james_w> np
<pitti> james_w: we retargeted a whole bunch of oneiric specs to p, and the tables updated properly, but not the charts
<james_w> hmm
<pitti> james_w: I suppose the charts still count the dropped WIs somehow
<james_w> not sure what would cause that
<james_w> pitti, you did it by changing the series on the blueprints?
<pitti> yes
<pitti> but I suppose that didn't clean the specs from the db
<james_w> hmm
<pitti> I'm still not quite sure what happened
<pitti> just that we dropped some 50 WIs, and there's no visible dent at all on http://status.ubuntu.com/ubuntu-oneiric/canonical-desktop-team.html
<pitti> hm, on second look I actually can't find any inconsistency in the numbers
<pitti> I'll just do an experiment
<pitti> james_w: do you know when the WI tracker cron fires?
<james_w> pitti, *:33
<pitti> james_w: thanks
<pitti> tseliot: if [ "$1" = install -o "$1" = upgrade ] && [ -z "$2" ]
<mdeslaur> mvo: any availability to talk about the stuff we didn't get around to talking about?
<slangasek> cnd: can x11proto-input 2.0.2-2 be merged?
<mneptok> @conference/canonical  <--- All-Hands? a sprint?
<udevbot_> Error: "conference/canonical" is not a valid command.
<mneptok> udevbot_: sit down you pile of persnickety Python.
<udevbot_> Error: "sit" is not a valid command.
<cjwatson> mneptok: platform rally
<cjwatson> (nee sprint)
<StevenK> Don't forget LP
<mvo> mdeslaur: I will come over at 17:00 or tomorow morning, is that ok?
<cjwatson> oh yes
<mdeslaur> mvo: sounds good, thanks
<mneptok> that's some coincidence. i just bought "Platform Rally" for the PS3.
<StevenK> Indeed, we're doing a bunch of good work. Unless you're infinity.
<StevenK> That came out wrong. :-(
<mneptok> StevenK: welcome to my world.
<StevenK> mneptok: You should see a doctor for that.
<mneptok> StevenK: i tried. the doctor said solving that issue is like putting a Band-Aid on an amputee. :/
<cnd> slangasek, I'm not sure what you're asking?
<cnd> I'm sure it could be merged, it looks like a bug fix according to the version numbers
<cnd> there could be conflicts, but I'd be surprised if there were
<slangasek> cnd: I'm asking if it's safe to merge the new upstream version; you're listed on https://merges.ubuntu.com/main.html as the last person to touch it, I haven't looked at the delta at all and don't know if from your perspective there's a risk of regressions caused by pulling the new upstream version
<cnd> slangasek, let me take a look at debian's changes, but I can't imagine it would be a problem
<cnd> my patch to x11proto-input is pretty large though :)
<cnd> it includes the prototype xinput 2.1 support
<cnd> but that should be rather self-contained away from the rest of xinput 2.0 and earlier stuff
<cnd> slangasek, looks like it should be fine save for one trivial conflict
<cnd> I pushed a small patch upstream that landed in 2.0.2
<cnd> that change was rolled up as part of my 1_xi2.1.patch, instead of being a separate patch
<cnd> I should have made it a separate patch back when I added it :(
<cnd> removing lines 94-101 (a small diff hunk) of 1_xi2.1.patch should do the trick
<slangasek> bdmurray: /usr/share/apport/general-hooks/ubuntu.py
<apw> pitti: do you know how often the ddebs.ubuntu.com packages files are rebuilt ?
<pitti> 10 3,7,11,15,19,23
<pitti> apw: ^ for oneiric
<apw> pitti: and for older releases ?
<pitti> 10 2,10,18
<apw> pitti: thanks :)
<sveinse> What is the difference between dh_install and dh_auto_install ?
<cjwatson> have you read the man pages?  they have quite good descriptions
<sveinse> Yes, but admit skimming them. Let me rephrase: dh_install handles the debian/install files while, dh_auto_install takes care of calling make install, right?
<sveinse> I have a rule here where I override install. How should I pass $DESTDIR to the target makefile?    override_dh_auto_install:  \n   make INSTALL_ROOT=$(DESTDIR) install      does not work, INSTALL_ROOT is empty
<cjwatson> sveinse: dh_install/dh_auto_install> right, that's a good summary
<sveinse> It seems DESTDIR environment variable is not set when going into the override_dh_auto_install rule
<sveinse> Hmm. I'm clueless and google doesn't tell me much.
<sveinse> How do you guys handle install if the Makefile wants to install to INSTALL_ROOT instead of DESTDIR?
<sveinse> Can't patch Makefile, as it's auto generated
<slangasek> sveinse: patch the non-auto-generated source file
<sveinse> This is a Qt application. That would mean to patch upstream qmake in another package...
<nigelb> sveinse: look at how other qt apps have been done maybe?
<nigelb> "apt-cache search qt" may give you a few pointers of other qt-based applications
<sveinse> Doing a quick search of qt4-x11 sources, it seems qmake is not patched for chaning INSTALL_ROOT to DESTDIR at least. Checking apps...
<sveinse> But override_dh_auto_install of qt4-x11 reveals it:   $(MAKE) install INSTALL_ROOT=$(CURDIR)/debian/tmp/
<sveinse> Not what I expected thou
<slangasek> sveinse: oh, sorry - INSTALL_ROOT and DESTDIR are equivalent except for the name?  Yeah, no need to patch that, the described override is pretty much what one would expect
<slangasek> (provided that dh_auto_install doesn't actually know how to detect qmake)
<sveinse> Hmm. Not quite. If I remove my override_dh_auto_install, I see dh running "make -j1 install DESTDIR=/home/user/packages/lmas/debian/lmas", while the above override uses debian/tmp
<cjwatson> sveinse: that depends on the dh compat level; with a modern package, $(CURDIR)/debian/lmas is correct
<cjwatson> it also differs for multi-binary packages
<cjwatson> qt4-x11 is unlikely to be a good example to refer to for Qt *application* packaging
<sveinse> cjwatson: This should be a single-binary package. Are there any other places than debian/control that control if it's a multi or single binary package?
<cjwatson> sveinse: nope
<sveinse> Given a newer dh compat level and if $(CURDIR)/debian/lmas is correct, then I need to find my own package name unless I want to hardcode the latter "lmas" part of the path
<cjwatson> $(shell dh_listpackages)
<cjwatson> (assuming single-binary)
<sveinse> excellent, now things look better. Thanks
<carldani> Hi!
<carldani> I'm not familiar with the development process of Ubuntu. I read the wiki, but I'm still a bit unsure about the significance of DebianImportFreeze.
<carldani> The flashrom package in Debian unstable is a bit outdated and the release of a new upstream flashrom version is expected to happen in the next few weeks. Is there a chance to get that new (mostly bugfixes) flashrom version included in Oneiric, and if so, can it be made a copy of the Debian flashrom package which is hopefully updated directly after the flashrom release?
<geser> carldani: DebianImportFreeze only means that automatic copies of packages Debian -> Ubuntu will stop, once the updated flashrom package is in Debian someone has to request a sync from Debian (assuming the upload to Debian happens between DebianImportFreeze and FeatureFreeze)
<carldani> geser: Thanks for the info!
#ubuntu-devel 2011-07-01
<hyperair> Ampelbein: pign
<AnAnt> Daviey: Hello, LP #796136
<ubottu> Launchpad bug 796136 in swt-gtk (Ubuntu) "Please merge swt-gtk 3.7-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/796136
<smoser> is there a limit on size of value for a debconf key ?
<cjwatson> smoser: not formally; you will run into slightly less-tested code in cdebconf if you cause any debconf protocol line to be greater than 1024 bytes
<cjwatson> smoser: but any limit is a bug
<smoser> thanks.
<cjwatson> (and one I'm prepared to fix)
<tkamppeter> mpt, sladen, hi
<mpt> jcastro, are you the right person to bug about the way Ubuntu is presented in Launchpad?
<udoprog> regarding lightdm, how do you configure it to run on a single screen (or any X configuration) in a nice manner?
<udoprog> do you specifically override the X command to use or are there any facilities to handle this?
<tjaalton> udoprog: write an xorg.conf if you need to force things for the login screen
<udoprog> tjaalton: k, thanks
<YokoZar> Is there a sprint of some sort going on atm?
<Laney> yeah
<Laney> platform rally I think it's called
<barry> zul: any word on python-image-store-proxy?
<zul> barry:  not yet
<barry> zul: okay.  since cr3 has decided to hide from me :) i'm going to upload checkbox, which will make p-i-s the last python-central package on the cds.  expect me to sit next to you after lunch quietly but disturbingly sipping my tea until its fixed. :)
<zul> barry: greeeeeat :)
<barry> zul: better here in dublin than at your house next week... :)
<GunnarHj> robert_ancell: Hi Robert, do have a minute to talk about lightdm and language chooser?
<robert_ancell> GunnarHj, sure
<GunnarHj> robert_ancell: Did you read my latest comment on bug 793366?
<ubottu> Launchpad bug 793366 in lightdm (Ubuntu) "Sets $LANG to invalid value "de"" [Undecided,Fix released] https://launchpad.net/bugs/793366
<ogasawara> cjwatson: apw plans to link up with you next week re: overlayfs
<robert_ancell> GunnarHj, yes, from what I'm hearing though there's not a requirement for a language selector at the greeter as such, but more of a requirement to be able to run from a fixed subset of languages.  I think this can be better achieved using the sessions as this only gives the user one choice
<GunnarHj> robert_ancell: A fixed subset of languages? But isn't that just what a language chooser would display? I.e. the translations in the languages of interest.
<GunnarHj> robert_ancell: Has the matter been discussed recently in the desktop team or elsewhere? I don't think I'm the only one who regret that the chooser has been dropped in GDM.
<robert_ancell> GunnarHj, yes, but you don't need all combinations.  For the majority of users they will never use the language option (and it is something that can be accidentally changed).  The use case that I have heard of seems to be non-english speakers wanting to switch to english.
<pitti> jdstrand, cyphermox: is the ufw profile support for https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-desktop-network-enhancements still on the plan for oneiric, or sohuld we postpone this?
<cyphermox> pitti: postpone, I think
<robert_ancell> GunnarHj, the design of the Oneiric greeter (done by the Canonical design team) does not have a langauge selector.
<pitti> it's currently marked for a2, which is rather impossible now, I guess
<AnAnt> could someone sponsor LP #801884
<ubottu> Launchpad bug 801884 in debhelper (Ubuntu) "Candidate revision debhelper 8.9.0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/801884
<cyphermox> pitti: yes, espcially the UI parts... but I guess that doesn't block working on getting UFW to have the necessary bits
<pitti> moved to a3 for now, and if it doesn't land by then, we'll move it to p
<jdstrand> pitti: I do plan to have the ufw specific support for oneiric, but that is probably going to be alpha-3
<pitti> jdstrand: great, thanks; so I milestoned it there then
<jdstrand> but if no one is working on the UI, then there is a high chance I'll backburner it as well
<jdstrand> pitti: thanks :)
<robert_ancell> GunnarHj, I'm updating the bug with more information
<GunnarHj> robert_ancell: I'm sure that the non-english speakers are more inclined to appreciate the feature than English speakers. But ... Don't you think that most of those 200 miljon Ubuntu users that was mentioned recently will belong to the former group?
<robert_ancell> GunnarHj, the important point here is the ability to use their session in the appropriate language, not to have a specific UI component.  A combo box is a very clumsy way of setting your session language
<GunnarHj> robert_ancell: Think I disagree on that. Personally I think that the Natty GDM approach is quite ok.
<GunnarHj> robert_ancell: And even if it wasn't included in the spec.: We are a few who would like to see it. Including it wouldn't hurt the rest, would it?
<GunnarHj> robert_ancell: And it won't require much additional work to get it in place.
<GunnarHj> robert_ancell: Should we maybe bring the discussion to the ubuntu-desktop list?
<robert_ancell> GunnarHj, sure, we also need the designers to get involved
<GunnarHj> robert_ancell: Ok. Do you want to start the discussion or should I do it?
<robert_ancell> GunnarHj, you can start it if you want
<GunnarHj> robert_ancell: Will do so later today. Thanks for the chat so far. :)
<robert_ancell> GunnarHj, no problem.  It's an interesting problem and I hope we can come up with a clever solution
<GunnarHj> robert_ancell: Me to.
<barry> ara ping
<ara> barry, hello!
<barry> ara: hi!  you are a member of ~checkbox-admins.  i want to upload the latest trunk, but there's a minor bug preventing building a source package from lp:checkbox.  would you be able to quickly review and land a merge proposal?
<ara> barry, sure
<ara> brendand will be able to help as well
<ara> he's been doing the latest changes to checkbox
<barry> ara: awesome.  will paste url in just a few minutes
<ara> thanks!
<barry> ara, brendand https://code.launchpad.net/~barry/checkbox/enoent/+merge/66598
<ara> barry, looking at it now
<barry> ara: \o/
<pitti> skaet: https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus updated, FYI
<skaet> pitti,  Thanks!
<barry> hi ara.  any questions or problems with the change?  as soon as you merge the branch i can push a new checkbox.  it's the last python-central package on the desktop cd so i'm really anxious to get it uploaded! :)
<brainwave92> Noone here?
<brainwave92> is there anyone active on this cannel?
<holstein> brainwave92: whats up?
<holstein> check out the topic, this really isnt a social channel
<brainwave92> ya but no ones saying anything, i thought of joining into some discussion on Oneiric
<brainwave92> holstein, thats  whyi was stunned by the silence....apologies!
<holstein> brainwave92: you might try #ubuntu+1 ??
<ara> barry, roadmr and I were trying to build checkbox after the merge, and it does not build for us in oneiric
 * roadmr :(
<brainwave92> k thanks....! i'll try
<brainwave92> join #ubuntu-1
<brainwave92> oops
<barry> ara: darn :(  where are you sitting, can i come down and shoulder surf?
<roadmr> barry: Munster room, ground level, thanks :)
<barry> on my way!
<roadmr> barry: thanks a lot, we really appreciate it
<debfx> pitti: firefox is pulled on the kubuntu cd due to bug #800857 so I think it's important to fix it before alpha 2
<ubottu> Launchpad bug 800857 in firefox (Ubuntu Oneiric) "language packs pull in Firefox on upgrade" [High,Triaged] https://launchpad.net/bugs/800857
<micahg> chrisccoulson: ^^
<pitti> good point, yes
<pitti> targetted back to a2
<brendand> does anyone know if 'The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present' that appears sometimes in Natty is a bug?
<brainwave92> i want to join ubuntu development team, as a beginner.....any one knows the channel for that chat by any chance?
<slangasek> brendand: is that a literal quote?
<slangasek> ah, yes it would be
<brendand> slangasek - that's exactly what plymouth (??) says
<slangasek> brendand: not a bug per se; if the message never /goes away/, that's a bug
<brendand> slangasek - it seems random to me. didn't happen in maverick though?
<slangasek> brendand: don't know what would have changed for you between m and n; it's entirely a timing thing
<brainwave92> #join
<brainwave92> oops
<barry> ara, roadmr yep, built fine for me in my ppa: https://launchpad.net/~barry/+archive/python/+packages
<ara> barry, roadmr is going to push the changes to the trunk
<roadmr> barry: thanks for the confirmation!
<barry> ara: roadmr beauty!
<AnAnt> Hello, could someone sponsor LP #801884  ?
<ubottu> Launchpad bug 801884 in debhelper (Ubuntu) "Candidate revision debhelper 8.9.0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/801884
<bdrung> cjwatson: can you sync distro-info from unstable (it was accepted recently)
<cjwatson> bdrung: done (though for the future, a sync request bug is easier for me to process)
<bdrung> cjwatson: thanks. i forgot that we passed DIF.
<cjwatson> well, that doesn't matter, it doesn't need particular approval yet, but a bug means I can use the sync-helper tool
<bdrung> good to know
<jsjgruber_> How do I convert an upstream to use dh_python2, as desired by Oneiric plans, and continue to build Maverick and Lucid packages from the same branch? (wrong channel to ask?)
<jsjgruber_> python-central build dependencies were not raised beyond lucid like dh_python2
<bdrung> jsjgruber_: you could backport dh_python2 (assuming you are using a PPA for maverick & lucid)
<tumbleweed> bdrung: it's a non-trivial backport, but it's in progress
<Quibus> hi all
<Quibus> I just asked this question on #ubuntu:
<Quibus> I'm wondering why ubuntu misses version 0.8.1. of the openMSX package (while it is in Debian for months already).
<Quibus> Strangely enough, the GUI of 0.8.1 is available (openmsx-catapult)
<Quibus> Looks like something went wrong?
<Quibus> openmsx-catapult is useless without openmsx
<nigelb> Quibus: In oneiric?
<Ampelbein> Quibus: most likely it didn't get merged yet
<Quibus> nigelb: I checked this: https://launchpad.net/ubuntu/+source/openmsx/
<Quibus> and this: https://launchpad.net/ubuntu/+source/openmsx-catapult
<tumbleweed> Quibus: it's generally up to the previous uploader to do a merge
<Quibus> 0.8.1 package was autosynced on 30 April
<tumbleweed> if we modified a package in Ubuntu, we need to manually merge those modifications into future versions
<tumbleweed> only un-modified packages can be auto-synced
<Quibus> How can I see if it is modified?
<bdrung> Quibus: if 'ubuntu' is in the version number
<Quibus> It is for 0.8.0
<bdrung> including the debian revision -> 0.8.0-1ubuntu1
<Quibus> ah, Matthias fixed something there
<bdrung> Quibus: you could ask him (doko on IRC) to merge the new version
<Quibus> doko_: hi :) Interested to merge openMSX 0.8.1 into O?
<tumbleweed> of course anyone else could merge it too, but it's probably not on their todo lists...
<Quibus> It should be quite easy, but OK
<bdrung> Quibus: if he doesn't want to do it, feel free to do it yourself
<bdrung> tumbleweed: btw, distro-info passed all barriers
<tumbleweed> bdrung: I saw, \o/
<Quibus> bdrung: I'm the upstream developer... I don't like to take care of package management for a kazillion distros out there...
<Quibus> I'd rather focus on the actual software
<bdrung> Quibus: as upstream dev, do you have fixed the inline assembler that is causing the problem with thumb2 (bug #635413)?
<ubottu> Launchpad bug 635413 in openmsx (Ubuntu Oneiric) "armel build failure (thumb problem?)" [Undecided,Confirmed] https://launchpad.net/bugs/635413
<Quibus> No, we don't have a compiler envirionment to test it
<tumbleweed> it might be reproduceable in qemu. /me looks
<bdrung> tumbleweed: what do you think about bug #796187?
<ubottu> Launchpad bug 796187 in libevent (Ubuntu) "Sync libevent 2.0.12-stable-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/796187
<bdrung> who decides to start a transition?
<Quibus> tumbleweed: thanks
<tumbleweed> bdrung: I think we generally trust uploaders to decide whether kicking off transitions is a good idea or not. I haven't seen the release team schedule them like in Debian
<bdrung> four package FTBFS carry no weight
<tumbleweed> obviously test-building all build deps is sensible. Then decide how important/fixable they are
<bdrung> tumbleweed: it was done last cycle (bug #622204)
<ubottu> Launchpad bug 622204 in dovecot (Ubuntu) "adduser: Warning: The home directory `/usr/lib/dovecot' does not belong to the user you are currently creating." [Low,Expired] https://launchpad.net/bugs/622204
<bdrung> wrong number, it was bug #701471
<ubottu> Launchpad bug 701471 in libevent (Ubuntu) "Sync libevent 2.0.10 from Debian experimental" [Wishlist,Expired] https://launchpad.net/bugs/701471
<tumbleweed> bdrung: I'd talk to kklimonda who evaluated it in natty, and the debian maintainer (who should have some feeling for how ready it is)
<bdrung> tumbleweed: then i was too fast ;)
<bdrung> tumbleweed: feel free to veto my bug comment
<tumbleweed> bdrung: that's the ubuntu way: "break it now, fix it later" :P
<tumbleweed> Quibus: you should easily be able to replicate this under qemu. 0.8.1 still exhibits it
<bdrung> tumbleweed: break it now, let someone else fix it later
<bdrung> :P
<Quibus> tumbleweed: yes, as I said, we didn't fix it, because we didn't have a working cross compiler with thumb2 support to test it
<Quibus> Only one for arm926
<tumbleweed> Quibus: I'm not using a cross compiler but a full-blown ubuntu armel chroot, and qemu-user-static. You could create such an environment by running "pbuilder-dist armel create"
<tumbleweed> anyway, seeing as I've looked at this, I'll merge it now
<Quibus> Oh, hey, thanks :-)
<Quibus> I gave this info to our ARM specialist
<Quibus> a.k.a. the main developer :-)
<Quibus> I hope he can fix it
<carldani> is https://help.ubuntu.com/community/SupportedArchitectures still correct w.r.t. Oneiric?
 * tumbleweed sees no mention of armel there
<bdrung> carldani: armel is missing in this list
<cjwatson> carldani: yeah, completely out of date - first time I've seen that page
<cjwatson> carldani: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Architectures is up to date
<broder> cjwatson: sounds like it's time to invoke that promise you made to jcastro :-P
<broder> (err, rather, that we all made)
<carldani> bdrung, cjwatson: thanks!
<cjwatson> maybe, but I'm going to bed :-)
 * cjwatson adeptly dodges responsibility
<cjwatson> bdrung: binary-NEWed distro-info, BTW
<Quibus> good night folks
#ubuntu-devel 2011-07-02
<_schulte_> anyone have pointers to information on configuring lightdm?  I'm trying it out as my display manger, and I'd like to try different (e.g., webkit) themes.  thanks
<bdrung> cjwatson: thanks
<dpolehn> has the debian import freeze already started?
<bryceh> _schulte_, /etc/lightdm/
<charlie-tca> dpolehn: according the schedule, yesterday - https://wiki.ubuntu.com/OneiricReleaseSchedule
<dpolehn> thanks
<dpolehn> charlie-tca: so bugs need to be filed to import packages from debian correct?
<charlie-tca> yes, I think so
<dpolehn> thanks again
<_schulte_> bryceh: beautiful, thanks, I should have thought to look there...
<evfool> has someone ever used auto-upgrade-tester? can I get a bit of help with it?
<euroford> hi all
<euroford> i want to update gmp and gcc in lucid
<euroford> gmp can be built without any problem
<euroford> bug it break gcc when i upgrade gmp
<euroford> and i just link libgmp.so.3 -> libgmp.so.10.0.2
<euroford> gcc works again
<euroford> and works well
<euroford> my question is what shall i do if i want put new gmp into ppa,  to build other packages?
<euroford> how can i install both version of gmp in pbuilder env?
<nh2_> cnd: is there an application that displays all fingers on a touchpad as dots to show where they are?
<cnd> nh2_, would a fingerpaint application work?
<nh2_> cnd: I think so
<cnd> nh2_, install qt4-demos and run /usr/lib/qt4/examples/touch/fingerpaint/fingerpaint
<cnd> that path is off the top of my head, so you may need to fiddle with it
<nh2_> cnd: it start a program "Finger Paint"; it does nothing, though
<nh2_> *starts
<cnd> nh2_, what do you mean by "it does nothing"?
<cnd> what device are you using?
<nh2_> cnd: Synaptics Touchpad in a Thinkpad
<cnd> oh
<cnd> synaptics doesn't provide full multitouch information
<cnd> so we can get some gestures out of it
<cnd> but you can't see the location of the touches, for example
<nh2_> cnd: actually, I wanted to find a program to find exactly that kind of information :D (what information touchpads deliver), so I better ask you
<cnd> ahh
<cnd> let me think
<cnd> I don't think we have any visual tools for semi-mt trackpads
<nh2_> so synaptics tells you where one finger is? what does it tell for this value when you put more fingers on it?
<cnd> all our visual tools are for fully multitouch devices
<cnd> it gives you a bounding box of all the touches
<cnd> unless you have a really new device, in which case it gives you the location of the first and the last touch
<cnd> in both cases you also know how many touches there are
<nh2_> cnd: how can I find out? I think I once had some kind of terminal app. that told me the numbers of fingers currently on the pad
<cnd> I don't know how you can tell between the two right now; someone posted a series of patches for the new devices just last week, but I haven't had a chance to review them
<nh2_> cnd: what is also weird is that cat and evtest don't show any output for /dev/input/event7 (which is my touchpad); both work fine on event6 though (which is the trackpoint)
<cnd> nh2_, the synaptics X input module grabs the evdev device node
<cnd> so you would need to change VTs and run evtest there
<nh2_> ahaaa :) it works
<nh2_> is there a tool for X that outputs what it grabs?
<nh2_> or something lower-level than xev that shows me what actually happens in the hardware from the X side?
<nh2_> cnd: and I guess synaptics does not support "quadtap"?
<cnd> nh2_, I don't know of any tool that visualizes evdev data
<cnd> and X does not generate any multitouch events for these devices
<cnd> I also don't know of anything in synaptics that does something for qaudtaps :)
<nh2_> cnd: When I use a synaptics device, should I get output from geistest?
<cnd> nh2_, yes, you should be able to get 1-3 touch gestures, everything except rotate
<nh2_> cnd: hmm, I don't get any output. What for example should generate output? 2-finger-move?
<cnd> yeah
<nh2_> hmm
<cnd> well, geistest doesn't subscribe to one finger gestures
<cnd> so two and three finger gestures
<nh2_> I guess this is also the reason why touchegg doesn't wokr
<cnd> probably :)
<cnd> are you sure your device is multitouch?
<cnd> it has to be semi-multitouch, not just multi-finger
<nh2_> ugh, what is the difference between semi-mt and multi-finger?
<nh2_> (btw scrolling up/down here in empathy works fine with 2 fingers, but I don't know if that tells anything)
<cnd> multi-finger is when the trackpad gives one coordinate (X,Y) and says how many fingers are on the touchpad
<cnd> semi-multitouch is when the trackpad gives two coordinates forming the bounding box of all touches, and how many touches are on the trackpad
<cnd> btw, touches == fingers :)
<cnd> multi-finger could provide drag gestures through uTouch, but we haven't added support
<cnd> we tried adding it at one point, which broke people's trackpads during the natty cycle, so we reverted the change and haven't tried again yet
<nh2_> how can I find out which type this Synaptics is?
<nh2_> cnd: ahh. I think this is my problem: https://answers.launchpad.net/utouch/+question/157563
<nh2_> the change you referenced to, is that already in Oneiric by now?
<tlp> Hi. Latest alpha release/kernel will not boot on my 2007 iMac at work. Known issue? I've been using the previous kernel via grub.
<tlp> I think there's a panic or something. Not sure if it's logged somewhere -- couldn't find it.
<penguin42> tlp: What happens ?
<tlp> system begins to boot as normal, then freezes. If I do the recovery mode, I see a normal dmesg boot combined with some errors (which I don't have with me unfortunately.)
<tlp> I'm thinking not having 3.x might be screwing up the r300g video driver as well, since Unity doesn't render.
<penguin42> bryceh: Ping
<penguin42> bryceh: bug 803610 looks like a continuation of your fight with synaptics
<ubottu> Launchpad bug 803610 in xserver-xorg-input-synaptics (Ubuntu) "synaptics touchpad upgrade freezes X directly after login" [Undecided,New] https://launchpad.net/bugs/803610
<bryceh> penguin42, you able to repro it?  you know the drill... collect a full backtrace
<penguin42> bryceh: No I'm not, just thought it worth pointing out given the work you'd done on that one
 * penguin42 is just triaging bugs at the moment
<bryceh> penguin42, ah thanks
<bryceh> penguin42, in general when you run across bugs reporting crashes without full backtraces, have them collect a full backtrace
<bryceh> crash bugs without backtraces are about as useful as freeze bugs without gpu dumps :-)
<penguin42> bryceh: By full do you mean a 'bt' from gdb or is the xorg.0.log ok if the debug packages are installed?
<bryceh> 'bt full'
<penguin42> ok
<bryceh> Xorg.0.log never includes the state of variables and such that you get with full backtraces
<bryceh> full backtrace also indicates what line number the failure was on
<penguin42> sounds like it could do with triggering gdb itself if it was installed
<bryceh> penguin42, now you understand what apport does :-)
<bryceh> X just uses the libc backtrace routine.  It'd be nice if libc had a routine that printed gdb like full traces
<bryceh> but for most purposes our apport hook does the trick
<bryceh> however it isn't turned on post-release
<penguin42> yeh, that's a shame really; it would be nice to turn it on for particularly problematic things like X
<bryceh> it'd be ok for X crashes, those are rare enough.  but in general we'd probably be innundated with too many bug reports
<bryceh> I mean, more than we already are :-P
<penguin42> nod
<bryceh> if we had a proper crash database for the post-release ones to go to, rather than filing them as bugs directly, that'd make it worth collecting them
<bryceh> https://dev.launchpad.net/LEP/ApportOnStable
#ubuntu-devel 2011-07-03
<faina> I'm trying to build packages for the firefox sync server, and have a question about packaging python mako templates.
<faina> should the templates be compiled to .py files and then included -- done some how in the debian/rules, or should I try to figure out some where to cache them when compiled after installation?
<maxb> Hm, if a package was removed from Debian in plenty of time before DebianImportFreeze, and there are no ubuntu modifications, shouldn't it have automatically been removed from oneiric too?
<jtaylor> I don't think its automatic
<jtaylor> must be requested
<tumbleweed> maxb: removal isn't automatic, archive admins occasionally look at removals in Debian
<tumbleweed> it's not necessary to explicitly request it when Debian has removed it
<maxb> ah
<bdrung> persia: re your dmb mail: all this should be documented somewhere (e.g. wiki page)
<ansgar> Does Ubuntu already allow packages (both source and binary) to use XZ compression?
<persia> bdrung: Absolutely.  If the TB doesn't change it, let's put it in the wiki
<Laney> Basically it's what (most of us) thought we were doing anyway.
<Laney> but thanks for spelling it out
<persia> I should probably rely less on memetic transmission and more on documentation :)
<Laney> at least it's in the ML archives
<Laney> that's a form of documentation.
<persia> I thought it was in the minutes of some meeting before.  Anyway, we should have iut in the wiki, as we'll forget again in another couple years.
<Laney> yep. after the tb speaks.
<faina> I was trying to build a debian package of the firefox sync server and ran into a python packaging policy question. They're using mako templates which compile to .py files. I was trying to figure out if it'd be better to compile the templates into the package, compile them into a cache directory at runtime on the installed systemm, or compile them when the package is installed.
<persia> faina: Create the .py files at build time.  Let the system generate the .pyc files at install time.  Do not build anything at package creation time.
<faina> Ok, I'd almost convinced myself that the template compiling should be done at install time, as that'd be like the current .py -> .pyc policy.
<faina> But I think compiling at build time would be a lot easier
<persia> Indeed.  Saves lots of compute cycles worldwide.
<faina> why is there the build .pyc at install-time policy? Oh... because you don't know which versions of python are installed
<persia> Right :)
<faina> thank you... I've been trying to figure out a good answer to that question for a couple of days
<jMCg> Hello happy people.
<jMCg> I'm a traffic server dev, and I'm trying to repro this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632546
<ubottu> Debian bug 632546 in trafficserver "trafficserver: FTBFS with ld --as-needed" [Normal,Open]
<jMCg> On Natty this builds fine, so if I get this right, these symbols don't exist in Natty's libssl.
<tumbleweed> jMCg: daemonkeeper was just asking the same questions in #debian-ubuntu on OFTC
<jMCg> tumbleweed: I'll be there for less.. uh.. stuff.
<tumbleweed> you'll only see this occur in pre-release natty or oneiric. ld stopped using --as-needed by default for natty release, because not all packages were building yet
#ubuntu-devel 2012-06-25
 * infinity wishes his compilers built as fast as yours.
<robert_ancell> infinity, well, we are just leveraging your compiler
<jbicha> robert_ancell: bug 1017289
<ubottu> Launchpad bug 1017289 in manpages (Ubuntu) "package manpages 3.35-0.1ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/getent.1.gz', which is also in package libc-bin 2.15-0ubuntu15" [Undecided,Confirmed] https://launchpad.net/bugs/1017289
<robert_ancell> jbicha, cheers
<alazare619> i cant locate smartbootmanager for making a ubuntu respun iso from scratch any idea
<ScottK> robert_ancell: I see stuff in New that isn't ready for the archives for core-devs routinely.  Even from other archive admins.
<cjwatson> Legal won't ever go for the notion of accepting uploads without some kind of gateway anyway, so this isn't something that's going to be relaxed.
<ScottK> FWIW, if you think debian/copyright is pointless, you're probably one of the reasons a check is necessary.
<ScottK> Painful, I totally agree, but not pointless.
<cjwatson> Right.  And if you want to be corporate about it, we have customers that want us to do better with it, not worse.
<cjwatson> (You == Robert)
<ScottK> Yes.
 * cjwatson is slowly getting round to converting his packages to the new machine-readable format now that it's stabilised ...
 * RAOF would prefer a machine-writable format ;)
<ScottK> Yes.
 * ScottK is at the "patches will be considered" stage for that.
<lifeless> hell yes
<lifeless> I've been hugely put off by the copyright format stuff
<lifeless> I get the various arguments, but its still super tedious, and only valuable in the margin. (Which isn't the same as not valuable).
<RAOF> Sadly I suspect a general solution is probably quite close to strong AI. But a mostly working one would do well, too :).
<RAOF> lifeless: I actually find the format quite valuable; it makes it easier for me to check that I've done the copyright thoroughly.
<lifeless> sure, I can see that.
<ScottK> If the machines want to read it, let them write it.
<ScottK> I confess to being sloppy about patch header formatting too.
<cjwatson> Sadly I think if it were machine-writable there'd be no need for a machine-readable format.
<RAOF> Because then you'd just run the tool over the codebase, irght.
<robert_ancell> The biggest problem with debian/copyright is it is only checked when creating the package, and then the package changes constantly underneath it.  How many of the debian/copyright files are actually an accurate representation of what the source copyrights are?  By writing a detailed file that probably contains incorrect information, what risk are we entering if we are incorrectly stating the copyrights?
<robert_ancell> The only purpose from our point of view seems to be so we can check that we can legally distribute the software.  Anything more than that we should just say "consult the source/upstream"
<cjwatson> This was all gone into in the discussions about the machine-readable format.
<cjwatson> And no, that's *not* the only purpose, and as an uploader it's important that you understand this.  It's also important that our customers and users be able to do scans of licence compatibility without having to read hundreds of licences by hand.
<cjwatson> This is a genuinely valuable piece of distro integration work.
<cjwatson> Even if you don't care about it.
<robert_ancell> yes, but that's only useful if the information is accurate
<cjwatson> True of any distro integration.
<cjwatson> Copyright changes are frequent, but for this purpose they're not desperately important.  Licence changes are infrequent and generally people do keep d/copyright up to date with those.
<cjwatson> And if they miss it, it's only a bug report away once somebody notices.
<robert_ancell> cjwatson, btw, which customers/users do these license scans?  And for what purpose?
<cjwatson> This is a public channel; I'm not going to go into specifics.
<cjwatson> Generally it's for compliance with what their legal department demand as due diligence.
<robert_ancell> I mean "what types of customers/users", but I think you've answered that
<cjwatson> Very big ones, generally.
<cjwatson> At least IME from when they've asked Amanda questions and she's redirected to me.
<robert_ancell> we should make the "Copyright" header optional, as that seems the most problemtaic one
<cjwatson> Most widely-used licences require that redistributed copies of the software include copyright notices.
<cjwatson> So I'm not particularly wild about encouraging you to violate those licences.
<cjwatson> (Hm, actually, GPLv2 only requires that for source; GPLv3 likewise although it permits supplementation with terms that require preservation of legal notices in binaries.  BSD requires binary redistributions to reproduce copyright notices.)
<cjwatson> Anyway, I appreciate that it's tedious and that it's an engineer's instinct to automate it away or try to avoid it, but good engineering also involves knowing what the constraints are.
<cjwatson> The consequences of failing to keep Copyright up to date are probably relatively minor, but I do think it's worth at least making some effort.  Most of the rest is genuinely important in that failing to do our job there can easily result in either us inadvertently violating licences ourselves (because we assumed that our own licensing records were accurate) or in leading our users to do so.
<cjwatson> So please make an effort.
<mwhudson> (if this sounds like hard work, i have a flexlm install you might be interested in ...)
<micahg> infinity: is there a chance we can use gcc-4.4 as the fallback for new compiler issues instead of gcc-4.5 on arm*?
<micahg> that is assuming Debian is dropping 4.5 and not 4.4 imminently
<slangasek> SpamapS: circular> yes, but that's allowed and not new
<jbicha> robert_ancell: did you see that your manpages fix didn't work?
<robert_ancell> jbicha, no, is there a bug report?
<robert_ancell> oh, reading it now
<robert_ancell> jbicha, ok, take 2
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Good morning
<ion> that
<dholbach> good morning
<larsduesing> morning together
<larsduesing> hmm, is it ok to give users some advice which do not match the bug but I found while browsing apport-attachments?
<larsduesing> (like i did https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1017161/comments/2 )
<ubottu> Launchpad bug 1017161 in aiccu (Ubuntu) "package aiccu 20070115-14.1ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<xnox> I see that initramfs hooks copy udev rules from /lib/, and do not copy udev rules from /etc/ on top.
<ogra_> sounds like a bug
<xnox> is this intentional, or simply not supported to copy udev overrides into initramfs, and people should right their own initramfs hooks.
<ogra_> if i'm admin of a system i expect my overrides to also show up in the initrd
<xnox> surely there should be a helper function copy_udev_rule. Instead of each hook inventing their own way to copy the udev rule
<ogra_> dont they just all use copy_exec ?
<xnox> nevermind that there is wait_for_udev, and yet hooks are calling their own incarnation of udevadm settle
<ogra_> oh my
<cjwatson> That sounds unintentional.
<xnox> copy_exec is to copy the binary + dependencies, not the text files *.rule
<xnox> should I file a bug with found instances of this and open a task per package to fix these?
<xnox> I'm guessing that a helper which does {/lib|/etc}/udev/*.rules copy first in initramfs-tools would be better.
<xnox> unless there is one, checking.
<xnox> anybody knows about the history of /usr/share/initramfs-tools/event-driven/upstart-jobs/mountall.conf
<xnox> ?
<ogra_> well, looking at my default install there are only three hooks copying rules around
<ogra_> dmsetup, cryptopenct and udev itself
 * ogra_ wonders why we still have the compcache hook ... i guess that can go
<xnox> ogra_: dmraid, mdadm, lvm2, cryptsetup copy udev rules on my machine
<xnox> well that means add lvm2 to your list ;-)
<ogra_> ah, i dont have mdadm, cryptsetup or lvm installed
<xnox> some of them actually do sensible things
<xnox> http://paste.ubuntu.com/1058793/ copies combinations of "etc lib" && "97- 97_"
<xnox> mdadm, udev, kpartx, cryptopenct  copy only the /lib/ version.
<xnox> note that cryptoopenct copies only /etc/ one which doesn't exist.... maybe it's dynamically generated?
 * xnox wonders if smartcard decryption works or not.
<Laney> Does anyone have a trick to get sbuild to enter the chroot on ftbfs?
<xnox> Laney: use pbuilder-dist with recovery hook. My recovery hook installs less & zile (small emacs clone)
<Laney> yeah, I know how to do it with pbuilder
<Laney> but sbuild is better :P
<xnox> Laney: alternatively, I had some luck with LVM snapshots backed sbuild builds to leave the snapshot around on FTBFS
<tumbleweed> Laney: it's not that hard to type schroot -rc $PASTE
<xnox> then I'd mount the FTBFS snapshot & chroot into that
<tumbleweed> sbuild has an option to leave snapshots around after failures, no matter how they are backed
<Laney> tumbleweed: if it's left around on failure
 * xnox once ran out of snapshot space though.....
<Laney> that is the kind of information i'm after
<tumbleweed> $purge_build_directory = 'successful';
<tumbleweed> $purge_session = 'successful';
<Laney> ta
<tumbleweed> now you need to occasionally run schroot -e --all-sessions
<Laney> yeah, well I sometimes have to do that anyway
<Laney> my overlay isn't that big, so I notice pretty quickly
<Daviey> slangasek / bdmurray / SpamapS : Please can the nova SRU be progressed soon.. ta muchly.
<larsduesing> hmm, is it ok to give users some advice which do not match the bug but I found while browsing apport-attachments?
<larsduesing> (like i did https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1017161/comments/2 )
<ubottu> Launchpad bug 1017161 in aiccu (Ubuntu) "package aiccu 20070115-14.1ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<tumbleweed> larsduesing: don't see why not
<tumbleweed> lucky user
<larsduesing> ok... just asking :)
<Laney> tumbleweed: where is BUILDDIR?
<tumbleweed> Laney: context?
<Laney> re our previous conversation, when I schroot -rc into the chroot
<tumbleweed> Laney: ah /build/*
<Laney> I see "replacing <BUILDDIR> with /some/relative/path", but I don't know what it's relative to
<Laney> oh, it's not relative, I see
<Laney> ta
<cjwatson> cd /build/<tab><tab>
<xnox> submittodebian didn't work as expected - it didn't let me edit the body of the message to explain why it is needed, instead it emailed the bug with ugly #### comments in them =(
<tumbleweed> xnox: you don't use mutt?
<xnox> tumbleweed: I use emacs
<xnox> tumbleweed: I think the option 'printonly' kicked in on the screen and it didn't actually send it
<tumbleweed> reportbug should have made you edit it first
<xnox> I didn't have editor option set in the reportbug, but I had printonly set (maybe i was debugging something?!), that's why it did run editor, I think.
<xnox> let's try again
<tumbleweed> yup, that's probably why
<xnox> worked like a charm =)
<tumbleweed> so you need to have more trust in your tools :)
<infinity> micahg: My 4.5 workaround are VERY temporary, until the buildds have new kernels.  I don't expect nor want this to be long-lasting.
<doko> ev, cjwatson: did you say, that the gdb debug mode only works with python2, not python3?
<SpamapS> Daviey: I think today your best bet might be infinity
<SpamapS> infinity: are you doing SRU processing today? If so, Daviey is asking for a queue jump for nova.
<cjwatson> doko: I thought you said that and we just agreed
<cjohnston> jdstrand: ping
<jdstrand> cjohnston: hi
<cjwatson> Perhaps /usr/lib/debug/usr/bin/python3.2-dbg-gdb.py being a dangling symlink isn't helping
<cjohnston> jdstrand: I was asked to ping you on bug #1017462 to see your opinion
<ubottu> Launchpad bug 1017462 in python-django-openid-auth (Ubuntu) "Please remove python-django-openid-auth from the repos" [Wishlist,Triaged] https://launchpad.net/bugs/1017462
<cjwatson> doko: I think there's some confusion here between python3.2 and python3.2mu
<infinity> SpamapS: I may be, but it won't be until after I've woken up from a much-needed nap. :/
<xnox> bremner> xnox: btw, I think rlb will upload emacs24 soon, which should fix (sortof) your notmuch emacs-bug
<cjwatson> Though my naÃ¯ve attempts at fixing it locally haven't worked
<jdstrand> cjohnston: what specifically did you need my opinion on?
<jdstrand> (also if this is related to patch piloting, I had to rescedule my shift today)
<cjohnston> jdstrand: see if you can think of any issues with removing it.
<cjohnston> I don't think so
<jdstrand> cjohnston: I can't no-- there are no reverse depends. You might want to look at http://wiki.debian.org/Renaming_a_Package (since it is effectively a rename when considering both Debian and Ubuntu)
<Daviey> cjohnston: I raised this issue about a year ago.. but there were hesitations with removing it then.. I don't think those are still valid.
<cjohnston> Daviey: ok..
<csaba_pap> msg NickServ identify butch1117
<pitti> someone might want to change her password now
<chrisccoulson> oops ;)
<xnox> is a 1.42.4-3ubuntu2~12.04.1  sensible version number for a Precise SRU where quantal has 1.42.4-3ubuntu2 ?
<xnox> this is not a security upload
<jamespage> xnox: does the fix apply for quantal as well?
<xnox> jamespage: i am "backporting" micro point releases from quantal which fixed a lot of bugs
<jamespage> xnox, ah
<jamespage> I see
<xnox> jamespage: well not a lot, but a few grave bugs.
<xnox> jamespage: i thought this way I will not "steal" security version number 1.42.4-3ubuntu2.1 or like 1.42.4-3ubuntu2.12.04.1
<xnox> jamespage: or I can upload a no-change rebuild into quantal to give myself room in the number, but I think that way will be slightly more ugly =/
<xnox> jamespage: or I can upload a no-change rebuild into quantal to give myself room in the number, but I think the '~' way is less ugly =/
<jamespage> xnox: I agree
<jamespage> its more like what happens with backports which is what this is
<tumbleweed> xnox: you can also use a more SRUish version, and just say that it's a backport of version X in the changelog
<xnox> tumbleweed: I could use 1.42.4-3ubuntu0.12.04.1 hmmmm
<xnox> but that would be lies.
<tumbleweed> xnox: what's the package?
<xnox> tumbleweed: oh *just a minor thing* *cough* e2fsprogs
<tumbleweed> it's not really lies. We don't sync to older releases
<tumbleweed> even could do 1.42.4-0ubuntu0.1
<xnox> i'd rather have SRU version clearly show up-to which point the packaging goes as well though.
<xnox> well, SRU team will review the version number anyway =)
<xnox> ev: test driven development with C and cppUTest http://raphaelhertzog.com/2012/06/25/test-driven-development-with-cpputest-now-in-debian/
<xnox> FYI
<ev> xnox: this looks excellent from a cursory glance. Might play around with it tonight or tomorrow. Thanks!
<xnox> ev: =)
<cjwatson> mvo: Hey, do you have a minute to talk about the way DDTP uploads work?
<ScottK> barry: If you're tracking python3.3 compatibility, the python3.3 compatible version of PyQt is in Debian New ATM and we'll have it shortly.
<mvo> cjwatson: sure, in a call right now, after that, in ~15min?
<cjwatson> mvo: Sure
<barry> ScottK: \o/
<micahg> infinity: ok, let's hope that's really the case :)
<mvo> cjwatson: so lp:apt-ddtp-tools has all the stuff needed plus a file called "UbuntuChecklist" that hopeflly covers the bits and pieces needed, its mostly automatic, but only mostly :/ it was meant to become part of rosetta at some point
<mvo> cjwatson: now obviously the branch owner "~mvo" on various places is wrong, I need to replace that with ~ubuntu-core-dev I think
<xnox> English question: "an FBI agent" or "a FBI agent"
<tumbleweed> an
<tumbleweed> a/an is phonetic
<ScottK> Agreed.
<cjwatson> mvo: Right - I'd found that, but the thing I wanted to talk to you about was the mechanism it uses
<cjwatson> mvo: It appears to me that apt-ddtp-tools is doing a set of binary-only custom uploads
<cjwatson> mvo: Is my understanding correct?
<mvo> cjwatson: yes, that is true, a custom upload target that got implmented around 2005 I think
<cjwatson> The custom-ness is fine, but the fact that it doesn't have a source package is less fine
<cjwatson> This makes it *really* hard to fix bug 827941
<ubottu> Launchpad bug 827941 in Launchpad itself "Copy ddtp-translations uploads to new distroseries" [High,In progress] https://launchpad.net/bugs/827941
<mvo> cjwatson: let me look at this bug
<cjwatson> I have a patch for the Launchpad side of it
<cjwatson> But it relies on being able to track through a SourcePackagePublishingHistory
<cjwatson> And ddtp-tarball uploads are utterly anomalous because they don't have one
<mvo> cjwatson: I'm happy to change the way the uploads are done in any way necessary
<cjwatson> Do you think it'd be reasonable to rearrange apt-ddtp-tools so that it generated a source package which then produces these custom uploads?
<cjwatson> I'd be happy to put a patch together
<mvo> cjwatson: absolutely, that is fine
<mvo> cjwatson: while at it, I  cleanup the branch ownerships issues
<cjwatson> Cool.  I'm not certain off the top of my head whether a build that consists exclusively of custom files will work; but, if it doesn't, I'll fix that in LP
<cjwatson> This will fix bug 672314, with a bit of cleanup of old series
<ubottu> Launchpad bug 672314 in apt (Ubuntu) "No translated package descriptions for -updates repository" [High,In progress] https://launchpad.net/bugs/672314
<Daviey> cjwatson: Re-spin of alternate & server?
<Daviey> err, that was supposed to be in -release
<cjwatson> que?
<ximion> pitti: hi! Are you there?
<ximion> you contributed to the PackageKit apt backend, right?
<juliank> ximion: Fun fact is that I asked glatzor about the undefined variable bug 3 hours ago, but he did not answer me
<ubottu> Launchpad bug 3 in Launchpad itself "Custom information for each translation team" [Low,Fix released] https://launchpad.net/bugs/3
<juliank> bad bot!
<ximion> :-D
<ximion> cool!
<ximion> well, the apt backend is in Debian if people want to try it out / to offer this option
<juliank> I also asked him something on Saturday, but did not receive an answer either, so maybe he just ignores everything I write currently.
<ximion> but if the apt backend does not work and nobody maintains it, I would likely drop it, as it is for no use to anyone at that state (and reinclude it later in Wheezy+1, if it is updated)
<ximion> probably busy...
<juliank> But not busy enough to introduce RC-buggy code everywhere I look.
<ximion> but I'm not sure if the future of apt-backend is very save, since glatzor is the upstream author of aptd, so why should he work on making his own project obsolete? (if he thinks aptd is better, what he does at time (and he has a fair point regarding some issues atm))
<ximion> hehe, okay - then it's a bad time to be busy :P
<ximion> I'm very busy too (exams), but I still look at this stuff (fyi the aptcc security issue will be fixed, but I'm not 100% sure if I can do that before freeze - but I'll definitely get an exception for that :P)
<JohnC_> anybody here?
<ScottK> No.
<ximion> juliank: I'll do a packagekit upload tomorrow - if I haven't heard a decision yet, I'll drop the apt backend for Wheezy then, it's unlikely that it will be fixed before release.
<ximion> the issues are massive and won't be ack'ed by the release-team
<ximion> *I mean fixes for them would be huge and not accepted into testing
<ximion> would be cool if pitti could comment on his view on the PackageKit apt backend :-)
<xnox> I messed up a wiki page
<xnox> can a revision be reverted
<micahg> xnox: sure, there should be an edit option
 * xnox whooh, I think I managed to do it.
<xnox> micahg: If you go to: https://wiki.ubuntu.com/StableReleaseUpdates how many special cases subtitles do you see?
<micahg> xnox: 10
<xnox> micahg: good. The 'info' tab diff is weird =/
<skinpatch> hi all
<tedg> slangasek, So, presumably the liveCD is going to have to have a collection of bootloaders on it.  How do we know which one is actually being used?
<tedg> On an installed system, but I figure that will match the live CD.
<tedg> Or will only one be installed?
<Sp4rKy> a/W 25
<Anxi80> Is there an official method for passing suggestions on to the devs for future version of ubuntu?
<Pici> !brainstorm
<ubottu> Post your ideas for Ubuntu at http://brainstorm.ubuntu.com and vote for the ones you like!
<Anxi80> perfect thanks!
<ahasenack> hi, is there a way to force do-release-upgrade to upgrade lucid to precise? It keeps saying "No new release found", and
<ahasenack> if I change the config from "lts" to "normal" it tries to upgrade to maverick
<xnox> ahasenack: LTS -> LTS upgrades start after the first point one release, i.e. 12.04.1
<micahg> ahasenack: -d
<ahasenack> micahg: won't that upgrade it to quantal?
 * ahasenack tries
<micahg> ahasenack: not from lucid :)
<ahasenack> micahg: ah, nice :)
<xnox> ahasenack: or listen to my evil twin micahg ;-)
<ahasenack> micahg: it's working
<ahasenack> xnox: thanks too, good to know about the .1 detail
<slangasek> tedg: what precisely is it that you want to know?  which bootloader /was/ used for the current boot?  which bootloader /will be/ used for the next one?  the latter may depend on whether the user has enabled/disabled secureboot between reboots
<hallyn> slangasek: hi, the debian sysvinit maintainer was very helpful at first, but now has gone quiet.  When you get a chance, could you take another look at my new proposed fix for bug 974584 ?
<ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584
<hallyn> slangasek: if you wouldn't want to take that into ubuntu without it being accepted in debian, then i think i'll give up and keep working around it in lxc
<dupondje> Empathy broken since last update :(
<infinity> rbelem: Any news on the new plasma-mobile snapshot?
<xnox> infinity: if I type $ host localhost
<xnox> what do you expect as an output?
<xnox> $ host localhost
<xnox> localhost has address 127.0.0.1
<xnox> localhost has IPv6 address ::1
<xnox> But on my local machine I get
<stgraber> xnox: depends on your DNS server
<xnox> $ host localhost
<xnox> Host localhost not found: 3(NXDOMAIN)
<xnox> so my machine has borked DNS server?
<stgraber> well AFAIK nothing in the RFC forces the DNS servers to return a record for localhost
 * xnox is not good with networking but "Host localhost not found: 3(NXDOMAIN)" doesn't sound good
<stgraber> what should always return the right result though is "getent hosts localhost"
<cjwatson> You aren't really supposed to go to the DNS to look up localhost
<xnox> $ host ::1
<xnox> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa domain name pointer localhost.
<xnox> doesn't look good either
<stgraber> running "host" goes right to your DNS server without going through the nss stack
<xnox> hmm
<cjwatson> host(1) does an explicit DNS server query - it's not simply ... right, what StÃ©phane said
<stgraber> I usually make sure that none of my DNS servers ever returns something for localhost/localhost.localdomain/127.0.0.1/::1/... as they shouldn't
<xnox> and is there a magic switch to getent to get a IPv6 address?
<cjwatson> Though your output for ::1 is a straightforward IPv6 reverse record
<xnox> $ getent hosts localhost
<xnox> 127.0.0.1       localhost
<xnox> so where is my IPv6 address?
<cjwatson> Doing this for everything in shell is probably difficult, but you can use getaddrinfo/getnameinfo in C
<stgraber> not aware of a specific way of forcing getent to return an ipv6 record, I usually just use getaddrinfo()
<cjwatson> Or any language that binds those functions
<stgraber> xnox: depends on the systems but IIRC by default in Ubuntu "localhost" isn't an alias of ::1, ip6-localhost is
<xnox> Started IPv6 smoke perftest on broker port 34980
<xnox> Cannot resolve ::1:34980: Address family for hostname not supported (qpid/sys/posix/SocketAddress.cpp:140)
<xnox> qpid-send: Failed to connect (reconnect disabled)
<xnox> qpid-receive: Failed to connect (reconnect disabled)
<xnox> receive failed '' != 'hello'
<xnox> FAIL: ipv6_test
<xnox> stgraber: it is the case on debian?
<stgraber> xnox: no idea, I don't see why we'd diverge there though, so probably the same is true on Debian
<cjwatson> AFAIK yes
#ubuntu-devel 2012-06-26
 * xnox will drop out of network for a moment
<cjwatson> It'll depend on /etc/hosts though
<xnox> for all I know `$ host localhost` on precise returns both 127.0.0.1 and ::1, on quantal it returns 127.0.0.1 and Host localhost not found: 3(NXDOMAIN) twice
<xnox> $ lsmod | grep ipv6
<stgraber> xnox: is /etc/resolv.conf identical on both?
<stgraber> (suspecting that one might be a desktop machine with dnsmasq and not the other)
<xnox> true
<xnox> the latter statement. One is a server the other is a desktop
<stgraber> it wouldn't really surprise me that dnsmasq is returning that localhost record (manpage doesn't really help though)
<xnox> how would I get a "clean" network environment on my desktop? chroot / sbuild?
<stgraber> xnox: for that test, does it actually need to bind against localhost? couldn't it bind against :: that'd bind everything?
<xnox> hmmm... let me check the code
<xnox> stgraber: yeap it's a bash script and I can easily change ::1 to ::
<xnox> but the build will take a while, since I don't have unpurged one locally
<stgraber> the error message still looks odd, I'm not exactly sure of what it's trying to do, so I'm not even sure using :: would make any difference...
<stgraber> from that error, it seems to just rely on "::1" working which should always be true on a system with a loopback and ipv6 enabled, it doesn't seem to rely on localhost resolving to ::1
<xnox>         int n = ::getaddrinfo(node, service, &hints, &sa.addrInfo);
<xnox>         if (n != 0)
<xnox>             throw Exception(QPID_MSG("Cannot resolve " << sa.asString(false) << ": " << ::gai_strerror(n)));
<xnox> would you like print statements? =)
<xnox> Finished on 2012-06-09 (took 35 minutes, 28.7 seconds)
<xnox> it will be a while until my laptop gets to test results....
<xnox> cause 35min is on launchpad buildd
<stgraber> I guess I'll take a look tomorrow if you can't figure it out before I get to it. It's still technically a bank holiday here and I have some !work stuff on my todo ;)
<xnox> =))))))
<xnox> ;-)
<xnox> stgraber: how would you pass a  port and :: ?
<xnox> :::port is a valid ipv6 address...
<xnox> host ::1:34980 works, maybe that's why it's failing....
<xnox> as in it's an IP address...
<stgraber> xnox: it depends, some software use [::]:<port> for that
<xnox> hmm
<xnox> ok good night
<will> hey guys. where should i go if i want to talk about developing apps for ubuntu, specifically the ubuntu app competition going on
<pitti> Good morning
<pitti> stgraber, cjwatson, kees: argh, did we have a TB meeting last night? calendar fail, sorry
<RAOF> SpamapS: Would you mind uploading your juju 0.5+bzr531-0ubuntu1.2 to precise-proposed again, but with the last two changelog entries in the .changes file? That way I can accept it over the top of the existing version in proposed, and we can verify the 0.1 bug that requires the fix in 0.2 to verify.
<SpamapS> RAOF: I wasn't sure if the changes file needed a -v or not.. will do
<SpamapS> RAOF: done
<dholbach> good morning
<xnox> dholbach: good morning
<dholbach> hey xnox
<xnox> dholbach: you probably want to schedule me for patch piloting ;-) or does the 'first month free' rule apply?
<dholbach> haha
<dholbach> yes, good point - let me see where I squeeze you in :)
<ximion> pitti: ping
<pitti> hello ximion
<pitti> ximion: ah, couldn't respond this morning, you were offline
<ximion> pitti: hi! have you read what I wrote yesterday?
<ximion> ah, okay :-)
<pitti> ximion: so I have no strong opinion on the apt backend; I added the plugin support and some other fixes upstream, but as we currently use aptdaemon in ubuntu and you use aptcc for Debian it's probably not very well maintained
<pitti> so if you want to remove it, please go ahead (but it's the only one that works with all the ubuntu plugins)
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<ximion> yep, agreed - we already removed it upstream after ~5 months of inactivity, but then glatzor did many changes, so I included it again
<ximion> if the backend does not work, it's a bit useless, so removing it for Debian Wheezy is the best way to go, as I can't fix the issues mentioned in time, and if someone fixes them, there would be massive changes needed, where I'm not sure if ftpmasters will ack them
<ximion> pitti: which functionality is covered by Ubuntu plugins?
 * ximion thinks it's very bad that everyone is unable to reach glatzor at this important phase
<mvo> cjwatson: r79 of my apt-ddtp-tools has a proper source package now in the package/ subdir, let me know when/how we can test the upload (i.e. should this be uploaded to some staging first )
<ximion> mvo: can you upload the changes in GPK from the experimental branch to Debian experimental if you've time? :-P
<pitti> ximion: we already discussed this, the WHAT_PROVIDES plugins, language-selectors "add language support packages as virtual dependencies", and the software-center plugin (I don't know exactly what that does)
<pitti> the second and third are specific to aptdaemon, I think
<pitti> while WHAT_PROVIDES plugins are defined by packagekit, and also supported by aptdaemon
<ximion> yes - what-provides is also supported by aptcc, as it is a official requirement
<pitti> right, just not the python plugins; I figure we'd have to have an entirely separate implementation of these there
<ximion> the language stuff is tracked as bug 238634 as far as I know
<ubottu> Launchpad bug 238634 in packagekit (Ubuntu) "gimp (or any other gnome app) should pull in the respective language-pack-gnome-*" [Wishlist,Triaged] https://launchpad.net/bugs/238634
<pitti> it's not just language-pack-*, it's all language support packages
<pitti> fonts, dictionaries, spell checkers, and the like
<pitti> installing libo on a system with French and German support should install libo-help-{de,fr}
<ximion> we could add that to aptcc I guess, added to my TODO (but not in time for Debian)
<ximion> the software-center plugin is a little odd, mvo, do you know what it does?
<pitti> ximion: doesn't PK have a generic plugin support?
<pitti> ximion: it seems more appropriate to define this as plugins instead of adding distro specific package knowledge to the upstream code
<ximion> pitti: it has, and it's pretty powerful - but PK plugins aren't backend specific (although you could add apt-specific stuff to them)
<ximion> we use the plugins e.g. to generate a desktop-file-cache or to check for running applications, or for Listaller support...
<ximion> the plugins have just to be written in C at time, which doesn't seem to be liked by Ubuntu :P
<ximion> pitti: the backends can ontian whatever they want, and if the feature is apt-specific, we don't need to add stuff to the generic abstraction layer. But you're right, a generic "install everything for language X" makes sense, and I think we already have this
<pitti> ximion: it's "install all i18n support related to the package you just want to install", to be precise
<pitti> but yes
<pitti> so if the generic PK plugins support this kind of plugin, it could be written in C for PK in theory
<ximion> we have a LANGUAGE_SUPPORT what-provides type, which is supposed to return all l18n packages for pkgs currently installed on the system
<pitti> TBH it's not very likely that Ubuntu will do this as long as aptdaemon is the preferrred PK API implementation
<pitti> we likely won't maintain two plugins that do the same time, especially not if the PK plugin takes 10 times the effort and is not being used by default
<pitti> if we would switch to PK only, that'd be a different story, of course
<pitti> ximion: right; that's exactly what the language-selector plugin implements
<ximion> so we wouldn't even need a plugin - cool :-) (but I don't remember that language-support is implemented in aptcc... so that needs to be done)
<pitti> wouldn't a generic PK plugin make it available for all backends?
<ximion> pitti: well, it depends on how fast aptd can catch up with the changes PK makes. To be honest, I'm not a fan of the aptd approach, but as long as it is working I also don't see a need for switching
<ximion> pitti: yes
<ximion> that's the whole point of it :-)
<ximion> at time, it's already in the specs as recommendation to implement for backends. backends can implement it, but they don't need to: http://gitorious.org/packagekit/packagekit/blobs/master/docs/provides-component-naming.txt#line62
<mvo> ximion: it allows adding system-wide license keys
<ximion> mvo: does it add new DBus API for that?
<mvo> ximion: iirc it does, need to look at the code to be sure
* lindbohm.freenode.net changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ximion> pitti: we did massive changes on PK API during the last development period (to make PK ready for beeing used for a software-center, I'm working on a distro-sgnostic variant as part of a GSoC project), and as soon as these changes hit Ubuntu without adjustments on aptd, this will fail very bad...
<ximion> mvo: hmm... okay - then it might be not so trivial to implement it as 3rd-party PackageKit plugin, but it's still possible, I guess
<ximion> (if you can give hughsie (PK author) a good use-case, he'll also likely accept proposals for PK changes, if they don't violate some PK concept rules)
<mvo> ximion: it would be nice to have this, I know its not a huge use-case for most people, but some apps require that
<ximion> mvo: you mean the license-key-management?
<mvo> ximion: yes
<cjwatson> mvo: Ooh, I was going to do that this morning
<ximion> mvo: I can look into this and see what is required to add it - probably we really need to expose a new DBus API, don't know if hughsie would like that (but he might be willing to add it or allow plugins to register new DBus signals)
<cjwatson> mvo: The section needs to be "raw-ddtp-tarball", not "translated-package-descriptions", or LP will reject it
<cjwatson> mvo: And maybe "Section: admin" or something, since "Section: base" is dead and gone
 * cjwatson checks the section list
<cjwatson> Ah, "Section: localization" surely :)
<cjwatson> mvo: Other than that, could you upload this to dogfood?  Bonus points if you upload it to precise-proposed there so that I can use it for QA of that other change later on
<cjwatson> mvo: http://paste.ubuntu.com/1060404/ if you don't already have the .dput.cf fragment
<Chipzz> cjwatson: I read part of the discussion about debian/copyright yesterday, and I have to agree that I strongly dislike it
<Chipzz> the bottom line for me (and I am guessing a lot of other ppl who're opposed to it too) is that I am a technical person, not a librarian or secretary (I hope this doesn't come of as too derogatory)
<Chipzz> technical ppl want to focus on technical things, not a load of administrativae
<Chipzz> IMO it's a huge barrier to entry
<Chipzz> also, while I can see the value of having it for ubuntu's partners' sake, that argument doesn't hold for debian. And if I'm not mistaken, debian/copyright was introduced by debian, not ubuntu?
<dholbach> I must have missed the discussion - was there anything specific to dislike about writing debian/copyright?
<infinity> dholbach: No, just that people don't like doing it, apparently. :P
<dholbach> right
<infinity> Chipzz: I'm not sure the discussion is even worth entering into.  We're not going to suddenly drop debian/copyright.
<debfx> pitti: I think you want to test virtualbox-guest-dkms instead of virtualbox-dkms in ubuntu-drivers-common.
<dholbach> infinity, let's go shopping :)
<pitti> debfx: well, I guess we might want both
<infinity> dholbach: *blink*
<Chipzz> infinity: well I wasn't saying that ubuntu should do that, just giving my reason for disliking it
<Chipzz> in my personal opinion, even given the argument about ubuntu's partners, it's a pure waste of time. but that's my 2 cents
<infinity> Chipzz: Sure, I'm just pointing out that this is one of those cases where having an opinion (and expressing it) won't particularly matter.  It's almost up there with "Hey, I noticed an RPM versus dpkg discussion, and I'd like to chime in that I also don't like dpkg, so maybe Ubuntu should switch."
<seb128> dholbach, infinity, we should drop debian/copyright, and no, I'm not trolling ;-)
<infinity> Chipzz: I didn't follow the original discussion, but the partner-auditing thing, while nice, isn't the reason for debian/copyright at all.
<seb128> well at least the copyright owners part of it
<seb128> having license infos is useful
<infinity> Chipzz: The reason for it is because it's included in BINARY packages, which we distribute to users without source (and without the original license) attached.
<debfx> pitti: testing all dkms packages would be good but I'm not sure u-drivers-common is the right place since not all those modules are drivers.
<Chipzz> infinity: surely that doesn't require you to account for the copyright of every single file in the source package?
<infinity> seb128: I suspect the license portion is the one people with complex mish-mash packages complain about the most.  GNOME folks are lucky in their licensing consistency. ;)
<seb128> infinity, well, I can still see the value of that part
<infinity> Chipzz: It requires you to at least account for the copyright of everything that gets compiled into your binary bits, sure.
<seb128> infinity, where the copyright holders just doesn't make any sense
<infinity> seb128: I suspect an IP lawyer may disagree with you.
<seb128> infinity, well then we need to fix our packages and spend time updating those infos, I bet than 90% of packages have a totally useless and outdated copyright holders list
<infinity> Changing the format of a work (ie: source->binary, or, say, VHS->DVD) doesn't mean you get to drop the copyright notices.
<Chipzz> infinity: and while I'm aware that my opinion carries very little to no weight, expressing my opinion at least allows me to voice another -1 to the whole thing
<seb128> infinity, what we have is worth that what we would get by running a script that grep through the source and build a list on fly
<infinity> seb128: On, I know they get out of date.  That's no excuse for dropping them, it's reasoning for fixing them.
<seb128> infinity, it's not a matter of excuse, but we need to stop pretending those infos have any value, when most package made a list 10 years ago when they went through NEW that they never updated since
<seb128> infinity, we could as well compute a grepped list, it would be closer from really than the old static outdated one
<infinity> seb128: And, as Colin mentioned before, if debian/copyright were actually machine-writable, we'd be doing that.
<Daviey> Yeah, i don't think i have ever updated a debian/copyright post-NEW
<seb128> infinity, I was not there when that was discussed so sorry I'm out of context on that discussion ;-)
<infinity> seb128: If you happen to maintain something with really well-formed and uniform headers in every source file that allow you, specifically, to automagically generate copyright, do so, by all means.
<infinity> seb128: Not all of us are so lucky.
<seb128> infinity, I'm not, but any bad scripting would give a list as good as what the current static copyright files are
<Daviey> infinity: etherboot maintainers went to great effort to make upstream have a function to output the licence of each file!
<seb128> infinity, like having a list of who was copyright owner 10 years ago in version 0.1 of a software that changed 15 time upstreams since and saw 50 contributors is of no use
<infinity> seb128: I agree entirely.  So don't do that.
<seb128> infinity, reality is that most of our archive is maintained this way
<infinity> Maintaining debian/copyright is part of a maintainer's "job".  Like staying policy compliant, and other such things.  Saying "most people don't do it, so I don't wanna either" doesn't help.
<seb128> I guess there is an educational issue there
<infinity> Yeah, it's a crap part of the job, but hey, we all review upstream diffs anyway, right?  I notice when copyright headers get changed.
<seb128> nobody ever convinced me of the fact that updating that list is useful
<seb128> and it's the most boring job ever
<infinity> Yeah, it's not fun.  Or exciting.
<seb128> so I just don't see why I would ever want to spend time on that
<seb128> and I guess it's the same for lot of people
<infinity> I'm sure lots of people could say the same for keeping policy-compliant, or fixing FTBFS bugs introduced by toolchain changes, or, or.
<cjwatson> I do - not 100% reliably but I do update it
<cjwatson> I regard it as professionalism
<infinity> Not everything about software integration is fun to everyone.
<cjwatson> Exactly
<seb128> well, either it's important and we have an issue that most of our maintainer don't do it and we should try to fix that
<cjwatson> seb128: I really wish you would stop making rubbish unsupported "90%" assertions.
<seb128> or it's not important, and why bother people with paper work they don't want to be doing?
<cjwatson> Lots of people do update these files.  You're not 90%, nor is the desktop team. :-)
<infinity> On a lighter note, as I exit this conversation and head to bed, here's how I feel about "fun": http://25.media.tumblr.com/tumblr_m5sm5tDckY1r2yrpho1_500.jpg
<cjwatson> I don't have numbers and so I'm not quoting them.  Please do us the same courtesy.
<lifeless> infinity: *that*
<Chipzz> infinity: good night!
<seb128> cjwatson, ok, fair enough, it would be an interesting pool to do amount the ubuntu-dev set
<seb128> I would be interested in the result
<seb128> cjwatson, and I do believe the number will be way lower in Ubuntu than in Debian if we were going to do a pool in both sets
<cjwatson> If I had to make intuitive guesses, I would say that the likelihood is more that 90% of packages change so rarely that their debian/copyright files are entirely up to date and have been for years. :-)
<Chipzz> seb128: 10:45 < Chipzz> the bottom line for me (and I am guessing a lot of other ppl who're opposed to it too) is that I am a technical person, not a librarian or  secretary (I hope this doesn't come of as too derogatory)
<cjwatson> Chipzz: Do you upload packages to Ubuntu
<cjwatson> ?
<cjwatson> Or Debian?
<Chipzz> cjwatson: I don't. but if I ever were too, that woudl discourage me
<cjwatson> Then I'm sorry but I don't think you're in the relevant subset of people
<Chipzz> cjwatson: no offence taken
<seb128> cjwatson, let's say I don't think I've seen anyone doing copyright updates in the desktop set of Ubuntu in years (I can speak for this set since I watch uploads)
<tumbleweed> I don't see how one can safely run a linux distribution without carefully evaluating and documenting the license of every package, and that means keeping it up to date
<Chipzz> cjwatson: I've thought about quite a lot, never got off my ass and did anything about it
<cjwatson> seb128: I wonder why 'grep 2012 gnome*/copyright' produces non-zero hits then ;-)
<Chipzz> (which is also why I'm idling here)
<cjwatson> (in /usr/share/doc/)
<seb128> cjwatson, because the pkg-gnome in Debian do it, mbiebl especially
<Chipzz> cjwatson: I have, however, contributed some patches and fixes in the past
<seb128> cjwatson, and we sync regularly
<cjwatson> seb128: Great, we merge enough from them that that'll make it not too out of date then
<cjwatson> Most of the non-desktop teams do much less in the way of uploading new upstreams directly, maybe with the exception of stuff like openstack
<seb128> cjwatson, for those we merge yes, it doesn't change what I was saying, in our Ubuntu contributor set I don't think I've seen anyone doing an update of the copyright owner in years, so we have likely outdated files in that set ... i.e if that's an issue that needs to be sorted somebody should raise it
<seb128> cjwatson, I'm not sure how problematic having those infos outdated is...
<cjwatson> The BSD licence explicitly requires it
<cjwatson> I dunno, I kind of feel that managing to violate the BSD licence is a sign you're doing it wrong
<Chipzz> cjwatson: tbh the only thing that I have ever seen producing a licence is dhcpcd
<cjwatson> Displaying a licence interactively or whatever is a different matter
<cjwatson> (Obviously the BSD licence doesn't explicitly require debian/copyright, but it does require preserving copyright notices in binary distributions, and we don't normally include copyright notices anywhere other than the copyright file)
<seb128> cjwatson, I'm wondering how i.e fedora is dealing with that, they don't have any copyright info in their spec files
<cjwatson> Then maybe they're violating the BSD licence
<cjwatson> Or maybe they just ship extra docs in rpms or something
<directhex> they probably aren't dealing with it
<seb128> cjwatson, just being curious at this point if somebody has a way to semi-automatically generate them which could save us the manual work ;-)
<Chipzz> I suspect a lot of distro's are
<cjwatson> I don't care much about rpm packaging so I've never looked
<Laney> ask directhex about copyright auditing new packages
<cjwatson> seb128: There are certainly tools that have tried to do this kind of thing for licences (e.g. licensecheck, fossology); I've never looked at whether they do it for copyright notices too
 * Laney sniggers
<cjwatson> I generally feel it's easier to do it by hand than to add in some wobbly stack of auditing stuff
<directhex> my experience is that only debian cares about actually following the license requirements for things
<directhex> experiences with fedora and suse folks suggests they don't really bother
 * tumbleweed would find a tool that compared licencecheck output with a DEP-5 coprygiht file handy
 * tumbleweed should write one
<seb128> cjwatson, well, doing it by hand once is fine, having the discipline to keep doing those check every time you update a package to a new version start being boring work after a while
<directhex> Laney, i wonder if the java packagers ever lifted my openjdk dep5, from src:ikvm
<cjwatson> seb128: Sure, I don't argue that it isn't boring
<cjwatson> Many things are
<Laney> tumbleweed: /usr/lib/cdbs/licensecheck2dep5 | diff? ;-)
<seb128> cjwatson, well, every step which is not fun is something that could discourage contributors to join or stay so the less annoying work we have the better...
<cjwatson> Sure, but the answer isn't "hey, let's violate licences"
<cjwatson> "that'll be more fun"
<cjwatson> I'm all for automation
<Chipzz> cjwatson: I don't think anyone is getting any fun out violating licenses :P
<cjwatson> Chipzz: Then stop arguing that we should.
<seb128> cjwatson, how bad would be a "grep -i copyright * -r > COPYRIGHT" done during the build?
<cjwatson> seb128: It's not unheard of
<cjwatson> You might want to be a *little* more selective
<pitti> changing debian/copyright during build is certainly wrong
<cjwatson> Some way to get that into DEP-5 form would be good eventually, since there is some pressure to do that across the board eventually for mechanical analysis
<pitti> it coudl be a debian/rules update-copyright rule
<cjwatson> pitti: binary copyright files don't have to be identical to debian/copyright
<seb128> pitti, well, the license doesn't see that the copyright owner list needs to be in debian/copyright
<seb128> see->say
<cjwatson> The requirements are different - debian/copyright is shipped with the source package which already includes whatever copyright notices are present in the source package
<pitti> cjwatson: right, but it seems a lot less error prone to do it when updating the package and inspecting the result before committing it
<cjwatson> Binary copyright files are shipped with the binary package which generally doesn't
<cjwatson> I've certainly had cases where I generated the latter automatically
<pitti> right, no arguing about that; but it still seems more robust to do it at package update time
<cjwatson> It's workable too, yes
<infinity> SpamapS: Oh, while it's fresh in my mind, before I go to sleep and forget about it.  Your fixes for #986892 probably should be coordinated with the security team and targetted at -security, not -proposed.
<infinity> SpamapS: Because, otherwise, any security updates of MySQL (or other affected packages) won't build with the new apparmor/debhelper, and will suffer the same issue.
<TheMuso> Is anybody able to tell me with any certenty whether we are likely to only have python 3 on the desktop image for 12.10? The stuff I care about, orca, at-spi, speech-dispatcher is done, with liblouis and brltty still be done... Orca upstrea are enquiring since python 3 is not a GNOME goal this cycle.
<infinity> TheMuso: That's the plan, and we've made good progress.
<TheMuso> SO it comes down to how much extra work is required, and if the target is unlikely to be met, whether its worth pursuing as hard.
<TheMuso> infinity: Ok I'll take that as a yes at this point then.
<cjwatson> It's still challenging, but it's still the plan.
<cjwatson> I think we have a decent chance of making it.
<TheMuso> Ok thanks.
<pitti> TheMuso: didn't they say they would keep master at py3, and the 3.6 branch at py2? It should not be too hard to actually keep identical code there
<TheMuso> pitti: Yes, but joanie just wants a status update as to whether we are really still pushing this forward.
<pitti> "self-fulfilling prophecy" :)
<cjwatson> TheMuso: OK, and the simple answer there is yes.
<TheMuso> cjwatson: Figured as much, thanks.
<mvo> cjwatson: I generate the upload now, its going to take a little bit as its quite a bit of data
<cjwatson> mvo: Right, thanks.  Let me know when you've done it as dogfood doesn't process uploads automatically
<mvo> cjwatson: 20/200mb uploaded so far, I let you know when its done
<mvo> cjwatson: I should probably have just generate the upload for main instead of the combined one
<mvo> oh well
<cjwatson> Won't hurt to test the lot
 * mvo nods
<cjwatson> IIRC no other package includes multiple custom uploads
<cjwatson> Ought to work but good to check
<mvo> cjwatson: it will be perfect on the first upload anyway ;)
<mvo> cjwatson: yeah, I think you are right, its the only one and previously I just did the uploads individually too not combined
<cjwatson> Right - if you hadn't, they'd have been rejected
<cjwatson> The loophole that allows binary-only custom uploads only works for a single custom file
<cjwatson> (AFAICS)
<mvo> oh, interessting
<cjwatson> This is a bit of Soyuz I never knew was there
<cjwatson> Even having objective evidence that it worked it took me a while to find it
<cjwatson> (NascentUpload:process, the "Single Custom Upload detected" bit)
 * mvo nods
<cjwatson> I'd like to delete that once this new approach works, since I do think it's a dodgy loophole
<mvo> I haven't had any interaction with this part since the custom upload for the ddtp stuff was added in ~2005
<cjwatson> Yeah, bzr blame for it went way back
<cjwatson> Typical for Soyuz code of that vintage in that it was all mushed together with other work
 * cjwatson wonders how many tests will fail if I nuke that
<xnox> seb128: cjwatson: infinity: Chipzz: Fedora/OpenSUSE are very explicit on copyright and licenses. All spec files are copyright assigned. All spec files have License Tags (not necessary full copyright headers / per file). And in some ways I find OpenSUSE/Fedora archives to be more restrictive e.g. aircrack is banned. As pointed out by tumbleweed and Laney `licensecheck` tool does generate automated output and there is also  /usr/lib/cdbs/licensechec
<xnox> k2dep5 . I don't see DFSG or the http://www.ubuntu.com/project/about-ubuntu/licensing  changing any time soon
<seb128> xnox, the question was rather "is fedora providing the list of copyright owners of the source with their rpms, and how do they build that list"
<seb128> xnox, I don't see any manual listing done in their specs
<tumbleweed> licensecheck isn't very accurate, but still useful
<seb128> xnox, like we do in debian/copyright
<xnox> seb128: for fedora it's easier since RedHat owns the copyright for most things. And no they do not list copyright owners of the source with the rpms, last time I did RPM packaging (~2009 or something)
<seb128> xnox, ok, thanks for the infos ;-)
<xnox> np
<cjwatson> Fedora are more likely to ship upstream COPYING files and such than we are, though - Debian has a tradition of excluding things like COPYING because debian/copyright covers it
<cjwatson> e.g. http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/17/Fedora/i386/os/Packages/m/man-db-2.6.0.2-6.fc17.i686.rpm%5Bpeek%5D and compare with /usr/share/doc/man-db/
<cjwatson> Of course that doesn't help if upstream copyright notices are only in source files and not in upstream documentation
<xnox> seb128: I have been twice in legalish action due to copyrights: once it was settle outside the court, the other time my hosting got terminate due to receiving immediate notice for take down
<xnox> due to Ubuntu & Debian growing popularity, I can see how we are becoming more of a target for such actions from minor to large scale.
<xnox> cjwatson: true, generally fedora/suse install all docs of COPYING, LICENSE etc
<seb128> xnox, right, I guess the real way forward there is to make it easier to have those infos uptodate than to rely on people to do tedious manual work
<tumbleweed> that's pretty dependant on upstreams to give it to us in a useful form
<xnox> seb128: I'm sure /usr/lib/cdbs/licesecheck2dep5 is right up GNOME package-set street ;-)
<seb128> xnox, it might well be ;-)
<seb128> tumbleweed, grep -i copyright in the source get you a long way I think ;-)
<xnox> I do find that $VCS log/blame is 1000 times better than tarball drops
<xnox> back in the day it was more pain!
<tumbleweed> seb128: right, but still requires manual review
<tumbleweed> what about all the license lines below Copyright ...
<seb128> tumbleweed, well, having something to review is better than having something to build manually from scratch
 * tumbleweed just looks for copyright when reviewing new upstraem diffs
<tumbleweed> unfortunately, most upstreams care about this less than we do. so we end up doing the legwork
<mvo> cjwatson: ddtp-translation uploaded
<cjwatson> mvo: thanks, https://dogfood.launchpad.net/ubuntu/+source/ddtp-translations - should build any year now, dogfood being what it is
<dholbach> Riddell, hey - any objections to https://code.launchpad.net/~logan/ubuntu/quantal/cagibi/new-upstream/+merge/111411? it looked alright to me AFAICS
<dholbach> Riddell, also I just ran into https://code.launchpad.net/~scarneiro/ubuntu/quantal/adept/fix-invalid-brace.expansions/+merge/111331 and saw that adept was removed from Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673085) - should it be removed from Ubuntu as well?
<ubottu> Debian bug 673085 in ftp.debian.org "RM: adept -- RoQA; RC buggy, unmaintained, low popcon" [Normal,Open]
<dholbach> ScottK, ^ maybe you know something about the two questions above too
<cjwatson> We mirror removals across eventually, although that tends not to happen so much if the package is modified in Ubuntu
<cjwatson> Though that's not the case here
<cjwatson> Ah, but it has reverse-depends
<cjwatson> Admittedly just a recommends from mythtv-database and a depends from ichthux-desktop (which is forever out of date)
<dholbach> ok, I'll send an email to ubuntu-devel and CC the relevant people
<Riddell> dholbach: looking
<dholbach> thanks Riddell
<xnox> cjwatson: ichthux-desktop is dead, i'd remove it
<seb128> directhex, Laney: is there any way somebody could try to get the banshee SRU bugs verified?
<Riddell> dholbach: yep cagibi is good
 * xnox speaking as a provider with the core packages for ichthux-desktop, cjwatson 
<dholbach> Riddell, ok, will upload - thanks
<cjwatson> xnox: If you can speak authoritatively for it, perhaps you could file a removal request bug (against the package, subscribe ubuntu-archive)
<cjwatson> Then we have an audit trail
<Riddell> dholbach: yes indeed adept can go
<xnox> cjwatson: ok. I will CC' a couple of people from sword-devel who may be still in touch with them
<Riddell> (as far as kubuntu is concerned)
<dholbach> right-o
<cjwatson> mvo_: https://dogfood.launchpadlibrarian.net/103960082/buildlog_ubuntu-quantal-i386.ddtp-translations_20120626.1_BUILDING.txt.gz looks OK
<dholbach> I hate it when I get spam related to holidays - I always think I just won a trip to a far-flung island - what a disappointment
<Daviey> dholbach: mythtv is happy to drop it.
<seb128> dholbach, island trips are just overrated ;-)
<seb128> dholbach, you are happier around with us
<dholbach> seb128, I'm happy for you to stay in rainy miserable France :-P
<iulian> dholbach: Heh.
<dholbach> Daviey, do you think you could do an upload to remove the reference to it?
<dholbach> then it's just ichthux left
<mvo_> cjwatson: great, so time for a real upload?
<seb128> dholbach, heh, it's not raining today (yet)! ;-)
<cjwatson> mvo_: Well, let's check that it publishes first
<Daviey> dholbach: i'm doing that :)
<dholbach> Daviey, awesome
 * mvo_ nods
<xnox> dholbach: i'm working on removing ichthux form the archive ;-)
<cjwatson> mvo_: So yeah, that works fine on dogfood
<cjwatson> mvo_: Can you upload that to real quantal and start using it for all stable updates from here on, and I'll close the loophole you were using?
<mvo_> cjwatson: sure, uploading now
<cjwatson> Yay
<cjwatson> Now I will understand how translated package descriptions work
<caribou> I have a begineer's question about proposing a merge to an Ubuntu package : kexec-tools
<Laney> seb128: don't know. hyperair, can you do it or do you know who can?
<caribou> should I propose the merge on lp:ubuntu/kexec-tools or to the version specific lp:ubuntu/precise/kexec-tools ?
<xnox> caribou: for next development release propose to lp:ubuntu/$package
<hyperair> Laney: do what?
<xnox> caribou: for SRU fixes to the individual release lp:ubuntu/$series/package
<caribou> xnox: but if it is to fix a but in the current release ?
<xnox> caribou: current release in development is quantal. and bugs should be fixed there first.
<caribou> xnox: fine, that's what I understood. Then get the fix SRUEd to Precise
<xnox> caribou: yes, following the http://wiki.ubuntu.com/StableReleaseUpdates
<xnox> caribou: note the handy bug template for the SRU request
<caribou> xnox: yes, I've done that already. Still waiting for it to be done in Lucid after a few months...
<caribou> maybe I should talk to someone
<xnox> caribou: about?!
<xnox> caribou: what bug are you trying to fix?
<caribou> the other SRU was about a vm-builder fix that is in Precise and wanted in Lucid
<xnox> caribou: do you have a bug number for that one?
<caribou> xnox: https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/531599
<ubottu> Launchpad bug 531599 in vm-builder (Ubuntu Lucid) "device mappings for partitions not removed after build using --raw, leading to filesystem corruption" [Undecided,Fix committed]
<Laney> hyperair: verify the banshee sru(s)
<hyperair> banshee has an sru?
<hyperair> i thought raof acked that already because banshee's got the microrelease exception
<Laney> ?!?!?!?!?!?! https://launchpad.net/ubuntu/+source/banshee/2.4.1-3ubuntu1~precise1
<Laney> do you still have to verify it?
<hyperair> no?
<seb128> you for sure have if you want it moved to -updates and not kicked out
<cjwatson> MREs still require verification
<Laney> not sure how it works with the MRE
<cjwatson> it's on the wiki page for MREs
<seb128> the MRE just makes it a valid candidate for a SRU
<seb128> it doesn't mean you don't have to follow SRU rules ;-)
<cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<cjwatson> It's a relaxation, not a free pass
<hyperair> ah
<hyperair> i see.
<hyperair> hmmmm
<hyperair> so which bug would constitute as the headline bug?
<Laney> it's had several SRUs; I'm surprised this is surprising :P
<seb128> you need to verify all the bugs listed on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<seb128> the 3 of them
<seb128> it will not move to update until they are all verified
<hyperair> Laney: it's surprising because it was accepted without me doing anything the last time.
<seb128> it's likely the qa team or somebody verified the bugs for you last time
<seb128> that doesn't seem to happen this time though
<seb128> it's there for 2 weeks and none is flagged verified
<hyperair> right
<hyperair> the microrelease exception page says something about how bugs are considered to be fixed if their upstream bugs are fixed
<hyperair> can i assume so?
<pitti> there still needs to be some regression testing on the actual .debs
<pitti> upstream testing is required, but not sufficient for MREs
<pitti> there is build dependencies, tool chains, packaging helpers, and the packaging itself which can go wrong
<hyperair> okay.
<alkisg> There's probably a design issue about keyboard layout handling in accountsservice and lightdm, they assume that the "primary keyboard layout" is just one layout, while e.g. Greek requires both "us,gr" (and also the ability to switch between them with alt+shift).
<alkisg> I filed LP bug #1016409 about it and commented on LP bug #919200 (which is supposedly fixed, but not for Greek) - is there anything more I could do to help in solving the issue?
<ubottu> Launchpad bug 1016409 in lightdm (Ubuntu) "Default XKBLAYOUT is not used, so new users only have "en" layout" [Undecided,New] https://launchpad.net/bugs/1016409
<ubottu> Launchpad bug 919200 in lightdm (Ubuntu) "Doesn't know system default layout/variant" [High,Fix released] https://launchpad.net/bugs/919200
<seb128> alkisg, hey, out of sending a patch I'm not sure, it will require somebody who has time to look at it
<alkisg> seb128: as it needs redesigning and changing their API, I'm not sure I could send a proper patch without first talking about it with some of the devs there :-/
<seb128> alkisg, try talking to mterry when he gets online
<alkisg> Thank you seb128
<seb128> alkisg, he should be online soon
<seb128> yw
<alkisg> OK, I'll be online for hours, np
<mvo_> cjwatson: its in the real archive now, lets see how that goes
<cjwatson> Thanks, I'll look at it in NEW in a bt
<cjwatson> *bit
<ScottK> dholbach: Kill it.
<cyphermox_> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox_
<mio> Hi, when using subprocess.call to open a txt file in Linux, I am getting permission denied error. I don't want to use sudo in code, any other way?
<cjwatson> mio: it's unlikely to have anything to do with sudo; subprocess.call opens executables, not documents
<cjwatson> mio: Perhaps try subprocess.call(["xdg-open", "whatever.txt"])
<mio> right thanks, xdg-open worked :)
<jibel> pitti, I published latest rev of auto package testing and refreshed the base vm. ubuntu-drivers-common is running with multiverse enabled.
<pitti> jibel: merci beaucoup
<xnox> dholbach: ichthux upsteam and all users contacted (exactly 3 people). Nobody is aware that it (a) exists (b) used by anyone
<xnox> sent emails to devel mailing lists and stuff
<xnox> so after a grace period ~ 1 week we can remove it from the archive
<dholbach> xnox, so shall we for now just remove it from the depends and let the ichthux team deal with any other necessary cleanup?
<xnox> dholbach: well, yeah I can do that now to unblock. But yeah the whole ichthux is going so there is no harm in leaving it in un-installable state
<xnox> dholbach: there was literarly no activity since 2009 on that 'respin'
<dholbach> ok, I'm happy either way
<dholbach> Michael Hall is giving a session at Ubuntu App Developer Week at 16:00 UTC (#ubuntu-classroom) to cover some (non-Quickly) packaging tools - would anyone be available to be around and help out with some questions which might come in?
<smoser> anyone running quantal want to try to crash their browser? https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1017761
<ubottu> Launchpad bug 1017761 in firefox (Ubuntu) "firefox page load makes X consume all cpu, firefox OOMS" [Undecided,New]
<smoser> i'd like to see if that is "just me"
<xnox> I googled for "germinate seeds" and the youtube results were utterly unhelpful for changing ubuntu seeds!
<dholbach> jelmer, are you OK with https://code.launchpad.net/~logan/ubuntu/quantal/bzr-builder/0.7.3/+merge/109506 going into quantal?
<Daviey> xnox: I assume you have read https://wiki.ubuntu.com/SeedManagement ?
<xnox> Daviey: yeah, yeah I did =) I just wanted the bzr branch =) as I don't have it checkout handy
<jibel> smoser, it works here with FF 14.0~b9+build1-0ubuntu1
<jelmer> dholbach: hi Daniel, let me have a look
<dholbach> jelmer, it looked OK to me - I just wanted to make sure you didn't have any other plans
<jelmer> dholbach: it seems okay to me too
<dholbach> great
<jelmer> dholbach: thanks for sponsoring that upload :)
<dholbach> de nada :)
<smoser> jibel, thanks. i wonder which of my addons is making it go crazy
<dholbach> @pilot out
 * dholbach hugs cyphermox_
<cyphermox_> dholbach: hey
<dholbach> :)
<cyphermox_> re: handoff ;)
<cyphermox_> https://code.launchpad.net/~cr3/ubuntu/quantal/checkbox/0.14/+merge/111701; set to Merged?
<cr3_> dholbach: thanks for merging checkbox, all converted to python3!
<cyphermox_> cr3 was confused by bugs being closed but the branch not merged; I told him about the importer ;)
<cr3_> barry: ^^^
 * cr3_ is easily confused
<dholbach> cr3_, yeah, it looks like quite a bit of work :)
<cyphermox_> bah
<cr3_> dholbach: yeah, hardware testing needs to read a lot of byte information which is now a big deal with python :)
<barry> cr3_: looking for a review?
<cr3_> barry: nope, just letting you know that checkbox was converted to python3. one more package to cross off your list :)
<barry> cr3_: has the new version been merged/uploaded?
<cr3_> barry: yep, thanks to dholbach
<barry> cr3_, dholbach: you guys *rock*.  thanks!
<cr3_> barry: I believe there's still a dependency on python-apport and python-apt, not sure why though
<barry> cr3_: both of those are already ported, i.e. python3-{apt,apport}
 * barry loves seeing rows go green
<cr3_> barry: might there be a ppa with python3-apport for precise?
<barry> cr3_: ah, for precise.  not that i know of :(
<barry> cr3_: it might make sense to try to create one though.  i don't want to spend a ton of time working on backports, but let me see if it's easy
<cjwatson> IMO you can't realistically do Python 3-directed development against precise.  Make your code bilingual so that you can keep it working with Python 2 in precise and Python 3 in quantal.
<cjwatson> (I mean you can in some cases, but when you run into missing ports the right answer is to switch to quantal rather than spending lots of time backporting stuff)
<barry> cjwatson: your py3 command-not-found branch is merged right?  but looks like it wasn't uploaded yet.  do you know what the status is of that?
<smoser> jibel, thanks for testing. i just tested and i die an immediate, horrible death.
<stark> Hi, I am writing my first Ubuntu app and these two bugs are getting in my way --> Bug #390508, Bug #663726 Please please fix them I want to submit app to showdown
<ubottu> Launchpad bug 390508 in notify-osd (Ubuntu) "notifyOSD ignores the expire timeout parameter" [Wishlist,Confirmed] https://launchpad.net/bugs/390508
<ubottu> Launchpad bug 663726 in notify-python (Ubuntu) "pynotify.set_timeout() ignores timeout" [Undecided,Confirmed] https://launchpad.net/bugs/663726
<cjwatson> barry: Yes - I thought mvo said he was going to upload it
<jibel> smoser, does it crash in safe-mode ?
<cjwatson> mvo_: ^-
<stark> is there any workaround to override default timeout in notify-send?
<seb128> stark, no, and it's not a bug
<seb128> stark, notifications have been designed to be consistent
<cr3_> barry: might you happen to know how to tell setup() to install some files under /usr/lib*? I have some compiled scripts currently installed under /usr/share, using setup(data=...), whereas those scripts should actually be under /usr/lib*
<mvo_> barry: feel free to upload, I had hoped that we can get a updated command-not-found-data package too, but that seems to be a problem as the replacement of rooerky is not fully ready yet, i.e. I don't have a ~mvo there yet to store the results, so the current automation will not work
<smoser> jibel, seems not to.
<xnox> cjwatson: do you have a stash of bzr branch ichthux seed from the updates you have been doing? or can I somehow rerun it from the tarball
<barry> mvo_: okay.  obviously i can't upload to debian yet, but will do ubuntu asap
<cjwatson> xnox: No, that isn't one of the centrally managed seeds
<xnox> cjwatson: well the old branch still works for checkout but it doesn't have your changes, ok. Am I ok to just sed through the changes? =/
<barry> cr3_: well, it's probably not correct to do that in setup.py because that's not cross-platform.  (the new py3.3 packaging will allow us to do stuff like this, but that doesn't help you now, and some of that may actually not land in 3.3)
<cjwatson> xnox: Uh, that's not possible
<stark> seb128: I am writing a desktop recorder and I want a notification that displays user specified delay in seconds before the recording starts. The default timeout is around 5-6 seconds and if user specifies 0 seconds, the notification will be still displayed for 6 seconds :( And it will get recorded in video
<xnox> cjwatson: ok. sorry.
<cjwatson> xnox: I didn't make any seed changes; all I did was rebuild against the current archive
<cjwatson> Using https://code.launchpad.net/~ichthux-dev/ichthux-seeds/ichthux.lucid
<cjwatson> Though it's clearly broken that there are no newer seeds - that was a hack
<xnox> hmm... ok. but they explicetely add adept which is going
<xnox> away.
<cjwatson> Ideally, get somebody to branch the seeds for quantal and then remove it
<cr3_> barry: hm, so should I have a Makefile that would call setup.py, and then have debian/rules use that Makefile?
<seb128> stark, check with mpt (he's a designer and worked on notify-osd) but I guess you should probably have that count somewhere in your software ui and not use the system notifications then
<cjwatson> Failing that, you could edit the output files manually before upload, as long as we remove the package shortly after that
<barry> cr3_: hang on.  lots of conversations going on at once ;)
<cr3_> barry: no worries :)
<mpt> stark, org.freedesktop.notifications is not a good way of doing a countdown -- not least because you can't update it each second. I suggest doing a custom overlay for that. The Kazam developers are working on something similar, so maybe you could share code.
<stark> mpt: Not doing a countdown, just alerting the user. Anyway will check out Kazam, thanks
<dholbach> SpamapS, do you know who could have a look at https://code.launchpad.net/~n-muench/ubuntu/quantal/open-vm-tools/open-vm-tools.may-merge.final2/+merge/111497 and https://code.launchpad.net/~n-muench/ubuntu/quantal/open-vm-tools/open-vm-tools.may-merge.final/+merge/111310?
<tumbleweed> dholbach: whoops, that should have been on my todo list
 * tumbleweed reviewed the first couple of rounds
<dholbach> tumbleweed, cool
<bdmurray> pitti: I forget during Precise was there an issue with the mapping between binary and source packages in apport?
<pitti> bdmurray: bug 993810 ?
<ubottu> Launchpad bug 993810 in apport (Ubuntu Precise) "apport-collect broken (with source pkg name != binary pkg name?)" [Undecided,Fix committed] https://launchpad.net/bugs/993810
<SpamapS> dholbach: looking
<dholbach> SpamapS, it seems like tumbleweed also wanted to have a look
<SpamapS> ahh
<dholbach> whoever gets to it first :)
 * SpamapS defers looking for a few minutes
<tumbleweed> won't be me right now
<dholbach> SpamapS, tumbleweed: I received https://twitter.com/NMinker/status/216957211002404865
<SpamapS> infinity: also re apparmor fixes in proposed.. I am wondering, should we do no-change rebuilds on all of apparmor's reverse-build-deps so that all of the postrm's are correct, just in case the apparmor profiles change hands sometime between 12.04 and 14.04?
<tumbleweed> dholbach: hrm, last I saw of it was https://code.launchpad.net/~n-muench/ubuntu/quantal/open-vm-tools/open-vm-tools.may-merge3b/+merge/109264 and that appears to have been deleted
<tumbleweed> I commented on it saying "offline for a week, someone else review, please"
<SpamapS> dholbach: I'm not sure what the problem is. We're behind in sponsoring, definitely, but I don't understand at all what it is we can do differently
<tumbleweed> he does seem to like creating new branches after each review comment...
<dholbach> SpamapS, don't take it personally - I can understand the submitter though: if I have to wait days or weeks for some feedback for work I did, it's obviously not ideal
<dholbach> but we need more hands on deck in terms of sponsoring
<dholbach> today I did my piloting shift and I easily ticked off ~20 sponsoring items which were trivial and anybody could have taken care of them beforehand
<bdmurray> pitti: no, I was wondering about the +filebug link creation
<tumbleweed> his creating a new branch every time he fixes something will keep him fairly far down the lits
<dholbach> tumbleweed, it might also be a misunderstanding
<dholbach> but yeah, it might have a "*bump* anyone out there?" effect as well :)
<dholbach> ...depending on where you start looking in the queue
<SpamapS> What I'm confused about is that I *think* he has gotten the package in sync.. or at least, one of the messages claims as much
 * SpamapS debdiffs w/ debian version
<tumbleweed> I think he's having a fairly hard time with preparing a merge proposal in bzr
<tumbleweed> the second attempt had the inter-ubuntu-version delta described in the changelog. I had to point out each debian-ubuntu delta to get it mentioned
 * tumbleweed is glad to see a 3rd-party application at the top of https://errors.ubuntu.com/ :)
<pitti> bdmurray: hm, I'm not aware of a bug there
 * Laney eyes 1:0.156.14.5+elementary2~precise1+elementary2~precise1+elementary2~precise1
<hyperair> whoa.
<hyperair> that sounds like a runaway script
<Laney> makes me want to runaway :-)
<bdmurray> pitti: okay, thanks
<micahg> dholbach: you sponsored some stuff that shouldn't have been during alpha 2 freeze :)
<dholbach> ugh, I hope I didn't break anything :)
<micahg> infinity: SpamapS: re mysql fixes, anything in -updates would be included in the next security update
<micahg> infinity: SpamapS:  it should only go to -security now if it's a regression in a previous security update
<SpamapS> micahg: I think infinity was commenting on the fact that we need to make sure my apparmor fix lands in -updates before your next mysql security update.
<SpamapS> but I could be wrong
<micahg> ok
<xnox> psusi: why did you set bug 1012946 'in progress'? are you working on resolving it  / providing an updated patch?
<ubottu> Launchpad bug 1012946 in parted (Ubuntu Quantal) "dm-part-sync.patch breaks creating multiple partitions on a LVM volume" [High,In progress] https://launchpad.net/bugs/1012946
<dupondje> eclipse is uninstallable ? :s
* ChanServ changed the topic of #ubuntu-devel to: Quantal A2 prep | Archive: please use -proposed | 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: cyphermox_
<infinity> SpamapS, micahg: No, I was referring to the fact that fixing debhelper/apparmor in -updates does no good if you then do a MySQL security update.
<infinity> SpamapS, micahg: Since -security doesn't build against -updates, and you're relying on your build-deps to make MySQL happy.
<SpamapS> infinity: oh!
<SpamapS> I didn't not know that the builds were not done w/ updates
<SpamapS> ok, so yeah we need to copy that to security, right?
<infinity> SpamapS: Yes, but you need security sign-off before we do, we don't just copy SRUs to security willy-nilly.
<SpamapS> I figured as much
<dupondje> meh, eclipse is ftbfs :(
<psusi> xnox: branches linked and merge requested already
<xnox> psusi: awesome!
<xnox> psusi: I will review it tomorrow hopefully. got to go now
<dobey> anyone can think of a reason why dpkg-buildpackage would not be applying patches in a 3.0 (quilt) package?
<micahg> infinity: oh, I thought the fix was in the mysql package
<psusi> dobey: are you sure it is actually in 3.0 (quilt) format, and not 1.0 with quilt?
<infinity> dobey: Is it using --single-debian-patch?
<micahg> SpamapS: yeah, infinity is right, please coordinate with mdeslaur
<dobey> psusi: yes. i just checked source/format to confirm even.
<dobey> infinity: i'm not passing that argument anywhere
<infinity> dobey: Which package?
<dobey> infinity: and it's my package, so also weird. dirspec
<infinity> dobey: Patch is in patches/series?
<dobey> realised the one i just uploaded to quantal-proposed is ftbfs due to new pep8 warning about more stuff, and made a patch, but it's not getting applied
<dobey> it is, yes
<infinity> dobey: Also, when you 'dpkg-buildpackage', you don't mean you expect it to be applied on build, right?
<infinity> dobey: It's applied when unpacking with dpkg-source.
<dobey> infinity: surely it has to be applied when built
<dobey> infinity: i stuck a patch in, did bzr bd, then building it in a quantal chroot
<dobey> and no patch
<mdeslaur> infinity, SpamapS: what's the issue? we need to rebuild the apparmor package in -security?
<dobey> i've done this a hundred times and it's worked fine before. so it not working now makes no sense
<infinity> dobey: If you dpkg-buildpackage -S, and then dpkg-source -x the resulting .dsc, does it get applied?
<infinity> mdeslaur: dh_apparmor needs to be updated (so, apparmor in one series, dehelper in another, AFAIK) so future MySQL builds don't have issues.
<dobey> infinity: yes
<infinity> mdeslaur: (And potentially other things, I don't know if anyone's looked at the impact yet)
<mdeslaur> infinity: do you have a bug #?
<infinity> mdeslaur: http://pad.lv/986892
<ubottu> Launchpad bug 986892 in debhelper (Ubuntu Oneiric) "mysql-server postrm breaks apparmor profile for later versions on purge" [High,In progress]
<infinity> dobey: Then it seems to be working as designed.
<dobey> infinity: wonder why it isn't getting applied when doing pbuilder-quantal blah.dsc then
<infinity> dobey: Erm, if the .dsc is the result of the above dpkg-buildpackage -S, it certainly should be.
<micahg> dobey: did you bzr add the file?
<infinity> Not that I use pbuilder, but I assume it just does a dpkg-source -x like anything else.
<dobey> huh
<dobey> micahg: yes
<dobey> ok wtf
<dobey> infinity: actually, in the pbuilder dpkg-source does say it's getting applied. but the thing it fixes is still failing. which is weird
<alkisg> mterry: hi there, would you have time to talk about AccountsService/LightDM wrt keyboard layouts? I think there's a design issue there resulting in LP bug #1016409 and LP bug #919200 (basically keyboard layout is now broken for Greeks unless they manually add them from gnome-control-center, but even then layout switching doesn't work in lightdm). X defaults are not respected in any case.
<ubottu> Launchpad bug 1016409 in lightdm (Ubuntu) "Default XKBLAYOUT is not used, so new users only have "en" layout" [Undecided,New] https://launchpad.net/bugs/1016409
<ubottu> Launchpad bug 919200 in lightdm (Ubuntu) "Doesn't know system default layout/variant" [High,Fix released] https://launchpad.net/bugs/919200
<mdeslaur> SpamapS, infinity: ok, so when I do the next mysql security updates, I'll also update the dh_apparmor stuff at the same time
<dobey> and it certainly fixes it, otherwise the branch i pulled the patch from, wouldn't have landed in our upstream trunk, which is running the exact same tests on quantal
<barry> mvo_, cjwatson you've done releases from lp:~ubuntu-core-dev/command-not-found/ubuntu before.  what's the best way to merge lp:command-not-found into the former for release?  or do you do it some other way?  (i want to use the same procedure you've used before)
<dobey> anyone know if the 3.4 (or 3.5) kernel is getting backported to 12.04 anytime soon? i thought i understood it would be from UDS
<micahg> dobey: I thought that happened after release
<dobey> after quantal final release you mean?
<micahg> yes
<dobey> maybe i should just upgrade to quantal on this machine then
<infinity> dobey: Yeah, only released kernels are backported.  But you can install quantal's kernel on precise without any backporting.
<dobey> also. is there a way to make pbuilder-dist NOT destroy the chroot directory when it fails?
<micahg> dobey: --preserve-buildplace ?
<dobey> micahg: apparently not. it doesn't unpack the chroot into a new PID directory underneath the build dir, but tries to use the build dir itself if i do that, and fails to create files because there's no directory structure
<dobey> :-/
<micahg> yeah, man page clarifies what it really does :(
<mvo_> barry: I would suggest using the ~ubuntu-core-dev/command-not-found/ubuntu branch and just run bzr-buildpackage from there
<dobey> what the heck is goin on.
<barry> mvo_: except that i don't think that branch has cjwatson's py3 support
<mvo_> barry: meh, ok, let me actually look at the situation
<barry> mvo_: sorry ;)
<mvo_> barry: haha, no I need to appologize for making suggestions without really investigating
<dobey> if i do "bzr bd" the dpkg-source during that build doesn't say it's applying the patch. if i do "bzr bd -S -- -sa" it also mentions nothing about the patch, but if i "dpkg-source -x" on the resulting .dsc, it clearly says it applies the patch (and it does, by looking at the resulting directory)
<barry> dobey: maybe add DH_VERBOSE=1 to d/rules?
<dobey> barry: doesn't seem to tell me anything extra/new
<dobey> the patch is clearly not getting applied during dh_clean
<infinity> dobey: The patch isn't applied during clean, or during build at all.
<infinity> dobey: Only during unpack.
<infinity> dobey: That's how v3-quilt packages work.
<dobey> dpkg-source happens during dh_clean; i don't see any dpkg-source before that in the log
<infinity> dobey: Uh, what?
<mvo_> barry: all ready now, if you don't mind I upload in a bit
<cjwatson> barry: I've not done an upstream merge of c-n-f before, which is one of the reasons I haven't done so this time :-)
<infinity> dobey: You're suffering layering issues here.
<dobey> oh now i see the one before and it says it's applying the patch
<infinity> dobey: dpkg-source unpackage source.  dh_clean runs from debian/rules.
<infinity> dobey: Clearly, B can't happen before A. :P
<dobey> infinity: i'm suffering from something driving me freakin insane
<cjwatson> infinity: while you're right, I think buildpackage is *also* meant to ensure that patches are applied
<barry> mvo_: go for it :)  cjwatson yeah ;)
<mvo_> cjwatson: all taken care of now, the upstream branch diverged a bit, but I think its all good now (fingers crossed)
<cjwatson> mvo_: great, thanks
<mvo_> barry, cjwatson: should be a matter of bzr merge lp:command-not-found in the future from now on
<mvo_> (for the upstream merge)
<barry> mvo_: perfect, that's what i would have thought, but the conflicts made me nervous :)
<infinity> cjwatson: I'm not sure I've ever noticed this behaviour, but it could be because I always follow the hack->sourcepkg->build workflow.
<cjwatson> yeah
<mvo_> barry: yep
<barry> mvo_: thanks.  i can't wait to turn another row green!
<mvo_> barry: https://launchpad.net/ubuntu/+source/command-not-found/0.3ubuntu1 :)
<mvo_> and ftbfs! joy!
<barry> mvo_: good enough for me!  thanks
 * mvo_ fixes
<barry> urg ;)
<mvo_> just b-d updates it seems like python-apt -> python3-apt etc
<barry> mvo_: yeah.  probably also python3-distutils-extra
<mvo_> yes
 * barry returns to the pain-inducing xapian port
<mvo_> barry: \o/
<mvo_> barry: is the concensus from upstream now *how* to approach it? last I checked there was a bit of uncertainty, no?
<barry> mvo_: still is unfortunately.
<mvo_> :/
<dobey> how can i upload stuff to people.ubuntu.com?
<cyphermox> dobey: use sftp
<dobey> i just get "connection closed by remote host"
<cyphermox> dobey: you also need to put the files under pu
<cyphermox> *public_html if you want them to be accessible
<dobey> yeah, the obvious bits are obvious, but i can't establish a connection
<cyphermox> ok
<cyphermox> it's reachable without issues from here
<dobey> hrmm
<dobey> ssh_exchange_identification: Connection closed by remote host
<dobey> that's all i can get
<dobey> anyway
<dobey> infinity: can you tell me if i'm totally crazy or not then? http://people.gnome.org/~dobey/dirspec/
<infinity> dobey: I can tell you that without looking.
<infinity> dobey: (But yeah, let me poke.
<infinity> )
<dobey> heh
<infinity> dobey: 403.
<Laney> dobey: sftp -vvv people.ubuntu.com â look for suspicious output?
<dobey> infinity: fixed
<dobey> Laney: it just loads the certs locally, spins a few seconds, then fails with the connection closed; i guess maybe my ssh key isn't on there
<infinity> dobey: Patch gets applied, package still fails to build.
<infinity> HAHAHA.
<dobey> what?
<infinity> dobey: Uhm.  So, your "pep8 --repeat . setup.py" invocation is leading to it checking the cached unpatched copy in .pc/
<dobey> wtf
<dobey> sigh
<dobey> oh of course
<dobey> crap
<infinity> http://lucifer.0c3.net/~adconrad/dirspec_3.99.1-0ubuntu2-amd64-20120626-1243
<dobey> yeah i see that now
<dobey> :(
<kees> hello MIR folks ... can someone approve this? I'd like to get XPS support into evince. https://bugs.launchpad.net/ubuntu/+source/libgxps/+bug/965467
<dobey> infinity: thanks. grmbl srcdr == builddir builds.
<ubottu> Launchpad bug 965467 in libgxps (Ubuntu) "[MIR] Please transfer libgxps 0.2.2-1 (universe) to main" [Undecided,Confirmed]
<kees> now I wish I didn't step down from the MIR team. ;)
<dobey> that reminds me of a couple MIRs i need to do
<infinity> dobey: pep8 take an --exclude=
<infinity> dobey: Adding --exclude=.pc should do.  (testing now)
<dobey> yeah
<dobey> i already made a patch to do that also
<infinity> dobey: Yeah, that worked for me.
<dobey> and uploaded, finally. thanks again
<hallyn> stgraber: hm, i can't tell if i have a bug in my code, or if i'm just having kernel bugs (on ec2)
<stgraber> hallyn: doing what?
<mvo_> barry: eh, so: dh $@ --with=python3 calls "dh_auto_clean: python setup.py clean -a returned exit code 1
<mvo_> " that does not looks quite right if I want a pure py3 package does it?
<mvo_> barry: what am I missing :) ?
<hallyn> stgraber: seems just starting containers
<barry> mvo_: you need dh_clean_override and not up-call to dh_clean :)
<mvo_> barry: *cough*
<mvo_> really?
<barry> mvo_: yep
<barry> http://wiki.debian.org/Python/LibraryStyleGuide
<barry> http://wiki.debian.org/Python/AppStyleGuide
<barry> mvo_: dh does not know how to handle python3 yet :(
<barry> and `dh $@ --with python3` is *not* enough to make it work
<hallyn> stgraber: http://paste.ubuntu.com/1061318/  doesn't look good, but that doesn't 'mean it's not my fault :)
<dobey> barry: is fixing that one of the goals for 12.10?
<barry> mvo_: the up-calls in those examples only work if you are providing both a py2 and py3 version.  remove the up-calls if it's py3 only
<infinity> barry: Maybe that should be fixed, instead of entrenching awful overrides all over?
<barry> dobey: no.  debian has a gsoc project working on python multibuild, but honestly i don't know what the status is.  being a gsoc project, i don't have high hopes ;).  it's something we should get involved in, but probably no time for 12.10
<hallyn> smb: ^
<hallyn> smb: is http://paste.ubuntu.com/1061318/ something known?
<barry> infinity: agreed, but see ^^ for the sad state of current affairs
<stgraber> hallyn: fun ;) I don't think I tried lxc on 3.5 yet, maybe that kernel is broken somehow
<barry> infinity: at least, when/if pymultibuild works, the overrides won't break, and then we can go back and clean things up during normal package maintenance (ha ha)
<hallyn> stgraber: d'oh, maybe that's it
<infinity> barry: Fair enough.  I dunno, one would think fixing dh_auto_clean would be vaguely trivial for someone who knows the issue.
<hallyn> stgraber: in any case i intend to wait a bit to push that lxc :)  you weren't in any hurry for your fix, or were you?
<hallyn> (i've pushed my additional pits to your tree, which isn't quite right, but it's what i did...)
<dobey> things like this really should be fixed *before* pushing everyone to py3 :)
<barry> infinity: you probably want to fix things consistently, iow, you don't want to eliminate the dh_clean up-call problem w/o also fixing dh_auto_build and dh_auto_install (which has some of the same problems)
<barry> dobey: well, that's what we get for trying to be aggressive.  the perfect is the enemy of the good.  /me reaches for other cliches
<infinity> barry: True.  But it's probably all reasonably trivially-derived from the X-Python headers, and easily cascaded down through the stack.
<dobey> even when dh is fixed to work with python3 without a billion overrides, i doubt it will be perfect
<stgraber> hallyn: nope, no hurry. Anyway, we're talking about landing stuff in -proposed, not like anyone would use that until post-alpha2 then
<stgraber> hallyn: so might as well wait till Thursday and push directly to quantal (once the freeze is lifted)
<mvo_> barry: meh, ok, this is a bit more work than I had hoped for 21:00 in the evening, I will leave it for now, its almost ready, I think simply building py2,py3 is the simplest approach for now
<dobey> i just like it when the ducks are in somewhat of a row, even if it's curvy
<barry> dobey: since dh is written in perl, that is assured
<dobey> well at least it's not in python
<dobey> then it'd have to deal with all the string parsing insanity to support both python2 and python3
<dobey> not a fun road, that one
<barry> mvo_: if you want to push a branch, i can take a crack at it for the rest of my day
<slangasek> hallyn: hi - so on bug #974584... this is the same bug we discussed a couple weeks ago?
<ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584
<slangasek> hallyn: I'm actually confused as to why we would block on the Debian maintainer for this
<slangasek> (though in any case, the git repo is maintained in Debian's collab-maint, so I can commit the fix as soon as we're sure it's right)
<hallyn> slangasek: yup, same one
<hallyn> stgraber: I suppose making a file under /usr/share/doc/examples/ executable is against policy?  (i'll check...)  drat
<infinity> hallyn: There's no reason to have something in examples executable unless you intend to run it from a maintainer script or something, in which case, it belongs in /usr/share/package, since /usr/share/doc shouldn't be referred to by scripts.
<stgraber> hallyn: I guess you could move it to /usr/share/lxc/example-hooks/ or something similar then
<stgraber> or just /usr/share/lxc/hooks/ but I guess some people would think that these would be hooks being run for all containers
<hallyn> think i do like /usr/share/lxc/hooks better...  but i'll defer
<hallyn> stgraber: multiple hooks work jsut fine, btw
<hallyn> oops, i need to not litter mtab from the mount hook.
<hallyn> and yeah it looks like a kernel bug on amazon's images.  not having a problem elsewhere.  i think it may have to do with ebtables
<slangasek> hallyn: I think I've missed the justification for why, in a chroot, we would ever want /run/shm to be a symlink to /dev/shm.  Is that because it's the only way to ensure things referencing /dev/shm and things referencing /run/shm (all 0 of them currently) see the same view?
<slangasek> hallyn: it would help me to see laid out what all the correct end states are
<hallyn> slangasek: if /dev is bind-mounted from the host ina  chroot, then we don't want to mess with its dev/shm
<hallyn> so, we could do nothing, rather than symlinking it to /run/shm
<hallyn> so yeah it' sso that anything you run in the chroot without exiting/reentering it will talk to each other if using /dev/hsm and /run/shm
<slangasek> hallyn: but then we should check if /dev/shm is bind mounted rather than if /dev is bind mounted, no?
<slangasek> hallyn: because /dev could be bind mounted while /dev/shm is either a) an empty mountpoint or b) a symlink to /run/shm, which would resolve within the chroot
<hallyn> slangasek: no, the point is not to mess up the contents of /dev on the host
<hallyn> heh, good point, it could make a circular symlink
<hallyn> so perhaps, if /dev is a mountpoint in a chroot, we just do nothing?
<hallyn> tbh i'm not sure what sort of case you'd have where /dev is a mountpoint and yo'ure in a chroot
<hallyn> schroot i guess
<slangasek> let me jot some thoughts into the bug
<hallyn> slangasek: thanks
<tkamppeter> In bug 1017507 a user writes "question # 200800" without link. Is there a way to find this question? Searching for question numbers in askubuntu does not work.
<ubottu> Launchpad bug 1017507 in cups (Ubuntu) "Cannot run updates on my system without getting errors" [Undecided,New] https://launchpad.net/bugs/1017507
<tkamppeter> question #200800
<micahg> tkamppeter: it's linked in the bug
<tkamppeter> Found it, nicely hidden at the lower right. Thanks.
<slangasek> hallyn: posted to bug #974584
<ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584
<dobey> whee, and no way to make pbuilder use proposed afaict :-/
<micahg> dobey: use a hook to enable it
<dobey> well, no easy way
<cjwatson> zul: Hm, was just moving python-glanceclient to main in response to its approved MIR, and in the process noticed that it FTBFS - did you notice that?
<hallyn> slangasek: thanks.
<zul> cjwatson: i thought it got fixed, ill fix it right now
<cjwatson> ta
<slangasek> hallyn: please check my reasoning :-)
<hallyn> slangasek: I will, however I'm ducking out now.  I'll think through this tonight
<slangasek> hallyn: ok, cheers :)
<geofft> what's the repo for the uefi secure boot shim mjg59 et al have been working on?
<cjwatson> https://github.com/mjg59/shim
<geofft> thanks
<ScottK> jelmer: How long is it going to take to get Bug #1014570  fixed? Since bzr 2.5.1 is now in precise-updates it's suddenly more urgent to fix the regression.
<ubottu> Launchpad bug 1014570 in bzr (Ubuntu Quantal) "bzr: Unable to sign commits: "no terminal at all requested"" [High,Triaged] https://launchpad.net/bugs/1014570
<ScottK> !regression
<ScottK> !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
<ScottK> See the bug I just pinged jelmer about.
<ScottK> It was filed last week, but not in reference to the precise SRU until after I copied bzr to precise updates today.
<ScottK> I don't think it's a blacklisting situation, but we need to get it sorted.
<slangasek> hmm, tagging fail :(
<xnox> ScottK: the SRU was fixing a GPG signing bug 847388
<ubottu> Launchpad bug 847388 in bzr (Ubuntu Precise) ""gpg: cannot open `/dev/tty': No such device or address" on Ubuntu when signing commits" [Medium,Fix released] https://launchpad.net/bugs/847388
<xnox> so the code from the same region was touched
<ScottK> xnox: Yes and apparently, in the process, broke it the other way.
<ScottK> slangasek: Since you were the first Canonical person to respond can you be the one that starts the incident report, etc?
 * ScottK doesn't know all the details about such stuff.
<slangasek> ScottK: I'm not sure an incident report makes sense in this case TBH
<ScottK> slangasek: OK.  I thought it was done for all regressions, but I'm the new guy on the team.
<slangasek> incident reports are a lot of overhead, and I expect the conclusion we would draw here is "we need better compliance with regression tagging and we need better reporting of tagged bugs on the SRU team report"
<slangasek> a conclusion I don't feel the need to write a novel to reach
<slangasek> jelmer: ^^ for reference, the key tag that puts this on the SRU team's radar is either 'regression-proposed' or 'regression-update'
<ScottK> Mentioning it the relevant bug is nice too.
<xnox> what's the story about ARM and libOpenGL?
<ScottK> We have GLES on armel/armhf.
<xnox> ScottK: does that mean that the software should be patched / support GLES or arm-any builds disabled?
<ScottK> Yes, but I'd only disable building packages that are ~never going to get ported.
<infinity> xnox: Yeah, don't just disable things willy-nilly.  A build failure is a nice reminder that porting is needed.
<infinity> (I wish more people would realise this)
<xnox> infinity: yeah, I found it crap that so many packages did a delta to disable arm, yet the GLES was fixed in debian and I was just syncing
<xnox> syncpackage into quantal-proposed is using *full* changelog, instead of realising that it should only include since proposed.
<xnox> syncpackage into quantal-proposed is using *full* changelog, instead of realising that it should only include since quantal release.
<infinity> xnox: Hrm?  Debian doesn't default to GLES on ARM unless something changed recently.
<xnox> infinity: hmmm not sure, the debian/changelog did say fix GLES or arm =/ need to find it again then
<xnox> maybe someone was overjealous taking ubuntu patches? =)
<micahg> xnox: re syncpackage, yeah, that's known, not sure if there's a bug
 * micahg can't seem to find a bug
<xnox> infinity: ScottK : is it hard to port from OpenGL -> GLES?
<lifeless> xnox: only if you use opengl facilities
<lifeless> xnox: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/
<xnox> lifeless: please elaborate
<lifeless> xnox: have a read of that url
<xnox> ok
<xnox> lifeless: thank you very much, very informative.
<xnox> I am correct to say that OpenGL is converging with OpenGL ES in 4.1 and latter?
<infinity> xnox: Define converging?
<infinity> xnox: GLES will always be based on GL (GLES 3.x is based on GL 3.3), but unless GL drops all support for features GLES doesn't have, they'll never "converge".
<xnox> infinity: porting to 2.0ES helps porting to 4.1
<infinity> xnox: And no one wants to drop support for anything, ever, because they don't want to break old software.
<xnox> right. ok.
<infinity> xnox: Sure, porting to a newer GLES (or a newer GL) helps in porting to the other.
<xnox> OpenGL 4.1 has this on wikipedia "Full compatibility with OpenGL for Embedded Systems (OpenGL ES) 2.0 APIs"
<xnox> yeap, yes that's what I meant infinity .
<infinity> xnox: And porting to *just* GLES tends to make things "just work" (though without fewer features available to you) on GL4+
<infinity> s/without/with/
<infinity> xnox: Right, yes.  GL4.1 is a superset of GLES2.0, but that's not helpful if your GL4.x program does Super Fancy Things.
<xnox> ah =) ok
<infinity> xnox: Then again, there's little excuse, outside of video games and 3D rendering software, to do things on a desktop that GLES can't do.
<xnox> infinity: "avogadro: Molecular Graphics and Modelling System" probably qualifies as "3D rending software"
<infinity> xnox: Yeah, there will be a few here and there.
<infinity> xnox: Blender could be another that has a legitimate need for full desktop GL.
<infinity> (THough, most open source GL stuff is so old that it's probably GL1.3 compliant, which means a quick port from old APIs to new APIs means it'll magically work on GLES2.0)
<xnox> ok. I'm intrigued and want to do a port of something in my spare time
<infinity> xnox: Pick something that's a KDE/QT application, since those have no choice but to be ported or rot.
<Riddell> infinity: why's that?
<infinity> Riddell: Because QT is linked to GLES, and that kinda bubbles up.
<infinity> Riddell: Trying to build a GL application against a GLES QT ends in tears.
<xnox> Riddell: on arm-any that is we are talking about
<xnox> porting KDE/QT apps sounds great to pick C++ and Qt and OpenGL at the same time ;) win
<Riddell> yeah applications should support both gl and gles which is hardly an easy thing to do
<infinity> Riddell: It's not hard to write them that way from the get-go, it's a bit of a pain to fix after the fact.
<infinity> (And sometimes, I just cheat and throw some #ifdef magic around and move on with my life)
<Riddell> infinity: so doesn't the same issue affect gtk or nux?
<infinity> Riddell: nux, yes.
<infinity> Riddell: GTK, no.  It doesn't directly do abusive things.
<infinity> Riddell: And gnome-shell links against cogl, which does effin' magical GL/GLES backend mapping, so YOU DON'T HAVE TO CARE (or be a 3D programmer).
<infinity> Riddell: All in all, I think gnome-shell wins here.
<Riddell> interesting
<infinity> Granted, if your application needs to do fancy stuff, you need to link libGL directly and do your crazy fancy stuff.
<infinity> But I'd contend that for "desktop effects" type of 3D rendering, cogl has your bases covered, and is a lovely shim to "not having to give a crap about how any of it works."
<robert_ancell> infinity, can you get libgee-0.8 out of NEW?  It's just a versioned copy of libgee with the latest update
<infinity> robert_ancell: Why are we versioning these source packages?  Is there value in having the old one around?
<robert_ancell> infinity, upstream versioned it, so so should we
<infinity> robert_ancell: I'm not sure I agree with that statement. :P
<robert_ancell> infinity, also it means we can keep the archive sane without manually updating 70 packages today
<infinity> robert_ancell: The previous one was just "libgee".
<robert_ancell> infinity, and you should be able to have both libgee-0.8-dev and libgee-dev installed at the same time
<infinity> robert_ancell: The archive remains sane if you upload "libgee_0.7.x" as well, the old libraries stick around as long as something depends on them.
<infinity> But, *shrug*
<xnox> robert_ancell: multiple co-installable -dev packages are rarely supported without a meta libfoo-defaults package, ala gcc / postgres / boost where you might end up supporting multiple major versions simultaneously on LTS timeframes.
<infinity> robert_ancell: If the APIs are wildly incompatible, I guess that makes some sense.  If they're not, having a versioned -dev package means touching every build-dep for a transition that could have just been rebuilds.
 * xnox is not sure how *big* libgee is.... judging by the name gee doesn't sound giant
<infinity> xnox: Oh, it happens more than you'd think.
<infinity> xnox: But I try to discourage it when I see it, unless there's good reason.
<xnox> *sigh*
<infinity> (gtk2 and gtk3 come to mind)
<robert_ancell> but what is the problem?
<infinity> (and qt3 and qt4)
<xnox> robert_ancell: the problem is that instead of doing no-change rebuilds, you actually have to modify the build-deps.
<infinity> robert_ancell: If the API isn't horribly broken, it just makes more sense to build libgee-dev from the new package, rather than having coinstallable versioned -dev packages.
<xnox> s/libfoo-1-dev/libfoo-2-dev/
<robert_ancell> xnox, but we modify those anyway when we change the (>= 0.16) to (>= 0.18)
<infinity> robert_ancell: We don't actually want multiple versions of most libraries around.
<xnox> robert_ancell: why?! shlibs depends will do that for you for the resulting binary packages
<cjwatson> robert_ancell: You'll understand when you do a shift on +1maint ;-)
<infinity> Also, upstream changed their SOVER scheme?  Cute.
<cjwatson> At scale, being able to just do no-change uploads of stuff is much easier than having to change the package name being build-depended on
<infinity> We've gone from libgee2 to libgee-0.8-0
 * xnox want's to bash libtool manual against something or someone
<RAOF> xnox: To be fair, the libtool manual is a bit of an impenetrable morass.
<micahg> still no reason to version the source unless we're keeping both around
<xnox> RAOF: it's think and heavy enough for bashing. I'm not intending to force people to read it ;-)
<xnox> I remember someone tried to do /usr/include/libfoo/1/*.h  and /usr/include/libfoo/2/*.h and actually have people hardcode #include <libfoo/1/bla.h>
<robert_ancell> micahg, except for the exact problem we have with poppler changing their api all the time.  If upstreams versions their libraries correctly like libgee and we match it then we never get unbuildable and uninstallable packages.
 * xnox cried
<robert_ancell> We just need to have a good process for reaping old versions
<xnox> robert_ancell: yes and the good process is symbols versioning
<cjwatson> Our process for that is pretty much fine, but it works even better when you don't have to create a new source package.
<micahg> robert_ancell: I don't see how having a versioned source helps unless you're keeping both around
<cjwatson> I'm entirely with infinity on that.  Sometimes it's necessary, but if it isn't absolutely necessary, please avoid it.
<robert_ancell> xnox, except that doesn't work when loads of packages ftbfs due to the -dev package no longer matching
<infinity> robert_ancell: Surely, the goal is to move to the new version.  I only see 5 dropped symbols here between 0.6 and 0.8 so, while it's an API break, porting things should be trivial.
<infinity> robert_ancell: And we want things to FTBFS and need fixing, rather than shipping 7 versions of a library.
<infinity> (Yes, really).
<micahg> xnox: you should bump build-depends if an FTBFS patch changes uses a new API
<xnox> micahg: that is true. I was working under assumptions of sane stable abi/api library maintainers
 * xnox wonders why 5 symbols were dropped.....
<robert_ancell> xnox, because upstreams don't want to drag around legacy stuff forever.  They just want to make a new versions and drop cruft
<infinity> xnox: Not everyone is libc. ;)
<infinity> API breakages happen.  We deal with them.
<xnox> I am surprised that libgee is actually a gnome'ish thing. gobject & gtk have very very stable api's with proper depreciation cycles etc.
<cjwatson> Though I do think some upstream library maintainers are a bit arrogant in their assessment of the worth of application developers' / packagers' time vs. the "cruft".
<cjwatson> "Getting rid of my kilobyte of compatibility code is worth you spending several hours porting stuff"
<infinity> robert_ancell: Anyhow.  If this is how Debian plans to maintain it too, fine, I'm all for keeping deltas low.  But since it's not in Debian yet, I'm guessing that perhaps they'll follow our lead (or, they'll pick an unversioned source and -dev name because that's the usual way to go).
<xnox> robert_ancell: where did libgee 0.8 come from ? I only see 0.7 at http://ftp.gnome.org/pub/GNOME/sources/libgee/
<infinity> xnox: 0.7 is the pre-release of 0.8
<robert_ancell> infinity, I ran it past #debian-gnome and they said version
<infinity> xnox: (0.7 is what robert_ancell uploaded)
<xnox> infinity: ah, ok.
<robert_ancell> xnox, 0.7 is the unstable release in the 0.8 series (GNOME versioning)
<infinity> xnox: Standard GNOME operating procedure.
<infinity> robert_ancell: Alright, if this is how they plan to maintain it, I'll accept it like this.  But I expect this won't be used as an excuse to avoid transitioning all the rdeps. :P
<infinity> And hey, there's only 70 of them.
<robert_ancell> infinity, nope
<xnox> infinity: upstream git repo has explicit support for co-installing 0.6 & 0.8, so it looks intentional
<robert_ancell> xnox, yes, it is
<mbiebl> infinity: since the .pc file is versioned, there is no chance an unversioned -dev file would work without sourceful changes
 * xnox scons is entertaining in calling configure to run clean, just saying....
<mbiebl> sourceful changes to the rdeps, I mean
<infinity> mbiebl: Bleh.  And, while that's true, that also seems like a poor decision. :P
<infinity> mbiebl: Oh well.
<seb128> yet a poor upstream decision
<xnox> I will run abicheck on the libgee to check how much is actually incompatible and see if they can maintain the cruft as deprecated.
<seb128> not really ours...
<xnox> since it's pre-release still, maybe they can be convinced to sanity
<infinity> seb128: Yeah, I realise.  Since now upstream configure scripts will look for pkg-config foo-0.8, and we sure as heck don't want to patch all of those.
<infinity> seb128: Though, we could provide some symlink magic and still have one true -dev package.
 * infinity thinks we need to lock some Debian library maintainers and release/ftpmaster/transition-type people in a room with a bunch of upstream library developers and wait for a few hours.
<StevenK> And then end up with a bunch of orpahned software?
<mneptok> the buffet would be gone. and?
<xnox> infinity: symlink magic is just delegating the trouble to security/sru/backport
<micahg> hrm?
<infinity> xnox: Hrm?  I don't see how it would affect security/SRU at all.
<infinity> xnox: And backporting is going to be a no-go period with every rdep having its configure and build-deps changed.
<micahg> and backport shouldn't be affected either if the build-depends are versioned properly
<infinity> xnox: (Well, sourceful backports would be needed)
<xnox> infinity: about locking people up: they will end up designing go & doing static linkin ;-)
<seb128> infinity, trust me I don't like it either, it's clearly bogus upstream behaviour
<seb128> but it doesn't really make sense to try to work around upstream in our packaging in such cases
<mbiebl> using API version only really works well if you do it like glib or gtk on be very strict about breaking it
<seb128> we should rather aim at teaching upstream how to do it correctly ;-)
<mbiebl> bumping it with each new GNOME major release would be painful, indeed
<seb128> vala is annoying in that regard
<seb128> it leads us to have often 3 vala versions around
<mbiebl> seb128: nod
<mbiebl> and chasing down all rdeps is time consuming as hell on each new upstream release
<xnox> libgee is written in vala... maybe that's why the break?!......
<robert_ancell> xnox, it's kind of a companion library to vala
<infinity> robert_ancell: And you win an implicit pointer conversion FTBFS.
<infinity> robert_ancell: (probably just a missing include somewhere)
<infinity> robert_ancell: 5 implicit declarations during the build.  Fixing even the ones that don't break the build would be swell.
<kees> infinity: oh! you're on MIR, can you approve this one? 965467
<infinity> kees: My god, it quotes wikipedia.
<kees> hehe
<kees> my mom needs xps reading support. ;)
<xnox> bug 965467
<ubottu> Launchpad bug 965467 in libgxps (Ubuntu) "[MIR] Please transfer libgxps 0.2.2-1 (universe) to main" [Medium,Confirmed] https://launchpad.net/bugs/965467
<infinity> kees: Your mom runs Quantal?
<infinity> kees: My mom can barely sort out the TV remote.
<slangasek> your mom's so quantal, she ____
<kees> infinity: she doesn't yet, but will in a few months :)
<infinity> kees: Fair enough.
<infinity> kees: Are you planning to make sure the desktop team hasn't forgotten about these magical evince/xps plans?
<kees> infinity: once xps is in main, yeah, I'll chase down the --enable-xps option in the evince build.
<infinity> kees: The rationale seems sane to me.  I'm just going to give the packages a once or twice-over.
<kees> infinity: okay, cool
<infinity> kees: If you want to get an evince in -proposed with that flag flipped, go to town.
<infinity> kees: I'll promote the lib once I'm sure it'll stick (cause I don't really feel like fighting with people over promotion/demotion over and over again in component-mismatches) :P
<infinity> kees: And I assume our evince is maintained in bzr, so do be a dear and commit there too.
<infinity> kees: Your mom will be proud that you touch software she actually uses.
<infinity> (My parents seem to be deeply unimpressed with what I do, unless I tell them I'm fixing a bug in Firefox or Thunderbird, cause they know what those are!)
<JontheEchidna> My dad always tells me to fix his KDE bugs :P
#ubuntu-devel 2012-06-27
<broder> my parents always ask me to fix their google bugs. at least you can do something about those :-P
<infinity> broder: Oh, my mom does that too.  And insists that I fix every broken spam filter around the world too.
<Chipzz> in	
<broder> hehe
<Chipzz> argh
<Chipzz> how do these chars even GET to irssi...
<Chipzz> infinity: I'ld much rather have them unimpressed than them trying to get me to fix their windows tbh
<StevenK> infinity: My mother used to work for a bank, and that experience seems to have completly turned her off computers, so I have no luck explaining what I do to her.
<Chipzz> my parents (and a lot of other ppl I know) seem to think that just because I work in IT, I care about windows and/or care about fixing their windows
<infinity> StevenK: I tried to explain "porting to other CPU architectures" to my parents once over dinner.
<JontheEchidna> My dad is a software engineer, so unfortunately he knows what is in the realm of possibility to do :P
<StevenK> infinity: Hahaha
<infinity> StevenK: And, while that was painful enough, they asked me to try to explain it again a week later.  And a month after that.
<JontheEchidna> He started using KDE because it was the DE most like CDE
<Chipzz> JontheEchidna: "unfortunately" you say? :)
<Chipzz> I would say "fortunately" :)
<StevenK> infinity: Oh, that's dreadful. Absolutely hilarous, but dreadful. :-)
<JontheEchidna> Chipzz: well, then he asks me to fix bugs that I can actually fix but maybe don't want to :P
<JontheEchidna> It's the equivalent of the teenager problem of "parents finding your facebook profile" for software engineers ;-)
<Chipzz> JontheEchidna: then again, he can fix his own windows. or that of your mother/other family ;P
<JontheEchidna> He fixes my mother's Windows begrudgingly. If he had his way she would be using Linux too
<JontheEchidna> especially since if something breaks around the time he fixes something else, he gets blamed :s
<Chipzz> infinity: so.. why did you even bother in the first place if you knew they wouldn't get it? :)
<Chipzz> making conversation? :)
<infinity> Chipzz: They keep asking what I do for a living.
<infinity> Chipzz: Over and over again.
<infinity> Chipzz: As if, some day, it will stick.
<infinity> Bless their luddite hearts.
<StevenK> "I work with a bunch of hippies on this free software stuff." ?
<Chipzz> infinity: explain it in simpler terms then? :)
<infinity> I've tried simple.
<infinity> And complicated.
<infinity> And some in between.
<Chipzz> "I'm trying to get firefox to work on your phone" ;)
<infinity> They need TV shows about programmers.
<StevenK> infinity: When I broke the news that I was joining Canonical to my mother her first answer was "Uh, when that finishes, will you go and get a real job?"
<JontheEchidna> heh
<infinity> It's not like my mother knows anything about the legal system either, but she's convinced she knows what my brother (a lawyer) does for a living because she watched Law & Order.
<infinity> So, she doesn't ask him. :P
<JontheEchidna> The company I work for provides board-level FPGA/DSP solutions, and I write development tools to aid developers with writing code for the boards.
<JontheEchidna> It usually just gets described as "I write computer programs"
<Chipzz> infinity: actually you may be rigt about the TV shows. like I mentioned earlier, if you mention you work in IT, the majority of the people will expect you to fix their stuff, even if you're say, a DBA
<infinity> JontheEchidna: I'm sure Dick Wolf could make that into an entertaining plot for my parents.
<StevenK> infinity: Have you tried having your parents watch The IT Crowd? :-P
<infinity> StevenK: But I'm not a helpdesk monkey!
<JontheEchidna> hehe
<Chipzz> StevenK: you're not suggesting trying to turn infinity's parents on and off, are you? ;)
<infinity> StevenK: (Even if I do bear a striking resemblance to Moss)
<StevenK> Although thinking about it, that may make things worse ...
<StevenK> "You hide under desks and plug things in, do you?!"
<TheMuso> My mother and sister have some understanding of Linux and open source, my sister understanding more about distros etc, but my father is clueless about computers period.
<stgraber> managed to get most of my family running Ubuntu, so sure I end up fixing their stuff but it's mostly interesting things to fix at least (where the last one in date was a weird kernel/NM ipv6 race condition, described by my grand-mother as "<wireless name> keeps showing up on my screen every 10 minutes")
<stgraber> so as long as people don't break 12.04, I should be fine for a few years ;)
<elky> My mother has submitted bug reports all by herself before. Do I win something?
<cjwatson> The right to fix them?
<elky> cjwatson, I recall one of them being about silly graphics cards that weren't intel, ati or nvidia. That gets fixed with fire aiui.
<infinity> elky: People still make GPUs other than those 3?
<elky> this was like 4 years ago now
<infinity> (That's actually a half serious question. Other than all the players in the embedded market, I haven't seen a non-big-3 desktop video card in ages... Does VIA still make the S3 Savage stuff?)
<elky> I would find what it was if launchpad wasn't insisting that she'd never reported bugs despite being able to find a different bug she reported.
<elky> Ah yes, it was a VIA.
<elky> And i never met one that didn't deserve to DIABCF
<directhex> i had an SiS card as an undergrad.
<RAOF> You sometimes find strange GPUs on server motherboards.
<JontheEchidna> I got a VooDoo2 card for Christmas in 2000 (I was 8)
<infinity> RAOF: I suspect that will finally be changing with Intel and AMD seeing the light about on-die graphics.
<directhex> RAOF: oh, yeah, there's a modern trend towards really weird ones
<infinity> RAOF: Though, it'll take a few CPU generations for them to realise they've seen it.
<elky> infinity, https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/157941 VIA/S3G DeltaChrome IGP and approaching 5 years ago... so several generations
<ubottu> Launchpad bug 296028 in metacity (Ubuntu) "duplicate for #157941 AisleRiot FreeCell Soltaire Fullscreen bug" [Low,Triaged]
<elky> i think the card had nothing to do with it though
<cyphermox> @pilot out
<cyphermox_> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal A2 prep | Archive: please use -proposed | 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> Good morning
<ion> hi
<stgraber> pitti: what, already? :) (I usually take you saying good morning as a sign that I should stop looking at IRC and think about getting some sleep)
<pitti> stgraber: I got up with my wife today instead of taking another nap after the alarm clock
<pitti> my brain started working and didn't let me sleep any more; silly invention, such a thing..
<stgraber> hehe :)
<StevenK> pitti: Bloody hell, I haven't even had lunch yet and you're up and on IRC.
<digitalknight> hi all
<digitalknight> I am a C and C++ developer with foundations in algorithms and distributed systems
<digitalknight> I am really interested in contributing to ubuntu
<digitalknight> Please let me know how I can proceed
<ScottK> Find something that's broken and annoying you.  Figure out the fix and then attach the patch to the existing bug (or file a new one) and then subscribe ubuntu-sponsors to the bug and someone will look at getting the fix into Ubuntu.
<larsduesing> good morning
<larsduesing> please could anybody have a look at SRU: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 thanks :-)
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [Undecided,New]
 * kees hugs infinity
 * infinity blushes
<kees> do uploads to quantal proposed not close LP bugs?
<digitalknight> hi all
<digitalknight> I am a C and C++ developer with knowledge of algorithms and distributed algorithms
<digitalknight> Please let me know how can I contribute to Ubuntu
<hyperair> digitalknight: didn't ScottK reply you earlier?
<hyperair> 12:51:26 <ScottK> Find something that's broken and annoying you.  Figure out the fix and then attach the patch to the existing bug (or file a new one) and then subscribe ubuntu-sponsors to the bug and someone will look at getting the fix into Ubuntu.
<digitalknight> hyperair, no,actually I went offline,so I could not read it
<digitalknight> Thanks a lot for reiterating it
<digitalknight> hyperair, Another thing,should I start off as a MOTU?
<hyperair> digitalknight: you can't start off as a MOTU. you start off by contributing patches to bug reports, and once you've contributed enough and proven your level of technical expertise, you apply for MOTUship.
<dholbach> good morning
<digitalknight> hyperair, I meant,as a MOTU hopeful
<hyperair> eh well, you can
<digitalknight> hyperair,what exactly do MOTU hopefuls do?
<hyperair> well the same things that MOTUs do, besides reviewing and uploading others' work.
<hyperair> instead of uploading changes directly to the archive, you'll have to submit patches via launchpad and get a motu/core dev to upload them for you
<digitalknight> hyperair, ok,and so eventually,I can try for core developer membership,right/
<hyperair> yup
<digitalknight> hyperair, right,thanks
<digitalknight> I am associated with OSS already
<digitalknight> I am a Google Summer Of Code 2012 student for PostgreSQL
<digitalknight> I just want to contribute to Ubuntu also,because I love ir
<hyperair> that's nice =)
<digitalknight> hyperair, thanks,also,what kind of knowledge is required(apart from good knowledge of C)?
<hyperair> well you eventually pick these up as you go along. it's easier for you to just jump straight in and learn fromthere
<hyperair> i think there's a page on wiki.ubuntu.com about getting started
<digitalknight> hyperair, okies,because,I do not have much knowledge of Operating Systems atm(I will be starting now)
<hyperair> http://www.ubuntu.com/community/get-involved
<hyperair> digitalknight: ^
<smb> hallyn, no
<sam-c> compare security 12.10 to 12.04 LTS??
<josh____> Hello, Gtk.FileChooser dialog rightly picks an executable file but throws an error for non-executable files. How to solve this? Here is my code for this --> http://pastebin.com/yY2PVR3r
<pitti> ogra_: the HDMI monitor bug with quantal/ti-omap4, would that be bug 1010423 or bug 1010009? or both?
<ubottu> Launchpad bug 1010423 in linux-ti-omap4 (Ubuntu) "pandaboard reports ti_hdmi_4xxx_phy_enable: hotplug absent after delay constantly" [Undecided,New] https://launchpad.net/bugs/1010423
<ubottu> Launchpad bug 1010009 in linux-ti-omap4 (Ubuntu Quantal) "omapdss fails to properly detect some monitors in quantal" [High,New] https://launchpad.net/bugs/1010009
<pitti> gema: ^ FYI
<gema> pitti: thanks!
<gema> ogra_: ping
<xnox> infinity: i gave my mom Ubuntu CD made her boot on the laptop setup wireless and open facebook / gmail. After that I said I work on making this CD. After she said "that doesn't look like much" I pointed out at thousands of things in the software centre, at which point she said "Oh, but surely that's impossible to do every 6 months"
<xnox> infinity: non the less according to her I have been leaving in London for 6 six years, although I haven't yet lived in London. But that is a minor implementation detail.
<vibhav> xnox: She could use only LTS versions?
<cjwatson> kees: Not until they get copied into quantal.  Then the bugs get closed.
<larsduesing> please could anybody have a look at SRU: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 thanks :-)
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [Undecided,New]
<ogra_> gema, hello
<gema> ogra_: you have been doing some arm testing this week, right?
<ogra_> lots, yes, since we have live images now
<ogra_> omap wasnt working at all (kernel issues) should be good with the new kernel
<gema> ogra_: could you upload your results to the tracker, so that we can track the bugs and mark them as important, etc?
<Sweetshark> quiz question to all the audience: so far I have seen bug 1017125 only on quantal -- with both gcc 4.6 and 4.7, but *not* on precise. Anyone having a hint on other toolchain changes that might cause this?
<ubottu> Launchpad bug 1017125 in LibreOffice Productivity Suite "LibreOffice crash in xmloff.Impress.XMLContentImporter::com::sun::star::document::XImporter with gcc-4.7" [Medium,Confirmed] https://launchpad.net/bugs/1017125
<ogra_> omap4 was waiting for the new ubiquity and should be fine now as well
<geser> Sweetshark: very wild guess: have your build-dependencies (c++ libs) been recompiled for your test with gcc-4.6 too in quantal? (see the thread about gcc-4.7, stl and c++ language version on ubuntu-devel)
<Sweetshark> geser: no.
<Sweetshark> geser: however, I see no external lib in the stack trace (not that that means anything ...)
<Sweetshark> geser: thanks for the hint.
 * ogra_ wonders if we changed something in frambuffer handling of the initrd recently ... looks like plymouth is broken on most of my arm installs (black screen until X)
<larsduesing> After looking after bug https://bugs.launchpad.net/bzr-builddeb/+bug/1006611 and browsing through the source a little: Am I right, maybe it is only the wrong parameter quilt-tree-policy given to bzr merge?
<ubottu> Launchpad bug 1006611 in bzr-builddeb "quilt patches are not reapplied after merge with debian" [Undecided,Confirmed]
<xnox> larsduesing: nope. the quilt-tre-policy is correct. Due to the way bzr-builddeb operates the files in the .pc directory get new file-ids (equivalent of rm & add due to quilt pop; merge; quilt push)
<xnox> larsduesing: hence the massive diff of everything removed & everything added back again
<xnox> larsduesing: plus the merge proposal diff would be against old ubuntu, not debian. And all the removed & new patches will generate even bigger .pc dir diff
<larsduesing> hmm... ok..
<larsduesing> I'll trying to look after it
<xnox> larsduesing: see also a related bug that I added in the comment, it's all the same code area
<xnox> larsduesing: my guess is that when both trees get 'quilt pop -a' treatment the file-ids are not backed-up in anyway, such that 'quilt push -a' treatment generates brand new fileids different from either trees. But this does sound very odd....
 * xnox is not a bzr dev, just a 'poweruser'
<cjwatson> quilt pop/push wouldn't drop file IDs unless you commit in between
<cjwatson> (haven't looked at the bug, just a drive-by comment)
<xnox> cjwatson: hmm but there is merge tree in between. It fails horribly if the quilt patch introduces new files, you get malformed tree bzr exception
 * xnox generally does ` quilt pop -f ` then
<larsduesing> yes
<larsduesing> there seems to be a much deeper problem in it...
<xnox> yeap, the idea & code in bzr-builddeb is sensible on high level
<larsduesing> any idea how to debug python-code which is run by "bzr merge"?
<xnox> larsduesing: read/use bzr verbose & debug modes??....
<larsduesing> oh.. maybe thats enough... yeah... thinking too deep :)
<larsduesing> Ohh...
<larsduesing> strange
<larsduesing> bzr -Dmerge -Dfetch -Dhooks merge debianlp:sid/aiccu &>../bzr.log
<larsduesing> does not give ANY debug-information...
<cjwatson> Sweetshark: I can help you with using the API to work around bug 1018349 if you'd like
<ubottu> Launchpad bug 1018349 in Launchpad itself "launchpad times out when trying to copy large package between PPAs with binaires" [Undecided,New] https://launchpad.net/bugs/1018349
<cjwatson> Sweetshark: Oh, except apparently I'm too late :-(
<cjwatson> Could've saved you six hours of build time there
<Sweetshark> cjwatson: :(
<Sweetshark> cjwatson: what would be the workaround?
<cjwatson> There's an API request you can make which is always asynchronous
<Sweetshark> cjwatson: I dont mind the build time too much personally, but hugging the ressources is bad.
<Sweetshark> cjwatson: k
<cjwatson> Sweetshark: something like this (and I do have a work item somewhere to script this more generally): http://paste.ubuntu.com/1062452/
<Sweetshark> cjwatson: saved, with try next time.
<didrocks> cjwatson: I have something generic I made for the autopilot run (copying all content from one ppa to another), I just need to find it again somewhere ;)
<cjwatson> didrocks: In my case it's part of the replace-archive-admin-shell-access spec, replacing the copy-package.py script that's part of Launchpad and requires direct DB access
<didrocks> cjwatson: ah ok ;)
<cjwatson> It'll be easy enough to translate, but I just want to make sure that it has all the options and checks done by the Launchpad version
<cjwatson> Since then (after a few other bits of work) I can delete it from Launchpad with a clear conscience
<hyperair> how does the software centre handle arch:all packages that depend upon an arch:i386 package on architectures that don't support i386?
<roaksoax> jodh: ping
<jodh> roaksoax: hi
<roaksoax> jodh: howdy!! so I'm trying to run a daemon as a particular user/group
<roaksoax> jodh: and added the stanzas setuid setgui however, it fails to start
<roaksoax> jodh: if I only add setgid it does start, however, still runs as root, ideas?
<roaksoax> http://paste.ubuntu.com/1062511/
<jodh> roaksoax: it might be becuase HOME isn't set for the user. See if you can run celeryd as shown here: http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
<xnox> roaksoax: is /var/log/maas/ created and user accessible?
<roaksoax> xnox: yep
<roaksoax> jodh: that asks for root password
<jodh> roaksoax: are you passing 'maas' at the very end?
<roaksoax> jodh: yes
<roaksoax> it asks for password
<jodh> roaksoax: it should be asking for the 'maas' users password
<roaksoax> jodh there's no password for the user
<jodh> roaksoax: what does 'su -c date maas' do?
<roaksoax> jodh: asks for password
<roaksoax> jodh: http://pastebin.ubuntu.com/1062524/ --> that's how it was created
<jodh> roaksoax: well you don't appear to have set a password for the user. That aside, what does /var/log/upstart/maas-celery.log show?
<roaksoax> jodh: i think it might be because of this: [2012-06-27 09:24:03,468: WARNING/MainProcess] [Errno 13] Permission denied: '/run/maas-celeryd.pid'
<roaksoax> jodh: yeah was that
<roaksoax> jodh: so how can I effectively be able to have a pidfile
<roaksoax> jodh: when running it as non-root. Simply create a /run/maas owned by 'maas'?
<xnox> roaksoax: why do you need a pid?
<jodh> roaksoax: yup.
<xnox> roaksoax: but /run/maas should be created on each boot, as in the pre-start script
<roaksoax> jodh: cool thanks
<roaksoax> xnox: I know that :). Thanks though
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal A2 prep | Archive: please use -proposed | 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: kenvandine
<mterry> kenvandine, ooh ooh, you're a pilot now?  can you review https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/split/+merge/109209 ?
<didrocks> mterry: well done :)
<mterry> didrocks, :)
<mterry> didrocks, I forgot that pilots existed
<didrocks> mterry: yeah, this totally suits the case. I feel already sorry for kenvandine :)
<seb128> didrocks, aren't you piloting as well today? ;-)
<kenvandine> mterry, indeed :)
<didrocks> seb128: yeah, but I'll switch my shift for tomorrow or friday
<didrocks> seb128: noticing that I already spent hours on mterry's branches :)
<seb128> didrocks, escaping mterry's reviews? ;-)
<seb128> right
<mterry> He did half  :)
<didrocks> he's doing work, that's annoying! :)
<kenvandine> mterry, pointers on what to look at for those tests?
<mterry> kenvandine, the deja-dup tests?
<kenvandine> yeah
<kenvandine> mterry, it's weird... one of those tests in the scripts dir passes
<kenvandine> but others fail
<kenvandine> ** (/home/ken/src/deja-dup/simple-threshold/tests/runner/.libs/lt-runner:17750): WARNING **: runner.vala:193: Error string didn't match; expected (null), got Failed with an unknown error.
<mterry> kenvandine, run a failing test like so:  DEJA_DUP_DEBUG=1 ./runner --verbose ../scripts/bad-hostname.test
<mterry> should give enough info to figure out why
<kenvandine> (MSG: DEBUG: DuplicityInstance.vala:557: duplicity (18336) exited with value 255
<kenvandine> mterry, is that helpful?
<mterry> mvo, I wanted to change update-manager's user-visible name in LP to "Software Updater" instead of "Update Manager", but you're the maintainer
<mterry> kenvandine, can I have the whole thing in a pastebin?
<kenvandine> http://paste.ubuntu.com/1062643/
<mvo> mterry: let me fix that
<mvo> mterry: its now ubuntu-core-dev
<mterry> mvo, ah neat, thanks!
<mterry> kenvandine, it's because "'--exclude=/storage/1/Downloads" got passed to the mock duplicity script and it wasn't expected
<mterry> kenvandine, is that an exclude from your normal user?  (we shouldn't be seeing those)
 * kenvandine checks
<kenvandine> oh... ~/Downloads is a symlink
 * kenvandine doesn't want to fill up his SSD
<mterry> kenvandine, interesting...  that's a side effect of how deja-dup handles symlinks in the exclude list (it expands it out and includes both the source and the target)
<mterry> kenvandine, let me see if I can make the mock smarter...
<kenvandine> thx
<mterry> kenvandine, in the meantime, there's that nice ubuntu-release-upgrader branch...  ;)
<kenvandine> in the mean time i'll try to run the tests on another box, after reviewing the release upgrader
<mterry> mvo, are there any consumers left for python-update-manager (as apposed to python3-update-manager)?
<cjwatson> reverse-depends says no
<cjwatson> It was fairly temporary I think
<cjwatson> We do need to keep py2 compat in the release upgrader though
<mterry> cjwatson, right, but I didn't know if there were any planned or 3rd parties that we knew would want it
<cjwatson> The main thing we knew about in the time was in the Ubuntu archive (I forget exactly what it was) and has apparently been fixed
<mterry> cjwatson, OK, you mean provide a python-distupgrade as well as python3-distupgrade, or something more intricate?
<cjwatson> Oh, I think it was apturl
<cjwatson> The upgrader probably needs to run with Python 2 when upgrading from precise and with Python 3 when upgrading from >=quantal
<cjwatson> Which is going to be quite intricate in the dist-upgrade tarball
<cjwatson> The tarball can't rely on python-distupgrade or python3-distupgrade packages
<mterry> cjwatson, OK, sounds like a separate branch after we do the split
<cjwatson> Providing your current branch doesn't break the upgrader from precise :)
<cjwatson> So, presumably your main useful purpose in providing python3-distupgrade is that python3-update-manager needs to depend on it
<cjwatson> As such, I don't think it will be terribly useful to build python-distupgrade
<mterry> cjwatson, agreed, as long as we drop python-update-manager
<mvo> yeah, the important part is that it does not break the release upgrader, if that is ensured I'm fine and I don't think there are any other users of it
<kenvandine> mterry, your the king of refactoring!
<cjwatson> mvo: Is command-not-found still busted?
<mvo> cjwatson: unfortunately yes, I meant to just update it in the evening but wasn't aware that so much override_ magic is needed for a py3 package at this point and then I went to bed, sorry for that
<cjwatson> Oh, I've dealt with that before.  Want me to finish it?
<cjwatson> I can just copy stuff from germinate or so
<hippiehacker> https://gist.github.com/3004812 # a question regarding metapackages and dependencies, 'apt-get install -y ubuntu-virt-mgmt ; apt-get autoremove -y ubuntu-virt-mgmt' leaves behind the dependencies but 'apt-get install -y virt-manager ; apt-get autoremove -y virt-manager' removes it's dependencies... both are metapackages
<hippiehacker>  can anyone explain the difference in behavior between the two metapackages? (one does depend on the other, but removing the higher dependency should remove both right?
<apw> TheMuso, i want to confirm that I have the right config options tweaked for lowlatency, do you have a list of the key changes, from the session I recall it being CONFIG_PREEMPT and HZ=1000 basically
<kenvandine> mterry, in the ubuntu-release-upgrader split merge proposal
<kenvandine> === target changed u'../UpdateManager/Core/MetaRelease.py' => u'/usr/share/pyshared/UpdateManager/Core/MetaRelease.py'
<mterry> kenvandine, yeah
<cjwatson> That's a Python 2 path
<cjwatson> Um, be kind of careful there
<hallyn> RAOF: bug 231060, stgraber mentions you both agreed it was ok for sru, if you agree can you comment in the bug?  (I'll fix the postrm bitof course)
<ubottu> Launchpad bug 231060 in dnsmasq (Ubuntu) "packages dnsmasq and libvirt-bin conflict with each other" [Low,Confirmed] https://launchpad.net/bugs/231060
<kenvandine> mterry, and i don't have that...
<cjwatson> It's only in python-update-manager
<kenvandine> and that is temporary right?
<cjwatson> Indeed
<mterry> hm
<cjwatson> Maybe link to /usr/lib/python3/dist-packages/UpdateManager/Core/MetaRelease.py instead
<cjwatson> But really this ought to be solved some other way than symlinking to system files from the source package
<mterry> Maybe better to fix the imports
<kenvandine> mterry, yeah
<cjwatson> Like having a vaguely rational hierarchy of modules
 * kenvandine comments on MP
 * mterry was just trying to have as little changes as possible, but that's a good reason to change it
<cjwatson> Same goes for the other symlinks to pyshared
<kenvandine> mterry, sorry... make sure you ping me when you need another review
<kenvandine> i spent a fair bit of time on this already so finishing it off won't be hard
<mterry> kenvandine, k
<mterry> cjwatson, do you know why these symlinks were used in the first place?  Are they part of how the release upgrader tarball works?
<cjwatson> You need mvo really
<mterry> mvo, I summon thee
<cjwatson> The dist-upgrade tarball does need to be pretty much self-contained
<dobey> mterry, kenvandine: why arey ou symlinking it anyway?
<cjwatson> But to me this rather feels like modules being in the wrong hierarchy
<mterry> dobey, that's what we're trying to figure out
<dobey> ah
<hippiehacker> vanhoof: you around?
<cjwatson> UpdateManager should be importing from DistUpgrade, I think, not the other way round
<mterry> Yeah, but some of the links seem obviously odd, like symlinking to apt-clone or sourceslist.  that's not updat-emanager related
<cjwatson> Although I'm less sure about UpdateManager.Core
<cjwatson> I would skip those for now if I were you, and concentrate on the DU/UM cross-imports
<cjwatson> Those other ones are generally in order to ship newer versions of some modules because the ones in older releases were broken in some way
<cjwatson> Or unavailable
<cjwatson> (Note that a symlink in the source tree turns into a real file in the dist-upgrade tarball, mostly)
<cjwatson> In order to work out whether we can get rid of those other symlinks, we need to know whether the version shipped in any version of Ubuntu we might be upgrading from is (a) guaranteed to be installed when dist-upgrading, (b) sufficient to support the dist-upgrader's needs
<vanhoof> hippiehacker: I am but on a call atm
<hippiehacker> vanhoof: np just wanted to catch up at some point
<vanhoof> hippiehacker: shoot me a mail or /msg, should be off in an hour or so
<mterry> kenvandine, ok, updated the branch
<lifeng> hi all, I am the maintainer of root-system package in Debian. http://packages.qa.debian.org/r/root-system.html
<lifeng> The current version cannot be built on ubuntu due to build-dep unmet, however, I fixed this issue in git-repo of Debian packaging stuff, is it possible for ubuntu to import the package from git-repo?
<bdmurray> bryceh: having been subscribed to the regression- tagged bugs for a few days now it seems like the xorg package hook is creating quite some false positives
<bdmurray> slangasek: would you agree?
<bryceh> bdmurray, ok
<slangasek> yes, very much so
<bdmurray> one issue might be presenting the question during the development of the release
<bdmurray> like in quantal now don't tag it regression-update
<bryceh> bdmurray, what tag should it use in that case?
<bdmurray> bryceh: regression-release if it happened between P and Q
<bdmurray> I suppose I could write something to remove regression-update from all bugs reported about P before 2012-04-whatever
<bryceh> actually wait, looking at the logic, the question leading to the 'regression-update' tag *only* gets asked if the distro version is "Supported" or "Current Stable Release"
<bryceh> if it's "Active Development" (as in quantal) it doesn't ask about software updates
<bryceh> bdmurray, so, that should be zero bugs
<bdmurray> oh, that's good
<slangasek> bryceh: hmm?  because people don't file bugs against stable releases?
<bdmurray> bryceh: it still seems to generate quite a few false positives though
<bryceh> bdmurray, can you show me a couple examples?
<bryceh> bdmurray, could it just be user confusion?
<slangasek> there are also a large number of unity-specific ones; I don't know if that's related to a specific script, or some sort of unity bug filing documentation?
<slangasek> (I think it's unlikely to be random user confusion)
<kenvandine> mterry, thx
<bryceh> slangasek, compiz uses the xorg apport hook, and I think unity redirects to compiz for some issues
<slangasek> bryceh: so it sounds like this script /is/ related to the large number of false positives, then?
<bdmurray> bug 888872
<ubottu> Launchpad bug 888872 in xserver-xorg-video-ati (Ubuntu) "Unity 3D desktop crashes in Oneiric using ATI Mobility Radeon X1600" [Undecided,Incomplete] https://launchpad.net/bugs/888872
<slangasek> bug #876745
<ubottu> Launchpad bug 876745 in unity (Ubuntu) "Mouse becomes unresponsive, windows are dragged around screen seemingly at random" [Undecided,Incomplete] https://launchpad.net/bugs/876745
<bdmurray> bug 908161
<ubottu> Launchpad bug 806248 in unity 4.0 "duplicate for #908161 Launcher icons are all rendered up in top left corner" [High,Confirmed] https://launchpad.net/bugs/806248
<bryceh> if the bugs have GraphicsCard defined, that's something only the xorg apport hook adds, so that's a way to tell.
<bryceh> so, yeah, I think I know what may be happening
<bryceh> I think it is indeed user confusion
<slangasek> the current hook's question is "The problem began right after system software update"
<slangasek> mapping that to regression-update is wrong; I don't think that's user confusion
<slangasek> the user is answering honestly, but it's setting a tag that's problematic
<bdmurray> earlier in the hook we can see a tag of just regression added in some cases
<bdmurray> maybe that would work?
 * bryceh shrugs
<bryceh> yeah if you'd prefer that, it's fine by me
<slangasek> the problem is that most of these users are truthfully answering that yes, it happened after a system update... but that system update was a dist-upgrade from one release to the next
<slangasek> so yeah, I think it's better to just use 'regression' here
<bryceh> slangasek, I would call that user confusion
<bdmurray> then those will be modified to regression-release or regression-update as appropriate
<bryceh> maybe honest user confusion :-)
<bryceh> bdmurray, I'll just eliminate the question
<bdmurray> bryceh: okay, I'm sure the SRU team would be happy to review SRUs for this ;-)
<bryceh> bdmurray, I wish they would be.  I already have an SRU filed (and confirmed) for this exact dialog, that still hasn't gone out :-(
<bryceh> in fact, that fix might solve this issue... hmm
<slangasek> bryceh: how do you mean, hasn't gone out?  There's an SRU of xdiagnose in -proposed that has one bug awaiting verification?
<bryceh> slangasek, what bug is waiting?
<slangasek> (bug #1009971)
<ubottu> Launchpad bug 997470 in xdiagnose (Ubuntu Precise) "duplicate for #1009971 apport-gpu-error-intel.py keep crashing for 4-5 times on every reboot" [High,Fix committed] https://launchpad.net/bugs/997470
<slangasek> oh
<slangasek> it's a duplicate of one that has been verified
<slangasek> ok, publishing then ;)
<bryceh> that got verified like a week ago
<kenvandine> mterry, back at you :)
<bdmurray> slangasek: does the sru report need another improvement?
<slangasek> bdmurray: well, this particular bug was marked already as a duplicate when the package was accepted into precise-proposed... I think we need to be more diligent about checking such things
<slangasek> so maybe that's an enhancement for queuediff
<cjwatson> My experience has been that I'm reluctant to bounce things for tweaking bug numbers, particularly if the upload has been there for a while
<slangasek> that reminds me, I still need to reupload update-manager, whose changelog references a private bug :-P
<slangasek> cjwatson: bdmurray has convinced me that it's better for us to just fix them up ourselves and reupload
<cjwatson> I'd rather that (a) the SRU report should be able to chase such references if possible (b) there should be some override mechanism that doesn't require a reupload
<cjwatson> ourselves, as in the SRU team?
<slangasek> cjwatson: yeah
<cjwatson> Hm, I suppose that's workable
<bdmurray> I don't remember trying to hard to convince you
<cjwatson> Though it does require pushing stuff back to revision control, often
<cjwatson> Kind of tedious for say the kernel
<slangasek> and in cases like update-manager, the changelog is wrong and needs to be fixed because it references private bugs
<cjwatson> (Which is a case where I'm particularly reluctant to reupload because it's generally already been built in a PPA by the time it gets to us)
<slangasek> cjwatson: right... though the kernel is a special case where we really just care about the tracking bugs
<slangasek> bdmurray: it didn't take much convincing ;)
<cjwatson> Yes, and there have been cases where the tracking bugs are missing :-)
<cjwatson> It'd be nice to have an override file for such things
<slangasek> cjwatson: ah, heh
<cjwatson> Or there was a recent cups SRU where some of the bugs turned out to be unrelated to the SRU and Till tried to "disconnect" them after the fact
<cjwatson> Which was sort of OK I guess but very confusing, and if I hadn't been processing it all at one go it would have been hard to keep track
<cjwatson> A way to tell sru-report "no, just forget about that one" would have helped
<cjwatson> (Till would still have had to reopen the bugs after the janitor closed them on moving to -updates, but not much to be done about that)
<bryceh> bdmurray, alrighty, regression-update removed.  Do you want to file the sru bug for this?
<bdmurray> bryceh: okay
<bryceh> while I'm at it I'll fix one other question that's been ambiguous
<bdmurray> bryceh: bug 1018510
<ubottu> Launchpad bug 1018510 in xdiagnose (Ubuntu) "apport hook tags too many bugs regression-update" [Undecided,New] https://launchpad.net/bugs/1018510
<bryceh> bdmurray, thanks
<bdmurray> thank you
<bryceh> your welcome, hopefully you can find some other way to identify update regressions in X/compiz/unity bugs
<bryceh> bdmurray, don't forget to add a test case, etc. to the bug.  I've subbed ubuntu-sru
<black_joe> http://pastebin.com/VDeZnR5T Apparently debuild doesn't like my rules file. Does anyone know how to let it just brush over the rules? I have a separate make / install file. (First time packaging)
<infinity> black_joe: Why mix-and-match cdbs and dh7 that way?
<infinity> black_joe: I bet if you drop the two includes (and stop using cdbs entirely), that'll Just Work.
<black_joe> Okay. I will try that.
<black_joe> I removed the includes, but what do you mean by "cdbs"?
<infinity> black_joe: If you don't know what cdbs is, you didn't want the includes. ;)
<black_joe> I just put them in to try to silence other errors. But I think they were cuased by something else.
<black_joe> (I actually copied most of this from gedit's rules)
<infinity> black_joe: Ahh.  Instead of cargo-culting from other packages, you might try installing dh-make and running "dh_make" in a clean unpacked source tree.
<infinity> black_joe: You'll get a dreadfully simple debian/* to tweak.
<black_joe> Yeah. The errors have returned. http://pastebin.com/4R3J4XMu
<infinity> black_joe: Also, most of this probably belongs in #ubuntu-motu or something.
<black_joe> I can try dh_make instead.
<black_joe> Probably. This was the most related channel I saw when I scanned over freenode though.
<black_joe> I'll try dh_make then go there. Thanks.
<slangasek> infinity: per resolution 698.1, Â§5.2, subsection B, packaging questions are now equally on topic for both channels
<infinity> slangasek: Coffee, laptop, narrow miss, nearly had to email you a bill.
<kenvandine> mterry, see my last comment on the ubuntu-release-upgrader split MP?
<mterry> kenvandine, yeah, it prompted a rabbit hole of looking at the tests
<kenvandine> haha :)
<kenvandine> ok
<mterry> kenvandine, about to fix an unrelated-to-my-branch test problem and upload
<kenvandine> i approved your other deja-dup branch :)
<mterry> kenvandine, I'm going to leave the pyflakes test alone for now.  that can be fixed post-merge
<kenvandine> ok
<mterry> kenvandine, oh cool.  I was halfway to figuring out how to make that work well for your weird symlink case  :)
<kenvandine> well, would be good to handle that :)
<kenvandine> i just ran the tests on my laptop
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal A2 prep | Archive: please use -proposed | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mterry> kenvandine, guh, the thing I thought would fix this error isn't.  I'm just pushing as is, it's not caused by my branch
<kenvandine> ok
<mterry> kenvandine, so the tests that I expect to still fail are pyflakes and quirks
<mterry> kenvandine, branch updated
 * kenvandine tests
<kenvandine> mterry, test_end_of_life.py fails for me with python3
<kenvandine> am i just missing a depends?
<kenvandine> mterry, it's an import error, no module named Dialogs
<mterry> kenvandine, ah yes...  that's because Dialogs is from update-manager trunk
<kenvandine> ok
<kenvandine> i'll ignore that one then :)
<kenvandine> mterry, the pyflakes test pass here :)
<mterry> kenvandine, really?  hmm
<kenvandine> quirks test pass with python3
<kenvandine> but not 2.7
<mterry> kenvandine, ah yeah, my flakes errors are from leftover built code in debian/
<mterry> kenvandine, yeah.  I didn't figure out why we are getting a unicode conversion error in 2.7 at a certain point
<kenvandine> mterry, approved :)
<mterry> kenvandine, yay.  thanks so much for the reviews
<kenvandine> np
<kenvandine> mterry, never a small diff from you!
<seb128> kenvandine, mterry: good job guys!
<smoser> jodh, around?
<dupondje>  trying to overwrite '/usr/lib/evince/4/backends/comicsdocument.evince-backend', which is also in package libevince3-3 3.5.3-0ubuntu1
<dupondje> hmz :)
<micahg> dupondje: file a bug and subscribe jbicha and robert_ancell unless another desktopper speaks up here to take it
<dupondje> No apport report written because MaxReports is reached already
<dupondje> why is that
<infinity> dupondje: Which package had that overlap?
<dupondje> libevdocument3-4_3.5.3-0ubuntu3_amd64.deb
<dupondje> -rw-r--r-- root/root      3770 2012-06-27 15:45 ./usr/lib/evince/4/backends/comicsdocument.evince-backend
<dupondje> micahg: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1018543 seems somebody else was first :)
<ubottu> Launchpad bug 1018543 in evince (Ubuntu) "evince fails to upgrade in GNome-shell 3.5" [Undecided,New]
<ggherdov> Hi all. I am trying to install the search UI solritas on my solr 1.4.1 instance, which I installed as an ubuntu package on ubuntu 11.04 (natty). This is being harder than expected. The recipe at http://wiki.apache.org/solr/VelocityResponseWriter says to copy a bunch of .jar from contrib/velocity/src/main/solr/lib to /lib .
<ggherdov> Well, I don't have any of those .jar, not in the solr-common package (list here: http://bpaste.net/show/WG6bJiFKuJhA4voRNTrI/ ) nor in the 'velocity' module, that I installed separatedly (list here http://bpaste.net/show/MAEICAOm8NpVbocS18Rj/ ).
<ggherdov> should I submit a bug in the solr-related packages?
<ggherdov> I might also add that "apt-cache show solr-common"  shows this note: This package also contains the dataimporthandler contrib while omiting  dataimporthandler-extras, clustering, extraction and velocity due to missing  dependencies.
<ggherdov> what does it mean? what are the "missing dependancies" for velocity in solr-common ?
<slangasek> stgraber, cyphermox: does network-manager-openvpn generally work well in quantal?  I'm having strange periodic drops, with nm-openvpn SIGTERM in the logs
<cyphermox> slangasek: stgraber can tell you. I don't have a permanent setup that I use
<slangasek> ggherdov: please see the topic - this is a channel for development of Ubuntu, not support.  Try #ubuntu
<cyphermox> slangasek: if it's flaky on quantal might want to take a good look at precise though, because it would be the same version, most likely the same behavior
<stgraber> slangasek: works great here, what VPN is that? QA?
<slangasek> stgraber: yes
<stgraber> slangasek: let me connect to that one. My config is quite different from that VPN though. One notable difference between my own VPNs and that one is that I'm running in tcp mode by default, not udp.
<slangasek> stgraber: tcp?!  madness
<slangasek> stgraber: but I'm testing now with a raw openvpn profile instead of through NM, and it seems to be working stably
<stgraber> slangasek: I just connected from here, will see if it disconnects
<bdmurray> bryceh: its possible to see what pocket a version of a package appears in so something like this could be used in your hook http://paste.ubuntu.com/1063282/
<bryceh> bdmurray, well the problem is that half the bugs reported against X actually aren't X bugs at all
<bryceh> and the other half are usually so ambiguous they might be legitimate X bugs but are rarely associated with the right X package
<infinity> bryceh: So, the solution is to file them all against mysql-5.5 and let SpamapS sort it out.
<bryceh> bdmurray, however that code would still be mighty handy for at least just indicating if the user has stuff installed from those other pockets
<bryceh> infinity, 90% of everything is just crap.  So maybe random.random() > .9 would work?
<SpamapS> =o
<bryceh> bdmurray, so yeah I like where you're going with that code.  do you think launchpadlib calls from apport hooks are ok?
<bdmurray> bryceh: I thought you already did one in check_is_supported
<bdmurray> but yes I think its fine
<bryceh> bdmurray, hey you're right
<bryceh> bdmurray, ok cool.  maybe with your change I should centralize the login to avoid re-logging in multiple times
<bryceh> bdmurray, hmm what do you think about us maybe getting lpltk included in main?
<bdmurray> well and it really could be one function and just pass the pocket
<bryceh> bdmurray, oh yeah, just do all the data lookup in one go, that's a good idea
<bdmurray> I was just experimenting there
<bryceh> bdmurray, yeah I like it.
<bryceh> although like I mentioned it probably won't work for finding regression-update appropriate bugs, since the bugs are almost never filed against the package the bug is actually in
<bryceh> ...which is kind of a separate issue in itself...
<hallyn> slangasek: just got a response on the debian bug for the sysvinit/initscripts /dev/shm bug - he's put a fix into the git tree
<slangasek> hallyn: is it the same fix?
<slangasek> hallyn: looks like he's applied your patch... which I think we're now agreed doesn't completely cover all the cases?
<cjwatson> bryceh: as long as you aren't assuming that launchpadlib will be available by default in 10.10
<cjwatson> er, 12.10
<cjwatson> we're not likely to have it ported to py3 ...
<hallyn> slangasek: what exactly does it do differently?  if /dev/shm is a non-mounted-on directory, it won't turn that into a symlink.
<bryceh> cjwatson, hmm that could be a problem, yes this does indeed assume it to be available
<bryceh> well, I guess that's one way to stop the deluge of bug reports to X.org :-)
<hallyn> i'm having late-afternoon logic inversion issues :)
<slangasek> hallyn: the question of whether /dev/shm itself is a bind mount
<hallyn> slangasek: it doesn't ask that q, but it simply leaves it be if /dev/shm exists and /dev was not a mountpoint (and always leave it be is /dev was a mountpoint)
<hallyn> i'll reply to the debian bug pointing to yours, thanks
<slangasek> ok
<hallyn> sent :)  thanks, ttyl
<xnox> infinity: "if we don't add explicitly pthreads library to linker flags after update glibc to version 2.15"
<xnox> a see a similar failure now, but the package compiled fine in precise
<xnox> did something change in eglibc to follow suite?
<infinity> xnox: Err, I might need some context.  And that first sentence in English. ;)
<infinity> xnox: (And no, we haven't changed anything in eglibc, but we have changed the compiler)
<xnox> infinity: http://paste.ubuntu.com/1063440/
<xnox> infinity: quick google search suggests that glibc stopped exposing/linking against pthreads.
<infinity> xnox: That just looks like as-needed, your -lpthread is in the wrong place.
<xnox> qutecom used to compile fine, but now it doesn't
<infinity> xnox: -lpthread IS on the command line there, just not with the rest of the libs.
<infinity> xnox: That said, you probably want -pthread, not -lpthread.  I believe.  I keep forgetting which direction that's flip-flopped in the toolchain.
<xnox> right.... i need to figure out where they are comming from. I am scared if the boost stuff is providing the flags the wrong way around now
<infinity> xnox: What package is this?
<xnox> qutecom
<xnox> infinity: to get to that error you need this patch http://paste.ubuntu.com/1063444/
<xnox> due to changes in quantal
<infinity> It's not boost-related at all, I'm sure.
<infinity> xnox: Plenty of hits for -lpthread in the source.
<xnox> infinity: how come it compiled fine on precise though?
<infinity> xnox: If I had to guess, I'd say maybe -lboost_thread used to link pthread, so it worked by accident.
<xnox> CXX_FLAGS look correct and have -pthread in them, but not the link command has -lpthread which should be just -pthread
<xnox> CMake is confusing
<infinity> CXX_FLAGS obviously doesn't have -pthread in that invocation.
<infinity> And -lpthread *would* work, if it wasn't where it is in the commandline. :P
<infinity> (But -pthread is much less hassle to get right, since the compiler just magically DTRT)
#ubuntu-devel 2012-06-28
<xnox> infinity: ok, added -pthread... i think.... not always sure things work with CMake the way you'd expect
<nwmcsween> so is there a reason efilinux was used over something like barebox?
<infinity> nwmcsween: 'cause?
<infinity> nwmcsween: (Is there a reason everyone feels the need to bikeshed over it?)
<xnox> infinity: thanks a lot.
<nwmcsween> not bikeshedding barebox has nice code it's got people working on it and it's not ugly like grub 2
<xnox> infinity: sometimes dead obvious things are missed
<cjwatson> We don't think GRUB 2 is ugly, so that's not a good start in trying to persuade us.
<infinity> nwmcsween: Does it have EFI support?  Last I checked, uBoot had no such thing.
<cjwatson> Mostly I'd just never heard of barebox.
<infinity> cjwatson: barebox is uboot2.
<cjwatson> Yeah, google tells me as much.
<nwmcsween> grub 2 has nested fucntions - it's ugly
<nwmcsween> relies on gccisms
<cjwatson> Only a few, and they'll go away eventually I think.
<geofft> In fairness I'm worried about efilinux, but that's because I have investment into GRUB scripts
<infinity> Good thing we build with GCC.
<cjwatson> And yeah, GCCisms aren't a problem for us.
<geofft> (for my own stuff)
<infinity> xnox: Can I see your patch? Curious how/where you fixed it.
<cjwatson> I'd rather they weren't there in this case, but it's cosmetic.
<geofft> So I'm not sure "GRUB 2 is ugly" is an argument even I'd listen to, being someone unhappy with efilinux
<xnox> infinity: building, don't know if it works yet, cause CMake 'forces' me to purge everything to reconfigure. Unless I'm doing it wrong...
<nwmcsween> having executable stack isn't really too great
<nwmcsween> I doubt it's a security issue with grub but still
<cjwatson> *shrug*.
<cjwatson> If we got authoritative assurance that we weren't going to get bitten by GPLv3 if an OEM screws up, I'm pretty sure we'd be back to GRUB 2 from efilinux like a shot.
<cjwatson> Until then we'll go with small and simple on the grounds that that probably means we don't have to invest too much effort in it.
<geofft> cjwatson, not to ask you to beat this horse too dead, but I'm curious what the nature of the argument is there
<geofft> isn't it the case for x86 at least that "just turn off secure boot" suffices?
<geofft> is the worry about non-x86?
<infinity> geofft: Sure, but "Just turn off Secure Boot" is a tough thing to tell someone you handed a CD to.
<cjwatson> geofft: No, the worry is an OEM shipping a "User Product" (in GPLv3 language) that has preinstalled Ubuntu and erroneously doesn't permit disabling secure boot.
<infinity> geofft: Our target audience is "everyone", and most of the "everyones" I know don't even know their systems have firmware, let alone how to enter and configure it.
<cjwatson> That's a violation of the GPLv3, but the question is who has to cure it.
<geofft> infinity: I'm curious about the legal argument, not the practical one. I understand why we need to support secure boot
<infinity> geofft: Oh, then what Colin said.
<geofft> cjwatson: Oh, we expect OEMs to erroneously not have the off button? Okay, sigh.
<nwmcsween> because there are benifits
<cjwatson> There's been some concern that we might end up having to disclose our private key in such a scenario.
<geofft> Yeah, that makes sense
<cjwatson> geofft: We very much hope they don't - and they'd be in violation of the Microsoft logo guidelines too - but it's a possibility
<cjwatson> Also, it's possible to detect from software whether secure boot is enabled, and I can imagine proprietary software acting conditionally on that.  Is an unsigned GRUB binary with secure boot disabled an equivalent replacement for a signed GRUB binary with secure boot enabled on such a system?
<cjwatson> (Note that the logo guidelines *don't* necessarily require that a user be able to install their own keys, AIUI ...)
<infinity> xnox: http://paste.ubuntu.com/1063467/
<infinity> xnox: ^-- That works here.
<infinity> xnox: (Of course, then the build fails later with glibc single-includes fun, which is also an easy fix)
<cjwatson> My feeling for how it *should* work involves recognising that Ubuntu is just trying to get things working, and isn't interested in locking down people's systems.  But I'm not 100% certain that that's how the licence works.
<xnox> infinity: OWBuild is a build system based on CMake.
<xnox> OWBuild is not a fork of CMake, it is simply a set of macros for CMake
<xnox> that simplifies CMake scripts writing
 * xnox head desk
<xnox> not another one
<infinity> xnox: How about I fix the glib thing too and just upload, since I'm halfway there? :P
<cjwatson> And IMO the cure for such a scenario would be to require the OEM, who did the locking down, to provide users with an unlock mechanism - i.e. in such a hypothetical scenario they ought to be counted as the violators, not us.
<xnox> infinity: well you so my "mega" patch earlier of just removing the include ;-) go ahead
<geofft> cjwatson: yeah, agreed. I mean, it's the OEM that's violating GRUB's/Ubuntu's copyrights / GPLv3 license!
<geofft> cjwatson: but you guys not being able to find an actual lawyer that agrees is worrisome
<cjwatson> If we could get a legal opinion, or an FSF statement, that that's what GPLv3 section 6 means, then I think that would fix the problem for us.  But from what I saw we weren't able to get such a thing.  I don't know if it's just that we weren't stating the problem clearly enough.
<cjwatson> (Speaking, mind you, as somebody who was advocating for using GRUB 2, so take with pinch of salt I suppose)
<cjwatson> Unfortunately with this sort of thing it's not clear that my armchair lawyer's opinion suffices. :-)
<infinity> xnox: Oh wait, hah.  The pthread failure was after the glib one, not before.  My fix didn't fix it. :P
<infinity> xnox: Did yours?
<xnox> infinity: nope
<xnox> it's using funky OWBuild stuff with it's own supermacros
<xnox> cjwatson: there are many comments on http://gplv3.fsf.org/comments/gplv3-draft-4.html#3469:3310:3412:3479: and the question of 'this bit prevents providing supported signed software' was raised
<xnox> but it's not legal advice
<xnox> "This phrase effectively stops three implementations: * Free software digitally signed * Free software used in DRM * Free software in closed environments"
<xnox> GPLv3 fail
<xnox> I'm guessing they were going aver the Tiovization
<infinity> That was exactly the intent, yes.
<cjwatson> Yeah, I can find lots of random armchair legal advice, but that's no more use to me than my own interpretation
<xnox> yes.
<cjwatson> (Which, FWIW, thinks that we would be OK, but that's only my personal opinion)
<xnox> and 'real' legal advice will only come after it's been tried in court..... all lawyers rely on case-studies anyway
<cjwatson> "Free software digitally signed" is obviously nonsense armchair advice because, for example, I'm pretty sure the FSF has said they're not out to stop e.g. distributions signing their packages for the purpose of integrity
<cjwatson> xnox: In this case, I believe that a clear statement from the FSF would suffice, as they're the sole copyright holder
<cjwatson> (And look up "estoppel")
<cjwatson> bryceh: oh, instead of that launchpadlib-based code, you could use rmadison, or something using the same backend CGI service
<cjwatson> bryceh: though that's only really expecting to be a developer service and not particularly scalable - but anyway, what I mean is that if all you need is "is this in -proposed" or "is this in -updates" there are lighter-weight approaches than launchpadlib for a desktop system
<cjwatson> bryceh: also, worth checking for -updates before -proposed, since the same version of a package can be in both
<bryceh> cjwatson, thanks
<cjwatson> Or even apt-cache policy, come to think of it
<cjwatson> though I expect there's a saner way to get at that information in python-apt, and conveniently you're in python already :)
<bryceh> cjwatson, seems like I had tried both of those but didn't like it for some reason
<cjwatson> apt-cache policy definitely seems to have the information and doesn't involve hitting the network at all
<bryceh> oh right; the "is this in -proposed or -updates" bit is actually a patch bdmurray is proposing.  What i actually am using lpl for in my apport hook is something different
<cjwatson> it only tells you whether it matches what's currently in your Packages for -proposed/-update
<cjwatson> ah, ok
<bryceh> what this is trying to do is see what release status the user's system is
<bryceh> IOW differentiate between stable release vs development release vs unsupported release
<cjwatson> Consider distro-info for that
<bryceh> cjwatson, for that I couldn't find an existing tool that'd already be on the user's system... but maybe you know of one?
<bryceh> hmm
<cjwatson> It's not installed by default right now, but it could be
<bryceh> mm, so yeah if that were installed by default, that looks like it would be an ok substitution
<cjwatson> Just depend on it if you need it
<cjwatson> Then it will be :-)
<cjwatson> It's tiny nowadays and it's in main
<xnox> infinity: it looks like upstream has ditched the owbuild crap and gone pure cmake in 'tip' of their hg repo
<infinity> xnox: http://paste.ubuntu.com/1063498/
<infinity> xnox: This worked for me for now.  If upstream fixed it better, good, because my patch isn't remotely upstreamable.
<infinity> xnox: It's a brute force "fuck it, I want it to build" patch. ;)
 * infinity uploads.
<stlsaint> Hello all, Can tell me the file used to set default apps on unity bar for livecd builds?
<stlsaint> hrm, can anyone...
<stlsaint> sorry for grammar
<StevenK> infinity: I was expecting it to be disgusting, but they're small and self contained.
<infinity> StevenK: No, they're readable, it's just that harcoding '-pthread' after it goes to the trouble of trying to detect how to link pthreads is hilariously wrong.
<xnox> infinity: aha! well done at tracing the real contents of ${CMAKE_THREAD_LIBS_INIT}
<infinity> StevenK: (right on modern Linux, wrong everywhere else)
<StevenK> infinity: Portable code is wrong code!
<StevenK> Or something.
<infinity> StevenK: Hah.
<bryceh> cjwatson, actually looks like all I'd actually need is distro-info-data
<bryceh> that's a csv file, python should be able to handle that :-)
<bryceh> but wow, that's manually updated every release?
<cjwatson> Is the format guaranteed though?
<xnox> infinity: if ${CMAKE_THREAD_LIBS_INIT} broken, then upstream is still broken as well =)
<cjwatson> Why not use python-distro-info?
<bryceh> cjwatson, it would need to be, since distro-info is a dependency on it
<infinity> bryceh: I was about to say that, yeah.  I think only the distro-info interface is (vaguely) guaranteed, the data files could randomly change (though, I imagine they won't)
<cjwatson> Seeing as bdrung went to the effort of writing loads of bindings :-)
<infinity> bryceh: distro-info and distro-info-data are tied together, he could change the data, make distro-info love it, and leave you broken. :P
<bryceh> infinity, well he could change distro-info and leave me broken too
<infinity> xnox: Not necessarily, it's how owbuild is using that.
<bryceh> infinity, as launchpad does all the fricken time ;-)
<StevenK> bryceh: You're welcome.
<infinity> xnox: FindThreads isn't inherently broken, it's that what it spits out is meant to be a library -llink line (ie: in LD_LIBS)
<StevenK> We aim to please.
<cjwatson> bryceh: published interface vs. unpublished interface.  Use 'import distro_info' from python-distro-info rather than rolling your own.  It's easier anyway.
<infinity> xnox: But owbuild was jamming it into LD_FLAGS, and I was too lazy to figure out where.
<xnox> infinity: you TIL, i'm not touching it ever again ;-)
<infinity> xnox: Heh.
<StevenK> infinity: I'm amused at it being 'owbuild'. You could almost use it as an explanation of failure.
<infinity> xnox: If the next upstream is a reorg of the source anyway, I'm sure I can just sync over my hack when the time comes.
<infinity> StevenK: Indeed.
<xnox> infinity: funny you should say that, cause a "little did you know" is coming up ;-)
 * xnox hides. good night all!
<cjwatson> (Well, python3-distro-info.)
<bryceh> no such package
<bryceh> well, on precise anyway
<bryceh> >>> import distro_info
<bryceh> >>> udi = distro_info.UbuntuDistroInfo()
<bryceh> >>> code_name = 'quantal'
<bryceh> >>> code_name in udi.devel()
<bryceh> True
<bryceh> >>> code_name in udi.supported()
<bryceh> True
<bryceh> >>> code_name in udi.lts()
<bryceh> False
<bryceh> >>> udi.stable()
<bryceh> 'precise'
<bryceh> >>> udi.supported()
<bryceh> ['hardy', 'lucid', 'natty', 'oneiric', 'precise', 'quantal']
<bryceh> >>> udi.unsupported()
<bryceh> ['warty', 'hoary', 'breezy', 'dapper', 'edgy', 'feisty', 'gutsy', 'intrepid', 'jaunty', 'karmic', 'maverick']
<bryceh> >>>
<bryceh> cjwatson, so yeah this looks like it should work, thanks
<bryceh> hrm, the one problem is it doesn't appear to give the release _dates_
<micahg> distro-info-data will be SRUd as needed
<jbicha> bryceh: have you heard of libosinfo?
<bryceh> jbicha, yes, I did hear about that just recently.  haven't played with it yet
<jbicha> I don't know much about it, but it does have a database of disto releases
<jbicha> http://git.fedorahosted.org/git/?p=libosinfo.git;a=blob;f=data/oses/ubuntu.xml
<bryceh> micahg, yeah but cjwatson and infinity said not to use that directly.  but I do know it has the dates I'm looking for
<infinity> bryceh: No, his point was that distro-info will always be accurate.
<infinity> bryceh: (because data gets SRUed)
<infinity> bryceh: So you don't need dates, as long as you're not on an EOL release, you can just rely on it to not lie (well, within a week or two).
<bryceh> infinity, oh gotcha, but no that's not what I meant
<infinity> bryceh: Kay, what's the use case for release dates?
<bryceh> I would expect it to be accurate, else I wouldn't consider it
<infinity> bryceh: Or did you mean version numbers?
<bryceh> no, although now that you mention it I don't know that I can get those either
<infinity> bryceh: distro-info (the CLI) does numbers and codenames, no idea what the python module does.
<infinity> bryceh: So, what did you want with dates?
<bryceh> so far I'm only seeing codenames
<bryceh> well, not so much dates as time since the release
<infinity> bryceh: I'm trying to sort out why that's valuable. ;)
<bryceh> there's certain checks I'm doing for post-release bug reports which I'd like to be less strict about if the release *just* came out.
<infinity> bryceh: What's your cutoff for that?
<bryceh> like a month or so
<xnox> bryceh: int(release.version.split('.')[-1])+2?
<bryceh> xnox, hehe
<xnox> bryceh: int(release.version.split('.')[1])+2?
<xnox> is better in case of a point release, e.g. 12.04.1
<infinity> bryceh: Again, not sure what the python module has, but the CLI version: "distro-info --date=2012-02-11 --supported"
<infinity> bryceh: Gives you info as if it were that date.
<micahg> bryceh: just wait until june/december :)
<infinity> bryceh: So, just put yourself a month in the past and see if you exist yet!
<xnox> bryceh: what if the clock/time is wrong on the machine?
<infinity> Ecxcept that's buggy.
<infinity> micahg: Hey Micah, fix distro-info.
<infinity> micahg: --supported lists the devel release.
<infinity> micahg: That's brimming with wrong.
<infinity> bdrung: ^
<micahg> yeah, that's certainly wrong
<infinity> Same bug with Debian.
<infinity> (My machine claims that both wheezy and quantal are supported)
<bryceh> yeah there's probably a few ways to achieve this.  I've been wondering if there's a file on the system with a date that dependably matches to the release date?
<infinity> (Or, if I go back in time, it tells me precise was supported before it was released)
<bryceh> (and that would never get updated later)
<infinity> bryceh: Other than the version, which is, like, the date?
<infinity> bryceh: lsb_release -rs
<bryceh> infinity, no I do agree that's one way of doing it, but if the release is at the start of the month vs. the end of the month, that could give me a lot more or less than 30 days
<infinity> bryceh: Just be liberal in your window, then?
<bryceh> I guess...
 * micahg wonders why June/Dec 1 isn't good :)
<micahg> that's 4-6 weeks ATM
<infinity> July4/Dec25, Independence from bugs day, and Merry Christmas, no more bugs.
<bryceh> I guess my hesitation here is just that  these solutions are all built on the assumption that ubuntu will always be released in april and october
<bryceh> which I suppose isn't a *bad* assumption given history, still...
<infinity> bryceh: Random dates assume that, release versions assume nothing.
<infinity> bryceh: Since we change the version when we slip.
<infinity> bryceh: (See 6.06)
<bryceh> infinity, true
<infinity> Granted, this has only happened once. :P
<bryceh> so, yeah xnox's solution would be the best for that
<bryceh> hey, so tell me, if I'd said I needed within 7 days of the release, what solutions would you guys come up with for that?
<micahg> bryceh: anonymous launchpad query
<bryceh> hahaha
<infinity> Modal dialog box with a question.  OBVIOUSLY.
<infinity> And make it too big to fit on a netbook display, for bonus points.
<infinity> Also, use Motif.
<bryceh> micahg, well I can go back to my launchpad query for this once launchpadlib's been updated to python3
<micahg> bryceh: actually, distro info should have the release date of the current stable release :)
<micahg> *planned
<bryceh> micahg, yeah that'd be nice
<micahg> i.e. it should know enough about itself, not necessarily the next release immediately though
<micahg> although in theory we can SRU that as soon as we know as well
<infinity> If only https://api.launchpad.net/1.0/ubuntu/precise/datereleased didn't throw an embarassing 500.
<bryceh> infinity, heh
<infinity> (It has the right date)
<bryceh> infinity, yeah I bet that's due to the change in date object type that happened a bit ago.  I'm still fixing my launchpad scripts due to that change.
<bryceh> and I totally don't blame StevenK for that!
<infinity> StevenK: *stare*
<infinity> StevenK: Why does https://api.launchpad.net/1.0/ubuntu/precise/datereleased 500?
<micahg> XML Parsing Error: syntax error
<infinity> micahg: Thank god someone's here to cover for my illiteracy.
<infinity> micahg: Not quite what I meant by "why".
<micahg> heh, just pointing out it seems to be another issue :)
<bryceh> actually if you look at the source of that page, it looks like a legit date
<micahg> s/it/there/
<bryceh> so maybe it's just that the content-type wasn't specified?
<infinity> bryceh: It is the right date, yes, I said that.
<infinity> If you wget it, it 500s all special-like.
<StevenK> infinity: Haha. It actually contains the date
<infinity> Anyhow, I was going to point at the static http API (rather than the xmlrpc bits) as a perfectly reasonable non-lplib way for you to get info.
<infinity> Since you don't need to actually DO any RPC here.
<infinity> StevenK: I know.
<StevenK> infinity: You can grab precise like that. I guess the lazr.restful machinery does not like you trying to get attributes like that
<infinity> StevenK: HAHAHAHAHA.
<infinity> wget -S https://api.launchpad.net/devel/ubuntu/precise/releasedate
<infinity> It gives a 404, then proceeds to give me the date raw.
<infinity> BRILLIANT.
<infinity> Best.  Webapp.  Ever.
<StevenK> infinity: That is what I meant by "[11:55] < StevenK> infinity: Haha. It actually contains the date"
<infinity> StevenK: Yeah, but I thought you just meant the body (as I was seeing in a web browser)
<infinity> StevenK: The full response is so much more entertaining.
<StevenK> Our API sucks. News at 11.
<infinity> Oh wait, that really was a 404, I typed it wrong...
<TerminX> does anyone know if mipmapping is ever going to be fixed in compiz?  it's pretty pathetic that it's still broken 2 months after someone at nvidia submitted a patch to fix it on launchpad (bug 991180)
<infinity> Yeah, the proper URL is a 500. :P
<ubottu> Launchpad bug 991180 in compiz (Ubuntu) "Ubuntu 12.04 Nvidia Compiz Expo Mipmap" [Undecided,Confirmed] https://launchpad.net/bugs/991180
<infinity> And the date.
<infinity> TerminX: "someone at nvidia"?
<TerminX> yes, the patch posted to that bug is from one of the linux driver maintainers there
<infinity> TerminX: To be fair, while you know that, I certainly don't.
<infinity> TerminX: It just looks like a drive-by patch (one that, I assume, no one's noticed yet, since no one's decided to nominate for a release, prepare an SRU, etc)
<infinity> TerminX: It happens.  Bugs get missed.  Hopping on IRC and calling people "pathetic" doesn't help.
<wgrant> infinity, StevenK: The 500 doesn't contain the date.
<infinity> wgrant: I bed to differ.
<infinity> wgrant: Or beg.
<TerminX> I called someone pathetic?
<StevenK> wgrant: Run the wget _S
<TerminX> I said the situation itself is pathetic
<StevenK> s/_S/-S/
<wgrant> StevenK: What's the got to do with it?
<wgrant> Accept
<wgrant> browser sends a text/html or application/xhtml+xml Accept
<infinity> wgrant: The date is in the body.
<wgrant> So lazr.restful obliges
<infinity> wgrant: Anyhow.  It's broken either way.
<wgrant> The 500 body looks to be 'TypeError', not the date
<wgrant> You can see it at https://api.launchpad.net/1.0/ubuntu/precise/datereleased?ws.accept=application/json
<infinity> TerminX: You don't see how it came across more confrontational than, say, helpful?
<StevenK> wgrant: TypeError: datetime.datetime(2012, 4, 26, 12, 9, 10, 437678, tzinfo=<UTC>) is not JSON serializable
<StevenK> Heh heh
<wgrant> Yes.
<wgrant> So it's broken, but not in a way that is even slightly special.
<RAOF> TerminX: Fun fact: that patch breaks mipmapping on everything else :)
<wgrant> bryceh: The date type difference is purely a client-side change. It is unrelated to any server-side error.
<bryceh> wgrant, yeah I know
<bryceh> wgrant, and IIRC not due to code changes from the launchpad team, so I blame them inappropriately :-)
<wgrant> bryceh: Yeah, there's not enough people actively working on LP atm to break that :)
<bryceh> wgrant, exactly
<bryceh> there's also a launchpadlib cache corruption bug that's been a chronic irritation, but again has ended up being something wonky client-side, in code not maintained by the LP crew
<wgrant> bryceh: It was in httplib2 itself?
<bryceh> wgrant, it may be, or whatever the layer is above that.  it faults in the json decoding logic
<wgrant> bryceh: Above that is probably wadllib, which we own.
<bryceh> wgrant, maybe.  The error in question is httplib.IncompleteRead, but I think that gets generated because the cache file is truncated and it's trying to "read" from that.  I don't know what code truncates the cache file though.
<TerminX> RAOF: does it?  maybe the guy who wrote it would know that and fix it properly if the maintainer he tried contacting (sam spilsbury) didn't just ignore him heh
<TerminX> I can't imagine it did much to break it further though since the bug also affects intel
<RAOF> I have no idea whether he contacted Sam, but I do know that Sam's been working on fixing the mipmapping code.
<TerminX> yeah, he told me he tried to contact him in several different ways and never got any sort of a response whatsoever
<TerminX> how recently has he been working on fixing it?  bisection of what change broke it in the first place revealed that the bug was caused by one of sam's changes anyway
<TerminX> and considering the bug was confirmed to occur on at least intel in addition to nvidia I can't really see how it was broken any further by correcting the code in question
<TerminX> do you have some sort of report where the patch was applied and something further broke?
<RAOF> No, because it was never pushed out, as the breakage was picked up in testing.
<plagman> was this documented anywhere?
<TerminX> and what configurations was that on?  it must have been several different configurations for you to say it "breaks mipmapping on everything else"
<RAOF> plagman: Not as far as I'm aware, which is disappointing; this has just come up in my conversations with Sam.
<plagman> in any case, jusding by its contents I strongly doubt that the patch broke anything by itself
<RAOF> From what I gather it *might* be due to a bug in mesa.
<RAOF> It would be nice for Sam to provide updates on bugs âº
<plagman> or on irc pings or emails, for that matter
<RAOF> Apparently he's in Canada at the moment, so he might have been flying?
<TerminX> the cool thing about email is how when you receive one, it persists in your inbox until you do something with it
<plagman> either Mesa is broken and doesn't know how to report the GLX_BIND_TO_MIPMAP_TEXTURE fbconfig attribute properly and this would mean that mipmaps were broken _only on Mesa_  before Sam's change that moved the context initialization around and after Sam's change on everything else
<plagman> and in this case the patch just reversed that tendency
<plagman> or Mesa works fine and the patch couldn't have really done anything harmful
<plagman> and AFAIK Mesa reports it just fine
<plagman> anyway, I'd be happy to discuss that with Sam over the bug or otherwise if he has any concerns
<RAOF> I don't know; I'm just running from what I picked up as he was complaining about all drivers, everywhere, while trying to fix the bug.
<RAOF> When I see him around I'll try and get sam to ping you.
<TerminX> regardless, it's a pretty significant bug to have in an LTS release.  I'm guessing mipmapping isn't enabled by default or else we'd be hearing a LOT about it (or more likely it would have just been fixed months ago)
<RAOF> Or it's hard.
<StevenK> RAOF: "[54302.526085] NVRM: Xid (0000:01:00): 8, Channel 00000003" makes me have a sad.
<RAOF> StevenK: Do you know how to trigger that? We should have made it as easy as possible for you to file that bug on nvforums, where nvidia want it(!).
<pitti> Good morning
<StevenK> RAOF: Not really, it happens randomly and then X has a large sad.
<RAOF> Yeah, that's your driver shouting obsceneties at your card.
<StevenK> RAOF: Yeah, I only just looked up what 'Xid' actually means, the last time I mashed reset
<StevenK> RAOF: So it's a driver bug?
<plagman> not necessarily
<plagman> could be memory corruption, bad HW, etc
<plagman> could very well be, though
<plagman> but impossible to say with just that data, that's the symptom
<RAOF> Ah, you're still here :)
<StevenK> I'm happy to try and diagnose when it happens, I have easy ssh access into the box, but I can't trust anything on the screen.
<plagman> yeah, though not at work anymore
<StevenK> plagman: Oh, just some pointers about what information would be helpful to collect before I go and napalm my X session and the module would be nice.
<StevenK> (I already have this time, so next time ...)
<plagman> run nvidia-bug-report.sh as root, after that error message pops up
<plagman> preferrably while X is still running if that's possible
<RAOF> I think ubuntu-bug nvidia collects all that information, too.
<StevenK> Over ssh is okay?
<RAOF> But that'll feed it to launchpad rather than as a nice tgz
<plagman> should be, maybe you need to set DISPLAY
<plagman> trying to narrow it down to a deterministic sequence of actions would be stellar of course
<plagman> but that's hard
<StevenK> plagman: Ugh, this script is horrid. :-)
<plagman> is it?
<StevenK> append_silent "/etc/redhat-release"
<StevenK> ...
<StevenK> append_silent "/etc/gentoo-release"
<StevenK> Because you know, a for loop is hard. :-)
<plagman> not that it would tremendously change the end-result
<plagman> anyway, patches welcome
<StevenK> plagman: Thanks for the pointer.
<plagman> generally I would advise running that script and posting the result as an attachment on the nvnews linux forum
<StevenK> plagman: That script could also grab /etc/lsb-release, since /etc/debian_version on an Ubuntu machine is going to be unhelpful.
<plagman> does it also grab /etc/issue?
<StevenK> Yeah, that's the first thing it does in that block.
<plagman> that would probably cover ubuntu
<plagman> but yeah, seems lsb-release could have value
<dholbach> good morning
<bryceh> RAOF, ubuntu-bug nvidia will also generate and collect the .tgz in addition to the stuff we ask for.
<jibel> pitti, what's your opinion on bug 1013334 , an issue on launchpad's side ?
<ubottu> Launchpad bug 1013334 in apport (Ubuntu) "apport could not connect to crash database" [Undecided,Confirmed] https://launchpad.net/bugs/1013334
<pitti> jibel: no, it's indeed a bug in some hook, I'll follow up on it; thanks!
<jibel> pitti, I get a crash in Ubiquity: "TypeError: update() takes exactly 2 arguments (1 given)" but apport redirects me to bug 194688. can you check the signature ?
<ubottu> Launchpad bug 194688 in ubiquity (Ubuntu) "ubiquity crashed with TypeError: on_partition_list_edit_activate() takes exactly 2 arguments (4 given)" [Undecided,Fix released] https://launchpad.net/bugs/194688
<jibel> or is there a way to force apport to file a bug ?
<pitti> jibel: ah, it says it's already known?
<jibel> pitti, yes
<pitti> that's an apport bug indeed, it should allow you to file bugs for closed master bugs
<pitti> jibel: you can edit the .crash file and remove the KnownBug: field
<jibel> pitti, ack
<pitti> jibel: sorry, KnownReport:
<pitti> jibel: and then run it through apport-bug again; that should work
<bdrung> infinity: define 'supported'
<bdrung> bryceh: you can call distro-info --date=2012-05-28 --supported if you want to know what was supported last month
<jibel> pitti, it worked thanks!
<jml> how can I get the dependency dag for a package?
<bryceh> bdrung, ok, and that should work similarly through the python api?
<bryceh> bdrung, also, any concerns if [python-]distr-info is included in the CD image?
<diwic> jml, see your email
<alexbligh> I want to build a package that will install on both Lucid and Precise. ${shlibs:Depends} brings in a dependency on  libssl0.9.8, but this then fails to work on Precise which iuses libssl1.0.0. I've had similar problems with libmysqlclient18 and libdbi1. Ideally I'd like just one package, but one package for Precise and one for Lucid would I suppose be ok provided I can build it in one place. What's the best way here?
<cjwatson> alexbligh: In general you can't avoid this problem.  precise users should still be able to install libssl0.9.8 even though it's not the default.  We normally rebuild packages against the current set of library sonames rather than keeping a zillion old libraries around, though.
<cjwatson> alexbligh: It should be possible to make the same *source* package work on both.
<cjwatson> If you must have a single binary package, build on the oldest of the releases you want to support, and then at least there's a fighting chance that the worst case will be that users of newer releases will need to dig out older libraries (which perhaps can be automated with cunning use of apt pinning).
<alexbligh> cjwatson, thanks
<pgraner> ogra_, hey I think I might have found what the issue is with the monitors
<ppisati> pgraner: if you have an installed system, give a try to this one:
<ppisati> pgraner: http://people.canonical.com/~ppisati/linux-image-3.4.0-202-omap4_3.4.0-202.7_armhf.deb
<ppisati> pgraner: it should resolve the video issue
<pgraner> ppisati, ok, I'll try after this call I'm about to be on.
<pgraner> ppisati, I'm finding when it fails I don't get a /sys/devices/omapdss/display0/edid file
<ppisati> pgraner: edid is read after the monitor is detected, looks like hotplug is broken
<ogra_> pgraner, oh ?
<pgraner> ogra_, see my comment above
<ogra_> ah, sweet
<mterry> mvo, hello! FYI last night I just went ahead and committed a pep8 branch and some test improvement commits.  I assumed such things don't need reviews
<mterry> (to update-manager)
<mvo> mterry: yeah, thats fine
<mvo> mterry: thanks for this, given all the recent work I consider u-m really team owned, but me owned anymore
<mvo> (which is a good thing :)
<mterry> mvo, you can't escape that easily.  ;)
<cjwatson> Not sure anyone else really understands all the quirks handling and such as yet
<stgraber> mvo: the code may be team owned, the bugs are still yours, don't worry ;)
<cjwatson> Or indeed the controller
<mvo> mterhaha
<mvo> well, its fine, I don't try to sneak out here :)
<mvo> just saying that I shouldn't be the lock/bootleneck/gil/bkl
<mpt> james_w, hi, I'd like to ask you some questions about phased updates <https://wiki.ubuntu.com/PhasedUpdates#update-manager> so I can adjust the settings design
<james_w> mpt, hi, sure thing
<mpt> james_w, in "t = x/100 * (s^128 - 1)", what are t, x, and s?
<james_w> mpt, good question :-)
<james_w> mpt, try now?
<james_w> mpt, it's converting a percentage as an integer between 0 and 100 in to a value to be compared with the output of md5 such that around x% of machines will fall below the value in the next step
<james_w> i.e. it's just an implementation detail of how the percentage of machines is selected
<james_w> otherwise in the next step (floor(md5(...)/2^128)) could be calculated and compared to x directly
<mpt> james_w, ok. Next question: Why have an X-Update-Percentage integer instead of an X-Update-Phase float? Are you worried about the crippling CPU requirements of a floating arithmetic operation? :-)
<james_w> heh
<james_w> no strong reason for either I don't think
<james_w> it will likely use floating point anyway with that algorithm as written, but could be avoided
<james_w> mainly I think I chose that as it's quicker for humans to grasp
<james_w> but it can certainly be changed if there's a good reason to use a float
<mpt> james_w, only because it allows simplifying the definition
<mpt> james_w, so would this be correct? "A computer is in the current testing set for a package if X-Update-Phase * (2^128 - 1) >= md5(machine-id + packagename + packageversion)."
<james_w> mpt, yeah
<mpt> splendid
<james_w> though we probably need to shift the bounds slightly
<james_w> otherwise some unlucky person could get the update if X-Update-Phase == 0
<mpt> So change ">=" to ">"?
<james_w> and lose the "-1" I think
<mpt> james_w, next question: Are you familiar with the current emergent client-side phasing? https://wiki.ubuntu.com/SoftwareUpdates#Launching_automatically
<james_w> otherwise X-Update-Phase == 1.0 doesn't mean that everyone gets it
<james_w> yeah
<mpt> james_w, so do you think this new phasing should be instead of, or in addition to?
<james_w> and I'm not sure we need to do this explicit stuff given that we have that
<mpt> (or not at all because, yeah)
<mpt> An advantage of the explicit phasing might be that you can ramp it down again
<james_w> that's true
<mpt> or at least it gives you a mechanism to ramp down or pause an update that is less brutal than pulling the update entirely.
<james_w> I'm not sure how the explicit would work with the settings people currently have though
<mpt> Well, the reason I'm looking at this now is to change the settings design
<mpt> But a disadvantage of the explicit phasing is that I don't know how to word it.
<cousteau> will Ubuntu develop a handwritten-looking font?  (if it were metrics-compatible with Comic Sans but less ugly that would rock)
<james_w> my instinct is that putting them together is bad because it stretches out the phasing
<james_w> mpt, I meant more with the spirit of the settings rather than their exact values
<seb128> bdmurray, hey, I heard you are doing SRU reviews today, could you review compiz,libunity,bamf? We would like to get those out this week if possible to have room for a new SRU round in 2 weeks
<cousteau> or alternatively, include one of the many free handwritten-looking fonts that there already are (license would be a topic to look into)
<mpt> james_w, the spirit of the current settings is to prevent you from being nagged two days in a row (unless it's a security update).
<james_w> mpt, e.g. I don't know if switching to explicit means that everyone will get prompted for updates every day
<mpt> cousteau, in general we lack someone with responsibility to say "okay, I have X MB of the Ubuntu ISO allocated to fonts, what would be the best possible default selection"
<cousteau> I see
<xnox> cousteau: about other design stuff #ubuntu-design channel might be better. Not sure if there is one just for fonts.
<cousteau> maybe a package then...  although there are already several packages
<mpt> cousteau, and to get new fonts packaged -- there are all kinds of interesting free fonts from the League of Moveable Type and elsewhere, which aren't easily installable.
<cousteau> xnox, ok
<cousteau> how can a font not be easily installable?  I usually just copy them to ~/.fonts/SomeFont/
<mpt> james_w, it doesn't, but it means it's pure chance. Depending on that formula, you might be nagged two days in a row, or 27 days apart, and there's no way to guess in advance without knowing the name of the package that will next be updated.
<james_w> mpt, indeed, but in aggregate we can have some idea
<james_w> if we push out an update a day then on average you will be prompted daily
<mpt> cousteau, well sure, but I mean easily findable. Ubuntu Software Center has a Fonts category, but it contains only fonts that are packaged, and the UI isn't optimized for fonts.
<mpt> e.g. you can't see previews when searching, things like that.
<james_w> and I don't know if allowing that to be limited to once a week fundamentally interferes with the aims of phased updates
<cousteau> I see...  well, I'm not a big fan of the software center (although it's probably easier than aptitude or synaptics)
 * james_w goes to get some food and think about it
<cousteau> maybe changing the icon of those packages to a representation of the font
<mpt> cousteau, that would be nifty. In the long run I'd love to see a separate font utility for buying/installing/removing fonts ... but even fixing those icons in USC would be an improvement.
<cousteau> a "software center for fonts" would be an interesting idea
<doko> what is wrong with:
<doko> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/quantal/Release  Unable to find expected entry 'main/binary---add-architecture'/Packages' in Release file (Wrong sources.list entry or malformed file)
<cousteau> What I want to avoid, essentially, is that an artist (or anyone) decides to use Comic Sans because it has "comic" in it
<doko> with deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ quantal main universe
<doko> cjwatson, slangasek: ^^^
<cjwatson> doko: Is that in lxc?
<cjwatson> doko: If so, bug 1017862, I believe
<ubottu> Launchpad bug 1017862 in lxc (Ubuntu Precise) "Migrate to dpkg --add-architecture to track foreign architecture in template lxc-ubuntu" [Undecided,New] https://launchpad.net/bugs/1017862
<mpt> james_w, the reason Microsoft has "patch Tuesday" is so that admins and other people can plan for and organize installation of updates all at once. I'm not *at all* suggesting we should do that for security updates, but there's a similar motivation in grouping non-critical updates together so you install them all in one go.
<cousteau> mpt, also, an "identify this font" online (or server-based) interface would be nice.  Like WhatTheFont but for free fonts.
<doko> cjwatson, no, just an amd64 chroot
<cjwatson> doko: I'm not sure then; I'd suggest getting an strace -f to find out where apt's getting that string from
 * jml discovers dpkg-dev-el
<arand> cousteau: There's http://fonts.debian.net/ which is outdated by now, but that combined with apturl, maybe?
<mpt> cousteau, try Purisa. <http://apt.ubuntu.com/p/fonts-tlwg-purisa> It concentrates on Thai, but it has Latin characters too.
<cousteau> I think I once tried it...
<cousteau> actually when I said "handwritten" I was thinking more "comic"
<barry> mvo: any word on command-not-found upload?
<cousteau> (Komika Text is rather nice for both comic and handwritten imo...  wonder if its license would allow to add it to repositories)
<smoser> can someone help me out here.
<smoser> i'm not sure where to go loking for this.
<smoser> i laucnhed a fresh instance of quantal on ec2
<smoser> i apt-get install 'pastebinit'
<smoser> it decides it needs to update-initramfs
<smoser> is there some reason for that? or does update-initramfs always have to run on installation?
<cjwatson> smoser: I suspect that's a trigger previously pulled by some other package that hadn't been activated.
<cjwatson> Perhaps due to an installation failure or something when building the image.
<smoser> cjwatson, what sort of thing would do that?
<cjwatson> Anything that delivers files that get copied into the initramfs.
<cjwatson> You can see the mechanism near the top of /usr/sbin/update-initramfs.
<smoser> thanks. that was my next question.
<cjwatson> So look for "update-initramfs: deferring update" in your build logs, compare with where update-initramfs is actually run, and see if there's a mismatch.
<cjwatson> Then investigate from there.
<smoser> gracias
<cjwatson> de nada
<james_w> mpt, I've added some thoughts to the unresolved questions section.
<james_w> mpt, basically I think having an option like today to not prompt for non-security updates every day will be ok
<james_w> we just need to understand that X-Update-Percentage: 80 means that < 80% of machines will have it installed
<james_w> which is true anyway, that option would just make even more sure of that
 * mpt tries to sketch some phase curves
<infinity> bdrung: I would argue that unreleased/devel releases shouldn't show as "supported", personally.
<mpt> james_w, so if t = time, the normal update curve (resulting from the wait-a-week client behavior) is u(t), and your phase curve is p(t), the resulting update curve will be u(t)*p(t).
<james_w> mpt, I think so, but my maths isn't up to thinking in a bounded plane
<mpt> james_w, if you were in the office I could show you on this here whiteboard. :-) But give me a few minutes and I'll sketch it
<james_w> mpt, I sketched a couple myself
<james_w> two linear curves gave an s curve for me
<bdmurray> seb128: neither of these bamf bugs have precise tasks (I've added them) nor a regression potential statement
<mpt> james_w, p(t) might be linear, but u(t) is not, because people don't have their computer on every day, and even if they do, sometimes they'll click "Remind Me Later"
<james_w> mpt, right, I was assuming u(t) was linear in that case
<seb128> sil2100, didrocks: ^ cf bdmurray's comment on the bamf SRU
<sil2100> seb128, bdmurray: looking into it, but I remember adding that during the sprint...
<didrocks> and I remember double checking that
<didrocks> well, regression potential is empty
<sil2100> Ouch
<didrocks> sil2100: can you file them, please?
<sil2100> Will do, I think I didn't save them or something
<seb128> sil2100, didrocks: the precise lines where missing as well, anyway that's easily fixed
<didrocks> seb128: well, when filing them for 20 bugs, I guess missing two in the row was unavoidable in double checking ;) (didn't happen in "my time" though :p)
<ogra_> hmm, do we have any magic cmdline option to debug plymouth ?
<ogra_> i suspect its broken on arm but cant find anything in any logs
<bdmurray> I think there is a boot option / switch
<bdmurray> https://wiki.ubuntu.com/Plymouth#Debugging
 * ogra_ hugs bdmurray 
<bdmurray> ogra_: ^ plymouth:debug
<ogra_> thanks !
<bdmurray> regarding the libunity SRU bug 893688 shouldn't be fix released for precise
<ubottu> Launchpad bug 893688 in libunity "Unity.ActivationResponse does not work properly for python scopes" [Low,Fix committed] https://launchpad.net/bugs/893688
<james_w> ah, I see the difference, I think you were considering only a single update, and so update-manager opens as soon as the phase includes the current machine?
<sil2100> bdmurray: regression potentials editted
<james_w> mpt, ^
<bdmurray> sil2100: thanks
<mpt> james_w, I was considering a naive implementation where update-manager starts treating the update as being "available" only once the phase includes the current machine
<mpt> james_w, and then starts the clock from that point
<james_w> mpt, right, I think we got different curves because I was assuming that update-manager would be opening for other things
<james_w> and so it might have opened just before your machine became part of the set, meaning that even though you were in the testing set now you wouldn't see update-manager for a week
<mpt> james_w, we don't have to do it that way, though. update-manager could do a maximum instead: open when the computer is in the phase set, or when the week has passed, whichever is later.
<james_w> mpt, my understanding was each day would go: are there security updates? no. Are there other updates for which I am in the testing set? Yes. Has it been a week since I last opened?
<mpt> james_w, that makes sense. That would avoid the kink in this curve: http://imgur.com/rT5iV
<mpt> (not that the kink matters much, but anyway)
<bdmurray> seb128, sil2100: none of these compiz bugs are fixed in Quantal?
<james_w> mpt, yeah, with that scheme I had something like a smooth version of your yellow curve
<james_w> of course if we want to drive something like the orange one we can make p(t) non-linear
<sil2100> bdmurray: which bugs?
<bdmurray> any of the bugs associated with the SRU for precise of compiz
<seb128> sil2100, the compiz sru ones
<seb128> https://bugs.launchpad.net/compiz-core/+bug/993608
<seb128> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1006335
<ubottu> Launchpad bug 993608 in compiz (Ubuntu Precise) "CMake Error at FindCompiz.cmake:84 (include): include could not find load file: CompizDefaults" [Undecided,New]
<bdmurray> bug 1005569 for example
<ubottu> Launchpad bug 1006335 in compiz (Ubuntu) "[callgrind] compiz spends ~7% of its time inserting into and destructing the events list in PrivateScreen::processEvents()" [Medium,Triaged]
<ubottu> Launchpad bug 1005569 in compiz (Ubuntu Precise) "[callgrind] compiz spends ~25% of its time constructing/destructing strings in PrivateScreen::handleActionEvent" [High,In progress] https://launchpad.net/bugs/1005569
<mpt> james_w, ok, thanks for clarifying this with me, I understand it better now
<sil2100> bdmurray: they are, since those were cherry-picked from trunk, and trunk is used now in quantal
<sil2100> didrocks: you released compiz for quantal yesterday?
<seb128> bdmurray, oh
<james_w> mpt, no problem, do you feel this is something that will work ok, and something that you can phrase for users?
<seb128> bdmurray, the quantal upload is in quantal-proposed
<seb128> sil2100, didrocks: ^
<seb128> bdmurray, and launchpad will close them only when it's copied to quantal
<seb128> bdmurray, so they are pending "end of a2 freeze"
<mpt> james_w, possibly. We can say something slightly vague like "After a week" (not mentioning exactly how long after...)
<bdmurray> seb128: hmm, okay
<seb128> bdmurray, but you can probably count quantal-proposed as them being uploaded
<didrocks> sil2100: I did, and yes, it's in proposed
<bdmurray> seb128: well what is the point of having it fixed in the development release?  Is it so the package gets some testing first?
<didrocks> bdmurray: it's to ensure we have both fixes in both sides
<seb128> bdmurray, it's mostly so we are sure that bugs will get fixed in the new serie
<didrocks> bdmurray: meaning, we won't trigger regressions but forgetting a fix
<didrocks> by*
<seb128> bdmurray, some SRU team members are fine with having the fix commited in the vcs or available in upstream git pending the next update
<slangasek> seb128: "end of a2 freeze" - but you're supposed to be able to upload to quantal-proposed?
<seb128> bdmurray, but even if you consider testing, the new version is being tested by quantal-proposed users
<slangasek> oh, you say this one is
<slangasek> so n/m
<didrocks> slangasek: it's in -proposed
<seb128> slangasek, I'm waiting for it to be copied to quantal-proper :p
<didrocks> I did the upload at the same time
<slangasek> "quantal-proposed users" - there's not supposed to be any of those
<slangasek> and we should not assume anything is getting tested by users in quantal-proposed
<seb128> slangasek, well, that's what you get by having freezes ;-)
<seb128> shrug
 * ogra_ wonders if the dropping of the intel drm stuff broke plymouth on arm
 * ogra_ tries to downgrade to the precise version ... lets see
<seb128> I want to kill alpha freezes
<slangasek> that seems to be quite a different topic
<infinity> bdmurray: My understanding of "fixed in devel" has always been that we want to make sure it's fixed in development so there won't be surprise regressions when people upgrade, not for extra testing (though testing is nice).
<james_w> mpt, ok
<seb128> slangasek, anything as long as SRUs don't get blocked because stuff in quantal are in quantal-proposed and can't be copied over :p
<infinity> bdmurray: Since "it's uploaded to quantal" is no guarantee anyone's actually using it (though, in the case of unity, people would be).
<bdmurray> well the language does say 'It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch.'
<didrocks> that wasn't the practice at all
<james_w> mpt, the other thing is that this requires LP changes as well as client-side, so if the new UI doesn't make sense for the current scheme we may want to be able to turn it on/off easily.
<infinity> slangasek: I don't think it's safe to assume that anything in quantal-release is getting heavy testing either (though, like I said, we can be fairly sure unity is).
<infinity> slangasek: For some leaf package, mind you, "uploaded to devel release" means nothing, except the guarantee that the fix won't regress when someone upgrades from 12.04 to 12.10 (which is the point of that bullet point, I thought).
<didrocks> infinity: I had the same understanding at the time
<ogra_> slangasek, as one of the plymouth gods in here, does anything in the log from https://launchpadlibrarian.net/108854042/plymouth-debug.log stick out on a glance ? seems all arm images have the same prob that plamouth only shows a black screen on boot
<bdrung> bryceh: yes, it's similar for the python API (the functions have an optional date parameter). i have no concerns about shipping it on CDs.
<bdrung> infinity: it depends on the definition of support. the current behaviour is correct if unsupported = get's security updates
<infinity> bdrung: Hrm?  I assume you meant "supported = gets security updates".
<bdrung> i meant unsupported = get's no security updates
<infinity> bdrung: And that's not true at all.  We often have security updates hit all stable/supported releases but miss the devel release because "we know it's fixed properly in the new upstream we're releasing in a week".
<bdrung> infinity: but the updates will hit the devel release sooner or later
<infinity> bdrung: Devel releases (in neither Ubuntu nor Debian) are "supported" in the way that any end-user would consider using the word, I suspect.
<infinity> s/are/aren't/
<infinity> bdrung: Devel releases also have packages randomly dropped from the archive, and other such forms of "not supported" that aren't true in stable/supported releases.
<bdrung> infinity: because end-user define "supported" as stable
<infinity> bdrung: Well, there's also how *we* define supported, which is basically the same. :P
<infinity> bdrung: Note the lack of quantal on http://changelogs.ubuntu.com/meta-release ;)
<bdrung> infinity: there we have the definition difference: stable VS get's updates
<infinity> bdrung: And we've tried to make it clear in Debian on many occasions that unstable/testing are both not "supported" too.
 * ogra_ suspects the pylmouth issue has something to do with "[./plugin.c]                         ply_renderer_head_map:Creating buffer for 1920x1200 renderer head
<ogra_> [./ply-renderer-libkms-driver.c]                                 create_buffer:Could not allocate GEM object for frame buffer: 22"
<bdrung> infinity: that file is called *release*
<infinity> bdrung: Yeah, I was looking at the "Supported: N" stanza.
<infinity> bdrung: http://changelogs.ubuntu.com/meta-release-development
<infinity> bdrung: Which has a 0 for quantal. :)
<slangasek> infinity, bdmurray, seb128: so I think one of the benefits to having fixes actually uploaded to the dev release before published in -updates *is* that it gives us additional confidence that the fix works; but yeah, if it's clearly on track I don't think we should treat that as a blocker for an SRU since the main purpose is to ensure we don't regress
 * ogra_ grumbles ... libdrm-intel seems to give us something that makes plymouth work on arm framebuffers :(
 * ogra_ tries that theory and runs a plymouth build that pulls libdrm_intel back in 
<slangasek> ogra_: plymouth> it looks to me like the regression is that the new plymouth in quantal now supports a generic DRM backend, so it's actually talking to omapdrm instead of using the framebuffer?
<ogra_> apart from the fact that there is no omapdrm that might be right :)
<slangasek> ogra_: try rm /lib/plymouth/renderers/drm.so
<ogra_> this kernel still uses omapdss
<slangasek> ogra_: your log says otherwise :)
<slangasek> [./plugin.c]                                   load_driver:Attempting to load driver 'omapdrm'
<ogra_> hmm, intresting
<slangasek> so... maybe the problem is you have a drm driver not connected to the monitor :P
<ogra_> yup, that could be, i see the same issue on ac100 and omap though
<ogra_> (same behavior, havent logged yet)
<ogra_> so something changed that made it stop working on plain framebuffers i think
<slangasek> cjwatson: do you know if we ever have /dev *not* by devtmpfs nowadays?  Is that supported?
<slangasek> ogra_: attach a separate log for ac100, please
<ogra_> yes, will do
<slangasek> plymouth is *very* hardware specific, don't try to generalize bugs there
<ogra_> ok
<slangasek> and please try that rm drm.so and see if that works - plymouth always prefers the drm renderer if it can get it, and only then falls back to fb
<ogra_> let me reinstall the qunatal version and try the removal ...
<ogra_> slangasek, thanks, that gets me fsck interaction and a splash :)
<infinity> slangasek: It could be that it's universally loading omapdrm on all arm* machines, regardless of whether the driver does anything useful for the platform (which it won't for any right now, and won't for anything but omap* when the kernel is fixed)
<infinity> slangasek: Which would explain ac100 being broken too.
<ogra_> ??
<ogra_> how could ac100 load an omap4 kernel driver ?
<ogra_> or even think thats there
<infinity> ogra_: I'm referring to the userspace.  We don't *have* an omapdrm kernel driver yet, do we? :P
<infinity> ogra_: We only just recently got an omap drm userspace library.
<ogra_> i think there is a stub or so
<infinity> ogra_: And that's likely exploding the world.
<ogra_> right
<ogra_> though whats that userspace thing you talk about ?
 * ogra_ never heard of omapdrm userspace libs
<infinity> libdrm-omap1
<infinity> Introduced in the recent libdrm upload.
<ogra_> oh !
<infinity> Needed for the omapdrm kernel driver, which won't work right until 3.5
<ogra_> yeah, that would be it
<ogra_> damned, another package to watch :P
<infinity> Obvsiouly, if that *is* causing issues, something's gone wrong, since having a drm userspace library shouldn't blow up the world (otherwise, having intel/nouveau/radeon installed on every x86 machine would end in tears)
<infinity> So, this may need some input and fixing from Rob.
<ogra_> well, lets see how the ac100 behaves ...
<ogra_> but i wont test that today anymore ...
<ogra_> given i have to do my patriotic duty in 2h and watch the game i'll be off soon :)
<ogra_> err, 1h
<slangasek> infinity: libdrm-omap1 still shouldn't explode ac100 unless /dev/dri/card0 is being created, and that's a kernel problem
<infinity> slangasek: Well, even in that case, it still shouldn't.
<slangasek> infinity: the issue on omap4 is that there *is* a /dev/dri/card0 and it's broken
<infinity> slangasek: That certainly wouldn't help.
<slangasek> I'm not going to speculate on the ac100 until I see a log :)
<ogra_> on ac100 there definitely isnt
<ogra_> a /dev/dri/card0 i mean
<cjwatson> slangasek: /dev not by devtmpfs> Not if there's an initramfs, but I'm not sure about the non-initramfs case.
<ogra_> the ac100 3.1 kernel has similar probs with the framebuffer though (only works if you set console=tty1 now)
<slangasek> cjwatson: AFAICS we have nothing that mounts it by default in the initramfsless case
<slangasek> so hmm, maybe that explains some previously-reported bugs
<slangasek> cjwatson: I ask because we have a job to fallback to calling MAKEDEV if /dev isn't devtmpfs, and lintian complains
<slangasek> so I was wondering if that still makes sense or if we should drop the makedev dep
<slangasek> I think I'm inclined to drop it anyway; makedev is prio: extra in Debian, and this job is definitely a no-op in the default case for Ubuntu
<cjwatson> I would rather we arranged to mount it early, for consistency
<cjwatson> Could init do this as part of its initial setup?
<cjwatson> Or is that evil?
<slangasek> cjwatson: I think it's evil to have init hard-code the information about what fs to mount
<slangasek> devtmpfs is the flavor of the month, but who knows what it'll be next round
<cjwatson> Perhaps we need an Upstart job for it that runs absolutely first, then
<cjwatson> Maybe mountall, and audit everything earlier, would do?
<slangasek> maybe
<slangasek> mountall itself is already 'start on startup' and most things can't start until after
<cjwatson> I see the job in question is already pretty early, but it's kicked off from mountall AIUI
<cjwatson> Since it's "start on mounted MOUNTPOINT=/dev"
<slangasek> right
<cjwatson> Actually wait
<cjwatson> ./src/fstab:16:none            /dev                      devtmpfs,tmpfs  mode=0755                         0 0
<slangasek> my question about that is why /dev would ever be mounted but *not* be devtmpfs
<cjwatson> So won't mountall already get this right?
<slangasek> yeah, it appears so
<slangasek> I had to think twice about what the 'none' there meant
<cjwatson> Yeah, I'm having a hard time seeing how - either the kernel or a pathological initramfs would have to have done it
 * slangasek nods
<slangasek> or a pathological /etc/fstab overriding /lib/init/fstab
<cjwatson> Oh, well, if the kernel doesn't have devtmpfs, then it falls back to tmpfs
<cjwatson> I think that's what that code in the job is for
<slangasek> but does it make sense to install makedev on all machines to cater to that?
<cjwatson> devtmpfs is still optional, of course
<cjwatson> No, I don't think so
<cjwatson> Well, the failure mode is unfortunate of course
<cjwatson> Do Debian kernels all have devtmpfs nowadays?
<cjwatson> slangasek: So, how about this, simpler option
<slangasek> I don't know if they all have devtmpfs, but surely any that don't must cope with the makedev requirement some other way
<slangasek> given that it's prio: extra
<cjwatson> slangasek: Ship /lib/mountall/devices/ or some such, which is a bit like /lib/udev/devices/, only this one contains the output of 'MAKEDEV std console fd ppp tun' and is only used in the non-devtmpfs case
<cjwatson> Then you can just copy it, and it's a lightweight runtime requirement
<slangasek> hmm
<slangasek> that risks skew with the output of the makedev command
<slangasek> and I'm still not sure why it should be needed at all on a recent system (Debian or Ubuntu)
<cjwatson> Homebrew kernels
<slangasek> but nothing's doing this in Debian today
<slangasek> there's no equivalent to that job in Debian
<cjwatson> In the sysvinit case?
<slangasek> yeah
<cjwatson> Maybe udev deals with it ...
<slangasek> I believe it does
<cjwatson> If it's being dealt with somehow, I'm certainly in favour of ditching the mounted-dev code, but it would be nice to know how
 * slangasek nods
<cjwatson> There's /etc/udev/links.conf
<cjwatson> (In Debian)
<cjwatson> Which is read a couple of layers deep by /etc/init.d/udev
<cjwatson> With Upstart, the question is whether that's early enough, because it's possible for other things to start between mounted-dev and udev
<cjwatson> OTOH if you don't have a /dev/{null,console} then Upstart can't start any jobs
<cjwatson> Anyhow, I think it is pub time
<slangasek> yes; udev isn't started until "virtual-filesystems" are up, and things may assume that includes MAKEDEV std
<slangasek> but we already don't work with initramfsless kernels because of the /dev/pts issue... I'm not sure that requiring users to hand-install makedev if they use a devtmpfsless kernel is really an issue
<hallyn> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal A2 prep | Archive: please use -proposed | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: hallyn
<ScottK> jelmer: Are we going to have a fix for Bug #1014570  soon?
<ubottu> Launchpad bug 1014570 in bzr (Ubuntu Quantal) "bzr: Unable to sign commits: "no terminal at all requested"" [High,In progress] https://launchpad.net/bugs/1014570
* ChanServ 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: hallyn
<pgraner> ogasawara, ppisati, ogra_ : the new kernel linux-image-3.4.0-202-omap4_3.4.0-202.7_armhf.deb works just fine
<ogasawara> pgraner: cool, I'm prepping the upload on behalf of ppisati right now
<pgraner> ogasawara, great, appreciate it
<infinity> ev: I forget, did I leave an HDMI/DVI-D cable in London, believing it was yours?
<infinity> ev: If so, turns out it's vorlon's. ;)
<ogasawara> skaet: re: omap4 kernel ^^, do you want me to upload that straight to the quantal release pocket or -proposed?  Right now I have it (and the meta package since it's an ABI bump) going to -proposed.
<infinity> pgraner / ogasawara: Yay.
<infinity> ogasawara: Proposed, if you plan to push the meta at the same time, release if you're willing to wait on the meta.
<ogasawara> infinity: I like firing both to -proposed since I can do both at the same time
<skaet> infinity,  have you cleaned out the others from proposed?
<ogasawara> infinity: it just makes more work for you to then pocket copy
<infinity> ogasawara: Yeah, it's much simpler.
<infinity> ogasawara: The pocket copy isn't really effort.
<infinity> skaet: Still carefully going through the list.  Not copying things that are broken, etc.
<ogasawara> infinity: ok cool, I'll fire off to -proposed then
<infinity> skaet: But if you want a count of how many things are in proposed, go count before I do. :)
<infinity> skaet: And add a few for the things we uploaded and subsequently copied/deleted during the freeze.
<skaet> infinity,  fair enough.   if you want it in proposed,  that's fine.
 * skaet goes to count
<mterry> hallyn, heyo!  If you're not busy with other stuff, I've got a couple branches I'd appreciate a review on.  https://code.launchpad.net/~mterry/ubuntu-release-upgrader/pkexec/+merge/112638 and related https://code.launchpad.net/~mterry/update-manager/pkexec/+merge/112639
<mterry> br
<mterry> brb
 * skaet counts it at 90 packages in -proposed. ;)
<hallyn> mterry: taking a look
<hallyn> mterry: changelog says "Implementation of "update on start" feature from spec https://wiki.ubuntu.com/SoftwareUpdates", but i don't see mention of that at that url
<mterry> hallyn, that's not part of these branches, that's already in trunk.  But the spec mentions that when you start update-manager, it should do an apt-get update (unlike precise's version which had a Check buton)
<hallyn> d'oh
<hallyn> mterry: i'm afraid it's almost all above my head, but paging through the diffs i didn't see any problems
<mterry> hallyn, yar, I suppose I just need a "did I do anything stupid" check
<mterry> hallyn, well, just mark 'em approved if you don't see anything crazy.  Thanks for looking them over!
<hallyn> mterry: will do, my pleasure
<hallyn> mterry: a q on this - i take it htat pkexec is generally meant ot supplant gksu everywhere now?
<mterry> hallyn, that's the idea
<hallyn> (just for my education)
<hallyn> ok.  (that really means, more than ever, i want to go look at policykit source one of these days :)
<hallyn> thanks :)
<hallyn> SpamapS: whenever you get a chance, could you look over https://code.launchpad.net/~serge-hallyn/ubuntu/quantal/pulseaudio/pa-upstart/+merge/112650  (which addresses previous review comments by you against my same branch for precise) ?
<SpamapS> hallyn: ACK, will try to get to it today, running quite behind tho
<hallyn> SpamapS: thanks, no real hurry (i've taken my own sweet time)
<ev> infinity: I'll have a look
<infinity> ev: No big deal if you have it, it's not worth shipping it around the world.  Just curious, cause I don't think I have it. :)
<infinity> ev: Unless you want to give it to xnox to give to vorlon.
<infinity> xnox: You're coming to Debconf, right?
<xnox> infinity: yeap, what's up?
<xnox> infinity: something related to what ev is going to look at?
<infinity> xnox: I stole one of slangasek's cables and then left it on ev's desk.  I think. ;)
<xnox> infinity do I get to charge you 1st Class Royal Mail stamp for the service?
<infinity> xnox: Sure.  I'll buy you a Nicaraguan beer.
 * xnox drinks *cider*
<ev> yeah, it was in my suitcase. I think I brought it to UDS to give back to you
<infinity> ev: Hahaha.
<xnox> ev: and safely took it back? =)
 * xnox the world-wide cable, eh? =)))))
<ev> cider? http://www.uniteddairy.com/htmlimages/Product_photos/Apple%20Cider/United_AppleCider_gallon.jpg
<ev> xnox: indeed
<xnox> ev: can I come in and work from the 'office' next week?
<xnox> for a day
<ev> xnox: you're welcome to work from the office whenever you want
<ev> we have hot desks for such things
<infinity> slangasek: So, xnox will be bringing you your cable, via ev. ;)
<hallyn> gah i truly despise the 'progress info' on a bzr branch
<slangasek> xnox, ev: don't go too far out of your way, I can just order a new cable :P
<infinity> slangasek: This way's more fun.  Shush.
<slangasek> yes, but I think one or more of you have actual work to be doing
 * infinity fixed an FTBFS while coordinating that.
 * ev did absolutely nothing
<slangasek> xnox, ev: let me know if I should order myself a new one
<hallyn> hm, something i'm not clear on.  if i'm doing UDD for a SRU (merging someone else's bzr tree), can i push to lp:ubuntu/release/package immediately, or do i just build and dput the package to -proposed and skip the udd steps?
<slangasek> hallyn: the latter
<slangasek> which is why I have an action item to document that UDD is not worth doing for SRUs because of the confusingness
<hallyn> slangasek: sort of too bad, but expected.  thanks.
<hallyn> slangasek: yeah... though it does give a nicer trail while the patch is being considered (at least through patch pilot process)
<slangasek> to some degree
<slangasek> but creating the UDD branch in the first place is problematic
<slangasek> because do you base it off precise, or precise-updates, or precise-proposed, or...?
<hallyn> precise gets updated by precise-updates right?  but yeah, right, -proposed gets lost, good point
<hallyn> slangasek: thanks
<hallyn> heh, here's hoping i didn't mess that up
<xnox> ... or precise-security if it currently diverged from the current -proposed....
<hallyn> nope, looks good
<hallyn> xnox: right
<hallyn> cyphermox: hi, on https://code.launchpad.net/~poliva/ubuntu/precise/wpasupplicant/fix-for-994739/+merge/106704 you comment "i will take care of this in the merge".  Does that mean that branch is handled (in terms of sponsoring)?  you'll definately merge that?
<cyphermox> yes, I'm about to upload it
<hallyn> cyphermox: great, i'll keep my hands off then, thanks :)
<cyphermox> np; sorry for the trouble ;)
<cyphermox> hallyn: I'm also looking at freerdp
<hallyn> paulliu's branch?
<micahg> cjwatson: when you get a chance, MoM seems broke again (apologies if you've already been told or know)
<cjwatson> micahg: thanks, hadn't realised, will take a look ASAP
<hallyn> @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:
<Daviey> http://lists.gnu.org/archive/html/grub-devel/2012-06/msg00093.html .. thought it would never happen!
<cjwatson> micahg: Should be fixed for the next run, I think.  MoM gets upset when packages fail to unpack.
<cjwatson> I'll check back tomorrow morning.
<micahg> cjwatson: ah, ok, thanks
#ubuntu-devel 2012-06-29
<pitti> Good morning
<infinity> Good night
<dholbach> good morning
<dholbach> hey mvo
<infinity> mvo: Are you planning to upload your FTBFS fixes for command-not-found soon?
<infinity> mvo: I was going to just release your current bzr head, but wasn't sure if maybe you were waiting to fix something else first.
<mvo> hey dholbach
<mvo> infinity: sorry, got distracted by various things, the ubuntu branch is close, but not quite there I think, the amount of fiddling needed to build py3 is higher than I expected (in my little naive ways)
<infinity> mvo: Ahh, kay.  I'll leave you to it, then.
<infinity> mvo: Or you can always punt to barry in his morning. ;)
<mvo> infinity: yeah, thanks, I have a look in a bit though
<cjwatson> mvo: I'm having a look now
<vibhav> Is there any place where there are applications which have to be transitioned to gcc 4.7 ?
<cjwatson> vibhav: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian-gcc@lists.debian.org
<vibhav> cjwatson: Any Ubuntu specific page?
<cjwatson> vibhav: Not that I know of; it would probably be harmful to diverge effort on this kind of thing
<vibhav> cjwatson: ah
<vibhav> anyways, thanks
<mvo> cjwatson: great, thanks
<cjwatson> mvo: (almost done, just test-sbuilding)
<mvo> \o/
<cjwatson> mvo: Try r169?
<mvo> cjwatson: looks good, but running it for real on the installed system fails because bash needs a update (it hardcodes /usr/bin/python) I will fix that next
<cjwatson> Oh seriousy
<cjwatson> I thought I'd fixed that
<mvo> maybe I didn't update recently, let me double check
<cjwatson> Yeah, I did
<cjwatson> You didn't just copy the new binary into place or something?
<cjwatson> Upstream r151.2.21
<cjwatson> Unless there's something lurking somewhere else
<mvo> cjwatson: grep -A15 command_not_found_handle /etc/bash.bashrc
<mvo> cjwatson: you use zsh, I assume?
<cjwatson> Argh!  Why is there another copy of that?
<mvo> cjwatson: I don't know
<cjwatson> No, I use bash, but I foolishly assumed that bash_command_not_found in the command-not-found source might be canonical :-P
<cjwatson> How about I go and fix bash
<mvo> sounds good to me!
<cjwatson> No excuse for hardcoding the interpreter there
<cjwatson> Do we need a Breaks then or something?
<cjwatson> Also this means that we might need to expect that old conffiles will stick around
<cjwatson> Should we check for Python 2 and re-exec with Python 3, or something?  At least if 'import apt' fails?
<mvo> cjwatson: its a bit odd, bash_command_not_found seems to not get installed, maybe worth checking with doko_ why its put into the bash package instead of via profiles.d
<cjwatson> Packages aren't permitted to rely on profiles.d
<cjwatson> That was a condition of adding that directory
<mvo> cjwatson: I see, its used by some stuff currently (byobu for example)
<cjwatson> Non-policy-compliant :)
<mvo> :)
<cjwatson> LC_BYOBUâ½
<cjwatson> For crying out loud
<cjwatson> $ sudo apt-get purge byobu
<mvo> isn't it in our default install?
<cjwatson> Maybe, I wouldn't have installed it manually
<mvo> cjwatson: re reexec> that is probably a good idea
<cjwatson> Hm, python-apt is only imported way down the stack
<cjwatson> I kind of feel uncomfortable about completely forcing python3, but maybe I should get over it
<Daviey> it shouldn't be default in desktop, or server.. it is in server-ship.. and installed by default on cloud images.
<cjwatson> It was default at one point
<Daviey> Hmm.. it was a recommends of screen for a while.
<cjwatson> mvo: How about http://paste.ubuntu.com/1065724/ ?
<mvo> cjwatson: yeah, that looks reasonable
<mvo> cjwatson: shall I merge/upload or are you on it already?
<cjwatson> mvo: Please go ahead, I'd blocked out some time to catch up on Debian TC stuff and I'm already half an hour late :)
<jml> hallyn: hello. I came across http://permalink.gmane.org/gmane.linux.kernel.containers.lxc.general/3724 recently (bug in initscripts.postinst preventing dist-upgrade inside lxc containers). Was just wondering if there's a LP bug for it?
<mvo> cjwatson: sure, thanks a lot for your help!
<jml> hallyn: I've found https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/891045, but that seems to run counter to stgraber's suggestion that you were working on it.
<ubottu> Launchpad bug 891045 in sysvinit (Ubuntu) "initscripts: upgrade fails in chroot" [High,Confirmed]
<mvo> cjwatson: I will also ensure that we have a fresh data extraction now that I no longer reply on rookery for the generation
<cjwatson> mvo: Right, I noticed, thanks
<xnox> is it just me or did dch stop updating maintainer trailer line?
<tumbleweed> it did, DEBCHANGE_RELEASE_HEURISTIC=changelog is now the default
<tumbleweed> see your nearest NEWS.Debian.gz
<pitti> tumbleweed: ooh, is it? niiiiiice!
<pitti> DEBCHANGE_MULTIMAINT_MERGE=yes as well by any chance?
<tumbleweed> if only :)
<xnox> tumbleweed: but it's just wrong....
<xnox> http://paste.ubuntu.com/1065763/
<tumbleweed> xnox: throw a -r in
<xnox> notice how it creates a *new* changelog entry with *not my name*
<xnox> tumbleweed: Only one of -a, -i, -e, -r, -v, -d, -n/--nmu, --bin-nmu, -q/--qa, -R/--rebuild, -s/--security, --team, --bpo, -l/--local is allowed;
<tumbleweed> ah
<xnox> i almost "sponsored" some packages
<seb128> xnox, sponsoring is good, it makes dholbach happy ;-)
<Sweetshark> cjwatson: http://paste.ubuntu.com/1062452/plain/ gives me "Not enabled for copying to PPAs yet."
<cjwatson> Sweetshark: Oh, bah, I forgot about that
<dholbach> xnox, go go go go go!
<xnox> infinity: why did you break dch?  `dch -R --distribution quantal -m 'No change rebuild'` produces a maintainer line on the new changelog.... same as the TIL person instead of me.
 * dholbach hugs seb128 and xnox
<seb128> xnox, btw can you run the command I pointed on bug #1018021 ?
<ubottu> Launchpad bug 1018021 in desktop-file-utils (Ubuntu) "promted about changes in /etc/gnome/defaults.list when I never touched it" [Medium,Incomplete] https://launchpad.net/bugs/1018021
 * seb128 hugs dholbach back
 * xnox gigles
<tumbleweed> xnox: it works just fine for me on Debian
<xnox> tumbleweed: =(
<cjwatson> Sweetshark: That might actually be fixable because I don't think the reason that was disabled is valid any more, but I'll need to do some testing
<cjwatson>             # We have no way of giving feedback about failed jobs yet,
<cjwatson>             # so this is disabled for now.
<cjwatson> But I think we actually do now
<xnox> seb128: i think I do have a few non-policy compliant non-free packages installed....
<tumbleweed> xnox: err, no that was due to my configuration. but it did use my name+email
<xnox> tumbleweed: name+email or DEB_* name & email?
<tumbleweed> xnox: don't follow
<seb128> xnox, right, is one of those messing up with the conffile? in which case I will happily NOTMYISSUE your bug ;-)
<xnox> seb128: not now, but how would I know? I have installed and purged acroread in between. Deffo mark it as invalid due to a bug in non-ubuntu package
<seb128> xnox, acroread is known as having this bug so yes I will close as invalid, thanks
<xnox> seb128: thank you for looking after the bug, and pinging me.
<xnox> and sorry for the noise ;-)
<seb128> xnox, yw ;-)
<seb128> no worry ;-)
<Sweetshark> cjwatson: are you enableing it?
<cjwatson> Sweetshark: I'll look at it, although timescale will be (at best) more like days than minutes
<Sweetshark> cjwatson: the alternative is hugging amd64 and i386 buildd for 2*6hours ;)
<Sweetshark> cjwatson: ok, its buildd hugging then.
<cjwatson> Well
<cjwatson> (ITYM hogging)
<cjwatson> I wonder if I can do anything with copy-package.py
<cjwatson> Sweetshark: Can you tell me exactly what you want copied from where to where?
<cjwatson> I might be able to administratively intervene
<Sweetshark> cjwatson: the two "libreoffice" packages from https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-quantaltest-20120601 to https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases
<cjwatson> Sweetshark: So that's for precise and quantal?
<Sweetshark> cjwatson: (and I mean hogging, but hugging sounds so much more friendly)
<Sweetshark> cjwatson: yes.
<Sweetshark> cjwatson: yes (precise and quantal)
<Laney> Hmm, wouldn't the PPA web UI for copying work here?
<AlanBell> dhcp3-client dhcp3-common grub-common grub-pc grub-pc-bin grub2-common would seem likely to be the offending updates
<AlanBell> sorry, wrong channel (but precise machines are breaking today)
<cjwatson> Laney: No, the asynchronous mode is currently disabled and the synchronous mode times out
<cjwatson> Laney: I'm fixing this (by re-enabling the asynchronous mode and deleting the synchronous mode), but not on the timescale Sweetshark needs
<Laney> I see, so using copyPackage via API is to work around UI timeouts
<cjwatson> Yes - except that it's disabled for copies to PPAs
<cjwatson> So copy-package.py is the only remaining option
<cjwatson> lp_archive@cocoplum:~$ copy-package.py -p bjoern-michaelsen --ppa-name libreoffice-quantaltest-20120601 --to-ppa libreoffice -s precise --to-ppa-name libreoffice-prereleases --to-suite precise -b libreoffice
<cjwatson> lp_archive@cocoplum:~$ copy-package.py -p bjoern-michaelsen --ppa-name libreoffice-quantaltest-20120601 --to-ppa libreoffice -s quantal --to-ppa-name libreoffice-prereleases --to-suite quantal -b libreoffice
<cjwatson> Sweetshark: Done
<cjwatson> (Er, slightly odd option ordering there, never mind)
<Sweetshark> cjwatson: thanks alot!
 * Sweetshark bows galantly to cjwatson.
<Sweetshark> ;)
<cjwatson> Sweetshark: So, er, the set of people who can do this is not easy to enumerate because it's the subset of ~ubuntu-archive who have shell accounts on cocoplum - feel free to just ask me if you need this done again, and I'll consider it as impetus to get something better working
<Sweetshark> cjwatson: ah, motivattion by annoyance! ;)
<Sweetshark> cjwatson: yes, will do.
<cjwatson> It's powerful
<Sweetshark> cjwatson: we should write a book about it -- after TDD, XP, pair programming: annoyance-driven development
<cjwatson> So, let's see - copy-packages-with-default-series has landed, so I could maybe upgrade dogfood, flip that feature flag, construct something that will fail to copy, and see if it shows up on the PPA page
<cjwatson> I think I should finish the other thing I was doing first :-)
<infinity> xnox: I did nothing to break it, that behaviour was broken before I got to it.
<xnox> infinity: hmm... ok
<jdstrand> @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: jdstrand
 * dholbach hugs jdstrand
<xnox> jdstrand: please review py3 port of apport.... =)
<jdstrand> heh
<jdstrand> I'll see what I can do
<seb128> xnox, isn't apport already py3 compliant in quantal for a while?
<vibhav> xnox: Arent you a core devel?
<xnox> seb128: there is ongoing confusion between me, pitti, ogra_  and now you. when I say apport, I meant *apparmor*.
<seb128> xnox, hehe, makes sense now ;-)
<xnox> for some reason we use the two names interchangeably given the context
<vibhav> jdstrand: Could you have a look at https://bugs.launchpad.net/ubuntu/+source/dbus-java/+bug/1019178 ?
<ubottu> Launchpad bug 1019178 in dbus-java (Ubuntu) "Please merge dbus-java (2.8-3) from Debian Unstable" [Undecided,New]
<jdstrand> xnox: ahh!! that makes much more sense. I will gladly look at that :)
<xnox> and somebody always pops up and 'hey what do you mean the other one'
<xnox> jdstrand: as part of piloting ;-)
<ogra_> yeah, we should rename them to iSecurity and iShield :) "App" is so worn out already
<vibhav> ogra_: hah
<jdstrand> xnox: yes-- convenient for me indeed :)
<vibhav> ogra_: Wouldnt that sound too "Applish" ?
<ogra_> you mean AppArmor and AppOrt dont ?
<seb128> ogra_, wrong letter, we are "u" around, uSecurity and uShield
<ogra_> oh, indeed !
<seb128> ;-)
<vibhav> I dont think apple invented the word "app"
<vibhav> We should have a slogan like "There is a .deb for that" or something :P
<ogra_> well, microsoft didnt invent the word "windows" either
<vibhav> s/we/debian based distros/
<xnox> seb128: isn't it ufw should be named uShield
<ogra_> (and stil they called their OS after a hole in the wall ...)
<seb128> xnox, indeed!
<vibhav> "If you want to $VeryComplexAction , there is a deb for that!" :D
<Chipzz> vibhav: except I wouldn't use the word .deb .. most users don't care about the unerlying technology
 * hyperair likes how apple and amazon fought over the "app store" term, which is so generic it's laughable.
<hyperair> "i'm sorry, but i trademarked the toothbrush. you can't call your toothbrush a toothbrush any more."
<vibhav> hyperair: haha
<vibhav> ".deb store" sounds pretty good too
<hyperair> but nobody knows wtf a .deb is
<hyperair> at least not new users
<hyperair> they'd be like "i've got this setup.exe, how can i install it on ubuntu?"
<vibhav> mm
<hallyn> jml: bug 891045 is a dup of bug 974584, which is where that one was being handled
<ubottu> Launchpad bug 891045 in sysvinit (Ubuntu) "initscripts: upgrade fails in chroot" [High,Confirmed] https://launchpad.net/bugs/891045
<ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584
<hallyn> jml: it's being handled through the debian bug now
<hallyn> jml: oh, wait, now...  that's an *upgrade* in a chroot, not the debootstrap.  in the end there is only so much we can do to handle existing setups, but i do think that one will be handled by the fix to bug 974584.  i*think*
<ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584
<hallyn> can't decidewhether to mark it a dup or not
<jml> hallyn: thanks.
<jml> hallyn: so, AIUI, the precise task on sysvinit will be marked "Fix Released" when the fix is available in precise?
<hallyn> jml: hm.  no, i thought it was going to not be fixed in precise, because in precise it was worked aroudn in lxc.
<jml> hallyn: hmm.
<hallyn> jml: since it affects others, not in lxc, i guess it will need to be srud after all
<jml> hallyn: I'm no expert. This is being driven by #juju's recommendation that I put "rmdir /dev/shm; ln -s /run/shm /dev/shm" as per http://permalink.gmane.org/gmane.linux.kernel.containers.lxc.general/3724 so I can run 'apt-get dist-upgrade' without the whole thing falling over.
<hallyn> jml: right, see that's a different problem :)
<hallyn> a simpler one - that gets messed up in debootstrap,
<hallyn> where the chroot hasn't had a chance to get messed up
<hallyn> the 'upgrade in chroot' is more complicated, because who knows what shape the chroot is in
<hallyn> that's why i'm torn on whether to mark the one a dup of the other or not
<jml> hallyn: hmm. ok.
<jml> hallyn: mostly what I want is a URL I can put above that work-around in a comment that says "look at this URL. If it says 'Fixed', try removing this kludge and see what happens."
<hallyn> jml: oh i decided to mark it a dup anyway, bc it shoudl remove that warning
<jml> hallyn: cool, thanks.
 * apw looks for an archive admin to stroke a linux-lowlatency kernel in quantal
<hallyn> say, is usb-creator-gtk supposed to be friendly with quantal iso's right now?
<hippiehacker> anyone have an example of what oem-config oem-config/repository should be set to?
<hippiehacker> trying to seed an oem run
<zul> can an archive admin review python-swiftclient please?
<xnox> cjwatson: ^^^ hippiehacker
 * apw looks for an archive admin to stroke a linux-lowlatency kernel in quantal
<cjwatson> xnox: I have no context; my network connection dropped
<xnox> <hippiehacker> anyone have an example of what oem-config oem-config/repository should be set to?
<xnox> <hippiehacker> trying to seed an oem run
<xnox> cjwatson: ^^^
<cjwatson> hippiehacker: It's just the same format as a single line in sources.list
<saurabh> Hello. Can somebody tell how can we import webkit python module into ubuntu
<saurabh> its giving an import error
<saurabh> says "no module named webkit"
<saurabh> anybody?
<ScottK> Do you have the package python-webkit installed?
<dobey> saurabh: you should use the gi bindings
<cjwatson> ... i.e. 'from gi.repository import WebKit'
<cjwatson> (Install python-gi or python3-gi as appropriate, and gir1.2-webkit-3.0)
<saurabh> I have tried using gi bindings but its gives an error too
<cjwatson> Then say what that error is
<saurabh> just a moment, I will post here
<saurabh> ImportError: could not import gobject (error was: ImportError('When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject".',))
<stgraber> saurabh: from gi.repository import GObject
<cjwatson> Right, as he says.  You can't mix and match old and new style.
<saurabh> let me try
<cjwatson> In general if an error message gives you explicit instructions on what to do it's probably a good idea to at least try those instructions before asking :-)
<saurabh> its still giving an error
<saurabh> ImportError: cannot import name _API
<cjwatson> That sounds like something specific to your code
<cjwatson> Perhaps post it to a pastebin
<saurabh> I tried this "from gi.repository import Webkit"
<saurabh> what does this mean "ERROR:root:Could not find any typelib for Webkit"?
<cjwatson> WebKit not Webkit
<cjwatson> The capitalisation matters
<saurabh> ok
<saurabh> I think, its working now...
<saurabh> thanks guys :)
<cjwatson> you're welcome
<slangasek> didrocks: heya, why exactly is compiz-plugins using a deprecated version of libjpeg?
<slangasek> didrocks: (libjpeg62 vs libjpeg8)
<didrocks> slangasek: hey, I think there is no actual reason. I can do a test with the newer version and see what happens
<slangasek> didrocks: would appreciate it :)  This is actually a change in the latest upload, it was using libjpeg8 before
<didrocks> slangasek: well, as you can see the latest upload is merging 8 sources in one
<didrocks> slangasek: so when merging the build-dep, I tried to be on the safe side and picking the lower one :)
<slangasek> ah
<didrocks> but let me see with the newer one ;)
<mterry> ScottK, hello!  So the release-upgrade bits of update-manager-kde are shortly moving to ubuntu-release-upgrader-qt.  I'll update seeds, but just wanted to give a heads up
<mterry> ScottK, oh, the kubuntu seeds don't even use it...
<ScottK> mterry: Yes, but users do use it.
<ScottK> IIRC.
<mterry> ScottK, OK.  It's not dying, but sounds like I don't need to update anything except the archive.  Thanks!
<ScottK> mterry: It is a rdepend of muon-notifier.
<ScottK> That we do use.
<ScottK> mterry: That will need to be fixed.
<mterry> ScottK, OK.  update-manager-kde still exists, so I'll just see if muon-notifier is using the release-upgrader bits and fix accordingly if so
<ScottK> mterry: Here's our documentation on upgrading: https://help.ubuntu.com/community/PreciseUpgrades/Kubuntu
<ScottK> It looks like it does in fact use it for upgrades.
<ScottK> Also, personally I'm suprised the KDE bits are being removed.  Was this coordinated with anyone?
<seb128> [ -e $$i ] || continue; in a rules
<mterry> ScottK, sorry, nothing is being removed.  I'm just splitting out update-manager and release-upgrader stuff into two separate sources
<seb128> is there a way to extend the test to add a -L check while keeping the short version?
<mterry> ScottK, which package is calling do-release-upgrade in that documentation?  I can't see such a call in muon source
<ScottK> mterry: I don't know.
<mterry> ScottK, OK.  /me digs
<seb128> or do I need to change to a if [ -e ] && [ -L ]; then?
<ScottK> I imagine Riddelll does, but I don't think he's around.
<cjwatson> seb128: -L implies -e, except for the case of broken symlinks; does that matter?
<cjwatson> Otherwise, various options:
<cjwatson> ([ -e $$i ] && [ -L $$i ]) || continue
<seb128> cjwatson, yes, I want to include broken symlinks as valid
<cjwatson> [ -e $$i ] || continue; [ -L $$i ] || continue
<cjwatson> And you can probably do something with inverting both tests somehow but I don't think it'd be very clear
<seb128> cjwatson, thanks
<seb128> cjwatson, I messed up my parenthesis use when I tried what you listed first, yours works, thanks ;-)
<cjwatson> yw
<didrocks> slangasek: looks fine to me with the newer jpeg, uploading with that
<xnox> didrocks: 5 left to go!  http://people.canonical.com/~ubuntu-archive/transitions/libjpeg.html
<slangasek> didrocks: super
<didrocks> heh ;)
<BenC> hoorah, powerpc ftbfs is tied for first with amd64
<jdstrand> @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> BenC: Impressive
<ScottK> jelmer: I verified your bzr regression fix and will copy it to -updates as soon as it's built.  Thanks.
<PaoloRotolo> Hi all!
<smoser> hm..
<smoser> anyone able to explain this
<Daviey> smoser: unlikely
<smoser> i ran 4 instances of the cloud images on a openstack cloud.
<smoser> 2 were precise, 2 were quantal (alpha2)
<smoser> upon their coming up, ssh in and see how long the resize2fs to grow the filesystem took.
<smoser> http://paste.ubuntu.com/1066330/ is the results, and then results repeated at http://paste.ubuntu.com/1066365/
<slangasek> maxb: hi, do you know why sbsigntool (new package in quantal) doesn't show up as being in the importer queue? http://package-import.ubuntu.com/status/
<smoser> basically, resize2fs on quantal happens in very rougly 1/10 the time it did on precise.
<smoser> (it could be coincidence based on hosts IO performance)
<maxb> slangasek: hmm, I'll look. When was it published?
<cjwatson> e2fsprogs (1.42.2-1) unstable; urgency=low
<cjwatson>   * Speed up resize2fs for large file systems (Closes: #663237)
<xnox> smoser: quicker or slower? quantal has newer e2fsprogs
<cjwatson> smoser: ^-
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663237
<ubottu> Debian bug 663237 in e2fsprogs "e2fsprogs: [patch] Make resize2fs shrinking use much less CPU" [Normal,Fixed]
<smoser> quantal is faster.
<cjwatson> Now that says shrinking; don't know if it's related
<xnox> smoser: there is SRU in unapproved with latest e2fsprogs, such that it is in the pipeline for prcise
<smoser> utlemming, ^
<utlemming> interesting
<smoser> cjwatson, well, the changelog entry is "Speed up resize2fs for large file systems". i wouldn't exactly think of a resize from 1.4G -> 10G to be "large"
<smoser> but it explicitly does not mention the shrink.
<smoser> so that certainly sounds like a hit.  and a very nice bug fix.
<smoser> i had always just assumed that it was IO that was limiting.
<mterry> bdmurray, jibel: hey folks, just FYI that there is a new source package you may care about.  ubuntu-release-upgrader, which holds some code pulled from update-manager
<mterry> (in terms of bug subscriptions and such)
<cjwatson> smoser: I'm only making an educated guess, but it seems like a good place to start looking if you care to look into it further
<smoser> cjwatson, nah. it seems like a *really* good guess.
<smoser> and i'm happy to have something run 10x faster
<cjwatson> I was going to say, it's not normally the sort of thing you'd complain about. :-)
<smoser> and xnox you're implying that htat is going to come back to precise for me too?
<smoser> that makes it even nicer.
<Laney> xnox: meet cyphermox. Someone else who is interested in teaching ben about proposed :-)
<xnox> smoser: yes. If you have capacity to test big data filesystems and comment on the bug 978012 that would be nice. ps. big filesystem is >16TB
<ubottu> Launchpad bug 978012 in e2fsprogs (Ubuntu Precise) "Please SRU micro bug fix release of e2fsprogs 1.42.4-3ubuntu1 (main) from Quantal (main)" [High,Confirmed] https://launchpad.net/bugs/978012
<xnox> utlemming:  smoser: yes. If you have capacity to test big data filesystems and comment on the bug 978012 that would be nice. ps. big filesystem is >16TB
<utlemming> xnox: well, I think I have a spare PB array under my desk :)
<utlemming> xnox: but in all seriousness, you could create one on EC2...might be a bit spendy though
<xnox> utlemming: PB array you say, is it RAID? =) cause testing things like mdadm on PB would be great!
<xnox> I will check if I can get the expenditure for EC2
<smoser> utlemming, on ec2, volume slimited to 1TB
<smoser> so gettin to 16 would require raid across 16 of them.
<utlemming> smoser: right
<utlemming> smoser: you'd have to LVM or mdadm it
<smoser> right.
<xnox> ok
<smoser> xnox, but you could do it. and the cost is $0.10/GB Month.
<smoser> so if you only had it up for 1 day, 0.10 * 16 * 1024 / 30 = ~ $54
<smoser> oh, i wonder if htere is a max volumes per account by default though.
<xnox> smoser: does it charge per day though?
<xnox> or per month for storage?
<utlemming> per month, but the average of the month
<utlemming> which is why it would only cost $54
<smoser> and potentially cost $0.0
<xnox> define *average* =) as long as they take daily or hourly average
<smoser> if you happened to hit the accounting right
<xnox> I will check the accounting ;-)
<maxb> slangasek: I've been unable to determine why it happened (no logging from the script in question), but I've queued it manually
<utlemming> the problem is that allocating that much could take a few hours. I did a similiar test two years ago and it took about 3 hours for the volumes to be ready
<smoser> yeah. so, it is not going to be free.
<smoser> and then you'll also pay for IO, which i guess probably adds up on 16TB
<slangasek> maxb: ta :)
<smoser> http://serverfault.com/questions/336825/amazon-ec2-ebs-pricing-over-a-month-of-dynamically-allocated-space is relative
<smoser> relavent
<dylan-m> Hey, anyone know if 12.10 will have any symbolic icons? (A symbolic system-restart icon, in particular?)
<bdmurray> mterry: thanks!
<ahasenack> hi, could I get an sru sponsor to take a look at #1004678 please? Thanks
<ahasenack> bug #1004678
<ubottu> Launchpad bug 1004678 in landscape-client (Ubuntu Precise) "Please update landscape-client to 12.05" [Undecided,New] https://launchpad.net/bugs/1004678
<infinity> ahasenack: Do you not have a regular sponsor for landscape?
<ahasenack> infinity: not really
 * infinity notes that pitti did the last round.
<SpamapS> ahasenack: is there any reason you can't use the normal sponsorship queue?
<ahasenack> SpamapS: am I not?
<SpamapS> ahasenack: you are not when you ask for somebody to look at your item before others. :)
<ahasenack> ah, in that sense
<SpamapS> If its a critical update then that is perfectly acceptible.
<ahasenack> SpamapS: boss breathing on my neck, that's all
 * ahasenack -> dinner
<SpamapS> darn the wiki foiled my plan to show him that there should have been *4* patch pilots today
<SpamapS> https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
<xnox>  29/06 23:11:23 <rlb> fwiw, emacs24 has been uploaded to unstable
<xnox> barry ^
<Beret> SpamapS, it is blocking a release
<Beret> SpamapS, if it was a typical update, we wouldn't be bothering anyone
 * micahg figures landscape updates aren't the type of thing you'd want to push out at 5PM on Friday
<slangasek> generally not a concern for publishing to -proposed
<micahg> true, but the week would be up then as well though
<infinity> micahg: We're trying to do away with the concept of waiting exactly 7 days anyway.  But yes, publishing on a Friday should be a no-go, except in dire circumstances.
<ScottK> infinity: I think that philosophically that's counter to your arguments about milestones.  If our SRUs are so crappy we're afraid to release them on Friday, then the solution is to do better SRUs.
<infinity> ScottK: It's not so much about quality as least surprise.  Lots of people who aren't me don't work weekends, and Friday updates can leave people a bit confused about why they have 873 voicemails over the weekend.
<infinity> ScottK: While quality's the goal, mistakes always happen.  (I don't see how this relates to the milestone thing at all).
<infinity> ScottK: In fact, it seems in line with my milestone philosophy.  Pretending a milestone is perfect because people stopped for two days to make it is about as silly as pretending an SRU is perfect because 3 people tested it.  Reality isn't ever on our side there.
<geofft> cjwatson: did you see the UEFI Firmware Agreement from MS on the sysdev site? Looks like _it_ excludes GPLv3 bootloaders, so what FSF says is irrelevant :(
<infinity> geofft: Public URL for this?
<geofft> Hm, not sure there is one, let me save a copy
<slangasek> geofft: that refers to objects that Microsoft is willing to sign, for the same basic reason (they don't want to receive a court order forcing them to disclose their private keys)
<infinity> ScottK: So, absolutely, in both cases, jacking up quality (and QA) is the answer, but that doesn't mean you also tempt fate and release on a Friday. ;)
<geofft> Oh, hm, I guess it does mean that the shim bootloader is still fine.
<geofft> infinity: http://ldpreload.com/p/windows-logo-uefi-amendment.pdf
<slangasek> correct - RH has already solved that part
<slangasek> geofft: haha, why does that copy of the pdf crash evince?
<geofft> Well, it came to me as a pdfx, but file says it's a PDF...
<geofft> Works in evince on Natty, in any case. Also, uploaded a new copy that takes my company's name out
<geofft> since if I do something silly like post that PDF publicly, HN is going to link to it in 3, 2...
<ScottK> infinity: I think it depends a lot on the SRU.  KDE point release - sure, I agree.  Two line obviously correct fix that helps people out, I think you can go for it.
<ScottK> There are a surprising number of people the just run with -proposed enabled, so at least for common/core packages if you break it in any obvious way, you'll find out.
<infinity> ScottK: Discretion and common sense are always a factor, sure.
<ScottK> I agree with don't release scary ones on Friday, but I don't think it's a good general rule.
<infinity> ScottK: Well, I think we have too many "general rules", so I agree with you there.
<infinity> ScottK: While some parts of the process need to be vaguely rigid and formal, the aim of the "make things more agile" spec was to try to get people to think a little bit while they're doing their robotic tasks. :P
<infinity> Well, one of the aims.
<ScottK> I did accept some SRU's today.  In one case I actually went back and re-reviewed the diff to see if it was a good idea.
<infinity> ScottK: That said, I think micah's point about landscape being a poor choice for a Friday update may well be on point.
<infinity> ScottK: Given that the sorts of people who use landscape may we be exactly the same sorts of people who update and leave for the (long, in Canada) weekend, and come back to "oh god, wut?"
<infinity> s/may we/may well/
<ScottK> Personally I'm not that worried about regressions in clients to proprietary services, but I understand others may feel differently.
<infinity> ScottK: Heh.  Indeed.  It's what the client does that matters. ;)
<infinity> ScottK: (I'd have similar reservations about an upstream bump with a massive patch to, say, how ksplice works)
<ScottK> I'd have reservations just based on who owns it.
<infinity> You know, if we distributed the proprietary kplice client, which we don't.
<ScottK> Yeah.
<infinity> As opposed to, say, updating purple/telepathy, which is also a collection of client for proprietary services that have a much slimmer chance of wedging your computer when you're not looking.
<ScottK> Are they all proprietary?
<ScottK> (I haven't looked)
<slangasek> bdmurray: seems like bug #1019448 is the sort of thing that should've auto-duped
<ubottu> Launchpad bug 1019448 in compiz (Ubuntu Quantal) "package compiz-gnome 1:0.9.7.8-0ubuntu3 failed to install/upgrade: trying to overwrite '/usr/share/gconf/schemas/compiz-ccp.schemas', which is also in package libcompizconfig0 0.9.7.0~bzr428-0ubuntu7" [High,Triaged] https://launchpad.net/bugs/1019448
<slangasek> bdmurray: is there not support for matching on file conflicts in apport?  maybe it's not common enough to have been dealt with?
<slangasek> (they're certainly the sort of bug we should be able to triage with high-certainty and should treat as high priority)
<infinity> ScottK: XMPP can go both ways (see GTalk versus, say, private jabberd servers)
<ScottK> Right.
<infinity> ScottK: Most of the other services (AIM, ICQ, MSN, Yahoo, Twitter, etc, etc) are, of course, very proprietary.
<ScottK> For Kubuntu we're switching from Kopete to KDE telepathy for 12.10, so I haven't really experimented with it much.
<infinity> I'm happy to hear that tp-qt4 is actually, finally usable.
<infinity> I was involved in the initial tp-glib->tp-qt4 port/mangling (whatever you want to call it), and it was a mess for ages.
#ubuntu-devel 2012-06-30
<vibhav> Why is https://launchpad.net/ubuntu/+source/speech-dispatcher/0.7.1-6.1ubuntu1 uploaded to "quantal-proposed"?
<infinity> vibhav: Because it was uploaded to -proposed during the freeze.  It's since been copied to release.
<infinity> Note under publishing "Pocket: release".
<vibhav> infinity: Do you mean it was orignally uploaded to precise-proposed?
<infinity> vibhav: No, quantal-proposed.
<infinity> vibhav: During the Alpha2 soft freeze.
<infinity> Laney: So, once I got an upgraded kernel on an armel buildd, I confirmed my mono patch DTRT.  If you want to pull it back into Debian sometime for me.
<infinity> Laney: (It will have precisely zero effect on Debian buildds, but if Debian ever builds armel on armv6/armv7 hardware, the same bug will hit them)
<infinity> Laney: Might be good to get it in before the freeze, just in case someone upgrades the buildds post-release, and a security update explodes unexpectedly.
<vibhav> infinity: ah
<vibhav> What does NBS stand for in http://people.canonical.com/~ubuntu-archive/NBS/ ?
<vibhav> Ah got it
<vibhav> Nevermind
<vibhav> What does super-seeded mean?
<JontheEchidna> vibhav: sounds like a mispelling of superseded? (To have been replaced)
<vibhav> yeah, its superseeded. thanks JontheEchidna
<directhex> superseded. one e.
<vibhav> For some strange reason, my pbuilder chroot does cannot find the package "blends-dev" in the Ubuntu repositories, any Idean why?
<vibhav> idea*
<JontheEchidna> I'd check to make sure that universe is enabled in its /etc/apt/sources.list
<JontheEchidna> and/or run a sudo pbuilder update
<vibhav> Ill try uploading it to a PPA and see if it works
 * malkauns_ fires up his raspberry pi :)
<fossilet> I am the debian maintainer of the package 4digits. I would like the version in testing to be sync to 12.04. How is that possible?
<fossilet> It has a bug fix than the version in 12.04.
<ailo> fossilet: You could request a backport. I believe, apart of the ubuntu-dev-tools package there's requestbackport
<ailo> I'm currently doing that now with another package
<ailo> I uploaded it to PPA so I can test it first
<fossilet> ailo, Ok. I requsted sync, and it seems unapproriate
<ailo> fossilet: Yeah, requestsync is done for the development release, which is now 12.10
<fossilet> ailo: I must upload it to ppa and test in 12.04 then request that?
<fossilet> ailo: It is already in quantal though
<cjwatson> fossilet: https://wiki.ubuntu.com/StableReleaseUpdates
<ailo> fossilet: When you do requestbackport, you will come to a stage when you need to fill in some text. There is some info on what you can do to test the package, as well as explain why you want to backport it
<cjwatson> If it's a bug fix rather than new features, you want that process, not requestbackport
<ailo> cjwatson: Oh, that was new to me too
<fossilet> cjwatson: I was reading it
<fossilet> but do not know how to apply to this package..
<fossilet> In the 'procedure' section, it assumes there is already a bug repot for it
<fossilet> but there is for it
<fossilet> it is fixed in debian
<cjwatson> So create one
<cjwatson> We use bug reports to track verification of stable updates; it isn't optional to have one in Ubuntu, even if it's already been fixed elsewhere
<fossilet> cjwatson: Create for update request or bug fix?
<cjwatson> I don't know what you mean
<fossilet> cjwatson: create a bug requesting that package be updated in 12.04?
<ailo> cjwatson: How about if a new feature fixes a bug?
<ailo> Or, half-fixes it
<cjwatson> We don't generally just copy packages from unstable releases into stable releases, any more than Debian stable does.  Somebody should prepare an upload that backports just the bug fix
<fossilet> ailo: In my case, it is just a fix
<cjwatson> ailo: StableReleaseUpdates has guidance, I believe
<fossilet> Ok, I will file a bug now
<ailo> cjwatson: Well, in the case of qjackctl, since the bug is probably not regarded critical, and is really caused by jackd, but where qjackctl has a new feature which makes that bug easier to live with, I find that backport is probably the best choice
<cjwatson> I don't really want to think about the specifics on a Saturday morning :)
<cjwatson> just giving general pointers
<fossilet> https://bugs.launchpad.net/ubuntu/+source/4digits/+bug/1019533
<ubottu> Launchpad bug 4 in Launchpad itself "Importing finished po doesn't change progressbar" [Medium,Fix released]
<fossilet> I have file the bug.
<Daviey> Anyone else booted this morning with a broken X?
<RAOF> Daviey: Not me, but bah transitions; what driver?
<RAOF> infinity: You wouldn't happen to be around to give a pointer about getting a pandaboard to actually boot, after netinsting to a USB disc?
<tumbleweed> RAOF: he said something about going to sleep, in #ubuntu-release
<RAOF> tumbleweed: Ta.
<Laney> RAOF: try ogra_
 * Laney is using a dist-upgraded precise server preinstall for now
<Laney> maybe I'll venture out today to find a USB key
<infinity> RAOF: You didn't take the SD out, did you?
<infinity> RAOF: (the installer installs the bootloader and kernel to the SD)
<infinity> tumbleweed: I lied, apparently.
<RAOF> infinity: I did not take the SD out; it did, however, say at the end of the install âyou'll need to boot this thing manually, because ARM hardware sucks and we don't have a bootloaderâ.
<RAOF> Not in so many words, but that was the gist I gained from it.
<infinity> RAOF: Err, that's a filthy lie.
<infinity> RAOF: What media did you use to install?
<infinity> RAOF: I literally *just* did a precise/armhf netboot install to USB disk in the DC and it worked just fine.
<RAOF> http://ports.ubuntu.com/ubuntu-ports/dists/quantal/main/installer-armhf/current/images/omap4/netboot/boot.img-fb.gz is what I zcatted to the SD card.
<infinity> RAOF: Try precise.
<RAOF> Will do.
<infinity> RAOF: quantal's flash-kernel may still be goofy (if it is, that's an interesting datapoint, and I should check when it's not a long weekend)
<RAOF> There's no arcane ritual to be done to dist-upgrade from precise to quantal?
<infinity> RAOF: My recommendation is "don't, use chroots".
<RAOF> Or is the advice to *stay* on precise?
<infinity> RAOF: Unless your goal is actually testing X and such.  In which case, dist-upgrading SHOULD work, unless Oli broke flash-kernel horribly (see above).
<RAOF> Will do.
<infinity> I suspect I should test all of this next week.  Remind me. :P
<RAOF> Actually testing X and such is one of the purposes of this board, yes.
<infinity> To be fair, X is in a bit of a state of flux right now anyway, until we get a newer libdrm, a newer kernel, and a newer x-mumble-omap driver.
<RAOF> Just to confirm: I didn't need to do anything special in d-i to make this work, right? Just throw a / on a USB drive, and install?
<infinity> I'm led to believe by KiBi that the newer libdrm is potentially blocked on nouveau having been yet again broken or something.
<infinity> RAOF: Just hit enter lots.  The defaults should be fine (unless you want to manually partition for more swap or something)
<RAOF> nouveau broke libdrm ABI. But I think they did so while actually bumping SONAME, so that should work, I think.
<infinity> Oh, in that case, let's go to town!
<RAOF> âI'm smelling a lot of âifâ on this planâ
<infinity> New libdrm means I just need a kernel bump, and I can dump Rob's newer omap driver in and it might actually work.
<infinity> And we get KMS and other fancy crap on omap, which would be shiny.
<RAOF> All manner of shiny!
<infinity> And xrandr.  And, you know, welcome to 1999.
<infinity> "Wait, what, I don't need my monitor plugged in when I boot?"
<RAOF> :)
<infinity> To be marginally fair, I don't think anyone really thought through to the point where some crazy people would start using embedded CPUs as low-powered desktops.
<infinity> And it turns out that most embedded systems have the screen permanently attached.
<RAOF> Who'd've thought? :)
<infinity> Anyhow.  I should try to sleep again.  In theory, I'm going to be awake in 4 hours to drive out to some party in the mountains or something.
<infinity> RAOF: Do let me know if precise works for you.  The only difference between your install and mine is that I used serial instead of the fb image, but if the fb one is somehow broken, that's just not right.
<RAOF> Sleep-deprived driving. What could possibly go wrong?
<infinity> RAOF: (So, I assume it's just quantal that's broken)
 * RAOF grabs the precise fb one.
<infinity> Sleep-deprived driving for a couple of hours into the middle of nowhere.  Seems like a winning scenario.
<Laney> Precise desktop never got past resizing for me.
<Laney> preinstalled, etc.
<infinity> Laney: We're talking netboot.
<Laney> yeah, I should try that
<infinity> Laney: If resizing broke on preinstalled, the only thing to blame is the SD card.
<Laney> I tried two, but to be fair they were the same make/model
<infinity> Every SD sucks.
<infinity> Sadly.
<infinity> I'm so very tempted to drop all the non-netboot ARM images, and just provide a netboot image that happens to have a desktop preseed, and call it done.
<infinity> But I suspect people would whine about that.
 * Laney decides to go out climbing instead
<b33j0y> join #ubuntu_classroom
<b33j0y> quit
<ejat> bug 2011
<ubottu> Launchpad bug 2011 in Launchpad itself "malone doesn't know about network-manager" [Medium,Fix released] https://launchpad.net/bugs/2011
<BarkingFish> Good afternoon guys. I wonder if you could help me, since I can't seem to find this on launchpad.  There is a gent in #ubuntu asking about a problem with OpenSSH 5.9p1 - i googled and found a bug which could be causing his issues, I can't find a launchpad report on it though.  Any ideas?
<BarkingFish> He's upgraded from 5.3p1 to 5.9p1, and from what I can see, this appears to have been present since 5.8p1
<BarkingFish> http://www.gossamer-threads.com/lists/openssh/dev/51339
<penguin42> hmm, this PDF has just printed a last page which says that it's printed using vegetable oil based inks on paper which is Forest Stewardship council certified - almost certainly isn't
<Daviey> RAOF: fglrx / ATI non-free
<infinity> Daviey: Oh, did the new xorg ABI break fglrx?
 * infinity isn't surprised.
<slangasek> yes, that happens every time there's a video driver ABI bump
<Daviey> infinity: it's beena little sketchy since linux 3.5.. but X now segfaults since the new xorg.
<infinity> \o/
<Daviey> slangasek: every time.. why isn't this avoidable ?
<infinity> You can, perhaps, blame me.  I went through the list of drivers in proposed and it looked complete.  Cause, well, I didn't even think to check the non-free ones.
<penguin42> the open Radeon driver is now working again in qq for the cards that are happy
<slangasek> Daviey: um.  because they're binary drivers?
<infinity> Daviey: Any chance the free driver works?
<slangasek> so when the binary interface changes and the driver doesn't, the driver breaks
<Daviey> infinity: Seems to now...  I've only recently gone back to ATI, and Precise required non-free
<infinity> nvidia's usually gotten around this by being so dangerously xserver-agnostic that, on the one hand, it rarely breaks, but on the other hand, it can't integrate for crap and needs to reinvent every X feature it wants.
<Daviey> slangasek: right.. but surely we can handle this a little more gracefully ?
<infinity> But fglrx plays "nicer", which means it breaks harder.
<infinity> Daviey: Well, the only grace we can exercise is "never upgrade X until AMD catches up", which isn't really a pleasant way to do development either. :/
 * infinity goes to look upstream to see if they've already fixed this and we just forgot to rev the driver.
<Daviey> I specifically questioned this aspect with the 'daily stability', and was told that if we break non-free, we'd still roll back.
<infinity> Oh look, something was released two days ago.
<slangasek> Daviey: really?  Because that's inconsistent with the desktop team's policy on binary drivers for years
<infinity> And the kernel team.
<Daviey> slangasek: right, that is why i raised it..
<infinity> In fact, especially the kernel team.
<slangasek> raised it with whom?
<infinity> Binary drivers break against new kernels every 20 minutes.
<Daviey> slangasek: UDS session about daily stability, Rick responded.
<slangasek> hmm
<slangasek> were the X maintainers in there? :)
<Daviey> NFI :)
<slangasek> so it's not realistic to wait for the binary drivers to be available before updating the X server
<slangasek> we've waited months at a time for binary driver updates
<Daviey> I raised this specific issue, as Natty cycle left me burned for about a month via Nvidia.
<Daviey> slangasek: yeah, i can see the pain here.. I wonder if it was known poor Daviey would be left X-less this morning when it was upload.
<slangasek> you said the free drivers worked, once you rejiggered?
<slangasek> if so, that suggests an integration bug with the binary driver packages
<slangasek> things should automatically un-configure themselves on ABI change
<Daviey> slangasek: Yeah, seems the free drivers now support this chipset.. So i'm pleased that it forced me to try the free ones again. :)
<Daviey> Although, X is lost on resume.. but i can live with that for now.
<slangasek> so please file a bug against the fglrx package about the fact that your config was left in a broken state on upgrade
<Daviey> slangasek: umm, ok
<infinity> Dear AMD, thanks for your release notes being two years out of date.
<infinity> Bit hard to tell if the new driver will actually be any happier with the new xorg.
<infinity> I guess I'll leave it to someone who has hardware.
#ubuntu-devel 2012-07-01
<L3top> I cannot reconsile the ubuntu version of fglrx/fglrx-amdcccle (2:8.960 in the case of precise) with the ATI versioning (eg 12-4). apt-cache show fglrx fglrx-amdcccle  reveals no clues. It is rather important as ATI tends to drop huge chunks of cards. Any clues would be much appreciated.
<Amaranth> L3top: the AMD versioning you're referring to is for their "catalyst" releases. A part of those releases is a particular version of fglrx which following the versioning style seen in that packet
<Amaranth> err, package
<Amaranth> which is following*
<Amaranth> bleh, can't type
<L3top> No worries. I understood. Thank you for the reply. I have been looking on the wrong side for a link. Thank you.
<chu> window 29
<vibhav> As per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650062 , im-switch is depreciated
<ubottu> Debian bug 650062 in im-switch "im-switch: Retiring im-switch for post wheezy" [Normal,Fixed]
<vibhav> So is it worth merging packgae im-switch from Debian? (https://bugs.launchpad.net/bugs/1019262)
<ubottu> Launchpad bug 1019262 in im-switch (Ubuntu) "Please merge im-switch 1.22 from Debian Unstable" [Wishlist,Incomplete]
<cjwatson> Merge everything until such time as it's removd
<cjwatson> *removed
<cjwatson> Merges are not generally so hard that it's worth agonising over
<cjwatson> (I followed up to the bug saying as much)
<infinity> vibhav: Also, the word you wanted was "deprecated".
<vibhav> infinity: yeah, thanks
<vibhav> Can some archive admin look at https://bugs.launchpad.net/bugs/1019778 ?
<ubottu> Launchpad bug 1019778 in r-cran-qvalue (Ubuntu) "Obsoleted by r-bioc-qvalue." [Undecided,New]
<infinity> vibhav: Commented.
<infinity> (and going to bed)
<vibhav> infinity: I was thinking that too
<vibhav> about that*
<melodie_> hi
<penguin42> hallyn: Do you have any tips for rebuilding the qemu git source so it can be used from libvirt?
<penguin42> ah, got it
<tomreyn> hi, i've got firefox 13.0.1 here on ubuntu 12.04 x86_64. I've got a mediocre 4 core CPU, and normally firefox causes less than 2% load if 100% is the 4 core combined. Currently, in safe mode (all plugins disabled, only the chrome page which lists pages to restore is loaded), it consumes 25% CPU. thunderbird also consumes way more CPU than it used to, other processes seem unchanged. i recently activated  xorg-edgers ppa (deb http://ppa.launc
<tomreyn> hpad.net/xorg-edgers/ppa/ubuntu precise main) by Sarvatt which also provided me with a linux 3.5.0-2 build. could this be related?
<Chipzz> tomreyn: stating the obvious, have you tried reverting either (the kernel would be a good idea if you suspect that)
<tomreyn> Chipzz: not, yet, couldn't reboot, but yes i plan to.
<Chipzz> that being said, this isn't the right place for these kind of questions :)
<tomreyn> okay, it seemed to me like it may be something the packger of said kernel image may want to know.
<Chipzz> yes, but like you said, you got it from a ppa
<Chipzz> this channel is strictly for ubuntu main/restricted as is
<Chipzz> I'm not sure if that's the best place to ask, but #ubuntu-desktop would probably be a better starting point
<Chipzz> it also might just be that newer versions of ff are more cpu hungry
<Chipzz> you didn't state wether your thunderbird version came from that ppa too
<Chipzz> anyway, a 25% cpu increase caused by the kernel sounds unlikely
<Chipzz> (but not impossible)
<Chipzz> but I would look at ff first
<Chipzz> #ubuntu-desktop is for the development of Unity etc, not 100% sure if ff is on-topic there, but you could ask there what would be a good channel
<Chipzz> keep in mind that it's weekend though, and a lot of people are AFK
<Chipzz> tomreyn:
<Chipzz> 06:06 < jamessan> hmm, chromium has been completely hogging my processor since the leap second. as soon as I restart, it immediately  pegs all cores
<Chipzz> (from #debian-devel)
<Chipzz> have you tried restarting ff, and if that didn't help, rebooting your computer
<Chipzz> and as a last measure adjusting your clock manually?
<Chipzz> there has been a leap second this night which might explain the behaviour
<tumbleweed> sounds exactly like it. my firefox went nuts until I adjusted the clock
<tomreyn> Chipzz: i didnt reboot for a few days now, but will do it soon. I'm aware of http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second (please point me to better resources if any).
<tumbleweed> tomreyn: http://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/
<tomreyn> it's unclear to me what's the scop of this bug (systems/kernels (not) affected)
 * Laney wibbles
<Laney> kirkland: are you aware of / do you care about â
<Laney> dpkg: error processing /var/cache/apt/archives/moreutils_0.47_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/errno.1.gz', which is also in package errno 1.3-0ubuntu1
 * dupondje wants new networkmanager version :)
<tomreyn> tumbleweed, Chipzz: this worked around it nicely for me, so it's indeed the leap second issue: sudo date -u -s "`date -R -u`
<tomreyn> that's missing a " in the end: sudo date -u -s "`date -R -u`"
<dupondje> slangasek: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1015753 whats your opinion about the comment? I guess nobody changes the upstart scripts themself? Or?
<ubottu> Launchpad bug 1015753 in cryptsetup (Ubuntu) "Sync cryptsetup 2:1.4.3-2 (main) from Debian unstable (main)" [Undecided,New]
<infinity> tomreyn: That's overly complicating the command.  date -s "$(date)" is more than enough.
<tomreyn> didnt work for me
<tomreyn> probably due to none english locale
<tomreyn> *non-
<infinity> tomreyn: Or an ambiguous timezone, perhaps.
<infinity> (There are a few)
<tomreyn> I guess Europe/Berlin is not one
<infinity> Yeah, CEST probably isn't ambigous.
<infinity> ambiguous*
<infinity> Unless your locale makes it "EST", which very much is.
<slangasek> dupondje: Clint is right that you need to handle the upgrade of the conffiles properly.  Also, why change the names from what they were in Ubuntu already?
<RAOF> Daviey: Ah, fglrx supports our new server, but apparently segfaults on x86-64 because madness.
<RAOF> Daviey: Also, which UDS were you referring to, there? I *was* in the session at UDS:P, and stated very clearly that the we-won't-break-the-binary-drivers goal was Precise-only; as far as I know we're free to break the binary drivers at our leisure (but will try not to, because we're not arseholes).
#ubuntu-devel 2013-06-24
<psusi> is there a way to get polkit to retain the user home dir?
<pitti> Good morning
<dholbach> good morning
<didrocks> doko__: hey, seb128 and I looked at google-mock for respecitively 30 min and 1h without finding out how to fix the google-mock FTBFS (pthread failures). Tried to add various -pthread (already included) before/after the linkage, tried to look if upstream has anything as well, tried to compare with debian, but the FTBFS is there as well, various google searchâ¦ do you think you can give us an hand?
<didrocks> tvoss: FYI ^
<tvoss> didrocks, thanks
<czajkowski> aloha
<czajkowski> If I buy a brand newlaptop to wipe and install Ubuntu on it, will I run into any issues with secure boot?
<czajkowski> looking at buying a X1 Carbon and just want to check to see if there is anything I should avoid
<hyperair> ugh x1 carbon
<hyperair> no ethernet.
<czajkowski> oh now never even thought about that or need for one
<czajkowski> altough it can be nice to have as a back up
<czajkowski> bugger
<hyperair> yeah you'll have to go out and get a USB-3 dock, or ethernet dongle
<czajkowski> aye you can get one via  a USB adaptor
<hyperair> it's still going to be capped at 100BaseT though
<hyperair> USB-3 ethernet dongles are incredibly hard to find
<hyperair> (at least here in singapore)
<czajkowski> nods gotcha
<czajkowski> am more concerned over the secure boot issues I may run into
<soren> If ethernet is an emergency backup (ie wifi is the normal connection type), being capped at 100 Mbps doesn't sound like a big issue.
<czajkowski> soren: more of a plan B back up
<xnox> czajkowski: if you use iso or dd the iso onto usb stick, it should all just work. You must be able to disable secure boot using bios/firmware screens.
<greyback> czajkowski: quoting the wiki page, SecureBoot might probably work. https://help.ubuntu.com/community/UEFI#SecureBoot
<greyback> czajkowski: and this person looks to have had success: https://x1carbon.wordpress.com/2012/10/16/install-linux-on-lenovo-x1-carbon/ - tho it may have been an earlier model
<greyback> http://vasilezaremba.com/installing-ubuntu-12-10-on-lenevo-x1-carbon/ too
<czajkowski> xnox: greyback cheers
<greyback> happy buying!
<infinity> czajkowski: Several of us have Carbons, and they seem to work just fine.
<infinity> czajkowski: (Not I, but many others)
<seb128> zul, infinity, mdeslaur: hey, does one of you plan to merge apache2 on Debian? there is a bunch of packages in the archive depwaiting on dh-apache2 which is a new helper shipped in the current Debian version
<cjwatson> If you do, then be aware that the Apache 2.4 transition is a large and complex one
<cjwatson> I think we probably ought to take it, but somebody needs to actually manage that transition
<cjwatson> cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661958
<ubottu> Debian bug 661958 in release.debian.org "transition: apache2 2.4" [Normal,Open]
<seb128> cjwatson, thanks, I was not planning to ... which is why I pinged the people who touched apache2 last ;-)
<seb128> but good to be aware that it needs planning
<cjwatson> Sure, which is why I didn't specifically address my comment to you :-)
<seb128> ;-)
<seb128> jamespage, doko, whoever looks after java: jarjar in saucy depwait on libasm4-java which is in universe, want to file a MIR for this one? ;-)
<pitti> @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: pitti
<infinity> seb128: I was thinking of merging and starting the transition after Alpha1, but it depends on how far Debian's gotten (or how many patches there are in the BTS), since I don't particularly want to do the whole thing myself.
<seb128> infinity, ok, no hurry, as said I just noticed that a few packages are depwaiting on it in saucy ... but we can as well wait for Debian to do a bit more of the heavy lifting ;-)
<infinity> seb128: *nod*... We should definitely do it this cycle, I'll keep an eye on it and start it when it seems sane.
<pitti> cjwatson: oh, you are handling the casper sponsoring? I was just about to do it, but saw your approval
<pitti> cjwatson: ah no, that was -cdimage, not the casper branch, nevermind
<pitti> mvo: hey Michael, how are you?
<pitti> mvo: there's a bunch of updates in lp:software-properties, is that good for uploading, or do you know of blockers?
<pitti> mvo: it works fine here after some basic testing, at least
<mvo> pitti: I think its fine, go ahead and upload (I can do that too later if you want)
<tvoss_> pitti, ping
<pitti> mvo: done
<pitti> tvoss_: hey
<tvoss_> pitti, hey there :) I'm looking into a VT_SETMODE ioctl resulting in an Input/Output error
<tvoss_> pitti, the behavior people are describing hints towards a race, but I'm not a 100% convinced
<tvoss_> is there any way to get a little more information about the cause of the error
<tvoss_> ?
<cjwatson> The notes in the comments at the top of /lib/udev/console-setup-tty may be helpful
<cjwatson> (or may not)
<pitti> tvoss_: first time I hear about VT_SETMODE, I'm afraid; what's the context there?
<tvoss_> pitti, Mir has to adjust the vt mode to process-controlled (as opposed to kernel controlled), and specify some callbacks to manage its state on vt switches
<cjwatson> I wonder if you're accidentally trying to perform that ioctl on a hung-up tty
<cjwatson> TBH for undocumented console ioctl failures you generally have to either attempt to divine the problem from kernel source or else rebuild the kernel with extra printk debugging
<apw> cjwatson, it is possible i have another report of linux-image-generic not being installed after install, do you know of any cases of this still occuring, and if it is would that likely be ubiquity ?
<cjwatson> apw: I don't know of one, but I'm not sure I would :)
<cjwatson> apw: Find out first whether it was a serverish or a desktopish install
<apw> cjwatson, they are saying "live USB key" and it is a laptop they are installing, so i belive it is a desktop job
<apw> bug #1172852
<ubottu> bug 1172852 in linux (Ubuntu) "USB keyboard and mouse don't work" [High,Incomplete] https://launchpad.net/bugs/1172852
 * apw tries to raise the reporter on irc as well
<smb> Since it says life usb key. I would assume not-server
<cjwatson> I'd suggest getting /var/log/installer/syslog and perhaps also /var/lib/dpkg/status then
<doko> didrocks, Daviey, Laney: did one of you ping me about the ipxe ftbfs? looks like an issue in ipxe, so the proposed fix seems to be ok
<Laney> I don't have any memory of that
<Laney> doesn't mean that I didn't ...
<didrocks> doko: neither did I, I pinged you about google-mock vs pthread
<doko> didrocks, can't remember that one either ;)
<didrocks> doko: here it is: http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-devel.html#t07:56 :)
<Laney> btw, I'm trying gtk3 with 4.7 to see if that really is it
<doko> didrocks, you need to build libgtest with -pthread, not just the executables for the unittests
<seb128> Laney, ?
<Laney> yes?
<seb128> Laney, gtk3 works fine with gcc 4.8 before those linaro changes got merged in
<Laney> you narrowed it down more?
<seb128> well, to one revision
<seb128> not sure how gcc 4.7 is going to be useful
<doko> well, to one gcc upload
<Laney> it's useful because you can upload using that on armhf in the interim
<seb128> right, sorry "revision" -> "upload"
<seb128> Laney, -O0 workaround it
<seb128> so we can use that was well
<doko> did you narrow it down even more?
<seb128> doko, ^ just that -O0 works
<seb128> -O1 or -O2 breaks
<seb128> not sure how to narrow it further down
<doko> is there a single test case which you can run?
<doko> well, it's the game about combining O0 and O2 object files until you find the offending one
<seb128> not really, it's basically "build libgtk.so, run one of the tests, it fails with new gcc"
<seb128> I don't know how to do that
<seb128> and libgtk has a full stack of object files
<seb128> I tried to "touch .c" on random sources
<seb128> but that feels like random poking going nowhere
<doko> I know, it's a time consuming task ...
<doko> did you open an issue for that?
<seb128> no, I will do it in a bit, I was waiting to get a bit more details
<seb128> e.g trying to optimization
<seb128> I poked enough around to open a bug with some content at this point
<cjwatson> Bisecting -f options can help too, although it's not always the case that you get a clean bisection there
<seb128> I'm not sure I will be able to spend more time on that anyway, I almost spend a day on it already
<seb128> cjwatson, you mean?
<cjwatson> I mean that much of the difference between -O0 and -O1 can be controlled in more fine-grained ways using a variety of -ffoo options
<seb128> oh
<seb128> is the list of options described somewhere?
<cjwatson> http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Optimize-Options.html#Optimize-Options
<seb128> thanks
<mlankhorst> brrr, rebuilding mesa 4 times again locally because the sru was preempted by a security update :/
<cjwatson> Like I say, it isn't always perfect - I don't think everything's independently controllable, and some of the optimisation options interact
<cjwatson> But it can sometimes help
<apw> cjwatson, confirmed it is a live cd install on a normal system, i've asked them to attach the said files
<cjwatson> ok
<pitti> didrocks: hm, the bunch of unity-ish uploads in https://launchpad.net/ubuntu/raring/+queue?queue_state=1 look like an error in the autolanding? or was that actually supposed to be a massive SRU?
<doko> right, bisecting options options helps too, but it won't help much finding the location
<seb128> cjwatson, doko, Laney: I will try to poke around a bit more, but that seems like a time sink work and I've already spend more time on than that I should (or rather delayed touch work that I should be doing) ... I might just end up filing the bug and build gtk with -O0 on armhf as a workaround
<seb128> pitti, that stack seems about right
<seb128> pitti, they are all components from a stable series with SRU bugs manually pushed (I think sil2100 worked on that landing)
<doko> pitti, infinity: I was wondering if we can build locales again from the eglibc sources, or what would be needed for that
<pitti> seb128: ok, thanks for confirming (just saying, the SRU team won't be happy about that)
<seb128> pitti, why wouldn't them?
<pitti> doko: I think we can actually; this was originally split back in the ancient days for adding locale editing support to LP, but this won't happen, and it's not very important
<pitti> doko: we have a couple of patches to locales which would need to go to eglibc then, plus our modificaitons to locale-gen, but not much else really
<seb128> pitti, it's only 10 sources, we do land more than that manually when we do e.g a GNOME minor releases round or when KDE does a point release update
<pitti> seb128: there's no debdiff nor changelog in the queue, so a bit hard to review
<pitti> anyway, it just caught my eye during my sponsoring shift
<seb128> pitti, yeah, that's a known issue, but the staging ppa which is used for copy should have the diff
<doko> pitti, cool, can you coordinate with infinity so that he may get these included upstream in 2.18 maybe?
<pitti> doko: ah, maybe the eglibc maintainers are more open to that; I sent all our locale changes to glibc, and some were even accepted, but you know Ulrich.. :)
<pitti> doko: does eglibc have a separate bug tracker? I can re-send them there
<doko> pitti, no, but carlos o donell is now doing glibc release management
<pitti> most of our patches are just taken from Debian's eglibc package, but we have some 5 extra
<apw> cjwatson, i assume if we see the below, this is not good:
<apw> Jun  7 12:16:27 ubuntu ubiquity: Removing linux-generic ...
<apw> Jun  7 12:16:27 ubuntu ubiquity: Removing linux-headers-generic ...
<cjwatson> apw: Probably not but I have a policy of not looking at partial log fragments :-)
<apw> cjwatson, it is attached in full to the bug
<apw> :)
<cjwatson> apw: Ah, that's bug 1070427 then
<ubottu> bug 1070427 in ubiquity (Ubuntu Quantal) "Ubiquity removes kernel headers, fails to build nonfree drivers" [High,Triaged] https://launchpad.net/bugs/1070427
<cjwatson> Not fixable without a 12.10 point release ...
<apw> cjwatson, ahh ok, nasty
<doko> didrocks, are you looking at google-mock?
<pitti> @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:
 * dholbach hugs pitti
 * pitti hugs dholback
<didrocks> dholbach: I tried to build libgtest (the one embeeded) with -pthread without any luck, if you can give a look, that would be nice :)
<didrocks> pitti: no, it's a SRU that has been reuploaded 3 times because the package went invalid after a while (the syncs)
<didrocks> pitti: it's indicators + unity srus
<dholbach> didrocks, are you sure you wanted to ping me about it? :)
<didrocks> dholbach: no, too many "d" on this channel!
<didrocks> "oh wait" :)
<didrocks> doko: I tried to build libgtest (the one embeeded) with -pthread without any luck, if you can give a look, that would be nice :)
<dholbach> yeah, thought so - the other German whose nick starts with a'd' :)
<dholbach> or "the other guy in Berlin..." :)
<didrocks> dholbach: I was close you will notice!" :)
<dholbach> didrocks, if it's early enough, I'll meet doko on Friday - I can let him know there ;-)
<didrocks> dholbach: ahah, let's plan on that then! :)
<dholbach> brilliant
 * didrocks hugs dholbach
 * dholbach hugs didrocks back
<seb128> doko, Laney: ok, I opened https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1194123
<ubottu> Launchpad bug 1194123 in gtk+3.0 (Ubuntu) "gcc 4.8.1-2ubuntu1 to 4.8.1-3ubuntu1 breaks gtk on armhf" [Undecided,New]
<mlankhorst> can some core dev sponsor xxv-intel-lts-raring and mesa-lts-raring from http://people.canonical.com/~mlankhorst/lts-raring.tar ? Keep in mind that you need to use dpkg-buildpackage with -v to get all the changes from the previous lts-raring entry, else the sru will get rejected again :/
<tseliot> mlankhorst: if you build the sources with "-v" for me, I'll gladly get your sources, sign them and upload for you
<mlankhorst> tseliot: the .changes in there should be correct
<tseliot> mlankhorst: ok, let me have a look
<pitti> fginther: so I was mostly wondering whether the ap-gtk tests should run at package build time or not
<pitti> fginther: doing so requires xvfb; it currently works, but it's rather slow and requires disabling one check
<fginther> pitti, I wouldn't go done that path of running xvfb during package build...
<pitti> fginther: if not, I'd like them to run at least for merge proposals (CI); but I don't know how to integrate them there
<pitti> fginther: but do you agree to the part of integrating it into "make test"/"ctest"? that makes local development a whole lot simpler
<fginther> pitti, for lp:autopilot, the tests were split into 'unit' and 'functional' tests. The unit tests run during package build and don't require any X interfaces.
<pitti> fginther: ok, I don't have that for ap-gtk, as by its nature all tests are integration tests
<fginther> pitti, I do agree an making it easier for devs to run.
<fginther> hmm
<pitti> fginther: or rather, as long as we can do blackbox testing through the AP interface, I'm not that keen on encoding particular implementation details in unit tests
<pitti> fginther: I can just change the dh_auto_test rule to not run the tests, so we can keep ctest without having to run it during package build
<doko> didrocks, could you point me to your fix attempt?
<pitti> fginther: so if we don't run them during package build, how can I ensure that they run for MPs?
<fginther> pitti, we should be able to add them to the daily-release integration testing
<didrocks> doko: I have a source in /tmp/, want me to upload it? I tried several autoreconf and modification of Makefile.am, but not sure that will give you anything
<didrocks> doko: basically, adding -pthread at multiple place and trying to executed the failing g++ line manually, switching the args
<fginther> pitti, we also have ways to run them during MP, but it's a bit clunky right now, so we only do it for a handful of packages
<pitti> fginther: hm, isn't that the main point of doing CI?
<pitti> fginther: in this case, perhaps we should keep the tests during package build for the time being? that'll run them in MPs too (I got a reject the first time, then added the missing build deps, and it succeeds now)
<fginther> pitti, the ci infrastructure is geared toward unit tests. running UI tests requires a lot of infrastucutre
<pitti> fginther: ah, I thought we'd use the same infrastructure for upstream CI as for the distro autolanding
<pitti> (as they are essentially the same test suites)
<fginther> pitti, we're not there yet :-)
<pitti> fginther: understood :) (sorry, I'm still not quite familiar with all the details behind that)
<fginther> pitti, I'll take a look at the MP and do some testing through jenkins. If there are no issues, there is no reason not to run the tests during package building
<pitti> fginther: so it sounds like we should keep the "xvfb-run ctest during package build" for now? It succeeds for the full test suite (https://code.launchpad.net/~pitti/autopilot-gtk/add-tests/+merge/171036)
<fginther> pitti, yes. I'll make sure it runs, then comment in the MP
<pitti> fginther: thanks (both MPs have links to jenkins build, FTR)
<pitti> fginther: locally I test in sbuild, that should be reasonably similar
<fginther> pitti, thanks. I'll get back to you
<pitti> fginther: ack, thanks to you
<tseliot> mlankhorst: uploaded
<mlankhorst> thanks
<seb128> Laney, sorry, not sure how much that spammed
<seb128> stupid website/firefox
<Laney> a lot
<Laney> :P
<seb128> I selected one line to copy but it seemed to have taken the whole file
<seb128> and IRC isn't clever enough to limit the paste
<cjwatson> It didn't spam everyone; I only saw you quitting
<seb128> cjwatson, it was on #ubuntu-desktop
<cjwatson> Ah
<cjwatson> Your IRC client might not be clever enough.  irssi is :-)
<seb128> I'm writting here because I'm not sure if spamming is still ongoing :p
<smoser> how often does the auto sync occur ?
<mlankhorst> bdmurray: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/1100586 .. irony
<ubottu> Launchpad bug 1100586 in xserver-xorg-input-synaptics (Ubuntu Quantal) "unable to use Apple Wireless Trackpad" [High,Fix committed]
<cjwatson> smoser: Every six hours; currently disabled, see https://lists.ubuntu.com/archives/ubuntu-release/2013-June/002422.html
<xnox> smoser: if it's already available at pad.lv/d/package, and is needed, then you can use syncpackage command ;-)
<smoser> xnox, yeah, i was aware i could do it. just didn't know why it didn't just happen.
<smoser> i think i'm ook waiting until tuesday morning.
<smoser> thanks cjwatson xnox
<bdmurray> mlankhorst: it'd be ironic if I were running Quantal, but the description says I was using 13.04.
<mlankhorst> ah :p
<mlankhorst> just accept I guess
<didrocks> cjwatson: hey, small and probably a dummy question. There are tracers tools (they are libs) using lttng to bind mirserver/mirclient to some kernel tracing calls. I put them in a mir-test-tools
<didrocks> cjwatson: I, of course, then get those lintian warnings: http://paste.ubuntu.com/5795887/
<didrocks> the 3 first are "wanted" (they are not real consumer libs anyway), but the last one shows that dh_makeshlibs is ignoring this package it seems
<didrocks> even forcing the call with -pmir-test-tools shows that it doesn't produce the postinst, postrm
<didrocks> so apart from making the ldconfig call manually in postinst, postrm, I'm out of ideas, would you know more?
<didrocks> (does dh_makeshlibs filters on package name, I tried looking if there was some algorightm like starting with "lib", but didn't get any luck?)
<cjwatson> didrocks: Can't you put them in a private directory instead, if they're not meant to be on the system runtime linker path?
<didrocks> cjwatson: I think lttng needs them to be on a system runtime path
<cjwatson> didrocks: e.g. /usr/lib/man-db/libman.so doesn't cause a problem
<didrocks> tvoss: would know more ^
<hyperair> ScottK: regarding bug #1193667, would it be too invasive if i could the BPM detection module in an SRU here?
<ubottu> bug 1193667 in banshee (Ubuntu) "banshee crashes while detecting BPM" [Undecided,Confirmed] https://launchpad.net/bugs/1193667
<jdstrand> jjohansen: hey, did you figure out a way to install a kernel on the touch image without regenerating it? if so, I can help you test aa3 kernels on mako and grouper
<jjohansen> jdstrand: heh I haven't gotten that far yet
<jdstrand> jjohansen: if that would be helpful that is.
<jdstrand> jjohansen: ack, let me know if I can be of assistance
<jjohansen> jdstrand: so no I haven't yes that would be helpful
<jdstrand> k
<MDesigner> hey guys, who can I contact w/ regards to all things Ubuntu audio? (sound effects, etc)
<seb128> MDesigner, hi, try TheMuso or diwic
<diwic> MDesigner, hi
<fhf> hello all I have a problem with packaging: I need to copy icon to particular dir and I add "cp" to "rules" file http://paste.ubuntu.com/5796280/ but it gives me error "no such file or dir" and it cannot copy icon http://paste.ubuntu.com/5796283/ any1 can help?
<tvoss> ScottK, ping
<fhf> hm any genius at packing can help?
<MDesigner> argh. was in a conversation w/ diwic but he split before I got off the phone. he said I should talk to the design team. soâ¦ now who do I contact? :)
<hallyn> pitti: hey, do you remember the udev bug which caused debootstrap to leave a udevd running from the install?
<cjwatson> Bug 1182540
<ubottu> bug 1182540 in ubiquity (Ubuntu) "Daemon-suppression code in installer breaks new invoke-rc.d logic" [Critical,Fix released] https://launchpad.net/bugs/1182540
<cjwatson> It wasn't a udev bug in the end
<hallyn> oh right.  thanks!
<stgraber> cjwatson: meetings minutes are in the moderation queue
<stgraber> *meeting
<cjwatson> poked
<stgraber> thanks
#ubuntu-devel 2013-06-25
<manchicken> Hey all, I've got a problem where libcunit1 builds and links, but when I run it gives me an error code 20 with error string "No Error." However, if I build a fresh copy of CUnit from SF directly, things work just fine. What is the best way to report this issue, keeping in mind that I'm willing to help if nobody is currently interested in maintaining that package?
<ScottK> manchicken: Did you build the new version as a debian package or from source directly?
<RAOF> manchicken: A bug on launchpad.net would be the most appropriate way to report the issue; I'd also check the bugs in Debian.
<manchicken> ScottK: Directly from source.
<manchicken> ScottK: That's how I built it on the Mac when I was testing this code there, too.
<ScottK> Next thing I'd do then is update the package to build the new upstream and see if the .deb you get when you build it works or not.
<ScottK> That should tell you then if it's a packaging issue or a new upstream issue.
<manchicken> Well, what I'm thinking of doing is just whipping up a quick test program, testing it with the source version to make sure it works, and then try it with the main package, and then include that source file in the bug report if it fails.
<ScottK> A reduced test case is always good.
<manchicken> Yeah, and an automated test seems strangely appropriate as a way of demonstrating a bug in an automated test framework.
<ScottK> It's automated tests all the way down.
<manchicken> I like automated tests.
<pitti> hallyn: hey
<pitti> good morning
<dholbach> good morning
<seb128> doko_, hey, did you debug the gtk/gcc/arm issue further since yesterday? (don't want to dup work)
<m4n1sh> ev: can you please have a look at #1192777 and  #1192778 when free
<zyga> hi
<zyga> I'm trying to understand why python3-requests is not in saucy
<zyga> was it removed for any reason?
<zyga> and if so, is there a record of such removals?
<zyga> http://packages.ubuntu.com/search?suite=all&section=all&arch=any&keywords=python-requests&searchon=names
<zyga> this shows that python3-requests was in precise, quantal and raring
<zyga> and up until recently I recall it was in saucy as well
<cjwatson> https://launchpad.net/ubuntu/saucy/i386/python3-requests
<zyga> looking at debian I can see the package is there
<cjwatson> It's there
<cjwatson> Don't trust packages.ubuntu.com
<zyga> oh
<zyga> too bad
<zyga> btw, debian has a more recent version
<zyga> and we found that the version in saucy is broken when you are using a http proxy
<cjwatson> BTW, we're in Debian Import Freeze
<zyga> will the package sync again?
<zyga> oh
<cjwatson> Or we were until that was due to be undone this morning :)
<cjwatson> I just haven't got round to preflight checks before turning auto-sync back on
<zyga> ah
<zyga> thanks
<zyga> so it should re-sync again?
<cjwatson> Yes
<zyga> cjwatson: btw, is there anything I could do to make packages.ubuntu.com reliable again?
<zyga> I really like that service
<cjwatson> Dunno, it's community-maintained
<cjwatson> I think Rhonda runs it?
<cjwatson> May be waiting for an IS deployment of some kind, I don't know; feel free to chase up
<zyga> ok, thanks
<ev> mpt: when you have a chance, can you help me understand how we calculate the "rate for matching machines" in "what's unusual about this problem?"
<ev> In the case of evaluating whether the architecture is relevant, is it:
<ev> Take the reports for i386. Filter down to reports for the current day. Get the systems responsible for each of these reports. Divide the number of reports by the number of unique systems. Do the same for each other day, then average out across all days.
<ev> Compare the average value for i386 against the value for amd64 and armhf. If i386 is significantly greater, highlight it.
<ev> Apologies, I know we discussed this before, but I'm struggling a bit understanding how we get the error rate for a subset of instances in the bucket.
<cjwatson> Daviey,jamespage: copies of public source to archives owned by private teams should be fully safe now; the fix for /builders visibility is deployed
<doko> \O/
<tvoss> cjohnston, hey there. We are running into static ctor/dtor issues right now. Could you give us a hand?
<tvoss> cjwatson, ^ that was meant for you :)
<tvoss> cjohnston, sorry for the noise
<cjwatson> doko: ^- Could you help tvoss?  You're probably better at this than I am
<doko> cjwatson, tvoss: vacation days today and tomorrow, so won't have much time
<Daviey> cjwatson: Super!  Thanks :)
<tvoss> doko, ack, here is the issue in case you are bored during vacation :) http://pastebin.ubuntu.com/5798108/
<doko> tvoss, has this something to do with the gmock build failure?
<tvoss> doko, nope, mir carries its own in-tree version of gmock for historic reasons
<doko> tvoss, just saucy, or raring as well?
<tvoss> doko, just saucy as far as I can tell
<jamespage> cjwatson, great! - thanks for fixing that up
<ev> pitti: if and when you have a minute, I've got a small change to our apport packaging. It enables core dumps of setuid processes, now that kees says it's okay: https://code.launchpad.net/~ev/apport/raring-suid_dumpable/+merge/171270
<pitti> hey ev
<pitti> ev: hm, doesn't that also affect normal core dumps?
<pitti> ev: (and I guess that's for saucy then)
<ev> oh whoops
<ev> yes, I'll apply it to saucy as well :)
<ev> pitti: affect normal core dumps how? 0 is the default, as I understand it.
<pitti> ev: ah, =2 is only applied for pipes
<pitti> ev: so, I haven't checked whether a suid program actually ends up being owned by the target user, but if that happens, that looks fine to me
<pitti> nice, thanks!
<xnox> ubiquity wrapper with pexec works: if .desktop specifies "Terminal=true", or if ubiquity wrapped with an extra shell script around it.
<cjwatson> jibel: libreoffice autopkgtest failures are "build slave doesn't have enough disk space", aren't they?
<cjwatson> schedule amended to move DIF to week 13; mail sent to ubuntu-release@; auto-sync running
<pitti> yay
<cjwatson> [Updating] requests (1.2.0-2 [Ubuntu] < 1.2.3-1 [Debian])
<cjwatson> zyga: ^-
<zyga> cjwatson: awesome, thanks!
<cjwatson> automake1.11 binary is heading back into the archive, for whoever it was who was asking about that
<pitti> cjwatson: ISTR it was seb128
<seb128> cjwatson, pitti: yeah, it was me, thanks
<chrisccoulson> this build failed earlier, any idea who restarted it? https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4742188#
<chrisccoulson> i hadn't had a chance to look at the old build log....
<cjwatson> I did, because it failed due to a broken builder
<jibel> cjwatson, yes, I increased disk size already but it's clearly still not enough. I'll have to make a specific setup for LO to run it on a bigger partition.
<cjwatson> heka chrootwaited its next eight builds after that, and the end of the chromium-browser log was all invalid-character-in-source-file stuff
<chrisccoulson> cjwatson, ah, thanks
<cjwatson> jibel: Right, thanks.  I've forced proposed-migration to ignore (that version of) libreoffice for the time being
<cjwatson> chrisccoulson: Now, unfortunately it got retried on heka, albeit after it was nominally fixed ... hopefully it won't eat it again
<chrisccoulson> cjwatson, yeah, fingers crossed...
<xnox> jibel: adt keyword: needs-libreoffice-amounts-of-disk-space ?! =)
<cjwatson> chrisccoulson: https://launchpadlibrarian.net/143317414/buildlog_ubuntu-precise-armhf.chromium-browser_28.0.1500.52-0ubuntu1.12.04.1_FAILEDTOBUILD.txt.gz is still accessible if you have the URL, FWIW
<cjwatson> So you can double-check me, but complaints about "WebGesttrdEvemt" are a pretty good sign of an insane builder
<cjwatson> :)
<tvoss> doko, in case you are around: seems like saucy already has the binutils and gcc version you were mentioning: http://pastebin.ubuntu.com/5798341/
<tvoss> doko, or do you want me to force the ppa version?
<smb> infinity, If you got not too much liquid related (or other issues), is there a possibility that you may get bored enough to look at the crash backports?
<tkamppeter> OdyX, hi
<OdyX> tkamppeter: hoy
<ev> pitti: *nods* I'll confirm it does
<ev> thanks
<hallyn> pitti: hey
<tkamppeter> OdyX, I would like to change the pstops priority again so that PostScript jobs for PostScript printers go through pstops instead of pstopdf+pdftopdf+pdftops. Do you know why "make test" fails then? Do you have an idea why the test fails and how one could fix it? Or should I change the cost factors after "make test" and before "make install" in the package build?
<tkamppeter> OdyX, see also https://bugs.linuxfoundation.org/show_bug.cgi?id=1138
<ubottu> bugs.linuxfoundation.org bug 1138 in cups-filters "Filters should not specify artificially low costs" [Normal,New]
<OdyX> tkamppeter: I'm all for re-enabling the ps-to-ps, but we have to find a sane way to have the tests working; and having them run in a setup which is not what we ship is not something I'd be happy with.
<jdstrand> tyhicks: hey, so I uploaded my apparmor packages to the ppa
 * tyhicks looks
<jdstrand> tyhicks: I'll be uploading another set to the archive in a few minutes (without dbus patches)
<jdstrand> tyhicks: what is the timeframe for uploading dbus to saucy?
<dholbach> cjwatson, thanks!
<jdstrand> (and by 'to the archive', I of course meant to saucy)
<tyhicks> jdstrand: it is hard to say with the policy language still up in the air
<tyhicks> jdstrand: there's not much left to do, but we do have to settle that first
<OdyX> tkamppeter: see Debian #712237
<ubottu> Debian bug 712237 in cups-server-common "cups-server-common: The cost factor for pstops" [Normal,Open] http://bugs.debian.org/712237
<jdstrand> tyhicks: right. I thought we said that it didn't need to be finalized. ie, when sbeattie gets back, we can finalize it but in the meantime, upload. or are you saying we are still waiting on jj for the ipc implications? (I am a bit behind on email right this second)
<tyhicks> jdstrand: yes, waiting on jj's input on future ipc implications
<jdstrand> tyhicks: I see. ok. my thoughts are that this is talking too long and we need to get the code out there-- the only ones that will be affected by the policy changes is us for the most part in the short term. when the language is finalized and uploaded, then we can blog
<jdstrand> s/talking/taking/
<pitti> hey hallyn
<jdstrand> tyhicks: that came out wrong. the dbus syntax iterations are taking a long time, which conflicts with us getting things into the archive, on the images, etc
<jdstrand> tyhicks: and the code exercised by others
<tyhicks> jdstrand: so you're suggesting that we push what we have now into the archive something this week?
<jdstrand> tyhicks: anyhoo-- this isn't anything against the good work you guys are doing, it is just taking longer than we planned
<tyhicks> s/something/sometime/
 * jdstrand checks something
<tyhicks> jdstrand: should uploading the userspace changes to dbus and apparmor depend on the kernel changes being in place?
<hallyn> pitti: did you want to talk about something?
<pitti> hallyn: not from my side, but you said "hey" half an hour ago
<tyhicks> jdstrand: to allow people to test the code, we'll need the aa3.0 patches in the saucy kernel
<jdstrand> tyhicks: well, we have a monthly goal to have the syntax finalized. that won't be met unfortunately. I'd like for us to work through the ipc implications and then upload something based on that
<jdstrand> tyhicks: and that shouldn't be blocked on sbeattie's vacation
<jdstrand> tyhicks: but, it probably doesn't matter, sbeattie is back next week
<jdstrand> tyhicks: re kernel patches> jj sent out pull requests for the phablet kernels a few minutes ago
<hallyn> pitti: that was bc you'd said hey about 8 hours ago :)  probably bc I pinged you yesterday - ttyl :)
<jdstrand> tyhicks: the desktop kernel we could keep waiting on
<tyhicks> jdstrand: and sbeattie did respond to the thread - I don't think that we're blocked by his vacation at all
<jdstrand> tyhicks: ok, it sounds like we just need to have the ipc implication discussion, then we can make the cahnges and upload?
<pitti> hallyn: heh, fun; so, enjoy your day :)
<jdstrand> tyhicks: then refine as needed
<jdstrand> tyhicks: is that accurate?
<tyhicks> jdstrand: yes, exactly
<jdstrand> tyhicks: ok. I think some testing I did yesterday showed this to be the case, but if there are dbus rules present in the policy and we boot into a non-v3 kernel, everything works like it does now (ie, the dbus rules are effectively ignored). correct?
<tyhicks> jdstrand: yes, dbus-daemon detects that /sys/kernel/security/apparmor/features/dbus/ does not exist and does not try to enforce any apparmor mediation
<jdstrand> tyhicks: ok, perfect. so, actually, have phablet kernels with v3 and desktop kernels without exercises different code paths nicely
<tyhicks> jdstrand: yes, both paths will be exercised
<jdstrand> tyhicks: are you comfortable with the path forward then?
<tyhicks> jdstrand: yes, it is clear
<mpt> Is it possible for the PC/phone to know the battery charge level of a connected Bluetooth headset? (cyphermox?)
<jdstrand> tyhicks: awesome, thanks! :)
<tkamppeter> OdyX, perhaps we should somehow change the cost factors in the cups-filters package to get the desired workflows?
<cyphermox> mpt: in theory yes, I've seen it :)
<mpt> excellent
<cyphermox> mpt: I'll look up the details
<OdyX> tkamppeter: I don't oppose that, certainly. What I want is that the cups IPP tests run with the cost factors that are shipped in the packages.
<mpt> cyphermox, https://wiki.ubuntu.com/Power#Indicator
<mpt> ev, "average out across all days" will result in very-nearly-zero rates for every error that started less than a year ago. Probably you want to collect only the past week or something like that.
<ev> ah yes, but generally does that look like the right algorithm?
<mpt> I'll rewrite it without looking and see if I get the same result...
<mpt> Architecture is most important if absolute_value(rate(some_architecture) - rate(others)) > any_other_difference
<mpt> ev, i.e. for a given period, errors(architecture)/machines(architecture) - errors(all_other_architectures)/machines(all_other_architectures)
<ev> mpt: was about to pastebin some code I already wrote to that effect, but immediately realised it looks like really bad Perl. :-/
<ev> thank you though
<mpt> Don't worry, I wouldn't be able to tell the difference between really bad Perl and really good Perl
<ScottK> No one can, it's write only.
<ev> amazing
<mdeslaur> there's really good Perl?
<mpt> Thanks ScottK, I thought it would take at least two minutes for someone to take that and run with it. ;-)
<ScottK> There is actually.
<ScottK> It's just rare.
<mdeslaur> hehe :P
<maxiaojun> hi, i just note that Ubuntu's 'chmsee' package struck at version 1.3.0-2ubuntu2
<maxiaojun> can we re-sync with Debian? Debian has latest upstream version in sid
<cjwatson> It's presumptively up to the last uploader (chrisccoulson) to either do it or delegate it
<seb128> maxiaojun, we sure can, if you want to work on it please do and subscribe sponsors?
<maxiaojun> seb128, what do you mean by "please do"?
<seb128> maxiaojun, if you want to update the package/rebase it on the current debian version that would be welcome help
<maxiaojun> i still don't understand what exactly should i do. file a bug? link a branch?
<mitya57> maxiaojun: http://developer.ubuntu.com/packaging/html/udd-merging.html
<jbicha> chmsee is a difficult package as it was patched to build with webkit instead of xulrunner
<maxiaojun> are the patches still needed? as the upstream is keeping up with Firefox change (though i think they should set slight larger MaxVersion) while webkit branch seems unmaintained
<pitti> ev: splendid, thanks!
<ev> pitti: sure thing. Tracking in https://bugs.launchpad.net/ubuntu/raring/+source/apport/+bug/1194541
<ubottu> Launchpad bug 1194541 in apport (Ubuntu Quantal) "Create core dumps for setuid binaries" [Undecided,New]
<pitti> ev: ah, the saucy one didn't have that bug ref, closing manually
<ev> thanks
<jdstrand> jodh: hi! I can't remember, what was the eta for upstart/apparmor with mdeslaur's distro patch?
<jodh> jdstrand: plan was "by tomorrow" as of last week, but we've had a nasty merge to perform which has slowed things rather I'm afraid. That merge is now done so once I've got an ack on a couple of other upstart branches we can get a new upstart release out.
<jdstrand> jodh: ack, thanks for the update and your work on this :)
<ricotz> mdeslaur, hi :), could take a look at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0037 which would mean to get at least raptor2 2.0.7-1 into precise
<ubottu> Redland Raptor (aka libraptor) before 2.0.7, as used by OpenOffice 3.3 and 3.4 Beta, LibreOffice before 3.4.6 and 3.5.x before 3.5.1, and other products, allows user-assisted remote attackers to read arbitrary files via a crafted XML external entity (XXE) declaration and reference in an RDF document. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0037)
<mdeslaur> ricotz: we fixed that already: http://www.ubuntu.com/usn/usn-1480-1/
<ricotz> mdeslaur, ok, this is about libraptor2-0 too
<ricotz> which librdf0 uses
<mdeslaur> ricotz: ah! I see, ok, I'll reopen the CVE and add raptor2 to it. Thanks!
<ricotz> mdeslaur, thanks
<Spee_Der> G'day folks....
<barry> @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: barry
<jbicha> barry: since you're piloting, you saw my 2 mp's for xdiagnose, right?
<barry> jbicha: nope.  they don't show up on the sponsoring page, but send me the urls and i'll take a look
<jbicha> https://code.launchpad.net/~jbicha/xdiagnose/fix-installing-icon-and-tweak-desktop/+merge/170927
<jbicha> https://code.launchpad.net/~jbicha/xdiagnose/mark-apply-close-translatable/+merge/170928
<barry> jbicha: i don't want to step on bryce's toes (his review claim is pending).  but maybe that was a few days ago
<barry> and he's on to other things?
<jbicha> never mind, I saw a B name and mixed you two up
<barry> jbicha: np
 * barry will leave it to bryce then
<barry> jbicha: but it looks like you do have a few other things in the queue, so maybe it's your luck day :)
<xnox> what was the story around GL and armhf? Or any pointers about fixing https://launchpadlibrarian.net/141550690/buildlog_ubuntu-saucy-armhf.qtiplot_0.9.8.9-4ubuntu1_FAILEDTOBUILD.txt.gz
<xnox> as far as I can tell glu.h does exist during build ...
<slangasek> xnox: GL on armhf should be EGL, but that shouldn't matter; I don't see libglu1-mesa-dev being installed as part of that build log?
<slangasek> you need an additional -dev package for glu vs. gl
<xnox> ok, thanks =)
<barry> robru, kenvandine okay, that was beautiful!  i was just using the friends app to post a new message.  i got as far as "say hell" and it crashed :)
<robru> barry, nuh uh!! nyanyanyanyanyanyanya i can't hear you!!!!
<slangasek> barry: you have the special version that's limited to 14 chars
<barry> robru: say hell!
 * barry has a new motto for today
<robru> barry, yeah, I'm getting lots of crasher bug reports for friends-app lately. I can't reproduce it, and i don't know much about Qml to fix it. I think kenvandine needs to step in here...
<kenvandine> humm
<kenvandine> not much going on there to cause it to crash
<kenvandine> i've seen it crash on startup if you don't have an account enabled
<kenvandine> but while you're typing all it does it change the counter
<kenvandine> barry, got a crash file?
<robru> kenvandine, also: https://bugs.launchpad.net/ubuntu/+source/friends-app/+bug/1176498 read the comments for two *different* crashes
<ubottu> Launchpad bug 1176498 in friends-app (Ubuntu) "friends app crashes on start." [Undecided,Confirmed]
<barry> kenvandine: i just ubuntu-bugged it
 * Laney wanted to congratulate barry in #debian-devel but he's not there so couldn't
<Laney> well done ;-)
<barry> Laney: thanks!
<barry> kenvandine: lp: #1194638
<ubottu> Launchpad bug 1194638 in friends (Ubuntu) "friends crashed when I typed "Say Hell"" [Undecided,New] https://launchpad.net/bugs/1194638
<slangasek> sw33t, the Foundations team has K DDs and can launch its own GRs now \o/
<slangasek> barry: grats ;)
<barry> slangasek: \o/
<xnox> slangasek: right, I did a build with libglu1-mesa-dev before, and armhf FTBFS with this now http://paste.ubuntu.com/5799672/ which in turn means one shouldn't include both GLES2 and GL =/
<kenvandine> barry, thx
<slangasek> xnox: it's true that it should not... is glu GL-only?
<xnox> slangasek: not sure. but I'm now discovering bug 707794
<ubottu> bug 707794 in clementine (Ubuntu) "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [Undecided,Triaged] https://launchpad.net/bugs/707794
 * slangasek nods
<kenvandine> barry, you filed that against friends, is there a crash file for friends-app?
<barry> kenvandine: oops, sec
<xnox> slangasek: looks like it was added for fit FTBFS with qt4.8 hmmm.....
<xnox> https://bugs.launchpad.net/ubuntu/+source/qtiplot/+bug/925652
<ubottu> Launchpad bug 925652 in qtiplot (Ubuntu) "please sync qtiplot (universe) from Debian main (unstable) 0.9.8.8-3 (fix crasher and FTBFS)" [Medium,Fix released]
<barry> kenvandine: oops, there was a crash reporter window buried.  i'll use that to report the bug on friends-app
<cjwatson> barry: ah, excellent, good to see advocatees make it through :)
<kenvandine> barry, thanks!
<tkamppeter> OdyX, I have changed the cost factors of cups-filters, now setting the cost factor of pstops in CUPS is not necessary any more. See current BZR state of cups-filters, rev. 7072. https://bugs.linuxfoundation.org/show_bug.cgi?id=1138
<ubottu> bugs.linuxfoundation.org bug 1138 in cups-filters "Filters should not specify artificially low costs" [Normal,Resolved: fixed]
<barry> kenvandine: lp: #1194646
<ubottu> Launchpad bug 1194646 in friends-app (Ubuntu) "Crashed when I typed "say hell"" [Undecided,New] https://launchpad.net/bugs/1194646
 * xnox finds https://code.google.com/p/glues/
<jcastro> hey slangasek
<jcastro> http://blog.utlemming.org/2013/06/psa-ubuntu-server-1104-natty-archives.html
<jcastro> If I wanted to file a bug like "we shouldn't break people's servers just because a distro is EOL" where should I file it?
<jcastro> or is this something I can bring up on the devel list?
<slangasek> jcastro: maybe -devel; it's not really a bug in the OS that we don't have infinite space to keep EOLed releases on the mirrors forever, and it's not clear to me we should actually be putting a lot of effort into making it a more pleasant experience to continue running a release with no security support
<jcastro> sure, I understand that.
<jcastro> I would think sharing slow bandwidth with all the other bad kids would be encouragement enough
<infinity> jcastro: How do you propose we not break things?
<jcastro> or perhaps spit out a warning via apt or something instead of just 404'ing people
<jcastro> infinity: I would say something like "this distro is EOL, we've moved you to slow mirrors no one cares about, but this is the least of your problems, please see this wiki page"
<jcastro> right now we just 404 them
<infinity> jcastro: Automatically editing people's sources.lists just because they start 404ing would be fraught with peril.
<jcastro> maybe we can do a motd or something?
<infinity> jcastro: In fact, automatically doing it at any point (even based on a more clever meta-release hint) seems bad.
<slangasek> we already motd about new upgrades available, right?
<infinity> jcastro: We already do an motd telling them there are new releases to upgrade to... Which they ignored for two years.
<slangasek> s/upgrades/releases/
<slangasek> infinity: sure, but admins are going to "if it ain't broke I'm not upgrading"
<slangasek> which is reasonable
<jcastro> yeah but there's a difference between "new version, I don't care, this server works" and "if you don't listen apt will break."
<slangasek> and I think it would be a worthwhile improvement to have the motd have another check and announce "you're EOL"
<infinity> Yeah, we could add an motd hook to yell at you if you're running an EOL release.
<infinity> Well, it would be in the same upgrade-check hook.
<infinity> Since the same info comes from the same place.
<jcastro> right so I think it's probably better to not spend the cost on moving people to old-releases, but maybe instead being more in your face when you're EOL
<slangasek> should arguably be made part of the existing ubuntu-release-upgrader-core hook
<jcastro> infinity: ok so I can just do a wishlist on the motd package?
<infinity> slangasek: I think I just said that. :)
<infinity> So, check-new-release would need to grow an option (or a sister binary) for check-eol.
<infinity> And the rest is trivial.
<jcastro> ubuntu-release-upgrader-core is the package I want?
<infinity> jcastro: Wishlist on ubuntu-release-upgrader with proposed tasks for some stables as well.
<slangasek> yep
<slangasek> actually
<slangasek> /usr/lib/ubuntu-release-upgrader/check-new-release, line 116
<jcastro> thanks fellas
<slangasek>   if m.no_longer_supported is not None:
<slangasek>     url = "http://www.ubuntu.com/releaseendoflife"
<slangasek>     print(_("Your Ubuntu release is not supported anymore."))
<slangasek>     print(_("For upgrade information, please visit:\n"
<slangasek>             "%(url)s\n") % { 'url' : url })
<infinity> Err, oh.
<infinity> Indeed.
<infinity> jcastro: So, it already claims to do this. :P
<slangasek> jcastro: already fixed; if these users were running a newer release they wouldn't have had this problem!
<slangasek> <scnr>
<slangasek> though actually, the changelog implies this code should've been in natty
<infinity> And it may well be.  It could fail to trigger due to the stale lock bug.
<slangasek> the which?
<infinity> The bug wherein, once you've been informed of an upgrade, that snippet never runs again.  Ever.
<infinity> (This is fixed in precise and onward in SRUs, I believe...)
<slangasek> ah
<jcastro> oh ok
<jcastro> so tldr, it's fixed in newer releases
<slangasek> yes
<jcastro> it would then make sense why ben sees people complaining about natty, but not q
<infinity> Probably.  Would be worth a bit of testing by artificially EOLing precise locally or something.
<infinity> jcastro: Q isn't EOL, why would they complain about it?
<jcastro> infinity: because I suck at arithmetic
<jcastro> infinity: so theoretically, when Q EOLs, we shouldn't see this as much as with Natty
<infinity> oneiric is EOL, but we've not removed it from the mirrors due to OEM SLAs.
<infinity> jcastro: Well, even if the release-upgrader/motd bits are all working better now, I wouldn't bet we'd see people complain less. :P
 * cjwatson awards software-properties the title of "most frustrating autopkgtest failures"
<cjwatson> so ... close ...
<infinity> jcastro: But I don't think forcefully mangling people's apt sources without warning is a particularly friendly thing to do either, so...
<infinity> jcastro: We're going to get people whining about the 404s, and we always have had.
<jcastro> yeah I get that
<infinity> (Yeah, I'm a pessimist)
<infinity> Anyhow, given that the lock bug wasn't actually about fixing THIS, I doubt anyone's tested the EOL case specifically.  Probably worth a poke to see if it works as expected for future releases.
<jcastro> XP is 11 years old and it's mirrors don't 404. They gracefully just stop updating it
<infinity> Shame it's too late to SRU back to oneiric.
<jcastro> "gracefully" is up to interpretation there.
<infinity> jcastro: If I could think of a reliable way to auto-rewrite people to old-releases, that would get us the same "doesn't 404, but doesn't update" thing.
<jcastro> I wonder if just a url rewrite would do the trick?
<slangasek> that only helps for mirrors we control
<sarnold> jcastro: despite appearances, MS says XP is supported for another 10 months or so..
<infinity> jcastro: But given that we specifically allow (and even encourage) people to mangle sources.list to their heart's content, it's not the easiest thing in the world to do sanely.  release-upgrader tries (and when it fails, just gives up and writes a new one), but that's interactive, and it warns you.
 * jcastro nods
<jcastro> I think the motd warning does the job
<jcastro> I didn't know we had fixed that
<dobey> infinity: make an apt archive with the release name "eol" that has empty Packages/Sources/etcâ¦ and use mod_rewrite to just send dead releases to that?
<infinity> dobey: I'm not sure how that solves... Anything.
<infinity> dobey: Other than "ugliness", empty Packages files and 404s are the same thing.  Can't install software anymore.
<jcastro> we should totally just turn the tty blood red with white text when something EOLs
<infinity> jcastro: Then they'll just think they accidentally launched a NetWare installer.
<infinity> (Okay, as if any kid in IT today remembers NetWare...)
<slangasek> U+1258930 LATIN SMALL LETTER I DRIPPING WITH BLOOD
<dobey> wouldn't that be U+666?
<infinity> dobey: Anyhow, if mod_rewrite tricks worked (as in, if we had control of the server side), we'd just rewrite people to old-releases.
<infinity> dobey: Which we clearly can't, because mirrors.
<dobey> well. it's ok. they just all go on askubuntu and ask jcastro to fix it for them anyway :)
<jcastro> only 23k views on the question
<infinity> I'm okay with that solution.
<jcastro> which is neither a huge problem nor a trivial problem
<cjwatson> Auto-rewrite: be careful of people within corporate networks where they can't talk to old-releases.
<cjwatson> (Just one reason forceful mangling would be scary.)
<jcastro> infinity: in better news, I've seen the "problem with MergeList" problems nearly disappear
<jcastro> wrt. apt
<infinity> jcastro: The one that was the hard limit on combined list sizes?
<jcastro> i think part of it was when you connected to a guest wifi with like a disclaimer page apt would append that text to a file or something crazy like that
<jcastro> so basically everyone who was in a hotel would hit the problem
<infinity> Daviey: Say, weren't your minions meant to be attending to MIRs for all of puppets new deps?  That seems to have been not happening for... Months.
<infinity> jcastro: Ahh, yeah, I think the captive portal case is mostly catered for, except for a few corner cases.
<infinity> jcastro: It's still not completely fool proof.  We keep finding better fools.
<Daviey> infinity: err, yeah - we'll look at that this week.
<ScottK> So this autopackagetest block for britney blocks other packages too?
<ScottK> I'm looking at pykde4 and it's apparently blocked by an apport autopackagetest.
<cjwatson> Reverse dependencies are checked as well as the packages themselves
<cjwatson> However it's currently buggy and forgets about failures, so ...
<ScottK> pykde4 in the release pocket is currently broken.
<cjwatson> You know about force-autopkgtest, right? :P
<cjwatson> I put that there precisely so people wouldn't need to complain
 * ScottK tries.
<cjwatson> That said, by the time you've done that the test might well have completed
<cjwatson> (Note that the thing to force-autopkgtest is the tested package, not the triggering package)
<ScottK> So in this case pykde4?
<cjwatson> No, the tested package is apport/2.10.2-0ubuntu2, the triggering package is pykde4/4:4.10.80-0ubuntu1
<ScottK> It is slightly frustrating to set something up, have to go offline for ~8 hours for $work and then come back to find yet another roadblock.
<cjwatson> IOW the point is to test that the new pykde4 doesn't break apport
<cjwatson> But it's possible to say "this autopkgtest is funted right now, ignore its failure"
<ScottK> What's "I don't care, migrate it."
<ScottK> I guarantee you it's broken in the release pocket right now.
<ScottK> (due to a new sip4 I messed up in Debian and it autosynced)
<cjwatson> "force-autopkgtest apport/2.10.2-0ubuntu2, the triggering package is pykde4/4:4.10.80-0ubuntu1
<cjwatson> err
<cjwatson> "force-autopkgtest apport/2.10.2-0ubuntu2" will make it eligible.  But you really really need to let update_output look at things beyond that.
<cjwatson> So how did sip4 get in and break it?
<ScottK> It should go if autopackagetest isn't stopping it.
<ScottK> I missed an API version change when I packaged it in Debian.
<cjwatson> Ah, it's been broken for a week then?
<xnox> plus added unfortunate timing in a rebuild from me to add autopkgtest.
<xnox> yeah, for quite a while now.
<ScottK> Not to mention pykde4 from 4.10.80 hit the archive about one publisher cycle before it would have migrated.
<ScottK> Then it was blocked on the kde4libs/armhf mess.
<cjwatson> I'm not wild about using maximum force to shove it in then.  Use minimum force so that it actually happens right this time.
<cjwatson> But as you say it does look as though force-autopkgtest should be enough.
<ScottK> OK.  Fixed.
<Laney> are there still bugs around tests being left at RUNNING?
<ScottK> BTW, this particular issue is proving harder to fix in Ubuntu than Debian.
<cjwatson> I saw a bunch of armhf-only migrations while kde4libs/armhf was broken that went in suspiciously easily.  I'm still concerned that those will be left uninstallable even after the dust settled.
<cjwatson> Laney: I think that's fixed
<cjwatson> The bug I know of at the moment is that failure states are forgotten after the run that initially collects them
<Laney> Hmm, alright. I'm suspicious about glib2.0 -> bluez/firefox
<Laney> Jenkins says they both ran at 17:20ish today
<cjwatson> adt-britney collected statuses for those six minutes ago that said running
 * ScottK needs to go retrieve a $CHILD from ballet lessons.
<cjwatson> hm, but
<Laney> Maybe jenkins is lying then
<cjwatson> $ cat ../../autopkgtest/data/adt/saucy-proposed/amd64/archive/2013/06/25/saucy_amd64_bluez_20130625-172427.result
<ScottK> Probably remove some autopackage tests when I get back.  Seems like more harm than good to me.
<cjwatson> saucy amd64 bluez 4.101-0ubuntu8b1 PASS kmod 9-3ubuntu1 systemd 204-0ubuntu4 pcmciautils 018-8 lsb 4.1+Debian11ubuntu2 alsa-lib 1.0.25-4ubuntu4 dbus 1.6.12-0ubuntu1 glib2.0 2.37.3-1ubuntu1 gstreamer0.10 0.10.36-1.2ubuntu1 eglibc 2.17-0ubuntu5 bluez 4.101-0ubuntu8b1 gst-plugins-base0.10 0.10.36-1.1ubuntu1 dbus-python 1.2.0-2 readline6 6.2-9ubuntu1 libusb 2:0.1.12-23.2ubuntu1 cups 1.6.2-9 dpkg 1.16.10ubuntu2
<cjwatson> ScottK: Please let us sort out the infrastructure a bit before you do anything precipitate
<barry> cjwatson: oops. sorry if i stepped on your toes with software-properties
<cjwatson> barry: s'ok, just one upload more than strictly necessary, not a problem
<barry> cjwatson: we can always make more version numbers
<cjwatson> Ah, the above was an archived result I think
<cjwatson> 2013-06-25 17:12:08,498 INFO Checking status for: saucy bluez
<cjwatson> 2013-06-25 17:12:08,551 INFO == New version of dependency 'libglib2.0-0 2.37.3-1ubuntu1'.
<cjwatson> which is a bit odd given that that's the version number in the archived result
<Laney> If that's what it says when it triggers a new run then the timestamps could be feasible
 * Laney bed
<cjwatson> I think adt-britney thinks it's still running on i386
<cjwatson> $ cat ../../autopkgtest/data/adt/saucy-proposed/amd64/work/saucy-proposed_amd64_bluez.20130625-171230.state
<cjwatson> {"status": {"i386": "RUNNING", "amd64": "PASS", "all": "RUNNING"}, "package": "bluez", "depends": {"libglib2.0-0": "2.37.3-1ubuntu1", "libbluetooth3": "4.101-0ubuntu8b1", "pcmciautils": "018-8", "lsb-base": "4.1+Debian11ubuntu2", "libdbus-1-3": "1.6.12-0ubuntu1", "libudev1": "204-0ubuntu4", "udev": "204-0ubuntu4", "bluetooth": "4.101-0ubuntu8b1", "bluez": "4.101-0ubuntu8b1", "libasound2": "1.0.25-4ubuntu4", "cups": ...
<cjwatson> ... "1.6.2-9", "libusb-0.1-4": "2:0.1.12-23.2ubuntu1", "bluez-alsa": "4.101-0ubuntu8b1", "python3-dbus": "1.2.0-2", "libgstreamer-plugins-base0.10-0": "0.10.36-1.1ubuntu1", "upstart": "1.8-0ubuntu7", "libgstreamer0.10-0": "0.10.36-1.2ubuntu1", "multiarch-support": "2.17-0ubuntu5", "libc6-dev": "2.17-0ubuntu5", "libc6": "2.17-0ubuntu5", "dpkg": "1.16.10ubuntu2", "dbus": "1.6.12-0ubuntu1", "libbluetooth3-dbg": ...
<cjwatson> ... "4.101-0ubuntu8b1", "bluez-gstreamer": "4.101-0ubuntu8b1", "libreadline6": "6.2-9ubuntu1", "module-init-tools": "9-3ubuntu1"}, "version": "4.101-0ubuntu8b1", "release": "saucy", "causes": {"glib2.0": "2.37.3-1ubuntu1"}}
<cjwatson> But I run with -a amd64 ...
<cjwatson> OK, I've stopped it caring about i386 for now, I think
<cjwatson> ScottK: BTW, I'm always happy to offer assistance with migrations that are proving difficult.
<cjwatson> Just ask.
<cjwatson> I: [Tue Jun 25 22:26:15 2013] - Collected autopkgtest status for bluez_4.101-0ubuntu8b1: PASS
<cjwatson> better
<cjwatson> I: [Tue Jun 25 22:26:15 2013] - Collected autopkgtest status for firefox_22.0~b6+build1-0ubuntu1: FAIL
<cjwatson> ScottK: Apparently not quite enough.  I'll look into the rest, until I need to sleep
<cjwatson>     * i386: epigrass, pymca, python-acidobasic, python-guiqwt, python-qwt3d-qt4, python-qwt5-qt4, python-taurus, spykeviewer
<cjwatson>     * amd64: pymca, python-guiqwt, python-qwt3d-qt4, python-qwt5-qt4
<cjwatson>     * armhf: pymca, python-guiqwt, python-qwt5-qt4
<cjwatson>     * powerpc: pymca, python-guiqwt, python-qwt3d-qt4, python-qwt5-qt4
 * infinity watches another batch of acl2 builds fail.
<cjwatson> Whee.
<cjwatson>  python-sip : Breaks: python-qwt3d-qt4 (< 0.1.7~cvs20090625-11+) but 0.1.7~cvs20090625-11build1 is to be installed
<cjwatson>               Breaks: python-qwt5-qt4 (< 5.2.1~cvs20091107+dfsg-6+b4) but 5.2.1~cvs20091107+dfsg-6+b3build2 is to be installed
<cjwatson> Overly-specific Breaks 'r' us.
<xnox> infinity: I didn't think canadian television is that bad, that you prefer watching build logs instead..... =)))))))
<infinity> xnox: Build logs are exciting.  It's like rubbernecking at car accidents and train wrecks.
 * cjwatson tweaks sip4's Breaks.  This should work a bit better.
<cjwatson> Any release team member want to double-check that for me and unblock it?
<cjwatson> http://paste.ubuntu.com/5799998/
<infinity> cjwatson: The second one seems fine (and upstreamable), I'd probably just reupload pyqwt5 as +b4 to deal with the first, though.
<infinity> Since +b3build2 is silly anyway. :P
<cjwatson> I was suspicious since it's rare for +b3 to make it into *source* version numbers.
<infinity> It was an attempt to fool the Debian breaks, I believe.
<cjwatson> But apparently ... yes, it really was manually inserted.  Weird.
<infinity> So, if we're already on that path, may as well upload a +b4
<cjwatson> Unfortunately I've already uploaded sip4.
<infinity> Oh, so much for the double-checking. :)
<cjwatson> So might be better to stick with that change if it's at least minimally acceptable
<cjwatson> Sorry, that was double-check before unblock rather than before upload.  Maybe I should have done the latter
<infinity> Breaks against binNMU versions are amazingly broken and wrong anyway.  Someone needs to yell at the Debian maintainer.
<infinity> Cause any new port (for instance) will have to binNMU 4 times to make things installable, for no good reason. :P
<cjwatson> I don't know what that's there for.  I assumed there was some arcane apt-fooling reason, but it does seem odd.
<cjwatson> Your reasoning is indeed sound.
<cjwatson> pyqwt5 is just long enough that waiting for it to finish would push me past bedtime, so I think for the moment I'll not upload that
<infinity> cjwatson: Sure, there's no need for us to unwind this mess, except that it's remarkably unpretty.
<infinity> cjwatson: I'll unblock sip4 after I ingest some food.
<cjwatson> I need to do some laundry, but I'll come back to make sure this mess all works.
<barry> @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:
* holmes.freenode.net 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: barry
<sarnold> barry: freenode netsplit put the /topic back -- you may want to re-run @pilot out
<barry> @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:
<barry> sarnold: thanks ;)
<sarnold> barry: woo :)
<ScottK> cjwatson: Thanks.
<ScottK> infinity: I can take care of the unblock.
<ScottK> cjwatson: Don't worry, that's mostly just me being really frustrated at the moment.  I'll get over it.
<cjwatson> Well, the offer stands in any case; I know we don't require notification of transitions the way debian-release does, and of course you're on ubuntu-release anyway, but it can still help to have more eyes on things if only to nudge them along at appropriate times.
<infinity> ScottK: Okay, then I'll blissfully ignore it unless you poke me with an issue.
<ScottK> OK.
<ScottK> Just finished, so we'll know in 40 minutes.
<TheMuso> @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: TheMuso
<ScottK> I love how things have improved (new rant):
<ScottK> $ pbuilder-dist raring login
<ScottK> raises the error "distro_info.DistroDataOutdated: Distribution data outdated." and quits.
<ScottK> Yes, it's been a while since that box got updated, but it's ridiculous to bail out of doing stuff about releases it knows about.
 * ScottK tries to remember where to file the bug.
<cjwatson> distro-info, probably either Debian or Ubuntu is fine
<cjwatson> Or post a love letter to bdrung :)
<ScottK> Yeah, just filed it in Ubuntu.
#ubuntu-devel 2013-06-26
<ScottK> Meh.  autopkgtest for python-qt4 4.10.2-1ubuntu1: RUNNING
<cjwatson> Hm, yeah, it would, I suppose.  It might be quick enough that the run I'm doing now will pick it up ...
<cjwatson> The hint was typoed so it wouldn't have gone through in that run in any event
<cjwatson> Last run was 12 minutes.  Maybe.
<ScottK> Thanks for fixing.
<cjwatson> Still running.  I'll go and make my son's lunch for tomorrow and then see ...
<cjwatson> It's done now.  I just missed it last time
 * cjwatson reruns
<cjwatson> Might squeeze it in before the next publisher run if I'm lucky
<cjwatson> ScottK: final: avogadro,calibre,pykde4,pyqwt3d,pyqwt5,python-poppler-qt4,python-qt4,qscintilla2,sip4,veusz
<cjwatson> phew
<ScottK> Thanks for the help.
 * cjwatson -> bed
<ScottK> Good night.
<TheMuso> @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:
<pitti> Good morning
<pitti> Laney: why is there a block on gucharmap?
<pitti> Laney: the MIR was resolved, so it built fine now
<ScottK> There's a block on a lot of stuff for Alpha 1.  It's not that, is it?
<pitti> ScottK: oh, could be, yes
<tvoss> ScottK, ping
<dholbach> good morning
<ScottK> tvoss: Hello
<ScottK> tvoss: Missed your chance.  I'm going to bed.
<darkxst> cjwatson, the syslinux splash on ubuntu GNOME images is a bit broken, do you know where that is configured?
<darkxst> cjwatson, we only get the text based screen, and the language selector is active (like F2 had been pressed)
<pitti> I thought the latter was deliberate
<pitti> to avoid having to present English text to find out how to set the language
<darkxst> pitti, ok, but there is still the first issue why we only get text-based splash
<pitti> right
<darkxst> I believe that was the case for raring images also ;(
<Noskcaj> roaksoax: This is your daily reminder to allocate a day to testdrive
<doko> didrocks: why is google-mock shipping a shared libgmock which has references to a shared libgtest, which is never shipped?
<didrocks> doko: yeah, I realized that when looking at the package the other day and I think we inherited that from debian
<xnox> doko: because google-mock shouldn't ship any shared libraries, but it's a mini transition where we need to fix r-build-deps first to use shared google-mock src code shipped by the package & then sync from debian.
<xnox> e.g. unity ;-)
 * xnox thinks there was a tracking bug about that.
<xnox> bug 1185265
<ubottu> bug 1185265 in unity (Ubuntu) "please stop shipping pre-build google-mock, instead all reverse-depends should compile their own google-mock" [Undecided,New] https://launchpad.net/bugs/1185265
<doko> didrocks, xnox: hmm, so the ftbfs should go away when merging the package from debian.
<didrocks> doko: I don't think so, I tried to build it with the same FTBFS
<didrocks> we inherited the issue from them, as told
<doko> didrocks, but then why ship a shared libgmock?
<xnox> building debian package I get undefined reference to pthreads.... despite -pthreads present on cmd line.
<didrocks> doko: I don't think that the shared libgmock is linked to the FTBFS, did you try building the debian source? I did and same issue
<didrocks> the one that xnox is telling ^
<doko> didrocks, the ftbfs goes away if you explicitly link against -lpthread
<doko> but then dpkg-shlibdeps complains about unresolved references, so this shipped libgmock can never properly work
<didrocks> doko: please feel free to sync from debian and add that, I tried adding -lpthread without any success here
<doko> didrocks, did you check that it is ok to discard the ubuntu changes?
<didrocks> doko: I'm fine with it for the unity side, I'll fix those packages so that we build our own google-mock
<didrocks> (the ones we are upstream for anyway)
<bdrung> ScottK: the correct target is pbuilder-dist in this case, but love letters are accepted, too. ;)
<doko> didrocks, http://people.canonical.com/~doko/tmp/ not uploading, so you can coordinate with the rest
<didrocks> doko: ah, thanks a lot! will handle that this week :)
<doko> didrocks, so the proper fix seems to be to that the package respects --enable-external-gtest and doesn't build it again
<doko> which it apparently doesn't do
<didrocks> yep
<doko> tvoss tries to escape me ...
<doko> ScottK, kde4libs explicitly b-d's on gcc-4.7. why?
<doko> ahh, infinity made a "fix"
<Laney> doko: Check out the previous build logs on armhf.
<xnox> doko: on armhf, if FTBFS otherwise, compiler ice.
<xnox> doko: yeap.
<Laney> "This bug is not reproducible" thing which was reproducible...
<Laney> not sure if anyone reported it on gcc though
<xnox> i didn't yet. was on my todo list......
<ScottK> doko: I filed Bug #1194501  to keep track of this.
<ubottu> bug 1194501 in gcc-4.8 (Ubuntu) "ICE on gcc-4.8 building kde4libs" [Undecided,New] https://launchpad.net/bugs/1194501
<OdyX> tkamppeter: saw it, cool. Does cups still build with these ?
<doko> ScottK, how do you restart the kde4libs build?
<ScottK> doko: Before that build was superseded I just hit the retry button in launchpad.
<ScottK> All the build logs are from the same upload.
<doko> ScottK, how do you restart a failed kde4libs build, without re-configuring
<ScottK> Ah.  I see.
<ScottK> I'm pretty sure passing -nc to dpkg-buildpackage is enough.
<ScottK> Sorry, /me had < 3 hours sleep the last three nights in a row, so I'm likely not fully coherent.
<tkamppeter> OdyX, CUPS should build without cups-filters and its build process should not depend on changes in cups-filters.
<OdyX> tkamppeter: hmmm. It doesn't. I had to add cups-filters to build-depends to get the test-suite to complete.
<cjwatson> darkxst: OK, if nobody else looked while I was offline, I guess I'll need to grab an image to look
<tvoss_> ScottK, ping
<tvoss_> ScottK, succeeded in installing kubuntu-desktop after manually install kde-workspace
<ScottK> OK.  I'll be offline for the day in ~a minute.  Please chat with Riddell.
<tvoss_> ScottK, ack and thx
<zyga> jcastro: hey, I must say I'm really interested in the juju + openstack virtual thing that one can deploy on a laptop
<zyga> jcastro: do you have any details on how that work, you've mentioned a blog
<pitti> fginther: good morning
<pitti> fginther: I think I bent the ap-gtk tests to my will now
<pitti> fginther: so if I can bother you to re-review? after that lands, I can create three MPs for three bug fixes, but they all add/change tests
<jcastro> zyga: http://javacruft.wordpress.com/2013/06/25/virtme/
<zyga> thanks
<jml> was just asking a question on behalf of an acquaintance on #ubuntu [http://askubuntu.com/questions/312927/booting-13-04-64-bit-pendrive-in-uefi-freezes-immediately-after-loading-ramdisk]. surprised there's so few devs there.
<yolanda> hi, i'm just going to work in the ipxe FTBFS
<tkamppeter> OdyX, this is really strange, "make test" should only test the source package itself and not require anything which is not needed for building the package. To build and test CUPS from scratch a user has to configure make, and install CUPS to be able to build cups-filters, then he has to configure, make, and install cups-filters to be able to test cups. I would consider this as a bug in CUPS upstream. "make test" should be independent
<tkamppeter>  of cups-filters. Also if "make test" of CUPS fails we should be sure that we have to fix CUPS and not cups-filters.
<OdyX> tkamppeter: I can't disagree. In my case I couldn't get the cups testsuite to run without cups-filters.
<tkamppeter> OdyX, can you report this to Mike? Thanks.
<OdyX> tkamppeter: Hrm. I can do, but I need to test all our patches to see which one breaks what.
<jbicha> barry: I updated bug 1194526 with a new debdiff if you want to re-sponsor to fix the ftbfs
<ubottu> bug 1194526 in libgsf (Ubuntu) "Merge libgsf 1.14.27-1 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1194526
<barry> jbicha: thanks.  i have some meetings coming up, but will take a look this afternoon
<jbicha> barry: thanks
<cjwatson> darkxst: so, I'm not sure what you mean about only getting the text-based screen - do you mean that you want the same kind of behaviour that's in Ubuntu where you just get an icon until you press a key?
<OdyX> tkamppeter: http://alioth.debian.org/~odyx-guest/cups-str-1.6-2013-06-26-didier.html <- is what you get if you disable the cups-filters patch
<chrisccoulson> cjwatson, did you see that chromium failed on heka again? (but this time, in a different place and much earlier too)
<cjwatson> I didn't but I guess you can sort it out?
<chrisccoulson> cjwatson, not sure. it hit an internal error in the linker this time, which it didn't hit on the previous build: https://launchpadlibrarian.net/143369029/buildlog_ubuntu-precise-armhf.chromium-browser_28.0.1500.52-0ubuntu1.12.04.1_FAILEDTOBUILD.txt.gz
<cjwatson> feel free to retry if it looks like hw corruption
<chrisccoulson> cjwatson, ok, i've got to do another upload in any case
<debfx> jodh: procenv doesn't print the test output to the build log anymore :(
<xnox> debfx: automake-1.13 doesn't, changing to serial-tester will get that back.
<cjwatson> Or cat test-suite.log at the end?
<cjwatson> automake seems to be fairly aggressively deprecating the serial test harness, so it might be safer not to assume it
<Laney> Is there a way to tell automake to do that?
<tkamppeter> OdyX, the CUPS test suite contains tests which are out of the scope of the CUPS package as printing JPEG, TXT, ... upstream CUPS does not ship this functionality any more and so these tests are actually testing cups-filters. These tests should be removed from upstream CUPS.
<tkamppeter> OdyX, test jobs with filters should only use the filters which come with CUPS.
<OdyX> tkamppeter: can't disagree. :)
<OdyX> tkamppeter: do you want me to report: I can't before tomorrow.
<jodh> debfx: yes I know :-( See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710955
<ubottu> Debian bug 710955 in automake "automake: how to force a verbose build with automake 1.13?" [Normal,Open]
<jodh> check.am in automake-1.13 still includes "test x"$$VERBOSE" = x || cat $(TEST_SUITE_LOG);" but I cannot make VERBOSE work :(
<tkamppeter> OdyX, please do so.
<Laney> jodh: I only played very quickly but it also didn't work for me
<Laney> let me know if you get it
<tkamppeter> OdyX, I am releasing cups-filters 1.0.35 now.
<cjwatson> jodh: Might be worth asking upstream directly
<cjwatson> help-automake or similar
<jodh> cjwatson: ack - will do.
<cjwatson> Looks like it's just automake at gnu.org actually
<tkamppeter> OdyX, I have release cups-filters 1.0.35 upstream now. I have also updated the BZR repo of the Debian package, so it is ready for you to upload cups-filters 1.0.35 to Debian.
<OdyX> tkamppeter: will do tomorrow then, thanks.
<jml> cjwatson: can I persuade you to take a look at http://askubuntu.com/questions/312927/booting-13-04-64-bit-pendrive-in-uefi-freezes-immediately-after-loading-ramdisk ?
<cjwatson> jml: posted some hints on at least getting more data
<jml> cjwatson: thank you :)
<bdmurray> Sweetshark: could you have a look at bug 1194740?
<ubottu> bug 1194740 in libreoffice (Ubuntu) "[precise] Saving xls files originally created in Excel 2003 causes considerable increase of file size" [Undecided,New] https://launchpad.net/bugs/1194740
<darkxst> cjwatson, yes basically, apparently the text-based menu is not accessible for screen-readers
<darkxst> but then I also suppose that the ubiquity menu can't be re-branded to be flavour specific?
<slangasek> infinity: around?  I think I need another brain to look at bug #1187318
<ubottu> bug 1187318 in plymouth (Ubuntu) "Splash skips text when asking for LUKS password" [Undecided,Confirmed] https://launchpad.net/bugs/1187318
<slangasek> infinity: i386-only, a plymouth upstream commit that adds a reference to ply_get_timestamp() from the 'script' theme engine breaks pango text display... I've checked everything I can think of to explain this.
<infinity> slangasek: I was just heading out to dinner, but my brain might be functional upon my return.
<slangasek> infinity: ok - the problem will be here when you return, I'm sure ;)
<infinity> Heh.
#ubuntu-devel 2013-06-27
<infinity> slangasek: Dude.  Lolwut?  I made the mistake of reading the bug log from top to bottom and thinking "oh, sure, this should all come down to something obvious and debuggable".
<infinity> slangasek: And then your bisect conclusion broke my brain.
<infinity> slangasek: A wild shot in the dark, but would changing that (int) cast to (unsigned int) fix it?
<infinity> slangasek: srand() takes a uint, not an int, which could be causing curiosity on 32-bit but not 64-bit systems (perhaps throwing rand off for something else in the same process space, or god knows what).
<infinity> slangasek: Is there a simpler reproducer for this than "install a VM with encryption"?  Like, starting a plymouth splash and throwing text at it somehow?
<slangasek> infinity: I've reproduced it by changing the code to call ply_get_timestamp() *and discard the result*
<infinity> slangasek: Oh, that's fun.  WTF does ply_get_timestamp() do?
 * infinity grabs the source/
<slangasek> infinity: reproducer: install plymouth-theme-ubuntu-logo in a VM, using the vga video driver, *not* the vmvga driver; call 'plymouthd --tty=/dev/tty7 && plymouth show-splash && plymouth ask-for-password --prompt='lolwut'
<infinity> ply_get_timestamp seems to be used all over...
<slangasek> yup
<infinity> As does the incorrect cast to srand() so, yeah, that would be a red herring.
<infinity> (Should still be fixed, IMO)
<slangasek> infinity: and ply_get_timestamp(), if you haven't already found it, is: http://paste.ubuntu.com/5803595/
<slangasek> infinity: and inlining all of that code in script_lib_math_setup() does not trigger the bug
<infinity> ...
<slangasek> infinity: and creating a *copy* of ply_get_timestamp() as a static function in script-lib-math.c does not trigger the bug
<slangasek> and linking with -Wl,-z,now does not change the footprint of the bug.  script.so invokes ply_get_timestamp(), the bug occurs.  script.so does not invoke it, bug does not occur.
<infinity> I assume this lands in a libplymouth DSO?
<slangasek> ply_get_timestamp() is in libply.so.2; the caller is the script.so theme engine
 * infinity nods.
<slangasek> LD_DEBUG=symbols shows no differences between the working and broken versions
<slangasek> so... what am I missing? :)
<infinity> The symbol tables in the amd64 and i386 lib certainly look the same, so that's probably chasing the wrong direction.
<slangasek> I suppose I could single-step around ply_get_timestamp(), and see if anything looks crazy
<slangasek> but I don't understand how this could be having an effect on text rendering. :P
<infinity> Yeah, that's a bit of a stumper.
<infinity> You'd expect something this potentially broken to do something more helpful like segv or just plain not work.
<infinity> If only it was broken at all.
<infinity> slangasek: Good luck with your obscure bug.  I have to run out for a previous commitment.
<slangasek> infinity: heh, ok
<slangasek> enjoy :)
<infinity> slangasek: If I have a half-drunken epiphany, I'll be sure to blurt it out when I get home.
<slangasek> sounds good
<pitti> Good morning
<dholbach> good morning
<m4n1sh> ev: just a friendly reminder. please look into those 2 bugs when you get time
<ev> m4n1sh: on it this morning :) thanks!
<steveire> Hi there. http://anonscm.debian.org/gitweb/?p=collab-maint/cmake.git;a=summary is a repo of the cmake debian package. It is very useful. Can I find something similar for gcc? http://thread.gmane.org/gmane.linux.debian.ports.arm/12742/focus=12778
<geofft> steveire: http://packages.qa.debian.org/gcc-4.8 -> VCS link on the left
<geofft> that should work for approximately any Debian package that is maintained in a VCS
<steveire> geofft: Great, thanks.
<steveire> geofft: Is the system down? http://paste.kde.org/783704/
<geofft> Bah, is this Alioth being silly again? Try anonsvn instead of svn, maybe
<geofft> Er, no.
<steveire> anonscm works, thanks
<geofft> yeah, that's what I meant.
 * xnox wishes pastebinit would be available on ubuntu desktop cd.
<steveire> doko: ping?
<doko> steveire, ?
<steveire> doko: Hi. Did you see my mail?
<doko> about what?
<steveire> doko: http://thread.gmane.org/gmane.linux.debian.ports.arm/12742/focus=12786
<doko> this is to ensure that you have a standalone cross compiler which doesn't depend on and conflicts with foreign architectures
<steveire> Can you say more?
<steveire> How does putting the stuff in gcc-cross/ instead of gcc/ have anything to do with foreign architectures ?
<steveire> or dependencies (I assume you mean package-dependencies)?
<doko> you can't install the -dev packages of the foreign arch
<steveire> Ah, so this is all about -dev packages.
<steveire> I don't see any available -dev packages actually. What -dev package do you mean?
<doko> apt-cache showsrc gcc-4.8
<steveire> Some of this stuff? http://paste.kde.org/783890/
<steveire> libgcc-4.7-dev specifically I guess.
<seb128> doko, hey, did you see the new comment on the gtk bug?
<steveire> doko: I still don't understand how this dev package issue relates to the gcc/ vs gcc-cross/ directory.
<doko> seb128, yes working with zhen on it
<doko> steveire, what don't you understand?
<seb128> doko, great, thanks
<steveire> doko: I don't understand the need to put the cross compile dirs in gcc-cross/ instead of in gcc/ . I don't understand how that has anything to do with the -dev package of $something, which I assume is libgcc-4.7-dev. The file listing doesn't give me any clues: http://paste.kde.org/783902/
<doko> steveire, you can't install libgcc-4.7-dev for the target together with the cross compiler
<steveire> doko: Sorry. Are you saying that if there was another version of  libgcc-4.7-dev like libgcc-4.7-arm-linux-gnueabi-dev you could not install that together with gcc-arm-linux-gnueabi? Why not? No matter the answer, how do you get from that fact to the conclusion that the stuff must be in gcc-cross/ instead of gcc/ ? There are missing logical steps in what you have been saying here. The two statements about -dev packages and the gcc-cross/ directory seem
<steveire> to be non-sequiturs.
<doko> steveire, cross build tools must not get in conflict with the the target arch. why is it so difficult to understand that?
<steveire> doko: I can see I've got all the useful information out of you I'm going to get. Thanks.
<doko> steveire, and thanks for not answering my question
<steveire> "my question" == "why is it so difficult to understand that?" ? What kind of answer would you want to a question like that? If I were to ask you a similar question it would be: 'Why is it so difficult to give a reason for putting the files in gcc-cross?' Doesn't that look like an anti-social question to you? It does to me, so I'll not ask it :).
<steveire> Anyway, I'll just post your answer to the mailing list and see if someone else can interpret it.
<xnox> steveire: i'm not sure, but on my amd64 host i can have native amd64 compiler, native i386 compiler and cross from amd64->i386. IMHO this is reasonable to co-install native and cross compiler for the same target architecture, thus the requirement for separate /gcc/ and /gcc-cross/ in case native&cross c runtime files are different.
<xnox> steveire: same story with arm64 host & armhf native and armhf cross compilers.
<doko> steveire, your paste shows libgcc-4.7-dev:amd64, not libgcc-4.7-dev:armhf. maybe that is you misunderstanding
<steveire> doko: Maybe. I just guessed the package. You didn't specify one :).
<steveire> xnox: Thanks, let me think about that for a moment.
<doko> what other -dev packages are in the gcc-4.x sources that I had to specify.
<doko> still not knowing what you are trying to achieve, and what it has to do here on this channel ...
<steveire> xnox: So a armhf native compiler would run on a arm64 host? Why would you install a armhf cross compiler on the arm64 host if you have a native one?
<steveire> xnox: And you are confirming that my point 2.2 here is the correct one: http://thread.gmane.org/gmane.linux.debian.ports.arm/12742/focus=12786 ?
<xnox> steveire: to compare the two toolchains, for example and well because you can. Let me rephrase/flip your question into: "Why limit and make them artificially conflict?" plus if both are different yet are using same location then they can't be multi-arch:same
<[diablo]> Good morning barry , are you around please?
<xnox> xnox: md5sum different, but possibly interchangeable. i'm not sure.
<steveire> xnox: Ok, that's clear. Thanks.
<cjwatson> steveire: It makes cross-building easier if you have as few conflicts as possible; you can sometimes end up with too many packages installed depending on the precise way build-dependencies are spelled, and it's helpful if things still work anyway
<cjwatson> (This is a special case of the principle that it makes everything easier if you have as few conflicts as possible :-) )
<steveire> Right. It causes a problem for clang though: http://thread.gmane.org/gmane.comp.compilers.clang.scm/73551/focus=73568
<steveire> I think I have the information needed to justify the patch now though. Thanks for the information.
<doko> rsalveti, what are these ABI changes you mention in the libhybris upload?
<ogra_> doko, apparently there are issues with float vars that get pushed through the socket if one side (android) is built with 4.7 while the other (ubuntu) used 4.8 for building
<doko> ogra_, hmm, I'm not aware of such a change. so a test case would be good
<seb128> doko, similar to https://code.launchpad.net/~ricmm/platform-api/gcc-4.7-abi/+merge/171643 I guess
<seb128> "GCC 4.8 introduces a change for ARM AAPCS calling conventions"
<ogra_> doko, ricmm was referring to paragraph 4 in http://gcc.gnu.org/gcc-4.8/changes.html
<ogra_> right aapcs
<ogra_> rotation and ambient light sensor shoot float data over the socket that arrives as nonsense on the ubuntu side
<doko> ahh, thanks
<barry> [diablo]: hi
<[diablo]> hey barry
<[diablo]> barry, wondered if I could possibly pop quiz you on flufl.lock once again ;-)
<barry> [diablo]: sure :)
<[diablo]> here or prefer a PM?
<barry> pm
<pitti> jcastro: hey Jorge, how are you?
<jcastro> hi pitti!
<jcastro> how can I help you this fine morning?
<pitti> jcastro: cleaning up old mail, WDYT about mothballing brainstorm now?
<jcastro> I didn't want to kill it without having the information available to the community
<jcastro> but IS needs to do a review of the database to ensure there is no privacy-sensitive user information there
<pitti> ah, ok
<jcastro> we could take it down immediately, but I wanted the data dump available if someone wanted to take it and do something with it
<pitti> jcastro: we could perhaps disable write access, so that the thing stays there for historic reasons?
<jcastro> yeah, I'll go ahead and ask IS and move forward, thanks for the prod
<chrisccoulson> cjwatson, looks like this is going to be a success now (on dactyl): https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4749276
<cjwatson> Cool
<cjwatson> "Stripping symbols from enormous libraries" is a good progress comment
<chrisccoulson> heh
<seb128> hum
<seb128> is that about dh_strip running out of resources?
<seb128> we got a webkit armhf build that failed on that earlier
<chrisccoulson> seb128, i'm not sure. maybe ask qengho about that?
<sladen> oh my, ubuntu-devel@ is friendly these days
<rsalveti> doko: yeah, aapcs related
<ScottK> sladen: It'd be easier to have a conversation if the start of the thread was more reality based.
<xnox> cjwatson: new debhelper upload has a fix for debbug 713257
<xnox> cjwatson: which at the same time, now fails to detect a check target and therefore dh_auto_test doesn't forexample run upstart's test suite.
<qengho> seb128: I have never seen dh_strip run out of resources.
<manish> ev: actually I was more worried about this one LP #1192778 because I was unable to get it working
<ubottu> Launchpad bug 1192778 in Activity Log Manager "Diagnostics tab doesn't show in standalone mode" [Medium,Confirmed] https://launchpad.net/bugs/1192778
<ev> manish: I don't understand why we want it to show in standalone mode?
<ev> the diagnostics tab is useful for Ubuntu, which uses a-l-m as a control center module
<manish> ev: because of ubuntu gnome
<ev> ah, *grumbles*
<manish> it doesn't have g-c-c patch I guess
<manish> but still uses whoopsie for error collections
<manish> I mean patched g-c-c to add more panels
<ev> yeah, this is a simple matter of playing with automake to build the whoopsie stuff when the control center module is not built
<manish> I have added a patch on that bug
<manish> but it segfaults
<manish> it looks close, but segfaults were making me mad
<manish> ev: so you can either work over it or start afresh
<ev> :) thanks. I'm at the end of my day, but I'll have a look in the morn'
<manish> that's good to hear
<manish> good night
<dobey> kenvandine: ! hey. for the uoa stuff, can a plug-in just create wholly custom UI for doing login/registration for a service, or does only oauth/openid type stuff that opens a browser work?
<kenvandine> dobey, you mean you want to open a browser?
<kenvandine> it can load a webview or display a form type UI
<dobey> kenvandine: no, don't want to open a browser
<kenvandine> dobey, however, with system-settings a plugin can provide qml components to display in the UI
<kenvandine> so a bit more flexible on the UI
<dobey> kenvandine: oh. are there docs on how to do a plug-in in qml that's not standard oauth stuff?
<kenvandine> dobey, of course not :)
<kenvandine> you can look at what gets installed by account-plugin-facebook
<dobey> yeah, we were just looking at the qml for it. and it's OAuth { some_stuff_with_http_and_whatnot() }
<kenvandine> humm
<kenvandine> not sure what OAuthMain {} really includes
<kenvandine> that is from Ubuntu.OnlineAccounts.Plugin
<kenvandine> dobey, ah... look at /usr/share/accounts/qml-plugins/example/Main.qml
<kenvandine> provided by ubuntu-system-settings-online-accounts
<dobey> hmm
<kenvandine> that should probably not get installed :)
<hallyn> could someone on SRU team please look at (and hopefully accept) https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=qemu-kvm ?
<kenvandine> but that is an example that includes other UI elements
<hallyn> the 1.0+noroms-0ubuntu14.10 is a better fix than 1.0+noroms-0ubuntu14.9, and meant as a replacement, not a followup
<hallyn> (it removes the 1.0+noroms-0ubuntu14.9 fix)
<dobey> kenvandine: is that the upstream project name too?
<kenvandine> yes
<dobey> ick :)
<kenvandine> dobey, i'd rather something explicit like that than *indicat*
 * kenvandine is looking at tedg
<dobey> kenvandine: uss-online-accounts at least would have been "cooler" :)
<kenvandine> hehe
<dobey> kenvandine: even if it's not a big boat
<hallyn> SpamapS: ^ in a case like that, is there a tag should be setting on the bug?  I suppose I coudl set verification-failed, though technically it didn't fail, rather the previous fix was deemed just a workaround...
<SpamapS> hallyn: the tags are just signals to us as to whether or not users feel the bug should stop or progress
<SpamapS> hallyn: verification-failed is "do not promote this"
<hallyn> SpamapS: right, and that's sort of what i want
<hallyn> i want the next one in unapproved to take its place
<SpamapS> then yes, leave it verification-failed and the sru-accept will replace it
<hallyn> ok, thanks
<hallyn> (done, this was bug 1189926 fwiw)
<ubottu> bug 1189926 in qemu-kvm (Ubuntu Precise) "data corruption in storage attached to VM using KVM" [High,Fix committed] https://launchpad.net/bugs/1189926
<hallyn> arges: ^ hopefully that gets the ball rolling again
<barry> cjwatson: still around?
<arges> hallyn: did i mess something up?
<arges> hallyn: oh i see you'll upload the new patch : ) thanks
<hallyn> arges: I uploaded it quite some time ago, but it never got promoted because the previos one was still waiting to be promoted
<arges> ah
<slangasek> infinity: so, no late-night headaches giving you visions to explain what's wrong with plymouth? :)
<slangasek> I've looked at gdb disas output on ply_get_timestamp(), and I don't see anything amiss.  maybe this needs someone who's better at x86 asm than me.
<infinity> slangasek: I was entirely epiphany-free last night.  And x86 asm is definitely not my forte.
<slangasek> infinity: whose forte is it?
<infinity> slangasek: I could point you at any number of Intel employees, if that's helpful. :P
<slangasek> hmm :)
<infinity> slangasek: ( Not relevant to the livecd-rootfs/eatmydata discussion we had, but vaguely related, should someone decide that regular buildds should get such a treatment: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713035 )
<ubottu> Debian bug 713035 in eglibc "eglibc: FTBFS when built with eatmydata" [Normal,Open]
<infinity> slangasek: TL;DR: eatmydata doesn't wrap sync convincingly enough to not eff up testsuites.
<lifeless> surely that should be a bug on eatmydata?
<infinity> lifeless: It's been cloned and reassigned already.
<lifeless> ah
<lifeless> sucks to be me :)
<slangasek> infinity: yeah, someone raised that bug to my attention already :)
<Noskcaj> kirkland_, roaksoax: This is your daily reminder to find a day for testdrive
<gQuigs> I'm trying to build samba to fix a bug, but failing: http://pastebin.ubuntu.com/5805829/
<gQuigs> running: debuild -uc -us  in the directory from apt-get source samba
<maxiaojun> hi, guys, I find some packages' section is probably wrong
<maxiaojun> imho
<maxiaojun> unity-webapps-* should belong to 'main'
<maxiaojun> ubuntu-sdk and dependencies should belong to 'main'
<maxiaojun> dependencies of "ubuntu-restricted-extras" should be long to multiverse
<ogra_> maxiaojun, that requires a main inclusion report and an extensive review process
<ogra_> packages usually enter the archive in universe before they get promoted to main
<jbicha> maxiaojun: multiverse depends on universe
<maxiaojun> universe -- community-maintained FOSS
<ogra_> just be patient, unity-webapps as well as the sdk will be in main by release day
<maxiaojun> multiverse -- Software restricted by copyright or legal issues
<maxiaojun> i guess dependencies of "ubuntu-restricted-extras" are indeed "Software restricted by copyright or legal issues"
<infinity> maxiaojun: Not all of them.  Is there a specific one you're concerned about?
<maxiaojun> i think most of them are
<maxiaojun> the problem is, if I disable 'multiverse', the repo still contains non-free software
<ogra_> surely not
<maxiaojun> on the other hand, if I disable 'universe', I miss some important but non-free software
<ogra_> it might contain a metapackage depending on nonfree sw ... but to my knowledge there is no nonfree stuff in universe
<infinity> maxiaojun: Which non-free software is in universe?  Names, please.
<maxiaojun> the codecs doesn't considered non-free?
<infinity> maxiaojun: "All the deps of ubuntu-restricted-extras" is not helpful, since plenty of its deps are free.
<ogra_> there are many open codecs, which ones specifically ?
<maxiaojun> *-bad *-ugly ?
<infinity> maxiaojun: Both of those are free, from a copyright perspective.
<infinity> maxiaojun: bad is "bad" because of quality concerns.
<ogra_> the package description is pretty informative :)
<ogra_> helps to read it ;)
<maxiaojun> "GStreamer plugins from the "bad" set" ?
<ogra_> thats the title ...
<infinity> maxiaojun: ugly is "ugly" due to potential distribution issues in some jurisdictions, but we don't split universe/multiverse according to random patent claims, only copyright concerns.
<infinity> (If we put everything that might be covered by a patent in restricted and multiverse, we'd have no main and universe left)
<infinity> Perhaps a slightly pessimistic world view of software patents, but probably not inaccurate.
<maxiaojun> The code might be widely known to present patent problems.
<maxiaojun> http://gstreamer.freedesktop.org/modules/gst-plugins-ugly.html
<ogra_> well, it is still opensource code under a free license
<ogra_> so it qualifies for universe ... no matter what patents there are
<ogra_> (and the patents are pointed out in the package description as you can see)
<maxiaojun> but it can be pulled automatically?
<ogra_> pulled ?
<maxiaojun> open a media file
<maxiaojun> then the media player would prompt to install additional package
<ogra_> yeah, it does that
<ScottK> tvoss_: When you made the XMir video, were you using non-standard settings for kwin effects on KDE?
<cjwatson> xnox: please report it to Debian - I won't be able to do anything until at least Monday anyway, and in any case Joey is way more familiar with the intricacies of make than I am
<xnox> cjwatson: ack. will make a minimal reproducer first.
 * ogra_ seriously wonders why infinity and I talked to maxiaojun .... if i have to answer the exact same stuff that was asked above by mail again
<Laney> ogra_: the mail came before irc
<ogra_> oh
 * ogra_ slaps himself to read timestamps 
<Laney> still duplication though
<ogra_> maxiaojun, sorry
 * xnox tries this Mir ppa.....
<xnox> it works rather nice.
#ubuntu-devel 2013-06-28
<pitti> Good morning
<tvoss_> ScottK, ping
<tvoss_> ScottK, for the effects/compositing setup: should be what comes as default when installing kubuntu-desktop
<ScottK> tvoss_: OK.  Thanks.  In the video, the effects looked less transparent, but that may just be the video.  It would have been nice to see more actual compositing effects demonstrated and some KDE apps.
<ScottK> I don't feel like I got much of a feel for it as it was.
<tvoss_> ScottK, hmmm, I can try with vanilla X and see if I notice any changes
<tvoss_> ScottK, any particular operation you want me to check except for playing around with it a little longer?
<ScottK> I'd be interested to see various window switching effects, like present windows, , box switch, cover switch, as well as some of the other effects like the outline effect on a focused window and the dialog darken effect.
<ScottK> I think seeing things like that are directly driven by kwin when using KDE apps would be more representative.
<ScottK> superm1: Would you please update the mythbuntu metapackage/seeds: http://people.canonical.com/~ubuntu-archive/NBS/ttf-droid
<tvoss_> ScottK, happy to do that, a screen cap is fine with you?
<ScottK> tvoss_: Sure.  Just trying to get a better idea of it.
<tvoss_> ScottK, mind pointing me at the keyboard shortcuts to activate the effects you want to see?
<ScottK> For present windows, I normally move my cursor to the upper left corner.
<ScottK> The window switching ones are alt-tab
<ScottK> I think ctrl f10 for present windows
<tvoss_> ScottK, cool, thx :)
<ScottK> the outline effect should be visible if you have multiple overlapping apps in the screen and one has focus.
<ScottK> For the darken dialog one, you'll have to arrange to have something pop up a diaglog
<tvoss_> ScottK, ack, any specific kde app you want to see?
<ScottK> No, it's more about the windeco/window than the contents.
<ScottK> Trying to exercise the things that kwin has direct control over.
<tvoss_> ScottK, sure
 * tvoss_ is off to kubuntu land for a minute or two :)
<tvoss_> ScottK, uploading to u1
<ScottK> Does that result in it going somewhere I can see it?
<tvoss_> ScottK, hmmm, I assumed you would have a u1 account
<tvoss_> ScottK, if not, where do you want me to put it?
<ScottK> Nope.
<ScottK> Anywhere public is fine.
<tvoss_> ScottK, let me see, youtube should work
<ScottK> I don't believe in storing data on systems I don't control.
<ScottK> Yeah.
<ScottK> At least not anything that shouldn't be public.
<tvoss_> ScottK, fair
<tvoss_> ScottK, I noticed that tracker is using quite a lot of cpu in the background. do you kick it off by default on session login?
<tvoss_> ScottK, hth: https://www.youtube.com/watch?v=8sKQnDAPEA4
<ScottK> I don't think nepomuk uses that normally, but that's probably what it is.  It can bog things down a bit on first run.
<ScottK> tvoss: Looks pretty good.  I get a much better sense of it from that.
<tvoss> ScottK, cool, glad that I could help
<ScottK> You might want to mention that in the comments to the first one or something.
<tvoss> ScottK, I will drop a mail to Jono
<dholbach> good morning
<seb128> dholbach, good morning my german friend! wie gehts?
<dholbach> hey seb128 - good good - yourself?
<seb128> dholbach, I'm good thanks ;-)
<brendand> why is openssh-server not in saucy?
<pitti> brendand: err, it better was.. and it is
<pitti> openssh-server |  1:6.2p2-5 |         saucy | amd64, armhf, i386, powerpc
<brendand> pitti, apt-cache search doesn't find it
<brendand> neither devscripts!
<brendand> something is wrong with my install then (most recent daily image)
<xnox> brendand: did you run apt-get update to get the package lists?!
<brendand> nothing wrong with sources.list
<xnox> ah, snap.
<brendand> xnox, doing that now
<brendand> xnox, that's a bug then, no?
<xnox> brendand: apt-cache is fully offline, it only looks up things in the downloaded package files.
<brendand> xnox, ah i know now - i couldn't get a connection during install because of a bug in ubiquity
<brendand> xnox, ergo it didn't run apt-get update during install (succesfully anyway)
<xnox> brendand: hence..... no caches. I do think that ubiquity in those cases should copy the stale cache from the cd though.
<xnox> but not sure if this should be implemented or not.
<ogra_> is there one ?
<xnox> ogra_: let me check.
<ogra_> i thought the cache is wiped during build
<ogra_> to save space
<xnox> ogra_: in /var/cache/apt/ pkgcache.bin is 5.1M and srcpkgcache.bin is 5.0M and nothing under archives/
<xnox> is that installed packages though?!
<xnox> ogra_: all is there for main and restricted under /var/lib/apt/lists/ 12M
<ogra_> hmm, could be a full cache should be bigger
<ogra_> we wipe /var/lib/apt/lists/ though
<ogra_> not sure the cache helps much without the list files
<xnox> but lists files are there as well.
<ogra_> oh ?
<ogra_> inside the squashfs ?
<xnox> yeap.
<ogra_> i always thought apt-setup handles them
<ogra_> from casper
<xnox> ogra_: http://paste.ubuntu.com/5807347/
<ogra_> yeah, i see
<ogra_> jodh, hey ho
<rbasak> So cgroups' kernel interface is changing, and non-systemd systems will need new code to cope: https://lwn.net/Articles/555920/
<rbasak> How much does this affect Ubuntu? Do we now need to write a cgroup manager?
<rbasak> hallyn: ^^ will this affect LXC at all?
<pitti> rbasak: I don't think it affects upstart a lot, but ICBW; it will affect containers (but that's being discussed upstream) and logind (but that will be handled by upstream, too)
<xnox> pitti: rbasak: It would be interesting to know if/how it affects lxc on ubuntu and nested-lxc on ubuntu.
<pitti> I asked stgraber about this the other day
<ogra_> definitely
<ogra_> given an essential bit of our stuff today depends on lxc
<ogra_> (touch, cloud)
<rbasak> How much do we need cgroup support in LXC?
<xnox> .... all of it?
<ogra_> yeah
<ogra_> without it it is just a chroot :)
<pitti> rbasak: for us this mostly amounts to pay attention to shipping matching kernel and lxc versions, AFAICS
<rbasak> Without cgroups there's still namespacing and apparmor
<rbasak> I guess on phone it'll be bad if an app uses 100% CPU or something
<ogra_> on the phone you will get issues with the running android init
<rbasak> Thanks for the comments anyway. I just saw the article and thought we might want to pay attention. I guess hallyn is the expert here for the LXC end of things
<jodh> ogra_: hi
<ogra_> jodh, so we have some slight probs with the container handling on ubuntu touch ... and i was wondering if upstart could help us ...
<ogra_> effectively we do not want the ubuntu system to handle certain things while android does the same inside the container
<ogra_> i.e. see bug 1190792
<ubottu> bug 1190792 in touch-preview-images "ueventd in a busy loop on container-flipped image" [High,Confirmed] https://launchpad.net/bugs/1190792
<ogra_> (we have plenty of such stuff)
<ogra_> jodh, i was wondering if it would be possible to have something like an init-to-init-bridge between the two so we can see in upstart what happens inside the container to then adjust our event handling accordingly
<jodh> ogra_: so you're talking about having androids init in lxc emitting events to the host systems upstart?
<ogra_> right
<ogra_> some kind of communication layer between host and container
<ogra_> currently we have a lot of override jobs that i.e. look for the existence of a socket and then fire the ubuntu process ... thats horridly racy
<ogra_> also bringing up the container on boot indeed costs several seconds, atm we can just wait for lxc-wait to make sure the OS inside the container is up, but that doesnt tell us if there is still stuff being processed ... racy again ...
<ogra_> if we could instead have a listener for the specific in-conrainer job to start when the services inside the container runs we wouldnt have to wait for the whole container to be up and could start bits in parallel
<jodh> ogra_: I guess the hacky way might be to poll with tools like lxc-ls/lxc-ps/lxc-nestat, but awe mentioned that some android services aren't even ready when the sockets appear so maybe we'd need to consider some sort of android service that talks back to the host? don't know enough about this tbh.
<ogra_> well, thats what i'm proposing :)
<ogra_> have either a hook in androids init (if it knows enough to give us any info) or have a watcher process that tells upstart about started processes
<ogra_> and yeah, apps can indeed create sockets before they are ready and fully attached, thats one of the probs we have
<ogra_> what we currently plan (and wich is really ugly) is for i.e. ueventd have it create a file in a shared space once it is done (kind of a udevadm settle with files) and have udev have a file-bridge handler watching it
<ogra_> i'm not proposing this for 13.10 but i think we should plan something similar for 14.04
<ogra_> (unless you think it's super easy and a thing of a days work to implement :) )
<doko> jamespage, could you have a look at all the maven build failures in the test rebuild?
<jodh> ogra_: you could do that now:
<jodh> ogra_: 'start on file FILE=/var/lib/lxc/raring/rootfs/tmp/foo EVENT=created'
<ogra_> not really, /var/lib/lxc/raring/rootfs/tmp/foo would never show up
<jodh> ogra_: ?
<ogra_>  /var/lib/lxc/raring/rootfs is only the input  your container runs somewhere in /proc
<ogra_> so files created in /tmp would show up in /proc/$lxc-pid/root/tmp ...
<ogra_> but we dont have $lxc-pid unless we explicitly process lxc-info output
<jodh> ogra_: a watcher process sounds like it would get more traction that hacking androids init, but I don't know what env is available to allow it to talk back to the host. maybe those that know lxc+android better than I could comment on a bp if you raise one?
<ogra_> you can create a socket in /dev/socket, thats shared for example
<ogra_> and /data will always be a shared dir since binary blobs depend on it on both sides
<ogra_> but while we will likely use the file approach through /data i dont think thats a proper solution
<ogra_> (in the long term)
<ogra_> jodh, oh, btw, i had tried to watch a socket with the file bridge ... seems i cant, it only seems to act on regular files, do you consider that a bug ?
<hallyn> rbasak: pitti: the actual kernel cgroups changes are somewhat independent of the systemd announcement
<hallyn> at some point it'll require a single unified hierarchy - that's no problem for us
<hallyn> lemme find the most soothing email in the thread,
<hallyn> http://lkml.org/lkml/2013/6/27/527
<hallyn> rbasak: ^ tl;dr : we'll all be experimenting for awhile and coming up wtih a new api
<jodh> ogra_: the bridge is using inotify, so I guess it's a limitation of inotify.
<ogra_> ah
<hallyn> the api is to set on *top* of cgroupfs, and we do want such a thing.  But if we want to be phillistines, we can always keep using cgroupfs :)
<tvoss_> didrocks, what is the blessed way to install a symlink from a packaging setup?
<didrocks> tvoss_: just do it like in a file, ship it, then dh_links will do the right thing for you :)
<didrocks> dh_link*
<didrocks> tvoss_: you can force creating some shipping debian/<package>.links (man dh_link)
<tvoss_> didrocks, thx
<didrocks> yw :)
<roadmr> xnox: hi! about bug 1194195, the binary package depending on gksu was checkbox-gtk, so all should be peachy if I remove that particular dep, right? (I'll be adding a depends on policykit-1 instead, in addition to code changes)
<ubottu> bug 1097816 in checkbox (Ubuntu) "duplicate for #1194195 Checkbox needs to use pkexec instead of gksu" [High,In progress] https://launchpad.net/bugs/1097816
<xnox> roadmr: yes.
<roadmr> xnox: ok, great! thanks. A fix should land in a few days then :)
<xnox> roadmr: awesome.
<jdstrand> mdeslaur: I've created a apparmor-easyprof-ubuntu package to ship our templates and policygroups
<infinity> mterry: To be clear on bug #1188935, were you okay with that being promoted despite the testsuite bug, or did you want that fixed first?
<ubottu> bug 1188935 in python-secretstorage (Ubuntu) "[MIR] python-secretstorage" [Undecided,Fix committed] https://launchpad.net/bugs/1188935
<mdeslaur> jdstrand: ok
<jdstrand> mdeslaur: the current version is 'ubuntu-0'. ie, things are installed in:
<jdstrand> /usr/share/apparmor/easyprof/templates/ubuntu-0/ubuntu-sdk
<jdstrand> /usr/share/apparmor/easyprof/policygroups/ubuntu-0/qmlscene
<mterry> infinity, I'm OK despite the test suite bug.  I just want the test suite bug fixed this cycle ideally
<mdeslaur> jdstrand: version 0? :P
<mdeslaur> jdstrand: odd choice :P
<infinity> mterry: Check.  Promoting, then.
<mterry> Or whenever gnome-keyring can be run under xvfb
<jdstrand> mdeslaur: I used 'ubuntu-0' just for namespacing. ie, the json manifest would use '"policy_version": "ubuntu-0"'
<mdeslaur> oh, yuck
<mdeslaur> why not just an integer there?
<mdeslaur> compating strings is painful
<mdeslaur> comparing
<jdstrand> easyprof supports that fine, I chose ubuntu-0 for namespacing
<mdeslaur> *cough*ugly*cough*
<jdstrand> mdeslaur: eg, if Debian wanted to ship easyprof templates, we would need to not collide
<mdeslaur> ok, if you want to do that, then do policy_vendor and policy_version
<jdstrand> jeez, you keep making me do more work :P
<mdeslaur> because now we have to start parsing strings all over if we want to do "older than version 3" checks
<mdeslaur> jdstrand: well, do it right the first time :)
<jdstrand> meh
<mdeslaur> hehe
 * mdeslaur hugs jdstrand
<sergiusens> cjwatson: hey, recalling the question about sdk apps and click, the fat package format is supposed to solve the arch specific packages right? I see there's an architecture entry I could add to the manifest today to workaround that until it's ready if that's the case
<cjwatson> sergiusens: fat packages are only needed if you want to ship multiple arches.  if you just need to ship one then you can just say "architecture": "armhf"
<cjwatson> the "problem" of shipping packages for a single architecture isn't one that needs solving :)
<sergiusens> cjwatson: great, so my temporary hack would be to use arch: armhf, but these apps would eventually need to be fattened up
<cjwatson> or linked or something
<cjwatson> we don't need to solve that problem just yet
<sergiusens> one less problem to deal with for now, I'll table it
<ev> manish: so this is going to be tricky. Since
<ev> activity log manager by itself is only vala code, not a c shim like the control center integration, it means extern'ing enough c code in alm.vala to get the diagnostics page up
<ev> manish: I'll keep at it, but can we release what we have? As the previous release disabled the diagnostics page, GNOME Ubuntu would be no worse off.
<jbicha> ev: that release wasn't in Ubuntu because it had a regression like that
<ev> jbicha: what's the regression?
<ev> the diagnostics page never appeared in a-l-m standalone.
<jbicha> what I meant was that alm 0.9.5 wasn't in Ubuntu
<ev> oh, right
<jbicha> ev: based on what you've said, I'm ok with releasing to saucy now with bug 1192778 unfixed but I'd really like it fixed before saucy is released
<ubottu> bug 1192778 in Activity Log Manager "Diagnostics tab doesn't show in standalone mode" [Medium,Confirmed] https://launchpad.net/bugs/1192778
<ev> jbicha: *nods* I'm working on it, I just don't want the release to block on it. :)
<barry> jbicha: the debdiff in lp: #1194526 comment #4 doesn't apply cleanly to the current saucy branch of libgsf.  can you generate a new patch?  if not, i will adapt it
<ubottu> Launchpad bug 1194526 in libgsf (Ubuntu) "Merge libgsf 1.14.27-1 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1194526
<infinity> barry: Meh, I'll just do that merge myself right now, it's trivial.
<barry> infinity: thanks
<jbicha> thanks
 * infinity resurrects a lost changelog entry while he's at it.
<smoser> slangasek, what would be in local-filesystems that is not in filesystems ?
<smoser> ie, i have a system hung where local-filesystems ahs fired but not filesystems
<smoser> hm..
<xnox> what is responsible for clearing /forcefsck after it's been done?
<slangasek> smoser: I guess you mean the other way around?  things in filesystem but not in local-filesystems; that would be network filesystems, by and large... 'filesystem' should be the union of 'local-filesystems' and 'remote-filesystems' IIRC
<smoser> yeah.
<smoser> slangasek, do you have a minute
<jodh> smb: we even have a picture: http://upstart.ubuntu.com/cookbook/#mountall-event-summary :)
<slangasek> smoser: ok
<smoser> ssh test@gwaclhostblkhljy4re3yp9swkdwp63kswkss9bqhn0zm3f3gunipzu5vwdr8qzw.cloudapp.net
<smoser> that system i think has not run rc yet. and i *thoht* had not emitted filesystme, but i don thtink thats rignht
<slangasek> smoser: cannot resolve hostname
<jodh> smb: oops - should have been smoser ;)
<smb> jodh, Very ..err nice. Why would we want that again. :)
<smb> ah
<smoser> slangasek, would it seem odd or bad for
<smoser> lockfile-create /var/lock/ntpdate-ifup
<smoser> to have been hung
<smoser> jodh, that 'last spoken tab completion' thing causes problems when both smb and i are talking
<smoser> i often say things to myself in that situation
<smb> smoser, Hey I haven't said a thing today. :)
<jodh> smb: we can hear your thoughts!
<smoser> slangasek, sorry. test@cf96b6aab6fe4ca8943422ee34fbca4b.cloudapp.net
<smoser> md5 hostnames for the win!
<smb> jodh, must be a lot of <beep>ing
<jodh> smb: hey, I like techno :)
<smb> :)
<slangasek> smoser: 'status mountall' -> stop/waiting; what do you see here that points to filesystem not having fired?
<smoser> slangasek, well, i think i have retracted that thought
<smoser> but
<smoser> $ ls -altr /var/run/landscape
<smoser> ls: cannot access /var/run/landscape: No such file or directory
<smoser> S45landscape should have created that.
<smoser> so it would seem it didn't run
<slangasek> smoser: if you run the script manually, what do you get?
<smoser> i haven tried. cause i didn't want ot ruin state
<slangasek> I see that the script will exit before creading the pidfile if check_config() failed
<smoser> ah. ok. then maybe i'm barking up the wrong tree then.
<smoser> why would lockfile hang ?
<smoser> the 2 instances i see hung like this have a lockfile pid hung
<ev> manish, jbicha I think I've got it. Just cleaning it up.
<slangasek> smoser: /etc/default/landscape-client doesn't exist; therefore RUN==0, CLOUD==0, and landscape-client won't start
<smoser> good enough.
<smoser> lockfile ?
<slangasek> not sure
<slangasek> strace?
<slangasek> futex(0x7f06a7d1f720, FUTEX_WAIT_PRIVATE, 2, NULL
<slangasek> looking pretty broken
<smoser> oh. the other thing . the otriginal thing that lead me to thinking filesystems hadnt been emited.
<smoser> cloud-init-config.conf hasn't run (or if it did, it didn't successfully log anything to /var/log/cloud-init.log)
<smoser> hm..
<smoser> i dont know
<smoser> i'm messed up.
<smoser> wait it did.
<smoser> i'm sorry.
<slangasek> smoser: so if I run lockfile-create directly under strace, it gives me this:
<slangasek> open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5
<slangasek> writev(5, [{"*** glibc detected *** ", 23}, {"lockfile-create", 15}, {": ", 2}, {"malloc(): memory corruption (fas"..., 34}, {": 0x", 4}, {"00000000023e8100", 16}, {" ***\n", 5}], 7*** glibc detected *** lockfile-create: malloc(): memory corruption (fast): 0x00000000023e8100 ***
<slangasek> ) = 99
<slangasek> rather rude of it to write to /dev/tty, I think
<smoser> cmdline has 'console=tty1 console=ttyS0'
<smoser> and that is probably coming through a console output job i suspect
<smoser> maybe ? trying to come up with some reason for it to be doing that.
<slangasek> no, the console settings don't explain why it would open /dev/tty which is the generic device
<xnox> hallyn: jdstrand: shadow with user name space support is in the archive ;-)
<jdstrand> neat
<jdstrand> sarnold: ^
<sarnold> jdstrand: woo :)
<sarnold> xnox: thanks :)
<sarnold> hallyn: thanks :)
<hallyn> xnox: woot, thanks!
<xnox> that's quite a party =)
<stgraber> yay!
<slangasek> infinity: upstream found the plymouth problem... no prototype for ply_get_timestamp() means that the double being returned by the function plays silly buggers with the floating point state
<slangasek> apparently we ought to be building plymouth with -Werror ;)
<sarnold> slangasek: wow...
<infinity> slangasek: Ah-ha.
<ogra_> root@ubuntu-phablet:/# dpkg -S /etc/rc6.d/S31umountnfs.sh
<ogra_> dpkg-query: no path found matching pattern /etc/rc6.d/S31umountnfs.sh
<ogra_> does anyone know from the top of his head where that comes from ?
<infinity> (base)adconrad@cthulhu:~$ dpkg -S /etc/init.d/umountnfs.sh
<infinity> initscripts: /etc/init.d/umountnfs.sh
<infinity> ogra_: Following the symlink would help. :)
<ogra_> oh
<ogra_> silly me
<ogra_> i should have looked in init.d
<ogra_> i wonder how even it would be to divert it ... it causes issues on phones
<ogra_> *evil
<ogra_> (reboot hangs at times)
<infinity> Perhaps sorting out WHY it causes problems would be good.
<ogra_> well, we will hopefully not offer nfs cloud access via mobile data :)
<ogra_> but yeah, if i could find that out i'd be happy as well
<infinity> Sure, but it does a bit more than the name would imply.
<infinity> So, it would be good to sort out what's breaking.
<infinity> As it may also affect other LXC setups or even normal desktops in some cases, etc.
<ogra_> http://paste.ubuntu.com/5808502/ is the processlist of a hanging boot
<ogra_> http://paste.ubuntu.com/5808513/ is the tail end of syslog
<infinity> sh -x /etc/rc6.d/S31umountnfs.sh stop ?
<infinity> Oh, wait.
<infinity> It's the very end that's hanging.
<infinity> So, blame it on upstart.
<infinity> Indeed, that's not the only initctl call that's hung.
<ogra_> right
<infinity> So, yeah, that's something we really should want to fix, not hackishly work around.
<infinity> I'd recommend filing an upstart bug and poking jodh and stgraber.
<ogra_> well, i would like to work around it for dogfooders ... indeed i did plan to research the cause and get it fixed
<infinity> ogra_: The problem I have with workarounds is that they seem to persist for two years before anyone notices and backs them out again.
<ogra_> heh
<ogra_> or even become permanent
<ogra_> for the phone stuff i have all of them in the lxc-android-config package ... and i expect the workaround part to be empty by release :)
<infinity> Anyhow, that's pretty clearly either an upstart bug, or a self-imposed mess due to container madness.
<stgraber> so if it's hanging on the emit for unmounted-remote-filesystems, that's because a job that's start on unmounted-remote-filesystems won't return
<ogra_> i doubt the container is involved
<infinity> stgraber: There's also a hung "initctl emit deconfiguring-networking" in his ps output.
<ogra_> stgraber, why would we have such a job ?
<infinity> stgraber: http://paste.ubuntu.com/5808502/ if you missed it.
<stgraber> right, same thing, unless you call emit with --no-wait, a broken job can make the emit hang
<stgraber> it's by design
<infinity> I suspect that doesn't want to change to --no-wait in either case, before someone hunts down what's halting the process.
<stgraber> so it's typically an issue with whatever job is started on that event more than upstart's fault (or maybe it's a case where we want it non-blocking, though for those two, I doubt it)
<stgraber> yeah, I think we want those shutdown related events to be blocking as they're there to cleanly bring things down and unmount network fs before the kernel cuts the power
<stgraber> in that ps dump, the problem appears to be dbus
<stgraber> dbus is supposed to stop on deconfiguring-networking and based on that ps, it didn't
<ogra_> right
<ogra_> thats why NM respawns
<ogra_> (in the syslog above)
<ogra_> i dont see much in the upstart log for dbus apart from moaning about no whoopsie user being present
<ogra_> but i think thats from startup anyway
<stgraber> just looked a bit closer, unmounted-remote-filesystems causes networking to stop which causes deconfiguring-networking to be emitted which should cause dbus to go away and the system to shutdown
<stgraber> so it looks like if we can figure out what's keeping dbus from stopping, the whole thing will be solved, all the blocking events will return and the system will shutdown
<stgraber> ogra_: btw, shutdown works fine here on mako, though that's a slightly older image (I don't appear to have powerd)
<slangasek> stgraber, ogra_: yes, those events are absolutely supposed to be blocking; the whole reason they exist is to ensure ordering of shutdown, making them non-blocking would reintroduce races :P
<ogra_> stgraber, it mostly seems to happen on maguro and also only every nth boot
<ogra_> though i think awe said he also saw it on mako
<awe> ogra_, ack
<ogra_> slangasek, into the races we have you mean ?
<ogra_> :P
<slangasek> ogra_: well, the standard Ubuntu shutdown scripts are race-free, so whatever races you're seeing are bugs in your stuff ;-)
<ogra_> right, seems something keeps dbus alive
<slangasek> keeps it alive, or respawns it somehow?
<ogra_> hard to tell
<ogra_> the info in the upstart dbus.log is pretty sparse, it doesnt show it respawned
<ogra_> only moans about whoopsie absence
<ogra_> Unknown username "whoopsie" in message bus configuration file
<ogra_> to be exact
<ogra_> (and indeed it is right, no whoopsie on the phones)
<awe> ogra_, you might need to run upstart with --verbose or --debug to catch the respawning...
<slangasek> or just run 'initctl log-priority info' after boot
<ogra_> awe, well, i rather would think i want a verbose dbus that logs somewhere
<slangasek> and this won't be logged to /var/log/upstart/dbus.log in any case, as that just captures the log output from dbus itself - it does not give you any information from upstart about the job respawning, etc.
<slangasek> ogra_: which image first introduced this problem?
<ogra_> i think tony reported it with his first test of flipped
<ogra_> i havent seen it until today
<slangasek> ok
<slangasek> which devices is it seen on?
<ogra_> maguro more often than mako
<slangasek> ok
<ogra_> i have never seen it on grouper
<ogra_> oh, wait
<ogra_> doesnt powerd use dbus ?
<sforshee> ogra_: yes
<ogra_> its in the processlist as well
<slangasek> what does that have to do with the dbus shutdown being blocked?
<ogra_> powerd has no "stop on" stanza
<slangasek> so?  dbus shouldn't care
<ogra_> hmm
<slangasek> that just means dbus will stop, and powerd will be left crying in the dark
<slangasek> it's the things that *do* have 'stop on stopping dbus' that are going to be the problem
<ogra_> oh, right
<ogra_> root@ubuntu-phablet:/# stop dbus
<ogra_> stop: Job has already been stopped: dbus
<ogra_> root@ubuntu-phablet:/# ps ax|grep dbus
<ogra_>   515 ?        Ss     0:00 dbus-daemon --system --fork
<ogra_> ...
<slangasek> ogra_: 'status dbus'?
<stgraber> ogra_: that means it's busy shutting down and not stopped yet
<stgraber> ogra_: if it was really stopped and all events processed, you'd get "stop: Unknown instance:"
<ogra_> root@ubuntu-phablet:/# status dbus
<ogra_> dbus stop/stopping, process 515
<ogra_> ah, k
<stgraber> right, so stuck in the stopping event as we suspected
 * ogra_ adds some verbosity to dbus
<ogra_> i bet now i cant reproduce the issue anymore ... :P
<slangasek> what jobs are 'stop on stopping dbus'?
<ogra_> http://paste.ubuntu.com/5808713/
<stgraber> ogra_: can you also paste a full "initctl list" when the system's stuck
<ogra_> likely something in the session then, but i dont see anything running
<slangasek> wow, trying to turn on -Werror for plymouth is spectacular fail
<slangasek> why is upstream building with -Wall by default and not cleaning up the resulting warnings?
<ogra_> http://paste.ubuntu.com/5808716/
<slangasek> ogra_: ofono stop/killed, process 864
<slangasek> it's all awe's fault ;-)
<infinity> slangasek: It seems that some people don't make the jump from -Wall to "I should fix those".
<infinity> slangasek: I've been helping a friend off and on with his CompSci homework, where one prof insists they always build with -Wall.  The comment he got back after a few assignments was "you're the only student who actually makes sure everything builds cleanly and addresses all the warnings".
<infinity> slangasek: Perhaps because I made him do so.
<slangasek> :)
<awe> my fault??  ;D
<slangasek> awe: ofono is refusing to die on shutdown, which blocks dbus, which blocks /etc/rc6.d
<stgraber> slangasek: well, actually it looks dead, I'm wondering if it's not a expect fork vs expect daemon issue
<awe> sigh...
<ogra_> i guess we could just leave it to sendsigs
<ogra_> and pull the stop on stanza
<slangasek> stgraber: presumably not, if ofono was working at all during the system's run
<awe> stgraber, slangasek... there's definitely an issue with ofono & upstart that I haven't been able to debug yet
<slangasek> ogra_: no, that's a wrong solution
 * awe is currently doing an evil ofono merge for PIN/PUK support
<ogra_> slangasek, well, we rip the socket out underneath it
<slangasek> sendsigs *deliberately* skips upstart jobs that don't have a 'stop' target
<slangasek> you want the opposite, you want to ensure the service shuts down
<ogra_> if it needs a stop on, that should probably the container
<awe> slangasek, I added code to ofono to exit on RILD socket errors, and was relying on upstart to respawn
<awe> it does this once, and then seems to get confused
<slangasek> awe: hmm, ok
<awe> ...thinking that ofono is still running
<slangasek> awe: my devices are not at easy reach at the moment; could you pastebin /etc/init/ofono.conf?
<awe> ( ie. initctl status ofono returns a PID, and says it's running, when it's not )
<awe> yea, one sec...
<slangasek> infinity: oh, so half of these warnings are actually from the ubuntu-text plugin, teehee
<awe> slangasek, http://pastebin.ubuntu.com/5808742/
<stgraber> awe: also paste the .override
 * awe knew someone was going to ask for that
<stgraber> as the whole job is overriden
<awe> one more sec...
<ogra_> yeah
<ogra_> the override is my fault :)
<awe> http://pastebin.ubuntu.com/5808747/
<ogra_> but that only adds a loop to wait for the socket
<ogra_> (and a start on for the socket dir(
<stgraber> ogra_: you know that a .override doesn't need to duplicate anything that exists in the original conf right? :)
<ogra_> stgraber, but its much more readable to have it all in the same file
<awe> slangasek, stgraber... the expect is correct, as if ofono is running, the correct PID/status is returned... but after the first respawn, it seems upstart gets confused
<awe> I see this on maguro, flipped
<stgraber> ogra_: until someone dumps a post-stop in the archive ofono.conf, then it's going to be very confusing :)
<ogra_> stgraber, well, i have hope that we can somehow merge the jobs before release
<awe> I checked and confirmed that ofono uses the daemon() call, so the 'expect fork' should be correct
<stgraber> ogra_, awe, slangasek: there's the problem, look at PID: http://paste.ubuntu.com/5808753/
<ogra_> 80% of lxc-android-config is throw away stuff
<slangasek> right, that looks like it should actually be 'expect daemon'
<stgraber> slangasek: well, strangely enough the initial startup worked with expect fork, but the second run appears to need expect daemon
<slangasek> hmm
<awe> yea..that's what I originally thought too
<slangasek> that doesn't make much sense
<stgraber> otherwise the PID for the instance running after boot would be wrong too and the first stop would hang
<ogra_> lovely
<awe> that said, when upstart respawns, does that cause a double fork that's not accounted for?
<awe> s/double/extra/
<slangasek> well, in stgraber's example, it's not using an upstart respawn
<awe> right...
<slangasek> oh
<slangasek> this is a bug that was just reported on upstart-devel
<slangasek> Subject: upstart shell magic for exec line
<awe> yea??
<slangasek> https://lists.ubuntu.com/archives/upstart-devel/2013-June/002554.html
<slangasek> I don't understand how a bug like that went unnoticed for as long as it did
<slangasek> unless something regressed somewhere along the line
<rsalveti> ouch
<slangasek> awe: there's a one-line change proposed there (dropping line 268 of job_process.c); I haven't evaluated this, but I guess you could try it out and see what else might explode
<awe> sure...
<slangasek> stgraber: can you follow up on bug #1181789, please?
<ubottu> bug 1181789 in upstart (Ubuntu) "second call of 'initctl start' leads to fork instead of exec ('mount: / is busy' during shutdown)" [Undecided,Confirmed] https://launchpad.net/bugs/1181789
<stgraber> slangasek: I think we did some changes in that part of upstart when fixing some build issues in 1.8 (or 1.7), so it's not impossible that we introduced the bug at that time
<infinity> slangasek: is this expect daemon/fork thing new, or did I just not know about it when I tore a deamon() call out of something that was driving us insane?
<infinity> slangasek: (And does it allow for a double-fork of 'exec shell-script-that-execs-daemon'?)
<ogra_> it has been in the cookbook for a while
<stgraber> slangasek: I'm fairly sure just dropping the line will cause test failures, finishing some loop-mount stuff and I'll take a look after that
<slangasek> infinity: you apparently just didn't know about it :P
<slangasek> infinity: exec shell-script-that-execs-daemon> there's a bug about that, I have a patch for it but I hadn't landed it because it was only useful to me if we fixed exit tracking at the same time; let me dig it up
<awe> stgraber, slangasek, I have to head out in ~20min or so, but can test later.  Totally explains the weirdness I was seeing with my socket retry scenario
<awe> also fyi, I'm out next week
<infinity> slangasek: Oh, kay, if that case still doesn't work, I don't feel bad about my workaround, then.
<stgraber> slangasek: IIRC the bug that cause that change (and introduced this bug in the process) was when your working dir contains a shell character (like the ~ in our daily builds). That was the bug that drove us insane for a couple of days a while back (upstart failing for dailies but not for distro upload)
<slangasek> infinity: lp:~vorlon/upstart/lp.855010
<slangasek> stgraber: right.  Can you please take care of fixing this? :)
<stgraber> awe: well, the job is correct, once we fix upstart it'll just work (I expect the patch to be pretty easy to backport to saucy and raring).
<awe> whew...
<awe> cool
 * awe spent lots of time reading, and re-reading the upstart cookbook this week
<infinity> slangasek: I suppose shell-that-calls-daemon would be a triple-fork, which is the problem (and why it cleared up when I removed the daemon() call).  Couldn't one just allow 'expect fork' to take an integer argument, so I can say "dude, this forks 17 times, that last one's what you want"?
<awe> lol
<slangasek> infinity: shell-that-calls-daemon would be a triple-fork, and that won't work; shell-that-execs-daemon *should* work fine and we just need to support that; letting things fork more than twice is a total non-starter until we properly add exit tracking
<slangasek> which is bug #530779
<ubottu> bug 530779 in upstart (Ubuntu Precise) "init: does not wait for parent to exit when following forks" [Medium,Triaged] https://launchpad.net/bugs/530779
<awe> and everyone on my team thought I was seeing pink elephants when I kept claiming shutdown was broken...
<slangasek> these are not mutually exclusive
<sergiusens> awe: I didn't, I just couldn't reproduce it anymore until today
<stgraber> awe: well, it's only broken if ofono crashes, so fix ofono and your shutdown will work reliably :)
<slangasek> hah
<slangasek> stgraber: ofono is exiting because of rild, I don't think that's ofono's fault ;)
<seb128> stgraber, when do you guys plan to update upstart?
<ogra_> but we love pink elephants
 * seb128 is getting tired of logout taking ages because init segfaults and apport block the logout while dealing with the issue
<stgraber> seb128: I plan to land the fix for the respawn issue as soon as I have it but that's probably unrelated to what you're talking about
<ogra_> seb128, come over to the phone team ... no apport here
<ogra_> *g*
<awe> stgraber, ofono wasn't crashing, it was exiting on purpose when the RILD socket operations returned errors while running in flipped
<awe> this is 'cause we had no way to reliably know that RILD had started in the flipped container
<slangasek> see, upstart should supervise rild too :P
<awe> ;D
<seb128> stgraber, I want http://bazaar.launchpad.net/~jamesodhunt/upstart/bug-1190526/revision/1481 in saucy ;-)
<ubottu> Launchpad bug 1481 in Scribus "outdated description for scribus" [Low,Fix released]
<infinity> slangasek: Well, I'm "happy" enough with the 1-line hack we're carrying in the kernel source for now, this conversation just reminded me of it.
<awe> well, now that chromeos an android are under the same mgmt, that's not too far-fetched...  ;)
<slangasek> infinity: ok.  but now that I know that bug has affected more than just cups, for which it's not a complete solution, I'll probably bump it up my list
<stgraber> seb128: I should be able to cherry-pick that one at the same time assuming I debug the other issue before we upload 1.9 to Ubuntu
<seb128> stgraber, thank you!
<ogra_> slangasek, well, i was asking jodh today about an upstart-container-bridge for us :)
<slangasek> ogra_: no, that's not what I'm talking about
<slangasek> I'm talking about rild being an upstart job that just happens to run in an android chorot
<slangasek> chroot
<ogra_> yes
<ogra_> thats what i wanted that bridge to be
<slangasek> it shouldn't be done by any bridge at all
<slangasek> you just need an upstart job with a 'chroot' stanza
<bregma> hey guys I'm trying to run valgrind on armhf under quemu (ie. in a pbuilder) but I always get an Out Of Memory error....  anyone else seen this?
<stgraber> slangasek: I have a kernel patch here that'd let us do that but only for mako/manta
<slangasek> (well, except you really need a container, but meh :P)
<ogra_> heh, if chrooting would work that way into lxc containers
 * awe heads out
<ogra_> but i see what you mean
<stgraber> slangasek: exec lxc-attach -n android --clear-env -- /system/xbin/env PATH=/system/bin:/system/xbin INSERT-YOUR-COMMAND-HERE
<rsalveti> that would require changes in the android side as well
<rsalveti> I'd just prefer a way to know when it's up from the android side
<rsalveti> which you can get via properties, we just need to hook that up somehow
<slangasek> sigh.  did firefox just change to no longer allow me to hide the tabs when I only have one tab in the window?
<lifeless> slangasek: firefix is intent on becoming a copy of chrome
<lifeless> slangasek: but badly; e.g. when you copy an http url it now copies it without the http://
<lifeless> slangasek: so it looks like chrome, but behaves worse.
<slangasek> chrisccoulson: ^^ do you know if this behavior is still controllable in ff 23? :/
<slangasek> http://forums.mozillazine.org/viewtopic.php?f=23&t=2687123
<slangasek> argh
<slangasek> yeah, might as well switch to chrome now
<ScottK> You might want to consider how rapidly and consistently we get security updates out first.
<slangasek> surely it's simpler to assume that any browser is compromised
<ScottK> That would be one way to approach it.
<mlankhorst> that's what I assume anyway
<debfx> lifeless: at least firefox has an about:config option to get the http:// in the location bar back
<chrisccoulson> lifeless, i've no idea why that doesn't work for you, but it works fine here...
<lifeless> debfx: yes, which is a saving grace
<lifeless> chrisccoulson: let me double check then.
<lifeless> chrisccoulson: and now my running ff makes a liar of me. NFI
<chrisccoulson> ;)
<ScottK> lamont: Can haz postfix 2.10.1?
<luist> anyone familiar with multistrap?
<lamont> ScottK: added to my weekend fun
<ScottK> lamont: Thanks.
 * xnox let's see if this works as well
<xnox> lamont: Can haz util-linux 2.23.1 ?
#ubuntu-devel 2013-06-29
<saiarcot895> When building a program using the hardening-wrapper, does the executable get changed into a library object and therefore cannot be launched through Nautilus?
<Raazeer> since I'm being ignored over in #ubuntu, allow me the liberty to ask here too: is there a way to get /dev/dsp et al back in 13.04? several packages still use it
<Raazeer> I'd very much like to use some of those
<penguin42> Raazeer: There aren't many left that still only use /dev/dsp - but you might try libpulsedsp which is a fudge that persuades them to use pulse audio
<Raazeer> penguin42, maybe not /dev/dsp specific but the whole group of nodes, including /dev/mixer or /dev/audio/mixer, /dev/audio in general, etc...
<Raazeer> aumix uses them for example
<Raazeer> imo, if the backing nodes were taken out of the sytem, those packages that needed it should either have been blacklisted or gotten a dependency on something that puts the nodes in, but that's just omo of course
<penguin42> Raazeer: Yeh that sounds fair - if they're still dependent on OSS then they need either fixing or removing; alsamixer is what I'd use instead of aumix these days
<Raazeer> penguin42, the problem is, aumix is very useful in scripts due to it's comparably simple, parser-friendly output.
<Raazeer> among others, the mute utility depends on it, meaning it's broken in current 13.04
<Raazeer> I guess I'll just try installing every component of oss I can find and see if I can somehow get at least the mixer and dsp node back
<Raazeer> in principle, I've got oss installed according to my package output. If I had to guess, I'd say something must have seriously dropped in the crapper here. gotta look into osspd, maybe that can be a solution
<Raazeer> Ah lookie here: linux-sound-base apparently contains a modprobe config file that blacklists oss completely
<Raazeer> let's take that out and see what happens
<Raazeer> Ok, taking that blacklist out did not bring the device nodes back, so I have to flag both siggen and aumix-common as broken at this time, how do I go about that?
<Raazeer> does anyone happen to know what part of OSS is supposed to create the device nodes?
<chowder> hey I tried asking this question in the main support channel but I didn't really get a reply. I was wondering if someone here could be of some assistance
<chowder> Looking to install Ubuntu 13.04 as a Dom0 with Xen but I want LVM taking care of the hard drives as well as encryption. I know there's documentation on Ubuntu+Xen but how and at what phase would I set up the encryption?
<chowder> *correction. I'm aware that LVM doesn't do encryption. That came out wrong. What I'm saying is that I don't know whether to encrypt the drives before setting up LVM or after.
<chowder> I figure that it would have to be after setting up LVM but I wanted to be sure. Also wanted to know how exactly I'd go about doing it.
<penguin42> chowder: Normal way is luks encryption with lvm on top
<chowder> penguin42: so luks before LVM?
<chowder> how would booting work in that case?
<chowder> I'm wondering if I would need a password to decrypt everything before the system finishes booting up and then use my normal login password
<penguin42> chowder: The way I'm used to is having an unencrypted boot partititon, then one more DOS partition that contains the luks crypt, and that luks contains an LVM set
<penguin42> chowder: Ubuntu sets up the initrd to ask for the password and open the luks and everything just works
<penguin42> chowder: Recent installers will do it all for you if you ask to encrypt the whole disk (when I say recent I think 13.04 does it, not sure about 12.04.2)
<chowder> I see. It just seemed so complex and intimidating to me
<penguin42> it's fine until it breaks - it's a little hairier to find your filesystem again, but it's not too bad
<chowder> Its a security measure because my apartment has crappy locks on the doors and the landlord is a cheapskate. She won't replace them. If my lappy gets stolen I at least want to know that a criminal can't access my data
<chowder> until it breaks? can luks cause filesystem corruption or something?
<penguin42> no, it's just more complex
<penguin42> chowder: luks is a good safe way of doing it - set a bios password as well
<chowder> penguin42: how about using a hardened kernel? I know there's a "ubuntu-hardened" channel but I think I'd be ok with encryption
<penguin42> chowder: Shrug that depends on what you're defending against
<chowder> mainly wanna prepare in the event my lappie gets stolen
<penguin42> chowder: Ideally you should set a hard drive password in the bios so that even if someone popped the drive into another machine they couldn't trojan the /boot part to record your password to rescue it later
<chowder> penguin42: would encrypted swap be a good idea?
<penguin42> chowder: Yes
<penguin42> chowder: But if you just do the luks-lvm route then the swap is just one more lvm logical volume - so you get that with no extra effort
<chowder> that's true...I kind of forgot about that
<chowder> I need to run Windows in a DomU for school...ugh. I go to university online
<penguin42> chowder: Now I don't know anything about Xen really - so don't know how this all interacts with Xen
<chowder> penguin42: I figure it shouldn't be too bad seeing as how Ubuntu has a how-to article on running Ubuntu with Xen. I'm guessing it'll be fine.
<penguin42> chowder: Probably but I think there is some magic about how Xen loads it's Dom0 and I don't know if that needs to be decrypted etc - but I use KVM and that just works with luks/lvm no hastle
<Raazeer> hi guys, is there any way of getting the snd-*-oss modules in 13.04 (short of a custom kernel compile if at all possible)?
<Raazeer> anyone?
<Raazeer> the sources have to be somewhere
<sladen> Raazeer: the ALSA OSS-emulation modules?
<Laney> Can we do support elsewhere please? :-)
<mlankhorst> Raazeer: use cuse + osspd
<Raazeer> I assume you mean fuse instead of cuse
<mlankhorst> cuse
<mlankhorst> character device in userspace
<Laney> :|
<Raazeer> Laney: I DID ask in #ubuntu earlier. nobody there even reacted to questions about oss
<Raazeer> I assumed (correctly) that I would find some more in-depth knowledge here.
<Raazeer> mlankhorst, found it, and thanks for the hint
<Raazeer> and thanks guys, that helps
<Raazeer> whom do I turn to to have some package dependencies updated?
<mlankhorst> the package's maintainer
<Raazeer> guys, cut me some slack here, I usually try to keep as
<Raazeer> close to the reef as possible where maintaining and stuff is concerned
<Raazeer> I think oss-compat needs osspd as a dependency. how do I go about finding the right guy to talk to?
<Raazeer> ok, have it your way - I was trying to help, see if I will again
<sladen> Laney: it might be the weekend, but there are politer ways of directing people elsewhere.  eg. stating a specific location, rather than just "somewhere else", may people that somebody receives assistance, rather than feeling simply deflected
<Laney> I PMed him
<sladen> Laney: there's certainly a case with keeping the signal-to-noise high when things are busily happening, but if it's the only activity on the channel all day, questions are unlikely to a major deteriment to productivity
<Laney> And my point isn't really the level of activity at the time of the question but creating inappropriate support backchannels
 * ScottK agrees with Laney
#ubuntu-devel 2013-06-30
<psusi> I've noticed a rash of bug reports lately where grub-efi fails to install because it depends on a version of grub-efi-amd64 that was superseded during raring development, and is newer than the version of grub2-efi that is present in the quantal, which is being installed.  anyone have a clue as to how the hell this could be?
<Snow-Man> can't install postgresql 9.2 on raring?  really?
<manchicken> Snow-Man: That would suck...
<infinity> Hrm?
<infinity> It's not in raring at all, is it?  How does that "suck"?
<manchicken> I'm mistaken, I thought 9.2 came out earlier than it appears that it did.
<Snow-Man> meh
<Snow-Man> the issue is this postgresql-common foolishness.
<infinity> Feel free to ask pitti when he intends to transition Ubuntu (and Debian) to 9.2, but 9.1 is what we're shipping right now.
<Snow-Man> the problem is that the packages on apt.postgresql.org won't work because he added a 'Breaks' against logrotate >= 3.8
<Snow-Man> presumably because the package doesn't do the right thing w/ it
 * Snow-Man is not impressed
<infinity> Snow-Man: I'm inclined to say that apt.postgresql.org is wildly out of scope for this channel.
<Snow-Man> infinity: bah, #postgresql-apt was overly quiet. :)
<Snow-Man> and pitti, who manages both (along w/ Myon) isn't in #postgresql-apt, so I tend to discuss such things w/ him here.
<infinity> apt.psql.org doesn't mention pitti at all under contacts...
<Snow-Man> eh, blame magnush
<infinity> Anyhow, it also doesn't have builds for >> precise, so I suspect there's a bit of "get to keep both pieces" going on here.
<infinity> Or, you can report the issues to them.  Not much help to discuss it here.
<Snow-Man> yes, I shall discuss it with them and point out this is why we *should* having PG packages for all of the Ubuntu releases, not just LTS.
<infinity> Well, it would be nice if experimental and a PPA were kept up-to-date, instead of some strange outside apt repo, but meh.
<Snow-Man> they deprecated the PPA in favor of the "official" apt.p.o, actually
<Snow-Man> which works for me, tbh, tho I could see how some might prefer it the other way.
<infinity> I don't use either, I just wonder why people don't like to leverage existing resources.
<ScottK> IIRC, pitti has a PPA that he generally keeps up to date.
<Snow-Man> ... and that's the one which is supposed to be deprecated by apt.p.o existing.
<ScottK> Right.
<ScottK> In pitti's PPA he did provide packages for all releases.  Looks like they are just doing the LTS releases.
<ScottK> That's definitely the place to complain.
<Noskcaj> kirkland_, roaksoax: you guys can't ignore me forever
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1035136
<ubottu> Launchpad bug 1035136 in lsb (Ubuntu) "install_initd crashed with SyntaxError in __main__: invalid syntax" [Low,Confirmed]
<maxiaojun> I find that "/usr/lib/lsb/initdutils.py" is a python 2 script ...
<maxiaojun> binary package concerned is lsb-core
<ogra_> maxiaojun, python2 was still the default in 12.10 so it shouldnt matter
<maxiaojun> InterpreterPath: /usr/bin/python3.2mu
<maxiaojun> ProcCmdline: /usr/bin/python3 /usr/lib/lsb/install_initd /etc/init.d/logmein-hamachi
<maxiaojun> from the bug report
<maxiaojun> head install_initd
<maxiaojun> gives #! /usr/bin/python3 on raring at least
<maxiaojun> and install_initd imports initdutils
<ogra_> well, feel free to fix it then :)(
<maxiaojun> i can run 2to3, but not savvy enough to verify whether the whole lsb stuff is working afterwards
<maxiaojun> and i do not have quantal box
<ogra_> use a cheoor ;)
<ogra_> *chroot
<maxiaojun> dummy question, is it considered better to link a branch rather than submit a patch ?
<ogra_> infinity, i see some very weird behavior of copy_exec with the ubuntu-touch-generic-initrd package ....  comparing https://launchpadlibrarian.net/143820277/buildlog_ubuntu-saucy-armhf.ubuntu-touch-generic-initrd_0.5_UPLOADING.txt.gz with http://paste.ubuntu.com/5813896/ does not seem to take the linked adbd libs into account
<maxiaojun> ok, all the files in /usr/lib/lsb is in python2 ...
<maxiaojun> but install_initd  lsbinstall  remove_initd has #! /usr/bin/python3
<maxiaojun> can Matthias Klose <doko@ubuntu.com> make a working change to python 3?
<siretart> maxiaojun: so you want /usr/bin/python to point to python3?
<maxiaojun> absolutely not
<siretart> maybe you can clarify your question then
<maxiaojun> i want lsb package be correctly ported to python 3
<siretart> doesn't lsb mandate python2? (not sure here)
<maxiaojun> if you don't mind, install "lsb" package and check /usr/lib/lsb
<tumbleweed> the interface to lsb scripts is identical no matter whether it's python2 / 3
<maxiaojun> you will find that all scripts under /usr/lib/lsb/ is in Python 2(contains print statement not print function, for example)
<tumbleweed> the lsb python modules are considered private, aren't they?
<tumbleweed> oh
<maxiaojun> but install_initd  lsbinstall  remove_initd
<maxiaojun> all have "#! /usr/bin/python3" at the beginning while initdutils.py doesn't specify
<tumbleweed> initdutils.py sounds like a module, not a script
<ogra_> maxiaojun, is that the quantal binary ?
 * ogra_ is pretty sure slangasek only ported lsb to py3 in saucy
<tumbleweed> IIRC we ported it earlier
<maxiaojun> i'm on raring but i guess quantal is almost identical in this issue
<tumbleweed> it was the thing we ported, to get python3 on the CD
<ogra_> tumbleweed, well, the changelog disagrees
<maxiaojun> http://changelogs.ubuntu.com/changelogs/pool/main/l/lsb/lsb_4.0-0ubuntu27/changelog
<tumbleweed> it was ported and reverted at least once
<ogra_> ah, reaverted
<maxiaojun>   * Use python3 instead of python2 (again). at version ubuntu22
<tumbleweed> 4.0-0ubuntu13 (oneiric)
<maxiaojun> before quantal
<maxiaojun> lsb (4.0-0ubuntu22) quantal; urgency=low
<maxiaojun> the end result is that scripts in /usr/lib/lsb just won't at all, crash at startup
<maxiaojun> just won't work
<tumbleweed> right, so they may need to be ported to python3
<tumbleweed> but clearly nobody else is using them
<ogra_> not even us :)
<maxiaojun> so i only noticed this through this bug: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1035136
<ubottu> Launchpad bug 1035136 in lsb (Ubuntu) "install_initd crashed with SyntaxError in __main__: invalid syntax" [Low,Confirmed]
<maxiaojun> i do not use any lsb software, but i guess we shouldn't close the door
<ogra_> yeah, definitely worth fixing (since lsb-core is in main) but given that nothing in ubuntu is using lsb-core by default thats not really high prio
<maxiaojun> can we guarantee that /usr/bin/python points to python 2 in quantal and raring
<ogra_> definitely in quantal
 * ogra_ forgot about raring
<tumbleweed> we're pretty sure that /usr/bin/python isn't going to point to python3 ever
<tumbleweed> the thought seems to be that python4 will be around before 2 goes away, or something like that
<nemo|omen> by default :-)
<maxiaojun> yes, i actually wonder whether raring has python 2 pre-installed
<maxiaojun> if we do have python 2, then let the scripts declare themselves as python 2 and problem solved
<maxiaojun> "The Ubuntu 13.04 image continues this process, although we will not be able to convert everything to Python 3 for Ubuntu 13.04 final image."
<maxiaojun> anyone have an idea whether python 2 is pre-installed on raring?
<ScottK> For clarity: /usr/bin/python will point to python2.7 for the foreseeable future (not python2, although /usr/bin/python2 also exists).
<maxiaojun> if it is there for raring, then just change the shebang may be sufficent for the bug. for saucy you seem to introduce lsb 4.1, then it is good chance to root fix this issue also
<infinity> ogra_: Weird...
<mwhudson> hm
<mwhudson> i guess i'll google this myself
<mwhudson> but how do i build -dbgsym packages myself?
<jtaylor> a normal package built with DEB_BUILD_OPTIONS=nostrip will be the same
<jtaylor> you may want to use "nostrip noopt" to disable optimization
<mwhudson> no, i'm benchmarking, not debugging :)
<mwhudson> ah i just install pkg-create-dbgsym and i get ddebs by magic?
<mwhudson> although...
<mwhudson> apache2 appears to be trying to build a -dbg package anyway
<mwhudson> but for some reason it's not appearing
<mwhudson> oh, rules stuff that prevents it from being built
#ubuntu-devel 2014-06-23
<psusi> I have noticed some udev attributes like this: ID_MODEL_FROM_DATABASE=P8P67 Deluxe Motherboard.  Where does this come from?  Is there a database somewhere one could record that it is known on such and such model motherboard that ata port X is in fact, esata?
<cjwatson> xnox: Could you please merge qutecom for the libav transition?
<pitti> Good morning
<dholbach> good morning
<xnox> cjwatson: ack.
<LocutusOfBorg1> Hi ubuntu developers
<LocutusOfBorg1> do you think flex should be demoted on universe?
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/flex
<LocutusOfBorg1> the last -8 upload needs cm-super, available on universe
<LocutusOfBorg1> so there is a FTBFS because of the missing dependency on i386 (B-D-I)
<xnox> LocutusOfBorg1: no, we can't demote flex. Because then a good chunk of main will not be able to build anymore.
<seb128> LocutusOfBorg1, http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/flex/flex
<xnox> LocutusOfBorg1: we'd typically promote cm-super-minimal into main, or modify documentation building process to not require it.
<Laney> https://bugs.launchpad.net/ubuntu/+source/cm-super/+bug/1328509
<ubottu> Ubuntu bug 1328509 in pfb2t1c2pfb (Ubuntu) "[MIR] cm-super, build dependency of gdb-doc" [Undecided,Incomplete]
<xnox> slangasek: bmurray: can you please subscribe foundations to pfb2t1c2pfb ?
<xnox> (ps. not a typo)
<Laney> bless you
<xnox> should unblock above MIR ^
<LocutusOfBorg1> :) yes a MIR is indeed better :)
<pitti> xnox: pronounce that 5 times in succession?
<xnox> pitti: "that p package's name i have written on the post-it note" http://xkcd.com/1105/
<Laney> it's a silly name for a package which contains two conversion tools: pfb2t1c and t1c2pfb
<pitti> haha
<cjwatson> Riddell: Hm, why the weird merged version for opencv?
<menace> Hi, i wanted to testbuild libreoffice on ubuntu. i did apt-get build-dep libreoffice ; apt-get source libreoffice ; i only updated the changelog of the libreoffice file and tried to rebuild it with dpkg-buildpackage -uc -us. But it breaks on trusty with an compilation error (http://pastebin.com/zBd2Fj7p). Since packages should be able to be rebuilt, why does that fail? Any Idea?
<infinity> menace: This is fixed in trusty, and will be fixed in utopic in the next upload.
<infinity> menace: This diff will fix it for you: http://launchpadlibrarian.net/177856415/libreoffice_1%3A4.2.4-0ubuntu1_1%3A4.2.4-0ubuntu2.diff.gz
<Riddell> cjwatson: oh yes, my mistake, do you know I should upload again with the right version number?
<cjwatson> Riddell: Not urgent, if you like, was just wondering
<TheMuso`> Does anybody know if we are likely to move to kmod version 17 this cycle?
<pitti> TheMuso`: we should certainly merge it, particularly if it's blocking you or anyone else
<TheMuso`> pitti: Its not blocking me as such, but alsa bits in Debian are starting to depend on it, and keeping in sync would be easier if we were in lock step with kmod.
<menace> infinity: thanks, I try that
<menace> aeh, wait a minute, infinity. i use trusty with updates and it does not work for me... but i'll try your diff.gz anyway :)
<menace> though i have libreoffice 4.2.3~rc3
<bluesabre> sponsors, sru team, can we upload these items to -proposed to begin verification?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
<ubottu> Ubuntu bug 1331871 in lightdm-gtk-greeter (Ubuntu) "[SRU] Please backport lightdm-gtk-greeter 1.8.5 to trusty" [Undecided,New]
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
<infinity> TheMuso: I can merge it.
<infinity> xnox: What was wrong with the xbmc upload 10 hours ago? :P
<mlankhorst> does anyone want to sponsor https://mblankhorst.nl/etc/llvm-toolchain-3.4_3.4.2-3ubuntu1.debdiff for me? debdiff is against the debian version
<mlankhorst> oh woops
<xnox> infinity: lack of coffeine in my body? =)
<cjwatson> brendand,mvo: sorry, I'm going to have to miss this call this week - I left a brief report in the calendar invite
<brendand> cjwatson, np - thanks
<mvo> cjwatson: no problem (from my side), thanks for the note
<mvo> s
<pitti> cjwatson: \o/ congrats for landing the image builds on buildds, really nice!
<mlankhorst> oh fixed the build issue, https://mblankhorst.nl/etc/llvm-toolchain-3.4_3.4.2-3ubuntu1.debdiff
<infinity> mlankhorst: Looking.
<GunnarHj> Anybody in the SRU team who can take a look at bug 1308771? What makes it special is that the fix consists of two new binaries.
<ubottu> bug 1308771 in openoffice.org-hyphenation (Ubuntu Trusty) "Update Swedish spellcheck and hyphenation dictionaries" [Low,Triaged] https://launchpad.net/bugs/1308771
<tseliot> bdmurray: hey, can you approve nvidia-prime in precise-proposed, please? It fits the same use cases of ubuntu-drivers-common
<tseliot> bdmurray: actually, let's hold off, I might as well check a few oem details first while I'm at it
<infinity> mlankhorst: You shouldn't have dropped the delta on patches/lldb-link-atomic.diff
<mlankhorst> why's that?
<mlankhorst> (it was conflicting, so i figured the debian one was more up to date)
<infinity> mlankhorst: Did you look at the delta?  We just drop the conditional.
<infinity> mlankhorst: The Debian one is still wrong, just slightly less wrong than it used to be.  Adjusting for the fuzz would have been the right thing.
<mlankhorst> ok
<mlankhorst> want me to redo it or?
<infinity> Nah, I'll fix it.
<mlankhorst> ok thanks
<infinity> Just going through the rest of the review before I sponsor.
<GunnarHj> bdmurray: ping?
<ChrisTownsend> I'm prepping the next Unity SRU for Trusty and we would like to include a fix that has a new string.  What is the policy for handling this regarding localization/documentation/etc?
<seb128> ChrisTownsend, "don't do that" would be the default response there ... what's the string/where is it going to be displayed?
<ChrisTownsend> seb128: It's  a string in the lcokscreen telling the user the Caps lock is on.  Give me a sec and I'll give you the exact string.
<seb128> ChrisTownsend, do you have a bug report about that/a screenshot?
<infinity> ChrisTownsend: Like a hover text over the /!\ icon?
<ChrisTownsend> seb128: I'll get that to you in a sec.  Trying to find the bug in my sea of open tabs.
<ChrisTownsend> infinity: Yes
<infinity> seb128: You can see it on utopic.  Ctrl-Alt-L, hit caps lock, hover over icon.
<infinity> ChrisTownsend: Generally, the answer to new strings is "just don't", but since it's not visible except on hover, maybe the added functionality is worth the lack of translation.
<infinity> ChrisTownsend: Though, if you could get some translations in too, that would be much better.
<seb128> ChrisTownsend, what infinity said
<seb128> having translations is doable
<seb128> upload a new template to launchpad, which includes the string
<seb128> wait for translators to work on it, and for a langpack export
<seb128> then include the code change
<infinity> Well, we'll spin new langpacks for 14.04.1 in a couple of weeks, probably.
<seb128> we did it for the logout-when-other-users-are-connected dialog
<infinity> So, if one can get it well-translated by then, that would be great.
<seb128> right
<seb128> launchpad shares strings between series I think
<infinity> But, being a mouseover hover, I'm also not hugely put out by it being untranslated at first.
<seb128> so it might already be translated in utopic and trusty should get those once the template is updated
<seb128> yeah, same here
<ChrisTownsend> infinity: So it's ok to go ahead and include the fix in our next SRU and let the translations catch up?
<infinity> ChrisTownsend: Yeah, I think that's fine.
<ChrisTownsend> infinity: Cool, thanks.
<ChrisTownsend> seb128: Thanks to you too:)
<seb128> ChrisTownsend, just make sure the string is included in the translation template
<infinity> ChrisTownsend: But if you guys can follow up on the state of the string in LP and see what it'll look like for 14.04.1, that would be nice.
<seb128> yw!
<ChrisTownsend> seb128: Will do
<ChrisTownsend> infinity: Ok
<zyga> sergiusens: rsync works :)
<zyga> sergiusens: I got a way to use rsync that works with the likes of phablet-shell
<zyga> sergiusens: and it's x10 faster from what I see
<zyga> sergiusens: I can show you the patches if you want to see
<sergiusens> zyga: sure; sounds good
<seb128> could somebody from the SRU team review libdbusmenu in the trusty queue? it's a simple diff and it has been there for a while, locking a landing silo
<infinity> seb128: Ahh, yeah, now that the KDE stuff is all cleared out, I can read the queue again!
<seb128> infinity, ;-)
<infinity> mlankhorst: Uploading.
<mlankhorst> ty
<infinity> seb128: Accepted.
<seb128> infinity, thanks
<cjwatson> mvo: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-click/lastBuild/? \o/
<mvo> cjwatson: yeah!
<mvo> cjwatson: that looks great! I was wondering if something like https://code.launchpad.net/~mvo/cupstream2distro-config/click-tests-against-devel-branch/+merge/224140 would help us too, i.e. run the jenkins-bot on all MPs against lp:click/devel (it seems to be defaulting to lp:click currently)
<menace> how can i recognize if a package is a virtual package? is there any way to see this in the control/apt-cache show part?
<infinity> menace: If it's a virtual package, it doesn't exist.  That's sort of the point.
<infinity> (base)adconrad@cthulhu:~$ apt-cache show mail-transport-agent
<infinity> N: Can't select versions from package 'mail-transport-agent' as it is purely virtual
<infinity> menace: ^-- As an example.
<cjwatson> mvo: Ah, that sounds like it'd make sense
<OdyX> tkamppeter: sorry, my cups-filters 1.0.54-2 upload had my local-non-committed-failing autopkgtests in it. I will upload an updated cups with the running script installed and then upload a new cups-filters with the filters activated or the tests removed.
<infinity> mlankhorst: I'm cancelling your PPA builds of llvm to reclaim buildd resources, since that seems somewhat redundant with the distro upload.
<menace> hrm, i'm updating packages in our distribution (based on ubuntu) in dak. and i already missed with the kernel-package and the ssh-package the concrete packages, because i just imported the virtual packages *headscratch*
<mlankhorst> sure
<xnox> menace: "imported the virtual packages" not sure that would be possible..... you possibly imported some package that is a provider of it. What are you trying to achieve, how & why? Maybe there is a better way to do it....
<mlankhorst> oh the llvm-toolchain ftbfs for ppc64el seems to not be a new one
<mlankhorst> goodie
<infinity> mlankhorst: Yeah, it's been like that for a while.  We'll get it sorted at some point.
<cjwatson> Riddell: For the opencv/arm64 failure, I think disabling precompiled headers on arm64 is the right fix for now - I've had to do that in a few other places
<infinity> cjwatson: Do we know if that's fixed in gcc-4.9?
<cjwatson> Not for sure
<infinity> (And why it seems to have broken only in utopic...?)
<infinity> Actually, hrm, I wonder if this spells doom for the gcc-4.8 microrelease SRU too.
<menace> well, i want to update packages from precise to OurCodeName via dak. and it happened a few times, when i updated the linux meta-package, the the dependent packages would not be updated. and as far as i saw, this was because the meta-package is virtual or has a new name
<infinity> menace: That doesn't sound like it has anything to do with virtual packages, just that you need to import both the "linux-meta" and "linux" source packages.
<menace> something similar seemed to happen with the ssh package as well. i'm not very sure, how to work with dak correct with that issue..
<menace> hrm
<menace> i'll come back when i better understand my problems :)
<bdmurray> GunnarHj: hello
<Riddell> thanks cjwatson
<xnox> menace: neither linux-meta nor linux are virtual. Simply each abi bump changes the binaries package names on the linux package, and the deps change name on linux-meta. If you import one without the other, your archive is inconsistent (you have packages depending on other packages, which are not present)
<xnox> menace: apt has no idea if that's intended or a mistake, and it tells you that it doesn't know about it - maybe it's virtual?! (and no providers where found for it)
<xnox> menace: but it cannot know, that the dak archive you created simply isn't in a consistent state and e.g. missing a matching copy of the linux package & binaries.
<psusi> cjwatson: I hate to bother you with this but I can find zero documentation anywhere on it ( I'll have to write some once I figure it out ).. I am guessing that the grub-xen package is supposed to serve as the proper pv aware boot loader for xen domUs, but it doesn't seem to have a main binary anywhere that you can configure xen to load as the boot loader; it just installs the modules
<cjwatson> psusi: It's a partial implementation that needs to be completed; https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00184.html and thread has background
 * infinity still uses this on precise, and wonders if he needs to learn new tricks for trusty: bootloader = '/usr/lib/xen-4.1/bin/pygrub'
<smb> psusi, Using pygrub as bootloader should work for PV guests. It comes with the xen-utils. For trusty you may need to modify apparmor frofiles (libvirt)
<cjwatson> psusi: The next stage at this point is to write up a boot protocol document that can be included in the Xen tree; I asked smb if he could help with this
<smb> Or are we talking about efi variants?
<cjwatson> psusi: It is *possible* to make grub-xen work, but it's not all assembled yet so documenting it would not be an appropriate next step
<cjwatson> smb: pygrub2
<cjwatson> smb: remember our conversation in Malta?
<smb> cjwatson, We had one?
<cjwatson> Yes
<cjwatson> Anyway, the thread above has the background :)
<smb> cjwatson, (you really had, with that guy that could not stand straight which was me?) Anyway ok
<psusi> afaics, pygrub was a hack that externally parses the grub.cfg from outside the domU and figures out how to translate that into xen commands to launch the domU with the right kernel.. and this new grub-xen is supposed to be an actual build of grub that can run inside the domU and use the pv disk io etc to do everything grub normally does
<cjwatson> smb: Hm, I guess maybe it was apw
<cjwatson> All you kernel folks are indistinguishable after all
<smb> psusi, Ah ok. There also is pvgrub buried in the xen source which works once one goes through the horrible setup path (involving downloading a lot of tar'ed libraries)
<cjwatson> pvgrub is what grub-xen will replace once it's finished
<cjwatson> a.k.a. PV-GRUB2
<smb> cjwatson, Usually people confuse the Ste(ph|f)ane?'s :)
<apw> cjwatson, erm, maybe, /me reads
<infinity> smb: Big Steffie and Little Steffie, you mean.
<smb> infinity, nope. really not
<infinity> :)
 * xnox wistles 2 1/2 man theme tune
<smb> I may have cup size a but not feeling very feminine :-P
<xnox> *whistles?!
<smb> cjwatson, Ok, yeah. I guess I have to grab apw at some point
<psusi> oh wait... grub-install maybe did make something... core.elf?
<apw> cjwatson, oh yeah that might have been me :)
<cjwatson> psusi: Don't expect any of this to work yet
<menace> 3
<caribou> is there a preferred way to build unit tests for bash scripts ?
<pitti> caribou: I think shunit2 (package|program) is the de-facto standard, although many scripts just use some ad-hoc stuff like [ $a = "expected ]
<caribou> pitti: ok I'll look into it, thanks
<caribou> pitti: was looking at what I did in another live, was using PERL for testing bash..
<caribou> pitti: matter of fact, those tests wil go to Debian forst
<caribou> s/forst/first
<slangasek> xnox: pfb2t1c2pfb? are you having a stroke?
<xnox> slangasek: mostly hayfever.
 * mdeslaur didn't know pfb2t1c2pfb was russian for 'Atchoo'
<ogra_> bless you
<slangasek> xnox: subscribed; but I wonder if I should put a moratorium on Foundations-owned MIRs to force the issue of archive reorg ;)
<pitti> sil2100: FYI, libunity-scopes2 now fails to install in -proposed due to "GError: Can not find a single database provider in /etc/click/databases"; this fails the tests for ubuntu-system-settings-online-accounts and unity-scope-click and thus holds back stuff
<pitti> ubuntu-system-settings-online-accounts and unity8 in particular
<pitti> robru: ^ maybe you are interested as well
<sil2100> pitti: oh...
<seb128> sil2100, moved that to -touch
<xnox> slangasek: https://launchpad.net/ubuntu/+source/moratorium does not exist.
<seb128> since we don't have mhr3 here
<pitti> sil2100: I'm not sure, are you interested in notifications like this, or is that just noise for you?
<sil2100> pitti: I would appreciate info like this, especially that I'm slowly moving to +1 maintenance work :)
<pitti> sil2100: ok
<seb128> pitti, thanks for pointing the issue!
<pitti> seb128: de rien
<shadeslayer> ev: how long does it take between someone applying for e.u.c access and them being added to the group?
<hallyn> stgraber: I don't know why i can't keep this straight...  Suggests does *not* get installed by default?  It's ok for something in main to Suggest something in multiverse?
<hallyn> or it does and it's not?
<cjwatson> Correct on both counts
<hallyn> uh.  the first pair, not the second? :)
<stgraber> hallyn: the first
<hallyn> cool, thanks, then qemu can Suggest ovmf, dropping one bit of delta from debian - thx
<stgraber> yep
<ev> shadeslayer: as long as it takes for me to review it. Is there a specific user you're waiting on?
<shadeslayer> ev: yeah, Marco Martin
<ev> do be aware they have to provide an address and project information
 * ev looks
<ev> yeah, Marco hasn't provided an address
<ev> he'll need to submit the form again with that part filled out
<ev> frustratingly there doesn't appear to be a way to make those fields required, though I'd still have the problem of people writing N/A in them.
<shadeslayer> heh
<shadeslayer> ev: I've passed on the info to him, he's upstream KDE, useful to have them access to the tracker, instead of me copy pasting backtraces on pastebin :P
 * ev nods
<ev> happy to add him as soon as he gets the form completed
<shadeslayer> cheers, and thx :)
<ev> sounds like he'd be a great addition to the team :)
<shadeslayer> *nod*
<shadeslayer> ev: David Edmundson too :)
<psusi> well once I remembered this old server I'm importing into a xen domU on new hardware was in fact 32 bit, and I used the 32 bit grub core.elf, it seems to work quite nicely... aside from the fact that the xen console does not seem to notify the domU about the terminal dimentions
<hallyn> mvo: hi, would you mind taking a look at http://people.canonical.com/~serge/netcf-src-0.2.4-2/netcf_0.2.4-2.dsc and sponsoring into debian-experimental?  (debian/libnetcf1.symbols fixes suggested by xnox)
<dobey> /usr/include/accounts-qt5/Accounts/service.h:38:24: fatal error: QDomDocument: No such file or directory #include <QDomDocument>
<dobey> whee, so i guess qt5.3 broke libaccounts-qt5?
<mdeslaur> what's going on with https://errors.ubuntu.com/ ?
<sbeattie> bdmurray: ^
<bdmurray> its not accepting core dumps at the moment, I'm actively working on it
<mdeslaur> bdmurray: darn, I was kind of hoping we had fixed every single bug :(
<mdeslaur> ;)
<bdmurray> yeah, that'd be neat
<ChrisTownsend> infinity: Hey, you're the SRU guy today, right?
<ari-tczew> can someone finally to sponsor one sync? bug 1327934
<ubottu> bug 1327934 in python3-stdlib-extensions (Ubuntu) "Sync python3-stdlib-extensions 3.4.1-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1327934
<Unit193> Just one sync?  What about others' uploads? :(
<ari-tczew> dunno
<Unit193> ari-tczew: Just pulling your leg. ;)
<ari-tczew> Unit193: tomorrow as patch pilot is xnox, looks good :P
<Unit193> Heh. :)
<brendand> lifeless, hi - i have something working for testtools, but i'm just worried i'll break something. unit tests still pass, but can you have a quick look at it?
<brendand> lifeless, http://paste.ubuntu.com/7692320/
<sarnold> is there an easy way to pull the build logs for all 'released' versions of a package from launchpad?
#ubuntu-devel 2014-06-24
<pitti> Good morning
<Unit193> pitti: Howdy.
<pitti> hey Unit193, how are you?
<Unit193> Stiiiilll alive.
<Unit193> You?
<pitti> infinity: how much can I rely on C.UTF-8 being present these days? I'd like to move autopkgtest's default C locale to that, as it's much more realistic
<pitti> Unit193: very much alive, although still a bit tired (it's early)
<infinity> pitti: It's shipped with libc-bin, it better always be there. :P
<Unit193> Heh, yeah.  You normally come on 1-2am my time.
<pitti> infinity: I don't see it yet in lucid/squeeze, but everywhere from precise/wheezy on; from these, will it always be there, or can the admin disable it?
<pitti> infinity: ah, good :)
<infinity> pitti: And yeah, wheezy/precise and onward.
<slangasek> infinity: so when does C.UTF-8 become the default in the installer+
<slangasek> ?
<infinity> slangasek: You mean the default if nothing else is selected?  I want to do that this cycle.
<infinity> TheMuso: Were you planning on dropping alsa-driver in favour of alsa-base at some point?
<infinity> TheMuso: (This came up with a kmod merge that has a versioned Breaks on alsa-base and expects the jessie/sid versions)
<infinity> TheMuso: Hrm, maybe I can just ignore it for now, since we don't install Debian's aliases files in kmod anyway.  But we should revisit this.
<TheMuso> infinity: Yeah, I was planning on doing that swap at some point, seems like a rather delicate dance given the inter-dependencies.
<infinity> TheMuso: Right, looks like alsa-base in Debian has gone completely empty, so we need to sort out what needs moving where and make it work for us.
<infinity> TheMuso: But for now, I'm just dropping the Breaks from kmod, since we don't ship the conflicting aliases either. :P
<TheMuso> Ok.
<TheMuso> infinity: alsa-base in debian is just a transitional dummy package to remove old conf files, everything module alias wise for alsa is now in kmod.
<TheMuso> I think we just need to remove alsa-driver from the archive, and sync alsa-base, given that alsa-driver and alsa-base source packages both share the same binary package namespace.
<infinity> TheMuso: Right.  Our alsa-base has some other junk in it, though, so I guess we sort out where that goes, or if we care anymore.
<infinity> TheMuso: I'll leave it to you to investigate which bits we care about and why, and we can move things around and follow Debian's lead.
<infinity> TheMuso: Please poke me before you abuse kmod, though. ;)
<TheMuso> Yeah, I don't *think* we care about that any more, given all that stuff is kernel anyway, but I'd ahve to check.
<TheMuso> infinity: I have no intension of doing so. I'd rather work this through with an archive admin and a kmod maintainer to make sure things don't break.
<infinity> TheMuso: I happen to be both of those things. :)
<TheMuso> i.e I don't plan to do a thing until action is planned, and acted upon.
<infinity> TheMuso: So, sometime that's not 11pm for me, let's play.
<TheMuso> infinity: Sounds good, maybe if I poke you first thing in my AM. That would be about 4 PM for you or there abouts...
<infinity> TheMuso: *nod*
<TheMuso> Not necessarily tomorrow AM, but as the first task for a morning for me.
<infinity> TheMuso: Yeah, no massive rush, just so long as we don't forget about it for 3 cycles.
<TheMuso> infinity: Sure, i'm just helping updating alsa in debian svn, and looking to get testing packages ready for Ubuntu, so its in my sights currently. Will skim alsa-driver and get back to you soonish as to taking action on the core bits.
<mvo> hallyn: sure, I sponsor netcf now
<dholbach> good morning
<popey> cjwatson: are you the only person about with live-build super cow powers? I am having an odd issue on trusty where sudo lb build doesn't bind-mount /dev so fails early on.. http://paste.ubuntu.com/7694146/ any ideas or someone else I can poke?
<cjwatson> popey: Don't know, not run into that; you're not running under confinement or lxc or something maybe?
<popey> cjwatson: no, just a bog standard trusty laptop (with luks). I bind mounted /dev in the chroot manually while it was in flight and its continuing now.
<popey> cjwatson: looking for a pre-chroot hook now to manually fudge that during the build of the choot.
<popey> cjwatson: is the config used by live-build to build an ubuntu iso publicly available - i presume it's modified from the skeleton you get from "lb config"?
<cjwatson> popey: it's in livecd-rootfs
<cjwatson> popey: https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
<popey> thanks cjwatson
<cjwatson> Theoretically you can even set up a local Launchpad instance now to drive it, though that's probably a bit much for casual use :)
<ogra_> cjwatson, is the new build infra more strict ? it feels like we get a lot more build failures with it
<popey> hah
<popey> yeah, i just want to run live-build locally to create an ubuntu iso, to prove it works, then futz around with it adding/removing packages
<cjwatson> ogra_: No, there's just a couple of bugs I'm working through
<ogra_> ah, k
<cjwatson> ogra_: Most of the failures are from trusty images, which weren't building before so you don't have a good basis for comparison there :)
<cjwatson> That's bug 1325281
<ubottu> bug 1325281 in livecd-rootfs (Ubuntu Trusty) "Cannot handle more than one kernel for generic (3.13.0-24-generic 3.13.0-27-generic)!" [High,In progress] https://launchpad.net/bugs/1325281
<ogra_> ah, yeah, i saw the uploads
<ogra_> (or upload and seed change rather :) )
<cjwatson> But at least now I have a way to test livecd-rootfs on our infrastructure without having to upload it to Ubuntu first \o/
<cjwatson> (Though for the time being it requires a devirtualised PPA)
<ogra_> cool !
<cjwatson> And I can cancel livefs builds ... I like my new toys
<xnox> winter's coming soon =)
<popey> cjwatson: hm, using livecd-rootfs it also craps out because dev isn't mounted â¨
<cjwatson> ogra_: Ah, I see you updated touch-image-monitor, thanks
<ogra_> yeah, missed to set the stamp
<cjwatson> popey: try 'sudo lb clean' and then start afresh
<cjwatson> just in case there's something left over from before
<cjwatson> maybe also 'sudo lb clean --cache'
<cjwatson> But I'm guessing, as I say this has worked for me not that long ago and we use it on our infrastructure
<cjwatson> You can see the exact things we run in lp:launchpad-buildd
<popey> k
<cjwatson> (buildlivefs)
<sil2100> doko: morning!
<sil2100> doko: did you have a moment to quickly browse through the debdiff of the opal package? I would like to upload it if possible
<sil2100> cjwatson: I guess the opal merge is so straightforward that maybe I could simply upload it?
<cjwatson> no idea whether it's straightforward or not :)
<cjwatson> I normally do prefer to wait for the touched-it-last person if at all possible
<sil2100> cjwatson: ok ;)
 * sil2100 waits a bit for mister doko still
<cjwatson> (for my own uploads too, not just when sponsoring)
<doko> sil2100, my upload was a no-change rebuild, so please go ahead
<sil2100> doko: thanks o/
<popey> cjwatson: that seems to have helped, thanks.
<cjwatson> sil2100: just general advice on merges, I usually find it helpful to debdiff against both the last version in Ubuntu and the being-merged version from Debian
<cjwatson> have caught a number of my own mistakes that way
<infinity> sil2100: doko's comment implies that you're probably asking the wrong person. ;)
<infinity> sil2100: The last uploader who did real changes was crimsun.
<mlankhorst> any idea how this can happen btw? https://bugs.launchpad.net/ubuntu/+source/xorg-lts-transitional/+bug/1310093
<ubottu> Ubuntu bug 1310093 in xorg-lts-transitional (Ubuntu) "package xserver-common-lts-raring 3:5 failed to install/upgrade" [Undecided,Confirmed]
<cjwatson> infinity: I usually ask the actual last uploader simply because that matches merge-o-matic assignments and thus likely pending work
<cjwatson> I think that's sufficient for the locking protocol, such as it is
<infinity> cjwatson: Fair enough.  I tend to ask the last person who actually abused the package, not because I care deeply about locking, but because they have context on what they mangled and why.
<infinity> I guess we all have our own method and madness. ;)
<cjwatson> Depends on the changes; as sil2100 says, these ones aren't overly complex
<infinity> Though, crimsun seems to have been mysteriously inactive since April 07... :/
<sil2100> In this case the merged changes is only the addition of one patch that actually fixes a FTBFS with libav10
<infinity> sil2100: Fair enough, yeah.
<sil2100> infinity, cjwatson: thanks guys :)
<mlankhorst> can someone sponsor https://mblankhorst.nl/etc/xorg-lts-transitional_6.tar.gz ? there's a debdiff too but it doesn't handle the symlinks for trusty postinst very well. :-)
<popey> cjwatson: am I right in assuming utopic is built on trusty? (seems syslinux has been updated in utopic and the chain.c32 files have become more numerous and moved)
<rbasak> doko: any chance of a pycurl merge please? We want one to sync python-tornado, which ScottK points out we can probably do with the latest pycurl.
<rbasak> doko: or I can take a look, but the floating point SSE Ubuntu delta that we carry scares me a little.
<rbasak> (and I'll need a sponsor)
 * popey stabs lzcat also
<popey> or indeed, to our builders run precise?
<rbasak> popey: I have no idea about images, but our builders run a chroot that is periodically updated against the release itself. So utopic builds on utopic. Otherwise build-deps wouldn't work.
<popey> rbasak: I'm talking about the host that live-build runs on, I expect the chroots to be $TARGET_RELEASE.. is that different?
<rbasak> That I don't know, sorry.
<popey> np, thanks
<doko> rbasak, won't do it today, just keep the existing patch
<rbasak> doko: OK, I'll take a look and stick it in the sponsorship queue and keep the existing patch - thanks
<sil2100> Hey, did anyone try upgrading from trusty to utopic today?
<infinity> popey: utopic builds on utopic, but if you're building ISOs with live-build, we don't do that.  We only use it to build the livefs (ie: the squashfs bit).
<seb128> sil2100, you and have an experience to share?
<popey> infinity: oh. i didn't realise that. what builds the isos?
<infinity> popey: debian-cd, shoestring, and bubblegum.
<sil2100> seb128: not sure what exactly happened yet, but apt-get dist-upgrade failed and I get tons of insserv warnings and errors during package configuration stage
<seb128> sil2100, can you pastebin those?
<popey> infinity: â» is this documented anywhere (hopeful I know)
<sil2100> seb128: sure, let me pastebin some of the outputs, one moment
<darkxst> popey, a terribly complex set of scripts, if you are wanting to just build stock trusty images it should be fine
<darkxst> but if you want custom images, maybe easier to just use genisoimage
<infinity> popey: The code is public, the documentation is lacking.
<popey> I am trying to build a stock utopic image, from which to then start fettling the packages to make a simple derivative
<darkxst> popey, livefs uses seeds which you can't alter for custom stuff
<popey> but I can make my own seeds right?
<popey> and point live cd at those seeds
<popey> i mean, point live-build at those seeds
<darkxst> popey, the actually it uses tasks generated from the seeds
<darkxst> and you can't make them
<popey> why?
<sil2100> seb128: http://paste.ubuntu.com/7694686/ <- this is the output of my second dist-upgrade after the failure
<darkxst> popey they are encoded into the archive Packages.gz file,
<sil2100> seb128: here's what happens when I try apt-get -f install: http://paste.ubuntu.com/7694687/
<popey> oof
<seb128> sil2100, urg
<darkxst> popey, you could make a seed, generate a meta package and then copy those package sets into live-build I guess
<Laney> you can make livecd-rootfs install the metapackage instead of using the task
<sil2100> I wonder if just my system was screwed or it's an overall problem
<seb128> xnox, pitti: do you have any idea about sil2100's log? seems init system related
<popey> so I probably don't want the ubuntu-desktop (for example) task, but a different set of packages entirely.
<popey> build from ubuntu-minimal up, and perhaps make my own task.
<darkxst> popey, you can't make a task
<popey> ok, meta-package?
<popey> apologies for my newbieness â»
<popey> but having trouble just proving that I can build a simple bog standard live cd first, to ensure the tools work
<seb128> sil2100, lot of that log is vmware, I wonder if it installs file that confuse things
<seb128> "insserv: Service mountkernfs has to be enabled to start service udev"
<darkxst> popey, have a look in config/package-lists, the offical build use apt-cache to generate the package list based on task
<darkxst> you should replace the ubuntu-desktop line, with you full list of packages
<popey> e.g. the live-build process builds an iso, but that wont boot because it can't find /casper/vmlinuz, which may or may not be related to a missing variable somewhere, as all the filenames it generated have .. in the middle, indicating a missing something
<popey> e.g. -rw-r--r--  2 root root 838M Jun 24 12:20 livecd..squashfs
<darkxst> popey, that is not an iso
<popey> no, it isn't an isi
<popey> *iso
<popey> it's just one of the files, all of which are missing something
<sil2100> I wonder, it's been such a long time ago since I actually used vmware, I even forgot I had it
<popey> http://paste.ubuntu.com/7694721/
<popey> see ^^
<popey> seems to be missing something, but I don't know what.
<darkxst> you can't boot a squashfs!
<popey> I didnt say I could
<popey> it also built a livecd..iso and binary.iso
<seb128> sil2100, that seems like a bug we should look at in any case, but not sure what to blame, I would like to heard back from some init system people on that one
<popey> the binary.iso boots in qemu but fails to find casper/vmlinuz
<popey> http://paste.ubuntu.com/7694727/ is the contents of the casper folder on the ISO...
<darkxst> popey, live-build isos don't work on Ubuntu
<popey> which seems to be missing the initrd/vmlinuz symlinks
<popey> â¹
<darkxst> you can make a working iso from the sqaushfs using genisoimage
<seb128> popey, you can try using http://people.canonical.com/~laney/random-scripts/build-ubuntu-iso which is what Laney did for the unity8 iso before we had it integrated
<sil2100> seb128: ok, I'll keep poking them as well, for now I'll try looking into it myself as well
<popey> thanks seb128
<seb128> popey, you need changes to livecd-rootfs to add you flavor if you do that
<popey> that looks very helpful.
<popey> thank you.
<sil2100> pitti, xnox: once you're around I would appreciate some expertise help
<darkxst> seb128, that only works for official flavours
<pitti> sil2100: hey
<darkxst> (well atleast the task based stuff that livecd uses)
<pitti> sil2100: which package ships /etc/init.d/vmware-USBArbitrator ?
<seb128> darkxst, the script is able to use a ppa, we built iso for unity8 with that before being "official"
<pitti> sil2100: looks like this has a broken or absent LSB header, but the log is a bit self-contradictory
<sil2100> Let me check
<darkxst> seb128, you can add a ppa via EXTRA_PPAS
<seb128> pitti, the second log he shared has ""insserv: Service mountkernfs has to be enabled to start service udev""
<Laney> that's newer than this work, but indeed you can
<sil2100> pitti: huh, seems to be some leftover
<darkxst> but the tasks come from apt-cache, so if there are package changes that needs to be manually generated
<sil2100> Not shipped by anything
<seb128> sil2100, don't delete it, move it away, in case it's useful for debugging
<sil2100> seb128: let me try that
<Laney> you just can't use tasks, but if you generate a meta package then you can install that instead
<pitti> sil2100: right, putting it into some pastebin would be useful for reproducing
<pitti> sil2100: supposedly some VMware third-party package installed it dynamically?
<sil2100> pitti: might be, but I wouldn't remember as it's been such a long time when I installed this actually...
<sil2100> It seems to have helped, let me pastebin the script anyway
<pitti> sil2100: ok, glad to hear it's at least unbroken again :)
 * pitti toddles off for some lunch then, bbl
<sil2100> pitti: thanks! :)
<popey> Laney: gotcha
<siretart> cjwatson: I guess that libavfilter-dev should in addition also depend on libswscale-dev, I'll add both libavresample-dev and libswscale-dev to libavfilter-dev's dependencies for the next upload
<siretart> thanks!
<seb128> sil2100, was that enough to restore sanity?
<popey> Laney: did you run that script on trusty or utopic?
<Laney> I was building U on U
<popey> ok
<sil2100> seb128: yes! Well, I'll give you guys an update once it finishes the upgrade, but it seems to have helped for now - and the file didn't seem to have been used at all since some time anyway
<seb128> sil2100, right, it means the system is not robust to "buggy" scripts though
<jamespage> infinity, do backports build with backports enabled yet?  just thinking about how we might get docker 1.0 back to trusty
<cjwatson> jamespage: yes
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/888665
<ubottu> Ubuntu bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Fix released]
<jamespage> cjwatson, ah - great - thanks!
<cjwatson> We do fix buildd bugs sometimes :-)
<infinity> jamespage: Why would docker need to build with backports?
<jamespage> infinity, cause it needs a few extra new go dependencies - and they are all packaged as per policy in Debian
<infinity> jamespage: Also, I think we're pretty intent on SRUing it, not putting it in backports (which is why I already SRUed docker/wmdocker).
<jamespage> infinity, oh - ok
<jamespage> I did not know that
<jamespage> I saw it was SRU'ed
<jamespage> infinity, docker 1.0 needs two extra dependencies and bumps on another four afaict
<infinity> jamespage: We'll discuss how to sort that out, this is an ongoing thing.
<jamespage> infinity, is there a bug or anything yet?
<infinity> jamespage: Unsure.  Might ask kirkland.  I was working with paultag to make sure it was all sane in Debian (which it should be now) and starting things going in Ubuntu.
<cjwatson> Riddell: Want me to sort out the opencv/arm64 thing?
<Riddell> cjwatson: I have it compiling on my pandaboard here
<Riddell> although still at 3%, I wonder if I should just upload
<cjwatson> Presumably the rules diff is obviously confined to arm64 and so compiling on a pandaboard won't reveal anything interesting
<cjwatson> (Please don't disable precompiled headers across the board, it's only needed temporarily on arm64)
<hallyn> mvo: thanks!
<Riddell> cjwatson: good point, I'll upload
<infinity> cjwatson: "temporarily"... We seem to be spreading that temporary hack far and wide. :/
<cjwatson> Yeah, I know :-/
<cjwatson> Hopefully we can grep -changes for it to undo
<cjwatson> I think it's still only on the order of 10 or 20 packages though
<popey> Laney: your funky iso maker script is great. Did you experience an issue where it barfed looking for isolinux.bin or various .c32 files? We had to do some funky symlinking as syslinux 6 has moved those files.
<Laney> nope, never saw that
<popey> wonder if you ran it before syslinux 6 hit utopic?
<cjwatson> most things that care about syslinux file locations need to be adjusted, indeed.
<seb128> Laney, popey: hey, that was before syslinux 6
<popey> yeah, it'll break when you run it again with syslinux6 in our experience
<psusi> infinity: that util-linux get delayed in the upload queue? ;)
<psusi> so if I understand udev correctly, ATTRS{} will search for a file with that name up the sysfs directory tree recursively... but what if you need to branch back down another path?  i.e. from the disk block device yuo go up several levels to ata1, then have to go back down into ata_port/ata1 to get to the port_no attribute, so how can you get a udev rule to match on that?
<cjwatson> doko: Do you still have any interest in the fdupes output in livefs build logs?  You added it back in gutsy, but since then limits on image sizes have increased, and I'm not sure anyone's looked at that output for a while; if anyone still cares perhaps it could be run separately from the main build.  It adds quite a lot to the size of the build logs ...
<cjwatson> So was wondering if I could get rid of it
<doko> cjwatson, no, don't care for it anymore
<cjwatson> doko: OK, thanks, will kill it off next time I'm uploading livecd-rootfs
<psusi> cjwatson: does anyone else work on debian-installer that could apply those patches so we can unblock the parted 3 transition?  I hate to keep pestering you about it when I know you are so busy... as soon as I get an authorization issue sorted with the gnu ftp servers I'm going to release parted 3.2
<cjwatson> I think they're all leaving it to me :)
<psusi> I got that feeling ;)
<cjwatson> I'm just finishing the livefs-in-LP project now, so we'll see
<cjwatson> (Tidying up a few loose ends)
 * psusi checks how long until utopic freeze
<kirkland> jamespage: infinity: hey guys, yeah, docker was what I was pinging you about late yesterday
<cjwatson> Riddell: That evidently didn't work - want me to have a play on arm64 hw?
<kirkland> jamespage: the goal, is as infinity says, to have docker 1.0 SRU'd
<jamespage> kirkland, OK
<jamespage> kirkland, as you appear to have it in hand let me know if you need me todo anything
<kirkland> jamespage: excellent, thanks, will do
<kirkland> jamespage: glad to see you interested and on board
<jamespage> kirkland, I started thinking about it this morning - but I see folks are ahead of me!
<kirkland> infinity: I see docker 1.0 landed in Utopic two weeks ago
<kirkland> jamespage: :-)
<andrewrk> psusi, august 7. I've been keeping an eye on that too :)
<bdmurray> Laney: can you have a look at bug 1333627?
<ubottu> bug 1333627 in fontconfig (Ubuntu) "update broke fonts in firefox" [Undecided,New] https://launchpad.net/bugs/1333627
<Laney> bdmurray: Doesn't sound like it's strictly a problem caused by the update?
<Laney> bdmurray: Looks like dpkg puts the symlinks back
<Laney> Feels like any fix ought to be there?
<Riddell> cjwatson: yeah please
<bdmurray> Laney: ah, yeah it doesn't seem to be related to that specific update at all
<Laney> bdmurray: if you remove one and then reinstall the deb it gets put back
<bdmurray> Laney: right, so not a regression
<Laney> no, but still a problem it seems
<pitti> kees, slangasek, stgraber: reminder, TB meeting in 20 mins in #u-m-2
<popey> cjwatson: do you need me to file a bug in live-build (it symlinks to files like *.c32 that have moved in syslinux 6.x)
<cjwatson> popey: Sure, otherwise it's unlikely I'd fix it since we don't use that code :)
<popey> heh
<ScottK> seb128: You're elfutils arm64 FTBFS seems to be blocking some other stuff.
<LocutusOfBorg1> sil2100, you there?
<LocutusOfBorg1> still waiting for lucene++ :(
<LocutusOfBorg1> I uploaded poedit (old version) in mentors
<LocutusOfBorg1> I hope to update it soon with lucene :)
<sil2100> LocutusOfBorg1: hey! I'll look for a sponsor soon :)
<LocutusOfBorg1> wonderful, let me know if you need a sponsor
<seb128> ScottK, sorry about that, I'm unsure how to debug/fix the issue though, I just merged on Debian and it built locally/on the debian archs
<brendand> lifeless, ping
<lifeless> brendand: hi
<brendand> lifeless, did you happen to see my pings yesterday?
<brendand> lifeless, or do i need to repeat?
<lifeless> brendand: pings?
<brendand> lifeless, i have a patch for the skip issue
<brendand> lifeless, but i'm not that confident it's right - unit tests do pass though
<lifeless> brendand: get it up in a PR on github then :)
<lifeless> we'll review it
<popey> Could someone please sync latest mate-session-manager from debian? Or tell me what buttons to press to request such a sync?
<ScottK> seb128: I don't know either else I'd have just fixed it.  Can you hunt someone down to look at it?
<ScottK> popey: We have the same one Debian does.
<ScottK> If one was just uploaded the tools don't know about, it'll happen automatically.
<seb128> infinity, slangasek: could anyone help to debug elfutils ftbsing on arm64? https://launchpadlibrarian.net/178211279/buildlog_ubuntu-utopic-arm64.elfutils_0.159-2ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> "/build/buildd/elfutils-0.159/tests/funcretval: dwfl_module_return_value_location: cannot handle DWARF type description"
<seb128> not sure what to do about it (I merged the current Debian version, so the upload has my name on it)
<popey> ScottK: sorry. my mistake
<ScottK> No problem.
<slangasek> seb128: make the Debian maintainer fix it? ;)
<slangasek> seb128: arm64 is still in bootstrapping there... #debian-arm could probably help
<seb128> slangasek, can we open bugs on the bts about the arm64? not sure how likely that is going to lead to a resolution
<seb128> ScottK mentioned it's blocking things from migrating in utopic
<slangasek> you certainly can open bugs in the BTS, but the only people realistically who'll work on it are the ARM porters, and for that - #debian-arm
<slangasek> or highlighting wookey, maybe
<seb128> k
<seb128> I'm calling it a day now but can do that tomorrow
<seb128> slangasek, thanks
<wookey> highlighting meworks
<wookey> I noticed elfutils was broke today
<wookey> not looked into it yet
<wookey> been having an NMU-fest for boring fixes
<seb128> wookey, hey, ok, it would be nice if you could have a look to it when you get some free slots ;-)
<nectarys> hi, how to make conky effects only appears on desktop. When I have set it to start on the startup of the PC via "conky" command. it's been displayed on the front of all of the windows. How to deal with this, please ?
<sarnold> nectarys: does conky come with a manpage that describes options?
<rick111> where are the glew files in ubuntu?\
<rick111> cant find the opengl libraries anywhere after i installed them via sudo apt-get
<sarnold> rick111: apt-file reports some glew-utils or libglew-dev packages
<jtaylor> dpkg -S libglew should list their locations
<jtaylor> oh its libGLEW
<rick111> i found them...
<rick111> im coming fromw windows and trying to get opengl up and running on linux
<jtaylor> you normally do not need to know the location of system libraries
<jtaylor> when linking use -lGLEW and the linker will find them when they are installed
<rick111> so i can just compile the programs with gcc -lGLEW filenmae.c
<jtaylor> gcc filenmae.c -lGLEW
<rick111> but what if im compiling them through an IDE? dont i have to place the file paths somewhere in there?
<jtaylor> libraries should always be after objects needing their symbols
<jtaylor> depends on how your ide handles it
<rick111> inside the code?
<jtaylor> on the command line
<rick111>  i know. but what about in an IDE? dont i have to know the file path to freeglut and glew libraries to place inside the IDE?
<rick111> im using codeblocks
<rick111> for the first time
<jtaylor> it should be in their documentation
<jtaylor> but also ides should not need to know the paths
<jtaylor> just the name of the library without extension and lib prefix
#ubuntu-devel 2014-06-25
<rick111> trying ot run empty file setup on codeblocks
<rick111> anyone know how to do this?  i have to manually set the file paths i guess
<pitti> Good morning
<dholbach> good morning
<ion> that
<xnox> rsalveti: do you use zoneminder?
<LocutusOfBorg1> Hi, I'm wondering if poedit will be automatically sync'd from debian
<LocutusOfBorg1> https://launchpad.net/debian/+source/poedit
<LocutusOfBorg1> but not shown in https://launchpad.net/ubuntu/+source/poedit
<LocutusOfBorg1> MoM should run twice every hour, I'm wondering if something broke again :(
<cjwatson> LocutusOfBorg1: It will be, you're just not quite patient enough
<ypwong> xnox, hi, does the branch for ubuntu kylin seed look good? wonder if you will have some time on working on the meta package.
<cjwatson> LocutusOfBorg1: MoM doesn't do the auto-syncing; that runs every six hours, not long after the import into https://launchpad.net/debian/...
<LocutusOfBorg1> ok thanks colin!
<cjwatson> That job is due to start in six minutes
<cjwatson> Sorry, actually one minute
<LocutusOfBorg1> ack wonderful :)
<LocutusOfBorg1> anyway, I'm rebuilding vtk with your fix
<LocutusOfBorg1> do you mind sponsoring it?
<cjwatson> err send me mail and we'll see
<cjwatson> seems a bit quick for an NMU; usually I would give a few days
<cjwatson> and I already uploaded that fix to Ubuntu
<LocutusOfBorg1> I was thinking about a delayed/5
<xnox> ypwong: right, sorry got swamped with other work. That will miss alpha-1, as we are frozen for it. Will aim for friday to upload, such that alpha2 is for sure built using seeds.
<cjwatson> LocutusOfBorg1: ok, maybe, send me mail
<LocutusOfBorg1> sorry but this is the third NMU, the maintainer seems to be not caring anymore :)
<cjwatson> don't drag me into that :)
<LocutusOfBorg1> I'll put the package on mentors maybe tomorrow
<LocutusOfBorg1> and mail you
<LocutusOfBorg1> the problem is that on debian I know where to look (incoming, upload queue, mentors, buildd, dinstall) on ubuntu is everything more "complicated"
<LocutusOfBorg1> I see it now :)
<cjwatson> LocutusOfBorg1: I think in general giving things slightly more than half an hour would be a good diea
<cjwatson> *idea
<LocutusOfBorg1> oh yes of course :) I just would like to know the "dependency graph", in order to be aware in case of troubles
<LocutusOfBorg1> xnox, you there?
<LocutusOfBorg1> thanks for the libavg upload
<LocutusOfBorg1> Seems that you added libmtdev-dev
<LocutusOfBorg1> but this is available for linux-any
<LocutusOfBorg1> :( is it possible to build without it?
<LocutusOfBorg1> also mipsel is FTBFS :(
<rsalveti> xnox: yes
<tseliot> pitti: hi, is it possible that when suspending (S3) using "pm-suspend" logind fails to catch the event?
<xnox> rsalveti: excellent! i've uploaded zoneminder with patches to build against libav10. If at some point you could test utopic-proposed that it is still somewhat operational, that would be great.
<tseliot> pitti: in that logind doesn't get to emit a ""PrepareForSleep" event
<rsalveti> xnox: sure
<xnox> rsalveti: we have a few instances where e.g. it builds fine but there is no sound and/or video is jammed =(
<pitti> tseliot: right, it's not only possible, but certain -- there is no event sent by the kernel when you call pm-suspend directly
<pitti> tseliot: i. e. logind would never notice
<tseliot> pitti: ok, so that certainly explains why LP: #1210077 can only be reproduced with pm-suspend
<ubottu> Launchpad bug 1210077 in unity (Ubuntu) "Screen freeze and garbled after resume from suspend" [High,Fix released] https://launchpad.net/bugs/1210077
<pitti> tseliot: also, sending PrepareForSleep wouldn't work anyway, as logind couldn't inhibit suspend for the listeners
<tseliot> pitti: would the solution be to write a hook for pm-suspend to send a message to Unity (through dbus?)?
<pitti> tseliot: err no; what are you trying to do?
<pitti> tseliot: everything in the desktop/phone is supposed to call logind's Suspend() method which will DTRT
<pitti> tseliot: some might still call upower's, but we are moving away from that
<tseliot> pitti: so, Unity listens to logind to see when the system enters S3, so that it can redraw the launcher on resume
<pitti> tseliot: hm, is that to work around graphics driver bugs?
<pitti> tseliot: but regardless of the "why", yes; that would only work if you actually request suspend through logind
<tseliot> pitti: it's not really a bug, you are not supposed to reuse the FBO
<tseliot> pitti: now the problem is that using fwts for testing triggers the problem
<tseliot> by calling pm-suspend directly
<pitti> tseliot: oh, is fwts calling pm-suspend?
<pitti> yes, that's a problem then :)
<pitti> programs should never ever call pm-utils directly
<pitti> it's not guaranteed to be installed (an in fact, 95% of hardware doesn't need it), we don't install it on the phone, etc.
<tseliot> pitti: yep. Shall we fix fwts instead? If so, where can I find the code that suspends the system on the desktop
<tseliot> ?
<tseliot> gnome-power something?
<pitti> there's basically only two ways (jedi-handwaving away all the old ones): logind suspend, or echo mem > /sys/power/state if you want a low-level one
<pitti> tseliot: yes, fixing fwts sounds right
<pitti> tseliot: there's not really much to it:
<pitti> $ gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.CanSuspend
<pitti> ('yes',)
<pitti> tseliot: if that's "yes", call .Suspend false
<tseliot> pitti: would that be /lib/systemd/systemd-logind in systemd-services ?
<pitti> (the boolean is the "interactive" flag)
<pitti> tseliot: yes, but don't assume that anywhere; d-bus it is :)
<tseliot> pitti: so I have to call .Suspend with false to make it suspend?
<pitti> tseliot: right; that's what things like indicator-session, gnome-settings-daemon, etc. do
<tseliot> pitti: ok, that's interesting, thanks
<pitti> tseliot: FTR, in the future that's easier with "systemctl suspend", but we don't have that part yet
<tseliot> pitti: that sounds a little easier. This solution will do for now, thanks again!
<tseliot> cking: would it be ok if I made fwts use dbus+logind to suspend (and hybrid suspend) instead of calling pm-suspend?
<cking> tseliot, what is the benefit?
<cjwatson> Ampelbein: Looks like you made the last substantial changes to scribes.  It's since been removed from Debian ("RoQA; RC buggy, unmaintained, dead upstream; Debian bug #745896").  Do you mind if I remove it from Ubuntu too?
<ubottu> Debian bug 745896 in ftp.debian.org "RM: scribes -- RoQA; RC buggy, unmaintained, dead upstream" [Normal,Open] http://bugs.debian.org/745896
<tseliot> cking: Unity will get a notification that the system suspended and will redraw itself thus avoiding certain corruption
<tseliot> cking: namely LP: #1210077
<ubottu> Launchpad bug 1210077 in unity (Ubuntu) "Screen freeze and garbled after resume from suspend" [High,Fix released] https://launchpad.net/bugs/1210077
<pitti> cking: also, things should never call pm-utils these days; it's been long obsoleted, you can't assume it's there (folks might uninstall it as 95% of hw doesn't need it, and we don't have it on the phone)
<cking> tseliot, pitti, fair point, however, fwts does run on other distros so I'd prefer it if we had an option in fwts to select the suspend mechanism rather that remove the older functionality
<pitti> cking: oh, even more important then :)
<pitti> cking: pm-utils has been dropped by e. g. fedora (and supposedly also on arch or gentoo) a long time ago
<pitti> cking: these days, logind is the standard API; it can have a fallback to echo mem > /sys/power/state for embedded systems and the like
<Ampelbein> cjwatson: no objection from me with regards to removing "scribes". Looks like it's dead for good :(.
<cjwatson> Ampelbein: OK, done, thanks
<cking> tseliot, so perhaps we should have an extra option, such as --pm-method=[pm-utils | sysfs | dbus.. ] etc
<tseliot> cking: or maybe detect if logind is running and use that when available?
<cking> tseliot, yes - making it smart is useful, but I still think an over-ride option is always useful too ;-)
<tseliot> cking: ok then autodetection and --pm-method to override it
<cking> tseliot, sounds like a plan to me
<tseliot> it sounds sane this way
<tseliot> good
<cking> patches welcome :-)
<tseliot> cking: shall I call dbus using the (painful) c dbus bindings or would a command line tool be ok too?
<cking> tseliot, i'm pragmatic, do what is easiest
<cking> since we call pm-suspend etc already, calling the command line tool is fine
<tseliot> cking: great, I'll send you a patch when it's ready. Does the project use a git/bazaar repository?
<cking> git://kernel.ubuntu.com/hwe/fwts,  and send patches to fwts-devel for review,  fwts is rather kernel like in the patch review process
<cking> (https://lists.ubuntu.com/mailman/listinfo/fwts-devel)
<tseliot> cking: excellent, thanks
<cking> tseliot, thanks for picking this up :-)
<tseliot> ;)
<pitti> thanks tseliot
<tseliot> yw
<rbasak> pitti: for the juju-quickstart test requirement, would you expect me to do this before upload to stable-proposed, or as part of SRU verification after the upload has been accepted? I would do both - just wondering what stage I need to document.
<pitti> rbasak: from my POV it doens't need to be overly bureaucratic; it's always better to test with teh actual packages from -proposed, i. e. as part of the SRU verification
<pitti> rbasak: but if the SRU bug somewhere has your confirmation "tested quickstart with this juju version", that's fine
<rbasak> pitti: that was my thinking - thanks. I'll do a proper check with the real binaries during SRU verification, and a cheap (not necessarily exactly reproducible, but enough to satisfy myself) before upload.
<rbasak> eg. I might change the changelog before upload, but not retest, etc.
<pitti> rbasak: btw, if you'd like any autopkgtest result to refer to, I'm happy to manually run the trusty jobs
<rbasak> OK - thanks!
<pitti> or, if you set up VPN, you can trigger them yourself too of course
<ypwong> xnox, sorry i was away for dinner. that's great, thanks for helping on that
<doko> bdmurray, arm unwind ping
<bdmurray> doko: hi
<doko> bdmurray, does the unwinding work with the coreutils ddbg package installed?
<bdmurray> doko: I could test that today
<infinity> @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: infinity
<asomething> mdeslaur, did you see jdub's comment in LP: #1307027?
<ubottu> Launchpad bug 1307027 in php5 (Ubuntu) "php5-fpm: Possible privilege escalation due to insecure default permissions of sockets" [Undecided,Fix released] https://launchpad.net/bugs/1307027
<asomething> I'm seeing the same thing. I seeing the same thing. Even on a fresh install I need to go edit /etc/php5/fpm/pool.d/www.conf to get php5-fpm working
<shadeslayer> chrisccoulson: poke bug 1274605
<ubottu> bug 1274605 in firefox (Ubuntu) "Please demote xul-ext-ubufox from Firefox Recommends to Suggests" [Undecided,Confirmed] https://launchpad.net/bugs/1274605
<mdeslaur> asomething: yes, you need to either relax permissions, or configure it with the account whatever you're accessing it is using
<mdeslaur> asomething: whatever procedure you followed to configure integration between your web server and php-fpm needs to be modified
<asomething> hmm... ok. are you saying there is no secure default that will work out of the box? I can handle that, but it seems to break most documentation on the web
<mdeslaur> we could make it default to www-data perhaps...not sure that would cover all the use cases
<asomething> that seems to be the most common, but maybe I'm just not aware of other uses
<mdeslaur> if someone can file a bug, and attach a debdiff, I'll sponsor it for an SRU assuming the SRU team considers it an appropriate change
<mdeslaur> asomething: actually, just file a bug, and I'll push it out as a regression fix
<asomething> ok, will do
<mdeslaur> asomething: thanks
<seb128> hum
<seb128> is that standard/agreed behaviour for packages using c++11 to specify a fixed g++ version to control ABI changes?
<seb128> slangasek, ^
<infinity> mdeslaur: Yeah, that's a perfectly reasonable fix.  All webservers in Debian/Ubuntu are meant to run as www-data, so that would cover the common case.
<infinity> mdeslaur: People with weird setups are on their own, but they already knew that.
<seb128> (unping about that question, discussing the specific change with those who suggested it)
<mdeslaur> infinity: ok, will do, thanks
<mdeslaur> asomething: let me know when you get the bug #, so I can add it to the changelog I'm preparing
<asomething> mdeslaur, LP #1334337 Not the best bug report, but you already know the issue =)
<ubottu> Launchpad bug 1334337 in php5 (Ubuntu) "Regression: php5-fpm's socket should be accessible by www-data by default" [Undecided,New] https://launchpad.net/bugs/1334337
<asomething> Thanks!
<mdeslaur> asomething: perfect, thanks!
<xnox> mdeslaur: probably regression from migrating to upstart job from initscript.
<mdeslaur> xnox: huh?
<mdeslaur> xnox: are you talking about the php update?
<xnox> mdeslaur: bug is marked fix-released in utopic, how was it fixed there?
<mdeslaur> xnox: utopic already set the user:group on the socket
<mdeslaur> I'm doing the same for trusty and saucy
<xnox> mdeslaur: oh, i think i am missundersting it completly.
<mdeslaur> xnox: my security update removed 'other' permissions from the php fpm socket
<mdeslaur> xnox: and the socket is root:root by default
<mdeslaur> so it broke setups that were relying on documentation that was relying on the 'other' permissions on the socket
<mdeslaur> etc.
<xnox> mdeslaur: so php5-fpm by default runs as root? or does it self drop priviliges?
<mdeslaur> xnox: no worries, it's under control, I'll push an update out soon
<mdeslaur> xnox: it drops privs after opening the socket
<xnox> ok, cool.
<doko> xnox, boost head ping
<doko> https://github.com/ruediger/Boost-Pretty-Printer
<doko> do you want to integrate that?
<bdmurray> infinity: maybe you could have a look at the patch in bug 1331201?
<ubottu> bug 1331201 in nfs-utils (Ubuntu) "rpc.gssd: ERROR: GSS-API: error in gss_free_lucid_sec_context(): GSS_S_NO_CONTEXT" [Undecided,New] https://launchpad.net/bugs/1331201
<infinity> bdmurray: Seems reasonable enough.  If you work up SRU paperwork, I'll do the uploads.
<infinity> bdmurray: Well, I suppose you probably don't know what the testcase would be, but we can hope the submitter does. :P
<infinity> bdmurray: Uploaded to both utopic and trusty.
<infinity> @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:
<arges> infinity: hey if you have a few minutes can you check out this patch, and see if its reasonable to fix an FTBFS: https://bugs.launchpad.net/ubuntu/+source/crtools/+bug/1256675/comments/8 . I think my hack is a bit heavy-handed ( i can upload if it looks reasonable)
<ubottu> Ubuntu bug 1256675 in crtools (Ubuntu) "RM: crtools -- renamed to criu; RoM" [High,Confirmed]
<infinity> arges: Here's my hack instead: http://paste.ubuntu.com/7702094/
<infinity> arges: Uploaded that.  The better fix is probably to link with $(CC) instead, but my carefactor is too low, since I've been awake for too long. :P
<arges> infinity: yea, how many hours is it now: )
<infinity> arges: A few.
<arges> infinity: heh. yea i like your patch better. that's why I pinged you: ) thanks
<infinity> arges: The bug log seems to have upstream people involved.  If that's true, tell them to stop *&^#!% passing LDFLAGS (a CC argument) to LD.
<infinity> arges: Ideally, by linking with CC instead.
<arges> infinity: yea that confused me a bit; since -Wl is a gcc flag right?
<infinity> arges: But my hack works if they really want to link with LD and use LDFLAGS.
<infinity> arges: Right, -Wl,foo means "hey, gcc, pass foo to ld".
<infinity> arges: And LDFLAGS is generally always passed to CC, hence it having commas and -Wl all over it.
<infinity> arges: So, my little conversion turns it into valid ld(1) arguments, but that's icky. ;)
<arges> infinity: the wierd thing is that 'make' by itsself in that envirnoment works fine. but maybe that's because LDFLAGS isn't populated with anything?
<arges> 'make' without dpkg-buildpackage
<infinity> arges: LDFLAGS is being populated by dpkg-buildflags, via debhelper, via debian/rules.  So, yeah, if you bypass all of that, you win.
<arges> infinity: makes sense. I can pass a helpful note upstream if you don't mind
<infinity> arges: Go nuts.
 * arges goes nuts.
<knocte> any python expert here? been hitting my head against the wall with this: http://stackoverflow.com/questions/24414278/attributeerror-module-object-has-no-attribute-cairo-font-map-get-default (and http://pastebin.com/b2VC6JxY )
<luist_> hey guysâ¦ can i run such commands in postinst when creating a new deb package? http://paste.ofcode.org/ycbXvi9DNjjv8kXjB77VyX
<dobey> omg the text on that site is so tingy
<dobey> tiny
<dobey> also wow that postinst script is awful
<tedg> bdmurray, Does the daisy webpage of an entry show all the fields? Or does it show a subset?
<bdmurray> tedg: Do you have a web page url in particular you are curious about?
<tedg> bdmurray, Uhm, a set, but for example: https://errors.ubuntu.com/oops/c9926216-fc08-11e3-8022-fa163e4ccdf2
<bdmurray> tedg: so that's really errors not daisy and yes it shows all the entries from the database. Is there something missing?
<tedg> bdmurray, Yeah, the filename for one: http://bazaar.launchpad.net/~indicator-applet-developers/url-dispatcher/trunk.14.10/view/head:/service/update-directory.c#L133
<tedg> bdmurray, We're putting that on as "Filename"
<tedg> bdmurray, But I also think that apport attaches the upstart logs for url-dispatcher on those, which don't seem to be there.
<bdmurray> tedg: whoopsie only accepts a subset of apport's data so we don't have tons of kernel, xorg, whatever log files. https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c#L93
<tedg> bdmurray, Hmm, that's a bit of a bummer. As we don't get data from apport hooks as well.
<bdmurray> tedg: long term the goal is to be able to ask for more details as needed for a specific problem e.g. for the next instance of this problem get this log file
<tedg> bdmurray, Seems like in general fields that are added by the app on the recoverable error or by upstream package hooks should probably make it.
<tedg> bdmurray, Even without adding them.
<bdmurray> tedg: I think the point was for each instance to have things that were quantifiable so for this problem we have 40 i386 instances and 20 amd64 ones. And with random log files that isn't possible / useful.  However, it'd be best to check with evan about the decision he made there.
<tedg> I think we have a brand new database, let's fill it! :-)
 * bdmurray shakes head
<tedg> Hmm, there's a parameter to send the full report. Seems in every call it is set to FALSE.
<mark06> anyone in here which knows software-center's code? I can't make it stop showing apt repositories which don't exist anymore
<bdmurray> are there corresponding sources.list files in /etc/apt/sources.list.d/ for these repositories? perhaps if you remove them that'll help sort it out
<bekks> mark06: So fix your repos then, in /etc/apt/sources.list and /etc/apt/sources.list.d/
<mark06> nothing I do fixes it, that sources.list.d was just one of the first things I've tried
<sarnold> mark06: maybe delete their lists from /var/lib/apt/lists ?
<mark06> does software-center store repositories in binary config? cause grep just can't find it by repo name or url
<mark06> there's nothing like that in  /var/lib/apt/lists
<bekks> mark06: Did you check both, /etc/apt/sources.list and /etc/apt/sources.list.d/ ?
<mark06> yes, in fact I checked whole /etc... SC shows a ghost 'Main' repo, but `sudo grep -rn Main /etc` can't find anything... it can't find it anywhere
<bdmurray> check for lower case main
<mark06> but the name is Main, which was the name of my ppa
<mark06> tried -I renatosilva as well, which is my username...
<mark06> what is /var/lib//mlocate/mlocate.db?
#ubuntu-devel 2014-06-26
<sarnold> mark06: that contains the database used by locate, for e.g. "locate apache"
<mark06> is this the module that fills in the repositories menu? http://bazaar.launchpad.net/~ubuntuone-control-tower/software-center/stable-13-10/view/head:/softwarecenter/backend/channel_impl/aptchannels.py
<mark06> HMM WHAT? PROBLEM DISAPPEARED
<mark06> I was just running apt-file update, is that interfering somehow?
<sarnold> oh I wonder if this is that crazy xapian thing I've tried to ignore
<Noskcaj_> pitti: Could you please merge gnome-packagekit soon? It drops upower usage. If you don't have time, i could take it
<mark06> I had deleted the xapian dir then SC started to exit after opening...
<mark06> folks, I'm leaving then, thank you for the attention anyways... if it's ever related to apt-file and I find reproducible steps, I think I'll just file a bug.... bye
<sladen> mtwebster:
<mtwebster> sladen: ?
<sladen> mtwebster: accidentally trying to tab-complete mark06 to provide encouragement, but tab-completion + enter failed
<luist> can i build a i386 package in my amd64 VM?
<pitti> Good morning
<Unit193> Howja.
<pitti> Noskcaj: oh, did I touch that last? indeed; if it's compatible with our packagekit, sure (feel free to steal, of course)
<pitti> Noskcaj: ah, the merge is trivial
<pitti> OdyX, tkamppeter: FYI, latest cups' autopkgtest now fails, thus it's stuck in -proposed
<dholbach> good morning
<pitti> hey dholbach, wie gehts?
<pitti> mvo_: guten Morgen
<dholbach> hey pitti, hey mvo_
<mvo_> hey pitti, good morning!
<dholbach> sehr gut - wie geht's Euch?
<mvo_> hey dholbach
<pitti> mvo_: recently we seem to have gotten a stricter pep8, which now makes a lot of tests fail; ubuntu-release-upgrader, update-manager, aptdaemon are your realm, there's some more
<pitti> dholbach: supi, danke!
<pitti> mvo_: want a hand with some of them? most of them are the new (IMHO relatively stupid) '# needs to be followed with a space' check, argh
<mvo_> pitti: aha, thanks. I saw the failures but haven't investigated further
<pitti> all my nice "#--------" separators cause complaints now :)
<mvo_> pitti: haha, I have a look now, perfect work to wake up fully ,)
<pitti> lol
<pitti> mvo_: alternatively that particular comment one could of course just be ignored :)
<pitti> mvo_: as I said, feel free to toss me one or two of these for fixing
<mvo_> pitti: thanks, if you could take a look at aptdaemon that would be great
<pitti> mvo_: sure
<mvo_> pitti: I take care of the other two (and did a bit of drive-by fixing along the way :)
<mvo_> pitti: thanks!
<pitti> mvo_: do you happen to have the changes from https://launchpad.net/ubuntu/+source/aptdaemon/1.1.1+bzr970-1ubuntu2 in local bzr and just forgot to push, or shoudl I just grab the diff from LP?
<pitti> mvo_: I'll also adjust vcs-* from trusty to utopic for the upload
<mvo_> pitti: ups, I accidently pushed it to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/aptdaemon/ubuntu-utopic/
<mvo_> pitti: its on the right branch now. and fix for fixing the vcs header
<pitti> mvo_: thanks
<pitti> mvo_: I assume s/fix for/thanks for/ :)
<mvo_> :)
 * mvo_ can't type and needs more tea
 * pitti hugs mvo
 * mvo_ hugs pitti
<pitti> mvo_: erk, I botched the version number, should have set it back to -1ubuntu1 (it's -1ubuntu3 now even though it's a new upstream snapshot); but no biggie
<pitti> mvo_: cf. "tea"
<mvo_> pitti: heh, no worries
<LocutusOfBorg1> cjwatson, the new vtk is on mentors :)
<LocutusOfBorg1> cjwatson, nevermind, vincent cheng is actually uploading, thanks :D
 * xnox lost my irc connection again =(
<xnox> doko: boost pretty printers that looks cool. Can one package it, in a way that it gets auto-enabled when installed / available.
<doko> xnox, if you do so, please check that it works with Python3
<xnox> ack.
<roadmr> why use awk when you can get just as confused with sed O_0
<brendand> roadmr, why use either when you can just kill yourself ?
<brendand> roadmr, haven't used either in a while and my life is better for it :)
<brendand> less stress
<brendand> mvo_, dumb question - how do i run the integration tests for click?
<cjwatson> LocutusOfBorg1: ok, cool
<LocutusOfBorg1> :)
<cjwatson> brendand: use an autopkgtest runner on click
<cjwatson> brendand: or debian/tests/run-tests.sh in an environment with all of click's binary packages plus the ones listed in debian/tests/control installed
<roadmr> brendand: oh you mean: https://www.youtube.com/watch?v=0B0sFtRTlx4
<LocutusOfBorg1> xnox, what is missing for http://people.canonical.com/~ubuntu-archive/transitions/html/libav10.html?
<LocutusOfBorg1> just performous?
<LocutusOfBorg1> seems that vtk6 and wxsvg are good
<brendand> roadmr, okay then...
<roadmr> brendand: so what do you use when you need a regex? or have you completely freed yourself from regexes?
<brendand> roadmr, grep
<roadmr> brendand: but.. but.. what about substitution?
<brendand> roadmr, bah, who needs substitution
<rbasak> infinity: with juju-core still stuck in utopic-proposed on the powerpc FTBFS, what do you think of ignoring the powerpc arch for the purposes of migration?
<roadmr> where we're going, we don't need substitution
<infinity> rbasak: We could pull the binaries for now.  I'd really like to get to the bottom of why it breaks, but not how I want to spend my vacation.
<infinity> rbasak: I'll yank the binaries in utopic/powerpc for now.
<infinity> GAH.
<infinity> I may have just removed juju-core entirely.  La la la.
<infinity> Well, that will have the same effect. :P
<cjwatson> LocutusOfBorg1: vtk6, wxsvg, nepomuk-core are all false positives.  I expect to demote performous to -proposed.  I think we just need to figure out what to do with mplayer's various reverse-dependencies (since mplayer's been removed from Debian, so we should probably eventually remove it).
<rbasak> infinity:
<rbasak> infinity: I'm not sure what you mean by "yank the binaries".
<infinity> rbasak: Remove the powerpc juju-core binaries from utopic.
<rbasak> But...they never got built?
<infinity> rbasak: Of course they did, or you wouldn't have this problem.
<LocutusOfBorg1> exactly cjohnston
<rbasak> Oh.
<rbasak> I see
<rbasak> So migration succeeds, because utopic "never had" a powerpc build. I follow now, thanks.
<LocutusOfBorg1> sorry cjwatson I hope with the accept of new ffmpeg will be back agan
<infinity> rbasak: Although, with my typo, migration will now succeed because utopic has no juju-core at all. :P
<rbasak> :)
<infinity> rbasak: But, whee.  End result the same.  Too lazy to waste the effort copying it back in just to supersede it half an hour later.
<rbasak> OK, thanks!
<bluesabre> hey guys, quick question... what's the process for shipping packages with *only* translation updates? I would imagine that they do not need to follow the whole SRU process, right?
<bluesabre> (gearing up for .1)
<infinity> rbasak: Anyhow.  We need to get to the bottom of this.  The regression is obviously a bug somewhere (toolchain bug, bug in juju tickling a toolchain change, who knows), and we do actually have people (Servergy) trying to do juju things with ppc32.
<infinity> rbasak: But, since it seems to be okay on trusty, as long as we make sure to figure it out on utopic "soon", I'm fine with a temporary hack around it.
<rbasak> infinity: I would have looked at it, except I don't think I have a chance of having access to somewhere where it reproduces.
<infinity> rbasak: Also, mildly concerned that, even though ppc32 isn't an officially supported arch, any regression in powerpc usually also affects ppc64, so we could have a sleeper bug that will bite us in two weeks on ppc64el.
<rbasak> I should probably focus on landing 1.18.4 in Trusty now that I have the MRE acked.
<infinity> rbasak: Right, the part where it doesn't reproduce on the porter confuses the crap out of me, since I installed all the same packages locally and *could* reproduce.
<rbasak> infinity: maybe copy the exact buildd chroot over?
<infinity> rbasak: I'll have to move on to trying to identically reproduce the porter, including hardware, and see if that at least reproduces the lack of reproduction, cause I'm puzzled.
<rbasak> infinity: I'm just saying that I seem to have no choice but to leave the whole thing to you right now.
<infinity> rbasak: Yeah.  I can give you access to a machine where it *does* reproduce, if you're interested in trying to trace the explosion.
<infinity> rbasak: Personally, I want to know why it *doesn't* fail on the porter, cause that's confusing as heck.
<cjwatson> LocutusOfBorg1: well, maybe, but I'd rather not wait for that
<rbasak> infinity: I might need to take you up on that, but I think I need to prioritise a few other things first before I can do a deep dive on that.
<LocutusOfBorg1> cjwatson, of course not, I was thinking about a debian reintrodution and an ubuntu sync
<infinity> rbasak: Right.  Focus on the SRU first, but keep this in the back of your mind.
<rbasak> Ack, thanks.
<rbasak> For an MRE SRU with 1.18.4-0ubuntu1 in utopic, is 1.18.4.0ubuntu1~14.04.1 a sensible version number for Trusty?
<cjwatson> LocutusOfBorg1: well the wnpp bug looks like a hideous swamp to me so I see no reason to predict any particular timeframe in which ftpmaster will want to deal with it ...
<bluesabre> Are any sponsors available to upload the following packages to trusty-proposed?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
<ubottu> Ubuntu bug 1331871 in lightdm-gtk-greeter (Ubuntu) "[SRU] Please backport lightdm-gtk-greeter 1.8.5 to trusty" [Undecided,New]
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
<xnox> doko: i've seen gobjc ftbfs, as gobjc points to gobjc-4.9, whilst gcc has been reverted to 4.8.
<xnox> doko: will you be re-instating 4.9 as default soon (and/or already did so)
<xnox> doko: or will you revert gobjc to 4.8 as well now?
<doko> xnox, planned for Monday to default to 4.9 again
<xnox> doko: cool!
<doko> then just give back the ftbfs
<xnox> sehr gut! =)
<sil2100> slangasek, seb128: so, regarding libqofono tests... not sure if we'll be able to get those easily working
<sil2100> slangasek, seb128: those tests seem to require ofono working to pass, and it's a strange configuration
<cjwatson> siretart: I think somebody needs to go through the dependencies on mencoder in Ubuntu (of which there are rather more than in Debian due probably to debian-multimedia.org imports in the dawn of time) and see what can be done with them
<shadeslayer> pitti: whom do I talk to about retiring some upgrade jobs on jenkins?
<pitti> shadeslayer: jibel or me
<shadeslayer> pitti: https://jenkins.qa.ubuntu.com/view/Upgrade/job/upgrade-kubuntu-precise-trusty-desktop-backports-amd64/ & https://jenkins.qa.ubuntu.com/view/Upgrade/job/upgrade-kubuntu-precise-trusty-desktop-backports-i386/ can be retired
<shadeslayer> pitti: I'm assuming saucy jobs will be auto terminated on saucy EOL
<pitti> jibel: ^ can I just delete them, or will they come back automatically from some config file?
<shadeslayer> IIRC he had a branch with the config in them
<brendand> cjwatson, what have i got myself into here: http://paste.ubuntu.com/7705276/?
<cjwatson> brendand: Can I see "find /opt/click.ubuntu.com -ls"?
<brendand> cjwatson, right - there's some user directories in there for users i later deleted
<brendand> cjwatson, enough to just rm those?
<cjwatson> brendand: I'd like to see the evidence before you delete it, if possible
<cjwatson> It definitely shouldn't crash and block upgrades
<cjwatson> (OK, that may be hard to fix in this case and you'll have to work around it anyway, but for the future)
<cjwatson> brendand: Also, you should be doing this kind of test in a clean chroot anyway
<brendand> cjwatson, http://paste.ubuntu.com/7705310/
<brendand> cjwatson, yeah. this was a little while ago
<seb128> sil2100, slangasek, well, we probably shouldn't block landing on that then, but still have a bug for tracking the work needed
<cjwatson> brendand: Right, so removing the stale directories from under /opt/click.ubuntu.com/.click/users/ will fix this, but I'd like a bug report
<brendand> cjwatson, will do
<cjwatson> We need to do something more intelligent there, not 100% sure what :)
<brendand> cjwatson, does "Can't update click if we have previously installed packages for users that were later deleted" summarise it?
<cjwatson> brendand: Yes
<brendand> cjwatson, https://bugs.launchpad.net/bugs/1334611
<ubottu> Ubuntu bug 1334611 in click "Can't update click if we have previously installed packages for users that were later deleted" [Undecided,New]
<brendand> cjwatson, now can i zap them :)
<cjwatson> brendand: Yep
<cjwatson> (for future reference, bugs on click go on the click package in Ubuntu, not the upstream project)
<cjwatson> Not even sure how that was possible, since click upstream doesn't have bug tracking in Launchpad configured
<sil2100> seb128: yeah, I've been trying to make them better, since I fixed up the rules to already start the tests properly but making the tests run as they should would require a lot of quilt patching probably
<seb128> sil2100, right, well please open a bug and write your finding in there
<sil2100> ACK
<mvo_> cjwatson: just catching up with the backlog, do you want me to look at this issue ? (bug #1334611)
<ubottu> bug 1334611 in click (Ubuntu) "Can't update click if we have previously installed packages for users that were later deleted" [High,Triaged] https://launchpad.net/bugs/1334611
<cjwatson> mvo_: If you like - we should probably just ignore registrations for users that don't exist when we're trying to iterate over all users
 * mvo_ nods
<cjwatson> mvo_: It would be nice to figure out why we're getting getpwnam returning NULL with errno == 0 ...
<cjwatson> Oh, maybe that's just what getpwnam does when the user doesn't exist but there's otherwise no error
<cjwatson> Yeah, getpwnam(3) ERRORS "0 or ENOENT or ESRCH or EBADF or EPERM or ...: The given name or uid was not found."
<cjwatson> Great, uh, I wonder if there's a reliable way of telling the difference!
<mvo_> cjwatson: yeah, just looked at the manpage too, great to get so many "or" options :/
<sil2100> seb128: what would be the best place to fill the bug at? As libqofono package doesn't exist yet
<siretart> cjwatson: I fear that most of them need to be removed. alternatively, we could have an mplayer/mencoder that links statically against its internal copy, but do we really want that?
<seb128> sil2100, just open against ubuntu and reassign once the package is uploaded
<cjwatson> siretart: I asked because I don't want to learn enough to make the decision ... :)
<sil2100> ACK
<sil2100> seb128: thanks :)
<siretart> cjwatson: I see :-)
<Matml_> Hi all.
<infinity> rbasak: 1.18.4-0ubuntu1~14.04.1 implies it's a straight backport of the utopic packaging.  If it's the trusty packaging, but the new upstream source, you want 1.18.4-0ubuntu0.14.04 or similar.
<infinity> rbasak: The distinction might not matter today, but I imagine it will in time, if {build-,}deps get versioned or the packaging diverges in other "can't be identical between releases" ways.
<rbasak> infinity: OK, thanks. That's a good point though - for an MRE, must I use trusty packaging? In this case utopic also carries the same major series version, so the packaging changes are generally good (eg. additional dep8 tests)
<infinity> rbasak: As a general rule, making unnecessary packaging changes in an SRU (even an MRE) just muddies the review and verification.
<rbasak> OK, I'll avoid that then - thansk.
<infinity> rbasak: But things that obviously don't affect the binary at all (dep-8 is a fine example), I can see why people might want to keep them in sync.
<infinity> rbasak: The general theory though, is that the packaging in trusty was tested on trusty, the packaging on utopic was tested on utopic, and there's no guarantee the latter works on the former.  Obviously, if changes need to be made to accomodate the new upstream, that's different.
<halfie> hi, I am very new to Ubuntu (and Debian) packaging. so I was wondering if I got get some early feedback on one of packages I am packaging currently?
<halfie> s/got/could
<halfie> https://github.com/kholia/rexgen
<pitti> shadeslayer: removed from internal jenkins, RT sent to remove from public one
<jibel> shadeslayer, and moved to old/ in the branch so they won't be recreated if I ever need to republish trusty upgrade jobs.
<Mlar_> Hi all.
<Dave77> how do I get somebody to make a patch for a program?
<chiluk> Can someone point me to the 12.04.5 development milestone dates?
<bekks> chiluk: I dont think there will be a 12.04.5
<chiluk> bekks there most certainly will be a 12.04.5
<bekks> Really? https://lists.ubuntu.com/archives/ubuntu-devel/2014-February/038042.html
<chiluk> bekks yes really https://launchpad.net/ubuntu/+milestone/ubuntu-12.04.5
<chiluk> except I'm looking for dates.
<bekks> Look for the expected date on the link you just posted.
<chiluk> bekks ok man , love the effort, but expected date does not a milestone date make..
<chiluk> basically I'm trying to find development milestones.. feature freeze dates... alpha beta milestones, etc.
<cjwatson> chiluk: Don't think they're set, project from the earlier entries on https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<chiluk> thanks cjwatson that is what I was looking for.
<alexbligh1> I'm having some fun with conffiles and upgrades. I am trying to upgrade between Precise (with apache 2.2) and Trusty (with apache 2.4). Precise apache has mod_ident, but Trusty does not (LP#1333388). No problem, I will create my own mod_ident module (https://github.com/abligh/libapache-mod-ident - also in the LP bug). This installs fine on a clean install of 14.04 but I am told that post an upgrade from 12.04 t
<alexbligh1> o 14.04 the conffile (/etc/apache2/mods-available/ident.load) does not install, presumably because the residual apache package deleted the conffile on upgrade. Assuming 14.04 isn't going to be fixed in the near future and I still need my module, what's the correct way to address this? Install the conffile somewhere else then copy it in postinst and remove it in prerm (yuck)?
<alexbligh1> I'm having some fun with conffiles and upgrades. I am trying to upgrade between Precise (with apache 2.2) and Trusty (with apache 2.4). Precise apache has mod_ident, but Trusty does not (LP#1333388). No problem, I will create my own mod_ident module (https://github.com/abligh/libapache-mod-ident - also in the LP bug). This installs fine on a clean install of 14.04 but I am told that post an upgr
<alexbligh1> ade from 12.04 to 14.04 the conffile (/etc/apache2/mods-available/ident.load) does not install, presumably because the residual apache package deleted the conffile on upgrade. Assuming 14.04 isn't going to be fixed in the near future and I still need my module, what's the correct way to address this? Install the conffile somewhere else then copy it in postinst and remove it in prerm (yuck)?
<alexbligh1> I'm having some fun with conffiles and upgrades. I am trying to upgrade between Precise (with apache 2.2) and Trusty (with apache 2.4). Precise apache has mod_ident, but Trusty does not (LP#1333388).
<alexbligh1> x
<alexbligh1> x
<sarnold> alexbligh1: you didn't miss any responses while you were away
<alexbligh1> (apologies if spamming the channel here, client is showing channel hung)
<rbasak> alexbligh1: so the Precise apache2 package had a conffile defined in it, but in Trusty that's gone?
<rbasak> alexbligh1: so the Precise apache2 package had a conffile defined in it, but in Trusty that's gone?
<rbasak> alexbligh1: if so, can you see if dpkg lists the conffile as obsolete after the upgrade?
<rbasak> If this is the case, then we have two bugs - the mod_ident regression, and the obsolete conffile.
<rbasak> https://wiki.debian.org/DpkgConffileHandling has some information on this.
<alexbligh1> rbasak, a pile of apache modules (including mod_ident) have gone between Precise and Trusty, as far as I can tell because the autoconf is 'dumb' (by which I mean doesn't send anything special on the ./configure line), and upstream apache changed the default from compile everything to 'most'. You need 'reallyall' or something for everything (it's in the LP bug)
<alexbligh1> rbasak, I'm not sure whether omitting these modules from the standard apache module is a bug or a feature, but it would at least be nice if they were around in apache2-mod-extra or something (which they aren't at the moment)
<rbasak> alexbligh1: sounds like that's a bug that needs forwarding to Debian.
<rbasak> If Debian go to 'reallyall', then maybe we should consider an SRU to Trusty, although that does scare me a little.
<alexbligh1> rbasak, well, I filed it in LP, with a patch to fix it for mod_ident :-)
<alexbligh1> rbasak, should I file it at debian as well as Ubuntu?
<rbasak> alexbligh1: thank you for investigation - it saves me from figuring out what's going on.
<rbasak> alexbligh1: if you could check if it affects Debian, and file if they don't have a bug already, etc, then that would be great, yes.
<rbasak> alexbligh1: I would prefer not to diverge from Debian on this, so would prefer to take a fix from them rather than add to the Ubuntu delta on apache.
<alexbligh1> rbasak, then the problem is made worse with the conffile thing. QA looked at it here and then (unhelpfully) did piles of purge stuff in order to try and fix it. It looks like the conffile is obsolete or something.
<rbasak> alexbligh1: right. If a newer package version intentionally drops the conffile, it needs to specifically take steps to remove the obsolete conffile.
<alexbligh1> rbasak, that essentially means I can't install my replacement mod_ident (repo provided) and will presumably bite us if we do a apache2-mod-extra too.
<rbasak> alexbligh1: that's right, yes. https://wiki.debian.org/DpkgConffileHandling explains what's going on there.
<sarnold> heh, I'd have tried the "piles of purge stuff" myself :)
<rbasak> alexbligh1: it sounds like this was inadvertent, so that would explain the obsolete conffile
<alexbligh1> rbasak, yeah I think so. I will file a bug with debian but I am not holding my breath for an Ubuntu SRU in the timescale I need it - which is entirely understandable given the modules are slightly obscure.
<alexbligh1> rbasak, what's the best way for me to work around this in the mean time?
<alexbligh1> rbasak, (and yes I'm reading that page)
<sladen> ...conffile shouldn't be disappearing even if it's missing from the newer package
<sladen> unless something is explicitly causing it to be nuked
<rbasak> alexbligh1: I'm not sure. Maybe don't ship the conffile in your extra package, and force the right thing in place with config management?
<rbasak> alexbligh1: the trouble is that the obsolete conffile is a bug in the apache packaging in Trusty, and you can't easily fix that without rebuilding it or us landing an SRU.
<alexbligh1> rbasak, config management == copy the file on postinst?
<rbasak> (and for production use rebuilding it causes issues with any future security updates)
<alexbligh1> rbasak, that is precisely my concern
<sladen> alexbligh1: if you need a short-term ugly kludge,  chattr +i theconfile  before upgrade
<rbasak> alexbligh1: I meant puppet/chef etc. Copying the file on postinst is evil and shouldn't be in the archive, but as a workaround for your own custom package sounds fine.
<alexbligh1> rbasak, no puppet chef in play here. These are in essence appliance boxes out in the field
<alexbligh1> rbasak, my concern is the next 'apt-get update && apt-get upgrade' then has the SRU in and confuses people.
<rbasak> alexbligh1: then the postinst method sounds OK, but I can see at least one catch - if/when we SRU a removal of the obsolete conffile, you'll lose the file.
<alexbligh1> rbasak, indeed :-/
<alexbligh1> rbasak, chance of released SRU shipping before Jul 15?
<alexbligh1> rbasak, (quite prepared for the answer 'zero')
<rbasak> Two and a half weeks? Feasible but maybe unlikely.
<rbasak> You'll want an Ubuntu developer who can help you land it as a priority.
<alexbligh1> rbasak, do you know off the top of your head whether the name of the .load file in apache2 has to match the name of the module? Because the other option is simply to rename the .load file to something else if it's just relying on a wildcard load.
<rbasak> IIRC it does have to match something.
<rbasak> (I've tried using a different name in the past and something broke)
<alexbligh1> actually perhaps I just rename the whole module, and beg someone at Ubuntu to add provides+conflicts+replaces to the SRU (when it comes) with my module.
<alexbligh1> (as the config directives will still conflict)
<alexbligh1> or I suppose I could change the config directives too (sigh)
<rbasak> I don't think that adding metadata for packages that never entered the archive (Debian or Ubuntu) is acceptable, sorry. But maybe somebody can tell me otherwise.
<rbasak> Can you fix the problem with a new apache2 in your own PPA maybe, and watch for security updates and maintain the PPA until an SRU lands?
<alexbligh1> rbasak, well we have our own repo so I can do better than a PPA :-) I suppose I can do that, yes. Actually I'm not sure I even need to watch for security updates as if the 'right' apache is upraded to it should remove all trace of needing the conffiles, so a security upgrade would then fix it, yes?
<alexbligh1> rbasak, and that would also mean that I could supply the bug fix for the main package :-)
<rbasak> alexbligh1: a security update will not fix the conffile bug. They bypass the normal SRU process, including the week-long public testing period, so can't do anything but fix security issues.
<rbasak> alexbligh1: a bug fix for the main package would be appreciated though! This probably needs some coordination with Debian's fix though, assuming this affects Debian - I don't want to diverge from them.
<alexbligh1> rbasak, no I meant that if "my" apache2.4 is installed first, it would (presumably) remove all trace of mod_ident.load from the relevant debian package file. So then if a security update comes through it would reinstall over my package (sure) but the mod_ident thing wouldn't be there in the first place. But I'd need to know "my" apache2 was installed before mod_ident (depends: would do I suppose)
<rbasak> alexbligh1: ah - good point. Your custom mod_ident package could have a versioned Pre-Depends on your custom apache 2.4 package to ensure that the postinst runs before it's unpacked.
<alexbligh1> rbasak, or perhaps I could do it in a transition package
<alexbligh1> actually doing it in my apache2.4 package is better
<rbasak> Just look out in case mod_ident is reintroduced in an SRU. I don't know if we'll do that or not though.
<alexbligh1> rbasak, I presume I need to do the bit marked "# Remove a no-longer used conffile" in that page you sent me?
<alexbligh1> rbasak, hopefully if you do reintroduce it it will be in an apache2-mod-extra
<alexbligh1> rbasak, or that will be what I will be suggesting in the debian bug :-)
<rbasak> alexbligh1: I think so, yes.
<rbasak> (haven't looked in detail)
<alexbligh1> rbasak, thanks
<alexbligh1> rbasak, very useful!
<roaksoax> 4/win 9
<FlowRiser> hey guys, I have a quick question; Is the /etc/os-release file also available on Ubuntu?
<bekks>  No.
<rbasak> I appear to have one (on Trusty)
<slangasek> yes, it is.
<bekks> FlowRiser: Use lsb_release -a instead
<slangasek> it's a relatively recent thing, so it's only present in releases after 12.04
<rbasak> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659853 was the bug in Debian. Fixed in base-files 6.8.
<ubottu> Debian bug 659853 in base-files "base-files: Please provide /etc/os-release" [Wishlist,Fixed]
<slangasek> but it's part of base-files, so every Ubuntu system from quantal on will have it.
<FlowRiser> thank you, slangasek!
<bekks> TIL :)
<FlowRiser> what does TIL mean?
 * FlowRiser is a noob
<mdeslaur> bdmurray: can I steal your gnupg merge?
<FlowRiser> also, bekks, i would normally use lsb_release on Ubuntu; But I am working on doing some Debian-Ubuntu stuff that need to work on both
<FlowRiser> lsb_release does not come by default with Debian
<bekks> FlowRiser: and debian doesnt support lsb_release? :P
<bdmurray> mdeslaur: yes, please
<FlowRiser> it just does not come by default, at least on jessie
<stgraber> slangasek, cjwatson: can one of you let my e-mail to u-d-a through?
<slangasek> stgraber: doing
<achiang> having trouble building a utopic schroot hosted in trusty. any clues? http://pastebin.ubuntu.com/7708123/
<achiang> or rather, it builds fine, but entering it is problematic
<achiang> hm, experiencing this symptom - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675189
<ubottu> Debian bug 675189 in schroot "schroot: Doesn't mount /dev, /proc, /sys, /home, etc. anymore" [Important,Fixed]
<infinity> achiang: Seems unlikely that it's that bug, based on when it was fixed.
<achiang> infinity: agreed that it's probably not the same bug, but at least it's giving me clues on places to look
<infinity> achiang: The output of "schroot -v -c utopic-amd64" might be enlightening.
<achiang> here is a different diff, first - http://pastebin.ubuntu.com/7708266/
<infinity> achiang: That's pretty much how it looks on my system.
<achiang> infinity: here's the -v output -  http://pastebin.ubuntu.com/7708268/
<achiang> infinity: interestingly, i have another schroot that i created a while ago (trusty-armhf) and it is using the default profile. and that one does mount my /home properly
<infinity> achiang: So, I see a PROFILE=sbuild there, mine has PROFILE=default.  Do you set profile in your config for the chroot? (I don't)
<achiang> yeah... i wonder why i am using the sbuild profile
<achiang> need to figure out what env vars influence that (or dotfiles)
<infinity> achiang: /etc/schroot/chroot.d/foo
<infinity> achiang: ideally, that shouldn't contain profile= at all, then you'll get default when you run schroot, and sbuild when you access it via sbuild.
<achiang> infinity: right... mine does contain a profile= line...
<infinity> achiang: Which is generally the desired behaviour.
<infinity> achiang: Err, oh.  Really?
<achiang> infinity: i'm trying to figure out now why/how that got in there
<achiang> it says profile=sbuild
<infinity> achiang: Oh, you said "does" and I read "does not".
<infinity> achiang: It could well be a bug in mk-sbuild or something.  I haven't used it in ages, since I just copied raring->saucy->trusty->utopic. :P
<achiang> hm, i don't seem to have anything in ~/.schroot or ~/.sbuild ...
<achiang> nothing suspicious in env either - http://pastebin.ubuntu.com/7708285/
<infinity> achiang: It's a mk-sbuild bug.
<achiang> indeed
<achiang> SCHROOT_PROFILE="sbuild"
<infinity> SCHROOT_PROFILE="sbuild" (overridable at runtime).
<infinity> achiang: Anyhow, just whack the line entirely from the config and you'll be happy.
<achiang> profile=$SCHROOT_PROFILE
<achiang> infinity: ack, i can do that... just wondering why am i getting bit now?
<infinity> achiang: Maybe you haven't used it in a while?
<infinity> Or on trusty?
<geofft> infinity: Oh, does leaving it out do that? Then why does mk-sbuild even bother to set it?
<infinity> geofft: Leaving it out does the right thing, which should be the mk-sbuild default, IMO.  No idea why it's not.
<geofft> I ran into this last night -- it changed in raring's ubuntu-dev-tools
<geofft> (and it's not even properly overridable via the environment, like it vaguely claims)
<infinity> geofft: It should be overridable as of 13.10, I think.
<infinity> geofft: But it really shouldn't have a default at all.
<geofft> You can override it in ~/.mk-sbuild.rc but not at runtime in the environment, unless I'm misreading
<achiang> ubuntu-dev-tools (0.149) unstable; urgency=low
<achiang>   [ Marc Deslauriers ]
<achiang>   * mk-sbuild: allow specifying the schroot profile.
<achiang>   * ubuntutools/config.py: properly handle name being None.
<achiang>  -- Benjamin Drung <bdrung@debian.org>  Tue, 13 Aug 2013 23:12:42 +0200
<infinity> geofft: Yeah, it only works with the dotfile.  Precisely because a default is set, which overrides the environment.
 * achiang fires up ubuntu-bug
<infinity> To be fair, the tool *is* called mk-sbuild, not mk-schroot, but given how many of us use it for the latter case, I'd call this a bug. :P
<achiang> https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1334886
<ubottu> Ubuntu bug 1334886 in ubuntu-dev-tools (Ubuntu) "/home not mounted, causes schroot errors" [Undecided,New]
 * achiang decides this yak looks nice and trim now, tries to remember what he was doing earlier
#ubuntu-devel 2014-06-27
<Unit193> pitti: Up so early?
<pitti> Good morning
<pitti> Unit193: yeah
<pitti> too much to do before the weekend and 3 days of holiday :)
<rsalveti> diwic: just saw pulseaudio is getting 'permission denied' when trying to make the sink/source thread realtime (calling org.freedesktop.RealtimeKit1 - MakeThreadRealtime), is that expected?
<rsalveti> I noticed pulse itself got a higher priority when starting
<diwic> rsalveti, I'd say it's something that needs fixing
<rsalveti> Jun 27 05:33:56 ubuntu-phablet pulseaudio[30497]: [pulseaudio] core-util.c: RealtimeKit worked.
<rsalveti> Jun 27 05:33:56 ubuntu-phablet pulseaudio[30497]: [pulseaudio] core-util.c: Successfully gained nice level -11.
<rsalveti> but can't set the thread though
<rsalveti> right
<rsalveti> started a few weeks ago afaik, just got time to understand the error
<rsalveti> rtkit was upload with a newer version in may 22
<rsalveti> *uploaded
<diwic> rsalveti, sometimes I've seen the rtkit fail when you run PA from a terminal but succeed when you autostart it the normal way
<rsalveti> right, in this case I'm also getting from autostart
<diwic> rsalveti, nice level is one thing, rtprio is another - it's the rtprio we want
<diwic> i e, SCHED_RR
<rsalveti> yeah
<rsalveti> the error message: 'core-util.c: Failed to acquire real-time scheduling: Permission denied'
<diwic> rsalveti, maybe it's an apparmor related problem
<rsalveti> yeah
<rsalveti> can try to disable it and retry
<jjohansen> how about checking for a denied message
<jjohansen> rsalveti: what was the error exactly?
<rsalveti> didn't get any denied though
<rsalveti> in syslog
<rsalveti> would I get that when apparmor blocks a dbus call?
<jjohansen> rsalveti: you would it will be in /var/log/syslog
<sarnold> rsalveti: yes, unless there is a 'deny' rule to deny an access silently
<jjohansen> grep DENIED /var/log/syslog
<jjohansen> true, but you can turn quieting off
<rsalveti> no denial for it
<rsalveti> worked fine in image 44, but that's a bit old
<rsalveti> and with previous rtkit
<rsalveti> Jun 27 05:55:44 ubuntu-phablet pulseaudio[2532]: [alsa-source-MultiMedia1 (*)] core-util.c: RealtimeKit worked.
<rsalveti> Jun 27 05:55:44 ubuntu-phablet pulseaudio[2532]: [alsa-source-MultiMedia1 (*)] core-util.c: Successfully enabled SCHED_RR scheduling for thread, with priority 5.
<jjohansen> rsalveti: well you can try disabling apparmor, or just doing /etc/apparmor.d/teardown to unload all the current profiles, so you don't have to reboot
<rsalveti> cool, will give it a try
<sarnold> /etc/init.d/apparmor teardown rather
<diwic> then it's probably the new rtkit and not apparmor
<diwic> in which case I haven't seen it (yet)
<jjohansen> rsalveti: oops yeah what sarnold said /etc/init.d/apparmor teardown
<rsalveti> diwic: yeah, image 44 + latest rtkit is already enough to reproduce the error
<rsalveti> so not apparmor
<dholbach> good morning
<LocutusOfBorg1> can anybody please help me with this bug?
<LocutusOfBorg1> * Topic for #debian-devel is: Broken: Permissions on alioth | https://db.debian.org/debian_known_hosts | help with QA, review packages with no bugs today! http://deb.li/nobugs
<LocutusOfBorg1> * Topic for #debian-devel set by vorlon!~vorlon@becquer.dodds.net (Sun Jun  1 05:05:36 2014)
<LocutusOfBorg1> <formorer> ehhhh
<LocutusOfBorg1> * vbernat has quit (Remote host cl
<LocutusOfBorg1> ops sorry
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1334864
<ubottu> Ubuntu bug 1334864 in dpkg (Ubuntu) "boinc-manager 7.2.42+gfsg-1 brick 14.04 new clean install" [Undecided,New]
<LocutusOfBorg1> I don't understand how to proceed, seems a critical bug for me (if reproducible)
<rsalveti> diwic: so, here is the issue, with latest rtkit they fixed the RLIMIT_RTTIME value type (was nsec, but it's actually usec)
<diwic> rsalveti, oh
<rsalveti> and previous max timeout was static unsigned long long rttime_nsec_max = 200000000ULL; /* 200 ms */
<rsalveti> changed to: static unsigned long long rttime_usec_max = 200000ULL; /* 200 ms */
<rsalveti> if (rttime <= rttime_nsec_max)
<rsalveti> to
<rsalveti> if (rttime <= rttime_usec_max)
<rsalveti> so pulse is setting max timeout to 1 sec
<rsalveti> but rtkit only allows 200 ms
<diwic> rsalveti, thanks for finding
<rsalveti> diwic: should I change pulse's default rlimit_rttime to 200ms then?
<rsalveti> upstream is also using 1sec
<rsalveti> http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/daemon/daemon-conf.c
<diwic> rsalveti, the change was done 2012, weird that you're the first one to discover it?
<rsalveti> diwic: the error only shows with log level debug
<rsalveti> but yeah
<rsalveti> really weird :-)
<rsalveti> happens on my desktop as well
<diwic> rsalveti, let me ask the other PA developers. If you don't hear back from me today, please go ahead and change PA's max rttime
<rsalveti> diwic: great, thanks
<Saviq> mardy, hey, I was getting password prompts on login on utopic desktop these past few days... now I noticed I have no "online accounts" in the settings, any idea how that could've happened, and what should I install to get them back again?
<Saviq> mardy, the pass prompts apparently were caused by missing google account plugin
<Saviq> mardy, ah, found it again
<Saviq> u-c-center-signon
 * Saviq looks when it got removed
<Saviq> hmm no commandline associated...
<Saviq> mardy, as you were, then... must've been some PPA's fault or something
<mardy> Saviq: hi! Sorry, I didn't see your messages. I really hope it was a PPA, but TBH I have no idea :-)
<Saviq> mardy, no worries
<Saviq> mardy, I just have http://pastebin.ubuntu.com/7710032/ in apt history.log
<Saviq> mardy, no command line, no nothing, just "remove"...
<Saviq> mardy, ppa-purge most probably
<tvoss> xnox, cjwatson I'm looking at https://code.launchpad.net/~alecu/unity-scope-click/explicit-gcc-version/+merge/224550
<tvoss> xnox, cjwatson I would propose that we get native compilation done first, to unblock the toolchain transition, and focus on cross compilation thereafter
<tvoss> thoughts?
<cjwatson> tvoss: I agree, and would add that making this work with cross-building is a centralised problem; see my comments in #ubuntu-ci-eng a little while back
<tvoss> cjwatson, yup. xnox ^
<cjwatson> tvoss: It's unfortunate fallout
<tvoss> cjwatson, yup, let's focus on the core problem first and clean up in step 2
<tvoss> thostr_, ^
<tvoss> thostr_, please update the MP accordingly such that we can get the silo building
<cjwatson> Have you dealt with all my review comments?  Most of them ought to be done before you start building it all.
<cjwatson> And you'll need to fix the mir failure.
<mdeslaur> cjwatson, beuno, sarnold: I've created a basic wiki page for click package signing here: https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning
<mdeslaur> cjwatson, beuno, sarnold: could you please take a look and make sure we're in agreement on the concept?
<cjwatson> queued up, thanks
<beuno> mdeslaur, thanks!
<beuno> (reading)
<stgraber> @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: stgraber
<beuno> mdeslaur, so. I'm wondering if we want the signature to involved the URL from which it needs downloading from
<beuno> to prevent MITMing the json outpu
<beuno> *output
<beuno> although I guess the device would only valdidate our signatures
<brendand_> mvo, hey
<mvo> brendand_: hello
<brendand_> mvo, do you know where in jenkins your click jobs are?
<mvo> brendand_: uh, I need to search
<brendand_> mvo, no it's alright. i'll find out - and then let you know :)
<cjwatson> brendand_: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-click/  https://jenkins.qa.ubuntu.com/view/Utopic/view/All/job/click-utopic-armhf-ci/
<cjwatson> I expect those are the two relevant sets
<brendand_> mvo, cjwatson knows :)
<cjwatson> Well, cjwatson's browser history knows
<cjwatson> Disturbingly sentient, that thing
<mvo> heh :)
<mvo> thanks cjwatson
<brendand_> and it has the coverage report - excellent!
<brendand_> mvo, cjwatson - now i can get that in the dashboard
<brendand_> \o/
<mvo> !!!
<zul> xnox:  ping you know python-wsgi-intercept ftbfs right?
<xnox> zul: hm, didn't notice, yet.
<xnox> zul: the one in git shouldn't, it's ahead of what's in the archive.
<zul> xnox:  just thought i would point it out
<xnox> zul: haha. yeah i didn't get an email about it cause it synced from debian under team name
<xnox> zul: and it's clearly trying to do network access which is allowed on my local builds & debian builds, but not ubuntu launchpad
<alexbligh1> I have a conffile question (again, sorry). rbasak was helping me with this yesterday and I thought I had got the answer, but I now don't think I have. The issue is that apache2.2 provides mod_ident and apache 2.4 does not, leading to it going AWOL on an upgrade from Precise to Trusty. When apache 2.2 is removed (or perhaps when 2.4 is removed) a conffile in /etc gets removed from the disk, but not from the DB,
<alexbligh1> so installing a new mod_ident package with the same conffile omits the conffile because the system thinks the user has chosen to delete it. rbasak  pointed me to https://wiki.debian.org/DpkgConffileHandling in some detail, and I've now looked at the source to dpkg-maintscript-helper, but this only seems to deal with removing (or moving) the conffile, and not correcting the database which is by now wrong. Any id
<alexbligh1> eas?
<alexbligh1> This is LP#1333388 (for the mod_ident bug)
<mdeslaur> beuno: yeah, even if someone MITMed it, the only thing it would allow them to do is proxy the package and the valid signature, not alter them
<mdeslaur> beuno: they could replace the package with another
<mdeslaur> beuno: but, it's still using ssl, so even that isn't a huge risk
 * beuno nods
<brendand_> cjwatson, btw this job makes sure not to run integration tests prior to generating coverage right? https://jenkins.qa.ubuntu.com/view/Utopic/view/All/job/click-utopic-armhf-ci/7/cobertura/_default_/
<cjwatson> brendand_: I wouldn't expect it to run integration tests at all, since that's done in autopkgtests
<brendand_> cjwatson, mvo proposed to have them run on each merge proposal as well. not sure if that job does that
<rbasak> alexbligh1: I think you need to publish a new apache2 package to your repo, which does the conffile handling and deletes it. And then publish a mod-ident package to your private repo, which pre-depends on a minimum of your specific apache2 version.
<cjwatson> brendand_: seems to, we get MP reviews
<rbasak> alexbligh1: then when you update a system, it'll pick up the apache2 fix for the conffile first, and dpkg will forget about the conffile. Only then will your mod-ident package be installed which will supply a new one.
<rbasak> alexbligh1: then, get an apache2 SRU sponsored, which either also removes the conffile correctly, or restores mod-ident.
<rbasak> (if I sponsor you, I will prefer what Debian does to fix this issue, assuming it affects them also)
<alexbligh1> rbasak, I've investigated a bit further. Actually what is happening is that the preinst and postinst of apache2.4 *do* treat it as an obsolete conffile - i.e. they do it exactly per the book. They see its md5sum hasn't changed, then they delete it. That's the problem. That prevents it from ever being used by any debian package again as far as I can see.
<alexbligh1> rbasak, I'd actually be compounding things if I published my own apache2.4 version, as apache2.4 does it precisely correctly according to the link you published.
<rbasak> alexbligh1: hmm, OK. I think I understand what you're saying, but that doesn't match my understanding. I don't believe that it's possible to make packaging prevent a conffile from ever being used again.
<rbasak> alexbligh1: you may well be right though - this is beyond my knowledge in that case though.
<alexbligh1> I did an strace of dpkg-query et al. The issue is (I think) that the updates file continues to list a conffile entry for that file under apache 2.2. So if someone ever purges apache 2.2 then it will be deleted.
<alexbligh1> I am presuming dpkg does not in general cope well with a conf file owned by two packages anyway.
<brendand_> cjwatson, doesn't look like it runs the integration tests though
<brendand_> mvo, you might want to check up on that - if you were expected it to run the integration tests
<cjwatson> brendand_: Like I say, those are run in autopkgtests
<cjwatson> brendand_: see the first link I gave you
<cjwatson> brendand_: Oh, yeah, it's true those aren't currently run on every MP - sorry misunderstood
<brendand_> cjwatson, :)
<alexbligh1> rbasak, hmmm - if I add Conflicts: apache2.2-common, Breaks: apache2.2-common, will that cause apache2.2 to be purged (effectively) when my package is installed? Or at least get the conffile 'ownership' removed?
<rbasak> alexbligh1: maybe. You could try Breaks/Replaces, too.
<rbasak> It won't purge the old package, but dpkg will understand that the new package owns the files.
<alexbligh1> rbasak, that sounds worth a try. And would be very simple.
<tedg> jodh, Do you guys have a plan when you expect to release the next Upstart?
<mvo> brendand_: aha, thanks. I will have a look
<mvo> brendand_: I need to check in what kind of container they are running, the nice property of the autopkgtest is that they run as root so I can install clicks systemwide etc in the integration tests
<jodh> tedg: we're still battling some issues with the async handling. fia estimate - end of next week earliest tbh.
<tedg> jodh, Okay, thanks for the info.
<shadeslayer> cjwatson: btw requirements sent to ubuntu-release
<shadeslayer> for Plasma 5 ISO
<jodh> grr - emulator still borked for me :(
<alexbligh1> if I'm reporting a bug that a precise->trusty upgrade fails in an lxc container, what package should I report it against?
<cjwatson> shadeslayer: thanks
<stgraber> alexbligh1: what kind of failure are you getting?
<alexbligh1> stgraber, I /thought/ I was was getting a hang somewhere on udev on reboot. But it appears it's a 2 minute wait. I'll see if the wait reoccurs if I stop and start it.
<alexbligh1> stgraber, I am obviously too impatient
<alexbligh1> stgraber, yup, a nice long wait after "Starting Bridge file events into upstart   ...done." - was starting instantly under precise.
<stgraber> alexbligh1: hmm, weird
<stgraber> alexbligh1: you may want to wipe /var/log/upstart/* and reboot the container, then check again after boot for any scary error
<stgraber> alexbligh1: typically 2min delay means something failed during network bring up
<alexbligh1> stgraber, literally all I had done was make a new precise container, install apache2, install update-manager-core, then do do-release-upgrade -d.
<alexbligh1> I have no RDNS but that surely should not be an issue
<stgraber> alexbligh1: ok, trying that quickly here
<alexbligh1> stgraber, I selected all default options on do-release-upgrade save that I said it could restart services itself
<alexbligh1> stgraber, and wiping /var/log/upstart/* does not help
<stgraber> alexbligh1: it shouldn't help but it should then log some useful things in there
<alexbligh1> stgraber, I /think/ it might be stuck on dhclient.
<alexbligh1> which is odd as I have a static IP in my lxc file
<alexbligh1> hmm. well it comes up with the right IP despite me not running dhcp.
<stgraber> alexbligh1: I'm running the same test here now
<alexbligh1> stgraber, tell me if you have the same result. the logs show it is trying for dhcp a lot, but sadly aren't timestamped. I snapshotted the container.
<stgraber> alexbligh1: worked fine here
<alexbligh1> stgraber, are you using dhcp?
<stgraber> alexbligh1: create a container with "lxc-create -t download -n precise -- -d ubuntu -r precise -a amd64", started it, installed apache2 and update-manager-core, ran do-release-upgrade -d, rebooted, still works fine and booted as quickly as usual
<stgraber> alexbligh1: yep, all default config, so dhcp
<alexbligh1> stgraber, I think the issue (via a look at pstree) is if you are NOT using DHCP but using a static IP set it lxc config file, that precise boots quickly and trusty hangs for dhcp. Seems to be the same on a clean trusty install.
<stgraber> alexbligh1: ah yeah, could be ifupdown or dhclient being confused by a pre-existing IP
<alexbligh1> stgraber, I'm sort of confused as to why console login should not be available until dhclient times out
<stgraber> alexbligh1: you should be able to fix that by either mark eth0 as manual in /etc/network/interfaces in the container or by not setting the ip in the container config
<alexbligh1> stgraber, I shall indeed do that, but I just thought it was odd it all worked with Precise.
<stgraber> alexbligh1: the /dev/console getty is only started once most of the boot sequence is done. That's so you can see any boot messages that'd appear
<slangasek> why do Mint users keep filing random bugs against the nfs-utils package?  (bug #1325367, bug #1335199)
<ubottu> bug 1325367 in nfs-utils (Ubuntu) "System freezes" [Undecided,Invalid] https://launchpad.net/bugs/1325367
<ubottu> bug 1335199 in nfs-utils (Ubuntu) "Login Window Preferences window too large" [Undecided,New] https://launchpad.net/bugs/1335199
<stgraber> alexbligh1: yeah, I think this is in the realm of undefined behavior, something must have changed somewhere in ifupdown or dhclient that makes it fail badly rather than just ignore pre-existing config
<alexbligh1> stgraber, thx
<alexbligh1> slangasek, the second of those, maybe they need the -orsize,wsize options :-)
<slangasek> heh
 * rbasak is tempted to troll slangasek with more Mint-related nfs-utils -unrelated bugs
<slangasek> rbasak: pretty sure I will know it's you though :)
<rbasak> :)
<Laney> Bobie Rasak
<alexbligh1> rbasak, (after some container fun) sadly Provides: & Breaks: doesn't work. dpkg-query still thinks the config file is owned by apache2.2-common. I'm guessing the problem here is Provides: Breaks: to replace files only works for binaries and not for conffiles. Bit stuck!
<rbasak> alexbligh1: you do mean Replaces, right?
<rbasak> If not you need that.
<alexbligh1> um
<alexbligh1> Breaks: & Replaces:
<alexbligh1> ignore Provides:
<rbasak> alexbligh1: I'm not sure exactly what's going on there, sorry. I do think it must be possible.
<alexbligh1> apache2.2-common is showing the conffile as obsolete (which is an improvement), but dpkg still didn't see fit to actually install it!
<alexbligh1> rbasak, well, if I do Replaces:+Breaks: and check for the existence of the file in postinst and if it's not there, copy it in, that appears to leave the system in a sane state. Which is disgusting but works for now.
<sergiusens> pitti: hey, I'm looking at that dbus/autopilot issue; I need some clarification on how some things work
<alexbligh1> stgraber, stranger and stranger. It wasn't dhcp. static interface file does the same thing. But I found this suspicious item in pstree: "sleep 40"
<stgraber> alexbligh1: if you have an IP defined in the container config, you need to have /etc/network/interfaces say "iface eth0 inet manual"
<stgraber> alexbligh1: putting inet static is as invalid as inet dhcp so both will result in the 2min wait at boot time (which is what you'll see as a bunch of sleep of various lengths)
<alexbligh1> stgraber, I've got it auto static (with the right set of IPs). Is that bad?
<alexbligh1> oh
<stgraber> auto eth0
<alexbligh1> I'll try manual then
<stgraber> iface eth0 inet manual
<stgraber> or just nothing at all (which should give you the same result)
<alexbligh1> stgraber, thanks, that fixed it :-
<alexbligh1> :-)
<sarnold> cjwatson, beuno, mdeslaur: one the one hand, I'd really like the json response from the server to be signed as well so the user has some confidence that what was on screen at "install" button-clicking time is actually what gets installed. On the other hand, if the user can't tell the difference between "netflix" and "netflÄ±x" application launch icons, they won't be able to tell the difference between "netflix" and "netflÄ±x" ap
<beuno> right
<beuno> do you have an idea on how to make those things clearer to the user?
<mdeslaur> display the publisher
<sarnold> cjwatson, beuno, mdeslaur: and I'm a little concerned about what happens if a developer submits an application package with a package name that's 254 chars long; tacking .asc on the end will probably break something :)
<mdeslaur> sarnold: we can add that check to our click package sanity script thingy
<sarnold> beuno: I'm afraid it's mostly on us to help prevent fishing attack copy-cat applications. :(
<beuno> mdeslaur, the publisher should either be already displayed, or is on someone's ToDo. I can check.
<mdeslaur> beuno: that's cool
<cjwatson> Of course that just moves the problem to copy-cat publisher names
<beuno> yes it does
<cjwatson> My best suggestion for this is to make sure there's an ASCII-only identifier and always show that somewhere as well (even if perhaps not prominently)
<cjwatson> Probably also forbidding whitespace in that
<cjwatson> The existing full package name should do
<beuno> well, I guess those are the rules for...right
<mdeslaur> displaying the publisher, and the other apps from the same publisher simply allows a user to see if something is the real facebook app, and not one of the zillion webapps, but I agree copycat names would still be a problem
<beuno> we also allow duplicate app names, so there can be thousands of apps called "Netflix"
<cjwatson> Display names are all well and good but the requirements for them aren't really compatible with avoiding lookalike Unicode codepoints and so on
<cjwatson> And that
<mdeslaur> but copycat names can be viewed as a malicious attempt at fishing, and we can ban them once they are discovered
<beuno> personally, I use popularity in the android store
<mdeslaur> ah, yes, that's also good
<beuno> as in, how many people downloaded it, reviews, etc
<mdeslaur> anyway, this is a parallel problem to package signing
<sarnold> "oh, good! twelve downloads! this must be the real thing to have so many" :)
<beuno> but there's a bootstrapping period
<beuno> hurtful!
<sarnold> metcalf's law is a cruel heartless beast
<beuno> and yes
<beuno> it's orthogonal to signing
<beuno> not something to ignore, just another level of a problem
<beuno> you also have to make a payment in the android and ios stores
<beuno> so that already is a small barrier
<beuno> and some form of identification
<mdeslaur> yes, it allows for getting a legal name and address
<sarnold> mmm. tough. I can see the obvious appeal there :) but I think that's a barrier we'd rather not artificially throw in front of developers.
<mdeslaur> sarnold: you can have different requirements...apps confined with standard policy groups are well confined, maybe not...apps that require manual review and/or agreements because they do something reserved, you most definitely want to know who the developer is
<mdeslaur> but see, this is why I didn't study law
<mdeslaur> too hand-wavy for me :)
<beuno> it's all made up anyway
<sarnold> mdeslaur: yeah, maybe there's room for fiddling there. I for one would like to know that the Chase Banking App I installed came from someone with $50 and a willingness to say "I legally represent Chase and I know they'll lop my head off if I'm lying"  :)
<mdeslaur> sarnold: heck, I would even be good with us _giving_ $1 per app to people to be able to get a confirmed address
<beuno> ok, so I'll pick this up in a separate thread
<beuno> to not distract us from signing
<sarnold> mdeslaur: well, okay, if you put it that way. What's one more buck to chase? :) haha
<rbasak> How about doing a web browser green ev certificate style thing? Distinguish a "verified account" in the UI.
<rbasak> Though that is another UX can of worms.
<mdeslaur> sarnold: my point is, it's not about the fee, that's artificial, it's about getting someone's name and address, which is just high enough to prevent anonymous malware uploads
<mdeslaur> rbasak: you could sell rankings
<mdeslaur> the "official" apps always get listed higher for exact search terms for example
<sarnold> ooops, we started a serious discussion on Security Team Evil Fridays  :)
<mdeslaur> heh, an off-topic discussion in #ubuntu-devel no less
<mdeslaur> mdeslaur: this channel is for development, go rant somewhere else.
<rbasak> I also have an opinion that a web of trust is the only real way. App developers should either pay to have some official signature, or find a community member already in the PGP strong set. That should prevent phishing on similar-looking names, since someone signing for such names could always be blacklisted (and closer in the trust chain if necessary)
<rbasak> But I understand that this might be too much of a barrier for new app developers.
<sarnold> rbasak: not to mention it'd only take one person i nthe strong set to set up an auto-sign bot that includes anyone else into the strong set, hehe
<rbasak> sarnold: that's what the blacklisting would be for :)
<mdeslaur> rbasak: well, the web of trust people are able to understand is ranking, ratings, popularity...I'm not sure how you get users to make a decision based on anything else
<rbasak> Users would make a decision based on identity name (uid), as signed into the strong set, and only that name.
<mdeslaur> rbasak: users aren't able to do that
<mdeslaur> "FacebookApp", "FaceBook", "Facebook" all look the same to users
<rbasak> mdeslaur: right, but somebody who signs anything that looks like Facebook into the strong set without it actually being Facebook deserves to be blacklisted.
<rbasak> And it's less whack-a-mole since anything on that trust path can be blacklisted.
<mdeslaur> rbasak: so I was planning on calling my new game 'Apple', should I be blacklisted?
<rbasak> mdeslaur: no, but your PGP uid "Apple" should not be signed into the strong set, and anybody who does deserves to be blacklisted.
<rbasak> I suppose there are edge cases like what happens if I change my name to "Apple" by deed poll.
<mdeslaur> rbasak: oh, my uid is going to be 'Equinox', or 'Chase'
<mdeslaur> I haven't decided yet
<mdeslaur> perhaps 'Acme'
<rbasak> Still though, I think by having a trail of real identities much of the phishing problem will go away. They only exist because others can't identify them through any path.
<rbasak> That's just IMHO. I accept that only practice will determine the effectiveness of my approach.
<mdeslaur> I do believe we should be protecting the big names and make sure we don't end up like this: http://www.geek.com/microsoft/when-will-microsoft-clean-up-the-windows-phone-store-1583813/
<mdeslaur> original link: http://oneslash.postach.io/microsoft-please-clean-your-store-from-junk#.Uu5FGbRGa9U
<mdeslaur> anyway, way off-topic for #ubuntu-devel
<rbasak> Yes - I agree that's an important problem.
 * rbasak shuts up now
<smoser> hey.
<smoser> who would i ask to get a trusty-netboot at http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/
<smoser> to follow from https://launchpad.net/ubuntu/+source/linux-meta-lts-trusty
<infinity> smoser: s/-updates/-proposed/
<infinity> smoser: If you test the one in -proposed and tell me it's not busted, I'll happily promote it.
<smoser> hm..
<smoser> i suppose maybe i can do that.
<smoser> infinity, is there a bug that i'd report that on ?
<infinity> smoser: Nope, just a verbal "it doesn't entirely suck" is fine.
 * infinity needs to run out for a bit.
<smoser> infinity, ugh. this could be user error, but when debootstrap starts i see:
<smoser>  Warning: Couldn't download package bsdutils (ver 1:2.20.1-1ubuntu3 arc amd64)
<cjwatson> smoser: Probably needs apt-setup/proposed=true at the moment
<cjwatson> smoser: Otherwise (unfortunately) you end up with a mismatched set of things from bug 1172101
<ubottu> bug 1172101 in wget (Ubuntu Precise) "wget-udeb should install to /usr/bin/wget instead of /usr/bin/wget.gnu" [High,Fix committed] https://launchpad.net/bugs/1172101
<cjwatson> All the fixes from that, bug 1135163, and bug 833994 need to be tested and promoted-or-not together
<ubottu> bug 1135163 in debootstrap (Ubuntu Precise) "d-i can't install against an https mirror" [High,Fix committed] https://launchpad.net/bugs/1135163
<ubottu> bug 833994 in cobbler-enlist (Ubuntu) "debian-installer does not support https when using with preseed files" [Medium,Triaged] https://launchpad.net/bugs/833994
<cjwatson> And I think they deserve the full seven-day aging period, not a fast-tracked promotion, especially since some others have expressed interest in testing them
<cjwatson> infinity: ^-
<cjwatson> I know that isn't directly related to -lts-trusty, but I can't disentangle them now without a complete revert and starting from scratch, which I'm probably not willing to do given that the HTTPS fixes are needed for 12.04.5
<smoser> why are https fixes needed ?
<cjwatson> We have customers
<stgraber> @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:
<smoser> infinity, well, i did run through a basic test
<smoser>  http://paste.ubuntu.com/7712804/
<smoser> seems reasonable. as cjwatson pointed out, it does require the proposed
<infinity> smoser: It shouldn't require proposed, the kernel is in -updates now.
<smoser> see cjwatson's comments.
<infinity> smoser: Oh, the wget thing, right.
<smoser> it does require proposed
<smoser> yeah
<infinity> Happy to let that bake and have it tested more.
<infinity> smoser: But if it works for you with proposed=true, yay.  That's one useful datapoint.
<smoser> right. so its not completely broken.
<Noskcaj> mterry, Could you have another look at bug 1327458 please?
<mterry> Noskcaj, still needs a bug subscriber
<mterry> but I can look at the rest
<Noskcaj> I was hoping the desktop team would be the subscriber, but i've got no responce
<mterry> Noskcaj, looks good besides that, will comment so
<Noskcaj> thanks
#ubuntu-devel 2014-06-28
<syntroPi> i want to modify an existing debian package and add some patches to it: in the debian/ directory there is that rules file: when i add an patch/ directory to the debian/ directory which command in the rules file applies those patches?
<Noskcaj> syntroPi, They automatically apply
<Noskcaj> as long as debian/source/format exists
<Noskcaj> with "quilt (3.0)" in it
<syntroPi> Noskcaj, yes that file exists with "3.0 (quilt)" in it. but there is no debian/patches
<Noskcaj> just make debian/patches. the rules file should see it
<syntroPi> can i just create debian/patches/series with "mypatch.patch" in it and debian/patches/mypatch.patch?
<Noskcaj> yep
<Noskcaj> could you pastebin the rules file so i can check it
<syntroPi> from which directory will the patches be applied? "debian/.." ?
<Noskcaj> what do you mean?
<syntroPi> are the patches expected to be relative to the <package_name> directory?
<syntroPi> Noskcaj, http://paste.ubuntu.com/7714491/
<syntroPi> its from http://archive.ubuntu.com/ubuntu/pool/universe/e/easystroke/easystroke_0.6.0-0ubuntu2.dsc
<Noskcaj> the patches apply to the top directory
<Noskcaj> So you know, you're using an old version of the package
<Noskcaj> 0.6.0-0ubuntu3 is the current one
<syntroPi> oh well good i will check the differences, but seems there is no patch for my issue included there
<Noskcaj> there's no real difference (it's just a rebuild)
<Noskcaj> I'd only just checked
<syntroPi> oh cool seems that works, too easy, should have tried that in the first place :-)
<syntroPi> ls
<syntroPi> Noskcaj, workes like a charm, thank you for your help
<Noskcaj> no problem. ping me if you need any more help
<geser> what's the current fix for code linking with -lgfortran where gcc is 4.8 while libgfortran is 4.9 and gcc not finding -lgfortran?
#ubuntu-devel 2014-06-29
<hamiltont> cjwatson: FYI I'm going to move my kickseed changed from launchpad into the mailing list as you requested. Please disregard my launchpad code merge request - I'll close it down shortly
<hyperair> did i declare the build-deps wrong, or is apt bugged?
<hyperair> in banshee, that is
<hyperair> libgpod-cil-dev (>= 0.8.2-7~), libgpod-cil-dev (<< 0.8.3-2) | libgpod-cil-dev (>= 0.8.3-4ubuntu3~)
<hyperair> but when doing apt-get build-deps banshee, apt complains that libgpod-cil-dev is too new.
<juliank> Wow that's a strange dependency.
<juliank> hyperair: build-dep only chooses the first alternative IIRC
<juliank> But really not entirely sure
<hyperair> juliank: that seems like the wrong thing to do
<juliank> hyperair: You might want to try with -o Debug::BuildDeps=true
<juliank> and check what that says.
<juliank> hyperair: build-dep does not use standard dependency solving algorithms. In any case, swapping the OR seems more coorrect.
<juliank> or do you really want to prefer the older version?
<hyperair> juliank: well, i just need to exclude a certain version.
<juliank> in any case, tools should prefer the first alternative by definition, so putting the newer one there makes sense.
<juliank> hyperair: or you just build-conflict with the broken version
<hyperair> the problem was that i did a half-assed port of libgpod to gtk3 which i reverted.
<hyperair> oh yeah, i forgot about that
<juliank> A build-conflict is easier to handle here than an ORed build-dependency from APT's perspective
<hyperair> alright
 * ari-tczew notices Mom is broken again :-/
<juliank> hyperair: If you want more detailed information about this, you need to ask DonKult in #debian-apt on OFTC, or wait for mvo to turn up tomorrow
<juliank> They know more than me about APT itself.
<hyperair> alright, thanks
<hyperair> for the time being i've filed a bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1335614
<ubottu> Ubuntu bug 1335614 in apt (Ubuntu) "apt doesn't handle bar build-deps properly" [Undecided,Confirmed]
<hyperair> i'll just workaround it with build-conflicts
<juliank> Some build servers (I believe the  Debian buildds) only consider the first alternative too, AFAIK
<juliank> But it's been some time since I looked at this.
<juliank> It creates more predictable builds to ignore alternatives.
<juliank> Does anyone have contacts at Lenovo I could ask about documentation about the charging control ACPI interface, possibly under NDA?
<hyperair> oh ffs, build-conflicts doesn't work unless i articulate it into = dependencies
<hyperair> so i need one libgpod-cil-dev (= ...) for every version i need to conflict on
<hyperair> goddamnit, why not just use the same dependency resolution engine when it so clearly works?
<juliank> hyperair: Ah, I thought you only had one broken version.
<juliank> Sorry about that.
<juliank> hyperair: Just try swapping the OR then and it should work fine for build-dep and automatic builds. People can still manually build if they have the old version installed
<juliank> In fact, Ubuntu build servers do consider alternatives too IIRC.
<hyperair> juliank: automatic builds seem to have worked fine though.
<hyperair> it's just that apt-get build-dep fails
<juliank> Yes, as said, launchpad considers alternatives. Debian infrastructure doesn't.
<wgrant> Launchpad doesn't exactly consider alternatives.
<wgrant> It always takes the package named in the first alternative, but then applies versioned constraints afterwards.
<hyperair> i see
<wgrant> So in this case it will work, as the two constraints refer to the same package. But in the general alternative case, the first one wins.
<cjwatson> ari-tczew: Should be fixed shortly, thanks.  usbredir was busted.
<cjwatson> wgrant: Well, it falls back to other alternatives if the package named in the first alternative doesn't exist, which isn't true in Debian.  (i.e. what's now sbuild --resolve-alternatives)
<wgrant> Ah yes, true.
<wgrant> But it has to not exist, not just be a bad version.
<cjwatson> Right.
<LocutusOfBorg1> Hi cjwatson, I'm not sure if I waited enough
<LocutusOfBorg1> but will vtk automatically be sync'd or not?
<LocutusOfBorg1> because your changes are in debian now, but the changelog is different...
<LocutusOfBorg1> I wonder how the sync/merge works exactly
<infinity> LocutusOfBorg1: Packages with 'ubuntu' in the version aren't automatically synced.
<infinity> LocutusOfBorg1: Did a manual sync now, after verifying the diff.
 * jtaylor wonders if his tcl patches still work
<jtaylor> didn't verify the debian package :/
<jtaylor> (in vtk)
<jtaylor> neat they still seem to work
<michagogo> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<michagogo> 19:12:12 <stgr aber (spaced to avoid possibly-unwanted ping)> that's something which needs discussion with the sru team
<michagogo> How is such a discussion initiated?
 * michagogo is trying to figure out how to move bug 1314615 forward...
<ubottu> bug 1314615 in tripleo "Existing tripleo passwords files are not correctly updated for newly added services" [Medium,Fix released] https://launchpad.net/bugs/1314615
<michagogo> erm, I mean bug 1314616
<ubottu> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,Confirmed] https://launchpad.net/bugs/1314616
#ubuntu-devel 2015-06-22
<sergio-br222> there is no libqt5opengl5-gles-dev in the armhf repo
<sergio-br222> so yeah, it's only x86 stuff
<Logan> is there any way to simulate pkgstriptranslations (as it acts on the buildds) in pbuilder?
<lifeless> sergio-br222: what RAOF was saying is that libqt5opengl5-dev on armhf *is GLES only*.
<lifeless> sergio-br222: and that the packaging layout is just really confusing for $reasons
<sergio-br222> heh
<sergio-br222> OK, now I'm understanding
<sergio-br222> $reasons, heh
<lifeless> RAOF: might be something to fix :)
<lifeless> RAOF: since the reasons seem fairly shallow
<dupingping> The awesome software is published, You can use the trial version of Sticky Notes.
<dupingping> http://korsoftware.com
<pitti> Good morning
<tsdgeos> What's the best way to get a patch into the fbi package? It's just a one liner so that it actually picks up the correct jpeg lib and doesn't just abort on run
<dholbach> good morning
<jamespag`> morning
<flexiondotorg> Laney, I see you're piloting sometime today. Please may I kindly request you take a look at the package updates:
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1466521
<ubottu> Ubuntu bug 1466521 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 0.4.9 new nelease [debdiff attached]" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1466785
<ubottu> Ubuntu bug 1466785 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 0.4.6 release [debdiff attached]" [Undecided,New]
<alkisg> infinity: good morning, may I ping you to approve this x11-utils SRU that's in the precise queue? https://bugs.launchpad.net/ubuntu/+source/x11-utils/+bug/1463663, https://launchpad.net/ubuntu/precise/+queue?queue_state=1, https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<ubottu> Ubuntu bug 1463663 in x11-utils (Ubuntu) "[SRU] Enable setting property of type UTF8_STRING" [Medium,In progress]
<Riddell> pitti_: libkdegames seems stuck on a test server error, can you retry it? https://jenkins.qa.ubuntu.com/job/wily-adt-libkdegames/lastBuild/ARCH=amd64,label=adt/console
<highvolt1ge> t/win 23
<seb128> Riddell, hey, did you notice bug #1461987?
<ubottu> bug 1461987 in kpackage (Ubuntu) "package kpackagetool5 5.9.0-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/kservicetypes5/kpackage-packagestructure.desktop', which is also in package libkf5package5:i386 5.9.0-0ubuntu1" [Medium,Confirmed] https://launchpad.net/bugs/1461987
<Riddell> seb128: hmm I did not, thanks
<seb128> Riddell, yw!
<Laney> LocutusOfBorg1: debfx: have you seen any problems with cmake 3.2 and CMAKE_INSTALL_LIBDIR? qtmir has started FTBFSing because it doesn't point to the multiarch libdir any more.
<debfx> Laney: I don't know how it worked before but -DCMAKE_INSTALL_PREFIX=$(TMP1_DIR)/usr/ is just wrong
<pitti_> Riddell: I doubt that this helps -- the -proposed version has failed consistently 8 times in a row, it's a real regression (in code or test)
<Riddell> pitti_: for which one?
<pitti_> Riddell: libkdegames
<Riddell> ah libkf5kdegames6
<Riddell> mm I think that's just not been changed since the kdelibs4 version so of course it's wrong
<Laney> debfx: this seems weird
<debfx> Laney: cmake uses multiarch paths only when the prefix is /usr, except when you patch it too much.
<debfx> so I'd suggest to a) fix the cmake invocation in qtmir
<debfx> b) fix the cross compile patch to not alter behavior in the default case
<debfx> c) install MultiArchCross.cmake to the correct dir
<cyphermox> good morning!
<seb128> hey cyphermox, how are you?
<cyphermox> good, you?
<seb128> did you have good holidays?
<seb128> I'm good thanks ;-)
<cyphermox> yep :)
<Laibsch> Previously, I was able to upload to a release pocket in my ppa other than the one specified in the changelog via "incoming = ~r0lf/ppa/ubuntu/trusty" in dput.cf
<Laibsch> Is that no longer supported?  It was very nifty.
<cjwatson> Laibsch: Should still work, but I can't see any evidence of you having tried that recently in the logs ...
<cjwatson> Laibsch: Though the preferred form now is ~r0lf/ubuntu/ppa/trusty; the earlier form is deprecated
<Laibsch> cjwatson: it was rejected by dput, I guess.  It could be that this is because it's debian's dput in this case
<cjwatson> Laibsch: I don't see why dput would care.  Do you have a transcript?
<Laibsch> cjwatson: http://paste.debian.net/252618/
<cjwatson> Laibsch: That has nothing to do with the incoming directory.  See line 28.
<Laibsch> dsc-upload-$target is a script I wrote for uploading to ppa: http://paste.debian.net/252619/
<cjwatson> "Error: uploading files for distribution UNRELEASED to trusty not allowed."
<cjwatson> $ dpkg -L dput | xargs grep -s 'not allowed'
<cjwatson> /usr/bin/dput:            raise dputhelper.DputUploadFatalException("Error: uploading files for distribution %s to %s not allowed."%(distribution, host))
<Laibsch> well, but I am uploading to my PPA. At least that is what i am trying to do and what worked until a few days ago.
<cjwatson> well, but you need to read the error message
<cjwatson> it's not relevant where you're uploading to
<cjwatson> except in that the host definition in dput's config has an allowed_distributions regex which is checked
<cjwatson> but UNRELEASED normally simply means what is says; I'd recommend running dch -r first
<cjwatson> *what it says
<cjwatson> releasing things (to PPA or otherwise) which are marked UNRELEASED is terribly confusing and should be avoided
<Laibsch> yes, I now checked /etc/dput.cf and this indeed seems to be Debian-specific
<Laibsch> checking for UNRELEASED
<cjwatson> it's not Debian-specific
<Laibsch> well, I am working on releasing the package officially and just making some testing packages available now
<cjwatson> the default allowed_distributions in Ubuntu's dput.cf for all hosts is (?!UNRELEASED)
<Laibsch> how about HALFRELEASED ;-)
<cjwatson> I care not what you write there, but dput's config does
<Laibsch> apparently, but IIRC this used to work when I did this kind of stuff in now-EOL lucid
<Laibsch> anyway, the root of the problem was found. thanks!
<cjwatson> that was rather a long time ago.  anyway dput's config is sensible and if I were you I'd improve your practices to be less confusing :)
<cjwatson> this dput change appears to predate lucid, see dput 0.9.2.30's changelog
<cjwatson> but hard to debug something that long ago
<dobey> jamespage: hi. why did you upload intermediate broken versions of unittest2/testtools to wily, rather than the latest versions?
<Laney> debfx: looks like (b) is enough ;)
<Laney> I saw "  * Fix install path of MultiArchCross.cmake to be cmake-3.0." but didn't twig that this was for 3.0 and not 3.2
<jamespage> dobey, that was an interim step towards newer versions, without the requirement for two new bits of packaging right now
<Laney> so discounted it as a possible breakage source
<dobey> jamespage: well it seems that it breaks @testtools.skip decorator, causing previously working tests to fail in autopkgtests; and it seems wily has python 3.5, so the latest versions could probably work without the other new packages in wily, by depending on 3.5?
<jamespage> dobey, urgh - sorry - obviously un-intended
<dobey> jamespage: any idea when this can be fixed? https://jenkins.qa.ubuntu.com/job/wily-adt-unity-scope-click/lastBuild/ARCH=amd64,label=adt/console for a reference to see the skip failure
<jamespage> dobey, looking now
<doko> mvo, online?
<mvo> doko: sprinting, sort of online
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<jamespage> dobey, looks like some sore of change in behaviour - even with latest I still see the same issue with the scopes test
<jamespage> dobey, still looking
 * dholbach hugs Laney
<dobey> jamespage: hmm, i am seeing the tests passing with what's in ppa:dobey/testtols (installed the trusty versions on top of wily)
<jamespage> dobey, ok - I have a fix - but its in the scope-harness package
<jamespage> dobey, ScopeHarnessTestCase needs to inherit from testtools.TestCase - currently it goes off unittest.TestCase
<jamespage> this may be a bug in testtools - but that at-least gets you past this problem
<dobey> hmm, ok
<jamespage> dobey, I'll raise a bug and see what upstream think
<dobey> jamespage: i guess we can land that change. i don't have a problem with it
<dobey> it seems like an unnecessary dep though, since it doesn't seem python3-scope-harness depends on testtools for anything else
<jamespage> dobey, https://bugs.launchpad.net/testtools/+bug/1467558
<ubottu> Ubuntu bug 1467558 in testtools "testtools.skip decorator not functional with unittest.TestCase as base class" [Undecided,New]
<dobey> oh
<dobey> jamespage: i guess the issue is because the decorator is on setUp there?
<jamespage> quite possibly
<jamespage> I think its the mixing of unittest/unittest2 which is causing the problem - this may have worked by accident before
<dobey> jamespage: i'm re-running the jenkins test builds on https://code.launchpad.net/~dobey/unity-scope-click/more-harness-tests/+merge/255211 now. i'm at least not seeing the problem there, with the testtools from my ppa; we'll see what happens with proposed
<jamespage> ok
<jamespage> dobey, apologies for the break
<dobey> jamespage: well, if it works ok with this branch, i'll fast track it through landing to get things back on course
<dobey> oh, that jenkins doesn't build with proposed it seems
<dobey> jamespage: looks like the issue is gone with that branch and the testtools in proposed, so I'll try to get it pushed through asap.
<dobey> jamespage: so i guess the issue is that it doesn't like the decorator on setUp() in newer versions for some reason
<jamespage> dobey, looks that way
<jamespage> does anyone know how often the component mismatches report is mean't to refresh?
<jamespage> http://people.canonical.com/~ubuntu-archive/
<jamespage> last refresh at 0850 ish today - I was hoping that my junit4 upload this morning might have made that a little shorter
<LocutusOfBorg1> Laney, sorry I was afk, seems you already have the solution :)
<Laney> LocutusOfBorg1: ya, merge mistake
<Laney> I moved the offending file up a bit in .install and added a comment but I worry this won't be enough at the next merge
<LocutusOfBorg1> Laney, I guess it will be enough if I prepare the next merge by myself (at least I hope to)
<LocutusOfBorg1> :)
<rbasak> infinity: any chance of SRU review for docker.io please?
<infinity> Maaaaaybe.
<work_alkisg> infinity: thanks a lot :)
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> TBC
<pitti_> wgrant, cjwatson: how "scalable" is stalingstack right now? i. e. how many instances could/should I be using in parallel for autopkgtesting? or should I ask IS that and not you?
<sarnold> who is the right person to talk with for more privileges on errors.ubuntu.com? cboltz is very helpful to the apparmor project, he's trying to track down something that's been reported in errors.ubuntu.com, and it'd be nice if he had privileges to view all the *apparmor* reports, at a minimum..
<smoser> anyone know of something that does what 'annotate-output' does but does so without running 'date' for every line of input ?
<sarnold> smoser: is it the calls to date you don't like or the timestamps themselves? maybe pass a format like +"" ?
<smoser> the fact that it calls date. ie, forks for every line of input.
<sarnold> ouch
<sarnold> strftime is right there...
<smoser> in bash ?
<sarnold> this thing is written in _bash_??
<smoser> yeah. its really simple. and works really well.
<smoser> but no 'date' builtin in bash means fork.
<sarnold> it's shorter and cleaner than I expected :) impressive
<hallyn_> arges: bug 1425619 - i think i'm about to become very cross
<ubottu> bug 1425619 in ubuntu-cloud-archive "Migration fails between QEMU 1.5 and QEMU 2.0" [Undecided,New] https://launchpad.net/bugs/1425619
<arges> hallyn_: what happened now
<arges> hallyn_: so the missing bit was allow_incoming_qemukvm
<cjwatson> pitti_: You should ask IS that; we don't have direct visibility.
<hallyn_> arges: yeah.  so the guy who was marking it incomplete wasn't fully up on the issue.  now i guess the test case wasn't fully documented ...
<hallyn_> grrrr!
<arges> hallyn_: well we can get this into the next update
<hallyn_> had you deleted the qemu pkg or can that still be used alongside a new libvirt pkg?
#ubuntu-devel 2015-06-23
<hallyn_> hm, dash isn't coming up
<hallyn_> (the dash, not the shell)
<dholbach> good morning
<tsdgeos> dholbach: do you know how do i get the patch at https://bugs.launchpad.net/ubuntu/+source/fbi/+bug/1450949/comments/8 to the package so that the fbi package is not totally useless by aborting on run?
<ubottu> Ubuntu bug 1450949 in geeqie (Ubuntu) "Wrong JPEG library version: library is 80, caller expects 62" [Medium,Confirmed]
<tsdgeos> which is quite funny is marked as medium since basically makes the software unusable
<dholbach> tsdgeos, maybe somebody marked the importance as medium who didn't really know what they were doing
<tsdgeos> i guess, now it feels a bit weird if i overwrite the importance given i'm a user of the package that just happens to have the power to change it
<dholbach> http://packaging.ubuntu.com/html/patches-to-packages.html is basically the answer
<dholbach> but I can take a quick look too
<dholbach> there's already debian/patches/use-jpeg-turbo.diff which patches the value to 62 right now
<tsdgeos> guess coming from debian that may be using jpeg-turbo and not libjpeg.so.8 like us
<tsdgeos> the package is a bit weird since it packages the jpeg headers itself
<dholbach> yeah
<dholbach> tsdgeos, I uploaded the following patch: http://pastebin.ubuntu.com/11760921/
<dholbach> (and confirmed that it works)
<tsdgeos> dholbach: awesomeness, will it hit vivid or just wily?
<dholbach> oh, that's just wily
<dholbach> tsdgeos, is it the same issue in vivid?
<tsdgeos> dholbach: yep, it's how i found it
<dholbach> ok
<dholbach> tsdgeos, do you know why there's a geeqie task for the bug?
<tsdgeos> i don't know what geeqie is sorry :/
<tsdgeos> ah you mean the other package
<tsdgeos> no idea really
<dholbach> mh, ok
<dholbach> I'll remove it from the bug - looks like geeqie only depends on it
<tsdgeos> yeah my guess it was either a dependency or "not sure what i'm doing"
<tsdgeos> after having a grep-look a geeqie's code
<dholbach> tsdgeos, uploaded the vivid fix as well - it's now sitting in the review queue
<tsdgeos> dholbach: great :) thanks a lot :)
<dholbach> anytime
<jamespage> pitti, any idea why component-mismatches-proposed is still showing junit4 + dependency explosion? the junit4 I uploaded yesterday should have resolved that
<LocutusOfBorg1> Logan, sorry, I fixed one udiskie build failure introducing another... :s
<LocutusOfBorg1> the new one comes from upstream, I'm opening a bug report there
<pitti> jamespage: hm, https://launchpadlibrarian.net/209692232/junit4_4.12-2_4.12-2ubuntu1.diff.gz LGTM too
<pitti> jamespage: perhaps c-m looks at the packages in -release as well, not sure
<jamespage> pitti, junit4 is blocked on migration due to a regression in libreoffice, but that was already failing afaict
<jamespage> (prior to my upload)
<pitti> jamespage: I was just looking -- libo fails on
<Laney> fixing that
<pitti> configure: error: Package requirements (libwps-0.3) were not met:
<pitti> No package 'libwps-0.3' found
<jamespage> awesome
<Laney> (wps transition)
<pitti> Laney: oh, you are? thanks
<Laney> currently deciding the best way to test build this :-)
<Laney> "not"
<pitti> jamespage: so, let's postpone this until it migrates?
<jamespage> pitti, just trying to unexplode component mismatches so that I can reasonable hassle about binary migrations to main :-)
<LocutusOfBorg1> Logan, a fix in on the Debian git, the upload will come shortly :D
<Unit193> pitti: Also, I took a quick look, know what bug (if any) is filed for restarting dbus crashing network-manager and lightdm (and not starting network-manager back up, at that)?
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach
<mdeslaur> cjwatson: in wheezy's putty package, you replaced the security fix's use of smemclr() with memset()...I have a feeling that's going to get optimized away by the compiler...
<cjwatson> mdeslaur: Do you mean in vuln-bignum-division-by-zero.patch ?
<mdeslaur> cjwatson: private-key-not-wiped-2.patch
<cjwatson> Oh, I'm on the wrong branch, one moment
<cjwatson> mdeslaur: To be fair, wheezy's putty didn't have smemclr at all, so if that's a problem, it's a problem for all the rest of putty as well
<mdeslaur> ah, yes, looks like there are other similar uses
<cjwatson> mdeslaur: But please do file a Debian bug - I probably ought to backport aa5bae89 et seq
<cjwatson> Thanks for the spot
<mdeslaur> cjwatson: ack, will do, thanks
<Laney> stgraber: trying to use lxd for the first time on wily and I think I'm being stung by https://github.com/lxc/lxd/issues/764 - any plans to update ubuntu's package?
<pitti> Unit193: sorry, I don't think I've seen a bug report like that before
<pitti> Unit193: we don't restart dbus on upgrades for this very reason -- many dbus services don't get along with that very well
<pitti> Unit193: it even used to crash your entire session (although I think that got fixed at some point)
<cyphermox> good morning!
<jtaylor> pitti: hi, the lvm2 package has the lvmcache manpage but the executable seems to be missing, is that a mistake?
<jtaylor> in vivid
<pitti> hey cyphermox, how are you?
<pitti> jtaylor: hm, no idea -- does Debian have it?
<seb128> hey cyphermox
<jtaylor> need to check
<seb128> cyphermox, btw did you see my ping from some days ago with that nm-applet upstream patch to backport?
<jtaylor> pitti: nevermind there is no such binary ...
<jtaylor> though fixing bug 1423796 would be nice
<ubottu> bug 1423796 in lvm2 (Ubuntu) "Unable to mount lvmcache root device at boot time" [High,Confirmed] https://launchpad.net/bugs/1423796
<cyphermox> pitti: hey!
<cyphermox> seb128: hi! I'm not sure, do you mean the one for the add_menu_item crash?
<seb128> cyphermox, yes
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<flexiondotorg> Laney, I wonder if you can help.
<flexiondotorg> Laney, I think this package update was not complete correctly - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1466521
<ubottu> Ubuntu bug 1466521 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 0.4.9 new nelease [debdiff attached]" [Undecided,Fix released]
<flexiondotorg> Laney, The update moved some images and added news. The new and moved images are no in the updated package.
<Laney> flexiondotorg: Wasn't me that uploaded it: https://launchpad.net/ubuntu/+source/ubuntu-mate-artwork/0.4.9
<Laney> You could provide a new package for sponsoring to fix it
<flexiondotorg> Laney, Thanks I see the sponsor now.
<pitti> kees, slangasek, infinity, mdeslaur, stgraber: TB meeting reminder
<mdeslaur> pitti: thanks!
<cjwatson> barry: Would it be worth doing a mass retry pass or two on the py35asdefault PPA, to weed out the easy uninstallable-dep cases without too much manual inspection?
<barry> cjwatson: i think it would.  can that be easily done through the api?
<cjwatson> barry: Yep, I can put that together for you
<barry> cjwatson: that would be awesome, thanks!
<infinity> Laney: syncing from Debian to a silo might not be the brightest idea while autosyncs are still on. :P
<cjwatson> barry: http://paste.ubuntu.com/11763253/
<infinity> Laney: (evolution-rss was synced to proposed while your silo was in prep, so you now have a version clash)
<barry> cjwatson: nice, thanks
<cjwatson> barry: scalingstack can probably blast through those in under half an hour, so feel free to do the same a couple more times later if you like
<cjwatson> (though wait for whatever pops out of this round to finish publishing first)
<smoser> pitti, dont know how closely you follow systemd bugs, but since you're the one who fixes all my issues with it, just thought i'd mention them here. bug 1468103 and bug 1468102
<ubottu> bug 1468103 in systemd (Ubuntu) "rc.local runs too early." [Undecided,Confirmed] https://launchpad.net/bugs/1468103
<ubottu> bug 1468102 in systemd (Ubuntu) "rc.local output does not go to console" [Undecided,Confirmed] https://launchpad.net/bugs/1468102
<smoser> (feel free to tell me not to ping you like this)
<doko> infinity, pitti: I'm not amused about gcc-5 stuck in proposed with nobody looking at the triggered autopkg tests. and I'm tired to do that myself, only finding issues with the test environment or other packages
<infinity> "0 days old" is "stuck"?
<doko> the last upload was stuck as well
<Laney> infinity: I'll no-change rebuild or delete if necessary before publishing
#ubuntu-devel 2015-06-24
<alkisg> arges, good morning, may I ping you to put the SRU'ed x11-utils (LP: #1463663) to precise-updates? I've done the verification-done step. Thank you.
<ubottu> Launchpad bug 1463663 in x11-utils (Ubuntu) "[SRU] Enable setting property of type UTF8_STRING" [Medium,In progress] https://launchpad.net/bugs/1463663
<pitti> Good morning
<pitti> smoser: oh, please do ping about these, I need to know what's blocking us
<pitti> doko: I usually override them after checking, but I didn't see it yet in the queue
<pitti> (doing in some minutes)
<pitti> doko: landed now
<dholbach> good morning
<jamespage> if there are any archive-admins around I have a few binary only main promotions I need to unblock FTBFS in proposed:
<jamespage> python-oslo.middleware python3-oslo.middleware python3-oslo.concurrency python-oslo.config python-oslo.vmware
<infinity> jamespage: On it.
<jamespage> infinity, thankyou
<jamespage> infinity, trying to unpick all of the oslo reshuffling :-)
<infinity> jamespage: Yeah, it's been a pain.
<lifeless> jamespage: pip it all up :)
<infinity> lifeless: Not sure how pip helps here.
<lifeless> infinity: it doesn't
<lifeless> I was trolling
<infinity> lifeless: And you used to be such a nice boy.
<lifeless> infinity: your memory is failing in your old age :)
<jamespage> lifeless, lol
<infinity> lifeless: I prefer to think of it not as failure, but rather the success of only remembering the good times.
<infinity> lifeless: Which, for you, is basically just your beard.
<lifeless> infinity: :) nice
<lifeless> infinity: I see you've joined the grey club
<lifeless> infinity: I managed to convince Lynne to stop plucking mine.
<lifeless> so I'm not bald
<infinity> It's the little victories.
<infinity> lifeless: And yes, I'm greying a tad, though it's pretty slow going, given my age, so I can't complain too much.
<infinity> lifeless: My brother was about 50/50 by this age, and my mother was white in her early 30s.
<lifeless> wow
<lifeless> genetics huh
<lifeless> [as in, you beat the odds in your family]
<infinity> lifeless: My brother's also 6 inches taller, so I think he's still winning. :P
<lifeless> infinity: I could make a terrible joke here.
<infinity> lifeless: Code.  Of.  Conduct.
<infinity> jamespage: Fixed up python3-tempest-lib too, looks like a bunch of things were waiting on that.
<jamespage> infinity, quite likely - we've got alot of py3 enablement coming in from work in Debian
<jamespage> infinity, component-mismatches-proposed is just confusing me right now - it looks wrong
<infinity> jamespage: Needs another couple of publisher cycles to sort that, then keystoneclient should be buildable, which a few other bits are waiting on.
<infinity> jamespage: And yeah, c-m is a mess.  I need to try to attack it a bit tomorrow and see if I can unmess it.
<infinity> jamespage: I think it's getting confused by the sheer volume of breakage we brought in this cycle.
<jamespage> infinity, well I fixed junit4 two days ago, which was causing the maven explosion - which should have removed alot
<jamespage> but that is still showing for some reason
<infinity> jamespage: Ahh, nice.  Thanks.  Every time maven tries to promote, the world goes to crap.
<infinity> Erk.  And someone made ltsp depend on MATE, which is blowing up the world too.
<jamespage> lol
<infinity> stgraber: ltsp depends on MATE now?  Halp.  Is that intentional?  Is it time to drop ltsp out of main?
<infinity> stgraber: Or do we just need to swap the gnome-session/mate-desktop-env deps?
<rbasak> infinity: hey. Can we chat about some dpdk packaging that smb is doing? Involving weird upstream arrangements about sonames, sovers, optimisation levels and how to package it all.
<rbasak> infinity: I think I have an idea about how we should be packaging it but I'd like to make sure what I'm suggesting is sane and there isn't a better way.
<rbasak> infinity: can we mumble with smb later today please?
<smb> rbasak, infinity, slight caveat today is my EOD at 1500UTC
<rbasak> I'm free from around 1300 to 1500 UTC
<rbasak> I have to pop out for an eye test in an hour or so. Not sure exactly how long it'll take or when I'll be back.
<rbasak> (by 1300 UTC I imagine)
<infinity> rbasak: Hrm.  1300 UTC is 7am for me.  Not positive I'll be alive, but maaaaybe?
<infinity> rbasak: "Weird upstream arrangements about sonames" scares me a bit, though. :P
<rbasak> infinity, smb: how about I ping when I'm back and we'll see if infinity is awake? Will probably be before 1300 - just not sure exactly when.
<smb> rbasak, Would work for me though there seems to be a higher chance of awakeness when planning for 1400 utc
<infinity> jamespage: Aaaand, now we get to python3-requests-mock.  Irksome that c-m is breaking right now, or it would have told me all of this in one shot. :/
<smb> infinity, could rather be phrased "weird upstream ideas about ..."
<infinity> jamespage: Another round, and away we go.
<rbasak> smb: infinity's awakeness? I thought that went down from 1300 to 1400, rather than up?
<jamespage> infinity, yeah - feel kinda blind without that report :-)
<infinity> rbasak: I'm more likely to be awake at 8am than 7am.  Though both seem slim, given it's currently 3:22.
<rbasak> Oh, OK.
<jamespage> rbasak, you would enjoy the use of unversioned so names in liberasurecode :-)
<rbasak> Well, I'll ping, and you can catch it when you're up, and we'll see?
<infinity> rbasak: We could chat nowish/soonish instead.
<rbasak> infinity, smb: that works too. Mumble now?
<smb> rbasak, not that I would even speculate about thinking to understand the awake/sleep cycles of infinity
<infinity> rbasak: For some value of "now" that allows me to grab a bucket of ice water and a smoke first.
<smb> rbasak, Sure
<infinity> So, in like 5m.
<rbasak> OK. See you on mumble in 5m.
<mitya57> infinity, stgraber: I think ltsp should still work fine with GNOME (Flashback), but that's also in universeâ¦
<infinity> mitya57: It's entirely possible that ltsp-in-main is just an artifact of "all flavours used to be in main, and edubuntu seed ltsp", and it never dropped out because it was never a problem before.  Perhaps worth revisiting.
<infinity> s/seed/seeds/
<mitya57> Yes
<infinity> Well, I guess it would be in an Ubuntu seed, not an edubuntu seed, but for edubuntuish reasons.
<tseliot> infinity: can you check if mesa-lts-vivid is available in trusty-proposed on ppc64el, please?
<wgrant> tseliot: https://launchpad.net/ubuntu/trusty/ppc64el/libgl1-mesa-dri-lts-vivid?
<tseliot> wgrant: right, I saw that, but one of my contacts showed me that the specific package couldn't be found
<wgrant> tseliot: Which specific package?
<wgrant> mesa-lts-vivid isn't a binary package.
<tseliot> wgrant: sorry, it's libegl1-mesa-drivers-lts-vivid
<tseliot> or is it a transitional package?
<wgrant> tseliot: That doesn't exist on any architecture.
<wgrant> https://launchpadlibrarian.net/206323600/mesa-lts-vivid_10.5.2-0ubuntu1~trusty1_i386.changes
<tseliot> wgrant: the instructions here (still for lts-utopic though) mention this: apt-getÂ installÂ --install-recommendsÂ linux-generic-lts-utopicÂ xserver-xorg-lts-utopicÂ libgl1-mesa-glx-lts-utopicÂ libegl1-mesa-drivers-lts-utopic
<tseliot> replace utopic with vivid, and that should work, except libegl1-mesa-drivers-lts-vivid is not available
<tseliot> https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<wgrant> That sounds to me like the documentation needs to be updated.
<tseliot> tjaalton: ^^
<wgrant> libegl1-mesa-drivers is a transitional package.
<tseliot> right, let's see what Timo says about it
<tjaalton> desktop packages on ppc64el?
<tseliot> ah, so there aren't any then
<wgrant> Is the ppc64elness relevant?
<tjaalton> i mean, who'd need to install those :)
<tjaalton> no
<tjaalton> the data is old
<wgrant> I don't think there's anything arch-specific here, apart from the q
<tjaalton> thing is that vivid stack isn't in updates yet
<tseliot> -proposed is ok for now
<tjaalton> so just drop the packages that don't exist from the apt-get line
<tseliot> ok, thanks
<tjaalton> that page won't get updated before .3 is released I think
<tseliot> yes, and that's reasonable
<micahg> hi Laney, I saw you working on libproj transition, here's the story with that: postgis seems to be a false positive on the ben tracker (migration seems happy enough with it), zygrib has issues with qwt 6.1.1 even with 7.0, mapnik needs its own transition and I think that we should just copy back the older version since the transition seems involved (discussed this one with infinity, to be done only once the rest of the transition is ready), and
<micahg>  pyspatialite has its own mini transition as well, but that one might be easily solvable
<micahg> I saw the libwps got entangled and tried to dig a little into zygrib last night without success
<Laney> hi micahg
<micahg> hi, I'm only here for a few minutes
<Laney> I saw that postgis had a dep on libproj0
<Laney> didn't get much further than seeing that zygrib doesn't build
<micahg> orly?  that's very weird, I rebuilt it twice
<Laney> ya, look in the build log
<micahg> and confirmed in my local build logs (and I thought on LP as well) that it was libproj9
<Laney> do you have a path out of the jungle?
<Laney> I mainly started caring when it got involved with poppler and wps
<micahg> at this point, I was planning to fix spatialite, do the switcharoo with mapnik and probably remove the binaries for zygrib  unless I could find a fix soonish
<micahg> that should release everything
<Laney> micahg: I don't see the spatialite thing, seems happy enough to go in from what I can see
<micahg> tilelite?
<micahg> hrm
<micahg> oh, haha, that's part of mapnik transition
<micahg> yay, so maybe just remove binaries for zygrib + copy back the rebuild I did with the old mapnik
<ari-tczew> cyphermox: hi, have you got any plans for merge of network-manager in wily cycle?
<ari-tczew> mvo: I just needed to stole your merge of ust. It's needed by another packages in universe. bug 1468345
<ubottu> bug 1468345 in ust (Ubuntu) "Merge ust 2.6.2-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1468345
<mvo> ari-tczew: thanks!
<ari-tczew> You're welcome.
<cyphermox> ari-tczew: I'd like to, but I'm busy with other stuff... and I think awe and others might want us to wait and test that phone things aren't broken by merging 1.0 or later.
<ogra_> well, wily is already broken on the phone since the last upload it seems (not sure if NM is at fault, but i think that was the only non siloed upload yet)
<awe> cyphermox, I have a standup in a few minutes, but at some point we should discuss plans for moving to 1.x
<awe> ogra_, indeed... because we're not doing *any* testing on wily
<cyphermox> awe: let's do that tomorrow or something
<awe> cyphermox, ack
<ogra_> awe, well, uploads should be siloed and self-tested ...
<ogra_> but yeah, there is no further QA
<jibel> ogra_, awe it's true that there is very little manual QA during the release cycle of the devel release but there are integration test executed automatically when the package is uploaded. In the case of network-manager tests have been failing for nearly 2 weeks. Maybe it's the place to start https://jenkins.qa.ubuntu.com/view/Wily/view/AutoPkgTest/job/wily-adt-network-manager/
<ogra_> jibel, well, the last two NM uploads were simple dputs to the archive
<awe> so far... none of my NM changes for the phone have landed in wily
<ogra_> no idea if either of them have been tested at all ( i assume the first one hasnt because that was the initial sync fromm vivid)
<awe> cyphermox and I will work this out
<awe> but I've done *zero* testing on wily
<awe> to-date
<awe> the ofono changes land in both places from a single tree
<awe> NM, not so much
<ogra_> awe, well, and you shouldnt invest to much into it
<awe> I haven't
<ogra_> a simple self test and langind through a silo should be enough
<ogra_> i suspect neither happened for the two versions wily has
<awe> yet now there's an open bug about mobile-data being broken on wily, and some very bizarre results.  I suspect the device tarballs for mako aren't in very good shape
<ogra_> (actually the first one wasnt the sync i thought, it was a security fix in the ofono plugin)
<awe> also, it only looks like there's been one update
<awe> 4ubuntu16
<ogra_> 0.9.10.0-4ubuntu15.1
<ogra_> thats the first one i see on -changes
<ogra_> synced from vivid-security
<awe> ok
<cyphermox> Tomorrow we can make sure your nm code got landed in the packaging branch and do the testing in a silo, it's not complicated
<awe> 16 has the changes for routing which pmcgowan had reported broken?
<ogra_> bug 1436330
<ubottu> bug 1436330 in network-manager (Ubuntu Vivid) "Network Manager doesn't set metric for local networks any more, causing connection issues" [Critical,Fix committed] https://launchpad.net/bugs/1436330
<ogra_> thats the bug mentioned in the changelog
<cyphermox> Routing changes in wily don't break the phone, but they don't completely fix that bug either
<awe> no pmcgowan and mdeslaur both reported that the change didn't fix the problem for them on desktop
<Laney> Is that meant to be in wily?
<awe> so this probably shouldn't have landed in wily
<cyphermox> Right, that's what I'm saying
<Laney> because it is definitely not fixed if so :)
<awe> +1
<cyphermox> The fix isn't complete, but it does improve a bit
<Laney> I have to fettle when I want to go to/from wired
<cyphermox> Metric for network routes is correct now, but it's missing it for the default route
<awe> could you update the bug?
<Laney> awe: are you doing something with https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1445134 btw?
<ubottu> Ubuntu bug 1445134 in network-manager (Ubuntu) "Network manager never scanning for new access points" [High,Confirmed]
<Laney> I see the assignee ;)
<cyphermox> I'm pretty sure it already was updated
<awe> it was marked FixReleased, as an upload was done and it's in vivid-proposed, and then a bunch of folks reported it didn't fix the problem
<awe> so maybe you could add a note about what remains to be fixed?
<cyphermox> Well I won't be able to do that now, I'm not home, it's a national holiday so I'm away and using my phone
<awe> Laney, I will be looking at the scanning bug, but I have one more phone bug stacked up ahead of it.   That said, I may try and do some testing this week
<cyphermox> Awe: could you do the update?
<awe> Laney, what device are you seeing this on?
<Laney> my laptop, assuming it is the same bug and not another one with same symptoms
<Laney> I posted what happend in comment #4
<Laney> got to go now, sorry
<awe> Laney, ok.  I'm not sure if it's the same or not.  I'll try and take a look this week
<awe> Laney, np
<awe> cyphermox, I don't fully understand the bug and/or how it was patched.  So you're saying what remain is to backport additional logic from 1.x that sets the route metric for the default routes?
<Laney> if you can create an AP e.g with an android phone then it should be easy to recreate what happened to me
<Laney> see you
<awe> yea, I think I should be able to handle that Laney!  ;)-
<cyphermox> Awe: yes. Backport being an oversimplification of the work that needs to be done
<awe> sure, but the gist of it is that the metrics aren't being set for the default routes
<awe> I'll update it
<awe> are you still on vacation?
<cyphermox> No, but off today
<awe> k
<awe> I have to head out to grab some lunch now, but will update it when I get back
<cyphermox> If I was on vacation I wouldn't touch irc at all :-)
<awe> good
<awe> now enjoy the rest of your day off, and I'll catch up with you tomorrow
<cyphermox> So let's take care of this tomorrow we should be able to completely fix this all
<infinity> stgraber: *nudge*
<infinity> stgraber: Did you see my whining about ltsp vs main vs mate last night?
<stgraber> infinity: yeah, ltsp shouldn't depend on mate, let me take a look
<highvoltage> that's really odd
<ogra_> yeah
<infinity> stgraber: It's in your merge.
<infinity> -  gnome-session | x-session-manager | x-window-manager,
<infinity> +  mate-desktop-environment | gnome-session | x-session-manager | x-window-manager,
<infinity> (in two spots)
<infinity> stgraber: Wasn't sure if you wanted to drop that, or change the order, or just move ltsp out of main and stay closer in sync with Debian.
<stgraber> infinity: we have some magic in debian/control in Debian to spit out different recommends/depends on Ubuntu than on Debian, I'll bug vagrantc to get this resolved
<stgraber> infinity: that's just spamming c-m right, nothing more urgent than that? (otherwise I can just cowboy the fix in Ubuntu and then merge again whenever vagrantc fixes it in Debian)
<infinity> stgraber: Yeah, just a lot of spam.
<infinity> stgraber: Do you have any insight into the lxc autopkgtest regression?
<infinity> stgraber: Is that just a "we need to fix network access" thing, or something else?
<stgraber> infinity: my guess is that it's network related, yes
<infinity> cyphermox: How about you?  Any ideas on the network-manager adt regression?
<cyphermox> infinity: I think there has been a change in something on the system running the tests, if it's still that wpa error
<infinity> cyphermox: It's that, yes.
<infinity> cyphermox: So, if you're sure it's a testbed problem, I'll let the world skip it for now, and we can sort it with pitti.
<cyphermox> Yeah, feel free to ignore it I'd say.
<cyphermox> Nm hasn't exploded here, in any case
<infinity> cyphermox: Well, I assume you also don't run proposed.
<cyphermox> No, but I'm not sure what would break things that badly.
<cyphermox> Is there a new wpa in proposed?
<infinity> cyphermox: New wpa for security issues, but that came a day after the test started failing.
<infinity> cyphermox: The only obvious change I can see around when it started failing was a dnsmasq rebuild against a newer libnettle.
<infinity> cyphermox: If dnsmasq exploding could cause those sorts of errors, that could be it.  If not, then it's probably the testbed.
<cyphermox> That wouldn't break wifi
 * infinity nods.
<cyphermox> It seemed more like some hostapd issue with the hardware on the system, so maybe the kernel / hwsim module changed enough to break things, or there really is a wifi device on the test system now and things are confused
<cyphermox> infinity: I already have other things for NM in to-do for tomorrow, so I will debug this too
<infinity> stgraber: Okay, from looking at your tests and where this appears to time out, I concur it's probably network sadness.  Would be nice if your tests failed more verbosely, mind you. :)
<infinity> stgraber: When pitti moves all of this, I think I can get the right holes punched to let these tests work instead of neutering your testsuite, FWIW.
<stgraber> infinity: typically it's gpg getting stuck on no-network and it never seems to timeout for some reason
<infinity> stgraber: Might be worth a skeleton "test-host-port" function that you can reuse to bang every host/port combo you intend to abuse and die early if they're broken with a useful error.
<stgraber> indeed
<infinity> stgraber: Alright, I'm going to badtest lxc for now.  It's a lie, but it's the best lie I can come up with.
<infinity> cyphermox: Ditto for n-m.
<cyphermox> OK
<Unit193> cjwatson: Sorry to bother again, but got any estimate on the newer openssh entering Debian/Ubuntu?
<cjwatson> Unit193: you mean 6.8p1?
<Unit193> Yes sir.
<cjwatson> Unit193: I'm in the middle of the very very complicated rebase of the gssapi patch
<Unit193> Oi, sorry about that. :3
<cjwatson> Unit193: once that's done it should be straightforward, but I don't yet have a time estimate; I'm on holiday this weekend so it won't be then
<Unit193> cjwatson: Sure that's fine, and understandable on both accounts.
<Unit193> Thanks for the information!
#ubuntu-devel 2015-06-25
<pitti> Good morning
<pitti> cyphermox: not sure either yet what broke NM tests -- it fails consistently now, not just the "usual" slowness
<infinity> Riddell: Your oxygen-fonts transitional package seems to be missing the critical bit where it should depend on the new package. :P
<dholbach> good morning
<Unit193> mdeslaur: Hey, I think there's something up with the trusty and vivid openssl SRUs perhaps?  I have something compiled against it and it can not connect from Vivid or Trusty to Debian testing, but wily can.
<Unit193> mdeslaur: And indeed, the one built/run on Wily can't connect to Vivid nor trusty.
<cjwatson> Cool, a load of perl stuff builds that didn't before, now that we have the new sbuild
<Unit193> \o/
<mdeslaur> Unit193: what are you using to connect?
<Unit193> mdeslaur: cvs snapshot of gvpe.  As I said, wily/testing/unstable interoperate, and vivid/trusty do as well, but they do not cross.  Maybe debian #788511 related?
<ubottu> Debian bug 788511 in openssl "openssl: breaks ABI" [Serious,Fixed] http://bugs.debian.org/788511
<mdeslaur> Unit193: no, that bug isn't related
<mdeslaur> it was a 1.0.1b specific issue
<Unit193> Aha, well wild guess.  Oh well.
<mdeslaur> Unit193: wily and unstable both have sslv3 disabled
<mdeslaur> Unit193: perhaps file a bug with the exact steps to reproduce?
<Unit193> Hrm...
<Unit193> mdeslaur: I'll test later and pull openssl from wily and just make sure it is openssl.
<juliank> mvo, zyga: I forgot to tell you both that python-apt 0.9.3.12 is out now, so it's time to get a 0.9.3.12ubuntu1 into vivid. The git branch ubuntu/vivid is basically ready, it only needs a changelog. But maybe mvo wants his latest commit c74dc171bf03d27ffb77f150f144cac47cd3f8f5 cherry-picked too, I don't know
<juliank> I'll most likely cherry-pick that to debian/jessie for a 0.9.3.13 release sometime later
<cyphermox> good morning!
<seb128> hey cyphermox
<cyphermox> hey seb128
<LocutusOfBorg1> pitti, can I steal you the usb-modeswitch merge?
<LocutusOfBorg1> pitti, bug 1468833
<ubottu> bug 1468833 in usb-modeswitch (Ubuntu) "please merge usb-modeswitch from Debian" [Undecided,New] https://launchpad.net/bugs/1468833
<LocutusOfBorg1> I wrote the debdiff
<LocutusOfBorg1> (modulo last newline in the changelog, damn bug)
<niedbalski> bdmurray, ping
<bdmurray> niedbalski: hi
<niedbalski> bdmurray, re: 1462495, effectively the trusty patch includes another fix backported from utopic (check_haproxy_config), do you suggest me to split them into another SRU or remove from that patch?
<bdmurray> niedbalski: either remove it or update the changelog with information regarding the other patch and a bug reference for it.
<niedbalski> bdmurray, ack.
<bdmurray> arges: re bug 1463844 I don't see your upload in the queue
<ubottu> bug 1463844 in neutron (Ubuntu Trusty) "Missing logrotate configuration for vpn_agent and metering_agent" [Undecided,In progress] https://launchpad.net/bugs/1463844
<TJ-> Is there up-to-date documentation somewhere on what tools and procedures are used to create the bootable hybrid ISO images?
<arges> bdmurray: for bug 1463844
<ubottu> bug 1463844 in neutron (Ubuntu Trusty) "Missing logrotate configuration for vpn_agent and metering_agent" [Undecided,In progress] https://launchpad.net/bugs/1463844
<arges> bdmurray: that got superceeded by the next neutron upload (which contained this fix as well)
<Unit193> mdeslaur: Well yep, libssl1.0.0/now 1.0.2c-1ubuntu1 pulled into vivid causes it to be unable to connect to Trusty (and presumably able to connect to Debian again.)
<mdeslaur> Unit193: possibly because sslv3 is disabled
<Unit193> Hrm, OK..  Well trying that now.
<mdeslaur> I'm just speculating, that is one of the big changes
<mdeslaur> the other is that it now rejects dh < 768 bits
<mdeslaur> Unit193: you're using the same version of gvpe on both sides?
<Unit193> mdeslaur: Yes, exactly.  2.25+cvs20150424-0vanir1
<Unit193> With no-ssl3 I can still connect to trusty. :/
#ubuntu-devel 2015-06-26
<pitti> Good morning
<pitti> LocutusOfBorg1: please go ahead
<alkisg> tjaalton: good morning, may I ping you to put the SRU'ed x11-utils (LP: #1463663) to precise-updates? I've done the verification-done step. Thank you.
<ubottu> Launchpad bug 1463663 in x11-utils (Ubuntu) "[SRU] Enable setting property of type UTF8_STRING" [Medium,In progress] https://launchpad.net/bugs/1463663
<pitti> infinity: nice alpha-1 quote :)
<infinity> pitti: Wilde should be an inspiration to us all.
<pitti> infinity: I always pass good advice. It is the only thing to do with it. It is never of any use to oneself.
<tjaalton> alkisg: well, there's a rule not to ack pkgs to updates on friday.. :)
<alkisg> Guys, it's getting really hard to do an SRU when one has to spend 8 hours on it
<alkisg> And ping 4 persons
 * alkisg will just put that in the greek schools PPA and ignore all other LTSP users out there... :-/
<tjaalton> has it been 10 days in proposed
<tjaalton> ?
<alkisg> No, I don't think so, I haven't seen that requirement in the SRU wiki
<alkisg> Ah, it's mentioned in the other page, https://wiki.ubuntu.com/StableReleaseUpdates, about 7 days
<tjaalton> or was it seven
<tjaalton> right
<tjaalton> dunno where i got ten
<alkisg> tjaalton, could you please tell me when do I need to ping devs?
<alkisg> For getting the SRU approved, I've seen that if I don't ping anyone, it never gets approved,
<alkisg> is it also needed for the move to -updates?
<tjaalton> yes
<tjaalton> two manual steps
<alkisg> OK, thanks a lot, I'll do that after 4-5 days then. :)
<tjaalton> i've been on holidays past three fridays, but not today
<alkisg> We've spoken last friday when I was trying to get the SRU accepted :)
<tjaalton> so will process the upload queue if nothing else
<tjaalton> and it was midsummer here then
<tjaalton> public holiday
<alkisg> infinity did accept it 3 days ago
<tjaalton> nice
<alkisg> tjaalton: no problem at all, it appears that I didn't know the procedure well enough, that 2 pings are necessary, with 7 days interval...
<alkisg> Thanks again
<tjaalton> sure, no prob
<RAOF> alkisg: I *generally* migrate all the things which are valid candidates on http://people.canonical.com/~ubuntu-archive/pending-sru.html at the beginning of my Tues SRU block.
<RAOF> alkisg: That's for the -proposed â -updates transition.
<RAOF> alkisg: Something is a valid candidate if it's (a) >= 7 days old (or less, if you make a compelling case for its urgency and safety), (b) all the bugs associated with it are green (ie: in validation-done state), and (c) there are no jenkins failures associated with it.
<alkisg> RAOF, what about the "getting it to -proposed" part?
<RAOF> alkisg: That's the bit that it's good to ping for :)
<alkisg> Would I e.g. ping you for that, or let it stay there and rely that you'll process it when you have time for it?
<alkisg> Good to know, thank you :)
<RAOF> alkisg: Well, both. If there's something urgent it's nice to be pinged so I can prioritise.
<alkisg> No urgency here, I just didn't want it to remain there forgotten... it can wait until next Tue :)
<RAOF> But if it's not especially urgent you can just upload and we'll get to it eventually (how long varies depending on how many hours SRU members have been spending on the queue recently)
<RAOF> I *like* to keep the queues < 2 weeks, but we've not been keeping up with that recently.
<RAOF> (Partially because I've been missing some of my SRU days, as have others)
<alkisg> I don't think I have upload rights, so that's an additional ping for me there... fortunately the #ubuntu-x folks did that
<dholbach> good morning
<pitti> stgraber: hm, lxc-net started failing on wily, although lxc itself didn't change; but yesterday we got a new dnsmasq, might that be it?
<LocutusOfBorg1> pitti, the merge is ready on sponsors-queue :)
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<pitti> seb128: is https://code.launchpad.net/~mir-team/gtk/mir-release-0.14.0/+merge/263034 something you'd like to handle in the desktop team, or should I sponsor it?
<seb128> pitti, hey, we can handle it but feel free to do it if you want ... did they roll the mir update our yet?
<seb128> Laney, ^
<pitti> seb128: oh right, we still have 0.13.3, so nevermind
<seb128> pitti, piloting? ;-)
<pitti> seb128: yes
<seb128> pitti, enjoy! and happy friday ;-)
<pitti> seb128: and to you!
<Laney> pitti: attente should probably merge that upstream
<Laney> and hi too
<pitti> hey Laney, how are you?
<Laney> great!
<Laney> I'm trying to find out how to access Dell tech support ;-)
<pitti> Laney: urgh, your laptop broke?
<Laney> nah, I just  got asked to file an issue about this space key repeating bug
<Laney>               â that one
<Laney> bah, missed!
<ogra_> blame the space key (for moving the arrow to far)
<Laney> that is true, I was trying to count the right number of spaces to insert :)
<jamespage> pitti, hey - did you just sponsor an oslo.messaging SRU for trusty?
<pitti> jamespage: yes, I did
<jamespage> pitti, its stacked alongside one already in the -proposed unapproved queue
<pitti> I checked that the fix is in wily already and updated the bug
<pitti> jamespage: oh, argh; I'll reject mine then; I already unsub'ed sponsors
<pitti> whoever uploaded that, pretty please mentino this on the bug!
<jamespage> pitti, np - just noticed it in -release and checked
<jamespage> pitti, its not the same bug
<pitti> jamespage: oh, it's something else
<jamespage> pitti, https://bugs.launchpad.net/oslo.messaging/+bug/1448650
<ubottu> Ubuntu bug 1448650 in oslo.messaging (Ubuntu Vivid) "rpc.server do not consume messages after message acknowledge failure" [High,New]
<pitti> jamespage: ack, I'll ask Jorge to merge
<jamespage> pitti, +1
<pitti> jamespage: done
<TJ-> I'm unclear whether this requires an SRU or a Backport request, could someone advise? bug #1468938
<ubottu> bug 1468938 in miniupnpd (Ubuntu) "postinst script writes garbage to /etc/default/miniupnpd" [High,Triaged] https://launchpad.net/bugs/1468938
<rbasak> TJ-: an SRU would be suitable for that I think.
<rbasak> TJ-: it's a direct maintainer script bug, no question.
<rbasak> TJ-: task for Trusty approved.
<TJ-> rbasak: Thanks, I thought so and have proceeded so far on that basis but the SRU Wiki  guidance made me wonder.
<pitti> yes, destroying config files is absolutely a bug/SRU matter
<TJ-> rbasak: Do I simply subscribe the SRU team to this? I have no upload rights
<rbasak> TJ-: follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure step by step. It accomodates users with no upload rights - attach debdiffs to the bug at the appropriate step, and then subscribe ~ubuntu-sponsors to the bug.
<rbasak> TJ-: if it also needs fixing in the development release, then you can just attach two debdiffs and ask for sponsorship for both at the same time.
<rbasak> The documented procedure is unclear about this :(
<TJ-> rbasak: Thats what I've been doing ... but I'm not sure a debdiff is appropriate since in this case it needs a backport
<rbasak> TJ-: why does it need a backport?
<TJ-> rbasak: The fix has been in from 14.10 onwards
<rbasak> TJ-: "The fix has been in from 14.10 onwards" OK so comment to that effect in the bug and mark the main task Fix Released.
<rbasak> TJ-: then mark the Trusty task Triaged if you feel appropriate.
<TJ-> rbasak: Yes, I've already marked it Triaged and in the Description it says "It turns out these were fixed in Debian and are available in 14.10, 15.04 and 15.10. A backport to Trusty would solve this and several other issues."
<TJ-> rbasak: This is why I'm sure what to do at this point ... simply subscribe the SRU team, or what?
<rbasak> TJ-: an SRU is appropriate here, but how the SRU should work is still an open question. Why a backport, over cherry-pick of the fix or the patch you attached?
<TJ-> rbasak: Well, mainly that the updated package contains "Fixes multiple vulnerabilities (Closes: #772644)."
<rbasak> TJ-: to be clear, an SRU for *this particular issue* is appropriate here. "Several other issues" is far too vague to SRU.
<rbasak> TJ-: OK, so if we want to fix those in the SRU as well, then they need to be documented for the SRU team to review in a bug somewhere.
<TJ-> rbasak: OK ... I'll dig a little more
<rbasak> TJ-: they look pretty well documented in the Debian bug actually.
<rbasak> TJ-: if that's the complete set of patches applied, they just need documenting for the SRU team and would be suitable I think.
<rbasak> TJ-: also, as they look to be security related, you could probably get all of these fixes through the security update process instead.
<TJ-> rbasak: Yes, the security issues look like we should have them in an LTS for sure
<TJ-> rbasak: Right ... so.... prefer a Security update over SRU to get all the fixes in?
<rbasak> I would ask the security team. I think they'd be OK with fixing the postinst at the same time as the bundle of security fixes.
<rbasak> As long as you can give them a debdiff to upload
<rbasak> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
<rbasak> Hmm. Although some of the fixes aren't security fixes.
<rbasak> See what they say, anyway.
<TJ-> The postinst is arguably a Denial of Service :)
<TJ-> rbasak: Thanks alot; I'm writing up the description then I'll ask the security team to look at it
<rbasak> TJ-: no problem. The main thing to do is to create the actual thing you want sponsored (ie. source packages - debdiffs are the easiest way to get these to sponsors)
<TJ-> rbasak: I usually do those or bzr branches depending on where the source lives, but the potential of a  backport to solve it doesn't make the procedure clear in the guidelines
<rbasak> TJ-: "If all of the changes are appropriate for an SRU by the criteria above, then it is acceptable (and usually easier) to just upload the complete new upstream microrelease instead of backporting the individual patches."
<rbasak> TJ-: from a policy perspective, there is no difference. A backport is fine provided that all the criteria are met for each part of the diff.
<rbasak> TJ-: but that immediately disqualifies the backport if any change appears (between the current release version and the proposed backport version) that does not meet the appropriate (SRU or security) criteria.
<rbasak> (unless the package has an exception; I don't believe this package does)
<TJ-> rbasak: OK, my misuse of terms.... by backport I was meaning if the source package to be used to fix the issue is exactly what is in a later release, should a copy of that later release be added as a debdiff or should someone with upload rights be able to directly import the package from the fixed release
<rbasak> TJ-: the debian/changelog file will still need manipulating to add a changelog entry and use a suitable version number for the SRU.
<rbasak> TJ-: for sponsorship I would still provide a debdiff, but perhaps against the release you're backporting instead. Then the only thing in the debdiff would be the debian/changelog change, but that's still useful to sponsors to understand exactly what you want.
<rbasak> TJ-: of course if you provide such a debdiff you'd probably want to make it clear which release and version your debdiff was generated against (though that could be inferred from the debian/changelog change)
<rbasak> TJ-: does that help?
<rbasak> TJ-: I guess the reason this isn't really documented is that in general sponsors don't particularly care _how_ you provide the changes that you want.
<TJ-> rbasak: Yes, and I guess those familiar with the processes do them instinctively whilst those of us outside the process just go round in circles on the Wiki guides :)
<rbasak> TJ-: I wish it were simpler :-/
<TJ-> rbasak: I'm going to write it up as best I can and ask the security team to look at it; the Debian updates don't identify the CVEs they fix and it looks like there may be an additional CVE not covered too :)
<rbasak> TJ-: thank you for your efforts!
<TJ-> Is there up-to-date documentation somewhere on what tools and procedures are used to create the bootable hybrid ISO images? I'm working on a universal GRUB2-bootable image that'll work on x86/amd64, BIOS and UEFI, with raw block and ISO9660/El Torito, supporting multiple sector sizes (512/2048/4096) and want to design it to work with the current tooling
 * mdeslaur hugs rbasak for fixing indefinite grub timeout
<tjaalton> pitti: hey, can I persuade you to review xserver-xorg-video-intel for utopic (and matching -lts-utopic for trusty) from the sru queue?
<attente> Laney: we already have a similar patch upstream: https://git.gnome.org/browse/gtk+/commit/?id=9800d83a721fd21b34df6dd36684d3e0e2a9fd7b
<Laney> attente: want to tell the MP / $person_who_filed_it?
<pitti> tjaalton: I haven't been in the SRU team for a few years, but I can have a look
<tjaalton> pitti: right, I know but you're on pilot duty today so figured I'd ask :)
<tjaalton> my sru duty is on fridays, and noticed that this upload was still missing because of a previous sru taking a long time..
<tjaalton> already acked grub2 and libvirt :)
<pitti> tjaalton: are these fixed in wily?
<tjaalton> and vivid, which have 2.99.917
 * pitti adds an x-v-i task to bug 1443345
<ubottu> bug 1443345 in HWE Next "[Dell Insprion 3646] Double cursor appeared when rotating the display back to normal [8086:0f31]" [Critical,In progress] https://launchpad.net/bugs/1443345
<tjaalton> hmm didn't check that one
<tjaalton> I'll fix that bug
<pitti> I updated the tasks
<tjaalton> ah, thanks
<pitti> tjaalton: yes, it's fixed, just checked
<pitti> tjaalton: done
<tjaalton> pitti: much appreciated, thanks
<rbasak> infinity: any chance of SRU review for docker.io please?
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs pitti
 * pitti hugs dholbach :)
<beuno> hey hey. Stop that.
 * ogra_ hugs beuno, dholbach and pitti 
<pitti> group hug!
<ogra_> !
 * pitti hugs beuno and ogra_
 * dholbach hugs you all
<dholbach> can you tell it's Friday? :)
 * beuno relents and sinks into the hug
<TJ-> I hope everyone's showered!
<pitti> TJ-: sure! once for Easter, once for christmas :)
<ogra_> and we hug on fridays to keep some memory of each other over the weekend :)
 * TJ- grins... I only said that since I suddenly realise I've not showered in a few days ... its a farmer thing I'm afraid :)
<hallyn_> pitti: hey - does a systemd service saying it "Wants" another service mean tha tit will wait until the other service starts, or finishes?
<hallyn_> mbiebl: hey, ^ do you know the answer? :)  the jobs are both Type=oneshot
<Laney> hallyn_: Don't you need Before= or After= for that?
<hallyn_> Laney: dunno, that's why i'm asking.  right now lxc.service has Wants=lxc-net, and users are reporting races;  if it needs to be After that's a trivial fix, but i want to make sure it makes sense
<Laney> hallyn_: Wants= without any ordering relation means they start up at the same time, let me find the reference
<hallyn_> Laney: makes sense i guess
<Laney> hallyn_: http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires= (same for Wants=)
<hallyn_> thanks Laney
<hallyn_> Laney: hm, from that it's still not clear to me that 'After=' really is equivalent to upstart's "start on stopped B"
<hallyn_> oh,
<hallyn_> so lxc-net.service should really do a ExecPreStart or something
<tr3y> Hello, I'm having trouble with Nautilus and Nemo on Ubuntu 14.04. The Ubuntu channel told me I might have success asking here. I changed the .desktop files to execute these programs with "Exec=gksudo -k -u root nautilus" (and 'nemo' for nemo) and now when they open, there's no top menu (E.G "Edit", "View", etc). Anyone know what's causing this?
<arges> cyphermox: hey are you merging multipath tools, niedbalski has a fix for it and I want to make sure his patch makes it in
<arges> cyphermox: bug 1469143 fwiw
<ubottu> bug 1469143 in multipath-tools (Ubuntu) "kpartx -d fails with image paths longer than 63 characters" [Undecided,In progress] https://launchpad.net/bugs/1469143
<cyphermox> arges: yeah, I'm still working on merging multipath-tools
<cyphermox> I have a few things to fix before it will work in the installer.
<cyphermox> (including that extra module for multipath-modules) :)
<arges> niedbalski: that ok to wait until cyphermox merges 0.5.0 then push your fix (unless its already in that release)
<niedbalski> arges, sure, I can wait for 0.5.0 and put the patch on top of it.
<arges> cool
<niedbalski> cyphermox, arges there is any bug tracking the 0.5.0 merge?
<cyphermox> niedbalski: won't that patch blow up if there is a collision in path names?
<cyphermox> niedbalski: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1455482
<ubottu> Ubuntu bug 1455482 in multipath-tools (Ubuntu) "Multipath: upgrade multipath-tools to upstream" [High,In progress]
<niedbalski> cyphermox, thanks
<niedbalski> cyphermox, I didn't get your first question
#ubuntu-devel 2015-06-27
<pitti> hallyn: what Laney said -- Wants= is just "start that unit"; you need After= for ordering
<pitti> hallyn: half of "start on stopped B" is A saying Conflicts=B.service, but that doesn't trigger the starting yet
<pitti> hallyn: there's OnFailure= if that's your use case
#ubuntu-devel 2015-06-28
<hallyn> pitti: thanks.  no my use case isn't onfailure, just need to fix lxc vs lxc-net.
<hallyn> pitti: switching to ExecPreStart or whatever in lxc-net seems like the way to go
<LocutusOfBorg1> xnox, hi, quick question, do you know why ubuntu-dev-tools doesnt depend at runtime to pbuilder?
<LocutusOfBorg1> I mean, I can't pbuilder-dist sid login without pbuilder, and the former is part of ubuntu-dev-tools
<ScottK> LocutusOfBorg1: udt doesn't depend on every single the every script needs.  It'd be very heavy to install otherwise. Devscripts is similar in this regard.
<LocutusOfBorg1> ScottK, I was wondering that was the reason, of course pbuilder-dist armhf login needs qemu and it is heavy
<LocutusOfBorg1> I was wondering how much of ubuntu-dev-tools can run without pbuilder, and I guess the answer is "a lot"
<LocutusOfBorg1> well, I won't ask to split anything :P thanks!
<zequence> I'm still very new to uploading packages. I can't seem to find any other information on the subject, than here http://packaging.ubuntu.com/html/udd-uploading.html.
<zequence> I'm about to upload lp:ubuntustudio-menu, but not sure which steps to take
<zequence> I'm not supposed to upload the bzr branch to ubuntu:ubuntustudio-menu, right?
<zequence> In the log for ubuntu:ubuntustudio-menu, it says committer is Package Import Robot
<zequence> So, I'm guessing it gets updated from a package that was uploaded to the archive with dput?
<zequence> Ok, I uploded to the archive, with: dput ../<changes_file>.
<Laney> zequence: https://wiki.ubuntu.com/MOTU/New might be useful
<zequence> Laney: Thanks!
<Laney> please edit it with any missing knowledge that you would have liked to know
<micahg> LocutusOfBorg1: regarding the virtualbox backport, did you intend to test a backport from wily to trusty, utopic, and vivid?
<micahg> I'm just trying to clean up some of the backports bugs and there are at least 2 open for virtualbox at present
<infinity> LocutusOfBorg1: Given that the majority of ubuntu-dev-tools users don't even use pbuilder (and will, generally, actively recommend against it), I'd be pretty miffed if it depended on it. :P
#ubuntu-devel 2016-06-27
<jbicha> Please consider ignoring autopkgtest failures for vagrant: https://bugs.debian.org/828706
<ubottu> Debian bug 828706 in src:vagrant "vagrant: autopkgtest fails if dependency has newer upstream version" [Normal,Open]
<cpaelzer> good morning
<pitti> Good morning
<pitti> slangasek: it is now; I guess still bug 1588566
<ubottu> bug 1588566 in Auto Package Testing "autopkgtest results go missing for a long time after the test completes" [Undecided,In progress] https://launchpad.net/bugs/1588566
<pitti> slangasek: although the runs take much shorter than the 1.5 hours now after the fs reorg, they still take way too long in some cases, not sure why
<pitti> i. e. this bug is still valid
<pitti> xnox, infinity: aupkg01 (10.100.0.12) is AWOL again, help please?
<pitti> jbicha: retrying gmp-ecm/armhf won't bring much: http://autopkgtest.ubuntu.com/packages/g/gmp-ecm/yakkety/armhf/
<pitti> jbicha: 7.0 is really broken on armhf
<pitti> (and it takes effing long too, so please don't retry too often)
<jbicha> pitti: sorry, I was just clicking buttons :(
<pitti> jbicha: no worries, just mentioning that this is really broken
<pitti> if it holds up stuff, we need to override
<pitti> but this looks like a genuine regression on 32 bit, so it should get at least a bug report
<pitti> jbicha: welcome back, by the way! how are you?
<jbicha> pitti: I'm doing pretty good, thanks :)
<pitti> cjwatson, wgrant: we didn't get an export yesterday on https://translations.launchpad.net/ubuntu/xenial/+language-packs; can you please kick the cron job manually?
<smb> Morning, I think someone needs to upload the signed grub2 updates to Trusty (proposed) still. Getting removal hints again
<pitti> jbicha: FYI, I filed debian bug 828717 about this
<ubottu> Debian bug 828717 in gmp-ecm "gmp-ecm: 7.0 regresses on 32 bit platforms" [Important,Open] http://bugs.debian.org/828717
<doko> cjwatson, https://launchpad.net/ubuntu/+source/gmp-gcc4/2:6.1.0+dfsg-2ubuntu4 causes gcc-4.7 to fail to build, because libmpc-dev and libmpfr-dev become uninstallable (depending on libgmp-dev). But I assume restoring the provides isn't an option either
<doko> https://launchpadlibrarian.net/268126150/buildlog_ubuntu-xenial-amd64.gcc-4.7_4.7.4-3ubuntu12_BUILDING.txt.gz
<rbasak> teward: thanks
<cjwatson> doko: I don't think restoring the Provides is a good option, no.  The sensible choices seem to be either making libmpc-dev and libmpfr-dev depend on libgmp-dev | libgmpv4-dev, or creating v4 versions of those two packages; I don't know which is better
<cjwatson> pitti: I can ask for it, but I'd prefer to wait until the vivid export that's due to start in 45 minutes has finished (which will take a few hours).
<pitti> cjwatson: hm, ok (the vivid one is not particularly urgent, but we need the xenial one for 16.04.1)
<pitti> but I guess building them tomorrow should be fine
<cjwatson> pitti: It could probably be ready by last thing today?
<pitti> cjwatson: right; if it is, I'll start the build tonight and do the testing/upload tomorrow
<xnox> infinity, sorry =)
<xnox> http://people.canonical.com/~ubuntu-archive/pending-sru.html seems to be last generated during EU referendum, and hasn't been since?
<xnox> pitti, could you please take a look as to why it is stuck? (if you have access to it)
<pitti> xnox: I don't -- I only have ssh, and have no privs to use the console method (remember, we tried a few weeks ago)
<pitti> xnox: I enabled crashdump on these machines, maybe there is one now
<xnox> pitti, i'm not talking about s390x =)
<pitti> xnox: oh sorry, I interpreted that as a pong to the above "aupkg01 is broken", sorry
<xnox> pitti, i'm talking about pending-sru generated by sru-report being stuck =0, should be on the same machine as the rest of the archive reports? =)
<pitti> xnox: yep, looking
<cjwatson> xnox: I've killed the current stuck run.
<cjwatson> pitti: ^-
<pitti> ah, thansk
<cjwatson> Probably got stuck during the GS2 power outage.
<cpaelzer> is it "normal" that once I added a remote bug tracker like from ntp in this case bug 1567540 - I "loose" the ability to nominate for Series?
<ubottu> bug 1567540 in ntp (Ubuntu) "ntpd crashed with SIGABRT (was: ntp crashes everytime the network goes up or down.)" [High,Triaged] https://launchpad.net/bugs/1567540
<cpaelzer> if so why - and will that state be back to being able to nominate once it fetched the remote status?
<rbasak> cpaelzer: swap debian for ubuntu in the URL.
<rbasak> cpaelzer: it's a Launchpad UI issue.
<cpaelzer> rbasak: thanks ... but ... I see no debian in my URL
<cpaelzer> rbasak: the remote bug tracker is to ntp and the "browser" utl is https://bugs.launchpad.net/ntp/+bug/1567540
<ubottu> Launchpad bug 1567540 in ntp (Ubuntu) "ntpd crashed with SIGABRT (was: ntp crashes everytime the network goes up or down.)" [High,Triaged]
<cpaelzer> rbasak: where do I need to change it?
<rbasak> Oh, sorry.
<rbasak> Try: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1567540
<rbasak> Basically the URL you follow has to be part of the Ubuntu project for you to see the Nominate stuff. Note that the bar that is yellow changes.
<cpaelzer> rbasak: dirty dark secrets - that did it - thanks
<xnox> ..
<xnox> how does one launch lxc armhf container on amd64?
<xnox> using lxd2.0
<rbasak> tjaalton: any objection to syncing cobbler in bug 1593434? You TIL.
<ubottu> bug 1593434 in cobbler (Ubuntu) "Sync cobbler 2.6.6+dfsg1-12 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593434
<tjaalton> rbasak: nope
<rbasak> tjaalton: great, thanks.
<pitti> tyhicks: hey, how are you?
<pitti> tyhicks: I just saw https://tracker.debian.org/news/777985 -- most of Debian's changes towards our package sound sensible for us too, so merging should hopefully have a very small delta now?
 * pitti is particularly interested in providing a native systemd units, as rcS init.d scripts are still problematic and we have a large patch for that downstream
<tyhicks> pitti: hi - doing pretty well
<tyhicks> pitti: those do sound like reasonable changes - we'll have a look at syncing
<tyhicks> pitti: we work with intrigeri quite a bit in #apparmor so I'll ask him if I see anything odd
<pitti> tyhicks: oh, nice
<bdmurray> tjaalton: Could you look at fixing bug 1500751 in Trusty?
<ubottu> bug 1500751 in initramfs-tools (Ubuntu Trusty) "Cryptsetup Keyboard not working on Xubuntu 3.19.0-30" [High,Triaged] https://launchpad.net/bugs/1500751
<tjaalton> apw: ^ can you cherry-pick that for trusty too?
<apw> tjaalton, likely :)
<tjaalton> good :)
<nacc> Logan: thanks! jbicha created a tag ('php7') for all those kind of bugs, I'll check on it
<smb> tjaalton, though you did not ask whether apw *will* do so :-P
<apw> smb, don't give away my trade secrets
<smb> apw, oops ... sorry
<nacc> mwhudson_: re: LP: #1569609, any ideas of how to make it get some more traction? was just reviewing LP: #1596578 and I don't think I can easily (without learning all about PHP internals) backport the change needed.
<ubottu> Launchpad bug 1569609 in php7.0 (Ubuntu Xenial) "[SRU] microrelease exception for src:php7.0" [Wishlist,New] https://launchpad.net/bugs/1569609
<ubottu> Launchpad bug 1596578 in php7.0 (Ubuntu) "zabbix issues with current php version" [Undecided,New] https://launchpad.net/bugs/1596578
<nacc> rbasak: re: LP: #1593434, would it make sense to SRU or (possibly instead -backport) it to 16.04? AIUI, due to at least LP: #1570891, the version in 16.04 doesn't currently work. I'm an upstream developer for cobbler, and I'd much rather see 16.04 have a more current release.
<ubottu> Launchpad bug 1593434 in cobbler (Ubuntu) "Sync cobbler 2.6.6+dfsg1-12 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/1593434
<ubottu> Launchpad bug 1570891 in cobbler (Ubuntu) "cobbler uses old cobblerd URL resulting in URLError" [Medium,Confirmed] https://launchpad.net/bugs/1570891
<jbicha> nacc: "upgrade of Cobbler from 2.4.1 -> 2.6.x is not supported upstream"
<jbicha> how bad is that going to be for those already using cobbler in Ubuntu?
<nacc> jbicha: i'm going to figure that out now :)
<nacc> jbicha: i've never deployed 2.4.x
<nacc> jbicha: and no one using cobbler these days (that i've dealt with) has either :/
<nacc> jbicha: i would argue this is similar to php5 -> php7, and other major transitions (albeit in a universe package), where we really can't migrate the configuration
<jbicha> I haven't used cobbler at all, but I'm thinking from an sru, it might be nice to know what happens from 14.04 LTS to 16.04 LTS
<nacc> agreed, i wouldn't suggest it formally until i figured that out
<nacc> jbicha: hence why i also wondered if -backports made some sense, since there might not be an upgrade path and backports is op-tin
<jbicha> oh, the upgrade from 14.04 to 16.04 needs manual work for php?
<nacc> jbicha: if you have local configuration, i believe it doesn't apply, possibly (variables got renamed, etc)
<jbicha> well since it's also "server" related I guess that's good precedence, if it's at least release noted
<nacc> jbicha: the language itself is BC, but i think the configuration has moved around, etc.
<nacc> well, mostly BC :)
<nacc> jbicha: yeah, i plan on adding a cobbler blurb yakkety release notes
<nacc> Logan: ok, there are definitely issues with zabbix, but i got them all fixed andwill file an SRU now
<nacc> i was able to successfully deply the version in xenial in a container and bring up the web ui
<rbasak> nacc: backports> yes, definitely. SRU> if it's completely broken in Xenial. Otherwise depends on severity I guess.
<rbasak> nacc: the amount of effort required to do it right may be too much though. I guess you'll find out.
<pitti> wgrant: I seem to have lost the combobox on https://translations.launchpad.net/ubuntu/xenial/+language-packs for marking a new full export as base for future diffs
<nacc> rbasak: ack, thanks!
<mwhudson_> nacc: er did you really mean to ping me about that?
<nacc> mwhudson: you touched it last, in terms of the bug, if you had any ideas, i'd appreciate it; probably not directly yours to figure out though
<mwhudson> nacc: oh heh
<mwhudson> nacc: my understading is that it still requires someone on the SRU team to decide
<nacc> mwhudson: ack, that's my understanding too; and given it's a larger request, I imagine it will take time. I'm just a bit worried because I'm not sure how to SRU more involved fixes at this point, given our code-base.
<mwhudson> nacc: uploading something is probably a good way to encourage that to happen though
<mwhudson> nacc: do you have/can you make a package for me to sponsor?
<nacc> mwhudson: yeah, i can do that shortly, give me a little bit (i'll update the bug)
<mwhudson> nacc: cool
<nacc> mwhudson: thanks for that reminder :)
 * mwhudson subscribes to the bug, oops
<nacc> mwhudson: i've got a couple php7.0 SRU bugs pending too; would the right thing to do be to submit two debdiffs (one for the two known bugs w/ fixes and then another after that pulling in the new upstream?)
<Grorco> what is the name of the software and updates package?
<mwhudson> nacc: if the bugfixes are in the new upstream release, then aiui, no, just mention all the bugs in the changelog
<Grorco> nevermind I figured it out
<nacc> mwhudson: they aren't (packaging issues) -- i could also fix them in my upstream release update, but i wasn't sure if that would be appropriate or not.
<mwhudson> nacc: ah. still, i think fixing it all at once /probably/ makes sense
<mwhudson> nacc: just write a clear changelog entry
<nacc> mwhudson: yep, i am happy to do it that way (and means only one upload). Will do!
<nacc> mwhudson: thanks for the input!
<mwhudson> nacc: i'm not an expert in predicting the SRU team's desires yet though :-)
<Logan> nacc: cool, I approved your nomination for Xenial
<nacc> Logan: thanks!
<mwhudson> ubuntu@yakkety:~$ du -h `which golang-petname`
<mwhudson> 16K	/usr/bin/golang-petname
<mwhudson> \o/
<sarnold> !!
<sarnold> nice :)
<mwhudson> now i just need to beat go-systemd's upstream heads together to get rid of a dependency loop...
<mwhudson> and MIR golang-github-coreos-pkg-dev (related to above)
<ret2libc> hi. https://www.youtube.com/watch?v=CgjdUkgPiZo at 36:39 he says that the appstream generator will be "in ubuntu, for ubuntu" if i hear it correctly. why not making it available for every distro?
<Grorco> Hello I'm new to this and I'm trying to us bazaar to get a branch of software-properties-gtk and it says it doesn't exist
<Grorco> bzr branch ubuntu:software-properties-gtk software-properties-gtk.dev is what I'm using am I doing something wrong?
<jbicha> bzr branch lp:software-properties
<jbicha> or apt source software-properties
<jbicha> the ubuntu: branches are usually out-of-date these days
<nacc> mwhudson: just an fyi, finally finished refershing the php7.0 patches, build and testing it now locally
<nacc> mwhudson: also filed LP: #1596735 so xenial's version doesn't get ahead of yakkety's
<ubottu> Launchpad bug 1596735 in php7.0 (Ubuntu) "Please merge with php7.0 7.0.8-2 from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/1596735
<mwhudson> nacc: looking
<nacc> mwhudson: our delta is pretty trivial, i've subscribed -sponsors already, so only if you have time
<nacc> Logan: had a quick q for you on zabbix. I noticed something kind of funky just now, in that if you install zabbix-server-mysql (or i think zabbix-proxy-mysql) and zabbix-frontend-php, you don't necessarily get php-mysql installed, even though it's a dep of the frotend package. That's because there are three alternatives and it just picks php-pgsql. But the frontend configuration wizard won't even show
<nacc> MySQL as an option for the backing database w/o php-mysql installed. Is there any prior art for handling if pkg A is to be installed and pkg B is installed, then pkg C should be used for an alternative-dep?
#ubuntu-devel 2016-06-28
<rbasak> nacc: it sounds like zabbix-frontend-php shouldn't depend on a DB at all. Can't it leave that for zabbix-server-* to pull in?
<rbasak> Oh, that maybe won't fully work.
<mwhudson> nacc: will leave it for sponsors then
<nacc> rbasak: it doesn't depend itself
<nacc> rbasak: the issue is that to use a db with zabbix, you'd install either zabbix-server-<db> or zabbix-proxy-<db>, i think
<nacc> that determines, in turn what php-<db> package should be installed
<nacc> but afaict, there's no way to communicate those kind of interdependencies
<nacc> so you'll just get pgsql not knowing you need to `apt install zabbix-frontend-php php-mysql` if you previously `apt install zabbix-server-mysql`
<nacc> rbasak: it's not a serious issue, per se, but i was just curious if there were ways to fix that, as for instance if i had installed zabbix-server-mysql first, then installing php-pgsql won't help me at all with the web ui :)
<nacc> mwhudson: woo, tests passed, uploading debdiff
<mwhudson> nacc: debdiff? isn't there a new orig?
<wgrant> pitti: Huh, are you sure you're logged in correctly? That option is still there, and nothing related has changed in years.
<nacc> mwhudson: yeah, sorry, not a debdiff, i just uploaded a new debian tarball
<nacc> mwhudson: and new orig comes from `uscan`
<mwhudson> nacc: i think the version number should perhaps be 7.0.8-0ubuntu0.16.04 ?
<mwhudson> er with another .1 on the end
<nacc> mwhudson: i wasn't sure how that worked with MREs. You are right, though, that probably matches better (my undersatnding for the above strings was specifically for backporting a version from Y to X, for instance). In this case, the packaging is the same but we're updating the orig tarball
<nacc> i'll review the security team page again, though, please put an update in the bug, if you don't mind?
<mwhudson> well i'm fairly new at this too :)
<mwhudson> nacc: uploaded https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
<nacc> mwhudson: thank you very much!
<nacc> rbasak: LP: #1569377 for reference
<ubottu> Launchpad bug 1569377 in zabbix (Ubuntu) "unable to select mysql server in zabbix-frontend-php" [Undecided,Confirmed] https://launchpad.net/bugs/1569377
<mwhudson> nacc: i guess it's worth mentioning https://launchpad.net/bugs/1596735 on the sru bug too?
<ubottu> Launchpad bug 1596735 in php7.0 (Ubuntu) "Please merge with php7.0 7.0.8-2 from Debian unstable" [Wishlist,New]
<mwhudson> er i guess i can do that
<nacc> mwhudson: thanks, i can do it if you're otherwise occupied, i should have done that already, my fault
<mwhudson> nacc: done
<nacc> mwhudson: thanks again!
<Logan> nacc: yeah, apt unfortunately doesn't support variants of packages
<Logan> or at least that kind of dependency handling, AFAIK
<Logan> nacc: well, I guess you could do a debconf kinda thing after install of the frontend to choose which PHP DB connection to install
<Logan> but that's gross
<mwhudson> dbconfig-common!
<mwhudson> and yes, it's horrible
<cpaelzer> good morning
<smb> cyphermox, uh erm, there is still something wrong with grub-efi-amd64-signed in trusty. I think it is that it still depends on the wrong version: apt-cache info: grub-efi-amd64-signed(1.34.11+2.02~beta2-9ubuntu1.8) depends on grub-efi-amd64 (= 2.02~beta2-9ubuntu1.8) but grub-efi-amd64 in trusty-proposed is 2.02~beta2-9ubuntu1.9
<smb> ^ that is all with proposed enabled
<pitti> Good morning
<pitti> wgrant: I just tried to log out and back in, same result -- no boxes
<pitti> wgrant: I'd like to mark yesterday's as current as I uploaded it
<wgrant> pitti: What is on the page for you?
<pitti> wgrant: http://picpaste.com/p-rA9K20PS.png
<wgrant> pitti: ah, I think it's because there's no driver set on xenial (or yakkety)
<wgrant> The other series are ~ubuntu-release, which will give you launchpad.TranslationsAdmin. As it stands you only have launchpad.LanguagePacksAdmin on xenial.
<pitti> wgrant: that sounds like a bug, no? that's clearly langpack admin, not release engineering
<wgrant> pitti: It is probably a bug, but it's a very deliberate one. And regardless, much faster and easier to fix by fixing the series config.
<pitti> https://launchpad.net/ubuntu/wily/ keeps timing out, but https://launchpad.net/ubuntu/xenial/ has "Drivers: Ubuntu drivers"
<pitti> oh, you mean the missing "Release manager:" I suppose
<pitti> ah, /wily loads now, that has ~ubuntu-release indeed
<pitti> slangasek: can you please set the release manager to ~ubuntu-release on https://launchpad.net/ubuntu/xenial/ and https://launchpad.net/ubuntu/yakkety/ ?
 * pitti supposes that this needs ~techboard powers
<wgrant> I believe that is correct.
<caribou> pitti: last week, you rejected the SRU for LP: #1529815 since LP: #1568485 was v-failed but bdmurray reverted it back to v-needed
<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
<ubottu> Launchpad bug 1568485 in isc-dhcp (Ubuntu Wily) "kernel: audit: type=1400 audit(1460259033.648:34): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13" [Medium,Confirmed] https://launchpad.net/bugs/1568485
<pitti> caribou: ... and?
<caribou> pitti: looks like it was not a regression so I don't understand why I'd need to remove the patch
<pitti> caribou: right, in this case the ", or..." part would apply :)
<caribou> pitti: I don't mind waiting until the first one go through
<pitti> caribou: yeah, it's blocked by verification of this bug either way, so the fastest way forward would be to verify this
<caribou> pitti: true, I'll look that up
<pitti> alternatively you can upload a new one with -V that includes the previous update, then the other fixes can be tested in parallel
<pitti> (but that bug still needs to be verified of course)
<caribou> k
<caribou> pitti: wait I'm not sure I'm following you : what you mean by -V ?
<pitti> caribou: dpkg-buildpackage's (or gbp buildpackage etc.) -V4.3.3-5ubuntu12 so that the previous changelog (current version in -proposed) is included into the .changes; same as you do for merges
<caribou> pitti: ah ok got it
<cjwatson> pitti: that's -v
<pitti> err yes, that, sorry
<apw> cyphermox, grub2-signed> of course uploading grub2-signed did not help, as the custom upload in question is broken and comes from grub2
<apw> cyphermox, so we likley need to upload grub2, or stop grub2-signed using current when it knows which version it is wanting
<caribou> pitti: Is foundation taking care of the desktop installer ?
<pitti> caribou: yes, mostly cyphermox
<caribou> pitti: thought so
<caribou> I think I found a bug that got me to reinstall my laptop 3 times yesterday : LP: #1596599
<ubottu> Launchpad bug 1596599 in ubiquity (Ubuntu Xenial) "Full disk encryption passphrase is using wrong locale" [Undecided,New] https://launchpad.net/bugs/1596599
<caribou> cyphermox: ^^^
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur 
 * mdeslaur hugs dholbach
<dholbach> :-)
<justxux> Some hugging party other here :D
<apw> cyphermox, ok we've played with grub2 and the practicle upshot is a no-change rebuild is the best way out; i am getting that done now
<cjwatson> Odd_Bloke: Can you point me to current-ish cloud image build logs for xenial?  None of the livefs objects I can find on LP seem very current
<Odd_Bloke> cjwatson: https://launchpad.net/~cloudware/+livefs/ubuntu/xenial/cpc/+build/66749 is the latest amd64; don't know if you'll have permissions on that though.
<tsimonq2> justxux: https://www.youtube.com/watch?v=4jzGIaZcGcM
 * tsimonq2 hides
<justxux> justxux is glad that everyone had a hug
<xnox> as per https://github.com/zyga/os-release-zoo/tree/master/ubuntu kylin has modified os-release file... i thought that is not allowed.
<xnox> Laney, cjwatson ^
<Laney> That is the least of it
<Laney> Or was the last time I had a reason to look
<cpaelzer> hi, I'm wondering what of a package delta to send to debian to shrink delta - I was wondering are they usually interested in stuff like apport hooks or ufw profiles?
<cpaelzer> or is any of that too ubuntu'ish
<cpaelzer> I almost expect an "it depends on the maintainer of the package" answer, but it is certainly better to ask first
<pitti> cpaelzer: Debian does have apport, but it has a fairly niche existence
<pitti> pretty well the same thing with ufw
<pitti> so I guess both can be justified, and as you say it depends on the maintainer; certainly not unreasonable to at least propose it
<cpaelzer> pitti: thanks for the feedback, I can easily throw it there and let them decide - but now I know what to expect
<pitti> if the maintainer is nice, it can also be installed iff dpkg-vendor --is ubuntu
<jdstrand> ufw is used in Debian and isn't Ubuntu-specific
<Laney> lxc
<Laney> hello12
<Laney> ssh x
<jdstrand> it is opt in of course, but I doubt you'd have any political issues
<pitti> Laney: you have an exceptionally bad password
<Laney> haha
<Laney> that's my vm password
<Laney> but why did that happen????????????????????????
<Laney> it's typing into multiple windows
 * pitti quietly disables the IRC keylogger again
<Laney> wtf
<pitti> Laney: iz GTK bug!
<Laney> oh terminator "broadcast all"
<Laney> SIGH
<Laney> at least I only have to change it in one place :)
<Laney> that VM is routeable
 * Laney makes sure it's not broadcasting before doing that
 * Unit193 tries hello13
<Laney> goodbye12
<Laney> CRAP
<Laney> and I just mistyped the new one three times in a row
<Laney> this is going to be fun
 * pitti just uses "a" as VM passwords, do I win the laziness crown?
<Laney> that ^ was my password on the first PDAish thing I got when I was 12
 * Laney used it for nostalgia purposes
<Laney> http://old-organizers.com/MorePicts/MP185.htm
<pitti> I had a PalmPilot III
<Saviq> lool, hey, seeing as you're the latest who touched doxyqml in Debian, any chance you would have time to update it to a newer version http://agateau.com/projects/doxyqml/ ?
<LocutusOfBorg> pitti, can you please make testsuite of opencv run against auto-multiple-choice and visp / proposed?
<stgraber> pitti: hey, any idea where the debug symbols for lxd 2.0.2-0ubuntu1~16.04.1 in xenial are?
<stgraber> pitti: not seeing them on ddebs
<stgraber> pitti: https://github.com/lxc/lxd/issues/2160
<LocutusOfBorg> stgraber, I see them https://launchpad.net/ubuntu/xenial/+package/lxd-dbgsym
<stgraber> LocutusOfBorg: yeah but they're not on ddebs.u.c
<LocutusOfBorg> not sure, maybe the mirror didn't keep up with the new uploads?
<stgraber> yeah, not sure, that's why I pinged pitti. That upload happened a few weeks back, so you'd think it'd be there by now :)
<stgraber> oh, that was a security upload, maybe that's somehow confusing something?
<cjwatson> ddeb-retriever has been having trouble for a while though I can't remember quite how long
<cjwatson> I killed it today to see if it'll catch up
<stgraber> ah good to know, thanks
<cjwatson> http://ddebs.ubuntu.com/dists/xenial-updates/ says 31 May so ...
<cjwatson> at one point it was having trouble because it didn't have permission to fetch one of the files it wanted; I never had a chance to dig into it
<Saviq> slangasek, hey, any chance someone could please look at bug #1585517
<ubottu> bug 1585517 in python-setuptools (Ubuntu Xenial) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517
<LocutusOfBorg> jbicha, abiword uploaded on deferred/2
<LocutusOfBorg> :)
<nacc> Logan: mwhudson: yeah, i was really hoping to avoid dealing with dbconfig-common again. We could do something smarter, though, I think, it's a valid bug/feature request. Right now, it just ends up broken for a less-than-obvious reason
<LocutusOfBorg> ubuntu built it :)
<Saviq> lool, if you do find time to bump doxyqml, Multi-Arch: foreign would be nice to have (bug #1585517)
<ubottu> bug 1585517 in python-setuptools (Ubuntu Xenial) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<semiosis> hi again.  any suggestions on how I can encourage a review of my merge proposal?  https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305
<semiosis> or help set my expectations for how long this might be sitting around?
<Odd_Bloke> semiosis: Thanks for taking the time to figure that all out!  I'm reviewing it now (though I don't have permissions to actually do the merge).
<semiosis> Odd_Bloke: awesome!  thank you
 * ogra_ thinks it would really be nice if people could use POSIX shell for patches to official code ... instead of bash
<Odd_Bloke> semiosis: Have you been able to test that this builds?  (And how?)
<semiosis> hmm good question.  i'll comment on the merge proposal with test instructions
<semiosis> i tested it on xenial, building xenial. it works, and solves all problems with the vagrant box i'm aware of
<Odd_Bloke> cjwatson: FYI, those initrd changes aren't going to make it in to our yakkety images until we get https://code.launchpad.net/~cloudware/livecd-rootfs/image-consolidation/+merge/297041 merged (so we aren't forked from lp:livecd-rootfs).
<Odd_Bloke> (infinity: slangasek: ^)
<semiosis> Odd_Bloke: instructions -- https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305/comments/768010
<Odd_Bloke> semiosis: Thanks!
<semiosis> you're welcome
<Odd_Bloke> semiosis: At a high-level, LGTM, I'll give it some actual testing tomorrow, probably. :)
<semiosis> sweet!
<cjwatson> Odd_Bloke: ah, is there a similar live-build fork for xenial images?
<cjwatson> Odd_Bloke: (also, not totally clear on how the existence of a livecd-rootfs fork is relevant to my live-build SRU, but I may be missing something)
<kilbith> hello, someone can explain me why the bloated package 'fonts-noto-cjk' is installed by default on ubuntu ?
<kilbith> apparenthy these are the chinese/japanese/korean fonts, but would i care if i'm european ?
<kilbith> this is a bit painful to download 75 MB whenever i update whereas these fonts aren't used by me
<ogra_> kilbith, because your browser might open chinese pages and you dont want weird squares scttered all over it
<kilbith> ... but i don't read chinese :/
<ogra_> nothing stops you from uninstalling that package
<kilbith> sure, i'm just questioning why it's installd by default for non-chinese people
<dobey> becasue not everyone is you
<dobey> the same reason many things are installed by default. to make the system useful to the widest group of people
<tgm4883> ogra_: would that be necessary for the in browser translations such as in google chrome?
<ogra_> tgm4883, no idea, but it iss necessary for showing the chars in any case ...
<dobey> chinese fonts are more useful to me than some of the applications installed by default, so i uninstalled those applications
<ogra_> if someone with a chinese name sends you an email his name will appear in chinese inn your mail app
<tgm4883> dobey: I think the question is more, if ubiquity knows where i'm located and my language, why install the package?
<ogra_> if you dont have any chinese fonts installed you just get broken squares
<nacc> it sounds like, so that *if* you run into any chinese characters in your usage of Ubunut, it will display properly
<ogra_> tgm4883, because the internet is intenational
<dobey> tgm4883: because chinese characters don't care what your locale or native language are
<nacc> given the population sizes, it seems like it could happen :)
<cjwatson> Lots of these things are trade-offs; making the livefs as universally useful as possible + making installation quick tends to imply keeping it on the installed system, but there's frequently room for changing font selection etc.
<dobey> i see han characters all the time, in my daily usage of the internet
<slangasek> pitti: release-manager> fixed, strange that this isn't a default?
<ogra_> i'm pretty sure fnts are usually just recommends, so you should always be able to uninstall them without doing much harm
<ogra_> *fonts
<nacc> this one in particular definitely is
<dobey> ogra_: most things are just recommends :)
<ogra_> yeah
<cjwatson> slangasek: it's part of the NewReleaseCycleProcess
<cjwatson> apparently not followed to the letter here
<cjwatson> at least I thought it was ... maybe not?
<Odd_Bloke> cjwatson: We use recipes to integrate the partner-specific changes which aren't public domain; these are based on bzr branches.  We currently just have a fork of lp:livecd-rootfs as of xenial release for that recipe.
<cjwatson> Odd_Bloke: right, so that doesn't relate to my change, I think
<Odd_Bloke> Oh, it is in live-build, right?
<cjwatson> Odd_Bloke: though if it might be possible to copy live-build from xenial-proposed into the base PPA for your livefs builds, that would be a great way for us to supply QA
<Odd_Bloke> I think we only do this for livecd-rootfs.
<Odd_Bloke> So live-build should come from the archive.
<cjwatson> Odd_Bloke: right, but you have a private PPA that you could copy-package it into if I succeed in persuading you that that's sensible
<slangasek> Saviq: bug #1585517> so, apparently someone dropped the Ubuntu patch to apt that would let us build-depend on arch: all packages without having to annotate every single one as M-A: foreign?
<ubottu> bug 1585517 in python-setuptools (Ubuntu Xenial) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517
<cjwatson> Odd_Bloke: (just in order that we can get this into cloud images faster and thus unblock xenial on LP builders)
<Odd_Bloke> cjwatson: You mean before it lands in xenial-updates?
<Odd_Bloke> (In a meeting, apologies if I'm being nonsensical)
<cjwatson> Odd_Bloke: right - I already did https://launchpad.net/~cjwatson/+livefs/ubuntu/xenial/cpc-experimental/+build/66852 to check that it basically worked and produced what looked like sensible results, though I didn't actually try booting that
<cjwatson> Odd_Bloke: since in order to get it into xenial-updates we have to QA it somehow anyway
<Saviq> slangasek, could be, it works in vivid still
<Odd_Bloke> cjwatson: Kicking it around with the team; if we were happy, how would we copy from -proposed?
<cjwatson> Odd_Bloke: copy-package --from ubuntu --from-suite xenial-proposed --to ppa:cloudware/ubuntu/cpc-livecd-rootfs --to-suite xenial --include-binaries live-build
<Odd_Bloke> cjwatson: Cool; copy requested.
<cjwatson> thanks!
<nacc> mdeslaur: thanks for the feedback, updated debdiff and submitted that part to debian
<mdeslaur> nacc: cool, thanks! :)
<tgm4883> nacc: you're aware that's the same guy about RAID in -server right?
<tgm4883> nacc: nry2 is hanktheai
<nacc> tgm4883: yeah, i'm gathering as much
<tgm4883> nacc: he didn't bother cloaking
<tgm4883> bah, I meant this for #ubuntu-discuss
 * tgm4883 hangs his head in shame
<slangasek> Odd_Bloke: looking at image-consolidation branch now.  I thought the plan had actually been to keep the tar.xz in parallel with the squashfs, but drop tar.gz as redundant?
<semiosis> Odd_Bloke: oh that ^ reminds me, with my changes vagrant no longer depends on the vmdk, but only on the root disk image, so it could be moved from 042 to something lower.  i didnt mess with that in my changes. figured that decision should be left up to the package maintainers.
<semiosis> lower numerically*
<slangasek> Odd_Bloke: looking back over the meeting notes to refresh my memory, I see that there is discussion of replacing tar.xz with squashfs, but I don't remember that being concluded in the meeting and am concerned that there may be deps on the .tar.xz that aren't ready to migrate
<pitti> slangasek: thanks, now I can do the necessary settings on the +language-packs page
<pitti> stgraber: ack, will have a look, added to my todo
<dasjoe> Was a containerdays today, sadly everything was quite Docker-centric, I hoped to see some LXD in action
<dasjoe> Oh, this isn't #lxcontainers :)
<LocutusOfBorg> oops jbicha I was uploading the tidy rebuilds
<LocutusOfBorg> BTW https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828902
<ubottu> Debian bug 828902 in src:utidylib "utidylib: please update for new tidy-html5" [Serious,Open]
<jbicha> LocutusOfBorg: ok, I asked in #kubuntu-devel for them to rebuild the 2 kde pkgs
<LocutusOfBorg> wonderful
<LocutusOfBorg> I'll leave the transition to you
<jbicha> libhtml-tidy-perl and python-tidylib both have test failures :(
<LocutusOfBorg> feel free to check the MIR status
 * LocutusOfBorg leaves, lets see tomorrow
<slangasek> Odd_Bloke: ok, have re-bootstrapped my brain to the conclusion that both tar.gz and tar.xz should go away.  Are we sure that nothing is consuming the tar.[xg]z downstream that will break by this change?
<Grorco> Hi I am just trying to get started on helping with small bugs and I'm a little confused, I got a branch of software-properties using bazaar and don't know where to go from here
<Grorco> the developer site says to use edit-patch to get a copy of it to work on but that errors out saying it's not a debian dir
<nacc> Grorco: link to said site?
<nacc> Grorco: edit-patch is used to modify debian patches inside a source package
<Grorco> nacc: http://packaging.ubuntu.com/html/fixing-a-bug.html
<nacc> Grorco: what's the bug in question?
<Grorco> nacc: alt-tab doesn't bring up the window
<Grorco> in unity*
<nacc> Grorco: ok, so once you've bzr-branch'd, you'll just go into the directory it was cloned to locally
<Grorco> nacc: the .bzr dir seems kind of empty outside of a .pack file
<Grorco> nacc: I guess what I'm asking is if I need to depackage that file for the code then fix and repack?
<nacc> Grorco: what was the command you ran to branch the bazaar tree?
<nacc> Grorco: the .bzr dir is more like the .git dir in a git repository, it's metadata about the repository (aiui). You want the directory that is in (by default)
<Grorco> nacc: bzr branch lp:software-properties software-properties.dev
<Grorco> which create a dir with the hidden .bzr file
<nacc> Grorco: well, you told it to branch to 'software-properties.dev'
<nacc> so that's where you should cd to, in order to develop on the source
<nacc> that's the 'root' of the source package directory
<Grorco> nacc: but it's empty outside of the .bzr file, maybe I should try branching again my internet was being all kinds of stupid yesterday
<nacc> Grorco: i ran that command just now and it produced a fully-populated software-properties.dev directory
<nacc> Grorco: also .bzr should be a directory, not a file
<nacc> Grorco: do you have some local bazaar configuration?
<Grorco> nacc: .bzr is a directory sorry if I called it a file, the only configuration I did was setting up my lp account with it
<nacc> Grorco: i would try 'rm -r software-properties.dev' and running hte branch command again
<nacc> Grorco: it worked for me? :/
<Grorco> nacc: It shows it fully populated from terminal after running it again :) but now I can't see the folder in caja?
<Grorco> is that normal?
<Grorco> nevermind I had other caja windows open closing them fixed that too thank you so much nacc! I felt like a complete idiot :)
<nacc> Grorco: dunno what caja is, but glad you are up and running :)
<Grorco> nacc: it's the default file explorer that comes with mate
<nacc> Grorco: ah ok, don't use mate, so didn't know :)
<Grorco> nacc: I'm going to go have a celebitory smoke, thanks again hopefully I'll be helping others soon
#ubuntu-devel 2016-06-29
<nacc> slangasek: would you have an opinion on LP: #1579815? Not sure if there is a precedence for that, although the regression chance is low, since it'd be a new package
<ubottu> Launchpad bug 1579815 in php-mongodb (Ubuntu) "Please "duplicate" as php5-mongodb to trusty-universe" [Wishlist,New] https://launchpad.net/bugs/1579815
<slangasek> nacc: that would normally be a no-go for SRU
<nacc> slangasek: that's what i thought as well, just wasn't sure, thanks!
<nacc> slangasek: given that, would i change the state to "invalid" (with an appropriate comment)? Or would you just leave it as "new"?
<sarnold> nacc: would this help the reporter? https://launchpad.net/~ondrej/+archive/ubuntu/php
<nacc> sarnold: checking; if i had to guess, that'll just be the backport of the php7-supporting php-mongodb to go with the php7 backport in the same ppa to trusty
<nacc> sarnold: hrm, perhaps i was wrong! Provides: php5.5-mongodb, php5.6-mongodb, php7.0-mongodb
<sarnold> nacc: it's a little terrifying that there's openssl and pcre3 and so on in there, it feels like a lot for one person to support.
<nacc> sarnold: yeah, i think that's because of the build-deps
<nacc> sarnold: not entirely sure
<nacc> sarnold: a lot of people use his ppa, i know that
<sarnold> yeah
<nacc> ah well, i think i've done my due diligence now :)
<sarnold> :)
<pitti> Good morning
<Odd_Bloke> slangasek: We've already been using this code to build yakkety images, so we did break (e.g.) lxd, but we've fixed it up now.
<LocutusOfBorg> pitti, pping again about opencv autopkgtests (please run against proposed)
<pitti> LocutusOfBorg: triggered
<pitti> LocutusOfBorg: indeed, looks better now (still blocked by the freeze)
<LocutusOfBorg> thanks pitti
<GunnarHj> pitti: Thoughts on bug #1591503? Would it be a good idea to rebuild fcitx-mozc for now and somehow override pkgstriptranslations?
<ubottu> bug 1591503 in language-pack-zh-hant-base (Ubuntu) "missing fcitx-mozc.mo" [Medium,Confirmed] https://launchpad.net/bugs/1591503
<pitti> GunnarHj: oh, so this isn't a regression from Monday's langpack builds, AFAIUI?
<rbasak> pitti: would you consider bug 1596056 for an SRU to Xenial? It'd be really helpful for all the postinst failure bugs we get.
<ubottu> bug 1596056 in init-system-helpers (Ubuntu) "output of invoke-rc.d for systemd units un-debuggable on failure" [Wishlist,Fix committed] https://launchpad.net/bugs/1596056
<rbasak> We can wait for it to settle and have some testing first of course.
<pitti> rbasak: yeah, seems fairly harmless
<rbasak> Great, thanks!
<pitti> rbasak: added a task
<rbasak> I just went to do that and Xenial wasn't in the list of options. Most confusing :-)
<pitti> rbasak: probably just mid-air collision
<rbasak> Yeah. Webapps and concurrency don't mix.
<pitti> I mean, I probably already added it when you tried to
<pitti> GunnarHj: yeah, rebuilding mozc with NO_PKG_MANGLE=1 seems fine as a workaround for now; I can't see what's wrong with it right now
<rbasak> cyphermox: bug 1211110 looks like it could use some attention. There are a few bugs I've seen with poor NM/OpenVPN interactions.
<ubottu> bug 1211110 in openvpn (Ubuntu) "network manager openvpn dns push data not updating system DNS addresses" [High,Confirmed] https://launchpad.net/bugs/1211110
<cyphermox> rbasak: are you pointing it out because you're affected?
<cyphermox> unfortunately, it's quite hard to get things to play nice when they all expect to be authoritative and they all go muck in resolv.conf
<rbasak> cyphermox: no I'm not affected, but it's a hot bug and I wasn't sure if you'd seen it.
<cyphermox> happyaron: ^
<pete-woods> pitti: question about packaging dbusmock templates
<pete-woods> if a package stuffs a new template in /usr/lib/python3/dist-packages/dbusmock/templates/
<pete-woods> are you okay with that?
<pete-woods> (I think it's already happening, btw)
<pitti> pete-woods: fine for me, as long as there are no conflicts
<pete-woods> pitti: awesome, that makes my life easier then
<pitti> pete-woods: however, you can specify a full path for the template
<pete-woods> as we can put new templates in a package we manage, without having to bug you
<pitti> so it shouldn't usually be necessary
<pete-woods> yeah, there's that option too
<pete-woods> I'd really like to have an official directory for it
<pete-woods> so I can know where to look
<pitti> templates should not really be shipped in debs
<pitti> they should only be necessary during package build ("make check") or autopkgtests, in both cases it can be taken from the source
<pitti> unless there's some foo-test-tools package
<pete-woods> actually thinking of -dev packages
<pete-woods> so I can include e.g. a mock template for connectivity-api in connectivity-api-dev
<pitti> ah
<pete-woods> which stays in lock-step with the API
<pete-woods> pitti: the main thing I was hoping for was a canonical path for 3rd party packages to contribute new mocks to (in their -dev packages)
<pete-woods> if we could agree on that, and get a patch to python-dbusmock to search it, that would be great
<pete-woods> as we'd like to start putting our money where our mouth is, and provide reusable mocks for each of the daemons that our team is responsible
<pete-woods> for
<pitti> pete-woods: ah, and you don't like the above because it's Debian specific? (specific to python3-defaults, that is)
<pete-woods> pitti: it just feels a bit naughty for us to stuff things in the upstream package's path
<pete-woods> as opposed to e.g. a /usr/share/dbusmock/templates dir
<pitti> pete-woods: I don't mind moving the templates to /usr/share/python-dbusmock/templates/ and search/put them there
<pete-woods> or something along those lines
<pete-woods> pitti: that would be great
<pete-woods> we want to put some documentation together for how we'd like teams to support testing by providing their own mocks
<pete-woods> mocks for their own daemons I mean
<pete-woods> and being able to release them into a standard place alongside their headers, etc would be great
<pete-woods> especially being able to point to a readme.md on your github site saying "this is where templates go"
<pete-woods> so we don't just look like some lone nuts
<pitti> pete-woods: well, if we change that, then dbusmock's own templates would go there too
<pete-woods> pitti: well it could search both paths
<pete-woods> pitti: but I'm happy with either option there
<pitti> that sounds a bit complicated to me
<pitti> and makes it less obvious which one wins on conflicts
<pete-woods> that's a fair point
<pete-woods> pitti: at any rate, anything along those lines would be great. I can try hacking on it myself if you don't have time to do it?
<slangasek> nacc: 'wontfix' would be my preference there :)
<nacc> slangasek: ack, thanks!
<nacc> mdeslaur: fyi, ondrej picked up your patch, thanks again!
<mdeslaur> nacc: ah, cool, thanks for sending it to debian!
<semiosis> Odd_Bloke: hi.  just checking in.  i'll be around most of the day if you have any questions about the merge.
<Odd_Bloke> semiosis: Oh, shoot, that completely fell off my plate. :(
<semiosis> if you can't get to it, do you think anyone else might be able to?
<Odd_Bloke> semiosis: It'll need to be someone on my team, and we're all equivalently busy ATM, I'm afraid.
<Odd_Bloke> semiosis: But I've milestoned it in a way that it'll show up on my list of things to do.
<Odd_Bloke> semiosis: So unless there's some catastrophe that I need to deal with, I should get to it by the end of the week.
<semiosis> well then i guess that's all I can do.  just want to mention that this bug affects a lot of people, who are going elsewhere for ubuntu vagrant images (https://github.com/mitchellh/vagrant/issues/7463#issuecomment-228363552)
<Odd_Bloke> semiosis: Apologies for dropping it.
<Odd_Bloke> semiosis: Understood, thank you again for taking the time to submit the MP.
<semiosis> it's my pleasure.  please let me know if there's anything else I can do to help move things along.
<sil2100> infinity, slangasek: hey! Could one of you, if you find some time, review https://code.launchpad.net/~sil2100/ubuntu-cdimage/ubuntu-touch-custom/+merge/298640 ?
<sil2100> infinity, slangasek: thanks!
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<coreycb> arges, hello there, any chance you could review some of our sru's in the wily queue?
<doko> slangasek, won't we trigger the "interpreter problem" by making setuptools M-A: foreign?
<slangasek> doko: yes and no.  python3-setuptools is pure python, with nothing in its dependency chain besides python3; there is one Arch: any package in the archive that depends on python3-setuptools, nml, and it includes a python .so, so it *could* be affected by the "interpreter problem".  And third-party packages could also be affected.  But in practice, we don't have a better way to express this
<slangasek> currently, and not annotating it blocks cross-building, so IMHO it's the lesser evil
<doko> slangasek, agreed about python-setuptools, but python-pkg-resources is much more used
<doko> the alternative is to make these packages Arch: any
<highvoltage> /win 19
<slangasek> doko: I get what I need (unblocking unity8 cross-build) with just python-setuptools, python-pkg-resources doesn't matter to me
<slangasek> doko: so I guess I should've filed a separate bug report, sorry
<doko> wondering why, because setuptools depends on pkg-resources
<doko> but yes, making it M-A: foreign is less invasive than making it Arch: any
<mvo> arges: hey, if you have time, it would be great if you could do a sru review/approval for snapd 2.0.10
<arges> ok
<arges> coreycb: sure
<coreycb> arges, thanks
<nacc> hallyn: ping
<hallyn> nacc: .
<nacc> hallyn: heya -- refreshing myself on the openipmi merge/delta and seeing what to send to Debian. We have a delta to not use /var/lock/subsys (typo'd in the changelog i realize now) because it doesn't exist (or didn't). But I think it exists in both Debian and Ubuntu now.
<nacc> hallyn: i'm thinking we can drop that delta
<hallyn> nacc: <shrug> i don't have /var/lock/subsys
<hallyn> xenial system running upstart
<nacc> hallyn: ah, might be an upstart vs. systemd thing?
<hallyn> but will openmpi create the dir if its needed?
<nacc> a sid container had it (was my first test)
<hallyn> "officially" upstart is no longer supported so you can probably drop it.  is it needed in cloud archives?
<hallyn> i think it'd be better if we use /var/lock/subsys and just make sure that upstart or openmpi creates it if it doesn't exist
<nacc> hallyn: right, and that'd be something i think debian would need to ensure too, so let me see and i'll double/triple-check on that
<hallyn> maybe update /etc/init/mounted-var.conf
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hallyn> nacc: cool - o \o
<hallyn> hm
<hallyn> that's me with broken glasses
<hallyn> \o
<nacc> heh
<nacc> hallyn: i think we can send the rest of the delta straight to debian, as it's bugfixes, etc. and then we can sync finally
<nacc> rbasak: --^ fyi
<nacc> rbasak: i'll update my MR too
<hallyn> excellent
<pitti> nacc, hallyn: /run/lock/subsys is created in /usr/lib/tmpfiles.d/legacy.conf; happy to drop this if we don't need it
<hallyn> pitti: i think its the other way around - openmpi wants it and upstart doesn't create it
<nacc> pitti: ah interesting ...
<hallyn> although maybe openmpi should then be updated
<nacc> hallyn: well, we could change openipmi to use /var/lock then
<hallyn> if it need something out of 'legacy.conf' :)
<hallyn> right
<pitti> yeah, we should not rely on those old paths any more
<nacc> pitti: and that would drop one more legacy user
<nacc> ok, is that true in debian too, pitti ?
<hallyn> good justification for a push to debian.
<hallyn> thx pitti
<pitti> also, not /var/lock/, using this is brittle for early-boot stuff
<arges> coreycb: why did you split the openstack SRU bugs up
<pitti> nacc: yes
<nacc> pitti: where would you suggest?
<pitti> nacc: /run/lock
<pitti> nacc: /var/lock is a symlink, but that doesn't help you if /var itself is remote
<nacc> pitti: ah intersetsing
<nacc> *interesting
<pitti> that was the whole reason for introducing /run :)
<nacc> pitti: got it, i'll update the patch and fix that then
<pitti> (well, that and that it's guaranteed to be a tmpfs)
<pitti> nacc: cheers
<pitti> FWIW, I don't think that we had /var/lock/subsys under sysvinit either
 * pitti boots a debian sid with sysv  to check
<coreycb> arges, I think originally glance-store wasn't ready so we didn't want to hold up the neutron*/nova sru
<pitti> nacc: FTR, openmpi is not early-boot stuff, so /var/lock is not technically broken; but it's better style to use /run directly IMHO
<nacc> pitti: yep, make ssense
<pitti> nacc: yep, no /run/lock/subsys (and therefore not /var/lock/subsys) under sysvinit-core in Debian
<pitti> nacc: so, doesn't affect us, but does affect Debian
<pitti> i. e. not worth keeping a delta over it, but worth filing fix to Debian
<nacc> pitti: yep, submitting now
<nacc> hallyn: pitti: thanks again for the guidance
<pitti> nacc: yw!
<hallyn> \o
<Odd_Bloke> How can I find if there's an Ubuntu bug corresponding to a Debian bug?
<Odd_Bloke> *find out
<pitti> Odd_Bloke: https://bugs.launchpad.net/bugs/bugtrackers/debbugs/12345
<ubottu> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]
<pitti> Odd_Bloke: of course that only works if the ubuntu bug actually got linked to that 12345 debian bug
<Odd_Bloke> pitti: Thanks!
<robert_ancell> slangasek, when you say "We have the capability to mark different support periods in the archive by packageÃarchitecture" does that mean we can blacklist a bunch of packages to not build i386?
<slangasek> robert_ancell: I mean that the Packages file can annotate what the support period is for a given binary package
<robert_ancell> ah
<slangasek> blacklisting a package from building should be done by changing the package itself to not build for that arch
<robert_ancell> oh right, that's easy to do. duh.
<Unit193> robert_ancell: LP 1494491 got a chance this cycle, btw?
<ubottu> Launchpad bug 1494491 in Light Display Manager "Use accountsservice extensions for background, keyboard layouts, has-messages" [Medium,Triaged] https://launchpad.net/bugs/1494491
<robert_ancell> Unit193, if someone does the work I'm happy to review / land it
<robert_ancell> It seems unlikely I'll have time at present
<Unit193> Alright, thanks.
<nacc> pitti: hallyn: while it seems like long-term we'd want to convert /etc/init.d/openipmi to a proper systemd unit file (?), is there any reason for there not to be a 'Default-Start' and 'Default-Stop' entry in that script? It apparently leads to errors: LP: #1596474
<ubottu> Launchpad bug 1596474 in openipmi (Ubuntu) "openipmi adding to autoload fail" [High,New] https://launchpad.net/bugs/1596474
<slangasek> nacc: there's certainly no reason not to
<nacc> slangasek: can i just provide a reasonable (read: common) default?
<slangasek> nacc: reasonable defaults are 'Default-Start: 2 3 4 5' 'Default-Stop: 0 1 6'
<slangasek> and you should certainly use those values :)
<nacc> slangasek: ack, that's what i was planning on
<nacc> will send that to debian too :)
#ubuntu-devel 2016-06-30
<Grorco> Hello I have a question about python imports, I'm looking at some code and after the initial imports the use from .WhatEver import blahblahblah how does the . work?
<Grorco> this is the specific part I'm having trouble with: from .SimpleGtkbuilderApp import SimpleGtkbuilderApp
<Grorco> is it just pointing to the current directory?
<sarnold> Grorco: it looks like "package-relative" rather than "directory relative" https://www.python.org/dev/peps/pep-0328/#guido-s-decision
<Grorco> sarnold: thank you this is the first source package I've worked on and I had never seen that before could I get around this temporarily for testing by just importing the module
<Grorco> I'm sorry if I posting this on the wrong channel to be asking I was working on a papercut so I came here, should I take questions like this to a python channel?
<sarnold> a python channel is more likely to be active at this time, anyway :) heh
<mwhudson> slangasek: if i want to make a snappy packaging change, where would be the best place to send it?
<mwhudson> slangasek: snapcore/snapd? vorlonofportland/snapd?
<cpaelzer> good morning
<happyaron> cyphermox: I gave it a try moment ago and it works the way in your comment, not sure if split tunneling has more scenes I'm not aware of, though
<pitti> nacc: no, Default-{Start,Stop} is a SysV init scripts' way to set the runlevel, that must be done if the service is to be started automatically
<pitti> nacc: btw, Default-Stop: 1 is usually preferred, unless your service needs some special code other than just being killed at shutdown/restart
<doko> infinity,  lintian merge would be appreciated
<pitti> stgraber: https://images.linuxcontainers.org/ â I can haz Fedora 24?
<seb128> does anyone has an idea how to debug issues like bug #1589097?
<ubottu> bug 1589097 in gnome-menus (Ubuntu) "package gnome-menus 3.13.3-6ubuntu3 failed to install/upgrade: triggers looping, abandoned" [High,Confirmed] https://launchpad.net/bugs/1589097
<seb128> we seem to get some report of that one
<seb128> bug #1590952
<ubottu> bug 1590952 in gnome-menus (Ubuntu) "package gnome-menus 3.13.3-6ubuntu3 failed to install/upgrade: triggers looping, abandoned" [High,Confirmed] https://launchpad.net/bugs/1590952
<seb128> etc
<Laney> You probably fix it by making bamfdaemon interest-noawait instead of interest
<seb128> Trevinho, ^ can we get that done and SRUed?
<seb128> Laney, how do you get that from the triggers list?
<Trevinho> seb128: sure, but I can't upload it in the silo. Can you?
<seb128> why not?
<Laney> It said bamfdaemon was involved, so I checked its triggers file
<Trevinho> seb128: I don't have powers AFAIK.
<seb128> Trevinho, isn't bamf on standard CI train landing?
<Trevinho> seb128: ahhhhh, sure. But I thought you meant the gnome menus thing
<seb128> Trevinho, yes, that's an upgrade bug/triggers depends loop, Laney thinks changing bamf to use interest-noawait should fix it
<jamespag`> pitti, hey - I added a reference to the OpenStack SRU wiki page to https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1585660
<ubottu> Launchpad bug 1585660 in ceph (Ubuntu Xenial) "[SRU] ceph 10.2.2" [High,New]
<seb128> Laney, k, I guess I didn't look at triggers for look enough to not understand the issue or where gmenucache is coming from ... anyway, not important, thanks for the hint!
<jamespag`> is that sufficient from your perspective as a regression test plan? its pretty much what we've done for the last 3 years for OpenStack bits in the archive
<Laney> seb128: Would need to do more digging to find out exactly why, but it's my first guess and might be easier to do it and see if the reports drop off
<seb128> Laney, k, makes sense, thanks
<seb128> Trevinho, do you need help with that?
<Trevinho> seb128: maybe, let me see :)
<kilbith> people, there's no reason to stick on mesa 11.2.0 when mesa 11.2.1 and 11.2.2 contain only bugfixes and no new features..
<tsimonq2> kilbith: could you be more specific about what release of Ubuntu?
<kilbith> tsimonq2: 16.04
<tsimonq2> kilbith: what's the package name?
<kilbith> traditionally ubuntu always stick with the same mesa version until the next release..
<kilbith> which is plain wrong
<kilbith> tsimonq2: mesa, obviously
<tsimonq2> !info mesa xenial
<ubottu> Package mesa does not exist in xenial
<tsimonq2> !info mesa yakkety
<ubottu> Package mesa does not exist in yakkety
<tsimonq2> weird
<tsimonq2> kilbith: so it's 11.2.0 in Xenial but 11.2.1 in Yakkety
<tsimonq2> kilbith: https://launchpad.net/ubuntu/+source/mesa
<kilbith> yes
<kilbith> and 11.2.2 is supposedly stabler
<tsimonq2> looks like 11.2.2 is in Debian Testing right now
<tsimonq2> we should get it via automatic import soon in Yakkety
<kilbith> and why not in Xenial ?
<tsimonq2> kilbith: then we just need an SRU filled out to get it in Xenial
<kilbith> so much administrative heaviness...
<tsimonq2> because the development release gets all the new packages, and package updates for Xenial, an LTS and stable release, need to be checked out before it's released to those users to ensure stability
<pitti> well, "supposedly more stable" is not a good enough bet for stable OS releases -- we must not break anything that currently works
<tsimonq2> ^
<pitti> and mesa is notoriously regression prone, verifying it on a lot of different hw is hard and expensive
<kilbith> look, the upstream devs are better able to determine if their package is stable or not than some distro maintainers
<kilbith> because it's their code
<pitti> well, I wasn't saying that we won't do the update (we most probably will), but we don't just throw it over the  fence and hope that nothing breaks :)
<tsimonq2> ^
<tsimonq2> kilbith: if you really need it right away, you can install the debs manually from Debian
<pitti> tjaalton: I guess at some point you guys were planning to update mesa in xenial, I figure?
<tsimonq2> pitti: but like I said, maybe it should wait for the import from Debian before an SRU? *shrug*
<kilbith> tsimonq2: if i use ubuntu, it's not for tinkering with the packages manually, otherwise i'd would return back on arch
<tjaalton> pitti: yes
<pitti> tsimonq2: yes, of course devel needs to be updated first, as usual
<tsimonq2> kilbith: it's FLOSS, so what you wish with your system, just because it's Ubuntu doesn't mean you don't have the ability
<pitti> kilbith: so, if there is something broken on your system, please file a bug about it (we can then use this for SRUing); if it's just "I want the new version just because", then there's no urgency and it will happen at some ponit
<kilbith> that said, the maintainer on fedora is dave airlie himself (mesa dev) and often update the mesa packages to the latest version even within the current stable release
<tjaalton> mesa has a standing MRE
<tsimonq2> aha, there you go
<tsimonq2> kilbith: so it's in the works, it's not like it won't happen :)
<tsimonq2> it just might take a few weeks if not longer
<tjaalton> i'm working on lts-xenial backport stack, mesa updates have lesser priority
<ppisati> i'm passing net.ifnames=0 and i've created a dummy /etc/udev/rules.d/80-net-name-slot.rules file, but my nic's keep changing name
<ppisati> any idea?
<pitti> psivaa: is that an USB device?
<stefanct> i am trying to build an ubuntu kernel with a single patch applied that should not change the ABI AFAICT (generic ID addition for a USB module)
<ppisati> pitti: yes
<pitti> psivaa: sorry, IRC nick fail, I meant ppisati
<pitti> ppisati: known bug, let me find the #
<psivaa> pitti: Yep. No problem. Hope you're doing well :)
<stefanct> so i followed the (various) articles in the wiki... currently ending up in II: Checking modules for generic...previous or current modules file missing!
<pitti> psivaa: I am, thanks! how's things in CI land?
<psivaa> pitti: CI land has been obliterated. Now OLS. Doing good. Thanks
<stefanct> i have created the <previous-version>/<arch>/ignore files as documented... although i am not 100% sure what previous-version refers to (i have used the ubuntu version string to which i have appended +bla for my own build)
<pitti> ppisati: bug 1593379 (with linked Debian bug)
<ubottu> bug 1593379 in systemd (Ubuntu) "systemd 229-4ubuntu6 ignores net.ifnames=0 on USB" [Undecided,In progress] https://launchpad.net/bugs/1593379
<stefanct> adding skipabi=true skipmodule=true seems to help... unlike the ignore files (unlike documented here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Overriding_module_check_failures )
<ppisati> pitti: thanks
<flexiondotorg> Anyone here know if Cloud images for 16.10 alpha 1 will be published today?
<Odd_Bloke> flexiondotorg: We're just going to participate as Ubuntu this time around (so no).  If you want what would have been the alpha1 image, just grab the latest daily. :)
<flexiondotorg> Odd_Bloke, Thanks. Just wanted to know for the release announcement.
<flexiondotorg> I don't appear to be able to edit the wiki.
<flexiondotorg> I've got a vague memory about it, or parts of it, becoming read-only.
<flexiondotorg> tsimonq2, Do you have the permission to add the required wiki pages?
<tsimonq2> flexiondotorg: yes
<tsimonq2> flexiondotorg: I would suggest making a Google Document so we can suggest stuff and make comments :)
<flexiondotorg> tsimonq2, Traditionally the release notes for each flavour are posted on the wiki.
<flexiondotorg> I can't do that anymore.
<flexiondotorg> As for the release announcement, sure, a Google Doc is fine :-)
<Trevinho> seb128: for that bamfdaemon change... what should I exactly do?
<Trevinho> I didn't find much docs around
<Laney> Trevinho: sed -i "s/interest/&-noawait/" debian/bamfdaemon.triggers
<Trevinho> Laney: ah, ok simple as that..
<Laney> Hopefully
<Trevinho> Laney: that's in generating the index file only though.. So it would affect first-startup only. not when new stuff is added
<Laney> Trevinho: Seems fine?
<Trevinho> Laney: I hope so
<Trevinho> Laney: is there a bug related to that, or just the same for gnome-menu?
<Laney> Trevinho: I would reassign or add a task to one of those gnome-menus ones
<Trevinho> ok, on that
<Trevinho> Laney: do you also know why the new unity7 landing is sticking in proposed for so long?
<Laney> Trevinho: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity this page does
<Laney> I just retried that test
<Trevinho> Mh, I really should land the changes I did so that we don't have this link with unity8
<Trevinho> Laney: https://code.launchpad.net/~3v1n0/bamf/triggers-noawait/+merge/298765
<Laney> Trevinho: no permissions to approve, but looks good
<Laney> Trevinho: you linked a weird bug though
<Trevinho> Laney: the name is not the nicest I agree
<Laney> https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1589097
<ubottu> Launchpad bug 1589097 in gnome-menus (Ubuntu) "package gnome-menus 3.13.3-6ubuntu3 failed to install/upgrade: triggers looping, abandoned" [High,Confirmed]
<popey> flexiondotorg: you should be an Ubuntu Member, should you not?
<popey> As you're a per package uploader?
<Trevinho> Laney: well, that's better, but still related to gnome-menus.. .I add bamf then
<popey> I don't know that process from the developer board / motu side. Dunno if someone else here does.
<popey> But either way, if you're in ~ubuntumembers you get edit rights on the wiki.
<flexiondotorg> popey, Thanks for approving my ~ubuntu-wiki-editors membership. I can now help tsimonq2.
<tsimonq2> \o/
<flexiondotorg> And yes, I "think" I might be eligible for Ubuntu Membership.
<Laney> You should have been added to ~ubuntu-dev, unless the DMB decided not to give you membership
<flexiondotorg> I was just reading the wiki and I seem like I might be able to get a nomination via the DMB because of my PPU.
<flexiondotorg> Laney, Membership wasn't discussed. I didn't even know it was an option until a few days ago.
<Laney> https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Teams_to_add_uploaders_to
<Laney> A script to find people who aren't in either of those teams would be nice
<flexiondotorg> jbicha, See above ^^^ I think you did that recently?
<Laney> Suggest you contact the DMB and ask them to fix it, providing that link
 * Laney lunch
<rbasak> flexiondotorg: when did you originally get upload access?
<flexiondotorg> rbasak, Ummm. April-ish.
<rbasak> flexiondotorg: I think you not belonging to ~ubuntu-dev is an oversight. I reviewed https://irclogs.ubuntu.com/2016/05/09/%23ubuntu-meeting.html and https://irclogs.ubuntu.com/2016/04/25/%23ubuntu-meeting.html that don't suggest otherwise, and granting membership is our default position according to https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Teams_to_add_uploaders_to
<flexiondotorg> rbasak, OK :-) So what happens next?
<flexiondotorg> rbasak, Thanks for looking into this.
<rbasak> flexiondotorg: I've added you :)
<flexiondotorg> :-)
<flexiondotorg> rbasak, So does being an ~ubuntu-dev member mean I can apply for ~ubuntu-member now?
<rbasak> flexiondotorg: no need - the DMB implicitly granted that when granting you PPU (since we didn't say otherwise). So you're in ~ubuntu-member by virtue of being in ~ubuntu-dev - see https://launchpad.net/~flexiondotorg/+participation
<rbasak> flexiondotorg: sorry this got missed before. And welcome :-P
<rbasak> Oh, and not PPU, the packageset.
<flexiondotorg> rbasak, No problem and thanks for sorting that so promptly :-)
<rbasak> flexiondotorg: also, you quite obviously should be a member :-)
<flexiondotorg> rbasak, So how do I get an @ubuntu.com email address?
<rbasak> Good question. That I don't know, since as the email infrastructure is shared with Canonical it's different for me.
<tsimonq2> flexiondotorg: If I remember correctly, vanguard at #canonical-sysadmin can assit
<tsimonq2> *assist
<flexiondotorg> rbasak, tsimonq2 Thanks.
<rbasak> Some info at https://wiki.ubuntu.com/UbuntuEmail
<flexiondotorg> popey, That got fixed then :-)
<rbasak> But those pages don't seem to explain how to get one added.
<tsimonq2> rbasak: I had a question relating my email one time and IS has the access to change whatever
<tsimonq2> s/relating/relating to/
<rbasak> Yeah I suspect the answer is "file an RT". We should document that in the wiki if so.
<tsimonq2> good idea
<popey> flexiondotorg: congrats ã
<tsimonq2> \o/ ^
<flexiondotorg> :-D
<cjwatson> rbasak: I believe it does say; it says "wait at least 48 hours [after being added to ~ubuntumembers] before checking if the email is working"
<tsimonq2> cjwatson: well no
<cjwatson> says there's a script that creates the aliases that runs every two days
<tsimonq2> when I got membership, I leanred that IS has to approve it
<rbasak> cjwatson: but what email? ie. how do you get the script to create you, and what alias would it use?
<tsimonq2> and that takes longer than 48 hours sometimes :)
<tsimonq2> *learned
<cjwatson> tsimonq2: it is possible that the page is wrong, but it does say :-)
<cjwatson> rbasak: it's always your LP username
<rbasak> Ah, I see.
<tsimonq2> cjwatson: well 48 hours is probably the standard response time
<cjwatson> rbasak: the page says that
<rbasak> cjwatson: you're right. Thanks.
<cjwatson> I guess it may be https://wiki.canonical.com/InformationInfrastructure/ISO/HowTo/LPMailMerge (internal only, sorry), which suggests that the alias file is generated automatically but a sysadmin has to sanity-check and commit it
<nacc> pitti: thanks
<stgraber> pitti: let me try
<cjwatson> pitti: FYI I believe I've fixed ddeb-retriever (by getting StÃ©phane to make a team public)
<slangasek> mwhudson: snappy packaging change> send it to both for right now?
<nacc> mterry: would you have a link or reference to the tidy-html5 transition?
<pitti> cjwatson: ooh -- was that the "permission denied"-thingy exception? thanks!
<cjwatson> that's the one
<semiosis> Odd_Bloke: just saw your comment.  i'm around if you want to chat
<Odd_Bloke> semiosis: Sure; the install is failing to find the virtualbox bits and (chef|puppet).  I'm hoping an `apt-get update` will fix it.  If not, then it may be that we don't have the right components enabled.
<Odd_Bloke> semiosis: But as this is failing in an environment I have access to and you don't, I figured it made more sense for me to iterate than to ask you to make changes you can't test. :p
<semiosis> hmm.  that stuff all happens in the debootstrapped chroot.  why would your environment be any different from mine?  both create the same disk image, no?
<semiosis> maybe those packages aren't in your apt mirror?
<nacc> rbasak: confused a bit by the output in the DpkgTerminalLog.gz of LP: #1597597
<ubottu> Launchpad bug 1597597 in php7.0 (Ubuntu) "package libapache2-mod-php7.0 7.0.8-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,New] https://launchpad.net/bugs/1597597
<nacc> it's one of those falsely attributed to php7 (afaict), as the underlying issue is perl warnings from debconf?
<rbasak> nacc: I've seen that before but I never figured out what it is.
<nacc> rbasak: do you have a default reply for such bugs handy? is it worth debugging?
<rbasak> nacc: http://paste.ubuntu.com/18180857/ is my standard reply. As politely as possible, "need steps to reproduce otherwise we can't work on it".
<nacc> rbasak: thanks
<rbasak> And then I mark Incomplete.
<Odd_Bloke> semiosis: Yeah, I'm not sure.  This is happening on the Launchpad builders though, which is where this eventually needs to work.
<semiosis> Odd_Bloke: ok thanks for working on it.  i'm here if you need me for anything
<Odd_Bloke> semiosis: Sure thing, thanks. :)
<mterry> nacc, no I don't -- something started in Debian and affecting yakkety, that's all I know
<nacc> mterry: ack, thanks
<nacc> rbasak: i'm still waiting for responses to my bacula bug fixes (testing), although some of the various bugs have responded affirmatively, if you're able to review those too. Or, as discussed today, I can send a MR for it
<pitti> doko: FYI, I'm fixing scour autopkgtest regression (one of the things blocking p-setuptools)
<doko> ta
<pitti> dinstall is in 3 hours, and LP takes ages to import these days, so won't go green until tomorrow; if it's urgent, I can hint
<doko> no, don't think so
<pitti> snapcraft is its own fault, not python's
<cjwatson> pitti: it does?
<pitti> cjwatson: yeah, something like 10 hours
<cjwatson> pitti: *blink*
<cjwatson> news to me
<doko> python2.7 and python3.5 migrated, good news
<doko> binutils still blocked on the lintian autopkg test. will try to merge that tonight or tomorrow morning
<pitti> cjwatson: well, maybe 8 or so;
<pitti> cjwatson: so, I uploaded https://tracker.debian.org/news/779188 on Tuesday night, it was dinstall'ed in Debian at 01:52 UTC
<cjwatson> pitti: I think any time I've looked it's actually been that it takes a while to appear on the mirror that we use
<pitti> and imported into LP https://launchpad.net/debian/+source/init-system-helpers/+publishinghistory at 12:13
<pitti> so pretty well 10 hours, yes
<pitti> cjwatson: ah, maybe it's that
<pitti> I didn't actually consider it a bug, I thought I'm just impatient :)
<cjwatson> pitti: but we try every six hours currently, maybe the cycle has got a bit out of sync
<stgraber> pitti: we now have fedora 24 images, no idea if they work though :)
<Odd_Bloke> semiosis: Looks like the `apt-get update` might have fixed the problem. :)
<semiosis> nice!
<jbicha> Laney: https://people.canonical.com/~ubuntu-archive/archive-permissions/
<jbicha> it has false positives though so you need to cross-ref results with lp-check-membership username ubuntu-dev
<jbicha> or make the script smarter
<Odd_Bloke> semiosis: Could you test http://people.canonical.com/~dwatkins/livecd.ubuntu-cpc.vagrant.box for me?
<Odd_Bloke> semiosis: (And I have to head off for the evening now, but if that looks good to you, could you post it on the bug and ask others to test?)
<semiosis> Odd_Bloke: will test & comment soon.  thanks!!!
<pitti> stgraber: yay, cool! is there some equivalent of "apt-get update" for the container list? I don't see them yet in lxc image list images:
<pitti> arf, and now I do, sorry
<stgraber> takes a little while between jenkins building it and it being imported, signed, packaged and published, so maybe you tried just before that happened
<stgraber> will be even slower soon as the frontends will be running by Canonical on a periodic rsync kind of setup (rather than current push rsync as I have on my network)
<pitti> and oh well, it boots :)
<pitti>              âânetwork.service
<pitti>              â ââ 53 /bin/bash /etc/rc.d/init.d/network start
<pitti>              â ââ176 /bin/bash /etc/sysconfig/network-scripts/ifup-eth ifcfg-eth0 boot
<pitti> shush :)
<pitti> stgraber: merci beaucoup; man, this is magnitudes more convenient than downloading the iso and installing it into a VM!
<stgraber> :)
<stgraber> glad that all it took was adding "24" to the list of series on Jenkins, 23 was significantly more painful to get building
<pitti> bdmurray: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#software-properties is stuck on a test regression  (.22 still works)
<mwhudson> slangasek: ok
<jderose> pitti: this is an extra weird one, wondering if you have any thoughts on it - https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597876
<ubottu> Launchpad bug 1597876 in systemd (Ubuntu) "installing/upgrading packages containing systemd services results in prompt for cryptoswap passphrase [xenial]" [Undecided,New]
<jderose> kirkland: when you have a chance, could you give this a look over (merge proposal submitted) - https://bugs.launchpad.net/ecryptfs/+bug/1597154
<ubottu> Launchpad bug 1597154 in System76 "ecryptfs-setup-swap fails with GPT partitioning + NVMe/MMC drives" [Critical,In progress]
<tyhicks> jderose, kirkland: that's on my todo list by EOW
<jderose> tyhicks: awesome, music to me ears! :D Do you think this fix can land in time to be included on the 16.04.1 ISOs?
<tyhicks> jderose: yes!
<jderose> tyhicks: more sweet music to my ears! thanks!
#ubuntu-devel 2016-07-01
<nacc> slangasek: can i get your opinion on something? debian (and yakkety, which is merged up at this point) have switched the first alternative for php7.0 from 'php7.0-fpm | libapache2-mod-php7.0 | php7.0-cgi' to 'libapache2-mod-php7.0 | php7.0-fpm | php7.0-cgi'. This is becuase of Debian Bug #822774. Would it be best to have 16.04 match 16.10 (for easier future upgrading and minimizing delta)? Is that even
<ubottu> Debian bug 822774 in php7.0-common "Prefer libapache2-mod-php7.0" [Normal,Open] http://bugs.debian.org/822774
<nacc> an SRU-able thing (we've been affected in 16.04 already in at least one package, LP: #1577916
<ubottu> Launchpad bug 1577916 in ganglia-web (Ubuntu Xenial) "Missing dependencies" [Undecided,In progress] https://launchpad.net/bugs/1577916
<kirkland> jderose: likewise, I'm going to look at it too -- thanks so much for sending it our way!
<jderose> kirkland: no problem, and thank you very much for looking at it! we've tested that patch with "extreme paranoia" and thus far haven't found any issues... but i'm eager for any feedback you might have
<slangasek> nacc: I don't think switching php7.0's dependency ordering is something we should SRU; and more to the point, any webapp package that's broken with the current dependency is still broken if you change it, since the admin may have selected a different php alternative locally.  So anything that has a requirement on a particular sapi but doesn't specify in its dependencies has buggy dependencies
<slangasek> nacc: (I reserve the right to change my opinion on whether to accept an SRU to change the dependency order, depending on how widespread this problem appears to be; but I will stand by the claim that any affected package is buggy and should /also/ be SRUed)
<jbicha> my understanding is that php-fpm is broken without at least manual configuration but libapache2-mod-php7.0 just works out of the box
<jbicha> so I believe this affects *all* php webapps
<jbicha> we could and should release note it, we could attempt to workaround it in php7.0 itself but I think it's too much to try to SRU all affected apps individually
<slangasek> jbicha, nacc: ok, if it's the case that you can't use /any/ webapp with php-fpm without manual configuration, that's an argument for changing the dependency order (or possibly dropping it as an alternative dep altogether?)
<jbicha> yes, I unknowingly tried verifying bug 1582340 (see cmnt 4) and I had to google to figure out why drupal didn't work
<ubottu> bug 1582340 in drupal7 (Ubuntu Xenial) "[SRU] Sync drupal7 7.43-3 (universe) from Debian unstable (main)" [High,Fix committed] https://launchpad.net/bugs/1582340
<cpaelzer> good morning
<cpaelzer> stgraber: as we said in the past - if I see you online when I join it might be time for you to call it a day :-)
<pitti> jderose: this is a well-known bug by now
<pitti> jderose: ah, and you found the master bug yourself
<pitti> flexiondotorg: I just moderated your alpha-1 mail on u-d-announce@; please ping somebody after sending an announcement so that it appears timely
<seb128> pitti, hey, I see that you already did you morning SRU round, could you just have a look to libwnck? it's a no change rebuild to get translations back since it's universe
<pitti> seb128: I only did trusty this morning, not xenial :) (and I released srus)
<pitti> seb128: mostly as part of my patch piloting
<pitti> oh, forgot..
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<pitti> seb128: trivial, done
<seb128> pitti, oh, right, I saw a bunch of xenial-changes updates with your name but it's copy to -updates ... I though we didn't do that on fridays? ;-)
<pitti> oh, crap
<pitti> seb128: for some weird reason I thought "it's Thursday, so let's rather do it today than on a Friday"
 * pitti needs holidays, obviously
<pitti> sorry -- I'll check IRC and bug mail tomorrow morning
 * seb128 hugs pitti
<seb128> thanks for libwnck
<seb128> don't worry much, those were not big/risky SRUs it seems
<seb128> and it's early european friday so still plenty of hours to get feedback today
<flexiondotorg> pitti, Thanks for the mail moderation. I did request that last night in #ubunutu-release after I posted :-)
<cpaelzer> pitti: hi, was there any external trigger for your comment in bug 1546565?
<ubottu> bug 1546565 in openvswitch (Ubuntu Xenial) "Ownership/Permissions of vhost_user sockets for openvswitch-dpdk make them unusable by libvirt/qemu/kvm" [High,Triaged] https://launchpad.net/bugs/1546565
<pitti> cpaelzer: I'm patch piloting and this is sitting in the sponsoring queue
<cpaelzer> pitti: ah ok good to understand
<pitti> cpaelzer: and it's a bit confusing; dpdk is already done, there's only an openvswitch SRU patch, but no yakketypatch
<cpaelzer> pitti: ther is no debian DPDK to sned this to
<pitti> cpaelzer: no, for the openvswitch part
<cpaelzer> pitti: the debian DPDK package that is currently in the making is based on my packaging which contains the patch
<cpaelzer> pitti: ah - now I got it - the ovs part
<flexiondotorg> rbasak, I've been working on a new component for Ubuntu MATE.
<cpaelzer> pitt: you mean this then right ? https://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/commit/?id=4f6e2ca2512e298faf17b1db532625132623a628
<flexiondotorg> It is Ubuntu specific.
<flexiondotorg> The required libraries are not availabe in Debian.
<flexiondotorg> So I'd like to upload to Ubuntu only.
<flexiondotorg> rbasak, Can my packageset be extended?
<flexiondotorg> I'll file bug for the ITP in a few days when I'm ready.
<cpaelzer> pitti: I agree it is confusing - openvswitch in debian is still way too old (not dpdk compatible) so the patch makes no sense for them yet
<LocutusOfBorg> pitti, can I ask a quick test?
<pitti> cpaelzer: ah, ok
<LocutusOfBorg>  syntax error at /usr/share/perl5/Sbuild/ResolverBase.pm line 970, near "USER"
<cpaelzer> pitti: it also would require a packaged dpdk with the respective fix to be available in debian
<pitti> hey LocutusOfBorg
<LocutusOfBorg> well, missing a ","
<LocutusOfBorg> :)
<LocutusOfBorg> hi ;)
<cpaelzer> pitti: I'll try to summarize in the bug so the next one reading it knows
<pitti> LocutusOfBorg: oh, I see it
<cpaelzer> pitti: your request to submit to debian is correct as soon as they have adpdk package and openvswitch >=2.5
<cpaelzer> pitti: which is both coming somewhen this year
<pitti> LocutusOfBorg: testing again
<LocutusOfBorg> works for me
<LocutusOfBorg> I can upload if you agree
<pitti> LocutusOfBorg: yes, works fine now; upload away
<LocutusOfBorg> you upload or me? :)
<pitti> LocutusOfBorg: please do
<LocutusOfBorg> done thanks!
<LocutusOfBorg> thanks for double checking, thanks for making me setup an sbuild chroot, I'll use it a lot I presume :)
<LocutusOfBorg> I'm more a pbuilder guy, but I know I'll have to switch one day :)
<pitti> haha
<pitti> LocutusOfBorg: mk-sbuild is pretty great
<Unit193> pbuilder is activly maintained.
<pitti> the only annoying thing is that one has to edit the generated config a bit for --type=file, but other than that mk-sbuild DTRT
<LocutusOfBorg> pbuilder-dist is so far the easier
<ricotz> pitti, hi, could you reject and remove this package from xenial proposed? -- https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-361/361.45.11-0ubuntu0.16.04.1
<ricotz> https://bugs.launchpad.net/snappy/+bug/1588192/comments/31
<ubottu> Launchpad bug 1588192 in nvidia-graphics-drivers-304 (Ubuntu Xenial) "GL interfaces seem wedged for Krita on nvidia" [Critical,In progress]
<pitti> ricotz: sure
<ricotz> pitti, thanks, tseliot ^
<pitti> cpaelzer: bug 1524526 is also confusing for me
<ubottu> bug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/1524526
<pitti> cpaelzer: so does the merge apply to yakkety, and the "rebuild only" patch (which says yakkety) shoudl be for xenial?
<pitti> cpaelzer: and the dovecot tasks shoudl be invalid?
<doko> LocutusOfBorg, any update on the virtualbox SRU?
<tseliot> ricotz, pitti: thanks!
<LocutusOfBorg> doko, what should I do? upload and see it on queue for months?
<LocutusOfBorg> I can do, but I need to also upload virtualbox-guest-additions-iso and virtualbox-ext-pack
<LocutusOfBorg> and I'm uploading them right now in my ppa
<LocutusOfBorg> at least I uploaded them some minutes ago
<LocutusOfBorg> I had to add a -2, because the debhelper in trusty is not aware of dbg-migration
<doko> LocutusOfBorg, did you SRU virtualbox in the past?
<doko> I mean, new upstream versions?
<LocutusOfBorg> yes, as security upload
<LocutusOfBorg> and I have two virtualbox pending in queue since... who remembers?
<LocutusOfBorg> https://launchpad.net/ubuntu/trusty/+queue
<LocutusOfBorg> oh yeah, months
<doko> ok, I'll fix the ftbfs for now in the current version
<LocutusOfBorg> as you wish
<LocutusOfBorg> I plan to SRU it to new releases, but not right now, I'm not enough confident
<ricotz> doko, hi, is defaulting to gcc-6 happening soon?
<rbasak> flexiondotorg: yes - email devel-permissions with details. I believe it just needs one +1 from a DMB member to check that the requested package meets the packageset description and so it can be added without a meeting.
<flexiondotorg> rbasak, Thanks. Will do.
<rbasak> nacc: for bacula I'd prefer to fix the multiple bugs in a single upload if possible, unless it'll be a while to resolve that way and an immediate fix would be more helpful. Are we ready for that yet?
<rbasak> nacc: (and also in a single SRU)
<doko> ricotz, not yet determined. probably end of July
<ricotz> doko, alright
<LocutusOfBorg> sbuild migrated, the testsuite should be buggy
<LocutusOfBorg> or my merge was good...
<Odd_Bloke> Hmm, we're seeing cloud image build failures that I think are caused by the e2fsprogs that just synced to yakkety.
<Odd_Bloke> Specifically on armhf and powerpc.
<Odd_Bloke> But I don't have a good way of testing anything on those architectures; can anyone suggest how I might do so?
<Odd_Bloke> (The error I see is http://paste.ubuntu.com/18226469/ which I wasn't getting yesterday, and don't see on 64-bit or Intel arches)
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> mwhudson: there's still something wrong with the docker test: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/d/docker.io/20160630_230250@/log.gz
<pitti> mwhudson:  just the warning on stderr
<doko> jamespage, will you fix migrate in xenial as well?
<LocutusOfBorg> any core-dev around for a quick llvm-toolchain-3.8 upload^
<pitti> LocutusOfBorg: debdiff?
<LocutusOfBorg> http://paste.ubuntu.com/18229738/
<LocutusOfBorg> between the current ubuntu proposed version
<LocutusOfBorg> the -2 is going in unstable in a few minutes, I grabbed from svn :)
<pitti> patching file debian/rules
<pitti> patch unexpectedly ends in middle of line
<pitti> Hunk #1 succeeded at 240 with fuzz 1.
<pitti> meh
<pitti> go pastebin
<pitti> +update-maintaner
<LocutusOfBorg> mail :)
<pitti> LocutusOfBorg: no, it's ok, final verification and about to upload
<LocutusOfBorg> oh... ok!
<pitti> LocutusOfBorg: done
<LocutusOfBorg> you were faster than my ppa :D
<LocutusOfBorg> thanks!
<LocutusOfBorg> btw congrats for the systemd sync
<pitti> LocutusOfBorg: err, thanks; anything you were waiting for in particular?
<pitti> LocutusOfBorg: it's autosynced, so I didn't have much to do with it :)
<LocutusOfBorg> xnox, a new btrfs-progs nmu :( #829205
<pitti> oh, you mean *getting* it syncable? thanks
<LocutusOfBorg> ^^ this one
<LocutusOfBorg> :)
<pitti> yeah, was some work and tech debt cleanup, but totally worth it
<pitti> after all, reducing pointless difference between distros is one of its goals :)
<LocutusOfBorg> :D and also *my* goals ;)
<pitti> I got init-system-helpers syncable too, although with one substvars (so a bit cheating)
<LocutusOfBorg> did you see my pbuilder sync?
<pitti> LocutusOfBorg: since xenial already, right? that's great too
<LocutusOfBorg> https://sources.debian.net/src/pbuilder/0.225.1/debian/rules/
<pitti> I wish we could sync sbuild oto, but not quite
<LocutusOfBorg> this is cheating
<LocutusOfBorg> :p
<pitti> haha
<LocutusOfBorg> 	sed "s/#DISTRIBUTION=sid/DISTRIBUTION=yakkety/" -i pbuilderrc
<LocutusOfBorg> terrible mapreri is terrible!
<LocutusOfBorg> fortunately he uploads a lot
<LocutusOfBorg> :p
<Odd_Bloke> mdeslaur: o/ I noticed that you sync'd e2fsprogs from Debian the other day; I think we've started seeing https://bugs.launchpad.net/cloud-images/+bug/1598136 as a result of that.
<ubottu> Launchpad bug 1598136 in cloud-images "Fails to produce a loop-mountable FS on powerpc/armhf" [Critical,New]
<jamespage> doko, yes - on my list
<doko> ta
<Odd_Bloke> mdeslaur: (I guess I'm most interested in whether the "Use the autotools-dev dh addon to update config.guess/config.sub for new ports." changes should have been dropped on sync :)
<mapreri> LocutusOfBorg: *g*
<cjwatson> Odd_Bloke: Do you know why https://cloud-images.ubuntu.com/xenial/ hasn't had a new daily build for a few days?  I was hoping to check to see if my live-build fix worked.
<Odd_Bloke> cjwatson: Ah, we disabled the automatic triggers during a CVE run, and missed xenial when turning them back on.
<Odd_Bloke> cjwatson: Turned back on, and build kicked off.
<Odd_Bloke> Apologies for the delay!
<cjwatson> Odd_Bloke: cool, thanks!
<doko> LocutusOfBorg, can't find your virtualbox paste / message anymore. could you repaste it?
<LocutusOfBorg> replying on the bug itself
<doko> already have it
<LocutusOfBorg> oops
<LocutusOfBorg> cjwatson, any idea about llvm-toolchain-3.8 on z13-009?
<LocutusOfBorg> it seems stuck in a stupid place
<LocutusOfBorg> seems uploading now
<pitti> LocutusOfBorg: looks fine to me; uploading can take two or three minutes, it's a big package
<LocutusOfBorg> pitti, yesterday llvm-3.8 got stuck on arm64 for ~20 hours
<LocutusOfBorg> ginggs, had to retry the build
<LocutusOfBorg> BTW it wasn't stuck in "Uploading" but in "build finished"
<LocutusOfBorg> anyway, glad it wasn't stuck
<LocutusOfBorg> pitti, give back i386? :(
<pitti> /usr/bin/ld.gold: out of memory
<pitti> collect2: error: ld returned 1 exit status
<pitti> hmm -- not sure if that will help, aren't these buildds all the same these days?
<LocutusOfBorg> maybe they needs some cleanup?
<pitti> that might need some special handling by infinity or so, to route it to some bigger iron?
<LocutusOfBorg> or maybe retrying will make it be picked up by another builder machine?
<LocutusOfBorg> with some extra space/memory?
<LocutusOfBorg> don't know
<cjwatson> No
<cjwatson> They're all the same, and they're reset from a VM image every time
<LocutusOfBorg> mmm how did it succeed yesterday and failed today
<pitti> new upstream version
<LocutusOfBorg> no
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8.1-1ubuntu1/+build/10188620
<pitti> ah, actually not
<LocutusOfBorg> this one is good, and is on 3.8.1
<cjwatson> Lots of builds are a little bit nondeterministic in ways that don't usually matter
<cjwatson> Especially when parallel builds are involved
<pitti> so, *shrug*, we don't have a queue ATM, I can retry it once
<LocutusOfBorg> :(
<LocutusOfBorg> and the situation will go worse
<pitti> except lcy builders seem to have gone into the weekend already :)
 * pitti checks his autopkgtest minions
<cjwatson> I'll try resetting them
<pitti> seems to WFM
<pitti> cjwatson: my current approach with dealing with our flaky clouds is: (1) in case of a temporary failure, wait 5 mins and try again; (2) after three tmpfails in a row, kill the worker process; (3) every 6 hours, clean up orphaned instances and restart all workers
<pitti> this seems to work well enough with "oh crap our cloud broke" downtimes without needing manual intervention
<pitti> the "phoenix" cron job :)
<pitti> where a tmpfail is stuff like "nova boot failed/timed out" or "timed out waiting for ssh"
<ackk> hi, packaging question about systemd config files. I have a python app I'm trying to package. the package.service file gets correctly included, but package.socket isn't by default. is there something I need to set to get it included? or should I do it manually?
<jrwren> what is package.socket?
<jrwren> is it actually a socket file?
<pitti> supposedly a systemd unit file that defines a socket (man systemd.socket)
<ackk> jrwren, what pitti said
<ackk> for socket service activation
<jrwren> ok, sorry. I don't know about that. I do know we packaged a python app and didn't include this socket
<LocutusOfBorg> today I did some sdnotify from java to systemd, with a keepalive watchdog notify method :)
<LocutusOfBorg> I'm always impressed by systemd
<jrwren> +1 i'm very happy with systemd
<LocutusOfBorg> in automotive and embedded systems is a must
<LocutusOfBorg> :)
<LocutusOfBorg> boot time < 2 sec
<LocutusOfBorg> but lets stop talking about systemd
<cjwatson> ackk: dh_installinit installs service files by default but not socket files.  Just install it with dh_install or whatever.
<cjwatson> (see their manual pages)
<ackk> cjwatson, I see, thanks
<cjwatson> Oh, actually, I think dh_systemd_enable installs them automatically these days.
<pitti> worth a bug report, if that's a common case
<cjwatson> Are you using --with=systemd?
<pitti> ah right, it does now
<pitti> mount path service socket target tmpfile
<slangasek> pitti: hi, you rejected the grub2 upload because it doesn't include the 2.02~beta2-9ubuntu1.9 upload, but that upload was withdrawn
<pitti> slangasek: oh, ok; dropping the call to update-secureboot-policy looked wrong to me, as all the other SRUs *added* that call
<pitti> so if this is deliberate, I can review/accept it from the rejected queue
<slangasek> pitti: the SRUs that added that call have all been dropped, yes
<slangasek> so I guess LP still gave you a diff against a version of the package no longer in the archive :)
<pitti> accepted and bug updated
<slangasek> pitti: thanks :)
<pitti> yes, it's usually against the most recent upload, not the most recent published version
<pitti> which is actually a good thing in most cases
<bdrung_work> infinity, https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1598212
<ubottu> Launchpad bug 1598212 in base-files (Ubuntu) "/etc/os-release: Please specify VERSION_CODENAME" [Undecided,New]
<bdrung_work> you did the last merge
<infinity> bdrung_work: Will look after I get to Cape Town.
<pitti> ^ commented on the bug
<bdrung_work> pitti, valid point
<slangasek> pitti: jinx
<pitti> :)
<infinity> pitti: "the other day" being November? :)
<pitti> infinity: sounds about right
<slangasek> snappy wasn't using os-release until last month, fwiw ;)
<infinity> slangasek: Sure, but he added it in Nov. :P
<slangasek> yes
<slangasek> but him adding it and snappy using it may be unconnected
<nacc> rbasak: yes, they are all fixed in one upload right now ... i'm still waiting for testing results, so we can hold off, that' sok
<nacc> rbasak: in my testing, the fixes work for both cases, but I'm not an active user, so I'd like a 3rd party confirmation
<nacc> rbasak: assuming you're not around, but have a mysql question for you, if you are
<nacc> rbasak: nm, figured it out
<slangasek> I: Base system installed successfully.
<slangasek> cp: '/etc/localtime' and '/var/lib/schroot/chroots/xenial-ppc64el/etc/localtime' are the same file
<slangasek> ok wut
<slangasek> ah, bug #1569400
<ubottu> bug 1569400 in ubuntu-dev-tools (Ubuntu) "mk-sbuild fails with cp: /etc/localtime... are the same file" [Undecided,Fix released] https://launchpad.net/bugs/1569400
<slangasek> infinity: you have u-d-t sitting in -proposed awaiting verification on bug #1579619 for 52 days, and requires an arm64 system. do you have one of those handy?  I would also like to fix bug #1569400
<ubottu> bug 1579619 in ubuntu-dev-tools (Ubuntu Xenial) "[mk-sbuild] treats armhf as foreign to arm64" [Undecided,Fix committed] https://launchpad.net/bugs/1579619
<ubottu> bug 1569400 in ubuntu-dev-tools (Ubuntu) "mk-sbuild fails with cp: /etc/localtime... are the same file" [Undecided,Fix released] https://launchpad.net/bugs/1569400
<nacc> slangasek: trying to figure out this php-horde-activesync issue. We fixed a similar issue in php-horde-db by updating the SQL configs to have a password for root and setting that password in the debian/tests/phpunit file. I have done that with php-horde-activesync as well, but when it runs via adt-run, it fails (same error). If I pass -s so adt-run drops to a shell, and immediately run
<nacc> ./debian/tests/phpunit, it passes. Any idea what is going on or how to debug?
<slangasek> nacc: what's your full adt-run commandline in each case, and can I see your debdiff?
<nacc> slangasek: yeah, one sec
<nacc> slangasek: debdiff: http://paste.ubuntu.com/18259801/
<nacc> slangasek: adt-run -U --setup-command='apt-get update' php-horde-activesync_2.34.0-1ubuntu1.dsc -s --- adt-virt-lxd adt-yakkety
<slangasek> nacc: so the only difference between the adt-run invocations was the '-s'?
<nacc> well, i mean it fails either way; but -s just lets it drops to a shell
<nacc> slangasek: sorry, that was unclear before
<slangasek> nacc: ah; so you get a shell, you run ./debian/tests/phpunit, it passes; you exit the shell, adt-run runs the tests, it fails?
<nacc> slangasek: yeah, to be clear, i'm dropped to the shell because adt-run already failed with the prior error ("ERROR 1698 (28000): Access denied for user 'root'@'localhost'")
<slangasek> huh
<nacc> slangasek: i am at a loss on how to debug it, right now, as it seems like it *should* work (esp. given that php-horde-db works)
<slangasek> nacc: yeah, I don't have an explanation for this
<slangasek> I particularly don't see any reason the automated test would fail, but manually running it would succeed
<nacc> slangasek: np, i'll keep digging; yeah, that's the confusing part to me :)
<nacc> slangasek: i might have found it, the tests might 'needs-root'  now
<slangasek> ah
<nacc> slangasek: was just comparing against the php-horde-db d/t/control
<nacc> slangasek: is simply stating it fixes the autopkgtests a sufficient SRU impact? it's a no-op to the code itself, just fixes the packaging, essentially
<nacc> slangasek: i submitted it as such anyways, we'll see :)
<slangasek> nacc: yes, that's sufficient for me
<nacc> slangasek: i did have a more relevant question for you, we've had two SRU 'regression' bugs come through for php7.0 so far (LP: #1597597 and LP: #1598166). They are both debconf issues, though, and I don't see how they are related to php7.0 itself (and jbicha has marked one a dupe of another bug showing the same issue). Have you seen anything like it?
<ubottu> Launchpad bug 1567291 in debconf (Ubuntu) "duplicate for #1597597 package phpmyadmin 4:4.4.13.1-1 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 128" [Undecided,Confirmed] https://launchpad.net/bugs/1567291
<ubottu> Launchpad bug 1598166 in php7.0 (Ubuntu) "package php7.0-fpm 7.0.8-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,New] https://launchpad.net/bugs/1598166
<hallyn> hm, are ppa builders having issues?
<hallyn> https://launchpad.net/~ubuntu-virt/+archive/ubuntu/ppa/+build/10307662/+files/buildlog_ubuntu-trusty-ppc64el.qemu_2.0.0+dfsg-2ubuntu1.25~ppa1_BUILDING.txt.gz
<hallyn> /Â«BUILDDIRÂ»/qemu-2.0.0+dfsg/fpu/softfloat.c:4272:1: internal compiler error: Segmentation fault
<cjwatson> hallyn: our ppc64el guests unfortunately have very occasional random corruption - just retry
<hallyn> ok thx
<slangasek> yeah, if only those guests running on top of qemu were stable so that you could build qemu?
<slangasek> yo dawg I heard you like virtualization
<slangasek> nacc: 128 is not a typical debconf failure exit code, fwiw
<nacc> slangasek: true, i think it's actually a perl failure, but not sure
<slangasek> nacc: I do think it's clearly not an SRU regression, given the output - where was this being tagged as a regression?
<nacc> slangasek: LP: #1569128
<ubottu> Launchpad bug 1569128 in phpmyadmin (Ubuntu Xenial) "php7.0-common provides incompatible php-gettext [16.04 Xenial]" [Undecided,New] https://launchpad.net/bugs/1569128
<slangasek> ah
<slangasek> ok, bug state mangled
<nacc> slangasek: thanks for confirming
<nacc> slangasek: re; php-horde-activesync, i've also sent the same to debian, so we hopefully will be able to sync again in 16.10 shortly
 * slangasek nods
 * nacc has finally learned to just do that right away :)
<slangasek> nacc: uploaded, thanks!
<nacc> slangasek: thank you!
#ubuntu-devel 2016-07-02
<jkazuo55> join
<jkazuo55> hi
<infinity> slangasek: Oh, derp, I totally forgot that was sitting there.  I can validate when I settle in CPT (in JHB right now), or I can reupload with both cherrypicks instead of just the one.
<LocutusOfBorg> mdeslaur, hi, you there?
<LocutusOfBorg> mdeslaur, I would like to ask your opinion (or anybody else) wrt steam package
<LocutusOfBorg> seems that now Debian has a steam package providing the udev rules in a steam-devices  package
<LocutusOfBorg> I would like to mostly force sync
<LocutusOfBorg> well, lets open a bug and subscribe you :)
<LocutusOfBorg> there was already an lp: #1591216
<ubottu> Launchpad bug 1591216 in steam (Ubuntu) "Update to 1.0.0.52 / Merge from Debian" [Undecided,Confirmed] https://launchpad.net/bugs/1591216
#ubuntu-devel 2017-06-26
<elky> CasW: https://launchpad.net/hundredpapercuts but i don't know if it's actually active anymore
<CasW> Thanks a lot!
<fnordahl> I have prepared patches that cherry pick restart on configuration changes fix for rsyslog from Debian to Artful in LP 1668639.
<ubottu> Launchpad bug 1668639 in rsyslog (Ubuntu Artful) "Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d" [Medium,New] https://launchpad.net/bugs/1668639
<fnordahl> Would anyone have a moment to review the patch?
<mwhudson> uh what's the story with libssl1.0.2 and ubuntu?
<mwhudson> https://launchpad.net/ubuntu/+source/pyelliptic/1.5.7-1.1 is depwait now, wondering if we should revert the commit or just wait
<mwhudson> and what the heck is going on here, https://launchpadlibrarian.net/325564633/buildlog_ubuntu-artful-amd64.paste_1.7.5.1-6ubuntu3_BUILDING.txt.gz "dpkg-genbuildinfo: error: cannot fstat file ../python-paste_1.7.5.1-6ubuntu3_all.deb: No such file or directory"
<geser> mwhudson: "dpkg-deb: error: obsolete compression type 'bzip2'; use xz or gzip instead" and as consequence "dh_builddeb.pkgbinarymangler: dpkg-deb -Z bzip2 --build debian/python-paste .. returned exit code 2"
<infinity> mwhudson: We seem to be 3 years behind on merging paste for some reason.
 * infinity wonders if the reason is him.
<infinity> mwhudson: New paste uploaded.
<rbasak> cpaelzer: OK, caught up.
<rbasak> Oh, wrong channel.
<mwhudson> geser: oh i thought that thing about bzip2 was just a warning
<mwhudson> infinity: thanks
<mwhudson> FAIL: test_Headbanging_Median_Rate_tabular
<mwhudson> i think this means i should go to bed
<ricotz> mapreri, hi :), could you look into syncing rustc/cargo?
<mapreri> hold on, writing a mail
<LocutusOfBorg> ricotz, can I do it?
<ricotz> LocutusOfBorg, I assume chrisccoulson might have a thought too
<LocutusOfBorg>  /tmp/cargo_0.17.0.orig-vendor.tar.gz has size 6526779 instead of expected 5023852
<LocutusOfBorg> bad people out there, sigh
<ricotz> chrisccoulson, I guess eventually firefox will require 1.17
<mapreri> cargo can't be synced
<mapreri> afaik
<ricotz> mapreri, maybe, but cargo should be sufficient for rustc 1.17 already anyway
<mapreri> it embeds a libgit2 that doko very much don't want to have embedded.
<mapreri> OTOH, probably that embedded lib can go away on the debian side now
<ricotz> ah I see
<mapreri> [02:48:51 PM] <mapreri> infinity0: can cargo stop embedding libgit2 now?
<mapreri> [02:49:02 PM] <infinity0> yeah i'll do that tomorrow hopefully
<mapreri> rustc should be free to go, so syncing that.
<ricotz> when was that?
<ricotz> thanks!
<mapreri> right now :)
<ricotz> good :)
<LocutusOfBorg> please don't use rustc 1.18
<LocutusOfBorg> and forward that to debian folks
<LocutusOfBorg> You are receiving this email because I have you listed as a downstream Rust packager.
<LocutusOfBorg> There is a bug in Rust 1.18 that prevents bootstrapping from a local toolchain, and it has affected multiple packagers:
<LocutusOfBorg> https://github.com/rust-lang/rust/issues/42543
<LocutusOfBorg> Fix is in progress. Sorry for the delayed response. If you want to discuss, please do so on the linked issue.
<mapreri> well, this is 1.17
<mapreri> LocutusOfBorg: please talk about that with the debian folks :)
<LocutusOfBorg> mapreri, done a few seconds ago
<LocutusOfBorg> but I would like to avoid somebody "hey lets do 1.18 in Ubuntu as delta"
<mapreri> ricotz: you asked for it, and I forgot to checkâ¦  are you aware it ftbfs on ppc64el?
<ricotz> mapreri, haven't check for ftbfs, just want to draw some attention to get it updated
<ricotz> mozilla kind of requires 1.17 it already
<mapreri> well, infinity0 seems aware, the last upload was a debugging one
<mapreri> I suppose he would appreciate help trying to fix it :P
<ricotz> ok
<zyga> jdstrand: hey
<zyga> jdstrand: cannot unmount preserved mount namespace file /run/snapd/ns/snapd-hacker-toolbelt.mnt: Permission denied
<zyga> jdstrand: cze 26 14:33:03 fyke kernel: audit: type=1400 audit(1498483983.583:116): apparmor="DENIED" operation="umount" profile="/usr/lib/snapd/snap-confine" name="/" pid=6500 comm="snap-confine"
<zyga> jdstrand: note the name that makes no sense and mismatches what was attempted
<zyga> jdstrand: this is after hopping into a namespace and then hopping out of it (via setns)
<zyga> jdstrand: I think this confuses apparmor
<zyga> CC jjohansen ^
<jdstrand> zyga: if this is after a pivot_root, I think that is correct. but, yes, jjohansen would be the person to talk to
<smoser> sil2100, around ?
<smoser> i guess you had pinged me with regard to https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1697545
<ubottu> Launchpad bug 1697545 in curtin (Ubuntu Xenial) "sru curtin 2017-06-12 - 0.1.0~bzr505-0ubuntu1" [Medium,Confirmed]
<smoser> the change in debian/new-upstream-snapshot does not at all affect the running code and should not block its acceptance into xenial.
<smoser> (i'm guessing thats why you didn't accept xenial when you did accept yakkety)
<cpaelzer> I face two launchpad git based build recipes - one works and the other one asks me for user on https://git.launchpad.net
<cjwatson> did you try to use a private repository?
<cpaelzer> cjwatson: no all public on my lp user
<cjwatson> links please
<sil2100> smoser: hey! Thanks for the info, I think there was some other reason for that, need to remember now what that is!
<cpaelzer> cjwatson: working http://paste.ubuntu.com/24956449/ failing http://paste.ubuntu.com/24956448/
<sil2100> smoser: since I was pretty sure I did accept it
<cpaelzer> I beg your pardon this is my first recipe, so it might suffer from all baby steps you can do
<sil2100> Let me do a quick re-review
<cjwatson> cpaelzer: https://git.launchpad.net/~paelzer/libvirt/+git/libvirt-daily either doesn't exist or is private
<smoser> sil2100, fwiw, the delta from -updates to the uploaded version should be identical for yakkety and xenial
<cjwatson> cpaelzer: looks like you put it in https://code.launchpad.net/~paelzer/qemu/+git/libvirt-daily by mistake
<sil2100> hm, why didn't this get approved, it seems all fine
<cjwatson> cpaelzer: so "change details" there and move it to the right project?
<cjwatson> cpaelzer: (and change any local clones to have the correct remote)
<cpaelzer> cjwatson: thanks will look into that repo confusion
<smoser> sil2100, all i know is you had asked me a question about the new-upstream-snapshot.  i'mi sorry. i was on holiday last week, so i'm a bit behind.
<smoser> away
<sil2100> smoser: approved now, sorry about this - I either forgot to press the final button or something, I really don't remember considering this new-upstream-snapshot being a blocker
<smoser> sil2100, thanks!
<cpaelzer> cjwatson: of course that was it - thanks, now I'm in the land of build errors that I expected I have to fix
<cjwatson> np
<rbasak> xnox: if you're working on it, can you assign yourself and set to In Progress bug 1700373 please?
<ubottu> bug 1700373 in intel-microcode (Ubuntu Zesty) "Please update microcode to version 20170511 on all supported platforms" [Undecided,Confirmed] https://launchpad.net/bugs/1700373
<bdmurray> pitti: Why was 1000000 chosen as a number here for a core file to be expected? http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/test/test_signal_crashes.py#L18
<bdmurray> pitti: I ask as it doesn't seem to be working - ERROR: apport (pid 12199) Mon Jun 26 08:22:55 2017: aborting core dump writing, size exceeds current limit 1000000
<bdmurray> pitti: or rather the core file created is greater than 1000000 bytes.
<ricotz> LocutusOfBorg, mapreri, while there is a delta for cargo already is it possible to update it to 1.18.0?
<jjohansen> zyga, jdstrand: it may appear that way, but apparmor is not confused. You are seeing artifacts of how the vfs handles these. If the file was opened inside of one namespace, and you switch to another, that file is disconnected
<jjohansen> so a file opened in the "child" namespace is disconnected when returning to the original ns
<jdstrand> and then attach_disconnected put it at '
<jdstrand> at '/'
<sarnold> which is why attach_disconnected is so frustratingly terrible
<gpiccoli> hi folks, sorry to bother. Anybody here can point me a Git repo for Ubuntu systemd?
<gpiccoli> I'd like to know if there's a repo somewhat equivalent of Ubuntu's kernel gits
<sarnold> nacc: do you have systemd in you track-all-the-things git repos?
<gpiccoli> Thanks in advance
<gpiccoli> track-all-the-things...seems nifty =O
<nacc> sarnold: https://code.launchpad.net/~usd-import-team/ubuntu/+source/systemd/+git/systemd
<sarnold> nacc: wow the branches so many branches :)
<nacc> sarnold: yeah :)
<nacc> sarnold: one for every release+pocket * 2 for patches-applied and patches-unapplied
<gpiccoli> tnx sarnold and nacc
<nacc> sarnold: with some extras for the importer itself (importer/) and then the 'always latest' ubuntu/devel
<nacc> gpiccoli: to be clear, this is more like a mirror of the archive than it is where active development necessarily occurs
<nacc> gpiccoli: it can be the latter, but no one is obligated to use it as such
<nacc> gpiccoli: it reflects exactly what is uploaded for each upload, and provides history
<gpiccoli> yes, that's exactly what I need naac
<nacc> gpiccoli: cool
<gpiccoli> Will check if some patches aren't applied yet, to request backport
<nacc> gpiccoli: since systemd is a native package, i think every import/ and applied/ will be identical
<gpiccoli> that's cool to hear
<gpiccoli> tnx
<nacc> gpiccoli: i would run `quilt push -a` to be sure, though :) ... and if something looks off, please file a bug (https://bugs.launchpad.net/usd-importer)
<gpiccoli> ok, thanks a lot nacc! =D
<nacc> gpiccoli: yw
<gpiccoli> nacc, sorryto annoy more, but I'm having trouble to figure which systemd commits were applied from the repo
<gpiccoli> is it a "meta-repo", that deals with histories and lists of patch applied, instead of the patches themselves?
<gpiccoli> I'd like to check if a patch is on systemd 229
<nacc> gpiccoli: right, it's just reflecting hte source packages as uploaded
<nacc> gpiccoli: let me look in detail on this one
<gpiccoli> ok naac, thanks and sorry for the annoyance
<nacc> gpiccoli: which specific systemd pkg version? and which patch?
<gpiccoli> systemd 229, from Xenial naac. Let me paste the patch info here
<nacc> gpiccoli: systemd is at 229-4ubuntu4, 4ubuntu10 or 4ubuntu17 depending on the pocket
<nacc> (release, security, updates respectively)
<gpiccoli> hmm...what are the differences nacc?
<gpiccoli> my version is the 17
<gpiccoli> 229-ubuntu17
<gpiccoli> There are 3 commits I'm interested in: https://github.com/systemd/systemd/commit/427a28e
<gpiccoli> a5110c9
<gpiccoli> b4c6f71
<gpiccoli> the 3 are related to nvme devs
<nacc> gpiccoli: e.g., you can do `git diff import/229-4ubuntu4 import/229-4ubuntu10` in your systemd repo clone to see the differences
<nacc> gpiccoli: so to see if they are in the 'latest' xenila, you can do `git checkout <remote name (origin)>/ubuntu/xenial-devel`
<gpiccoli> ok, thanks nacc
<nacc> gpiccoli: and then do `quilt push -a` to push all the quilt patches
<gpiccoli> but for example, in Ubuntu kernel repo, I can check the commits backported to Ubuntu kernel
<gpiccoli> In 4.4.0-73, if I want. So, I can say if something need to go in or not...is there a quick way to do it for systemd?
<nacc> gpiccoli: look at the source to see if the patches are applied?
<gpiccoli> yes, this is the hard way nacc hehehe
<gpiccoli> I'll take it, tnx
<gpiccoli> Git are easier in general...
<gpiccoli> *Gits
<nacc> gpiccoli: it would appear the first two are present, but not he third
<gpiccoli> that's really great nacc, thanks a lot
<gpiccoli> So I might request the backport for https://github.com/systemd/systemd/commit/b4c6f71
<sarnold> bdmurray: https://launchpadlibrarian.net/325392048/term.log  "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable" *2 when trying to install openssl packages
<bdmurray> sarnold: what bug number is that related to?
<sarnold> bdmurray: 1692981
<bdmurray> sarnold: Hmm, I meant which bug is that attachment from?
<sarnold> bdmurray: the "openssl breaks updates forever" one
<bdmurray> sarnold: right but the term.log file you linked to is from which bug number? Its not clear from the librarian url.
<sarnold> bdmurray: ah. I duped all the openssl bugs to 1692981. I don't know how to get to just alister's version of the bug.
<sarnold> bdmurray: oh hey the advanced search has a button to show dupes :) alister's bug is https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1697801
<ubottu> Launchpad bug 1692981 in openssl (Ubuntu) "duplicate for #1697801 package libssl-dev:amd64 1.0.2g-1ubuntu11.2 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration" [Undecided,Confirmed]
#ubuntu-devel 2017-06-27
 * mwhudson bangs head on desk
<mwhudson> has something changed in binutils recently (or possibly not recently) wrt preferring to emit dt_runpath over dt_rpath
<pitti> bdmurray: it certainly used to work; I can't imagine that crashing /usr/bin/yes leaves a > 1 MB core file behind now??
<infinity> pitti: It was rewritten in Go.
<pitti> I'm sure a complex program like yes can benefit greatly from that
<infinity> pitti: It's also now a symlink to /usr/bin/maybe
<seb128> good morning desktopers
<tsimonq2> But what if I'm a serverer *and* a desktoper? :P
 * tsimonq2 obviously needs more sleep and exits left
<pitti> bonjour seb128 !
<seb128> hey pitti! wie gehts?
<LocutusOfBorg> pitti, <3
<pitti> seb128: gut, danke! greetings from Karlsruhe, we have a hackfest this week
<seb128> pitti, ah, nice, greetings toward Karlsruhe then :-)
<cpaelzer> hmm - on package versioning the ~ is nice to stay below something, but what is the trick to stay above in any case?
<cpaelzer> the version has to start numeric
<pitti> cpaelzer: how do you mean exactly?
<cpaelzer> so starting with 99- seems ugly but does the trick for quite a while
<cpaelzer> I wonder if there is a better thing
<cpaelzer> pitti: I think about creating some daily builds of packages
<cpaelzer> in a ppa
<cpaelzer> but I'd like them to be fully automated and preferred to whatever is current if the ppa is enabled
<rbasak> I don't force a "stay above" in my PPA versioning. If the archive carries the same version, it's fine for the archive to "win" IMHO.
<cpaelzer> manually modifying versions is against the automation thought
<cpaelzer> but 99-* is so ugly
<rbasak> You could use an epoch I suppose.
<cpaelzer> uh yeah
<cpaelzer> that was the <numb>: starter right?
<rbasak> Yeah. Normally we avoid those, but that's in the archive. In a PPA, you're basically asking for exactly what they do - a bump beyond anything else.
<cpaelzer> yep
<cpaelzer> ok thanks that will do for sure
<cpaelzer> but maybe there is an even better way
<rbasak> The issue is that you'll need user intervention to go back to the archive version, but I think you're asking for that exactly.
<rbasak> Apt pinning might be another option maybe?
<cpaelzer> can I somehow ignore my changelog and generate the version from source?
<rbasak> You can ask apt to score the PPA higher even for a lower version I think.
<xnox> is debconf broken in zesty? https://launchpadlibrarian.net/324836850/DpkgTerminalLog.txt
<xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1699360
<ubottu> Launchpad bug 1699360 in systemd (Ubuntu) "package libpam-systemd:amd64 232-21ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,Confirmed]
<xnox> or is it systemd?
<cpaelzer> xnox: known bugs (plenty of)
<cpaelzer> wait there is one to dup to
<cpaelzer> oh that might already be it
<cpaelzer> xnox: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1679435 ?
<ubottu> Launchpad bug 1679435 in gnome-software (Ubuntu Zesty) "GNOME Software fails to install .deb packages that trigger debconf prompts" [High,Fix committed]
<cpaelzer> yet it is supposed to be fixed now
<cpaelzer> there is also an older incarnation https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/442941
<ubottu> Launchpad bug 442941 in ubiquity (Ubuntu Oneiric) "debconf failed to upgrade from 1.5.27ubuntu1 to 1.5.27ubuntu2: exit status 128 - Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66" [High,Fix released]
<jbicha> xnox: gnome-software/zesty got stuck in phased-updates so there are several bugs that still affect people that were fixed 2 months ago :(
<xnox> jbicha, yeah, it looks like installation is done via aptdaemon with passthrough.
<xnox> I guess https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1688721 ?!
<ubottu> Launchpad bug 1688721 in gnome-software (Ubuntu Zesty) "Packages that trigger multiple debconf prompts fail to install" [High,Fix committed]
<cpaelzer> pitti: rbasak: even after the epoch I need a number again :-/
<cpaelzer> I thought I could get away with something like 2:daily-201706270956-054914f
<cpaelzer> I can insert a random number, but is there a way to even insert a real number generated fomr e.g. the source?
<cpaelzer> note: in LP recipe
<rbasak> cpaelzer: I'm not sure I follow. What does your recipe say right now?
<cpaelzer> rbasak: # git-build-recipe format 0.4 deb-version 2:daily-{time}-{git-commit}
<cpaelzer> which would have given me ahead of archive (due to epoch) but clearly daily on time+commit hash
<cpaelzer> but it wants a numeric after the colon
<cpaelzer> I might go with 2:0
<cpaelzer> that way it surely is below any other 2: if one ever exists
<rbasak> Yeah
<cpaelzer> but what I meant before is if the build recipes could do ynthing like the following
<rbasak> Or 0~ or 0~~ - depends on how far you want to go :-)
<cpaelzer> # git-build-recipe format 0.4 deb-version 2:$(get from VERSIONS file)-daily-{time}-{git-commit}
<cpaelzer> this doesn't hold anything that seems to solve this for me https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Version_numbers_and_substitution_variables
<rbasak> I still don't really follow why you need this.
<cpaelzer> if I want to build a daily ppa from an upstream that changes versions but I don't want to touch the debian/changelog that is merged into the build as part of the LP recipe
<rbasak> I see
<cpaelzer> if upstream goes version 3->4, then I can't find a way in the recipe to pick that up - which is why I chose to "stay ahead for sure"
<rbasak> Perhaps a feature request for git-build-recipe is in order? Though I don't know about the status of executing arbitrary code on Launchpad.
<rbasak> (for the build recipe stage; obviously the build itself is rather arbitrary code by definition)
 * cpaelzer doesn't like "executing arbitrary code on Launchpad"
<rbasak> It'd have to be arbitrary though - how else could you make "parse from VERSIONS file" work generically?
<cpaelzer> rbasak: allow only a sed string or smth like it
<cpaelzer>   {localver <FILE> <sedstring>}
<rbasak> sed can't be trusted
<rbasak> 'r /etc/shadow' etc
<cpaelzer> grml
<cpaelzer> true
<cpaelzer> a chrooted sed or something like it maybe?
<rbasak> This is probably why it doesn't support what you want already :)
<jbicha> juliank: hi, LP: #1697120 is annoying :)
<ubottu> Launchpad bug 1697120 in apt-file (Ubuntu) "artful's apt-file complains about Ubuntu sources.list" [High,Confirmed] https://launchpad.net/bugs/1697120
<cpaelzer> rbasak: about random code on LP - the build of the recipe runs dpkg-source -i -I --before-build => dh clean => override_dh_clean can run any code
<cpaelzer> although it is in fakeroot
<cpaelzer> just as I'd have suggested for the version generator code
<cpaelzer> so one could say "if it is safe enough for A it is safe enough for B as well" and a feature request bug would not be too bad
<jbicha> cpaelzer: this thread feels like questionable advice to me, so let me add one more idea for you: override_dh_gencontrol
<jbicha> dh_gencontrol -- -v
<jbicha> I've only ever used that to change an epoch, but if you don't care about the source package version, it might workâ¦
<juliank> jbicha: Well, see what Niels wrote in the bug.
<cpaelzer> thanks jbicha, reading into that as an option
<cpaelzer> to locally debug germinate before a change to the seeds how much deeper than "germinate -d artful -d artful-updates -S file:///home/paelzer/work/seeds/ -s ubuntu.artful" can I go?
<cpaelzer> currently I miss rdepends in the generated Dirs/Files
<cpaelzer> but it is not run with --no-rdepends
<cpaelzer> jbicha: thanks a lot - qemu_2.9.50-daily-20170627140413 via dh_gencontrol - just how it should be
<rbasak> jbicha, cpaelzer: ah. Interesting approach, thanks.
<zyga> jjohansen: hey
<zyga> jjohansen: are you around?
<bdmurray> xnox: What in bug 1699360 leads you to believe gnome-software as the frontend in use?
<ubottu> bug 1699360 in systemd (Ubuntu) "package libpam-systemd:amd64 232-21ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,New] https://launchpad.net/bugs/1699360
<xnox> bdmurray, discussions here earlier in Europe morning time; the journal logs that aptdaemon invoked the install, with passthrough frontend.
<xnox> bdmurray, i'm not sure if it is software-updater or gnome-software, but i've been advised that the unphased gnome-software in zesty only may be the culprit.
<xnox> this bug is on zesty.
<jbicha> bdmurray: do you want to phase gnome-software/zesty or should we just wait for the next SRU (already in -proposed) at this point?
<bdmurray> xnox: I'm just trying to understand what indicates that it is gnome-software so more bugs related to that gnome-software bug can be found. I don't doubt that it could be gnome-software. Its just not obvious from the logs that it is.
<xnox> bdmurray, it would be nice to document in aptdaemon /who/ started a given transaction, but i do not think we currently log that.
<xnox> maybe that is logged somewhere, but i don't know where.
<xnox> the dpkg frontend and the aptdaemon mentions strongly indicate a desktopy / gui update.
<bdmurray> xnox: I think I've found a way to determine which frontend it is although its not great. The JournalErrors will contain a PyGIWarning when its gnome-software and maybe an update-notifier.desktop error when its update-manager.
<xnox> bdmurray, >_< lovely =) so we gonna go by gtk vomit =)
<xnox> as good as anything
<bdmurray> Well I think something (apport?) should be fixed so we know which frontend it is for sure.
<jjohansen> zyga: just getting in
<jjohansen> what can I do for you?
<zyga> jjohansen: hey, I found a bug in apparmor, I'm just preparing a program to reproduce it
<zyga> jjohansen: I wanted to share what I have so far
<zyga> jjohansen: and ask what you think
<jjohansen> zyga: the issue from yesterday, with pivot_root?
<zyga> jjohansen: I think so
<zyga> open("/proc/1/ns/mnt", O_RDONLY|O_CLOEXEC) = 6
<zyga> setns(6, CLONE_NEWNS)                   = 0
<zyga> chdir("/")                              = 0
<zyga> umount2("/run/snapd/ns/snapd-hacker-toolbelt.mnt", UMOUNT_NOFOLLOW) = -1 EACCES (Permission denied)
<zyga> write(2, "cannot unmount preserved mount n"..., 85cannot unmount preserved mount namespace file /run/snapd/ns/snapd-hacker-toolbelt.mnt) = 85
<zyga> write(2, ": Permission denied\n", 20: Permission denied
<jjohansen> correct
<zyga> [46499.130927] audit: type=1400 audit(1498576919.074:225): apparmor="DENIED" operation="umount" profile="/usr/lib/snapd/snap-confine" name="/" pid=19511 comm="snap-confine"
<zyga> jjohansen: does that look plausible
<jjohansen> correct
<zyga> jjohansen: my gut feeling is that after jumping out of the namespace something is not updated
<jjohansen> it is however correct
<zyga> yes/
<zyga> ?
<jjohansen> switching namespaces will cause the files opened within the namespace to disconnect
<zyga> jjohansen: hold on, this is not using any files opened from the namespace anymore
<jjohansen> mount namespaces can't even be thought of as parent child
<zyga> jjohansen: umount uses just the path
<zyga> jjohansen: and for sure, umount was not using / but another thing, so how did / show up without any other error (like disconnected path)
<bdmurray> jbicha: I think we really want the version of gnome-software in -proposed. I don't think the unphased one in -updates gets us much.
<jbicha> bdmurray: it allows installing 3rd party deb's !
<zyga> jjohansen: can you explain how you see it?
<jbicha> it's almost moot now since maybe the new one will start phasing later this week anyway
<jbicha> bdmurray: sorry I didn't ping you sooner about it
<bdmurray> jbicha: Which bug / crash is it fixing? I don't see the new one as being verified.
<jjohansen> zyga: mounts are try too, what does /run/snapd/ns/snapd-hacker-toolbelt.mnt look like? is there a bind mount involved, is there a component that steps through nsfs
<jbicha> LP: #1672424
<ubottu> Launchpad bug 1672424 in gnome-software (Ubuntu Zesty) "Cannot install Debian files outside of the repositories" [Critical,Fix released] https://launchpad.net/bugs/1672424
<zyga> jjohansen: /run/snapd/ns/snapd-hacker-toolbelt.mnt is a bind-mounted mount namespace of a process
<jjohansen> zyga: can you give me a stat of each component of the path?
<jbicha> the new one has not been verified yet, robert_ancell is sprinting this week
<zyga> jjohansen: from my regular mount namespace? yes
<zyga> jjohansen: the file itself is nsfs, everything else is / /run (tmpfs) ... all until the .mnt file which is nsfs
 * zyga goes to stat it
<jjohansen> zyga: okay, that explains it
<zyga> http://pastebin.ubuntu.com/24964030/
<jbicha> the gnome-software SRUs look simple enough to verify so I'm going to take a look
<zyga> let me know if you want stat -f as well
<jjohansen> nsfs, exists in its own special kern mount, that is detached from the system
<jjohansen> apparmor doesn't handle that well atm
<zyga> aha
<zyga> so it is a bug in some way?
<jjohansen> I have some wip to address this
<zyga> (stat -f: http://pastebin.ubuntu.com/24964032/)
<jjohansen> zyga: bug sure, or feature still in dev
<zyga> jjohansen: interestingly it works if you don't setns at all
<zyga> jjohansen: because we unmount them all the time
<zyga> jjohansen: I was thinking about unmounting it from a helper forked process that doesn't transition at all
<zyga> jjohansen: to work around it for now
<zyga> jjohansen: do you think that is sensible?
<jjohansen> possibly, it certainly seems to be the way to avoid the issue until a fix lands
<zyga> jjohansen: do you have a reference to the bug?
<zyga> jjohansen: or your way to describe it accurately
 * zyga is still unsure if it is setns done twice or the fact that pivot_root was used on the namespace that is being "jumped" out of
<jjohansen> zyga: there is no bug that I know of, feel free to open one. It is an issue I am aware of, there is a bug that mentions the nsfs issue I will have to dig for that, it comes out of lxc reports but I lost the all my open tabs in a browser crash, the double pivot_root/setns is a separate thing and I know there is nothing for it
<zyga> jjohansen: ok, is that something that you are planning to fix soon? is it still unknown in some regard or just not implemented but well understood?
<jjohansen> zyga: the don't know that I would say all the issues around setns, and pivot_root are well know but I have been working on a patchset for upstream RFC that adds some new hooks that help us so that the LSM will get the information we actually need to be able to properly deal with them
<jjohansen> so yes, actively being worked on, I am hoping to land something for 4.14
<zyga> jjohansen: is there anything we should be aware of that may affect snapd? we use setns and pivot_root for fundamental snap operations
<jjohansen> note: landing something for 4.14 would mean we should be able to put it into 17.10
<zyga> jjohansen: I'm somewhat worried as this affects all the snaps, all the way back to 14.04
<jjohansen> zyga: heck yes, it certainly does
<jjohansen> the LSM can't do anything about setns, we only see its affects post it happening
<jjohansen> zyga: we will have to be careful and do some abi detection, if we do it correctly we should be able to emulate old behavior and not break things
<jjohansen> I will make sure you get patches in advance
<zyga> jjohansen: I'm still unsure about what is broken exactly but I worry that the issue may affect regular (existing) operations in snapd
<zyga> jjohansen: I only noticed the issue when trying to implement a new issue
<zyga> jjohansen: apart from getting the fix merged in 17.10, do you think we could get a fix in 16.04 kernels earlier?
<zyga> s/a new issue/a new feature/
<jjohansen> zyga: yes, I am going to backport/SRU everything that lands upstream, the goal is to get rid of all (most) ubuntu sauce patches, making it easier for the kt to also support, and pull fixes from upstream
<zyga> jjohansen: understood
<zyga> jjohansen: we're kind of tired after a very unhappy day but I'll file a bug as soon as I can (tomorrow) and try to make a program that reproduces the issue, just to understand it better
<zyga> (hopefully without attaching all of snap-conifne)
<jjohansen> zyga: understood, and sorry
<zyga> jjohansen: no worries, thank you!
<doko> infinity: please could you have a look at the glibc autopkg test failures triggered by binutils?
<infinity> doko: Looking.
<infinity> doko: On all arches.  Looks like a real regression.  Fun.
<infinity> {standard input}: Assembler messages:
<infinity> {standard input}: Error: `loc1@GLIBC_2.2' can't be versioned to common symbol 'loc1'
<infinity> {standard input}: Error: `loc2@GLIBC_2.2' can't be versioned to common symbol 'loc2'
<infinity> {standard input}: Error: `locs@GLIBC_2.2' can't be versioned to common symbol 'locs'
 * infinity will look into that.
<doko> right, maybe look first if it's already addressed upstream
<infinity> Indeed.
<infinity> 388b4f1a02f3a801965028bbfcd48d905638b797
<infinity> Will pick that up and commit to Debian too for you.
<doko> ta
<mwhudson> doko: did you see my mail about the gcc-cross packages in the python rebuild ppa?
<doko> mwhudson: I did, and I thought I sent a reply: please ignore it
<mwhudson> doko: oh yes you did send a reply, i hadn't got to that part of my email yet
<mwhudson> doko: thanks
<zyga> slangasek, infinity: hey, did you get my message about testing initrd a few days ago?
<slangasek> zyga: hi, I did - sorry, thought I had replied here on IRC.  I think it's a good idea and I have added it to my backlog^W open browser tabs for further consideration
<zyga> slangasek: thanks I must have lost the response
<zyga> slangasek: let me know when would be a good time to have a chat about what should be the next step
<zyga> slangasek: and if you have any views on the approach taken
<slangasek> zyga: any urgency attached to this?
<zyga> slangasek: no, none
<infinity> zyga: I looked at it, and had some emotions, but didn't have the time to turn those emotions into English opinions.
<zyga> infinity: positive or negative emotions?
<infinity> zyga: Yes.
<mwhudson> hooray you can't install python-argcomplete and python3-argcomplete at the same time?
<mwhudson> hm no
<sarnold> I can't see any reason why the two would conflict based solely on the apt-cache show output and apt-file show output
<sarnold> I could understand that maybe you get to use only one of them at a time..
<mwhudson> i get
<mwhudson> Unpacking python3-argcomplete (1.7.0-0.1ubuntu1) ...
<mwhudson> dpkg: error processing archive /tmp/apt-dpkg-install-Xce9pu/60-python3-argcomplete_1.7.0-0.1ubuntu1_all.deb (--unpack):
<mwhudson>  trying to overwrite '/usr/bin/python-argcomplete-tcsh', which is also in package python-argcomplete 1.7.0-0.1ubuntu1
<mwhudson> in a build lot where other very strange things are happening
<mwhudson> also python-argcomplete itself ftbfs in a-p in really odd ways
<sarnold> eww.
<mwhudson> https://launchpadlibrarian.net/325814526/buildlog_ubuntu-artful-amd64.python-cement_2.10.0-1_BUILDING.txt.gz
<mwhudson> https://launchpadlibrarian.net/318923342/buildlog_ubuntu-artful-amd64.python-argcomplete_1.8.1-1_BUILDING.txt.gz
#ubuntu-devel 2017-06-28
<Unit193> gcr-viewer.desktop:X-GNOME-Bugzilla-Component=gcrX-Ubuntu-Gettext-Domain=gcr  that looks correct! :D
<rbasak> xnox: o/
<rbasak> xnox: wearing my server team hat, rather than my SRU hat: how do you plan to proceed with intel-microcode please?
<xnox> rbasak, yo. it's in the unapproved queue. Waiting for accept or a reject with a snarky comment.
<xnox> which is the usual responses i get with most of my sru upload.
<xnox> (then again maybe snarky comments are only from a pw & i nfinity.... and maybe only for me....)
<rbasak> xnox: I hadn't rejected in case SRU consensus was the opposite of my opinion.
<rbasak> xnox: but I've had +1 and no opinion from anyone else.
<xnox> rbasak, my expectation is for SRU review be more trigger happy - one way or the other.
<rbasak> Fair enough
 * rbasak pulls the trigger
<mwhudson> Laney: based on touched-it-last do you want to figure out why session-migrate ftbfs with python 3.6?
<mwhudson> Laney: https://launchpadlibrarian.net/324067009/buildlog_ubuntu-artful-amd64.session-migration_0.3_BUILDING.txt.gz
<mwhudson> (or decide it's irrelevant now and remove it from the archive)
<mwhudson> didrocks: you too? ^^
<Laney> haha
<Laney> it's certainly not irrelevant
<mwhudson> boo!
<xnox> rbasak, awww my proposed srus got rejected. But i think what i have prepared was right. I have no other updates to propose for this package to upload. Removing assignee.
<mwhudson> hasn't built since y so let's see if it's broken in artful already
<mwhudson> yes it is
 * Laney nods
<mwhudson> the failure is not very transparent
<Laney> it's complaining about the " somehow
<rbasak> xnox: you want me to ask my manager to ask the foundations manager to assign someone as I think it's important for server users?
<xnox> rbasak, i believe intel-microcode is not actually subscribed by any team =/ and there was confusion whether kernel, foundations or server should be taking care of it.
<rbasak> xnox: Zesty would be OK, but then it'd be inconsistent with the other upcoming SRUs.
<rbasak> xnox: understood. I think one of those three teams needs to start taking care of it. I'll ask my manager to hammer it out with the other teams.
<xnox> rbasak, at least zesty can be used as a canary to check this microcode doesn't kill puppies.
<mwhudson> Laney: yeah
<rbasak> xnox: I don't like it, but OK.
<mwhudson> Laney: some unicode nonsense?
<mwhudson> no the stderr really does contain ? not "
<mwhudson> why would that be...
<rbasak> xnox: do you know if microcode updates are persistent or do they need re-application on every reboot?
<mwhudson> Laney: looks like glib changed:
<mwhudson> mwhudson@aeglos:/opt/opensource/deb/py36$ grep "Failed to exec" -r glib2.0-2.*/glib/gspawn.c
<mwhudson> glib2.0-2.48.2/glib/gspawn.c:                           _("Failed to execute child process \"%s\" (%s)"),
<mwhudson> glib2.0-2.53.3/glib/gspawn.c:                           _("Failed to execute child process â%sâ (%s)"),
<mwhudson> Laney: not sure why that's getting mangled to ? though
<Laney> that's not a ? though
<Laney> :)
<mwhudson> jinx
<Laney> mwhudson: maybe a missing setlocale(LC_ALL, "")?
<mwhudson> yeah something like that maybe
<Laney> and setting of a UTF-8 locale
<mwhudson> in session-migrate itself
<mwhudson> ?
<Laney> in main, yeah
<Laney> the tests are decoding things to UTF-8 so probably running in C.UTF-8 would be expected?
<xnox> rbasak, they are not persistent. On each boot stock microcode is loaded, then uefi firmware may update the microcode, then we get a chance to update the microcode in the initramfs, and then on recent kernels microcode can be updated at runtime, and then all of that is lost on reboot.
<mwhudson> Laney: sounds plausible at least, i have an anglophone's confusion when it comes to locales
<xnox> rbasak, hence e.g. in the SRU bug i'm asking for journalctl -k / dmesg output, it should be similar to http://paste.ubuntu.com/24971121/ when a relevant microcode has been applied.
<xnox> mwhudson, it's mostly s/s/z/
<rbasak> xnox: thanks, that's very useful to know. What's the the difference between early initramfs and normal runtime from the kernel/hardware perspective? I didn't think there was any distinction? But there has been talk of Trusty not having early initramfs support. I don't follow why that's a thing.
<xnox> rbasak, early micocode loading means that microcode is appended to the initramfs as an extra cpio archive. The kernel looks at the initramfs, notices there is microcode appended, and then it loads the microcode before executing init of the initramfs.
<xnox> rbasak, meaning that microcode is loaded "early", before any userspace process is started.
<xnox> rbasak, this is relevant in the context of e.g. lock ellision where microcode update _removes CPU instructions_
<rbasak> Ah. That makes sense - thanks!
<xnox> and e.g. loaded shared libraries already did the checks if they can use something, continue to try to use them, and segfault.
<Laney> didrocks: mwhudson: something like https://paste.debian.net/973679/ ?
<mwhudson> Laney: +1 (is the "Run the tests in C.UTF-8" part really necessary, it's not in my sbuild at least...)
<Laney> mwhudson: I don't know what you're guaranteed
<Laney> when I entered an schroot I was in the POSIX locale
<mwhudson> Laney: belt and braces it is then!
<Laney> and it fails there obvs
<Laney> it's didrocks project really so I'll wait for his review
<mwhudson> Laney: ok
<mwhudson> xnox: are you going to end up looking at botch for the ocaml transition?
<xnox> mwhudson, yes. it is a lie that it is in the second round, as it clearly fails to install things from like round six.
<xnox> mwhudson, i still have a bit to do to get there http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html
<mwhudson> xnox: ok
<xnox> sorry level 7, as botch wants dose3 to be installable.
<xnox> i have been uploading level 3 fixes today
<mwhudson> xnox: python 3.6 does something odd to it but i can't look into that until it's build-deps install again :)
<xnox> mwhudson, its build-deps should be installable in the -release pocket; e.g. you should be able to install botch and all the build-deps in the release pocket without -proposed.
<xnox> mwhudson, and then get python 3.6 into there. No?
<mwhudson> ah yea that might work
<mwhudson> i also have a lot of other things i could look at first
<xnox> that is also true
<mwhudson> xnox: i owe you an email about subiquity stuff, will have to be tomorrow now
<mwhudson> xnox: was going to suggest maybe implementing vlan support first
<xnox> mwhudson, could do.
<xnox> mwhudson, at the moment i'm fixing livecd-rootfs to give me something sensible on s390x. At the moment build success; no contents. As the binary hooks ignore errors from snap download =)
<mwhudson> ha
<xnox> mwhudson, i, at the moment, still have plenty of things i could be doing with subiquity.
<xnox> mwhudson, any tips / documentation on how you rebuild subiquity and re-run it in development would be helpful. So far I am improvising as I go along.
<mwhudson> xnox: there is an inscrutable script in installer/geninstaller
<mwhudson> but it's very different from the livecd-rootfs process so yeah
<xnox> mwhudson, tah! will look.
 * xnox picked the devil i know - livecd-rootfs path =)
<mwhudson> this area is not really idea
<mwhudson> if you can come up with instructions to make an image with livecd-rootfs on my machine, that'd be great
<xnox> i am using launchpad builders at the moment, but it should be possible to use Odd_Bloke's cloud builder to do a completely local build with local shnaps and local livecd-rootfs
<didrocks> Laney: sorry, having water infiltration and a specialist came, checking in
<decci> Hi
<decci> Is there any way one can pass DKMS module for my storage RAID controller card using live PXE environment
<didrocks> Laney: mwhudson: ok, the patch looks good to me, and indeed, C.UTF-8 fun :) mind doing a PR against https://code.launchpad.net/~ubuntu-desktop/session-migration/trunk ? (you can even upload it yourself if you want, I don't mind)
<Laney> didrocks: oh dear
<decci> Any idea how can one pass DKMS driver during the PXE boot installation
<decci> Ubuntu trusty lacks RAID controller driver and I need to pass it during the installation phase
<decci> usually I use driver disk to pass it
<decci> But now I have Live PXE boot environment
<xnox> doko, this is known / transient?
<xnox> dpkg: error processing archive /tmp/apt-dpkg-install-VAxZ47/32-gcc-6_6.3.0-20ubuntu1_ppc64el.deb (--unpack):
<xnox>  trying to overwrite '/usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so.0.0.0', which is also in package cpp-6 6.3.0-14ubuntu3
<juliank> apt 1.5~alpha1 should hit artful tomorrow, making libgnutls28 a dependency of the apt package, because the http method gains native https support.
<juliank> That's still very early now, so it's opt-in (set dir::bin::methods::https to "http")
<juliank> Very early as in: I wrote this yesterday
<juliank> in anticipate it becoming the default in a few weeks, though, so please test :) [and I forget to syncpackage it from experimental it would be great if somebody else does]
<juliank> Once the new https method is default, apt-transport-https will then install an curl+https variant or something
<juliank> and we drop it next release cycle
<xnox> so 18.04 LTS is a test monkey for bustler?! =)
<juliank> xnox: Yeah. Like 16.04 is for stretch, mostly :)
<juliank> stretch was the first time apt > 1.1 was shipped in Debian, I'm not sure when we started shipping that in Ubuntu
<LocutusOfBorg> "buster" not "bustler" :D
<LocutusOfBorg> we started with xenial, 16.04
<LocutusOfBorg> 1.2.10-1.2.20
<juliank> Did willy still have 1.0.something?
<juliank> ehm, wily, and yes
<juliank> So, we put one of the biggest releases in APT's history into an LTS release without even having a single test release before it....
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/apt/+publishinghistory?batch=75&direction=backwards&memo=150&start=75
<juliank> Luckily that went well
<LocutusOfBorg> xenial I would say
<LocutusOfBorg> with a shiny 1.1.3
<juliank> LocutusOfBorg: I just looked at https://launchpad.net/ubuntu/wily/+source/apt, and that was 1.0.10.2ubuntu1
<juliank> so, yes, xenial
<LocutusOfBorg> publishinghistory keeps tracks also of removals
<LocutusOfBorg> in case some AA removed it after being copied from unstable/experimental or whatever
<LocutusOfBorg> but who would remove that lovely apt 1.1? :D
<juliank> 1.5 will be artful's series, and it surely will be artful.
<juliank> infinity: I just disabled test-apt-download-progress in my master branch, I thought you'd like to know
<jbicha> laughing as we mangle each other's release code names
<infinity> juliank: Just gave up trying to make it reliable? :P
<juliank> infinity: Too annoyed that 1.4.6 has not migrated yet
<juliank> Can make it more reliable later, but want to have reasonable situation now
<infinity> juliank: Oh.  Let me bump that hint for 1.4.6 :P
<infinity> juliank: (But yay if I never have to hint that test again)
<juliank> Do we have https enabled Ubuntu mirrors?
<infinity> juliank: None that Canonical hosts.
<infinity> juliank: We do, however, rely heavily on apt-transport-https for private PPAs.
<infinity> juliank: (1.4.6 hinted)
<infinity> Of course, won't migrate until the alpha freeze is lifted tomorrow.
<juliank> infinity: But that's not a huge set of users to test the new https method, then :)
<juliank> infinity: thx
<infinity> juliank: It's not an insignificant number, but certainly not as huge as https-everywhere mirrors would be, no.
<infinity> juliank: OTOH, I'm fundamentally opposed to people who think bulk traffic should go over https "just because" :P
<infinity> "I don't want the gubmint to spy on me and know that I install moon-buggy on all my servers."
<juliank> infinity: Ah, not just because, people want to make it harder to figure out which packages you download, so they don't know which software versions you have installed.
<juliank> or even which packages
<infinity> juliank: Yeah, I covered that. ;)
<infinity> juliank: And yes, it's a plausible attack vector, sort of, except that people who are that paranoid should also be installing the latest security updates ANYWAY.
<infinity> juliank: So, it kinda negates itself.
<juliank> infinity: Not sure. But I guess it also helps with some "helpful" firewalls
<juliank> Unless they are too "helpful"
<infinity> juliank: Unless what they're really saying is "I don't want people to know that it takes me three months to evaluate a security update before rolling it out" in which case, I think they get to keep aaaaaall the pieces left to them from their inevitable intrusion.
<rbasak> xnox: can I retry your systemd upload builds? I'm running artful :-/
<juliank> infinity: And well, there are also https proxies, which we'll soon be able to support :)
<juliank> I have my experiences with https proxies....
<infinity> Oh look, doko broke gcc.
<doko> never
<nacc> has anyone tried to use the autopkgtest-virt backends with sbuild successfully? Specifically trying ot use autopkgtest-virt-lxd
<infinity> juliank: Right.  So, none of the above was in any way meant to discourage you from improving https support.  Just a bit of a tangential rant about https archives.
<infinity> Unpacking gcc-6 (6.3.0-20ubuntu1) over (6.3.0-14ubuntu3) ...
<infinity> dpkg: error processing archive /tmp/apt-dpkg-install-OLqr6Z/37-gcc-6_6.3.0-20ubuntu1_amd64.deb (--unpack):
<infinity>  trying to overwrite '/usr/lib/gcc/x86_64-linux-gnu/6/liblto_plugin.so.0.0.0', which is also in package cpp-6 6.3.0-14ubuntu3
<infinity> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<infinity> doko: ^
<infinity> doko: I'm going to delete it from proposed, so it stops breaking builds.
<rbasak> Ta
<doko> ok
<doko> hmm, it should have a replaces ...
<juliank> infinity: Would be good if we can drum up some people that check over the code from a security perspective, it's only about 300 lines of gnutls calling now, that seems a bit easy.
<juliank> That's the TLS support: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2851ec6cf037d552118b885be0dd7796d74730c6
<infinity> juliank: You might see if sarnold (or someone else from his team) is down to do a review/audit for you.
<infinity> rbasak: I'll retry all the builds that broke when it's gone.
<rbasak> Thanks!
<juliank> Eww, I accidentally squashed the SOCKS refactoring in there
<juliank> So, only below the whole socks part
<juliank> If somebody wants to be silly, we can run SOCKS on TLS if there is demand.
<doko> infinity: do you have a binary package, or a build log? can't find it in lp
<infinity> doko: https://launchpadlibrarian.net/325906551/buildlog_ubuntu-artful-amd64.systemd_233-8ubuntu2_BUILDING.txt.gz
<infinity> doko: Can't find what in LP?
<doko> infinity: no, the gcc-6 build log
<infinity> doko: https://launchpad.net/ubuntu/+source/gcc-6/6.3.0-20ubuntu1
<doko> ok, that link doesn't exist anymore from the gcc-6 page
<infinity> doko: Indeed, because I deleted the package.
<infinity> doko: So, indeed, there's no Replaces there.
<doko> infinity: uploaded -21. the patch backported from gcc-7 applied to the wrong chunk :-/
<infinity> doko: Oops.
<infinity> doko: "cpp-6 (<< 7.1.1-8)" <-- Shouldn't that be 6.3.0-20 for cpp-6?  Using a 7 version there means you'll have that Replaces "active" for the life of gcc-6.
<doko> ohh, sure. I'll fix that. but that shouldn't hurt for the upload
<jbicha> xnox: Ubuntu's systemd has been kept in sync, so have you discussed your change with Debian? https://bugs.debian.org/761658
<ubottu> Debian bug 761658 in systemd "Please do not default to using Google nameservers" [Wishlist,Open]
<infinity> doko: Yeahp, should be fine for now.
<rbasak> jbicha, xnox: Debian's position is clear, no? What is there to discuss? Note that they justify their position in part by systemd-resolved not being enabled by default. I think it is in Ubuntu now?
<jbicha> rbasak: maybe resolved would be enabled in unstable too? I think it's at least polite to let the Debian maintainer know when Ubuntu intends to diverge
<jbicha> it's about communication; I'm not saying Ubuntu shouldn't diverge when it makes sense
<jbicha> IIRC mbiebl wasn't interested in changing the setting since it didn't seem to be a practical problem since nobody used resolved; that basis is no longer true now
<jbicha> oh, I didn't realize he was in this channel, hi!
<jbicha> IMO it's the person who makes the change who should start the conversation :)
<mbiebl> jbicha: can you give me some context?
<jbicha> mbiebl: https://launchpad.net/ubuntu/+source/systemd/233-8ubuntu2
<mbiebl> xnox: I assume if no fallback server is defined, the DNS servers acquired via dhcp are tried again (in order)?
<mbiebl> not sure if I understand https://github.com/systemd/systemd/issues/5755 correctly, but it seems, resolved switches to alternative DNS servers (and the fallback) very quickly
<mbiebl> and sticks with them
<mbiebl> i.e. it doesn't retry the servers in order like defined in /etc/resolv.conf on a new request
<mbiebl> in light of that, it seems resolved uses the google name servers more often then necessary
<juliank> Hmm, so looking at bug 1522675, AFAICT all that needs to happen is for update-notifier to Pre-Depend on apt (>= 1.1~) and then change the owner of /var/lib/update-notifier/package-data-downloads/partial/ to _apt
<ubottu> bug 1522675 in update-notifier (Ubuntu) "Warning messages about unsandboxed downloads" [Medium,Triaged] https://launchpad.net/bugs/1522675
<juliank> Or is that owned by update-notifier-common
<juliank> I'm not entirely sure where the dir is created
<juliank> nvm
<jbicha> juliank: I'm annoyed that I see the warning when I use "apt install ./foo.deb" as a subsitute for "dpkg -i" or gdebi
<sarnold> you can do that? o_O
<jbicha> the ./ is a bit annoying too but that's a different issue
<juliank> jbicha: The ./ is really annoying IMO
<juliank> But not my decision
<juliank> Well, I did not make the decision
<juliank> jbicha: I hope we can drop the ./ when we turn of regex and glob matching, and switch to a stricter CLI
<juliank> jbicha: Where do you see that, I don't see that in zesty
<juliank> Hmm, but I guess _apt seems to have read access to my files
<juliank> Now
<juliank> jbicha: It's fairly silly for file:/, I agree
<juliank> Or well, there is no download at all I think
<jbicha> juliank: https://paste.debian.net/973798/
<jbicha> I did mention this on that LP bug :) would you like me to file a new bug somewhere?
<juliank> jbicha: Well, this issue was "scary message" and that's "solved"
<juliank> So yes, another issue might be a good idea
<juliank> Anyhow, let's hope I did not break update-notifier-common :)
<juliank> I tested it, and it seems fine, but there might be issues
<juliank> The diff is tiny: https://launchpadlibrarian.net/325943314/update-notifier_3.180_3.181.diff.gz
 * juliank used the same setup apt uses, so he's hopeful it works out
#ubuntu-devel 2017-06-29
<xnox> jbicha, i even have commit access to debian's git and we do co-ordinate on common things.
<xnox> mbiebl, there are multiple issues with fallback handling if resolved is used by default (true for Ubuntu, not true for Debian). What I guess jbicha doesn't realise is that we are doing extensive code review and DNS resolution and networking configuration improvements. Hence e.g. already two CVEs identified and disclosed by Canonical security team in resolved. (One had other reporters as well) and the privacy settings we are adjusting. Indeed, changing
<xnox> fallback defaults is a privacy issue for Ubuntu, but not for Debian.
<sarnold> I fear aiming a fuzzer at systemd-resolved
<sarnold> I tried once but never figured out how to build another object file in the codebase
<sarnold> chrisccoulson's approach of just aiming it at a malicious server is good fun
<xnox> indeed.
<sarnold> .. but I'd really love to see someone aim a fuzzer directly at the functions.
<sarnold> juliank: "uint8_t hostname[namelength + 2];"  -- I thought C++ committee decided against VLAs?
<sarnold> juliank: '%02X%02X' -- that backslash feels way out of place. what does it do?
<Unit193> LocutusOfBorg: Does the new screen in experimental fix the delta in Ubuntu?
<LocutusOfBorg> Unit193, let me check
<LocutusOfBorg> probably yes
<juliank> sarnold: The C++ committee decided against it AFAIK, yes; but this is GNU C++ :) But should probably be allocated on the heap and have some length check or something. Not sure what you mean with a second part, where is a backslash in '%02X%02X'  (and which part of the code is that). That's both SOCKS support BTW which is in for quite some time already.
<abeato> sil2100, hi, was wondering if ubuntu-image can build classic imagess?
<sil2100> abeato: hey! Not yet, but it will
<sil2100> abeato: it's on our roadmap
<abeato> sil2100, ah, very nice... any rough idea on when that will happen?
<sil2100> abeato: we're on the spec phase now, I'll know more once I have the plan finished
<abeato> sil2100, great... meanwhile, which is the suggested way to create some sort of raw, customized, classic images? I'm playing with debootstrap + parted + kpartx at the moment
<abeato> (which works, but maybe there is something more standardized)
<juliank> abeato: Maybe you could use poettering's mkosi? (it's only in zesty and artful, though) There are probably a ton of other tools too
<LocutusOfBorg> Unit193, seems syncable, doing it now
<abeato> juliank, did not know about that tool, interesting suggestion, thanks
<Unit193> LocutusOfBorg: Thanks.
<juliank> Hmm, launchpad did not import apt from experimental yet, I'd have hoped 12 hours is enough for that
<cjwatson> juliank: Importer setup bug - we'll be rolling out the fix today
<juliank> cjwatson: ah, ok.
<LocutusOfBorg> doko, hello, new binutils broke ghc build on arm64 :(
<LocutusOfBorg>  /usr/bin/ld.gold: internal error in fix_errata, at ../../gold/aarch64.cc:1971
<LocutusOfBorg> hello ScottK can you please check the new pyyaml logs? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> I did import a new patch from jrtc27 and this one seems way better
<cjwatson> juliank: next importer run should work
<juliank> cjwatson: thx
<doko> LocutusOfBorg: does the BFD linker work?
<LocutusOfBorg> doko, I don't know how to test :/ let me try
<seb128> slangasek, hey, do you know who could be pinged about nplan autopkgtests blocking the  n-m update in artful while cyphermox_ is on vac?
<seb128> jbicha, ^
<slangasek> seb128: well, first it's not a new blocker, and second last I knew the root of these failures was believed to be in NM, so... :) I will mark it badtest for p-m.
<slangasek> seb128: ah, but that was ppc64el-specific; why is NM triggering autopkgtest failures on other archs?  I'm not badtesting those without someone investigating to show it's not genuinely an NM regression
<seb128> slangasek, define "new"? it's new since the n-m update
<seb128> some problem with mtu handling
<seb128> it could be a n-m issue/regression, it's just that cyphermox_ understood the issue at least a bit when I talked with him
<slangasek> seb128: ok, well I don't believe he handed off that context to anyone.  Did he say it was definitely a test bug?
<seb128> slangasek, it was discussed on https://irclogs.ubuntu.com/2017/06/22/%23ubuntu-desktop.html#t13:49
<seb128> he wrote "and indeed the mtu issue seems like a genuine regression"
<slangasek> seb128: that implies a regression in NM, surely?
<seb128> slangasek, or netplan doing something not documented/supported which happened to work but stopped doing so
<slangasek> "seb128: MTU is special in that so far we've been relying on systemd to apply the change (via udev) rather than NM, so it might not write anything in this case"
<slangasek> seb128: I'll look into it later this morning
<seb128> thanks
<chiluk_> tjaalton: ... hey man... so i've been hitting a few bugs related to slowdown in chromium and chrome on skylake *(slow page scrolling, flashing, etc... there are quite a few bugs out there on this)... At the moment I've moved to using the xserver-xorg-video-intel-hwe-16.04 driver.  Is there anything else I can do to help you out on this?  I'm no X stack expert, but I can be pretty persistent.
<betanu701> Hi all, I was wondering if anyone can point me in the right direction on getting a tarball of ubunutu. I am trying to install a 64bit version in wsl but the only ones I can find are x86
<betanu701> ubuntu* too many us!
<nacc> betanu701: what is wsl?
<nacc> betanu701: a 'tarball' of ubuntu doesn't make sense to me. ubuntu is a distribution
<betanu701> windows subsystem linux
<nacc> !ubuwin | betanu701
<ubottu> betanu701: Canonical and Microsoft have announced that Windows 10 will be able to run Ubuntu programs without needing porting/recompilation. This functionality is still in beta and is not supported in #ubuntu. For discussion and support, see #ubuntu-on-windows.
<nacc> betanu701: that thing?
<nacc> betanu701: or something else?
<betanu701> yes that thing. I will check out that channel. Thanks!
<nacc> bdmurray: re: LP: #1574670, it's not fix released, do you agree?
<ubottu> Launchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [Undecided,Confirmed] https://launchpad.net/bugs/1574670
<bdmurray> nacc: sure
<nacc> bdmurray: thanks, updated the bug states
<sarnold> juliank: interesting. I copy-and-pasted that \ right from the link https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2851ec6cf037d552118b885be0dd7796d74730c6 here... but I don't see it now when I reload. Crazy.
<jbicha> bdmurray: did you see that u-release-upgrader's artful autopkgtests are failing? new pep8 error 'E722 do not use bare except'
<jbicha> http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader/artful/amd64
<bdmurray> jbicha: No, shouldn't I get emails about that?
<jbicha> I don't believe autopkgtest sends automated emails at all
<nacc> you'll get an e-mail eventually taht it's stuck in -proposed for X days
<jbicha> this is how it was fixed in another pkg: https://launchpadlibrarian.net/324926055/update-notifier_3.179_3.180.diff.gz
<jbicha> webkit2gtk is stuck in proposed but no one in Ubuntu uploaded that
<tjaalton> chiluk: try ppa:canonical-x/x-staging
<chiluk> tjaalton: then what? would the plan then be to find fixes to cherry-pick?
<chiluk> we have entire generations of Intel chips that are causing browser badness.
<tjaalton> chiluk: this will hit xenial in 16.04.3
<tjaalton> so you'd get upgraded to it anyway
<chiluk> unless you aren't on the hwe stream.
<chiluk> right?
<tjaalton> right, those users are on -intel anywa
<tjaalton> y
<chiluk> how can you be so sure?  I'm sure there's lots of users out there who haven't figured out that they need to be on the -intel driver.
<chiluk> are the fixes for all this slowdown known?
<chiluk> basically can we backport the fixes into xenial-updates.
<chiluk> rather backport the specific patches into xenial-updates.
<tjaalton> I'm assuming you mean folks on -hwe-16.04 that are using the default driver, which is the modeset driver
<tjaalton> stock xenial uses -intel, if it's installed
<chiluk> actually I haven't checked is it possible to be on skylake or kaby-lake and not on the hwe stream?
<tjaalton> yes it is
<chiluk> and have a fully functional desktop?
<tjaalton> because we enabled kbl on 16.04.1
<tjaalton> I bet you
<chiluk> yeah I bet you are correct.
<chiluk> alright well I'lls tart with the x-staging + the default modeset, and see where that gets me.
<chiluk> thanks tjaalton
<tjaalton> the new xserver should fix at least some performance issues
<tjaalton> which reminds me to update my skylake desktop on it..
<mwhudson> Laney: you going to upload that session migration fix?
#ubuntu-devel 2017-06-30
<Laney> mwhudson: yeh
<juliank> I just synced apt 1.5~alpha1 to artful, with HTTPS support in the http method, but note that ~alpha1 loads the system CA store even if specified a custom one. ~alpha2 tried to fix that but had a regression that is fixed in ~alpha3 (which I'll sync later today)
<infinity> juliank: What dependencies does this introduce to the base system?
<juliank> infinity: It  adds a dependency on libgnutls
<infinity> juliank: Yeah, just found that.
<infinity> juliank: libgnutls30 was already prio:important for other reasons, so that seems pleasantly alright by me.
<juliank> Apparently, we don't have gnutls in the base system yet (compared to Debian, where wget uses gnutls, we use openssl )
<juliank> ignore that
<juliank> I was looking at my build chroot, and that does not even have wget
<infinity> juliank: Anyhow, +1 for gnutls instead of curl-gnutls.  I think this'll shrink some annoying cruft from the LP buildd chroots when we can switch.
<infinity> juliank: How do I select one over the other?
<juliank> infinity: Currently you have to set Dir::Bin::Methods::https to http (and the same for tor+https for people who use that...)
<juliank> Although, tor actually only works in alpha 3
<juliank> infinity: Eventually it will become the default, but support for CONNECT proxies (and HTTPS proxies) is not there yet
<infinity> juliank: So, I'm not against us doing that in the artful chroot configs if/when you think we're ready to hammer on it a bit.
<infinity> juliank: Then all private PPAs building for artful would use the new method.
<juliank> As long as the PPAs don't use proxies, you can switch them as soon as it landed (if you set a CaInfo file, you might want to wait until alpha 3)
<cjwatson> PPA building doesn't use proxies; snap building does
<cjwatson> (in LP)
<infinity> cjwatson: For apt?
<juliank> proxies for https, that is
<cjwatson> not specifically for apt, but snap builds set up a proxy in order that they can fetch stuff from non-DC sources
<cjwatson> so apt will (IIRC) end up using that
<infinity> Ahh, but I can configure apt to skip proxies.
<juliank> I'll try to write CONNECT support (and the https proxy support) soon.
<cjwatson> sure, but we have a thing that works at the moment :)
<infinity> Which maybe we should for that very scenario.  Unless you think it's sane to cache our own stuff in squid.internal.
<cjwatson> I'm mostly disinclined to fiddle much with the config since it's been a time-sink
<juliank> It's just Acquire::https::Proxy "DIRECT" that needs to be set, really
<cjwatson> and this isn't squid.internal
<infinity> squid.whatever. :P
<cjwatson> https::proxy direct is the wrong fix for snap builds, because it's quite possible that they'll want to use https archives outside of the datacentre, which can only possibly work through the proxy
<cjwatson> private PPAs are really not my primary concern there, because private snap builds in LP aren't yet a thing
<cjwatson> (BTW, I'm not intending to give juliank a hard time for not having done this yet - sounds like great work so far)
<infinity> Kay, we can just wait for the support to be complete.
<infinity> I'm just excited to see apt-transport-https, and half of its deps, go away. :P
<cjwatson> definitely
<juliank> OK, I'm reading now :)
<juliank> And luckily for us, I do have a proxy here, so I really need this
<infinity> "luckily".
<juliank> infinity: Yeah, otherwise it might take longer. But if I don't do this soon, I end up exceeding my data limit at some point (and the proxy works around the data limit ...)
<elopio> Trevinho: ping, check your email.
<juliank> infinity: Seems to be working now
<juliank> But the code is a bit hacky so far
<Trevinho> elopio: is the video already live on youtube or what?
<juliank> infinity: Have a look at it and tell me if you see something scary https://github.com/Debian/apt/compare/master...julian-klode:feature/https-proxy?expand=1
<infinity> juliank: I'd recommend sarnold, if you want a "is it scary" code review.
<juliank> infinity: well, then tell me if you see something odd :)
<juliank> Did I say that I like that C++ has lambdas now?
<juliank> infinity: I tested: anonymous HTTP proxy, and an HTTPS proxy with Basic auth, BTW :)
<juliank> infinity: I think the transition to http being the default https will start later today, now that it's feature complete.
<juliank> Exciting times :)
<juliank> Oh, maybe I should probably talk to the proxy in HTTP/1.0 CONNECT, instead of HTTP/1.1 CONNECT
<juliank> or read the spec for it
<juliank> The RFC says I'm doing everything right :)
<xnox> juliank, not using HTTP/2.0 and push the relevant metadata and packages from the server in parallel?
<juliank> xnox: No HTTP/2 yet
<juliank> xnox: But we do pipeline
<juliank> I think HTTP/2 is really hard actually, if you want to fully do parallel streams
<juliank> Our code only handles receiving one file at a time
<juliank> Anyway, pipelining works well for apt, as we can integrity check everything :)
<xnox> juliank, not sure we want parallel downloads. i believe mirrors complained when people do that
<juliank> xnox: I meant the parallel stream thingy that http2 does
<juliank> Where it multiplexes multiple responses
<ricotz> infinity, hi, is there some eta to update builder-choots for https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1699772 ?
<ubottu> Launchpad bug 1699772 in scilab (Ubuntu) "linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic Regression: many user-space apps crashing" [Undecided,Confirmed]
<cjwatson> ricotz: Kernels aren't in the chroots.
<cjwatson> ricotz: The builder VM images are updated automatically from cloud images on cloud-images.ubuntu.com, so they should pick it up once it turns up in cloud images.
<ricotz> cjwatson, ok, you know what I mean ;), so I am hoping this happens soon
#ubuntu-devel 2017-07-01
<sarnold> bdmurray: 1701491 has a DpkgTerminalLog.txt that shows the openssl upgrade dying; again no actual error messages from dpkg :(
<juliank> Hmm, there seem to be issues installing udev on armhf, causing the autopkgtests postgresql-debversion/unknown and ubiquity/unknown to fail.
<juliank> Or maybe the machine was shutting down while running the tests?
<juliank>  Main PID: 2311 (systemd-udevd) -  Status: "Shutting down..."
<juliank> Well, let's try again and see if it works this time
<juliank> In the apport test suite, Failed to fetch https://launchpad.net/ubuntu/+archive/primary/+files/coreutils-dbgsym_8.26-3ubuntu3_amd64.ddeb Error reading from server. Remote end closed connection [IP: 91.189.89.222 443]
<juliank> It worked yesterday with apt 1.5~alpha3, so it's either the "Improve closing the TLS connection" change in 1.5~alpha4 - https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=8f5db6b513b90b6ee5b625131a25b146fa912e0d - or the server side
<juliank> Maybe Launchpad is angry with apt because apt just closed the fd with an incomplete TLS closure ;)
<thewillo> Hi, I noticed the daily snapshot I got yersterday isn't triggering any of the compiler segfaults previous versions were on my Ryzen 7 1700x. But right before I did that, I overclocked my ram. Now there is 2 explanations, the ram clock fixes the SMP bug I was having, or you guys are compiling with gcc-7.1.0 and/or using some workarounds
<thewillo> so did you upgrade compilers for the new builds?
<juliank> thewillo: It's still 6.3, but newer SVN revision
<juliank> (AFAICT)
<thewillo> either it's fixed with SOMETHING done different in the daily snapshot, or me overclocking my ram fixed it. I don't know which
<thewillo> knowing what I do about computers I could see how overclocking the ram could possibly be a fix
<thewillo> but I don't know enough to say that for sure
<thewillo> i could just see how it might be something
<thewillo> but I also know that compiling everything with gcc7.1 fixes it
<thewillo> but first you have to compile gcc 7.1, then you have to compile it with itself, then you have to compiler your whole system
<juliank> I can assure you that nobody recompiled everything
<thewillo> I did... then my SSD failed
<thewillo> so I had to start fresh, and I got the daily snapshot... Damn installer didn't work at all. I had to do everything manually with the live usb and chroot
<juliank> And it's unlikely that's every going to happen.
<thewillo> which I only kept doing because I thought it would be good to know how
<thewillo> juliank, why is it unlikely?
<juliank> Because recompiling an entire distribution is not usually done. It'd have to be fixed in microcode or worked around in the kernel or something
<thewillo> doesn't every updated package involve compiling the updated version?
<juliank> Sure
<juliank> But do you want to update every package, there are like 20000 of them
 * thewillo shrugs
<juliank> thewillo: Isn't AMD working on microcode fixes or something?
<juliank> I don't completely keep track of the situation
<thewillo> they did fix it
<thewillo> they distributed the fix on the 20th
<thewillo> but it's not patched in my bios
<juliank> Ah good
<thewillo> the fix went out, but it's not available in my uefi firmware yet
<thewillo> but they've been updating it almost weekly
<thewillo> lots of stability fixes and better support for higher ram clocks
<juliank> That's good to hear, let's hope things are stable when I'll have money and time to get some Ryzen (2?) :)
<thewillo> but the SMP segfaults were still happening with the firmware from 5 days ago
<thewillo> juliank, want my e-mail in PM, when time comes you can e-mail me and ask how it's going, since my project involves a lot of toolchains and a ton of source and I use linux
<thewillo> ?
<juliank> Nah, I think it might take a long time
<thewillo> oh
<thewillo> ok
<juliank> thewillo: Let's put it like this: When I'm ready to buy, it will probably be the second generation already :)
<thewillo> ahh
<thewillo> I wonder if the microcode patch is in the 17.10 repo's version of amd64-microcode
<juliank> thewillo: No. Apparently Ryzen microcode can't even be updated at runtime
<juliank> Because it contains memory and sata controller firmware needed for early boot or something
<thewillo> oh
<thewillo> well, to be fair, patching microcode from software is something that you don't want software to be capable of
<thewillo> unless you enable it for a specific need
<thewillo> like it should be disabled by default but an option in firmware
<juliank> It seems that apt 1.5 breaks the Launchpad recipes with "E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed."
<cjwatson> juliank: Hm, do we possibly need to make launchpad-buildd do "deb-src [trusted=yes] file://..." there?  I'm surprised that that's new though.
<cjwatson> juliank: Did apt use to consider file: as automatically trusted or something?
<juliank> cjwatson: Hmm, not sure what happened precisely, just saw it in the build logs for the ~deity/sid PPA
<juliank> cjwatson: There was a warning before, and now it's an error
<cjwatson> juliank: Could you file a launchpad-buildd bug and I'll get it fixed?
<juliank> cjwatson: https://bugs.launchpad.net/launchpad-buildd/+bug/1701826
<ubottu> Launchpad bug 1701826 in launchpad-buildd "APT 1.5: E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed. " [Undecided,New]
<cjwatson> ta
<cjwatson> MP sent
<juliank> cjwatson: Any idea about 'Failed to fetch https://launchpad.net/ubuntu/+archive/primary/+files/coreutils-dbgsym_8.26-3ubuntu3_amd64.ddeb Error reading from server. Remote end closed connection [IP: 91.189.89.222 443]' - it could be that I did something wrong in the new https handling between apt 1.5~alpha3 and 1.5~alpha4, but I don't really see what. So, could it be a Launchpad <-> autopkgtest issue?
<juliank> Ah no, ~alpha3 did not run the new https method on autopkgtest, so it really could be anything
<juliank> But just downloading from launchpad works for me
<juliank> I wish I had more details
<juliank> I guess someone with access needs to run the autopkgtest and then enter that environment and check manually with apt-helper and debugging options
<cjwatson> juliank: Have you tried just retriggering the test?  It might have been transient
<juliank> cjwatson: Yeah, but I guess I'll try it again
<juliank> Queues are empty now anyway
<juliank> From what I understand either gnutls_record_recv() or gnutls_record_send() must have returned 0 at some point
<cjwatson> It's not just getting confused by the 303 response or something?
<juliank> cjwatson: Well it works locally with apt-helper
<juliank> I guess I'd want to rerun the tests with debug::acquire::https=1 and debug::pkgacquire::worker=1
<juliank> set in the apt config
<juliank> That'd be really noisy but tell us more
<juliank> Hmm, the new tls support is much slower for this file than the curl one
<juliank> 3.4 vs 5.4 seconds
<juliank> Mostly handshake/header waiting AFAICT
<juliank> Hmm, no it waits 2 seconds between receiving the 303 and returning it to apt. odd.
<juliank> Ah, because it tries to read a body and that takes some time.
<juliank> So maybe that's where we're failing - trying to read a body
<juliank> I'm not sure why we try that anyway - Content-Length is 0
<juliank> cjwatson: APT assumed that if Content-Length is available that there is content. Launchpad responded Content-Length 0, I think that might be causing it (not sure why it works for me, though)
<cjwatson> LP is per spec
<cjwatson> "[stuff about HEAD, then:] All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length."
<cjwatson> RFC 2616 4.3
<juliank> Yeah
<juliank> Minor nitpick: Current RFC is 7230, though
<juliank> ;)
<juliank> cjwatson: It's incredible what kind of issues I detect in that old code now that I added TLS support to it...
<juliank> With that fixed, http redirects should be faster now.
<juliank> I'll upload that to artful and see what it thinks
<juliank> cjwatson: I think most servers just close the connection after a redirect, and that's why nobody noticed that
<juliank> (or well, send Connection: close)
<juliank> cjwatson: Seems treating Content-Length: 0 correctly as no content solved the issue :
<juliank> :)
<juliank> That bug must have been lurking there like forever
<cjwatson> juliank: Nice find
<cjwatson> juliank: Some RFCs I remember by number and it's tough to update my mental model; 2616 has been in my head for 17 years :P
<juliank> cjwatson: Next week the launchpad build chroots for artful can drop apt-transport-https then :)
<juliank> Going to be epic :)
<cjwatson> I will leave that to infinity ...
<juliank> He's going to be very happy :)
<juliank> cjwatson: the fix working also means that apt just migrated, so I fear things are broken everywhere now
<juliank> I wonder if we could somehow make interactions with launchpad an autopkgtest. Like a fake package that launches builds on launchpad and waits for them
<cjwatson> juliank: Recipes on artful fortunately mostly aren't too critical
<juliank> cjwatson: Yeah, I feared other sutff might be broken too
#ubuntu-devel 2018-06-25
<mvo> rbalint: hey, iirc you work quite a bit on shadow, right? I have a change for "su" that I would love to get an opinion on: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/984390
<ubottu> Launchpad bug 984390 in shadow (Ubuntu Precise) "$PATH is taken from login.defs not /etc/environment" [Medium,Triaged]
<mvo> rbalint: this is an issue on core18 currently but the bug itself was reported some time ago (and has a patch). if that looks valid I can prepare a cosmic upload
<rbalint> mvo, looking
<mvo> rbalint: I guess I need to also sent this upstream
<rbalint> mvo, morover the plan is shipping login/su/... from util-linux, thus it we change anything we should make sure the switch won't regress it https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833256
<ubottu> Debian bug 833256 in util-linux "util-linux: Please use login/su/... implementations provided by util-linux" [Normal,Open]
<rbalint> mvo, i'm generally ok with the patch, offering it upstream would be nice, so please do it or I can do it sometimes later
<mvo> rbalint: great, thank you, I clean it up a little and sent it upstream
<mvo> rbalint: I can also look at util linux just to see what will happen once the switch happens
<rbalint> mvo, thanks!
<mvo> rbalint: thank you
<mvo> rbalint: I updated the bug with the link to the upstream report and my finding about util-linux (looks like there su-common.c is DTRT from reading the code)
<cpaelzer> doko: search engines won't help me, is "invalid suffix ... on integer constant" more common with the most recent toolchain?
<doko> cpaelzer: context?
<cpaelzer> doko: https://launchpadlibrarian.net/375901368/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu1~ppa2_BUILDING.txt.gz
<cpaelzer> most common case: my mistake, but I fail to yet see it
<cpaelzer> I kicked a rebuild of the most recent version (to make sure if it is me or the toolchain)
<cpaelzer> then I know in which direction to stare more
<cpaelzer> doko: but if you might know like "yeah this now is more often because ..." I would appreciate to know about it
<doko> no idea, maybe look at the macro expansion first?
<cpaelzer> already on it
<cpaelzer> only inserts it into  function/struct names
<cpaelzer> which is why I wonder if any of it now wconsiders 2_12 an int
<cpaelzer> doko: but TL;DR you are not aware of common issues, so most likely something on my rebase broke
<cpaelzer> let it be my task then
<cpaelzer> only wanted to poll for known issues on that
<doko> cpaelzer: sorry, no
<doko> python had thousands separators, not C ;)
<cpaelzer> hehe :-)
<sil2100> slangasek, cyphermox: hey! Could one of you merge my keep-grub-pc ubiquity branch? I can release this without having it merged, but I didn't want to introduce a desync between the vcs and what's in ubuntu
<sil2100> slangasek, cyphermox: of course, if you don't mind that, I could also just release that as is
<slangasek> sil2100: I cannot, I am not in the installer team
<cyphermox> I will
<sil2100> cyphermox: thanks!
<sil2100> slangasek: uh oh, I could have checked, I just assumed because you should be part of "all the teams" I guess!
<cyphermox> sil2100: slangasek: well, you both should probably be in that team, cjwatson or xnox can fix that
<cjwatson> done
<cjwatson> you will probably want to filter at least incoming ubiquity bugmail
<cjwatson> oh, hm, I think slangasek may have been there already and deactivated themself; apologies if that was intended
<slangasek> oh?  not that I was ever aware of doing :)
<slangasek> well, maybe past-me was aware
<cjwatson> ICBW but your membership date is nearly a decade ago
<sil2100> cjwatson: thank you!
#ubuntu-devel 2018-06-26
<Unit193> sarnold: Poooke.
<didrocks> bdmurray: hey! So, I expanded a little bit on https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1774597/comments/9, I would like to know in particular what do you think about the way to fix the first bug, promoting as a SRU apport-noui to main and seed it or moving the unit files?
<ubottu> Launchpad bug 1774597 in gnome-control-center (Ubuntu Bionic) "G-C-C privacy option don't allow sending manual report" [Low,Fix committed]
<bluesabre> Any core devs interested in sponsoring this gvfs upload? https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1762595
<ubottu> Launchpad bug 1762595 in gvfs (Ubuntu) "Thunar incorrectly thinks USB storage device hasn't finished ejecting" [Undecided,New]
<bluesabre> infinity: would you be interested in reviewing our merges for Xubuntu Base/Core? https://code.launchpad.net/~xubuntu-dev/debian-cd/xubuntu-base/+merge/347414, https://code.launchpad.net/~xubuntu-dev/livecd-rootfs/xubuntu-base/+merge/347319, https://code.launchpad.net/~xubuntu-dev/ubuntu-cdimage/xubuntu-base/+merge/347320
<GunnarHj> Hi mvo, I'd like to call your attention to bug #1758684. First I thought that LP was broken somehow, but - as wgrant explained - the problem is that the number of strings in the POT varies between the builds for respective architecture. So the POT build when uploading is simply not reliable; it fails more often than not.
<ubottu> bug 1758684 in Ubuntu Translations "LP only imported a fraction of the snappy translation template" [High,In progress] https://launchpad.net/bugs/1758684
<cpaelzer> Skuggen: hi a question - https://github.com/mysql/mysql-server/blob/8.0/scripts/mysqldumpslow.sh#L66 needs https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/819535/comments/6
<ubottu> Launchpad bug 819535 in mysql-5.7 (Ubuntu) "mysqldumpslow looking for slow.log file on an incorrect directory" [Low,Confirmed]
<cpaelzer> Skuggen: I wonder what the best path is to submit that, and rbasak recommended to ping you
<cpaelzer> should I do a PR for it on github, or a report in their bugzilla (need Oracle id :-/) or ... ?
<mvo> GunnarHj: aha, thank you! let me look at this
<GunnarHj> mvo: Yeah, please do. ;) I have tried to fix it manually a few times, but that's not a sustainable model.. And the with the latest bionic upload none of the architectures seems to have produced a complete POT.
<mvo> GunnarHj: aha, so the problem is that this is not properly sorted? the pot?
<GunnarHj> mvo: Don't think it is about sorting. Every upload results in multiple build, one for each architecture, and each build generates a POT. AFAIU those POTs ought to be identical, but they are not. You may want to take a look at the latest tarballs with stripped translations:
<GunnarHj> https://launchpad.net/ubuntu/bionic/+queue?queue_state=3&queue_text=snapd_2.33.1
<nacc> bluesabre: i can try and look today
<mvo> GunnarHj: aha, I see, it looks like the i386 version is very short for some reason
<mvo> GunnarHj: thanks again, I see that one set of files in ~40k and the other 9kb so something is wrong, I dig into it
<GunnarHj> mvo: Right, that's it. And furthermore, unless you dropped dozens of translatable strings in 2.33, I don't think that any of those tarballs contains a complete POT with all strings which ought to be there.
<mvo> GunnarHj: yeah, its strange when I run this locally it seems to be fine
<mvo> GunnarHj: I need to dig a bit harder. I also wonder if its always the same architecture that has not enough data
<mvo> GunnarHj: or if it is random
<GunnarHj> mvo: It's certainly random. (I thoght otherwise first.)
<GunnarHj> mvo: So I withdraw my suggestion in comment #19 in the bug report.
<mvo> GunnarHj: yeah, I think we need to get to the bototm of this, is it only happening on 18.04+?
<GunnarHj> mvo: Don't know. Have only looked at 18.04, but I suppose we have reasons to fear that it's not limited to that.
<mvo> GunnarHj: I added two snapd PRs to attack the issue #5404 and 5402
<tsimonq2> smoser: What's your UTC offset, out of curiosity?
<tsimonq2> Because if you have the time right now, I'd like to talk about ssh-import-id.
<smoser> ah. tsimonq2 i am US/Eastern (-0400)
<smoser> sure. we can chat now.
<tsimonq2> smoser: Ah, nice, I'm US/Central.
<tsimonq2> smoser: So to get this straight, doesn't Launchpad 404 even when you're trying to get team SSH keys?
<ubottu> Launchpad bug 404 in Launchpad itself "PyGettextPO is not able to handle Unicode strings" [High,Fix released] https://launchpad.net/bugs/404
<tsimonq2> Ah, no, I'm wrong.
<tsimonq2> smoser: Your implementation in fetch_keys_lp LGTM. I'm just wondering about the best way to recursively do teams.
<mnaumann> hi. would you say it is expected that gnupg2 crashes when you try to encrypt to an ecdsa key on 16.04.4?
<smoser> tsimonq2: http://paste.ubuntu.com/p/vYmCHSFXZM/
<tsimonq2> smoser: Right.
<smoser> the one thing i'm not sure of ... don't have a user without ssh keys, is if you can tell the difference between valid-group and user-with-no-keys
<tsimonq2> Perhaps from there we could fall back to launchpadlib.
<tsimonq2> But, iff there's no keys fetchable via the way already implemented.
<tsimonq2> (So existing users wouldn't have the overhead.)
<smoser> well, thats what i had originally suggested. that we could do that.
<smoser> but will your MP do recursive groups ?
<tsimonq2> Mine doesn't. In order to do that, we would need to implement a system to continue down the recursive chain and avoid duplicates (and eliminate duplicate LP usernames).
<tsimonq2> We could probably use a set or something like that for the individual usernames... then when we scan a group, put it in a list.
<tsimonq2> The only question would be how to correctly avoid duplicate group scans.
<smoser> well, one level of groups is not terribly useful, right?
<tsimonq2> Right.
<smoser> and yeah, duplicate group membership is kind of a pain. and my 'path' suggestion is overly simplistic in that regard
<smoser> the reason i was thinking that way was
<smoser> a.) there is a bug open for "trimming" removed entries .. in order to do that we have to know how an entry got in there.
<tsimonq2> (Got a link for that ooc?)
<smoser> b.) if you import a group and all you got was the group name as a marker there, it isn't that useful
<tsimonq2> Oh, right.
<smoser> https://bugs.launchpad.net/ssh-import-id/+bug/1745541
<ubottu> Launchpad bug 1745541 in ssh-import-id "Delete SSH key on remote removal" [Wishlist,Triaged]
<tsimonq2> For the comment aspect of this... maybe the comment could contain every way the key was added (how the person was pulled in), and on calling remove, if removing all comment listings for that entry, delete the whole key, otherwise keep the key and the remaining references.
<tsimonq2> For example, let's say I added my key to a server, I add ~lubuntu-dev, but I then want to remove ~lubuntu-dev. It shouldn't pull my key with it in the removal command.
<tsimonq2> This seems a bit hacky, but when recursively scanning teams we could keep two variables: a set for the teams searched (and searching of the set before adding a team) and a dictionary of people with the teams that correspond to each person.
<tsimonq2> When the scanning is done, we could take the latter variable and add the keys with the appropriate references.
<tsimonq2> smoser: How does that sound?
<smoser> i'd thought of that, but it will get long possibly.
<smoser> i think your suggestion is sane.
<smoser> i'm ok though to first blush justput the group/user name there and improve on it later
<smoser> but i really want to have the user name that it came from
<tsimonq2> So the case where I add ~ubuntu-core-dev, add ~lubuntu-dev, then want to remove ~lubuntu-dev without it removing ~ubuntu-core-dev with it?
<tsimonq2> That's a good point.
<tsimonq2> Let's some up with some comment syntax...
<tsimonq2> Maybe something like this: # ssh-import-id lp:tsimonq2;~ubuntu-dev;~motu (this is in the case that somebody added ~ubuntu-dev)
<tsimonq2> So, username, original username added, then what team it's pulled in as a part of...
<smoser> that just gets long though. i'm willing to sovle that at the po int where we attempt to do removal
<smoser> you dont have to bite all that off now
<tsimonq2> I think once we add support for adding them, there should be support for removing them, right?
<tsimonq2> (And if anything though, I don't know if the reason for pulling it in even matters... maybe something like # ssh-import-id lp:tsimonq2 ~ubuntu-dev;~lubuntu-dev;etc. would work better.)
<smoser> tsimonq2: well there is no support for removing anything right now
<tsimonq2> Yes there is. `ssh-import-id -r tsimonq2` works fine for me.
<smoser> oh. i didnt remembre that ;)
<tsimonq2> np :D
<smoser> it seems reasonably defensible for '-r' to apply only to the way the user was added i think
<smoser> ie, ssh-import-id lubuntu-dev
<tsimonq2> Right, which is why I proposed the second scheme
<smoser> adds tsimonq, so -r lubuntu-dev would remove all of those
<tsimonq2> It would remove all keys explicitly added by lubuntu-dev.
<tsimonq2> However, if I add my own key, then add lubuntu-dev, but then remove lubuntu-dev, my key should stay.
<smoser> yeah
<tsimonq2> (One thing I'd like to implement after this is merged is refresh support, so someone could do e.g. ssh-import-id --refresh lubuntu-dev and if I add/remove a key from my LP profile, or if a user is added or removed from the team, it would automatically update the client. It would be a very similar thing to this to implement, I think.)
<tsimonq2> smoser: Either way, I can come up with an updated MP (or you can, whatever you'd like to do) soon which implements A) the changes you've already made B) support for adding teams, recursively C) properly manipulating the comment (and updating existing entries for consistency).
<tsimonq2> Does that sound good to you?
<sarnold> Unit193: poke!
<sarnold> (finally the best part of facebook, now ported to IRC!)
<smoser> tsimonq2: i wont have much time to look at it, but im' happy to review
<cjwatson> tsimonq2,smoser: Remember also that if you're iterating over .../members yourself then you're going to need to handle collection batching yourself too, following the next_collection_link URLs.
<cjwatson> Assuming that's still your intent.
<cjwatson> Try a decent-sized team like ~ubuntumembers as a test case.
<tsimonq2> smoser: Thanks!
<tsimonq2> cjwatson: I'll look into it, thanks for the pointer.
#ubuntu-devel 2018-06-27
<LocutusOfBorg> doko, I'm attempting a python-networkx mere
<LocutusOfBorg> *merge
<LocutusOfBorg> this should unblock: givaro fflas-ffpack linbox sagemath
<LocutusOfBorg> and probably more
<didrocks> bdmurray: hey, around? Did you get time to look at my questions about apport/whoopsie?
<bdmurray> didrocks: Yeah, sorry still thinking about it.
<didrocks> bdmurray: sure! As you saw, I fixed one on the 2 bugs, for the other, I'm currently heading thinking we should put the systemd units in apport binary package and removing them from apport-noui, but tell me once you are settled on it
<bdmurray> didrocks: apport-noui seemed good for servers, what do you see apport-noui still doing?
<didrocks> bdmurray: it's not installed on servers though?
<didrocks> bdmurray: and people still need to use whoopsie API to autoreport (or drop the file)
<didrocks> basically, just to create /var/lib/apport/autoreport file
<bdmurray> didrocks: right, but if you install apport-noui the thought was crash reporting would just work
<didrocks> (so, installing apport-noui alone isn't enough to autoreport)
<didrocks> hum
<bdmurray> Its been a while since I looked at this though.
<didrocks> let me look again, but I'm pretty sure it doesn't create that file
<didrocks> bdmurray: yeah, it doesn't from what I seeâ¦ So, basically, you install apport-noui and nothing happens
<didrocks> ah
<didrocks> the postinst is touching /var/lib/apport/autoreport
<bdmurray> Okay, good!
<didrocks> bdmurray: so, basically, what we could is move the systemd services to apport (binary package)
<didrocks> and have apport-noui just touching that file (and depending on whoopsie)
<didrocks> then, it enables
<didrocks> others to have the autoreport functionality without installing it
<didrocks> as the whoopsie-preferences API is doing the same (touching or removing that file, based on what you request)
<didrocks> does it make sense to you?
<bdmurray> Okay, I just wanted to make sure there was still an easy way to setup automatic crash reporting without using a UI.
<bdmurray> Yes, this sounds reasonable to me.
<didrocks> I think we fix the bug and still cover this use case
<didrocks> bdmurray: ok, I'll MP that later on :)
<didrocks> thanks for raising this on the bug report, I was just assuming the API was working :p
<bdmurray> didrocks: Great thanks! It'll be good to get this sorted and get more crash reports. :-|
<bdmurray> Well get more data. ;-)
<didrocks> bdmurray: ahah, yes, in some waysâ¦ :p
<didrocks> bdmurray: do you mind refreshing ~ubuntu-core-dev/ubuntu/cosmic/apport/ubuntu (and maybe bionic? didn't check yet) with your latest uploads?
<didrocks> (weird, it seems 2.20.10-0ubuntu3 has been uploaded as a native package where bzr bd clearly requests an upstream tarball)
#ubuntu-devel 2018-06-28
<doko> cpaelzer: could you have a look at migrating mysql and mariadb packages? or somebody else ...
<cpaelzer> doko: I'll ask rbasak to look as he is more mysql'y than myself
<cpaelzer> but I'll take a look myself if there is anything easy I can help with once I'm done with my current task
<LocutusOfBorg> stgraber, what is your opinion wrt libxml-sax-perl ? is the patch still needed? can we forward upstream?
<Unit193> Hello, any hints as to why ppc64el failed?  It shouldn't have, https://launchpad.net/ubuntu/+source/xfdesktop4/4.13.2-0ubuntu1
<LocutusOfBorg> Unit193, pbuilder-dist cosmic ppc64el create && pbuilder-dist cosmic ppc64el login? :)
<Unit193> Not quite how I have my pbuilder set up, but that seems unideal.
<LocutusOfBorg> why? it works!
 * LocutusOfBorg is trying this
<Unit193> Just seems odd that it was the only one to fail, and it wasn't an issue solved by autoreconf.
<LocutusOfBorg> Unit193, they are installable to me
<LocutusOfBorg> I retried the build
<Unit193> Yes, precisely why it's weird...
<LocutusOfBorg> I did some perl stuff, and python is doing some weird things because of transition maybe...
<LocutusOfBorg> it is working now, meh
<davidgiluk> rharper: You're bouncing on oftc/#qemu   rharper left the room (quit: Killed (NickServ (Too many failed password attempts.))).     about every 20 seconds
<infinity> ahasenack: *poke*
<infinity> ahasenack: You around?
<infinity> ahasenack: Looks like it's time to revert the mod-proxy-uwsgi revert from your last upload (uwsgi no longer builds the module).
<infinity> ahasenack: Erm, referring to apache2, that is.
<ahasenack> infinity: hi
<ahasenack> infinity: we should start using the one from apache now then?
<infinity> ahasenack: Aye/
<infinity> ahasenack: http://launchpadlibrarian.net/371383267/apache2_2.4.33-3ubuntu1_2.4.33-3ubuntu2.diff.gz
<infinity> ahasenack: Just revert every bit that refers to uwsgi, IMO.
<infinity> ahasenack: I'd do that myself, but I don't want to be TIL.
<ahasenack> infinity: ok, I'll do it. And then the other source will be removed from the archive?
<infinity> ahasenack: The other binary, you mean.  Which it'll be replacing.
<ahasenack> it comes from its own source, but yeah, its binary
<infinity> ahasenack: There's a lot more in the uwsgi source than just that binary. :)
<ahasenack> I see
<infinity> ahasenack: Only mod-proxy-uwsgi was dropped (because it's now part of apache)
<infinity> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894785
<ubottu> Debian bug 894785 in apache2 "apache2: File conflict with libapache2-mod-proxy-uwsgi" [Serious,Fixed]
<ahasenack> and that's the only bit that is failing to build I assume
<infinity> ahasenack: No build failures.  It's that things depend on libapache2-mod-proxy-uwsgi, which no longer exists because you aren't building it. :P
<infinity> (or, it will no longer exist if I were to remove the NBS package)
<ahasenack> ah, no longer builds == on purpose no longer builds
<infinity> Yes.
<infinity> As in, this transition happened in Debian, and you undid half of it. :)
<infinity> And then we synced the other half.
<ahasenack> for a reason, I think we were missing that sync of the other half
<infinity> Likely.
<ahasenack> it was stuck in migration
<ahasenack> it will all come back to me once I re-enable it
<infinity> Danke.
<infinity> Can that happen today?
<rbasak> ahasenack: and when you're done with that, submit your core dev application already :)
<infinity> If not, I'll grumpily do it myself, but then nag you about taking apache2 back. :P
<infinity> Oh, if you don't have upload rights, I can just do it in your name and pretend I sponsored it for you.  *cough*
<ahasenack> infinity: no grumpyness needed, I'm just starting my day, plenty of time. But I'll need reviews from my peers, it's how we have been doing things. But I guess you can review it if you are still aroun
<rbasak> He can upload apache2 I think - through the server packageset
<rbasak> But still
<rbasak> Core dev.
<rbasak> ahasenack: I think infinity would count as your peer from our team's peer review perspective
<infinity> I might still be on your team!
<infinity> The oldest member, no less.
<ahasenack> didn't mean to imply otherwise :)
<ahasenack> rbasak: I still have some checkboxes to tick in that checklist of yours ;)
<rbasak> infinity: the second oldest member. Looks like you were beaten by 24 seconds :-P
<ahasenack> we have that kind of resolution?
<rbasak> Mouse hover
<infinity> rbasak: Curses.
<infinity> rbasak: Deactivating Fabio would fix that.
<infinity> Pretty sure he hasn't contributed in about a decade.
<rbasak> There are tons of people in ~ubuntu-server who don't appear to have ever been involved at all.
<infinity> Yeah, some past admins were a bit nutty with the accept button.
<infinity> Because building a "community" was more important to them than a useful team.
<rbasak> It's an open team. There is no accept button.
<infinity> Oh, or that.
<infinity> I thought it was once closed.
<infinity> But I could be misremembering.
<ahasenack> ubuntu-server-dev is the more crucial one in terms of privileges
<infinity> Yeah, that didn't exist (cause packagesets didn't) back in "my day".
<infinity> WHEN I WAS YOUR AGE.
<Unit193> Where you ever?
<doko> Unit193: are you handling the thunar transition?
<Unit193> doko: Yes, should be only one package left.
<doko> ta
<Unit193> xfconf should be one too, and that's also going to be done real soonâ¢
<juliank> Phasing of update-notifier uploads has stopped due to https://errors.ubuntu.com/problem/4844575ab1a533f9e47d6fdde541010e267bd9d3 - but all I did was move around some print statements (https://launchpadlibrarian.net/375023334/update-notifier_3.168.8_3.168.9.diff.gz), does anyone see anything I'm missing?
<infinity> juliank: Clearly not a new crash.
<juliank> It does seem familiar
<infinity> juliank: Well, the list of versions at the bottom confirms it's not new. :P
<infinity> Or, wait.  Unless those are all current SRU versins?
<juliank> infinity: no, these are all my SRUs
<infinity> Indeed they are.
<infinity> Hrm.
<infinity> Colour me stumped.
<juliank> infinity: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/882882
<ubottu> Launchpad bug 882882 in ubiquity (Ubuntu) "installer crash with ValueError: invalid literal for int() with base 10: ''" [Undecided,Invalid]
<juliank> I think xnox's comment from 2012 explains it
<juliank> "What happens is that debconf database is locked and status ends up as empty string."
<juliank> why it's locked, though, no idea
<juliank> another one: https://bugs.launchpad.net/ubuntu/+bug/537952
<ubottu> Launchpad bug 537952 in Ubuntu "the installer crash" [Undecided,Fix committed]
<infinity> juliank: Maybe, yeah, but why just now?
<infinity> juliank: Seems fishy.
<infinity> Granted, only 6 total reports, but still weird that it's only on that version.
<juliank> timing issue?
<juliank> the first print moved after the database opening now
<juliank> (well, and after db shutdown)
<infinity> Could be.
<juliank> infinity: no reports from artful yet
<infinity> I suspect the number of people using artful isn't high.
<infinity> So that makes sense.
<juliank> true
<xnox> juliank, sorry, i forgot.
<ahasenack> infinity: local test build worked, upgrade with dpkg -i with old uwsgi installed worked, just waiting on a ppa build to try with apt
<ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/apache2-restore-uwsgi/+packages
<infinity> ahasenack: Pointer to the PPA, so I can re... Thanks. :)
<ahasenack> branch is https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+ref/apache2-restore-uwsgi
<ahasenack> not an mp yet, pending that ppa
<juliank> xnox: there's nothing you have to be sorry about, your comment helps.
<juliank> I wonder what locks the debconf db
<juliank> Like, for my problem, is package-data-downloader run inside a maintainer script that does debconf itself?
<infinity> ahasenack: Diff looks sane to me.
<infinity> juliank: It very much could be, yes.
<infinity> juliank: Try installing flashplugin-installer and see what happens?
<infinity> juliank: Or ttf-mscorefonts-installer, but it might be broken in other ways.
<juliank> infinity: I have that installed on my system for testing
<juliank> in cosmic
<juliank> but I tested those for the SRU verification
<juliank> maybe I need to have both installed?
<juliank> Well, I do
<juliank> infinity: that seems to be it
<juliank> . /usr/share/debconf/confmodule; /usr/lib/update-notifier/package-data-downloader
<juliank> fails
<juliank> like that
<juliank> But this does not really explain it
<juliank> /usr/lib/update-notifier/package-data-downloader gets run from update-notifier-common.postinst only, at least here
<ahasenack> infinity: https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+merge/348679
<ahasenack> rbasak: ^
<ahasenack> rbasak: we should find out why lp can't get the diff correctly for the apache package
<infinity> ahasenack: libjansson4 being removed... Is that because you didn't re-add it to build-deps?
<ahasenack> infinity: that is because of the md module, which I'm still not building
<ahasenack> I'm not changing it in this diff
<infinity> ahasenack: No, I mean it's listed for autoremoval when you remove libapache2-mod-proxy-uwsgi ..
 * ahasenack checks
<infinity> ahasenack: Or is that just cause your system is in a state where that was already on the hit list?
<ahasenack> I started with a fresh cosmic container, just as the testing description says
<ahasenack> let me see what I get out of the box
<infinity> ahasenack: Kay, uwsgi-core depends on it.
<infinity> ahasenack: But I'm wonder if apache2 would too, if you had it in build-deps and the module build detected it, that's all.
<ahasenack> I will check. I thought it was because of the md module, as that's why debian added it to build-deps in https://salsa.debian.org/apache-team/apache2/commit/b9d37f2a96da2fd69bf
<infinity> $ rgrep -l jansson | grep modules
<infinity> modules/md/mod_md.dsp
<infinity> modules/md/md_json.c
<infinity> modules/md/config2.m4
<infinity> modules/md/mod_md.mak
<infinity> Yeah, the source agrees.
<LocutusOfBorg> stgraber, I merged it, please correct me if I'm wrong, maybe we can upload a revert and let it be syncd on next update
<ahasenack> just md?
<infinity> So, just a weird coincidence is all.
<infinity> rbasak: If I sponsor this the usual way and don't bother with the MP (other than to review and mark it merged), some magical import tool will DTRT, right?
<infinity> Like, I don't actually need to commit this to git just to make your tooling happy?
<ahasenack> infinity: the original uwsgi-mod-proxy package recommends uwsgi-core, that's where jansson4 comes from. The new libapache2 transitional package doesn't to that of course, nor does apache2-bin (where mod-proxy-uwsgi lives now)
<infinity> Oh, not that I'm in the list of reviewers anyway. :P
<ahasenack> infinity: ops
<ahasenack> autopilot, sorry
<ahasenack> infinity: it's infinity in lp too?
<infinity> ahasenack: Yeah.  I meant it's a weird coincidence that uwsgi-core and mod_md happened to have that same dep and caused the confusion on my part. :)
<rbasak> infinity: the magic isn't implemented yet
<ahasenack> no, adconrad
<infinity> ahasenack: ~adconrad
<infinity> rbasak: Wait, really?
<infinity> rbasak: So, if I upload apache2, your branches all go to poop?
<rbasak> If you just upload, then the importer will manage, but the git commits won't be incorporated. New commits will be synthesized by the importer instead, but only one for each upload.
<rbasak> The unimplmeneted magic is to be able to detect the MP and incorporate automatically, or similar.
<infinity> rbasak: Oh, sure.  But that's almost more desirable.  A single rebase-style commit is more readable than "here's some changes, here's a changelog". :P
<infinity> (Why do people always commit changelogs separately?)
<rbasak> In the meantime, we can incorporate manually by pushing an "upload tag" so the importer will find it when it sees the upload. Currently that's restricted to ~usd-import-team.
<rbasak> I insist on commiting changelogs separately, since it reduces hell when cherry-picking.
<rbasak> IMHO, git makes changelogs inside source trees obsolete. They should be generated from commits when needed instead.
<ahasenack> changelog always conflicts
<infinity> Kids these days.
<ahasenack> :)
<infinity> rbasak: Well, if you want to do the thing "properly" (I'm not in the mood to learn a new workflow), go to town, I'm +1 on the debdiff in the PPA.
<infinity> Which is supposedly what the branch diff is, but LP's diff is broken beyond recognition.
<rbasak> I was just looking at that. I don't understand why it's broken. I'll dig.
<ahasenack> rbasak: it's been like this for all apache mps
<ahasenack> I vaguely remember nacc saying something about a bug in python[23]?-git or whatever the name of that module is
<infinity> That would seem to imply that it's very confused about what the target branch actually is.
<ahasenack> the lp diff is correct for the top part
<infinity> So it is.
<ahasenack> it breaks once it hits that docs directory
<infinity> The other 1400 files, though...
<cjwatson> debian/changelog is IMO closer to a NEWS file than to a trad ChangeLog file.  I agree that git makes the latter obsolete, but not the former.
<rbasak> I think it makes sense to maintain a NEWS file in a git-based source tree, but I'd want it to be done in separate commits (perhaps at release time, to nicely aggregate things together) to avoid the conflict hell.
<infinity> Or learn to CP without picking the NEWS bits?
 * infinity shrugs.
<infinity> I think a news item belongs with the commit it's referring to, so I can trace back that way.
<rbasak> I'm quite capable of doing that but that doesn't stop it being painful
<infinity> blame the news file, find the commit.
<ahasenack> I'll be back in ~30m, need to fetch Ted from the pet store from his bath
<rbasak> For our merge workflow, you end up having to resolve the conflict manually for every single Ubuntu upload since the divergence point.
<rbasak> I'm sure git could be taught to resolve that itself automatically somehow, but we don't even want those parts cherry-picked anyway.
<rbasak> The news file won't necessarily have a 1-1 correlation between commits and entries anyway
<rbasak> The MP is identical to the PPA diff except for the changelog version as expected.
<infinity> Then +1 from me.
<rbasak> ahasenack: so I pushed the upload tag for you. Upload when ready.
<infinity> Go forth and merge/upload, pretty please.
<stgraber> LocutusOfBorg: I don't even remember doing that :) so may very well not be needed anymore indeed
<LocutusOfBorg> stgraber, ack thanks!
<ahasenack> back
<ahasenack> rbasak: ok, thanks
<LocutusOfBorg> doko, https://launchpadlibrarian.net/376363514/buildlog_ubuntu-cosmic-amd64.python-taskflow_3.1.0-0ubuntu5_BUILDING.txt.gz
<LocutusOfBorg> do you have any idea? it seems to be related to new python?
<nacc> ahasenack: rbasak: yeah, i dug into it and it seems like it's something was in pygit2 or libgit2, but i forget immeidately
<ahasenack> nacc: ok
<nacc> ahasenack: in theory, we should be able to reproduce the diff that LP shows via turnip (iirc, that's the name of the project)
<nacc> ahasenack: by tracing that code to the diff generation (which I believe is pretty straightforward) and then seeing if we can get the same thing in a simple tool
<rbasak> nacc: thanks!
<rbasak> I'll chase it up at some point.
<nacc> rbasak: np, i remember in one case, I couldn't get pygit2 to get me quite the same thing, and that's about all I remember right now
<cjwatson> Start from turnip.api.views.DiffMergeAPI
<cjwatson> And if you want to reproduce exact versions and such, use a trusty container with ppa:launchpad/ubuntu/ppa
<rbasak> Thanks! I filed bug 1779178 so as to keep that info around for later.
<ubottu> bug 1779178 in usd-importer "git diff generation is sometimes wrong" [Undecided,Triaged] https://launchpad.net/bugs/1779178
<bdmurray> manjo: Could you respond re the verification of bug 1716517 so we can get it released?
<ubottu> bug 1716517 in The Ubuntu-power-systems project "[arm64/ppc64le] load ipmi_ssif/ipmi_powernv instead of ipmi_si" [Low,Incomplete] https://launchpad.net/bugs/1716517
<manjo> bdmurray, done
<bdmurray> manjo: but it says "Installed: (none)" in the apt policy output
<manjo> right .. I skipped a step where I did the apt install openipmi
<manjo> so in between the status and apt policy there was an apt install which I did not cut and past .. I assume . .that would be obvious
<manjo> s/assume/assumed
<bdmurray> well its inconsistent in that comment #20 you showed the version installed (which is really the best practice)
<manjo> bdmurray, I can repeat the test if you need
<bdmurray> manjo: nah, its fine. just going forward please run 'apt policy' with the package installed
<manjo> bdmurray, ack .. won't screw up
<manjo> bdmurray, thanks for reaching out to me
<ahasenack> bdmurray: is this your sru day? Is https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1766186 next or close to next perhaps? :)
<ubottu> Launchpad bug 1766186 in apache2 (Ubuntu Bionic) "IncludeOptional fails when a directory does not exist" [Low,Fix committed]
<bdmurray> ahasenack: It is, have these autopkgtest regressions been investigated?
<ahasenack> "these"? hm
<ahasenack> no, I wasn't aware of them, my fault
<bdmurray> no problem we could do better about messaging the failures
<ahasenack> I keep assuming that if the upload made it, the tests passed
<coreycb> LocutusOfBorg: the taskflow upload seems to be causing issues
<coreycb> LocutusOfBorg: https://paste.ubuntu.com/p/wvS4kqmckj/
<coreycb> not sure why that fails though. OrderedDiGraph inherits from DiGraph which defines nodes_iter.
<LocutusOfBorg> coreycb, where did you take it? the fixed one is waiting for python breakage to reduce a bit https://launchpad.net/ubuntu/+source/python-taskflow/3.1.0-0ubuntu5/+build/15064887
<LocutusOfBorg> I suspect this is because of new networkx
<coreycb> LocutusOfBorg: i have a nova build that picked it up from cosmic-proposed
<coreycb> or maybe not, checking. i probably need the new one is what the issue is.
<coreycb> LocutusOfBorg: ok yeah i'm using 3.1.0-0ubuntu4. i'll wait on 3.1.0-0ubuntu5. sorry and thanks :)
<LocutusOfBorg> coreycb, nice to know :) I don't even know if it will build or not BTW
<LocutusOfBorg> I hope and I have fingers crossed!
<coreycb> LocutusOfBorg: ok, then i'll cross my fingers too :)
<LocutusOfBorg> coreycb, 4 pkg-openstack packages required patches to work with python3.7, "async" keyword being now reserved
<LocutusOfBorg> I suspect lots of breakage in the archive :/
<LocutusOfBorg> hello jamespage, please merge kazoo from Debian?
<LocutusOfBorg> I don't know if new deps requires mir or not...
<LocutusOfBorg> neither if python now has automagic autopkgtest
<doko> LocutusOfBorg: I'll have a look once I'm finished with all these no-change uploads
#ubuntu-devel 2018-06-29
<LocutusOfBorg> doko, I think I have fixed them, but a double check would be awesome
<LocutusOfBorg> kazoo python-tenacity and psycopg2
<juliank> It seems one of the hosts hosting archive.ubuntu.com is outdated, in 4 runs with xenial-proposed, I only got apt to upgrade itself to the proposed version once.
<sarnold> juliank: btw curl's --resolve is the easiest way to track down which servers have which contents
<juliank> sarnold: nice, letme check
<juliank> hmm
<juliank> I see it everywhere with curl
<sarnold> hrm, I wonder if they got in sync inthe meantime or ..
<sarnold> oh well, that's for someone more awake than me :)
<tomreyn> for IP in `dig -t A archive.ubuntu.com +short` `dig -t AAAA archive.ubuntu.com +short`; do echo "$IP: $(curl --silent --resolve archive.ubuntu.com:80:$IP http://archive.ubuntu.com/ubuntu/dists/xenial-proposed/Release | grep ^Date: | cut -d ' ' -f2-)" ; done
<tomreyn> looks identical to me
<juliank> I still get some runs where apt install apt does not find it
<juliank> maybe I'm hitting a bug in apt somewhere
<juliank> Yup, it seems to be a bug in apt
<juliank> 'grep ^Package.*apt /var/lib/apt/lists/archive.ubuntu.com*Packages'
<juliank> Package: apt
<juliank> succeeds
<juliank> but apt-cache shows no apt version in a repository
<juliank> In fact, the cache only contains the status file
<juliank> might be a race with some cloud stuff when initializing the container
<juliank> simple test case: https://paste.ubuntu.com/p/4Zzw6mnhKg/
<juliank> just launch a new container, wait 5 seconds
<juliank> replaces sources.list, run update
<juliank> => you only see dpkg status file
<juliank> sarnold: tomreyn so the problem I was seeing is that cloud-init rewrites the sources.list file after I rewrote it, and thus my newly added proposed repo goes missing
<juliank> I guess I have to modify my scripts to wait for cloud-init to settle first
<tomreyn> juliank: why dont you place yours in /etc/apt/sources.list.d/ instead?
<juliank> tomreyn: mostly don't want to download all the other stuff in the default sources.list
<juliank> performance!
<juliank> could -o dir::etc::sourcelist=/dev/null, though
<didrocks> xnox: do you mind merging https://code.launchpad.net/~didrocks/apport/whoopsie-auto-ui/+merge/348479? We would like to upload to cosmic today and seb128 approved it but can't merge (nor can I)
<didrocks> or maybe juliank, I saw you touched apport recently :)
<didrocks> juliank: so, if I take the bzr branch (lp:apport), all the snap part isn't in it, and the bzr-ubuntu branch is outdated versus the repo
<didrocks> I'm happy to apply a debdiff, but it seems we don't have any source of truth anymore?
<juliank> didrocks: apport is complicated
<juliank> didrocks: the ubuntu branch seems up to date? https://code.launchpad.net/~ubuntu-core-dev/ubuntu/cosmic/apport/ubuntu
<juliank> not sure what you were looking at
<didrocks> juliank: the cosmic one is, not binoic
<didrocks> bionic*
<didrocks> juliank: but what do you generally do, merge lp:apport into this one?
<didrocks> and so, you have the snap stuff into /ubuntu but not upstream apport?
<juliank> didrocks: I leave it to bdmurray to handle that
<juliank> but yes, the snap stuff is in ubuntu only
<juliank> didrocks: sometimes people don't push bzr branches for stable stuff
<didrocks> juliank: yeah, it's kind of annoying as we have inline deltas with upstream
<juliank> Yeah
<didrocks> ok, I'll upload a debdiff then for now (at least cosmic)
<didrocks> the branch is up for upstream to merge
<didrocks> and I'm happy to have a bionic/ branch ready if up to date
<juliank> maybe cyphermox and bdmurray have some branches locally for their uploads
<juliank> (apport 2.20.9-0ubuntu{7,7.1,7.2} for bionic)
<juliank> Otherwise, I'd say import the dscs
<juliank> :D
<didrocks> yeah, also those are native packages, which isn't expected from the version, as told the other day
<didrocks> (and no release :p)
<juliank> yes
<didrocks> but yeah, let me create a debdiff, that way, I'm sure to not revert your work ;)
<juliank> they were not initially
<didrocks> yeah, and we didn't have distro-patches
<didrocks> and .pot was updated ;)
<didrocks> (not only when building the package)
<didrocks> anyway, not that important for now, but I'm happy to help fixing anything that needs to be fixed in case
<xnox> did didrocks quit?
<seb128> yes, he called it a week
<seb128> he had the apport changes uploaded which was a good point to stop working
<seb128> :-)
<sarnold> juliank: ugh :/ thanks for the feedback
<Unit193> cjwatson: BTW, thanks for putting some time in on new SSH key types.
<cjwatson> incremental progress :)
<Unit193> Yes, I've been following upstream get stuck on it, out of your court and you're still prepping for when they do add support.
<cjwatson> ECDSA is doable now, though I'm not especially wild about that format.
<Unit193> Unfortunately I'm waiting for Ed25519.
<cjwatson> Yeah, I use that most other places now.
<cjwatson> (At least merely offering it to Launchpad no longer causes an SSH hang.)
<Unit193> Huh, cool.
<bluesabre> infinity: would you be interested in reviewing the xubuntu core/base patches? https://code.launchpad.net/~xubuntu-dev/debian-cd/xubuntu-base/+merge/347414 - https://code.launchpad.net/~xubuntu-dev/livecd-rootfs/xubuntu-base/+merge/347319 - https://code.launchpad.net/~xubuntu-dev/ubuntu-cdimage/xubuntu-base/+merge/347320 (or do you know who might be? :))
<infinity> bluesabre: TBH, I've been dragging my feet a bit because there's been some discussion that we really should do stacked livefses in ubiquity, which would allow you to have both "flavours" in one ISO.
<infinity> bluesabre: Of course, if the only real goal here is a smaller download, then you really do want two different ISOs.
<bluesabre> infinity: I think the team is interested in the dual-iso solution. We've been spinning the Core iso for each release since the 2015 announcement and getting testing on it. One of the reasons it's promoted is the smaller size, for those with limited bandwidth or CD-drive requirements
<infinity> bluesabre: Kay, fair enough.  Icky, but understandable.
<bluesabre> :)
#ubuntu-devel 2018-06-30
<infinity> smoser: curtin's btrfs-tools dep is muy obsolete.  Can you update it to either btrfs-progs or "brtfs-progs | btrfs-tools" if you're aiming for backportability?
#ubuntu-devel 2018-07-01
<Tecan> strangest thing, in mate desktop the sleep inhibitor applet is a cpu pig, uses 8% cpu itself and causes xorg to use an additional 15%
<smoser> infinity: ack. rharper can maybe get to that this week https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1779521
<ubottu> Launchpad bug 1779521 in curtin (Ubuntu) "update obsolete dependency on btrfs-tools" [Medium,Confirmed]
<Tecan> https://github.com/mate-desktop/mate-panel/issues/831#issuecomment-401580080
<bluesabre> Any core devs interested in sponsoring a fix to gvfs? https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1762595
<ubottu> Launchpad bug 1762595 in gvfs (Ubuntu Cosmic) "Thunar incorrectly thinks USB storage device hasn't finished ejecting" [Undecided,Confirmed]
#ubuntu-devel 2019-06-24
<The_Ball> Where can I find git repos for how packages are built? Debian uses salsa.debian.org, is there an equivalent for Ubuntu?
<Skuggen> The_Ball: It's often specified in the package metadata
<Skuggen> If you run apt-cache showsrc <package>, see if there are "Vcs-" fields
<The_Ball> Skuggen, ah, thank you very much
<Skuggen> Many Ubuntu packages are just synced from Debian (or with small patches applied on top)
<The_Ball> Skuggen, doesn't look like python-twisted has the vcs fields, but I was able to find the source -> git clone https://git.launchpad.net/ubuntu/+source/twisted
<The_Ball> The twisted package is lagging a bit from Debian so I have to backport one fix
<Skuggen> Looks like it's just synced directly from debian. At least on bionic it has a debian version string
<cjwatson> Yep, it's in sync between Debian unstable and Ubuntu eoan right now
<LocutusOfBorg> vorlon, xnox I'm syncing mono, the s390x build has been successful!
<xnox> nice
<LocutusOfBorg> xnox, to be honest, instead of building with -O0, Debian decided to disable docs generation on s390x with --with-mcs-docs=no
 * LocutusOfBorg updates bug https://bugs.launchpad.net/ubuntu/+source/mono/+bug/1525454
<ubottu> Launchpad bug 1525454 in mono (Ubuntu) "bootstrapping mono compiler fails at mdoc" [Undecided,Fix released]
<LocutusOfBorg> bdrung, https://launchpad.net/~videolan/+members#active can you please add me back?
<teward> tsimonq2: i noticed in the tests that they are using snapped Chromium to power Selenium.  I wonder if that's what's broken on their test...
<Laney> blorp
<teward> Laney: TL;DR it's broken and it's your fault :p
<teward> just kidding ;)
<Laney> I feel like that *should* work
<Laney> teward: can you file a bug please?
<teward> Laney: bug on...?
<Laney> will ask if oSoMoN can take a look
<Laney> kopano thing
<teward> ah yes
<teward> Laney: if you can take a peek at the autopkgtest failures as well and see if I'm right that it's Chromium related
<teward> and if I can badtest it temporarily
<teward> or get it badtested*
<Laney> I would expect that's the relevant change
<teward> probably.
<teward> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/k/kopano-webapp/20190624_082152_0ef6d@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/arm64/k/kopano-webapp/20190624_084645_0ef6d@/log.gz
<teward> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/armhf/k/kopano-webapp/20190624_082623_0ef6d@/log.gz
<teward> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/k/kopano-webapp/20190624_082523_0ef6d@/log.gz  the 4 buildfailures
<teward> s/buildfailures/test failures/
<teward> 3 of them are CHromium crashes
<teward> 4th said something about snaps not working on the arch
<teward> Laney: bug against chromium or the kopano-webapp package?
<Laney> probably chromium for now
<teward> Laney: i filed an autopkgtest failures bug against kopano-webapp reporting the test failures; if it's indeed a Chromium issue they can still look into it.  https://bugs.launchpad.net/ubuntu/+source/kopano-webapp/+bug/1834052
<ubottu> Launchpad bug 1834052 in kopano-webapp (Ubuntu) "autopkgtest failures: Chromium-Related" [Undecided,New]
<Laney> thanks
<Laney> kenvandine: ^---- is ok to ask Olivier to look at this?
<teward> Laney: may still ask for it to be badtested if "No Easy Fix" is the problem here.
<teward> since one of them was some complaint about incompatible architecture or something
<Laney> yeah maybe, but I feel like we should be able to run snaps there
<Laney> give us a couple of days
<teward> Laney: indeed.  armhf seems to be the hjeadache: ==> Installing the chromium snap   error: system does not fully support snapd: apparmor detected but insufficient permissions to use it
<teward> but i'm more concerned with the chromium crashes on the other ones
<teward> i'm also confused WHY the test pulls in Chromium just to test what's in the title of the navbar
<teward> they could just curl that...
<teward> (seems like an overly heavy test IMO)
<Laney> Not sure - I'm just concerned that we don't break Selinium on Chromium
<teward> ack
<teward> the only reason I care as of late is because I pushed the distropatch from TJ that fixes NGINX's pidfile race conditions in SystemD
<teward> which are addressed by changing how NGINX handles pidfiles
<teward> and it SEEMS to work in production
<Laney> ð¤
<seb128> cpaelzer, thanks for the lmdb MIR review!
<cpaelzer> yw seb128
<kenvandine> Laney: check with seb128, oSoMoN is on his team now
<seb128> Laney, create a card on the trello board please and yes it's fine to ping Olivier about it
<Laney> ah sry I forgot that
<Laney> I am making a card, it's a -proposed item after all :>
<seb128> thx
<ginggs> https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts \o/
<ginggs> now that we know i386 will only be running on amd64 hardware, is it possible to raise the baseline to i386+sse2 or so?
<tsimonq2> doko, vorlon: ^
<mitya57> xnox: hi, have you seen bug 1832295?
<ubottu> bug 1832295 in lighttpd (Ubuntu) "lighttpd broken by OpenSSL update" [Critical,Confirmed] https://launchpad.net/bugs/1832295
<xnox> mitya57:  thanks!
<vorlon> ginggs, tsimonq2, doko: making a change to raise the baseline for i386 introduces the possibility of build regressions; I think we should certainly consider i386 to be in maintenance mode
<sarnold> is it worth selecting which packages we will build i386? or which packages we will not? (I'm thinking specifically of The Big Browsers and LO.. ceph?)
<vorlon> sarnold: https://blog.ubuntu.com/2019/06/24/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts explicitly says we will select, with community input
<sarnold> vorlon: yay, thanks
#ubuntu-devel 2019-06-25
<tsimonq2> vorlon: ack, thanks.
<mitya57> xnox: thanks to you :)
<LocutusOfBorg> xnox, boxbackup merge/sync please? there is an openssl 1.1 build fix
<LocutusOfBorg> also xonsh might be syncable now...
<LocutusOfBorg> also meson and something more...
<xnox> LocutusOfBorg:  can try these.
<LocutusOfBorg> ta
<xnox> LocutusOfBorg:  i beleive meson will require a merge, but can try doing force sync to see if it got better or not
<LocutusOfBorg> xnox, yes that was my intention, prepare a merge and upload or not based on autopkgtests
<odc> the launchpad.net certificate has expired :(
<odc> or is it just me?
<LocutusOfBorg> September 15, 2019
<LocutusOfBorg> I would say just you
<rikmills> bugs.launchpad.net has expired
<LocutusOfBorg> that one is expired, indeed
<odc> yes, it only happens on bugs.lp.net
<odc> thought it was the same
<rikmills> just been flagged to #canonical-sysadmin channel
<LocutusOfBorg> notAfter=Jun 25 12:00:00 2019 GMT
<LocutusOfBorg> x
<LocutusOfBorg> sahid, hello, I fixed your python-ddt upload, otherwise cinder was not building at all
<LocutusOfBorg> please be careful about your upstream tarballs next time :)
<LocutusOfBorg> and sync from Debian if possible
<LocutusOfBorg> mismatching tarballs are PITA to have
<LocutusOfBorg> xnox, looks lie boxbackup needs help...
<sahid> LocutusOfBorg: yes true i was actually working on it, how did you fixed it?
<sahid> I can't see your change in ubuntu-server-dev
<sahid> the problem is that debian.net does not provide doc with the tarball
<sahid> and jamespage just proposed to me to use the one from debian experimental
<jamespage> sahid, LocutusOfBorg: pkg-openstack in debian generally snapshot from git, so they don't use a sdist generated tarball
<jamespage> hence why the version in experimental has the docs subfolder.
<LocutusOfBorg> sahid, that one, syncing from experimental did the trick
<LocutusOfBorg> I don't honestly care about how debian generated it :) it works
<LocutusOfBorg> maybe bugging upstream about fixing their tarball is worth doing
<sahid> LocutusOfBorg: in all cases thanks for your help on it :)
<jamespage> LocutusOfBorg: yup - that was the next step (patch upstream to include docs folder in release sdist)
<jamespage> ok so now for a broader eoan question - I know python2.7 is going to universe this cycle; do we have an objective to remove all of the python-* packages in archive?
<jamespage> debian experimental seems to contain alot of pre-work towards that goal
<jamespage> LocutusOfBorg: python-ddt being a case in point - the reverse-depends list of binary:python-ddt is quite long
<jamespage> which is why we had not synced (yet)
<LocutusOfBorg> jamespage, uploading a broken 1.2.1-0ubuntu1 makes no difference wrt syncing 1.2.1-1 from experimental... does it?
<Eickmeyer> Working on some packaging and I'm having trouble getting some lintian-overrides to take. Any idea what I'm doing wrong? https://code.launchpad.net/~eeickmeyer/+git/raysession (I'm still learning)
<vorlon> Eickmeyer: I see you've created debian/source/lintian-overrides.  I don't recall if this is a supported path (the path I'm used to is debian/source.lintian-overrides; debian/source/lintian-overrides may be supported nowadays but it looks jarring to me to include this in debian/source which is otherwise instructions to dpkg-source).  But the real problem is that the overrides you're declaring there
<vorlon> are overrides for binary packages, not for the source
<vorlon> Eickmeyer: you need a debian/$binary_package.lintian-overrides for the binary-level overrides
<Eickmeyer> vorlon: Thanks, I'll give that a shot.
<cjwatson> vorlon: It's the path that Lintian prefers and documents nowadays
<cjwatson> There's a pedantic-severity tag for using debian/source.lintian-overrides
<cjwatson> (Not disagreeing with you about debian/$binary_package.lintian-overrides)
<Eickmeyer> cjwatson, vorlon: Yeah, that's what I read in the documentation.
<vorlon> cjwatson: :)
<tsimonq2> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots: tsimonq2
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040751.html
<tsimonq2> Wimpress, popey: Would someone with more experience with snaps than I be able to confirm that this bugfix works? bug 1802483
<ubottu> bug 1802483 in libnotify (Ubuntu) "Notifications emitted by a snap with local files or desktop files use wrong namespace" [Medium,In progress] https://launchpad.net/bugs/1802483
<tsimonq2> It's been in the sponsorship queue for a while.
<Laney> That fix needs properly reviewing
<tsimonq2> Laney: I agree.
<tsimonq2> Bug 1770093 needs review from someone who works with Pi stuff more than I do; I have a Pi 3 and I'll circle back once I can get an SD card for it later this week, if needed.
<ubottu> bug 1770093 in ubiquity (Ubuntu) "Ubiquity crashes with mount points that are FAT16/32" [Undecided,New] https://launchpad.net/bugs/1770093
<tsimonq2> sil2100: Poke on reviewing bug 1814118 when you get the chance.
<ubottu> bug 1814118 in rpi.gpio (Ubuntu Cosmic) "Make RPi.GPIO work on arm64" [Low,New] https://launchpad.net/bugs/1814118
<tsimonq2> bluesabre: I'm looking at bug 1822380 and I wanted to get your feedback as to what's left here. I don't see any other debdiff specifically that needs sponsoring, so I'll unsubscribe sponsors, but it does seem there's a GTK bug here.
<ubottu> bug 1822380 in gtk+3.0 (Ubuntu) "Thunar right-click menu not expanded" [Low,Triaged] https://launchpad.net/bugs/1822380
<tsimonq2> Hmm, it looks like the upstream GTK issue isn't getting much traction. https://gitlab.gnome.org/GNOME/gtk/issues/1843
<tsimonq2> I'm willing to bet a Git bisect will reveal the issue. I'll circle back later this week when I look at Pi stuff.
<tsimonq2> Well, I do see a random patch from an obscure forum post. What could go wrong? :P
<tsimonq2> jamespage: Would you (or someone else with knowledge of the swift package) be able to take a look at bug 1827340? It's been in the sponsorship queue for a bit.
<ubottu> bug 1827340 in swift (Ubuntu) "swift-container package is missing Upstart and System V files for the container-sharder service" [Low,In progress] https://launchpad.net/bugs/1827340
<tsimonq2> juliank: Debian bug 927876 's Ubuntu counterpart, bug 1766068, has been in the sponsorship queue for a bit. Would you be able to review the patch when you can?
<ubottu> Debian bug 927876 in command-not-found "zsh: Does not print 'command not found' message if handler does not match" [Important,Open] http://bugs.debian.org/927876
<ubottu> bug 1766068 in command-not-found (Ubuntu) "Using Zsh, it doesn't show an error message when command not found" [Low,Triaged] https://launchpad.net/bugs/1766068
<tsimonq2> cyphermox: Did you plan on driving the SRU for bug 1828948 as well?
<ubottu> bug 1828948 in dkms (Ubuntu Bionic) "OBSOLETE_BY in DKMS.CONF not work" [High,New] https://launchpad.net/bugs/1828948
<cyphermox> tsimonq2: yes
<tsimonq2> cyphermox: Sounds good, thanks.
<Eickmeyer> vorlon: RE: lintian-overrides, that did not work. lintian is still throwing invalid errors on the binary.
<vorlon> Eickmeyer: I don't believe ' binary' is part of the expected content of the override
<vorlon> i.e. it should be $bin_pkg_name: $lintian_tag_name $other_info
<Eickmeyer> vorlon: Thanks for the hint, will make the change.
<Eickmeyer> vorlon: That didn't work. Does it need "#/usr/bin/python3" appended?
<Eickmeyer> rather, #!/usr/bin/python3
<tsimonq2> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040752.html
<Eickmeyer> tsimonq2: I (very quickly) provided the links you requested.
<tsimonq2> Eickmeyer: Thanks.
<Eickmeyer> vorlon: Answered my own question. It needed the #! line too. Thanks!
<sarnold> is that the lintian thing?
<Eickmeyer> sarnold: Yep. You can look for yourself at what it needed.
<Eickmeyer> If you want...
<sarnold> woot
<Eickmeyer> \o/
<bdmurray> ahasenack: We, the foundations team, would close bug 1810780 but it is assigned to you. Are you still planning on doing any work there?
<ubottu> bug 1810780 in lftp (Ubuntu) "FTBFS: missing zlib1g-dev" [Undecided,In progress] https://launchpad.net/bugs/1810780
<ahasenack> oh, ow
<ahasenack> let me check
<ahasenack> bdmurray: it can be closed. My mp was rejected because debian fixed in while it was in review, so no changes needed.
<ahasenack> bdmurray: is cosmic still affected, though?
<ahasenack> my mp was for disco
<bdmurray> ahasenack: It could be but end of life for cosmic is near
<ahasenack> I see. Well, I'm not working on that, and if this package needs an sru for another reason, the ftbfs fix is simple enough
<ahasenack> I think this is fix released for disco, and a cosmic task may or may not be added
<ahasenack> adjusted
<juliank> tsimonq2: Sure, but note that Ubuntu is upstream, Debian is downstream
<juliank> Debian tracks the latest LTS version of c-n-f, and software-properties
<juliank> I'll be tracking stuff more aggressively post buster I think, as this improves quality for everyone
<bdmurray> ahasenack: Thanks!
#ubuntu-devel 2019-06-26
<seb128> bdmurray, bug #1513528 you tagged it as rls-ee-incoming but there has been no report on disco or eoan so far, I'm unsure what's the logic behind the nomination? how a bug that got 0 report can be a rls candidate for that serie?
<ubottu> bug 1513528 in software-properties (Ubuntu) "/usr/bin/software-properties-gtk:KeyError:__getitem__:__getitem__:show_drivers:set_driver_action_status:__getitem__" [Undecided,New] https://launchpad.net/bugs/1513528
<LocutusOfBorg> coreycb, what about syncing congress from Debian?
<sil2100> Laney: woot! SRU commenting works: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1832374/comments/8
<ubottu> Launchpad bug 1832374 in gnome-settings-daemon (Ubuntu Disco) "Media keys stop working due to missing service file" [Undecided,Fix committed]
<sil2100> Laney: I'll have to create/switch to some bot account for the messages though
<cpaelzer> seb128: I see you retried spcie as well - I haven't found the time to file the bug yesterday - I hope you didn't waste more time on it
<cpaelzer> the upload that should resolve it is already in E-proposed
<LocutusOfBorg> xnox, looks like from all the syncs, only boxbackup is sad... can I fix or do you want to take it?
<cpaelzer> but I see that you have found the bug today :-)
<seb128> cpaelzer, I didn't, I shouldn't have clicked that retry, I had a bunch of things open in tabs and clicked that one by error, I meant to look at the log first
<seb128> cpaelzer, right :)
<seb128> thx
<cpaelzer> hehe
<cpaelzer> ok I only was concerend you'd have spent hour(s) on debugging this
<cpaelzer> we are good then
<seb128> I didn't
<seb128> thx for the ping :)
<Laney> sil2100: nice!
<sil2100> And I guess next step is to make the comment a bit more verbose, with what specific tests are failing etc.
<Laney> sil2100: there's an Ubuntu Archive Bot account isn't there, maybe you can spoof its address?
<Laney> on the other hand you will get karma from these comments ;-)
<sahid> LocutusOfBorg: anychance you review https://git.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/python-mimeparse/ ?
<sahid> buildlog here: https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/eoan-train-proposed/+build/17192172
<LocutusOfBorg> sahid, sure, if you first push changes in Debian on the two bugs open about new release, I can review/upload to experimental and then sync to Ubuntu
<LocutusOfBorg> uploading such delta as Ubuntu only seems just stupid...
<LocutusOfBorg> (unless there is an Ubuntu-only bug, but this isn't the case to me)
<sahid> LocutusOfBorg: I was working on OpenStack Train snapshots, zaqar is requiring python-falcon 1.1.0 so I bumped the version but python-falcon 1.1.0 is requiring python-mimeparse 1.5.2 so I bumped the version
<sahid> LocutusOfBorg: also I think debian experimental is removing python2 support which will create for us lot of difficulties
<LocutusOfBorg> sahid, nobody is removing python2 yet
<sahid> LocutusOfBorg: right, I'm woking on the package update for debian, should be ready soon
<sahid> LocutusOfBorg: https://salsa.debian.org/sahid-guest/python-mimeparse
<LocutusOfBorg> sahid, can you please also open a merge request against https://salsa.debian.org/python-team/modules/python-mimeparse ?
<LocutusOfBorg> screw that, you already did a good job
<LocutusOfBorg> sahid, did you forget to push pristine-tar branch?
<LocutusOfBorg> I'm converting to pybuild
<LocutusOfBorg> you did some mistake, e.g. wrong -0 version (should be -1)
<LocutusOfBorg> and missed the "closes" bugs in new release
<LocutusOfBorg> but the other stuff looks good
<LocutusOfBorg> sahid, please see my changes
<LocutusOfBorg> uploaded in Ubuntu too
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/python-mimeparse/1.6.0-1~build1
<LocutusOfBorg> you are now on your own to fix bugs :D
<sahid> great thanks LocutusOfBorg
<sahid> and thanks for the fixes
<GunnarHj> cyphermox: Hi Mathieu, yesterday you added a couple of packages, including gnome-control-center, to the ubuntu-desktop packageset. As a new ubuntu-desktop member I just tried to upload g-c-c to disco, but it was rejected. Any chance you can make the changes in the ubuntu-desktop set for disco (and bionic) too?
<GunnarHj> cyphermox: I also sent a mail to DMB with the same request.
<sil2100> GunnarHj: I can do that
<GunnarHj> sil2100: Excellent, thanks!
<woenx> Hello everyone. I'm trying to compile an application, and also compile some of its dependencies, because the ones in the repositories are not recent enough. Particularly, I am having trouble with libexiv2. It seems to have compiled correctly, as I can run the command and all witout errors, but it is not detected by the other software I want to compile (digikam). One of  the developers suggested it might have something to do with
<woenx> PKGConfig not find the library. How could I check that?
<woenx> They told me this is the script that checks for libexiv2 while compiling: https://cgit.kde.org/digikam.git/tree/core/cmake/modules/FindExiv2.cmake
<rbasak> woenx: this channel is for development of Ubuntu itself, as opposed to development _on_ Ubuntu.
<woenx> Oh, ok
<rbasak> woenx: I'm not sure where to suggest on IRC.
<rbasak> woenx: you might try askubuntu.com
<woenx> I might, thank you
<LocutusOfBorg> oSoMoN, can I fixup sphinx build failure?
<LocutusOfBorg> oops looks like my fix didn't work
<oSoMoN> LocutusOfBorg, be my guest if you have a fix that works for python 2 and 3. Note that according to https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1834236/comments/6 the bug is in Python 3.7.4, and is already fixed there, so the next upload of python3.7 should resolve the situation
<ubottu> Launchpad bug 1834236 in python3.7 (Ubuntu) "codecs.open(errors='strict') doesn't fail on invalid encoding with python3.7.4 RC1" [Undecided,New]
<doko> I'm waiting for the 3.7.4 release which should be tomorrow
<LocutusOfBorg> nice oSoMoN !
<bdmurray> seb128: I wanted to talk about the bug with the Foundations team during our meeting.
<seb128> bdmurray, ah ok
<bdmurray> I guess rls-bb-incoming would have been more appropriate...
<bdmurray> although this looks like a smiliar issue https://errors.ubuntu.com/problem/7aae2289a43859d4f1ec3b362edf284bcc6dca7a
<rbasak> ddstreet: thank you for driving bug 1556302
<rbasak> Would it be worth release noting that change?
<ubottu> bug 1556302 in sudo (Ubuntu Disco) "Ubuntu patch to add HOME to env_keep makes custom commands vulnerable by default" [Low,In progress] https://launchpad.net/bugs/1556302
<seb128> bdmurray, yeah, if the bug is abour bionic rls-bb-incoming makes probably more sense
<ddstreet> rbasak yes, i think it would be worth adding to the release notes
<cpaelzer> I'm failing to see why exactly the build actually breaks on https://launchpadlibrarian.net/430699542/buildlog_ubuntu-eoan-amd64.qemu_1%3A4.0+dfsg-0ubuntu1~ppa6_BUILDING.txt.gz (PPA) or http://paste.ubuntu.com/p/Rt5wXwR2mP/  (sbuild)
<cpaelzer> if these build logs ring a bell for someone let me know the hints that you have
<cpaelzer> they fail reproducibly, but at slightly different places as if it would fail after x time or y space (no matter where it is at that time)
<tsimonq2> cpaelzer: Is there a diff between a known good's debian/rules and this version's debian/rules?
<cpaelzer> tsimonq2: same d/rules as in the qemu 3.1 in Eoan atm (no change yet for qemu 4.0 which this is) -> http://paste.ubuntu.com/p/ZMgxCdT8q7/
<cpaelzer> I might rebuild a qemu 3.1 tomorrow in Eoan to know if it might be some other change in Eoan that triggers this behavior
<cpaelzer> I'll call it a day, but if anyone sees something in these logs hints are welcome :-)
<cpaelzer> cu
<tsimonq2> I don't know on this one :)
<ddstreet> cpaelzer looks to be failing due to:
<ddstreet> dh_install: qemu-system-data missing files: pc-bios/qemu_logo_no_text.svg
<ddstreet> dh_install: missing files, aborting
<ddstreet> make: *** [debian/rules:345: binary-indep] Error 25
<ddstreet> make: *** Waiting for unfinished jobs....
<ddstreet> plus a couple other missing files on the lines right above that
<wxl> with germinate-update-metapackage, it doesn't seem to take %(dist) as the value for the distribution field in d/changelog. should that be considered a bug or is there some other mitigation i'm not aware of for this?
<TJ-> wxl: shouldn't it be %(dist)s  or did you not type the "s" suffix?
<wxl> TJ-: well, that's what it is.. i was just typing it out in a way that sounded grammatically correct XD
<roaksoax> p/win 2
<TJ-> wxl: so far as I can tell germinate-update-metapackage only uses replaceable python variables within update.cfg itself
<wxl> TJ-: why it doesn't take dist to update distribution in the changelog is beyond me
<cjwatson> wxl: it just calls dch, and dch's default behaviour is to put UNRELEASED in new changelog entries rather than any particular series; so it's out of scope for germinate-update-metapackage
<cjwatson> it is intended that you will separately use dch -r when you've decided to release the package.  (after all, germinate-update-metapackage might reasonably not be the only change you make)
<wxl> cjwatson: works for me, thanks!
<wxl> thanks cjwatson :)
#ubuntu-devel 2019-06-27
<TJ-> cjwatson: question about "dch -r" - I just noticed it doesn't do what the man-page says, which is to use the previous changelog distribution entry, instead it inserted the host OS's distribution. Specifically, I was working on  host bionic with a package that had "unstable" as the last changelog entry
<TJ-> cjwatson: is the man-page out of sync or do I misunderstand ?
<kyrofa> It seems pygraphviz is busted in bionic for armhf, see bug #1834379. Anyone know why just rebuilding the deb seems to work, and how we might fix it?
<ubottu> bug 1834379 in python-pygraphviz (Ubuntu) "armhf Bionic python3-pygraphviz package errors for simple use case" [Undecided,New] https://launchpad.net/bugs/1834379
<sarnold> kyrofa: if it were mine to debug I'd probably start with a no-change rebuild of the package in a ppa
<kyrofa> Thanks sarnold, we'll give that a shot. If that ends up working, is there a way to just request a rebuild of that package?
<cpaelzer> ddstreet: thanks for having some awake eyes, great hint!
<alkisg> Hi, I read in https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179/55 that there's a plan that some .debs will only be available as snaps from 19.10 and on
<alkisg> Would it make a difference if a few thousands users opposed that? If yes, where would be a good place to start a petition against it?
<valorie> alkisg: a petition?
<alkisg> valorie: not a native English speaker, I'm not sure if it's the correct word, I mean a place where concerned users would voice their arguments and vote against it
<valorie> what helps is getting involved in development and be one of the peoples steering the decisions
<alkisg> I spend 10 hours per day in development, sure
<valorie> the people who do the work make the decisions about what they want to do
<alkisg> Well, if everyone would do whatever they wanted in their packages, there wouldn't be a debian/ubuntu community
<valorie> I personally don't like snaps and don't like to think of debs going away
<alkisg> All developers want to hear valid concerns
<valorie> or just regular packages
<valorie> of course
<valorie> people work in teams
<alkisg> Right, and I'm doing my part in the packages I maintain
<valorie> I can't see Debian moving to snaps, personally
<valorie> well, cool
<alkisg> Sure; I'd like to try to convince canonical otherwise, before switching the Greek schools to Debian
<alkisg> That's exactly why I'm asking here
<alkisg> To see if there's a chance for it
<valorie> aha, well then I'll hush
<Unit193> 'Petition' would mainly indicate a list of people that agree such a move would be bad, discussion with arguments and counter-arguments is different.  It does sound like you did mean petition, to some extent.
<alkisg> Maybe it's just me; and all my concerns are invalid; but maybe there are thousands of users that feel like me, and it would be best not to FORCE snaps on people that want to keep using debs
<Unit193> alkisg: FWIW, valorie also indicated a distate of snaps, as do I and some other devs.
<Unit193> Distaste, rather.
<alkisg> For example, technical arguments would be "they waste RAM; they have a lot of mounts for apps I don't use"; but all those could be easily ignored by persons wanting to push snaps; while, e.g. 10.000 "votes" would be harder to ignore, they would indicate a user  base that would leave Ubuntu if that indeed happens
<alkisg> So I'm not sure which of those methods would work better in this case
<tjaalton> alkisg: if you have technical issues, the fourth reply to the post explains how to file them
<tjaalton> and as for voting, well this isn't a democracy ;)
<alkisg> tjaalton: the snapcraft forum? ...ok, I can invite users that do not want snaps to sign up and participate there, but it doesn't sound like the appropriate place...
<alkisg> Of course it's not; still, I'm pretty sure Ubuntu does want to hear the voice of its users
<alkisg> The day that someone claims otherwise, is the day I'll abandon this boat :)
<seb128> alkisg, I missed the start but https://community.ubuntu.com/t/please-do-not-use-snap-into-ubuntu-its-too-early/11206 has already quite some discussion from people who don't like snaps
<alkisg> Thank you seb128, reading...
<tjaalton> i don't think two separate builds of a security sensitive browser would be maintained forever
<alkisg> It *is* possible, even if you think 1%, that snaps may be abandoned in the future. It would be bad if users left because of a failed attempt, but never came back just because of it
<tjaalton> possible yes, but not free
<tjaalton> of cost
<seb128> whatever you do you will have hates and people who resist to change and world moving and are going to rage quite over something
<seb128> I don't think we are going to stop doing work because some users are resistant to change
<alkisg> Sure. I enjoyed the "wayland by default" bug on debian; very civilized discussion even on a heated topic. I'd love to see a similar civilized discussion on snaps.
<seb128> we do listen to feedback and work on fixing issues like the mount noise you mentioned
<seb128> that discourse topic is civilized
<seb128> Laney, sil2100, hey there, re. the SRU/autopkgtest regresssion&comment on bugs, could the system detect infra issues and avoid commenting on the bug in those cases?
<seb128> like the g-s-d regressions are the arm64 chroot failing to install the kernel
<Laney> probably not
<Laney> I mean if we could analyse and determine what those were we could auto-retry them
<seb128> http://autopkgtest.ubuntu.com/packages/i/indicator-session/disco/arm64
<Laney> at least it's a hint so that someone can go and retry or nag to get it fixed
<seb128> if version is "unknown" that's usually sign of an infra issue no?
<Laney> sometimes, but it can also be that the pkg is broken and couldn't unpack or something like that
<seb128> k
<seb128> so I guess next question is for Lukasz then
<seb128> what's the way to clear the situation for SRU team?
<seb128> commenting back on the bug saying "please don't block on those, they are not a problem in the package"?
 * Laney thinks that's what they want from those mails
<Laney> the first comment is like what the SRU team would have done manually
<seb128> ideally they would have checked it's a really issue before nagging, but alright
<seb128> I commented on the bug
<seb128> thx
<seb128> it's getting very tedious to get a SRU going
<seb128> (that adds up to the regular "e.u.c has a bug report, we stopped the line" false positives)
<sil2100> seb128: it's just an automated message, nothing really changed in the SRU process here - I mean, even if such a 'notice' comment is sent to a bug, if I do my SRU shift and see one failure that's basically something obvious, I won't block on it and act by myself as I always did
<seb128> sil2100, I'm concerned that it makes the process even more tedious for the uploaders who don't understand what they could/should do in such cases
<seb128> like if it's a problem in the package fair
<seb128> but now I'm being nagged about some arm64 machine failing to install a kernel package
<sil2100> seb128: it was always the uploaders responsibility to acknowledge and check any autopkgtest failures triggered by one's upload
<sil2100> So nothing changed here, only a notification comment is now happening
<seb128> nobody ever nagged me on a SRU because of those autopkgtest infra issue before, I think reviewer usually did the reasonable thing to do about those and just ignored them
<sil2100> seb128: infra issues like that usually require some action, usually a re-run - and if it's reproducible, only then ignore, so it's still sometihng that needs *some* action from one person or the other
<seb128> I tried a retry didn't work
<sil2100> If I get to the bug first before the uploader, see this, re-run it (or check that it's really nothing to worry about), I will release without the need of action from the uploader
<seb128> I can't be bothered chassing arm64 insallability issues for a disco SRU though
<sil2100> But if you do it before me, that's even better
<seb128> k
<seb128> well I understand the intend and I made my comment
<seb128> thx for listening :)
<seb128> it does feel tedious nowadays to drive a SRU as an uploader, you keep being nagged by buggy systems/bots and have to defend against false positive to unblock your work
<seb128> which I know some people just give up on and let the SRU stalle
<sil2100> No worries, I can understand your point, but I think the number of cases where this might cause confusion is smaller than the number of cases where we had to manually write comments 'hey, autopkgtests are failing, please take a look' because of people completely not looking at that
<seb128> right, for sure it's good to comment on the bug when a regression in the test happens
<seb128> it's the false positive that are annoying
<seb128> to be fair I'm mostly annoyed about the e.u.c ones
<seb128> those keep triggering and blocking SRUs
<seb128> those autopkgtest is just yet another case pilling up
<sil2100> Indeed, for the SRU case this is just an annoying notification - so please treat it more like a 'helper tool' to not make you have to look at excuses, waiting for tests to finish
<sil2100> ;p
<sahid> sil2100: o/ anychance you look at #1831754, if you can accept nova we could start the testing
<sahid> https://bugs.launchpad.net/cloud-archive/+bug/1831754/
<ubottu> Launchpad bug 1831754 in nova (Ubuntu Disco) "[SRU] stein stable releases" [Undecided,New]
<sil2100> sahid: hey! So the problem with that one is that there's already a nova upload in disco-proposed that's pending verification
<sil2100> sahid: one of the 4 bugs is still not verified, accepting the new nova would mean clobbering the current SRU info and verification
<sil2100> sahid: I think I poked coreycb about that already, I think they have some problems in getting the verification done...
<sahid> oh... that is unfortunate, do you have the link in hand?
<sil2100> sahid: looks like it's this one: https://bugs.launchpad.net/nova/+bug/1808951
<ubottu> Launchpad bug 1808951 in tripleo "python3 + Fedora + SSL + wsgi nova deployment, nova api returns RecursionError: maximum recursion depth exceeded while calling a Python object" [High,Triaged]
<sahid> sil2100: thanks a lot I will try to se wheher I can make the tests moving forward
<sil2100> sahid: thanks! Once we have this verified and released, I'll quickly pick up the pending SRU in unapproved
<sahid> sil2100: https://bugs.launchpad.net/nova/+bug/1808951 is that OK for you?
<ubottu> Launchpad bug 1808951 in tripleo "python3 + Fedora + SSL + wsgi nova deployment, nova api returns RecursionError: maximum recursion depth exceeded while calling a Python object" [High,Triaged]
<TJ-> when building a package imported from Debian without ubuntu changes, should I ignore the Lintian error "changes: bad-distribution-in-changes-file unstable"
<Skuggen> TJ-: The changelog entry generally specifies the distribution you're building it for (disco, eoan, etc), and it sounds like right now it says "unstable", which is debian-specific
<cjwatson> In general the changelog header is an instruction to the source upload machinery.
<cjwatson> If you're building a source package you've got from somewhere else then it's immaterial.
<cjwatson> It's normal for packages synced without modifications from Debian to say "unstable" there.
<cjwatson> So yes, you should ignore that Lintian tag./
<sil2100> sahid: hmmm, so the test-case mentioned deploying with TLS endpoints - has that been done during testing? Since the output of catalog list seems to include http:// only
<rbalint> seb128 i'm thankful for sil2100's comment on my sru bug about autopkgtest failures which i would have noticed much later
<sahid> sil2100: good catch, you are right i need to fix that
<sil2100> sahid: thanks! ;)
<TJ-> cjwatson: thanks; that is what I thought but I always like to clear all warnings let alone errors - sbuild was happy anyhow
<seb128> rbalint, +1 for comments about actual issues, I was -1ing on nagging bug reporter and package uploaders when it's the infra that is at fault
<kyrofa> sarnold, regarding https://bugs.launchpad.net/ubuntu/+source/python-pygraphviz/+bug/1834379 , it seems that a no-change rebuild in a PPA does indeed work, what would be the next step?
<ubottu> Launchpad bug 1834379 in python-pygraphviz (Ubuntu) "armhf Bionic python3-pygraphviz package errors for simple use case" [Undecided,New]
<sarnold> kyrofa: very good question :) I *think* an SRU with debdiff, where the changelog includes "No change rebuild (LP: 1834379)" would be a reasonable next step
<ubottu> Launchpad bug 1834379 in python-pygraphviz (Ubuntu) "armhf Bionic python3-pygraphviz package errors for simple use case" [Undecided,New] https://launchpad.net/bugs/1834379
<sarnold> there's likely more, there's always more..
<kyrofa> sarnold, ah darn, guess I'll need to relearn that! Thanks for the pointers :)
#ubuntu-devel 2019-06-28
<kyrofa> sarnold, alright, done, any chance you'd be willing to sponsor it for us?
<sarnold> kyrofa: sorry, I'm not a coredev :(
<Unit193> python-pygraphviz is in universe.
<sarnold> oh! so motu would suffice?
<sarnold> (which, alas, I am also not, but that's probably a larger poool :)
<Unit193> Yes sir.
<Unit193> Is there anything preventing someone sync'ing libjson-c from experimental?
<tsimonq2> Unit193: .
<tsimonq2> When are you going to become a Core Developer, again? :P
<Unit193> Why would I?  I like the fringe packages. :3
<tsimonq2> Â¯\_(ã)_/Â¯
<Unit193> (Read: I'm only looking into this because of 'sway')
<tsimonq2> OOOOOH
<tsimonq2> What's the progress on that?
<tsimonq2> A little birdie tells me someone is interested in starting an Ubuntu Sway flavor.
<Unit193> depwait on json-c .13 :P
<tsimonq2> :P
<Unit193> Urgh, not another...
<wxl> your what hurts?
<tsimonq2> Unit193: Between Ubuntu Sway, Ubuntu Cinnamon, and Ubuntu Unity, I wonder if someone is already betting who actually pulls through first. :P
<tsimonq2> (All three of those are currently in some stage of "in the works.")
<tsimonq2> Now, if we had an active TB that could actually process a flavor application...
 * tsimonq2 runs
<Unit193> Who's behind them?
<tsimonq2> Unit193: Oh look, your binaries are in the NEW queue.
<tsimonq2> Ubuntu Unity has... Khurshid Alam? I'm not sure who else. Ubuntu Cinnamon is by someone I was told I should meet when I went to SELF but never got the chance to, so *shrug*. Ubuntu Sway is a few flavor folks.
 * tsimonq2 glares at bashfulrobot 
<tsimonq2> :P
<wxl> i'd be interested in trying a sway flavor actually
<tsimonq2> wxl: That makes four existing flavor people interested.
<Unit193> Right, so reading proposed migration output...
<wxl> oh yeah and i'm starting a fbui flavor.
<tsimonq2> Unit193: Oh?
<Unit193> skipped: elogind (0, 5, 11) got: 7+0: a-1:a-4:a-0:i-0:p-0:s-2 * arm64: elogind, libelogind-dev, libelogind0, libpam-elogind
<tsimonq2> Actually, that's a good point that I should add to the wiki page.
<Unit193> Going to guess it's installability issues, which yeah that's sort of expected in Ubuntu since there's no systemd alternative.
<tsimonq2> Yeah, even on notest.
<tsimonq2> Hm.
<Unit193> Which if sway depends on that...Hrm!
<tsimonq2> Oh, well, I wonder why I thought that in the first place, since it wouldn't show as a candidate anyway if autopkgtests didn't pass.
<tsimonq2> Unit193: It does?
<tsimonq2> Wat?
<Unit193>     - Make build-deps libsystemd-dev and libelogind-dev alternatives   So we'll want the new sway, good.
<tsimonq2>   * libelogind0 is ABI compatible with libsystemd0 so conflict, replace and
<tsimonq2>     provide libsystemd0 (=${source:Upstream-Version}), and also install
<tsimonq2> Wait... wat?
<tsimonq2>     libsystemd.so symlinks (Closes: #923244).
<Unit193> ...You understand the point of elogind, yes?
<tsimonq2> I actually don't. To Google I go.
<Unit193> To replace sytemd's logind, so one can have gnome or other such things on a sysvinit/openrc system.
<tsimonq2> Elogind has been developed for use in GuixSD, the OS distribution of GNU Guix.
<tsimonq2> Hmm.
<tsimonq2> Okay.
<tsimonq2> Unit193: So you're telling me that sway depends on this thing?
 * wxl blinks
<tsimonq2> Oh.
<tsimonq2> No, I'm glad it isn't.
<tsimonq2> I guess they just want it to work in Devuan? :P
<Unit193> https://sources.debian.org/src/sway/1.1.1-1/meson.build/#L55 well it *has* support.
<tsimonq2> I wonder what went through Drew's mind to do that.
<Unit193> Why not?
<Unit193> Seems like a good thing to do.
<tsimonq2> I'm just wondering why. :)
<wxl> https://files.devuan.org/devuan_ascii/Release_notes.txt flavors are (consolekit + slim) + (XFCE|MATE) || (elogind + lightdm) + (Cinnamon|KDE|LXQt)
<Unit193> That's like wondering why one would support logind..
<wxl> almost exactly
<Unit193> Anyway, doesn't matter.  Things are sync'd.
<tsimonq2> Ohhh, it just clicked to me that it's drop-in for their use case.
<tsimonq2> Okay, that's cool.
<wxl> the sleeper has awakened
<tsimonq2> There, added update_output_notest.txt to ProposedMigration.
<Unit193> Wasn't there an openbox style Wayland compositor?
<rbalint> seb128, i'm -1 about nagging uploaders about infra issues, too, but this is not the sru team's fault, the infra should retry automatically
<seb128> rbalint, right, fair enough
<rbasak> seb128: I agree it's tedious to drive SRUs because of the false postiive autopkgtests
<rbasak> seb128: but I don't think it makes sense for the process to require that the limited-in-size SRU team do that driving when any uploader can do it. It'd be more efficient if everyone pitched in.
<rbasak> seb128: separately, if we can figure out how to reduce the false positives, that'd be good too :)
<seb128> rbasak, well, I know that some uploaders get confused on what to do when the test failures is an infra issue and just do nothing and then the SRU sits there for ages
<seb128> indeed
<rbasak> sil2100, seb128: I suggest a tag that means "autopkgtest results have false positives"
<rbasak> The notification could ask the uploader to tag if they've checked, and we could have the pending-sru report mark the autopkgtest faiilures green or something like that.
<rbasak> Then uploaders will know what to do and the SRU team can focus on the ones that have been looked at first.
<seb128> yeah, that would be better/less confusing I think
<sil2100> rbasak: might be a possibility
<sil2100> Anyway, even without the bug notification, in most cases people would anyway 'be confused' if they checked the autopkgtest failures, which we expect them to do
<Laney> That indicator-session case from yesterday passed once the kernel had fully published out, by the way.
<sil2100> As I said, nothing changed in the process or anything, we always expected people to look at autopkgtest results of their SRUs
<rbasak> Yes - adding the notification hasn't made anything worse IMHO.
<seb128> Laney, you mean gnome-settings-daemon?
<Laney> That was the trigger.
<seb128> ah, right
<seb128> crap, I did a test retry
<seb128> thx awesome bar to completing to the retry url for me :/
<ahasenack> xnox: I've been testing apache2 with client cert auth following the openssl 1.1.1 update
<ahasenack> I don't have a conclusion yet, but I've been finding some things
<ahasenack> for example, in disco, it doesn't even establish a connection, because browsers try tls 1.3, and that fails with this errror in the logs:
<ahasenack> [Thu Jun 27 20:55:43.549681 2019] [ssl:error] [pid 2620:tid 140250923878144] [client 10.0.100.1:60000] AH10129: verify client post handshake, referer: https://bionic-apache-client-cert.lxd/
<ahasenack> [Thu Jun 27 20:55:43.549715 2019] [ssl:error] [pid 2620:tid 140250923878144] [client 10.0.100.1:60000] AH10158: cannot perform post-handshake authentication, referer: https://bionic-apache-client-cert.lxd/
<ahasenack> [Thu Jun 27 20:55:43.549732 2019] [ssl:error] [pid 2620:tid 140250923878144] SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received
<rbasak> ahasenack: sounds like we should bump it to Critical?
<ahasenack> I googled that extension, firefox seems to have it in some version, and chrome/chromium hasn't implemented it yet
<ahasenack> rbasak: I just want to be sure my setup is ok first, client cert auth is messy to setup and prone to errors
<ahasenack> I tried disco thinking it would be my good case, but it failed there too. I wanted to try xenial now
<rbasak> Ah
<rbasak> Somehow I missed that it was limited to client cert auth only, sorry.
<maswan> we run on client cert auth all over at $work, and as of today everything is horribly slow :/
<ahasenack> on tls v1.2, bionic, I get the same error as reported in https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039
<ubottu> Launchpad bug 1833039 in openssl (Ubuntu) "18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1" [Undecided,Confirmed]
<ahasenack> maswan: that's the bug above, a long timeout
<ahasenack> rbasak: there is also something about mod reqtimeout, which we have set to 20s, I think the timeouts are related to that kicking in. I tried disabling it, but then the connection never times out
<ahasenack> something else to investigate
<maswan> yeah, our wiki maintainer already found that bug, and luckily it's almost weekend here and we hope for better times after the weekend. :)
<ahasenack> the upstream commit pointed at in the bug talks about tls v1.3 only:     mod_ssl: disable check for client initiated renegotiations with TLS 1.3.
<ahasenack> but we are seeing the timeouts with 1.2
<ahasenack> I think there are many things going on and we need to separate them
<ahasenack> first, I don't think apache in bionic has tls v1.3 support
<maswan> hm. it's 1.2 here, at least when it finally manages to connect and load
<paride> ahasenack, so in your setup it just fails, no long waits
<ahasenack> not what I said
<xnox> ahasenack:  ouch
 * paride re-reads
<ahasenack> in disco it fails, because tls 1.3 is negotiated, but apache complains the browser lacks a certain extension
<ahasenack> I found bugs about that in firefox and chromium
<ahasenack> in bionic I reproduce the timeout
<ahasenack> and I think modrequesttimeout is playing a role here, maybe even helping, I'm not sure yet
<paride> ahasenack, and in disco there is no fallback to tls1.2, if I get it right
<ahasenack> for client cert auth, nope
<ahasenack> the upstream bugs need a closer inspection (firefox, chromium). There was one for apache too, when it was thought it was an apache bug, but apparently that was closed as invalid (that one I didn't even skim yet)
<paride> ahasenack, I wonder if changing the MinProtocol / MaxProtocol options in /etc/ssl/openssl.conf would have an effect in this case
<ahasenack> apache has settings for that
<ahasenack> I mean, if you are thinking about a workaround, it could be set in apache, if there is one
<ahasenack> I'm not clear on the renegotiation feature, if it's allowed or not
<ahasenack> openssl's s_client can trigger a renegotiation, via the R key after the connection is established, and it's refused all the time by the server
<ahasenack> I'm not sure yet what's the expected behavior
<ahasenack> these are my raw test setup instructions: http://paste.ubuntu.com/p/2fTg2yM2Ht/
<xnox> ahasenack:  paride: so upstream have refactored SSLVerifyCLient processing inside location stanzas
<xnox> ahasenack:  paride: due to observed brokeness.
<xnox> ahasenack:  paride: i don't think that's in any release.
<ahasenack> xnox: are you saying this in response to my comment about things working if I move that outside of a location block?
<xnox> ahasenack:  paride: shall we try capping apache2 to tlsv1.2 for now, across the board, until we can get new apache upstream release which is actually compatible and performance with tlsv1.3
<ahasenack> xnox: I don't think capping to 1.2 fixes it. That's in fact where I see the problem
<xnox> ahasenack:  yes, moving things outside of the block fixes things. but existing deployments will not change their apache config.
<xnox> ahasenack:  SIGH
<ahasenack> tls 1.3 has another issue with browser support, that post-auth handshake situation
<xnox> ahasenack:  it seems like we are about to do a quite a fat apache2 update of core & mod_ssl then
<ahasenack> that we can "fix" by capping to 1.2
<xnox> ahasenack:  right, so capping would fix that bit only, but not everything.
<ahasenack> the timeout is still there
<xnox> yes, timeout  / long delay got fixed in the refactor patch series
<xnox> ahasenack:  what about eoan? i guess it's also still broken?
<ahasenack> xnox: in this bug the commenter says it's fixed: https://bz.apache.org/bugzilla/show_bug.cgi?id=62691#c5
<ubottu> bz.apache.org bug 62691 in mod_ssl "OpenSSL 1.1.1 and client-certificate renegotiation causes 1 minute delay" [Normal,Resolved: fixed]
<xnox> yeap that.
<ahasenack> the 1.3 patch is fully in 2.4.39
<ahasenack> which we don't have in eoan, because of the dbeian freeze
<xnox> when i looked at backporting that, to bionic it looked akward.
<ahasenack> I was just discussing this with the team this week, if we should go ahead of debian for some packages
<xnox> ahasenack:  it's not unusual for us to do that during a freeze.
<xnox> ahasenack:  and/or ask debian to upload things into experimental for us to merge/sync from
<ahasenack> xnox: I haven't tried eoan. I stopped at disco while still trying to understand the issues at play, differenciating the timeout from the tls v1.3 post-auth handshake issue
<ahasenack> disco+ can be tested if we disable tls 1.3
<ahasenack> I can do that
<ahasenack> just need to be careful, I'm trying multiple things at the same time
<ahasenack> and certificate auth quickly gets messy
<xnox> indeed
<paride> ahasenack, true; I'm trying to replicate your setup from the pastebin
<ahasenack> yeah, it's a bit raw
<ahasenack> the reqtimeout change, for example,
<ahasenack> with that  module disabled, the connection doesn't complete, it stays stuck
<ahasenack> and I saw in another comment in one of these multiple bugs that 2.4.39 has an extra setting in that module specifically for ssl handshakes
<ahasenack> which one user was hoping to use as a workaround
<xnox> hmmmm
<xnox> ahasenack:  rebuild apache against openssl 1.0.2
<ahasenack> hmmm
<ahasenack> not wanting to get hopes up
<ahasenack> but I think I found a patch that worked
<teward> xnox: fwiw
<teward> https://bugs.launchpad.net/ubuntu/+source/kopano-webapp/+bug/1834052
<ubottu> Launchpad bug 1834052 in kopano-webapp (Ubuntu) "autopkgtest failures: Chromium-Related in Tests" [Medium,In progress]
<teward> regarding the badtest
<ahasenack> https://github.com/apache/httpd/commit/bbedd8b80e50647e09f2937455cc57565d94a844
<teward> xnox: just to mention i noticed the same problem when nginx got stuck as well
<teward> i've asked in -release for it to either be ignored or badtested several times with E:NoResponse
<ahasenack> yea, that patch worked
<ahasenack> xnox: paride: https://github.com/apache/httpd/commit/bbedd8b80e50647e09f2937455cc57565d94a844
<ahasenack> I'll ask for people to test the ppa I have
<ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/apache2-client-cert-1833039
<paride> ahasenack, the description and comments sound very promising
<ahasenack> it fixed my test case at least
<ahasenack> tried multiple times: package from distro, fail/timeout; upgrade to ppa, works
<xnox> ahasenack:  that looks ok
<xnox> ahasenack:  but please test it in all apache mode.
<ahasenack> which modes do you mean?
<xnox> ahasenack:  i.e. forking / threading / blocking / non-blocking "worker" engine stuff. => not sure about terminology, but does that make any sense at all?
<ahasenack> ah, mpm
<ahasenack> given the setup intructions I have, I could even add a dep8 test for this probably, but that would take more time
<xnox> ahasenack:  there are cases where unsetting auto_retry may result in things not consumed right (hang) if the app doesn't know how to handle the SSL read/write_more_wanted error codes.
<ahasenack> well, that is committed upstream already
<xnox> ahasenack:  just restart the server locally with one vs the other engine. should be good enough.
<ahasenack> I could check if there were follow-up commits
<xnox> ahasenack:  true, just thinking if it has more commit deps or follow-ups => yes that.
<ahasenack> ok
<xnox> (you are on track there)
<ahasenack> maybe it's not even the auto-retry that fixed it, the other bit of that commit looks suspiscious
<ahasenack> " For OpenSSL >=1.1.1, turn on client cert support "
<ahasenack> the autoretry could be specific to tls v1.3
<ahasenack> anyway
<teward> xnox: do we want to push any Ubuntu level changes to fix the tests in kopano-webapp so we don't need to badtest it? oSoMoN did some debugging and found it's specifically due to passing a log-path arg to chromedriver (and snap isolation being the problem)
<teward> rather than just badtesting the tests
<teward> at least, until Debian does something about the test ( oSoMoN made a Pull Req in Debian to fix the test, but Debian is frozen so...)
<xnox> teward:  if there is a fix, i'm happy to upload it into ubuntu.
<xnox> teward:  link?
<teward> xnox: https://salsa.debian.org/giraffe-team/kopano-webapp/merge_requests/1/diffs
<teward> it requires alteration to d/tests/test_webapp.py
<teward> but just adjusting the service_args
<teward> author is oSoMoN
<xnox> ack
<teward> xnox: I can push it in also (yay for coredev) but wanted to check BEFORE making any changes
<xnox> ahasenack:  yeah that other bit, is weird.
<xnox> teward:  it looks harmless, go for it.
<teward> ack
<teward> .. bleh where'd i put the code...
<xnox> teward:  as long as, like we don't collect the log from that path. Or like we assert on stderr and without the log, it will start producing stderr.
<teward> ... oh that's right it was in my tmpfs *derp*
<teward> xnox: AFAICT that's not even a retrievable artifact after autopkgtests have run
<teward> my guess is it'll spit out to stdout/stderr
<teward> but oSoMoN would have details there
<Laney> test it yourself
<teward> xnox: that is, however, the reason chromedriver is crashing
<Laney> don't blindly upload
<teward> Laney: i am testing it - slowly ;)
 * teward is currently stuck in a "Downloading files" state
 * Laney sends some bandwidth over in the post
<Laney> would be good if the installing snap stage showed progress
<teward> indeed
<teward> Laney: i'm running the autopkgtest locally, it's slow only because of the Internet being stupid.
<teward> it's the uplink speed here there's a lot of visitors on site too so it breaks things.  and apparently my LXD image for Eoan autopkgtests is broken soooo..... i'mma have to rebuild it.
 * teward rebuilds the LXD image
 * teward runs the autopkgtest
<Laney> you might have some trouble installing the snap there
<Laney> (that's the armhf problem)
<teward> Laney: amd64 can install it fine
<teward> my infra's amd64
<teward> the amd64 failure is due to log-path and snap confining
<Laney> it is not an arch problem, it is a VM vs LXD problem
<teward> Laney: well SO FAR I haven't had the issue in my local snaps
<teward> s/snaps/LXD tests
<Laney> it's possible to have lxd containers which can install snaps, sure
<Laney> the ones we have for autopkgtest can't, though
<teward> right but i'm talking for my local tests, not the ones in use on the autopkgtest env.
<teward> if we can pass the amd64/i386 tests we can badtest the armhf still
<teward> THAT i already asked for :p
<Laney> I said might
<teward> and got E:NoReply in -release
<Laney> and that badtest is already there
<oSoMoN> teward, it's likely that without a --log-file parameter, the --verbose switch to chromedriver will make it write to stderr, but that should be fine because the autopkgtest already has the allow-stderr restriction
<teward> oSoMoN: indeed.
<oSoMoN> https://sites.google.com/a/chromium.org/chromedriver/logging confirms it will write to stderr
<teward> i don't have a VM to autopkgtest with damn snaps.
<teward> does autopkgtest have a vmware hook for creating VMs for testing? just curious
<teward> i have VMware Workstation on this system which is why I ask :|
<Laney> nein
<teward> meh qemu it is then.
 * teward installs into the system
<teward> at least i have a local archive mirror so it will do THAT part fast heh
<Laney> teward: oSoMoN: It's still failing for me fwiw https://paste.ubuntu.com/p/GJJPNB3BwR/
<teward> Laney: *with* the patch?
<Laney> yes
<teward> oSoMoN: sounds like it's still fubar.
<oSoMoN> meh
<teward> still going to get my Eoan qemu autopkgtest env set up
<Laney> sorry :(
<teward> but it's slowwwwwwwwwww (56% of 500MB and I'm jacked right into the network)
<oSoMoN> Laney, passing here, in an eoan amd64 VM
<Laney> run it with autopkgtest, that's what I've been doing
<oSoMoN> yes, Iâve run it with autopkgtest -B . -- null
<oSoMoN> verified failing without the patch, and passing with it
<Laney> ...
<Laney> I mean it fails
<Laney> try the qemu runner
<Laney> autopkgtest --output-dir out2 --shell-fail --timeout-copy=6000 --apt-upgrade kopano-webapp_3.5.6+dfsg1-1ubuntu1.dsc  -- qemu --ram-size=8192 ../reallytemp/autopkgtest-eoan-amd64.img
<oSoMoN> gotta go now, family waiting for me, but please keep me posted (comments on the bug), thanks!
<teward> Laney: i'll do so as soon as this thing finishes building the image.  It's sit on libc6 triggers :|
<LocutusOfBorg> hello xnox, can I fix borgbackup please?
<ahasenack> xnox: confirmed disco works with client cert auth with no timeouts if I disable tlsv1.3 in the vhost (SSLProtocol all -SSLv3 -TLSv1.3). With TLSv1.3 I get
<ahasenack> out of the box, I get https://pastebin.ubuntu.com/p/XdWq2xzq7Z/ (out of the box we have tlsv1.3 enabled)
<ahasenack> so that will need a different fix, even if it's disabling tlsv1.3
<ahasenack> FF needs release 68 to work as far as I can tell, we are at 67
#ubuntu-devel 2019-06-30
<[rg]> hello, some of the links for the debian installer are broken on this page http://d-i.alioth.debian.org/doc/internals/apa.html
<CarlFK> [rg]: Host d-i.alioth.debian.org not found: 3(NXDOMAIN)
<[rg]> CarlFK: the page should be updated then?
<CarlFK> what page?
<[rg]> oh woops
<CarlFK> and I'm guessing you want to tell #alioth on oftc.net
<[rg]> https://wiki.ubuntu.com/Installer/Development
<[rg]> thats the one ^
<CarlFK> ah, that makes more sense now
<themill> (anything that is pointing to an alioth.debian.org domain is a stale URL that needs fixing)
<[rg]> which branch do I browse for the debian installer? there are so many ...
<CarlFK> well... https://salsa.debian.org/carlfk-guest/debian-installer  is likely a fork of what you want, but "Service Unavailable"
<[rg]> ah :/
<cjwatson> [rg] seems to have left, but I've updated the broken links
<TJ-> is there a way to get apt to list packages for a single arch when a foreign arch is installed? "apt -a=i386 list" reports "E: Sense i386 is not understood, try true or false."
<tsimonq2> TJ-: Well, if it's a boolean, my first thought would be to set that as "true" and use grep.
<TJ-> tsimonq2: right, but the error message doesn't seem to match the man-page which shows "...[-a=architecture] {list | ..." and "apt --help" says 'read the man page' !
<TJ-> tsimonq2: in fact, "-a true" seems to be effectively "--all"
#ubuntu-devel 2020-06-22
<teward> who spearheads the deb to snap stuff for chromium right now
<Laney> anyone know / has looked into what's going on with libsane1? https://launchpadlibrarian.net/485340393/buildlog_ubuntu_groovy_amd64_ubuntu_BUILDING.txt.gz
<Laney> I remember something in Debian about this and a transitional package
<seb128> Laney, LocutusOfBorg was discussing that transition with RAOF the other day
<seb128> but I don't know what's missing at this point
<Laney> thanks, hopefully those are enough highlights to get people who understand :>
<seb128> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962936
<ubottu> Debian bug 962936 in src:sane-backends "sane-backends: please still keep libsane transitional package around" [Serious,Open]
<Laney> I'll avoid digging into it for now :p
<seb128> right, same here
<RAOF> I did the promotion of libsane1 to main, which resolved what we were talking about.
<RAOF> So I think it's now all "LocutusOfBorg" (https://matrix.to/#/@freenode_LocutusOfBorg:matrix.org) ð
<sich> Hi all ... first time joining this channel.  I'm interested in helping out with ubuntu development and looking for a little direction if possible.
<seb128> sich, hey, unless you have specific things you want to contribute to you could start by reading https://wiki.ubuntu.com/UbuntuDevelopers
<sich> @seb128 I do have a few areas that I'd like to contribute in, but as I'm new I'll go through the steps one by one ... thank you
<udevbot> Error: "seb128" is not a valid command.
<LocutusOfBorg> Laney, it is installable here, not sure what are you talking about to be honest, can you please provide some more context?
<Laney> LocutusOfBorg: see the build log I gave
<LocutusOfBorg> Get:5 http://archive.ubuntu.com/ubuntu groovy/universe amd64 libsane1 amd64 1.0.30-1~experimental2ubuntu1 [2387 kB]
<LocutusOfBorg> Get:6 http://archive.ubuntu.com/ubuntu groovy/main amd64 sane-utils amd64 1.0.30-1~experimental2ubuntu1 [202 kB]
<LocutusOfBorg> Get:7 http://archive.ubuntu.com/ubuntu groovy/main amd64 libsane amd64 1.0.30-1~experimental2ubuntu1 [14.8 kB]
<LocutusOfBorg> as said, it is installable here, not sure what is doing your build log
<Laney> that's of an ubuntu desktop image
<LocutusOfBorg> ah ok
<LocutusOfBorg> so now I got it
<LocutusOfBorg> will rebuild everything to pick up the new old libsane1
<Laney> ok cool, I didn't follow what's going on there - and I'm happy not to learn if you want to handle it
<Laney> thanks :>
<LocutusOfBorg> Laney, to be honest, instead of having an useless transition, you might want to add the transitional package libsane1 to main
<LocutusOfBorg> it is just a transitional package I added to ensure smooth upgrades
<seb128> LocutusOfBorg, R_AOF said earlier that he did promote it?
<LocutusOfBorg> it will save a ton of rebuilds, but I can do them anyway, as you wish (I know rebuilding helps to make transitional foo disappear)
<Laney> it's not in main no
<LocutusOfBorg> seb128, debian switched again from libsane1 to libsane, so I asked to promote the libsane again, and demote libsane1 that is now a transitional package
<Laney> ah
<LocutusOfBorg> but of course if you runtime-depend on transitional package but it is universe, nobody will teach you to move to the new one
<Laney> yes component-mismatches asks for it to be promoted
<Laney> maybe do both? promote and fix the archive too?
<LocutusOfBorg> it won't ask again to be promoted when the reverse-deps are rebuilt ;)
<LocutusOfBorg> I can do the rebuilds anyway, maybe just of main packages
<seb128> rebuild of main sounds like the best solution
<Laney> as you wish
<Laney> I assume it's not so many
<LocutusOfBorg> the only problem is that since this morning reverse-depends is not working :)
<LocutusOfBorg> but I can steal from there https://release.debian.org/transitions/html/auto-sane-backends.html
 * LocutusOfBorg does them
<Laney> cheers
<LocutusOfBorg> thanks fro the prod
<soren> What's the preferred way to get a package upload (to main) sponsored these days?
<juliank> soren: same as always https://wiki.ubuntu.com/SponsorshipProcess
<seb128> soren, easiest is probably debdiff to a launchpad but with ubuntu-sponsors subscribed
<soren> juliank: So debdiff on Launchpad, not .changes (etc). on a web server somewhere?
<soren> seb128: Right. Got it. Thanks :)
<seb128> np
<seb128> LocutusOfBorg, the rebuilds you did depends on the versioned lib, which isn't what is expected from what you said this morning?
<ahasenack> LocutusOfBorg: hi, you uploaded https://launchpad.net/ubuntu/+source/libguestfs/1:1.42.0-5ubuntu2, did debian drop the erlang package from it?
<LocutusOfBorg> seb128, libsane-dev depends on libsane1 and both should be in main
<LocutusOfBorg> libsane is transitional and should be moved to universe and possibly die in a fire or be "Provided:" by libsane1
<LocutusOfBorg> can you please do the magic promote again?
<seb128> LocutusOfBorg, that's the opposite of what you wrote this morning?
<seb128> <LocutusOfBorg> seb128, debian switched again from libsane1 to libsane, so I asked to promote the libsane again, and demote libsane1 that is now a transitional package
<LocutusOfBorg> yes sorry, I had no coffee at that time, and everything that has "sane" in the sentence gives me headaches
<LocutusOfBorg> the bug report I filed in Debian is good
<seb128> k
<LocutusOfBorg> do you have power to fix them up? they should migrate in a run or two, they all looks ok
<seb128> LocutusOfBorg, yes
<LocutusOfBorg> seb128, also, somebody should MIR src:libnma?
<seb128> LocutusOfBorg, I guess?
<rafaeldtinoco> there was an old bug from cyphermox related to adding support for netplan into netcf:
<rafaeldtinoco> https://bugs.launchpad.net/ubuntu/+source/netcf/+bug/1688345
<ubottu> Launchpad bug 1688345 in netcf (Ubuntu) "add netplan support or RM package from archive" [Undecided,New]
<rafaeldtinoco> I was wondering, should we keep it opened or just request netcf removal from the archive ?
<rafaeldtinoco> (it seems that netcf isn't much "maintained" lately, and our strategy is to support netplan with backends only, no ?)
 * rafaeldtinoco waits feedback to continue or not with [RM] bug to AA
<ahasenack> question, how are translations updated if an SRU changes the text of some package? Or are they not?
<sarnold> I've seen sru uploader making changes where that's possible
<ahasenack> you mean also uploading an updated locales package?
<ahasenack> language-pack-$lanf
<sarnold> ahasenack: no, just the .po files in the package; a recent example I noticed https://launchpad.net/ubuntu/+source/apt/2.0.2ubuntu0.1
<ahasenack> sarnold: oh, I guess I'm not sure how lp translations work then
<ahasenack> I thought translations were separate from the package and that that was one of the big ubuntu differences
<seb128> ahasenack, sarnold, the normal 'cycle' is that the source package generates a template during the build, which is imported by launchpad
<seb128> then translators do their work
<ahasenack> when does it get back into the package?
<seb128> and translations are exported to build langpacks on a regular cadence
<seb128> we do langpack refreshes, at least in the LTS cycles
<seb128> we will have one for .1 for sure
<ahasenack> seb128: but the package also installs its own .mo file
<ahasenack> apt installs 43 of those
<seb128> ahasenack, if you have a package shipping its own translations then it's a special case
<seb128> ahasenack, pkgbinarymangler/striptranslations.blacklist
<seb128> ahasenack, basically things that impact the installer don't use langpacks
<ahasenack> I see
<seb128> so we cover all languages for the installer
<seb128> for those to update translations you need a source upload
<ahasenack> seb128: does lp "ingest" changed translation templates when an SRU is done?
<seb128> ahasenack, yes
<ahasenack> seb128: also for esm releases? like trusty?
<seb128> I guess, I don't see a reason why they would be special
<ahasenack> I assume we just don't update langpacks for those
<seb128> afaik we don't no
<ahasenack> ok, thanks
<seb128> np
<seb128> you can see if there a new template in the launchpad queue
<ahasenack> I checked https://translations.launchpad.net/ubuntu/trusty/+source/update-notifier/+pots/update-notifier/pt_BR and it doesn't have new strings already updated in update-notifier in trusty
<seb128> https://translations.launchpad.net/ubuntu/<serie>/+source/<source>/+imports
<ahasenack> https://translations.launchpad.net/ubuntu/trusty/+source/update-notifier/+imports is empty
<seb128> I think the records don't stay long there so you would need to look soon after an upload
<seb128> ahasenack, for launchpad to have a template to import the package build must generate one
<seb128> https://launchpadlibrarian.net/444456802/buildlog_ubuntu-trusty-amd64.update-notifier_0.154.1ubuntu8_BUILDING.txt.gz
<seb128> which is the most recent trusty upload doesn't have one
<seb128> compared to e.g focal
<seb128> https://launchpadlibrarian.net/472635894/buildlog_ubuntu-focal-amd64.update-notifier_3.192.30_BUILDING.txt.gz
<seb128> Building update-notifier.pot...
<seb128> Removing generated header (.h) files...done.
<seb128> Wrote update-notifier.pot
<seb128>  
<ahasenack> interesting, why would it have been removed, if the release package has one (as it has translations in lp)
<seb128> ahasenack, the package has one but did you check that it has been updated to include the new strings you are after?
<ahasenack> all the ESM stuff, as far as I can tell, is not available for translation in lp
<ahasenack> I need to inspect this further, at least the LP side seems ok and will do its job once the pot file is generated
<seb128> ahasenack, right, looking at e.g http://launchpadlibrarian.net/440218814/update-notifier_0.154.1ubuntu6_0.154.1ubuntu7.diff.gz the .pot isn't updated/part of the diff
<seb128> and since the build doesn't do an update/use dh_translations or such, launchpad probably just has an outdated template
<ahasenack> yeah
<seb128> ahasenack, it's late here and I need to call it a day but feel free to Cc me on an email/bug/whatever or just ping me tomorrow, I'm having to look at resolving that with you
<ahasenack> seb128: thank you, good night
<seb128> I'm happy*
<ahasenack> I'm also dropping off
<seb128> np!
<seb128> night
<kanashiro> mwhudson: when you have some time could you please check this bug and provide some feedback? LP #1884663
<ubottu> Launchpad bug 1884663 in containerd (Ubuntu) "cadvisor/0.35.0+ds1-4 FTBFS in Groovy" [Undecided,New] https://launchpad.net/bugs/1884663
<kanashiro> it is containerd related
<mwhudson> kanashiro: can we just make everything a snap? :)
<kanashiro> :)
#ubuntu-devel 2020-06-23
<bryce> teward, https://code.launchpad.net/~bryce/ubuntu/+source/nginx/+git/nginx/+merge/386231
<Laney> seb128: LocutusOfBorg: what's up with the sane stuff? libsane1 needs promoting after all or?
<seb128> Laney, yes, LocutusOfBorg changed his mind, I will look at that after the meeting I'm currently in
<Laney> right, I looked at the package and it seems that libsane is the one that should be demoted eventually
<Laney> thanks!
<seb128> right, libsane1 is the one to promote now
<LocutusOfBorg> yes, sorry for saying the exact opposite :/
<LocutusOfBorg> we transitioned that library back and forth around 3-4 times in the last 2 years, and no ABI changes at all
<RAOF> Didn't I already promote that?
<Laney> I think there was some confusion :P
<LocutusOfBorg> this sucks a lot, because people kept syncing it over and over from experimental, debian changed its mind and reverted that change, but we had already transitioned
<seb128> RAOF, the binary is still in universe, if you want to try again please do, otherwise I've a look after that meeting
<LocutusOfBorg> also RAOF please move src:libnma to main, the binaries are already in main :) https://people.canonical.com/~ubuntu-archive/component-mismatches.html
<LocutusOfBorg> and I think we can also demote libsane to universe, but I'm not quite sure about that
<Laney> wait for component-mismatches to say
<seb128> xnox, could you look at sponsoring the update on bug #1882185 ? Olivier is out this week but he said that's going to be needed for the new firefox that is due for next week
<ubottu> bug 1882185 in nodejs (Ubuntu) "Firefox 78 requires nodejs >= 10.21" [High,In progress] https://launchpad.net/bugs/1882185
<seb128> hum, security updates bypass the autopkgtest infra? :(
<LocutusOfBorg> seb128, problem is that nodejs regressed a lot of stuff :/
<LocutusOfBorg> but meh, I can also have a look if x nox is away
<seb128> LocutusOfBorg, how do you know if that version hasn't landed yet?
<seb128> LocutusOfBorg, also we are going to need to update firefox one way or another
<seb128> LocutusOfBorg, thanks
<LocutusOfBorg> https://packages.qa.debian.org/nodejs
<LocutusOfBorg> seb128, the debian tracker shows them, and nodejs are pretty much packages in sync...
<LocutusOfBorg> in any case, lets upload and see what happens
<seb128> LocutusOfBorg, thx
<mwhudson> is ubuntuwire down?
<seb128> mwhudson, seems so, probably something to mention to IS?
<mwhudson> i don't think we run it though
<seb128> wgrant might know
<mwhudson> yeah he is on https://launchpad.net/~ubuntuwire-sysadmins/+members#active
<seb128> there is a #ubuntuwire also
<wgrant> Looking
<wgrant> seb128, mwhudson: Is back.
<seb128> wgrant, thx!
<mwhudson> wgrant: thanks
<LocutusOfBorg> wgrant, can you please help understanding this setarch failure? https://launchpad.net/ubuntu/+source/util-linux/2.35.2-4ubuntu1/+build/19497777
<wgrant> LocutusOfBorg: It's not one I know about, but vorlon at least glanced at it a few weeks back.,
<LocutusOfBorg> I mean, wgrant this command setarch riscv64 -v --uname-2.6 seems to give segfault, but I don't know if qemu is to blame or not
<LocutusOfBorg> do you have a possibility to launch that command?
<LocutusOfBorg> and also setarch from the old util-linux in release has the same segfault, just to be sure... the regression might be in something else, kernel maybe?
<wgrant> LocutusOfBorg: Oh really, pretty sure that used to work
<wgrant> Let me see
<wgrant> I just put away my board because my cat was trying to bite the fan
<wgrant> She'll just have to deal with it
<wgrant> There was an issue with related code that assumed a glibc thing was static, but it become non-static and broke on like m68k and riscv64
<wgrant> I wonder if this is related.
<LocutusOfBorg> the code of setarch didn't change at all, so something else is going under the hood, but trying to gdb it gives lots of uninplemented stuff
<LocutusOfBorg> mmm interesting
<LocutusOfBorg> linux changed from 5.3 to 5.4, glibc from 2.31-0ubuntu7 to ubuntu10
<wgrant> LocutusOfBorg: Where did you see that the old one has the same segfault?
<wgrant> Oh, building the old version in a PPA or something?
<LocutusOfBorg> nope, ppa is sad
<LocutusOfBorg> pbuilder chroot local
<LocutusOfBorg> based on this build, https://launchpad.net/ubuntu/+source/util-linux/2.35.1-5ubuntu2/+build/19330488 changes in toolchain are not that many
<LocutusOfBorg> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4114/+build/19498613
<LocutusOfBorg> this is the focal version just no change rebuilt in bileto
<LocutusOfBorg> old one still builds with focal
<LocutusOfBorg> lets try the new one with focal https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4114/+build/19499332
<seb128> LocutusOfBorg, argyll/riscv seems not happy (ftbfs)
<LocutusOfBorg> seb128, nack, not a regression
<seb128> LocutusOfBorg, I didn't speak of regression
<seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages just state
<seb128> colord
<seb128> Unsatisfiable depends:
<seb128>     argyll: riscv64
<LocutusOfBorg> I wanted to no change rebuild just because the riscv64 was not retryable
<seb128> I see, the changelog was confusing
<seb128> I though you meant it would build now :)
<LocutusOfBorg> seb128, yes, but meh
<LocutusOfBorg> I guess britney will consider it and let it migrate anyway
<LocutusOfBorg> it is not installable on riscv64 but also on release pocket
<LocutusOfBorg> what is the workflow for a library that was in main, not in universe, and we want it in main again?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/xxhash
<LocutusOfBorg> (new rsync is trying to use it in proposed)
<seb128> LocutusOfBorg, read https://irclogs.ubuntu.com/2020/06/23/%23ubuntu-meeting.html
<LocutusOfBorg> ta
<teward> bryce: thanks for the link.  cpaelzer brings up some good points, but I think we need to check to see the difference between Debian and us, some things may need poked up there for them failing for things.
<LocutusOfBorg> Laney, looks like component is now saying it, thanks! libsane	sane-backends
<LocutusOfBorg> seb128, ^^ :)
<Odd_Bloke> slyon: bdmurray: Have you seen https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1884221 ?  (It appears to be fixed in lp:apport.)
<ubottu> Launchpad bug 1884221 in apport (Ubuntu) "`ubuntu-bug` fails with "UnboundLocalError: local variable 'project' referenced before assignment"" [Undecided,Confirmed]
<bdmurray> Odd_Bloke: I've seen it but haven't dug into it yet
<Odd_Bloke> bdmurray: Want me to take a look?
<bdmurray> Odd_Bloke: Sure if you are interested.
<Odd_Bloke> bdmurray: What's the appropriate way to propose the change?
<bdmurray> Odd_Bloke: an MP against the groovy branch - not upstream
<Odd_Bloke> bdmurray: Including changelog entry?
<bdmurray> Odd_Bloke: yes please
<rafaeldtinoco> ahasenack: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/autofs/+git/autofs/+merge/386267
<rafaeldtinoco> if you have time for a quick +1
<rafaeldtinoco> its the same as the previous, without the & quoting as well
<rafaeldtinoco> I'll keep the & for the SRUs since its not backed by an upstream change and we are are  fixing the $ behavior only
<ahasenack> rafaeldtinoco: ok
<Odd_Bloke> bdmurray: https://code.launchpad.net/~oddbloke/apport/lp1884221/+merge/386269
<bdmurray> Odd_Bloke: thanks!
<bdmurray> jibel / xnox: can the SRU information in bug 1875045 be updated?
<ubottu> bug 1875045 in ubiquity (Ubuntu) "Ubiquity 20.04 exports existing ZFS pools" [Low,Fix released] https://launchpad.net/bugs/1875045
<bdmurray> and bug 1880869
<ubottu> bug 1880869 in ubiquity (Ubuntu) "Use persistent device name for vdevs" [High,Fix released] https://launchpad.net/bugs/1880869
<xnox> jibel:  i did ask about it before. It's not blocking testing ubiquity for the point release.
<xnox> jibel:  shall i drop the zfs backports, and reupload SRU without them?
<jibel> xnox, do not drop the backport, I'll update the bugs and do the verification this week
<xnox> tah
<rafaeldtinoco> are there any plans for ifupdown deprecation ?
<ogra> didnt that happen in 18.04 ?
<rafaeldtinoco> I meant removal, sorry
<rafaeldtinoco> ddstreet: ^ this was for our merge-review discussion
<rafaeldtinoco> I think the sync approach and "let it go" is the best way
<rafaeldtinoco> will seek that
#ubuntu-devel 2020-06-24
<cpaelzer> juliank: is debian/current-config some magic file/place for dh_auto_build?
<cpaelzer> juliank: I've seen you use it in packages and want to complete the missing 5% of the puzzle to feel like I really understand it :-)
<juliank> cpaelzer: I have?
<cpaelzer> juliank: https://git.launchpad.net/ubuntu/+source/ipxe/commit/?id=c727c197a06dde15bd9eb140bc1d588cfba35280
<cpaelzer> I understand the export if the target matches the file name, but I yet fail to see the point of "current-config"
<juliank> cpaelzer: I don't understand it either. Where's 2018 juliank when you need him?
<cpaelzer> juliank: it might be that "all you wanted" was to detect if you need to clean it up
<cpaelzer> juliank: which is fine with me, yet I wanted to be sure that there is no arcane magic dust hidden somewhere
<kanashiro> mwhudson: I attached a cadvisor debdiff to LP #1884663 disabling containerd support while we do not have a fix for the containerd library package, could you take a look at it?
<ubottu> Launchpad bug 1884663 in containerd (Ubuntu) "cadvisor/0.35.0+ds1-4 FTBFS in Groovy" [Undecided,New] https://launchpad.net/bugs/1884663
<seb128> LocutusOfBorg, https://launchpad.net/ubuntu/+source/remmina/1.4.6+dfsg-2ubuntu1 ... isn't the 'remove the remmina session from GDM" part resolved by the kiosk binary split done in Debian?
<jibel> xnox, the 3 zfs related bugs have been updated with sru information.
<LocutusOfBorg> seb128, let me have a look
<LocutusOfBorg> seb128, will fix thanks
<seb128> LocutusOfBorg, thanks!
<xnox> bdmurray:  jibel>	xnox, the 3 zfs related bugs have been updated with sru information.
<bdmurray> xnox: ack
<seb128> teward, hey, bug #1875231 has been sitting there for a while, any plan to do the SRU verification or find someone to do it?
<ubottu> bug 1875231 in nginx (Ubuntu Focal) "[SRU] [20.04] Update NGINX version string to 1.18.0" [Undecided,Confirmed] https://launchpad.net/bugs/1875231
<seb128> kanashiro, bryce, similar question for bug #1871685
<ubottu> bug 1871685 in vagrant (Ubuntu Focal) "[SRU] vagrant spits out ruby deprecation warnings on every call" [Low,Fix committed] https://launchpad.net/bugs/1871685
<kanashiro> seb128: thanks for the heads-up, I'll act on it
<seb128> kanashiro, thanks
<teward> seb128: it had already been verified like an eternity ago.  It's a simple version string change, upgrade works without issue, and we've done about a ton of those already.
<teward> seb128: the tricky part is Server Team's now working on a merge from Debian of 1.18.0-3
<teward> so that may have to land first.
<teward> in order for version strings to not collide.
<teward> seb128: was left with https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1875231/comments/8
<ubottu> Launchpad bug 1875231 in nginx (Ubuntu Focal) "[SRU] [20.04] Update NGINX version string to 1.18.0" [Undecided,Confirmed]
<teward> afaict it never landed in proposed to test, so ppas are the only way i tested
<seb128> teward, the bug has no tag so no it's not marked as verified
<teward> it's been held in unapproved for an eternity and never released to -proposed
<teward> so it couldnt be tested per SRU restrictions
<seb128> ?
<seb128> https://launchpad.net/ubuntu/+source/nginx
<teward> or at least I never saw a message about it
<seb128>  1.18.0-0ubuntu1 	proposed (main) 	2020-04-29
<teward> seb128: well then the system never *told* me it was let through
<seb128> right, unsure how that happened
<teward> probably LP exploding
<seb128> I'm coming from https://people.canonical.com/~ubuntu-archive/pending-sru.html
<teward> so because i never saw the notification I never *saw* that it was ready for testing
<teward> but the package as it was should work - however not sure you want to give bryce even more work :P
<seb128> where it's marked as 56 days old and not verified
<teward> it's been tagged now
<seb128> thx
<teward> also nobody put verification-needed
<teward> note that this would be superseded by the merge bryce is working on
<seb128> right, looks like it was accepted without the usual SRU tooling
<teward> yep
<seb128> no comment, no tgging
<seb128> k, good to know
<seb128> I was mostly trying to make sure that things don't end up sitting in proposed for ever because it's just a waste of effort for everyone
<teward> seb128: but unless you want a "WTF" to happen in Groovy with it having a lower version than in Focal you'll have to wait for bryce to complete their merge from Debian in Groovy
<teward> seb128: ack
<bryce> teward, yeah just wrapping up things on that merge, might be uploaded tomorrow
<teward> bryce: sounds good :)
<bryce> teward, actually since you're here, one of the last bits needing thought is how the replaces/breaks added by debian to nginx-core for nginx-full will behave for users upgrading from focal.  Christian suggested in review we may want to have something to give users a cleaner upgrade experience from focal, until 22.04.  What do you think we should do?
<teward> bryce: if they used the nginx metapackage that just pulls in nginx-common and nginx-(core|full|light|extras) so it SHOULD work without issue
<teward> so to my knowledge if how APT works nginx-full still meets the dep criterion
<teward> lemme double check the control file
<teward> yeah to my knowledge https://git.launchpad.net/~bryce/ubuntu/+source/nginx/tree/debian/control?h=merge-v1.18.0-3#n34 is where that magic happens and this should Just Work
<teward> i could test it if necessary but nginx-full will upgrade to nginx-full and nginx-core will upgrade to nginx-core here in Ubuntu
<teward> in Debian, nginx-core is new so any upgrade tasks will still meet nginx-full or nginx-light or nginx-extras
<teward> if they're using nginx metapackage
<teward> and flavors will still upgrade to their corresponding flavor both in Ubuntu and Debian
<teward> bryyce: let me know what you missed from my mini dump of info
<teward> tl;dr I think it will Just Work because those deps on nginx metapackage are ORs.
<teward> and it should Just Work in a Debian/Ubuntu way, and in upgrade stay on the same nginx version since nginx-full, nginx-light, nginx-core, nginx-extras are independent binaries and can't work in the same install
<bryyce> sorry, kernel gpu driver oopsed
<bryyce> last I saw was <teward> lemme double check the control file
<bryyce> ok, was hoping it'd just work
<teward> incoming text wall
<teward> see direct messages for the logs bryyce
<bryyce> thanks
<teward> bryyce: as is it should just work for the upgrade
<teward> nginx full doesn't switch to core, etc.
<teward> same in Debian.  Because the "or" condition for Debian file is met.
<teward> for the nginx metapackage*
<bryyce> teward, *nod* I'll include this in the MP update, I'm going to send it shortly
#ubuntu-devel 2020-06-25
<Unit193> Just curious at this point, but how would Ubuntu handle a request from a Debian maintainer to blacklist his package from autosync?  Is there already a process for this?
<bryyce> Unit193, dunno if there is a process for Debian specifically, but it is possible to prevent packages from automatically syncing.  I might suggest filing a launchpad bug against the package in question, and subscribing the appropriate admin team (maybe ubuntu-archive?)
<Unit193> OK, thanks.
<seb128> xnox, ddstreet, other people who might have a clue about that, could you check https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1880258 and see if it makes sense to you?
<ubottu> Launchpad bug 1880258 in systemd (Ubuntu) "Add trailing dot to make connectivity-check.ubuntu.com. absolute and reduce NXDOMAIN warning noise" [Undecided,New]
<seb128>  [connectivity]
<seb128> -uri=http://connectivity-check.ubuntu.com/
<seb128> +uri=http://connectivity-check.ubuntu.com./
<seb128> I'm happy to merge the change but I don't understand enough the issue to know if it's the right fix
<seb128> juliank, hey, is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958960 something you can review/fix?
<ubottu> Debian bug 958960 in src:synaptic "synaptic: FTBFS in Ubuntu" [Normal,Open]
<juliank> seb128: Don't really care, nothing new there
<juliank> I've done an NMU to make it build, it works fine in Debian, and we have no need to merge it in Ubuntu, so why bother?
<seb128> juliank, you mean by "no need to merge it in Ubuntu'?
<seb128> juliank, sure we can ship outdated software but that's not great
<seb128> juliank, we usually do merge on Debian at least once by cycle
<xnox> seb128:  https://serverfault.com/questions/803033/should-i-append-a-dot-at-the-end-of-my-dns-urls so adding the dot means "lookup on the real internet, do not try to do local network lookups"
<xnox> seb128:  in some ways it is correct, and will make the connectivity check quicker.
<xnox> seb128:  the NXDOMAIN stuff, fedora gave up on it, i wonder if we should too.
<xnox> seb128:  i think the '.' will prevent doing those lookups with warnings, when there is no default route anywhere.
<xnox> thus UX wise is good.
<seb128> xnox, k, and no expected drawback right? said differently no reason to not do it?
<xnox> seb128:  drawbacks => it is http url, if it's ever switched to https, it would need multiple domains in the cert.
<xnox> seb128:  but i guess it is intentionally http, to catch captive portals, which cannot be https.
<xnox> seb128: but interestingly enough http://start.ubuntu.com./connectivity-check does not work =(
<xnox> and gives me 503
<xnox> seb128:  do test that our deployment is correct and/or check with IS if they are happy for us to hit it with trailing dot by default.
<xnox> from client point of view it's fine, but IS might not like it from endpoint point of view.
<xnox> i.e. it will make it harder in corporate environments to fake that dns name i think.
<xnox> (cause some do that)
<seb128> xnox, right, I will check with IS, thanks
<juliank> seb128: you do know that basically the only change in there is that it's now saving the column width?
<seb128> juliank, does it matter? still having a package in sync and uptodate is a win compared to having it outdated and showing on the merge report and having users bothering us
<juliank> But I just noticed it seems to be missing the 0.84.6ubuntu5 change in debian
<juliank> seb128: yes it does, we only do manual work if there are meaningful changes
<seb128> juliank, the angle I was coming from is bug #1870900 in the sponsoring queue
<ubottu> bug 1870900 in synaptic (Ubuntu) "Sync synaptic 0.90+nmu1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1870900
<seb128> so it bothered some contributor enough that they went to file a bug and subscribe sponsors
<seb128> anyway,  feel free to keep an ubuntu delta if you wish, I argue enough on the topic
<juliank> seb128: It's tough. We need to remove the patches series in Debian to comply with new rules there, but we still need to keep 01_ubuntu_changelog.dpatch effectively, or well, rework it
<juliank> It's quite some work
<seb128> juliank, the debian reports stated the patch isn't needed anymore, is that wrong?
<seb128> 'I suspect this file can simply be dropped, as synaptic
<seb128> builds fine in Ubuntu without it, and is still able to retrieve
<seb128> changelogs due to PR #45.'
<seb128> https://github.com/mvo5/synaptic/pull/45
<seb128> juliank, without removing the patch series we could at least update the patch so it applies as a first step
<juliank> seb128: Yes of course it's wrong ,the patch is mostly not about changelogs.
<juliank> well, half of it is
<juliank> seb128: Half of the patch is about showing you correct supported or not status
<juliank> :D
<juliank> Though that's also missing ESM
<juliank> We should add ESM to list of supported origins
<seb128> juliank, k, I'm not familiar with that patch, I was just trying to clean some of the sponsoring queue. Thanks for responding. Ideally we would still refresh that patch in Debian so it applies then we can sync :)
<juliank> and then there's code telling you to look at launchpad if changelog could not be found, which does not work for ESM
<juliank> seb128: Refreshing the patch would not be a valid NMU reason IMO, and just an annoying useless download Debian users.
<juliank> Gotta merge it I guess
<seb128> juliank,you are afraid that mvo would freak out about you updating the ubuntu patch in Debian?!
<seb128> mvo, how angry would you be in juliank NMU synaptic in Debian to update 01_ubuntu_changelog.dpatch to correctly apply to the current version?
<juliank> seb128: Oh I'm sure mvo is fine with that, but other Debian people will look funny and disapprovingly :)
<seb128> juliank, the missing fix from 0ubuntu5 might be enough of a reason for an upload
<juliank> seb128: It's actually not missing it seems
<seb128> juliank, I don't think other Debian people care about who a maintainer authorize to NMU that package
<seb128> that discussion is ridiulous...
<juliank> In any case, I should rework this properly so we don't need all that dpatch stuff and become compliant with the TC ruling on distro-specific patch series
<xnox> seb128:  ubuntu first..... derivatives can cherrypick our patches.
<seb128> xnox, yes, that discussion started out by me mentioning a sync request we have for synaptic in the sponsoring queue
<seb128> xnox, it drifted to juliank ask why we need to merge packages and saying Debian maintainers wouldn't approve him including Ubuntu patch refreshes in a NMU even if the maintainer is fine with it
<seb128> weird world
<juliank> seb128: You do know there are quite a few people in Debian who hate Canonical, Ubuntu, and I don't want to give them more cannon fodder
<juliank> because in the end we end up with a heated discussion that "Canonical NMUs packages with ubuntu-only changes" and I'm not interested in that.
<juliank> Ugh, and I found a synaptic memory leak
<juliank> OTOH, they do have a story to tell about how an ubuntu person uploaded an NMU that doesn't even build on Ubuntu
<juliank> fun!
<seb128> :)
<xnox> seb128:  just RM synaptic from Ubuntu Archive
<xnox> =)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
<xnox> Fix Released
<seb128> wfm
<seb128> really I just saw an opportunity to have one more package in sync which means less work from our side
<mvo> juliank, seb128 sorry, only now saw the discussion, let me know how I can help
<seb128> mvo, I guess it would help if you could refresh 01_ubuntu_changelog.dpatch to apply and do an nonNMU upload of synaptic at some point, juliank believe that if he does that as not being the maintainer the Debian people who hate Ubuntu are going to be after him
<mvo> seb128: sure thing, I cna do that
<seb128> mvo, thanks :)
<seb128> we should be able to sync back again then
<mvo> seb128: yeah, I need to check why it's not, it was at some point
<seb128> mvo, some new apt fixes that have been NMUed since
<seb128> mvo, we could sync, but it 0.90 doesn't build on Ubuntu due to the Ubuntu patch not applying (which isn't impacting Debian/didn't get noticed when building there)
<mvo> seb128: aha, ok
<mvo> seb128: so it's just this refresh, I will see what I can do, today is a bit busy but maybe tonight or tomorrow
<seb128> mvo, thanks!
<seb128> mvo, no hurry, it's a minor thing
<seb128> so whenever you will have free cycles (if ever ;)
<juliank> mvo: also debian wants us to get rid of the per-distro patch series entirely, which is why I was thinking to do like if dpkg-vendor --derives-from ubuntu; then CPFFLAGS+=-DVENDOR_DERIVED_UBUNTU; and put stuff inside #ifdef
<juliank> Or even better, if () ...
<juliank> so that we build the same code on debian and ubuntu
 * mvo nods
<ahasenack> hi, anyone aware of this error that I just started seeing with tdb /i386 dep8 tests:  libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed
<ahasenack> http://autopkgtest.ubuntu.com/packages/t/tdb/groovy/i386
<ahasenack> ah, an ftbfs in latest gcc10
<LocutusOfBorg> wgrant, just FYI according to this page: https://buildd.debian.org/status/logs.php?pkg=util-linux&arch=riscv64 the logs from 2020-06-21 02:10:59 (failed) and 2020-06-21 11:05:43 (good) differs in kernel change from 5.0 to 5.7
<LocutusOfBorg> considering Ubuntu has 5.4, I would say that something in kernel changes between 5.4 and 5.7 "fixed it"
<LocutusOfBorg> jamespage, hello, FYI I'm syncing python-rfc3986
<ricotz> might be good to remove gcc-10 from -proposed?
<ricotz> LocutusOfBorg, hi, is libmount-dev missing a dep on libcryptsetup-dev?
<ricotz> https://launchpad.net/ubuntu/+source/util-linux/2.35.2-5ubuntu2
<bdmurray> vorlon: I'm looking at the gkrellm2-cpufreq ftbfs and it depends on licpupower-dev which is provided by linux in debian. What's the way forward here?
<vorlon> bdmurray: ask the kernel team if they can provide libcpupower-dev; if not, blacklist the package?
<LocutusOfBorg> ricab_, already fixed thanks :D
<LocutusOfBorg> sed s/ricab_/ricotz/
<bryyce> seb128, teward nginx 1.18.0-3ubuntu1 is in proposed now, if it helps for that focal version string sru.
<teward> it should since it's now lower than Groovy
<teward> i think anyways
<teward> seb128: i'll just leave this in your hands while I go get drunk.  'tis booze o-clock here :)
<bdmurray> well that was some honesty there
<bdmurray> vorlon: looking at gajim in update_output.txt it added a break on gajim-rostertweaks so then that package becomes uninstallable. Oh and there is a debian request to remove it.
<bdmurray> vorlon: So do I just need to ping an AA about removing it?
<bdmurray> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963604
<ubottu> Debian bug 963604 in ftp.debian.org "RM: gajim-rostertweaks -- ROM; not maintained upstream" [Normal,Open]
<sarnold> Laney: oh yes, polite reminder that eoan support ends in a month or so, we usually send a message like https://lists.ubuntu.com/archives/ubuntu-announce/2019-July/000246.html to give folks a heads-up
<sarnold> Laney: (where "we" means "someone on behalf of the release team" :)
#ubuntu-devel 2020-06-26
<dja> hiya, is there any way to query LP (e.g. to search for bugs) and get the results back as JSON or something like that rather than a web page?
<wgrant> dja: That's more of a #launchpad sort of question, but https://help.launchpad.net/API/
<dja> ah, didn't realise there was a channel for launchpad, sorry. thanks for the link, that's the pointer I needed!
<dja> lovely lovely lovely
<dja> wgrant: thanks!
<wgrant> dja: np, happy to answer any questions about details over there.
<Laney> sarnold: https://wiki.ubuntu.com/EndOfLifeProcess says 14 days, that's what we've been working towards
<ahasenack> good morning
<sarnold> Laney: aha, cool, thanks
<vorlon> bdmurray: gajim-rostertweaks> yeah, that's what was needed; I had overlooked the removal request when looking at bugs, else I would've done it yesterday. Wound up getting handled per LocutusOfBorg's request on #ubuntu-release
<bdmurray> vorlon: Do you want to close bug 1885201 then?
<ubottu> bug 1885201 in gajim-rostertweaks (Ubuntu) "RM: gajim-rostertweaks -- ROM; not maintained upstream" [Undecided,New] https://launchpad.net/bugs/1885201
<vorlon> yah probably
<bdmurray> If you have command output or something.
