#ubuntu-devel 2005-06-20
<pepsi> https://bugzilla.ubuntu.com/show_bug.cgi?id=11758
<pepsi> ?
<KaiL_> if I read that error correctly, the folder must exist, not be removed
<pepsi> it already exists
<KaiL_> which is required for pre-rm
<pepsi> there were 2 files in there that didnt make much sense
<pepsi> and like i said, rm'ing it made it work
<KaiL_> there I see only an error because the folder doesn't exist (in other words: after it got deleted)..?!
<pepsi> i dont understand... /var/lib/mozilla-firefox did indeed exist.. i was guessing that it was looking for something inside there
<pepsi> i could install again and investigate further
<KaiL_> find: /var/lib/mozilla-firefox/: No such file or directory <<this seams to cause the pre-removal script to fail
<pepsi> right
<Mez> Kail_: known bug in findutils
<Mez> if the folders an empty folder
<Mez> no - sorry - just with a find command with multiple folders
<Mez> it';s being fixed upstream
<KaiL_> so the "error" is, that the folder is empty?
<pepsi> there were 2 files in it
<Mez> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313079
<Mez> hey, anyone here with accuess to amin ? if so cna they rebuild findutils - it's been fixed upstream
<pepsi> was filing the bug report the most appropriate thing to do? 
<pepsi> i never know if problems i find are already known and being fixed or what.. you know?
<KaiL_> I think so - would be great, if everybody would do and I don't only find "bugreports" on pro-linux.de, heise.de or golem.de ;)
<mdz> lifeless: around?
<doko> mdz: would you mind probing libant1.6-java for main?
<Mez> k3b needs rebuilding for breezy doesnt it?
<doko> Mez: do you fix it?
<Mez> I've taken the current package for hoary and am repackaginfg for breezy
<Mez> it seems to be building ok
<Mez> in a breezy chroot
<Mez> unless there was something else that needed doing previously
<doko> Mez, no, it doesn't
<Mez> nothing else needs doing? just rebuilding?
<Mez> well - well se eif it builds ok (IT's still buulding
<Mez> if it does, wanna sponsor it?
<doko> http://people.ubuntu.com/~lamont/buildLogs/k/k3b/0.11.23-0ubuntu4/
<mdz> doko: it looks very good so far
<mdz> no more kaffe or classpath
<mdz> I'll post the complete output
<doko> yippie!
<Mez> yeah i noticed doko ... lol - I'm not at that stage yet ... so i'll probably crash out :d
<mdz> http://people.ubuntu.com/~mdz/temp/anastacia.txt
<mdz> doko: if you can confirm that all of the java packages in that list are properly packaged, I can do the promotions now
<mdz> my list is ant bcel cup jakarta-log4j1.2 javax-servletapi2.3 jlex jsch junit libbsf-java libcommons-logging-java libcommons-net-java libgnucrypto-java libgnuinet-java libgnujaf-java libgnujaxp-java libgnumail-java libjaxp1.2-java libjdepend-java libjessie-java liblogkit-java liboro-java libregexp-java libxalan2-java libxerces2-java libxml-commons-resolver1.1-java rhino xml-crimson
<doko> mdz: we did have a bug in ecj-bootstrap, infinity did build the fixed version in universe, needing libant1.6-java, so this is the only unclean package
<doko> but when we promote libant1.6-java to main, that's again a clean build.
<Mez> lol
<Mez> nah it just bombed
<doko> mdz: bcel, cup rhino seem to be unrelated
<mdz> doko: bcel is a build-dep of libxalan2-java
<mdz> rhino is a build-dep of bsf
<mdz> cup is a build-dep of libxalan2-java
<doko> mdz: ok, I didn't touch these. wasabi did convert these to java-gcj-compat, they should be fine.
<mdz> ok, as long as each of those has been looked over by you or wasabi
<mdz> confirm?
<doko> wait, I'll look at the packages, that don't have a -ubuntuN suffix
<pepsi> so you guys build packages for breezy eh?
<mdz> all your breezy are belong to us
<GammaRay> Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/universe/r/rxvt-unicode/rxvt-unicode_5.3-1_i386.deb  MD5Sum mismatch
<GammaRay> bad file?
<Mez> GammaRay, us archive = fault
<Mez> use archive.ubuntu.com
<doko> mdz: looks fine, all packages touch by you, wasabi, or me.
<GammaRay> Mez: thanks
<mdz> doko: migrated to main
<doko> mdz: cool
<mdz> anastacia output is much shorter now :-)
<doko> mdz: something else on the list: kde-i18n should not be demoted, as well as amd64-libs-dev, gcc will depend on it soon again to build i386 biarch
<mdz> doko: please review the proposed demotions to universe at http://people.ubuntu.com/~mdz/temp/anastacia.txt and add them to supported if they are sane
<mdz> heh
<mdz> I will not move amd64-libs-dev or kde-i18n until things are settled
<mdz> the -doc packages for the java stuff I just promoted should definitely be seeded
<doko> sure, let me do that tomorrow, I need some practice
<mdz> doko: ok, thanks for all your attention on the java packages
<mdz> doko: perhaps some sleep is in order :-)
<mdz> Keybuk: hello, you world-breaker you
<doko> yes, I won't start early tomorrow ;)
<Keybuk> which world did I break this time? :p
<Keybuk> and can I get "DESTROYER OF WORLDS" on my Business Cards? :p
<mdz> Keybuk: dpkg is the new gtk bug
<Mez> lol
<mdz> all unresolved problems are delegated to you
<doko> Keybuk: it's shorter if you ask, which you didn't break ;)
<Keybuk> not for the first time, I'm suddenly glad I don't work for you, mdz :p
<Mez> wait, I thought you did Keybuk ?
<mdz> Keybuk: you're glad to be part of the launchpad inferno? ;-)
<Keybuk> not especially
<Keybuk> Mez: nah, I'm not distro-team
<mdz> the distro team is an oasis of joy
<Mez> sorry - I got confused... someone once told me that mdz was the "big boss" for canonical
<Keybuk> I _cause_ merge requests, I don't do them :p
<mdz> I mean, here's doko working on packaging at about 3am because it's so much damn fun
<Keybuk> Mez: he's the CTO of Ubuntu
<mdz> Mez: Canonical does more than just Ubuntu
<Mez> CTO? never heard that one before
<Mez> yeah memdz, but someone told me you were the BIG like - boss of canonical - the CEO or whatever
<mdz> Keybuk: is on the skunk works side of things
<Keybuk> no, that'd be Mark Shuttleworth
<Keybuk> mdz may be able to walk up walls (backwards), but hasn't yet made it to space ;P
<Mez> ahuman01, someone told me it was matt zimmerman (and then told me that was mdz)
<jbailey> mdz: The same joy that leaves me hacking on initramfs on a Sunday evening.  =)
<mdz> emphasis on 'yet'
<Keybuk> mdz: you have plans?
<Mez> s/ahuman01/ah
<mdz> I have dreams
<mdz> I expect that within my lifetime it will become possible to do it for much less than it cost Mark and other early adopters ;-)
<Mez> mdz - I feel sorry for them (the dreams)
<Mez> hmm
<Mez> btw, does anyone wanna liek - fix findutils?
<Mez> just needs merging from debian :d
<Mez> like *
<mdz> it's the changes from debian which have triggered the chaos
<Mez> yeah, and now they;'ve been fixed
<Mez> ;)
<Mez> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313079
<mdz> at any rate, findutils in breezy is unmodified relative to Debian, so new versions in unstable will be brought in as a matter of course
<mdz> it is experiencing a high rate of change at the moment
<wasabi> i think I'm getting stupider as I'm getting older.
<Mez> *shrugs* well findutils broke the buildd.. now findutisl is fixed :D
<mdz> wasabi: you're older than you've ever been, and now you're even older
<Mez> and it;s also causing nearly EVERYTNg in breezy to break (according to what people tell me)
<wasabi> mdz, i just forgot 4 or 5 impotant things as you said that
<mdz> wasabi: 7 +/- 2
<Keybuk> mdz: ya know, it's funny about the world breaking
<wasabi> So Java got promoted?
<mdz> wasabi: yep
<Keybuk> so, you know how dpkg 1.13 improves life a lot for the non-Linux people?
<mdz> in theory oo.o2 is now buildable
* wasabi saluts Java.
<Keybuk> ...and build-depends on a package only available in Linux? :p
<mdz> Keybuk: ask me how much I care about the non-Linux people with the schedule we're on ;-)
<mdz> O Linux, thou art the way and the truth and the light
<Keybuk> 18 months until the next release? :p
<Keybuk> oh, wait, wrong hat
<tseng> mdz: dude, hurd
* Keybuk hunts for his Ubuntu one
* mdz hands Keybuk a spare
<tseng> mdz: it will be really good someday!
* Mez waits and sees if this k3b breezy build bombs out
<mdz> tseng: and that is exactly the time when I will start to worry about it
<tseng> heh, yep.
<mdz> tseng: meanwhile, there are mono packages and deps which need review for promotion to main
<jbailey> mdz: Or at least as much as you worry about *bsd? =)
<mdz> beagle deps primarily
<tseng> yep they need some fixing up
<tseng> mono 1.1.8 will have what i hope is the last fix
<mdz> evolution-sharp, gecko-sharp, gecko-sharp2, gmime2.1, gtk-sharp, gtk-sharp2-unstable, gtksourceview-sharp2, pnet, treecc, xsp
<mdz> lions and tigers and bears, oh my!
<tseng> pnet, treecc?
<wasabi> I guess it wouldn't hurt for me to dedicate a week to go over EVERY java package and verify they are actually sane.
<tseng> where did those come from :P
<wasabi> I get the feeling there is a lot of cruft in there
<mdz>  o pnet: pnet-interpreter
<mdz>    [Reverse-Depends: mono-mcs] 
<wasabi> like that xerces deal
<mdz>  o treecc: treecc
<mdz>    [Reverse-Build-Depends: pnet] 
<tseng> ah thats an | deal
<mdz> wasabi: the general idea is that we can do that as we need to move them into main
<mdz> now that the entire ant dependency chain is in, that's a solid base
<mdz> next week: eclipse!
<wasabi> Buh.
<wasabi> Don't remind me. Too much drama!
<doko> wasabi: the primary goal for java in main is OOo2
<mdz> surely we can get eclipse into main for breezy
<wasabi> Yeah we can.
<wasabi> What's the timeline though?
<mdz> we'll add it to gnome-app-install and everything
<doko> 3.1, not 3.0.1 ...
<wasabi> Eclipse in multiverse right now is hacked to bits to be free.
<mdz> say, feature freeze
<ajmitch> I don't see pnet & its deps going into main soon
<wasabi> doko, I really need to go over man-di's packages. I think they just went thru a bit of NIH
* wasabi supposed to be on vacation
<ajmitch> tseng: it might be time to drop the pnet deps, as I doubt it can even run beagle
<doko> wasabi: fine, please don't upload before 4.0.1 is uploaded, which will badly break binary compatibility
<tseng> ajmitch: doubt?
<ajmitch> tseng: there might be a slim chance
<tseng> ajmitch: i dont really need to thing about it :P
<wasabi> We're not native yet anyhow.
<wasabi> I have to put together an actual "plan" for doing that.
<ajmitch> pnet 0.7.0 was just released, so there's still hope for it :)
<wasabi> And I suck at those.
<doko> wasabi: I know ;-)
<wasabi> Know about the plan or me sucking? :)
<doko> I don't know about the former ...
<wasabi> haha
<wasabi> I swear my attention span is nill.
<wasabi> This new job is beating the crap out of me too.
<doko> you have to make some time for the next Ubuntu meeting ...
<Mez> hmm ... I think the problem with k3b is that the gcc compiler isn picking up an error that the previous version in hoary wasnt
<wasabi> This sucks too. I get home tomorrow at 10pm from my "vacation".
<wasabi> And go to work at 8 the next morning.
<jdub> (do we actually care about supporting pnet?)
<tseng> jdub: no, we pull it in from debian
<tseng> jdub: where we pretend to support more than just mono
<ajmitch> jdub: no, and we shouldn't care
<tseng> btw where is herve
<tseng> id like to have his permission to totally redo evo-sharp
<tseng> it follows the "old" policies
<Mez> riddell: ping
<tseng> ar not herve, koke
<the--dud> moo
<Mez> any c++ programmers here?
<jbailey> Mez: I am.
<Mez> http://www.sourceguru.net/ubuntu/k3berrors
<Mez> any idea what those top couple of errors mean?
<Mez> thats whats making the k3b build bomb out
<jbailey> Mez: You're probably missing an include for a typedef or something.
<Mez> the lines are
<Mez>   K3bMixedDataDoc( K3bMixedDoc* parent );
<Mez> and
<jbailey> Mez: Take the compile line, add -E -dD and change the -o to point to /tmp/foo or something.
<Mez> class K3bMixedAudioDoc : public K3bAudioDo
<Mez> jbailey - I've no idea how to find where it has the compile line :d
<jbailey> Mez: Then look in the file for the K3bMixedDoc declaration.
<Mez> class K3bMixedDoc : public K3bDoc
<jbailey> It'll be the g++ line right about the build failre.
<Mez> It's there...
<Mez> on line
<Mez> 49
<Mez> something possible to do with the order in which things are loaded in?
<Mez> I knwo in ADa you havd to make anything that was referenced later on available before it was reference
<jbailey> Right, you need to declare things in C++ before use.
<jbailey> In C, too. =)
<Mez> well it compiles ok under hoary :D
<jbailey> The Hoary C++ compiler was a little less picky about some things.
<Mez> but so, I'd have to change that file round so that the k3bmixeddoc was before it
<Mez> okies, well that seems to be the k3b problem
<Mez> lets see if I change it if it bombs
<Mez> I'll let you know
<jbailey> Cool. =)
<Mez> but i guess it was caus ethe file tried to reference something later on in the file, not to start with eh?
<Mez> schtoopid thing
<Mez> now I bet you it bombs, but somewhere else :D
<Mez> god it takes ages to build
<Mez> ;p;
<jbailey> BOOYAH!  initramfs boots with md software raid1
<wasabi> Buh.
* Mez crosses fingers and hopes this doesnt bomb
<jbailey> wasabi: Is that a good noise or a bad noise?
<wasabi> Bad.
<wasabi> I'm going over man-di's eclipse 3.1 packages
<wasabi> hell with this
<jbailey> mdz: Around?
<Mez> w00t
<Mez> k3b got past the bit it bombed at afore
<jbailey> Mez: Congrats. =)
<Mez> :D
* Mez hopes it doesnt bomb out completely now
<Mez> jbailey - you a dev?
<jbailey> Mez: Yes.
<Mez> wanna sponsor my apcakge itf it build properlY?
<crimsun> we don't sponsor packages, really
<crimsun> did you read the MOTU guidelines?
<Mez> wanna sponsor my package if it builds properly?
<Mez> is k3b in MOTU ?
<Mez> universe *
<crimsun> k3b is in main
<Amaranth> C++ uploads are restricted right now
<Amaranth> oh, it's in main...
<crimsun> you're welcome to push your fixes as a unified diff
<Mez> exactly, so i need a dev to sponsor the upload :D
<Amaranth> doesn't work like that for main
<crimsun> we do source-only uploads. You only provide the diff, dsc, changes.
<Mez> yeah i know crimsun
<Mez> but someone has to sponsor it to upload
<Mez> cause i dont have upload access :P
<Amaranth> you send a diff to someone (probably riddell in this case) and he can merge it
<crimsun> yeah, jr or amu
<Mez> ah fair enough - I'll send to riddell then seeing as he sponsored my last package i built for main
<jdub> hrm, what's a little java thing that is working at the moment that is worth playing with? :)
<eruin> they say us.archive.ubuntu.com isn't fixed after all in #ubuntu
<Mez> crimsun: ping
* luis_ hands jdub a JDS CD
<luis_> ;)
<jdub> free java dude
<jdub> lots of free java
<crimsun> Mez: pong
<jdub> hrm, clearlooks went through the buildd poopchute quickly
<Mez> us.archive = still b0rked :D
<Amaranth> eruin: it's hit-or-miss
<eruin> so it seems
<Amaranth> jdub: 0.6.1 is out, btw
<jdub> Amaranth: boh!
<jdub> it says no such thing on the website!
<jdub> and yet
<jdub> there it is in the list
<Amaranth> jdub: i get my info from the developer :)
<Keybuk> jdub: you should know better than to trust strange websites
<Amaranth> came out yesterday
<jdub> Keybuk: haha
* jdub churns out another one
<eruin> how is xorg today? :P
* eruin hides
* Mez dances
<Mez> and k3b builds properly
<Mez> except for: dpkg-genchanges: warning: no utmp entry available and LOGNAME not defined; using uid of process (0)
* jdub uploads 0.6.1
<jbailey> Mez: Sounds like you're su'd into a chroot without doing su -
<Mez> *shrugs*
<Mez> i let pdebuild do it...
<Mez> but
<Mez> I've fixed k3b I think
<jbailey> Nice, congrats.
<Mez> and i made it into a patch file too :D
<Mez> though i did it with the lastest version form the web, not from the repos (.23 and i used .24 (uupdatE)) so am gonna rebuild and see if it works in .23
<Nafallo> zul: rt2500 has a fix for creating adhoc networks in cvs, kthxbye ;-)
<Nafallo> zul: or rather create adhoc networks and you can find the fix in cvs. :-)
<mdz> jbailey: yeah
<mdz> jbailey: on the phone, though
<Keybuk> meh
<Keybuk> try:  yield ""  finally: ...
<Keybuk> is illegal in Python
<robitaille> jdub, your answer and mine to that e-mail on the ubuntu-doc list about a weekly newsletter are so similar...it's scary. But you beat me to it by 2 minutes :)
<mike_douglas> I'm getting md5sum mismatches on the update server (both ca and us mirrors), would this be on my end or yours?
<Mez> mike - there ar eproblems
<Mez> use archive.ubuntu.com
<Mez> and that'll work
<mike_douglas> thanks
<bob2> podcasting continues to be the most annoying word in world atm
<toresbe> podcasting?
* toresbe skips around singing "helter skelter" with "podcasting" over and over again as lyrics
<seth_k> bob2, no no no. The continual use of the made-up word "Ajax" in relation to 1.22 x 10^7 different new web software packages is MUCH more annoying
<bob2> ooooh
<bob2> good point
<seth_k> :D
<daniels> seth_k: now imagine how this must feel for adam jackson, who IRCs as ajax, and has done so since the dawn of time (and it's his username everywhere, etc)
<daniels> seth_k: he also gets random abuse from soccer fans who dislike the dutch team of the same name
<seth_k> lol
<bob2> wow, there's a soccer team named after cleaning powder?
<bob2> daniels: firegl for 9600xt is stupid, right?
<robitaille> I always thought the soccer team was named in honour of Ajax, a town near Toronto :)
<daniels> bob2: nope, it's not accelerated for 3D otherwise
<fabbione> morning
<bob2> ah
<daniels> bob2: eye-axe, rather than age-axe
<bob2> oh
<bob2> crazy dutch!
<jbailey> mdz: All good.  Just an initramfs status bit, emailed you.
<jdub> robitaille: :-)
<mdz> jdub: is he dutch?
<fabbione> mdz: you are not supposed to be working on sunday :P
<mdz> fabbione: it's monday for you :-P
<fabbione> mdz: yes.. but not for you ;)
<mdz> yet
<daniels> 12:01am doesn't count
<mdz> the day doesn't count until you sleep
* kafeine is away: hearing your voice is like icicles down my spine
* Keybuk agrees with mdz
<mdz> no sleep 'til brooklyn
<Keybuk> I'm not entirely sure what day it is anyway
<mdz> days are irrelevant
<mdz> there is sleep, and there is wake
<mdz> and there is a release
<daniels> mdz: where 'brooklyn' in this case is actually 'breezy', or?
<mdz> daniels: <screaming power-chord guitar riff>
<daniels> mdz: it's so horribly 80s, yet I can't tear myself away
<daniels> mdz: didn't they have that awful drumkit in there, too?
<mdz> daniels: a drum machine, I expect
<daniels> mdz: well, yeah
<daniels> but that same dodgy snare in every other 80s song
* mdz applies for a license to Ill
<daniels> mdz: [DENIED] 
<daniels> sorry
<daniels> [DENIED] 
<pepsi> hey, how can i help?
<mdz> pepsi: I don't think much can be done about the beastie boys' drum machine and its dodgy snare
<mdz> but regarding Ubuntu, see  http://udu.wiki.ubuntu.com/BreezyBounties
<pepsi> i dont like any of those :)
* Keybuk thinks mdz has been taking too much sugar
<Keybuk> or has been attending "Hollywood Parties" again
<mdz> I don't do sugar
* bob2 imagines Keybuk, mdz and daniels as 3 mc's, with elmo kicking up the phat beats
<daniels> Keybuk: 'hollywood sugar'
<daniels> bob2: and you can be the bboy
<daniels> spinning on yoru hair
<Keybuk> nah, bob2 will be behind bars shouting "I'M GOING TO KILL YOU BART!"
<daniels> he doesn't shout it, he just creepily utters it in a gravelly voice
<mdz> bart?
<mdz> like the san francisco light rail?
<fabbione> like simpson
<mdz> ah, with bob2 as sideshow
<Keybuk> yes, Sideshow Bob
<bob2> I'll get you, Scott Ja...yadayaday
<Keybuk> bob2: eat my distro, man
<mdz> I'll get you for this, Midler.......
<bob2> Keybuk: you're arch-team, foo'
<mdz> is there an arch-team gang sign?
<mdz> if so, please submit a photograph
<Keybuk> what's a "gang sign" ?
<mdz> Keybuk: ....
<mdz> Keybuk: http://women.alioth.debian.org/profiles/pictures/erinn.jpg
<mdz> like that
<Keybuk> ah, the "respect" thing
<Keybuk> sure
<mdz> in that particular photo, it is representative of "DW"
<Keybuk> https://wiki.canonical.com/ArchCheatSheet?action=AttachFile&do=get&target=rosetta-arch.png
<mdz> but the generalized concept applies to all sorts of things
<Keybuk> it looks like that
<Keybuk> takes 500 people, some with dislocated vertebrae, to pull it off though
<mdz> Keybuk: ok, I want a photo of you representing that diagram with your hands
<Keybuk> mdz: that I can do
<Keybuk> it involves one hand, and one finger :p
<mdz> pix plz
<Keybuk> meh, the only camera I have nearby is my phone
<mdz> I'll take what I ca nget
<bob2> mdz: http://people.ubuntu.com/~rweir/arch.jpg
<Keybuk> yeah, but I bet your phone doesn't accept photo messages? :p
<mdz> Keybuk: I can receive MMS
<mdz> it probably costs me about $10 US, but it works
<mdz> bob2: that's either an exaggerated latin letter 'H', or a characterization of an arch
* Keybuk tries the USB lead
<Keybuk> (and mutters something about breezy's lack of bluetooth support)
<bob2> mdz: it's an arch with a crossbar
<bob2> mdz: it symbolizes our unity through suffering
<Keybuk> but phone being USB storage device, that's sex
<Keybuk> http://descent.netsplit.com/~scott/dsc00009.jpg
<Keybuk> that's a far more appropriate "gang sign" for arch
<daniels> Keybuk: bluetooth with obex works fine for me
<bob2> woah, you're BALD
<mdz> Keybuk: catalogued in the corporate photo portfolio
<mdz> Keybuk: by the way, wHAT HAPPENED TO YOUR HAIR
<daniels> woah
<daniels> haha
<Keybuk> I got bored of it
<bob2> haha
<fabbione> Keybuk: omg!
<luis_> whoah
<bob2> so you reimplemented it from scratch
<fabbione> you look like a nazi!
<bob2> in python!
<luis_> Keybuk == scott
<daniels> ... is that a dressing gown?
* luis_ had never made that connection
<Keybuk> luis_: yes :p
<bob2> daniels: I'm glad of it, personally
<daniels> Keybuk: i think that picture violates the code of conduct :P
<Keybuk> mdz: anyway, you can talk; the first time I met you, you had lots of hair
<Keybuk> and it to mysteriously vanished under suspicious circumstances
<mdz> most of you folks met me during a rare hair-having period of my life
<daniels> i've done the reverse; my hair has blossomed since I joined Canonical
<mdz> I have returned to a reasonable level of hairness since
<bob2> mine too
<bob2> Keybuk: linkage of mdz with hair, kthx
<Keybuk> The Ubuntu Technical Bald
<mdz> next thing, you'll be saying that you scaled walls because of me
<mdz> Keybuk: that's a cameraphone photo?  not bad in terms of resolution
<fabbione> mdz: we all remember the foot prints on Oxford's walls
<mdz> 1632x1224
<Keybuk> yeah, has a two mega-pixel camera in it
<Keybuk> and a flash/light that doubles as a weapon in case of emergencies, instantly blinding anyone you shine it at
<Keybuk> which is quite fun
<mdz> fabbione: the evidence has been summarily erased
<daniels> me with possibly slightly more hair than I do now: http://people.freedesktop.org/~daniels/tmp/dsc00549.jpg
<daniels> me slightly pre-oxford: http://people.freedesktop.org/~daniels/tmp/dsc00552.jpg
<daniels> it's now returned to the former, maybe a tiny bit longer, actually
<Keybuk> I tend to bounce between ultra-short and long
<Keybuk> in other words, I get pissed off with it, shave it all off, and forget about it for a year, after which I do it again :p
<mdz> daniels: 90 degrees out of phase
<daniels> mdz: yeah, it's on a remote host, can't be arsed scp'ing it back, rotating it, and scp'ing it over again
<daniels> mdz: (it was on there from an ancient backup of my old machine)
<Keybuk> open it in gnome image viewer, rotate, and save
<Keybuk> it should "just work"
<daniels> current vintage daniels making the ubuntu gang sign: http://amnesiac.heapspace.net/~daniels/gang-sign.jpg
<Keybuk> that's an impressive book-shelf
<mdz> nice natural lighting
<daniels> Keybuk: yeah, all dad's books
<daniels> Keybuk: the book with the three blue stripes to the left of my shoulder is mastering dBase IV programming
<Keybuk> yes, I actually have that one I think
<daniels> mdz: normal light coming in from the window, the rest of the house is dark as hell
<daniels> terrible design for lighting
<Keybuk> http://www.netsplit.com/2005/redecoration/off02_wall-done.jpg <-- my bookshelf is considerably less impressive :(
<mdz> http://dijkstra.csh.rit.edu/~mdz/temp/DSC00002.JPG <-- mdz freshly shorn
* fabbione promoted davis has his new battlestar
<fabbione> s/has/as
<daniels> Keybuk: that's eight shelves behind me; we have 35
<Lathiat> daniels: damn
<Lathiat> thats alot of boooks
<Keybuk> mdz: that is a fantastic "rabbit in the headlights" look
<daniels> mdz: dude, we're all comparing pictures from the last 12 months, keep up :P
<bob2> Keybuk: wow, nice house
<mdz> daniels: are you trying to say that I look older?
<daniels> mdz: you look about 16 in that picture
<mdz> I was about 21 I think
<Keybuk> daniels: I was going to go with 14
<mdz> Keybuk: what is the actual colour of the lighting in that photo?
<mdz> the overall composition is very reddish
<Keybuk> bob2: yah, I like it :p
<Keybuk> mdz: ordinary halogen
<Keybuk> the walls are pink :p
<mdz> "ordinary eye-destroying halogen"
<daniels> Keybuk: oh, and that's sol8 beind my other shoulder :)
<mdz> not one, but TWO ubuntu CD display cases
<daniels> mmm, it's about a bajillion times cleaner than my house
<bob2> I like the artful art54g antenna arrangement
<Keybuk> mdz: I gave away a _lot_ of Ubuntu CDs
* daniels goes downstairs to poke at the stuff in the pot.
<mdz> and I
<Keybuk> meh, 'spose I better try and head to the gym
<mdz> Keybuk: 24-hour gym?
<Keybuk> no, is 6am here
<Keybuk> they open now
<mdz> 6am is essentially the middle of the night
<Keybuk> I wish it was 24 hours though
<Keybuk> would fit my sleep pattern better
<mdz> you have a sleep pattern?
<mpt__> sleep patterns ... I remember those
<Keybuk> sure, impressionism is still art ;)
<fabbione> Keybuk: dpkg 1.13.7 make the kernel FTBFS on i386 :)
<Keybuk> fabbione: oh?
<mdz> Keybuk: DESTROYER OF WORLDS
<Keybuk> is this because of an unexpected reason?
<Keybuk> or is this just the symlink doko hasn't put in gcc yet?
<fabbione> Keybuk: let me try to explain, but i have no idea what to look for exactly
<fabbione>  /usr/src/wartydevel/kernel/breezy/linux-source-2.6.12-2.6.11.94/scripts/gcc-version.sh: line 11: i486-linux-gnu-gcc: command not found
<mdz> the best explanation would be a URL for a build log
<fabbione> mdz: it fails like after 10 lines...
<Keybuk> yeah, doko knew that one would happen
<fabbione> there is not even a need for a build log
<Keybuk> breaks zlib too
<fabbione> Keybuk: so i need to wait for a new set of gcc???
<mdz> zlib is unimportant; hardly any packages use that thing
<Keybuk> ln -s /usr/bin/i486-linux-gcc /usr/bin/i486-linux-gnu-gcc
<Keybuk> or whatever it wanted
<fabbione> Keybuk: i somehow... hmmm can NOT do that inside the buildd!
<Keybuk> mdz: Are you the Gatekeeper?
<mdz> Keybuk: are you the keymaster?
* fabbione shakes at the idea of mdz and Keybuk opening the doors to zul
<Keybuk> Gozer the Gozerian, Gozer the Destructor, Volguus Zildrohar, the Traveler has come!
<mdz> fabbione: ITYM "XUL"
<Keybuk> Choose and perish!
<Keybuk> "iz xul bug"
<mdz> Everything was fine with our system until the power grid was shut off by dickless here. 
<Keybuk> Is that true?
<mdz> Yes it's true
<Keybuk> tsk @ mdz failing to complete the quote correctly
<mdz> next UbuntuConf: Ghostbusters screening BOF
<mdz> Keybuk: dude, I was correct and you were off
<Keybuk> "Is that true?" ... "Yes, this man has no dick"
<mdz> s/Is that true/Is this true?/
<mdz> -> "yes it's true"
<mdz> followed by, "this man has no dick"
<Keybuk> you still missed the funny bit :p
<mdz> you failed to provide the correct cue
<Keybuk> meh
<mdz> feel free to review the film to verify
<Keybuk> you've studied it that closely?
<mdz> trust me
<Keybuk> it's still too early to watch movies
<mdz> movies >> gym
<Keybuk> my neighbours dislike my sound system
<mdz> this problem can be trivially addressed by a decrease in volume
<Keybuk> where's the fun in that?
<Keybuk> movies are supposed to be watched LOUD
<Keybuk> on a big tele
<mdz> staying alive and within the terms of your lease?
<Keybuk> heh, I own the freehold on my house :p  no lease here
<mdz> the proper size of the screen is relative to the size of the room and the viewing distance/angle
<mdz> a large screen is not necessary unless it is distant from the vewier
<mdz> viewer
<lifeless> mdz: not really, can be later. whatsup ?
<mdz> lifeless: allow me to pause and review my notes in order to establish the basis for that ping
<mdz> lifeless: oh yes, I wanted to pick your brain about squid
<lifeless> sure
<mdz> I have encountered a web server whose responses squid persisnently rejects
<lifeless> if you dontmind latency, now is ok ;)
* Keybuk heads to the gym, really, properly
<mdz> lifeless: are you behind a squid at the moment?
<mdz> lifeless: e.g., http://www.la.com/home/interstitial?stxt=foo&button.x=0&button.y=0&sd=Results+for+%22foo%22
<mdz> its response looks reasonably compliant to the naked eye
<mdz> but squid rejects it
<pitti> Morning
<\sh> moins pitti
<mvo> morning pitti 
<pitti> Hi mvo, \sh
<pitti> Mez: yay, the findutils bug was fixed in Debian (and upstream)
<pitti> Riddell: ^
<fabbione> hey pitti
<pitti> Hi fabbione 
<\sh> hmmm...is anybody working on this project? https://alioth.debian.org/projects/webapps-common/
<pitti> brb
<jdub> mdz: who? (dutch)
<\sh> jdub: is it possible to put the "ircnicks" under the realnames on the planet? just like the debian planet=
<\sh> s/=/\?/
<jordi> \sh: uh, isn't it the other way round?
<\sh> jordi: sorry...on planet.gnome.org is it 
<\sh> not on debian ;)
<pitti_> Riddell: here?
<mvo> elmo: can you please sync balsa (override ok)
<jordi> hmm
<mvo> jordi: hmm?
<jordi> ECHAN, but my server was late exactly 1h.
<pitti> carlos: it seems you have a hard time convincing the fdo people about the .desktop translation domain idea...
<carlos> pitti, yeah :-(
<daniels> is that the .mo vs .desktop thing on xdg?
<carlos> pitti, I think we will need to do it and if it's fast enough, try again
<daniels> with the binary .desktop format
<carlos> dand, binary .desktop format?
<carlos> s/dand/daniels/
<daniels> carlos: there's some @sun.com guy on xdg@ talking about .mo, which is basically a binary format for .desktop aiui
<pitti> brb
<carlos> daniels, is that thread and I send some mails about it, yes, but it was an extension instead of a movement to .mo files by default as people seems to read...
<daniels> carlos: right
<daniels> i haven't been following it too closely
<carlos> pitti, the main problem there is that only two persons answered the mails
<carlos> pitti, so I think the other don't care
<pitti> daniels: right, Mark is the tough one and the other one seems to agree with you
<daniels> i don't really have anything to do with specs; waldo bastian would be the person to talk to
<daniels> pitti: hm?
<carlos> pitti, well, I don't know if they agree or not, they just don's say anything
<pitti> daniels: erm, sorry, that was aimed at carlos
<carlos> daniels, he's on the CC of some of the mails
<daniels> carlos: aha
<carlos> no answer yet
<carlos> pitti, the good point is that SUN has already a patch that adds .mo support to GNOME
<pitti> doko: btw, is the uploading of C++ packages still restricted?
<carlos> pitti, so we could ask them for it
<pitti> carlos: yay :-)
<pitti> carlos: yeah, I read about it (I just read the whole thread)
<carlos> ok
<seb128> carlos: I don't think we should piss upstream though
<seb128> carlos: ie: are we sure that .mo are not slowing the panel a lot?
<pitti> elmo: is there a reason why postgresql-8.0_8.0.3-5 is not autosynced from Debian?
<carlos> seb128, sun says it's not a big issue
<carlos> seb128, and that's not pissing upstream
<seb128> carlos: a sun guy say that and he has no clue on how to mesure performances apparently
<carlos> seb128, we have two options, forget .desktop support or fix them in a way they can be updated with language packs
<seb128> carlos: when upstream get "your piece of software is slow" bugs that pisses upstream
<pitti> ... or use our original idea of a parallel hierarchy
<carlos> seb128, dude, we are not talking about integrate a slow feature
<pitti> seb128: no, we won't do desktop .mo without any sort of caching
<carlos> seb128, we need to experiment and go for the best solution
<carlos> seb128, and I'm sure a cached version will be needed
<seb128> carlos: as explained on the list, the .mo way means a lot of i/o which is slooooow
<daniels> seb128: my panel's still sucking up 100% CPU and 2GB of RAM, how can it possibly be worse? :P
<seb128> right, if we use a cache I've no objection
<seb128> daniels: kick vuntz on #gnome-hackers :)
<Treenaks> daniels: dpkg --purge setiathome-panel-icon ?
<daniels> Treenaks: the first question anyone asked when I pasted that output was 'are you on amd64?'
<daniels> so apparently GNOME doesn't work on amd64
<daniels> i'm still waiting for seb to fix it
<Treenaks> daniels: scary
<seb128> troooool
<carlos> seb128, first, we implement it, then we improve its performance, it's simple. If the performance is good enough, then upstream would be interested. If we forget that feature because upstream has a closed mind... I don't think it would be a good thing to improve our users experience. We need a prototype :-)
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=10601, nobody spoke about amd64 for your panel bug :p
<seb128> carlos: right, but you are not the one who need to work with upstream after breaking their software :p
<carlos> seb128, well, I think we are not breaking their software but improving it :-)
<carlos> seb128, that's why I don't see a problem there :-D
<daniels> seb128: that was the first question that was asked on IRC
<seb128> oh :)
<daniels> seb128: (on #g-h)
<seb128> carlos: markmc is upstream, if he says than we are going to slow the panel just be carreful on this
<carlos> seb128, I know he knows what are he talking about
<carlos> seb128, but we are not going to give our users a solution that breaks the panel that way
<carlos> it's stupid from our side to do it
<seb128> nice :)
<carlos> seb128, that's why pitti and I talk about caching it or any other solution that improves the performance
<pitti> yes, but that's an implementation detail
<pitti> it does not need to become part of the spec
<pitti> seb128: btw, gnome-menus translations should be there
<pitti> seb128: gnome-panel's are missing, and now I know why
<pitti> infinity: here?
<{Seb}> hi all
<seb128> pitti: why?
<{Seb}> i'm doing a dist-upgrade to breezy
<{Seb}> and it is removing totem, totem-xine and xine-ui
<{Seb}> any idea?
<pitti> seb128: the tarball neither contains a POT file nor stripped mo files from the debs
<{Seb}> also, it is upgrading the kernel to 2.6.11
<pitti> seb128: thus the script cannot find out the domain
<{Seb}> does this have inotify?
<{Seb}> 0.23 I mean
<pitti> seb128: I have NFC why the tarballs don't contain stripped debs sometimes
<seb128> pitti: "implementation detail" is an easy way to say "we don't care about performance, let's do the change and fix things then if we can"
<seb128> k
<pitti> seb128: no, it is the right way if it comes to discuss a spec
<pitti> seb128: merely adding another option for doing translations won't hurt anybody
<Treenaks> {Seb}: 2.6.12 has it, don't know about .11
<Treenaks> {Seb}: and try apt-get install totem when it's done dist-upgrading
<fabbione> {Seb}: don't use .11
<fabbione> use .12
<{Seb}> Treenaks: thanks
<{Seb}> is there a meta-package i can install which will install all the neccessary packages?
<Treenaks> {Seb}: ubuntu-desktop, but that might be broken atm
<{Seb}> yeh, that's been removed at the moment
<{Seb}> i guess i need linux-kernel-headers
<{Seb}> what else?
<{Seb}> sorry but I've been away from the Ubuntu scene for a while
<{Seb}> for the past ~1 month, I have been using SUSE for the latest packages but Breezy is looking awesome
<{Seb}> btw, is there going to be a graphical installer in breezy final?
<{Seb}> is that the OEMInstaller?
<pitti> mvo: Warning: tarball update-manager_0.37.1+svn20050404.2_translations.tar.gz does not contain a POT file
<pitti> mvo: I thought you fixed that?
<mvo> pitti: fixed locally, I haven't uploaded a new package in a while. should I do a upload with just the intltool-update change?
<mvo> pitti: IIRC when we talked about it last week you said that it's ok if it comes with the next regular upload
<pitti> mvo: ah, ok; if you do an upload in the next weeks anyway, that's fine
<mvo> pitti: hopefully this week
<pitti> mvo: ISTR that you actually uploaded, so nevermind
<mvo> pitti: np :)
<seb128> do we have any germinate-output//breezy/rdepends/ graph with universe?
<fabbione> hey Kamion 
<pitti> hi Kamion 
<pitti> Kamion: everything alright in your new house?
<Kamion> morning folks
<Kamion> pitti: haven't got ADSL sorted out yet - that's coming tomorrow morning
<Kamion> otherwise not too bad
<opi> morning Kamion, how's move?
<Kamion> I'm working from Kinnison's place for today
<pitti> Hey sivang 
<sivang> pitti: Hey Martin! What's up? What's the breakage level of breezy currently? ;-)
<pitti> sivang: it's actually not that bad any more
<sivang> pitti: ah cool, I've just started to upgradd
<Mez> hey pitti, yeah I saw :D
<Mez> was it merged over to ubunut yet
<Mez> ubuntu *
<pitti> Mez: not yet
<Mez> ah well
<Mez> btw, I managed to fix k3b
<sivang> hmm, are we supposed to lack some of the hoary files for breezy?
<sivang> Err http://de.archive.ubuntu.com breezy/main libglib2.0-data 2.7.0a-0ubuntu1
<sivang>   404 Not Found
<pitti> libglib2.0-data | 2.7.0a-0ubuntu1 | http://archive.ubuntu.com breezy/main Packages
<pitti> hm
<seb128> pitti: what about it?
<daniels> heh, mythbusters has a thing about floating small children with balloons
<daniels> i had flashbacks to the lca dinner
<pitti> seb128: I mean, wrt. sivang's question, it should be there
<seb128> pitti: oh, k
<thom> daniels: i don't _think_ kamion counts as a small child ;-)
<sivang> pitti: this happens to Err http://de.archive.ubuntu.com breezy/main libglib2.0-0 2.7.0a-0ubuntu1
<sivang> pitti: as well, weird
<Kamion> they may just not have hit that mirror yet
<Kamion> looks that way
<sivang> Kamion: I see, I'll finish the upgrade and try again afterwards then
<Kamion> I think de.archive caught its upstream mirror half-way through updating, or something
<seb128> Kamion: do we have a germinate-output//breezy/rdepends/ version with universe?
<seb128> or is that easy to get?
<Kamion> no, not yet
<seb128> we could use one such graph for gtk+1.2 (we want to clean up old GNOME/GTK 1 stuff) .. is that easy to get?
<Kamion> no, not yet
<Kamion> :-)
<Kamion> give me a bit
<sivang> heh
<sivang> seb128: you want that also for the lp integration stuff?
<Kamion> seb128: germinate output for universe is kind of meaningless
<Kamion> seb128: are you just talking about "what depends on gtk+1.2 in universe"?
<Kamion> seb128: also, please port putty to gtk2 before killing gtk1, kthxbye
<tseng> Kamion++
<seb128> Kamion: that's rather "getting a graph of rdepends for gtk+1.2"
<tseng> i havent found another way to ssh via an authenticated http proxy
<Kamion> seb128: apt-cache rdepends. germinate isn't designed for that
<tseng> or, another simple way
<seb128> Kamion: rdepends doesn't do a graph but a list
<Kamion> seb128: however, germinate does an entirely different task
<Mez> hmm does anyone here know the easiest way to create the "Release" file?
<Kamion> seb128: rdepends is just a side-effect of germinate - it's not a general-purpose reverse-depends grapher
<Mez> in the main dist
<Kamion> Mez: apt-ftparchive release
<seb128> k, so what is appropriate to get a graph like http://people.ubuntu.com/~cjwatson/germinate-output/breezy/rdepends/gtk+1.2/libgtk1.2 ?
<Kamion> seb128: there's apt-cache dotty
<Kamion> you might be able to use that
<seb128> I'll have a look, thanks
<Kamion> seb128: otherwise, you could create a custom set of seeds containing everything in the archive, and run germinate over it locally
<seb128> hum, right
<Mez> thx Kamion
<Kamion> then you'd probably get suitable rdepends output, assuming it didn't crash :-)
<seb128> anyway we don't plan to trash gtk1.2
<Kamion> the germinate package in breezy should be fine for that
<seb128> just to clean up stuff like "glade"
<seb128> ie: all the old gnome/gtk1 apps which are deprecated
* daniels mutters something about xlibs-dev.
<Kamion> elmo: any chance I could get /srv/ftp.no-name-yet.com/database/ synced to rookery (maybe without the contents/ subdirectory, since that's huge)?
<Kamion> elmo: it would be useful for getting britney running on rookery
<lifeless> mdz: what squid version ?
<lifeless> and what symptoms do you see? (do you get some of the page/ broken graphics/ an error page ?)
<lifeless> it works for me with my local squid here, which is a) squid 3.0, and b) somewhat out of date.
<tepsipakki> hmm.. is this a bug: if I edit applications.menu and tell some menus not to include some specific .desktop-files, it then creates the "Other" menu and all those previously deleted launchers are in it..
<doko> pitti, Kamion: libdb4.2++-dev: Depends: libdb4.2-dev (= 4.2.52-18ubuntu5) but it is not going to be installed
<doko> I fail to see why
<lifeless> mdz: if you are running latest- squid 2.5, stable9 or 10, then you are seeing the results of our http-protocol attack defenses. There are a bunch of ways to compromise http behaviour that we are now checking. (things like adding headers, duplicate headers, headers with whitespace that makes their content look like other headers, etc.
<mvo> doko_: seems to work here. maybe your mirror is outdated or something?
<Kamion> looks fine on the archive to me
<doko_> infinity: ^^^ is it the buildd which is outdated? OOo2 build ...
<Kamion> sivang reported apparent breakage with de.archive.u.c above
<Kamion> lifeless: is base-config syncing properly? there are changes from Saturday not reflected in base-config--MAIN--0
<Kamion> lifeless: (but merging is now SO MUCH EASIER, thank you :-))
<lifeless> Kamion: looks like it is
<lifeless> whats the latest rev in base-config ?
<lifeless> (in svn)
<Kamion> r1564 | bubulle | 2005-06-12 14:05:24 +0100 (Sun, 12 Jun 2005) | 1 line
<lifeless> mmm
<thom> tseng: um. sh: line 1: 11722 Trace/breakpoint trap   (core dumped) LANG=C /usr/bin/monodis --assemblyref Tomboy.exe 2>&1
<lifeless> haha
<lifeless> linux doesn't like have 32K dirs in /tmp
<Kamion> tmpfs?
<lifeless> uhm
<lifeless> yes
<lifeless> importd has been leaking tmp dirs
<lifeless> and now gets 'Exception: [Errno 31]  Too many links: '/tmp/tmphcqufX''
<doko_> can anybody else than elmo see, why a package is not accepted (got neither an accept nor a reject)? i.e. binutils
<pitti> doko: which version?
<doko> 2.16.1-1
<pitti> 2005-06-13 02:40: binutils_2.16.1-1_source.changes
<pitti> binutils_2.16.1-1_source.changes
<pitti> REJECT
<pitti> Rejected: Unknown distribution `unstable'.
<pitti> Rejecting.
<pitti> haha :-)
<doko> ohh, fun
* jordi snickers.
<astharot> lol
<doko> hmm, no reject mail ...
<Kamion> shouldn't be -1 to Ubuntu anyway
<Kamion> surely?
<Kamion> doko: that's because you used doko@debian.org in changed-by:
<Kamion> which isn't whitelisted
<pitti> Kamion: http://udu.wiki.ubuntu.com/LanguagePackRoadmap was never approved so far; since it affects the installer (in particular the kde/gnome/other split), are you fine with that?
<doko> Kamion: it's the same upload as I'm proposing for unstable, sure, I can name it 1build1
<lifeless> Kamion: syncified
<lifeless> 4 new patches
<Kamion> -1build1 *before* -1 gets uploaded to unstable seems unwise
<doko> Kamion: ok. if that get's whitelisted, I'll get the mails twice?
<doko> Kamion, so upload -0?
<pitti> Kamion: i. e. can the Kubuntu installer install l-p-kde-lang and the Ubuntu installer installs l-p-gnome-lang?
<doko> -0build1?
<pitti> doko: why not 0ubuntu1? you can sync later
<Kamion> doko: -0ubuntu1 and merge when -1 actually gets uploaded (you don't know that it will be identical unless you have a time machine ...)
<Kamion> pitti: that's possible, yes
* doko grumbles, seeking my time machine
<Kamion>      + Support for resolving dependencies (--resolve-deps)
<Kamion> mdz: ^-- debootstrap 0.3.0 changelog
<fabbione> elmo: ping?
<daniels> Kamion: \o/
<daniels>  dbus (0.33-0ubuntu4) breezy; urgency=low
<daniels>  .
<daniels>    * Re-enable dbus, rename libdbus-cil to libdbus-1-cil.
<daniels> ladies and gentlemen, give it up for our very own Tourguide Thom!
<daniels> 'Bug#1794: dbus: not dbussy enough'
<Kamion> mvo: can we get #225947 fixed in apt?
<Kamion> debootstrap wants it
<Treenaks> daniels: debussy?
<mvo> Kamion: I can build you a package for this if you then test it :)
<daniels> Treenaks: 'Re-enable dbus'
<Kamion> mvo: sure
<Kamion> mvo: (though it'll have to be once I get my machine farm back)
<mvo> Kamion: I cleaned up aj's diff and merged it into a branch already, I just never got around to test it. how was moving? as bad as moving a house usually is? or worse :) ?
<thom> daniels: oh, bite me
<Kamion> mvo: about normal badness, pretty much
<Kamion> I get to live in chaos for a while
<{Seb}> hey all
<{Seb}> i got breezy working!
<{Seb}> it is awsome!
<{Seb}> thanks guys :-)
<{Seb}> the only thing is that Tomboy is broken so I'm gonna build it from source
<Mez> lol
<mvo> Kamion: I think after we moved last time (gf and me) we opened the last cardboard box with $stuff about 6 months after the moving 
<Mez> havre fun
<{Seb}> btw, can 
<{Seb}> i need the mp3 and libdvdcss
<{Seb}> should i use the Debian Marillat repos or the Backports Hoary Extras?
* fabbione scratches his head on fs-common-modules
<Mez> seb - neither
<Mez> buold from source
<{Seb}> why?
<{Seb}> what's wrong with them?
<Mez> their not built for breezy, and they probably wont work in breezy
<Mez> marillat = not for ubuntu
<Mez> hoary backports = not for breezy
<{Seb}> true
<Kamion> mvo: that won't surprise me :-)
<Kamion> fabbione: what about it?
<{Seb}> i like the new clearlooks v. nice
<{Seb}> i am glad that acroread is the universe
<fabbione> Kamion: if both ext2 and ext3 are modules, fs-common needs to have mbcache.ko... now.. this is true for ia64, but not for ppc... and why ppc has nls/nls_base in there????
<Kamion> fabbione: it's only not true for powerpc because nobody's merged my patch from Debian linux-kernel-di-powerpc-2.6
<fabbione> Kamion: and both ia64 and ppc are the only ones with both ext2/ext3 as modules
<Kamion>       + Add mbcache to fs-common-modules, and make ext2-modules and
<Kamion>         ext3-modules depend on that.
<{Seb}> hey, it recongises my iPod Shuffle
<{Seb}> cool!
<Kamion> nls is in there because stuff from multiple udebs depends on it
<fabbione> Kamion: that kind of missing depends would have a caused mbcache to be in both ext2 and ext3 = FTBFS
<Kamion> ide-modules, iirc
<Kamion> fabbione: wasn't needed before 2.6.11 or so, I know that much
<Kamion> I assume mbcache got introduced as a module
<fabbione> Kamion: yes, but we had this problem with 2.6.10 too on some arches
<fabbione> oh well
* fabbione goes and checks the udebs
<sladen> {Seb}: these are question for #ubuntu   You can get dvdcss/mp3 from multiverse
<{Seb}> thanks, sladen
<{Seb}> just i guessed since it was breezy
<fabbione> Kamion: this is royally weird.. the mbcache in .12 was landing in ext3 only....
* fabbione suspects a conspiracy against a working ppc kernel
<fabbione> :P
<mvo> Kamion: what kind of deb do you want for #225947? I assume ppc? 
<Kamion> mvo: yup - or a source package is fine
<sivang> bah, what about all those locale settings error on the upgrade...?
<fabbione> Kamion: the nls_base in fs-common is (yet) another missing allignment in the kernel CONFIGs
<fabbione> Kamion: at least i manage to understand wth was going on
<fabbione> thanks dude!
* fabbione goes to hit his head against a pillow for an hour or so, before starting a titanic fight with ide*
* toresbe gives fabbione a decent beer for the work
<fabbione> ehhe
<toresbe> get drunk, it makes the kernel more comprehensible :P
<fabbione> oh i am not fighting with the kernel itself
<fabbione> i am trying to realling the installer kernel udebs with what's in the kernel images
<fabbione> that's a real challenge :)
<sivang> oh so many mono errors as well :-)
<jdub> daniels: fair use doesn't magically disappear because someone explicitely grants you additional rights beyond copyright :-)
<daniels> jdub: sure, but the entire concept of a document about free software being rabidly non-free is entertaining
<daniels> jdub: does 'verbatim' mean that they intend that I can't just quote part of their speech? :)
<azeem> daniels: you cannot change the GPL either, remember?
<jdub> daniels: fair use doesn't magically disappear because someone explicitely grants you additional rights beyond copyright :-)
<daniels> jdub: sure, but again -- if their intent was to disallow that, then they're crap
<azeem> I think their intent was that you are free to post that whereever you want, but please don't add 'RMS is the satan' in the middle of it
<daniels> sounds lame to me
<daniels> the following is legal:
<daniels> theFSF(can->bite.me);
<daniels> the following is not legal:
<daniels> The FSF can bite me.
<daniels> ...
<Treenaks> daniels: in perl both would work
<erb> hello
<doko> seb128: libedataserver1.2-dev is the only package in main b-d on db4.1-dev, causing the FTBFS for OOo2, infinity did find out the cuase. any reason to stick with 4.1?
* daniels stares at drbyte.
<drbyte> hi daniels 
* drbyte wonders why the stare ;-)
<seb128> doko: no, I've forgotten to drop the Debian change
<seb128> doko: eds has a copy of libdb, Debian patches it to use the system version which is stupid
<seb128> I'll fix that with next upload
<doko> fine, infinity is offering an upload as well
<seb128> go for it
<doko> infinity: ^^^ ;-)
<infinity> seb128 : Using the system version isn't stupid, just using the system 4.1 version is stupid. :)
<infinity> seb128 : I'll just switch it to 4.2, and everything will be happy.
<infinity> (Please, please, plase don't use bundled libraries unless absolutely necessary)
<daniels> infinity: here I was about to re-enable expat, zlib, FreeType, fontconfig, et al, within xorg
<infinity> daniels : YOu should be shot for even joking about it. :)
<seb128> infinity: no no no
<infinity> DO you have any idea how hard it is to track down every copy of zlib in the archive when an exploit comes out?
<infinity> (Hard enough that we generally miss a few)
<seb128> infinity: upstream use 4.1 for a reason
<infinity> seb128 : What reason is that?
<infinity> seb128 : Is it a *valid* reason?
<seb128> they say than doing what you want to do is the best way to break the compatibility with other evolution installation/distro of your datas
<infinity> Or is it the same reason apache bundled an old PCRE.. ("It's too much of a pain to try to upgrade our in-tree copy, so we never bothrered")
<daniels> infinity: yeah, I know
<daniels> infinity: this is why attempting to build with zlib will produce around 6000 lines of #warnings on a make World
<infinity> seb128 : Ugh.  So, they'll never upgrade, because asking users to db_upgrade their data files is too much hassle?
<daniels> infinity: double that if you also include FreeType
<infinity> seb128 : But, whatever.  I'll give you discretion on this one.  If you want to re-enable the builtin copy, do so.  I'll just wait for someone to tell me it's been fixed and retry OO.org.
<seb128> infinity: dunno the details, but I've spoken some days ago about that with ximian guys
<infinity> (Well, you don't even have to ask users to db_upgrade, you just need to make sure you always db_open with the "upgrade on open" flag..)
<infinity> It means people can't move BACK to old distros that use old libdb versions, but that could be seen as a feature. :)
<kkanto34> hi
<seb128> infinity: they are strongly again using an another version of libdb and I think we should not try to piss them on this for almost no win
<infinity> seb128 : Anyhow, if you know what needs to be done to fix my buildd problem and to keep your upstream happy, do it. :)
<seb128> k
<tseng> thom: howd you manage that
<thom> tseng: just building tomboy...
<tseng> on?
<pitti> Riddell: any luck with extracting pot files in KDE bulds?
<pitti> Riddell: builds, even
<thom> amd64
<Riddell> pitti: yep, I'm packaging the xgettext-kde now, I'll get you to review it in a bit
<pitti> cool
<pitti> Riddell: I'm in the process of splitting the langpacks ATM
<thom> tseng: also, when is libgtk-cil moving to main?
<tseng> thom: im apperantly supposed to be filing some kind of detailed report about all the packages
<tseng> thom: but rather im spending my free time actually fixing them atm
<tseng> not sure whats more correct, but i cant be doing both in the same time frame
<pitti> tseng: if you bug and remind me from time to time I'll do the report eventually :-)
<tseng> pitti: heh you have better things to do as well
<pitti> right, but somebody has to review the stuff
<tseng> i can do it eventually
<tseng> or do it on broken packages
<tseng> which brings me back to, where is koke
<pitti> oh, fixing first is definitively the right approach IMHO :-)
<tseng> he "owns" a package i need to fix
<tseng> if i dont see him soon i am just going to upload it
* pitti points out that we don't have a strong maintainer concept in Ubuntu
<tseng> true, but i still find it a bit rude
<tseng> ive not seen him in nearly a week now so im going to fix it soon
<pitti> yes, depends on the work relationship you have with him
<pitti> but merely fixing bugs should be appreciated (as long as you don't repackage it from scratch...)
<tseng> thats sort of what its like
<tseng> the package is done according to "old" mono policies
<tseng> so its a good number of changes for that + bugfix
<Lathiat> tseng: wheres the spec for the "new" policy
<thom> tseng: oh, ok. i just uploaded dbus with mono enabled and of course it broke due to no libgtk-cil. oh well.
<tseng> Lathiat: its a draft atm
<Lathiat> tseng: ok, wheres the draft :)
<tseng> Lathiat: wiki/CLIPolicy
<Lathiat> thanks
<tseng> nps
<tseng> it will move to debian wiki at some point
<tseng> thom: argh
<tseng> thom: that one doesnt need any fixing, lets document it tonight and move it over
<tseng> then kick dbus
<thom> yes please :-)
<tseng> its the beagle-related and dbus-dependants that still need the most love
<mvo> is 'search' broken in malone? 
<mvo> Kamion: apt with arch-override support is available at http://people.ubuntu.com/~mvo/apt/bts225947/. please give it a try and tell me if it works
<mvo> (source only)
<Riddell> pitti: could you take a look at http://dev.kubuntu.org.uk/~jr/kubuntu/gettext-kde/
<pitti> Riddell: the package looks fine so far, but I didn't test it
<pitti> Riddell: if it works, i. e. the tools produce a valid POT file from a source package, that's fine
<Riddell> pitti: do the .pot files need to be included in a binary package?
<pitti> Riddell: no, they don't even need to be included in the source package
<pitti> Riddell: i. e. it is okay to rm it in debian/rules clean
<pitti> Riddell: it must just be built so that pkgstriptranslations can pick it up
<pitti> Riddell: however, leaving it in the package diff.gz does not really hurt either, so do whatever is easier
<Riddell> pitti: ok, I'll upload gettext-kde and if NEW approves of it I'll modify and upload all the KDE packages
<pitti> Riddell: you really need to touch all packages?
<pitti> Riddell: isn't there anything like cdbs kde.mk which is a common piece of code where this could be hooked into?
<Riddell> pitti: yes, the debian/rules file or debian/cdbs/debian-qt-kde.mk file needs to be changed
<pitti> Riddell: btw, it must go into main before you can depend on it
<Riddell> pitti: plus the packages need to depend on gettext-kde as you say
<pitti> Riddell: we already modified cdbs for gnome.mk, so modifying kde.mk seems to be the right thing and easier for you
<Riddell> pitti: cdbs's kde.mk is out of date so most of the KDE packages include their own debian/cdbs/kde.mk and debian-qt-kde.mk
<jbailey> Riddell: I have no moral objection to cdbs being tweaked for Ubuntu's needs in Ubuntu only.
<pitti> Riddell: hmm, the dependency really hurts, that's right
<Riddell> but I can modify cdbs for the packages that use that too
<pitti> Riddell: argh, they copy cdbs stuff? how evil...
<Riddell> jbailey: of course then cdbs would have to depend on gettext-kde
<jbailey> Riddell: If you dno't want to upload cdbs for the changes you need, we can just move kde.mk out of the package so you can maintain it somewhere else...
<pitti> Riddell: about how many packages are we are talking btw?
<\sh> hmm..talking about tweaking cdbs..can we tweak lintian as well?
<Riddell> \sh: lintian just needs sycned with debian I think
<jbailey> \sh: I think it already is at least a little bit.
<Riddell> pitti: a dozen or so KDE modules
<\sh> jbailey: also for "non fdo desktop files for kde?" ,-)
<Riddell> \sh: that's been removed in debian version I'm sure so just sync with debian
<jbailey> Riddell: We'll likely also tweak the ant.mk stuff in some Ubuntu-specific ways.
<Riddell> jbailey: how would you feel about cdbs depending on gettext-kde?
<pitti> that doesn't really look right
<Riddell> pitti: why?
<pitti> Riddell: well, so far cdbs does not even depend on debhelper...
<jbailey> Riddell: I'd prefer not, since every cdbs package doesn't need it.
<jbailey> Riddell: I'd rather see a 'kde-build' package created which had all of the build-deps in it.
<pitti> Riddell: maybe we can convince infinity to just install it in the dchroots
<pitti> Riddell: or jbailey's proposal
<jbailey> But that's sort of the idea behind the control file generation and the build-depends handling.
<pitti> Riddell: in any way kde.mk should check for the existence of gettext-kde before calling it
<jbailey> cdbs2 will handle that in a much better way (although agreed to by the Debian DAM)
<Riddell> jbailey: DAM?
<jbailey> pitti: It could be a hard chjeck and a fail with a sane error message.
<jbailey> err.. ftp master.
<jbailey> I still tend to just think of Jrg as the DAM rather than The New Elmo(tm)
<pitti> jbailey: oh, why fail? if I build a pacakge locally, I don't need a pot
<jbailey> pitti: Yeah, true.  But you don't want it to wind up running through the buildd setup that way.  Maybe a DEB_BUILD_OPTION="nopot" check?
<Kamion> he's only an ftp assistant rather than master, but yeah
<jbailey> Kamion: Ah, didn't know.
<pitti> Kamion: speaking of ftp masters, I still need to tell elmo that we will add another 400 langpack related packages when we split off gnome and kde translations...
<Kamion> good luck
<pitti> he doesn't seem to be here today, but when he returns, I'll better get my asbesto pants :-)
<bob2> goddamn
<bob2> someone patch firefox to get rid of the "send link" option, which is right above the "copy link" item
<Treenaks> bob2: easy.. 1-line greasemonkey script :)
<Kamion> mvo: what's that supposed to do for Architecture: all packages?
<Kamion> mvo: at the moment extraoverrides work for Architecture: <architecture-of-override>, but if you say "foo/i386 Task i386-test" then it doesn't get applied to foo_*_all.deb
<sivang> tseng: tomboy is broken?
<mvo> Kamion: what real packages would make a good test-case?
<Kamion> mvo: I used apt-doc
<Kamion> I'll /msg you apt.conf and override if you like
<mvo> Kamion: thanks, please do that
<doko> Mithrandir: ia32-libs-dev ping (libGL.so.1 symlink)
<ddaa> Does anybody understand when cvs will print "file foo.c is no longer relevent" error messages?
<ddaa> lamont?
<daniels> iirc when it's been removed from the upstream repository, but you still have it on your system
<lamont__> ddaa: not I
<bob2> ddaa: lamont__ just knows how to provoke such errors using rcs, not cvs ;p
<ddaa> daniels: removed in which way? Removed as in "it's no longer at all in the repository, forget about it",  or removed as in "it's deleted, but you can still retrieve the file if you juggle three balls while standing on your hands"?
* lamont__ throws tomatoes at bob2
<daniels> ddaa: as in 'cvs rm'.  the file isn't present in the current repository state, but you can get it back by asking for it if you wan tit.
<lamont__> bob2: I only did what I did because, well, it seemed like a reasonable idea, at the time.
<lamont__> (once you have tac-nukes, everything begins to look like a small city)
<bob2> the road to cscvs hell is paved with ...
<ddaa> daniels: maybe I should give more context
<lamont__> bob2: I didn't say it _WAS_ a good idea. :-)
<bob2> hehe :)
<ddaa> I ask this question because the CVS protocol documentation says that the "Deleted" response is what is sent by the server in the cases where the cvs client prints "file foo.c is no longer relevent".
<ddaa> We get that response while doing one-file checkouts, where the CVS server supposedly has not information on the state of the local tree.
<ddaa> daniels: do you have any clue how we can convince the cvs server to stop trying to be smart, and just give us the damn file?
* lamont__ wonders what peoples thoughts are on tinyca... sabdfl?
<infinity> ddaa : Ask for a specific revision of the file, if you really want it.  If it's deleted on HEAD, the server will yell at you for trying to retrieve it without context.
<daniels> ddaa: find the revision immediately before the one it was deleted on, ask for that revision specifically
<ddaa> infinity: that's what we are doing, asking for a specific revision of a specific file
<daniels> ddaa: since you guys aren't working on branches, you just want to go back along HEAD
<daniels> ddaa: cvs up -r1.2 foo.c
<ddaa> daniels: thats' what we are doing
<daniels> awesome
<ddaa> we request specific revisions of the files, so we can get at past history.
<daniels> to me, it sounds like you're going one revision too far
<daniels> i.e. asking for a revision of the file in which it's already deleted
<tseng> daniels: any chance you could try building libgdiplus on ubuntu?
<ddaa> daniels: thanks, that's what I was fearing, I'll have to add some error reporting to figure it out.
<infinity> (The most receny revision of the file will be the revision in the Attic, so if you're asking for that one, it will spew errors at you)
<tseng> daniels: i couldnt get it to pick up freetype
<infinity> s/receny/recent/
<tseng> daniels: so it doesnt do a #def and fails later on ifdef || ifdef where neither font lib is set, basically
<daniels> tseng: tomorrow, yo
<tseng> daniels: sure.
<svenl> mmm, why are the packages on us.archive.debian.org corrupt, or at least some of them ? 
<svenl> Or am only me seeing that ? 
<bob2> do you mean ubuntu.com?
<bob2> then yes, it's screwed
<svenl> yeah.
<Kamion> ooh, d-i arch imports starting to appear
<Amaranth> svenl: the mirror is fscked
<svenl> Nice.
<svenl> only us.archive.ubuntu.com ?
<bob2> yes
* svenl wondered after redownloading those files for the 3rd time :/
<svenl> BTW, only the packages without good md5sum are suspisious, or should i empty my whole cache before upgrading ?
<mdz> Kamion: resolving deps in shell --> ph33r
<mdz> lifeless: that was with the squid in breezy, 2.5.9-10
<fabbione> morning mdz
<mdz> morning
<Amaranth> fedora core 4 is out?
<Kamion> lifeless: kernel-wedge seems to be a couple of days behind, too; last svn revision was r28324 (although only one patch missing)
<Kamion> lifeless: (am I being too impatient? I don't know what the sync frequency is supposed to be, although I got the impression from somewhere that it was a day)
<ddaa> Kamion: kernel wedge is happy and syncing
<ddaa> last sync this night 2:40 BST
<Kamion> ddaa: strange that it's out of date then
<ddaa> cannot say anything, svn updates seem to be lacking a bit of verbosity
<ddaa> does not appear to have got any new revision since it was first imported
<ddaa> on saturday
<mdz> Kamion: ./menu/pkgsel: line 5:  8688 Segmentation fault      DEBIAN_PRIORITY=high aptitude --without-recommends -y install "$PATTERN"
<mdz> Kamion: that's from a completely reproducible Hoary installation failure
<Kamion> erk. surely an aptitude bug though ...
<mdz> curious that it works for the rest of us, though, in that case
<Kamion> although I suppose a bogus pattern could be triggering it or something
<Kamion> unusual language?
<mdz> (this is reported by a friend of mine)
<mdz> US english, certainly
<Kamion> well, an unusual language, but not in any sense that matters here ;-)
<Kamion> I dunno, I'd have to see an strace or something
<mdz> 0 packages upgraded, 617 newly installed, 0 to remove and 6 not upgraded.
<mdz> 6 not upgraded?  eh?
<mdz> Kamion: I've CCed you on my response to his mail, and attached base-config.log and installer/syslog
<Kamion> mdz: ok, but I won't receive any mail until tomorrow; my home server is in limbo
<mdz> eek
<Kamion> it's still at the old house; I'll pick it up this evening and move it
<Kamion> now that it is no longer a critical part of my former housemates' network infrastructure
<mdz> heh
<grirgz> hi
* mvo is away to play hockey now
<Kamion> mdz: aj's blog post about debootstrap 0.3.1 is way neater
<Kamion> I'll do some cdimage hacking tomorrow to prepare for that
<Kamion> and that's significantly ahead of cdebootstrap, which still requires a bunch of hardcoded stuff
<mdz> seb128, jamesh: how have the LaunchpadIntegration goals turned out?
<sivang> mdz: I've just started working on the list, which to IMHO would resemble the old one as far as the non menu / custom gui apps 
<sivang> mdz: for the std users, I'll have detail
<eazel7> hi ppl
<eazel7> can I switch to breezy now?
<eazel7> (I mean, is it still broken?)
* mdke points at the topic
<doko> infinity, lamont, lamont__: please buildd OOo2, new evolution-data-server is in the archives
<lsuactiafner> can anyone recommend me CASE tool to draw use-case diagrams ect?
<ddaa> lsuactiafner: try dia
<lamont__> doko: queued
<fabbione> mdz: ping?
<chrissturm> lsuactiafner, poseidon uml is nice if you dont mind using java
<fabbione> hey sabdf1 
<sabdf1> howdy
<fabbione> humpf... mono is not portable on sparc
<tseng> hm its supposed to be afaik
<fabbione> it is for sparc/solaris
<fabbione> not for sparc/linux :/
<zul> fabbione: port it then ;)
<tseng> ah :(
<fabbione> zul: ehhe
<zul> people would love you...more so than now...*cough* bs *cough*
<fabbione> zul: oh i get already enough love :)
<zul> hehe
<fabbione> specially when something fucks up and everybody knocks on my door :)
<fabbione> it's still love.. i swear :P
<mdz> fabbione: pong
<fabbione> hey mdz.. i was just writing an email to you
<mdz> mako: is there a log/summary of the backports meeting published somewhere?
<mdke> mdz, kassetra is working on it I believe
<tseng> mdke: she was working on the agenda also, it was blank up until meeting day.
<mdke> tseng, don't shoot the messenger man
<mdke> i don't know how she is getting on with it
<tseng> just cautious pessimis :P
<tseng> er, cant spell either.
<mdke> pessimism eh
<mdke> fairly healthy
<mdke> but no fun!
<mdke> she is online right now if you wanna ping her and ask
<mako> mdz: kassetra was writing it up.. she was not finished last i checked.. although that have been nearly one week ago
<bronson_> Anyone know why I can't get ddd to work on Hoary?  It's complaining about a missing elf/start.S.
<bronson_> I have libc6-dbg installed.
<bronson_> Where on earth would I find elf/start.S?  packages.ubuntu.com list nothing.
<Mithrandir> bronson_: it sounds like a part of the gcc or binutils source
<jbailey> sladen: ping?
<Mithrandir> bronson_: hm, no, wrong.  Unsure, then.
<Mithrandir> glibc source, perhaps?
<jbailey> Mithrandir: hmm>
<jbailey> ?
<Mithrandir> jbailey: 22:21 < bronson_> Where on earth would I find elf/start.S?  packages.ubuntu.com list nothing.
<jbailey> Yes, that sounds right.
<jbailey> The elf loads is in glibc.
<Mithrandir> it's discussed on libc-alpha at least.
<jbailey> bronson_: For which arch?
<bronson_> jbailey: i386
<jbailey> You'll find it in sysdeps/i386/elf/start.S in the glibc sources.
<sladen> jbailey: pong, though I'm in the middle of a router upgrade
<bronson_> I'm just trying to use ddd to debug a simple C app.
<bronson_> DDD complains of a missing elf/start.S and refuses to work.
<jbailey> sladen: No rush.  I added the hookscripts to the initramfs last night, wanted to make sure they were adequate for bootsplash (splashy, usplash, etc...) needs.
<jbailey> What's DD?
<jbailey> D
<bronson_> I think it's because Ubuntu's libc isn't stripped.
<bronson_> data display debugger.  front-end for gdb.
<bronson_> I just tried running gdb by hand and it's complaining of the same thing.
<bronson_> This has got to be a pretty common problem, hasn't it...?
<bronson_> Does anybody use GDB on Hoary?
<sladen> jbailey: groovy.  I'll ping you in due course, what's the package called?
<jbailey> sladen: initramfs-tools
<jbailey> sladen: It's still evolving, but if there's anything I can do to make it so that you can use this as a testbed now, I'd love to hear it.
<Mithrandir> bronson_: I've done that without any problems, yes.
<bronson_> Mithrandir: you haven't seen any complaints about missing start.S?
<bronson_> Weird.  I must be missing some package but I sure can't figure out which one.
<Mithrandir> bronson_: nope, can't remember it, at least.
<bronson_> Mithrandir: what libc do you have installed?  libc6-i686?
<Mithrandir> bronson_: yes, apparently.  And libc6-dev, but not -dbg.
<bronson_> Arg.  Well, short of downloading a ton of source packages and scanning them by hand, I think I'm stuck.
<bronson_> Bogus.
<bronson_> Mithrandir: libc6-686 version 2.3.2.ds1-20ubuntu13?
<Mithrandir> have you tried just setting a breakpoint and doing run?
<bronson_> yep.
<Mithrandir> bronson_: this box is running breezy, so I'm not sure what version I used back then
<bronson_> ah.  I look forward to upgrading.  I tried Breezy last week and paid the price.
<bronson_> Problem with setting a breakpoint is that a routine in start.S is at the top of the stack so every time gdb does anything, it complains that it can't find the source.
<bronson_> really irritating.
<Mithrandir> hm, weird.
<bronson_> I give up.  If printf logging won't do it, I'll just use gdb on a Fedora box for now.
<lifeless> mdz: ok, then thats probably the sanity checks. check squid.log, there should be a reason logged, also 2.5.10 is out now I think, and relaxes some of the constraints, (ie. double content-length headers are allowed IFF they have the same value)
<lifeless> ddaa: found a bug in svn, it doesn't call 'update' on syncs ;)
<ddaa> that might explain some things :)
<ddaa> lifeless: https://macquarie.warthogs.hbd.com/hoover/status/gsl-main/events/40/log
<lifeless> yes
<lifeless> found it yesterday nightr
<lifeless> just before bed
<ddaa> I'm zeroing on the remaining "missing =" problem
<ddaa> it's turning out scary
<ddaa> also see https://macquarie.warthogs.hbd.com/hoover/status/ijs-main/events/15/log
<ddaa> hu... ECHAN
<mdz> lifeless: 2005/06/12 17:21:14| WARNING: found two conflicting content-length headers in
<mdz> interesting
<mdz> and it's correct; there are two conflicting content-length headers
<lifeless> mdz: in which case there is no concievable way to determine which is correct.
<lifeless> guess that a following response after the shorter just means that the next pipelined request may be hacked.
<lifeless> guess the other, and the connection may hang while you wait for data that never arrives, or swallow up a real following response.
<lifeless> and thus corrupting the third request in a row
<mdz> hmm, discover1 is missing from breezy-live-amd64.iso
<mdz> daniels: it's not obsolete yet, is it?
#ubuntu-devel 2005-06-21
<tseng> is there an example of a main promotion document already done?
<tseng> i dont see the mono one on the wiki in the obvious place
<mxpxpod> thom: ping
<thom> mxpxpod: you always manage to ping when i'm either asleep or going to bed :-)
<mxpxpod> thom: hah
<mxpxpod> thom: just wondering how gnome-power is coming along on breezy
<mxpxpod> thom: because the latest release of pbbuttonsd sucks hard
<thom> mxpxpod: -> ogra
<mxpxpod> thom: is he taking care of pm now?
<tseng> https://www.ubuntulinux.org/wiki/MainInclusionReportGtkSharp
<tseng> is this acceptable?
<thom> he is doing the ui based stuffs, yes
<mxpxpod> thom: oh, I'm talking about backend stuff
<thom> gnome-power == ui
<thom> fundamentally
<mxpxpod> thom: right, I mis-spoke... I meant pmi
<thom> i'm not involved in that at all
<mxpxpod> stink
<thom> mxpxpod: you want to speak to ogra. really
<mxpxpod> and he's not around... ok
<mxpxpod> I'll have to email him or catch him on irc
<lamont__> thom: you around?
* jdub sends hugs to jordi 
<jdub> "Recently former founder of Gentoo Linux, Daniel Robbins, has managed to procure employment with Microsoft. Robbins describes his position as "helping Microsoft to understand Open Source and community-based projects."
<jdub> elite!
<wm_eddie_> cool
<wm_eddie_> jdub, I have a question with the bounties on the Ubuntu wiki.
<tritium> jdub, he's in #ubuntu right now
<wm_eddie_> when it says People: MichaelVogtLead, JeffWaughSecond what's that mean?
<zul> jdub: bah...traitor :)
<HrdwrBoB> jdub: sounds good, but he's still the founder, he's not the 'former founder' :)
<LinuxJones> jdub, he's in #ubuntu right now chatting
<mdz> wm_eddie_: it's a funny way of making it easy to search for the people responsible for a spec
<jdub> wm_eddie_: those are the people who wrote the spec
<wm_eddie_> oh ok.
<wm_eddie_> I've been messing with the FindingPackages bounty.
<lifeless> anyone got a list of the source packages in main? or a trivial way to make one ?
<jdub> tritium: weird
<wm_eddie_> I'm going to apply for it.
<zul> lovely..#ubuntu has changed into #gentoo-love
<wm_eddie_> he
<wm_eddie_> h
<lamont__> lifeless: zcat Sources.gz | awk '/Package:/ {print $2}'
<lamont__> lifeless: alternatively, the germinate output includes all of them...
<lifeless> thanks
<lamont__> lifeless: sorry I didn't have a list handy. :-(
* lamont__ heads for home
<Burgundavia> gnome upstream people, any thoughts on this? --> http://www.ubuntuforums.org/showthread.php?t=41530
<KaiL> .o0(and I thought, only Mozilla patches get old before somebody finds them)
<lamont> In file included from t_main.c:18:
<lamont> /usr/include/tcl8.4/tk.h:96:23: error: X11/Xlib.h: No such file or directory
<lamont> hrm... tk8.4, or puredata... wonder who's to blame
<tseng> lamont: that happens to several packages, daniels swears its NOTOURBUG
<lamont> tseng: no.  it's NOTANXBUG
<tseng> hah.
<lamont> er, NOT_AN_X_BUG, not NO_TANX_BUG :-)
<lamont> and to be fair, the apps that are failing are in violation of a 10-year-old spec
<tseng> ill have to get a proper fix from him
<tseng> in beagle we added the gross CFLAGS="-I/blah" hack
<tseng> in configure.in
<lamont> well, in this case, it's probably tk8.4 not including -I/usr/X11R6/include in the flags to pkgconfig, or possibly puredata not asking for the list
* lamont has 125 failures in his mailbox that match: 'X11.*No such file' in the body
<tseng> gross :(
<lamont> how dare thom be asleep now. :-(
<lifeless> oh wow 
<lifeless> tk comes up again ;)
<lifeless> tseng: so did we get that 8.3 config.sh fix backported ?
<tseng> lifeless: i had nothing to do with anything tk besides giving daniels a hard time
<lifeless> uhm, must have been infinity I was talking with a week or so back, about the broken gnu-smalltalk build
<lifeless> because /usr/lib/tk8.3/tkConfig.sh exported a CFLAGS value of "# no special flags needed"
<lifeless> which is so NOT WHAT YOU GIVE gcc.
<Lathiat> lifeless: haha
<infinity> lifeless : You just can't let it go, can you? :)
<daniels> mdz: not yet, but I could make it so
<mdz> I wonder how it went missing
<calc> do the ati xpress 200m based laptops work with xorg?
<calc> or ati's binary driver?
<calc> i'm helping my supervisor find a replacement laptop for his old p3 system
<lifeless> infinity: no, I can't, I want that fixed in hoary ;)
<lifeless> infinity: mmmm, reminds me, did the fix bubble through to sarge in time ?
<calc> bestbuy seems to have a pretty good one for $900 athlon64 3200, 80gb, 512mb, dvd-rw, 54g, etc
<eruin> wth
<eruin> wonder if they ship internationally
<Lathiat> wtf thats a nice price
<eruin> $900 is nothing
<Lathiat> theyre $2k aud here
<eruin> I hopethe dollar stays low until I'm buying my new lappy ;)
<eruin> x200 doesn't quite justify the a64 though
<wm_eddie_> Man, that feature freeze date is not cool...
<calc> yea ati 200 integrated is probably slow
<calc> http://www.bestbuy.com/site/olspage.jsp?skuId=7125327&type=product&id=1109937811956 <- url 
<eruin> the apples on that site are dead cheap :O
<eruin> " Built-in 54g high-speed wireless LAN with 125HSM/ SpeedBooster support (802.11b/g); 10/100Base-T Ethernet (RJ-45 connector)"
<eruin> lots of text and no info :>
<eruin> I wonder if they would ship without the microsoft suite
<dmb> hey, is it me, or are the faqs broken?
<calc> apples cheap? where?
<infinity> lifeless : Didn't I make that fix like 3 days before Sarge released?  (in other words, no the fix isn't in sarge)
<daniels> calc: the ibooks are actually very, very competitive with similarly-specced x86 laptops (arguably slightly cheaper)
<Lathiat> esp at edu prices
<HrdwrBoB> in terms of value for money, they are cheaper
<lifeless> infinity: yeah, somethink like that ;|
<lifeless> the ibooks price is sweet
<daniels> right.  a slow, shoddily-constructed dell, or a slowish, reasonably-well-constructed, ibook.
<Lathiat> the ibooks have had their issues
<lifeless> daniels: bah. samsung q30, makes them all envious
<Lathiat> back in the g3 era theyhad countless issues with dying logic boards
<daniels> Lathiat: true
<daniels> lifeless: not in terms of price
<calc> daniels: weight wise i suppose that is true
<Lathiat> i know at least 5-10 ibook owners, and everyoneof them except 1 has had at least 1 ifnot 5 logic board replacements,includinga couple g4s
<lifeless> daniels: true. it jumped 400 after I bought it ;)
<calc> daniels: though on the pc side you can trade weight for much faster systems
<lifeless> daniels: btw, the q30 is /not slow/
<lifeless> its faster than desktops in many ways, just don't mention the video card
<maswan> lifeless: what kind of battery time do you get in the q30?
<lifeless> 2 hours on the 3-cell, 4 on the 6-cell
<lifeless> 6 total, doing pretty much anything. haven't seen any difference doing lp development / baz/ email etc
<lifeless> maswan: (note that I have a dell X1, which is a q30 + bluetooth)
<Lathiat> i get 5.5h out of my dell
<Lathiat> if i push it
<Lathiat> 3-4 average
<Lathiat> 15.4" p-m 2ghz with an nvidia
<lifeless> Lathiat: how many K is your battery ?
<Lathiat> 5.5 is with wireless too
<Lathiat> lifeless: ~75
<Lathiat> design capacity:         71590 mWh
<lifeless> design capacity:         4800 mAh
<lifeless> thats the 6-cell
<Lathiat> whats your voltage?
<Lathiat> mine wouldbe ~6500mAh
<lifeless> design voltage:          11100 mV
<Lathiat> minesan 8 celli think
<Lathiat> yeh same voltageasmine
<Lathiat> and 4800*(8/6)is6400
<lifeless> I don't have a mWh rating
<Lathiat> so tahts about right
<Lathiat> lifeless: ~54000
<wm_eddie_> man, I'm really confused about the Spec...
* lamont looks around for anyone who actually understands ssl certs
<daniels> lamont: thom :)
<lamont> daniels: yeah, I know that.
<lamont> but I don't want to wait 6 hours.
<bob2> you should call him!
<mdz> daniels: how soon can you land the xserver-xorg.config changes for LTSP/casper?
* lamont gets racoon auth working, through the simple technique of saying 'verify_cert off;' :-(
<lamont> so, I know that much works... now I just gotta make it like the CA cert
<daniels> mdz: with the next upload, which is either today or tomorrow; whenever it is that I unbreak locales in libX11
<mdz> ok
<daniels> mdz: but if it's urgent, I can just drop it now and screw everyone who C isn't an appropriate locale for :)
<mdz> no, I can keep busy with UbuntuExpress for a few more days
<daniels> swoit
* lamont does the happy dance
<lamont> and no, I don't want to explain what it was
<daniels> lamont: but you'll have to, now that you've said that
<lamont> well, it said it wanted the ca_cert... that needs to be ROOT and sub-CA cert, it turns out... :-)
<daniels> heh
<daniels> oh my christ, this grep bug really *is* bad
<daniels> (he says, grepping over 181 files with an 887-line exclude pattern)
<lamont> daniels: what'd you do now???
<daniels> lamont: there's a bug in grep with UTF-8 locales where it takes an exhorbitant amount of time to grep files
<lamont> ouch
<daniels> lamont: there's a bug in grep with UTF-8 locales where it takes an exhorbitant amount of time to grep files
<daniels> oops, wrong window for up-enter
* lamont discovers that neither AH nor ESP packets in transport mode cause the unencapsulated packet to go through either INPUT or OUTPUT chains... hrmpf
<Amaranth> daniels: fedora has a fix for this
<daniels> Amaranth: so do I, it's called LC_ALL=C
<Amaranth> daniels: It's been sitting in the bugzilla or whatever for grep since march, iirc.
<Amaranth> daniels: some people grep non-english things
<daniels> yeah, well none of the filenames installed by xorg are !ASCII, so I'm sweet
<fabbione> morning
<jdub> daniels: do we have any problems with intel 915GM Express video chipsets?
<daniels> jdub: laptop, no.  desktop, some (which can be fixed by XORG_SYNC_RANGES=yes sudo dpkg-reconfigure -phigh xserver-xorg, and will be fixed in a hoary update and breezy update)
<jdub> ok, ta
<Amaranth> wtf
<Amaranth> qt4 can have images in text boxes?
<daniels> Amaranth: yeah, sounds about right
<Amaranth> sounds like crack :)
<daniels> Amaranth: probably using the QRichText equivalent (hopefully they rewrote its layout engine though)
<Amaranth> a text widget that does images and tables, whee
<daniels> rich text widget
<Amaranth> i certainly hope it isn't the regular text widget
<daniels> probably has a mode for selecting rich or plaintext
<daniels> yep, looks like it
<daniels> http://doc.trolltech.com/4.0/qtextedit.html
<bob2> maybe they can use it to replace khtml
<Amaranth> ha
<Amaranth> khtml is actually pretty cool
<daniels> it's the best lightweight free renderer
<pitti> Good Morning
<Keybuk> what's so good about it? :)
<pitti> Keybuk: it's still early, all of my flat mates and my gf are still sleeping, and finally the summer seems to have arrived :-)
<Keybuk> heh
<pitti> Keybuk: btw, yay for the new dpkg features
<Keybuk> which ones did you like?
<pitti> Keybuk: in particular the direct support for separate patches
<bob2> I liked that you fixed my bug
<Keybuk> still need to get dpkg-source -b (or equivalent) support into each
<pitti> Keybuk: I came across so many different (and so many broken) patch systems that I really hope that this will unify packaging
<daniels> i liked the ones that broke everyone's bulids
<pitti> hehe
<pitti> daniels: he warned us :-)
<infinity> Well, so much for waffling.  I just ordered my new T43.
<infinity> I can actually hear my bank account screaming from here.
<daniels> infinity: it's screaming for an X40
<infinity> Pff.
<infinity> You and your crazy cult.
<daniels> infinity: one of us ... one of us ... one of us ...
* daniels wonders why GOP is on the first page of hits for "one of us".
<infinity> If they're putting Lenovo logos on these instead of IBM logos, I'm going to be miffed.
<bob2> hm
<bob2> that would be significantly less leet
<daniels> ah, Grand Old Party
<robitaille> anyone knows the story about the us ubuntu mirror problems?  I see at least 7 bug reports open in the bugzilla about md5sum mismatch due to that mirror. Obviously it's affecting quite a few users.
* daniels wanders off to pick his little sister up.
<Keybuk> infinity: they've changed the Thinkpad TV adverts here now
<Keybuk> they seem to be just advertising "Thinkpad" as a branch (with a tiny "Product of Lenovo" comment)
<Keybuk> so I guess they'll replace the IBM logo with a Thinkpad loogo
<bob2> robitaille: the mirror's screwed
<bob2> the admins have been notified
<bob2> etc
<Keybuk> uh s/branch/brand/, heh
<daniels> Keybuk: yeah, we're getting the THINKPAD (product of lenovo) thing too
<Nafallo> yay!
* Nafallo just posted his first blog! http://www.livejournal.com/~nafallo/ :-)
<Nafallo> morning all btw! :-)
<Treenaks> hey naf
<infinity> Hrm, that talk of caffiened reminds me that if I want to get any work done this evening, I should go buy a bottle or three of Coke.
<Nafallo> infinity: hehe, pills are quicker :-)
<infinity> Less tasty.
* Treenaks votes for the iv
<Nafallo> indeed :-).
<Nafallo> hmm, are there any info on what goes on p.u.c? I might aswell try to get it syndicated there :-).
<daniels> infinity: bring me some iced tea
<Nafallo> the blog is probably going to be rather ubuntu-centric :-).
<Nafallo> but then again... seems I have to be a member, and I can't be that before 22:th of July anyway ;-).
<Nafallo> well now, shower.. later all :-).
<Keybuk> heh
<Keybuk> dilinger: nice debian-devel post
<pitti> hm, is it true that "eric" is obsolete and "eric3" supersedes it?
<fabbione> pitti: https://bugzilla.ubuntu.com/attachment.cgi?id=2739&action=view
<fabbione> pitti: do you have any idea what hald is trying to do?
<fabbione> (11824)
<pitti> fabbione: gulp
<fabbione> i blame binary modules..
<fabbione> but he claims he can't remove the nvidia
<fabbione> that i somehow exclude given that it was working with the old kernel
<fabbione> but the vmware modules are way more intrusive
<fabbione> and they might infact exploit the mm fix we introduced 
<fabbione> in order to work properly
<pitti> fabbione: that's a security update, and not even an ABI changing one...
<fabbione> pitti: exactly
<pitti> fabbione: ah, the "start > end" mmap fix?
<fabbione> pitti: probably
<pitti> there really is a valid use case for that? tsk
<pitti> fabbione: vmware needs kernel modules?
<fabbione> pitti: yes it does to emulate the hardware to the client
<pitti> it seems as if the guy is doomed...
<pitti> fabbione: however, it doesn't seem to be hal specifi
<pitti> c
<fabbione> pitti: it is clearly not hald related :)
<HrdwrBoB> similar to the way kqemu speeds up qemu orders of magnitude
<pitti> fabbione: it seems that hal crashed while trying to read sysfs
<fabbione> hey sabdfl 
<pitti> Hi sabdfl 
<sabdfl> mornin'
<fabbione> pitti: that shouldn't cause a schedule in atomic
<fabbione> pitti: an error of that kind shows up when you access a portion of the memory allocated as G_ATOMIC and request an irq to be scheduled
<fabbione> pitti: it's easy to fix.. if i can get to know what is causing it
<fabbione> s/G//
<pitti> fabbione: hm, we need a hal backtrace for that to find out the original call
<fabbione> pitti: i am still 100% sure it's a vmware fault...
<fabbione> i mean everybody is running hald out there
<fabbione> we would have noticed it way before that
<pitti> fabbione: well, I can look for all poll() calls, but there are certainly a few
<pitti> yes, and many people run the new hoary kernel
<fabbione> exactly
<pitti> he should try without vmware first IMHO
<fabbione> pitti: i did ask for that
<pitti> yes, he didn't reply to that
<pitti> Hi seb128, what's up?
<seb128> hey pitti 
<seb128> not a lot of new, got a sort of flue ... not my day
<seb128> and you?
<pitti> pretty fine, doing some python again (langpack-o-matic) :-)
<seb128> s/flue/flue/
<seb128> ups
<seb128> s/e//
<pitti> not really your day :-)
<seb128> see :p
<pitti> seb128: then don't work for > 12 hours today
<seb128> I've not planned to :)
<siretart> hi folks
<seb128> (I already took some extra sleep this morning)
<seb128> pitti: have you found why gnome-panel has no translations with the new language-packs?
<pitti> seb128: I stared at the logs, code, and tried to reproduce that without success
<siretart> is there some issue with http://packages.ubuntu.com? I see some packages in breezy are newer than in on p.u.c
<pitti> seb128: I uploaded a version with more debugging output yesterday
<seb128> k
<pitti> seb128: as soon as the next package has that symptom, I hope to learn more from the logs
<seb128> should I upload a new panel?
<pitti> seb128: if you have some fixes? new uploads have a high chance of good translation tarballs, and with the new cdbs we will get a POT anyway
<pitti> seb128: the problem only occurs if we have neither a pot nor stripped mo files
<seb128> k
<sivang> morning all
<pitti> Hi sivang 
<mjg59> sabdfl: Oh, you're doing a talk in Cambridge?
<mjg59> Enjoy the management students :)
<Treenaks> mjg59: http://www.lugradio.org/live/2005/
<mjg59> Treenaks: No, not that one
<mjg59> (That's in Wolverhampton, which is a far more miserable place)
<Treenaks> mjg59: yes, it's almost impossible to get there
<bob2> feature, not a bug?
<Treenaks> bob2: good point
<sivang> pitti: hey martin
<{Seb}> seb128: sorry about the bug
<seb128> which one?
<{Seb}> seb128: the one i filled today about the Run Application...
<{Seb}> seb128: it would make sense to have it in the System menu
<{Seb}> seb128: after reading the GNOME Bugzilla
<seb128> there is a discussion about that on the -desktop list IIRC
<seb128> I'll ask upstream 
<{Seb}> right
<seb128> but is that really useful? You have alt-F2
<{Seb}> i should really get more involved with gnome/ubuntu ;-)
<{Seb}> i have just started to use Alt-F2
<{Seb}> but my Mum uses Ubuntu Hoary on her laptop
<{Seb}> then when she uses my machine with Breezy, she goes and find it ain't there!
<{Seb}> just have to get used to it
<seb128> right, changing existant feature is not nice
<{Seb}> btw, i am getting a few Segmentation Faults on Breezy
<{Seb}> gFTP and Synaptic both produce them
<{Seb}> while running
<{Seb}> is there any way of debugging them
<{Seb}> because if i run them from terminal, it just says 'Segmentation Fault'
<seb128> gdm
<seb128> ups
<seb128> gdb
<{Seb}> what?
<seb128> gdb gftp
<{Seb}> right
<seb128> (gdb) run
<mvo> {Seb}: if you can reproduce them run gdb (as seb said)
<seb128> ... crash
<seb128> (gdb) bt
<{Seb}> lol, i'll give it a go
<seb128> what's funy?
<mvo> {Seb}: can you reproduce the synaptic segfaults? what distro? breezy? hoary?
<seb128> hey mvo :)
<{Seb}> breezy
<mvo> hey seb128 
<{Seb}> just mbo said seb and i'm also called seb!
<{Seb}> doesn't matter ;-)
<{Seb}> when i run 'gdb gftp' i get this error:
<{Seb}> "/usr/bin/gftp": not in executable format: File format not recognized
<seb128> gdb gftp-gtk
<{Seb}> k
<{Seb}> sorry, but it still won't work
<{Seb}> i ran gdb gftp-gtk
<{Seb}> and then ran 'run' from the (gdb) prompt
<{Seb}> and it is trying to connect to a site called gftp-gtk
<seb128> ??
<{Seb}> i'll try synaptic
<siretart> I'm currently reviewing tla-load-dirs, a package from universe, automatically merged by mom.
<siretart> what is your opinion, should the maintainer in the merged changlog from MOM be changed from scott to the reviewer?
<thom> siretart: most people leave it as scott if they make no changes
<infinity> Which no doubt gives Scott many giggles.
<infinity> siretart : I always change it to my name purely to provide a simple audit trail, so fellow developers can smack me around for having not merged correctly or ask me why I let change A or B in, or whatever.
<siretart> infinity: sounds reasonable. will follow that
<jsgotangco> bye bye
<infinity> siretart : Looking for a name in the changelog is much simpler than finding the .changes on the list and checking the GPG sig to see who uploaded, basically.
<seb128> is hct supposed to work atm?
<pitti> seb128: well, for some hoary packages it does
<seb128> pitti: hum, I get "The exception had the value: (111, 'Connection refused')" when I try to source something
<sabdfl> mjg59: i'm considering giving them a walkthrough of the component architecture in zope3 as used by Launchpad
<pitti> seb128: hm, right, I get the same
<pitti> seb128: IIRC the lunchpad guys do some new rollout ATM
<seb128> pitti: k, so that's not me (not me day :p)
<seb128> s/me/my/
<{Seb1> btw, when is there a version freeze on breezy?
<seb128> you can find the schedule on the wiki
<mjg59> sabdfl: At JIMS? Haha
<{Seb1> thanks
<sabdfl> mjg59: those bus students deserve a little rollercoaster ride :-)
<Nafallo> pitti: I take care of ethereal. tseng informed me about what to do with it :-).
<mjg59> It's in the middle of May Week, so your chances of finding sober students are... slim
<sabdfl> hmm... maybe i should read Mithrandir's paper on bi-arch and present that instead
<sabdfl> May Week is in June?
<mjg59> Yes
<{Seb1> btw, is smeg going to be the offical menu editor in breezy?
<Nafallo> pitti: any news on that cryptsetup bug I found?
<mjg59> (It used to be in May, but then got moved to after exams)
<Nafallo> mjg59: I love your blog! :-)
<pitti> Nafallo: no, sorry, no time yet...
<Nafallo> pitti: oki. no rush.
<{Seb1> sorry to be a bother
<{Seb1> irrc, hoary had like Array-1 to Array-7
<{Seb1> will this happen with Breezy
<{Seb1> or are they called Collony-1
<{Seb1> etc...
<infinity> Yes.
<Nafallo> mjg59: btw, suspend hates me. hibernate works with lan and wlan in MODULES="" @ Targa Visionary 811
<{Seb1> Yes?
<infinity> {Seb1 : Yes, they're called "Colony-X".
<{Seb1> instead of Array?
<Lathiat> yes
<{Seb1> got it
<mjg59> Nafallo: Could you file a bug, including the output of lsmod?
<{Seb1> just out of interest, when will Colony 2 come along?
<{Seb1> breezy is looking very very good
<{Seb1> it is usable now imho!
<mvo> {Seb1: did you manage to produce a backtrace from your synaptic crash?
<{Seb1> nope, i couldn't get it to go it!
<seb128> {Seb1: all that informations are on the wiki
<{Seb1> sods law ain't it
<Nafallo> mjg59: or rather suspend works, but doesn't turn on the backlight on the screen. I should probably try to ping the damn thing to see if it's alive :-).
<Nafallo> mjg59: sure. against acpi-support?
<{Seb1> seb128: i'm looking http://www.ubuntulinux.org/wiki/BreezyBadger and can't stuff like that
<mjg59> Nafallo: Sure
<{Seb1> glad mono is now in main
<mjg59> {Seb1: We'll see how long that lasts...
<{Seb1> why? i thought mono was there for sure
<{Seb1> as Beagle is going to be an essential part of Breezy
<mjg59> There are patent issues. It's not clear how MS is going to deal with them.
<{Seb1> i thought miguel sorted that one out a while ago
<mjg59> No, Miguel said that they had to be licensed under RAND terms
<mjg59> Which MS are free to charge money for
<AndyFitz> mjg,  last time I spoke to a MS man concerned with those issues  he tried to push the fud onto novells hands 
<{Seb1> right
<mjg59> Now, it's entirely possible that MS will grant a free patent license. But they haven't publically committed to that.
<mjg59> And it's probably going to take some community pressure to get any sort of statement of intent out of them
<{Seb1> it seems kind of wrong that a free project is asking MS for a favour
<mjg59> They own the patents...
<mjg59> The alternative is to get software patents overturned in the US
<{Seb1> how do you mean 'overturned'?
<mjg59> The idea that software should be patentable
<mjg59> It's not universal
<{Seb1> now, in europe, software is not allowed to be patentable yet?
<{Seb1> but it could be soon
<mjg59> Correct
<{Seb1> btw, does the French and Dutch vote of No have any consequences on this
<{Seb1> i'm in the UK
<mjg59> Nope
<mjg59> It's independent of the EU constitution
<{Seb1> right
<mjg59> (Other than that they now have other things to worry about, so patents may be on hold for a short while)
<Nafallo> mjg59: bug# 11832
<{Seb1> mjh59: that's the spirit
<mjg59> Nafallo: Can you add lsmod?
<{Seb1> mjh59: does this mean the foss will be limited if patients come into force in europe?
<Nafallo> mjg59: sure
<mjg59> {Seb1: It could do. The long term consequences aren't clear.
<{Seb1> these bureaucrats!
<mjg59> Nafallo: Hmm. You shouldn't need to rmmod and modprobe by hand. They ought to be automatically picked up.
<mjg59> I'll look into that
<Nafallo> mjg59: /etc/default/acpi-support as well? :-)
<mjg59> Please
<Nafallo> mjg59: done :-)
<mjg59> Ta
<Nafallo> ey ogra! :-) how's life?
<sivang> hey ogra , 'sup?
<pitti> moin ogra
<{Seb1> weird!
<ogra> hi all :)
<{Seb1> has anyone used sound juicer successfully on breezy?
<{Seb1> hey ogra
<{Seb1> it seems to be putting a whole cd into one track
<pitti> {Seb1: please file a bug about this, or look whether there already is one :-)
<{Seb1> gnome or ubuntu bugzilla?
<Lathiat> {Seb1: thats a know gstreamer issue i think
<Lathiat> someone mentioned it earlier
<{Seb1> i've installed grip
<{Seb1> and see if that is any better
<Lathiat> wellthat doesnt use gstreamer
<Lathiat> soassumedly it should work
<{Seb1> yeh it is
<Lathiat> no its not n
<Riddell> how does gnome-volume-manager get started?
<Lathiat> Riddell: gnome-session assumedly
<{Seb1> by gnome-session?
<Riddell> is that a shell script?
<{Seb1> think it could be hard-coded in
<Lathiat> Riddell: no
<{Seb1> Lathiat: is it hard coded?
<Lathiat> Riddell: its a fairly key compoennt of gnome written in c :)
<Lathiat> {Seb1: no
<{Seb1> i am wrong (as usual)
<seb128> {Seb1: the sj bug is gst-plugins0.8 one fixed with an upload yesterday which has not built yet
<Lathiat> its started by gnome-session, but afaik its in gconf or something
<seb128> no
<{Seb1> seb128: will it be in breezy-annouce when it is built and uploaded?
<seb128> it's listed by the default session: /usr/share/gnome/default.session
<Lathiat> "or something" :)
<Lathiat> thanks seb128 
<seb128> {Seb1: what is -announce?
<{Seb1> whoops!
<{Seb1> breezy-changes
<Lathiat> man
<{Seb1> i meant
<Lathiat> dude
<Lathiat> the { in yournick is annoying
<{Seb1> mine?
<Lathiat> i keep thinking theres irc lines are unterminated :)
<{Seb1> it is meant to {Seb}
<{Seb1> as Seb is already taken
<Lathiat> "Shouldn't there bea closng }on thatline
<Nafallo> Lathiat: lol! :-)
<{Seb1> it is meant to be
<Lathiat> Nafallo: im seriouslol
<{Seb1> but Gaim is being stupid
<{Seb1> sorry Lathiat!
<{Seb1> didn't meant to offend you
<Lathiat> spot the programmer
<{Seb1> i'm gonna log out and in again
<Nafallo> Lathiat: I agree without being a programmer (yet) :-)
<{SebPayne}> oh bollox
<{SebPayne}> it still won't go to {Seb}
<{SebPayne}> it says the nick already exists
<{SebPayne}> is there a way of killing it
<{SebPayne}> i registered it with FreeNode but Gaim obviously hasn't logged off
<Lathiat> is thenick registered?
<pitti> {SebPayne}: is it from you, from a crashed session?
<{SebPayne}> yep
<{SebPayne}> yep
<pitti> {SebPayne}: it will time out automatically
<{SebPayne}> iirc, there is a NickServ command
<infinity> If it's registered, just tell nickserv to punt it.
<Lathiat> . /msg nickserv ghost <nick> <pass>
<{SebPayne}> right
<{SebPayne}> i'll give it a go
<{Seb}> yeh!
<{Seb}> i should just stick to XChat
<{Seb}> what do people use around here for IRCing?
<Lathiat> irssi
<Nafallo> irssi from when I last logged in ;-)
<{Seb}> lol
<Nafallo> before that xchat
<Nafallo> and before that gaim
<pitti> btw, that's heavily OT for #u-d
<Nafallo> pitti: agreed :-)
<{Seb}> irssi?
<Nafallo> {Seb}: irc-clients if not discussion about the devel of them :-).
<{Seb}> lol. Ok Nafallo
<Nafallo> pitti: how should I test bugzilla on warty? :-)
<pitti> sudo dpkg -i bugzilla_*.deb?
<Nafallo> hmm. warty stuff on breezy? :-)
<pitti> that should work fine
<Nafallo> oki
<pitti> Nafallo: I have dchroots for that purpose, but usually you can test on breezy
<{Seb}> i found that irssi was installed automatically
<{Seb}> by Ubuntu!
<{Seb}> exit
<{Seb}> exit
<{Seb}> soryr
<{Seb}> *sorry
<pitti> {Seb}: /quit
<{Seb}> that's the one
<tseng> hi ogra 
<pitti> mvo: here?
<mvo> pitti: yes
<pitti> mvo: is python-apt able to use remote source urls?
<pitti> mvo: i. e. on rookery I don't want to use the local apt lists (which don't have breezy sources)
<pitti> mvo: but I want to download (urllib) the source list from archive.u.c or the local mirror
<ogra> hi tseng 
<mvo> pitti: apt (and python-apt) can do this with the Dir::Etc::sourcelist variable
<pitti> mvo: how do I do that with python-apt?
<pitti> sorry, but ENODOCS
<mvo> pitti: I know, one of the biggest problems with python-apt right now. give me a minute and I'll give you a example
<pitti> that'd rock
<pitti> mvo: I mean, it is easy to implement that stuff on my own, but IMHO it makes more sense to extend python-apt for common tasks
<sivang> mvo: you're the author for python-apt?
<mvo> sivang: no, but I work on it nowdays
<seb128> sivang: what's this list on the wiki?
<seb128> sivang: seems to be the 'about dialog', not the menus?
<sivang> seb128: I have taken the old list, since most of the stuff wrt which lib an app uses still relevant, I will have it finished by end of the week, talked with mdz about it last night
<seb128> I'm working on it atm ...
<sivang> seb128: I will modify it for the menu stuff, but after comparing with the new breezy seed list this most of it is relevant and serves as guideline for the reasearch work
<seb128> good to communicate when you talk with mdz about something assigned to somebody else
<sivang> seb128: sorry :-/
<seb128> np
<sivang> seb128: but acutally I have not managed to do too much on it,
<seb128> anyway the list is not revelent
<seb128> the menu and the about dialog are 2 different stuff
<sivang> seb128: so it's cool, just add a column that specifies the number of the method
<seb128> hum
<seb128> I would rather do a table listing the menu updating something not adapted
<seb128> ie: bug-buddy has not menu
<sivang> seb128: you mean to seperate all the apps that don't have a menu ?
<sivang> seb128: into another list?
<seb128> hum
<seb128> I mean do a table speaking about menus
<sivang> seb128: ah I see
<seb128> " bug-buddy
<seb128> 
<seb128> libgnomeui/(6)
<seb128> 
<seb128> Druid UI, uses an "About" button on first dialog , doesn't have a menu , must patch about box "
<seb128> how is that adapted to the current spec?
<sivang> seb128: well, the current spec didn't talk about apps that don't use a menu approachj at all, so I figured to be more inclusive
<seb128> this should be "has no menu"
<seb128> your previous work is on an another wiki page, so no dropped
<seb128> I would rather make a new table for menus on the current spec
<sivang> seb128: ok
<seb128> anyway what did you talk about with mdz? 
<sivang> seb128: so we will focus only on apps that have menus, and deal later with those that do not?
<seb128> right
<sivang> seb128: about that I want to adapt the list, but forget it, he was probably over busy to notice my blabber ;-)
<seb128> make a table package/way to build the menu
<seb128> I'll change the wiki
<sivang> seb128: and also about maybe pushing this to end of the week, but again, I am not sure to which extent he read me, and if youre' already into it then it's irrelevant
<sivang> seb128: cool with me
<sivang> seb128: sorry for the confusion I caused
<seb128> did you get a reply from mdz? or that's a one way talk from you with him?
<seb128> np
<sivang> seb128: ;-) Almost, but I did got a reply but as I said, if you're already working on it - then better not postpone this any further
<seb128> if mdz said that's ok to delay a few days that's fine, but I had the feeling that's not the case
<sivang> mdz: better talk to him directly
<sivang> mdz: I don't want to cause more confusion...
<seb128> ?
<seb128> I'll work a bit on this now
<sivang> seb128: ok
<sivang> seb128: all I say we better check with mdz about this again, when he wakes up
<sivang> seb128: regarding timeframe
<seb128> right
<Lathiat> Have I missed some kind of pam/ssh related DoS lately?
<Lathiat> i had some IP connecting at me making ssh log bad protocol and no id strings, and afterabout 14 hours ssh refused accepting connections
<tseng> er, there have been bruteforce worms for awhile now
<sivang> seb128: oops, just noticed I talked to mdz when I wanted to talk to you.bah
<seb128> np
<infinity> daniels : Package: libglu1-xorg / Provides: libglu1c2 / Replaces: libglu1c2, libglu1 / Conflicts: libglu1, libglu1 ....
<infinity> daniels : Missing a "c2" on that last Conflicts?
<infinity> daniels : And while I'm at it, if it's really your intention for GLU implementations to now provide libglu1c2 instead of libglu1, your shlibs should be updated.  It currently reads: "libGLU    1 libglu1-xorg | libglu1"
<daniels> infinity: RETURN OF CAPTAIN SKILL
<daniels> thanks for the catch
<mdke> .clones
<mdke> dammit
<mdke> wrong chan
<mdke> soz
<seb128> Keybuk: hey. "(111, 'Connection refused')" with hct is a known issue?
<infinity> daniels : Any uploads planned soonish?... If not, I'll fix those two issues and upload, since the broken shlibs is a bit viral.
<Keybuk> seb128: no ... ?
<seb128> Keybuk: I get that when try to hct source something
<seb128> s/try/trying/
<Keybuk> yup, looks like the server has gone away
<seb128> k
<daniels> infinity: 'as soon as I fix locales in libX11', which doesn't really have any definite timeframe.  feel free to fix those two and upload.
<Keybuk> can't see anything, have ping'd stub
<infinity> daniels : Alright, consider it done.  I need to hunt down anything with broken deps and rebuild them afterward.  Yay, shlibs.
<Keybuk> seb128: database update, will be down for a while
<daniels> thanks
<m0rphx> apropos X11, libxcursor1 is also broken
<daniels> m0rphx: how so?
<seb128> Keybuk: k, I'll try again later so, thanks
<seb128> Keybuk: and have you debuged gdm import?
<m0rphx> daniels: for example when you're trying to start firefox it says "XCursorCursorsDestroy" is undefined
<Keybuk> no, not yet
* Keybuk does it now
<daniels> m0rphx: 'whoops'.
<daniels> m0rphx: open /usr/lib/libXcursor.so.1 with vim, change XCursor to Xcursor
<daniels> my laptop must be interestingly broken
<m0rphx> daniels: wow, I love that quick feedback. thx
* daniels wonders where the duplicate libXcursor that actually works is on his filesystem.
<daniels> m0rphx: no worries
<seb128> hum
<seb128> "dpkg-source: error: unrecognised file suffix `.tar'"
<m0rphx> and while I am at it, where's the nice ubuntu branded xscreensaver? ^^
* seb128 kicks dpkg
<daniels> seb128: it's for your own good
<seb128> daniels: native Debian packages are forbidden from now? :)
<Keybuk> native packages with Debian revisions? :p
<seb128> Keybuk: right, but this package is already in the archive :p
<Keybuk> seb128: gdm worked today, I think it just got hit by the pybaz bug I fixed a while back
<seb128> cool, just to wait to get the server running again so
<Keybuk> yeh
<thom> GAR
* thom smites daniels
<thom> /usr/bin/../lib/libXcursor.so.1: undefined reference to `XCursorCursorsDestroy'
<thom> collect2: ld returned 1 exit status
<thom> (and yes, i saw the solution)
<Keybuk> yeah, these people who upload broken pages
<Keybuk> kill zem all
<Keybuk> "iz eeks bug"
<\sh> one theory in my past was: break gentoo thursdays and fork gentoo always on fridays
<\sh> but nowadays it's: break breezy every single day, and fork debian at last once in your life ;)
<daniels> yeah
<daniels> the solution here is don't copy shared libraries around
<daniels> that way, when you test something, it'll actually find the right library :P
<thom> bah, someone's broken zsh svn completion
<daniels> svn?  wassat?
<thom> one of those scm thingies
<thom> you know, like visual sourcesafe
* thom blames Clint entirely
<Clint> stop using broken scm thingies
* ogra hits lintian with a sledgehammer
<thom> Clint: basically, svn rm now only completes things that have already been deleted
<thom> which is not so helpful
<daniels> oh, vss!  i love that thing!
<Keybuk> daniels: see, libtool was right ;)
<ogra> could some native speaker give me an advise for a sane dscription text for ggradebook ? 
<ogra> Description: student grades tracking tool.
<ogra> seems not to work...
<ogra> at least for lintian
<daniels> Keybuk: having been outsmarted by libtool is possibly the ultimate shame I can endure
<daniels> far worse than even spraying a table in an Argentinian restaurant in Matar with beer
<Treenaks> you had beer in Matar? :)
<Clint> thom: that sounds like a brilliant change
<thom> Treenaks: yeah, he was just about old enough
<thom> Clint: it has some minor drawbacks, it seems ;-)
<Treenaks> thom: no I mean.. I can only remember sangria
<Clint> good thing i avoid using svn
<daniels> thom: s/just about //
<daniels> thom: make another age joke and I'll break your hip :P
<thom> *smirk*
<thom> you deserved that one
<infinity> ogra : "tool for tracking students' grades".  But I bet lintian is just complaining about the trailing "."
<ogra> i'll try....
<pitti> Hi lamont__ 
<doko> infinity: taking over xorg maintainance? ;-)
<ogra> (creating the package took me 2 min, making lintian happy about my Description takes 20 min... thats just silly)
<lamont__> g'morning
<thom> that's lintian
<ogra> hey lamont__ 
<daniels> doko: see above where I asked himt o upload it ;)
<tseng> pitti: do you have 2 minutes to check my email?
<pitti> tseng: sure?
* pitti syncs mail
<infinity> pitti : Oo, check my email too, I can't be bothered.  I'll send you my spool.
<tseng> pitti: just to make sure i did it right, i posted 2 reviews for main
<thom> lamont__: did you resolve whatever it was you were trying to disrupt my sleep for last night?
<pitti> tseng: ah, that one. sorry
<lamont__> thom: well, that part, yes.
<lamont__> thom: and I wasn't trying to disrupt your sleep, I was just grumbling that you were sleeping. :-)
* pitti alters his .procmailrc to defend against infinity spam
<lamont__> thom: if I wanted to disrupt your sleep, I believe I still have your phone numbers
<thom> lamont__: *g*
<thom> lamont__: trust me, you don't want to do that ;-)
<lamont__> thom: the final tidbit was that when you put toegether a CA cert, it needs to go clear back to the root cert. :-(
<Treenaks> lamont__: just mail the private part of the keys around
<lamont__> Treenaks: that's not my trick...
<Treenaks> lamont__: no, but you were asking the expert ;)
<lamont__> thom: klatu barata nicto
<ogra> infinity, thanks, removing the dot helped :)
<lamont__> ok.  maybe that was a bit obscure/skewed.
<pitti> tseng: point 5 is boilerplate, otherwise it looks fine
<thom> lamont__: uh?
<pitti> tseng: I'll take a look at the packages today and add my ack
<lamont__> thom: line from _the day the earth stood still_, spoken to Gort, causing him to not destroy the earth.
<AndyFitz> gksudo not working,   gdm not starting properly   and too many instances of X trying to be opened on the one display..  what happened with libxcursor
<lamont__> and somehow, the angry-thombot reminds me of Gort.....
<Nafallo> pitti: thanx :-)
<lamont__> klaatu barata nikto, actually
* Nafallo want mono-love ;-)
<bradb> hey dudes. malone usability question for you: when looking at a list of bugs, do you care who the submitter of the bug was?
<daniels> bradb: not usually
<daniels> assigned to is typically more helpful in this case
<pitti> not really
<pitti> yes, assignee is important, just like the lists in bz
<bradb> ok
<seb128> no
<thom> ah, heh
<tseng> pitti: thanks!
<thom> hrmph, having two instances of dhclient running is bad, mmmk?
<daniels> thom: yes
<pitti> thom: yes
<daniels> thom: it's up!  it's down!  it's up!  it's down!
<pitti> thom: intermediate dhclient3 versions had a bug
<pitti> thom: the latest breezy version should fix it
<Nafallo> thom: depends. is it on the same device it's bad :-)
<thom> (especially with different command line arguments and different leases files)
<thom> pitti: NM v ifupdown in this instance
<seb128> bradb: is there any way to get the bugs filled against <package> by mail?
<thom> D"wooops"
<seb128_> grumpf
<seb128_> bradb: have you replied to my question?
<daniels> seb128_: no
<seb128_> k
<seb128_> less than 3 weeks before switching to malone? :)
<infinity> daniels : D'oh.  I assume that xcursor upload that was 2 minutes before the xorg upload fixes the xorg-hates-xcursor FTBFS I just had? :)
* daniels giggles.
<daniels> infinity: how cool am I?
<AndyFitz> rock!
<AndyFitz> daniels.  10 points for the quick fix
* AndyFitz is listening to resin dogs - daily trouble  ...  and thinking of xorg hassles ;)
<bob2> haha
<bob2> they need to tour again
<AndyFitz> they never play here in brissie
<AndyFitz> hardly ever
<zul> uh wiki down/
<AndyFitz> no brissie bands play for us  unless its part of a national tour
<bob2> haha
<bob2> even down in the 'valley?
<AndyFitz> uh  once regurgitator threw a free gig in the valley on a random sunday
<bob2> haha
<AndyFitz> bob2,  thats where I live
<AndyFitz> all we get is butterfingers showing up to every on-the-spot set
<AndyFitz> yay for the 3 hour drive to splendour in the grass
<bob2> bah for selling out before I bought tickets
<AndyFitz> missed out on BDO due to that.   not this time
<AndyFitz> clearlooks-olive  in breezy is sexier than... many things
<bradb> seb128: sorry dude, alarm system guy showed up so i was away for 20 mins. no, the email UI doesn't have a query interface yet.
<seb128> bradb: query interface? No, I want get mails for bugs sent on my packages
<thom> clearlooks-olive? are you having a giraffe?
<bradb> seb128: oh, i interpreted your question to mean a query UI. the answer is: yes, since about 8 months ago. ;)
<seb128> bradb: how to I do?
<seb128> bradb: ie: I want to get the bug for gnome-panel and Cc: upstream by default
<AndyFitz> thom:  no,  pet-reptile permits are hard enough to get here in AU let alone wanting a whole giraffe
<AndyFitz> you need one of those to get a funky-turtle as I learnt on the weekend
<infinity> But you can get the non-funky kind without?
<bradb> seb128: one sec, i'm just looking at if we have a UI to set you as the maintainer of that package yet.
<AndyFitz> yeah , but who wants  a turtle without a mohawk
<thom> AndyFitz: do you have a dog license? and a goldfish license too?
<thom> oh, hurrah, we finally have working lighthouseblue again.
<AndyFitz> tropical or marine fish  don't require anything
<AndyFitz> I'll be right back x restart
<thom> AndyFitz: i was aiming for http://orangecow.org/pythonet/sketches/fish.htm
<zul> i love that sketch
<AndyFitz> zul,  nice one :)
<seb128> jamesh: http://udu.wiki.ubuntu.com/LaunchpadIntegration, I've listed some of the packages here ... gtkuimanager is used by most of the Desktop stuff
<bradb> seb128: it appears that we don't have a UI for setting the sp maintainer on things. (ISTR this has been a problem for a while now.) i'm filing the appropriate bugs and contacting the relevant people to see what we need to do here to make sure you are properly set as the maintainer where you want to be.
<seb128> bradb: thanks
<KaiL> something went wrong with the synaptic update?
<KaiL> ah, and there comes the fix :)
<bradb> seb128: so, according to debonzi (our soyuz/source packages guy) we'll be running a script next week that imports package release data, and you'll be correctly set as the maintainer of gnome-panel. that information will be grabbed from that archive at that time.
<mdz> morning
<tseng> morning mdz.
<pitti> Hi mdz 
<fabbione> morning mdz
<mvo> morning mdz 
<ogra> hey mdz
<zul> hi mdz
<doko> Mithrandir: please could you update the OOo2.amd64 packages? It's still the old snapshot, but is currently uninstallable. So, low priority.
<tseng> doko: the gnome guys were wondering why we didnt sync with michael meeks changes for awhile
<pitti> tseng: btw, we really need both gtk-sharp and gtk-sharp2?
<tseng> pitti: yes.
<tseng> pitti: different api
<doko> tseng: because we had to fix our build environment first ... working on it.
<tseng> doko: yay :)
<tseng> pitti: gtk-sharp wraps gtk 2.2 features, stable api
<pitti> tseng: what about the status of upstream/Debian/Malone bug reports?
<tseng> pitti: gtk-sharp2 wraps also 2.4 stuff, new api, allegedly unstable but it hasnt broken anything for months
<tseng> there are probably alot of open small bug reports upstream.. i dont have anything assigned in ubuntu space
<pitti> tseng: I'm asking because gtk-sharp2-unstable is also on the list
<tseng> ill search
<pitti> tseng: no, I'm just interested in open showstopper bugs
<pitti> tseng: and in particular how well they are handled
<pitti> tseng: but with -unstable we have three different versions in main...
<pitti> tseng: is -unstable still required?
<tseng> let me confirm which one is real
<tseng> what happened is a DD posted them and i synced
<tseng> they went into debian w/ a slightly different naming
<pitti> tseng: alright, I take a look at the debs now
<tseng> gtk-sharp2-unstable is the correct source
<tseng> whats the other one called again?
<tseng> we need to drop it
<pitti> gtk-sharp2?
<tseng> um
<tseng> i dont think there was a source package called that
<pitti> tseng: oh, gtk-sharp2 is the deb, -unstable the source
<tseng> yes
<pitti> tseng: so the report should be adopted
<tseng> should be a meta package
<pitti> alright
<tseng> but i cant remember what dajobe was calling it
<pitti> tseng: any reason why libvte-cil is not arch:all?
<pitti> tseng: same for libgconf-cil?
<Zomb> pitti: arch specific glue code, IIRC
<pitti> Zomb: not in these two pacakges AFAICS
<pitti> Zomb: that's true for e. g. libgtk-cil
<tseng> it all looks managed
<tseng> in gconf
<tseng> same for vte
<tseng> those should be fixed in debian and synced across if meebey doesnt have a good reason
<pitti> tseng: ok, it's no biggie, but it should be fixed
<tseng> yes i've pinged him
<bradb> another random malone usability question: what do you guys think of this style of listing? http://rt.cpan.org/NoAuth/Bugs.html?Dist=DBD-mysql.
<tseng> bradb: perhaps if the subitems were slightly indented
<pitti> bradb: I miss the assignee and the ID should be better separated from the description
<bradb> do you guys think that grouping by severity is effective?
<tseng> i think severity is usually set inappropriately at present
<tseng> some people think their bugs are "blockers" or "major"
<pitti> bradb: I think yes; it's up to the maintainer to adjust severity
<pitti> bradb: my own bz page is sorted by severity at least
<bradb> is grouping by severity a good thing or a bad thing?
<tseng> good.
<pitti> bradb: good
<bradb> is there something better to group by than that?
<pitti> bradb: however, it should be configurable in personal prefs
<bradb> pitti: good point
<pitti> bradb: sometimes I need to group chronologically, i. e. by descending bug id
<bradb> pitti: but grouping by severity by default...would that make you happy?
<pitti> bradb: everybody should set his personal preference, with chronological being a sane default IMHO
<pitti> bradb: as long as I can modify it, severity default would be fine for me
<pitti> bradb: bz does it nicely, you click on the colum header you want to sort it after
<bradb> that's one of the change i'm making to the current search page as we speak :)
<jbailey> bradb: I usually sort by most recently touched so that I can see if someone has replied to a bug or if a new one came in easily since I last checked.
<bradb> jbailey: so, let's say that, for 1.0, changing the default grouping as not an option. what grouping, sorting-within-grouping order would you want to see?
<pitti> tseng: similar case in -unstable: it might be best to inspect all packages whether they can be made arch:all
<tseng> pitti: *nod*
<mvo> elmo: can you sync balsa please? (override is ok)
<pitti> tseng: packages look fine to me
<jbailey> bradb: My biggest concern when I'm looking at the whole list of bugs is to find the ones that have had something change on them.
<tseng> thanks a lot pitti 
<tseng> will talk to meebey re: arch all
<tseng> vs any
<pitti> tseng: I update the report now and add my ack
<pitti> reports, even
<jbailey> bradb: I do that in bugzilla by sorting by last updated time, but it could easily be a flag or some other way to let me quickly see what's new.
<tseng> i guess i should mail to -devel now
<elmo> mvo: done
<mvo> elmo: thanks :)
<bradb> jbailey: i see what you mean. thanks, i'll ponder that while i'm modifying things on the page.
<elmo> has anyone see interdiff fail miserably with -p1 ?
<elmo> 1 out of 1 hunk FAILED -- saving rejects to file /tmp/interdiff-1.HYD4ix.rej
<elmo> interdiff: Error applying patch1 to reconstructed file
<elmo> like that?
<mdz> thom: what remains on the todo list before uploading NM to Breezy, and then before adding it to desktop?
<mdz> elmo: yeah, I have seen that happen once before
<pitti> tseng: https://www.ubuntulinux.org/wiki/MainInclusionReportGtkSharp
<pitti> tseng: ^ I made some adjustments
<mdz> eek, udu.wiki is giving 500 errors
<mdz> http://udu.wiki.ubuntu.com/GraphicalPartitioningTool
<thom> mdz: figuring out why it causes the ipw2100 driver to panic
<thom> mdz: besides that, i think it's ready to go, but i don't fancy doing so when it causes systems to die 
<KaiL> thom: Version 1.10 on Kernel 2.6.12rc? ;)
<thom> KaiL: probably so, yes
<fabbione> hey thom
<fabbione> hey elmo
<fabbione> elmo: can you please move redhat-cluster-suite (source) and libdlm1 (binary from rh-c-s) to main? the latter is required to build lvm2
<KaiL> saw the same on an ASus M2400N - works stable with hoary, crashes with breezy-Kernel (btw. only if it finds a Net!)
<mdz> thom: is there any way we can cripple it so that it doesn't poke that driver?  we need to start testing the rest of it ASAP
<thom> mdz: not sure, looking at solutions now
<mdz> elmo: can you take a look at the udu moin instance?
<fabbione> thom: i know the ipw2100 needs an update in 12rc6
<fabbione> thom: i have it in my todo list
<elmo> mdz: did I kill it?
<thom> fabbione: ok, i'm gonna do it now and try it
<thom> fabbione: unless you have any objections?
<fabbione> you mean upload?
<fabbione> thom: i have no objections if you do it in baz
<mdz> elmo: someone or something did
<thom> well, i mean merging and building myself a test kernel
<elmo> mdz: sweet
<thom> and commiting, yes
<fabbione> thom: but don't upload. the toolchain is fucked and i need to fix a FTBFS on ppc
<fabbione> thom: i have no problems with the rest :)
<fabbione> thom: just be 100% sure to check the compilation options.
<thom> fabbione: nod
<fabbione> thom: there are a few tricks to update that driver
<fabbione> thom: it would probably easier for you to just compile it externally
<fabbione> otherwise go ahead and i will check it tomorrow :)
<elmo> fabbione: err, did it do the requisite hoop jumping?
<fabbione> hoop jumping????
<fabbione> elmo: it has been approved by pitti for the security review
<fabbione> if that's what you mean
<elmo> yeah
<fabbione> yes it did
<fabbione> we don't need more than that for now
<elmo> fabbione: done
<fabbione> elmo: thanks
<fabbione> elmo: can you also kindly kick-back lvm2 on all arches?
<fabbione> it's FTBFS because of libdlm-dev not installable
<fabbione> (that you just kindly fixed) ;)
<elmo> ok, I'll give it back once the change hits the archive
<fabbione> rocking
<fabbione> elmo: let me tell you what....
<fabbione> elmo: YOU ROCK!
<Burgundavia> can I have a developer opinion on --> http://www.ubuntuforums.org/showthread.php?t=41145
<Burgundavia> and can someone knowledgeable about nautilus look at --> http://www.ubuntuforums.org/showthread.php?t=41530
<mdz> jbailey: what is the name of that 2.6.12 tool you mentioned for EarlyUserspace coldplugging?
<jbailey> mdz: modprobe in a more-recent-than-we-have module-init-tools can take the modalias as an argument.
<sladen> Burgundavia: re: QoS by default, I mentioned to the last person who asked to add it to the IdeasPool page---could you check they have and if not, add it
<Burgundavia> sladen, ok, cheers
<elmo> jesus christ
<elmo> libaqbanking-plugins-libgwenhywfar17c2
<elmo> and the award for package name of the year goes to ....
<fabbione> ahahha
<fabbione> oh god
<fabbione> how are you supposed to remember something like that?
<wm_eddie_> is it seriously libgwenhywfar17c2?
<pitti> sounds like daf's package :-)
<pitti> welsh
<tseng> pitti: thanks!
<pitti> no worries :-)
* Mez yawns
<pitti> Hi Mez 
<Mez> evening pitti :D
<Mez> konv built in the end :D
<Mez> than ks to you D
<pitti> yeah, I saw
<Mez> though it's apparently affecting the sintall of firefox now :P
<Mez> (only the install though - firefox works fine if It's already installed
<wasabi_> huh. this dbus interface for dhclient... i've never noticed that before.
<mdz> seb128,jamesh: how is the LaunchpadIntegration work going?  did we meet our milestones for yesterday?
<Mez> mdz: ping
<mdz> ?
<Mez> you#re on CC right ?
<mdz> no
<Mez> ah, fair enough, who is
<mdz> http://www.ubuntulinux.org/community/processes/
<Mez> just want to talk to someone about a user harrasing the ubuntuforums staff... and threatening to goto CC and get hem shut down ... 
<mdz> mako: is the most likely to be around at the moment
<Mez> mako: ping
<thom> mdz: the ipw2100 oops is caused by doing a scan; so iwconfig eth1 scanning triggers it too. it'll be very hard to avoid NM doing that
<mdz> thom: 2.6.10 or 2.6.12?
<thom> 12
<mdz> did you try with the latest ipw2100 driver?
<mdz> (from upstream)
<thom> we have the latest already, yeah
* thom tries it with .10, just out of interest
<thom> bleah. regression in 2.6.12; it works _perfectly_ in .10
<seb128> mdz: I've updated the wiki with a list of desktop packages, most of them use GtkUIManager ... maybe worth patching gtk for that, I'm waiting on jamesh pong on that
<mdz> hmm, I have a CD where sound-juicer just keeps reading the first track forever
<mdz> seb128: have you ever heard of anything like that?
<mdz> it is only a 2:45 track, but it keeps encoding forever (and the file grows)
<seb128> mdz: that's a gstreamer0.8-cdparanoia 0.8.9 bug fixed with my upload from 2 days ago which has not built yet
<mdz> it reads the CD TOC fine, though, and lists all the tracks
<mdz> seb128: oh, thanks
<Burgundavia> OO devs, response on OO --> http://www.ubuntuforums.org/showthread.php?t=41734
<seb128> mdz: np
<mdz> seb128: I don't see a new source for it though
<seb128> http://people.ubuntu.com/~lamont/buildLogs/g/gst-plugins0.8/0.8.9-0ubuntu3/
<seb128> this one
<seb128> which is waiting for libpolypaudio to main
<mdz> oh, there it is
<mdz> seb128: promoted
<seb128> thanks
<mdz> I think it will retry on its own soon
<seb128> cool
<HiddenWolf> mdz, I had something like that on a copy-right protected cd
<seth_k> anyone familiar with autoconf / automake, enough to take a stab at deciphering this error message on build?
<mako> Mez: hey there
<mako> Mez: i just saw a message from ryan troy about the same thing
<\sh> mako: hey when r u at the linuxtag?
<Mez> probably :D
<tseng> hi mako.
<Mez> I'll talk to you via query if thats ok ?
<mdz> seb128: is goffice something which is suitable for main?  gnumeric build-deps on it now
<seb128> yep
<seb128> some of the gnumeric widgets have been placed to libgoffice
<seb128> so they can be used for abiword and other stuff
<justin> and evince right? :-)
<seb128> too
<mdz> jbailey: can you give me the 5-minute intro to mkinitramfs hooks?
<jbailey> Yup!
* jbailey looks at the time and sees that he really means 5 minutes. =)
<jbailey> mdz: Got 0.7 installed?
<thom> mdz: so fabbione tells me the likely cause is upstream out-of-syncness, and that'll get resolved in the course of time. so i'm tempted to upload and tell people with problems on ipw2100 to run 2.6.10 in the mean time...
<mdz> jbailey: yep
<jbailey> mdz: 'kay.  In /usr/share/initramfs-tools
<mdz> jbailey: (perhaps a 5-minute conversation spread out over 15? ;-))
<jbailey> =)
<mdz> that's my normal mode of operation
<mdz> (that was an incoming phone call)
<jbailey> Works for me, I won't block on your responses then. =)
<mdz> good plan
<jbailey> mdz: init, scripts/nfs and scripts/local now contain lines that say "run_scripts /scripts/foo"
<jbailey> mdz: Those are the directories under scripts
<jbailey> mdz: Each script is called twice, the first time with an argument of 'prereqs'
<jbailey> Where it's expected to return a string saying which scripts must be run first from this directory.
<jbailey> I intend it to be a soft dependancy, so that if they're not there that it's not a problem.
<jbailey> It's intended to make it easy to do things like force evms to run after lvm if lvm is present, but not freak otherwise.
<pitti> mdz: meeting now?
<jbailey> scripts/local-top contains an example script, it's the md stuff
<jbailey> (Which I'm using to boot my machine now)
<mdz> wasabi: /join #ubuntu-meeting
<mdz> ogra: can you /join #ubuntu-meeting?
<Mez> please tell me the wiki transtiiton isnt happening now
<Burgundavia> Mez, tomorrow, 10am
<Mez> ah kk
<jbailey> mdz: I have some vague thoughts that the scripts I've used here to do the init stuff could be tweaked for the dependancy based init system.
<\sh> that was fast
<mdz> jbailey: ok, so where would I drop the ltsp script and what does it need to do?
<jbailey> mdz: Do you need anything before the hacked nfs script that you sent me?
<mdz> jbailey: I would like for it to be independent of the root filesystem being used
<mdz> I could just provide a complete script which is a modified nfs script (I could do that without hooks), but I'd rather it be a hook which runs after the root fs is mounted
<jbailey> So whether it's nfs or booting off of a local harddrive?
<mdz> seb128: http://people.ubuntu.com/~lamont/buildLogs/g/gst-plugins0.8/0.8.9-0ubuntu3/ <-- successful
<mdz> jbailey: right
<mdz> whether the root filesystem is NFS, GFS, an nbd device, or even a local hard disk, it should be possible to stack a unionfs COW layer on top
<seb128> mdz: nice
<ogra> mdz, sorry, totally forgot about the meeting
<jbailey> mdz: cym
<mdz> ogra: it's ok, most of the candidates didn't show
<ogra> yeps, just read the log... 20mins is a new record, isnt it ?
<jbailey> mdz: Also, you mentioned that you needed the unix module, so create a file called /usr/share/initramfs-tools/modules.d/ltsp that just contains the word unix
<mdz> jbailey: ok. what about the unionfs magic?
<jbailey> mdz: Did I miss a bit in the script?
<mdz> jbailey: where do I drop my script?
<jbailey> mdz: /usr/share/initramfs-tools/scripts/init-bottom
<jbailey> mdz: I think the script I sent you has everything you need.
<mdz> you sent me a script?
<mdz> oh, _just_ now
<jbailey> mdz: Sorry, yes.  That's what the cym was for. =)
<mdz> jbailey: oh, I wasn't familiar with that acronym
* mdz mutters about dh_install not being able to rename files
<wasabi_> I should obviously move around the world so that I don't have to be at work when Ubuntu has meetings.
<dilinger> wasabi: yea, it's much better when they happen at 4am local time
<mdz> jbailey: hmm, first attempt failed
<mdz> jbailey: my init-bottom hook didn't get copied into the initramfs
<mdz> oh, I put it in the wrong place, silly me
<wasabi_> The obvious solution is that Canonical should pay to move us all to the best place on earth. ;)
<justin> wasabi_: outer space? :-)
<mdz> jbailey: ok, after fixing that, my hook script is in place, but still doesn't seem to get run
<wasabi_> Disney land!
<mdz> jbailey: I get 2x "basename: not found"
<mdz> I have BUSYBOX=n if that makes a difference; I think that's the default though
<jbailey> mdz: Oh, I think I might still have busybox loading optional.  Can you please set it to yes and respin?
<jbailey> Thinking of which.
<jbailey> Kamion: ping =)
<mdz> testing
<Kamion> jbailey: hi
<mdz> jbailey: having a hyphen in the filename of an init-bottom script breaks horribly
<mdz> jbailey: eval: 1: array_name-with-hyphens=: not found
<jbailey> Kamion: Wanted to final check that there's no objection to me adding another busybox pass with just what I want for initramfs.
* mdz uses underscores
<trulux> mako: ping
<Kamion> jbailey: no objection here
* trulux has a 2 min. break after studying History
<mako> trulux: yes
<trulux> mako: Amaya replied
<trulux> mako: if it's absolutely necessary, I'll meet her
<jbailey> Kamion: tx
<mako> trulux: well, it's not absolutely necessary to meet her
<mako> but it's absolutely necessary to meet someone
<mdz> jbailey: hmm, my hook script is getting a null/unset ${rootmnt}
<mdz> jbailey: missing export?
<trulux> mako: well, I will see
<jbailey> Shouldn't be, or the nfs script itself shouldn't have seen the variable.
<mdz> jbailey: that one is sourced
<jbailey> Oh, right.
<jbailey> Hmm, that would mean that my rootmnt= hack wouldn't work either for changing the variable.
<jbailey> I wonder if there's any reason not to just source these to run.  I want them to be able to fiddle with the environment.
<jbailey> mdz: Mind trying something?  LIne 101 of scripts/functions, please change ${initdir}/${cs_x} to . ${initdir}/${cs_x}
<mdz> jbailey: I added an export to init, and that fixed it
<mdz> jbailey: I had already changed it not to use the rootmnt= hack anyway
<mdz> it just mounts over the existing ${rootmnt}
<mdz> jbailey: the only thing remaining is that the NFS mount needs to be read-only
<mdz> it should be sufficient if the nfs script honors the kernel command line 'ro' parameter
<jbailey> I wonder if I were to mount it always read only if the usualy remount from ro to rw would work.
<jbailey> But I'll fix it to honour the cmdline.
<mdz> remounting from ro to rw does work with nfs, I believe
<estragon> hello
<mdz> you're already parsing it out; should be trivial to fix
<jbailey> Yup
<estragon> i have tray to go on breezy
<estragon> i have had not to much tooble but i loos a wxpython pack ;-((
<jbailey> Yup, -o ro, or -o rw, /me fixes
<mdz> I don't know why it doesn't work when the NFS mount is rw, but I did run into this before
<mdz> unionfs is not what one might call "robust"
<jbailey> Does this otherwise get you a working initramfs?
<mdz> jbailey: seems to; I'm going to hack up nfs to test
<mdz> (whether it goes 100% normal once I get a read-only mount)
<elmo> ogra: ?
<ogra> elmo, ?
<jbailey> mdz: Cool.  On your system if you include "ramdisk=/usr/sbin/mkinitramfs" in your /etc/kernel-img.conf now, new kernels will call that instead of mkinitrd.
<ogra> elmo, ggradebook ?
<elmo> ogra: nm, see mail :)
<ogra> whoops... ok
<mdz> jbailey: great
<mdz> jbailey: unfortunately, it still needs to be regenerated manually, since the user needs to specify their network driver
<mdz> jbailey: until the initramfs can do the detection
<estragon> any experience with the breezy tree ?
<jbailey> mdz: Right, or a generous list specified in /etc/mkinitramfs/modules for testing.
<mdz> jbailey: seems to work fine with a hacked nfs script to add -o ro
<seb128> any reason we don't have gnome-alsamixer somewhere?
<seb128> (Debian has it)
<jbailey> Lovely, that'll be in the next upload. then.
<mdz> jbailey: if you're going to upload those two fixes shortly, I'll go ahead and upload with a dep on initramfs-tools >= 0.8
<seb128> hum, nm
<seb128> hum, no ... it's on the archive but apt-cache search doesn't find it
<mdz> estragon: the development team all run breezy, yes
<jbailey> Two being the export of init and the ro nfsmount, yes?
<mdz> correct
<mdz> I'm pretty sure that's all I changed
<mdz> ltsp 0.24 uploaded
<torkel> seb128: isn't that replaced by gnome-volume-control? 
<mdz> jbailey: with 0.24, you should be able to build your own ltsp setup without much trouble
<mdz> should make a pretty good test case for initramfs changes
<mdz> it exercises all these new code paths :-)
<estragon> i just install it on an old ppc g3 beige.. but i tray wxpython, but it's no more present in the new depot...
<jbailey> mdz: Nice, thanks. =)
<seb128> torkel: "replaced"?
<torkel> seb128: well, g-v-c does everything g-a does
<seb128> right, but that's not my question
<seb128> I don't discuss if it has some interest, by it's on archive.u.c and apt-cache doesn't find it
<ogra> elmo, fixed, sorry
<torkel> ah
<seb128> s/by/but why/
<estragon> mdz, it's regard wxpython that seam's to be no more present!
<mdz> estragon: libwxgtk2.4-python
<seb128> mdz: any idea for gnome-alsamixer?
<mdz> seb128: none
<torkel> seb128: it is available in warty, but not i hoary (or breezy). Did it get dropped after warty?
<mdz> I never heard of it before
<estragon> and no more 2.5 ... in hoary it's cool wxpython2.5.3 ... but i will tray has you say
<seb128> mdz: I've a bug about it, http://archive.ubuntu.com/ubuntu/pool/universe/g/gnome-alsamixer/ has the package, but it's not listed by the archive
<seb128> mdz: should I reassign the bug to somebody?
<seb128> elmo?
<estragon> mdz, houps ...libwxgtk2.4 is all ready install ... but the othe pak go away of the new tree...
<elmo> seb128: ?
<elmo> seb128: it's only in warty
<seb128> elmo: any reason? 
<elmo> [rene]  RoMOTU: replaced by built-in fuctionality of GNOME
<seb128> hum? 
<elmo> it was removed at the request of the MOTU
<seb128> we remove universe stuff for random reasons?
<elmo> if MOTU ask for it
<seb128> and now a guy bug to get it ...
<seb128> do you know what motu asked for that?
<mdz> elmo: can you retry nfs-utils?
<mdz> it was failing due to needing a promotion to main, but it hasn't retried since the promotion happened
<ogra> seb128, sorry, that must have been daniel, no idea why it was removed
<elmo> mdz: giving back
<mdz> thanks
<elmo> seb128: AFAICR all the removals were done at dholbach's request
<seb128> elmo: k, I'll poke Daniel about this, thanks
<seb128> I don't really get the point to drop stuff than Debian still ships, but whatever
<HiddenWolf> seb128, sounds like extra work to me...
<elmo> seb128: there weren't that many apart from a huge amount of kernel stuff
<seb128> k
<estragon> mdz, i have to leave, tanks for the help
<elmo> seb128: http://people.ubuntu.com/~james/paste/removals.txt, grep for MOTU
<seb128> right, there is not a lot
<seb128> thanks elmo 
<jbailey> initramfs boots my raid1 system still with the changes, anyway.  /me uploads
<Mithrandir> jbailey: how can I test initramfs now?
<jbailey> Mithrandir: Right now we can cover booting from a harddisk, nfs or a raid1 hd setup.  No lvm/evms/or cryptroot yet.  Do you still qualify? =)
<Mithrandir> jbailey: yes
<jbailey> Mithrandir: Excellent!!!
<jbailey> (I've always wanted to be the lynx browser)
<Mithrandir> jbailey: /home is on evms, but that shouldn't matter, I guess.
<jbailey> Nope, that'll be all after you're booting.
<jbailey> Mithrandir: The first bit is to install initramfs-tools.
<jbailey> Mithrandir: You'll then need to edit some config files.
<jbailey> Mithrandir: /etc/mkinitramfs/modules needs to contain a list of everything you need for booting right now.  There's no hw autodetection yet.
<Mithrandir> just got to pull down about 60MB of random updates first.
<jbailey> Mithrandir: And /etc/mkinitramfs/initramfs.conf needs to have busybox set to yes.
#ubuntu-devel 2005-06-22
<mdz> jbailey: how soon do you think you can land the hardware detection?
<jbailey> mdz: I'll have a better answer for you after tomorrow, but I'd really like it to be the end of the week.
<jdub> oh dudes
<jdub> stunning interview with ubuntu contributor, seb128
<jdub> http://oskuro.net/blog/freesoftware/interview-seb128-2005-06-14-17-21
<elmo> that's clearly not seb
<elmo> he didn't say "iz gtk bug" even once
* seb128 slaps jordi again
<jordi> lol
<jordi> yuck, seems like my poor little box is planetgnome'ed
* Nafallo waits for the page to show up ;-)
<jordi> it will... at some point
<jordi> or go to planet.gnome :)
<Burgundavia> jdub, can you comment on --> http://www.ubuntuforums.org/showthread.php?t=41530
<Nafallo> ahh. it's there :-).
<elmo> ogra: ?
<maswan> jordi: want to make a quick fix? get a static dump of it and redirect the accesses there?
<elmo> ogra: tablix should b-d on libpvm3-dev (or whatever it's called) not libpvm3
<ogra> elmo, there is no -dev
<ogra> (at least here on amd64.... )
* ogra looks at i386
* Nafallo grumbles
<Nafallo> forget "--" and you build against the wrong release *sigh*
<elmo> ogra: pvm-dev ?
<ogra> ARGH ... why the heck do they call it pvm-dev and not libpvm-dev
<ogra> elmo, just saw it *sigh*
* ogra prepares a fix
<jordi> maswan: yeah, I probably should for a few days
<maswan> jordi: and if you run out of bandwidth, just redirect it to a server with enough. :)
<elmo> maswan - professional bandwidth pimp
<Nafallo> lol
<Mithrandir> you mean you don't irc from a box with a gbit pipe?
<maswan> elmo: We did peak at about 2Gbit/s for the sarge release. :)
<elmo> maswan: nice
<maswan> Hope we get to beat that for breezy. :)
<maswan> s/for/with/
<Nafallo> hehehe
<Burgundavia> seb128, is there a reason why gnome-network was not built for hoary or breezy?
<seb128> what is this stuff?
<Burgundavia> it was a shell for ssh and telnet
<seb128> gnome-nettool no?
<Burgundavia> nope
<seb128> apt-cache show gnome-nettool
<seb128> are you sure?
<Burgundavia> yep
<seb128> it points to http://www.gnome.org/projects/gnome-network/
<seb128> and Replaces it
<Burgundavia> maybe the shell stuff was dropped by Gnome
<seb128> maybe you want tsclient?
<Burgundavia> nope
<Burgundavia> this is what doesn't appear anywhere else:
<Burgundavia> gnome-remote-shell: a remote shell (Telnet/SSH) client.
* Nafallo wishes good night
<tseng> infinity: can you kick dbus off again?
<tseng> infinity: gtk-sharp is in main now, was the last failure
<fatshame> (complete IRC newb) ... Is anyone here familiar with the Ubuntu installer internals?
<tseng> fatshame: yes but you probably want to read around on the wiki before asking questions
<tseng> if you havent already, of course
<fatshame> I've tried, but unf. wasn't able to find what I was looking for
<fatshame> do you have a min?
<fatshame> question should be pretty quick
<tseng> you want Kamion or maybe mdz 
<fatshame> thanks tseng
<tseng> the general irc etiquitte is to just come right out with your question and hope someone answers
<tseng> if not, try again at a sufficently later time.
<fatshame> oh, sorry trying not to be obnoxious
<mdke> fatshame, fire away, someone might know
<fatshame> I am trying to create a script which will resize an NTFS partition to a specified size.  Using NTFS and sfdisk creates the necessary adjustments but renders the XP partition unbootable.  Where can I find out what steps the Hoary installer takes during it's NTFS resize?
<mdz> fatshame: it uses ntfsresize
<mdz> from ntfsprogs
<fatshame> yea, I'm using that too.  Steps are to resize w/ ntfsresize and rebuild new partition table with partitioning software.  I'm specifying something incorrectly in the second step and trying to figure out what.
<fatshame> I'm feeding something wrong to sfdisk
<fatshame> mdz: does this make sense?
<mdz> fatshame: so your problem is with resizing the partition, not NTFS
<fatshame> mdz: I think so
<mdz> well, you can easily test that by skipping the second step
<fatshame> mdz: I think I've already verified that it's the second step that is wrong, it's a matter of figuring out how to carry out the second step correctly...
<fatshame> mdz: Other projects (parteds, Hoary installer, Suse installer) are all able to resize ntfs partitions to a specified size using ntfsresize, so I should be able to do it too.  It's just a matter of figuring out what mistake I'm making in step two.
<mdz> fatshame: the ubuntu installer uses parted
<mdz> so you won't be able to look at it to see how to use sfdisk
<tseng> mdz: re the pnet depend, is that from the mono-mcs source package, or mono-mcs from the mono source package?
<mdz> tseng: if it's a depend, that's the binary package name; if it's a build-dep, it's the source package name
<fatshame> mdz: right, but I might be able to switch to parted, or figure out how to do the correct sizes...
<tseng> hm I see it now
<tseng> mdz: its a virtual
<tseng>   Depends: <cli-virtual-machine>
<tseng>     mono-jit
<tseng>     pnet-interpreter
<tseng> do we need to pull in both?
<tseng> pnet is not supportable
<mdz> no, just one
<tseng> well then we are covered there.
<tseng> and that will drop treecc off the list also.
<tseng> wonderful, ill chip away at the rest. thanks mdz
<mdz> we do need to figure out why germinate chose that one; it doesn't make much sense
<mdz> are mono-mcs and mono-jit built by the same source package?
<tseng> yes.
<mdz> if we need to, we can add a hint to the seeds to work that out
<tseng> great.
<tseng> i wonder if we can get around xsp-in-main
<tseng> would have to drop monodoc-http or mutilate the source into two ala old dbus-mono
* netjoined: irc.freenode.net -> orwell.freenode.net
<mdz> tseng: is xsp bad news?
<mdz> tseng: it looks like monodoc-http could work with mono-apache-server instead; should we switch it to that?
<mdz> jamesh: ping?
<mdz> jbailey: I think next week is when it (EU hardware detection) needs to be if it's going to happen; please make that your priority
<jdub> Burgundavia: comment on the bug, post a reference to the nautilus mailing list
<tseng> good morning jdub 
<jdub> Burgundavia: perhaps talk to the gnome bug dudes about it
<Burgundavia> jdub, ok, can do
<tseng> Burgundavia is a big filing machine
<AndyFitz> you ?
<Speedy2> Can someone send me the binary for "lspci" ? I am trying to debug an issue with the Ubuntu install CD and the console during the install does not have lspci
<Speedy2> Don't rush to help now.
<Burgundavia> Speedy2, be patient, don't be rude, and this is wrong channel for getting help
<Speedy2> Burgundavia:  I'm doing this so I can feed a bug report back to Ubuntu developers.
<Burgundavia> #ubuntu is for help
<Burgundavia> this is for the fix to that bug
<fatshame> mdz: still there?
<tseng> infinity: nevermind, it kicked itsel
<tseng> f
<mdke> mako, i think the shipit faq has been rolled back too, i could have sworn it was more up to date than that
<jsgotangco> mdke, what happened
<mdke> nothing I just thought that I remember reading more up to date information about shipit for hoary
<mdke> at http://www.ubuntulinux.org/support/documentation/faq/shipit/
<mdke> morning jsgotangco btw
<jsgotangco> morning
<jsgotangco> hows it going
<mdke> fine thanks
<jbailey> mdz: Okay.
<wasabi> Hmm. Not in the main keyring yet.
<wasabi> Hum de dum.
<jbailey> wasabi: elmo's quite swamped.
<jbailey> Need something uploaded?
<wasabi> Naw It can wait.
<jbailey> a'ight
<daniels> so, if you all upgrade libxcursor1 to the latest, I think you'll find Firefox will leak a whole lot less
<mako> mdke: dude.. it was rolled back
<mako> mdke: i know.. it bummed me out a lot
<jsgotangco> heh
<mako> there at least a couple of hours of work missing
* daniels glares at his 290MB-resident Firefox process.
<jsgotangco> mako, long time no see
<jbailey> daniels: Ooo.  Is that likely to apply to epiphany as well? =)
<mako> jsgotangco: a few days maybe.. i kept my head low over the weekend.. had like 5 people staying with me from out of town for the debian release party
<jsgotangco> mako, join the docteam meeting on the 16th 22:00 UTC if you're available
<daniels> jbailey: anything that uses xcursor
<daniels> jbailey: basically, we leaked the set of xrender images for the animated cursor every time we set one
<mako> jsgotangco: send me a reminder
<mako> jsgotangco: i should be around though
<jsgotangco> mako, k will do
<daniels> jbailey: in a long-lived process like a web browser that makes extensive use of the animated busy cursor ...
<mako> jsgotangco: if i'm not on irc, email or sms my mobile
<jsgotangco> ok i'll just get your mobile on your page
<jbailey> daniels: Oh ouch.
<mako> i've been going to sit in the park next to my house around evenings these days.. there is wireless but sometimes i unplug.. makes me productive :)
<davyd> how broken is X today?
<davyd> ie, did I pick a very bad day to switch to breezy?
<seth_k> davyd, I'm running upgraded X and breezy. no issues
<seth_k> davyd, you'll want to check the breezy forum if you just upgraded. probably some goodies there for you
<davyd> will do in a minute, there seems to be new X packages to download
<davyd> so I'm getting those now
<seth_k> good good
<seth_k> are you having issues?
<davyd> yeah, it looks like X is trying to start, ie. flash flash flash flash (Screen on, screen off)
<davyd> and then it stops and things lock up
<davyd> although I still have system-requests
<davyd> so it didn't take out my interrupt handlers
<davyd> I figured I would check for new X before I started digging too deep
<seth_k> odd, haven't seen that one yet. The flavor of the day was libxcursor iirc, or maybe that was yesterday
<daniels> seth_k: yeah, xcursor was yesterday's fun
<daniels> davyd: if you've just upgraded and you have a custom config, edit /etc/X11/xorg.conf and change your /usr/lib/X11/fonts fontpaths to /usr/share/X11/fonts
<daniels> (or maybe they're /usr/X11R6/lib/X11/fonts, who knows
<seth_k> somebody did a whopping good job on libxcursor... I upgraded, rebooted, no X, sudo aptitude update && sudo aptitude upgrade and I was back in business
<davyd> daniels: aah, I might have custom lines in my config, can I just regenerate the default Ubuntu config?
<seth_k> davyd, sure, sudo dpkg-reconfigure xserver-xorg
<daniels> davyd: sudo dpkg-reconfigure -phigh xserver-xorg
<daniels> seth_k: um yeah, that was me
* davyd looks up daniels' flags
<wasabi> eclipse 3.1... so.... close....
* wasabi pant.
<davyd> oh right
<seth_k> wasabi, any more releases after rc2? or is final next
<wasabi> Dunno. It's close if nothing else.
<wasabi> What I mean is that I'm almost done packaging RC2.
<fabbione> morning
<seth_k> wasabi, for breezy, or for yourself?
* seth_k yoinks a copy
<wasabi> breezy.
<wasabi> You may notice 3.0 is in breezy RIght Now.
<seth_k> yay
<wasabi> Multiverse though.
<seth_k> yes
<seth_k> i saw free java stuff got brought in?
<Amaranth> i thought it didn't work
<seth_k> so we can put 3.1 in universe?
<wasabi> Well, technicall 3.0 is good for universe right now, but I don't want to move it.
<Amaranth> hey, fedora core 4 has eclipse built as a native binary using gcj, you should grab their patches :)
<wasabi> Since 3.1 will be done soon.
<seth_k> gotcha
<wasabi> Amaranth, no need.
<davyd> warning interface eth0 at line 2 is not safely mappable
* davyd ponders that that means
<davyd> generated by hotplug
<seth_k> error's been there forever. no clue what causes it, but harmless
<davyd> although, working X
<davyd> seth_k: goodo, I'll ignore it then
<davyd> hmm, Fixed has gone missing from the fonts list :(
<seth_k> heh, i remember that error
<seth_k> you have X though?
<davyd> yep, X is alive
<davyd> daniels: you've been bang on the money so far, any idea why Fixed is a no go?
* seth_k grumbles that siretart went offline in the one hour I was away
<seth_k> Riddell, you around?
<seth_k> hmm, suppose not. I apt-got kubuntu-desktop metapackage today on a fresh Breezy, sources updated, and it didn't pull in kdebase or kde-core. I had to install those separately before I had a working KDE install
<daniels> davyd: try apt-get install --reinstall xfonts-base
<davyd> daniels: seems not, could it be fontconfig?
<davyd> I also have a copy of the font in my ~/.fonts directory
<daniels> nope, the server doesn't use fontconfig
<daniels> your font path is definitely /usr/share/X11/fonts/fo?
<daniels> s/fo/foo/
<davyd> yep, X starts now, I have most fonts
<daniels> word
<davyd> except Fixed is never listed in my gtk2 apps
<davyd> though it used to
<daniels> that'd be a fontconfig thing
<daniels> you'd need to change its paths also
<wm_eddie_> autopackage needs to die ><
<wm_eddie_> Does anyone know how to remove the debian menu entry that autopackage put in my Applications menu?
* davyd forces fontconfig to regenerate it's cache
<davyd> still not...
<davyd> hmm
<Amaranth> pfft, who needs the Fixed font anyway? :)
<davyd> it's a nice terminal font
<davyd> I see fontconfig has configuration to turn off non-scalable fonts
<davyd> now to work out how to enable Fixed anyway
<daniels> jdub: http://gsynaptics.sourceforge.jp/
<wm_eddie_> I saw that today (gsynaptics) That's awesome.
<davyd> zing
<davyd> http://oracle.bridgewayconsulting.com.au/~davyd/misc/20-davyd-enable-fixed.conf
<davyd> not quite
<davyd> ok, it works if you have the fonts in your .fonts
<davyd> I'm sure I could fix that too
<davyd> daniels: you want to fix dbus-mono, your Depends line refers to dbus-glib-1-dev
<davyd> that should be libdbus-glib-1-dev
<davyd> I am pretty sure that was your package
<daniels> davyd: thanks, will do
<daniels> oh, wait
<daniels> no, not dbus-mono
<daniels> that's deprecated and disappearing as soon as libgtk-cil hits main
<davyd> oh ok
<davyd> that explains why it's still broken for me
<daniels> yeah
<fabbione> daniels: speaking of which.. would it be possible to make dbus not build-dep on mono stuff for sparc?
<daniels> fabbione: sure'
<fabbione> i think ia64 and hppa would need the same kind of love
<daniels> fabbione: but its b-ds are broken everywhere at the moment, so don't worry, it's not just you :)
<fabbione> daniels: given mono is not portable :(
<daniels> yeah
<fabbione> daniels: yes i saw that :)
<fabbione> daniels: i tend to check pretty carefully all FTBFS
<davyd> I thought Mono worked on Sparc nowadays
<davyd> or is it that it works on Solaris x86?
<fabbione> davyd: on sparc/solairs.. that's what i was told
<fabbione> not sparc/linux
<davyd> fabbione: but not on sparc/linux?
<davyd> nutty
<davyd> you would have thought that once you have to code to do evil things like passing parameters up and down the stack, the rest would be easy
<daniels> At this point, only the Solaris operating system is supported.
<daniels> Adding support for Linux/SPARC or UltraLinux requires somebody with the neccessary technical skills, motivation, and access to hardware to do the port. This effort boils down to adding support for the differences between Solaris and Linux and their ABI. 
<davyd> I guess no one who cares is running Linux on a Sparc
<davyd> I wish I had the time to sit down and learn about that sort of stuff
<fabbione> davyd: usually who run sparc/linux is not for workstation
<davyd> I'm sure I could be good at it
<davyd> instead, all my engineering skills go to waste
<fabbione> but for servers
<fabbione> hey pitti
<davyd> fabbione: yeah
<davyd> are you dudes going to officially support sparc?
<pitti> Morning
<jsgotangco> i think fabbione has sparc builds but they're unofficial
<jsgotangco> ooppss sorry i didn't read the latter posts
* davyd nods
<davyd> supporting sparc would be an interesting move
<davyd> we have one sparc workstation in the UCC, but it's a whore
<fabbione> davyd: i am building sparc64 yes
<fabbione> but it's not official
<davyd> it's currently (trying to) run Solaris 10
<fabbione> and probably won't be for a while
<fabbione> i am somehow stalling in a little loop
<fabbione> because i don't have enough cpu power to keep up with all the new packages
<fabbione> so basically it's never (or almost) installable
* davyd smirks
<fabbione> that means not being able to build a community around it to help me supporting it :)
<fabbione> so i don't get CPU power to keep up
<davyd> yeah, there can't be a big sparc desktop community around at all
<davyd> I wonder what EE is doing with it's sparcstations
<davyd> those are relatively grunty
<davyd> they wouldn't give me an account on them to jhbuild with though
<davyd> because they guy who's job it is to do Solaris adminning is a bit of a control freak
<maswan> fabbione: what kind of cpu power do you have, and what would you need?
<fabbione> maswan: i have a netra t1 466Mhz
<fabbione> maswan: i think another buildd would do
<fabbione> doesn't need to be an E10K :)
<maswan> fabbione: ok, I'll see what I can do
<fabbione> maswan: basically i need something that can build universe so that i can dedicate my machine to main
<fabbione> maswan: but i am not in a hurry to build universe in itself
<fabbione> maswan: that would be awesome
<maswan> fabbione: we were thinking of putting this machine into d-d general use, but that is pending an exception to the general "only staff and students on the network"-rule
<fabbione> maswan: oh i see
<maswan> fabbione: given that this has been pending for quite some time now, ...
<davyd> we have an E4k running Debian now
<fabbione> maswan: yes i understand the uni-rules
<maswan> this would be an E250 with 2x400MHz and 512 megs of ram.
<fabbione> neat
<davyd> I'm not sure what's in this thing
<davyd> or we have an E6k, but that's running Solaris 9
<maswan> fabbione: now, one buildd admin like you, we can sneak in. but not open up for a large ammount of developers.
<maswan> fabbione: so, is it installable, or would a chroot install from a sarge host system be more likely to be usable?
<fabbione> maswan: i don't want to be a problem. if it is allowed good, otherwise please do not worry :)
<davyd> State:
<davyd> CPU0:           online
<davyd> CPU4:           online
<davyd> CPU5:           online
<davyd> CPU6:           online
<davyd> CPU7:           online
<davyd> Cpu0Bogo        : 332.80
<fabbione> maswan: the machine can run whatever you want.. 
<maswan> fabbione: it's fine
<fabbione> davyd: please stop flooding
<davyd> Linux manduba 2.6.8-2-sparc64-smp
<davyd> fabbione: would that do?
<fabbione> maswan: i only need a sparcbuildd account and a breezy chroot (that i can scp from here)
<davyd> apologies about the first 5 lines, they weren't meant to be pasted
<maswan> fabbione: any kernel requirements?
<fabbione> davyd: that's a nice toy :)
<davyd> fabbione: we have a Solaris 9 machine with 14 CPUs of similar capabilities
<torkel> maswan: when/if ubuntu starts supporting AFS we can probably make it even less a problem... :-)
<davyd> and someone just returned from the US with somewhere near 10gigs of RAM
<fabbione> maswan: nope.. i only need to be able to ssh in/out + access http://archive.u.c and http://ports.u.c
<fabbione> davyd: i did run debian on an E10K with 32 CPU / 32 GB of ram
<fabbione> davyd: i am not new to sparc hw
<davyd> fabbione: we don't have one of those :(
<davyd> I figured
<davyd> I'm just trying to think what is useful
<davyd> we can't complain at this stuff, it was free
<davyd> and realistically, at the moment, both of them are being space heaters
<davyd> they're hardly utilised
<fabbione> maswan: if you are going to create an account for me, please call it sparcbuildd and not just buildd as it is used to be
<maswan> fabbione: ack
<fabbione> maswan: thanks
<maswan> fabbione: Ok, so can I get an ssh key for that?
<fabbione> maswan: sure..
<fabbione> maswan: email address?
<maswan> maswan@acc.umu.se, please sign the mail
<fabbione> maswan: clearly :)
<fabbione> maswan: on the way
<fabbione> maswan: i will need some sudo privileges to install a few packages on the main hosts (like wanna-build, buildd and sbuild) and to be able to manage the chroots
<fabbione> maswan: but we can talk about it later on...
<fabbione> if that's ok with you :)
<maswan> Well, I'll think about it first, when I'm not so tired. :)
* maswan handles the easy parts first. :)
<fabbione> maswan: eheh sure..
<fabbione> thanks a lot
<bob2> Kamion: which's the install option to avoid copying all the .debs to the hard disk during install?
* maswan waits impatiently for the greylisting to do its magic
<fabbione> maswan: just go to sleep if you are tired :)
<fabbione> maswan: it's not something i need now :)
<maswan> fabbione: I'm not going to sleep, I'm going out with family to do more violence to the old summer house. :)
<fabbione> maswan: go and have fun :)
<maswan> fabbione: I will, as soon as they arrive with a car. :)
<maswan> fabbione: anything you need immediately?
<fabbione> maswan: only you to confirm the keys
<fabbione> maswan: and no.. i want you to go out and have fun :)
<fabbione> maswan: i will setup the minimal stuff in the meanwhile
<maswan> fabbione: well, I'll be around for a while, until I leave. :)
<jdub> hrm, no jbailey
<BeerDump> JaneW, hello
<Simira> morning JaneW 
<Simira> how  was Bergen?
<JaneW> hello jgotangco 
<JaneW> nice
<jgotangco> wow you went to Norway?
<bob2> go firefox
<Treenaks> bob2: kill -9!
<bob2> see, I'd like to leave it running for weeks
<Treenaks> bob2: \o/ memory fragmentation
<bob2> nah, it just screws up
<bob2> like the address bar stops updating
<bob2> and dialogs can't be closed anymore
<Treenaks> bob2: get traces, file bugs
<Kamion> bob2: archive-copier/copy=false
<bob2> ah, thanks
<bob2> Treenaks: bleh, it's just in a poll loop
<bob2> I so can't be arsed to recompile it with debugging symbols
<elmo> the udu and edubuntu wikis are going down temporarily
<sivang> elmo: edubuntu has it's own wiki ? 
<elmo> sivang: yes
<ogra> sivang, sure
<ogra> sivang, it has its own ML :)
<jsgotangco> heh
<jsgotangco> i should subcribe to that
<jsgotangco> ogra, hello
<ogra> jsgotangco, yes, go ahead :)
<jsgotangco> it needs a lot of love :)
<ogra> jsgotangco, if everything goes fine i'll have the first edubuntu liveCD based on mdz's ltsp packages and the k12ltsp appset ready in two weeks
<jsgotangco> ahhh i should get ready with that then
<fabbione> Kamion: hey dude
<jsgotangco> oohh i see the evil hostmaster account
<Kamion> fabbione: morning
<fabbione> Kamion: got adsl at the new flat? :)
<Kamion> fabbione: yep
<fabbione> cool
<Kamion> up to megabit, about damned time
<fabbione> Kamion: ehheh neat :)
<fabbione> Kamion: installer/partman question...
<fabbione> how much do we care about aoe devices?
<fabbione> we know we cannot boot from them....
<Kamion> ata-over-ethernet?
<fabbione> yeps
<Kamion> almost not at all
<fabbione> but i know partman has a patch upstream to support them
<fabbione> and we have kernel support for breezy
<Kamion> you really mean partman, or parted?
<fabbione> not sure... probably the latter?
<Kamion> that would be more likely
<fabbione> yeah i leave that up to the "d-i allmighty" ;)
<Kamion> google suggests http://lists.gnu.org/archive/html/bug-parted/2004-09/msg00172.html
<fabbione> that would be it
<fabbione> for me it's a line to add in ide-modules...
<Kamion> I don't really know very much about parted, though; I prefer not to touch it myself if possible
<fabbione> and in the initrd creation..
<Kamion> SteveA's problem this morning was likely a parted thing
<fabbione> but i think we can deffer it, if you prefer not to touch parted
<Kamion> well, there's no reason not to start adding support
<Kamion> in the hope that upstream pick up that patch
<fabbione> how fast is upstream generally?
<fabbione> because tbh it's an easy change to do, even later on
<fabbione> so if you are confortable with it i can do it right away. otherwise we can wait
<Kamion> the patch dates from September, no replies ...
<fabbione> ok.. let's wait :)
<ogra> eeek.....
<fabbione> ogra: hey dude
* ogra wonders why he has to deal with python2/tkinter crap
<ogra> hey fabbione 
<fabbione> ogra: ClusterFS is all in main/universe
<fabbione> i need you to start testing too
<ogra> fabbione, i'll do, sorry for the lag
<fabbione> ogra: that's ok.. don't worry
<ogra> has anybody experience with and (auto nice daemon) how cracky is that ?
<bob2> wtf
<bob2> firefox lost my url history
<bob2> thoooooooooooooooooooooooooom
<daniels> bob2: eep
<Lathiat> thats not a bug, its a "feature"
<bob2> no, it's "shit"
<daniels> heh
<wm_eddie_> I once accidentilly opened firefox in sudo.  That's bad.
<Lathiat> but now mummy won't see those naughty sites you visited!
<wm_eddie_> all your bookmarks are instantly gone.
<Lathiat> whoah, filed a bug?
<wm_eddie_> I can't understand bugzilla enough.
<Lathiat> so what major is broken in breezynow?
<Lathiat> who takes care of the audio stuff? (dmix etc)
<Kamion> Download all files that we need to get (775 MiB).
<Kamion> oh dear, my mirror is a bit out of date
<pitti> Lathiat: that's mainly me
<Lathiat> pitti: dmix in breezy + esd doesnt work so well here, yet the settings ive stolen from various wikis before that i used on hoary worked fine, file a bug or ?
<Lathiat> or are we just moving to polypaudio and not caring?
<pitti> Lathiat: we changed the default sink to ALSA
<pitti> Lathiat: right, esd+new alsa == the suck
<Lathiat> pitti: right
<pitti> Lathiat: maybe the brand new upstream version cures that, but my previously attempted patches didn't
<Lathiat> pitti: ah ok, cool
<jbailey> daniels, seb128: ping?  Interesting this with some upgrade in the last week, when I restarted my machine, the panels got swapped as to which monitor they were on.  Everything else was still correct.
<jbailey> (xinerama setup)
<seb128> weird
<seb128> I blame xorg :p
<jbailey> Even if it is a gtk bug, you'll never admit it again? =)
<seb128> exactly :p
<jbailey> Objet: 	Nokia 770 developer device program request
<jbailey> BOOYAH!
<seb128> (I don't have any xinerama here and I know that's the same for one of the gnome-panel upstreams)
<seb128> you got a Nokia 770? :)
<jbailey> No, but I qualified for one of the 500 discounted ones.  90 or something like that.
<jbailey> seb128: Will you know if you need me to be your bitch for testing xinerama stuff. =)
<jbailey> s/Will/Well/
<sjoerd> jbailey: when did you receive mail about being qualified for that ?
<jbailey> sjoerd: Looks like about 45 minutes ago.
<seb128> is there any source package known to be known by hct?
<jbailey> cdbs was in there
<seb128> $ hct source cdbs
<seb128> Houston, we have a problem ...
<seb128> HCT caught an exception not handled by the command: Fault
<seb128> The exception had the value: <Fault 8002: 'error'>
<seb128> 
<seb128> GRRR
<jbailey> I get the same error now, so it's not your setup.
<mvo> jbailey: I got a mail too (/me is happy)
* sjoerd is still hoping to get such a mail :)
<jbailey> mvo: It's finally an excuse to clean up my vCard.  evo seems to have about 45 instances of jbailey@canonical.com in it.  The only way I can tell to get rid of them is deleting an email address in the contact and then one of the other ones rushes in to fill the slot.
* mvo keeps my fingers crossed for sjoerd 
<sjoerd> mvo: thanks
<jbailey> sjoerd: If it's alphabetical, we should both have heard before you, so good luck!
<seb128> jbailey: thanks
<jbailey> Hmm, weird.  evo has a way of expanding to handle the additional phone numbers, but not the additional emails.
<jbailey> It doesn't show extra phone numbers in the summary display, but will show all of the email addresses. =)
<Kamion> why might a GtkComboBox I've defined in glade and populated in python still show up empty?
<jbailey> reflow?
<Kamion> reflow?
<Kamion> I'm doing:
<jbailey> ISTR gtk had a mode where you could tell it not to update the widgets live when you were rapidly filling them up.
<Kamion>         list_store = gtk.ListStore(str)
<Kamion>         geographic_area = self.glade.get_widget('geographic_area_combo')
<Kamion>         geographic_area.set_model(list_store)
<Kamion> and a bunch of append_text() after that
<jbailey> The last gtk coding I did was some time ago, though.
<Kamion> when I click on the combo box, it pops up as a blank rectangle about four lines high
<Kamion> it kind of looks like there's something in it but gtk is horribly confused about what
<mvo> Kamion: you could just do a area.set_model(None), udate the list and do a set_model(liststore) after that again
<Kamion> oh, do I have to set the model after populating the list?
<seb128> should not
<mvo> Kamion: the combo box has two modes, one is a mode that needs a model and one is a simplified mode that only works with text. 
<mvo> Kamion: you need to set the model only once, but I'm not sure if the problem might be that you mix the two "modes" 
<Kamion> I tried leaving it at None (which was what I got after using gazpacho to lay out the interface), but then append_text() failed an assertion because the model wasn't a list store
<Kamion> populating the list store first doesn't seem to make any difference
<mvo> Kamion: could you /msg me the complette code snippet?
<Kamion> mvo: http://people.ubuntu.com/~cjwatson/comboboxproblem.tar.gz
<Kamion> mvo: oh, you'd gone by the time I finished testing that second round of apt changes for extraoverrides, and my mail was non-functional at that point - but it worked fine, thanks
<seb128> Kamion: 
<seb128> "The append_text() method appends the string specified by text to the list of strings stored in the combo box gtk.ListStore. Note that you can only use this method with combo boxes constructed with the gtk.combo_box_new_text() function."
<seb128> according to the API
<mvo> seb128++
<doko> seb129
* mvo -> lunch
<jdub> The following packages will be REMOVED:
<jdub>   aptitude* ubuntu-base* ubuntu-minimal*
<jdub> The following NEW packages will be installed:
<jdub>   python2.4-apt
<jdub> The following packages will be upgraded:
<jdub>   apt apt-utils python-apt synaptic update-notifier
<jdub> 
<jdub> ^ been getting this for a while now -> what's b0rk?
<thom> lamont/infinity: can you give-back tomboy, please?
<elmo> thom: won't help
<elmo> libdbus-1-cil is still in universe
<thom> argh, when did tomboy get promoted? (and, shouldn't the fact that tomboy deps on libdbus-1-cil autoseed it?)
<elmo> it's asking to be promoted yes
<elmo> I don't know who promoted tomboy and not it, and whether or not it's had (or even needs) it's security  review
<elmo> teri needs logging so badly
* pitti never looked at tomboy
<Kamion> wasn't me, I assume it was mdz
<pitti> it is not even in the queue https://www.ubuntulinux.org/wiki/UbuntuMainInclusionQueue
<tepsipakki> is the http://www.ubuntulinux.org/wiki/SecurityUpdateProcedures page out of date?
<tepsipakki> regarding the "issues that warrant" an update
<mdke> hno73, looking good :)
<hno73> mdke :)
<mdke> this is so awesome
<mdke> we have a proper wiki
<Lathiat> heh yay
<Kamion> tepsipakki: why do you ask?
<pitti> Kamion: I'm just talking with him, the "reasons that warrant an update" really warrant an update .. :-)
<tepsipakki> yeah, I got what I asked for ;)
<mvo> jdub: do you get this on dist-upgrade? what happens when you do "apt-get install update-notifier"
<Duck_work> jbailey: hope there is not to much noise
<Duck_work> coin everybody
<Duck_work> seb128: could you say cdbs or cdbs2 ?
<koke> mvo: I'm upgrading with aptitude and update-notifier shows the post-upgrade information stuff
<koke> but aptitude is not finished yet
<koke> mvo: any suggestion to debug (if needed)
<seb128> cdbs
<Duck_work> seb128: perfect :-) thanks
<seb128> np
<Duck_work> jbailey: i'm ready
* pitti is confused
<pitti> Duck_work: so seb128 saying "cdbs" actually helps you with something? :-)
<Duck_work> pitti: hilight test
<pitti> aah :-)
<Duck_work> i don't want to miss cdbs2 devel infos
<Duck_work> that's why i'm here actually
<pitti> ah, now the name wiki.duckcorp.org makes sense to me :-)
<mdke> hno73, will there be an equivalent of the comments system?
<hno73> mdke: We plan to use /talk sub-pages, but we need to add a button to the interface for it
<mdke> ok yeah
<hno73> It will be similar to the 'discuss' page in Mediawiki
* mdke nods
<mdke> sounds good
<hunger> hno73: Is that to comment on the BreezyGoals? Or for something else?
<mdke> for the ubuntu wiki in general
<hunger> PS: fedora's (pre-)installer has a really niffty feature: It has a "Test install CDs" function right after the boot screen.
<hno73> hunger: the idea is the have comments _about_ a page on a sub-page so not to clutter up the actual page
<hunger> hno73: Yeah, great:-)
<mdke> hunger, yeah that test CDs function is pretty cool
<hunger> hno73: BreezyGoals is not in the ubuntu wiki though... so does this apply to the udu wiki as well.
<hunger> mdke: I am remembering now since I am trying to install from a kubuntu-CD which seems to be broken:-(
<hno73> hunger: you can create a /talk page there if you like too
<mdke> omg it is so nice not to have to login back to the wiki everytime I close and open the browser
<hunger> hno73: I am under the impression that I can't. Would make sense... those texts are "official", you won't have all kinds of wierdos scribbling into them;-)
<bob2> hunger: ubuntu has had that feature for a long time, too
<hunger> bob2: Where?
<hunger> bob2: md5sum does not count;-)
<bob2> hunger: in the main installer menu
<bob2> boot in expert mode and you'll be dropped at it
<Kamion> or select 'go back' from the first screen to get to the main menu
<hunger> bob2: Ah! there it is!
<hunger> Maybe you could try to make that somewhat more prominent:-)
<hno73> hunger: That's why 'talk' is a good feature. Just visit http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals/talk. Tell them I said it's ok :)
<Kamion> hunger: can't in the current architecture, I'm afraid
<Kamion> hunger: may be able to in the future
<hunger> Sorry... I only keep asking you to add stuff and do not contribute back:-(
<hunger> Hehe... FC4 did not find my wlan card... hoary asks whether I want to install using it as my primary interface!
<jdub> mvo: Package upgrade-notifier is a virtual package provided by:
<jdub>   update-notifier 0.39.2
<jdub> mvo: same as before with update-notifier
<mvo> jdub: what happens if you run "apt-get install update-notifier aptitude"?
<hunger> Any comments on debian's TODO for etch? Will that be stuff ubuntu can use?
<tseng> hunger: we pull in most everything from debian, so of course
<tseng> two of those are on our own list for breezy and breezy+1
<tseng> (g++, multiarch)
<hunger> tseng: What is multiarch?
<tseng> 32 + 64 bit libs
<tseng> on amd64 or ppc64 for example
<hunger> tseng: Oh, great.
<tseng> wow debian dropping old kernels
<hunger> tseng: Well, talking about dropping...
<tseng> on the list anyway.
<hunger> tseng: http://wiki.debian.net/?EtchTODOList has a summary of the debian-devel discussions.
<tseng> im reading it
<Kamion> [ 19%]  Getting: pool/main/g/gcc-3.4/cpp-3.4_3.4.4-0ubuntu6_i386.deb      # failed:Can't access /sites/archive.ubuntu.com/ubuntu/pool: I/O error
<Kamion> wow
<daniels> Kamion: awesome
<daniels> Kamion: cdimage?
<Kamion> nah, ftp.mirrorservice.org
<daniels> ah
<bob2> is gam_server supposed to spin at 100% stat'ing non-existent files in /tmp?
<tseng> bob2: thats a feature
<bob2> oh, and if you kill it, nautilus, gnome-panel and mail-notification go up to 100% to make up for it
<daniels> haha
<daniels> awesome
<Lathiat> better than spinning on /media/usbdisk/blah
<Lathiat> bob2: heh
<bob2> it seems all running gtk programs are trying to take all my cpu now
<bob2> inkscape, gimp, gnome-settings-daemon, etc
<tseng> cool someone made a traceback to my blog
<tseng> and his site has an htaccess
<Mithrandir> heh
<Lathiat> hmmm
<Lathiat> imfairly sure apt isnt supposed to take >30 seconds to calculate a dist-upgrade
<daniels> Lathiat: your gnome-panel has probably gone insane :P
<Lathiat> hmm it got there
<Lathiat> i guess it realy did needtoo
<Lathiat> so, whats broken in breezy atm?
<tseng> mono dbus stuff needs rebuilt
<tseng> maybe a few more things for cxx
<tseng> mostly working on my end..
<Lathiat> so mono mostly works
<Lathiat> X mostly works
<tseng> yes.
<Lathiat> and bluez-utils is patched for new dbus
<Lathiat> ok everything i careabout works now:)
<chmj> :) 
<daniels> x completely works
<Lathiat> daniels: completely? rocking :)
<bob2> daniels: no more "if you make this symlink *here*..."?
<daniels> yeah, and now I'm about to break it, because I hate each and every one of you
<daniels> bob2: right
<daniels> bob2: but that's shit boring, so I'm going to dump a modularised libX11 on breezy soon
<daniels> locales only *just* started working
<bob2> rock
<tseng> :(
<daniels> (like, with my CVS commit from ten minutes ago)
* Treenaks buys daniels a beer for that
<tseng> daniels: hah we added that cflags crap the the beagle release
<tseng> about libxss
<daniels> tseng: heh
<daniels> well, this is where Xlib.h moves from /usr/X11R6 to /usr
<daniels> the rest should go pretty quickly
<daniels> since they don't do anything fancy-pants like libX11
<tseng> Treenaks: save those beers for all the guys who made the wiki unsuck
<Treenaks> tseng: I have enough money to buy them stonger stuff than mere beer
<ogra> Fatal server error:
<ogra> could not open default font 'fixed';
<ogra> the X server's font paths might be misconfigured
<ogra> seb128, ^^^
<seb128> ?
<ogra> seb128, thats sabayon ? why does it need the fixed font ?`
<seb128> I'm not maintainer xorg
<seb128> s/ainer/aining/
<daniels> wtf is sabayon?
<seb128> sabayon is the stuff for GNOME to create profiles
<ogra> seb128, it looks like it tries to start a second xserver
<seb128> it starts a gdmflexiserver
<ogra> ah
<daniels> hm
<seb128> you do your changes here
<ogra> ok, then i understand the error :)
<seb128> and it saves the changes to create a profile
<daniels> ogra: make sure your FontPaths are all pointing to /usr/share/X11/fonts in xorg.conf
<ogra> seb128, thanks 
<seb128> np
<ogra> daniels, i didnt restart my xserver since last weekend, so my config might not be the newest :)
<daniels> heh
<ogra> i was just astonished that sabayon needs a own xserver
<tseng> ogra: its actually a pretty clever way to do ti
<tseng> it
<ogra> tseng, yeps
<ogra> tseng, i'd love to incorporate it in edubuntu....
<tseng> indeed
<tseng> i could probably use it for mono-live
<tseng> to make a custom session
<bob2> this is screwed
<lifeless> bob2: ping
<daniels> OH MY GOD WHY DOES SO MUCH STUFF ABUSE /USR/X11R6 SO BADLY
<lifeless> 42
<daniels> i am so going to go on a mass-bug-filing RAMPAGE in debian
<tseng> daniels: because its been there for an enternity?
<daniels> tseng: policy forbids t
<daniels> and lintian and linda BITCH REALLY LOUDLY at you for doing it
<ogra> daniels, heh, policy
<tseng> heh
<tseng> lintian
<daniels> (this is an issue which irritates me to some degree)
* tseng says as he writes a policy
<jbailey> Duck_work: Heya. =)
<jbailey> dilinger: Around?
<Duck_work> jbailey: !!!
<dilinger> jbailey: yessir
<jbailey> dilinger: Wanted to introduce you to duck, he's a new stalker of ours.
* dilinger waves
<dilinger> cdbs2 related stalking, or he just likes the long hair?
<jbailey> dilinger: He did pretty much the only documentation that exists for cdbs1 (I think the motu's use it), and has nick highlighted on cdbs and cdbs2 to follow the conversations in here, since we usually have them here or in #ubuntu-kernel. =)
<dilinger> ah, right.  yea, i remember seeing his docs
<jbailey> (He also might like boys with long hair.  The subject has never come up.)
<ydo> Hi folks
<bob2> so
<bob2> the only way to fix this is to SIGSTOP gam_Server
<bob2> if you kill it, it respawns
<bob2> and continues walking your entire hard disk
<Lathiat> bob2: rebootand format!
<bob2> for a GTK bug?
<Duck_work> jbailey: i prefer short-haired boys usually :-)
<Duck_work> coin dilinger 
<Lathiat> bob2: of course,what else?:)
<jbailey> Duck_work: Ah well, I'm spoken for an monogamous anyway. ;)
<jbailey> s/an/and/
<Duck_work> jbailey: never said i had more than one at once, and unfortunatly stats are often stalled to 0
<Simira> *ubuntu t-shirts ordered*
<Treenaks> Simira: I want ubuntu t-shirts too!
* HiddenWolf too
<Simira> Treenaks: I hope to get them before Debconf.
<Simira> then I'll bring some
<Treenaks> Simira: I can't come to debconf because I got a new camera
<Simira> Treenaks: that made sense :p
<Simira> else, I'll ship them to Europe. Information will come soon, somewhere near you ;p
<HiddenWolf> Treenaks bought a camera, and now he's too broke to go to debconf, presumably
<Simira> I guessed that
<bob2> hah, holland -> debconf is the price of a camera.  such a trip would cost as much as my car.
<Treenaks> bob2: get a cheaper car
<Simira> bob2: I don't have a car, and I can't afford a camera ;p
<bob2> hahahaha
<Simira> brb, dinner
<Treenaks> Simira: yes, but you're practically next to helsinki ;)
<ogra> bob2, thats because they all fly with KLM
<Simira> Treenaks: yeah... practically.... uh
<bob2> hth is it dinner time in norway?
<Treenaks> bob2: 16:18 ?!
<ogra> early dinner :)
<bob2> = late lunch
<eruin> do any of you know where I can get involved in d-i i18n? after installing breezy, I can safely say the person doing norwegian has a complete lack of basic grammar knowledge :O
<Simira> eruin: and thanks to you ;)
<Simira> eruin: www.ubuntu.no, #ubuntu-no
<HiddenWolf> eruin, should be careful, you might just be talking to that person just now. :P
<Simira> HiddenWolf: shhh
<eruin> is that you Simira? :&
<Simira> eruin: not exclusively. not much actuay. I just try to organize it.
<Simira> ehm
<Simira> = ll
<Lathiat> trs80_: davyds on laptop?
<trs80_> my laptop
<trs80_> console, of course
<trs80_> since I can't get working X
<Lathiat> stillno X love?:)
<Lathiat> heh
<Lathiat> Should have bought a dell!
<trs80_> tried upgrading to breezy, now I don't have an xserver at all
<Kamion> eruin: #debian-boot
<Kamion> if the strings aren't Ubuntu-specific, I'd greatly prefer not to be the bottleneck on passing corrections back to Debian
<Simira> Kamion: which translation is on Breezy-installer? Debian/Sarge has a completely good one, as far as I know ...
<Kamion> Simira: the same
<Simira> hmm.. ok
<Kamion> Simira: there are some additional translations of Ubuntu-specific strings, which I'm happy to take corrections for
<lamont__> elmo: pin
<lamont__> g
<Simira> Kamion: eruin just volunteered ;p
<Kamion> well, when I say "the same", it's difficult, because d-i is highly modular. It should all be at least as new as sarge, though
<Simira> Kamion: but you got a new translation from Terance Sola just before hoary released?
<Kamion> yes
<Kamion> I believe I only accepted translations of new strings, though
<Kamion> although my filter may have missed a ffew
<Kamion> few
<Kamion> eruin: which strings in particular?
<eruin> Kamion, any chance of seeing d-i stuff on rosetta?
<eruin> Kamion, I could reboot and fetch the relevant screens if you want
<HiddenWolf> rosetta needs some love, awefull lot of red there. :(
<Simira> eruin: I suppose you'd want to get into hoary translations and to it upstreams
<Simira> to/do
<eruin> ie have a stab at the debian-boot guys
<dilinger> yay, nobse's bzr no longer uses python2.4
<Kamion> eruin: yeah, it's on my list of things to do for breezy
<Kamion> eruin: please, that will help me to determine whether you need to pester me or upstream
<eruin> kk
<eruin> brb
<dilinger> bah, still not installable on hoary
<ogra> damned... i have an infinite and unsolvable lintian error....
<ogra> E: bibshelf: spelling-error-in-copyright debain Debian
<pitti> fabbione: any objections if I resolve your #8116 as duplicate of #7619?
<ogra> bad for software that comes from http://www.debain.org
<ogra> grr
<azeem> ogra: add a lintian override
<bob2> hahaha
<ogra> azeem, yeps, that would do it, thanks.... i was nearly going insane *g*
<eruin> Kamion, okay, trouble found in the hostname setup, partition method select, partition manager itself, "copying remaining packages" screen, and the screen that's supposed to tell users that there's no root
<eruin> I'm guessing the noroot-part is ubuntu-specific ;)
<mvo> does anyone have a idea what encoding http://ring.fujixerox.co.jp/archives/linux/debian/debian-ddtp/dists/unstable/main/i18n/Translation-ja might have?
<Kamion> eruin: right, as is "copying remaining packages"
<mvo> and what language http://ring.fujixerox.co.jp/archives/linux/debian/debian-ddtp/dists/unstable/main/i18n/Translation-uk could be?
<Kamion> mvo: -ja is EUC-JP
<Kamion> mvo: -uk is one of the KOIs, probably KOI8-U
<mvo> Kamion: thanks for EUC-JP, works now!
<bradb> hey guys, question for you as we sync the debian bugs into Malone. let's say we imported 200 debian bugs you personally had filed into Malone, *and* that you had an active launchpad account that you were using. would you expect to get Malone email notifications if any comments or other changes are made in Malone to those imported debian bugs that you reported?
<Kamion> yes, looks like KOI8-U, there's a slight difference
<Kamion> (from -R)
<Kamion> bradb: comments definitely, not sure about other administrivia
* Kamion goes for more coffee
<bradb> Kamion: noted, thanks
<mvo> Kamion: how did you figured it out?
<Kamion> mvo: I knew the standard legacy encodings for those languages, so I tried feeding them through iconv to UTF-8 and verified that they looked right
<mvo> Kamion: cool! thanks, works now for both files :)
<mdz> thom,elmo: at the time that I promoted tomboy, it appeared that all its deps were in main (though perhaps this one was masked by beagle?)
<seb128> Keybuk: hey ... hct is known to have issues atm? It returns a 8002 on "hct source" 
<tseng> mdz: tomboy is still build-dep on libdbus-cil
<tseng> mdz: which is now libdbus-1-cil
<mdz> tseng: oh, so it changed names?  that would match my observations
<tseng> which just finally built sometime yesterday
<tseng> mdz: indeed.
<mdz> if it's essentially the same as the old package, it doesn't need another review
<tseng> i dont keep my gpg and all that at work, it will have to wait.
<tseng> but easy fix.
<Keybuk> seb128: hct source what?
<Keybuk> hmm, meh
<seb128> Keybuk: whatver I've tried, cdbs by example
<seb128> why according to jbailey is listed by hct
<Keybuk> yeah, it's breaking somewhere deep in pybaz
<seb128> s/why/which/
<Keybuk> will look into that in a minute
<seb128> thanks
<mdz> Kamion_: have you ever seen an aptitude segfault like the one in the email I CCed you on?
<tseng> daniels: do you have time today to look at libgdiplus ftbfs? its gross cairo/x stuff
<tseng> daniels: hm i should try the CFLAGS hack first
<daniels> tseng: sure
<danielki> hi
<tseng> gdip.h:33:22: error: X11/Xlib.h: No such file or directory
<tseng> might fix that actually
<tseng> and /usr/include/X11/extensions/Xrender.h:34:23: error: X11/Xutil.h: No such file or directory
<mvo> mdz: could you please forward that segfault to me too? does it contain a backtrace?
<Keybuk> seb128: there's an internal error in pybaz, and I'm not really sure what it means; will have to wait until ddaa is about -- could be a problem with last night's dogfood rollout
<thom> tseng: i uploaded a fixed tomboy, too
<tseng> thom: you rock!
<thom> tseng: it needs to be given-back once libdbus-1-cil is promoted
<seb128> Keybuk: k, no hurry, thanks
<tseng> thom: promoted? libdbus-1-cil is from dbus source
<daniels> tseng: CFLAGS="-I/usr/X11R6/include"
<mdz> mvo: no, it's just: ./menu/pkgsel: line 5:  5121 Segmentation fault      DEBIAN_PRIORITY=high aptitude --without-recommends -y install "$PATTERN"
<mdz> mvo: in base-config.log
<mdz> but it's 100% reproducible
<thom> tseng: yes, but currently it's in universe
<mdz> only for that invocation, though. later aptitude invocations work fine
<mvo> mdz: how hard would it be to get a backtrace? 
<mdz> mvo: hard
<mdz> mvo: I'm working on it
<mdz> I have to get him to set up a serial console for the first boot, before base-config runs
<tseng> daniels: testing.
<mvo> mdz: uh :/
<Kamion_> mdz: nope, never
<mdz> Kamion_: me either
<Kamion_> right now I'm working on the impressive stack of stuff that caused #11852
<mdz> Kamion_: how is OEMInstaller looking?
<Kamion_> mdz: 		 
<Kamion_> #
<Kamion_> gah
<Kamion_> mdz: I've got a debconf-only version working, with modifications to localechooser and kbd-chooser; yesterday/today I've been working on a pygtk layer in front of that so that it's actually reasonably usable
<elmo> lamont__: ?
<mdz> Kamion: please update BreezyGoals, if you haven't already
* kafeine is away: hearing your voice is like icicles down my spine
<thom> kafeine: please don't have public away messages in this channel
<Kamion> mdz: done
<mdz> mvo: why the b-d on expat in apt-listchanges?  I'm not aware of anything in apt-listchanges which uses it
<mdz> daniels: what's your latest ETA for xorg?
<daniels> mdz: fixed libX11 locale issues now, so tomorrow morning is the plan
<daniels> mdz: doing non-work stuff at the moment as it's well beyond core hours
<mvo> mdz: gettext needs it to generate a pot file from the glade file for the gtk frontend
<mvo> mdz: I need to fix it so that it does not update the pot file during the package build though
* lamont__ notes that a 64MB-RAM PII-400 is not something one would want to boot a livecd on
<thesaltydog> is there any german-speking mate who can help me in translating a message?
<thesaltydog> speaking
<mdz> mvo: if gettext needs it, gettext should depend on it
<mdz> mvo: I thought we wanted the pot file to be updated during the build?  pitti has been sending patches to that effect
<r0bby> you guys should throw qmail into the apt repository 
<r0bby> it's reletively secure
<lamont__> daniels: if I have a box with multiple graphics cards, does the xorg stuff just automatically make me multi-screen?
<daniels> lamont__: nope
<lamont__> iz complex?
<lamont__> (being multi-screen, that is..)
<lamont__> apparently it "just happens" on XP.
<jdodson> mako: you around?
<mako> jdodson: yessir
<jdodson> mako: i would appreciate a chat if you have a spare moment.
<mvo> mdz: hm, right. gettext does only need it for glade files. I'll check that now
<fabbione> Kamion: ping?
<sebest> hello, anyone knows if the CDDL (opensolaris licence) allows tools like smf to be ported to linux?
<sebest> SMF-> Service Management Frameworks, equivalent of apple launchd, that could replace the aging init.d system
<bob2> haha aging
<bob2> CDDL is gpl incompatible
<sebest> bob2 MPL also!
<azeem> but SMF doesn't sound kernel related?
<sebest> but firefox is in ubuntu right?
<sebest> the same for the php, apache licence and so on
<elmo> man, is beagle going to be in breezy?
<bob2> sebest: er, firefox is triple LGPL. GPL and MPL
<elmo> I keep losing notes I write in random cryptically named files
<sebest> bob2 and what about php?
<ogra> elmo, yes, thats planned
<bob2> sebest:  no idea, but php isn't essential for anything on linux
<mdz> Kamion: does your OEMInstaller prototype include the proposed test mode?
<ogra> elmo, but you should buy really fast disks for it ;)
<elmo> ogra: meh, it can work in the background can't it?
<tseng> elmo: it throttles
<elmo> I only ever lose stuff that's from 2-3 days ago
<Kamion> mdz: no, not yet
<ogra> elmo, it does... but my lappie gets dran slow over here
<Kamion> fabbione: pong
<elmo> tseng: hum, how's it do that as a userland process?
<sebest> bob2, i just mean that many software are gpl incompatible and are distributed by debian/ubuntu
<bob2> sure
<tseng> elmo: it scales down normally, scales up when you turn on a screensaver or i think X idle time
<fabbione> Kamion: yo... i noticed a "strange" thing about some pcmcia modules on some arches...
<crevette> hello
<elmo> tseng: ah, cunning
<tseng> elmo: links to libxss
<fabbione> Kamion: perhaps you can shed some light on it..
<sebest> and i wanted to know if something like smf could also be distributed if ported
<tseng> but now it doesnt scale up if you are on battery, ogra 
<fabbione> Kamion: drivers/ide/legacy/ide-cs.o
<ogra> tseng, cool
<azeem> they claim the CDDL is OSI-free I think
<fabbione> Kamion: some arches ship that module.. others don't..
<fabbione> Kamion: and they do it in ide-modules. meaning that ide-modules needs to depend on pcmcia
<sebest> azeem, yes, but who say, "this can be ubuntu", this can't
<fabbione> Kamion: since i am trying to allign a little bit the mess around...
<fabbione> Kamion: should i kill that module or should i make ide-modules depends on pcmcia
<fabbione> ?
<tseng> elmo: rob love just added some stuff for profiling disk utilization, i dont think it does anything useful with it yet
<ogra> elmo, but regarding my inbox it might be an individual problem :)
<Kamion> fabbione: if I were you I wouldn't try to align that - the differences between architectures in that regard is generally because some architectures have actually shipped with IDE PCMCIA devices whereas others never have
<ogra>  du -hcs /home/ogra/.evolution/
<ogra> 927M    /home/ogra/.evolution/
<ogra> 927M    total
<Kamion> fabbione: so please make ide-modules depend on pcmcia-modules just on the appropriate architectures
<sebest> azeem for example APSL2 is a is also OSI compatible but no software under apsl2 can enter debian :s
<elmo> ~/mail % du -sh .
<elmo> 1.8G    .
<elmo> ogra: don't even go there :P
<tseng> ogra: was it you or daniel who got an ioctl out of space? i know what causes it now
<ogra> elmo, beagle does
<fabbione> Kamion: ok...
<Kamion> fabbione: there is really no point creating an artificial pcmcia-modules on e.g. ia64 just for the sake of uniformity
<ogra> tseng, i didnt, but think i remember it was dholbach
<fabbione> Kamion: it was already there...
<fabbione> Kamion: on ia64 i mean...
<Kamion> it's not in Debian
<Kamion> oh, 2.6 only
<tseng> ogra: inotify has a limit on monitored folders per process
<ogra> ah
<Kamion> well, $ARCH that's never had PCMCIA hardware, then
<tseng> ogra: he was over it :)
<ogra> heh
<fabbione> Kamion: well there are pci <-> pcmcia adapters...
<fabbione> Kamion: and i found pcmcia there.. so i'd rather keep it
<ogra> tseng, how do we work around that ?
<tseng> ogra: its an ioctl, you can kick it up
<tseng> ogra: but its high enough i dont think we need to do it in the distro.. (8192 folders in ~)
<ogra> hmm, sonds enough for the average user...
<ogra> sounds even
<tseng> thats directories, not files
<tseng> thats a ton
<tseng> ogra: i think we might direct people to #ubuntu-mono for a few weeks to avoid me/users flooding other channels?
<erb> hello
<hunger> Who handles the acpi-support init-script?
<jdub> mvo: there?
<mvo> jdub: yes
<jdub> hey
<tseng> hi jdub 
<jdub> hey hey
<Kamion> hunger: that's mostly been thom
<hunger> thom: Are you around?
* hunger sighs.
<hunger> Looks like I will have to use a bugtracker.
<hunger> What is the best way to send a patch for a packet? Attach it to a bugreport?
<Kamion> hunger: s/packet/package/; yes, that works
<hunger> Does someboby know a tool that works on scsi devices like hdparm does on ide?
<hunger> Kamion: My new laptop breaks the acpi-scripts by not having a hda:-)
<hunger> Lots of ugly warnings...
<grover> no hda?
<HiddenWolf> grover, sata drives are named sda
<hunger> grover: It insists on calling its drive sda. SATA I think...
<grover> sata laptop?
<grover> cool
<hunger> grover: It is by far the nicest laptop I had so far!
<HiddenWolf> grover, it's hardware, those tend to run hot. :P
<HiddenWolf> and sata has few advantages as of yet... :P
<hunger> HiddenWolf: Well, my previous laptop gets *WAY* hotter.
<hunger> grover: HiddenWolf is right though: not worth the trouble of getting a SATA laptop yet.
<HiddenWolf> sata desktop drives are cool because you can do away with master/slave ide meddling during building, but that's about it.
<hunger> HiddenWolf: It is nice for the drives to be hotpluggable in laptops...
<hunger> HiddenWolf: Not that you will want to replace the primary drive during opperation;-)
<grover> but the cdrom is still not sata right?
<Kamion> hunger: there's an 'sdparm', although it hasn't quite been packaged yet
<Kamion> Debian bug #312580
<hunger> Kamion: Maybe I should upgrade to breezy...
<hunger> Kamion: I got a IBM laptop and BreezyGoals states those to be supported;-)
<HiddenWolf> hunger, I'd not advise you to at this stage. :P
<hunger> HiddenWolf: My other laptop is on breezy... works not-too-badish.
<HiddenWolf> hunger, your call then. :P
<HiddenWolf> Eh, why is the bounties page that's advertised on the front page mostly an empty skeleton? Most don't even have a status assigned...
<HiddenWolf> I bet you'd get a lot more responce to them if you'd put them as "to be assigned"
<tseng> thom: thomboy!!
<Nafallo> tseng: ?
<tseng> Nafallo: its working
<Nafallo> yay!
* Nafallo updates
* hunger sighs. This laptop is too new for hoary:-(
<HiddenWolf> hunger, i'd sue
<hunger> HiddenWolf: Whom? canonical for not syncinig their release schedule with my plans or myself for always needing the newest gadgets?
<Nafallo> hunger: sue yourself! that would be fun :-)
<seth_k> make sure when you do sue yourself, you sue for court costs as well. those are expensive. :P
<hunger> Please stop making fun of me... I am depressed enough already.... Installing win took a couple of hours and installing linux will take the next couple of days! That is the first time in years that it will take longer for me to install linux than win:-(
<Nafallo> hunger: what about breezy-daily to install?
<Nafallo> TFBIS?
<Nafallo> dooh!
<Nafallo> FTIFS even :-)
<hunger> Nafallo: Doesn't have the restricted modules I need:-(
<hunger> FTIFS?
<Nafallo> Failed To Install From Scratch ;-)
<hunger> Nafallo: Looks like I'll need to rebuild at least some of the stuff myself.
<Nafallo> nice :-)
<hunger> Nafallo: I think I'll give the almost-dark side a whirl before I have to move over to the really dark side of windows.
* hunger downloads gentoo-unstable.
<Nafallo> lol
* hunger weeps softly when seeing the gentoo "installer".
<mvo> what locale is "eo"?
<KaiL> esperanto?
<HiddenWolf> right
<HiddenWolf> ISO 639 Language Codes
<HiddenWolf> ISO 639 Language Codes. ISO 639: 3-letter codes ... 450-1100) esk Eskimo (Other)
<HiddenWolf> epo eo Esperanto
<mvo> heh, thanks :)
#ubuntu-devel 2005-06-23
<wasabi_> oh hell
<wasabi_> there is a script here.
<doko> wasabi_: I think tromey told you ;)
<wasabi_> I asked last night and haven't been able to check personal email heh
* schweeb opens up his new laptop
<schweeb> IBM X41s are sweet.
<tseng> hm
* wasabi_ sneaks out of work early.
<wasabi_> May get something done tonight. ;)
<Mez> MOTUTodo confuses me - it sesm theres's useful links and done, but nothing to do
<diamond> Mez: aye, ditto
<Mez> lol
<thom> hunger: the sata thing is known
<bob2> woo, some dhtml crashed firefox
<quio> Hello every one !  I'm using Breezy and I just upgraded my dist... when i tried to start my X , I got this error:  glibc detected *** double free or corruption (fasttop) , somebody knows how to fix it?
<schweeb> did you check the mailing list?
<maswan> elmo: 130.239.18.137 is gone from ftp.acc for the moment, you should probably update
<jamesh> quio: it means that the app is buggy
<schweeb> X is known to be pretty broken in breezy
<schweeb> (intentionally so)
<jamesh> quio: you could try running "MALLOC_CHECK_=0 startx" to see if it starts
<quio> ok, let me try it :)
<jamesh> that just turns off glibc's malloc bug checker
<quio> yeeeeah!!! :D it works!! thanks jamesh ... really I appreciate your help ;)
<jamesh> quio: setting that env var doesn't solve the problem though -- it just stops glibc from looking for it
<quio> so, It appears to be a glibc bug, by now I can continue working with your sol :).  To really fix this, do you think that I have to wait for the upgrade of glibc or have another permanent solution?
<jamesh> not a glibc bug
<jamesh> a bug in the application (e.g. calling free() on the same bit of memory twice)
<jamesh> once the heap gets corrupted anything can happen in the program, which is why glibc checks for the condition and aborts
<quio> mmm yes..... ok, thank jamesh... I will continue my work by now ;)....
<jamesh> better to have an aborted process than a rooted system.
<eruin> anyone packaging istanbul in here?
<seth_k> eruin, see my reply in -motu
<fabbione> morning
<schweeb> mornin
<toresbe>  moin
* netjoined: irc.freenode.net -> orwell.freenode.net
<wm_eddie_> hmmm... autoplay and multiple log-ins and auto-play don't work together...
* wm_eddie_ wonders how to fix that...
<Lathiat> autoplay?
<wm_eddie_> I put in a DVD, and my sister's account auto-played it.
<wm_eddie_> hmm...
<wm_eddie_> Maybe the Fast User Switching Applet can tell gnome via D-BUS who'
<wm_eddie_> s
<wm_eddie_> account is currently visible.
<Lathiat> oh right
<Lathiat> wm_eddie_: well, yeh, g-v-m already does dbus so
<wm_eddie_> There's no other way huh...
<Lathiat> wm_eddie_: thats not such a badidea
<Lathiat> maybe g-v-m can figure out what tty its X server ison?
<wm_eddie_> Yeah, but the auto-play stuff needs to know about multiple logged in users.
<Lathiat> yeh but
<Lathiat> if it know what tty it is on
<Lathiat> it can see if its active or not
<wm_eddie_> What do you mean tty?
<wm_eddie_> :0, :1, etc?
<daniels> wm_eddie_: vt7, vt8, et al
<wm_eddie_> hmm
<daniels> but what $DISPLAY it's on is more interesting, easy to get, and practical
<wm_eddie_> What do you mean it's on?
<Lathiat> daniels: but can you tell what $DISPLAY is active?
<daniels> Lathiat: if FUS was keeping track, sure
<daniels> if you switch away, or have a multiseat setup, all bets are off
<Lathiat> right
<daniels> (but if you wanted to keep track of it even through vt switches, an x extension could potentially be interesting)
<Lathiat> wel obviosuly it would be overriden for multiseat
<Lathiat> in favour or manual config
<daniels> right, as g-v-m is now
<Lathiat> is there an easy way to find what xserver is on a tty?
<Lathiat> im just thinking an X extension could be over the top
<wm_eddie_> It's pretty frustrating that I can't eject my DVD because my sister logged into the computer 4 days ago...
<Lathiat> wm_eddie_: just unmount it
<Lathiat> as root
<Lathiat> :)
<Lathiat> but yeh, it is
<Lathiat> (if she has stuff open on it)
<wm_eddie_> Yeah, I know that, but that's because I've been using linux for years.
<Lathiat> linux really could do with a way to invalidate files for removable media
<daniels> Lathiat: no solution that doesn't involve ps and grep, no
<Lathiat> so it can just tell a process usingit to fuck off
<daniels> Lathiat: even though, you'd need a root helper app to determine what tty you're on anyway
<Lathiat> daniels: or looking around /proc, slightly lessevil
<daniels> Lathiat: still equally evil, and open to subversion from user processes with carefully crafted strings
<Lathiat> hm
<Lathiat> \
<daniels> i've been thinking of an X extension for different (and arguably stupid) reasons anyway
<Lathiat> like?
<daniels> have your compmgr hook into a vt switch event.  when switching in, fade in from black (either gamma or just tool wit hthe colourmap), when switching out, delay the switch until you've faded down to black
<wm_eddie_> daniels, That'd be pretty cool.
<Lathiat> daniels: heh neat
<Lathiat> how bout a cube animation? :)
<wm_eddie_> That'd be too Appley
<Lathiat> apple do that?
<Lathiat> hm ok
<wm_eddie_> We have to take it a step further.
<Lathiat> triangular? :)
<wm_eddie_> Yes OS Xs fast user switching does a cube animation.
<daniels> the most extreme example of stupidity I can think of is animating a spinning globe or something
<daniels> where all your sessions are mapped over a sphere
<daniels> however, if anyone actually implements that, I'll be extremely dirty at them for wasting their talent on something like that and not spending their time hacking on core X
<wm_eddie_> What about melting off of the background session?
<daniels> which hooks in well with the vt switch idea, since you don't need knowledge of the other user'ss session
<wm_eddie_> If I don't win any Google bounties I'll see what I can do about that bug.
<daniels> if you needed an image of another session, you'd have to use something like dmx
<daniels> to which my answer is 'no'
<daniels> unless your gdm slave could request an image of other slaves from the master
<wm_eddie_> Eh, I'm sure the glitz powered X can do something like that easily.
<daniels> wm_eddie_: if it includes getting images of other sessions, then the answer is no, not really
<daniels> it won't be computationally expensive, but how do you screen-scrape another session?
<daniels> unless you just disable all authentication, in which case you're completely screwed when someone just points a keylogger at your $DISPLAY
<wm_eddie_> I see...
<Lathiat> and its potentially security bad unless you know your about to switch to that display
<Lathiat> daniels: so when do we get working glx+composite?
<wasabi> In other words, when can the arteests start making eyecandy?
<daniels> you can do it today with xglx
<daniels> or xegl or whatever
<daniels> xgl*
<wm_eddie_> OMFG!!!!
<wasabi> I'm not an arteest. THe problem is most arteests can't install all that crud. ;)
<daniels> provided your compmgr is glx-based
<wasabi> But when it's in front of them!
<wm_eddie_> I just heard a Puerto Rican song in Japanese radio!!!!
<daniels> david reveman demonstrated glxcompmgr at guadec
<daniels> wasabi: well, yeah.  i'm packaging it.
<wasabi> I'm curious... what are the long term plans for a totally GL based gfx system? I was reading some of the wishlists and stuff about running X on top of GL instead of the other way around.
<wasabi> Are people working on that?
<daniels> xglx is running X on top of GL
<daniels> ditto xegl
<wasabi> Or is it just a pleasent dream at this point?
<wasabi> Oh.
<daniels> it works today if you want it
<daniels> thing is, stacks of people use render these days, and render ops are generally far far better accelerated by 3D engines (in particular all the compositing) than 2D
<daniels> so handing off to a GL library is a big win in that case
<wasabi> Oh I have no doubt. Having X on top of GL is the obvious good way to go.
<wasabi> xgl runs inside of X though doesn't it?
<wasabi> like xnest
<daniels> pretty much the only problem with doing that is arbitration
<daniels> wasabi: xglx does; xegl doesn't
<Lathiat> whats xegl
<Lathiat> like xglx but runningunder it?
<wasabi> seems sol
<daniels> (xgl* is a family of X servers that translate to GL calls.  glx is the gl-over-X protocol, and egl is an 'embedded GL' subset thingy.  we can plug mode switching into egl fairly easily, so the plan is to make that the API the X server relies upon.)
<wasabi> SO how is that stack implemented? THe video vendors wil have to build differnet GL drivers that are interfacing with something else?
<daniels> there aren't any accelerated egl drivers available to us at the moment, but we have xegl rendering to the linux framebuffer justfine
<daniels> the vendors will have to supply egl drivers, right
<daniels> which isn't too difficult
<wasabi> Interesting. So egl is the base graphics framework, and there would be... for instance, an xorg driver for it?
<wasabi> Or would it be totally different than that.
<Lathiat> nice im on 91% and acpi predicts 5h5m battery left
<Lathiat> with bt, 802.11 and music playing
<daniels> wasabi: an X server layered on EGL, yes
<daniels> wasabi: so instead of having radeon_drv et al, we just have an EGL driver
<wasabi> That really sounds like such an ideal design, etc.
<Lathiat> daniels: so the question is
<Lathiat> if im running a s3 trio
<daniels> wasabi: this lets the vendor provide a completely binary driver if they want.  there's one argument that says this is great, because everyone will do it.  there's one argument that says this is absolutely terrible, because everyone will do it.
<wasabi> You could have gdm basically do fast user switching between different X server instances on VTs by rotating the cube the X servers are on.
<Lathiat> will this be slower?
<daniels> Lathiat: in that case, you hang back on the xorg server
<Lathiat> daniels: right
<Lathiat> is Xgl part of xorg?
<wasabi> The vendors will come in line wiuth the open source thing on their own.
<wasabi> No reason to force their hand.
<wasabi> That is, if we really believe it's better.
<daniels> Lathiat: right now, it's not
<daniels> Lathiat: we're working towards much greater codebase parity though
<wasabi> If it's not better, then I wouldn't ask them to. ;)
<daniels> (modularisation will help us a *lot* here)
<Lathiat> daniels: is it based on xorg?
<Lathiat> or xfree?
<daniels> wasabi: given the extreme reluctance every vendor is now displaying to do open source (intel probably being the least reluctant), this is a terrible thing
<daniels> wasabi: closed drivers for every card is a nightmare
<daniels> Lathiat: closer to kdrive than anything
<Lathiat> daniels: ahh ok
<wasabi> Well, I personally think that people will choose foss because it is simply a better system.
<wasabi> Market forces, etc, yadda yadda.
<Lathiat> they should be foss
<wasabi> obviously it will be fought tooth and nail, like everyting.
<Lathiat> but have code like the nv driver in xorg
<wasabi> ANd ti will suck until they get on board.
<wasabi> But they will.
<daniels> Lathiat: not if it involves their 3D engine, they won't
<daniels> wasabi: i'm not convinced they will
<wasabi> daniels, im talking over the course of Many Years.
<daniels> wasabi: some vendors who were previously very keen on open source are now retreating back into their proprietary shell as quickly as they can
<daniels> wasabi: we're designing an X server for next year
<wasabi> There are still many people, a vast majorty I would say, who don't like Linux itself because it's open source.
<daniels> wasabi: if I have to endure 5 years of binary-only drivers to get a win, then screw that
<wasabi> heh.
<daniels> if that's the case, there's a whole class of us who will just keep on maintaining Xorg until there are free EGL drivers
<wasabi> I think that when Linux becomes main stream. When we have a product that people EXPECT to work.
<wasabi> The vendors will be forced to make that happen.
<wasabi> And the only way they'll be able to, is by playing nice.
<Lathiat> it'l be all about vendors
<Lathiat> then
<wasabi> IT's never about vendors.
<wasabi> It's about users.
<Lathiat> we'll lose the hackers cus open source wont be minority or fun anymore :)
<wasabi> Well. Heh.
<wasabi> I dunno.
<wasabi> I can't predict that. Either all teh FOSS guys will jump ship... for hurd...
<wasabi> ANd Linux will turn corporate. ;)
<wasabi> Or not.
<Lathiat> hurd ;p
<Lathiat> heh
<Lathiat> well im off
<Lathiat> tofix some stupid computer 
<daniels> the only thing that keeps some vendors with tiny bits of nominally open source drivers is that most distributors flat-out refuse to distribute proprietary drivers, at least in their default set
* wasabi shrugs.
<wasabi> We're a massive minority right now.
<daniels> sure
<wasabi> And we're not going away.
<daniels> but I guarantee you that if Ubuntu, RHEL/Fedora, et al, all said 'we'll distribute proprietary drivers in our default set', the free drivers would vanish from the vendor radar
<wasabi> Short term I'd agree.
<wasabi> But at the same time, there is a reason people use Linux and not *insert closed source OS here*
<wasabi> I mean, I hope there is.
* wasabi looks around.
<wasabi> I have a firm belief that if we can't win on our own merit, we don't desearve to win.
<maswan> well, you know, in the server space, drivers are already happening, with a few exceptions
<maswan> because there it isn't as much a vocal minority as a significant part of the market
<wasabi> Anybody aware of the eepro/e100 driver deal?
<wasabi> I'm curious about that one.
<maswan> what regarding it?
<wasabi> eepro existed, then e100 came into being.
<maswan> yeah
<wasabi> Looked like one was a community effort, the other was official.
<maswan> one was becker's driver, the other was intel
<maswan> 's
<wasabi> Why did Intel do that?
<daniels> elmo: x11proto-* -> main please
<maswan> because becker writes drivers quickly, but not always the best possible. at least in our experience
<daniels> elmo: (xorg b-d)
<wasabi> Yeah but what made intel give the source vs just releasing a binary only driver?
<wasabi> I think that's a rhetorical question.
<daniels> the fact rhel wouldn't distribute it if it was a binary-only driver?
<maswan> Well, probably clue. :)
<fabbione> hey maswan 
<wasabi> daniels, thank god for the redhats of the world then, right?
<maswan> hi there
<grover> well....
<maswan> wasabi: I think that in our experience, we're grateful that becker wrote drivers for network cards, we just wish they had been more solid and less buggy. :)
<fabbione> maswan: you tell me when you are awake enough to setup the buildd :)
<maswan> fabbione: want more stuff?
<maswan> I am
<fabbione> maswan: well i need some packages and some sudo rights
<daniels> (also, the kernel guys deliberately don't expose a stable ABI, so attempting to provide a binary driver is far, far mroe difficult in that case)
<grover> open sourcing lowers maintenance burden, since the community can proactively fix stuff
<fabbione> maswan: ok let me find all the stuff we need :)
<wasabi> Just make sure to keep EGL rotating. ;)
<maswan> fabbione: ok. what do you need?
<daniels> grover: however, in reality, the number of people who can, say, fix an SMP-related deadlock in radeon DRM/DRI, is pretty low
<fabbione> maswan: looking at the overall :)
<maswan> grover: having drivers in the kernel.org tree means less chance of changes breaking it
<grover> daniels: true, nice drivers are simpler
<grover> nic driver
<grover> s
<stockholm> ogra: hi!
<wasabi> I dunno. I think there'sa  reason FOSS is growing as fast as it is.
<wasabi> It doesn't just give a warm fuzzy feeling.
<grover> it's free? :)
<wasabi> It's doing something right.
<wasabi> Maybe that's it.
<wasabi> But it's actually GOOD. ;)
<wm_eddie> gah WTF is updatedb running now...
<wm_eddie> I still can't beleive I heard a Puerto Rican song on Japanese radio...
<daniels> mdz: -25 uploaded
<daniels> elmo: (libx11-dev and libx11-6 need to be in main also, but they already have binary overrides)
<wm_eddie> I think the next couple of years is going to be the second open-source explosion.
<wm_eddie> With Mandrake turning into one big MegaDistro, Novell pushing Mono, RedHat with their mad X magic, and Ubuntu doing things the way they should be done.  It's just a matter of time before critical-mass.
<pitti> Moins moins
<wm_eddie> Crap, major security holes in Sun Java :(
<\sh> *grmpf*
<\sh> what was the common fix for this error message?
<\sh> g++-4.0.gcc-opt: ../intl/libintl.a: No such file or directory
<\sh> on amd64/ia64
<doko> b-d on getttext?
<\sh> yepp
<\sh> and I tried gettextize -f -c 
<\sh> ah...una momenta..
<\sh> this looks good
<jdub> daniels: still can't enter text :-)
<robitaille> jdub,  the news on the right-hand side of planet.u.c seem a bit confused since the wiki conversion
<jdub> robitaille: hmm
<jsgotangco> NEWS: CD does not boot
<jsgotangco> nice
<pitti> Kamion: would it be totally evil if the Kubutu installer installed kde-i18n-<lang> in addition to language-support-<lang>? otherwise I had to create a l-support-kde-<lang> which just depends on kde-i18n-<lang>, which would add another ~80 packages to the archive
<pitti> Kamion: it is trivially easy to generate the kde-support packages (in fact I have to disable that actively), but I don't want to make elmo cry
<\sh> gentlemen, i would like to point to this mailing http://article.gmane.org/gmane.linux.ubuntu.devel/8094 and if -devel is the right place to ask this. do we have a common ubuntu solution?
<mvo> is it possible to add comments to a task in malone (not to the bug itself, but the "needs fixing in ..." bits)?
<Kamion> <cjwatson@cairhien ~/src/ubuntu/cdimage/debian-cd/data/breezy/preseed/kubuntu>$ grep patterns kubuntu.seed
<Kamion> base-config     base-config/language-pack-patterns      string language-pack-$LL kde-i18n-$LL
<Kamion> pitti: it already does :)
<Kamion> (with language packs, rather than language support packages)
<pitti> Kamion: oh, neat
<pitti> Kamion: the plan is to pull the translations out of kde-i18n-<lang> and into language-pack-kde-<lang>
<pitti> Kamion: so the remaining contents of kde-i18n-<lang> will be translated documentation, which is rather support-ish
<fabbione> hey Kamion 
<fabbione> hi pitti
<pitti> Hey fabbione 
<Kamion> pitti: I can install them with support instead, sure
<fabbione> Kamion: i figured the pcmcia thingy.. it was bong.. there was a pcmcia-storage-modules for it :)
<Kamion> might involve a couple of lines of code, but nothing new or exciting
<pitti> Kamion: ok, fine. I ping you back if that change is actually done
<Kamion> fabbione: ah yes
<Kamion> pitti: cool
<pitti> s/if/when/ :-/
<fabbione> Kamion: yeah.. cleaning the all is a pain, but it's coming nice and dandy :)
<Kamion> let's see how broken today's CD is ...
<fabbione> Kamion: before upload i will push you the changes so you can take a look
<\sh> guys, why does my package compile normally on amd64 and i386 but not on the buildd's?
<pitti> build-depends?
<\sh> no
<Kamion> what package?
<\sh> sdcv
<\sh> i tested it on a adm64 box, and it compiled without problems, on my i386 box as well
<Kamion> it's trying to run stuff like gettextize during the build, which it really shouldn't; that's a maintainer tool
<Kamion> timestamp issues on files in the source package?
<Kamion> make sure that your tests involve unpacking the source package, rather than just copying the build tree around
<\sh> Kamion: if I'm not running it, i386 would compile , not no 64bit archs...
<Kamion> and if you're running gettextize in the build, don't
<Kamion> similarly aclocal and automake
<\sh> s/not no/but no/
<\sh> Kamion: so u mean better to make a patch out of it? takin orig source, gettextize, aclocal etc., taking the diff and put it as patch?
<Kamion> that sort of stuff should really be in the upstream source package, but if it isn't, then yes it should be part of the .diff.gz
<Kamion> I don't care which patch system or none you use :)
<\sh> ok..then i will try it the other way around ;)
<bob2> go muine
<bob2> when you pause it, it consumes 100% cpu
<Treenaks> bob2: nice
<Treenaks> bob2: sounds appropriately .NETish
<stockholm> ogra: ?
<stockholm> when is ogra awake?
<Treenaks> stockholm: usually about now
<stockholm> (c:
<stockholm> ok
<koke_> hi all!
<koke_> hey, what do you think about http://koke.amedias.org/img/ooo-splash-ubuntu.png ??
<wm_eddie> It'd be better without the blue "Office" 
<mvo> hey seb128 
<seb128> hi mvo
<pitti> elmo: ping
<pitti> mvo: do you see any problem with adding two new colums "KDE translations" and "Gnome translations" to the langpack selector?
<pitti> Riddell: here?
<mvo> pitti: not really, might be better to automatically install them depending if kde/gnome is installed
<mvo> what do you think? or is this impractiacal?
<pitti> mvo: well, the installer will install them for your primary language
<pitti> mvo: but not for additional languages you might want
<pitti> mvo: it's the same as with the normal language-pack-<lang>
<pitti> mvo: in the future there will be l-pack-gnome-<lang>[-base]  and l-pack-kde-<lang>[-base]  in addition
<mvo> yes, I was thinking that if the user selects "translation" and has gnome installed we may just automatically install the language-pack-gnome-<lang> (same for kde of course)
<pitti> mvo: ah, right, that's even better
<pitti> mvo: hm, but there should still be an interface of any kind; the user might want translated KDE apps he uses under Gnome
<Riddell> mvo's idea sounds good
<mvo> pitti: how many packages does the langpack for kde cover? I assume there is a list? language-detector could use that list to deciede if it needs to install the langpack. 
<pitti> Riddell: since the new langpack-o-matic works now, are you fine with stripping the kde-i18n-<lang> packages now?
<mvo> I mean, adding a column for gnome/kde is no problem, I'm just playing around with ideas
<pitti> mvo: well, right now only 3 apps, but that'll change if we actually strip kde-i18n-xx
<mvo> pitti: what about gnome? how many apps there?
<pitti> mvo: maybe the Gnome/KDE colum is automatically selected if you check translations and are under Gnome/KDE?
<Riddell> pitti: stripping kde-i18n-<lang> seems good
<pitti> mvo: 99 apps for de ATM
<pitti> mvo: (gnome)
<pitti> Riddell: ok, then I upload a new pkgstriptranslations without the KDE blacklist, pester infinity to install it, and then ping you to reupload kde-i18n again?
<Riddell> pitti: ok
<mvo> pitti: could you please send both lists to me? 
<pitti> mvo: yes
<Riddell> mvo: the kde langpack covers a lot of packages, there's no list (a list of course packages would be easy, list of binary packages longer)
<pitti> mvo: for all languages, or is .de as example enough?
<mvo> pitti: does the list vary for different languages?
<pitti> mvo: I only have a list of translation domains per language, not per application or deb
<pitti> mvo: so if there is a German translation for rhythmbox, but not a Spanish one, it would differ
<mvo> ah, I see. this makes things more complicated certainly. please send me the german one as a start then
<mvo> if we have no mapping pkg<->translation domain :/
<pitti> mvo: oh, I have such a mapping, it's generated during import
<pitti> mvo: ah, you mean you want to install the langpack if the user has any such app installed?
<mvo> pitti: yes
<pitti> mvo: great idea :-)
<mvo> :-D
<pitti> mvo: however, the list will change since there are still some stripping issues
<pitti> mvo: http://people.ubuntu.com/~pitti/de-gnome.txt  http://people.ubuntu.com/~pitti/de-kde.txt  http://people.ubuntu.com/~pitti/de-main.txt
<mvo> pitti: that shouldn't be a problem as long language-selector is updated regularly
<pitti> mvo: it won't change any/much more close before the release; I think updating the map in l-s is doable right before the release
* mvo nods
<mvo> pitti: is the mapping pkg<->domain available somewhere too?
<pitti> mvo: http://people.ubuntu.com/~pitti/domain_map.txt
<pitti> mvo: that is a symlink to langpack-o-matic, i. e. updated automatically
<mvo> pitti: thanks
<Mithrandir> smurfix: is your smurflogbot a bit sick? :-)
<ogra> heh
<smurfix> Mithrandir: It's OK now
<smurfix> It managed not to log to the right files :-/
<jsgotangco> heh
<fabbione> smurfix: why are logging the same chans i do?
<fabbione> i think it's a bit pointless :)
<smurfix> fabbione: cause I missed that
<fabbione> ehhe ok
<smurfix> fabbione: which channels *are* you logging?
<smurfix> I'll take mine off them
<fabbione> smurfix: a sec...
<tseng> is it safe to update all this x stuff?
<fabbione> i need to check
<pitti> Hey jbailey 
<pitti> jbailey: btw, do you plan to upload a new glibc soon? maybe we can fix the gettext lookup then
<pitti> infinity: do you have some minutes for me?
<jbailey> pitti: I can do that next week.  I have some high priority tasks for this week.
<Lathiat> daniels: remind me, why is middle click with 2 buttonsdisabled by defualt?
<sandip> My heartfelt thanks to Canonical for shipping 5.04 over to my place for distributing to my local LUG. :) ... to New Delhi, India.
<pitti> erm, jbailey?
<jbailey> pitti: yess'r?
<pitti> jbailey: is there a reason why amd64 and ia64 don't have gettext in libc?
<jbailey> umm, what?
<pitti> jbailey: I banged my head about the question why some stripped translation tarballs are broken
<jbailey> Is this recent breakage or has always been this way?
<pitti> jbailey: I found out that (some?) amd64 and ia64 builds don't install translations, but powerpc and i386 do
<pitti> jbailey: that is broken for quite some time now
<jbailey> oh good.  I was worried that you were saying that I had broken it recently with one of the uploads. =)
<jbailey> Lemme check on it in a moment.
<Keybuk> ok, hct is working again now
<pitti> jbailey: if any 64 bit platform finishes a build as the last one, the stripped tarball is broken
<sabdfl> Keybuk: w00t :-)
<Keybuk> database was wedged up its jacksie with no useful errors
<Keybuk> stub hit it with a wrench
<pitti> seb128: I finally found the reason for the b0rked translation tarballs :-)
<seb128> oh ?
<pitti> seb128: yes, it's not a pkgstriptranslations bug after all, but a libc problem on 64 bit platforms, as it seems
<pitti> seb128: depending on whether a 32 or 64 bit platform buildd finished last, we get a correct or broken tarball
<seb128> k
<Kamion> sandip: you're welcome; share the love. :-)
<thom> mvo: seen:
<thom> debconf: unable to initialize frontend: Gnome
<thom> debconf: (Can't locate object method "new" via package "Text::Iconv" (perhaps you forgot to load "Text::Iconv"?) at /usr/share/perl5/Debconf/Encoding.pm line 57, <> line 24.)
<thom> ?
<thom> or Kamion, either
<Kamion> debconf-i18n unconfigured?
<mvo> thom: not seens yet, when does it happens?
<Kamion> it Depends: libtext-iconv-perl
<Kamion> is this during an upgrade?
<thom> Kamion: during an upgrade, yes. but debconf was upgraded a while ago
<thom> ie, this has been happening for some days
<thom> and no, debconf-i18n is fully installed
* Kamion upgrades a chroot at home in order to avoid using all the pub's bandwidth
<thom> ah
<thom> libtext-iconv-perl appears not actually contain Text/Iconv.pm
<thom> that might explain it
<Kamion> !
<Kamion> b0rked b0rked b0rked
<Kamion> seems fine in the archive
* seb128 kicks find
<Kamion> thom: arch?
<pitti> seb128: it should be fixed in the most recent version?
<Kamion> oh, it's just on amd64
<Kamion> B0RKED
<Kamion> thom: I'll sort it out
<seb128> pitti: the current version has some regression 
<thom> Kamion: oh, rocking. thanks
<pitti> another one?
<seb128> pitti: "find ./ -regex '.*\.so\..?.?$'" used to work, it doesn't
<thom> and yes, was just updating my i386 chroot to see if it occured there
<seb128> pitti: doesn't seems to like the ".?"
<Keybuk> seb128: hct source gdm
<Keybuk> enjoy
<Kamion> ah, I think libtext-iconv-perl/amd64 was caught by the perl MakeMaker bug
<Keybuk> (it was imported after all, there was a missing publishing record so hct couldn't see it)
<seb128> Keybuk: thanks (I've just reworked gdm without it yesterday, but I'll find something else to play :p)
<Keybuk> bah :p  I just spent the last two hours debugging that for you <g>
* Keybuk beats you with a gtk bug
<seb128> I've waited for a few weeks
<Keybuk> true
<Keybuk> that was a fucking strange bug ;)
<seb128> I didn't though it would be fixed today
<seb128> Getting gdm_2.6.0.7.orig.tar.gz
<seb128> it works :)
<pitti> ^ for breezy?
<HiddenWolf> bug#?
<Kamion> thom: no-source-changes rebuild uploaded, should sort it out
<thom> what was the MakeMaker issue?
<thom> thanks
<seb128> pitti: what?
<pitti> seb128: so far I thought hct would only get you hoary packages
<seb128> gdm has not changed since hoary
<seb128> dunno which one is that
<Kamion> thom: Debian bug #312419
<seb128> grumpf, gdm picks /usr/X11R6/include instead of /usr/include ... anybody if that's xorg to blame?
<Lathiat> blame daniels 
<Lathiat> so.. why did gnome remove the run application menu item
<fabbione> seb128: mostlikely :)
<infinity> seb128 : Which buildd (or were all build broken)?
<thom> ah, ouch
<thom> Kamion: thanks
<lbm> breezy kernels != inotifized?
<Keybuk> pitti: I, uh, copied a breezy publishing record <g>
<fabbione> lbm: 2.6.12 has inotify
<ogra> lbm, what makes you think this ?
<seb128> infinity: trying to build a new gdm on my box
<lbm> ogra: 2.6.10 doesn't seem to include it
<fabbione> lbm: inotify in 2.6.10 is dangerous
<ogra> lbm, breezy will user 2.6.12
<ogra> use even
<fabbione> lbm: you can use it at your own risk
<fabbione> lbm: adding inotify as boot options
<fabbione> lbm: but be aware.. it's disabled for a very good reason..
<fabbione> lbm: wrong operation = crash
<lbm> fabbione: oh, maybe i should just give 2.6.12 a try? (do i need inotify boot parm for that one too?)
<Keybuk> pitti: I've asked the Soyuz guys to do another gina run against breezy, though not sure what their ETA is (there's a refactor going on)
<seb128> the config.log has
<seb128> | #include <X11/Intrinsic.h>
<seb128> configure:21246: result: libraries /usr/X11R6/lib, headers /usr/X11R6/include
<fabbione> lbm: if you are running breezy yes.. you can use and test .12, and inotify is enabled by default
<lbm> fabbione: is it, in breezy lingo, fairly stable?
<fabbione> lbm: just keep in mind that 2.6.12 is not final upstream yet.. it's a release candidate
<lbm> sure
<fabbione> lbm: i am using it.. since a while.. i know for sure ipw2100 is broken (due to some upstream problems)
<fabbione> lbm: but i am not aware of other big issues
<lbm> i need ipw2200
<fabbione> ipw2200 is ok.. or should be
<fabbione> i don't own that hardware..so i can't really say
<lbm> so restricted modules is packaged for 2.6.12 too, perfect
<fabbione> no
<fabbione> there is no l-r-m
<ogra> lbm, it might wipe your HD or elope with your girlfriend, but for most people it ran stable until now
<lbm> ogra: last time i tried (mid-hoary-dev-cycle) it ran fairly stable :)
<fabbione> lbm: we might do l-r-m as soon as 2.6.12 will be final upstream
<lbm> fabbione: isn't ipw* part of l-r-m?
<fabbione> lbm: spending too much time during the devel cycle is not worth
<fabbione> lbm: nope.. it's a GPL driver
<fabbione> and it is part of main
<fabbione> + kernel
<lbm> what about the firmware?
<fabbione> lbm: it will work.. trust me
<fabbione> lbm: btw.. where do you live in dk?
<fabbione> <- copenhagen
<lbm> fabbione: i live in the northern part, close to aalborg :)
<fabbione> we should try to get some .dk people for an ubuntu beer
<fabbione> ah ok
<fabbione> a bit far ...
<lbm> fabbione: indeed
<fabbione> i used to live in Aarhus
<lbm> fabbione: no, denmark is a small country, 4 hours and i'll be with you :)
<fabbione> lbm: i know.. i lived here in dk for 5 years now
<lbm> i will move to aarhus later this year, great city don't you think?
<fabbione> i just don't *cough*speak*cough danish
<lbm> fabbione: study?
<lbm> :)
<fabbione> lbm: no.. work
<fabbione> and family
<lbm> it will come
<lbm> okay, may i ask where?
<fabbione> yeah i am starting lessons the 1st of Aug
<fabbione> <fabbione> <- copenhagen
<lbm> i was asking about your employer
<lbm> :)
<fabbione> lbm: you can happily zless /usr/share/doc/linux-source-2.6.10/changelog.Debian.gz
<fabbione> ;)
<ogra> hehe
* fabbione will look extremely arrogant.. but well...
<Kamion> "where" is not a good question to ask when trying to find out who employs somebody around here :)
<fabbione> Kamion: point :)
<lbm> fabbione: hehe :)
<ogra> hmm, is there a reason we dont have python-mathml packaged ?
<ogra> and hydra ?
<lbm> oh, firmwares are included in the kernel image package
<lbm> fabbione: you moved to denmark because of family?
<fabbione> lbm: kinda...
<fabbione> i never hide that she was blonde :)
<fabbione> but i am now married with a brunette ;)
<lbm> fabbione: hehe, we have great girls don't you think? :)
<fabbione> lbm: eheheh :)
<fabbione> anyway.. back to more important stuff
<lbm> fabbione: ;)
<lbm> always nice meeting danes
<fabbione> lbm: Aarhus is a nice city.. a bit too small for my taste
<lbm> let me give 2.6.12 a try
<fabbione> lbm: well. i am italian :)
<fabbione> don't confuse here, eh? ;)
<lbm> fabbione: i like the size
<lbm> fabbione: irc is messy :)
<fabbione> lbm: it's ok really.. you can have a lot of fun there
<lbm> fabbione: great city life i think
* ogra restarts for ne X
<ogra> new
<tseng> elmo: did muine go into new (new binaries)? it built, but isnt on archives
<lamont> daniels: you awake?
<lamont> libx11 Build-Depends: pkgconfig
<pitti> Hi lamont
* lamont must head to work - back on in about 45-60 min
<infinity> lamont : It's more broken than that, I've been hunting.
<infinity> lamont : Even if I get all the missing build-deps in (pkg-config x11proto-kb-dev x11proto-input-dev), it's still broken. :)
<pitti> Hi infinity
<Simira> hi JaneW 
<Kamion> thom: libtext-iconv-perl_1.2-4build1_amd64.deb confirmed fixed
* Kamion rebuilds CDs with that
<thom> Kamion: rocking
<infinity> lamont : Eureka.  Looks like I've got it all fixed.
<robertj> hrmm, I've got a program that is giving me main.c:89: error: DBUS_INTERFACE_ORG_FREEDESKTOP_DBUS undeclared (first use in this function)
<robertj> I downloaded the latest dbus and installed it, but I'm still getting that error, do I have to tell it to use the local one?
<pitti> robertj: interesting, I didn't know that xchat can display inverse text :-)
<robertj> me neither
<robertj> I just copied and pasted from OS X terminal
<robertj> (still can't get dual head to work on my machine at work :(
<mvo> robertj: what program is complaining?
<robertj> avahi
<seb128_> your software is not updated for the current API probably
<robertj> seb128_: ok, so I probably need to regress instead of progress eh?
<robertj> it threw that same error with the breezy version
<seb128_> better to update your software
<robertj> seb128: I'm running avahi from svn and last night's release of dbus
<seb128_> yeah, update the code of your software for the new dbus
<robertj> hehe, a slightly bigger task than I wanted to chew on ;)
<jdong> is it ok for KDE Backports to be compiled against Kubuntu's new hoary-updates 3.4.1 repo?
<jdong> I assume amarok users would be using Kubuntu, and since the 3.4.1 is an official Kubuntu.org repo, it'd be ok
<tseng> it sounds like you would have to widely document that
<tseng> since i dont think hoary-updates is enabled for default installs
<JaneW> Simira: hi
<Riddell> jdong: compile it against KDE 3.4.0 then it'll work for everyone
<jdong> ok, thanks
<skora> ick.
<skora> trollers posting links to goatse in the main channel....meh.
<sivang> wheeee! we switched back to moin?
<tseng> yes, it rocks.
<sivang> tseng: since when?
<tseng> since a few days ago
* sivang nearly cries to find out this exciting news.
<sivang> tseng: did you notice the performance boost ?
<tseng> yes
<tseng> its huge
<tseng> and the theme looks much cleaner as well
<sivang> tseng: oh that's so cool, who the person to bless for?
<lamont__> g'morning
<tseng> sivang: some guy i never heard of before, he posted to -devel
<sivang> tseng: about that he made moin work inside plone/zope ? I mean, sure;ly there has been some porting to do..
<tseng> beats me
<sivang> tseng: well, it's just cool,. I'll go look for that thread
<sivang> morning lamont__ , 'sup?
<Kamion> infinity: is "sentinal" meant to be misspelt that way? (x11proto-core)
<infinity> Kamion : No, I just can't spell.  It's correct in the source, broken in my changelog. :)
<infinity> The next person to touch the changelog is welcome to fix my typos. :)
<infinity> (But the package is fine)
<pitti> infinity: is the quick fix for rescuing langpacks possible?
<infinity> pitti : ... Did I miss a conversation?
<Nafallo> tseng: what's up with muine?
<pitti> infinity: it's in the email
<tseng> Nafallo: i duno
<tseng> Nafallo: it built, its not in the archive
<infinity> pitti : One sent to me? :)
<infinity> pitti : If so, I probably stupidly deleted it in a rage of spam-killing.
<Nafallo> tseng: and no buildlogs either (amd64)
<tseng> well it isnt set for amd64 or something
<elmo> tseng: why are the plugins split out like this?
<Nafallo> tseng: I built it myself and that works.
<tseng> elmo: because thats how the debian developer did it
<tseng> elmo: the trayicon plugin isnt installed by default by the makefile
<elmo> gar
<tseng> and the inotify one I just followed along
<tseng> there are a bunch of external plugins
<pitti> infinity: i bounce it back to you
<Nafallo> tseng: I get segfaults with that plugin enabled ;-)
<Nafallo> tseng: trayicon that is
<elmo> tseng: there's a small (but x 15000 and it adds up) cost to adding extra packages, there needs to be a good reason to do it
<pitti> infinity: bounced; "Subject: Found the reason of broken translation tarballs"
<elmo> if a plugin package comes from upstream source and doesn't have any extra depends, I'm unclear why it's in a separate binary package
<tseng> when i was doing the package locally i made it in the same binary
<elmo> tseng: also, debian doesn't seem to have any muine-plugin packages despite having 0.8.3-1?
<tseng> it was uploaded to unstable split up
<tseng> its in NEW
<elmo> ah, they're in NEW; I suspect/hope an ftp-master will reject it
<infinity> pitti : I'm betting the current scheme just does an scp of the tarball without looking.  I'd have to wrap that to do filesize checking.
<jvw> depends on which camp has the most interesting offer...
<infinity> pitti : WOuld it hurt terribly to wait on getting it fixed properly?
<tseng> elmo: k
<tseng> elmo: i tend to follow the debian way as closely as possible, i can put it back together no problem
<elmo> tseng: don't get me wrong, following debian is a good default - I'm not criticising you, it's their bad split
<infinity> pitti : Another quickfix option is to encode the $ARCH in the tarball filename, so we get 4 instead of 1 and you can pick and choose.
<elmo> tseng: for now, if you could put them back, I'd appreciate it - if it goes into Debian split like it is, feel free to then follow them
<tseng> elmo: k.
<pitti> infinity: well, the langpacks are broken with that and the later we fix it, the later we need to recompile half of the archive
<pitti> infinity: alternatively, would it hurt to just take i386 and ppc tarballs for now?
<pitti> infinity: I doubt that there are many ia64/amd64 specific pacakges with translations
<pitti> infinity: the $ARCH option would be a possible workaround, too
<Kamion> there are a few such in the installer, but they don't count
<infinity> pitti : Well, that would be on your end. :)
<pitti> infinity: *grumpf*, okay, fixing my scripts shouldn't be too hard :-)
<ogra> Riddell, ping
<Riddell> ogra: hi
<ogra> Riddell, 3 probs in ivman
<Riddell> ogra: ok
<ogra> Riddell, missing build-deps on libxml2-dev and on libhal-dev, and you got a spare ${misc:Depends} in the control file
<ogra> Riddell, if you solve these, the package is fine, nice work :)
<Riddell> ogra: cool, thanks
<Riddell> ogra: you missed that it was build-depping on build-essential and the section shouldn't be kde :)
<ogra> Riddell, ouch, true
<infinity> build-dep on build-essential?
<infinity> How... Odd.
<Riddell> infinity: wasnae me, the cdbs control generation did it
<jbailey> infinity: There's some nasty crack that snuck in between uvf and us sync'ing it again. =(
<jbailey> Anyone feel free to upload it (here or in Debian) to remove that build-dep...
<Duck_work> jbailey: synced in svn somewhere ?
<jbailey> Duck_work: I'll merge it to svn sometime after to do a mop up.
<jbailey> Duck_work: I get a nice diff of what's changed between Debian and Ubuntu's packages, so when I sync them, I can see which bits really want to make their way back to Debian.
<jbailey> Ubuntu inherits the changes from Debian quite easily.
<Duck_work> jbailey: ok, so you'll do the doc sync by yourself in a natural way ?
<jbailey> Duck_work: Yup, if you upload it into the Debian package no prob.
<Duck_work> nice :-)
<jbailey> If you want to work with the Ubuntu package directly, that's possible too.
<jbailey> Although involves sponsoring and other stuff until you're much better known by this community.
* jbailey looks up to see what Colin's array CDs are called this time around.
<Duck_work> i don't think that's needed, even if i never reject ubuntu users contacting me because they look at maintainer's field
<bob2> Colony.
<jbailey> bob2: Thanks. =)
<lamont__> jbailey: he could have called them 'Cete's, as well... But chose 'Colony'
<lamont__> although he was pushing for a <mumble> Crow release, so that he could make 'Murder 1' available early on
<Kamion> lamont__: who, me? :-)
<Nafallo> lol
<jbailey> *lol*
<daniels> Lathiat: because the algorithm is broken, and often produces missed keypresses
<mdz> morning
<Nafallo> morning mdz :-)
<Lathiat> daniels: ah right
<daniels> Lathiat: you end up with move-move-move-move-press-release, instead of press-move-move-move-move-release
<daniels> i.e. you can't drag
<Lathiat> who middle click drags? :)
<daniels> it does this with all buttons
<daniels> basically, it waits to see if another click is going to come through, and sends motion events through while doing this
<Lathiat> daniels: uh, really?
<Lathiat> i never noticed that..
<daniels> yeah
<Lathiat> ah right, so its a little late?
<Lathiat> hm
<Lathiat> i also only just noticed
<Lathiat> nautilus has a middle click drag context menu
<Lathiat> :)
* infinity decides that after babysitting xorg all night, it's time for bed.
<daniels> night dude
<daniels> remind me to buy you an ultimate long island some time
<infinity> Yessir.
<bob2> how many fists does that contain?
<daniels> bob2: about six
<daniels> bob2: the one at blue train is really good as well.  last time, infinity had to send his back to get them to add more coke and lemon.
<bob2> hahaha
<infinity> (He's not joking)
* bob2 adds another item to his "things to do in melbourne" list
<\sh> doko: ping
<daniels> bob2: along with jesters and sumo
<bob2> and 24 hour JB
<ogra> mdz, ping
<mdz> ogra: pong
<ogra> mdz, like a short edubuntu update
<ogra> ?
<mdz> ogra: yes, definitely
<pitti> Hi mdz
<pitti> Treenaks: I just uploaded a new eject version which now works with encrypted devices, too. So using the icon right-click now works properly. Testing appreciated :-)
<mdz> pitti: good morning
<fabbione> hey mdz
* Kamion kicks gazpacho
<doko> \sh: pong
<seb128> anybody knows how /etc/X11/default-display-manager is managed?
<seb128> the current value is "/usr/bin/gdm", but gdm has moved the binary to "/usr/sbin/gdm"
<seb128> I'm trying to figure how /etc/X11/default-display-manager should be updated
<ogra> via alternatives ?
<ogra> err update-alternatives
<seb128> random guess? I don't think that's an alternative
<seb128> that's a text file
<mdz> seb128: probably managed the same way as /etc/X11/X
<ogra> seb128, ye, wild guess
<daniels> ogra: for what it's worth, Xlib.h is now in /usr/include/X11
<daniels> seb128: iirc d-d-m is managed via debconf
<mdz> seb128: gdm.postinst updates it
<ogra> daniels, thanks :)
<mdz> as do the other display managers
<seb128> mdz: thanks. I've figured that but I'm trying to find how to force it to update the config ... 
<seb128> # debconf is not a registry, so we only fiddle with the default file if it
<seb128> # does not exist
<mdz> check if its value is /usr/bin/gdm, and if so, change it to /usr/sbin/gdm
<seb128> removing /etc/X11/default-display-manager if is set to /usr/bin/gdm to force its update would be fine?
<seb128> k, what I thought
<seb128> thanks
<\sh> oh lord, sometimes call-center people can be sooo stupid
<mdz> thom: huzzah network-manager in breezy
<Nafallo> yay! :-D
<ogra> YAY
<daniels> does it ... work?
<ogra> daniels, who cares.... its in !
<ogra> :)
<Nafallo> hmm, network-manager-gnome? ;-)
<elmo> mdz: there's a bunch of packages that don't sync - and I'm too lazy to find out why beyond "it's not josie's fault" - mind if I file bugs on them?
<elmo> it usually just involves working out what the problem is, either a non-main package is now building something from main and needs promoted, or there's been orig.tar.gz damage and someone needs to work out how to proceed etc.
<Lathiat> ogra: heh
<Lathiat> ah fuge
<estragon> hello
<Lathiat> i didnt pay attention
<Lathiat> and dist-upgrade just removeda bunch of packages
<Lathiat> like gdm
<Lathiat> :)
<Lathiat> he following packages will be REMOVED:
<Lathiat>   gdm gksu gnome-netstatus-applet gnome-system-monitor gnome-system-tools
<Lathiat>   gnome-volume-manager hwdb-client libgksu1.2-0 libgksuui1.0-0 ubuntu-desktop
<Lathiat>   x-window-system-core xbase-clients xterm
<estragon> i have make a tray with bb
<Lathiat> ah crap
<Lathiat> i didnt mean to paste that
<Lathiat> irssi paste detection needs to work on 3 lines
<mdz> Lathiat: this is a normal (transient) situation in the development branch
<Lathiat> mdz: i know, sorry, like i said, i didnt mean to paste it :)
<Lathiat> i hit the wrong window
<Lathiat> i was saving the list to go back and fix it
<Lathiat> :)
<ogra> Lathiat, the way around that is not to dist-upgrade, use only upgrade and pick the leftovers manually...
<Lathiat> well,usually i pay attention and make sure itsnot doing bad things
<Lathiat> they all install again anyway
<Kamion> Lathiat: /set paste_verify_line_count <whatever>
<Lathiat> Kamion: oh,cool
<Lathiat> that was the best feature irssi ever implemented
<Lathiat> saved me a few times
<Lathiat> interesting, apt wanted to remove those packages so it can upgrade libx11-6/libx11-dev, yet, even if it does, it still holds themback
<mdz> elmo: don't sync?
<elmo> mdz: as in the sync program breaks, deliberately, and they get added to the BROKEN list
<mdz> elmo: what would be an example of a problem which could cause that?  the repository is not maintained correctly?
<mdz> does josie spit out enough information for someone who can't run josie to diagnose it?
<elmo> mdz: I just did?
<mdz> ah, I see
<elmo> mdz: I'd post what josie says to the bug and give a rough indication
<mdz> elmo: ok, sounds fine
<elmo> I mean it's not many and I could do it myself, but I've been saying that for months now
<elmo> ok, thanks
<mdz> elmo: is faad2 one of them?
<elmo>         if pkg == "mozilla-thunderbird" or pkg == "ocrad" or pkg == "gnuradio-core" or pkg == "gtk-smooth-engine" or pkg == "lib
<elmo> ant1.6-java" or pkg == "ncmpc" or pkg == "glade":
<elmo> is the current, unchecked list
<elmo>  think faad2 was blacklisted, which I've just now taken off and am resyncing stuff
<Lathiat> that line is so unpythonic :)
* mvo goes to play hockey
<elmo> aww, man
<elmo> IOError: [Errno ftp error]  421 Too many connections (2) from this IP
<mdz> ogra: I think UniverseCandidates needs an update; it says the package must build on warty :-)
<ogra> oops
<ogra> heh
<elmo> that looks like a urllib bug too, rock on
<Amaranth> urllib bug? can i see? :)
<mdz> urllib or urllib2?
<elmo> urllib
<mdz> daniels: please add your new -dev packages to supported or change stuff to build-dep on them
<daniels> mdz: hm?
<mdz> daniels: incoming
<elmo> mdz: cron.sync hasn't been run since xorg was uploaded with new b-d's?
<elmo> if so, it'll f-p on you
<elmo> err, false-positive
<elmo> my over-acronymn-ing is such a problem
<daniels> i'm so confused
<mdz> you need to o-a less
<mdz> daniels: I will recheck as elmo suggests
<daniels> cool
<daniels> if it doesn't, should I just grab the seeds out of arch and dump them in?
<elmo> no, don't add them to seeds unless they really need to be there
<elmo> unnecessary seedings make baby jesus whine quietly
<mdz> daniels: looks like it's mostly OK after re-germinating
<mdz> these want to fall into universe:  o pm-dev, xlibmesa-glu-dev                                             {xorg}
<daniels> yeah, sounds about right
<daniels> actually, i don't think either of those actually exist anymore
<daniels> if they do, they want to fall into universe, yeah
<mdz> they definitely both exist
<infinity> How's that now?
<infinity> Package: xlibmesa-glu-dev
<infinity> Source: xorg
<infinity> Version: 6.8.2-10
<infinity> That's so not right.
<Kamion> it's no longer built from source
<infinity> Right, so it should be dropped, not moved to universe.
<Kamion> agreed
<dilinger> fg
<elmo> moving to universe is harmless
<elmo> rene's painful atm due to either glibc or the kernel
<elmo> done anyway
<wasabi_> elmo, just want to see if you know about my keyring request. No hurry.
<elmo> wasabi: can you mail keyring@ubuntu.com if you haven't?  that way I won't forget
<wasabi_> oh yes. always forget.
<elmo> and btw, TB people, please tell people to do that when you give them main rights, kthxbye
<wasabi_> my fault. ;)
<wasabi_> I'm just brain damaged.
<elmo> wasabi: nah, it's not your fault, the last 3 main uploaders have all had the same problem
<elmo> anyhoo, so I had this rocking idea when I couldn't sleep last night, and it's probably horribly obvious and/or already specced, but:
<elmo> do we have/plan to have hotplug packages?
<Lathiat> you mean hotplug-ng?
<elmo> dunno.  I mean, when you plug in a HP OfficeJet, hplip should be auto-installed, if it's available, for example
<daniels> elmo: hm
<Lathiat> oh
<Lathiat> i see what you mean
<daniels> elmo: i would expect someone to be saying that
<wasabi_> Wow that's a damned cool idea. ;)
<daniels> elmo: and your reply to be punctuated with profanity and the word 'crack', with a mentioning of the security implications of just installing random (pseudo-random) packages onto their desktop
<daniels> cool as it would be
<elmo> what security implications?  it's packages from ubuntu/main
<Lathiat> whats that package
<wasabi_> Obviously those apps would have to be in main.
<wasabi_> And gpg signed.
<Lathiat> that finds debian packagesthings need
<Lathiat> i assume it does some kind of LD_PRELOAD
<Lathiat> trapping open()
<elmo> Lathiat: that _is_ crack
<Lathiat> elmo: it really is
<daniels> elmo: i can just see people getting a little peeved that packages just wander on to their machine
<elmo> I'm talking about on detection of hardware
<Lathiat> im just curious whatit is
<Mithrandir> Lathiat: auto-apt?
<Lathiat> since you mentioned a similar topic
<elmo> daniels: only hardcore linux guys
<elmo> daniels: real users expect their officejet to just work
<wasabi_> Windows does it. ;)
<daniels> elmo: oh, fo'shizzle
<elmo> and it's not an unreasonable expectation
<daniels> yeah
<Lathiat> elmo: office jet drivers should already be installed?
<elmo> Lathiat: no, they're not
<Lathiat> i mean
<Lathiat> like
<elmo> well, not in hoary
<Lathiat> they _should_ be
<daniels> hmm, i thought hplip was targetted for breezy
<Lathiat> not, they are now
<daniels> we ran with hpoj for hoary and man was that ever a mistake
<daniels> and I am so not asleep right now
* daniels rectifies.
<elmo> daniels: hplip is in breezy and once you install it, the officejet stuff (well scanning anyway) Just Works(tm)
<daniels> elmo: right
<elmo> but AFAIK, hplip isn't targetted for install-by-default
<daniels> elmo: i'm pretty sure it's in desktop tho?
<daniels> gar, still not in bed
<elmo> it's not in current ubuntu-desktop package in breezy at least
<elmo> in any event, hplip/OfficeJet is just an example I dealt with personally in the last 48 hours, I'm sure there's more use cases and packages we don't necessarily want to install by default
<elmo> (I'm surprised we want to do hplip, it adds two daemons)
<wasabi_> One of these days I'll finish my .apt file idea.
<wasabi_> (Where you can open a .apt file from a web site and it will walk you through installing packages described by it.)
<doko> elmo: please sync twisted from unstable
<mdz> Kamion: does it work to specify multiple patterns with debconf-copydb?
<mdz> hmm, no, doesn't look like it
<wasabi_> Hmm. Almost 10 minutes is wasted in Eclipse on compiling SWT for ia64, ppc and sparc.
<wasabi_> on i386. =/
<wasabi_> Heh. It compiles for win32 also.
<mdz> wasabi_: whaa?
<wasabi_> silly build process.
<mdz> wasabi_: compiling SWT for ia64 on i386?  cross-compiling?
<wasabi_> It's indiscriminate about what parts it builds.
<wasabi_> No. It's Java.
<wasabi_> It builds seperate Jars for each.
<mdz> won't they be identical?
<wasabi_> Basically.
<wasabi_> or close to it.
<wasabi_> 64 bit platforms use long for raw pointers.
<mdz> I thought SWT was mostly native code
<wasabi_> the others will be the same.
<wasabi_> No, SWT is mostly not native code.
<wasabi_> SWT is mostly Java with a thin JNI wrapper.
<wasabi_> The SWT code itself is Java. Obviously it uses Gtk.
<Nafallo> yay! network-manager installed and netapplet thrown out :-)
<wasabi_> It's just silly. It doesn't detect what platform it's on and build what it needs.
<Nafallo> thom: thanks! :-)
<wasabi_> It builds everything and then only includes what it needs in the output.
<torkel_> Nafallo: and it seem to be working?
<Nafallo> torkel_: dunno. I'm still online anyway ;-)
<torkel_> :-)
<wasabi_> It's platform specific Java.
<wasabi_> But it's still Java, not native.
<Lathiat> thom: ping
<Nafallo> yikes :-P
<Nafallo> NetworkManager just made my laptop _really_ hot :-)
<Lathiat> so
<Lathiat> how do you actually use NM with nm-gnome?
<Nafallo> I don't know. my syslog got spammed anyway ;-)
<Lathiat> oh, theres an applet now, looks like im being bitten by notification issues again
<Lathiat> brb :)
<Nafallo> hmm
<Nafallo> thom: ping ;-)
<mdz> thom: Depends: bind9?
<Lathiat> hub: interesting
<Lathiat> doh
<Kamion> mdz: no. I suppose I could make it do that if you'd like, but I generally just use a fancier pattern :-)
* Kamion goes out again, having just called in very briefly
<mdz> Kamion: yeah, Perl REs will get me there as well ;-)
<Nafallo> mdz: is it bugzilla or Malone for NetworkManager? :-P
<mdz> Nafallo: there won't be an entry in bugzilla for it yet, since it's in universe
<Nafallo> mdz: oki. thanks :-).
<mdz> Nafallo: considering that it's only been in breezy for a few hours, thom might prefer that you mention something to him if he's around, before filing a bug
<Nafallo> mdz: yea. but he isn't :-/.
<Nafallo> baah, I'll wait for him :-)
<mdz> mjg59: ping?
<mjg59> mdz: Hi
<mdz> mjg59: hey, looking for a status update on LaptopMission for BreezyGoals
<mjg59> mdz: To be sorted at the weekend
<mjg59> (Sorry, life has been relentlessly awkward this week)
<mdz> mjg59: what's the next milestone-or-few?
<mjg59> We have a list of people, I just need to get in touch with them
<mjg59> Then we need to get hardware out
<mjg59> I've got the testing spec pretty much written
<eruin> what's going on wrt sound in breezy?
<mdz> do we have a list of the people documented anywhere?  I assume there are wiki bits to be created
<mdz> eruin: http://udu.wiki.ubuntu.com/AudioInfrastructure
<mjg59> mdz: Afraid not. I'll sort that at the weekend.
<eruin> thanks. I fear I'll have to start collecting data for bug reports :P
<mdz> mjg59: ok, thanks
<mdz> has anyone else experienced firefox violently crashing while moving the cursor in textareas?
<eruin> mdz, have there been any reports about sound playing but in a very dirty (as in noise) fashion, and is that expectable atm you think?
<mdz> it's awfully inconvenient
<mdz> eruin: yes, that's known at the moment, and there are some possible fixes inbound
<eruin> I havent seen anything about it on the list (apart from by myself)
<eruin> ah, great
<mdz> things are, shall we say, in flux :-)
<eruin> hehe
<mdz> eruin: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313378
<mdz> I believe that's the issue you're hearing about
<mdz> which reminds me, I should import it into bugzilla
<eruin> yeah, that's the one
<mdz> now also https://bugzilla.ubuntu.com/show_bug.cgi?id=11903
<mdz> so folks can add themselves to the CC list there for updates
* eruin adds
<whiprush> thom: I _think_ the n-m in the archive built without dhcdbd support, because rebuilding it when dhcdbd is installed works.
<whiprush> DCHDBD_BINARY_PATH is undefined
<whiprush> DHCDBD_BINARY_PATH I mean
<Mithrandir> jamesh: ping?
<Mithrandir> jamesh: on fd#3550; I'm inclined to just drop the caching altogether as you're talking about.. I wonder what's the real reason why Keybuk added it though.
<wasabi_> http://flickr.com/photos/bicherele/18416780/
<wasabi_> haha
<wasabi_> i am so sort.
<wasabi_> i should have thought longer before pasting that
<wasabi_> hope I don't get in trouble. =(
<ogra> wasabi_, was already on planet.... 
<wasabi_> oh was it?
<ogra> yep, jdub posted it
<wasabi_> oh I don't feel nearly as bad as I did then
<whiprush> thom: I've filed 11904 and 11905 under unknown component (bugzilla doesn't have a n-m component yet)
<\sh> hmmm
<\sh>  /etc/network/interfaces was overwritten by my dist-uprade to breezy without asking to do so
<Nafallo> whiprush: thanx, I'll try it :-
<Nafallo> :-)
<eruin> http://pastebin.com/300569 <- how would I go about submitting a bug / gathering bug data for that?
<eruin> Seems to only occur after the system has been up for a while
<eruin> in a hoary environment
<Nafallo> thom: why do we need to dep on bind9? I want to use my lan-server for my internal domain! :-P
<elmo> Nafallo: read the changelog
<Nafallo> elmo: and that should tell me what?
<elmo> ... read it?
<Nafallo> elmo: you don't mean the ubuntupackage? cause I do and bind9 is not mentioned.
<elmo> hum.
<Nafallo> elmo: indeed
<elmo> well, in the first version there was a NEWS.Debian, but that disappeared
<xuzo> nas
<Nafallo> elmo: so you know the answer to the question? :-)
<elmo>   These packages are still quite rough and need a fair amount of work. The main
<elmo>   issues are: 
<elmo> i.e. it's WIP
<elmo>    * Currently, you need to manually kill any preexisting dhclients
<elmo>    * Depends on bind9
<elmo>    * resolv.conf will have interesting potential issues.
<Nafallo> I just rebuilt locally without it. I'll see where this lands ;-).
<seth_k> eruin, you around?
<syndicate> your DNS won't work
<mvo> I uploaded balsa this morning (~12h ago) and it was accepted, but it wasn't attempted to build yet. is there anything wrong?
<elmo> it b-d's on a removed package
<elmo> or the buildds think it does
<elmo> yeah, it still does
<elmo> fix the gtkhtml3.2 dep
<ogra> grmpf
<ogra> seems nm doesnt like pcmcia
<mvo> elmo: thanks, I was fooled by control vs. control.in :/
* ogra wonders since quite a while whats the usecase for control.in
<azeem> ogra: I think I've seen control.in.in.in
<ogra> argh
<ogra> what for ?
<azeem> don't remember
<ogra> no, i mean why ....
<mvo> azeem: arggg
<azeem> the Debian GNOME team uses control.in to populate Uploaders with an up-to-date list
<Nafallo> ogra: and it _depends_ on bind :-P
* Nafallo tried to run without it ;-)
<KaiL_> does anybody know, which driver is selected for a Matrox Parhelia?
#ubuntu-devel 2005-06-24
<jdub> mdz: ping
<Burgundavia> what the heck is Colin Watson's irc nick?
<jsgotangco> Kamion
<wasabi_> Slight problem understanding the .install files used by dh_install.
<wasabi_> What is the root path they are copied from?
<Kamion> Burgundavia: yo?
<Burgundavia> Kamion, someone on the forums, asking about OEM installer
<Kamion> wasabi_: root of the unpacked source package
<Burgundavia> so I mentioned to come and talk to you
<Kamion> Burgundavia: *shrug* will be ready when it's ready :)
<Burgundavia> indeed
<wasabi_> Kamion, Hmm. I'm a bit confused why this used to work.
<wasabi_> I thought I could just put usr/share/foo in the .install file.
<wasabi_> Without preceeding it with debian/tmp
<Kamion> wasabi_: do you mean the left-hand side or the right-hand side of the line?
<wasabi_> Left handed side.
<wasabi_> Without a right handed side
<Kamion> wasabi_: you're using --autodest?
<wasabi_> I am using cdbs.
<Kamion> or --sourcedir?
<wasabi_> Doesn't look like that's being passed.
<Kamion> oh, who knows what that does
* Kamion only does debhelper
<wasabi_> Heh.
<wasabi_> dh_install -peclipse-platform
<wasabi_> cp: cannot stat `./usr/share/eclipse/eclipse.ini': No such file or directory
<wasabi_> This is odd because I swear I've done this, with cdbs, before.
<Kamion> use DH_VERBOSE to see what it's doing
<Kamion> perhaps you need to use --sourcedir if ./usr/share/eclipse/eclipse.ini doesn't exist relative to the root of the source package you're building in
<Duck_busy> coin
<wasabi_> Heh.
<wasabi_> It does a bunch of files.
<wasabi_> But just doesn't do this one. This one is a symlink.
<Duck_busy> wasabi_: use .links then ?
<wasabi_> Yeah. That just means part of the logic for creating the symlink is in rules and part isn't.
<wasabi_> This thing always beats my ass.
<wasabi_> Duck_busy, okay... how about this. I have removed all the complicated parts. I have only usr/share/eclipse/eclipse.ini listed in .install.
<wasabi_> And it's saying not found.
<wasabi_> This has worked before without me having to tell it what the sourcedir is.
<Duck_busy> hum
<Duck_busy> was in debian/tmp/ but is now in debian/<pkg>/ ?
<Jerrac> I was told on the forums to talk to Kamion or mdz about my request. Are they here?
<wasabi_> jhaltom@station-1:/dev/shm/eclipse/eclipse-3.1~RC2$ ls debian/tmp/usr/share/eclipse/eclipse.ini
<wasabi_> debian/tmp/usr/share/eclipse/eclipse.ini
<Kamion> Jerrac: I'm here, but about to be dragged off to bed
<Jerrac> ah, ok. maybe I can be quick then.
<Kamion> so if it's not a one-line-answer thing it'll probably have to wait :)
<Duck_busy> wasabi_: then using debian/tmp/usr/share/eclipse/eclipse.ini should strip debian/tmp and be ok
<Jerrac> Here is my post:
<Jerrac> I see that there is going to be an OEMInstaller: http://udu.wiki.ubuntu.com/OEMInstaller
<Jerrac> I am working on a Ubuntu based computer to sell on ebay, the one thing I am having problems with is an easy way for the buyer to change the default username and password I have to put on with Hoary.
<Jerrac> Is there a way I could use part of the current OEMInstaller to create a script that the buy could run when they first start the computer? As in they log in under the default username and then click the script to run it.
<Jerrac> Thanks!!
<wasabi_> Duck_busy, I have to put debian/tmp in .install?
<wasabi_> See, I've just never had to do that before.
<Kamion> Jerrac: there isn't a "current OEMInstaller"
<Duck_busy> wasabi_: yes sir
<wasabi_> I used ot be able to just plain list "usr/share/eclipse/eclipse.ini"
<Jerrac> Is there some code I could use to do what I want?
<wasabi_> wihtout a leading /
<Duck_busy> did u used .files instead of .install ?
<wasabi_> NOpe.
<Jerrac> Or do you have any other suggestions?
<Duck_busy> wasabi_: or dh_install --autodest ?
<wasabi_> I've done this previously with cdbs
<Kamion> Jerrac: not really, if I were you I'd install without creating a user (you can do this by setting the root password instead) and run dpkg-reconfigure passwd afterwards
<wasabi_> without touching the dh_install logic at all
<Duck_busy> wasabi_: why stop using cdbs ?
<wasabi_> I am using cdbs. I haven't stopped.
<Kamion> Jerrac: but the work basically just hasn't been done yet, so you'll have to do a certain amount of stuff yourself
<wasabi_> Actually I'm converting a non-cdbs package to cdbs
<Duck_busy> perhaps cdbs logic changed then
<Jerrac> yah, i figured that.
<Duck_busy> but is am not aware of such changes
<Jerrac> How do I bypass creating a user in the install?
<Kamion> Jerrac: like I say, set the root password
<Duck_busy> wasabi_: ask jbailey tomorrow about it
<Duck_busy> he will be able to tell you if anything changed
<Jerrac> ok, thanks. I will try to figure that out. :D
<Duck_busy> he is cdbs main author
<Kamion> Jerrac: if you're working interactively, use expert mode and you'll see it
<wasabi_> yeah
<wasabi_> I'm looking at this package right here... java-common
<Kamion> Jerrac: otherwise, preseeding/kickstart can do it
<wasabi_> In it's .install it lists etc/jvm
<wasabi_> in it's rules it lists dh_install -i
<Jerrac> ok, thanks! 
<wasabi_> and that's it
<Kamion> anyway, got to go ...
<Jerrac> I will go work on it more. :D
<Jerrac>  Have a good evening!
<Kamion> ta
<Duck_busy> wasabi_: compat level is ?
<wasabi_> oooh. ones doesn't have it listed.
<wasabi_> the one that is broken is 4
<Duck_busy> here it is
<Duck_busy> old behavior was .files compat stuff with like --sourcedir=debian/tmp i'm sure
<wasabi_> ahh.
<wasabi_> okay. that probably explains it.
<Duck_busy> wasabi_: try using : DEB_DH_INSTALL_ARGS := --sourcedir=debian/tmp
<Duck_busy> if you don't want to modify your .install files
<wasabi_> I'll just put debian/tmp in front of everything
<wasabi_> my install files need to copy from debian/extra also.
<Duck_busy> ok
<thom> whiprush: feh, feh, feh
<Nafallo> thom: hi :-)
<thom> Nafallo: you're welcome to, ensure that your dhcp server gives out the right details and you will
<Nafallo> thom: it's way more complex than that I'm afraid ;-)
<Nafallo> thom: my domain exists both outside and inside my network (with different ips assigned) 
<Nafallo> thom: I want to use the internal dns when I'm at home and whatever dns I get when I'm away.
<thom> Nafallo: so? if your dhcp server gives out the correct nameservers, then NM will configure bind9 to use them
<Nafallo> thom: this new setup breaks that :-/
<thom> Nafallo: i don't see how, at all
<Duck_busy> good night folks
<elmo> man, mdz's got his joeyh-game-face on for ubuntu uploads
<thom> Nafallo: all bind9 is being used for by NM is as a caching nameserver that it can reconfigure based on the instructions it recieves from dhcp
<wasabi_> oh darn dh_install can't rename
<thom> yes, it totally sucks that it has to be bind9; there're moves afoot to fix that. but that's not the issue here
<Nafallo> thom: hmm, and the instruction is not the options domain-name-servers and domain-name?
<thom> Nafallo: if it's not working, you're probably seeing the result of 11905
<thom> which i will fix in the morning
* seth_k is away: out
<Nafallo> thom: I've recompiled with that package as build-dep :-)
<Nafallo> thom: ehm. let me check something ;-)
<thom> well, what does "grep forwarders /var/lib/NetworkManager/NetworkManager-named.conf" give you?
<Nafallo> thom: right now I've screwed the config a bit. but that has indeed the correct forwarder :-)
<thom> and your /etc/resolv.conf has 127.0.0.1?
<Nafallo> thom: yes
<thom> then i don't see what the problem is? i'll fix the two bugs whiprush reported in the morning
<Nafallo> thom: before I didn't got the correct forwarder set, cause I couldn't find my own domain.
<sabdfl> http://help-info.de/en/Help_Info_Longhorn/longhorn_help_pane.htm
<sabdfl> "Ask Your Community"
<sabdfl> can you say... launchpadIntegration?
<Nafallo> thom: right now I'm happy you came online so that I can test it again :-)
<Nafallo> thom: thanx for explaining :-)
<thom> np
<thom> mdz: i'm not keen on bind9 being necessary; i'm going to chase down what changes are needed for lwresd to be suitable and work on them tomorrow
* seth_k is back.
<Unfrgiven> what does "CCDEPMODE = depmode=gcc3" mean in makefiles? im trying to build a package right now that seems to want gcc-3.4 and I have a feeling its because of the depmode
<mako> http://finaperf.com/annuaire/
<mako> nice logo
<mako> http://finaperf.com/images/logo-finaperf.png
<tseng> mako: circle of ripoffs
<mdke> mako, did you see the msn one too?
<mako> dude, people mail me about the MSN one at least 4-5 times a week
<mdke> oh sorry
<mako> ALL THE TIME
* mdke buries himself in the ground
<mako> everybody else did too apparently :)
<mako> well, it's fine.. you don't read my email :)
<mdke> that's what you think
<mako> i get trademarks@ubuntu.com
<mdke> ah that explains it
<mako> so i see it all 
* Clint stops reading mako's email.
<mako> Clint: fine with me.. answer some of it will you
<mdke> mako, one day i will apply to be a lawyer at Canonical ;)
<mako> mdke: then i get to forward to this stuff to you :)
<mdke> *grins*
<Unfrgiven> anyone have a link for the msn one?
<mako> better yet, my email will BE your email
<mdke> Unfrgiven, hang on, it is on someone's blog
<azeem> it's in mako's mailbox
<jsgotangco> i love the backports logo
<jsgotangco> reminds me of bizarro
<Unfrgiven> jsgotangco: link?
<mako> Unfrgiven: it's msn-spaces
<jsgotangco> its basically the ubuntu logo in blue and the dots are inside
<mako> azeem: my inbox is a scary scary place
<azeem> I can imagine
<mdke> Unfrgiven, http://blog.carthik.net/vault/2005/04/14/msn-spaces-and-ubuntus-logo/
<azeem> mine already looks quite scary
<mdke> whoops
<mdke> Unfrgiven, sorry, follow the link to http://people.warp.es/~jorge/blog/?p=38
<Unfrgiven> woah!
<jsgotangco> heh
<jsgotangco> mdke, become Ubuntu's favorite Barrister
<Unfrgiven> jsgotangco: the backports logo is pretty neat!
<mdke> jsgotangco, what can i say, it would be my dream job
<mdke> mako, so what is the answer to the msn-spaces trademark thing? i'm curious
<jsgotangco> Unfrgiven, yeah, totally Bizarro
<mako> mdke: the answer is we're not doing anything about it now
<mako> i've told mark and jane
<mako> and i guess we're sitting on it
<mako> we're registering the mark as many places as we can
* mako shrugs
<mdke> hmm
<mdke> you also have copyright in it
<mako> we were there first
<mako> well, that's going to really impact any dilution suit
<jsgotangco> Barrister, please give your pro bono opinion
<jsgotangco> heh
<mdke> i'm not great on copyright
<mako> personally, i'm happy with MSN using their little pudgy friends thing
<mdke> that's why I'm interested
* mdke nods
<mako> what i'm worried about is that they will sue *us* just as a way to hurt us
<mdke> mako, well if they do you can respond
<mako> ultimately, it's up to mark and/or his lawyers
<mako> if they think we're safe, great
<mako> i suspect it's a "how long is this string" sort of thing
<mdke> jsgotangco, its basically a question of whether they WANT to do anything about it, its pretty clear that they can do if they want
<mako> we'll be able to find folks on either things
* mdke nods
<mako> i mean, MS can sue for stupid things with or without the logo
<mdke> are mark's lawyers SA based?
<mako> some of them (e.g., patents, etc) probably more promising than this :)
<mako> i have no idea
<mako> mark doesn't talk about his lawyers very much :)
<mdke> LOL
<mako> i mean, even in situations where i think he would, he doesn't
<mako> like, his bankers.. sure.. lawyers not so much
<mdke> interesting
<mdke> we're not a popular race
<mako> i have a disproportionately large number of friends among your ilk
<mdke> yeah i am not surprised
<mdke> i've read your blog
<mako> at least one of them is trying to recruit me
<tseng> mdke: you should read it daily
<mdke> tseng, alright
<tseng> heh, he stopped updating it
<tseng> but its always great
<mako> tseng: no way dude.. 1 week break
<mako> i'm recouping my strength
<mako> i posted yesterday
<tseng> ill await your triumphant return to the blogosphere
<mako> oh man.. it's gotta be good
<mdke> *grins*
<mdke> pressure!
<mako> i need to invent a game
<mdke> night all
<tseng> cya
<mako> oh man.. i thought of a good one
<jsgotangco> i want to hear that
<tseng> mako: my recent favorite was about eating pennies
<mako> not really a game.. but sort of
<mako> i am going to write poetry using only the names of packages
<mako> this will be great
<jsgotangco> oh no
<jsgotangco> this reminds me so much of magnetic poetry
<mako> jsgotangco: i'm pretty good at magnetic poetry
<jsgotangco> "synergistic action"
<jsgotangco> "we come"
<mako> that was long
<mako> it was an epic
<mako> move over homer
<jsgotangco> hah
<mako> there are a lot of packages
<mako> i'm still at b
<jsgotangco> hmm probably around 17,000
<mdz> mako: you should write a poem using each of them exactly once
* daniels blinks at findutils.
<mdz> except the ones containing the letter 'e'
<jsgotangco> go beat dr. seuss
<mako> mdz: well, i'm going to have it make sense.. so i'm using the ones that are or could be read as real words out of context
<jdub> you *have* to use apt
<mako> jdub: i'm gonna to do better
<jdub> it's just a good real word
<mako> jdub: BETTER.. you'll see
<mako> i'm going to write several
<mdz> mako: apt-cache dumpavail | grep-dctrl -nsPackage '' | sort | comm -12 /usr/share/dict/words
<mako> i'm going to write one in honor of sarge
<mako> mdz: nah.. i'm not *just* using the real words
<jdub> are you going to ignore numbers in names?
<mako> mdz: i'm also using ones that *could* be read as real words
<mako> like apoo
<mako> "that software is totally apoo"
<jsgotangco> how about emacs
<jsgotangco> or gpg
<jsgotangco> heh
<mako> nope
<mako> probably not
<mako> dude, there are a lot of words to choose from
<jdub> mako: zenity :)
<jsgotangco> the zenity of it all....
<mako> mdz: i will do that to make sure i didn't miss any
<mdz> jdub: what's wrong with apt?
<mako> hmm.. cccc, maintained by Kamion 
<mdz> mako: ah, right, you can use some of them phonetically
<mdz> the enthusiastic spaniard said "cccc"
<mako> or compound words
<mako> exactly
<jdub> mdz: i was praising it as an excellent word
<mdz> jdub: oh, I misinterpreted you
<mako> oh, howa bout "cduce"
<jdub> mako: so you couldn't use 'man', for instance?
<mako> as in, "cduce me"
<jsgotangco> sounds like an sms acronym heh
<mako> jdub: no, i'm using both real words and sound-alikes
<mako> i will probaly use man
<jdub> man isn't a package though
<mako> 'an' 'and'
<jsgotangco> "cduce me, it feels so apoo"
<mako> ah, you're correct
<mako> damnit
<mako> so, no, i won't
<jdub> aha
<jdub> it is rad that 'the' exists
<jdub> so you could say package names and 1 or 2 letter words
<mako> i'm happy about that
<tseng> as does wtf
<jdub> tseng: haha!
<mako> dude, cheesetracker!?
<jdub> $ apt-cache show bbq
<jdub> W: Unable to locate package bbq
<jdub> E: No packages found
<jdub> cock!
<mdz> CHEESETRACKER??
<mako> oh man
<mako> totally NOT a cheesetracker
<tseng> $ apt-cache show cock 
<tseng> whiprush: Unable to locate package cock
<tseng> elmo: No packages found
<tseng> buh ironwolf you suck ass
<tseng> irssi!
<mdz> there are 660 package names which are also in dict/web2
<tseng> gosh stupid thing.
<mdz> that is a pretty big vocabulary by itself
<mako> mdz: awesome
<tseng> ironwolf: sorry :(
<mako> mdz: yes, it is
<jdub> mdz: hrm, so that doesn't catch packages that are multiple real words with or without a hyphen. hmm.
<mako> mdz: how did you get that list?
<mdz> mako: amphetamine
<mako> mdz: have it
<mdz> mako: apt-cache pkgnames |sort | comm -12 /usr/share/dict/words
<jdub> mako: will you let yourself pluralise if it's just a matter of adding 's'?
<mako> oh, i already did that
<mdz> mako: apt-cache pkgnames |sort | comm -12 /usr/share/dict/words -
<mdz> there is a distinct lack of adjectives, though
<mdz> predominantly nouns
<jdub> how is apt-proxy2 going?
<jdub> hrm, ww
<mdz> the august zebra thrust straw at the zoo
* mako giggles
<jdub> *snicker*
<mako> i'm going to write three
<mako> one about sarge, one about politics and one about sex
<mdz> in haiku form?
<mako> no
<mdz> :'-(
<mako> i MAY try to make the sarge one a limerick
<mako> (!!!)
<jdub> mako: august has gotta be a sarge word ;)
<mako> jdub: ok
<mako> LIMERICK DUDE
<mako> THATS LIKE FUCKING IMPOSSIBLE
<jdub> is there a Free rhyming dictionary?
<jdub> i have one on my shelf
<jdub> but i can't grep it
<mako> jdub: not that i've found
<mdz> the bamboo beast felt evolution outguess muscle
<jdub> ha ha
<jsgotangco> jeezz
<mako> watch out for hte bambee beast
<mdz> mako: I don't know where you got this idea, but I hope there was whiskey involved
<mako> i am also not going to repeat words
<jdub> mako: 'the'? :)
<jdub> $ apt-cache show rules
<jdub> W: Unable to locate package rules
<jdub> d'oh
<mdz> mako: your limerick claim sounds like a challenge
<jdub> rocks!
<jdub> haha
<jdub> Description: Make network sockets reliable in a transparent way
<mako> mdz: dude, let me get mine out the door
<mako> i'm still on 'c'
<mdz> oh, interesting, web2 doesn't have plurals in it
<jdub> wow, rocks looks interesting
<mako> hahah
<mako> jdub: it DOES have 'coq'
<mako> COQ
<jdub> haha!
<mako> and coq-doc
<tseng> just in case you needed instruction on proper care of your coq
<mako> exactly
<mako> my potty poem involves: cpp! apoo!
<jdub> heh
<jdub> tseng: "first, remove extraneous packaging" ;)
<mdz> we should have packages named after all of the words in Jabberwocky
<mdz> the next time I don't know what to name something, I will choose one of those
<mdz> we already have bandersnatch
<jdub> s/don't know what/need/
<mdz> jdub: those are equivalent
<jdub> heh
<mdz> I _never_ know what to name programs
<jdub> casper was inspired
<jdub> although it wasn't actually inspired
<mdz> I lost like a week of work on that one
<mdz> LTSP wouldn't even be started yet if it hadn't already had a name
<jdub> is express remotely close to CD testing?
<tseng> ltsp puts release-early-release-often into full effect
<mdz> jdub: hmm?
<mako> i actually wrote a section of a howto on how to name packagesonce
<jdub> mdz: ubuntu express, live installer
<mdz> jdub: oh, "is ubuntu-express ready for people to test it"
<jdub> yeah
<mdz> jdub: I read that as "is ubuntu-express a good test of a CD" :-)
<jdub> wow, traffic to archive blows from here atm
<jdub> mdz: ah, heh, d'oh ;)
<mdz> jdub: it doesn't install the boot loader
<mdz> but is otherwise functional, if raw
<jdub> nice
<jdub> we could write a poem about six month release cycles
<jdub> to catch the ubuntu-express!
<mdz> it would be nice if, when one logs out of GNOME, if all of the processes in one's session exited
<mdz> haha
<mdz> I did not anticipate the train metaphors when I came up with that name
<mdz> the press will be all over it
<jdub> heh, yeah
<jdub> Catch the Ubuntu 5.10 Express!
<tseng> not if lugradio doesnt ruin it first
<jdub> mdz: what's not dying for you?
<mdz> 21886 ?        Ss     0:00 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=17
<jdub> did we convince daniels about xlibs-dev depending on all the dev packages?
<mdz> 21889 ?        S      0:00 /usr/lib/control-center/gnome-settings-daemon --oaf-activate-iid=OAFIID:GNOME_SettingsDaemon --oaf-ior-fd
<mdz> 21892 ?        S      0:00 /usr/lib/gamin/gam_server
<mdz> 21903 ?        S      0:00 xscreensaver -nosplash
<jdub> "transitional package" -> grr.
<jdub> mdz: ouch!
<mdz> I wonder how gdm handles this
<mdz> I bet it resets the X server after the session leader exits
<mdz> which kills their connections to the X server, causing them to exit
<daniels> jdub: xlibs-dev will never grow more dependencies.  ever.
<daniels> jdub: that being said, I haven't actively *removed* any dependencies ...
<jdub> daniels: we need a meta package tho
<mdz> jdub: we do?
<jdub> it would be handy for anyone building against X stuff who doesn't really grok all of X
<mdz> having one for compatibility purposes seems OK, but do we really need a metapackage for everyhting going forward?
<tseng> jdub: apt-get build-dep, dude
<jdub> perhaps a task, but i haven't really bought in to the task thing
<mdz> jdub: by that logic, we should have a metapackage of all -dev packages in Ubuntu ;-)
<jdub> tseng: outside package land
<jdub> mdz: YEAH THAT TOO!
<jdub> no
<jdub> i mean
* mdz lowers his fist of IRON
<jdub> random dude using jhbuild or something
<mdz> dude, jhbuild ought to be packaged
<mdz> and depend on all the build-deps
<tseng> jhbuild should list debian deps
* mdz gesticulates wildly
<tseng> garnome used to iirc
<jdub> suddenly their gnome doesn't have xinerama support
<jdub> mdz: i appreciate your enthusiasm, but... ;)
<tseng> besides that sebuild has obsoleted jhbuild
<daniels> jdub: i think the entire concept of a metapackage is broken
<daniels> jdub: user convenience will turn into packages b-d'ing on every single x library in existence because a) they can and b) they can't be arsed working out which libraries they depend on
<daniels> (metapackage broken -> in this case, not in general)
<jdub> daniels: but you can see the issue with xinerama and friends
<daniels> jdub: that's actually a separate issue
<daniels> jdub: where it used to be in xlibs-static-dev, and I intentionally broke something that used to work
<mdz> jdub: we don't do this for gnome, or jakarta, or anything else I can think of.  why X, now that it's split up?
<jdub> mdz: primarily because there are a lot of optional depends on X things
<jdub> i don't know if this is the right solution
<jdub> i think we need something like it for gnome
<tseng>  man we need a monopod package
<jdub> but for different reasons
<mdz> I think that if anything, we should have a grouping of development libraries for everything in desktop
<jdub> tseng: it has such a bad name!
<daniels> eh, imo if you want xinerama functionality, just hardcode --enable-xinerama, or whatever
<tseng> jdub: dude think of 3 pees in a pod
<tseng> jdub: but with 2 less pees
<daniels> that way, if libXinerama would ever fall out of a package it was in (hypothetically), you would just have a hard build failure, not a silent failure to use Xinerama
<jdub> daniels: most configure scripts check, it says no, they continue on -> optional depends
<mdz> would it be worthwhile to load powernowd on thin clients?  what portion of thin client-ish hardware is likely to support frequency scaling?
<jdub> daniels: now, we can do things to make sure we don't miss these in ubuntu
<daniels> jdub: right, but if you use --enable-xinerama or whatever, you break when these things disappear
<daniels> instead of just silently stop using it
<jdub> mdz: do those via chips do power scaling?
<daniels> i think this is a general best-practice thing, not just for ubuntu
<mdz> jdub: dunno
<jdub> daniels: Common Man doesn't care to do that
<jdub> mdz: mjg might know
<infinity> mdz : A lot of smaller all-in-one systems will (and have) ship with CPUs that can frequency scale.
<mdz> jdub: yeah, but he also might be asleep
<jdub> most of the thin client things i've seen have via c3s or laptopish cpus
<infinity> mdz : And for machines that spend a lot of their time doing very little (which thin clients tend to do), it may be a win to have half your network at low power.
<mdz> jdub: that, and recycled 10-year-old desktops
<jdub> oh, well, yeah
<infinity> (What I don't know is if powernowd supports frequency scaling of VIA CPUs, which do support it at the hardware level)
<mdz> infinity: well, there's "might be handy in some deployments" and "should be there by default"
<daniels> jdub: arguably Common Man shouldn't be maintaining stuff in main?
<infinity> jdub : The CPUs definitely do.  I don't know if the package supports them.
<jdub> mdz: i'd say there by default, removeable :)
<jdub> daniels: building stuff, dude
<jdub> daniels: nothing to do with ubuntu land
<daniels> jdub: i think mdz's idea is a good one
<jdub> i'm definitely not saying packages should b-d on a metapackage
<jdub> yeah, though i'm not sure about tasks
<jdub> but there should be a way for someone to say "I want to build my kernel" -> zap
<daniels> er
<jdub> "I want to write a GNOME app" -> zap
<daniels> 'I WANT LESS SECURITY SUPPORT"
<mdz> jdub: that is totally a build-dep use case
<daniels> 'make that really easy'
<jdub> mdz: i'm not thinking in terms of ubuntu land
<jdub> consider dude who wants to build jhbuild
<mdz> the one I'm driving at is sort of the traditional unix "if you install something, you have the development bits too" semantic
<jdub> or write a gnome app
<mdz> jdub: everything should be part of ubuntu land!
<mdz> there is no other
<jdub> "i appreciate your enthusiasm, but..." ;)
<mdz> I'm not keen on optimizing for the case of unpackaged software
<mdz> I'd rather it be a pain, to drive people into packaging ;-)
<jdub> mdz: whoa, so one bit flip that says "i am a developer" and everything comes with related -dev?
<jdub> or mark's idea of making sure related packages are installed
<mdz> jdub: the former
<jdub> if you have php and mysql installed, you should get the bindings
<mdz> I haven't actually evaluated the list of packages which would result; it might be crack
<mdz> but I think there's a greatest common factor "development STUFF" that we could do
<jdub> ^ expression of idea, not statement ;)
<mdz> which is like "what you expect to have"
<jdub> mdz: particularly if it stressed the interfaces we support
<mdz> we'd just have to add a jennifer check to reject packages which build-depend on it ;-)
<jdub> should these things be packages at all?
<jdub> what was the spec for fixing meta?
<daniels> yeah, if anyone b-ds on it, I will file bugs every hour until it is fixed
<jdub> daniels: you are so debian-devel
<daniels> and then every two hours afterwareds out of spite, until I get bored
<daniels> jdub: i hope the irony of saying that to a canonical employee in #ubuntu-devel hasn't escaped you, given threads of late
<daniels> also, I haven't used any profanities in this discussion
<jdub> i was counting on those ironies
<infinity> (... yet)
<daniels> jdub: and it's irony that's why we can't ship a x-development package
<daniels> hth, hand, kthxbye
<daniels> but, uhm, yeah
<daniels> can we not use the task mechanism for this?
<infinity> Tasks and metapackages are all about "all or nothing", though.
<infinity> So, I say "I'm a developer" and I get every lib*{,-dev} in the archive?
<infinity> That's very not keen.
<jdub> it's odd that ian thinks glibc is too much divergence, but xorg and gnome aren't
<jdub> infinity: for stuff you install
<infinity> I want a switch that automatically makes sure I have a matching -dev for every lib I have installed, but not for ones I don't.
<infinity> Which would require a bit more magic than tasks or metapackages.
<jdub> yes, that's what we were talking about
<infinity> To do it elegantly, it would require a new control field.
<infinity> Headers: libfoo-dev
<infinity> So when I install Package:, I get it's Headers:, if I want them.
<infinity> Or something.
<infinity> s/it's/its/... I can hear English teachers around the world screaming even now.
<daniels> jdub: no dude, there's GOOD divergence (innovation), and BAD divergence
<daniels> jdub: afaict, sid has all the bad divergence.  from itself. :)
<infinity> (Of course, that control field can be added after the fact with ftpmaster overrides, so we don't have to touch each source package, initially)
<daniels> infinity: dude, it's SUPERKEEN
<infinity> daniels : Shall we get xorg building on i386 today?
<infinity> daniels : I fear version skew and archive oddities until we get it happy again.
* daniels looks at infinity, over at his xorg build whizzing away, back at infinity.
<infinity> Check. :)
<infinity> Yay.
<infinity> Thanks.
<daniels> ARE WE THERE YET?!? :)
<infinity> Can I have an ice cream?
<daniels> infinity: Not until you've eaten all your pumpkin, broccoli, and zucchini.
<infinity> <giggle>
* infinity notes that this "instal all headers" thing comes with other issues.
<infinity> Like, you can have 12 versions of libdbXX installed, but only one libdb-dev.
<daniels> well, it's not like anyone ever uses multiple versions of libdb
<daniels> maybe you could have a Prefers header on your -dev, to make it the first of a conflicting set of packages
<daniels> either that, or have apt's dependency resolver work out which one will involve removing the least packages.
<daniels> which should actually be fairly trivial
<infinity> apt's dependency resolver is black magic that no sane man (hi mdz!) wants to touch. :)
<daniels> infinity: it's actually reasonably easy to do in this case.
* mdz <-- sane
<infinity> Yeah, I know.  I just knee-jerk when anyone suggests diving into Culus's code.
<daniels> instead of calling markRemove() on every package, you just increment a counter in an array of strings (or packages)
* mdz <-- does not know how to solve SAT-3 in polynomial time
<daniels> either that, or just have a list of packages to be removed for every package installed
<Keybuk> I thought mvo was the APT maintainer these days? :p
<daniels> then just pick the shortest one and install that
<infinity> Keybuk : Not by choice, I'm sure. :)
<daniels> hm, leaving in 5 hours or so.  probably should investigate this 'packing' theory.
<Keybuk> bring back the dselect FTP method
<daniels> Keybuk: dpkg-ftp!
<daniels> hm.  on that note, wonder how I'll get to the airport.
<Keybuk> where you going?
<infinity> He's skipping the country to get out of the drinks he owes me.
<daniels> eh, don't you still have Coopers in your fridge? :)
<daniels> Keybuk: the only possible answer to this is 'your mum's house'
<infinity> No.  It kinda went away.
<infinity> (What?... it wasn't going to drink itself)
<daniels> well, there's your answer
<infinity> daniels : If your xorg stuff still isn't building by the time you have to find your way to the airport, care to dump your working directory in my lap, so I can fix it up?
<daniels> infinity: don't have to leave for about 5 hours yet, so it would take a fairly tremendous effort, but yeah, will do
<Keybuk> CHECKSUM FILE(S) DISAGREE WITH DIRECTORY LISTING ABOUT WHAT FILES SHOULD BE PRESENT IN REVISION DIR OF ARCHIVE
<Keybuk> oh yes, I know this one
<Keybuk> it means I'm doing more than one thing at once to the same archive
<Keybuk> bad me, I should do less
<daniels> haha
<daniels> dad's sitting downstairs eating tuna out of the tin
<mako> daniels: i've done that
<mako> oinkmaster
<Keybuk> is that a euphemism for something?
<daniels> /etc/gdm/Xsession invoves #!/bin/ksh but does not have a depenedency on pdksh
<daniels> not any other corn shell. Suggestions would be to add this dependancy or replace
<daniels> the script with on that calls /bin/sh
<daniels> SSSSEEEEEEEEEEEEBBBBBBBBBBBBBBBBBBBBBBBB
<daniels> infinity: seemed to work fine on amd64 here, doing a chroot test now
<daniels> infinity: i can throw you a version if you want to do an i386 chroot test?
<infinity> daniels : Well, it built on amd64 before, so you proved nothing. :)
<infinity> daniels : Unless you turned on the via driver on amd64 in this version..
<daniels> infinity: yeah, good point
<daniels> (nope, not yet, but I might on the next CVS pull, since they allege it's hopefully less broken)
<infinity> (Which isn't an entirely insane idea)
<infinity> And disable it on ia64, while you're at it.
<infinity> The idea of an ia64 machine with a VIA embedded video chipset seems laughable to me.
* Amaranth doesn't see an ia64 using a via video chipset
<Amaranth> yeah
<daniels> stop oppressing ia64 users
<daniels> infinity: so ... got a fast i386 around? :)
<infinity> It's in the mail.
<daniels> wonder if I should feed libxext to the dogs of war^W^W^Warchive
<infinity> (I can spin it on a buildd)
<daniels> that'd be good if you could throw them both in locally
<daniels> libxext is in chinstrap:~daniels (well, scping now)
<daniels> there you go, have a libxext
<daniels> this time I even used B-D rather than B-D-I
<infinity> Good boy.
<daniels> xorg uploading now
* infinity heads off to subvert a buildd for a while.
<daniels> infinity: xorg's there too, when libxext's finished building (or not)
<robitaille> jdub,  ping
<jdub> robitaille: pong
<jdub> elmo: planet sync please
<robitaille> jdub,  is it possible to put my blog on planet.u.c?
<jdub> elmo: s/sync/update/ ykwim
<jdub> robitaille: haha! elmo needs to update it for me :)
<jdub> robitaille: committed the change only half an hour ago or something
<robitaille> ok...wasn't sure you got my email a few days back.  thanks.
<Keybuk> daniels: is libx11 known fucked? :p
<daniels> Keybuk: i386 is known to be shit
<daniels> libx11 works just fine
<Keybuk> I can't upgrade it
<infinity> libx11 is fine, if xorg is built.
<Keybuk> it conflicts on xlibs-data
<daniels> Keybuk: i know
<daniels> so upgrade xorg :P
<infinity> Keybuk : That's cause xorg didn't build on i386.
<Keybuk> heh
<infinity> Keybuk : Working on that right now.
<Keybuk> right, known-fucked
<infinity> (but libx11 is fine)
<Keybuk> I guess this is also why my X server won't start? ;)
<infinity> NEAT.
<Keybuk> Fatal server error:
<Keybuk> could not open default font 'fixed';
<Keybuk> ... sweet
<jdub> do a dpkg-reconfigure
<infinity> I think that's the single most-reported X error message.  Ever.
<daniels> Keybuk: it can be one of two things
<Keybuk> on what?
<daniels> Keybuk: a) you have a custom config, and need to change all your font paths to /usr/share/X11/fonts/foo
<daniels> b) i'm shit, and mkfontdir is broken
<daniels> b can happen in a corner case on !i386 at the moment, I'm fixing that
<Keybuk> daniels: it was (a)
<daniels> Keybuk: ahar
<daniels> Keybuk: that'll go away when I fix every universe package
<daniels> ha ha ha
<daniels> uhm, yeah
<Keybuk> "every universe package" ?
<daniels> zgrep /usr/X11R6/lib/X11/fonts Contents-foo.gz
<daniels> kind of hard to turn it into a symlink :P
<Keybuk> heh
<Keybuk> why?
<Keybuk> dpkg lets you do that
<Keybuk> and doesn't whinge like a bitch about it either
<daniels> i don't want a 1266-character Replaces line, either :P
<Keybuk> turning directories into symlinks is expressly allowed (and the reason for much pain when people try and reverse it)
<Keybuk> heh
<daniels> Keybuk: by the way, dpkg doesn't have any restrictions on line length in control fields, does it?
<daniels> because, hypothetically, if one was to have a 1282-character Build-Depends line ...
<daniels> that was expected to grow before it expanded
<dilinger> daniels: you could split it up amongst multiple lines
<Keybuk> none that I'm aware of
<Keybuk> if you find out, let me know ;)
<daniels> word
<daniels> heh
<Keybuk> dilinger: that so doesn't work
<Keybuk> though I'm sure evolution would've found it by now
<Keybuk> evolution, the primary use case for "Build-Depend: the whole fucking archive"
<daniels> Keybuk: it would be really cool if it could just do Build-Depend: headers
<daniels> and drag in the whole fucking archive that way :P
<Keybuk> which headers? :p
<dilinger> Keybuk: eh?  it works for depends
<Keybuk> dilinger: FSVO. works
<dilinger> heh
<Keybuk> dpkg tends to be happy about it, but other things (*cough*katie*cough*) don't
<daniels> just like .bz2 debs :P)
<Keybuk> there's an open wishlist about dpkg automatically folding them into single lines
<daniels> (diveintopython, anyone?)
<Keybuk> katie is fine with them?
* Keybuk is sure he saw stuff in jennifer to check them
<daniels> when it was uploaded, katie choked
<Keybuk> her gag reflex is improving
* jdub replaces ubuntu with solaris express build 16
<jdub> on his sparc :)
<jsgotangco> opensolaris!
<daniels> COMMUNITY EDITION
<jsgotangco> not good enough?
<Unfrgiven> im having a problem with a package at the moment. when doing a pbuilder build, it fails as it can't find gcc-3.4. but the source doesnt have any reference to gcc-3.4. what gives?!?
<Amaranth> what package?
<Unfrgiven> Amaranth: gmetadom
<Amaranth> (i can't help, but it would help others find the problem)
<fabbione> morning
<daniels> shooting shoulder-to-fingertip pains -> afk for a bit
<Keybuk> daniels: we told you to ease up on the heroin
<daniels> infinity: poke
<infinity> daniels : ekop
<daniels> infinity: any buildd love?
<infinity> daniels : Still building.  (xext was fine)
<daniels> dude, your buildd is crap
<infinity> ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(via_drv.o): In function `ViaInitXVMC':
<infinity>  /build/buildd/xorg-6.8.2/build-tree/xc-xserver-xorg-dbg/programs/Xserver/hw/xfree86/drivers/via/via_xvmc.c:390: undefined reference to `xf86XvMCRegisterDRInfo'
<daniels> ...
<bob2> it would be via, wouldn't it
<daniels> nothing even CHANGED there!
<daniels> unless they typoed it
<infinity> Indeed.
<Lathiat> daniels: can you tell me (I can't find any descriptions) what XvMC does?
<daniels> Lathiat: it's 'xvideo motion compensation'.  basically, allows you to feed video in at an earlier stage of the pipeline (i think you can basically cram raw MPEG into some cards), so you have to do less decoding in software.
<Lathiat> ahh, what the hell does that have todo with 'motion compensation'? :)
<Amaranth> http://www.gnome.org/~carlosg/stuff/gst/new-services.png
<Amaranth> isn't that what BUM does?
<Lathiat> Amaranth: somewhat,but thats *much* simplerand usable. :)
<daniels> Lathiat: well, it makes it more tolerable when you have large videos with lots of movement :) else you can't get the data in fast enough, so your videos end up looking like arse
<Lathiat> daniels: oh i see
<daniels> Lathiat: i think there's also some code in the hardware-specific libraries to enable actual on-card motion compensation though
<Amaranth> Lathiat: Exactly, BUM is more of a poweruser interface.
<Lathiat> Amaranth: i like that interface :)
<Lathiat> actually
<Lathiat> does that mean
<Lathiat> 'running'
<Lathiat> or does  it mean
<Lathiat> 'start on boot'
<daniels> infinity: ... i honestly have no idea how this ever built.
<infinity> daniels : Blind luck..?
<daniels> oh, I see how
<daniels> clever.
<daniels> infinity: edit debian/patches/000_stolen_from_unichrome.sf.net.diff
<daniels> infinity: search for XvMCRevision
<jdub> so is usplash going to happen for breezy?
<daniels> infinity: change #if foo || bar to #if defined(fnord) && ...
<daniels> jdub: it needs some sweet bountying
<daniels> jdub: i'm on the verge of overcommitted as it is
<jdub> what about that dude who wrote his own usplash?
<Amaranth> splashy?
<daniels> i thought it wasn't what we wanted?
<jdub> no, but the dude might be able to do it
<daniels> probably worth a shot
<lamont> daniels: what does this mean fro libx11's build?
<lamont> ../../include/X11/Xlib.h:3575: error: parse error before '_X_SENTINEL'
<infinity> lamont : It's fixed.
<Lathiat> daniels: so, xvmc wouldnt help if i was playing xvid?
<infinity> lamont : You need the latest x11proto-core
<infinity>  ... -dev
<infinity> (Yes, maybe I should have fixed libx11 to have a versioned build-dep on x11proto-core-dev, but I figured since it was just uploaded, we can consider it a bugfix and move on)
<infinity> daniels : Changing those to ifdefs will change what they were trying to test for...
<infinity> daniels : Or, did you want "if defined(XvMCRevision) && XvMCVersion > 1" (which still looks diffrently wrong to me)
<daniels> infinity: you want to end up with defined(fnord) && (XvMCVersion > 1) || (XvMCRevision > 0), or whatever
<daniels> basically, the protocol headers are now up to scratch, but we haven't got the latest implementation details in the server
<daniels> so we never want it to test true
* infinity wonders if the last commit message to via_xvmc.c upstream is relevant...
<infinity> "Note that this severely brakes libviaXvMC and when this commit
<infinity> is transferred to Xorg, libviaXvMC build must be disabled until
<infinity> an update is made of that library."
<daniels> nah, no-one cares about libviaXvMC
<daniels> the whole concept of separate hardware-dependent client-side libraries is UTTER, UTTER, UTTER CRACK
<daniels> crikey, it seems vfat is rather buggy
<daniels> keeps trying to write beyond the end of my iAudio
<infinity> ...
<infinity> Generic USB mass storage?
<fabbione> daniels: what kernel?
<daniels> fabbione: .10 still
<daniels> infinity: yeah
<infinity> That sounds more likebuggy hardware misreporting its volume/partition sizes.
<daniels> it's always been good to me
<daniels> i re-mkfs.vfat'ed the thing, upgraded the firmware, and I'm going to try again
<infinity> Oh, for the love of...
<infinity> daniels : Would you believe that "fnord" actually /is/ defined?
* infinity just changes the statement to if 0
<daniels> infinity: you.  are.  not.  serious.
<infinity> Well, either that or you suck at cpp operator precedence.
<daniels> yeah, just make the whole line #if 0
* infinity gets out and pushes.
<infinity> FASTER!
<fabbione> Kamion: can you please readd usb-modules to sparc64 in d-i? we will start shipping it in 2.6.12
<fabbione> (we don't care if it fails with 2.6.10)
<infinity> daniels : Oh, you may want to upload xext now to give the buildds a head start on that before we get xorg up.
<daniels> infinity: good point
<daniels> uploading now
<jdub> can i turn the screen back on with a command?
<jdub> backlight
<jdub> gdm is running, but the screen is still off
<jdub> i'd hate to be unable to type *and* unable to see it :-)
<infinity> daniels : make install is going... Looks like we're okay with that "if 0" fix.
<infinity> daniels : So, you can do that and upload xorg too.  (it'll get auto-dep-waited just fine)
<daniels> infinity: thanks
<infinity> Build finished fine, BTW.
<jdub> aha, new xserver + xset :)
<jdub> daniels: still no keyboard love
<Burgundavia> jdub, the reports I have seen from splashy on the forum seem to be very positive. It would also be great press
<jdub> daniels: what else can i do to help debug?
<jdub> Burgundavia: hrm?
<Burgundavia> jdub, the ubuntu specific graphical boot thingy
<daniels> jdub: do you have new xorg and shit?
<jdub> daniels: the very latest
<robitaille> smurfix,  ping
<daniels> jdub: like, xorg -25, libx11-6 1:6.2.1+cvs.20050615
<mdz> is -25+ in the archive now?
<daniels> cock
<jdub> Burgundavia: graphical boot == great press?!
<daniels> mdz: 25 is in for amd64/powerpc, 26 has just gone in to fix a stupid via cock ftbfs
<smurfix> robitaille: 
<Burgundavia> jdub, no, adopting something that someone on the forums created
<daniels> (as an added bonus, I broke another big library out of 26)
<jdub> daniels: i have 6.8.2-24 of both
<robitaille> smurfix,   is smurflogbot a new permanent feature of all the LoCo channels?
<mdz> now is the time for breaking things
<smurfix> robitaille: yes
<daniels> jdub: ok, wait until new xorg lands
<robitaille> smurfix,  great; so we can now turn off our own canadian home-made logger
<fabbione> daniels: ah... new more crack??
<jdub> mdz: except for my keyboard. now is the time to fix my keyboard.
<daniels> fabbione: libXext is gone
* fabbione kills -25 build on sparc
<smurfix> robitaille: I can import your old logs if you want them to continue being available
<fabbione> daniels: is libxaw8 gone?
<daniels> fabbione: killed it in -25
<fabbione> daniels: (sparc related question)
<fabbione> daniels: ok.. that explain
<mdz> jdub: now is the time to work around your keyboard so that development marches on ;-)
<fabbione> hey mdz...
<mdz> fabbione: morning
<daniels> jdub: i had the exact same problem, it sort of mystically disappeared with a new libx11 and a couple of symlinks.  um.
<robitaille> smurfix,  I'll ask the owner of the logger if he wants to;  but I think the logs are somewhat incomplete
<fabbione> mdz: 1.2 is almost done.. i only need to sort a few more modules and do a build test orgy
<daniels> jdub: if not, I'll try to dive headlong into the code and work out WHAT THE FRIG IS GOING ON
<daniels> (worst.  code.  ever.)
* daniels dputs -26.
<mdz> fabbione: ok. I probably won't be awake for much longer
<fabbione> mdz: you will get it when you wake up
<fabbione> mdz: there is no way i can manage to build it in time before you go to sleep :)
<daniels> bbiab, got to head down to the post office
<fabbione> mdz: and not because i wouldn't love too
<mdz> fabbione: when you're ready, ask elmo to move it into main
<fabbione> mdz: we don't have machine fast enough for that :P
<fabbione> mdz: yup
<robitaille> smurfix,  what's the prefered URL for your irc logs.  I see one with "free" and one with "freenode" in their URL; they appear to be the same.
<smurfix> robitaille: freenode. The "free" is just there because the IRC server truncated the bot's name and I didn't want to restart it Yet Again.
<robitaille> smurfix,  ok; but  "/whois smuflogbot" display a link to the "free" url.
<smurfix> robitaille: That's what I said -- that text comes from the Freenode IRC server.
<robitaille> oh.
<smurfix> My bot logs in with "freenode" at the end when it logs on. :-/
<infinity> mdz : Can we get libxext shoved through NEW?
<mdz> infinity: not by me right now, but elmo should be awake soon enough
<infinity> Alright, I'll pester him in a while.
<mdz> night
<infinity> 'Night.
<fabbione> night mdz
<pitti> Good morning
<fabbione> morning pitti
<fabbione> maswan: ping?
<\sh> any ia64 specialists around? ,-)
<\sh> http://people.ubuntu.com/~lamont/buildLogs/c/cln/1.1.9-1ubuntu2/cln_1.1.9-1ubuntu2_20050616-2350-ia64-failed.gz
<\sh> but the other archs were ok...
* infinity has a look.
<robitaille> smurfix,  to quote from your e-mail:  "log a hundred channels during the next ten years".  Pretty impressive future to think of it that way.
<smurfix> robitaille: I sure hope so
<robitaille> smurfix,  I'm also hoping for it.  But first, we have to do 10x10.
<xuzo> hi smurfix, I reply your email to loco maillist. Category "CategoryUserpages" is not created.
<smurfix> xuzo: Bah. Thanks.
<xuzo> ;)
<infinity> \sh : I think I'll defer to an ia64 porter on that one.  The cause doesn't immediately jump out at me.
<\sh> infinity: i checked the upstream bugzilla and ml...but they don't mention anything concerning this problem...actually it's really on ia64 :(
<infinity> Smells like toolchain to me.
<\sh> problem is, i'm not an expert in things like assembler..the last time i programed with assembler was on a z80
<Lathiat> i wrote some x86 asm
<Lathiat> booted from a floppy toggle bitsonthe parallel port that showed up as 8 leds on this little device.:)
* Lathiat wonders why 4/5 times he runs apt he ends up with some form of http error at least once
<mvo> Lathiat: what sort of http error?
<robitaille> elmo,   is it possible for members to get @ubuntu.com addresses now, or it's something that will only be done in the future?
<elmo> jdub: done
<elmo> robitaille: not right now, but it's going to be done fairly soon
<robitaille> elmo,  ok.  thanks
<fabbione> Kamion: ping?
<pitti> infinity: is pkgstriptranslations 13 already installed in all buildds?
<Kamion> fabbione: pong
<fabbione> Kamion: scsi-*.udeb question :/
<fabbione> Kamion: other than scsi-core... there are 3 other scsi- udebs.. all in priority standard.. do they all get loaded? or there is still a specific selection per arch?
<Kamion> anything priority >= standard gets loaded when anna runs
<Kamion> however some of those are built into the initrd and some aren't
<Kamion> depending on the architecture and the installation medium type
<fabbione> hmmm ok
<fabbione> i guess i will just stick the new scsi drivers in extra than
<fabbione> and review it later on with you
<fabbione> Kamion: scsi and nic are the 2 most problematic ones at the moment.. all the others are pretty clean
<Kamion> if they're not the sort of SCSI controllers you'd find on huge numbers of machines, scsi-extra's generally sane
<fabbione> Kamion: i think i will defer scsi-* nic-* cleanup for the next upload.. we have no rush to add
<fabbione> Kamion: and given that they are the last 2 sets of udebs that needs cleaning
<Kamion> sure
<fabbione> Kamion: did you also read the scrollback about sparc64/usb?
<fabbione> Kamion: if you want you can readd it. i will start shipping the udebs with .12
<Kamion> no, my machine crashed, haven't read scrollback at all
<fabbione> so it's less diff to merge for you
<fabbione> ah ok
<Kamion> I'll re-add it when we switch to .12 then
<fabbione> Kamion: it's ok with me at any time.. we need to move .12 in main today
<Kamion> ah, ok
<fabbione> so i think we can switch from monday or when you fell more confident with it
<infinity> pitti : Is that the one you uploaded over a day ago?... I'm pretty sure it got installed yesterday when I was doing a bunch of manual chroot maintenance.
<pitti> infinity: I uploaded it yesterday noon
<pitti> infinity: it removed the KDE blacklist so that kde-i18n-* gets stripped now
<infinity> pitti : Yeah, I think that's installed on all 12.
<pitti> infinity: ok, great. Then I can ask Riddell to reupload the kde-i18n stuff
<pitti> let's break KDE translations and annoy KDE users :-)
<infinity> I'm all for that.  I did two KDE uploads a few minutes ago too, in hopes of irritating people.
<infinity> (Well, that, or to fix bugs)
<pitti> elmo: according to the LanguagePackRoadmap we split the packs into KDE/Gnome/other; so this will require some major NEW love in the near future; is there anything we should do to ease this pain?
<jdub> elmo: thanks!
<elmo> pitti: not do it?
<elmo> so we've gone from 150 x 3 to what?  150 x 6?  rock on
<pitti> elmo: we don't split the support packages
<elmo> pitti: where's this spec?
<pitti> elmo: 
<pitti> http://udu.wiki.ubuntu.com/LanguagePackRoadmap
<elmo> oh, blah udu
<pitti> (skip the -support split, we don't do it)
<infinity> Surely you remember UDU... Lots of fruit flavoured candies, people speaking with Australian accents?
<pitti> lots of blood flowing in our head, standing upside down all the time...
<elmo> what's the rational for splitting the non-support stuff?
<pitti> elmo: if we didn't, the langpacks would contain all the KDE and Gnome translations, although almost no user will require them both
<pitti> elmo: i. e. Ubuntu isntalls l-p-gnome-*, Kubuntu installs l-p-kde-*
<jdub> elmo: RATIONALE
<elmo> jdub: IT WAS A TYPO
<daniels> elmo: ARE YOU SAYING IT'S IRRATIONAL?!?
<elmo> pitti: dude, by definition the language packs are going to contain things most users will never use
<jdub> elmo: IT MAKES ME MAD!!!
<elmo> what makes the kde/gnome split special? 
<jdub> enormous amounts of translations
<daniels> jdub: ITS JUST A SIMPLE MISTAKE, A PERSONS GRAMMAR DOESNT MATTER BUT THERE INTENT
<elmo> we went down the one language pack per language thing for a reason, and you seem to be creeping back down the slope to madness
<pitti> elmo: the special thing is we don't translate KDE yet at all
<daniels> pitti: wow, that is special :)
<pitti> elmo: well, we can't fit all the KDE translations onto the Ubuntu CDs, for example
<infinity> "there intent"... I hope that was intentional irony.
<pitti> elmo: vice versa for Kubuntu CDs
<pitti> elmo: btw, supporting KDE wasn't exactly *my* idea ... :-)
<jdub> pitti: perhaps we should make the split down derivative lines-- hrm, no
<jdub> that's fucked up
<pitti> jdub: as long as Kubutu and Ubuntu are built from the same archive and so on, that doesn't work
<jdub> yeah
<pitti> if Kubuntu was a proper derivative with its own buildds, Kubuntu could have its own pkgstriptranslations
<pitti> and adapt the langpacks
<pitti> but right now we can't
<daniels> infinity: absolutely
<\sh> infinity: can u do me a favour and have a look where openscenegraph is on the buildd? i uploaded it yesterday, but it didn't show up as compiled or not compiled ;)
<infinity> \sh : dep-wait on giflib-dev
<infinity> \sh : Probably a broken dep-wait.  Let me look at it in a few minutes.
<\sh> hmmm...giflib3g i have here
<infinity> \sh : It was a bug in the auto-dep-waiter, since fixed.
<infinity> \sh : Packages released and building.
<\sh> thx :) 
<infinity> daniels : Is your suitcase filling up yet?
<pitti> brb
* infinity uploads a new libxext.
<Keybuk> *chuckle* it seems that Manoj comes from the daniels school of testing code
<Keybuk> "let other people do it"
<Keybuk> the SELinux patches he wrote for dpkg don't work
<Keybuk> and, in fact, they don't just not work -- they don't even get compiled in to the resulting binary
<infinity> Rock.
<daniels> infinity: slowly
* infinity mumbles something about epochs and uploads xorg -27
<daniels> ... epochs?
<daniels> oh, libxext-dev b-d
<fabbione> uhuhuh davis for the first time in history has been faster than ia64 :)
<fabbione> Kamion: http://people.ubuntu.com/~fabbione/foo <- it should be detailed enough....
<Kamion> fabbione: s/wegde/wedge/g please :-)
<fabbione> op
<fabbione> s
<Kamion>         + Update fat-modules to force all modules inclusion.
<Kamion> what's that?
<Treenaks> Kamion: fat vs vfat -> uppercase vs lowercase I think?
<fabbione> Kamion: they were optional (-drivers/...) but since we ship them, i enforced the check removing the -
<Kamion> Treenaks: fat-modules already contained both
<Kamion> fabbione: ah, ok, thanks
<fabbione> Kamion: i did try to enforce the sanity checks as much as i could
<fabbione> Kamion: given that sanity checks are good
<Kamion> fabbione: FWIW it'd be easier to read the changelog if it were of the form "added the following to d-i/shared/; made the following .lnk files point to shared: ...; did other stuff: ..."
<Kamion> since I want to read by category of change, not by individual udeb
<fabbione> Kamion: i prefer this way to be hounest... if you want i can rewrite it, but it won't take me exactly 2 minutes
<Kamion> fair enough, your choice
<fabbione> Kamion: it needs to be confortable for you to read too...
<fabbione> so i have no problems to rewrite it :)
<fabbione> it will just take some time
<fabbione> humpf.. ppc barfed
<sladen> 00/query jamesh
<sladen> ping
<infinity> fabbione : My PPC will be here on tuesday, BTW.
<fabbione> infinity: cool
<infinity> I'm hoping it'll come in handy. :)
<fabbione> infinity: but the hw on davis is ok
<fabbione> the build barfed for a duplicate module :)
<infinity> Yeah.  But you can't reboot davis.
<fabbione> ppc64 kernels > *
<fabbione> i don't need to :)
<infinity> (Yet)
<fabbione> don't even consider to touch it :)
<fabbione> brb
<Lathiat> mvo: various, bad header line is popular
<Riddell> pitti: should I re-upload kde-i18n now?
<pitti> Riddell: according to infinity it should be stripped now
<pitti> Riddell: so if the new packages can build POT files, then go ahead :-)
<pitti> Riddell: it would be nice to get POTs and stripped files in one shot
<ogra> infinity, any idea why xlibmesa-glu-dev is missing from hoary since yesterday ? there are a lot of user complaints on the mailing list
<elmo> fixed
<ogra> thanks
<elmo> added hilarie to cron.daily too
<jdub> so, future of ubuntu ppc
<jdub> "how much does ibm care?"
<infinity> Well, clearly someone needs to convince IBM to start making PPC laptops, since they just sold off their x86 desktop/laptop range. :)
<Mithrandir> heh
<Mithrandir> given their problems with getting laptop chips to apple, I'm not sure apple would be happy
<infinity> Somehow I doubt that making Apple happy is at the top of IBM TODO list these days.
<infinity> s/IBM/IBM's/
<Lathiat> heh i was about to say that
<tseng> neither is selling hardware to a small niche home user
<fabbione> elmo: linux-source-2.6.12_2.6.11.94-1.2 is on the way to jackass. it will need some NEW love (udebs) and it will need to go in main (per mdz request).
<infinity> tseng : Shh, a man can dream.
<infinity> fabbione : Have you seen any segfaults during your builds since davis got its new kernel?
<fabbione> infinity: not one 
<infinity> Dayum.
<fabbione> and with -j200 the machine does NOT suffer at all
<infinity> Kay, then I think we need to seriously look at upgrading the buildds.
<infinity> The segfaults on the PPC buildds are irritating.
<fabbione> i think i am going to push it up to -j500
<fabbione> concordia had problems with 500 because of only 2GB of ram
<fabbione> but davis has 3 :P
<infinity> Anyone ever tell you that you're weird?
<fabbione> infinity: why? i love to wake elmo because nagios starts to scream and yell for the load :)
<fabbione> it's a good stability test for the kernel
<Mithrandir> infinity: because he likes to exercise the machines?
<fabbione> nobody uses them.. i *RAPE* them :)
<fabbione> humpf.. only 20KB changes
<fabbione> i need to do better next time
<fabbione> time for food :)
<tseng> "Hardening Linux: a 10 step approach to a secure server"
<tseng> I love you, OSNews
<Mithrandir> tseng: didn't you know?  Security is just this module you bolt on at the end.
<tseng> Mithrandir: its a link to a wordpress blog, ironically
* Lathiat laughs
<infinity> elmo : openscenegraph binaries need NEW love.
<infinity> Alright, for i386/breezy users complaining that xorg was somewhat wedged, you should be good to upgrade now.
* infinity -> weekend.
<fabbione> infinity: have fun
<JaneW> mjg59: PING
<jsgotangco> JaneW, hi
<JaneW> hi jsgotangco 
<mjg59> JaneW: Hi
<Treenaks> any more news about October? :)
<pitti> @all: we want to install /sbin/unix_chkpwd as setgid shadow by default (instead of setuid root); however, setuid root is required for nis, therefore we need a statoverride there (a bit evil, but this was agreed on with Keybuk); can anybody please take a look at http://people.ubuntu.com/~pitti/nis.unix_chkpwd-deroot.diff to check for obvious mistakes?
<JaneW> mjg59: hello
<mjg59> JaneW: Hi
<JaneW> mjg59: are you still running with the BreezyGoal: LaptopMission?
<mjg59> JaneW: Yup. It'll be updated tomorrow.
<mjg59> Sorry, far too much real life for the past couple of weeks :)
<JaneW> mjg59: because it has still not been updated on http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<JaneW> mjg59: ok thanks. I was concerned that it had been forgotten
<JaneW> being a top priority goal that would not be good.
<mjg59> Sure, no problem
<JaneW> cool thanks
<JaneW> could anyone else who hasn't updated the status of their BreezyGoals please do so soon. http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<JaneW> Please put the date of the update at the start of the line for easy refernce. Thanks.
<Lathiat> elmo: ping
<Lathiat> elmo: unping
<Lathiat> jdub: ping
<Duck_work> jbailey: build-dep missing on dash Sir
<jbailey> Duck_work: Context?
<Duck_work> jbailey: cdbs2 of course
<jbailey> Ah. =)
<Duck_work> i'm trying to build it
<jbailey> Yeah, it's not intended to require dash in the end.  That's just what we're using for testing for now.
<tseng> jbailey: do you have a design doc about cdbs2?
<jbailey> I wonder if we should add the b-d
* jbailey hands a pile of napkins to tseng 
<Duck_work> jbailey: temporary b-d is not so awful to remove later
<tseng> ah, skunkworks
<jbailey> The important bits are between the beer stain and the french fry grease. =)
<elmo> library packages called libfoo-cvs are JUST WRONG
<seb128> jbailey: do you know why some cdbs packages have a .cdbs-config_list?
<tseng> elmo: its better if you have a bunch of stuff build-dep on it
<tseng> elmo: and no epoch
<seb128> jbailey: ie, gaim has gaim-1.3.1.tar.bz2.cdbs-config_list
<pitti> seb128: I think that happens to all cdbs packages which were built recently; it certainly happens to all of mine and I think it's annoying...
<jbailey> tseng: Essentially the design stuff that I have is scattered across IRC sessions, phone calls, and in person descriptions.  The problem is that the design evolves everytime dilinger and I talk to someone or touch it.
<jbailey> seb128: Ugh, I don't.  Sorry.
<seb128> pitti: yeah, same for me
<jbailey> tseng: I find it easiest to talk about it relative to the current cdbs, rather than as a complete design on its own.  We've committed that it will have at least some basic docs in it before the first upload this time, though.
<seb128> that and it put config.guess/sub stuff to the diff for a simple source rebuild
<azeem> I guess nyu put that in, it's his automatically-update-config.{sub,guess} magic
<seb128> I hate this magic
<pitti> seb128: yes, that's why I try to purge autotools-dev as often as possible...
<Duck_work> seb128: the condig.* stuff was due to bad stuff in clean rules, it should be solved by now
<azeem> s/magic/black magic/
<elmo> seb128: welcome to how we all feel about cdbs :-P
<seb128> elmo: ah ah :)
<Duck_work> elmo: not all, happilly
<fabbione> elmo: did you read my message in the scrollback about 2.6.12?
<elmo> fabbione: yeah
<fabbione> elmo: rocking
<jbailey> seb128: The magic that Robert put in has too many side effects, and no testsuite bits so I can't even feel safe about pulling it out with a minimum of side effects.  It's incentive to do more with cdbs2.  Testsuites and docs are basically all that's left for something that is good enough for most autotools uses.
<seb128> elmo: can you sync nss-mdns please?
<Lathiat> seb128: interesting timing, i was just talking about that
<seb128> Lathiat: ross asked for it
<Lathiat> cus lennart (author) was just asking me why it was so old. :)
<elmo> seb128: done
<seb128> elmo: thanks
<seb128> Duck_work: fixed with what version?
<jdub> Lathiat: pong
<\sh> who can adjust the frozenappslist?
<Lathiat> jdub: 'sok, was gonna ask about nss-mdns
<Lathiat> jdub: but seb just got it synced so its all good:)
<\sh> argl
<\sh> i'm too slow
<infinity> \sh : What needs adjusting?
<seb128> is galeon still frozen?
<infinity> No.
<seb128> cool
<seb128> thanks
<\sh> infinity: it's ok...i was to slow...new package from debian arrived
<jdub> YAY NEW KERNEL
<\sh> anyone know what octave is?
<Lathiat> mvo: 
<Lathiat> Err http://au.archive.ubuntu.com breezy-updates Release.gpg
<Lathiat>   Bad header line [IP: 82.211.81.151 80] 
<tseng> \sh: isnt it some obscure programming language?
<Lathiat> mvo: i got that often
<\sh> tseng: i don't really know...but I need to compile it :( 
<azeem> \sh: apt-cache knows
<tseng> octave - GNU Octave language for numerical computations (2.1 branch)
<tseng> its guh-knew
<tseng> it must be good
<\sh> when hdf5 is compiled ;)
<mvo> Lathiat: try to run apt-get update -o Debug::Acquire::http=True 2> http_debug
<Lathiat> ok,i'll let you know when i make it happennext
<elmo> fabbione: 2.6.12 just floated by - didn't seem NEW, FWIW
<Nafallo> anyone has troubles with X today? :-)
<\sh> I wasn't restarting X since the update this morning ;)
<fabbione> elmo: some udebs are. iirc sparc64, ia64.. probably hppa
<fabbione> elmo: nothing new on the main arches side
<fabbione> jdub: and new idiotify :p
<Nafallo> hmm, actually I didn't update it before gdm wouldn't let me in to my default session :-/
<Nafallo> anyone has troubles with gdm today? ;-)
<Lathiat> Nafallo: yeh 
<Lathiat> Nafallo: just selection GNOME as your session
<Lathiat> Nafallo: and it works
<Nafallo> Lathiat: oki. I'll try that and get right back :-).
<jdub> fabbione: on by default? :)
<tseng> jdub: it has been for awhile
<tseng> in the .12 pres
<jdub> yay
<fabbione> jdub: tsk...
<Nafallo> Lathiat: yay! :-)
<pitti> sjoerd: here?
<sjoerd> pitti: sortof
<Nafallo> now to X... can't activate the XKB-config :-P
<jdub> mdz, pitti: can you check nss-mdns and zeroconf for sanity? :-)
<pitti> sjoerd: just a quick question, what's the status of the new dbus in Debian? (which entails the transition)
<pitti> jdub: I hate you :-)
<pitti> jdub: no, seriously, you mean the usual main inclusion review?
<jdub> pitti: yeah
<sjoerd> pitti: the upload was rejected becasue of the planned C++ abi transition
<pitti> sjoerd: even to experimental? hrmpf
<jdub> pitti: unless you hate the idea out of principle or something ;)
<pitti> jdub: I didn't dig into that enough to hate it yet :)
<\sh> http://blog.iansview.com/archives/64-Keep-your-computers-time-in-sync-using-HTP.html 
<\sh> this could be quite interessting alternative to ntpdate
<ogra> jdub, freescreensaver ?
<sjoerd> pitti: yeah, unfortunately my exams are taking a lot more time then planned, so hal will take a while :(..
<infinity> \sh : Cute idea.
<jdub> ogra: F WORD!
<pitti> sjoerd: well, without dbus we can't do any other updates anyway
<\sh> infinity: yes I think so :)
<ogra> jdub, feel like working on a spec ? ;)
<jdub> hmm
<sjoerd> pitti: yep, i'm going to ask for it to be allowed into experimental.. i don't really see why experimental stuff should slow down the transistion (as long as it stays in exp. untill after the transition)
<jdub> everyone wants to fork
<jdub> no one wants to be the dude responsible for forking it though
<\sh> infinity: do u want to package it? or should I do it tomorrow
<infinity> \sh : Go nuts.  I dan't have the time, or the interest. :)
<\sh> hehehe
<ogra> jdub, if you provide a spec that matches all needs your fork will just smart out the original
<infinity> \sh : Check to see if there's a Debian ITP first (and if not, file one... I'll sponsor your uploads to Debian)
<\sh> infinity: i will...but first tomorrow :) I want to go home just now..and then I will have a couple of pints with some friends :)
<\sh> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313595
<Duck_work> seb128: latest if i remember well, i remember removing a dirty hack in cc or other gnome pkg because of such bug
<seb128> k
<infinity> \sh : Well, there you go.  If you're impatient, contact the submitter and offer to work with him.  Otherwise, just wait. :)
<\sh> infinity: any chance to put it as an alternative to ntpdate for main?
<infinity> \sh : It could certainly be discussed.  I'm not the man to make that decision, though.
<pitti> \sh: If you want to push this, please write a spec about it and do some research
<pitti> \sh: then this should be discussed in a TB meeting
<\sh> pitti: i think it could be a good alternative for laptop users in a corporate office enviroment
<Lathiat> jdub: i'd so do it just to piss him off for that flaming email? :)
<Lathiat> not that i'd be any good at maintaing it :)
<\sh> pitti: i will do some research and will write something on the wiki about it..
<infinity> \sh : If the code is sane, I do like the idea.  But it needs a bit of an audit, and a lot of testing, I'd suspect.
<infinity> \sh : ntp may be annoying for some users (due to firewalls and such), but it DOES work, and have a massive install base, etc.
<Lathiat> its also more accurate
<Lathiat> if you really care
<infinity> Lathiat : ntpdate wouldn't be much more accurate than htpdate.
<\sh> infinity: I don't want to push ntp away ;) htp is also only running with a near webserver as I read just now..so if i put a webserver in the config file from the states, I'm in a new timezone ;)
<infinity> Lathiat : I would never push this as a replacement for ntpd.
<Lathiat> infinity: why not? ntp is sub-second 
<infinity> Lathiat : But for the one-off boot-time config, it's sane.
<Lathiat> infinity: it also accounts for latency better than a  http server good
<Lathiat> s/good/could
<Lathiat> but,sure, its accurate enough formost users
<Lathiat> esp. if it'l work more often and not hold up the boot somuch :)
<infinity> \sh : http header dates have timezones in them.  Where the server is doesn't matter, except for latency.
<infinity> \sh : And a one second round-trip still beats a clock that's off by minutes/hours on boot.
<infinity> (If you want real time syncing, run ntpd, as always.. The boot-time sync is just for a "close enough, fix the clock if it's broken" setup.
<infinity> )
<\sh> infinity: well, at home it doesn't work anyways..without a direct network connection even ntpdate is stucked ;)
<Nafallo> infinity: xkb broken with -27?
<Nafallo> infinity: atleast here... ;-)
<infinity> Nafallo : If it was broken before, and not fixed, then "yes".
<infinity> Nafallo : In other words, "I'm not sure, I was just making sure the packages built"...
<Nafallo> infinity: was not broken with -25
<infinity> Nafallo : Tomorrow, I may look at other xorg bugs, but it's also my weekend, so I may not. :)
<infinity> (Yay breezy)
<tseng> Nafallo: a bunch of stuff is broken
<Nafallo> infinity: I know. new xorg should go in on wednesdays or something ;-)
<Nafallo> tseng: indeed. I have US keyboard for instance :-P
<tseng> so speak english :)
<Nafallo> tseng: hehe
<tseng> no problem
<infinity> Speaking English does seem to solve many software problems, yes.
<Nafallo> dooh :-P
<Nafallo> if only thom could be awake and fix 11904 everything would be less of a pain ;-)
<HiddenWolf> nafallo, use him as an excuse to sleep till he fixes it. :)
<tseng> such a whiner
<Nafallo> HiddenWolf: hehe
<Nafallo> tseng: baah, bugs :-P.
<tseng> baah, whiners :-P
<tseng> did you debug/fix/report those crashers yet?
<Nafallo> tseng: there is one crasher to report :-).
<tseng> 2
<tseng> 3, you can report the ctrl+f thing for me :)
<Nafallo> tseng: I'm waiting for the new muine with builtin trayicon :-). if it exists I'll report it.
<Duck_work> jbailey: DEB_CONFIGURE_SCRIPT_ENV is broken
<tseng> well its stuck somewhere
<jbailey> Duck_work: Is the fix obvious?
<Nafallo> tseng: hmm, I better try the new libxklavier first ;-)
<tseng> buh
<Duck_work> jbailey: yes, missing quotes
<Duck_work> jbailey: is used : DEB_CONFIGURE_SCRIPT_ENV := LDFLAGS=" -Wl,-z,defs -Wl,-O1"
<Duck_work> and quotes for LDFLAGS were removed
<Duck_work> seems there is another problem
<Duck_work> during build this time
<azeem> it overrides CFLAGS
<azeem> if you do := instead of +=, that is
<Duck_work> azeem: ok
<jbailey> Ugh, this is not what my brain is on at the moment...
<jbailey> Duck_work: Would you mind collecting up a diff of these things and sending it to me when you're done hacking for the day?
<Duck_work> jbailey: i've got a config.h not found :-(
<jbailey> I'll get them merged in right away.
<Duck_work> i could
<Duck_work> if i am able to solve things
<jbailey> config.h ?
<Duck_work> yep
<jbailey> It's written in shell, it shouldn't be looking for C header files.
<Duck_work> i took a working pkg
<jbailey> Ah. nice! =)
<jbailey> Live tests!
<Duck_work> only changed things related to cdbs
<jbailey> If you can reduce the problem to a test case, I would *really* appreciate it.
<Duck_work> of course live tests
<jbailey> Then I can promise you from that point forward that it will never happen again. =)
<Duck_work> ok
<jbailey> (We give you new bugs at each iteration, not OLD and STALE bugs!)
<infinity> I sure do love fresh bugs!
<Duck_work> jbailey: just a hint to help me do tests: what is the hook format like now ?
<Duck_work> what is build/pkg:: equivalent ?
<jbailey> Duck_work: dilinger implemented it, so I don't know off hand.  I remember how we had talked about it, but it almost certainly wouldn't have been implemented that way in the end.
<jbailey> (You know how these things go)
<infinity> Nonsense, dilinger is a mind-reader, and surely did it exactly as you imagined.
<infinity> He and I have had many CVS collisions with identical commits for that very reason.
<Duck_work> dilinger: HELP REQUIRED !!!
<infinity> HE'S CREEPY.
<dilinger> I SEE BUILD SYSTEMS
<infinity> See?
<infinity> CREEPY.
<dilinger> Duck_work: here's an example
<dilinger> http://mouth.voxel.net/~dilinger/rules
<Duck_work> coin Sir dilinger 
<Duck_work> thanjks
<pitti> Kamion: would it be possible to remove the "ro," from the CD-ROM fstab entries created by the installer?
<dilinger> np
<pitti> Kamion: it prevents the r/w mount of UDF DVD-RAMs, and normal CD-ROMs default to ro anyway
<Kamion> pitti: I guess so - file a bug on partman-target, please?
<pitti> Kamion: alright
<dilinger> Duck_work: note that debian/rules help should spit out all kinds of information, as well
<Duck_work> dilinger: nice, i should | less to avoid flooding my term :-)
<Duck_work> DEB_CONFIGURE_INVOKE is ... strange
<Duck_work> DEB_CONFIGURE_INVOKE='cd . && /home/duck/gnusound/gnusound-0.6.2/./configure <-- i guess this is done to handle specific locations, multibuilds, ...
<Duck_work> dilinger: all quote desapeared :-(
<Duck_work> +s
<Duck_work> example :
<Duck_work>   DEB_MAKE_INSTALL_TARGET='install DESTDIR=/home/duck/gnusound/gnusound-0.6.2/debian/tmp/'
<Duck_work> DESTDIR had ""
<dilinger> variables are eval'd
<dilinger> hm, i thought i had an example there
<dilinger> anyways, you'll need to play around w/ escaping
<dilinger> the eval stuff is suboptimal, but it was the only way i could make bash and posh both happy
<jdub> pitti: actually, don't worry about nss-mdns yet
<dilinger> they both appear to have different behavior
<pitti> jdub: if you do worry about zeroconf, could you please add it to https://wiki.ubuntu.com/UbuntuMainInclusionQueue and prepare a short report for that?
<Duck_work> dilinger: :-(
<jdub> pitti: ok, but i'll leave them until they're ready together (zeroconf, avahi and nss-mdns)
<seb128_> pitti: boooooog on your cdbs/languagepack magic
<seb128_> (tricky case rather)
<pitti> seb128_: details?
<seb128_> pitti: libglade2 has no po/, ./configure && make creates an empty po/ dir, your magic try to "/usr/bin/intltool-update -p --verbose;" here and returns on a "intltool-update: POTFILES.in not found."
<pitti> seb128_: ah, and this exits with an error?
<seb128_> you should probably [ -e po/POTFILES.in ] 
<pitti> seb128_: so the sanest thing would rather be to append || true
<seb128_> intltool-update: POTFILES.in not found.
<seb128_> make: *** [common-post-build-arch]  Erreur 2
<seb128_> debuild: fatal error at line 765:
<seb128_> dpkg-buildpackage failed!
<seb128_> 
<seb128_> that's an option too
<pitti> alright, fixing now
<Kamion> http://cdimage.ubuntu.com/daily/current/report.html <- I wonder what all that's about
<seb128_> pitti: thanks
<pitti> Kamion: seb128 and me too, today's dist-upgrade wants to remove many packages
<pitti> we blamed daniels so far :-)
<seb128_> pitti: have you read the query this morning?
<pitti> seb128_: erm, not your answer? I had some network trouble again :-(
<seb128_> Investigating libx11-6
<seb128_> Package libx11-6 has broken dep on xlibs-data
<seb128_>   Considering xlibs-data 467 as a solution to libx11-6 1474
<seb128_>   Added xlibs-data to the remove list
<seb128_>   Fixing libx11-6 via remove of xlibs-data
<seb128_> 
<seb128_> I said that
<pitti> uh
<seb128_> that's apt with Debug::pkgProblemResolver=yes
<jordi> elmo: > <seb128> I'm pretty sure that's not a gtk bug
* seb128_ kicks jordi 
<ogra> Kamion, i guess X causes that...
* ogra reboots to new kernel and X
<Nafallo> seb128_: libxkbfile-dev as build-dep for libxklavier built locally.
<seb128_> Nafallo: say it again?
<seb128_> is there any context to this?
<Nafallo> seb128_: FTBFS on all arches.
<Nafallo> seb128_: the buildlogs are fairly straightforward :-)
<pitti> Hi lamont
<seb128_> Nafallo: you are just trying that you sit on front of the build log to bother people on IRC when something FTBFS? :)
<lamont> morning pitti
<seb128> Nafallo: I'm doing a bunch of syncs, I'll fix the FTBFSes later, but thanks
<pitti> lamont: do you think you can fix the translation stripping tarball download soon? It's pretty much effort to correct it 
<pitti> (i. e. correct from my side)
<Nafallo> seb128: k :-).
<lamont> and winds up with lots of files owned by pitti in my html tree...
<pitti> lamont: yeah, sorry, I recovered the good tarballs from the various buildds
<pitti> lamont: thom will certainly help you to chown them to you :-)
<lamont> how soon do you think you'll have packagestriptranslations fixed to make it yet another file that is delivered to "not the archive" through the normal dupload process? :-)
<pitti> lamont: well, that would be dpkg-source -b'ish rather than in pkgstriptranslations, right?
<lamont> pitti: checking that the a new tarball is larger than the existing one strikes me as a hack, fwiw
<pitti> lamont: so far we didn't discuss that with anybody yet
<lamont> that'd be a dpkg-genpackage-ish thing, by adding it to a file list/
<pitti> lamont: it is a hack, until the gettext issue on 64 bit platforms is sorted out; but that might take a while
<lamont> and then teaching the archive process to magically handle it by dropping it off to the side somewhere, rather than in the mirrored archive
<lamont> it's less of a hack to add $ARCH to the filename...
<Duck_work> dilinger: makefile.sh:    ## FIXME: Define CFLAGS, CXXFLAGS correctly
<Duck_work> taht's why it is not working
<pitti> lamont: I could live with $ARCH as well, I don't know about the rosetta guys
<pitti> lamont: either is fine for me, whatever can be made quicker
<lamont> pitti: well, since it's magic knowledge in sbuild right now (sounds of vomitting) instead of being just another file, any change is going to require me to do something...  let me ponder it a bit and poke the rosetta guys about their pain levels
<pitti> thanks
<Kamion> er. where'd xterm go?
<Kamion> xorg no longer builds it, but nothing else does either
<Kamion> daniels: ?
<lamont> Kamion: good catch.  if he doesn't get it back soon, we'll send guidofinity over to his place to discuss the situation...
<Kamion> and britney lists it as uninstallable, although it installs fine for me
<lamont> wonder if it still would install after a dist-upgrade, and removing some orphaned packages
<Kamion> well, I did dist-upgrade; let's try dselect ...
<Kamion> I had a couple of things from universe installed, but nothing relevant. No obsolete packages.
<Kamion> ah, libxaw8 disappeared
<Kamion> I did wonder about that when reading the changelog ...
<seb128> elmo: zenity gthumb galeon eog syncs please
<lamont> elmo/thom: pls chown -R lamont ~lamont/public_html/translations
<jbailey> ANyone here familiar with how the only-ifup-when-I-load-a-module magic works?
<elmo> seb128: done
<elmo> lamont: done
<lamont> elmo: thanks muchly
<seb128> elmo: thank you
* netjoined: irc.freenode.net -> orwell.freenode.net
<spotter> anyone using the newest X packages?
<\sh> yes
<spotter> no problems?
<\sh> and xkb is broken..so don't complain ;)
<spotter> more than xkb
<pitti> again???
<spotter> gnome wont event start
<\sh> spotter: apt-get install ubuntu-desktop
<spotter> lots of errors in .xsession-errors
<spotter> ok, lets see what that installs
<lamont> hrm... is there a gethostbyname in python, I wonder.
<\sh> ok...i need a hardware sponsor...
<\sh> 1. powerpc ;)
<\sh> 2. ia64
<\sh> 3 archs ok...but ppc libtool: link: `../lib/libh5tools.la' is not a valid libtool archive
<lamont> pitti: re pkgstriptranslations: I'm just going to disable both 64-bit architectures..  that's the simplest hack-on-hack, and the rosetta guys are OK with the possible need to handle the <10 packages that could be dropped that way
<pitti> lamont: great, that's fine for me
<spotter> k, problem1 startx wants to run /usr/bin/X11/X
<spotter> it doesn't exist
<spotter> Xorg does though
<spotter> symlink fixes that
<spotter> then however, startx wants to create /var/log/Xorg.0.log, but it cant (as regular user, as root, no complaints)
<spotter> as an aside, does vt switching in X work for anyone anymore?  (ctrl-alt-fkey, stopped working a few weeks back for me)
<spotter> ok, server isn't suid root
<\sh> spotter: can u file a bug with all those things?
<spotter> chmod u+s /usr/X11R6/bin/Xorg fixed that and X starts (from startx)
<spotter> yea
<spotter> can you email it to me (spotter@cs.columbia.edu) in bitchx and can't copy and paste to X
<spotter> and of course your comment of xkb broken again seems to be accurate
<\sh> spotter: send
<Keybuk> so, uh, am I not supposed to be able to login from gdm at the moment
<Keybuk> ?
<seb128> elmo: can you sync gnome-alsamixer again (it has been dropped on MOTU request as discussed but Daniel said he has no objection to get it again)
<seb128> Keybuk: what version?
<Keybuk> seb128: whatever was in the archive NOW-$how_long_the_update_took
<seb128> I tend to blame xorg so
<Keybuk> I get an ugly "CHOOSE YOUR SESSION WIDGET" thing
<Keybuk> which does nothing
<seb128> new gdm has an issue (using /usr/ksh instead of /usr/sh) this morning but I've fixed that for hours
<Keybuk> did you fix it in ubuntu3?
<seb128> yep
<Keybuk> right
<Keybuk> cancel the anti-aircraft weaponry
* Keybuk nukes france instead
<Keybuk> :p
<Keybuk> I must have _just_ missed that when I started the upgrade
<HrdwrBoB> Keybuk: no-one will notice
<HrdwrBoB> except maybe the french 
<Keybuk> (I was _really_ far behind with breezy -- laptop's been gathering dust since UDU)
<seb128> roh
<Keybuk> I notice all the gdm binaries moved
<seb128> Keybuk: I would have transitioned gdm some time ago already, but I was waiting for hct *g*
<seb128> Keybuk: yeah, /usr/bin to /usr/sbin or /usr/lib
<Keybuk> seb128: there's a #hct channel you can hassle me on now :p
<seb128> nice :)
<Keybuk> I can do "right now" imports I think
<Keybuk> fabbione: you're not supposed to /join and /part :p
<fabbione> Keybuk: i was only hasseling :P
<Keybuk> you should put it in your auto-join
<Keybuk> and hang out with the cool kids
<Keybuk> they're all using HCT these days
* Keybuk is thinking of getting HCT charity wristbands made up
<Keybuk> what colour should they be?
<fabbione> pink
<spotter> Keybuk: lots of problems
<spotter> about to file a bug
<Keybuk> spotter: with?
<spotter>  /usr/bin/X11/X is missing (Xorg is there) 
<spotter> startx depends on that
<Keybuk> oh, I fixed _those_ already :p
<spotter>  /usr/X11R6/bin/Xorg isn't chmod u+s
<Keybuk> it's just session and display management that I fall over and get confused
<\sh> hmm....it's in the topic of #u-m
<Keybuk> we should make a policy
<Keybuk> daniels does not upload X before international travel
<lamont> Keybuk: would those wristbands come with razor blades? :-)
<\sh> Keybuk: better idea...open the archives only to people who know that everything is bleeding nose buggy ,-)
<Keybuk> it's not the bleeding nose I worry about
<Keybuk> it's the bleeding testicles
<infinity> Mmm, testicles.
<\sh> right, i can't enter my backslash ;)
<\sh> my personality ... just disappeard :(
<mdz> daniels: xserver-xorg 6.8.2-27 fails to configure itself for my laptop hardware anymore (chooses vesa) and adds a "Generic Mouse" to ServerLayout without a corresponding InputDevice section
<jdub> Keybuk: i can't type in X.
<jdub> Keybuk: but otherwise, everything else is quite alright. :-)
* ogra can.... except umlauts
<\sh> no umlauts and no backslash ;)
<jdub> ogra: oh well, no one here listens to heavy metal anyway.
<Kamion> mdz: since xterm is currently hosed (libxaw8 got removed under it), what do you think about temporarily removing it from desktop?
<ogra> hhhehehe
<mdke> jdub doesn't listen to heavy metal?
<mdke> SHOCK
<mdz> Kamion: xterm is in desktop?
<Kamion> mdz: yes
<mdz> Kamion: it oughtn't be
<Kamion> really?
<Kamion> er, ok
<mdz> if I can get over my xterm addiction, I think the rest of the world can too ;-)
<jdub> i don't think it's a terrible thing to have in desktop
<jdub> and removing it doesn't save too much space :)
<fabbione> no
<fabbione> don't remove xterm please
<Kamion> just seems kind of an odd thing to ship without
<jdub> the powerkids love us for it
<fabbione> even Michael Jackson uses xterm...
<fabbione> we can't remove it :P
<dilinger> heh.  totem wins for most useless error message ever.
<dilinger> ** (totem:663): CRITICAL **: bacon_message_connection_get_is_server: assertion `conn != NULL' failed
<\sh> michael jackson uses xterm?
<fabbione> elmo: no luck yet to move 2.6.12 to main?
<seb128> dilinger: what it useless about this?
<seb128> dilinger: you have the line, function and condition b0rked
<dilinger> seb128: it doesn't actually mean anything to a user :p
<seb128> dilinger: that's why it's not an UI dialog
<fabbione> dilinger: it's all a conspiracy to make people switch to kde
<dilinger> seb128: is it a network thing?  is it misconfigured?  is it a sound thing?  is it having problems w/ gconf or something?  dbus, maybe?  what's bacon?
<seb128> dilinger: that's a line to put to bugzilla so upstream knows what is wrong and can fix it
<mdz> doko: it seems that twisted added a dep on zopeinterface, which wants python2.2
<doko> mdz: ok, dropping it
<\sh> 7join #ubuntu-ppc-specialist
<mdz> doko: thanks
<mdz> fabbione: I moved it already
<fabbione> mdz: the change didn't propagate to the archive yet.. did it?
<mdz> fabbione: probably not
<fabbione> ok
<mdz> fabbione: I moved the whole thing, but most of it wants to move back to universe unless it's seeded
<fabbione> mdz: ah ok
<fabbione> mdz: i need another upload to complete the cleanup for the udebs and we can switch the installer to .12
<fabbione> mdz: at that point it should be ok without seeding
<mdz> fabbione: well, switching the installer is a matter of changing the seeds ;-)
<mdz> fabbione: do you know what causes this xorg.conf mouse problem?  it has happened before
<fabbione> mdz: no. it's a while i don't upgrade my machine
<Kamion> mdz: ... no it's not :)
<fabbione> Kamion, mdz: well up to you 2 to agree :)
<fabbione> i need to go and cook dinner guys
<fabbione> start to enjoy the .12 ride!
<fabbione> because this kernel seems to be rock solid
<mdz> Kamion: oh, that variable is set in germinate or someplace instead (now?)?
<\sh> fabbione: have fun.../me is getting ready for party...
* fabbione &
<mdz> installer: * Kernel-Version: 2.6.10-5-amd64-generic
<mdz> installer: * Kernel-Version: 2.6.10-5-386
<mdz> installer: * Kernel-Version: 2.6.10-5-itanium-smp
<mdz> installer: * Kernel-Version: 2.6.10-5-power4 2.6.10-5-powerpc
<mdz> installer: * Kernel-Version: 2.6.10-5-sparc64
<mdz> are those no longer meaningful?
<Kamion> mdz: they're perfectly meaningful, they're just not sufficient
<Kamion> and never have been
<Kamion> d-i needs to be uploaded when switching kernel versions, to rebuild the initrds and cope with any udeb rearrangements
<fabbione> oh Kamion please don't merge kernel-wedge yet.. i need another upload to complete the cleanup and fix sparc FTBFS
<fabbione> we will switch immediatly after
<fabbione> (question of one day MAX 2 )
<Kamion> those seed variables are there so that we don't have to repeat "2.6.10-5" a zillion times in the seeds
<fabbione> i am off for real
<fabbione> bye bye
<Kamion> fabbione: wasn't planning to - in fact I'd rather you did it so you can coordinate any necessary kernel changes
<mdz> Kamion: I don't think we disagree
<fabbione> Kamion: SUPER!
<mdz> perhaps s/is a matter of/involves/
<Kamion> mdz: oh, I think I may have misread you
<Kamion> yes, that
<mdz> I didn't mean to imply that it was exclusively a seed change
<Kamion> ah, ok, I take back the disagreement :-)
* Kamion tries to write his lugradio talk
<mdz> Kamion: how is the house coming along?
<Kamion> mdz: still rather living out of boxes, but otherwise more or less sorted
<mdz> Kamion: is it close to where you lived before?
<mdz> I don't see anything in the changelog about the .config script changing at all, how odd
<Kamion> mdz: yeah, about a mile or so away, same side of town
<Kamion> separate study and bedroom now, which is an unbelievably excellent improvement :)
<mdz> heh
<Kamion> http://maps.google.co.uk/maps?q=atherton+close+cambridge+to+pelham+court+cambridge&spn=0.014039,0.042443&hl=en <- moved from bottom right to top left
<Kamion> with my favourite pub almost equidistant between the two ;-)
<Lathiat> mvo: "apt-get update -o Debug::Acquire:http=True"
<Lathiat> mvo: is that right?i got not extra debug info
<azeem> s/:/::/?
<Lathiat> heh
<Lathiat> toobad i have to wait half an hour to reproduce it again
<Lathiat> andnow md5sum mismatches on main+universe sources -- what causes that? in betweenupdates? (i see it every so often)
<mdz> daniels: there seem to be several changes from -24 to -27 which are not documented in the changelog; are they intentional?
<mdz> (at least one of them is the cause of my mouse problem)
<mdz> I have no idea what is causing the driver detection bit to fail yet, though
<infinity> Driver detection, as in video driver?
<infinity> I see no changes to that between -24 and -27...
<mdz> infinity: neither do I, but I get vesa now where before I (correctly) got ati
<mdz> what does dexconf mean by "multiplexed"?  the logic doesn't seem to refer to the definition of that word with which I am familiar
<mdz> it feels that /dev/psaux is a "multiplexed" mouse device
<mdz> as well as serial devices
<infinity> Yeah, I have no idea what the deal is with the mouse stuff.  I'm trying to hunt the keyboard issues right now.
<mdz> oh, there are keyboard issues too?
<infinity> There are if you're not from the US. :)
<infinity> (So, I didn't notice either, until people whined)
<mdz> I'm from the US, but I don't use a us layout
<lamont> seb128: got a few minutes for a puzzler?
<infinity> xkb is completely stillborn.
<infinity> mdz : Really?... Interesting.  Many others have been complaining that xkb won't load or won't load their keymap, etc.
<mdz> infinity: so far I've only upgraded my ltsp test laptop
<mdz> where X keymap configuration has never worked
<Lathiat> xkb errors on gnome start here
<mdz> because it was waiting on the changes that went into -25
<siretart> did anyone try to use rpcgen with gcc-4.0? I have a package here were sourcefiles created by rpcgen FTBFS with gcc-4.0 :(
<infinity> Right, well going from "doesn't work" to "doesn't work" wouldn't hurt much. :)
<mdz> yeah, the changes didn't start it working either
<ogra> argh, my at key is screwed....
<Lathiat> ogra: which key? ;)
<ogra> i cant type mail adresses 
<danielki> copy this one: @
<danielki> (:
<ogra> heh
<infinity> (Breaking things horribly is a good way to see who is and isn't running breezy, though...)
<Lathiat> ogra: change keyboard maps :)
<lamont> seb128: nm
<ogra> hmmm, gnome-keyborad-settings crashes....
<ogra> ** (gnome-keyboard-properties:13906): CRITICAL **: XkbGetKeyboard failed to get keyboard from the server!
<ogra> fun
<mdz> I can't even generate a config file: xserver-xorg/config/inputdevice/keyboard/layout not set.  Aborting.
<infinity> Hrm.  Was all the xkb stuff working happily in -24?
<Lathiat> yeh
<mdz> "working" as in, it at least generated a config with the default value
<infinity> The biggest change in that are is actually him reverting a patch (backport of a HEAD cleanup of xkb) which was added in -24, removed in -25...
<infinity> s/that are/that area/
<infinity> mdz : Well, it's hard to generate a config when every xkb-related tool you use to lint your keymap now chokes and claims the keymaps are invalid.
<mdz> so the vesa thing was a red herring
<infinity> Oh?
<mdz> that was just "I didn't generate a config at all"; that's the one which was there from installing in the chroot
<infinity> Ah. :)
<infinity> So, we're at "mouse config got weird", "xkb is buggered", and "twm's postinst sucks, but only one user cares, cause no one else installs it"
<infinity> Right?
<infinity> (Of course, the 3rd bug is the simplest to fix... Always is)
<infinity> I wonder if reintroducing this XKB HEAD cleanup patch would magically fix everyone's issues.
<infinity> Maybe we should wait for daniels to find an airport in Germany and ask him why he reverted it...
<infinity> Or... Not care and just put it back.  <experiments>
<mdz> there is no default for xserver-xorg/config/inputdevice/keyboard/layout
<mdz> and yet it blows up if it isn't set
<infinity> Or, the third option: go to bed, cause it's 3am.  Why don't I notice these things until my girlfriend yells at me? :)
<mdz> the mouse config thing should be easy to fix; we can revert that patch
<mdz> no clue what it was intended to do, since it wasn't in the changelog
<infinity> Yeah.  Well, I'll be happy to play with both in the morning, if daniels doesn't show up and fix them first.
<infinity> But right now is apparently a "Bad Time", since I've been working all day and have only now realised this.
<infinity> I wonder if perhaps the stuff that was reverted from -24 to -25 was just a "switching from one working directory to another" brain fart.
<infinity> It's not typical for people to go back and edit their old changelog entries when reverting changes, afterall. :)
<infinity> Anyhow.  Bed.  Xorg in the morning, if others don't beat me to it.
<infinity> (feel free to beat me to it)
<pitti> sleep well, infinity!
<mdke> sabdfl, you around?
<sabdfl> yes
<mdke> https://wiki.ubuntu.com/MarksHoaryGoals <--need this?
<mdke> oh
<mdke> i just saw its linked in your homepage so there is no danger of it disappearing
<mdke> sorry to bother
<sabdfl> jdub, daniels, seb128: can we use OSD for the battery-low indicators, rather than the modeless dialog that currently pops up?
<tseng> sabdfl: xosd afaik still doesnt use freetype
<tseng> it looks pretty ugly
<Lathiat> theres a gnome osd
<Lathiat> (that does afaik)
<Lathiat> sarge-hoary works?
* dilinger snickers
<dilinger> [14-Jun-2005]   We just released the first release candidate for PHP 4.4.0. This is a bug-fix only release, the increased middle digit is needed because this release changes PHP's Internal API that causes existing third-party binary extensions to be incompatible with the new version.
<dilinger> groundbreaking
<Clint> mmm... internal api bugfix
<Keybuk> anyone know stuff about postgresql?
<Keybuk> pitti?
<Keybuk> meh, figured it
<Keybuk> someone moved the socket
<thom> Kamion: are current breezy dailies somewhere close to installable?
<Kamion> thom: no, xterm's broken
<Kamion> mdz: I'll remove that from desktop for the moment just so that we have working dailies
<Kamion> thom: first stage works fine though
<mdz> Kamion: fine with me
* Treenaks upgrades gdm and watches some weird X session manager appear
<Treenaks> (it could be an X thing though)
<Lathiat> Treenaks: choose GNOME fromthe session list and it goes away
<Lathiat> gdm seems tobe losing the defaultsession
<Treenaks> Lathiat: yes, but that's not the Best solution
<Lathiat> and starting some weirdarse thing
<Treenaks> also, for the record, network-manager sucks (i.e. it can't connect to my simple WEP-encrypted wifi net)
<Treenaks> Lathiat: oh, try ctrl+alt+f1
<Lathiat> its suposed to ask for the key if you click on a wep net
<Treenaks> Lathiat: it does ask.. then I select "Hex key" and enter my key in hex
<Treenaks> Lathiat: then it waits for a while, iwconfig shows everything works
<Treenaks> Lathiat: but nm-applet thinks I'm not connected, and its right
<Lathiat> nm has never ever worked for me once
<Lathiat> not with my orinoco wireless,and not with my new b44+ipw2200 laptop
<Treenaks> Lathiat: I tried with prism54 and ipw2200
<Lathiat> anyone know why im getting "/dev/sda1 is not removable" errors (error mounting my external usb drive)
<fabbione> maswan: ping?
<thom> ber, ghc is gonna need rebootstrapping, or some nasty kludging
<fabbione> thom: yup... ghc is a pain
<fabbione> i did look at it not too long ago
<fabbione> and the worst is that even in bootstrap is FTBFS due to gcc-4.0 or something else in the toolchain
<thom> oh, joy
<jdub> seb128: around?
<jdub> never mind
<jdub> well, maybe
<maswan> fabbione: pong
<Lathiat> im also getting a mass of "IPP request failedwith status 1030"from gnome-cups-icon
<maswan> elmo_: ping?
<fabbione> maswan: hey dude..
<mdz> fabbione: can you explain auto_answer in xserver-xorg.config?
<mdz> it makes no sense to me
<fabbione> mdz: i can look at it.. but i am not sure it's the same code i knew a long time ago
<mdz> it has been there a long time
<fabbione> mdz: it has always been there.. but i dunno if daniels did change it
<mdz> the name of the function does not seem to describe what it does
<fabbione> let me check.. but i need to run after.. wife is waiting me to go to the concert
<fabbione> mdz: ok.. now i remember
<fabbione> do you recall a long time ago when we were killing xfree86 debconf questions?
<fabbione> the problem was (and is for Debian) that we didn't have a proper way to answer all the questions
<fabbione> now.. this is ok if you have a debconf frontend that allow the user to interact with the installation
<fabbione> but that's not true in non-interactive or some other combination
<fabbione> auto_answer tries to answer these questions, if a previous answer was already present in the debconf db
<fabbione> sort of "use debconf" as a registry
<fabbione> note that when auto_answer is called there are other functions involved to gather default answers and stuff like that
<fabbione> does it make more sense now?
<mdz> fabbione: it seems to me that the end result is just to set a new default for the question; wouldn't this be better done with a debconf substitution?
<fabbione> mdz: i don't really know.. i didn't design that :) it's something coming from Xfree86 / Debian
<fabbione> i need to go now...
<fabbione> cya tomorrow or monday
<mdz> fabbione: bye
<mdz> and thanks
<fabbione> mdz: no problem :) sorry that i don't have more time.. but we are alrady a bit late :)
<fabbione> bye
<mdz> mdke: how is the new wiki working out?
<Kamion> you can't do debconf defaults with SUBST; you have to use SET
<Kamion> which means you also have to test whether the current value of the question differs from the default (and possibly from previous defaults), etc.
<maswan> hmm.. are dns-records for archive.ubuntu.com strictly elmo's department?
<maswan> or can someone else take 130.239.18.137 out?
<Kamion> elmo/thom probably
* maswan summons elmo/thom :)
<maswan> damn, need to check my summoning spells. :)
<maswan> hi sabdfl, sorry, that was a refernce to me hitting enter on "+ maswan summons elmo/thom :)" 20 seconds before you joined
<mxpxpod> ogra: ping
<jdub> daniels: around?
<torkel> maswan: if the slaves are asleep summon the big boss? :-)
<sabdfl> maswan: YOU CALLED?
<tseng> who dares awake the great sabdfl 
* maswan trembles in fear
<maswan> sabdfl: oops. I tried summoning the elmo, but must have aimed wrong.
* maswan slowly backs out and says five quick hail ubuntu prayers. ;)
<sabdfl> ALL IS PEACEFUL
<sabdfl> night ;-)
<mxpxpod> ogra: are you around?
<tseng> ogra: its getting way past working hours there
<tseng> er, mxpxpod.
<mxpxpod> tseng: hrmm
<mxpxpod> tseng: I need to talk to him about using pmud instead of pbbuttonsd in the next release of ubuntu
<mxpxpod> since the latest release of pbbuttonsd really really really sucks
<tseng> isnt that thom's baby?
<mxpxpod> IIRC, he told me to talk to ogra about it
<tseng> huh
<tseng> i didnt know ogra owned a ppc
<mxpxpod> oh, maybe I do need to talk to thom about it
<jdub> holy crap!
<jdub> i can type in X again!
<tseng> jdub!
<tseng> pants off.
<mxpxpod> anyway, I hacked powermanagement-interface to work with both pmud and pbbuttonsd
<ogra> mxpxpod, hey
<ogra> mxpxpod, yes, thom is the right one...
<mxpxpod> ogra: ok
<mxpxpod> ogra: how's gnome-power coming along in breezy?
* jdub reboots for new kernel love.
* tseng successfully routes the packet
<ogra> mxpxpod, i'm currently busy with edubuntu, next week too.... then i've time to care about other stuff again....
<mxpxpod> ogra: ah, ok
<mxpxpod> tseng: you've got a ppc, right?
<tseng> no sir
<mxpxpod> nevermind
<ogra> mxpxpod, gnome-power is missing the connection to pmi, but then it will be fine... i also have to decide what to do about screensaver power management, since it duplicates the functions now
<mxpxpod> heh
<mxpxpod> ogra: well, like I said to tseng, I hacked pmi to work with pmud
<ogra> nice
<mxpxpod> and I know thom has wanted to get rid of pbbuttonsd for a loooong time
<mxpxpod> now I just need to figure out how to do a diff of a package while I'm building it
<ogra> but i' not sure if thats necessary anymore, since hal is the input for gnome-power... and it cares for pmu devices as well
<mxpxpod> ogra: ahhh
<mxpxpod> that'd be really nice
<Kamion> does pmud have all the hotkey-handling stuff?
<ogra> but ask thom, he's the pbuttonsd guy
<mxpxpod> Kamion: no, gnome would handle that
<Kamion> eh, not everyone uses GNOME
<mxpxpod> my bad
<mxpxpod> Kamion: actually, I think hal can handle the power button
<seb128> jdub: pong
<seb128> lamont: pong?
<mxpxpod> ogra: ok, another question regarding hal/gnome-power... will those two actually sleep the laptop, or will we need to invoke something when a signal is fired
<lamont> seb128: no more issue
<ogra> gome-power just sends a dbus message
<ogra> gnome even
<lamont> seb128: unless you have one for me....
<ogra> so we need a listener at the other end... thats currently missing
<mxpxpod> ogra: ah
<mxpxpod> ogra: i.e. the connection to pmi
<ogra> yep
<mxpxpod> gotcha
<mxpxpod> so we'll need a pmi daemon listening or something like that
<seb128> lamont: nop, just a pong in case of you need me for something
<ogra> for example, yes.... or a gnome-power-backendd to be replaced by a kde-powerd or a xfce-powerd ....
<mxpxpod> ogra: ah, cool
<lamont> seb128: thansk
<seb128> np :)
<mxpxpod> how close is breezy to be ready to use?
<mxpxpod> and also, is network manager ready for use on ubuntu?
<tseng> jdub can type in X
<ogra> tseng, i heard about that too.... he must be privileged, i cant really type in X
<mxpxpod> ok, this may be a dumb question, but what exactly does network manager do?
<tseng> it screws up your network connection
<mxpxpod> does it do what netapplet does?
<tseng> and in the case of kerberos authetication
<tseng> tries really hard to lock you out of your pc
<mxpxpod> and will it automatically connect your ethernet when you plug it in?
<jdub> network-manager is not ready to use
<jdub> i just tried
<mxpxpod> heh, ok
<jdub> mdz: whoa, champion (xorg upload)
<mdz> it doesn't fix the xkb stuff; I didn't have time to look into that one
<jdub> fixed a lot of annoying crap though!
<jdub> THREE CHEERS FOR MDZ!
<mdz> it looks like daniels may have inadvertently dropped some stuff from about -21
<tseng> we should take turns uploading xorg
<tseng> and see where we end up
<jdub> say hooray you bastards.
<lamont> seb128: actually, any gtk+2.0 uploads planned soon?
<seb128> 2.6.8 ftbfs?
<seb128> nop, it doesn't
<lamont> seb128: there was this little regression in gcc-4.0 for hppa...
<seb128> binary-NMU? :)
<seb128> jdub: you pinged for a reason?
<lamont> that's an option for us poor ports second-class citizens, as long as there's a -ubuntu version
<lamont> (or a -build version)
<lamont> seb128: anything that does function pointer compares may get bad results from the compare, and behave incorrectly.
<lamont> like, say, callbacks. :-(
<lamont> that bug would go a long way to explaining why gdk-pixbuf-query-loaders sometimes works, sometimes hangs, no?
<jdub> seb128: no, it was just a random drive-by ping
<seb128> k
<seb128> lamont: hum, gdk-pixbuf-query-loaders hangs sometimes? weird
<lamont> only on hppa
<seb128> iz hppa bog :)
<lamont> and the gcc regression is that (on hppa) function pointers don't get canonized before getting compared, and therefore things that should compare equal say 'unequal'
<seb128> anyway you want a source upload? there is some translation issue that could pretext a new upload :p
<lamont> and yes, is optimizer/hppa b ug
<seb128> k, I understand
<lamont> dunno if it would fix it or not
<seb128> I'll probably upload one new package on monday
<lamont> I mean, it could be anything that it calls, too... :-)
<lamont> and since it already has a -1ubuntu1 version, I can binNMU it, although it makes elmo cry
<lamont> (problem with binNMU's is that 1.0.1 > 1ubuntu1 --> bad juju)
<seb128> 1ubuntu1.0.1 ?
<jdub> whoa!
<jdub> latest kernel also makes my laptop audio not sound like crap
<doko> fabbione: the new kernel on amd64 is fun ... no sata detection, no cpu frequency scaling, bad sound ...
<tseng> jdub: eh?
<jdub> i used to get a yucky buzzing noise
<tseng> hm
<ivoks> hm... X in breezy after upgrade don't listen to xorg.conf about keyboard layout
<jdub> ivoks: an upload was just done to fix that
<ivoks> oh, thanx
<jdub> ivoks: build will be available soon
<jdub> ivoks: temporary fix -> dpkg-reconfigure xserver-xorg
<ivoks> great
<jdub> don't set --priority=high :)
<ivoks> jdub: ")
<jdub> type in 'us' when it asks you for the keyboard layout
<ivoks> i tried that, but did't work
* doko looks up buzzy
<ivoks> problem is that it assumes 101 keys, instad of 105
<lamont> seb 1ubuntu1.0.1 requires that -1ubuntu1 or -1ubuntu1.0 source be in the archive.
<lamont> hence if the package has a raw debian version, I have no choice but a sourceful upload
<seb128> right, but gtk is 1ubuntu1
<lamont> mdz/jdub; thoughts on the right answer when a 2nd class arch needs to rebuild a package or 2000 - do we hate binNMU's that much?
<lamont> seb128: exactly
<jdub> not a q for me :)
<lamont> hence I just have to decide if I want to introduce a binNMU into the archive, or be a good little boy.
<mdz> lamont: 2000?
<lamont> mdz: well, one could be more careful and examine the source of everything that hppa has built using gcc-4.0 or g++4.0 to see if it compares function pointers...
<lamont> for the moment, I'm ignoring it, and planning an as-discovered solution model
<lamont> compiling with -O1 makes the problem go away (although no guarantees came with that answer)
<jdub> o/~ we are the badgers, we are the badgers, no time for hedgehogs, cause we are the badgers! o/~
<ivoks> :)
<lamont> but a sourceful upload for most of them would be a waste of mirror-bandwidth
<lamont> mdz: on the bright side, we force gcc-3.4 for glibc and gcc-4.0.  Or maybe not -- they break big time.
<lamont> (actually, gcc-4.0 might be built with gcc-4.0... that'd be bad
<mdz> seb128: the xdmcp greeter seems to fail to start in my gdm now
<mdz> seb128: is that just because I've upgraded and not restarted gdm yet?
<seb128> mdz: so sure, could you restart gdm? If that still happens then that's a bug ...
<mdz> seb128: I would have to log out :-)
<seb128> correct :)
<seb128> what does it say?
<mdz> and lose all my firefox state and emacs state and xchat state :-)
<mdz> a dialog opens (on the thin client) saying the greeter could not be started and the display will be disabled
<mdz> "Cannot start the greeter program, you will not be able to log in.  This "
<mdz> "display will be disabled.  Try logging in by other means and editing the "
<mdz> "configuration file"
<mdz> daemon/slave.c:2665
<mdz> 2792
<mdz> that po file was out of date :-)
<seb128> hum, lemme try here
<mdz> seb128: did gdmlogin move to a new location?
<seb128> yep
<mdz> ah, ok
<mdz> that path is compiled in it looks like
<seb128> they moved binaries from /usr/bin to /usr/sbin or /usr/lib
<mdz> I probably just need to restart it, then
<mdz> I hate logging out
<seb128> he he
<mdz> seb128: did you see when I was talking about processes being left behind from the session, with connections to the X server?
<mdz> it causes some problems with LTSP-over-ssh
<seb128> mdz: nop, when was that? what processes?
<mdz> bonobo-activation-server, gnome-settings-daemon, xscreensaver
<mdz> gam_server also, but I don't think that talks to X, does it?
<mdz> no, it doesn't
<seb128> no 
<mdz> so that one is ok
<seb128> I'll have a look for b-a-s
<mdz> bonobo is ok too
<seb128> weird for g-s-d, I'm pretty sure it exits with gnome-session here
<mdz> I just need for xscreensaver and g-s-d to die
<mdz> oh, nm
<seb128> ?
<mdz> killing g-s-d seemed to cause b-a-s to exit
<mdz> let me do a better test
<mdz> mizar:[/tmp/gdm-2.8.0.0]  sudo lsof -i G -e '->localhost:6010'
<mdz> gnome-set  8704 testuser    3u  IPv4 3010231       TCP localhost:55874->localhost:6010 (ESTABLISHED)
<mdz> xscreensa  8718 testuser    3u  IPv4 3012713       TCP localhost:57066->localhost:6010 (ESTABLISHED)
<mdz> so g-s-d and xscreensaver are the only ones connected to the X server
<mdz> the others are not important for this issue
<seb128> mdz: lemme try here
<seb128> mdz: no xscreensaver or gnome-settings-daemon after a logout here
<mdz> seb128: hmmm
<seb128> mdz: gnome-session should really stop gnome-settings-daemon
<mdz> perhaps I should strace it
<mdz> ?
<seb128> and according to Np237 xscreensaver exits when the connexion to X is broken
<mdz> seb128: right, this isn't a problem with gdm logins because it resets the X server
<mdz> I can't reset the X server because I can't tell when the session has ended
<mdz> because these processes cause ssh to keep running
<mdz> I run ssh, wait for it to exit, and then reset the server
<mdz> gdm runs gnome-session, waits for it to exit, and then resets
<seb128> right
<mdz> gnome-session exits when it exits, but ssh doesn't exit until all connections are closed
<seb128> k, so that's an issue for xscreensaver
<seb128> but should not for gnome-settings-daemon, since you logout, which closes gnome-session and should stop it
<lamont> Kamion: thoughts on 314368 and how it affects breezy?  likewise, any issue with dropping the modutils udeb entirely?
<jbailey> lamont: I will likely want to compile modutils with klibc or uclibc anyway for the initramfs stuff I'm doing.
<jbailey> lamont: That might solve the problem in a different way?
<mpt> mvo: To answer your question from a while back, it's not currently possible to add comments to a Malone task, but there will soon be an "Explanation of status" field where you can put task-specific info
<mvo> mpt: aha, thanks
<mpt> and update it over time, wiki-like
<tseng> mako: holy crap you used coq in a poem
<jdub> seb128: yo?
<seb128> jdub: pong
<jdub> seb128: esound 0.2.36?
<jdub> seb128: want me to turn it around?
<seb128> jdub: I don't care about esound, feel free to do it :)
<siretart> hi folks
<jdub> seb128: you make esound feel unloved
<seb128> it is
<siretart> maybe a stupid question, but is it possible to distribute binary contents in debian/? like debian/package.png?
* seb128 kicks esound
<jdub> heh
<jdub> harsh.
<jdub> but fair.
<jdub> MORE X!
<jdub> MIRROR ME HARDER!
<mako> tseng: OF COURSE I USED COQ
<tseng> mako++
<mako> Super bonobo sex atop Alex!
<maswan> jdub: "it's only bandwidth"? :)
<tseng> jdub: what is my rss feed on puc?
<jdub> maswan: says you, swede!
<tseng> jdub: the one wordpress is linking to seems busted
<jdub> [http://smarterits.com/~brandon/log/wp-rss2.php] 
<tseng> jdub: cheers
<maswan> jdub: well, I wouldn't like to be living on an island where all the bits go through a single tiny straw.. :)
* jdub sucks harder.
<jdub> it's like a thickshake
<tseng> yay for context
<jdub> the harder you suck, the less you get
<maswan> tseng: It was tempting, but I didn't dare add encouraging comments to that.
<tseng> maswan: jeff needs no encouragment
<maswan> tseng: exactly. :)
<jdub> i'd take offense at this, if i thought i could get away with it
<ogra> siretart, uuencode the png, then it becomes text data.... uudecode it in the rules file
<jdub> i wonder what hct does about binary files
<siretart> ogra: yes, but then I would have to build depend on sharutils :/
<ogra> siretart, whats wrong with that ?
<siretart> well, If there is really no other way..
<jdub> siretart: no kittens will be killed for that
<siretart> ok. will do
<ogra> siretart, its the best way to do it... the next step is to convice upstream to use your png, so it will get included in the next upstream release ;)
<siretart> ok
#ubuntu-devel 2005-06-25
<robertj> ooh avahi shiny
<syndicate> if you wanted to write an applet in Gnome, would you use libpanel-applet2?
<mdke> mdke, new wiki is awesome
<tseng> tseng, i agree
<mdke> damn
<mdke> good point
<mdke> mdz, ^^
<som> hrmm, ppp_mppe_mppc isn't getting probed in by pptpd...
<robertj> is that the intended functionality?
<robertj> ppp-compress-18 is aliased to ppp_mppe but ppp_mppe_mppc is needed for pptpd to play nice with OS X & Windows machines
<tseng> puc looks stupid with 3 of me
<schweeb> tseng: I agree, less tseng, more jdub
<tseng> schweeb: dude jdub blogs are all like gnomegnomegnomegnomebadgerbadgerbadger
<schweeb> hehe
<schweeb> and tseng blogs are all omgmonomonomonoiambrandonhalemonomono
<tseng> yes
<tseng> infinately cooler
<schweeb> well, they would be
<schweeb> if you could frigging spell infinitely
<tseng> gosh
<jdub> MORE X!
<mdz> jdub: EVERYONE GETS A PIECE
<mdz> tear off a hunk and start chewing
<mdke> mdz, how are you liking the new wiki?
<mdke> we are loving it
<mdke> TM
<mdke> some teething problems but it'll get there
<mdz> mdke: I much prefer moin; I'm glad that the transition seems to have gone well
<mdke> :)
<mdke> its working better too: speed and caching
<mdke> makes such a difference
<mdke> henrik will be sending a mail detailed any outstanding issues
<mdke> mdz, one to note right now is that subscriptions have not been carried over, dunno if you use that
<mdke> its not a biggie, given that diffs and RecentChanges are so much better
<mdz> mdke: yeah, I was subscribed to the whole wiki as a substitute for RecentChanges
<mdke> *grins*
<mdke> me too
<mdz> so now I'm only resubscribing to a few pages
<mdke> cool
<jdub> mdz: enjoying reading the ltsp changelogs ;)
<mdz> jdub: it's now at a point where if you want to play with it, the only manual portion of the setup is dhcpd.conf
<mdz> everything else just works
<jdub> mdz: yikes
<jdub> mdz: is there a setup guide?
<jdub> i love seeing tell-tale signs of ubuntu in project screenshots
<jdub> http://www.ndesk.org/nbind/
<bob2> the GIGANTIC date div on planet is a little surprising
<jbailey> jdub: The theme on the window?
<Burgundavia> jdub, thoughts? (who should this person talk to?) http://www.ubuntuforums.org/showthread.php?t=42465
<jdub> Burgundavia: technically extremely difficult
<jdub> and requires lots of integration
<jdub> hard integration
<jdub> totally non-breezy
<Burgundavia> ok
* jdub returns with NO FACIAL HAIR
<Lathiat> We're all screwed now
<|QuaD-> who maintains gaim?
<Jimbob> Maintainer: Robert McQueen <robot101@debian.org>
<Jimbob> "apt-cache show gaim"
<|QuaD-> Jimbob: i was referring to for ubuntu
<|QuaD-> seems that si the debian maintainer
<jdub> |QuaD-: look at the changelog :)
<|QuaD-> jdub: how?
<Jimbob> /usr/share/doc/gaim/changelog.Debian.gz -- Martin Pitt <martin.pitt@ubuntu.com>
<|QuaD-> oh :)
<|QuaD-> he isn't areound :(
<|QuaD-> i was wondering if he would include a cool new plugin
<|QuaD-> actually not new
<|QuaD-> http://gaim-assistant.tulg.org/
<bob2> jdub: blog it!
<srbaker> i don't suppoase anyone has made dvd images for ubuntu?
<srbaker> all i have are blank dvds
<srbaker> for hoary.  i'd rather not put breezy on my system yet
<Lathiat> srbaker: There are hoary dvd images
<srbaker> Lathiat, i can't find them.  can you point me in the right direction?
<Lathiat> http://releases.ubuntu.com/hoary/
<srbaker> aha
<srbaker> the install/live ddvd
<srbaker> got it
<fabbione> morning
<srbaker> it says bittorrent onliy
<Lathiat> So bittorrent it :)
<Lathiat> Now this discussion should really be in #ubuntu
<Lathiat> this channel is for development discussion
<AndyFitz> xorg broken ?
<AndyFitz> meh .. too late  upgraded :-P
<mdz> jdub: setup guide:
<mdz> jdub: 1. install ltsp-server-standalone (or ltsp-server + the pieces you need), 2. configure dhcpd.conf to netboot pxelinux, 3. ltsp-build-client, 4. boot thin client(s)
<mdz> I just need to publish an example for #2 and it should be trivial
<hunger> Is xkb hosed again?
<Amaranth> hunger: Oh dear, people are going to be pissed.
<hunger> Amaranth: Might be me skrewing up my keyboard...
<Amaranth> oh
<hunger> Win-key is gone missing again here... maybe it is just my system.
<Amaranth> well, it's 1:34am and i need to get up early tomorrow, goodnight all
<Q-FUNK> say... when exactly did the wiki move from ubuntulinux.org to ubuntu.com ?
<Q-FUNK> pretty silly now, because I hadn't logged in in a while and forgot which username I had & all.  Galeon used to remember it, but obviously won't if the domain is different.
<desrt> is it appropriate to report stupid little bugs against breezy?
<desrt> (specifically, libxfixes3 is required by a whole whack of stuff, but not formally depended on by anything)
<desrt> is that worth opening?
<fabbione> desrt: a direct dependency is not always required.
<fabbione> is this whack of stuff linked with libxfixes?
<desrt> fabbione; ya
<fabbione> or it is an indirect depends
<desrt> like gnome-*
<desrt> essentially, i can apt-get install gnome-panel without xfixes being installed
<fabbione> desrt: if it is linked, than it should have been added to the Depends: at build time
<desrt> in breezy right now
<fabbione> desrt: gnome-panel is not linked to libxfixes
<fabbione> that's ok
<fabbione> it doesn't need a Depends:
<desrt> ...
<fabbione> ldd /usr/bin/gnome-panel | grep fix
<fabbione> fabbione@gordian:~$ 
<desrt> desrt@moonpix:~$ ldd /usr/bin/gnome-panel | grep fix
<desrt>         libXfixes.so.3 => /usr/X11R6/lib/libXfixes.so.3 (0xb7548000)
<desrt> heh.  weird.
<fabbione> hmm what version of gnome-panel ?
<desrt> 463a5659fe2ef97774f2067295dabcf3  /usr/bin/gnome-panel
<fabbione> let me see if i am one version behind
<desrt> it could easily be that this machine is seriously messed up right now
<fabbione> nah i am checkign... gimme a sec
<desrt> it's gone from hoary to breezy back to hoary and i just brought it to breezy again :)
<fabbione> 463a5659fe2ef97774f2067295dabcf3  /usr/bin/gnome-panel
<fabbione> 463a5659fe2ef97774f2067295dabcf3  /usr/bin/gnome-panel
<fabbione> ops
<fabbione> sorry
<desrt> fun.
<fabbione> ldd /usr/bin/gnome-panel | grep fix
<fabbione> no results
<desrt> i'm just gonna un/reinstall X
<desrt> thanks for the comparison :)
<fabbione> no problem
<ivoks> heh
<ivoks> no fix here too
<desrt> another one, though: ubuntu-desktop doesn't depend on ubuntu-base and i think it should :P
<ivoks> hm... keyboard still not working right in X :(
<Kamion> lamont: the approach in #314368 looks totally sensible for breezy
<Kamion> lamont: we don't need the modutils udebs in Ubuntu, but I can't remember whether anything in Debian uses them
<Keybuk> hmm, I _still_ can't login from gdm
<bob2> tseng: muine doesn't run no more
<Keybuk> so is breezy X working for anyone at the moment?
<thom> works for me
<Keybuk> hmm
<Keybuk> you can login from gdm, and startx on the console?
<Keybuk> startx gives me /usr/bin/X11/X: No such file or directory
<thom> i could yesterday, yeah
<Lathiat> works for me and i have the latest
<Lathiat> Keybuk: make sure ubuntu-desktop is installed?
<Keybuk> Lathiat: it is
<Keybuk> hmm, what makes that symlink
<Keybuk> it looks like daniels moved it to /etc/X11/X
<Keybuk> and xinitrc hasn't caught up
<Keybuk> Lathiat: what does /etc/X11/xinit/xserverrc contain on your box?
<Lathiat> root@ubuntu:~ # cat /etc/X11/xinit/xserverrc
<Lathiat> #!/bin/sh
<Lathiat> exec /usr/bin/X11/X -dpi 100 -nolisten tcp
<Keybuk> do you have a /usr/bin/X11/X ?
<Lathiat> nope
<Lathiat> butit still works
<Keybuk> startx works?  or just gdm?
<doko> the only thing I get is a popup dialog complaining about xkb
<doko> everything else seems to work
<Keybuk> hmm
<Keybuk> now it appears that Xorg isn't setuid root
<sivang> yo all
<Keybuk> changing that file and making Xorg setuid root lets me startx
<Keybuk> but gdm still won't login -- I get a session chooser widget thing that does nothing
<Keybuk> right, so if I explicitly select "GNOME" I can login
<Keybuk> but the "Default Session" thing isn't GNOME
<Lathiat> yeh
<Keybuk> weirdness
* Keybuk hates X
<opi> Hi guys
<opi> (host lists.ubuntu.com[209.61.182.217]  said: 421 Unexpected failure)
<opi> is there anything wrong with ubuntu.com mail server?
<Keybuk> brb, now I have something graphical
<opi> or where should I report that :-)
<opi> (host lists.ubuntu.com[209.61.182.217]  said: 452 Space shortage)
<opi> hmmm
<sabdfl> opi: oops. that's an old box of mine and it's out of disk space
<sabdfl> thanks for the heads up
<opi> sabdfl: no problem
<sabdfl> i'll try fix it, maybe elmo has a plan to move those lists to a newer canonical box
<opi> sabdfl: I just rushed to raport, because it's like that since 2h or so
<dholbach> hi
* mvo is away for a bit to get some food
<opi> OK, my work is done here. I'm moving back to work :P
<tseng> bob2: youd have to be more specific
<bob2> tseng: when I start it, ot does nothing, and venetually comes up with a "time out" error
<bob2> tseng: even after nuking ~/.gnome2/muine/
<tseng> dpkg -l muine* | grep ii
<tseng> ?
<bob2> tseng: 0.8.2-5ubuntu2
<tseng> actually
<tseng> things are going to get alot more broken
<bob2> this is hoary
<tseng> uh
<tseng> WFMAEE
<tseng> (and everyone else?)
<bob2> yeah, and used to work for me
<tseng> ive never heard of muine "timing out"
<tseng> is it timing out to dbus?
<Keybuk> ok... so I can get X to start
<Keybuk> but none of the bucky-bits work on the keyboard
<bob2> Unhandled Exception: DBus.DBusException: No reply within specified time
<bob2> in <0x00167> DBus.Message:SendWithReplyAndBlock ()
<bob2> in <0x000c6> Muine.DBusLib.Player.Proxy:SetWindowVisible (bool)
<bob2> in <0x00112> Muine.Global:Main (string[] )
<bob2> tseng: right
<tseng> there you go
<tseng> fix your dbus
<tseng> :)
<bob2> hrm
<bob2> same error, even after restarting the dbus daemon
<bob2> I'll bitch at daniel when he lands
<Keybuk> is there anything daniels didn't break before he left? :)
<tseng> restarting system dbus daemon, or user dbus?
<tseng> not the same thing
<bob2> system
<tseng> can you start a new session (after insuring there are no left overs from this one)?
<tseng> gnome session i mean
<bob2> ah, user
<bob2> = restart gnome?
<bob2> or in addition to the existing one?
<tseng> i dont know how to do it by hand
<hunger> Wha! The keyboard guessing game in the installer is fun;-)
<tseng> buh we are going to have to --force-overwrite the new mono debs
<dholbach> brb
<tseng> since upstream pulled a fast one on me last release
<dholbach> hrm
<tseng> wb
<dholbach> none of the comments to the xkb bugs was helpful
* dholbach cries desperately
<Keybuk> dholbach: bug#s?
<hunger> dholbach: So there is a new xkb bug?
<dholbach> Keybuk: 11909 and 11931 iirc
<hunger> dholbach: I am seeing it (at least my win key is no longer recognized). How can I help?
<Keybuk> and 10695 and 10939? ;)
<tseng> ok kids, DO NOT install this mono
<tseng> its a bootstrap
<dholbach> hunger: fix "(EE) Couldn't load XKB keymap, falling back to pre-XKB keymap" for me :)
<hunger> dholbach: I am definitly only missing the win key...
<dholbach> writing latex without backslash and curly braces is ... not funny
<Keybuk> I'm missing Compose too
<Keybuk> And AltGr
<dholbach> (not to mention writing C or C++ code)
<hunger> dholbach: Now that you mention those: AltGr is missing too.
<hunger> dholbach: Yes, I got the same error in Xorg.log.
<mdke> everyone has it i think
<dholbach> perhaps i should just grab a pen and some pieces of paper and take a train to the nearest lake and write some pages there
<hunger> Feels good to not be alone after all;-)
<tseng> dput should actualyl show some stuff about the upload
<tseng> speed, progress
<dholbach> tseng: how about some ascii movie, if the upload takes a bit longer? ;-)
<tseng> yes
<hunger> I wonder how my completly custom keyboard mapping managed to turn from xkb into pre-xkb?
<sivang> Hmm does anybody know if gibraltar is non free? looks that way judging by their downloads section
<mdke> smurfix, ping?
<Keybuk> kids ... don't strace X
* dholbach takes some time to comfort Keybuk 
<mdke> *laughs*
<dholbach> Keybuk: i thought about it too :)
<thom> Keybuk: yeah, it has interesting side effects, like hanging your system
<Keybuk> it didn't hang ... it's just went v  e  r  y      s  l  o  w  l  y
<dholbach> (but thought the better of it)
<thom> ah, it hangs my laptop every time
<thom> but that just might be the awfulness of the i810 driver
<Keybuk> well, a lot of stuff is trying to access /usr/X11R6/lib/X11/xkb/...
<Keybuk> which daniels appears to have helpfully ommitted the symlink for
<Keybuk> and /usr/lib/X11/XKeysymDB
<Keybuk> (now /usr/share/X11/XkeysymDB)
<hunger> Keybuk: That does not change anything:-(
<dholbach> i tried to symlink XKeysymDB but that doesnt seem to be enough
<Keybuk> hunger: did you do _both_ ?
<hunger> Keybuk: I did the last time the keyboard was broken.
<__keybuk> well, it's fixed vt-switching
* __keybuk tries logging in
<__keybuk> I got an X and GNOME differ dialog -- and selected GNOME
<__keybuk> yay, and I have Win, AltGr and Compose now
* __keybuk tries logging out and in again
<thom> what the christ does "dpkg (subprocess): unable to execute post-installation script: Exec format error" mean
<dholbach> __keybuk: what should /usr/X11R6/lib/X11/xkb/ point to?
<tseng> perhaps the script is -x?
<mjg59> Is postinst an executable script?
<hunger> __keybuk: So symlinking helps this time round?
<thom> mjg59: yes
<thom> tseng: no
<Keybuk> w00t
<Keybuk> \o/
<Keybuk> no dialogs this time
<Keybuk> syndicate scott% xprop -root | grep XKB
<Keybuk> _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "gb", "", ""
<Keybuk> _XKB_RULES_NAMES(STRING) = "xorg", "pc105", "gb", "", "compose:rctl"
<thom>  "sudo /var/lib/dpkg/info/network-manager.postinst configure" works fine
<Keybuk> hunger: it looks like you need both symlinks
<Keybuk> mjg59: script can't be -x, dpkg would've refused to build the deb
<thom> there's nothing useful in dpkg.log
<Keybuk> thom: ?
<thom> Keybuk: trying to figure out why dpkg is crying about my postinst
<Keybuk> thom: what's the error?
<thom> < thom> what the christ does "dpkg (subprocess): unable to execute post-installation script: Exec format error" mean
<Keybuk>        ENOEXEC
<Keybuk>               An executable is not in a recognised format, is  for  the  wrong
<Keybuk>               architecture,  or has some other format error that means it can
<Keybuk>               not be executed.
<thom> ah, heh. found it. missing !.
<Keybuk> ;)
<Keybuk> yah, is generally bad shabang
<thom> besides that, looks like new NM is hot to trot
<Keybuk> how usable is it at the moment?
<thom> the one i'm just about to upload works great for me
<Keybuk> cool, I shall test
<thom> the one in breezy is known not to work, so don't bother for the next hour or so :-)
<HiddenWolf> omg, I've never seen it so active here on a saturday. :)
<Keybuk> thom: yeah, I tried that one
<Keybuk> I'm trying to ween myself off NIH
<thom> Keybuk: heh
<thom> Uploading via ftp network-manager_0.4.1+cvs20050618-1_source.changes: done.
<thom> Successfully uploaded packages.
<mdke> jdub, around?
<dholbach> Keybuk: thank you :)))
<mdke> we are having some issues with the -doc mailing lists, is anyone else receiving list mail?
<bob2> lists.ubuntu.com is temporarily screwed
<mdke> right
<mdke> ok
<Keybuk> who broke xscreensaver?
<pef> hello
<pef> can someone explains me why oss is not completely deleted (for alsa) from ubuntu ?
<bob2> because not everything does alsa
<pef> bob2: have you examples (apps ?)
<bob2> no idea
<dholbach> see you later
<smurfix> mdke: 
<mdke> *grins*
<mdke> smurfix, did you add #ubuntu-it-meeting to LoCoBot?
<smurfix> it's there now
<mdke> bingo
<mdke> thanks :D
<smurfix> I forgot to re-add it after freenode annoyed me with a "you're on too many channels" message
<mdke> idiots
<mdke> smurfix, so is there a way to get on more channels you think?
<smurfix> I don't know, I'll have to ask them; at the moment there's a locobt and a locobot2 *shrug*
<mdke> ok
<mdke> well thanks v much for doing that
<mdke> its a cool service
<smurfix> np
<ogra> Keybuk, whats broken in xscreensaver ?
<Keybuk> ogra: it has the old-fashioned jwzware password dialog
<Keybuk> and not the Ubuntu one
<ogra> Keybuk, http://www.grawert.net/xss_mockup.png
<ogra> Keybuk, it has a new login button, and jwz changed all xpm funcition names internally.... so i hav to rewrite the whole stuff :-/
<Keybuk> right
<Keybuk> is there any particular reason we don't make it look _exactly_ like the gdm greeter?
<Keybuk> they see that for logging in, and for switching users, so it makes some sense to me that they'd see it for unlocking screen too
<torkel> ogra: looks really nice. Two things I miss though. A clock and for how long it has been locked
<ogra> torkel, nope, new concept ;)
<ogra> (how long it has been locked was never included)
<torkel> ogra: I know, and I have missed it all these years :-)
<ogra> torkel, the next version should just reset the timeout on every keystroke, so it closes only if there is really no input for some while
<ogra> Keybuk, because we have found nobody to do it.... vunz wants to do it, butnot in breezy time
<ogra> Keybuk, so currently we fall back on my old dialog...with modifications
<Keybuk> still better than jwzware :)
<ogra> yes...
<torkel> Keybuk: everything is better than jwzware :-)
<ogra> jdub's blogentry about freescreensave made me think about it... we probably should do it :)
<Keybuk> jwz has the UI instinct of an octopus
<ogra> hehe
<ogra> and weird ideas of copyrights
<ogra>    change the logo that xscreensaver displays on the splash screen and
<ogra>    password dialog, please don't.  The logo is xscreensaver's identity.
<ogra>    You wouldn't alter the name or copyright notice on a program that
<ogra>    you didn't write; please don't alter its logo either.
<ogra>  */
<ogra> a comment from jwz 
<Lathiat> ogra: heh
<thom> right, please test newest network-manager, please
<thom> well, when it gets to the archive
<doko> pittiping
<doko> pitti: ping
<doko> :)
<ska-fan> no route to host
<ogra> thom, do you have a version that builds now ?
<ogra> (last upload failed)
<ogra> chown -R bind:bind debian/network-manager/var/lib/NetworkManager
<ogra> 1526	chown: `bind:bind': invalid user
<thom> ogra: yes, 2 is already uploaded and built on all arches
<ogra> ah, ok
<ogra> i didnt see it on -changes
<thom> ah
<thom> yeah; it's in the archive and downloadable now
<ogra> btw, it doesnt work with my pcmcia card to well....
<thom> try the new one, please. and then file a bug :-)
<ogra> its a common problem.... that lies rather on the HAL level....since that card doesnt support network scanning and HAL doesnt even recognize it as wlan
<lamont> wooo hooo... xpaint forkbomb-of-xorg-death
<thom> ogra: ah
<ogra> hmpf
<Keybuk> thom: so, I installed network-manager, now what? ;)
<Keybuk> ah, it's still an icon?
<Keybuk> thom: it thinks my signal is half of what it is
<Keybuk> and now it thinks it's 8% not 80% :p
<robertj> heya ogra, from what I understand, pptpd won't accept windows or mac clients with the default set of module aliases
<Treenaks> Keybuk: wow, you can connect to your network with n-m ?
<robertj> has this been discussed before?
<Keybuk> Treenaks: yeah, and my neighbour's :p
<Treenaks> Keybuk: wow..
<Treenaks> Keybuk: I can't connect to any networks
<robertj> without ppp_mppe_mppc it's very unhappy, but apparently ppp-compress-18 is aliased to plain old ppp_mppe
<Treenaks> robertj: ppp?!
<tseng> have you filed a bug assigned to kernel team?
<Treenaks> robertj: what does my WEP-encrypted wifi network have to do with ppp?
<robertj> Treenaks: it doesn't different question
<Treenaks> robertj: ah ok :) nm then
<robertj> Treenaks: This is needed to get pptpd to play nicely
<robertj> tseng: is that for me?
<tseng> robertj: yes
<tseng> christ me, NM actually did something
<robertj> tseng: well its probably a policy question
<robertj> because it seems that that compression implementation is patented
<tseng> well if you file a bug or post to a mailing list instead of asking on irc at odd times
<tseng> you are more likely to hear about policy or whatever the reasoning is
<robertj> I just wanted to check here before bothering the list
<tseng> well it sounds like you have a valid question, please pose it somewhere less volatile
<tseng> things on irc are lost instantly if the right person isnt watching
<robertj> yeah, I will
<tseng> thanks :)
<robertj> I'm actually going to wait and talk to a fellow in pptp when he signs on that will know if there is a way to disable this compression and still talk to microsoft clients
<robertj> because if so, that seems like the only viable thing to do
<robertj> btw, I finally got avahi compiled, whee.
<tseng> thom: it actually kind of sort of works sometimes
<tseng> thom: congrats
<pitti> Hi
<LinuxJones> hello pitti 
<dhonn> is there a way to make a gnome panel not "always on top"?
<mdke> dhonn, if you ask in #ubuntu, they should be able to help
<dhonn> it needs to be developed
<mdke> oh, sorry misunderstood ya
<mdke> you don't like the properties "autohide" thing?
<dhonn> theres a bug where transparent panels dont show whats underneath them.  you just see the bg image and not underlapping windows under them
<mdke> is that a bug?
<mdke> or just lack of real transparency
<dhonn> both
<dhonn> lol
<mdke> well i don't know much about it, but I can't see real transparency being implemented in gnome-panel for a while
<mdke> you can get it with xcompmgr and transcod tho
<mdke> argh
<mdke> transset
<thom> tseng: *giggle*
<|QuaD-> pitti: you around?
<pitti> |QuaD-: yes
<|QuaD-> pitti: you package gaim right?
<pitti> no, that's seb128
<|QuaD-> oh ok
<pitti> |QuaD-: I do the security updates, though
<|QuaD-> pitti: i was wondering if it would be possible to have a plugin included, but i gotta talk to seb :)
<pitti> yes, that'd be better
<|QuaD-> pitti: thanks
<pitti> no problem :-)
<mdke> mako, around perchance?
<sivang> pitti: yellow :-) 'sup?
<pitti> sivang: just returned from a nice 50 km biking tour, I feel great :-) and you? (and what about yellow?)
<mdke> has anyone any news about the mailing lists?
<zul> they're down?
<mdke> i haven't had any mail for 14 hours
<mdke> since about 2 am UTC
<bob2> some are down
<bob2> only the ones on rince
<mdke> ah right
<mdke> bob2, is there an ETA for getting them back up?
<mdke> i guess its a weekend...
<bob2> I have no idea
<bob2> go play in the park or something ;p
<mdke> *grins*
<mdke> i'm english
<bob2> ah
<mdke> i can't go outside because it will be too hot or too cold
<mdke> depending
<bob2> you could go drink tea and whinge about the weather instead, then ;p
<bob2> haha
<sivang> pitti: ah , had lost a debian router this weekend but other then that, nothing special ;-)
<sivang> pitti: yellow is like hello, from some stupid joke I heaed
<pitti> Hi sabdfl 
<doko> pitti: unstable builds postgresql-8.0-pljava-gcj, but not breezy?
<pitti> doko: that's not my package, but Peter Eisentraut's... it isn't in breezy yet?
<pitti> it could be NEW
<doko> ahh, ok. we'll break libgcj6 compatibility with the next upload
<wasabi> huh what's this
<wasabi> Hi Jerry,
<wasabi> I saw some of your posts on the Ubuntu mailing list and thought you might be interested in taking a look at a book proposal we have and 
<wasabi> doing a quick review. Does that sound like something you'd like to do? 
<wasabi> heh. I don't remember ever posting anything remotely intelligent to either Ubuntu list.
<sabdfl> hey all
<two-face> Hi
<two-face> I'd like to know if Ubuntu is going to follow Debian if the latter decides to remove all GFDL docs
<doko> wasabi: we need to remove the java-gcj-compat dependency from the lib*-java packages. we don't want to have the compilers installed for a runtime dependency
<two-face> hi doko
<doko> two-face: no
<two-face> doko, so packages will have to be forked?
<siretart> is it possible that a source package creates binary packages in different sections?
* Treenaks pokes xkb
<two-face> siretart, yes
<two-face> doko, i'm asking since i comaintain emacs, so i'd like things done in common as much as possible
<doko> two-face: are you debian maintainer?
<hughsie> Anyone want to ask questions about GNOME Power Manager? I'm the main dev.
<two-face> doko, yep
<wasabi> doko, true.
<wasabi> Those should depend on java-runtime I believe.
<doko> wasabi: yes, with a real alternative, so better: gij | java1-runtime. I think java-runtime is deprecated
<wasabi> Oh? I thought it was the other way around.
<doko> two-face: please read mako's mail to debian-private
<doko> wasabi: no
<two-face> doko, i know about it. I'm just anticipating
<asase> can we use breezy?I mean dist-upgrade to breezy? or only some packages? es xorg working ok?
<asase> thanks
<hughsie> I got an email about this http://packages.ubuntu.com/breezy/gnome/gnome-power today.
<zul> hey pitti 
<hughsie> And knowing little about ubuntu I'm asking you guys what the plan is!
<pitti> Hi zul
<doko> two-face: the source has to be modified, so we might not build from the same source. I'd replace the texinfo docs then with dummy docs, so that the build and install process works and only needs to be adapted for the removal of the docs. but if you ship a separate -doc package as well, we might just import that one and relabel it from non-free to main.
<two-face> doko, alright thanks
<Treenaks> muine-dbus, muine-plugin* need NEW love
<Treenaks> I think
<asase> ?
<Treenaks> asase: well, the muine-plugin packages are being built..
<Treenaks> asase: but they're not in Packages
<asase> cool for all those want to get running plugins :)
<asase> I always have to build muine to use some plugins
<asase> :)
<asase> good idea :)
<Treenaks> asase: exactly :)
<srbaker> sigh
<srbaker> what a fucking waste of time.  i tell someone "hi, i've added these features to your software and want to prepare a patch" and he says "no.  i won't accept it even though everyone's crying for it"
<mdke> can someone please hack into the mailing lists server and do a reboot
<mjg59> Why is my apt-get update complaining that the .gz files aren't bzip2ed?
<mjg59> Looks like some sort of content-type issue - it works fine if I use ftp instead
<Keybuk> srbaker: it's his software, maybe he doesn't watch that feature?
<Keybuk> uh, want that feature
<Keybuk> see Havoc Pennington's excellent essays on this issue
<Keybuk> metacity "workspace support" and "windows above the panel" support, passim.
<wasabi> What sort of security issues are presented by having suid root applications connected to the X server?
<wasabi> Curious.
<Keybuk> wasabi: other applications can poke stuff into them
<Keybuk> you can send keypresses, etc.
<Keybuk> so a non-root app can influence a root app
<wasabi> When you say poke do you seriously mean "alter memory used by the program" in a way as to take control of it?
<wasabi> OR just do simple interactions with it.
<Keybuk> no, but (e.g.) if you ran a setuid gnome-terminal -- any other app could run anything as root by sending the shell commands to it
<Keybuk> there's also shared memory between the X server and the application that _may_ be exploitable
<Keybuk> not to mention shared resources
<Keybuk> the general advice is to only connect to the X server as the user, and use a separate setuid sibling process to do the root stuff with IPC between them
<Keybuk> ie. a setuid program that forks, and drops privileges from one side
<wasabi> Is that how gnome-system-tools work?
<Keybuk> yes
<wasabi> And Synaptic? :)
<Keybuk> and even things like gnome-su
<wasabi> Synaptic ignores my theme setting... which worries me.
<Keybuk> synaptic, not sure
<Keybuk> if it's ignoring theme settings, that's a hint of a different user
<Keybuk> actually, don't know if that's how gst works
<Keybuk> but then I really don't like gst
<wasabi> yeah g-s-t ignores themes too
<wasabi> looks like it's just wrapped in gksu
<jdub> GOOD MORNING FREEDOM LOVERS!
<robitaille> good morning in mailing-list-less Ubuntu-land
<tseng> hi jdub 
<tseng> robitaille: blamewaugh.com
<tseng> robitaille: register now.
<mdke> morning jdub 
<tseng> its right next to blamestoner.com
* tseng waits for someone to blame him
<robitaille> it's so quiet today... I actually caught up on all my e-mails.
<jdub> robitaille: what's happening?
<jdub> you're getting errors from the listserv, or did elmo start moving them?
<mdke> just no mail coming through for some lists
<mdke> if they are being moved, that would explain it
* jdub tries to make more free space on the listserv
<Treenaks> jdub: BOFH-style? :)
<jdub> no
<jdub> i don't know half the people who use this machine
<jdub> so i have to be extremely careful
<jdub> and unBOFH
<Treenaks> hm, good point
<Keybuk> aren't we supposed to have our own mailserver by now? ;p
<robitaille> jdub,  according to the ubuntu-devel logs from a few hours ago, sabdfl knows about it...something about a disk full for the listserver computer
<jdub> yeah
<lsuactiafner> does sabdfl mean anything specific to him? cant figure it out
<Keybuk> Self-Appointed Benevolent Dictator For Life
<tseng> or south african
<lsuactiafner> rofl
<tseng> if you like acronym overloading
<lsuactiafner> no if SA was south-african it will prolly be the next several presidents..
<lsuactiafner> funny nickname its cool
<jdub> elmo: ping
<mjg59> Hm. hal-device-manager is giving me "bus instance has no attribute get_service"
<mjg59> And networkmanager isn't finding any devices, which I assume is connected
<robitaille> jdub,  was the listserver move planned for soon?
<jdub> robitaille: very soon, hopefully last week, but elmo and i had a hard time syncing up :)
<tseng> ah 2.6.12
<tseng> about time
<mjg59> Anyone here on Breezy?
<mjg59> If so, does your hal-device-manager contain anything other than the acpi devices?
<mjg59> (assuming gnome-power is installed)
* Keybuk installs gnome-power
<Keybuk> still have devices in hal
<mjg59> Keybuk: Have you restarted dbus?
<Keybuk> no
<mjg59> Can you do that and retry?
* jdub installs gnome-power
<mjg59> Grah
* mjg59 does a dist-upgrade to see if it'll fix things
<jdub> hrm, prefs ui is a bit bong
<jdub> haha
<mjg59> jdub: for gnome-power?
<mjg59> Yeah
<mjg59> There's various bits that need to be stripped out
<jdub> and has so much more stuff when gnome-power-manager is actually running ;)
<jdub> and mine displays two batteries
<mjg59> Do you have two batteries?
<jdub> i *can* have two batterie
<jdub> s
<jdub> and proc/hal says stuff about both
<jdub> hrm
<jdub> $ cat /proc/acpi/battery/BAT1/state
<jdub> present:                 yes
<jdub> capacity state:          ok
<jdub> charging state:          charged
<jdub> present rate:            0 mA
* mjg59 wonders why he has no hal love, then
<jdub> remaining capacity:      1348 mAh
<jdub> present voltage:         16614 mV
<jdub> 
<jdub> $ cat /proc/acpi/battery/BAT2/state
<jdub> present:                 yes
<jdub> capacity state:          ok
<jdub> charging state:          charged
<jdub> present rate:            unknown
<jdub> remaining capacity:      unknown
<jdub> present voltage:         unknown
<jdub> 
<jdub> bong
<nbm> I'd be happy with one working battery monitor.
<jdub> mjg59: dude, what's the userlinux status?
<mjg59> The userlinux status is that Bruce Perens needs to get a life
<mjg59> More seriously, Bruce has been pissing about with the LMI and there's no sign of a release
<tseng> he does it for love, you have to give him credit. and who wouldnt love their aunt tilly?
<mjg59> I don't want Bruce's love
<mjg59> It's deviant
<tseng> (his take on average users + linux is hilarity)
<tseng> he should meet Tim from UDU and get a dose of clue
<mjg59> Aunt Tillie was ESR rather than Bruce
<Keybuk> mjg59: well, restarting dbus crashed the computer
<mjg59> Keybuk: Cool!
<tseng> oh damn i got my oss-luminaries-as-buzzwords mixed
<Keybuk> and on reboot, network-manager fucked up (shock)
<Keybuk> but hal-device-manager had devices int
<Keybuk> in it
<jdub> n-m is a bit patns
<mjg59> It's a bit pants, but it's TEH FUTAR
<robertj> mlg59: what's the LMI?
<mjg59> Linux Mark Institute
<mjg59> The people who are supposed to deal with handing out Linux trademark licenses
<robertj> ohhhh
<robertj> hehe, you think thats sad? I spent an hour today mocking up changes for a the Connect to Server dialog that I don't have the skills to implement :(
<robertj> (I also found out Gazpacho will crash if attempting to save to a directory it doesn't have enough permissions to acccess)
<jdub> mjg59: he reckoned they were ok with it
<jdub> mjg59: more likely his new job doesn't give him time to work on it :)
<mjg59> Argh I need a new keyboard
<robertj> mjg59: if you don't mind ergonomics I recommend the MS Naturals'
<robertj> they are pretty cheap and are... well, ergonomic
<mjg59> robertj: Yeah, but it won't fit my laptop terribly well...
<robertj> mjg59: oh, that's a bummer
<mjg59> I broke the left shift key, which is a bit pants
<robertj> I'm about to sell my old laptop, so I may buy a new one soon
<mjg59> Someone's ebaying a French one, though, so that's a possibility
<robertj> is it possible to get the iso images of the hp ubuntu cds?
<robertj> are they anything special or will they just be standard Breezy images?
<HiddenWolf> HP as in Hewlett Packard?
<robertj> yeah
<HiddenWolf> They're shipping ubuntu?
<robertj> err, vaguely
<Keybuk> in a wishy-washy kind of way
<robertj> from what I understand, if your in eastern europe, africa, or the middle east you can request they send you a cd
<Keybuk> they'll ship you Ubuntu for certain laptops if you ask
<Keybuk> and live in the right place
<robertj> but are they standard cds?
<tseng> it was mentitoned something about extra drivers
<tseng> in the paraphrased press releases
<sivang> Shipping ubuntu as part of their desktop OS ?
<tseng> i mean... technical news sites
<sivang> or for laptops?
<robertj> sivang: laptops
<sivang> robertj: woooo cool
<Keybuk> 6xxx series
<sivang> When is this scheduled?
<mjg59> It's lightly modified
<robertj> mjg59: will we be able to get isos if we get ahold of a matching laptop?
<mjg59> robertj: I'm not sure, I'm afraid
<mjg59> It's all GPLed, so there's certainly nothing stopping you getting a copy off someone who already has a copy
<robertj> so no non-free drivers then
<lamont__> mjg59: are all the tweaks for the nc6000 et al in breezy then?
<mjg59> lamont__: Not entirely
<lamont__> ok
<ogra> mjg59, we'll have a new upstream version of gnome-power next week, richard huges just mailed me very sweet screenshots
<mjg59> Cool
<ogra> the hibernate and sleep commands are now set in gconf keys, so we just have to modify these for pmi and thats it :)
<mjg59> Cool
<sivang> ogra: cool, 'sup?
<mjg59> ogra: Any idea why I might only be getting ACPI devices in hal-device-manager?
<ogra> mjg59, nope... i have no apm machine around....
<mjg59> Mm? This is with ACPI
<mjg59> If I run hal-device-manager, I /only/ get the ACPI devices
<mjg59> No PCI ones
<ogra> oh
<ogra> mine looks ok
<mjg59> I'm upgrading to current Breezy now, I'll see if it's still doing it
<jdub> why would wget get a 403 attempting to get a page on the ubuntu wiki?
<jdub> ie:
<jdub> wget -O- "https://wiki.ubuntu.com/UbuntuWorldWide?action=raw"
<jdub> it's not like you have to be logged in
<mdke> dunno
<mdke> permissions?
<mdke> they will probably be able to tell ya in #moin
<mdke> they are good
<jdub> we're molesting it in unpredictableish ways
<schweeb> jdub: not loading for me either
<mdke> jdub, molesting?
<jdub> schweeb: with wget? but works for browser?
<schweeb> on, not in browser... either that or it's extremely slow
<schweeb> s/on/no/
<jdub> oh
<mdke> i get it in browser
<schweeb> man, I love this new laptop
<schweeb> gotta upgrade to breezy now
<jdub> your laptop must be slow ;)
<schweeb> h4n
<schweeb> it's an IBM X41 ;)
<mdke> jdub, honest, try #moin
<jdub> i'll talk to them when i'm happy it's not us
<mdke> jdub, even if its us, they might be able to tell you
<mdke> but fair enough
<schweeb> ah, works fine for me now
<schweeb> for some reason the SSL cert stuff didn't get focus
<schweeb> I get 403 with wget as well...
<schweeb> bleh
<schweeb> you have access to the apache logs, jdub?
<schweeb> (I realize they'll be HUGE)
<jdub> nup
<schweeb> http://pastebin.arslinux.com/2011
<schweeb> that's what I get with --debug
<schweeb> nothing real useful
<schweeb> could it be a user agent thing? or a cookie thing?
<sivang> hmm, seb128 already went to sleep?
<jdub> schweeb: either would make me cross ;)
* jdub wishes we didn't have to use https for *everything*
<mdke> same happens on the moin base wiki
<schweeb> jdub: indeed
<mdke> wget -O- "http://moinmoin.wikiwikiweb.de/RecentChanges?action=raw"
<schweeb> I'm guessing a user agent thing
<schweeb> lemme get a user agent string to test
<jdub> pity i can't do ssl with nc (which is what i was using before https)
<jdub> maybe moin kills wget
<mdke> wget -O- "http://moinmoin.wikiwikiweb.de/HelpContents?action=raw"
<mdke> ditto
<jdub> jesus
<jdub> wget -O- -U "me" "https://wiki.ubuntu.com/UbuntuWorldWide?action=raw"
<jdub> ^ fine
<schweeb> yep, user agent
<schweeb> worked with IE6's user agent for me
<schweeb> that's wonderful.
<mdke> :)
<jdub> so much bong
<Keybuk> I thought you liked the bong?
<lsuactiafner> omg this is funny  CTCP PING reply from lsuactiafner: 793.311 seconds
* mjg59 watches networkmanager explode his kernel due to the ipw2100 bug
<tseng> mjg59: it stomps on ipw2200 also
<mjg59> It's your fucking birthday
<mjg59> tseng: Should only happen in 2.6.12
<tseng> but, i think that one explodes by itself
<tseng> yeah probably a less annoying bug here
<tseng> it occassionally just gives up the ghost or jumps in and out
<mjg59> Oh man now X is broken
<mjg59> So, what's the story with making X work today?
<jdub> mjg59: what kind of b0rk do you have?
<jdub> current X seems fine
<mjg59> No fonts
<mjg59> Ah, missing symlink from /usr/share/X11/fonts/misc to /usr/lib/X11/fonts/misc
#ubuntu-devel 2005-06-26
<mjg59> (I have a hand-hacked xorg.conf, so dexconf wouldn't have rewritten it automatically)
<mjg59> Though my cursor seems to have gone back to the old-style one
<mjg59> Uh. It just started x-session-manager
<schweeb> mjg59: you're the lead on laptop stuff, right?
<jdub> do a dpkg-reconfigure
<mjg59> schweeb: Yeah
<mjg59> jdub: On what?
<jdub> or switch to the right fonts dirs
<jdub> xserver-xorg
<mjg59> jdub: I just added the symlink
<mjg59> It breaks upgrades at the moment
<schweeb> mjg59: heard of anyone with an IBM X41 yet?  just got one like 2 days ago, about to start testing breezy on it
<infinity> schweeb : Is that the convertible tablet
<infinity> ?
<schweeb> no, just the laptop
<mjg59> schweeb: Not yet, but as far as I know it's just an X40 with i915
<schweeb> k
<mjg59> infinity: There's a tablet version, but not all of them are tablets
<mjg59> ogra: About?
<schweeb> tablet was finally released like the day after I ordered this one
<schweeb> my sound doesn't work yet, but I'm assuming that's the same IRQ problem I had with my Dell
<ogra> mjg59, yep
<mjg59> Uh. On Breezy?
<mjg59> There should be no IRQ issues
<schweeb> no, hoary at the moment
<mjg59> Is snd_intel8x0 getting loaded?
<schweeb> yep
<mjg59> ogra: We need to tidy up the power preferences
<mjg59> schweeb: 2.6.10?
<schweeb> yep, latest ubuntu kernel pkg
<ogra> mjg59, lets wait til next week,  havent seen the new preferences window yet
<mjg59> ogra: Ok, no problem
<mjg59> ogra: Oh, can you get it added to the default session?
<mjg59> (Check if it's installed, and if so run it)
<schweeb> mjg59: on the Dell, the parport and intel8x0 were trying to unsuccessfully use the same IRQ... I always had to blacklist the parport
<mjg59> schweeb: That shouldn't have happened post warty
<ogra> i think it should work like update-manager, say the user has to run it once...
<mjg59> Hmph
<schweeb> hrm
<mjg59> ogra: Hmm. I'm inclined to think it should always be running (much like the networkmanager back end)
<mjg59> Otherwise people won't get low battery notifications by default
<schweeb> /proc/interrupts doesn't show that the parport or the snd driver even have an interrupt...
* schweeb investigates further
<mjg59> schweeb: Check dmesg for signs that the sound driver actually bound to the device at all
<mjg59> schweeb: The other possibility is that we're missing PCI IDs
<schweeb> yea, this does have some odd hardware for a laptop
<schweeb> SATA, PCI Express
<ogra> mjg59, i'll try to get the backend started by default...
<schweeb> haven't tried bluetooth yet either
<mjg59> ogra: Cool
<mjg59> schweeb: Oh, it's SATA? Right, you're not going to get suspend/resume
<schweeb> but my wifi works great, that's all that matters at this exact moment :p
<ogra> mjg59, but network manager's backend is a system service
<schweeb> mjg59: oh, boo
<mjg59> ogra: Yeah, but that doesn't matter to the user :)
<ogra> mjg59, nope, but for the implementation ;)
<mjg59> thom: networkmanager hasn't crashed on me yet!
<schweeb> mjg59: that makes me weep, wish I would have known that one (hell, I didn't know it was SATA until I installed ubuntu)
<jdub> sata lappy? nice! (mostly)
<schweeb> so, that's a SATA wide issue?
<HWolf> jdub, sata isn't useful, really. :P
<HWolf> Only thing its good for is reducing cable clutter. 
<jdub> i don't care about useful
<jdub> i care about SPEED
<schweeb> HWolf: especially considering this has a 1.8" 4200 RPM drive :(
* jdub revs his very old athlon.
<schweeb> but it's so damn light
<jdub> and his server with no lid on it.
<schweeb> lol
<jdub> both of which his laptop outperforms. :|
<HWolf> ide wouldn't limit even a decent desktop drive, let alone a laptop drive
<schweeb> mjg59: I could get you lspci output if you'd like, just so you guys can get PCI IDs
<HWolf> it'll show no increase in speed whatsoever, even in a synthetic benchmark.
<schweeb> I already submitted to hwdb
* infinity wonders if his new T43 will be SATA....
<infinity> The specs claimes ATA133, but the specs often lie.
<infinity> Guess we'll see when it gets here.
<HWolf> But now I'm off, before I get kicked out for being OT, or I drop my sleepy head on my keyboard. :)
<mjg59> schweeb: Yeah, that'd be good
<schweeb> any specific options? -v, or anything further than that?
<mjg59> schweeb: SATA support for suspend/resume ought to appear in Breezy soon
<mjg59> lspci -n
<schweeb> email or pm?
<jdub> anyone here have sip love?
<jdub> i'm bored of calling echo tests and random red hat pstn numbers
<schweeb> jdub: whiprush would probably be more than happy to be a test subject
<ogra> jdub, call anthony
<jdub> ogra: it's 8am on sunday morning
<jdub> ogra: i don't believe he's seen one of those since he got up to watch church on tv in his younger days
<ogra> hehe, great, the right time.... he will love you :)
<schweeb> jdub: go to sleep then!
<jdub> i just got up!
<schweeb> why
<jdub> i'm now on EXTREME .au time
<jdub> which means early to bed, early to rise
<schweeb> you have like 6 more hours of sleep ahead ofy ou
<schweeb> mjg59: what's your email, or should I email them to ubuntu-devel list
<mjg59> schweeb: mjg59@srcf.ucam.org
<schweeb> sent
<thom> mjg59: heh, cool
<Burgundavia> thom, have you heard any reports of network manager writing "nameserver 127.0.0.1" to a /etc/resolv.conf ?
<thom> Burgundavia: uh, that's what it's supposed to do?
<thom> so, yes, i've heard that it does that :P
<Burgundavia> thom, it also broke networking on my machine, when rebooted into recovery mode
<thom> how?
<Burgundavia> the machine cannot contact the outsite world
<Burgundavia> through DNS that it
<Burgundavia> s/it/is
<jdub> thom: no name resolution...
<jdub> no bind
<thom> ok, so that's _not_ breaking networking
<thom> please don't confuse the two
<Burgundavia> seems that something else is looking for /etc/resolv.conf to be a simlink
<thom> jdub: nod, working on it
<Burgundavia> symlink even
<thom> Burgundavia: resolvconf, yes
<ogra> thom, for me dhcp doesnt work
<jdub> thom: so will /e/n/interfaces basically become irrelevant?
<thom> jdub: well, no
<thom> jdub: NM reads it and uses it in the case of static config
<jdub> ahr
<thom> long term we'll do more integration
<thom> ogra: doesn't work is a big and unhelpful phrase. does it work normally? is this on your wifi card? does the rest of the networking stuff get set up correctly?
<ogra> its a orinoco silver pcmcia card, if i ifdown/up the interface, it works normally...
<jdub> thom: have you looked at the zeroconf package?
<thom> what i need to do is figure out how to make resolvconf and NM play in such a way as to not break in the case where NM isn't running
<thom> jdub: NM does zeroconf
<thom> or it should
<jdub> oh, ok
<thom> ogra: is this the one that hal doesn't know is a wifi card?
<ogra> yeps
<thom> you're doomed then; kernel bug
<ogra> argh
<mjg59> Well, lack of kernel functionality
<thom> (it needs to export the correct info in sysfs)
<thom> mjg59: well, old driver, yeah
<mjg59> thom: The main problem is that pcmcia cards don't seem to play nicely with the sysfs stuff
<mjg59> cardbus is fine
<jdub> thom: what do you get out of using resolvconf?
<thom> oh, just old school pcmcia
<thom> jdub: i'm hoping that i can get it to the point of being able to get NM to use resolvconf to generate a resolv.conf, so if NM isn't running you still get a reasonable resolv.conf
<Goshawk> hi
<jdub> thom: the server case, basically?
<Burgundavia> and the recovery mode
<Burgundavia> that is where nm bit me
<jdub> Burgundavia: that's avoidable in other ways (ie. don't even try)
<thom> jdub: server case isn't really interesting, you won't ever have NM installed 
<jdub> thom: have you drawn little workflow diagrams of this?
<thom> jdub: but being able to play nice with the system is definitely a feature
<thom> jdub: no
<thom> not yet, anyway
<jdub> my brain is scrawling little workflows on the inside of my skull
<Goshawk> this may be a gnome bug: afther you have created a parent folder and many child folders, with files inside, and folders without any file, and click the right mouse button on the parent folder and choose "Create Archive" in format tar.gz, the archive is created but all the empty folders are missed... should it be a bug? should i report it to reportbug?
<jdub> Goshawk: bugzilla.gnome.org is probably a better place (and yeah, sounds like a good bug to me)
<Goshawk> jdub, thanks :D
<thom> my ears are ringing too loud from U2 for my brain to work right now ;-)
<jdub> thom: so in the n-m exists case, what happens when you invoke ifup or ifdown?
<thom> jdub: at the moment, shitfight central
<jdub> awesome
<jdub> do you want to make it so they send appropriate d-bus messages to n-m, and ignore everything else?
<jdub> hmm
<thom> jdub: i'm unsure as yet. Thomas Hood is interested in working on this too, need to talk to him at somepoint again
<tseng> thom: man i love the moment after n-m realizes it doesnt have total control over a network device
<jdub> jtdhood?
<thom> jdub: yeah
<jdub> cool
<thom> tseng: heh
<jdub> man, this is hard stuff
<thom> tseng: i thought "shitfight" covered it quite accurately :-)
<tseng> yes
<tseng> i wonder if i put nm-applet in my session if ill get properly associated at login
<tseng> (brb)
<eazel7> hi ppl
<jdub> thom: what if n-m became a type of /e/n/i configurations?
<jdub> so you had managed interfaces and unmanaged interfaces
<thom> jdub: hrrrrm
* thom writes tomboy notes
<jdub> then ifup on a managed interface would tell n-m to do its thing (via dbus, i imagine)
<jdub> ifup on an unmanaged interface would just do the right thing
<jdub> as per configuration
<jdub> and n-m would *never* try to manipulate an unmanaged interface
<jdub> like, it would completely ignore them
<jdub> hrm
<jdub> though you'd want n-m to own anything that wasn't specified
<thom> yeah
<tseng> jdub: would if* work properly in the absense of nm?
<thom> i wonder if you could use a hotplug mapping script to do that
<jdub> tseng: you mean, would a managed interface work in the absence of nm?
<tseng> jdub: sure
<jdub> hmm
<thom> there's no reason for it not to, is there?
<jdub> thom: what would it do?
<jdub> it's like
<tseng> if you told people they need dbus and nm on a server, then you would find out what shitfit central is
<jdub> ifup eth3 when you don't have an eth3 definition in interfaces
<thom> tseng: yes
<jdub> tseng: well, in that case, you just have all unmanaged interfaces as per normal
<tseng> hm right
<jdub> what i'm thinking of is this (which thom groks, i think):
<tseng> i see how you mean
<jdub> iface eth1 inet managed
<jdub> ^ in /etc/network/interfaces
<tseng> oh
<thom> jdub: not really; the interface is defined, all you're really doing is notifying NM that you want it to be available; there's no reason that you couldn't also have fallback config i think
<jdub> heh, you could even set mandatory (unchangeable) settings in the stanza :)
<thom> that too
<jdub> thom: so if i did ifup eth1 when nm wasn't running, what do you see happening? (when the only configuration is that one line)
<thom> jdub: more like: "iface eth1 inet dhcp \n mode managed"; don't forget that NM can use static configs because it can do the ifplugd case of bringing an iface up when the it gets a connection
<jdub> but then you've got a mandatory setting of dhcp, right? :)
<jdub> hrm
<thom> yes, and that's fine
<jdub> what if you have a managed interface without a dhcp or static mandatory setting?
<thom> in the scheme i just proposed, you can't
<jdub> however, in the scheme i proposed, you couldn't have a mandatory setting for that at all
<jdub> unless you had another stanza item
<thom> i can't see how you'd usefully use that, unless it just zeroconfs the iface
<thom> NM still has to know how it should bring the iface up
<jdub> it works that out itself, doesn't it?
<thom> no? it defaults to dhcp but parses /e/n/i for any clues 
<jdub> that static/dhcp bit is 'how to do it' and nm is a 'how to do it'
<thom> no; think of /e/n/i as a policy statement, NM just implements that policy
<jdub> so static configurations are not stored by NM?
* thom thinks he's characterising this right
<thom> not afaik
<thom> could be wrong though
<jdub> aha, so
<jdub> then you could use the same thing
<jdub> iface eth1 inet managed
<jdub> and all of the fields are optional
<jdub> *if* you set address, it doesn't dhcp
<jdub> if you set any of the others, they're overrides or something
<jdub> does NM interpret maps in interfaces?
<thom> hrm, see what you mean
<mjg59> jdub: Unless you manually override in the interface at some point
<jdub> mjg59: hrm?
<mjg59> jdub: I ought to be able to override anything in /e/n/i through the UI at runtime
<jdub> mjg59: yeah, though we were just talking about mandatory settings too
<jdub> mjg59: perhaps there should just be another field 'mandatory yes' or something to do that
<mjg59> Yes, it needs some amount of lock-down support
<jdub> but you're right, that should be optional
* jdub nudges fascist hat further away
<jdub> does NM start really early?
<tseng> it starts with dbus
<jdub> oh yeah
<thom> 20 in rc2
<thom> not, actually, early enough
<jdub> mmm
<thom> i think we should get dbus up ASAP
<thom> like, in the initrd or so... ;-)
<jdub> pondering if ifup eth1 would invoke NM if it wasn't running, or just talk to it (and NM would kick all the managed interfaces off when it starts)
<jdub> haha
<jdub> thom: in en_GB, 'tomboy' should be 'thomboy' ;-)
<thom> piss off :-)
* jdub writes a letter to orph.
<thom> jdub: it's not like it's a usual spelling here, either
<tseng> jdub: beat him senseless until he replaces the shithouse icons
<tseng> jdub: i mentioned i replaced it and he started cursing
<jbailey> thom: Eh?
<thom> jbailey: initrd is a highlight these days too?
<jbailey> thom: If you're serious, please look at the initramfs hooks.  There won't be glibc in there, so I'll need to be able to compile it with klibc or uclibc.
<jbailey> thom: Yeah. =) 
<thom> jbailey: no, i'm not serious. but it does need to be early
<thom> (i'm not sure it'd build with klibc, anyway)
<jbailey> thom: Oh good. =)  I was growing this deep fear that perhaps usplash might need it for something.
<thom> heh
<thom> usplash is not me, but it might well
<jdub> tseng: seriously? i thought they changed upstream too?
<tseng> jdub: no way
<thom> we could have udbus ;-)
<sladen> the stuff I did to date is just statically built and striped.  comes to < 30kB
<tseng> jdub: its still the dumbass comic guy from 1940
<mjg59> sladen: So, when are we getting more of it?
<jdub> don't call tin tin a dumbass
<jbailey> sladen: Sounds lovely.  Did you get a chance to look at the intiramfs hooks?
<jdub> you'll offend seb
<tseng> ha ha
<thom> jdub: we should send orph a profile shot of seb
<tseng> YES
<jbailey> sladen: 0.11 is quite well baked for raid1, hd boot and nfsroot.
<thom> it'd be *so* cool
<sladen> mjg59: ah, yes.  urm.
<jdub> thom: a seb hackergotchi, which i don't have...
<tseng> that should be april fools next year
<tseng> tomboy -> seb
<thom> the ubuntu hackergotchi icon set?
<jbailey> sladen: You should be able to install initramfs-tools, add one line to your kernel-img.conf: "ramdisk = /usr/sbin/mkinitramfs" and reinstall your kernel and have it Just Work(tm)
<thom> that'd be terrifying!
<tseng> thom: yes!
<sladen> replace tseng with a Tub of Lard
<jbailey> Phear the April 1 Ubuntugotchi set.
<tseng> (are you calling me fat?)
<jdub> jbailey: now?
<jdub> The following extra packages will be installed:
<jdub>   busybox-cvs-initramfs klibc-utils libklibc
<jdub> ouch ;)
<jbailey> jdub: No, April 1 was a little while ago.
<sladen> tseng: it's the clasic thing that Have I Got News FFor You do when one of their guests does a no-show
<jdub> jbailey: initramfs, silly :)
<jbailey> Oh, I see. =)
<jdub> Need to get 518kB of archives.
<jdub> After unpacking 1372kB of additional disk space will be used.
<tseng> sladen: ah.
<jdub> boh ;)
<jbailey> Yes.  mdz is using it already and I'm booting one of my systems on it all the time.
<jbailey> jdub: Doesn't do lvm or evms.
* jdub does it
<jbailey> Tested on i386 and ppc64
<jdub> nice
<jbailey> Don't mind the 9mb initrd, that will get smaller. =)
<jbailey> Right now you have a pile of static binaries, glibc, klibc and about 30 megs of drivers packed into there. =)
<jdub> ouch
<jdub> is there a nice initramfs boot process doc around?
* sladen grabs initramfs
<jbailey> I think that needs to be about 6 megs worth of drivers, and about half a meg worth of code.
<jbailey> jdub: You're talking kernel side or my package?
<jdub> both
<sladen> 30MB initrd?!
<jbailey> sladen: Nonono, 9mb, but that's compressed.
<jbailey> Much need for shrinkage.
<jbailey> My smallest test case was 250k
<tseng> sladen: dude you need the whole kernel source tree in there for good luck
<jbailey> And that could still be reduced further.
<jbailey> jdub: No, for my package, but I can give you the door through it in about 2 minutes.
<jbailey> I've been waiting for usplash to write docs, since I think that's the next thing that will probably cause the design to stretch a little.
<sladen> jbailey: you should add support for sticking GCC + binutils in there so that you can compile the driver on the fly.  the Gentoo converts would *love* that
<jbailey> jdub: http://lwn.net/Articles/14776/ is a reasonable place to start.
<jbailey> sladen: If you have the backing store, honestly nothing stops it.
<jbailey> sladen: And the assembly model that we're working towards would make it pretty trivial to do, sadly.
<jbailey> sladen: It's worth noting that the initramfs includes *all* of the hardware autodetection.  You can take this initramfs and copy it to another machine and expect it to Just Work.
<jdub> yeah, reading it already ;)
<jdub> first google hit
<jdub> i've read it before but i never remember why it rocks
<jbailey> jdub: Less crap in kernel, basically.
<jbailey> jdub: There's a bunch of things that otherwise have to stay resident, like dhcp code or raid detection code that can be jettisoned.
<jdub> jbailey: so in future, you imagine that the basic initramfs image will be built into the kernel, so not requiring much at all to be built on kernel install?
<jbailey> Having that in userspace also means that if there's a bug, it's not risking taking out the whole box.
<jdub> ie. i won't have to install klibc or busy box on my machine? :)
<jbailey> Hopefully, yes.
<jdub> nice!
<jbailey> klibc is intended to go into the kernel source tree.
<jdub> so modules will be stacked on top and so on
<jbailey> I wound up adding busybox when doing the raid1 stuff.
<jbailey> Right, your bootloader will be able to take various cpio images and mash them together.
<jbailey> So whatever pieces you need can be made available.
<jbailey> If you're not network booting, there's no reason to include the network drivers.
<jbailey> So I can imagine: scsi-2.6.12-1-powerpc64 ide-2.6.12-1-powerpc64 net-2.6.12-1-powerpc64 etc..
<jbailey> Your bootloader would just put the interesting ones together.
<jbailey> Plus a "base" initramfs of some sort that's all nice and pre-assembled.
<jdub> and we can do dsdt stuff more sanely :)
<jbailey> Hopefully.  I haven't finished the DSDT bits yet.
<jbailey> I know with the initrd it's just mashed onto the end with a magic number.  I'm guessing it's the same in this case.
<jbailey> So again, adding it becomes a matter of bootloader configuration, or having the helper program assemble them together at kernel install time.
<jdub> reboot time ;)
<jbailey> Rather than building based on what it thinks you might need.
<jbailey> Enjoy, and good luck. =)
<jdub> will be rad for thin client foo
<jdub> haha
<jdub> oooookay
<jbailey> Is that a good laugh or a bad one?
<jdub> fatal error inserting ipw2200, unknown symbol in module
<sladen> jbailey: so what exactly does 'cpio --dereference' do if it doesn't do what it says on the tin?
<jbailey> Oh that's ad.
<jdub> no such file /conf/modules
<jbailey> sad.
<jdub> no such file /proc/mdstat
<jdub> hda1 doesn't exist
<jdub> dropping to shell
<jbailey> Oh shit.  IDE case.
<jdub> sh can't access tty; job control turned off
<jbailey> You probably want to modprobe ide-generic.  I haven't tested on a pure IDE system yet.
<jbailey> Forgot about ide-generic madness.
<jdub> oh, what've you been using?
<jbailey> SATA
<sladen> jbailey: and could that hardcoded stuff be done in a more generic way with 'find'?
<jdub> ok, ide-generic loaded
<jbailey> sladen: Which hardcoded stuff?
<jbailey> jdub: rerun udevstart to create the device files.
<jbailey> sladen: I donj't have find available in the initramfs right now.  I'm trying to reduce the bits that I need so I can get rid of busybox.
<jdub> jbailey: i ran udevstart, still no hda*
<sladen> jbailey: all the 'lkn -s's in mkinitramfs
<jbailey> jdub: modprobe ide-disk ?
<jbailey> jdub: I'll cook up the ide bus walking stuff and put it in.  I keep forgetting that ide is a bit weird.
<jdub> jbailey: ended up doing ide-core + ide-disk and it was fine
<jbailey> sladen: No, those are likely to be more specific.
<jbailey> sladen: I want to include an absolute minimum of stuff in there.  Right now I'm already pulling in crap like gzip.
<jbailey> The reason I'm doing ln -s's is to avoid copying it, then making another copy with cpio.  ln -s is nice and quick.
<jdub> jbailey: next step? :)
<jbailey> modprobe ext3
<jbailey> Or for amusement, you can type fstype < /dev/hdaN
<jbailey> (replace N)
<jbailey> And then modprobe whatever FSTYPE comes out as.
<jdub> nice :)
<jbailey> mount -r -t ${FSTYPE} ${ROOT} /root
<jbailey> umount /sys
<jbailey> umount /proc
<jbailey> exec run-init /root /sbin/init
<jbailey> ---
<jbailey> And that should chain to your working system.
<jbailey> jdub: If you feel brave enough to try again, add ide-disk and ide-generic to /etc/initramfs/modules
<jbailey> Rebuild and try again.
<jdub> blammo!
<jdub> good blammo
<jdub> :)
<jdub> ok
<jbailey> I think ide-core should get pulled in them as a sideeffect.
<jdub> oh MAAAN
<jdub> my keyboard isn't working again
* jbailey quiets the warning about /conf/modules
* jbailey blinks
<D1> anyone run a laptop that has a smart battery and was able to get it to work in ubuntu?
<jdub> jbailey: unrelated
<jbailey> Oh good. =)
<jbailey> If you have a USB keyboard, this initramfs detects that too.
<jdub> nice
<jbailey> So if you have to fallback to the shell, it's useful.
<jdub> soon, you should make it detect when X IS BROKEN
<jbailey> And do what...  emerge you a new X? =)
<jdub> haha
<sladen> D1: not yet, lack of driver support/specs.  pester mjg59 for more details
* jdub wonders what changes to make the keyboard work
<sladen> shnake in initramfs.  r.
<jbailey> sladen: EPARSE
<jdub> jbailey: boots fine after a rebuild :)
<jdub> but my X still isn't working
<jbailey> jdub: Sweet.  The next upload will handle the IDE case correctly.
<jdub> noice :)
<jdub> what's the timeline for making this the default?
<jbailey> No later than 2.6.13 =)
<jdub> ha ha
<jbailey> That release will drop devfs support which the current initrd needs. =)
<jdub> are we doing .13 for breezy?!
<jdub> EEEK!
<jdub> die devfs! die!
<jbailey> Dunno if we're doing .13 for breezy or not.  
<jbailey> .12 is finally out.  I don't know what's coming up next beyond the devfs bits.
<jdub> how hard will it be to remove the devfs assumption/dependency?
* jdub considers saucy things to do with initramfs
<jbailey> Depends on the approach taken.  We could put static device nodes in there, which seems wrong.
<jbailey> We could put udev in, which is the work that I've aready done.
<thom> ogra: http://www.livejournal.com/users/kernelslacker/19564.html
<jbailey> Mostly I think the mkinitrd code is so bloody ugly, and we have far more elegant ways of doing things now.
<jbailey> Literally the hardware detection code is:
<jbailey>         for x in /sys/bus/pci/devices/*; do;                if [ -e ${x}/modalias ] ; then;                        modprobe -q $(cat ${x}/modalias);                fi;        done
<jbailey> Repeat for usb.
<jbailey> Add a few lines after this to cope with ide
<jbailey> I could hardcode all of the lvm and evms stuff the way the current initrd does, but I'm hoping that we can just be more flexible than that.
<jdub> jbailey: tasty!
<jbailey> Anyone know anything about kmod?
<jbailey> =)
<LinuxJones> can someone pop into #ubuntu and kick the spammers please
<LinuxJones> please !!!
<jdub> whiprush: ping
<whiprush> jdub: pong
<tseng> jdub: dude do you still have that random laptop crasher on battery
<tseng> jdub: im thinking laptop-mode, i turned it off for now
<jdub> oh
<jdub> um
<jdub> i haven't seen that for a bit
<jdub> but that's mostly because i haven't been using my laptop very much (directly)
<tseng> you only get it on battery power?
<tseng> or cant say
<jdub> no only on battery
<tseng> exactly, laptop-mode is all i can think of
<tseng> since i ran badblocks
<tseng> and got nothing
<whiprush> jdub: you rang?
<jdub> whiprush: yo
<jdub> whiprush: what's your sip url?
<whiprush> don't have it set up yet, I could never connect to anything.
<jdub> oh
<whiprush> jammcq uses sip though
<fabbione> morning
<bob2> *cough*fridge*cough*
<mpt> The fridge has a cold? :-)
<mdz> wow, network-manager produced a 3 gigabyte syslog file. impressive.
<fabbione> mdz: ROTFL
<mdz> Jun 18 03:10:17 localhost NetworkManager: <information>^IActivation (eth0) failure scheduled...
<mdz> Jun 18 03:10:17 localhost NetworkManager: <information>^IActivation (eth0) Stage 3 (IP Configure Start) complete.
<mdz> Jun 18 03:10:17 localhost NetworkManager: <information>^IActivation (eth0) failed.
<mdz> that sort of thing, repeated a few hundred times per second
<fabbione> neat :)
<ompaul> possible bug in thunderbird, try to look at the full message headers and you can't (a) see them all  because (B) you can't scroll up and down in the window :)
* fabbione does an attempt to bootstrap ghc6
<robitaille> ompaul,  I have the same problem here.  And can't find it in the bugzilla.   You should fill a new bug report about this.
<ompaul> robitaille, now having someone else confirm this I will
<fabbione> ompaul: yes.. i have the same problem here
<ompaul> it will be in bugzilla soon
* ompaul pops off from bugzilla to launchpad 
<ompaul> its done 
<robitaille> ompaul,  url?
<ompaul> robitaille,  https://launchpad.ubuntu.com/malone/distros/ubuntu my name is Paul O'Malley last two  :-)
<cartman> X.org no longer compiled with -fPIC on amd64?
<cartman> I got lots of linking errors due to that now
<hughsie> Anyone know if the gnome-power debs have been built?
<pitti> Good morning
<hughsie> Morning. 
<hughsie> I got an email yesterday from someone in ubuntu telling me that debs were being built
<daniels> jdub: pong
<daniels> mdz: ... which changes?
<daniels> Keybuk: sounds like your entire symlink farm is somehow complteely maggotted
<daniels> Kamion: pong
<daniels> mdz: will check out the xserver-xorg thing a little later
<Keybuk> daniels: they're your packages
<Keybuk> c'est ne pas un dpkg bug
<daniels> Keybuk: iz gtk bug
<daniels> Keybuk: the upgrade path is still a little rocky, because I haven't got to fully testing a hoary -> breezy upgrade yet
<cartman> daniels: X.org on amd64 seems no longer compiled with -fPIC ?
<cartman> I got relocation errors while linking to some X libs
<daniels> cartman: ... which libs?
<cartman> one sec
<cartman> usr/X11R6/lib/libXext.a
<cartman> for example
<cartman> gcc tells me to recompile with -fPIC rolling back to -24 works fine
<torkel> hughsie: gnome-power                 0.0.3+20050605cvs-0ubuntu1
<hughsie> torkel: how often will the new cvs stuff come through?
<daniels> cartman: oh, right -- that's a change from modular to monolithic
<daniels> cartman: iirc you only need -fPIC when linking static to shared, though
<daniels> and libXext has been available in shared form also for around a bajillion years
<cartman> daniels: and KDE does that, don't ask me why or how
<cartman> maybe I need to reconfigure hmmm
<cartman> daniels: ok so I will retry cleanly & re-report
<sabdfl> hey guys, is there any way to examine files that are hidden by a new mount?
<cartman> daniels: also xkb seems to be broken again xorg rules file is missing
<sabdfl> say i had files on a filesystem under /tmp/bar/
<sabdfl> and i then mount another filesystem at /tmp/bar/
<Keybuk> sabdfl: only if you know the inode number
<Keybuk> otherwise unmount the other mount
<sabdfl> Keybuk: how do i find the inode number?
<sabdfl> unmounting could be tricky, it's /var we're talking  about :-)
<Keybuk> unmount the other mount, and use stat or ls
<Keybuk> heh
<Keybuk> and I guess rebooting into single-user is out of the question?
<sabdfl> not remotely, no :-)
<sabdfl> i tried that and it screwed me nicely
<Keybuk> if there anything particular you are looking for?
<sabdfl> sudo init 1.... oops
<sabdfl> ha! got it, lsof |grep var
<sabdfl> killed everything that was reading/writing there
<Keybuk> that'll give you the open files
<sabdfl> maybe i can unmount now
<sabdfl> nup
<sabdfl> what else would keep the device busy?
<daniels> cartman: xkb is, um, interesting at the moment
<sabdfl>  /bin/dd bs 1 if /proc/kmsg of /var/run/klogd/kmsg
<Keybuk> sabdfl: kernel log daemon
<sabdfl> and what could that be?
<cartman> daniels: looks like symlink is missing but I rolled back to -24 for now :/
<Keybuk> well, you have direct access to the disk underneath (/dev/hdaX)
<Keybuk> so you could grep that for what you were looking for
<sabdfl> Keybuk: i need to delete a bunch of those files
<Keybuk> any particular reason?  they're not doing much
<Keybuk> or are they using space?
<Keybuk> sabdfl: you should be able to stop that with /etc/init.d/klogd stop
<fabbione> hmmm also sysklogd
<sabdfl> errr... jdub, could you cd / please?
<doko> $ apt-get source python-defaults
<doko> Reading package lists... Done
<doko> Building dependency tree... Done
<doko> Need to get 207kB of source archives.
<doko> Get:1 http://archive.ubuntu.com breezy/main python-defaults 2.4.1-0ubuntu2 (dsc) [695B] 
<doko> Get:2 http://archive.ubuntu.com breezy/main python-defaults 2.4.1-0ubuntu2 (tar) [206kB] 
<doko> Fetched 207kB in 0s (238kB/s)
<doko> dpkg-source: error: unrecognised file suffix `.tar'
<doko> Unpack command 'dpkg-source -x python-defaults_2.4.1-0ubuntu2.dsc' failed.
<doko> E: Child process failed
<doko> Keybuk: ^^^
<thom> native packages with debian versions don't work anymore, apparently
<thom> and keybuk's quit
<daniels> mdz: the Generic Mouse thing being reverted from -21 sounds plausible
<daniels> mdz: didn't help that I was offline for about 50 hours
<doko> thom: he escaped at the right moment ;)
<cartman> re
<fabbione> thom: i am trying to bootstrap ghc6... it's a royal pain
<thom> fabbione: yeah, it looked like being no fun at all, which is why i'm running darcs in a hoary chroot 
<fabbione>  /usr/src/wartydevel/misc/ghc6-6.4/ghc/includes/HsFFI.h:112:2: error: #error GHC untested on this architecture: sizeof(void *) != 4 or 8
<fabbione> this is on i386 :)
<bob2> haha
<daniels> haha
<daniels> go ghc!
<fabbione> i think the only way to bootstrap it properly is a dual build dance
<fabbione> the c++ transition isn't helping
<fabbione> first port libgmp3 to debian
<fabbione> rebuild debian ghc6 with the new libgmp3
<fabbione> so that it can be installed in breezy
<fabbione> and from there build ghc6 in breezy
<fabbione> direct bootstrap seems pretty broken
<thom> fabbione: new libgmp3? it's libgmp3c2 now, you realise?
<fabbione> thom: that's what i meant
<fabbione> ghc6 depends on libgmp3
<fabbione> so it cannot be installed in breezy
<fabbione> ghc6 b-d on ghc6
<fabbione> somewhere you need start breaking the loop
<thom> ok, you expressed it badly. i know the chain
<fabbione> yes.. it's sunday dude :P
<jdub> sabdfl: pong?
<sabdfl> hiya
<jdub> haha
<jdub> now i grok :)
<sabdfl> i'm bring up a new var partition, needed to SIGHUP you to unmount the new one while i cleaned up underneath it
<jdub> yeah
<jdub> rock
<sabdfl> just waiting for the IO to finish
<jdub> elmo and i will transfer it this week too
<HiddenWolf> Guys, stupid question, but does the ubuntu project currently have someone whose job it is to check where ubuntu is going and provide commentary on the user-friendly-ness of the solution rather than the technical side of things?
<sabdfl> HiddenWolf: we try to do that all the time, but we probably do need a formal structure to provide direction on that front
<HiddenWolf> saddfl, please try to do so. I keep running into those little things that are the downside of OS-dom. Interfaces and structures directed at the poweruser, technical solutions to problems in experience or communication, etc.
<HiddenWolf> *grumble* typo's
<HiddenWolf> Now this is much better in ubuntu than it is in for instance gnome, i'll give you that, but it's hard to think outside of your own patterns and experiences, so the poblem is still there.
<daniels> sometimes you don't always realise how broken stuff is
<daniels> so as much specific feedback as we can get will always help
<HiddenWolf> I realise that for instance you with x are swamped with cases where you just need to make it work. Downside of that is that you might not have time to fix some annoying issue that bugs the hell out of everyone, think lack of support for scrolling with the mouse-wheel.
<HiddenWolf> You and I will have set it up so that that'll work fine for us, and forget about it.
<daniels> uhm, mouse wheel scrolling should work already :)
<HiddenWolf> It didn't for me, last time I installed. :P
<daniels> hm, bong.
<daniels> it's always worked out of the box for me
<daniels> unfortunately because it's so hardware-specific, there's a lot of options you can't enable because it doesn't work on some hardware
<HiddenWolf> Now there. That's an issue that's very hard to solve technically, so the best way to do it, imho, is check if it works, and if it doesn't, inform the user, and piont to how he can make it work.
<daniels> yeah, I do that as much as possible
<daniels> but the failure modes are frequently: a) machine locks up hard, b) indications all perfectly good as far as we can tell, but complete failure to display anything on the screen
<HiddenWolf> I don't blame you for fixing A first, mind you.
<daniels> but sometimes it's just flat-out impossible to tell
<daniels> (doesn't help when it's BIOS-dependent, so you can't even have a whitelist of devices that work.)
<HWolf> It's the kind of thing that caused sarge to ship with security disabled in /etc/apt/sources.list - every devel must have noticed that, fixed it in a few seconds, and went on with his live.
<daniels> actually, I'm betting that most just weren't *using* sarge out of the box, CD-wise
<daniels> i do test installs, but I don't use them for terribly long; I stay with the same install I've had for a while
<daniels> customising it to work again just takes too long
<daniels> also, they were enabled, just wrong
<daniels> so it was a bit too subtle
<HWolf> It nicely illustrates the "works for me, no issue" kind of problem, tho.
<daniels> sure
<daniels> but sometimes there are failures you really just can't detect
<daniels> such as the security line shipping with 'testing' rather than 'unstable'
<daniels> in any case, if you do have any specific issues with X et al, please do let me know and I'll do what I can
<HWolf> X has been a charming bit of software since I started loving ubuntu, no issue there, but I'll let you know. :)
<HWolf> I'll do a breezy test once it's somewhere near usable, and give you the heads-up on the mouse thing tho.
<bob2> HWolf: er, the sarge issue wasn't noticed because the problem only manifested itself after stable pointed at sarge on the mirrors
<daniels> x charms no-one
<HWolf> Reason I bring this up is that I regularly have these discussions, and often people are like "well, it works for me / is not much of an issue / it'd only save the user a few seconds of time if I did that" and they'll happily go on hacking some nice new feature. :)
<daniels> sure
<daniels> sometimes there's not much we can do -- 'mouse wheel doesn't work' isn't entirely useful in and of itself
<daniels> so as much information as you can give is awesome
* HWolf grins
<daniels> anyway, bbiab
<HWolf> I understand that the information I give just now isn't entirely adequate. :)
<mdke> filing bugs is the best thing
<mdke> even for the smallest usability issue
<lsuactiafner> anyone know how many simultaneous connections a user opens when he browses compared to having a p2p app on?
<HWolf> lsuactiafner, p2p usually takes up a magnitute more in connections than simple browsing.
<lsuactiafner> 1:100 ratio?
<HWolf> mdke, know what you're asking. That'd go from evo not checking mail at startup to that stupid progress-bar in archive-manager that doesn't display progress and back.
<lsuactiafner> i need to limit outgoig TCP SYN request else i get flooded with ACKS on my 5k/s dailup
<mdke> HWolf, absolutely anything
<HWolf> lsuactiafner, I'd say somewhere 10 or 50:1, but I'm not an expert.
<HWolf> mdke, like them in bugzilla here, or upstream? :)
<lsuactiafner> thanks
<mdke> HWolf, well it depends, both i guess. Sometimes they will get pushed upstream if you file them here first
<mdke> HWolf, here is an example: https://bugzilla.ubuntu.com/show_bug.cgi?id=6076
<HWolf> lsuactiafner, fyi, If I'm using torrent, i'm usually *limiting* uploading to 20 people per file.
<HWolf> mdke, cool.
<lsuactiafner> torrents dont even work for me, too slow
<lsuactiafner> getting via a ftp is faster
<HWolf> Going OT there. ;)
<HWolf> btw, how do I find out which program is swapping even tho I have 600mb ram free?
<Lathiat> HWolf: why are you concerned
<Lathiat> its not an issue
<Lathiat> linux will swap stuff out to keep disk buffers in memory
<Lathiat> which is a much better use
<HWolf> Hm, so the kernel will do that?
<Lathiat> yes
<HWolf> Looks silly to me, but ok
<lsuactiafner> HWolf : sysctl -a | grep mem and ratio
<HWolf> mdke, I'll blame you if I drive seb128 into cardiac arrest. 4 bugs on his plate, and that's just the things that come to mind now. :P
<lsuactiafner> sysctl -e vm.overcommit_memory=1
<lsuactiafner> vm.overcommit_ratio=16
<lsuactiafner> works better like that in my experience but dont take my word for it
<mdke> HWolf, *grins* ok. Make sure you check bugzilla to make sure the bug isn't already filed tho
<HWolf> mdke, sure thing.
<HWolf> I'll refrain from indulging till I switch to breezy tho. :)
<Keybuk> meh ... *so* hot today :(
<thom> not as  silly as yesterday
<azeem> how was the concert?
<HWolf> thom, it's worse than yesterday here
<HWolf> or rather, much much nicer. ;)
<thom> azeem: very, very, very good
<thom> better than good
<azeem> cool
<HWolf> thom, very good is better than good, yes. :P
<sabdfl> jdub: it should be fixed now, rebooting and dashing out
<sabdfl> privmsg me if there are further issues
<sabdfl> i'll pick them up when i get back
<mdke> oooh
<mdke> we got mail
<bob2> lists are back
<mdke> :)
<ogra> yay
<Keybuk> oh, crap
<doko> Kebuk: do you mean 11966? ;)
<Keybuk> doko: no?
<\sh> nice..the MLs are working again
<tseng> thom: any idea why network-manager seems to be killing my X session when i walk away?
<tseng> thom: i come back and vt7 is at the console with a bunch of dhcp crap
<thom> tseng: huh, weird
<HWolf> Guys, can't you patch firefox to deny it acces to my sound system?
<tseng> dont install flash?
<infinity> ...
<HWolf> tseng, that'd turn half the internet off-limits. :S
<tseng> i dunno what sites you are going to
<tseng> flash is for suckers
<HWolf> Nearly worth it, with the amount of flash-based popups for ringtones I get nowadays. :S
<HWolf> One moment I'm listening to mozart, the next it's crazy frog, or whatever the next hype will be. :S
<xxenon> hi
<xxenon> is "noinotify" still needed when starting a 2.6.12 kernel ?
<zul> xenon: no
<wasabi> Oh damn.
<wasabi> I found my Eclipse compile problem. When I don't use fakeroot it works fine. ;)
<mdz> daniels: the reports of XKB trouble seem to indicate that perhaps other patches were dropped from earlier versions as well
<jdub> mdz: weirdly, my keyboard worked with xorg -28 but not -29
<ogra> mine is still stuck at us mapping and 101 keys
<mdz> jdub: not so much weird as ludicrous ;-)
<mdz> ogra: that's been broken since ~-26; I haven't tried to fix it
<mdz> dvorak seems to work ok
<ogra> yes
<ogra> i noticed
<mdz> ogra: if you can test it, look back through the revisions and look for a patch reverted without being mentioned in the changelog, and try reversing that change
<ogra> i'll do... after i reviewed the patch i'm looking at
<infinity> ...
<infinity> Not so much "without being mentioned", but "being unmentioned".
<infinity> Try to un-revert the patch that gets unmentioned from the -24 changelog. :)
<Mithrandir> unrevert, aka "apply"?
<infinity> (if you debdiff from -24 to current, you'll see some lines in the -24 changelog get mysteriously changed)
<infinity> Mithrandir : Yes. :)
<infinity> I haven't had a chance to look at it, due to it being a weekend, and me liking not being single.
<mdz> infinity: do you still have some notes or something you could share?  it sounded like you had isolated the bit that should be reapplied
<infinity> But I suspect that re-applying the stuff that got dropped from 24 to 25 will make people's keyboards live again.
<infinity> mdz : The computer I was looking at it on is now in intercontinental transit, so I have nothing beyond handwaving in front of me.
<mdz> -25 is gone from the mirrors, but I suppose it's still in the morgue
<infinity> (a friend is coming to visit, and bringing the PPC machine that's been colocated at his house for the last 2 years)
<infinity> -24 is the important one.
<infinity> debdiff from -24 to anything newer will show the dropped "xkb cleanup" patches.
<infinity> Err, no, from -25 to current.
<infinity> -24 was just an FTBFS fix.
<infinity> Meh, I wake up and start work in 6 hours anyway.  If it's still unfixed by then, I'm "on the job", so I'll get it done.
* infinity -> sleep.
<mdz> infinity: ogra said he would take a look when he finished with his current work
<infinity> mdz : Alright, I'll ping ogra in the morning, then.  Or just check -changes for uploads. :)
<infinity> ogra : If you get completely lost in a maze of X breakages, mail me, or hang around for 6ish hours and catch me on IRC.
<ogra> heh, i'll do... but i'll keep my current X version around so i should be able to switch back if needed.... its the big time of gnome-charmap here :)
<mdz> Kamion: I would like to add a line to sshd_config when ltsp-server is installed, and remove it when it is removed.  Which method would you recommend?
<infinity> ogra : Ahh, I was right the first time.  Look at the diffs between -24 and -25.
<infinity> ogra : The that I think we want back was introduced in -21, and dropped in -25 (in diffs from -24 to -25, you'll see that the -21 changelog gets changed retroactively)
<infinity> s/The that/The patch that/
<infinity> And now, to bed.
<ogra> infinity, i'll do, GO TO BED NOW !! 
<infinity> Yes, mom.
<ogra> heh
* Mithrandir pats infinity on the head
<Kamion> mdz: run away. sshd_config is handled really badly at the moment
<Kamion> mdz: what exact line do you need to add?
<Kamion> daniels: can't remember what I pinged you about
<Kamion> daniels: oh, it was xterm being uninstallable and unbuilt by anything
<mdz> Kamion: "AcceptEnv LTSP_CLIENT"
<Kamion> I wonder if that could just go in the default config - although it's rather unclean
<mdz> if you don't mind adding it to the default configuration, that is of course fine too.  I don't know why environment variables shouldn't be accepted by default though
<Kamion> er, LD_PRELOAD
<Kamion> (say)
<mdz> Kamion: I don't see the issue, unless it's a command-restricted login
<Kamion> well, that exactly
<Kamion> sshd doesn't distinguish at that point
<Kamion> (afaik)
<mdz> ah
<mdz> due to privsep, or just the way it is?
<Kamion> there are other kinds of restricted environments, remember
<Kamion> e.g. restricted shells
<mdz> yes
<Kamion> plus in general I just prefer to be paranoid where sshd is concerned :-)
<Kamion> so what goes in LTSP_CLIENT?
<mdz> it's analogous to SSH_CLIENT
<mdz> it'll just say where the client came from
<mdz> but mostly things will just test whether it is set
<mdz> to do things like, e.g., use  different xscreensaver configuration
<Kamion> hmm, ok
<mdz> s/  / a /
<mdz> hmm
<mdz> I suppose I could pass it via the command instead
<mdz> ssh server env LTSP_CLIENT=blah <command>
<mdz> as long as I can suffer the quoting issues
<ogra> mdz, ssh has a option to pass env vars....
<Kamion> if you stick with the AcceptEnv version, I think I'd prefer ltsp to do the sshd_config modification
<mdz> ogra: see above
<Kamion> ogra: that's what he's using
<ogra> ah
<ogra> sorry, missed that
<Kamion> hmm, I wonder if multiple AcceptEnv variables work
<mdz> I should hope so
<mdz> but I'm going to try the env approach I think
<Kamion> well, you can also do 'AcceptEnv FOO BAR BAZ' which is why I'm checking
<Kamion> ah, yes, the man page says multiple AcceptEnv settings work
<Kamion> so you can just stick 'AcceptEnv LTSP_CLIENT' on the end, and remove any line precisely matching that on removal
<Kamion> should probably get upstream to implement Include <directory> at some point, although I'm betting they won't see the need
<mdz> bah, need to reboot due to 2.6.12 abi change
<mdz> gah, rebooting cost me my working xkb setup
<ogra> hmm, whats wrong with the morgue, the listing stops at 2005-03-29
<danielki> hmm
<danielki> probably because that's my birthday
<mdke> hmmm
<mdke> how has dholbach succeeded in subscribing to the whole wiki
<mdke> i am intrigued
<ogra> mdz, Kamion ? any idea how to get the packages ?
<thom> mdke: .* in the subscribe line should do it
<mdke> thom, aha
<mdke> thom, doesn't seem to have done the trick
<abarbaccia> hey all - can someone give me a gameplan on whats going to be included in breezy?
<whiprush> abarbaccia: scour udu.wiki.canonical.com
<whiprush> everything is in there
<whiprush> BreezyGoals will give you a general idea
<Echylo> slaapwel iedereen :)
<mdz> ogra: any luck with xorg?
<ogra> mdz, not yet
<ogra> i cant compare with -21, the morgue doesnt have packages after 2005-03-29 it seems....
<mdz> -24 is still in the archive; that's all we need
<ogra> but it looks like a symlinking problem...
<ogra> mdz, /usr/X11R6/lib/X11/xkb -> /etc/X11/xkb/ and /usr/lib/X11/XKeysymDB -> /usr/share/X11/XKeysymDB might do it
<mdz>    * Fix keysym<->string semantics by backporting the rest of Markus Kuhn's
<mdz> -    Great Keysym Cleanup from HEAD, and creating a symlink from
<mdz> -    /usr/lib/X11/XKeysymDB into /usr/X11R6/lib/X11 (closes: Ubuntu#10942).
<mdz> +    Great Keysym Cleanup from HEAD (closes: Ubuntu#10942).
<mdz> yep
<mdz> diff -u xorg-6.8.2/debian/xlibs-data.links xorg-6.8.2/debian/xlibs-data.links
<mdz> --- xorg-6.8.2/debian/xlibs-data.links
<mdz> +++ xorg-6.8.2/debian/xlibs-data.links
<mdz> @@ -2,2 +1,0 @@
<mdz> -usr/X11R6/lib/X11/XKeysymDB usr/lib/X11/XKeysymDB
<mdz> -usr/X11R6/lib/X11/XErrorDB usr/lib/X11/XErrorDB
<ogra> hmm
<mdz> I will test and upload
<ogra> @|~
<ogra> works :-D
<mdz> ogra: ok, you upload then. my build failed :-)
<ogra> meh, i havent built yet....
<ogra> ok
#ubuntu-devel 2006-06-19
<raphink> malone #1
<Ubugtu> Malone bug 1 in Baltix "Microsoft has a majority market share" [High,Confirmed]  http://launchpad.net/bugs/1
<raphink> debian #12345
<raphink> debian #2345
<raphink> :(
<raphink> debian 326833
<Ubugtu> Debian bug 326833 in kdelibs "Subject: kdelibs: KDE pseudoprinters do not work" [Normal,Closed]  http://bugs.debian.org/326833
<Keybuk> anyone awake?
<crimsun> specifically?
<mjg59> Yes
<Burgundavia> Keybuk: no, we are all living dead
<Keybuk> no, just in general
<Keybuk> I wanted to see whether evil-binary-teamspeak-crap works
* mjg59 = gone
<crimsun> Keybuk: would love to test, but I'm horribly firewalled here.
<Burgundavia> Keybuk: teamspeak binary crap? got a download link, I can test it
<Burgundavia> isn't mark funding that somehow?
<Keybuk> http://www.goteamspeak.com/index.php?page=downloads&id=2a
<zul> i have teamspeak installed but i dont have a mic
<Burgundavia> give me a sec
<zul> yay...xen is building
<Burgundavia> Keybuk: where are you?
<Keybuk> teamspeak.uds.canonical.com
<Keybuk> or do you mean where, locality-wise?
<Burgundavia> Keybuk: the latter. I am having issues my laptop, just a sec
<Keybuk> Paris,
<Keybuk> CDG
<Burgundavia> oh, yes, forgot completely about that
<tseng> hi Burgundavia 
<Burgundavia> hey tseng
<Burgundavia> Keybuk: sorry, just got crunched for time, so I will not able to help out with testing
<Keybuk> aww
<Burgundavia> specifically, I am going out for dinner and lost track of time
<Keybuk> ooh, anyone cute?
<Burgundavia> my ex, sadly
<Keybuk> aww
<Keybuk> was that a yes?
<zul> oh that must be fun
<tseng> Keybuk: harsh
<Keybuk> *shrug*
<davfigue> Good evening 
<davfigue> could anybody help with recovering /dev/eth0 ?
<Hobbsee> hi everyone
<davfigue> hi
<Hobbsee> davfigue: that's probably a question for #ubuntu and most of the devs are in paris at the moment - it's almost 5am there
<davfigue> thanks
<RadiantFire> Hobbsee: did you get my e-mail back about the spazz's module-assistant is having with the ndiswrapper packages you gave me?
<Hobbsee> RadiantFire: indeed, i did.  that's weird, about how only one bit built, not both
<RadiantFire> if i read the error right somewhere a version number in the dependency is wrong
<RadiantFire> cuz when I just compile the module manually all works fine
<Hobbsee> yeah, but when you compile the module manually, it only seems to do two files?  and this one outputted one? i'll have to see what it's doing there...
* Hobbsee glares at it menacingly
<Hobbsee> at least i dont have another exam for a full week!
<RadiantFire> still having exams?
<Hobbsee> yes, i had one this morning
<davfigue> Hobbsee: this channel is for package developers, right ?
<Hobbsee> davfigue: see the topic
<davfigue> Hobbsee: excuse me, I have a question, what I have to do to become a developer ?
* Hobbsee notes the /topic again
<Hobbsee> davfigue: http://www.ubuntu.com/community/participate
<davfigue> Hobbsee: thanks !
<Hobbsee> davfigue: not a problem
<jdong> is the edgy kernel still "dapper-compatible"?
<jdong> for the daring and reckless? ;)
<Burgundavia> tseng, Keybuk, that would be a yes
<crimsun> jdong: to some degree, yes
<crimsun> jdong: though if you're going to do that, you probably want to go Edgy wholescale in a vm
<jsgotangco> bonjour!!!
<ajmitch> :P
<jsgotangco> monsiuer ajmitch!
<robitaille> monsieur :)
* ajmitch watches jsgotangco mangle the language :)
<jsgotangco> heh
<Burgundavia> hey jsgotangco
<jsgotangco> hi
<jsgotangco> man we only have french outlets here
<jsgotangco> euro plugs won't fit
<Hobbsee> heya jsgotangco 
<fabbione> bella scott
<Keybuk> bella fabbione!
<fabbione> how is going?
<Burgundavia> Keybuk: you didn't tell me I was going to be testing QT crap. Bad enough that it is closed source
<Burgundavia> Keybuk: and yes, my ex is cute. :(
<TheMuso> Morning all.
<ajmitch> hi TheMuso 
<fabbione> ajmitch: please use your real name in TeamSpeak
<fabbione> Hobbsee: the same please
<LaserJock_> TheMuso: hi!
<ajmitch> new rules now?
* ajmitch reconnects
<Hobbsee> fabbione: i almost never go by my real name
<jsgotangco> bye bye Player
<fabbione> when you are face to face you don't call people by IRC name
<TheMuso> Hey LaserJock_. How was your flight?
<Mithrandir> fabbione: I often do.
<LaserJock_> TheMuso: long, and yours?
<TheMuso> Very long.
<ajmitch> hey pitti 
<TheMuso> To top it of, my ffinal flight from Dubai was delayed.
<TheMuso> Hey ajmitch.
<ajmitch> Mithrandir: sorry I didn't stick around the other night
<fabbione> Mithrandir: that's probably because of we already know each other 
<Hobbsee> fabbione: as you wish :)
<fabbione> Hobbsee: thanks :)
* Hobbsee starts to count
<fabbione> nothing real will start before 1 hour and something
<fabbione> 13 minutes to start -> introduction ..etc.
<Hobbsee> yes, when i'm at work
<Keybuk> siretart: ping
<netstar> Anyone using powerpc and libxine and having issues?  I've found the cause but could do with some help.
<lifeless> is the cuase libxine ?
<lifeless> [I'm not a ppc user, can't help there] 
<Seveas> Keybuk, is the ip address of the hotel fixed?
<Keybuk> Seveas: yes, could we get a "PLEASE DON'T K-LINE US" from the IRC people
<Keybuk> I tried last night but they were all away
<Seveas> working on iy
<netstar> the cause is internal POWERPC assembly routines that are just broken
<netstar> Though I can't fix them :P
<Mithrandir> fabbione: you
<Mithrandir> argh
<Mithrandir> you're clipping
<fabbione> Mithrandir: probably better if use the talk on button
<fabbione> or whatever is called
<fabbione> otherwise each time somebody laughs you talk
<ajmitch> picking up a lot of background noise, too
<fabbione> yeah
<fabbione> i can hear Mark
<Mithrandir> I've increased the voice activation thingy.
<Seveas> hmm, I misread that as 'I can fear Mark' 
<Mithrandir> fabbione: better now?
<ajmitch> now we get a couple of seconds of sabdfl
<Mithrandir> (it ought to be, I've muted my mic)
<fabbione> Mithrandir: yeah
<fabbione> Mithrandir: but it's best if you enable the press to speak
<fabbione> instead of speak on voice
<Mithrandir> fabbione: that's going to be really, really annoying.  I'm running it through vmware
<fabbione> Mithrandir: i know, but it's equally annoying for all the others to hear all the noise
<shenki_> is this audio being streamed for all to hear?
<Hobbsee> shenki_: you can just join the server, and not speak...
<shenki_> Hobbsee: where can we find details on that? (where the server is, what's happening when etc)
<Mithrandir> shenki_: https://wiki.ubuntu.com/UbuntuDeveloperSummitParis/Participate
<netstar> how can I stop debuild making clean when rebuilding?
<Seveas> Keybuk, k-lines should not happen and no one should be blocked, modulo some tidbits lilo is fixing up right now
<Keybuk> Seveas: thanks, and thank them for us
<Mithrandir> netstar: debuild -nc
<shenki_> Mithrandir: thankyou :) a few of us in #ubuntu-au were looking for a page such as that, it doesn't seem to be linked from anywhere though
<Mithrandir> shenki_: it should be linked to from https://wiki.ubuntu.com/UbuntuDeveloperSummitParis, but might not be there.
<shenki_> Mithrandir: yeah, it's not there. thanks again.
<Keybuk> fabbione: did you have approval from ubuntu-release for your dapper-updates upload?  (silo)
<fabbione> Keybuk: hem.. *cough*no*cough* but it fixes one of the 3 release KnownIssues left from dapper
<fabbione> Keybuk: so perhpas let's wait for mdz/Kamion to review before you reject
<Keybuk> fabbione: s'ok, I don't reject from unapproved unless it's specifically denied
<sivang> morning all
<fabbione> Keybuk: ok thanks.
<Keybuk> mostly people have approval, or have asked for it
<Keybuk> and in those cases, usually I don't get cc'd :p
<simira> morning sivang. Are you also in .fr?
<Keybuk> so I as
<Keybuk> +k
<sivang> simira: yeah
<fabbione> Keybuk: no, i didn't have approval but the patch is trivial and it's a very good fix
<Keybuk> agree
<Seveas> is noone talking on teamspeak or is my client misconfigured?
<siretart> Keybuk: pong
<jsgotangco> we're just introducing specs atm
<netstar> Mithrandir: delayed thanks
<shenki_> random guests on the teamspeak chanel are not allowed to talk, but is there a reason why we also have our 'headphones muted' set by the server?
<Keybuk> hmm?
<Keybuk> random guests should be allowed to talk
<Keybuk> if your icon is muted then your client thinks your microphone is muted
<shenki_> okay. either way, I don't really have a need to talk, but i'd like to listen - and telling it to 'unmute' my headphones does nothing
<shenki_> is that a problem on my end?
<Hobbsee> Seveas: no one's talking
<ajmitch> shenki_: generally yes
<Seveas> Hobbsee, that explains the silence I get 
<Hobbsee> Seveas: quite possibly, yes :P
<Seveas>  silence is golden 
<ajmitch> teamspeak is OSS only, so nothing else is allowed to be using /dev/dsp
<Seveas> dennis@mirage:~/Desktop/ts2_client_rc2_2032$ lsof /dev/dsp | tail -n1
<Seveas> TeamSpeak 29515 dennis   19u   CHR   14,3      9127 /dev/dsp
<Mithrandir> ajmitch: unless your sound card does hardware mixing.
<ajmitch> sadly mine doesn't
<ajmitch> so I run TS on the laptop instead :)
<Hobbsee> i think imbrandon found a way around that...
<Seveas> you can use a dsp hijacker
<shenki_> hmm. everything is unmuted, and nothing is using /dev/dsp, any suggestions?
<Hobbsee> i would say "mute kde or equivalent sound" but you've probably done that
<Hobbsee> bye all!  back in a few hours...
<Seveas> Kinnison is blinking
<Seveas> ooh, I got sound from jsgotangco 
<imbrandon> lol
<jsgotangco> ackk sorry...my teamspeak was configured on alt gr
<Treenaks> Seveas: you're writing a Free teamspeak replacement? :)
<Seveas> hell no
* imbrandon thought about it but i dont have any voip experince
* jsgotangco wonders where he could get an FR adapter atm...
<Seveas> fabbione, !
<fabbione> yo yo
<jsgotangco> the extensions are all FR :(
<Seveas> jsgotangco, local supermarket?
<jsgotangco> we're in the middle of nowhere haha
<LaserJock_> heh, where's one of those?
<Seveas> jsgotangco, hotel lobby?
<imbrandon> Seveas, on _MY_ setup if you load apt-get install alsa-oss and then modprobe snd-pcm-oss it remaps /dev/dsp to alsa, works for me but not everyone seems to get it working that way
<jsgotangco> you go out, you see a wheat field
<msw> Treenaks: couldn't one just use an asterisk meet-me conference, then use one of many free VoIP clients?
<msw> Treenaks: (regarding a free replacement)
<LaserJock_> highvoltage and I took an bit of a walk when we got here to see if we could find a SIM card
<imbrandon> msw, thast what i was thinking
<Treenaks> msw: or jabber + that google voice thing + conference mode ?
<msw> Treenaks: hmm... I'm not familiar with how they implemented it
* imbrandon still thinks the room should be mic'd ( not much on TS atm )
<jdub_> msw: one of the desired features was flashy lights for the current speaker
<imbrandon> VoIP isnt much good if we cant hear whats going on
<msw> the main problem with asterisk meet-me is echo cancellation (currently it's easy to get an echo chamber when you have tons of participants)
<msw> jdub_: oh dude, there's an asterisk app for that I think
<jdub_> msw: none of the free clients (that i have seen) include it
<imbrandon> jdub there is an astrix app that does that
<msw> jdub_: I believe there are several -- one is proprietary I think.
<crimsun> shenki_: I can assist in #ubuntu if you're still having issues
<jdub_> msw: meanwhile, this works, and was driven by sabdfl
<shenki_> crimsun: I just tried alsa-oss, i'll see how this goes. if not, cya in #ubuntu :)
<lifeless> sfllaw: the spec name for the pluggable automated test framework is very uninformative - do you mind if I rename it 
<msw> jdub_: just checking, the current app_conference (note not app_meetme) has speaker detection messages sent via the AMP (asterisk management protocl)
<jdub_> msw: meanwhile, are you in atlas?
<msw> jdub_: *nod* - I'm a big fan of using what works. ;-)
<msw> jdub_: nope
<jdub_> when are you getting in?
<sfllaw> lifeless: It's actually meant to be a collection point for information about deviations from expected behaviour.
<sfllaw> So the name is pretty useful, if you're not implementing it.
<msw> jdub_: I'm here...
<jdub_> oh
<jdub_> why aren't you in atlas?
<jdub_> oh
<msw> jdub_: I'm sitting to the left of ian
<jdub_> oh
<lifeless> sfllaw: sounds like two specs to me - a infrastructure thing to build, and a process that will use it
<jdub_> that's why i didn't see you
<jdub_> msw: going to guadec too?
<msw> jdub_: I can't. :-(
<msw> jdub_: going on vacation directly after I get back to Raleigh
<jdub_> boh
<msw> jdub_: yea, it's lame
<msw> jdub_: but I had external schedule constraints (the so's vacation week)
* jdub_ prepares a kidnapping
<simira> jdub_: feel free to kidnap me for Paris :-/
<sfllaw> lifeless: We're not specing the process that will use it.  I figure people will use it in innovative fashions that we don't yet expect.
<fabbione> so where is the schedule?
<mdz> fabbione: I've no objection to silo for dapper-updates if you're confident in it
<mdz> fabbione:  there is no schedule quite yet; we're just introducing all of the topics
<fabbione> mdz: yes i am confident with it. It has been tested also at SUN
<fabbione> mdz: ok.. i will wait for it
<Keybuk> you doj
<Keybuk> you don't have to shout their name all the time ;)
<Keybuk> (and gnargh, usual laptop "press enter when I mean backspace" issues)
<fabbione> Keybuk: ?
<Keybuk> fabbione: "Sun" would suffice, not
<Keybuk>  ___ _   _ _  _
<Keybuk> \__ \ |_| | .` |
<Keybuk> |___/\___/|_|\_|
<Keybuk> oh, bah
<siretart> Keybuk: pong?
<fabbione> Keybuk: Sun != SUN ;)
<Keybuk> siretart: who approved the upload of sysinfo
<siretart> I was told that mdz approved it. 
<\sh> do we have an UDS channel? 
<Keybuk> siretart: do you have an e-mail from it?
<siretart> I'm sorry, no
<fabbione> Keybuk: no there was a discussion here in IRC friday i think
<siretart> phanatic should have
<siretart> but he's not around ATM
<lifeless> sfllaw: http://bazaar-vcs.org/BzrExtendTestSuite
<sfllaw> lifeless: Thanks.
<Seveas> OUCH
<Seveas> who was that?
<Keybuk> jdub: http://www.circlemud.org/~jelson/software/fusd/
<Keybuk> GRUB2! FOR ALL EDGY ARCHITECTURES!
<Keybuk> </mdz>
<msw> hah
* msw remembers doing the lilo->grub change in Red Hat Linux.  Mmm, painful
<Kinnison> Can everyone on teamspeak who is using one of the funky headsets here please ensure they're not near any mobile phones which are turned on. The dit dit dit dit does come through online and it'd be nice if we didn't end up recording it
<sivang> Kinnison: are we recording the spec presentation session ?
<\sh> solution: switch of the mobile ;)
<Kinnison> sivang: I think that's the intention
<sivang> Kinnison: makes sense
<Keybuk> Kinnison: what if you're using teamspeak, but the person next to you isn't and is using their mobile phone?
<Kinnison> Keybuk: then murder them in cold blood
<sivang> hehe
* Kinnison admits this may contravene the CoC
<\sh> lol
<fabbione> what happeed to team speak?
<fabbione> everybody has been kicked out
<ajmitch> it hurt my ears
<\sh> network down in paris
<\sh> looks like
<\sh> or port's closed
<Seveas> hmm, conference dropped off the net
<simira> ouch...
<simira> what happened?
<ajmitch> they all died?
<simira> I hope not...
<ajmitch> seems like a few of them are still alive
<Fujitsu> Where'd everybody go?
<msw> Fujitsu: network failure
<msw> Fujitsu: just getting back online now
<Fujitsu> Everybody on the same network? At UDS Paris?
<msw> Fujitsu: I think there are a few ADSL lines, but everyone is currently in one room
<Fujitsu> Ahh. That'd do it :(
<TheMuso> Ok that was fun.
<sivang> simira: we lost adsl for some minutes
<TheMuso> Anybody here at the summit trying to send email to an smtp server? If so, how are you doing it I am being blocked from sending to a smtp server.
<LaserJock> TheMuso:  I'm using gmail instead
<Mithrandir> TheMuso: works fine for me.
<Mithrandir> 220 vawad.err.no ESMTP Exim 4.60 Mon, 19 Jun 2006 11:34:12 +0200
<TheMuso> hmmm.
<LaserJock> TheMuso: that is to say, I had a problem to so switched to gmail
<TheMuso> Ok then.
<TheMuso> argh
<TheMuso> I'd rater not change to gmail if I can help it.
<Mithrandir> TheMuso: follow the instructions on http://freerelay.err.no/ and you should be fine.  If you can't use port 25, use 2525 or 6667
<TheMuso> Thanks.
<mdke> Znarl: dunno if it was you that fixed my email, but it's going to the right place now :) Thanks if you did!
<jsgotangco> hi mdke
<mdke> hi jerome
<pitti> mdz: do you want to approve https://launchpad.net/distros/ubuntu/+spec/rosetta-desktopfile-ui for Paris? or is that too late?
<msw> http://people.ubuntu.com/~mdz/schedule/2006-06-19/
<Znarl> mdke : Was not fixed by my actions.  
<mdz> pitti: will do
<Riddell> sivang: coming upstairs?
<sivang> Riddell: yeah, on my way - level 1 , which room?
<Riddell> sivang: level 2
<Riddell> turn right
<sivang> okay, see you there.
<Riddell> does gobby work?
<fabbione> Riddell: yeah
<Riddell> what server?
<fabbione> make sure to use "Join Session" instead of "Create.."
<mdke> Znarl: oh well, must have fixed itself. :) chances of wiki love during Paris are slim I guess?
<Riddell> fabbione: what's the gobby server?
<fabbione> gobby.uds.ubuntu.com
<Riddell> doesn't work from here
<Mithrandir> what port?
<Riddell> 6522
<tseng> WAUGH!
<jdub_> HUH!
<jdub_> GOOD LORD!
<Seveas> jdub, you called?
<Seveas> ehrm, no more teamspeak?
<ajmitch> lunchtime!
<ajmitch> most people would have packed away their laptops & wandered off to grab food
<HiddenWolf> ajmitch: rude, now we'll miss all the gossip. :)
* HiddenWolf hides.
<ajmitch> it's always the way..
<\sh> gossip: Chinese Food 
<\sh> every day ;)
* ajmitch has hardly touched chinese food since then :)
<\sh> ajmitch: yeah
<sorenh> Er... What happened to the session in Dionysos?
<fabbione> ?
<sorenh> fabbione: mvo and sivang just showed up, so now we're getting somewhere. I was all alone a second ago. :-D
<sorenh> fabbione: Dionysos is one of the conference rooms.
<fabbione> ah ok
<sorenh> Everybody know that. :-D
<Hobbsee> hi all
<zul> hi Hobbsee 
<raphink> hi Hobbsee
<_ion> hi Hobbsee
<profoX`> hi Hobbsee 
<Fujitsu> Evening, Hobbsee.
<Hobbsee> hey zul raphink _ion profoX` and Fujitsu 
<Hobbsee> wow
<Fujitsu> ?
<profoX`> lol
<Hobbsee> lots of people saying hello
<profoX`> we're a friendly bunch
<Seveas> bye Hobbsee 
<Hobbsee> heh, bye Seveas :P
<Fujitsu> Silly developer summits... They leave this channel in a pile of rubble :(
<jono> hey
<Seveas> hi Jon O'Bacon ;)
<jono> Seveas, oi!
* Hobbsee wonders if keybuk is really hard to understand to anyone else.
<Seveas> Hobbsee, indeed
<fabbione> Hobbsee: nah
<Seveas> fabbione, via teamspeak that is
<simira> Fujitsu: whatdidyousay? ;p
<Fujitsu> Goodnight everybody!
<msw> 5
<msw> doh
<raphink> question: if I request a rebuild for edgy because a package FTBFS because of the debhelper stuff
<raphink> should version number be -Xbuild1 and distro be edgy ?
<ajmitch> I think that packages will probably get thrown back at the buildds anyway
<raphink> ajmitch: ah?
<ajmitch> that's what usually happens if the build fails on all archs
<raphink> ok 
<raphink> :)
<raphink> how about the ones marked as waiting dependencies ?
<ajmitch> same
<raphink> ok, good :)
<Seveas> sivang, you're causing echo
<Seveas> sivang, please enable your mic only when speaking
<ajmitch> darn, should have told jsgotangco to go & 'sort out' sivang
<jjesse> is there an echo ?
<Hobbsee> hehe
<ajmitch> yes
<ajmitch> echo & hum
<Hobbsee> wish everyone would get rid of the "new player" thing too...
<Hobbsee> if they're playing with their systems :P
<imbrandon> nah , this better be a good bounty for group voip lol
<imbrandon> bah*
<Hobbsee> heh
<Hobbsee> heya Keybuk 
<fabbione> Keybuk: hey dude.. wouldn't be a good idea to start closing old channels?
<fabbione> Keybuk: or make a rule that who create the chan gets to close it?
<fabbione> otherwise we will end up with 3948394831298349 chans
<imbrandon> are they all sharing sivang mic or something ?
<Keybuk> fabbione: meh, I go around and close them every now and then :p
<fabbione> ok
<shenki> teamspeak is fairly useless for anyone trying to follow along online, with only a couple of the speakers talking into it
<jjesse> shenki: agreed, can barely hear anyone except mark
<Hobbsee> shenki: the last session was better
<shenki> jjesse: I think that sivang has their mic permantly on, and because of that we can *almost* hear what others are saying...but yeah, mark seems to be the only one using it
<shenki> we'd be better off if there was a mic in the middle of the table/front of the room
<jjesse> looks like sivang has turned off the mic now can't hear anything :(
<Hobbsee> jjesse: sivang quit :P
<jjesse> ah
<jjesse> seems sort of pointless to try and follow online then
<Hobbsee> ah there we go
<shenki> ?
<jsgotangco> welll
<Hobbsee> we did have him back for a bit :P
<shenki> ah
<shenki> anyone who's in the room want to remind/ask people to talk into a mic?
<fabbione> shenki: just tell them in teamspeak
<fabbione> they will NOT kill you if you do so
<Hobbsee> famous last words :P
<shenki> fabbione: I don't have a mic with me
<fabbione> Hobbsee: shhh :P
<jjesse> me either
* Hobbsee does, but doesnt want to speak.
<fabbione> ajmitch: ping?
<ajmitch> pong
<ajmitch> fabbione: what's up?
<fabbione> ajmitch: can you read above please?
<fabbione> ajmitch: about people not talking in the mix
<fabbione> mic even
<ajmitch> yes?
<fabbione> ajmitch: can you please report it to the channel you are in ?
<Hobbsee> (into teamspeak presumably)
<fabbione> since you are in the same channel as them
* ajmitch seems to have a very quiet mic, will try
<shenki> yes, that is a very quiet microphone there ajmitch :)
<ajmitch> probably some sound settings to tweak
<shenki> yay
<mako> jdub_: has the issue with the irc stuff been resolved?
<mako> jdub_: lilo claims it has
<theine> Thanks for fixing #50031 (at least for me) so quickly.
<sivang> Seveas: yeah, I noticed it eventually, thanks :-/
<glatzor_mobile> hi sivang: where are you?
<glatzor_mobile> you are not in atlas, right?
<glatzor_mobile> i replied to mpt's proposal. perhaps we should use the time for the spec to collect use cases and possible workflows.
<desrt> wow.  i just got a really confusing email from andrew morton
<desrt> what to do -- http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt
* desrt wonders if ben's git tree counts as "a git tree"
<Mez> Kamion: pingt
<Mez> Kamion: ping *
<Mithrandir> __keybuk: got a second?
<Mithrandir> __keybuk: nm
<__keybuk> Mithrandir: no
<shaya> what does ubuntu use to intelligently partition a disk?
<shaya> need to do a similiar thing and wondering what I can use/reuse
<ajmitch> pitti! gcc-ssp now?
<pitti> ajmitch: yep
<ajmitch> you have teamspeak, or just gobby?
<pitti> ajmitch: I'm still alone on the table, though
<ajmitch> ok
<pitti> ajmitch: no TS, I'm on powerpc :/
<shaya> btw, is it just me or do other people have locale problems in edgy?
<Hobbsee> pitti: easier to hear you speak that way :P
<ajmitch> ah :(
<Hobbsee> oh
<pitti> shaya: known, locales are broken in edgy
<shaya> ok
<shaya> works, just perl is annoying :)
<ajmitch> pitti: which gobby port are you on?
<pitti> ajmitch: 9004
* fabbione heads offline
<fabbione> cya tomorrow
<ajmitch> bye fabbione 
<Hobbsee> bye fabbione 
* desrt has conference jealousy
<desrt> wow.  edgy is fast.
<ajmitch> hehe
<ajmitch> fast to crash & burn?
<desrt> fast from now until release
<desrt> UVF is next month already
<ajmitch> as the current spec suggests, at least
<sladen> desrt: that's just a bit too soon...
<sivang> anybody know if the common-customization BOF is taking place?
<Kinnison> Yes
<Kinnison> You're not in it
<Kinnison> I am
<sivang> Kinnison: but you don't seem to be talking at all :-) I was sure some more drafting / work on the release schedule is being done.
<Kinnison> gobby 9001 / Common Customisations
<\sh> oh god...you need a wired keyboard, to bind a bluetooth keyboard to the bluetooth dongle...strange IT world...
<Kinnison> heh
<sladen> \sh: can't you just hold the button down;  and then the actual dongles also provide a USB HID interface so that the keyboard function should work even before bluetooth is brought up (eg. in the BIOS)
<\sh> sladen: no..the keyboard lost the complete key
<\sh> sladen: it was on my office window pc
<\sh> sladen: and during bootup it doesn't work...
<sladen> \sh: not even in the BIOS?
<Kinnison> People wanting their spec reviewed should make sure the status in launchpad is set to 'review'
<Kinnison> Reviewers congregate in #uds-review
<\sh> sladen: no
<yosch> hi guys
<yosch> quick question: is there an IRC channel alongside https://wiki.ubuntu.com/UbuntuDeveloperSummitParis/Participate ?
<Kinnison> Would at least one native english speaker like to join in the review process please on #uds-review?
* \sh needs to go
<ploum> Hello
<ploum> I just packaged Rhythmbox 0.9.5 for dapper
<ploum> could someone point me to the transparent-tray-icon patch ?
<ploum> found it, sorry for the noise !
<yosch> quick question about the summit schedule
<yosch> if a session related to a particular spec appears on the current schedule, how do I participate remotely?
<yosch> what gobby ports can I join? is there a irc channel set up?
<yosch> a session I'm particularly interesting in seems to be hapenning now and I'm not in Paris yet :-(
<dieman> which session?
<yosch> dieman: open-fonts in the Olympe room
<dieman> hrm, im not actually down thre, so I dont know which gobby port they are using
<dieman> do you have the hostname from the participate page?
<dieman> https://wiki.ubuntu.com/UbuntuDeveloperSummitParis/Participate
<yosch> dieman: hostname gobby.uds.ubuntu.com
<dieman> problem is i dont know what port either
<dieman> 9008 perhaps?
<yosch> trying
<dieman> is anyone on teamspeak for that one?
<dieman> yeah, they may not be using gobby or teamspeak on that one
<dieman> its been sporradic
<yosch> OK, who can I ping from the participants
<shenki> ploum: would it be possible to grab rb 0.9.5 from you?
<yosch> isn't the gobby port if it's used published somewhere?
<ploum> shenki: http://ploum.fritalk.com/packages/
<shaya> does anyone know of a good way to have an x-widgit (controlled by a shell script) that shows that "work is being done" i.e. something that goes back and forth?
<shenki> yosch: if a session has been using gobby, they tend to announce it as the session starts, maybe over irc, maybe over teamspeek... it hasn't been readily available information :) (just as an observer)
<shenki> ploum: cheers
<yosch> maybe I'm looking at the wrong schedule? 
<yosch> shenki: over IRC, you mean in this channel or in another one?
<shenki> yosch: generally this one. one session was hosted in #ubuntu-meeting. cross your fingers for those kind of details to be fine-tuned tomorrow
<yosch> shenki: OK, got it. Thanks.
<yosch> shenki: just a bit worried about missing some sessions that's all
<shenki> yeah. did you find the schedule page? it didn't seem to be followed exactly, but atleast it gives you an indication
<shenki> It would have been nice if being subscribed to a spec in launchpad ment getting told/reminded about the corresponding session happening
<yosch> shenki: yes I saw the one on ~mdz 
<Kinnison> I've done as much review as my brain can cope with today
<Kinnison> I'll do more tomorrow review session
* Burgwork hugs Kinnison 
<Kinnison> If I've said something in a review of your spec which you don't understand or don't agree with, come and find me
* Kinnison ruffles Burgwork 
<Riddell> mdz: is there a way to request priority for BoFs for tomorrow?
<sladen> mako: you signed a key just based on the key-id and not on the fingerprint
<ploum> shenki: wait ! I upload another version 
<ploum> 0.4.99 so it won't conflict when seb128 will package it itself ;-)
<ploum> I also added the transparency-in-the-tray patch
<ploum> http://ploum.fritalk.com/packages/
<shenki> oh, okay. thanks
<shenki> is this a proper package, or...?
<ploum> proper ?
<shenki> is it made with checkinstall?
<shenki> also, shouldnt you have the version -0ubuntu0?
<ploum> I didn't make it witch checkinstall. I took the 0.9.4 of seb128 and upgraded the code source, deleted a non-needed patch and added the tray patch
<ploum> nothing more
<ploum> -0ubuntu0.. argh.. perhaps you are right
<ploum> not sure
<shenki> oh well, it works, thanks :)
<mako> sladen: what do you mean?
<Burgwork> fabbione, Keybuk: http://www.linux.com/article.pl?sid=06/06/12/1418228
<wasabi> Anybody taken a look at iSCSI under Ubuntu? ie packaging sf.net/iscsi-linux?
<zul> not me
<hughsie> hey guys. Can I get some feedback from http://hughsient.livejournal.com/1906.html wrt to ubuntu please.
<hughsie> I want to know if edgy is going to run pm-utils and if the script runs okay.
<hughsie> mjg59, i think this applies most to you, although I might be mistaken.
<lilbigman80> hi, maybe somebody in here has an idea. I just downloaded and installed the ubuntu 6.06 desktop version on a iBook g4. the installation went well but the system drops me a shell saying i do not have an root filesystem when booting. now i am using the live cd and can see /dev/hda but no /dev/hda[1-6]  with 5 as my root-partition. fdisk works fine on hda but there seem to be no mountable partitions... by the way i have a samsung hd 
<Burgwork> lilbigman80, please try #ubuntu as this is not a support channel
<lilbigman80> ups, sorry. i am gone :)
<Burgwork> no worries
<mjg59> hughsie: That's the plan
<mjg59> But nothing's been done yet
<hughsie> mjg59, gotcha. i guess you're waiting for a formal release, right?
<mjg59> More for me to have some time, I think :)
<hughsie> yes :-) -- I guess we can catch up and grab a few beers a guadec, right?
<mjg59> Sure
<fabbione> so assuming xine crashes and mplayer tells me there is no audo and totem refuses to play this dvd..
<fabbione> what other options do i have other than committing suicide?
<fabbione> mplayer dvd:// to be specific
<fabbione> mplayer radomfileimage does work
<shenki> windows? :P
<fabbione>  /ignore shenki all
<fabbione> feh
<shenki> heh
<shenki> there's always vlc
<Seveas> fabbione, amarok?
<Keybuk> fabbione: ogle
<fabbione> Seveas: i am not in kubuntu
<fabbione> Keybuk: point..
<Seveas> fabbione, amarok reportedly works in gnome too 
<fabbione> Seveas: i am only trying to avoid to install few GB of extra libs if i can avoid it
<bluefoxicy> I generally try to avoid qt
<Seveas> Need to get 25.6MB of archives.
<Seveas> After unpacking 80.7MB of additional disk space will be used.
<Seveas> not nearly a GB ;)
<Keybuk> fabbione: it generally works for me where mplayer doesn't
<bluefoxicy> amarok-xine
<bluefoxicy> looks like it's a xine core
<fabbione> Keybuk: yeah i just couldn't remember all of the names :)
<fabbione> Keybuk: score.. thanks
<Burgwork> Keybuk, fabbione did you see that linux.com wrote about your f1 tool?
<fabbione> Burgwork: yes thanks :)
<fabbione> it's MOVIE TIME!
<fabbione> later
<Keybuk> Burgwork: no?
<Keybuk> url?
<Burgwork> Keybuk, http://www.linux.com/article.pl?sid=06/06/12/1418228
<Keybuk> Burgwork: how curious ... they never bothered to contact me to say they'd written it :)
<Keybuk> anyhoo, other things to do
<crimsun> ...more initNG crack?
#ubuntu-devel 2006-06-20
<sbalneav> neuralis: ping
<neuralis> sbalneav: hey
<sbalneav> Hey!  Quick question.  I'm not sure how to create a spec in launchpad
<sbalneav> Any ->'s?
<sbalneav> Or do I not have privs to do so?
<neuralis> sbalneav: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-June/000145.html
<sbalneav> Ah, thx.  
<neuralis> sure
<rodarvus> sbalneav, I'll be online (and at the meeting room) for another 10 minutes, please ping me if you need anything
<zul> heylo
<Hobbsee> morning all
<zul> evening
<Hobbsee> RadiantFire: ping
<RadiantFire> Hobbsee: pong
<Hobbsee> RadiantFire: i just tried building ndiswrapper again - it's building both files...
<RadiantFire> it is?
<Hobbsee> yeah
<RadiantFire> i don't know anything about debian packaging so..
<Hobbsee> i'll check by installing it though (argh)
<Hobbsee> how did you build it?
<RadiantFire> I'll gladly be your guinea pig though
<RadiantFire> I used module-assistant which failed
<Hobbsee> yeah, it installed okay..
<RadiantFire> to get it built I just unzipped and did make, make install inside of /usr/src/module/ndiswrapper
<Hobbsee> bleh, no wonder it didnt work
<RadiantFire> ?
<Hobbsee> RadiantFire: the way to do it is to get the source package (*.orig.tar.gz, *.dsc, *.diff.gz), dpkg-source -x *.dsc, and debuild
<RadiantFire> it is?
<imbrandon> heh
<imbrandon> yup
<RadiantFire> I thought you were supposed to use module-assistant
<RadiantFire> gah...
<Hobbsee> nope, it should "just work"
<RadiantFire> wait... the sudo dpkg -i put ndiswrapper-source.tar.bz2 in my /usr/src
<Hobbsee> it did?
<RadiantFire> yes
<Hobbsee> it doesnt here.....interesting.
<RadiantFire> and in order to install, I unpacked that directory and compiled
<RadiantFire> I assumed module-assistant took care of everything
<Hobbsee> hey yeah, so it did.
<RadiantFire> when module-assistant failed, I"m left with a deb lik linux-ndiswrapper-module-2.6.15-25.deb
<RadiantFire> in /usr/src
<Hobbsee> technically you shouldnt even need to do that - it should just build both packages when you run debuild from the source directory
<RadiantFire> the source directory being where ndiswrapper-source unpacks to?
<Hobbsee> i think the /usr/src stuff gets autohandled, let me check..
<Hobbsee> no, the source directory being where you downloaded the source off revu to, and ran dpkg-source -x *.dsc <-- the directory created from there
<RadiantFire> huh?
<RadiantFire> oh crap, I never downloaded the source of revu, I just downloaded ndiswrapper-source*.deb that you gave me
<Hobbsee> hmmm...interesting, i thought i sent you the source
<RadiantFire> all I have is ndiswrapper-source.deb and ndiswrapper-utils.deb
<RadiantFire> p.s. the source file is 1.17-0ubuntu1_all.deb
<Hobbsee> yeah
<Hobbsee> if i gave you the deb files, then you *should* just be able to install it by sudo apt-get build-dep ndiswrapper-utils && sudo dpkg -i *.deb
<RadiantFire> oh
<Hobbsee> if not, and you have to do something weird and random, then something's wrong.
<Hobbsee> that .tar.bz2 file's copied into /usr/src via the rules file - so that's okay - it's not randomly copying
<RadiantFire> Hobbsee: when module-assitant fails, I'm left with this file that is not install
<RadiantFire> e
<RadiantFire> ndiswrapper-modules-2.6.15-23-386_1.17-0ubuntu1+2.6.15-23.39_i386.deb
<RadiantFire> cuz this is using a 386 kernel
<RadiantFire> haven't gotten around to updating this computer to 686
* Hobbsee still doesnt understand why you're manually calling modprobe at all....
<RadiantFire> because it never installed a new module
<Hobbsee> i wasnt aware that you had to...
<RadiantFire> the problem I was having was with the kernel module on the other computer
<RadiantFire> the ndiswrapper module won't load if it isn't compiled for the running kernel exactly
<RadiantFire> so I had to compile it mysle
<RadiantFire> f
<Hobbsee> actually, it installs a new module as ndiswrapper-source installs, according to this
* Hobbsee swaps to wired, and tests it out.
<RadiantFire> Hobbsee: thast wier
<imbrandon> yea but installing isnt loading
<RadiantFire> Hobbsee: seriously the problem is your ndiswrapper-source builds a module that says it depends on utils 1.17.1
<Hobbsee> pity my wifi card doesnt actually work with the newest version - it'll flash, but wont get a connection
<RadiantFire> when it should really depend on 1.17.-0ubuntu1
<Hobbsee> it should really depend on 1.17*, but i'll check that
<Hobbsee> oh wait, debian's updated it anyway, they'll fix it via a sync
<RadiantFire> thats exciting...
<RadiantFire> Hobbsee: I'm curious, how much does ubuntu actually rely on debian
<RadiantFire> cuz I got the impression its just taking the tools and rerolling everything
<Hobbsee> RadiantFire: a lot
<RadiantFire> so there is more help required than Ithought
<RadiantFire> so is there something new for me to test?
<RadiantFire> Hobbsee: ping
<Hobbsee> RadiantFire: pong
<Hobbsee> darn multiple pbuilders, they confuse me.
<Hobbsee> not at the moment, that i know of
<RadiantFire> Hobbsee: you said you are in University right?
<Hobbsee> RadiantFire: yes
<RadiantFire> undergrad or grad?
<Hobbsee> undergrad
<RadiantFire> where at?
<Hobbsee> a uni in sydney - macquarie uni
<RadiantFire> majoring in compsci or something else
* desrt likes symmetry of two people talking to each other
<desrt> 23:05 <RadiantFire> Hobbsee: ping
<desrt> 23:05 <Hobbsee> RadiantFire: pong
<RadiantFire> good call :-)
<Hobbsee> RadiantFire: no, doing a bachelor of technology in optoelectronics, actually
<imbrandon> [21:57]  <RadiantFire> Hobbsee: I'm curious, how much does ubuntu actually rely on debian <-- RadiantFire ubuntu takes a snapshot of debian unstable every 6 months and basis our release on that but as far as tool and such we are totaly indep, with things like our own pactches and bzr branches for 90% of the packages, but at the same time we send patches back to upstream if they are wanted
* Hobbsee continues to sift thru the email.  woo, more to discuss at the next meeting.
<RadiantFire> ok, so I wasn't completely off base
<desrt> that said -- ubuntu would be in a lot of trouble without debian
<desrt> since an ubuntu system isn't very much fun without universe and most of universe comes from debian
<HrdwrBoB> ubuntu wouldn't exist per se without debian
<stub> Launchpad will be going down in 15 mins for its regular code update. Downtime should be around 15 mins.
<fabbione> morning
<Hobbsee> morning fabbione!
<fabbione> hey Hobbsee 
<fabbione> you are up early...
<Hobbsee> @time sydney
<Ubugtu> Current time in Australia/Sydney: June 20 2006, 16:38:18
<Hobbsee> fabbione: i just had lunch :P
<Hobbsee> fabbione: where are you?  
<neuralis> hmm. no schedule up yet for today?
* Hobbsee is bad with accents
<fabbione> Hobbsee: oh you are on the other side of the world...
<fabbione> Hobbsee: EU
<fabbione> hey netstar 
<Hobbsee> fabbione: ah, i figured that much - where in particular?
<netstar> hi
<fabbione> Hobbsee: copenhagen/denmark
<Hobbsee> yes, i'm on this strange side, where it's winter, and where we all fall off the edge of the world occasionally
<Hobbsee> fabbione: ooh, i'm jealous.  would love to be there one day.
<fabbione> Hobbsee: i have been there :)
<Hobbsee> hehe
<Hobbsee> but you survived and made it back!
<ajmitch> morning fabbione 
<fabbione> Hobbsee: yeah :)
<fabbione> hey aj
<Hobbsee> hi ajmitch 
<ajmitch> hello again Hobbsee 
<Mithrandir> Hobbsee: does it feel like bungee jumping?
<Hobbsee> Mithrandir: quite possibly
<fabbione> Mithrandir: ahhah
<Hobbsee> morning Keybuk 
<neuralis> Mithrandir: only if you don't reach escape velocity ;)
<Hobbsee> haha
<Mithrandir> neuralis: true.
<Hobbsee> uh oh...that didnt sound good...
<fabbione> Hobbsee: ?
* Hobbsee goes off to investigate a large bang.
* fabbione dist upgrades
<\sh> hmmm...is this intltool-debian problem solved? can someone create a nice chroot?
<Hobbsee> back :)
<TheMuso> Morning all.
<Keybuk> \sh: it appears to have built
<\sh> Keybuk: cool...:) thx :)
<fabbione> hey marilize 
<marilize> hellooo fabbione :)
<sivang> morning
<\sh> hey sivang
<sivang> hey \sh 
<Hobbsee> evening sivang 
<sivang> hi Hobbsee !
<sivang> hey marilize 
<\sh> ln: creating hard link `/home/shermann/pbuilder/aptcache/edgy//adduser_3.80ubuntu2_all.deb' to `/var/cache/pbuilder/build//17822/var/cache/apt/archives/adduser_3.80ubuntu2_all.deb': Invalid cross-device link
<\sh> wth...
<ajmitch> \sh: yes, you broke the config :P
* Hobbsee blames ajmitch 
<marilize> sivang morning :)
<Hobbsee> for the broken config
<ajmitch> APTCACHEHARDLINK="yes"
<ajmitch> change it to no
<ajmitch> sigh, I always get picked on here
<Hobbsee> heh
<siretart> hi
<ajmitch> hi siretart 
<siretart> err, are you serious with UVF at July 13th? I think it is way too early
<siretart> hey ajmitch 
<Hobbsee> hi siretart 
<BenC> how do I test udev for why it isn't loading a NIC module with 2.6.17?
<BenC> isn't there someway to tickle the "plug" of the device and watch udev for what it does with it?
<fabbione> BenC: hit Keybuk with a huge bat? :)
<fabbione> he is there.. you can.. DO IT! :P
* BenC looks around for a decent sized bat
<BenC> actually swinging a bat around at a conference might be bad given some recent other conferences ;)
<ajmitch> heh
<Keybuk> BenC: sudo udevmonitor -e
<Keybuk> echo add > /sys/bus/pci/devices/???/uevent
<ajmitch> as long as you don't have a crown..
<mdke> jdub: is my blog still getting a 404 from planet?
<BenC> lol
<Keybuk> BenC: usually that's a missing alias in the modinfo
<BenC> loading the module by hand works, so the table entry should be there
<Keybuk> nopaste the modinfo for me
<Keybuk> actually, why don't I come and lean over your shoulder
<Keybuk> that would be MUCH more efficient
<Hobbsee> haha
* Hobbsee was wondering when that would happen
<BenC> ok, bat is for me this time
<BenC> Keybuk lucked out
* Hobbsee hands BenC the bat
<jsgotangco> BenC: you doing anything right now? we need a kernel person for speakup inclusion
<TheMuso> jsgotangco: Thats not until 11 now.
<TheMuso> Refresh the schedule.
<jsgotangco> TheMuso: there's a 9-10 sched
<TheMuso> Twas removed.
<jsgotangco> ooopps yeah sorry
<TheMuso> or pushed back. I can't exactly remember.
<BenC> jsgotangco: which table?
<TheMuso> BenC: It will be whatever table henrik is on, as he is subscribed to the spec and he can't exactly move around as easily as the rest of us.
<BenC> is discussion going on right now?
<jsgotangco> no till 11
<jsgotangco> err i mean we're starting at 11 the sched got moved
<msw> BenC: not yet
<BenC> ok, just noticed that the schedule needed to be reloaded
<BenC> I had the old one showing it at 9am :)
<looksaus> is there a real time, non-intrusive way I can contact Marilize Coetzee, the Ubuntu distribution manager?
<looksaus> irc, for example?
<sivang> marilize: ^^
<looksaus> sivang, thx
<TheMuso> c
<TheMuso> damn ssh
<marilize> looksaus: hi, you want to speak to me?
<TheMuso> Morning LaserJock.
<LaserJock> hi TheMuso 
<jdub> LET'S GO TO THE AIRPORT!
<LaserJock> wahooo!
<Hobbsee> er...okay then
<sivang> jdub: what will we be doing there? :-)
<LaserJock> jdub: OK, OK
<Hobbsee> hi jdub! would have thought you'd recognise my accent, even if no one elses :P
<sivang> jdub: I can watch planes takeoff and land here as well
<Hobbsee> sivang: drinking beer, of course, what else?
<sivang> hmm
<rodarvus> jdub, clever idea ;)
<jsgotangco> we can try practising for our departure later
<TheMuso> hehe
<LaserJock> jdub: maybe we shouldn't let mako talk to the driver next time?
<TheMuso> When do you fly out sivang?
<jsgotangco> haha
<TheMuso> sorry sjoerd.
<TheMuso> damn
<TheMuso> I meant jsgotangco 
<jsgotangco> TheMuso: saturday
<TheMuso> Ah ok.
<ajmitch> Hobbsee: how he could mistake the distinctive sydney accent is beyond me :)
<Hobbsee> ajmitch: haha yeah - it's only where he lives, for goodness sake :P
<jdub> LaserJock: "OK!"
<Hobbsee> actually, it may well be a combined sydney/adelaide accent
<ajmitch> scary
<jdub> Hobbsee: you're not based in sydney though, right?
<Hobbsee> jdub: i'm in sydney, yeah
<jdub> !!!
<jdub> you are in so much trouble
<Hobbsee> haha!!!!
<Hobbsee> why so?
<jdub> have you been to slug?
<TheMuso> For not coming to SLUG.
<Hobbsee> jdub: nope.
<Hobbsee> where is it?
<TheMuso> UTS
<jdub> UTS, last friday of the month
<Hobbsee> which campus?
<jdub> central
<TheMuso> Broadway
<Hobbsee> kurringai or broadway
<TheMuso> Check the slug website for details.
<Hobbsee> ahh...
<ajmitch> what a shame, I'll be in canberra on the last friday in june
* Hobbsee really doesnt want to drive that far :P
<jdub> Hobbsee: pia has a women's dinner beforehand too, started last month with about 15 - you should go this month
* Hobbsee would get lost.
<jdub> where abouts are you?
<Hobbsee> around pennant hill
<Hobbsee> s
<jdub> ha ha
<jdub> "sydney"
<Hobbsee> well...
<Hobbsee> most people dont know where anything closer than that is :P
<Hobbsee> hey JaneW 
<jdub> (i live in surry hills, so i'm just being an arse)
<Hobbsee> :P
<ajmitch> jdub: returning to sydney after UDS?
<jdub> guadec
<jdub> then home
<ajmitch> right
<jdub> Hobbsee: lca is going to be in sydney in january too
<ctd> Hobbsee: some do :)
<Hobbsee> jdub: yes, so i hear :)
<ajmitch> I'll be in sydney in the 1st week of july or so
<Hobbsee> anyway, cant do last friday this month - we're doing a recording
<jdub> hrm, reminds me, i have some postcards to hand out
<Hobbsee> ctd: yes, some
<Keybuk> jdub: can you hand out some air tickets too?
<Hobbsee> haha
<TheMuso> Hobbsee: Excuses excuses.
<jdub> Keybuk: yeah dude, i will procure them from my soft fleshy behind
<TheMuso> ahaha
<Keybuk> jdub: thanks
<Keybuk> "Thankyou for flying Sladen Air"
<jdub> haha
<Keybuk> "In a short moment, the crew will be coming through the cabin with fresh straw to sit on"
* ajmitch checks the dates for lca
<jdub> Hobbsee: slug.org.au -> mailing lists
<Keybuk> jdub: annoyingly LCA is at almost exactly the same week as the most expensive air fares
<jdub> Keybuk: lucky - you don't have to fly that week, you just have to be there!
<TheMuso> I think it is expensive to fly to/from Australia no matter what time of year.
<Keybuk> jdub: that involves flying there
<Keybuk> thus expense
<jdub> TheMuso: only to; it is cheap to fly out
<ajmitch> TheMuso: not too bad from NZ at times
<jdub> because we are worldly
<Keybuk> strange
<Keybuk> once it was easy to get passage there
<Keybuk> just not back
<jsgotangco> jdub radio heh
<sladen> jdub: can you have LCA not in January, it's summertime in Oz... and all the northern want to go there on "holiday"
<jdub> Keybuk: let's steal some bread!
<Keybuk> jdub: we're in the wrong country
<jdub> sladen: that's the whole point!
<Keybuk> we'd get sent to Northern Africa
<msikma> Hey guys
<zyga> hey :)
<msikma> Is there anyone who can give me a little hand in making a new Launchpad spec? I'm member of the Ubuntu Artwork Launchpad team, but I can't seem to make any new ones.
<Hobbsee> hi msikma 
<msikma> Hello
<msikma> How's Paris?
<thom> keybuk joins the french foreign legion!
<zyga> msikma: what's the problem? what happens when you try to create a spec?
<msikma> The problem is I don't know which link to click. :)
<msikma> I can't seem to see any button that says "magically create new spec"
<zyga> msikma: first off, create the spec on the wiki
<zyga> you need that *before* you create it on lp
<zyga> msikma: just a sec
<jdub> msikma: french.
<msikma> I've got a link to a mailing list post which will suffice as "read more" link
* Keybuk wonders how you spell that hotplug notification thing
<Keybuk> "airmiss" is what I heard
<lifeless> hermes ?
<jdub> msikma: has to be a wiki page, otherwise we can't edit the spec
<msikma> Hermes, isn't that a greek god?
<jdub> it is also a pair of underpants
<msikma> Seems that more of the Ubuntu Art specs are just mailing list links, though. Should I put it in the Wiki first?
<jdub> yeah, much better to
<lifeless> it is hermes
<msikma> I'll be right back  (at work, gotta do something...)
<lifeless> http://ws314.juntadeandalucia.es/plugins/scmsvn/cgi-bin/viewcvs.cgi/*checkout*/Changelog?root=guadalinex2005
<Hobbsee> msikma: isnt there already a spec for that?  oh, never mind me.
<jsgotangco> that visual bluetooth notification thing is nice though
<fabbione> dholbach: hey dude
<lifeless> jsgotangco: thats hermes!
<msw> jsgotangco: gotta move fast to use it though. ;-)
<fabbione> dholbach: Settings -> Sound Settings -> "select push to talk"
<dholbach> fabbione: hey man
<fabbione> dholbach: and select a key you will use to talk
<dholbach> fabbione: I couldn't shout, because I'm in a talk about guadalinex :)
<jdub> "Bluetooth support enabled. CATCH ME IF YOU CAN!"
<dholbach> fabbione: ah ok - I'll try that
<fabbione> dholbach: something like l-win will do
<fabbione> dholbach: please thanks
<msw> jdub: hah
<jsgotangco> hermes heheh isn't that the messenger of the gods
<dholbach> :-)
<LaserJock> jdub: musically notification bubbles?
<LaserJock> *musical
<TheMuso> LaserJock: Thats a cool idea re musical bubbles
<ChipX86> I so don't want to implement that
<dholbach> brb
<lifeless> jsi think that is the point :)
<lifeless> meh
<zyga> is mark in france yet?
<highvoltage> zyga: yep
<Hobbsee> zyga: he was speaking there last night
<zyga> can someone tell him Polish ubuntu community sends regards? :)
<pitti> doko, infinity: are you fine with https://wiki.ubuntu.com/GccSsp ?
<msikma> zyga: I'm back... could you still help me with it? :)
<zyga> msikma: I checked launchpad and.. I cannot find it either :D
<zyga> ask carlos on #launchpad
<msikma> Actually, I think that I can do it without first going to the Ubuntu-art team
<msikma> There we go.
<pitti> G0SUB: ping
<sivang> Kinnison: I've worked out the design sectoin, https://wiki.ubuntu.com/PurgeOldKernels
<sivang> Kinnison: now working to have some direction in the implementation part
<highvoltage> hmmm... i can't unmute myself in teamspeak
<infinity> pitti: Looks fine to me, but doko may want to talk to you about it.  I spoke with him this morning.
<pitti> infinity: we already spoke, too
<infinity> Ahh, good.
<ajmitch> pitti: so you'll turn it on for edgy, not edgy+1?
<infinity> Tomorrow would be good.
<infinity> Or even today.
<pitti> ajmitch: 'edgy is broken by design' :)
<ajmitch> nice :)
<infinity> Since we have 12000 pending builds still.
<ajmitch> right, I thought the buildds had already chewed through a few by now
<pitti> infinity: depends on doko, AFAIR he wanted to do another gcc upload by tomorrow anyway
<ajmitch> btw, good morning pitti, infinity  
<pitti> ajmitch: so what, most of the main packages will be rebuilt at some point anyway
<pitti> ajmitch: hello :)
<doko> infinity, pitti: I do hesitate to change the defaults in gcc itself. Just checked the FC package, and they do not change it in this way. looking at gentoo now (FC uses some global flags to build packages)
<pitti> ajmitch: and for some crucial ones we can still do no-change uploads if necessary
<pitti> doko: so, gcc-defaults?
<ajmitch> yes, but you'd need to check them to ensure that they got rebuilt after a certain date
<infinity> doko: Wimp.
<pitti> doko: global flags sounds like the equivalent of gcc-defaults
<infinity> ajmitch: It's no harm done to NOT have some stuff rebuilt.  It doesn't put us in a position any worse than now.
<ajmitch> those that matter will get touched anyway
<doko> pitti: gcc-defaults is more evil, remember BenC's sparc wrapper ;-)
<infinity> Yeah, I'd rather avoid wrappers.
<infinity> We just killed the last one we were using.
<infinity> (And good riddance to it)
<infinity> I see no real argument for not enabling it in GCC itself.
<infinity> Yes, stuff will break.  But we all now how to fix it trivially (-fno-stack-protection), so who cares?
<infinity> I suppose there could be an argument made for people building 3rd party sources and not having a clue why they break...
* infinity waffles.
<ajmitch> they could run into that with us using gcc-4.1 anyway
<infinity> I dunno.  I expect nothing to work right on edgy anyway.
<ajmitch> given the amount of broken code out there
<ghee22> hello, i'm looking for help regarding reading & writing files.  is anyone available?
<hunger> ghee22: I am sorry, but this is not a help channel, please use #ubuntu for that.
<ghee22> hunger: oh, i'm sorry for not being more clear, i meant development wise
<ghee22> hunger:  i'm writing a project for SoC and I need to read & write files for the project.  I'd like to use something that is cross-platform for Kubuntu & Ubuntu.  can you help?
<infinity> ghee22: This is why you have an SoC mentor, no?
<ghee22> infinity: yes, that is one reason i have a mentor.  I like to "shop around".
<Keybuk> ghee22: curiously, "read" and "write" are the syscalls you need
<hunger> ghee22: I'd recommend getting a book on unix programming then.
<zyga> ghee22: read and write is quite portable ;] 
<hunger> ghee22: You will need it;-)
<ghee22> keybuk:  thanks... i think i'll come back here after reading a bit more.  
<zyga> ghee22: info libc
<ghee22> hope you guys enjoyed a laugh at my expense
<zyga> after installing libc-doc package
<ghee22> zyga: got it. that's directly helpful.
<hunger> ghee22: Why should we laugh?
<hunger> ghee22: I started with similar please for help:-)
<Chipzz> hunger: plees ;)
<Chipzz> nice play of words though ;)
<TheMuso> http://www.themuso.id.au/speakup-20060501.tar.bz2
<TheMuso> http://www.themuso.id.au/speakup-20060501.tar.bz2
<TheMuso> http://www.themuso.id.au/speakup-20060618.tar.bz2
<BenC_> got it, thanks
<BenC> which spec would appreciate my presence more, gcc-ssp or boot-message-logging?
<mdke> Znarl: you haven't got rid of me yet
<\sh> guys, is there a plan to change the time of the TB meeting this evening?
<tseng> \sh: no
<tseng> oh, i am thinking of distro team perhaps was pushed back until after paris
<\sh> so still at 20UTC...
* tseng gets the mail
<tseng> \sh: dunno, mdz only mentioned postponing dev team meeting
<fl4b> I though of something that doesnt appear to have been looked into before- spyware. Although its not a prob yet, there have been proof of concept tests that show it is not too hard to create. Rather than waiting for Ubuntu (or any distro) to become popular for average users, and then spyware makers developing crap for linux and being a few steps ahead of anti-spyware developers, why not 'pre-empt' this and do some work into what spyware people may do, and 
<fl4b> post and 1/2
<imbrandon> fl4b, sounds like it might be an idea, have you written a spec ?
<fl4b> spec?
<fl4b> im newbish
<imbrandon> ubuntu works with specifications , one sec let me get you the links
<slomo> BenC: ping? do you know if someone is working on updating libraw1394 in debian? otherwise i would update it for edgy in ubuntu as i already planned for dapper ;)
<BenC> slomo: I know I'm not, not sure if anyone else is
<slomo> BenC: ok, from looking at the RFA bug it doesn't look like it... i guess i'll just get it updated for edgy then if that's ok for you
<BenC> sure thing
<slomo> ok thanks
<highvoltage> dodgy internet--
<Keybuk> I blame elmo
<StevenK> Keybuk: For everything ... ?
<Keybuk> no, not for everything
<Hobbsee> hi all
* StevenK jumps on Hobbsee.
* _ion jumps on self
* Hobbsee is jumped on, and splats on the ground
<Hobbsee> hiya StevenK 
<Amaranth> hey
<StevenK> Hobbsee: Your fathers machine is feeling better?
<Hobbsee> StevenK: seems to be, until it breaks again
* StevenK tries to come up with a webpage design that doesn't suck and fails miserably.
<Hobbsee> hehe - is that possible?
<StevenK> I've used some webpages that don't suck.
<zul> what happened to all of the voip seesions?
<sladen> zul: proprietary binary that fills up your hard disk when you suspend
<sladen> zul: I think the functionality needs folding into gobby to make it 'on by default'
<zul> so no one is using it?
<Keybuk> zul: the network keeps going down here
<zul> ah ok
<Hobbsee> pity
<jono> hey
<highvoltage> hey jono and sbalneav 
<jono> hey highvoltage 
<mjg59> Why does nm keep saying "The NetworkManager applet could not find some required resources. It cannot continue"?
<Mithrandir> mjg59: because it's silly.  I think the problem goes away if you reboot.
<mjg59> Mithrandir: Nope
<mjg59> Unless it needs me to do a clean reboot
<mjg59> Oh. Because I need to delete all the icon caches.
<mjg59> Didn't we fix that?
<Mithrandir> mjg59: uh.  Go nm-applet
<mjg59> Hardly its fault
<mjg59> It asks gtk for icons, gtk didn't give it any
<mjg59> Possibly a package bug
<Mithrandir> it should give out a better error message, though
<jsgotangco> Laser_away: http://enterprise.kde.org/articles/kiosk-lp.php
<jono> wow, havent seen enterprise.kde.org for a while :)
<\sh> fabbione: ping
<\sh> fabbione: vlan configuration ubuntu-server...
<fabbione> pong?
<\sh> fabbione: installed by default for /etc/network/interfaces support?
<fabbione> -EPARSE
<\sh> fabbione: I need to setup vlan on an ubuntu-server...for debian I need those vlan tools...
<fabbione> yeah and you need the same on ubuntu
<\sh> fabbione: whishlist bug: please include vlan tools by default ;)
<fabbione> \sh: did you open it in malone?
<fabbione> \sh: did you assign it to infinity ?
<\sh> fabbione: I'll do :)
<bddebian> Heya folks
<\sh> fabbione: which package is the best to file this bug?
<bddebian> Heya \sh
<\sh> hey bddebian
<\sh> against vlan obviously
<fabbione> \sh: good question.. it's the seeds
<fabbione> no. it's a matter of seeds
<fabbione> are the tools in main actually?
<\sh> fabbione: yes
<fabbione> \sh: just assign it to infinity 
<\sh> fabbione: I used ubuntu-server ;)
<fabbione> ok
<\sh> and I can't tell launchpad anymore, that this is a wishlist bug..oh joy
<sladen> \sh: can you file a wishlist for that
<\sh> sladen: for what? I can't choose anymore what type of bug that is
<\sh> sladen: I can set the status, and importance I can't choose anything
<\sh> sladen: https://launchpad.net/distros/ubuntu/+source/vlan/+bug/50460
<Ubugtu> Malone bug 50460 in vlan "Please install this package by default" [Untriaged,Unconfirmed]  
<seb128> you need to be a member of ubuntu-bugs to set the importance of a bug now
<\sh> seb128: ug
<Keybuk> seb128: \o/
<Keybuk> though people should at least be able to set "wishlist" without being ubuntu-bugs
<Keybuk> though, I suppose, formally, a wishlist request is actually a support ticket
<seb128> Keybuk: people should be able to set an importance when filling the bug, not sure about changing when it's filed
<\sh> Keybuk: short question. TB meeting this evening will not be postponed?
<\sh> seb128: which is not possible in the actual UI of "Report a Bug" in LP
<Keybuk> \sh: no idea
<\sh> Keybuk: just asking, because you, mdz, mark, etc. are in Paris...and I think you have better things to do in paris these days ;)
<Keybuk> especially given the time of the meeting
<\sh> Keybuk: yes
<sladen> \sh: if you're motu, you should be in ubuntu-bugs, IIRC
<\sh> sladen: I removed myself from those teams a couple of months ago, because of a very special reason.
<sbalneav> ogra: ping, online
<ogra> sbalneav, pongie
<\sh> sladen: that's why my name is on tonights TB Agenda ;)
<ogra> sbalneav, sorry, i was held up on the corridor, but it seems there is no internet anyway at the comfy chairs
<sladen> \sh: given that you have been before, there are probably easier ways of getting that sorted
<sbalneav> yeah, we're in the room for a bit.  We can help draft there.  Do you want a gobby session?  or just keep reloading the wiki and the occasional comment from us?
<sladen> \sh: and that IIRC, the reason that you resigned was to ensure safety of the archive incase keys got compromised
<ogra> sbalneav, the latter should be fine for now
<\sh> sladen: I think TB is the right way to do..so everybody knows, and keybuck or mdz can enable my account again
<\sh> sladen: yes, that was the very special reason
<sbalneav> ogra: k
<ogra> sbalneav, i dont expect the spec to be done today, we'll have another session anyway and there is currently not much to write apart from "we're taking upstreams implementation"
<ogra> all the intresting stuff will happen tomorrow ;)
<sbalneav> ogra: save frequently so we can see updates :)
<ogra> heh, yes
<sladen> \sh: well in case it doesn't happen tonight, you should probably grab keybuk/mdz and get it reticked so that you can start doing useful work again
<Keybuk> sladen: interestingly, how do we know that his key _hasn't_ been compromised, and that this is really \sh and not somebody else? :p
<jsgotangco> good question
<ogra> Keybuk, was the key actually revoked on the keyserver ? 
<Keybuk> ogra: no
<ogra> so why wouldnt you trust it then :)
<Keybuk> I'm pointing out that the "resign for key safety" is null and void, because he never removed or revoked his key
<sladen> ogra: because it's actually Darl McBridge pretending to be '\sh' and trying to tell us that all is well and the key hasn't been compromised
<bddebian> Keybuk: Oh, \sh has definetly been compromised ;-P
<jsgotangco> sladen: Darl McBride perhaps?
<sladen> bddebian: plz.  Keep it to the bedroom
<bddebian> Doh
<ogra> Keybuk, right, thats sparse, but there is no reason not to trust the existing key 
<Keybuk> ogra: there's no reason to trust it either
<Keybuk> it's obviously the same key
<Keybuk> but is it the same \sh ?
<ogra> Keybuk, not more that trusting mine or yours, no :)
<Keybuk> Given he deactivated from the team for the safety of the archive because he believed his key could have been compromised, it's not unreasonable to assume that the key was not safe
<Keybuk> A prudent, or perhaps simply paranoid, keyring maintainer at this point would require proof that this was really \sh coming back -- and not someone who has compromised the key that \sh clearly believed was compromisable
<Keybuk> That proof could be simply somebody who we know that knows \sh verifying it is really him
<Keybuk> or the generation of a new key that is signed by a useful percentage of the same signatures as the original key
<Keybuk> depending how paranoid one is feeling, of course
<Keybuk> we could also take the airport checkin approach
<Keybuk> "Did you pack these bags yourself?"
<Keybuk> "...no..."
<Keybuk> "OH, WAIT, I MEAN YES!"
<bddebian> heh
* bddebian makes note to not get even MORE on Keybuk's bad side :-)
* Keybuk doesn't have a bad side to ge ton
<ogra> Keybuk, well, if you require it i can visit him and take a fingerprint next week :)
<sladen> ogra: I'm not sure a fingerprint will be enough.  I think keybuk wants the whole finger
<\sh> Keybuk: kenneth wimer, oliver grawert, raphink, riddell
<raphink> \sh:  yes?
<sladen> ogra: preferably take a little one so that \sh doesn't miss it too much ;-)
<Keybuk> sladen: it's got to be better than the food here!
<ogra> sladen, right, i can arrange that as well :)
<ogra> Keybuk, thats easy i guess
<\sh> raphink: you can declare that it was me :)
<Keybuk> ogra: indeed, if consensus suggests paranoia is required, it may be appropriate for you to visit him to check
<Keybuk> or even just call him
<ogra> well, thats something i can do right away
<Keybuk> I'm not saying paranoia is required, I'm just thinking about the implications of reactivating a maintainer
<Hobbsee> but then how do you know it's not some imposter who has a similar voice, depending on your level of paranoia.
<Keybuk> it's clearly something we have to have a policy for
<ogra> (unless he gave his mobile to the pretender :) )
<raphink> \sh: huh? what are you talking about?
<Keybuk> its also something we currently don't have a policy for
<ogra> yep
<Keybuk> and then, obviously, there are the standard questions such as "you went away, are you sure that this won't happen again" etc.
<Keybuk> anyway, all TB meeting stuff really
<bddebian> Is the TB meeting on today?
<simira> did anyone put Mithrandir somewhere?
<Hobbsee> simira: locked in the cellar - he was causing too many disruptions :P
<simira> Hobbsee: oh. Well. Couldn't you just give him his laptop so he could talk to me?
<Hobbsee> simira: no wifi from the cellar...
<Hobbsee> so not really much point, except so that he can code.
<simira> Hobbsee: that's what he's there for, isn't it?
<jdong|coreduo> is Edgy still on lockdown?
<Hobbsee> simira: true, but they dont usually get locked in cellars :P
* Hobbsee beds.
<ogra> Hobbsee, they dont call that cellar here, its apprently "-1"
<Kinnison> Spec reviews are happening now. If you want to participate as a reviewer, please come to Atlas4/1
<\sh> Keybuk: thinking about that I was close to not come back to any job/work/duty I had...because of living under a bridge
<Hobbsee> ogra: hah, right.  i was about to call it the attic, and then released that was the wrong way around :P
<ogra> in the ariport they even have -2 and -3 :)
<Hobbsee> yeah, i've seen a few -2's
* \sh needs a pause...cu later
<azeem> Seveas: ping
<Seveas> azeem, ?
<lifeless> Keybuk: ping
<lifeless> anyone know what room keybu is in ?
<Keybuk> lifeless: ?
<lifeless> Have something to show you ;)
<\sh> re
<\sh> brb
#ubuntu-devel 2006-06-21
<bioengine> Hey, what would be a good open source project for an electrical engineer to work on?
<Burgwork> bioengine, anything at all. What enthuses you
<Burgwork> ?
<bioengine> I need to get electrical engineering experience
<bioengine> because it is required of me as a student
<bioengine> Otherwise, I will be rejected from opportunities at school
<Burgwork> there are some good circuit creation/simulation apps
<bioengine> Open source?
<winkle> oregano for example
<bioengine> Where can I find that app at?
<winkle> http://oregano.gforge.lug.fi.uba.ar/
<bioengine> Are there other apps that are open source for EE's?
<bioengine> And would they have a development community?
<bioengine> Are there any other projects for EE's that are open source?
<zul> you might want to check google
<bioengine> code.google.com
<Burgwork> bioengine, http://gnomefiles.org/category.php?cat_id=6
<bioengine> Thanks
<Riddell> bioengine: ktechlab
<bioengine> What is ktechlab?
<bddebian> Howdy
* bddebian wonders how Paris is going..
<dem> anyone can tell me what's the status of of laptop-mode vs upstream in ubuntu? because i wanted to add support for controlling power usage of wireless cards
<Hobbsee> morning all
<bddebian> Hi Hobbsee
<Hobbsee> hi bddebian :)
<Hobbsee> jdub: wow, thanks
<Hobbsee> you found my email quick :P
<fabbione> morning
<Hobbsee> morning fabbione!
<fabbione> hi Hobbsee 
<bddebian> Heya fabbione
<fabbione> hi bddebian 
* fabbione is having insomnia again
<bddebian> You must be missing X too much? ;-P
<Hobbsee> hehe
<Hobbsee> fabbione: what's teh time there?  around 4.20am?
<fabbione> bddebian: die :)
<fabbione> Hobbsee: yeah 5:30
<Hobbsee> ouch
<bddebian> :'-(
<Hobbsee> bddebian: surely you want to take it over yourself?  :P
<bddebian> Hobbsee: If I had a brain, I wouldn't mind trying
* Hobbsee taps bddebian on the head a few times
<Hobbsee> nope, no rocks in there, you must have a brain.
<bddebian> Well, it's very small :-)
<Hobbsee> i didnt hear much of an echo either :P
<ajmitch> morning fabbione :)
<fabbione> hi aj
<bddebian> Hobbsee: That was just all the fluid deadening the echo :-)
<Hobbsee> hah
<TheMuso> Morning all.
<jsgotangco> whiprush_: fix your blog heh
<TheMuso> c
<Keybuk> oops, NOMALS=-M doesn't work
<sivang> el: https://wiki.ubuntu.com/HomeUserBackup/UDSParis
<Keybuk> *sigh* no time for a nap bof today
<Hobbsee> Keybuk: find coke/
<Hobbsee> ?
<Keybuk> of the lines variety?
<Hobbsee> er, coke as in the thing that contains caffeine, and is in a red can.
<Keybuk> I suspect there may be issues with cutting up between BOFs
<ajmitch> now that would cause some interesting specs to be written
<Hobbsee> haha
<Hobbsee> hi jsgotangco 
<jsgotangco> good morning Hobbsee
* jdub snarfs breakfast from the restaurant, takes it back to the big room. muhaha.
<jsgotangco> doh
<jdub> (hard to have breakfast when your first bof is a sleep in bof)
<jsgotangco> jdub: would you like some raw beef with those?
<Hobbsee> jdub: haha.  yes, and feed him a new zealander accent too :P
* jdub has no idea where he got that from
<ajmitch> Hobbsee should be honoured
<jdub> there must be a kde hacker in nz i confused you with
<Hobbsee> haha
<Hobbsee> jdub: i don tknow of any.  but how did you know i was involved with kde?
<jdub> ajmitch: instead, she's offended 
<ajmitch> jdub: I can't understand why
<jdub> Hobbsee: you're a kubuntu dude
* jdub knows all
<Hobbsee> oh dear.  i wonder just how much you know about me.
<jdub> my nickname in canonical is echelon
<jdub> well, i know that you live on the outskirts of civilisation, but only 'cos you told me
<Hobbsee> true, ues
<Hobbsee> *yes
<Hobbsee> now hey, i dont live in kenthurst or penrith - and those are more the outskirts :P
<ajmitch> at least you don't live in sunny dunedin
<Hobbsee> yes, at an average of -25C
<Hobbsee> oh, and not really offended - just amused.  i really dont have anything against NZ'ers
<fabbione> guys i am looking for a volunteer to maintain a simple package that's already done
<ajmitch> what is it?
<fabbione> and just need some small cleanup love
<fabbione> ajmitch: openais
<fabbione> i have the package done...
<fabbione> and i can sponsor it to main
<fabbione> but i don't want to maintain it
<fabbione> (it's not in the archive yet)
<raphink> what does it do?
<jsgotangco> interesting
<fabbione> it's a cluster messagging infrastructure/framewoek
<fabbione> framework even
<raphink> interesting
<jsgotangco> clusters
<jsgotangco> http://developer.osdl.org/dev/openais/
<fabbione> yeps
<fabbione> that one
<fabbione> anybody interested?
<ajmitch> vaguely so :)
<fabbione> of course who takes the maintainance will also test it
<fabbione> it will be part of my automatic redhat cluster suite testing
<jsgotangco> ajmitch: cluster your laptops
<fabbione> since the new GFS2 relies on openais
<ajmitch> I'm interested, but not sure if I'd use it much
<fabbione> jsgotangco: i do that to test ppc :)
<ajmitch> jsgotangco: sure.. :)
<jsgotangco> heh
<ajmitch> morning mdz 
<raphink> hi mdz
<raphink> hi slomo
<sivang> glatzor_mobile: ping
<slomo> hi raphink 
<raphink> :)
<raphink> work activity: say hi to everybody on IRC
<glatzor_mobile> pong sivang
<raphink> I'l put that in my work report tonight
<marilize> cvd: ping
<fabbione> marilize: wrong chan :)
<marilize> fabbione: heh, thanks, (morning)
<fabbione> :)
<mdz> morning
<fabbione> hey mdz
<fabbione> so nobody wants to offer volunteer???
<jdub> fabbione: for..?
<fabbione> jdub: you win!
<fabbione> jdub: i was just looking for an openais maintainer
<fabbione> jdub: and you won!
<jsgotangco_> lol
<fabbione> impressive, isn't it?
<ajmitch> or just get a group of people who might care enough - as long as at lesat of them does work it's fine :)
<jdub> I AM TEH WINNAR!
* ajmitch hands jdub his prize pony
<Mithrandir> PONY?  I WANT A PONY TOO!
<ajmitch> http://fridge.ubuntu.com/files/no-pony-for-you.jpg
<Mithrandir> I'll have a balcony soon.  Then I can get a pony if I want to.  *sniff*
<Hobbsee> haha
<dholbach> http://developer.osdl.org/dev/openais/ is more likely to be the prize pony
<Hobbsee> no Mithrandir, you cant have a pony.
<fabbione> ajmitch: it's not worth a group of people.. it's not even 400KB of source
<Mithrandir> Hobbsee: I might  not have one, but I can get one if I want to. :-P
<jdub> "The project implements cutting edge research on virtual synchrony to provide 100% correct operation in the face of failures or partitionable networks with excellent performance characteristics."
<jdub> pfft
<Hobbsee> Mithrandir: no you cant. you're not allowed.
<jdub> I WANT MY VIRTUAL SYNCHRONY!
<jdub> Mithrandir: (PONY) <- not yours.
<Mithrandir> Hobbsee: I'm sorry, but the person who'd be able to deny me that would be simira, not you.
<Mithrandir> ;-)
<Hobbsee> Mithrandir: hehe, i spoke to simira last night :P
<Mithrandir> about ponies?
<jdub> and she said
<jdub> NO PONY!
<jdub> COME BACK ONE YEAR
<Hobbsee> no, i said you were locked in the basement, and that she couldnt speak to you, as there was no wifi down there.
<Mithrandir> we have a basement here?
<jsgotangco_> the restaurant has a basement restroom
<Hobbsee> Mithrandir: of course
* Mithrandir looks at Hobbsee, confused.
<Hobbsee> Mithrandir: how on earth would i know?  i've not even been in the continent, let alone inside the building!
<jdub> not even incontinent?
* fabbione takes away the pipe from jdong 
<fabbione> meh
<Mithrandir> Hobbsee: it's a quite nice continent.
* fabbione takes away the pipe from jdub 
<\sh> jdub: tststs...;)
<Mithrandir> Hobbsee: you should come visit one time.
<Hobbsee> Mithrandir: i'm sure it is, but i no longer have a passport.
<\sh> Hobbsee: but don't come near jdub...he bites
<Mithrandir> Hobbsee: I'm sure you're able to get a new one.
<\sh> ;)
* Hobbsee would like to.  at some point.
<Hobbsee> \sh: something tells me i dont have much choice there.
<Mithrandir> Hobbsee: it's a bit like saying you don't have a boarding pass and therefore can't go.
<Hobbsee> Mithrandir: true, but it makes sense to wait till i'm over 18..
<Mithrandir> Hobbsee: well, true.
<Mithrandir> but that's not very far away, is it?
<Hobbsee> no
* \sh has a wish: One picture where Jdub looks really serious, and I mean really serious
<Hobbsee> one month and one day - what should i do?
<Hobbsee> haha
<Mithrandir> \sh: I have one.  In my camera.
<Hobbsee> Mithrandir: was he asleep at the time?
<Mithrandir> Hobbsee: no, he was talking to somebody and didn't see me
<Hobbsee> ah, i see
* jdub recalibrates the orbital laser platform.
<Mithrandir> jdub: I'm in the same building as you.  Applying the golp is not a good idea.
<TheMuso> Hobbsee: You sound older than you are. :)
<Hobbsee> TheMuso: thanks.
<TheMuso> np :)
<Mithrandir> Hobbsee: if he says that in ten years, you can twap him. :-)
<Hobbsee> Mithrandir: hehe
<TheMuso> lol
<TheMuso> I thought Hobbsee was in her early twenties at least.
<Hobbsee> hehe
<Hobbsee> TheMuso: you thought i was human, too
<TheMuso> i see no reason why I should think otherwise.
<ajmitch> and then there are those who think she's from NZ..
<Mithrandir> Hobbsee: no, we're just amazed at the author writing such a good IRC bot.
<Hobbsee> hehe
* Hobbsee is a green bug eyed alien.
<TheMuso> \/me will wait to see that for himself at the first SLUG meeting that Hobbsee attends. :)
<Hobbsee> hah
* Hobbsee might just not ever attend :P
<Mithrandir> Hobbsee: I hear you claim that, but I haven't seen anything to prove that.
<Hobbsee> Mithrandir: thought i showed you a picture :P
<Mithrandir> that didn't have any context.  Like, your IRC session with this channel open.
<ajmitch> she just has to come along to the next conf
<Hobbsee> oh, as in, you wanted a pic of me next to my computer?
<sivang> Everybody, there's a BoF going on now about an automatic free space making proggy, anybody interested is welcome to join.
<spungles> thom: ping?
<ajmitch> sivang: you're straying horribly off-topic here :)
<Hobbsee> hehe
<Mithrandir> Hobbsee: nah, I've decided you're just a brilliantly written IRC bot and am happy with my knowledge. :-P
<Hobbsee> yes, while the high and mighty devs are away, the not so high and mighty devs will play :P
<Hobbsee> Mithrandir: haha okay
<sivang> ajmitch: hmm, is there a proper channel to announce something like to people ? :-)
<Hobbsee> sivang: yeah.  not this one.
<thom> spungles: ack
<spungles> thom: learnt dutch yet?
<simira> Hobbsee: are you a dev?
<Hobbsee> ajmitch: answer simira's question :P
<simira> Hobbsee: are you a dictator?
<ajmitch> simira: yes
<Hobbsee> simira: well, my name is sarah, and i'm told that means i'm supposed to boss everyone around.
<simira> Hobbsee: I must admit I thought you were a boy *blush*
<Hobbsee> haha
<simira> there are not many girls in here... me Claire, Jane and Silbs, I think
<Hobbsee> simira: yes, that's a fairly logical assumption to make
<Hobbsee> yeah wow :P
<simira> Hobbsee: and just as you know, I am deadly jealus of you all for being in CDG. There'l probably be a not-so-mysterious massacre next time I join in
<Riddell> ogra: ok for kubuntu hwdb at 15:00?
<simira> just *so* you know
<Hobbsee> simira: CDG?
<Riddell> Hobbsee isn't here (sadly)
<Hobbsee> Riddell: BOO!
<simira> Charles De Gaulle, Hobbsee 
<Hobbsee> simira: i'm here in australia...
<apokryphos> wrong train?
<ogra> Riddell, i only have a free slot between 16:00 and 17:00
<Hobbsee> Riddell: where's here?  going to be running via TS?
<simira> Hobbsee: you, you're just irc-invading the conf? You seem like you're there, you know... :p
<Hobbsee> simira: hehe, yes, i'm here on irc - i have no passport, and no plane ticket.
<simira> Hobbsee: *all* of them are in Paris now for the distro summit. Except for me *cries*
* Hobbsee hugs simira 
<ajmitch> simira: not all, sadly
* Mithrandir hugs simira too
<Hobbsee> not all of them are...
<fabbione> simira: no no.. i am home too
<simira> ajmitch: no, I am the one not being there... ;)
<simira> fabbione: are you why? Is Ulla down soon?
* ajmitch is at home in NZ
<ogra> pitti, ?
<fabbione> simira: yeah.. too close to Ulla's delivery :)
<pitti> ogra: EBUSY
<ogra> pitti, we need to talk if you have 2-5min later
<Mithrandir> ajmitch: can we do a status meeting for networkauth today?
<simira> fabbione: tell her hi from me and good luck!
<ajmitch> Mithrandir: when?
<fabbione> simira: will do :)
<Mithrandir> ajmitch: http://people.ubuntu.com/~mdz/schedule/2006-06-21/tfheen is my schedule, so now'd work
<ajmitch> lucky you, busy for the rest of the day
<ajmitch> I guess now will be ok - I'll get dinner later :)
<Hobbsee> haha - around midnight ajmitch?
<ajmitch> Hobbsee: hm?
<simira> hm. Remember we have a date, Mithrandir 
<ajmitch> I would never leave it that late..
<Hobbsee> ajmitch: the time for dinner
<Mithrandir> simira: always, my love.
<Hobbsee> simira: when you do get to be here, and i'm there at the same time, tell me, and we'll take over the world, okay?
* Hobbsee pictures a fully pink distrobution or something crazy :P
<Mithrandir> Hobbsee: http://www.linuxrising.org/screenshots/bella.png
<Mithrandir> (warning: pink overload)
<Hobbsee> oooohh...OUCH!
<Hobbsee> that is beyond scary!
<apokryphos> ouch; the xmms in there was the finisher
* TheMuso imagines a distribution where the whole GUI was rendered tactally on a refreshable braille display.
<Hobbsee> Mithrandir: urgh....man tha'ts terrible!
<Mithrandir> Hobbsee: I'm sure the ubuntu-women would be delighted to have such a theme. :-/
<fabbione> Mithrandir: i want that theme!
<Hobbsee> Mithrandir: hah
<Hobbsee> Mithrandir: you should send that to ubuntu art mailing list, and say "sabdfl says that all artwork should become like this" just as a joke :P
<Mithrandir> Hobbsee: it's not April 1st. :-P
* Hobbsee cant really imagine the responses, but thinks it could be amusing.
<Hobbsee> Mithrandir: a delayed one :P
<fabbione> http://www.linuxrising.org/screenshots/jeffsmilling.png
<Mithrandir> Hobbsee: I'd obviously fake it decently.
<fabbione> OMG :)
<fabbione> jdub: ^^
<Hobbsee> haha
<simira> :)
<jdub> pfft
* fabbione -> food
<\sh>  /dev/sdb1             6.3T   54G  6.3T   1% /data - go ubuntu mirror go
<mdeboer> hi. with hoary, i run into many difficulties trying to use a more recent (dapper) kernel. will this be the same with dapper? i believe the kernel has settled down quite a bit since hoary, so maybe running the 2.6.17 edgy kernel on dapper is feasible?
<jdub> more feasible
<jdub> there were userland changes in dapper to use the kernel effectively, so it's much less likely to work on older distros
<mdeboer> yes, i am aware of this. so, there are no such dapper userland/edgy userland incompatibilities?
<fabbione> mdeboer: not yet.. too early to say
<jdub> no one has added any so far ;)
<mdeboer> ok :-)
<mdeboer> ok. i'll give it a try soon
<ajmitch> maybe some fun with udev
<highvoltage> 12:08 <@Vhata> weiers: do you run gnome or KDE?
<highvoltage> 12:08 < weiers> I run gnome Vhata
<highvoltage> 12:10 <@Vhata> do you run any other KDE apps apart from amarok?
<highvoltage> 12:10 <@highvoltage> Spinach: hola!
<highvoltage> 12:10 <@Vhata> what happened after you did those 'killall -9' commands?
<highvoltage> 12:10 < Spinach> howdy, highvoltage!
<highvoltage> 12:10 < weiers> Ok, it would seem that between killall -3 and killall -9 something worked, because I was able to
<mdeboer> my main interest is to apply the latest rt-preempt patch http://people.redhat.com/mingo/realtime-preempt/
<highvoltage>                 launch the programme and got it to work.
<highvoltage> 12:11 < weiers> Vhata, I don't think that I am consciously running any other kde apps.
<highvoltage> 12:12 <@Vhata> did you run it from a terminal this time?
<seb128> flooood
<highvoltage> 12:12 < weiers> yes
<highvoltage> 12:13 <@Vhata> go to the "settings" menu, and then to "Configure global shortcuts", and find the "Toggle Playlist
<highvoltage>                Window" option, and set a shortcut there (I use windows+P), so that you can bring the window up
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
<jsgotangco> err???
<highvoltage>                whenever you want
<highvoltage> ugh, sorry about that
* mode/#ubuntu-devel [+b *!n=jonathan@ubuntu/member/highvoltage]  by fabbione
* highvoltage was kicked off #ubuntu-devel by fabbione (fabbione)
<neuralis> highvoltage: dude, STOP FLOODING
<jsgotangco> highvoltage: bless you
<jsgotangco> he's all red now haha
<Hobbsee> haha
<jdub> GLOWING JONATHAN CARTER
* mode/#ubuntu-devel [-b *!n=jonathan@ubuntu/member/highvoltage]  by fabbione
<jdub> REPORT TO THE SICK BAY IMMEDIATELY
<rodarvus> haha
<Hobbsee> hehe
<jdub> dude
<jdub> holy shit
<jdub> turn that thing off
<LaserJock> lol, highvoltage is soooo red
<rodarvus> <highvoltage> err, hi
<highvoltage> sorry!! wrote with my notepad on notwbook. and copied and pasted accidentally (extremely embarrased here)
* jdub meant the bright light in the middle of atlas
<Hobbsee> highvoltage: your client doesnt have a "stop accidental paste" feature?
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<highvoltage> Hobbsee: it's supposed to, normally it asks press ctrl+c to cancel or ctrl+k to let it through, i don't know what went wrong here, i'm just going to back away from my laptop for a while :)
<Hobbsee> highvoltage: ah okay.  hehe, yes before it bites
<LaserJock> highvoltage: maybe your laptop has caught a bug from the French power ;-)
<Hobbsee> haha
<simira> hm
<simira> where's mvo?
<thom> LaserJock: nah, then it wouldn't do /anything/
* thom ducks
<LaserJock> thom: good point
<ogra> mdke, around ? 
<zul> hey
<ajmitch> hi zul :)
<zul> hey ajmitch 
<Hobbsee> hi zul and ajmitch 
<zul> hey Hobbsee 
<ajmitch> hello Hobbsee 
<Hobbsee> where are the logs for why my system froze held?
<Hobbsee> i thought it was /var/log/messages, but there's nothign too obvious there
<zul> kern.log maybe.
<thom> kern.log, old dmesg, syslog are all possibilities
<Hobbsee> ok
<Mithrandir> can somebody get mdz onto irc, please?
<seb128> Mithrandir: he has no computer in front of him atm
<seb128> Mithrandir: should I forward him a message?
<Mithrandir> seb128: I was wondering why my optimized live cd for faster boot was put back to drafting rather than approved and if I can just change the time estimate a bit and set it directly to approved.
<Hobbsee> jdub: heya.  you dont have to use TS - if you were wanting to run the discussion offline, that's cool, i was just going to listen
<jdub> Hobbsee: only have two of us with mics
<jdub> Hobbsee: i've asked mvo to use his now
<jdub> (just there was no one in the channel earlier, so we didn't bother)
<Hobbsee> jdub: yeah, that's cool.  i just saw it, and saw it looked interesting, and was going to listen in, if it didnt cause trouble
<Keybuk> can anybody see jbailey from where they are?
<netgrabber> I think i solved bug #38335 maybe someone can review my "work"?
<Ubugtu> Malone bug 38335 in ipodder "UVF exception - iPodder no longer supported" [Unknown,Unconfirmed]  http://launchpad.net/bugs/38335
<Hobbsee> jdub: wow, it's working nicely :)
<seb128> Mithrandir: network issue, I was saying that mdz has no computer in front of him atm ... any message to forward?
<Mithrandir> seb128: 14:27 < Mithrandir> seb128: I was wondering why my optimized live cd for faster boot was put back to drafting rather than approved and if I can just change the time estimate a bit and set it directly to approved.
<seb128> Mithrandir: ok, no hurry for that probably, can wait after the BOF right?
<Mithrandir> seb128: sure.
<seb128> ok
<netgrabber> I have DEBIAN/md5sums in my .diff is this ok?
<netgrabber> I don't think so
<Mithrandir> netgrabber: no, it's not ok
<netgrabber> how can I fix this?
<Mithrandir> you've probably forgotten to run dh_clean
* _ion recommends cdbs
<tseng> er?
<netgrabber> I used debuild
<Hobbsee> jdub: how much longer will the smart BOF go for?
<ozamosi> I need to get in touch with smurf asap, but he's been away for 48 hours, and he's not answering mail. Can anyone tell me how to reach him?
<jdub> Hobbsee: kinda finishing time
<Hobbsee> jdub: yeah, just heard - mornfall forgot about it
<mjg59> jdub: Pong?
<mjg59> If it was about the pants, aes has been working all week so far
<mjg59> Should be able to get them this evening or tomorrow
<netgrabber> Can I upload packages created by myself on launchpad?
<dholbach> netgrabber: you might want to have a look at http://wiki.ubuntu.com/REVU
<dholbach> netgrabber: if you're not in the ubuntu-dev or ubuntu-core-dev team, your uploads to the buildd will be rejected
<netgrabber> dholbach: my situation is a bit complicated
<netgrabber> ipodder is no longer supported by upstream. it is now called castpodder, I did the migration
<netgrabber> it is bug #38335
<Ubugtu> Malone bug 38335 in ipodder "UVF exception - iPodder no longer supported" [Unknown,Unconfirmed]  http://launchpad.net/bugs/38335
<dholbach> netgrabber: I doubt we're going to introduce a package which conflicts the old one in a stable release
<dholbach> netgrabber: in edgy i'm sure this will be remedied
<netgrabber> I allready did the work...
<netgrabber> maybe my patch is usefull?
<dholbach> assign it to 'motureviewers' for edgy
<dholbach> and we'll get it done
<dholbach> and thanks for your work
<seb128> Mithrandir: he said he don't remember what he wrote to the witheboard but you can't set it to approve no
<netgrabber> assign?
<seb128> Mithrandir: and he runned away quickly after than, maybe best to do your change and set it for review again
<Mithrandir> seb128: well, the change's not in the spec.. it'd be in the "how much time is allocated for this".
<kane__> Mithrandir: hi ... i wonder, do you remember the bug #48164 ?
<Ubugtu> Malone bug 48164 in xorg "Video corruption at installation of xserver-xorg" [Medium,Confirmed]  http://launchpad.net/bugs/48164
<Mithrandir> kane__: yes, why?
<kane__> Mithrandir: well, a couple of days ago, I appended splash to the kernel line in GRUB, and the usplash came up without any video corruption
<kane__> Mithrandir: any ideas what may be the problem ?
<Mithrandir> kane__: X probably corrupts the display if there's a framebuffer there already.
<Mithrandir> kane__: that usplah works doesn't really matter.
<kane__> Mithrandir: hmm ok
<netgrabber> dholbach: Successfully uploaded packages.
<dholbach> netgrabber: cool
<ajmitch> netgrabber: please upload source-only packages :)
<netgrabber> sorry
<ajmitch> use debuild -S -sa
<netgrabber> should I redo it?
<ajmitch> yes please
<netgrabber> Already uploaded to revu.tauware.de
<netgrabber> Doing nothing for castpodder_5.0_i386.changes
<LaserJock> use the _source.changes file with dput netgrabber 
<ajmitch> not that one
<netgrabber> ah ok
<netgrabber> done
<netgrabber> where are those files now?
<netgrabber> dholbach: can I point on launchpad to this files?
<mdke> dholbach: heya :) there is an ubuntu-docs package for dapper-updates waiting in our dapper branch, if you happen to have any time in the next few days
<mdz> jdub: ping?
<Riddell> anyone seen ogra?
<sladen> Riddell: sitting outside the downstairs toilets
<Riddell> sladen: could you ask him if he can join us for hwdb talk?
<sladen> Riddell: mmm, good excuse to go past the cake stand.  Where should I send him?
<Riddell> sladen: upstairs to olympe
<Riddell> sladen: progress?
<Hobbsee> Riddell: he's still busy at the cake stand, probably :P
<dholbach> Riddell: ogra is in another session still
<dholbach> Riddell: and sladen is still sitting there
<jdong|coreduo> why has xfsprogs been taken out of standard-*?
<jdong|coreduo> is Ubuntu dropping support for XFS??
<jdong|coreduo> and same for reiserfs
<_ion> pool/main/x/xfsprogs/xfsprogs_2.7.7-1_i386.deb
<_ion> Oh, i misread your question.
<jdong|coreduo> Edgy's ubuntu-meta upload today
<pitti> ivoks: hi!
<pitti> ivoks: thanks for trying the redhat cups stuff! looks quite nice indeed
<pitti> ivoks: today I also sat together with the Mandriva printing guy, he showed me printerdrake
<ivoks> and?
<seb128> is that package somewhere online?
<ivoks> redha tool is too much redhat
<ivoks> :)
<ivoks> it depends on druid for printer detection, so that part should be rewritten if we want that solution
<seb128> what is wrong with a druid?
<ivoks> so, I had an idea of writting our own code...
<ivoks> seb128: nothing
<seb128> we "just" have to writte code, good :
<seb128> :p
<pitti> ivoks: mandriva uses some perl-gtk stuff with a mandriva GUI library on top of foomatic
<pitti> ivoks: it's quite good, too, but it'll also require hacking, and moreover, severe UI cleanup
<ivoks> pitti: just like RH tool
<ivoks> so, dead end? :)
<pitti> ivoks: is the rh one really so evil?
* pitti sees his hopes destroyed
<ivoks> pitti: well, no..
<ivoks> pitti: it's python
<ajmitch> at least the rh one will be python, right? :)
<ajmitch> like most of their tools now
<pitti> heh
<ivoks> so, it should be easy to reimplement it :)
<ivoks> rh tool depends on few libs we don't have in ubuntu
<ajmitch> import those libs if needed
<ivoks> that's the easiest part
<ajmitch> shouldn't be a big challenge to package them - there's a few RH tools I'd like to see in ubuntu
<jdong|coreduo> don't most of the rh tools depend on the huge-ass "redhat python library of goodies"?
<ivoks> jdong|coreduo: it does
<ivoks> like this rhpl
* jdong|coreduo has hacked system-config-lvm for ubuntu :)
<jdong|coreduo> I was bored one day
<ivoks> i think that's lib for localisation
<jdong|coreduo> yeah, rhpl was one of them
<jdong|coreduo> do we just want to import those as-is?
<jdong|coreduo> I got a feeling Ubuntu has different mechanisms for the functionality...
<ivoks> bottom line, i'm not programer and I can't repackage it for ubuntu by my self
<ivoks> or, at least, not for edgy :)
<jdong|coreduo> :)
<ajmitch> ivoks: so get one of us to do it - I'd like 1 or 2 of those tools for selinux config
<pitti> ivoks: how could you do screenshots on dapper if you don't have the libs?
<ivoks> pitti: i compiled them :)
* pitti sees sabdfl jump on his throat when he uploads redhat-library-crack package
<ivoks> :)
<pitti> :)
<ivoks> printconf starts nicely
<ivoks> and it detects all config there were before
<ivoks> but it doesn't recognise printers
<ivoks> (it doesn't autodetect them)
<ivoks> since all the tools it uses for detection aren't in ubuntu
<ivoks> it would be better to rewrite that part
<Yagisan> pitti: you using a kernel patch for ssp ? IIRC the kernel didn't build with ssp (but I haven't checked in a while)
<pitti> Yagisan: I'm just running a test build
<pitti> Yagisan: it's running for ~ 30 minutes, works fine so far
<pitti> Yagisan: (the build is running, not the kernel)
<TheMuso> Keybuk: When you have a minute, could you please have a glance over SpokenBoot, and let me know if I have writtup what discussed earlier correctly? Thanks in advance.
<jdub> mjg59: reping
<jdub> mdke: ping
<mjg59> jdub: Hi
<jdub> mjg59: hey - did you get my pants mail?
<mjg59> jdub: Yeah
<mjg59> jdub: I'm on it
<_ion> "did you get my pants by mail?"
<jdub> mjg59: rad
<Mithrandir> jdub: does there exist a usable tool for making UI mockups?
<sladen> Mithrandir: glade 
<Mithrandir> sladen: it's not very good when I want to put in example data and such, IME.
<bddebian> Hello
<jdub> Mithrandir: not wildly
<jdub> Mithrandir: but yeah, glade is an okay start
<jdub> Mithrandir: plus gimp for putting shit inside
<msw> jdub: Stetic was nice
<Mithrandir> jdub: glade makes me want to poke my eyes out, but I'll see what I can do.
<bddebian> heh
<jdub> Mithrandir: try gazpacho
<msw> http://gazpacho.sicem.biz/
<Mithrandir> iz packaged.
<msw> and written in python
<jdub> msw: debian/ubuntu users don't use sourceforge, freshmeat, or websites :)
<Mithrandir> software not in Debian/Ubuntu doesn't exist.
* msw looks at the current channel
<msw> #ubuntu-devel
<Mithrandir> jdub: it looks better, at least.  Thanks.
<jdub> how do you purge with smart?
<pitti> Yagisan: oh, shit, kernel linking indeed fails since it doesn't find the __stack_chk_fail symbol
<mdke> jdub: hi. email would be best at the moment, am a bit swamped at work
<mdke> jdub: go ahead here though if it is something simple
<apokryphos> jdub: no option currently; it'll be added for 0.42 I hear though
<jdub> mdke: hrm?
<mdke> jdub: you pinged
<mdke> no?
<jdub> no
<jdub> unless i did ages ago
<mdke> 34 minutes ago
<tseng> you absolutely did.
<tseng> at 11:02
* mdke is grateful his client doesn't lie to him
<thom> jdub: senility STRIKES!
<jdub> i have *no* idea what for
<jdub> 34 minutes ago?!
<seb128> we should force people to ping with some context
<jdub> i so did not
<BenC> (spam) http://mkdump.sourceforge.net/
<mdke> no worries
<seb128> you so did
<Gman> thom, next will be blader control :)
<jsgotangco> jdub: its those tam tams
<jsgotangco> tsk tsk
<jdub> ROAR!
<sivang> jsgotangco: didn't you mean tim tams?
<seb128> we should not let jdub have meat at lunch, he's ROARING now
<sivang> lol
<jsgotangco> sivang: yeah thanks
<sivang> hmmm I would just love having a tim tam now. mmm
<Gman> get a penguin bar instead...they're the real tim tams..
<thom> Gman: *giggle* x 2
* jdub kicks Gman and thom in the pants
<thom> jdub: watch out for the arthritus!
<tseng> thom: :(
<tseng> my hand is starting to hurt lately
<desrt> too much... uh.... coding.
<thom> tseng: i recommend ion3 and as little mousing as possible. did wonders for my rsi
<bddebian> I don't suppose anyone would want to help me with a broken Edgy?
<desrt>  "Ubuntu Development (not support, even with edgy)"
<desrt> :)
<HiddenWolf> desrt: ;)
<simira> bddebian: seriously?
<Mithrandir> I recommend laptops in your lap against rsi.
<Mithrandir> and feet on the table.
<desrt> rsi is teh suck
<ogra> Mithrandir, pingedipingf
<ogra> -f
<Mithrandir> ogra: I have no idea what a diping is, but here's a dupong.
<bddebian> simira: Yeah, I updated one of my Dapper dev boxes to Edgy to start on some packaging and it's hosed
<ogra> Mithrandir, is ldap server management etc planned for the network auth SoC ?
<bddebian> desrt: I am well aware that this is not a support channel
<thom> bddebian: may i commend the concept of chroots to you?
<Mithrandir> ogra: read the spec?
<simira> bddebian: somepeople's early... good luck on you!
<bddebian> thom: On some of my machines I will do that
* bddebian feels the love
<seb128> bddebian: don't update to edgy :p
<ogra> Mithrandir, what about this ton of additional remarks, its not really clear *what* exactly is planned from them ... or are they just random user comments ?
<thom> bddebian: seriously, don't run dev trees this early, they will *NOT* work in any useful form consistently
<ogra> (at the bottom of the wikipage)
<zul> bddebian: rember only you can prevent yourself from upgrading
<Mithrandir> ogra: they're random user comments.
<ogra> Mithrandir, thanks :)
<ajmitch> ogra: complain to me about it
<ajmitch> for some reason I'm still awake
<Hobbsee> go sleep then ajmitch :P
<Mithrandir> ajmitch: work harder! :-P
<ajmitch> yes sir! right away sir!
<Hobbsee> ajmitch: good slave.
<ogra> ajmitch, do you plan to do anything on the server side for edgy already (the spec says just that it might take long or even not :) )
<ogra> (and as i understood it initially the server wasnt planned yet)
<ajmitch> ogra: yes
<Hobbsee> night all
<ogra> yes ou plan to do anything on the server ? or yes the server wasnt planned yet ?
<ogra> s/ou/you/
<ajmitch> ogra: yes I plan to, does the spec need clarified there?
<ogra> well, it could 
<ajmitch> ok
<ogra> we'll make the fat client spec depending on it then, thanks for clearifying it :)
<ajmitch> yes, I plan to run an LDAP & Kerberos server, have some user/group management & migration tools
<ogra> ok, great :)
<ajmitch> sounds interesting :)
* ajmitch goes & reads the LTSP fat client spec
<ogra> fat clients wont work without network auth and nobody of us wants to duplicate your work ...
<ajmitch> it would be a bit painful to have duplication
<ogra> it not a high prio anyway
<ajmitch> no, but I've got to push what I've done/am doing onto the supermirror soon
<ajmitch> so we can all play along together
<ajmitch> having some filesystem mounting would be useful though
<ajmitch> & could be done without too much extra hassle
<bddebian> Heya Keybuk
<Yagisan> pitti: IIRC there is a patch for ssp, but only on amd64. It was a 2 part patch. 1 for kernel, & 1 for gcc. It should be on lkml, but you'd need to hunt for it.
<lifeless> Keybuk: would like 5 minutes of your time..
<thom> lifeless: do you and keybuk have something going on? you two keep sneaking off together ;-)
<Keybuk> lifeless: POSEIDON
<lifeless> Keybuk: no need to shout :)
<lifeless> thom: what do you think?
<Keybuk> thom: yes, now he's lost all that weight he's a hottie
<lifeless> be up in a minute
<thom> SEE
<bddebian> uhm
<raphink> what might prevent dh_installinit from creating the rc links ?
<raphink> i've got a package here that somehow doesn't create the links after installing the init.d script
<Keybuk> depression, ennui, malaise, etc.
<Keybuk> raphink: do any links already exist?
<raphink> nope
<raphink> not for this daemon at least
<Keybuk> grep update-rc.d .../postinst
<shawarma> raphink: dh_installinit writes the code to do it into postinst..
<shawarma> raphink: er... yeah, what Keybuk said. :-)
<raphink> shawarma: ok
<raphink> yeah postinst doesn't have it
<shawarma> raphink: Which package is this?
<raphink> shawarma: a private one ;)
<raphink> in that case
<Keybuk> man dh_installinit
<raphink> that's what I did Keybuk
<raphink> it's not very clear though ;)
<shawarma> raphink: Ok. 
<shawarma> raphink: Are you sure it's called at all?
<Keybuk> man update-rc.d
<Keybuk> (which is what dh_installinit causes to be called in postinst)
<Keybuk> raphink: does your postinst have 
<Keybuk> #DEBHELPER#
<Keybuk> ?
<raphink> nope
<Keybuk> I see
<Keybuk> probably best to start off with some Debian package HOWTOs then
<raphink> it should have it so it get replaced I guess
<raphink> hehe
<shawarma> raphink: Oh, you have a custom postinst in your package?
<raphink> *blush*
<raphink> it's no my package Keybuk I'm fixing it
<raphink> ;)
<raphink> thanks I know what to do now :)
<shawarma> np. :-) 
<Keybuk> lifeless: keeping me waiting, eh?
<thom> Keybuk: he's keeping you keen!
<lifeless> yup
<lifeless> sorry, ELOCAL
<Keybuk> I'm not familar with that one?
<lifeless> local interruptions
<Keybuk> EINTR
<Keybuk> surely?
<lifeless> maybe, but they are outside my skin, so I dont thinkso
<Keybuk> E2BIG?
<lifeless> could be EPIP
<Keybuk> ("Argument list too long")
<lifeless> *EPIPE
<zul> EWIFE also
<Keybuk> EIEIO
<Mithrandir> EPIP, the cousin of EBIRD.
<thom> i think EUSERS might be more suitable ;-)
<Keybuk> well, lifeless kept his word
<Keybuk> he came
<Mithrandir> was it good?
<Mithrandir> (SCNR)
* bddebian covers his ears
<pitti> infinity: do you have some minutes?
<infinity> pitti: Sure, what's up?
<infinity> pitti: You want me in person, or is IRC fine?
<pitti> infinity: let's talk about it at dinner, or tomorrow; I'd prefer a personal talk 
<pitti> infinity: (just to scare you: THE RETURN OF GCC WRAPPERS) MUHAHAHA
<ivoks> bon apetit guys :)
<pitti> ivoks: merci
<pitti> infinity: https://wiki.ubuntu.com/GccSsp
<bddebian> Is requesting syncs of Experimental packages frowned upon?
<fabbione> bddebian: i suggest to wait 2/3 weeks before asking for syncs
<fabbione> there is all the merge phase
<fabbione> and most of the stuff might come in naturally in main
<bddebian> fabbione: This would be new ... Oh
<fabbione> well new or not new, it makes no difference really
<fabbione> all of sid is processed
<bddebian> Hmm, well gnash would be in Universe I think
<fabbione> but it's a good idea to get the toolchain the time to stabilize
<wasabi> Hmm. Suse's boot screen is Really Big Res
<bddebian> fabbione: OK, so what could I be 'helping' with currently? :-)
<fabbione> bddebian: hmmmmm 
<fabbione> what about relaxing, accumulate some power so as soon as Merge-o-Matic will open, you can help with that?
<bddebian> OK, I'll go back to bugs then :-)
<fabbione> there isn't much we can really do
<fabbione> at elast if you don't want to start to do manual MoM
<bddebian> Well in my experience most of MoM is manual anyway :-)
<fabbione> bddebian: in your experience MoM does a lot of work for you.
<bddebian> Oh crap, I do still have some patches I wanted to send to Debian..
<fabbione> work that you would be forced to do manually now
<fabbione> anyway.. movie time
<bddebian> Enjoy
* fabbione vanishes
<fabbione> thanks
<t0rtoise_> +
<wasabi> http://us.archive.ubuntu.com/ubuntu/pool/universe/   <--- missing some things
<tefera> How do we get a wiki page for our translation team?
<Keybuk> create it
<Keybuk> (go to it, and click "Create this page")
<tefera> ok!!!
<tefera> hmm!! I see that all teams and people have a "wiki" under "details" which makes is possible to create a wiki page but https://launchpad.net/people/ubuntu-l10n-am does not have one. It seems i hav to ask the same question again.
<Keybuk> edit details
<mikearthur> are you guys aware of the bug with PPC CDs?
<infinity> "the bug"?
<infinity> That's really pretty unspecific.
<mikearthur> sorry
<mikearthur> finding link
<mikearthur> http://www.ubuntuforums.org/showthread.php?t=121214
<mikearthur> http://www.ubuntuforums.org/showthread.php?t=185580
<mikearthur> http://ubuntuforums.org/showthread.php?t=187056
<mikearthur> and I'm having the same problem
<mikearthur> the release media doesn't work at all on a good deal of PPC hardware
<mikearthur> bug was filed prior to Dapper release, and at least one dev knows of the problem, but the ISOs are still sitting there with no warning
<Keybuk> which bug number?
<mikearthur> and, by the sounds of things, PPC cds are getting printed and delivered which, again, won't work on a lot of hardware
<mikearthur> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/34508
<Ubugtu> Malone bug 34508 in linux-source-2.6.15 "2.6.15 kernel fails to boot on ppc machine" [High,Fix released]  
<mikearthur> the fix didn't make the CDs
<Keybuk> https://wiki.ubuntu.com/DapperPointReleaseProcess
<infinity> Well, if it's fixed already, it'll be in the next point release.
<infinity> Not much we can do before that.
<mikearthur> yes there is
<mikearthur> you can put a notice next to the ISOs that there are known problems on some hardware, causing them to simply not boot
<mikearthur> and an estimated release date for the point release
<Keybuk> there's known problems on all hardware
<Keybuk> I believe it's mentioned in the Dapper Release Notes too, though I could be mistaken
<mikearthur> yeh, but this is a lot more severe than most hardware
<infinity> No, it's only more sever because you own it.
<infinity> We have boot failures on other bits of hardware too.  The world is less than perfect, unfortunately.
<infinity> s/sever/severe/
<mikearthur> seems a fair few people complaining in the forums
<mikearthur> and thats not including people who will burn a disc, oh, it doesn't boot, next distro
<mikearthur> I realise the world isn't perfect
<mikearthur> I'm just saying, you might want to make this information a bit more public
<ivoks> as fas as i can see, regular update should fix it :)
<mikearthur> so people don't waste CDs and time
<Keybuk> the net effect is the same though
<mikearthur> Keybuk: the net effect compared to what?
<mikearthur> its not in the release notes on the page
<Keybuk> people won't use that cd on that machine
<mikearthur> do you want ubuntu to be used more or less?
<Mithrandir> oh, excellent.
<Mithrandir> my first jprobe written.
<fabbione> Mithrandir: jprobe?
<Mithrandir> fabbione: mhm
<Mithrandir> fabbione: writing a small module which logs all file accesses and the time they're done.
<fabbione> Mithrandir: the "j" at the beginning is scary :)
<Mithrandir> fabbione: why?
<fabbione> smells of Java
<fabbione> rsync: write failed on "/srv/mirrors/ubuntu/dists/edgy/main/binary-hppa/Packages.gz": No space left on device (28)
<fabbione> UHMPF
<Mithrandir> nah, it's a kprobe except it's allowed to inspect the function's arguments.
<fabbione> we didn't kill warty from the archive did we?
* Mithrandir is scared by the container_of macro.
<fabbione> since edgy we added already a 10GB delta of data
* fabbione heads to bed while the system does add a few GB to the mirror
<fabbione> good night guys
<Mithrandir> night, fabio.
<robertj> does anyone here have any background on why teamspeak was chosen?
<Keybuk> yes
* robertj waits with giddie school-girl giggles
<Keybuk> because it's the only program of its kind that used TCP and showed who was speaking
<robertj> fair enough
<robertj> does the gaim plugin still work?
<Keybuk> the whuhwhat?
<robertj> libtbb had a gaim plugin inthere somewhere I thought
<Keybuk> never heard of it
<robertj> it seems to implement the teamspeak protocol
<Keybuk> that seems to be the UDP one
<robertj> oh 
#ubuntu-devel 2006-06-22
<jdong> what's up with edgy right now?
<jdong> is universe syncing yet?
<zul> jdong: most of the core-developers are in paris and its 4 am right now
<zul> so you might not get an answer
<jdong> k
<bluefoxicy> What linker options are used with glibc in ubuntu?
<sladen> bluefoxicy: apt-get source  the package and find out
<bluefoxicy> nevermind I see
<sladen> bluefoxicy: I think  --omg-optimised  is one of them
<bluefoxicy> lol
<bluefoxicy> sladen:  I'm talking to someone about interesting optimizations that get major speed gains but that never got into binutils or libc because of prelink
<whiprush_> hi paul
<sladen> because of prelink?  or without it?
<sladen> whiprush_: morning
<whiprush_> sladen: you in paris?
<bluefoxicy> sladen:  Guy got my hopes up, then told me the patch never made it in :(
<sladen> whiprush_: why yes.  Not that it's actually particularly near to Paris, somewhere next to an airport
<whiprush_> heh
<bluefoxicy> sladen:  there's some old binutils linker switch -Bdirect that somehow makes linking a lot faster without actually prelinking, or so I gather.  The patch is probably unmaintained, and not in upstream; I thought it was in upstream, so I was gonna recommend building using it if it turns out to work as advertised.
<whiprush_> sladen: hey if you see jdub this morning and if he has time, can you ping him about my blog feed on planet? I'm pretty sure my feed is fine, and I want to blog about the new ubuntu book buy don't want to break planet.
<whiprush_> I'm heading to bed so I don't think I'll be able to track him down anytime soon.
<sladen> whiprush_: I'm sure he'll notice when he wakes up.  It's a bit early and during the hours of darkness I think jdub normally sleeps in his vampire costume, so I might not want to go knocking until after breakfast... :)
<whiprush_> sladen: heh, no problems. 
<whiprush_> You are a gentleman and a scholar.
<sladen> whiprush_: and a sleepy one at that
<jkanter> exit
<bluefoxicy> uh.  Evolution asks for my time zone.  It probably should ask the system.
<aedwards232> When will xen be a mainstream part of Ubuntu?
<Mithrandir> probably sometime this release cycle.
<ajmitch> probably very soon in egdy, judging by work done already
<ajmitch> morning Mithrandir :)
<Mithrandir> ehlo, ajmitch 
<G0SUB> ajmitch: how's work going on?
<Hobbsee> hi all
* fabbione yawns
<fabbione> morning guys
<Hobbsee> afternoon fabbione!
* Hobbsee drops a few ice cubes down fabbione's back.
<fabbione> Hobbsee: #@!*
<Hobbsee> fabbione: you wanted to be woken up didnt you?
<fabbione> nope
<fabbione> i love to enjoy my liter or so of coffee
<Hobbsee> haha
<Hobbsee> scary
<fabbione> why is that scary?
<Hobbsee> just the thought of drinking so much coffee in one hit...
<Hobbsee> you must end up bouncing off the walls..
<fabbione> no, it's not in one hit
<fabbione> it takes about one hour
<fabbione> and no i don't jump on walls..
<Hobbsee> oh.  pity.  that could be kinda amusing.
<fabbione> i used to drink much more but i did cut down a lot after quitting smoking
<Hobbsee> ah...
<Hobbsee> well, at least the drinking isnt likely to kill you, whereas the smoking will - so i think you quit the right thing.
<fabbione> that really depends..
<fabbione> my grand-grand-mother died 105 years old, smoking 40 cigarettes (of the worst quality) each day
<fabbione> she just felt asleep on couch
<Hobbsee> ack
* Hobbsee cant even comprehend that.
<fabbione> i can also tell you of my huncle that dies of cancer 30 years old. He didn't smoke, drink or anything
<fabbione> so it's a matter of "luck"
<fabbione> i did quit only because i am going to be father in about 3 weeks
<fabbione> and i am not doing it for me because i love smoking
<Hobbsee> fair enough
* Hobbsee just isnt willing to be thrown out of the house for it.
<fabbione> Hobbsee: fair enough :) both my parents were heavy smokers..
<fabbione> so it didn't make much of a diff when i started
<Hobbsee> true
<Hobbsee> actually, i dont care if people do smoke - just if they have a smoke, then they come and breathe over me, then they'd better expect me to whinge and whine and hit them till they go away...oh, and hit them in the arm till they do.
<Hobbsee> my boss knows this :P
<Hobbsee>  /end rant
<fabbione> :)
* Hobbsee tells self to shut up, as fabbione didnt.
* Yagisan hands Hobbsee his shovel so she can keep digging
<Hobbsee> heh, thanks Yagisan 
* Hobbsee goes back to hide in her little corner.
<Yagisan> Hobbsee: no worries. For some reason I wasn't using it today, so I though you could get some use out of it
<Hobbsee> Yagisan: you sure LaserJock couldnt use it again?  he was doing so well with it yesterday!
<Yagisan> Hobbsee: I must have missed that. I've been running around like a headless chook getting my uni stuff done
<Hobbsee> Yagisan: ah, fun.  it was over him saying i needed to become a MOTU so i could become the MOTU calendar girl.
<Hobbsee> enough said, really :P
<fabbione> Hobbsee: i am not that evil.. but i can be much worst :)
<Hobbsee> haha, right, i'll have to remember that.
* Hobbsee makes a mental note to never meet up with fabbione 
<fabbione> eheh
<Hobbsee> hi imbrandon_ 
<Hobbsee> in the sources list, why are we making this happen?  # Line commented out by installer because it failed to verify: 
<Hobbsee> surely that just causes more problems, when the internet connection finally is gotten, but cant find any packages.
<fabbione> Hobbsee: otherwise apt will refuse to install stage 2 (desktop)
<Hobbsee> fabbione: ah, i see.  and why do we have multiverse listed as part of backports, but not just normally multiverse?  
<Hobbsee> hmmm...that didnt seem to make much sense.
<fabbione> is it?
<fabbione> i didn't notice
<fabbione> but backport is disabled by default due to its.. *special* nature
<Hobbsee> yes
<Hobbsee> really, multiverse should either be in multiple locations, or taken out fully
<fabbione> Hobbsee: agreed.. file a wishlist bug on apt-setup (installler)
<Hobbsee> its so confusing to users who say "yes, i've got multiverse enabled, i can see it" who we then have to say "well, actually, that's backports multiverse, the multiverse you're really looking for is this multiverse"
<Hobbsee> so the package is apt-setup?
* fabbione rechecks
* Hobbsee contemplates just patching it, and adding that to the wishlist bug.
<fabbione> yeps
<Hobbsee> fabbione: is that where you mean, or i havent found the correct thing yet? https://launchpad.net/distros/ubuntu/edgy/+source/apt-setup/+bugs
<fabbione> yeah that one
<Hobbsee> cool, thanks :)
* fabbione zero's a few machines to test cluster
<Hobbsee> fabbione: done, thanks :)
<fabbione> no problem
<Hobbsee> weird that we cant set the status of our own bug though.
<fabbione> morning mdz
<Hobbsee> hi mdz 
<dsas> Hobbsee: You need to be in the bugsquad to do that now I think.
<Hobbsee> dsas: ah, okay, interesting.  might have to join that then, as i tend to deal with a lot of the kde bugs.
* Hobbsee joins.  thanks for that dsas :)
<mdz> morning
<Mithrandir> mdz: why does /schedule/$today give me a 403?
<Hobbsee> hi Mithrandir 
<Mithrandir> hiya Hobbsee.
<Mithrandir> How's Sydney today?
<Hobbsee> Mithrandir: okay, i went shopping :)
<Mithrandir> Hobbsee: you girl. ;-)
<Hobbsee> hehe
<Mithrandir> Hobbsee: found anything interesting?
<Hobbsee> Mithrandir: yeah, two jackets and a light
<Mithrandir> light as in torch?
* Hobbsee rarely goes shopping.  she's a betrayer of her sex.
<Hobbsee> yeah
<TheMuso> Morning all.
<Hobbsee> morning TheMuso!
* mdke helloes
<jsgotangco> good mornig
<Hobbsee> hi mdke!
<Hobbsee> hi jsgotangco 
<desrt> hello, world.
<desrt> hello, city
<Hobbsee> hi desrt, from a green bug eyed monster from outer space.
<desrt> is that you?
<desrt> or just a friend?
* Hobbsee is a green bug eyed monster, yes.
<desrt> i see....
<janimo> jdub: dholbach: daniel told me you have a wikipage gathering ideas to talk about with gnome upstream at guadec?
<dholbach> janimo: http://wiki.ubuntu.com/JeffWaugh/GUADEC2006 or something
<janimo> dholbach: thanks
<janimo> https://wiki.ubuntu.com/JeffWaugh/Guadec2006
<mdke> Znarl: yo?
<Kagou> hi
<TheMuso> highvoltage: ping
<highvoltage> TheMuso: pong
<TheMuso> highvoltage: Henrik was wondering whether you were going to attend the access.ubuntu.com bof?
<jsgotangco> GO HERE NOW
<jsgotangco> =)
<highvoltage> ok, be right there
<siretart> wow. adding teams to a team makes launchpad quite noisy...
<Lathiat> i like the To: a, b, c
<Lathiat> thats a bit dodge :\
<LaserJock> siretart: those emails are a bit cryptic too, it took a while for me to figure out what the heck the id of the new team was
<LaserJock> LP thing I guess
<siretart> LaserJock: I didn't remember that lp is that noisy. next time I will provide a comment in the textfield
<siretart> but this won't be too soon, I hope
<LaserJock> hehe
<TheMuso> Kamion: Do you have that patch fot ehatspi stuf somewhere where I can grab it?
<Riddell> TheMuso: can we look at kubuntu-accessibility at 17:00?
<Riddell> anyone got sight of mvo?
<TheMuso> Riddell: Sure thing. I'm free.
<Riddell> TheMuso: is henrick around for you to ask too?
<TheMuso> Not atm. he went to have a rest, I don't think he is feeling that great today.
<TheMuso> He said he would probably see me after lunch, so the est thing we can do is ask him then I think.
<jsgotangco> s/that great/not that great
<Riddell> TheMuso: ok
<TheMuso> He is free according ot the schedule.
<TheMuso> thanks jsgotangco 
<shawarma> w/in 8
<shawarma> argh...
<jdub> elmo: ping
<yosch> here is the list of OFL fonts: http://scripts.sil.org/OFL_fonts
<doko> jdub: you can even use ttf-gentium on Ubuntu, it's *not* optimized for gentoo ;-P
<jdub> GENTIUM, OPTIMISED FOR GENTOO USING GENTLEMENT
<jdub> WHO LIVE IN GENT
<jdub> (bah on beligians for pronouncing that so badly)
<jdub> belgians
<jdub> ha ha
* Mithrandir turns down the jdub-o-volume.
<Lathiat> Error: cannot open /dev/mixer: device not found
<StevenK> And here I was wondering why mdz is in France.
<StevenK> And then my brain kicked in.
<jvw> is there any work going on on forwarding bugs in launchpad to debian where appropriate? I just discovered a couple of bugs were filed on packages I maintain in Debian, but those reports haven't reached debian yet, one of them being from august 2005. Since those bugs are just as relevant for Debian too and could've been solved if they were known, it'd be cool if they were forwarded, esp. when there's no ubuntu activity on the bug for let's say ...
<jvw> ... half a year?
<fabbione> jvw: you want to talk to bradb on #launchpad
<fabbione> the definition of appropriate is really delicate as you can imagine yourself
<jvw> yeah, I'm aware of the discussions/flames...
<jvw> maybe something like 'try to file the bug with debian' as automatic comment after a certain amount of inactivity?
<azeem> there was talk about setting up a list similar to LowThresholdNMU, so you could forwar bugs to a whitelist of DDs
<fabbione> jvw: as i said it's best if you talk to bradb
<fabbione> there can be tons of different implemenations i think
<fabbione> but the major point is exactly what azeem mentioned.. how DD's would like to receive the info?
<fabbione> assuming they want it, and if not how to filter.. blablablablablabla*flame*blablabla*flame*etc...
<azeem> or there could be a feature "subribe me to all bugs reports affecting packages maintained by me in Debian"
<azeem> subscribe
<fabbione> azeem: exactly.. there can be tons of different implementation
<fabbione> but bradb is the malone god :)
<zul> azeem: there is already for inidividual packages i think
<jvw> the PTS now supports getting derivative bugs/upload notifications etc that are seperately disableble/enableble
<TheMuso> Riddell: Oh BTW, will we have the Bof at Henrik's table? I still haven't seen him yet.
<simira> someone: is +35 france phone number?
<mdke> I think it's 31
* mdke looks
<lucas> 33
<lucas> +33 [drop the leading zero] 
<jsgotangco> you win!
<lucas> I'm french, so ... :)
<spacey> +31 is the netherlands
<simira> wonder who called me from Cyprus...
<Riddell> TheMuso: the gap in the schedule is for Atlas 4/1, but we can do it with at heno's if he's around
<TheMuso> Ok.
<Hobbsee> hi simira 
<bddebian> Heya folks
<seb128> mdz: could you assign gst-to-umbrella to me on launchpad?
<TheMuso> Has anybody seen Henrik at all since lunch?
<Riddell> TheMuso: he's just coming in now
<TheMuso> Oh ok.
<Riddell> TheMuso: he's at atlas 1
<TheMuso> np
<TheMuso> Was not sure whether he was around.
<TheMuso> Do you want me to ask him about kubuntu a11y?
<Riddell> TheMuso: please do sure, in an hour
<TheMuso> Yep, will do.
<Riddell> jdub: is your bof going to finish soon?
<Riddell> we need to borrow henrick
<jsgotangco> its becoming a stalemate
<Hobbsee> jsgotangco: it wasnt before? 
<ajmitch> jsgotangco: was anything agreed on?
<jsgotangco> its always been like that :/
<ajmitch> unfortunate
<Hobbsee> ajmitch: to get the guy on the phone tomorrow instead.
<jsgotangco> but roald is here and great to have him around
<ajmitch> yes, I saw that
<TheMuso> What spec was that?
<ajmitch> forums stuff
<TheMuso> oh ok.
<bddebian> Heya crimsun
<Mithrandir> lifeless: is there a way for me to get the diff which would result if I did bzr merge?
<Mithrandir> so bzr merge ; bzr diff ; bzr revert, except bzr revert doesn't always work.
<pitti> Mithrandir: why not just do it and revert --no-backups later?
<pitti> Mithrandir: oh
<Mithrandir> pitti: because revert doesn't always revert properly.
<Mithrandir> I can't remember the failure cases, but there are bugs filed.
<lifeless> Mithrandir: bzr rever should always work
<lifeless> Mithrandir: bug #'s ?
<Mithrandir> lifeless: I can't find it now.
<lifeless> assume its fixed then
<pitti> Mithrandir: I had troubles in the past as well and filed bugs, but they got fixed a while ago
<jbailey> sivang: ping
<Mithrandir> Kinnison: adding it into bterm however.. :-)
<Kinnison> Mithrandir: *g*
<Keybuk> BenC: ping
<BenC> Keybuk: pong
<Keybuk> BenC: speakup
<Keybuk> have you read the spec?
<BenC> I can't talk any louder
<BenC> Keybuk: not lately
<bddebian> heh
<BenC> I read over it when the BoF was happening, but not since
<Keybuk> could you do it quickly, if you're not busy
<BenC> yeah, pulling it up now
<BenC> Keybuk: looks pretty much like what I heard at the BoF, the only thing new that I wasn't aware of before (and it's pretty obvious if you think about it) is the need for sound driver udeb's
<BenC> Keybuk: I have speakup in the kernel already, and building nicely with udeb, so it's mainly userspace that needs to be done for this spec
<Keybuk> ok
<Keybuk> BenC: are the hardware synthesisers really not PCI?
<Keybuk> I'm confused by the bit in the spec talking about loading modules named in a configuration file at a particular point in the boot
<Keybuk> cause that's BROKEN
<TheMuso> Keybuk: No. Mostly serial and internal ISA
<Keybuk> meh
<Keybuk> ok, so the bus is broken too :p
<BenC> Keybuk: what Muso said
<TheMuso> Actually, all are serial and internal ISA. Only one driver is for software speech use, which just spits the output back to userspace.
<BenC> by default it will load a software synth which would work in any case where they have a sound card
<Keybuk> right-o
<BenC> TheMuso: here's a question, can more than one synth be loaded at a time?
<TheMuso> BenC: No.
<BenC> is that enforced, or is it just hoped that no one will do it? :)
<TheMuso> That would require a complete redesign of the synth and proc subsystem.
<TheMuso> It is inforced pretty much. When speakup is running, one can change synths by echoing the synth name to /proc/speakup/synth_name
<TheMuso> Speakup then goes and brings up the requested driver.
<BenC> ah, so you can load all the synths and pick one on the fly?
<BenC> I'm guessing a few of them need module_params though
<TheMuso> My guess is the authors didn't think multiple synths simultaneously would be really needed.
<TheMuso> No they don't.
<BenC> I can't see that it would be needed either, just wondering how it handled it
<TheMuso> They just probe for serial ports or ports that the ISA card would be sitting on.
<TheMuso> It would be nice to get the serial synths one day to use the tty subsystem, so that things such as serial to usb adapters can be used for synths.
<BenC> hmm, a full-on "if speakup userspace is loaded, load all synth drivers" type deal would be nice then :)
<TheMuso> BenC: Not atm. If a synth driver is loaded, speakup starts its keyboard capture.
<TheMuso> If synth_name is set to none, no keyboard capture is performed.
<TheMuso> But you couldn't load all drivers anyway. They bail out if they can't find a synth.
<TheMuso> Except for the softsynth driver.
<TheMuso> Anyway, time to pack up for dinner. If you want to talk about it more, catch me at dinner or some time later if you like.
<HiddenWolf> mdke: thee community docs link from the help.ubuntu.com/606/ site 404's because it points to 606/community rather than /community
<Znarl> HiddenWolf : That's my fault, I plan to fix it shortly.
<HiddenWolf> Znarl: ah, ok, no problem
<XMuffinFlavoredX> Hello.
<XMuffinFlavoredX> Dead chat?
<mikearthur> how would I go about making a self-compiled kernel image fill the dependency for linux-image?
<XMuffinFlavoredX> I have a suqestion similar. How would I get the restricted modules required for Nvidia drivers with a newer kernel.
<HiddenWolf> Guys, try #ubuntu-kernel
<XMuffinFlavoredX> Thanks.
<mikearthur> cheers
<mdke> HiddenWolf: yes.
<HiddenWolf> mdke: znarl is fixing it, never mind. :)
<mdke> HiddenWolf: yes
<bluefoxicy> tseng:  do you know if anything in Ubuntu is built with -Wl,-O1?
<bluefoxicy> I'm looking at performance improving stuff... I've never really benched the linker optimization though
<bluefoxicy> oh holy crap
<bluefoxicy> that doubled my load speed
<bluefoxicy> about 38% load speed gain sweet.
<bluefoxicy> http://rafb.net/paste/results/Lnhs6k53.html  How's that?  :)
<bluefoxicy> huh.  Looks like it's done already
<TheMuso> sladen: Do you still happen to have those espeak changes you made handy in regards to it trying to find the espeak-data folder? If so, would you mind sending me a diff, or at least a pointer to the file you changed and how you changed it? Thanks.
<tseng> bluefoxicy: we have been using -Wl,01 since warty
<bluefoxicy> tseng:  on just a few things?
* bluefoxicy can't find it, he just dpkg-buildpackage'd coreutils...
<bluefoxicy> tseng:  is there an easier way for me to verify this besides building crap and watching text fly past my screen?
<Keybuk> bluefoxicy: yes.
<bluefoxicy> yes what hi?
<Keybuk> bluefoxicy: answering your mailing list question
<bluefoxicy> Keybuk:  Is it supposed to happen whet *I* build things?
<bluefoxicy> because for the life of me I can't make it
<bluefoxicy> dpkg-buildpackage -uc -us -rfakeroot spits out no text containing -Wl,-O or anything for gcrypt or coreutils (checked with grep -e "-Wl,-O")
<Keybuk> bluefoxicy: depends, do you have gcc-opt installed?
<bluefoxicy> I've also grepped /usr/lib and /usr/bin for the string (looking for wrappers) 
<bluefoxicy> oh
<bluefoxicy> I need a separate package for that?
<Keybuk> http://librarian.launchpad.net/2796588/buildlog_ubuntu-dapper-i386.nautilus_2.14.1-0ubuntu9_FULLYBUILT.txt.gz
<Keybuk> e.g.
<Keybuk> LDFLAGS="-Wl,-O1 -Wl,--as-needed"
<Keybuk> (grep it)
<bluefoxicy> got it
<bluefoxicy> nautilus-2.14.1/debian/rules:13:DEB_CONFIGURE_SCRIPT_ENV += LDFLAGS="-Wl,-O1 -Wl,--as-needed"
<bluefoxicy> Keybuk:  seems to be per-package.
<Keybuk> could be
<Keybuk> most of the gnome ones, at leat
<Keybuk> (I picked that one at random)
* bluefoxicy wonders if there's even a mechanism to enable an optimization system-wide
<Keybuk> modify the gcc defaults?
<msw> anyone seen lifeless?
<bluefoxicy> I meant for ubuntu's build system o_o
<bluefoxicy> Keybuk:  although if you WANT to go spec hacking  :)
<Keybuk> msw: probably playing mao
<msw> ah
<Keybuk> bluefoxicy: I don't especially
<msw> spec hacking is evil
<Keybuk> specs are evil
* Keybuk is trying his evil "make openoffice start faster" hack
<msw> Keybuk: oh?
<msw> Keybuk: the "link it all together" hack?
<Keybuk> msw: worse :p
<tseng> Keybuk: i think -Wl,-O1 is probably in ENV on the buildd's
<tseng> Keybuk: i would bet on it, actually
<Keybuk> tseng: it used to be in our insane gcc wrapper scripts
<Keybuk> it probably still is
* bluefoxicy looks for other nice things then.
<bluefoxicy> tseng:  help me beat -Bdirect into Drepper's skull :>  (no not really, I don't understand it enough to try yet...)
<tseng> Drepper is a genius
<tseng> you are not.
<bluefoxicy> oh how would you know.
<tseng> because I've known you for 4 years
<bluefoxicy> heh
<bluefoxicy> Ask a silly question
<bluefoxicy> tseng:  http://sourceware.org/ml/binutils/2005-10/msg00436.html http://bugs.gentoo.org/show_bug.cgi?id=114008
<bluefoxicy> tseng:  Can't be used in Ubuntu, at all.  Not part of glibc or binutils mainline, probably at this point fading away due to lack of maintainer interest since upstream is hard up for "prelink is better than this"
<tseng> I maintain that upstream might actually know something that you don't
<tseng> I am not motivated atm to prove it to you
<bluefoxicy> I'm rather certain they do, but they're not interested in telling anyone what that something may be.  On the other hand, a few other known geniuses like -Bdirect as well.
<bluefoxicy> (other i.e. other than drepper; you're indeed right, I don't exactly have a genius star nailed above my door ;)
<bluefoxicy> but it doesn't matter, like I said.  Upstream will never go for it, it's ill maintained now, it had implementation bugs that I don't know if they ever got fixed, and interest in it is dead.  Time to search for other things that might do nicely.
* Keybuk stares at doko
<Keybuk> openoffice.org build-deps THE ENTIRE FUCKING ARCHIVE
<bluefoxicy> XD
<bluefoxicy> Keybuk:  no space left on device?
<Keybuk> I had to download a FUCKING GIGABYTE into a chroot just to build it!
<_ion> Build-Depends: *
<_ion> A wildcard! :-)
<fabbione> Keybuk: be grateful it doesn't build-dep on mono .. yet :)
<HiddenWolf> fabbione: ugh
<HiddenWolf> fabbione: isn't python, java and whatever else it uses enough already? 
<fabbione> HiddenWolf: well OOo has mono bindings but we can't enable them
<HiddenWolf> fabbione: just curious, has the beagle-by-default proposal been discussed yet?
<Keybuk> HiddenWolf: which beagle-by-default proposal?
<fabbione> HiddenWolf: no idea. i am not in Paris
* Keybuk can't see it in the spec list
<Keybuk> or is this a "forums proposal" ?
<HiddenWolf> Keybuk: well, the "we want beagle installed" proposals that zoom around the wiki
<Keybuk> (like "forums bugs" ... the ones everyone knows about but nobody has actually reported!)
* HiddenWolf looks again
<fabbione> HiddenWolf: if it's not tracked in LP it will never be discussed and the deadline for paris was 10 days ago or more
<fabbione> so no
<fabbione> there is no chance it will be
<Keybuk> Launchpad doesn't (yet) do ESP
<HiddenWolf> *chuckle*
<Keybuk> you can't think hard about what you want, and have it automatically registered
<fabbione> Keybuk: not yet? tsk.. lp slackers..
<Keybuk> fabbione: it would be nice, but it pales in comparison to the soul-crushing pain of other things
<Keybuk> DO NOT DISTRACT THE SOYUZ TWINS
<fabbione> KaiL: agreed
<HiddenWolf> Keybuk: fabbione, never mind me. :)
<fabbione> HiddenWolf: we forgive you
<HiddenWolf> fabbione: https://launchpad.net/distros/ubuntu/+spec/beagle-integration <- like this, btw. :)
<fabbione> Priority: Low. <- unliely to be even discussed
<HiddenWolf> hm. :)
<HiddenWolf> I'm just a bit emotionally averse to .dll's and .exe's, don't mind me again. :)
<Keybuk> HiddenWolf: nobody proposed it for this meeting
<HiddenWolf> Keybuk: ah, ok
<SeanTater> for those interested, I've accumulated about three bugs in about 10 minutes (three different people)
<SeanTater> never heard of it, told to report http://rafb.net/paste/results/u5d5hM97.html
<SeanTater> where might I find a useful log for arts, it's had two memory leaks lately..
<Gadi> So, does anyone have an (edu)buntu server going with RAID5, an adaptec 2005S RAID controller, and dapper?
<Gadi>  kernel seems to like to panic on any newer version than hoary :(
<Gadi>  and, presumably the dpt_i2o bug was fixed in the latest kernel....
<Gadi> actually, its a 2010S
<Gadi> but, same difference
#ubuntu-devel 2006-06-23
<dooglus> is it worth reporting edgy bugs in launchpad yet, or should I leave them unreported?
<jdub> go for it
<dooglus> ok, I'll go for it
<Hobbsee> morning all
<jdub> howdy Hobbsee 
<Hobbsee> heya jdub! you're up early!
<ajmitch> or late
<jdub> other way around :)
<ajmitch> hello jdub 
<jjesse> maybe he just hasn't been to bed
<Hobbsee> ouch.  crazy.
<jdub> yo ajmitch 
<jdub> crazy is a good word for ubuntu developer summits
<Hobbsee> heh
<mjg59> jdub: I have the pants
<jdub> mjg59: you're a bloody legend, thank you so much
<mjg59> When do you get to Spain?
<jdub> um
<jdub> i forget
<mjg59> And how well do you remember them?
<jdub> the wiki knows
<mjg59> Just in case.
<mjg59> Ahem.
<jdub> ha ha
<Hobbsee> hehe
<jdub> they're brown corduroy :)
<mjg59> Excellent
<mjg59> If all else fails, I'll substitute them with the ones I'm wearing at the moment
<jdub> how's awes doing?
<jdub> er
<jdub> aes
<mjg59> Fine
<mjg59> Just finished his third year, hoping to make guadec next year
<jdub> cool
<mjg59> Which seems foolish, since he'll probably be graduating or something
<mjg59> jdub: Oh, Fiona's coming to guadec
<mjg59> So you can laugh at each other again
<jdub> sweet
<mjg59> And we can recount the tale of your fight against the circle line
<jdub> dude, we were laughing at you
<mjg59> Damnit
<jdub> hrm
<jdub> well
<jdub> that was laughable
<Hobbsee> hehe...who's fiona?
<mjg59> Hobbsee: My girlfriend
<Hobbsee> ah
<mjg59> Jeff met her after utterly failing to navigate the London public transport system
<Hobbsee> hehe
<mjg59> "Jeff, we need to be at dinner in 15 minutes"
<Hobbsee> well, he's a sydney sider.  we dont have a working reliable public transport system.
<mjg59> "Right. I'm sort of still in London"
<Hobbsee> haha
* jdub spanks Hobbsee 
<Hobbsee> you cant blame him for being shocked over something actuallyl operating well enough to use - and so therefore not being able to use it
<jdub> ours is perfectly reliable
<Hobbsee> hey now!  that's not fair!
<jdub> now they've changed the timetables to make it easier to suck less
<mjg59> It would have been fine if he'd got on the right train
<mjg59> Rather than the ghetto one
<Hobbsee> sure, as long as you dont expect it to follow the timetable :P
* RadiantFire gasps
<jdub> i totally went the wrong way around the circle line
<Hobbsee> haha
<RadiantFire> Atlanta's public transit is perfectly reliable, it just doesn't go anywhere useful
<jdub> uh... that's right.. it's in atlanta!
<RadiantFire> whats in atlanta?
<jdub> Atlanta's public transit
<RadiantFire> mmm, the joys of MARTA, using token machines that are older than I am
<Hobbsee> trees?
<dilinger> infinity: ping?
<neuralis> dilinger: it's 4:04am in paris.
<neuralis> er, 4:14.
<dilinger> ah
<dilinger> i was going to ask him whether new upstream releases for security updates are going to be the norm for dapper :/
<neuralis> that's crack. no, of course not.
<neuralis> some things get EOL'd by upstream, however, and backporting just isn't feasible.
<dilinger> well, the specific instance that caught my eye was the mysql-server update
<dilinger> Preparing to replace mysql-server-5.0 5.0.21-3ubuntu1 (using .../mysql-server-5.0_5.0.22-0ubuntu6.06_i386.deb) ...
<dilinger> it looks like that included not only a new upstream release, but some additional debian releases as well
<neuralis> it was probably judged as safe and reasonable, probably a minor bugfix release, so a backport wouldn't make sense.
<Lathiat> well if the minor upstream release was simply the bugfix then it would make some sense i guess
<Lathiat> check the changelog
<dilinger> i did
<dilinger> it's not simply the bugfix
<dilinger> it makes me a bit nervous to see that kind of thing
<neuralis> 5.0.22: "This is a security fix release for the previous production release family."
<dilinger>   * Upstream fixes REPAIR TABLE problem. Closes: #354300
<dilinger>   * Upstream fixes problem that empty strings in varchar and text columns
<dilinger>     are displayed as NULL. Closes: #368663
<neuralis> http://dev.mysql.com/doc/refman/5.0/en/news-5-0-22.html
<dilinger>   * SECURITY: This upstream release fixes an SQL-injection with multibyte
<dilinger>     encoding problem. (CVE-2006-2753)
<Lathiat> http://dev.mysql.com/doc/refman/5.0/en/news-5-0-22.html
<Lathiat> its entirely a security bug fix release
<neuralis> Lathiat: one step ahead of you ;)
<Lathiat> heh
<neuralis> Lathiat: anyway, find better things to worry about, this is totally sane.
<neuralis> er, dilinger: --^
<dilinger> Lathiat: it is not entirely a security bug fix release
<dilinger> one of the things listed in the upstream changlog is a fix for not compiling w/ -fPIC on sparc and amd64
<dilinger> while i agree that it's certainly a bug, it's not security related
<dilinger> my fear is that i'm going to switch servers over to dapper, and then dapper will start pulling in all sorts of new upstream releases
<neuralis> dilinger: find better things to fear?
* dilinger rolls his eyes
<neuralis> dilinger: your concern is unfounded.
<dilinger> that's a very valid fear when you're attempting to keep a couple hundred servers stable
<Lathiat> the fixes in upstream seem all to be justifiable to me, if not, open a bug / query teh person who uploaded it?
<dilinger> Lathiat: that's what i was doing
<dilinger> well, attempting to do
* netjoined: irc.freenode.net -> brown.freenode.net
<jmg> can i participate in paris meeting from here?
<Hobbsee> jmg: sorta.  not really.  there are sessions on gobby, and occasionally teamspeak
<jmg> sad
<jmg> they are discussing my specs
<jmg> and i dont even get to participate
<Hobbsee> i didnt think they were discussing specs if the spec writer wasnt in paris
<jmg> i wrote two and they got accepted
<Hobbsee> jmg: um, IIRC, they're not discussing *all* the specs - just the ones where the people are in paris
<jmg> ok
<jmg> ill try and find mdz
<Hobbsee> jmg: good luck, i'ts about 7.30am there
<Hobbsee> hi raphink 
<raphink> hi Hobbsee
<jmg> heh, bug #1
<Ubugtu> Malone bug 1 in Baltix "Microsoft has a majority market share" [High,Confirmed]  http://launchpad.net/bugs/1
<Hobbsee> yeah
<Hobbsee> i recall some of the comments benig pretty funny
<jmg> yes they are
<raphink> they're great :)
<infinity> dilinger: Pong?
<fabbione> hey infinity 
<fabbione> morning guys
<Hobbsee> hi infinity and fabbione 
<fabbione> hey Hobbsee 
* Hobbsee didnt realise it was that late already.
<TheMuso> Morning all.
<dilinger> infinity: see my bit about the mysql security update
<Hobbsee> hi TheMuso 
<infinity> dilinger: It was a conscious decision, based on the fact that we wanted .22 before release, but it didn't happen.
<infinity> dilinger: It's not going to be a continuing theme, I assure you.
<infinity> dilinger: We just figured that "right after release, before everyone has stabilised thundreds of systems, we can probably afford a few larger-than-usual updates for bugfixes"
<dilinger> infinity: ok.  that's good to hear
<infinity> dilinger: Don't worry, I share your fear.  This particular update just felt justified, based on the timing.  I think we're already too late now to pull the same trick again withoug feeling rather guilty about it.
<dilinger> infinity: yea, i was just a bit surprised to see it... especially given your background :)
<dilinger> infinity: you'd be the last person i'd expect to blindly trust upstream
<dilinger> infinity: so i figured it was justified, i just wanted to make sure it wasn't going to be something that was just done out of momentum
<infinity> No, no, you're safe.  Martin and I weren't simultaenously hit in the head with a bat or anything.
<pitti> infinity: ?
<dilinger> hehe, excellent
<Mithrandir> infinity: we could arrange that, however.
<infinity> pitti: Explaining that the recent "slightly more than just security fixes in our security updates" policy with, eg, PostgreSQL and MySQL isn't going to be the norm for the life of dapper.
<pitti> infinity: ah
<TheMuso> /c
<dholbach> sfllaw: "There are 100 direct members of the "Ubuntu BugSquad" team"!!!!111!!
<Hobbsee> dholbach: wow!  i didnt think it was that many when i joined
<raphink> dholbach: might I be the 101st ?
<Hobbsee> seems weird that the kubuntu-members team isnt part of the bugs team - seeing as they all seem to end up fixing a lot of bugs.
<dholbach> raphink: sure :)
<raphink> :)
<TheMuso> Riddell: What time do you want kubuntu-accessibility? I haven't seen Henrik this morning however.
<TheMuso> And I don't have anything officially scheduled today.
<TheMuso> Sorry it is at 15:00
<Hobbsee> TheMuso: is he even awake yet?  :P
<TheMuso> Hobbsee: he wasn't feeling very well at all yesterday. I wouldn't be surprised if he doesn't make an appearance.
<[hawk] > Hello, I did a stupid thing so I'll ask a stupid question: how do I find files that are not installed by any package?
<TheMuso> But we need to have that bof anyway.
<Hobbsee> TheMuso: ouch, i think he went to bed at around 3.30am this morning, too
<TheMuso> Oh ok?
<Amaranth> [hawk] : locale <file> Next time please ask in #ubuntu.
<[hawk] > I'm asking it here because I could not find a solution on the docs... nor on the #ubuntu channe!
<Amaranth> err, locate
<Hobbsee> TheMuso: unless someone else borrowed his computer, and pretended to be him :P
<TheMuso> heh
<[hawk] > Amaranth: maybe my question was not clear... I would like to find which files are on the filesystem but not owned by any package.
<Amaranth> [hawk] : ah
<mdke> [hawk] : that's not how it works. This channel isn't a fallback for support if other methods don't help
<Amaranth> hmm
<Keybuk> Day Five in the Big BOFfer house ...
<Keybuk> ...lifeless is in the Dairy room
<Hobbsee> hi Keybuk!
<TheMuso> heh
<jsgotangco> hmmmm
<[hawk] > mkde: If I don't get a positive anwer (I think there is not a way to do this) I will request this feature as a wish-liist item...
<[hawk] > mdke: sorry for mistyping your name :-)
<mdke> [hawk] : no problem. Sure, you could do that.
<Amaranth> [hawk] : It's not something you could do easily or quickly, that's for sure.
<Amaranth> [hawk] : I imagine it would take 24 hours or so on your basic system
<[hawk] > mkde, Amaranth: I think knowing if a file is coherent with the dpkd database is a nice (securirty) feature. But if it takes 24h...
<infinity> Amaranth: If "find /" and comparing with dpkg list files takes 24 hours on your system, you either have a really slow hard disk, or WAY more packages installed than I.
<[hawk] > mdke: sorry again!
<Amaranth> infinity: heh, i overestimate
<Amaranth> i would take the contents of dpkg --get-selections, parse it and feed it into dpkg -L <package name>, then compare to the results of find /
<Amaranth> find / takes about 5 seconds
<Amaranth> you could probably do it in an hour
<[hawk] > infinity, Amaranth: thank you very much. That way I find what files are not installed by dpkg (more or less becouse for example files in /usr/local are generated by postinstall scripts)....
<sivang> morning all
<Amaranth> [hawk] : unless i've done something wrong http://rafb.net/paste/results/Jzhjnu41.html should do what you want
<Amaranth> it'll probably take awhile
<Amaranth> 6 minutes, i'm not going to let it run anymore :P
<Lathiat> theres a utility called debsums
<Lathiat> that goes and compares all the md5sums to the package sums
<Lathiat> could be usefull too
<jsgotangco> sivang: do we still have a discussion later on home user backup? it seems done already
<david`bgk> hi
<david`bgk> I'd like to contact sabdfl quickly, anyone know how to proceed? (french phone number will be awsome)
<sivang> jsgotangco: nope, I've set it up so it won't need anhy more discussion
<jsgotangco> nice!
<jsgotangco> david`bgk: go to the hotel?
<sivang> jsgotangco: being reviewed by Ian at the moment
<sivang> :-)
<jsgotangco> yeah i saw the spec email
<david`bgk> jsgotangco, I've two possibilities (for lunch or at 6pm) to meet him and I want to know which is the most pertinent, in fact when he will have free time
<david`bgk> did you know if mark leave paris tonight?
<Keybuk> he does
<david`bgk> so he leave meeting at 6pm or he have some time to speak?
<Keybuk> no idea
<Keybuk> speak about what to whom?
<Keybuk> have you spoken to Claire?
<TheMuso> Has anybody seen Henrik this morning?
<david`bgk> I'd like to speak with Mark about French support in France, state of oss and ubuntu-fr projects, the president of the AFUL association (one of the most famous oss association in France will be present too)
<jsgotangco> you could have tried earlier its going to be a tight day today
<jsgotangco> well it is already that is
<david`bgk> I've no doubt about that :)
<david`bgk> my situation is a bit complicated those days
<Keybuk> david`bgk: I'd suggest you contact his PA
<david`bgk> sorry, what is PA?
<Keybuk> Personal Assistant
<Keybuk> e-mail mark.shuttleworth@canonical.com
<sladen> TheMuso: http://www.paul.sladen.org/ubuntu/upload/espeak-1.10-data-paths.diff
<TheMuso> Thanks heaps.
<TheMuso> Much appreciated.
<jmg> iwj
<jmg> ping
<pitti> infinity, elmo: since you two have the strongest opinions about doing the ssp stuff one way or the other, can we meet again today to come to a final conclusion? I updated the specs to describe the pros and cons of both options
<spacey> i'm giving a talk about ubuntu tonight, any idea where i can get some stats about downloads/shipped cd's? or just a guess of the install base?
<jmg> spacey: distrowatch
<jmg> spacey: and shipit maybe but i dunno how to get to stats
<spacey> jmg: distrowatch just indicates its most popular but doesn't give any cool numbers 
<spacey> ah it was mentioned before, somewhere:P
<sivang> jmg: there's a #uds-review channel
<iwj> jmg: Hello.
<sivang> iwj: have you had a chance to finish reviewing HomeUserBackup?
<iwj> sivang: Urr.  Was it me that was reviewing it ?
<iwj> I can review it if you like ...
<jmg> iwj: i saw you reviewing one of my specs
<jmg> xen-edgy
<sivang> iwj: Yes, you asked me about setting to review so I assumed you were reviewing it, but in that case we can leave it for the technical board to sort.
<iwj> Reviewing it now.
<sivang> iwj: thank you :)
<iwj> jmg: Err, no, I was hatcheting it.
<iwj> Someone else will have to review it :-).
<jmg> my mdzspeak not good enough?
<jmg> :p
<iwj> uh?
* jmg checks out the hatchet job
<iwj> xen-edgy used to be xen-enabled-kernel but the latter was too hard.
<iwj> :-/
<jmg> heh
<jmg> why not hire me to do it?
<jmg> "too hard"
<mjg59> "too hard" in terms of "breaks out of tree binary shite"
<jmg> that means "nobody wants to do it"
<mjg59> And a few other things
<mjg59> It's not practical to ship a xen-enabled kernel as default
<mjg59> (sadly)
<jmg> whoever thought it was needs a clue
<jmg> thats not what i was advocating
<iwj> Unfortunately there's an ongoing war in lkml between xen and vmware and the kernel bods don't seem to wait to choose and just say `come back to us when you both agree'.
<jmg> oh well
<iwj> jmg: We're going to have a xen guest kernel but it'll be in universe.
<jmg> iwj: why cant the tools and kernel be in main? too complex?
<iwj> what i was advocating> Well, err, we go by what's in the spec (which is something everyone can edit).
<iwj> Impractical to do security support for the kernel.
<jmg> okay
<jmg> im prepared to work with security to trickle fixes into the package
<pitti> jmg: for this to be halfway efficient, you need the xen kernel in git
<jmg> oh yay locked out by infrastructure politics
<pitti> jmg: of course the good old 'generate patch from the current xen kernel's RCS and apply them to the package' still works, but is painful
<pitti> jmg: ^ this is how hoary and breezy kernels were done, btw
<infinity> pitti: Yeah, I can make time to argue about it some more, but in the end, I'll cope with whatever we decide.  I can't keep arguing it forever. :)
<jmg> whats stopping the xen kernel entering git?
<pitti> infinity: in fact I'm with you, and I think I almost convinced mdz, but I do not want to punch elmo in the face without even having asked him
<mdz> pitti: "may I punch you in the face?"
<infinity> pitti: I don't recommend punching him in the face even after asking him. :)
<fabbione> first punch.. then ask :)
<pitti> mdz: ok, my sentence construction sucks today :/
<jmg> what a pity it cant get into main, i was hoping to become a main uploader :-)
<sivang> fabbione: heh
<iwj> jmg: Do you approve of the things I wrote in XenEdgy ?
<jmg> iwj: I dont really agree with the direction the upstream team has taken rolling almost everything into xen-utils, but if ya cant beat em, join em...
<jmg> iwj: otherwise yes
<iwj> What do you think shouldn't be in xen-utils ?
<jmg> iwj: wait can i use a universe package on a livecd?
<jmg> iwj: libraries
<iwj> Urr.  You mean the xen hypervisor comms libraries ?
<Mithrandir> jmg: just enable universe and install it?
<jmg> iwj: and also they dont generate a kernel-patch-xen anymore
<iwj> livecd> If you have enough RAM.
<jmg> what about for the xenubuntu dvd?
<jmg> i suppose i can do anything i like there :-)
<iwj> The hypervisor comms libraries are really only used b the stuff in xen-utils; I think it's OK for them to be in the same package.
<iwj> jmg: Sure :-).
<jmg> iwj: yeah the shared libaries and bindings. that's what they said upstream
<jmg> iwj: unless i develop a web frontend for xen for ubuntu-server
<iwj> No, you don't want to call the xen libraries directly, surely.  Just the python modules.
<jmg> which i have been known to do in the past
<iwj> Or better still fork/exec xm whatever.
<jmg> you need to use the c libraries for xenstat
<iwj> Hmmm.
<jmg> luckily nobody uses xenstat
<jmg> yet
<iwj> How stable is the abi ?
<jmg> I just hink its bogus and goes against policy to not seperate
<jmg> it isnt
<jmg> Xen is mostly written by Ian's students
<jmg> They seem to have a tendency to make annoying changes
<jmg> Also the minimum version that should be in Edgy is 3.0.2 and kernel 2.6.16
<iwj> So you want a separate lib package so you can have several things using different c lib abi's ?
<jmg> iwj: No, i dont, but someone else might
<jmg> iwj: I have sufficient powers to split the packages myself if required, but other users may not
<jmg> iwj: On the other hand, since its such a moving target at the moment it is unwise to write anything that doesnt simply hook xm at this stage
<jmg> iwj: Anyone that goes and writes something hooking xenstat does so at their own peril.
<jmg> Abandon all hope ye who enter here, etc.
<Mithrandir> neuralis: revive-tasksel -> drafting, some minor details you might want to look clear up.  Apart from that, I'm happy.
<iwj> jmg: JOOI, who are you ?  :-)   And how much of XenEdgy do you want to do ... ?
<jmg> iwj: im the drafter. give me a job and ill do all of it :-)
<ajmitch> hah
<iwj> jmg: I see.  That kind of thing's not my department, really ...
<jmg> i know
<jmg> *spams hr@canonical.com*
<zul> hey
<zul> iwj: ping
<Kinnison> infinity: ping
<infinity> Kinnison: Sproing.
<Kinnison> infinity: Upload Policy NG -- you're the approver -- feel up to the task?
<iwj> zul: Hi.
<zul> iwj: heylo...i was wondering if you are going to need help for the xen kernel stuff
<infinity> Kinnison: Has it been through review land successfully?
<iwj> zul: Are you Chuck Short ?
<Kinnison> infinity: yes, including sabdfl
<zul> iwj: indeed
<iwj> What kind of help are you offering ?  Certainly help is usually gratefully received :-).
<infinity> Kinnison: Alright, I'll go read it again and make sure it's something I'm confortable signing off on.
<zul> iwj: packaging the xen kernel stuff
<infinity> comfortable, too.
<zul> maintianing it as well
<iwj> zul: That would be very nice, yes, please.
<iwj> Have you read the new XenEdgy page I wrote ?
<zul> yeah i just saw it
<iwj> Excellent.
<pitti> infinity: I'm quite content with my dh_strip-with-super-cow-powers now; do you think we should merge this and pkgstriptranslations to pkgbinarymangler right away, or should we keep separate packages for the sake of modularity?
<zul> ill get a start on it tonight
<pitti> infinity: (I'd favor two packages)
<iwj> zul: Shiny and most excellent.
<iwj> I'm not sure what the state of our xen-3.0 package is (if any) but I'll pick that up on Monday probably and take a look at it.
<_ion> I wish bug #43117 is reconsidered for Edgy.
<Ubugtu> Malone bug 43117 in linux-source-2.6.15 "grsec support in linux-image-server" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/43117
<tseng> _ion: no way
<zul> cool..i have to head off to work but ill talk to you more later
<_ion> tseng: Why?
<infinity> pitti: Does it need a no-act flag, so whacky stuff that builds nested packages doesn't break?
<fabbione> _ion: it's crack and it breaks stuff
<tseng> _ion: there are plenty of reasons that is a bad idea
<zul> iwj: ttyl
<tseng> _ion: I would start at supportability
<pitti> infinity: yes, I'm going to make it respect $NO_PKG_MANGLE
<iwj> zul: ttfn
<pitti> infinity: it doesn't change anything but the .changes file in the source package
<infinity> pitti: That would be the only advantage I could see to having it in one package (so that NO_PKG_MANGLE makes sense as a package-specific flag)
<tseng> _ion: also that breaking up any one bit and sending upstream has gotten resounding rejection
<infinity> pitti: Other than that, I'm indifferent about having it integrated or seperate.
<pitti> infinity: oh, wait, I lied; it changes the .gnu.debuglink in ELFs
<infinity> "Nosferatubuntu"... *giggle*
<_ion> :-D
<infinity> (One of Kinnison's use cases)
<infinity> "Steve, a goth, is leading the Nosferatubuntu project. He requires all uploads to include the word "DEATH" in the changelog in order to pander to his particular neuroses"...
<TheMuso> its at times like this that I love having my IRC sesion on a box at home. :)
<fabbione> infinity: ahha
<Mithrandir> doko: edgy-toolchain-roadmap -> drafting,  FYI
<pitti> infinity: sorry, network went down here
<Keybuk> TheMuso: except you still can't access IRC even then
<neuralis> infinity: re: moving all of revive-tasksel into ubuntu-server-tasks, do we really care, or should i leave it in r-t and update u-s-t to point to it?
<TheMuso> Yeah, but you don't miss out on the action. :p
<infinity> Kinnison: Ahh, that looks much better.  It seems fairly crack-free now.
<infinity> Kinnison: I approved it; can you fill in the estimated time box?
<Kinnison> infinity: I will do so after we've had our scheduling meeting later, thankee
<Keybuk> would anyone care if I made /bin/sh point to dash? :)
<pitti> Keybuk: I use that for ages
* fabbione looks at Keybuk evily
<Kinnison> Many would care, but they probably don't have a good reason
<neuralis> Mithrandir: kamion beat me to fixing up those details
<Mithrandir> neuralis: yeah, I'm looking at it now.
<fabbione> so who is doing reviews?
<Mithrandir> I am
<infinity> Keybuk: When I want bash, I explicitely ask for it anyway.  So, I'd be fine with it as long as we don't find a mess of buggy scripts that break as a result.
<Keybuk> /etc/init.d/rc 2  0.67s user 0.51s system 71% cpu 1.664 total
<Keybuk> ^ dash
<Keybuk> /etc/init.d/rc 2  1.22s user 0.89s system 71% cpu 2.946 total
<Keybuk> ^ bash
<fabbione> Mithrandir: i did put ubuntu-edgy-cluster and sparc64-port as review about 2/3 days ago.. i was wondering if they even appear in the list
<Keybuk> (both third runs)
<fabbione> Mithrandir: clearly i got no feedback (not that there is that much to feedback.. but still)
<Mithrandir> fabbione: they don't
<Mithrandir> fabbione: they're not proposed for uds-paris
<fabbione> Mithrandir: right, that was on mdz input since i was not going to be there.. i guess we will review them after paris than
<pitti> infinity: I regularly fix bashisms when I deal with packages since they'll break on my system, but they are not that common anymore nowadays
<Mithrandir> fabbione: at least I use https://launchpad.net/sprints/uds-paris/+specs as my work queue, but I can certainly look at ubuntu-edgy-cluster and sparc64-port after lunch (which is in about 1 minute)
<fabbione> Mithrandir: in about one minute it will be weekend and i will be heading to the other side of denmark :)
<fabbione> Mithrandir: so we might as well wait after paris
<Mithrandir> fabbione: sure.
<fabbione> thanks anyway dude
<neuralis> pitti: have a second, or are you heading to lunch?
<pitti> neuralis: the latter
<TheMuso> Riddell: You around? it seems that Henrik will be unavailable today, so we want to have the session as on the schedule? If it suits you, I can come to whereever you will be/are going to be.
<Riddell> TheMuso: hi
<Riddell> TheMuso: I'm in a bof just now, I'll come to you when done in half an hour if that's ok
<TheMuso> np
<Hobbsee> hi all
<zul> hey hobbsee
<Hobbsee> hi zul 
<highvoltage> anyone staying at Radisson SAS getting a taxi real early tomorrow morning (like, 4-5am)? can you please /msg me?
<Hobbsee> Mithrandir: nice, thanks
<jsgotangco> heh what time is your flight? 7am?
<Riddell> TheMuso: I've remembered I have a meeting in 5 minutes, so we'll need to do accessibility in an hour at 16:00 (or whenever my meeting finishes)
<TheMuso> Sure thing.
<Hobbsee> Riddell: you've not mastered the art of being in two places at once?  :P
<highvoltage> jsgotangco: yes
<jsgotangco> ugh
<Riddell> two tables is manageable but upstairs and downstairs at the same time is a bit of a stretch
<Hobbsee> hehe
<Hobbsee> Riddell: run very quickly :P  Are you feeling any better today?
<Mithrandir> Hobbsee: Riddell is such a slacker, you know.
<Hobbsee> Mithrandir: :P
<Hobbsee> if Riddell's a slacker, i'd hate to see what you'd say about me.
<Mithrandir> you're not an employee, so I have to be nice to you.
<Mithrandir> ;-)
<Hobbsee> haha right.
<gurumeditationer> I know the way to run 32bit stuff on 64bit ubuntu is to make a 32bit chroot but is there a reason ubuntu doesn't do it like fedora core?
<Lathiat> gurumeditationer: because theres currently no support in our packaging infrastructure to do it as such
<Lathiat> aiui
<Mithrandir> gurumeditationer: because FC is doing it the wrong way.
<gurumeditationer> Mithrandir, what's bad about the FC way?
<Mithrandir> it doesn't scale.
<pitti> gurumeditationer: I installed ia32-libs and could run 32 bit binaries just fine without a chroot
<gurumeditationer> Will it ever get to a point where you can choose to have a 32bit firefox for the 32bit plugins?
<gurumeditationer> I mean as simply as you can with FC, it's the only thing I miss about it
<Mithrandir> yes
<siretart> gurumeditationer: what you are asking for is something called 'multiarch'. it is in the works, but not there yet.
<gurumeditationer> What are the odds of it being in edgy?
<Mithrandir> 0
<gurumeditationer> Does it entail a serious amount of change to the current way ubuntu is put together?
<Mithrandir> gurumeditationer: you might want to read the two pdfs on http://multiarch.alioth.debian.org/
<gurumeditationer> Thanks Mithrandir 
<gurumeditationer> It'd make my life easier to use an ARM development kit, it's something I'd be willing to donate a lot of time to
<Mithrandir> it's a fair bit of work to implement, yes.
<zul> hey mdz 
<mdz> bonjour
<Hobbsee> hi mdz 
<zul> did anyone get a french taunting yet
<Kinnison> infinity: on
<Kinnison> infinity: no even
<simira> did you guys lock up Mithrandir in the cellar again?
<TheMuso> mako: ping
<Hobbsee> simira: guilty as charged.
<simira> Hobbsee: as I now know that you are a girl, I'll have to ask you to put your hands off from my man!
* Hobbsee did not touch him at all.
* Hobbsee used her cattle prod.  they come in handy.
<simira> Hobbsee: then I would like you not to treat him as a cow...
<Hobbsee> hmmm..okay then.
<Hobbsee> simira: FYI, and i'm not sure if you're joking or not, i've got no interest at all in your man.
<simira> Hobbsee: I am not at all worried, really.
<Hobbsee> that's what i thought :P
<Hobbsee> good
<Hobbsee> !
<simira> Hobbsee: you wouldnn't like to be this near me, then ;)
<Hobbsee> simira: hmm?
<simira> Hobbsee: never mind
<simira> I'm off, dialup is tiresome...
* Hobbsee rereads.  hmmm.  i'm not sure that makes sense, but i get the idea :P
<TheMuso> Ok folks. If you need to talk to me about anything to do with my submitted specs or accessibility in general? Now is the time. I will be at at the table that has been known as Kenrik's table for the net 15-20 minutes if you want to catch me before I get ready to leave.
<TheMuso> Ok folks. I'm outa here. Nice to meet you all.
<highvoltage> anyone in the mood for signing keys?
<zul> i thought that said singing keys
<highvoltage> we're signing keys at atlas 2
<Hobbsee> highvoltage: sure, sign mine?  :P
<highvoltage> Hobbsee: aren't you in Sydney atm? :)
<Hobbsee> highvoltage: yeah, so?  :P
* Hobbsee runs away before she gets the lecture on how keysigning must be done in person.
* Hobbsee contemplates getting her key signed on monday.
<RadiantFire> lol
<raphink> Hobbsee: keysigning must be done in person
<giftnudel> it must not, but it makes more sense
<Hobbsee> raphink: hush please.  i've heard that before.  that's why i put the  ":P" at the end of my statements.
<raphink> yeah I know ;)
<raphink> hi mdz
<wasabi_> Hmm. Something messed up my locales.
<mdz> raphink: bonjour
<raphink> :)
<raphink> a va ?
<mdke> anyone in physical vicinity of henrik?
<jdub> not atm
<mdke> jdub: give him a message for me? apparently one of the locoservers (ganges) has gone down with no remote access, and needs a physical reboot. is there is anything he can do from there?<endmessage>
<jdub> mdke: we can't at the moment
<jdub> mdke: perhaps mail the admins instead of henrik
<mdke> jdub: the locoservers aren't in the DC - they are with a provider and only Henrik has access to their control panel, as far as I know.
<mdke> if you tell me the admins have access, great, I'll bug them. 
<jpatrick> mdke: yes, there's a typo in the network configuration
* HiddenWolf does a little dance
<mdke> jpatrick: /query
<duck-> I have a question concerning who to contact with regards the last sentence of this section: https://wiki.ubuntu.com/CommonCustomizations?highlight=%28customiz%29#head-4768d95fc6651390bd90f8ef2dca0a96d856c45e
<duck-> It instructs a representative to contact the development team to discuss a solution.
<duck-> I have need of a customization solution in the technical college I am employed at.
<zul> you might want to talk to canonical directl then
<duck-> ok, thanks
<wasabi_> Jun 23 13:53:55 localhost gdm[4665] : PAM [dlerror: /lib/libresolv.so.2: symbol __res_iclose, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference] 
<wasabi_> uh oh. ;)
<nexu> anyone have a idea why pbuilder tells me :
<nexu>  -> Considering  libboost-filesystem-dev
<nexu>    -> Trying libboost-filesystem-dev
<nexu>        -> Cannot install libboost-filesystem-dev; apt errors follow:
<tseng> please use a pastebin if you must
<tseng> support requests go to #ubuntu
<nexu> i'm trying to make a dist deb
<nexu> not sure or folks there talking about how to login and install firefox can help me
<tseng> the topic says "Ubuntu Development (not support, even with edgy)"
<nexu> than whats the point of this channel if i may ask ?
<tseng> sorry but if we help one person, have to help them all
<tseng> the point of the channel is to discuss fixing bugs in the distro, building new features and such
<nexu> hmm k , i assumed this channel was to help ppl getting into helping to dev on ubuntu 
<nexu> rather than just helping 'users'
<tseng> that is #ubuntu-motu
<tseng> for getting involved
<nexu> k i'll try there
<tseng> the topic says all this, btw
<nexu> thx
<zyga> hi
#ubuntu-devel 2006-06-24
<Hobbsee> morning all
<pschulz01> Morning Hobbsee.
<pschulz01> In there any information on what's been happening in France?
<Hobbsee> hi pschulz01 
<Hobbsee> pschulz01: i think the conference ended, and they just had a final dinner...
<pschulz01> any of the work online yet?
<zul> Hobbsee: and they got drunk and played ping pong?
<pschulz01> :-)
<Hobbsee> zul: probably.  i wouldnt know, i'm not there
<Hobbsee> pschulz01: should be the wiki pages attached to each of the specs
<Mithrandir> no ping pong, but plenty of people got drunk
<pschulz01> Is anyone blogging, or are they all too drunk?
<Mithrandir> I'm blogging and drunk, why?
<pschulz01> Link?
<Mithrandir> http://err.no/personal/blog is my personal "everything I feel like blogging about" blog with both personal stuff as well as technical posts which are syndicated onto other planets.
<Hobbsee> pschulz01: it's around 4am there.  
<pschulz01> Hobbsee: There are lots of people who wsh they were there.. especially at 4am in the morning.
<Hobbsee> oh i know
<pschulz01> Mithrandir: Thanks... 
<neuralis> pschulz01: mako posted some thoughts on newsforge
<pschulz01> Was that the 'part 1'? I saw that,, 
<neuralis> http://trends.newsforge.com/trends/06/06/22/1524249.shtml?tid=138&tid=18&tid=2
<neuralis> it wasn't in parts.
* neuralis goes to pass out.
<pschulz01> Thanks all... happy recovering.
* Mithrandir goes to bed
<Hobbsee> night Mithrandir 
<zul> c ya Mithrandir 
<jmg> iwj
<mon> #kubuntu-devel
<Lathiat> whens the net language pack update?
<Lathiat> or whats the schedule?
<mdke> Lathiat: first monday of each month
<Lathiat> hm ok cheers, not too far away i guess
<mdke> nope, monday after next I suppose
<Lathiat> (theres a nasty bug in the en_AU translation atm that shows 'keyboard label' on every menu with a shortcut item that has been fixed but not released yet)
<Lathiat> ah, hrm
<mdke> Lathiat: there are daily language packs if you can't wait
<Lathiat> yeh thats a while away
<Lathiat> its not even just me it is quite a nasty bug to have for like 3-4 weeks ;p
<Lathiat> hrm where do you get those?
<mdke> at ~pitti
<Lathiat> cheers
<mdke>  deb http://people.ubuntu.com/~pitti/langpacks/daily/dapper-updates ./
<Lathiat> hrm any idea how to debmirror that
<Lathiat> it cant seem to get over the lack of section
<mdke> Lathiat: no idea. Martin will know I suppose
<Pupeno> Hello.
<Pupeno> If I want to play with the installer, that is, trying to add a feature I have in my head... how should I do it ? how should I set it up ?
<jpatrick> Can someone explain what the diff between https://launchpad.net/distros/ubuntu/edgy/+source/kdmtheme and https://launchpad.net/distros/ubuntu/edgy/+source/kcontrol-kdmtheme is?
<neuralis> Pupeno: are you talking about the graphical installer, or the textual (alternate CD) one?
<Pupeno> neuralis: I think my feature is for the graphical one.
<neuralis> Pupeno: the version in dapper is package 'ubiquity', you can grab its source as any other source package
<Pupeno> neuralis: but, how do I test it ?
<neuralis> Pupeno: the bzr branch appears to be http://people.ubuntu.com/~cjwatson/bzr/ubiquity/ubuntu/ but i can't tell if that's fully up to date.
<neuralis> Pupeno: well, depends on how you're planning to change it. it might be easiest to ask colin how he does testing on it, and adopt his workflow.
<Pupeno> neuralis: ok. Thanks.
<neuralis> Pupeno: you can poke him on IRC when he's around (kamion), or mail ubuntu-devel about it; it's sufficiently interesting that i recommend the latter
<Pupeno> Thanks.
<Riddell> jpatrick: one is from kubuntu and one is from debian
<Riddell> jpatrick: I've filed a bug for one of them to be removed
<jpatrick> Riddell: ok
<Hobbsee> hi again all
* Kaloz is trying to install dapper (and then edgy) to an imac g5 revc and update the wiki page about it
<Hobbsee> Kaloz: nice :)
<Kaloz> and then fix thermal management :P figured out some problems already, but now i'm hitting a wall with installation of the base system, and the kernel screams about the installer is trying to access beyond the end of the deivce
<hunger> Any chance of getting an upgraded libglib2.0-dev? It is older than libglib2.0-0 at the moment.
<hunger> in edgy that is...
<Amaranth> hunger: it's probably got some reason it didn't make it to the archive
<Amaranth> hunger: they come from the same source package
<hunger> Amaranth: Yes, I guess so. Is there a way for me to find out what is going on?
<Amaranth> dunno
<Amaranth> it might be in the process of being uploaded to the archive/sent to the mirror
<Amaranth> otherwise if one didn't make it neither would
<hunger> Amaranth: I noticed this a couple of days ago. It should have made it to the mirrors in the meantime:-(
<hunger> Amaranth: Is there a way for "outsiders" to find out where a deb got stuck?
<Amaranth> I dunno, I'm an "outsider". :P
<hunger> Amaranth: Well, I can always build the debs themselves from source:-|
<hunger> Amaranth: Even though doing so feels so gentooish;-)
<hunger> Damn... I can't. The source deb is 2.10.2, just like the deb of the headers. The lib itself is 2.10.3.
<zul> hey
* bluefoxicy upgrades to edgy :X
<mako> tseng: hey dude, i lost you after i got my badge
<tseng> mako: yo
<tseng> mako: i was talking to benm then sorry
<tseng> mako: 10:01 < zakame> ooh new code of conduct
<tseng> zakame: where are you ? :)
<tseng> mako: $ diff -ruN coc100 coc101 | wc -l
<tseng> 32
<tseng> *shrug*
<tseng> i broke the hinge on my laptop, this really blows
<benroot> sfllaw may i please 2u for a few minutes ?
<benroot> introduction:  i'm ben - i have a computer retail shop in south africa.  tommorrow i'm having a meeting with AMD's director for the middle east and africa regarding FlexiGo.  flexigo is Microsofts inistiative for prepaid PC's to developing countries.  I want to try to convince AMD to not only limit the conmcept to the MS O/S but also to give OSS a chance.  I need confirmation form a developer that ubuntu would in principle be willing to
<benroot>  support a 'pay as u go' prepaid facility
<benroot> the concpet is basically that people can buy a PC for an upfront downpmt of 1/3 of the computers value. during the first 800 hrs of operation is limited to the amount of time purchased via a prepaid voucher
<Chipzz> a meeting on a sunday?
<Chipzz> anyway, I think most developers are absent (or not very active) during the weekend
<Chipzz> it may be a while before you get an answer
<benroot> mmm
<benroot> iok in any case i'll make the statement that it would be better to have the preapaid function only in the hardware and independant of the software - so that consumers can have a choice about which operating system the want to use
<benroot> it would however be nice to be able to say that developers is willing to give it a go on linux also.  apparently AMD has developed a chip especially for this purpose.
<HiddenWolf> benroot: most of the developers are coming home from the conference today, might be a while.
<neuralis> benroot: what kind of commitment would you be specifically looking for from ubuntu?
<neuralis> benroot: if it's allocation of developer time and public commitment, you need to mail mark directly.
<benroot> at this stage only a willingness to get involved
<benroot> i don't want the linux community to be left behind shen prepaid pc's hit the market
<benroot> it would be nice to ofer a choice between xp and ubuntu as O/S
<benroot> since it is a MS initiative - they have asked AMD not to deal with me directly
<neuralis> yes, but you need to explain what exactly "a willingess to get involved" means to you.
<benroot> AMD's interest is to sell CPU's and not necesessarily an O/S together.  if the limitation of operation is only in the hardware - and not software dependant it would be great - but if there is some software functionality to be added in order to make the preapdaid system work - then we need a commitment that linux developers will start a project to support the preapaid system
<neuralis> benroot: in the ubuntu world, that commitment can only come from mark; not the developers. 
<neuralis> unless we're talking about spare time, unofficial involvement, which obviously anyone's free to provide.
<benroot> in such a case i can ask AMD tommorrow to keep OSS in mind and give consumers a choice about the O/S
<neuralis> benroot: mark -at- ubuntu.com.
<benroot> AMD's representative in SA phoned me today and informed me that MS has 'ordered' them that they (MS) will take up the initiative and they are not about to discuss the FlexiGo system with me - so we will be discussing 'general' AMD stuff - but i'm in any case going to raise the matter.
<benroot> neuralis:  ok i'll pop mark an email
<neuralis> benroot: BCC me, and i'll pass it on to a couple of other people. 
<benroot> neural:  ok u email plz
<neuralis> benroot: ivan at radian.org.
<sbalneav> Hey jammcq
#ubuntu-devel 2006-06-25
<jcar> <soap opera voice> the role of highvoltage will now be played by jcar </soap opera voice>
<morbidi> hello
<morbidi> I am wondering, where might be the package for one develop applications with opengl ? I am missing the includes... any ideas ?
<crimsun_> that's a #ubuntu question. Start with libgl1-mesa-dev.
<crimsun_> (you'll probably need mesa-common-dev, too)
<bluefoxicy> heh, I'm splitting the lwn article I'm writing in half
<morbidi> hhmm, I asked there, and I already installed libgl1-mesa-dev
<bluefoxicy> one is going to be a prelink security issue (local information leak), the other is going to be a general article on program start time optimizations (including some established ones like -Wl,-O1 and some new ones like direct linking, symbol hash values, and whatever dynsort is)
<imbrandon> where is the daily live kubuntu ? http://cdimage.ubuntu.com/kubuntu/daily-live/current/ <-- thats quite old ( may 31 ? )
<neuralis> bluefoxicy: you're jrmoser, i assume?
<bluefoxicy> neuralis:  jrmoser from what?
<neuralis> bluefoxicy: a contraction of your full name from ubuntu-devel
<bluefoxicy> neuralis:  yeah that'd be me
<neuralis> bluefoxicy: heads-up: though your (long) proactive security in edgy message didn't get on-list answers, there will hopefully be interesting things happening in edgy in that respect.
<bluefoxicy> neuralis:  I'm aware.  There's going to be fortify source and stack smash protection on a few choice services I'm told
<bluefoxicy> neuralis:  I want stack smash protection on everything, eventually... more importantly I'm looking for some sort of policy allowing users to quickly check which packages have stack smash protection disabled before/after installing
<morbidi> thanks guys
<neuralis> bluefoxicy: ssp is getting turned on for almost everything; i'm still looking at what pie breaks (probably will enable it for as many of the ubuntu-server packages as possible), and i have yet to see about getting in chunks of PaX and grsec (ASLR to begin with, capability inheritance, etc).
<bluefoxicy> neuralis:  chunks of pax would be nice, but not exactly necessary.  I favor pax but that battle is very much uphill.
<bluefoxicy> neuralis:  it's possible to get PaX's mprotect() using a few selinux permissions {execstack,execheap,execmem,execmod}
<neuralis> bluefoxicy: well, there's obviously a difference between getting pax chunks in ubuntu, and getting it upstream. i don't care about trying the latter; not my battle to fight
<bluefoxicy> as for ASLR, well... I guess you COULD tweak the in-kernel values but this will occasionally break things here and there (notably oracle, whatever mail client Linus uses); getting heap randomization will be hard (this breaks a few more things, it used to break emacs)
<bluefoxicy> I REALLY want a way to adjust randomization levels at runtime
<bluefoxicy> neuralis:  nods, but remember pax is a big, invasive patch; patching it in and then throwing Ubuntu patches on top of it means that Ubuntu's kernel team has to maintain a kernel that neither looks nor behaves like stock linux
<neuralis> there's no way we're taking all of pax.
<bluefoxicy> splitting it apart is even more work
<neuralis> this is what's still in the air, and pending a discussion with spengler. pitti and i would be willing to go and break up grsec into a bunch of separate patches, if brad would want to keep maintaining things in that way.
<bluefoxicy> but at least then the rest of the distro doesn't have to deal with it (which may not be a bad thing mind you, it'd give a chance to target bugs)
<bluefoxicy> neuralis:  that would be awesome, but you'll have to involve pipacs with that as well.  both of them are on oftc
<neuralis> yeah, we'll see what comes of it.
<bluefoxicy> neuralis:  actually pipacs is fond of the idea of getting the PaX address space randomization infra into mainline.  This will take a bit of clean-up work (i.e. replace TASK_UNMAPPED_BASE with mm->mmap_base where we are NOT using the unrandomized base), but it's a nice looking infra
<bluefoxicy> I managed to kill off every instance of arch_align_stack() with it :)  (pipacs leaves these in, but when pax is enabled they do nothing and pax has no equivalent function)
<bluefoxicy> well, "fond of the idea" => I tried to get mainline to make the ASLR entropy exremely tweakable and pipacs told me to port PaX's aslr into mainline
<neuralis> bluefoxicy: that seems to be the long-term way to go, but i'd like to see more proactive security now, and we won't get a chance to do this kind of radical, potentially-breaking-things invasion into the kernel for a long while, most probably. edgy's perfect for it.
<bluefoxicy> yeah
<bluefoxicy> neuralis:  I specifically attempted to 1) do clean-up (non-breaking); and 2) just change the underlying infrastructure but seed it with the existing values (i.e. in the end the kernel does exactly what it already does, but in a code-cleaner way)
<bluefoxicy> But you're right
<neuralis> are you known in the grsec community? if so, and you want to lead that dialog with brad/pipacs/..., i'd be happy to have you talk to them.
<bluefoxicy> target the distro first, then use that weight to pressure^Wcoerce^Wconvince mainline (I am a terribly vicious negotiator)
<bluefoxicy> ehhh... I get along with pipacs but I'm not exactly their favorite person in the world
<bluefoxicy> I'm currently banned from #grsecurity
<bluefoxicy> the only reason I've been in there the past month is because I changed my identd, which broke the ban
<bluefoxicy> #pax I'm fine in
<neuralis> bluefoxicy: i'll do the talking, then :)
<bluefoxicy> :)
<bluefoxicy> I can still hang around though
<bluefoxicy> oh, there's a gentoo dev that you might like as well
<bluefoxicy> he hangs out in #gentoo-hardened under 'solar'... he's kind of strict, but he knows his stuff
<bluefoxicy> He's dropped conversations with me for mentioning selinux
<neuralis> the first point of contact for me will be brad, and then we'll see where this goes.
<bluefoxicy> nods.  solar may or may not be on oftc at the time, he bounces in and out on there.
<neuralis> if he's unwilling to deal with a bunch of patches, all further conversations are unnecessary, really.
<neuralis> i.e. we're just not patching our kernels with all of grsec, period.
<bluefoxicy> i have doubts spender will do that kind of work, perhaps if you help him do the initial split though he'll be good about it.  Also I would discuss ridding grsecurity of certain things like /proc restrictions in favor of a default policy brought up by gradm2 that implements these globally except for <root,someuid,somegid>
<bluefoxicy> some of those things really can be done in policy, either in SELinux or GrSecurity; it's ridiculous to maintain code modifications for it.
<bluefoxicy> (I told you I'm not their favorite person in the world :)
<neuralis> one step at a time.
<neuralis> are you capable and interested in helping with the split work if we receive a green light for it?
<bluefoxicy> I'm still looking for a real job and not very reliable ;)  Somewhere around here I had split out the basics (i.e. chdir("/") on chroot()) back in 2.4 but
<bluefoxicy> Also yeah one step at a time
<bluefoxicy> the point of mentioning policy artifacts was that it's a reduced amount of work maintaining (unchanging) policy than it is maintaining code (in a changing codebase)
<bluefoxicy> My interests lie partly in reducing the stress of the maintainers, for inertial purposes.
<bluefoxicy> but I do think a little too far ahead
<neuralis> i agree with you, but i have no intention of charging in, guns blaring with requests and suggestions. we'll go slow.
<bluefoxicy> nods.
<bluefoxicy> I like to load the queue for the next few steps and then make notes next to them as things become feasible/infeasible ;)
<bluefoxicy> neuralis:  aside, for humor value, have you read the POSIX definition of chroot()?
<bluefoxicy> I was looking into it to see if it'd be feasible to get mainline to force chdir("/") on chroot(); it's not, the definition specifies that the working directory will not be changed by a call to chroot()
<bluefoxicy> however, it also specifies that "There is no portable use that an application could make of this interface," which I found amusing.  ("we believe this function is useless")
<bluefoxicy> neuralis:  pie, ssp, trying to split up grsecurity, is that it for now?
<neuralis> bluefoxicy: i've read most of posix at one time or another
<bluefoxicy> neuralis:  I should note that I was told (I have not verified the code for this) that it is technically impossible to separate most of grsecurity from the MAC system
<bluefoxicy> i expect you don't want the MAC system
<bluefoxicy> it's permenantly on when anything besides PaX is enabled, and you won't get that split out; practically everything uses it for logging at the very least, and I think some of the stuff in there may be implemented by hacking the ACL system
<neuralis> bluefoxicy: ssp everywhere, pie in a few places, and splitting up grsec; we're looking at a few policy settings, and there's supposedly some ready firewall work
<bluefoxicy> I expect it's literally less work to REWRITE grsecurity's features from scratch, which brings us back to the basic issue that most of that stuff is better done in policy.
<bluefoxicy> firewall
<bluefoxicy> you mean stateful filtering, and a control app besides firestarter?
<neuralis> well, the things we would initially take are things like aslr, capability inheritance, strengthened jails, etc; i suspect most of this doesn't have far-reaching depedencies
<neuralis> bluefoxicy: no, i mean per-package firewall policies shipping with debs
<bluefoxicy> ah
<bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/aslr-patches/  These do not work but I made a good try ;)
<bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/aslr-patches/patch-2.6.17-rc6-tub-mmap_base.diff  In particular Arjan van de Ven says this patch is broken in one or two places, and it's a prerequisite for PaX's aslr to actually work (that is a clean-up patch)
<neuralis> in any case, i have a very good idea of where i'd like proactive security to go in ubuntu, and pitti is largely on board with it. we'll get there eventually.
<bluefoxicy> good.
<neuralis> the bottleneck, as usual, is developer time; this is a place where you (or other capable people you know) are very welcome to help and see some really useful things come of it.
<bluefoxicy> neuralis:  when are you planning on speaking with spender?
<neuralis> bluefoxicy: i'll send a mail today.
<bluefoxicy> neuralis: nods.  I figured you'd pop by on oftc tomorrow or such (pipacs left for today, spender has not talked in a while)
<neuralis> bluefoxicy: i prefer mail for this kind of communication, actually.
<bluefoxicy> neuralis:  I'll see if I can get any interest out of solar.  Last I checked he's got a LOT of stuff to do, some of the tools I use are his doing... he just pops stuff out constantly :)
<neuralis> sure, ping him, but be *careful* in your approach. you're obviously capable of pissing people off, so tread softly; we don't want to gather any ill will for this effort before it even starts.
<bluefoxicy> haha
<bluefoxicy> so blunt ;)
<bluefoxicy> I talk way too much more than anything... and spender got mad at me for asking too many questions
<bluefoxicy> neuralis:  Is there money in it?
<neuralis> bluefoxicy: it could be bounty material. i'll see.
<bluefoxicy> neuralis:  you're not getting any love from spender ;)
<bluefoxicy> solar says he's been asked countless times to split grsec up and he always says no
<bluefoxicy> neuralis:  also bug 49192 needs attention if you in any way intend to apply a strict memory protection policy (pax mprotect() or selinux exec*) because you can't even log into gnome
<Ubugtu> Malone bug 49192 in libgcrypt11 "libgcrypt11 has an executable stack" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49192
<bluefoxicy> neuralis:  Comment 3, patching the .S source files, is the appropriate fix; although comment 4 will produce the exact same results in the end
<neuralis> well, i'm still shooting him an e-mail, and if he's adamant about not breaking things up, perhaps we'll cherry-pick the invariant bits (caps, jails, etc) and leave the rest behind. or just leave it entirely.
<bluefoxicy> nods
<bluefoxicy> have you read the code?
<neuralis> bluefoxicy: a long time ago. i haven't kept up at all.
<bluefoxicy> me either
<bluefoxicy> neuralis:  i'm not interested in hacking it at the moment, right now i'm trying to write a couple articles and see if I can get LWN to buy them off me.  One of which is going to be about a bunch of linker/libc hacks that decrease executable load time (decrease boot time, decrease how long OOo takes to start...)
<neuralis> i'm out for now. cheers.
<bluefoxicy> alright.
<bluefoxicy> I'll take another crack at ASLR some time soon
<bluefoxicy> you have fun :>
<neuralis> that's the plan.
<bluefoxicy> (I would love to see edgy ultra-snappy and ultra-secure, that would break the "{secure,fast,easy} pick 2" axiom, which I've been saying is false for years)
<HrdwrBoB> it is false
<HrdwrBoB> erm, it's not false
<HrdwrBoB> security is a relative term
<bluefoxicy> yes
<bluefoxicy> but there is a perception that it is absolute that each increase in security represents a decrease in performance and usability
<HrdwrBoB> increasing security requires reducing ease of use in many cases
<bluefoxicy> I noticed a Wired article written by a "security expert" who literally said that every time you make something more secure it gets harder to use
<HrdwrBoB> for the most part it does
<bluefoxicy> http://www.hackinglinuxexposed.com/articles/20020917.html
<bluefoxicy> this one talks about ssh being harder to use than telnet
<bluefoxicy> which is really reaching.  It's disruptive for those who already know the system, but it's not harder to use.
<HrdwrBoB> yeah that's a bit of a stretch
<bluefoxicy> HrdwrBoB:  stack smash protection and address space randomization will definitely not make the system "harder to use"
<HrdwrBoB> no, certainly not
<HrdwrBoB> it depends on what 'security' you're talking about
<bluefoxicy> address space randomization, interestingly, was previously used in mainline as a performance tool ;)
<bluefoxicy> HrdwrBoB:  obviously implementing strict mandatory access control and multi-level authentication, authentication time-outs, and the like get in the way significantly
<bluefoxicy> HrdwrBoB:  but that's all authentication and access control; you'll always get in the user's way with those eventually.
<bluefoxicy> My concern is the other side of it.
<HrdwrBoB> yes, which shouldn't interfere with the user
<HrdwrBoB> at least, not in any significant way
<bluefoxicy> Broken programs let you get around the access control system, we've seen those all over the place, how many security-updates does dapper have already?
<bluefoxicy> Increasing the integrity of the system directly by making such holes either non-exploitable or exploitable only in a non-guaranteed manner should be fully transparent to the user
<bluefoxicy> if it's not, you're doing it wrong
<bluefoxicy> anyway
<bluefoxicy> "However my personal favorite is to hire some security consultant to come in and 'fix' things. They come in dictate what needs to be changed and leave. You then have a perfect scapegoat -- the Klingons have fired first, and you're just getting the engines working again"
<bluefoxicy> this guy is brutal :)
<msw> anyone still in paris?
<msw> (other than me)
<rixxon> i don't quite know where to report errors in the repos, so lets do it here. me, and many more, are having problems installing the vmware-player package
<rixxon> here's a copy of my terminal output, http://paste.ubuntu-nl.org/16411p
<Hobbsee> rixxon: see [13:02]  <ubotu> If you find a bug in Ubuntu, please report it at http://bugs.ubuntu.com
<rixxon> Hobbsee: repos count for that? ok
<Hobbsee> rixxon: *every* ubuntu thing counts in that, yes.
<rixxon> heh ok, i'll see if it is already submited or otherwise try to write a report
<Hobbsee> check if it's already reported
<Hobbsee> yeah
<TheMuso> Hey all
* TheMuso flew in this morning, but has just had a few hours sleep. Man long flights aren't fun.
<ajmitch> lucky you :)
<rixxon> hm, several problems with installimg vmware-player seems to be reported
<rixxon> but i'm not sure if this specific issue is covered
<Hobbsee> hi ajmitch and TheMuso 
* Hobbsee sleeps on planes.  far more effective.
<ajmitch> hello Hobbsee 
<Hobbsee> rixxon: if it's not already there, which i think it isnt, then report it at https://launchpad.net/distros/ubuntu/+source/vmware-player/+bugs
<TheMuso> Hobbsee: But it isn't good sleep. It is sleep I agree, but doesn't beat getting into a proper bed.
<rixxon> Hobbsee: i'll do my best, might not be totally professional but hey
<Hobbsee> rixxon: you'll be right :)  make sure you add in that pastebin error too
<rixxon> Hobbsee: the link or the text?
<Hobbsee> TheMuso: that's true
<rixxon> gee is there no "bug reporting HOW-TO" :P
* rixxon getting nervous
<Hobbsee> rixxon: um....you can put in the text i think - it's not that long
* Hobbsee thought there was.
* Hobbsee thought bugsquad did something about htat.
<rixxon> heh
<Hobbsee> breakfast - back later
<ajmitch> Hobbsee: there was
<Hobbsee> ajmitch: and where is it now?
<ajmitch> seems that someone decided to wipe the page on the wiki 
<Hobbsee> ah
<ajmitch> ah nope
<ajmitch> it just took awhile to redirect
<ajmitch> https://help.ubuntu.com/community/ReportingBugs
<rixxon> Hobbsee: will launchpad email me on replies to my report now? (i am listed as subscriber)
<Hobbsee> rixxon: yes
<rixxon> cool
* netjoined: irc.freenode.net -> brown.freenode.net
<dilinger> why can't lilo just shut up?
<Hobbsee> hi StevenK 
* StevenK waves.
* ..[topic/#ubuntu-devel:irc.freenode.net] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | Edgy is Open
* ..[topic/#ubuntu-devel:Hobbsee] : 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
<zakame> tseng: I am here :)
<v6sa> hello
* netjoined: irc.freenode.net -> brown.freenode.net
<Norgz> hello
<nox-Hand> Hey
<nox-Hand> The new GUI installer; It overwrites MBR without asking, whereas the old would ask you. I think this is a mistake, as some people might have a bootloader they wish to keep and edit their own conf from their other Linux operating system :P
<nox-Hand> I dunno, maybe I am the only one with that idea? I just really liked how the text-install nicely asked one, and I think this should be incorporated in the next version of Ubuntu?
<ivoks> nox-Hand: that's what alternate CD is for
<nox-Hand> ivoks, Yes, but not all Linux 'geeks' will wish to do that. I mean, there are some 'newbies' who know how to edit their bootloader, but don't think about making backups. I, for example, when I installed the new Ubuntu Dapper, lost my other bootloader, as noone told me that it did no longer ask. 
<ivoks> nox-Hand: i agree, check if there is a bug about that and if isn't report it
<nox-Hand> Shall do
<ivoks> thanks
<hunger> nox-Hand: Well, the target audience of the graphical installer would not know what a bootloader is in the first place, so I doubt that it will make sense to ask about it.
<ivoks> hunger: well, graphicall installer has couple of more "mbr-grub" related bugs
<hunger> ivoks: So I have read.
<hunger> ivoks: I never used it, so I can not comment.
<ivoks> so, hopefully this is something for edgy
<nox-Hand> Well, with all the nice space there is on the screen, one could write something like: Ubuntu needs something called a bootloader. This is what Windows XP also uses, but the XP bootloader is simply hidden. We can also leave the bootloader out, but then you will manually need to install a bootloader.      |||    We have detected the following Operating Systems on your computer: Windows Xp, Fedora Core 6 and Arch L
<nox-Hand> inux. If these are the only operating systems on your computer, it will be safe to install the bootloader. Continue?
<nox-Hand> (( I don't have those O/S's, just for example ))
<nox-Hand> Where is the Ubuntu Bugzilla anywho?
<ivoks> nox-Hand: launchpad.net
<nox-Hand> ivoks, cheers
<hunger> nox-Hand: ubuntu uses launchpad which is supposed to be better than bugzilla... but has a horrible interface IMHO.
<ivoks> nox-Hand: https://launchpad.net/distros/ubuntu/+bugs
<nox-Hand> ivoks, I found it ;)
<nox-Hand> How hard is it to do translation? I am a british citizen, but I have lived in Denmark most of my life. I am completely fluent in both languages, and I guess I could be of use with translating apps :)
<nox-Hand> (( though I use English Ubuntu, Danish users would probably like some translating ))
<hunger> nox-Hand: There is rosetta on launchpad.net for that.
<nox-Hand> rosetta? Whatever it is, I shall take a look :)
<hunger> nox-Hand: It is a proprietary web-based translation tool developed for ubuntu.
<nox-Hand> Very cool :)
<nox-Hand> An error occurred.
<nox-Hand> I get that when reporting my bug o_o
<sabdfl> nox-Hand: https://launchpad.net/distros/ubuntu/dapper/+lang/da
<nox-Hand> sabdfl, I am already in the group ;)
<ogra> hey sabdfl 
<jsgotangco> sabdfl!
<sabdfl> hey guys
<sabdfl> good stuff, nox-Hand
* jsgotangco just arrived home a few hours ago
<Hobbsee> hi sabdfl 
* Hobbsee doesnt have to use her real name now - yay
<tseng> Hobbsee: ?
<nox-Hand> sabdfl, Glad to be able to help :P
<Hobbsee> tseng: they made us use real names on teamspeak, and gobby by association.
<tseng> i see.
<sabdfl> hmm.. that page should talk about the danish translation team, and it doesn't
<tseng> Hobbsee: how awful
<sabdfl> that's no good
<Hobbsee> tseng: kinda embarassing being the only female, and speaking higher than everyone else :P
<ogra> Hobbsee, well, abbreviating your first name whould have done it, no ? 
<_ion> hobbsee: Use some DSP program that lowers your voice. ;-)
<Hobbsee> ogra: to what?  there arent many names you can abbreviate sarah to, and it wouldnt have disguised the voice :P
<Hobbsee> _ion: heh
* jsgotangco wonders if he still has the strength to go to work tomorrow
<ogra> (indeed still everybody would have heard youre female)
<Hobbsee> jsgotangco: large amounts of caffeine
<Hobbsee> ogra: yeah, darn :(
<ogra> Hobbsee, to s. indeed :)
<Hobbsee> ogra: hah
<fabbione> yo yo
<Hobbsee> hi fabbione 
<ivoks> hi all
<fabbione> hey Hobbsee 
<ogra> hey fabbione 
<fabbione> hi ogra
<jsgotangco> hey fabbione
<fabbione> ogra: how was Paris?
<ogra> you were missed at the smokers OBFs :)
<ogra> *BOFs too
<fabbione> hi tangco :)
<Hobbsee> heh
<fabbione> ogra: i wouldn't have been there anyway
<ogra> stopped ? 
<fabbione> ogra: 5 months ago
* Hobbsee thinks the beer drinking BOF's would be interesting too.
<ogra> wow, kudos !
<fabbione> i also gave away patches and everything else
<fabbione> i used to have always a box of cigarette with me.. i got rid of that too
<ogra> Hobbsee, not for 9 per glass
<jsgotangco> Hobbsee: there werent much, beers were so expensive
<jsgotangco> crazy hotel
<jsgotangco> coke is 4
<Hobbsee> true, i thought you found somewhere else with cheeper beer
<Hobbsee> ouch
<fabbione> Hobbsee: usually hotels are in the middle of nowhere
<ogra> Hobbsee, somewhere else  == 45min train ride 
<Hobbsee> ah...
<jsgotangco> Hobbsee: the nearest pub closes at 8
<fabbione> Hobbsee: it makes the last party evening > *
<ogra> (after 15 min with the shuttle bus to get to the trainstation)
<Mithrandir> fabbione: the last party was > * :-)
* nox-Hand has just translated the pkgconf-freetds package \o/ Whatever the hell it does xD
<Hobbsee> nearest pub closing at 8???  my goodness!
<fabbione> Mithrandir: was taht thursday or friday?
<ogra> yeah the last evening was great fun :)
<jsgotangco> lol
<ogra> friday
<fabbione> Mithrandir: i heard a couple of scary stories
<jsgotangco> hehehe
<fabbione> ok
<ogra> LOL
<Mithrandir> fabbione: Friday.
<Hobbsee> oh yes, do tell
<Mithrandir> fabbione: quite wild, yes.
<fabbione> last i heard was infinity_ being rescued in the hotel bathroom
<ogra> yeah there were some incidents others would find scary *g*
<jsgotangco> there's more
<fabbione> but that was thursday
<jsgotangco> hehe
<Mithrandir> that wasn't the last party.
<fabbione> yeha
<ogra> fabbione, yeah, he fell in love with the bowl and couldnt stop hugging it ;)
<jsgotangco> those are really scary stories
<Hobbsee> do tell
<fabbione> ogra: ahah
<Hobbsee> heh
* jsgotangco wonders if bradb survived the night
<ogra> he did ... i mmet him in the morning
<fabbione> i blame 3 weeks at UBZ for not being in Paris :P
<Hobbsee> fabbione: well, at least you came to a nice city.  why 3 weeks?
<fabbione> Hobbsee: becuase i attended also the Launchpad session.. and the pre-conference syndrome is going to make me father in a couple of weeks ;)
<fabbione> and my wife needs help by now.. she can't cope all on her own
<ogra> we should probably have the distrosprint in copenhagen ;)
<fabbione> ogra: i so hope so
<fabbione> but cph is expensive
<Hobbsee> fabbione: that's true
<fabbione> tho i admit i love to travel and stay longer in different places
<fabbione> it was good to be there
<ogra> fabbione, well, we could put some tents in your garden and call it ubuntu bootcamp ... that would save a lot ;) its summmer then anyway :)
<jsgotangco> ahh it feels nice to see darkness at 7pm again
<Hobbsee> ogra: hehe.  as long as you had some interesting power adn internet stuff
<fabbione> ogra: oh yeah.. i would love that :)
<ogra> i guess fabio has wireless in his house
<fabbione> yeah 
<fabbione> and 6Mn/768
<fabbione> probably more than any other conference
<ogra> and even a local archive mirror ;)
<fabbione> exactly
<Hobbsee> hehe - but gettign that much power?  i guess it'd be possible
<fabbione> Hobbsee: i have power too
<fabbione> about 8KW only for the office
<ogra> Hobbsee, he has his own datacenter 
<fabbione> industrial lines :)
<Hobbsee> nah....i expected you to live without power.  :P  Wasnt sure if there would be enough power to let everyon e have access to a powerpoint
<fabbione> Hobbsee: http://people.ubuntu.com/~fabbione/office/
<fabbione> yeah there is enough power :)
<Hobbsee> *eyes widen*
<Hobbsee> got enough ports on that switch there?
<fabbione> i have other 3 switches like that one :)
<fabbione> just not mounted
<fabbione> there are 2 closets full of equipment in the rest of the house
* Hobbsee laughs at the pathetic little mess of cables, compared to our huge mess :P
<ogra> do you have the closet *in* your office ?
<fabbione> ogra: one in the office
* ogra imagines you need earplugs there
<fabbione> the other is in the baby's room
<ogra> heh
<fabbione> ogra: more like airconditioning
<ogra> that as well
<ogra> my cabinet is horribly loud ... i didnt use it in this house ... in the new one i'll have a separate cellar for it ...
<StevenK> Hobbsee: You should see the switch at work ...
<Hobbsee> heh
<nox-Hand> laters
<Hobbsee> we only have two computer geeks in our household, so dont get the opportunity for much of this.
<StevenK> Hobbsee: I have a 16 port Gigabit switch about 4 meters behind me.
* Hobbsee shakes her head.  wow.
<StevenK> Hobbsee: Don't make me jump on you. :-P
<Hobbsee> bleh.  think that'll happen anyway.
<StevenK> Hobbsee: Stop seeing through my plans!
* Hobbsee hides behing the big strong ajmitch 
* StevenK topples over the idle ajmitch.
<Hobbsee> fabbione: must say, that's a very impressive office.  and i take back what i said about having enough power.
<Hobbsee> & internet connectoin
<fabbione> :)
* Hobbsee was expecting a "normal" sort of office - like dad's, which wouldnt fit a few servers, and other assorted bits and pieces.
<ogra> well, that *is* a normal office for real geeks :P
<fabbione> Hobbsee: i am planning some changes in time.. 
<fabbione> like using the garage for racks
<fabbione> and keep only a couple of workstations in the house
<Hobbsee> haha - right
<Hobbsee> ogra: now that's kinda scary - cos that probably makes me more of a geek than dad?
* ogra admittedly only has one cabinet though
<Hobbsee> hehe
<Hobbsee> just an extra big one.
<StevenK> Hobbsee: You have more geek bragging rights than your father since you use Linux.
<ogra> nah, not bigger than one of fabios
<Hobbsee> heh
<TheMuso> Hey all.
<Hobbsee> hi TheMuso 
* TheMuso is about to have a very early night, but thought to check in to let you all know he arrived home safely.
<ogra> hey TheMuso 
<ogra> good to hear that
<TheMuso> Hey ogra. Was Friday night fun? I wish I was there for it. :)
<Hobbsee> TheMuso: yay :)  (very early?)
<ogra> yeah, a lot of fun
<ogra> you missed a very nice dinner
<TheMuso> Now thats enough to get annoyed about. :)
<ogra> yeah, was very much needed after the hotel food
<TheMuso> Hobbsee: My intension is to be in bed by 10PM.
<Hobbsee> TheMuso: good luck!  run!
<TheMuso> After flying in at 6:30AM this morning and a 13 hour flight.
<highvoltage> hey ogra. recovered from paris? :)
<TheMuso> Hey highvoltage.
<ogra> not really yet ...
* TheMuso has a screwed up throat from the dry air on the plane.
<highvoltage> TheMuso: hey! glad to hear you're home safe :)
<ogra> but i'm not home yet either ... sitting in the old house between tons of packed boxes ...
<TheMuso> heh
<Hobbsee> ogra: um, why?
<highvoltage> ogra: ah, just caught up with scrollback, hope things get sorted out easily on that side.
<ogra> Hobbsee, because i'm moving 
<ogra> highvoltage, me too ... 
<Hobbsee> ah.  didnt expect that right on the end of the conference.
<ogra> Hobbsee, started before the conference ... but the old house is half way to the new one from paris ... so i have to be here to open the house for my landlord so he can show it to potential successors
<jsgotangco> TheMuso: same here, i can still taste the plane food
<Hobbsee> ogra: right.
<jsgotangco> TheMuso: you missed some very nice memory-worthy incidents after dinner as well
<TheMuso> hehe
<TheMuso> The food was alright, but the dry air wasn't.
* ogra would be happy if he could wipe some of these from his mind :)
<jsgotangco> hahaha
<TheMuso> Anyway, must be making a move. Talk to you all later, and thanks for what was for me at least, an absolutely awesome week! Oh and if someone could fill me in on the status of Henrik, that would be much appreciated. Thanks again.
<shawarma> TheMuso: "the status of Henrik"?
<ogra> hey shawarma 
<shawarma> ogra: Hola!
<jsgotangco> shawarma: henrik wasn't feeling well the last 2 days
<jsgotangco> that's why he wasn't anywhere on sight
<shawarma> jsgotangco: I see. I didn't really realise it was that bad.
* ogra didnt know heno was bad
<tseng> hi ogra 
<ogra> hey tseng 
<asac> iwj: ping
<eitch0000> how can I create new linux-restricted-module package compiled against a new kernel?
<uniq> are there buildd/sbuild/wanna-build packages for ubuntu, or are the debian ones beeing used? 
<robertj> wow has freenode been massively "ownz0red
<highvoltage> there was an announcement earlier about tests being done on the network.
<bddebian> Heya gang
<highvoltage> hey bddebian 
<bddebian> Heya highvoltage
<highvoltage> what's up?
<bddebian> Nada, you?
<highvoltage> trying to blog about uds paris, but i don't know where to start :)
<bddebian> Heh
<Didius> Hi
<Didius> Question: I've started making a physics programm, in Java. I would like it to become open source when it's done.
<Didius> 1) is Java a good language for open-source projects
<Didius> 2) should I distribute it at edubuntu.org?
<shawarma> Didius: It kind of defeats the purpose of being open source if you require a non-free java to run it, so you need to make sure it runs with a free Java. Preferably gcj.
<Didius> ok thnx
<shawarma> Didius: ...but as to whether or not it's a good language for open source projects, you need to define good.. "Good" can mean that there are many developers that know the language so that it'll be easier to find more devs. It can mean that it'll be easy to run in many environments. It can mean that it adds few dependencies..
<Didius> well I want it to run in linux/windows and mac os
<mjr> yeah, that's basically the issue you have... Recommend not using AWT or Swing for the GUI, they are generally the bigger problem in getting programs to work with free java implementations... SWT and Java-Gnome would be options.
<mjr> well, SWT then, better portability
<shawarma> Didius: Python is gaining a lot of momentum and is in many cases the preferred language of new stuff in Ubuntu.
<Didius> mjr: ah that's intresting
<shawarma> Didius: I'm not sure how computationally heavy your program is, but depending on that you might choose a lower level language for the most demanding bits.
<shawarma> Didius: But if you're most comfortable with Java, just go for that. 
<Didius> well actually I'm kinda new in java. But the program is fairly simple. Just ordinary radiobuttons, checkboxes etc.
<shawarma> Didius: Better to have the software working and in good shape than trying to make everyone use technology they're not comfortable with.
<mjr> Didius, and, of course, it would be helpful if you tested it with a free java environment such as gcj all the while during developing
<Didius> ok, thnx
<mjr> if you're doing mostly standard core java and the gui with swt, it shouldn't be difficult to have it working that way
<mjr> (well, standard and "standard", but anyway)
<Didius> if it's done i will return here to ask where I should release it (sourceforge, ...) Thnx for the info already
<Didius> bye
#ubuntu-devel 2007-06-18
<Hobbsee> morning all
<desrt> good evening
<Hobbsee> :)
<Hobbsee> er, afternoon
<desrt> since you're clearly unaware of what the time is there, we shall use my timezone.
<Hobbsee> heh
<Hobbsee> apparently it's 2pm
<Burgundavia> hello people
<desrt> and... uh... "good morning"
<desrt> (technically)
<Hobbsee> hi weaselboy
* Hobbsee ducks
<desrt> i think you mean beaverboy
<Hobbsee> ahhh...a new name!
<desrt> the beaver is a proud and noble animal
<Burgundavia> indeed
<calc> Hobbsee: good evening :)
<Hobbsee> heya calc!
<calc> its 11:14pm ;)
<fabbione> morning guys
<Hobbsee> morning fabbione!
<fabbione> hey Hobbsee 
<desrt> fabbione; 'sup?
<fabbione> desrt: not sure.. i will tell you once i am awake
<desrt> you type well for a sleeping person :)
<Hobbsee> it's a skill
<LongPointyStick> In the ancient words of our leader, "Oh Shit."
<StevenK> LongPointyStick: Hum?
* LongPointyStick seems to not have mastered "rm"
<pitti> Good morning
* StevenK waves to pitti
<pitti> hey StevenK, how are you?
<StevenK> pitti: All told, I'd rather be at home than working, but what can do you do? :-)
<StevenK> s/can do/can/
<pitti> :)
<Hobbsee> morning pitti 
<pitti> hey Hobbsee 
<Hobbsee> oh impressive.
* Hobbsee has now found a bug.
<dholbach> good morning
<pygi> morning dholbach 
<dholbach> hi pygi
<Hobbsee_> ....
<Hobbsee> okay, the patch that stopped my system hanging in xorg 7.2 clearly wasnt taken for 7.3
<Burgundavia> Hobbsee: it might have been one of the fedora ones that was just dropped
<Hobbsee> Burgundavia: it was one that was written in one of our bug reports.
<Hobbsee> i'll have to look it up later
<Hobbsee> it just hangs X - everything else still works
<Hobbsee> so, X hardlocks, but music, etc, keeps playing.
<Burgundavia> I have been having an issue with NetworkManager hard locking my system
<Burgundavia> seems to only happen on resume
<Hobbsee> bug #60288
<ubotu> Launchpad bug 60288 in xorg-server "xorg segfaults in libglx.so(__glXleaveServer+0x22)" [Medium,In progress]  https://launchpad.net/bugs/60288
<Hobbsee> that's the one.
<ccm> *moan*
<dholbach> hey ccm
* dholbach hugs Hobbsee
* Hobbsee hugs dholbach 
* Hobbsee runs around like headless chool
<Hobbsee> er, chook
* Hobbsee --> work.  bye all!
<ccm> hi dholbach 
<dholbach> seeya Hobbsee
<cotyrothery> hey 
<cotyrothery> can someone help me out im new to c++
<cotyrothery> im trying to learn it so i can help with ubuntu
<Burgundavia> cotyrothery: what are you trying to help with?
<cotyrothery> programming the core and anything else 
<cotyrothery> i really have no clue were to start
<Burgundavia> ahh
<cotyrothery> im guessing you guys are experts
<Burgundavia> cotyrothery: if you are not a prorammer, I would start with python
<cotyrothery> why not c++
<cotyrothery> what is python anyways?
<Burgundavia> cotyrothery: python is simpler to learn and a lot of GNOME is coded in it
<cotyrothery> ok
<cotyrothery> so were are tuts on it
<popey> morning all
<Burgundavia> python.org  will get you going
<Burgundavia> popey: did you see that email for that dude?
<popey> cotyrothery: there is a freely downloadable book called "Dive Into Python", it's pretty good
<popey> yes Burgundavia, wanted to say "thanks" - I think ;)
<cotyrothery> ok
<cotyrothery> were can i get it
<Burgundavia> popey: it that still isntalled by default?
<Burgundavia> is, rather
<RAOF> cotyrothery: google says http://www.diveintopython.org/
<popey> dunno, but it's easily googleable
<cotyrothery> i would have used google but i have a lot of stuff running
<cotyrothery> and my computer is going a bit slow
<cotyrothery> so once i learn python do i move on to c++
<cotyrothery> because i have a book on c++
<RAOF> cotyrothery: If you're interested in KDE development, you'll want to know C++.  Apart from that, I don't know of many Gnome projects using it, frankly.
<cotyrothery> oh ok
<cotyrothery> so i should learn c
<cotyrothery> doesnt gnome use c also
<RAOF> Yes.
<cotyrothery> thats what i thought
<RAOF> But mainly for the underlying libraries.  A lot of the GUI stuff is python.
<cotyrothery> ok
<cotyrothery> how long would it take the avg. person to learn and understand python
<RAOF> I don'
<RAOF> I don't know the average person :)
<RAOF> But probably on the order of a day or so, if you already know how to program.
<RAOF> You won't be a python god after a day, but you should be fairly productive.
<cotyrothery> ok
<cotyrothery> cool
<RAOF> If you're trying to learn programming at the same time, it'll take a bit longer :)
<cotyrothery> so are most of you guys programers for ubuntu
<pitti> cotyrothery: right; it takes years to become a really good programmer (which is independent from the language), but it only takes a couple of days to learn a new language
<cotyrothery> ok
<cotyrothery> i knew that
<cotyrothery> so it will take me awhile before i can prog. for ubuntu
<pitti> cotyrothery: nevertheless, if you want to help with Ubuntu you don't need to be a highly skilled programmer; there are lots of things you can help with that do not require programming at all, and lots of things which only require basic understanding of e. g. C or Python
<pitti> cotyrothery: e. g. fixing bugs, searching patches and apply them to packages, etc.
<pitti> cotyrothery: the best way (IMHO) to get into Ubuntu development if you don't (yet) have a clear focus is to start with a few itches you experience yourself, get used to the bug tracker and bug triage, and fix them
<cotyrothery> ok
<pitti> cotyrothery: those can be very simple things, like fixing typos or improving documentation, or mediating with upstream and take their patches
<cotyrothery> but ubuntu is so great i have never experianced any bugs
<pitti> cotyrothery: that's much more motivating than starting with the most complicated things :)
<cotyrothery> pitti: good
<pitti> cotyrothery: uh? we have some 30.000 of them :)
<cotyrothery> really?
<cotyrothery> i never would have know
<cotyrothery> n
<pitti> cotyrothery: that's the number of open bugs in the bug tracker
<cotyrothery> wow
<pitti> cotyrothery: of course nobody knows the number of bugs that are actually in Ubuntu :)
<cotyrothery> I wonder how they effect me
<pitti> because that is (1) impossible to define and (2) impossible to count
<RAOF> Although a lot of computer science attempts both :)
<pygi> in effect to no.2 ) too many of them ^_^
* pygi hides =)
<cotyrothery> I hope it will be fun programming for ubuntu to help the people
<pitti> cotyrothery: btw, https://wiki.ubuntu.com/ContributeToUbuntu is a good entry point
<cotyrothery> its so cool to have the chance to do something like this
<pitti> cotyrothery: fun> you bet!
<cotyrothery> what have you done for it
<pitti> cotyrothery: as I said, start with very simple things to get used to the process, packaging, patching, etc., and slowly evolve to the more difficult things
<cotyrothery> will do 
<cotyrothery> will i need the source
<RAOF> Depends on what you're trying to do, but generally, yes.
<RAOF> You might want to hang around in #ubuntu-motu, actually.
<RAOF> That's a good place for people wanting to make stuff better :)
<RAOF> We should (hopefully) be able to answer packaging questions, etc.
<cotyrothery> ok
<cotyrothery> but what do you guys do here
<cotyrothery> like are you the main prog. of ubuntu
<pitti> cotyrothery: see topic; we coordinate development issues
<pitti> cotyrothery: btw, it would be too much credit to give us to call us 'main programmers'
<cotyrothery> oh
<pitti> cotyrothery: as distribution developers we mainly focus on packaging and integrating
<RAOF> And the main work of Ubuntu is not really programming; that's what all the various open-source projects are for :)
<cotyrothery> ok
<cotyrothery> Im taking a guess here but i have a long way to go and a lot of work to go through
<RAOF> Much of what needs to be done is to take the work of others (upstream projects) and package it in a form that works well in Ubuntu.
<cotyrothery> oh i see
<cotyrothery> so make prog. that dont work for ubuntu work for  ubuntu?
<RAOF> Almost all open-source software is not "for Ubuntu", it's for everyone.  Firefox, Xorg, Gnome, KDE, etc.
<pitti> cotyrothery: well, "don't work" -> "make it work out of the box, and integrate well with other programs"
<cotyrothery> yea
<cotyrothery> ok
<cotyrothery> i see now
<Tonio_> pitti, seb128: uploading network-manager 0.6.5
<pitti> yay!
<Tonio_> pitti: the applet package will end in NEW as discussed on friday.
<seb128> Tonio_: cool!
<seb128> k
<seb128> I'll review it
<Tonio_> pitti: also, that'll inlude changing the seeds, as the package name changes
<pygi> seb128, do you have a sec?
<seb128> pygi: don't ask to ask
<Tonio_> I also repackaged/update the pptp, openvpn and vpnc plugins
<pygi> seb128, I need bug #119725 changed to wishlist
<ubotu> Launchpad bug 119725 in brasero "Have pre-defined preference for burning .iso packages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119725
<pygi> seb128, I didn't ask to ask :)
<pitti> Tonio_: no problem; give us a poke here, we'll update it
<pygi> seb128, I asked a direct question :P
<cotyrothery> python is a lot more technical than c++ from what i see
<Tonio_> pitti: oki
<seb128> pygi: well, I have a second or not, depending of what you want :p
<seb128> pygi: changed
<pygi> seb128, thanks ;)
<seb128> you're welcome
<seb128> pygi: I don't really understand the bug though
<seb128> pygi: is there different iso mimetypes?
<RAOF> cotyrothery: Want to take this to #ubuntu-offtopic or #ubuntu-motu now that there's some traffic in here?
<pygi> seb128, nobody does. Shirish is always making troubles, everywhere
<pygi> seb128, ask Hobbsee when she's around :-/
<pygi> seb128, nop, not really :)
<seb128> so it should be Needs Info
<pygi> perhaps even refuse bug but meh
<seb128> hum
<pygi> personaly I'd refuse the bug =)
<seb128> pygi: could you add a comment and I'll Needs Info or Reject it according to it
<pygi> seb128, kk
<pygi> seb128, will do right now
<seb128> cool
<Tonio_> seb128, pitti should be in new now
<pitti> Tonio_: uh, source new? how that?
<seb128> pitti: the applet is a new tarball
<pygi> seb128, done, :)
<pitti> seb128: ah, right
<Tonio_> pitti: the standard new queue for new packages
<Tonio_> pitti: talking about network-manager-applet
* pitti cranks up his script to purge a gazillion MB of obsolete CoreDump.gz bug attachments
<pitti> Tonio_: right, thinko; ignore me
<pygi> how am I supposed to get anything out of bug #120927 o.O
<ubotu> Launchpad bug 120927 in brasero "[apport]  brasero crashed with SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/120927
<seb128> pygi: bug closed
<pygi> seb128, thank you :)
<seb128> you're welcome
<pygi> too much thanks today :P
<seb128> pygi: http://launchpadlibrarian.net/8111099/Stacktrace.txt
<pygi> doesn't hurt I guess :)
<seb128> that's what you got from retracing
<pitti> pygi: first_element=0x2 -> that looks wrong
<pitti> (as a pointer)
<pitti> pygi: unfortunately the rest of the trace is not recoverable
<pygi> pitti, hm, right
* pygi still has to get used to apport stuff
<seb128> or brasero-dbgsym didn't get installed
<pygi> seb128, a question
<pygi> if there was a replacement ever written for n-c-b would it be *too* important to be api-compatible with libnautilus-burn?
<pygi> (I do understand that some applications still use it --> perhaps a compatibility layer?)
<seb128> yeah, would be nice to have a compatibility lib
<pygi> k, got it
<pygi> seb128, I filed a bug 6 months ago in gnome, and tried to contact n-c-b authors without any success
<pygi> http://bugzilla.gnome.org/show_bug.cgi?id=384540 
<ubotu> Launchpad bug 6 in rosetta ""next 10 entries" at bottom of page" [Medium,Rejected]  https://launchpad.net/bugs/6
<ubotu> Gnome bug 384540 in cd-burner "Libburn/libisofs backend" [Enhancement,Unconfirmed]  
* pygi thinks that's bugging for more then a sec
<seb128> pygi: that's the sort of bug where you have better to send a patch and argue why it would be better than the current code which is working for most users
<pygi> seb128, I would be ofcourse ready to submit a patch. But the patch would change almost entire n-c-b code, which I believe would be a problem
<seb128> you better start a discussion on the GNOME desktop-devel-list on why you think libburn would be better than libnautilus-cd-burner then
* pygi will see
<lithiumX>  does anyone know where tour applications go when their installed?
<pitti> lithiumX: "dpkg -S <packagename>" will print you a list of files; and please ask that in #ubuntu (see topic)
<pitti> lithiumX: erm, dpkg -L, I mean
<lithiumX> oh ok thank you
<pitti> Tonio_: did you set up the build-deps of the n-m plugins tight enough for 0.6.5?
<Tonio_> pitti: yes
<Tonio_> pitti: they all builddep on >= 0.6.5 version
<pitti> Tonio_: cool, thanks
<Tonio_> that's a requirement for them to work with the latest Knetworkmanager
<pitti> Tonio_: out of interest, why did you rename network-manager-gnome to network-manager-applet?
<pitti> why not just keep the old name?
<pitti> Tonio_: rest of package looks fine
<Tonio_> pitti: well I renamed simply to have the deb name the same that upstream name
<Tonio_> pitti: looks like upstream calls the applet "network-manager-applet"
<pitti> Tonio_: hmmkay; renames are always painful, that's why I ask
<pitti> Tonio_: anyway you still need to build network-manager-gnome as a transitional package, until the next LTS
<giskard> LTS?
<pitti> Tonio_: can you please add that and upload again? (or just leave the old name for now)
<Tonio_> pitti: pittiwould you prefer network-manager-gnome ?
<pitti> Tonio_: for dapper -> next LTS upgrades
<Tonio_> sure will change that
<pitti> Tonio_: personally I find -gnome better; first, it's really for gnome, and second it avoids the name change
<pitti> Tonio_: but I'll leave that decision to you
<pitti> Tonio_: I reject the current upload, so please reuse the version number
<pitti> Tonio_: (note that you can leave the source package as -applet, and the binary package as -gnome, too)
<Tonio_> pitti: sure
<Tonio_> pitti: ust discovered a little issue concerning networkmanager/gnome and the vpn part
<Tonio_> pitti: an issue in the way upstream splitted the sources
<Tonio_> pitti: I'll take care to package the applet the same way that the debian maintainer, we just discussesd about that, so reuploading the package might take a bit of time
<Tonio_> maybe toonight or tomorrow
<pitti> Tonio_: that sounds fine
<pitti> Tonio_: taking the same name as Debian is much more important than upstream's or our preference :)
<pitti> Tonio_: if the old applet works with the new daemon, that should be fine
<Tonio_> pitti: well it is not only a problem with the name :)
<pitti> Tonio_: right, I understand; just mentioning it
<Tonio_> pitti: the problem is that the split is only partial in fact, some of the gnome datas are still in the backend tarball..... so as a result we might need 2 packages for the gnome part, so 2 names.....
<Tonio_> mbiebl: sounds like we need to be sure we're doing this the same way so please ping me when you're arrond :)
<pitti> Tonio_: you mean that the daemon package builds the 'other part' of the applet?
<Tonio_> arround
<pitti> that would be nasty
<Tonio_> pitti: yes, it builds the vpn-properties for example which is part of the gnome part....
<Tonio_> pitti: means would could have as a result a network-manager-gnome and a network-manager-applet depending n-m-gnome
<pitti> ugh, indeed that should be avoided
<Tonio_> pitti: another option (dirty) is to merge the 2 tarballs...
<Tonio_> pitti: what would you suggest in that case ?
<pitti> Tonio_: copying the gnome relevant bits into the -applet/-gnome orig.tar.gz doesn't sound too bad, as long as the split will be finished upstream eventually
<pitti> Tonio_: or keep the bits in the main package and teach dh_shlibdeps to ignore the gnome dependencies
<Tonio_> hum, so doing this in the form of a patch then
<Tonio_> talking about the first option of coruse
<pitti> we don't want to keep such a patch forever, so it should only be copied if upstream will split it properly
<Tonio_> sure
<Tonio_> pitti: isn't iproute installed on the buildd machines ?
<fabbione> Tonio_: why would it be installed by default?
<Mithrandir> apt-cache show iproute | grep Prio
<Mithrandir> Priority: important
<Mithrandir> so no, it won't be there by default
<Tonio_> Mithrandir: hum okay
<Tonio_> fabbione: just asking since it was installed in my pbuilder chroot
<Mithrandir> it shouldn't be.
<Tonio_> fabbione: so I missed a builddep because of that :)
<fabbione> Tonio_: pbuilder chroots != debootstrap --variant=buildd
<Tonio_> fabbione: indeed
<simira> fabbione :) How's the family?
<fabbione> Tonio_: best is to use the latter if you are checking for B-D
<fabbione> simira: hey there... growing :)))
<fabbione> simira: but fine i guess
<simira> fabbione: I heard that...busy times
<fabbione> simira: yeah...
<simira> has nr. 2 arrived yet?
<fabbione> simira: nah... mid-dic
<simira> ok
<StevenK> Hrm. Apport retracing seems to have gone crazy
<pochu> New feature ;)
<shawarma> StevenK: No, pitti has been cleaning house.
<shawarma> StevenK: ..assuming you're referring to the load of lp e-mails about removed attachments?
<pitti> StevenK: sorry that Malone sends bug mail spam for attachment removals
<StevenK> And six mails that looked virtually identical.
<Tonio_> pitti: n-m ftbfs due to missing iproute, I'll wait for a solution with the split problem to reupload now...
<pochu> They might be dups...
<pitti> Tonio_: sure, if you think that's better
<pitti> Tonio_: curious, though, iproute as a *build* dependency strikes me as pretty mad
* pitti -> lunch, bbl
<Tonio_> pitti: configure checks for it, that looks to be new with that version....
<Mithrandir> pitti: some configure scripts try to detect paths and such for it.
<pitti> ah, that makes sense
<StevenK> Mithrandir: How debconf?
<StevenK> How's, even.
<Mithrandir> StevenK: iz good.  Lots of interesting discussions
<pochu> pitti: the problem is that 90% of coredump removals are duplicates.
<pitti> pochu: what do you mean with 'duplicate removals'? what's the problem?
<adam0509> hi, I'd like to know if a package for "Linux2.4 kernel with debian patches" will be available for next LTS release ?
<ogra> ubuntu never supported 2.4
<ogra> so thats very unlikely
<adam0509> I don't ask about a pre-compiled kernel, just a package containing a 2.4 kernel for compiling
<adam0509> because kernel.org kernels aren't very adapted, and If you try to add ALSA (from package alsa-source) then you get errors
<pygi> that would be source package
<pygi> doubt it
<pochu> pitti: e.g. for Bug #85776, apport is removing the Coredump for the 118 dups, and malone sends the messages... which means a lot of 'spam' even if you're just subscribed to that bug, or to any of the duplicates
<ubotu> Launchpad bug 85776 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV on package installation, valgrind log required" [High,Confirmed]  https://launchpad.net/bugs/85776
<pochu> pitti: for example some people reported one of those dups, and I don't think they want to receive 119 messages saying a Coredump has been removed ;)
<pitti> pochu: oh, right, you mean the spam
<pygi> pochu, agreed :P
<pygi> pochu, network manager :P
<pochu> Yes. I don't care that much (I just mark it as unread), bug as dholbach's said on -bugs, 'how many people will unsubscribe from random -bugs@ lists after that'
<pochu> pygi: that and the gnome-panel, yes ;)
<pochu> Luckily, this is the consequence of the first run, and won't be that much
<pochu> Mostly because apport is still disable :)
<pygi> pochu, hm ... good thing it's not enabled then :P
* pygi will brb
* Starting logfile irclogs/ubuntu-devel.log
(StevenK/#ubuntu-devel) pitti: Ta
(StevenK/#ubuntu-devel) pitti: I might need to fix it anyway, it appears in the cruft list, too
<StevenK> It does, it explicitly wants libsnmp9-dev
<pitti> StevenK: hm, any idea what heartbeat vs. heartbeat-2 is all about?
<luisbg> hello all
<StevenK> pitti: No, actually, although amusingly, heartbeat's version is larger than heartbeat-2's.
<luisbg> all my mails to the ubuntu-devel mail list need to be approved by a moderator before going through, can I ask somebody to grant me straight through access?
<pitti> StevenK: indeed, heartbeat-2 was removed from Debian
<StevenK> Kill it!
* pitti kicks
<StevenK> Yay!
<Hobbsee> luisbg: you're looking for cjwatson.  and often the answer to that is "no" if you're not part of ~ubuntu-dev
<siretart> pitti: sorry, my bad, the package isn't NBS. it's just not on launchpad's source package site
<luisbg> Hobbsee, oooh ok, just wondering, I'll ask when I'm part of that team =)
<siretart> pitti: it is an empty convinience package for faciliating support. I hope nothing depends on it
<StevenK> pitti: I need to make changes to openipmi, but I'm not sure if I should set the Maintainer to MOTU or core-dev. :-)
<pitti> siretart: cprov currently looks for the reason why the latest version isn't in the archive, but that's an unrelated problem, as it seems
<siretart> cprov: btw, I didn't get an ACCEPTED mail for my last ppa upload. the package got built anyway hoever
<shawarma> StevenK: Huh? heartbeat is 1.2.5-4, while heartbeat-2 is 2.0.8-2?
<StevenK> shawarma: Binary, the source is the DEPWAIT
<StevenK> s/the //
* shawarma crawls back under his rock
<StevenK> Heh
* Hobbsee removes shawarma's rock
<shawarma> Aw..
<Hobbsee> no rock for you.
<cprov> siretart: when was it ?
<pitti> StevenK: erk, opemipmi is not a trivial package at all
* Hobbsee then places it in australia, and names it Uluru #2
<StevenK> pitti: I saw that.
* shawarma sulks
<StevenK> pitti: heartbeat isn't in a position to be demoted?
<fabbione> hmmm
<fabbione> do we really want to support hearbeat?
<cprov> siretart: check your spams -> '20:40:09 DEBUG    Recipients: Reinhard Tartler <siretart@tauware.de>'
<pitti> siretart: got it; libxine1 is in binary NEW
<pitti> siretart: for the -doc package
<StevenK> fabbione: ubuntu-dev doesn't want to either. :-P
<siretart> pitti: right.
<pitti> fabbione: not for my sake; we haven't touched it much
<StevenK> pitti: Shall I leave heartbeat/openipmi alone for a little while?
<fabbione> hmmm
<fabbione> the only 2 interesting bits that Suggets it are ipvsadm
<pitti> StevenK: yes, please; just start with the other rdeps while we sort this out
<pitti> fabbione: no reverse deps, I already checked that
<fabbione> and possibly drdb
<fabbione> yeah
<fabbione> Suggets:
<shawarma> fabbione: It's my impression that it's still the canonical (no pun intended) HA software?
<StevenK> Hah
<fabbione> shawarma: nope...
<StevenK> To be honest, given we use heartbeat at $WORK, it's a piece of crap. :-)
<pitti> hm, why is it in main in the first place? I don't see a seed for it
<fabbione> the canonical cluster is redhat-cluster-suite and/or ocfs2-tools
<fabbione> pitti: i think we did drag it in main because at the time we had no RHCS
<fabbione> (or ocfs2-tools for the matter)
<fabbione> this is probably warty history in the seeds
<pitti> fabbione: I mean, can you point me to a seed or reverse dependency that keeps it in main? I don't see one
<shawarma> fabbione: Hmm.. I don't know anyone who uses rcs, actually. I know a few who use heartbeat (and so did I when I needed that sort of thing).
<StevenK> heartbeat has always been in main, according to LP
<fabbione> pitti: pre-warty.. afair
<pitti> StevenK: I know, but ATM I don't see what's keeping it there
<fabbione> shawarma: heartbeat is a very cheap version of RHCS..
<StevenK> pitti: Hysterical raisins from what I can see here.
<pitti> StevenK: that's not what I mean
<pitti> StevenK: a main package either needs to be seeded, or a dep/build dep of another main package, or appear in anastacia
<StevenK> Ahhh, right
<pitti> and neither of those three seems to be the case here
<shawarma> pitti: It's b-d of evms
<StevenK> Ewwww
<zul_> fabbione: cheap but effective
<pitti> oh, crud, indeed
<fabbione> score...
<StevenK> Personally, I think evms needs to be booted out of the archive, but that's just me. :-)
<fabbione> StevenK: for how much i love weird block device setups, i agree with you
<fabbione> it was the only one i never got to work
<shawarma> fabbione: Indeed it is. I just thought that was what people used. I also have a bit of empirical data that supports that, but not enough to be statistical valid by any standarad.
<StevenK> fabbione: I think Keybuk agrees with us, too.
<fabbione> StevenK: IME Keybuk is a bit more drastic on block devices :)))))))
* StevenK grins
<fabbione> StevenK: but Mithrandir would probably hang us for proposing that
<pitti> it seems that it's only needed for evms-ha, which is in universe
<Hobbsee> fabbione: yes, but he's not here :P
<StevenK> pitti: But the evms source is in main, so it needs to stay.
<pitti> so, we might be able to drop evms-ha and the heartbeat-dev b-dep from evms
<StevenK> Ahh
<StevenK> Tackle it that way
<pitti> and thus drop heartbeat and the openimpi stuff
<pitti> Mithrandir: would you terribly miss evms-ha?
* StevenK sighs at having to munge the Maintainer field for a build1 change
<pitti> StevenK: don't
<fabbione> pitti: i doubt he will and if so we can always port it to openais
<Hobbsee> StevenK: you dont have the update-maintainer script?
<pitti> StevenK: a mere changelog entry is not really worth doing that
<StevenK> pitti: I thought you had to...
<Mithrandir> pitti: no
<Keybuk> what's wrong with dropping evms from main? :p
<Keybuk> it doesn't work anyway
<pitti> Keybuk: nothing really from my side, but it's seeded, so someone seems to want it
<Hobbsee> evening Keybuk!
* shawarma scurries off for a bit
<StevenK> Oh dear, look what I started.
<Mithrandir> Keybuk: sure it works.
<Keybuk> Mithrandir: for you, not for mere mortals
<pitti> StevenK: main->universe demotion domino :)
<StevenK> pitti: Yup. :-)
<Keybuk> for them, it leaves their system largely unbootable right now <g>
<Mithrandir> *shrug*. :-P
<fabbione> Keybuk: for once i can see nothing.. drop it! :P
<pitti> argh, evms again uses libglib1.2
<Tonio_> pitti: uploading network-manager, and fixing network-manager-gnome, we decided what to do with mbiebl
<pitti> Tonio_: what did you decide?
<StevenK> pitti: Surely another nail in it's coffin? :-)
* Hobbsee puts in a word for throwing yada out of main.
<pitti> StevenK: we had it use 2.0 for some time, but it was not perfect, and upstream doesn't care
<fabbione> pitti: go for it....
<Hobbsee> if we're throwing things out of main, that should go...
<StevenK> Hobbsee: Stop the 3 packages in main using it, and it can
<Tonio_> pitti: move the nm-vpn-properties binary to /usr/lib to make it, makes it ignored by shlibdeps and patch the applet to use it
<Hobbsee> StevenK: by removal, right?  :p
<fabbione> pitti: evms/heartbeat/*kde* -> universe should so
<StevenK> Hobbsee: Heh
<pitti> fabbione: lol
<Tonio_> pitti: that avoids maintaing lots of patches, waiting for upstream to perform the split properly
<StevenK> fabbione: It was nice knowing you.
<ion_> fabbione: :-D
<Hobbsee> fabbione: haha
<pitti> Tonio_: cool
* fabbione grins
<Tonio_> pitti: next step is to fix knetworkmanager configure...
<StevenK> pitti: Okay, if heartbeat gets demoted, will it automatically try and build itself again?
<pitti> StevenK: it should; if not, I can poke it manually
<Keybuk> (I have no problems with evms if someone stops it trying to make devmapper shadows of every system block device, and instead makes it only shadow those block devices it intends to use)
<seb128> pitti: having no space after the sudo prompt feels weird, did you do it on purpose or that's a bug? ;)
<pitti> seb128: mainly on purpose; the older sudo prompt didn't have a space either
<pitti> seb128: and I want to be careful to not break frontends
<seb128> hum, k, I was probably used to it then
<pitti> seb128: I tested gksu and kdesu
<Tonio_> pitti: you'll find network-manager-gnome in NEW in a few minutes
<pitti> Keybuk, Mithrandir: hm, so you favor demoting evms over dropping the evms-ha package?
<pitti> Tonio_: so you decided for -gnome; nice
<Tonio_> yup
<Keybuk> pitti: to me, it is clear that we have nobody with sufficient combination of time, inclination and motivation to correct interaction problems with evms
<Tonio_> pitti: network-manager-pptp ftbfs, but builds locally in a pbuilder chroot.... strange
<Keybuk> which suggests that we don't have people maintaining it
<pitti> Keybuk: that's my thought, even more so with heartbeat (which is why I want to demote this in any case)
<Keybuk> so I think that it is failing main requirements
<Tonio_> pitti: forget that, bad builddep, should be waiting for 0.6.5
<fabbione> and if somebody needs to maintain it, it should really port it to something != heartbeat
<pitti> hey mbiebl 
<StevenK> pitti: So who's the lucky person that gets to unseed evms? :-)
<pitti> StevenK: I'm at it already
* StevenK nods.
<mbiebl> pitti: hi
* Hobbsee waves to mdz 
<sladen> Hobbsee: pop over to Edinburgh and you can wave in person
<Hobbsee> sladen: if i wanted to be shot by my uni on my return, sure!
<mrsn0> can i grab a lift from ireland ? :p
<mrsn0> if its on the way, of course
* Hobbsee curses uni exams that she should be studying for
<zul_> Hobbsee: heh then you can become a professional student if you fail them
<sladen> "should"
<Hobbsee> zul_: hahaha.  got a recipe on how to do taht?
<Hobbsee> sladen: yes.  should.
<zul_> zul_: no but I know several people at my own school who were on that track
<zul> gah..
<zul> s/zul/Hobbsee/
<StevenK> Woot.
* Hobbsee is not zul.
* StevenK watches evms and heartbeat drop like a stone.
* Hobbsee is Hobbsee.
<Hobbsee> zul: right
<pitti> hi zul 
<pitti> zul: btw, do we still need xen-3.0 in gutsy, or is it entirely superseded  by xen-3.1?
<ogra> Riddell, is there a specific kde package for power management ? seems i'm geeting the KDE bugs filed for g-p-m
<Riddell> ogra: kde-guidance-powermanager is the frontend (kde-guidance source)
<StevenK> ogra: kde-guidance, from memory
<ogra> oki
<ogra> and there is no specific backend i guess
<ogra> apart from hal
<StevenK> pitti: If you do get the cruft lists generating automagically, can you put a comment at the top with a timestamp?
<pitti> StevenK: the file dates should be enough, no?
<pitti> it's just a directory
<StevenK> Point
<pygi> pitti, I'll have to unsubscribe from all the bugs
<pygi> it's messy :-/
<pitti> pygi: it's just an one-time spam
<pitti> but you can generally drop emails from apport@piware.de, there won't be much useful stuff
<pitti> pygi: in any case, it'll get silent in the future anyway, with https://wiki.ubuntu.com/CrashReporting
* pygi hopes so
<pitti> spam wave is over soon -- script is at 4336/4876
<pygi> wee :P
* Hobbsee clears out her "discard" folder again
* StevenK wills LP to mail him an ACCEPTed mail so he can go to bed.
* Hobbsee has already teleported StevenK's bed out into the rain.
* pygi has already ate Hobbsee 
<Hobbsee> i cant really see *why* you'd want to go to bed, on that basis.
<Hobbsee> pygi: no you havent.  
<pygi> Hobbsee, yup, I did :)
* Hobbsee explodes pygi 
<pygi> Hobbsee, kid, kid ... that doesn't work on me :)
* Hobbsee makes pygi answer every single one of shirish's questions.
<Hobbsee> forever.
<pygi> Hobbsee, meh, did you see "new" brasero bug?
<Hobbsee> nope.
<pygi> wanna see it? xD
<Hobbsee> on the basis of general health and sanity, i've been ignoring him.
<Hobbsee> oh, why not.
<Hobbsee> then i can take sadistic pleasure in rejecting it.
<pygi> https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/119725
<pygi> we already rejected it
<ubotu> Launchpad bug 119725 in brasero "Have pre-defined preference for burning .iso packages" [Wishlist,Rejected]  
<StevenK> "where one could associate speeds with mime types"
<StevenK> Twitch
<Hobbsee> pitti: please giveback swfdec0.4, swfdec-mozilla on all arches
<pygi> StevenK, yes ? :p
<Hobbsee> heh
<StevenK> I'm so tempted to reject one of Shirish's bugs with "Can you please provide me the name and phone number of your dealer."
<Hobbsee> StevenK: hahahhaa
<Hobbsee> StevenK: well, there are plenty.
<pygi> StevenK, this channel is being logged =)
<Hobbsee> StevenK: https://bugs.launchpad.net/~shirishag75
<ion_> :-D
<Hobbsee> pygi: so it's also logged me wanting to call him a fucking moron, in channel.  so?
<Hobbsee> some people warrant it.
<pygi> impressive number of bugs
<pygi> 103 bugs 
<StevenK> Oh ye
<StevenK> yes
<Hobbsee> that's non-rejected bugs, too
<Hobbsee> that's 100 easy rejects
<pitti> Hobbsee: swfdec0.4 given back, -mozilla is in depwait
<Hobbsee> pitti: thanks.  it needs the former
<pitti> I figured
<seb128> pitti: oh, you are buildd admin now?
<pitti> seb128: yes, I am
<seb128> good to know ;)
<pitti> easier when doing release management stuff
<seb128> right
<desrt> hey... not all of this guy's bugs are bogus
<StevenK> Just 90% of them.
<Hobbsee> desrt: no.  most of the bogus ones have been gotten rid of as they hit -bugs
<pitti> well, he does have good ideas, but they are incredibly hard to implement at times
<desrt> why do some of the bugs in this list show up twice?
<pitti> desrt: multiple tasks?
<desrt> pitti; ya.
<desrt> upstream vs. distro
<pygi> yay, soon we'll be able to create ISOLINUX bootable cd's with libisofs :)
<ogra> Keybuk, if i create a device with MAKEDEV and then run /sbin/udevcontrol reload_rules will udev cange te ownership properly to match the rules or will it just silently do nothing ? 
<Keybuk> ogra: no
<ogra> ...beacues the device is tere 
<ogra> *because
<Keybuk> why are using MAKEDEV?
<ogra> Keybuk, seems like a merge bug in fuse-utils
<ogra> http://paste.ubuntu-nl.org/26135/
<ogra> makedev is called by debian 
<ogra> we call /sbin/udevcontrol reload_rules
<ogra> they dont handle it through udev at all
<Keybuk> *shrug*  that's because Debian's udev doesn't reload automatically
<Keybuk> ours does
<ogra> oh, then i can drop both ? 
<ogra> cool
<Keybuk> I guess
<Hobbsee> hiya mvo_!
<pygi> Hobbsee, you eat him!
<mvo_> hey Hobbsee!
* Hobbsee eats pygi 
<pygi> not me!
<pygi> him!
<pygi> mvo_ <-- him!
<Hobbsee> bah
<Hobbsee> but why?
<pygi> no idea
<pygi> because :)
<Hobbsee> 77% [23 alsa-utils 443/1051kB 0%]                                                                                             95.6kB/s 33s
<Hobbsee> come on...
<shawarma> Tonio_: I noticed you didn't add iproute as Depends: to network-manager.. Is that on purpose?
<shawarma> Tonio_: If it needs it as a build-dep, doesn't it need it at runtime, too?
<pygi> not always
<Hobbsee> pitti: any idea what liboggflac3 was replaced by?
<Hobbsee> or what source package it was in?
<Hobbsee> oh, was in flac
<geser> Hobbsee: libflac-dev
<Hobbsee> right
<Hobbsee> just seeing that now
<geser> liboggflac got merged into libflac
<Hobbsee> yeah, i see
<pitti> mvo_: can you write a MIR for compcomm-plugins-main? (compiz build dep)
<mvo_> pitti: sure
<pitti> mvo_: and compiz-bcop
<pitti> StevenK: I wonder why this openipmi change isn't done in Debian -- it certainly needs to?
<Tonio_> shawarma: it ftbfs without iproute as builddep
<Tonio_> shawarma: it is just a matter of checking path and so on
<Tonio_> shawarma: no big deal
<shawarma> Tonio_: It checks for it, but doesn't need it?
<Tonio_> shawarma: think so
<shawarma> Tonio_: crack :)
<Tonio_> shawarma: it was already there before, I just didn't remove it in fact :)
<Tonio_> shawarma: no time to check all the dependancies on that point, and nothing in the changelog concerning a change on that point, so... :)
<shawarma> Tonio_: meh.. I just thought it needed it at runtime and since it's not the kind of thing that would be picked up by shlibdeps..
<Hobbsee> pitti: if you're going to send mass email like that, via apport, would you mind sending an email a few days prior to all devleopment mailing lists about it, so we can warn upstreams?
<Hobbsee> pitti: otherwise, they tend to want to kill us.  or at least not work with us.
<Hobbsee> pitti: had you done so, we could have warned the upstreams about it, and they could have put in a filter to discard any apport mail, so that it didnt absolutely flood their bugmail mailing lists.
<Keybuk> "Runway 05/23 is not available from 1600 Fri to 0800 Sun 0800 (Tue after PH) due to market."
<Keybuk> *amused*
<Hobbsee> haha
<Treenaks> Keybuk: where's that?
<Keybuk> Treenaks: airfield near me
<Treenaks> Keybuk: so.. going to the market then? :P
<Keybuk> Treenaks: I thought I might "drop in"
<bryce> morning - Hobbsee still about?
<Treenaks> she was 10 minutes ago
<Hobbsee> bryce: heya!
<Hobbsee> bryce: contrary to what upstream says, https://bugs.launchpad.net/bugs/60288 is not fixed, and still needs that patch.
<ubotu> Launchpad bug 60288 in xorg-server "xorg segfaults in libglx.so(__glXleaveServer+0x22)" [High,Confirmed]  
<bryce> Hobbsee: okie
<bryce> wonder what happened - tepsipakki do you know on this one?
<Hobbsee> bryce: upstream says it's been fixed somewhere else
<Hobbsee> but it hasnt.
<Hobbsee> or, there's something else, which that patch fixes
<bryce> hmm, it's a bit ambiguous how this was fixed. lemme look
<bryce> can you confirm that the patch fixes the problem? 
<Hobbsee> bryce: either way, it's kidna important that this gets fixed, pronto
<Hobbsee> yep
<Hobbsee> or at least, it did in feisty
<bryce> well, it sounds from the bug like if we're still experiencing the problem, it might be due to something else
<Hobbsee> today was the first time i'd tried a non-blank screensaver in gutsy - hardlocked X, music kept playing.
<bryce> so I can pump out the patch, but it may not fix it
<Hobbsee> (seeing as this happens multiple times a day, when that patch isnt in)
<Hobbsee> this is true.  it may not fix the problem - it may mask it, and the problem is somewhere else
<Hobbsee> bryce: do you want logs of this?
<Hobbsee> bryce: if you tell me what you want, i can hardlock the machine fairly easily with this
<bryce> yeah, and if you can post a fresh backtrace, that'd be handy
<bryce> ok cool.  
<Hobbsee> hwo do i get the backtrace - the only option is to shut the machine off?
<Hobbsee> or at least, used to be able to 
<bryce> maybe this?
<bryce> gdb /usr/bin/X
<bryce> gdb> run -ignoreABI
<bryce> no
<Hobbsee> i cant actually get any info, unless i pipe it, i expect
<Hobbsee> as it locks keyboard, etc.
<shawarma> Hobbsee: ssh?
<Hobbsee> shawarma: no other linux machine here
<shawarma> Hobbsee: putty?
<bryce> have you checked after reboot but before restarting X, if there is a trace appended to you /var/log/Xorg.0.log?
<Hobbsee> and i dont have ssh running here, for the aforementioend reason
<Treenaks> Hobbsee: serial console?
<Hobbsee> Treenaks: none
<shawarma> Hobbsee: Well, you could install openssh-server on your box, putty on another and do the gdb thing through that?
<Hobbsee> bryce: doesnt that show up in Xorg.0.log.old or something?
<Hobbsee> shawarma: i could...but at 3am, that's a bit nasty
<Treenaks> 3am, sounds like a perfect time for "nasty" to me ;)
<bryce> Hobbsee: yup
<Hobbsee> right.  will grab them, at least
<bryce> Hobbsee: it sounds from the bug description that it always results in a backtrace
<Hobbsee> gah.  famous words
<Hobbsee> bryce: no idea, i've never been able to ssh in :)
<bryce> if there isn't a backtrace, that suggests it's some different bug
<bryce> (backtrace at the end of your Xorg.0.log file)
<Hobbsee> i never said that there wasnt - just that i couldnt access it
<Hobbsee> ahh.  dont remember, tbh
* Hobbsee had to leave for work and suhc whne it was dying
<Treenaks> Hobbsee: priorities ;)
<Hobbsee> Treenaks: yeah, well.
<shawarma> Hobbsee: You're right index finger is out of sync.
<shawarma> Why can't I spell properly today?
<Treenaks> shawarma: your apostrophes are ;)
<Hobbsee> bryce: i didnt know X servers were so much like horses.  gah.
<shawarma> Treenaks: Precisly. I wrote "it's" at least ten times today when it should be "its". What's up with that?
<Hobbsee> "no, i wont die when there's someone here who's waiting for me to"
<Treenaks> shawarma: it's annoying ;)
<Hobbsee> shawarma: likely.
<Hobbsee> shawarma: too much typing
<shawarma> Hobbsee: It appears to be slightly ahead of the other fingers, so a bit tape or a an elastic band might help.
<bryce> hehe
<Treenaks> shawarma: hacky hardware solution to a wetware problem
<Treenaks> shawarma: just sleep a bit, then try again
<bryce> Hobbsee: ok looks like the thing we're looking for in the backtrace is "lXleaveServer"
<Hobbsee> imbrandon: your machine is dead.  again.
<Hobbsee> imbrandon: pleasefix :)
<Hobbsee> bryce: right
* Hobbsee --> bed.  will look later
<pitti> seb128, bdmurray: FYI, there are 196 bugs left which need a retrace; I'll tag them tomorrow
<pitti> if you want
<pitti> it would mean more bug spam, of course
<seb128> 196 is not going to make any difference now :p
<seb128> feel free to tag them ;)
<pitti> 'k
<sjoerd> 
<ion_> 
<slomo> hm, is the gnome part of the new network-manager already waiting somewhere? :)
<slomo> Tonio_: will you also upload the gnome frontend of the new network manager?
<Tonio_> slomo: done
<Tonio_> slomo: should be waiting in the NEW queue probably
<slomo> Tonio_: thanks :)
<Tonio_> :)
<tepsipakki> bryce: about the patch; maybe a new upstream bug report is needed for the problem Hobbsee is seeing (as alanh requested in the closed bug)
<bryce> yes that's what I think too
<bryce> tepsipakki: do you think restoring the patch would fix the issue?  I'm thinking about preparing a deb for her to test
<tepsipakki> I believe so, yes..
<mikmorg> cjwatson_: Hello there
<calc> is openjdk going to be packaged for ubuntu?
#ubuntu-devel 2007-06-19
<wasabi> Probably as soon as it is for Debian.
<wasabi> I believe people are working on combining it with classpath.
<pochu> Debian #398448
<ubotu> Debian bug 398448 in wnpp "ITP: openjdk-compiler -- sun java compiler, javac" [Wishlist,Open]  http://bugs.debian.org/398448
<calc> wasabi: ok
<gnomefreak> crimsun: have you heard anything reguarding flashplugin-nonfree still being broken?
<crimsun> gnomefreak: more context, please, in -motu?
<gnomefreak> oh thought i was
<StevenK> Neat. I haven't seen this build state before.
<StevenK> gutsy amd64   Failed to upload
<sladen> sabdf1: party @ http://maps.google.co.uk/maps?q=Bristo+Place,+Edinburgh
<sabdf1> hey sladen
<sabdf1> party @ taipei tomorrow for me
<sladen> sabdf1: party @ beijing yesterday for me :)
<sladen> iwj and elmo are having a competition to see who can jump down from the pulpit
<sladen> *thud* *..thud*
<Chipzz> sladen: sounds like a strange kind of party to me ;)
<Chipzz> "sounds" being the operative word ;)
<Chipzz> (oh, not really a party)
<jcole> where can i find a list of available packages differences between ubuntu and debian?
<bryce> jcole, I don't know about ubuntu/debian overall, but I maintain a differences list for just the xorg stuff here:  http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<jcole> thanks bryce, thats a start
<crimsun> jcole: patches.ubuntu.com
<mneptok> i had a kitten named Patches. she breathed fire.
<mneptok> well, not really. but i tried to make her.
<mneptok> i miss you, Patches.
<jml> mneptok: haha
<pygi> good morning folks
<fabbione> morning guys
<pygi> hey fabbione 
<pygi> it's 5:24, doubt anybody is awake yet :)
<fabbione> i am :)
<pygi> I know you are :P
<pygi> same here =)
<pygi> but still ... ;p
<StevenK> Of course fabbione is awake, he has a small child.
<fabbione> yeah and he is about to wake up
<pygi> StevenK, :)
* fabbione grrrrs at libcman
<fabbione> so ok..
<fabbione> who can help me with something stupid in C
<fabbione> i clearly can't see the simplest thingy
<fabbione> i have a set of functions that are like..
<fabbione> foo(int fd, void *buf, int bufsize)
<fabbione> they call each other in sequence
<fabbione> if bufsize is < 0 then the last function needs to allocate the buf
* Hobbsee ponders getting rid of feisty
<fabbione> how can i easily propagate back the new value of buf up in the chain?
<fabbione> clearly just doing a buf=malloc(buf); is not enough
<xhaker> fabbione, i've run into that but workaround it by making the thing global
<fabbione> global is not a solution
* xhaker knows
<xhaker> i'd like to know a solution to this thingie too :D
<fabbione> no really, you can't make this stuff global at all
<fabbione> or the application will boom
<fabbione> i mean.. there is a way for me to do it but i don't really like it
<xhaker> i didn't too, but it was a college CG work.. they don't care
<xhaker> well, i remember messing with realloc()
* xhaker always ended up with new memory space instead
<Hobbsee> oh darn, pygi isnt here.
* Hobbsee has a quote for him.
* Hobbsee dies at #ubuntu+1
<desrt> does anyone know if writing a double precision float on an x86 is atomic?
<LaserJock> Hobbsee: please don't die
<Hobbsee> LaserJock: awww, why not?
<shawarma> fabbione: Can you change the function's prototype?
<shawarma> Goodmorning to all, by the way.
<shawarma> fabbione: ..or are they part of a public API or something?
<lifeless> fabbione: if you can change the prototype, making it void **buf and int *bufsize would do
<fabbione> yes i can change them
<shawarma> fabbione: Ok, what lifeless said then. :)
<fabbione> thanks guys
<shawarma> np, dude.
<fabbione> there.. working finally
<shawarma> \o/
* Treenaks looks around for a new network-manager-gnome package, but sees none
* netjoined: irc.freenode.net -> kubrick.freenode.net
<pitti> Good morning
<fabbione> hey pitti
<geser> morning pitti
<shawarma> Good morning, pitti.
* pitti hugs geser, fabbione, and shawarma 
<Hobbsee> morning pitti
<Hobbsee> !
* Hobbsee hugs pitti 
<pitti> Hobbsee: *big hug*
<Hobbsee> :D
<pitti> mvo_: hmm, why doesn't upgrade-manager support sth. like 'apt-get dist-upgrade' for gutsy?
<pitti> mvo_: it currently tells me that it cannot install all updates, and when I click on 'system upgrade' it crashes 
<Treenaks> pitti: network-manager-gnome is broken anyway
<pitti> Treenaks: *upgrade*, not network :)
<Treenaks> pitti: I know, but that's the thing upgrade-manager is breaking on, I think
<Hobbsee> pitti: you need the network for upgrading...
<pitti> hi mvo
<Treenaks> it is for me
<mvo> hey pitti
<pitti> a normal 'apt-get dist-upgrade' works just fine
<pitti> mvo: hmm, why doesn't upgrade-manager support sth. like 'apt-get dist-upgrade' for gutsy?
<Treenaks> pitti: but deinstalls network-manager-gnome :)
<pitti> mvo: it currently tells me that it cannot install all updates, and when I click on 'system upgrade' it crashes 
<pitti> Treenaks: sure
<mvo> pitti: that was a bug,  crash should be fixed with the new upload from yesterday
<pitti> ah, cool
<pitti> zakame: did you already find out about the xmms2 FTBFS on amd64?
<zakame> pitti: yes, it on the debian BTS, upstream's still figuring it out
<pitti> zakame: ah, good
<zakame> http://bugs.debian.org/426382
<zakame> oh, there's a new version now, will check that
<pitti> zakame: oh, fixed now
<zakame> yeah
<pitti> zakame: ah, usual lack of -fPIC :)
<pitti> zakame: I'll reject the current binaries now, to avoid inconsistencies
<zakame> ok, will remerge
<pitti> zakame: (from the binary NEW queue)
<pitti> zakame: thanks
<zakame> pitti: thanks for the heads-up :D
<dholbach> good morning
<zakame> good day dholbach :)
<dholbach> hey zakame
<bryce> heya zakame, small world :-)
<zakame> bryce!!! yeah it is :D
<Mithrandir> why does ekiga insist on running the setup wizard every so often?
<Treenaks> because it's broken?
<Hobbsee> evening Mithrandir 
<Tonio_> hi
<Tonio_> pitti: ping ?
<pitti> hi Tonio_ 
* StevenK waves to pitti
<Tonio_> pitti: hi ;)
<pitti> hey StevenK 
<Tonio_> pitti: I noticed knetworkmanager ftbfs for ia64, I know the reason but I don't have the clue for this, I may require some help to get it to work
<StevenK> pitti: Can you re-run your cruft checker? It should have most of the libsnmp9 ones sorted out.
<pitti> StevenK: sure, doing now
<Tonio_> pitti: to make it simple, there is a problem with libnl on ubuntu concerning the typedefs.
<StevenK> pitti: I also saw a build state I haven't seen before for heartbeat. " gutsy amd64   Failed to upload"
<XAngelusX> hi to everyone
<pitti> StevenK: oh, that again *sigh*
<pitti> StevenK: I'll have a look
<Tonio_> pitti: the solution is to include the linux types.h in the code, which results a second error, missing types __64
<pitti> Tonio_: just a second
<Tonio_> sure :)
<StevenK> pitti: I have another issue, but I'll wait until you're ready.
<mvo> pitti: MIR reports for compcomm-plugins-main and compiz-bcop ready
<pitti> StevenK: heartbeat amd64 poked, it's accepted now
<StevenK> pitti: Thanks!
<StevenK> pitti: My other issue was I upload cpqarray, but I didn't get a mail about it, and it didn't turn up in the accepted queue.
<pitti> StevenK: great, you cleaned libsnmp9 for main; now it's only two handful of universe
* StevenK cracks his knuckles.
<pitti> http://people.ubuntu.com/~pitti/tmp/cruft/ updates
<pitti> updated
<StevenK> I only spent 2 hours at $WORK doing ten uploads. Sssshh! :-P
<StevenK> Most of the remaining will be cleaned up when the binaries for all the uploads I did publish.
<StevenK> cpqarrayd and wmnd-snmp look to be the odd ones out.
<pitti> 06:20:58 DEBUG   Not permitted to upload to the RELEASE pocket in a release in the 'CURRENT' state.
<StevenK> Oh crap.
<pitti> You uploaded to 'feisty' :)
<StevenK> It's because I'm a bozo, isn't it.
<StevenK> Yes...
<pitti> I cannot find wmnd-snmp; is it a typo?
<StevenK> I haven't uploaded that one, it appears in your list.
<pitti> ah, I see
<StevenK> pitti: Oh yes, all but one of the updates actually makes use of libsnmp9.
<pitti> ah, so no --as-needed magic
<StevenK> Right.
<pitti> Tonio_: ok, back to you
<Tonio_> pitti: oki ;)
<StevenK> pitti: Thanks for your help.
<pitti> btw, any idea why network-manager-gnome is uninstallable ATM?
<pitti> StevenK: you're welcome; thanks for your's :)
<Tonio_> pitti: so here is the hack to make knetworkmanager to build :
<StevenK> pitti: :-)
<Tonio_> pitti: http://paste.tonio.homelinux.org/104
<Tonio_> pitti: I know that really ugly, but there is no other solution, except that cause, logically, a ftbfs on ia64
<Tonio_> pitti: wanted to know if you had another option in mind in fact...
<pitti> Tonio_: TBH, I think that's the wrong way to solve this
<Tonio_> pitti: of course it is :) but how to do better ?
<pitti> Tonio_: the point is, userspace should not use the __foo types, they are defined in the kernel and should only be used there
<pitti> Tonio_: the official way for userspace is to use uint64_t, int32_t etc.
<Tonio_> pitti: so the solution is to fix the libnl, right ?
<pitti> Tonio_: I guess so; a big s/__uint64/uint64_t/g, and sending it to upstream
<pitti> erm, u_unt64_t
<pitti> erk
<pitti> u_int64_t
<pitti> Tonio_: it's in sys/types.h
<StevenK> Oh, grah. kolab-cyrus-imapd failed to build due to ghostscript SEGVing on ia64.
<pitti> Tonio_: there were similar things in hal, and it caused trouble; I sent a similar and huge patch upstream, and they took it
<pitti> Tonio_: (maybe better to send them a set of sed commands than a 300 kB patch :) )
<Tonio_> pitti: that's a kernel patch right ?
<Tonio_> oups sorry I missunderstood you
<pitti> Tonio_: what, what, kernel patch?
<Tonio_> pitti: so we have to sed the libnl code
<Tonio_> pitti: yeah sorry I missunderstood the "<pitti> Tonio_: it's in sys/types.h" ;)
<Tonio_> pitti: I'm not a coder, so....
<Tonio_> pitti: okay so I'll let the workarround for the moment, and try to get the libnl fixed
<Tonio_> pitti: thanks for the teaching :)
<pitti> Tonio_: just /usr/include/sys/types.h, should be a standard C header
<pitti> Tonio_: you're welcome
<pitti> Tonio_: ok, standard POSIX, not standard C, but you get the idea
<Tonio_> pitti: yup, got it
<pitti> Tonio_: you are sure that the workaround works? and why not just fix it properly right from the start?
<Tonio_> pitti: works as long as it builds :)
<Tonio_> pitti: the workarround works on several architectures, just fails on ia64
<pitti> Tonio_: heh, true :)
<pitti> asac: oh, do you need more info from me for bug 121027?
<ubotu> Launchpad bug 121027 in gnash "gnash crashed with SIGSEGV in std::_Rb_tree<boost::intrusive_ptr<gnash::as_object>, boost::intrusive_ptr<gnash::as_object>, std::_Identity<boost::intrusive_ptr<gnash::as_object> >, std::less<boost::intrusive_ptr<gnash::as_object> >, std::allocator<boost::intrusive_ptr<gnash::as_object> > >::erase()" [Undecided,Needs info]  https://launchpad.net/bugs/121027
<pitti> erk, what a topic; yay C++ templates
<Tonio_> I also have a ftbfs for the pptp plugin, I don't understand the cause of this since it builds like a charm in a chroot or pbuilder chroot here...
<asac> pitti: no we have a tester from my team now :)
<pitti> Tonio_: looking
<Tonio_> pitti: looks like a problem with lb, but I can't figure out the difference between the buildd and my chroot...
<pitti> Tonio_: ah, forgot to build something with -fPIC
<pitti> Tonio_: you actually tested it in an amd64 chroot?
<Tonio_> pitti: no, just an i386 one, but it is a global ftbfs
<Tonio_> pitti: hum right, the latest upload only fails on amd64, right ;)
<pitti> Tonio_: hm? it only failed on amd64
<Tonio_> pitti: I missed that one, I was talking about n-1 upload
<EliasAmaral> why there is so few 32bits libraries on amd64 port? i can find only these: http://packages.ubuntu.com/cgi-bin//search_packages.pl?version=feisty&subword=1&exact=&arch=any&releases=all&case=insensitive&keywords=32-lib&searchon=names and http://packages.ubuntu.com/cgi-bin//search_packages.pl?version=feisty&subword=1&exact=&arch=any&releases=all&case=insensitive&keywords=lib32&searchon=names
<Nafallo> EliasAmaral: ia32-libs
<EliasAmaral> ia32-libs contains /all/ libraries?
<EliasAmaral> there are a huge number of libsomething on repos
<pitti> EliasAmaral: only the most imoprtant ones to run popular apps
<EliasAmaral> I was using amd64 edgy, but the lack of libraries (also, the lack of support for flash/etc) made me running a dchroot, but in the end it was a very poor idea and i am using i386 feisty now
<Hobbsee> er, the arts maintainer is?  
<pitti> EliasAmaral: we can put more stuff into ia32-libs if desired; right now it's working with e. g. vmware, skype, some games, etc.
<EliasAmaral> i think amd64 should have a good support for running 32bits apps. i was expecting finding every lib compiled twice
<EliasAmaral> hmmm
<Hobbsee> oh wait, found it
<pitti> EliasAmaral: but that's hardly necessary?
<pitti> EliasAmaral: the prime usage of ia32-libs is to run commercial apps which are only available for 32 bit
<EliasAmaral> i don't know about necessary, but it sounds like 'the right thing'
<pitti> EliasAmaral: but they usually have a relatively limited set of dependencies, to run on a decent variation of distros
<EliasAmaral> hmmmmmm
<pitti> EliasAmaral: if you need the entire range of i386 libs on amd64, then you are probably better off installing the i386 arch in the first place IMHO
<EliasAmaral> what i though about a 64bits system was it would run any 32bits or 64bits app. so i could in theory install 32bits firefox from i386's .deb
<pitti> EliasAmaral: right, but support for that isn't that perfect yet; you need different directories for the libraries, etc.
<pitti> EliasAmaral: i. e. you cannot install the 32 and 64 bit variant of e. g. libgtk2.0 if they don't have different paths
<EliasAmaral> pitti, do you know if it is included in any blueprint, or planned for any future release? i would see this as a nice technical advantage
<EliasAmaral> pitti, hmmm, yes, 32bits packages installs only in /usr/lib ..
<pitti> EliasAmaral: I don't, sorry; doko might know
<Mithrandir> EliasAmaral: it's planned for an undefined future release, but it's a hard problem.
<Nafallo> wasn't multiarch kind of dropped because the goal is to get everyone running x86_64 and everything working on that arch? :-)
<EliasAmaral> maybe moving i386 /usr/lib to /usr/lib32 and making /usr/lib a symlink to /usr/lib32 would be a good step
<shawarma> Nafallo: sssh.. That's the *secret* goal. :)
<Nafallo> shawarma: I read it on ubuntu-devel@ ;-)
<Mithrandir> Nafallo: you read it on the intarweb so it must be true.
<doko> EliasAmaral: no, the good step would be to use lib64 for 64bit libs
<Nafallo> Mithrandir: :-)
<Mithrandir> hi doko
<EliasAmaral> doko, but if i actually wanted to install a i386 package in a amd64 box, the /usr/lib in amd64 system would be full of.. 32bits-only libs, what doesn't make much sense
<doko> EliasAmaral: sure, if you want to do that, you would have to do something like ia32-libs, ia32-libs-kde, ia32-libs-gtk
<Keybuk> I thought we were moving i386 /usr/lib to /usr/lib/i484-linux-gnu
<Keybuk> and amd64 /usr/lib to /usr/lib/x86_64-linux-gnu
<EliasAmaral> i am trying to figure out if this is a joke or not
<EliasAmaral> ubuntu isn't meant to be linux-specific? =D
<pitti> EliasAmaral: well, some guys ported Debian to a BSD kernel, or to Hurd
<Keybuk> it'd be pretty hard to truly port to non-Linux
<EliasAmaral> doko, the problem is, each package depends upon specifics libraries, so if i want to install an arbitrary i386 package, i would have to install arbitrary i386 libs, too. and, from i386 repos
<Keybuk> some of our core bits are Linux only
<Mithrandir> EliasAmaral: I suggest you read the papers in http://multiarch.alioth.debian.org/, they explain the problem and a possible solution.
<EliasAmaral> reading:)
<doko> EliasAmaral: the only way that works now is the ia32-libs* approach.
<Nafallo> gaah. opening Mithrandirs key with seahorse makes my computer nearly freeze :-P
<Mithrandir> : tfheen@thosu ~ > gpg --list-sigs 817a996a | wc -l
<Mithrandir> 1011
<Mithrandir> :-P
<shawarma> Oh, dear.
<shawarma> I'm at 48. :)
<pitti> 804 here
<Mithrandir> five UIDs though
<Nafallo> hehe. I think seahorse fetches all of them for trusted keys ;-)
<Mithrandir> I should revoke one of them, since it no longer works.
<Nafallo> yay for automation! :-)
<Mithrandir> there, revoked.
* Keybuk only has 1 UID on each key now
<fabbione> gpg --list-sigs 44779E18 | wc -l
<fabbione> 1740
<fabbione> tsk :P
<Fujitsu> Wow.
<EliasAmaral> Mithrandir, liked that paper, "Packages would simply depend on the appropriate string for their architecture, so an i386 package can be installed on either system." is exactly what I think about being multi-arch. but this is from dapper's release time..
<fabbione> yeah and it's ages that i don't go to a keysign party
<Hobbsee> dammit. message moderated, as i used the wrong email
<Hobbsee> although, i would have expected an @ubuntu.com address to automatically work - it's listed on LP
<Hobbsee> says i'm not subscribed to the list
<StevenK> pitti: Last two packages for the libsnmp9 transition uploaded.
<pitti> rock
<bhale> yay snmp
<StevenK> pitti: Any other transition you want me to knock over? :-)
<pitti> StevenK: oh, there are plenty; the libcurl3 mess is awkward
<StevenK> pitti: I had plans to deal with ibatlas-cpp-0.6-0c2a, which is waiting on the Debian maintainer.
<StevenK> libatlas-cpp-0.6-0c2a, that is.
<geser> pitti: isn't Debian moving back from libcurl4 to libcurl3?
<pitti> StevenK: oh, as long as it'll get fixed in Debian soon and we can just sync it, we don't need to worry about it so much
<pitti> geser: erk? I don't know
<geser> pitti: http://lists.debian.org/debian-release/2007/06/msg00106.html
<StevenK> pitti: Yeah, the Debian maintainer of libatlas-cpp-0.6-1 is the maintainer of the 3 packages listed.
<StevenK> pitti: Yay... libcurl3 lists heartbeat as well. :-)
<pitti> StevenK: hm, so let's find out what happens with curl in Debian and do one of the smaller ones
<StevenK> pitti: Aye, okay
<pitti> StevenK: siretart already wanted to care about the ffmpeg stuff
<pitti> StevenK: and gpocentek about the libgoffice, the rest is fair game AFAICS
<StevenK> pitti: I can deal with the 3 or so for libiw28, if you like.
<pitti> StevenK: that would be nice
<StevenK> Although, preparing ten uploads at the same time was kind of cool.
<geser> StevenK: if you looking for a transition: libboost-*1.33.1 -> libboost-*1.34.0
<StevenK> Which isn't listed by pitti's cruft.
<Nafallo> oh! boost will make gnash installable? :-)
<pitti> hm, I cannot find any 1.33 boost packages in the archive
<StevenK> pitti: Oh, and you were right, even though the packages Build-Depend on libsnmp9-dev, the buildds still deal and install libsnmp-dev.
<pitti> StevenK: ah, indeed, apt-cache unmet depends on some 1.33 stuff
<StevenK> Ah, unmetdeps.
<geser> the debs are gone, but not the depends
<Nafallo> lovely :-)
<pitti> StevenK: right, because the package doesn't exist any more, but libsnmp-dev provides: it
<StevenK> pitti: Yeah, and I should have realised that before I changed openipmi ...
* StevenK shrugs. If Debian changes it, we'll just sync it.
<StevenK> Ugh. boost has a lot.
<StevenK> Actually, I need to fix one more for libsnmp
<Viper550> hi
<Viper550> Anyone here?
<EtienneG> hey guys
<EtienneG> regarding https://wiki.ubuntu.com/FreeSoftwareDrivers
<Nafallo> ho EtienneG 
<EtienneG> should the discussion also include peripheral (such as printers) ?
<Nafallo> s/o/i/
<EtienneG> ho, hi, it's all fine Nafallo !
<Nafallo> :-)
<EtienneG> specifically, I was thinking that HP should get a special mention for the work they do getting good support for their printers and MFP
<EtienneG> ie, HPLIP
<Nafallo> I would agree with that :-)
<Nafallo> dunno who makes that decision though.
<EtienneG> I'm just throwing the idea
<Nafallo> +1 from me then ;-)
<Viper550> You've been wanting ideas for a better recovery mode?
<Hobbsee> Viper550: probably on the mailing list?
<Viper550> Well, anyway, I'm going to embark on a mission that may make system building with Linux a bit less painful if your end-user messes everything up
<Hobbsee> cool.  not my decision, but cool
<seb128> Viper550: you might want to look at https://wiki.ubuntu.com/FriendlyRecovery
<Viper550> seb128: Actually, that's repair tools for the OS. I'm talking about those recovery partitions all those fancy Windows computers come with nowadays, just press a key on bootup, click a few buttons, wait a half-hour, and whammo! Fresh reinstalled system as it was out of the box!
<StevenK> pitti: Got a tick?
<pitti> StevenK: about to leave to lunch, but just leave your question, I'll read backscroll :)
<StevenK> pitti: Right. :-)
<StevenK> pitti: One of the packages listed as needing libsnmp love is lustre. Lustre is kernel module package that has been pulled from Debian, and it Build-Depends on 2.6.18, since the build system looks for a kernel at build time. I'm just wondering what we should do.
<pitti> erk
<shawarma> StevenK: Why not update it to 2.6.22?
<StevenK> Because I'm not a fan of patching their code to work against 2.6.22
<pitti> shawarma: that's not something we should do, unless someone is actually interested in that apckage
<StevenK> And I'm so not.
<pitti> StevenK: my recommendation so far: ignore it
<shawarma> pitti: Well..
<shawarma> StevenK: What does it need it for?
<pitti> StevenK: I can kill the libsnmp9 package and just leave this uninstallable
<shawarma> StevenK: Any idea t all?
<Hobbsee> damn.  no bulletproofX for kubuntu.
<StevenK> pitti: Sounds fine to me.
<StevenK> shawarma: Hum?
<StevenK> pitti: I *think* that's everything for libsnmp9.
<Nafallo> ooh. gnash IS installable :-)
<shawarma> StevenK: What does it need the kernel source for?
<shawarma> StevenK: Ah.. "kernel module package".
<shawarma> StevenK: I missed that :)
<StevenK> shawarma: :-)
<StevenK> shawarma: Consider taking a reading comphresion class? :-P
<hunger> When will the new networkmanager finally be installable?
<shawarma> StevenK: :(
<Nafallo> when pitti NEW'd nm-gnome? ;-)
<pitti> Nafallo: when Tonio_ actually uploads it :)
<Nafallo> hehe. oki :-)
<pitti> oh, there it is
<Nafallo> pitti: lunch? :-P
<pitti> it's called -applet now
<pitti> Nafallo: yeah, yeah, I promised my gf 15 minutes ago
<pitti> so, LUNCH!
<hunger> Hmmm... maybe ubuntu-desktop needs an update then to work with the new name?
<Nafallo> :-)
<Tonio_> pitti: it should be in the NEW queue since yesterday :)
<Tonio_> pitti: didi as you said, naming the package -gnome
<Nafallo> Tonio_: source -applet and binary -gnome? ;-)
<Tonio_> Nafallo: yes
<Nafallo> hehe. that might confuse a bit. I like it! :-)
<Tonio_> Nafallo: just wait a bit for someone to review and accept the package in NEW
<Nafallo> Tonio_: I would wait longer than that. I want to see how many bugreports it gets ;-)
<Tonio_> Nafallo: lol
<Tonio_> Nafallo: I don't use the gnome applet myself, but the new knetworkmanager works great
<Tonio_> Nafallo: nm-applet shouldn't be that buggy
<Nafallo> :-P
<seb128> is the old applet broken?
<Tonio_> seb128: when you tested, it worked with n-m 0.6.5
<seb128> right
<seb128> that's why I'm asking if it's broken for other people
<hunger> seb128: aptitude claims that network-manager-gnome depends ot network-manager = 0.6.4-6ubuntu7, so somebody must update the required version string...
<seb128> Tonio_: 
<seb128> src/wso-leap.c: * (C) Copyright 2006 Thiago Jung Bauermann <thiago.bauermann@gmail.com>
<seb128> src/menu-items.c: * (C) Copyright 1999, 2000 Eazel, Inc.
<seb128> src/eggtrayicon.c: * Copyright (C) 2002 Anders Carlsson <andersca@gnu.org>
<seb128> src/wso-wpa-eap.c: * (C) Copyright 2006 Novell, Inc.
<seb128> Tonio_: could you list those to debian/copyright?
<seb128> Tonio_: eggtrayicon.c is under LGPL
<seb128> could you also mention it to debian/copyright and make the package ship a COPYING.LIB with the LGPL text?
<seb128> pitti: ^ I looked at nm-applet, don't accept it for now
<Tonio_> seb128: okay, true that I didn't spend much time on the licencing part.... too boring :)
<Tonio_> let's go
<seb128> Tonio_: well, that's the most important part to get it accepted in the archive :p
<Tonio_> seb128: hehe, I know, but I didn't have that much time to make all the packages in one day ;)
<seb128> you had no pressure to upload
<seb128> take the time you need ;)
<Tonio_> seb128: the pressure I had is that I don't have internet at home :)
<Tonio_> thanks to france telecom :'(
<seb128> Tonio_: they don't want to take your money? ;)
<Tonio_> seb128: why shipping a copying.lib ? isn't juste adding the 4 paragraphs with the path to the lgpl enought ?
<seb128> Tonio_: I've opened http://bugzilla.gnome.org/show_bug.cgi?id=449111 upstream
<ubotu> Gnome bug 449111 in nm-applet "tarball sould ship the LGPL license text" [Normal,Unconfirmed]  
<Tonio_> seb128: I do pay but I'm disconnected for 2 month now
<seb128> Tonio_: no, the source should have a copy of the license
<Tonio_> just because someone unplugued me by error
<seb128> not cool
<Nafallo> Tonio_: I wouldn't pay for a service I don't have. why do you? :-)
<Tonio_> Nafallo: because I'll be reimboursed once the problem ends
<Nafallo> ah :-)
<ogra> seb128, the volume icon not reflecting the actual volume is a known bug i assume ?
<seb128> ogra: yes
<ogra> good 
<siretart> cprov: I figured out what happened to the PPA accepted mails: They are lacking the 'regular' X- Headers for upload notifications, so they ended up in my 'other lp messages' mailbox
<ion_> The new compiz package seems to use ccp instead of gconf. Is someone going to upload a config tool using it soon, or am i just being blind? :-)
<seb128> ion_: cpp uses gconf
<seb128> ccp
<seb128> ion_: a config tool using what?
<mvo__> ion_: compizconfig-setup-manager (ccsm) is uploaded, it may wait in NEW currently
* seb128 looks in NEW for mvo__
<ion_> seb128: Hm. I didnt really study what this ccp thing is, but i tried to do some changes using gconf and they didnt seem to apply, and i also noticed a new directory ~/.compizconfig. I expected its just using plain config files instead of gconf now.
<ion_> mvo: Alright, thanks.
<seb128> mvo: ccp should use gconf no?
<mvo> ion_: do you run gnome? or something else?
<mvo> seb128: yes
<ion_> mvo: Xfce
<mvo> ion_: what is in .compizconfig/config
<mvo> ion_: aha, ok. then it will default to .ini files
<shawarma> ogra: Do you tweak vm.swappiness on your edubuntu clients?
<ion_> mvo: The lines [general] , profile = , 
<seb128> ion_: you need to use GNOME ;)
<ogra> shawarma, nope
<mvo> ion_: is gconf always available under xfce?
<ion_> mvo: And Default.ini is empty.
<seb128> ion_: it detects the desktop and enable gconf if you use GNOME
<ogra> shawarma, we try to tweak as less as possible
<shawarma> ogra: I see. I just thought about it after you said you swap over the network. It might be worth it to try lowering the swappiness.
<ogra> shawarma, yep, ggod point, i'll look into it ... 
<shawarma> ogra: Cool.
<ion_> mvo: xfce4-session seems to depend on libgconf2-4
<ion_> seb128: I definitely would use Gnome if my computer had more memory.
<mvo> ion_: I guess that could be fixed, is there a environment var that can be used to uniq identify a runing xfce session?
<ion_> mvo: env | grep -i xf yields GDMSESSION=xfce4 and DESKTOP_SESSION=xfce4. I havent checked what defines DESKTOP_SESSION (e.g. does it exist if one uses startx instead of gdm).
<shawarma> mvo: I think the xfce session manager sets SESSION_MANAGER to something sensible.
<ion_> SESSION_MANAGER=local/luotain:/tmp/.ICE-unix/17772
<pitti> seb128: right, so if the current n-m-applet upload is bad, we should reject it
<Tonio_> seb128: I'm just fixing the licencing part
<Tonio_> pitti, seb128: reuploading... I hope it's okay now
* popey pokes imbrandon with bug 414866
* popey pokes imbrandon with debian bug 414866 :D  launchpad bug 112552
<ubotu> Debian bug 414866 in apt-mirror "apt-mirror: cleans out all files with tilde (~) in file name" [Normal,Fixed]  http://bugs.debian.org/414866
<ubotu> Launchpad bug 112552 in apt-mirror "Packages containing a tilde are deleted by clean.sh" [Undecided,Confirmed]  https://launchpad.net/bugs/112552
<Keybuk> the author of Planet needs to die in a raging green chemical fire
<hunger> How about adding ZFS support?
<evand> Keybuk: Aren't you the author of Planet?
<Keybuk> evand: damn
<evand> hah
* Keybuk burns himself
<evand> yeah, really.  What a terrible piece of software.
<Keybuk> it might be typo's fault, in which case I can burn thom
<Keybuk> (not because he wrote it, but because he suggested it <g>)
<imbrandon> popey, i have a fix for that i'll upload it today
<popey> yay
<popey> thanks imbrandon 
<shawarma> _ 
<shawarma> what the..
<shawarma> Ok, this is odd.
<Keybuk> evand: hmm, so the funny thing is, right; my feed looks right
* thom redirects Keybuk to mountain view
<Keybuk> and the ids are right
<StevenK> thom: Heh
<Keybuk> so Planet shouldn't've done that
<Keybuk> unless jdub broke it since I stopped maintaining it, of course <g>
<thom> also, 'henrink'?
<evand> hrm
<Keybuk> it's written to ignore dates and stuff from feeds (which are right anyway)
<Keybuk> and was written to cope with people changing feed urls
<shawarma> If I plug in my ipod really slowly, it starts charging and all that, so there's definitely a connection, but there's nothing in dmesg and it doesn't try to mount it or anything. If I just plug it in at regular speed, it's detected, and mounted, etc... wtf?
<Keybuk> so I figure someone broke it
<thom> Keybuk: it's never really coped with feed urls changing though, IME
* shawarma plugs and unplugs his iPod a few times more..
<shawarma> Yup. It's reproducible.
<shawarma> That's about a 4.6 on my wtf-o-meter.
<Keybuk> thom: the worst it used to do was assume it was a new blog, and only take the top two posts
* pbn pokes the channel with bug 36655
<Keybuk> even that bit seems to be broken
<ubotu> Launchpad bug 36655 in kdenetwork "pppd dies on connection" [High,Confirmed]  https://launchpad.net/bugs/36655
<ion_> shawarma: Perhaps something detects i was connected to a host / a peripheral was connected to me; it gives/drains power but doesnt talk USB; ill just ignore it. :-)
<davmor2> Hi devs.  Network manager just went away after an update is there a fix on the way or I can type in?
<pitti> seb128: ^ let's NEW this package to stop people from breaking their machines, shall we? /me looks
* netjoined: irc.freenode.net -> kubrick.freenode.net
<pitti> davmor2: if all goes well, you can install network-manager-gnome again in about two hours
<davmor2> pitti: okay thanks is it just one of those alpha moments then :)
<pitti> davmor2: yeah; you should pay attention to the packages apt-get dist-upgrade wants to remove
<pitti> and only upgrade instead of dist-upgrade if it's something important
<shawarma> ion_: I don't know, dude. It's really odd!
<pitti> Tonio_: hmm, I'm afraid you have to upload again. COPYING.LIB needs to be in the orig.tar.gz, not in the diff.gz
<davmor2> pitti: I never realised you could do that.  Also is there any reason why update-manager has stopped working?
<pitti> davmor2: update-manager -> mvo question
<davmor2> mvo: Any idea why update-manager has stopped working?
<Hobbsee> davmor2: no network connection, maybe
<davmor2> Hobbsee: no I can update via cli and synaptic just dies with u-m
<ion_> hobbsee: I was reminded of an old IRC quote of someone complaining about his Internet connection not working on IRC. :-)
<Hobbsee> ahhh
<Hobbsee> true that
<ion_> complaining on IRC, that is.
<Tonio_> pitti: hehe, I was pretty sure you would complain about that :)
<Tonio_> pitti: no time today, I'll upload tomorrow
<pitti> Tonio_: if you promise, I'll NEW it now to sort out the uninstallability
<pitti> Tonio_: or no, wait, that would make the orig.tar.gz name ugly
<siretart> 
<mvo> davmor2: update-manager is working for me, so you have to be a bit more specific :) best is probably to either file a bugreport or come to #synaptic and give me more details
<seb128> re
<seb128> pitti: feel free to look at it
* dholbach hugs seb128
<Tonio_> pitti: as long as the current applet works.... that can wait tomorrow I guess
<seb128> pitti: I didn't reject it because I was too lazy to write the rejection mail, I prefer to ping on IRC, wait on a new upload and accept this one :p
<seb128> pitti, Tonio_: there is no requirement for the license to be in the orig I think
<Hobbsee> mvo: i think someone else mentioned it in #ubuntu+1 a few days ago
<pitti> seb128: there is
<pitti> seb128: the orig.tar.gz itself needs to be redistributable
<Tonio_> pitti: the point is that I didn't want to touch the tarball :)
<Tonio_> pitti: but I'll rebuild it, no problem
<seb128> pitti: why? the diff.gz is at the same place on the server
<pitti> Tonio_: upstream needs to fix his' anyway
<seb128> pitti: I've opened a bug upstream
<pitti> seb128: yeah, I know it's picky
<Tonio_> pitti: of course, I'll ping upstream on that point
<pitti> thanks
<seb128> Tonio_: I opened a bug on bugzilla already
<Tonio_> seb128: just read that, thanks :)
<xivulon> Hi, anybody familiar with the suspend/hibernation mechanism?
<xivulon>  I'd need some help to make it work with wubi (wubi is installed in a file mounted via fuse). I played a bit with acpi-support settings to no avail.
<Keybuk> http://awn.wetpaint.com/page/Make+Topaz+Ideas+a+Reality
<Keybuk> ^ pretty
<ion_> Unreadable due to opacity.
<desrt> Keybuk; 'sup?  haven't heard from you in a while :p
<Keybuk> desrt: I'm good :)
<desrt> you'd be better if you had tea.
* Hobbsee dumps the tea on desrt 
* desrt wonders if this is shirish-induced rage
<Hobbsee> nah
<desrt> just normal this-is-how-i-feel-like-treating-desrt-today stuff?
* Mithrandir tickles Hobbsee 
* desrt goes to refill his tea and get a raincoat
* Hobbsee stomps on Mithrandir's feet
* Mithrandir har ironclad shoes
<Hobbsee> desrt: it's impending-maths-exam-induced rage
<Hobbsee> Mithrandir: dont make me kick you in the shins.  people tell me that it hurts.
<Mithrandir> Hobbsee: maybe I'm wearing full plate armour.
<Hobbsee> Mithrandir: which means you'll have a terrible time trying to wander around debconf
<Mithrandir> Hobbsee: motorised full plate armour.
<Hobbsee> hah
<Nafallo> lol
<Hobbsee> good luck with that
<thom> i tend to find plate armour and a large sword does wonders for getting around places
<Hobbsee> thom: true - but i'm not allowed to take it to work.
<davmor2> Hobbsee: borrow this stick of dynamite place it in the back of the plate mail :)
<Hobbsee> the sword, that is.
<Hobbsee> davmor2: ahh.  right.  blow all the painful people at work up
<Hobbsee> ahem.  wait.
<Hobbsee> i'm not allowed to do that, dammit.
<Nafallo> hmm
<Nafallo> xv is screwed for playing videos @ i845GE again...
<Nafallo> both xine and mplayer affected.
<desrt> Hobbsee; ah.  that'll get to anyone.
<Hobbsee> desrt: yes.  someone else should have to do it.
<desrt> i'm fairly sure that, even down-under, exams don't work like that
<Hobbsee> true.
<Hobbsee> unfortunately
* desrt commits to spending the rest of the day filling in gtkdoc comments
<pitti> mvo_: I try to teach synaptic not to display debconf questions. However, setting DEBIAN_FRONTEND=noninteractive does not work
<pitti> mvo_: is there a trick?
<mvo_> pitti: hrm, that is most likey a synaptic bug
<pitti> mvo_: can I set the priority somehow? setting it to critical should work as well for my purpose
<mvo_> pitti: DEBIAN_PRIORITY=critical should work
<pitti> mvo_: that did it, thanks!
<psusi> it seems that VAR=$((VAR+1)) is a bashism... how would one do this under dash?
<Mithrandir> \u@\h:\w$ A=1
<Mithrandir> \u@\h:\w$ A=$(( $A + 1 ))
<Mithrandir> \u@\h:\w$ echo $A
<Mithrandir> 2
<Mithrandir> (with dash)
<psusi> what was with the "\u@\h:\w$" stuff leading eac of those lines?
<psusi> looks like line noise ;)
<ogra> some people call that aprompt i think :)
<ogra> heh
<Mithrandir> dash doesn't do prompt expansions like bash does
<ogra> *a prompt
* ogra wonders if there is something wrong with bazaar.lp.net ... this push takes 20min already
<Keybuk> psusi: it's not a bashism
<Keybuk> psusi: $((expression)) is valid POSIX, and supported by dash
<Keybuk> quest scott% dash -c 'echo $((4 + 3))'
<Keybuk> 7
<Keybuk> though the missing $ on VAR may be a bashism
<Keybuk> $(($VAR+1)) is portable
<Keybuk> Mithrandir: why are you exporting PS1 ?
<Mithrandir> Keybuk: hysterical raisins, I suspect.
<ogra> yummy
<Keybuk> Thought of the Day:  if you blog, make sure your e-mail address is obtainable somewhere ... just in case some nice man likes a post, and wants to hire you
<Hobbsee> Keybuk: heh.  smart.
<Hobbsee> Keybuk: some people try to stay slightly private :P
<Hobbsee> seems they never suceed, though.
<Keybuk> heh
<Keybuk> the irony of private blogging is compelling
<Hobbsee> Keybuk: there's a difference between a person online, and that person being able to be traced back in their home country
* Hobbsee wonders which bit of kde will crash next...
<Viper550> I'm going to begin work on a project for possibly Ubuntu
<Hobbsee> Keybuk: unfortunately, this gets rather blown away when you get invited to a UDS, or whatever.
<LaserJock> Hobbsee: kde crashes? ;-)
<Hobbsee> LaserJock: occasionally
<Hobbsee> gnome themes still crash more for me
<LaserJock> I haven't really had any problems since I got rid of NetworkManager
<pochu> Viper550: that's cool! What are you thinking about? Triaging bugs, packaging...?
<LaserJock> at first I thought Feisty must have done something nasty, then Burgundavia told me to try removing NM, now it's pretty rock solid
<Viper550> Actually, most specifically, it could really help out Dell. I'm planning on doing a System Recovery system for Linux
<Hobbsee> Keybuk: btw - why did you flood planet?
<Keybuk> Hobbsee: Planet bug
<ogra> Hobbsee, global warming
<Nafallo> Hobbsee: changed feed URL :-)
<Hobbsee> more to the point "are you aware that you flooded it?"
<Hobbsee> ahhh
<Keybuk> Hobbsee: I unflooded it, no?
* Hobbsee floods ogra 
* ogra grins
<Hobbsee> planet debian is flooded still
<Keybuk> I changed my feed URL to exclude posts about PPL training, since that's rather off-topic
<Keybuk> Hobbsee: yeah, I told mako
<Hobbsee> Keybuk: yeah, ubuntu is
<Hobbsee> ahhh
<Viper550> pochu: sorta like this (scroll down) http://www.hardocp.com/article.html?art=MTI5Nyw5LCxoY29uc3VtZXI=
* Hobbsee nwo wonders what ppl is
<LaserJock> people
<Hobbsee> ah
<Viper550> My plan is to make it utilize Mondo
<Keybuk> Hobbsee: learning to fly
<somerville32> Rubber flooring?
<Hobbsee> Keybuk: oh *neat*
<pochu> Viper550: a recovery tool?
* Hobbsee hides from all scary keybuk-carrying planes
<Viper550> pochu: you know how those newer XP computers have those recovery partitions and all that?
<pochu> Nope
<Viper550> you press a key on bootup and it reformats and everything
<Hobbsee> that's....risky
<Hobbsee> *holding key, absent mindedly*...."oh shit, where's my documents???"
<Viper550> Yeah, they have them for Windows system builders, but why not a Linux-based one? Also, it does still give you options once you hit it
<pitti> BenC: do you think it would be reasonable to make the bcm43xx module fail to load at all if there's no firmware? then we could avoid rmmod'ing it when installing the firmware (which is not recommended AFAIK)
<Viper550> Hobbsee: just go here, they've got pictures of Gateway's utility: http://www.hardocp.com/article.html?art=MTI5Nyw5LCxoY29uc3VtZXI=
<Nafallo> Viper550: since linux is more stable and doesn't need as much reformating? :-)
* Nafallo goes to hide in the kitchen now ;-)
<Viper550> <Nafallo> but still, what if you mess something up? Dell's ubuntu machines have DOS based recovery
<Nafallo> Viper550: then we have what seb128 linked you earlier? :-)
<Viper550> Mondo
<Nafallo> https://wiki.ubuntu.com/FriendlyRecovery
<Nafallo> you might want to integrate your idea into that framework anyway...
<Viper550> But, I'm thinking about this as a universal system that's distro-independent, although the recovery enviroment could be Ubuntu based
<Viper550> Codename Iono is about to begin
<somerville32> Oh my.
<Hobbsee> speaking of blogs.  i could swear my blog had more info than that before.
<LaserJock> hmm, why wouldn't you just stick a LiveCD squashfs on a separate partition and load that up as a "Recovery Partition"?
<LaserJock> or is that the idea
<BenC> pitti: it's a possibility. Can you file a wishlist bug to that affect?
<pitti> BenC: sure
<Viper550> <LaserJock> I'm not quite sure, but the recovery partition will utilize a Mondo image possibly
<Viper550> And, it will also use an Ubuntu based GUI to launch and manage it
<Viper550> Adding it to launchpad
<Hobbsee> Mithrandir: can you give back kdemultimedia on amd64 and ia64 please?
<Viper550> https://launchpad.net/iono
<zasf> pitti: hey Martin
<pitti> hi zasf
<zasf> pitti: just got your email
<Mithrandir> Hobbsee: done
<Hobbsee> Mithrandir: thanks
<pitti> zasf: I'll upload the new package today; I'm still working on some stuff, though
<zasf> pitti: I'm so glad you merged it :)
<pitti> zasf: it was much more changes than I expected TBH
<zasf> what do you mean? dirty code?
<pitti> zasf: TBH the LRMDriverHandler seems a bit overkill to me, and I cannot test it
<pitti> zasf: no, just more changes than I thought you made :)
<zasf> pitti: sorry about that
<pitti> zasf: but if you have hardware that's covered by that default configuration file and it works, that's fine :)
<zasf> pitti: I realized to late that I personalized too much the code
<pitti> zasf: oh, no need to be sorry; I just meant it took me a while to grind through it
<psusi> Keybuk, so the bashism is that it doesn't require the $ inside the $()?
<Hobbsee> hiya heno 
<pitti> zasf: but in any case, do you think we can clean up lrm_driver.py a bit? it currently has a lot of internal and duplicated knowledge about lrm-common
<heno> hey Hobbsee
<pitti> zasf: like the module grouping
<pitti> zasf: this should go into lrm-common itself through some easy interface, and that class should use it
<zasf> pitti: I'll have a look at it
<zasf> pitti: I also have done some more tests wich bcm43xx, will share my thoughts via email
<zasf> pitti: if that is ok with you
<heno> To all: Please note the change in bug states that takes effect tomorrow: https://lists.ubuntu.com/archives/ubuntu-devel/2007-June/023836.html
<pitti> zasf: appreciated, thanks
<pitti> zasf: after some fixes it works great for me now, too
<pitti> zasf: nice job! *hug*
<zasf> pitti: thanks a lot :D
<zasf> pitti: Ubuntu is so much fun
<zasf> pitti: I'll get back to you via email, gotta go now
<zasf> goodbye everybody
<LaserJock> heno: hmm, I've got a bit of an issue with "triaged", did the LP guys do a lot of user consultation on that one?
<Lazesharp> hi guys, how should I go about making a comment on a gutsy spec?
<Hobbsee> Lazesharp: on the whiteboard, iirc?
<LaserJock> Lazesharp: it should have a wiki page attached to it
<Hobbsee> or teh wiki page
<Lazesharp> I thought the whiteboard was for status comments?
<Lazesharp> so on the wiki page then
<Lazesharp> right, cheers
<psusi> and if dash doesn't do prompt expansion, then how do we still have a functioning prompt?
<LaserJock> "we" as in?
<psusi> oh wait... we're still using bash for the user shell, but dash for /bin/sh?
<psusi> ubuntu
<LaserJock> exactly
<LaserJock> user shells are still bash
<psusi> why did we switch to dash for /bin/sh then?
<mjg59> Because it's faster
<Mithrandir> it's faster and more standards-compliant
<heno> LaserJock: there was a BOF at UDS Sevilla
<Hobbsee> heno: he was part of the discussions before hand, over lunch
<heno> making it just perfect for everyone is impossible
<Hobbsee> this is true
<psusi> hrm... it is faster for bash to fork and execute dash to interpret the script instead of interpreting it directly?  wait... doesn't bash interpret it directly if it sees it's a shell script?
<Mithrandir> no, it doesn't
<LaserJock> heno: yes, and I only remember Rejected getting split into won't fix and not a bug 
<psusi> hrm... only does that if you . foo.sh eh?
<LaserJock> heno: my issue is that when I talk about triaging anywhere, there's at least a one or two people who have no idea what the word "triage" means, especially in non-English countries
<Lazesharp> direct them to a combination of a translation tool and a dictionary
<LaserJock> that's a bit of a cope out, IMO
<LaserJock> *cop ?
<Lazesharp> yeah, cop
<Lazesharp> call it "bug assessment" or something?
<heno> it's difficult to capture that process in any one word
<LaserJock> in fact, I think it might be wise to assess our heavy use of "triage" in BugSquad/QA
<heno> that would be a reason for not introducing any technical words that you have to explain
<Lazesharp> question re: commenting on the wiki, where should I comment? should I create a section called "Comments" or something? what's the generally accepted standard?
<LaserJock> at least ones that people aren't commonly going to know
<heno> it's usually good advice but it cannot always be avoided
<LaserJock> Lazesharp: that works
<LaserJock> heno: well, I just know of one person that was avoiding helping triaging because they didn't know what the word meant
<LaserJock> once I told them then they were happy to help
<LaserJock> anyway, it's not a big deal as long as we're aware that we need to document what the the status's mean
<ion_> mvo: You packaged compizconfig-setup-manager, right? Could you perhaps upload the source package somewhere it could be downloaded from until its available in gutsy?
<pitti> ion_: source NEW queue is published daily
<pitti> http://people.ubuntu.com/~ubuntu-archive/queue/
<ion_> pitti: Thanks, good to know.
<pitti> oh, unless he didn't upload it at all yet, of course
<Lazesharp> ok, final question guys, what are the chances of comments actually being read by those developing the specs?
<Lazesharp> actually, don't worry, I just noticed the subscription thing
<Keybuk> Lazesharp: any edits to the spec will show up in the assignee's INBOX
<Keybuk> of course, they may not actually reply or anything
<Lazesharp> yeah, thanks, I just noticed
<Lazesharp> I have to admit guys, I'm impressed, normally the sort of questions I've just asked in a development channel would be trampled upon and I'd be set on fire (or the IRC equivilent). It's a testament to the Ubuntu community spirit. :)
<Lazesharp> makes me want to get involved that much more
<pitti> mvo, Riddell: FYI, I added my xorg.conf formatting fix to guidance-backends and dropped the code copy from restricted-manager; displayconfig-gtk should do the same now
<bryce> hi all, I've upgraded linux-restricted-modules with the new fglrx:  http://people.ubuntu.com/~bryce/Testing/
<bryce> the debs work ok on my radeon system, and I've had one other person successfully install them, but would appreciate additional testing feedback
<bryce> the specific packages we installed (YMMV) are:  fglrx-control, xorg-driver-fglrx, fglrx-kernel-source, linux-restricted-modules-common, linux-restricted-modules-2.6.22
<bryce> oh, btw, since fglrx doesn't support composite, don't forget to turn Compiz off before running these
<rbs-tito> Hi guys, I've just finished my first patch and the guys at bugsquad said it is OK. Would anyone care to take a look?
<rbs-tito> https://bugs.launchpad.net/ubuntu/+source/desktop-effects/+bug/120853
<ubotu> Launchpad bug 120853 in desktop-effects "Repeated word in error message" [Undecided,Confirmed]  
<Lazesharp> are comments allowed on specifications that have been accepted?
<Lazesharp> it says "If it is Approved, contact the Assignee or another knowledgeable person before making changes." but I'm not certain that includes comments?
<bryce> Lazesharp: yup, comments are fine
<Lazesharp> thanks
<bryce> heya mvo
<mvo> hey bryce!
<bryce> mvo, do you know where glatzor is?  I haven't seen him in a few days.  Conferencing perhaps?
<mvo> bryce: learning for his final exams :)
<bryce> ahhh
<mvo> bryce: I talked to him today, he is alive and kicking, just very busy - anything in particular you want to talk to him about?
<bryce> nope, just curious how he was doing
<ogra> bryce, hey
<bryce> I've not been tinkering with displayconfig lately; trying to get bugs and packaging under control
<bryce> heya ogra
<bryce> mvo, wish him luck in his exams :-)
<ogra> bryce, i told you already ltsp works great without xorg.conf ... but now i discovered one prob ...apparently the X server cant restart properly, complaining about the framebuffer 
<bryce> hrm
<ogra> i suspect something hogs it even Xorg is gone
<bryce> ogra: one thing I've been thinking we could try is running xorg with just the Screen, Device, and Monitor sections missing
<mvo> bryce: I will, thanks :)
<bryce> ogra: in theory, with xserver 1.3 that should work, however I haven't tested it as extensively as I want to 
<bryce> ogra, perhaps GDM?
<ogra> bryce, well, that would still mean i have to use debconf to configure it ... 
<ogra> bryce, well, ldm ... we have our own display manager ...
<ogra> but the thing is that it works fine with a file created by Xorg -configure 
<bryce> hmm, I think I ran across an option for gdm to force it to really restart... dunno if that relates, but lemme dig it up
<ogra> which i would assume to use the same values as if i run it without any config
<ogra> so its somehow related to the existence of the file
<bryce> I bet that's true
<bryce> aha, in /etc/gdm/gdm.conf there's an "AlwaysRestartServer" option
<bryce> I don't know anything about ldm but if it's gdm-like, maybe it has a similar thing going on?
<ogra> well, i cant even run startx from the commandline
<bryce> hmm
<ogra> i could implement it, yes 
<bryce> is ldm running when you try to run startx?
<bryce> if it isn't, then my guess would be wrong
<bryce> do you happen to have the error message handy?  I could do some poking around for you
<ogra> nope. ldm isnt running, i clean the processlist
<ogra> i'm not near my lab atm, but i can get it for you tonight ... i'll file a bug 
<bryce> ok cool
<Il0v3LuCifer> howdy good folks
<Il0v3LuCifer> *hint*: would be good if you could customize from repositories and pull from different variants of ubuntu then install all related dbg packages, like a meta dbg package for further scrutinization of segfaults
<Nafallo> hmm. is apport usuable from cli? :-)
<Nafallo> i.e. would it make any sence at all on a server?
<pitti> Nafallo: apport-cli :)
<pitti> Nafallo: that's the intent, yes
<Nafallo> pitti: was that implemented in feisty already? :-)
<pitti> Nafallo: es
<pitti> yes, even
<Nafallo> kewl. installs then :-)
<Nafallo> not that I think it will be used much but... ;-)
<Kmos> pitti: check your mail
#ubuntu-devel 2007-06-20
<mneptok> omg. a Riva TNT.
* pochu too
<pochu> a Riva TNT2 64 :/
<mneptok> the Diamond Viper V550 was a TNT card. not even TNT2.
<rbs-tito> http://www.pastebin.ca/577585 Could someone take a look at this? The objective is to add a trailing slash to Firefox bookmarks if there isn't one already, the code starting from line 2 is mine. 
<rbs-tito> For bug 120720
<ubotu> Launchpad bug 120720 in firefox "Bookmark image icons" [Undecided,Confirmed]  https://launchpad.net/bugs/120720
<jsgotangco> LaserJock: congratulations!
<Burgundavia> LaserJock: indeed, congrats
<Burgundavia> hey jsgotangco
<jsgotangco> hi
<bhale> hi LaserJock, jsgotangco Burgundavia 
<bhale> duderinos!
<jsgotangco> hehe
<Burgundavia> hey bhale
<LaserJock> thank jsgotangco and Burgundavia 
<bryce> welcome aboard LaserJock :-)
<Hobbsee> where's he boarding now?
* #ubuntu-devel  [freenode-info]  if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
<manchicken> Any packagers in the house?
<RAOF> Well, yes.
<RAOF> Although that introduction suggests that #ubuntu-motu will be a more appropriate forum for whatever it is you actually want to ask :)
<manchicken> Well, I'm a developer, and need I'm just needing someone to tell me where to put additional missing dependencies on packages?
<Hobbsee> manchicken: what's up?
<Hobbsee> RAOF: he writes adept and such
<Hobbsee> or cowrites it
<manchicken> Hobbsee: tagcoll isn't in the adept deps.  Trying to figure out how to save someone the trouble.
<RAOF> Ah, that makes more sense.  Sorry manchicken :)
<manchicken> RAOF: Not a problem at all :)
<manchicken> RAOF: If I was trying to package--which I'm not :)--your answer would have been perfect :)
<manchicken> And spot on.
<Hobbsee> manchicken: as in, how to add the build dep?
<manchicken> yup :)
<Hobbsee> in debian/control
<manchicken> And where's the package search engine thingy that Riddell always uses when I scream that I'm missing a lib and don't know what package it is in?
<manchicken> I really should bookmark that.
<Hobbsee> apt-cache search foo?
<Hobbsee> packages.ubuntu.com ?
<StevenK> apt-file search <file> ?
<RAOF> ^^^ is right, as long as you've built the apt-file database.
<manchicken> didn't know about apt-file
<manchicken> That's a nice one to know.
<RAOF> Yes.  It's like a supercharged "dpkg -S" :)
<manchicken> Ah.h
<RAOF> Which, if you're not familiar with it, will search your currently installed packages to see which packages own files you're interested in.
<manchicken> Yeah, I know that one.
<manchicken> It's the other way around I didn't know :)
<RAOF> Yeah, apt-file is really useful :)
<manchicken> I know the code, but still figuring out a lot of the packaging quirks.
<manchicken> It's ironic that many of the packagers regard the hackers as cleverer, while many of the hackers regard the packagers in the same fashion.
<fabbione> morning
<Hobbsee> morning fabbione!
<manchicken> Okay, so libtdb1 comes with a .so, but not the .la that libtool insists on making it use.  Is this a new thing that we're not putting .la's in packages anymore?
<Fujitsu> libtdb-dev?
<RAOF> I thought we *never* put .la's in packages?
* Starting logfile irclogs/ubuntu-devel.log
<pitti> Good morning
<LaserJock> morning pitti 
<Hobbsee> morning pitti!
<StevenK> pitti: Morning! The libiw28 transition should be done now, too.
* pitti hugs Ste"transition master"venK
<Hobbsee> heh
* Hobbsee hugs pitti 
* StevenK grins
<StevenK> Funnily enough, my nick hilight didn't pick that up.
<pitti> StevenK: only libsnmp9 reverse dependency left is snmptrapfmt
<pitti> StevenK: that's small enough now to kick it out of the archive
<StevenK> Hum? I so uploaded that one.
<StevenK> In fact, I remember doing it.
<StevenK> pitti: Give me a few seconds, I'm just sponsoring nagios-plugins which spuriously Build-Depends on libsnmp-dev
<pitti> snmptrapfmt | 1.11build1 | gutsy/universe | source, amd64, i386, ia64, powerpc, sparc
<pitti> and it built everywhere, too
<pitti> Hobbsee: last libiw28 rev dep: xsupplicant
<StevenK> pitti: xsupplicant is in Accepted
<Hobbsee> ?
<pitti> Depends: snmpd, libsnmp9
<StevenK> Or should be
<pitti> StevenK: that almost looks like a manually set dependency, not from dh_shlibdeps
<StevenK> pitti: Is that snmptrapfmt?
<pitti> StevenK: yes
<crimsun> Depends: snmpd, libsnmp9
<StevenK> pitti: Right. I shall prepare 1) a -1ubuntu1 upload, and 2) a sharp knife to stab the maintainer in the face with.
<pitti> StevenK: for 2), a sharp patch and bug report might be more efficient :)
<pitti> StevenK: xsupplicant> ah, indeed
<Hobbsee> pitti: never underestimate the use of sharp knives
<StevenK> Oh, my god!
<StevenK> Conflicts: none
<StevenK> Replaces: none
<StevenK> EAT FLAMING DEATH, Jochen Friedrich!
<pitti> lol
<pitti> StevenK: well, just fix it and point him to the MoM output or so
<pitti> too bad that sync-source doesn't work in the other direction :-P
<StevenK> I shall do so.
<StevenK> pitti: Heh, now that would be cool.
<StevenK> Hrm. Now libsnmp-dev doesn't turn up in shlibs:Depends
<pitti> StevenK: FYI, /cruft/ on people updated
<pitti> StevenK: why should -dev turn up there?
<pitti> LaserJock: congrats to your -core-dev badge!
<StevenK> Er, sorry. libsnmp at all
<StevenK> Just digging, it doesn't even link against libsnmp
<StevenK> Because some bright spark commented out the LIBS directive in the upstream Makefile.
<StevenK> If I find this guy ...
<StevenK> Better.  Depends: libc6 (>= 2.5-5), libsnmp10 (>= 5.3.1), snmpd
<pitti> yay
<StevenK> pitti: Okay, snmptrapfmt uploaded.
<hunger> Any progress on making apt and networkmanager installable again on gutsy?
<pitti> hunger: n-m-applet still needs a fix before it can pass NEW
<pitti> hunger: Tonio wanted to upload it today
<dholbach> good morning
<pitti> mjg59: does http://launchpadlibrarian.net/8036236/laptop-mode-tools_1.34-1ubuntu1.debdiff look sensible to you?
<carlos> segfault: hi, around?
<pitti> seb128: are you using keescook's greasemonkey script for stock bug replies? where can I find them?
<seb128> pitti: no, I'm not, I've the basic version I'm using since the Oslo sprint
<seb128> dunno where he has his scripts, that's something I've planned to ask as well ;)
<pitti> seb128: ah, ok; I gave greasemonkey another try, and this time it actually works (not firefox-greasemonkey package, but getting it from upstream)
<seb128> pitti: http://outflux.net/greasemonkey
<pitti> ah, I looked on people
<Hobbsee> pitti: seb128 a stupid question..but how does one actually use it?
<pitti> Hobbsee: as I said, the package doesn't work; Extras -> Addons -> Download -> Greasemonkey -> restart ffox
<dholbach> install greasemonkey extension for your browser, install the script, go :)
<pitti> Hobbsee: I use right-click on a .user.js, 'view source', if I like it, click the install button
<seb128> Hobbsee: in epiphany-browser right click on the .js and install
<pitti> voila
<seb128> dunno about firefox
<Hobbsee> oh, forgot to restart the browser
<pitti> wow, http://outflux.net/greasemonkey/lp_stockreplies.user.js kicks ass
<pitti> keescook: ^ *hug*
<Hobbsee> pitti: seb128 could figure out how to install it - just not use it. 
<seb128> ;)
<seb128> Hobbsee: open a launchpad bug page
<pitti> seb128: before I used the hardcoded reply version, but this one is so great
<seb128> it adds control you can use on the page
<seb128> pitti: right
<Hobbsee> seb128: wah.  why do i see no control?
<Hobbsee> or am i looking for the wrong thing, or what?
<seb128> Hobbsee: sec
* Hobbsee starts to suspect that she's just moronic or something.
<Hobbsee> oh wait.  err, are the stock replies on the bug page already there?
<seb128> no
<Hobbsee> didnt think so
<Hobbsee> didnt realise you couldn't just hit "add a comment"
<dholbach> Hobbsee: did you try to change the state of the bug?
<Hobbsee> dholbach: tryng now
<seb128> the version from kees seems to do nothing
<Hobbsee> that's...what i'm finding
<Hobbsee> it'll add the comment, but wont change anything else
<seb128> you should have entries and button to add actions
<Hobbsee> found them.  added them.  still doesnt seem to do anything
<Hobbsee> ahhh, now it seems to wokr
<pitti> seb128: hmm, I cannot get keescook's script to set the bug status; does that work for you?
<Hobbsee> pitti: it's case sensitive
<pitti> I typed 'Fix Released', doesn't work
<Hobbsee> dunno what "name" actually does, though
<seb128> pitti: no, it doesn't work at all for me, doesn't display any widget
<pitti> Hobbsee: it's the name of the reply, that will appear between the [] 
<Hobbsee> ahhh
<Hobbsee> ohhh, right.
<Hobbsee> yes
<Hobbsee> pitti: it's wokring fine here
<pitti> Fix+Released and Fix%20Released don't work either
<Hobbsee> !responses
<ubotu> response is https://wiki.ubuntu.com/Bugs/Responses
<Hobbsee> it should just be Fix Released, no quotes or anything
<pitti> Hobbsee: ah, I additionally gave it an assignee and priority, it works now
<Hobbsee> :)
<Hobbsee> okay, that's very cool
<Hobbsee> thanks keescook :)
<Hobbsee> hiya Tonio_ 
<seb128> firefox is the suck
<Tonio_> hey Hobbsee
<seb128> could it make any harder to install greasmonkey? ;)
<Hobbsee> seb128: you mean the ubuntu version of firefox sucks.
<seb128> no, I mean the software sucks when you are used to something easy to use like epiphany
<seb128> I'm trying to install greasmonkey for 5 min now
<Hobbsee> seb128: it just works in vanilla firefox
<seb128> "vanilla" like "non Ubuntu"?
<carlos> seb128: isn't it in Ubuntu already?
<Hobbsee> seb128: yes.
<carlos> seb128: at least I show up in apt-cache search
<carlos> s/I/It/
* ajmitch does the waiting for root filesystem dance again
<seb128> carlos: that version is outdated and buggy
<carlos> seb128: maybe you should ask an Ubuntu developer to update it... they usually are in this channel
* carlos hides
<seb128> carlos: well, I don't really care about the package, I'm trying to use the software UI atm :p
<seb128> I managed to install it
<seb128> now I have an "install" button when opening the .js
<seb128> clicking on it does nothing though
<seb128> I'm wondering if it does install and gives no feedback
<seb128> or doesn't install
<Hobbsee> seb128: i believe that ubuntu has disabled the auto-updater, which buggers all this stuff up
<pitti> hi Tonio_ 
<Hobbsee> with the mozilla binaries, it all works perfectly.  *shrugs*
<pitti> seb128: when I click on the install button, the yellow bar disappears and it's installed
<seb128> pitti: k, so it's buggy here
<pitti> and that's the standard ubuntu ffox
<seb128> clicking on install doesn't make the bar disappears
<seb128> ah, it worked after reloading the page
<Tonio_> pitti: will upload np-applet with the licence in the tarball in a moment
<Tonio_> pitti: finally, should be okay this time :)
<pitti> Tonio_: yay
<seb128> Tonio_: your debian/copyright is not really exact
<seb128> src/wso-leap.c:
<seb128>     (C) Copyright 2006 Thiago Jung Bauermann <thiago.bauermann@gmail.com>
<seb128> there is also "src/nm-gconf-wso-leap.c: * (C) Copyright 2006 Thiago Jung Bauermann <thiago.bauermann@gmail.com>"
<seb128> and the corresponding .h
<seb128> same for src/nm-gconf-wso-wpa-eap.c which is under the Novell copyright
<seb128> and the .h
<seb128> Tonio_: src/applet.c has also "(C) Copyright 2001, 2002 Free Software Foundation"
<seb128> Tonio_: src/menu-items.c also "This also uses code from eel-vfs-extentions available under the LG"
<seb128> Tonio_: src/menu-items.c also "This also uses code from eel-vfs-extentions available under the LGPL"
<asac> pitti: seb128: anyone can help and NEW/review firefox-granparadiso ?
<pitti> if me: on Friday
<StevenK> Ohh, firefox 3
<asac> yeah :)
<StevenK> Does that have a hope in hell of getting backported to Feisty?
<Kmos> asac: it will fix most of the LP bugs ?
<asac> StevenK: we have -trunk builds in mozillateam preview archive
<asac> !mozillatest
<ubotu> Sorry, I don't know anything about mozillatest - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<asac> hmm
<asac> !moztest
<ubotu> The Mozilla-testing repos can be found at: https://wiki.ubuntu.com/MozillaTeam/PreviewArchives. Please remember these are testing repos, the packages in these repos are not stable and may break things on your system. Use with caution. Please report bugs found from these packages to: https://wiki.ubuntu.com/MozillaTeam/PreviewArchives/Bugs.
<asac> :)
<Kmos> some friend mine is reporting this from gutsy
<Kmos> emdebian-tools (0.2.0) ...
<Kmos> Unable to determine apt-cache policy for Debian main! at /var/lib/dpkg/info/emdebian-tools.postinst line 132.
<Kmos> trying to install it from upgrade
<Kmos> status error: 255
<Hobbsee> !mozillatest is <alias> moztest
<Hobbsee> !mozillatest is <alias>moztest
<Hobbsee> !mozillatest
<ubotu> Sorry, I don't know anything about mozillatest - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Hobbsee> !mozillatest is <alias>moztest
* Hobbsee kicks ubotu 
<gnomefreak> Hobbsee: !moztest
<gnomefreak> but i think i kept it in -mozillateam channel but that is changable
<Chipzz> gnomefreak: I think she's trying to make an alias for it, not ask what it means ;)
<asac> gnomefreak: mozdtest did work here (look a few lines above)
<Hobbsee> there we go.
<Hobbsee> !mozillatest | asac 
<ubotu> asac: The Mozilla-testing repos can be found at: https://wiki.ubuntu.com/MozillaTeam/PreviewArchives. Please remember these are testing repos, the packages in these repos are not stable and may break things on your system. Use with caution. Please report bugs found from these packages to: https://wiki.ubuntu.com/MozillaTeam/PreviewArchives/Bugs.
<gnomefreak> ah it did :)
<asac> Hobbsee: great ;)
<Hobbsee> gnomefreak: bot's obviously changed a bit since i last added factoids.   it's misbehaving.
<Hobbsee> gnomefreak: seems you have to say foo is bar, no foo is <alias> bling (x2), instead of just going foo is <alias> bling
<gnomefreak> hmmmmmm
<gnomefreak> that is odd
<Hobbsee> yes
<Tonio_> seb128: okay I'll grep for the copyright in the code and indicate them file by file :)
<seb128> Tonio_: thanks ;)
<Kmos> any kernel developer ?
<Kmos> bug 120677
<ubotu> Launchpad bug 120677 in linux-source-2.6.20 "uuid is never the same with w810i phone" [Undecided,Needs info]  https://launchpad.net/bugs/120677
<Hobbsee> Kmos: doubt benc is awake yet
<Kmos> :(
<Kmos> bug 41809
<ubotu> Launchpad bug 41809 in alsa-driver "PCM level is reset to 0 after every reboot" [Medium,Needs info]  https://launchpad.net/bugs/41809
<carlos> pitti: hi, around?
<mjg59> Doesn't sound like an alsa-driver issue
<pitti> carlos: hi
<carlos> pitti: hi, we have a user on #ubuntu-translators complaining about Persian not being offered as a language to install on install time
<pitti> carlos: hm, we have language-pack-fa, so this is rather an installer problem? evand?
<carlos> pitti: ok, got more info
<carlos> seems like the installer is not in Persian with all releases after Dapper
<StevenK> Neat
<carlos> pitti: ok, the problem is with liveCD, I guess we are not including Persian language pack with liveCD, are we?
<pitti> carlos: we don't, but that's not the problem (it can be installed off the network)
<pitti> carlos: I suspect there is a problem with supporting the fonts or so; cjwatson and/or evand might know
<carlos> pitti: the problem he complains about is that they don't get the chance to select Persian
<pitti> right, I understand
<carlos> pitti: should I redirect them to debian-installer package in launchpad to file a bug?
<carlos> pitti: he says that he gets the option to install the language pack (which confuses me because I think he said first he was not able to...)
<pitti> carlos: ubiquity rather, I'd say
<carlos> pitti: so the only thing I can think on is that debian-installer is not including Persian translation (this is outside language packs)
<carlos> pitti: hmm, right, having its translations included in debian-installer confused me :-P
<mjg59> carlos: Or that there's a fonts issue
<carlos> ok, then I will ask him to file a bug against ubiquity 
<carlos> so he can talk directly with someone that could fix the problem and understand it better :-)
<Kmos> BenC: are you there?
<BenC> Kmos: yes, I got your msg from yesterday
<Kmos> from the PCM level reset to 0 ?
<Kmos> bug 41809
<ubotu> Launchpad bug 41809 in alsa-driver "PCM level is reset to 0 after every reboot" [Medium,Needs info]  https://launchpad.net/bugs/41809
<BenC> ubotu: sounds more like a alsa userspace bug
<BenC> shit
<BenC> Kmos: ^^
<Kmos> BenC: that's a package ?
<BenC> Kmos: alsa-base
<Kmos> alsa-base points to alsa-driver
<Kmos> :)
<BenC> then try alsa-utils
<BenC> either way, it's userspace that saves and restores the sound state
<Kmos> changed :)
<Kmos> thx
<BenC> np
<Kmos> i subscribed crimsun to the bug
<Kmos> BenC: kernel-wedge needs update from debian
<Kmos> 2.37 is out
<BenC> it'll get done, but it's not urgent
<BenC> Kmos: sub ubuntu-audio instead
<BenC> err, I mean assign to ubuntu-audio
<Kmos> BenC: ok
<cypherbios> Hi mvo. Would you know what packages/daemon is the responsible for showing this dialog when a ubuntu medium is inserted in the drive? http://img367.imageshack.us/img367/5500/screenshotsoftwarepackazz2.png
<Kmos> BenC: this one is for you.. i think :) bug 120677
<ubotu> Launchpad bug 120677 in linux-source-2.6.20 "uuid is never the same with w810i phone" [Undecided,Needs info]  https://launchpad.net/bugs/120677
<mvo> cypherbios: that one is update-notifier
<cypherbios> mvo: sounds good. Would it accept a 'plugin' for showing the same dialog when another media (not Ubuntu specific) with packages is inserted?
<cypherbios> mvo: In this case I mean a media created with aptoncd, which is perfectly apt-gettable
<mvo> cypherbios: yes, as long as its suffiently different (the dialog). are you aware of the 3rdparty CD support that we also have? not sure how useful that is in the context of aptoncd
<cypherbios> mvo: software-properties are enough to add the media as apt source. But I would like, when a aptoncd media is inserted in the drive, it automatically prompts this dialog (or something like this) asking the user if he wants to add media as apt source
<mvo> cypherbios: sure, that should not be very hard
<cypherbios> mvo: just a way to automatize things, just like with a ubuntu media
<BenC> Kmos: is that firewire UUID?
<cypherbios> mvo: How can I (or we if you want) can make it real? Could you point me the right path?
<cypherbios> mvo: what criteria is used to identify a ubuntu CD? the .disk/info file or the label of the CD/DVD?
<mvo> cypherbios: please look at /usr/lib/update-notifier/apt-cdrom-check and src/hal.c 
<Kmos> BenC: don't know.. i don't have reported the bug
<Kmos> BenC: but I think it connects by usb
<BenC> Kmos: nope, not a kernel bug...partition UUID is a userspace thing
<Kmos> BenC: at good it says, it's a usb cable
<Kmos> *good = google
<Kmos> BenC: which package
<Kmos> uuid - OSSP uuid
<Kmos> ?
<BenC> No idea..
<Kmos> anyone here knows what handles uuid stuff ?
<BenC> most likely it's a vfat partition...maybe the device is frequently changing it
<BenC> Kmos: it could very well be the device is just dumb
<Kmos> BenC: yeah
<BenC> in which case the bug gets rejected based on the fact we can't fix stupid hw firmware
<Kmos> reason: "The problem should be in w810i phone firmware..."
<Kmos> it's ok ?
<Kmos> BenC: done. rejected 
<Viper550> hello
<Keybuk> Viper550: WAIT!
<Hobbsee> Keybuk: no Viper550 for you!
<Tonio_> seb128: you rejected latest nm-applet upload ?
<seb128> Tonio_: no, I didn't look at it yet, doing it now
<seb128> Tonio_: looks like it has been accepted, must be pitti
<silvertip257> I've compiled busybox and would like to add openssh to it for a network tool/project ... I have trouble when I try to chroot to compile openssh
<pitti> seb128: yep, just did it
<seb128> Martinp23: you claimed the gnome-games tarballs some time ago, are you still working on it?
<pitti> Tonio_: I rejected the old one and accepted the latest one
<seb128> pitti: do you do some NEW (just to know if we need to organize to not do the same reviews) or just this one?
<pitti> seb128: just this one, due to urgency
<seb128> k
<seb128> thanks for doing it ;)
<pitti> seb128: I take an hour break now, playing some Wesnoth :)
<pitti> np
* seb128 hugs pitti
<Martinp23> seb128: Interesting, I just sent dholbach and email about that :-).  I'm busy with exams at the moment unfortunately, so if anyone does want to take them off me, I wouldn't be averse to that.  Sorry about this - real life is a pain :S
<seb128> enjoy!
<seb128> Martinp23: no problem, that's alright, if you are not working on them better to update the wiki though so you don't block other people who could do it
<Martinp23> OK seb128 - will do.
<seb128> thank you
<Tonio_> pitti: ah ok
<cypherbios> mvo: I made a little hack in src/hal.c and data/apt-cdrom-check to recognise an aptoncd medium. I've added the RES_APTONCD=4
<cypherbios> mvo: Would you take a look and merge this little patch?
<cypherbios> as well a case CD_WITHAPTONCD
<Hobbsee> morning sabdfl 
<hunger> Anyone working on getting the apt stuff installable again?
<pitti> hunger: what do you mean?
<sabdfl> Hobbsee: 
<sabdfl> hiya
<Hobbsee> heh.  just ban the enter key.
<sabdfl> anybody able to point me at the image for the current default ubuntu usplash?
<hunger> pitti: aptitude says that there is a new version of apt, synaptic, etc.
<Hobbsee> sabdfl: is it usplash-theme-ubuntu ?
<Hobbsee> i'm not positive, i dont run gnome
<hunger> pitti: But to do so it wants to deinstall ubuntu-desktop... plus most of the stuff that depends on.
<pitti>        apt | 0.7.2ubuntu2 |         gutsy | source, amd64, i386, powerpc
<Hobbsee> er, in the source of
<nrdb> I am using 2.14.3, when I view a directory with lots of .WMF files in it, the memory isn't freed when I quit Nautilus, is this a known problem, my 'Bug Report Tool' is functional
* nrdb oops thats - "Bug Report Tools" isn't functional
<pitti> hunger: hm, I don't even have ubuntu-desktop, so I didn't notice
* Hobbsee --> bed.  night all
<Hobbsee> exams are evil.
<mikmorg> hello all
<mikmorg> I have an issue in alsa, which is resolved as of 1.0.14. The latest deb packages for alsa, however, are 1.0.13. Is there a way I can press to have 1.0.14 packaged?
<mikmorg> If anyone could assist me as to who I should discuss this with (I'm sure there is a more appropriate channel - possibly #alsa?), I would appreciate it.
<cypherbios> mvo: ping
<pitti> keescook: btw, your stock replies .user.js kicks ass! *big hug*
<keescook> \o/
<keescook> thanks!  I was just reading the backlog about it.  :)
<keescook> did everyone get its use sorted?  I realize it's not the most intuitive design...
<pitti> keescook: took me a while to get it going, but seems to work now; I still don't know why setting the bug status didn't work initially
<keescook> If it was a brand new entry, the whole page needs to be reloaded.
<keescook> I could fix that, but it requires some weird javascript dancing.  :P
<pitti> keescook: would it be feasible to set the description in the normal description textarea instead of the very small input line?
<pitti> keescook: I tried plenty of reloads, hmm
<Riddell> enrico: I needed some changes for tagcoll1 to compile with gcc 4.3 http://kubuntu.org/~jriddell/tmp/kubuntu_01_gcc4.3.diff
<keescook> pitti: I was trying to have a trade-off between space and code sanity, etc, but I agree, it's not correct as is.  I'll fix it.
<keescook> or I'm happy to take a patch.  ;)
<pitti> keescook: oh, not urgent
<calc> Riddell: bug 15451
<ubotu> Launchpad bug 15451 in openoffice.org "Kubuntu SMB issue with OpenOffice" [Medium,Confirmed]  https://launchpad.net/bugs/15451
<calc> Riddell: any ideas about that issue, seems like a smb kioslave issue(?)
<calc> Riddell: tried to reassign it to kubuntu-meta but i get integrity errors in launchpad, heh
<enrico> Riddell: thanks
<Riddell> calc: I suspect it's because in /usr/share/applications/ooo-writer.desktop etc we have X-KDE-Protocols=file,http,smb,ftp,webdav
<Riddell> calc: I seem to remember someone telling me at the time that openoffice could do smb, presumably it can't
<Riddell> calc: if you could remove smb from that line in the .desktop files that should fix it
<calc> Riddell: it works with gnome smb somehow, not sure what it actually does
<Riddell> hmm, curious
<Riddell> maybe the URL format is different
<Riddell> I'm sure openoffice won't do webdav:// URLs too
<calc> the gnome places-network thing
<calc> Riddell: hmm yea probably not
<Riddell> calc: what's the URL format for a typical smb file on gnome?
<calc> Riddell: it can open the file but locally only
<calc> Riddell: no idea
<calc> sorry i'm not much use on the details yet
<calc> it says this when using the kde smb stuff
<calc> ** Protocol "smb" is supported only partially. Local copy of the file will be created. **
<sebbar> hi, will gutsy have slick-boot?
<calc> i'll have to dig around and see what it is doing soon
<exobuzz> from reading the bugs it seems not everyone is referring to the same problem.. with the kde file browser on openoffice, it has problems with kioslaves, but this is not the same problem as reported in the upstream bug listed
<exobuzz> i always assumed its the way the file browser is "hacked" onto openoffice. There are some other strange things with it also.
<exobuzz> its still better than the openoffice file requester though
<exobuzz> personally, i still prefer "reqtools" on my amiga as a file chooser :D
<calc> exobuzz: its a really old bug, apparently it used to break in different ways
<calc> exobuzz: now it works fine under gnome but doesn't under kde, it works for reading but can't update the file
<dholbach> siretart: do you know what the problem with bzr 0.17 and bzr-builddeb is?
<DrFrasierCrane> hey, i have a stupid question..
<DrFrasierCrane> is it possible to change gtk+ expander pixbuf used by default in ubuntu ?
<mdomsch> what's the canonical way to know what version of Ubuntu is running presently?
<mdomsch> s/running/installed/
<mjg59> mdomsch: /etc/lsb_version
<mjg59> Uh.
<mjg59> /etc/lsb-release
<mdomsch> mjg59, sweet, that'll work
<mdomsch> does that get created at bootup, or at install time?
<mdomsch> looks like install time
<pitti> ogra: ltsp FTW! your blog sounds great
<ogra> yeah
<ogra> its a milestone :)
* mdomsch and mikmorg teach dkms how to generate debs for driver updates, driver disks, etc
<DrFrasierCrane> any gtk hackers ?
<Treenaks> ogra: congratulations then :)
<ogra> Treenaks, thanks :)
<stgraber> ogra: I'll be able to test if my thin clients really boot <1 minute tomorrow afternoon :) Let's hope so
<ogra> stgraber, the slowest one i have (the worst HW ever) makes it in 1:40 now, that one took nearly 4 min with feisty ...
<stgraber> :)
<ogra> usual times were around 90-110 secs with feisty though ... 
<stgraber> I'm already playing with xorg.conf-less Xorg on a USB HDD, that's just beautiful to have Xorg detects everything (even better than the previous auto-detection)
<stgraber> and that + others improvment will for sure make some people happy here :)
<ogra> yeah
<ogra> keyboards are an issue though
<ogra> no xorg.conf no keymaps setting ...
<ogra> *keymap
<mjg59> pitti: To be honest, I think laptop-mode-tools really isn't appropriate for our purposes
<carlos> pitti: hi
<carlos> pitti: are you uploading daily lang packs for Gutsy as we agreed?
<mjg59> So I think the merge is absolutely fine, but I'd be tempted to replace it with something much simpler for the default install
<carlos> pitti: we just got an email asking for that
<pitti> carlos: not yet, I want to wait until a base update for tribe-2 and then reengineer the stuff for daily packs
<pitti> carlos: (no time yet)
<pitti> mjg59: ok
<carlos> pitti: ok, could I give any date estimation  for that?
<pitti> carlos: what about June 25th?
<carlos> next Monday?
<carlos> that's fine
<carlos> pitti: does it mean I should do a full export on Monday?
<pitti> carlos: Saturday or Sunday would be better IMHO, to have some breathing space
<cypherbios> mvo: I made a little hack in src/hal.c and data/apt-cdrom-check to recognise an aptoncd medium. I've added the RES_APTONCD=4 as well a case CD_WITHAPTONCD
<carlos> pitti: ok
<carlos> will do it on Sunday
<carlos> pitti: btw, what about your people.ubuntu.com repository? is it getting daily updates for gutsy? I think it's not...
<LaserJock> anybody know who is handling mailing lists?
<pitti> carlos: no, just the daily base updates
<carlos> pitti: daily base updates?
<carlos> pitti: I'm not doing daily base updates
<pitti> carlos: I take the full tarballs, not the delta ones
<pitti> right
<carlos> ok
<pitti> carlos: but you said the delta ones were way too big ATM
<pitti> due to some unlucky KDE export or so
<carlos> pitti: indeed
<Riddell> LaserJock: it depends on the list
<carlos> although I didn't know I should move back to full exports ;-)
<pitti> carlos: for tribe-2 it's enough, I think
<carlos> ok
<segfault> carlos: wanted to talk with me?
<carlos> segfault: yeah
<carlos> segfault: I'm cleaning up all pending files from the translation import queue
<carlos> segfault: and I saw an entry from you for Linbox
<carlos> I need to know whether you are part of its development team or whether they agreed on you importing that into Launchpad
<carlos> to accept it
<carlos> You can see the import policy to know more details: https://help.launchpad.net/RosettaImportPolicy
<LaserJock> Riddell: I got a couple new MOTU lists apparently
<LaserJock> one of them really shouldn't be a MOTU list though
<Riddell> LaserJock: ask in #canonical-sysadmin
<Riddell> mvo: well adept compiles, but it can't open the apt database
<mvo> *ick*
<mvo> Riddell: what is the error message?
<Riddell> mvo: "The APT Database could not be opened! This may be caused by incorrect APT configuration or some similar problem. Try running apt-setup and apt-get update in a terminal as root and see if it helps to resolve the problem."
<mvo> Riddell: is everything in place so that I can compile it myself (ie did you upload the fixes for the missing .la files already?) - then I have a look
<Riddell> mvo: yes, although not everything may be through to the archive yet, debtags I only just uploaded
<zasf> pitti: Hi Martin
<zasf> pitti: I forgot to mention something in my last email
<segfault> carlos: humm, the linbox developers asked me to remove all linbox entries from LP
<segfault> carlos: can you do that?
<LaserJock> seb128: do you mind if I patch gnome-panel to not show About Ubuntu when About Edubuntu exists?
<mvo> Riddell: ok, I check it out. maybe a recompile for libapt-front first helps?
<carlos> segfault: no, I cannot
<carlos> segfault: I can remove the translation request
<Riddell> mvo: done that
<mvo> :/
<carlos> segfault: for its project entry you will need to request it on https://answers.launchpad.net/launchpad
<segfault> carlos: humm, ok.. so please drop the translation request please
<Daviey> segfault: out of interest; did they state why?
<carlos> segfault: already done. Thanks for your input
<segfault> daviey: well, they said they want to manage the translation themselves, but maybe because they were acquired by mandriva IIRC...
<Daviey> They make a conversion from ms-office tool?
<segfault> daviey: i dont think so
<seb128> LaserJock: attach the patch in launchpad rather so we can comment on it
<LaserJock> seb128: will do
<seb128> cool
<pitti> zasf: hi
<Mithrandir> hmm, how come network-manager-gnome doesn't depend on network-manager?
<pitti> Mithrandir: good point, this probably got dropped inadvertedly in the split
<pitti> good night everyone
<Riddell> keescook: any ETA on security review for https://wiki.kubuntu.org/MainInclusionReportXapianCore ?  it's blocking apt rebuilds
<keescook> Riddell: ack, sorry, I should have time before EOD today.
<Riddell> thanks
#ubuntu-devel 2007-06-21
<kmon> Hi. There's a fix in mepis' grub that I'd love to have in ubuntu (since if make grub usable for intel core 2 duo macs. Anyone knows how to ask for this? or know the url of mepis deb-src apt packages? thanks
<sladen> kmon: file a bug report with the patch (so that it gets preserved), then talk to cjwatson if it's not already been included in the imported package from Debian
<kmon> the problem is that I have no clue where mephis has their apt sources packages
<kmon> and as far as tribe 1, it's not included
<kmon> I've just asked in #mepis but no one answered
<kmon> well, that's not correct
<kmon> a gyu answered, saying he had no clue
<kmon> I've filled my comment on the debian bug.
<kmon> and launchpad
<kmon> hopefully someone can find mepis source packages :)
<kmon> time for bed, thanks sladen
* kmon leaves
<siretart> dhsorry? it works for me. can you perhaps file a bugreport?
<LaserJock> siretart: what are you doing up so late? :-)
<Fujitsu> lllll
<Fujitsu> Oops. Laaaag.
<ajmitch> siretart: how's debconf?
<keescook> just so I understand usage patterns for xapian-dev, libept has it as a build-dep, but apt itself won't be using the xapian backends?
<keescook> Riddell: ^^
<keescook> Riddell: or better yet, which package is going to be using libept?
<StevenK> The only one I can think of is packagesearch.
<keescook> StevenK: ah, cool.
<StevenK> I've looked at doing the libept merge, it's ... interesting
<StevenK> And the xapian stuff looks pretty broken, too.
<StevenK> pinot needs to be transitioned due to xapian, but also makes use of libcurl3 and even better, boost, which is completly scragged.
<StevenK> keescook: I don't sound bitter, right? :-)
<keescook> hehe.
<keescook> I just want to understand how often the xapian stuff is going to be running with root privs.
<StevenK> keescook: I couldn't say, sorry.
<StevenK> Ah ha!
<StevenK> xapian-bindings needs a merge. Yoink!
<fabbione> morning guys
<mthaddon> Launchpad is going down in 15 mins for a code update. Estimated downtime is approx 30 mins
<nxvl> :(
<nxvl> does anyone knows where can i find pitti?
<Hobbsee> nxvl: he's asleep at the moment - but here
<nxvl> Hobbsee: wich is his nickname?
<nxvl> oh ok, i understand
<nxvl> sorry
<nxvl> he's german, doesn't him?
<Hobbsee> yes
<Hobbsee> he's pitti on irc
<nxvl> ok
<nxvl> so there it must be morning in a few ours mmm i will talk to him tomorrow
<fabbione> nxvl: one hour more or less....
<nxvl> fabbione: yes, but here it is 12 oclock almost, and i need to work early in the morning, so i need to sleep
<nxvl> :S
<fabbione> i suggest you send him an email then
<Hobbsee> morning fabbione 
<fabbione> hey Hobbsee 
<nxvl> fabbione: yes, i have do it :D
<nxvl> i hate to work in corporate world using microsofts productus, but it make's me horney to develop free software :D
<nxvl> does anybody know the package gnome-volume-manager?
<Hobbsee> it exists.
<nxvl> heh
<nxvl> i mean, if anybody know the source, if anybody has work with it
<lifeless> nxvl: I think you are asking that as a prelude to asking something else.
<lifeless> nxvl: dont. Just ask the real question.
<nxvl> the thing is that im trying to fix the bug #107668
<nxvl> but i don't find where the code of the bug is
<nxvl> i'm new in this
<Hobbsee> LP isnt up.  doesnt help
<nxvl> hes
<nxvl> yes
<nxvl> i know
<nxvl> i have the bug open
<nxvl> i will paste it in pastebin
<nxvl> http://pastebin.com/933157
<nxvl> there it is
<fabbione> nxvl: looking in the code is a learning curve.
<fabbione> it can take some time to do it on your own, but once you get there, it will much easier to understand than just asking where the bug is :)
<nxvl> fabbione: yes i have do it, but i've open the .glade and it looks diferent i thing it isn't about the gnome-volume-manager package
<fabbione> nxvl: i didn't read the bug.. i am just giving you a hint :)
<nxvl> fabbione: heh, ok thnx for the helo anyway :D
<nxvl> help*
<nxvl> what is a .desktop.in?
<LaserJock> it is a file that is built into a .desktop
<LaserJock> which is generally a file used for menu entries
<LaserJock> although it can be used for other things I think
<nxvl> mm
<nxvl> now im sure, the bug isn't talking about that package
* desrt comes to #ubuntu-devel to find an idle Hobbsee 
* desrt *shock horror*
<LaserJock> desrt: it's because LP is down
<Hobbsee> desrt: idle?  nah.
<desrt> oh.  thank goodness.  i was frightened for a moment.
<Hobbsee> desrt: i cant talk to people forever - tehy seem to get bored of me :P
<LaserJock> she's connected bionicly to LP
<ajmitch> or scared
<Hobbsee> heh
* Hobbsee has been shopping though.
* Hobbsee has been being a proper girl.
<ajmitch> scary
<Hobbsee> now *that* should make you scared!
* desrt just got back from shopping
<ajmitch> it does
<fabbione> my eyes!
<desrt> i bought a shwarma.
* desrt hands fabbione some very dark sunglasses
<fabbione> Hobbsee shipping.. desrt shopping... 
<fabbione> are we all becoming girls? :P
<fabbione> s/shipping/shopping
<somerville33> Hobbsee is... shipping?
<somerville33> lol
<nxvl> when automount makes an icon on my desktop, what package opens when i click on Properties on the "right-click" menu?
<desrt> nxvl; nautilus...
<Hobbsee> fabbione: haha
<Hobbsee> fabbione: you're next.
<nxvl> desrt: thats when y click, not in propertins on right click
<nxvl> s/y/i/
<desrt> nxvl; i'm positive that nautilus is responsible for showing the properties dialog
<somerville33> Wee... lp is back
<nxvl> desrt: sure? ok, i will look on that code
<nxvl> LP is up again
<nxvl> well im going to sleep, please tell pitti to read mi mail (at ubuntu dot com) and/or answer me at launchpad (bug #107668)
<ubotu> Launchpad bug 107668 in gnome-volume-manager "Setting an invalid mount point can make a removeable media unaccessible" [Undecided,Confirmed]  https://launchpad.net/bugs/107668
<nxvl> see you
<mthaddon> Launchpad is back up after code update - total downtime was 26 minutes
<Hobbsee> desrt: you wouldnt happen to have a picture of quinn anywhere, would you?
<Hobbsee> mthaddon: yay, thankyou :)
<ajmitch> Hobbsee: now go attack that bug!
<desrt> Hobbsee; i would happen to.
<Hobbsee> desrt: link?
<desrt> on flickr somewhere :p
<Hobbsee> desrt: that doesnt hlep
<Hobbsee> morning pitti 
<nxvl> there he is
<StevenK> pitti: Morning
<pitti> Good morning
<desrt> Hobbsee; quinn was at DAM4
<nxvl> pitti: good morning
<pitti> hey StevenK 
<somerville33> Morning pitti
* StevenK sighs.
<nxvl> pitti: i was looking for you
<pitti> Hobbsee: poking time for tribe-2 bugs?
<pitti> nxvl: hi
<Hobbsee> pitti: quite possibly.
<ajmitch> hi pitti 
<nxvl> pitti: i have send you an e-mail
<pitti> ajmitch! how are you?
<nxvl> pitti: and post on LP bug #107668
<ajmitch> pitti: good, how are you?
<ubotu> Launchpad bug 107668 in gnome-volume-manager "Setting an invalid mount point can make a removeable media unaccessible" [Undecided,Confirmed]  https://launchpad.net/bugs/107668
<pitti> nxvl: right, I saw that yesterday, I think; still on my list...
<StevenK> pitti: I've looked at libxapian13 cruft, one sync filed, one upload, and the third blows up violently.
<nxvl> pitti: i have answer like an hour ago
<pitti> StevenK: blows up?
<nxvl> pitti: i was looking for the bug but is seems to me it isn't that package
<pitti> nxvl: ah, it's in gnome-mount
* nxvl is downloading the source
<pitti> nxvl: that particular dialog is in /usr/share/gnome-mount/gnome-mount-properties.glade
<pitti> nxvl: and managed by /usr/lib/nautilus/extensions-1.0/libgnome-mount.so
<StevenK> pitti: Package in question is pinot, and is also affected by the libcurl3 and boost transitions. Boost is utterly, utterly stuffed, and I think pinot doesn't cope with the changed in xapian anyway.
<pitti> nxvl: I fixed the package in the bug
<nxvl> pitti: so i don't need to fix it?
<pitti> StevenK: so, candidate for the "*shrug* leave it broken" list?
<nxvl> :(
<StevenK> pitti: Not sure, I will have another look.
<pitti> nxvl: no, I mean I didn't fix the actual bug, I just changed the package name in the bug report :)
<nxvl> heh
<nxvl> ok
<StevenK>   device-mapper: reload ioctl failed: Cannot allocate memory
<StevenK> Hrm, neat.
<nxvl> so i will try to fix it
<nxvl> :D
<pitti> asac: when do you plan the next ffox upload? bug 119814 is trivial to fix, and currently milestoned
<ubotu> Launchpad bug 119814 in firefox "/usr/share/doc/firefox/MPL missing in gutsy package" [Critical,In progress]  https://launchpad.net/bugs/119814
<pitti> nxvl: great! thanks a lot
<nxvl> but i will do it tomorrow, now it's time for bet
<StevenK> Hum.
* StevenK ponders trying to clean up all of the LVM snapshots
<nxvl> bye to everyone
<nxvl> and thnx for the help
<Luckye> hi?
<Luckye> theere is anyone here?
<Luckye> i have some cuestion?
<pitti> !ask | Luckye 
<ubotu> Luckye: Don't ask to ask a question. Just ask your question :)
<Burgundavia> Luckye: hello
<Luckye> mmm
<Luckye> okas
<Luckye> is there some one who has used glade?
<Burgundavia> this channel really isn;t for developing software on Ubuntu
<Burgundavia> I recommend the #gnome-hackers or irc.gimp.net for that
<Luckye> mm
<Luckye> and where is the channel?
<Luckye> sorry?
<Burgundavia> on irc.gimp.net
<Burgundavia> s/or/on/
<Burgundavia> Luckye: ^
<Luckye> mm?
<Luckye> nop
<Luckye> my friend,
<Luckye> i went to irc.gimp.net
<Luckye> and anyone could tell me some thing about that problem
<Luckye> jeje
<dholbach> good morning
<pitti> hey dholbach 
<dholbach> hiya pitti
<pitti> Tooooooniooooo!
<LaserJock> morning pitti 
<pitti> hey LaserJock 
<LaserJock> nice interview :-)
* Hobbsee puts the crazy pitti back in his cupboard, and locks the door.
<pitti> Hobbsee: he broke the 'do not touch static interfaces' fix of n-m
<Hobbsee> pitti: oh dear.
<StevenK> I knew there was reason I didn't want to touch n-m.
<StevenK> People wanting my blood if I broke it would be it.
<Burgundavia> I had fun with n-m today
<Burgundavia> my wired port is physically busted
<Hobbsee> well, knetworkmanager's wokring fine.
<Hobbsee> :P
<Burgundavia> imagine the fun when n-m decided not to see my wireless card
<StevenK> pitti: Do you have a second to help me with some C++ hell?
<pitti> StevenK: I'm not a C++ expert, but what's up?
<StevenK> pitti: I'm trying to patch pinot so it actually builds.
<LaserJock> Burgundavia: oh, remember when I was having all kinds of freezes and weird things?
<Burgundavia> yep
<LaserJock> Burgundavia: and you told me to try removing NM
<Burgundavia> yep
<LaserJock> I haven't had *any* issues since
<Burgundavia> ironically I haven't had any issues since I told you
<StevenK> pitti: It was calling stem_word(), but it seems the newer version of xapian changes that to operator(). So I replaced pStemmer->stem_word(blah) with pStemmer(blah), but it still gives me an error.
<pitti> hm, no idea really
<hunger> StevenK: (*pStemmer)(blah)?
<StevenK> hunger: Hrm, let me try that.
<StevenK> hunger: That did the trick, thanks!
<StevenK> hunger: My question is, why do I need to (*blah) it?
<hunger> pStemmer is a pointer.
<hunger> StevenK: So (*pStemmer) dereferences that so you get the actual object.
<StevenK> Ah, so I need to dereference it.
* StevenK nods.
<hunger> StevenK: And on that you call the operator().
* hunger thinks the operator() sucks when used with pointers... ruins the whole elegance of the original idea:-)
<StevenK> Heh, yes.
<StevenK> pitti: Okay, if pinot builds, it should hit the archive before the publisher run, and if you process the sync I just filed, that's all of the xapian transitions, too.
<pitti> StevenK: bug#?
<pitti> or package name?
<StevenK> pitti: Heh, I was only kidding.
<StevenK> pitti: Bug 121488
<ubotu> Launchpad bug 121488 in xapian-bindings "Please sync xapian-bindings (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/121488
<pitti> hey, what happened to my stock replies?
<Hobbsee> pitti: they changed with the new LP
<StevenK> pitti: pinot uploaded.
<StevenK> Launchpad supports stock replies?
<pitti> StevenK: a greasemonkey script from keescook 
<StevenK> Ahh
<pitti> Hobbsee: darn, it again forgets the status
<Hobbsee> pitti: statuses have changed a lot...
<Hobbsee> and it's case sensitive
<pitti> right, but it's the same problem I had yesterday
<pitti> erk
<Hobbsee> ahh
<pitti> zope.security.interfaces.ForbiddenAttribute: ('currentrelease', <Distribution at 0x2aaab2908f10>)
* pitti stares at sync-source
<pitti> it's all seb128's fault!
<Fujitsu> Hah.
<StevenK> Neat
<seb128> hey pitti
* seb128 looks at pitti
<seb128> what did I do this time? ;)
<pitti> $ sync-source -b stevenk -f xapian-bindings
<Fujitsu> seb128: Everything.
<pitti> zope.security.interfaces.ForbiddenAttribute: ('currentrelease', <Distribution at 0x2aaab2908f10>)
<seb128> utch
<pitti> yay new LP rollout
<pitti> handy a week before tribe-2 release
<Hobbsee> pitti: indeed.
* Hobbsee needs to look into said bugs.
<pitti> Hobbsee: ah, got it: if I first use "Fix%20Released", save, and then change it to "Fix Released", it works
<seb128> too many status choices with the new version :/
<pitti> Hobbsee: apparently the first save attempt doesn't get along with spaces
<Hobbsee> pitti: go figure...it works fine with Fix Released here
<Hobbsee> heh
<pitti> right, it's just a workaround for the initial saving
<pitti> and it's not clear at all which of the states are 'closed' ones
<Hobbsee> yeah
<pitti> StevenK: so, "No milk^Wsync today"
<Hobbsee> pitti: can i have a pony instead?
<StevenK> pitti: So it would seem.
<pitti> OMGponies!
<pitti> StevenK: there's still http://people.ubuntu.com/~pitti/scripts/syncpackage, of course :)
<pitti> StevenK: I wrote that ages ago when soyuz sync wasn't there yet
<StevenK> Heh
<Hobbsee> pitti: have you seen https://bugs.launchpad.net/ubuntu/gutsy/+nominations yet?
<Hobbsee> pitti: https://bugs.launchpad.net/ubuntu - left panel.  easy to get to now, too
<Fujitsu> That view is nice, I saw it before.
<pitti> Hobbsee: oh, cool
<Hobbsee> :)
<Fujitsu> It even has proper permissions :D
<Hobbsee> where proper == ?
<Fujitsu> MOTU can accept/reject for {un,mult}iverse.
<Hobbsee> ah right
<pitti> ion_: got a minute to discuss r-m's modalias handling?
<pitti> look, another Hobbsee_!
<Fujitsu> Attack of the clone-sticks.
* LongPointyStick attacks Fujitsu 
<Hobbsee_> ZOMG THEY'RE MULTIPLYING!  EVERYBODY HIDE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* Hobbsee_ decided that it was far saner to transfer 5gb via wired, rather than wireless, tyvm.
* Fujitsu decided that it was saner to have irssi running on an external machine.
<LongPointyStick> heh
<Hobbsee> i prefer not to have private conversations, and logs, on other people's machines.
<Hobbsee> else i would, too
<Fujitsu> True.
<Fujitsu> I do most of that over XMPP, so it's not much of a problem.
<Hobbsee> Fujitsu: LongPointyStick does that, though.
<Hobbsee> XMPP?
<Fujitsu> XMPP is Jabber.
<StevenK> Extensible Messaging and Presence Protocol
<Fujitsu> eXtensible!
<Hobbsee> true.  i was more thinking "how does it work in this context"
<Fujitsu> It works by me not PMing much, and talking to people over XMPP instead.
<Hobbsee> ahhh
<Hobbsee> right
<mvo> Riddell: debtags complains that it needs libept-dev >= 0.5.2 but that appears to be not in the archive yet
<mvo> Riddell: for me adept works now, recompile is enough, I do not get a error or anything on opening the cache
<dholbach> hiya mvo
<mvo> hey dholbach
<pitti> hi Tonio_ 
<pitti> Tonio_: current n-m breaks statically configured interfaces in /e/n/interfaces again
<Tonio_> pitti: that was patched right ?
<Tonio_> pitti: that's a part of the patches I didn't reapply, I have to ping the patcher for this
<pitti> Tonio_: in the previous version, yes
<pitti> Tonio_: Mithrandir or Keybuk presumably?
<Tonio_> pitti: if you look in the package, there is a "non applied patches" folder for those that needed rewritting
<pitti> ah, ok
<Tonio_> pitti: I guess it was fabionne
<Tonio_> s/b/bb/
<asac> pitti: when is tribe-2 milestone release?
<fabbione> asac: https://wiki.ubuntu.com/GutsyReleaseSchedule
<asac> pitti: i have this MPL bug already committed locally ... wanted to fix one or two more bugs before upload
<fabbione> it's next week
<asac> fabbione: thanks ;)
<fabbione> so it's possible that freeze will come soon
<pitti> asac: next Thursday
<asac> pitti: ok ... so is monday ok for you?
<pitti> asac: sure, that's fine
<dholbach> gpocentek, mr_pouit: we can drop the gcalctool-gtk package as the libgnome dependency has been dropped upstream
<dholbach> gpocentek, mr_pouit: I'll upload the new version now - can you make another upload of it and drop the -gtk package stuff and change your seeds?
<pitti> dholbach, gpocentek, mr_pouit: NB that you should keep the old package as transitional one until next LTS (or next release if that package wasn't in dapper)
<siretart> LaserJock: was just about to go to bed ;)
<siretart> ajmitch: great! - very different to UDS, but great!
<dholbach> siretart: do you know something about why bzr-builddeb is not installable atm?
<siretart> dholbach: oh. damn. /me checks
<siretart> dholbach: oh, right. we need to sync 0.16.2 from unstable to gutsy
<dholbach> nice :)
* dholbach hugs siretart
<siretart> dholbach: I thought Etienne agreed to take care that a new upload of bzr doesn't break bzr-* packages :/
<geser> is the auto-syncing from Debian already stopped?
<pitti> geser: not yet
<geser> pitti: will claws-mail be synced from Debian or should I reopen bug #118643?
<ubotu> Launchpad bug 118643 in Ubuntu "please sync claws-mail from debian unstable" [Undecided,Invalid]  https://launchpad.net/bugs/118643
<pitti> geser: we'll sync it automatically
<geser> good, because it didn't happen yet (it's a new package)
<seb128> geser: new packages are not synced every day
<siretart> dholbach: I need to merge python-debian for bzr-builddeb
<dholbach> alright
<dholbach> thanks siretart
<shawarma> Is it on purpose that there are no package description translations for e.g. feisty-updates ?
<siretart> dholbach: can you please request a sync of bzr-builddeb for me? (I only have a chroot at hand, I'm still at debconf)
<siretart> dholbach: I just uploaded python-debian
<dholbach> seb128: could you do a sync of bzr-builddeb (when you find the time)?
<seb128> dholbach: syncs are borked since the recent launchpad rollout
<seb128> will do when that's fixed
<dholbach> oh... :(
<dholbach> thanks a lot seb128
* dholbach hugs seb128
<seb128> you're welcome
* dholbach hugs siretart too
* seb128 hugs dholbach back
<siretart> seb128: would you hit be very hard if I did a fakesync? (upload it as 0.16.2build1)?
<seb128> no, feel free, better to use a lower version than Debian though
<seb128> ~build1 maybe
<siretart> ok. thanks
<seb128> so we can sync later
* siretart hugs seb128 
* seb128 hugs siretart
<siretart> dholbach: okay, bzr-builddeb should work again in a few hours
<dholbach> rock and roll
<dholbach> TheMuso: want to update gnome-speech?
<TheMuso> dholbach: Ah yes. I wanted to be sure that recent additions to gnome-speech in Debian made it through binary new.
<dholbach> ah ok
<TheMuso> What happens with new binary packages that are placed in the contrib section, but the source package is in main, when they are brought into Ubuntu?
<shawarma> ajmitch: Are you planning to do the samba merge, by the way?
<ajmitch> shawarma: I was going to, though I'm surprised that noone else picked it up since then
<Riddell> mvo: yes, debtags is waiting on ept to get libxapian in main
<shawarma> ajmitch: It just had your name written all over it :)
<ajmitch> there wasn't much to do, I think I had it mostly done & not at all tested
<ajmitch> shawarma: you're the first person to even ask me about the merge :)
<shawarma> ajmitch: Heh. 
<ajmitch> ah, I see I have to update for 3.0.25a-2 anyway
<shawarma> What's the point in keeping kbd-chooser around in universe?
<shawarma> Has the next [BH] ugDay been announced? I know it's the 27th, but has an announcement been made?
<Keybuk> asac: ping?
<Keybuk> Tonio_: ping?
<Tonio_> Keybuk: pong ?
<Keybuk> Tonio_: why doesn't network-manager-gnome depend on network-manager?
<HawkeV> hey guys, does a debug version of 2.6.17-10-generic (edgy) exist with the kernel memory leak detector patch implemented?
<Tonio_> Keybuk: I didn't investigate on that point
<Tonio_> Keybuk: I kept the same depedancies as on the previous package
<Keybuk> Tonio_: also why have you dropped the manual configuration patches?
<Tonio_> Keybuk: I didn't drop them, but there was a problem to reapply them since the applet is now a separate tarball
<Keybuk> Tonio_: you haven't; the feisty network-manager-gnome *does* depend on network-manager
<Keybuk> Tonio_: why didn't you reapply them?
<asac> Keybuk: i didn't do the last merge ...
<Keybuk> there was a daemon and an applet patch
<Tonio_> Keybuk: my C knowledge is very limited so I wanted to ping fabione, he wrote the patch in the first place
<Tonio_> Keybuk: the patch mostly needs to be rewritten, as the code changed a lot, and I'm not a C coder myself...
* Keybuk wrote the patch
<Tonio_> Keybuk: concerning the dependancies, I guess there is something wrong with network-manager-dev/shlibsdeps
<Keybuk> if you can't apply a patch, don't just drop it!
<asac> Keybuk: is network manager code in bzr somewhere?
<Keybuk> in fact, you shouldn't have uploaded the merge without it -- instead handed the complete merge (without the patch) to someone who can fix it
<Keybuk> we're now left with a network-manager regression against feisty
<Tonio_> Keybuk: I didn't drop it, I put it in a "non-applied-patches" folder in the source package, waiting to ping the guy to rewrite it
<Keybuk> and we would not have been aware of it, had I not been reading -changes
<asac> Tonio_: ask me next time ... do you still have the original merge files ... so we can redo?
<Tonio_> Keybuk: that was discussed with seb128 and pitti, that all the patches were not there etc...
<Tonio_> asac: the original not applied patches are in the source package
<Tonio_> Keybuk: I was about to ping the guys tomorrow to fix those patches issues
<Keybuk> Tonio_: ok
<Tonio_> Keybuk: concerning the depedancy, I have to investigate, but the easiest is to just reupload with a manually added dep
<Tonio_> Keybuk: something changed in the -dev part and shlibsdeps seems not to get it...
<Tonio_> Keybuk: I know the upload perfect, but we're in the dev cycle right ? :)
<Keybuk> it could be
<Keybuk> sure, we're in the dev cycle :)
<Keybuk> but it is important that when an upload is made with a Todo, the Todo is announced somewhere public
<Tonio_> Keybuk: was a first shot, then I'll ping the patchers to help on the patching part
<Keybuk> just in case you're hit by a bus or something
<Keybuk> best way is to make an obvious large note in the changelog
<Keybuk> or to mail ubuntu-devel with the note
<Tonio_> Keybuk: the big problem was the nm-applet now splitted in another tarball
<Tonio_> Keybuk: hehe, oki I'll send an email on -devel, probably tomorrow (no time today, emergency at work)
<asac> Tonio_: ok, will you try get these patches reapplied and if you run into problems let me know?
<Tonio_> asac: sure
<asac> Tonio_: great!
<Tonio_> asac: as I'm not a gnome user myself, it'll be hard for me to test the patches, but I'll ping the guys that patched before, and the ml, that's the easiest way to get n-m working correctly in a short time I guess
<shawarma> Did everyone else also get an lp e-mail about #121292 ?
<ogra> shawarma, do i have to feel left out if not ?
<shawarma> Bug 121292
<ubotu> Launchpad bug 121292 in ksudoku "test bug" [Low,Invalid]  https://launchpad.net/bugs/121292
<shawarma> ogra: You're not missing out :)
<Keybuk> shawarma: not me
<shawarma> I'm just wondering since it didn't have the usual "You're receiving this e-mail because..." and i can't figure out why. I
* shawarma -> #lp
<ion_> pitti: Yes.
<Keybuk> hmm, ENOPITTI
<Keybuk> pitti: aha!
<pitti> hi Keybuk 
<Keybuk> bcm firmware
<Keybuk> is there any particular reason that you need to rmmod/modprobe the module?
<Keybuk> or any particular reason you want it to fail on modprobe so you can modprobe again?
<pitti> Keybuk: yes, it would be nice if we could make this effective without a reboot
<Keybuk> pitti: I have a much cuter solution
<pitti> Keybuk: is there a 'poke this module again' call?
<mjg59> Yes, you can detach/attach via sysfs
<Keybuk> yup
<pitti> Keybuk: I mean, bug 121504 could still be implemented to reduce confusion, but if there's a 'reload' option, that would be nicer indeed
<ubotu> Launchpad bug 121504 in module-init-tools "test availability of firmware for bcm43xx" [Low,New]  https://launchpad.net/bugs/121504
<Nafallo> Mithrandir: around?
<kylem> pitti, the "correct" way to do this, would be to use modinfo to pull the MODULE_FIRMWARE fields out of the module and check for those.
<kylem> then it could be extended to all modules using firmware.
<ion_> pitti: Im online.
<Keybuk> pitti: it'd be worth testing to see whether unbind'ing and bind'ing to its devices causes a firmware reload
<pitti> kylem: hmm, modinfo bcm43xx|grep -i firmware is empty here
<kylem> pitti, well, conveniently enough, we can fix this. ;-)
<pitti> Keybuk: testing now
<pitti> yay LP file downloads
<AnAnt> Hello, when is the next sync with Debian ?
<Keybuk> mvo: hmm, none of the alternate focus animations work for me
<pitti> AnAnt: I would have done it tomorrow; right now the sync tool is broken, thoug
<Keybuk> mvo: they all just "fade"
<Keybuk> mvo: if I set it to "dodge", it sets it back to fade when I look again
<Keybuk> bug for racarr, I suspect :p
<pitti> Keybuk: so, I removed the firmware, rebooted, and now are firmware-less
<mvo> Keybuk: I have set "fade" to autoenable in the global config, I wonder if that causes this 
<pitti> Keybuk: what exactly do I have to poke now/
<Keybuk> pitti: 
<Keybuk> cd /sys/bus/pci/drivers/$BROADCOM
<pitti> Keybuk: /sys/module/bcm43xx/drivers/pci:bcm43xx has some 'bind'/'unbind' files
<Keybuk> echo -n $PCIID > unbind
<Keybuk> echo -n $PCIID > bind
<Keybuk> the pci id can be found by just "ls" :)
<pitti> ah, that one
<AnAnt> pitti: ok, I find that the package mutt in gutsy is sync'ed with a mutt version in experimental (not unstable)
<AnAnt> pitti: but it is sync'ed to an old version of mutt (1.5.16 is now out)
<pitti> AnAnt: no problem, that will autosync in the next run
<pitti> Keybuk: 'echo 0001:10:12.0 | sudo tee unbind' gives me 'unbind: no such device'
<Keybuk> err
<pitti> 'bind' as well
<Keybuk> -n is important
<pitti> ah, sorry
<AnAnt> pitti: so will that sync update mutt to 1.5.16 ?
<Keybuk> and I'm not sure -n is compatible with tee ;)
<AnAnt> pitti: thanks
<pitti> Keybuk: indeed, that works great
<Keybuk> pitti: does that reload the firmware
* pitti hugs Keybuk 
<Keybuk> exxxxxxcellent
<Keybuk> isn't Driver Core great? :)
<pitti> keescook: *sniff* my fancy canned bug replies disapper with every reboot
<pitti> so, let's turn this into r-m code 
<StevenK> Grah. pinot failed to build on sparc, i386 and ppc. Funnily enough it managed to build on amd64 and ia64.
<Mithrandir> Nafallo: now I am
<Nafallo> Mithrandir: PM :-)
* Hobbsee checks if she's still alive
<pitti> Hobbsee: *poke* :)
* Hobbsee is poked.  damn.
<Hobbsee> must be alive then.
<xxxxx1> hello Hobbsee 
<Hobbsee> hi
* Hobbsee looks for a very stiff fdrink, or something.
<zul> water?
<Hobbsee> water will do nothing.
* ion_ pours a shot of Salmiakki Koskenkorva for Hobbsee.
<Hobbsee> heh, thanks
<pitti> so, one click to open restricted-manage, one to activate the firmware for bcm43xx, one to acknowledge dl'ing from the internet, and *plopp*, wifi is usable from r-m
<pitti> that's almost too easy to stay an incentive to buy hardware with free drivers :)
<pitti> Keybuk: thanks again for the bind trick :) it's codified in r-m now, in a pretty generic manner
<pitti> s/usable from r-m/usable from network-manager/, of course
<StevenK> pitti: Neat!
<cyberix> How will the default configuration for Effect-enabled desktop be generated?
<mjg59> pitti: I'm a bit worried about doing it in r-m
<mjg59> pitti: The freeness of the bcm firmware isn't very different to that of most firmware we distribute...
<cypherbios> pitti: no need to restart nm-applet?
<pitti> cypherbios: nope
<cypherbios> that's great
<pitti> mjg59: well, the difference that matters to us is that we cannot distribute the bcm firmware
<mjg59> pitti: Eh. We can't really distribute the ipw2100 firmware, but we do it anyway :)
<mjg59> The difference is that we have tacit approval to do so...
<mjg59> I'm not sure that we have any guarantees that that extends to downstream distributors
<pitti> cypherbios: so far you had to restart NetworkManager and reload the module; nm-applet is the least complicated bit :)
<dholbach> TheMuso: why don't you do the gnome-speech update to 0.4.14 at the same time?
<cypherbios> pitti: in this case I think is better to tell the user he needs to restart the computer and ask if he wants to do it now. what do you think?
<pitti> cypherbios: that's what happened before with firmware, and still happens with video drivers
<pitti> cypherbios: but now, firmware installations don't need a restart of anything any more
<cypherbios> sounds nice
<mvo> pitti: what does restriced-manager --check-composite do exactly? will it just check or will it modify the configuration?
<pitti> mvo: if it needs one, it'll offer you to enable it
<Riddell> keescook: did you do the xapian review?
<pitti> mvo: in detail, if you start it as normal user with --check-composite, and you need the nvidia driver, it'll do 'gksu restricted-maanger --enable nvidia'
<pitti> Riddell: yes, he did
<pitti> Riddell: couple of issues, but nothing earth-shaking; these can be sorted out later
<pitti> Riddell: if this stuff is urgent, go ahead and promote it now
<mvo> pitti: is the behaviour/exit codes documented somewhere?
<Riddell> pitti: thanks, it's only urgent because of the number of people telling me adept needs to be fixed :)
<pitti> mvo: not really; it's just standard exit codes: 1 for failure or not necessary, 0 for installed successfully; but we can change this
<mvo> pitti: its fine, I will document it in the desktop-effects enable code
<pitti> mvo: we probably need to tell apart the 'not needed' vs. 'failed to install' cases?
<pitti> mvo: anyway, that code bit is quite small and in one place, so if you need to change r-m, just point me to a branch (or tell me what to change)
* StevenK kicks pinot until bits fall off.
<pitti> StevenK: kick it with remove-package? :)
<StevenK> pitti: It's frankly, pissing me off. It builds on amd64 but not i386
<pitti> StevenK: unless you actually care about that package, don't waste too much time on it
<StevenK> I so don't.
* StevenK looks at some of the libwnck18 cruft
<pitti> StevenK: cruft list on people updated, FYI
<StevenK> pitti: Thanks, you rock.
<geser> mvo: Hi, how can I find out why update-manager doesn't want to update my gutsy system?
<geser> when I click on "Install updates" only the dialog "Checking for Updates" appears and I'm back at the start
<seb128> geser: does it happen if you run update-manager from a command line?
<geser> it doesn't matter if I do start update-manager from the console or the tray icon
<seb128> k,I had the same bug the other day but it was happening only when using the tray icon
<Keybuk> hmm
<Keybuk> is gnome-keyring broken?
<geser> it tried starting update-manager from the console in hope to get some error message
<Keybuk> or is it gnome-gpg that's broken?
<pitti> gnome-gpg: gkr-secure-memory.c:653: gkr_secure_memory_free: Assertion `0 && "memory does does not belong to gnome-keyring"' failed.
<geser> I tried now gksu update-manager and this works
<Keybuk> pitti: yeah, I get that too
<pitti> Keybuk: however, it works for me
<mvo__> geser: know bug, https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/120957
<Keybuk> oh, I see, it does actually work
<ubotu> Launchpad bug 120957 in update-manager "UpdateManager fails to fetch dist-upgrade tarball" [High,Fix committed]  
<Keybuk> I assumed with such an OMGTSIF error, it didn't work
<Keybuk> heh
<Hobbsee> Keybuk: what does OMGTSIF extract to?
<pitti> the sky is falling?
<Hobbsee> ahhh
<Hobbsee> cool!  let it fall!
* Hobbsee wants to know what's above the sky.
<geser> mvo__: I'm already running gutsy, is it still the same bug?
<Keybuk> Hobbsee: more sky
<Keybuk> and then, after a while, no more sky
<mvo__> geser: oh, that is a different one, can paste it
<Hobbsee> ooo :)
<Hobbsee> Keybuk: and what's there instead of teh sky?  :P
<Keybuk> Hobbsee: nothing
<Keybuk> well, mostly nothing, with stray bits of thing moving through it
<nxvl_> pitti: hi again
<Hobbsee> Keybuk: way cool :P
<pitti> hi nxvl_ 
<nxvl_> pitti: i'm trying to solve the bug, but i'm kind of lost
* Hobbsee nukes one of the bits of thing, and packs it to take to work tomorrow.
<pitti> nxvl_: where's the obstruction?
<nxvl_> pitti: tell me if i'm on the right way, i have open the .glade using glade-3, then i look for the name of the textbox and i i'm loking for it on the .c file
<geser> mvo__: when I click on "Install updates" only the dialog "Checking for Updates" appears and I'm back at the start. it doesn't matter if I start update-manager from the console or the tray icon. using gksu update-manager from a console works.
<nxvl_> pitti: but i only find the call for the GUI, not the main function of what is the program doing with it
<nxvl_> pitti: y also don't find the "OK" button to see what happen when it's press
<pitti> nxvl_: the drive_mount_point_entry GtkEntry, right?
<geser> mvo: http://paste.ubuntu-nl.org/26607/ that's all I get
<pitti> nxvl_: this is connected to mount_point_entry_changed()
<nxvl_> pitti: no, the volume_mount_point_entry GtkEntry
<pitti> nxvl_: right, one for the drive, one for volume
<pitti> nxvl_: but they are both connected to mount_point_entry_changed()
<pitti> nxvl_: that's the function which reads the value from the input line and puts it into gconf
<nxvl_> pitti: and how do i know that? just knowing or is any way to see it?
<pitti> $ grep -r drive_mount_point_entry .
<pitti> nxvl_: there you see the gtk_signal_connect()
<mvo__> geser: interessting, could you please file a bug
<pitti> it's easy to find if you search for the entry widget name in ./src/gnome-mount-properties-view.c
<pitti> nxvl_: I think this should either print a warning dialog or just change a slash into an underscore or so, or maybe both
<geser> mvo: will do
<nxvl_> pitti: i see the gtk_signal_connect, but don't see the function attach to it :S
<nxvl_> pitti: i see the gtk_signal_connect, but don't see the function attach to it :S
<pitti> eh, WTF? my xchat window disappeared into the void again
<pitti> nxvl_: if you said something after my last reply, I lost it
<nxvl_> pitti: i knew it, so i repeeat it :D
<StevenK> pitti: It's a hint that you need to use irssi.
<Hobbsee> pitti: you shouldnt have named it martin.
* StevenK ducks
<pitti> itz gtk bug
<pitti>         gtk_signal_connect (glade_xml_get_widget (properties->xml, "volume_mount_point_entry"),
<pitti>                             "changed",
<pitti>                             GTK_SIGNAL_FUNC (mount_point_entry_changed),
<pitti>                             properties);
<pitti> nxvl_: ^ here, 3rd line
<nxvl_> with irssi there is no gtk bugs :D
<Nafallo> hehe
<ion_> stevenk: irssi is dead, long live irssi2. :-)
<Nafallo> ion_: huh? :-)
<ion_> stevenk: Just kidding, its not ready for everyday usage yet.
<ion_> But it will rule, when it gets there.
<nxvl_> :D
<nxvl_> pitti: ah ok, now i see it, thnx, now a little bug attacking
<nxvl_> thnx a lot
<StevenK> Oh, thanks, metacity.
<pitti> nxvl_: you're welcome; happy hacking! :)
<StevenK> Please remove DOUBLE_CLICK_ from known macros
<geser> mvo__: filed as bug #121581
<ubotu> Launchpad bug 121581 in update-manager "[gutsy]  update-manager doesn't update anymore" [Undecided,New]  https://launchpad.net/bugs/121581
<nxvl_> pitti: i need to check for every / or just the first one? i mean if it starts with a /
<mvo__> geser: thanks!
<pitti> nxvl_: depends on what you want to do
<pitti> nxvl_: I'd recommend to replace all / with _ and give a warning dialog that / is not allowed
<pitti> nxvl_: there's g_string_replace() or so for that
<pitti> nxvl_: also, the label says 'mount point', that's really confusing
<pitti> nxvl_: it should be 'mount directory in /media' or so
<pitti> but that's too long
<Hobbsee> !ping
<ubotu> pong
<nxvl_> pitti: so, change the / for _ and tell in the warning that / are not allowed and i'm changing it fot _?
<pitti> nxvl_: the user will see the replacement, just pointing out / is enough IMHO
<nxvl_> pitti: "Mount point inside /media" sounds good to you?
<pitti> nxvl_: but the UI for that needs to be more clear
<pitti> nxvl_: the label would be quite long, wouldn't it?
<pitti> nxvl_: you should discuss that with David Zeuthen (upstream) on the mailing list
<pitti> if we change strings, it shuold be done upstream so that we don't keep breaking translations
<nxvl_> pitti: yes, it's very long :S
<pitti> nxvl_: 'mount point in /media' should still fit, though, the dialog layout is generous
<nxvl_> i will post the patch for glade now
<pitti> cjwatson: WDYT about http://paste.stgraber.org/1725 for bug 114296?
<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: from looking at the other install scripts this should work
<Mithrandir> evand: do you know what the plan wrt casper and who's going to maintain it forward is going to be?
<Mithrandir> evand: since you're our installer person, it might make sense for you to grab it.
<evand> Mithrandir: That's not something cjwatson has discussed with me yet.  But yes, I can see how that would make sense.
<ogra> Mithrandir, i do a lot suff in initramfs recently for ltsp and the classmate ... if you dont find anybody i'd volunteer since i have to fiddle with it anyway for gutsy at least
<StevenK> pitti: notification-daemon and python-gnome2-desktop uploaded, which (when they build) takes care of 3 out of 5 of the main cruft for the libwnck transition.
<Mithrandir> evand: I've spoken with some of the debian-live people here at debconf and it would be good if they knew who they could talk with
<pitti> StevenK: you rock
<StevenK> pitti: :-)
<evand> Mithrandir: I'm not sure I follow.  You're more than welcome to give them my email address if they ask.
<Mithrandir> evand: yes, that's more or less what I was planning
<evand> thanks
<pitti> keescook: good morning
<keescook> pitti: bug replies> oh no! that's no good.  when you click "save changes" do they show up in about:config
<pitti> keescook: trying
<pitti> keescook: hm, what do I have to look for?
<pitti> keescook: I defined one new reply now, 'bzrhead', but that substring doesn't exist in the search
<keescook> hm
<keescook> pitti: in the about:config Filter, put in "outflux"
<keescook> it should show a mess of greasemonkey.scriptvals.http://outflux....
<pitti> keescook: ah, yes, it's there
<pitti> keescook: I guess it only searches keys, not values
<keescook> hm... afaik, that should save.  the script is just using the internal greasemonkey config settings
<keescook> I don't see any setting to "forget" GM config items.  so if you quit and restart firefox those disappear?
<pitti> keescook: no, that works; but it happened twice after a reboot
<pitti> keescook: I'll turn off my computer in a bit when I leave, and turn it on again for today's meeting; I'll check it again then, I guess
<keescook> how very odd!
<keescook> some kind of strange firefox bug?
<pitti> no idea
* pitti blames asac
* Hobbsee blames pitti 
* pitti blames Hobbsee for never ever getting to bed and sleep
<Hobbsee> pitti: i do too!  occasionally
<Hobbsee> pitti: i've gottne worse since UDS though
<Hobbsee> pitti: and i did go to work tonight, so...
* Keybuk wonders why, when idle, his laptop still regularly changes CPU speed
<Keybuk> it seems to blip to 100% every couple of seconds
<ion_> keybuk: Does top or powertop help at all?
<ion_> s/es//
<Keybuk> ion_: not really
<Keybuk> top show snothing
<Keybuk> powertop says USB, i915, ipw3945, powernowd and X
<davmor2> how can I debug nm-applet please it is core dumping
<pitti> davmor2: feisty? gutsy?
<davmor2> gutsy latest update
<pitti> davmor2: hm, do you still happen to have the feisty kernel installed?
<davmor2> no gutsy fresh install
<pitti> hmm
<davmor2> part of iso testing
<pitti> davmor2: unfortunately the gutsy kernel doesn't work with apport still, so you cannot use the easy way
<asac> pitti: what are you trying to do? greasescripts?
<pitti> asac: yes, keescook's canned replies
<davmor2> that's what I assumed as apport has report all core dumps before
<pitti> davmor2: https://wiki.ubuntu.com/DebuggingProgramCrash
<pitti> davmor2: i. e. install the -dbgsym packages and run nm-applet under gdb
<davmor2> thanks I'll check it out
<pitti> davmor2: I gotta go now, please email me if you have questions (or just ask here)
* pitti will be back for the meeting
<asac> keescook: do you have a problem ... or is it just pitti whose prefs are not persistent?
<ogra> hmm, whats up with gutsy-changes ... ?
<ogra> any known outages ? 
<nosrednaekim> could anyone point me to the source code for how synaptic does it download scripts?
<seb128> ogra: you might want to ask on the sysadmin chan 
<nxvl_> can someone point me to a manual of C regexp, or field valitation in C?
<nxvl_> please
<mvo__> nosrednaekim: do bzr get http://people.ubuntu.com/~mvo/bzr/synaptic/synaptic--main/ and gtk/rgmainwindow.cc: RGMainWindow::cbGenerateDownloadScriptClicked
<keescook> asac: just pitti's prefs being non-presistent across reboots (!?)
<nosrednaekim> mvo__: ok, thanks.
<geser> nxvl: afaik libc has only wildmat matching, if you need more you should probably look at libpcre
<nxvl_> geser: i only need to look if there is a / on the string
<geser> nxvl: that should be easy, it should be doable with one of the str* functions, looking now which one
<geser> strchr, strrchr, strchrnul - locate character in string
<nxvl_> geser: thnx :D
<nxvl_> geser: where did you get that?
<geser> from man strchr :) I remembered that there is a function for it and looked for it with "apropos str"
<nxvl_> geser: thnx i will read it :D
<nxvl_> geser: *HUGS*
<geser> if you need it for a wide-char string (wchar_t) than the function is wcschr
<seb128> any REVU admin around?
<keescook> Riddell: xapian-core> yup, I took a bunch of notes and said "okay" to pitti.  I wish they'd clean up their code a bit more -- it was not easy to read.  I worry there may be hidden issues with some of the database formats, but it would take a great deal more time to fish those out.
<Hobbsee> seb128: yes
<asac> keescook: but for you it works?
<seb128> Hobbsee: can you remove the current gtkglext gtkglextmm gnome-build update from there? gandalfn had problem with his uploads and he can't upload again
<seb128> the diff and dsc have been uploaded correct but the orig didn't work
<keescook> asac: yeah, I'm fine -- multiple reboots, firefox upgrades, etc.  perhaps I'm just lucky?
<Hobbsee> seb128: done
<seb128> Hobbsee: thanks
<Hobbsee> seb128: no problem
<asac> keescook: i guess pitti is just doomed ... or maybe he doesn't close firefox, but just reboots/restarts X?
<keescook> dunno. pretty odd -- he said he'd test again once he was back.
<HawkeV> what extra debug does the debug rev of the 2.6.20-15 open up?
<mvo> ENOPITTI?
<geser> mvo: [17:36:57]              -*- pitti will be back for the meeting
<mvo> thanks geser
<HawkeV> i see
<Riddell> keescook: ok, many thanks
<HawkeV> i guess it was a pointless question anyway, since the debug kernel doesn't boot
<tarzeau> does #ubuntu-motu not exist anymore?
<keescook> tarzeau: I'm on that channel -- works for me.
<tarzeau> keescook: thanks, suddenly it worked
<keescook> cool :)
<bryce> in the latest xorg, Debian has added a Depends on sparc-utils, however I'm wondering if I should move that to Suggests
<bryce> "sparc-utils | not+sparc,"
<tarzeau> bryce: does it not build without it on sparc?
<tarzeau> bryce: got a version number/src package?
<bryce> tarzeau: sparc-utils is apparently used for detecting the correct resolution on sparc
<tarzeau> bryce: at build-depends time, for who?
<bryce> xorg-7.2.-5
<bryce> no, it's a Depends, not a Build-Depends
<kylem> sparc-utils | not+sparc means it is only a Depends on sparc.
<tarzeau> ah sorry misread you
<kylem> although, i've never seen that syntax before.
<bryce> kylem: so should it be okay to leave as is?
<HawkeV> hey guys, i have a 100% reproducable kernel memory-leak on x86_64, who do i need to speak to to get some help debugging it?
<tarzeau> HawkeV: how to reproduce?
<tarzeau> HawkeV: which kernel version exactly?
<Nafallo> HawkeV: #ubuntu-kernel ? :-)
<HawkeV> i can reproduce it on 2.6.17-10 and 2.6.20-15
<HawkeV> leak starts when i invoke /etc/cron.daily/find on a system with a large xfs partition that has a lot of data on it
<bryce> hmm, guess I'll leave it as is until I know more
<aquo> hmm, i don't understand where is the connectiong between germinate and the iso images ...
<aquo> https://help.ubuntu.com/community/LiveCDCustomization descibes customization only
<aquo> but i am interested how the official images are created?
<aquo> isn't this automatized?
<j1mc> aquo: http://codebrowse.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/xubuntu.gutsy/files
<j1mc> that's the link you need
<aquo> yeah, so i am able to generate package lists, but is there a way building new install media from scratch without remastering a cd image?
<aquo> are the official images just altered old versions of themself, or are they generated from scratch?
<aquo> -old +new
<aquo> i don't want to include extra packages on my cds, i want to include less.
<aquo> where is the automatized connection between germinate and the cd-images?
<Nafallo> slomo: hi :-)
<aquo> may anybody help me?
<LaserJock> aquo: it will be much easier for you to customize an existing image
<LaserJock> aquo: but you can check the code at https://code.launchpad.net/debian-cd/
<aquo> LaserJock: Yes, but that is not the scripts that are used for Ubuntu, there must be modifications
<Keybuk> aquo: generated from scratch each time, iirc
<aquo> Keybuk; how, where is the documentation?
<Keybuk> aquo: wiki.ubuntu.com, look under generating custom CD images
<Keybuk> https://help.ubuntu.com/community/LiveCDCustomization
<aquo> no, that is just an description how to modify existing images.
<Keybuk> if you want to make an image from scratch, you want "debootstrap"
<Keybuk> https://wiki.ubuntu.com/DebootstrapChroot?highlight=%28debootstrap%29
<aquo> i doubt that the official images are generated this way.
<Keybuk> to generate CD lists from seeds, use germinate
<Keybuk> err, why?
<aquo> they take the old images and modify them?
<Keybuk> why not?
<Keybuk> germinate generates package lists that you can feed into apt
<Keybuk> germinate also generates the lists that mean the original debootstrap works
<aquo> i managed the germinate part already ...
<Keybuk> so you just debootstrap a chroot, and then apt install the germinate lists you want
<Keybuk> (I think debian-cd uses dpkg --set-selections/dselect for hysterical reasons, I'm not sure)
<aquo> i just don't now to come from the lists to the cds ...
<aquo> +k
<Keybuk> you'll have a chroot
<Keybuk> in that chroot will be an installed filesystem
<Keybuk> so just mksquashfs that and drop it into a CD, following the customisation howto bit
<aquo> debian-cd package in baazar look like to be customized for etch, not for ubuntu
<Keybuk> if you change the kernel, see the appropriate bit of that doc
<Keybuk> I don't really understand what else you're looking for
<aquo> i really would like to see the exact script that are used to build the official images.
<Keybuk> you're assuming there is one
<LaserJock> aquo: https://code.launchpad.net/ubuntu-cdimage/
<TheInfinity> hmm ... has somebody here the patched pam_foreground.so: https://bugs.launchpad.net/ubuntu/+source/libpam-foreground/+bug/76364 ?
<ubotu> Launchpad bug 76364 in libpam-foreground "authdaemond: dlerror: /lib/security/pam_foreground.so: undefined symbol: pam_set_data" [Undecided,Confirmed]  
<LaserJock> aquo: I doubt you'll find a ton useful in there, but there it is
<Keybuk> iirc, there's just a bunch of random scripts that work together
<aquo> Keybuk: have you ever build a image?
<Keybuk> aquo: yeah, loads of times; you just run the appropriate bit depending what change you made
<aquo> yeah, but the changes won't be simply adding this or that package ...
<aquo> my changes will change the install media in the amount xubuntu differs from ubuntu
<Keybuk> right, and xubuntu has a whole different script there, iirc
<LaserJock> aquo: grab the bzr branch for ubuntu-cdimage and debian-cd from cjwatson 
<Keybuk> aquo: we really don't have a "make-me-a-cd-image -r xubuntu -l package-list" type script
<Keybuk> there are plenty of community ones like that, but they're not "official"
<aquo> i first want to remaster just the offfical ubuntu images, for gaining knowledge how to do it ...
<Keybuk> sure, so see that customisation howto
<aquo> the documentation for this seem spread all over the net
<Keybuk> that tells you how to get an image, change bits of it, and then make a new one
<wolfeon> aquo: that would be fun :)
<Keybuk> aquo: remember that Ubuntu never started from scratch
<aquo> yes, but i don't wan't to change anything, i want to build the images from scratch
<Keybuk> we started from Debian
<Keybuk> so we've never *had* to build things from scratch ;)
<wolfeon> is there a link I missed?
<wolfeon> I need to do it too.. since I need to build a custom iso for a business  :)
<LaserJock> aquo: get http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline and http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
<aquo> ok
<Keybuk> to do it from scratch, you want debootstrap, germinate, debian-cd and ubuntu-cdimage
<Keybuk> there are far better community things to do this than we use :p
<LaserJock> aquo: but seriously, you will mostly likey want to rebuild an existing image
<wolfeon> hmm
<LaserJock> the LiveCD is relatively easy to modify
<aquo> seriously, i don't want, because with this approach my changes will be valid for one branch (feisty) only
<LaserJock> why?
<wolfeon> the live cd just copies a base right? not debs and unpacking?
<LaserJock> right
<LaserJock> so you can just unpack the squashfs, do your modifications, and pack it back up. there are some additional things you need to do to get things installed right, but there is documentation for that
<aquo> yes, and i want to exclude lots of packages, and packages that depend on them ...
<LaserJock> fine
<LaserJock> that's no problem
<wolfeon> errrr, where are fixes uploaded once a bug is fixed?
<wolfeon> via launchpad
<LaserJock> it depends
<LaserJock> if it's a fix in gutsy we just upload to gutsy
<wolfeon> LaserJock: https://bugs.launchpad.net/ubuntu/+source/vino/+bug/112955
<ubotu> Launchpad bug 112955 in vino "vino (vnc) keyboard mapping problem" [Low,Fix committed]  
<LaserJock> if it's for a stable release (i.e. Feisty, Edgy, etc.) then it goes through a Stable Release Update procedure
<wolfeon> right, where is the repos for the Feisty test updates? :)
<LaserJock> those are -proposed
<LaserJock> wolfeon: but that bug will presumably be included in the next Gnome release in gutsy
<LaserJock> *bug fix
<wolfeon> well its an embarrassig bug.. I'm converting a business to use Ubuntu.. :))
<wolfeon> sob
<wolfeon> https://bugs.launchpad.net/ubuntu/feisty/+source/python-fam/+bug/115655
<ubotu> Launchpad bug 115655 in python-fam "using PyMem_DEL() instead of PyObject_FREE() causes python 2.5 to double free or corrupt" [Medium,Confirmed]  
<wolfeon> I'm confused, how come my fix has not been sent to proposed?
<wolfeon> for feisty
<wolfeon> its easy to load the package on my feisty servers, but what if I need people to use it on a stock feisty? :)
<LaserJock> wolfeon: it has been marked as "Incomplete" until the fix has entered gutsy
<wolfeon> pitti: poke :)
<wolfeon> LaserJock: o?
<LaserJock> the last comment
<pitti> wolfeon: hi
<wolfeon> o :) guess one can't rush things, heh.
<wolfeon> I never did talk with upstream, does that mean after gutsy they will take debian's package again with the bug?
<wolfeon> its also broken in debian still, heh.
<pitti> keescook: hm, this time it didn't forget my bug responses; maybe a weird interaction with the LP update, or cosmic rays, or so
<LaserJock> wolfeon: if you don't talk to upstream or Debian, then it does have a fair chance of not getting fixed there :-)
<LaserJock> wolfeon: you should push to get your fix into gutsy
<LaserJock> then you can do the SRU to get it into Feisty
<wolfeon> LaserJock: there is a fix attached to the bug, how do I get it sent to gutsy?
<keescook> pitti: yeah, no sure, it's kind of out of my script's control -- it's all up to GM to do the right thing.  hmpf
<LaserJock> wolfeon: the package is in Universe so you should subscribe the ubuntu-universe-sponsors team so they can sponsor the upload
<wolfeon> all this just to get a small bug fixed :/
<LaserJock> well, it could be worse I suppose
<LaserJock> it's a matter of letting the right people know so they can upload your fixes
<LaserJock> we have thousands of small bugs
<wolfeon> yeah :/
<wolfeon> back to this bug https://bugs.launchpad.net/ubuntu/+source/vino/+bug/112955
<ubotu> Launchpad bug 112955 in vino "vino (vnc) keyboard mapping problem" [Low,Fix committed]  
<wolfeon> looking at "source package in ubuntu" it says "Initially uploaded to Ubuntu gutsy" does this mean it was *not* fixed in feisty?
<Keybuk> right
<pitti> is it only me, or do other people get weird rejection mails for gutsy-changes@ as well?
<Keybuk> usual practice is to *not* apply fixes to released distributions
<Keybuk> feisty is as feisty was when feisty released
<Keybuk> that is, for us, what release means
<wolfeon> if it was not fixed in feisty.. then VINO is broken on EVERY ubuntu desktop
<Keybuk> we make exceptions for security fixes or other critical bug fixes
<Keybuk> right
<wolfeon> Keybuk: Wouldn't that bug be critical? since it doesn't map correctly on any 7.04 install?
<Keybuk> so what happens there is a fix is prepared and tested, and normally uploaded to gutsy first
<Keybuk> the patch for the fix is then applied to the feisty package, and built
<wolfeon> it was marked fixed, so nobody will pay any attention to it :)
<Keybuk> if successful, that is uploaded to the feisty-proposed distribution and tested there for several days
<wolfeon> then I better open the bug back up and mark it separately gutsy and feisty?
<Keybuk> and if it fixes the problem, and causes new ones, then it is uploaded to feisty-updates
<Keybuk> wolfeon: https://wiki.ubuntu.com/StableReleaseUpdates
<Keybuk> wolfeon: especially see "Propose" :)
<geser> pitti: I've also seen two rejections mails on the motu ML
<Keybuk> since this fix has apparently occurred in GNOME, you may find it easier to get one of the developers participating in that bug to propose it for an SRU
<Keybuk> (funny story...
<Keybuk>  someone asked me once why, after releasing edgy, we didn't fix bugs in it, and improve it further
<Keybuk>  I pointed out that we did, and just called it "feisty")
<wolfeon> hehe
<wolfeon> well I want a stable version of software with fixes :P Else I'd have gone the unstable path a long time ago, heh.
<pitti> geser: last mail on https://lists.ubuntu.com/archives/gutsy-changes/2007-June/thread.html is from last night, that's suspicious
<Keybuk> wolfeon: what do you mean by "stable" ?
<wolfeon> Keybuk: how can you tell which subscribers are developers in the bug list?
<wolfeon> Keybuk: stable, just the same software which fixes are being made.
<geser> pitti: do you know who admins the gutsy-changes ML and where the admins can be found?
<pitti> geser: I just asked cprov
<Keybuk> wolfeon: ask on the bug list :)
<Keybuk> or click on their names, and see which teams they are members of
<Keybuk> wolfeon: what if the bug fix *is* the new version of the software? :p
<zasf> pitti: about your last email, if you pulled the entire branch, I guess it wasn't mirrored yet
<Keybuk> wolfeon: I mean that the other way around, obviously, but the point remains
<pitti> zasf: right
<zasf> pitti: it normally takes a while, you should pull directly from my server
<pitti> zasf: btw, any reason why you don't push to LP directly?
<wolfeon> Keybuk: sorry, I just dont use launchpad all that often. If I attach a comment, it gets pushed to some list like a forum or mailing list?
<pitti> zasf: ok, will switch to your URL then
<zasf> I don't have rights :D
<Keybuk> wolfeon: it gets mailed to the people subscribed, yes
<wolfeon> Keybuk: o, right :)
<zasf> or maybe now that I joined the bugsquad maybe I have
<wolfeon> just flog me. I need more coffee.
<zasf> it would be helpful to know that from an experienced person here
<zasf> pitti: UnlockableTransport: Cannot lock: transport is read only
<pitti> zasf: with sftp://?
<TheInfinity> hmm ... is somebody with an 64 bit processor here who can compile https://bugs.launchpad.net/ubuntu/+source/libpam-foreground/+bug/76364 ?
<ubotu> Launchpad bug 76364 in libpam-foreground "authdaemond: dlerror: /lib/security/pam_foreground.so: undefined symbol: pam_set_data" [Undecided,Confirmed]  
<pitti> zasf: probably because it is a mirrored branch
<TheInfinity> this bug is since 6 month not fixed :(
<keescook> TheInfinity: why do you need an amd64 for that?
<keescook> (i mean, it looks like a generic build problem)
<TheInfinity> because i have exacly this problem on an 64 bit server
<TheInfinity> and i have no compile maschine - and the other users will kill me if i compile on this server ;)
<keescook> heh, I will poke at it.
<zasf> pitti: hum with sftp it goes one step further: Permission denied (publickey).
<zasf> pitti: I'll set a key and see if taht is the problem
<pitti> zasf: yes, you need to register a gpg key in LP for this to work
<zasf> pitti: nice, I'll do it soon
<TheInfinity> keescook: this means ... ? ;)
<keescook> TheInfinity: I'll try to get it built, I mean.  :)
<TheInfinity> okay ... thanks :)
<mrsn0> TheInfinity with some instructions explaining how i can compile on gutsy 64 here if you like :)
<TheInfinity> i dont know gutsy at all ;)
<mrsn0> well feisty/gutsy whatever really
<wolfeon> Keybuk: I'm thankful I saved the instructions on updating a package from last bug. its just a deleteion of 3 lines of code :)
<mrsn0> i have both in a vm
<wolfeon>  I'll just sent a patch to the bug tracker, heh.
<TheInfinity> and: i am not that good in compiling and so on - but in this case i am not even ablte to try it ;)
<keescook> Keybuk: do you know off-hand if libpam-foreground is actually an ubuntu-native package?  the changelog is not sane, especially when compared against the debian changelog.
<TheInfinity> debian has libpam-foreground 0.2 ...
<Keybuk> keescook: I think it probably was at one point
<TheInfinity> <-- has also watched debian pakages ;)
<mrsn0> TheInfinity thats quite a conundrum then :p
<keescook> Keybuk: I'm going to switch it to 0.3-0ubuntu1, is that sane?
<Keybuk> I don't see why not
<pitti> keescook: it would be even better to get 0.3 into Debian; 0.2 doesn't work well...
<keescook> pitti: sounds right, the orig split would be the first step
<dholbach> pitti, keescook: do you want a MIR for a cursor theme?
<pitti> dholbach: I'm fine with a quick package review and handling this without much fuss
<dholbach> alright
<pitti> MIRs are not really for packages which only ship five pngs...
<dholbach> dmz-cursor-theme would be the package - I'd like to replace human-cursors-theme
<pitti> dholbach: please send me a tiny mail about it for me to not forget
<dholbach> pitti: sure will - thanks a lot
<keescook> zomg pwnage via PNG!  ;)
<dholbach> muuhuhahahaha :)
<pitti> keescook: mentally 0wned is not that far-fetched; just check out http://www.schaf.de/gal/main.php?g2_view=core.DownloadItem&g2_itemId=30346&g2_serialNumber=2 :)
<keescook> yaaarg
<pitti> (and no, it's *not* an animated gif :) )
<keescook> that's nice, I hadn't seen that one before.  :)
<pitti> keescook: show this to anyone, and he'll tell you every password he knows
<dholbach> Keybuk: how did you fix that terminal shortcut? it's not in my shortcut capplet anymore
<Keybuk> dholbach: gconf-editor
<dholbach> hrm
<Keybuk> dholbach: /apps/compiz/general/allscreens/options/command_terminal
<Keybuk> I set it to "gnome-terminal"
<dholbach> it's set to gnome-terminal already
<LaserJock> pitti: gaaaah, you're going to make my brain explode :-)
<pitti> LaserJock: do I?
<LaserJock> pitti: that pick is very troublesome to the mind ;-)
<LaserJock> *pic
<pitti> LaserJock: MUHAHA PWNED
<Keybuk> dholbach: oh, that made my key work
<Keybuk> it works now
* Keybuk presses it
<Keybuk> are you using today's compiz with the ccsmpthingy backend
* mvo waves to stratus_
<Keybuk> or last week's with gconf backend?
<dholbach> I'm up to date
* stratus waves to mvo
<mvo> dholbach: lets debug it tomorrow together :)
<xxxxx1> how can i silence console startup messages like is in the installer?
<xxxxx1> for example..
<xxxxx1> * Starting x... y... z...
<xxxxx1> just show the kernel Booting message and later the login
<xxxxx1> ?
<pitti> shawarma: so, about bug #119075: did you get a response from Sean or Christian already?
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
<pitti> shawarma: I would really like to find a design that suits both Debian and us
<shawarma> pitti: As i mentioned in the flood, I haven't had a chance to ask them yet. I didn't know it had been milestoned.
<shawarma> pitti: I was planning on doing it tomorrow or start of next week, actually.
<pitti> shawarma: right, no problem; how do you think we should fix this? 
<shawarma> pitti: Ideally get MySQL to just grant full privs to a user with euid 0.
<shawarma> pitti: And then remove the debian-sys-maint user.
<pitti> shawarma: right, that's what I prefer as well
<shawarma> pitti: I'll see if I can strike up a conversation with a MySQL dev tomorrow?
<shawarma> pitti: That would be the coolest way around it, I think.
<pitti> shawarma: I suggest a bug report
<ogra> i dont actually know any mysql user who actually uses debian-sys-maint
<pitti> shawarma: so far my experience with mysql bugs has been relatively good, especially if it is raised upstream as well
<shawarma> pitti: It's likely to be rejected on grounds of "we already have a documented way of resetting the password".
<shawarma> ogra: Every user who ever shuts down his mysql server. Ever. :)
<pitti> shawarma: well, a pretty braindead one
<ogra> shawarma, oh
<shawarma> pitti: Well, it's worth a try. I'll file a report about it tomorrow.
<shawarma> ogra: But not directly, no.
<shawarma> ogra: It's also used for /etc/init.d/mysql status
<keescook> shawarma, pitti: looks like I can't just put xmms into flac -- it needs the whole library and "xmms-config" programs to compile.
<pitti> shawarma: hm, if you are concerned about Christian defending debian-sys-maint, then start it with upstream right away :)
<shawarma> keescook: Yes, I found that out too :)
<pitti> shawarma: however, Christian is pretty sane, and since this d-sys-maint is such an obvious and blunt hack, I hope he'll agree to that solution, too
<pitti> keescook: erk
<ogra> shawarma, ah, i didnt know that
<keescook> so, I think our only option is to cripple it.  if someone wants to build a flac-universe package, that's the only way I see this going.
<pitti> keescook: I didnt' follow that, why does flac need xmms? shouldn't it be the other way ronud?
<keescook> the xmms-flac module is built in the flac source tree.
<keescook> I tried hauling it into the xmms tree, but it was non-trivial, and I didn't feel comfortable blowing a whole bunch of time on it, since it's a universe package.
<pitti> erk
<pitti> keescook: hm, but putting xmms code into the flac source sounds sooo wrong...
<keescook> right, that won't fly at all.  I was hoping it was just going to be headers
<keescook> but, it's much deeper than that.
<pitti> keescook: then it would be better to move that stuff into the xmms source, right?
<pitti> keescook: anyway, maybe xmms2 has this solved more elegantly
<pitti> keescook: if you need it for playing around, I can NEW it, it should be good now
<keescook> I haven't looked at xmms2 yet.  should I really spend time getting the flac module into the xmms package, especially since upstream devel is dead?
<ogra> not really ... its sad to cripple it but its likely to die anyway
<keescook> ogra: do you use xmms with flac support?  I personally don't.
<pitti> keescook: no, please don't waste time on that
<ogra> upstream is always a great excuse
<pitti> ogra: what about xmms2?
<ogra> no, i dont but xmms is still one of the most popular players
<ogra> pitti, i'm RB user :) 
<pitti> ogra: so am I
<ogra> but many edubuntu users prefer xmms because its a low ressource thing
<keescook> yeah, I still use it too.  :P
<keescook> It seems that the popcon voting for "xmms-flac" isn't sane
<keescook> it reads out at "0" but I can't believe it.
<pitti> xmms2-plugin-flac_0.2DrJekyll-3ubuntu1_i386.deb
<pitti> keescook: ^
* pitti reviews the 3242380429482 binary packages of xmms2
<ogra> i'd fear MrHide here 
<ogra> :)
<ogra> or was it Hyde ?
<keescook> okay, good, we can point people at xmms2, then, I guess.
<Keybuk> or a media player for grown-ups
<Keybuk> :p
<keescook> Keybuk: heh. :)
<ogra> for pairs
<pitti> Keybuk: if there is an accident in the archive and xmms inadvertedly *cough* gets kicked off the archive, can I blame cprov?
<pitti> (the stories about years-old unfixed security holes are scary...)
* pitti hugs cprov 
<shawarma> We can just remove xmms and put it a picture of xmms instead, file a bug about "XMMS ui un-responsive" and mark every other xmms bug a duplicate of that one.
<keescook> AHAHA
<shawarma> 2. ?
<mdke_> very clever
<shawarma> 3. Profit!
<pitti> LMAO
<mdke_> can we have a list going of apps to do that to?
<shawarma> They'll never know. :)
<shawarma> mdke_: What else do you feel like getting rid of? :)
<Burgundavia> <troll> KDE-* </troll>
<mdke_> openoffice
<pitti> shawarma: OO.o *duck*
* mdke_ hugs pitti 
* pitti ^5s mdke_ 
<shawarma> Yeah!
<Burgundavia> Firefox!
<shawarma> That will free up *LOADS* of space on the LiveCD as well.
<pitti> shawarma: well, it's unresponsive enough already *ducking even lower*
<shawarma> pitti: LOL
<ajmitch> Burgundavia: too obvious
<Burgundavia> ajmitch: I just woke up
<shawarma> Burgundavia: That's what they all say.
<Burgundavia> well, at least it was on purpose
<keescook> okay, xmms-dev removed from flac.
<pitti> keescook: great; really this sounds a bit like glibc: Build-Depends: firefox
<keescook> hah!
<Keybuk> mdke_: nobody would notice
<ion_> pitti: :-D
<shawarma> Burgundavia: :)
<ogra> bah, lamers ... firefox ... openoffice ... tsk
<ogra> take GDM !
<ogra> that solves it one and for all
<keescook> pitti: agh! I keep alt-tabbing through my firefox windows and getting my eyes freaked out by that image.  I need to close that tab.  ;)
<zasf> pitti:good night everybody
<zasf> good night everybody
<pitti> bye zasf 
<keescook> bryce: where is the amd driver thingy you mentioned?
<bryce> keescook, http://q-funk.iki.fi/debian/pool/x/xserver-xorg-video-amd/
<bryce> sorry, I'd assumed there was a link in the email
<pitti> keescook: I told you -- security vulns in images :)
<bryce> I'm hoping to have all the x drivers updated for tribe2... just a few left to go
<ogra> any chance for openchrome ? 
<nxvl> wich package contains glibc.h?
<keescook> bryce: so this amd driver is not in Debian yet?
<bryce> keescook, not yet
<bryce> keescook, I emailed the packager to ask for an eta on when it'll appear in debian, but no response
<bryce> (or maybe response never made it through spam filter... ;-)
<bryce> ogra: yes, let me look
<keescook> Date: Fri, 15 Jun 2007 16:15:42 +0300
<keescook> The package is now sitting in NEW.
<keescook> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400748
<ubotu> Debian bug 400748 in wnpp "RFP: xserver-xorg-video-amd -- X.org X server -- AMD Geode GX/LX display driver" [Wishlist,Open]  
<keescook> bryce: and this line is right?
<keescook> +Provides: xserver-xorg-video-1.0
<keescook> I know there were ubuntu-specific changes for this stuff in other video drivers
<pitti> Riddell: libept/sparc failed with a bus error, ominous; did you see this before? shall I try a give-back?
<bryce> yep, that's there so binary l-r-m drivers, etc. can let X know that the video driver requirement is satisfied
<keescook> okay, but the -1.0 vs no suffix is correct?  (i.e. the changelog mentions changing this around)
<bryce> oh
<bryce> hmm, I've never seen -1.0 appended there
<keescook> pitti: how do I snag a dsc/orig/etc out of debian's NEW?  the new list is just an HTML report, and I can't find it in the pools
<pitti> keescook: there's no public way to do that AFAIK
<keescook> d'oh
<pitti> keescook: pinging Joerg in #debian-devel or so :)
<pitti> keescook: TBH I was a bit nervous about publishing our source NEW queue, too
* keescook nods
<pitti> after all, that might be stuff that is not redistributable, so it shouldn't be too official
<keescook> bryce: cool, once you get the Provides: line sorted out, just point me at your resulting -amd package.
<pitti> xmms2 binary-NEWed (phew), so have fun playing around with it
<keescook> pitti: cool.  I will let ogra investigate xmms2.  :)
<ogra> gah ... i talk to much ... voluntold again ...
<LaserJock> ;-)
<keescook> hehe
<shawarma> pitti: Mysql bug 29287
<bryce> ogra, the -via driver is already on my todo list; is a new -unichrome driver also needed?
<shawarma> pitti: http://bugs.mysql.com/bug.php?id=29287
<ubotu> Launchpad bug 29287 in xserver-xorg-driver-ati "Fails to clone display to external video (dup-of: 36768)" [Medium,Fix released]  https://launchpad.net/bugs/29287
<ubotu> Launchpad bug 36768 in xserver-xorg-driver-ati "[dapper]  Cannot switch external vga-out / LCD" [Medium,Fix released]  https://launchpad.net/bugs/36768
<ogra> bryce, no, only the yet unpackaged openchrome 
<pitti> Riddell: ah, libept is in binary NEW
<pitti> Riddell: that explains a lot :)
<shawarma> ubotu: No, I was talking about an *upstream* bug. Sheesh!
<pitti> Riddell: given-back on sparc, let's cross fingers
<keescook> okay, kdeutils uploaded to drop xmms-dev.  that's it, afaik.
<bryce> ogra, oh, the openchrome driver that doesn't have a package?  hrm
<keescook> with xmms out and evms out, gtk1 can go too
<bryce> ogra, well not likely to be done by tribe2... but I'll put it on my todo list to look into it
<ogra> bryce, i dont care about tribes :)
<ogra> only about final :)
<pitti> shawarma: thanks, sounds good
<pitti> -- gutsy/main build deps on libgtk1.2-dev:
<pitti> kdebindings
<pitti> libdv
<pitti> libiodbc2
<pitti> smpeg
<pitti> xmms
<pitti> keescook: ^
<shawarma> We'll see where it goes. I took a quick peek at the mysql code, and although my C++-fu is weak, it didn't look entire unmanageable.
<keescook> pitti: oh dang.
<keescook> libdv??
<pitti> gosh, not having -changes is really awkward
<ogra> Keybuk, any chance for initramfs-tools 0.88 before tribe2 ? 
<Keybuk> err?
<Keybuk> what do you want in 0.88?
<ogra> fixed netbooting
<Keybuk> ?
<Keybuk> -v
<ogra> option root-path "192.168.17.61:/opt/ltsp/ubuntu_feisty_i386"; doesnt work for us
<Keybuk> I see
<ogra> option root-path "/opt/ltsp/ubuntu_feisty_i386"; does 
<ogra> 0.88 has a fix for that
<Keybuk> and why doesn't it work for you?
<Keybuk> err, we're upstream for initramfs-tools
<ogra> because the variable handling in the nfsroot script is broken
<ogra> well the fix is in debian
<Keybuk> so it needs a merge?
<ogra> i can move it over indeed
<Keybuk> that seems like the best plan, if you've already found the fix
<Keybuk> patch is your friend ;)
<ogra> <-- was lazy waiting for a merge :)
<Keybuk> initramfs-tools rarely gets merged
<ogra> oki, i'll fix it then :)
<ogra> well mom lists it
<Keybuk> we tend to leave it alone unless we either want something from Debian, or Jeff has a lazy day
<pitti> Riddell: libept failed again on sparc
<pitti> Riddell: it's a bit awkward to binary-NEW stuff that's FTBFS on some arches, but I'll do it anyway since it blocks you
<pitti> keescook: libdv> for libdv-bin, I suppose? some GUI frontend
<keescook> let's make it non-responsive :)
<pitti> keescook: libdv-bin is in universe, though, so if they still didn't port it to gtk2, we could just drop -bin, or ./configure --without-gtk or so
<pitti> -- gutsy/main build deps on libsmpeg-dev:
<pitti> sdl-mixer1.2
<pitti> bah
<pitti> just one
<keescook> where are you getting the dep output from?
<pitti> keescook: checkrdepends
<pitti> http://people.ubuntu.com/~pitti/scripts/checkrdepends
<pitti> keescook: conveniently runnable on rookery (it has a local mirror)
<pitti> keescook: did you already fix 
<pitti> -- gutsy/main build deps on xmms-dev:
<pitti> kdeutils
<pitti> ?
<keescook> yup
<pitti> (it has flac, too, but you did that already, AFAIUI)
<pitti> keescook: cool
<pitti> keescook: so tomorrow xmms should be in anastacia
* pitti sharpens the change-override axe
<keescook> \o/
<keescook> I'm bummed about gtk1.2 -- I thought evms and xmms were it.  s'okay.
<pitti> Riddell: ept NEWed, so debtags should build everywhere except on sparc; can you please look into the sparc ftbfs for libept?
<bryce> keescook, ok it looks like xserver-xorg-video-1.0 is valid:  http://packages.ubuntu.com/feisty/x11/xserver-xorg.  Also I found that -i810 and -unichrome provide xserver-xorg-video-1.0
<bryce> http://packages.ubuntu.com/feisty/virtual/xserver-xorg-video-1.0
<keescook> bryce: ah! very good. then I'll just upload it as-is.
<bryce> yuppers
<bryce> yay, another one down.  Now back to -nv.
<keescook> bryce: whoa, is this an i386-only driver?
<keescook> https://launchpad.net/ubuntu/+source/xserver-xorg-video-amd/2.7.6.5~20060905-0ubuntu1
<keescook> it fails on all but i386
<bryce> probably
<bryce> I think the amd video is an onboard chip for amd mboards
<bryce> lemme doublecheck...
<sommer> wc
<keescook> that's going to keep it out of Debian; I adjusted the control file to build only on i386
<bryce> kees, yeah - http://en.wikipedia.org/wiki/Geode_(processor) x86 only
<wasabi> Um... any idea how to add static routes with network manager?
<wasabi> guess it doesn't support that. =/
#ubuntu-devel 2007-06-22
<ubuntu> 83.39.152.4 
<ubuntu> you fucker listen 
<ubuntu> who try to hack ubuntu server
<ubuntu> 83.39.152.4 
<ubuntu> this ip-hack ubuntu server
<ubuntu> where i can write to the police,to get him.
<somerville32> Ummm...
<Nafallo> ubuntu: contact abuse at your ISP instead.
<Nafallo> ubuntu: and this is not the right channel
<mvo> Riddell: looking over the cmake merge, I think the package can be synced (but I leave it for your judgment)
<fabbione> morning
<ajmitch> morning fabbione 
<mvo> hey fabbione
<fabbione> mvo: you are up incredibly early...
<fabbione> or late...
<mvo> fabbione: very early, happens to me every couple of weeks that I wake up in the middle of the night and can not sleep no more
<fabbione> mvo: welcome to the club dude
<fabbione> of the married people :P
<mvo> haha :-D
<fabbione> it's all the feelings we repress during the 2 weeks that explodes in one night
<fabbione> ;)
<mvo> I was told it will get worse when family grows :)
<mvo> who needs sleep when there are outstanding merges anyway?
* mvo drinks some more tea to wake up
<jsgotangco> mvo: i wake up at 5am to bring my kid to school at 7 and sleep around 1am sheeshh
<mvo> jsgotangco: uhhh, that is *very* little sleep :)
* jsgotangco sleeps all weekend
* StevenK has been naughty this week, going to bed around 1:20am, and getting up at 7:30am to go to $work
<pjdid> does anyone know any "GOOD" screen capture recording programs for linux
<lousygarua> checkout www.skrbl.com, gives u a nice web-based svg collaborative whiteboard, in case u wanna sketch some ideas in realtime outside of launchpad's blueprints thing
<pitti> Good morning
<mvo> good morning pitti
<fabbione> hey pitti
<ajmitch> hi pitti 
<Hobbsee> hiya pitti, mvo, fabbione 
* pitti hugs the channel
* Hobbsee throws pitti into the total perspective vortex
<fabbione> hey Hobbsee 
* StevenK waves to pitti
<pitti> NOOOOOOOOOoooooooo.......
* Hobbsee rescues pitti back out of it again
<Hobbsee> hi jono.  fix the world, please.
<Hobbsee> hi spam
<jono> Hobbsee: heh
<jsgotangco> hi
<nixternal> haha
<jono> I am off to bed in any sec - been awake 33 hours
<nixternal> hola
<nixternal> jono: I hate odd number, wait another hour and then go to bed
<Hobbsee> haha
<jono> heh
<Hobbsee> jono: i believe your input is wanted on the irc ops thing - it's the only thing holding up the council
<jono> when was this input requested? its news to me
<Hobbsee> it's probably in your email
<Hobbsee> CC mail, from what i hear
<jono> right
<jono> I havent checked mail for a few days because of travel
<Hobbsee> jono: that's...expected.
<Hobbsee> only the crazy people can check mail and irc and such while travelling.
<Hobbsee> apparently it's a skill.
<jono> heh
<jsgotangco> i think its w.r.t. governance docs
<jono> some would say I am crazy logging in when there is a perfect opportunity for sleep, after 33 hours and I have to be up in 6 hours
* Hobbsee shrugs
<ajmitch> jono!
<jono> heya ajmitch :)
<dholbach> good morning
<Hobbsee> morning dholbach!
<dholbach> hey Hobbsee
* Hobbsee ponders throwing dholbach into the total perspective vortex too
<dholbach> quoi?
<Hobbsee> pitti: was already thrown in.  *shrugs*
<Hobbsee> dholbach: any ideas on when we should call a REVU day for?
<dholbach> Hobbsee: I'd think that any day is a good day
<dholbach> TheMuso: uploaded - thanks a lot
<mdke_> does anyone know if we have a bug open about the fsck that starts every 30 boots?
* dholbach hugs mdke_
<TheMuso> dholbach: np thank you.
* dholbach hugs TheMuso too
<mdke_> morning dholbach 
<mdke_> Hobbsee: just to clarify, jono doesn't get CC mail
* dholbach hugs bzr-builddeb... a lot
<mdke_> so bzr-builddeb gets more hugs than us, eh?
<mdke_> fair enough
<fabbione> mdke_: that's not a bug
<fabbione> checking of the fs is normal and it should be done
<fabbione> 30 is usually a random number that can vary depending on a few things
<mdke_> fabbione: well, it's existence might not be, but its implementation is not good enough, in my opinion. I think there should be at least one of the following: (1) an opt-out, (2) an explanation that makes sense to people without knowledge of the linux filesystem, and (3) a splash screen
<fabbione> mdke_: 1) tune2fs or learn /etc/fstab, 2) google 3) there is a spec already
<mdke_> fabbione: thanks for 3), that answers my initial question. I don't understand 1) or 2) though
<fabbione> mdke_: the value of 30 is tunable and can be disabled. you need to know how to do it because it's really really bad to disable it
<mdke_> ok, so let's scrap (1). No opt out
<fabbione> mdke_: 2) if you want an explanation on why it's good to fsck your FS once in a while look for docs..
<mdke_> fabbione: no, that's not what I meant
<fabbione> mdke_: ok so explain what you mean
<mdke_> I will... give me a sec to type it
<fabbione> 1
<fabbione> too late
<fabbione> :)
<mdke_> damn these italian sense of humours
<mdke_> I was thinking that instead of "/dev/sda3 has been mounted 30 times..." it would be nice to say something that makes sense to normal users, like "Your hard disk needs to be checked every 30 boots, checking now..."
<fabbione> mdke_: well ok that's a totally different issue that can be addressed easily.. wishlist bug
<mdke_> cool
<mdke_> what's the appropriate package?
<shawarma> e2fsprogs
<mdke_> bless you
<mdke_> ok, thanks fabbione and shawarma 
<mdke_> it's bug 121687 if you are interested in triaging/subscribing
<ubotu> Launchpad bug 121687 in e2fsprogs "Confusing message for fsck check at boot" [Undecided,New]  https://launchpad.net/bugs/121687
<jsgotangco> nice
<jsgotangco> i wondered though, why it does that on first boot after install in alternate as well?
<Hobbsee> mdke_: right, yes.  i believe he was CC'd.
<Hobbsee> mdke_: but thanks for the clarification
<mdke_> Hobbsee: ah, there is more than one meaning of CC :)
<mdke_> he's not on the recent stuff, but maybe older email
<Hobbsee> mdke_: okay, i believe he was CC'd on the CC (community-council) email about the irc ops stuff
<Hobbsee> mdke_: indeed.  so the person who uses the most at once wins!
<Hobbsee> :P
<Tonio_> hello
<Hobbsee> hi Tonio_ 
<jsgotangco> dholbach: i've already updated the wiki on the sched for next week's CC thanks
<lousygarua> where do i download a beta for gusty for testing? is there such a thign? do i have to compile it from source?
<Hobbsee> !gutsy | lousygarua 
<ubotu> lousygarua: Gutsy Gibbon is the code name for the next release of Ubuntu (7.10). See https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000276.html and https://wiki.ubuntu.com/GutsyReleaseSchedule - Roadmap and specifications: https://blueprints.launchpad.net/ubuntu/gutsy - Support in #ubuntu+1
<shawarma> lousygarua: We had out first alpha release about two weeks ago. 
<shawarma> lousygarua: http://cdimage.ubuntu.com/releases/gutsy/tribe-1/
<shawarma> lousygarua: If you're slightly more adventurous, there are daily images as well.
<shawarma> lousygarua: http://cdimage.ubuntu.com/daily-live/current/
<lousygarua> shawarma: hmm thanks
<dholbach> jsgotangco: rock and roll - thanks a lot
<shawarma> lousygarua: Thanks for helping out.
<dholbach> asac: new CC meeting announced (June 26th, 13-15 UTC)
<asac> dholbach: thanks!
<asac> dholbach: will forward
<Hobbsee> hm.  gutsy problems looks a little nasty
<pitti> mvo: can you please upload the package for bug 114569?
<ubotu> Launchpad bug 114569 in update-manager "update-manager -d does not show new development release (only -c -d)" [Medium,In progress]  https://launchpad.net/bugs/114569
<pitti> mvo: then I can process it with today's batch
<shawarma> The GutsyReleaseSchedule wiki page says "Please do not edit".. Nonetheless, it's ok if I add our server sprint, right?
<pitti> shawarma: that sounds fine to me
<shawarma> Yay, -changes is back.
<pitti> shawarma: \o/
<shawarma> Aw, crap. Those two were from feisty-changes..
<shawarma> Maybe gutsy-changes is still gone.
* siretart hugs mvo for the now merged work on  http://people.ubuntu.com/~mvo/bzr/apt/xs-vcs-bzr/
<siretart> :)
* mvo beams
<mvo> pitti: will do the upload now (sorry, was disctracted)
<mvo> pitti: new update-manager for feisty-proposed uploaded
<pitti> mvo: thanks, accepted; there is another one in -proposed, that stuff should be tested
<pitti> piling up stuff in -proposed is bad
<mvo> pitti: totally agreed, I will talk to brian about it and do a test plan with him
<mvo> pitti: I can't test it myself :/
<mvo> (well, I *do* test it myself of course :) 
<pitti> :)
<mvo> you know what I mean :P
* pitti moves xmms into universe and yays
<mvo> yeah!
<seb128> ;)
<mvo> desktop-effects can go that way too (or vanish from the archive complettly)
<pitti> mvo: oh?
<seb128> pitti: merged to gnome-control-center
<pitti> oh, cool
<pitti> mvo: can you unseed it then, please?
<seb128> pitti: it's a new tab in the appearance capplet now
<seb128> doing it now
<ajmitch> pitti: just evms to go, or is that the last of gtk+ 1.2 in main?
<seb128> mvo: ^
<seb128> I've some seed changes to do
<pitti> ajmitch: it's already iun universe
<ajmitch> yay!
<seb128> pitti: BTW do I need to discuss with somebody if I want to add xdg-user-dirs(-gtk) to desktop seed?
<pitti> ajmitch: there's still some stuff left: libdv and smpeg, AFAIR
<ajmitch> aw.. :(
<pitti> seb128: no, that's fine; in fact you should do so to keep it in main
<seb128> pitti: a new smpeg using gtk2 has been uploaded to Debian yesterday
<pitti> seb128: if it's part of an approved spec or will happen upstream, that's fine
<mvo> pitti: I have done that this morning, just not uploaded new ubuntu-meta yet
<pitti> seb128: ! rock
<pitti> seb128: cool, that's not modified
<pitti> seb128: hm, it's not in incoming
<pitti> ... want ... sync ...
<ajmitch> syncing still broken?
<seb128> pitti: maybe I'm wrong
<seb128> pitti: http://packages.qa.debian.org/s/smpeg/news/20070621T131703Z.html
<pitti> ajmitch: no, works
<pitti> seb128: maybe my current autosync run caught that then :)
<geser> pitti: LP lists it as pending without a date
<pitti> yeah, being published
<pitti> seb128: seed changes> darn, I forgot to change galde
<pitti> seb128: glade
<ajmitch> pitti: when does autosyncing stop?
<pitti> ajmitch: at UVF
<ajmitch> hm, I thought it was DebianImportFreeze
<seb128> pitti: doing it
<seb128> pitti: I've to do some seed changes
<pitti> mvo: ok, so can I kick desktop-effects out of the archive right now? or does it still need somehting?
<pitti> mvo: I don't see anything in 'appeareance'
* pitti dist-upgrades first before complaining
<pitti> ajmitch: that should coincide
<pitti> mvo: ah, there it is, nevermind me
<ajmitch> pitti: I'm confused, DebianImportFreeze is listed as today
<pitti> mvo: 'Enable extra effects' -> that's a bit underdescribed IMHO
<pitti> ajmitch: hm, weird
<seb128> mvo: I told him on #ubuntu-desktop some minutes ago ;)
<geser> I uploaded xcache tonight and got these two mails: http://paste.ubuntu-nl.org/26686/ a reject and an accept
<geser> does somebody have an idea what happened there?
<pitti> mvo: compiz-fusion-plugins-extra> please do a followup upload with pointing to common-licenses/GPL (I'll let it through and trust you with that, though)
<ogra> oh, is -changes back ?
<pitti> ogra: apparently only for syncs and feisty
<dholbach> siretart: mvo just told me that he uses   bzr bd --merge --builder "dpkg-buildpackage -S -sa -rfakeroot"  because otherwise it will not include the orig.tar.gz in the .dsc for -0ubuntu1 versions - do you know anything about that?
<ogra> i just got a gutsy mail ....
<pitti> ogra: hm, right, that was one I source-NEWed
<pitti> ogra: I'm not sure whether it works for non-NEW uploads
<ogra> ah
<mvo> pitti: cool, thanks
<pitti> mvo, seb128: compiz stuff source NEWed
<seb128> pitti: danke
<mvo> danke!
<seb128> pitti: https://bugs.launchpad.net/ubuntu/feisty/+source/nautilus-cd-burner/+bug/114770
<ubotu> Launchpad bug 114770 in nautilus-cd-burner "Cannot burn on RW media because n-c-b does not unmount it" [Low,Fix released]  
<seb128> pitti: easy SRU candidate if you want to look at it
<pitti> seb128: erk, indeed; ack'ed
<seb128> pitti: danke
<siretart> dholbach: right, this is currently a PITA. 
<siretart> dholbach: the problem is that we are a bzr plugin here, and so we have to use the bzr commandline parser
<siretart> dholbach: which isn't as flexible as dpkg-buildpackage, so you cannot have options like '-sa'
<siretart> dholbach: we are still looking for a solution how to do that use case much simpler. suggestions welcome
<pitti> keescook: FYI, I'll override  libapache2-mod-apparmor to section 'web'; 'libs' is not the best one IMHO
<dholbach> siretart: ok, I see
<dholbach> siretart: just wanted to know, how I'd explain it in the http://wiki.ubuntu.com/MOTU/Recipes
<geser> have .changes files to be ascii only?
<pitti> geser: UTF-8 should be ok for Maintainer: and changelog
<geser> because I got these to mails http://paste.ubuntu-nl.org/26686/ when I uploaded xcache
<geser> Maintainer is  Michal iha <nijel@debian.org>
<pitti> geser: hmm, please report this as a soyuz bug
<geser> ok, will do
<pitti> might be yet another regression from yesterday's rollout
<seb128> dholbach: glib fix uploaded
* dholbach HUGS SEB128
<seb128> pitti: seed updated for glade-2 to universe and glade-3 supported
<dholbach> seb128: you ROCK
<pitti> seb128: yay
* seb128 hugs dholbach pitti
<dholbach> seb128: I'll make sure the *mm stuff gets uploaded and I'll try it on my own
<pitti> seb128: we actually need an ubuntu-meta upload for the desktop-effects dropping; shall I care about that?
<pitti> seb128: oh, btw, did you merge the changes to edubuntu etc.?
<seb128> pitti: wait a min please, I do the xdg-user-dirs(-gtk) change now
<seb128> pitti: no
<seb128> will do
<pitti> cool, thanks
<seb128> pitti: xdg changes commited to desktop, you can update ubuntu-meta if you want
<seb128> I'll merge with other seed later, I've to run for lunch now
<seb128> I'll do it after lunch
<pitti> mmm lunch
<Chipzz> mdke_, fabbione: I think there should also be a Postpone option. These checks always tend to happen just when they're a pain in the behind :P
<fabbione> Chipzz: i disagree for different reasons.. you have usplash there, three is no "GUI" for lusers that don't understand what it is, you can't halt the boot for a question (that is bad bad bad bad).
<fabbione> one option could be something you pass to the boot options
<fabbione> skipfsck
<Chipzz> it shouldn't be a question, just more sane behaviour from e2fsck
<fabbione> that is temporary
<fabbione> Chipzz: e2fsck can't read your mind if you want to check or not
<Chipzz> problem is, pressing ctrl-c will cause e2fsck to exit with an error, and the rest of the boot will fail
<fabbione> and you don't want to interrupt a fix if it started realy mangling inodes around
<Chipzz> fabbione: fsck shouldn't exit with an error when pressing ctrl-c then
<fabbione> Chipzz: it doesn't at boot time afaik
<fabbione> and if you do it manually when running .. well you do the mess, you collect the pieces...
<Chipzz> I had someone complain about the issue that the fsck happend just when he was booting his laptop for his final thesis presentation; the public was not amused for having to wait
<Chipzz> neither was he
<Chipzz> the next person to give a presentation just disabled the automatic check with tune2fs to avoid having the same embarassement
<Chipzz> (I did that too back when I had debian installed, when I grew sick of having to wait)
<Chipzz> which may not be the effect you want
<fabbione> i still disagree on disabling it by default..
<fabbione> if you want to do it on your laptop or machine go ahead and do it
<fabbione> i prefer to preserve my data if something is going wrong
<fabbione> and i am sure most of the users out there will agree that data > a bit of waiting time
<mvo> we have a spec to make it possible/easy to skip the check now
<fabbione> specially given the fact that most of the users out there do not yet understand what this fsck thing is all about
<fabbione> mvo: making possible to skip is good.. on request.. etc.. disabling by default is bad ..
<fabbione> mvo: anyway..
<fabbione> this is yet another one of those endless discussions
<Chipzz> fabbione: but I wasn't arguing in favor of enabling by default ;)
<Chipzz> 13:01 < Chipzz> mdke_, fabbione: I think there should also be a Postpone option. 
<fabbione> <fabbione> one option could be something you pass to the boot options
<fabbione> <fabbione> skipfsck
<Chipzz> fabbione: that's something you're likely to forget
<fabbione> it still requires the user to understand what to do and why he is doing it :)
<fabbione> even clicking on a GUI with Postpone
<fabbione> "Hey we need to fsck your disk.. " <OK> <Postpone>
<fabbione> just the idea of fsck my disk.. would make me think of a typo :P
<Chipzz> you would obviously put check there instead of fsck ;)
<fabbione> ehhe
<Keybuk> cool ... I think, for the first time in a while, all our patches are now in udev upstream again
<ogra> pitti, i ust did a testinstall of the daily iso ... 
<ogra> apart from being oversized debootstrap segfaults
<pitti> erk
<StevenK> ... debootstrap is shell. Ouch.
<StevenK> Unless it's using cdebootstrap.
<ogra> no its tar that fails it seems
<pitti> StevenK: no, we don't use that
<ogra> debootstrap: tar:
<pitti> StevenK: I wonder what the idea about cdebootstrap is; the very point of it should be portability etc., which shell certainly is much better at than a C program?
<pitti> back in ~ 30 minutes
<ogra> debootstrap: Short header
<ogra> debootstrap: 
<ogra> debootstrap: Segmentation fault
<StevenK> pitti: Indeed.
<StevenK> ogra: Can you sh -x it?
<AlinuxOS> pitti, Viel Gluck! ;9
<ogra> ls  
<ogra> gah
<mvo> pitti: restricted-manager --check-composite will check for nvidia only, is this correct? so it will not tell me if the driver is generally compositable?
<pitti> mvo: right
<pitti> mvo: it only checks if it can install one
<mvo> ok, thanks
<sladen> doing occasionally at boot isn't necessarily the best time.  taking a cow snapsnot, running fsck --check-only on that will report if there are errors;  then at *that* point (eg. a running system, the user can be notified that they need to reboot [now, later] 
<Keybuk> sladen: are you advocating lvm by default there?
<sivang> smurf: ping
<sladen> Keybuk: suspect dm-snapshot is all that is needed
<mvo> woah, runing glxinfo in a vesa session kills my X server
* mvo is impressed
<simira> mvo: I am very happy with update-manager for the time being
<mvo> happy to hear that simira :-D
<StevenK> pitti?
* Hobbsee waves
<pitti> StevenK: what did I break this time?
<Hobbsee> pitti: the world.  pleasefix.
<StevenK> pitti: Heh. rss-glx. I think.
<pitti> StevenK: o freealut: libalut-dev libalut0
<pitti>    [Reverse-Depends: libalut-dev] 
<pitti>    [Reverse-Build-Depends: rss-glx] 
<pitti> this?
<pitti> this is there for ages, and not really my fault :)
<StevenK> pitti: Yup, hang on a sec
<Hobbsee> pitti: you'll get blamed anyway
<pitti> although I'm ultimately the one who got to clean it up
<StevenK> pitti: http://paste.ubuntu-nl.org/26725/
<ion_> Could someone please describe the Build score at launchpad.net? I assume the build order is based on that, but how is it defined?
<pitti> StevenK: oh, you made it drop the jasper dependency? cool
<Mithrandir> ion_: it's just a priority, higher means higher priority.
<StevenK> pitti: Along with a bunch of others, and rss-glx doesn't even Build-Depend on it.
<pitti> StevenK: good case for -Wl,--as-needed, I guess
<StevenK> pitti: ubuntu2 was just a rebuild
<StevenK> pitti: Hence my concern
<pitti> ah
<ion_> mithrandir: I mean, what is the algorithm used to set the score for each build?
<StevenK> I'd rather Depends stay nailed on. :-)
<pitti> StevenK: bah, many of them are bogus
<Mithrandir> ion_: unsure, but why are you asking?
<ion_> mithrandir: Just curious.
<pitti> StevenK: with --as-needed I could drop 2/3 of binary dependencies sometimes
<StevenK> I suspect --as-needed has hit further up the build chain
<Mithrandir> ion_: libs are higher than non-libs, stuff with higher priority go before bits with lower priority, iirc.
<StevenK> pitti: Okay, if you're not worried, I'll upload it.
<ion_> It would be kind of nice if --as-needed would be the default, and it would be removed on a per-package basis in case it breaks a build.
<Hobbsee> Mithrandir: and anthing by you at the end.
<ion_> mithrandir: Alright, thanks.
<Hobbsee> of course.
<pitti> StevenK: usually those get pulled in through transitive dependencies
<Mithrandir> Hobbsee: shh!
* Hobbsee ducks
<pitti> StevenK: if the exectuable itself doesn't link against it, the dependency is bogus and just a nuisance
* StevenK checks that
<StevenK> pitti: Right, I concur. None of the binaries touch jasper.
<StevenK> pitti: Uploaded. Thanks for your help.
<pitti> StevenK: dh_shlibdeps is very good at not dropping needed stuff, it's very precise
<pitti> StevenK: thanks for house cleaning
<StevenK> pitti: Any time, means the next time is easier.
<pitti> hi calc
<Hobbsee> morning calc
<calc> good morning
<pitti> mvo: can you do a GnomeAppInstallDesktopDatabaseUpdate, please?
<mvo> pitti: sure
<pitti> btw, for the folks listening here, bigjools has found the reason for gutsy-changes@ breakage
<dsk> ubuntu 7.04 compiler sucks 
<Amaranth> dsk: err
<gnomefreak> dsk: pick a compiler
<pitti> dsk: that lacks a tad of detail to be an useful bug report
<dsk> every time it give a stack_check_failed :(
<dsk> i tried compiling FILO 0.5
<pitti> dsk: -fno-stack-protector
<dsk> yeah tried that too :(
<dsk> the same package compiled on Fedora 7 perfectly well
<Amaranth> dsk: i see no error log
<pitti> above option should work
<dsk> ubuntu even gives stack check failed on cryopid compilation
<dsk> Amaranth: error log where?
<Amaranth> of your compile that failed
<dsk> ohh :) where do i put it?
<pitti> asac: nspluginwrapper NEWed, right in time for the publisher cycle in 2 minutes :)
<pitti> asac: that thing sounds promising
<Hobbsee> pitti: does it actually build, though?
<pitti> Hobbsee: yep, it was binary new
<Hobbsee> ahhh
<asac> pitti: yeah ... works well for flash
<asac> pitti: flash will be updated right after tribe-2
<dsk> Amaranth: oops! it worked now
<dsk> i was missing -fno thing from one makefile 
<dsk> sorry for the trouble :)
<pitti> dsk: a make distclean before changing the option works wonders :-P
<pitti> heh
<Amaranth> meh, nspluginwrapper
<Amaranth> gnash works with youtube :)
<dsk> pitti: yeah did that :)
<Amaranth> and i think google video
<asac> Amaranth: google video works with gnash ... cool
<asac> Amaranth: i hope next gnash upload will be better ... want to try agg renderer instead of opengl
<Amaranth> yeah, that should help a lot
<Amaranth> it's the most cared for backend
<asac> need some backporting from trunk in order to build konqueror/klash though
<Amaranth> yeah, i remember debian punting on that is using opengl for klash
<Amaranth> err, and using
<dsk> umm one more question ->
<dsk> can i install xcdroast + its dependencies from a ubuntu repo to my fedora 7 box via alien
<Hobbsee> surely you'd need to ask fedora people that?
<Amaranth> i would not recommend it
<dsk> well fedora 7 xcdroast is broken :( 
<Amaranth> tell them :)
<dsk> Amaranth: then maybe i could take the source(debian/ubuntu) + patch and compile ->  then it should not be a problem i hope ?
<dholbach> pitti: THANK YOU
<pitti> dholbach: np
<StevenK> pitti: rss-glx, dvdauthor, kxstitch, prestimel and kmediafactory uploaded for libjasper transition love. That's all of the main and multiverse, and leaves about 4 universe ones that I can wrap up tomorrow.
<pitti> StevenK: yay you
* pitti hopes that -changes@ works again soon
<Hobbsee> http://www.fredemmott.co.uk/blog_99
* Hobbsee likes.
<sn0> nice Hobbsee 
<sn0> did you see the wifi eats your babies one ?
<Hobbsee> yep
<sn0> :-)
<pitti> seb128, dholbach, asac, Hobbsee: what should we mention as highlights in tribe-2 on the wiki page? gnash, compiz by default, xdg-user-dirs, Broadcom firmware install in r-m, anything else?
<seb128> GNOME 2.19.4 ;)
<Hobbsee> nixternal: ^
<pitti> seb128: do you have a pointer about xdg-user-dirs, what the marketing team could turn into an useful description?
<Hobbsee> pitti: amarok 1.4.6
<Hobbsee> hrm.  there doesnt seem to be terribly much on the kde side...
<Hobbsee> disturbing.
<Riddell> mhb should get gdebi merged and uploaded
<Riddell> gdebi-kde
<Hobbsee> oh good
<dholbach> kdebi? :)
<Riddell> dholbach: god no
<dholbach> but! it! has! to! start! with! a! K!
<Riddell> no, it really doesn't
* dholbach shuts up :)
<Hobbsee> heh
<Hobbsee> Riddell: dont you like kworld?
<asac> pitti: yeah ... maybe firefox 3.0 alpha for testing (with a hint that this is experimental software)
<asac> pitti: and only if the builds went fine
<asac> pitti: firefox 3.0 alpha5
<pitti> asac: I just source-NEWed it, let's find out
<Riddell> Hobbsee: names with excessive k's are evil
<Chipzz> dholbach: kdebi-kde? ;)P
<asac> pitti: yes keep that info out of release notes until i get some positive feedback (hopefully over the weekend)
<ogra> hmm, weird, i assume seb128 updated the seeds before rebuilding edubuntu-meta ... why didnt bazaar.lp.net send me a branch change notification for that, i'm subscribed to it ... and it does that for all other branches ... weird
* Chipzz ducks :P
<asac> pitti: i will ask on forums to test, so we see if it trashes profiles or something in some cases ;)
* Riddell burries Chipzz and dholbach in a pile of g's
* Chipzz likes it there :)
<ogra> heh
<asac> pitti: don't know if its normal, but i don't see an upload on https://launchpad.net/ubuntu/+source/firefox-granparadiso so far
<seb128> ogra: what? I did merge the ubuntu seed changes to edubuntu, yes
<seb128> pitti: http://mail.gnome.org/archives/desktop-devel-list/2007-May/msg00006.html
<asac> pitti: i believe to remember that it usually appears after it has been source NEWed
<ogra> seb128, yeah, its weird that i didnt get a branch change ail for that, i thought subscribing to the branch would send that like it dos for all others i'm subscribet to
<Hobbsee> erk.  thunderbird buglist looks terrible.
<ogra> s/ail/mail/
<asac> Hobbsee: feel free to help :)
<asac> Hobbsee: any specific bugs you have in mind?
<Hobbsee> asac: i just marked one invalid :)
* asac hugs Hobbsee 
<asac> ;)
<Hobbsee> asac: nah.  it's hard for me to triage them anyway, as i use the mozilla binaries of firefox & thunderbird
<asac> Hobbsee: oh most bugs should be upstream
<Hobbsee> asac: true that
<asac> Hobbsee: so you will see them in your builds as well
<Hobbsee> true
<dholbach> can somebody give back libglademm2.4 on sparc, powerpc and i386?
<Hobbsee> asac: come to think of it - not running the ubuntu version might be useful - seeing as i can tell what's still in a clean upstream version, vs the ubuntu changes.
<asac> Hobbsee: exactly
<Hobbsee> asac: https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/36218 looks like an easy fix.
<ubotu> Launchpad bug 36218 in mozilla-thunderbird "Thunderbird should be compiled with gnomevfs" [Wishlist,Confirmed]  
<asac> Hobbsee: that is fixed imo
<asac> we ship -gnome-support iirc
<Hobbsee> asac: want me to close it as such then?
<asac> hmm
<asac> Hobbsee: ok its fixed since gutsy
<asac> Hobbsee: i fixed it in debian ages ago ... which is why i thought that the package in feisty should have it as well
<Hobbsee> asac: cool.  marked as such
<asac> Hobbsee: yes please close
<asac> Hobbsee: thanks
<Hobbsee> :)
<asac> Hobbsee: https://wiki.ubuntu.com/MozillaTeam/Bugs/Tags
<asac> we hav tags set on most bugs ... so you can pick a task and work on a small set of bugs
<asac> e.g. if you feel like you want to verify testcases (if you can reproduce) you click on mt-needtester link
<Hobbsee> asac: right.  er, if we've got bugs that are saying "fixed in 2.0" can we mark as fixed?
<Hobbsee> looking at mozilla-thunderbird bugs, as opposed to thunderbird
<asac> Hobbsee: yes ... just state that its fixed in gutsy since 2.0
<Hobbsee> cool
<Hobbsee> ok
<asac> Hobbsee: hmm mozilla-thunderbird bugs are not really mozilla-thunderbird anymore ... afaik next time you touch them lp automatically reassigns them to thunderbird
<Hobbsee> asac: yeah, i suspected as much.  yet you still run 1.5 in dapper, dont you?
<asac> Hobbsee: so we should deal with them as if they where thunderbird bugs
<asac> Hobbsee: me?
<asac> Hobbsee: no :) ... just in chroot
<Hobbsee> you being ubuntu
<asac> Hobbsee: ah ... sorry
<Hobbsee> :)
* Hobbsee hasnt used dapper in...ages
<asac> Hobbsee: thunderbird is 2.0 since gutsy ... dapper, edgy, feisty ... all are 1.5
<Hobbsee> oh right, yes.
<asac> thunderbird 2.0 release was late about 6 month upstream ;)
<Hobbsee> asac: i get confused - i ran 2.0 alpha's and betas for ages, as there was such a difference - so i tend to think it's been out longer than it actually has
<pitti> asac: right, but it needs a publisher cycle first
<Hobbsee> asac: https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/43493 may warrant fixing
<ubotu> Launchpad bug 43493 in mozilla-thunderbird "Thunderbird should have a "Get Help Online" option in Help menu" [Wishlist,Confirmed]  
<pitti> dholbach: given back
<dholbach> pitti: rock - thanks
<pitti> seb128: merci for the link
<seb128> pitti: np
<Hobbsee> asac: what was your thought on https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/49568 ?
<ubotu> Launchpad bug 49568 in mozilla-thunderbird "Thunderbird KDE-integration" [Wishlist,Confirmed]  
<Hobbsee> asac: that's a kubuntu-type thing.  got any interest in implemetnign it from your end?
<asac> Hobbsee: let me see
<asac> Hobbsee: i have a big todo to get better kde integration for mozilla applications done
<asac> Hobbsee: but i haven't received much input so far on what would be needed
<Hobbsee> asac: right, so that is on your todo list.  it looks doable with a custom user.js file.
<Hobbsee> asac: shoot me an email, etc, when you want to work on that - i've got thoughts, and know of places where people have talked about it.
<Hobbsee> asac: i've just got stacks that i want to do, and that hasnt gotten to the top of the pile yet - particularly as i dont even run the ubuntu version
<asac> Hobbsee: why don't you run ubuntu version?
<Hobbsee> asac: a)  it seems a lot slower, probably due to the pango stuff, iirc  b)  i was running 2.0* for ages before ubuntu released it c) lots of extra gnome dependancies
<Hobbsee> mainly b) - which became habit
<asac> c) isn't true
<asac> all gnome dependencies should be in -gnome-support now
<asac> Hobbsee: a) should be fixed ... it was a patch we had that had severe performance impact
<asac> it should be fixed since final feisty version
<Hobbsee> asac: yummy
<Hobbsee> right
<Hobbsee> like i say - mainly b
<asac> Hobbsee: would be great if you could at least compare
<Hobbsee> and i like being able to just install any browser plugin, or run an update from the main firefox window
<asac> as you have about a feeling of the performance ... e.g. is there still a recognizable difference
<Hobbsee> i mean, installing flashplayer *just works* with the binary - it was amazing.
<asac> Hobbsee: where is flashplayer installed?
<asac> after you do this?
<Hobbsee> didnt look.
<Hobbsee>  /home/sarah/.mozilla/plugins/libflashplayer.so i'd say
<asac> please verify 
<Hobbsee> yep.
<Hobbsee> sarah@LongPointyStick:~$ locate flashplayer
<Hobbsee> /home/sarah/.mozilla/plugins/libflashplayer.so
<Hobbsee> /home/sarah/.mozilla/plugins/flashplayer.xpt
<Hobbsee> /home/sarah/.macromedia/Flash_Player/macromedia.com/support/flashplayer
<Hobbsee> /home/sarah/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys
<Hobbsee> /home/sarah/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/settings.sol
<asac> does your user have write access to global install location?
<Hobbsee> no, it's in /opt
<asac> Hobbsee: did the install work through plugin wizard?
<Hobbsee> asac: yep
<Hobbsee> i'm going "i dont think this will work, but we'll give it a shot...hey look!"
<crimsun> are you implying that that method of installing the Flash plugin works whereas using flashplugin-nonfree didn't/doesn't?
<Hobbsee> crimsun: i didnt try flashplugin-nonfree
<Hobbsee> crimsun: i'm not implying anything about the ubuntu version of firefox and thunderbird, per se.
<Hobbsee> crimsun: i usually have to do slight fiddly bits as it's in a different location anyway - which is fine.
<asac> crimsun: why does plugin wizard not work for us?
<crimsun> I'm more interested in whether flashplugin-nonfree works or not.
<asac> crimsun: e.g. we don't get results, right?
<asac> crimsun: it works :)
<Hobbsee>  flashplugin-nonfree works, last time i checked.
<crimsun> asac: I've never used the plugin wizard, but I've seen conflicting reports whether it does work.  It's clouded by the affected firefox versions - some are for dapper, others edgy, yet others feisty, etc.
<dholbach> TheMuso: want to do the new gnome-mag?
<Hobbsee> crimsun: i've had it not work a lot of the time - this was the first time it happened to work.
<Hobbsee> uh...okay...virtualbox broke on me.
<Hobbsee> how weir.d
<asac> Hobbsee: just tried in gutsy firefox ... plugin wizard works
<Hobbsee> asac: neat!  :D
<asac> Hobbsee: feisty too
<Hobbsee> asac: very cool :)
<wasabi> the commercial repository never really worked out well did it?
<Hobbsee> wasabi: it probably would if it were kept updated, etc
<wasabi> exactly.
<Hobbsee> then again, i wonder about linspire
<Hobbsee> werent they wanting to do CNR?
<Hobbsee> for ubuntu?
<wasabi> Do people actually care about CNR?
<wasabi> I've never met a single person who wasn't happen with our add/remove
<Hobbsee> define "people"
<Hobbsee> s/happen/happy/ ?
<wasabi> happy. yes
<wasabi> excuse my idiotic spelling.
<Hobbsee> depends.  if they're used to opera in windows, they want to use it in ubuntu too.  *shrugs*
<wasabi> Just not sure why that can't be done with our add/remove ;)
<mikmorg> hello
<Hobbsee> asac: killed 5.  
<Hobbsee> asac: and i take back what i say about a bad listing of bugs - you guys are actually using "high" and statuses and such.
<mikmorg> cjwatson: Are you around today?
<asac> Hobbsee: yes ;)
<Hobbsee> asac: :)
<Hobbsee> asac: it's still way better than kde* is
<asac> hehe ... we try to sort bugs and push them from bucket to bucket ... the strict tag/state policy allows us to detect 'triag-bugs' ... like someone confirmed without having a real testcase et al.
<pitti> BenC: hi
<Hobbsee> asac: yep
<BenC> pitti: hey
<Hobbsee> seb128: heh, i see why you're about to trout the next person who asks about that glib warning
<Hobbsee> oh grrr.  i fixed the autoreplies yesterday, adn tehy're broken today
<pitti> Hobbsee: ?
<Hobbsee> pitti: the greasemonkey script.  didnt you mention the same thing?
<pitti> Hobbsee: it forgot my responses completely twice
<pitti> Hobbsee: but today it was tame
<Hobbsee> urgh
<Hobbsee> it keeps mine, just the versions i first put in
<pitti> and, I have the problem that it sometimes doesn't remember bug states the first time
<Hobbsee> :(
* Hobbsee wonders what to do with https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/116642
<ubotu> Launchpad bug 116642 in thunderbird "Thunderbird always shows 1 unread email in Inbox" [Undecided,New]  
<Riddell> mvo_: are you planning to merge gdebi-kde today?  I can do it if you're short of time
<Riddell> pitti: dolphin file manager is new in tribe 2 for kubuntu (it's not default yet but will be if people like it)
<pitti> Riddell: oh, indeed; I'll do a followup to the mail to marketing team, for dolphin and gdebi (noticing that it's not sure yet)
<keescook> pitti: libapache2-mod-apparmor> yeah, good call.  it seems other stand-alone apache mods are that way too. (libapache2-mod-geoip)  thanks!
<mikmorg> cjwatson: ping
<mvo_> Riddell: I will do it today
<Riddell> ok, thanks
<pitti> bdmurray: hmm, mounting FAT partitions on my USB stick and my hard drive works well
<pitti> bdmurray: do you get this with vfat, too?
<pitti> bdmurray: org.freedesktop.Hal.Device.Volume.UnknownFilesystemType : Unknown file system 'ntfs-3g' seems pretty specific to ntfs
<bdmurray> pitti: I only have ntfs on that system
* pitti creates an NTFS partition
<bdmurray> and the original reported hasn't responded
<pitti> right :/
<pitti> I really don't believe that VFAT is generally broken
<pitti> maybe he just tested ntfs as well, or so
<bdmurray> It seems like it is recommending ntfs-3g instead of ntfs
<pitti> right
<pitti> and we don't install that by default
<bdmurray> right
<pitti> bdmurray: do you have ntfs-3g installed? if not, does it help?
<Hobbsee> who's interested in dpkg?
<bdmurray> pitti: I don't at the moment
<pitti> Hobbsee: iwj. Heavily. :)
<Hobbsee> there's an update-alternatives fix at https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/118246
<ubotu> Launchpad bug 118246 in dpkg "update-alternatives warnings" [Medium,Confirmed]  
<Hobbsee> iwj: ping
<Hobbsee> it's annoying me.
* Hobbsee coudl just...milestone it for herd 2 to make sure it gtes done...
<nixternal> Hobbsee: what were you pointing out to me up there?
<bdmurray> pitti: that helped a fair bit ran into another issue re unclean shutdown but I think that is fine
<nixternal> I think the Gnome side of the tribe pages are done by marketing
<Hobbsee> nixternal: a couple of lines above the point
<pitti> Hobbsee: looks sane enough
<Hobbsee> pitti: i've no idea.  
<pitti> Hobbsee: why don't you upload it yourself if you fixed it? :)
<Hobbsee> pitti: i didnt fix it.
<Hobbsee> pitti: i just looked up the bug
<Hobbsee> pitti: but i've had the unpleasant thought that i could upload it, yes
* Hobbsee notes that she'd end up writing a very interesting changelog release if she did...
<pitti> Hobbsee: '* fix some unintelligible Perl runes to desuckify it'?
<Hobbsee> pitti: it was going to be along the lines of * This is the ZOMG i hope i dont break dpkg upload.  Patch by ...
<pitti> bdmurray: so, I set up an ntfs partition now; gnome-mount gives me an error dialog that ntfs-3g is not supported
<pitti> Tonio_: can you pleae fix network-manager-gnome to depend on network-manager? apt-get wants to auto-remove network-manager
<bdmurray> pitti: right that's the bug
<pitti> /dev/hdc2 on /media/testntfs type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=4096)
<pitti> yay
<Tonio_> pitti: yes
<pitti> wow, my first ntfs fs EVER
<Tonio_> pitti: there is something broken in the network-manager-dev package
<Tonio_> pitti: dhshlibsdeps should pick up the network-manager dep automatically
<pitti> uh?
<pitti> that would be interesting
<Tonio_> pitti: that's the way the depandancy was picked up before :)
<Tonio_> pitti: it never had to be hardcoded in control
<Hobbsee> pitti: ...you mean you've never used NTFS before?
<pitti> bdmurray: so, this would need a MIR and review, promotion, and to become a dependency of something (probably a recommends of ubuntu-desktop)
<Tonio_> pitti: or am I missing something ?
<pitti> Hobbsee: no, up to a few weeks ago my state of mind was 'yeah, there's a r/o kernel driver for it and no way how to create an ntfs fs under linux'
<Hobbsee> heh
<pitti> Tonio_: oh, I see
<pitti> Hobbsee: and my latest windows was some 3.11, which I never used much (just if I needed to write a letter or so); I spent most of my time in DoS and then switched to SuSE 4.3 :)
<Hobbsee> ahhh....
<Hobbsee> i see, i see.
<Hobbsee> (you lucky people)
<pitti> bdmurray: maybe it would be easier for tribe-2 to just use the kernel fs
<bdmurray> pitti: that seems safest I am not current on the state of ntfs-3g
<Tonio_> pitti: fyi, I'll send an email on the -devel list on monday concerning the missing patches and what's todo on the packages
<Tonio_> the kde part is done, but I'll technically limited concerning the gnome part
<Tonio_> s/I'll/I'm
<pitti> bdmurray: thanks for your work on the bug so far, I take over here
<pitti> Tonio_: that would be good, especially for the handling of statically configured devices
<pitti> mvo: erm...
<pitti> WARNING: 'gnome-mount' is maintained in the 'Browser' version control system at:
<pitti> 'http://svn.debian.org/wsvn/pkg-utopia/packages/unstable/gnome-mount'
<pitti> mvo: it should probably ignore -Browser :)
<mvo> pitti: isn't that what you wanted?
<pitti> mvo: but great that it points this out now!
<mvo> pitti: aha, yeah. browser is probably not there :)
<mvo> s/is/shouldn't/
* pitti hugs mvo
* Hobbsee hugs pitti and mvo 
* Hobbsee waits for dpkg to build.
<txwikinger> Is bug hugging day again?
<mvo> pitti: please remind me about it, I will not manage to look at it today
* mvo hugs pitti and Hobbsee
<pitti> mvo: no, it's nowhere near urgent
<mvo> txwikinger: there can never be enough hugging
<pitti> mvo: I'll file a bug, ok?
<txwikinger> also true :)
<mvo> pitti: yes please
<pitti> mvo: done (bug #121770)
<ubotu> Launchpad bug 121770 in apt "apt-source should ignore X-Vcs-Browser" [Undecided,New]  https://launchpad.net/bugs/121770
<Hobbsee> pitti: not sure how much RE/RM'ing i'm going to be able to help with this tribe - iv'e got an exam on the 25th (my time)
<Hobbsee> then work is being sucky, and forcing me to go  in there
<mvo> pitti: thanks, confirmed and milestoned so that I get to it early
<pitti> Hobbsee: I can cope with the REing (I plan to attend to release stuff mostly full-time anyway), I'd just appreciate some poking and triaging of the Kubuntu tribe-2 milestone bugs
<Hobbsee> pitti: of course, yes
* pitti hugs Hobbsee and wishes her all the best for her exam
<Hobbsee> heh, thanks
<Hobbsee> it'd help if i studied for it - but i'm hating the subject so much anyway
<Hobbsee> pitti: even that may be delayed.  i'll be online in some form or another, anywy
<tkamppeter> pitti, I have looked into whether printing stuff needs to be merged from Debian and have seen that you have done a CUPS change in Debian. Will you merge this change into Tribe 2?
<pitti> hi tkamppeter 
<pitti> tkamppeter: no, I won't
<pitti> tkamppeter: I still need to find some time to fix it properly
<pitti> tkamppeter: btw, merges.u.c. has one or two packages for you (foo2zjs and so)
<tkamppeter> pitti: So there are third-party backends not working with your non-root mode?
<pitti> tkamppeter: well, you have to chmod 4754 them ATM
<pitti> tkamppeter: my plan is to make the behaviour with backend permissions compatible to upstream again
<tkamppeter> pitti, this means that a process running as root will start them?
<pitti> tkamppeter: right
<tkamppeter> pitti, this would be great, as otherwise many of the distribution-independent driver packages from OpenPrinting will not work with Debian and Ubuntu.
<pitti> yeah, indeed, including cups-pdf
<tkamppeter> pitti, is this the reason why the cups-pdf feature request did not make it into Feisty?
<pitti> tkamppeter: noone doing it mainly
<tkamppeter> pitti, so I will not touch the cupsys package until you have a solution with upstream-compatible backend invocation.
<tkamppeter> pitti, will this mean that you will drop privilege-dropping completely?
<pitti> tkamppeter: no, of course not
<Jessehk> I know I'm probably OT here, but I was wondering what I can do (or who I can talk to) to get the the ocaml package updated to 3.10
<keescook> pitti: can you explain a "fakesync" to me?  (re:121665)  I've been helping calc with merges, and this is a corner-case I haven't run into before.
<pitti> keescook: I thought I explained
<pitti> keescook: take our orig.tar.gz, Debian's diff.gz, add a -build1 changelog with '* Fake sync with Debian (different orig.tar.gz)'
<elmo> step 3: kill a kitten
<keescook> pitti: so match the target sync version in the changelog 0.7.6-3build1, but use our orig.
<keescook> what happens when debian bumps to -4 ?  won't it collide again?
<pitti> keescook: yes, we need to wait until Debian gets a new orig.tar.gz, then it'll autosync
<pygi> hi
<desrt> http://72.14.253.104/search?q=cache:D1ZIAHrGuGIJ:www.windowsmarketplace.com/details.aspx%3Fitemid%3D3411347+ubuntu+windowsmarketplace&hl=en&ct=clnk&cd=1&gl=us
<desrt> <censored>
<desrt> but google remembers :)
<calc> Riddell: are you here?
<Riddell> hi calc 
<calc> Riddell: i'm looking at merging arts if that is ok
<Riddell> it needs merging?
<Riddell> "Updated Merges" not too important
<Riddell> calc: is there something you need it for?
<Riddell> (can't really imagine anyone needing arts :)
<calc> oh ok
<calc> just trying to find work to do for my app ;)
<Riddell> of course if you do merge it, I'm all for that, but updated merges aren't the priority (they've already been merged once this cycle and we'd be forever merging things if we did them all)
<Riddell> I note dholbach has a package still on http://merges.ubuntu.com/main-manual.html
<Riddell> I suspect it just needs a sync
<Riddell> calc: looks like we're an upstream version behind on digikam, so that would be good to have merged
<Riddell> enrico: libept fails to build on sparc, any idea what a Bus Error is? https://launchpad.net/ubuntu/+source/libept/0.5.7/+build/351283
<agoliveira> cjwatson_: ping
<agoliveira> cjwatson_: !ping. Sorry :)
<evand> agoliveira: he's at Debconf
<Adri2000> Mithrandir: can you please give-back gpac on ia64? (that should work now that xulrunner builds correctly on this arch)
<geser> Adri2000: afaik he's still at debconf
<geser> he'll be back on monday
<pygi> Adri2000, afaik pitti can do the same?
<calc> Riddell: ok
<Adri2000> pygi: I don't think pitti is a buildd admin (archive admin != buildd admin)
<Adri2000> geser: ok
<geser> Adri2000: pitti and doko are build-admins now too (they are listed at https://launchpad.net/~launchpad-buildd-admins)
<pygi> Adri2000, what did I tell ya! :P
<Adri2000> oh, ok :) but unfortunatly none of them is here at the moment
<Adri2000> probably at debconf as well ? :)
<mc44> Adri2000: more the fact its a friday night I expect :)
<Adri2000> eh, right too :p
<calc> Riddell: once i get the merge ready can i have you upload it for me?
<Riddell> calc: sure
<_paco_>  okaratas, okaratas  u are the lamest of all
<_paco_> u can't even code "hello world" in visual basic
<calc> Riddell: there appears at least so far to only be one difference between ubuntu and debian versions
<calc> oops hold on a sec
<calc> yea just the gphoto depends in the debian one not in ubuntu
<calc> i guess that is enough of an issue to keep it forked for now
<calc> whatever kubuntu does to not need the la files probably needed porting to debian
<Riddell> calc: yes, we've been wonding why that is and havn't worked it out
<Riddell> although even if we don't need the .la files no reason to exclude them
<calc> Riddell: oh maybe i didn't explain fully enough
<calc> debian has a depends on the -dev package because it needs the .la files
<calc> ubuntu doesn't because it can get by without them
<calc> that is the only difference left in the digikam
<Riddell> ok, doesn't sound like we need to keep that
<Riddell> but if gphoto is different you can just change that, merge in changelogs and done
<calc> ok i think i have it done now
<calc> i'll file a bug with the debdiff etc, helps to track which things i have merged
<calc> bug 121807
<ubotu> Launchpad bug 121807 in digikam "Please merge digikam (2:0.9.2~beta3-1) from Debian" [Undecided,New]  https://launchpad.net/bugs/121807
<Lucifer_stunn> i stole from you.  deinfected my system with your MS propaganda.  and am now running Debian. :D
<calc> Riddell: bug 121807 (if you haven't seen it already)
<ubotu> Launchpad bug 121807 in digikam "Please merge digikam (2:0.9.2~beta3-1) from Debian" [Undecided,New]  https://launchpad.net/bugs/121807
<Riddell> looking
<Riddell> calc: looks perfect, uploading
<calc> thanks! :)
<enrico> Riddell: I have an idea what a bus error is, let
<enrico> s see if I also can figure out why it happens
<calc> enrico: bus errors? on a sparc?
<enrico> Riddell: that one's weird
<enrico> calc: from the buildd log, yes
<enrico> normally bus errors are like unaligned memory accesses
<calc> enrico: ok, yea i've seen bus errors in the past but only ever on sparc
<enrico> no idea if that applies to sparc, though
<bdmurray> bryce: does the dmidecode task for bug 40659 mean anything to you?
<ubotu> Launchpad bug 40659 in dmidecode "[ia64]  Can't get past "Configuring xserver-xorg"" [Medium,Confirmed]  https://launchpad.net/bugs/40659
<bryce> looking
#ubuntu-devel 2007-06-23
<bryce> hmm, he says he has an ia64 box
<bryce> perhaps dmidecode is buggy on that architecture?
<bryce> hmm, however this says dmidecode should work on ia64:  http://www.nongnu.org/dmidecode/
<bryce> brian, if you'd like, you could forward the bug upstream here:  http://savannah.nongnu.org/projects/dmidecode/
* Nafallo ponders if it's a feature or a bug that he can remove compiz?
<LaserJock> I sure hope a feature
<Nafallo> me too :-)
<brylie> how do I 'create a release' on a launchpad project I started? I have a .py file to upload. I'm having trouble getting a response in #launchpad.
<LaserJock> brylie: if #launchpad is slow you might try emailing the launchpad-users mailing list
<brylie> no, I'm slow
<brylie> I'm just new to launchpad
<brylie> Just need to register a series is what I was informed.
<wasabi> Um. The new /proc/sys/net/ipv4/conf/$ifname/ stuff.
<wasabi> Do we have any proper way to set that for interfaces? Since they appear and come from hotswap.
<wasabi> sysctl -p running during boot isn't going to catch them.
<geser> doesn't default or all cover them?
<geser> doesn't default or all cover them?
<superm1> Hi everyone, any archive admins about right now?
<Mithrandir> superm1: maybe. :-P
<superm1> Hi Mithrandir :).  I just wanted to poke about libhdhomerun.  It's been sitting in NEW since 06-01, and there have been several NEW source packages uploaded and approved after it.  Were there complications with it?
<Mithrandir> unsure; probably not
<Mithrandir> I've been on vacation for the last two weeks so I'm hardly on top of stuff
<superm1> ah
<geser> how is/was debconf?
<Mithrandir> good
<Mithrandir> still good
<superm1> Mithrandir, would you have a few moments to ack/look at that source package to get it moving along the path?
<Mithrandir> superm1: not now; it's half past one in the morning and my brain is knackered, sorry.
<Mithrandir> ask me on monday?
<superm1> Mithrandir, sure.  What time are you on then, UTC?
<Mithrandir> UTC+2
<superm1> Ok. i'll get you at some point in the middle of the day Monday then.  have a good weekend :)
<SlimG2> Anyone know what font is beeing used for the "ubuntu" string top-left at http://ubuntu.com ?
<Fujitsu> SlimG2: https://wiki.ubuntu.com/UbuntuTitle
<SlimG2> Fujitsu: Is that the same as the one in the ttf-ubuntu-title package?
<Fujitsu> SlimG2: It is.
<SlimG2> Fujitsu: thanks alot for your help!
<Fujitsu> SlimG2: No problem.
<Hobbsee> morning all
<calc> Hobbsee: good morning
<Hobbsee> :)
<LaserJock> hola Ms. Hobbs
<nixternal> hey, quit using my hola!
<Hobbsee> LaserJock: :)
<Hobbsee> !nixternal | nixternal 
<ubotu> nixternal: Oh no!  The pointy-clicky Vista lover has arrived!  He's rumoured to be giving out free money, too!
<nixternal> free money!!!
<LaserJock> nixternal: dude, I'm in NEVADA, I get hola ;-)
<LaserJock> nixternal: you get sup, or some mob greeting
<nixternal> hahaha
<nixternal> wassa matta
<ScottK> Good morning Hobbsee.
<Hobbsee> morning ScottK 
<ScottK> MIR for pinentry-qt is filed...
<Hobbsee> woo!
<ScottK> Hobbsee: I'm still trying to figure a non-insane way to modify gpg.conf for kmail users to use-agent....
<Hobbsee> ScottK: good luck with that
* ScottK was hoping for a differnt class of response to that ...
<ScottK> :-(
<Hobbsee> hehe
* Hobbsee has been fighting her scanner.   
<sbalneav> The update that went in a few days ago to nbd-server has completely and utterly broken it.  It now no longer can be started from inetd.
<ajmitch> sbalneav: bug filed?
<sbalneav> ajmitch: gonna file one.
<sbalneav> Far as I can see, the entire section that does inetd starting's been #if 0'd out.
<sbalneav> oh, pain.
<Lucifer_stunn> hi u r not mad r u?
<Lucifer_stunn> i cnvtd from ubuntu to debian cuz the nekkid ppl mantra p|$$ed me oFF
<Lucifer_stunn> but uzed ur ubuntu installer-n-repos todoso
<Lucifer_stunn> i just don't like all the M$/C#/Java bologna if that's ok...nvidia.ko is ok imho...
<Lucifer_stunn> cuz they are american...
<tarzeau> Lucifer_stunn: converted? using www.linuks.mine.nu/ubuntu/uncurse or manual reinstallation or debootstrapping?
<Lucifer_stunn> huh?
<Lucifer_stunn> pls dun ban me
<tarzeau> i was just curious about your conversion (i've got debian too :)
<tarzeau> as long as you don't be off-topic here, nobody's gonna ban you
<Lucifer_stunn> ubuntu is great, dun git me rung, but i can't take the nekkit ppk and allof the proprietary softwares u support
<tarzeau> (i guess) 
<tarzeau> Lucifer_stunn: it's nice you want completely free software. but some nvidia cards can't be run with the nv driver only
<Lucifer_stunn> all of the java/c#/ms support i dun agree wit.
<tarzeau> Lucifer_stunn: nobody forces you to use it?
<Lucifer_stunn> ur repos r good for newbie but been using linux since rh4.2 so...
<Lucifer_stunn> i juz dun like all the nekkid ppl advertisment and not being NYSE compliant.
<Lucifer_stunn> in ur trading.
<tonyyarusso> Canonical isn't a publicly traded company.
<Burgundavia> Lucifer_stunn: this channel is for discussion of Ubuntu development only
<Lucifer_stunn>  i have no authoriti w/Canonical but used to invest in redhat and frustrated can't invest in Canonical Inc so my repos switched to Debian cuz meh family can't invest in Canonical so sry
<Lucifer_stunn> we are Roman Catholic investors from German Republic and we do not support 'private firms' sry
<ion_> Sounds more like Troll Republic. :-)
<Lucifer_stunn> ok.  bye.
<ajmitch> took long enough
<Amaranth> hahahahahaha
<Amaranth> I can buy stock in Debian?
<ion_> Yeah, i can give you my account number.
<superm1> Amaranth, actually there is this new process.  You give us your account number, name, first dog, mom's maiden name, US SS # and we'll buy the stock for you :)
<Amaranth> superm1: awesome, i'm in!
<tonyyarusso> BenC: Question for you, general topic is whether Keyspan Serial-USB converter driver modules (in vanilla kernel, not allowed in Debian due to licensing somehow) might be includable in linux-restricted.  I'll be around after 01:00 UTC I expect tomorrow.
<Mithrandir> doko: have you uploaded a gcc with lpia support yet?
<doko> Mithrandir: not yet
<doko> Mithrandir: are the optimization settings finalized?
<Mithrandir> TBH, I care less about that than being able to start bootstrapping
<Mithrandir> you have a set of optimisation flags, don't you?
<Kmos> doko: update dbus-python from debian unstable
<doko> Mithrandir: yes, let me resend my email today, and make the upload on Monday
<Mithrandir> thanks
<Kmos> broadcom has some package specific ?
<Kmos> or just kernel
<pygi> hya Hobbsee 
* Hobbsee waves
<Hobbsee> :)
<pygi> ^_^
<pygi> Hobbsee, I think we can clear some k3b bugs by replacing wodim by cdrskin, but not sure if you'd be happy with that by default?
<Hobbsee> pygi: cool.   no idea.  
<pygi> Hobbsee, and yes, yes, I know you're not in charge of that, but still :P I can bug you :)
<Hobbsee> pygi: apperas to be in universe
<pygi> Hobbsee, uh, uh, yes
<pygi> for now :p
<Hobbsee> yeah
<Hobbsee> pygi: without knowing the codebase, i cant say definetly - but in the general case, it's smart to use the best piece of software for the job.
<pygi> Hobbsee, I know entire codebase :)
<pygi> I'd rather hack-in optional support/search for cdrskin in k3b
<pygi> it could be done with a pretty simple patch IMHO
<Hobbsee> pygi: seaLne's still at debconf
<Hobbsee> pygi: right.
<Hobbsee> pygi: i'd run it past him - but the idea sounds sane, at least in theory
<pygi> Hobbsee, perhaps it's better to hack in optional support for now. We can't pull cdrskin in main just yet
<pygi> (I don't want to do it just yet)
<Hobbsee> pygi: why?
<pygi> Hobbsee, because cdrskin is fine for almost all common operations and even better with dvd burning then wodim (much better!) but it may fail (i.e. not supported) on some exotic burn operations
<Hobbsee> pygi: ahh
<TheMuso> Wouldn't dvd+rw-tools be better for DVD?
<pygi> TheMuso, dvd+rw tools are used for DVD afaik
<pygi> just stating the situation ^_^
<TheMuso> I know that.
<TheMuso> But isn' tthe idea to use the best tool for the job?
<TheMuso> Sorry, am not really following.
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<TheMuso> Just saw DVD mentioned
* mode/#ubuntu-devel [+b *!*@cpepool1-81.bayoucable.com]  by Hobbsee
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [-b *!*@cpepool1-81.bayoucable.com]  by Hobbsee
<pygi> mhmh
* mode/#ubuntu-devel [+b *!*@cpepool1-81.bayoucable.com!#ubuntu-ops]  by Hobbsee
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<pygi> weird
<pygi> :P
<Hobbsee> there.
<pygi> mhm, we still have breezy bugs open for k3b
* pygi goes to close some bugs
<pygi> Hobbsee, you've got some time?
<pygi> Help me close bugs :)
<Hobbsee> oh neat.  thye can be rejected
<Hobbsee> er, i have time somehwat, yes.
<pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/k3b/
<pygi> Hobbsee, I take those bugs in color, you take those without color
<pygi> ok? :)
<mr_pouit> Hobbsee: are you working on ubuntu-restricted-extras, or can I upload a new version to add xubuntu binaries?
<pygi> ask for information, close, reject, prioritize :)
<Hobbsee> mr_pouit: go ahead and add to it
<mr_pouit> ok, thanks
* Hobbsee is munching dinner.
<pygi> Hobbsee, you ok with that? ^_^
<Hobbsee> pygi: i'm Ok with you doing it, certainly
<Hobbsee> but i do want to eat my dinner while ti's still hot
<pygi> Hobbsee, :P
<pygi> k, bon appetit
<geser> the auto-syncing is stopped, right?
<Hobbsee> bug_close++
<Hobbsee> geser: unsure
<pygi> Hobbsee, right, a lot of outdated bugs
<pygi> going through them now
<pygi> (my part ^_^)
<Hobbsee> cool
<TheMuso> According to GutsyReleaseSchedule it is off yes
<Mithrandir> geser: it's no longer run, yes.  It's not autosync, it's a byhand job
<geser> Mithrandir: perhaps I was a bit imprecise: what I meant is that that packages were regularly synced from Debian.
<Hobbsee> Mithrandir!
<geser> and now I've to file sync requests to get a package synced again
<pygi> Hobbsee, nice, we'll get rid of a lot of bugs
<Mithrandir> Hobbsee!
<Hobbsee> pygi: cool :)
* Mithrandir ponders food
<pygi> Hobbsee, if I don't get responses to info requests in two weeks, I'll close most of the bugs
<pygi> they are like 1 year old
<Hobbsee> cool
* Hobbsee eats Mithrandir 
<geser> Hobbsee: will you be then archive-admin and buildd-admin?
<Hobbsee> geser: i wish.
<Hobbsee> but alas, no.
<Hobbsee> pygi: yay, 5 gone.
<pygi> Hobbsee, yup, and closing more
<Hobbsee> :D
<geser> Hobbsee: then please don't it him, we need him :)
<Hobbsee> awww
<pygi> geser, she took that from me!
<pygi> she can't eat people around!
<Hobbsee> no fun.
<pygi> Hobbsee, some fixes are trivial, after I get responses, I'll have a couple of patches to create
<Hobbsee> pygi: cool
<Hobbsee> very cool
<pygi> ha, yellow bugs almost down =)
<Hobbsee> :)
<Hobbsee> anyway, i'm done.  grey is a colour.
<pygi> Hobbsee, k, thanks
<Hobbsee> https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/118274 is closable, imo
<ubotu> Launchpad bug 118274 in k3b "libk3b2-mp3 package not well described" [Undecided,New]  
<Hobbsee> seeing as kubuntu-restricted-extras exist
<pygi> Hobbsee, mark as "wishlist" pls: https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/58767
<ubotu> Launchpad bug 58767 in k3b "k3b: On verify of CD burn, do not open "What do you want to do?" dialog" [Medium,New]  
<pygi> Hobbsee, bug 118274 can be resolved as invalid (that one is yours)
<ubotu> Launchpad bug 118274 in k3b "libk3b2-mp3 package not well described" [Undecided,New]  https://launchpad.net/bugs/118274
<Hobbsee> pygi: done x2
<pygi> Hobbsee, thanks
<Hobbsee> no problem
<Hobbsee> i thought you had -qa now
<pygi> Hobbsee, I had it!
<pygi> then I revoked my rights, and now ...
<pygi> oh well :P
<pygi> (but that was like year and a half ago :P)
<Hobbsee> why'd you revoke your rights?
<pygi> because I even revoked my ubuntu-member status?
<Hobbsee> ahh
<Hobbsee> carzy person
<pygi> thank you, thank you :)
<pygi> Hobbsee, If you have any doubts, do poke ^_^
<Hobbsee> pygi: doubts about what?
* Hobbsee has lost context here
<pygi> Hobbsee, no idea. about how bug should be resolved
<pygi> or something :P
<pygi> yay, yellow and orange bugs are down
<pygi> time for the blue ones
<pygi> hm, that's a wishlist
<pygi> I'll start the grey ones as well then
<pygi> Hobbsee, did you start from bottom or from up?
<pygi> top*
<Hobbsee> pygi: i picked the likely-packaging-error bugs
<pygi> Hobbsee, oh, k, I'll just go around and look
<pygi> k, LP is slow!
<Hobbsee> haha
<Hobbsee> define "slow"
<pygi> very slow!
<pygi> I can't post a comment
<sladen> it could be b0rken
<Hobbsee> again
<Hobbsee> sladen: how's the roaming life?
<pygi> Hobbsee, we'll get entire k3b sorted today! :P
<pygi> and a lot of mails yay :-D
<sladen> Hobbsee: need to hop on a Eurostar in 4hours to do London->Brussels->Hamburg->Copenhagen->Stockholm->Helsinki for work on Monday morning :)
<Hobbsee> sladen: erk!  good luck with that!
<Hobbsee> it must be cool, to be able to, though
<Hobbsee> hiya PriceChild 
<pygi> somebody explain me this bug pls: https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/115615
<ubotu> Launchpad bug 115615 in k3b "probleme avec lancement de k3b sous gnome" [Undecided,New]  
<pygi> (and yes, I can read what it says)
<pygi> hey PriceChild 
<PriceChild> :)
<PriceChild> hey pygi 
<stgraber> pygi: want a translator ? :)
<pygi> stgraber, I do understand what it says, but meh, it's weird
<pygi> stgraber, but if you can do it better then me, why not ^_^
<stgraber> indeed
<pygi> stgraber, just reject? xD
<stgraber> Is k3b supposed to be run from root ?
<pygi> stgraber, afaik no
<pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/114224 --> wishlist pls
<ubotu> Launchpad bug 114224 in k3b "Burn additional CDs with k3b" [Undecided,New]  
<stgraber> in this bug report it's
<Hobbsee> stgraber: it gives you a warning either way
<ion_> /usr/bin/iceauth: creating new authority file /root/.ICEauthority Is he running k3b as root?
<stgraber> ion_: I think so
<pygi> ion_, seems like
<ion_> Ah, im being blind again.
<ion_> It was already mentioned. :-)
<pygi> Hobbsee, do tell when you marked it as a wishlist
<Hobbsee> pygi: done
<pygi> Hobbsee, thanks
<pygi> Hobbsee, sorry for bugging too much, but meh
<pygi> it's for a good cause :0
<pygi> :)
<Hobbsee> pygi: it's fine :)
<stgraber> pygi: I think you can reject it as : the user should report in english not french and k3b isn't supposed to be run from root
<pygi> stgraber, I once responded in spanish to a user :P
<stgraber> pygi: :)
<pygi> stgraber, do go ahead, and do so
<pygi> I won't eat you, you know :p
<stgraber> k :)
<pygi> Hobbsee, this one if your field: packaging stuff - https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/112342
<ubotu> Launchpad bug 112342 in k3b "Error ripping audio cd to mp3" [Undecided,New]  
<pygi> so I'm skipping it
<pygi> it's also a licence problem, so mind explaining it to him? :)
<pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/109968 --> set as wishlist
<ubotu> Launchpad bug 109968 in k3b "K3b shows an inexact information if MP3 plugin not installed" [Undecided,Confirmed]  
<Hobbsee> pygi: when you're coding, can you change the suggests libk3b2-mp3 to kubuntu-restricted-extras ?
<stgraber> pygi: -> invalid and left a comment in both french/english (in case he doesn't understand any single english word :))
<pygi> Hobbsee, you mean change package dependencies? Sure
<Hobbsee> pygi: thanks
<Hobbsee> in fact, that's a wontfix.
<pygi> Hobbsee, right
<Hobbsee> pygi: are you up for coding a thing where k3b realises it needs more codecs, and grabs k-r-e?
<pygi> Hobbsee, I wanted to change a way in what it reports. Just wanted to make it show that you need "a, b, and c packages"
<pygi> or just that one actually
<pygi> k-r-e
<Hobbsee> pygi: you can just use a "enable multiverse, adn install k-r-e"
<pygi> Hobbsee, yup, that might work
<Hobbsee> like the common customisation specs
<pygi> Hobbsee, so assign to me if you want
<Hobbsee> pygi: do you want a separate bug on it?
<pygi> Hobbsee, if you prefer
<Hobbsee> pygi: as that one's listed as wontfix now
<Hobbsee> makes no difference to me
<pygi> Hobbsee, I'll talk with mvo. Perhaps we can make it auto-pull k-r-e if needed
<pygi> Hobbsee, just open a new one then
<Hobbsee> ok
<pygi> but ergh, we can't auto-enable multiverse
<pygi> that's evil
<pygi> oh well, a note will do :P
<pygi> bug 109095 should go wishlist
<ubotu> Launchpad bug 109095 in k3b "k3b should fork on verify" [Undecided,Confirmed]  https://launchpad.net/bugs/109095
<pygi> meh, so many bugs triaged today
<Hobbsee> :)
<Hobbsee> pygi: i thought you could
<Hobbsee> pygi: besides, you can say "do you want to?"
<Hobbsee> actually, i think we do enable universe now
<Hobbsee> and maybe multiverse too
<pygi> Hobbsee, universe we do. But don't think we enable multiverse
<Hobbsee> ah
<pygi> I hate apport, so bug #104195 is yours :)
<ubotu> Launchpad bug 104195 in k3b "[apport]  k3b crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/104195
<Hobbsee> pygi: https://bugs.launchpad.net/ubuntu/gutsy/+source/k3b/+bug/121877
<ubotu> Launchpad bug 121877 in k3b "K3b doesnt prompt the user to install kubuntu-restricted-extras for codecs" [High,Triaged]  
<Hobbsee> pygi: i've NFI what to do with apport bugs
<pygi> Hobbsee, hahah, then we'll skip :) Thanks for 121877, I'll look at it
<Hobbsee> pygi: that BT looks useless
<pygi> as always :p
<Hobbsee> i'm not sure that apport actually works with kde stuff
<pygi> mhmh, but I can never get anything out of apport bugs :(
<Hobbsee> neither
<Hobbsee> but i can see by the lack of info, that it's useless
<Hobbsee> right, marked as invalid
<pygi> I've got two on brasero, and can't draw anything usefull from them :)
<pygi> Hobbsee, great =)
<Hobbsee> pygi: tentatively milestoned that k-r-e bug as tribe 3.
<pygi> Hobbsee, haha, when is tribe 3?
<Hobbsee> https://wiki.ubuntu.com/GutsyReleaseSchedule
<Hobbsee> 19 july
<pygi> it'll work, sure
<Hobbsee> :)
<pygi> but that's evil ... without even asking :P
<pygi> Hobbsee, can we get 1.0.1 in feisty-updates?
<pygi> I'd need that as we'd fix a lot of bugs
<Hobbsee> pygi: backports, likely.  not updates
<pygi> Hobbsee, kk, then jdong it is ^_^
<pygi> Hobbsee, lol, look : https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/99973
<pygi> :p
<ubotu> Launchpad bug 99973 in k3b "spelling error "savely"" [Undecided,New]  
<pygi> shall I fix that with newest upload? :P
<Hobbsee> pygi: i saw that.  heh.  yes, and file it upstream, i guess
<pygi> (if it isn't fixed in 1.0.1 ? :P)
<pygi> Hobbsee, k, I mark to myself, you file upstream and add upstream bug tracker
<Hobbsee> k
<Riddell> Hobbsee: c++ kde apps already have a crash handler
<Riddell> djdyjchmkfd
<Riddell> cghxmkrsekmcbbm 
<Riddell>  gcsdkrwe  n#
<pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/104799 --> add upstream bug watcher (I have no idea how :P)
<ubotu> Launchpad bug 104799 in k3b "k3b copies DVD+RW to itself without any questions" [Undecided,Confirmed]  
<pygi> there's a upstream bug mentioned in the report
<pygi> Riddell, see? You'll have a nice k3b for gutsy ^_^
<pygi> Hobbsee, yay, we're almost done
<Hobbsee> pygi: launchpad confuses me there.  i've no idea WTF series release means
<pygi> Hobbsee, :P
<pygi> Hobbsee, probably 0.6.x and such stuff
<Hobbsee> it seems to cope with kdemultimedia/main
<pygi> Hobbsee, please milestone bug 69684 for me
<ubotu> Launchpad bug 69684 in k3b "gnome-app-install does not install i18n packages" [Undecided,Confirmed]  https://launchpad.net/bugs/69684
<Hobbsee> i'm assuming one has to add the k3b project in and whatnot
<Hobbsee> pygi: to what tribe/
<pygi> Hobbsee, tribe 3
<Hobbsee> consider it done
<pygi> thanks
<Hobbsee> pygi: installing all the translations by default will suck though
<Hobbsee> suggests may be more appropriate
<Hobbsee> Riddell: right
<pygi> Hobbsee, it is already suggests
<Hobbsee> Riddell: and wake up
<pygi> but that's kind of bad because other users feel left-out
<Hobbsee> pygi: installing every translation for k3b, for everyone...isnt...fun.
<pygi> Hobbsee, what about splitting translations?
<Hobbsee> no idea.  i dont do translation stuff
<pygi> Hobbsee, mhmh ... what to do then?
<pygi> just leave as is?
<pygi> and mark bug as invalid?
<Hobbsee> ask relevant people their opinions
<pygi> Hobbsee, ok, will do. remove the tribe for now then. also look at https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/83155, and test that
<ubotu> Launchpad bug 83155 in k3b "cd automount stops working after k3b" [Undecided,New]  
<pygi> confirm if you can
<pygi> Hobbsee, pitti might be the one to ask
<Hobbsee> pygi: i can always decline the tribe later.
<pygi> Hobbsee, kk
<Hobbsee> pygi: it's probably safer to leave it - as then i can poke you later, if you havent alreayd found out
<pygi> Hobbsee, understood ^^_
<Hobbsee> pygi: all the kde bugs that are milestoned default to me for poking
<pygi> ^_^
<pygi> as long as we fix stuff I'm happy
<Hobbsee> :)
<pygi> Hobbsee, do look at that 83155 bug pls
<pygi> I think we got one duplicate even, so ...
<Hobbsee> pygi: have no DVD to burn.  looks strange, though
<pygi> if you can confirm this one, do find the another one and confirm it as well :P
<pygi> I can borrow you some? I have like 250 pieces around :p
<Hobbsee> heh
<pygi> Hobbsee, I'll put myself as bug contact for k3b
<pygi> that subscribtion or whatever 
<Hobbsee> pygi: if you've got a list of bugs that you'd like to see tested, i can poke relevant mailing lists and such about testing them
<pygi> (ignore the spelling :P)
<Hobbsee> pygi: yep, right, cool
<pygi> Hobbsee, sure I've got a list :) You can get it this week
<Hobbsee> :)
<Hobbsee> send it to me, would be cool :)
<pygi> (or a bit later, 4 exams this week :P)
<pygi> Hobbsee, will do, thanks :)
<Hobbsee> yeah, exams are nasty.  i willd rop off the planet in a couple of days, for a bit
<pygi> hehe :)
<pygi> Hobbsee, did you file that typo stuff upstream?
<Hobbsee> pygi: was already fixed upstream
<pygi> Hobbsee, oh, in 1.0.1?
<pygi> Hobbsee, then could you close the bug pls? 
<pygi> I'm almost done with everything
<Hobbsee> pygi: already done so
<pygi> thanks
<pygi> Hobbsee, remind me that in two weeks we'll close 80% of those bugs
<Hobbsee> pygi: woo :)
<pygi> we must close*
<Hobbsee> pygi: sounds very good to me
<pygi> https://bugs.launchpad.net/ubuntu/+source/k3b/
<pygi> only handful of "new" bugs which I have no idea right now what do to with
<pygi> a lot of bugs can be fixed, or auto-closed soon
<pygi> Hobbsee, thanks for your help ;)
<Hobbsee> pygi: marked a couple as fixed,or incomplete
<Hobbsee> pygi: no problem - tahnsk for yours :)
<pygi> Hobbsee, k, great ^^
<pygi> Hobbsee, do you have any more packages we need cleaned up for tribe3?
<Hobbsee> pygi: anything in kde, really...
<Hobbsee> pygi: so much of it needs to be filed upstream, etc.
<pygi> Hobbsee, see, this I hate: https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/105425
<ubotu> Launchpad bug 105425 in brasero "[apport]  brasero crashed with SIGSEGV in g_str_hash()" [Undecided,Confirmed]  
<pygi> apport again :P
<Hobbsee> pygi: actually, anything with bugs in it
<Hobbsee> haha
<pygi> and how am I supposed to fix that xD
<Hobbsee> pygi: you're not.  it's reported upstream, and linked, so you wait
<Hobbsee> pygi: https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/91181 looks like the person not in the correct group - whatever that is
<ubotu> Launchpad bug 91181 in k3b "k3b wrong permissions" [Undecided,New]  
<pygi> you mean upstream is supposed to learn apport language?
<pygi> Hobbsee, I'll look now
<pygi> Hobbsee, k, commented, thanks :)
<Hobbsee> pygi: the backtrace?  yes.
<Hobbsee> pygi: apport, from what i understand, is only "collect the backtrace, adn retrace it in the data center"
<Hobbsee> (and attach that)
<pygi> perhaps, but it's still mmhm ..
<pygi> confusing :p
<Hobbsee> hehe
<pygi> amarok has a number of critical bugs :-/
<Hobbsee> backtraces are
<Hobbsee> true that.  upstream knows about them
<Hobbsee> they helped go thru them
<pygi> yup, I know upstream knows
<pygi> just read a handful of them
<Hobbsee> and are now getting bugmail, etc, as we run vanilla amarok + the install mp3 script
<pygi> got it
<Hobbsee> of course, they probably do want help upstream.  *shrugs*
<pygi> but the install mp3 script is still buggy :P
<pygi> bug #58167
<ubotu> Launchpad bug 58167 in ubiquity "Installer crashed at around 83% of the installation status inspector (dup-of: 47687)" [Undecided,New]  https://launchpad.net/bugs/58167
<ubotu> Launchpad bug 47687 in ubiquity "crash installing in Chinese with non-Chinese country" [Medium,Fix released]  https://launchpad.net/bugs/47687
<pygi> ups
<pygi> bug 58617
<ubotu> Launchpad bug 58617 in amarok "mp3 installation script crashes and/or hangs" [High,Confirmed]  https://launchpad.net/bugs/58617
<pygi> wrong order of numbers
<pygi> if I knew more about amarok codebase, we'd sort out that today as wel
<pygi> well*
<Hobbsee> pygi: now if you want to fix that....i think someone in #kubuntu-devel was looking, but i never heard the result
<Hobbsee> i'm tempted to get it rewritten in python, so more people are willing to touch it, and fix it's bugs
<pygi> Hobbsee, what's it written now in?
<Hobbsee> pygi: bash
<pygi> uh, uh
<Hobbsee> yeah
<pygi> Hobbsee, python would make it better
<Hobbsee> pygi: indeed.
<mhb> Hobbsee: what does the script do actually?
<pygi> hm, we can't do this for tribe3, but Hobbsee, if you're up for some pair hacking after that ....
<pygi> let's work on it
<pygi> gobby does magic ^_^
<Hobbsee> mhb: installs libxine-ffmpeg, basically
<Hobbsee> pygi: i dont grok python much, sorry :(
<Hobbsee> as in, i can read some of it, or at least understand what's going on, but i cant write it myself.
<pygi> Hobbsee, well, you'll learn ^_^
<Hobbsee> i really should learn to code - but i find it quite dry, so havent put in the effort to do so.
<pygi> Hobbsee, I helped pete learn, can help you as well ^_^
<Hobbsee> :)
<Hobbsee> that'd be cool
<pygi> and see all the cool stuff he's working on now ^_^
<pygi> aka cbx33 :P
<Hobbsee> :)
<pygi> oh well ^_^
<pygi> be back in like 3 minutes or so, gotta make some lemonade
<pygi> it's very hot
<pygi> hey abattoir_ :P
<Hobbsee> have fun.  freezing here
<Hobbsee> hey abattoir 
<mhb> Hobbsee: does that script run adept_batch?
<Hobbsee> mhb: yeah
<Hobbsee> or synaptic install thing, or apt-get, if neither are installed
<StevenK> If all it's doing is installing libxine-ffmpeg, I don't see why bash is a bad thing.
<pygi> Hobbsee, what's the temperature at your place?
<StevenK> pygi: ~ 11 degrees
<Hobbsee> pygi: probably around 10C
<pygi> k, that's low
<pygi> 36C here
<StevenK> Send it here!
<mhb> Hobbsee: me neither
<StevenK> mhb: You mean me? :-)
<Hobbsee> yes, send it here!
<pygi> Hobbsee, 72 bug mails!!!
<Hobbsee> pygi: haha
<Hobbsee> pygi: minor
<mhb> StevenK: it's not you who wanted to rewrite that in python, so ... no. :o)
<pygi> select all --> mark as read
<abattoir_>  hi pygi, Hobbsee, mhb :)
* Fujitsu notes it's about 4C here.
<mhb> hi abattoir_ 
<Hobbsee> poor Fujitsu 
<Fujitsu> My room is likely a couple of degrees above that, fortunately.
<pygi> lemonade rocks :P
<Hobbsee> :)
<geser> Fujitsu: you need more computers :p
<Fujitsu> geser: Heh, my poor laptop doesn't do much :(
<Fujitsu> The server room at school is nice and toasty though!
<Fujitsu> 6x single Xeon servers, and a dual-Xeon, and an AMD X2, in a small room. Very hot.
<Hobbsee> yummy
<StevenK> No air conditioning?
<Fujitsu> Air-con on when it's 5 degrees outside is a little strange.
<Fujitsu> We convinced the administration we needed it a few months ago, but it took 2.5 years.
<StevenK> Our server room is regulated at 20 degrees with roughly 20 servers.
<Fujitsu> Nice. Ours is this great 60-year-old storeroom which had two powerpoints until 12 months ago.
<StevenK> Two completely seperate air conditioners, one primary, and a second set to kick in if the temperature hits 32
<maswan> Heh. We used to have redundant cooling, but then we started wanting to use four times as much power as the room was designed for. So it isn't redundant anymore. ;)
<StevenK> Heh
<pygi> Hobbsee, closed another bug, thank you, thank you :)
<Hobbsee> pygi: woo!
* StevenK waves to pitti_ 
<Fujitsu> We had no ventilation at all until this air conditioner was installed. It was completely uninhabitable for any appreciable length of time.
<pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/82323
<ubotu> Launchpad bug 82323 in k3b "[KDE 3.5.6]  k3b wants "+-DVDs" ... and rejects "+DVDs" " [Undecided,Fix released]  
<pitti_> hi StevenK 
<Hobbsee> hiya short tailed pitti_ 
<StevenK> pitti_: rss-glx hit DEPWAIT. :-/
<pitti_> hmm
* Fujitsu chops off pitti_'s tail.
<pitti> bah, someone seems to use my nickname
<pygi> pitti, I'll need to talk to you next week about k3b language packs
<pitti> took me three attempts to kill the bad pitti
<Hobbsee> pitti: ghost is your friend
<StevenK> I wish Freenode still enforced Secure.
<maswan> Fujitsu: well, we're building a new machine room now, which will have some new and interesting designs, and it'll handle 25 kW/rack. :)
<Fujitsu> pitti: Set the security thing on so they automatically get killed after 30 seconds.
<pitti> Hobbsee: that's what I did, but the 'other' pitti logged back in too fast
<Hobbsee> StevenK: i so wish.
<Hobbsee> pitti: urgh
<Fujitsu> StevenK: I think they do... I've seen it a couple of times.
<Hobbsee> Fujitsu: freenode disabled it.
<pitti> but only the real pitti has 'pitti' registered, muhahaha
<Hobbsee> Fujitsu: that's not the same as nick collision message - that's manual
<Hobbsee> pitti: *evil grin*
<pitti> StevenK: needs a MIR for freealut
<Fujitsu> How strange. I've seen some nicks get killed after exactly 30 seconds.
<StevenK> pitti: I think it would be openal?
<Hobbsee> Fujitsu: staffers?
<pygi> Hobbsee, woo, a lot of users are reporting back already :)
<Hobbsee> pygi: yay!
<Fujitsu> Hobbsee: I don't believe so.
<pygi> got like 4 feedbacks already
<Hobbsee> Fujitsu: weird
<Hobbsee> pygi: yay!
<Arby> pygi: you'll get another one when I get my gutsy up to date :)
<pygi> Arby, yay! Which one? :)
<Arby> bug 119187
<ubotu> Launchpad bug 119187 in k3b "[Gutsy]  cd burning with k3b fails" [Low,Incomplete]  https://launchpad.net/bugs/119187
<pygi> Arby, k, thanks
<StevenK> pitti: Actually, both freealut and openal need MIRs
<geser> pitti: could you give-back mlterm on all archs != sparc? or should I ask on monday again?
<pitti> geser: that's fine
<Mithrandir> geser: given-back
<geser> thanks
<geser> pitti: do you know if Ubuntu will also do the libcurl3 -> libcurl4 -> libcurl3 transition Debian did?
<pygi> geser, hm, back to libcurl3?
<geser> yes
<StevenK> libcurl in Debian is a *mess*
<pygi> damn
<geser> curl 7.16.2-5 is back to libcurl3{,-gnutls} (see http://packages.qa.debian.org/c/curl/news/20070620T223309Z.html)
<StevenK> geser: I'm ignoring it until they stop fiddling.
<StevenK> pitti: https://wiki.ubuntu.com/MainInclusionReportOpenAL ; that's the first one
<geser> StevenK: I've uploaded some rebuilds for the libcurl3 -> libcurl4 transition only to notice that this transition will be undone again
<geser> I'm wondering now if I've to upload them again for libcurl4 -> libcurl3
<StevenK> geser: Which is exactly why I'm ignoring it.
<geser> the current status of the curl package isn't the best either: libcurl3 but libcurl4-openssl-dev
<pitti> StevenK: weird, anastacia says it wants freealut
<pitti> geser: erk, why should we do that?
<StevenK> pitti: Build logs say libopenal-dev
<StevenK> pitti: But freealut is in there as well
<StevenK> pitti: https://wiki.ubuntu.com/MainInclusionReportFreeAlut as well
* ogra curses nbd upstream
<pitti> StevenK: oh, great
<pitti> geser: erm, mlterm is current on all arches
<StevenK> pitti: Mithrandir handled it
<pitti> geser: why oh why did they have the brilliant idea of rolling back the ABI? at some point they need to do it anyway...
<StevenK> pitti: If it helps openal used to be in main
<pitti> StevenK: hm, we demoted it in dapper
<pitti> StevenK: can you please add those two MIRs to the queue?
<StevenK> pitti: Done.
<StevenK> pitti: Re-generate the cruft pages when you feel so inclined, please.
<pitti> StevenK: archive-cruft-check is broken, sorry
<pitti> StevenK: I'll talk about it with cprov
<StevenK> Okay, cool.
<geser> pitti: the libcurl transition caused to much trouble with the testing transition so they found it easier to fix the abi than coordinate the transition
<lfittl> smurf: you were working on packages for 1wire owfs at some point, are they available somewhere?
<Arby> pygi: bug 119187 seems to be fixed in updated gutsy, shall I close as fix released?
<ubotu> Launchpad bug 119187 in k3b "[Gutsy]  cd burning with k3b fails" [Low,Incomplete]  https://launchpad.net/bugs/119187
<Hobbsee> Arby: yes please
<Arby> and another one gone :)
<Hobbsee> woo!
<pygi> Arby, yea :P
<pygi> sorry, was eating
<pygi> but thanks :)
<Arby> pygi: no problem :)
<pygi> Hobbsee, told ya! :P
<pygi> bdmurray, poke
<pygi> bdmurray, I triaged entire k3b, can I get -qa now pls? :P
<pygi> Hobbsee, yay, a user is asking me did I test it on the specific home theater system he has :p
<Hobbsee> hehe
<Hobbsee> "sure, i broke into your house!"
<pygi> nah, he meant the model
<pygi> but hehe :)
<pygi> Hobbsee, another one done
<Hobbsee> pygi: woo :)
<pygi> Hobbsee, could you see about putting 1.0.1 into feisty-backports?
<Hobbsee> pygi: bug jdong 
<pygi> Hobbsee, but, but ...
<pygi> you should do something :)
<Hobbsee> pygi: i am.  i've just discovered a major critical bug.
<pygi> Hobbsee, which one, which one?
<pygi> jdong, awake pls
<Hobbsee> adept is totally broken
<pygi> ah
<pygi> that happens a lot
<Hobbsee> not like this...
<pygi> what exactly is a problem? Can I help?
<pitti> geser: sorry, my ISP dropped off for a bit; so Debian will permanently keep curl3?
<geser> I've looked now into the libcurl3-gnutls deb: the lib is named libcurl-gnutls.so.4.0.0, there is also a symlink libcurl-gnutls.so.3
<geser> they restored the API, kept the new so-version from upstream but use the old package name again to avoid the transition
<geser> pitti: imho it's a mess now
<geser> Hi sabdfl
<Hobbsee> gahh.....
* Hobbsee kicks launchpad
<sabdfl> howdy
<pygi> Hobbsee, do it for me as well :)
<Hobbsee> hiya sabdfl 
<pitti> hi sabdfl
<geser> Hobbsee: be careful to not break it anymore
<pitti> geser: OMG
<Hobbsee> neat.  because i nominated a bug for a release, i cant actually approve said nomination for some reason.
<Mithrandir> Hobbsee: which bug?
<pitti> geser: so they rather break almost all common practices about libraries than simply doing that transition? that's weird
<Hobbsee> that's almsot as good as the "triaged state is counted as a closed state" bug, which is brilliant for doing milestone stuff.
<Hobbsee> pitti: main freeze was..tuesday, london time?
<pitti> Hobbsee: yes, on an appropriate time (bugs fixed, etc.)
<Hobbsee> pitti: okay, i'm fairly certain that there will be some kubuntu fixes going in later than that, due to exams and such.
<Hobbsee> like, this adept one.
<pitti> Hobbsee: that's fine, just subject to our examination
<Hobbsee> pitti: where our == ?
<pitti> Hobbsee: I'd say, your's for Kubuntu, mine for Ubuntu, ogra's for edubuntu
<Hobbsee> pitti: okay, cool
<Hobbsee> pitti: thought as much - was just checking that it wasnt some other group of people
<pitti> Hobbsee: and, if there are doubts, discussion in #u-r
<Hobbsee> pitti: yeah
* pygi should work on k3b asap then
<Hobbsee> pygi: that's set for tribe 3, not 2 - but that'd be great :)
<pygi> Hobbsee, oh, k, tribe 3 is better :P
<pygi> thanks :P
<Hobbsee> hehe
<geser> Hobbsee: that nomination bug is still isn't fixed? use the workaround: visit that bug via the distrorelease url and click "needs fixing also here"
<Hobbsee> geser: no, that is fixed.
<Hobbsee> geser: there's a propose/decline functoin if you're in ~ubuntu-releas
<Hobbsee> e
<pitti> s/propose/accept/?
<geser> ah
<Hobbsee> er, yes.
<pygi> Hobbsee, is there any kubuntu-related package that needs updating?
<Hobbsee> pygi: there are some that need fixing.
<Hobbsee> pygi: if you're wanting to look into something, https://bugs.launchpad.net/ubuntu/gutsy/+source/kde-guidance/+bug/119408
<ubotu> Launchpad bug 119408 in kde-guidance "[gutsy]  kde-guidance power manager causes screen to turn off" [Undecided,New]  
<pygi> meh, no idea about it's codebase :p
<Hobbsee> yeah, thoguth so
<Hobbsee> do you run kde?
<pygi> I have kubuntu on one machine, yes
<Hobbsee> confirming that bug would be useful.  i cant reproduce it
<pygi> well, that machine isn't here atm, so that would be a problem :)
* pygi looks for some other things
<Hobbsee> ahhh, fair enough
<Hobbsee> pygi: https://bugs.launchpad.net/ubuntu/gutsy/+bugs is what i'm looking off
<pygi> Hobbsee, k, I'll see what I can do on reproducing that guidance bug for you this wekk if it won't be too late
<Hobbsee> pygi: had 2 non-reproduces.  will bug bdmurray about it.
<Hobbsee> dont worry about it
<Hobbsee> ie, i'm suspecting it's something local.   or to do with his machine
<pygi> k, then I'll worry about that k3b stuff
<Hobbsee> cool :)
<pygi> and some others, if I can find something :p
<Hobbsee> hehe
<pygi> Hobbsee, a lot of k3b bugs closed today :)
<Hobbsee> pygi: yep :)
<Hobbsee> pygi: that should show up on bugstats too :)
<pygi> Hobbsee, this release will have lowest amount of cd-recording bugs ever, yay!
<ogra> who pinged ?
<Hobbsee> woo!
* ogra scrolls back
<Hobbsee> ogra: pitti did
<pygi> ogra, nobody, you were just referenced AFAIK :)
<pygi> Hobbsee, too bad we can't do 0 bugs just yet :P
<ogra> ah :)
<ogra> pitti, we have a very scary bug in nbd that might make edubuntu skip tribe2
<pygi> ogra, what's nbd? o.O
<ogra> bug #121827
<ubotu> Launchpad bug 121827 in nbd "nbd-server can no longer be started from inetd" [Undecided,New]  https://launchpad.net/bugs/121827
<pitti> ogra: oh, so hard to fix? well, it's your call anyway
<Hobbsee> "tribe 2 is cancelled due to lack of interest" :P
<ogra> pitti, well, we need to develop half the nbd-server new
* pygi kicks Hobbsee due to lack of interest
<ogra> since upstream didnt care for one work wise at all and only developed the standalone functionallity witout noting it even anywhere
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* pygi was kicked off #ubuntu-devel by Hobbsee (HERE BE MY BOOT OF DOOM!!!!)
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
* Hobbsee grins
<pygi> k, that was abuse of powers :'(
<Hobbsee> awww
<Hobbsee> [02:36]  *** You have kicked pygi from the channel (HERE BE MY BOOT OF DOOM!!!!).
<ogra> so they dropped 50% functionallity out of laziness instead of waiting with the release until they have no regressions anymore ...
<ogra> evil practise
<ScottK> pitti: Riddell said I should ping you about an MIR. Is this a good time? https://wiki.kubuntu.org/MainInclusionReportPinentry
<pygi> :'(
<pitti> ScottK: is it targeted for tribe-2?
<ScottK> pitti: No.
<ScottK> Kmail will depend on it once we get it into main.
<smurf> lfittl: will be soon, I can also mail you the current diff
<lfittl> smurf: would be useful, to lfittl AT ubuntu.com, thanks
<sbalneav> Can someone help me with a policy issue?  for ltsp-server, we rely on nbd-server being able to be started from inetd.  Upstrem's completely removed this from the code because they "think no-one's using it".  I'd be willing to hack together a standalone nbd-server-inetd package, and become upstream for it...
<Mithrandir> why not rather tell them you're using it and would like it back?
<Nafallo> sbalneav: have you talked to upstream about it?
<sbalneav> So far, unanswered
<sbalneav> but in other threads, others have broought it up, and they seem... reticent to bring it back.
<sbalneav> So, our options seem to be 1) backpedal to a previous version, 2) maintain a patchset, or 3) roll our own server.
<sbalneav> which would be "preferable", if wheedling with upstream fails?
* pygi votes for 3
<Mithrandir> why do you need to have it started from inetd rather than running all the time?
<sbalneav> for swapping.  When we attach, we need to create the swapfile in /tmp, attach the nbd-server, and when it exits, clean up the swapfile.
<sbalneav> this is handled with a wrapper script, which gets launched from inetd.
<sbalneav> Plus, imho, upstream's added a huge amount of security fluff (don't allow connects from listed ip's, launch as a certain user, etc etc) which is easily handled by existing inetd/tcpd.
<sbalneav> Mithrandir: I've emailed again, I'll create a patchset, and hopefully, they'll be willing to take it upstream.
<davmor2> Hi devs:  I have downloaded today iso and ubiquity is crashing out.  What info do you need
<ScottK> davmor2: First try in #ubuntu for help to see if you can get the problem figured out.
<davmor2> ScottK:  this is today's gutsy iso image.
<ScottK> davmor2: Then #ubuntu+1 I would guess.
<davmor2> ScottK:  will they be able to fix the problem there then?
<pochu> davmor2: you can attach the crash under /var/crash/ to a bug report.
<ScottK> davmor2: That is the help channel for Gutsy.  Start there and if they can't sort it out, file a bug.  This is a channel for development, not for help.
<pochu> davmor2: Also the output running ubiquityunder a terminal.
<davmor2> pochu: ta
<davmor2> pochu:  It's firing up a memory warning but the memory is fine?
<davmor2> will post a bug now that I have lowered it down a bit
<pochu> davmor2: ignore that memory warning ;)
<davmor2> pochu: but that's what is crashing it out :( 
<pochu> davmor2: isn't there a backtrace?
<pochu> davmor2: I doubt that warning is related, since it talks about Glib functions, and ubiquity is written in python...
<evand> davmor2: there's currently a bug in Ubiquity that SIGSEVs.  It doesn't produce a report, afaik, nor does it dump anything helpful in the logs.  I'm looking into it.  I'm not sure if it's the bug you describe, though.
* evand runs out
#ubuntu-devel 2007-06-24
<ikesire> is it true that gutsy won't include ntfs-3g?
<ikesire> (by default)
<calc> crimsun: you here?
<calc> crimsun: got some alsa devel questions for you
<calc> crimsun: eg what is NID in reference to patch_realtek.c
* calc is trying to figure out how this stuff works so he try to fix the ALC268 support
* calc has never written an audio driver though
<jdahlin> Why isn't a package's source code included in the -dbg deb?
<calc> jdahlin: why would it be?
<calc> jdahlin: you can easily get the source via apt-get source
<jdahlin> calc, for tools such as gdb where the source code is useful
<jdahlin> well, the complete source tree is not necessary only the .c files (and perhaps the .h)
<minghua> jdahlin: but as calc said, it's easy to get the source with "apt-get source", .c, .h, everything.
<jdahlin> I know that fedora has .debuginfo packages which provides the libraries/programs compiled with debugging symbols in addition to the source code
<jdahlin> minghua, *I* am not interested in reading the source code, I programs that uses the debugging symbols to be able to read it
<persia> jdahlin: A couple other reasons are 1) archive space, and 2) reduction of redundancy.  The -dbg package is useful for those generating stack traces.  The source is useful for those investigating the issue.  These are not always the same person, and the source must be distributed separately in any case.
<minghua> I don't see the point.  The -dbg package should give you the function name and the filename and line number
<jdahlin> persia, -dbg doesn't seem to be something the normal user installs, I can't quite why the source shouldn't be shipped together, it makes it easier for developers to use tools which depends on them (gdb, valgrind for instance)
<minghua> that's all you need to identify the problem in the source, if you want to
<jdahlin> minghua, right, but you're still missing the point. I do not want to track this down manually, I'd like tools to be able to use the references
<minghua> jdahlin: it also duplicate the source several times (once for each architecture) and consume a lot of archive space
<persia> jdahlin: Matter of preference I suppose.  I often don't need the -dbg or -dbgsym package when working on a stacktrace generated by someone else, and don't always try to fix stacktraces I generate.
<jdahlin> the -dbg package for glib points to a path inside a buildd root, it's not very useful...
<jdahlin> minghua, that could be solved by having a separate repository for debugging packages
<minghua> honestly I don't see how that would help anything
<jdahlin> minghua, I guess you don't use gdb a lot do you?
<minghua> It's probably a little more convenient for those who do debugging, but the downside is not worth it
<minghua> jdahlin: no I don't
<ikesire> is it true that gutsy won't include ntfs-3g by default (on the install cd)?
<jdahlin> persia, the -dbg packages are already quite heavy and contains redudant information, I can't see why it shouldn't contain all necessary information to make life easier for developers
<minghua> jdahlin: what redundant information do the -dbg packages contain?
<jdahlin> minghua, gdb is very painful to use without access to the sources, it's like walking blind folded, you can't really see what you're doing without the source code
<jdahlin> minghua, a completely new binary!
<Fujitsu> apt-get source somepackage
<Fujitsu> Done.
<persia> jdahlin: Aside from archive space, personal preferences, reduction of redundancy, and different (but overlapping) target audiences, I don't have any explanations.
<minghua> jdahlin: I don't quite know about the -dbgsym packages for Ubuntu, but for Debian, the -dbg packages, if built correctly (with dh_strip, for example), don't contain completely new binaries, only the debug symbols
<jdahlin> persia, I can't see who's the target audience for -dbg packages without source code included.
<minghua> jdahlin: and I believe the -dbgsym packages are the same
<persia> minghua: The Ubuntu -dbg and -dbgsym packages also follow that model.
<minghua> persia: do ubuntu have different/separate -dbg packages?  I thought not.
<Fujitsu> We keep most that Debian has, but -dbgsym makes them redundant.
<persia> jdahlin: Those generating backtraces for bug reports.  These people may not be developers, but they may have just the right environment to generate a crash that cannot be replicated by a developer.  Also, the apport retracing service.
<persia> minghua: Sometimes.  Generally the dbgsym packages are enough, but many packages (especially Debian imports) have -dbg packages defined as well.
<calc> crimsun: ah NID == Node ID
<jdahlin> persia, remember that source package is not the same as the source code as I am refering to
<jdahlin> persia, the source code I'd like to have included is just all the source files which the debugging symbols refers to
<jdahlin> persia, which in general is very small compared to the size of the complete source package
<jdahlin> sorry, it's not that small I compared compressed vs uncompressed. it appears to be about the same size as the object files.
* LongPointyStick waves
* Fujitsu waves back.
* minghua gets out of LongPointyStick's way :-P
* LongPointyStick picks up Fujitsu, and throws him at minghua, for a bit of variety
<Fujitsu> Ouch.
<LongPointyStick> why use a pointy end when you can use a person-projectile?
<LongPointyStick> at least some of the time
<Nafallo> grrr
<Nafallo> something has put folders in my homedir!
<persia> Nafallo: xdg-user-dirs
<Nafallo> but... why?! :-)
<LaserJock> my money is on "because it's fun" ;-)
<Burgundavia> Nafallo: to make nice default locations for crap
<Nafallo> Burgundavia: I already have those, and it's not the new folders :-P
<Nafallo> they use big Capitals ffs ;-)
<superm1> hi guys, I was wondering if anyone could speak to casper and the requirements for the hooks to properly work
<sbalneav> Booyeah.  fixed nbd-server
<calc> ScottK: hi :)
<ScottK> Hello calc.
* ScottK guesses you read my mail to MOTU Council.
<calc> ScottK: yea
<calc> ScottK: just replied to it
<ScottK> OK.
<ScottK> calc: Sounds reasonable.  It's just a little odd for a community driven process when someone shows up and says (essentially, although very politely) I need to be annointed because of the job Canonical gave me.  
<calc> ScottK: well i was hired for OOo but all of my other debian packages are in core as well
<calc> though since i am in debian already i could probably manage to maintain them directly in debian such that they only need sync on ubuntu side
<ScottK> Interested in fixing any KDE related bugs?
<StevenK> ScottK: Oh no, get your hooks off him. :-P
<ajmitch> hah
<calc> heh
<ajmitch> maybe he's ran away from KDE to preserve sanity?
<calc> i haven't used KDE in several years, stuck with gnome in Ubuntu :)
<ScottK> calc: Actually I think that's preferred (work in Debian) that way more people benifit.
<calc> ajmitch: yes thats part of it ;)
<ajmitch> calc: and yet you do OOo...
<calc> ajmitch: hehe
<calc> ajmitch: OOo can't be as insane as KDE, er right? ;)
* ajmitch coughs
<calc> lmao
<calc> ok so i'm not sane, but its fun anyway
<ajmitch> that's probably why they hired you
<ajmitch> sanity doesn't seem to be a common trait
<calc> number one thing for me is to do work that benefits a lot of people and promotes oss
<calc> the best way i saw to do that was to become the OOo guy :)
<calc> i took over KDE when the previous debian guy got burned out on it and orphaned it at all at once
<calc> while i had a full time job and full time school on top of that, heh
<calc> so i think i am slowly becoming less insane
<calc> my current pet bug is to fix the alc268 codec
* calc notes he knows nothing about audio drivers yet
* calc is reading source and datasheets
* Fujitsu is laughing at calc for having to deal with OOo.
<Fujitsu> That really can't be pleasant :(
* superm1 wonders why everyone wants to hear things so badly.  first crimsun working on lots of audio bug , then him pawning off audio work to LongPointyStick , and now calc wants to help.
<calc> superm1: my sound doesn't work :)
<calc> so i am going to fix it myself
* calc has written webcam and fs drivers before
<calc> learning enough about hda to actually understand whats going on takes a while though
<calc> ok i think i have the beginnings of a clue about how this audio stuff works after reading this datasheet
<calc> whee i understand this stuff now
<calc> now the question is whether i can figure out what is wrong with the patch so i can fix it
<jetscreamer> \o/
<pygi> morning folks
<Hobbsee> hiya
* popey hugs everyone
<Fujitsu> Hi popey.
<Fujitsu> Why do we deserve such hugs?
<Hobbsee> hello popey 
<pygi> Hobbsee, !!! :)
<Hobbsee> hi pygi :)
<pygi> Hobbsee, just looking over some other stuff ... mhm, most of the bugs are either fixable in 5 minutes, or closable already
<Hobbsee> pygi: yay :)
<pygi> Hobbsee, but nobody is working on those :(
<Hobbsee> pygi: yell if/when you need a sponsor
<pygi> looking at this right now: https://bugs.launchpad.net/ubuntu/+source/nautilus-cd-burner/
<Hobbsee> are they coding bugs, or packaging bugs?
<pygi> both
<Hobbsee> right
<pygi> Hobbsee, wanna work on that one? I have two hours, we might solve n-c-b as well today
<pygi> (and yes, I know it's sunday :P)
* Hobbsee needs to study and such, and if i start bug fixing, i sure as heck wont do the study.
<Hobbsee> mind you...reading this blog i wont either...
<Hobbsee> pygi: yeah, why not.  at least a bit.
<pygi> Hobbsee, k, blue ones and grey ones are yours
<Hobbsee> of n-c-b?
* Hobbsee doesnt know n-c-b at all
<Hobbsee> and it was the colourless ones that were mine, yesterday
<pygi> Hobbsee, yea, but grey is a color =)
<Hobbsee> indeed :P
<pygi> see? I learn :p
<pygi> Hobbsee, we'll take some package of your choice after exams then :)
<pygi> we could fix-up amarok or something ^_^
<Hobbsee> cool
<pygi> btw. blue are mostly trivial, it's a wishlist
* Hobbsee marks a dupe
<Hobbsee> true
<pygi> if there are some things we can easily implement, do poke about the bug number, and I'll see what can we do
* Hobbsee kills a couple more
<pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/nautilus-cd-burner/+bug/49127
<ubotu> Launchpad bug 49127 in nautilus-cd-burner "Long file names are truncated without warning" [Low,Confirmed]  
<pygi> interesting bug ^_^
<Hobbsee> pygi: indeed
<pygi> Hobbsee, good that I know about that standard ^_^
<Hobbsee> :)
<pygi> finally something useful out of it :p
<Hobbsee> pygi: did you need to do an upload of k3b from yesterday?  I found another patch
<pygi> Hobbsee, patch for what? Point me ?
<Hobbsee> pygi: https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/109968
<ubotu> Launchpad bug 109968 in k3b "K3b shows an inexact information if MP3 plugin not installed" [Wishlist,Confirmed]  
<pygi> why didn't we saw that before?
<Hobbsee> pygi: because i rejected it, adn didnt see the patch.  *shrugs*
<pygi> Hobbsee, ah, we've got similar bug which is assigned on me
<pygi> gimme a sec
<Hobbsee> pygi: yeah, thoguht so.
<pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/gutsy/+source/k3b/+bug/121877
* Hobbsee downloads k3b source to throw at a feisty pbuilder, to see if it builds.
<ubotu> Launchpad bug 121877 in k3b "K3b doesnt prompt the user to install kubuntu-restricted-extras for codecs" [High,Confirmed]  
<Hobbsee> pygi: true that.  want me to mark as a dupe?
<pygi> Hobbsee, yup
<pygi> Hobbsee, and AFAIK that patch is useless for us
<Hobbsee> done
<pygi> thanks
<pygi> Hobbsee, I'm done with mine n-c-b bugs
<pygi> you?
<Hobbsee> pygi: i was done a while ago - based on the fact that i don trun the software, so could only do packaging bugs
<pygi> Hobbsee, hehe, oki :)
<Hobbsee> sarah@liquified:~/current/k3b-1.0.1$ pl-feisty
<pygi> it should afaik build
<Hobbsee> oops
<pygi> and I *want* it in feisty-updates :(
<Hobbsee> is it a SRU candidate?
<pygi> no idea :p
<pygi> but if not, it should be
<pygi> it fixes some important bugs
<Hobbsee> if it's a new upstream version, then no, it isnt.  you'd have to cherry pick
<Hobbsee> or at least, tha'ts hte usual case
<Hobbsee> (see dapper xorg breakage for the reson why)
<Hobbsee> !sru
<ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse.
<pygi> meh :P
<pygi> I know what a SRU is, thank you :)
<Hobbsee> way cool.  another LP bug.
<Hobbsee> right
<Hobbsee> this newest rollout has had a whole lot of new bugs.  brilliant.
<pygi> hehe :)
<pygi> Hobbsee, I've suggested workarounds on number of n-c-b bugs
<Hobbsee> pygi: workarounds or fixes?
<pygi> let's hope they work. If they do, we can just package it with the workaround probably
<Hobbsee> jdong: recurring ping
<pygi> Hobbsee, workarounds, by using cdrskin instead of wodim
<Hobbsee> pygi: ah right
<pygi> not sure if it'll work, but worth to try
<Hobbsee> :)
<pygi> Hobbsee, wake up =)
<pygi> ergh
<pygi> jdong, wake up :P
<pygi> brasero and k3b backports awaiting you :)
<pygi> Hobbsee, sorry ^^
<Hobbsee> no problem
<pygi> talking too much with you lately is bad :P
<Hobbsee> haha
* Hobbsee is evil, like that
<Hobbsee> i wish this exam tomorrow was actually on something interesting.
<pygi> Hobbsee, what is it?
<Hobbsee> pygi: it's electronics
<Hobbsee> pygi: unfortunately, i had only very small amounts of interest in it when i *started* the subject this semester.
<pygi> o yes, you told me about that
<Hobbsee> then i just didnt understand it, went to spain, got so far behind, etc, that i definetly lost all interest in it.
<pygi> hehe :)
<pygi> meh, LP interface is messy :(
<pygi> no idea how to add upstream tracking
<pygi> o well
<Hobbsee> pygi: the "upstream" section
<Hobbsee> which bug?
<realist> https://bugs.launchpad.net/ubuntu/+source/nautilus-cd-burner/+bug/49127 - could that be filesystem related?
<ubotu> Launchpad bug 49127 in nautilus-cd-burner "Long file names are truncated without warning" [Low,Confirmed]  
<pygi> realist, afaik it's mkisofs related =)
<Hobbsee> pygi: you want Also affects:  +   Upstream
<pygi> Hobbsee, I can't find neither kde or gnome on the list of upstream projects
<pygi> meh
<Hobbsee> pygi: gnome should be there
<pygi> Hobbsee, I got that, but still :p
<Hobbsee> which bug?
<pygi> sec
<Hobbsee> oh, the project is n-c-b
<pygi> nah, it's brasero now
<pygi> but still can't find anything useful
<pygi> https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/120322
<Hobbsee> does lp.net/brasero exist?
<ubotu> Launchpad bug 120322 in brasero "Add functionality to make multiple copies of a disk" [Wishlist,Confirmed]  
<pygi> needs watch on:
<pygi> http://bugzilla.gnome.org/show_bug.cgi?id=447399
<ubotu> Gnome bug 447399 in general "Add functionality to make multiple copies of a disk" [Enhancement,Resolved: duplicate]  
<Hobbsee> pygi: instead of what's there already?
<pygi> Hobbsee, yup, instead of the old upstream bug watch
<Hobbsee> pygi: right.  click on the old bug watch, change it to GNOME Bug tracker, and add the new number
<Hobbsee> it's there - scroll down a bit
<pygi> Hobbsee, and yay for us, so much k3b bugs closed
<Hobbsee> :D
<pygi> yay, I fixed the upstream tracker!!!
<pygi> :)
<Hobbsee> woo!
<pygi> realist, why do you think it's a FS problem?
<pygi> well, truncating does need to happen indeed, but the bug has two problems:
<pygi> a)mkisofs should have more intelligent truncating algorithms
<pygi> b)n-c-b should provide a way for renaming
<pygi> the ISO9660 does indeed impose length limit which can be extended with joliet/rockridge, but still .... 
<realist> I was just assuming that certain filesystems would have a limit on path/filename lengths
<pygi> two above problems still stand :)
<pygi> read what I just said ^_^
<Hobbsee> realist: so fix those filesystems :P
<realist> Hobbsee: I'd rather not :-)
* pygi eats Hobbsee 
<pygi> be good Hobbsee :P
<mhb> Hobbsee: are you sure about bug 121877 ?
<ubotu> Launchpad bug 121877 in k3b "K3b doesnt prompt the user to install kubuntu-restricted-extras for codecs" [High,Confirmed]  https://launchpad.net/bugs/121877
<realist> pygi: so basically, the bug relates to handling potential truncation, before it actually happens, and giving sane options/alternatives?
* pygi looks
<pygi> realist, I've explained the problem a bit in my latest comment, but mostly ... yes
* Hobbsee sends pygi to her workplace, and makes him work all her shifts
<mhb> Hobbsee: what I think is that the user should not *get* any unsupported software he does not request.
<Hobbsee> mhb: what about it?
<pygi> Hobbsee, will do :)
<realist> Reading the bug comments now.
<mhb> Hobbsee: and k-r-e is not just k3b encoding/decoding, right?
<Hobbsee> good pygi.  you'll save me from killing the stupid people
<Hobbsee> mhb: this is correct.
<Hobbsee> mhb: i'm going off the easy-codec-installation and common-customisations spec
<Hobbsee> pygi: maybe a thing to say "this will install the most commonly used stuff, if you wish to only install components, please install x,y,z manually"
<pygi> Hobbsee, meh, useless
<pygi> IMHO ofcourse
<Hobbsee> pygi: well, yeah.  but it is possible that they may only want certain codecs.
<Hobbsee> i'd have to check the two specs for it
<pygi> Hobbsee, do check, and report to me :)
<Hobbsee> as i never saw what the outcome was fro gnome
<pygi> Tell me what "manual stuff" we want mentioned there then
<Hobbsee> liblame0 and libk3b-mp3*whateveritis, iirc
<pygi> Hobbsee, just mention it there pls :P
<Hobbsee> ok
<pygi> I can''t track everything in my head =
<pygi> =)
<Hobbsee> :P
<Hobbsee> why not?
* Hobbsee should actually read the tribe 1 feedback, etc, on teh mailing list, before startign tribe 2 testing, i guess...
<mhb> Hobbsee: to be honest, I don't believe in pop-ups at first-startup-time
<Hobbsee> mhb: was that what the spec specified?
<pygi> mhb, this isn't popup at first-startup-time ?
<Hobbsee> mhb: i would assume it's for the first time a codec-required app is started.
<pygi> it's just a change in the dialog that k3b regulary shows
<mhb> pygi: at first-startup-time
<pygi> ok, I don't get you :P
<pygi> we aren't introducing any new dialogs at startup time :)
<pygi> (when it's first ran :P)
<mhb> Hobbsee: I might be wrong, but Ubuntu apps I ran offered to install the codecs only if I played any non-free media
<pygi> ok, now I'm seriously confused
<pygi> someone fill me in on what we're talking about
<Hobbsee> mhb: this isnt the restricted manager here
<mhb> no, it isn't
<mhb> Hobbsee: restricted-manager is also something completely different
<Hobbsee> exactly
<mhb> Hobbsee: why aren't we discussing this in #kubuntu-devel?
<realist> What's the best way of approaching upstream authors, about providing bug/security patches that you've written?
<realist> Just a straight-forward email, with the patch?
<pygi> realist, mailing them politely with a patch, with GPG encrypted message? :)
<pygi> if it's a security patch ^_^
<Hobbsee> mhb: because pygi is here, and we've had various burning related discussions here in the past few days.
<realist> encrypted? is signing enough?
<Hobbsee> mhb: and it's quiet
<pygi> Hobbsee, I'm there as well if you really want to do it in #k-d
<Hobbsee> realist: usually.  i dont bother encrypting, for the most part
<Hobbsee> pygi: makes no difference to me.  go for it
<pygi> Hobbsee, same to me :P
<pygi> everyone is quiet anyway =)
<realist> Okay, so just say, upstream author rejects patch, is it still okay to apply our own patches for ubuntu packages?
<realist> Or is it preferred for package to be inline with upstream source?
<pygi> realist, it is ok to apply own patches, depending on the patch
<ajmitch> ~/win 28
<pygi> ajmitch, ? ^_^
* pygi is confused :P
<ajmitch> that's ok
<realist> So I guess it's our job to make sure that our patch doesn't conflict with any changes subsequently made to upstream sources?
<pygi> realist, we can just drop the patch later on
<realist> Okay, next silly question. It's okay to be both debian _and_ ubuntu developer?
<pygi> ofcourse
<realist> Good, because I was having a difficult time deciding where to direct my efforts :-)
<pygi> hehe :)
<realist> Now, if only I can pick up an orphaned package that exists in _both_ distros
<realist> Is there an easy way to find such packages in ubuntu?
<realist> i.e. no maintainer?
<pygi> realist, in ubuntu we don't have maintainers
<Hobbsee> although there are plenty of packages which arent being kept up to date in ubuntu
<pygi> or properly maintained (i.e. no patching to make sure everything works, and stuff)
<realist> pygi: that's a concept I can't understand
<pygi> realist, there's MOTU which maintain universe and multiverse packages, and core devs which maintain Main and Restricted
<realist> So the MOTU don't look after _specific_ packages?
<pygi> nop
<realist> They just contribute where ever, and when ever they want?
<pygi> not exactly like that, but ...
<pygi> there's ofcourse coordination, talks, decisions, arguments, and stuff
<Hobbsee> realist: basically
<Hobbsee> realist: often people work in teams - or have sets of packages taht they touch
<realist> Chaos theory!
<Hobbsee> realist: but anyone can touch anything, yes
<Hobbsee> realist: not really.  it works reasonably well.
<realist> I can see how that'd work actually
<realist> So people just start these 'teams' on launchpad?
<Hobbsee> realist: i mean, there's social protocol that says "if a person has done the last few uploads of this, i should ask them first before i touch it"
<Hobbsee> realist: a lot goes on in #ubuntu-motu, via email, whatever
<realist> And focus on certain sets of bugs/requests, etc?
<Hobbsee> well, for kde, for eg, we tend to have a group of people who works with debian kde extra team, who keeps control of all the kde packages in ubuntu
<realist> Hobbsee: but it's not written in stone
<Hobbsee> realist: not currently
<realist> This will take me some getting used to :-)
<Hobbsee> realist: i mean, people go inactive
<Hobbsee> and if there's no response, then feel free to go and change it
<realist> Is there official protocol for those cases?
<realist> Like, no response within X days/weeks, etc?
<pygi> realist, not really
<Hobbsee> and most people will say "feel free to patch this", or in some cases "dont bother to merge this, i've looked at it already, and it's broken"
<pygi> we just know when and how to handle it
<realist> Just wondering where the ownership, or accountability is
<Hobbsee> realist: nope.  it's really just a free-for-all.
<Hobbsee> realist: the MOTU team takes responsibility of them, really.
<realist> Perhaps I've been in a commercial environment too long already ;p
<Hobbsee> realist: it's not main, whihc is commercially supported
<realist> This "free-for-all" I could get used to
<pygi> Hobbsee, it mostly works really good
<StevenK> realist: Loosely organised choas. It's fun.
<Hobbsee> realist: but even that - there are teams of people who do variosu bits
<realist> More eyes and hands on the code, has to be a "good thing" right?
<Hobbsee> exactly
<realist> So how are arguments/debates resolved?
<ion_> With guns.
<Hobbsee> ion_: *grin*
<Fujitsu> ion_ is correct.
* realist laughs
<Hobbsee> realist: cant say there have been many, actually.  very few.
<Hobbsee> realist: ther'es one on what to do about clamav stuff
<Fujitsu> There are too few of us to have debates.
<realist> What if someone disagrees with changes I've made?
<Hobbsee> realist: but the people get on reasonably well - you've seen the COC, i presume, which everyone is under?
<Hobbsee> realist: then they'll politely tell you, usually with reasons about why it's incorrect
<realist> I've already _signed_ the CoC
<realist> Is there avenues for arbitration?
<pygi> realist, everything can be agreed on, and there are policies on sane and insane stuff :p
<Hobbsee> realist: right.  i was merely pointing to it, and saying taht that stops a lot of flames, etc
<pygi> mostly unwritten, but they do exist
<Hobbsee> realist: motu mailing list is a good start - if it really escalates, there's the community council or tech board.  
<realist> Mmmm it's the "unwritten laws" I'm uncomfortable with
<realist> Hobbsee: that sounds sensible
<Hobbsee> (which is written, in the procedures of ubuntu)
<realist> I should probably get on that mailing list
<realist> Any others I should be interested in?
<Hobbsee> ubuntu-devel, maybe ubuntu-devel-discuss too
<Hobbsee> ubuntu-devel-announce and ubuntu-announce are low traffic, and are useful
<realist> I'm already on security-announce, is there a place for security related discussion?
<Hobbsee> realist: ask keescook 
<Hobbsee> when he's here
<realist> I'm actually more interested in security related fixes, than anything else
<pygi> realist, nice :)
<Hobbsee> realist: he's the security guy.  i beleive there is stuff, but i dont remember exactly what, offhand
<Hobbsee> realist: have you come from debian, or what?
<realist> I vaguely remember a security-discuss, but I think it's dead
<realist> I've been using debian for, umm 10+ years
<Hobbsee> i meant a developer of it
<realist> But never an 'official developer'
<Hobbsee> right
<realist> It's about time I started giving back
<Hobbsee> realist: you'll find there's a collaborative attitude here, rather than an "it's my package, and if you touch it, then i'm going to come and hunt you down", as is often (it seems, from an outsiders POV) the case in debian.
<realist> Also a fan of OpenBSD
<realist> Hobbsee: there's just more organisational structure in debian, relating to single packages
<Hobbsee> realist: indeed.
<realist> Although, nothing stopping anyone else from contributing code to that particular developer
<Hobbsee> realist: which is why i've never gotten involved particularly much in debian.
<Hobbsee> true - they just can reject it, and be a right pain
<realist> Having said that though, I could see the benifit in a 'free-for-all' approach
<realist> Hobbsee: indeed
<Hobbsee> hiya mvo 
<realist> Although, if your suggestion/contribution is good enough, they could accept it
<mvo> hey Hobbsee
<realist> So, in order to upload, you need to be either MOTU, or core dev?
<Hobbsee> realist: this is true.  i've submitted a couple of packages back to debian.
<realist> But for now, what can I do to contribute?
<Hobbsee> realist: technically, yes.  there are sponsorship processes, though
<realist> Submit packaged work to existing MOTU?
<Hobbsee> realist: check https://wiki.ubuntu.com/MOTU
<Hobbsee> hmmm.  persia's guide isnt in there yet, for sponsorship
<realist> Hobbsee: a more useful link, would be a list of willing mentors/sponsors :-)
<Hobbsee> realist: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue is the info about the sponsorship queue
<realist> Woot!
<realist> Thanks :-)
<Hobbsee> realist: this is true - but there arent a lot of mentors around.  and the current lot of mentorees seem to go "i want a mentor, to tell me what to do, in everything"
<pygi> realist, if you need anything, just ask
<Hobbsee> which is...less than useful.  you'll do better if you've already got something that you'd like to work on - either a package or an area
<pygi> we're always willing to help :)
<realist> I guess it's time for me to debootstrap a chroot dev environment now :-)
<realist> Get some actual _work_ done
<pygi> realist, pbuilder might work good as well =)
<Hobbsee> realist: or use a pbuilder
<Hobbsee> realist: dual booting, etc, is often a good way to test
* Hobbsee uploads exaile from that queue
<mhb> hi mvo 
<mvo> hey mhb, thanks for your mail
<Hobbsee> mhb: pygi mvo can probably provide input about the restricted stuff - or maybe not during a sunday
<pygi> Hobbsee, let's not do it today, and let's keep it simple :)
<mhb> mvo: check the code once you have time. If you could manage to look at it so we could upload a package in time for Tribe 2, that would be awesome.
<Hobbsee> depends what mvo wants.
<Hobbsee> if he can keep his connectoin for long enough
<ajmitch> hey mvo/mvo_ :)
<Hobbsee> case in point.
<mvo__> mhb: I will answer to your mail, network is way too unstable again here (but I was promised that it get fixed on monday, yay!)
<ajmitch> Hobbsee: maybe he's just having a multiple personality day?
<Hobbsee> mvo__: hooray!
<Hobbsee> ajmitch: heh, perhaps.  but this happens most days :P
<mvo_____________> ...
<ajmitch> hah
<Hobbsee> haha
<Hobbsee> poor mvo
* Fujitsu loves his reliable cable.
* TheMuso pats his reliable ADSL.
<TheMuso> c
<mhb> mvo: uh oh, that sounds like you hated the code :o)
<TheMuso> ugh
<Hobbsee> TheMuso: you really do love the "c" key, dont you...
<TheMuso> Hobbsee: You know what the reason is for that.
<TheMuso> I nedant mention it again.
<Hobbsee> TheMuso: i used to.  unfortunately, exams have killed my brain or something.
<Hobbsee> i've forgotten :(
<TheMuso> Hobbsee: Speakup + kvm
<Hobbsee> TheMuso: ahhh.  right
<Hobbsee> TheMuso: i figured it was likely something to do with speakup
<realist> what's "speakup"?
<realist> Oh cool :-)
<TheMuso> realist: At this point of time, I would call it a piece of crap code that does its best to screw your system if its loaded.
<Enola_Gay> hi all
<Enola_Gay> I think that support is very important for Linux/Ubuntu. Since many people are behind routers/firewalls it isn't so easy to help them with vnc. People who need support doesn't often know how to open ports. Another group are people behind a firewall which can't be changed by them. For all them it would be great to have GUI for connection to listen vnc. People who give support know how to forward ports so it makes much more 
<Enola_Gay> sense to let supported connect to vnc listen clients. This also makes things more secure since they don't need to open ports. Should I make a feature request or are there several reasons why this isn't already implemented?
<Enola_Gay> And please don't forget to fix the vnc compiz bug until Gutsy release. Otherwise vnc support isn't possible anymore.
<Hobbsee> Enola_Gay: --> ubuntu-devel-discuss mailing list, please
<Hobbsee> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<Enola_Gay> thx
<Hobbsee> no problem
* realist pats ubotu 
<Enola_Gay> I post it to launchpad so if someone is interested ...
<realist> Enola_Gay: To be honest, I'm not entirely sure what you're proposing.
<Enola_Gay> realist: Atm it is only possible to connect to someones computer to help him with vnc
<Enola_Gay> So there have to be a port forwarded
<Enola_Gay> But vnc has an option listen so the clients wait for connections and the remote desktop connects to the client
<realist> Ahhh I see.
<Enola_Gay> So everyone who needs support behind a firewall doesn't need to forward anything just insert the ip and connect to the support who of course is able to forward ports.
<Enola_Gay> Much more easier.
<Enola_Gay> But without a gui it isn't so easy.
<realist> Might actually be easier for someone providing the support, to instruct someone to use the CLI, than a GUI
<realist> I know this is the case for me, since I can remember CLI better, as opposed to GUI navigation
<realist> You could even post the CLI instructions, where the support client could copy/paste
<realist> That'd be my workaround, but your suggestion is still a good one, so definately post to the mailing list
<Enola_Gay> this is true but many people who needs support doesn't like the console :)
<Enola_Gay> Do you know svnc? This is a great program for windows. It consists a little vnc server and all information needed to connect to the supporter. So if someone needs support you send him this file and he needs nothing more than just start it. It even supports encryption.
<Enola_Gay> And it is open source :)
<Enola_Gay> Ok, I have made the feature request. By the way the program is called scvnc. Thanks for your support. Cu
<popey> they dont need to use the console, you can do ALT+F2 and type the command in the box
<Enola_Gay> popey: :)
<Enola_Gay> But I have to send them per Mail. Most of the old ones don't use im
<Enola_Gay> And it would be very hard through a telephone
<Enola_Gay> This is needed to convince them from Linux imho since they need much support at first. The great thing is that they didn't play 3D games and most of the time only surf, write or print something but if they have i.e. a Canon printer it would be a problem too.
<Enola_Gay> Btw does anyone know if Java would be OpenSOurce in Gutsy and main?
<pygi> Enola_Gay, no
<Enola_Gay> Because it isn't ready?
<pygi> it isn't open source
<pygi> not completely
<Enola_Gay> ok
<Enola_Gay> thanks
<Enola_Gay> cu
<StevenK> pitti: Hi!
<pitti> hello
<pitti> Hi StevenK 
<StevenK> pitti: Is archive-cruft-checker still busted?
<pitti> StevenK: yes, I doubt that someone fixed it over the weekend
* StevenK nods.
<StevenK> It's becoming a little hard to juggle state about it in my head.
<tsmithe> are there any archive admins able to look at http://revu.tauware.de/revu1-incoming/ubuntustudio-sounds-0706231730/ubuntustudio-sounds-0.5/debian/copyright (the debian/copyright file for ubuntustudio-sounds), and tell me if it is acceptable?
<Hobbsee> hi pitti!
<pygi> pitti, hey ho
<pitti> StevenK: are you interested in a particular package? I can generate the rdepends per-package manually
<pitti> StevenK: bah, I just regenerate them all
<Hobbsee> pitti: he's watchign tv
<pitti> StevenK: all updated
<pitti> siretart, gpocentek: can I poke you again about the ffmpeg / libgoffice transition?
<StevenK> pitti: Thanks!
<pitti> StevenK: http://people.ubuntu.com/~pitti/scripts/checkrdepends, BTW
<pitti> StevenK: that's the scripts which generates the output per package (source, or binary with -b)
* StevenK nods.
<StevenK> pitti: I'm a bit loath to just blindly rebuild the packages for ppc and ia64 for jasper without checking, but I am without ppc and ia64.
<pitti> StevenK: no big problem; at worst it doesn't work and we need to build them again; no big deal
<StevenK> pitti: Well, I'm happy to do so if you like.
<pitti> StevenK: great, thank you
<StevenK> Ugh. Some of the sources are huge.
<StevenK> pitti: Your script seems to write out empty files, too.
<StevenK> pitti: libtotem-plparser1 is zero size
<pitti> StevenK: yeah, I didn't remove packages without rdepends
<StevenK> checking whether system headers can cope with -O2 -fno-inline... irrelevant
* StevenK chuckles
<davmor2> Hi Devs  Ubiquity and deb-installer are both failing on iso's for the 24/06/07.  Ubiquity gets a bugreport but it is empty.  deb-installer fails on debchroot ?  I think it is called.
<Hobbsee> davmor2: ok.  not sure if the candidate cds are being spun and such yet - main's not frozen yet
<davmor2> I know but it definitely is something that needs to be worked on.  That's my reason for highlighting it.
<Hobbsee> thanks :)
<davmor2> well what else is the isotesting team here for ;)
<Hobbsee> davmor2: i doubt all the stuff is in, if main's not frozen - which is when the real tribe 2 candidates testing will start.  so hang around for a couple of days, and please test again :)
<Hobbsee> main freezes on tuesday, then they'll spin iso's and whatnot from there
<davmor2> Hobbsee:  Yes my main testing is on tuesday evening/ Wednesday.  but I was having bother with updating nm-applet and it not working well with gnome-keyring-manager.  So I was hoping that an update cd would solve the issue.  It's works fine on live I just can't install :(
<Hobbsee> ahhh
<davmor2> but it has at least highlighted the issue with the installer
<Hobbsee> true
<davmor2> bye for now
<afflux> TheMuso: Hobbsee sent me to you because of bug 121937. Someone requests a way to let blind people decide in what language the live-cd should boot up.
<ubotu> Launchpad bug 121937 in Ubuntu "live-cd should ask for the language country (and maybe keyboard)" [Undecided,New]  https://launchpad.net/bugs/121937
<Hobbsee> afflux: he's asleep
<afflux> uh.
<afflux> I tend to forget that it's 16 o'clock only in central europe ;)
<Hobbsee> lol
<pygi> ogra, ! :)
<pygi> afflux, 4:40 to be precise =)
<ogra> hey
<ogra> 42 here :P
<pygi> ok, ok, germany is always special :p
<ogra> indeed
<afflux> now 42 in germany :D
* pygi is just joking ^_^
<afflux> (it's the answer!)
<ogra> yeah
<pygi> how are you doing?
<ogra> playing with hal ...
<ogra> http://people.ubuntu.com/~ogra/ltspfs-hal-root.png
<pygi> uh, that must be interesting
<pygi> it always is :)
<ion_> 17:41:36 < pygi> afflux, 4:40 to be precise =)  17:41:44 < ogra> 42 here :P
<ogra> hehe
<pygi> ion_, but, but ...
<pygi> you're *wrong*
<ion_> My ntpd should be working, unless it has became b0rked.
<sim2> who knows why /var/run and /var/lock are excempted from umounting in /etc/init.d/umountfs
<ion_> They are mounted as tmpfs.
<sim2> no they are specifically filtered based on their name
<sim2> but why, it keeps my /var mounted during shutdown
<Kmos> keescook: are you there?
<silvertip257> good day everyone
<silvertip257> I doubt I'm in the right place, but I'd like to learn how to put together a live cd
<mc44> silvertip257: https://help.ubuntu.com/community/LiveCDCustomization ?
<silvertip257> mc44:  I tried that, but to no avail ... i'm lookin into making one from the foundation up
<pygi> silvertip257, try reconstructor
<silvertip257> hmm ok pygi
<silvertip257> thank you ... I will check that out .. bye
<imachine> Hi
<imachine> would this be the place devs sit about ?
<pygi> imachine, what ya need?
<imachine> pygi: dude, I need to know what patches apply against vanilla on ubuntu kernel
<imachine> talking about standard normal amd64 kernel that gets installed, 7.04
<pygi> ah
<pygi> you could apt-get source the kernel package, and get the source
<imachine> I'd like to use them maybe on the distro I use currently, but I don't know what they are. I need I guess acpi-asus patches.
<imachine> yeah, but I use archlinux ;)
<imachine> so no apt-get about ;] 
<pygi> ah
<imachine> pygi: wouldn't that provide me with the ready sources anyway, and not vanilla + patches lying about in some patches/ dir ?
<pygi> ubuntu holds it's own kernel tree
<imachine> cuz I could always download them just from some ubuntu mirror manually, whatever files apt-get source would provide me with.
<pygi> I'm really not the right kernel person you should talk to :)
<imachine> well, don't you guys patch the vanilla stuff? I think you have to one way or the other no ?
<crimsun> of course.  Its public via kernel.ubuntu.com/git/
<pygi> ofcourse that patching happens
<crimsun> It's, even.
<pygi> but don't ask me :P
<pygi> there, crimsun :)
<imachine> oic.
<imachine> ta
<imachine> well. ultimately, I'd just like a directory I could get to ? and see stuff in there?
<imachine> uh I'm feeling dumbified, if that's even a word.
<imachine> this whole ubuntu business, sorry guys I mean no offence, but it's on f..... mess for me.
<imachine> I could never dev for you ;P
<imachine> respect for finding your way about.
<bhale> it isnt so hard if you have the tools and the will to learn them
<imachine> well it's not hard. it just seems overly complicated for no reason.
<crimsun> you need the git-core package or its equivalent on arch
<imachine> feels like you guys have levels of awareness ;)
<crimsun> then just clone the appropriate tree
<imachine> crimsun: well I guess I can use git yeah
<imachine> crimsun: and what will git pull in? will it pull in what I want, that is, vanilla + patches aside ?
<imachine> I'm used to a PKGBUILD + patches and stuff in the PKGBUILD mentioning them.
<crimsun> I recommend you read the documentation on using git.
<imachine> bsd style Makefile. emerge files.
<imachine> whatever like that.
<crimsun> cloning a git tree pulls the entire tree
<imachine> yeah that's okay. just what will I get there.
<imachine> i.e. , what does your git tree contain.
<crimsun> the entire Linux tree
<imachine> does it contain what I need, that is, vanilla + patches ?
<crimsun> are you even looking at kernel.ubuntu.com/git/ ?
<imachine> do you even have patches aside ?
<imachine> or you just dev and submit.
<crimsun> patches are in git changesets.  There is no separate patch repository.
<crimsun> Seriously, read the git documentation.
<imachine> well you don't understand what I'm saying I guess. because I understand patches to git, and to certain next/before versions of the tree. that's one thing.
<imachine> but what I'm talking about is Ubuntu patches to the vanilla kernel.
<imachine> that's what I ultimately need.
<imachine> i just need the ubuntu patches, nothing more. the stuff that makes ubuntu kernel an ubuntu kernel.
<imachine> like I said somewhere else, I *could* just get your kernel through git like you said, and diff the files I want against a clean vanilla kernel
<imachine> that way I'd get patches.
<crimsun> then execute a recursive unified diff over the source and the origin.
<imachine> but that's overhead I think.
<imachine> yeah, so no other way then I reckon ?
<superm1> crimsun, do you have a copy of that script that you use for collecting alsa related info?  I have a friend who is having troubles with gutsy and alsa, so I was going to have him run that and file a bug
<imachine> crimsun: have you got no build files? or would those build files use the already patched kernel sources.
<crimsun> superm1: linked from my LP profile.
<superm1> thx crimsun 
<crimsun> imachine: "build files"?
<imachine> yeah.
<imachine> I mean, how do you build your packages?
<crimsun> see debian/rules
<imachine> not interested.
<imachine> anyway.
<crimsun> um, you asked how they're built, and that's what you would need to see...
<imachine> a build file is a file which contains information as to how a package is supposed to be built.
<crimsun> that's precisely debian/rules
<imachine> well, that was sort of a rhethorical question I guess.
<imachine> I see, I thought that was some disclaimer ;)
<imachine> sorry.
<imachine> ok.
<imachine> crimsun: so normally, I'd expect a line somewhere in this rules file that orders the build process to patch. since it would normally fetch vanilla sources, and patch them locally. that's how I'm used to doing stuff at least.
<imachine> but in your case I take it sources are fetched already patched, even worse, there's a source package for that matter which includes the rules.
<crimsun> imachine: the entire git tree is, using standard terminology, "patched"
<imachine> this is like those dogs with fur over their eyes, you can't say whether they're barking with their arse. at least for me that's how I see it ;)
<superm1> crimsun, are there any known bugs in that script?  It is hanging for both my friend and I when trying to run it following the directions listed on linux-sound.info
<crimsun> superm1: how is it being invoked?
<superm1> bash alsa-info.sh
<imachine> crimsun: where could I see those patches? or do you just dev this stuff in such a fasion, that there simply isn't some general place one could get patches ?
<crimsun> superm1: pastebin.ca may have high latency depending on his source
<imachine> yeah I guess I'll just git your tree
<imachine> and diff locally.
<crimsun> superm1: have him use --no-upload and --debug, then pastebin the file generated in /tmp
<imachine> this is more work than I thought.
<superm1> K
<crimsun> imachine: it's precisely how all git trees that clone from Linus operate
<crimsun> see www.kernel.org/git/
<pygi> imachine, just because ubuntu != arch doesn't mean that it's bad
<imachine> pygi: I never said that.
<pygi> not directly
<imachine> arch is what I like not because it's called 'arch' but because it keeps to the KISS way.
<crimsun> whatever floats your boat.
<imachine> as, in the end, your ways of doing things is probably not far different in consequences, it's mostly a matter of preference.
<imachine> if you can get the same end funcionality, more-less, with a more simplistic apporach however, in my opinion that's better. hence I use arch. and not only because of that, actually I never knew how your development goes on until today ;)
<imachine> so yeah, use whatever you like.
<imachine> anyway I have to look through the files. I think it shouldn't be a lot of work anyway ;)
<imachine> crimsun: thanks for the info so far lad.
<pygi> imachine, let's not discuss arch and it's development :)
<pygi> I know much more about it then you think ^^_
<pygi> ^_^
<imachine> pygi: you're right, let's not.
<imachine> also, I didn't mention how things are done basing on human factor, rather than on how the ways things could be done on it.
<imachine> I'm sure there is plenty of rreasons to not choose arch or whatever other distro. But luckily for that, there is other possibilities.
<pygi> yes
<imachine> ok, tas lads. that's helpful info. have a good one I might drop by sometime if noone minds ;] 
<imachine> laters.
<draik> To everyone who worked on Feisty...
<draik> THANK YOU!
<draik> My laptop works much cleaner and smoother than with Edgy. No complaints about Edgy, mind you. I'm just saying Edgy was great, but Feisty is Excellent!
<draik> Thank you all
<alex_mayorg1> Hello all, any dev can have a look at bug# 121111
<alex_mayorg1> please
<ScottK> alex_mayorga: There aren't likely to be many around on a Sunday afternoon/evening.
<ScottK> Bug #121111
<ubotu> Launchpad bug 121111 in linux-source-2.6.22 "Gutsy Tribe 1 CD don't load on Dell Inspiron 1501" [Medium,Confirmed]  https://launchpad.net/bugs/121111
<alex_mayorga> ScottK, fair enough
<alex_mayorga> I do most of my Ubunting on the weekends though
<ScottK> alex_mayorga: There is also a separate #ubuntu-kernel channel that might work better for you (at a better time).
<alex_mayorga> ScottK, I'll give it a try, thanks
<alex_mayorga> Is there a plan to do an Ubuntu like http://www.puppyos.com/flash-puppy.htm
<Toxicity999> alex_mayorga That's sort of a novelty project, I've seen individuals do it with great success though.
<superm1> alex_mayorga, an ordinary ubuntu install can be installed onto a flash drive or usb hard drive and bootable
<superm1> the only problem is that different systems will refer to it is hd0 or hd1 or hd2 depending on what other things are plugged in
<Mithrandir> it'll usually be hd0 if you boot off it.
<superm1> and depending on what the bios is currently set as the primary drive to boot from
<superm1> Mithrandir, my intel mobo installs grub onto the usb drive thinking its hd1, but really its hd0 unless i change the boot order in the bios
<superm1> in which case its a bit difficult to boot from :)
<Nafallo> hmm
<Nafallo> my home on lvm are named dm-0 :-P
<Nafallo> confusing :-)
<Nafallo> /dev/dm-0 that is
<Daviey> Hi, I have a USB module that i'm trying to write drivers for.  It is a hub & two devices.  It seems it's poorly implemented and it has a broken port 3.  Can i stop the kernel trying to enable the port?
<Daviey> getting repeated; "hub 4-8:1.0: Cannot enable port 3.  Maybe the USB cable is bad?"
#ubuntu-devel 2008-06-16
<Baron1984> http://ubuntuforums.org/showthread.php?p=5194590#post5194590
<pitti> Good morning
<ion_> Hi
<Hobbsee> pitti!
<TheMuso> Morning pitti.
<dholbach> good morning
<pitti> zul: yay, Debian accepted all our openvpn patches; yay bug/patch forwarding, we can sync :)
<ion_> Whee
<dholbach> hey thekorn
<thekorn> good morning dholbach
<dholbach> thekorn: with the new /+text parser bug summaries just contain one character :-)
<pitti> cjwatson: Good morning
<pitti> cjwatson: if you have a moment, your input in bug 220805 would be appreciated
<ubottu> Launchpad bug 220805 in base-installer "when selecting "only free software", I get restricted from the original CD and for -security" [Medium,Fix committed] https://launchpad.net/bugs/220805
<thekorn> dholbach, oh, thanks for letting me know, will check this in a bit
<dholbach> thekorn: http://paste.ubuntu.com/20548/ :-)
 * dholbach hugs thekorn :)
<thekorn> looks like a bad start in this day
<dholbach> thekorn: nah... apart from that the new text connector seems to work fine :)
<dholbach> thekorn: as always top-notch work from you!
<\sh> moins
<\sh> thekorn: the start in this day is great..when I see our bzr commits ;)
<\sh> rainct rockt da house
<thekorn> dholbach, hehe, thanks for motivating me
<thekorn> \sh, morgen
<\sh> thekorn: guten morgen :)
<\sh> damn...I have to catch up with the gtk guys
<\sh> they did awesome work last night
<wgrant> \sh: You probably should wait for the LP API.
<\sh> wgrant: well...to change the backend is not a problem :)
<wgrant> \sh: True, true
<wgrant> The API will hopefully make it much faster.
<\sh> the point is to get this project started...and it's awesome to see how it evolves in only 4 days :)
<dholbach> if the project is only read-only the text connector is the way to go
<\sh> dholbach: it won't :) whatever thekorn is giving us, we'll implement it :)
<superm1> is this eventually intended to make a full out replacement LP interface from a custom GTK app?
<thekorn> dholbach, rev 99 fixes bug.summary and bug.reporter
<dholbach> thekorn: ROCK!
 * dholbach hugs thekorn
 * thekorn hugs dholbach 
<wgrant> I'll be interested to see how the official LP Python lib will compare to p-lp-b.
<thekorn> me too
<wgrant> It would be nice if they released an API at some point so we could poke holes into it first.
<wgrant> Er, the Python API.
<wgrant> Before the whole thing's actually released.
<geser> pitti: Hi, can you look at the buildlog for openocd? http://launchpadlibrarian.net/15228528/buildlog_ubuntu-intrepid-amd64.openocd_0.0%2Br655-1_FAILEDTOBUILD.txt.gz
<geser> pkg-create-dbgsym fails with "objcopy: Unable to recognise the format of the input file `./usr/lib/openocd/ecos/at91eb40a.elf'
<geser> debian/openocd/usr/lib/openocd/ecos/at91eb40a.elf: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
<geser> should pkg-create-dbgsym skip unrecognized files or do I need to add a -X at91eb40a.elf to the dh_strip call?
<cjwatson> pitti: OK, I'll just give it a spin here
<stgraber> morning
<pitti> geser: it uses -X invalidly
<pitti> geser: -X doesn't take a glob, it takes a substring
<geser> oh, overlooked it. Thanks, will fix the package then.
<pitti> geser: I wonder how that builds in Debian
<pitti>         foreach my $f (@{$dh{EXCLUDE}}) {
<pitti>                 return if ($fn=~m/\Q$f\E/);
<pitti>         }
<pitti> that doesn't work with globs either
<pitti> seb128: no intrepid copy love for you in bug 230998; is that fixed upstream in 2.23 already?
<ubottu> Launchpad bug 230998 in evolution "evolution leaves deleted messages strike through" [Low,Fix committed] https://launchpad.net/bugs/230998
<dholbach> thekorn: rev99 works NICEly :)
<thekorn> phew
<pitti> seb128: same question for bug 211604
<ubottu> Launchpad bug 211604 in gnome-applets "trash icon disappears in panel" [Low,Fix committed] https://launchpad.net/bugs/211604
<seb128> pitti: no an dno
<seb128> no and no
<seb128> pitti: will be fixed when next versions are available which should be today
<slangasek> seb128: just got some insight into bug #209520, and sent a follow-up just now
<ubottu> Launchpad bug 209520 in nautilus "SMB error: Unable to mount location when server configured with security=share" [Undecided,Confirmed] https://launchpad.net/bugs/209520
<pitti> seb128: ok, great; thanks
<seb128> slangasek: ah, nice ;-)
<slangasek> seb128: basically, any server that's security=share can only use weak password authentication, which we deliberately disabled in samba for hardy; slightly ahead of upstream, but on the grounds that upstream will do the same in samba 3.2 and it would be unfortunate to have vulnerable default settings for the life of hardy
<seb128> slangasek: oh, so those are non supported configs?
<slangasek> well, that's /my/ position on it with my samba hat on, but I'm willing to be persuaded
<slangasek> I think nautilus/gvfs needs some fixing there regardless
<slangasek> but that's not necessarily 8.04.1 material
<seb128> right
<slangasek> and if there's a sense that enabling the weak client auth is the lesser evil, then that's a quick fix
<seb128> but seeing the number of people concerned by the issue I'm not sure what the right fix would be
<seb128> out of letting them using their config ...
<Mithrandir> slangasek: any particular reason why security=share isn't then just disabled?
<slangasek> Mithrandir: it's a server setting; the servers are not hardy servers, AFAICS
<slangasek> Mithrandir: i.e., there are corresponding defaults on the server side which someone would have to override to get a hardy server in security=share mode
<Mithrandir> slangasek: oh, ok, so you're talking about the client.  Ack.
<slangasek> yeppers
<slangasek> and when the client is nautilus+gvfs, the user gets no feedback about why it failed... :)
<pitti> soren: the virt-manager bugs of the hardy-updates version are still open in intrepid; can you please apply the fixes to intrepid, too, and upload?
<slangasek> anyway, with that bug triaged, I'm off to bed
<seb128> slangasek: thanks for your work on that, good to have a clue about the issue
<seb128> I'm not convinced yet that making those connection fail on purpose is a good idea though
<slangasek> seb128: n/p.  feel free to discuss with pitti and whoever else about whether we should relax this setting for hardy
<seb128> but I don't really have an idea about the number of broken configuration which are around
<seb128> will do
<slangasek> and I'll catch up in the morning :)
 * pitti <- no clue about samba :(
<slangasek> pitti: oh, well, most of what you need to know can be learned from scrollback + the last comments in the bug log ;)
<seb128> pitti: read the current comment on https://launchpad.net/bugs/209520 and tell me what your gut feeling is about this option ;-)
<slangasek> pitti: the only missing piece is "how easy is it to break this password mechanism?"
<ubottu> Launchpad bug 209520 in nautilus "SMB error: Unable to mount location when server configured with security=share" [Undecided,Confirmed]
<pitti> seb128: my gut feeling is that there should be a dialog box which explains the issue, instead of silently failing; WDYT?
<seb128> pitti: right, that's for sure
<slangasek> oh I agree, but I'm not sure that we get a proper feedback channel from libsmbclient for this :/
<seb128> pitti: the question is rather to know if it should fail or not by default
<pitti> so AFAICS it affects servers which are either still running win98, or badly configured samba, right?
<seb128> I'm not sure how many users know that those are "badly configured"
<pitti> IMHO disabling LANMAN by default makes sense; if it gets explained properly, then these servers can be reconfigured
<seb128> ie, how many users have a similar config on a local network which worked until now and breaks in hardy
<pitti> did previous Ubuntu releases configure samba with LANMAN by default?
<seb128> dunno but it was not restricting access to those
<pitti> i. e. will default hardy client fail to connect to default gutsy/dapper samba server?
<slangasek> pitti: not all of them.  Win9x "servers" aren't capable of doing anything stronger than Lanman; likewise, any ancient Unix NASen based on Samba 2.x
<slangasek> pitti: previous Ubuntu releases allowed lanman by default
<seb128> I would argue that we should still allow those
<pitti> slangasek: right, but I mean s/allowed/& only/
<seb128> we will not fix the world by confusing users who try to use broken servers
<seb128> servers they can use from other distros and gutsy
<slangasek> pitti: uh... sorry, I think we're talking past each other, none of the lines of yours I was replying to had "allowed" in them and I'm now a little lost :)
<slangasek> I should probably just go to bed ;)
<seb128> we just get bad press than hardy can't connect to working servers at the moment where other distro can, admitelly that would be better if nautilus was displaying a proper error but I'm still not sure it would make those users happy
<seb128> especially that often users don't have control over the servers they are trying to use
<pitti> slangasek: I meant: if I apt-get install samba on dapper on server A, and install hardy on client B, will B fail to connect to A?
<pitti> i. e. what's the default setting in dapper?
<slangasek> seb128: note that agreeing to negotiate lanman auth exposes the user to a security risk, which is more of a problem than just not wanting random servers to not use weak auth...
<pitti> seb128: I tend to agree (FSVO "working server" :) )
<pitti> with the current explanation, these servers are not really working flawlessly, AFAIUI? (because they are a password stealing trap)
<slangasek> pitti: I would have to check where in the history dapper's version of samba falls, but I believe that it should do encrypted passwords by default, and therefore work ok with hardy clients
<seb128> slangasek: I would argue that it depends of the context
<seb128> slangasek: people having 3 boxes on a local lan probably don't care about that, they just want their nas and server working as they used to
<seb128> but in corporate environments you might want better security
<slangasek> pitti: encrypted passwords are enabled by default in dapper, so hardy clients are perfectly compatible
<pitti> slangasek: right, that was my primary concern; i. e. does it fail OOTB, or do you need to manually (mis-)configure it to fail
<slangasek> seb128: well, I definitely disagree, but I recuse myself from this decision because I implemented this change in defaults myself with my maintainer hat on :)
<pitti> seb128: in this case I still lean towards a better error message; people with broken ancient NASes can still change smb.conf to re-enable LANMAN again
<seb128> slangasek: anyway no hurry, I'll speak with some other people about it to collect opinions, you should go to bed ;-)
<pitti> and with modern Windows and supported distros it shouldn't be a problem either?
<slangasek> right, 'night folks :-)
<pitti> slangasek: sleep well! thanks
<seb128> night slangasek
<seb128> and thank you for your work on the issue ;-)
<seb128> pitti: right, it just means new strings and it's not clear than libsmbclient has an api which makes it easy to know that the issue is due to this
<seb128> pitti: ie, might not be easy to sru in hardy
<pitti> right; might be necessary to grep it out of the log, or so?
<pitti> but I can't believe that it has such a poor error reporting API?
<seb128> pitti: not sure, I'm not a samba guy, now that we know what the issue is I'll try to have a look though
<pitti> mvo: can you please apply bug 184238 to intrepid?
<ubottu> Launchpad bug 184238 in transmission "Menu entry should be named "Transmission BitTorrent Client" Instead of only the unclear "Transmission"" [Medium,In progress] https://launchpad.net/bugs/184238
<mvo> pitti: sure
<mvo> pitti: its already fixed, forgot to update the bug :(
<pitti> mvo: I didn't see it in the changelog; thanks
<mvo> my bad, it was fixed upstream
<mvo> and I forgot to add that to the changelog
<mvo> when I did the merge
<pitti> doko_: is bug 211309 actually an issue in sun-java{5,6}? If not, can the tasks be closed?
<ubottu> Launchpad bug 211309 in icedtea-gcjwebplugin "[hardy] Java plugin not registered in Firefox 2" [Undecided,Fix committed] https://launchpad.net/bugs/211309
<pitti> soren: same for virtinst (bug 221746)
<ubottu> Launchpad bug 221746 in virtinst "Assigning storage space fails if acceleration enabled" [High,Fix committed] https://launchpad.net/bugs/221746
<asac> pitti: we dont forward bugs that are incomplete :)
<asac> jcastro: ^^
<pitti> asac: sometimes they become incomplete after forwarding
<pitti> (happens to me quite often, at least); i. e. upstream needs further info, etc.
<asac> pitti: well ... that discussion is usually done in upstream tracker, but the ubuntu task is mostly static after that point
<asac> e.g. the upstream task would be "incomplete", while the ubuntu one stays at whatever state it was before
<asac> makes sense or are you always changing the ubuntu task as well in-sync with the upstream status?
<persia> If upstream needs information and the person coordinating the bug doesn't have it, using the Ubuntu bug to ask for it (and setting "Incomplete") makes sense.
<asac> persia: point is that the ubuntu task is used to determine whether a bug was forwarded upstream in the +upstreamreport
<asac> persia: i dont think that using the ubuntu task is a reliable way to determine that ... better look at the upstream status (e.g. is upstream bug "incomplete", "confirmed" or whatever)
<seb128> asac: better to look if there is an upstream watch available
<seb128> the status is not revelant there
<asac> seb128: right. thats what i mean
<asac> seb128: yeah, but still the
<asac> +upstreamreport currently only uses Triaged ;)
<asac> everything else is forgotten about
<seb128> I know, most of the GNOME stats are broken due to that
<asac> https://edge.launchpad.net/ubuntu/+upstreamreport
<asac> seb128: well ... at least you are using Triaged for forwarded bugs ... which i am not ;)
<seb128> because we have lot of confirmed bugs forwarded from the time before triaged
<asac> seb128: so you are far better off atm :)
<seb128> right ;-)
<asac> seb128: right. in the past mozillateam moved forwarded bugs that were on track upstream to "in progress" :)
<asac> jcastro: so read above: just use the watch count for open bugs to get the right count for forwarded bugs
<guysoft42> hello all, i have a heavily modified system of ubuntu that i want to make bootable from a livecd. is that possible in any way?
<pitti> Riddell: is bug 194474 still an issue in intrepid?
<ubottu> Launchpad bug 194474 in kdebase "[hardy] kded in loop (100%CPU) when using 'mount automatically'" [Undecided,In progress] https://launchpad.net/bugs/194474
<Riddell> pitti: no, intrepid uses kde 4 so different codebase
<pitti> Riddell: thanks
<pitti> tkamppeter: is bug 219999 an issue in intrepid? if 4.0 fixes it, pleaes close the task
<ubottu> Launchpad bug 219999 in foomatic-filters "[Hardy SRU request] foomatic-rip does not handle enumerated-choice options with choices "True" and "False" correctly, leading to Duplex on most Ricoh printers not working" [High,Fix released] https://launchpad.net/bugs/219999
<pitti> asac: can you please upload epiphany-browser 2.22 to intrepid? (bug 236116); I can copy-package epy-extensions, but e-browser differs in hardy and intrepid
<ubottu> Launchpad bug 236116 in epiphany-browser "new upstream 2.22.2 release" [Undecided,In progress] https://launchpad.net/bugs/236116
<zul> good morning
<pitti> hey zul
<asac> pitti: ok looking
<cjwatson> pitti: do you have a dhcp3 merge in progress? I need it to build d-i
<pitti> cjwatson: only as far as "need to get to it RSN", if SRUs ever leave me some time :)
<pitti> cjwatson: I just finished SRUs, though
<pitti> so I can get to it after lunch
<pitti> cjwatson: oh, we need 3.1 for d-i now?
<cjwatson> yeah, netcfg's dhclient-script got merged into dhcp3-client-udeb so now netcfg requires the version where it was merged
<pitti> cjwatson: ok, thanks for the poke; queued for the afteroon
<pitti> afternoon, too
<cjwatson> pitti: thanks, appreciated
<ScottK> doko: It look likely that pyogg can be sync'ed now.  Do you mind if I look after it (you touched it last)?
<ScottK> look/looks
<doko> ScottK, not at all. thanks for doing that
<ScottK> No problem.
<jcastro> asac: so in your opinion it should be counting watches, not a certain status?
<persia> Maybe count != (Invalid | Won't Fix)?
<jcastro> persia: that sounds reasonable to me
<seb128> jcastro: what the status changes to the fact that there is an upstream bug corresponding to the launchpad one?
<jcastro> I don't understand your question
<seb128> jcastro: why should the status do a difference there?
<asac> jcastro: i think what matters for upstream is an absolute number. not something that measures the ratio
<jcastro> seb128: that's just what we started with.
<jcastro> I think keeping track of the watches themselves makes more sense though
<seb128> ok, cool
<jcastro> asac: well, I think having a ratio is a good thing to track as well
<jcastro> asac: we know that number will never be 100%
<jcastro> seb128: the report is still very much alpha, which is why I want to make sure we're measuring what you guys are doing
<jcastro> and adjusting the report accordingly
<jcastro> it shouldn't be "your numbers look weird, you are doing something wrong,"
<jcastro> it should be "your numbers look weird, are we measuring the right thing?"
<seb128> jcastro: right, and the reply is that you are not, we have hundred of GNOME bugs forwarded upstream which are "confirmed" because they have been sent upstream when launchpad had no triaged for example
<jcastro> yep
<freeflying_> when I try to merge fbreader from sid, I found it build-deps on a package dosen't exist in ubuntu, so what the workflow for such a case, btw, fbreader is in main
<persia> freeflying_: On which package does it depend?
<asac_> jcastro: sorry. reconnect
<freeflying_> persia: liblinebreak-dev
<persia> freeflying_: https://launchpad.net/ubuntu/+source/liblinebreak ?
<jcastro> asac_: http://paste2.org/p/39840
<asac_> jcastro: right
<persia> freeflying_: Alternately https://launchpad.net/ubuntu/intrepid/+package/liblinebreak-dev or https://launchpad.net/ubuntu/+source/liblinebreak/0.9.6-5
<persia> It probably needs a MainInclusionReport for the merge
<asac_> jcastro: anyway, i think the problem with the ratio is that its hard to tell for sure what bugs should be forwarded. especially since we have no real common usage of bug statusses
<freeflying_> persia: wired, my latest intrepid chroot can't find it
<asac_> stati ;)
<jcastro> asac_: yeah each team does it different.
<jcastro> asac_: that's the reason I sent you guys that mail
<persia> freeflying_: it's in universe only: things in main need to build against main, which is likely the issue you see.
<freeflying_> persia: thanks for clarify this for me :)
<seb128> jcastro: to who did you send mails?
<jcastro> seb128: calc and asac so far, since their packages showed up obviously wrong in the report.
<seb128> jcastro: ok, just checking if I should have received a mail or not
<asac_> jcastro: ok. i think the ratio watch vs. upstream task without watch could be used as something that would fit in our new bug workflow
<jcastro> seb128: I am planning on bugging you guys as a group during the sprint
<seb128> alright
<jcastro> seb128: your columns are still mostly green so I'm going after the ones that look bad first. :)
<seb128> jcastro: right but the numbers are far to be as good as they should :-p
<jcastro> seb128: right.
<seb128> since half of the forwarded bugs are "confirmed" and not counted ;-)
<jcastro> yeah
<jcastro> the thing is that kiko wants confirmed to go away and is specifically measuring triaged instead
<jcastro> but that's a different argument, heh
<asac_> jcastro: the ubuntu state makes no sense. how about what i just proposed: compare upstream task without watch with upstream task with watch?
<asac_> according to launchpad "advanced search" adding an empty upstream task is similar to expressing that this needs to be forwarded
<jcastro> asac_: yeah I have that down here in my notes to ask kiko about it (he actually implements the report)
<asac_> jcastro: ok cool
<seb128> asac_: almost nobody is bothering adding empty upstream tasks for the bugs that need to be forwarded though
<asac_> seb128: well. thats the official mean to express that though :) ... so if there is something you can use to measure that then its that
<asac_> seb128: and i will try to make more use of that in future
<seb128> I would rather like a setting the other way
<seb128> because 99% of the GNOME bugs we receive are upstream one
<asac_> seb128: which way?
<seb128> and I would prefer to flag 1% as distro bugs rather than 99% as upstream bugs
<seb128> default to "this is a bug in the software"
<asac_> seb128: so you want to have an empty upstream task opened by default?
<seb128> and having a way to express the bug is rather an ubuntu one
<seb128> not sure if the empty upstream task is the right semantic there
<seb128> but yeah, I would like to have things considered as upstream issues by default
<asac_> seb128: you could do your "flag 1% as distro" by setting the empty upstream task to "invalid"
<seb128> but that's what they are most of the time
<seb128> right
<jcastro> that's an interesting way to look at it
<seb128> jcastro: we are a distribution so ideally we just distribute upstream code and have no ubuntu specific issues ;-)
<jcastro> yep
<ScottK> OTOH it doesn't take so many packaging bugs forwarded upstream before we lose credibility.
<jcastro> well, the people forwarding the bug would be the same person who is doing it now
<asac_> ScottK: why would that happen if we add an empty upstream task by default?
<asac_> why would that happen more frequently ?
<ScottK> Just saying that we need to be thoughtful about shipping all bugs upstream.
<seb128> nobody speak about doing that
<ScottK> OK.  That's how I read "I would like to have things considered as upstream issues by default".
<ScottK> Nevermind then.
<jcastro> ScottK: he means an empty task thing on launchpad
<ScottK> Ah.
<seb128> that would be rather a workflow change
<jcastro> ScottK: though, we've had brainstorming sessions on how to make it easier to file bugs in an upstream bugzilla and yes, it can be scary sounding
<seb128> rather than having to open empty upstream tasks for all the bugs you would just have to reject some for bugs which are distro specific
<asac_> well, we have to ensure that triagers really know that you are not supposed to forward anything that is incomplete
<jcastro> ^^^^
<seb128> ideally only triaged bugs should be forwarded anyway
<seb128> and by the time they are triaged the upstream task should be closed if that's a distro specific bug
<asac_> seb128: so we could auto create empty upstream task once a bug goes to triaged \o/
<jcastro> asac_: but you said you're not using triaged
<seb128> would work for me if you have a box saying "distro bug"
<asac_> jcastro: thats a historical thing
<asac_> jcastro: i dont want to do two things just to indicate that a bug is ready to go up
<jcastro> asac_: afaik confirmed is eventually going away right?
<asac_> so either set to triaged, or use launchpad upstream task. i use launchpad upstream task :)
<seb128> jcastro: why should it?
<asac_> because thats what the advanced search page suggests imo
<jcastro> seb128: dunno, that's what kiko wants
<seb128> he's the one who insisted to adding the extra confirmed and triaged thing in the first place no?
<jcastro> seb128: clearly there needs to be some kind of discussion because I haven't gotten any solid yes or no answer from anyone
<seb128> alright
<jcastro> I'll bring it up to heno because if they are getting rid of triaged then it might make sense to do it sooner rather than later in the cycle
<pitti> zul: hm, the apache merge log is confusing; it doesn't list the remaining changes from Debian, but the changes in that upload
<pitti> zul: do we still actually have a delta? AFAIR, infinity and Mithrandir went to great effort to synchronize the package in hardy
<pitti> (gutsy and feisty, too)
<zul> pitti: no we dont, I should have synced it
<freeflying_> who can have a look of this bug #239069
<freeflying_> #239069
<Pici> The bot is currently undergoing a server upgrade ;)
<masood> hi everybody
<masood> i'm a beginner here.. can someone tell me how team channel are different from support ones?
<freeflying_> its really a security relate bug
<Pici> masood: Ubuntu doesnt come together magically, these channels are here for planning, bug fixing and development discussion to go on :)
<pitti> freeflying_: how is that a security issue?
<freeflying_> pitti: just wonder :)
<masood> pici: i figured that out a while ago, I'm just not sure in which channel should I ask my question :D
<Pici> masood: Well, I'd start in #ubuntu and hope they point you in the right direction :)
<foka> LP:239069 has become a rather high profile issue in the Chinese GNU/Linux community.
<foka> Or rather, controversial issue.
<foka> BenC1, Hi!
<foka> It started here: http://bbs.chinaunix.net/viewthread.php?tid=1154718
<freeflying_> foka: no one can read Chinese here, besides you and me :)
<foka> A local developer (of a local Chinese distribution) began complaining that there are too many blind fans/sheep of Ubuntu
<foka> freeflying_, Right, but just to offer some perspective.
<masood> pici: k. thanks for the help ;)
<foka> I guess there are indeed some over-zealous Chinese Ubuntu fans, which is both good and bad...
<freeflying_> foka: lets forget the qurrel, come back to the bug itself :)
<foka> Anyhow, that certain developer (cjacker) noticed that bug as a proof to those "mindless Ubuntu fans" that Ubuntu core isn't as good as it seems, and claiming that this bug is worse than a kernel panic.
<BenC> foka: hey
<foka> freeflying_, You're right, but just again, I'm offering more background info as to why it may be good PR to investigate this bug and get it fixed ASAP.
<foka> freeflying_ is right in saying "let's forget about the quarrel and focus on the bug itself" though.
<tkamppeter> pitti, I have closed bug 219999 now. Thanks for remombering me.
<pitti> tkamppeter: thanks
<foka> But it is a somewhat perplexing and evasive bug, as not all people can reproduce it yet.
<foka> A small bit of information that isn't reflected in the Launchpad bug report yet:  cjacker mentions it could be related to a particular version of libc6 and bash and wtmp/utmp, i.e. hinting an upstream issue.  (though cjacker's main point is that Ubuntu's QA is slightly insufficient)
<ubottu> Launchpad bug 219999 in foomatic-filters "[Hardy SRU request] foomatic-rip does not handle enumerated-choice options with choices "True" and "False" correctly, leading to Duplex on most Ricoh printers not working" [High,Fix released] https://launchpad.net/bugs/219999
<foka> Let me try to go through the Chinese discussion more thoroughly and try to pick out more technical info.
<kirkland`> pitti: hey, i had another idea, wrt to ecryptfs and mounting/unmounting
<pitti> hi kirkland`; oh?
<kirkland`> pitti: another option would be to create a group for ecryptfs users (say, ecryptfs), and allow those users sudo access to mount and unmount commands?  or do you think that would give too much access to those two commands?
<pitti> kirkland`: we are currently trying to abolish all groups which control device/privilege access, so I don't like this at all
<kirkland`> pitti: gotcha, okay
<pitti> kirkland`: apart from this, unlimited mount == root
<kirkland`> pitti: okay, i'll work on the custom unmount more today
<pitti> kirkland`: thus, you could just as well work as root in the first place
<pitti> ogra: do you still remember dhcp3's revert-next-server.dpatch patch? what is it good for? the code changed in 3.1.1, so the patch doesn't apply any more
<ogra> i can take a look
<pitti> ogra: I guess it broke LTSP somehow?
<ogra> it breaks old ltsp configs and is totally useless for standalone servers
<pitti> ogra: I would disable it for now (for the merge), is that ok for you?
<ogra> sure, i can merge it back in later
<ogra> lets get that CD out :)
<pitti> or, rather, develop a new patch (this time with upstream preferably)
<ogra> upstream refuses to take that change
<ogra> we had long discussions
<ogra> its already over 2 years old
<jsgotangco> jcastro: do you rememer ColinCharlesQueue
<jsgotangco> remember
<jcastro> jsgotangco: yeah, he was in sydney
<jsgotangco> jcastro: yeah he's currently in Manila and meeting up with him tomorrow. I think Sun/MySQL has an event here heh, just wondering if you still remember him
<jcastro> jsgotangco: yeah, say hi for me please.
<jcastro> jsgotangco: he was one of the editors that you had to have approve your spec to get it past the Drafting stage
 * jcastro remembers that not being very fun. :p
<jsgotangco> lol yeah
<jsgotangco> old skool
<DktrKranz> pitti, since you sponsored last merge, any chance to look at scons (bug #226783) ? Current version causes some FTBFS with some packages in the archives.
<ubottu> Launchpad bug 226783 in scons "Merge scons 0.98.5-1 (main) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/226783
<pitti> DktrKranz: not right now, but later/tomorrow; I assigned it to me
<DktrKranz> pitti: thanks.
<pep> Hi! I will be attending an install party the 5th of July, that was organised thinking that 8.04.1 will be out by then (it was planned 3rd july on hardy release schedule). Now on intrepid schedule I see it will be at the soonest the 10th. Will there be a stable release candidate out by then? Stable enough to install it on user machines?
<pep> If not we will make our own .iso simply out of an up-to-date hardy... but I was wondering if we could not already install the 8.04.1rc...
<Kl4m> The schedule says July 3rd
<pep> Kl4m: that's what I thought too, when someone pointed out to me that this one said july 10th... https://wiki.ubuntu.com/IntrepidReleaseSchedule
<Kl4m> Hmm https://wiki.ubuntu.com/HardyReleaseSchedule says 3
<pep> jupp
<pep> you see we're wondering what to do, if it will be out by july 5th or not....
<pep> if it will, then no problem, if not, then my question is: will there be a stable rc? or do you think it is safe to use a working daily build? or just modify an iso to make it up-to-date?
<cjwatson> I would expect that daily builds would be safe to use by then, even if 8.04.1 isn't out
<cjwatson> it would likely be waiting for testing and certification to complete
<cjwatson> you won't gain much by building your own, and that's more likely to create problems than not, I expect
<pep`> back, sorry, the internet connection is bad here :( last phrase I got was "<cjwatson> you won't gain much by building your own, and that's more likely to create problems than not, I expect"
<pep`> thanks for the info
<pep`> we already did this for a previous install party and it worked out great, but it sure would be easier to use .1 directly...
<_MMA_> pep: That was the last message from cwatson.
<pep> thank you!
<pep> do you think the intrepid release schedule ismore trustworthy? or rather the hardy one? because I am preparing an email to the LUG to inform them of this problem we might have..
<pep> Who must I contact or where must I ask to have the best possible opinion about the release of 8.04.1 ?
<cjwatson> pep: preferably, don't ask every ten minutes ;-)
<cjwatson> pep: at least the end of the intrepid release schedule is rock-solid, but early milestones are always fluid depending on what can be made to work
<pep> ah no, I'm just wondering if there is a channel dedicated to the development of hardy LTS...
<cjwatson> you are in it
<pep> ok ;)
<cjwatson> of course it's also dedicated to other things
<pep> then I can safely assume and tell my LUG that it will not be out by 5th July I suppose. Thank you ;)
<cjwatson> huh? when did I say that?
<pep> oh, ok... so it's not sure...
<cjwatson> IF it is not out by 5th July, it will likely just be waiting for testing to complete
<cjwatson> but the current schedule has it due to release on 3rd July
<pep> Ah, ok thank you, that was what I wanted to know, which schedule to trust.
<cjwatson> there is only one relevant schedule ...
<cjwatson> you definitely don't want to use an early milestone of intrepid for widespread installation
<pep> ok :)
<cjwatson> it's meant for experienced testers only at this stage
<cjwatson> (and developers, obviously)
<pep> hehe, yes I understand
<pitti> ogra: ah, ignore me; it still applies
<pep> thanks for the advice, have a nice day.
<mvo> Riddell: what package has dcopidl nowdays with kde4?
<norsetto> asac: I have had no reply to my comment on the gnome-mplayer ITP (dbug 415381). How do you want to proceed?
<asac> norsetto: just upload ;)
<asac> norsetto: take ownership -> upload
<asac> debian bug 415381
<ubottu> Debian bug 415381 in gnome-mplayer "ITP: gnome-mplayer - a simple GUI for MPlayer" [Wishlist,Open] http://bugs.debian.org/415381
<norsetto> asac: err ... upload to where?
<asac> norsetto: what email do you plan to use for debian package contact?
<norsetto> asac: the usual norsetto@ubuntu.com
<asac> norsetto: ok i set owner to you dropping a mail that I will upload your package if we dont get a veto in a few days
<norsetto> asac: ok, thx
<Riddell> mvo: kde 4 doesn't use dcpo
<Riddell> dcop
<mvo> Riddell: aha, thanks
<Riddell> jdstrand, kees: so got those MIRs scheduled in for sometime soon?
<Riddell> pitti: not able to look at qca2 MIR?
<pitti> still doing the dhcp3 merge requested by Colin (gosh, taking 4 hours already)
<jdstrand> Riddell: I will be looking at chmlib soon yes. kees has the other one
<calc> anyone know of a console utility that can read info from a truetype font and output info about it?
 * calc used to a have a script to usefully rename ttf fonts but can't find it
<Riddell> jdstrand: what about libzip?
<jdstrand> Riddell: I just saw that today-- kees or I will pick it up
<slangasek> pitti: did you and seb128 get anywhere on the question of lanman client enabling?
<pitti> slangasek: I think we should keep it disabled and provide a better error message, since AFAIUI it does not affect a majority of users, and in the affected cases the server should really be updated
<slangasek> well, providing a better error message is a lot harder than re-enabling it would be; does that change your opinion?
<slangasek> (the libsmbclient API is intended to be POSIX-like, so no extended samba error messages are available without capturing debug logs of some kind)
<pitti> cjwatson: hm, I need to leave to Taekwondo soon; I'm afraid I have to continue this dhcp3 mega-merge tomorrow morning
<pitti> slangasek: hm; I'm just afraid of endlessly proliferating such setups
<pitti> but that's just gut feeling; I don't know much about Samba for an objective judgement
<slangasek> well, due to bug #1, I'm not sure that Ubuntu is a major factor yet in whether it's practical for sites to deploy such servers :)
<ubottu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
 * slangasek smirks at ubottu u
<pitti> slangasek: OTOH, when we enable it, there will be no encouragement (or even knowledge) about it, so that it will stay that way forever?
<slangasek> pitti: fwiw, I found the upstream thread that discusses how these default settings have been changed on the Windows side; it sounds like Vista Enterprise is even more strict than we are currently: http://lists.samba.org/archive/samba-technical/2007-February/051421.html
<slangasek> pitti: well, we could leave it disabled in intrepid maybe, and hope that time takes care of things for us? :)
<pitti> slangasek: I can live with that
<pitti> bye everyone
<slangasek> pitti: ah, I need more direction than "I can live with that" :-)  Do you want me to prepare a samba SRU that reverts this change?
<\sh> hmm...riddell and I are missing dl.so from python2.5 on amd64... gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I../Include build/temp.linux-i686-2.5/build/buildd/python2.5-2.5.2/Modules/dlmodule.o -o build/lib.linux-i686-2.5/dl.so is missing somehow from the amd64 build :)
<SynthroidMan> http://synthroid.co.uk/
<kees> Riddell: I already looked at openbabel (bug 236051) and assigned it back to you after including the results of my audit.
<ubottu> Launchpad bug 236051 in openbabel "main inclusion review for openbabel" [Undecided,Incomplete] https://launchpad.net/bugs/236051
<kees> Riddell: short version: I can't recommend it for main.
<Riddell> kees: saw that thanks, upstream say they're looking into your comments
<kees> Riddell: okay, cool.
<paulproteus> I'm the Debian maintainer of the alpine package, and I see this bug in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/alpine/+bug/120735
<ubottu> Launchpad bug 120735 in alpine "Alpine 0.82+dfsg-5 seg faults when attempting to view certain messages with attachments" [Undecided,New]
<paulproteus> What is the right way for me to handle it?  alpine is in universe, fwiw; this bug was fixed a year ago but the bug affects Ubuntu 7.04.
<paulproteus> Hmm, I'm told: " You are not the bug assignee nor the maintainer of alpine (Ubuntu), and therefore cannot edit this bug's status. "
<DktrKranz> paulproteus, you may want to ask for a stable release update (see https://wiki.ubuntu.com/SRU). Also, in order to edit bug status, you need to login in Launchpad.
<paulproteus> I don't think it's that critical, DktrKranz.  (I'll see about logging in now.)
<paulproteus> Should I just leave a note telling the reporter to upgrade and mark it as invalid?
<ScottK> paulproteus: It's fixed in releases later than Feisty ?
<DktrKranz> You should mark it as fix released
<paulproteus> ScottK, Bingo.
<ScottK> paulproteus: It's as DktrKranz says then.  It should be fix released.  I'll mark it.
<paulproteus> I'll mark it, ScottK.
<paulproteus> I need the practice. (-:
<ScottK> paulproteus: I already did.  Sorry.
 * paulproteus shrugs, I'll find another then. (-:
<DktrKranz> paulproteus, you have tree more to practice :)
<paulproteus> DktrKranz, Pending feedback from the submitter. (-:
<psyke83> hi asac, can I ask you a quick question re: Firefox? I was told you've got experience with the code. I'm working with Cory on UbuntuStudio's dark theme, and I had an idea re: Firefox, but I'm not sure if it's feasible. I was wondering if it's possible to force Firefox to use native widgets only for rendering of websites (not the actual interface of Firefox such as menus, popup windows, toolbars and options windows)?
<psyke83> asac, my idea is to force Firefox to render widgets using Human-Murrine as dark widgets simply look out of place on 95% of websites, who often make bad decisions re: colour choices in style sheets, etc.
<munckfish> cjwatson: hi you got a minute?
<cjwatson> munckfish: sure
<munckfish> I'm still trying to get the series/milestones setup on LP for PS3
<munckfish> Tiago made me Driver
<munckfish> but that still hasn't given me the "Add a series" link
<munckfish> do you know what's needed?
<cjwatson> munckfish: should be "Register a series", https://launchpad.net/ubuntu-ps3-port/+addseries
<cjwatson> blink, why did he make specifically you driver rather than a team?
<munckfish> cjwatson: we were trying to work out how to give the required perms
<munckfish> the doc on help.lp.net said I had to be either driver or registrant
<munckfish> but seems not
<munckfish> can you fix it?
<munckfish> as in make the team driver instead
<cjwatson> I can't fix it
<cjwatson> I don't have any kind of special launchpad god-mode permissions
<munckfish> cjwatson: I am forbidden to access that page
<cjwatson> give me a minute, I'm checking the code (since I can at least do that)
<munckfish> cjwatson: I know but I thought you had better perms than me on the project page
<munckfish> cjwatson: wow insider stuff, cewl
<cjwatson> don't see how, Tiago's registrant, you're driver ...
<cjwatson> munckfish: Tiago should be able to do it. I think he just missed it
<cjwatson> munckfish: give him the URL I gave you
<cjwatson> munckfish: or else get him to make some suitable team registrant so that you can be in the registrant group too
<munckfish> cjwatson: ok I'm getting some help on #launchpad now
<cjwatson> adding series to products requires either "registry experts" (a special team), the registrant, or a Launchpad admin
<munckfish> cjwatson: I understand
<munckfish> I think the registrant should be a team in that case
<cjwatson> munckfish: that is often appropriate, yes
<cjwatson> please make sure a bug's filed about the documentation saying that you need to be either driver or registrant - it doesn't match the code, so one or the other is wrong
<jcole> is the latest dri "enabled" in ubuntu kernels -> http://dri.freedesktop.org/wiki/Building
<jcole> or does one need to follow that guide to get the latest dri
<kirkland> I'm calling the umount() system call in a C program.  It seems that /proc/mounts is updated properly, but not /etc/mtab ...  What needs to happen such that /etc/mtab is sync'd and sees the changes?
<slangasek> you need to edit /etc/mtab in your C program... :)
<kirkland> slangasek: oh, seriously?
<slangasek> the functions setmntent(), getmntent(), and addmntent() will help
<kirkland> slangasek: cool, thanks.
<slangasek> why calling umount() directly instead of via the umount program, though?
<kirkland> slangasek: I need to create a setuid program to umount as a non-root user
<slangasek> presumably this is an suid helper that has already done the necessary security checks, so you could safely call /bin/umount instead of umount()
<kirkland> slangasek: being written from scratch, i can go any route that is recommended
<kirkland> slangasek: this is back to solving last week's problem regarding pam_mount's inability to umount a filesystem on ssh logout
<slangasek> kirkland: well, my assumption is that your helper has already done the necessary security checks in your helper - this assumption needs to hold true whether you call umount() or /bin/umount :)
<kirkland> slangasek: seems that umount supports such "helper" programs
<kirkland> slangasek: ;-)
<kirkland> slangasek: but your suggestion of calling out to /bin/umount is a good one, as that would take care of /etc/mtab for me, right?
<slangasek> kirkland: so, with that assumption in place, you might as well just setuid(0) and invoke /bin/umount, yes, since that will take care of all the niceties for you
<slangasek> as for as umount supporting "helper" programs, those are for per-filesystem handlers
<slangasek> mount/umount already know how to handle this filesystem type, right?
<kirkland> slangasek: yes
<slangasek> yeah - so calling /bin/umount as root for the dirty work is better
<kirkland> slangasek: and "security checks"; user owns the mountpoint, perhaps a check of open fh's on that mountpoint....  anything else?
<slangasek> I don't think you need to check for open fds, /bin/mount will do that for you
<kirkland> slangasek: okay, good
<slangasek> is there a corresponding mount wrapper?
<kees> what's the method for checking mountpoint ownership?  aren't those overridden by the underlying filesystems's perms?
<slangasek> I'm wondering if the mtab entry for the mount should somehow record that the user in question is the one who /did/ the mounting
<slangasek> kees: exactly
<kirkland> slangasek: pam_mount actually works well mounting the FS, so I was just going to "fix" the unmounting with a custom unmount setuid program
<kirkland> kees: i was thinking access()
<kirkland> kees: well, maybe not....
<slangasek> access() will only tell you the ownership of the root node of the filesystem, not of the mountpoint
<slangasek> i.e., in order to determine the ownership of the mountpoint, this will have to be recorded somewhere at mount time
<slangasek> (with /etc/mtab being the obvious place)
<kirkland> slangasek: kees: what about checking the ownership of the device?
<kirkland> slangasek: kees: what we're dealing with here is mounting /home/user/.Private onto /home/user/Private
<kirkland> slangasek: kees: the intention is for user:user to own both of those, permed 700 when mounted, and 500 when not mounted
<slangasek> checking the ownership of the device is also race-y
<slangasek> what do you do if the user *removes* /home/user/.Private, prior to unmounting?
<kirkland> slangasek: hmm, well, they've hosed their underlying encrypted data in that case
<slangasek> sure
<slangasek> but why should that leave them unable to unmount it? :)
<slangasek> actually, as long as it's mounted, they haven't hosed it because the kernel still has a reference and they'll still be able to access it...
<kirkland> slangasek: well, additionally, i'd also expect that the top node of the mounted filesystem to match ownership
<slangasek> but that's not an argument in support of breaking the unmount semantics IMHO :)
<kirkland> slangasek: ie, a "Private" directory should only be mounted/unmounted/read/written/listed by the user owning it
<slangasek> these are all heuristics that you're trying to use to answer the question, "is the mount point specified here one that was mounted as part of the user "private data" implementation?"
<slangasek> the best way to answer that question without heuristics, AFAICS, is to /tag/ the mount at the time it's done, with this info
<kirkland> slangasek: okay, so this is what's currently written to mtab:
<kirkland> /home/kirkland/.Private.ecryptfs /home/kirkland/Private ecryptfs rw,noexec,nosuid,nodev,ecryptfs_sig=5b25c24a4bd3ed6e,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,user=kirkland 0 0
<kirkland> slangasek: the user=kirkland part is there because it's currently an entry in /etc/fstab
<kirkland> slangasek: and that's what currently allows me to mount/unmount as non-root user
<slangasek> kees: do you know if we have any raciness involved in reading /etc/mtab?  is there a standard way to lock the mtab so that we're assured to not race against a different mount being done at the same time as the unmount on the same mount point?
<slangasek> kirkland: ummm, what's the "user=kirkland"?
<kirkland> slangasek: pitti has suggested that i remove the dependency on reading/writing /etc/fstab
<slangasek> oh, you just answered that question
<slangasek> ho-hum
<slangasek> :)
 * kirkland types to slow for slangasek :-)
<kirkland> slangasek: i can easily keep that user=kirkland bit as part of the custom mount setup in pam_mount
<kirkland> slangasek: perhaps that gets us what we need there
<kees> slangasek: hmm, I don't know of any mount "lock" routines
<slangasek> well, if you do *that*, I don't think you need a custom unmount wrapper at all. :)
<kirkland> slangasek: right, exactly
<slangasek> kirkland: so yes, I think that's by far the simplest solution :)
<kirkland> slangasek: erg...  can you me and pitti sit down and have a pow-wow about this?  :-)
<kirkland> i'm quite literally running around in circles!
<kirkland> slangasek: i've been on a week-long wild goose chase trying to *not* have a script updating /etc/fstab
<kirkland> and every day that goes by, that seems like the easiest solution
<slangasek> kirkland: oh, I'm not suggesting updating /etc/fstab
<kirkland> kees: speaking of /etc/mtab locking, what was it that we had to do for the udev/upstart bits about nfs mounts not showing up on startup?  we had some lock issues to solve there
<slangasek> kirkland: but I think if you add -ouser=kirkland as a mount option when mounting, it will be echoed to /etc/mtab
<kirkland> slangasek: okay, i missed something
<kirkland> slangasek: yup, i agree with that....
<calc> nautilus cd burner defaults not to using burnproof if available?
<kirkland> slangasek: okay, so do that on mounting
 * calc is looking in gconf-editor on a fresh installed system
<kirkland> slangasek: and continue with my custom umount wrapper work?
<slangasek> kirkland: if you're able to pass user=kirkland into the /etc/mtab entry, I think the unmount might work as a normal user?
<slangasek> maybe not, hmm
<kirkland> slangasek: nope, i tried that :-(
<slangasek> ok
<slangasek> then I believe you want a) to get a distinguishing option into /etc/mtab at mount time, b) a custom unmount wrapper that checks this option before doing the unmount
<kirkland> slangasek: i can look at the umount source code, it might just be an arbitrary /etc/fstab check.... but it does error out with "umount: /home/kirkland/Private is not in the fstab (and you are not root)"
<joaopinto> kirkland, the mount man pages tells that the user option allows to mount/unmount the fs
<slangasek> kirkland: right, I half-suspected that
<slangasek> joaopinto: but only if the user option appears in /etc/fstab, which we're trying to avoid writing to
<kirkland> slangasek: would a "fix" to umount be in order, changing that behavior?
<slangasek> kirkland: no :)
<joaopinto> slangasek, not really, the man refers to mtab
<kirkland> slangasek: :-p
<joaopinto> quoting: "The name  of  the mounting user is written to mtab so that he can unmount the file system again. "
<kees> kirkland: that was related to handling if mtab existed yet or not
<kirkland> joaopinto: what man page is that?
<kees> kirkland: to check for old entries, etc
<joaopinto> kirkland, man mount, user= option
<kirkland> kees: oh, right... race on creation, not mulitple simultaneous editors
<slangasek> joaopinto: but the username in mtab only helps if the option is also in fstab.
<kirkland> joaopinto: right, perhaps that documentation could be stated more clearly
<joaopinto> slangasek, well, you can pass the option from a system call mount, it doesn't need to be on the fstab
<kirkland> joaopinto: but in practice, what i'm seeing is that umount will check /etc/fstab before /etc/mtab
<slangasek> um, that's not the existing security model
<slangasek> which should not be changed haphazardly
<kirkland> slangasek: so should I recycle the user= option, or something more custom-identifiable?
<slangasek> kirkland: given that the security policy for unmounting these will be explicitly different than the one built into unmount, it should have a different option name as well
<kirkland> slangasek: everything else has ecryptfs_, so ecryptfs_user=kirkland then
<slangasek> is ecryptfs_ the name of the tool, or the underlying fs?
<kirkland> slangasek: ecryptfs is the name of the filesystem
<kirkland> slangasek: ecryptfs-utils is the userspace package
<kirkland> slangasek: ecryptfs-setup-confidential is the script that I'm working on to setup up the mountpoints, keys, settings, ciphers, etc.
<slangasek> then I would tend to suggest an option name that's tied specifically to the implementation of this spec, rather than eating into the namespace for options related to the filesystem itself
<kirkland> slangasek: umm, something more generic like mounted_by=kirkland ?
<slangasek> ubuntu_private_owner=kirkland? :)
<kirkland> slangasek: ah, more like that, huh....
<kirkland> slangasek: okay, so the security check now becomes a) is an ecryptfs mount, b) has ubuntu_private_owner=kirkland option
<kirkland> slangasek: and i don't look at the perms of the mountpoint or the device or anything?
<kirkland> slangasek: okey doke, thanks for your awesome assistance ;-)
<joaopinto> hum, umount referes to the need of using an umount helper for regular users to umount fs which are not defined on fstab, so yes, there is something wrong with the mount/umount user option description
<slangasek> kirkland: yep, that should do it :)
<kirkland> pitti: could you please try syncing ecryptfs-utils from Debian again when you come online?  Thanks ;-)
<kirkland> pitti: I'd like to see the 48-1 version pulled from Debian into Intrepid
<kirkland> slangasek: regarding ubuntu_private_owner=kirkland ... to make this upstream-palatable, could I say ecrypts_private_owner=kirkland?
<kirkland> slangasek: or something along those lines?
<kirkland> slangasek: all of my work has been going smoothly into ecryptfs-utils upstream git
<slangasek> kirkland: oh, if you think the helper tools are going to end up integrated upstream, then yeah, that would make sense
<kirkland> slangasek: yeah, all of this is going upstream, cool, thanks.
#ubuntu-devel 2008-06-17
<tacone> hello, how may I ask to, for reporting a problem on a canonical server ?
<tacone> err.
<tacone> who may ask to ?
<tedg> Why do the lpia PPAs always build faster?
<TheMuso> tedg: Probably because they are not loaded down with arch all packages.
<tedg> TheMuso: Ah, okay.  Thanks.
<TheMuso> o/c
<pitti> Good morning
 * StevenK waves to pitti 
<ajmitch> hi pitti
<pitti> kirkland: if you keep 'user=kirkland' in mtab, then umount works as user? I. e. it doesn't need an fstab entry? nice! the "mount as root" part was ok, AFAIR, right?
<pitti> kirkland: ecrypts_private_owner=kirkland? that's not something umount currently understands; so you do want to patch mount after all?
<pitti> kirkland: sync> will do
<pitti> slangasek: "I can live with that"> If we disable LANMAN by default in intrepid, to put an end to it, and reenable it in hardy-updates, if you think that a gvfs patch to display a proper error message is too complicated for an SRU
<nxvl> slangasek: around?
<slangasek> pitti: I don't think it's too complicated for an SRU; I do think it would take too long to include in 8.04.1.
<slangasek> nxvl: vaguely
<nxvl> slangasek: i was wondering about the delay on alpha1
<nxvl> slangasek: is there some page or something with a list of what's needed?
<pitti> slangasek: that was because of the insufficient error reporting API in libsmbclient, so it takes some hacks to get the actual error cause?
<slangasek> nxvl: the short list is "debian-installer needs to be merged"
<slangasek> pitti: yes, the libsmbclient is POSIX-like, so detecting the right error would require some kludging to get out-of-band info
<pitti> no smberrno or so?
<pitti> kirkland: hm, I just did a "sync all" run, but ecryptfs wasn't amongst it; apparently it's not on ftp.uk.d.o yet?
<nxvl> slangasek: look like a looong and hard merge
<slangasek> nxvl: yes, it's in progress; merges are, of course, not very parallelizable
<nxvl> yup
<nxvl> but we can still have a bzr branch to work on it
<slangasek> well, that would be a strange way to handle merge conflicts, IMHO
<nxvl> mmm
<nxvl> yep, it could be
<nxvl> well
<nxvl> now i need to sleep
<nxvl> see you
<nxvl> slangasek: if you need some help on anything please ping me
<nxvl> :D
<lifeless> slangasek: actually its a common feature request for large-scale vcs's
<lifeless> slangasek: to be able to save and restore conflict state and collaborate on such things
<slangasek> lifeless: hmm, feels dirty to me, but ok. :)
<slangasek> nxvl: sure :)
<lifeless> slangasek: consider a merge with 2K conflicts
<lifeless> slangasek: parallelising that would save a lot of time off the process, if you could
<slangasek> lifeless: I would prefer to never have to consider one of those if I can help it ;)
<lifeless> slangasek: or even, imagine if debian and ubuntu were single vcs trees
<lifeless> mom is basically doing this by splitting the conflict set by package, but there are conflicts that are cross-package - they are artificially partitioned by our tool chain but need to be treated as a unit
<dholbach> good morning
<theJamAbides> Hey guys just looking for the bugs channel and how to get involved with helping out a little... see it in the banner, see you around!
<philwyett> Yikes... People are using the [[FullSearch()]] macro on wiki.ubuntu.com in their personal pages to list all pages with their wiki name in instead of using links. That might be stressing the server doing many searches. :-/
<lifeless> philwyett: if so, then its a bug in the wiki
<ion_> Indeed
<philwyett> Going by the limited docs, it's usage is not restricted and is doing the correct thing and listing pages containing the calling pages title string which is the users wiki name. Where would I file something like this do you think?
<ion_> If it slows down the wiki, probably whereever one is supposed to file bugs agains the wiki engine in question.
<philwyett> I will dig further and see if can be corrected at the server now or it should be file at MoinMoin.
 * philwyett laughs. Well [[FullSearch()]] is not a bug it's a feature. Listed No.1 in the performance cpu and I/O usage hit parade on the MoinMoin site. Educating users is suggested. :-)
<ion_> philwyett: Fixing MoinMoin is suggested. :-)
<philwyett> ion_: I will put in an RFE with MoinMoin, but also mail the Ubuntu webmaster and discuss. There are 432 instances of it's use on the wiki, so only a medium large job to correct the bad usages. :-)
<ion_> s/correct the bad usages/workaround the wiki bug/
<philwyett> :-)
<ion_> macslow: Hi
<ion_> macslow: Btw, the keyboard layout indicator in gnome-screensaverâs unlock dialog doesnât share the background gradient.
<MacSlow> greetings ion_
<MacSlow> ion_, that's "fixed"...
<ion_> Alright :-)
<MacSlow> ion_, in the way that there is no more gradient as it was decided against the gradient
<ion_> Oh, ok. I kind of agree with that.
<MacSlow> ion_, but otherwise it would have been fixed too by now :)
<MacSlow> ion_, sadly there are still a couple of issues with some widgets and RGBA-colormaps
<MacSlow> ion_, but if we don't stress it, issues don't turn up and we don't know that we need to fix them
<ion_> Yeah
<asac> is there a "common" way to specify dns server for static interface definitions in /etc/network/interfaces ?
<RicardoPerez> asac: Hi! Any news about language-pack-es-base bug #240028?
<ubottu> Launchpad bug 240028 in language-pack-es-base "Problem in language-pack-es-base order installation makes Firefox translations lost" [Undecided,Confirmed] https://launchpad.net/bugs/240028
<Doris> when running dpkg-buildpackage on a project i get "dpkg-shlibdeps: failure: no dependency information found for" - anyone know where this is fixed ? i have a depends line in my debian/rules file.
<pitti> asac, RicardoPerez: ah, we figured it out (bug updated); I'll fix it
<persia> Doris: Better to ask packaging questions on #ubuntu-motu.  Also, you generally want the dependencies in debian/control, rather than debian/rules.
<RicardoPerez> pitti: oh, great!
<Doris> sorry i did mean the control file
<Doris> ill try motu though, thanks :)
<pitti> cjwatson: *phew*, dhcp3 merge finally done and uploaded (adopting our patches and sending them all upstreamwards took a while)
<RicardoPerez> pitti: I can do all the testing you want, if you need it...
<pitti> RicardoPerez: I at it already
<pitti> RicardoPerez: I'd upload them to hardy-proposed, then you test, and if it's confirmed to work, I'll copy them to -updates
<pitti> RicardoPerez: works for you?
<RicardoPerez> pitti: great, of course!
<RicardoPerez> pitti: you only need to notify me when the updates are in hardy-proposed, in order to test them
<pitti> RicardoPerez: will do; thanks!
<RicardoPerez> pitti: thanks to you :)
<DktrKranz> mvo: bug 222000 still has issues. If you want, I can look at it myself.
<ubottu> Launchpad bug 222000 in axyl-lucene "Update from Gibbon to Heron failed" [High,Confirmed] https://launchpad.net/bugs/222000
<cjwatson> pitti: woo, thanks; if that turns out to be enough to build d-i (unfortunately it's hard to tell in advance), I'll upload it
<pitti> cjwatson: still needs to pass NEW (new -ldap package), I'll watch it
<mdke> what package should I use for filing a bug on the absence of sound if I don't have the first idea about what the cause is?
<mvo> DktrKranz: that would be nice, I looked at this and fixed some bits, but there are other issue left I think
<DktrKranz> mvo: thanks, I'll look at it more deeply.
<mvo> thanks
<seb128> mdke: what sounds?
<mdke> seb128: all
<mdke> since asking the question I've found some info on the debug page on the wiki
<mdke> I'll follow those instructions, sorry for the noise
<seb128> mdke:  I guess trying aplay first is a good idea
<RicardoPerez> pitti: there's a delay in the hardy-proposed packages to be updated, isn't it?
<pitti> RicardoPerez: yes, they need to build now, and then publish, I'll shepherd that
<pitti> RicardoPerez: they should hit archive.u.c. at 1100 UTC
<mdke> seb128: ok, I'll try that too, thanks
<RicardoPerez> pitti: ok, great, i'll wait then :)
<cjwatson> pitti: dhcp3-server-ldap is in NEW now for all but hppa
<Riddell> pitti: indi is compiled now for that MIR, I realise the reason it wasn't uploading before is it used to be part of kdeedu (and so the version number was too low), so maybe it doesn't need a MIR?
<pitti> oh, doko is on the conference
<pitti> Riddell: I'll have a look soon
<pitti> Riddell: right, I just poked indi to build so far, so that it can actually be reviewed
<mnabil> guys, when  i tried to chroot on ubuntu from sabayon , i successfuly chrooted but i wanna run a gui application from ubuntu,   i got "Error: cannot open display: :0.0" ,  i export the DISPLAY variable, and used xhost , but i got the same error
<mnabil> http://pastebin.ca/1048997
<mnabil> details
<mnabil> any idea
<cjwatson> I use things like http://people.ubuntu.com/~cjwatson/tmp/chroot-enter (see also chroot-setup and chroot-teardown) to deal with that sort of thing
<cjwatson> don't use xhost
<cjwatson> the reason it can't resolve your DISPLAY is that you haven't bind-mounted /tmp/.X11-unix so it can't find the socket
<Mithrandir> xhost is fine if you use xhost +SI:localuser:foo, though.
<Mithrandir> but you still need that bind-mount, yes.
<mnabil> thanks , i'll try that
<Riddell> pitti: dhcp3-server-ldap in main or universe?
<pitti> Riddell: main should be fine, I think; the server guys should be happy about it
<Riddell> pitti: shouldn't it conflict with dhcp3-server since they both contain /usr/sbin/dhcpd3 ?
<pitti> Riddell: no, it diverts dhcpd
<pitti> Riddell: thus -ldap even depends: on dhcp3-server, for reusing the init script, config files, and other infrastructure
<Riddell> right
<RicardoPerez> pitti: I've noticed that only language-pack-es & language-pack-es-base has been updated. Is it right?
<pitti> RicardoPerez: no, also -pt and -zh
<pitti> RicardoPerez: or what do you mean?
<pitti> Riddell: hm, libsbigudrv-dev doesn't ship any header files?
<pitti> Riddell: also, indi seems to deal with quite special hardware; do we have any of this for supporting this?
<Riddell> pitti: right, the header files are duplicated in kdeedu
<Riddell> pitti: no, can't say I have any telescopes
<pitti> Riddell: so, not having it in main would entirely disable that part of kdeedu instead of just having it in universe (which would be ideal), right?
 * ogra_cmpc fears thats kstars
<Riddell> pitti: yes
<Riddell> ogra_cmpc: yes
<pitti> Riddell: ok, then I guess you want to have it in main
<ogra_cmpc> pitti, if Riddell doesnt, i do
<pitti> ok
<pitti> so, promoted
<ogra_cmpc> unkless you have any equivalent to kstars i could take :)
<pitti> Riddell: the -dev package still looks broken, though
<Riddell> pitti: how so?
<pitti> RicardoPerez: the langpacks are on archive.u.c. now, ready for testing
<pitti> Riddell: no header files
<pitti> Riddell: qca2 doesn't contain any crypto functions on its own, right?
<Riddell> pitti: I'm afraid I don't know
<pitti> ok, I'll have a look
<ccm> hey guys, just a short question: i looked at #156204, checked it and wrote a six line patch for pidgin-otr to enable creation of files with 0600 instead of 0644.
<zul> morning
<ccm> no my question is if i should mail this patch to the debian maintainer, attach it to the bug report
<ccm> or... whatever
<james_w> ccm: hi, so the bug is in the pidgin-otr package, and not pidgin?
<RicardoPerez> pitti: I'm working on it :)
<ccm> james_w: yes. but i got already two answers instructing me how to proceed
<RicardoPerez> pitti: I'll do a fresh install, then an update, to be really sure the fix works
<Riddell> infinity: do you know why openhackware hasn't built?  I'm not sure what to do with bug 217432
<ubottu> Launchpad bug 217432 in openhackware "Please build openhackware 0.4.1-3" [Undecided,Fix committed] https://launchpad.net/bugs/217432
<geser> Riddell: see I it correctly that openhackware 0.4.1-3 has no build records? neither for hardy nor intrepid
<ScottK> geser: It has to be manually built.
<elmo> IIRC, openhackware is/has an arch all package that can't be built on i386 (sic) - soyuz doesn't support that
<geser> right, it's in Pas: %openhackware: powerpc      # per Guillem Jover
<Riddell> mvo: motu-sru don't like your proposal for bug 231098
<ubottu> Launchpad bug 231098 in ubuntu-restricted-extras "Please add sun-java6-jre and sun-java6-plugin to *ubuntu-restricted-extras" [Wishlist,Fix committed] https://launchpad.net/bugs/231098
<mvo> Riddell: thanks, I'm answering now
<norsetto> Riddell: don't think he is in motu-sru
<Riddell> norsetto: hmm?
<ScottK> norsetto: I asked Riddell to respond to his comment.
 * ScottK is in motu-sru
<norsetto> ScottK: ah ok
 * mvo answered now
<persia> Riddell: I'm not MOTU SRU.  I'm just an opinionated MOTU.
<Coren`> anyone know where is "doko" ?
<persia> Coren`: This is the right place to ask, but providing context will often generate a more full response.
<jordi> oi
<jordi> I notice ia32-libs in ubuntu includes alsa plugins.
<ogra_cmpc> likely for flash
<jordi> we'd love to provide this in lib32asound-plugins, but we really don't grok biarch, I wonder if someone from the ubuntu core team would be able to tackle that
<Coren`> persia: ok, I will give more context
<Coren`> persia: he has forgotten to add a file into ooo-build svn
<Coren`> nothing really serious, but I am pretty confident that he is the only one which has the file available
<persia> Coren`: Ah.  Put that next to his name, and there's a chance that he'll see it in backscroll, and add the file.
<Coren`> persia: good idea
<Coren`> mmh .. he can see irc logs even if he is not connected ...
<jordi> who's the biarch dude? doko?
<Coren`> well, whatever, doko, please addd writer-default-font.diff to ooo-build svn whenever you can, thanks
<jordi> doko?
<pitti> Coren`: you want to talk to calc about OO.o patching
<jordi> pitti!
<pitti> hey jordidude! how are you?
<jordi> pitti: besides doko, any others who I could mail regarding biarch matters'
<jordi> pitti: all is well. dude, I saw pics of you, lots, from UDSS
<jordi> -S
<jordi> nice beard :)
<Coren`> pitti: thanks, but calc cannot help me on this one
<pitti> jordi: *scratching head* look how lib32readline5 or lib32z1 are built?
<pitti> jordi: thanks
<Coren`> (as far as i know)
<jordi> pitti: see above; we need help to create a biarch alsa plugins package
<jordi> we already build lib32asound
<jordi> people want lib32asound-plugins
<jordi> Ubuntu actually sticks the plugins in ia32-libs, but that's ugly, of course
<pitti> jordi: yes, absolutely
<cjwatson> Coren`: people rarely read IRC logs from when they aren't connected; please send e-mail
<pitti> jordi: ia32-libs should ideally disappear; it's a PITA and a hack
<pitti> jordi: in an ideal world you could just apt-get install the _i386.deb on amd64, and we'd avoid all the multibuild stuff and ia32-libs *dream*
<Coren`> cjwatson: he has an email @ubuntu.com ?
<cjwatson> Coren`: yes
<Coren`> ok, thanks cjwatson
<ScottK> mvo and Riddell: I acked the SRU for bug 231098 conditional on adding amd64.
<ubottu> Launchpad bug 231098 in ubuntu-restricted-extras "Please add sun-java6-jre and sun-java6-plugin to *ubuntu-restricted-extras" [Wishlist,Fix committed] https://launchpad.net/bugs/231098
 * norsetto wonders why java packages are arch dependent
<Coren`> I have send it, thanks again cjwatson, pitti and bye everyone
<pitti> bdmurray: any chance that you can generate the DB queries on https://devpad.canonical.com/~brian/ with "psql -At"? this will suppress the table header and footer, and the leading whitespace
<cjwatson> norsetto: sun-java6-plugin doesn't work properly on amd64, I believe; 64-bit support was pushed out to JDK 7
 * ogra_cmpc wonders what's the reason for gpg stealing his terminal if a passphrase was mistyped three times or a passphrase input was canceled
<ogra_cmpc> i mean, if i have to execute reset anyway, gpg could do that for me as well on exit
<norsetto> cjwatson: I was just curios in a general way as why a java package was arch dependant (don't know what that particular one does)
<cjwatson> ogra_cmpc: usually just a bug in terms of forgetting to turn the echo flag back on in some code paths
<ogra_cmpc> ah
<cjwatson> terminal settings are per-terminal rather than process-specific, so the process has to take care to restore them
<ogra_cmpc> right, wso i should file that against gpg i guess
<cjwatson> and if it forgets (often due to being interrupted by a signal that it doesn't handle properly, but not always) then you can end up with echo left off
<cjwatson> yes
<ogra_cmpc> right, thats what i see (actually since ages, but it didnt bother me enough yet)
<kirkland> pitti: hiya
<kirkland> pitti: http://packages.qa.debian.org/e/ecryptfs-utils.html shows 48-1 is in unstable
<pitti> hi kirkland, how's it going?
<kirkland> pitti: good, i made some good progress yesterday with help from slangasek and kees
<kirkland> pitti: i created a C program for umount.ecryptfs, setuid
<pitti> kirkland: hm, looks like it's on ftp.uk.d.o now, too
 * pitti runs a sync
<cjwatson> kirkland: FWIW you don't normally need to ask for syncs of unmodified-in-Ubuntu packages until DebianImportFreeze (26 June)
<kirkland> cjwatson: by that you mean they happen automatically?
<cjwatson> semi-automatically
<cjwatson> as in, an archive admin runs some stuff roughly daily which slurps everything in, in bulk
<kirkland> cjwatson: right, but if I want it to happen "now", i was told to ask pitti....
<cjwatson> if you're desperate for it to happen in sub-day timeframes, yes :)
<pitti> right, I tried this morning, but ftp.uk.d.o. seems to be pretty behind
<pitti> hm, sorry, ftp.uk's Package lists still seem old
<pitti> still not autosynced
<cjwatson> you could always just switch ~lp_archive/bin/update-sources over to some other mirror
<cjwatson> wouldn't be the first time :)
<pitti> ah, we can still do that?
<pitti> I thought it'd all be buried in LP code now
<cjwatson> syncorigins.py downloads from ftp.d.o anyway ;-)
<cjwatson> update-sources isn't
<pitti> ah
<cjwatson> syncorigins.py *ought* to be under our control but isn't
<kirkland> pitti: you mentioned force-syncing *just* ecryptfs-utils last week....  is it possible for me to use those scripts and do that, pushing to my PPA instead of the real Intrepid archive?
<kirkland> (that assumes PPA have started building Intrepid binaries, which it wasn't last I checked)
<cjwatson> you can't use the LP scripts, but you can always upload the same thing manually to a PPA
<cjwatson> just need to construct a suitable .changes file ...
<cjwatson> kirkland: anyway, I see (from happening to have a shell there) that pitti is in the process of syncing ecryptfs-utils now, so don't worry about it
<kirkland> cjwatson: or, if the deb is completely unchanged, I should in theory be able to use the Debian .deb, right?
<pitti> kirkland: not 'force', but 'fake'; yes
<pitti> kirkland: yes, I switched to ftp.debian.org, which seems to be better ATM; sync coming in
<kirkland> pitti: cool, thanks
<cjwatson> it is often possible to use Debian .debs with some care
<kirkland> cjwatson: not "deb completely unchanged", but "package unmodified"
<pitti> kirkland: http://people.ubuntu.com/~pitti/scripts/syncpackage is the script I am using
<kirkland> ah, right, different tool chain.....
<cjwatson> kirkland: like I say :)
<kirkland> pitti: thanks, i'll take a look
<pitti> kirkland: it constructs a suitable source.changes from a .dsc
<cjwatson> or why not just download the source and build it yourself if you're in a rush to test with it
<pitti> kirkland: but use it with a grain of salt, and only after proofreading that the .changes has the correct changelogs
<kirkland> cjwatson: that's what I've been doing
<kirkland> cjwatson: i've been working from the upstream's git
<cjwatson> perfectly reasonable for local testing
<kirkland> cjwatson: testing/building/running that
<kirkland> cjwatson: patching against that, sending upstream
<kirkland> cjwatson: when the upstream maintainer takes them, he'll do a version bump
 * ogra_cmpc scratches head why the cmpc kernel doesnt show up in the PPA
<kirkland> cjwatson: if the debian packager doesn't pick up the change within a week or so, i'll ask him to bump up the unstable version
<kirkland> cjwatson: he's been very kind and responsive
<kirkland> once it's built in debian, i pull that dsc and build and test locally on Ubuntu
<kirkland> cjwatson: then i usually ask pitti for a sync, if it hasn't happened
<kirkland> cjwatson: how does that workflow sound to you?
<pitti> there, all synced and uploaded
<kirkland> pitti: big thanks ;-)
 * ogra_cmpc sighs and actually gives the right option to dput ...
<Laney> Would there be any problem with me doing the merge/sync for boost? It's blocking at least two merges in Universe atm.
<jordi> pitti: unfortunately we're not in that ideal world yet ;)
<ogra_cmpc> Laney, i doubt anyone would complain if you do the work, but contact the former uploader/maintainer (see http://merges.ubuntu.com) and have him review it or so
<Laney> ogra_cmpc: Yeah, I've just not done one for main before so thought I'd check in here ;)
<ogra_cmpc> boost is in main, so you will need a main sponsor anyway
<Laney> jdstrand: You were the last uploader of boost. Do you mind if I work on the sync/merge?
<Laney> ogra_cmpc: :)
<jdstrand> Laney: you'll want to ask zul-- he asked me if he could do it
<jdstrand> (and I said yes)
<Laney> jdstrand: Ah, right.
<zul> Laney: go ahead
<Laney> zul: Thanks. Will do now.
<pitti> jordi: so, I haven't done multiarch building myself either, so I'm sorry that I cannot give you hints for that
<kirkland> pitti: oh, i just saw another post from you to me at Jun 17 00:21:37 ...
<kirkland> <pitti> kirkland: if you keep 'user=kirkland' in mtab, then umount works as user? I. e. it doesn't need an fstab entry? nice!
<kirkland> pitti: that would seem the case from the umount manpage, but in practice that's not what's happening....
<kirkland> pitti: i haven't inspected umount's code yet (on today's todo list), but empirically, umount checks existence in /etc/fstab FIRST, and errors out if there's no entry
<pitti> kirkland: I wonder whether it would be too evil to modify mount itself to (alternatively) accept user= in mtab
<pitti>               user   Allow an ordinary user to mount  the  file  system.   The
<pitti>                      name  of  the mounting user is written to mtab so that he
<pitti>                      can unmount the file system again.
<kirkland> pitti: well, either the code or the manpage needs updating, i agree with that
<pitti> kirkland: ^ the manpage seems to indicate that it's meant to be like that
<kirkland> pitti: slangasek's objection to changing the code was mainly that that cannot be done haphazardly.....
<pitti> so umount should continue to check fstab for the people who have /etc/mtab -> /proc/mounts
<kirkland> pitti: yep, your reading and my reading of the manpage agree
<pitti> of course people who do have that won't be able to use your ecryptfs-umount either then
<kirkland> pitti: however, my test case looks like....
<seb128> pitti: any reason that new versions srus don't move to hardy-updates? ie tomboy is a new tarball upstream specially rolled to fix one bug and has been uploaded 18 days ago
<kirkland> pitti: 1) add fstab entry allowing user=dustin to mount a filesystem, 2) have user=dustin mount the filesystem, 3) become root and comment out that fstab entry, 4) have user dustin umount, and umount fails saying entry is not in fstab
<pitti> re
<pitti> argh, that was the dumbest action ever
<pitti> I dropped a piece of chocolate, and it flew straight to the power plug, hitting the switch
<pitti> seb128: usually the reason is that nobody gave testing feedback on the SRU bug
<pitti> kirkland: last thing I got from you was "however, my test case looks like...."
<kirkland>  pitti: 1) add fstab entry allowing user=dustin to mount a filesystem, 2) have user=dustin mount the filesystem, 3) become root and comment out that fstab entry, 4) have user dustin umount, and umount fails saying entry is not in fstab
<kirkland> pitti: weird that got dropped
<ogra> pitti, a "piece" ?
<pitti> ogra: half of an Easter bunny :)
 * ogra looks at his switched powerplug ... it would need at least two bars of chocolate to switch
<kirkland> evidently germans have large pieces of chocolate!
<seb128> pitti: well, for new versions bug we could say that the no feedback is a good sign ;-)
<ogra> kirkland, we're not swiss ... we'Re the ones with the big sausages ;)
<pitti> seb128: are you using tomboy, and the actual hardy-proposed .debs?
<kirkland> ;-)
<pitti> well, with 80 cm of acceleration, even a small piece evidently has enough impulse to flip the switch...
<seb128> pitti: yes
<pitti> seb128: can you please say so in the SRU bug then? that's the kind of feedback I want to hear :)
<pitti> seb128: (and yes, we should push for verifying all the currently pending stuff and get it to -updates ASAP)
<norsetto> asac: re. gnome-mplayer, I just sent a patch upstream to fix some license/copyright issues for translations. We therefore have some time since I would like to upload the newer version (to avoid being rejected)
<asac> norsetto: oh ok. thanks for looking into it
<asac> let me know when the bits are ready to go up ;)
<norsetto> asac: sure
<pitti> asac: did you hear any regressions with ffox/xulrunner rc2? 7 days in -proposed have elapsed
<lool> c
<lool> Ups
<pitti> ogra: I'm a bit worried about the ltsp verification; none of the bugs got any feedback so far :(
<pitti> ogra: once we get a couple of "I have used that updated version for a few days in my production environment", I'm happy, but we didn't
<cjwatson> kirkland: workflow> sounds normal and reasonable
<kirkland> cjwatson: thx
<cjwatson> ooh, looks like d-i roughly builds now
<cody-somerville> cjwatson, I thought you fixed the PPC build failures for Xubuntu.
<cody-somerville> cjwatson, I'm still getting notifications of failures.
<cjwatson> you thought wrong ;-)
<cjwatson> I just suggested a possibility for fixing it
<cjwatson> and put some provision in place to make fixing it possible
<asac> pitti: no they are fine. we should wait till 10:00 PDT and release them
<asac> thats 1900 our time i think
<asac> pitti: ok i am off now for 1h ... if you are around, please push xulrunner-1.9 and firefox-3.0 at 19:00 our time (or slightly in advance). thanks
<asac> (to -updates)
<cody-somerville> cjwatson, okay :)
<ogra> pitti, well, as i predicted, ltsp users are reluctant to upgrading their chroots (thats why its important for me to get it on the 8.04.1 CD) ... all i can say is that i verfied all of the fixes and am running ltsp here with them successfully since without problems ... afaik stgraber verified two of them as well
<stgraber> ogra: yep I did, I'll try to verify the lts.conf ones (X parameters) too
<ogra> that would be great
<calc> slangasek: do you happen to know what is currently holding OOo out of updates?
<calc> or is it just a time thing?
<slangasek> calc: the SRU policy, which states there's a 7-day waiting period barring exceptional circumstances? :)
<calc> slangasek: ah ok
<tedg> Is there a good reason that I have to do "(cd mypackage; debuild)" instead of "debuild mypackage"?
<tedg> It's mighty annoying that debuild and dput have to be done in different directories.
<fqh> ï»¿any one familiar with script? I want to erase all the first characters "+" of each lines in the diff file, how to do it?
<slangasek> tedg: I'm going to take it as assumed that any reason given would not be accepted as a good reason. :)  But you could write "tedbuild" which wraps debuild... :)
<slangasek> fqh: why would you want to do that?  If you do that, what you have is no longer a patch...
<fqh> ï»¿slangasek: Actually, it is a completely new c source file. so all line starts with "+". after erasing "+", my tool will be able to parse that source file
<slangasek> fqh: sed -e's/^\+//'
<tedg> slangasek: I'd rather patch debuild to do it right :)
<fqh> slangasek: thanks very much
<slangasek> tedg: I think any syntax you would come up with would be less optimized for the common case than just running "dput ../foo.changes" ?
<slangasek> since typically, one edits a package before building it
 * ScottK agrees with slangasek.
<ogra> and all the output of dpkg-buildpackage/debuild usually has the ../ if you are in the source dir
 * ogra finds that very convenient for copy/paste
<tedg> I don't ever edit the package before building it.  I'm always editing the debian directory in the VCS and then copying it over.
<tedg> So it's something more like "tar -xvzf mypackage ; cp -a vcs/debian mypackage ; cd mypackage ; debuild ; cd .. ; dput mypackage"
<slangasek> oh, well, keeping only the debian directory in the VCS is its own kind of breakage ;)
 * mvo raises a eyebrow
<pwnguin> putting the whole source package in vcs makes sense to me. whether it's feasible today's another story
 * tedg is going to laugh when slangasek gets hit with the bazaar packaging dunk tank :)
<slangasek> like the grub package that I put into bzr myself for maintenance?
<tedg> Where are you putting the bazaar branches for the packages?  I put them under "~ted-gould/<package name>/ubuntu-packaging" -- I didn't know if they should go under /ubuntu/ or something different.
<pitti> stgraber, ogra: fine; can you please say so in one of the bug reports?
<pitti> asac: ok; I guess we can move them now then?
<pitti> asac: ok, seems slangasek beat me to it
<slangasek> tedg: for grub, it's https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu (i.e., a shared branch committable by all of core-dev)
<slangasek> one can obviously have other personal branches too
<mvo> hey cody-somerville! what environment does xfce set when it runs? something like XFCE_SESSION or XFCE_SESSION_ID or something like this?
<mvo> to detect if a session is running
<mario_limonciell> tedg, but its not necessarily <package name>, you have to make a LP project for that part of the branch name
<tedg> slangasek: Hmm, that'd imply that I'm core-dev ;)
<slangasek> tedg: well, if it's a package in main, the official packaging branch (and the one represented in the Vcs-Bzr field) ought to be one that core-dev can commit to... :)
<mario_limonciell> tedg, so in the case for the mythbuntu project, we have about 15 branches out there, so we push them to ~mythbuntu/mythbuntu/<package name> for sanity
<slangasek> or the subset of core-dev that maintains the package in practice, I guess, such as ubuntu-desktop
<tedg> mario_limonciell: Ah, but I usually have "ubuntu-packaging" and "debian-packaging" -- so I guess they'd become "<package>-..."
<mario_limonciell> tedg, all the more reason to make shoe packaging the same :)
<mario_limonciell> shoe=those
<tedg> slangasek: Well, having a branch that core-dev can commit to does me no good, as I'm not core-dev.  But ubuntu-desktop would be interesting.
<liw> pwnguin, it's perfectly feasibly to have the entire source for a package in a bzr branch (been there, done that...)
<mario_limonciell> it just gets a wii bit slow when you have a very large source package and need to do a full checkout somewhere
<slangasek> tedg: the commit rights on the "official" packaging branch should match the commit rights in the archive; that's certainly the game plan for the eventual everything-in-bazaar scheme.  You would just prod someone to merge your branch (&& upload), rather than prodding to upload
<ogra> pitti, ok, commented on all of them, the NBD_PORT one actually got some more feedback :)
<tedg> slangasek: While I see what you're saying, that'd be very annoying for me personally.
<pitti> ogra: thanks! hm, I wonder why I didn't get mail about it; is ubuntu-sru sub'ed?
<pitti> ogra: anyway, I have the bug list here, I'll look at that
<ogra> thanks
<ogra> yep, "SRU Verification" on all of them
<pwnguin> are there any packages still in debian/ubuntu that require explicit distribution as patches?
<stgraber> I receive mail notification only for one of them (so far), maybe LP is a bit slow with bugmail
<stgraber> *received
<pitti> cjwatson: ah, d-i upload; did the dhcp changes work out?
<pitti> ogra: ah, sru-verification; I meant ubuntu-sru
<ogra> oh, no, should i ?
<pitti> pwnguin: yes, at least LaTeX is like that
<pitti> ogra: ah, that explains it
<ogra> i have them all open anyway atm
<pitti> ogra: if it's quick for you, would be nice
<pitti> ogra: ubuntu-sru > slangasek and me (management); sru-verification -> QA team (verification)
<pitti> yes, slightly confusing
<pwnguin> pitti: ah right
<ogra> ah, k
<asac> pitti: thanks. sorry for asking steve. didnt know if and when you return and wanted to get the bits out
<pitti> asac: why sorry? no need to apologize for causing less work for me :-P
 * pitti hugs asac
 * pitti hugs heno, too, for verifying all the OO.o SRU bugs
<pitti> ogra: oh -- not fixed in intrepid yet?
<pitti> ogra: are all the fixes in bzr trunk?
<ogra> pitti, still fiddling with the new setup of the ltsp source
<ogra> yes
<ogra> upstream
<ogra> but we rearranged the complete tree and i'm merely building new packages and starting to consider to just take vagrantc's work from debian to avoid that in the future
<ogra> so it takes a bit longer this time
 * heno hugs pitti for helping push .1 along
<pitti> ogra: ok, so I can reasonably rely on the fixes not getting lost for intrepid?
<ogra> pitti, yes
<pitti> ogra: indeed there was quite a lot of positive feedback from other people; so I just didn't see it due to the missing subscription
<pitti> so all is well
<ogra> yay :)
<ogra> now to find out why my classmate kernel build failed *again*
 * ogra sighs loudly .... i thought i had cheated the abicheck 
<pitti> ogra: so updating the ltsp package doesn't cause the chroots to be rebuilt?
<ogra> pitti, ergh, no ...
<pitti> ogra: how do you automatically fix bugs in the chroots then?
<ogra> that would be mean
<pitti> "Don't introduce bugs"?
<ogra> there is no automatism
<stgraber> pitti: you can't
<pitti> ogra: well, surely you need to at least apply security updates?
 * pitti thinks "libssl!!!!"
<ogra> you need to chroot into it, update, and re-roll the squashfs
<pitti> right, that's what I meant
<stgraber> people have to chroot inside it, run "apt-get update && apt-get dist-upgrade", then run ltsp-update-client
<stgraber> ogra was faster ... :)
<pitti> so it'd be impractical to do that in the ltsp postinst?
<ogra> ad i dont want to hog peoples machines for 20min for rebuilding an image while upgarding
<pitti> (so that fixes in ltsp actually get applied)
<pitti> ogra: *shrug* better than unsafe SSL keys :)
<stgraber> you can't do that in postinst as you don't know where the chroot is, if it's using nbd or nfs, you don't even know if it's the same arch as the server :)
<pitti> stgraber: well, the arch shouldn't matter, should it? As you say, it's more or less "chroot /foo apt-get"?
<ogra> pitti, well, ldm wont let you log in without updating the keys indeed
<ogra> the server prevents that
<ogra> pitti, powerpc chroots on x86 do matter for some packages :)
<stgraber> pitti: I have an amd64 server with a powerpc chroot on it, people with large network can do that to match all their thin clients
<stgraber> and ogra was faster, again ...
<ogra> and if we get arm, arm will also have a problem here
<pitti> right, I don't question that
<pitti> that wouldn't work locally, true
<ogra> i was playing with some qemu ideas a year ago
<pitti> well, at least not very easily
<ogra> but the time i have left for ltsp gets less and less so beyond noml maintenance and fixes there is not much dev time atm
<ogra> so that never got implemented
<ogra> i count on the other distros though, fedora just had their fors ltsp5 release, opensuse plays with ltsp5 in kiwi now and gentoo just had their first successfull install
<ogra> s/fors/first/
<stgraber> usually LTSP server admins are aware of security and updates and update their chroot at the same time as the servers (for large network at least). You can't take 100% CPU power for 20 minutes during every upgrade affecting the chroot on a LTSP server with users using it ...
<stgraber> ogra: do you know if guys from the other distros plan to integrate it with their respective update managers so it proposes to update the chroot too ? (or similar way of solving the issue)
<ogra> no idea
<ogra> i discussed that with mov once but never got around to implement that either
<ogra> *mvo
<stgraber> anyway, I don't see much possible security issues with a thin client. Even if they manage to get root access, that won't help them as it doesn't have an hdd and will be stuck with a squashfs+unionfs setup ...
<ogra> well, there might be some ... in case external access from teh network side gets possible due to some bug
<laga> yeah, but are in your network..
<laga> yeah
<ogra> i'm not worried about local exploits either with a 100% locked down system
<ogra> but remote stuff can be harmful
<stgraber> you shouldn't have access to the outside on the thin client network
<stgraber> thin clients should only have access to the terminal server and nothing else
<mkrufky> mario_limonciell / superm1: ping me when you want to
<Ng> do auto-logged-in users not qualify for consolekit is-local?
<tormod> is it only me, or is there a problem with ssh+svn on alioth.d.o?
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down in from 22:00 UTC until 03:00 UTC for hardy server upgrades | Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu
<cjwatson> pitti: yeah, it was fine, thanks
#ubuntu-devel 2008-06-18
<lamont> Argument "27ubuntu13" isn't numeric in numeric lt (<) at /usr/bin/bts line 3039.
<lamont> hrm...
* mthaddon changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment |
* mthaddon changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<kees> owch.  something in udev or lvm has regressed -- uuids aren't being picked up for my lvm partitions any more.
<TheMuso> kees: Is this intrepid?
<kees> TheMuso: yeah, I haven't tracked it down.  I just rebooted before dinner, and I'll probably go digging tomorrow morning.
<kees> the new timeout (30s) worked, though.  :)
<kees> it's really odd... lvm started fine, just none of the /dev/disk/by-uuid links were created
<kees> even after a udevadm trigger
<kees> in fact, it's still that way, even outside of the initramfs so hopefully this should be easy to find.  :)
<TheMuso> ouch
 * Hobbsee cheers, for more non-free software off her computer
<kees> Hobbsee: oooh, what'd you eliminate?
<persia> Hobbsee: What did you purge?
<Hobbsee> kees: adobe reader.
<kees> whoa, didn't that go away in edgy?  :P
 * Hobbsee doesn't have to use pdf's which require user input anymore.
<kees> ah-ha!
<Hobbsee> sure, so i had to install it locally, for the last couple of years.
<kees> TheMuso: hmmmm... something is causing 65-dmsetup.rules not to run (I can see due to the wrong blockdev --getra settings
<kees> TheMuso: ah-ha.
<kees> TheMuso: DM_TARGET_TYPES doesn't seem to exist any more
<TheMuso> ah
<kees> sudo /sbin/dmsetup export -j254 -m11
<TheMuso> lovely
<kees> so it sees it as an empty target and skips it
<kees> TheMuso: I lied -- I didn't wait until tomorrow morning.  ;)  Fixed version uploading shortly...
<TheMuso> kees: heh
<fabbione> morning guys
<Hobbsee> hey fabbione
<fabbione> morning Hobbsee
<fabbione> Hobbsee: how is life down under?
 * cody-somerville waves.
<pitti> hey fabbione
<Hobbsee> fabbione: good - finished exams for the semester :D
<pitti> fabbione: so, not kicked out of the soccer championship yet :)
<fabbione> hey pitti
<fabbione> Hobbsee: congratulation
<fabbione> pitti: nope.. not yet :)))))
<fabbione> pitti: just waiting for seb128 to shake his hand today :P
<TheMuso> 5~/c
<dholbach> good morning
<ccm> hey dholbach
<Hobbsee> dholbach!
<dholbach> hi ccm, hi Hobbsee
<ccm> dholbach: they really acceppted my pidgin-otr patch upstream yesterday :)
<dholbach> ccm: in Debian?
<ccm> dholbach: my first real patch :)
 * dholbach hugs ccm
<ccm> dholbach: in pidgin-otr directly, debian waits for them as they are also informed
<dholbach> good work! :)
<dholbach> ah great
<ccm> i told nobody that i never wrote c code before :)
 * Hobbsee is so not liking the fact that flash keeps crashing her firefox.
<dholbach> ccm: hehe - that reminds me of mvo telling me after he wrote some of my first C code "maybe you should read the chapter about pointers again" ;-)
<nxvl> dholbach: i was just looking for you
<nxvl> dholbach: i'm packaging a library
<nxvl> dholbach: and it has 2 libraries on the source
<nxvl> like it ships with this libraries
<dholbach> nxvl: both with different sonames?
<nxvl> should i remove them from the orig.tar.gz and link them as build-dep?
<dholbach> eh?
<nxvl> i have
<nxvl> inside the code
<dholbach> what does "has 2 libraries on the source" mean?
<nxvl> a dir called "gnulib"
<dholbach> you mean it ships with the code of two build-deps?
<nxvl> inside it there is "lib  m4  tests
<nxvl> yep
<nxvl> something like that
<nxvl> those are 2 gnu libs
<dholbach> in that case that makes sense - best to document what you need to do generate your orig tarball
<nxvl> well, i think is just one
<dholbach> I guess you'll need to remove the dir, change Makefile.am and run automake/autoconf again
<nxvl> but it also build the tests, don't know why
<dholbach> also I'd talk to upstream
<nxvl> yes, that i will at weekend
<dholbach> did you check if there's a configure option to build with external libraries?
<nxvl> after i finish my tests
<nxvl> nop
<dholbach> if not, upstream should add it
<nxvl> just playing from now on
<nxvl> i also tried to check at the src.rpm package
<nxvl> but it's a mess
<dholbach> sometimes you can pass something like       --libdb-dir=/usr/share/include/something     to let it build with an external library (provided by the distribution)
<dholbach> in that case you wouldn't have to repack the tarball
<nxvl> but i don't find useful to have a library using bites in the orig.tar.gz without any reason
<dholbach> I agree - it's definitely something to ping upstream about
<nxvl> i will send them an e-mail
<dholbach> excellent
<dholbach> what project is it?
<nxvl> augeas
<nxvl> http://augeas.net
<dholbach> ah right - there was something in the server team meeting about it, right?
<nxvl> yup
<nxvl> and i'm taking care of it
 * dholbach hugs nxvl
<dholbach> keep up the good work!
 * nxvl HUGS dholbach back
<nxvl> btw
<nxvl> on Friday i show your packaging101 video
<nxvl> it was cool for a quick introduction
<nxvl> then when i explain everything in more detail and do all the work with them they understand quicker
<dholbach> great - I'm very happy it was useful to you
<nxvl> yes, it was great since i use ed to :D
<nxvl> i will use it from now on
<dholbach> hehe
<cody-somerville> Does anyone know how I can find out whats on the other side of a socket?
<nxvl> and it seems i have a lot of Packaging Jams comming in the short time
<nxvl> :D
<nxvl> cody-somerville: as in?
<dholbach> really? where are you going to run them?
<nxvl> i'm running some workshops on my university
<cody-somerville> nxvl, like, I see process has fd X open and it is a socket
<nxvl> every Friday i think
<cody-somerville> nxvl, how do I see what is on the other end of the socket?
<nxvl> last one was about packaging 101
<nxvl> this friday i will patch some bitsize
<dholbach> nxvl: great
<nxvl> next saturday (i thin) i'm going to other university to run one
<dholbach> nxvl: I'm so happy to see South America kicking arse like that
<nxvl> cody-somerville: oh! as in that, don't know, sorry
<nxvl> dholbach: my goal is to have at least 5 people involved for end of year
<dholbach> if you look at the GlobalBugJam page, most Bug Jams look like they're happening in South America :)
<dholbach> ROCK! :)
 * dholbach hugs nxvl
<pwnguin> cody-somerville: netstat?
<pwnguin> yea, netstat
<cody-somerville> pwnguin, Isn't that only for network sockets?
<pwnguin> you should try it on a desktop real quick and look
<cody-somerville> interesting
<pwnguin> UNIX sockets are sockets too
<cody-somerville> does the I-Node correspond to the number given by looking at where the fd links to?
<pwnguin> it should
<pwnguin> i mean, that's how I'd write it
<pwnguin> but thats not always a good way to reason about things ;)
<cody-somerville> hmm..
 * nxvl HUGS dholbach back
<dholbach> :)
<cody-somerville> It doesn't seem to give me anything useful though
<nxvl> dholbach: there is already one on his way to motu
<cody-somerville> pwnguin, If I see that an application is hanging waiting for activity on fd which is a socket, whats the best way to debug?
<nxvl> dholbach: Roaksoax
<dholbach> ah great
<nxvl> dholbach: also i have 2 people saying they will start some day
<nxvl> but i don't belive them anymore
<pwnguin> cody-somerville: you might want to file a bug against the manpage
<nxvl> i hope that in the GBJ more people come into the project
<pwnguin> for netstat
<pwnguin> it's not done =(
<nxvl> it is a really good way to teach people the full process of a bug report and how to contribute
<nxvl> :D
 * cody-somerville narrows eyes.
<nxvl> and since i'm getting out of time because of the work i will need to focus on recluting some people, didn't i?
<pwnguin> cody-somerville: http://www.ecst.csuchico.edu/~beej/guide/ipc/
<nxvl> ok, now time for bed
<nxvl> see you later
<dholbach> sleep tight
<nxvl> thanks!
<cody-somerville> pwnguin, Although that looks like a good guide to using unix sockets pragmatically, it is lacking on debugging of said applications.
<pwnguin> doh
<pwnguin> ok, well this is a bit hamhanded, but you could strace one side of it
<cody-somerville> I did strace it
<cody-somerville> and it told me that it was hanging on fd 13 which is a socket
<pwnguin> so what's on the other side of it?
<cody-somerville> Thats what I'm trying to figure out :)
<cody-somerville> https://bugs.edge.launchpad.net/ubuntu/+source/dbus/+bug/232364 for details
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed]
<pwnguin> hmm. that sounds like a bug i'd like fixed
<cody-somerville> same here :)
 * pitti hugs kees for his devmapper fix; I think that fixes bug 238793?
<ubottu> Launchpad bug 238793 in devmapper "[Intrepid] boot failure: by-uuid symlinks not created" [High,In progress] https://launchpad.net/bugs/238793
<pitti> kees: thanks for cleaning up after me
<pwnguin> cody-somerville: ok. so after reviewing the internet literature, inodes are unique per connection, and the file is the name space
<pwnguin> cody-somerville: wait, how is this guy running 2.6.26?
<cody-somerville> pwnguin, maybe it is a typo
<cody-somerville> I experience the issue too and I'm using the vanilla ubuntu kernel so that can't be it
<pwnguin> you dont typo -rc3 but you're right, it's got dupes so that's probably not it
<pwnguin> cody-somerville: so lsof gives an inode. use that to find the file name with "netstat | grep $fid", then "netstat --programs | grep $filename"
<cody-somerville> pwnguin, Okay. I'll do that the next time it freezes.
<pwnguin> good luck!
<cody-somerville> Considering the backtrace, would it not be safe to assume though that it is the bilateral connection to the X server consider what dbus-launch --exit-with-session does?
<cody-somerville> Interesting.
<pwnguin> cody-somerville: im afraid im not qualified to understand half of that question
<cody-somerville> http://bazaar.launchpad.net/~vcs-imports/dbus/main/revision/1652
<cody-somerville> Could passing an int when a long is expected cause the crash? :/
 * fabbione hugs seb128 
<seb128> hey fabbione, is that because of the football game yesterday? ;-)
<fabbione> indeed :)
<fabbione> i was just waiting for you ;)
<seb128> hehe
<seb128> can't always win ;-)
<pwnguin> cody-somerville: that diff is too big =(
<fabbione> oh i know.. it will be our turn sooner or later
<seb128> I've been impressed by how netherland has been playing, let's see what they do next ;-)
<cody-somerville> pwnguin, very bottom
<fabbione> but the feeling of "twice in a raw" between World Champion and EU cup... is GOOD! :P
<pwnguin> cody-somerville: i guess you're bisecting it?
<cody-somerville> It is freezing when opening the connection to the xserver,
<pwnguin> i think this is a race
<pwnguin> im not sure what happens if a message is sent before dbus-launcher has connected
<pwnguin> the number of race condition bug reports in dbus bugzilla is not endearing
<cody-somerville> pwnguin, join #xfce-dev
<cody-somerville> please :)
<psypointer> hi
<psypointer> i'm working with the ubuntu hardy proposed webinstaller. i've got many problems with the client installation. at the package installation the downloading of a random package often fails with "400 Host Header missing"
<psypointer> is this a known bug?
<psypointer> http://pastebin.ubuntu.com/21096/ thats the syslog
<ion_> Broken server at http://10.255.255.250/?
<psypointer> ion_: that would mean that apt-cacher is broken..
<psypointer> (verifying this is my next step, but this would be really strange)
<psypointer> hm, not it seems to work after manually starting the cleanup script. i'll fill a bug report, bye
<Chipzz> pitti: did you check if the new dhcp3-server-ldap package actually works? I had some minor problems with that package installed from debian testing a while ago
<Chipzz> pitti: it lacked a directory in IIRC /var/lib
<Chipzz> (yeah I should have filed a bug report in debian :P)
<fabbione> dendrobates: ping?
<dendrobates> fabbione: hey.
<fabbione> hey dude
<fabbione> got a minute?
<dendrobates> fabbione: for you, of course.
<fabbione> ehehe :)
<fabbione> dendrobates: http://www.redhat.com/archives/cluster-devel/2008-June/msg00116.html
<fabbione> dendrobates: ^^ maybe somebody in the server team might be interested
<dendrobates> fabbione: where will it be held?
<fabbione> dendrobates: like it's writted down in the email.. depends from the list of participants
<cody-somerville> pwnguin, are you coming back?
<fabbione> dendrobates: we will calculate the center of the universe for the devels that will be there and then decide a location
<pwnguin> nope
<fabbione> dendrobates: dates maybe August or from mid-Sept to end-Oct
<pwnguin> that got outta my league fast
<fabbione> dendrobates: depending on venues availability
<cody-somerville> pwnguin, but we're making progress :)
<fabbione> dendrobates: but mostlikely US... exactly where i can't say
 * cody-somerville is way way out of his league too ;]
<dendrobates> fabbione: ok, I'll discuss it with the team.
<fabbione> dendrobates: ok cool.
<pwnguin> cody-somerville: 80 percent of development is reading code. i suggest finding people who've already read the code and ask their opinions
 * cody-somerville nods.
<pitti> Chipzz: actually no, I don't have an ldap setup; however, -ldap just diverts the binary from -server
<slangasek> mvo: ping on bug #220890; should this get uploaded to hardy-proposed?
<ubottu> Launchpad bug 220890 in software-properties "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [High,Confirmed] https://launchpad.net/bugs/220890
<mvo> slangasek: I would rather want to have it tested first, but if there is no ppc available, then -proposed is the only option
<cody-somerville> pwnguin, btw, does dbus-launch --exit-with-session run for you in gnome?
<cody-somerville> It isn't for me.
<Tim20> im trying to build 2 deb packages, when running dpkg-buildpackage on the second, i get the error "dpkg-shlibdeps: failure: no dependency information found for <lib from first deb>". i've tried making a postinst file on the first deb to run ldconfig, and i've tried making the first deb via checkinstall, but neither method worked.
 * Hobbsee wonders who broke the intrepid mimetypes.
<Hobbsee> unless i'ts somehow pebkac.
<Hobbsee> seems that one program will try to open all files now.
<cjwatson> Tim20: are the two binary packages built from a single source package?
<pitti> anyone here using PostgreSQL? I need some testing feedback in bug 238587
<ubottu> Launchpad bug 238587 in postgresql-8.3 "PostgreSQL bug fix releases 8.3.3/8.2.9/8.1.13" [High,Fix committed] https://launchpad.net/bugs/238587
<pitti> I tested them myself thoroughly, so I think they are good, but for SRU I need a second "thumbs up"
<Tim20> cjwatson, no, and one is a single lib package
<Tim20> may have fixed it, just rebuilding them now. cross fingers. :)
<Chipzz> pitti: you don't need an actual ldap setup to test it; traditional config file will work too
<Chipzz> or rather, break when it finds that directory doesn't exist
<pitti> Chipzz: ah, is that Debian bug 484424?
<ubottu> Debian bug 484424 in dhcp3-server-ldap "Can't open lease database /var/lib/dhcpd/dhcpd.leases: No such file or directory" [Unknown,Open] http://bugs.debian.org/484424
<Chipzz> pitti: yeah
<Chipzz> pitti: I suspect it's missing a configure option to specify the correct dir?
<pitti> I guess so, yes
<Chipzz> pitti: hrrrm, just took a look at the build log; apparently no such option is passed to either build?
<Chipzz> http://launchpadlibrarian.net/15370081/buildlog_ubuntu-intrepid-i386.dhcp3_3.1.1-1ubuntu1_FULLYBUILT.txt.gz
<pitti> seb128: are you currently working on a gdm merge?
<pitti> seb128: I wonder whether I should apply lifeless' small patch in bug 234101 now, or just ask you to include it
<ubottu> Launchpad bug 234101 in gdm "Support latin locale" [Undecided,Triaged] https://launchpad.net/bugs/234101
<seb128> pitti: as said before there is no merge required, we need to package the rewrite
<seb128> pitti: feel free to upload that if you want, packaging the new gdm will take some time
<pitti> ok
<seb128> especially that I don't know what to do about the configuration
<seb128> it moved from a text file to gconf and don't have the same option
<seb128> and there is no migration code
<seb128> I'm wondering if we should attempt to write one
<pitti> gconf?
<pitti> oh, right. gdm user
<pitti> seb128: is that the file gdmconfig writes?
<pitti> in this case it would be nice indeed
<seb128> pitti: yes
<pitti> bummer
<seb128> would be nice but it'll not be trivial
<seb128> especially that some of the option don't exit in the new code
<seb128> s/exit/exist
<pitti> right, was just going to say
<pitti> no need to handle options which can't be sensibly mapped to the new code
<emgent> morning
<jdstrand> hi Riddell! Now that I got the samba update out the door, I have (finally) moved my focus to chmlib. kees and I will talk about libzip too
<Riddell> jdstrand: I'm holding my breath!
<jdstrand> heh
<broonie>  /win 24
<emgent> morning dendrobates
<Hobbsee> slangasek: did you want to look into https://bugs.edge.launchpad.net/ubuntu/+source/gnuplot/+bug/195111 ?  Looks like it needs demoting to multiverse.
<ubottu> Launchpad bug 195111 in gnuplot "gnuplot is not GNU and not free Software" [Critical,Confirmed]
<cjwatson> Hobbsee: the requirement to distribute as patches is explicitly allowed by http://www.ubuntu.com/community/ubuntustory/licensing
<cjwatson> which other part of that is non-free?
<Hobbsee> cjwatson: oh, my error.
<cjwatson> the only bit flagged by debian-legal as potentially awkward was the contact identification thing, which could be read to prohibit anonymous modifications (although I don't buy that inference)
<cjwatson> happy to have a second opinion, but I think it's fre
<cjwatson> e
<Hobbsee> cjwatson: can i yoink your comments, and mark as invalid?
<cjwatson> (and indeed I think there *should* be a second opinion)
<cjwatson> iff you have thought about my arguments and agree with them :-)
<Hobbsee> cjwatson: oh, i see your arguments.  my brain is just somewhat still fried by the maths this morning.
<cody-somerville> pitti, you did a lot of the work on avahi, right?
<cody-somerville> cjwatson, are we able to move the Xubuntu seeds yet?
<pitti> cody-somerville: not that much actually
<cody-somerville> pitti, would it be safe to set the avahi stuff as recommends in the seeds?
<pitti> cody-somerville: which 'stuff'?
<cody-somerville> https://bugs.edge.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/192258
<ubottu> Launchpad bug 192258 in xubuntu-meta "avahi should be downgraded to Suggests dependency" [Undecided,New]
<pitti> cody-somerville: ugh, long vehicle
<pitti> cody-somerville: I didn't find an actual reason why it shouldn't be installed by default, though?
<cody-somerville> pitti, I just want to allow the guy to be able to uninstall it w/o having to remove xubuntu-desktop
<pitti> cody-somerville: suggests in metapackages do not make sense; downgrading to recommends is doable, of course, and should be done, so that people can uninstall avahi if they want to
 * cody-somerville nods.
<cody-somerville> My thinking exactly.
<pitti> cody-somerville: but I would heavily object to dropping it altogether
<pitti> stuff like nss-mdns is soo useful, and not a security threat at all
 * cody-somerville nods.
<cody-somerville> I just wanted to make sure it is safe to set it as a recommend :)
<pitti> cody-somerville: I'll comment on the bug
<cody-somerville> Ok
 * ogra_cmpc thinks the only problem avahi really has is lots of people not really knowing anything about it and spreading FUD
<ogra_cmpc> i havre run in so obscure arguments in discusssions already :)
<cjwatson> cody-somerville: so we need to run two identical branches in parallel for a while, until we get the LP code change made
<cjwatson> cody-somerville: just push the usual branch to wherever the new location ought to be *as well*
<cody-somerville> cjwatson, okay.
<cjwatson> cody-somerville: and, for a while, you'll need to remember to push to both places
<cody-somerville> cjwatson, I can't push to core-dev
<cjwatson> well, push to the new location and get somebody to pull from there to core-dev, then
<cjwatson> which team were you going to use for the new seeds? I think I'd recommend just xubuntu-dev
<cjwatson> ideally it ought to match the set of people you'd like to be able to upload Xubuntu packages in general (in the as-yet-unimplemented new world order)
 * cody-somerville nods.
<\sh> pitti: will you kill me, when I ask you to add libnspr* to ia32-libs? ,->
<pitti> cody-somerville: answered
<pitti> \sh: ugh?
<seb128> hey doko
<seb128> doko: do you plan to do a subversion upload to intrepid soon?
<doko> seb128: no, not this week. is 1.5 released?
<seb128> doko: no, but it creates installability issues in intrepid
<seb128> it needs a rebuild
<seb128> doko: gicmo would like to be able to use git-svn again to be able to commit fixes to GNOME ;-)
<rexium> hey everyone, I have noticed a problem with openexr. With the release of openexr 1.6.1, upstream has seperated out some of the code into a package called ilmbase. Ilmbase has been auto-synced but it is in universe. Openexr has been modified in debian unstable to reflect the dependancy change but now would depend on a package in universe. Suggestions on how to handle this? Also, is there any documentation I can read about handleing library tra
<rexium> nsitions?
<rexium> I should note that openexr1.6.1 is held up in a merge (though I think it could be a sync)
<doko> seb128: I'll see what I can do
<seb128> doko: thanks
<rexium> doko, you are listed as the last uploader for openexr, do you have any ideas?
<doko> rexium: ideas about what?
<rexium> doko, Openexr, have a look at the scrollback
<doko> rexium: please file a MIR for ilmbase, and then a sync request (or propose a merge in a bug report)
<rexium> ok
<emgent> dendrobates: take a look http://en.emanuele-gentili.com/index.php/2008/06/18/rapache-02-1-alpha-packaged/
<dendrobates> emgent: ok,
<emgent> dendrobates: now work only in local, in stage-3 i will add ssh support for remote managing.
<gicmo> mvo: an update of compiz wants to remove compizconfig-backend-gconf, is that ok?
<dendrobates> emgent:  it looks interesting, I'll install it and see what I think.
<seb128> gicmo: you should rather wait for this one to build
<gicmo> oh
<gicmo> ;-)
<gicmo> I realized that updating would work anyways due to dependency issues
<seb128> wouldn't?
<gicmo> exactly
<mvo> gicmo: hm, I need to check that, it sounds like one of the dependencies is not updated correctly - thanks for letting me know
<mvo> gicmo: wait a sec with the compiz update first please
<gicmo> mvo: sure
<mvo> until the new compizconfig-backend-gconf is build
<gicmo> ok
<emgent> dendrobates: ok thanks, i'm thinking to possiility to add rapache in intrepid (stable version)
<emgent> s/possiility/possibility/
<\sh> pitti: I've been playing with Adobe Flash Media Server...and it needs libnspr* in i386 mode :)
<\sh> pitti: and some symlinks to simple .so links to the libs :) so that it can run properly...could be needed for the server flavour and gives RHEL a good clap
<greedo> hello, i would like to know if System > Preferences > Keyboard shortcuts is ubuntu specific or if it's just a gnome feature
<greedo> the reason why i'm asking is because shortcuts are associated with keycodes but the keycodes don't have keysym attached
<greedo> so querying the keyboard mapping through xlib returns keycodes that are apparently unused but this is not the case in fact since they trigger global shortcuts
<rexium> doko, fyi, I  have filed the MIR
<mterry> greedo: I believe it's a GNOME thing
<greedo> mterry: ok, well on #gnome-hackers they told me it's an ubuntu thing :)
<mterry> greedo: Then they must be right.  :)
<zul> pitti: hi can you accept the samba sitting in proposed? thanks
<pitti> zul: please talk to slangasek now, since we are frozen for .1
<zul> pitti: okies I will thanks
<kees> pitti: ah! I hadn't found the LP bug for the dmsetup uuid breakage.  no problem -- certainly not your fault, debian reduced the "export" patch for some reason.
<pitti> kees: well, I should have tested it better before upload; but I didn't actually test it with root-on-raid *brown paperbag*
<jetsaredim> ï»¿if i've run into an issue with the installation cd for ubuntu-server - what package would i file that bug against?
<MacSlow> anybody with some knowledge about consolekit... who might know where the binary ck-get-x11-display-device should come from?
<cody-somerville> jetsaredim, At what point did the install problem occur?
<jetsaredim> cody-somerville: two places
<pitti> MacSlow: http://packages.ubuntu.com/search?searchon=contents&keywords=ck-get-x11-display-device&mode=exactfilename&suite=hardy&arch=any
<pitti> MacSlow: "locate ck-get-x11", too
<jetsaredim> first - failed to detect cdrom drive so I had to get to the shell and modprobe ide_generic
<MacSlow> pitti, ah... forgot about the handy tool locate... thanks!
<kees> pitti: heh.  well, it still may not have shown up without UUID-based lvm mounts (many people mount via the /dev/mapper name).  regardless, it was fun to use my udev debugging skills.  :)
<jetsaredim> second - during the disk wizard the / partition was not marked as bootable
<seb128> pitti: dlocate rather if you are searching which package is providing the binary
<jetsaredim> third (did I say two?) - after the install the system failed to boot
<cody-somerville> jetsaredim, https://launchpad.net/debian-installer
<tormod> we have an issue with the live CD eagerly mounting swap from raid raw devices, can someone have a look at bug #136804?
<ubottu> Launchpad bug 136804 in casper "livecd auto mounting swap partitions detected on dmraid volume members" [Undecided,Confirmed] https://launchpad.net/bugs/136804
<pitti> cjwatson: hm; do you have any idea why avahi-daemon is a dependency in ubuntu-desktop? It's not seeded anywhere
<cody-somerville> pitti, I think it is in platform maybe?
<pitti> oh, right
<tormod> sorry wrong channel, I though this was #ubuntu-installer for a second
<cjwatson> pitti: platform.intrepid/desktop-common
<cjwatson> jetsaredim: it isn't usually necessary for / to be marked as bootable - BIOSes just need *a* bootable partition
<pitti> cjwatson: thanks
<cjwatson> Windows cares, but Ubuntu doesn't
<cjwatson> so we leave it alone unless there's no bootable partition on the disk
<cjwatson> jetsaredim: CD drive not detected is a kernel problem; /ubuntu/+source/linux
<cjwatson> cody-somerville: please don't file bugs on /debian-installer - /ubuntu/+source/debian-installer at most
<cjwatson> /debian-installer is the upstream project
<pitti> cody-somerville: bug 192258 updated
<ubottu> Launchpad bug 192258 in ubuntu-meta "avahi should be downgraded to Recommends:" [Wishlist,Fix committed] https://launchpad.net/bugs/192258
 * sladen celebrates filing a bug with three zeros at the end
<sladen> ...that's only happened about 250 times before!
<persia> sladen: For extra points, try for 4 zeros :)
<slangasek> pitti: ref zul's samba SRU - if we're going to change the smbclient defaults for .1, then I need to reject that other SRU; if we're going to leave the smbclient defaults alone, then it stays put until after .1
<norsetto> mvo: are you around?
<slangasek> pitti: so I'm still hoping you'll tell me which way we should go on the smbclient question for SRU, since I feel I should recuse myself
<cjwatson> hmm, so an intrepid daily now exists, but the boot loader is mysteriously a bit buggered
<cjwatson> but, it boots ...
<cjwatson> detect keyboard layout hosed
<cjwatson> fails to mount CD. damn.
<cjwatson> ah, no isofs
<james_w> doko: mind if I ask for ca-certificates to be synced? Debian uploaded a fixed package.
<doko> james_w: sure, there is one ubuntu change outstanding
<james_w> doko: ah, sorry, we don't want to sync really, as they now have the fix that we dropped post-hardy.
<slangasek> zul: ah, your SRU has a version number conflict with a security update anyway, it seems; rejecting from the queue
<slangasek> zul: ... rather, the first one, not the second renumbered one
<zul> yeah that was uploaded this morning
<cody-somerville> pitti, thanks.
<pitti> slangasek: hm, I thought I agreed to the compromise of reenabling LANMAN in hardy and disabling it in intrepid?
<pitti> slangasek: (assuming that LANMAN is "insecure" as in md5, and not as in libssl/hardy-final
<slangasek> pitti: is "agreeing to" the same as telling me I should upload it?
<slangasek> :-)
<pitti> slangasek: at this point it seems like the only realistic alternative for .1 anyway, so yes
<slangasek> it's unhashed, case-insensitive, 7-bytes-at-a-time md4
<slangasek> so it's significantly more insecure than md4, if you MITM it
<slangasek> er, more insecure than md5
<pitti> slangasek: so, it's not completely broken, just terribly weak, such as WEP64
<slangasek> pitti: well, consider that a client can be tricked by an attacker into using LANMAN when it's enabled on the client side, instead of using NTLM
<e-gandalf> asac: ping
<seb128> pitti, slangasek: I agree that we should do the change for 8.04.1 because we will not change gvfs to handle that nicely before 8.04.1
<slangasek> pitti: thus compromising a user password that may be used in contexts where the security is assumed to be much stronger than just LANMAN
<seb128> we might want to reconsider for 8.04.2 ;-)
<slangasek> pitti: so, with that additional explanation, what's your position?
<nxvl> hi
<nxvl> i'm having some problems/questions packaging a library
<nxvl> the library ships with gnulib in the source
<nxvl> so i'm removing it from the source to add it as Build-Depend
<nxvl> but it's kind of hard coded on the Makefile and configure script
<nxvl> did anyone can point me to the best way to deal with this?
<seb128> slangasek: btw upstream is working on fixing the authorization changes, they spotted issues with your new version
<seb128> slangasek: the guy reviewing it said it broke the anonymous login case
<slangasek> seb128: um, ok; do you know how he intends to fix that without a completely new UI?
<pitti> slangasek: my gut feeling says to keep it disabled, and the pragmatical pressure from users to reenable it; so TBH I'm not 100% sure myself
<slangasek> pitti: well, you and seb128 pick an option please, and let me know if I should upload :)
<pitti> seb128: I'd lean towards keeping the status quo and fix it post .2, since, as you just said, there are new issues with slangasek's proposal, and the matter is still not fully discussed?
<pitti> erm, post .1
<slangasek> pitti: his comment above is in reference to a different bug
<pitti> ah, ok
<seb128> slangasek: what new ui?
<pitti> seb128: the proper error reporting, I guess
<seb128> slangasek: well it should at least ask for a password when anonymous login is not authorized
<pitti> "unsafe server configuration, see README"?
<slangasek> seb128: I don't know - how can he "fix" the anonymous case, when the whole problem in this bug is that anonymous logins were being given precedence over authenticated logins
<pitti> and README describes how to poke the admin, or the workaround with enabling LANMAN in smb.conf
<slangasek> seb128: if it only asks for a password when anonymous login is not authorized, then we have the same exact behavior we have now
<slangasek> pitti: talking about the other bug, again ;)
<pitti> hm; sorry; *which* bug are we currently discussing then?
<mario_limonciell> before the system goes down for a reboot at the end of the install, should all modules already be properly unloaded (eg rmmod), or is it possible that some will  be left dangling?
<pitti> slangasek: I think I only discussed the LANMAN bug with you
<slangasek> pitti: bug #207072
<ubottu> Launchpad bug 207072 in gvfs "nautilus does not display samba shares for machines inside an ADS network." [Unknown,Confirmed] https://launchpad.net/bugs/207072
<seb128> pitti: right the second one is work in progress and there is not much to discuss
<seb128> slangasek: well the issue is that right now it nevers ask for a password, anonymous and password being authorized is yet another case and trickier to solve
<seb128> you don't want to ask for a password when anonymous works
<pitti> seb128: so for that second one, we keep current samba and provide better error message after .1; is that still the consensus?
<seb128> and you still want to be able to provide one if required
<seb128> pitti: yes
<slangasek> seb128: er, yes, you /do/ want to ask for a password when anonymous works; anonymous "works" with all of the servers of the people subscribed to that bug, it just gives an empty list of available shares
<pitti> so ideally the dialog would always present user/password, but if you don't enter anything, try anonymous?
<pitti> (and point that out in the dialog)
<pitti> well always present -> if there's nothing in the keyring
<slangasek> ideally something along those lines, yes
<pitti> anyway, I need to leave for Taekwondo; but I have no clue about this bug anyway
<slangasek> seb128: if we're not going to solve the problem that unauthenticated connections will succeed but give you the wrong share list, then we're not addressing the problem the users are having in that bug, so we might as well forget about SRUing anything
<slangasek> pitti: waaaait, am I uploading samba or not? :-)
<pitti> slangasek: that samba upload is for yet another bug then?
<slangasek> pitti: the samba upload is for the LANMAN bug
<seb128> slangasek: yes, we have consensus for this one
<pitti>    pitti| seb128: so for that second one, we keep current samba and provide better error
<pitti>           message after .1; is that still the consensus?
<pitti>  seb128| pitti: yes
<slangasek> ok, so - no upload of samba
<slangasek> thanks :)
<pitti> I vote for that, too; WDYT?
<seb128> oh, I didn't understood it this way
<pitti> I really like to err on the side of correctness, TBH
<seb128> hum
<seb128> I really like to be on the "just work" side
<pitti> seb128: ok, once again I'm confused
 * pitti arghs
<slangasek> :-)
<seb128> so I would authorize those login until we have the error dialog
<pitti> "go to square one. do not pull $4000"
<seb128> sorry too many things at the same time
<seb128> we always had those authorized and that has never been an issue until now
<slangasek> I think I find seb128's position persuasive
<pitti> well, md5 and weak ssl keys also hadn't been an issue until someone discovered that they are bad
<pitti> admittedly I still don't have a clear idea how weak the LANMAN keys actually are, but Steve made me think it's dead easy to break them
<slangasek> if you MITM the connection, yes
<seb128> pitti: let's continue that discussion later or you will miss your classes
<pitti> so if we can say in good faith "it's easier to bruteforce your password than MITM/mathematically break LANMAN", I'm ok with enabling
<pitti> if it's dead easy as in "significantly easier than bruteforcing passwords", then I don't think we should allow it any further
<slangasek> significantly easier
<pitti> and while we won't provide better errors in .1, we should still aim to provide them within a reasonable time frame, such as a month from now, or so
<slangasek> anyway, if we let this go much further without a decision, the default is going to be to not change samba for .1
<seb128> let's decide tomorrow morning
<slangasek> ok
<seb128> no other distribution did the change and we used the non secure thing until now
<pitti> so, I think I pointed out my personal opinion, based on the facts I read so far (weakness of keys, and percentage of affected users)
<seb128> so I think we can live with the option on until we figure something
<seb128> and solve that in hardy-updates after 8.04.1
<slangasek> seb128: OTOH, the change is made upstream for samba 3.2, which will release in the next two months and is already targeted for next Fedora, at least
<seb128> solution = ui in nautilus
<slangasek> so by the time we get done re-enabling it, others will be disabling it ;)
 * pitti <- really has to run now, sorry
<seb128> pitti: see you later
 * slangasek waves. Sorry for holding you up :)
<pitti> no problem; I'll just bicycle a little faster :)
<seb128> that's tricky, but I'm not a security guy so I'm not best placed to judge how much exposure to attacks it gives
<seb128> I guess I'm fine with letting it this way and pushing gvfs or nautilus changes to hardy-updates after 8.04.1
<YokoZar> Was there a new date for Intrepid Alpha 1?
<ogra> YokoZar, hey, congrats to v1.0
<YokoZar> ogra: Thank you.  I spent all yesterday getting 1.0 working on everything from Dapper to Intrepid (also Etch) :)
<ogra> cool
<gicmo> mvo: Hey, the buttons are working correctly again, thanks champ!
<kees> hm, kinda cool: http://start.gotapi.com/
<nxvl> lucas: around?
<bryce> kees: hey do you know if there is a tool for taking a debian changelog and a ubuntu changelog and merging them together (like MoM does)?
<jdstrand> kees: what do you think about the libzip audit?
<kees> bryce: beyond just a straight "diff" or possibly interdiff, not really
<kees> bryce: but I think the MoM source is somewhere in bzr, but I can never remember where
<jdstrand> kees: it's small but I may not finish til beginning of next week
<kees> jdstrand: I haven't had time yet to look at it, and I suspect I'm going to be baby-sitting the kernel security publication for a while today.
<bryce> hmm
<kees> jdstrand: if I have time, I'll snag it, otherwise we can work it out tomorrow.  :)
<jdstrand> kees: I just finished chmlib, and am audited out for today
<kees> anyone know what replaces iceape-dev?
<jdstrand> kees: so I guess we'll battle it out then :)
<kees> :)
<slangasek> isn't iceape obsolete?  that would be "seamonkey", which was the monolithic suite
<bryce> aha https://code.launchpad.net/merge-o-matic
<kees> slangasek: well, gtk-vnc is in a wait-dep for iceape-dev which will never exist...
<kees> slangasek: (and virt-manager needs modern gtk-vnc, etc etc)
<slangasek> kees: if we still have a mozilla-dev, then iceape-dev is that; otherwise, it's obsolete and the build-dep needs to be fixed to point at something more useful
<kees> slangasek: right, I was looking for "more useful" ;)  I think it might be xulrunner-1.9-dev
<slangasek> mayyybe
<slangasek> there is a mozilla-dev package, fwiw
<slangasek> which is the cognate
<kees> asac: can you poke at this (gtk-vnc needing iceap-dev) when you're back?  it seems something should be providing a meta-package or something, maybe?  mozilla deps are a mystery to me.  :)
<slangasek> kees: the mozilla ice* rename is a divergence between Debian and Ubuntu
<slangasek> and xulrunner-1.9-dev is by no means guaranteed to be compatible with mozilla-dev
<kees> slangasek: but mozilla-dev is in universe and virt-manager (and gtk-vnv) have been in main, so something got wonky.
<slangasek> sure. is this in intrepid?
<wasabi> general dpkg question: trying to get a trigger that runs ONCE at the end of an install set. I have a trigger now, but it runs like, 4 times, in between some packages that invoke it. It is being triggered though, just can't figure out why so often.
 * jdstrand wonders why gtk-vnc needs iceape-dev/mozilla-dev at all
<jdstrand> 0.3.4 didn't
<jdstrand> ah-- mozilla plugin maybe
<jdstrand> gtk-vnc (0.3.4-2) experimental; urgency=low
<asac> kees: yes, i think seamonkey-dev should be used (but needs to b fixed first)
<jdstrand>   * enable the browser plugin
<asac> if its not a xpcom plugin, we can use xulrunne-1.9-dev too
<slangasek> seamonkey-dev is also in universe
<jdstrand> kees: just diable the plugin like we did in 0.3.4-0*
<asac> right, but it needs the sdk :)
<jdstrand> kees: then it can stay in main
<kees> jdstrand: hm, bad merge?
<jdstrand> *shrug*
<asac> is gtk-vnc in main?
<kees> yeah
<asac> oh. ok then it should go for xulrunner-1.9-dev i guess
<jdstrand> DEB_CONFIGURE_EXTRA_FLAGS += --with-python --with-gtkglext --with-examples --enable-plugin=yes
<jdstrand> change that to 'no' and we should be ok, assuming xulrunner doesn't work for us
<asac> it should work
<kees> xulrunner-1.9 doesn't seem to work.
<kees> checking for MOZILLA_PLUGIN... configure: error: Package requirements (iceape-plugin >= 1.0) were not met:
<asac> kees: can you look in configure.* and tell me which pkg-config it uses?
<kees> No package 'iceape-plugin' found
<asac> kees: yeah. use libxul
<asac> or libxul-unstable
<kees> har har, there is a patch "xulrunner-not-mozilla.diff"
<asac> what does that contain?
<kees> but it switches from mozilla-plugin to iceape-plugin
<slangasek> heh
<kees> -MOZILLA_PLUGIN_REQUIRED=1.8
<kees> +MOZILLA_PLUGIN_REQUIRED=1.0
<kees> -                          mozilla-plugin >= $MOZILLA_PLUGIN_REQUIRED)
<kees> +                          iceape-plugin >= $MOZILLA_PLUGIN_REQUIRED)
<asac> kees: that should work too
<asac> just drop that patch
<kees> asac: is there some Debian-proof way to adjust xulrunner-1.9 to provide iceape-dev?
<kees> (i.e. so we don't have to carry a patch)
<asac> kees: in this case we have to drop a patch :) ... not carry it
<kees> what pkg provides mozilla-plugin?
<asac> kees: xulrunner-1.9-dev
<kees> rockin'
<asac>  dpkg -L xulrunner-1.9-dev | grep plugin.pc
<asac> /usr/lib/pkgconfig/mozilla-plugin.pc
<asac> kees: debian diverges from upstream here
<asac> :-P
<asac> kees: for universe we can provide iceape-dev as a virtual package in seamonkey
<kees> <sarcastic> \o/ </sarcastic>
<asac> kees: main redepends should be fixed
<kees> fixing...
<jdstrand> kees: is that the same as /o\
<kees> jdstrand: head-holding.  :)
<jdstrand> kees: exactly
<asac> slangasek: just saw that we have aa action item to talk about firefox 3 final on CD. I assume thats done now, right?
<slangasek> asac: yes, that's done
<asac> good
<gandi> asac: piiing :)
<asac> gandi: ?
<gandi> asac: I'm the Mozilla guy from UDS, maybe you remember me ;)
<gandi> asac: I need your help
<asac> gandi: consider #ubuntu-mozillateam :)
<asac> gandi: but hi!
<gandi> oh, that's the channel name!
 * nxvl HUGS asac for ff3!
 * asac hugs nxvl 
<kees> \o/ gtk-vnc compiled
<mvo> ScottK: re bug #231098 - there is currently no sun-java6-plugin for amd64, should I add sun-java6-jre regardless ?
<ubottu> Launchpad bug 231098 in ubuntu-restricted-extras "Please add sun-java6-jre and sun-java6-plugin to *ubuntu-restricted-extras" [Wishlist,Fix committed] https://launchpad.net/bugs/231098
<mvo> I don't mind either way
<jpeirce> really, /j #ubuntu-motu
<jpeirce> err, oops, sorry :)
<pwnguin> did imbrandon leave ubuntu?
<jpds> pwnguin: no, I think he's busy with other things.
<pwnguin> I haven't heard or seen him in ages
<pwnguin> jpds: technically I think going six months of "busy with other things" without mentioning it is a CoC violation
<jpds> pwnguin: "life happens"
<pwnguin> but doing much about it is akin to giving out the death penalty for attempted suicide
<pwnguin> jpds: "Step down considerately" is one of the CoC line items, and there are bugs assigned to him =/
<bryce> kees: bingo
<bryce> kees, 'merge_changelog' now lives :-)
<kees> bryce: ah-ha! excellent.
<bryce> http://people.ubuntu.com/~bryce/scripts/merge_changelog
<james_w> bryce: http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2008-January/000101.html
<mterry> Is there a convenient way to have something load on user-login just once?  I know I can drop stuff into ~/.config/autostart/, but if I want it to be one-time-only, do I need a wrapper app to handle the deleting of the .desktop autostart file?
<bryce> mterry: you mean like .xsession ?
<mterry> bryce: Sure, but i don't want to muck about with the user's .xsession, would be cleaner just to drop something into the autostart dir.    Plus, I'd still have one-time-only problem
<mterry> Hmm, maybe drop in a .desktop with "Exec=foo; rm ~this~"
 * mterry grins evilly
<bryce> james_w: hmm interesting, that script gives different results
<bryce> james_w: it looks like that script gets messed up if there are epoch numbers
<james_w> bryce: I doubt that script has had as much testing as yours.
<bryce> e.g. it sorts all the 2: items at the top of the changelog, and 1: at the bottom, putting everything out of order
<bryce> james_w: although it's much more concise
<james_w> yup.
<james_w> is that location a permanent home for yours?
<bryce> yeah more or less
<james_w> bryce: do you mind if I send it there to let them know about it?
<bryce> james_w: sure; I'll drop a post to ubuntu-devel@
<james_w> bryce: great, thanks.
<james_w> is there a wiki page anywhere describing pkgstriptranslations?
<seb128_> james_w: why do you want a wiki page, the package description is clear no?
<cjwatson> nxvl: don't remove gnulib from packages
<james_w> seb128_: as reference for forwarding something to Debian.
<seb128_> james_w: pkgstriptranslations should require no packaging change
<cjwatson> nxvl: gnulib is designed to be copied into source packages, not to be used as a shared library. IMO it's one of the few cases where this is actually a sensible thing to do, because it comes with a script to automatically update itself - think of it as the other half of autoconf, rather than as a normal library
<seb128_> james_w: what change is that exactly?
<james_w> seb128_: NO_PKG_MANGLE for a nested build.
<cjwatson> nxvl: you will likely hose the package in subtle ways with little hope of recovery if you attempt to remove gnulib from it
<seb128_> james_w: ah ok, I was just curious but don't know about a wiki page on the subject, maybe pitti does though since he worked on those changes
<james_w> seb128_: I took the description, it should be enough, thanks.
<seb128_> you are welcome
<james_w> though a wiki page on the whole thing might be useful for me, as I don't really understand it.
<cjwatson> nxvl: (speaking partly as an upstream with some experience of using gnulib, and partly as a contributor to gnulib)
<seb128_> james_w: the language packs? there is not a lot to understand, the translations are not installed in the normal binaries but in language packs using the rosetta translations
<james_w> that's what I'd understood. Am I right that it's good because it means translations can be improved via rosetta, and you can uninstall languages you don't care about?
<james_w> or is it mainly the former reason?
<cjwatson> it lets us do post-release updates of translations in a straightforward way with minimal risk
<cjwatson> that's really the main motivation
<james_w> ah, ok, thanks.
<cjwatson> it has some arguable space benefits although it's not clear how much they really hold
<ScottK> mvo: I think it would be better to add it.
<mvo> ScottK: thanks, that is fine with me. I will add it and upload the new version.
<ScottK> mvo: Great.
<PurplePotato> Hello
<PurplePotato> I was going to say - anyone here know the DadaDodo program for ubuntu?
<PurplePotato> It uses an imput text file to create Markov Chains of words to display. Its really weird and often creepily insightful
<PurplePotato> I put in a chineese aspiring movie script, and came out with lots of fun things
<PurplePotato> Began to use the king of which can be their power of this and
<PurplePotato> sorcery are ready to show his mother throws the old tools which
<PurplePotato> initiates thunder and to do with writes a garbage can; be their
<PurplePotato> friends, and Glassy and sending KOBY flies fall into one lazy afternoon when you invisible.
<PurplePotato> ill shut up now
<laga> hmm, interesting
<PurplePotato> SERIOUSLY THOUGH... open up synaptec and download DadaDodo, its really fun
<PurplePotato> ime already entertained for days!
<PurplePotato>   The DOKEBYS decided to the Dokeby comes KOBY is a lucky kid who just an old broom; Dokeby and the old  omnipotent and everybody at school, there is the invisible hat.
<slangasek> PurplePotato: sorry, what does this have to do with Ubuntu development?
<PurplePotato> this is all mathmatically generated too!
<PurplePotato> idk
<PurplePotato> i leave
<PurplePotato> actually i had a question
<PurplePotato> how would i write a script to add on "conditions" to a shortcut?
<PurplePotato> like in windows, for a video game you might have it link to the file, then have it imput the condition "+connect 8.2.120.174"
<andrew_sayers> You mean command-line arguments?
<PurplePotato> yes, thats it
<PurplePotato> its like for a Q3 engine game, or other things
<andrew_sayers> Write a file called something like "my-command.sh", where the first line is "#!/bin/sh", and the second line is the complete command line, with arguments.
<andrew_sayers> Then set that file to be executable.
<PurplePotato> ok, will do! thx
<andrew_sayers> np, good luck.
<PurplePotato> *sigs* i suck at this.... thx!
<cody-somerville> slangasek, if you're around, can you wave in #ubuntu-meeting
<slangasek> ... wave?
<YokoZar> So I guess update-manager -d won't work until Alpha 1 is out, right?
<cjwatson> alphas are just CD image releases - they don't have a lot of bearing on the upgrader
* mthaddon changed the topic of #ubuntu-devel to: Codebrowse/Codehosting on LP down for hardy upgrade 22:00- 00:00 UTC | Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDeve
* cjwatson changed the topic of #ubuntu-devel to: Codebrowse/Codehosting on LP down for hardy upgrade 22:00-00:00 UTC | 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
<cjwatson> trimmed a few old items so that it'll all fit
#ubuntu-devel 2008-06-19
* mthaddon changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* cjwatson changed the topic of #ubuntu-devel to: 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
<gribouille> hi
<cody-somerville> Is the survey on the Ubuntu-devel-discuss mailing list legit?
<gribouille> do you there is a problem with firefox+google toolbar on ubuntu ?
<gribouille> hey, are you sleeping ?
<cody-somerville> no...
<mario_limonciell> gribouille, this isn't really the right place for that kind of discussion.  #ubuntu should be better for it.  To answer your question though, it's very possible that Google hasn't updated their Google Toolbar extension for Firefox3 (which is in Ubuntu 8.04)
<cjwatson> also, bug reports are really better off on bugs.launchpad.net/ubuntu - they can be tracked properly that way
<gribouille> mario_limonciell, the problem existed also with firefox 2
<cjwatson> bug 228636
<ubottu> Launchpad bug 228636 in firefox-3.0 "Google Toolbar cannot install" [Undecided,Invalid] https://launchpad.net/bugs/228636
<gribouille> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/135110
<ubottu> Launchpad bug 135110 in firefox "[gutsy] firefox freezes with google toolbar enabled when you attemp to open more than two windows" [Undecided,Incomplete]
<cjwatson> (not sure how useful that is though)
<gribouille> my question is : why do you need to patch firefox so heavily ?
<cjwatson> gribouille: by the way, waiting three minutes after asking your question and then asking if anyone is asleep is unpleasant behaviour on IRC - it's an asynchronous medium and conversations routinely take hours if one relevant party is away
<gribouille> cjwatson, ok, sorry
<gribouille> cjwatson, it is 1 A.M., so I can't wait for hours
<cjwatson> use the bug tracking system, then
<cjwatson> it's 1am where the firefox maintainer lives too
<gribouille> cjwatson, the bug was already reported, but it doesn't seem to habe been taken into account
<cjwatson> well, in some ways it's a google toolbar problem, of course
<cjwatson> we simply can't wait for *every* extension to upgrade, I'm afraid
<gribouille> cjwatson, I don't think it is a google toolbar problem, since the problem appears only with the patched version of firefox kindly ditributed by ubuntu
<cjwatson> in that case it would be useful to narrow down which patch is responsible
<cjwatson> there's a reason for each patch we carry, and FWIW our patches generally go through patch review by upstream
<cjwatson> we don't just patch it for fun
<gribouille> cjwatson, what do the patches add in functionality ?
<cjwatson> that is an extremely broad question best answered by looking at the changelog
<gribouille> where can I find it ?
<cjwatson> /usr/share/doc/xulrunner-1.9/changelog.Debian.gz, /usr/share/doc/firefox-3.0/changelog.Debian.gz
<emgent> heya people
<nysin> How long generally happens after a bug gets marked as fixed should it appear back in the intrepid repositories? In particular, there's one 11 hours old that hasn't appeared at packages.ubuntu.com
<gribouille> cjwatson, will I have problems if I use the version of firefox from mozilla ?
<Keybuk> nysin: between 3 hours and 6 months
<cjwatson> gribouille: no idea, up to you
<nysin> heh.
<cjwatson> nysin: which bug?
<gribouille> nysin, but it can take 10 years too
<nysin> https://bugs.launchpad.net/ubuntu/+source/scons/+bug/226783
<ubottu> Launchpad bug 226783 in scons "Merge scons 0.98.5-1 (main) from Debian unstable (main)" [High,Fix released]
<cjwatson> gribouille: thanks for your helpful remarks, but please don't
<nysin> and I'm looking at http://packages.ubuntu.com/intrepid/scons
<Keybuk> https://edge.launchpad.net/ubuntu/intrepid/+source/scons/0.98.5-1ubuntu1
<TheMuso> I've found packagesw.ubuntu.com to be behind.
<nysin> ah
<Keybuk> it's listed as built and published
<TheMuso> pacages.ubuntu.com even
<TheMuso> gah typing
<cjwatson> nysin: yeah, that all seems to be in place
<nysin> cjwatson: well my link still has it at 0.97
<Keybuk> (from any bug, just click the "Overview" tab to see which versions are in which releases of Ubuntu)
<mario_limonciell> nysin, you are usually better off looking at https://edge.launchpad.net/ubuntu/intrepid/+source/scons for more information on the version in different places
<cjwatson> http://archive.ubuntu.com/ubuntu/pool/main/s/scons/
<nysin> but Keybuk's is useful
<cjwatson> nysin: ^- more accurate than packages.u.c
<mario_limonciell> er well https://edge.launchpad.net/ubuntu/+source/scons
<mario_limonciell> instead
<cjwatson> launchpad.net -> what ought to be in the archive, archive.ubuntu.com -> what is in the archive, packages.ubuntu.com -> what was in the archive some hours ago
<gribouille> cjwatson, do you think it is better to despise the users ?
<nysin> cjwatson: ah, I did not know that, thanks.
<cjwatson> gribouille: err, you're being completely irrelevant; the bug nysin is talking about is already fixed and in the archive and your comment was unhelpful
<Keybuk> gribouille: sleeping for 8 hours a day is despising users?
<gribouille> Keybuk, I'm not talking about that
<gribouille> cjwatson, he's lucky
<Keybuk> gribouille: it is unclear to me what you are talking about
<nysin> no I'm not
<nysin> I've been watching this bug for some days now
<nysin> I subscribed to it to find out when it was fixed
<nysin> and then when it was I looked for the fix
<cjwatson> gribouille: it is a reality of life anywhere in the software world that not all bugs get fixed, I'm afraid; we are willing to work with people who are willing to help us
<nysin> stop assuming
<nysin> please
<nysin> my timing here is not accidental
<gribouille> cjwatson, we don't ask you to fix all the bugs, but at least, please, fix the bugs you introduced yourseves
<Keybuk> gribouille: bug# ?
<cjwatson> gribouille: it's an interaction between our changes and non-free code that we cannot see; it's unclear, as far as I can see, what's going on
<gribouille> Keybuk, https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/135110
<cjwatson> gribouille: but, as I said, somebody who's willing to put the work in to figure out which patch is responsible would help greatly
<ubottu> Launchpad bug 135110 in firefox "[gutsy] firefox freezes with google toolbar enabled when you attemp to open more than two windows" [Undecided,Incomplete]
<cjwatson> gribouille: shouting at us on IRC achieves nothing
<gribouille> cjwatson, can't you understand that users can become angry ?
<cjwatson> gribouille: yes, I can. That doesn't mean we have to tolerate people being uncivil to us here.
<Keybuk> gribouille: several people seem to be affected by that bug, and are posting useful information
<Keybuk> it's only a matter of time before the right piece of information is found by somebody affected by it, and posted to the bug
<Keybuk> at which point, a developer may be able to act on it
<Keybuk> of course
<Keybuk> I'm not sure _why_ that is marked as a security vulnerability
<cody-somerville> Keybuk, probably to get developer attention
<Keybuk> cody-somerville: ironically, that has the exact opposite effect :)
<kees> it's such a tempting checkbox
<Keybuk> security-related bugs cannot be seen by most developers
<Keybuk> so marking it as security means your bug will be hidden to everyone :p
<kees> Keybuk: "private" can't.
<Keybuk> kees: oh, did they break that link now?
<gribouille> Keybuk, what "piece of information" are you waiting for ? can't you find it yourselves ?
<Keybuk> gribouille: no, we can't find bugs ourselves
<kees> Keybuk: yeah, it defaults to private+security and prompts you to please make it public if it's not really private
<gribouille> Keybuk, but what information do you need ?
<cjwatson> gribouille: please be aware that we have an enormous amount to do, and the fact that we cannot give every bug all the attention it deserves does not mean that we are lazy
<Keybuk> gribouille: in almost all cases of annoying bugs, the developers are not affected by it
<Keybuk> the developers are likely entirely unable to replicate it
<kees> 135110 is not a security bug anymore.  ;)
<Keybuk> it simply works for us
<Keybuk> so we rely on our users, who _are_ affected by the bug and who _can_ replicate it, to provide as much information as they can
<Keybuk> and to actively help out to detect the bug
<Keybuk> as to what information it needs, an exact description of how to replicate the bug on any system -- ideally with lots of detail about what causes it
<Keybuk> a patch would be nice too ;-)
<cjwatson> it is now the third time that I've said that, ideally, somebody affected by the bug would figure out which Ubuntu patch is responsible for introducing it
<gribouille> Keybuk, strange, because the bug happens conctantly on my computer. I can't believe that it is not the case with you
<cjwatson> i.e. bisect the set of Ubuntu patches, building with and without various ones, until it is isolated
<Keybuk> gribouille: that is why you fail (to get it fixed :p)
<cody-somerville> gribouille, I don't think Keybuk uses that software.
<gribouille> Keybuk, did you even try to reproduce the bug ?
<Keybuk> gribouille: yes
<cjwatson> gribouille: we have many, many other bugs
<Keybuk> for the sake of interest, I installed GTB while we've been talking
<Keybuk> and it works for me
<ogra> but you dont use gutsy :)
<ogra> or ff 2
<Keybuk> oh, I tried hardy ;)
<cjwatson> it has also been asserted that it fails on hardy
<gribouille> Keybuk, are you saying that no ubuntu developer has ever managed to reproduce the bug ?
<cjwatson> that said, gribouille has not been clear
<ogra> oh
<Keybuk> gribouille: I'm saying that there is no instance of that bug being confirmed by a developer
<cjwatson> gribouille: do you believe that every Ubuntu developer attempts to reproduce all tens of thousands of open Ubuntu bugs, separately? :-)
<gribouille> cjwatson, surely not
<cjwatson> gribouille: we have to work in priority order, and bugs that affect the standard Ubuntu installation without extensions tend to receive higher priority because more users encounter those
<gribouille> for your information, the bug affects ff2 on gutsy as well as ff3 on hardy
<cjwatson> Firefox 3 on hardy for *some people*
<cjwatson> but, it is clear, not all - like all the hardest bugs
<Keybuk> gribouille: does it affect vanilla upstream ff3 on hardy?
<kirkland> does anyone know anything about libpam-script ?  it doesn't seem to be packaged for Debian or Ubuntu....
<gribouille> Keybuk, I haven't tried
<Keybuk> gribouille: trying that would be useful, and reporting in the bug
<Keybuk> if it does work, then there is a problem in the ubuntu specific packaging
<Keybuk> then please try bisecting through the ubuntu patches and changes until you find the one which breaks it
<slangasek> kirkland: I know that the idea makes me slightly nauseous ;)
<Keybuk> _that_ would be amazingly useful
<kirkland> slangasek: :-)  has it been proposed and shot down previously?
<gribouille> Keybuk, the people who reported the bug said there was no problem with the version of ff distributed by mozilla
<slangasek> kirkland: not that I'm aware of
<Keybuk> gribouille: so the next step is to bisect until you find what about the ubuntu version causes it
<Keybuk> like they do at the opticians
<Keybuk> "better with, or without?"
<Keybuk> (change lens)
<kirkland> slangasek: okay, thanks.  i'll look into putting the bits i need into pam_ecryptfs.so instead.
<gribouille> Keybuk, I'm not an ubuntu developer
<Keybuk> "better with, or without?"
<Keybuk> gribouille: it's a great way to become one ;)
<gribouille> Keybuk, sure, I don't have anything else to do
<cody-somerville> gribouille, good, we have a lot to do! :)
<Keybuk> thanks, that would be really helpful
<Keybuk> put as much detail into what you find into the bug
<cody-somerville> gribouille, If you need help, let us know.
<cjwatson> gribouille: the more that this sort of thing can be done by folks who are directly affected by and bothered by a bug, the more time Ubuntu developers can spend on fixing bugs that already have all the necessary information in them
<cjwatson> we're not short of those
<cjwatson> and they're the ones that can *only* be addressed by developers
<gribouille> I don't say I don't want to help, but I can't spend hours a day trying to find the cause of certain bugs
<Keybuk> gribouille: yet you expect other people to do it for the bugs that affect you?
<Keybuk> most ubuntu developers do this in their spare time, remember
<gribouille> Keybuk, I don't have the necessary tools to fix bugs
<Keybuk> gribouille: we're not asking you to _fix_ it, just provide enough information for a developer to be able to, if not replicate it, understand it
<Keybuk> and thus the developer to fix it
<cjwatson> gribouille: it's OK not to be able to help - many people fall into that category - but we do ask that people who aren't able to help themselves don't come into our development coordination channel and have a go at us for not fixing something
<Keybuk> (and you have, in the Ubuntu system, all the tools that the developers have :p)
<nxvl> cjwatson: thanks!
<cjwatson> nxvl: hope it's less work for you that way ;-)
<nxvl> yep
<nxvl> i thought it was just not needed, and since i didn't get any response from upstream i thought i should, thanks a lot!
<gribouille> cjwatson, I came here because I had an urgent need to understand something
<cjwatson> perhaps we can start again, then
<cjwatson> what do you still need to understand that has not been answered so far?
<gribouille> cjwatson, now, I know better how you work
<gribouille> do you fix the bugs yourselves or do you just forward the bug reports to the authors of the software ?
<cjwatson> a bit of both
<gribouille> what is the % of bugs you fix yourselves ?
<cjwatson> I don't think we have the materials to answer that question even approximately
<cjwatson> we fix many problems ourselves, and often forward those fixes where appropriate; in other cases we forward the report; in some of those cases we work with upstream to figure out a fix. It depends on the importance of the software to Ubuntu, how actively it's maintained in Ubuntu, how much else the relevant maintainer has to do, how experienced the relevant maintainer is in that area of the software in question, sometimes ...
<cjwatson> ... whether the maintainer judges that it would be too disruptive to attempt a fix in a distribution-specific patch, and probably all kinds of other reasons I've forgotten
<cjwatson> and there are, unfortunately, some bugs that don't get the attention they should, because there are simply more reports coming in than we have the manpower to handle at present
<cjwatson> (I suspect most popular projects are in this position, and we're always looking for ways to improve it)
<gribouille> I can't even run firefox in gdb :-(
<cody-somerville> evand, What would cause errors like this?
<cody-somerville> https://bugs.edge.launchpad.net/ubuntu/+bug/157260
<ubottu> Launchpad bug 157260 in ubuntu "Dell Dimension 8200 LiveCD and alternate CD don't boot properly" [Undecided,New]
<BenC> pitti: ping
<gribouille> is a version of firefox with debugging symbols available ?
<cody-somerville> gribouille, Are you gutsy or hardy?
<gribouille> hardy
<cjwatson> grabbing and installing the matching-version packages from http://ddebs.ubuntu.com/pool/main/x/xulrunner-1.9/ and http://ddebs.ubuntu.com/pool/main/f/firefox-3.0/ should help
<cjwatson> (detached symbols)
<cody-somerville> gribouille, Add deb http://ddebs.ubuntu.com/ hardy main multiverse restricted universe and install the -dbgsm counterparts.
<cjwatson> see https://wiki.ubuntu.com/MozillaTeam/Bugs
<cjwatson> detailed directions there in the "Crashes" section
<gribouille> sudo apt-get install xulrunner-1.9-dbgsym : The following packages have unmet dependencies:
<gribouille>   xulrunner-1.9-dbgsym: Depends: xulrunner-1.9 (= 1.9~b5+nobinonly-0ubuntu3) but 1.9+nobinonly-0ubuntu0.8.04.1 is to be installed
<gribouille> E: Broken packages
<cjwatson> gribouille: looks like you didn't include the hardy-updates line - see https://wiki.ubuntu.com/MozillaTeam/Bugs
<cjwatson> (hardy-updates has xulrunner-1.9-dbgsym 1.9+nobinonly-0ubuntu0.8.04.1
<cjwatson> )
<gribouille> I installed firefox-3.0-dbgsym xulrunner-1.9-dbgsym libgtk2.0-0-dbg libnss3-0d-dbgsym libnspr4-0d-dbg libpango1.0-0-dbg libcairo2-dbg libc6-dbg, but gdb /usr/lib/firefox-3.0/firefox still says there are no debugging symbols
<cody-somerville> gribouille, can you pastebin the output?
<cody-somerville> !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<gribouille> bash: /usr/lib/debug/usr/lib/firefox-3.0/firefox: cannot execute binary file
<gribouille> the file is -rwxr-xr-x 1 root root 1672 2008-06-10 17:05 /usr/lib/debug/usr/lib/firefox-3.0/firefox
<Amaranth> tjaalton: with http://www.realistanew.com/random/xen.patch the 173.14.09 nvidia module will build against the 2.6.26-1 kernel
<cody-somerville> I think we may have a rather big regression on our hands.
<Amaranth> cody-somerville: ?
<cody-somerville> https://bugs.edge.launchpad.net/ubuntu/+bug/221657
<ubottu> Launchpad bug 221657 in ubuntu "xfce4 does not load on normal ubuntu-desktop (dup-of: 232364)" [Undecided,Confirmed]
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed]
<cody-somerville> I'm starting to see reports the issue also occurrs with gnome
<cody-somerville> bryce, ^^
<bryce> cody-somerville: url for the gnome report(s)?
<cody-somerville> https://bugs.edge.launchpad.net/ubuntu/+bug/221657/comments/7
<ubottu> Launchpad bug 221657 in ubuntu "xfce4 does not load on normal ubuntu-desktop (dup-of: 232364)" [Undecided,Confirmed]
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed]
<TheMuso> Hrm. Trying to use ubuntu-vm-builder to build a hardy kvm image, yet it seems to fail when attempting to set up grub. Anybody had anything similar? http://www.pastebin.ca/1050720
<cody-somerville> Alrighty folks.
<cody-somerville> Wish me luck. Hopefully I can solve bug #232364 with this next test.
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed] https://launchpad.net/bugs/232364
<lamont> pitti: requestsync does silly things... see bug 241144 for an example
<ubottu> Launchpad bug 241144 in bind9 "Please sync bind9 1:9.5.0.dfsg-3 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/241144
 * lamont read through the merge list going "I touched that?"
<cody-somerville> bryce, ping
<cody-somerville> bryce, [pid  7877] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfd17a18) = -1 ENOTTY (Inappropriate ioctl for device)
<cody-somerville> [pid  7877] select(21, [20], NULL, [20], NULL
<cody-somerville> :)
<Keybuk> [pid  7877] select(21, [20], [20], NULL, NULL) = 1 (out [20])
<Keybuk> [pid  7877] writev(20, [{"\225\0\2\0\1\0\0\0", 8}], 1) = 8
<Keybuk> [pid  7877] select(21, [20], [], NULL, NULL) = 1 (in [20])
<Keybuk> [pid  7877] read(20, "\1\1\6\0\0\0\0\0\1\0\0\0H\217\357\277}s\33\10\230\3378"..., 4096) = 32
<Keybuk> [pid  7877] read(20, 0x8056f3c, 4096)   = -1 EAGAIN (Resource temporarily unavailable)
<Keybuk> [pid  7877] select(21, [20], NULL, [20], NULL
<Keybuk> --
<Keybuk> so that's where it's hanging
<toaster_fun> How do I create a wiki page?
<toaster_fun> on http://wiki.ubuntu.com
<Keybuk> actually, cody's ioctl is quite interesting after all ;)
<ion> how is intrepid running
<ion_> Hello, other ion. :-)
 * slangasek uses a mass spectrometer to tell the two apart
<ion_> I stole an electron from him, thus we both became ions.
<wgrant> ion_: You should be Ã¯on, and he should be Ä±on!
<Keybuk> what happens if we split you apart?
<wgrant> How often does changelogs.u.c update?
<n8k99> Keybuk: depends on what you use to split them
<Keybuk> LHC, of course
<persia> wgrant: I've heard 4-hourly, but I may be mistaken.  mvo knows for sure.
<ion_> LHC â¥
<n8k99> heh
<wgrant> Is there any reason to not run it right after the publisher?
<persia> wgrant: To avoid the "changelogs cannot be found" issue?
<wgrant> persia: Indeed.
<persia> wgrant: bug #40058
<ubottu> Launchpad bug 40058 in update-manager "update-manager shows no changelog for various packages" [Medium,Confirmed] https://launchpad.net/bugs/40058
<wgrant> persia: Thanks
<sbeattie> slangasek: I assume it's known that the 8.04.1 daily builds have been failing to show up since the 20080617 build?
<TheMuso> sbeattie: That sounds correct to me.
<TheMuso> sbeattie: As in, thats only yesterday for me at least.
<sbeattie> TheMuso: there's a 20080617.1, 20080618 and 20080618.1 directory that are all unpopulated.
<TheMuso> sbeattie: Oh right haven't looked that deeply.
<iwkse> hi all, i got a crash by the installer, ubuntu hurdy, http://pastebin.ca/1050814. Anybody can help me to understand what's going that on it?
<slangasek> sbeattie: yes; unfortunately I didn't know this before the QA meeting this morning, sorry
<sbeattie> slangasek: no problem, just wanted to be sure you were aware. I should be pulling isos from there more frequently.
<Hobbsee> [15:26] * Hobbsee tries to remember which version of ubuntu first writes to ntfs by default.
<Hobbsee> [15:26] <Hobbsee> er, out of the box, not by default.
<ScottK> Gutsy I think.
 * calc wonders if the glib timestamp file manager bug is ever going to get fixed in hardy :-\
<TheMuso> Hobbsee: I'd say gutsy as well.
 * calc doesn't like using the command line for organizing files
<Hobbsee> oh, it was gutsy?
<Hobbsee> nice.
<pitti> Good morning
<pitti> BenC: pong
<pitti> lamont: that's a known limitation; for versions which were never in Debian you have to specify the "base version" (branch point); see manpage
<pitti> StevenK: you use postgresql a bit, don't you?
<StevenK> pitti: Certainly do
<pitti> StevenK: would you mind giving 8.3.3 a try, in hardy-proposed? I need someone else than just me to verify bug 238587
<ubottu> Launchpad bug 238587 in postgresql-8.3 "PostgreSQL bug fix releases 8.3.3/8.2.9/8.1.13" [High,Fix committed] https://launchpad.net/bugs/238587
<pitti> StevenK: (or, rather, any *-proposed)
<\sh> moins
<fabbione> morning guys
<pitti> hey fabbione
<fabbione> yo yo pitti
<StevenK> pitti: Bug updated about 8.3
<StevenK> Updating. Move it, Launchpad
<pitti> StevenK: oh, that was quick; thanks! you were already running -proposed?
<StevenK> pitti: Nope. Creating chroots is easy.
<pitti> that wasn't a very extensive testing then :)
<StevenK> pitti: It runs, and imports a database dump I had lying around, and answers queries. What else do I want a database server to do? :-)
<pitti> StevenK: ah, that's fine
<dholbach> good morning
<dholbach> does the new intrepid kernel work for anybody in KVM?
<Hobbsee> StevenK: make you tea, coffee, and dinner on request.  duh.
<StevenK> Hobbsee: No, that's how pitti thanks me for testing.
<dholbach> also with the old kernel, does anybody else have funny mouse movement? as in mouse moving very very slowly just in the upper left 100*50 pixel area?
<Hobbsee> StevenK: it'll be cold by the time it gets there.
<lifeless> pitti: btw I haven't tested yet, my conversion took waaay longer than I expected
<pitti> lifeless: conversion from 8.2 to 8.3?
<lifeless> pitti: kernel version, suspend bug
<lifeless> oh, no bzr repo stuff
<pitti> oh, that
<Amaranth> that reminds me, I don't know if it is the new nvidia driver or the new kernel but one of the two added at least 30 minutes to my battery life
 * Amaranth is happy
<pwnguin> Amaranth: checked powertop?
<Amaranth> pwnguin: same wakeups but I think I spend a little more time in C3
<Amaranth> only problem I was with the 2.6.26 kernel is I can no longer use my keyboard to wake up my laptop if I suspend it with the button instead of closing the lid
<Amaranth> i have to push the power button
<Amaranth> otherwise I'm impressed at how well everything still works
<pwnguin> heh
<Amaranth> well, except that it seems to support Xen DomU by default now which means I had to make a patch for the nvidia driver
<pwnguin> when i updated yesterday, i think i missed the nvidia binary
 * pwnguin hopes the dust settles on drm2 soon
<Amaranth> luckily the debian guys already had to do the same thing so I just updated their patch to the latest driver
<Amaranth> pwnguin: you could try http://ubuntuforums.org/showthread.php?t=833633
<pwnguin> i havent looked at it much yet
<wgrant> Amaranth: Are you using 2.6.26 from the kernel-team PPA?
<pwnguin> 2.6.26 hit intrepid
<Amaranth> I thought it hit 4 days ago
<Amaranth> i dunno, the mirror I was using seemed to die
<pwnguin> Amaranth: besides which, "Design charge: 50Wh. Last full charge: 18.5Wh"
<Amaranth> was thinking "where did all the updates go?" then "oh crap, 571 updates"
<Amaranth> pwnguin: forget where that info is
<pwnguin> click on the battery
<Amaranth> ah
<Amaranth> both are 97.7 Wh
<pwnguin> my laptop's nearing two years of age
<Amaranth> and this battery is 2 years old, I'm impressed
<Amaranth> my other battery for it is completely shot because I forgot to use it for awhile
<pwnguin> i wonder if the cold killed it
<pwnguin> i used to leave my laptop on the floor. I'd wake up and it wouldn't boot
<pwnguin> or rather, it'd boot but only if you sat at grub for a while or restarted
<Amaranth> ooh i never leave mine on on the floor, get crap from the carpet in it and it overheats
<pwnguin> it was off
<Amaranth> weird
<pwnguin> the floor is concrete with carpet over it
<pwnguin> it probably got cold enough to screw it
<Amaranth> that would have to be incredibly cold
<Amaranth> like around 0
<pwnguin> then there was the time someone decided toshiba_acpi didnt need to be around
<pwnguin> on my scale, 10 is around 0
<Amaranth> err, which scale are we talking?
<Amaranth> Oh, I guess I should use F then
<Amaranth> I meant 32
<pwnguin> i wouldn't be surpised it it approached 40F or lower
<pwnguin> winter is cold
<pwnguin> i know there was a point where the whole house was at 45 when we lost power
<pwnguin> that was a fun finals week
<pwnguin> anyways, the cheapest way to add battery time for me is to replace the thing =(
<seb128> pitti: hello
<seb128> pitti: so about this lanman password things, there is several points to consider and I've no idea about the number concerned there
<seb128> - how many setup requiring this weak authentifications are still around
<seb128> - how of a security issues is the option, knowing that upstream, other distro and other ubuntu versions are still using it
<pitti> AFAIUI, Vista already disables it completely, and XP/2000 don't configure it by default; and neither did we in any supported Ubuntu release?
<seb128> - and if we prefer to annoy users for their own good
<seb128> speaking about server or client side?
<seb128> we didn't configure any server side to use that
<seb128> but there is people who have NAS using samba 2 for example
<pitti> admittedly CIFS passwords are used in much more controlled environments than SSH keys
<seb128> and they used to be able to connect to those using gutsy
<seb128> and that still work using, let's say fedora 9
<seb128> ideally nautilus and gvfs should display clear errors about why they can't connect and what they can do to fix the issue
<seb128> but that's not going to happen before 8.04.1
<seb128> so either we declare that those are still broken in a confusing way
<seb128> or enable the option until getting the dialog
<pitti> so for judging the potential exposure, how many SAMBA servers are realistically accessible from the internet?
<seb128> ideally none? ;-)
<seb128> in really, no real clue
<seb128> s/really/reality
<pitti> if they pretty much all are confined to private home/corporate networks, I'm not too concerned about weak passwords, but for anything exposed to the web I am
<seb128> right
<seb128> do you know about any usecase for having a samba share available on the internet?
<seb128> my understanding is that those are used to share things on local network usually
<pitti> my gf's uni offers access from home, but solely through a VPN
<wgrant> seb128: I have a usecase - stupidity. Most ISPs block SMB ports.
<pitti> apparently (and rightfully) they don't trust CIFS passwords enough to offer a direct connection :)
<seb128> ;-)
<pitti> wgrant: that would be a good thing indeed
<wgrant> (in .au at least, not sure about elsewhere)
<StevenK> Silly weather applet. It's not a clear sky, it's raining!
<persia> Is it not possible to warn the user, rather than enabling/disabling it?  Something like "Your password will be transmitted unencrypted: are you sure you want to send it?"
<fabbione> wgrant: pretty much everywhere, but i can see scans on smb ports within the same ISP
<persia> There's also wireless access to homes/offices to consider, but isn't this just about a client setting?
<wgrant> StevenK: It's not raining here, but my clock applet says it is. I think we need to swap.
<wgrant> What about enterprise LANs? Are they not a risk?
<StevenK> wgrant: Is it clear sky? :-)
<pitti> wgrant: admittedly the *actual* risk is misconfiguring the server
<wgrant> StevenK: Too dark to tell.
<persia> wgrant: Few true enterprise LANs permit LANMAN password shares
<pitti> wgrant: this client-side setting will just prevent to connect to those
<wgrant> Couldn't an attack on the network convince the client to send a LANMAN password, if it were enabled on the client?
<wgrant> *attacker on the
<persia> pitti: Hasn't the LANMAN trivial hash vulnerability been public for a decade or so?
<seb128> persia: such changes are not possible before 8.04.1 no
<persia> seb128: Ah.  Too bad.
<seb128> persia: either we keep the current way, ie things not working and not giving any indication of why, or we authorize the lanman authorization again until having the interface changes
<seb128> persia: 8.04.1 is frozen so now is not the right time to start writting new code and doing user interfaces changes
<persia> seb128: Well then.  I'm in favour of permitting lanman authorisation.  It's bad, but it's been known bad for so long that it's really a server issue.
<persia> (unless wgrant is correct that someone can spoof samba to pass a LANMAN authentication token without user intervention)
<seb128> we don't speak about server side change
<seb128> and that's a smb.conf option, people who want to use it to do something will not be stopped by the default value
<persia> seb128: Right :)  I should have said "a server administrator issue"
<wgrant> Wouldn't an attacker simply have to get a victim to attempt to connect to his machine, then request LANMAN? ARP poisoning makes that nice and easy.
<pitti> yeah, it's really more like a "fix your broken server now, dammit!" measure
<pitti> well, and prevent your password from being intercepted, of course
<pitti> wgrant: exactly; that's the MITM scenario
<pitti> and the primary reason why clients shoulnd't accept LANMAN any more
<seb128> do we have any idea on how many samba 2 NAS, servers and w9x configs are still around?
<pitti> so at *some point* we have to stop doing that
<wgrant> So it's a question of breaking a few outdated things, or letting everybody's passwords be got at trivially.
<wgrant> Right?
<seb128> well, if we had a dialog explaining why the connection doesn't work I would be fine stopping it now
<seb128> wgrant: "everybody"?!
<persia> pitti: I agree, but I think interface is the way to solve it: without an interface change, the user just experiences the device as broken.  Considering that many NAS boxes come with LANMAN auth (null-password) by default at the shop...
<seb128> wgrant: why would correctly configured server expose passwords?
<pitti> seb128: because you can do a MITM attack and ask the client to use LANMAN
<pitti> regardless of what the server is or how it is configured
<seb128> pitti: well, that's not everybody, that's broken server configs
<pitti> seb128: no, it's not dependent on the server config
<seb128> pitti: you still need somebody trying to connect
<persia> pitti: It's more a social engineering attack than a MITM attack.  A user would want to connect to a new resource.
<pitti> right, with changing DNS, or just telling someone "use this"
<seb128> pitti: if I try to connect to a vista box on my local network why would lanman be used?
<pitti> persia: true; DNS poisoning is not a very common scenario in commercial environments, I guess
<seb128> right, you have to change DNS and get people to "use this"
<pitti> persia: (DNS poisoning would make it a true MITM)
<pitti> seb128: s/and/or/
<seb128> people who try to connect to random server people they don't know tell them to try can always be screwed in some way
<pitti> seb128: but given SMB's auto-announcement of servers and shares, this is not that unlikely
<seb128> and I don't think DNS changes are easily to do
<persia> pitti: Ah.  Right.  wildcards.
<pitti> you don't need DNS changes
<pitti> they are helpful, but not required at all
<pitti> just setup a LANMAN share on your own box, and wait for people to connect and thus give you their password
<wgrant> ARP poisoning isn't hard in most circumstances, either.
<seb128> well, let's word it differently
<seb128> lanman is being authorized for years and years and the world never broke due to it
<persia> Well, lots of data was compromised.
<seb128> is there any reason it should break between now and the time we get a nautilus interface to display a clear message?
<wgrant> seb128: It has another 3 years to break it on Hardy...
<wgrant> Or is a better fix coming later for Hardy?
<seb128> wgrant: no, it hasn't
<seb128> wgrant: as soon as we get the nautilus and gvfs change we will switch the samba default again
 * Amaranth cries at banshee using 10% CPU to play a song
<seb128> wgrant: it's just too near of 8.04.1 to do the interface changes now
<wgrant> Amaranth: Is the UI also horridly slow for you?
<wgrant> seb128: Makes sense. I never read the whole bug, I must admit.
<Amaranth> wgrant: nope, and rhythmbox uses that much cpu too
<Amaranth> and everything else that uses gstreamer to play an mp3 file
<seb128> Amaranth: and gst-launch?
<seb128> Amaranth: what plugin do you use?
<Amaranth> i have no idea
<seb128> is the fluendo plugin installed?
<Amaranth> probably
<seb128> trying uninstalling it
<seb128> s/trying/try
<Amaranth> it sucks that bad?
<seb128> I don't use it but I think some users had cpu usage issues when using it
<Amaranth> neat, banshee crashed when I removed the plugin :P
<Amaranth> still 10-12%
<emgent> morning
<Amaranth> iirc I've always had this
<pitti> seb128: that's a much better and convincing argument
<Amaranth> no one else has gstreamer-based apps using outrageous CPU time playing an mp3?
<Amaranth> (or just about any other media)
<seb128> 12459 seb128    20   0  182m  46m  22m S    2  2.3   0:02.29 rhythmbox
<seb128> 12459 seb128    20   0  183m  48m  22m S    2  2.4   0:03.03 rhythmbox
<seb128> no
<Amaranth> what cpu?
<seb128> pitti: which one?
<seb128> Amaranth: the "2" column
<Amaranth> i know
<Amaranth> i have 2ghz core duo
<seb128> ah
<pitti> seb128: the "we had allowed it for so long, so we can allow it just a little longer"
<seb128> Amaranth: E6750
<seb128> duo core intel
<Amaranth> shouldn't be that different
<seb128> pitti: well, really I don't have an idea on how many basic user have NAS they can't use due to that for example so it's not easy to argue either way
<seb128> that would really depend of this number
<seb128> if the reply is "almost none" don't think it's worth enabling, if the reply is "quite some" I think we should authorize it for 8.04.1, work on the nautilus change and get that to hardy-updates quickly after 8.04.1
<seb128> pitti: now it's your and slangasek calls ;-)
<brt> hi
<saispo> hi
<saispo> BenC: ping ? :)
<saispo> any kernel maintainer in this room ? :)
<RAOF> saispo: You're probably after #ubuntu-kernel
<saispo> yes, maybe too :)
<MacSlow> Where can I see what's current in debian regarding packages and used upstream-versions?
<persia> MacSlow: http://qa.ubuntuwire.com/multidistrotools/all.html has them (in comparison to Ubuntu)
<persia> drop the all.html if you want a more focused list (there are several from which to choose)
<RAOF> My, subversion packaging is complicated.
<persia> RAOF: Depends on how one uses tags...
<RAOF> No, I mean the packaging for svn is complicated.
<persia> heh
<RAOF> But it (A) FTBFS and (B) causes svn-buildpackage to be uninstallable, care of the perl 5.10 transition, and that lack is blocking me from working on gnome-do packaging :)
<RAOF> And since noone seems to be doing the merge, I'm looking at it.
 * persia gives RAOF a bucket, a katana, and a yak :)
 * RAOF wonders if a yak has enough blood to placate the dark gods of SVN.
<RAOF> Oh, crap.  Debian partially adopted some of our changes, but in a way apparently incompatible with some of our other changes.
<seb128> RAOF: I asked doko about the subversion merge yesterday and he was looking at it
<seb128> RAOF: you might want to ask him when he will be around
<MacSlow> Keybuk, hey there
<mvo> didn't he said we will not look at it before monday or something?
<mvo> because he is traveling?
<MacSlow> Keybuk, for todays meeting I just added another discussion point
<RAOF> It's big and evil and complicated.
<MacSlow> Keybuk, I hope that's ok... it'll be mainly me asking to get a more recent version of clutter in intrepid
<RAOF> I'd be very happy to leave it to doko :)
<seb128> maybe somebody should just do a rebuild for the perl transition now and let doko to the merge later
<rockyrock> hi guys
<rockyrock> I need a help
<rockyrock> Does any USB external DialUp modem work on Ubuntu?
<james_w> RAOF: bzr-svn 0.4.10 + bzr-builddeb 0.95 should work as a replacement for svn-buildpackage if you can't get anything working. If you want more details then just ask.
<RAOF> subversion currently fails to build, at least it did for me; we can't just rebuild it.
<RAOF> james_w: Thanks.  I actually have a fallback; my not-intrepid install.  That'll work fine. :)
<pwnguin> Amaranth: ok so updating didnt fix it. why's it called a xen patch though?
<Amaranth> pwnguin: because the problem is that the kernel includes xen
<Amaranth> the patch makes the driver ignore this
<pwnguin> i thought KVM was the new hotness
<Amaranth> xen is more 'enterprise', i guess
<pwnguin> boy im sure glad people don't read press releases
<cjwatson> dholbach: the intrepid kernel fails for me in kvm too; I brought it up on #ubuntu-kernel a few days ago
<cjwatson> dholbach: I've been falling back to qemu
<dholbach> cjwatson: thanks for letting me know - does X and the mouse pointer work OK for you (with the old kernel)?
<cjwatson> dholbach: that's been OK for me
<dholbach> ok, thanks
<dholbach> I'll ask soren about it once he's back again :)
<lifeless> RAOF: subverison FTBS? how elegant
<pitti> tkamppeter: are you aware of your three assigned merges on http://merges.ubuntu.com/main.html?
<pitti> tkamppeter: please let me know if some of them can be just synced (which I suppose, since you tend to just apply fixes upstream)
<cjwatson> Riddell: should I disable kubuntu-kde4 CD builds?
<cjwatson> now that you've merged it
<Riddell> cjwatson: yes
<cjwatson> Riddell: done
<asac> siretart: do you have iwlXXXX ?
<james_w> Where's it documented that you can put stuff at the end of debian/changelog, I don't see any mention in policy.
<pitti> james_w: you shouldn't really; what do you want to do?
<james_w> e.g. "Local variables:\nmode: debian-changelog\nEnd:"
<james_w> pitti: I don't want to, and I wish other people wouldn't :-)
<pitti> right
<pitti> people who add that should fix their editor
<james_w> I'm trying to parse them, and these lines don't fit the specified format, but are apparently allowed.
<pitti> james_w: they are not really allowed, but do exist nevertheless
<pitti> james_w: btw, do you use dpkg-parsechangelog, or did you implement it yourself?
<james_w> is there any mention of a standard format anywhere that you know of?
<Keybuk> james_w: you need to always handle unparseable junk at the end of changelog
<Keybuk> since the changelog format itself has changed over time
<pitti> james_w: but for very old packages you'll also find the "old-style" changelogs, which don't match the current syntax either
<Keybuk> so you may hit entries that don't parse, but were valid according to policy at the time
<james_w> yup, I'm just wary of allowing "too much" at the moment, as not getting information about a version could do bad things to my alogrithms.
<emgent> \sh: leonov is avaiable ?
<james_w> I didn't know about --all to dpkg-parsechangelog, so that may be a safer way to go.
<james_w> however, the output of that isn't ideal.
<pitti> james_w: indeed I was pretty surprised that you "changed" to dpkg-source recently; in general I think it's safer to use the standard dpkg-deb, dpkg-source, and other dpkg tools instead of reimplementing parsers
<Mirv> cjwatson: I've tried to reach Jeroen with no luck wrt bug 144741 - the translations for 8.04.1 would be there in Rosetta for most languages, but they've not been fetched.
<ubottu> Launchpad bug 144741 in ubiquity "Untranslated strings in manual partitioning window" [Medium,Confirmed] https://launchpad.net/bugs/144741
<james_w> pitti: yeah, I just didn't think you could get the two parts out separately until recently.
<pitti> james_w: well, it transforms it into reasonable RFC822; Python should have a parser for that in the MIMETools?
<james_w> pitti: yup, but I need the list of versions, which still requires parsing text out of one of the fields.
<pitti> james_w: oh, I see what you mean
<james_w> I could have a loop with --count and --offset it appears.
<james_w> I wonder what happens when I hit the end.
<james_w> empty output, no error, apparently.
<pitti> right
<pitti> so you'd loop until you get an empty output
<pitti> that's quite expensive, of course
<pitti> (subprocess.call()'ing a Perl programm dozens of times)
<pitti> if that was perl, you could use the library (libparse-debianchangelog-perl)
<pitti> james_w: do you just need the versions? or anything else, too?
<cjwatson> Mirv: please talk with evand
<cjwatson> he did the last translation update in ubiquity
<cjwatson> Mirv: if the strings look OK in Rosetta, it's not Jeroen's problem
<pitti> james_w: in the former case, a simple re.finditer() might be much easier and more efficient
<james_w> pitti: I need the whole list of versions, but everything for the most recent version.
<james_w> pitti: I'm the author of changelog.py in python-debian, which is what I use, so it would be good to make that more robust.
<pitti> james_w: I don't think you need to worry too much about old-style changelogs; they were abolished many, many years before Ubuntu even existed and created forks
<pitti> oh, nice! wasn't aware of that package
<siretart> asac: yes, I use iwl3945 on my laptop
<MacSlow> what maketarget also removes autom4te.cache again
<asac> siretart: not sure if its 4965 only, but with nm 0.7 (aka no hacks) essid frequently doesnt get set and stays empty
<asac> not sure if its never set or just bounces back quickly yet
<asac> NM sends ssid to wpasupplicant though
<siretart> I have this phaenomenon as well with the NM from hardy from time to time
<siretart> sometimes it is sufficient to reload the iwl module, yesterday I had to remove the complete configuration entry from NM.
<siretart> NM is sill a very black box for me :/
<\sh> emgent: as preview source sure
<emgent> \sh: launchpad branch avaiable ?
<\sh> emgent: launchpad.net/leonov :)
<emgent> ok thanks :)
<\sh> emgent: on http://leonov.tv/ there are all infos as well including the links to lp
<emgent> cool :)
<asac> siretart: i always assumed that this issue was due to the missing scan_capa patch ... but i have the latest modules from rtg and still see this
<asac> siretart: looks like a race ... what kind of race could that be?
<siretart> asac: a race in the firmware?
<Mirv> cjwatson: oh ok, jeroen was only about getting stuff to rosetta
<Mirv> evand: could you do debian-installer translation update from Rosetta, to have 8.04.1 partitioning screen fixed? the strings are there and translated to 20+ languages.
<cjwatson> Mirv: please note that it was updated at the deadline, though
<cjwatson> r2686 in ubiquity trunk
<cjwatson> Mirv: translators may simply have missed the boat
<cjwatson> unless it was mis-updated somehow
<asac> siretart: please test the disable_hw_scan=1 option for your module
<asac> siretart: for iwl4965 it appears to fix the problem for me \o/
<siretart> asac: what does 'disable_hw_scan' do? (yes, I'll tell my girlfriend to do that)
<asac> siretart: it does what it suggests :) ... it scans from software
 * ogra wildly guesses it also diables the hardware scan at the same time :)
<ogra> who is on sync duty today ?
 * ogra needs cbflib which is not in ubuntu yet to build rasmol
<siretart> asac: with 'software' meaning processed by the linux kernel on the host cpu instead of the broadcom cpu by the firmware?
<Mirv> cjwatson: I feel it was mis-updated somehow. I did notice the changelog entry that translations had been updated, but they weren't actually in the UI.
<Mirv> evand: ^
<Mirv> evand: at least as an example fi.po wasn't updated even though the translation was updated two weeks before the bzr commit on 2008-06-02
<asac> siretart: good question. the driver code suggests that it doesnt do anything except refusing to scan if there is already a HW_SCAN running :(
<asac> but i guess i miss the right code
<asac> siretart: maybe its a bogus option?
<asac> siretart: http://paste.ubuntu.com/21369/
<asac> thats the only place where its actually used
<asac> doesnt look like its really something that contributes to anything except strangeness ;)
<cjwatson> evand: I'm wondering if you got caught out by the fact that Rosetta exports started to unpack into multiple directories?
<cjwatson> ogra: hmm, not showing up in new-source
<ogra> strange
<cjwatson> ogra: https://launchpad.net/ubuntu/+source/cbflib
<ogra> http://packages.debian.org/source/sid/cbflib has it though
<cjwatson> ogra: it's in Ubuntu
<ogra> oh, right, i didnt look on LP
<cjwatson> built and everything
<cjwatson>    libcbf0 |  0.7.9.1-1 | intrepid/universe | amd64, i386
<ogra> oh sigh, i knew that the cmpc has to stay on hardy thing would bite me
<ogra> itsn indeed not in hardy so i can search for ages on my laptop :P
<ogra> (and my chroot only has main enabled on purpose)
<ogra> cjwatson, gracias ... sorry for beng stupid today
<ogra> *being even
<pitti> mvo: hm, I just tried packagekit, this still seems to be pretty buggy :/
<pitti> mvo: Spawn of helper '/usr/share/PackageKit/helpers/apt/resolve.py ~installed pmount' failed
<pitti> mvo: and similar error messages for update, etc.
<mvo> pitti: hrm, ok. I check that out
<pitti> too bad, I thought it would already work nowadays
<pitti> mvo: oh, that didn't mean "fix it now", just for discussing, and whether you tried it out as well already
<pitti> hah, /usr/share/PackageKit/helpers/apt/resolve.py doesn't exist :)
<iwkse> hi almost at the end of the installation (ubuntu hurdy), ubiquity fails. http://pastebin.ca/1050814. Any hints?
<pitti> ah, package_id != package name; pkcon  install 'pmount;0.9.16-4;amd64;available' at least doesn't throw an error (but does not do anything either)
<Hobbsee> evand: ^
<Tm_T> Hobbsee: hi, new hat? looks nice ;)
<cjwatson> iwkse: need to get /var/log/syslog
<Hobbsee> Tm_T: thanks ;)
<iwkse> cjwatson, let me check
<iwkse> cjwatson, there's anything else i can watch? it seems nothing interesting in /var/log/syslog
<iwkse> i'll paste it though
<cjwatson> iwkse: interestingness is a matter of opinion ;-)
<iwkse> cjwatson, of course:) i'll paste it so we can see if our opinion matches
<iwkse> cjwatson, http://pastebin.ca/1051000
<cjwatson> iwkse: err, that doesn't look like the installer has been run in that session
<iwkse> cjwatson, oh, probably it's been overwritten
<cjwatson> iwkse: by what?
<mvo> pitti: the o.2.x branch is better, but not uploaded yet
<iwkse> cjwatson, no idea, i got the log from the installer in a vm
<pitti> mvo: right, I am just downloading 0.2.2 and want to install it locally
<iwkse> cjwatson, i'm sure is this one
<cjwatson> iwkse: well, the evidence has been erased. Can you reproduce the error and fetch /var/log/syslog immediately after the installer fails?
<cjwatson> iwkse: oh, though check /var/log/syslog.0 in case it got rotated
<iwkse> cjwatson, let me see
<iwkse> cjwatson, bingo, it's in syslog.0
<cjwatson> iwkse: ...?
<iwkse> cjwatson, moment i'm pasting it
<iwkse> cjwatson, it seems i fault of mine, some problems in gconf
<iwkse> cjwatson, http://pastebin.ca/1051008
<iwkse> i think i did some rubbish in gconf
<cjwatson> iwkse: yeah, looks like it, though I'm going to change user-setup upstream to not worry if update-gconf-defaults fails
<cjwatson> but you'll want to fix that anyway
<iwkse> cjwatson, yes, that's good to know i have so bad things in gconf
<iwkse> cjwatson, i cry for the old good text configuration files :-(
<iwkse> thank for the help cjwatson, you helped me
<Amaranth> stupid "GPE storm"
<pitti> mvo: ok, will take me a little longer; I need to download and install intrepid and try it there (0.2.x doesn't work on hardy, too old PK and such)
<cjwatson> installing intrepid may still be a little optimistic :)
<cjwatson> though you can upgrade, I guess
<pitti> cjwatson: I thought the current alternates should be (mostly) installable? so they aren't?
<cjwatson> oh, blast, I stopped the publisher this morning and then totally forgot what I was doing
<pitti> cjwatson: d-i isn't built against 2.6.26 or something?
<cjwatson> it is, I just haven't tested past CD detection
 * pitti apologizes for sounding stupid, I'm not really up to date wrt. intrepid
<pitti> cjwatson: well, then I'll give you some further results soon :)
<cjwatson> the boot loader is also a bit hosed
<cjwatson> it should be usable, it'll just look odd
<cjwatson> yesterday, I got as far as CD detection and then had to rebuild d-i due to some kernel udeb changes
<cjwatson> haven't tested the new version yet
<cjwatson> publisher re-enabled; I fixed up hardy-proposed/restricted/debian-installer/ (I hope), and copied the installer images from hardy-proposed to hardy-updates to match the debian-installer source package
<pitti> seb128: ok, I think you convinced me about smb LANMAN; so we should reenable it for .1, create the better UI, and then disable it in all supported releases and add the new UI in a security update; ok for you?
<seb128> pitti: exactly what I suggest yes ;-)
<seb128> slangasek: ^
<pitti> slangasek: so, Seb and I discussed this at length this morning (some other folks participated, too); they finally convinced me, mainly because exposure of smb shares is usually limited to reasonably trusted environments, and not to the internet
<evand> Mirv, cjwatson: OK, I'll look into it.  Is it too late for updating translations in 8.04.1?
<cjwatson> it's difficult since ubiquity is currently waiting in -proposed for verification
<mvo> hey doko! do you mind if I take some of your merges?
<doko> mvo: not at all. was looking at subversion and wondering why the debian maintainers thinks its better to build things twice ...
<seb128> doko: what was this libdb thing you told me about yesterday?
<cjwatson> I thought I'd fixed up libdb the other day
<doko> ohh, nevermind, was confused by some b-d's requiring both 4.6 and 4.7 -dev packages
<cjwatson> (I fixed a bunch of uninstallable stuff over the weekend, db was deeply embroiled in that)0
<pitti> cjwatson: dhcp in the  installer didn't work for me, and the gfxboot menu is a bit strange, but at least it's installing
<cjwatson> pitti: dhcp: bug 241295
<cjwatson> pitti: I think I have gfxboot nearly fixed now
<gribouille> still trying to find what's wrong with firefox+google toolbar, but it isn't easy without a working version of firefox with debugging symbols
<pitti> cjwatson: I'm crossing fingers that the kernel will be alright
<pitti> cjwatson: want a bug for "asks question about scanning another CD"?
<cjwatson> yes please
<cjwatson> I hadn't got that far yet
<gribouille> bash: /usr/lib/debug/usr/lib/firefox-3.0/firefox: cannot execute binary file. is it normal ?
<Chipzz> gribouille: you're not supposed to execute that file
<Chipzz> just start firefox the way you normally would
<pitti> cjwatson: bug 241304
<pitti> cjwatson: I can attach the installer log after installation is finished
<cjwatson> probably not needed
<pitti> cjwatson: ah, dang, failed; xserver-xorg-video-ati is not installable
<lifeless> so with WINE reaching 1.0, can it run windows viruses yet ?
<pitti> ^ bryce, tjaalton: -ati depends on -r128 amd -mach64, which are not installable
<gribouille> 1759 stack frames for firefox ! what's the term for such software ? bloatware ?
<cjwatson> pitti: should be fixed soon; I promoted xserver-xorg-video-{r128,mach64} as obvious split-outs
<cjwatson> pitti: need to wait for nautilus to build though
<pitti> cjwatson: thanks for fixing; well, ATM I just went on in manual mode and now use apt-get install ubuntu-desktop
<bigon> infinity, are you around?
<bXi> hello
<bXi> whats the best place to "whine" about outdated libraries?
<dholbach> bXi: file a bug report on the package and tag it as 'upgrade'
<bXi> dholbach: i do this on launchpad right?
<dholbach> right
<bXi> ok
 * bXi looks for the pacakge
<dholbach> perfect
<bXi> -typo
<Keybuk> pitti: you wanted to know about prefetch
<pitti> Keybuk: your opinion about it seems to have aggravated dramatically since UDS? :)
<pitti> james_w: so you have a s3kr1t branch on top of PackageKit 0.2.2 which makes apt backend truly work? (I haven't tried 0.2.2 upstream yet, still installing hardy)
<Keybuk> let me grab a drink, and I'll pull up an arm chair while you stoke the fire ... :p
<pitti> Keybuk: getting out the poker chips then
<BenC> pitti: hey, I thought there was something in apport to detect if /var/crash/vmcore existed, to signal that there was a kernel crash
<pitti> hi
<james_w> pitti: I think my patch is in 0.2.2, but I'm not sure.
<pitti> BenC: not ATM; the last time we spoke about it we designed the interface for /usr/share/apport/kernel_hook, which is there for ages
<BenC> pitti: right, but that just helps to gather info right?
<pitti> BenC: right, it currently doesn't have any support for cores
<BenC> pitti: what would it take for apport to trigger on /var/crash/vmcore existing, and take action to report a bug on the kernel?
<BenC> and ask that the core be included in the bug report
<pitti> BenC: we only have the existence of the file as a trigger? i. e. not something like core_pattern for userspace crashes which could call a binary on an oops?
<pitti> BenC: or should we just check it on boot?
<BenC> pitti: there's actually two triggers vmcore, and vmcore.log (the former may not exist if makedumpfile failed for some reason, but there was still a crash)
<gribouille> where can I find firefox source code online ?
<pitti> (that would be easy, we can do it in the init script)
<BenC> pitti: check on boot
<BenC> pitti: vmcore.log will always exist after a kernel crash, vmcore will most times
<joaopinto> gribouille, apt-get source firefox will get you the source code for the ubuntu package
<pitti> BenC: ah, that's easy then, no inotify watching required
<pitti> BenC: could you please open a bug against apport and put in all the paths and the semantics?
<lool> cjwatson: d-i ftbfsed on lpia http://launchpadlibrarian.net/15175531/buildlog_ubuntu-hardy-lpia.debian-installer_20070308ubuntu40.3_FAILEDTOBUILD.txt.gz
<pitti> easier to track for me
<cjwatson> lool: d-i isn't used on lpia
<lool> cjwatson: (I'm looking at hardy-updates -> ume archive promotions)
<pitti> BenC: I should be able to do that relatively quickly; still busy with hardy.1, but that will be done soon
<cjwatson> lool: so I've never cared about build failures there
<pitti> BenC: please also have a look at /usr/share/apport/kernel_hook for the other information it collects; anything that's obsolete or anythign that should be added?
<BenC> pitti: ok, thanks
<BenC> pitti: I checked it, looked good
<pitti> BenC: (aside from the obvious source package renaming, etc.)
<lool> cjwatson: Ok; I'd like to fix it still, we might use d-i bits in intrepid at least; I'm curious about the dpkg barks and I would guess something is weird if gcc is missing
<ogra> cjwatson, well, we should start consdering using d-i on lpia imho
<lool> Also, it shows up in my promotion report, but I could avoid it
<ogra> proper preseeding and the ability for using oem mode is really a good idea i think
<lool> I guess I'll grab it for intrepid and see if it fails to build then see how to port it
<lool> I misread the hardy ftbfs at first, I thought it was just missing bdep
<cjwatson> lool: happy to do so for intrepid if you so wish
<cjwatson> lool: it's almost certainly just that there's no configuration for lpia; the d-i build system is extremely architecture-specific
<ogra> d-i is supressed on lpia in the linux-image source
<cjwatson> the gcc: not found message is in the base system, I think
<cjwatson> and happens for everything, so don't worry about it
<ogra> there shouldnt be any udeb build attenpts even
<cjwatson> yes, kernel udebs would need to be laid out too
<ogra> which indeed also means lpia will start to need an abicheck (which in turn makes life hard on PPAs)
<lool> cjwatson: Ok
<cjwatson> ogra: udebs don't significantly increase the need for an abi check
<pitti> BenC: oh, please assign that bug to me (apport kernel crash)
<cjwatson> I mean, they do a bit, but far less so than e.g. lrm
<ogra> oh, i thought they were one of the resons for having it
<ogra> ah
<cjwatson> quite a minor reason, really
<ogra> or more iportant on lpia lum :)
<ogra> *important
<gribouille> I still don't understand why it is better to use the version of firefox that is distributed by ubuntu instead of the originak one
<cgregan> liw: ping
<Keybuk> pitti: right, so, prefetch
<Keybuk> I think that the idea of doing this in the kernel is the right one
<Keybuk> that in the kernel, we intercept requests for disk blocks and record them is absolutely correct
<Keybuk> and that when a binary is exec()d, we automatically load the blocks it requires
<Keybuk> much better than the readahead approach of doing the watch by inotify, and the fetching by a userspace tool
<pitti> right, so that didn't change so far
<ogra> will prefetch work with stacked filesystems (unlike readahead with unionfs) ?
<afflux> pitti: you are the main apport developer, right? apport strips "k" from function calls / similar, because my username is "k".
<pitti> ogra: it's all about blocks on block devices, below the VFS layer AFAIUI
<Keybuk> so one would assume that the way prefetch works is this:
<Keybuk> - when a process requests a block, it's recorded
<pitti> afflux: hm, I thought I fixed that in hardy-updates
<Keybuk> - and tracked back to its pid, and thus the executable on disk
<afflux> I'm on intrepid
<Keybuk> - and a table of executable -> block is updated (and visible in /proc or similar)
<afflux> pitti: see the function calls in bug 241320
<ubottu> afflux: Bug 241320 on http://launchpad.net/bugs/241320 is private
<Keybuk> when an executable is loaded, the table is read to know which blocks to fetch
<pitti> afflux: hm, can you please file a bug with an example crash file?
<afflux> woops, made public now.
<pitti> Keybuk: right, that would be straightforward; maybe an inode (renames/moves), but that's quite similar
<Keybuk> ok
<Keybuk> we might want to do grouping of apps into stages
<Keybuk> so we prefetch boot at once
<Keybuk> we might do that by writing "boot" to a stage file, and the stage -> app association is recorded
<Keybuk> when we change a stage, we prefetch all of the blocks for all of the apps
<Keybuk> if we were clever, we might just do that with cgroups - use a cgroup property to specify the stage for an app, and do it that way
<BenC> pitti: ok
<Keybuk> but that last bit is a bit of a "obviously it doesn't work like that now"
<pitti> Keybuk: so that'd be even more efficient than fetching per-binary?
<pitti> Keybuk: ah, I see what you mean, I think
<BenC> pitti: bug #241322 created and assigned to you
<ubottu> Launchpad bug 241322 in apport "Detect kernel crashdump" [Undecided,New] https://launchpad.net/bugs/241322
<pitti> Keybuk: so unlike readahead (which slurps in everything we need for boot), you still get interruptions with prefetch, since it only fetches whenever you actually start a process? that sounds weird
<pitti> BenC: thanks
<Keybuk> pitti: oh, it's worse than that ;)
<Keybuk> I was describing how it _should_ work
<Keybuk> now, this is how it works:
<Keybuk> when you exec() an app, it remembers the executable name, and starts a timer (30s)
<pitti> it would be much better if the blocks were already in the cache even before the app is started
<Keybuk> all block accesses within that time are associated to the app
<Keybuk> if you start two apps, then all block accesses will be for the second app
<pitti> BenC: thanks, looks fine
<Keybuk> stage is done by overriding the timer, and just associating all block accesses with the magic "stage"
<pitti> so that would be the step which brings the actual speedup (the grouping and loading everything in advance)
<Keybuk> except it doesn't
<Keybuk> since everything just gets mashed
<pitti> Keybuk: hm, I always assumed that the kernel would merely do the collection of data; the actual prefetching had to be done in userspace, based on a list of blocks you collected earlier
<pitti> Keybuk: well, mashing for a group should be fine, and is even intended, so that you can sort all the blocks you need to be read with peak performance, no?
<Keybuk> pitti: it'd work if the grouping wasn't "by time"
<Keybuk> consider:
<Keybuk> start openoffice, then firefox
<Keybuk> all of openoffice's blocks will now be read every time you start firefox
<pitti> Keybuk: but only if that 'read for prefetching' is done automatically by exec(), right?
<Keybuk> which is desirable
<pitti> hm, I'm not sure about that
<Keybuk> done right, it makes openoffice start really fast the second and onwards time ;)
<Keybuk> consider the udev case on boot
<Keybuk> it lasts a long time
<pitti> if you merely look at boot speed, I'd think it wuold be better to have a small program that gets a sorted list of blocks, slurps them all in, and then starts the boot sequence
<Keybuk> in fact, it does stuff pretty much through each stage of the boot
<Keybuk> so you end up prefetching it three times, for each stage
<Keybuk> pitti: that's what readahead does
<pitti> Keybuk: exactly
<pitti> Keybuk: but this time with autogenerated, auto-updated data
<Keybuk> prefetch doesn't really help here
<pitti> I just fail to see how "fetch the blocks on exec()" can be much more efficient, since that happens on exec() away?
<Chipzz> gribouille: you didn't actually read what I told you, did you?
<Keybuk> pitti: it's more, fetch blocks inside the kernel
<Keybuk> you'd fetch on exec() for programs after boot
<pitti> Keybuk: so the problem is that it cannot tell apart which block belongs to which process
<gribouille> Chipzz, about what
<Keybuk> during boot, you'd fetch on the start of a stage
<pitti> bummer
<Chipzz> 15:22 < gribouille> bash: /usr/lib/debug/usr/lib/firefox-3.0/firefox: cannot execute binary file. is it normal ?
<Chipzz> 15:23 < Chipzz> gribouille: you're not supposed to execute that file
<Chipzz> 15:23 < Chipzz> just start firefox the way you normally would
<Keybuk> echo boot > /proc/prefetch/stage - causes everything "Boot" to be fetched
<Keybuk> that's fine
<gribouille> Chipzz, of course I did
<Keybuk> it's how it decides what was "boot" and what was "gui" that's the problem
<Chipzz> then that should work
<gribouille> Chipzz, of course it did.
<pitti> Keybuk: hm, but if it integrates the gdm bits into the block ordering/prefetching, that can only benefit us?
<Keybuk> pitti: I don't follow?
<Chipzz> gribouille: if you want the source, apt-get source firefox I think
<pitti> Keybuk: I mean, we do want to prefetch gdm, libgtk, etc. as well
<Keybuk> pitti: we do
<Keybuk> but we don't want to _over_fetch_
<Chipzz> which will extract the source in the current directory
<Keybuk> the danger with things like prefetch is that they can be too enthusiastic
<gribouille> Chipzz, I know that
<Keybuk> so actually spend longer fetching things than it would have taken to just load them anyway
<pitti> Keybuk: you mean if the user does autologin and immediately starts OO.o while still measuring boot
<Chipzz> then why are you asking where to get the source? :p
<Keybuk> pitti: actually, I just mean that the overlap between boot and gui in Ubuntu (we start gdm while stuff is still going on) kills us ;)
<Keybuk> we end up fetching things twice
<pitti> Keybuk: why twice?
<Keybuk> gdm loads, and fetches its pages by itself
<Keybuk> a little later, prefetch goes "oh, and load gdm"
<Keybuk> often half way through the login after gdm got paged back out again
<gribouille> Chipzz, don't bother, I've found the solution to my problem
<Keybuk> it's the "fetch by time" stuff that's the issue
<pitti> Keybuk: but in the end we want to read it all (boot+gdm+maybe session) in one efficient big block, since the net time will be still faster, even if parts of the boot will happen later due to the large prefetch
<Keybuk> pitti: nope
<Keybuk> we want to read the really essential bits first
<Keybuk> then, while udev is spinning and HAL is waking up
<Keybuk> we read in more
<Keybuk> hammer the disk while we're blocked in other things
<Keybuk> if you prefetch the entire boot into memory at the start, you'll actually usually overflow the memory ;)
<pitti> ok, good point, if you have little memory
<Keybuk> not even then
<Keybuk> I think prefetch would be better if it were process tree based
<pitti> yeah
<Keybuk> ie. if we prefetch gdm (either because it was exec()'d or because we did it manually)
<pitti> I wasn't aware that it is only time-based
<Keybuk> then it prefetches the entire login tree until we changed something
<Keybuk> we might for example have essential boot, system daemons, gdm, user login
<Keybuk> and do those by the pid that starts them (or group of pids)
<pitti> hm, so once again we don't have a good solution implemented :/
<pitti> eww, the vmmouse driver in intrepid seems to be totally broken
<Keybuk> pitti: no
<Keybuk> I've gone through the prefetch code, and I don't think it would be hard to make it behave well
<Keybuk> after all, it's basically just vm block dump ;)
<Keybuk> but there are several things on the critical path before I can do kernel patches <g>
<pitti> james_w: joy; 0.2.2 does not even build
<james_w> pitti: oh dear.
<james_w> I was using a snapshot from just before 0.2.2, so I don't know what changed.
<james_w> pitti: I can make my source package available if you like.
<pitti> james_w: which configure arguments did you use?
 * pitti used --enable-apt --with-default-backend=apt --enable-tests
<james_w> I don't think you want --enable-tests
<james_w> pitti: --enable-apt --disable-dummy --with-default-backend=apt --with-security-framework=polkit
<pitti> james_w: for me it crashes in pk-main.c, over some invalid g_set_error()
<pitti> but it uses a lot of constants and macros, it's not just a trivial typo
<pitti> james_w: will try that, thanks
<pitti> james_w: hm, same problem
<pitti> james_w: might be a gcc-4.3-ism
<pitti> oooh
<pitti> james_w: indeed, that looks like a -Wformat-security issue
<pitti> and it uses warnings-as-errors
<pitti> it's all kees' fault :-P
 * pitti hugs kees
<james_w> pitti: lp:~james-w/packagekit/debian-packagekit-0.2.x.jamesw
<pitti> james_w: hah, I fixed it; it really was -Wformat-security
<pitti> I'll send that fix to upstream
<pitti> james_w: thanks anyway
<james_w> well, I hadn't fixed that, so thank you.
<seb128> hum, archive.ubuntu.com still outdated
<seb128> is the mirror sync not running?
<liw> cgregan, pong
<pitti> james_w: did "make test" work for you ? it fails on "get distro ID" for me
<james_w> pitti: never tried it, sorry, I was just trying a few manual tests.
<james_w> what's the failure?
<pitti> james_w: ok, thanks
<pitti> well, it just says that
<pitti> haven't looked into details
<cgregan> liw: I had a mentor question for you. Heno picked it up in your absence.
<liw> cgregan, ok, cool
<Twigathy> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/221613 <-- failbug :(
<ubottu> Launchpad bug 221613 in initramfs-tools "NFSroot broken on hardy" [Undecided,New]
<lamont> 92 MB is not a diff. kthx
<ogra> so you dont touch diffs under 100M ?
<laga> lamont: unzip it?
<lamont> if the diff is that large, it's time to tar it up as openoffice.org_2.4.1+ubuntu1.orig.tar.gz.  really.
<lamont> unless that's 92 MB of _new_ stuff
<Hobbsee> i'ts probably new spaghetti code, for your enjoyment.
<lamont> it's Oo.o...  enjoyment is not possible.
<seb128> lamont: better to upload 90meg than 360
<Hobbsee> lamont: i was thinking of the sadistic type.  or masochistic.  whichever it is.
<wasabi> So would anybody be opposed to something like preventing smb/winbind from stopping BEFORE an upgrade, and only making it restart in the postinst or a trigger or something?
<wasabi> When winbind is the provider of your NSS passwd table, stopping it for 3 minutes sort of sucks.
<mathiaz> wasabi: that seems reasonable - did you file a bug ?
<mathiaz> wasabi: slangasek may also have an opinion on this issue (^^)
<pitti> james_w: *sigh* I built with correct sysconfdir(/etc) and prefix(/usr) now, and yet it says "launch helper exited with unknown return code 1"
<james_w> pitti: do you have /usr/lib/packagekit/aptDBUSBackend.py ?
<pitti> james_w: I have an /usr/lib/packagekit-backend/libpk_backend_apt.so
<james_w> you need both of them.
<pitti> it didn't even install a directory /usr/lib/packagekit/
<pitti> james_w: ok, I'll copy it manually
<pitti> didn't help, though
<james_w> pitti: running "packagekitd --verbose" often gives good clues, if you haven't found it already.
<lamont> generally speaking, having daemon's stay alive across upgrades is a good thing.
<pitti> james_w: ah
<pitti> james_w: I just used pkmon so far, but that isn't very helpful
<mvo> pitti: you may need to build with the "apt2" backend - not sure if they have merged already
<mvo> (sorry, was distracted and only just looked at irc)
<pitti> mvo: that option is still in 0.2.1, but not in 0.2.2 any mor3
<james_w> the rename has been done in 0.2.2 I think
<pitti> I think the DBUS apt backend is the only one in 0.2.2 now
<mvo> aha, cool
<mvo> even better
<pitti> hm, nothing really enlightening
<pitti> a-haa
<pitti> /etc/init.d/dbus reload did the trick
<pitti> odd, I thought that bug was fixed now
<pitti> so 'search' and 'refresh' work, and 'install' gives me a nice Python backtrace about a missing function in policykitd --verbose
<pitti> james_w: ah, seems that "make install" put aptDBUSBackend.py into /usr/libexec/
<pitti> ugh, there are so many bugs in aptDBUSBackend.py that this can hardly have been tested on any Debian so far
<mvo> pitti: its in development (glatzor was working on it) and PK changes really fast
<pitti> ok, I think there is something major missing in doResolve(), which isn't just a typo
<pitti> yay, I got doResolve() working mostly \o/
<pitti> get-details works now
<james_w> pitti: "get-details package_id" or "get-details package_name" ?
<pitti> james_w: "get-details pmount" works now
<pitti> "install pmount" doesn't
<james_w> ah cool, nice work.
<pitti> but right, I need to specify an ID there, don't I?
<james_w> you used to, but I think it's supposed to do package names now.
<pitti> hm, if I disable teh _is_package_visible() test, "install pmuont" works
<james_w> I've never worked out what is missing to allow that.
<calc> anyone looking into fixing bug 185311 ?
<ubottu> Launchpad bug 185311 in libxcb "hardy, locking assertion failure, xorg/libsdl" [High,Confirmed] https://launchpad.net/bugs/185311
<pitti> so apparenlty there are some filters in action
<calc> its causing OOo to crash a LOT
<pitti> james_w: right; "install package_id works
<pitti> james_w: and "remove package_name", too
<pitti> james_w: so, I guess that's "good enough"
<bdmurray> If I find a bug requiring sponsorship the right thing to do is subscribe the appropriate team correct?
<james_w> pitti: yeah, I don't think anyone's going to actually use the tools directly.
<iwkse> cjwatson, ping?
<calc> bryce: ping
<pitti> james_w: right, I wasn't either, but they are great for testing the backend
<james_w> I'm not even sure we should have gnome-packagekit in the archive for a while.
<cjwatson> iwkse: pong
<iwkse> cjwatson, according to this http://pastebin.ca/1051008, it seems i can't file the file since it's in temp file :\ looks like a panel schema file though but i couldn't see such errors in the panel schema file.
<cjwatson> iwkse: are you modifying this CD?
<iwkse> cjwatson, yeah
<cjwatson> it's rather hard for me to say then ...
<iwkse> cjwatson, changing the panel objects
<pitti> james_w: ok, I'll send the two patches to upstream now; bug reports will work, I assume?
<james_w> I assume so, I've done patches to the mailing list previously.
<pabix> Hello, where is it possible to leave suggestions?
<Keybuk> pabix: brainstorm.ubuntu.com
<iwkse> cjwatson, actually gconf in this step is doing update-gconf-defaults?
<pabix> Keybuk, thanks
<cjwatson> iwkse: user-setup is calling update-gconf-defaults
<iwkse> cjwatson, i see, if i call directly update-gconf-defaults i don't get errors
<cjwatson> it's not doing anything unusual
<iwkse> i see
<cjwatson> remember that it's calling it chrooted to /target
<cjwatson> so 'sudo chroot /target update-gconf-defaults' if you want to try to reproduce it
<iwkse> ah ok, thanks
<pitti> kees: what's the compiler switch for enabling format string warnings? -Wformat-security, something like that?
<pitti> ah, I think that's it
<calc> bryce: ping?
<RiotingPacifist> i need to manually install some source code for a ubuntu package, where to i put it so that compilers know its thier?
<jordi> are there any daily CDs of hardy with the latest packages accepted in main?
<jordi> ie, a test cd of 8.04.1?
<persia> RiotingPacifist: It very much depends on the package.  Take a look at debian/rules to determine how patches are applied for a given package.
<RiotingPacifist> thx
<persia> jordi: http://cdimage.ubuntu.com/hardy/daily/ is likely the closest (but perhaps not quite what you seek)
<pabix> Keybuk, proposal done!
<kshah> thanks for fixing my eSATA problem with the last update
<slangasek> wasabi, mathiaz: I'm not opposed to keeping winbind running until the postinst on upgrades, as long as we're idempotent and handle all the maintainer script cases :)
<slangasek> pitti: yes, samba SRU being prepared now
<kees> pitti: yeah, -Wformat-security (which requires -Wformat also)
<kees> pitti: so, technically,  -Wformat -Wformat-security
<kees> pitti: https://wiki.ubuntu.com/CompilerFlags
<pitti> kees: thanks
<kees> pitti: why? reporting upstream bugs?
<pitti> kees: yes, freedesktop bug 16431
<ubottu> Freedesktop bug 16431 in core "Fails to build with -Wformat-security" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=16431
<kees> pitti: yeah, I've been plucking FORTIFY_SOURCE patches out of Fedora and sending them to upstreams.
<mvo> james_w: we need to ask glatzor to add more administrators to the packagekit team :)
<persia> sistpoty, nixternal: congratulations !
<tseliot> mvo: do you have experience with PolicyKit?
<zul> slangasek: bug #180493 those two bugs look similar to me since the network has been disabled but nmbd dies
<ubottu> Launchpad bug 180493 in samba "[SRU] nmbd shuts down when network disconnected" [Medium,Fix released] https://launchpad.net/bugs/180493
<cody-somerville> nixternal, congratz. :)
<slangasek> zul: sure; I just think it makes more sense then to merge the bugs instead of listing two bug numbers for the same issue in the changelog?
<slangasek> zul: a minor point - dropping the security patch is a bit more of a problem :)
<zul> slangasek: sure no problem
<zul> slangasek: yeah I didnt realized that I did that
<zul> it can wait until afer 8.04.1
 * calc pings bryce until he looks at irc again ;-P
<kirkland> slangasek: hey, question about bug 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,Confirmed]
<ion_> Meh, .local/bin :-)
<slangasek> kirkland: <whine>
<calc> hmm it sounds like 185311 was fixed already but just fixed in debian recently if i am reading the changelog correctly, so why am i getting all these locking bugs still :-\
<kirkland> slangasek: :-?
<slangasek> kirkland: what's your question? :)
<kirkland> slangasek: i'm guessing since that since that bug is really old, the one-line fix i submitted is probably not acceptable as is
<kirkland> slangasek: i guess i'm asking you if that bug is really a "won't fix"
<slangasek> kirkland: well, that won't get you tilde expansion within the environment variable; not sure whether that's required, or by which shells
<slangasek> pitti: samba SRU in the queue for you
<kirkland> slangasek: understood that the tilde will be written to /etc/environment ...  my shells (dash/bash) are okay with it and it works as expected
<slangasek> I think it ought to be checked with some other common interactive shells, like zsh and maybe ksh
<kirkland> slangasek: i'll go test.....
<zul> its libdb4.7 in intrepid now isnt it? so sources hardcoded to use db4.6 have to be updated?
<slangasek> kirkland: otherwise, I guess I can't see any reason to treat it as wontfix; it will slow down tab completion if $HOME is on NFS though
<kirkland> slangasek: yes, i think kees raised that (or a similar) concern
<kirkland> slangasek: I can add some logic to test that, i suppose, if you think it's necessary
<slangasek> kirkland: no, I think that would be overengineered at that point :)
<mathiaz> zul: yes - better to depend on libdb-dev though
<zul> k
<slangasek> zul: hrm, I don't know that there's been any discussion of systematically moving to db4.7 for intrepid; fwiw, Debian is entering freeze for lenny soon and will most likely not see updates to db4.7, which means pretty much all such updates will be a divergence
<slangasek> mathiaz: no, libdb-dev is an abomination :P
<slangasek> if you build-depend on libdb-dev, you have no guarantee that a random rebuild won't render your program incompatible with your on-disk data
<mathiaz> slangasek: when I merged bogofilter, I saw that : Build-Depends: libdb-dev (>= 4.6.19-1)
<pitti> well, admittedly the db format hasn't changed in ages, and most packages don't have on-disk transactions (those should depend on db4.x-dev)
<slangasek> mathiaz: bogofilter has the same maintainer as libdb itself
<mathiaz> slangasek: hm.. bad example then
<slangasek> :)
<mathiaz> pitti: when you did the libdb4.6 migration in hardy, what did you use ? libdb4.6-dev or libdb-dev ?
<zul> it doesnt look like libdb-4.6 is available now though?
<pitti> mathiaz: hm, I'm not actually sure any more; I think libdb-dev for the pacakges without transactions
<pitti> zul: it's 4.7 now
<pitti> db is a PITA :/
<slangasek> anyway, any change in db version requires a sourceful upload in Ubuntu, I don't see the value in creating a delta to use libdb-dev
<slangasek> db4.6 is still available, incl. libdb4.6-dev
<mathiaz> pitti: ok
<slangasek> libdb4.7-dev is also available :)
<mathiaz> slangasek: so the policy in debian is to use libdb4.X-dev ?
<slangasek> there's no policy
<slangasek> I'm just saying that libdb-dev is an abomination :)
<slangasek> if it had been named libdb<version number of on-disk format>-dev, that would have made sense
<pitti> slangasek: samba accepted
<zul> so should php5 be using libd4.6-dev instead of libdb-dev?
<zul> ergh libdb4.6-dev
<pitti> zul: php5 doesn't use on-disk transactions, so this would be ok with libdb-dev
<EagleScreen> hello, can anyone help me?? i need help to validat my GPG on Launchpad, i am reading this howto: https://help.ubuntu.com/community/GnuPrivacyGuardHowto and it gives this other link for validating on Launchpad: https://help.ubuntu.com/community/https%3a//launchpad.net/%7e%3cusername%3e/+editpgpkeys but i think the link is not working propertly
<tormod> EagleScreen: -> #ubuntu-doc - seems like a typo
<LaserJock> siretart: good email
<nixternal> persia and cody-somerville: thanks!
<LaserJock> nixternal: congrats!!
<nixternal> thanks
<nixternal> nothing like walking 1/2 mile for food, then walking 1/2 mile back after eating...I am hungry again :)
<LaserJock> nixternal: now get to work!!! *whip*
<nixternal> I am at work
<nixternal> tired now after eating :)
<LaserJock> no, *real* work
<LaserJock> the *buntu kind
<nixternal> I would kill to do that kind right about now
<nixternal> anyone good with Kickstart and Anaconda?
<cjwatson> only in that I stared at it enough to reimplement Kickstart for Ubuntu about three years ago
<cjwatson> I'm not sure this will actually help you
<nixternal> hehe, I wish our appliance used Ubuntu, then I would just use FAI
<nixternal> oh well, I will just have to use the hackish way and place the tune2fs -m 0 in a %post script using Python
 * slangasek shakes his fist at seb128's retreating form... oh sure, upload and run then :)
<kirkland> slangasek: okay, appending ~/bin to /etc/environment seems to work for (bash, dash, ksh, ash), but not for (zsh, csh, fish, tcsh, es, rc, sash)
<slangasek> seb128: hmm, the upstream comment in bug #207072 is wrong, I tested this patch in a Kerberos environment and it works correctly
<ubottu> Launchpad bug 207072 in gvfs "nautilus does not display samba shares for machines inside an ADS network." [Unknown,Confirmed] https://launchpad.net/bugs/207072
<slangasek> seb128: so either he's commenting on a previous version of the patch, or we're getting a disconnect somewhere else
<seb128> slangasek: which one? yours or the new upstream version?
<slangasek> seb128: I tested my patch in an ADS env
<slangasek> kirkland: right, about the spread I was expecting :-)
<seb128> slangasek: could you try the current upstream version (that's the one I uploaded to intrepid)?
<seb128> slangasek: note that upstream is a redhat guy and I think they are using samba 3.2.0 pre versions if that makes a difference
<seb128> slangasek: I'm also not sure what would be the right behaviour for anonymous against authentificated logins
<slangasek> seb128: hum, I'm looking over the patch right now, and it looks pretty darn similar to mine.. so I think upstream's comments are about the original patch :)
<slangasek> seb128: this bug report exists specifically because anonymous connections are made without giving the user a chance to provide a username/password instead; so like I said, if we continue to try anonymous connections before asking for auth, we aren't fixing this bug
<seb128> the issue is that you don't want to get a password prompt for every click you do on a local network which requires no authentification
<slangasek> true; could users save settings to the keyring, in that case?
<seb128> what setting?
<slangasek> the "anonymousness" setting :)
<seb128> they somewhat solved this issue in gnomevfs I think, I need to look how
<seb128> but my gut feeling is that default should be anonymous
<seb128> and you should be able to specify an user name in the uri or using a menu item in case that's required
<slangasek> er, for hardy, the difference in default is the difference between "users with unpassworded resources have to click past the auth dialog, and that's annoying" and "users who need to authenticate to get a browse list can't use the GUI browser at all"
<seb128> slangasek: did you look at the difference between your patch version and the new upstream one?
<slangasek> seb128: still grabbing it
<seb128> is that only the order between password and anonymous login?
<seb128> one thing to consider is that "upstream" is a new upstream guy
 * slangasek nods
<seb128> the gvfs maintainer is on holidays currently
<seb128> and the one who is writting the patch started looking at gvfs and nautilus some weeks ago but I don't think he knows the code really well yet
<slangasek> just so I can keep this all straight - what's the name of this new upstream guy?
<seb128> Tomas Bzatek
<slangasek> ok
<seb128> he's the one who attached the new patch version and commented
<seb128> he's not really upstream for gvfs but working for redhat and looking at gvfs and nautilus for them and the most active contributor currently
<seb128> technically Chistrian Kellner is the maintainer
<seb128> and Alexander Larsson is the original maintainer who is on holidays
<slangasek> yes, the main difference between the patches is prioritizing anonymous before password auth
<seb128> ok, so I think I'll argue with you than we should get things working first and fix annoyances then
<seb128> s/argue/agree
<slangasek> ok
<slangasek> he also adds an smbc_getdents() check... let me see what the semantics are
<slangasek> because that might mitigate somewhat
<slangasek> mm, no, it doesn't
<slangasek> (I was hoping his check might detect the case of zero share entries, but it doesn't)
<seb128> is there still a slot to get your change in 8.04.1?
<seb128> I though that was the idea
<seb128> 0 share = try login
<slangasek> well, that's not what his code does :)
<bryce> what do the different colors on the MoM page indicate?  browsing through the MoM source they seem to be related to some sort of prioritization?
<seb128> ok, so let's use your version
<slangasek> ok
<seb128> should I talk to pitti about getting that accepted tomorrow morning
<slangasek> we can still get this into 8.04.1, yes; we still have pulseaudio hanging over our heads
<slangasek> ( :/ )
<seb128> or will you accept it to hardy-proposed if I upload it tonight?
<seb128> anyway tonight or tomorrow morning will not make a big difference
<kirkland> bryce: i think it has to do with how old or how long it's been since the last merge
<seb128> I'll prepare the upload and let see who accepted it then
<slangasek> seb128: yes, if you want to get it done tonight I'll accept it; I wasn't going to suggest that, you're allowed to sleep instead and do it in the morning :)
<seb128> slangasek: that's alright, it's not late yet ;-)
<bryce> kirkland: yeah I also thought it was age related, which is why I was surprised to see it listed as a priority thing
<slangasek> seb128: oh - ok, reading closer, the smbc_getdents() part would mitigate
<slangasek> seb128: so it would address the AD case, it would not address the "per-user samba share" case
<slangasek> so it's up to you which you think is more appropriate, I'll accept either one
<seb128> well, I think if the upstream one mitigate I would accept it on the basis that setups allowing to list different shares anonymously or using login are not too frequents, but I'm not sure this assumption is right
<seb128> I've no real idea on what setups are used in real world
<slangasek> one specific real-world case is the commented-out example in our smb.conf for user home directory shares :)
<seb128> I mean that seems to be a good comprise if we don't annoy desktop users and allow to browse ad domains
<slangasek> yes, I think it's a reasonable compromise
<seb128> ok, so let's try this one for now then
<seb128> I've already uploaded an updated gvfs to intrepid
<seb128> let me know if you can give a try to the patch in your ad setup before I upload to hardy
<seb128> just to make sure it works for somebody ;-)
<slangasek> seb128: I only have my laptop set up for AD and it's still running hardy, and the AD setup is through the work VPN, so I'm afraid I'll have to test after it's uploaded
<seb128> slangasek: alright
<mathiaz> Keybuk: I've modified mom to include the section (updated, outstanding or new) in the status file (tomerge-*). See https://code.launchpad.net/~mathiaz/merge-o-matic/section-in-status-file
<mathiaz> Keybuk: what do you think about it ?
<hwilde> when I run "top" what is meant by the "buffers" in the memory display?
<hwilde> Mem: 507664k total, 475780k used, 31884k free, 92116k buffers
<hwilde> don't feel bad, nobody else knows either... :/
<Keybuk> hwilde: socket buffers, memory for devices, stuff like that
<hwilde> right but what is the interpretation of this?  is that memory in use, or is it free
<Keybuk> in use
<Keybuk> well
<Keybuk> available
<hwilde> yeah exactly
<Keybuk> it's the amount of memory currently taken up by buffer structures
<Keybuk> not the amount of memory in actual use
<hwilde> lol
<Keybuk> should the system run low on memory, the kernel will return much of that if it's not actually being used
<Keybuk> likewise for cached
<Keybuk> cached is the amount of memory currently taken up by the page cache
<Keybuk> since any of that can be returned, since it's just a copy of what's on disk, it's in use
<Keybuk> but available
<Keybuk> so we tend to say that the unused memory is free + buffers + cached
<Keybuk> err, available memory
<Keybuk> 100% of the memory of the system should be in use at all times
<Keybuk> anything in free is wasted memory
<pwnguin> well, a bit less than 100 but a close value is optimal
<hwilde> Keybuk, thnx
<hwilde> found a decent articel  http://www.faqs.org/docs/linux_admin/buffer-cache.html
<pwnguin> hwilde: written by our very own liw
<hwilde> hehe
<geser> cjwatson: who grants exceptions for new merges after DIF? I guess for packages in main it's ubuntu-release and motu-release for packages in universe.
<cjwatson> sounds right
<LaserJock> serious?
<LaserJock> I don't believe we've done that in the past have we?
<norsetto> LaserJock: iirc, we did it after feature freeze in motu-release
<LaserJock> norsetto: right
<LaserJock> DIF and FF is quite a bit different though
<ScottK> So I can package and upload a new upstream version directly until FF, but I need some kind of approval to sync a new revision from Debian?
<ScottK> That seems rather putting the cart before the horse.
<james_w> pitti: thanks!
<geser> ScottK: only if you didn't merge it till DIF
<ScottK> What if there's a new revision?
<persia> For the hardy cycle, DIF exceptions were granted by MOTU and core-dev.  Do we really want to change that?
<ScottK> Right.  If an developer thought it was appropriate they did it.
<ScottK> It's not really clear how that's a freeze, but whatever.
<persia> And presumably, we each, as developers, respect the release goals and will ask any relevant people who may be affected.  For deep leaf universe, that's almost nobody.  For deep core platform, that's a lot of people, and probably some meetings.
<persia> ScottK: Freeze in the sense that it should only be done for a reason, rather than just because it's there.
<geser> cjwatson: does it also apply for new merges where the first new Debian upload after hardy happened after DIF? or only for "old" unprocessed merges?
<persia> The idea is to provide some stability so that we can work on integration and bugfixing.
<ScottK> Yes, but this is a matter of judgement for the developer.
<ScottK> I don't think we should ever be uploading stuff 'because it was there'.
<persia> Well, a developer within the development community, sure.
<persia> That's what we tend to do pre-DIF.  Lots of stuff comes from Debian that breaks things, and that's fine
<ScottK> But that's equally true for sponsorship requests.  Just because someone asks doesn't mean we have to upload it.
<persia> Absolutely, although we ought look and provide feedback as to why we won't upload it if we don't.
<ScottK> Once again, no different before/after DIF.
<persia> The difference is in focus.
<persia> Pre-DIF we ought try to get up-to-date with everything out there.  Post-DIF we ought integrate what we have and shape it into an integrated distribution.
<ScottK> Right, but I still don't see it as a freeze/exception process.  Just doing what we are supposed to be doing.
<persia> I prefer to call it a freeze for two reasons: 1) it's historically been called a freeze, and 2) it helps encourage people to think about it.
<persia> I especially don't like it when someone starts a library transition a couple weeks before feature-freeze: it's a bunch of NBS work when we are otherwise busy.
<ScottK> Freeze is fine, it's the 'needs an exception' bit that I think is overkill.
<persia> ScottK: I detailed the exception process for Hardy, and received Ack from the release manager (and yourself).  It's not onerous.
<geser> so we are allowed to request syncs from Debian after DIF but the merge needs an exception?
<ScottK> persia: I didn't much like it then either.
<persia> geser: sync is also an exception, but as ScottK points out, it's not hard to get one.
<slangasek> sbeattie: fixed hardy daily CDs are available again, with right-sizing
<ScottK> geser: And apparently since you're a developer you can self grant it.
<geser> persia: sync need also a exception from *-release after DIF?
<persia> geser: I'm not convinced exceptions ought be granted by *-release, but if *-release says so, I'm willing to try it.  I think it's a lot of work for them for not so much gain.
<ScottK> persia: I'm arguing against the entire concept that there is anything to except.
<geser> persia: the announcement says sync requests are ok, only new merges need an exception
<geser> but I still doesn't understand the rationale for this
 * persia hasn't liked any of the DIF announcement mails that have ever been sent.
<DktrKranz> so, what's the main difference? I'm a developer, I can upload since I can self-grant an exception myself? weird...
<geser> a sync can break as much as a new merge
<ScottK> geser: Yes.  You can upload a new package without and exception.  You can request and unmodified package be synced without an exception.  We just make it special if a package has been modified in Ubuntu and Debian did something with it.
<ScottK> It's complete nonsense.
<persia> More so, really, as a merge tends to involve more careful thought on the part of the developer.
<nixternal> actually, a sync can break more than a new merge, as I found out by someone taking smb4k and asking for a sync instead of a merge thinking the patches were there, and somehow it got through
<nixternal> and just recently someone cried about their /etc/sudoers getting messed up :)
<nixternal> muhahahaha
<persia> (for the fourth different time that the bug was raised)
<nixternal> 4th? probably getting close to 10th
<ScottK> I'd argue that syncing over an Ubuntu diff is much riskier than updating a merge.
<nixternal> I will email upstream and be like "wth dude, how many sudoers files you gonna screw before we pull your app"
<persia> nixternal: Really?  I thought the smb4k sudoers bug had only been fixed four times.
<nixternal> well someone messaged me in -motu yesterday about it
<nixternal> wgrant actually did
<persia> ScottK: I'd agree with you.  Personally, I think people ought think twice before making any non-bugfix upload after DIF.
<ScottK> So why special case one class of upload that is not particularly risky compared to others.
<seb128> persia: that's early to think that much before uploading
<persia> seb128: Is it?  Why then do we turn off the autoimporter?
<ScottK> persia: If you said DIF/FF I'd agree.
<DktrKranz> persia, most merges done after DIF will close bug, so I can see a need for some exception
<nixternal> are we getting ready to freeze? I haven't even had time to check the schedule
<ScottK> persia: So we have control over what happens, not because we're done with features.
<DktrKranz> *can't
<persia> ScottK: See, I'm not happy about our historical quality.  I think we ought fix more of our bugs.
<geser> nixternal: DIF is on 26 June
<seb128> persia: to avoid disruptive changes, ie pulling changes that require a transition for example
<persia> nixternal: DIF is about a week away.
<ScottK> persia: So propose FF = DIF for Intrepid + 1
<nixternal> argh
 * ScottK wonders where this DIF exception process is documented?
<nixternal> need to figure out what is left, ScottK have you heard anything? I thought I saw Riddell say the other day on the K* side we are good
<ScottK> Dunno.  I did python-kde3 last night.
<persia> seb128: Right.  So, if we're avoiding disruptive changes, why is it early to think twice about uploads?  I think that pre-DIF, it's not so important to worry about integration, but post-DIF, one should think more about how the upload affects other packages, not just the one being uploaded.
<nixternal> we need to find us a good little documenter to start reworking our wiki pages
<nixternal> they are a mess
 * nixternal knows the fingers are getting ready to be pointed at him
<seb128> persia: being conservative on random app changes between feature freeze slow down upstream fixes rather than bringing stability
<ajmitch> nixternal: correct
<nixternal> hrmm, that isn't a bad idea...I should put everything on Development/Policies/* and make it all nice and easy to read
<persia> seb128: That's not been my experience, but I tend to work in deep edge leaf territory, where upstream might have one release every 5 years.
<ScottK> nixternal: ryanakca is in charge of the web site.  Doesn't that mean he's going to fix it all.
<seb128> persia: right, but there is a difference between being careful and disruptive changes and being careful about any non-bug fix uploads
<nixternal> but moinmoin sucks for making things easy to read :)
<seb128> s/and/on
<nixternal> ryanakca: ya, get to fixing it all!
<persia> seb128: OK.  I'll grant that.  If you have a good upstream, it's a lot safer to pull new versions, etc.l
<calc> btw vmware 6.5 is cool :)
<ryanakca> nixternal: fix what about the website?
<norsetto> nixternal: congrats!
<nixternal> ScottK: lucky for us, the K side is a bit more relaxed...we are already packaging broken software, so if we break somthing, it is easy to just blaim upstream :P
<nixternal> norsetto: thanks!
<seb128> persia: ie for GNOME I don't bother about stability until feature freeze, granted that GNOME is a special upstream yes
<persia> seb128: For GNOME, I think that's a relatively conservative position.
<seb128> persia: but I'm happy to upload new version for random applications when there is a request from upstream or users until feature freeze without reading the diff in details
<seb128> quick look on the Changelog or NEWS is usually enough
<persia> seb128: I think that's dangerous.  Some of those may have knock-on effects that break 10s of packages in universe.
<seb128> well, I say rando applications
<seb128> not libs
<seb128> ie, I'm happy to update to a new gimp version
<seb128> or a new inkscape
<sbeattie> slangasek: thank you!
<persia> seb128: See, gimp would be one of those cases I'd be careful.  It has about 20 rdepends.
<slangasek> sbeattie: now to get the other flavors all built for testing...
<sbeattie> Heh, yeah. Good luck with that. :-)
<seb128> persia: well, we still have 4 months before intrepid, that's early to start wasting energy
<seb128> persia: I assume that the breakage cases will cost less energy to fix than checking every upload we do in the next weeks
<seb128> we don't have breakages that often
<seb128> but we upload a lot
<persia> seb128: I guess.  I consider it a waste of energy to have to investigate whether 31 packages FTBFS as a result of someone wanting nicer gradients in gimp, unless there is some particular goal involved in the gimp update.
<persia> (and, yes, gimp tends to be one of the better upstreams, and may not be a perfect example)
<seb128> right, but for one breakage case you will get 30 updates which bring something without any breakage
<persia> seb128: Sure.  For true leaf apps, I don't see a problem.
<seb128> that's a matter to know how you want to spend energy
<persia> I just think a developer should investigate, and try to avoid any transitions without a good reason.
<seb128> rather in a conservative way and slow down changes
<seb128> or rather go for changes trusting debian and upstream and fixing issues then
<seb128> we usually have time to stabilize after feature freeze anyway
<seb128> so I don't think there is a real need to be careful now
<seb128> I already tried to argue for not freezing universe syncs so early previous cycle
<persia> Well, except that every release since Breezy has crashed my computer once a day or so until the next dev release starts.  I'm not confident we do well with integration post-feature-freeze.
<seb128> because motus don't have the manpower to fix everything anyway there
<seb128> and the syncs usually bring rather good things than breakages
<persia> seb128: For universe, I think I'd be happier with a later DIF, but I don't see the point of ignoring DIF just because we haven't figured out how to do a delayed DIF for universe.
<seb128> and that would avoid the energy wasted to file hundred of sync requests every week and having archive admin processing those
<slangasek> persia: er, my plain English parsing of that doesn't make any sense at all to me; you're saying that the stable releases don't bceome stable for you until the next devel release is opened...?
<MacSlow> hm... what is the cause of LP refusing to copy the PPA-package of clutter 0.7~svn20080619-0ubuntu2 (from Intrepid) to the Hardy?
<EagleScreen>  i am learning to use pbuilder, what happens if i am running Debian lenny but i want to build a package for Hardy?
<persia> slangasek: Basically.  From about Final Freeze to about two weeks after archive open, I can expect my computer to crash hard every day.  This has been true since Dapper.
<MacSlow> it complains that "same version already has published binaries in the destination archive"
<slangasek> persia: wow.  what hardware is this?  maybe we should get one to use as a canary :)
<MacSlow> this worked without a problem for clutter-cairo - 0.7~svn20080619-0ubuntu1
<persia> slangasek: AMD 4400+/nVidia nForce4/nVidia 6800
<MacSlow> does LP not like the 0ubuntu2 there being requested to an earlier release?
<slangasek> MacSlow: well, if so, LP is right to not like it
<MacSlow> persia, is that the thing you mentioned earlier this afternoon?!
<slangasek> MacSlow: because copying binaries to a previous release isn't guaranteed to give you satisfied deps
<slangasek> I can't speak to whether this is what LP is /doing/, but it's a reason why you shouldn't do it even if it did work :)
<MacSlow> slangasek, but it did not complain for clutter-cairo... that what made me assume it would work for clutter too
<persia> MacSlow: Indeed it is.
<slangasek> maybe LP got smarter in between
<MacSlow> so better do Hardy -> Intrepid then I guess?!
<slangasek> yes
<MacSlow> *sigh* ok
<LaserJock> there are certainly examples where people at least need to look at dependencies they may be breaking before uploading, early in the release cycle
<MacSlow> thanks forlks
<persia> seb128: While I tend to file lots of sync requests, I agree it's a waste of time for the archive admin to process them, and anxiously await being able to sync to anything to which one can upload.
<seb128> right, orthogonal issue though
<seb128> it takes a lot of energy for you too
<EagleScreen> i think i must to use: sudo pbuilder update --distribution DIST-NAME --override-config
<LaserJock> I've had libraries synced from Debian experimental to satisfy deps on Main apps without talking with or asking other people about the other deps
<LaserJock> it's not great to do
<EagleScreen> but in addiction must i change repositories to hardy?
<persia> Sure, but I only sync maybe 1 in 5 updates, as most don't offer sufficient improvement to be worth possible disruption.
<ScottK> EagleScreen: #ubuntu-motu is a better channel for such questions.
<EagleScreen> thanks Scottk
<mardi_soir> hello
<mardi_soir> i think i have a bug
<mardi_soir> i know one issue
<persia> mardi_soir: You'll want to file it in LP.  If you have coordination questions, #ubuntu-bugs is probably the right channel for discussion.\
<mardi_soir> sorry
<cjwatson> LaserJock: I copied the message from Steve's hardy DIF message, so I don't believe I was introducing anything new
<persia> cjwatson: You weren't.  Steve received complaints about his hardy DIF message.  I think the issue is that we've not well defined what the "Freeze" part of DIF means, or put any appropriate exception process on the wiki.
<cjwatson> I don't feel especially strongly about what the exception process is, but I do think it's important to have some meaningful encouragement that merges do actually need to happen by that point, otherwise they'll just slip and slip
<cjwatson> and I think developers *should* think hard about merging something late in the cycle
<cjwatson> complicated merges can easily interfere with feature development
<cjwatson> I certainly don't think we should erect huge piles of red tape
<cjwatson> it's too early for that
<persia> cjwatson: Unfortunately, we seem to have lost the forum to take that decision.
<persia> There used to be a development-team meeting, but I haven't seen one in several months (just team meetings).
<persia> A lot gets determined at MOTU Meetings, but there's a sense that these decisions don't affect core-dev, which leads to strife and confusion.
<cjwatson> they became impractical
<cjwatson> forum> TB
<cjwatson> surely?
<persia> I guess.  I don't like to bother the TB unless we, as developers, can't reach consensus.
<cjwatson> I'm afraid I had forgotten that it was contentious, anyway; I was just conscious that DIF was approaching and something needed to be announced
<persia> cjwatson: Unless you prefer, I'll email TB about the confusion (now over two cycles), and ask to use a TB meeting as a forum to determine the appropriate policy to apply for DIF for general publication.
<cjwatson> that seems very appropriate - whatever gets decided should be documented on the corresponding wiki page
<MacSlow> trying to upload a source-package with dput I get a "connection refused" error atm
<persia> And it's good you announced it :)  I don't think you ought feel any guilt over the mail, despite my disagreement with the content.
<cjwatson> since I went and looked there first (https://help.ubuntu.com/community/Debian/ImportFreeze) and it didn't really speak to this at all
<cjwatson> MacSlow: Soyuz is down for some hours for an upgrade
<MacSlow> it worked just a few minutes ago... and idea what to l...
<persia> cjwatson: OK.  Do you want to take it, as one of the people coordinating release (and the author of the mail), or shall I take it as an objector?
<MacSlow> cjwatson, ah... ok thx
* cjwatson changed the topic of #ubuntu-devel to: Soyuz will be going down from 22:00 UTC to 00:00 UTC | 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
<cjwatson> (since mthaddon hasn't ...)
<mthaddon> cjwatson, thx
<cjwatson> persia: please go ahead, (a) it's 2300+, (b) I'm not sure I understand the objections coherently (I realise there are some but haven't really absorbed them)
<persia> cjwatson: OK (although it's 31:21 here).
<cjwatson> mthaddon: is that timeline still accurate given the publisher delay on drescher?
<cjwatson> persia: I like your notation
<mthaddon> elmo, ^ downtime still looking accurate?
<MacSlow> until tomorrow then
 * cjwatson is massively looking forward to ditching the backported germinate I had been maintaining for drescher
<elmo> cjwatson/mthaddon: yes
<seb128> slangasek: alright, I uploaded gvfs, glib and evolution updates that would be nice to have for 8.04.1
<seb128> slangasek: the gvfs update is the patch we spoke about, glib fixes nautilus changing timestamps on copy which some users really complained about and evolution fix meeting invitation not being displayed correctly which is an hardy-updates, had been fixed and the patch has been dropped by mistake during a version update so it would be nice to have it again now ;-)
<ScottK> persia: Perhaps we should collaborate since I think I object too, but in the opposite direction so we can have a coherent presentation of the concerns.
* cjwatson changed the topic of #ubuntu-devel to: Soyuz will be going down from 22:00 UTC to 03:00 UTC | 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
<cjwatson> my bad
<jdub> anyone working on the kernel freeze (possibly related to wireless) issue with hardy? i have a useful petri dish of varying hardware presenting the symptom.
<calc> either novell has a lot more bandwidth than we do for release day or not many people are downloading opensuse 11.0
<persia> ScottK: Sure.  I'm still researching historical announcements and referents, and haven't yet determined how to add to the TB agenda.  I believe it's likely to be a wiki page for presentations of thought that is linked from an Agenda item.  I was planning to send a mail to all known interested parties (having participated in the recent discussion or in the ML threads for any of the freeze announcements) pointing at the wiki page.  Does that wor
<persia> k for you, or do you want something closer?
<ScottK> That's fine as long as we have consensus around the wiki page before we ask the TB.
 * ScottK heads out.
<persia> ScottK: I don't think we can achieve consensus on the wiki page, but I do believe we can present a balanced set of opinions for TB review prior to the meeting.
<persia> I think the next meeting is in about two weeks, which ought be enough time for interested parties to add to the page.
<ScottK> persia: Consensus about what the argument is about.  Not about what the solution is.
<persia> I'm not even sure we can all agree on that, beside the central problem that the impact of DIF on developers is ill-defined.
<ScottK> persia: I'm after 2nd order agreement.  See http://pastebin.kubuntu-de.org/269 but I'd settle for 3rd.
 * ScottK really heads out.
<persia> ScottK: Sounds reasonable (and thanks for the reference).  I think we can reach about 2.5, but I don't want to wait too long, as I'd rather see this resolved so it doesn't happen again (especially as we'll already be in freeze by the next TB meeting)
<mathiaz> james_w: I'm playing with bzr branches from mysql on LP
<mathiaz> james_w: I'm looking into importing all the patches we have in debian/patches/
<mathiaz> james_w: do you have a tool that helps doing this ?
<mathiaz> james_w: or suggestions on how to do this properly ?
<james_w> mathiaz: hi. I don't have anything specifically for that, but it shouldn't be too hard to cook up.
<james_w> as a start you could just iterate them and use "bzr patch", provided by bzrtools, to apply them and then commit.
<mathiaz> james_w: hm - do you think it's worth creating one branch for each patch ?
<mathiaz> james_w: I'd like to see how we can submit patches to upstream
<james_w> mathiaz: that's more about how you want to work I think
<james_w> mathiaz: one thing that might interest you is "bzr-loom"
<james_w> it's designed exactly to help manage a stack of patches on upstream.
<mathiaz> james_w: right - well - I don't really know for now :) that's the whole point of this exerciese
<james_w> of course :-)
<mathiaz> james_w: currently I'm branching lp:mysql-server/5.0
<mathiaz> james_w: and then I have all the patches applied in debian/
<mathiaz> james_w: so I could apply one patch, commit etc, and finish by adding the debian/ directory.
<mathiaz> james_w: how would this work if I want to submit my patches to upstream ?
<james_w> yep that would work, but it loses the separation as you move forward
<james_w> and yes, it makes it difficult to extract them to send upstream.
<mathiaz> james_w: right - so I though about another workflow, which is to create one branch for each patch
<james_w> bzr-loom allows you to keep them separate
<mathiaz> james_w: and then merge all of them in one ubuntu branch
<mathiaz> james_w: ok - and with bzr-loom I can submit only one branch to upstream ?
<james_w> that's kind of what bzr-loom does, you get a branch for each patch, but they are ordered like the patches in debian/patches/
<james_w> you can get a diff of one patch with "bzr diff -r thread:" I believe.
<mathiaz> james_w: right - but I'm still dealing with diff then
<james_w> ah, or course, sorry.
<mathiaz> james_w: I'd like to be able to use the submit for merging feature in lp
<james_w> it's easy if you want to submit the patches from bottom to top. If you want to reorder them it is more difficult.
<james_w> lifeless: hi, mathiaz is looking at mysql packaging and the handling on debian/patches/ after today's announcement.
<lifeless> hi
<lifeless> I'm looking at a FootLong bacon and egg with extra egg in about 2 minutes
<lifeless> if you can wait I'd be happy to chat after that :)
<mathiaz> lifeless: wfm
<james_w> lifeless: I'm explaining loom, but as I haven't used it much I'm not how easy/feasible it is to extract a branch from the middle of the loom to propose for merging to trunk.
<james_w> lifeless: sure.
<lifeless> james_w: send -r thread:lower..thread:higher
<mathiaz> lifeless: ok - but that creates a diff IIUC
<mathiaz> lifeless: I'd like to use lp to propose for merging to mysql team
<lifeless> mathiaz: no it creates a cherrypick merge request with all needed history
<lifeless> mathiaz: #launchpad please, this is about lp not bzr then
<lifeless> -> food back soon
#ubuntu-devel 2008-06-20
<ion_> I wonder why dictd was merged instead of synced. The changelog entry only says âMerge with Debian; remaining changes:â.
<persia> ion_: Does the debdiff say anything?  Sometimes people grab from MoM and aren't careful with changelogs.
<ion_> persia: I didnât take a better look, just happened to take a look at the changelog.
<jcole> is there a reason why the dhcp3-client dpkg post install scripts dont finish? see here:
<jcole> # ls /etc/dhcp3/dhclient.conf*
<jcole> /etc/dhcp3/dhclient.conf
<jcole> /etc/dhcp3/dhclient.conf.dpkg-dist
<jcole> for every fresh install of hardy, i do "mv ï»¿/etc/dhcp3/dhclient.conf.dpkg-dist ï»¿/etc/dhcp3/dhclient.conf"
<jcole> im using the alternate cd
<jcole> btw
<sjoerd>   
<lifeless> back
<lifeless> mathiaz: so, can you join #launchpad ?
* mthaddon changed the topic of #ubuntu-devel to: 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
<jelmer> is there a bugtracker for ubuntu-dev-tools ? launchpad says it's not the bug tracker
<persia> jelmer: https;//launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bugs
<persia> (LP is sometimes a little confused about native packages)
<jelmer> persia: ahh, ok. Thanks
<emgent> some debian devel up here?
<slangasek> yes, though there are more reliable places to look for them... :)
<emgent> hehe :)
<emgent> slangasek: possible query? :)
<slangasek> ok
<kirkland> slangasek: hiya, still around?
<dholbach> good morning
<ion_> Hi
<dholbach> hey thekorn, hi ion_
<trivial> hello
<trivial> I have a problem "request to switch into FULLSCREEN mode failed: too dumb terminal 'xterm' (no cursor move capabilitie)
<trivial> " in both Konsole and xterm how can I fix this?
<pitti> Good morning
<ion_> Hi
<pitti> ScottK: merge approvals are mostly a kind of educational measure to encourage people to get them done in time, AFAIUI
<ScottK> Agreed.
<ScottK> I just don't want to turn this into another bureacracy.
<ScottK> Good morning.
<trivial> I have a problem "request to switch into FULLSCREEN mode failed: too dumb terminal 'xterm' (no cursor move capabilitie)
<trivial> " in both Konsole and xterm how can I fix this?
<ion_> Does it echo in here?
<trivial> nobody knows?
<trivial> hello.........hello............oooooooooo...... hello????????
<trivial> lol
<ion_> Please read the topic.
<trivial> ok you guys develop ubuntu?
<trivial> or is it developing applications to run on ubuntu?
<pwnguin> develop ubuntu
<thekorn> hello dholbach
<trivial> sorry wrong link
<ScottK> slangasek: RE Bug 207473 - The user complaining the fix didn't help is using Gnome.  Since it's a KDE fix, I think it's not suprising.
<ubottu> Launchpad bug 207473 in kde-guidance "Screen brightness double level changes" [Medium,Confirmed] https://launchpad.net/bugs/207473
<slangasek> ScottK: oh, heh
<slangasek> so /all/ these people are following up to the wrong bug? :/
<slangasek> "Adam" doesn't mention GNOME or not
<ScottK> Since it's a two part hal/guidance bug it wouldn't suprise me if there was a gnome impact.
<ScottK> But it's the guidance bit that we have a fix for.
<slangasek> right
<slangasek> and have the affected users verified that the fix works?
<ScottK> It should probably also affect some Gnome thing, but I've no idea on that.
<slangasek> probably gnome-power-manager as a starting point, sure
<ScottK> Sounds reasonable if it does brightness for Gnome.
<ScottK> slangasek: It's not clear to me that there is a verification from someone who reported the exact original problem.  It's also pretty clear that none of them are active in the bug either.
<slangasek> mm, ok
<ScottK> I can verify no regressions and it fixed some problems I was having that I hadn't actually reduced to a bug because I didn't understand it well enough yet.
 * slangasek nods
<ScottK> My recommendation would be put it in hardy-updates.  The problem isn't totally solved until Hal is fixed in any case and I'm confident this is better.
<slangasek> ScottK: no verification on bugs 231163 or 82279 yet, either?
<ubottu> Launchpad bug 231163 in kde-guidance "kde-guidance-powermanager: python2.5 crashed with AttributeError in checkBatteryCritical()" [Undecided,Fix released] https://launchpad.net/bugs/231163
<slangasek> oh, 82279 has been verified, n/m
<slangasek> silly non-auto-refreshing reports
<ScottK> slangasek: I'll make you a deal: if there's a regression found, I promise to take care of it if you go ahead and publish.
<slangasek> ScottK: oh, well, I don't think we should be covered for regression-testing now that it's been in for 15 days, but whether I can close the bugs with confidence when copying it over is another question :)
<slangasek> but yes, let's go ahead
<slangasek> ivoks: hi, I had a question for you
<ivoks> slangasek: sure
<slangasek> ivoks: https://wiki.ubuntu.com/DistributionDefaultsAndBranding says that for Croatian, "Debianova, Debianove, Debianovu" are ok to replace in translations with just "Ubuntu" - is that right?
<slangasek> it seems suspect to me that you would replace an adjective with a noun like that :)
<ivoks> slangasek: eh, depends on circumstances... i'll take a look at it
<slangasek> basically, this is the guide that gets used to mangle the debian-installer translations when doing merges
<ivoks> in most cases you can just apply same rules
<ivoks> but with Ubuntu is very hard, cause it ends with a vowel...
<slangasek> so there wouldn't be an "Ubuntove" adjective form?
<ivoks> so, Ubuntu's would be Ubuntuov, which soulds strange; 'In Ubuntu' is U Ubuntuu - very strange :D
<slangasek> heh
<soren> I like it!
<soren> :)
<slangasek> just cheat and claim that Ubuntu is the accusative form of "Ubunta"
<slangasek> >:)
<ivoks> slangasek: Ubuntuove sounds right
<slangasek> ok
<ivoks> like Ubuntu's web pages; Ubuntuove web stranice; that's for plural
<slangasek> ah, so there's also precedent, excellent
<ivoks> but Ubuntu's page; Ubuntu stranica
<slangasek> yes, of course
<ivoks> slangasek: i'll have to check each phrase...
<ivoks> or someone from ubuntu-hr
<slangasek> ivoks: well, it should never be /incorrect/ to do s/Debianov/Ubuntuov/, should it?
<ivoks> it should be correct, right
<LucidFox> seb128> I'm preparing to upload a new debdiff for the f-spot merge
<seb128> LucidFox: ah good, I was starting to wonder about this one ;-)
<LucidFox> I've dropped the debian/copyright change, FSF address probably isn't big enough of an issue to diverge from Debian
<LucidFox> and added the new patch from hardy-updates
<seb128> cool
<seb128> you can do the new version update too if you want ;-)
<LucidFox> to 0.4.4?
<slangasek> ivoks: fwiw, here's an example of what we have currently:
<slangasek> -msgstr "Provjeravam Debianovu zrcalnu arhivu"
<slangasek> +msgstr "Provjeravam Ubuntu zrcalnu arhivu"
<slangasek> so. :)
<LucidFox> I'd wait for Debian to update first, diocles has said he's going to upload it this weekend
<seb128> LucidFox: yes
<seb128> alright
<seb128> hey slangasek, thanks for accepting the sru uploads ;-)
<slangasek> seb128: yep - thanks for uploading... :)
<seb128> things look good from my side for 8.04.1
<slangasek> excellent!
<slangasek> because I don't want to have to approve any more uploads >:)
<seb128> right, those were already late
<pitti> hi seb128; you pung last night, so that's settled now?
<seb128> the only remaining problem now is pulseaudio and the alsa update, right?
<pitti> yeah :/
<seb128> pitti: did I?
<LucidFox> Uploaded to bug #226117
<ubottu> Launchpad bug 226117 in f-spot "Please merge f-spot 0.4.3.1-1 from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/226117
<seb128> pitti: anyway that was probably for the sru uploads slangasek accepted so everything is fine now
<seb128> LucidFox: looking
<pitti> seb128: right
 * seb128 hugs pitti
 * pitti hugs seb back
<ivoks> slangasek: that's ok :) (sorry, i was on the phone)
<ivoks> slangasek: both 'Provjeravam Ubuntu zrcalnu arhivu' and 'Provjeravam Ubuntuovu zrcalnu arhivu' are ok, but the first one sounds better and is easier to pronounce
<slangasek> ivoks: ok.  well, if you can review my changes in http://bazaar.launchpad.net/%7Eubuntu-core-dev/choose-mirror/ubuntu/ rev. 599, that'd be awesome; c.f. revision 486.1.526 which shows the branding changes vs. Debian's
<ivoks> slangasek: i will
<slangasek> and if you tell me to, I'll revert the changes, or whatever :)
<ivoks> slangasek: ok :)
<slangasek> but it's ideal if we have something that can be applied mechanically, since usually that's how these branding changes have to be done
<slangasek> (it's interesting that you say "Ubuntu zrcalnu arhivu" sounds better; in Czech this construction sounds very strange to me)
<ivoks> slangasek: in 'Ubuntu zrcalna arhiva', everything is object, and in 'Ubuntuova zrcalna arhiva' 'zrcalna arhiva' is object
<ivoks> slangasek: meh... just drop 599 revision; it really sounds bad :D
<slangasek> ok... :0
<ivoks> sorry
<slangasek> :)
<ivoks> slangasek: thanks for keeping an eye on it
<slangasek> n/p
 * slangasek still thinks Croatian's choices here are weird ;)
<ivoks> i'll take the blame if someone complains, i translated it like that in the first place in d-i
<slangasek> actually, I think what really bothers me is that it's "Ubuntu zrcalnu arhivu" instead of "zrcalnu arhivu Ubuntu"
<slangasek> but that's not a mechanical change :/
<slangasek> and may not even be the correct word order in Croatian, for all I know ;)
<ivoks> ubuntuove sounds very czech and it's kind of normal there.. like krusovice
<slangasek> heh :)
<ivoks> slangasek: you have a point there
<ivoks> zrcalna arhiva Ubuntua sounds very good
<ivoks> hm... i'll crate a diff and send it to you, if needed
<ivoks> ok?
<slangasek> well, then we still have the difficulty of whether we can continue to maintain it?
<ivoks> right...
<slangasek> since it's then not a mechanical translation - one needs to understand the grammar enough to get the word order right
<slangasek> so if the current is acceptable, we should probably just leave it alone
<ivoks> sometimes i whish we all speek same language...
<ivoks> current is ok
<pitti> kirkland: I reviewed your program, long answer in your mbox
<MacSlow> question about PPAs: although I deleted packages from my PPA, trying to upload revised versions for another distro-series results in LP rejecting it, stating that "the source is already accepted in ubuntu/intrepid..."
<MacSlow> What more than delete packages can I do?
<MacSlow> Does LP still cache some info about previously uploaded (but now deleted) packages?
<wgrant> MacSlow: You really don't want to do that.
<wgrant> We bump versions for a reason.
<wgrant> What are you trying to upload, though?
<MacSlow> wgrant, my own version of upstream clutter & friends
<wgrant> If anybody else ever uses your packages, they'll get confused to death if a version is in fact not the same as that same version.
<MacSlow> well then
<wgrant> Bumping to -0ubuntu3 won't kill anything, I'm sure.
<MacSlow> ok... I admit I just wanted a fresh start for "cosmetic" reasons :)
<ion_> wgrant: Assuming Ubuntu has e.g. -0ubuntu1, better use something thatâs -0ubuntu1 < x < -0ubuntu2, for instance -0ubuntu1.1
<wgrant> Ubuntu doesn't have -0ubuntu1, but you're right in that different versioning should be used.
<wgrant> Security versioning is not the solution, however.
<wgrant> People will often append a +username1 or +ppa1
<ion_> I mean, for a < b < c, where a is the current Ubuntu version, c is what the next Ubuntu version for the same upstream release will be and you pick b.
<wgrant> Right.
<pitti> pycentral pkginstall: not overwriting local files
<pitti> dpkg: error processing python-launchpad-bugs (--configure):
<pitti> argh
<pitti> doko: ^ any idea about why that happens? breaks hardy dist-upgrade
<pitti> oh, ENODOK
<pitti> seb128: ^ that broke the retracers; fixing (FYI)
<seb128> urg, thanks
<seb128> that's not the first time that happens
<MacSlow> oh why... LP now complains it's missing the *.orig.tar.gz although it's in the same directory from where I issued the dput command
<dholbach> debuild -S -sa   vs.   debuild -S ?
<MacSlow> but it was obviously not uploaded with the dput command... I'm not doing anything other then...
<MacSlow> dholbach, I did dpkg-buildpackage -S
<dholbach> right
<MacSlow> that's not good anymore?
<ion_> mcaslow: Try removing ...orig.tar.gz.uploaded or whatever it was.
<dholbach> -sa will add the .orig.tar.gz to the .changes file
<MacSlow> dholbach, it only uploads the orig.tar.gz with 0ubunt1 ?!
<dholbach> it doesn't care about the version number
<ion_> Oh, and yeah, -sa.
<dholbach> if you (and nobody else) has ever uploaded the new .orig.tar.gz, use -sa
<dholbach> if it has already been uploaded, don't use -sa and save bandwidth and time
<MacSlow> ion_, btw I never saw such a *.orig.tar.gz.uploaded before
<dholbach> just remove the .upload file, regenerate the source package with -S -sa and try again
<MacSlow> dholbach, -sa ?= "source attach"
<MacSlow> ok
<dholbach> no idea what it stands for
<dholbach> thanks mvo for sponsoring! thanks seb128 too!
<seb128> ;-)
<mvo> cheers
<seb128> dholbach: do you consider https://bugs.edge.launchpad.net/ubuntu/+source/courier-authlib/+bug/239643 as a correct bug? I don't know what universe standards are, but is there any need to use revu when a debdiff could be attached?
<ubottu> Launchpad bug 239643 in courier-authlib "Please merge courier-authlib 0.60.1 (universe) from Debian unstable (0.60.1-2)" [Undecided,Confirmed]
<dholbach> seb128: no, it's absolutely not required to upload to REVU
<seb128> and the description is not good either
<dholbach> right
<wgrant> Is the top (menu bar, tabs) of my gnome-terminal in Intrepid meant to be translucent, while other apps aren't?
<seb128> is that really a question? ;-)
<seb128> I don't see a reason why one application should behave differently no
<seb128> seems to be a bug rather
<ion_> In MacOSX, such inconsistencies seem to be the norm. :-)
<wgrant> I thought maybe the new theme supported transparency, and some apps would initialise a window with an alpha channel, and those that didn't were the bug...
<seb128> ok, if that's the case I don't know about it
<seb128> maybe MacSlow knows about that
<ion_> Huh, translucent Gtk background by default? Now *that* would be a bug.
<MacSlow> ion_, no... it's slick :)
<ion_> If by slick you mean less readable. :-)
<wgrant> ion_: With blurring it probably won't be too bad.
<MacSlow> ion_, it really depends on the opacity and if you happen to have compiz' blur enabled
<wgrant> Haha.
<MacSlow> ion_, got a screenshot for me to take a look?
<MacSlow> wgrant, I meant
<MacSlow> sorry
<wgrant> MacSlow: Sure, in a sec.
<MacSlow> day two of my clutter-PPA efforts and still not done *sigh*
<MacSlow> no please don't tell me it failed because of the german-umlaut in my name
<MacSlow> if anybody cares to take a look -> http://launchpadlibrarian.net/15472094/6c17UkRT6WzAJ8VPK8kCtoyGGfq.txt
<wgrant> MacSlow: What's the error?
<wgrant> Ah.
 * wgrant tries.
<wgrant> My i915 really didn't like turning blur on.
<pitti> MacSlow: heh; but it shouldn't matter in the Mainainer: field or anywhere, hmm
<MacSlow> it built for hardy... then I copied it to intrepid and there it failed?
<pitti> MacSlow: sounds like a cprov problem
<seb128> cprov: ^
<wgrant> MacSlow: It rejected it, and then failed to generate the rejected message because of your name, I suspect.
<MacSlow> wgrant, oh... don't bother with blur if you don't have a GeForce-card
<wgrant> But it didn't reject it because of your name.
<wgrant> Although, that's a strange character...
<MacSlow> pitti, wgrant: but I don't get why for hardy it built and only failed on intrepid
<wgrant> MacSlow: Did you upload the same version?
<cprov> MacSlow: did you copy only the source ?
<MacSlow> wgrant, no... I uploaded it for hardy and after that finished I used the LP/PPA-UI to copy it to another distro-seriies
<MacSlow> cprov, yes
<wgrant> Aha, 0xFC is Ã¼ in latin-1?
<MacSlow> cprov, I remember that this is saver to have it actually rebuilt
<MacSlow> wgrant, yes... MÃ¼ller is my surname
<wgrant> Shouldn't everything be UTF-8 these days?
<cprov> MacSlow: you can't rebuild the same source within the same PPA (archive pools).
<MacSlow> wgrant, well I didn't touch/change anything on my system
<ion_> wgrant: Definitely yes.
<wgrant> cprov: Edge should prevent that nowadays, shouldn't it?
<cprov> MacSlow: +copy-packages form should not allow it.
<wgrant> Except for that remaining race.
<cprov> wgrant: no, edge is frozen  :(
<MacSlow> cprov, ehm... but didn't yesterday somebody tell me that this would be ok (moving from distro-series -> distro-series+1 and keep the version number)?
<wgrant> cprov: But is it in 1.2.6?
<cprov> MacSlow: when you include binaries in the copy, it's fine
<cprov> wgrant: yes, the bug is in PQM
<MacSlow> cprov, hm.
<cprov> the bug fix ...
<MacSlow> f**k!
<MacSlow> now I deleted the failed versions, and copied (with binaries) from hardy to intrepid... and that failed right away
<ogra> pitti, to many kits eh ? (you thanked james for his help on policykit in your last sentence of teh packagekit mail  :) )
<MacSlow> how long does it take for a deletion of a package to actually happen?
<wgrant> MacSlow: Now that I've got Compiz to go less slothfully - http://qeuni.net/f/1/2008/noblur.png
<wgrant> ogra: Can we please rename Nautilus to DirectoryKit?
<ogra> yay
<MacSlow> wgrant, looks like you're using some murrine-based GTK+-theme-engine
<ogra> and kernel to hardwarekit :)
<wgrant> MacSlow: It's the default in Intrepid.
<pitti> ogra: oh, indeed; PK != PK any more :)
<MacSlow> wgrant, that's intrepid?
<wgrant> It is.
<MacSlow> wgrant, hm... now I'm surprised
<ogra> pitti, i'm always confusing all these kits .... they really should stop *now* with inventing new ones
<wgrant> GTK+ -> WidgetKit, GDM -> LoginKit. The possibilities are endless and horribly confusing.
<ogra> yeah
<ogra> but fedora has fun confusing the world at least :)
<ion_> GTK+ â Gimp ToolKit ;-)
<wgrant> ion_: True.
<ion_> Or perhaps GraphicsKit ToolKit :-P
<afflux> Pidgin -> ConversationKit, uh yeah :P
<ion_> Hehe
<wgrant> MacSlow: The panel customisations are mine, but the rest of the theme is stock.
<MacSlow> wgrant, the opacity in murrine is a hardcoded-value (at least it was when I last looked at its source)
<ogra> wgrant, working on BlingKit with MacSlow ?
<MacSlow> wgrant, it should be a settable theme-property-value in the optimal case... so people can have it a bit translucent if they can run with compiz' blur... in that case it's really nice
<pitti> slangasek: ah, apparently Debian now has a 'db-defaults' metapackage for libdb-dev
<MacSlow> although I deleted packages from my PPA (about 15 minutes ago) they still show up in the "Delete packages from PPA"-page... why's that?
<wgrant> MacSlow: Indeed, it looked very good when I had blur on, but it regrettable ran at less than 0.1fps.
<wgrant> MacSlow: Try now.
<wgrant> s/regrettable/regrettably/
<MacSlow> wgrant, the i915 has no hw-accelerated offscreen rendering (FBOs) needed for fast blur
<wgrant> wgrant: Publisher only runs every 20 minutes, so trying a couple of minutes after the hour might have made a difference, but cprov would know.
<wgrant> MacSlow: Aha.
<wgrant> Um. I keep referring to myself for some reason.
<MacSlow> wgrant, I think in the case of the i915 it uses the slowest possible option in GL... the only available on the i915
<wgrant> MacSlow: Do any newer Intel chips do it well?
<cprov> MacSlow: the package will continue to be listed in +delete-package until it is entirely removed from the archive. I usually takes 2 death-row cycles (30 min)
<MacSlow> wgrant, on the i965 I saw FBOs finally being exposed by the driver when I did a fresh git-checkout of Xorg, driver & Co at UDS-Prague... even GLSL-examples ran on it... that's a sweet outlook for Intrepid :)
<MacSlow> cprov, ah ok
<ion_> Wow, a free driver with GLSL and FBO support? I gotta get one of those cards.
<wgrant> MacSlow: Nice, nice.
<wgrant> GLSL == GL shader language?
<ion_> (Are there cards anyway, or are they only available as integrated chips?)
<MacSlow> ion_, cool eh?!
<wgrant> (fairly random guess)
<MacSlow> wgrant, correct
<wgrant> ion_: I heard they were coming up with cards eventually.
<MacSlow> wgrant, well all chips supported by free drivers should get GLSL-support
<wgrant> But not yet that I know of.
<wgrant> Unfortunately.
<MacSlow> wgrant, but I only have a GeForce and a i965 myself so I cannot tell anything about e.g. ATI-chips
<MacSlow> wgrant, I would not be surprised if the nouveau (the free nvidia-driver) will offer all that too at some point
<MacSlow> cprov, so for having a package available for <distro-series> and <distro-series+1> I _absolutely_have_ to bump the version?!
<wgrant> MacSlow: Nouveau seems like it should be rather good - I wonder how radeonhd will turn out.
<wgrant> MacSlow: One would normally upload for distro-series, and then copy it (with binaries) to distro-series+1.
<wgrant> Like we do when we create a new release.
<wgrant> All the binaries are copied from the previous one.
<MacSlow> wgrant, regarding ATI/Radeon I put all my bets on Dave Airlie (!= RadeonHD)
<MacSlow> just for the record...
 * MacSlow is the bloodiest packageing noob on the planet
<wgrant> MacSlow: WRT the Murrine translucency... does it only work on RGBA windows?
<cprov> MacSlow: what willian said, binaries normally can be safely carried from series-(n-1) to series-(n)
<MacSlow> wgrant, well of course and it needs a working/running compositor
<wgrant> MacSlow: So that would explain why most of my windows are opaque. That's what I was initially wondering, thanks.
<MacSlow> wgrant, I forgot which widgets murrine draws with some transparency by default
<MacSlow> wgrant, it certainly does not create every widget with a RGBA-colormap by default... that would cause some breakage... especially for the tray-icons (notification area)
<ogra> seb128, i was told gdm wil drop support for ~/.dmrc, do you know anything about that ? (we just planned ~/.dmrc support in ldm but i dont want manpower being wasted if upstream switches to different ways of setting default lang and session)
<seb128> ogra: the new gdm uses gconf
<ogra> hmm
<cody-somerville> ughh :(
<wgrant> seb128: ConfigKit!
<ogra> how does that work with KDM, xdm and others then for default session and language ? they require ~/.dmrc .... or does KDM switch to gconf now ? :)
<seb128> ogra: that's like asking how evolution read kmail accounts settings ...
<ogra> there should be a freedesktop.org standard for that imho ...
<ogra> no, its different
<seb128> not really
<ogra> you might wat to run a desktop that requires that file
<ogra> from gdm
<seb128> what file?
<ogra> or you might want to switch over and expect no regression :)
<ogra> ~/.dmrc
<seb128> you might want to use your thunderbird accounts in evolution too
<ogra> it carries a users default language and session
<ogra> as a quasi standard since DMs exist
<seb128> don't switch software if you don't want to reconfigure?
<ogra> well, why should i switch my default session language
<seb128> I don't get the question
<seb128> why would an user switch login managers?
<ogra> ok, question made easier: why does gdm break common standards ?
<ogra> i mean the way to set lang and session is long established
<ogra> i dont get why they need to break it and get incompatible with all other DMs
<seb128> it doesn't in fact
<seb128> I was just looking at the code
<seb128> .dmrc is still used
<ogra> phew, ok
<ogra> warren told e differently
<ogra> *me
<ogra> he said mccann would remove it or had already
<seb128> "	* daemon/gdm-session-worker.c: (_save_user_settings),
<seb128> 	(gdm_session_worker_start_user_session):
<seb128> 	Save out user settings to ~/.dmrc before starting the
<seb128> 	session"
<ogra> good
<seb128> ogra: I don't know what they will do
<seb128> I just know what the current code is doing
<seb128> but I'm not sure they consider .dmrc as a standard
<ogra> ok, i thought you had any insight in the "why do they want to drop traditional setups" :)
<seb128> and that they consider switching dynamically login managers as something that needs to be supported
<ogra> thats why i said "quasi" standard :)
<seb128> honestly who is wanting to switch between login managers?
<ogra> i'm sure its not written down anywhere as "the standard"
<ogra> me
<ogra> and all my ltsp users do that regulary
<seb128> why?
<seb128> why should an user care about that?
<ogra> depending if you sit on the server directly or on a client you use either ldm or gdm
<seb128> that's like saying that grub should use lilo.conf because some users want to switch the boot manager
<ogra> and i want them both to have the same settings indeed
<ogra> which is what ~/.dmrc was made for
<ogra> so DMs can share session and language info
<seb128> well, as said the code to support .dmrc is still there
<seb128> so let's see what they do
<ogra> yeah
<seb128> but if mccann said he wants to remove it that's probably true
<ogra> well, warren said
<ogra> i tend to trust him less and less since i met the people in person he usually proxies to me :)
<ogra> (i.e.l lennart or davidz)
<seb128> I don't know him so I can't say
<ogra> (thas why i picked your brain to gather some more info :) )
<seb128> but from the changelog they added code to write and read the .dmrc during this cycle
<ogra> good
<seb128> so they probably agree with you that's an useful thing
<seb128> and I somewhat doubt they will drop that now
<ogra> it definately is
<seb128> I would not worry to much for now
<ogra> thanks :)
<wgrant> 5~/win 4
<wgrant> Gah.
<asac> siretart: is wpa roam feature debian only?
<norsetto> asac: any idea why debian bug 415381 hasn'changed ownership? I also tried sending an email to control without results.
<ubottu> Debian bug 415381 in gnome-mplayer "ITP: gnome-mplayer - a simple GUI for MPlayer" [Wishlist,Open] http://bugs.debian.org/415381
<asac> norsetto: yeah :)
<asac> norsetto: because i forgot the bugnumber ;)
<asac> norsetto: you can just send owner 415381 !
<asac> if you send from the email you want to use
<norsetto> asac: ah ok. I sent it with bugnumber but haven't got any results either :-/
<asac> norsetto: debian had some outages recently. try to send again
<norsetto> asac: ok, will try again, viel danke
<asac> welcome
<siretart> asac: no, it is available in ubuntu since ages as well
<siretart> bug #44194 makes it quite annoying to use in ubuntu, however. I still didn't understand where the race actually is here
<ubottu> Launchpad bug 44194 in wpasupplicant "wpasupplicant doesn't start when the network start" [Medium,Confirmed] https://launchpad.net/bugs/44194
<zul> morning
<asac> siretart: err, i meant debian/ubuntu only ... as "not in upstream"
<MacSlow> hm... locally a package compiled fine, but on LP/PPA it is missing "gtk-doc >= 1.4" thus fails to build (both for hardy)
<siretart> asac: err, I think we are miscommunication. I mean with 'wpa-roam' feature the wpa-roam integration in /etc/network/interfaces, which is very specific to debian/ubuntu
<siretart> what are you talking about?
<asac> MacSlow: missing build-depends :)?
<asac> siretart: right thats why i ask. i see that wpa-roam for eni is debian only
<asac> siretart: now i wonder about wpasupplicant.conf?
<asac> e.g. is that a debian thing? or is that upstream? if its upstream, what happens if you define two configurations in there :)
<MacSlow> asac, well in the original package I "lended" the control file from there's not mentioning of gtk-doc in Build-Depends
<siretart> asac: what is with wpasupplicant.conf? you terribly confuse me now
<siretart> asac: perhaps you want to give me a call?
<asac> siretart: yeah ... if you have time now ;)
<asac> MacSlow: add it ... and maybe try with pbuilder
<asac> MacSlow: maybe you are missing a configure switch to disable docs?
<MacSlow> asac, yeah... just checking that
<siretart> hosts:          files dns [NOTFOUND=return] nis
<emgent> heya pitti :)
<pitti> hello again
<asac> siretart: /etc/NetworkManager/dispatcher.d/01ifupdown
<asac> thats the wrapper
<siretart> asac: aah, excellent. is that the only purpose of the NM Dispatcher?
<pitti> argh
<pitti> apparently 2.6.26 has an alsa driver for the PC speaker
<ogra_cmpc> fun
<pitti> which makes pulseaudio playback sounds through it
<pitti> and as a result, the session startup takes some 10 minutes, while the PC speaker gives really weird noise
<pitti> (in vmware, anyway)
<asac> siretart: yes i think so
<ember> pitti i'm having that on a intrepid machine using pulse
<ion_> pitti: :-D
<asac> siretart: http://paste.ubuntu.com/21615/ ... you think thats too hacky? :-P
<asac> err, s/usr/var/ :)
<asac> siretart: not a serious approach. just a poc. to do it right we would have to check if NM is running or something
<siretart> asac: I'm not really familiar what this mdns_minimal.so does, but if it really only duplicates the dns module using a custom resolv.conf, it might be an interesting 'hack' for the nm problem :)
<siretart> asac: right. you need to consider the cornercases
<asac> siretart: yeah. we could put NM logic directly into mdns ... not sure how much cheering that would get though :)
 * persia thinks little
<asac> e.g. if running -> use this ... otherwise use that
<siretart> asac: well, mdns has very little to do with NM. I fear you'll get into unneeded complexity with that.
<siretart> asac: however it might be a very good start and source for inspiration
<asac> siretart: btw, if you use dhcp in interfaces it will also just overwrite your /etc/resolv.conf, wouldn't it?
<siretart> asac: no. why should it?
<siretart> err
<siretart> wait
<asac> siretart: how does it work then?
<asac> siretart: doesnt dhclient do that?
 * asac confused
<siretart> asac: yes, of course it does. sorry. /sbin/dhclient-script to be exact does that
<siretart> need to run now however. cu later!
<asac> cu
<cody-somerville> bryce, Is how we did libxcb in Hardy down in Debian too?
<dholbach> mvo: where do I get -virtual?
<mvo> dholbach: eh, were did you get 2.6.26 :) ?
<mvo> dholbach: I don't have it here in my intrepid VM
<dholbach> mvo: are you sure you're on intrepid? :)
<dholbach> I tried both 2.6.26-{1,2}-generic - both don't boot up in KVM
 * mvo updates
<mvo> just to be sure
<dholbach> also I have this strange issue with the mouse pointer - it just moves in the upper left 50x20 pixels, really slowly
<dholbach> very weird
<dholbach> soren: ^ do you know anything about that?
<mvo> dholbach: how strange, I do not see 2.4.26
<mvo> :/
<mvo> soren: did you had a chance to look at this alt-gr patch for kvm that I sent you some days ago via LP?
<soren> dholbach: Err... Does it not boot or does the mouse misbehave? It can't be both :)
<soren> mvo: I've been away for two weeks. I'm not really caught up on lp bug mail just yet :)
<dholbach> soren: with 2.6.26-{1,2}: no boot, with 2.6.24-16: no fun with the mouse pointer
<mvo> soren: no problem :)
<dholbach> mvo: https://edge.launchpad.net/ubuntu/intrepid/+source/linux/2.6.26-2.6
<mvo> geh, since monday
<soren> dholbach: Hm... You might be shocked to know that I don't use kvm's graphics capabilities very much :)
<dholbach> mvo: using de.archive.u.c?
<mvo> no, archive.u.c
<dholbach> soren: GAR!
<soren> dholbach: Are you using vmmouse in your guest?
<dholbach> yes
<soren> dholbach: Are you running though libvirt (i.e. using vnc) or are you running kvm from the commandline (and hence probably using sdl)?
<dholbach> soren: I tried both
<soren> dholbach: Same problem? This is with the kvm from intrepid?
<dholbach> host is hardy, guest is intrepid (amd64)
<mvo> now I have it, that is *very* mysterious
<dholbach> mvo: I'm sure smart would have found it ;-)
 * dholbach hugs mvo
<soren> dholbach: This only happens with intrepid guests?
<dholbach> soren: it's just been happening since a few days - let me try an older hardy image I have
 * soren glances at our esteemed X maintainers
<dholbach> it just feels that I'm the only one seeing this behaviour :)
<dholbach> ... weird ...
<mvo> dholbach: joy! it it does no longer find my uuid anymore with the latest -generic kernel too
<mvo> is that what you see too?
<Koon> soren: I also have no boot on 2.6.26 kernels
<dholbach> mvo: I don't get any message at all
<dholbach> Koon: cjwatson said he reported the problem to the kernel folks already
 * soren tries to install an intrepid guest
<dholbach> soren: it works with hardy, doesn't work with intrepid (X mouse, bla)
<mvo> dholbach: have you tried to remove the quiet and splash at the bootprompt?
<soren> What seems to be the problem?
<Koon> soren: looks like it gets stuck in initramfs at boot.
<dholbach> mvo: no
<Koon> dholbach: cool.
<mvo> Koon: for me it can not find my uuid anymore (missing driver or something?)
<soren> I'll take a look.
<Koon> mvo: yes, same here.
<Koon> soren: you might want to pull the latest intrepid branch, otherwise you might get caught by the other issues I ran into (and fixed)
<Koon> soren: like lilo being pulled in by the new install-recommends default.
 * mvo whistles inocenntly
 * Koon hugs mvo
<Koon> soren: you might also want to review https://bugs.launchpad.net/ubuntu/+source/ubuntu-vm-builder/+bug/206763/comments/4
<ubottu> Launchpad bug 206763 in ubuntu-vm-builder "dapper install prompts for lilo questions" [Medium,Fix committed]
<Koon> you might disagree with my patch (and you might even be right)
<soren> Koon: Heh.. Check this out...
<soren> http://bazaar.launchpad.net/~ubuntu-virt/ubuntu-jeos/intrepid/revision/soren%40canonical.com-20080604161510-93365utmi0eppjn4?start_revid=nick.barcet%40canonical.com-20080619151306-i0ucr8zdcz13t84s
<soren> shorter version: http://surl.dk/4co/
<Koon> soren: that's the change I didn't like, and reworked :)
<pitti> soren: (btw, revision/1234 works, too)
<soren> Koon: Oh, I though you didn't see it.
<soren> Koon: :)
<soren> kees: But yeah, the install-recommends bit is a good idea, too.
<Koon> soren: I saw it and I didn't like it :)
<Koon> see http://bazaar.launchpad.net/~ubuntu-virt/ubuntu-jeos/intrepid/revision/107 :P
<nijaba> soren: good reason not to like it, it certainly did not work for most of us :(
<soren> Er.. Ok, if you say so :)
<cody-somerville> Hmm... it seems the dbus issue not only affect Xubuntu but also Ubuntu users.
<cody-somerville> I've updated bug #232364 to critical
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed] https://launchpad.net/bugs/232364
<soren>  
 * mvo grabs the dash merge if noone objects
 * Lightkey objects to the use of dash as shell
<cjwatson> tkamppeter: PostscriptColor.ppd seems to have disappeared from cups-pdf, but the postinst script still relies on it; this causes intrepid CD images to fail to install. What's the right fix?
<cjwatson> (cp: cannot stat `/usr/share/ppd/cups-pdf/PostscriptColor.ppd': No such file or directory)
<soren> Oh, yay, linux-source is back!
<mvo> calc: do you mind if I take lzma?
<mon> hi, i just built netatalk with DEB_BUILD_OPTIONS=ssl sudo dpkg-buildpackage -us -uc
<mon> still it seems the required modules weren't build. any clues?
<james_w> mon: DEB_BUILD_OPTIONS won't be propogated to the subcommand by default.
<mon> so i should export it first or something?
<mon> i pretty much copypasted it from a howto, seemed to work for the other readers
<geser> mon: it's also a good idea to build as a user and use fakeroot
<geser> install fakeroot and then "DEB_BUILD_OPTIONS=ssl dpkg-buildpackage -rfakeroot -us -uc"
<mon> -rfakeroot?
<mon> no space?
<cjwatson> no space
<cjwatson> I think 'debuild -e DEB_BUILD_OPTIONS=ssl -uc -us' is a bit easier though
<cjwatson> (requires installing devscripts)
<mon> i'm running the fakeroot version already
<mon> though i don't really care whether i build as root or user (yes that's a BAD user!)
<mon> this is my testing box and i really want it to "just work" ;)
<mon> hm the process quit because it couldnt find libcrack-dev
<mon> which was pointed out by the howto but i didnt include because i thought it was for testing passwords only
<cjwatson> you do need to install all build-dependencies, as a general rule
<cjwatson> or else modify the package to remove the need for them
<cjwatson> if you absolutely believe it's not necessary and will build without, add the -d option
<cjwatson>        -d     Do not check build dependencies and conflicts.
<mathiaz> dholbach: is there a place where you have your really-fix-it script ?
<dholbach> no, not right now - in a session, will chat to you about it in a bit
<mathiaz> dholbach: great - thanks :)
<bdmurray> pitti: still around?
<pitti> hi bdmurray
<bdmurray> Hi! I ran across bug 230877 and thought it looked like a good thing to fix for Hardy.
<ubottu> Launchpad bug 230877 in dbus "dbus inherits parent filedescriptors" [Unknown,Fix released] https://launchpad.net/bugs/230877
<bdmurray> Well, or easy at least.
<mon> it worked! thanks geser and cjwatson
<mon> is there a more general linux-dev channel btw?
<jcastro> anyone know the proper url in lp for all the intrepid specs?
<pitti> jcastro: https://blueprints.launchpad.net/ubuntu/intrepid/+specs
<pitti> jcastro: however, not complete yet (many are still only 'proposed')
<jcastro> I see, no way to see the raw list?
<pitti> not that I know of
<jcastro> k, thanks
<seb128> jcastro: what do you call raw list?
<pitti> 'proposed' list?
<jcastro> seb128: everything proposed
<seb128> jcastro: https://blueprints.edge.launchpad.net/ubuntu/intrepid/+setgoals is you have access
<jcastro> I don't
<seb128> me neither ;-)
<jcastro> but if it's not public then that's ok, I am just putting a report together of UDS
<jcastro> and want to point people to the list of specs
<jcastro> so whatever is available is fine by me
<seb128> alright
<\sh> didn't we have a spec about a launchpad client? ,)
<bryce> cody-somerville: yes, in fact we're getting xcb via a libx11 sync from debian
<bryce> cody-somerville: see changelog for libx11 (2:1.1.4-2)
<cody-somerville> bryce, Corasc says Debian Xfce isn't experiencing this problem
<cody-somerville> bryce, so it is either a Ubuntu delta exposing the libxcb bug or a ubuntu delta agitating it.
<bryce> cody-somerville: ok
<cody-somerville> bryce, I also feel that due to the nature of the issue a lot of people who experience it just restart x or reboot and continue going
<cody-somerville> Clearly how Xubuntu is setup the issue occurs much more frequently which is why we have the bug reports
<cody-somerville> but it has taken awhile for it to build up
<cody-somerville> It started as a whisper and now it looks like a regression that affects both Xubuntu and Ubuntu.
<mario_limonciell> cody-somerville, what's this bug number?
<cody-somerville> bug #232364
<ubottu> Launchpad bug 232364 in dbus "dbus-launch freezes for unknown reason at session start" [High,Confirmed] https://launchpad.net/bugs/232364
<mario_limonciell> wooh, yuck! :)
<pitti> bdmurray: oh, indeed, that looks fine
<bdmurray> pitti: should I subscribe ubuntu-main-sponsors then?
<pitti> bdmurray: I assigned it to me
<bdmurray> okay, great!
<pitti> (just commented on the buG)
<pitti> bdmurray: thanks for digging that out, that sounds important
<BenC> checking for x86_64-linux-gnu-gcc... (cached) gcc checking for C compiler default output file name...  configure: error: C compiler cannot create executables
<BenC> anyone know why that would be happening in intrepid amd64/grub builds?
<BenC> can't reproduce it locally
<BenC> and it seems to be grub specific, but it builds everywhere else fine, and locally fine
<BenC> and it was fine in hardy
<slangasek> BenC: it may be related to the new default CFLAGS settings
<BenC> slangasek: anyway I can get config.log?
<BenC> maybe I could hack the build to cat it before failing
<BenC> so I can see it in the build.log
<slangasek> could do
<cody-somerville> So... what is the best course of action? I assume it would be too risky to recompile X11 with libxcb disabled or to apply the experimental upstream patches for Hardy :(
<bryce> cody-somerville: well, the experimental patches don't apply.  I think what we need is a git tree we can pull from, or some directions on how to get those patches built
<BenC> configure:2984: gcc -m32   -static conftest.c  >&5/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.1/libgcc.a when searching for -lgcc
<BenC> slangasek: looks like -m32...not sure where it came from
<BenC> maybe I need to do something about getting 32-bit libs in build-deps
<slangasek> hrm, I thought grub was always built as 32-bit
<slangasek> and I also thought it already had the build-dep on the 32-bit libs
<BenC> slangasek: ah, I wonder if gcc-4.2-multilib needs to be changed to gcc-multilib
<BenC> in build-deps
<BenC> I have that locally, so it would explain it
<slangasek> if there's a gcc-multilib available and we're otherwise not using a specific version, then that sounds right :)
<BenC> intrepid is using gcc-4.3-multlib, and gcc-multilib is the meta package pointing to the right one
<BenC> matching the gcc command
<BenC> I'm pretty sure this will fix it
<slangasek> sounds like it
<cody-somerville> bryce, I don't think those patches would fix the issue anyhow without patching the applications themselves to use the stuff
<bryce> ah ok
<bryce> cody-somerville: is there anything else I could do in helping resolve this issue?
<cody-somerville> bryce, make it work? :P
<cody-somerville> lol
 * bryce waves a wand
<bryce> guess I can re-dig through all the logs and backtraces another time
<cody-somerville> Oh, I know what you could do
<cody-somerville> First, install Xubuntu and see if you can reproduce it easily enough
<cody-somerville> Then you could try recompiling with xcb disabled and see if it still occurs
<cody-somerville> btw, Keybuk was convinced that the select it was hanging on was in dbus-launch and not actually libxcb
<cody-somerville> However, I'm not so sure because I attached gdb to the other running processes and they all had the similiar backtraces.
<cody-somerville> xfce4-session had pretty much the same backtrace as dbus-launch
<cody-somerville> the others were in some xcb wait function
<bryce> what did Keybuk say exactly?
<bryce> the one system I have that I can easily reinstall at the moment is an amd64. have there been reporters seeing the problem on amd64?
<cody-somerville> bryce, yes
<cody-somerville> http://ubuntu.pastebin.com/m50aa1bc4
<bryce> ah thanks
<bryce> hmm
<bryce> so sort of sounds like debugging from the libxcb side of things is the wrong place to look?
<bryce> hmm, scott's comments just give me more questions :-P
 * cody-somerville nods.
<cody-somerville> I talked to someone else
<cody-somerville> and they said the previous write statements do not mean that it isn't in libxcb
<cody-somerville> bryce, if you were to attach gdb to X, what would you expect to see?
<bryce> since it's a hang, I'd expect it to be stuck somewhere along the waitfor loop
 * cody-somerville nods.
<cody-somerville> #0 __kernel_vsyscall()
<cody-somerville> #1 wait4() from [path to libc]
<cody-somerville> #2 ??
<cody-somerville> #3 __libc_start_main from [path to libc]
<cody-somerville> #4 ??
<cody-somerville> But before that
<cody-somerville> Er,, sorry
<cody-somerville> I tried again and the next time I found it was in ptrace
 * cody-somerville ponders.
<bryce> well, in case it is an xcb issue, I do know bart massey personally...  I'll drop him an email.  If nothing else maybe he can get some action going on our upstreamed bug.
<cody-somerville> Well, the issue seems to be deadlocks involved in waiting for responses from the X server.
<cody-somerville> and it has been known since 2004
<cody-somerville> Who decided to enable libxcb anyhow?
<bryce> now, now
<bryce> email sent
<bryce> I cc'd you
<bryce> I don't think it's productive for you to look for assigning blame, but you can consider it my decision if you want
<bryce> of course, the decision ultimately comes from upstream of us
<bryce> libxcb had been disabled in debian previously due to problems it caused with java apps, so we did not activate it until after that problem was resolved.
<cody-somerville> I'm not looking to "place blame".
<cody-somerville> I wanted to discuss with the person (ie. you) if it would be possible for us to disable it again
<bryce> of course anything is possible, however do you have proof that the problem goes away when it's disabled?
<cody-somerville> bryce, I would ofcourse test the solution before recommending it :)
<bryce> there's also the issue if turning it off would cause other problems
 * cody-somerville nods.
<cody-somerville> Indeed. Very scary prospects all around.
<bryce> let's wait on bart's response.  Bart was the one who encouraged us to turn it on long ago, so I'd expect him to supply some help in pointing us towards solutions.
<bryce> even if we did shut it off in hardy, though, I'd want to leave it on for intrepid.
<bryce> the only way these issues are going to get found and fixed is if people use it and report it
<cody-somerville> bryce, In the mean time, I'm going to see if omitting --exit-with-session fixs the hang and just take care of killing dbus manually.
<bryce> ok
<bryce> I'll see if I can identify what's involved in compiling libx11 without libxcb if you want to also test that
<slangasek> isn't that "grab an older version of libx11 before the switch"?
<bryce> slangasek: maybe
<cody-somerville> bryce, whats the risk associated with the session bus not being terminated at the end of session?
<bryce> cody-somerville: I'm not sure...  if the user re-logged in would it result in multiple sessions running?
<bryce> cody-somerville: btw have you been able to obtain a full backtrace yet?
<cody-somerville> What did you say was the command for that?
<bryce> (gdb) backtrace full
<bryce> also see https://wiki.ubuntu.com/X/Backtracing
<bryce> this looks like maybe the bit keybuk was referring to:
<bryce> [pid  7877] read(20, 0x8056f3c, 4096)   = -1 EAGAIN (Resource temporarily unavailable)
<bryce> [pid  7877] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfd17a18) = -1 ENOTTY (Inappropriate ioctl for device)
<bryce> [pid  7877] select(21, [20], NULL, [20], NULL) = 1 (in [20])
<bryce> [pid  7877] read(20, "", 4096)          = 0
<bryce> cody-somerville: mm interesting check this search out - https://bugs.freedesktop.org/buglist.cgi?quicksearch=dbus-launch
<bryce> "You can look at the environment of your apps with something like
<bryce> "ps ewwwww" and everything in your login session should have the same
<bryce> DBUS_SESSION_BUS_ADDRESS. If anything has a different (or missing) address,
<bryce> that is your problem."
<bryce> fdo #8294 looks interesting
<bryce> not directly relevant though
<bryce> ditto 9884
<cody-somerville> hmm
<cody-somerville> Weird, a buddy of mine reports those recent updates to gutsy caused his screen to revert to 800x600.
<bryce> cody-somerville: the only X updates were some security fixes
<bryce> and that was about a week or so ago
<cody-somerville> bryce, from the log, it seems like it was after the kernel was updated.
<bryce> cody-somerville: was he using -nvidia or -fglrx by chance?
<cody-somerville> yes
<bryce> which?
<bryce> <gchaix> bryyce: Oh what fun.  X is starting up in failsafe mode after rebooting on the new 2.6.24-19 kernel
<bryce> * gchaix digs into the logs
<bryce> <gchaix> Huh ... comes up in vesa mode thinking the virtual size is only 800
<bryce> gchaix was using -nvidia
<cody-somerville> He has an nVidia card to the best of my knowledge.
 * cody-somerville nods.
<cody-somerville> nvidia
<bryce> gchaix was on hardy though
<bryce> could have been the same update though
<bryce> cody-somerville: fwiw, gchaix worked around via use of envyng
<bryce> however I'm not sure how safe envy was on gutsy
<bryce> anyway, kees thinks it's probably unrelated.  -nvidia troubles are usually caused by "badly installed meta packages or 3rd party drivers"
<kees> heh, beat me to it -- was just going to say it here too :)
<bryce> kees, while we have your attention, would you mind looking at this xubuntu/xcb bug, that seems to be hanging during a socket() call?  https://bugs.freedesktop.org/show_bug.cgi?id=16420
<ubottu> Freedesktop bug 16420 in Library "Freeze in _xcb_in_read_block during select()" [Critical,New]
<bryce> kees: we're currently stumped on what to do next to debug it further, and have not yet gotten feedback from upstream
#ubuntu-devel 2008-06-21
<kees> bryce: sure, one sec
<kees> after only a quick look, that select just means it's expecting to read data from one of the pipes
<kees> some kind of race condition resulting in both processes getting blocked
<kees> I'd probably need to read up a lot more on dbus to be useful, I'm afraid.
<cody-somerville> kees, It is the bilateral X socket
<cody-somerville> both dbus-launch and xfce4-session get stuck
<cody-somerville> killing dbus-launch releases the dead lock
<cody-somerville> so I would agree a race condition
<kees> I bet killing xfce4-session release the deadlock too.  ;)  but it's not a dbus pipe?
<cody-somerville> kees, well, the fd is created by libxcb for the purpose of returning said connection to X
<cody-somerville> so I assume it is bilateral X connection
<bryce> cody-somerville: until we get the libxcb issue sorted, could you join and lurk on #ubuntu-x?  tjaalton and/or jcristau may be in a better position to give advice.
<YokoZar> How do I add something to the sync blacklist?
<cody-somerville> I imagine you'd request it from an archive admin
<ScottK-laptop> YokoZar: Generally it's done in conjunction with package removal requests.
<slangasek>   op_backend->mount_source = NULL;
<slangasek>   if (res != 0)
<slangasek>     {
<slangasek>       /* TODO: Error from errno? */
<slangasek>       op_backend->mount_source = NULL;
<slangasek> ahhh, confidence-inspiring
<lamont> hrm... I guess I'd better work on my merges, eh?
<evocallagha> Ping
<evocallagha> Got a mate trying to install Ubuntu 8.04 on a AMD x86 box with VIA chipset, ï»¿CD passes its md5sum so we know its not that, we passed noapci acpi=off noapic and tried a different CD rom drive. After GRUB the CD hangs on "Kernel 100%". Anyone know what _could_ be going on ?
<evocallagha> Sorry to ask here, #ubuntu is filled with people without a clue :/
<BenC> evocallagha: I'm guessing, but I'd say you need to wait longer
<BenC> evocallagha: and removing "quiet splash" from the command line might help
<evocallagha> ï»¿BenC:ok thanks you, I he did say he waited
<evocallagha> I think ï»¿"quiet splash" is the key I was looking for, as I don't have the box in front of me, it makes it a bit harder over the phone
<evocallagha> After about 3mins he says it comes up with 8042809F
<evocallagha> No scrolling text from the kernel after its unpacked so it would seem
<evocallagha> IO error
<evocallagha> I asked him to change the CDROM drive and burn another copy. However, I am rather perpelexed by this.
<evocallagha> s/perplexed
<linux4ever> hello. is there anybody from the real ubuntu-team?
<linux4ever> does anyone of you know a good tool to remaster ubuntu?
<AstralJava> Hey gang, where can I find latest updates (for Gutsy)? I'm having a problem that occurred after installing the latest updates, the problem is that root filesystem cannot be found.
<AstralJava> *list of latest updates
<Chipzz_> 1) this is not a support channel
<Chipzz_> 2) it's a weekend
<Chipzz_> 3) try booting with your previous kernel if it's still installed
<AstralJava> Actually I'm not expecting any more support except the thing I asked first. I'm well aware of the nature of the channel.
<Chipzz_> I heard something fly by about latest kernels being unbootable, but I thought that was intrepid
<Chipzz> so the issue may possibly be known
<AstralJava> Doesn't look like it, this is a Gutsy system.
<AstralJava> Yeah okay, thanks.
<Chipzz> you could always try to ask in #ubuntu-kernel
<AstralJava> Still, do you know of a link or any such thing, that contains latest updates?
<Chipzz> but again keep in mind that it's a weekend
<AstralJava> Alright will do.
<AstralJava> Not a problem. :)
<AstralJava> I can work around this, just interested in helping out if possible.
<Chipzz> ah
<Chipzz> you could also file a bug in launchpad
<Chipzz> but make sure to do it against the correct kernel version and ubuntu release then
<AstralJava> I'll do that, I'd just gather up some more information ahead.
<AstralJava> Sure, will do.
<Chipzz> as far as the latest updates go
<Amaranth> this EC GPE storm thing is annoying
<Chipzz> that depends on what's in /etc/apt/sources.list (or other files in that dir)
<Amaranth> poll mode for my volume and brightness keys makes me sad
<Chipzz> licensing issues make me sad
<Amaranth> Chipzz: the 2.6.26-2-generic kernel in intrepid boots fine
<Amaranth> I've even got nvidia :)
 * Chipzz rebuilding apache against mysql because if apache license and gpl being incompatible
<Chipzz> s/if //
<Chipzz> s/if /of /
<Chipzz> rather :P
<Amaranth> mysql isn't using gpl3?
<Amaranth> i thought they were one of the first to switch
<Chipzz> http://svn.apache.org/viewvc/apr/apr-util/trunk/INSTALL.MySQL?view=markup&pathrev=371029
<soren> Oh, the horror!
<soren> pulseaudio uses my internal pc speaker by default in Intrepid.
<soren> I didn't even know I had one, so it freaked me out *BIG* time.
<crimsun_> already worked around in the alsa-driver source.
<soren> Since when?
<crimsun_> since 1.0.16-1.1ubuntu1
<soren> of?
<crimsun_> alsa-base: /etc/modprobe.d/alsa-base
<soren> I'm already at that version.
<soren> And yes, I've got:
<soren> options snd-pcsp index=-2
<crimsun_> soren: need alsa-info.sh output and pulseaudio -vv output pastebinned.
<crimsun_> (you'd need to kill the latter and invoke it as such)
<crimsun_> (http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh)
<soren> Oh, so that was what that horrible, horrible sound was when I booted!
<soren> I thought one of my drives was horribly, horribly broken, but it was probably just the login sound playing through the pc speaker.
<soren> Whew.
<soren> crimsun_: Where do I find this alsa-info.sh?
<soren> Oh, sorry.
<soren> http://pastebin.ca/1052627
<nxvl> soren: does u-vm-b already support debian? or it's doable to make it support debian?
<soren> nxvl: I'm working on a new version that will do Debian, too.
<nxvl> wooho
<nxvl> soren: branch?
<nxvl> btw
<nxvl> if you have some time, can you please take a look at agueas: http://revu.ubuntuwire.com/details.py?package=augeas
<soren> crimsun_: and http://pastebin.ca/1052629
<soren> nxvl: Wow, what a coincidence. I was just reading augeas's website.
<nxvl> heh
<soren> nxvl: It's not public yet. There's a few things I want to sort out first. Monday or Tuesday.
<nxvl> well it's already packaged
<nxvl> it just need review
<nxvl> btw
<nxvl> you are also a DD, don't you?
<soren> Nope.
<Lightkey> wanna know my cup size too?
<laga> bah
<crimsun_> soren: ok, thanks.  I'll patch that in pulseaudio.
<soren> crimsun_: Cool. Thanks!
<soren> crimsun_: For now, I've just unloaded that module to restore my sanity.
<crimsun_> On first boot, it makes sense to not default to the speaker if another device is available.  The user can always choose to default to the speaker.
<nxvl> mm
<nxvl> soren: well, then just review the ubuntu version of the package please
<nxvl> :D
<soren> nxvl: I'll take a look.
<soren> nxvl: I get almost empty packages when I try to build it.
<soren> nxvl: Let's go to #ubuntu-motu..
<s0ullight> hello i'm making a .deb for the xmms package since it is often asked but i can't serve it is someone interested?
<laga> s0ullight: use the PPA service in launchpad
<s0ullight> i'll take a look after the .deb is completed :D
<bimberi> s0ullight: https://help.launchpad.net/PPAQuickStart
<s0ullight> the .deb isn't finished yet :( :P
<s0ullight> a cflag is like --prefix=/usr right?
<s0ullight> because the only difference is that during the ./configure
<virtuald> no a CFLAG is like -gg -DWHATEVER\=something
<s0ullight> well i have this exception ./configure --prefix=/usr where in the rules file do i have to make a change?
<jldugger> https://bugs.edge.launchpad.net/~knuth-bug
<jldugger> anyone like TAOCP?
<s0ullight> tail: cannot open `debian/changelog' for reading: No such file or directory
<s0ullight> dpkg-buildpackage: failure: tail of debian/changelog gave error exit status 1
<s0ullight> but the changelog file is there :&
<s0ullight> :|
#ubuntu-devel 2008-06-22
<YokoZar> ï»¿Hmm, when I download steaminstall.msi, nautilus doesn't identify it as an application/x-msi type, but instead as "OLE2 compound document storage" -- how is this being determined?  /etc/mime.types says to give .msi files application/x-msi
<virtuald> YokoZar: libmagic1 i think
<nxvl> does anyone know how do i difference a package between main or universe (for ppa)
<jldugger> debdiff?
<wgrant> nxvl: All PPA packages go into main.
<nxvl> wgrant: and there is no way to change that?
<wgrant> nxvl: That's correct.
<wgrant> nxvl: Why do you wish to do anything else?
<nxvl> dunno
<nxvl> just asking
<nxvl> :D
<wgrant> LP devs decided it was a bad idea. Not sure why.
<bliZZardz> hi .. n00b here who wants to contribute :) .. looking for packages that might need 'care takers' .. am comfortable with Py
<DktrKranz> bliZZardz, let's move to #ubuntu-motu :)
<emgent> morning
<Mirv> evand: thanks, ubiquity hardy translations are now great!
<nxvl> asac: around?
<YokoZar> Is there an intrepid image that installs yet?
<asac> nxvl: ?
<calc> for some reason ssh doesn't seem to like my rsa key, i just realized it kept asking me for a password when it shouldn't need it
<calc> it looks like it doesn't know what type key it is?
<calc> debug2: key_type_from_name: unknown key type '-----BEGIN'
<calc> debug2: key_type_from_name: unknown key type '-----END'
<calc> debug1: identity file /home/ccheney/.ssh/id_rsa type 1
<kostmo> what channel is for discussion of making packages for ubuntu?
<ScottK> kostmo: #ubuntu-motu
<kostmo> thanks
#ubuntu-devel 2009-06-15
<lajjr> hello pitti
<lajjr> Hi pitti
<ccheney> anyone know how long it takes to get from the madrid airport to the train station?
<stgraber> depends what terminal you're at
<ccheney> i'm not sure
<stgraber> ^ forget that
<stgraber> (wrong airport ;))
<ccheney> i have to get from madrid airport to renfe to go to caceres
 * stgraber tries to remember Madrid
<ccheney> hmm it appears it stops at 'atocha' station will need to look for a madrid train map
<ccheney> ah i found one :)
<superm1> ccheney, it took us about an hour, but it really depends on what terminal you fly into because some are 20-40 minutes from the metro stop
<ccheney> superm1: ah, fun
<superm1> there should be about 2 transfers on the metro you gotta do too
 * ccheney wonders if he can possibly make the train trip from caceres and the flight on the same day
<ccheney> it sounds like it would be very tight time wise to be able to do it
<dholbach> good morning
 * hyperair wonders if anyone could sync nautilus-share from debian unstable
<TheMuso> hyperair: Have you filed a bug about it?
<dholbach> TheMuso: it's unmodified in Ubuntu
<TheMuso> dholbach: Oh, it should automatically sync then.
<dholbach> right-o, or when ever big sync command is run
<TheMuso> yeah
<pitti> Good morning
<pitti> slangasek: hah, sounds like a good idea
<pitti> slangasek: there is: ENV{DMI_VENDOR}=="MICRO-STAR*", RUN+="keymap $name micro-star"
<pitti> slangasek: I agree, having udev-extras conflict sounds appropriate, since this takes over keymaps
<superm1> pitti, next time you do an upload of udev extras can you add something like a debian/README.Debian explaining how the branch is constructed for uploads from upstream checkouts? when i was porting hid2hci over to it I was quite perplexed trying to do it from bzr as I still had to run autogen.sh and have a whole slew of extra build depends to make it work
<pitti> hi superm1
<superm1> good morning pitti
<pitti> superm1: incidentally I'm just at preparing a new upload (one bug fix and upstream pull)
<superm1> pitti, ah good to know, then i'll do an upload disabling hid2hci in bluez too
<pitti> superm1: okay, I'll add a debian/README.source
<superm1> thanks, most appreciated :)
<slangasek> pitti: the micro-star map is not a complete replacement for what was in the micro-star-infinity hal-info one, AFAICS
<pitti> slangasek: in some cases I merged entries for models which didn't collide
<pitti> slangasek: IIRC that happened with the  INFINITY and the two special cases
<tkamppeter> pitti, can you upload CUPS to Debian and Ubuntu ASAP, in your 1.3.9-3 release you have also deactivated pdftopdf and not only pdftoopvp.
<pitti> tkamppeter: okay; what did that break?
<tkamppeter> pitti, you have commented out the line in addtocups which adds pdftoopvp to the Makefile. This line also added pdftopdf. I have fixed that already in the BZR.
<pitti> tkamppeter: right, I saw; I mean, did that break a lot?
 * infinity wonders if he should start typing PITTI in all-caps to see if it hilights for him.
<pitti> infinity: it doesn't :)
<infinity> Dang.
<pitti> I don't like to be yelled at
<tkamppeter> pitti, it switched CUPS simply back to the old PostScript printing workflow.
<StevenK> Haha
<StevenK> I wonder if it's case-sensitive for my client
<nellery> STEVENK
<StevenK> Yeah, it does. :_)
<tkamppeter> pitti, and I added also some patch to CUPS which should improve multiple copies printing with OOo and it should make the PDF workflow obeying optionm settings from Windows clients.
<StevenK> pitti: Oh, you broke something in udev-extras as opposed to trying to summon infinity?
<pitti> StevenK: yes, that was a laptop model name
<StevenK> Ahhh
<pitti> superm1: http://bazaar.launchpad.net/%7Eubuntu-core-dev/udev-extras/ubuntu/annotate/head%3A/debian/README.source
<superm1> pitti, ah ha.  makes much more sense now. thanks!
<pitti> superm1: well, it's still hideously complicated, but it avoids calling autotools at build time (which Keybuk doesn't like)
<superm1> what's wrong with autotools at build time?
<StevenK> superm1: Non-deterministic results
<pitti> you upload something that you didn't actually test-built before
<lifeless> people have different opinions
<pitti> and they tend to break over time
<lifeless> I prefer to build dep on autotools and avoid tar timestamp related bugs
<lifeless> tar + patch I mean
<superm1> well surely you still test build, and normally your sbuild/pbuilder env should be mirror the archive though.  by doing autotools at build time, the diffs between two different uploads can actually have a sane delta
<superm1> i'd take it more of the worry is if you have to do a rebuild later and it just adds another variable for failure when you dont want it
<infinity> Yeah.  It can leave you with unbuildable source packages.  Though, really, that would be an autotools bug, generally.
<infinity> I'm of two minds.
<infinity> I've historically patched .in files and run autotools at build-time.
<infinity> But if you run them locally using the same versions as upstream, the diffs still remain small and readable.
<pitti> infinity: autotools bug> which there are plenty of, apparently :(
<infinity> At which point, it becomes reasonably moot.
<infinity> pitti: In all my time doing the "patch .in, run autotools at build time" with the AMP stack, I only ran into one or two times when autotools rendered me unbuildable at a later date.
<infinity> pitti: Then again, those packages were updated and uploaded frequently enough that they never really suffered code rot.
<lifeless> pitti: if it randomly becomes unbuildable its straight forward enough to change styles
<lifeless> mind you the autotool stack is broken-by-design anyway; so its hard to really care.
<superm1> mvo, would it be feasible to add a hook to update manager querying if a kernel module is loaded while update manager is running, and if so, to mark a package for installation during the upgrade?
<superm1> i'm thinking that would be the better transition than the currently proposed solution for bug 381684
<ubottu> Launchpad bug 381684 in bcmwl "Need to produce a transitional binary package for LRM" [Undecided,New] https://launchpad.net/bugs/381684
<mvo> superm1: adding such a hook is certainly feasible, I can add it
 * mvo reads the bugreport
<superm1> mvo, okay cool, more or less if you see 'wl' is loaded, install bcmwl-kernel-source
<lifeless> pitti: how would you feel about https://launchpad.net/mnemosyne being removed/renamed in favour of https://launchpad.net/mnemosyne-proj? I haven't asked the mnemosyne devs yet, but it was certainly confusing for me to find the former when looking for the latter
<pitti> lifeless: I don't care about this any more, it was an early-abandoned GSoC project
<liw> a flat namespace for project names is becoming an increasingly large problem
<lifeless> quick, claim your name
<lifeless> or propose a hash based solution :)
<liw> though still luckily very small (and yay for known _two_ obscure languages to pick names from :)
<liw> lifeless, <suspicous> are you making facebook references at me?
 * directhex claims "default.aspx" as a project name
<lifeless> liw: would I?
<lifeless> directhex: take con.1, that will break all asp sites :)
<directhex> lifeless, if mono is immune to that, can i use it as an argument that microsoft is a poor platform for asp.net?
<lifeless> http://blog.bitquabit.com/2009/06/12/zombie-operating-systems-and-aspnet-mvc/
<directhex> lifeless, i know!
<lifeless> I think you can yes; read the above link for a laugh.
<directhex> jms@osc-bigmac:~/testy$ curl http://localhost:8080/con.1
<directhex> <html>
<directhex> <head>
<directhex> <title>ASP.NET Hello World</title>
<directhex> winnar
<ajmitch> as long as it's not as bad as the old blue screen whenever a windows system viewed a webpage referencing c:\con\con
<directhex> ajmitch, awesome
<ajmitch> directhex: so easy to put in an img tag
<lifeless> ajmitch: score!
<ajmitch> that bug even has its own wikipedia page
<directhex> man, people actually used windows with bugs like that? o_o
<AnAnt__> Hello, will nvidia 180.60-0ubuntu1 be backported to Jaunty ?
<lifeless> is there a SRU bug open for it?
<AnAnt__> nope, but there is a bug about instability of Jaunty's nvidia driver
 * mvo hugs liw for the apt-sync spec
<lifeless> apt-sync?
<AnAnt__> LP 353502
<ubottu> Launchpad bug 353502 in nvidia-graphics-drivers-180 "system freezes with nvidia 180.37 driver" [Medium,In progress] https://launchpad.net/bugs/353502
<lifeless> mvo: where is the PPA UI now?
<mvo> lifeless: delta deb downloads b
<lifeless> oh cool
<mvo> lifeless: in software-properties
<mvo> lifeless: just add "ppa:lifeless" there in the add dialog
<directhex> mvo, we need a different name for them than "delta deb" though. "ddeb" is taken.
<AnAnt__> tseliot: ping
<mvo> lifeless: the script is not (yet) included
<mvo> directhex: true
<directhex> oh, i have an awesome idea
<directhex> since we force-feed people utf-8.....
 * ajmitch cringes
<lifeless> mvo: is that 'software sources'?
<wgrant> Hahaha.
<mvo> *autsch*
<mvo> lifeless: yes
 * ogra wonders if there is a gree letter for "deb"
<lifeless> mvo: so its in synaptic too?
<ogra> *greek
<directhex> Î´deb
<AnAnt__> mvo: oh, you're the guy working on adding PPA support in update-manager ?
<mvo> lifeless: yes
<lifeless> cool
<mvo> AnAnt__: yes
<directhex> or Îdeb
<liw> mvo, I would welcome feedback on the spec
<directhex> either way, totally awesome and fun to tab-complete
<AnAnt__> mvo: so, will it also be able pull the key of this PPA ?
<lifeless> mvo: are you using the same approach I did, of a list.d file, with ppa name driving the disk file ?
<lifeless> mvo: (I want to convert the things I used ppa-enable on to use the 'official' code
<directhex> mvo, ooh, can i ask for changelog support for PPAs in update-manager?
<lifeless> directhex: file a bug
<lifeless> :)
<mvo> AnAnt__: yes
<ogra> directhex, will be added after Îdeb :P
<james_w> directhex: you can ask...
<AnAnt__> mvo: cool, thanks
<directhex> james_w, awesome, here goes:
<mvo> lifeless: it adds it to the main sources.list currently, but that is a implementation detail, your approach is nicer
<mvo> lifeless: it looks the same in the UI
<directhex> mvo, please add changelog support for PPAs in update-manager while you're at it!
<lifeless> mvo: ! copy my code!
<AnAnt__> mvo: so probably there is no need for this package: http://revu.ubuntuwire.com/details.py?package=sabily-keyring , right ?
<lifeless> mvo: or do you need me to give you a patch?
<mvo> lifeless: I want to merge your script into some package (not sure which one yet) so that its available on servers as well
<mvo> lifeless: I can not just copy it, the software-properties bits use aptsources for the dealing with the sources.list, so its slightly different
<lifeless> mvo: sure; I appreciate layers etc.
<mvo> AnAnt__: that should no longer be required
<AnAnt__> mvo: ok, thanks
<james_w> directhex: it's not that easy
<james_w> directhex: and probably not an update-manager change
<mvo> directhex: there is a patch for this, it had some issues, it also will hammer launchpad quite a bit (and LP does not provide the changelog in "raw" format)
<ajmitch> mvo: sounds like a change needs to be made on launchpad for it then
<mvo> ajmitch: yeah
<AnAnt__> mvo: ok, I archived it
<geser> is there a location where one can check when the last auto-sync from Debian was done?
<cjwatson> not to my knowledge
<cjwatson> but if this is code for "please run an auto-sync", I can do that now
<geser> cjwatson: yes, please and thanks for doing it
<ogra> seb128, did anything in the evo folder format change with a recent upgrade ? i cant get to my mail, its only "savig folder" over and over
<seb128> no
<ogra> hmm, weird then
<lifeless> I'm running tip and its fine for me
<ogra> oh, now it recieves ...
<lifeless> still does way to much IO
<lifeless> ogra: look at IO top when its like that
<lifeless> ogra: its probably doing 1 MB/sec of IO :P
<ogra> lifeless, yeah, i usually just need to ask seb128 and it starts working again :)
<ogra> its finally getting my 600 waiting mails
<Ng> all gnome apps fear seb
<ogra> i'll check with iotop next time
<Tm_T> Ng: then what seb fears?
<lifeless> ogra: feel free to confirm/sub to http://bugzilla.gnome.org/show_bug.cgi?id=584602
<ubottu> Gnome bug 584602 in Mailer "opening a folder does too much disk IO" [Normal,Unconfirmed]
 * ogra puts a bookmark up ... 
<ogra> it definately does take to much IO
<ogra> (it also definately recieves to much spam, but that might not be evos fault :P )
<indus_> hello all
<mok0> Has selinux been introduced into karmic?
<cjwatson> geser: (done, by the way)
<mok0> Apparently gcl has some issues with selinux, so if that has been introduced into karmic it would explain an FTBFS I am working on
<hyperair> mok0: apparently yes it has
<cjwatson> we've had selinux packages in the archive for eons
<hyperair> CONFIG_SECURITY_SELINUX=y
<cjwatson> ah
<hyperair> i'm not sure about previous kernels
 * mok0 was so happy not having to deal with selinux crap anymore after leaving redhat behind :-(
<mok0> hyperair: where is that config?
<hyperair> mok0: /boot/config*
<hyperair> i think it can be disabled though
<mok0> hyperair: thanks, will look into that
<hyperair> =)
<mok0> hyperair: you wouldn't dream of the grief selinux has cost me over the years.
<hyperair> what grief?
<mok0> hyperair: compilations fail with the most incomprehensible errors
<hyperair> heheh
<hyperair> access violations and whatnot i bet =p
<hyperair> i really hated selinux's guts when i was maintaining a centos server
<mok0> hyperair: and you spend hours and hours debugging until you discover that it was stupid selinx interfering without letting you know
<hyperair> heheh
<mok0> hyperair: seriously I hate selinux with a passion
<hyperair> don't we all =P
<hyperair> on a side note, i think the kernels have selinux disabled by default
<hyperair> compiled in, just not enabled
<hyperair> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
<hyperair> unless i'm misunderstanding something =\
<mok0> hyperair: I don't have /boot/config/
<hyperair> mok0: it's not /boot/config/, it's /boot/config-`uname -r`
<soren> hyperair: /boot/config-`uname -r`
<mok0> right ><
<hyperair> hehe
<mok0> Any suggestions as how to deal with this problem in a builder? See here: http://pastebin.com/f73508858Â¨
<mok0> http://pastebin.com/f73508858
<mok0> Let me change that again: http://pastebin.com/m20327b7a
<mok0> And if that's done, will axiom be able to run without changes to the kernel?
<mok0> trying to compile using setarch ... -R
<soren> mok0: Axiom? As in the computer algebra system?
<mok0> soren, yes
<mok0> soren, working on the ftbfs
<soren> Oh!
 * soren hugs mok0
<mok0> heh
<soren> I've been wondering about that one for... Well, *years* I suppose.
<soren> Not actively all the time, mind you.
<soren> but still.
<mok0> soren: trying to build the newest version
<mok0> soren: looks as if the setarch ... -R gets me a bit further
<mok0> soren: but I am afraid the resulting app might need to work under the same environment
<jerroome> hello, I would like to start an application on startup. Therefor, I edited the /etc/event.d/tty1 file. I replaced the /sbin/getty with my application. Some parts of the application is launched; but the main visual part isn't. It's a text based application. Does anybody know what I'm doing wrong ?
<mok0> jerroome: is your program a getty replacement?
<jerroome> no, it isn't
<mok0> jerroome: it sounds like a very unconventional way to start a process
<jerroome> I also tried to give my program as argument to getty, but the result is the same
<jerroome> before, it was started inside inittab
<mok0> jerroome: what does your program do
<mok0> ?
<mok0> jerroome: why don't your put "program &" in /etc/rc.local?
<jerroome> hmm, because I thought that wasn't the way to do ...
<mok0> jerroome: replacing getty is the completely wrong way
<jerroome> ok
<mok0> getty is for watching tty connections, terminals, modems and that sort of thing
<mok0> jerroome: you can also place a script to start your program in /etc/init.d
<jerroome> I thought I had to put it there if I needed my app to run inside vt1
<mok0> jerroome: just for output?
<jerroome> you mean vt1  ?
<mok0> jerroome: yes, you want to re-direct output to vt1?
<jerroome> I need the application to run there because I'm asked to, I think it's for communication with some serial ports
<jerroome> I'm porting an app which was developped for fc6 onto ubuntu ...
<jerroome> It's an automatic bike renting application which is connected to different serial devices ..
<jerroome> as I thought, the application doesn't run correctly when launched through /etc/rc/local
<jerroome> /etc/rc.local
<mok0> jerroome: a bit beyond my experience I'm afraid. Try #ubuntu-server
<jerroome> ok, however, thank you for your advices
<pitti> does anyone have a multi-format SD/MMC/CF card reader, or any SCSI device with multiple LUNs? (quick test: "lshal | grep storage.lun" outputs something)
<mok0> soren, axiom compiled, but then segfaults :-(
<soren> /o\
<Nafallo>   storage.lun = 0  (0x0)  (int)
<Nafallo>   storage.lun = 0  (0x0)  (int)
<Nafallo> pitti: you didn't say I had to have something plugged in, so hopefully that wasn't the case :-)
<pitti> Nafallo: could you pastebin or email the output of "lshal" and "udevadm info --export-db"?
<Nafallo> pitti: http://pastebin.com/f577b3f6e
<pitti> Nafallo: no, I just wonder how to get the SCSI LUN from udev
<mok0> soren: I suspect it could be a problem with gcl. Do you know of any gcl packages that *work*?
<Nafallo> pitti: http://pastebin.com/f609ed562
<Nafallo> pitti: oki :-)
 * Nafallo wonder how he can teach pastebinit to use the right pastebin :-P
<pitti> Nafallo: and perhaps udevadm info --attribute-walk --path=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
<Nafallo> pitti: http://pastebin.com/f17f1bf6f
<mok0> soren, bug 387255 in case you want to subscribe to it. I'm stuck for now
<ubottu> Launchpad bug 387255 in axiom "axiom version 20081101 FTBFS on all platforms" [Undecided,New] https://launchpad.net/bugs/387255
<Nafallo> pitti: enough info you reckon? :-)
<pitti> Nafallo: yeah, I think I got it
<pitti> Nafallo: many thanks!
<Nafallo> pitti: no worries mate :-)
<JonReagan> Keybuk, you on?
<Keybuk> JonReagan: just about to have a call, grab me a bit later?
<JonReagan> k, no prob
 * Riddell sends bug 374973 back to kees, sorry for the delay
<ubottu> Launchpad bug 374973 in enca "main inclusion report enca" [Undecided,New] https://launchpad.net/bugs/374973
<superm1> pitti, can I get another set of eyes on the udev rules for hid2hci?  I swear I checked that everything worked before I submitted it, but for some reason, the rule is launching hid2hci --method dell -v  -p  --mode hci (rather than injecting the numbers via $attr{})
<pitti> superm1: TBH I don't really know what these are all about, but one thing catches my eye:
<pitti> superm1: you match on ATTRS in the first rule, but run with $attr
<pitti> superm1: i. e. the first rule will match on any child device, any of which's parent has idVendor==413c; but the device itself won't have this attribute
<superm1> pitti, I thought that's the syntax though?  looking through /lib/udev/rules.d, that's how 75-persistent-net-generator.rules does it too
<pitti> superm1: the other rules should be okay
<superm1> oh.. $attr{} doesn't grab from child devices at all?
<pitti> superm1: s/child/parent/
<pitti> superm1: no, I don't think that there's a $attrs{}
<superm1> pitti, hm well that would definitely explain it.  I'll have to rethink that first rule then. thanks
<pitti> superm1: is it just the first rule which is broken, or others, too? (the others look fine to me)
<superm1> I've only got the hardware for the first rule
<superm1> and that's the one I really care about
<pitti> superm1: I guess KERNEL== will select a particular subdevice of the entire physical device which has vendor/product ID
<pitti> superm1: oh, and another thing
<superm1> pitti, it's perplexing then how I  got this working before when I submitted it. ..
<pitti> superm1: the parent device which SUBSYSTEMS selects must also have the idVendor/idProduct attributes
<pitti> superm1: I think it's more robust to move this line to the start:
<pitti> SUBSYSTEM!="usb", GOTO="hid2hci_end"
<pitti> oh, and use SUBSYSTEMS
<pitti> unless you are sure that SUBSYSTEM=="usb", ATTR{idVendor} are on the _same_ parent device
<superm1> pitti, okay thanks for the tips.  i'll see I can strike a combination that works better and see which devices really have these different attributes with udevadm
<pitti> superm1: hang on, seems that I lied
<pitti> $attr does follow the parental chain
<pitti> superm1: so the only possible explanation that I have is that SUBSYSTEMS, idVendor, and bmAttributes don't all match on the same parent device
<superm1> Keybuk, pitti and I were trying to debug a problem with a udev rule and it looks like some really weird behavior is happening.  the rule is in udev-extras (62-hid2hci), and supposed to match ATTR{idVendor} and then pass $attr{idVendor} to the command.  it's properly matching, but passing " " to the command instead.  can you take a look if perhaps this looks like a bug that developed in udev traversing parents? http://pastebin.com/f29b3e865
<Keybuk> do you have the rule handy?
<pitti> Keybuk: in particular, s/udev traversing/$attr traversing/
<Keybuk> $attr doesn't traverse parents
<pitti> Keybuk: the manpage claims otherwise
<Keybuk> the manpage is wrong
<pitti> If the matching device does not have such
<pitti>            an attribute, follow the chain of parent devices and use the value
<pitti>            of the first attribute that matches.
<Keybuk> yeah, it's wrong
<pitti> Keybuk: well, that'd explain it :)
<Keybuk> most of the matching stuff in the manpage is bogus these days
<Keybuk> ATTR, DEVICE, SUBSYSTEM, etc. all match the exact device being operated on
<pitti> Keybuk: could he instead use $env{ID_PRODUCT} ?
<Keybuk> ATTRS, SUBSYSTEMS, etc. all match the *same* parent
<Keybuk> ie. ATTRS{foo}=="x", ATTRS{bar}=="y" will only match a single parent that has both foo=x and bar=y
<Keybuk> $attr{} expands to the exact device *or* the matched parent
<pitti> Keybuk: right, the matching already works, we went through that
<pitti> Keybuk: ATTRS{idProduct} _does_ match, we verified that; but $attrs{idProduct} in RUN is empty
<Keybuk> can you show me the rule?
<pitti> KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
<pitti>     RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
<Keybuk> hmm, so that _should_ work
<Keybuk> because $attr{} can match the match parent
<pitti> that's what I thought
<Keybuk> idVendor doesn't get expanded?
<superm1> right and neither does idProduct
<pitti> superm1: if you s/$attr{idVendor}/$env{ID_VENDOR}/ does it work then?
<pitti> superm1: (likewise with product)
<pitti> superm1: usb_id attaches those
<Keybuk> env won't work
<Keybuk> oh, sorry, yes I see
<superm1> pitti, yeah $env{ID_VENDOR} works
 * Keybuk checks the code
<Keybuk>                         /* try to read the attribute of the parent device, other matches have selected */
<Keybuk>                         if (value == NULL && event->dev_parent != NULL && event->dev_parent != event->dev)
<Keybuk>                                 value = udev_device_get_sysattr_value(event->dev_parent, attr);
<Keybuk> that should work
<pitti> Keybuk: "the" parent device is the one that *S matched on?
<Keybuk> yes
<pitti> superm1: sounds like worth a bug report then
<Keybuk> superm1: could you run udevadm with UDEV_LOG=debug before it?
<pitti> superm1: the rule, --attribute-walk output and udevadm test output should be attached
<superm1> Keybuk, sure, the same udevadm test command with UDEV_LOG you mean right?
<Keybuk> actually, that won't work ;)
<Keybuk> don't worry
<Keybuk> hmm
<Keybuk> WFM
<Keybuk> udevadm_test: run: '/usr/bin/touch /tmp/mouse-045e'
<Keybuk> err
<Keybuk> superm1: where did you get udev 142 from? ! :p
<pitti>      udev |      142-2 |        karmic | source, amd64, i386
<pitti> ?
<superm1> Keybuk, us.archive.ubuntu.com :) ?
<Keybuk> oh, did I upload that?
<pitti> -- Scott James Remnant <scott@ubuntu.com>  Wed, 13 May 2009 11:04:31 +0100
<pitti> actually, I'm TIL, but I just added the apport hook
<Keybuk> udevadm_test: run: '/usr/bin/touch /tmp/mouse-045e-008c'
<Keybuk> weird
<Keybuk> it definitely works for me
 * Keybuk tries 142
<superm1> while you're at that, i'll try downgrading to 141
<superm1> works fine in 141
<pitti> the only other $attr in a RUN that we have is
<pitti> /lib/udev/rules.d/50-udev-default.rules:KERNEL=="fd[0-9]", ACTION=="add", ATTRS{cmos}=="?*", RUN+="create_floppy_devices -c -t $attr{cmos} -m %M -M 0640 -G floppy $root/%k"
<pitti> I doubt that a missing floppy device would be noticed very fast :)
<Keybuk> works for me on 142 too
<superm1> oh wait, no it doesnt work in 141 for me either.
<superm1> (was running with the env{ID_VENDOR} in place)
<Keybuk> I used this rule@:
<Keybuk> KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{bmAttributes}=="a0", RUN+="/bin/echo hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
<Keybuk> that's basically identical to yours, right?
<Keybuk> http://pastebin.com/m25b63e4c
<superm1> yeah basically
<Keybuk> specifically, note:
<Keybuk> #
<Keybuk> udevadm_test: run: '/bin/echo hid2hci --method dell -v 046d -p c047 --mode hci'
 * superm1 is quite perplexed now why this isn't functioning
<superm1> Keybuk, pitti something about matching with that KERNEL device was messing things up.  using this rule works, so i'll just submit this upstream instead I think: ATTR{bInterfaceProtocol}=="02" ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
<superm1>     RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
<pitti> superm1: but shouldn't that at least ensure that it's an USB device?
 * pitti -> dinner
<superm1> pitti, i moved it to the top of the file
<pitti> superm1: sounds good
<znh> Hello :-)
<znh> I'm working on a system to help users find solutions to their problems is this the right place to share this?
<znh_> any reply yet on the above? Changed connections
<maxb> znh_: Your question is so very broad, it's unclear what a useful response might be.
<znh_> well I'm working on a website that lists questions asked in #ubuntu with replies based on that question. I'd like to share this in some way.
<znh_> kinda like a knowledge base
<maxb> Interesting. Though as I have given up on #ubuntu as being too high traffic to be useful, I'm probably not a useful person to talk to about this.
<evanrmurphy> znh_: I also think it's interesting. Do you have a link?
<znh_> Yes, does this work? http://62.163.12.248/print.php
<evanrmurphy> znh_: Sure does. Hmmm...
<znh_> It's still very primitive but the parsing part is reaching it's goal
<ccheney> can someone process suitesparse for me, its in new and needed by new version of OOo
<evanrmurphy> znh_: I'm very much in favor of an innovation along these lines. Speaking broadly and with more pickiness, I'd rather see an advancement integration of Ubuntu's current communication tools rather than the introduction of a new one.
 * ccheney is going to locally build the package so he can continue his work
<dajhorn> znh_: Would it be sensible to add this functionality to ubottu?
<evanrmurphy> znh_: Imagine a way that questions on IRC could tap into the archives of Ubuntu Forums and Launchpad Answers...
<znh_> Hmm...
<znh_> or a system that asks input from the user and checks multiple locations
<znh_> like Google but more targeted
<slangasek> ccheney: I'll be a-newin' shortly
<evanrmurphy> znh_: Well there are the various Google customizations for Ubuntu, two examples: http://www.googlubuntu.com/, http://crunchbang.org/ubuntu-search-engine/
<znh_> okay. How do you imagine the linkage with Ubuntu Forums and Launchpad?
<evanrmurphy> +1 to dajhorn's question of possible integration with bot functionality.
<ccheney> slangasek: thanks
<evanrmurphy> znh_: Wow, good question. Lemme think about that...
<evanrmurphy> znh_: I remember while reading the about page for Launchpad Answers, that it touted its advantage over IRC and Ubuntu Forums as being the indexing of questions in a searchable database with useful status indicators (new question, open question, etc.).
<znh_> in that case this database could be expanded with entries generated on IRC in a manner that Launchpad accepts
<evanrmurphy> znh_: Btw, as you're looking for the best venues to discuss this project, you should consider the ubuntu-irc mailing list (https://lists.ubuntu.com/mailman/listinfo/Ubuntu-irc). I haven't read or posted to it before, but the description (basically meta-discussion about IRC) seems relevant.
<evanrmurphy> znh_: Yes, I think so (to what you just said).
<znh_> I'll give it a thought. Thanks for the feedback :-)
<evanrmurphy> znh_: There might be some important hunting around to do for the big shots in Launchpad and Ubuntu Forums to get their advice on the feasibility of something like this. If it's possible, I think it could be a big breakthrough for the Ubuntu community and facilitate our communications substantially.
<evanrmurphy> znh_: Needless to say, I'm excited and interested in the project. Will you keep me posted in the near future as you continue to scout this out? I may be willing to pitch in with the work.
<lajjr> Hello pitti
<directhex> oh, for the love of..... dear requestsync, please comprehend the idea of u-u-s not being u-m-s
<directhex> i appear to have inadvertently ack'd my own mono sync
<slangasek> sounds like a requestsync regression
<slangasek> but that's ok, I was going to come pester you again about that outstanding merge anyway, so I'll just ack it myself when I do the sync. :)
<directhex> slangasek, there's a pending -5 upload being prepared which fixes a kfreebsd regression. tell me how much you care about that one :p
<slangasek> directhex: sounds critical to me - how else will we ship tomboy by default with the kfreebsd port?
<directhex> slangasek, i'm sure all sane & rational minds are happy with "tomboy | openoffice.org-writer" to catch funny arches
<mib_f0ikvw> kees: Sorry to disturb you with this, but if you could spare 5 mins, needed to bring up  the discussion you have had here with TJ on an apparently fixed major bug - https://bugs.launchpad.net/ubuntu/+source/devmapper/+bug/358654/+activity.
<ubottu> Launchpad bug 358654 in watershed "udevadm trigger is not permitted while udev is unconfigured" [Medium,Fix released]
<elfan> Is there a standard location for where source code for packages resides.  For example, https://code.launchpad.net/ubuntu/karmic/+source/xorg-server is empty yet there is clearly a changelog being generated from somewhere
<slangasek> elfan: the only standard location is in the Ubuntu archive; 'apt-get source' is an interface for downloading these sources
<cjwatson> code.launchpad.net will get populated for all source packages at some point during this release cycle (not to invalidate what slangasek said, I agree)
<elfan> But right now if I want the latest (ie 'trunk') code for a package, I just just download the latest tarball?
<james_w> cjwatson: I just happen to be starting up the scripts now :-)
<slangasek> heh :)
<decipherstatic> bryce: I tried grabbing the gpg key for the XServer with no backfill PPA but keep on getting a timeout error.  Is the ubuntu keyserver down? or just this PPA?
<bryce> decipherstatic: no idea, probably just launchpad flakiness
<decipherstatic> bryce: :) k anywhere else I can grab the key?
<bryce> decipherstatic: afaik only from the ppa
<decipherstatic> bryce: k thanks
<Keybuk> valgrind: m_scheduler/scheduler.c:1144 (vgPlain_scheduler): the 'impossible' happened.
<Keybuk> valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure
<Keybuk> sweeeeeeet :D
<slangasek> ccheney: suitesparse accepted
<ccheney> slangasek: thanks :)
<DGMurdockIII> can i get the source code for the ubuntu oem installer?
<DGMurdockIII> is the source code for the ubuntu oem installer avable?
<slangasek> pitti: ok, you're right; dunno how I misread that earlier, but I see now that all the microstar infinity keys are in that file
<cjwatson> I answered DGMurdockIII's question on #ubuntu-installer
<cjwatson> james_w: oh good :)
<cjwatson> elfan: yes
<debfx> slangasek: may I merge ptlib 2.6.3-1?
<slangasek> pitti: is there documentation somewhere of what's contained in the default keymap, or a way to query it in the current regime?  that might help eliminate some of these hotkey requests I've been reassigning to udev-extras, if we can show that they're already in the default map; or maybe not
<slangasek> debfx: if you're meaning to ask the last person who merged it, that's not me
<debfx> slangasek: ah yeah, sorry
<ccheney> is every small bug in Ubuntu now a hundred papercut bug? :)
 * ccheney sees a lot his have gotten marked this way
<ccheney> or maybe it just happens to be coincidence that they are the ones i am looking at
<ajmitch> ccheney: I think the papercut thing caught on too well
<ccheney> the last one i saw i am fixing with my upload today but it seemed odd to see so many of them
<ccheney> ajmitch: yea
<ajmitch> perhaps people think it's a way to get those bugs fixed quickly
<ccheney> ajmitch: well as long as someone is going to actually fix the bugs its a good thing, right :)
<ajmitch> sure, if they're not all just wishlist or rather specific bugs
 * ccheney thinks the people nominating hundred papercut bugs should be the ones fixing them
<ccheney> otherwise how would they know if they are 'easy' to fix bugs
<ccheney> iirc that was part of the definition of what to nominate
<ajmitch> I don't think that part was made clear originally
<ScottK> By definition any bug I don't have to fix is easy for me ....
<ccheney> slangasek: so the ooo 8.04.3 issue was already fixed just not thoroughly investigated before it seems (/me reading OOo bugmail today)
<ccheney> slangasek: erm wrt OOo itself i mean
<mdz> slangasek: hotkey-setup being removed is expected, yes?
<slangasek> mdz: yes
<slangasek> ccheney: yep
<mdz> slangasek: hooray!
<slangasek> :)
<ccheney> slangasek: ok
<marctw> when you specify partition sizes during creation, the prompt is in block size unless you append a "k/m/g" to it?
<slangasek> james_w: python-oauth debian/control: s/libarary/library/
<james_w> slangasek: is that it?
<james_w> I'll re-upload if so
<slangasek> james_w: only thing I saw on the way through... :)  Accepted already
<slangasek> so upload with a new number, please
 * james_w commits for later upload
<james_w> thanks for the reviews
<directhex> yays, thanks slangasek
<BUGabundo> tedg: ping
<tedg> BUGabundo: Hello.
<BUGabundo> tedg: another user, trying to debug GPM and getting no output at the cli
<BUGabundo> same as it did we me a few days ago, when I was trying to debug it with you
<BUGabundo> he is running jaunty, not karmic like me
<tedg> BUGabundo: It's probably that his keyboard map is not sending the hotkeys to X.
<BUGabundo> any idea why --verbose is not working ted ?
<tedg> BUGabundo: Typically HAL needs to be set up for that hardware in some way.
<BUGabundo> tedg: diff prob: his screen dims while he is typing
<BUGabundo> tedg: I've asked kimus to ping you!
<cjwatson> slangasek: IIRC lp:~ubuntu-core-dev/grub/ubuntu got fixed so that it would be mergeable from bzr-svn again. Exactly how do I go about getting a bzr checkout of the Debian svn branch (what URL, any necessary bzr-svn options, ...)?
<BUGabundo> also asking him to run apport on gpm
<slangasek> cjwatson: bzr co svn://svn.debian.org/pkg-grub/grub/trunk/debian
<kimus> BUGabundo: in
<tedg> BUGabundo: Okay, I have to run now.  But the apport data is very good.
<cjwatson> slangasek: thanks
<BUGabundo> eheh
<BUGabundo> just my timming
<kimus> BUGabundo: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/387529
<ubottu> Launchpad bug 387529 in gnome-power-manager "screen goes black after a while even when typing" [Undecided,New]
<directhex> hm, i wish we knew for sure whether the audio from UDS was saved anywhere. I'd love to get an archive copy of the debian/ubuntu relationship session
<mneptok> woot! the Albuquerque airport has free wifi!
 * mneptok does a distrubing happy dance
 * slangasek covers his eyes
<BUGabundo> ehehe
<directhex> mneptok, a few airports do. yay for them!
<directhex> mneptok, iirc tampa does
<slangasek> PDX does.  PDX > your airport!
<slangasek> james_w: hmm, is this branch spam your doing? :)
<directhex> i had to pay, like, 8 quid for an hour of wifi in barcelona!
<directhex> that reminds me, need to fill out that expenses form. no, i'm not going to try expensing wifi
<james_w> slangasek: aye, 'tis me
<directhex> when's alpha 3 due?
<BUGabundo> !schedule
<ubottu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
<BUGabundo> not that... humm
<BUGabundo> !release
<ubottu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
<BUGabundo> !karmic
<ubottu> Karmic Koala is the codename for Ubuntu 9.10, due October 2009 - Karmic WILL break - Discussion and support in #ubuntu+1
<BUGabundo> directhex: ubottu: A schedule of Karmic Koala (9.10) release milestones can be found here: https://wiki.ubuntu.com/KarmicReleaseSchedule
<directhex> meh, over a month then. no hurry to bringing in the latest space-saving changes to mono-related things
#ubuntu-devel 2009-06-16
<directhex> meebey's got a 5 meg reduction sat in SVN. we'll roll it out before alpha 3
<dcushman> How can a *NIX n00b developer with 20+ years of professional software development get up to speed and make a useful contribution?
<directhex> dcushman, start by moving to #ubuntu-motu, which is the more beginner-oriented place to be
<BUGabundo> !daily | directhex:
<ubottu> directhex:: Daily builds of the CD images of the current development version of Ubuntu are available at http://cdimage.ubuntu.com/daily/current/ and http://cdimage.ubuntu.com/daily-live/current/
<directhex> BUGabundo, i'm not rushing for the sake of dailies, not this early in the cycle
<BUGabundo> directhex: won't those changes be there?
<BUGabundo> ah ok
<slangasek> superm1: mythbuntu-desktop Recommends: dvb-utils, which is NBS; I guess it should now Recommend: dvb-apps instead?
<superm1> slangasek, i'll take a look and see
<superm1> yeah that looks right. i'll make the changes
<mib_hjyq55hr> heeeeeeeey
<mib_hjyq55hr> can anybody help me ?
<nellery> !ask
<ubottu> 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. :-)
<nellery> mib_hjyq55hr: ^^
<mib_hjyq55hr> i cant see mikrotik os router Login page on firefox although it appear in vista
<mib_hjyq55hr> r	i cant see mikrotik os router Login page on firefox in ubuntu  although it appear in vista
<borrell> please ask in #ubuntu, thats the general support channel ;)
<dholbach> good morning!
<pitti> Good morning
<ttx> Good morning :)
<pitti> slangasek: /usr/share/doc/udev-extras/README.keymap.txt has debugging instructions and also shows how to use /lib/udev/keymap input/eventX to print the current map
<oespirit> Can somebody help me out with this issue: https://bugs.launchpad.net/ubuntu/+source/devmapper/+bug/358654 ? I did an upgrade and my system wont boot anymore. I know this isnt the right channel, but noone in #ubuntu has a clue. Kees helped out many users in that thread on the lp link, but for me that option doesnt work, because cpio doesnt 'recognise' anything in /bin/*
<ubottu> Launchpad bug 358654 in watershed "udevadm trigger is not permitted while udev is unconfigured" [Medium,Fix released]
<TheMuso> Morning pitti.
<slangasek> pitti: aaaah, thanks; that should go in Hotkeys/Troubleshooting, for sure
<pitti> slangasek: yes, updating the wiki is on my TODO list
<slangasek> \o/
<jp_> auto-identify
<jp_> hello all
<pitti> TheMuso: next time, can you please use "build1" for fake syncs, so that it'll autosync automatically on the next upstream version?
<ttx> doko: about bug 384739, let me know if it makes sense and I'll prepare an update
<ubottu> Launchpad bug 384739 in java-access-bridge "libaccess-bridge-java makes -jre-headless install a full -jre" [Undecided,New] https://launchpad.net/bugs/384739
<doko> ttx: no, updated the bug report
<ttx> doko: works for me, thanks
<mneptok> slangasek: if you just got the sensation that someone walked across your grave in the future ... i have landed in PDX.
<ppawel> hey folks
<ppawel> when was upstart dbus service added to ubuntu/upstart ?
<ppawel> in latest ubuntu I only have upstart 0.3.9
<ppawel> does it have dbus api exposed?
<cjwatson> james_w: https://wiki.ubuntu.com/DistributedDevelopment/ImproveDebianImportSpecification says "The Debian Vcs-* headers are not present for every package, and even when they are not there they may be incorrect" - shouldn't that be "even when they are there"?
<cjwatson> james_w: we should totally have a standard "Non-assumptions" section in specs ;-)
<james_w> cjwatson: good catch
<seb128> hum
<seb128> why did I got 11 emails about lp:ubuntu/karmic/cairo etc on cairo bugs which are closed?
<seb128> ie bug #211791
<ubottu> Launchpad bug 211791 in cairo "Please sponsor cairo 1.5.18-0ubuntu1" [Undecided,Fix released] https://launchpad.net/bugs/211791
<cjwatson> because somebody decided to push the branch to the ubuntu/karmic/ namespace
<seb128> james_w, ^ is that due to some work of yours?
<james_w> seb128: it is
<seb128> hum
<seb128> that seems buggy to me
<james_w> we're looking in to it
<seb128> which should it spam me about sponsoring request bugs closed for years?
<seb128> thanks
<cjwatson> it's because it has bug links and LP tells you about new ones :-/
<seb128> define "new"?
<cjwatson> in the "link between this bug and this branch was not previously in the database" sense
<seb128> right now it's updating everybody bug listed in the changelog since warty?
<seb128> everybody -> every
<james_w> just sending them on bugs which still have a task open would be a good start
<seb128> right
<seb128> do you have a lp bug open about that that I can track?
<james_w> not every bug, but quite a lot of them
<james_w> no, I need to write one
<seb128> ok, let me know if you open a bug, thanks
<dholbach> pitti: do you know if there's any plans to get libchamplain* into ubuntu (maybe even main) this cycle?
<pitti> dholbach: no idea what this is; if someone files an MIR, we'll review it
<james_w> bug 387731
<ubottu> Launchpad bug 387731 in launchpad "Too many mails on new bug-branch links for Ubuntu branches" [Undecided,New] https://launchpad.net/bugs/387731
<james_w> oh
<james_w> dholbach: I thought it was already in universe
<dholbach> james_w: you're right
<dholbach> excusez-moi
<dholbach> pitti_: http://projects.gnome.org/libchamplain/ - AFAIK eog and empathy can already be built with it (http://blog.pierlux.com/2009/06/15/geolocation-in-empathy-now-real/en/ for example)
<pitti_> oh, geolocation? sweet
<cjwatson> I don't see geolocation there, it's just map display?
<geser> how often are MIRs looked at/processed?
<pitti_> geser: irregularly, it helps to ping team members if something is urgent
<pitti_> (please not me, I already did some 3 hours of MIR review in the last week)
<geser> it's not urgent, so I'll wait
<liw> does karmic have a known problem automatically mounting usb sticks?
<borrell> yep
<borrell> one sec
<borrell> LP 376786
<ubottu> Launchpad bug 376786 in hal "hal-storage-mount Segfaults" [Undecided,Confirmed] https://launchpad.net/bugs/376786
<liw> thanks
<maxb> huh, I have a different problem, it thinks my usb-sticks are internal drives, but otherwise works fine
<mdz> mvo: lately, it seems like whenever I run apt-get dist-upgrade, I find myself going back and doing ionice -c3 on the dpkg and apt-get processes so that it doesn't bog my system down
<mdz> mvo: I wonder if it would be useful to have a config option for that?
<mvo> mdz: I can add a option for that
<mdz> mvo: do you have the same experience?  I find that with modern kernels, interactive processes are severely affected by dpkg
<mdz> I'm not sure it was always this way
<pitti_> my system becomes very sluggish when there's even just a moderate amount of I/O, too
<mvo> mdz: I have a similar experience - I don't ionice, I switch to my other computer and wait for it to finish :) I like the idea, I add it right away (should be easy)
<mdz> mvo: no hurry :-)
<ogra> pitti_, mdz, did you guys watch your RAM usage in case of sluggish I/O ? i noticed that my swap is often fully used (even though there is only xchat and a terminal open) if such a massive slowdown occurs ... i'm still trying to find out why though
<pitti_> ogra: it became much better when I plugged in a second GB
<pitti_> my HD is painfully slow, thus more ram helps a lot
<ogra> well, i have 3GB RAM ... and 4G swap
<mdz> ogra: no, I haven't noticed excessive swap usage at those times
<mdz> I did see a lot of swap being used on my laptop this morning, which is new, but nothing to do with apt
<ogra> after some days without reboot i notice my swap is fully used while the system only uses 100M of ram
<pitti_> seb128 mentioned a major memleak on his intel 965
<mdz> the system I'm on right now has only 1.5G of RAM and has only used tiny amounts of swap
<lifeless> mine on my desktop leaks gigs
<mdz> pitti_: that would explain it, my laptop is 865
<mdz> er, 965
<ogra> mdz, no, i'm not blamig apt here, the apt and I/O slowness just seems to be a sideeffect
<pitti_> doesn't seem to happen on 945
<ogra> ah, 965 here too
<pitti_> lifeless: 965, too?
<lifeless> pitti_: EFAILINGMEMORY
<lifeless> my desktop is nvidida. And leaks gigs.
<ogra> lspci ;)
<lifeless> ogra: nah, just late enough I shouldn't be on IRC.
<ogra> heh, go to bed then :)
<wgrant> -intel seems to leak terribly at the moment - but it leaks GEM objects, so the used memory only manifests itself as other stuff eating into swap.
<ogra> well, the fun stuff is that even if i kill everything the swap wont be freed
<wgrant> ogra: You should be able to fix it by killing X, but you might have to swapoff to actually get the stuff out of swap.
<RAOF> Why does my laptop have a monotonically increasing swap usage?  And... oh.  Backscroll.
<RAOF> Gah.  Intel.
 * soren is trying the desktop installer for the first time in years.
<soren> Looks nice.
<RAOF> Yes, it does.  Faster than the alternate CD, too.
 * soren wouldn't know
<soren> It's *lots* slower than the server install :)
<RAOF> Really?
 * soren can do 18 server installs in 25 minutes.
<RAOF> Lately I've been doing nothing but netinst, myself.  None of this outdated cdimage crap :)
<soren> Yeah, that's what I usually do.
<soren> Unfortunately, the only way to get this box on the network was using the desktop cd apparantly.
<RAOF> That's... odd.
<RAOF> You don't have a 50" cat5 cable handy? :)
<soren> Ethernet didn't work.
<soren> Wifi did.
<soren> Go figure.
<soren> The box is 12cm (~5 inches) from my local mirror, actually :)
<soren> No need for 50" cables (which by the way are a bad idea).
<soren> Er..
<soren> No, they're not. I'm an idiot.
<RAOF> Difference between 50m and 50ft?
<lifeless> 50m should be fine, if of the right type for your switch
<soren> RAOF: No, really. I'm an idiot :)
<soren> RAOF: I was waaaay off.
<soren> RAOF: Ethernet cables shouldn't be longer than 92m, IIRC.
<RAOF> I knew there was some maximum length, but I've never had a cable remotely long enough to trigger it.
 * soren has a ~50m cable running from his office to a shed in his garden (i.e. "the server room")
<soren> That's the longest I have (and have had).
<wgrant> Isn't the limit actually 100m, with 92m suggested to allow for patch cables at both ends?
<soren> wgrant: I'm not sure. I've never done the math.
<soren> wgrant: Somehow 100m strikes me as odd. Why would it be such a neat, round number?
<RAOF> Because people like engineering to neat, round numbers?
 * wgrant leaves it for the hardware people.
<pitti> why do I suddenly get tons of "branch linked" mails? is that due to james_w's imports?
<pitti> ** Branch linked: lp:ubuntu/karmic/consolekit
<pitti> looks like it, anyway
<wgrant> pitti: Yep. Bug #387731
<ubottu> Launchpad bug 387731 in launchpad "Too many mails on new bug-branch links for Ubuntu branches" [Undecided,New] https://launchpad.net/bugs/387731
 * ogra noticed that too
<pitti> thanks
<macvr> hi all... i did an inplace upgrade of the ext3 drive to ext4... but i'v noticed considerable drop in system performance... so inorder to refresh the ext3 files as ext4 would a reinstall of the packages do the trick or has anyone tried e4defrag? i do understand this isnt the help channel but was hoping to find someone with knowledge about this...
<geser> soren: 100m is correct, see http://standards.ieee.org/getieee802/download/802.3-2005_section2.pdf the table on page 280
<soren> geser: I'm not really in the mood to read the legalese required to download that pdf.. Is the table that just lists the maximum lengths for different types of cable or does it explain how those numbers came about?
<geser> soren: it mentions that the max length is limited by the signal transmission characteristics for the specific cable. I guess there is a section describing this characteristics
<soren> Ah, so they designed the cable specs to hit 100m? I guess that almost makes sense.
<lamont> so... firefox starts to render a page, I shift focus off to another window, and then firefox finally finishes rendering the page and hijacks focus from where I'm now doing stuff (having finished with the page)...  is that just config, or do I fire a bug at firefox?
<StevenK> lamont: Tasty!
<lamont> StevenK: no, not so much.  dear gnome QUIT THINKING YOU KNOW WHERE I WANT FOCUS, DAMMIT
<lamont> and worse, it's the app, not metacity
<soren> lamont: I used to see that a lot, but I don't remember seeing it for a while. Is this Jaunty?
<lamont> er, um, hardy on the machine in question (iz server that happens to have desktop love too)
<lamont> though I'm near certain I've seen it on the jaunty box too
<Pik0r> I just developed my own small binary application (I don't want to provide the source code yet). is checkinstall the way to go when creating cross-linux installation files I can offer for download? or does checkinstall include the source code?
<StevenK> Pik0r: checkinstall is never, ever the way
<Pik0r> StevenK: why not?
<StevenK> Pik0r: Because checkinstall is effectively crack cut with arsenic and washing powder.
<Pik0r> StevenK: do you have a more technical, understandable answer why I shouldn't use checkinstall?
<RainCT> pitti, seb128: Any chance to get bug #386035 fixed in Jaunty?
<ubottu> Launchpad bug 386035 in pygtk "crash in gtk.RecentInfo.get_application_info()" [Medium,Fix released] https://launchpad.net/bugs/386035
<seb128> RainCT: we could if it's considered important for users but we didn't get such indications so far about it
<StevenK> Pik0r: It does not do dependancy resolution correctly, does not support upgrades, and it's generally better to provide a .deb for users of Debian/Ubuntu
<Pik0r> StevenK: so the best thing would be to write my own little scripts which generate .deb and .rpm files separately and run them each time I want to create a new package?
<StevenK> Pik0r: I'd suggest a .spec file for rpm packaging and a debian/ directory for .deb packaging.
<Pik0r> alright thank you, StevenK.
<cjwatson> Keybuk: regarding the foundations-karmic-swapfile spec, I was wondering if you'd put any thought into appropriate defaults for the swap file size; the spec handwaves over this a bit, I think :-)
<cjwatson> Keybuk: there seems to be a tension between allocating excessive amounts of swap for people with plenty of RAM who never hibernate, and offering enough space for hibernation for those who want it
<cjwatson> Keybuk: should we just allocate size-of-RAM and punt to a System -> Administration tool for fine control?
<RainCT> (sorry, lost the wlan connection, if you said something I didn't get it :/)
<jpds> RainCT: < seb256> RainCT: we could if it's considered important for users but we didn't get such indications so far about it
<RainCT> >> (I don't know of it causing a problem with any program available in the repos, but we want to use this in Zeitgeist and the workaround is quite ugly so I wanted to try if we can get the fix pushed everywhere :P)
<pitti> RainCT: doesn't look like a major bug to me?
<RainCT> (anyway, I have a PPA with the fix so we can live without it)
<seb128> RainCT: jaunty users will not run zeitgeist or if they do they will get it from a ppa which can get the fixed pygobject too
<RainCT> pitti: The affected function is unusable
<RainCT> Okay. Just wanted to ask :)
<Keybuk> cjwatson: I don't think there's any sane default except the current default for swap partitions
<Keybuk> I'm not convinced by the "I have hoojabytes of RAM, I don't need swap" argument
<Keybuk> especially since I've got evidence Linux really doesn't cope in that situation :p
<Keybuk> put hoojabytes of RAM in your PC
<Keybuk> fill the page cache (untar some kernel images)
<cjwatson> Keybuk: unfortunately we don't actually really have a current default :)
<Keybuk> then start firefox
<cjwatson> Keybuk: we have a set of heuristics
<Keybuk> and watch your system performance go away for a while
<cjwatson> which are vague and dependent on disk and RAM
<cjwatson> in particular, the default size for swap is computed while setting automatic partition sizes
<cjwatson> I'm not quite sure how that would work when swap creation is moved out of automatic partition computation
<Keybuk> those heuristics should be still fine, no?
<joaopinto> what's wrong with the old 2xRAM rule :) ?
<cjwatson> our partitioner has never implemented a 2xRAM rule
<cjwatson> I've changed partman-auto to support size declarations like "2500+100%" (= 2500MB + 100% of RAM)
<cjwatson> but those are always balanced against other partition sizes in the recipe
<cjwatson> i.e. you don't give partman-auto a size, you give it minimum and maximum sizes and a weighting
<ivoks> 2xram was ok until ram went over 1024MB
<Keybuk> ivoks: why?
<Keybuk> disk space when over 1TB at roughly the same time ;)
<joaopinto> ivoks, why is it not ok on that condition ?
<ivoks> but it's just wasting space :)
<Keybuk> ivoks: no it's not
<cjwatson> so this sort of debate is exactly why partman-auto weights things, so that if disk *is* short for some reason then it can adjust sizes as need be
<cjwatson> (frex you might have lots of RAM but be installing Ubuntu in a relatively small part of your disk that also has Windows on it
<cjwatson> )
<Keybuk> cjwatson: exactly, which is why I think we should just retain whatever algorithm or heuristic we have today
<cjwatson> as I say that doesn't work terribly well once swap is no longer a partition
<Keybuk> that's an implementation issue with your code ;)
<cjwatson> I can't think how to retain it easily, although I'm willing to keep trying
<cjwatson> I acknowledge that it is an implementation issue
<cjwatson> that doesn't make it go away, sadly :)
<Keybuk> well, at some point you must have <size of space available to Ubuntu>
<Keybuk> and divide that into <size of space for disk> and <size of space for swap>
<Keybuk> ?
<cjwatson> according to a partitioning recipe that might well be considerably more complicated than that (and often is for people customising Ubuntu)
<Keybuk> right
<Keybuk> so instead of making a partition with the number, you just make a file
<cjwatson> what, you're suggesting having a file declared in the recipe?
<Keybuk> sure
<Keybuk> it's a file that ends up in /etc/fstab after all
<cjwatson> I suppose that might work but is probably no less effort :-)
<Keybuk> and I suspect you write fstab from that bit of code as well
<cjwatson> I'd been hoping to avoid that
<cjwatson> sort of
<Keybuk> of course, implementing file partitioning would allow you to do all sorts of things in the future
<cjwatson> basically the recipe format is not very flexible right now and in particular has problems with the concept of nested devices
<Keybuk> like encrypted files mounted somewhere and suchlike
<cjwatson> well, we have a hacky approach to loop-mounts for wubi
<cjwatson> but it isn't embedded in the same recipe format :(
<cjwatson> it all needs to be reworked ...
<cjwatson> I suppose we could do something like
<cjwatson> 96 512 300% linux-swap method{ swap } format{ } file_name{ /swapfile } on_mountpoint{ / } .
<cjwatson> and when creating partitions we add together the sizes for everything with matching on_mountpoint
<TheMuso> pitti: The original tarballs are different, due to ubuntu moving to the new upstream version before Debian, and upstream using bz2 tarballs. Once Debian has a newer orig tarball, things will be synced.
<pitti> TheMuso: right, I understand; just suggesting to call them build1, so that they'll get autosynced
<pitti> TheMuso: just a nitpick, don't worry
<TheMuso> pitti: Fair enough, point taken.
<pitti> TheMuso: BTW, isn't it in the middle of the night for you?
<RobertF> Hello
<RobertF> Where can I ask a question about Ubuntu 9.10 (alpha2)?.
<Pici> RobertF: #ubuntu+1
<robbiew> whois pere
<robbiew> whoops :P
<mdz> Jun 16 10:35:47 mizar kernel: [1292114.416048] end_request: I/O error, dev fd0, sector 0
<mdz> I wonder which process triggered that...
<Pik0r> do you include MIT-licensed software in your repositories, too?
<Pik0r> or only GPL'd?
<pochu> MIT is fine
<directhex> Pik0r, any license meeting the ubuntu free software guidelines, which are like the debian free software guidelines with with a less hard-line approach
<hyperair> directhex: less hard-line approach how?
<directhex> hyperair, afaik non-used non-free stuff in source tarballs can be gotten away with. but is frowned upon due to lack of synability
<hyperair> directhex: i see. synability?
<directhex> syncability
<Pik0r> directhex: any place where I can read up on the  ubuntu free software guidelines? I searched google and the only thing I can find are the debian ones.
<hyperair> ah
<cjwatson> the main (possibly even only) difference between the DFSG and our guidelines is that we're more lax about non-code material
<cjwatson> Pik0r: http://www.ubuntu.com/community/ubuntustory/licensing
<cjwatson> Pik0r: it's also in the Ubuntu Policy Manual: http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/
<Pik0r> thank you. flying over it, it looks like even closed source software is fine, as long as it can be freely distributed. is this assumption correct?
<Pik0r> (would be placed in restricted then)
<directhex> Pik0r, restricted or multiverse, yes
<hyperair> i think you can ship stuff like that in debian under non-free
<Laney> really?
<hyperair> is it not?
<Pik0r> any how is decided whether to include a closed/open source program or not? clearly you cannot include all software there is.
<Pik0r> is this based on popularity?
<Laney> I guess binary drivers
<hyperair> Pik0r: popularity, and if you can package it.
<Laney> Pik0r: Someone willing to maintain it
<Laney> Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists).
<cjwatson> Pik0r: restricted is only for non-free drivers
<cjwatson> Pik0r: Mark has given us very clear guidance that non-free applications are not to be supported by Ubuntu
<cjwatson> i.e. not in restricted and certainly not in main
<seb128> cjwatson: do you know what 003_gdk.pc_privates does exactly in gtk?
<seb128> cjwatson: I think you had installer issue when it was not used correctly previous cycle
<seb128> I'm wondering if that's still required
<mdz> aha
<mdz> root      6987  0.0  0.0   3544  1024 ?        S    10:34   0:00 hald-addon-storage: no polling on /dev/fd0 because it is explicitly disabled
<mdz> root     29159  0.0  0.0   5724   760 ?        S    15:42   0:00 devkit-disks-daemon: polling /dev/sr0 /dev/sr1 /dev/fd0
<pitti> mdz: bug 384469 ?
<ubottu> Launchpad bug 384469 in devicekit "constantly polls floppy drive" [Unknown,In progress] https://launchpad.net/bugs/384469
<mdz> pitti: indeed, thanks
<al-maisan> hmm .. building zsh on lpia fails due to the non-availability of libcap2-dev (http://launchpadlibrarian.net/27991987/buildlog_ubuntu-karmic-lpia.zsh_4.3.10-2ubuntu1_MANUALDEPWAIT.txt.gz)
<al-maisan> how is something like this resolved?
<dholbach> al-maisan: seems like the last upload of libcap2 failed on lpia: https://edge.launchpad.net/ubuntu/karmic/+source/libcap2/1:2.16-5
<dholbach> http://launchpadlibrarian.net/27714759/buildlog_ubuntu-karmic-lpia.libcap2_1%3A2.16-5_FAILEDTOBUILD.txt.gz
<superm1> slangasek, can you re-enable mythbuntu dailies?
<al-maisan> dholbach: thanks for the info.
<dholbach> al-maisan: TBH no idea why it breaks
<directhex> congrats stgraber
<al-maisan> yeah .. I had a brief look as well .. it looks like the /usr/include/asm/sigcontext.h file is broken ..
<persia> al-maisan, Don't fuss about lpia failures.  Once the spec gets written up, lpia will get lots less well supported.
<al-maisan> persia: good to know, thanks :)
<cjwatson> seb128: the breakage was that the gtk directfb udeb was linked against cairo-xlib
<cjwatson> which is incorrect
<cjwatson> seb128: oh, or it may have been that other things built against gtk/gdk directfb linked against cairo-xlib - actually I think that's what it was
<cjwatson> seb128: so build gtk, build cdebconf against new gtk, see what the linkage of stuff in cdebconf-gtk-udeb is
<seb128> ok thanks
<seb128> I think it's fixed in the new version
<seb128> they build against cairo-$backend now
<seb128> ie gtk-directfb depends on cairo-directfb
<cjwatson> that wouldn't surprise me, I seem to remember that getting upstream activity
<cjwatson> worth checking the output .pc files by hand though
<seb128> yeah I will do that
<cjwatson> cheers
<seb128> +Requires: gdk-pixbuf-2.0 pango pangocairo gio-2.0 fontconfig cairo-directfb
<seb128> is the new version gdk-directfb-2.0.pc
<stgraber> directhex: thanks
<seb128> which seems correct to me
<seb128> lool: ^ if you want to double check after your meeting
<cjwatson> seb128: *looks* ok
<ogra> stgraber, hmm, looking at bug 357429, how do you make sure the dirs get deleted properly ?
<ubottu> Launchpad bug 357429 in ltsp "Using ldm, the user is unable to lock its Xauthority file making some applications to freeze/fail" [High,Fix released] https://launchpad.net/bugs/357429
<slangasek> superm1: done
<superm1> thanks
<mterry> kees: When you get a sec, can you talk to me a bit about the details of bug 255635?  I don't quite get the changelog entry.  I'm working on rsyslog and want to make sure it's not affected
<ubottu> Launchpad bug 255635 in sysklogd "Kernel messages not logged to /var/log/kern.log" [High,Fix released] https://launchpad.net/bugs/255635
<kees> mterry: sure!  basically, glibc and sysklogd fought with eachother over the definition of syslog()
<kees> mterry: when compiling under Ubuntu, -D_FORTIFY_SOURCE=2 is defined, which causes glibc to add additional protective macros.
<kees> mterry: one of those is for syslog(), so when klog.c compiled, it ended up getting its syslog calls redirected to glibc
<kees> mterry: but it had it's own version of syslog() that allowed for kernel messages to be inserted.  the glibc one doesn't allow that.
<kees> mterry: so, kernel messages went silent.
<mterry> kees: I see...  So as long as rsyslog doesn't define its own syslog(), there shouldn't be that specific conflict
<kees> mterry: right.  I would just carefully examine how kernel messages are handled, or at least verify they're still being reported at and after boot time.
<mterry> kees: Right.  OK.  I'll play with it, but basically, at the end of the day, as long as kern.log is filling up, I'm happy, eh?
<kees> mterry: yup
<mterry> kees: Cool, thx
<kees> mterry: though note that there might be a difference between "catch up"(flushing the ring-buffer from before syslog started) and "live" kernel log reporting.  testing both should be sufficient.
<mterry> kees: OK
<lool> seb128: I think the issue is with pango .pcs IIRC
<seb128> lool: the patch I'm talking about is the gtk one though, do you think it's still required?
<lool> I would patch the gtk+ configure script heavily to workaround the very specific namings of cairo .pcs in Debian in the past
<cjwatson> mterry: I looked at the rsyslog source briefly during the UDS session, and it appeared that it might well have the same problem
<lool> seb128: Hmm the part I'm talking about was dropped completely from the Gtk+ package (see 2.10.3-1), so that's probably something else
<cjwatson> mterry: but I didn't actually try it, so I left that link in the spec as a warning
<mterry> cjwatson: I'm thinking it may not have the same problem, but I'm not done investigating
<Pik0r> cjwatson: " Mark has given us very clear guidance that non-free applications are not to be supported by Ubuntu" ... just not supported, or even not to be offered?
<Pik0r> cjwatson: and do you mean by 'free' 'open source'?
<pitti> Pik0r: making them available in multiverse is okay (as long as we are allowed to ship them), but not restricted (which is the supported subset of non-free sw)
<slangasek> pitti: anacron postinst> doesn't this miss the case of reinstalling the package when it's in "config files" state, since then only the preinst is told the previous version number, not the postinst?
<pitti> slangasek: oh, really? I didn't know that
<mterry> cjwatson: Would the rsyslog change be affected by the FeatureDefinitionFreeze?  It needs an MIR still, so it seems like it fits the "updates to be landed in main" clause
<pitti> slangasek: so most-recently-configured-version is empty if you reinstall a previously removed package?
<slangasek> pitti: I believe so, yes
<pitti> hm, so that stuff needs to move to preinst then, I figure (which is a bit ugly, but *shrug*)
<cjwatson> Pik0r: not supported as in "not to be in the main or restricted components". And "free" is essentially synonymous with "open source" here, yes.
<cjwatson> mterry: that means that the feature must be on the list, not that the package must be in main
<cjwatson> I think I've mentioned rsyslog in a release meeting and nobody had a heartattack
<mterry> cjwatson: OK, heartattacks may not be the best threshold, but I get ya.  ;)
<tgpraveen1> why does jaunty ppa still have banshee 1.4.3
<tgpraveen1> why isn't it upto 1.5 series
<directhex> tgpraveen1, even numbered are stable releases, odd for unstable releases
<directhex> tgpraveen1, i.e. banshee-unstable-ppa for 1.5 series
<tgpraveen1> directhex: yeah I just found the unstable ppa
<tgpraveen1> thanks
<thebloggu>  Some time ago my ubuntu installation somewhere on boot jumps to verbose mode, as well as it is taking much longer to boot now than before. It doesnt seem there are any errors
<cjwatson> thebloggu: usplash has a timeout - if something takes too long then it'll cancel the splash screen on the grounds that something is clearly weird and you might like to be able to see what
<thebloggu> cjwatson, it seems (from my search on google) it has something to do with the size of swap partition
<thebloggu> http://ubuntuforums.org/showthread.php?t=901254
<thebloggu> it goes verbose exactly on "reading files needed to boot"
<cjwatson> I don't think that's a sound inference
<cjwatson> sure, it's worth checking, but that's not enough data to say that it's swap
<cjwatson> and that forums post is about the swap partition's UUID, not its size
<thebloggu> i upgraded xp to vista in the meantime, but didnt touch the ubuntu or the swap partition
<cjwatson> type 'swapon -s' in a terminal
<cjwatson> (incidentally why is this on #ubuntu-devel?)
<cjwatson> if you see a line starting with /dev, then that forums post is unlikely to be your problem
<thebloggu> Filename				Type		Size	Used	Priority
<thebloggu> thought of asking here since the main ubuntu channel is too noisy and normally they help better with smaller/easier to solve problems
<Chipzz> thebloggu: wrong reasoning; this channel is not an overflow channel for #ubuntu
<thebloggu> Chipzz, i know, i'm sorry for that
<thebloggu> the truth is here i could get someone to listen to me and help
<thebloggu> and asked 4 times there
<thebloggu> with no response whatsoever
<stgraber> ogra: the exact same way we used to remove the ldm-xauth file
<thebloggu> cjwatson, http://pastebin.com/mf6f9d6a should i edit the resume file to the swap uuid on top?
<cjwatson> thebloggu: I'll help if you promise to use #ubuntu+1 in future ;-)
<cjwatson> or #ubuntu, or some non-IRC forum
<thebloggu> cjwatson, sorry but no :P i'm on jaunty not karmic
<thebloggu> but yes
<thebloggu> i'll do it
<cjwatson> ok. yes, you need to change /etc/initramfs-tools/conf.d/resume, and you probably also need to change /etc/fstab.
<thebloggu> cjwatson, once again, i'm sorry for the trouble, i know this channel is for development
<thebloggu> cjwatson, thanks, i'll reboot to see if it works, i'll come back in a minute to tell you if it worked
<cody-somerville> jcastro, ping
<thebloggu> cjwatson, it worked
<thebloggu> thank you very much
<cjwatson> ok, good
<cjwatson> it's a bug that swap resize changes the UUID
<jcastro> cody-somerville: yo
<Laney> Is there a wiki page on editing grub2 configurations? I need to add a devicemap to my windows line
<thebloggu> cjwatson, that's one of the reasone i came here too, but after seeing that post thought it wasn't a bug
<cody-somerville> jcastro, Is there any way Xubuntu could get in on your upstream bug reporting stuff?
<thebloggu> cjwatson, should i submit a bug somewhere?
<thebloggu> reasons*
<jcastro> cody-somerville: yeah right now it's by open bug, so the buggier it is the better. People have been telling me they want it broken down by team level
<jcastro> cody-somerville: which I think makes sense, depends on getting lp manhours on it
<cody-somerville> jcastro, Would we just be able to add the xfce related packages to the report for now?
<jcastro> cody-somerville: a motivated person could grab the links to the numbers (which are just lp queries) and make a page that is similar, which is what I would recommend
<jcastro> cody-somerville: yeah just take an existing query (after you click on it) and replace it with the package you want
<jcastro> cody-somerville: a seperate page with the same queries would probably be easier to do, the lp team are kind of booked for a while. :-/
<cody-somerville> jcastro, I can make the necessary code changes if need be.
<cody-somerville> jcastro, but you're saying I can make my own https://edge.launchpad.net/ubuntu/+upstreamreport ?
<jcastro> cody-somerville: I am saying you can just make a people.u.c page or something if you want to whip it up.
<jcastro> cody-somerville: but if you want to branch and fix +upstreamreport I won't complain!
<jcastro> cody-somerville: gmb would be the person to talk to about that
<jcastro> if there were a way to make it so we can have team-specifc ones (server, desktop, xubuntu, etc.) that would be much more useful
<cody-somerville> jcastro, Where can I find the code if I wanted to setup a people.u.c page for Xubuntu packages?
<jcastro> gmb would know
<jcastro> I don't really know anything about lp or it's internals, I just tell gmb what we want and then he goes off and implements it.
<jcastro> cody-somerville: mail him and CC me and I will help you with this
<cjwatson> thebloggu: yeah, probably, on the parted package in Ubuntu
<cjwatson> Laney: could just wait for the next update :)
<AnAnt> will tomboy & fspot still be installed in Ubuntu desktop by default ? or will they be replaced with non-Mono alternatives ?
<Laney> cjwatson: that's going to fix it? i.e. set the drivemap correctly or make the configuration easier to edit?
<cjwatson> Laney: it'll set it correctly by default
<Laney> ah fair enough
<cjwatson> AnAnt: I don't know of any plan to remove them
<Laney> I just edited it by now
<ebroder> So anybody with main bits who could look at bug #362691?
<ubottu> Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Medium,Confirmed] https://launchpad.net/bugs/362691
<cr3> how can I set the proxy for apt to access packages under https? it seems that Acquire::https::Proxy either doesn't exist or doesn't work
<robbiew> Keybuk: did we ever get the benchmark results for the i586 rebuild for foundations-karmic-i586-support?
<`26> glGetInfoLogARB omits line numbers and file name from error messages, am I doing something wrong? [platform: ubuntu 9.04 + Intel graphics card]
<`26> Okay, xserver-xorg-driver-intel does NOT report GLSL compilation line numbers and file names, which makes debugging quite virtually impossible.
<`26> I tested with a nearby computer who has a nVidia card, and at least their driver, although closed-source, reports line numbers.
<TheMuso> pitti: I was just heading to bed at the time, and jumped on to check something. :)
<Sarvatt> `26: i believe you mean mesa :D
<`26> Sarvatt: yes, I just ran a search for string "Syntax error" and it's really in package libgl1-mesa-dri.
<Sarvatt> you might want to try updating your mesa - https://launchpad.net/~xorg-edgers/+archive/ppa
<`26> This is a pretty bad problem, since the GLSL specification document says that Implementation *must* provide line numbers and filenames in log.
<`26> sure
<Sarvatt> looks like it was fixed in mesa 7.4.3
<`26> Sarvatt: good trying ppa right now
<`26> Packages installing, /me is saying his prayer.
<`26> be right back
<cr3> if I run apt-get update on a sources.list containing https repositories on karmic, I get:  server certificate verification failed. when I try on jaunty, it works just fine. any ideas what might be wrong?
<`26> Sarvatt: I installed all packages in the PPA you gave me. X wouldn't start anymore, so I downgraded xserver-xorg-* and left everything else the same. Problem was not fixed, still no line numbers in GLSL log output.
<cr3> nevermind, the problem was that the clock on the client was offset by too long... I really need to run ntpdate
<Sarvatt> do you have a 965 or newer?
<`26> lsmod says i915, otherwise IDK
<Sarvatt> what does glxinfo | grep Intel say?
<`26> OpenGL renderer string: Software Rasterizer
<`26> err that can't be right
<`26> Should I downgrade everything to what it was?
#ubuntu-devel 2009-06-17
<`26> Your silence is approbative.
<directhex> and ablative, and subjunctive.
<Sarvatt> i'm sorry, wasnt looking at this channel. if you don't want to figure out why X wont start with those packages to use the newer stuff what other option do you have besides downgrading things back? anything older than i965 doesn't have GLSL support by the way, which is why I was asking
<`26> Sarvatt: GLSL runs just fine here, I tested with qsharededit.
<`26> *qshaderedit
<Sarvatt> in swrast yeah
<`26> Sarvatt: it didn't use any CPU in the Mandelbrot example -- also, the extension for shader program appears in glxinfo (when used against some DRI libraries that actually work)
<Sarvatt> you saw GL_ARB_vertex_shader and GL_ARB_fragment_shader, or just GL_ARB_fragment_program and GL_ARB_vertex_program?
<Sarvatt> lspci | grep Display
<`26> Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
<`26> I'm not done downgrading yet, apt is being strange.
<Sarvatt> ah should be ok then, after you downgrade it would probably be best to ask over in #dri-devel
<`26> Sarvatt: Mesa DRI Mobile IntelÂ® GM45 Express Chipset GEM 20090326 2009Q1 RC2
<stgraber> ogra: any chance you're still around this late ?
<Tonio_> ca m'output ca :
<Tonio_> anyone using gnome over karmic could tell me the output of this command please ? pkg-config --print-errors --short-errors "gtk+-2.0"
<Sarvatt> Package @GDK_PRIVATE_PACKAGES@ was not found in the pkg-config search path.
<Sarvatt> Perhaps you should add the directory containing `@GDK_PRIVATE_PACKAGES@.pc'
<Sarvatt> to the PKG_CONFIG_PATH environment variable
<Sarvatt> Package '@GDK_PRIVATE_PACKAGES@', required by 'GDK', not found
<cjwatson> Tonio_: no output
<cjwatson> oh, well, I last upgraded this afternoon
<Sarvatt> was 2 gtk+ updates today, second one hasnt been published yet
<Tonio_> cjwatson: hum ok I'll test the second one... I get a strange issue, and since I know nothing about gtk...
<cjwatson> $ dpkg-query -W libgtk2.0-dev
<cjwatson> libgtk2.0-dev   2.17.0-0ubuntu1
<Tonio_> cjwatson: libgtk2.0-dev   2.17.2-0ubuntu1
<Sarvatt> https://lists.ubuntu.com/archives//karmic-changes/2009-June/002794.html
<Tonio_> cjwatson: the above command outputs me Package @GDK_PRIVATE_PACKAGES@ was not found in the pkg-config search path.
<Sarvatt> theres a 0ubuntu2 coming
<cjwatson> sounds like a fairly clear build snafu
<cjwatson> that's an indicator of the autotools not having been properly told to substitute something
<Tonio_> Sarvatt: thanks for the info, I'll wait and retest then...
<Tonio_> cjwatson: thanks for the help
<TheMuso> IdentityFile /home/luke/.ssh/work_rsa/c
<TheMuso> woops
<TheMuso> Fresh install of karmic, does evolution crash for anyone else?
<TheMuso> i.e no GUI comes up at all?
<pitti> Good morning
<Sarvatt> TheMuso: it works here
<TheMuso> Sarvatt: Interesting. THis is a fresh karmic install done today, and updated.
<TheMuso> pitti: Good morning.
<ajmitch> morning pitti
<StevenK> Morning pitti
<StevenK> pitti: I synced  opal a little while ago, and it wants celt :-(
<pitti> yay new versions
<StevenK> pitti: Yes :-(
<StevenK> pitti: Shall I file an MIR and beat you with it?
<pitti> s/you/anyone in MIR team/
<StevenK> pitti: Beating you is much more fun :-P
<pitti> pah
<iulian> Riddell: Hey.  I've just seen that you uploaded a new version of python-qt4 to Karmic.  Is there any reason why you didn't merge it with Sid?  The reason I'm asking is because git-cola currently FTBFS because of a simple wrapper for pyuic4 which is in Sid at the moment but not in Karmic.
<iulian> I'd like to have that wrapper script for pyuic4 in Karmic.  This could prevent other packages from FTBFS.
<iulian> Having said that, I'm not 100% sure that this is the reason why git-cola failed to build, but looking at the build log from Debian, there is no sign of failing.  So, I believe this is the reason why it failed to build in Karmic.
<TheMuso> c
<highvoltage> d
<iulian> Oh well, ScottK mentioned something about qscintilla(?) when I asked him about merging python-qt4 with Sid.  I don't know what he meant (/me hides).  Maybe he can give his opinion about this?
<iulian> ScottK: ^
<dholbach> good morning
<iulian> Morning Daniel.
<highvoltage> morning dholbach
<dholbach> hiya iulian, hi highvoltage
<StevenK> pitti: Bug #388285 for celt MIR :-)
<ubottu> Launchpad bug 388285 in celt "MIR for celt" [Undecided,New] https://launchpad.net/bugs/388285
<pitti> asac, lool: ^ time to have a look?
<pitti> jamesh: \o/ debian bug 532757
<ubottu> Debian bug 532757 in erlang "erlang-base: Contains debug information which makes the package" [Unknown,Closed] http://bugs.debian.org/532757
<jamesh> pitti: cool.  The rabbitmq-server packages in Debian have also been updated with reduced dependencies now.
<jamesh> so I guess the only erlang package specific delta we're carrying w.r.t. Debian is the libmozjs one in couchdb
<jerroome> Hi, can anyone tell me how to manage the case where 2 packages procduced by myself have conflicts because they copy a file at the same location.
<lifeless> jerroome: don't do that.
<jerroome> secondly, is anyone able to tell what the reversed slot is for
<StevenK> Reversed slot?
<jerroome> inside the control file, there is a slot called rdepends
<jerroome> sorry, I meant rdepends, not reverse slot
<jerroome> why not doing that
<jerroome> ?
<StevenK> There shouldn't be, that can be determined by the archive
<slangasek> (and can't be determined by the package itself)
<jerroome> ok
<jerroome> and why not writing at the same location with 2 different packages
<jerroome> .
<jerroome> ?
<Hobbsee> because it's the equivalent of parking two cars on top of each other.
<slangasek> turning the question around: why do you think this is something you *want* to do?
<jerroome> should I create a third package and set the two others dependend on that one ?
<slangasek> if it's the same exact file, then yes, definitely
<slangasek> that, or have one of the packages depend on the other, if that's a reasonable thing to do
<jerroome> no it isn't because there aren't necessary 2
<jerroome> there can be one or n
<jerroome> I'm developping software to run on axel terminals
<jerroome> sorry, which should also run on terminals
<jerroome> sometimes, there can be a few terminals
<jerroome> and I need one package per system to run
<jerroome> because, I have to be able to add and remove easily one machine
<jerroome> I have trouble to explain everything in english
<jerroome> ..
<jerroome> I will make a third package
<jerroome> thank you guys, once again, I got an answer quite fast .. :)
<pitti> meh, seems gcc went crazy on the ports? I get a lot of "configure: error: C compiler cannot create executables
<pitti> doko: ^
<al-maisan> pitti: probably the recent binutils upload?
<pitti> could be
<al-maisan> pitti: from a recent perl build on sparc:
<al-maisan> sh: gcc: not found
<pitti> I saw it on libsoup2.4 and gnome-games
<al-maisan> here's the relevant snippet from the build log: http://pastebin.com/m4f1ff8c4
<seb128> pitti, not only on port, I got the same issue for gtk on armel
<pitti> seb128: me too
<reduz> Hi guys, question! does anyone here know if there is a way to get opengl 3.1 nvidia drivers working on ubuntu?
<Riddell> hi  iulian
<Riddell> I didn't see anything  in debian's svn for that package that was new, but let me look again
<asac> hmm ... getting /usr/lib/gcc/powerpc-linux-gnu/4.4.0/../../../../lib/crti.o: could not read symbols: File format not recognized
<asac> thats probably known?
<Tallken> ft
<Tallken> ups soz
<asac> doko: ^^
<mok0> Would someone please request a give-back on libdc1394-22 ?
<mok0> It's clogging up the pipeline
<Hobbsee> karmic, all arches?
<mok0> Hobbsee: yes
 * Hobbsee blinks at this new stuff
<mok0> Hobbsee: what new stuff is that?
<Hobbsee> neat
<Hobbsee> mok0: the credential stuff for ubuntu-dev-tools
<mok0> ah
<lifeless> API's
<Laney> we got a bug telling us off for that recently
<Hobbsee> Laney: why so?  although it would be nice if the man page were finished
<Hobbsee> in particular, the part about what consumer is
<Hobbsee> and what it should be set to
<Laney> Hobbsee: It can send http requests to LP to login on your behalf, which is naughty
<mok0> Hobbsee: thx, I see it's building now!
<Hobbsee> Laney: well, there is that
<Hobbsee> Laney: does it log in properly?  ie, both to production and edge?  :D
<Hobbsee> mok0: you're welcome
<Laney> Hobbsee: I didn't even know it could do this actually. I didn't pass my credentials and it spawned a browser for me to login there.
<Laney> that's the Proper OAuth Way isn't it?
<Hobbsee> Laney: i'm not sure - but i would expect that's the sane solution
<Laney> check out th ebug for a detailed analysis if you're curious
<wgrant> Laney: That is the Proper Way, yes.
<Hobbsee> i'm suer that will further stop me from studying for exams :(
<wgrant> ie. you only ever give your Launchpad password to Launchpad.
<wgrant> Not some nasty script written by those malicious Ubuntu developers.
<Hobbsee> after all, they might take over your sysetm
<Laney> they talk about writing some CLI clients to do this auth for you because doing the context switch to a web browser is undesirable
 * Laney didn't think it was that bad
<mok0> Hobbsee: Hm, the rebuild didn't succeed. I don't understand it, the dependency it claims is missing, is there
<wgrant> mok0: Log?
<mok0> https://edge.launchpad.net/ubuntu/karmic/+builds?build_text=libdc1394-22&build_state=all
<mok0> I just built the package successfully right here ?!?!!
<wgrant> mok0: ogre-model
<cjwatson> libdc1394-22 is in main
<wgrant> The dep is in universe.
<mok0> ah
<bigon> Hi I think that libchamplain and geoclue must go to main if we want geoloc in next empathy release
<mok0> wgrant: so should I request a move to universe?
<wgrant> mok0: That doesn't sound like a very good idea.... stuff in main probably depends on it.
<mok0> wgrant: well, that's no good if it doesn't build
<mok0> request libusb-1.0-1 -> main then
<ogra> write a MIR for the dep ? or fix the package to not dep on it ?
<directhex> do i need to explicitly ask for something to drop to universe?
<ogra> directhex, only if its seeded, else it should move on its own if all dependencies are gone
<pitti> directhex: if it appears on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt, then no
<pitti> directhex: if it doesn't appear there and needs to be unseeded, then please file a bug against ubuntu-meta
<pitti> or ping here
<pitti> hm, wget --no-check-certificate -O- 'https://wiki.kubuntu.org/Kubuntu/Todo/Karmic?action=raw' gets me a 403
<directhex> pitti, will do. i need a package uploaded to debian before i can realistically do it
<tkamppeter> pitti, I want to prepare the SRU for CUPS, but there is no reference to the repo for Jaunty.
<tkamppeter> Seems that LP has lost connection to the repos.
<directhex> pitti, this change also removes a circular build-dep (yay)
<pitti> tkamppeter: it's lp:~ubuntu-core-dev/cups/jaunty/
<pitti> tkamppeter: (as Vcs-Bzr: says)
<tkamppeter> pitti, there is no reference on https://code.launchpad.net/ubuntu/jaunty/+source/cups to any repo. Could they get added?
<pitti> tkamppeter: no, those are package branches
<pitti> tkamppeter: but they aren't intended to be used for the debian/ only bzr trees we currently have
<pitti> so they remain on https://code.launchpad.net/cups for now
<pitti> tkamppeter: eventually we'll use the package branches, but it's currently in a transition period
<gaspa> is there some plan to change from usplash to plymouth in ubuntu as well?
<ogra> seb128, the new padding in the listview of the latest evo looks weird
<ogra> gaspa, no
<Keybuk> kees: you never committed upstart 0.3.9-8 to bzr
<Keybuk> damn you
<Keybuk> *shakes first*
<Keybuk> :p
<Keybuk> err, fist
<Keybuk> argh, worst still you patched the source directly
<Keybuk> meh
<ogra> debdiff ftw :)
<gaspa> ogra: not at all? or simply "hasn't been talked about"?
<Keybuk> actually, I'm trying to figure this mess out ;)
<ogra> gaspa, the plan is to boot fast enough to not require any splash
<Keybuk> source packages in revision control make everything such hard work
<ogra> yeah
<gaspa> ogra: ah, wow. :)
<gaspa> thanks
<ogra> there will be cases where you cant be fast enough, i.e. fsck or encrypted homedirs, where usplash will kick in
<ScottK> iulian: Look at the eric bugs in Ubuntu (I mis-remembered).
<billisnice> If you guys add click2try please make sure it can be disabled in services. I do not want the office staff to have access to it.
<billisnice> I would like to see a service that is diabled not to show in the menus. Be totallly gone so not to try.
<iulian> ScottK: Aha, OK, thanks.  I believe Riddell is looking into it as well.
<iulian> It's worth having that wrapper script for pyuic4 in Karmic.
<Laney> billisnice: what is quick2try exactly? I can't figure it out from their website
<Chipzz> billisnice: how about uninstalling it then?
<Keybuk> configure: error: C compiler cannot create executables
<Keybuk> ...err,,,
<pitti> Keybuk: all builds on ports fail today, probably binutils wreckage
<Keybuk> oops ;)
<seb128> not only port, armel fails the same way
<seb128> only i386, amd64 and lpia are building
<pitti> anyone happens to have experience with wiki downloading?
<pitti> wget -O- 'https://wiki.ubuntu.com/Kubuntu/Todo/Karmic?action=raw' just gets me a 403
<pitti> hm, seems it's just wget acting up. urllib works fine
<liw> hm, I used requestsync and now I don't know what happened to the request
<liw> the request bug should be filed against the source package, right? (speedcrunch in this case)
<ion_> liw: Btw, even though the clientside processing overhead is not considered for karmic (re: apt-sync), since youâll set up a benchmarking environment, might as well benchmark the extra CPU time for each method. That information will be useful in the future. :-)
<cjwatson> liw: yes
<RainCT> Out of curiosity, is Karmic following Debian with the section changes?
<cjwatson> we already did
<RainCT> ok, cool
<cjwatson> though we haven't actually gone through all the packages and changed the sections - but the archive supports the new sections
<liw> ok, unless the mail requestsync generated is in some queue somewhere, the bug has completely vanished
<cjwatson> mails to LP should be processed every three minutes, normally
<cjwatson> maybe it's in some local mail queue?
<cjwatson> you could also try using the --lp option rather than relying on mail
<liw> the mail got accepted by mx.canonical.com about 25 minutes ago, so I doubt it is in a queue anymore
<liw> oh, there's an --lp option? why isn't it used by default? why mess with mail at all?
<Laney> the api is relatively new
<cody-somerville> Whats the process for applying to get upload permissions to a single package?
<cody-somerville> ie. I want to get upload rights to dput in main
<liw> bah. "launchpadlib.errors.HTTPError: HTTP Error 401: Unauthorized"
<cjwatson> manage-credentials, I think
 * liw decides requestsync is not worth the trouble
<cjwatson> cody-somerville: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package%20Uploaders
<cody-somerville> cjwatson, thanks
<liw> I've done manage-credentials once already. If it needs doing multiple times: not worth it.
<billisnice> chipzz: The folks in my office do not understand uninstall, etc. They just want it to work. Millions just want it to work.
<RainCT> liw: Running it once should be enough; seems like there's something wrong if that doesn't work
<liw> RainCT, well, yes
<Riddell> iulian: I don't understand what the wrapper script is for, there's already a /usr/bin/pyuic4 script
<iulian> Riddell: Hmm, take a look at this build log: http://launchpadlibrarian.net/27856034/buildlog_ubuntu-karmic-i386.git-cola_1.3.7.45-2ubuntu1_FAILEDTOBUILD.txt.gz
<iulian> /usr/bin/pyuic4: 1: import: not found
<cjwatson> somebody forgot a #! line?
<iulian> cjwatson: I don't think so, where?
<Riddell> cjwatson is right, the upstream /usr/bin/pyuic4 has no #! line
<cjwatson> iulian: if pyuic4 is a python script then it should have #! /usr/bin/python at the top ...?
<iulian> Oh, right.
<liw> Riddell, fyi #388450 (speedcrunch merge/sync)
<Chipzz> billisnice: I was thinking you would be the one installing those pcs...
<billisnice> we have 30 office puters
<billisnice> i do not know that much either
<billisnice> just enough to mess it up
<Riddell> iulian (cjwatson): I see, our package uses the upstream module and puts it in /usr/bin which doesn't work.  debian has that wrapper script instead so I'll change to what debian is doing
<Riddell> liw: excellent, thanks
<iulian> Riddell: Yea, that should do it, thanks.
<Chipzz> billisnice: ... ...
<Chipzz> billisnice: also, why are you talking about that here?
<ogra> Chipzz, because you respond ?
<ogra> :)
<Chipzz> ogra: oh you mean I should tell him in my usually subtle way to read the fine topic? :)>
<Chipzz> s/usually/usual/
<billisnice> i thought developers were in here
<billisnice> maybe not
<ogra> billisnice, yes, developers are in here, discussing development issues of developing ubuntu :)
<billisnice> i though it would a nice feature to add for us non tech folks, that is why i asked here....
<Hobbsee> billisnice: there are a lot of nice featues that could be added.  Fotunately, there's a great place to collate them, and that's brainstorm.ubuntu.com.  You might want to try there, as irc really doesn't make a good todo list
<ogra> beyond that i didnt see and question yet ...
<ogra> "<billisnice> If you guys add click2try please make sure it can be disabled in services. I do not want the office staff to have access to it." .... doesnt really look like a feature request or something
 * Chipzz wonders if someone can disable sth in services, why he can't uninstall it...
 * ogra wonders what click2try is 
<Chipzz> but I suppose that would just be me
<Chipzz> ogra: that too :)
<billisnice> i will look for that site. I am in the real world of using Ubuntu for business. We do not understand or have time to understand the tech stuff.  lol
<billisnice> i am on vac for a few weeks...and enjoy ubuntu
<Chipzz> billisnice: you have it the wrong way around. click2try offers ubuntu. ubuntu doesn't offer click2try
<Chipzz> now unless you can point us to a click2try package in the ubuntu repositories, I suggest you take the issue elsewhere
<Pici> If you just want to chat about Ubuntu, you can join #ubuntu-offtopic, but the -devel channels are for actual development issues :)
<billisnice> i do not understand lots for sure, but to not show services turned off in the menus leave no confusion of what you can and can not do...just a wanted feature for non tech folks.
<Chipzz> billisnice: again, point us to the package which would be causing problems
<Chipzz> I suspect there is none
<billisnice> http://www.ereleases.com/pr/click2trytm-helps-users-run-ubuntu-open-source-catalog-21839
<Chipzz> billisnice: did you even READ that????
<Chipzz> FIRST sentence:
<Chipzz> "click2try (http://www.click2try.com) today announced the availability of Ubuntu 8.04 (http://www.ubuntu.com) in its online catalog of virtualized Open Source applications."
<billisnice> ok
<billisnice> na
<billisnice> just saw it
<Chipzz> analyze the grammar
<Chipzz> analyze the vocabulary
<Chipzz> and tell me how this does concern the ubuntu developers?
<Hobbsee> nice idea, though.  Totally irrelevant to here
<billisnice> i am just a dumb butt for sure
<billisnice> lol
<billisnice> i do like ubuntu
<cjwatson> billisnice: services are usually servers, rather than anything that might appear in the menus
<cjwatson> if you mean as in System -> Administration -> Services
<billisnice> ok, thanks
<cjwatson> very few things there are at all tightly bound to a menu item
<cjwatson> and in the cases where they are, it's usually in a client/server kind of way where the service is not necessarily on the same machine as the clients which would have the menu items
<kees> Keybuk: iirc, upstart's tree was only writable by you at the time. :P
<Keybuk> kees: not only that, but the source is missing from it anyway
<Keybuk> so it has changelogs but no patches
 * Keybuk deleted the tree
<kees> Keybuk: heh
<kees> Keybuk: making a core-dev branch for it?
<Keybuk> kees: will do so at some point
<Keybuk> though it's kinda hard
<Keybuk> the core-dev branches are supposed to be buildable from a checkout
<Keybuk> but I'd kinda like it to be branched off the upstream branch
<Keybuk> which doesn't make things like configure in it ;)
<kees> Keybuk: how about a get-orig-source build target?
<cjwatson> Keybuk: like many things, James has a plan for that ;-)
<cjwatson> (tarball branches)
<pitti> Keybuk: or we just give in and call autoreconf in debian/rules; many packages do that, after all
<pitti> (I don't particularly like it, but it's practical for git snapshots)
<Keybuk> cjwatson: with an easy tool to update the tarball branch?
<cjwatson> I'm not sure I've ever seen james_w do something that *didn't* involve writing a bzr plugin that anyone could use
<cjwatson> (aka yes)
<Riddell> asac: some MIRs assigned there for you.  feel free to take bug 374973 too although kees was looking at it last
<ubottu> Launchpad bug 374973 in enca "main inclusion report enca" [Undecided,New] https://launchpad.net/bugs/374973
<asac> Riddell: did you use "assign" or subscribe?
 * asac wonders whats up with his procmail rules ... no mails about thos MIRS in his "assigned" folder
<Riddell> asac: subscribe
<asac> Riddell: hmm ... my subscribed mailbox is currently under construction ;)
<asac> do you have bug ids at hand? ;)
<Riddell> asac: now assigned
<asac> great
<asac> thx
<kees> asac: feel free to snag enca.
<kees> i won't be able to check mir until later this week
<mok0> Huh?? configure: error: C compiler cannot create executables
<mok0> That's quite problematic for a compiler...
<hyperair> mok0: the compilers sure seem to hate you recently
<mok0> hyperair: they do
<hyperair> heh
<slangasek> it's a known problem
<cjwatson> same binutils thing we were discussing earlier no?
<slangasek> everything's FTBFS on the ports
<hyperair> ouch
<slangasek> cjwatson: made any progress on that, beyond definitively blaming binutils? :)
<cjwatson> not I, didn't know I was on the hook
<MacSlow> what's the package-name again of the https apt "thing"?
<MacSlow> sorry for the lack of a better word
<slangasek> cjwatson: you're not, but I thought you might know of some progress
<MacSlow> ah... apt-transport-https it is I think
<cjwatson> slangasek: I don't, I'm afraid; I can't even see a bug report
<cjwatson> binutils was uploaded about the time everything stopped building, that's all
<slangasek> no response from doko to the poking
<freinhard> hi!
<slangasek> doko: are you around?
<freinhard> pitti: fixed some bugs in kubuntu's install-package, all of them catch exceptions, so no new features, just fix crashes. can we get these into jaunty? see http://bazaar.launchpad.net/~jr/install-package/trunk/revision/21
<slangasek> al-maisan: did you reproduce the build failures on any of the porter boxes, and confirm that binutils is to blame?
<doko> slangasek: yes, arm and ia64 fixes are there, but not yet for sparc and powerpc
<al-maisan> slangasek: no, not yet.
<slangasek> doko: ok - staged on your side I guess, given that I don't see an upload?
<doko> still running test builds
<mok0> doko, give us  a poke when we can request give-backs
<mok0> I thought I read that hppa was going away?
<slangasek> mok0: would be more appropriate for the give-backs to be done centrally
<mok0> slangasek: ok
<ScottK> mok0: AFAICT, I think it's gone already.
<mok0> ScottK, I got one error like that during the last hour or so
<ScottK> mok0: (I mean hppa)
<mok0> ScottK, ah :-)
<mok0> ScottK, indeed, you are right. It's the sparc arch that's giving me troubles
<mok0> Translational brain error
<Riddell> iulian: new python-qt4 uploaded
<mok0> Things are changing. This is the error I get now: Checking for C Compiler ...  Error: no C compiler detected - cannot do anything
<slangasek> that's the same thing still
<iulian> Riddell: Excellent, ta.
<mok0> Isn't it possible to pause the buildds on the ports until things are back to normal?
<pitti> freinhard: please check which of the fixed bugs match the criteria on https://wiki.ubuntu.com/StableReleaseUpdates, request an SRU on them, and  and subscribe ubuntu-sru
<ScottK> mok0: IIRC it'd have to be stopped for all releases and not just the developement release, so that'd have an unfortunate affect on -updates/proposed and -backports.
<pitti> I think we'll just do a global retry on those
<cjwatson> I don't see a reason to pause the buildds - there seems to be a negligible risk of misbuilds here, it's just a certain amount of mails (which serve to remind us of the problem)
<shtylman> anyone having inkscape crash on them with an internal error? and no other info?
<mweichert> how is compiz called in gnome-session? I ask because I want compiz called with the following options --loose-binding and --indirect-rendering
<ccheney> anyone have a suggestion for something to mirror https deb packages besides lftp? lftp in karmic seems very broken and segfaults after a small amount of transfer for me every time
 * ccheney sees if it works for jaunty
<billybigrigger> colin?
<billybigrigger> !seen colin
<ubottu> I have no seen command
<joshk> is there a way to print something to tty0 even during a quiet boot?
<joshk> i've tried: stderr, and log_*_msg from /lib/lsb/init-functions
<joshk> i have this /etc/rc.local file that takes a while to run
<TheMuso> Good morning.
 * slangasek waves to TheMuso 
<slangasek> hmm, why is flash not talking to pulseaudio again here
<dtchen> if you're using flashplugin-installer, check ia32-libs.
<dtchen> fta: was the migration for libpulsecore* => libpulse0 done in ia32-libs?
<billybigrigger> dtchen::: ia32-libs needs to be installed for sound in flash?
<dtchen> billybigrigger: if pulse is configured to be active (which it is by default) using the 32-bit plugin and nspluginwrapper, yes
<billybigrigger> that's only if i installed via flashplugin-installer?
<dtchen> billybigrigger: if you're on 64-bit and installed via flashplugin-{nonfree,installer}, yes
<billybigrigger> hmm
<billybigrigger> i have met all the above requirements, still no sound
<soren> dtchen: Do you have any pointers on troubleshooting a system I have where anything involving gstreamer just gives me a sort of static, while mplayer for instance produces sound just fine?
<dtchen> soren: is pulse active?
<soren> dtchen: Or is that a bit too high up the stack for you? :)
<soren> dtchen: It's a fresh Jaunty install.
<soren> dtchen: With a Karmic kernel, though.
<dtchen> billybigrigger: hence my question above to fta; i haven't checked if ia32-libs has been updated
<hile> hmmh, why is alsa-plugins still dropping build dependency on libavcodec-dev - I understood this was a temporary problem with ffmpeg not being in main, but afaik all bits required for this ARE in main
<soren> dtchen: I've not activated nor deactivated pulse. Whatever is the default, that's what I got. :)
<billybigrigger> so once ia32-libs has been updated we should be looking for working sound in flash then
<dtchen> hile: ogra seems to be the last person to nudge/verify the libavcodec shipping (rather, not being able to be shipped) on cds issue
<hile> I'm not actually interested about a52 output myself, was just wondering the alsa jack output status and noticed this as well (yes I would be much happier if libjack-dev were in main)
<fta> dtchen: i have an updated ia32-libs in my staging PPA but it breaks flash, so i'm holding it for now, until we figure out why nspluginwrapper breaks with it.
<dtchen> fta: ok, thanks
<soren> dtchen: I see a pulseaudio process running, so I'm assuming that means "pulse is active".
<hile> dtchen, you mean a52 output is not supported because the libs don't fit to CDs? duh
<fta> dtchen, https://edge.launchpad.net/~fta/+archive/staging
<dtchen> soren: if you configure the GSt audio.*sink to use alsasink, is the static reproducible?
<dtchen> soren: if it's still reproducible, then you'd look at alsa-lib, specifically whether "speaker-test -c2 -Dplughw:X" corroborates the symptom
<dtchen> soren: if it's not reproducible, then you'd look at which sink (and its corresponding "volume") is chosen in pavucontrol
<dtchen> hile: no, there was a redistribution issue back in the hardy timeframe
<soren> dtchen: No matter which sink I choose in gstreamer-properties and hit "Test", I get static.
<soren> dtchen: It's a very clear static. I doubt it's a volume thing.
<soren> dtchen: ..but what do I know? :)
<hile> dtchen, but we DO ship the ffmpeg code in question anyway, or is this some a52-related patent stuff?
<soren> brb
<dtchen> soren: ok, so presuming Master/PCM/Front are not zeroed or muted, is the sink configured as intended? e.g., check pavucontrol
<dtchen> hile: checking the changelog, it seems more a matter of "no one dropped the delta", but i haven't chased it down
<hile> yeah, maybe it should be checked again before release?
<hile> well, whatever, does not help promoting libjack+deps to main even if a52 is solved (so that I could use the damn jack alsa plugin without recompile)
<dtchen> hile: the movement of j-a-c-k back into main is in progress
<hile> very good, hope it can be done for karmic...
<soren> dtchen: Thanks for your pointers. I'll have to check tomorrow. It's getting late, and I've still got a stack of actual work to do before I can call it a day. :/
<dtchen> soren: yw
<slangasek> dtchen: "back into" main?
<soren> slangasek: libjack and friends were in main in Breezy and earlier.
<slangasek> ah
<slangasek> ancient history :)
#ubuntu-devel 2009-06-18
<soren> Yeah, wow, that's four years ago.
<soren> Time flies.
 * soren gets all misty eyed thinking about Breezy.
<ajmitch> and that was a modern release
<debfx> bryce: what do you think about including virtualbox in xserver-xorg-*-all packages (bug #348497)?
<ubottu> Launchpad bug 348497 in xorg "Pulling Xorg virtualbox support by default" [Undecided,New] https://launchpad.net/bugs/348497
<soren> ajmitch: Weren't they all? :)
<ajmitch> soren: back in the day, when we were young :)
<cjwatson> billybigrigger: were you looking for me? there's more than one developer named Colin in Ubuntu
<bryce> debfx: will reply on the bug
<debfx> ok, thanks
<ebroder> Any main uploaders around who could look at bug #362691?
<ubottu> Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Medium,Confirmed] https://launchpad.net/bugs/362691
<TheMuso> wwwwwwwwwwwwww/c
<TheMuso> gah
<shtylman> is inkscape crashing for anyone else?
<johanbr> shtylman: yep
<johanbr> my libraries aren't completely updated, though, so that might be the cause
<shtylman> johanbr: I just got the latest pre-release inkscape from their ppa and it works :)
<johanbr> alright
<johanbr> well, considering that one of their main developers works too Canonical, I'm pretty sure it'll be fixed soon :)
<johanbr> *works for
<shtylman> indeed :)
<shtylman> new inkscape is nice...glad to see they fixed the export to relative location stuff
<johanbr> I had trouble with gradients when exporting to SVG... do you know if that's been fixed?
<micahg> is this the channel to talk about papercuts?
* slangasek changed the topic of #ubuntu-devel to: Archive: open | karmic alpha-2 released | armel buildds on manual for binutils fix-up | 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
<ScottK> micahg: #ayatana
<micahg> thanks ScottK
<LucidFox> Riddell, why is arora being promoted to main? Is it going to be the new default browser in Kubuntu?
<ScottK> LucidFox: It's likely.
<LucidFox> Sweet.
<lifeless> anyone else having their laptop randomly power off under karmic?
<lifeless> nothing in messages/syslog/etc indicating why
<Hobbsee> lifeless: power off, or graphics die and machine doesn't recove?
<lifeless> Hobbsee: power off
<lifeless> occassional black screen for 1 second with no side effects
<Hobbsee> i get the latter, but i've not seen the former
<lifeless> I've seen the former twice now
<Hobbsee> it wouldn't suprise me
<AnAnt> LP 388515
<ubottu> Launchpad bug 388515 in mutt "Candidate revision mutt_1.5.20-1ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/388515
<lifeless> where would be appropriate for a bug on this
* lamont 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
<lamont> I just wish I knew who decided that armel needed to be off MANUAL before it was ready to be off MANUAL
 * lamont -> bed
<dholbach> good morning
<pitti> Good morning
<dholbach> hiya pitti
<superm1> hi pitti
<micahg> are there any plans to allow an underscore in username?
<StevenK> pitti: Can haz MIR? :-)
<pitti> lool, asac, infinity: ^ got some time for MIR?
<pitti> StevenK: I didn't actually get a UNRish request, though
<StevenK> pitti: I was talking about celt :-)
<micahg> \are there any plans to allow an underscore in username?
<pitti> uid=1003(test_user) gid=1003(test_user) Gruppen=1003(test_user)
<micahg> sorry
<pitti> micahg: that should have worked forever already?
<micahg> in the installer
<micahg> had a friend install xubunut today
<pitti> micahg: can you please file a bug report for this?
<micahg> and couldn't use his username with an underscore
<micahg> ok
<micahg> sure
<micahg> wanted to know if it was a known issue or not
<slangasek> pitti: except for the part where debian regressed and I had to re-fix it
<micahg> what package is the installer?
<slangasek> pitti: bug #341698
<ubottu> Launchpad bug 341698 in adduser "adduser not allowing underscore "_" in a username" [Undecided,Fix released] https://launchpad.net/bugs/341698
<micahg> pitti: can you tell me which package the Ubuntu Installer is in so I can file the bug?
<pitti> micahg: ubiquity
<micahg> ok
<micahg> what's the official purpose of this channel?
<lifeless> micahg: /topic
<micahg> yes
<micahg> ok
<micahg> so generic Ubuntu devel
<micahg> so this was the right channel to ask my question
<lifeless> yes
<micahg> thanks for your help
<slangasek> micahg: which release of Ubuntu were you using for the installation?
<micahg> Xubuntu jaunty
<micahg> LiveCD
<slangasek> ok
<slangasek> then I guess there's a separate bug in ubiquity, indeed
<micahg> I found an open bug in one of the gnome tools package
<micahg> but that seemed gnome specific
<slangasek> pitti: btw, I did get the explanation from mjg59 about what the last bit of hotkey-setup was for; I'll get that documented and into one of the specs before killing hotkey-setup from the archive
<pitti> \o/
<pitti> slangasek: so it's confirmed obsolete now?
<slangasek> also, update-manager seems unwilling to remove hotkey-setup from my system, here - have you seen that?
<slangasek> pitti: the DOS stuff isn't obsolete, but it should certainly be moved somewhere else, such as the kernel
<pitti> slangasek: haven't heard about it, no?
<mattn_> hi
<pitti> slangasek: perhaps udev-extras should also Replaces: hotkey-setup then?
<mattn_> i'm trying to set up an modified live-cd at our company
<mattn_> it works already great
<pitti> slangasek: btw, udev-extras was merged into udev yesterday, so we need to move the Conflicts anyway
<mattn_> but now i'm trying to add a casper script to modify some gconf settings and desktop stuff
<MacSlow> Greetings everybody!
<mattn_> adding a new script to /usr/share/initramfs-tools to the casper-bottom folder doesn't help
<mattn_> seems the new script is not executed at all
<mattn_> is there any documentation available on how to customize casper?
<mattn_> even update-initramfs -u isn't helping
<mattn_> every hint is welcome ;)
<slangasek> pitti: heh, perhaps that will make a difference in update-manager's willingness to remove it
<slangasek> pitti: I wouldn't think a Replaces is needed; maybe it's actually one of the other packages that u-m is declining to upgrade that's really to blame
<slangasek> gnome-bluetooth or audacious, I guess
<slangasek> let's tentatively blame audacious
<ebroder> pitti: could you take a look at bug #362691 (specifically comment 37)? There's one more patch needed to make future upgrades work
<ubottu> Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Medium,Confirmed] https://launchpad.net/bugs/362691
<ebroder> Err, sorry, comment 38
<lool> StevenK: What is celt for?
<lool> I mean in main
<StevenK> lool: It's a new Built-Depends of opal, which is already in main
<StevenK> *Build-Depends
<lool> Aha
<StevenK> Which is in the MIR ... :-)
<pitti> ebroder: hm, it seems strange to change init script installation in a SRU
<lool> StevenK: Weird, I see the bdep in place already, but no opal package dep-ing on celt or libvelt
<StevenK> lool: It can't build!
<StevenK> It's in DEPWAIT
<lool> Hmm I need a cup of coffee
<ebroder> pitti: I haven't been able to figure out any other way to get the unpacking/prerm/postinst/etc order to work out
<StevenK> lool: Or two ...
<ebroder> pitti: My best guess is that something weird is happening with the various provides/conflicts/replaces
<pitti> ebroder: during upgrade, python modules won't work, that's a known fact
<pitti> ebroder: what does -R do?
<ebroder> pitti: Instead of stopping in the prerm and starting in the postinst, it does a restart in the postinst
<pitti> oh, right, it's not an option to xend
<ebroder> pitti: As far as I can tell, the prerm for a package shouldn't be running before the prerm for packages that depend on it. That's the weird bit
<ebroder> But that's what was happening
<pitti> ebroder: that's a bit dangerous, though; while the upgrade is running, xend can't use any python modules or other stuff
<ebroder> Sure it can - it just might have trouble importing new modules
<ebroder> But I don't think it does imports mid-execution under normal circumstances
<pitti> right, that's what I mean
<pitti> okay, just wanted to point it out
<ebroder> I guess it might be an issue if you try to...use xm to manipulate domains or config while the upgrade is running?
<superm1> pitti, lirc now depends on libfti-dev for the latest version which is living in universe, should I file a MIR on libfti, or will it show up on component mismatches or something like that and get taken care of via other regular archive admin work?
<StevenK> superm1: An MIR needs to be filed.
<superm1> okay thanks StevenK
<pitti> ebroder: uploaded
<ebroder> pitti: Great! Thanks. I'll try to test it some time in the next week or so
<pitti> ebroder: this needs fixing in karmic as well, apparently
<ebroder> Yeah, there's a patch on the ticket, but I've had a horrible time finding a sponsor
<pitti> tkamppeter: ah, you didn't upload cups to jaunty-proposed yet?
<mattn_> nobody can help me with my casper questions? is this the wrong location to ask questions about caspar? if yes, can somebody please point me to a proper location or channel?
<tkamppeter> pitti, I have sent you the debdiff because I thought you want to pass it through your BZR repo.
<pitti> tkamppeter: right, and I just remembered to bump the poppler-utils dependency
<lool> StevenK: I'm quite scared with the bitstream situation if it's going to be used in ekiga; the maintenance part and the other small issues call for further input too
<StevenK> lool: Bitstream situation?
<StevenK> lool: I'm not sure if Ekiga will pull it in
<lool> StevenK: The bitstream isn't frozen claims the README
<StevenK> lool: That's a problem?
<lool> See my comments in the MIR
<seb128> slangasek, are you sure that the gvfs change for hardy was not working correctly?
<lool> StevenK: celt seems optional in opal; if it's not used in ekiga, what's the point of pulling it in main?
<seb128> slangasek, it's the same that has been used for intrepid and jaunty and seems to work for quite some users
<StevenK> lool: Well, I can merge opal to drop celt
<slangasek> seb128: the bug report has follow-ups saying that it introduced regressions; it's possible that this fix was insufficient, that it depends on other changes?
<seb128> slangasek, I think it's hard to track properly those bugs because there is so many users having different issues commenting on wrong bugs
<seb128> it's not clear to me that the update actually broke anything
<slangasek> this was a user commenting specifically on regressions after installing the new packages in hardy-proposed.
<seb128> *shrug*
<asac> pitti: i have StevenK's and 3 other on my list for today (MIR)
<StevenK> asac: lool has already looked at it
<lool> StevenK: I think ekiga is the only user of opal in main and it's not on the CDs AFAIK (only DVD), so I wouldn't mind pulling it to avoid a delta with Debian modulo the other questions (and if it's not exposed in the list of codecs used by ekiga as long as the bitstream isn't frozen)
<asac> StevenK: yeah saw that now.
<lool> asac: I picked celt
<seb128> slangasek, ok fair enough, I guess we will just not get that change in hardy now, people will have to wait for the next lts
<asac> lool: fine. i actually started yesterday on it. i think i should have assigned explicitly to me.
<StevenK> lool: So we can move celt to main to avoid a delta?
<lool> StevenK: That's a good rationale, but the other questions stand
<lool> I would have objected if we have had other Ubuntu changes in opal or if ekiga had been on the CD
<juanje> hi guys, anyone knows how to debug acpi stuff? when a laptop doesn't suspend and stuff like that
<lifeless> there is a wiki page for debugging power support
<juanje> ummm
<juanje> lifeless: thanks :-) do you know the url or so?
<lifeless> no
<juanje> lifeless: oki, don't worry, I'll find it
<juanje> thanks
<lool> pitti: Hmm ISTR you asked about a new poppler for cups, but this was for Debian alone, we have the one you need in Ubuntu right?
<seb128> lool, yes
<seb128> lool, we have poppler 0.11
<lool> Yes, but I think pitti asked about it last week or so and we have 0.11 in Ubuntu for longer than that
<seb128> lool, but cups requires this version now apparently
<seb128> I'm not sure what your question is now ;-)
<lool> seb128: I'm asking pitti to confirm whether it's only in Debian that he was asking for the update   :-)
<seb128> yes
<seb128> since ubuntu already has 0.11 which is current
<seb128> not sure if you want to track the unstable version in debian though
<seb128> they changed the soname
<seb128> and the api might still change
<lool> Ok I find it unlikely that I find much time for it then; I don't have a lot of Debian time, even less for poppler, in particular when it's a development series
<pitti> re
<pitti> lool: yes, I asked about Debian; there's a pending patch (-origpagesizes) that I need for cups, and it would be nice to upgrade to newer version so that we can add a new pdf filter to cups
<pitti> lool: but I was told that Debian usually doesn't update to the odd-numbered devel releases
<lool> It depends whether there's interest and manpower as usual
<seb128> stable version is schedule for in some weeks
<seb128> so you might as well wait for it if there is no hurry
<tseliot> pitti: does this log look good to you (note: I don't have the hardware here but the modaliases and the modules are already in place)? http://pastebin.ubuntu.com/198356/
<tseliot> pitti: the modalias file is bcmwl
<pitti> tseliot: if you create a fake modalias for any other piece of hw, do you get it offered, and does it install okay?
<tseliot> pitti: no, it doesn't show up, even with a fake alias: http://pastebin.ubuntu.com/198365/
<pitti> tseliot: can you please show me the modalias file? does it have the correct package name?
<pitti> BroadcomWLHandler enabled(): kmod disabled, bcm43xx: blacklisted, b43: blacklisted, b43legacy: enabled
<tseliot> pitti: sorry, I've just tried again and there was a typo in the modalias. It works now
<pitti> tseliot: perhaps the issues is that the b43 blacklist is incomplete and misses b43legacy?
 * tseliot blames it on vim
<tseliot> let me try to remove it now
<tseliot> pitti: ok, the package was removed correctly. Shall I add a better description to the handler (if one is provided)?
<tkamppeter> pitti, the CUPS SRU package hangs in "Waiting for approval" for some hours now. Is it not you who approves it?
<pitti> tkamppeter: I had to run for the dentist, I returned to SRU work now
<pitti> tseliot: if you can think about one; otherwise just leave like it is now
<tseliot> pitti: my package already contains a file with the modules to blacklist (we need it for our customised OEM images) so we may end up blacklisting the same module twice. Would this be a big problem (I know it's ugly)?
<pitti> tseliot: shouldn't be a problem, just that jockey can't unblacklist it then
<tseliot> pitti: right but when you remove the package the blacklist goes away
<pitti> tseliot: ah, you mean the bcm package itself ships the blacklist?
<tseliot> yep
<pitti> tseliot: nice, that's even better than doing it in the jockey handler
<pitti> tseliot: we couldn't do that with l-r-m obviously
<pitti> tseliot: so we could just rip out the jockey handler blacklisting code now, since the package itself will DTRT
 * pitti favors solutions which also work with apt-get install
<tseliot> pitti: ah, right it was in the lrm before. Sure it's a good idea
<tseliot> pitti: do you know if the trick to load wl before b44 is still required? http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/annotate/head%3A/data/handlers/broadcom_wl.py
<pitti> tseliot: I think so, unless wl was changed to use the ssb module now?
<tseliot> pitti: I'm asking because I only blacklist b43 and ssb but maybe something more should be done
 * tseliot is unsure as to how to solve this problem in the blacklist file
<pitti> tseliot: the legacy ones need blacklisting as well then, I think
<pitti> tseliot: well, let's just keep the current code as it is then, and test it properly
<tseliot> pitti: jockey's blacklist file is blacklist-bcm43.conf while I could use a different name
<tseliot> pitti: this way I think we should cover all cases
<tseliot> s/should/would/
<pitti> tseliot: is wl's a conffile? if so, then mere removal of the package won't remove it
<pitti> if it's created/removed in postinst/prem, that's fine
<tseliot> pitti: it's listed in the .install file of the package, therefore it's removed when the package is removed
 * tseliot is using CDBS
<joaopinto> does anyonw know about NILFS stability ? It would be great to have such an improved file system recoverability
<super__rad> could someone upgrade empathy (and related telepathy packages) to newest versions as it's empathy hug day today and the newest versions contain a lot of bug fixes
<hyperair> hmm is anyone noticing that the getty processes disappear after logging out?
<hyperair> and that /etc/inittab is now missing O_o
<hyperair> no wait, it was always missing
<hyperair> hmmm the tty[1-6] services weren't running
<ogra> asac, hmm, FF 3.5 seems to ignore the shift key if i hit shift-ctrl-reload
<asac> ogra: please check latest firefox-3.5 and xulrunner-1.9.1 daily from ~ubuntu-mozilla-daily
<ogra> will do
<asac> ogra: i go to https://launchpad.net/ and type something in the search field. then hit ctrl+R -> text i typed is still there. then i hit shift+ctrl+R -> text is gone. so it seems to work somehow
<ogra> well, my prob is that it opens in a new tab instead of reloading (sorry, should have said that in the first sentence :) )
<asac> ogra: so you hit the reload toolbar button with ctrl+shift? thats a feature. its just shift
<ogra> oh, so the "clear cache" function if you hold ctrl+shift while hitting reload is gone ? or does it immediately work with shift only now ?
<liw> I thought it had been shift-reload since netscape 1
<asac> ogra: yeah. you probably think its ctrl because you usually type ctrl+shift+R on the keyboard
<ogra> that didnt clear out pictures, ctrl+shift+reload did
<asac> but if you click on the button it was always just shift
<ogra> it used to remove all pic of the site from the cache
<ogra> and load them newly ...
<ogra> anyway, i'm just irritated because it opens a new tab now
<asac> ogra: i checked in ffox 3.0 and ctrl+shift vs. shift is not different
<ogra> ok
<asac> at least not according to sniffed http headers
<DktrKranz> Riddell: I've been asked why we bumped sip b-d in python-qt4, so it could have it in sync again. Could you shed a light on that?
<vorian> it wont build otherwise, iirc
<Riddell> DktrKranz: I had errors  building sip/pyqt/pykde with anything  other than the latest
<Riddell> and we  can't be in sync, Debian has  an older  version
<DktrKranz> I see, thanks.
<geser> @archive-admins: maven-plugin-tools build-depends on a package build by itself, would a deb build from the Debian deb (as done with cup in the past) pass NEW? this would be undone asap
<pitti> geser: I wouldn't know how to upload this; I think this might need a manual build
<geser> pitti: I'd do it similar to http://launchpadlibrarian.net/25782720/cup_0.11a%2B20060608-1_0.11a%2B20060608-1build1.diff.gz
<pitti> geser: ah, I see
<geser> the question is: would such a package pass NEW?
<pitti> geser: if the included binaries get reverted, it will probabl
<pitti> y
<pitti> it's obviously a bootstrap issue, so it should be fine
<ogra> pitti, are you still hunting the memleak =
<ogra> ?
<pitti> ogra: me? what memleak?
<ogra> dunno, you asked about xrestop some days ago
<pitti> aah
<pitti> I don't get that, but seb128/mdz do, I think
 * pitti has a 945
<ogra> i just stumbled over that:
<ogra>  4717 ogra      20   0 3071m  44m 4152 S    1  1.5  20:12.36 compiz.real
<pitti> it only seems to happen on 965 as it seems
<ogra> 3G virtual ram ...
<pitti> wow
<ogra> after 24h
<seb128> videocard?
<ogra> 965
<soren> pitti: You don't see it on your laptop?
<pitti> apparently not
<pitti> I boot it every day, though
<soren> pitti: Mine's identical (apart from the wifi), and I see it.
<pitti> but so does seb128, and he notices
<soren> pitti: Oh, right, that would explain it.
<ogra> mine runs all the time
<ogra> and i see swap being eaten after about 12h
<pitti> suspend is broken with xorg-edgers as well as karmic, so I have to
<soren> pitti: It happens to me after ~30 hours.
<seb128> pitti: no, I tend to suspend my laptop at the moment
<ogra> the swap usage raises constantly then ... untill all swap is used ...
<seb128> not sure for how long it was not rebooted the other day but my 2Go of ram and all swap was used
<ogra> the intresting part is that it then doesnt move over to RAM or something to raise further
<pitti> ogra: so if you just do "compiz --replace", does that help?
<pitti> ogra: that wouldn't happen if it's just a memleak
<pitti> swap->ram happens on demand, not "just because it can"
<pitti> so, if it's dead allocated memory, it should stay in swap
<ogra>  3047 ogra      20   0  111m  24m 7688 S    4  0.8   0:01.84 compiz.real
<ogra> after compiz --replace
<ogra> though the swap isnt freed ...
<ogra> its using 3.5G
<Hobbsee> oh, is that why i end up having a whole bunch fo swap in use?
<seb128> Hobbsee: video card?
<ogra> swapoff failed: Cannot allocate memory ... and it seems to be used still ...
<Hobbsee> seb128: 945GM
<pitti> hm, seems I just didn't notice then
<seb128> pitti: if you reboot daily it might not be enough to notice
<ogra> yeah
<Hobbsee> 968mb virtual ram by compiz, anothe 508 to xorg, anothe 511 to firefox...no wonder my system's going into swap
<pitti> I have 0 used swap ATM
<seb128> pitti: how much is compiz using for you?
<pitti> martin    4610  0.5  2.0 388624 41880 ?        S    11:07   1:14 /usr/bin/compiz.real --ignore-desktop-hints --replace --sm-client-id 107cc6fd5a54f6c25f124531603772994800000044390021 core ccp
<pitti> seb128: what's the magic number, 388624?
<ogra> heh, nothing ...
<pitti> 388624 VSZ
<ogra> yeah, thats nothing
<seb128> pitti: yeah, watch how this one is moving, ie in one hour
<pitti> well, 388 MB != "nothing"
<pitti> but I understand it's counting all the shlibs, etc.
<ogra> compared to 3G it is ;)
<pitti> a few minutes ago it was 385072
<pitti> so it's growing
<ogra> funnily mine isnt after the --replace
<ogra> it jumped from 111M to 134 after the start and seems to stay there
<seb128> could be when switching workspace or something
<seb128> where you stay on front of IRC now ;-)
<ogra> i only have two workspaces and never switch
<seb128> ok, so that's not it
<pitti> I switched ws, changed window focus, that didn't do it
<pitti> simply waiting did
<ogra> oops, mine jumped to 136 ...
<seb128> just did 495 to 507 in on minute there
<seb128> 508
<ogra> just alt-tab'bing between a htop terminal and xchat
<pitti> I never ever use alt-tab, so that's not it either
<ogra> well, i meant all i do is switching windows ...
<seb128> pitti: I guess you have the issue too then, one day is just enough to eat your ram and swap apparently
<pitti> seb128: *nod*
<seb128> +not
<seb128> still we are lucky, mdz get gpu hangs while he's working
<ogra> everyone running KMS here ?
<pitti> o/
<seb128> do I have to do something to get kms used?
<pitti> although recently gdm doesn't use it any more
<pitti> that worked fine some weeks ago
<ogra> seb128, yeah, enable it in modprobe.d iirc
<pitti> gnome session itself does, though
<seb128> ok so I don't
<pitti> $ cat /etc/modprobe.d/i915-kms.conf
<pitti> options i915 modeset=1
<seb128> I didn't touch anything, I'm on jaunty upgraded
<ogra> right
<pitti> seb128: does it work OOTB on your ATI box?
<ogra> so its not kms related
<pitti> seb128: recent karmic kernel was supposed to auto-enable it on radeon
<seb128> pitti: dunno, how do I notice if it's used?
<pitti> ogra: very unlikely, too
<pitti> seb128: ctrl+alt+f1
<pitti> seb128: get a huge nice VT and no flicker?
<seb128> I will try later my desktop is not booted right now
<seb128> but I don't think it's used
<pitti> should switch in an instant
<seb128> I switched recently and I still had the standard textmode
<seb128> but I've a r6xx
<seb128> no compiz working on this box etc
<seb128> so I would not be surprised if kms was not working
<pitti> ah, perhaps KMS is just for <= r5xx
<ogra> hmm, after vt switch i notice xchat drops a shadow on my panel
<ogra> in fact all windows do
<ogra> and clicking the panel makes it go away
<ogra> and now i cant reproduce :(
<pitti> lool: shall we just try and ditch https://merges.ubuntu.com/libi/libipc-sharelite-perl/libipc-sharelite-perl_0.13-1ubuntu1.patch and sync it? 0.17 might have fixed the test failure
<ogra> pitti, we can reintroduce the patch, sync it first
<pitti> that was my thought
<pitti> NCommander: can you please forward patches like bug 300000 to Debian? it's a nuisance having to carry and merge them
<ubottu> Launchpad bug 300000 in libgtk2-perl "FTBFS fix for libgtk2-perl" [High,Fix released] https://launchpad.net/bugs/300000
<pitti> NCommander: (either way, still your merge)
<NCommander> pitti, the fix is Ubuntu specific, and I talked to the maintainer about it. (its an issue with the restrictiveness of our build environment)
<pitti> NCommander: wouldn't it work on Debian, too?
<mib_o6egw3k8> Help bring Google Gears to Opera, star this issue http://code.google.com/p/gears/issues/detail?id=15&q=opera&colspec=Version%20Milestone%20Owner%20ID%20Summary%20Component
<pitti> mib_o6egw3k8: this channel is not an adboard
<NCommander> pitti, I had the conversation a few months ago, but I think the maintainer didn't want to merge an ubuntu specific changeset. That being said, I'll ping him again on it
<pitti> NCommander: I'm curious, what's the difference on our buildds?
<mib_o6egw3k8> Sorry pitti
<NCommander> pitti, something prevents xvfb from properly initializing
<mib_o6egw3k8> I just realised I clicked on the WRONG irc
<NCommander> pitti, *is digging into his memory*
<mib_o6egw3k8> My bad
<pitti> NCommander: that sounds more like a bug, or it works on debian's buildds for sheer luck?
<pitti> NCommander: anyway, thanks for having pinged him
<NCommander> pitti, its too far back for me to remember. It works on Debian, but not on Ubuntu.
<NCommander> pitti, funny, I thought I put a sync request in, the delta wasn't needed anymore
<NCommander> let me reconfirm that
<pitti> NCommander: for libgtk2-perl?
<pitti> I just checked the diff, the xvfb call is basically unchanged
<pitti> but perhaps that underlying bug was fixed
<seb128> xvfb got some changes though
<seb128> what was the build error?
<NCommander> pitti, the maintainer axed the test suite run
<NCommander> pitti, due to bugs on most port architectures
<pitti> (hmm)
<pitti> NCommander: no pending sync request
<seb128> I would say "try to sync and see how it works and fix if required"
<seb128> easy enough ;-)
<NCommander> seb128, I'm about to punt it into my PPA
<NCommander> to see if we need to merge anything
<lool> pitti: I think you asked about taking a new libipc-sharelite-perl upstream version some time ago already, and NCommander tested it and it didn't help
<NCommander> lool, the issue however only persists on our build hardware :-/
<lool> I'm pretty sure it's a kernel issue, for which we need a test case   :-(
<NCommander> lool, which after two weeks I still couldn't produce :-/
<dholbach> pitti: thanks for sponsoring python-crypto
<pitti> n/p
<dholbach> al-maisan: there's the "what-patch" command you can run in a source tree to figure out which patch system a package uses :-)
<dholbach> (in ubuntu-dev-tools)
<cjwatson> mvo: how do you think that foundations-karmic-repository-management and foundations-karmic-golden-iso-image interact?
<al-maisan> dholbach: ah, another great tip :) thanks!
<mvo> cjwatson: I have not read the iso-image one yet, let me do that now
<dholbach> anytime :)
<mvo> cjwatson: there is a quite a bit of overlap, especially in the mirror part
<cjwatson> that's what I was thinking
<cjwatson> I was wondering if my spec should depend on yours ...
<mvo> cjwatson: sounds sensible, at least the add-distribution, add-package are something I need to add too
<mvo> cjwatson: I update my spec to point to the golden-image one
<mvo> cjwatson: did you had a chance to look at my debconf question btw? (not urgent, I'm just curious if I'm on the right track in general)
<cjwatson> mvo: I've looked at it, but haven't worked out the answer yet :-)
<cjwatson> mvo: I think you're on the right track in general, yes; that's the same approach that installer bits use
<cjwatson> mvo: sorry, it literally took me four hours this morning to get through stuff that had accumulated overnight
<cjwatson> mvo: I don't suppose you could get a 'DEBCONF_DEBUG=.' log?
<mvo> cjwatson: no problem, thanks for looking at it
<cjwatson> I think you're probably accidentally talking to the wrong frontend at some point, or one of the frontends isn't quite being configured right, or something
<cjwatson> the file descriptor plumbing for these things can be insanely delicate
<cjwatson> especially with confmodules re-execing themselves
<cjwatson> I got it wrong in debconf-apt-progress several times
<mvo> cjwatson: no worries, if I'm doing the right thing in general, I will try to work it out, I just wanted to avoid debugging something that was the wrong approach :)
<NCommander> pitti, we're going to need to promote pango-perl for libgtk2-perl to be buildable
<pitti> NCommander: ok, can you please file a MIR bug?
<pitti> sounds like an easy package
<NCommander> pitti, I assume a full MIR is also needed :-/
<pitti> NCommander: if it's a trivial package (perl bindings to a lib), just check Debian maintenance and bug status
<pitti> and add that to the bug report
 * ScottK thinks NCommander should do the full MIR just for practice.
 * NCommander stabs ScottK for practice
<NCommander> pitti, http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=libpango-perl
<jpds> Anyone know what happened to http://cdimage.ubuntu.com/daily/current/ ?
<pitti> NCommander: fair 'nuff :)
 * NCommander loads the coffee maker
<NCommander> crap
<NCommander> My home folder backup seems to have been corrupted
<ScottK> NCommander: Not good with coffee.
 * NCommander gives ScottK the EVIL eye
 * NCommander has concerns about the wiseness of using ext4 as the default filesystem ...
<ogra> NCommander, to late ... switch already happened
<toggles_w> works great for me, been using it since jaunty alphas
<NCommander> ogra, I know it did
<NCommander> toggles_w, sam ehere, and I suspect I may have had data corruption due to it :-/
<toggles_w> i must say i like the fsck speed ;-)
<NCommander> That I do like.
<toggles_w> Oh really?
<NCommander> toggles_w, well, I can't prove it
<toggles_w> loose anything interesting?
<NCommander> Near miss on my GPG and SSH keys
<NCommander> I just wiped the HDD after doing badblocks and reinstalled today
<toggles_w> sorry to hear that, im running it on a bunch of machines, power failures etc, seems to be fine
<NCommander> Parts of my music collection and a few episodes of TV :-/
<NCommander> Well, I was suspecting the HDD, but that passed badblocks ...
<toggles_w> backup ;-)
 * toggles_w ducks
<NCommander> I did
<NCommander> It was partially corrupted
<NCommander> That's what I managed to salvage out of the tbz2 I made of my home folder
<toggles_w> ouch
<NCommander> Yeah
<NCommander> I'm trying to figure out how that happened
<NCommander> Because I backed it up on the machine, then punted it to my Babbage board, then punted it back.
<ogra> for your gpg keys you just use the backup you burned on CD when you got them signed first :P
<NCommander> argh
<NCommander> I think I lost my .vimrc
<NCommander> .... *hopes theres a spare copy on the ARM porting box ..*
<NCommander> -rw-r--r-- 1 mcasadevall warthogs 178 Jun 12 16:19 .vimrc - bahahahahaha
<cody-somerville> mvo, ping
<mvo> cody-somerville: hello
<NCommander> Lesson learned: Test your ability to restore from backup before wiped your HDD
<NCommander> *sigh*
<ScottK> NCommander: "Amateurs back up.  Professionals restore."
<ogra> ++
<NCommander> *glares*
<cody-somerville> lol
<NCommander> Well, the absolute irreplacebles survived
<NCommander> so thats good
<rtg> tseliot: whats the name of the Karmic Broadcom wl DKMS package? It appears to have disappered from the archive.
<tseliot> rtg: bcmwl-kernel-source
<rtg> tseliot: universe still ?
<tseliot> superm1: ^^
<superm1> rtg, tseliot : https://edge.launchpad.net/ubuntu/+source/bcmwl it's in restricted
<rtg> doh!
<al-maisan> hello Riddell, could you please take a look at https://bugs.edge.launchpad.net/ubuntu/+source/lcms/+bug/388987 ?
<ubottu> Launchpad bug 388987 in lcms "Please merge lcms_1.18.dfsg-1 (main) from debian/unstable" [Undecided,Confirmed]
<tseliot> rtg: BTW I haven't uploaded my changes yet. I'm working on it
<rtg> tsk
<rtg> tseliot: damn tab completion. OK
<Viper550> ooh so they changed the grub menu design?
<cjwatson> err, by virtue of switching to grub2
<cjwatson> what's there right now is not permanent
<Viper550> you can still do customization right?
<Viper550> and I knew it was probably grub 2
<cjwatson> I have no idea what its customisation facilities are
<cjwatson> they're in flux anyway
<lool> evand, cjwatson: Would it make sense to consider GRUB 2 for USB disks created by usb-creator instead of syslinux?  One thing I have in mind is EFI support, but I don't know whether it's possible to have both classical BIOS and EFI support on USB
<cjwatson> lool: maybe
<lool> (/me knows next to nothing on EFI, just that more platforms are switching to it)
<cjwatson> there are still USB fixes going into GRUB 2 though ...
<Viper550> why can't we use isolinux on the bootloader as a temp?
<Viper550> on the CD
<cjwatson> huh? we do
<lool> I didn't here any complains about CDs, isolinux is fine there
<Viper550> on karmic you use grub2?
<Viper550> oh wait
<lool> Not on the CDs (for now at least)
<lool> grub2 is the bootloader we now install for the installed system
<Riddell> al-maisan: ok
<cjwatson> Viper550: what lool said.
<Viper550> oh
<cjwatson> long-term I might be comfortable switching to grub2 on the CDs as well
<cjwatson> but not this release
<cjwatson> for one thing, the graphical menu patches to grub haven't landed yet
<Viper550> not until suse does them right?
<cjwatson> nothing to do with suse
<cjwatson> I shouldn't think grub2 will get gfxboot; there's an independent graphical menu effort going on
<cjwatson> http://grub.gibibit.com/ if you want to look into it, I haven't really yet
<Viper550> so ubuntu will probably use that?
<cjwatson> maybe
<cjwatson> we haven't fully evaluated it - I just know it exists
<lool> I just thought of something
<lool> Why don't we load the kernel in the background when waiting for the grub timeout?
<lool> (Add an optional enabled by default feature to autopreload the default entry)
 * cjwatson has no idea if grub can do that
<lool> I doubt it can do that know, but I am pretty sure it would save us exactly timeout seconds boot time  :-)
<cjwatson> suggest it upstream :)
<lool> Actually I only ever looked at GRUB1, don't take my word GRUB2 can't do it, I don't use it yet
<cjwatson> it's not completely impossible that it can
<cjwatson> GRUB 2 does have scripting support
<Riddell> al-maisan: uploaded, thanks
<al-maisan> Riddell: thank you :)
<rtg> cjwatson: what was the decision on the minimum supported x86 instruction set for Karmic? What it i586 and higher?
<rtg> s/What/Was/
<rtg> in other words, the 386 ports kernel is pretty much at a dead end with Jaunty.
<lool> cjwatson: According to random upstream developer on IRC, it's not possible yet and better to file a patch implementing it than a feature request (which I can understand)
<evand> kenvandine: am I correct in believing that we're getting webkit on the CD via gwibber per the social from the start work?
<evand> please say yes :)
<lool> That said, it might be mot as I think Scott mentionned a zero timeout and entering grub is a key is held down; but I'm not 100% sure I remember correctly
<rtg> lool: that is my recollection
<lool> rtg: I suggested doing that two cycles ago, but Scott argued back then that some BIOSes would disable keys if you'd press them down during boot (considering the keyboard/key as buggy)
<Keybuk> lool: then Fedora did it, and proved there weren't any
<evand> apparently that's no the case
<evand> not*
<evand> heh
<Keybuk> or at least, not many
<lool> Too bad we didn't do it then
<NCommander> pitti, how goes the MIR :-)
<lool> But we're going to do it!  \o/
<rtg> lool: using the shift key is evidentally OK
<NCommander> rtg, the only reason the 386 kernel survived into the karmic cycle is because we needed at least one kernel building on i386 or increase the delta between the ports kernel and mainline kernel
<rtg> NCommander: but what good is the 386 kernel if user space won't work?
<lool> rtg: I'm using ctrl/alt/shift just fine with "mbr", but I'd be interested in knowing why it's inherently ok?  You mean because these are modifiers?
<NCommander> rtg, its virtually useless, the problem is Arch: all binaries needed to be built on i386, and the build system when snap when we tried dropped 386.
<NCommander> rtg, it was on my to-be-fixed list, but there isn't much point since ports will be merging into the mainline kernel git tree.
<rtg> lool: that is my understanding
<rtg> NCommander: ok, at least I'm not insane
<NCommander> rtg, I told Luk to drop it (with the HPPA kernel) as part of the merge he generated (I have a set of outstanding patches to fix ia64 and sparc's config files which will hopefully be posted shortly after everything lands in the main tree)
<rtg> NCommander: I was responding to mvo about upgrades. It sounds like there is no upgrade path for 386.
<cjwatson> rtg: decision not made because we're still waiting for benchmarking which is waiting for infinity to get back from being ill
<rtg> ah, limbo.
<NCommander> rtg, oh, sorry, missed that bit. Yeah, thats correct. (strictly speaking, the 386 kernel only worked on 486 machines)
<cjwatson> rtg: and in any case we were talking about optimisation not minimum supported set
<cjwatson> rtg: i.e. -mtune not -march
<cjwatson> rtg: so no effect on the 386 ports kernel
<rtg> cjwatson: so the 386 ports kernel will still workl?
<cjwatson> rtg: ought to
 * NCommander wonders if anyone actually uses it
<cjwatson> yes
<cjwatson> I get people showing up on #ubuntu-installer asking for help with such systems from time to time
<NCommander> cjwatson, I'll be darned.
 * NCommander needs to sit down and see if we can drop powerpc-smp as a individual kernel
<NCommander> I'd like to drop sparc-smp, but to my knowledge, our userland will work in places where that kernel won't ....
<tgpraveen> evand: some amount of webkit support will
<tgpraveen> be there as empathy uses it for their adium themes
<tgpraveen> and iirc there will be a human theme for it by default also
<NCommander> cjwatson, BTW, d-i sparc should be fixed with the next kernel upload, I found out what was breaking it :-), ia64 images should also start building with the next upload
<evand> tgpraveen: empathy in karmic does not currently list webkit as a dependency, are you saying that a newer version will?
<cjwatson> NCommander: good, thanks
<tgpraveen> don't know exactly bt I do know libwebkit is needed for the adium themes for empathy which WILL ship in karmic
<tgpraveen> so yes maybe it will be added soon . maybe some dev could confirm?
<NCommander> cjwatson, the problem was we've been shipping uncompressed kernels for the last two and half cycles on port architectures due to a little mistake dating from when the ports tree and the mainline tree were separated :-/
<Keybuk> cjwatson: bug #385911 - what kind of "more careful" were you thinking of?
<ubottu> Launchpad bug 385911 in upstart "event.d: recovery menu appears on every boot if cmdline contains the word "single"" [Medium,Triaged] https://launchpad.net/bugs/385911
<MacSlow> asac, what means it exactely when the nm-applet ghosts the wifi-devices in its the menu?
<al-maisan> Hello Keybuk, please take a look when you have time: https://bugs.edge.launchpad.net/ubuntu/+source/lm-sensors-3/+bug/389031
<ubottu> Launchpad bug 389031 in lm-sensors-3 "Please merge lm-sensors-3_3.1.0-2 (main) from debian/unstable" [Undecided,Confirmed]
<Keybuk> cjwatson: nm, I have an idea
<cjwatson> Keybuk: maybe whitespace or start/end-of-string either side?
<Keybuk> cjwatson: for ARG in $(cat /proc/cmdline) seems like a good way ;)
<cjwatson> it's just being a bit too liberal about word boundaries is all
<cjwatson> that works too
<Keybuk> split on $IFS
<asac> MacSlow: screenshot please ;)
<MacSlow> asac: well "GerÃ¤t wird nicht verwaltet" is stated there too for both wifi-devices
<MacSlow> asac, but I've no clue where to instruct nm to "feel responsible" for these two
<asac> MacSlow: anything in /etc/network/interfaces?
<MacSlow> asac, yes auto wlan0 ... and auto wlan1 ...
<MacSlow> asac, should I get rid of those entries?
<asac> MacSlow: hmm. remove those too lines, then do sudo killall nm-system-settings
<asac> two
<asac> MacSlow: also if that helps, file a bug please ... auto lines alone shouldnt make the devices unmanaged i think
<MacSlow> asac, I think I had someone like you or keybuk once mess with my laptop... so that might explain these lines... I think to remember now
<asac> MacSlow: did you have iface lines too? or just auto?
<asac> MacSlow: if it was just auto i definitly want a bug
<asac> thx
<MacSlow> asac, no there were also "mode managed" and "essid ubuntu" lines below each "auto wlan*" line
<asac> MacSlow: ok. so also iface wlan0 ... etc?
<asac> thats a feature then
<MacSlow> yes
<MacSlow> hm... nothing changed
<MacSlow> do I need to restart more than NetworkManager after doing "sudo killall nm-system-settings"?
<MacSlow> *sigh* fsck
<MacSlow> asac, well that didn't change anything
<asac> MacSlow: paste your interfaces please
<MacSlow> asac, "iwlist scan" tells me for wlan0 "Failed to read scan data: Network is down" and for wlan1 I get "No scan results"
<asac> MacSlow: also paste hat you get in syslog after killall and restarting NM
<ttx> cjwatson, pitti, slangasek: By FeatureDefinitionFreeze "all features with updates to be landed  in main for the release must be named and acked by the ReleaseTeam" -- how do you want to proceed exactly ?
<ttx> get an email ? be subscribed to the relevant blueprints ?
<ttx> Hobbsee, Riddell: same question ^
<MacSlow> asac, http://pastebin.ubuntu.com/198631
<asac> MacSlow: you didnt paste your current /etc/network/interfaces
<asac> MacSlow: anyway. the problem now is your killswitch
<asac> (no need to paste more)
<asac> MacSlow: so either use fn+F5 until you see the wifi led
<asac> MacSlow: or check that you dont have the hardware killswitch flipped
<MacSlow> asac, the hw-killswitch is certainly off
<MacSlow> asac, Fn-F5 only makes the bluetook LED switch on or off
<asac> MacSlow: please flip the hw-killswitch a few times and paste the tail of syslog you get when doing that
<MacSlow> asac, http://pastebin.ubuntu.com/198638
<MacSlow> asac, only bluetooth seems to be affected by the killswitch
<asac> MacSlow: thats not syslog ;)
<asac> (guess its dmesg)
<asac> MacSlow: anyway. try to reboot. maybe its a bad driver state
<asac> (or check that you havent disabled wireless in the applet menu)
<MacSlow> asac, I did "tail -f /var/log/syslog >/tmp/log.txt"
<MacSlow> if that's not syslog then call me stupid
<MacSlow> what's the difference between dmesg and syslog anyway?
<asac> MacSlow: try to reboot or reload the iwlagn driver (you are still using thinkpad right)?
<asac> MacSlow: also paste output of nm-tool ;)
<MacSlow> asac, rebooted no change
<MacSlow> asac, I'm using the iwl3945 driver here and the ath9k fro the wifi-card plugged into the PCMCIA-slot
<MacSlow> asac, looking at the nm-tool output now
<asac> why do you have two wifi cards? does it change if you boot without the ath9k thing?
<MacSlow> asac, http://pastebin.ubuntu.com/198643/
<MacSlow> asac, no
<MacSlow> asac, no matter if I boot with the ath9k plugged in or not
<MacSlow> I cannot get any wifi-connection
<asac> MacSlow: when did this start? are you using karmic or jaunty?
<MacSlow> between interpid/jaunty timeframe
<MacSlow> asac, if that observation is any hint...
<MacSlow> when I plug in the ath9k
<MacSlow> I do get a scan result from "iwlist scan"
<asac> MacSlow: have you tried to install linux-backport-modules-jaunty?
<MacSlow> asac, no
<asac> MacSlow: do that and restart your system
<MacSlow> asac, I guess I should try?!
<asac> yeah
<asac> MacSlow: anyway. i am out for today and have two days holidays. if backport modules dont help, i would like to look next week closer. so just ping me after tue ;)
<asac> MacSlow: its linux-backports-modules-jaunty ... ok out for a while
<DrPepperKid> asac, it's me MacSlow (on the laptop now... ethernet-based internet for the moment)
<superm1> tseliot, one more thing on the bcmwl, i'm not sure shipping that blacklist file in /etc/modprobe.d/blacklist-bcmwl.conf is the right solution. when jockey enables it, it builds a blacklist that is a little more advanced (queries to see if it needs to work with b44 too)
<superm1> pitti can comment hopefully more on what jockey is doing
<DrPepperKid> asac, I'm on karmic on this laptop not jaunty
<superm1> maybe it's best to just move that logic for building the blacklist into the postinst, and then all jockey has to do is install bcmwl-kernel-source and bcmwl-kernel-source's postinst then would figure out what to do about b44 and how to build such a blacklist
<rtg> superm1: the bcm wl Karmic package does appear to work, I have it on a mini-9.
<rtg> (after futzing with blacklists)
<superm1> rtg, good to hear
<superm1> hoping to see the proper blacklist preparations sorted out before tseliot's new modalias stuff hits to prevent too much confusion
<rtg> superm1: did Jernone pass on Tony and my thoughts about their user space version of the driver?
<superm1> rtg, yes but keep in mind the channel you're discussing in
<rtg> I don't think its a secret. I've already seen discussion of it in the wild.
<superm1> i'll  be summarizing the points I saw for next time we discuss with them
<MacSlow> asac, ok ath9k based wifi works on the laptop again now
<MacSlow> asac, thanks for the help sofar!
<MacSlow> asac, http://pastebin.ubuntu.com/198664
<MacSlow> asac, does that tell you anything about the remaining problem with iwl3945 wifi-card (that's the internal one)?
<ccheney> slangasek: is there anything needed to be approved for OOo 3.1.1 wrt FDF, we already have 3.1.0 in and 3.1.1 will release sometime in august
<MacSlow> 800 MBytes worth of updates *sigh*
<tseliot> superm1: yes, I'm aware of what jockey does. I'm not sure as to whether I can do the same in a blacklist file. Currently we have separate blacklist files: one in my package and one is created by jockey. The one in jockey can blacklist b44 and make sure that it's loaded after wl
<tseliot> superm1: here's what jockey does:
<tseliot> http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/annotate/head%3A/data/handlers/broadcom_wl.py
<MacSlow> hm... how can gnome-power-manager-2.27.1 compile on Karmic if it does not have the right version of DeviceKit-power defining dkp_client_lid_is_closed() ?
<MacSlow> pitti, do you know how that can work ... compiling gnome-power-manager 2.27.1 under Karmic although DevKit-power-dev is not current enough?
<MacSlow> pitti, my installed DevKit-power-dev is missing the definition for dkp_client_lid_is_closed() which is used in gnome-power-manager 2.27.1
<ccheney> didn't dapper desktop support already go away by now? i didn't see mention of it on ubuntu-announce yet though
<superm1> tseliot, i think that same stuff can be done in sh in the postinst, just checking lsmod for b44, and writing out a different blacklist if so
<Keybuk> 64-bit gdb can't read 32-bit core files and executables
<Keybuk> I honestly did not expect that
<elmo> Keybuk: there's a gdb64 on 32-bit; is there not a gdb32 for 64-bit?
<Keybuk> elmo: not that I could see
<tseliot> superm1: only on 1st installation?
<Sarvatt> anyone familiar with usplash here that I could nag? usplash segfaults (but leaves the graphic on the screen) under a KMS framebuffer which is kind of a problem when fsck or a password entry is needed
<Sarvatt> is it only designed to work at certain resolutions?
<mterry> cjwatson: I'm looking at the oem-config desire to translate city names.  What's the best thing to do for a case like that, where translating city names would leave us with a large translation delta?  Only do it through debian?  Use a separate template in its own directory?
<mterry> evand: ^^
<jpds> Sarvatt: You'd probably want to talk to Keybuk.
<Sarvatt> I'm not sure how to debug it further is all. when you build i915 with KMS enabled into the kernel to get the high resolution drmfb from the start of boot you get the initial graphic and it segfaults right away instead of running throughout the boot process looking at my bootcharts. some people on the ubuntu stock kernel with i915 as a module have their screen black out after the cryptloop password entry when it switches to the KMS framebuffer. if
<Sarvatt> they build i915 into the initrd so it switches to the KMS fb earlier they can no longer see the password entry screen at all
<superm1> tseliot, not necessarily.  Here's what i'm thinking (untested) http://pastebin.com/f45ce73aa
<superm1> so if someone removes it and say runs dpkg-reconfigure bcmwl-kernel-source, it would be rebuilt for them
<RainCT> pitti: I've just given you reviewer rights on REVU (so you can advocate/veto/archive).
<RainCT> If any other MOTU/Core Dev is missing them poke me or another REVU admin (there's a full list at REVU's Statistics page, at the bottom right)
<cjwatson> mterry: make every possible effort to use an existing source for the translations - we don't want the quadratic effort of doing it ourselves
<cjwatson> mterry: and then have a dynamic build process that uses that existing source
<cjwatson> mterry: yes, it should be a separate set of .pot/.po files that get merged. there are already some udebs that do this sort of thing
<cjwatson> mterry: I'm not sure if any of Debian's installer interfaces ever display all available cities in any given language
<cjwatson> mterry: if there are any, it would be tzsetup
<tseliot> superm1: and how do I decide whether I should remove the blacklist file or not (which jockey might have modified in the meantime) in the postrm? Shall I simply remove it if it exists?
<superm1> ah yeah probably
<superm1> tseliot, ^
<cjwatson> Sarvatt: try to set up usplash to run in an environment with 'ulimit -c unlimited' set, and then try to arrange that the core dump ends up somewhere useful that you can look at after boot
<cjwatson> Sarvatt: usplash hasn't been adapted for KMS in an initramfs environment yet though - I did make a start on that but ran into some problems with KMS on my hardware and haven't finished
<tseliot> superm1: now that I think of it, pitti is available to remove those commands from the handler in Jockey if I can deal with the blacklist directly in the package (we discussed this today)
<superm1> tseliot, yeah so that's what i'm thinking, jockey wouldn't do any of that, it would all be handled by the package itself indeed
<superm1> tseliot, so jockey really is just a frontend then to say "install me" and the postinst/postrm would do what the handlers did soley
<tseliot> superm1: ok then, I'll work on it tomorrow.
<superm1> tseliot, awesome thanks!
<slangasek> ttx: an email listing all the specs for your team, and a discussion item at tomorrow's release meeting
<slangasek> ccheney: no, nothing we need to worry about with OOo 3.1.1 there
<ccheney> slangasek: ok
<Fabio23> salve c'Ã¨ un modo per vedere il numero dei cicli che ha compiuto il mio hd da linux ubuntu?
<EvanCarroll> I just merged together 13 bugs related to a debian-perl group problem.
<directhex> banshee magnatune extension developer is coming out of the woodwork
<directhex> he's accepted my fixes to get the preview stream part (the only implemented part so far) working on banshee 1.5.0
<EvanCarroll> https://bugs.launchpad.net/ubuntu/+source/libxml-sax-perl/+bug/13917
<ubottu> Launchpad bug 13917 in libxml-sax-perl "CPAN's XML::SAX update conflicts with libxml-sax-perl's XML::SAX" [Medium,Confirmed]
<EvanCarroll> Anyway, I'm not sure the Debian Perl guys will fix this. I'm thinking about blueprinting out a removal of all Debian hacked perl modules.
<EvanCarroll> Becaues it is dirty thing they do, fork a cpan module, modify the contents of it, pollute its namespace ,and then publish it under the same name.
<EvanCarroll> the gain isn't worth it
<cjwatson> EvanCarroll: (a) I don't see why Debian wouldn't fix this; yes, I know there was a semi-objection raised by a maintainer in the past, but the Debian Perl Group has had a good deal of turnover since then; (b) this is the first case I've ever heard of featuring this kind of change so I don't think it's all that big a thing
<cjwatson> and just look at all those rdepends - this needs to be fixed, not removed
<Caesar> So multiple hyphens in a version is a no no isn't it?
<slangasek> it's tacky, but not prohibited :)
<StevenK> Caesar: It's not, but only if the package is non-native
<Caesar> I seem to have grown a plus sign
<slangasek> "If there is no <debian_revision>, then hyphens are not allowed [in the upstream version]"
<Caesar> So I'm looking at the sun-java6-jre package for example
<Caesar> With a version of 6-14-1 in karmic/multiverse
<slangasek> Caesar: perfectly permitted, since the -1 is the Debian revision
<Caesar> Okay, so the problem is grep-dctrl in Hardy then
<Caesar> It's spitting out stuff like: grep-dctrl: -:10221: expected a colon.
#ubuntu-devel 2009-06-19
<jcastro> anyone know anything about libtheora? Seems we just get it from debian
<slangasek> jcastro: is there more to know than "it's the lib that implements the codec"?
<jcastro> slangasek: yeah it's just recently it's been a contentious issue with browsers, etc. upstream, I think it would be great if for karmic we had it nice and fresh
<jcastro> "open web" and all that
<slangasek> hrm?
<jcastro> so, new browsers support the <video> tag
<jcastro> so you can just embed videos
<slangasek> what do you mean by "nice and fresh"?
<jcastro> and mozilla and others have been sponsoring theora development
<jcastro> the current dev branch "thusnelda" brings a bunch of improvements to the encoder
<jcastro> to make it more competitive for web video
<jcastro> and I was just wondering if someone is keeping an eye on it (PPA or otherwise), so that for 9.10 we're not behind as far as a platform for people who want to encode theora video
<ajmitch> I take it there's no new release of it yet?
<jcastro> slangasek: keeping in mind that this didn't really seem important until like, last week
<jcastro> ajmitch: it's in alpha2
<slangasek> that's the 1.1 branch, then?
<jcastro> slangasek: that would be the alpha one I am referring to
<billybigrigger> anyone know when the gtk2.0 problems will be sorted?
<slangasek> billybigrigger: what problems?
<billybigrigger> the constant seg faulting
<slangasek> where has this been reported?
<billybigrigger> im pretty sure, lemme check
<billybigrigger> libgtk2.0
<billybigrigger> i can crash deluge, transmission all day just by trying to change where i save my torrent's
<billybigrigger> also im pretty sure my constant nautilus crashes are also caused by gtk2.0
<billybigrigger> can't seem to find a bug related to it, so ill file one
<slangasek> that would be the first step.
<slangasek> please use apport, so that we can actually see where this crash is happening.
<billybigrigger> libgtk-x11-2.0.so to be more specific
<billybigrigger> Jun 18 17:53:43 cabo kernel: [174822.185657] deluge[7151]: segfault at c0cc100 ip 00007f642a4b1e59 sp 00007fff1696da40 error 4 in libgtk-x11-2.0.so.0.1702.0[7f642a3fc000+43e000]
<billybigrigger> Jun 18 17:54:33 cabo kernel: [174872.489733] transmission[17614]: segfault at 640114e0 ip 00007fac754b9e59 sp 00007fff34c7c750 error 4 in libgtk-x11-2.0.so.0.1702.0[7fac75404000+43e000]
<slangasek> yes, please use apport to file a bug that shows us the backtrace.  kernel messages don't give enough information to debug
<slangasek> or even to match your crash up with other reports
<billybigrigger> and what about this whole empathy thing, like why is it replacing pidgin? empathy doesn't use libnotify or notifications, and is bugged all to hell, i can start it up, see 0 contacts online, and fire up pidgin and see 10+ contacts online...
<billybigrigger> apport won't even fire up
<billybigrigger> when i crash deluge or transmission
<billybigrigger> so i guess the crash log from /var/crash will have to do
<slangasek> yes, you should be able to use apport-cli -c /var/crash/crashfile to pick it up.
<DreadKnight> i'm running kubuntu.. recently pidgin doesn't connects to my yahoo account...
<DreadKnight> i wanted to try empathy and it kept asking for a stupid password in order to connect to the accounts imported from pidgin automatically.. that was epic fail
<DreadKnight> i removed empathy... now yahoo is not working... I don't recall any recent updates to pidgin or libpurle
<DreadKnight> my guess is that empathy messed it up
<Syrius> hello
<Syrius> can you ask questions in here ?
<tgpraveen> Syrius: develop related ques yes
<Syrius> okay cool tgpraveen
<Syrius> I have newbie questions tgpraveen
<Syrius> about pbuilder
<Syrius> hold on
<Syrius> let me see what my question exactly is
<Syrius> so once you make the debian packages you just install the ones in /var/cache/pbuild/result ? tgpraveen
<Syrius> with pbuilder
<tgpraveen> sorry am a noob too maybe someone else could help you here
<Syrius> okay
<TheMuso> Syrius: #ubuntu-motu would like be a better place to ask.
<TheMuso> likely
<Syrius> what does that stand for?
<Syrius> motu?
<TheMuso> Syrius: thats the IRC channel where you will most likely get the answers to your questions.
<dholbach> good morning
 * nixternal hugs dholbach 
<MacSlow> Greetings everyone!
<tgpraveen> is there a ppa for the messaging indicator so that I can get the empathy support for it( which is available in karmic ) in jaunty
 * dholbach hugs nixternal back
<hyperair> does anyone know how long it usually takes for a NEW package to get synced from Debian?
<pitti> Good morning
<pitti> MacSlow: seems we need to update dk-p then
<MacSlow> pitti, wait...
<MacSlow> pitti, I just pulled all updates (800+ MBytes) and now it compiles
<pitti> MacSlow: we do have 2.27.1 in karmic, though
<pitti> and it builds fine
<MacSlow> pitti, yes
<MacSlow> pitti, I have no clue was different though
<MacSlow> just happy it works and I don't have to enter dependency-hell
<kwah> hi all
<kwah> whom may I contact with respect to tools available to create generic Ubuntu add-on CD?
<tseliot> pitti: about dealing with the blacklist file directly in the broadcom package (instead of the Jockey handler). What do you think about doing it in the postinst? https://pastebin.canonical.com/18727/
<tseliot> pitti: this part "if [ ! -f $BLACKLIST_FILE ]; then" is what does what I said
<tseliot> and of course there will also be a postrm which removes the file
<pitti> tseliot: that would work, since it would avoid conffiles staying around if you remove, but not purge
<pitti> tseliot: but why don't you blacklist b43 in the "b44" case, and b43legacy in neither case?
<pitti> tseliot: you should also blacklist ssb, and (just in case you are running an older kernel), bcm43xx
<pitti> tseliot: similar to what the current jockey handler is doing
<pitti> tseliot: but I do like the packaging approach
<lucas> seb128: have you seen the thread on debian-devel@Â about patch tagging guidelines?
<lucas> seb128: since you did the original work on the ubuntu policy, it might be interesting for your to take a look
<lucas> seb128: the current debian proposal is incompatible with the ubuntu one
<seb128> lucas: ubuntu-devel got emailed about that I did read the email
<lucas> ah ok
<tseliot> pitti: yes, the script is not complete yet but thanks for the feedback. I'm glad to read that you like the approach.
<tseliot> pitti: ok, this version does exactly what jockey does. Shall I still call /usr/sbin/update-initramfs -u? https://pastebin.canonical.com/18728/
<pitti> tseliot: initramfs> yes, you need to, so that the driver isn't accidentally loaded in initramfs
<tseliot> pitti: ok, thanks
<tseliot> pitti: one last thing. Shall I remove the blacklist file in the postrm when the postrm is passed the "upgrade" parameter too? (so that the file is regenerated when the package is upgraded)
<pitti> tseliot: hm, I think it's only necessary on removal
<pitti> reduces the chance to stomp over local modifications
<tseliot> pitti: ok, good point
<pitti> tseliot: btw, please add a comment saying "# This file is autogenerated and will be overwritten" or so
<tseliot> pitti: sure
<cjwatson> pitti: do you know why bug 363712 is on Steve's agenda under foundations rather than desktop?
<ubottu> Launchpad bug 363712 in openclipart "cliparts are not in gallery-path of openoffice 3.0" [Medium,Confirmed] https://launchpad.net/bugs/363712
<cjwatson> pitti: I know doko was the one who targeted it ...
<pitti> cjwatson: not sure, I mention it on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
<pitti> cjwatson: probably just a glitch in the topic list
<bigon> Keybuk: hi what was the reason of such changes?   * Bump build-depend on debhelper to install udev rules into
<bigon>     /lib/udev/rules.d, add Breaks on udev to get correct version.
<bigon> ? can these changes be dropped?
<doko> cjwatson, pitti: this one just needs a change of directory name, or else the extra cliparts are not seen in OOo
<Keybuk> bigon: udev rules have to be installed in /lib/udev/rules.d
<Keybuk> bigon: dropping those changes would mean they would be installed in the wrong place
<Keybuk> bigon: so, no
<cjwatson> doko: if you agreed with the patch in the bug report, I'm happy to sort out uploads
<bigon> Keybuk: http://launchpadlibrarian.net/21147124/garmin-forerunner-tools_0.09-2_0.09-2ubuntu1.diff.gz << there is nothing intresting in this diff as debhelper and udev are at the good version in karmic
<Keybuk> bigon: incorrect
<Keybuk> bigon: the build-depends is still needed to ensure correct builds if people backport
<Keybuk> bigon: the Breaks is still needed to support upgrades (e.g. LTS to LTS)
<dholbach> pitti: I'm just taking a look atit
<doko> cjwatson: yes, this looks fine (plus maybe update the dependency on OOo to >= 3.0
<dholbach> doko: or are you done with it already?
<dholbach> doko: ooops
<doko> dholbach: done with?
<bigon> Keybuk: mmm ok
<dholbach> pitti: or are you done with it already?
<ScottK> Keybuk: Thanks for worrying about backports.
<pitti> dholbach: no, currently doing spec reviews; thanks
<dholbach> pitti: I'll take over json-glib then
<pitti> dholbach: I'm already at that one
<pitti> about to dput it, finished building
<apw> pitti, any idea who looks after the upload janitor?  the one which moves bugs to Fix Released?
<pitti> apw: hm, might be cprov? or at least he should know who
<apw> hrm... i think i just found the failure ... our end ... thanks for the info
<cprov> apw: ehe, is it also called 'janitor' ?
<apw> heh ... no the failure it called me ... damn
<cprov> apw: okay, ping if you need anything.
<apw> cprov, thanks will do
<lool> Err I thought (hd0,1) meant sda2, not sda1; did this change with GRUB2?
<cjwatson> yes, it did
<lool> Geez how confusing
<cjwatson> see http://www.gnu.org/software/grub/grub-2.en.html ("design mistakes in GRUB Legacy")
<lool> Thanks
<cjwatson> should mostly be using UUIDs now anyway ...
<Riddell> mathiaz: will mysql 5.1 be in main for karmic or 5.0?
<mathiaz> Riddell: hm - good question
<mathiaz> Riddell: I've thinking about doing the transition
<mathiaz> Riddell: I think that the security team wants 5.1 in main for the next LTS
<kirkland> Keybuk: upstart question for you...
<kirkland> Keybuk: i assume you use some sort of kernel interface to see when new processes are launched?
<Keybuk> in upstart-nl, yes
<kirkland> Keybuk: something more advanced than grep'ing ps or /proc, i assume?
<Keybuk> yes
<kirkland> Keybuk: where can i learn this magik?
<ogra_> dutch upstart ?
<mdz> mvo: bluez-gnome is holding  back gnome-bluetooth on my system.  is this a known upgrade issue?
<cjwatson> ogra_: netlink
<ogra_> ah :)
<Keybuk> kirkland: I can tell you about it ;)
<kirkland> ogra_: heh
<kirkland> Keybuk: please, do
<mdz> kirkland: it helps to be pid #1
<Keybuk> mdz: actually, it doesn't
<mdz> Keybuk: you just like to be contrary
<Keybuk> kirkland: it's called the "proc connector", it's a netlink socket on which the Linux kernel sends messages about fork()/clone(), exec(), exit(), setuid(), setgid() [and hopefully by 2.6.31 if akpm gets up from under the firehose] setsid()
<Keybuk> mdz: it's a hobby :p
<kirkland> Keybuk: i have a new package, powernap, that i think might benefit from such an interface
<kirkland> Keybuk: it's part of our cloud-power-management work
<cjwatson> it *used* to help to be pid 1 ...
<Keybuk> kirkland: in principal, you open a PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR socket
<Keybuk> you bind to nl_family = AF_NETLINK, nl_groups = CN_IDX_PROC
<Keybuk> then you send the kernel a secret magic message
<mvo> mdz: not a known issue (to me), I have a look
<Keybuk> the kernel should ACK that message
<Keybuk> and then the firehose starts
<kirkland> Keybuk: it's a simple python daemon that watches the process table for some list of MONITORED_PROCESSES; if none of those show up for some contiguous number of ABSENT_SECONDS, the daemon will execute a specified ACTION
<Keybuk> http://people.ubuntu.com/~scott/forkwatch.c
<Keybuk> is a trivial example
<kirkland> Keybuk: with the daemon polling at a configurable INTERVAL_SECONDS
<kirkland> Keybuk: okay, so ....
<Keybuk> kirkland: well, firstly i'd point out that such a use case is pretty much near the top of Upstart's design goals
<Keybuk> also the proc connector is a firehose
<Keybuk> you receive a massive number of events
<Keybuk> because the average Linux system spawns children like a monty python catholic
<Keybuk> (threads are children too)
<kirkland> Keybuk: heh
<kirkland> Keybuk: every sperm *is* sacred
<kirkland> Keybuk: http://bazaar.launchpad.net/~kirkland/powernap/trunk/annotate/head%3A/powernap.py
<Keybuk>   while <condition in which PROCESS should be started> and not PROCESS
<Keybuk>   after TIME
<Keybuk>   exec ACTION
 * Keybuk shrugs ;)
<kirkland> Keybuk: so this is pretty upstarty then :-)
<Keybuk> that's not to say it's not useful
<Keybuk> the timescale for me getting that kind of thing working in Upstart is a lot less than the timescale for your already-written Python script ;)
<kirkland> Keybuk: heh
<kirkland> Keybuk: thanks for the dose of realism, then
<kirkland> Keybuk: b/c this script is doing what we need it to do, right now
<kirkland> Keybuk: so i am interested in this netlink interface, though
<Keybuk> exactly, better to have software today than vapourware ;)
<kirkland> Keybuk: your inclination is that it would be more efficient than digging through /proc/*/args ?
<ScottK> kirkland: If you make the script ugly enough it might be motivational for upstart improvements.
<Keybuk> kirkland: well, digging through /proc/*/args is necessary anyway
<Keybuk> the only thing the proc connector gives you is pids
<kirkland> Keybuk: i see, so it would eliminate my polling/sleeping
<Keybuk> you still have to read /proc/$pid/* to figure out niceties such as process name, arguments, command line, etc.
<Keybuk> yes
<Keybuk> instead of polling /proc and sleeping in between, you'd continuously read from the netlink socket instead
<kirkland> Keybuk: and fire when a new pid shows up
<kirkland> Keybuk: if that pid's args matches one of my regexes, reset its counter to zero
<Keybuk> I'd err on the guess that for the specific few processes you'll be monitoring, polling /proc is sufficient
<Keybuk> it'd be more CPU/power efficient for a start
<Keybuk> (wake up once a second, not barely off the process table)
<kirkland> Keybuk: oh, but i'd need the polling anyway, to tell when i've met the sleep threshold
<Keybuk> depends whether the process is likely to come and go within IDLE
<Keybuk> which is the basic race you have
<kirkland> Keybuk: yes, documented fairly well in the config file, though
<kirkland> Keybuk: see the bottom of http://bazaar.launchpad.net/~kirkland/powernap/trunk/annotate/head%3A/config
<tgpraveen1> hi which is the channel for a beginner in open source development could find help?
<Keybuk> kirkland: if that's not a concern, I wouldn't worry about it too much
<Keybuk> kirkland: the proc connector will obviously alleviate that concern
<kirkland> Keybuk: sounds like a 2.0 feature for me then, as it's not a huge concern
<Keybuk> but it's quite expensive to read, because you get a *lot* of data
<Keybuk> now, if you want to limit the data
<Keybuk> there's another piece of undocumented Linux functionality ;)
<kirkland> Keybuk: i'm waking every 10 seconds right now, though in my testing, running every 1 second has no visible effect on load or powertop
<Keybuk> for a given socket, you can upload a basic machine code program which the kernel will execute for each packet before placing it in your socket buffer
<Keybuk> so, combine the proc connector torrent of events with a packet filter that removes everything but the specific events you're interested in
<Keybuk> and you reduce your wakeups to something manageable
<Keybuk> I'd also recommend using epoll() so you can edge-trigger the socket and back off further letting the data pool up
<kirkland> Keybuk: am i just being lazy, or does that sound like overkill for the goals of powernap?
<Keybuk> I think it's overkill :)
<Keybuk> I think you're fine just polling /proc
<kirkland> Keybuk: basically, if a machine hasn't seen [/usr/bin/kvm, or ssh:] in its process table for 5 minutes, pm-suspend
<Keybuk> right
<kirkland> Keybuk: also, what do you think of the 10 second default polling period?
<kirkland> Keybuk: nudge that up or down?
<Keybuk> given those processes, you're unlikely to be worried too much about missing them between polls
<kirkland> Keybuk: right
<Keybuk> polling proc is cheap, you don't need disk for it
<Keybuk> you could poll every second without changing the processor wakeup I'd guess
<kirkland> Keybuk: i'm actually testing this at home on my mythtv frontends, watch for (mplayer, vlc, xine, sshd:)
<Keybuk> see what works for you
<kirkland> Keybuk: cool
<kirkland> Keybuk: as always, thanks for your time and info ;-)
<Keybuk> hey that's ok ;)
<Keybuk> I've been debugging somebody's machine-that-goes-ping all day
<Keybuk> it's nice to have a distraction
<mterry> cjwatson: Regarding the ubiquity reorg, you talk about saving history and using 'bzr mv'.  But you can't move files between branches, can you?  Is there a secret bzr command for doing so?
<cjwatson> mterry: there's 'bzr join'
 * mterry RTFMs
<cjwatson> mterry: but I don't mind *quite* so much if we end up losing some file-level history from oem-config
<cjwatson> bzr join is a bit some-assembly-required
<cjwatson> I think it's probably fine to keep the history from the ubiquity tree (which is richer, in general) and to move in files from oem-config as necessary
<cjwatson> bzr join is probably overkill for this
<mterry> cjwatson: I see.  I'll try to join as possible.  Lots of it should be joinable
<cjwatson> mterry: the thing I objected to in the last discussion was that file history from the ubiquity branch had been lost as well by moving files around in it with rm/add
<mterry> cjwatson: Right
<cjwatson> I suspect you might end up wasting a lot of time with the bzr join approach
<mterry> hehe
<cjwatson> and we'd have to use special repository formats
<cjwatson> and you'll probably run into exciting bugs
<cjwatson> and it may just generally not be worth it; that's my suspicion
<cjwatson> but you asked :-)
<mterry> cjwatson: Ah, I thought most bzr branches with recent versions were already rich-roots
<mterry> cjwatson: I guess I see now that it's a special format
<cjwatson> I don't think so, even --development-rich-root is still separate
 * mterry is nostalgic for oem-config, doesn't like to see it treated as the red-headed stepchild
<cjwatson> I believe they merge with brisbane-core, but I forget
<mterry> cjwatson: Alright.  Well I'll forget it for now and just avoid losing ubiquity history.
<mterry> cjwatson: Good to know about join though
<cjwatson> we'll probably be using join for putting together debian/-only branch history with upstream
<cjwatson> so it might be doable, if you first join into a subtree and then separately worry about moving all the files into place
<cjwatson> you're bound to lose history from files that exist in both branches and need to be merged, though, absent some proposed bzr features that don't exist yet
<cjwatson> so if that's interesting to you, don't let me stop you :)
<mterry> cjwatson: Yar, natch.  But you don't mind the format requirements
<mterry> ?
<cjwatson> I guess it would be dealable with
<cjwatson> we'll be on brisbane-core soon enough anyway :)
 * mterry joins it up
<pitti> tseliot: great work on bcmwl!
<tseliot> pitti: thanks for your help ;)
<mvo> Keybuk: what was it that happend to vol_id in karmic? is it in a different package now? or replaced by something else?
<Keybuk> mvo: replaced by blkid
 * mvo updates ubuntu-vm-builder 
<tgpraveen1>  hi which is the channel for a beginner in open source development could find help?
<superm1> pitti, can you take a look an at LPIA FTBFS for bcmwl?  it's borking out in dh_strip, not sure if it's a problem in dh_strip or with the way the build was done for bcmwl
<superm1> http://launchpadlibrarian.net/28118134/buildlog_ubuntu-karmic-lpia.bcmwl_5.10.91.9%2Bbdcom-0ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> superm1: will do (in meeting ATM)
<superm1> pitti, thanks
<pitti> superm1: pkg-create-dbgsym acting up
<superm1> tseliot, it's possible you might be able to work around that FTBFS by just installing wlc_hybrid.o_shipped_x86_64 on amd64, and wlc_hybrid.o_shipped_i386 on lpia and i386
<pitti> meh, but only on lpia :/
<mvo> Keybuk: thanks
<tseliot> superm1: ok, if you're sure that this can solve the problem I can work around it in the debian/rules so that it generates a different install file from the .in file according to the architecture
<superm1> tseliot, assuming it's only going to bork out on that one file during lpia, that should work around it.  you can check by uploading to a PPA I think.  (assuming pkg-create-dbgsym runs on PPAs too)
<superm1> or if you build an lpia pbuilder with pkg-create-dbgsym installed
<pitti> superm1: it doesn't, but you can fake it by adding it as a build dep
<tseliot> pitti: by adding what package?
<pitti> tseliot: if you want to test workarounds in a PPA, add a b-dep on pkg-create-dbgsym
<tseliot> ok, thanks, I'll try it
<mathiaz> slangasek: regarding the sru for hardy 8.04.3 - looking that bug for samba and redhat cluster suire
<mathiaz> slangasek: *suite*
<slangasek> thanks
<mathiaz> slangasek: bug 290399 and bug 328874
<ubottu> Launchpad bug 290399 in redhat-cluster "After ran the command fence_tool dump, the fenced process will take 100% CPU usage" [High,Fix committed] https://launchpad.net/bugs/290399
<ubottu> Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Fix committed] https://launchpad.net/bugs/328874
<mathiaz> slangasek: I don't see how we can verify them
<mathiaz> slangasek: we don't have access to the necessary envrionement
<slangasek> oh?
<mathiaz> slangasek: bug 290399 - Test Case description: This is difficult to reproduce as it supposes a full RHCS setup and hitting the situation where those daemons enter the loop.
<mathiaz> slangasek: how can this be verified?
<slangasek> 1) set up a full RHCS setup ... :(
<mathiaz> slangasek: bug 328874
<ubottu> Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Fix committed] https://launchpad.net/bugs/328874
<mathiaz> slangasek: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/328874/comments/10
<ubottu> Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Fix committed]
<mathiaz> slangasek: the reporter doesn't have access to the domain controller anymore
<slangasek> mathiaz: he says the patch itself is good, so mostly we need regression testing there
<mathiaz> slangasek: I don't see how we can easily do the verification there
<mathiaz> slangasek: hm - right. So how do we do regression testing on the samba package?
<slangasek> mathiaz: installing it as a domain controller and shaking it? :)
<mathiaz> slangasek: what's the timeline for these verification tests to be done?
<slangasek> mathiaz: we need to have them all wrapped up in the next week
<mathiaz> slangasek: for the openldap bug 305264, I wrote up the test case and did the upload
<ubottu> Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [High,Fix committed] https://launchpad.net/bugs/305264
<mathiaz> slangasek: I thought that someone else was supposed to do the verification
<slangasek> yes
<mathiaz> slangasek: because it works in my use cases
<MacSlow> Why is there no ubuntu branch for gnome-power-manager? (like for lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu)
<slangasek> mathiaz: I asked dendrobates if the server team could help with verifications on these; I didn't tell him to pick on you specifically :-)
<mathiaz> slangasek: Oh I don't imply that. I'm looking at the bugs to see the potential work
<mathiaz> slangasek: IIUC verification requires both checking that the bug is fixed *and* that there isn't any regression
<slangasek> correct
<mathiaz> slangasek: we've got no plans to cover the latter for the samba, redhat-cluster suite and openldap packages
<slangasek> I'm not willing to assume that there's a pool of people using hardy-proposed that will see these packages and notice breakage, so regression testing has to be explicit
<slangasek> not necessarily /deep/, but explicit
<mathiaz> slangasek: agreed.
<slangasek> for openldap, the security team's test suite might be appropriate?
<mathiaz> slangasek: right - that's an option
<mathiaz> slangasek: and there is also the upstream test suite that is rather good for openldap
 * slangasek nods
<mathiaz> slangasek: for samba and redhat-cluster-suite we've got nothing AFAICT
<mathiaz> slangasek: so that means more time is needed to get the bugs verified
<mathiaz> slangasek: s/bug/upload/
<slangasek> yes; unfortunately these have each been lingering for over a month already, we need *somebody* to pick up the verification
<slangasek> sbeattie: ^^ do you have some bandwidth to set up a verification of the samba hardy SRU bugfix?  probably requires a bit more committment than the average hug dayer will want to make
<sbeattie> slangasek: yeah.
<mathiaz> sbeattie: I can outline what needs to be done in terms of regression testing in the bug
<mathiaz> sbeattie: it's probably a day of work to get everything setup correctly
<sbeattie> mathiaz: please do! my samba knowledge is somewhat shallow.
<tseliot> superm1: I've uploaded the package here: https://launchpad.net/~albertomilone/+archive/broadcom-sta
<mathiaz> sbeattie: I've updated the bug
<mathiaz> sbeattie: the biggest hurdle will be to have access to a NT/200X domain
<slangasek> mathiaz, sbeattie: Etienne should be able to get you access to one
<mathiaz> slangasek: right
<sbeattie> okay, thanks.
<mathiaz> sbeattie: another solution (that I haven't had time to investigate a lot) is to use EC2
<mathiaz> sbeattie: EC2 now has the possibility to boot windows system
<mathiaz> sbeattie: last time I tried to install AD on it, it failed though.
<sbeattie> I do have access to a win2k instance locally, but have never set it up as a domain controller.
<mathiaz> sbeattie: seems that it may be a good opportunity to dive into that :)
<superm1> tseliot, great, and it looks like that was successful on all 3 arch's too
<tseliot> superm1: ok, let me push the fix
<tseliot> superm1: ok, the fix is in revision 15. Can you check my changes, please (my eyes are very tired)?
<superm1> tseliot, yeah those look sane to me
<superm1> tseliot, bump the changelog entry up for the fix, and i can sponsor that in
<tseliot> superm1: sure
<tseliot> superm1: ok, done
<cr3> pitti: if I have a crash file under /var/crash, how can I submit it to launchpad from the command line?
<slangasek> cr3: apport-cli -c /path/to/crash
<cr3> slangasek: darn, doesn't support http_proxy environment variable :(
<ogra_> cr3, file a bug !!
<tgpraveen1> are there any plans for LIRC integration with notify-osd
<tgpraveen1> if I click play on my remote then play notification could come
<cr3> ogra_: thanks for the reminder, I added my 2c to the existing bug #370924
<ubottu> Launchpad bug 370924 in apport "apport doesn't work behind a proxy" [Undecided,Confirmed] https://launchpad.net/bugs/370924
<ogra_> ah
<ogra_> sorry for nagging :)
<cr3> ogra_: all good, my reaction was actually "meh, there's probably a bug open already" or "pitti probably knows already"
<ogra_> and he didnt fix it yet !!!
<cr3> ogra_: see, that's how confident I am that ubuntu is being tested by everyone, but there's a problem when everyone starts expecting everyone else to have done the work of reporting :)
<cr3> ogra_: there are probably issues with the fact apport runs as root, I'd expect it to not be as trivial as it sounds
<ogra_> well, as we all know pitti he usually fixes the bugs a day before they are filed ;)
<cr3> ogra_: perhaps trivial ones, but maybe he coded those bugs on purpose in the first place in order to acquire that superstar status :)
<ogra_> haha
<ogra_> karma fishing :)
<mathiaz> kees: do you know how to interpret the values Sig* from /proc/pid/status ?
<Keybuk> mathiaz: I know
<Keybuk> mathiaz: iirc, they're just all 0 :p
<Keybuk> actually, they might not be, the kernel might re-apply the SigQ to it
<Keybuk> basically they're the set of pending, blocked, etc. signals for that process
<Keybuk> SigPnd = signals pending
<Keybuk> ShdPnd = shared signals pending
<Keybuk> SigBlk = blocked signals (process mask)
<Keybuk> SigIgn = ignored signals (SIG_IGN)
<Keybuk> SigCgt = caught signals
<Keybuk> each column is a signal
<Keybuk> 1 if in the set, 0 if not
<mathiaz> Keybuk: http://paste.ubuntu.com/199475/
<mathiaz> Keybuk: these are two different mysqld_safe processes - once after an apt-get install and another after a reboot of the system
<Keybuk> oh, sorry
<Keybuk> it's hex
<Keybuk> what are you looking for?
<mathiaz> Keybuk: whether SIGHUP is ignored
<mathiaz> Keybuk: I'm tracking down bug 326768
<ubottu> Launchpad bug 326768 in mysql-dfsg-5.0 "mysqld_safe thinks mysqld has crashed when it hasn't" [High,In progress] https://launchpad.net/bugs/326768
<mathiaz> Keybuk: and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527623
<Keybuk> mathiaz: in the second one, it looks like it
<ubottu> Debian bug 527623 in mysql-server-5.0 "mysql-server-5.0: 38_scripts__mysqld_safe.sh__signals.dpatch is inherently" [Important,Open]
<mathiaz> Keybuk: so it seems that after apt-get install is run, SIGHUP is ignored by shell scripts
<Keybuk> possibly
<Keybuk> if apt sets SIGHUP to SIG_IGN
<mathiaz> Keybuk: ie shell scripts (mysqld_safe in that case, started by mysql init script) ignore SIGHUP after the mysql-server package is installed
<Keybuk> then that'll be passed on to dpkg
<Keybuk> which will be passed on to the maintainer scripts
<Keybuk> which will start the service
<Keybuk> which, if it doesn't change it, will also be SIG_IGN
<Keybuk> we should write a replacement init daemon that has a proper "start" command to avoid this kind of thing ;)
<Keybuk> one assumes though that mysqld sets SIGHUP to something else itself anyway?
<mathiaz> Keybuk: yes - mysqld installs its own handler
<mathiaz> Keybuk: however the init script uses mysqld_safe, which is a wrapper around mysqld that makes sure to restart mysqld if it crashes
<Keybuk> ah, and mysqld_safe therefore doesn't TERM on SIGHUP ?
<mathiaz> Keybuk: mysqld_safe being a /bin/sh script
<Keybuk> ./apt-pkg/deb/dpkgpm.cc:      // ignore SIGHUP as well (debian #463030)
<Keybuk> ./apt-pkg/deb/dpkgpm.cc:      sighandler_t old_SIGHUP = signal(SIGHUP,SIG_IGN);
<ubottu> Debian bug 463030 in apt "apt >=0.7.7 break menu update mechanism" [Important,Closed] http://bugs.debian.org/463030
<Keybuk> ... fail
<mathiaz> Keybuk: nope - SIGHUP is trapped so that a refresh command is send to mysqld via mysqladmin
<Keybuk> it's amazing how many people forget that your signal mask and disposition are passed onto your children
<Keybuk> mathiaz: the shell script uses trap?
<mathiaz> Keybuk: yes - http://paste.ubuntu.com/199481/
<Keybuk> mathiaz: that should set a signal-handler in the shell, surely?
<mathiaz> Keybuk: hm - apparently not
<mathiaz> Keybuk: if I send a killall -HUP mysqld_safe the refresh command is not sent to mysqld
<mathiaz> Keybuk: just after the package installation
<mathiaz> Keybuk: however it does work correctly after the system is rebooted (for ex)
<Keybuk> dash src/trap.c looks like it sets sigaction() for a trap
<Keybuk> are you sure that killall is actually sending the signal to the process?
<Keybuk> killall sometimes likes to pretend it can't see things
<mathiaz> Keybuk: well how can I make sure of that?
<Keybuk> strace
 * mathiaz tries
<Keybuk> though I admit it's suspicious that it looks like it's ignored ;)
<mathiaz> Keybuk: hm - using "sudo kill -HUP $(pgrep mysqld_safe)" gives the same result
<mathiaz> Keybuk: and stracing the kill command gives http://paste.ubuntu.com/199487/
<mathiaz> Keybuk: which seem like kill sent the SIGHUP command to the correct process
<Keybuk> yeah
<mathiaz> Keybuk: so the last comment on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527623 may be useful
<ubottu> Debian bug 527623 in mysql-server-5.0 "mysql-server-5.0: 38_scripts__mysqld_safe.sh__signals.dpatch is inherently" [Important,Open]
<mathiaz> Keybuk: especially this paragraph: http://paste.ubuntu.com/199490/
<Keybuk> right, I was just reading through the trap source code for dash
<Keybuk>                 if (act.sa_handler == SIG_IGN) {
<Keybuk>                         if (mflag && (signo == SIGTSTP ||
<Keybuk>                              signo == SIGTTIN || signo == SIGTTOU)) {
<Keybuk>                                 tsig = S_IGN;   /* don't hard ignore these */
<Keybuk>                         } else
<Keybuk>                                 tsig = S_HARD_IGN;
<Keybuk>                 } else {
<Keybuk>                         tsig = S_RESET; /* force to be set */
<Keybuk>                 }
<Keybuk>         }
<Keybuk>         if (tsig == S_HARD_IGN || tsig == action)
<Keybuk>                 return;
<Keybuk> so yeah, it looks right
<Keybuk> apt sets SIGHUP to be ignored
<Keybuk> fails to run dpkg in a clean environment
<Keybuk> dpkg passes on the ignored SIGHUP to its maintainer scripts
<Keybuk> its maintainer scripts run the initscripts
<Keybuk> so initscripts are run in an inconsistent environment
<mathiaz> Keybuk: only SIGHUP? or are there other signals ignored too?
<Keybuk> SIGQUIT and SIGINT too
<Keybuk> though those are ignored in your top as well
<mathiaz> Keybuk: right - this a little bit more worrysome: There is also a trap for INT QUIT and TERM to send a shutdown command to mysqld
<mathiaz> Keybuk: that means that after a package install, mysqld would not be shutdown properly
<mathiaz> Keybuk: could upstart be used in karmic to replace mysqld_safe (wrapper script around mysqld)?
<EvanCarroll> wow.
<kees> mathiaz: is it not documented upstream?  let me go check
<kees> mathiaz: oh, nm, Keybuk gotcha
<Keybuk> mathiaz: TERM doesn't look like it's ignored
<Keybuk> mathiaz: and yes, Upstart should be able to wrap mysqld_safe
<Keybuk> just as soon as I get 0.10 out the door
<mathiaz> Keybuk: I could upstart replace mysqld_safe (which is a wrapper around mysqld)?
<pitti> cr3: http_proxy> iz python urllib bug (and well-known)
 * pitti -> off again
<cr3> pitti: I knew there was a good reason, you might like to add that to the bug so that people know
<mathiaz> slangasek: I've updated bug 326768
<ubottu> Launchpad bug 326768 in mysql-dfsg-5.0 "mysqld_safe thinks mysqld has crashed when it hasn't" [Undecided,Incomplete] https://launchpad.net/bugs/326768
<mathiaz> slangasek: I've found a regression if bash is used as the default shell (/bin/sh)
<c_korn> when will the next daily build be available?
<mathiaz> bdmurray: hey - is there a way in LP bugs to get all the bugs that have a reply made after *my* last comment?
<mathiaz> bdmurray: I've got ~20 bugs in mysql where I have asked the same feedback to reporter and would like to go through the ones where updates have been posted
<bdmurray> mathiaz: maybe incomplete w/ response sort by date last updated?
<mathiaz> bdmurray: w/ == without?
<bdmurray> mathiaz: otherwise some python-launchpad-bugs magic should do it
<bdmurray> mathiaz: w/ == with
<mathiaz> bdmurray: thanks - seems like it gives me the list I want :)
<bdmurray> mathiaz: this url should do it https://bugs.edge.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bugs?field.searchtext=&orderby=-date_last_updated&search=Search&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=mathiaz&field.subscriber=&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&fi
<slangasek> mathiaz: hmm - why would anyone do that? :)
<slangasek> "dash is too fast for me, let's use bash instead" :)
<mathiaz> slangasek: well - apparently some people do that - there was a similar bug in openldap IIRC
<mathiaz> slangasek: hm - well - I'm not sure anymore about openldap
<slangasek> well, it's a bug certainly if the scripts aren't POSIX-clean, but I'd treat that as rather low-priority
<EvanCarroll> god these automated bug reports are overhwhelming
<EvanCarroll> 95% of them are dupes
<EvanCarroll> one program crashes and it affects 5 things, you get 5 bug reports, he does it five other times you get 25 total bug reports
<EvanCarroll> from the same person
<dtchen> TheMuso: finally getting traction with fedora folks in cooperating on sound stack issues :)
<Viper550> hey
<Viper550> http://hacktolive.org/wiki/App_Runner should be integrated somehow
<dtchen> Viper550: discussion already started; not sure if it's public aside from logs of this channel
#ubuntu-devel 2009-06-20
<cjwatson> slangasek: managing to find a case where bash isn't a strict superset of dash is relatively good going though. (yes, I know there are a couple ...)
<lfaraone> Are there any plans to make Empathy in the default in karmic or karmic+1?
<lfaraone> (default IM clinet)
<toggles> lol
<toggles> lfaraone: you missed hug day mate, https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/MessagingAndCommunicationSelection
<TheMuso> dtchen: cool.
<lfaraone> toggles: just because I empathize with your problems doesn't mean I want to get all touchy-feely about it. :P
<AnAnt> Hello
<AnAnt> regarding Depending/Recommending default-mta
<AnAnt> I worked on mutt, and changed the Recommends from exim4 to default-mta
<AnAnt> and sent that to Debian, so they just replied me with the following:
<AnAnt> the policy says that the first depend should be
<AnAnt> always a real package and not a virtual (check debian policy 3.8.2);
<AnAnt> should that be mentioned here on in the -server chanel ?
<AnAnt> debian bug 533442
<ubottu> Debian bug 533442 in mutt "mutt: Recommend default-mta instead of exim4" [Wishlist,Closed] http://bugs.debian.org/533442
<shastry> why does the ubuntu installer assume that system time is UTC? it no longer gives me the option to set it!
<shastry> i am talking about the 9.04 installer.
<lamont> slangasek: where was the discussion that convinced me that default-mta should be a Provides:?
<lifeless> ttp://lists.debian.org/debian-devel/2009/05/msg00068.html?
<lifeless> [as a link in a thread about that]
<slangasek> lamont: debian-devel in Feb/Mar, I guess?
<shaw> hrm, how do I get an arm ppa build?
<cjwatson> shaw: you don't at the moment I'm afraid; there is no working virtualisation set up for arm so PPAs can't be offered
<cjwatson> shaw: there is some hope of this changing in the future but not very short-term
<shaw> cjwatson: ok, dang.
<BUGabundo> guud day
<BUGabundo> any compiz experts around?
<BUGabundo> mvo is not here right now
<BUGabundo> hey MattJ
<MattJ> Hi
<maxb> Any devicekit-power wizards around who'd care to have a glance at https://bugs.launchpad.net/ubuntu/+source/devicekit-power/+bug/384304 and recommend how to debug?
<ubottu> Launchpad bug 384304 in devicekit-power "devicekit-power fails to realize I'm on battery" [Undecided,New]
<RainCT> Are there any plans to update portaudio? (Or, any reasons why it wouldn't be updated other than that nobody cares about it?)
<TheMuso> infinity: When you're around, mind giving me some pointers as to where I could start in debugging the powerpc texlive-base build issues experienced on the buildds? I haven't yet been able to reproduce it locally, and I'd like to get this fixed.
<dtchen> RainCT: right, no current movement, so feel free to tackle
<MacSlow> I really hate asking for help...
<MacSlow> But how is one supposed to geta  working ./configure into a package meant for building in a PPA?
<directhex> not sure i get the question
<MacSlow> well I had to update configure.in and examples/Makefile.am of notify-osd in trunk
<MacSlow> now I want to build a PPA from an earlier attempt yesterday and just include the changes to notify-osd trunk in a "distro-patch"
<MacSlow> I did that via cdbs-edit-patch and all is fine (almost i think)
<MacSlow> but the patched-in configure is not executable and the PPA-buildsytem can't find the ./configure thus fails
<directhex> make it executable in your configure-stamp rule?
<directhex> oh, cdbs. pass.
<MacSlow> and that means?
<MacSlow> I mena which file to edit?
<directhex> it means i don't know how to override cdbs behaviour enough to do what you want
<MacSlow> debian/rules
<MacSlow> is debian rules applied before or after cdbs patches are applied?
<directhex> before. debian/rules is the makefile which is executed in order to build the package. it's the makefile which contains a rule (or includes a rule from an external file) specifying HOW to apply debian/patches/foo
<Nafallo> s/before/while/
<MacSlow> btw... how comes configure isn't executable in the first place?
<MacSlow> when I initially generated the 90_autoreconf.patch after I updated configure.in and examples/Makefile.am it was executable
<lesshaste> hi
<lesshaste> hi RainCT
<lesshaste> hi mrooney
<lesshaste> hi mterry
<mterry> lesshaste: Yo
<lesshaste> I was wondering if anyone could give me advice on reporting/debugging a strange thing where "shutdown" actually "hibernates" on my laptop
<lesshaste> it's not really clear to me even which log file is relevant
<lesshaste> this is on jaunty 2.6.28-13-generic
<mterry> lesshaste: /var/log/kern.log might be useful
<mterry> lesshaste: But a likely culprit is gnome-power-manager...  Not sure where it logs to
<lesshaste> ah... I am certainly in gnome
<mterry> lesshaste: 'ubuntu-bug gnome-power-manager' will probably pull in all useful logs for you
<lesshaste> thanks
<lesshaste> how can you tell if you have just hibernated or suspended?
<lesshaste> I mean, how can you tell them apart?
<lesshaste> and ubuntu-bug crashed :)
<lesshaste> http://pastebin.ca/1467715
<mrooney> lesshaste: you might be better served in #ubuntu-bugs
<lesshaste> mrooney, thanks again
<slangasek> seb128, pitti: what has rewritten all the .desktop files on my karmic system and invalidated the packages' .checksums files?
<slangasek> (will try to file bug eventually, but am in airport right now and this is incidental to the reason I'm running debsums in the first place)
<slangasek> pitti: hmm - I think the new pkgbinarymangler stuff is rewriting .desktop files after dh_md5sums is already written out?
<slangasek> yep, looks like it... the file on the filesystem matches the one in the package, but doesn't match the .md5sums file
<Nyquist333> Anyone know how to get started working with the Grub2 project. I need to know how to get my image to run in a VM for testing. I have to add a feature for my company.
#ubuntu-devel 2009-06-21
<meoblast001> hi
<meoblast001> why is the Sun JRE even in the repos?
<meoblast001> it has absolutely no practical advantage over the OpenJDK-JRE
<zhurai> because some people prefer sun's one?
<meoblast001> yeah... aparently frostwire does too
<meoblast001> and made it a recommended dependency, so now my system is installing this useless package
<meoblast001> found a bug in the Sun JRE
<meoblast001> if you don't agree to the license it keeps asking you again
<meoblast001> and starts giving crash reports
<directhex> meoblast001, here's a reason: icedtea is broken by design, so you need proprietary java to use applets without killing your browser
<meoblast001> what do you mean?
<directhex> java applets on web pages?
<meoblast001> i mean... broken by design?
<meoblast001> you mean like www.defectivebydesign.org ?
<directhex> doesn't even remotely work
<meoblast001> i find it to work
<meoblast001> i think
<meoblast001> well.. not Icedtea... never tried it
<meoblast001> but OpenJDK-JRE
<meoblast001> and why would it be defective by design?
<directhex> sigh.
<meoblast001> it's free software... fork it
<meoblast001> design it better
<directhex> i have zero interest in java plugins from a developer standpoint. as a user, i occasionally need to use them
<meoblast001> directhex: are you trying to say that Sun purposely f***ed it up?
<directhex> i'm saying openjdk doesn't include the plugin component found in sun java
<directhex> and that icedtea is a poor stand-in
<meoblast001> lol
<meoblast001> maybe i should get gNewSense
<rendero> hello, i need the package libmysqltcl
<rendero> do i have to compile from source ?
<Hobbsee> rendero: it's already in the archives as mysqltcl.  I already answererd you in -bugs
<rendero> ok thx i will check
<ripps> Can someone please fix python-gnome2-extras in Karmic? I think the problem has to do with python-gdl.
<ripps> So, nobody knows what's going on with python-gnome2-extras in Karmic?
<lifeless> ripps: all I know is that you've asked twice here
<mrooney> lifeless: isn't okay to ask questions multiple times with an appropriate waiting period in between if no one answers?
<lifeless> TheMuso: so, dmraid
<lifeless> mrooney: Did I say it wasn't?
<mrooney> lifeless: I don't know, it seemed like a pretty negative response
<lifeless> mrooney: it was all the data I had. I figured that was better than no response at all.
<mrooney> lifeless: haha, fair enough
<mrooney> good night!
<pmatulis> what is up with the string 'really' in some package names (ex: 5.1.30really5.0.75-0ubuntu10)?
<ion_> Itâs really 5.0.75
<pmatulis> ok, but why the weird naming convention?
<ion_> See the packageâs changelog.
<pmatulis> ok
<loof> question for anyone who's awake
<loof> why hasn't ubuntu added an option to turn on/off a keypress that would run xkill?
<loof> like say kde or xfce does?
<loof> having to download xbindkeys to do it kinda sucks when it should be in the default wm
<loof> and most users don't even know they can do that
<torkiano> Hello, Can I edit this blueprint: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnome-3 ?
<torkiano> I'd like to add this link: http://www.gnome.org/~fpeters/299.html . I think that would be very useful to see the progress to Gnome 3
<torkiano> pitti, ping
<mdz> hey, that worked (switched to grub 2)
<geser> is an archive admin around (or someone else) who could me advise on versioning I should use when fixing bug 384515? what version should I use for the new .orig.tar.gz (as I also need to remove the problematic files from the source package) and not make a new upload from Debian unsyncable due to bad versioning
<ubottu> Launchpad bug 384515 in pdftk "pdftk - Files - Sun confidential code" [Undecided,Confirmed] https://launchpad.net/bugs/384515
<StevenK> geser: appending +dfsg to the upstream version is the usual method
<geser> StevenK: I know but wouldn't that make the package unsyncable from Debian if Debian uses a different +dfsg.orig.tar.gz? which I want to avoid if possible
<geser> I was thinking about using +~dfsg-0ubuntu1 for the new upload
<StevenK> geser: Yes, it would.
<geser> so we could use Debian's .orig.tar.gz when it's fixed there
<StevenK> In which case, you need to fix it, *and* choose a version that is less than Debian's new one
<geser> yes, therefore the +~dfsg which is less than +dfsg (hope Debian will use this suffix}
<geser> but perhaps there is a better solution to that
<StevenK> +arepack or so
<StevenK> Something that sorts less than dfsg
<geser> and another question for this bug: what about the version in hardy,intrepid and jaunty? I've found a patch from Fedora to build it with a packaged libitext-java but the packages and versions which this patch is for are only available in karmic
<geser> I guess the only solution would be to remove that package from those releases (it's that even possible?)
<StevenK> I seriously doubt that.
<geser> so how to solve this for the released releases? if I'm correct that is an issue there
<StevenK> I'm not certain. Repack it there too? But that doesn't fix it for the packages already in the released archive
<geser> thanks. do you know whom I should ask how to fix it for the released archive? just ask again tomorrow when more people are here?
<Laney> Is there precedent for modifying the archive (as opposed to -updates) once a release is made? :O
<napsy_> hum
<napsy_> just installed empathy 2.27.3
<napsy_> damn it rox
<tgpraveen> napsy_: how did you install ? compile from source?
<napsy_> yes
<napsy_> the adium themes are awesome
<tgpraveen> napsy_: you on jaunty?
<napsy_> yup
<tgpraveen> napsy_: could you give me instructions to compile from source
<tgpraveen> I haven't done it before
<napsy_> you just download the latest source and get the dependencies
<napsy_> then you run ./configure --prefix=/usr --enable-webkit=yes && make && sudo make install
<tgpraveen> napsy_: download the latest tarball?
<napsy_> and there you have it
<napsy_> yes
<tgpraveen> napsy_: how do I know which all are the dependencies?
<napsy_> well I installed every component that the configure script told me was missing
<tgpraveen> napsy_: also do you have the libchamplin required for the geolocation features?
<napsy_> until configure finished successfuly
<napsy_> I didn't try geolocation
<napsy_> I'm not quite sure how geolocation should work without a location source
<napsy_> e.g. gps or phone
<tgpraveen> napsy_: it will use your wifi connection or your ip address etc
<tgpraveen> I know there are many sources supported
<tgpraveen> ask on #telepathy
<napsy_> hm that can be true
<geser> why not use the empathy from the telepathy PPA? that way you don't need to compile, get package updates and can also easily remove it
<tgpraveen> geser: ppa is behind
<tgpraveen> still on 2.27.2
<tgpraveen> which is VERY buggy
<tgpraveen> .3 fixed a lot of stuff and added a few nice features
<tgpraveen> like adium themes, geolocation
<torkiano> hello, is it possible to have a PPA with bonobo free evolution packages (fedora already has a repo). more info here: http://mbarnes.livejournal.com/3002.html
<torkiano> Gnome 3.0 transition is more easy with that packages ;)
<dlec> hi
<dlec> whats the noteable differences in the new ubuntu
<dlec> ive got the new kernel and all
<dlec> dont see anything visibly different
<dlec> not even ff3.5
<dlec> anyone awake
<highvoltage> no
<dlec> erm
<highvoltage> dlec: well, karmic isn't even 25% done yet (thumbsucking a number)
<highvoltage> dlec: it will be a few months until you can see some bigger changes in karmic vs jaunty
<dlec> ohh
<highvoltage> dlec: although I've seen quite a few smaller things so far because of the newer versions of the newer software installed
<dlec> i see
<dlec> so then my updating was a waste? :/
<highvoltage> dlec: for example, my intel graphics is notably faster, transmission has lots of little improvements, and gnome has a big bunch of bug fixes
<dlec> highvoltage i just moved to jaunty.
<highvoltage> dlec: aaah
<dlec> i guess i'll stay 2 months behind
<highvoltage> dlec: well, in that case, check the release notes and the release announcement
<dlec> it'd be no fun if everyone patched their shit immediately.
<dlec> :P
<highvoltage> dlec: it should tell you everything you need to know. in my opinion Jaunty wasn't the most exciting release ever though
<dlec> why though
<dlec> im only concerned about security and kernel stuff
<dlec> as far as those are concerned how well does jaunty do
<highvoltage> dlec: pretty much as good as any other ubuntu release so far. the jaunty kernel doesn't play well with Intel graphics drivers though, which is the only problem I've had with it personally
<dlec> are you an ubuntu dev
<dlec> ohh
<highvoltage> dlec: besides that it's a very solid release, many are calling it their favourite release
<dlec> thats not good is it
<highvoltage> dlec: nope, not yet anyway
<dlec> what are the common issues
<dlec> if any
<dlec> with intel drivers
<dlec> so i install a generic kernel?
<dlec> is that what jaunty recommends?
<dlec> i just installed the new kernel
<highvoltage> if you install a desktop machine, yes
<highvoltage> -generic is good.
<dlec> i have some sort of nvidia joint
<dlec> and it is -generic as of now
<dlec> 2.6.28-13-generic
<dlec> ok im good to go then
<highvoltage> yep
<dlec> thx!
<highvoltage> you're welcome
<ScottK> Any other archive admin around who's up for some weekend clamav backport fun?
#ubuntu-devel 2010-06-21
<ebroder> Does anybody know if there's a D-Bus method or some way for me, as root, to force the GDM greeter to login as a particular user (on demand, so not something like auto-login)
<dholbach> good morning
<orangey> hello all
<orangey> I'm trying to compile a new kernel
<orangey> and I'm doing it with: sudo make -C /usr/src/linux-headers-`uname -r`  M=`pwd`
<orangey> however, it will NOT compile this new file!
<orangey> it DOES compile properly all the OLD files, though
<dholbach> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild might be helpful
<dholbach> and #ubuntu-kernel
<orangey> dholbach: thank you
<orangey> i've already been through that page
<dholbach> there's nothing about "sudo make" in there :)
<orangey> right.. make would work too : )
<dholbach> and you don't seem to use mak-kpkg
<dholbach> make-kpkg
<dholbach> but I should shut up now, I haven't built a kernel for like 10 years now, never necessary
<jussi> hahah!
<orangey> ; )
<orangey> dholbach: a lot of that is the obviously ill-fated attempt to compile a single directory instead of every part of the damned kernel
<orangey> sadly, time-saving elegance will take me way more time than if I would have just done it the hard way
<pitti> Good morning
<seb128> mr_pouit, hi
<seb128> mr_pouit, you could maybe send the goffice intltool update change to the debian bts, usually they take such changes it doesn't cost them a lot and it allows to sync between distros
<seb128> ScottK, hi, what is cpp doing in poppler exactly? and I would appreciate you pinging before doing such changes to it next time
<Cheery> what's the reason for: 64-bit - Not recommended for daily desktop usage ?
<Cheery> oh. google told me already
<Cheery> cya.
<seb128> ScottK, you also added tons of html documentation changes to the diff.gz
<seb128> ScottK, the diff also has a cdbs-package-list which is not described in the changelog
<mr_pouit> seb128: yeah, it's on my todo list, but I didn't have the time yesterday
<seb128> mr_pouit, ok, I've noticed that like 2 cycles ago when doing merges but I forgot about it since, thanks
<seb128> directhex, Laney: I'm not sure uploading the new f-spot to ubuntu without the ubuntu changes was something we want to do
<seb128> didrocks, Laney: Debian might not care about Ubuntu changes but we do...
<Laney> seb128: RAOF is already prepping them for upstream
<Laney> I do care about those changes :)
<directhex> Laney asked me to sync! :(
<directhex> brb minibus
<seb128> Laney, well they are dropped now though
<Laney> yeah it was all me, not him guvna
<seb128> wouldn't it make sense to still include the updated version in Ubuntu until he manages to get those in git?
<Laney> they required porting for the new upstream release
<Laney> and it seemed sensible for only one of us to do that
<seb128> yeah, not discussing
<seb128> I would just have waited for those to be ported and did a merge on debian
<seb128> but I guess that's fine to have those off for a short time
<Laney> I thought it was a win to get the new release some testing given that we will get the other changes back very soon anyway
<seb128> I just wouldn't like that to stay they way for half the cycle because it takes time to get things upstream
<seb128> ok, fair enough
<seb128> Laney, thanks
<Laney> no problem
<bigon> robert_ancell: hi, is this change http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550478 really needed? Josselin is not really happy with putting things for thesting only to production pkg
<ubottu> Debian bug 550478 in gobject-introspection "gobject-introspection: Please include the Everything-1.0 typelib" [Minor,Open]
 * RAOF stops wrangling the intel DDX and switches to f-spot hacking modeâ¦
<directhex> i'll do mono 2.6 as soon as 2.6.4 is in debian
<directhex> there are no major changes this time, it's a straight update
<directhex> i.e. no need to worry about transition stress
<tseliot> cjwatson: do you know how I can make sure that the following parameter show up as it is in grub.cfg (without any of the backslashes or of the quotation marks being escaped) if I put it in /etc/default/grub ? acpi_osi=\"!Windows 2009\"
<cjwatson> tseliot: there's a bug about that somewhere, I think you have to doubly-quote it or something stupid
<cjwatson> oh, or maybe not even that
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550319
<ubottu> Debian bug 550319 in grub-pc "grub-pc: grub2 does not honor quoted kernel command line arguments" [Important,Open]
<cjwatson> we need to sort it out upstream, I don't think there's a good answer right now
<tseliot> cjwatson: ok, thanks
<tseliot> cjwatson: acpi_osi=\\"\""!Windows 2009\\\"" did it (the last quotation marks are meant to end the line)
<ScottK> seb128: I packaged it because a KDE upstream developer was here over the weekend asking that it be added.  I didn't get the impression from your debian/changelog entry that there was any reason not to.  I did have him verify that the library works in the package before I uploaded it.
<zyga> anyone else sees problems running current virtualbox 3.2.4 on Lucid?
<zyga> I keep getting my VMs crash on disk issues
<ScottK> I'm not sure why there are html documentation changes and cdbs-package-list now in the diff.gz.  I didn't make any changes related to those.
<seb128> ScottK, you likely build it twice without cleaning the source and the clean target is buggy
<seb128> ScottK, what is the cpp backend doing exactly?
<ScottK> seb128: As I understand it it's just a different library you can build with if that's your preferred interface.  He was specifically concerned that developers would avoid this new library if it wasn't available in Ubuntu.  Sorry about the clean problem.
<ScottK> If you want to discuss it, I'll ping him when he's online.
<seb128> ScottK, no, I planned to chat with poppler upstream about the new lib that's why I didn't active it in the first upload
<seb128> ScottK, thanks for working on the change, I would still appreciate if you could ping on IRC about such changes next time
<seb128> ScottK, there is often a reason why changes are done a way
<ScottK> seb128: I did look and you weren't online.  I didn't get a hint from debian/changelog that there was a reason to wait.  Sorry for any confusion.
<seb128> that's ok
<seb128> lunch time; bbl
<didrocks> seb128: enjoy
<baptistemm> hello
<IdleOne> When doing apt-cache policy package. Shows if package is installed or not and version, it also shows a repository, is that the repository it was downloaded from or is that info contained in the package ( meaning the repo can be faked)?
<IdleOne> I am asking because I want to know if that information can be used to authenticate (for myself) if the package is trustworthy
<cjwatson> IdleOne: it's the repository that it would be downloaded from if you were to install it now
<cjwatson> it's not information from the package
<IdleOne> cjohnston: is there a way of finding out what repo a package was installed from?
<maco> apt-cache policy <package> ?
<maco> oh wait you already said that
<maco> IdleOne: zgrep through /var/log/apt/term*
<IdleOne> Someone just asked about Gparted in #u I asked where he got it from and he seemed unsure. He said it spit out an error about possibly malicious software
<maco> IdleOne: you can see the path from which it wget'd
<IdleOne> maco: thank you :)
<cjwatson> IdleOne: other than log files as maco suggested, that information is not stored anywhere machine-parseable
<cjwatson> the error you mention could be an attack, or it could be fixed by running 'sudo apt-get update'
<maco> cjwatson: you should see the chain of pipes i concocted to get the date the current version was installed like rpm -qi gives!
<IdleOne> maco: example command for zgrep?
<IdleOne> I did zgrep gparted zgrep through /var/log/apt/term* but it did not return useful info
<maco> IdleOne: just use it like grep
<IdleOne> errr
<maco> zgrep is grep for .gz's
<IdleOne> zgrep gparted /var/log/apt/term*
<maco> IdleOne: do you have it installed?
<IdleOne> yes
<maco> er sudo that too
<IdleOne> yup
<IdleOne> gives me 3 lines of output but nothing about wget info
<maco> :-/ youre right. term.log just has the unpacking process
<IdleOne> I guess my question is How can I be sure that a package came from a secure repository?
<IdleOne> not for my personal systems. I know what repos I use but more for support of other users in #u
<jpds> IdleOne: Check the sha1 of the package in /var/cache/apt/archives/ ?
<siretart> seb128: hi. last week you said that you "will see if we can find somebody interested" to write a MIR vor libvpx. Did you find someone?
<seb128> siretart, no
<seb128> siretart, hi btw ;-)
<siretart> :-)
<IdleOne> jpds: I guess so.
<IdleOne> thanks for the answers folks
<baptistemm> hello, anyone to review lp:~bluetooth/ubuntu/maverick/bluez/main and lp:~bluetooth/ubuntu/maverick/obexd/main? :)
<ScottK> doko: Did you plan to merge python-defaults and python3-defaults soon?  We've got packages depwaiting on the newer versions for dh_python{2,3}.
<doko> ScottK: later this week, go ahead with merging if you like
<ScottK> doko: Is it OK to use the current python2.6 version as the minimum required?
<doko> ScottK: no, but python2.6 is almost syncable, just the version numbers in the maintainer scripts have to taken from the ubuntu packages
<ScottK> So 2.6 needs updating first.
<ccheney> doko, will you be looking at the OOo related MIRs from a few weeks ago? :)
<ScottK> slangasek: I see at least one package in Debian using the Boost MPI bits.  We've been stripping them out as "not used" and that's no longer true.  Any thoughts on how to deal with this?
<dabaR> Anyone seen SVN conflicts now creating a .u1conflict file?
<dabaR> Oh, is it an UbuntuOne thing?
<dabaR> Yes it is.
<hunger> cd
<hunger> Sorry:-/
<smoser> james_w, or other, when i use quilt 3.0 format in a packaging bzr branch, I think that I"m supposed to commit with patches applied (ie, 'quilt push -a' rather than 'quilt pop -a').  Is that correct ?
<james_w> smoser: yeah
<cjwatson> that's what I do
<smoser> hm..
<smoser> so i commited some i know (have to think about which ones)
<smoser> and pushed to the packaging brnach (lp:ubuntu/maverick/<package>) with the patches *not* applied
<smoser> would that cause issues ?
<slangasek> it gives you a branch there that doesn't match what the importer would create
<slangasek> best to fix it up when you have a chance
<smoser> ok. thanks.
<Nhdb> why is it so hard to create a deb-package of a simple application? :/
<ion> Itâs not that hard.
<Nhdb> dh_make, pbuilder, debhelper, everyone seems to do it in a different way
<azeem> those three are orthogonal
<Nhdb> yeah, but they are all optional it seems
<azeem> the stress being on "optional"
<ion> You better use debhelper rather than NIH it.
<Nhdb> I've got a simple python I want to package, but I'm stuk on the debian/rules (seems to be the hardest part)
<Nhdb> currently it contains only "%:     dh $@"
<Nhdb> how can I fill it so my application will go to /usr/share/?
<azeem> applications go to /usr/bin
<Nhdb> the program I have has multiple (python) source files
<Nhdb> so that should go to /usr/share/ right?
<azeem> depends
<Nhdb> on what?
<azeem> on your application
<azeem> does it have a setup.py?
<ion> See the python-central package and dh_pycentral
<Nhdb> yeah ok, I've got multiple python files, and 1 is called main.py and is executable, I don't have a setup.py
<azeem> Nhdb: how is your application started?
<Nhdb> azeem: "./main.py" or "python main.py"
<ion> nhdb: See e.g. debian/rules in the source package of apturl.
<Nhdb> ion: thanks, got it
<cjwatson> the intent of that tiny debian/rules is that most standard packages should never need to touch it at all; that includes packages with a working reasonably standard setup.py
<azeem> btw, does it also support cmake?
<cjwatson> yes
<cjwatson> /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm
<azeem> cool, thanks
<Nhdb> so I'm a bit confused about what my debian/rules should actually do, how does the system know what to put where?
<azeem> if you don't have a standard build system, you need to do it manually
<cjwatson> long story but the short form is don't worry about it and write a working setup.py and it'll figure it out
<azeem> also, consider renaming your application to something else than "main.py"
<cjwatson> but what actually happens is that dpkg-buildpackage calls 'debian/rules build', which that debian/rules expands to 'dh build', and then you can read 'man dh' for what happens next; likewise, it then calls 'debian/rules binary'
<cjwatson> 'dh <target>' expands to a bunch of individual commands, which you'll see output in the build log when you build a package that uses that tiny debian/rules
<cjwatson> and you can read the man page for each command to find out what it does
<Nhdb> hm okay, I think I'll go find some docs on how to write a setup.py and go that route
<cjwatson> for instance dh_auto_install knows to call 'setup.py install --force --root=$destdir --no-compile -O0' or something along those lines
<cjwatson> but it's easier to let dh_auto_install do it for you unless you have some unusual requirements
<cjwatson> if you need to install individual simple extra files, 'man dh_install'
<cjwatson> etc.
<Nhdb> cjwatson: hmm oke thanks
<Nhdb> cjwatson: sounds like a ton of work :)
<cjwatson> Nhdb: nah, pretty easy really, certainly quicker than crafting it all by hand at least once you're used to it
<ebroder> Does anybody know how I, as root, can force GDM to login as a particular user?
<ebroder> (from the greeter)
<geser> as a last resort: configure temporarily an auto-login for that user
<micahg> pitti: are the retracers working?
<ebroder> geser: Hmm...do you know if I do that without restarting GDM?
<Cheery> do you know how to install opencl development stuff for ubuntu?
<Cheery> I have CL -directory, but there's not headers here.
<slangasek> superm1: a mythbuntu test build completed, so it seems you're consistently running into the mirror skew bug on antimony.  I guess we'd better find a resolution to that...
<cjwatson> skew> might be able to avoid it by rescheduling
<slangasek> maybe, but if it's a problem now when it wasn't before, that means builds are now overlapping that previously weren't; I think we should bite the bullet and get proper locking in that script
<gaurav> https://help.ubuntu.com/community/Kernel/Compile is this documentation still valid for 10.04 ?
<gaurav> ignore i got the answer :p
<ScottK> cjwatson: Would you have a little time later in the week to talk with me about Germinate?  For Kubuntu in 10.10 we are trying to build two metapackage variants out of main/restricted and one out of main/restricted/universe.  The only way I found to do this so far is too ugly to even describe in public.
<cjwatson> ScottK: I don't have much synchronous time, but I should have plenty of asynchronous time (mail or whatever)
<ScottK> cjwatson: OK.  Thanks.  I'll try to write it down and mail you,
<jjardon> Hello, seems that the glade documentation is not packaged. Should I fille a bug?
<jjardon> (the user manual and the developer manual, both included in the tarball)
<seb128> jjardon, the user documentation is in the binary?
<jjardon> seb128, in the glade tarball, yes
<seb128> jjardon, in the installed deb as well
<jjardon> oh. Maybe a bug in glade itself then
<jjardon> The not installed doc It's the devel doc, sorry
<jjardon> http://library.gnome.org/devel/gladeui/
<seb128> jjardon, it's in libgladeui-1-dev
<jjardon> oh, yeah. Sorry for the noise
#ubuntu-devel 2010-06-22
<slangasek> ScottK: boost MPI> well, it's a long MIR chain if we pull that all in; I'm not convinced that's what we want to do
<ScottK> slangasek: The package in question is in Universe.  I was thinking maybe finish the 1.40 -> 1.42 transition in Main and then add the MPI stuff back to 1.40 in Universe.
<ajmitch> ScottK: you want to keep 1.40 around?
<ScottK> ajmitch: Not particularly, but there's at least one package using MPI now and so it'd be an alternative to MIR for the entire MPI stack.
<ajmitch> then I'd better merge it at some point
<ajmitch> unless you prefer to do it
<ScottK> No.  I never "prefer" to touch Boost stuff.
<ajmitch> I was afraid of that
<ScottK> We need to drop it to Universe first if it hasn't already.
<Cuervo> foes the c library offer any interfaces to kvm?
<Cuervo> *does
<ajmitch> it's still in main at the moment
<Cuervo> and if so, how do I access them?
<ScottK> It may not need to be/
 * ScottK investigates
<ajmitch> it still had a few rdepends when I looked last week, but I didn't check if any were in main
<ScottK> None are in Main.
<ScottK> slangasek: Unless you have a better idea for dealing with MPI, would you please demote all the boost1.40 stuff to Universe and we'll get it restored that way (it's in compononet mismatches)
<ajmitch> if I'm to do the merge, want me to add in the MPI stuff at the same time?
<ScottK> ajmitch: Yes.  Please.
<ScottK> No particular reason to wait either.  It should just dep wait until it's demoted.
<ajmitch> it's the majority of the changes carried from debian at the moment
 * andreserl TestDrive PyGTK Front-end Demo Released!
<ajmitch> andreserl: how many channels was that in? :)
<andreserl> ajmitch, uhmmm 15?? most of them #ubuntu-* :)
<ajmitch> andreserl: posted to planet ubuntu yet?
<andreserl> ajmitch, I'm about to :)
<ajmitch> since you provided no url or screenshots for me to look at
<andreserl> ajmitch, yeah I'm finish writing the blogpost, though there are screenshots: http://www.roaksoax.com/2010/06/gsoc-update-of-the-week-testdrive-pygtk-front-end-3 http://www.roaksoax.com/2010/05/gsoc-update-of-the-week-testdrive-pygtk-front-end-2
<ajmitch> looks good, I might need to try it out :)
<superm1> slangasek, hm, that (otherwise) successful build appears to have a livefs that's about 10 days old
<superm1> even though the livefs from today was success filled
<andreserl> ajmitch, http://www.roaksoax.com/2010/06/gsoc-update-of-the-week-testdrive-pygtk-front-end-4
<ajmitch> andreserl: nice, so it does work well with virtualbox?
<andreserl> ajmitch, it works :)
<orangey> hello all!
<orangey> hmm.
<orangey> any tips on testing out the latest alsa from lucid?
<TheMuso> orangey: When you say testint out, what do you mean exactly?
<orangey> TheMuso: well, I'm using lucid and am having difficulties with my sound card, so wanted to put the new driver set in place.
<orangey> for which, yes, there are PPAs
<orangey> but on the face of it, doesn't seem like it's working
<TheMuso> orangey: Right, there are some unusual build failures that haven't yet been solved, and are unfortunately something that upstream will have to resolve, at least unless another member of the audio team manages to do so.
<TheMuso> orangey: The only way to test newer also code atm is to build your own kernel, or use one of the kernel team's mainline builds.
<orangey> TheMuso: gotcha
<orangey> I'm trying this now, but it's out of the #devel territory by now: http://ubuntuforums.org/showthread.php?p=6589810
<TheMuso> orangey: I don't endorce that method, as there is a chance it will break something.
<orangey> TheMuso: I've looked through the shell and agree ; )
<dholbach> good morning
<slangasek> ScottK: ah, boost1.40 demoted, then :)
<slangasek> superm1: ah; the livefs buildds moved, but the script to download the built images isn't in sync. :/ fixing
<superm1> slangasek, ooh fun.
<slangasek> superm1: running another test
<superm1> slangasek, mkay thanks
<orangey> hmm.
<orangey> is there any way for me to figure out the ID of an alsa device?
<orangey> i.e., the microphone of sound card 0?
<TheMuso> orangey: What do you mean by id?
<orangey> the identifier like "hw0,0"
<TheMuso> manjo: You can't refer to a sound card's indivudla inputs/outputs like that, at least for the most part.
<TheMuso> manjo: sorry not meant to go to you.
<TheMuso> orangey: ^^
<orangey> : )
<orangey> TheMuso: not true. you CAN
<orangey> e.g., in pulse configs
<hyperair> hmm what's the difference between gstreamer0.10-fluendo-mp3 and gstreamer0.10-fluendo-plugins-mp3-partner?
<TheMuso> orangey: Please explain then.
<orangey> TheMuso: well, the card is 0
<orangey> i.e., hw:0
<orangey> then the particular subdevice or whatever is ,whatever
<orangey> so that the default device is usually hw:0,0
<orangey> is that what you're asking?
<TheMuso> orangey: No, you asked about how one could use the mic etc via hw:0, and I said it was not possible.
<TheMuso> orangey: It is possible by setting the capture device through the mixer, and recording from hw:0 etc.
<orangey> TheMuso: pulseaudio is incorrectly detecting my internal mic
<orangey> I want to help it by pointing it to the correct one
<orangey> if I knew its internal alsa ID, I could
<pitti> Good morning
<TheMuso> orangey: run alsamixer and look for the string that identifies your mic.
<TheMuso> orangey: Then you need to look at the files in /usr/share/pulseaudio/alsa-mixer/ to adjust things appropriately.
<orangey> intriguing
<geser> Riddell: could you please kill http://people.canonical.com/~ubuntu-archive/NBS/rdoc? All versioned dependencies (without an alternative) on rdoc should be gone and ruby provides rdoc. The real rdoc deb prevents that several ruby packages can currently get build in maverick as ruby conflicts rdoc and the buildds try to install both.
<pitti> geser: thanks for checking! killed
<nigelb> We now have http://wiki.debian.org/DerivativesFrontDesk
<dholbach> and a debian-derivatives mailing list
<nigelb> dholbach: worth adding to the Debian page on w.u.c?
<dholbach> Alsoâ¦ we have an Ubuntu Developer Week schedule to fill: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep - if you're interested in giving a session or suggesting one, please go ahead and add it :)
<dholbach> nigelb: totally
<nigelb> dholbach: you should probably also write to -devel (about front desk and developer week)
<dholbach> nigelb: or you!
<dholbach> I'll write about UDW :)
<nigelb> dholbach: my mails get moderated :/
<cjwatson> that can be rectified
<nigelb> doh, of all the times for you to pop in :P
 * nigelb goes to write mail
<cjwatson> tell me when you've sent it
<hrw> hi
<hrw> dholbach: alive?
<geser> cjwatson: should bugs using your openssh PPA on lucid also be filed in LP?
<cjwatson> geser: yes please, just mark them clearly
<cjwatson> geser: (see http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2010-05-10-openssh-5.5p1-for-lucid.html)
<dholbach> hrw: yep
<hrw> dholbach: as part of "Ubuntu Developer Week" would be nice to have a talk about blueprints/specs/workitems - what they are and how they are supposed to be used
<dholbach> hrw: can you add it as a suggestion to the bottom of the page?
<dholbach> hrw: I guess it could be useful
<hrw> added
<hrw> dholbach: took me a while to find out about them
<dholbach> hrw: excellent, thanks
<jpds> 3
<hrw> dholbach: and I still think that they are made wrong way
<dholbach> hrw: what exactly do you think is wrong? the format of specifications? the way we track work items?
<geser> cjwatson: I just checked and the version in lucid has the same problem (filing a bug anyways)
<hrw> dholbach: using whiteboard for work items + status + notes. it should be split into work items (handled like bugs but not being bugs), status/notes should be wiki (so history is present)
<cjwatson> everyone involved acknowledges that work items are a hack
<hrw> dholbach: and status of how many workitems exists and how many are completed should be part of LP not external service
<dholbach> hrw: I filed a bug about it part 1 of your complaint
<dholbach> I can try to find it
<dholbach> but I'm sure the LP folks would love help with that
<hrw> from my perspective as new developer in ubuntuland it looks like hack on hack which everyone is fine with
<dholbach> and I'm sure they'd agree
<hrw> dholbach: I can share ideas not code
<dholbach> hrw: it's quite easy to criticise the LP team
<hrw> dholbach: I know, they do lot of great work
<dholbach> (and give them yet another idea :))
<cjwatson> hrw: the perfect is sometimes the enemy of the good
<hrw> and I know that I can create a bug for each work item to have a way to track each of them
<cjwatson> having something available now which is distinctly suboptimal but works is better than having a perfect design which nobody has time to implement
<hrw> cjwatson: thats also true
<cjwatson> and we've been consistently told that blueprints is unmaintained
<DktrKranz> mvo: hi! what do you think about uploading gdebi to unstable and sync it to maverick shortafter? There are some good fixes already. Or do you prefer waiting to merge python-apt branch?
<cjwatson> and yet we're fairly committed to using it, so it makes sense to make do
<mvo> DktrKranz: sync sounds good, I can do the python-apt merge today I think
<mvo> DktrKranz: will you be able to do the debian upload?
<dholbach> hrw: bug 578263 was what I was talking about
<cjwatson> it was all done outside of the LP team, so there's nothing stopping somebody else implementing something better
<ubottu> Launchpad bug 578263 in Launchpad Blueprints "Add "work items" to blueprint" [Low,Triaged] https://launchpad.net/bugs/578263
<DktrKranz> mvo: sure thing
<mvo> thanks .)
<hrw> thx
<DktrKranz> not before this evening, though :)
<cjwatson> but that's a little different from saying that we shouldn't be using what we have
<hrw> cjwatson: I did not said 'lets abandon blueprints'
<DktrKranz> mvo: mind give me a ping when you perform the merge?
<mvo> DktrKranz: sure
<DktrKranz> thanks ;)
<nigelb> cjwatson: sent :)
<cjwatson> nigelb: moderated, and your postings should be accepted in future.  (please send plain-text mail rather than alternative text+HTML, though.)
<ajmitch> there has been a little bit of work done on blueprints, hopefully it'll get in
<nigelb> cjwatson: its the gmail thingie.  Im away from my evolution.  It formats it correctly
<ajmitch> and yeah, using the whiteboard for tracking work items is a bit of a nasty hack :)
<nigelb> ajmitch: I'd love to see all blueprints where I have been assigned a task.  NOw I have to keep a seprate list
<ajmitch> nigelb: yes, that'd make sense - I think the original intent was to have lots of blueprints linked through their dependencies
<nigelb> ajmitch: what happens now is if the blueprint is not part of series, it doesn't get shown anywhere.  I wish we had a "collect all" page where all blueprints discussed at uds would turn up
<ajmitch> an interim step to get rid of the screen scraping in the work items tracker is to expose those properties on blueprints via the API
<nigelb> +1 to that
<nigelb> like having a feature of assigning people to each task in the blueprint
 * ajmitch hopes that exposing some of the API can land in the next month or so
<mvo> DktrKranz: i just checked and the maverick python-apt version should be very up-to-date, no code changes in the merge
<nigelb> ajmitch: we should pester jorge or someone from LP team
<ajmitch> nigelb: for which part?
<nigelb> ajmitch: for the LP-related part
<ajmitch> I mean for which part of blueprints? the basic API stuff is almost there
<nigelb> if we start a dialogue now, we can have something by next uds
 * ajmitch has looked at it a bit
<nigelb> ajmitch: ah, I didn't know you worked on LP in your free time :)
<ajmitch> nigelb: infrequently :)
<nigelb> ajmitch: rocking :)
<ajmitch> as in, I haven't got anything in yet
 * nigelb hasn't touched LP (yet :D)
 * apachelogger pokes pitti with http://paste.ubuntu.com/453322/ and hopes some thoughts on that matter will fall out of him ^^
<apachelogger> usb-creator has the same problem supposedly
<apachelogger> or really anything created by intltool I would argue
<pitti> apachelogger: I know that a thing like "context" exists in translations, but why does it need to be mandatory?
<pitti> I'm afraid I don't quite understand the problem
<apachelogger> pitti: It is not mandatory it just happens to be used in the KDE templates, hence our desktop-file-translation-from-mo patches do a context+value lookup instead of just value
<apachelogger> Suffice to say that a context would probably also help translators in this particular case, since one might not know that a comment is really a comment unless launchpad tells one that this is a comment ;)
<pitti> apachelogger: i. e. we need to fix the build system to add a context to the strings extracted from the .desktop.in?
<apachelogger> pitti: I do think so.
<pitti> (that would need a new option in python-distutils-extra, I figure)
<apachelogger> pitti: Do you want a bug report about it?
<pitti> please, with the details
<apachelogger> pitti: against python-distutils-extra?
<pitti> right
<pitti> that should provide the functinoality
<pitti> and then we just need to set the context name or enable the option in jockey
<apachelogger> ok, will report in a bit
<juliank> didrocks: You can also contact me here on dh-autoreconf stuff.
<didrocks> juliank: oh perfect, that will be quicker next time :)
<didrocks> juliank: thanks for your work on dh-autoreconf btw, it's really great and avoid generating an autoreconf patch each time :)
<ajmitch> juliank: were you still planning to do http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559752 ?
<ubottu> Debian bug 559752 in wnpp "ITP: ubuntuone-client -- Ubuntu One client" [Wishlist,Open]
<juliank> ajmitch: If you want, you can take them. I'm already maintaining the whole high-level package management GNOME world and writing a new package manager, so I think I have enough. If you want to, I can co-maintain it.
<ajmitch> juliank: alright
<ajmitch> it's a bit easier now that 2.6 is default in debian
<ajmitch> you seem to have a bit on your plate at the moment :)
<juliank> ajmitch: There are also some licensing issues to sort out first (https://bugs.edge.launchpad.net/ubuntuone-storage-protocol/+bug/583335) before this can go into Debian.
<ubottu> Launchpad bug 583335 in Ubuntu One storage protocol "contrib/mocker.py has __license__="PSF License"" [Low,Triaged]
<juliank> That was probably the reason why I paused working on it.
<ajmitch> right, thanks for the heads-up on that one
<ajmitch> looks like it just got fixed, too
<didrocks> juliank: I saw you new feature. I don't see for now package where we would need it for now, but it sounds good :)
<juliank> mvo: Do we want to sync sessioninstaller? (I took the Ubuntu tarball, so it should work)
<juliank> The tree being at lp:~juliank/sessioninstaller/debian-sid
<juliank> if you want to merge it.
<apachelogger> pitti: bug 597216
<ubottu> Launchpad bug 597216 in python-distutils-extra (Ubuntu) "add a context to the strings extracted from .desktop.in" [Undecided,New] https://launchpad.net/bugs/597216
<pitti> apachelogger: thanks
<mvo> juliank: hello! sounds good, I will do a sync request. thanks for the update
 * apachelogger leaves bug 290351 on the desk of cjwatson ;)
<ubottu> Launchpad bug 290351 in casper (Ubuntu) "live session user and host should be called kubuntu on kubuntu" [High,Confirmed] https://launchpad.net/bugs/290351
<Riddell> can't say I'm fussed about that issue myself
<apachelogger> cjwatson: supposedly we just need to have a different casper.conf installed for kubuntu or whoever wants to have a different setup?
<cjwatson> I can't deal with it now, sorry
<apachelogger> k :)
<engla> DktrKranz: I see you are involved in packaging shotwell. that's a great program, thanks for doing that.. :)
<DktrKranz> hi engla! yeah, currently doing porter work to let it build everywhere ;)
<engla> debian has very ambitions goals in getting it to work on even kfreebsd, I imagine many packages can be tricky
<DktrKranz> that is easy, I just have to adjust patch originally provided by "regular" porters ;)
<DktrKranz> and once 0.6.0 is released, I plan to get it in sync with Maverick (it's better to avoid duplicating efforts)
<sri> so, I have hald running on lucid and I suspect it is an artifact of an apt-get dist-upgrade from karmic.. how do I get off of hald?
<sri> actually I'm probably asking the wrong channel. sorry about that.
<DktrKranz> mvo: cool, so merge should be easy
<ricotz> seb128, hello, will maverick ship a gsettings enabled gconf?
<seb128> ricotz, hi, no
<seb128> ricotz, desrt said that backend should not be shipped in distros
<seb128> ricotz, it's hackish and made for hackers porting their code not for being used
<ricotz> seb128, ok, thank you
<seb128> you're welcome
<seb128> ricotz, do you need it for something?
<ricotz> seb128, gnome-shell currently using it and therefore settings are broken
<seb128> oh ok
<seb128> I guess talk with desrt and g-s guys and get them to agree on what to do
<ricotz> alright
<seb128> I'm fine with shipping the gconf backend if that's what we should do
<seb128> but he told us to not ship it at uds
<ricotz> seb128, i was thinking to put an enabled gconf into the gnome-shell ppa
<qense> directhex: Did you see the bug reported against banshee-community-extensions already? :) banshee-extension-appindicator needs to be rebuilt on Maverick because of changes to the Mono bindings of libappind on 0.2.1
<directhex> qense, i didn't see the bug. is appind all fixed up now? i know hyperair was contributing to that
<hyperair> qense: er i just test built, forgot to upload.
<qense> directhex, hyperair: It seems the problem is solving itself already now. :)
<qense> hyperair: thanks!
<hyperair> directhex: what do you do with a library that doesn't break ABI in terms of interfaces/symbols, but screws itself up anyway through some weird exceptions or other?
<hyperair> Bug #597283
<ubottu> Launchpad bug 597283 in banshee-community-extensions (Ubuntu) "banshee-extension-appindicator needs to be rebuilt for Maverick (appind 0.2.1-0ubuntu1)" [Undecided,New] https://launchpad.net/bugs/597283
<hyperair> directhex: ^^
 * hyperair staggers into bed
<qense> hyperair: sleep well
<directhex> hyperair++
<ccheney> doko_, i was wondering if you were going to be able to process the OOo related MIRs I filed about 2 weeks ago?
<ccheney> asac, perhaps reassigning them to someone else if doko is overloaded would be helpful? :)
<apw> slangasek, the only bit of our installer which seems to touch debconf is the fragment below, and i am not convinced that we are therefore using it at all really
<apw> use Debconf::Client::ConfModule qw(:all);
<apw> version('2.0');
<apw> my $capb=capb("backup");
<ajmitch> ScottK: I can see why you didn't want to touch boost
<slangasek> apw: you're loading the module; this is only guaranteed to succeed if the debconf package is in installed state; either the pre-dep should be added so the package manager knows what order to configure things in, or the references should be dropped from the preinst
<apw> slangasek, yeah i am trying to ask if you concur that actually we arn't using it, and therefore ripping it out is the right thing to do to solve the error
<cjwatson> apw: a dusty memory somewhere indicates that, although debconf isn't used directly by the kernel preinst, it was needed in order to make things work when /etc/kernel/preinst.d scripts used debconf
<cjwatson> this may be nonsense
<cjwatson> but you might want to look through the history for that
<cjwatson> and perhaps grep the archive for /etc/kernel/preinst.d scripts and see what they do
<slangasek> cjwatson, apw: there was some issue surrounding dkms, yeah, but I honestly don't remember if this preinst usage was related to that
<lex79> someone can look at this: https://launchpad.net/ubuntu/+source/libvdpau/0.4-5/+build/1790677
<lex79> libvdpau needs ia32-libs to build which is in universe
<lex79> and ffmpeg needs libvdpau to build...so it ftbs only on amd64
<lex79> https://launchpad.net/ubuntu/+source/ffmpeg/4:0.6-1ubuntu1/+build/1796084
<lamont> Building database of manual pages ... <-- I want that to go faster, dangit
<geser> I disabled that for my pbuilder :)
<geser> lex79: I've strong doubts that ia32-libs comes even near main
<soren> geser: It used to be in main. Back in the old days. :)
 * micahg though ia32-libs would be going away with multiarch
<micahg> *thoguht
<micahg> ugh :-/
<cjwatson> lamont: feel free to suggest ways it could be further optimised ...
<arand> cjwatson: For btrfs in installer, which is the relevant package to track, d-i? Some of the partman-* packages? Or a bzr branch somewhereabouts?
<arand> (If you're just wanting to keep up with any news)
<cjwatson> partman-btrfs
<cjwatson> not that I can guarantee any given change will affect that.  the installer's modular, there isn't necessarily a single package to track
<arand> Right, I was just wondering because of the announcement, and then not finding any mention in the installer-related changelogs I could find. Thanks!
<cjwatson> arand: also, http://lists.debian.org/debian-boot/2010/06/msg00088.html and thread
#ubuntu-devel 2010-06-23
<lamont> cjwatson: well, the part of me wearing my buildd-guy hat would be tempted to just stub it out completely, but that would be, well, wrong.
<cjwatson> lamont: it's a genuine request, I've spent a fair bit of time making that go faster (principally by optimising the hell out of process execution and trying to do as much in-process as possible) but perhaps other eyes could see something I missed
<lamont> cjwatson: yeah - I'll add it to my list of things to do
<cjwatson> I note idly that man-db can do full-text search of all manual pages on my laptop over seven times faster than Fedora's man package can
<cjwatson> (and that's without either of them having a proper FTS engine in there, which would probably be a good idea)
<cjwatson> (http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009-07-14-man-db-K.html)
<ScottK> ajmitch: :-)
<ScottK> I only got involved with it because no one else was sorting it and one of the major users in Main is KDE.
<ajmitch> ScottK: I've dropped the majority of changes that we had, but there's some black magic going on with dependencies from what I've seen
<ajmitch> I only touched it because of boost-python being broken & it being a dependency of other packages
<ScottK> ajmitch: If you want a package that uses the MPI stuff, elmerfem needs merging.
<ajmitch> I may take a look
<Joit> hi. where can i make suggestions for the install cd
<dholbach> good morning
<chilicuil> hhh
<pitti> Good morning
<geser> could an archive admin please kill http://people.canonical.com/~ubuntu-archive/NBS/rdoc1.8. ruby1.8 provides/conflicts/replaces rdoc1.8 and there are only unversioned dependencies left (and one versioned but ruby1.8 is the preferred alternative to rdoc1.8)
<geser> and the same for http://people.canonical.com/~ubuntu-archive/NBS/rdoc1.9.1. ruby1.9.1 provides/conflicts/replaces rdoc1.9.1 and only unversioned dependencies left.
<sabgenton> ubuntu servers usb install instructions http://www.ubuntu.com/server/get-ubuntu/download show how to install desktop
<sabgenton> this is disconcerting as with say   the old  karmic this never worked for server editon
<sabgenton> does this information even work?
<sabgenton> (for server)
<sabgenton> considering there was never in the  past support  for server on usb   http://www.ubuntu.com/server/get-ubuntu/download should be made a lot clearer if there really is support now.
<bigon> robert_ancell: are you around?
<robert_ancell> bigon, hi
<robert_ancell> bigon, ?
<bigon> robert_ancell: hi, about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550478 is this really needed? josselin was not happy with putting things for testing purpose only in the "production" package
<ubottu> Debian bug 550478 in gobject-introspection "gobject-introspection: Please include the Everything-1.0 typelib" [Minor,Open]
<pitti> is it just me, or has edge.lp been ridiculously slow since yesterday?
<robert_ancell> bigon, it's proposed to be in the -dev package.  It is used by python-gi in their make check.  If we don't package it somewhere then that will always fail.
<robert_ancell> bigon, since it is built and installed with make install, I'm guessing the gobject-introspection guys consider it useful in other projects.
<bigon> robert_ancell: it's require the adding of an extra shared lib too
<robert_ancell> bigon, does that matter?
<cjwatson> sabgenton: please file a bug on https://bugs.launchpad.net/ubuntu-website about that
<sabgenton> doing right now :)
<cjwatson> sabgenton: (the webmaster isn't likely to be awake at this time and isn't in this channel anyway)
<sabgenton> what chanel ?
<sabgenton> cjwatson: where does he live on irc?
<cjwatson> sabgenton: please use the bug tracking system, it's more efficient
<sabgenton> k doing
<ogra> pitti, hey, looking at udisks i see we dont have any ubuntu patches in it, i need to add one thats really specific to the image builds, so very ubuntuish, do you think upstream would accept that or should i just go ahead and add a quilt patch ?
<pitti> ogra: depends on the patch
<ogra> pitti, its adding another partition label to the hidden partitions in the udev rule
<pitti> ogra: if it's sensible for Debian, I can commit it there; if it's sensible for upstream, I'd rather commit it there and then cherrypick to Debian and sync
<ogra> its not sensible for either i think, since it fully depends on the way we build images
<pitti> ogra: and we can't use one of the standard partition types for rescue partitions?
<pitti>   ENV{UDISKS_PARTITION_TYPE}=="0x00|0x11|0x12|0x14|0x16|0x17|0x1b|0x1c|0x1e|0x27|0x3d|0x84|0x8d|0x90|0x91|0x92|0x93|0x97|0x98|0x9a|0x9b|0xbb|0xc2|0xc3|0xdd|0xef", \
<ogra> omap images will have a vfat partition that fakes a NAND and is the first partition, i want to hide that on desktops
<pitti> there's plenty to choose from, after all?
<ogra> no, i cant change the type
<ogra> it has to be a label
<ogra> else the bootloader wont work
<pitti> does the type/label come predefined by some vendor?
<ogra> no, i can define the label, the type needs to be vfat bootable etc etc
<ogra> (wioth a certain CHS layout even)
<pitti> ogra: so, what's the new label?
<pitti> ogra: we can't just use "Recovery Partition" or "RECOVERY"?
<ogra> well, i'D call it OMAPBOOT or some such
<pitti> ah
<ogra> currently i use one of the SYSTEM* labels
<ogra> works fine but its an abuse
<ogra> if you think that abuse is fine i can also keep it but calling it OMAPBOOT or some such would be cleaner
<pitti> ogra: I don't mind the "abuse" :)
<ogra> ok, i'll keep the current name then
<pitti> ogra: OTOH, any package can ship a rule to ignore it
<pitti> ogra: i. e. if your boot loader package ships an udev rule to ignore OMAPBOOT, that's just fine
<ogra> right, but that would mean a new package just for that
<ogra> we dont install the bootloader packages :)
<pitti> ok
<ogra> flash-kernel could probably do it though ... hmm
 * ogra will think about that, thanks pitti 
<pitti> ogra: so, I don't mind which label it has; I'd just like to avoid a delta to Debian just for this
<ogra> yeah, understood
<pitti> so if it's necessary, I'd rather commit it to the Debian tree
<pitti> (need to ask mbiebl for that, since it's debatable)
<ogra> well, its very ubuntu specific
<ogra> so i dont think debian wants it
<pitti> other distros don't use that boot loader?
<pitti> (meego, etc.)
<ogra> its bound to the way we build the new images which i assume debian will never adopt )preinstalled images)
<pitti> ogra: in general such things should be maintained in one place; i. e. if your image build system defines $LABEL, it could also stick in an udev rule file which ignores that very $LABEL :)
<ogra> the new images are two partition images where we resize the second partition on the fly to the full size of the disk while the first partition has to follow a ceratin scheme
<pitti> echo ... > /etc/udev/rules.d
<ogra> right, butu the tool i use gets removed with oem-config
<geser> cjwatson: could you please kill rdoc1.8 and rdoc1.9.1 from the NBS list? or should I file a bug for it?
<ogra> and i dont really want a file on the FS thats not handled by a package
<pitti> ogra: /etc/udev/rules.d/ already has a few
<ogra> but rolling a package only for the rules file seems overkill
<pitti> persistent network, etc.
<ogra> hmm
<cjwatson> geser: one moment
<pitti> ogra: no, if nothign else, the image build process should do that along with creating the partitions -> define stuff in one place
<ogra> pitti, well, then i can also do it from jasper-initramfs during fiorst boot
<BlackZ> pitti: did you read my e-mail regarding cdbs?
<cjwatson> geser: done
<geser> thanks
<pitti> BlackZ: not yet, bit busy right now; I'll get to it
<jmux> Hi. I'm on 8.04 LTS using upstart. I have a dhclient-exit hook, which fails, because udev starts ifplugd, which starts dhclient, which calls the hook before I have a writable local fs. How can I wait for the upstart writable fs event inside my dhclient exit hook?
<BlackZ> pitti: thanks
<pitti> BlackZ: I'm not in the ubuntu distro team this cycle, so I'm lagging on distro stuff, sorry
<apw> cjwatson, was it you i was talking to about ti-omap in maverick, that we were now building those from the main package ?
<cjwatson> apw: yeah, I hadn't got round to doing anything about the result of that conversation yet ...
<apw> cjwatson, ahh ok then that makes sense... a quick Q on how to migrate the meta package, i _think_ i don't need anything speciial (replaces et al) to produce a replacement binary package at a higher version number from a different source package ... is that correct ?
<sabgenton> is there any reason I should have my bug  ticked private?
<apw> sabgenton, if apport ticked it private then it would likely mean that it thinks it added some backtrace information which may contain private information and it cannot tell
<cjwatson> apw: correct
<apw> cjwatson, thanks
<sabgenton> apport?
<sabgenton> sorry new to launchpad
<apw> apport is the automatic bug filer, like from application crashes
<apw> if its just your own bugs, then normally not
<sabgenton> so if i want my bug to get traction I should make it unprivate?
<sabgenton> I just typed the bug up my self on the website
<apw> if you made it private, then likely  only you can see it, so noone else is even aware of it
<cjwatson> private bugs are for (a) security bugs that need to not be disclosed to the public as yet (but in that case tick the security box so that the security team get to see it) (b) bugs with private information like crash dumps from your mail reader (but apport deals with subscribing some people so that they aren't entirely lost) (c) commercially-sensitive bugs, such as bugs from a hardware manufacturer on unreleased hardware
<cjwatson> a private bug with no explicit subscribers other than yourself is invisible
<cjwatson> (well, to everyone other than Launchpad admins, but they'll probably never look at it)
<achaemenes> hi guys, im running 2.6.24-28-server on 8.04 - i want to get the kernel source, as-is currently running, disable CONFIG_DEBUG_RODATA, and build a package
<achaemenes> i dont want the latest from git, i want the exact version, and all i want to do is rebuild it with that single change
<apw> achaemenes, there are two ways to do that, but i would normally get the git source, the version you have is tagged in that
<sabgenton> thanks for  the info
<apw> achaemenes, we tag every released version
<achaemenes> oh, i just installed linux-source-2.6.24
<sabgenton> acording to what I understand now I'll unprivate it
<apw> achaemenes, that is a raw source and not that useful for building
<achaemenes> right, ok ill do a git clone then
<apw> achaemenes, if you have trouble you can find us over on #ubuntu-kernel
<achaemenes> excellent - thankyou apw
<sabgenton> grr it won't  unprivate
<sabgenton> ajax symbol spins but just  says error
<sabgenton> probly my slow conection I guess
<Joit> hi. where i can make suggestions for the install cd?
<cjwatson> the bug tracking system, usually
<Joit> ok thanks
<Joit> and bye :)
<cjwatson> there's #ubuntu-installer if you want to discuss things first, but IRC is in general not so good for anything you want to be remembered
<Joit> ok i will try this channel too
<Joit> well its actually only a option what is to add
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, what does the reporter of bug 597248 has to enter to get Apport making a symbolic backtrace of his segfault.
<ubottu> Launchpad bug 597248 in cups (Ubuntu) "cupsd[1064]: segfault at 2d726574 ip 00135538 sp bf844ac0 error 4 in libcups.so.2[114000+42000]" [Undecided,New] https://launchpad.net/bugs/597248
<pitti> tkamppeter: easiest would be to enable apport for the current session and replicate the crash, and have apport pick it up; https://wiki.ubuntu.com/Apport#How%20to%20enable%20apport
<pitti> tkamppeter: if he doesn't want that, the fallback is to install debug packages etc. locally and run under gdb, see https://wiki.ubuntu.com/DebuggingProgramCrash
<tkamppeter> pitti, thank you.
<Riddell> ev, cjwatson: as you may or may not have gathered we'd like to merge the kubuntu desktop and netbook images and load the correct desktop based on screen size, where is the best place to detect screensize and edit the config file on starting the live CD and installing the system?
<cjwatson> somewhere in casper I suppose
<thangam_arun> Hello all
<thangam_arun> i am trying to trebuild kernel on ubuntu 8.10
<thangam_arun> but i am getting only 2 .deb files, image and header
<thangam_arun> is there any body can direct me to the right path ??
 * ogra directs thangam_arun to #ubuntu-kernel :)
<thangam_arun> Thanks
<ccheney> doko, hello?
<doko> ccheney: ?
<ccheney> doko, did you happen to see my comments about the OOo MIRs that need processing?
<ccheney> doko, they were assigned to you on jun 7
<ccheney> pitti, hi
<ccheney> pitti, iirc you are the person who assigns MIR bugs to people to process, is that correct? there is a server MIR I need to have processed for a2, bug 594372
<ubottu> Launchpad bug 594372 in tgt (Ubuntu Maverick) "MIR: tgt" [Medium,Confirmed] https://launchpad.net/bugs/594372
<pitti> ccheney: hello
<pitti> ccheney: that's asac now (since I'm OEM this cycle)
<ccheney> pitti, ah ok
<ccheney> asac, ping, see above :)
<pitti> :)
<ccheney> pitti, have a great day :)
<pitti> ccheney: thanks, you too!
<pitti> in fact, was a pretty good "boot faster" day so far
<asac> pitti: hey
<pitti> hello asac, how are you?
<asac> pitti: quite well ;)... hope you too! did you discuss with other linaro folks on how we can use your "reduce disk footprint"
<pitti> oh, was I supposed to?
<pitti> asac: I moved the stuff to the public wiki now, so it should be easy to grab
<asac> pitti: no ;) ... just wanted to check so i dont ask questions already discussed
<pitti> https://wiki.ubuntu.com/ReducingDiskFootprint
<asac> pitti: cool. did the dpkg changes land in maverick?
<pitti> it links to all the bzr changes, patches, etc
<pitti> asac: not yet, just in debian's trunk so far
<pitti> and I have a backport for lucid
<asac> pitti: is it risky to make that available in maverick?
<pitti> no, it's fairly well tested by now
<pitti> we have run that in an OEM project for two weeks
<asac> pitti: ok we have a https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-disk-footprint spec
<asac> pitti: i would like to give you an item to make the dpkg  available in the archive ... if you dont mind ;)
<pitti> asac: the apt changes are interesting as well, but I'd like mvo to review the branch first
<pitti> that didn't land upstream yet
<pitti> asac: sounds fine
<pitti> please do
<asac> pitti: ok. i will read through your wiki and reuse most of that for the footprint spec which needs some love
<asac> pitti: thanks!!
<asac> stay tuned
<pitti> gern geschehen
<asac> ccheney: pushed that MIR to mterry
<ccheney> asac, thanks!
<mterry> asac, I have been remiss with MIRs, sorry
<asac> mterry: heh. well, we all failed ;)
<asac> mterry: do you have capacities at all atm?
<mterry> asac, not really.  maybe this weekend
<tseliot> pitti: do you think it would make sense if I made the -dev packages of the different nvidia packages conflict with each others? This would allow me to install the headers in (/usr/include) e.g. /usr/include/GL instead of what I'm currently doing /usr/include/nvidia-current/GL (so that all of them can be installed at the same time)
<tseliot> slangasek: ^
<pitti> asac: who is handling the firefox translation bits in langpack-o-matic these days?
<asac> pitti: we said chrisccoulson_ would take that over through learning by doing
<asac> e.g. whenever there is a need we would discuss and see how things go
<pitti> asac: thanks
<pitti> asac: I got a bug about adding a new language; I'll assign to Chris and sub you, does that sound ok?
<asac> pitti: the po2xpi processor was improved by ArneGoetje in the past ... so if the problem is there he might be a good candidate
<asac> pitti: yeah. tahts good
<pitti> shoudl be easy, like adding a new file somewhere
<asac> pitti: though ArneGoetje should be able to handle that too iirc
<asac> but chrisccoulson_ should definitly be invovled so he get that knowledge too
<pitti> *nod*
<slangasek> tseliot: I think that makes sense, yes
<tseliot> slangasek: ok, thanks
<vish> pitti: hi, the sd/mmc card is also verified bug , previously we had a bigger numbering there , it is not visible now at normal view. which fixes the bug for most users. we will however be adding more icons in larger sizes for maverick which will solve the problem for users trying to zoom to 400% :)
<vish> the humanity update ^
<pitti> vish: ah, I see; please tag it as verification-done then (sorry, busy right now0
<vish> pitti: cool , i didnt know i could do that. wanted to check with you first. Thanks
 * vish doing it now
<JFo> bryce_, bug 573601 looks like it is solved by some configuration in an X config. does this need to go back to an X package?
<ubottu> Launchpad bug 573601 in linux (Ubuntu) "Lucid: GLX not working on Nvidia driver" [Undecided,Confirmed] https://launchpad.net/bugs/573601
<bryce_> *looking*
<bryce_> JFo, yeah refile to nvidia-graphics-drivers if it looks like something a dev should look at
<bryce_> JFo, if it's purely a configuration goof by the user, forward to answers or close as not a bug
<JFo> hmm, not sure
<JFo> he added some stuff and it fixed him
<JFo> dunno where the goof was
<JFo> I'll send it up to the dev
<dupondje> pitti: you here ?
<JontheEchidna> So, looks like libept broke API something awful yesterday. The textsearch class used for xapian is totally obliterated and left as two nearly-useless functions for getting the database path and the database timestamp
<JontheEchidna> Since synaptic uses that class, somebody's gonna have to take care of it sooner or later. This is what I did for libqapt: http://pastebin.com/5rw3XwBV
<JontheEchidna> It's not worth it to link to libept anymore to get a string and a time_t, imo
<JontheEchidna> oops, wrong diff. http://pastebin.com/n5xKSqAg
<JontheEchidna> Basically all one has to do is make member variables for the timestamp and the Xapian::Database, initialize them, then rip the expand() function out of ept::textsearch and slap it in the code somewheres
<JontheEchidna> I'd contribute a patch, but I'm not in-tune with the build-systems of the G* world, given my K background. ;)
<hdon> hello hard working ubuntu devs :) i submitted a bug report affecting "ALT+TAB" window switching -- a critical feature for developers and power users -- a long time ago but nobody seemed to notice it because, i believe, they were skeptical it could be reproduced. the bug still exists in Karmic Koala, and i have now updated the bug with a video demonstrating the problem: https://bugs.launchpad.net/ubuntu/+bug/405252
<ubottu> Launchpad bug 405252 in Ubuntu "focus-follows-mouse option fights alt-tab function" [Undecided,New]
<micahg> hdon: #ubuntu-bugs is more appropriate to have bugs triaged in
<hdon> micahg, thanks for the advice
<jono> is GIMP continually crashing for you all?
<ddecator> the stable version was working for me earlier (on lucid)
<arand> jono: 10.10? Randomly or on start?
#ubuntu-devel 2010-06-24
<jono> arand, it happens when I click a toolbox item
<jono> it starts fine
<jono> in maverick
<arand> jono: I was clicking about, painting, selecting, etc. With no problem. I may not be on the latest version if there was updates in the last day though..
<jono> arand, odd
<arand> jono: Thos was a i386 kvm machine.. Which seems to have bigger problems that that all of a sudden (kernel panics), so an updated test might take a while from my side.. :/
<jono> arand, sorry to hear that
<arand> Well, just have to step back a while in snapshots.. got some update-downloading to do now..
<arand> jono: Seems to be no gimp updates at that though, so if anything did break it recently it wasn't a gimp-package fault, not directly at least I guess..
<jono> hmmm
<arand> jono: amd64 on your side? Apport manages to catch it?
<jono> arand, apport doesnt catch it
<jono> I am going to do some more testing in a bit
<jono> thanks!
<arand> jono: Nope, all upgraded and gimp seems as stable as ever, at least on this here instance.
<pranay_09> hi, while downloading any package via synaptic manager in ubuntu if i go for system shutdown, then the system does not inform me that some downloading is going on . so how can i incorporate this feature ?
<micahg> pranay_09: file a bug?
<pranay_09> micahg: where?
<micahg> good question :)
<micahg> pranay_09: you can always file just against ubuntu and add the needs-reassignment tag if you'
<micahg> re not sure
<pranay_09> micahg: ok
<pranay_09> micahg: acutally i wanted to know that how can i work upon it?
<micahg> pranay_09: ah, ok
<micahg> pranay_09: well, all the sources are available either as source packages or in bzr, I just don't know which package this would be
<micahg> pranay_09: maybe someone else will know
<pranay_09> micahg: ok, so where should i search for such package , any idea?
<micahg> pranay_09: looks like gnome-session might be it
<micahg> pranay_09: also, you might want to check bugzilla.gnome.org to see if anyone's filed such a request or if there's a partial patch
<pranay_09> micahg: k, thanks :)
<micahg> pranay_09: np
<Chipzz> micahg: are you seriously proposing patching gnome-session for that?
<Chipzz> ^^
<micahg> Chipzz: nope
<micahg> Chipzz: but if someone wants to make a patch, should I stand in their way?
<Chipzz> then why is it a bug against gnome-session?
<micahg> Chipzz: I don't think he's going to file a bug, I misunderstood, he wanted to work on it
<Chipzz> if you're wasting their time because that patch has 0 chance of being accepted, yes
<RAOF> There's an existing mechanism for making this work, by the way.
<micahg> where was everyone an hour ago?  I was just trying to help :-/
<Chipzz> playing WoW :P
<micahg> user's still here, anyone want to talk to pranay_09 about it?
<RAOF> pranay_09: You could make that work with an app that registers with the session-management protocol - one of the things that protocol does is send a âI'd like to shutdown nowâ message to all clients, which can block the shutdown.
<micahg> RAOF: thank you :)
<pranay_09> RAOF: thanks for that
<LucidFox> Chipzz> WoW \o/
<dholbach> good morning
<ion> That.
<j1mc> dholbach: i'm not sure if you've had a chance to look at the packaging guide emails yet, but let me know if you have any questions.
<dholbach> j1mc: not yet, I'm sorry - I've been drowning in emails and work, but I'll do my best to get to it today and I'll reply to them
<dholbach> j1mc: thanks a bunch for helping me out!
<j1mc> dholbach: no worries.  i'm looking forward to the project.  i think having good packaging docs will go a long way in helping ubuntu.
<dholbach> definitely - I look forward to having a good discussion about it, that's why I wanted your and the doc team's advise
<dholbach> advice
<j1mc> :)
<j1mc> i'm sure we'll be seeking out your input quite a bit as things get started.
<j1mc> i'm off to catch a few Zzzz's
<j1mc> later!
<dholbach> sleep tight
<dholbach> ArneGoetje: HAPPY BIRTHDAY! :)
<ArneGoetje> dholbach: THANK YOU! :)
<dholbach> :)
<pitti> Good morning
<NCommander> stgraber: ping, do you care about Ithanium1 support in Ubuntu?
<StevenK> NCommander: s/h//
<NCommander> StevenK: it burns less when I spell it wrong.
<StevenK> Yes, but the pain will never fade.
<ara> soren, hello :)
<ara> soren, is there a way to use vmbuilder without debootstrap (i.e. copying from a base image)
<dholbach> soren: you could give a session at UDW about vmbuilder and stuff! https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule :-D
<dholbach> soren: â¦ and how VMs are good for you
<soren> ara: Yes.
<soren> ara: It has a --existing-chroot option or something like that.
<soren> dholbach: I'm afraid I'm in meeting all that time.
<dholbach> soren: it was worth a try :)
<soren> dholbach: It was, yes :)
<soren> ara: ...so if you first run VMBuilder with "--only-chroot" it gives you the path to the chroot it built. Subsequently, you can add a "--existing-chroot=<the path you got from --only-chroot>" and that should save you a bunch of time.
<ara> soren, thanks!
<seb128> jdong, hi
<seb128> jdong, is there any chance you could do some sru reviews this week?
<seb128> slangasek, ^ or you?
<seb128> other sru teams member are busy with other things atm and the queue is a bit stalling
<zyga> dholbach, where does ubuntu developer week take place? #ubuntu-meeting?
<dholbach> zyga: #ubuntu-classroom
<zyga> thanks :)
<dholbach> zyga: I'll send a mail to all speakers explaining it a few days inadvance :)
<zyga> dholbach, I added this to my calendar so that I can keep track
<dholbach> awesome
<dholbach> thanks again zyga!
<hoare> guys, any wubi developers here?
<LucidFox> Is it possible to make gcc or clang to reject C++ incompatible C features?
<zyga> LucidFox, gcc has some switches that spit warnings for C-okay C++-notokay code but I'm not sure if it really covers all cases
<ebroder> What causes the loopback interface to get started on an upstart system? Does it happen through the normal net-device-added -> network-interface -> ifup chain?
<LucidFox> I wonder
<LucidFox> Is there a standard way for doing automatic PPA daily builds from a VCS?
<hoare> guys, any wubi developers here?
<nigelb> LucidFox: like daily builts?
<nigelb> *builds
<arand> LucidFox: https://wiki.ubuntu.com/DailyBuilds might have some info there in the links..
<dupondje> pitti: you there ?
<pitti> dupondje: hello
<dupondje> pitti:  :) could you check https://bugs.launchpad.net/ubuntu/+source/pybootchartgui/+bug/596475 ?
<ubottu> Launchpad bug 596475 in pybootchartgui (Ubuntu) "Upgrade to upstream version r141" [Wishlist,New]
<seb128> dupondje, the debdiff is weird, the changelog mentions new options but there is no code for those?
<pitti> dupondje: right, what seb128 just said, was going to ask the same
<pitti> dupondje: and we already fixed the find bug yestrday
<pitti> mousewheel?
<pitti> oh, pybootchartgui has an interactive mode as well?
 * pitti was only ever looking at the produced .pngs
<dupondje> pitti: yes :) if you scroll now, it zooms directly
<dupondje> patch fixes that it zooms only when CTRL is entered :)
<pitti> ah, that directly reads the .tgz
<dupondje> seb128: those 'new options' are also in the current versions ... Didn't know if I needed to add the info in latest changelog
<dupondje> as its a new upstream version, with the ubuntu changes included ...
<seb128> dupondje, well changelog describes what changed
<seb128> dupondje, it's weird to describe things which didn't change in the new entry ;-)
<pitti> dupondje: ah, then you should perhaps indent it properly
<pitti> dupondje: so the --crop-after bits were previously cherrypicked as patches?
<pitti> but right, if we already got them, no need to repeat, it's only confusing
<dupondje> It was just to make clear we kept the upstream delta in the new version :)
<LucidFox> arand> So basically, I'd need my own build server... okay
<arand> LucidFox: TO be honest I have no idea, I just found the wiki page and it looked relevant ;)
<pitti> dupondje: oh, that is a delta of our's? then it shouldn't be in the changelog at all IMHO
<dupondje> those are changes that are made in the ubuntu package only indeed, not in upstream
<seb128> dupondje, changelog is to indicate changes, if those are in the previous version we will indicate if we drop them, otherwise we assume that we keep what was done before
<seb128> dupondje, you would have to do a summary of all the changes at every upload otherwise ;-)
<pitti> ah, so it's not really that magic; just seems to be a terribly slow eog :)
<dupondje> seb128: Want sure :) ah well, just remove the lines then ^^:)
<doko> barry, ScottK: just disable the profiled build on the archs where it does fail
<ScottK> doko: OK.  Will do.
<barry> doko: thanks
<apachelogger> doko: do you happen to know why binutils(-gold) does not use update-alternatives for ld diversion?
<doko> apachelogger: because alternatives are evil for anything other than editor or www-browser
<apachelogger> hm, ok :)
<doko> you can't see from logs what was really used, makes understanding bug reports harder, etc
<superm1> slangasek, so today's 06-24 build is doing that same thing with the hash sum mismatch again.  could you perhaps temporarily reschedule it at a different time so as to avoid this conflict until that proper locking can be put in place?
<ScottK> pitti: Would you please rescore python2.6.  I need to find at all the archs it's going to fail on before I upload it again.
<apachelogger> doko: well, you do not see this with the current approach either, do you?
<doko> apachelogger: why not?
<apachelogger> I mean, binutils-gold will dpkg-divert ld and then the builder will just use ld as usual
<doko> apachelogger: no, you know it's gold, if binutils-gold is installed
<apachelogger> doko: not if the user manually messed with the link that is, which is likely considering dpkg-divert is from a user perspective not exactly usable
<apachelogger> especially considering that one might not want to use gold for everything
<doko> apachelogger: a user always looses when manipulating things directly
 * sebner waves at pinky apachelogger 
<apachelogger> Just to give this context. The kdepim team is thinking about using gold for in-development builds for various reasons and the concern was raised that one should probably be able to switch easily.
<apachelogger> sebner: o/ lo
<doko> apachelogger: then you should use -B<directory with ld>
<apachelogger> *nod*
<apachelogger> doko: thanks for the chat :)
<flupke> ScottK, hi, I posted a bug about qtmultimedia missing in python-qt4, you asked me to see what they think of it on debian... There has been no activity on it since june 7, and people on #debian said me to stop spamming about it, so I think qtmultimedia will be deprecated before being integrated on debian :)
<ScottK> flupke: The bug just discussed on #debian-python (on OFTC) just a little bit ago.  I'd suggest joining.
<flupke> ScottK, ok, done
<ximion> siretart: ping
<siretart> ximion: what's up?
<ximion> first of all: hi! (glad that I finally found you) I packaged the music visualisation library projectM for Debian to replace the old, orphaned packages in sid. The packaging was accepted as pkg-multimedia-maintainers project...
<siretart> ximion: ah, yes, I've seen your query yesterday, and reviewing your projectm package is indeed still on my todo list
<ximion> ...but I still need someone to review the packageing. On the multimedia-maintainers mailinglist I was told to try to contact you ^^
<siretart> we use the channel #debian-multimedia on irc.debian.org for the team pkg-multimedia
<ximion> oh, I wasn't sure if you got my message - Konversation did some really weird stuff that day.
<siretart> oh, I see. no problem
<siretart> I think I'll find time to review/sponsor it tomorrow
<ximion> the debian-multimedia channel throws me out: invitations only.
<siretart> are you sure that you're on the right irc network?
<ximion> Freenode?
<siretart> not freenode, oftc
<siretart> as said, irc.debian.org
<ximion> should read the wiki page more carefully...
<ebroder> mvo: Whenever you're around, if there's anything I can do to move bug #594206 forward, let me know - I'm happy to help
<ubottu> Launchpad bug 594206 in update-manager (Ubuntu) "update-manager disables third-party repositories with suite suffixes" [Undecided,New] https://launchpad.net/bugs/594206
<ScottK> doko: I'm a bit worried what to do about python-defaults and the ICE on ia64.  If I merge python-defaults from Unstable, then that will make python-minimal uninstallable on ia64 won't it?
<ebroder> Is there a reason that intrepid is still in archive.ubuntu.com? Are unsupported releases not getting moved to old-releases.u.c anymore?
<doko> ScottK: well, then delay the merge until this is fixed
<Pici> ebroder: I know that intrepid's packages were *just* moved to old-releases, so there may be some time for them to be removed from archive.u.c
<ScottK> doko: OK.  Maybe I should talk to the Ubuntu gcc maintainer about fixing it then ... :-)
<ebroder> Pici: Oh! So they are. I hadn't noticed that yet. Awesome
<Pici> ebroder: ports was there before, but i386 just got there today.
<ScottK> doko: Bug filed.
<doko> ScottK: please make sure to include the .gcda file together with the preprocessed source
<ScottK> doko: I don't have hardware, so no way I can do that.
<doko> another reason to drop ia64
<ScottK> Next cycle you probably get that wish.
<_melvin__> cyphermox, Hi. is it possible to make two ore mor openvpn Connections with NetworkManager at the same time?
<_melvin__> mn
<cyphermox> _melvin__: hi! sadly, no. only one vpn connection at a time. I think that has been discussed on the NM mailing list however and there may be work towards that... thanks for reminding me I wanted to make a call for testing for the new NM version
<_melvin__> cyphermox, can i make a feature request somewhere?
<cyphermox> _melvin__: yes. please bring it up on the gnome bugzilla project for NetworkManager or on the mailing list, see http://live.gnome.org/NetworkManager
<fale> hi
<_melvin__> cyphermox, ok. Thank you
<fale> I think here (http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/files) there is the script that canonical suses to create iso images... but I dunno the name :(
<DktrKranz> mvo: have you had occasion to look ad python-apt merge for gdebi?
<mvo> DktrKranz: yes, the maverick version should already be fine
<mvo> DktrKranz: the diff between maverick and debian-sid is tiny
<DktrKranz> mvo: so, it should be fine to merge and upload for you? I can have a look
<mvo> DktrKranz: not sure I understand correctly. what I try to say is that the maverick python-apt version should be fine for gdebi. the remaining delta for python-apt is so small that its not worth a upload at this point IMO
<DktrKranz> mvo: I mean if it's ok to merge gdebi's python-apt branch into trunk
<mvo> DktrKranz: ohh, I misunderstood. sorry. let me look at this branch
<mvo> DktrKranz: I assume you mean  lp:~mvo/gdebi/python-apt0.8-port   ?
<DktrKranz> mvo: exactly
<mvo> DktrKranz: yeah, that should be fine :) if you could also give it a bit of testing, that would be much appreciated
<mvo> DktrKranz: I thought you meant the "python-apt" package merge between debian and ubuntu :)
<mvo> thats why I was confused
<DktrKranz> I should have expressed better, sorry
<DktrKranz> I'll give it a try
<DktrKranz> if my tests are fine, is it ok for you to merge and upload in Debian, then sync in maverick?
<DktrKranz> (I'll take care of the process)
<mvo> yes
<mvo> and thanks a lot for this :)
<DktrKranz> cool, thanks :)
<ebroder> mvo: Did you see my message earlier about bug #594206?
<ubottu> Launchpad bug 594206 in update-manager (Ubuntu) "update-manager disables third-party repositories with suite suffixes" [Undecided,New] https://launchpad.net/bugs/594206
<mvo> ebroder: I have not seen this one, let me have a look
<ebroder> mvo: It's a followup to the Sources.AllowThirdParty option. I just wanted to offer to help with implementation if there was any way I could
<mvo> ebroder: thanks, could you please put a example sources.list in there? just so that there is something to test against?
<ebroder> mvo: Will do
<mvo> ebroder: odd, from the code it looks like it should work
<mvo> ebroder: let me create a test case for it
<soren> slangasek: Can I borrow your brain for two minutes? I want to help this guy, but my upstart-fu is not strong enough: https://bugs.launchpad.net/bugs/350936
<ubottu> Launchpad bug 350936 in libvirt (Ubuntu) "Should shut down domains on system shutdown" [Low,Triaged]
<slangasek> soren: the only problem I see there is that the last line of the job shows that there are timing issues in his script
<slangasek> why isn't 'virsh destroy' synchronous?
<soren> slangasek: Sorry, my phone rang..
<soren> slangasek: "virsh destroy" should be synchronous.
<slangasek> soren: ok, then why does he have a sleep at the end? :-)
<soren> slangasek: His problem is that apparantly libvirt gets shut down before his script gets to finish.
<slangasek> soren: anyway, 'stop on stopping foo' definitely blocks the killing of process foo
<slangasek> that doesn't prevent something outside of upstart from killing the process, but I don't know what would do that
<soren> slangasek: Ok. Hm..
<soren> slangasek: Oh, wait.
<soren> slangasek: This is "start on stopping foo".
<soren> slangasek: ..but that shouldn't matter, should it?
<slangasek> right, that too
<soren> slangasek: Well, thanks. I'll see what we can come up with :)
<fale> hi guys
<fale> some times ago, someone in this channel linked me to a script/set of scripts, that canonical uses to create the official ubuntu CDs, is there anyone that could pass me that link again, please?
<kees> anyone (slangasek, cjwatson, siretart) know if emacs22 can be synced with debian yet?  what's the state of the "emacs" metapackage, etc?
<slangasek> kees: that was discussed recently on ubuntu-devel, right? Aren't we meant to get rid of emacs22 in favor of emacs23?
<kees> slangasek: I assume
<kees> slangasek: but I wasn't sure what needed to happen there.
<slangasek> nor I
<seb128> slangasek, thanks for the sru review ;-)
<slangasek> seb128: still ongoing...
<seb128> slangasek, that's appreciate, thanks for reviewing some of the waiting uploads, after that round I should be mostly done for lucid .1 and focus on maverick so there will be less desktop changes coming ;-)
<seb128> slangasek, that's appreciate, thanks for reviewing some of the waiting uploads, after that round I should be mostly done for lucid .1 and focus on maverick so there will be less desktop changes coming ;-)
<seb128> urg, sorry
 * seb128 dislike touchpad clicky randomly when typing...
<kees> uhmm...
<kees>   570 root      16  -4 17536 1232  304 R  100  0.0  10:40.58 udevd
<encodec> hey all
<encodec> i want to understand how packages work
<encodec> by that i mean...
<encodec> who compiles them
<encodec> how are they added to package system
<cjwatson> developers upload source packages; they're compiled by automatic build servers
<encodec> how?
<cjwatson> please expand on your question
<encodec> well i guess in linux its just a ./configure make script..
<cjwatson> dpkg-buildpackage  is the official entry point
<cjwatson> unpack source package, cd into unpacked tree, run dpkg-buildpackage -b
<cjwatson> that calls debian/rules with various arguments, behind the scenes
<cjwatson> and debian/rules takes care of whatever the specifics of the package are.  not everything is ./configure && make
<encodec> ok ok
<seb128> cjwatson, hey
<encodec> what describes the dependencies, destination paths and such things?
<seb128> cjwatson, I know you are busy atm but did you get kenvandine's email about his upload rights for desktop set?
<cjwatson> encodec: debian/control describes dependencies, although many of them are worked out dynamically by dpkg-shlibdeps
<cjwatson> encodec: destination paths are done by a mix of things; it's easiest to run dpkg-buildpackage on a package and watch its output
<verb3k> is it possible to build gst-ffmpeg with an already installed version of ffmpeg (instead of the one in the source tree)?
<cjwatson> sometimes it's the upstream build scripts (Makefile or whatever), sometimes debian/*.install, sometimes manual commands written directly into debian/rules, it varies
<seb128> cjwatson, seems he's having limited access to upload dx components atm, we can deal with sponsoring but still it would be nice to get that sorted
<cjwatson> seb128: I did get it, at the moment I have it queued for right after I'm off this OEM project
<cjwatson> I know it's blocking him, sorry about that :(
<seb128> cjwatson, oh, no need to be sorry, I though I would check because he said he didn't get a reply from you yet
<seb128> cjwatson, I know you are busy, we are done for this week updates so really no hurry ;-)
<seb128> cjwatson, thanks
<cjwatson> mm, I tend to reply only when I'm done
<cjwatson> maybe I should adjust that habit
<seb128> cjwatson, I was not sure if that was a one command to run from you side but you missed the email or if you queued it for after busy time
<cjwatson> it's a few commands plus some thought
<cjwatson> I'll need to go through adjusting exception lists
<seb128> ok, thanks for the update, as said that was rather a status checking than a need to get this done now
<Sarvatt> siretart: are you around by any chance? gstreamer0.10-ffmpeg (and vlc) are built against libavutil49, and the libavutil-extra-49 package in the maverick archive is an empty package outside of docs
<encodec> cjwatson, thx for all the fish
<Sarvatt> not sure what to do since libavutil49 isn't built in ffmpeg-extra anymore, should all this stuff just be rebuilt against libavutil50? totem is pretty unusable because of it since it can't find codecs
#ubuntu-devel 2010-06-25
<psusi> so.... with the debian import freeze going into effect today is there any chance of getting lvm2 updated this cycle?
<lifeless> yes
<lifeless> just requires manual requests
<lifeless> not automatic
<RAOF> It's still open season on merges and sync requests.
<lifeless> its not the end of syncs, its the end of the firehose
<ebroder> lvm2 was never going to get automatically synced anyway, because Ubuntu modifies heavily from Debian
<psusi> ok... anyone planning on doing that anytime soon? :)
<psusi> yea, I looked at the bzr repo for it and the last merge is a nightmare
<psusi> but the new upstream has support for merging a snapshot back into the origin so you could make a snapshot, test an upgrade, then if it goes tits up, revert to the snapshot
<lifeless> psusi: that would be nice; care to do the merge ? ;)
<ebroder> psusi: The difficulty isn't really in dealing with LVM metadata restoration. The problem is that the way that Ubuntu packaged things is substantially different (because the startup processes for Debian and Ubuntu are fundamentally different)
<psusi> I tried already... none of the ubuntu specific patches have proper documentation within the quilt patch file, and when I tried to track down their history in bzr, I got stuck on the nightmare merge and could not penetrate that history
<ebroder> psusi: Exactly. That's why nobody's done the merge :)
<psusi> ebroder, how so?
<psusi> I ended up just disabling all of the ubuntu specific patches iirc... except for one or two that seemed to still apply to the new upstream without any fudging
<psusi> what are the critical points of divergence ubuntu needs to maintain?
 * psusi pets make -j 2... if it takes this long to compile the kernel with it... boy...
<siretart> Sarvatt: just rebuild it so it picks up libavutil50
<pssw0rt> maybe in this room
<pssw0rt> one day, ubuntu would be xfce4??? i don see future with gnome 3
<pssw0rt> and the use of another lang called Vala
<pssw0rt> and mono and C#
<Chipzz> pssw0rt: no, not in this room ;P
<pssw0rt> xD
<pssw0rt> developers  without opinion xD
<pssw0rt> bb
<dholbach> good morning
<dholbach> can an archive admin please take care of the sync bugs? particularly 598274?
<dholbach> pitti: do you know what GSI means on https://wiki.ubuntu.com/UbuntuPackagingChanges?
<dholbach> ccheney: is GSI still a change that should be listed on https://wiki.ubuntu.com/UbuntuPackagingChanges?
<Laney> that page seems somewhat out of date
<Laney> but I guess that's what you're cleaning up right now :P
<dholbach> Laney: no, everybody's invited to update it
<dholbach> Laney: don't rely on me - it was just a question that just came up :)
<Laney> alright
<dholbach> :)
<Laney> I'll nuke the outdated ones (breaks, dh_iconcache)
<dholbach> thanks
<pitti> Good morning
<pitti> dholbach: GSI is the name of the OO.o translation format; don't ask me what it's spelt out
<nigelb> pitti: the question rather is if its still significant
<pitti> well, it has never really been
<pitti> oo.o has had its own langpacks forever
<pitti> we have our own source package oo.o-l10n
<pitti> but that's about it, the binary structure is as in Debian
<pitti> apw: good morning
<pitti> apw: debian bug 509089 is such a gold nugget, thanks for digging this out!
<ubottu> Debian bug 509089 in dhcp3-client "dhcp lease negotiation takes longer than necessary" [Normal,Open] http://bugs.debian.org/509089
<BlackZ> pitti: hmm, I can't find that file in cdbs
<pitti> for my ethernet connection, it drops DHCP time from 2.5 s to 0.15
<BlackZ> I downloaded the currently version in maverick
<pitti> BlackZ: ah, perhaps the Kubuntu team dropped it and it was just a copy&paste error in the merge changelog
<pitti> seems so, yes
<BlackZ> pitti: so could it be dropped?
<pitti> from the merge changelog, right
<BlackZ> BTW it fails locally too, pitti
<BlackZ> I have no idea
<Riddell> BlackZ: what's this?
<BlackZ> Riddell: the dropped file? or the FTBFS?
<Riddell> whatever the bit the kubuntu team should care about is :)
<BlackZ> Riddell: - Add 1/class/kde4.mk.in: Generic KDE4 build rules. Install it in Makefile.am;
<BlackZ> I can't find it in the package
<Riddell> yes it's gone
<Riddell> use /usr/share/pkg-kde-tools/makefiles/1/cdbs/kde.mk from pkg-kde-tools
<BlackZ> OK, dropping it then
<pitti> BlackZ: as I said, run one of the tests locally and see what it's failing on
<BlackZ> pitti: .: 21: testsuite_functions: not found
<pitti> you have to cd tests
<BlackZ> I'm in it
<pitti> cd test; ./langpack-1.sh -> works fine for me
<pitti> do you actually have the testsuite_functions file?
<BlackZ> hm, yes
<BlackZ> and the package from debian works fine
<BlackZ> maybe I've broken something but I don't think so
<pitti> well, it fails all tests, so _something_ was broken
<BlackZ> pitti: http://pastebin.ubuntu.com/454884/
<pitti> BlackZ: so whatever "debhelper.mk.in:239: *** Riferimento incompleto a variabile.  Arresto.
<pitti> " means, that's likely the error
<pitti> "variable does not exist" or so?
<BlackZ> "reference to variable incomplete"
<BlackZ> OK, looking there
<ogra> pitti, ... could you set the trend line again for http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html (57 items) and http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-3.html (16 items) ?
<ogra> pitti, sorry, we got a new spec yesterday
<pitti> ogra: alpha-3 will auto-reset once alpha2 is done
<pitti> so I won't touch that
<ogra> ah. great then only the overall view
<pitti> the idea is that you plan a milestone before it begins and the chart grows up
<pitti> and you see how much stuff you have
<ogra> yeah
<pitti> and once the milestone begins, the chart begins "clean" again
<pitti> ogra: note that the entire idea is to _not_ change the trend line when you add a spec
<pitti> the point is that you see what/when the additional workload was added and thus what is to blame for dropping other work instead :)
<pitti> but I can change it if you really want
<DktrKranz> mvo: gdebi uploaded in Debian (with some little trivial changes), and sync request filed. you can mark branch as merged :)
<ogra> pitti, yes, but i was asked to since the initial value is all wrong for the total at least
<mvo> DktrKranz: sweet, thanks!
<pitti> ogra: sure, was just a suggestion; committed
<ogra> pitti, thanks, i have another issue :)
<ogra> pitti, we need jockey to show an eula for a driver, is something for that implemented or do i need to do it on a dpkg/debconf level
<pitti> ogra: it's an open wishlist thing, bug 271288
<ubottu> Launchpad bug 271288 in jockey (Ubuntu) "Require the user to confirm the license before downloading a driver if it is non-free or if it has patent issues" [Wishlist,Triaged] https://launchpad.net/bugs/271288
<ogra> ok
<pitti> ogra: jockey doesn't show debconf, sorry
<ogra> no, buut dpkg does if gtk-perl is installed, no ?
<ogra> i.e. if i put it in the package and make sure gtk-perl is there it should use the gtk frontend
<pitti> jockey doesn't use synaptic
<pitti> it uses python-apt in the dbus backend
<pitti> it doesn't have anything to display stuff to, and isn't meant to have
<ogra> hmm, and that omits debconf questions ?
<pitti> if a package requires debconf, you can't use jockey, sorry
 * ogra thought that would work parallel to jockey just using the debconf gtk frontend
<mvo> pitti: have you considered switching to aptdaemon as the backend? then you get debconf support
<pitti> mvo: it's an option indeed, but I haven't found much time to hack on jockey since aptdaemon exists
<pitti> but it's also kind of a design decision
<pitti> drivers shouldn't need debconf or anything scary to work
<ogra> sadly some driver manufacturers disagree :)
<pitti> I do acknowledge the need for displaying an EULA at some point, but that should be in jockey's UI, not debconf
<pitti> apw: I uploaded dhcp3 with those patches to maverick now
<pitti> well, slightly adapted (without conffile changes)
<cjwatson> kirkland: merged your uec-live seed; as far as I'm concerned you can hack on it directly in the main seed branch at this point
<geser> doko: would it be possible to get our python-defaults package merged/synced with Debian ones? The first packages are already in DEPWAIT on python >= 2.6.5-2~
<cjwatson> mvo: is the rest of foundations-maverick-buy-something likely to land for alpha-2?
<cjwatson> doko: arm-m-tool-chain-selection has a work item for alpha-2 on it; is that still feasible?
<cjwatson> cking: you have "Investigate situation with Intel graphics drivers on EFI" as a work item for alpha-2, which is showing up on the foundations list; have you had a chance to look into that at all?
<cking> cjwatson, not yet, been a bit swamped. Will find some cycles today to start thus
<cking> cjwatson, want to you need to know?
<cjwatson> cking: at the moment, I'm just checking in so that I have information for the release meeting
<doko> geser: ScottK is working on this, waiting for the ia64 build
<geser> ok
<doko> cjwatson: yes, I think the test rebuild is still doable, the decision probably later
<mvo> cjwatson: the buy-something work-items are not 100% reflecting reality anymore, there were some changes in the server side. I will update them today with noodles (who works on the server side of things)
<cjwatson> thanks
<hrw> someone remember where I can find uds-m presentation about udev/hal?
<hrw> keybuk's one
<cjwatson> dholbach: processing syncs now
 * dholbach hugs cjwatson
<nigelb> hrw: ubuntu miro community should have them
<hrw> nigelb: I already have video version
<hrw> bbl - called for lunch
<ogra> cjwatson, for enabling preinstalled images i'm wondering if i should either mangle bin/cron.ports_daily-live to export CDIMAGE_PREINSTALLED instead of CDIMAGE_LIVE or should i rather create a new command i.e. bin/cron.ports_daily-prenistalled and leave ron.ports_daily-live alone ?
<ogra> (without the typo indeed :P )
<dholbach> could somebody imagine giving a session at Ubuntu Developer Week about the release schedule, freezes and stuff we do? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has a few open slots
<cjwatson> ogra: I don't mind either way really; what's clearest in the code?
<ogra> cjwatson, well, i think cron.ports_daily-preinstalled would be less intrusive
<cjwatson> that's fine by me, then
<ogra> effectively its only that one variable that needs to change
<ccheney> dholbach, yea support is still there its not working correctly atm
<dholbach> ccheney: does the page need an update?
<ccheney> dholbach, i think its accurate enough about the gsi item
<dholbach> ok
<kirkland> cjwatson: ah, great, thanks
<kirkland> cjwatson: and as for building a server image directly for the hardware, I have gotten vmbuilder working for that purpose now :-)
<kirkland> cjwatson: when will it build on cdimage?  anything else I need to do on that front at this point, to get an ISO together that we can start working from?
<cjwatson> kirkland: do I have to have more things on cdimage?  it's really tight on space
<cjwatson> if it's at all possible to do it externally, that would be preferable
<kirkland> cjwatson: okay -- can you point me to some docs as to building an ISO from the seed itself now?
<cjwatson> kirkland: that said, how big does it end up being?
<kirkland> cjwatson: ~800MB roughly
<cjwatson> hm, not small then
<kirkland> cjwatson: yeah, well, i need to work on shrinking it down some
<kirkland> cjwatson: there's more stuff that can go
<cjwatson> /dev/mapper/cdimage-srv
<cjwatson>                      1693107968 1560767584 132340384  93% /srv
<cjwatson> we might be able to cope with another
<cjwatson> does it need to be i386 and amd64?
<kirkland> cjwatson: and that estimate was from my modified desktop livecd -- i've not yet built an ISO based directly on this seed
<kirkland> cjwatson: no, only amd64 IMHO
<cjwatson> ok, that helps
<kirkland> cjwatson: and 800MB is an over estimate
<cjwatson> leave me with the action to get it done, then
<cjwatson> alpha-3 work item or whatever?
<kirkland> cjwatson: sure
<cjwatson> does anyone know where the code that updates changelogs.ubuntu.com comes from?
<dholbach> cjwatson: mvo might
<cjwatson> hm, lp:extract-changelogs maybe
<mvo> cjwatson: that is a mix of code living on changelogs.ubuntu.com plus fixup code that adds symlinks where binver != srcver. is there a problem with it?
<seif_> any1 know where anmar ius
<cjwatson> mvo: when processing syncs I noticed that some packages didn't seem to have changelogs, e.g. http://changelogs.ubuntu.com/changelogs/pool/universe/m/mc/mc_4.7.0-1ubuntu2/
<cjwatson> mvo: and I was wondering if this was something to do with them being 3.0 (quilt), since all the examples I noticed were
<cjwatson> mvo: but then current man-db has a changelog and that's 3.0 (quilt), so maybe dpkg-source was just out of date?
<mvo> cjwatson: that is likely, it does use a simple dpkg-source -x iirc but we requested a backport
<cjwatson> that would make sense then, thanks
<cjwatson> just wanted to check that it wasn't a current problem
<mvo> cjwatson: it maybe that its stuff extracted between the time when v3 arrived and when we got the backport installed
<cjwatson> yeah, could well be
<LucidFox> Yay, finally, for most applications, the global menu seems to Just Work(tm)!
<LucidFox> no reordering or vanishing issues so far
<LucidFox> Okay, Qt applications are still reordered
<LucidFox> but GTK ones are fine
<jcastro> LucidFox: can you check gnome-terminal and tell me if you see a partial menu?
<LucidFox> jcastro> Okay, the Help menu is different in the global menu applet, and the Terminal menu has some different items entirely
<jcastro> yeah, that seems to have regressed, people are looking into it
<LucidFox> the Help menu has only Contents and About
<jcastro> yeah in some cases it's still showing partial menus
<jcastro> that's lp #594228
<ubottu> Launchpad bug 594228 in Application Menu Indicator "[Master] Application is showing a partial menu" [High,Confirmed] https://launchpad.net/bugs/594228
<LucidFox> But there are separators, correct order in everything apart from VLC, and it no longer loses the menu when the application is restarted
<LucidFox> It's almost usable now :)
<jcastro> LucidFox: feedback on any of those open bugs on the menu would be appreciated
<LucidFox> Out of curiosity, why did you implement this from scratch instead of using the gnome2-globalmenu code?
<jcastro> the DX guys talked to the gnome2-globalmenu guys before they started
<jcastro> i don't know the details other that they decided that ted/bratches way was the way forward
<LucidFox> ted/bratches?
<LucidFox> Oh, and the panel periodically crashes now -_-
<jcastro> ted and bratsche I mean (cody)
<jcastro> LucidFox: join us in #ayatana if you want to help us with the menu!
<MacSlow> bryce_, ping
<LucidFox> Okay, the status of xchat-gnome upstream is concerning
<LucidFox> They're apparently a hairline away from release, yet nobody's answering bug reports or mail, the IRC channel is almost empty, and my post to the mailing list has been held in moderation for days.
<dholbach> sorry for spamming, but we have one slot for UDW left: would anybody like to talk about distributed development 16th July at 17 UTC?
<unknown> where can i find out how the jockey-gtk package is built?
<ScottK> unknown: apt-get source jockey
<unknown> ScottK: what if i'm not running ubuntu? (i have a ubuntu vm, but just curious)
<ScottK> Getting the source package and looking is still the best way.  Do that in the vm is the easiest.
<ScottK> It's also available at https://launchpad.net/ubuntu/+source/jockey
<unknown> ahh, all i found was this: http://packages.ubuntu.com/source/lucid/jockey
<ebroder> unknown: Yeah, Launchpad is a little less discoverable than packages.u.c, but it has about a gajillion times as much information
<cking> cjwatson, "Investigate situation with Intel graphics drivers on EFI" - I'm on the ball, waiting for some more input from Intel on this
<cjwatson> cool, ta
<cking> apologies for the delay, hope to get some info back next week
<arand> How are the dailies of the alternate CD faring atm, there seems to have been none the last three days, and we're a bunch that's quite eager to try out btrfs...
<cjwatson> arand: I fixed a problem earlier today that affected them
<arand> cjwatson: Cool, so hopefully one for tomorrow then?
<cjwatson> maybe, I wouldn't like to promise
 * cjwatson scores up d-i
<cjwatson> gah, one hour to start even at 20000
<cjwatson> toolchain ate our builders
<ScottK> cjwatson: Looking at the other packages, I think it's safe to say doko ate our builders.
<cjwatson> openjdk is sort of toolchain :)
<ScottK> python2.6 has been at 999999 for 7 hours on ia64 and didn't get a chance yet ...
<[reed]> any Makefile experts around, Firefox could use your assistance -- http://christian.legnitto.com/blog/2010/06/25/are-you-a-makefile-guru-would-you-like-to-make-firefox-more-secure/
<hunger> In maverick I get "root filesystem check failed" on the console... mounting fails, btrfsck says all is well, the lucid kernel boots fine. Any ideas what I can try to debug this?
<rohan> wasn't ubuntu 8.04 onwards supposed to receive latest versions of firefox from upstream (3.6.4) last week?
<rohan> was the plan dropped?
<rohan_> wasn't ubuntu 8.04 onwards supposed to receive latest versions of firefox from upstream (3.6.4) last week?
<rohan_> was the plan dropped?
<rohan_> i'm talking about https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model
<arand> rohan: They were testing it in the security PPA, not sure if they rolled it out yet..
<rohan> arand: they haven't..
<ScottK> rohan: Yes. No. Yes. No.
<jdstrand> rohan: it is being worked on
<jdstrand> rohan: see https://wiki.ubuntu.com/Testing/Firefox3.6.4Upgrade/SecurityPublication
<jdstrand> rohan: hardy and lucid should go out early next week. jaunty and karmic sometime after
<rohan> ScottK, jdstrand : thank you
<rohan> hmm is this going to cause one more point release of 8.04?
<cjwatson> as far as anyone's told me, no more point releases of 8.04 are planned
<ebroder> cjwatson: Are they not going to be done every 6 months anymore?
<rohan> cjwatson: then what is the point of updating the "release notes" for 8.04?
<cjwatson> ebroder: https://wiki.ubuntu.com/HardyReleaseSchedule - "Point releases will cease once Ubuntu 10.04 is released."
<rohan> ubuntu 8.04 support for desktop has expired right?
<ebroder> cjwatson: Ah, ok. I hadn't really been paying attention; my apologies
<cjwatson> we don't have the resources to do point releases for multiple LTS series at once
<cjwatson> rohan: no idea - but of course saying there are no more point releases is not the same as saying there are no more updates
<cjwatson> rohan: no, 8.04 is supported on desktop until April 2011
<cjwatson> we're just not planning more CD image refreshes, that's all
<rohan> i understand, but the page which jdstrand linked to mentions updating the release notes for 8.04, which doesn't make sense
<rohan> and i thought LTS support was 2 years for desktop and 5 years for server..?
<cjwatson> 3 years for desktop
<jdstrand> rohan: you misunderstand
<jdstrand> rohan: those release notes are special notes that need to be added to the USN
<jdstrand> I could have perhaps been clearer, but the idea is that there are additional notes for the 3.6.4 release in hardy, et al
<rohan> jdstrand: oh, i am sorry.
<rohan> thanks for clarifying, cjwatson
<achiang> anyone know what happened to gdk-pixbuf in lucid?
<gord> achiang, nothing? its still there
<achiang> gord: hm, i'm actually looking for the package that would supply the gdk.typelib file in /usr/share/girepository-1.0
<gord> achiang, ah, i have no idea about that
<achiang> and apt-cache search pixbuf doesn't reveal anything interesting
<achiang> nor does apt-cache search gdk
<gord> achiang, there is a gir-repository package (or something like that) that installs a lot of the glib/gnome typelibs
<achiang> gord: yeah, i've got that installed and it doesn't provide anything related to gdk
<geser> Gdk-2.0.typelib is in gir1.0-gtk-2.0
<achiang> geser: ah, there it is! ta!
#ubuntu-devel 2010-06-26
<psusi> bloody hell, bootchart is filling the ureadahad trace buffer with tons of opens to /proc/pid/stat
 * psusi wonders where Keybuck is... not seen him on irc lately
<jmarsden> psusi: I think his name lacks the 'c' :)
<psusi> I think you're right ;)
 * psusi dives back into the ureadahead sources to battle the deamon
<elafroshinobi> hi
<wapadmin> ÑÑÑ Ð¾Ð´Ð½Ð¸ Ð´Ð¾Ð»Ð±Ð¾ÐµÐ±Ñ Ð¸Ð»Ð¸ Ð½Ð¾ÑÐ¼Ð°Ð»ÑÐ½ÑÐµ ÑÐ¾Ð¶Ðµ ÐµÑÑÑ?
<BlackZ> wapadmin: please, write in english
<wapadmin> BlackZ: ÑÐ¾ÑÐ½Ð¸ Ð»ÑÑÑÐµ
<elafroshinobi> wapadmin: check your font settings
<wapadmin> elafroshinobi: Ð´Ð° ÑÑ Ð¾ÑÑÐµÐ»? Ñ Ð¼ÐµÐ½Ñ Ð¾ÑÑÐµÐ½Ð½ÑÐµ Ð½Ð°ÑÑÑÐ¾Ð¹ÐºÐ¸ ÑÑÐ¸ÑÑÐ¾Ð²! ÑÑÑÑÐºÐ¸Ðµ Ð±Ð»Ñ!
<elafroshinobi> wapadmin: your chat looks like you are using a non-english font. Try using the default fault
<elafroshinobi> *font
<wapadmin> elafroshinobi:Ð½Ñ ÑÑ Ð¼Ð¾Ð»Ð¾Ð´ÐµÑ.....
<elafroshinobi> wapadmin: sorry man, I cant understand a thing you are sayin
<wapadmin> .........fuck((((
 * YokoZar wishes there were a "notify" terminal command so he could say: "compile && notify" and then get a message when it's done so I don't have to keep glancing back at a terminal...
<YokoZar> wapadmin: there that sounds better ;)
<wapadmin> The truth?
<elafroshinobi> wapadmin: now you are back on
<elafroshinobi> what truth?
<wapadmin> there that sounds better
<jpds> YokoZar: Use Terminator with split terminals?
<elafroshinobi> I think he meant he can now read your chat
<elafroshinobi> how did you fix it?
<YokoZar> jpds: strangely enough, I'm doing work not on a terminal ;)
<doko> ScottK: python2.6 is in the archive for ia64
<geser> YokoZar: sudo apt-get install libnotify-bin && notify-send "Installation done."
<YokoZar> geser: ah hah, it really is that easy, thanks
<ScottK> doko: I saw that.  I'll try to get to defaults today.  Also I'll drop the priority on the gcc-4.4 bug.  It's a lot less important now that there's a work around.
<daveyj> anyone here use glade for gtk application design?
<ebroder> I'm sort of confused by bug #538912. Why does xlinks have a higher priority than firefox for x-www-browser? This seems too...obvious for there to not be something more sinister going on
<ubottu> Launchpad bug 538912 in links2 (Ubuntu) "xlinks shouldn't replace Firefox as /etc/alternatives/x-www-browser" [Undecided,Confirmed] https://launchpad.net/bugs/538912
#ubuntu-devel 2010-06-27
<KIAaze> hi
<KIAaze> what is the name of the program/script to test install/uninstall/upgrade/etc of a package?
<KIAaze> I remember reading about something like that, but I can't find it anymore
<ScottK> puiparts?
<KIAaze> yes, that looks like it. Thanks. :)
<KIAaze> piuparts*
<KIAaze> I get "chroot: cannot run command `umount': No such file or directory" when trying to use piuparts.
<psusi> cjwatson, you around for a little guidance?  I'm looking into the os-prober scripts because I'd like to add an option to chain load the other grub.cfg instead of parsing all of the entries it contains and adding them to this grub.cfg
<ansgar> kees: The kernel changes to not allow hardlinks in some cases does indeed break (at least) atd: LP #598824
<ubottu> Launchpad bug 598824 in at (Ubuntu) "atd fails to start on new kernel 2.6.35-6" [High,Triaged] https://launchpad.net/bugs/598824
<ansgar> kees: Also, does the patch work with (POSIX) ACLs and on file systems that use different means to check permissions (such as OpenAFS)?
<lool> Hmm mercurial failed to upload on some arches with:
<lool> 2010-06-26 19:10:51 WARNING Unhandled exception processing upload: permission denied for relation emailaddress
<lool> http://launchpadlibrarian.net/50960018/upload_1810533_log.txt
<geser> lool: bug #589073
<ubottu> Launchpad bug 589073 in Soyuz "Unhandled exception processing upload: permission denied for relation emailaddress" [High,Fix committed] https://launchpad.net/bugs/589073
<lool> thanks
<ari-tczew> lool: did you review the patch?
<lool> ari-tczew: Sorry, no, not yet
<kees> ansgar: ah-ha, thanks for the atd bug.  I will find a solution.  the hardlink patch doesn't check extended ACLs, only standard DAC ACL.
<echo6> need some advice on compiling splashutils for fbcondecor in 10.04, getting ar: jcapimin.o: No such file or directory
<echo6> it is related to jpeg-6b libraries libjpg62-dev which are present and also in source tree of splashutils
<kees> ansgar: btw, I'm looking through Fedora's patches for atd, http://cvs.fedoraproject.org/viewvc/devel/at/  some of these looks like they should be upstreamed (especially "nitpicks")
<kees> ansgar: I've attached a patch to the bug report; does that look okay to you?
<ebroder> Can anybody on Lucid reproduce bug #579044? I just grabbed the 2.30.2-0ubuntu1 .deb from Launchpad and I can't reproduce it (with the same gconf setting and custom.conf file). I'm wondering if it's a 32-bit only thing or something
<ubottu> Launchpad bug 579044 in gdm (Ubuntu) "Setting disable_user_list to true causes gdm to crash on clicking "Log In"" [Medium,Confirmed] https://launchpad.net/bugs/579044
<ebroder> Oh, scratch that - I just managed to get it
<ebroder> I think I just wasn't kicking gdm hard enough
#ubuntu-devel 2011-06-20
<pitti> Good morning
<lifeless> micahg: btw ff seems to work ok for me
<micahg> lifeless: cool, thanks :)
<dpolehn> I am kind of a noob.  So I have what is probably a noobish question.  I have bunch of changes after running pdebuild on a package should I shelve these changes before proposing a merge?
<micahg> dpolehn: you shouldn't be running pdebuild in the same dir as the bzr checkout
<dpolehn> oh alright how should I be running it then?
<micahg> dpolehn: use bzr-builddeb
<dpolehn> I had a hard time finding good usage documentation
<dpolehn> ok I am testing to see if it will build on oneiric
<dpolehn> still use bzr-builddeb?
<micahg> dpolehn: yeah, you can pass it an argument to use whatever build env you want
<dpolehn> great thank you
<micahg> dpolehn: you're welcome
<dholbach> good morning
<didrocks> good morning
<rokr1> hello all
<rokr1> I cannot bridge iwl3945 module
<rokr1> Which I can do in debian
<rokr1> any solution
<rokr1> ?
<rokr1> anyone ?
<rokr1> here ?
<persia> Have you tried #ubuntu?  That's a better support channel.  If you're trying precisely the same steps in Debian and Ubuntu and it's not working, you might want to file a bug.
<rokr1> Yes I tried
<rokr1> but seems like its a bug in ubuntu
<rokr1> since its release
<lifeless> cjwatson: if you're around, we have a small q in launchpad about Contents.gz and non-utf8 paths
<lifeless> cjwatson: seeking an off-the-cuff-opinion about LP dropping such paths from Contents[.gz] at some future date (probably a few months out)
<StevenK> lifeless: I've already asked
<lifeless> StevenK: ah!
<lifeless> StevenK: i didn't see it
<StevenK> Not in this channel :-)
<lifeless> StevenK: and did you get an indicative response?
<StevenK> Nope
<cjwatson> lifeless: my answer was "I would not be excessively sad if you felt like dropping non-UTF-8 names from Contents, although it would be better to deal with non-UTF-8 data"
<lool> cjwatson: Hmm I have a weirdo with ssh/sshd; I can ssh locally quickly, but if I pass -X or -XY then it takes a long time before it completes login; it's stuck at "debug2: x11_get_proto: /usr/bin/xauth  list :0.0 2>/dev/null", after it unstucks it says "Warning: No xauth data; using fake authentication data for X11 forwarding."
<lool> cjwatson: oddly, if I 'ssh host "/usr/bin/xauth  list :0.0"' this completes immediately
<lool> now it gets uglier: if I open a regular ssh (no -X/-XY) in another term while the first one is trying to connect, the other ssh gets stuck too
<lool> it seems sshd is stuck on the server side in some long-running call; maybe a reverse DNS check of some form?
<cjwatson> I don't know, sorry - you'd want to run with -vvv, and possibly run a temporary server on a different port with -ddd in order to see what it's doing
<geser> lool: do you use connection-sharing for the 2nd ssh?
<lool> geser: no
<lool> cjwatson: I ran the client with -v, but not the server; ok, will try running a debug server, thanks
<lool> (s/-v/-vvv/)
<cjwatson> if you're very lucky there's already something useful in server:/var/log/auth.log, but probably not
<lool> Didn't find anything relevantin the logs  :-/
<lool> it's just a stream of sessin opened, disconnect, session closed
<lool> but dumping network traffic, I see no additional DNS request over a regular SSH
<lool> (that is, same requests for ssh -XY/-X or for plain ssh)
<lool> cjwatson: with a sshd -ddd, the last line before the hang is "debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0" and the first one after the hang is "debug1: server_input_channel_req: channel 0 request x11-req reply 0", which confirms it's X related, albeit I don't understand how
<lool> -4 doesn't change anything
<lool> http://paste.ubuntu.com/629742/
<cjwatson> perhaps gethostname() is slow
<cjwatson> I'd be inclined to strace the server
<cjwatson> actually, your pause is *before* processing x11-req, why would that be ...
<lool> strace might have private key, right?
<cjwatson> yes
<lool> 9563  11:56:55 select(8, [3 7], [], NULL, NULL) = 1 (in [3])
<lool> 9563  11:57:15 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
<lool> Now what's fd 8
<cjwatson> I doubt that approach is useful
<lool> wtmp
<cjwatson> oh, sorry, misread
<cjwatson> well, that's just "waiting for responses from anything at all for 20 seconds"
<cjwatson> it sounds to me as though it's the client pausing, not the server
<apw> lool, thats not fd8, its any of the first 8 fds, though 3 and 7 i think are marked as intersting .. 3 was the one which did something
<lool> apw: yes sorry
<lool> I can see the PAM session started already
<cjwatson> do you have -vvv output where you've noted the position of the pause?
<cjwatson> (client)
<lool> yep, that was the first message when I pinged you; I'll get a full log
<cjwatson> 'ssh host "/usr/bin/xauth  list :0.0"' is the result of confusion
<cjwatson> ssh is trying to get xauth data on the client side, not the server side
<apw> lool that shouldn't be remote, but local xorg list
<apw> heh what cjwatson said
<cjwatson> snap
 * apw bets the xauth lock is 'lost'
<lool> oh right
<lool> indeed, this command is hanging here
<lool> gah, sorry for the confusion folks!
<lool> I filed LP #799674 on the xauth issue mentioned earlier
<ubottu> Launchpad bug 799674 in lightdm (Ubuntu) "/var/run/lightdm permissions break xauth list" [Undecided,New] https://launchpad.net/bugs/799674
<davmor2> Hey guys quick query I'm running a vm of oneiric and on my netbook too.  I noticed in the vm that you get a warning about not being able to write to /run/udev I thought it was just a vm thing however it is also displayed on the netbook is this an issue,  also I get a string of modem types when shutting down instead of a splash screen.
<cjwatson> davmor2: it's known but there's no particular need to worry about it for the momenet
<davmor2> cjwatson: okay cool just thought I'd check :)
<smoser> anyone core-dev or motu willing/able to sponsor https://code.launchpad.net/~dpolehn-gmail/ubuntu/oneiric/pygame/fix-755980/+merge/65114 ?
<mdeslaur> smoser: sure, I'll upload it, hold on a sec
<RoozbehOnline> mvo: hi dude :)
<RoozbehOnline> are you there ?
<mvo> hey RoozbehOnline, I'm good, thanks
<RoozbehOnline> mvo: daniel holbach intoduce you to me :)
<RoozbehOnline> mvo: you are developer of ubuntu software center yes ?
<RoozbehOnline> introduce *
<mvo> RoozbehOnline: yes, one of the developers indeed
<RoozbehOnline> :)
<RoozbehOnline> good
<RoozbehOnline> i have an idea and im working on since last night
<mvo> what is this idea about :) ?
<RoozbehOnline> mvo: my idea (project) is an online ubuntu app center
<RoozbehOnline> with web2.0 features
<mvo> RoozbehOnline: nice! there is some django code with some basic work on this already, let me try to find the branch
<RoozbehOnline> :)
<mvo> RoozbehOnline: sounds like you and that django project should join forces!
<RoozbehOnline> is it active ?
<mvo> yes
<RoozbehOnline> mvo: http://roozbehonline.net/filez/app-get-soon.jpg
<RoozbehOnline> mvo: can you link me ?
<mvo> RoozbehOnline: check https://launchpad.net/ubuntu-webcatalog it has a bunch of django code already, I haven't checked yet how complete it is at this point though
<RoozbehOnline> mvo: the problem is the base of django is python
<mvo> RoozbehOnline: I'm not really part of that effort, but the ISD people behind it will certainly welcome your input/code/ideas
<RoozbehOnline> mvo: im working with php
<mvo> RoozbehOnline: oh, i see
<RoozbehOnline> mvo: if i do this from scratch will you support this project ?
<mdeslaur> smoser: the fix for pygame is wrong
<smoser> mdeslaur, oh?
<pitti> tseliot: ah, another missing module for py3ification of jockey is python3-curl
<smoser> it does fix the ftbfs
<mdeslaur> smoser: the patch fixes the prompt, but the actual fix is to get the dependencies right so the prompt doesn't get asked
<mdeslaur> smoser: Warning, some of the pygame dependencies were not found. Pygame can still
<mdeslaur> compile and install, but games that depend on those missing dependencies
<mdeslaur> will not run. Would you like to continue the configuration? [Y/n]
<tseliot> pitti: oh, so I guess it's something we'll have to postpone to Oneiric+1?
<smoser> well, thank you for not trusting me, mdeslaur
 * smoser embarrased to not have looked deeper.
<mdeslaur> smoser: lol, I just looked as the fix didn't work when I build it locally with sbuild
<mdeslaur> smoser: it stops until I hit enter
<pitti> tseliot: not necessarily; perhaps python3 now has a non-broken proxy handling for https
<pitti> tseliot: I just stumbled over it when trying to port it some more
<smoser> mdeslaur, it *did* work for me locally with sbuild
<mdeslaur> smoser: huh, curious
<mdeslaur> smoser: I'm using a wrapper and stuff around sbuild, maybe I have a terminal set or something
<tseliot> pitti: ah, good. BTW I'm going to have some fixes for Jockey for multi-arch. We can discuss this in PM
<mdeslaur> smoser: anyway, sorry for giving you the impression I don't trust you :)
<smoser> my sbuild is running on natty, with my sbuild of 0.62.2-1ubuntu1~natty1 (backport of natty for a dependencies resolution fix).
<smoser> http://paste.ubuntu.com/629826/
<mdeslaur> smoser: ok, maybe it's something on my end. Want me to upload it anyway?
<smoser> well, i do see that error in my build logwhic his strange
<smoser> ah, the one in my log though happens , then patches are a pplied, and it does not happen.
<smoser> mdeslaur, i think you're correct though, that something else is amuck.
<mdeslaur> smoser: your call, just let me know if you want me to upload it as-is.
<pitti> tseliot: hm, no hurry with jockey -- it also needs python3-gobject (which should be doable) and python3-dbus (which won't happen most probably)
<pitti> tseliot: and gdbus servers from python are still buggy :(
<tseliot> pitti: right, you mentioned the lack of -dbus last time
<tseliot> too bad
<mvo> RoozbehOnline: ups, missed your last line. it depends on what you mean with support, but I will welcome it and I don't have anything against it. I would prefer having a single project though :/
<MoonTiger> hey guys :)
<MoonTiger> has the glibconfig.h problem been solved yet?
<stat> This is where you come to ask about policies and decisions that have been made for Ubuntu, correct?
<smoser> i'm guessing this is multi arch related..
<smoser> but is this right: http://paste.ubuntu.com/629852/
<smoser> libpng only puts stuff in /lib/x86_64-linux-gnu/libpng12.so.0
<cjwatson> smoser: looks right to me
<cjwatson> the linker knows to look there
<smoser> cjwatson, so.. i'm loking at pygame build, it is just asusming that it can look in /usr/lib for dependency libraries
<smoser> what would you recommend for that simplistic view of the world ?
<cjwatson> it's not uncommon for stupid build systems to make incorrect assumptions about where libraries live
<cjwatson> they should not make incorrect assumptions
<smoser> :) all developers should be as knowledgeable as you, cjwatson, i dont think you'll find argument with that.
<cjwatson> the correct way to link against libpng is to ask pkg-config
<cjwatson> stat: that depends ...
<stat> I'm curious about a choise to disable the "big memory" flag fopr the PAE kernel.
<stat> It seems that the "big memory" flag is disabled by default now. That means you only get a maximum of 3.5GB. If you only get an extra 512MB, why even bother with PAE?
<cjwatson> for the kernel, I'd ask in #ubuntu-kernel instead
<stat> Ah, ok. Thanks.
<smoser> cjwatson, ok. so i'll try to move that to use pkg-config. thank you.
<janimo> rsalveti, do you know why clutter needed to have the same glx soname for the EGL backend? Hardcoded in some packages using Clutter?
<rsalveti> janimo: problem is the way clutter is handling the backends
<rsalveti> currently you still don't have one common so that then can load the backend one, and have different functionalities selected at run time
<cjwatson> smoser: I think you'd want to do something a bit like DependencyProg in config_unix.py, although the pkg-config calling convention is a bit different (--modversion instead of --version, and ask for modversion separately from cflags/libs)
<rsalveti> like support for gl and gles
<smoser> cjwatson, yeah, thats what i was doing.
<rsalveti> janimo: they were still producing different libraries for those different backends
<cjwatson> smoser: *nod*
<rsalveti> janimo: even if the gles abi was almost the same one as the gl so
<janimo> rsalveti, and what woudl be lost if we had an egl.so?
<rsalveti> janimo: we would need to build the clutter applications against it if we want gles support
<rsalveti> there was a bug upstream about this, let me try to find
<janimo> rsalveti, if an app (gnome shell) wants to use clutter, should it know which backend it uses? Now it looks for glx which can be fixed by renaming our .pc file as well from egl to glx
<janimo> but then als includes things from clutter/glx
<rsalveti> janimo: it shouldn't, but currently it's related directly with the backend, as the glx one is the default provider for clutter
<janimo> rsalveti, bug 791310 is where I hit the issue. The configure step can be fixed but I am not sure it won't be even more confusing later when GS thinks it uses the GLX backend, but does not have inlcude paths
<ubottu> Launchpad bug 791310 in gnome-shell (Ubuntu) "gnome-shell version 3.0.1-1 failed to build on armel" [High,Triaged] https://launchpad.net/bugs/791310
<rsalveti> JanC: http://bugzilla.clutter-project.org/show_bug.cgi?id=2276
<ubottu> bugzilla.clutter-project.org bug 2276 in General "Use a single soname for all the clutter flavours" [Normal,New]
<rsalveti> JanC: sorry
<rsalveti> janimo: the upstream bug
<janimo> rsalveti, thanks, no progess since last time apparently
<rsalveti> nops
<rsalveti> janimo: so yes, if we want to maintain the same so with both gl and gles support (based on the arch), then we should make it consistent regarding so name, include paths and so on
<rsalveti> otherwise we'll end up having gl support by default on all archs
<rsalveti> and if you want to use gles you'll install the clutter es package and rebuild your application against it
<rsalveti> :q
<rsalveti> argh
<rsalveti> janimo: currently this is the abi difference between glx and egl: http://paste.ubuntu.com/629870/
<rsalveti> egl is just adding more functions, so it should be at least 100% compatible with the glx one
<rsalveti> janimo: problem is, upstream is not going to accept this change for the 1.x series, and will probably also hard to convince debian to apply them
<rsalveti> janimo: upstream would probably just want to fix 2276, and probably against 2.x series
<RoozbehOnline> mvo: because i cant work with django and python now , i prefer do this with php :)
<RoozbehOnline> mvo: i hope this project become an official project for ubuntu as firefox or chromium home page :)
<RoozbehOnline> in next releases
<Daviey> cjwatson: The netcfg BOOTIF fix, is that a mac address, or IP address field?
<cjwatson> mac
<Daviey> super, thanks
<cjwatson> the syntax is defined in pxelinux's docs
<Daviey> okay, dandy.
<cjwatson> it's basically BOOTIF=01-$(echo "$mac" | tr : -)
<jamespage> cjwatson: when you next take a look at new packages to sync from Debian please could you pull in libpam4j
<cjwatson> jamespage: done
<jamespage> cjwatson: thanks!
<stgraber> geser: ping (DMB if you happen to be around)
<smoser> mdeslaur, if you'd like to revisit the pygame fix, i'd appreciate it at https://code.launchpad.net/~smoser/ubuntu/oneiric/pygame/fix-755980/+merge/65255 .
<mdeslaur> smoser: ah! nice...
<mdeslaur> smoser: that turned into a can of worms apparently :)
<mdeslaur> smoser: sorry about that :)
<smoser> mdeslaur, well, i think it wuld have regressed without your suggestions.
<smoser> its much cleaner now i think.
<smoser> i really dont know if its better to run "wrap-and-sort" or not.  I had originally suggested it to the original poster. the ubuntu version is newer than the debian.
<micahg> smoser: we should only run wrap-and-sort on stuff that's Ubuntu only, it adds an unnecessary diff when merging from Debian
<mdeslaur> smoser: As micahg said, I would tend not to run it if the package is in debian. In this case, it looks like the package diverted from debian anyway quite a bit, so...meh...
<mdeslaur> smoser: uploaded. thanks!
<micahg> actually, there's a new version of pygame on mentors.d.o apparently
<bryceh> smoser, are you still patch piloting?  tedg could use some piloting help on his lp:ubuntu/json-glib branch
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smoser> bryceh, so , no. :-(
<maco> hah. a couple coworkers just walked past my desk:  "do you use ubuntu?" "oh yeah, definitely"
<sladen> were you part of the conversation, or just the listener?
<maco> listener
<ScottK> maco doesn't (AFAIK) use Ubuntu in any case.
<micahg> heh
 * micahg thought she liked Aubergine...
<maco> micahg: nope, i'm K user
<micahg> maco: I know :)
<ScottK> When there was Ubuntu (the project) and Ubuntu Desktop (the product) I think one could reasonably infer that any Ubuntu sibling that has official ISOs was a user of Ubuntu, but since Ubuntu is now the desktop, not so much.
<Keybuk> yeah, I don't use Ubuntu either ...
<Keybuk> it's ironically more confusing
#ubuntu-devel 2011-06-21
<pitti> Good morning
<didrocks> good morning
<dholbach> good morning
<\sh> moins
<smb> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smb
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, my single-sign-on (OpenID AFAIK) does not work any more on wiki.ubuntu.com.
<pitti> tkamppeter: do you get wiki timeouts?
<pitti> I got plagued by them as well since the recent wiki update; I just kept trying until it worked
<pitti> i. e. log in twice, then wait a minute, and press reload
<pitti> then it suddenly worked
<tkamppeter> pitti, yes, after a certain time delay (some minutes) I get 502 Proxy Error.
<tkamppeter> On FF and Chromium.
<tkamppeter> pitti, reload gives: "OpenID error: Nonce already used or out of range."
<pitti> tkamppeter: can you please ask in #canonical-sysadmin ?
<pitti> there's nothing I can do about the wiki, I'm afraid
<tkamppeter> pitti, thanks, I have posted the problem on that channel now.
<zyga> mvo, ping
<mvo> hey zyga
<zyga> mvo, hey
<zyga> mvo, is python-apt a native thing or is it pure python
<zyga> mvo, or actually -- is there a chance to get python-apt up on pypi?
<mvo> zyga: its mostly a wrapper around the c++ libapt stuff, so not native
<jamespage> doko: around? I have a query re a change in openjdk-6 6b23
<zyga> mvo, is it still "normal" setup.py + friends?
<mvo> zyga: yes
<mvo> zyga: but it needs libapt-pkg-dev to build
<zyga> mvo, do you think it would be possible to publish python-apt on pypi
<zyga> mvo, this way one could use virtualenv with --no-site-packages to get it
<zyga> mvo, and still having libapt-pkg-dev installed locally they would build it fine
<mvo> zyga: I don't have experience with pypi, but if its possible, sure, why not
<mvo> zyga: I will ask bary for advice once he is online
<nigelb> 7/w 27
<nigelb> bah
<Ursinha> nigelb: irssi? :P
<zyga> mvo, thanks
<seb128> !pilot in
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smb, seb128
<seb128> (catching up the round I missed yesterday)
<ogasawara> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara, smb, seb128
<seb128> slangasek, since you assigned bug #742017 to yourself should I unsubscribe the sponsors? (i.e will you handle it)?
<ubottu> Launchpad bug 742017 in popularity-contest (Ubuntu) ""readline() on closed filehandle FILES" warnings caused by multiarch" [Medium,Triaged] https://launchpad.net/bugs/742017
<nigelb> Ursinha: Yes :-)
<cjwatson> pitti: language-pack-kok{,-base} is missing from the archive and causing build failures (language-pack-gnome-kok{,-base} is there)
<pitti> cjwatson: lokoing
<pitti> "looking" too
<pitti> hm, they shoudn't even exist
<tumbleweed> can an ubuntu-branches member please mark these merged: https://code.launchpad.net/~marcelstimberg/ubuntu/natty/epdfview/fix-for-783109/+merge/61794 https://code.launchpad.net/~vanvugt/ubuntu/natty/oss4/fix-746048/+merge/64945
<cjwatson> tumbleweed: done
<tumbleweed> thanks
<pitti> cjwatson: ah, I found the bug in langpack-o-matic, fixed; I removed these two empty -kok packages
<cjwatson> pitti: great, thanks
<pitti> funny corner case
<lool> pitti: I don't know what causes it, but I really have trouble booting nowadays; I can only boot when going back to 2.6.38-8-generic, the 3.0 kernels have a too racy boot; I get various types of boot failures
<lool> sometimes I get errors about not being able to rnu dmsetup, sometimes I get the /home couldn't be mounted screen "Keep waiting etc.", if I skip I get lightdm but can't move the mouse or type with the keyboard (not even switching ttys)
<ogra_> can you ssh ?
<ogra_> we have a weird error on omap where the whole usb stack stops working in 3.0 if compiled with the current toolchain
<lool> didn't try, but probably as the system is running: if I trigger a reboot before pressing skip, it will actually reboot -- or if I press the power button
<lool> ogra_: that's known, isn't it?
<ogra_> yes
<lool> ogra_: let me hand you the patch
<ogra_> but your symptoms sound so similar
<lool> no, the omap issue only affects the OMAP USB stack, nothing else
<ogra_> nah, hand it to ppisati rather :)
<lool> this is on a thinkpad, I don't think keyboard and mouse are on USB; plus the build issue is specific to an OMAP struct
<ogra_> k
<ogra_> i dont know much about the bug, just that it only shows up with the recent toolchain
<geser> I get the race with mounting my lvm volumes in oneiric too. I get better a success rate when booting without "quiet splash".
<lool> ogra_: workaround http://paste.debian.net/120560/
<ogra_> lool, ah, i saw that one, doesnt work
<ogra_> paolo already tired that
<smb> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara, seb128
<bdrung> cjwatson: when will be new packages synced from debian. it's in debian for three days.
<seb128> cjwatson, should the sponsors be subscribed to https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/604335
<seb128> ?
<ubottu> Ubuntu bug 604335 in grub2 (Ubuntu) "grub-pc.postinst script fails to detect virtio vda disk in KVM guest" [High,Triaged]
<bdrung> s/n./n?/
<cjwatson> bdrung: which package do you care about?
<seb128> cjwatson, or is that something you will deal with when you have time rather?
<cjwatson> seb128: I'll deal with it when I have time; best not to be dealt with by general sponsorship IMO
<bdrung> cjwatson: packaging-dev
<seb128> cjwatson, ok thanks, that's what I was thinking, unsubcribing the sponsors then ;-)
<cjwatson> bdrung: I literally *just* synced that
<bdrung> cjwatson: :) thanks
<salty-horse> any chance of natty getting this simple fix for a gdb segfault ? https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/691814
<ubottu> Ubuntu bug 691814 in gdb (Ubuntu) "gdb crashed with SIGSEGV in response to strace command with no arguments" [Medium,Confirmed]
<seb128> does anybody has any clue about libevent or an opinion on bug #796187
<seb128> ?
<ubottu> Launchpad bug 796187 in libevent (Ubuntu) "Sync libevent 2.0.10-stable-1 (main) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/796187
<seb128> the version is still in debian experimental but is needed by some softwares (fedora did the update for f15 it seems)
<davmor2> hey guys is the delay for the touchpad disable while typing adjustable?  It's taking 2 or 3 seconds to react once I stop typing in oneiric
<Ampelbein> seb128: re bug 765915, I updated the merge proposal and added a comment. Could you review the patch again?
<ubottu> Launchpad bug 765915 in libqtbamf (Ubuntu Oneiric) "libqtbamf version 0.2-0ubuntu2 failed to build on i386" [High,Invalid] https://launchpad.net/bugs/765915
<mr_pouit> cjwatson: hey, I've again another weird issue with xubuntu daily builds for you (sorry ;-). There's no ubiquity-slideshow-xubuntu in the current daily builds (yet it is in live seed, and apparently recognized by germinate). Ubiquity-slideshow-*edubuntu* is selected and shipped instead...
<seb128> Ampelbein, thanks
<seb128> Ampelbein, about the optional symbols my guess was that somebody marked them optional for a reason so I would like to understand why if we drop them
<seb128> Ampelbein, like it's already weird that symbols are different when building on natty and oneiric
<Ampelbein> seb128: maybe the switch from gcc4.5 to 4.6? I've seen that a few times symbols differ between natty and oneiric.
<Ampelbein> seb128: I think I can agree on the optional symbols comment. There's no harm in having them, I just thought it would be best-practice to have them removed.
<seb128> Ampelbein, well, it might be fine, I will just let somebody with a better understanding of that package decide on why they were marked optional rather than dropped to start ;-)
<omnibus> Ciao!
<pitti> lool: is the booting trouble on arm or x86? haven't had a boot failure in months
<hallyn> mvo: could you take a quick look at bug 800209?  It seems similar to bug 455861 in debconf...
<ubottu> Launchpad bug 800209 in libcap2 (Ubuntu) "package libcap2-bin 1:2.20-1 failed to install/upgrade: error writing to '<standard output>': No such file or directory" [Undecided,Incomplete] https://launchpad.net/bugs/800209
<ubottu> Launchpad bug 455861 in aptdaemon (Ubuntu Lucid) "Possible race in debconf socket forwarding" [High,Fix released] https://launchpad.net/bugs/455861
<mvo> thanks hallyn that looks indeed like it, might be that aptdaemon crashed  too or got killed
<hallyn> mvo: cool, thanks for looking
<cjwatson> mr_pouit: hmph :-)
<cjwatson> mr_pouit: that's really rather bizarre
<cjwatson> mr_pouit: that's freaky.  have you tried reproducing it locally?
<cjwatson> this business of removing .pyc files from the squashfs is good at finding obscure bugs in packages
<didrocks> cjwatson: you mean, packages shipping them?
<cjwatson> yeah
<didrocks> hum, that'sâ¦ interesting :)
 * dholbach hugs barry
<cjwatson> specifically it catches cases where packages run dh_python2 or whatever in the wrong place and thus lose the generated maintainer scripts
<barry> dholbach: we even got our first participant on #ubuntu-pyjam :)
<cjwatson> e.g. python-appindicator (I'm fixing it now)
<dholbach> barry, NICE
<dholbach> barry, I'll blog about it in a bit
<Laney> pyjamas?
<barry> Laney: that's the only appropriate outerwear for the jam session
<mr_pouit> cjwatson: no, not yet (I'm not on my system, so I only browsed through several live build & germinate logs in http://people.canonical.com/~ubuntu-archive/)
<seb128> james_w, hi, could you mark https://code.launchpad.net/~alexandru.cucu/ubuntu/natty/whois/fix-for-785052/+merge/64172 as merged?
<pitti> seb128, james_w: ^ done
<seb128> pitti, oh you can do that? thanks ;-)
<pitti> I wonder why you can't
<pitti> probably because TB owns UDD owns those merges or so
<seb128> likely something like that
<Laney> it's ~ubuntu-branches membership
<seb128> I can set as merged those for which I've upload rights to
<seb128> but natty is stable so I can't for those
<seb128> I think
<bdmurray> seb128: could you look at sponsoring the debdiff in bug 797894?
<ubottu> Launchpad bug 797894 in update-manager (Ubuntu Natty) "update-manager bug reports would benefit from an apport-hook" [Medium,In progress] https://launchpad.net/bugs/797894
<seb128> bdmurray, why do you need to do
<seb128> +    report['GconfUpdateManager'] = command_output(['gconftool-2', '-R',
<seb128> +        '/apps/update-manager'])
<seb128> if you use
<seb128> +    attach_gconf(report, 'update-manager')
<seb128> ?
<bdmurray> attach_gconf only shows the non-default values while command_output shows both
<seb128> why are the default values useful?
<bdrung> barry: do you have a todo list for the dh_python2 transition?
<seb128> we usually want to see what is non standard?
<bdmurray> How would someone easily find the default values?
<seb128> bdmurray, why do they matter? they could be as well variable in the source
<seb128> bdmurray, what is useful on bugs is usually what users tweaked to be non standard, we know what is the standard behaviour
<seb128> well it's mvo's software so I will let him decide what he finds useful in bugs ;-)
<cjwatson> mr_pouit: test-building locally now, will take a while
<mr_pouit> cjwatson: I checked some old build logs, and the latest build containing ubiquity-slideshow-xubuntu is from June 13 (incidentally, just before the switch to live-build). After that, -edubuntu is selected instead (I don't know why we didn't notice that earlier)
<charlie-tca> mr_pouit: attaching the logs to the bug from today
<cjwatson> mr_pouit: ... oh, it's because I'm an idiot
<cjwatson>         xubuntu)
<cjwatson> ...
<cjwatson>                 add_task live edubuntu-live
<cjwatson> charlie-tca: what's the bug#?
<charlie-tca> It was xubuntu slideshow for alpha1
<charlie-tca> bug 800211
<ubottu> Launchpad bug 800211 in xubuntu-artwork (Ubuntu) "Xubuntu desktop installation shows edubuntu slideshow" [Undecided,New] https://launchpad.net/bugs/800211
<cjwatson> yeah, alpha-1 predated live-build
<cjwatson> thanks, I'll take that
<bdmurray> seb128: I can see what you are saying and I'll watch to see if the default gconf information really is useful.  It might be worthwhile to remove it.
<charlie-tca> thanks
<lool> pitti: it's on x86
<mr_pouit> huhu, this explains the issue ;-)
<charlie-tca> I will throw all the logs into it
<lool> pitti: on a thinkpad with LVM root and home
<seb128> bdmurray, thanks, the reason I prefer not having it personally is to avoid having useful informations in the middle of the noise, we should limit what we list to what is useful
<cjwatson> charlie-tca: no need
<charlie-tca> Okay, I won't.
<bdmurray> seb128: and I honestly don't know how to find the default gconf values for an application (regardless of whether or not that is useful)
<cjwatson> fixed for tomorrow's builds
<charlie-tca> Thanks
<mr_pouit> thanks
<seb128> bdmurray, why would the default gconf values be useful? do you try to get the default value of the code variables?
<seb128> bdmurray, software variable defaults are not really useful to debug usually, the code writer know those, what is useful is what is non standard
<pitti> yes, in general it's better to only include "unexpected" information, as then it's a lot easier to read and spot
<bdmurray> okay that makes sense
<apw> pitti, do you use editmoin? and if so is it still working for you
<bdmurray> apw: I think you need to update your cookie in your moin_ids file
<bambee> Evening, I've two bug fixes for language-selector (KDE frontend), Can I propose a merge directly (including a description)? or I need to report a bug ?
<pitti> apw: no, unfortunately it broke with the recent wiki upgrade :(
<pitti> apw: I haven't found a way to make it work again, the new wiki doesn't set the cookie any more
<pitti> apw: it sets _a_ cookie, but that doesn't work with editmoin
<apw> phththt, thats very annoying
<seb128> sbeattie, hi, could you unsubscribe the ubuntu-security-sponsor from bug #783508 ?
<ubottu> Launchpad bug 783508 in nginx (Ubuntu) "nginx package in Lucid Lynx allows null byte vulnerability in certain configurations" [Undecided,Triaged] https://launchpad.net/bugs/783508
<seb128> sbeattie, so it drops from the sponsoring list ;-)
<sbeattie> seb128: sure, though it should be getting auto-closed soon.
<seb128> sbeattie, ok, thanks
<seb128> sbeattie, I forgot it was a security upload, I was thinking normal SRU with the bug staying on fix commited for a week while it's in proposed ;-)
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara
 * dholbach hugs seb128
<seb128> dholbach, ;-) hug!
<dholbach> :)
<Ampelbein> hi there, is there an archive admin available to push gnustep-gui through binary new? thanks.
<RoAkSoAx> hey guys, two upstreams have merged their code of two different projects into one single project. That has left us with a new package in Oneiric (resource-agents). Thjis package replaces the package cluster-agents and some of the bits installed with redhat-cluster (part of both cman and rgmanager). This new pakcage (resource-agents) is not yet in Debian, but will be soon. However, I'll be filing a MIR for resource-agents so I was wondering if it 
<slangasek> RoAkSoAx: you truncated at "I was wondering if it"
<RoAkSoAx> I was wondering if it would make sense to request a removal of cluster-agents (even though it will not be removed from
<RoAkSoAx> Debian anytime soon) or should I just request a demotion
<slangasek> by "request a demotion" you mean "get the package unseeded"?
<RoAkSoAx> slangasek: yeah a demotion from main to universe, and replace all those depends on cluster-agents for resource-agents
<slangasek> archive admins don't demote packages except when the components-mismatches page tells us we can... so just do the replacement of the depends and the archive state will take care of itself
<RoAkSoAx> slangasek: cool. Thanks!
<slangasek> does resource-agents really need an MIR, given that both cluster-agents and redhat-cluster are in main?
<slangasek> a stub bug saying "resource-agents is the software formerly known as prince" is probably sufficient
<RoAkSoAx> slangasek: not really, it basically hsa the same as what's in cluster-agents plus some pieces of redhat-cluster, plus a couple of new scripts/manpages
<slangasek> hmm, are we getting rid of c-a and r-c *both* this cycle, or only c-a?
<RoAkSoAx> slangasek: only c-a
<slangasek> ok... I guess you should file an MIR then, the MIR team might care about having two copies of the r-c source around :)
<RoAkSoAx> slangasek: ok cool.. cause in redhat-cluster I'm just dropping the installation of such files
<RoAkSoAx> slangasek: but anywayas, thanks for the tips
<slangasek> sure
<ogasawara> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<broder> do the Release/Sources/Packages/etc. files in the archive end up in LP anywhere?
<broder> or are they generated entirely externally?
<jelmer> broder, they're generated from the database but not stored in the database
<broder> so there's no archive of them anywhere?
<jelmer> broder: there isn't a as-is copy of them in Launchpad itself, though all the data should be present to reconstruct what was in an archive at a given time
<broder> jelmer: sure, but i can't reconstruct the signatures :)
<jelmer> broder: there might also be external copies/backups of them, outside of Launchpad
 * broder nods
<broder> unfortunately, "ubuntu", "archive", "backup", and "snapshot" are all sufficiently generic that they're really hard to google for
<broder> :)
<em> Oh hi
<jcrigby> cjwatson, ping?
<cjwatson> jcrigby: it's bedtime here, please leave a message
<jcrigby> cjwatson, ok
<micahg> jcrigby: re e-mail to devel-permissions> do you remember who was chairing that meeting?  I would suggest asking that person to e-mail the tech board on your behalf to make it happen
<jcrigby> micahg, thanks, I'll do that
<jcrigby> persia, ping?
#ubuntu-devel 2011-06-22
<maco> i just attempted to allocate the permissions with edit_acl.py. i got an error. can the DMB seriously not do that?
<stgraber> maco: only TB can
<maco> that's annoying
<jcrigby> maco, thanks for trying
<micahg> that's why I said what I said :)
<micahg> any DMB member can e-mail the TB, but in the past it's been the person chairing
<jcrigby> micahg, I sent an email to persia
<jcrigby> per your advice
<micahg> jcrigby: k, if you need this immediately, you could ask one of the other DMB members to do it
<jcrigby> micahg, it can wait until tomorrow.  If I don't hear back from persia I will do that
<broder> email to persia> i thought persia didn't read e-mail
<micahg> jcrigby: I would offer to sponsor but E_NOTACOREDEV
<jcrigby> broder, ok I won't be surprised if I don't here back from him then:)
<jcrigby> micahg, no problem
<stgraber> jcrigby: do you have that package around somewhere? as you're supposed to have upload rights, I'm fine uploading it for you.
<jcrigby> stgraber, actually one of the reasons for uploading today was to test the uploading:)
<jcrigby> stgraber, I actually have 5 linaro kernels to upload total
<stgraber> jcrigby: ok. Got to go now anyway. If it's not solved tomorrow and you want it uploaded, just poke me and I'll upload all of them.
<jcrigby> stgraber, thanks!
<apw> help /buffer
<micahg> RoAkSoAx: why would you add an epoch to a new package?
<RoAkSoAx> micahg cause it ships a binary that is another spurce package which also has and epoc and to upgrade is neecessary
<RoAkSoAx> is in another source package aswell
<micahg> RoAkSoAx: you can do that in debian/rules with a substitution, non need to bump the source like that
<RoAkSoAx> micagh the shource is was already bumped in snother in the old.ackage and needed to be in new package
<micahg> RoAkSoAx: huh?  you can bump a binary separately from the source, see thunderbird in oneiric for an example
<RoAkSoAx> k
<micahg> I would suggest having this deleted and roll back the epoch, it'll make syncing with Debian harder
<RoAkSoAx> bthats how it was handled.by debian initially
<RoAkSoAx> y
<micahg> RoAkSoAx: is Debian introducing the same epoch?
<RoAkSoAx> cluster-agents was handled by thst when got seplarated from heartbeat
<RoAkSoAx> yes we will have same lackage
<micahg> RoAkSoAx: I mean in the new package, if you're sure they'll take the same epoch, that's fine then
<RoAkSoAx> yes they will
<micahg> k
<RoAkSoAx> they are waiting for me to.forward it
<RoAkSoAx> thats all.already been discussed at AUDS
<alex__> Anyone know when the Ubuntu key servers will be back online?
<pitti> Good morning
<micahg> hi pitti :)
<micahg> great timing :)
<pitti> hey micahg -- ready to release the lot? :-)
<micahg> pitti: can I get you to promote all the firefox locale binaries in -updates and -security :)
<micahg> pitti: I had jdstrand do that earlier, we seemed to have forgotten to promote the locale packages to main though
<pitti> ok, I see that firefox itself is in natty-updates/main
<pitti> doing
<micahg> thans
<micahg> *thanks
<pitti> seems the langpacks made it alright
<micahg> \o/
<pitti> so let's hope not too many people only have main enabled, and thus broken the upgrade
<pitti> micahg: promoted now; will hit the mirrors in 70 mins
<micahg> I've only had one bug report so far and I think that was due to the langpacks hitting after firefox (we'll watch for that next time)
<micahg> pitti: thanks
<pitti> slangasek: hey Steve
<slangasek> pitti: hey, how goes?
<pitti> pretty well, thanks!
<pitti> slangasek: I was pondering debian bug 583958, and the 'usergroups' option of pam_umask
<ubottu> Debian bug 583958 in libpam-modules "enable pam_umask usergroups by default" [Normal,Open] http://bugs.debian.org/583958
 * slangasek nods
<pitti> slangasek: your/ceg's proposal seems to be to change pam_umask to read the USERGROUPS_ENAB option, but I wonder how that should behave wrt. the "usergroups" option
<pitti> slangasek: if we make this an "and" , i. e. when you specify "usergroups" it reads login.defs, then we might break systems which expect usergroups to be enabled that way (but disabled it in login.defs)
<pitti> although this admittedly would be a weird configuration
<slangasek> pitti: ah, I was thinking 'or'
<pitti> so the other optiohn would be to imply "usergroups" if login.defs says USERGROUPS_ENAB
<slangasek> and then effectively deprecating the 'usergroups' module option
<pitti> right, that was my idea; so you agree?
<slangasek> yep!
<pitti> so the plan would be:
<pitti> - read login.defs USERGROUPS
<pitti> - document "usergroups" as deprecated
<pitti> - add pam_umask without any options to common-session{,-noninteractive}, as per http://launchpadlibrarian.net/42107572/pam_umask-for-common-sessions.patch
<pitti> sounds ok?
<slangasek> yep, sounds good to me
<pitti> thanks
<slangasek> thank *you* :)
<pitti> I updated the WIs accordingly
<slangasek> pitti: looking closely I see that there's an explicit 'UMASK' setting in our login.defs, which ought to take precedence if set; so we should update login to comment that out at the same time
<pitti> slangasek: that's Debian bug 583971
<ubottu> Debian bug 583971 in login "login.defs: UMASK 022 (and have pam_umask relax it to 002 for private usergroups)" [Normal,Open] http://bugs.debian.org/583971
<pitti> slangasek: I added a WI to update the documentation there
<pitti> slangasek: so you'd rather prefer an implicit default of 022, and not have USERGROUPS_ENAB relax that to 002 automatically?
<slangasek> I don't think USERGROUPS_ENAB should override an explicit UMASK
<slangasek> or was that how login worked before PAM?
<pitti> we haven't used usergroup magic by default in Debian/Ubuntu, so this is a yet undefined territory
<pitti> in the past, /etc/profile just had a static "umask 022", I think
<pitti> lucid still has
<slangasek> "before PAM" was a long time ago :)
<pitti> ah, I took that to mean "before pam_umask"
<slangasek> we don't have to be bound by pre-PAM behavior, but the meaning of login.defs is defined by login, not by pam
<slangasek> so it would be best to be consistent
<pitti> ok, so comment it out by default, and have implicit default be "022 with automatic usergroups"
<pitti> ?
<pitti> and if it's defined anywhere (login.defs, /etc/default/login, and all the other places that pam_umask looks for), just take it as it is
<didrocks> good morning
<pitti> slangasek: the email thread and bug report seem to think that the historic behaviour is that USERGROUPS_ENAB did modify the UMASK default
<pitti> slangasek: it would have the added benefit that you could set 077 and automatically get 007 for user groups
<pitti> but it's a bit less expected indeed
<pitti> slangasek: I'll follow up to the Debian bugs to digest it there
<wgrant> pitti: >= Natty, not >= Oneiric?
<pitti> wgrant: hmm, good question; I guess we could start with oneiric only
<pitti> wgrant: updated bug description
<wgrant> pitti: OK. >= Natty is easier, but >= Oneiric is probably safer.
<dholbach> good morning
<seb128> do we have a wiki page or something explaining how to use submittodebian without a mta configured?
<seb128> i.e without having a working sendmail or whatever
<didrocks> I think there isn't last time I check
<seb128> got a contributor who tried to send a patch to debian following the wiki and says he's blocked because summittodebian write the email but doesn't manage to send it
<seb128> dholbach, ^
<seb128> he's asking if he can tell submittodebian to use his gmail account or something
<micahg> seb128: https://wiki.ubuntu.com/Debian/Bugs#Using_reportbug_to_report_bugs_in_Debian
<micahg> that's the closest I know of
<micahg> and yes, it's not explicit
<seb128> micahg, it doesn't tell you "that relies on you to be a sysadmin and having configured your command line to send emails"
<apw> load /usr/share/weechat/python/go.py
<micahg> seb128: no, if you run reportbug --configure, it should walk you through it
<didrocks> also, IIRC, submittodebian is reporting with the ubuntu version which breaks the version tracking there is in debian (got flamed once because of that, now I edit it or report manually)
<micahg> but idr, it's been almost 2 years
<seb128> micahg, but users don't want to configure a mail server, they just want to send the email on gmail or whatever
<seb128> re
<seb128> sorry, got some issues
<micahg> seb128: not configure a mail server, configure reportbug
<micahg> there's an smtphost setting
<seb128> ok
<seb128> well I still think we could do better ;-)
<micahg> indeed :)
<seb128> like at least give an option "send it using your normal email client"
<seb128> which would just do what i.e nautilus-sendo is doing
<seb128> calling the composer and attach the patch and set the title and text or something
<micahg> well, I just use Debian's SMTP host actually, it's a lot easier that opening in the mail client (and Debian sends you a copy in any event)
<seb128> it's a free to world smtp?
<micahg> yep
<seb128> like you can send a patch with your gmail account by it?
<micahg> well, at least to report bugs :)
<seb128> ok
<micahg> sure, you set the address in the reportbugrc file
<seb128> thanks, I will reply that to the user
<dholbach> is there something that we can improve in the docs?
<micahg> dholbach: invite people to set up reportbug before using submitodebian?
<dholbach> yes
<dholbach> seb128, micahg: I followed up on https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/704845
<ubottu> Ubuntu bug 704845 in Ubuntu Packaging Guide "Add article explaining how to work with Debian/Upstream" [Undecided,In progress]
<dholbach> didrocks, is that a bug that can be fixed in submittodebian?
<didrocks> dholbach: I guess that we should have a way to replace with the current version (or the closest we have) in debian
<seb128> dholbach, thanks, I think ideally submittodebian would ask you whether you want to send it from a command line and telling you what is configured or not or give you the option to open the dump in your email client
<dholbach> yes, that'd be nie
<dholbach> nice
<seb128> so people who want to use their normal email client and see what they send can do that rather than relying on some command line magic to send the email where they get no feedback on whether it worked
<dholbach> can somebody file a bug on ubuntu-dev-tools about that?
<micahg> seb128: reportbug tells you that you should receive a response w/in an hour I think
<seb128> it's still not really intuitive
<seb128> what the contributor emailed me is
<seb128> "The only problem was that I tried using submittodebian (for the first time) but I still haven't found out how to get it send the emails. I reported a bug on this since the tool outputs that the patch was sent but in /var/log/mail.log I could see that this was not the case."
<micahg> seb128: right, it needs more sanity checks for either a local MTA or a remote one
<seb128> "Do you know how to configure sendtodebian, reportbug or postfix to actually send mails using gmail for example(or whatever the easyest way is)?"
 * micahg also thought reportbug offered to configure the first time it's run, does submittodebian bypass that?
<seb128> dholbach, ok, I will do a bit of checking on what works and not and maybe check open bugs and send an email to ubuntu-devel about that
<seb128> dholbach, then I can open a bug as well about what comes out from it
<pitti> slangasek: OK, that's working nicely now; I sent https://code.launchpad.net/~pitti/pam/pam-umask/+merge/65451 your way for a first review
 * dholbach hugs seb128
 * seb128 hugs dholbach
<tumbleweed> seb128: is this in reference to bug 800429?
<ubottu> Launchpad bug 800429 in ubuntu-dev-tools (Ubuntu) "submittodebian needs configured mail agent" [Undecided,New] https://launchpad.net/bugs/800429
<seb128> tumbleweed, yes
<seb128> dholbach, ^ the bug about the issue (the contributor who emailed me opened it)
<tumbleweed> I think it's relatively straightforward to display some instructions if a ~./reportbugrc doesn't exist
<seb128> why do a reportbugrc need to exist?
<seb128> that seems backward, it should just do it works and call your email client composer
<seb128> with the patch attached and the title and text set
<tumbleweed> using an unconfigured reportbug is very irritating (it won't let you set severities, for a start)
<tumbleweed> and unless the user has an MTA on their machine, tehy'll want to configure it to use another MTA
<seb128> why does it need to use reportbug to start?
<tumbleweed> because that's the official method for reporting bugs to debian?
<tumbleweed> how much do we want users to learn how to interact with debian's BTS (which does require some learning)?
<micahg> reportbug is used to find if there's an existing bug in the BTS to attach the patch to as well as manipulate that bug
<tumbleweed> err new developers
<tumbleweed> it doesn't attach the patch for me, (when using it with mutt), must actually look into that...
<seb128> tumbleweed, learning the Debian BTS is fine, learning how to configure sendmail to send a bug is not
<tumbleweed> seb128: you don't need to. reportbug can use your ISPs MTA, gmails, or even debian's
<seb128> well somewhat it manages to confuse contributors, cf the bug we are discussing
<seb128> I've to admit I usually copy the reportbug summary in my email client composer
<seb128> because submittodebian never worked for me either and I didn't want to bother fighting with mail servers when I've a working email client
<seb128> so it's not only that guy ;-)
<tumbleweed> it's really not hard ot get reportbug to work. You just need to know that you need to configure it :)
<seb128> well that's what is driving contributors away
<tumbleweed> indeed, and debian is aware of this, but there is lots of inertia (and some people are afraid that if it's too easy, they'll get bad bug reports)
<seb128> we are not talking about bug reports there, we are talking about patches
<seb128> which are sent in form of bug report, but those sort of bugs should be easy to open
<seb128> if the contributor is technical enough to send you a fix you probably want to make it easy for the fix to reach you
<seb128> it's not like saying you make easy to file "doesn't work" bugs
<tumbleweed> we could easily make submittodebian drop in a .reportbugrc using Debian's MTA for bugs (and tell the user that it did so)
<seb128> ok, so please do that ;-)
<seb128> that would seem a good start
<seb128> though ideally I still think it should open whatever it did in the user preferred email client
<seb128> that way you can pick what email you want to use to send it, you have feedback it's sent, you have it archived in your outbox, etc
<tumbleweed> is there a standard interface for giving an e-mail client a prepared email?
<pitti> persia: in https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-qin-ubuntu-china we discussed "install sunpinyan by default, drop bopomofo"
<pitti> persia: bopomofo maps to ibus-table-zhuyin as far as I can see, but we don't install that by default anywhere, nor does language-selector; am I missing something?
<seb128> tumbleweed, xdg-email is somewhat aiming at that I guess
<seb128> xdg-email [--utf8] [--cc address] [--bcc address] [--subject text] [--body text
<seb128> ] [--attach file] [ mailto-uri | address(es) ]
<tumbleweed> that seems usable
<pitti> echo body | mail -s "subject" address1 ..
<pitti> but requires mailx, which we don't install by default
 * tumbleweed is glad to see zack is still poking debian bug 590214
<ubottu> Debian bug 590214 in reportbug "support for submitting bug reports via http" [Normal,Open] http://bugs.debian.org/590214
<pitti> so I guess xdg-email it is
<Laney> and a configured MTA, which is the problem
<pitti> ah, right
<pitti> how can you not have one :)
<seb128> pitti, the discussion started because relying on a working system email setup is an issue, contributors don't want to have to deal with that
<pitti> right, sorry, misunderstood
<seb128> you also get no feedback of what you send, not outbox archiving, etc
<seb128> pitti, no worry ;-)
<tumbleweed> by default it CCs it to you, so you do get what you sent
<seb128> if it works
<seb128> if it doesn't you have no clue of what is happening and why
<tumbleweed> however we can't get that if we use the debian public MTA
<Laney> ?
<micahg> pitti: can I get you to copy one more thing for me?
<seb128> out of knowing what system logs to read to figure what went wrong
<pitti> micahg: sure
<Laney> I've used X-Debbugs-CC with reportbug.d.o for ages
<seb128> Laney, X-Debbugs-CC?
<micahg> pitti: firefox source, lucid from ubuntu-mozilla-security PPA
<tumbleweed> Laney: I mean submission-time CC
<Laney> does it matter?
<tumbleweed> seb128: that CCs the bug after it's been filed, i.e. to other people who should know about it
<pitti> micahg: to lucid-proposed?
<tumbleweed> Laney: no, I don't think so (assuming it all works)
<micahg> pitti: no, lucid-security
<Laney> what env var does xdg-mail use?
<Laney> http://paste.debian.net/120616/ :'(
<pitti> micahg: done
<micahg> pitti: thanks
<dholbach> hey ev - I just noticed, there's ~ev and ~evand - do you think they can be merged somehow?
<ev> dholbach: oh weird
<ev> annoyingly I can't merge them as evand@ubuntu.com will bounce.  I'll follow up with #launchpad
<ev> thanks for bringing that to my attention
<seb128> tumbleweed, do you plan to send your clasp build fix to debian?
<debfx> pitti, chrisccoulson: the new langauge packs pull in firefox (on natty and oneiric)
<tumbleweed> seb128: did so (that was actually for testing submittodebian changes)
<debfx> firefox-locale-* probably shouldn't depend on firefox
<seb128> tumbleweed, ok, it's not showing on http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=clasp so I was wondering
<tumbleweed> seb128: debian bug 631270
<ubottu> Debian bug 631270 in clasp "clasp: FTBFS with ld --as-needed" [Minor,Open] http://bugs.debian.org/631270
<seb128> tumbleweed, thanks
 * tumbleweed normally includes debian bug numbers in the patch before uploading to ubuntu (naughty me) :P
<seb128> tumbleweed, sorry for picking on this one, I noticed a stack of build fixes in the sponsoring queue yesterday and none sent to debian, I'm trying to see how we do in regard of sending those to debian when we upload ;-)
<seb128> tumbleweed, ideally I think we should have the debian but reference in the patch or changelog
<tumbleweed> yes, I usualyl do that
<seb128> it's a good practice and ensure the fix is sent back ;-)
<diwic> does anybody know why my build fails on amd64 with "dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by debian/snd-hda-tools/usr/bin/hda-verb (ELF format: 'elf32-i386'; RPATH: '')."?
<diwic> is this something multiarch related?
<diwic> never mind, got it figured out I think
<brendand> if glxgears is exhibiting poor performance on my system, is that symptomatic of something?
<directhex> glxgears is not a benchmark
<persia> pitti, I don't remember clearly.  After looking at the spec again, and language-selector, I *think* that the request is to use ibus-table-zhuyin as a useful option, rather than, or in addition to, the set already in place for zh-han*
<persia> Err, nevermind.  I see what you mean now.  I don't see how ibus-table-zhuyin is selected either.
<brendand> directhex - maybe 'poor performance' is the wrong term. it's somehow using much more CPU than other GL applications
<persia> freeflying, Do you happen to remember precisely what was desired for Qin and bopomofo ?
<freeflying> persia: bopomofo is nearly useless to us, try to remove it
<persia> freeflying, Remove from the archive, or just not present it?
<freeflying> persia: not present it
<persia> Do you know how it is presented now?
<persia> It doesn't appear to be the default anywhere.
<freeflying> persia: within natty, if you choose chinesee during installation, it will be presented
<persia> freeflying, Could you file a bug with the precise steps needed to be taken to do that?  I can't find anywhere in the code that seems like it should install ibus-table-zhuyin.  Alternately, do you expect the issue is more about ibus configuration, rather than about the packages that are installed?
<freeflying> persia: seems its not from ibus-table-zhuyin, mostly from m17n
<persia> ibus-m17n ?
<Quintasan> jono: ping
<Quintasan> jono: meh, ubuntu-pl has expired from locoteams-approved, can something be done about that the quick way or we need to follow some procedure?
<persia> Quintasan, You want a member of the LoCo Council for that question: tru #ubuntu-locoteams as a starting point
<persia> s/tru/try/
<persia> freeflying, I'm confused how ibus-m17n even gets installed.  To me it looks like zh-hans should always get ibus-pinyin+ibus-table-wubi and zh-hant should always get ibus-chewing+ibus-table-cangjie
<pitti> freeflying: hm, but we don't install m17n either any more
<persia> pitti, Looking at language-selector, it seems data/pkg-depends is new for oneiric: what was the equivalent in natty?  (I've been looking at the dependencies of binary language-support-input-*)
<pitti> persia: pkgdepends has been around since maverick or even lucid
<persia> pitti, As the handler for input methods?
<pitti> persia: ah, no; in natty we still used language-support-input-*
<pitti> Package: language-support-input-zh-hans
<persia> Ah, good, then I've been looking in all the right places :)
<pitti> Depends: im-switch, ibus-pinyin, ibus-table-wubi
<persia> Right.
<pitti> Package: language-support-input-zh-hant
<pitti> Depends: im-switch, ibus-chewing, ibus-table-cangjie
<freeflying> pitti: persia I was wrong, bopomofo seems included within ibus-pinyin, lemme double check
<persia> Ah, so the request is to modify the configuration of ibus-pinyin so that it doesn't default to bopomofo (or bopomofo is hidden by default)?
<freeflying> persia: hide bopomofo from default
<pitti> freeflying: the request also includes installing "sunpinyan" by default for zh-hans; is that ibus-sunpinyin?
<pitti> if so, should that replace the current ibus-pinyin, or be installed in addition?
<persia> Alternately, is that just a different default for ibus-pinyin?
<freeflying> pitti: yes
<pitti> freeflying: "yes" means sunpinyan == ibus-sunpinyin?
<freeflying> pitti: sunpinyin here means ibus-sunpinyin
<pitti> thanks
<pitti> freeflying: should that replace ibus-pinyin, or be in additino?
<persia> so zh-hans: should specify ibus-sunpinyin+ibus-table-wubi ?
<freeflying> pitti: ibus-sunpinyin itself perform better than ibus-pinyin
<freeflying> pitti: but it lacks a configuration tool atm
<pitti> freeflying: ah, ok; so if we drop ibus-pinyin, and that is the one which pulls in bopomofo, replacing it would also drop bopomofo?
<freeflying> pitti: yes
<persia> Heh, and now "replace bopomofo with sunpinyin" makes sense :)
<freeflying> pitti: is this the plan for oneiric? if so, I will talk to ibus-sunpinyin upstream to see if they can implement the configuration
<chihchun> No.
<persia> chihchun, ?]
<pitti> freeflying: I was asked to do that in https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-qin-ubuntu-china
<freeflying> pitti: ok, btw, ibus need merged from sid to get gtk3 support
<pitti> ah, right
<chihchun> persia: I thought  "replace bopomofo with sunpinyin" is plan for general ubuntu installation
<chihchun> persia: but it's ok for china only.
<pitti> chihchun: right, this is all per-locale now (zh_CN)
<freeflying> pitti: #789882
<persia> chihchun, It's the expected default for all zh-hans environments.
<pitti> zh_TW/zh-hant has different ibus modules
<chihchun> no problem
<chihchun> understand. :-)
<persia> chihchun, So, if you're working in zh-hant, you can ignore this.  If you think that it makes sense to have bopomofo as default for zh-hans, be prepared to make a very strong argument.
<pitti> freeflying: ok; seems the biggest thing there is porting the indicator, but that shoudln't be too hard
<pitti> freeflying: so, we add ibus-sunpinyin and drop ibus-pinyin, which will also get rid of bopomofo; right?
<freeflying> pitti: to merge from sid, I think indicator's patch still works
<freeflying> pitti: exactly
<pitti> freeflying: nah, needs porting to gir1.2-appindicator
<pitti> freeflying: thanks
<pitti> but that should be easy
<persia> The beauty of a 3-character patch :)
<freeflying> pitti: the only difference between sid and oneiric is gtk3 support, guess we enable it, and add a binary package would be fine
<pitti> freeflying, persia: ugh, replacing pinyin with sunpinyin would be a + 5 MB compressed size increase :/
<pitti> would we actually need to install that on the default ubuntu CDs, or is it enough to have on the Chinese Edition?
<pitti> cjwatson: ^ do you know?
<freeflying> pitti: indeed, sunpinyin is statisitical language model based
<cjwatson> pitti: we're going to have to talk at the rally about localised CD build questions.  until then I don't know
<pitti> well, even the Ubuntu CD will install it when you select Chinese, but would download it from the network
<pitti> cjwatson: ok, thanks
<cjwatson> pitti: (because right now the Chinese edition uses the very same livefs and pool as the primary Ubuntu images)
<pitti> cjwatson: we are going to have an ubuntu-defaults-chinese package anyway (https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-qin-ubuntu-china), perhaps we can build the Chinese edition with that
<pitti> ok, -> rally
<cjwatson> I think that would be the idea, yes
<cjwatson> since all the ubuntu-defaults-* changes are additive, presumably this would still mean that the localised Chinese image wouldn't fit on a CD
<pitti> yeah, we'd need a separate solution for dropping all other langpacks from that
<freeflying> ubuntu-chinese-default-settings and ubuntu-chinese-meta hit universe since natty
<cjwatson> freeflying: that's not what we're talking about
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-cd-localization
<persia> Where ubuntu-defaults-${LOCALE} just provides localised configuration for default packages, whereas *default-settings provides configuration variables for a flavour?
<pitti> the package name doesn't have to have any particular form, although ubuntu-defaults-french or derivative-default-settings are the two recommended forms
<persia> I'd like to avoid the word "derivative" in this context, as it's already overloaded in lots of ways.
<persia> I'd also prefer to avoid declarations based solely on common language names: should the same values be used in Quebec and France?
<persia> Obviously, friendly locale names are preferred, rather than "zh_CN" or similar :)
<pitti> persia: I mean like "mythbuntu-default-settings"
<cjwatson> I don't see why that's obvious.  People get these packages mainly by downloading images, not by selecting the package name for a list.  Personally I'd rather that the packages used locale names to keep it simple and avoid collision.
<pitti> OEM custom projects also use that schema
<persia> pitti, Ah, sorry.  Missed that as a variable.  Sure.
<cjwatson> or will get these packages, anyway, according to the Plan
<persia> cjwatson, So use the same sort of strings we used for language-support-* ?
<cjwatson> yep.
<pitti> well, l-support provided packages for all countries of a particular language
<cjwatson> but probably with more instances of country codes tacked on the end.
<pitti> these are not really just language bound
<persia> Ah, so maybe it is better to use proper locale codes then.
<freeflying> same scheme like language-support-xx would be clear
<pitti> if the France loco team wants to do their own image, they'd probably call it -france, but I agree that the standard ll-cc schema avoids conflicts
<pitti> so we probably should recommend that
<persia> Or rather, flattened codes (e.g. de_at)
<persia> Err, "de-at" (_ is prohibited)
<pitti> and a special -bavaria edition, with a white-blue background by default
<cjwatson> just use ISO-639-3 for that and call it ubuntu-defaults-bar. :-)
<pitti> (gotta do somethign with those excess mirror space, bandwidth and iso testing resources..)
<persia> pitti, Well, at least the french and japanese teams are likely to prefer their own mirror networks anyway (as they already have infrastructure).  Wouldn't surprise me if the same was true for several other locales (with which I'm less familiar).
<persia> Similarly, many locos are already doing ISO testing for remastered images, so that implies there are resources.
<pitti> persia: that was the idea indeed
<pitti> persia: we absolutely don't want to host/test a dozen iso flavour
<pitti> s
<pitti> persia: but instead write tools that allow locos etc. to do them on their own with a safe and "approved" set of tools
<persia> Right.
<persia> Mind you, I'm all in favour of hosting as many flavours as can justify themselves technically, but I categorically exclude language-specific variants as potential "flavours".   This may just be my personal nomenclature though.
<didrocks> persia: indeed, for the french at least, we have something like 15 mirrors in our infra, so I guess it's better to rely on that
<didrocks> (some having the official flavors as well, but most of them only hosting our own respin)
<persia> didrocks, Do you guys do just ubuntu-fr, or also kubuntu,. xubuntu, etc.?
<persia> We've done kubuntu-jp a couple times, with some interest (with not much overhead over having the first remix)
<didrocks> persia: we just do that for the ubuntu desktop iso. But we have kubuntu-fr.org and xubuntu-fr.org domain name. Just don't provide a respin (would be too much work)
<persia> The new tools should help with that :)
<persia> But it depends more on your testing resources than anything else.
<didrocks> right, the thing is that we press 10 000 CD of ubuntu desktop respin, we can't do that for kubuntu-fr and xubuntu-fr ;)
<didrocks> right
<persia> Oh, certainly.  I think the last time we pressed the Japanese remix, it was only 3000 or so, but the other flavours were download only.
<didrocks> noting that the testing has already limited ressource on our first respin (which is also used for framakey ubuntu-fr remix which is an usb key sharing profiles between windows/mac/ubuntu with portable applications), which is quite scary for the volume of pressed CD/installed usb key we have :)
<didrocks> but sure that other flavors can come as download only
<mterry> doko_, ping about deja-dup's MIR (well, really ubuntuone-couch).  It's ready to be re-reviewed after converting to dh_python2
<jcrigby> cjwatson, pitti or some other other TB member I need to get permissions to upload some packages.  This was approved on the DMB mtg on 23May and I believe persia sent an email about this yesterday or earlier today.  My application is here (it lists the packages) https://wiki.ubuntu.com/JohnRigby/DeveloperApplication-LinaroLinuxAndUBoot
<jcrigby> also is there a way to check permissions without actually trying an upload?
<Daviey> jcrigby: Yes, and you currently have no upload access.
<Daviey> :(
<jcrigby> Daviey, that is actually not a surprise:)
 * cjwatson goes to see if that mail is in the mod queue
<cjwatson> I don't see any such mail
<cjwatson> the TB is happy to act when instructed by the DMB but I'd prefer to actually get an instruction from them directly :)
<cjwatson> let's see, I wonder if I can find the meeting log
<Daviey> jcrigby: I note that another package set (adding user to lp team) hasn't been actioned yet.  So they may be still doing the actions
<stgraber> cjwatson: http://irclogs.ubuntu.com/2011/05/23/%23ubuntu-meeting.html
<jcrigby> cjwatson, persia was the chair that day and said yesterday that he would send an email to the TB
<Daviey> oh wow, i assumed that was a recent meeting.
<cjwatson> OK, found it now
<cjwatson> jcrigby: done now
<jcrigby> cjwatson, thanks!
<cjwatson> I've also done upload rights for hrw's cross toolchain packages
<cjwatson> I'm a bit surprised at the backlog there.  Perhaps somebody could check whether there are any other things that the TB is supposed to have taken action on?
<hrw> cjwatson: armhf ones? thanks
<cjwatson> no, armel-cross-toolchain-base gcc-4.4-armel-cross gcc-4.5-armel-cross gcc-defaults-armel-cross
<hrw> cjwatson: ok
<cjwatson> are the armhf ones in the archive yet?
<cjwatson> or the 4.6 ones?
<hrw> cjwatson: yes, they are now. I was busy with other tasks to ask for upload permissions
<cjwatson> if you could give me the source package names, I can add them
<sarit> the command "/lib/udev/firmware --firmware=/lib/firmware/2.6.39.1/bnx2/bnx2-mips-09-6.2.1a.fw --devpath=/dev" gives libudev: set_loading: error: can not open '/sys/dev/loading'. Any ideas?
<hrw> cjwatson: armhf-cross-toolchain-base, gcc-defaults-armhf-cross, gcc-4.4-armhf-cross, gcc-4.5-armhf-cross, gcc-4.6-armhf-cross
<hrw> cjwatson: and same for armel: armel-cross-toolchain-base gcc-4.4-armel-cross gcc-4.5-armel-cross gcc-defaults-armel-cross gcc-4.6-armel-cross
<cjwatson> oh, looks like the armel bits may have been there already
<cjwatson> I've added the armhf packages now
<hrw> thx
<hrw> cjwatson: I asked TB for most of armel ones in past
<didrocks> dholbach: can you advise to use debcheckout for http://people.canonical.com/~dholbach/packaging-guide/html/udd-intro.html#getting-the-source please? (see https://code.launchpad.net/~amoog/ubuntu/oneiric/libqtbamf/lp-765915/+merge/65132)
<slangasek> pitti, seb128: do you know if I should merge pitivi 0.14.0-2 from Debian?  I touched it for the dh_python2 migration, now it's under my name on merges.u.c :)
<seb128> slangasek, that would be great ;-) should be an easy one
<seb128> slangasek, thanks
<slangasek> seb128: ack - didn't figure the merge would be problematic, but I don't use it so my testing will be non-existant :)
<seb128> slangasek, that's fine, I just run it and close it usually to test, we are few changes over debian and nothing likely to break it
<dholbach> didrocks, could you file a bug on https://pad.lv/p/ubuntu-packaging-guide?
<didrocks> dholbach: sure :)
<slangasek> seb128: ok :)
<dholbach> didrocks, I'm not 100% sure what exactly is the best approach and if it always works, so maybe it's good if somebody else comments on it as well
<didrocks> dholbach: agreed, I'll link to my discusson on ubuntu-devel mailing list as well
<dholbach> gracias!
 * mvo just discovered "gummi" the latex editor
<juliank> mvo: Sounds interesting
<pitti> mvo: hah, nice name
<mvo> looking over the new stuff in app-install-data is always fun :)
<didrocks> I was more found of Kile :)
<slangasek> cjwatson: so as ev mentioned in the meeting, all the options for updating wubi this cycle seem to imply it won't fit on the CD anymore.  Where does that land on our priority list?
<ev> not all of them. It might be wise to keep the legacy version around, if that's the route we go with.
<ev> so at least they have *something* on the CD
<slangasek> ev: a complete legacy branch, or a legacy frontend that's maintained in parallel?
<ev> a complete legacy branch
<ev> unless we're still writing python code
<ev> the wubi code is actually core/ui split
<slangasek> right; having two completely different branches of wubi would worry me
<slangasek> doesn't seem sustainable
<ev> ideally the old one wouldn't break and we wouldn't have to poke it much, other than to update it for new versions of grub and whatnot.
<ev> that's actually largely been the case
<ev> we barely touch the UI code these days
<ev> mind you, I may live in a fantasy land full of rainbows and unicorns
<slangasek> I've heard that said about London :)
<ev> lol
<slangasek> well, we could let wubi drift for a few cycles that way, but I think ultimately we'd wind up with only one of the two well-supported
<ev> sure, but in a few cycles time hopefully the number of Windows XP users hitting Ubuntu.com will be far, far less
<ev> or they'll all have .NET 3.5
<cjwatson> I think it's still pretty cool for inserting a USB stick into a Windows system to do something useful, although it doesn't have to be the current form
<slangasek> meaning we'd do *another* rewrite?  Or we'd target .NET 3.5 now for the website with the understanding that it's not good enough for the CD?
<cjwatson> even if it were a shell one of whose options downloaded stuff from ubuntu.com to kick off wubi
<cjwatson> a bit weird, but ...
<ev> slangasek: well, we could be fancypants and offer up the legacy version on the website where we can detect a version of .NET older than 3.5
<slangasek> hah
<slangasek> I don't think we'd want that, really
<ev> and do the rewrite in WPF or whatever Microsoft is pushing on top of .NET these days
<ev> why not? It's in the user agent string.
<ev> simple enough
<slangasek> yes, but then it gives them a crippled experience
<slangasek> if they're on the website downloading anyway, better to give them the full experience
<ev> it's better than no experience or a 50MB download before they get an experience
<slangasek> I'm not convinced the latter is true
<cjwatson> we haven't touched UI code very much, but I do occasionally have the need to work on the backend Python code; I'd appreciate it if that were at least somewhat accessible to Ubuntu developers who aren't Windows developers
<cjwatson> e.g. if you're going to use .NET, make sure it works with mono, or something
<ev> yeah, I was just thinking I should really test that.  The .NET 3.5 installation experience when running a WPF application, that is.
<ev> mono> WPF wont, Silverlight will.
<cjwatson> didn't moon just get removed?
<slangasek> ev: I don't want a user to have a completely different experience clicking the "install Ubuntu" link from one XP machine where they happen to have .NET upgraded, than on another machine where they haven't, with no explanation
<ev> Moonlight? I have no idea.
<cjwatson> or I'm pretty sure I saw directhex talking about it
<ev> That would be an interesting development.
<ev> slangasek: fair point.
<slangasek> oh hah, that's why no one's complained about the util-linux merge breaking things, it's still in NEW
<hallyn> hm, when i do debuild -S, it gets to telling me what user (mine) it will sign with, but never asks for passphrase
<hallyn> oh, it's complaining about dead agent
<hallyn> nm
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<broder> stgraber: fyi, overlay doesn't support more than 2 branches, unfortunately
<broder> it just has an "upper" and "lower" branch
<broder> err, overlayfs
<hallyn> broder: yeah but you can nest them :)
<broder> blech
<stgraber> broder: ok, I guess I'll have to play with that soon...
<cjwatson> jhunt: I've fixed the priority_list problem you spotted in debconf
<cjwatson> it only happened if you did 'use Debconf::Priority' under 'use strict' before 'use Debconf::Config' (or something else that used Debconf::Config)
<stgraber> broder: hey, I'm looking at the SRU for bug 565047
<ubottu> Launchpad bug 565047 in initramfs-tools (Ubuntu) "Unable to install off USB 3.0 port (HP Envy 15 Laptop)" [Undecided,Confirmed] https://launchpad.net/bugs/565047
<broder> stgraber: yeah, i think the fix in oneiric is still pending
<broder> last i heard cjwatson was waiting to figure out what was going on with /run before merging the new initramfs-tools
<stgraber> broder: so apparently debian's initramfs-tools in version 0.99 fixes it but it's not in oneiric yet. Should I just apply the same fix to oneiric for now and upload the SRUs or wait till we get 0.99 in oneiric?
<broder> stgraber: cherry-picking the commit for oneiric for the time being seems like a good idea, since the /run stuff seems to be a bit stalled
<broder> i can do the writeup for that in a few minutes if you'd like
<stgraber> broder: that'd be great. Just let me know when it's done and I'll upload all of that
<jhunt> cjwatson: thx!
<broder> stgraber: do you know if the SRU team will still do forward-copies of packages like they do with 0-day SRUs? because that would work here
<stgraber> broder: I don't think it's part of the official SRU process, at least I noticed quite a few cases where that didn't happen.
 * broder shrugs
<broder> not like the debdiff is hard to put together or anything
<stgraber> broder: in this case I'd just upload 0.98.8ubuntu4 in oneiric and the exact same thing as 0.98.8ubuntu3.1 to -proposed
<broder> stgraber: ok, debdiff with s/ubuntu3.1/ubuntu4/ is attached to the bug :)
<broder> i didn't want to mess with the branch because i don't know what to do with Keybuk's /run change
<stgraber> broder: ok, I'll have a look. thanks
<stgraber> broder: hmm, yeah, I'm not entirely sure how to deal with what's currently in the branch for oneiric...
<stgraber> I don't really want to upload what's in the branch at the moment. I just want to upload the bugfix...
<stgraber> barry: how should I deal with that? (non-uploaded changes in a packaging branch where I just want to apply a small bugfix but not upload what's currently waiting in there)
<slangasek> stgraber: I think in general people shouldn't push changes to the official packaging branch before they're ready for upload; is there a reason you don't want to upload those at the same time?
<slangasek> is the stuff on there right now entangled with /run?
<stgraber> slangasek: yeah, current content of the packaging branch is the switch from /dev/.initramfs/varrun to /run (changes to the init script and manpage)
<slangasek> mmk
<stgraber> slangasek: http://paste.ubuntu.com/630925/
<slangasek> what's the current holdup with /run?  I thought that was ready to go
<stgraber> well, maybe it's ready to be uploaded but as Keybuk is a coredev I'd think he'd have uploaded it then. I know that broder's fix won't cause any problem when uploaded to oneiric but I really don't have the same confidence with the /run change :)
<stgraber> looking at the code currently in the branch, it "seems" good. The only thing I'm wondering is what will happen if /run doesn't exist on the target (as it's currently the case in oneiric)
<broder> stgraber, slangasek: there was also the change that Keybuk had sitting on top of base-files. initramfs-tools might be good to go if you upload the base-files change first
<broder> stgraber: yeah, the new base-files creates /run
<stgraber> broder: where's that code? I don't see any non-uploaded commit in ubuntu:oneiric/base-files
<broder> stgraber: it got moved out of the way by the package importer: https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/base-files/oneiric-201105041859/+merge/59981
<stgraber> hmm, for base-files, shouldn't we instead merge 6.4 from debian that essentially does the same thing ?
<broder> On upgraded systems, initscripts will handle the transition to /run> seems potentially problematic for us
<stgraber> I'm almost tempted to just upload broder's fix to oneiric without using UDD. Let the imported move the current changes from Keybuk to another branch as the whole switching to /run thing seems to be a bit more work than what I'm prepared to do when patch piloting :)
<stgraber> *importer
<broder> geez. the number of things that change to support /run in sysvinit 2.88dsf-13.3 is terrifying
<stgraber> I "could" upload base-files with the changes from Keybuk, then upload initramfs-tools with a strict dependency on base-files + broder's fix. But I'm really quite worried I'm going to break a lot of systems just a few days before people go to the sprint...
<broder> haha, and look what happens if you say "Keybuk" enough times :-P
<stgraber> hehe
<stgraber> hey Keybuk
<stgraber> Keybuk: broder has a simple one line patch to apply to initramfs-tools in oneiric and I noticed you currently have non-uploaded changes in the branch for the switch to /run
<stgraber> Keybuk: should I move your changes to a separate branch for now and upload broder's fix or are the changes to switch to /run ready to upload?
<Keybuk> stgraber: oh, yes
<Keybuk> sorry, I stalled my changes based on things in Debian
<Keybuk> and didn't back them to a branch
<Keybuk> so yeah, move my changes out of the way for now
<stgraber> Keybuk: ok, thanks
<stgraber> slangasek: what's the best way of doing that? do a direct upload and let the importer deal with it or do a push to another branch, then uncommit, then push overwrite to the packaging branch?
<slangasek> Keybuk: what's stalled on the Debian side?  I thought it was moving along over there
<slangasek> stgraber: whatever you do, do NOT uncommit - the importer will never forgive you :-)
<slangasek> stgraber: direct upload + importer dealing seems fine
<stgraber> slangasek: ok, noted :) will do a direct upload then
<stgraber> slangasek: AFAICS initramfs-tools, base-files and sysvinit have all been uploaded to Debian
<stgraber> so unless I missed something, sid should already be using /run
<Keybuk> slangasek: nothing, I mean I stalled my side when I realised it was already being worked on there
<slangasek> ah
<stgraber> broder: uploaded for oneiric, natty-proposed and maverick-proposed. Thanks!
<broder> stgraber: rock on. thank *you*
<charlie-tca> ubuntu-bug xubuntu-default-settings
<charlie-tca> or
<charlie-tca> ubuntu-bug xubuntu-meta
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2011-06-23
<lamont> bah.  what's the command for checking wireless network bios switch settings?
<lamont> rfkill
<lamont> is it really such an unusual work model to fire off something and then start doing work in another window while that gets going, where you really don't want the newly-spawned window to hijack focus from the work that you are now doing in the second window??
<lamont> or is that just me?
<lamont> </rant>
<TheMuso> lamont: Yeah had that with virtualbox in natty with compiz/unity-decorator.
<ScottK> There you go again.  Thinking it's you that knows best.
<TheMuso> I'd start a VM, put it on another workspace, move back to the original workspace to do work, only to find the VM window appearing in that workspace where it is least wanted.
<lamont> ScottK: heh
 * lamont just killed the libvirtwindow he spawned while closing tabs in xchat
<lamont> TheMuso: one more reason to not use virtualbox, thanks
<infinity> lamont: I'm pretty sure we consider it a bug when things steal focus (unless they're justifiably modal, like gksudo).
<lamont> infinity: you'd think
<infinity> lamont: I tend to find it refreshing when I swap between Windows and Ubuntu, and the very same software in Ubuntu DOESN'T do that, while it does in Windows.
<lamont> infinity: sometimes, I wonder if it's because of focus mode ==strict in metacity :)
<infinity> lamont: No, no.  I'm not being facetious.  As in, people consider it to be more than an annoyance, but somewhere hovering between accidental DoS and potential data loss, since if you're blissfully clicking about when something steals focus, you can do Very Bad Things.
<lamont> yeah
<lamont> I know you're serious
<infinity> lamont: So, I'd file bugs with extreme prejudice, if I were you.
<lamont> infinity: I'll work on reproducing it
<TheMuso> lamont: In that case I blame compiz, not virtualbox.
<lamont> compiz has hooks to defeat what virtualbox is doing
<lifeless> barry: ; around ?
<didrocks> good morning
<dholbach> good morning
<didrocks> guten morgen dholbach
<dholbach> salut didrocks
<diwic> TheMuso, ping
<TheMuso> diwic: Hi.
<diwic> TheMuso, I want to set up daily builds for pulseaudio git master, do you have an opinion on what ubuntu-audio-dev ppa they should be in?
<TheMuso> diwic: Oh right, let me have a glance at what we have, and will create one if I think we need another.
<TheMuso> diwic: ok will create another one.
<diwic> TheMuso, I think it would make most sense to create a new one
<TheMuso> Right, doing so.
<TheMuso> diwic: ppa:ubuntu-audio-dev/pulse-testing
<TheMuso> Fire away.
<diwic> TheMuso, while you're at it, a ppa for the daily dkms builds as well perhaps?
<TheMuso> Sure.
<TheMuso> diwic: ppa:ubuntu-audio-dev/alsa-daily
<diwic> TheMuso, thank you
<TheMuso> No problem.
<diwic> TheMuso, hopefully I can create recipes myself if not, I might poke you again
<TheMuso> No problem, ai M end of day, but I will take a look tomorrow.
<diwic> TheMuso, ok, seems I can create recipes
<diwic> TheMuso, as for the packaging of this I plan to start off with our ubuntu.oneric bzr tree, remove all of patches subdirectory and a little thing in debian/rules
<diwic> TheMuso, and leave the rest. Does that make sense to you?
<NCommander> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<NCommander> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: NCommander
<tkamppeter> pitti, hi
<seb128> cjwatson, do we need ssh-askpass-gnome on the CD?
<seb128> cjwatson, I'm reviewing the gtk2 rdepends list and I was wondering if we need it since gnome-keyring has an ssh agent
<cjwatson> seb128: last time you asked me this I complained about all the bugs I get due to gnome-keyring's agent
<cjwatson> ssh-askpass-gnome is 15K
<cjwatson> is it worth talking about? :-)
<seb128> cjwatson, the gtk2 depends is worth, I will open a bug "needs to be ported to GTK3" ;-)
<cjwatson> sure, shouldn't be hard
<seb128> cjwatson, right, I will file one, I'm just trying to make sure we are on track to drop GTK2 from the CD for the LTS if we can, first step is to know where we stand and what needs to be done ;-)
<seb128> (same for gconf)
<cjwatson> yep
<seb128> cjwatson, I asked if we need it on the CD because it seems duplication, the users who know enough about ssh agent to want to replace the default one are likely to know how to install the one they want
<seb128> cjwatson, but as you said the CD space is not worth arguing ;-)
<cjwatson> yeah, I guess it wouldn't be that bad if it went off the CD
<seb128> well let's say I don't care enough either way to argue, it just seems not logical to have 2 agents on the CD, either we think gnome-keyring is too buggy and it shouldn't be the default or we think it's fine for being the default and users who have extra need can install the other one
<seb128> but anyway, let me open the bug to port to GTK3, CD or not we will need to port it ;-)
<cjwatson> tseliot: where's the latest branch for the x-kit package?  Vcs-Bzr says lp:~albertomilone/xorgparser/main, but that branch is not in sync with the latest upload
<tseliot> cjwatson: right, I think I have it here in my local branch. Let me check
<tkamppeter> pitti, hi
<seb128> tkamppeter, he's off today, it's an holiday in Germany
<tkamppeter> seb128, thanks, it is not a holiday in all the states of Germany. In Berlin it is a workday.
<seb128> tkamppeter, well pitti said it was an holiday for him in any case ;-)
<seb128> yw
<tseliot> cjwatson: the last revision seems to match the last upload: https://code.launchpad.net/~albertomilone/xorgparser/main https://launchpad.net/ubuntu/+source/x-kit
<tseliot> maybe there's something that I'm missing?
<cjwatson> tseliot: diff it against the actual unpacked package and you'll see
<tseliot> ok, let's see
<cjwatson> tseliot: http://paste.ubuntu.com/631173/
<tkamppeter> Anyone works with the problem that a service taking a random port stealing the port from another service with a fixed port?
<cjwatson> should only happen if the "fixed" port is foolishly in the ephemeral port range
<dholbach> barry will give a session about porting to dh_python2 in #ubuntu-pyjam in 24 minutes
<tkamppeter> cjwatson, CUPS uses port 631 which is the officially reserved port for the Internet Printing Protocol IPP. It seems that before CUPS got loaded on boot, another service has taken port 631.
<tkamppeter> cjwatson, bug 800424.
<ubottu> Launchpad bug 800424 in Ubuntu "package cups 1.4.6-5ubuntu1.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Fix committed] https://launchpad.net/bugs/800424
<tseliot> cjwatson: I really don't know what happened there. I moved to git and I use it only to maintain the code (without the debian directory): https://github.com/tseliot/XKit
<cjwatson> tseliot: perhaps you could fix it up?
<cjwatson> tkamppeter: don't know then sorry
<cjwatson> tseliot: I only ask because I have a patch to submit to make it use dh_python2
<tseliot> cjwatson: sure, is it urgent? As I'm trying to fix nvidia-* and fglrx before leaving for the Platform sprint
<cjwatson> tseliot: well, not urgent as such, but the dh_python2 porting jam is today and it would be pretty nice to clear out main
<cjwatson> I can just file a bug with the patch
<apw> clap4ham
<apw> heh how many times will i do that i wonder
<Laney> :(
<apw> its a test box password thankfully
<mterry> doko__, ping about ubuntuone-couch
<Laney> Some of my passwords are so embarrassing that if I ever type them to IRC I'll never live it down
<apw> heh, a problem :)
<Laney> it makes me more circumspect :-)
<apw> we should all use "i hate irc" as our password
<tseliot> cjwatson: would it be ok if I simply pushed to my bzr branch the diff that you've just shown me?
<tseliot> and correct the rest another time
<tseliot> cjwatson: or maybe I can do the right thing now and leave it as UNRELEASED so that you can complete it with your work and upload?
<jdstrand> cjwatson: fyi, I just happened to be preparing an openssl-blacklist upload, so I'll process your patch rather quickly :)
<jdstrand> cjwatson: that for that and openvpn-blacklist patches
<jdstrand> interestingly, it was not ssl2, but a difference with openssl 1.0.0 output
<cjwatson> jdstrand: heh, ok, thanks
<cjwatson> tseliot: sure, I don't really mind
<cjwatson> tseliot: I'll just send you the dh_python2 patch in a bug and you can sort it out as you see fit
<tseliot> cjwatson: ok, thanks a lot
<mterry> StevenK, is it your archive day?  Could you do a pass on MIR bugs today?  I know a couple just got approved (deja-dup & etc, qt-at-spi).
<mterry> StevenK, nm, didrocks is faster than me
<lamont> what does it mean when I upgrade a machine from hardy to lucid and the last thing it says it that it was mounting filesystems?
<lamont> other than that it sucks to be me
<elmo> lamont: on reboot?
<lamont> yeah
<elmo> lamont: if so, it means you need to take some stuff out of /etc/fstab
<lamont> ah, ha.
<lamont> sigh
 * lamont debates one more time whether it's easier to bring the monitor to the machine, or the machine to the monitor
<lamont> elmo: ta
<smoser> jibel, https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/801132
<ubottu> Ubuntu bug 801132 in indicator-session (Ubuntu Oneiric) "indicator-session should depend on indicator-session-gtk2" [Medium,Fix released]
<smoser> i'm just curious, why "recommend"  and not depend ?
<jibel> smoser, I don't know, I just pasted the relevant part of the changelog, kenvandine would know better.
<jibel> kenvandine, ^
<smoser> in my experience it doesn't start without. that would seem "depends"
<seb128> smoser, jibel: because unity will use gtk3 next week
<seb128> so that's just a transitional workaround
<seb128> indicator-session is the gtk3 version
<seb128> in theory it shouldn't pull in the gtk2 version
<seb128> you might also use indicator-applet or a gtk3 loader in which case you don't want the gtk2 binary
<seb128> but yeah, we could have used a depends, it wouldn't have made any difference with that typo ;-)
<smoser> good enough for me.
<kenvandine> thx seb128 :)
<seb128> yw ;-)
<smoser> jibel, i apologize for opening up 2 duplicate bugs today
<jibel> smoser, no worries, that's good for my karma ;-)
<jibel> seb128, thx for the explanation.
<apw> if you have a Recommends: foo | bar  1) does the order matter, and 2) will this pull all of them onto the CD or is that controlled some other way ?
<slangasek> apw: the order does matter; it won't pull them all onto the CD, only one of them - but whether you get foo or bar depends on whether something else has already pulled in bar
<apw> slangasek, what does the order imply ?
<slangasek> apw: it implies which one is the preferred alternative :)
<apw> slangasek, are you saying you get the first unless something asks for one of the latter ones
<slangasek> yes
<apw> slangasek, thanks
<lynxman> jdstrand: ping
<jdstrand> lynxman: yes?
<lynxman> jdstrand: hey o/
<lynxman> jdstrand: got your email concerning mcollective-plugins
<lynxman> jdstrand: fixing the copyright issues and the one lintian error
<lynxman> jdstrand: but I really rather not use sed -i as you suggest
<lynxman> jdstrand: that's what I was using before, and in some scenarios it resulted in an empty config file
<lynxman> jdstrand: which is really not desirable
<jdstrand> lynxman: I think you should talk to Daviey who just contacted me about all this
<lynxman> jdstrand: that's why I made it a lot simpler
<lynxman> jdstrand: I'm talking with Daviey, just wanted to justify the reasoning behind that one :)
<lynxman> jdstrand: no worries, thanks for your time
<jdstrand> lynxman: cool. though the sed -i is troublesome to me-- that sounds like a serious bug in sed. you might want to report that if you have a reduced test case
<lynxman> jdstrand: as soon as I get the package ironed out I'll see if I can reproduce reliably and do so, thanks :)
<Daviey> I'm finding the lintian issues to be concerning.  On oneiric lintian i'm not seeing them with both pednantic and information mode.
<Daviey> Ah, i think i only dug that deep on the source package
<AnAnt> would someone help with LP #798513 ?
<ubottu> Launchpad bug 798513 in lintian (Ubuntu) "Candidate revision lintian 2.5.1ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/798513
<AnAnt> also, could someone review LP #796136 ?
<ubottu> Launchpad bug 796136 in swt-gtk (Ubuntu) "Candidate revision swt-gtk 3.6.2-1ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/796136
<Daviey> AnAnt: If nobody beats me, i'll do the swt-gtk one in a few hours.
<AnAnt> Daviey: thanks
<Ampelbein> hi there! what could be the reason that https://launchpad.net/ubuntu/+source/gridsite/1.7.13-5 fails on amd64 on the buildd, but works in a amd64 pbuilder, on i386 and powerpc? The file missing should have been created by the build and I can't seem to find a reason why it doesn't work.
<micahg> Ampelbein: looks like a buildd fluke, I'd say retry it
<micahg> I just had it work fine in sbuild locally
<Ampelbein> micahg: thanks, I'll retry the build
<Ampelbein> micahg: retrying worked, strange thing. thanks again.
<micahg> Ampelbein: no problem
<akheron> why some libraries are in /usr/lib/i386-linux-gnu and some are in /usr/lib ?
<Ampelbein> akheron: multiarch enabled libraries are in /usr/lib/<triplet>
<akheron> Ampelbein: what does "multiarch enabled" mean?
<Ampelbein> akheron: http://wiki.debian.org/Multiarch/
<akheron> Ampelbein: do you know whether /usr/lib/<triplet> is a widely used standard location for this purpose?
<Ampelbein> akheron: as far as I know debian/ubuntu are the first to implement multiarch.
<akheron> I just happened to notice that Python's build system doesn't look there by default, and therefore doesn't enable some modules at compile time
<akheron> ok... may I'll file an issue and see what happens
<broder> akheron: it should as of the latest 2.7
<akheron> s/may/maybe/
<akheron> broder: ah, but I'm compiling 3.2
<broder> that might work too? i'm not up to speed
 * broder attempts to summon barry
<barry> hi
<Ampelbein> akheron: that would be bug 738213
<ubottu> Launchpad bug 738213 in python2.7 (Ubuntu Natty) "Python build from source lack some modules due to non-standard libraries placement" [Critical,Fix released] https://launchpad.net/bugs/738213
<akheron> actually I'm talking about vanilla Python source tarball
<barry> akheron: the fix should be in our source package, and it's been pushed upstream, but that version hasn't been released yet.  it'll show up in 3.2.1
<barry> akheron: for now, grab the setup.py from hg (or just grab the hg branch)
<akheron> barry: ok, thanks
<barry> akheron: np.  i have no eta for python 3.2.1
<ScottK> barry: If only you knew someone involved in release management for Python.
<ScottK> ;-)
<barry> ScottK: or, if only i was insane enough to rm 3.2 :)
<slangasek> doko__: hi, regarding http://wiki.debian.org/Python/PyCentral2DhPython2, there's a comment to "read /usr/share/doc/python/changelog.Debian.gz to check if you need a newer version"... what should we be looking for when reading the changelog?
<seb128> does somebody known the name of an usb sniffer? i.e something to watch the communication between a device and the computer
<smoser> is there a tool available to forward-to-debian other than report bug and referencing ubuntu bug ?
<nigelb> submittodebian?
<nigelb> smoser: ^^
<slangasek> smoser: submittodebian if you have a patch; for opening an upstream bug corresponding to an LP bug, no, I don't think we have anything
<nigelb> Its in ubuntu-dev-tools.
<slangasek> and I don't think Debian would welcome anything more automated than that :)
<nigelb> slangasek: wait, we might. bryce wrote something, let me hunt.
<smoser> i was aware of submittodebian
<hallyn> stgraber: doh!  the patch I sent to teh m-l was wrong.  I had apparently not doing a git add before git commit --amend
<hallyn> stgraber: but the version in the bzr tree I pointed you to is right
<Laney> Actually it might be good if submittodebian could take a Launchpad bug# and pre-fill the email with the description (and attach patches)
<smoser> i was just doing bug triage and have in other cases come across the same situation, where i have a low-ish priority bug that ideally we'd like to have fixed in debian and synced rather than just fixed in ubuntu.
<nigelb> there is a wrapper that someone wrote, I just dont remember where the source was
<smoser> i guess submittodebian isn't too bad for this.
<slangasek> yeah, if you have a patch for it, I'd use submittodebian
<pitti> slangasek: hey Steve
<slangasek> pitti: hey there
<pitti> slangasek: so for the md5summing of common-session and friends, I take everything between the magic markers, including or excluding the markers themselves?
<slangasek> pitti: IIRC it's the sum of the whole file, minus the lines with the tokens that get replaced
<micahg> Laney: well, I think taking from the upload is better than the bug since the patch can be modified before upload and not reattached
<slangasek> pitti: so: sed -e'/^$/d' | md5sum
<Laney> depends what you want to do really
<pitti> slangasek: get_template_md5sum()'s state machine explicitly triggers on the magic comments, that's why I ask
<pitti> I'm trying to reproduce the original mdsums to be sure
<pitti> ok, I'll play with this
<pitti> (it's not just dropping the $ line)
<pitti> well, I'll just call that very perl function, I guess
<nigelb> oh, well, I can't find what I was looking for.
<nigelb> I clearly remember attempting this and someone actually writing it better than me.
<nigelb> smoser: okay, I found what I was looking for earlier - http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/launchpadlib-scripts/forward-bug-to-debian.py
<stgraber> hallyn: hehe, that explains it :)
<hallyn> sorry about that
<nigelb> slangasek: ^^ there is indeed a script to forward bugs to debian using the LP api and wrapping over reportbug
<smoser> thanks nigelb
<nigelb> :)
<pitti> slangasek: ok, got it
<pitti> slangasek: do you know why there's both an %md5sums map in pam-auth-update, and debian/local/*.md5sums files?
<pitti> (which don't match)
<pitti> slangasek: ok, MP updated
<pitti> thanks
 * pitti waves good night
<doko__> slangasek: sorry, don;t know. didn't write this :-/
<poolie> barry: hello? want to talk about oauth?
<barry> poolie: no, but i will ;)
<barry> poolie: what do you know about it?
<poolie> uh, basically, how urgent is it?
<poolie> i'm sprinting this week
<poolie> and next
<barry> poolie: will you be in dublin next week? it can certainly wait until then
<poolie> i can ask someone to look at the import failure tomorrow, since the bug seems to have a reasonable way to resolve them
<poolie> i will be
<poolie> ok
<poolie> next week or after that we can try to upstream my patches
<barry> sounds good, thanks
<slangasek> doko__: oh, barry said you did write it :-)
<slangasek> pitti: the debian/local/*.md5sums files are for migration from pre-pam-auth-update versions; I'll eventually be able to drop those I think
<slangasek> doko__: http://wiki.debian.org/Python/PyCentral2DhPython2?action=recall&rev=3 says you did write it... but if you didn't have anything specific in mind, I'm happy to continue ignoring that bit :-)
<stgraber> pitti: thanks!
<slangasek> bdmurray: when you submitted your latest patch to software-center, did you do that against a bzr branch somewhere?  Because the one listed in the Vcs-Bzr field is out of date, and the UDD branch is clearly auto-imported
<bdmurray> slangasek: this one I think - https://code.launchpad.net/~software-store-developers/software-center/trunk
<slangasek> bdmurray: aha, thanks
<barry> cr3: ping
<cr3> barry: pong dude, what's up?
<barry> cr3: hiya!  we've been working over in #ubuntu-pyjam on the dhpy2 conversion.  chadadavis has a branch that looks good to me for checkbox.  since lp:checkbox has debian/ in it, what is the best way for us to get the change into ubuntu?  i can do an upload, but what about merging his branch into trunk?
<cr3> barry: will that run in oneiric?
<barry> yes, it should
<cr3> barry: even in the live environment?
<barry> cr3: that i don't know ;)
<cr3> barry: if you could find out and the answer is positive, then consider it done. we'll just merge chadadavis' branch and start playing with it
<cr3> barry: just know that my only constraint is: make ubuntu happy
<Awsoonn> hi all, I'm wondering if there is a wiki page for debugging unity that you can point me to
<Awsoonn> I just upgraded to unity and got myself a blank desktop. :(
#ubuntu-devel 2011-06-24
<broder> TheMuso: ping? i was looking at python-virtkey for the dh_python2 jam, and slangasek noticed that the there's a lp:python-virtkey branch owned by ~onboard. there are recent commits to it, but it doesn't reflect the last two archive uploads, so we were wondering if you had any idea what's up
<slangasek> TheMuso, broder: looking closely at the branch history, it doesn't appear that lp:python-virtkey quite matches what's been uploaded even before the two latest uploads; so I'm going to drop the Vcs-Bzr field since it doesn't appear to be accurate
<TheMuso> Sounds reasonable.
<aldeka> Hi all!
<aldeka> So, I have a dumb question.
<aldeka> Roughly how many people contribute to Ubuntu? Hundreds? Thousands?
<aldeka> (I guess meaning people who wrote a patch, or who were otherwise significantly active, in the past year)
<sladen> aldeka: hard question to answer.  There are many more people who contribute to Ubuntu than write patches!
<aldeka> That is true.
<sladen> aldeka: it's a bit like the "how long is a piece of string" question
<aldeka> Heh.
<sladen> aldeka: For example, there are 1350+ people who've have subscribed to and install the PPAs to beta test early versions of the ubuntu Font Family
<sladen> aldeka: and taking the time to beta-test fonts is a pretty niche activity
<aldeka> Wow.
<aldeka> re: # of font-testers
<sladen> aldeka: https://launchpad.net/~ubuntu-typeface-interest/+members
<NCommander> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<NCommander> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Good morning
<ion> that
<didrocks> good morning
<dholbach> good morning
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, it is about bug 801306, a user is only able to use AirPrint when he adds "ServerAlias *" to cupsd.conf. What should we do?
<ubottu> Launchpad bug 801306 in cups (Ubuntu) "Airprint from Safari on ipad doesn't print" [Undecided,Confirmed] https://launchpad.net/bugs/801306
<pitti> slangasek: is it ok for you if I upload the multiarch cups in 4 days (when the current version went to testing)? if you need it earlier, I can do an ubuntu specific upload
<slangasek> pitti: there's no hurry
<pitti> tkamppeter: <hostname.local> is the standard FQDN for zeroconf networks
<pitti> tkamppeter: but '*' seems a bit excessive for that -- cups should listen to all local hostnames in /etc/hosts (all names for 127.0.*.*) and for <hostname.local>
<pitti> this seems to be a more sensible internal default
<pitti> slangasek: for the pam upload, do you want to wait until I have the shadow upload ready with the updated login.defs documentation?
<slangasek> pitti: I don't think you need to wait
<pitti> I'll fix that today anyway, just want to know whether you are waiting for something else, or want me to upload
<tkamppeter> pitti, so we should patch CUPS to add "<hostname>.local" to their internal defaults?
<pitti> tkamppeter: I think so, yes
<pitti> tkamppeter: I wonder why it doesn't do that already -- after all, the .local stuff is way more popular in the apple world
<tkamppeter> pitti, so this can even be a bug in CUPS and not a missing feature.
<pitti> tkamppeter: yes, I think so; it's certainly upstreamable
<pitti> tkamppeter: well, it might be an omission in our avahi patch
<slangasek> pitti: you can upload; otherwise I'll do so after merging the latest Debian upload
<pitti> slangasek: ok, then I'll upload it together with shadow, so that we have this in a2
<tkamppeter> pitti, the error message originates from scheduler/client.c
<pitti> slangasek: I sent an updated patch to the BTS as well (although I guess that's just you with a different hat as well :) )
<slangasek> pitti: same hat, just wearing it backwards ;)
<pitti> clever!
<tkamppeter> pitti, it is a bug in our patch, scheduler/client.c has "#ifdef HAVE_DNSSD" sections, these need also be compiled if Avahi is present.
<AnAnt> Daviey: ping (reminding you of swt-gtk)
<tkamppeter> pitti, other possible DNS-SD bugs are in cgi-bin/admin.c, scheduler/ipp.c, as these files also contain "#ifdef HAVE_DNSSD" but are not modified by cups-avahi.dpatch.
<Daviey> AnAnt: ok, thanks
<Daviey> AnAnt: hmm.. the debdiff doesn't seem to cleanly apply?
<AnAnt> huh
<AnAnt> let me check
<Daviey> AnAnt: for example, in the Debian version you are a Uploader: , but not in the debdiff?
<Daviey> AnAnt: i can fix it up, but i'm interested what happend?
<AnAnt> dunno
<AnAnt> Daviey: while I prepare a fixed debdiff, any comments on the dropped change I mentioned ?
<AnAnt> Daviey: done
<Daviey> AnAnt: it looks good to me, visually
<AnAnt> Daviey: ok, please sponsor then :)
<tumbleweed> didrocks: we upload ubuntu-dev-tools to Debian where possible
<didrocks> tumbleweed: oh sorry, didn't notice that, do you want to sponsor it and then we make a dummy sync?
<didrocks> will know for the future : )
<tumbleweed> sure, can do. did you upload yet?
<didrocks> tumbleweed: I just did, let me check again
<didrocks> tumbleweed: should be in the next round, right. If we don't upload ubuntu-dev-tools only for ubuntu, we should really rename the package name :)
<tumbleweed> didrocks: heh, we're trying to get most of the non-ubuntu-dev-specific scripts rehomed elsewhere
<didrocks> tumbleweed: I've just seen more than 4 weeks of pending changes, hence the upload, if you want, just upload 0.126 in Debian and I'll sync
<tumbleweed> I'll see if I can get some of the pending merges landed first
<tumbleweed> bdrung: any objection to merging broder's fix-785854 branch?
<cjwatson> lamont: should we migrate bug 797555 into RT in order to get some of your work time on it?
<ubottu> Launchpad bug 797555 in libjboss-buildmagic-java (Ubuntu Oneiric) "libjboss-buildmagic-java needs a manual build using the unstable binaries" [High,Confirmed] https://launchpad.net/bugs/797555
<ogra> cjwatson, just fyi (and since i have the first images today since the change) manifest files work fine on preinstalled images now
<cjwatson> oh good
<dholbach> pitti, do you have an idea why community-o-new-ubuntudev-outreach does not show up on status.u.c?
 * ogra would like to see his team on status.u.c actually :)
<pitti> dholbach: no work items defined -- you need a "work items:" header :)
<dholbach> gah, I'm stupid
<dholbach> thanks pitti
<pitti> dholbach: also, note that the [dholbach] tags are redundant -- you are already the default WI assignee as you are the BP assignee
<pitti> they don't hurt, of course, just make typing harder
 * pitti hugs dholbach
<dholbach> ah ok, good to know
<dholbach> thanks pitti!
<ogra> pitti, are you maintining access for teams to that ? i would like to see ubuntu-armel on there
<pitti> ogra: you mean like http://status.ubuntu.com/ubuntu-oneiric/ubuntu-armel.html ?
<pitti> ubuntu-armel has been in the reports for ages, I think
<ogra> err
<ogra> it hasnt been there a week ago or so
<pitti> ogra: but anyway, the config is writable by platform, lp:~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config
<pitti> hm, perhaps
<ogra> oh, its the wi tracker code it uses as backend
<ogra> then i'm fine
<pitti> ogra: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html has data since at least May 26 (UDS)
<ogra> yeah
<pitti> so the config was there before; perhaps status.u.c. didn't because of a recently fixed bug?
<ogra> it just wasnt on status.u.c and i didnt know they are the same
<pitti> they are separate instances really
<pitti> people.u.c. is the old one, but keeps running until status.u.c has been fully announced and the quirks shaken out
<ogra> yeah
<ogra> ok, then i'm fine, sorry for the noise
<pitti> no problem :)
<tkamppeter> pitti, the fix for CUPS (new cups-avahi.dpatch) is on its way ...
<pitti> tkamppeter: cheers!
<lamont> cjwatson: RT gets core-hours time applied to it, launchpad bugs are after-hours things, so yeah, RT will get it more attention, esp since it's written up so more than just me can do it
<tkamppeter> pitti, slangasek, current Debian BZR is FTBFSing, it does not pass the built-in regression tests. So I will test my changes on an SRU for Natty and add it to Oneiric as soon as the code stabilizes/the multiarch addition is finished.
<Daviey> Laney: around?
<Laney> yep
<Daviey> Laney: are you able to ack jamespages membership to ~ubuntu-server-dev please?
<Daviey> https://launchpad.net/~ubuntu-server-dev
<Daviey> (he was in approved in the most recent meeting)
<Laney> sure
<Daviey> Laney: thanks \o/
<Laney> beep boop blop
<Laney> there we go
<Laney> jamespage: enjoy
<jamespage> Laney: thankyou!
<Daviey> super!
<Laney> lucas: hey, I just got around to crunching the ubuntu -changes archives into a format similar to the one you use for debian-devel-changes... http://master.debian.org/~laney/ubuntu-changes-split/ â would it be easy for you to set up a table in UDD for these?
<Laney> I also changed http://master.debian.org/~laney/munge_ddc.py to work with them
<Laney> "To: warty-changes@rince.africaninspace.com" heh heh
<Daviey> Laney: where did you get the original archives from?
<Laney> -changes mboxes on lists.u.c
<Daviey> oh interesting.
<Daviey> I thought the dead releases were no longer there.
<elmo> they're just not advertised, they're still there, we try not to remove stuff unnecessarily
<Daviey> elmo: rocking
<Laney> just filed an RT ticket to have them rsyncable so that I can be more server friendly
<Laney> currently I have to dowload the whole mbox again when there's an upload
<Daviey> Laney: you don't want to know how i recently parsed them. :)
<Laney> using one of the many great Free mbox parsing libraries?
 * Laney coughs
<Daviey> no comment
<lucas> Laney: quite
<lucas> Laney: I'll add it to my TODO, but will try to get to do it this afternoon
<Laney> thanks
<Laney> I shall set up a daily cron to update them
<Laney> it'll have Launchpad-Bugs-Fixed (IIRC) as well as Closes
<lucas> ok
<tkamppeter> pitti, tested AirPrint fix on Natty and pushed it to Debian BZR repo.
<cjwatson> lamont: ah, now that I look, I see that jamespage already did.  RT#46381
<lamont> cool
<lamont> ISTR a few more that may or may not have migrated yet
<lamont> my plate is currently plenty-full until july 7 or so, fwiw
<ScottK> lamont: Slightly unconveniently we got our first real "Hey, please make multi-instance work" bug today.
<lamont> ScottK: on the bright side, I have a plane ride coming up real soon where I'll be able to make some time to work on that
<lamont> may even stuff that in on sunday
<ScottK> Nice.
<lamont> not just because, well, using it myself
<ScottK> lamont: That's handy as I've got a project that's currently on BSD that may move to Ubuntu and it would be very convenient for me not to have to figure it out.
<lamont> ScottK: you have my permission to pester me relentlessly on multi-instance
<ScottK> Excellent.
<zul> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: zul
<pitti> zul: happy flying
<zul> pitti: thanks
<apw> pitti, had any reports of the burn-down reports being shy some tasks?
<apw> pitti, i am seeing only 1 TODO on alpha2 for our ubuntu-delta-review on your tables, but my matrix shows 5 todos in the same combinations
<tkamppeter> pitti, I have now uploaded the SRU for Natty for the AirPrint fix (bug #801306).
<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
<pitti> tkamppeter: thanks
<pitti> apw: hey
<apw> pitti, hey
<pitti> I didn't have reports, let me look
<pitti> hm, indeed
<apw> pitti, i presume the db is ok as my report has them in
<pitti> it looks like it leaves out the WIs from the people who aren't in ~canonical-kernel-team?
<pitti> ah, no
<pitti> manjo is in the team
<pitti> apw: ooh
<james_w> do the workitems have the same description?
<pitti> apw: the work items have the same name
<pitti> james_w: snap :)
<pitti> apw: right, it seems it assigns one and the same WI to different people, and the report identifies them
<james_w> they are counted in the burndown, but not shown in the table
<pitti> probably the last one wins, or whatever the DB order is
<apw> pitti, yes ... but we changed that ages ago to allow it
<apw> as its clearly something one might want to do, i specifically remember fixing it
<james_w> well it's broken again :-)
<james_w> https://bugs.launchpad.net/launchpad-work-items-tracker/+bug/795681
<ubottu> Ubuntu bug 795681 in work-items-tracker "Work Items with same descriptions are counted as one, eventhough they are for different milestones" [Undecided,New]
<james_w> same cause I think
<apw> james yeah sounds likely
<pitti> apw: but in this case they are on the same milestone
<pitti> so we probably need to include the assignee into the primary key?
<james_w> It may be enough to just remove the DISTINCT around description in the queries
<pitti> hm, the WI table doesn't even have a PK
<james_w> there's nothing that stops you from creating identical workitems, but I'm not sure it's the tracker's job to enforce that
<apw> james_w, whats confusing is when we had this same situation in natty ... i went through and took them all out cause it caused exactly this problem
<apw> its not obvious why we want to squash them ever
<apw> (all out, all the DISTINCTs out)
<james_w> apw, http://bazaar.launchpad.net/~work-items-tracker-hackers/launchpad-work-items-tracker/trunk/revision/239
<james_w> so I don't think you took them all out
<james_w> you fixed it for the graph by the look of it
<apw> james_w, very odd we didn't notice till now ... fair enought ... will try and look at it next week
<bdrung> didrocks: you uploaded u-d-t to oneiric and that adds work to me.
<bdrung> didrocks: we were waiting for distro-info to get accepted in debian
<didrocks> bdrung: tumbleweed already mentionned it to me, I never noticed that a package with ubuntu in the name was synced from debian. I added some fixes and seeing no release for more than 4 weeks, I decided to upload. Sorry for that
<didrocks> bdrung: tumbleweed told me he would upload on debian and then I'll sync back
<slangasek> seb128: components-mismatches picked up a weird build-dependency tree, gtkmm2.4 -> gtkmm-documentation -> gtkmm3.0; do you know whether we should be migrating to gtkmm3.0 for main, or if we need to cut out the dependency?
<pitti> it's mainly just gnome-system-monitor and parted which use these
<jdstrand> zul: ok, libvirt 0.9.2-4ubuntu1 uploaded. while it build fine on amd64, hallyn's 9023-disable-test-poll.patch was dropped. if builds fail, you might want to grab it from 0.9.1-1ubuntu4, adjusting it for 0.9.2
<pitti> slangasek, seb128: cjwatson already started porting gparted to 3.0, and if/when that happens, I think we could just drop g-s-monitor from the default install
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<slangasek> pitti: +inkscape :)
<pitti> slangasek: that's not on the CD, though
<pitti> slangasek: at some point it ought to be ported as well, of course, but the pressure is lower there
<slangasek> pitti: right, well I was asking about component status, and inkscape is in main at leat
<slangasek> least
<pitti> from that POV I think it should be in main; it's similar to gtk-3, a new upstream version of the C++ bindings, but new package names as we need for for some time
<slangasek> ok
<slangasek> does it need an MIR?
<pitti> we usually handled new upstream versions with changed names without one
<pitti> mterry, didrocks, doko ^ ok with you, or do you want an MIR?
<didrocks> sounds that more paperwork isn't needed IMHO
<mterry> pitti, yeah, that's fine
<pitti> I promote it ithen
<hallyn> jdstrand: thanks!
<pitti> bah @ typing -- TGIF
<didrocks> pitti: becoming a mac addict? ;)
 * pitti pats his Android mobille
<didrocks> :)
<pitti> didrocks: hardly -- after installing my mother's iPod touch I loved android five times more :)
<didrocks> pitti: heh, never touched those things. Still happy with my android phone :) but ithen -> izen? maybe a new concept coming? :)
<slangasek> pitti: right, but we usually don't give carte blanche to having more than one upstream version in main at the same time - but if you're all happy, that's fine :)
<pitti> slangasek: necessary wart, I guess; the bindings themselves are by and large zero maintenance anyway
<pitti> it's gtk2 and 3 themselves which double work
<slangasek> sure
<broder> pitti: re bug 565047, i am still using maverick in a couple of places where i saw hardware support regressions in natty, so i would like to get the fix into both m and n. i can do the verification legwork
<ubottu> Launchpad bug 565047 in initramfs-tools (Ubuntu Natty) "Unable to install off USB 3.0 port (HP Envy 15 Laptop)" [Undecided,Fix committed] https://launchpad.net/bugs/565047
<Jarvis> hmm, have a curious issue regarding direct access to keyboard events. It seems certain applications want direct access to /dev/input/event* (namely java apps)
<Jarvis> i'm wondering whether to bug rep it or not
<Jarvis> can anyone think of a reason not to give world read access to /dev/input/event*
<broder> because i don't want every unprivileged user to be able to see my keystrokes?
<Jarvis> somones suggested possibly dropping it into its own group and giving access to that
<Jarvis> i've no clue why java (lwgl it seems inparticular) wants read access like that, but hey
<Jarvis> fair point broder
<Jarvis> i might try and find out why its directly accessing it in the first place
<Jarvis> as it shouldn't be
<jaberwokey> Should questions about the C appindicator api be asked here, or in #ubuntu-app-devel?
<ScottK> jaberwokey: I would guess the latter or #ayatana.
<jaberwokey> k, thanks
<seb128> re
<seb128> slangasek, pitti: yeah, just promote it
<seb128> the goal would be to use gtk3 if we can this cycle
<Ampelbein> hi there, has something changed in oneiric regarding --no-copy-dt-needed-entries (--no-add-needed)? 'gcc -Wall -Wl,--no-as-needed,--no-copy-dt-needed-entries test.c -o test -lslang' works (with test.c being http://paste.ubuntu.com/631913/). shouldn't that give an undefined reference error?
<doko> infinity: ping
<Ampelbein> doko: maybe you can tell if something is changed in oneiric: 'gcc -Wall -Wl,--no-as-needed,--no-copy-dt-needed-entries test.c -o test -lslang' should IMHO give a undefined reference error, test.c is http://paste.ubuntu.com/631913/. Am I thinking wrongly?
<infinity> doko: 'sup?
<infinity> doko: You know better than the fire off contentless pings. ;)
<infinity> doko: s/than the/than to/
<pitti> broder: okay then
<broder> pitti: thanks
<ScottK> infinity: Apparently not.
<mannic> hi
<mannic> there is someone who can help me on building the last unity trunk in 11.04?
#ubuntu-devel 2011-06-25
<poptisse> This the development team - because I have a really annoying bug that I have found which is not present on 10.10
<poptisse> only on Natty
<Ampelbein> poptisse: what is the bug number?
<poptisse> 600178
<poptisse> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/600178
<ubottu> Ubuntu bug 600178 in nvidia-graphics-drivers (Ubuntu) "Screen tearing when dragging window, in videos and other large screen redraws (on nVidia GPU)" [Undecided,Confirmed]
<poptisse> It is extremely irritating - as some of the fixes I just don't understand as I am brand new to Ubuntu.
<poptisse> It just appears to be an on-going issue that needs a fix
<poptisse> Ampelbein: You part of the development team?
<Ampelbein> poptisse: not of the core development team, no. but that issue seems to be with the closed source nvidia drivers anyway so the development team will most likely not be able to do anything about it.
<poptisse> Workarounds are mention on the bug - just one of the workarounds is confusing me lol
<poptisse> If you could help me understand it that, would be perfect
<Ampelbein> poptisse: user support is better placed in #ubuntu
<poptisse> I have tried ubuntu and no one understands what i am asking so cant help
<poptisse> Enable Workarounds -> Force full screen redrews (buffer swap) on repaint - Its just this
<poptisse> and
<poptisse> Disable Workarounds -> Don't wait for video sync
<poptisse> Does that mean I tick force full screen and untick don't want for video sync
<poptisse> Because in compizconfig don't wait for video sync is alreayd unticked..
<Ampelbein> poptisse: i don't know. have you tried it?
<poptisse> Yes/No because
<poptisse> In compizconfig there is an option to disable workarounds
<poptisse> so am not sure if i disable workarounds and than tick the don't wait for video sync
<poptisse> :l
<poptisse> I am just going to downgrade to 10.10
<bdrung> tumbleweed: around?
<wibblymat> Does anyone have a moment to point a packaging newbie in the right direction?
<bdrung> wibblymat: shoot
<wibblymat> I have downloaded a package using bzr and copied in the latest upstream source
<wibblymat> But when I try yo bzr build, I get 'Looking for a way to retrieve the upstream tarball' and some errors
<wibblymat> Why is it trying to download the source?
<wibblymat> Hmm, tried to keep it short, hopefully that is still intelligible :)
<bdrung> the file is in the wrong directory or named wrongly
<wibblymat> Which file?
<bdrung> the upstream source tarball
<bdrung> it should be ../package_version.orig.tar.gz (or .bz2)
<wibblymat> But... why does it need the upstream tarball at all?
<Laney> so that it can tell which parts are your modifications to upstream's source
<bdrung> it's needed for the source package build (if you build only the binary .deb package, it's not needed)
<wibblymat> Ok, I can see that I have got the wrong end of the stick somewhere :) I downloaded the upstream source and then copied the files from in the tarball over the top of the source in the package. Was that wrong?
<Laney> did you add a new changelog entry with the new version number?
<wibblymat> Yep
<Laney> should be fine if you have the file in .. then, as bdrung said
<wibblymat> I'm still a bit confused about why the build requires the original source tarball
<Ampelbein> wibblymat: did you use 'bzr merge-upstream' to include the changes?
<wibblymat> No
<wibblymat> Should I have done?
<Ampelbein> wibblymat: that's the recommended way when using bzr
<Ampelbein> wibblymat: see http://people.canonical.com/~dholbach/packaging-guide/html/udd-merging.html#merging-a-new-upstream-version
<wibblymat> Ah, thanks!
<Laney> a source package usually consists of some upstream code (orig.tar.gz/bz2) and the Debian modifications (diff.gz/debian.tar.gz), as well as a control file (dsc)
<wibblymat> Ah, ok. Was thinking of it as just a way to get the binary deb so couldn't understand why it needed the tarball when I had already included the code.  I'll revert and start again :)
<frafu> Hi, I need some advice about what version of a dependency to use in debian/control because of a bug in the dependency.
<frafu> In fact, the package named Onboard needs python-distutils-extra >= 2.10. But distutils-extra 2.26 has a bug that breaks the building of Onboard. The bug is fixed in distutils-extra 2.28. Thus, I am wondering if I should use 2.10 or 2.28 in debian/control. Could anybody please give me any advice? Thanks in advance.
<bdrung> frafu: use 2.10
<bdrung> frafu: bumping the version if only one version has a bug
<bdrung> it would make backporting harder
<frafu> bdrung: Thanks for the answer and the explanation. I will leave it to 2.10.
<mirak_> hi
<mirak_> is there a way to run the alternate installer from within an ubuntu install ?
<maxb> any of the various virtual machine systems
<maxb> but as a plain chroot builder, no
<vish> anyone have an idea where the bug could be ? Bug #792085  the bug has three tasks and no debugging..
<ubottu> Launchpad bug 792085 in usb-creator (Ubuntu) "Automatic remount of safely removed drive" [Undecided,Confirmed] https://launchpad.net/bugs/792085
<vish> .. and I'm able to reproduce it too on two separate WD drives
<bdrung> broder: bug #801945
<ubottu> Launchpad bug 801945 in ubuntu-dev-tools (Ubuntu) "[backportpackage] Fails to backport local .dsc file" [Undecided,New] https://launchpad.net/bugs/801945
<broder> bdrung: in find_package, just change SourcePackage to UbuntuSourcePackage
<bdrung> broder: that doesn't seem to be the right solution
<broder> the code used to use UbuntuSourcePackage. i changed it because i didn't see any reason i couldn't but forgot to test
<bdrung> bug #801945 look more like a bug in tumbleweed's archive.py
<ubottu> Launchpad bug 801945 in ubuntu-dev-tools (Ubuntu) "[backportpackage] Fails to backport local .dsc file" [Medium,New] https://launchpad.net/bugs/801945
<broder> bdrung: maybe, or maybe we just shouldn't be using SourcePackage
<broder> (and only using the subclasses)
<bdrung> tumbleweed: your opinion to ^?
<sveinse> I'm trying to make a debian package, and the files within this package can be installed without compilation. dh_make seems to be centric around building a source package, then a binary package. What is the easiest way to create a binary package without building. (I'm a n00b on this)
#ubuntu-devel 2011-06-26
<cafezim> hi
<cafezim> I am new
<cafezim> not in programming :)
<cafezim> Someone here in this room?
<axp2> Hi cafezim
<cafezim> Hi
<cafezim> axp2
<axp2> do you have a question?
<cafezim> yes, I would like to develop software
<cafezim> I am good at Java
<maco> cafezim: did you see what i said  in #ubuntu about how to find java packages in ubuntu?
<cafezim> hi maco
<axp2> cafezim: here's a good place to start https://help.ubuntu.com/community/Programming
<axp2> also, the way I got started was by joining papercuts-ninja
<axp2> https://launchpad.net/~papercuts-ninja
<cafezim> Who programs for ubuntu here?
<cafezim> Not talking
<cafezim> Programming
<cafezim> ?
<axp2> what do you mean?
<cafezim> I mean who in this room actually develops software for the Ubuntu communnity
<cafezim> I am asking
<axp2> probably most of the people in here
<cafezim> do you?
<axp2> I am Community (i.e. not Canonical staff), but I write code for Ubuntu Software Centre
<cafezim> Ok
<cafezim> you gave me this link here
<axp2> yes
<cafezim> What are you coding?
<axp2> do you mean which language? at the moment, python
<cafezim> Ok, I can python, but i am good at java
<cafezim> can't*
<cafezim> Do you know about any relevant Java project?
<axp2> well if you know java then you'll probably find python very easy but if you are looking for projects written in java to contribute to you can do that
<cafezim> ok man, I will learn python
<cafezim> syntax :)
<cafezim> so man, are you always in this channel?
<axp2> you don't have to learn python, but you will probably find there are far more projects to contribute to in Ubuntu if you can
<axp2> I'm in here fairly often
<cafezim> Ok
<cafezim> what about c++?
<cafezim> do you know it?
<axp2> what about it?
<axp2> i learned it a long time ago but have not used it for a while
<axp2> i can read it but don't currently attempt to use it
<cafezim> Because i am interested in OS
<cafezim> programming
<axp2> do you know C?
<cafezim> not much
<axp2> I think alot of the OS is written in C
<axp2> but I'd recommend you start with the two links I gave you
<axp2> the first one will give you an idea of the structure of things and how it all fits together
<axp2> the second one is a good place to get started with small bugs that are (supposed to be) easily fixed
<cafezim> https://launchpad.net/~papercuts-ninja
<cafezim> this one?
<axp2> yep. i started out with papercuts and after i'd fixed some bugs for software centre i just started writing code for it directly
<cafezim> fixing bugs is helpful
<axp2> sorry I have to go now, good luck. if you want to start learning some python, diveintopython.org is a good starting point
<cafezim> thanks man, peace
<axp2> i came from java too and i love python now
<axp2> bye
<cafezim> ok
<cafezim> Tem brasileiro aqui?
<cafezim> Ou so gringo doido
<cafezim> hi folks how can I help
<cafezim> ?
<cafezim> I am good at java
<mirak_> hi
<cafezim> hi everyone
<cafezim> I have just joined https://launchpad.net/~papercuts-ninja
<cafezim> for fixing bugs
<cafezim> enter if you have programming skills
<ScottK> slangasek: https://launchpadlibrarian.net/74126243/buildlog_ubuntu-oneiric-i386.pdns_2.9.22-9build1_FAILEDTOBUILD.txt.gz looks like a multi-arch related build failure to me.
<ohsix> hm why are the changelogs in aptitude still broken for security and proposed packages
<cjwatson> sveinse: all binary packages come from source packages.  to do what you're asking, simply have the source package not do anything interesting at the build step, and just have it copy the binaries into the output tree
<cjwatson> source package doesn't necessarily imply distinct source code
<cjwatson> (although it's usual, hence the name)
<notdurandal> anyone awake?
<MeIsBrains> hey all
<MeIsBrains> braaaand new here
<MeIsBrains> anyone here?
<cjwatson> lamont: https://launchpad.net/ubuntu/+source/linux/3.0-2.3/+build/2590256 looks stalled to me; hasn't shifted since I checked earlier this morning
<cjwatson> and has taken over 14 hours longer than the previous build https://launchpad.net/ubuntu/+source/linux/3.0-1.2/+build/2571636 so ofar
<cjwatson> *far
<slangasek> ScottK: confirmed; bypassing autoconf, grr
<ScottK> slangasek: Have fun.
#ubuntu-devel 2012-06-18
<ScottK> lifeless: Will do.
<ScottK> lifeless: https://answers.launchpad.net/launchpad/+question/200735
<lifeless> thanks
<SpamapS> how long after a package is accepted in Debian unstable must I wait before running syncpackage?
<infinity> "A while".
<infinity> I don't recall how often the syncy stuff runs.  Plus, it obviously can't run until after dinstall.
 * SpamapS resolves to just wait till morning
<lifeless> 'published'
<larsduesing> good morning
<pitti> Good morning
<pitti> ev: the "upgrade after process start" is also fixed in -proposed, BTW; currently waiting for verification
<pitti> slangasek: RT 52633> ok, thanks; I'll kill another arch or so then
<dholbach> good morning
<pitti> hey dholbach, wie gehts?
<dholbach> hey pitti
<dholbach> sehr gut - wie gehts dir?
<pitti> dholbach: prima, danke!
<pitti> a bit tired, we went to bed rather late (we watched the game in a Biergarten :) )
<dholbach> ah nice :)
<dholbach> I'm a bit tired as well - I only had about an hour's sleep on SatâSun
<dholbach> but life's good :)
<cjwatson> larsduesing: soyuz> I don't think you'd learn desperately much by doing that, compared to the effort involved; I do a good deal of archive infrastructure work and even I've never felt the need for a local soyuz instance (as opposed to running bits of soyuz via the LP test suite when making changes)
<Laney> When I first wanted to do some LP development I tried to get Soyuz working too, but it's pretty nontrivial so now I also just tend to rely on the testsuite.
<Riddell> pitti: are you the language pack expert?
<pitti> Riddell: I guess I am
<Riddell> pitti: where's the magic script to make them?  I want to change it so the kde ones are simple meta packages
<pitti> Riddell: it's in https://code.launchpad.net/~ubuntu-langpack/langpack-o-matic/main
<gema> cyphermox: can you guys have a look at bug 983583 ?
<ubottu> Launchpad bug 983583 in network-manager (Ubuntu) "nm-applet does not show VPN submenu on login" [Undecided,Confirmed] https://launchpad.net/bugs/983583
<gema> cyphermox: the QA team cannot really use network manager to connect to our VPN because it is a pain atm
<toabctl> bilal, about bug #1012505: are the dbus patches sent upstream? i can not find any mail on the dbus list about upstart integration for dbus.
<ubottu> Launchpad bug 1012505 in DBus Test Runner "tests hang in pbuilder environment" [Undecided,Incomplete] https://launchpad.net/bugs/1012505
<brendand> does anyone know an option for pexpect in python3?
<brendand> is there any conversion happening or an alternative?
<xnox> brendand: "Pexpect-U is unicode-aware, and compatible with Python 3 (using distribute to run 2to3 during setup). It requires Python 2.6 or above."
<xnox> http://pypi.python.org/pypi/pexpect-u
<brendand> xnox, is there an ubuntu package?
<xnox> brendand: no, but since it's pure python you could use pypi-install
<xnox> which should make a package for you
<toabctl> pitti, are there any reasons why ubuntu does not send the dbus patches upstream? there is already some code for systemd upstream, but nothing for dbus. i ask because i want to use dbus-test_runner on debian but the package needs a patched dbus version.
<toabctl> nothing for upstart, i mean.
<pitti> toabctl: the only patches I'm aware of that are not sent upstream are the ones for upstart activation
<toabctl> pitti, yes. that's the question why theses patches are not send upstream.
<pitti> I actually dropped them from my 1.5 merge in https://launchpad.net/~pitti/+archive/ppa/+packages
<pitti> toabctl: I don't know; these are rather old, we don't use them, and I didn't feel like porting them
<pitti> dbus 1.5 causes some trouble with the indicators, so it wasn't uploaded yet
<toabctl> pitti, so ubuntu should also work with a upstream dbus version without theses patches?
<toabctl> pitti, then maybe comment https://bugs.launchpad.net/dbus-test-runner/+bug/1012505/comments/2 is wrong?
<pitti> yes, absolutely
<ubottu> Launchpad bug 1012505 in DBus Test Runner "tests hang in pbuilder environment" [Undecided,Incomplete]
<pitti> toabctl: I followed up there
<pitti> so we are down to two simple config change patches
<toabctl> pitti, ok. thanks
<larsduesing> cjwatson: Ok - thanks :)
<seb128> SpamapS, slangasek, bdmurray, RAOF: the SRU queue is still around 25 items, some being there for 3 weeks, is there anything we can do to help that moving?
<RAOF> seb128: When I last went through the queue the bottom items were all waiting on information/comment/action from the uploader; I'll do a sweep tomorrow and I'll reject those things waiting more than a two weeks for uploader action.
<RAOF> If the uploader provides what we're after we can always fish the package out of the rejected queue.
<seb128> RAOF, ok, thanks
<seb128> RAOF, lo-menubar has a rational on why we need the new version, it's basically "it would be as much diff to backport the fix only" and the package is just broken atm and in universe so the update can only be a win
<Laney> xnox: howdy, did you hear anything about emacs24?
<xnox> Laney: I didn't get around about enquiring =(
 * xnox it's at the bottom of my todo list
<xnox> Laney: I'm using ppa:cassou/emacs and am generally happy about it. Apart from bamf/unity dash integration which I fixed up locally.
<xnox> but that's emacs-snapshot and it will move on quickly =(
<vibhav> How Do I configure dch and requestsync to use emacs?
<jelmer> vibhav: they should just use the EDITOR or VISUAL environment variables I think
<vibhav> lemme see
<vibhav> mdeslaur: ping
<mdeslaur> vibhav: yes?
<vibhav> mdeslaur: Firstly, thanks for sponsoring my uploads
<mdeslaur> vibhav: yw
<vibhav> Also, I am applying for universe-contributors, could you write an endorsement at https://wiki.ubuntu.com/VibhavPant/UniverseContributorApplication ?
<mdeslaur> vibhav: remind me which uploads I sponsored for you?
<mdeslaur> vibhav: ah, I see them on your page, never mind
<xnox> vibhav: if you remove newlines between the table lines, it will render as one table, instead of a table per line.
<vibhav> xnox: thanks!
<vibhav> mdeslaur: done?
<mdeslaur> vibhav: I don't have time to do that now...I'll get to it eventually, when are you applying?
<vibhav> 2nd July
<mdeslaur> vibhav: I'm not sure I've sponsored enough to actually write an endorsement in any case
<mdeslaur> vibhav: one was a trivial merge, and the other was a SRU that I had to correct a number of things in the debdiff...not exactly enough material for me to form an opinion on your work
<xnox> jodh: I'm plowing through eventbased initramfs specs/etherpads/braindups since like forever. I have currently fleshed out https://wiki.ubuntu.com/Initramfs with slightly more uptodate info (stealing from eventbased spec previously written ;-) )
<xnox> please check it out =)
<jodh> xnox: will do, thanks.
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
 * vibhav hugs pitti
<pitti> cyphermox: handing the network-manager task in bug 1013171 to you, as I cannot push to the Vcs-Bzr: (that ought to be fixed, perhaps?)
<ubottu> Launchpad bug 1013171 in network-manager (Ubuntu Quantal) "Many package hooks not ported to python3" [Undecided,In progress] https://launchpad.net/bugs/1013171
<pitti> cyphermox: it's got a patch
<cyphermox> pitti: ok, thanks!
<vibhav> pitti: are you busy?
<pitti> I'm always busy :)
<vibhav> pitti: If you get some free time, could  you have a look at https://bugs.launchpad.net/ubuntu/+source/fische/+bug/1014637 ?
<ubottu> Launchpad bug 1014637 in fische (Ubuntu) "Please merge fische 3.2.2-3 from Debian Unstable" [Undecided,In progress]
<pitti> vibhav: yes, I can do that; I'm on patch pilot shift, after all
<pitti> I just finished sponsoring #1013171, so going to the next one now
<pitti> vibhav: has it actually been confirmed that this patch is still needed?
<pitti> vibhav: if so, it would be good to send to upstream/Debian
<vibhav> yeah
<pitti> otherwise we'll carry such stupid patches forever
 * vibhav nods
<pitti> vibhav: so, how about I sync fische first, and if it fails on armel still, we apply this?
<vibhav> sure!
<vibhav> pitti: You are going to do that in a PPA, right?
<pitti> no, I synced it into quantal
<pitti> we don't have publicly accessible arm PPAs
<vibhav> ah fine
<pitti> vibhav: followed up to bug 1014317; do you know how to submit a Debian bug?
<ubottu> Launchpad bug 1014317 in gjiten (Ubuntu) "Please merge gjiten 2.6-2.2 (main) from Debian Unstable" [Wishlist,New] https://launchpad.net/bugs/1014317
<vibhav> yup
<vibhav> lemme do that
<pitti> vibhav: fische built fine
<pitti> vibhav: your qof merge says "for a first build", but quof is already built on armhf; so this looks obsolete as well?
<pitti> same story, /me syncs first
<vibhav> pitti: SO Ill set the fische merge request to invalid?
<pitti> I already closed it
<arges> doko__, hello. i was told you would be the person to ask about armel compilation problems?
<vibhav> Any idea why debuild -S -sa fails in rbot with http://paste.ubuntu.com/1047313/ ?
<pitti> vibhav: looks like a missing build dep on some ruby tools
<vibhav> Well, I did build-dep rbot
<vibhav> Looks like thats not enough
<geser> you need gem2deb
<geser> (and it should be listed in Build-Depends)
<vibhav> I was going to say that
 * vibhav does that
<vibhav> then , as per me logic, rbot should FTBFS in debian sid too
<jamespage> infinity, OK if I steal the hsqldb merge from you? it has a Java 7 fix and I need to update it for the tomcat7 transition as well....
<vibhav> jamespage: You busy?
<xnox> jamespage: i'd think infinity is still asleep =)))) am I sure he wouldn't mind ;-)
 * pitti notes that "are you busy" is a trick question which you should avoid; just ask your actual question
<jamespage> vibhav, yes :-)
<jamespage> vibhav, hey - wassup - missed your ping yesterday
<vibhav> jamespage: Well, If you get some free time, could you add an endorsement on https://wiki.ubuntu.com/VibhavPant/UniverseContributorApplication ?
<jamespage> vibhav, on my TODO list already
<vibhav> thanks!
<vibhav> pitti: thanks for sponsoring
<jamespage> xnox, I'm sure he won't - but its good etiquette to ask first!
<xnox> ;-)
<pitti> vibhav: btw, merges need a justification why the current delta is still applicable; it would be easier if you could do that research before spending your (and also your sponsor's) time on merges which can just be syncs
<arges> cyphermox, hey have a question about nm. pad.lv/872824 is a bug about strongswan vpn not being compatible with NM. I see some patches on this bug, and am wondering what approach would make sense in getting this functionality working. thanks
<vibhav> pitti: sure, thanks for the info though
<cyphermox> arges: it would take extensive porting of the strongswan plugin to the new API; IIRC
<cyphermox> I'll look at the patches again
<arges> cyphermox, ok thanks. yea i'd like to know what the approach is
<doko> arges, anything more specific?
<seb128> pitti, bug #984944, I can't verify it still
<ubottu> Launchpad bug 984944 in apport (Ubuntu Precise) "Reject crashes that happen right after upgrade" [Medium,Fix committed] https://launchpad.net/bugs/984944
<seb128> pitti, doing the package update steps I get a
<seb128>   File "/usr/lib/python2.7/dist-packages/apport/report.py", line 439, in add_proc_info
<seb128>     assert os.path.exists(self['ExecutablePath'])
<seb128> in the log
<apw> pitti, are we expecting a cups to sync through or should be we be patching it in ubuntu ?
<arges> doko, yes. looking at the build for witty: https://launchpad.net/ubuntu/+source/witty/3.2.1-2/+build/3572681
<arges> seems to build fine on other archs + armhf, didn't know if this was a known issue, or I should follow through with a bug
<apw> infinity, a few for review in http://people.canonical.com/~apw/plusone/
<pitti> xnox: you can certainly continue to use UDD for merges if it works for you; I was just pointing out that in general debdiffs are faster on the sponsor side, but I'll deal with UDD :)
<Chipzz> xnox: concerning https://wiki.ubuntu.com/Initramfs : "All these files are collected in a temporary directory and then they are cpio archived and then gunziped." -> I think you mean gzipped instead of gunzipped there
<pitti> seb128: hmm, I only tested it in quantal; I'll need to have a closer look at this then, in a precise environment
<pitti> apw: we generally keep cups in sync; there's another (two) RC bugs I'd like to fix in Debian before an upload, if only I'd ever get to it
<seb128> pitti, ok, no hurry but I can't confirm the fix, feel free to grab me if you need debug infos
<xnox> pitti: ok. to be honest doing $ bzr diff -rtag:1.0-1 > merge.debdiff && open lp bug && attach is easy enough. And is comparable to $ bzr push lp:~/ubuntu/quantal/package/merge && bzr lp-propose-merge
<xnox> pitti: one spams branches/merge proposals; the other spams bug reports
<Chipzz> xnox: also you have some typo's: "calls run-init to run the real init in yoru reall roofs kept in /root."
<xnox> pitti: I'm up for coredev this evening, so maybe soon I will be on the sponsorship side fighting with UDD ;-)
<pitti> xnox: if it works for you, great; I just find that UDD forces me to spend a rather inordinate amount of time fiddling with patches and rejectinos
<xnox> pitti: =((( sad times
<xnox> Chipzz: I didn't write any of it =)))) I refactored it out of out-of-date spec. And this type of information was more suitable on the Initramfs page
<xnox> Chipzz: fixes welcome =)))))
<Chipzz> xnox: ah kk, nm then :)
<xnox> Chipzz: nm = nanometer?
 * xnox is confused
<Chipzz> xnox: don't think I have an account to edit that
<Chipzz> xnox: nm = nevermind
<xnox> Chipzz: if you don't have an account, I will pick up your questions above and factor them in. It only needs a launchpad account to login?!
<Chipzz> ah k I have a lp account
<Chipzz> wasn't sure what was needed for it
<Chipzz> xnox: hrrrm, but it says "Immutable Page"
<Chipzz> wouldn't that restrict things mortals like me can do?
<cjwatson> That sounds like you're not actually logged into the wiki
 * xnox is a mere mortal with a lp account
<Chipzz> cjwatson: prolly. trying to remember credentials :)
<Chipzz> found it
<kelemengabor> pitti: ping, got a few minutes for language pack updating?
<kelemengabor> http://irclogs.ubuntu.com/2012/06/15/%23ubuntu-devel.html#t14:27
<pitti> kelemengabor: I have a meeting in 1 minute, sorry
<kelemengabor> okay, maybe later :)
<pitti> kelemengabor: you need copying PPA -> -proposed?
<pitti> kelemengabor: I can do that, yes
<smoser> cjwatson, could you comment on bug 1014695? i think i talked to you at UDS about this request, and i think you at least implied you'd be open to it.
<ubottu> Launchpad bug 1014695 in grub2 (Ubuntu) "need some mechanism to support /boot/grub/menu.lst and pv-grub" [Undecided,New] https://launchpad.net/bugs/1014695
<kelemengabor> pitti:  yes, thanks in advance
<Chipzz> xnox: fixed (including several other typos)
<xnox> Chipzz: thank you a lot!
<Chipzz> np, 5min work :)
 * Chipzz wonders when spell-checking, should technical terms be added to the dictionary, or should it be left alone?
<Chipzz> I simply left it alone this time
<cjwatson> smoser: I would be open to it as long as it's in a separate source package I don't need to have anything to do with :-)
<cjwatson> smoser: With it in a separate source package, there should be no need to gate on me for anything
<smoser> hmm... i thought you had implied it'd be ok to be in grub source package.
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672104
<ubottu> Debian bug 672104 in wnpp "ITP: pv-grub-menu.lst -- <missing description>" [Wishlist,Open]
<pitti> kelemengabor: seems there isn't any newer version in the PPA, it still has 0508
<cjwatson> smoser: Well, it kind of would, but it's not really connected to it.  I think it would be better to have it separate.
<cjwatson> And I don't see why it can't be?
<smoser> cjwatson, right. and i was reading the debian bug too.
<smoser> cjwatson, the other thing you were going to do for me was just create pv-grub2
<smoser> :)
<kelemengabor> pitti: argh indeed, the crontab seems to be disabled :(
<kelemengabor> precise-updates at 10:00 on Tue: disabled
<cjwatson> *I* sure wasn't
<infinity> jamespage: I have no attachment to hsqldb, all yours.
<cjwatson> I don't even slightly have time
<cjwatson> Upstream has done some work on this, whose status I'm not up to date with
<pitti> kelemengabor: reenabled
<kelemengabor> thanks!
<pitti> kelemengabor: so I guess we'll wait a few days for the PPA to update
<cjwatson> So if that arrives for free with 2.00, great - but otherwise ...
<smoser> cjwatson, i'm just kidding. i did think at one time i thought i had you near thinking "hm... that does sound kind of neat, maybe i'll just stay up all night and do that" (regarding grub-pc)
<smoser> er... regarding pv-grub2
<cjwatson> Yeah, but infinite work
<kelemengabor> pitti: right, sorry for not checking that before
<pitti> kelemengabor: no problem
<cjwatson> Anyway, if it sucks too badly to have it outside grub, feel free to merge the grub-legacy-ec2 stuff into grub (not grub2) in as noninvasive a way as you can manage
<cjwatson> I'd review a patch, but am unlikely to be able to help otherwise, I'm afraid
<cjwatson> It *really* doesn't belong in grub2
<smoser> cjwatson, i think i
<cjwatson> But maybe it could be conditionals in the code in grub (legacy
<cjwatson> )
<smoser> i think it'd be better outside of grub than inside it.
<smoser> so if i'm going to split it out of cloud-init, i think i'd go to new package rather than grub
<smoser> but thanks.
<jamespage> infinity, marvellous
 * jamespage goes to sync it
<highvoltage> stgraber: well, if you have some time for this at any point :) https://code.launchpad.net/~jonathan/ubuntu-seeds/edubuntu.quantal/+merge/110841
<hallyn> highvoltage: hey, not sure if you're on the lxc-devel m-l, but i'd be interested if you had any opinions on http://sourceforge.net/mailarchive/forum.php?thread_name=20120615221638.GA6236%40sergelap&forum_name=lxc-devel
<highvoltage> hallyn: I'm only on lxc-users but stgraber mentioned something about lxc-devel last week and I've been meaning to subscribe
<hallyn> highvoltage: :)  i tried to convince people to merge the two lists, but they wouldn't go for it :)
<stgraber> highvoltage: looks good, merging. I'll refresh edubuntu-meta a bit later
<highvoltage> stgraber: thanks!
<barry> kenvandine: so i think the good news is that libpeas *already* supports py3.  e.g. PYTHON=python3 ./configure --enable-python passes all its tests.  i scanned the code and found only very minor issues (which i'll open upstream bugs on) but none of which afaict should affect py3.  i think the tricky part will be building 1.4.0 in ubuntu such that an app can either enable py2 or py3 plugins (but obviously not both)
<kenvandine> cool
<xnox> barry: since libpeas is compile time, make two python2/3 libpeas dev packages and make them conflict each other. None of the reverse-build-dependencies of libpeas will be able to enable both of them.... unless there is a fallacy in my argument.
<xnox> barry: provides, conflicts dance thingy as done for e.g. virtual mta package
<barry> xnox: my thinking too
<xnox> =)
<barry> lunch first :)
<infinity> jamespage: Hrm, two things about that sync.  One, you dropped the default-jre-headless dep (maybe that's okay?), and two, the arch line seems to confuse lp-buildd's sbuild.  Not sure if it should or not, that may need investigating and fixing on the buildds.
<jamespage> infinity, yeah - I'm looking at that ATM
<jamespage> the drop on the dependency is OK
<jamespage> but the architecture check in sbuild is doing something cranky
<infinity> jamespage: You could "fix" it by just letting that package build on "any" again, but perhaps the current arch list is perfectly legal and we're just not handling it correctly, due to the fact that we've never run into a package that was "all something-not-i386" before. :P
<jamespage> infinity, OR I could just drop the bits that are being retained for kfreebsd-*
<jamespage> or we could fix sbuild
<jamespage> I think its a valid combination
<infinity> Dropping those bits would be a quick and simple hack, yeah.
<jamespage> that would get me out of jail now
<infinity> Filing a bug on launchpad-buildd and assigning it to me for the issue would be nice.
<jamespage> infinity, sure - I just tested something locally with sbuild which I think resolves it
<infinity> But dropping the freebsd-only package seems like a quick fix.  I don't have the time to fix lp-buildd right now.
<jamespage> infinity, ack
 * jamespage goes to file a bug
<slangasek> SpamapS, pitti: where do we stand wrt nova getting an MRE?  It looks like the upload to oneiric-proposed has still not progressed, and there's another package that's been uploaded to precise-proposed queue
<AnAnt> Hello, who should be subscribed to LP #1014705, ubuntu-sponsors or someone else ?
<ubottu> Launchpad bug 1014705 in skype (Ubuntu) "Candidate revision skype 4.0.0.7-0precise1" [Undecided,Confirmed] https://launchpad.net/bugs/1014705
<Daviey> slangasek: The original precise one was superseeded by security upload
<xnox> barry: you sound like movie the Mask: "But first..."
<Daviey> slangasek: which just dropped the proposed package dead in the water
<slangasek> seb128: the lo-menubar SRU is not at all clear; comment #11 from pitti on bug #754562 claims that this bug is *invalid* for lo-menubar in precise, and I don't see which bit here is supposed to supersede this.
<ubottu> Launchpad bug 754562 in LibreOffice Menubar Extension "soffice.bin crashed with SIGSEGV in g_hash_table_lookup() (Libreoffice with lo-menubar crash from page preview)" [Undecided,In progress] https://launchpad.net/bugs/754562
<slangasek> Daviey: which "original" precise one are you referring to?  I don't see that there's ever been a nova SRU accepted for precise
<slangasek> Daviey: and the one in the queue is stalled not because of a security update but because it doesn't appear to fit the SRU policy
<Daviey> slangasek: we were discussing this in #ubuntu-server about an hr ago.
<xnox> jamespage: what's the bug number?
<jamespage> xnox, just writing it now
<Daviey> slangasek: We are intentionally doing SRU's that don't normally fit the SRU policy
<xnox> jamespage: surely the lucid buildds have no clue what kfreebsd-* is what's so ever
<Daviey> slangasek: bdmurray has been trying to dig into it.
<Daviey> Context: https://lists.ubuntu.com/archives/technical-board/2011-December/001155.html
<bdmurray> Daviey: I went through and read more of the tech board emails
<slangasek> Daviey: it's because of bdmurray's digging that I'm pinging SpamapS and pitti for the MRE status
<bdmurray> Daviey: and it seems like the tech board wants to see a history of successful micro releases being SRU'ed but that is explictily stated anywhere
<jamespage> xnox, bug 1014722
<ubottu> Launchpad bug 1014722 in launchpad-buildd "Unable to build hsqldb 1.8.0.10-12 directly from Debian" [Undecided,New] https://launchpad.net/bugs/1014722
<slangasek> Daviey: and MREs are part of the SRU policy - I mean that this SRU neither has an MRE nor is verifiable using the more traditional route
<Daviey> bdmurray: this is the test candidate to 'see how it goes' to be granted MRE, no?
<slangasek> the test candidate was one uploaded to *oneiric*
<slangasek> which has stalled 6 months, and now there's another upload to precise
<Daviey> slangasek: yes, the test candidate from oneiric is the one that failed due to security superseeding
<slangasek> ok
<Daviey> which is why we are super keen to get this progressing to minimise the chance of it happening again
<xnox> jamespage: commented ;-)
<slangasek> Daviey: getting it to progress is going to require having some plan for how the SRU is going to be verified, which is what I'm asking for
<slangasek> accepting it into -proposed only to have it stall there because no one will verify it is a waste of everyone's time
<Daviey> slangasek: Right.. So.. We are doing unit testing at package build time.. functional testing in the CI lab, and extended validation by putting it into production in a real cloud (canonistack)
<Daviey> (canonistack will test the -proposed package, when it lands there)
<bdmurray> well it also seems like pitti is for an alternate verification process, one where each bug isn't necessarily verification-done
<slangasek> and this testing would be done for any nova SRU, or just the ones for precise because canonistack happens to be running precise?
<slangasek> and what should happen with the oneiric nova SRU that's still sitting there?
<bdmurray> Daviey: https://lists.ubuntu.com/archives/technical-board/2011-December/001153.html - here chuck says the package won't FTBFS if the testsuite failed
<bdmurray> Daviey: has that changed?
<zul> bdmurray: yeah its been like that for a while now
<Daviey> bdmurray: was that a typo?  they DO ftbfs if unit tests fail, no?
<Daviey> zul: ^
<zul> they do
<Daviey> slangasek: I don't have a good answer for Oneiric.. We can do extended validation ourselves, but not in a proper cloud.
<bdmurray> Daviey: not a typo
<Daviey> slangasek: We are closely involved with upstream stable tress.. zul and myself are both reviewers.  The idea is to keep upstream ubuntu regression free (which is why we've invested in so much CI)
 * Daviey has to go now.. but will be back later.
<SpamapS> slangasek: AFAIK, nova has no MRE, and the decision was stalled on "lets try a pretend one" where we don't verify all bugs but show a lot of regression testing.
 * SpamapS responds and *then* reads and realizes this is still under discussion
<slangasek> Daviey: well, that doesn't sound like you're *committing* to do that validation though?  Either somebody should commit to following through on the oneiric SRU (including updating it for whatever security fixes make the current one invalid), or we should kick it out of -proposed instead of leaving it sitting there
<slangasek> Daviey: in any case, if the one currently in -proposed is non-promotable because it's missing security fixes, we should remove that one from -proposed... is that the current state?
<zul> slangasek: imho we should kick oneiric out from -proposed
 * xnox was under impression that heavy testing is done *before* uploading to -proposed, not after. as suggested above by Daviey "(canonistack will test the -proposed package, when it lands there)"
 * vibhav hugs xnox 
<vibhav> xnox: thanks for the comment!
<slangasek> xnox: we prefer that as much testing as possible happen with the real live package in -proposed, to avoid any mistakes with misbuilt binaries
<xnox> slangasek: ok I see your point. Simply other things, e.g. kernel, X-org edgers, KDE have beefy PPAs for pre testing before upload to -proposed.
<xnox> slangasek: yet one more unwritten "de-facto" policy
<slangasek> xnox: the kernel ppa is a special case, we *copy* those binaries from the ppa into the archive
<vibhav> Ampelbein: ping
<slangasek> xnox: in cases where we don't do a package copy, I do not consider ppa testing a substitute for SRU testing
<SpamapS> xnox: perhaps de-facto, but I think also pretty obvious as to why.
 * xnox noted, ok
<slangasek> zul, SpamapS: nova removed from oneiric-proposed
<slangasek> zul, SpamapS, Daviey: nova removed from oneiric-proposed
<zul> slangasek: cool
<vibhav> How can I debuild -S -sa msv without installing maven?
<vibhav> http://paste.ubuntu.com/1047590/
<tumbleweed> vibhav: -nc
<vibhav> tumbleweed: thanks!
<tumbleweed> but you can only do that when it is already clean
<vibhav> yeah, done that
<seb128> slangasek, I didn't read the full bug history to be honest so I'm not sure about the old comments, the bottom line is that the precise version segfault when you try to print preview with lo-menubar installed
<seb128> slangasek, which is happening to lot of users who read on the internet to install lo-menubar to get menus integrated, hud working, etc
<Daviey> xnox: We also have a pre-proposed PPA, where testing happens.
<xnox> ok
<Daviey> xnox: We also regress test as much as we currently can per-commit, upstream
<seb128> slangasek, bdmurray: if you have questions about the lo-menubar can you maybe grab directly kenvandine on IRC to sort them? that might work better than bug pingpong to figure what details you guys need
<jml> any idea when emacs24 might hit quantal?
<seb128> jml, when it's ready (tm) ;-)
<jml> heh
<xnox> jml: currently no. there are a lot of emacs users from ubuntu core devs. and we all want it =)
<xnox> this reminds me of Laney doing a ping on me this morning to ping emacs maintainer about it.......
<Laney> ping me to ping you to ping him
<seb128> jml, <xnox> Laney: I'm using ppa:cassou/emacs and am generally happy about it.
<mpt> pitti, hi. I have a work item for the installer, "add '3-D graphics' to the installer's third-party software text (ubiquity can detect whether nvidia card is in the system)". But ev just told me he thought the plan is to remove the Nvidia driver from that software bundle. Do you know which is right?
<seb128> jml, read earlier on this channel, in case that's of any use to you
<jml> seb128: ah yes, thanks.
 * barry also wants emacs 24.1 :)
<jml> I'll go back to waiting patiently then. I'm not in a rush to use a snapshot.
<xnox> mpt: pitti: ev: I think I saw bugs about not being able to install nvidia proprietary driver, while running in Live-CD / during installation. It succeeds only after first boot.
<ev> xnox: right, we never installed it in the live cd session
<ev> on in the target system
<ev> only*
<xnox> mpt: ^^ i think you have your answer =)
<mpt> xnox, no, the paragraph isn't about the live session
<mpt> it's about installing Flash, MP3 codecs, etc on the installed system
<xnox> mpt: which will not ever include nvidia drivers
<mpt> xnox, how do you know?
<xnox> mpt: nvidia drivers where previously comming from the jockey. In the future they will be offered/installed by ubuntu-drivers-common and/or software-centre based on modlines
<mpt> xnox, I don't know what a modline is, so I don't know what that has to do with the installer.
 * xnox modlines ?! well the hardware graphics card identifier line in packages,
<mpt> xnox, by "the installer" I mean Ubiquity
<xnox> mpt: Ubiquity currently does not install nvidia. There are no plans to make it do so.
<xnox> mpt: nvidia graphics drivers require adding kernel modules and regenerating initramfs, which currently is not possible to do onto the target hard-drive.
<mpt> So, I wonder why someone put it as a work item in the session
<mpt> [albertomilone] ensure that installing nvidia/fglrx driver package also updates the alternatives symlinks and updates initramfs for the changed blacklists: DONE
<mpt> I guess that means Alberto has done the impossible? :-)
<xnox> mpt: http://paste.ubuntu.com/1047658/
<xnox> mpt: 'installing' != 'ubiquity', installing as in on the machine, not during the installation.
<mpt> I see
<mpt> Well, that's annoying.
<xnox> mpt: the paste lists depends & the packages, which I think are dynamically downloaded and installed from the internetz
<xnox> mpt: yes it is annoying. That even if you choose to install updates & restricted stuff during the installation, you still will have to install stuff on the first reboot.
<xnox> mpt: but there is little we can currently do about it. Maybe in two-three releases something will change and we will be able to fix that.
<mpt> Heh, true, but I meant annoying only for me. :-)
<xnox> Oh, I see =))) workitems =))))
<xnox> mpt: the text you did for ubiquity is fine. Another text maybe needed for the ubuntu-drivers-common, not sure.
<mpt> xnox, it's not fine if it says it might install graphics drivers when it never does.
 * xnox hides
<mpt> Sorry, didn't mean that to sound anvil-droppy. :-)
<xnox> mpt: this got me thinking about this a bit. there is a support to run a post-first-boot-script which we can tell to install the package.
<xnox> and if we detected which nvidia drivers to install
<xnox> we can make it install automatically without user intervention
<xnox> (and pre-download the package during the installation and stick it into (target)/var/cache/apt/archives)
<xnox> mpt: this will result in (1) install (2) reboot (3) notification - your system needs a restart to complete upgrades
<xnox> =/
<mpt> heh
<mpt> I guess pitti will tell us tomorrow
<mpt> thanks xnox
<slangasek> kenvandine: ping re: bug #754562
<ubottu> Launchpad bug 754562 in LibreOffice Menubar Extension "soffice.bin crashed with SIGSEGV in g_hash_table_lookup() (Libreoffice with lo-menubar crash from page preview)" [Undecided,In progress] https://launchpad.net/bugs/754562
<kenvandine> slangasek, pong
<barry> xnox, kenvandine: i don't think it's quite as easy to adjust the packaging to include py3 support in libpeas.  first, it doesn't package up a separate python loader, so you can't just add a python3-foo package.  you end up with /usr/lib/libpeas-1.0/loaders/libpythonloader.so.  so i guess you could just do a second build of just the py3 loader and name it libpython3loader.so and include it in the libpeas-1.0-0 package (w/corresponding
<barry> changes for the debug version).
<barry> xnox, kenvandine of course it's also cdbs, so ouch :/
<barry> xnox, kenvandine or maybe we should just do a binary package split of the python2 and python3 loaders
<kenvandine> barry, i think that makes sense
<barry> xnox, kenvandine since i don't use libpeas, i don't know what the right thing to do is.  suggestions welcome
<kenvandine> i've never used it before... so not much help there
<xnox> barry: i don't use libpeas, I use apps that use libpeas. Have you talked to upstream on GIMPNet as to what the best way to support both?
<slangasek> kenvandine: hi, can you fill out the bug description with the information required per https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ?  The bug history is very fuzzy, we need authoritative information about what is being fixed here and why.  The bug history shows pitti saying the code isn't even in lo-menubar past natty.
<kenvandine> slangasek, i can try... it is a bit fuzzy to me too
<kenvandine> it has been merged into upstream LO
<kenvandine> but never enabled
<kenvandine> the changes in this version is actually from upstream LO
<barry> xnox: i haven't.  upstream may not be the most appropriate place though since as far as upstream's concerned, they support py3.  i think it's more a packaging issue, so i think i'll contact the debian maintainer (pkg-gnome-maintainers) and cc debian-python
<xnox> barry: two thumbs up
<kenvandine> slangasek, as best we can tell the only real fix included in this version is for this bug... the rest was refactoring for upstream
<kenvandine> s/upstream/LO
<kenvandine> slangasek, however upstream for lo-menubar tried to backport just the fix for this bug and gave up... said it would be just as big of a change and more work than it was worth
<slangasek> kenvandine: ok.  when updating the bug, can you include that information, and also comment on why it's safe to take the refactoring changes instead of doing that backport?
<kenvandine> sure
<slangasek> ta
<slangasek> kenvandine: fwiw I've just done a naive test; I can't crash lowriter on amd64 with a page preview, when lo-menubar is installed
<slangasek> so the test case definitely needs to cover how to reproduce the original bug...
<kenvandine> slangasek, did you click the one on the toolbar?
<slangasek> kenvandine: no, but I have now and still nothing
<kenvandine> i think you have to do it first
<kenvandine> before clicking it in the menu
<kenvandine> seb128, right ^^
<slangasek> it was a fresh instance when I tested the toolbar
<kenvandine> that's what i just wrote in the test case :)
<kenvandine> humm
<kenvandine> slangasek, i just reproduced it by clicking on page preview first thing
<slangasek> on amd64?
<kenvandine> hung for a couple seconds and boom
<kenvandine> yes
<slangasek> how did you launch LO?
<kenvandine> move ~/.config/libreoffice out of the way
<kenvandine> well
<kenvandine> had you upgraded to the newer lo-menubar then downgraded?
<kenvandine> for some reason downgrading doesn't work... it stores something for the extension in your profile
<slangasek> oh hah, I can't reproduce it because I'm on quantal \o/
<kenvandine> ah!
<slangasek> ok, so ignore me ;P
<kenvandine> there is a problem with downgrading though... i think LO doesn't something evil there
<kenvandine> if you downgrade it'll continue to use the newer version
<kenvandine> ah... we only have one mterry again.. sounds less productive
<mterry> kenvandine, :)
<kenvandine> slangasek, bug description updated
<slangasek> kenvandine: cheers :)
<kenvandine> slangasek, thank you!  this is really our best hope of getting this bug fixed in 12.04 :/
<slangasek> understood
<slangasek> dobey: your latest upload of ubuntu-sso-client has a hard build-dep on python-support which needs to be dropped
<dobey> slangasek: doh, thanks.
<slangasek> dobey: looks like there's also a new build-dependency on python-qt4reactor, which is not in main currently... is there a MIR bug open for this?
<bdmurray> dobey: cany chance you could look at https://code.launchpad.net/~brian-murray/lptools/bug-dupe-props/+merge/108433
<ubottu> Launchpad bug 99019 in konq-kim (Ubuntu) "duplicate for #108433 [apport] package konq-kim failed to install/upgrade: " [Undecided,Invalid]
<dobey> slangasek: double-doh.
<dobey> bdmurray: as soon as i can. been swamped with releases and security fix drama
<bdmurray> dobey: it'd be nice if more people than you could or were doing reviews for lptools
 * xnox today I learned $ man grep-merges
<dobey> bdmurray: like lifeless, jelmfer, or poolie? :)
<bdmurray> dobey: or like ubuntu-core-dev
<dobey> slangasek: there isn't a MIR; and I suppose there won't be one. So I guess I'll have to not run the tests during build :(
<slangasek> dobey: why wouldn't there be an MIR?
<slangasek> dobey: I mean, I think as the uploader of the package trying to pull it in, it's up to you to file the MIR bug... which I think you should do before deciding to skip running tests at build time
<dobey> slangasek: qt4reactor is not well supported/maintained, and we don't want to take over for upstream on it
<slangasek> ah
<xnox> dobey: but you should at least use dh_python2 not python-support
<slangasek> he knows :)
<xnox> =)
 * xnox sorry, dobey.
<dobey> xnox: yes we already use dh_python2. :)
<xnox>   o python-support: python-support
<xnox>     [Reverse-Build-Depends: ubuntu-sso-client (MAIN)]
<xnox> dobey: spurious build-dependency?
<dobey> yes
<xnox> =)
<xnox> ok
 * xnox read scroll back. Me has a facepalm embarrassment moment.
 * xnox goes back to reading kindle
<dobey> well, the | dep will remain, but the explicit will drop. also working on having the package buildable on all supported versions of ubuntu from a single source. :)
<xnox> dobey: why? do you care about hardy?
<xnox> oh wait, lucid as well
<xnox> hmm
<dobey> i don't care about hardy. it's EOL :)
<slangasek> not yet it isn't
<slangasek> well, the desktop is, so yeah
<dobey> well, not for server it isn't.
<dobey> but for what i care about, it is :)
 * xnox adds google calendar reminder to drop python-support in april 2013 =)
<dobey> slangasek: new ubuntu-sso-client uploaded. sorry i fumbled that, and thanks for pointing it out :)
<slangasek> dobey: no worries - thanks for the fix :)
<xnox> vibhav: meeting ping? =)
<hallyn> stupid question perhaps - is 'fakeroot debian/rules clean; debian/rules build' supposed always trigger dh_auto_configure?
<infinity> hallyn: If it's a new-skool dh-7-ish package, and doesn't override auto_configure, yes.
<hallyn> infinity: well it does define override_auto_configure, but that's really what i meant :)
<hallyn> thanks
<hallyn> must be doing something else wrong
<xnox> hallyn: `dh build --no-act` is your friend
<xnox> similarly for clean target
<hallyn> xnox: will try it, thanks
<xnox> it lists all the targets and in what order they will be called. You may need --with addon bits as well
<xnox> that way you can easily troubleshoot dh's behaviour.
<xnox> hallyn much better than he CDBS dot graphs of thousands make targets
<mattrae> hi, i can't seem to generate debug symbols packages for mysql-server using methods that work for other packages.. anybody able to confirm a way that works?
<mattrae> here's some details on what i've tried: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-June/013677.html
<mattrae> in the end i just need the debug symbols for a backtrace, so if there are manual steps i can take to apply patches and compile, thats fine too. i don't know enough about packaging yet to know what is safe
<xnox> mattrae: i think it is a known problem that mysql-server is missing ddebs
<xnox> there was a bug about it or something somewhere
<xnox> mattrae: basically the buildsystem unconditionally strips them / builds without them.
<xnox> mattrae: pretty sure that someone took an action item on it, as it was picked for the blueprint that ddebs should be generated for every single version of the package, not just the current one
<mattrae> xnox: great, yeah maybe i can find that blueprint
<mattrae> xnox: would it be simple enough to manually apply patches and compile? just so i can get this backtrace
<xnox> mattrae: i don't know.
<mattrae> xnox: hmm, i'll see what i can figure out.. thanks for for the information
<bdmurray> stgraber: I'm looking at removing the bug pattern for bug 989585.  There is no way to encounter this anymore right?
<ubottu> Launchpad bug 989585 in resolvconf (Ubuntu Quantal) "resolvconf failed to install/upgrade because /etc/resolv.conf immutable" [High,Fix released] https://launchpad.net/bugs/989585
<stgraber> bdmurray: starting with quantal, no. That was just an issue on precise, fixed by an SRU.
<xnox> bdmurray: if SRU is installed...
<bdmurray> okay so the pattern could be modified to specify version 1.63ubuntu11 of the package
<dobey> bdmurray: reviewed your lptools branch. thanks. sorry it took a while.
<bdmurray> dobey: thanks
 * xnox is core-dev!!!! Whooo-ho =)
<dobey> barry: http://pastebin.ubuntu.com/1047991/ <- too bad that's pretty much all it does right now :P
<infinity> xnox: That was quick.
<infinity> xnox: Please don't break my computer.  Thanks.
<xnox> infinity: blame "tumbleweed> +1 [[ it's a faily early core-dev application, but warranted ]]"
<xnox> infinity: I'll try, but I can't promise you anything beyond the secrets of the universe.
<infinity> xnox: Breaking things is my job.  If you start doing it, I become redundant.  Just sayin'.
<xnox> infinity: it *only* took ~5 years
 * xnox wonders what my first upload should be
<dobey> xnox: it's no fun if it's not linux :P
<stgraber> xnox: a broken eglibc is usually a good one if you want to see how quickly we can revoke your upload rights ;)
<infinity> stgraber: *glare*
<stgraber> dobey: nah, linux is way to easy to work around, grub lets you boot an older kernel, libc is way more fun :)
 * xnox was more thinking partman-base with a date check to really screw up an RC iso ;-)
<dobey> stgraber: well, you can also upload grub to fix that :P
 * infinity wonders if perhaps this core-dev acceptance was a bit too hasty.
<infinity> xnox: I'd recommend your first upload be something not broken. :P
 * xnox where is my stash of 100 .changes files
<xnox> infinity: to be honest I was thinking to finish boost1.49 transition
<infinity> xnox: Oh, is it still not done?
<xnox> infinity: nope =)
<maco> stgraber: you're making me think of a few instances of ubuntu-devel-announce@ that said "DON'T UPGRADE!"
<xnox> infinity: I was waiting for upload rights to stop pestering you about it.
<infinity> xnox: Slacker.
 * xnox =(
<maco> and that time a classmate walked in and said "i hope you didnt upgrade today" and i said "no i saw the email in time.... but im guessing you didnt, by that face" "yeah...i had to reinstall"
<xnox> I loved the one which complete made your hardware explode, e.g. graphics or network card or something
<infinity> xnox: I think you just volunteered to to an aptitude merge.
<maco> i think that was hardy... compile flags were changed and everything was ok for about 2 weeks and then libc6....kersplode
<xnox> which like completely destroyed hardware rendering it a brick
<maco> xnox: the bad intel firmware for the e500 network card?
<xnox> infinity: I'm waiting for cjwatson to do it =)
<xnox> maco: yeah that one. I was freaked out cause I had a similar but not affected one.
<ahasenack> hi, can someone please target this bug for lucid, natty, oneiric and precise? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1004678
<ahasenack> O
<ubottu> Launchpad bug 1004678 in Landscape Client "Release 12.05" [High,Fix committed]
<ahasenack> I'm going to prepare an SRU for those
<stgraber> maco: :)
<infinity> ahasenack: Sure.
<ahasenack> infinity: thanks a lot
<tumbleweed> xnox: we offer a 30 day money-back guarantee on your core-dev application, if you break everything
<xnox> tumbleweed: fix the web link on your core-dev application, then we'll talk ;-)
<tumbleweed> :)
 * xnox started the trend with table based applications
<xnox> tumbleweed: should that be added to the template?
<tumbleweed> naah, but your one was prettier
<tumbleweed> the sponsorship miner does table generation
<xnox> stgraber: am I ok to forward your LXC reply to ubuntu-distributed-developer mailing list?
<stgraber> xnox: sure
<xnox> tumbleweed: what sponsorship miner?
<tumbleweed> xnox: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
<xnox> tumbleweed: it's so slowwwwwww
<tumbleweed> blame the ancient samosa.d.o
<xnox> tumbleweed: and no syncs, but that's a known bug
 * tumbleweed should actually host that on ubuntuwire, now that we have UDD there
<xnox> tumbleweed: I think my table css should be added to the template css for inside the page tables
<xnox> tumbleweed: I stole it from the Releases page ;-)
<tumbleweed> it'll have recent synsc (since lp started recording the sponsor)
<xnox> fair enough
<cnd> ginn is seeded in ubuntu's desktop image, but we don't plan to support it in quantal and future
<cnd> I want to remove it from the desktop seed
<xnox> tumbleweed: ## [[CategoryCoreDevApplication]] where you mean to uncomment this?
<cnd> is there a process I need to follow, or do I just edit the seed directly?
<tumbleweed> xnox: your attention to detail is impressive :)
<xnox> tumbleweed: don't thank me, thank OCD
<infinity> cnd: If there's some concensus in your team that dropping it is the right thing to do, just edit the seeds and commit.
<cnd> infinity, ok, thanks
<infinity> cnd: And if you want it gone RIGHT NOW, update ubuntu-meta afterward.  Otherwise, someone will pick it up when they refresh meta later.
<cnd> infinity, it can wait
<ahasenack> hi, I see that oneiric has had a landscape-client sru already (12.04.3-0ubuntu0.11.10 in oneiric-updates), but the branch lp:ubuntu/oneiric-updates/landscape-client doesn't seem to exist
<ahasenack> do I have a typo, or was the update not imported into udd?
<infinity> cnd: Note that it's in the edubuntu seeds as well as the ubuntu ones.
<infinity> stgraber: ^
<cnd> infinity, I'll remove it from there too, but how did you figure that out?
<cnd> do you have all the seeds on your computer?
<cnd> or is there some tool?
<infinity> cnd: apt-cache show ginn.
<infinity> cnd: But I do have them all checked out as well.
<cnd> infinity, from the Task field?
<infinity> cnd: Yeah.
<cnd> ok
<cnd> thanks
<infinity> cnd: There's also "seeded-in-ubuntu" in ubuntu-dev-tools.
<infinity> cnd: "seeded-in-ubuntu ginn"
<cnd> ahh
<stgraber> infinity, cnd: edubuntu-desktop depends on ubuntu-desktop, so that's how it ends up being seeded by edubuntu too. I'm fine with dropping it.
<cnd> stgraber, I was just about to ask about that
<infinity> stgraber: Ahh, I've never looked at edubuntu's STRUCTURE.
<cnd> since I didn't see ginn in the edubuntu seed :)
<cnd> infinity, thanks for the help, I think everything is good now :)
<cnd> infinity, though this does beg the question: will ginn be automatically demoted from main to universe?
<infinity> cnd: Once meta is refreshed, yes.
<cnd> ok
<cnd> cool
<infinity> cnd: If you want it in main, add it to supported.
<cnd> nope, we don't want to support it anymore :)
<infinity> Check.
<infinity> Then yes, it'll automagically drop out once nothing in main depends on it.
<infinity> (Which is just ubuntu-desktop)
<ScottK> xnox: Congratulations.
<xnox> ScottK: thanks a lot
<xnox> ScottK: at the meeting we mostly discussed cookies & food transfer protocols and then did a vote
<ScottK> yes.  I saw it in my scrollback.
<ScottK> Meetings like those as a good sign you were ready to apply.
<broder> xnox: yeah, +1 - congrats :)
 * xnox OMG my team memberships exploaded. So this is how almost everyone has 50 shades of Xubuntu logo on their homepage
<xnox> broder: thanks
<xnox> infinity: thanks for ~debiandevelopers approval
<malkauns> how do i change the titlebar text vertical offset?
<infinity> xnox: Yeah, I really need to clean that up some time.  I only add people who I can easily verify, I think I need to some sort of challenge/response email with the people I don't know and get them to sign the response with their Debian keys or something.
<infinity> xnox: Y'know, when I find some mythical "spare time".
<tumbleweed> how about just checking if they have a debian-keyring key in their profile?
<infinity> tumbleweed: You can upload any old public key to your launchpad profile.
<xnox> infinity: I'd think @debian.org on launchpad page is enough, since they had to verify launchpad's challenge response email
<infinity> tumbleweed: (If I could verify what key they signed the CoC with, that would work)
<tumbleweed> oh, I thought it made you verify it
<infinity> tumbleweed: Oh, if it does, that helps.  I haven't changed my key in LP since 2005. :P
<xnox> infinity: gpg key upload has challenge response.
<xnox> on launchpad that is
<infinity> xnox: Kay, good to know.  That'll help me automate probably about half the list.
<xnox> infinity: the trickier bit is removing MIA / alumni
<infinity> xnox: Well, it's not like the group grants you anything useful.  I just want it to be vaguely accurate and not hand out swirls willy nilly.
<xnox> infinity: =)))) the swirls willy nilly master
<xnox> infinity: lp-api to the rescue =) for automation
<infinity> (It should actually be bottles and swirls, but man, that's hard to represent in a tiny icon)
<infinity> The swirl looks bad enough as it is at that size.
<xnox> infinity: you and your urges to get everyone drunk.....
 * xnox kidding
<cjwatson> xnox: oh, well done
<xnox> cjwatson: thanks =)
 * Laney spots some controversial core-dev apps on the horizon ...
<xnox> Laney: don't forget to vote for yourself ;-)
<slangasek> xnox: congrats :)
<slangasek> Laney: oh?  how's that?
<xnox> slangasek: thank you
<Laney> slangasek: these "Laney" and "tumbleweed" characters are on the list
<slangasek> oh, your own, I see :)
<xnox> slangasek: my "quick" (only 5 years) core-dev application triggered Laney & tumbleweed to apply
 * slangasek grins
<Laney> I heard they were the shady sort
<xnox> Laney: 5 years or Laney&tumbleweed's applications
<broder> you guys finally are applying!
<ajmitch> Laney: can't trust them, I heard
<infinity> Laney: The team's full, we'll have to kick out ajmitch to make room for you.
<ajmitch> wouldn't surprise me if they did :P
<Laney> then who would I trick into doing last minute high risk uploads?
 * xnox winks
<ajmitch> I think xnox just volunteered?
<cjwatson> Oh, I usually go for infinity for that
<infinity> I do that all by myself without prompting!
 * micahg seems to end up with some of those as well on occastion
<infinity> micahg: Yeah, but mine work.
<micahg> infinity: good point :)
 * infinity runs away to find "lunch" before micahg hunts him down.
 * ajmitch should quietly hide from micahg also
 * xnox is off to try the UDD way of committing to branch to find out why core-devs complain about it so much. I can't possibly break package import more than it already is, right?
<jono> slangasek, hey
<jono> slangasek, do you have time for a quick G+ call?
<micahg> xnox: yes, you can :)
 * micahg thinks casper was the example of that
<xnox> also I'm sure infinity told me I get cookies after becoming a core-dev =)
<slangasek> jono: sure
<jono> thanks slangasek, I will set it up
<jono> slangasek, https://plus.google.com/hangouts/_/13aeff6fdafa4ec1dbc1f373306e10f0df4f8a3b?authuser=0&hl=en-US
 * SpamapS starts a test build of PHP 5.4.4 for quantal
<bkerensa> SpamapS: nice!
<SpamapS> sans-suhosin unfortunately.. but still.. time to move forward
<bkerensa> SpamapS: You know of any straightforward guides to debian chroot on Ubuntu?
<SpamapS> bkerensa: mk-sbuild --architecture foo unstable
<infinity> bkerensa: debootstrap --variant=buildd sid sid http://ftp.us.debian.org/debian
<bkerensa> ahh
<bkerensa> :D
<infinity> Or his. :P
 * SpamapS hugs mk-sbuild
<bkerensa> SpamapS: you rock... I think thats command slangasek gave me a few months back (I need a notebook)
<SpamapS> bkerensa: nah, you just need grep :) 574M    irclogs
<SpamapS> I think aths like, 9 years of irc logs
<infinity> Pfft.  IRC logs are for people whose hosts go down.  I just have unlimited backscroll.
<SpamapS> aths .. very close to thats
<SpamapS> infinity: uptime, the true measure of an admin's virility
<infinity> SpamapS: And how.
<infinity> Gather 'round the netcraft kids, let me tell you a story.
<infinity> About the good old days, when Linux hosts appeared to always reboot at 437 days.
<bkerensa> infinity: Can you search infinite backscroll?
<bkerensa> =/
<infinity> Err, 497.
<infinity> It's been a while.
<SpamapS> infinity: and then redhat begat day 438, and then day 1007 begat local kernel exploits, and all was rooted, ahhhhhhmmmeeeenn
<bkerensa> SpamapS: E: You must put some 'source' URIs in your sources.list
<bkerensa> why would it not put some in itself?
<maxb> Why would building a chroot require source?
<bkerensa> maxb: this is when I try and apt-get build-dep packagename
<maxb> well, do what the error tells you to, then
<micahg> bkerensa: yes, you need a source entry to know which build deps to use (or use mk-build-deps -i -r in a debian source dir)
<bkerensa> micahg: well the sources.list inside the chroot already have a source entry defined
<bkerensa> micahg: my fail for not apt-get update
#ubuntu-devel 2012-06-19
<pitti> Good morning
<pitti> mpt: actually ev is right; we will stop installing the proprietary drivers automatically in ubiquity; we actually never intended to at least for fglrx (that was a blatant bug)
<pitti> mpt: and with the system compositor, lightdm for screen locking etc, non-KMS drivers just won't cut it any more, so I'm all for not enabling nvidia automatically either any more
<pitti> mpt: (but NB that this is not really my decision to take any more)
<pitti> mpt: right, it's irrelevant whether the driver comes from jockey, or what modaliases are; this is just about "do we install it automatically or not?"
<infinity> doko / jdstrand: https://bugs.launchpad.net/ubuntu/+source/libfile-fcntllock-perl/+bug/1014961 is going to need a reasonably quick review by someone MIRish.
<ubottu> Launchpad bug 1014961 in libfile-fcntllock-perl (Ubuntu) "[MIR] libfile-fcntllock-perl; new dpkg-dev dependency" [Undecided,New]
<infinity> apw: FWIW, the above is to fix your debian/files concurrency issues, do you can stop employing dirty locking hacks in the kernel with the new dpkg.
<tremolux> RAOF: heyo! thanks for the upload of software-center 5.2.3  :D
<RAOF> tremolux: Please make it less of an ordeal next time :)
<tremolux> RAOF: not really under my control, my friend, but I'll do my best ;)
<astraljava> Hi gang, does anyone else get the cdimage mails to mailing lists? We're (Studio) having a problem with the size of the emails, seems they're about 50KB when apparently the mailman stops messages at 40KB.
<astraljava> I haven't found a way to tweak this individually for our list only on the administrative interface, but have I just not looked hard enough? How have you resolved the issue?
<micahg> astraljava: http://staff.imsa.edu/~ckolar/mailman/mailman-admin-quickref-0.2.html
<astraljava> micahg: bah... I can't seem to get anything right today. Thanks! :)
<dholbach> good morning
<pitti> cjwatson, ev: could you please add an XS-Testsuite header to ubiquity, like in http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/2031 ? I recently discussed that with the DEP-8 guys, and the spec is updated now
<vibhav> xnox: who pinged me?
<vibhav> s/who/you/
<vibhav> xnox: Also, congrats!
<mpt> pitti, so the Nvidia driver won't be installed even if you check the "Ubuntu uses third-party software to play Flash, MP3..." checkbox?
<pitti> mpt: that's how I take it, anyway
<mpt> pitti, ok, thanks
<pitti> mpt: I guess in the end we need to see how much we value system compositor, lock screen etc. over nvidia performance by default, and how well nvidia and nouveau work with unity
<pitti> RAOF: ^ how did you understand this discussion back theN?
<pitti> RAOF: (installing nvidia by default when you click the "third-party" check box in ubiquity)
<mpt> pitti, while I was digging through this yesterday I was depressed to discover that "text-free boot" has basically been made dependent on "ship Wayland" :-)
<pitti> mpt: we won't actually ship wayland
<pitti> mpt: that's teh "system compositor" stuff
<mpt> pitti, or at least that's what the blueprint says
<pitti> but again, it's depending on a KMS graphics driver
<pitti> mpt: they are very similar, anyway
<mpt> "The technology used will probably be Wayland, and in some ways this change is to implement the Wayland Tech Preview that was proposed for Precise [1]."
<RAOF> pitti, mpt: I'm not sure whether that's the right tradeoff yet. *Certainly* fglrx is wrong.
<pitti> yes, fully agreed to fglrx
<pitti> this _never_ was intended to be installed automatically
<pitti> it was a bug
<pitti> as for nvidia, I guess the desktop team needs to decide that in this cycle, considering performance, stability, and KMS-dependent features
<RAOF> (Sorry, multiplexing conversations)
<RAOF> We're not going to *break* the existing setup with the system compositor; if you're not running it, you'll get exactly the same behaviour as now.
<RAOF> Except in so much as the system-compositor based stack will get progressively better, and those improvements won't be able to be made on the binary driver side.
<pitti> RAOF: so you think nouveau is still considerably worse than ati? i. e. worse enough to warrant shipping nvidia by default?
<pitti> . o O { such a hard trade of which kind of badness you want... }
<RAOF> Yes; power management is the last big thing.
<pitti> mpt: ok, so it actually seems it's relatively likely that we'll install nvidia by default; sorry for all that confusion
<RAOF> If nouveau had power management enabled now, I'd be putting nvidia in the same basket as fglrx; some people will want it, most won't need it.
<pitti> RAOF: does "enabled" mean that it already exists and is buggy, or that it doesn't exist at all yet?
<mpt> pitti, by "by default" do you mean if the checkbox is checked, or even if it isn't?
<pitti> mpt: if the checkbox is set, sorry
<mpt> ok
<pitti> we don't install any proprietary stuff without the checkbox
<mpt> pitti, how did you find this out? :-)
<pitti> (and haven't ever)
<RAOF> pitti: It already exists, and I *think* it's in our quantal kernel, but is hidden behind an elaborate series of tests designed to disuade the unworthy.
<pitti> mpt: with "this" == ?
<mpt> pitti, that we will be installing Nvidia driver if you check the checkbox
<pitti> mpt: ah; cf. "desktop team needs to decide that during quantal"
<pitti> mpt: but it seems after what RAOF said we should install it for now
<mpt> pitti, oh, you found it out from that discussion with RAOF
<RAOF> Yes. If you need it again, unequivocably: Ticking that checkbox should enable the nvidia driver, if available.
<mpt> not from some mailing list message I haven't seen yet :-)
<pitti> RAOF: ok; committing that change to ubuntu-drivers-common then
<mpt> pitti, so the text in the installer should mention graphics after all
<pitti> yes, seems so :(
<mpt> okay.
<mpt> Heisenbergian work item
 * pitti sympathizes with https://plus.google.com/u/1/110197054476722784567/posts/eK8RFnDg39K
<vibhav> xnox: pong
<vibhav> pitti: hehe
<xnox> vibhav: hello, sorry, I think I got the dates wrong. Keep calm and carry on.
<vibhav> yeah, thats what I thought
<pitti> RAOF, mpt: ok, done: https://github.com/tseliot/ubuntu-drivers-common/commit/3edabca8
<mpt> ok
 * mpt tries the "bzr uncommit" command for the first time
<diwic> pitti, fwiw; I don't sympathise with that comment - the contact I've been having with the one Nvidia engineer active in the audio area has been good and friendly. (That doesn't mean that I think they should provide open source drivers, but that's another story.)
<pitti> no doubt about that; but I still critizice them about not releasing specs and claim it's because of patents or so
<seb128> hey pitti, diwic
<pitti> I mean, whether it's bit 5 or 8, or port 55 or 58 to wiggle to activate a particular function is not science, it's simply an arbitrary decision and convention
<pitti> hey seb128
<diwic> seb128, hi
<pitti> so it's once again not an engineer problem (I'm sure many of them feel similar), but again a management/patent/bureaucracy one
<diwic> pitti, yeah, agreed.
<pitti> I wouldn't put it as strongly as Linus, but I would never recommend anyone to buy an nvidia card if they want to use linux
<diwic> pitti, interesting. I think the xbmc community recommends nvidia as being the best.
<diwic> let me look that up
<pitti> well, I don't speak for the world :)
<RAOF> diwic, pitti: The actual nvidia linux driver team is pretty cool; they care about things being good. But there aren't that many of them.
 * pitti quietly hides his world domination plan
<diwic> from http://wiki.xbmc.org/index.php?title=Supported_hardware - "Team-XBMC recommends NVIDIA GeForce 6150 or later as NVIDIA are currently the manufacturer that offers good device-drivers for Linux"
<pitti> I think they should clarify "good" here
<pitti> they have lots of bugs, have lots of problems with multiple heads, have poor support for older hardware, and no KMS support, and nvidia hardware is a power drain compared to intel (although that is quite understandable given the different performance level)
<pitti> so they are certainly the better choice for gamers, but an absolutely bad choice for a work laptop
<RAOF> That's true.
<RAOF> They've got quite a good GL stack.
<RAOF> stgraber: I've just rejected the libvirt precise SRU. Are you here to discuss it?+
<infinity> RAOF: He lives in Canadia, and all sane Canadians (ie: the ones who aren't me) are fast asleep.
<hrw> http://marcin.juszkiewicz.com.pl/~hrw/shots/bad-fonts.jpg - does anyone know why I have some crappy fonts in GTK apps?
<xnox> hrw: because you use Gvim? =) /me no clue to be honest
<hrw> xnox: same in chromium, gnotes
<xnox> =(
<hrw> looks like oxygen-gtk theme is borked
<pitti> light-themes is rather broken ATM as well; both need adjustments for current GTK presumably
<pitti> s/presumably/confirmed/ for light-themes
<hrw> pitti: so which light colour theme is safe? (other they rayleigh)
<cjwatson> pitti: Sounds good, thanks - done
<pitti> cjwatson: cheers
<pitti> hrw: light-themes should mostly work again (I use Radiance)
<hrw> looks like 'xfce-winter' is also safe
<hrw> nope ;(
<seb128> text rendering is not part of the theme
<hrw> seb128: part of engine?
<seb128> no
<seb128> that's pango, freetype, etc
<seb128> the theme does shapes and colors basically, and effects
<hrw> seb128: Qt also uses freetype and displays properly
<seb128> when did the issue start?
<seb128> gnotes and chromium are not gtk3
<hrw> at least few days ago
<seb128> so I doubt it's any of the recent gtk3 changes
<seb128> neither is gvim
<hrw> in chromium issue is only on tabs and toolbars - pages are rendered properly
<seb128> is chromium using gtk3? (I don't think it does)
<hrw> gtk2
<seb128> ok, so your issues are different from what pitti mentioned
<seb128> no clue what they are but gtk2 didn't change for a while
<hrw> on my system only nautilus-dropbox is returned by 'aptitude why libgtk-3.0'
<hrw> s/3.0/3-0/
<seb128> urg
<seb128> dunno what weird setup you use
<hrw> seb128: kde
<seb128> ok, so I guess check with the KDE guys what they changed
<hrw> mkey
<seb128> I doubt the issue comes from the GTK side
<seb128> that stack didn't change in months
<achille> hi guys !!!
<achille> can anyone help me please ,  i found a bug  but i dont know against which package i have to report it . the bug goes as follow  when  opening  a gtk app  (gedit for example)  the menubar appears on both  the application   and the global menu    but only  when these apps are running on kde
<ev> doko, barry: are there any plans of getting this into Ubuntu: https://fedoraproject.org/wiki/Features/EasierPythonDebugging#py-bt
<ev> The use case I have is for hanging application. We're going to pop up apport when we detect an desktop application hang. When the user presses submit, apport then SEGVs the process and we get back a nice core dump
<ev> Which will give us a stack trace, but for python applications it would be better if we could get a python traceback
<ev> I suppose one alternative is to install a special signal handler in every python application and get it that way
<doko> ev: this should already be there. I can check if this is the newest version however, but I'd like to avoid backports to gdb
<doko> hmm, maybe not for python3
<ev> (gdb) py-bt
<ev> Undefined command: "py-bt".  Try "help".
<ev> That's gdb 7.4-2012.04-0ubuntu2
<cjwatson> ev: Which python executable are you debugging?
<cjwatson> ev: It works with python-dbg.
<cjwatson> ev: (Which is my reading of the Fedora spec too)
<ev> ahh
<ev> cjwatson, doko: that was indeed it
<ev> thanks
<cjwatson> But yes, not in python3-dbg right now
<ev> cjwatson: while I have you here, what are your thoughts on the idea? gdb to python stacktrace or installed signal handler that raises an uncaught exception?
<ev> if you have a moment, of course
<ev> otherwise no worries
<cjwatson> I'm *very* wary of injecting signal handlers into unsuspecting processes, even if they are SEGV.
<cjwatson> You must be ^-- this tall to use signals, as the saying goes
<ev> :)
<ev> looks like that leaves us with one option then
<cjwatson> You don't want to have to re-exec with python(3)-dbg, though.
<ev> yeah, hm
<cjwatson> Is it possible to make the gdb script work with the non-dbg interpreter?  (If it isn't, the signal handler approach wouldn't work anyway)
<ev> Why wouldn't the signal handler approach work with a non-dbg interpreter?
<ev> or am I incorrectly parsing your sentence
<cjwatson> Something still has to be able to introspect enough of Python's data structures to generate the backtrace.
<cjwatson> I don't know whether the dbg-ness is what allows us to do that.
<ev> cjwatson: python application hangs, send SIGQUIT to it, signal handler does raise(YoullNeverCatchMe), apport python hook picks it up, job done.
<ev> no need to know the internals of the python data structures
<ev> mind you, I'm not saying we go with this approach for the reasons you raised
<ev> just pointing out that I don't see why it needs dbg packages
<cjwatson> I'm concerned about Python's habit of leaking signal handlers to subprocesses it calls.  See SIGPIPE.
<ev> indeed, I do recall the pain you faced from that in ubiquity :)
<cjwatson> Unless you were supernaturally careful in a way that I'm not even sure how it's possible to be, the effect of this would be that any non-Python subprocess of Python would have SIGQUIT ignored.
<cjwatson> So I can't recommend that.
<ev> hmm, indeed
<cjwatson> (And yes, I'd misunderstood how you were planning to use the signal handler)
<ev> It doesn't seem like there's a good way to do this at present then. I think it's still valuable to collect these so that we get statistics on application hangs, but the python ones will just be unparseable.
<ev> unparseable in that a developer will look at them and their brain will melt out, not that the retracers will have any difficulty handling a SEGV'ing python application
<ev> The signatures for these may end up looking very similar to one another as well, but I think I'd rather collect python hangs and provide consistent UI than only show the dialog for binary applications.
<cjwatson> Mm.  (A small handful of the Python crashes will be useful even without this.)
<lifeless> atfork?
<lifeless> [ok, terrible idea]
<ev> cjwatson: I'm not sure I follow
<ev> hi lifeless
<lifeless> hi ev, and bye, tis sleep time for me! :)
<cjwatson> ev: Cases where the crash is in a C extension will be useful
<ev> lifeless: enjoy!
<ev> cjwatson: to be clear, they're hangs not crashes. We're just treating them as crashes because that's the most secure way to do it (https://bugs.launchpad.net/ubuntu/+source/whoopsie-daisy/+bug/1006398)
<ev> but if the hang were in a c extension, that would indeed be useful to capture
<ubottu> Launchpad bug 1006398 in whoopsie-daisy (Ubuntu) "Bypassing ptrace restrictions for errors from hanging applications" [Undecided,New]
<ev> if I'm following your logic :)
<cjwatson> ev: Right
<pitti> infinity: there, have a building cups
<ev> cjwatson: I've created bug 1015080 to track this, if we ever come up with a better solution.
<ubottu> Launchpad bug 1015080 in Whoopsie "Retrieve Python tracebacks from hanging applications" [Wishlist,New] https://launchpad.net/bugs/1015080
<hippiehacker> https://gist.github.com/2953844 # I'd like some thoughts on creating .deb packages that install ppas/repos that can in turn be dependencies of metapackags.
<jdstrand> infinity: libfile-fcntllock-perl: done
<tumbleweed> hippiehacker: this was discussed at some length at the last UDS. https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-security-of-third-party-debs Summary: it's not somthing we are mad about, it'd be nice to provide a recommended alternative
<hippiehacker> tumbleweed: I'm trying to create a tool that generates a local repository (with self-signed .debs) the debs themselves containing only dependency lists and ppas generated from simple profiles: https://github.com/hh/sputnik-repo/blob/master/data_bags/sputnik_profiles/rails%2Bsublime.json
<hippiehacker> The profiles could be easily shared  / possibly digtially signed / and include the gpg for the dependent repos.
<tumbleweed> hippiehacker: we'd like it if that problem could go away, but for now it's a reasonable solution
<Riddell> dpm: pitti: I'd like to suggest this to stop creating the kde language packs from launchpad https://code.launchpad.net/~jr/langpack-o-matic/no-kde-lang-pack/+merge/111010
<hippiehacker> tumbleweed: is https://wiki.ubuntu.com/ThirdPartyApt the main thrust of where we are currently headed?
<tumbleweed> hippiehacker: that's ancient, but it's what I'd want,yes
<barry> does anybody have an example of a cdbs package that has to call configure twice and build with two different set of options?  i'm currently looking at libpeas, but the cdbs magic is evading me.  or should i just switch it to dh and avoid the pain? ;)
<ailo> Hello. I'm trying to do a requestsync for qjackctl, but I get this: E: The package 'qjackctl' does not exist in the Debian primary archive in sid, sid-security, sid-updates or sid-proposed
<ailo> Never done this before, but I do know qjackctl does exist in Sid
<cjwatson> ailo: What's your full requestsync command line?
<ailo> Just: requestsync qjackctl
<ailo> I assumed options would be right by default
 * cjwatson blinks
<Laney> https://launchpad.net/debian/+source/qjackctl/+publishinghistory
<cjwatson> rmadison thinks it's present, though
<Laney> it is present
<Laney> but not according to LP
<vibhav> ailo: requestsync -d sid qjackctl quantal
<cjwatson> vibhav: No
<vibhav> cjwatson: why?
<cjwatson> vibhav: Won't help
<vibhav> ah got you
<vibhav> sorry :(
<cjwatson> This is confusing; I have no idea why LP thinks that was removd
<cjwatson> *removed
 * cjwatson wonders if he can get at the importer logs anywhere
<cjwatson> 2012-06-18 04:24:30 ERROR   Error processing package files for qjackctl
<cjwatson>  -> http://launchpadlibrarian.net/107864828/3nXxcopS5CWaeRIReI3Axcuek7g.txt (Error 25 unpacking source)
<cjwatson> That ain't gonna help
<xnox> barry: build: make -f debian/rules configure1-stamp && make -f debian/rules configure2-stamp .....
<xnox> barry: or you can simply add additional -stamp dependencies to the configure magic target
<mtcomscxstart> Hello, can anybody help me with Glade?
<cjwatson> So, it'll work if LP changes to unpack with DEB_VENDOR=debian
<cjwatson> bug 901334
<ubottu> Launchpad bug 901334 in Launchpad itself "ExecutionError: Error 2 unpacking source raised by gina.py" [Critical,Triaged] https://launchpad.net/bugs/901334
<barry> xnox: i have to do major surgery on the build.  i have to build it in two different locations, with clean, different configures each time, then move and rename one of the .sos into place.  i've no doubt that there's plenty of makemagic hidden in there, but the cdbs documentation is pitiful, and the .mk files are inscrutable.  you can probably infer my opinion of cdbs ;)
<cjwatson> (different source, same bug)
<xnox> barry: do you want me to try packaging it, if you promise to test it?!
 * xnox did many 'multi build' splits before
 * xnox used to love cdbs....
<vibhav> Does resyncronize and merge mean the same thing
<cjwatson> vibhav: Depends who's using the terms, but probably yes
<ailo> cjwatson: So it's a launchpad bug? Doesn't this affect a whole range of packages?
<vibhav> cjwatson: you
<cjwatson> ailo: I think I can fix this, but it will require landing an LP change so will take at least a couple of days; is that OK with you?  Once this is fixed, it'll be auto-synced, and won't need anyone to run requestsync
<cjwatson> vibhav: Then yes
<vibhav> ah thanks
<cjwatson> ailo: A handful; not many packages have different Debian and Ubuntu patch series to start with, and of those only a small fraction fail to unpack using the Ubuntu patch series
<ailo> cjwatson: Sounds great. I'm not in a hurry, no. Actually looking to backport that package to Precise later
<ailo> Aha
<vibhav>  ncbi-rrna-data Pre-Depends: dpkg (>= 1.15.6) for xz compression support.
<vibhav> Needed until after Ubuntu 12.04 LTS.
<Laney> won't it still fail to unpack when we try to build it though?
<vibhav> cjwatson: Do you know if we still need dpkg as a pre-depends in ncbi-tools6 for quantal?
<Laney> I suppose it is more correct to have the failure there than in the importer
<cjwatson> vibhav: We do not, and in any case the Pre-Depends was added in Debian; I've synced that package now.  (Though it'll probably fail to build until Adam's new dpkg upload lands.)
<cjwatson> Laney: Probably, but at that point it'll actually be feasible to fix it by hand
<vibhav> cjwatson: Thanks for the info
<vibhav> slangasek: you there?
<stgraber> RAOF: wasn't around anymore to discuss libvirt, ping me (and probably hallyn too as AFAIK he's the author of the SRU) when you start your day
<dobey> pitti: ping. any news about u1 MRE request?
<pitti> dobey: it seems fine to me, but we either need three more +1 on the list, or wait for the next TB meeting (next Monday)
<dobey> that's not what the wiki says
<dobey> "Changes can be approved via any single TB member"
<dobey> is the wiki wrong again? :)
<pitti> hm, I was not aware of that
<seb128> slangasek acked that when we discussed GNOME, he said one +1 was enough
<pitti> changing policies sounds like a board decision, not a member decision to me
<pitti> but so much the better
<pitti> I'll reply to the list and add it to the MRE page
<pitti> cjwatson: OOI, were you aware that new MREs can be approved by a single TB member?
<pitti> it's from 2007 already: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=diff&rev2=3&rev1=2
<dobey> right. 2007 is pretty old :)
<dobey> pitti: thanks again. :)
<cjwatson> pitti: Heh, I did know that once but I'd forgotten
<vibhav> xnox: you there?
<xnox> vibhav: yes
<vibhav> xnox: PM?
<xnox> ?
<xnox> vibhav: what do you mean?
<vibhav> xnox: Could I PM You?
<vibhav> Private Message
<xnox> yes.... you could have just done that straight away
<Yankees52> !staff
<ubottu> hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, dax, stew, or tomaw, I could use a bit of your time :)
<Yankees52> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<ahasenack> hi, could someone help me understand this lintian warning: W: landscape-client source: binary-nmu-debian-revision-in-source 12.05-0ubuntu0.12.04
<ahasenack> I'm building a sru candidate for precise, upstream version 12.05
<ahasenack> current precise package is 12.04.3-0ubuntu1
<ahasenack> current quantal package is 12.05-0ubuntu1
<dholbach> ahasenack, this warning is safe to ignore - NMUs are a Debianism
<ahasenack> dholbach: ok, it doesn't warrant an override I guess?
<dholbach> no
<ahasenack> ok, thanks
<seb128> bdmurray, SpamapS: hey, could one of you review the gwibber SRU today? I've added a filtered debdiff to the bug (the queue diff is a bit noisy due to vala autogenerated code diffs), the update fixes a bug in libgwibber-gtk that the appdevelopper guys would like to see resolved because their documentation example of how to use gwibber hits the said bug
<bdmurray> seb128: I'll have a look
<seb128> bdmurray, thanks, let me know if anything is missing
<bdmurray> seb128: well bug 938667 doesn't have an explicit test case
<ubottu> Launchpad bug 938667 in gwibber (Ubuntu Precise) "gwibber-accounts crashed with UnicodeEncodeError in on_facebook_auth_title_change(): 'ascii' codec can't encode characters in position 0-7: ordinal not in range(128)" [High,Fix committed] https://launchpad.net/bugs/938667
<seb128> bdmurray, refresh
<bdmurray> seb128: and this is supposed to supercede the existing one in -proposed?
<seb128> bdmurray, yes, the fix from the current one was incomplete and failed verification
<seb128> bdmurray, thanks ;-)
<jdstrand> infinity: bug #1011597 - done
<ubottu> Launchpad bug 1011597 in perl (Ubuntu) "[MIR] libfcgi-perl, libcgi-fast-perl" [High,Fix committed] https://launchpad.net/bugs/1011597
<xnox> SpamapS: do you mind if I rebuild drizzle for boost1.49? Or will you do bug 987575 really soon now ;-)
<ubottu> Launchpad bug 987575 in drizzle (Ubuntu) "Please merge drizzle 1:7.1.33-stable-4 from Debian unstable" [High,In progress] https://launchpad.net/bugs/987575
<SpamapS> xnox: I'll upload drizzle ASAP
<xnox> SpamapS: awesome =)
<xnox> thanks
<infinity> pitti, jdstrand: My heroes.
 * xnox doesn't feel like breaking autofs today, unless I messed up my upstart state
<ahasenack> hi, can someone help me interpret this basic message?
<ahasenack> "Good signature on /home/andreas/bzr/sru/12.05/precise/landscape-client_12.05-0ubuntu0.12.04.dsc.
<ahasenack> Package includes an .orig.tar.gz file although the debian revision suggests
<ahasenack> that it might not be required."
<ahasenack> why would the .orig file not be required?
<cjwatson> ahasenack: It's a case of tools being insufficiently clever.  Ignore it.
<ahasenack> it's not a native package
<ahasenack> cjwatson: ok, thanks
<cjwatson>             if debian_version == '0.1' or debian_version == '1' \
<cjwatson>                or debian_version == '1.1' or debian_version == '0ubuntu1':
<cjwatson>                 include_orig = 1
<cjwatson> But that's just a heuristic which goes wrong in this case, to purely cosmetic effect
 * xnox how unpythonic. BTW what about 0.1ubuntu1?
<cjwatson> I suspect it's not worth trying to add further band-aids
<xnox> or to be honest 0ubuntu0*
<xnox> =)))
<stgraber> if you want to get an extra line of code in your LP quota, you can probably switch to "if debian_version in (...)" (or just drop the check entirely?)
<cjwatson> stgraber: this is in dput, not LP
<xnox> I'm doing the fork count of automount and I get........ 9
<xnox> =(
<cjwatson> LP *knows* whether the .orig is needed; dput is guessing
<hallyn> stgraber: now this is funky.  didn't it sued to be that you could 'bzr push lp:~user/ubuntu/project/whatever' and it would auto-expand to add 'quantal' after 'ubuntu'?
<hallyn> maybe not
<cjwatson> Not AFAIK.
<stgraber> hallyn: that works for the main branch (lp:ubuntu/lxc) but for user branches you need to have the series in tehre
<cjwatson> I think you're thinking of lp:ubuntu/package -> lp:ubuntu/<development series>/package.
<stgraber> *there
<hallyn> i see
<hallyn> thanks
<pp7> why is there a small thin line just under the titlebar when i move windows around?
<SpamapS> infinity: so, how important is it for us to drop gcc 4.5 from the mysql build? At this point, upstream has ack'd the i386 ASM bug.. but I have no idea how long it will take them to reproduce
<infinity> SpamapS: It should happen eventually, so we're not carrying 17 versions of GCC, it's certainly not world-endingly urgent.
<SpamapS> infinity: ok, it appears that mysql is also one of the only things keeping 4.5 in Debian, and there's a push to drop it for wheezy
<SpamapS> infinity: 4.4 has been offered up as an alternative, apparently it has to be kept for some reason
<infinity> I'm not sure that's much of an alternative. :P
<infinity> SpamapS: I don't see anything obviously keeping gcc-4.4 in either, but maybe I'm missing it.
<SpamapS> infinity: Yeah, I think the right answer is actually to just disable the optimizations for i386 SSL
<SpamapS> infinity: upstream has it as a Serious / Critical issue so they will fix soon enough.
<SpamapS> in the mean time, i386 users will just have slow SSL. :-P
<infinity> SpamapS: Oh, boost depends on gcc-4.4.  Hilarious.
<SpamapS> infinity: of course it does
<SpamapS> boost depends on anger
<SpamapS> and frustration
<SpamapS> and pixie-dust I think
<SpamapS> should rename it to dementor
<infinity> SpamapS: So, I guess you could join the ranks of boost for now and downgrade.  Except that downgrading compilers makes things more and more likely to suck on ARM.
<infinity> SpamapS: And I hear we care about ARM now.
<infinity> SpamapS: You could use 4.4 on i386, and 4.7 everywhere else?
<infinity> SpamapS: That would be an acceptable solution to me for now.
<lifeless> infinity: caring, whats that?
<SpamapS> infinity: I wonder if it will make x86 suck a bit more too tho
<infinity> SpamapS: A tiny bit, perhaps, but not as much as disabling SSL optimisation, I imagine.
<SpamapS> infinity: if SSL is 4x slower, but the rest of the server is 5% faster, I'd prefer that.
<infinity> SpamapS: The x86 codepaths in GCC are fairly solid and mature, oddly enough, so all you'd be missing out on is random clever hacks for shiny new hardware we don't target.
<SpamapS> infinity: SSL is a niche case for mysqld
<infinity> But, you could always test, I suppose.
<infinity> Your call.
<SpamapS> I'll take your word for it. This is i386 after all
<infinity> Just saying that if you do decide to downgrade compilers, please only do it on i386.
<SpamapS> yeah that makes sense
<Daviey> slangasek: hey, so what is blocking precise nova sru?
<Daviey> slangasek: we sort of left the conversation unfinsihed yesterday.
<slangasek> Daviey: clarity from the TB about whether there should be an MRE for this and on what terms.  It clearly doesn't fit *except* as an MRE, and things are in limbo due to the "trial" MRE SRU in oneiric stalling out.  I asked zul to email the TB with details on what the test plan is, so we can un-stick it
<Daviey> slangasek: why is nova wedged on this, but the other openstack components were accepted?
<Daviey> slangasek: verification of the whole suite, were intended to be done coordinated.
<slangasek> Daviey: I don't know the openstack components by package name; but that question is better addressed to whoever did the accept?
<slangasek> in general terms, they were accepted because the SRU team member who reviewed them was satisfied that they meet the SRU requirements as-is, and that doesn't appear to be the case for nova
<infinity> Daviey: The simple answer could be (though I don't know) that the other components had simple and targetted fixes, and nova doesn't.
<Daviey> slangasek: do you see harm in nova being accepted into -proposed, under the condition that it does not paas verification until this matter is cleared up?
<infinity> Daviey: And slangasek beat me to that.
<Daviey> nova certainly has more changes, but i am not satisfied that the other components had fixes soley targeted towards issues that impact us.
<slangasek> Daviey: a) our processes don't give us any way to effectively put a hold on the package once it's in -proposed, b) I don't see any progress being made on clearing it up as there are no new mails on the tb list about this from the server team
<Daviey> slangasek: okay, bug 978907 is a bug fix for SUSE which is in glance currently in -proposed that was accepted.
<ubottu> Launchpad bug 978907 in glance (Ubuntu) "[SRU] capture-output fails in glance-control" [Undecided,In progress] https://launchpad.net/bugs/978907
<Daviey> If your demand is accurate, we should probably pull glance out of -proposed.
<Daviey> zul: can you rekindle the mail to TB as a matter of urgency please
<zul> Daviey: yeah
<slangasek> Daviey: the glance diff is 4% the size of the nova diff, and over half of the glance diff is in the debian/ directory.  I think it's reasonable to think that the glance changes actually did fit in the SRU guidelines as-is.
<slangasek> sorry, I missed a decimal point
<slangasek> .4% :P
<slangasek> though strangely most of that diff is the addition of a ChangeLog file, heh
<Daviey> slangasek: Currently, this is a one off request.  Which means it doesn't need a TB blessed MRE.  mdz commented that the SRU team are empowered to make this call.
<slangasek> Daviey: where has he said that?
<Daviey> slangasek: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/651875/comments/12 .. until we ask to do this again, it's a one-off.. no?
<ubottu> Launchpad bug 651875 in bind9 (Ubuntu Lucid) "Bind 9.7.0-P1 validation errors" [Medium,Confirmed]
<slangasek> do you intend to only ask for one?
<Daviey> Note, i'm not trying to bypass the TB.. i'm just keen to try to get this progressing to avoid what happend in Oneiric.
<Daviey> slangasek: today, i plan to only ask once.
<slangasek> I don't see how this is at all analogous to what happened in oneiric
<slangasek> the SRU *was* accepted into oneiric, and then there was no follow-through
<Daviey> slangasek: numerous contributing factors lead to it not being successful.
<Daviey> slangasek: it was accepted yes, but superseeded by -security, no?
<slangasek> Daviey: well, and?  Once superseded by security, shouldn't the uploader have merged the security changes and re-uploaded?
<slangasek> --> no follow-through
<Daviey> slangasek: no, it's not as simple as that.
<slangasek> and it seems to me that the server team, as a rule, does want MRE handling of these packages, which means everyone's time is better spent getting that MRE than having the SRU team review it and *then* have the TB review it
<Daviey> slangasek: as mentioned above, a standing MRE is being re-sought.  (i hoped it would be obvious the prior approval would be carry forwarded).. but at this stage, it seems reasonable to consider it a one off, whilst that is ongoing IMO.
<slangasek> what prior approval?
<slangasek> someone on the TB proposed a trial SRU in oneiric, which for all intents and purposes was a failure
<Daviey> slangasek: the oneiric MRE wanted to see a 'one off first'
<Daviey> this is the new, 'one off'.
<micahg> infinity: FWIW, the libboost and libusb deps on gcc-4.4 seem to be alternate deps
<infinity> micahg: Ahh, indeed.  That's rather unclever.
<micahg> infinity: the thing is, Debian doesn't seem to have plans to remove it ATM, so I wonder what they're keeping it for
<iamfuzz> IIRC the automatic installation of recommends came in Lucid.  Is this behavior enabled on Ubuntu Server installs as well or just desktop builds?
<infinity> iamfuzz: It's at the apt level.
<infinity> iamfuzz: (So yes, servers too)
<iamfuzz> infinity, cool, thanks, I thought I had remembered a discussion where a conf file was changed via the installer as serve rpeople didn't like recs getting yanked in by default
<iamfuzz> probably just losing my mind as usual
<infinity> iamfuzz: Nah, we did go on the warpath long ago to make sure that none of the recommends in main were silly, though.  And drop some to suggests.
<infinity> iamfuzz: Of course, if people prefer to not pull in recommends, they can change their apt configs (or run apt-get --no-install-recommends)
<micahg> or aptitude -R
<iamfuzz> infinity, I'm actually a fan of it
<slangasek> if people prefer that, they really shouldn't
<slangasek> ;)
<iamfuzz> slangasek, prefer having recommends installed by default?
<slangasek> prefer to not pull them in
<slangasek> the definition of Recommends in policy is such that anyone excluding them by default is inviting trouble
<iamfuzz> indeed, but I find many Debian "purists" annoyed by it
<iamfuzz> not a strict dep, so don't install it without my asking
<bdmurray> infinity: you'd said link to the build pages with sru-sccept? https://bugs.launchpad.net/ubuntu/+source/cron/+bug/794082/comments/7
<ubottu> Launchpad bug 794082 in cron (Ubuntu Lucid) "cron ignores /etc/default/cron" [Undecided,Triaged]
<SpamapS> lifeless: hey, would you be able to have a peek at bug #978356 .. or perhaps know a squid person who I can talk to about it?
<ubottu> Launchpad bug 978356 in squid3 (Ubuntu) "squid3 gets killed at startup with dnsmasq and no networkmanager" [Low,Confirmed] https://launchpad.net/bugs/978356
<barry> mterry: hi.  i have to leave in a bit, but i will look again at your branch later tonight.
<mterry> barry, sure!  I'll hit up mvo tomorrow about tests
<barry> mterry: sounds good, and i'll respond to your responses tonight too.  no worries on the indents.  u-m is on my hit list for major refactoring, though with all the py3 work i doubt i'll get to it this cycle. ;)
<mterry> barry, if you liked reviewing that branch, you'll live the 5 more I have chained on its back!
<mterry> :)
<mterry> s/live/love/
<barry> :-D
<barry> mterry: i'll rubber stamp any change that has more red than green :)
<mterry> :)
<barry> anyway gotta run.  ttyl
<RAOF> stgraber, hallyn: Ping, re libvirt SRU.
<stgraber> RAOF: pong
<RAOF> So, you've probably noticed that I've rejected the libvirt SRU; primarily because the postrm was doing bad things, but I'd also like to know what the impact of setting bind-interfaces is.
<stgraber> it's technically hallyn's SRU so I didn't actually look at that SRU at all but I indeed created that dnsmasq workaround for lxc initially that found its way to quantal and is being SRUed for lxc and libvirt in precise
<lifeless> SpamapS: hi
<stgraber> basically, the problem is that dnsmasq (not to be confused with dnsmasq-base) binds 0.0.0.0, preventing any other dnsmasq daemon from starting
<stgraber> bind-interfaces instead makes it bind all the interfaces (available at startup time) individually
<stgraber> and the "except" lines that we're adding for lxc and libvirt prevent the main dnsmasq daemon from binding interfaces where we spawn our own dnsmasq instance
<stgraber> this fixes a whole lot of bug report we've been getting for both lxc and libvirt (and I'm hoping to soon have the same trick in Network Manager, still need to talk to cyphermox)
<RAOF> Ok. And dnsmasq won't bind to interfaces that appear after it's started, right? What can be the consequences of that?\
<RAOF> Presumably the worst case is something like: a user plugs in a 3G modem and doesn't get DNS on it?
<stgraber> right, that's the one downside of that change though dnsmasq starts late in the boot sequence so it's unliekly to miss one of the builtin network cards
<stgraber> and it's pretty unlikely that you want a dns/dhcp server to automatically bind a usb interface you'd plug post-boot
<stgraber> so yeah, if a user plugs a 3G modem they won't get a DNS server binding to it, but I can't really think of a good reason why they'd like a server to bind to it in the first place :)
<lifeless> SpamapS: replied in the bug.
<stgraber> that config change will only impact people who have both dnsmasq and lxc or libvirt installed. That's a very small subset of people as none of these are installed by default (we installed dnsmasq-base which doesn't contain the dnsmasq init script)
<stgraber> and these users already have a 50% chance of not getting dnsmasq started at boot time
<stgraber> (the other 50% is the case where they have dnsmasq but not a working lxc or libvirt)
<SpamapS> lifeless: I filed a bugzilla ticket.. will that have a similar effect as emailing squid-dev ?
<RAOF> Oh, because lxc/libvirt's dnsmasq claim the interface?
<SpamapS> lifeless: meanwhile revisiting it made me realize we can work around the issue by just respawning squid if it dies via SIGHUP
<stgraber> RAOF: we currently have libvirt, lxc and network-manager that all spawn their own dnsmasq. They all use bind-interfaces and only bind their interface (respectively virbr0, lxcbr0 and lo)
<stgraber> RAOF: the problem is that if they try to do so after the dnsmasq init job is started, they can't as it's already binding 0.0.0.0 on all interfaces
<stgraber> and by chance they start before the dnsmasq init job, then dnsmasq itself will fail as it can't bind all interfaces (because some are already taken by lxc/libvirt/network-manager)
<andersk> Todayâs dpkg upload broke my quantal multiarch system.  I filed bug 1015329.
<ubottu> Launchpad bug 1015329 in dpkg (Ubuntu) "dpkg: error: file triggers record mentions illegal package name `libgtk2.0-0' (for interest in file `/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules'): ambiguous package name 'libgtk2.0-0' with more than one installed instance" [Undecided,New] https://launchpad.net/bugs/1015329
<lifeless> SpamapS: close enough
<stgraber> so while not perfect, I think that bind-interfaces trick is the best way we have to force all dnsmasq instances to bind only what they actually need (where dnsmasq itself is considered to "need" everything but the libvirt/lxc/NM interfaces)
<lifeless> SpamapS: that said, the race still exists with your patch
<lifeless> SpamapS: you actually need to either a) set SIGHUP to ignore as you spawn, or b) check for something (e.g. the pid file) before assuming you can SIGHUP it.
<lifeless> SpamapS: mmm, I might be wrong, if you are setting it before the pid file is written, and the script gets the pid by reading the pidfile.
<RAOF> stgraber: I don't suppose there's a way to get the best of both worlds? Have dnsmasq ignore the interfaces you need, *and* pick up new interfaces?
<RAOF> For example: how disruptive is restarting dnsmasq?
 * xnox ---> this made my day "svn log can now print diffs"
 * xnox it's --diff not -p
<stgraber> RAOF: I think we might be able to do something like that using an upstart job triggering on net-device-added and net-device-removed and sending SIGHUP to dnsmasq (assuming dnsmasq binds to new interfaces in such case)
<slangasek> svn --i-want-to-be-a-real-boy^H^H^Hvcs
<stgraber> RAOF: but that's somewhere on my nice to have list of dnsmasq stuff for 12.10, not something I consider critical for the 12.04 SRU
<xnox> infinity: thank you for dpkg! dep-waits unleashed =)
<stgraber> RAOF: mostly because dnsmasq itself isn't supported (universe package). We care a lot more about libvirt/lxc/network-manager so improving dnsmasq is pretty low on the todo.
<infinity> xnox: Mmhmm, and https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1015329 caused, apparently.
<ubottu> Launchpad bug 1015329 in dpkg (Ubuntu) "dpkg: error: file triggers record mentions illegal package name `libgtk2.0-0' (for interest in file `/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules'): ambiguous package name 'libgtk2.0-0' with more than one installed instance" [Undecided,New]
<xnox> slangasek: one of these days PAPT PMPT will change to a real vcs
<slangasek> unfortunately it'll probably be the one that's real but ugly ;)
<RAOF> stgraber: It would make *me* happier with the SRU if it changed behaviour for only libvirt, lxc, network-manager :). I wonder if SpamapS would like to weigh in?
<xnox> infinity: nah =) I only care about unblocking packages in boost1.49 transition. If only cjwatson does aptitude merge in his sleep ;-)
<xnox> only 10 left !
<stgraber> RAOF: well, as it is the SRU will only change the behaviour for users of libvirt, lxc and network-manager as it's a change in these packages and not in dnsmasq itself.
 * xnox or 15 if including otherwise marked as dealt with
<cjwatson> xnox: hopefully tomorrow
<xnox> cjwatson: \0/ yeah =)
<xnox> cjwatson: hopefully tomorrow i will train autofs' upstart job to work after merging new release!
 * xnox new release == merging debian
<stgraber> RAOF: oh, and I apparently forgot to mention that on top of the boot time race between the various dnsmasqs, this bug also prevents someone from installing lxc, libvirt or network-manager on a system that's already running the system wide dnsmasq.
<slangasek> we should probably put an archive hold on the new dpkg for bug #1015329
<ubottu> Launchpad bug 1015329 in dpkg (Ubuntu) "dpkg: error: file triggers record mentions illegal package name `libgtk2.0-0' (for interest in file `/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules'): ambiguous package name 'libgtk2.0-0' with more than one installed instance" [Critical,Triaged] https://launchpad.net/bugs/1015329
<RAOF> stgraber: Right, but what I meant is that it (potentially) changes the behaviour on interfaces which aren't owned by libvirt, lxc, and network-manager. But dnsmasq *is* in universe, so the bar for convincing me that it'll be too much effort to avoid that is lower than for a main package :)
 * xnox off to sleep while buildds do their chugga chugga
<stgraber> RAOF: oh, and btw, lxc with the exact same fix was allowed into -proposed a week ago :)
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso, pitti
<SpamapS> lifeless: ACK, I see that the patch is probably not entirely sufficient.
<SpamapS> lifeless: just narrowed the window of vulnerability
<stgraber> RAOF: I guess my point of view is that these systems are already broken, so anything we do will make them less broken. If these people, after getting the initial fix through lxc, libvirt and network-manager get into the issue where dnsmasq doesn't bind some interfaces, we can always look at SRUing dnsmasq to introduce the upstart job trick (or an ifupdown hook, or udev hook, ...)
<RAOF> stgraber: That makes sense.
<RAOF> Thanks.
<dupondje> slangasek: just hit that bug also now :( just when I decided to upgrade my system :P
<slangasek> dupondje: info on the bug about how to manually recover; working now on mitigating
<dupondje> 'by manually editing /var/lib/dpkg/triggers/File' :) doesn't really say what to change :)
<andersk> I had to replace libgtk2.0-0 with libgtk2.0-0:amd64 in the second column, then repeat for a few other packages as the error message changed.
<dupondje> lets see
<dupondje> seems working
<dupondje> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667843
<ubottu> Debian bug 667843 in apt "dpkg: error "ambiguous package name" during upgrade to multiarch package" [Important,Fixed]
<YokoZar> !regression-alert
<YokoZar> https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1015337  --- apt-get install dansguardian started failing with the new clamav update
<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
<ubottu> Launchpad bug 1015337 in clamav (Ubuntu) "clamav-base fails configure with `/usr/share/doc/clamav-base/examples/main.cvd': No such file or directory" [Undecided,New]
<YokoZar> Good afternoon folks :)
<slangasek> dupondje: bug description updated with a script to rescue the system
<YokoZar> Actually, my regression alert is an ubuntu-security regression it seems.
<slangasek> andersk: thanks for the bug report - I've updated the bug description now with a script that I believe should DTRT for all users, do you want to review?
<dupondje> great :)
<mdeslaur> YokoZar: hi! clamav upstream no longer bundles the virus definitions in the main package
<mdeslaur> YokoZar: oh, switching to #ubuntu-hardened
<andersk> After fixing the triggers file, I was in a state where apt didnât understand that any foreign packages were installed, which is why I did âdpkg --add-architectureâ.
<andersk> Itâs possible that dpkg.postinst would have taken care of that, but Iâd have to think carefully about the ordering of events or try to test it again.
<slangasek> andersk: yes, there's an unfortunate window where dpkg has forgotten about the foreign architectures, but 'dpkg --configure -a' was definitely sufficient here to fix it
<slangasek> so provided you're not unpacking foreign-arch packages at the same time as dpkg itself, it will definitely work; and if you *are* unpacking foreign-arch packages at the same time as dpkg, I'm not sure what happens, but definitely nothing unrecoverable
<andersk> I also reinstalled the affected packages for good measure.  For that I had to delete a bunch of broken symlinks: /usr/share/doc/libglib2.0-0/{README.gz,changelog.Debian.gz,AUTHORS,NEWS.gz}.  But that might be an unrelated bug from long ago.
<andersk> In fact, I still have several such broken symlinks, e.g. /usr/share/doc/libfuse2/changelog.Debian.gz is a symlink to itself.
<slangasek> I'm reasonably certain that's unrelated
<slangasek> given that I had that broken symlink on my system before upgrading dpkg
#ubuntu-devel 2012-06-20
<slangasek> mind you, I don't see what's *caused* that broken symlink... but I don't see anything multiarch-related here
<andersk> Yeah, itâs only multiarch-related in that it causes multiply-installed multiarch packages to fail to reinstall.
<slangasek> andersk: that's a mis-migration in the fuse-utils binary package
<slangasek> $ dpkg -c /mirror/ubuntu/pool/main/f/fuse/fuse-utils_2.9.0-1ubuntu2_all.deb |grep changelog
<slangasek> lrwxrwxrwx root/root         0 2012-06-11 09:18 ./usr/share/doc/fuse-utils/changelog.Debian.gz -> ../libfuse2/changelog.Debian.gz
<slangasek> yet /usr/share/doc/fuse-utils is itself a symlink to libfuse2
<andersk> /usr/share/doc/ure/changelog.Debian.gz is the other example I see.
<dupondje> What is the reason some packages are more recent in Precise then in Qunatal? For example bind9
<RAOF> dupondje: Because people have been naughty, it seems.
<RAOF> Or because we expect a new version in quantal real-soon-now.
<dupondje> no newer version in debian neither
<dupondje> so I doubt there is a new version comming real soon :)
<RAOF> Hm. What bug was the SRU associated with?
<dupondje> RAOF: was due to http://www.ubuntu.com/usn/usn-1462-1/
<dupondje> but can't find bug directly :s
<gnomefreak> is it known that dpkg update is spitting out a 403 forbidden error
<slangasek> yes
<slangasek> http://identi.ca/notice/94752326
<StevenK> There's a good reason for that, too.
<gnomefreak> thanks
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<micahg> jbicha: you took away infinity's beer: http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
<pitti> Good morning
<jbicha> micahg: I think evolution is ok now, evolution-exchange can just be synced from Debian later today
<micahg> jbicha: yeah, I was referring to evolution-exchange :)
<micahg> infinity: i386 and powerpc are tied now (including depwaits) :)
<pp7> why is there a small thin line just under the titlebar when i move windows around?
<pitti> cjwatson, ev: https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-ubiquity/lastFailedBuild/ARCH=i386,label=albali/ failed due to not finding the "mock" module; I think you need to change python-mock to python3-mock in debian/tests/control
<pitti> cjwatson, ev: OOI, what does the "@" do in d/t/control's Depends: line?
<infinity> micahg: My poor beer. :(
<infinity> micahg: On a more positive note, if the test build ever finishes, I suspect I have mono/armel licked.
<infinity> micahg: With that, dpkg, and debhelper, I intend to do a mass-give-back and see what sticks.
<micahg> infinity: yeah, armel takes the cake for failures
<infinity> micahg: It's mostly just fallout from mono and ghc.
<infinity> micahg: I have the ghc fix in the wings, just need to jam the rebootstrap in sideways.
<micahg> cool
<infinity> So, after our panic to fix dpkg, has anyone run into problems with -3ubuntu2?
 * pitti must admit he never noticed any trouble with dpkg
<infinity> pitti: Then you didn't have multi-arch:same packages installed when you upgraded to -3ubuntu1
<infinity> Or, rather, not ones with triggers.
<infinity> So, desktop ones like libgtk.
<pitti> $ dpkg -l *:i386 | wc -l
<pitti> 78
<pitti> not GTK, though
<infinity> Yeah.  Was an issue specifically with packages with triggers.
<infinity> Hence why I didn't catch it pre-upload.  Didn't test on a fully-loaded m-a/desktop mess.
<infinity> Oh well.
<infinity> Sort of "fixed" now in the most recent version, but we need to revisit it later with different shaped hammers.
<larsduesing> it won't be honoured, if I add a patch to a package in ubuntu, if this patch is in upstream bugzilla for >2 years as enhancement, nobody at upstream cares about, but users are asking me what's on with that patch?
<larsduesing> good morning :-)
<TheMuso> [B/c
<micahg> larsduesing: is it an Ubuntu specific package?
<larsduesing> no
<larsduesing> cyrus-sasl...
<larsduesing> :)
<larsduesing> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3219
<ubottu> bugzilla.cyrusimap.org bug 3219 in plugins "sql canonuser plugin" [Enhancement,New]
<larsduesing> (oh, cool... ubottu is really smart :) )
<micahg> larsduesing: I suggest speaking with the Debian devs about it, as they sometimes have upstream connections (the Debian SASL team seems to have an ML as well) http://packages.qa.debian.org/c/cyrus-sasl2.html
<larsduesing> good idea..
<larsduesing> thanks
<infinity> Ooo, my mono/armel passed the point where it failed on the buildds...
<infinity> Exciting times.
<infinity> Now, do I upload it and pray it doesn't fail later, or wait?
<larsduesing> micahg: omg... there are _bugs_ in debian-bts (I would identify as security-ones...) from 2008 not patched in sasl...
<larsduesing> so talks from debian to cmu aren't much better either...
<micahg> larsduesing: well, it's maintained (last upload 3 months ago, but they might need help if this is an itch you'd like to scratch)
<micahg> larsduesing: I still suggest speaking with them as upstream seems active enough (average one release per year)
<larsduesing> yes
<larsduesing> there are current git commits (last 10days ago)
<micahg> larsduesing: there are no known open security issues in Ubuntu for cyrus-sasl2: http://people.canonical.com/~ubuntu-security/cve/pkg/cyrus-sasl2.html, if there are issues affecting us, please let the security team know: https://wiki.ubuntu.com/DebuggingSecurity#How%20to%20File
<larsduesing> I must confirm if there is still a bug... working on it
<pitti> cjwatson, ev: wrt adt-ubiquity again, I think there's a bug in autopkgtest; ubiquity does not specify "no-build-needed", so it shoudl buidl the package and therefore install all its build deps (which include python3-mock)
<pitti> jibel: ^ FYI
<jibel> pitti, I filed bug 1015400
<ubottu> Launchpad bug 1015400 in ubiquity (Ubuntu Quantal) "update depends to python3-mock in autopkgtest control file" [Undecided,New] https://launchpad.net/bugs/1015400
<pitti> jibel: ah, thanks; following up there
<pitti> jibel: followed up with some details; I guess that broke with --no-built-binaries
<jibel> pitti, I think so. without this option build-deps are installed and python3-mock is listed there.
<pitti> right
<pitti> but it should still build ubiquity in this case
<dholbach> good morning
<cjwatson> pitti: I think that autopkgtest behaviour is deliberate and sensible.  The tree has been built, but that doesn't mean that the tests are run in the same chroot that built it.  They really shouldn't assume that they do, since what they're trying to do is test the as-installed environment, which won't include build-dependencies.
 * pitti is a bit lost with his brand new panda board; I wrote the daily-preinstalled to an USB stick, connected the board to a HDMI monitor, switch on, nothing happens at all except the green LED turning on
<cjwatson> pitti: I'll fix that ubiquity control file bug, thanks.
<pitti> https://wiki.ubuntu.com/ARM/OmapNetbook and http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage don't give additional info either
<cjwatson> pitti: Oh, no, you're right, I see now that it isn't trying to build the package, so yes that's a bug.  I think my point stands as well though
<pitti> cjwatson: hm, I don't see a build in https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-ubiquity/37/ARCH=amd64,label=albali/artifact/results/log
<pitti> cjwatson: right, that's why I left the ubiquity task open
<cjwatson> pitti: @ means "all the binaries built by this source", per the spec
<pitti> cjwatson: but nevertheless in that case it ought to have been built
<pitti> (even if it's not necessary; I don't know if it is)
<cjwatson> Yeah
<cjwatson> It is
<pitti> cjwatson: @> thanks
<pitti> ogra_: do you know if there is any chance to set up a panda board without an SD card? I only have 1 GB cards available, but an 8 GB usb stick with the current preinstalled image
<pitti> ogasawara: but I don't see anything at all on hdmi and the serial port
<pitti> err, ogra_ ^
<pitti> ogasawara: ignore me
<ogra_> pitti, just use netinst, there are SD images
<pitti> ogra_: uboot is the thing that talks to the serial port, isn't it?
<ogra_> that gives you a normal alternate install
<ogra_> well, MLO (first stage bootloader) initialize the serial port, then it loads uboot-bin
<pitti> I had expected this to run from some internal flash; but it seems not even that is there
<ogra_> nope,  to costly
<pitti> I also followed http://www.omappedia.org/wiki/Ubuntu_Pre-built_Binaries_Guide, but no luck
<ogra_> if you find something internal nowadays, its an eMMC
<pitti> all documentation I can find is for sd cards
<pitti> ogra_: i. e. the serial port is by and large useless, I just need a big enough SD card and then I don't need to worry about the serial port?
<ogra_> the serial port is disabled in the desktop images ... you will only see the first few bootloader messages, else it behaves identically to an x86 images
<ogra_> the server images do everything on serial though ...
<ogra_> so if you got display probs, start with a server image
<ogra_> if you want to do a real alternate install use the netboot images
<ogra_> that enables you also to have / on USB
<ogra_> (which is tons faster than SD, but you need the SD card as "bootfloppy" still)
<pitti> ogra_: http://ports.ubuntu.com/dists/quantal/main/installer-armel/current/images/ -> no omap4?
<ogra_> http://ports.ubuntu.com/dists/quantal/main/installer-armhf/current/images/omap4/netboot/boot.img-serial.gz
<pitti> nevermind, armhf
<ogra_> right, armel is semi dead
<pitti> ogra_: thanks; with that image I at least see d-i in minicom
<pitti> still no hdmi, though
<pitti> the monitor doesn't even recognize that there's somethign attached to the cable
 * ogra_ would recommend using screen for serial 
<ogra_> try the dvi port instead
<pitti> would that be boot.img-fb.gz ?
<pitti> or sohudl it also work with -serial?
<ogra_> thats a quantal image ? we had some display issues and are waiting for a new codedrop from TI, if you cant get it to work, downgrade to the precise kernel package
<ogra_> the fb image defaults to framebuffer output, yep
<pitti> ogra_: ok, when I use the dvi connector (not hdmi), the monitor recognizes the hdmi input; fun
<pitti> ok, trying quantal
<pitti> err, precise
<Laney> let me know if you get DVI working
<Laney> we talked about this a bit yesterday, seems nobody did
<ogra_> well, try with a precise kernel then
<Laney> I was trying the precise desktop image
<ogra_> hmm, that should be flawless unless you have a weird monitor that reports wrong EDID data
<Laney> maybe I did something wrong
<ogra_> there is not much you can do wrong with the preinstalled images
<ogra_> as long as your power supply is powerful enough andd your monitor isnt reporting insane things you should be fine
<Laney> like I connected to the wrong HDMI port or something
<ogra_> if your monitor *does* report insane things though, you can boot with it unplugged
<ogra_> and plug it in after boot, that will give you at least 800x600 (fallback mode)
<Laney> cheers, i'll try it later
<pitti> ogra_: thanks for the hand holding! precise's -fb image works fine
<ogra_> yay, good
<pitti> ogra_: so I guess I'll buy a large SD card on Saturday and try again next week
<ogra_> k
<ogra_> note that we will switch to live images in quantal ... that means USB disk is required (ubiquity cant install to its installation media yet)
<pitti> ogra_: that seems like what I want anyway; except that I'll still need the SD card for the initial boot?
<ogra_> no, for all boots
<ogra_> it will become your "bootfloppy" since there is no flash and no way to boot off a USB disk directly
<pitti> ogra_: but that will boot from the USB stick, when it's plugged in?
<pitti> (I mean the uboot part on the SD)
<pitti> and if the USB stick doesn't have anything or is not present, continue to boot from the SD?
<ogra_> right, but you need both, SD card and USB disk/card
<pitti> yes, understood (that's what I meant with "initial" boot, the uboot part)
<ogra_> no, it wont boot off the Sd anymore after install
<pitti> so I guess I can use one of my 1 GB SDs for booting
<pitti> and just need the large one for the install
<ogra_> (new cmdline etc, no casper initrd anymore)
<ogra_> right
<ogra_> you can just dd the size of the first partition from one SD to another
<pitti> cjwatson: ubiquity failed again, FYI; now needing python3-six :/
<cjwatson> pitti: Yes, that's the autopkgtest bug, I think
<cjwatson> pitti: ubiquity already depends on python3-six, so this shouldn't be needed in debian/tests/control
<pitti> ah, so that's not actually the bug I meant
<cjwatson> Oh
<pitti> I meant that it does not attempt to build the package although it should
<cjwatson> Wouldn't it be fixed by building and installing the binaries?
<pitti> so you mean that it does not actually install the @ Depends:?
<cjwatson> Apparently not
<cjwatson> But perhaps that's simply because it didn't build them
<cjwatson> It wouldn't surprise me to find that that was just a consequence
<pitti> that would certainly hide the other bug, yes
<pitti> but even if it installed ubiquity's build dependencies it would just mean it would test ubiquity from the built tree
<pitti> instead of the system-installed bits from the ubiquity package
<pitti> it should install the latter and test that, not the build tree
<cjwatson> No, I mean that @ is "all the stuff I just built"
<pitti> which is what the @ Depends: is supposed to do
<cjwatson> And if it didn't build anything it would be null
<pitti> oh, you mean it computes @ from teh list of built .debs, not from debian/control?
<cjwatson> Which would have the effect of transitively losing python3-six
<cjwatson> I'm not sure; it seems plausible though
<pitti> that's again wrong, it needs to look at debian/control
<pitti> as we have a lot of packages with no-build-needed
<pitti> (as we just need the test suite from the source, nothing else)
<pitti> jibel: ^ perhaps we should drop --no-built-binaries for now until these bugs are sorted out
<jibel> pitti, sure, I'll revert the change.
<pitti> I made a note in bug 1015400 to investigate that other bug, too
<ubottu> Launchpad bug 1015400 in autopkgtest (Ubuntu Quantal) "does not build packages which do not declare "no-build-needed"" [High,In progress] https://launchpad.net/bugs/1015400
<ev> GDBus GI bindings or python-dbus for new code?
<pitti> ev: if you want to export DBus objects, python-dbus
<pitti> ev: if you only want to call services, it doesn't matter much
<ev> I do indeed
<ev> thanks, I hadn't realized GDBus was missing that in what it exposed over GI
<pitti> gnome bug 656325 FYI
<ubottu> Gnome bug 656325 in gdbus "Make GDBusInterfaceVTable binding friendly" [Normal,Assigned] http://bugzilla.gnome.org/show_bug.cgi?id=656325
<pitti> ev: I finally fixed the underlying pygobject bug a while ago, but didn't get around to fixing this in glib, mostly because python3-dbus is there now
<ev> pitti: subscribed. Thanks
<cjwatson> mvo: Is there any way to use 'apt-ftparchive generate' to generate Contents files without it also generating Packages/Sources?  https://bugs.launchpad.net/launchpad/+bug/1013583
<ubottu> Launchpad bug 1013583 in Launchpad itself "contents-generation could be 2x faster by not regenerating Packages/Sources" [Low,Triaged]
<mvo> cjwatson: I don't think so, but adding it shouldn't be too hard, something like APT::FtpArchive::ContentsOnly could be added I presume
<mvo> cjwatson: http://paste.ubuntu.com/1050714/ <- somehting like this maybe?
<xnox> autofs has changed the # of times it forks, which results in upstart tracking wrong pid. The actual number of forks is now probably 4, instead of previous 1. But i'm not too sure, because depending on which auto.foo scripts are enabled there can be more forks.
<xnox> I have changed autofs to run in the foreground mode instead, and let upstart connect conlose log to it into /var/upstart/autofs.log
<xnox> but this means that automount messages no longer appear in syslog
<xnox> i'm thinking to add descriptive changelog & NEWS entry w.r.t to this change
<xnox> or is this issue serious enough to hunt down where/why autofs has changed its work behaviour
<xnox> Daviey: slangasek: jodh: cjwatson: ^^^^^
<cjwatson> mvo: Seems plausible, though I haven't looked in detail; if that works, do you think we could SRU that to lucid and precise, for LP's benefit?  (A bit out of the ordinary for an SRU, but we've done it before for apt-ftparchive.)
<mvo> cjwatson: yes, I think that could be done
<cjwatson> An hour of cocoplum time isn't to be sniffed at
<cjwatson> Actually 1.5 hours
<cjwatson> xnox: I think it's at least worth understanding what the extra forks are, to start with
<xnox> cjwatson: ok. let me digg a bit further.
<xnox> it's clones, not forks, but still...
<cjwatson> Meh, much the same thing
<Daviey> xnox: not having autofs logging at all is bit of a pain, but based on both issues, is the better of two.  Ideally, still logging the output somewhere would make me a happy bunny.. but i supposed you have explored that?
<Daviey> xnox: i haven't checked, but i guess there is no --foreground --log= , similar option?
<xnox> Daviey: /var/log/syslog -> /var/log/upstart/autofs.log for automount messages
<xnox> Daviey: upstart by default now attaches console, e.g. stdout/stderr and flushes them into /var/log/upstart/$job.log
<xnox> for free
<xnox> Daviey: so instead of doing logcheck/logwatch/ manual troubleshooting from /var/log/syslog it now needs to be done from /var/log/upstart.....
<xnox> /var/log/upstart/$job.log that is
<xnox> cjwatson: Daviey: there is a new function called check_nfs_mount_version, which calls fork, and possibly spawns shells when executing /etc/mount.[net|nfs] et all
<xnox> (not sure if additional spawning counts as forks/clones or not)
 * xnox goes to read git log
<Daviey> xnox: Providing it's documented, and as more log data seems to be going into upstart, it seems reasonable to JFDI...  I do wonder if upstart might be able to log job output to syslog.. jodh ? :)
<xnox> Daviey: spamming syslog, is not inline with upstart's goals. although it does bring the question of syslogd pushing logs to remote machines....
<Daviey> well, that is the intent i am thinking.. log aggregation is a big deal.
<jodh> xnox: +1 on needing to understand the change.
<jodh> Daviey: "console syslog" is on the wishlist somewhere (along with allowing syntax like "console log output").
<Daviey> jodh: oh, super!
<vibhav> pitti: ping
<pitti> vibhav: hello
<vibhav> pitti: Should I attach the debdiff for -8 at https://bugs.launchpad.net/ubuntu/+source/attr/+bug/1011639 or file a new merge request?
<ubottu> Launchpad bug 1011639 in attr (Ubuntu) "Please merge attr 1:2.4.46-8 (main) from Debian Unstable (main)" [Wishlist,Fix released]
 * vibhav thinks that we should have a requestmerge tool too
<pitti> vibhav: no need to send debian diffs; just the diff between current debian and your merged package
<vibhav> Didnt get you
<pitti> vibhav: oh, you mean "debdiff against -8"?
<vibhav> pitti: yup
<pitti> that's what I meant
<vibhav> pitti: I have attached it at #8
<vibhav> bilal: ping
<melodie_> hi
<smoser> bah.
<smoser> http://paste.ubuntu.com/1050861/
<smoser> anyone able to help with: mixed non-coinstallable and coinstallable package instances present
<smoser> that is the result of s/precise/quantal/ then apt-get dist-upgrade
<cjwatson> infinity: ^- looks like another regression from new dpkg
<vibhav> smoser: Probably a regression
<cjwatson> maybe this is one of the database corruption instances that Guillem obliquely warned about
<smoser> :)
<smoser> any suggestions on how to un-foobar?
<vibhav> Checking the soucre code of this error
<vibhav> "Sanity checks: verify that the db is in a consistent state." was all that could be understood by me
<cjwatson> smoser: before doing anything else, take a tarball of /var/lib/dpkg so that we can analyse it even if you (accidentally?) fix it
<cjwatson> and post that somewhere
<cjwatson> I believe the problem it's complaining about here is that you have >1 package of the same name installed (presumably different architectures), some of which are Multi-Arch: same and some of which are not
<cjwatson> but we'll need that tarball to look into it properly
 * cjwatson -> lunch
<melodie_> could someone give me a little information ? In a remix I am doing the vc (tty) is qwerty instead of french azerty. I found the file /etc/kbd/config where I could set it up : does someone know the exact syntax which must be used in it ?
<smoser> is there anything in /var/lib/dpkg that i should be weary of including ? ie, sensitive information?
<xnox> If I want to push something into quantal-proposed, how do i make sure somebody else doesn't copy it into quantal until it's ready?
<cjwatson> melodie_: No, you want /etc/default/console-setup instead
<vibhav> didrocks: ping
<cjwatson> melodie_: Er, sorry, /etc/default/keyboard nowadays
<melodie_> hi cjwatson ! thank you. I look what it looks like
<cjwatson> melodie_: say, XKBLAYOUT="us"  and  XKBVARIANT=""
<cjwatson> smoser: I wouldn't expect so, no
<melodie_> cjwatson: yes, I see it right in front of me ! great !
<cjwatson> xnox: We don't have a good way to inhibit promotion yet; that's one of the several outstanding problems with using -proposed more seriously
<melodie_> what is the syntax for variant, ie may I insert "latin-9" ?
<xnox> cjwatson: ok. I will stick with a ppa then.
<cjwatson> smoser: Unless you think your installed package list is sensitive
<cjwatson> melodie_: The available layouts and variants are listed in /usr/share/X11/xkb/rules/xorg.lst
<cjwatson> e.g.
<cjwatson>   intl            us: English (US, international with dead keys)
<melodie_> cjwatson: I look ! thanks a lot !
<cjwatson> indicates that you can use XKBLAYOUT="us" and XKBVARIANT="intl" and that's what it means
<smoser> hm.. well you might then find out that i have 'justin-bieber-fanclub' theme installed.
<vibhav> melodie_: What are your exact intentions?
<melodie_> I am doing a remix and I would like the vc to be fr instead of azerty in the live.
<cjwatson> Or you could use 'sudo dpkg-reconfigure keyboard-configuration' to reconfigure that file interactively
<melodie_> the first live I did has azerty in X but qwerty in tty's
<cjwatson> Oh, that sounds like just a bug
<cjwatson> They're supposed to always be in sync
<vibhav> yup
<melodie_> I can't file it, I would not know how to do that
<cjwatson> Unfortunately probably something painfully arcane in console-setup
 * vibhav wonders what package it could be
<cjwatson> vibhav: As I just said, console-setup
<melodie_> I have used a set of scripts having for name "ModCustom", which appears to work, whereas UCK failed without any clear clue in the build.log
<melodie_> it failed several times in a row... :/
<cjwatson> I bet running 'sudo setupcon' in a TTY switches TTY configuration to match X
<cjwatson> But that would have to be done on each boot - a permanent fix requires figuring out how to fix the bug
<melodie_> cjwatson: even in a chroot ?
<cjwatson> chroot -> irrelevant
<cjwatson> So this means that you can't actually select a different layout in VCs right now
<melodie_> I am working in a chrooted console, because I am now modifying the content of the build directory
<cjwatson> Because the very problem here is that the existing configuration is not being applied at boot
<cjwatson> You can't fix this by messing around with configuration files
<melodie_> cjwatson: this is why it's ok to edit files
<cjwatson> It's not *useful* to edit files here
<melodie_> ?
<cjwatson> The configuration for your system almost certainly already says that the layout is azerty
<smoser> cjwatson, bug 1015567, and /var/lib/dpkg.tar.gz  is in transit to launchpad (13M upload)
<ubottu> Launchpad bug 1015567 in dpkg (Ubuntu) "upgrade failed: mixed non-coinstallable and coinstallable package instances present" [Undecided,New] https://launchpad.net/bugs/1015567
<cjwatson> But it's not being applied correctly at boot
<melodie_> cjwatson: no the files says "us"
<melodie_> I mean
<melodie_> this file
<cjwatson> Oh, very odd that X has a French keymap then
<melodie_> the one you said
<cjwatson> It's supposed to pick that up from /etc/default/keyboard
<cjwatson> So the default for French in /etc/default/keyboard is usually meant to be XKBLAYOUT="fr" and XKBVARIANT="oss"
<cjwatson> I guess a naive remixing tool might have done something at some higher level
<melodie_> cjwatson: did you mean naive or native ?
<cjwatson> I meant naive
<cjwatson> or naÃ¯ve if you like
<melodie_> I would like to say a very good point for this ModCustom set of scripts : easy to use and a great fantastic feature : it can resume a work which has been interrupted !
<melodie_> it can even allow the person doing the remix job to reuse a work directory to add modifications. And this is fantastic !
<melodie_> it spares quite some work.
<melodie_> cjwatson: and thank you very much.
<cjwatson> np, hope I wasn't too confusing
<melodie_> really straightforward. :)
<melodie_> one more for the road ! (hips ! :p ) : where are located the files where the changes on the Unity panel launcher are stored ?
<melodie_> this is really bugging my curiosity, I didn't find any info on the web about it : is it related to gconf ? or else ?
<stgraber> melodie_: IIRC it's a gsettings/dconf key
<stgraber> melodie_: gsettings get com.canonical.Unity.Launcher favorites
<melodie_> stgraber: ah ha ! I have looked into dconf and was not able to guess which section it is related to
<melodie_> and gsettings has a set of commands I suppose ? Is there a documentation describing the use of this command tool ?
<stgraber> man gsettings and calling gsettings without any argument will give you the help
<stokachu> stgraber: team meeting today?
<stgraber> stokachu: yep, mumble in ~30min, then IRC in an hour
<stokachu> stgraber: cool thanks
<seb128> ev, hey
<ev> seb128: hi!
<seb128> ev, some whoopsie questions for you ;-)
<ev> sure :)
<seb128> ev, 1- is there any ignore list in whoopsie? like a "those bugs are known, they are harmless, we should stop bothering users about them"
<seb128> ev, I've a case of harmfless bug that is going to be hard to fix in precise, I would like users to stop getting "oops" dialogs about it, that ruins their user experience for no good reason
<ev> seb128: could I have a concrete example? If this is a desktop application, then we always want to show those dialogs, as they tell the user why the window just disappeared on them.
<seb128> ev, bug #858390
<ubottu> Launchpad bug 858390 in d-conf (Ubuntu) "nautilus crashed on startup in dconf_engine_refresh_user()" [High,Triaged] https://launchpad.net/bugs/858390
<seb128> ev, basically dconf hitting a bug because mmap doesn't work reliably on ecryptfs,nfs and we don't support XDG_RUNTIME_DIR
<seb128> ev, hum, good point
<seb128> that takes nautilus down :-(
<ev> yeah, nautilus is still going away by my reading of this
<seb128> ev, right
<ev> we need to convey why that happened, even if we can't fix it in precise
<ev> (and that's incidentally one of the reasons why we're careful not to promise things getting fixed)
<ev> or indeed giving them something they can follow
<seb128> ev, ok, second question ... is there any way to figure if those users are using ecryptfs?
<ev> seb128: once we get the metrics stuff operational, yes
<seb128> ev, any eta on that?
<ev> we'll be able to query against both data sets
<ev> it's scheduled for 12.10, but it may slip
<ev> definitely by 13.04
<seb128> ev, ok, thanks for the answers ;-)
<ev> sure thing!
<seb128> that was all for today (I think)
<ev> :D
<ev> you're always welcome to ask more
<seb128> ev, ;-)
<pitti> seb128, ev: NB that apport already tags bugs for users who use ecryptfs with "EcryptfsInUse=yes"
<pitti> by way of /usr/share/apport/general-hooks/generic.py
<ev> nice
<melodie_> have to reboot, thanks and bye !
<smoser> cjwatson, is there anything else you'd like in that bug report? i seemed to have gotten by the dpkg error by removing the entry for that package from /var/lib/dpkg/status at least for the moment.
<cjwatson> smoser: maybe whatever dpkg logs mention that package
<cjwatson> (I'm just triaging it though, hoping to not have to actually end up fixing it)
<seb128> pitti, is that reliable? does it show on errors.ubuntu.com as well (I guess it does, the detailed reports seem to be dumps of the apport files)
<pitti> seb128: it works for me, anyway
<pitti> seb128: it's what kirkland advised back then
<seb128> pitti, half of those bugs don't have it, but they could be using nfs and I don't think apport flag NfsInUse?
<pitti> seb128: we don't detect that, right; if you have a recipe for this, we can
<seb128> pitti, I will think about it, thanks ;-)
<mdeslaur> ugh, we're going to install the nvidia proprietary drivers by default?? I have a security support issue with that...
<mdeslaur> oh, with an option in ubiquity...ok, that's better
<dholbach> apw, nice blog post
<dholbach> apw, borrowed your last paragraph for the ubuntudev FB and G+ page :)
<apw> dholbach, :)
<jdstrand> mdeslaur: security support issue? Canonical supports restricted already-- or am I missing something?
<mdeslaur> jdstrand: we can't fix security issues in the binary driver, I thought it was going to get installed for everyone by default
<mdeslaur> jdstrand: but I guess an optional checkbox during install is ok
<jdstrand> mdeslaur: no *we* can't, but we are supposed to talk with upstream about those sorts of things. I agree that not by default is preferred generally speaking, but I imagine at some point that will slip to checked by default...
<mdeslaur> jdstrand: upstream only supports their current driver, which may not work on older cards...
<mdeslaur> jdstrand: when we push an update, we'll most certainly break people...using the open source driver as default for a majority of users is the better choice
<jdstrand> mdeslaur: I don't disagree-- I was merely being a pessimist :)
<jdstrand> you know, it's the security way ;)
<mdeslaur> hehe
<kees> any progress on making /dev/nvidia* not world-writable?
<mdeslaur> kees: not yet, no
<mdeslaur> kees: I've just assigned myself to that bug (LP: #979307)
<tedg> pitti, Is there a place where I can just download the DB/config for status.ubuntu.com ?  (want to test a patch)
<pitti> tedg: yes, http://status.ubuntu.com/ubuntu-quantal/ubuntu-quantal.db
<pitti> likewise for precise
<pitti> tedg: the config is in lp:~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config
<tedg> pitti, Cool, thanks!
<rtg> hallyn, does it make sense for qemu-kvm to be 'Architecture: any' ? The description implies that its for x86 only.
<hallyn> rtg: at least powerpc is supposed to support kvm, and eventually arm too.  historically we've compiled it without acceleration for those, but built it
<hallyn> i'm hoping to get it built with acceleration for powerpc, but haven't yet
<rtg> hallyn, well, its failing on all of those arches.
<hallyn> rtg: yes, i'm working on it
<rtg> hallyn, ack
<xnox> ev: googletest might not work for C at all. It's for C++ =( http://stackoverflow.com/questions/7668510/can-we-use-googletest-gtest-to-test-c-code
<hallyn> rtg: i'd happily not build for those arches, but was afraid someone would miss them
<rtg> hallyn, they're gonna miss 'em anyways if they don't build :)
<ev> xnox: http://code.google.com/p/test-dept/wiki/TestDept looks interesting
<hallyn> SpamapS: the cgroups-mount and cgroups-umount should be moved from /usr/bin to /bin.  Any objections to SRUing that?
<hallyn> (this is to support systems with separate /usr)
<xnox> ev: hmmm... after you do the ground work, I'd be happy to pick up =)
<ev> xnox: :)
<xnox> ev: btw what does upstart use for it's intensive test-suite? anything in / for C ?
<ev> xnox: libnih has testing functions, if I remember correctly
<xnox> ev: pre-arranged. hmm.
<ev> but nothing that does function replacement ( jodh do correct me if I'm wrong)
<SpamapS> hallyn: can we keep a compat symlink in /usr/bin ?
<SpamapS> hallyn: I worry about people who have automated with full path
<cjwatson> upstart adopts a coding style where testing it doesn't really need a lot of function replacement, I think
<cjwatson> if I were in the mood for an argument I would say that needing function replacement is a sign that your code is structured wrongly :-)
<hallyn> SpamapS: those scripts are only (meant to be) used by the upstart jobs...
<hallyn> but i can do symlinks :)
<SpamapS> hallyn: your call.. if you think people wouldn't have hard coded them, then a move is fine.
<SpamapS> hallyn: but I'd feel better, and I don't see a problem with it, if there were symlinks
<hallyn> SpamapS: great, thanks.
<stokachu> xnox: o/
<xnox> stokachu: \o
<xnox> high-five ;-)
<stokachu> lol
<stokachu> so re: apt, does it actually apply patches in lucid building somehow?
<xnox> stokachu: nope
<cjwatson> it's a native package, they don't usually use patch systems
<stokachu> ah ok.. so just update the code and commit then build again?
<cjwatson> yes
<stokachu> sounds good! thanks
 * xnox feels information overload after the meeting
<stokachu> xnox: org-mode is my savior
<ev> cjwatson: generally I would agree, but I'd like to test the point where things intersect. And I can see no way to structure code to make those easy to test, short of passing in a struct of function pointers
<xnox> stokachu: yeah, doesn't work that well for me. I don't embrase GTD, so don't set deadlines, and it just piles up with cruft.
<xnox> plus my org-mode is mostly spammed with personal stuff. Need to better configure work/non-work items
<stokachu> xnox: lol, sounds like how i handle things i dont understand.. "get rid of it"
<bdmurray> infinity: you'd said link to the build pages with sru-sccept?  https://bugs.launchpad.net/ubuntu/+source/cron/+bug/794082/comments/7
<ubottu> Launchpad bug 794082 in cron (Ubuntu Lucid) "cron ignores /etc/default/cron" [Undecided,Triaged]
 * xnox still want's to browse through all the bugs stokachu linked at during the meeting. at least to see if anything interesting tickles my fance
<stokachu> xnox: there are a couple ugly multi-arch ones, but the rest is just administrative stuff
<xnox> hmmm, ok.
<stokachu> getting sru's written and formatted patches
<xnox> stokachu:  did you know that there is 5.0.4-3.1ubuntu5.2 autofs sitting in Lucid's SRU queue for 301 days now
<xnox> stokachu: can you validate it?
<xnox> stokachu bug #578536
<ubottu> Launchpad bug 578536 in autofs5 (Ubuntu Natty) "when stopped, automount orphans some mounts" [Medium,Fix committed] https://launchpad.net/bugs/578536
<stokachu> xnox: so we need to invalidate that sru
<xnox> stokachu: why?
<stokachu> xnox: the patch i sent to be tested overwrites that one
<stokachu> that was done before i even touched the case
<stokachu> also re: #23 doesn't look like it fixed it
<xnox> stokachu: ah, so superseed with 5.3 then
<stokachu> yea
<xnox> .*ubuntu5.3 that is =))))
<stokachu> what autofs version is in oneiric
<stokachu> 5.0.5?
<xnox> stokachu: rmadison is your friend
<xnox> http://paste.ubuntu.com/1051200/
<stokachu> nice.. what is rmadison :X
<xnox> rmadison $package
<xnox> stokachu: in ubuntu it would be probably called: distro-series-version-checker
<stokachu> xnox: nice
<stokachu> i wouldve never guess rmadison
<xnox> stokachu: it's Remote query tool of MADISON....
<xnox> stokachu: it's a script from debian, all archive scripts in debian are named after human names.
<stokachu> gotcha
<xnox> e.g. britney, madison, ana, a few others
<xnox> there is bob as well
<stokachu> never forget about bob
<cjwatson> madison is 'dak ls' in Debian now, but the name stuck
<xnox> cjwatson: and rmadison needs to be added to the 'geek names for your child'
<xnox> book
<infinity> bdmurray: Oh, indeed, there's a chicken and egg issue with actually linking to builds before they've been completed. ;)
<infinity> bdmurray: Or, rather, before they've been created.
<infinity> bdmurray: But linking to the versioned source page (as you've done there) seems reasonable.
<bdmurray> infinity: well plus I wouldn't want to link to every arch's build
<infinity> Ahh, I see USNs have switched to just linking to the source version too.
<infinity> bdmurray: So, my only complaint would be the wall-o-text.  Could perhaps be formatted a bit nicer.
<bdmurray> infinity: okay, thanks
<zul> i sent an email to the tech board can someone unmoderate it please? thanks
<cjwatson> zul: done
<zul> cjwatson: thanks
<rtg> --:1
<jtaylor> doko: do we really need that diff: https://launchpad.net/ubuntu/+archive/primary/+files/mpich2_1.4.1-1build1_1.4.1-1ubuntu1.diff.gz
<jtaylor> blcr is broken since natty anyway
<dupondje> any idea when new kernel will be accepted from queue ?
<dupondje> want to upgrade :)
<dupondje> lamont: any chance on new bind9 in debian ?
<dupondje> mdeslaur: can you patch bind9 in quantal ? :)
<mdeslaur> dupondje: lamont is supposed to update to a newer version soon
<mdeslaur> lamont: any ETA?
<dupondje> aha ok, cause now precise -> quantal is a downgrade
<mdeslaur> dupondje: yes, but it's synced from debian...I don't want to introduce a delta if lamont's going to upload a new version soon
<dupondje> yea sure :)
<dupondje> delta shouldn't be a problem imo, if its simple, it can be synced again
<seb128> dupondje, downgrades are not possible, soyuz wouldn't accept a lower version
<seb128> nor would apt downgrade you
<dupondje> seb128: apt will not downgrade indeed :)
<dupondje> but current bind9 version in quantal is lower then in precise
<Laney> isn't it usual for those kind of security uploads to be copied up to the dev release?
<Laney> or uploaded
<mdeslaur> Laney: we have a procedure...we either merge from debian, or submit the patch to debian and merge, and if we think it'll take a long time, we will upload to the dev release
<mdeslaur> In this case, lamont, the debian bind9 maintainer said a new upload was imminent
<Laney> mdeslaur: ok
<dupondje> so we just need to pull lamont's ears ;)
<mdeslaur> as it's not happened yet, I'll upload to quantal in a few minutes
<Laney> is there a report which tracks packages in this state?
<dupondje> there is another one: https://launchpad.net/ubuntu/+source/xen
<dupondje> ^^ smb` ?
<mdeslaur> well, for security updates, our tracker lists quantal as not being fixed...but we don't specifically have a report to indicate if a package in the dev release is older than the stable release
<mdeslaur> unless someone else does
<Laney> well, that one's only 2 days
<dupondje> mmm yea :)
<dupondje> anyone knows the status on kmod ?
<geser> there is a merge of our current delta needed, don't remember who had it on his TODO list
<dupondje> geser: for kmod ?
<geser> dupondje: yes as it replaces the current tools which has ubuntu delta
<dupondje> hmz ok, cause https://launchpad.net/ubuntu/+source/kmod hasn't been in ubuntu yet
<dupondje> which makes oss-compat uninstallable from the start ...
<geser> it can't be synced as it replaces module-init-tools which has changes which need to be checked and applied to kmod too
<lamont> dupondje: trying to figure where to put bind9 (and nmap, tbf) into my schedule this week.  It may turn out to be saturday.  I'm hoping that it's tomorrow night
<lamont> mdeslaur: ^^
<mdeslaur> lamont: ok, cool...thanks...I'll wait then
<geser> dupondje: slangasek wanted to look at kmod
<dupondje> geser: ok :) lets remind slangasek then ;
<dupondje> also kernel is uninstallable atm, but guess somebody will accepted it from the queue I guess :)
<bambee> http://paste.ubuntu.com/1051451/  <--- circular dependency on itself ?
<bambee> (on quantal)
<dupondje> hallyn: update-rc.d: warning: /etc/init.d/qemu-kvm missing LSB information
<dupondje> fyi :)
<geser> bambee: where? note the missing -dev in the package name in line 12
<bambee> woo good catch
 * bambee is tired v_v
<slangasek> dupondje: cryptsetup sync> wow, interesting
<slangasek> I wonder if the cryptsetup upstart jobs work in Debian
<mdeslaur> dupondje: bind9 uploaded to quantal, FYI
<bambee> additional informations: http://paste.ubuntu.com/1051474/
<geser> bambee: any specific reason why you don't try the multi-arch package? "sudo apt-get install libc6:amd64" (note the : instead the -)
<hallyn> dupondje: weird.  that should be autogenerated as an upstart wrapper
<hallyn> thanks
<dupondje> slangasek: yea sync is good, all ubuntu changes are in the debian package :d
<dupondje> hallyn: just noted it on upgrade so :D
<dupondje> mdeslaur: thx
<dupondje> slangasek: you'll check kmod ?
<slangasek> dupondje: yes, though not today
<dupondje> great! :)
<arges> cyphermox, hello. looking at pad.lv/872824. would it make sense to at least try to get a proper PPA going and do some tests? or what do you think would be a good approach?
<cyphermox> arges: way ahead of you, package is almost ready
<arges> cyphermox, oh awesome
<arges> cyphermox, : )
<cyphermox> ppa:mathieu-tl/nm
<dupondje> Do we have bumblebee or something as default now in Quantal ? or
<cyphermox> arges: so I just uploaded a package for precise
<arges> cyphermox, in -proposed?
<cyphermox> arges: ah, sorry, no, I mean in my PPA: ppa:mathieu-tl/nm
<arges> cyphermox, ok cool.. i'll make sure that gets tested
<cyphermox> thanks
<arges> : )
<kees> SpamapS: zul says "Clint Byrum is on the SRU team and he can vouch for these packages." :) you feel Nova, Glance, Horizon, and Keystone are in good shape?
<SpamapS> kees: I think upstream's processes are far more capable of stopping regressions than our SRU process...
<SpamapS> kees: I won't speak to how bug-free the software is.. but I don't think it will regress on micro releases
<kees> SpamapS: okay, thakns
<zul> kees: i think we are in the position to spot regressions before uploading to -proposed with our testing that we do as well
 * kees nods
<kees> seems like it's in a good shape overall. I've emailed to that effect. I'd like to hear from at least 1 other TB member before making it official.
<SpamapS> kees: any need for me to email?
<stgraber> cjwatson: can you moderate my message to ubuntu-devel-announce (DMB meeting minutes)?
<micahg> slangasek: cjwatson: stokachu: re bug bug 977940, sorry, I snagged it for sponsoring, but it got lost in my stack, if it's urgent, feel free to resteal, otherwise, I'll try to get to it when I finish my pilot sponsoring this time around
<ubottu> Launchpad bug 977940 in gnome-vfs (Ubuntu Precise) "Please transition gnome-vfs to multi-arch" [Medium,In progress] https://launchpad.net/bugs/977940
<kees> SpamapS: nah, thanks.
<cjwatson> stgraber: done
<dupondje> Do we have something to support Optimus now in Quantal ?
<stgraber> cjwatson: thanks
<infinity> TheMuso: Do you plan to bring the linux-lowlatecy package in quantal into the present?
 * micahg wonders what happened with the kernel team adopting that as a flavor
<Caesar> Hi, I'd like to get a newer version of audit into quantal, and getting it into Debian first isn't looking doable with the imminent freeze and a library transition being needed
<Caesar> How are library transitions handled in Ubuntu?
<Caesar> (audit is in universe fwiw)
<geser> now large is the transition?
 * micahg was going to suggest speaking to the Debian release team as it seems to only have 2 rdeps (at least in UBuntu)
<ajmitch> reverse-depends on libaudit0 looks pretty small
<micahg> slangasek: why not just use lsb_release and a .in file in devscripts to autogenerate the release it's on?
<TheMuso> infinity: I thought there were plans to possibly integrate lowlatency into the main kernel package, depending on whether the kernel guys could get rid of other kernels. But since that doesn't appear to be happening yet, yes I'll attend to it in the coming days.
<infinity> TheMuso: It was still an "in discussion" deal, I believe.  I think we all expected the -lowlatency source to continue to be maintained up until that discussion reached fruition. :)
<infinity> TheMuso: But hey, you successfully skipped the entire 3.4.x cycle, and get to jump from 3.2 to 3.5!
<TheMuso> Right
<TheMuso> I really need to get the studio guys to take t over.
<infinity> Yeah.
<infinity> Given what it is, it should be trivial for them to merge against master every ABI bump.
<infinity> (Yeah, easier still if it can be integrated, but that requires changing the patch to be a config option, config review, etc, etc)
<Bluefoxicy> are /var/spool/cron crontabs run by default?
<Bluefoxicy> 0 * * * * root fstrim /
<Bluefoxicy> 0 * * * * root fstrim /home/_vm/
<Bluefoxicy> I have this in /var/spool/cron/crontabs/root, but I just manually ran those commands (it's been in there for months) and a LOT got discarded.  Not a lot of activity really goes on on /home/_vm/
<Bluefoxicy> I can only surmise that this wasn't run at midnight last night (there aren't actually any VMs running atm, so there's no activity on that partition)
<Bluefoxicy> trying to figure out if this is normal behavior (on Precise) or a bug
<slangasek> micahg: <shrug> no objection if you want to write it; I was just restoring the previous code
<cjwatson> dobey: Please to be evicting python-support from ubuntuone-control-panel again?  We don't want it in main.
<Bluefoxicy> oh I'm stupid nm.
<Bluefoxicy> i don't need the username, so it thinks 'root' is a command.
<Bluefoxicy> the bug is me :|
#ubuntu-devel 2012-06-21
<stokachu> micahg: thanks, yea its targetted for 12.04.1 but ill keep an eye on it and if you can't get to it by next week ill make sure to get it handled
<micahg> stokachu: well, if you just make sure the current debdiff works on quantal so when I go to sponsor, I don't run into issues, that would be great
<stokachu> micahg: sure ill do that
<micahg> stokachu: thanks
<stokachu> np thank you :)
<infinity> micahg: Looks like firefox/thunderbird is another case of "using the buildd to determine the target arch".
<infinity> micahg: Which means they're getting it wrong on armhf too (I see a NEON define in there, for instance)
<micahg> infinity: awesome :), well, cross building probably isn't a priority for upstream, but they'd probably take patches
<infinity> Building for a generic target isn't "cross-building".
<infinity> If all their Windows builds emitted SSE3 instructions, they'd be just as miffed. :P
<infinity> But people seem to make these mistakes on ARM a lot more than x86.
<infinity> Anyhow, I might look at it later.  The build log just showed me it was doin' it wrong.
<micahg> infinity: heh, ok, well, I'm sure chrisccoulson would love a patch for that
<dobey> cjwatson: doh. sorry about that. uploading fix now
<stokachu> micahg: i got that debdiff attached to 977940, let me know if there is anything else I can do to help
<micahg> stokachu: oh, thanks, I just wanted to make sure it built :)
<stokachu> micahg: yea it builds
<vibhav> cjwatson: you there?
 * xnox at 4AM ?!
<vibhav> Ah, Time Zones :(
<infinity> Timezone, timeschmones.
<TheMuso> For the insane among us perhaps, but I like my sleep.
<micahg> heh, sleep, was nice once upon a time
<TheMuso> I guess one factor for me is that I am a morning person.
<xnox> TheMuso: well, I'm up at 4AM ;-)
 * xnox went to bed at 8PM and now woke up
<TheMuso> As I said, for the insane among us. :)
 * xnox is fiddling with cdbs
<xnox> ah, are you in ~ 4AM as well ? =))))
<micahg> xnox: you're still asleep, stuck in a nightmare :)
<TheMuso> No, its 13:22.
<TheMuso> On a Thursday.
<xnox> TheMuso: are in australia / japan or something?
<TheMuso> Sydney Australia.
<xnox> micahg: =((((
<vibhav> Its 9 Am here
<micahg> xnox: that's what fiddling with cdbs at 4AM sounds like to me :)
<ajmitch> micahg: s/4AM/any time/
<nigelb> ajmitch: lol
<vibhav> nigelb: hehe
<xnox> micahg: you are so judgemental =)
<infinity> xnox: Being judgemental doesn't make him wrong.
<micahg> xnox: I would think 90% of maintainers agree :) http://upsilon.cc/~zack/stuff/dh-vs-cdbs/
<pitti> Good morning
<ajmitch> morning pitti
<micahg> hrm ,about 15% of main uses cdbs
<xnox> micahg: cdbs supports flavors. Running VPATH builds with different configure flags for each build: e.g. full, minimal, udeb, etc...
<xnox> micahg: simply specify a list of flavours & configure flags for each one ;-)
<micahg> xnox: that doesn't mean that it's not a bear to use :)
 * xnox =(
<xnox> pitti: Good morning, I'm about to go back for my second half of sleep ;-)
<pitti> hey xnox, how are you?
 * micahg just read an article about that
<xnox> pitti: good good, went to bed early woke up in the middle of night =)
 * vibhav wonders how large coffee cups devs have
 * micahg goes to get some tea
<xnox> vibhav: 0.35ltr
<xnox> http://shop.canonical.com/product_info.php?products_id=828
<xnox> I also have the previous cup, it's less capacity
<xnox> was a nice upgrade =)
 * vibhav drools
<pitti> xnox: congratulations to your new core-dev badge!
<xnox> pitti: thank you.
<xnox> although i would still like code review before uploading core stuff
 * xnox doesn't want to be the guy who broke quantal
<infinity> xnox: Don't worry, that's me currently.
<micahg> xnox: knowing when to ask for help is important, no one knows everything
<vibhav> infinity: By breaking, you mean dpkg, right?
<infinity> vibhav: Indeed.
<micahg> infinity: don't worry, it falls under the title of uploader of eglibc :)
<infinity> micahg: I only break eglibc in Debian.
<infinity> micahg: Well, so far.
<vibhav> hehe
<xnox> vibhav: technically, whoever merged early multi arch support way back in precise (??) broke dpkg
<infinity> Maybe I'll break it in Ubuntu with the next upstream.  Stay tuned.
<micahg> infinity: I meant breaking the archive, it's all encompassing :)
<infinity> xnox: natty.
<xnox> infinity: was it still you?!
<infinity> xnox: We've been multiarching for a long time.
<infinity> xnox: And no, it wasn't me.
 * xnox BINGO!
<micahg> xnox: nope, not at all, the dpkg implementation multiarch changed after we introduced it
<infinity> And what he said.
<infinity> I'm still trying to sort out what the guard is preventing.
<infinity> So, if you have a non-ma-same package in an rc state, and you want to install an ma-same version from another arch, it flips out.
<infinity> That seems fair.
<xnox> infinity: I think the brain damage of having 3 packages installed: pkg        pkg:i386      pkg:amd64
 * ajmitch should try & upload some packages tonight
<infinity> But wouldn't that be exactly the same situation if you have an old ma-same version in rc, and want to install a new on from another arch?
<infinity> There's still a chance of whacky conflict.
<infinity> xnox: But if it's just a mapping issue, we can kludge it the same way we did for triggers.
<infinity> xnox: noarch = native, done.
<xnox> yeap, but the files in the non-multiarch location must be identical
<xnox> across all architectures
<infinity> xnox: Yes, but they're NOT identical in the ma-same-rc plus ma-same-install case either.
<xnox> noarch = native, will not help with triple arch
<infinity> xnox: Eh?  it's not triple arch once you've mapped it.
<xnox> infinity: if they are not, then it's an RC bug against the package. There were a few of those recently
<infinity> xnox: pkg = pkg:native
<infinity> xnox: No, no.  You're missing the point.
<xnox> infinity: as it pkg = pkg:native will not help if you have i386, amd64 and armhf multiarches enabled
<infinity> xnox: You remove libfoo:i386, it poops conffiles.  You later install a NEWER version of libfoo:amd64.  That's no guarantee of identical anything anymore.
<infinity> xnox: If you have ma-same stuff installed this doesn't trigger.  It's only for the old skool pre-ma packages this is an issue, which is where you map noarch=native.
<xnox> true
<infinity> xnox: And, in that case, I fail to see how it's then any different from the scenario I paint above, with different versions.
 * xnox needs to read multiarch spec again, what ma-same means
<infinity> xnox: M-A:same means paclages can be co-installed.
<infinity> xnox: So, most multiarch libraries.
<micahg> infinity: I think the issue is without the package being marked m-a:same, there's no guarantee the conf files won't conflict
<infinity> xnox: And this error specifically trips on M-A:same + pre-M-A-rc
<infinity> micahg: There isn't anyway.
<infinity> micahg: It's tripping on a REMOVED (but not purged) package.
<micahg> infinity: yes, but I think that's what it's trying to guard against
<infinity> micahg: You can't enforce the contents of mismatched packages.
<xnox> and one of the requirement is that they (a) do not install anything in non-multiarch qualified locations (b) if the do install anything outside => they must be identical across all arches. So yeah, I see your point that rc should not matter, unless it's in like /usr/lib/$ANY_TRIPLET/libc6.so
<infinity> micahg: Like i said, this is (afaict), no different than having a removed libfoo1:i386_1.2.3-1 and then installing a new libfoo1:amd64_1.2.3-2
 * xnox wants to create config file /usr/lib/$ANY_TRIPLET/libc6.so for giggles
<micahg> infinity: right, but maybe it's trying to do some conf file handling in some futile fashion (my best guess ATM)
<xnox> infinity: well multiarched libraries do not ship conf / conffiles
<infinity> xnox: I'm trying to wrap my head around how noarch=native would break things here (or, be any worse than the situation I've outlined above), but I suspect it's the way forward for now.
<slangasek> infinity: so dpkg should regard the m-a: same package as implicitly replacing, and therefore taking over, any conffiles?
<infinity> micahg: Even if it is, I don't see how the arch matters.
<infinity> slangasek: Why not?  That's what it does on newer-same -> older-same?
<infinity> slangasek: If so, I don't see why new-same -> old-non-same should be different.
<micahg> infinity: it might be worried about the old conf file being broke in the multiarch world
 * xnox want's to look at the sample dpkg tarball from the bug to see what library shipped a conf file in the first place
<infinity> slangasek: Whatever it's doing in the old->new (but both same) scenario, that seems the sane thing to do for non-same->same.
<infinity> micahg: That's just weird speculation.  It's a package's job to upgrade its broken conffiles, not dpkg's job to guess.
<xnox> infinity: will that break upon people trying to use multiarch to do a cross-arch dist-upgrade / reinstall to migrate from i386 -> amd64
<infinity> xnox: For one, that's not even remotely supported.  For two, how does it break it?
 * xnox ponders
<micahg> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676496 ?
<ubottu> Debian bug 676496 in dpkg "dpkg: premature removal of "Multi-arch:" leads to all dpkg commands failing" [Grave,Fixed]
<xnox> it won't because there is only on :native at a time.
<xnox> it won't because there is only one :native at a time.
<infinity> micahg: Hrm.  That isn't the same bug/misfeature, is it? :P
<micahg> infinity: not exactly, but looks like it might be close
<infinity> No, definitely not the same bug.
<micahg> I figured it might give some hint on where to look
<infinity> Don't think it relates, really.
<infinity> But I should merge that version...
<xnox> infinity: if the new libfoo:native does not ship the config file anymore, and for example that file got moved into an foo:all package, that stale rc file will be removed?
<xnox> libfoo:native is now ma-same, old libfoo is not.
<infinity> xnox: To be honest, I'm not sure what happens, but I don't see why it should be any different than in the mismatched-versions-of-ma-same-packages case, do you?
<infinity> There's no reason to assume that a migration a removed libfoo between and old non-ma version and a new ma-enabled version will be significantly more broken than between, say, two wildly skewed but both ma-same versions.
<infinity> s/migration a/migration of a/
<xnox> infinity: have you seen that in the bug 1015616 the problem got resolved by adding :native to the culprit packages
<ubottu> Launchpad bug 1015567 in dpkg (Ubuntu Quantal) "duplicate for #1015616 upgrade failed: mixed non-coinstallable and coinstallable package instances present" [High,Triaged] https://launchpad.net/bugs/1015567
<infinity> xnox: Actually, he added M-A:same headers, but the end result internally in the pkgset logic would be the same.
<infinity> xnox: Anyhow, I've thought too much about this for today, but if you come up with any snazzy ideas that you want to talk over, I'll be awake sometime tomorrow. ;)
<xnox> infinity: the kicker is that the conffile was not modified, it's untouched in both packages of the bugreporter
<xnox> infinity: i'd just pre-purge those packages
<infinity> xnox: I don't see why modified or not should matter, really.
<xnox> no data loss ;-)
<infinity> There's no data loss if you do a conffile takeover either.
<xnox> if it fails with an rc package, would it also fail with an installed one?
<infinity> Which is exactly what happens if you go "old i386 package removed" -> "new amd64 package installed" of different versions, with a modified and shared conffile.
<infinity> xnox: With an installed one, it will force the upgrade.
<infinity> xnox: Cause the versions have to match.
<xnox> right.
 * xnox has no concerns about going for rc -> :native
<infinity> It seems like the sane way to go.
<infinity> Might make your eyes bleed a bit sorting out where to do that.
<xnox> infinity: are you doing the new merge first though?
<infinity> Tracing back from the error message, and stepping back through every function until you get to the one that seems reasonable to fix. :P
<xnox> or not.
<infinity> xnox: I won't be merging tonight.  Shouldn't impact your fix anyway.
<xnox> ok
 * xnox off to sleep for shorter second half, before starting my day
<infinity> xnox: Or, you can just merge if you like.  MoM actually got it right, except for a conflict in control.
<xnox> hmmm. ok
<infinity> xnox: (I assume due to the fiddling with xz-utils and lockfile deps)
<infinity> Actually, since MoM got it right and I just need to eyeball it, I'll just upload this now.
<xnox> still needed after precise, or is it to be backports safe?
<infinity> And you can do your stuff when you wake up.
<xnox> great. deal.
<infinity> We don't aim to backport dpkg.
<micahg> infinity:  MoM has a useful ../merge-buildpackage script :)
<infinity> micahg: Hrm?
<micahg> it calls its useful merge-genchanges script to auto add the -v from the previous Ubuntu verison :)
<micahg> *version
<infinity> micahg: Oh, I missed the -v after I went and added more changes.  Silly me.
<infinity> micahg: Oh well.
<infinity> jbicha_: Thanks for updating UML!
<RAOF> But there *are* to AAs who have been active in #ubuntu-release in the last 10 minutes or so âº
<RAOF> Imagine that went into #ubuntu-desktop, where it was intended.
<infinity> RAOF: Hahaha.
<infinity> RAOF: What needs AAing?
<robert_ancell> infinity, new package bug 1011361
<ubottu> Launchpad bug 1011361 in Ubuntu "[needs-packaging] libpwquality" [Wishlist,Triaged] https://launchpad.net/bugs/1011361
<infinity> robert_ancell: Ahh, doing a NEW source review probably isn't on my list of things to do at 23:30, I'll punt.
<robert_ancell> infinity, fair enough
<infinity> robert_ancell: But if no one's looked at it before tomorrow, you can give me a gentle nudge.
<cjwatson> dobey: thanks
<jibel> pitti, the crash I get while reporting a bug seems to be https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1015788
<ubottu> Launchpad bug 1015788 in apport (Ubuntu) "All the apport crash reports are now "*** Error: Invalid problem report" - TypeError: startswith first arg must be bytes or a tuple of bytes, not str" [Undecided,Confirmed]
<pitti> jibel: ah, that's not the one in DKMS again
<pitti> jibel: I just fixed bug 1007826, currently fixing dkms, will then look at that one
<ubottu> Launchpad bug 1007826 in apport (Ubuntu) "crash with AssertionError: file stream must be in binary mode when trying to save report to file" [High,Fix committed] https://launchpad.net/bugs/1007826
<pitti> jibel: could you please add what command you were trying to run?
<jibel> pitti, right, it's different. dkms crashes which triggers apport which in turn crashed with the "invalid problem report" dialog
<dholbach> good morning
<enrico> Why is http://paste.ubuntu.com/1052137/ requiring me to log into launchpad to download the patch as text?
<pitti> so that you cannot abuse it to anonymously store tons of data there (a la filesharing)
<enrico> pitti: couldn't that have been done like any other pastebind does, or requiring the login only for contents >100Kb? I've been pushed that patch to be applied in Debian, not Ubuntu, and I find it ridiculous that I need to have a launchpad account in order to have a version that I can feed to patch
<pitti> >100 kB sounds sensible indeed
<pitti> enrico: need the patch? I can put it someplace else for you
<enrico> pitti: thanks, copypaste seems to have done TRT
<cjwatson> enrico: #canonical-sysadmin would be the place to complain about it - #ubuntu-devel doesn't admin the pastebin
<enrico> cjwatson: any reasonable place I could file a bug instead?
<cjwatson> I don't know, sorry
<cjwatson> If there were, it would require a Launchpad account ;-)
<smb> dupondje, For the Xen package I am waiting for the review of my merge. The current version in Quantal is only there because of the initial pocket copy done. It would not compile in Q.
<enrico> cjwatson: I should still have a launchpad account I can use to report bugs; my problem is being forced to use it when doing things that are not ubuntu-specifc
<cjwatson> sure
<Laney> enrico: cjwatson: I once filed an RT about that and it was denied
<diwic> Laney, for what reason? I'm curious, because I've got complaints from my upstream friends about it too.
<bkerensa> anyone know why Quickly is install two versions of glade and potentially two versions of the depends for each version of glade?
<bkerensa> on Quantal
<Laney> diwic: enrico: https://rt.ubuntu.com/Ticket/Display.html?id=18758
<Laney> (yes, you probably need to log in to see that â¦)
<cjwatson> guest/guest IIRC
<cjwatson> or maybe ubuntu/ubuntu
<cjwatson> the latter
<cjwatson> ... oh.  it used to be.  I guess it's all SSO now?
<enrico> cjwatson: none of those. Now trying to work out how SSO works
<Laney> using the same credentials as LP
<enrico> Laney: found it, and sigh.
<Laney> I just default to paste.d.n now
<cjwatson> I'm sure most people supplying pastes would be happy to do so in a more convenient way if requested
<enrico> Laney: I did indeed resolve to ask the person not to use paste.ubuntu when sending stuff to non-ubuntu developers
<diwic> Laney, thanks
<diwic> Laney, although I'm a little surprised that the spammers can't use the non-login version as well (just strip away some html code)
<bkerensa> barry: do you know why might be installing two versions of glade?
<bkerensa> quickly*
<dupondje> smb: ok great :)
<pitti> cjwatson: yay, thanks for change-override
<xnox> good morning =)
<cjwatson> pitti: You're welcome :-)
<cjwatson> pitti: Do you know if it's been necessary to run firefox-overrides in recent times?  I have a feeling that the override ancestry bug that prompted that has been fixed
<pitti> cjwatson: I have never used that oen
<pitti> one
<pitti> chrisccoulson, micahg: ^ do you know about this?
<cjwatson> https://wiki.ubuntu.com/ArchiveAdministration#Publishing_packages_from_the_ubuntu-mozilla-security_public_PPA FWIW
<cjwatson> That script needs to be moved to client-side, but if it's no longer needed then I would be just as happy to remove it
<micahg> pitti: I didn't know there was such a thing :)
<cjwatson> OK, I'm going to take a punt and say that this has been fixed - the LP copying code looks up the new ancestry of binary packages it copies and tries to apply matching overrides
<pitti> at least in precise and quantal, all binaries are in main anyway
<melodie_> hello
<cjwatson> This doesn't work for the kernel because package names tend to change, but it should be fine for firefox
<micahg> cjwatson: lately, the only thing that needs overrides are new binaries
<pitti> in oneiric, -mozsymbols is in universe
<pitti> and so it is in oneiric-updates
<pitti> so whavever is done for those, it works without that script apparently
<pitti> cjwatson: *nod*
 * cjwatson looks up the publishing history for that to check
<pitti> cjwatson: even for the kernel, all packages that don't change keep their component
<micahg> well, there was some work done to make copies to the archive end up in the proper component
<micahg> or rather make copies respect existing components
<cjwatson> I think that's what I'm referring to above
<cjwatson> Assuming you mean work in LP as opposed to per-upload work
<melodie_> I'll bb
<micahg> yes
<cjwatson> lib/lp/soyuz/adapters/overrides.py:UbuntuOverridePolicy is applied to binary copies, and looks like it should be right
<cjwatson> And I've confirmed that none of the BPPHs for firefox-mozsymbols in oneiric since at least mid-March have been anywhere except universe
<melodie_> hi
<micahg> cjwatson: that's good news re: binaries ending up where they belong
<melodie_> I am looking for a simple way to update with packages coming from another machine (a place where the connection is much faster). I failed when trying to just copy the apt directory from /var/cache : is there a simple way to do that ?
<cjwatson> /usr/share/doc/apt-doc/offline.html/index.html talks about this
<cjwatson> Don't know how current it is but my guess is it should require at most minor adjustments
<melodie_> hi cjwatson, I look, thanks
<melodie_> cjwatson: there is no "apt-doc" directory in /usr/share/doc in precise
<melodie_> I am going to try to cheat and put the packages in the "partial" directory
<cjwatson> melodie_: That's because you don't have the apt-doc package installed.
<melodie_> It looks like it wants to work.
<melodie_> cjwatson: you are probably right. well, putting the packages from /var/cache/apt/archives to /var/cache/apt/archives/partial, then "apt-get update && apt-get dist-ugrade" seems to work. I'll know in a moment when the unpacking and replacing will be finished.
<melodie_> bbl
<infinity> rbelem: And progress on the new snapshot for plasma-mobile?
<jdstrand> cjwatson: fyi, I wrote that bit in AA for firefox some time ago. while firefox hasn't needed it for quite sometime, it seems I have had to use it on rare occasion for non-kernel stuff
<jdstrand> cjwatson: however, I think it is fine to remove it-- it is really just my team and the SRU team that use it
<jdstrand> my team knows about it and the SRU team has a documented process for the kernel still anyway
<cjwatson> jdstrand: Well, you have find-bin-overrides still; firefox-overrides was hardcoded to firefox so was clearly of no use
<cjwatson> jdstrand: When you next see this for something that isn't the kernel, I'd like to hear about it
<cjwatson> jdstrand: There's still a section below explaining the use of find-bin-overrides
<jdstrand> cjwatson: oh, I missed we were talking about firefox-overrides and not find-bin-overrides. yes, I haven't used firefox-overrides in ages
<jdstrand> and yeah, the section below on find-bin-overrides was what I was referring to with "the SRU team has a documented process for the kernel"
<cjwatson> I'd still like to know about non-kernel cases.  My reading of the code is that manual overrides should never be necessary when copying from PPAs, *unless* the binary packages in question are new to that distroarchseries
<jdstrand> noted
<infinity> We do sometimes get new packages in SRUs and security updates that aren't kernels.
<jdstrand> I don't have specifics atm. I want to say openjdk-6, but it has been too long
<infinity> mozilla.org sources introduce new translationy bits, if I recall.
<jdstrand> infinity: re secureity updates> on occasion
<jdstrand> bind9 might be another
<cjwatson> Yeah, it does happen now and again.  My feeling is that fixing bug 192076 will sort out most of it, and for the rest, manual overrides would be OK.
<ubottu> Launchpad bug 192076 in Launchpad itself "component of new binary packages should default to source component" [Critical,Triaged] https://launchpad.net/bugs/192076
<infinity> Yeah, I'm happy with doing it manually when it comes up anyway.
<infinity> And fixing that ancient bug would just make that process simpler.
<cjwatson> I have a test case for half of it now.
<cjwatson> There are two pieces: firstly, the override policy doesn't implement this suggestion; secondly, normal uploads (as opposed to copies) don't use the override policy as extensively as they should
<ogra_> pitti, http://paste.ubuntu.com/1052388/ does that look sane to you ?
<pitti> ogra_: if you really want to match the names that precisely, sure
<pitti> ogra_: I don't have "Hardware" in my /proc/cpuinfo (amd64), all keys are lower-case; is that really right?
<ogra_> pitti, well, once we get omap3 drivers there will be many boards our kernels work on but the pvr driver likely wont
<ogra_> yeah, HArdware isnt in x86 but on all arm SoCs
<pitti> ogra_: stick the file into /usr/share/ubuntu-drivers-common/detect/ and run "ubuntu-drivers debug", to ensure that it's working
<tumbleweed> unfortunately, /proc/cpuinfo is completely different across archs
<ogra_> ah., great, thats what i was missing, i just added a main() function and ran it with prints for testing
<ogra_> tumbleweed, yeah, but luckily reliable at least on arm :)
<ogra_> pitti, http://paste.ubuntu.com/1052397/ looks fine
<pitti> ogra_: yep
<ogra_> seems panda even has a modalias (most other arm paltforms wont though)
 * Daviey tries to use apport to report an apport bug
<Daviey> sadly, it fails.. and i'm expecting apport to try to report a bug, about the bug that i encountered a bug when trying to report a bug.. GOTO 10
<pitti> Daviey: please update to apport 2.2.4, I fixed two major bugs this morning
<Daviey> pitti: i'm running 2.2.4-0ubuntu1
<pitti> ok, then I need more information, I'm afraid
<Daviey> pitti: I'll raise a bug, but looks like a py3 issue... ""
<Daviey> startswith first arg must be bytes or a tuple of bytes, not str
<Daviey> bug 1015788
<ubottu> Launchpad bug 1015788 in apport (Ubuntu Quantal) "All the apport crash reports are now "*** Error: Invalid problem report" - TypeError: startswith first arg must be bytes or a tuple of bytes, not str" [High,Fix released] https://launchpad.net/bugs/1015788
<pitti> Daviey: hm, that's what I fixed this morning, or at leat I thought I did
<pitti> Daviey: can you please attach your .crash file there? It might stumble over a different code path; I tested with jibel's and that works for me now
<jml> running apt-get dist-upgrade, is there a way to specify "don't ask me any (debconf) questions?"
<jml> this is for an automated process to spin up a new 12.04 server
<astraljava> jml: With the -y option it should assume yes to questions.
<cjwatson> astraljava: That doesn't affect debconf.
<infinity> jml: DEBIAN_FRONTEND=noninteractive
<astraljava> My apologies, I mixed things up.
<infinity> But you do want -y as well for unattended apt-gettery.
<jml> infinity: thanks. I'll try that out.
<jml> nope.
<infinity> jml: There's also --force-yes, but I'd contend that if your archive or system are in a state where that would be required, you're usually better off with the error. :P
<jml> I still get prompted by console-setup
<jml> I guess there I need to use debconf-set-selections or something?
<cjwatson> Er
<cjwatson> It shouldn't be able to prompt if you've *correctly* set DEBIAN_FRONTEND=noninteractive
<cjwatson> Exactly what command line did you use?
<jml> export DEBIAN_FRONTEND=noninteractive; sudo apt-get update -q; sudo apt-get dist-upgrade -q -y --force-yes
<cjwatson> sudo filters the environment.
<jml> ah right.
<cjwatson> sudo apt-get update -q; sudo DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -q -y --force-yes
 * jml man sudo
<cjwatson> (Though personally I wouldn't use --force-yes, for the reasons explained in apt-get(8).)
<infinity> jml: And yeah, I'd skip --force-yes
<infinity> jml: The error is almost always better than having it solve it for you.
<jml> so, just -y
<cjwatson> Yeah
 * infinity nods.
<jml> ok.
<Laney> sudoers(8) â "env_reset"
<jml> that bit is cargo-culting. I'll check out the man page so I can learn this proper.
<infinity> Holy crap, â is a compose set?
<jml> yeah
<infinity> This changes everything.
<jml> ->
<infinity> â â
<jml> infinity: it's magical _and_ revolutionary.
<infinity> Right.  That shouldn't excite me.  For the fifth attempt tonight, nap time.
<Daviey> pitti: attached
<pitti> Daviey: btw, I fixed that dkms bug this morning, too
<pitti> i. e. the one that generated _usr_share_apport_package-hooks_dkms_packages.py.0.crash in the first place
<Daviey> pitti: wine is for fglrx rather than virtualbox.. i marked the bug back to Confirmed.. I didn't think you'd want a seperate bug
<Daviey> s/wine/mine
<pitti> yes, the bug was in dkms' apport hook; not driver specific at all
<pitti> Daviey: can you please check the version in dpkg -l python-apport ?
<pitti> your .crash works for me (and in fact, it's the exact same as jibel's)
<Daviey> pitti: ii  python-apport  2.2.4-0ubuntu1
<pitti> ok, then I'm officially clueless why it still happens for you :/
<Daviey> pitti: I upgraded, rebooted to get the fresh kernel.. and the timestamp on the .crash file is that of first boot.
<pitti> Daviey: are you using apport-cli, and the "view report" option?
<Daviey> pitti: i've not touched apport-cli, this was the gui error raised on first boot
<pitti> ok, tested apport-gtk as well; but shouldn't make a difference, it's all the same backend code
<Daviey> pitti: Okay, should i rm the .crash file and reboot, see if i get the same result?
<pitti> followed up to the bug
<pitti> Daviey: the .crash file is not the issue here
<pitti> it's apport crashing if you try to report the DKMS bug
<Daviey> pitti: well, i can confirm that apport-cli does work.
<pitti> Daviey: if you run apport-bug /var/crash/_usr_share_apport_package-hooks_dkms_packages.py.0.crash, what happens?
<Daviey> pitti: huh, problem cannot be reported... The problem happened with the program /usr/share/apport/package-hooks/dkms_packages.py which changed since the crash occurred.
<pitti> ah, right
<pitti> that wouldl be the fixed dkms :)
<Daviey> but I haven't upgraded since...
<pitti> dpkg -l dkms ?
<Daviey> 2.2.0.3-1ubuntu4
<pitti> Daviey: that's the new one from this morning
<pitti> https://launchpad.net/ubuntu/+source/dkms/2.2.0.3-1ubuntu4
<pitti> which fixed that very bug (bug 1008092)
<ubottu> Launchpad bug 1008092 in dkms (Ubuntu) "dkms_packages.py crashed with AssertionError in _assert_bin_mode(): file stream must be in binary mode" [High,Fix released] https://launchpad.net/bugs/1008092
<Daviey> pitti: Yes, but i am saying that i upgraded, rebooted, then hit this issue.. So how did it change without touching apt?
<Daviey> Anyway, if this is gone for others.. and an oddity, i'm happy to ignore it.. just very peculiar.
<pitti> so it seems the apport crash is confirmed fixed for you as well
<pitti> Daviey: perhaps you opted to not report the dkms crash in the session where you did the upgrade?
<Daviey> pitti: that sounds likely, and makes sense.
<Daviey> thanks.
<pitti> anyway, I'm fairly confident that both bugs are fixed now
<pitti> Daviey: and on top of that, I wrote an ubuntu-drivers-common autopkgtest which will exercise the binary drivers, to ensure that they build, install, and work :)
<pitti> I didn't add the virtualbox ones, though, but that's easy
<pitti> Daviey: virtualbox-dkms, right?
<pitti> jibel: speaking about this, do you have an idea how the u-d-common adt test can be triggered for each new kernel upload? I could add a linux-y dependency to it, but which depends do you parse exactly? debian/control b-deps, binary deps, or debian/tests/control ?
<Daviey> pitti: no, my failure was fglrx.
 * pitti -> lunch, bbl &
<mterry> barry, is the goal for Quantal to have python3-only on only the Ubuntu Desktop CD or also the Ubuntu Server CD?
<mterry> Ah, desktop I see in the blueprint
<jibel> pitti, I added another case to reproduce 1015788 with apport 2.2.4-0ubuntu1 this time with accerciser.
<Daviey> mterry: confirmed it's not a target for server this cycle.
<jibel> pitti, binary deps
<cjwatson> dupondje: Do you think you could take the courier merge from me, please?  You did the last substantive merge - all I did was rebuild it for a Perl transition
<ogra_> pitti, hmpf, so to contribute to ubuntu-drivers-common i need a github account ? why is that not on LP as a bzr branch ?
<ogra_> tseliot, ^^^
<tseliot> ogra_: a matter of taste
<ogra_> no, a matter of workflow imho ... i cant just file a merge request now
<jibel> pitti, more precisely binary depends of all the binaries built from a source package. for u-d-common that'd be binary deps of u-d-common, dh-modaliases and nvidia-common
<ogra_> nor will UDD work with it in any way
<pitti> ogra_: I can just put in the file for you
<pitti> jibel: hm, so we could only add a dependency like linux-generic to u-d-common
<ogra_> pitti, tseliot bug 1016006
<ubottu> Launchpad bug 1016006 in ubuntu-drivers-common (Ubuntu) "please incluse arm-gles.py since impossible to commit new code to the ubuntu project as ubuntu-core-dev" [Undecided,New] https://launchpad.net/bugs/1016006
<pitti> ogra_: thanks, will do
 * ogra_ finds that massively annoying btw
<pitti> it is indeed
<pitti> but well, if someone will just upload or use UDD, it's always possible to import that into the git, too
<ogra_> sure
<ogra_> what bothers me is that it is a tool we ship on the CD and provide as a core component, there should at least be a bzr import from the github branch that we can work with on LP
<ogra_> i dont mind if someone wants to use git because he prefers it, but excluding all other devs from committing doesnt look very ubuntu to me
<pitti> just weird that there is no UDD branch for it
<pitti> oh, there is
<pitti> bzr lp-open lp:ubuntu/ubuntu-drivers-common
<ogra_> well, i'll use this one in the future or just upload and leave it to tseliot to merge into his git branch
<tseliot> ogra_: it's a shared branch and I can give you commit privileges if you like
<pitti> jibel: are you sure it's the same crash? If I let accerciser crash and run apport on it, I get bug 1014341
<tseliot> ogra_: otherwise your solutions are fine too
<ubottu> Launchpad bug 1014341 in apport (Ubuntu) "apport-gtk crashed with configparser.InterpolationSyntaxError in _interpolate_some(): '%' must be followed by '%' or '(', found: '%f'" [Undecided,In progress] https://launchpad.net/bugs/1014341
<ogra_> tseliot, i dont want a github account
<jibel> pitti, let me try again
<ogra_> and i am already in a  team that should have full access to the source of the ubuntu core componnents
<pitti> jibel: i. e. with apport-cli it works just fine, with apport-gtk I get above carsh (which does not affect -cli, as that does not parse desktop files)
<jibel> http://paste.ubuntu.com/1052519/
<jibel> pitti, ^
<pitti> jibel: if line.startswith('tags:'):
<pitti> that's not what apport 2.2.4 has
<pitti> that fixed it to b'tags:'
<pitti> jibel: dpkg -l python-apport?
<pitti> jibel: err, dpkg -l python3-apport
<pitti> jibel: argh, nevermind
<pitti> that was b'bugs:'
<pitti> as I actually got a string array here after the line splitting
<jibel> pitti, http://paste.ubuntu.com/1052523/
<pitti> so why the heck can't I reproduce this
<pitti> jibel: anyway, will look into it harder, thanks
<arges> mvo, hi. noticed a ftbfs in debtags. Just need to add 'dh-autoreconf' to Build-Depends. I have a patch if needed: http://people.canonical.com/~arges/plusone/debtags-ftbfs.debdiff     Laney mentioned this is also broken in Debian.
<mvo> arges: uh, thanks
<mvo> arges: pushed to the upstream git
<vibhav> we use git for ubuntu?
<Laney> he said upstream git
<vibhav> ah
<arges> mvo, cool.
<vibhav> "Attention to Detail" :(
<nuketro0p3r> #F2F2CEI edited the /usr/share/themes/Ambiance/gtk-2.0/gtkrc to fix my Eclipse tooltip. It worked, but how come my tooltip in other softwares is intact? - just curious o.O
<nuketro0p3r> Any one have a clue?
<nuketro0p3r> please ignore the color code in the beginning.
<cjwatson> ailo: qjackctl is imported and synced to quantal now, although as predicted it's failing to build for much the same reason it was failing to import: https://launchpad.net/ubuntu/+source/qjackctl/0.3.9-1
<cjwatson> ailo: For the record, three packages were affected, and all three are now fixed
<xnox> cjwatson: slangasek about bug #1015567
<ubottu> Launchpad bug 1015567 in dpkg (Ubuntu Quantal) "upgrade failed: mixed non-coinstallable and coinstallable package instances present" [High,Triaged] https://launchpad.net/bugs/1015567
<xnox> i have created two packages: (a) no m-a, amd64, v1 with a conffile. (b) m-a, i386,v2 with same conffile
<xnox> installing and removing the (a), installing (b) => succeeds
<xnox> http://paste.ubuntu.com/1052700/
<xnox> so I can't reproduce it in clean pbuilder
<xnox> did I miss something?
<cjwatson> xnox: I think you need to install (b) over (a) using precise's dpkg, and then upgrade to quantal's dpkg and try installing something else
<ailo> cjwatson: Thanks. I guess the building failure will be fixed sometime soonish? I'll keep an eye out beginning next week. The haze of midsummer is shortly closing in
<cjwatson> xnox: the problem isn't that quantal's dpkg corrupts things, AFAIK; it's that precise's dpkg left a corrupted database in place, and now quantal's dpkg objects to it
<cjwatson> ailo: It won't happen automatically, and I'm not doing it, so I don't knw
<cjwatson> *know
<cjwatson> Hopefully somebody will pick it up, or you could send a patch ...
<ailo> Ok. I'll investigate more next week then :)
<xnox> cjwatson: ok. that will break.
<xnox> cjwatson: so the bug is not due to left over rc config file
<mpt> ev, hi, when updates are installed pre-login, where will the UI for that be? Will it be in Plymouth, like fsck?
<cjwatson> xnox: I never thought it was :-)
<cjwatson> It's not due to the config file itself, but due to the package being there in rc state with its .list file inadvertently removed from /var/lib/dpkg/info/
<cjwatson> As Guillem/Raphael explained on -dpkg
<xnox> ok. I get the error now, but it's different from the bug report message
<xnox> cjwatson: do you have a link to the explanation the thread is long
<cjwatson> No, just the first post in that thread by buxy
<cjwatson> And the original post by Guillem
<barry> kenvandine: https://bugs.launchpad.net/ubuntu/+source/libpeas/+bug/1015868 :)
<ubottu> Launchpad bug 1015868 in libpeas (Ubuntu) "Support both Python 2 and Python 3 plugins" [High,Fix released]
<kenvandine> barry, thx, saw your email!
<kenvandine> yay!
<kenvandine> i'll look at it soon
<barry> awesome.  let me know if i can help with anything else for gwibber
<kenvandine> barry, thx!
<pitti> cjwatson: @ udeb expansion> will do that (tomorrow), thanks for pointing out
<cjwatson> pitti: thanks
<nemo> So, Like many people, I'm really missing not having notification-daemon in 12.04
<nemo> If I search for the relevant crasher from what I see in gdb, I get a ton of hits on launchpad
<nemo> unfortunately, they seem to be duped against https://bugs.launchpad.net/bugs/926583
<ubottu> Error: malone bug 926583 not found
<nemo> which appears to either be missing or not accessible by me
<nemo> Now, there's a debian bug (and fix) on exactly this problem.
<nemo> AFAIK has even been packaged.
<nemo> All I'd like to know is.  Is ubuntu planning to address this at some point? 'cause I really missing having notify-send.  And, if they aren't, and that is a locked bug, unlocking it would be appreciated so people could try to figure out workarounds
<nemo> otherwise, duping stuff against something that either doesn't exist or won't be fixed any time soon isn't too helpful :(
<nemo> https://www.google.com/search?q=site%3Alaunchpad.net+gdk_pixbuf_scale_simple+notification-daemon+crashed
<nemo> https://bugzilla.gnome.org/show_bug.cgi?id=673749
<ubottu> Gnome bug 673749 in GtkStatusIcon "Error Message When Creating Tray Icon" [Normal,Resolved: fixed]
<nemo> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669883
<ubottu> Debian bug 669883 in libgtk-3-0 "notification-daemon crashes in gdk_pixbuf_scale_simple" [Important,Open]
<mpt> nemo, notify-send works for me with notify-osd in 12.04, as it has for every version since 9.04. It doesn't require notification-daemon.
<nemo> hum. is notify-osd unity only?
<mpt> No, it predates Unity.
<mpt> It looks like bug 926583 is waiting for the Apport retracer to retrace the crash report and then make it public
<ubottu> Error: Launchpad bug 926583 could not be found
<nemo> ah
<nemo> mpt: well. has been happening a lot. and without notification-daemon running, I get no notifications
<nemo> well. I don't get them with it running either
<nemo> but I do get a crasher then, if I run gdb ... notification-daemon   and then try notify-send
<mpt> nemo, if you want help with access to that bug report, try a member of this team: <https://launchpad.net/~ubuntu-crashes-universe>
<nemo> oh. I'd just like it to be unlocked, really
<nemo> since it has been happening on 3 different computers
<mpt> That must be frustrating
<rbelem> infinity, not yet. I will have the packages ready by the weekend
<nemo> I figure from the huge number of hits on launchpad, that it must not be a coincidence
<nemo> ah. notify-osd is installed, but not running
<nemo> if I launch it from commandline, I get the notification
<nemo> hm. I guess the fix is to uninstall notification-daemon, since it can't run at the same time anyway.
<nemo> just the sort of thing I would say in the bug if it wasn't locked :-p
<mpt> Maybe those packages should conflict with each other, since they try to do the same thing
<nemo> yeep. removing notification-daemon prompts for removal of gnome and gnome-core :(
<nemo> oh geez.
<mpt> oh, maybe that's why they don't :-)
<nemo> ugh. I can hack around this locally, but a clean solution would be nice
<nemo> mpt: well. then we have one that gnome depends on, that crashes :-p
<nemo> and one that it doesn't depend on, that works, but isn't launched
<nemo> hey. more stuff to put in the bug once it is unlocked :-p
<nemo> one odd thing is I've been sending crash reports every time I get prompted. a few a day
<nemo> Does ubuntu not have the equivalent of Mozilla's "top crashers" ?
<mpt> Aha. https://bugs.launchpad.net/notify-osd/+bug/357273/comments/5
<ubottu> Launchpad bug 357273 in Awn Extras "awn-notification-daemon randomly overrides notify-osd" [Medium,Fix released]
<mpt> That's why they don't conflict
<nemo> you'd think if others are experiencing the same thing, that folks would notice eventually
<mpt> nemo, we do indeed: https://errors.ubuntu.com/
<nemo> huh. that's odd
<mpt> Ubuntu has used a replacement for notification-daemon by default for three years now, so it's understandable that even a reproducible crash in it won't be showing up.
<nemo> heh. why on earth does gnome depend on it then, if it isn't even supposed to be used
<nemo> people do occasionally install other desktops ;)
<xnox> nemo: gnome != ubuntu-desktop
<mpt> I thought gnome-shell used its own embedded notification code now
<nemo> welp. I see that it is indeed in the top crashers for the month
<nemo> 157 for notification-daemon
<nemo> and linked to the inaccessible https://launchpad.net/bugs/926583
<ubottu> Error: malone bug 926583 not found
<nemo> ok. not *high* in the topcrashers
<nemo> but still!
<nemo> if I launch notification-daemon w/ notify-osd running then it exist immediately. so isn't even clear why I'd have it
<nemo> apart from wanting gnome3 (and more importantly, MATE)
<mpt> aha
<nemo> hm. XFCE4 doesn't depend on it
<nemo> mpt: MATE doesn't depend on it though, oddly
<nemo> just gnome
<nemo> well. I've only been keeping gnome around for testing, since it was crashing on this ATI card in the past
<nemo> I guess I could just uninstall it.
<nemo> Not sure what I'll do on the other machines though
<mpt> MATE + notify-osd ~= Ubuntu 9.04 to 10.10
<nemo> hrm. Depending on the syntax, that's either an attempt to do a pattern operation, specify inequality, or specify approximate equality :)
<nemo> anyway. whatever. was just trying to find a clean fix.  I guess I'll just make sure notify-osd is started in startup apps or somesuch.  Not sure what is firing off notification-daemon though
<nemo> as long as you guys are keeping the package around, it would be certainly nice if you picked up the fix :-p
<nemo> heck. it even has the pretty little ubuntu symbol. so that means maintained core right?
<nemo> and right now it doesn't really work at *all*
<hallyn> SpamapS: cgroup lite is 1.1 in precise, 1.2 in q (we're upstream).  I'm calling the SRU to precise 1.1.12.04.1.  debuild seems happy with it.  lemme know if that's not quite right
<hallyn> (it's my best guess per https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation)
<cjwatson> I'd be inclined to just use 1.1.1 in such cases
<hallyn> cjwatson: my fear is, it also exists in o
<hallyn> oh wait,
<hallyn> it has different versioning there.  so 1.1.1 is fine.  thanks
<cjwatson> It's 0.37.1-1ubuntu7.11.10.1 in oneiric
<cjwatson> (well, oneiric-proposed)
<hallyn> cjwatson: yup.  i'll go with 1.1.1.  thanks.
<mpt> nemo, notification-daemon is in Universe. <https://help.ubuntu.com/community/Repositories/Ubuntu>
<nemo> huh. I thought the ubuntu logo meant core
<nemo> or ubuntu maintained or something
<seb128> ev, mpt: what's the "frequency" unit on errors.ubuntu.com? reports/day?
<nemo> seb128: I assume it is reports over the time period selected
<mpt> seb128, "in the past day" by default. It's not averaged at the moment
<nemo> so notification-daemon got 157 reports to the secret bug over the last month
<seb128> mpt, "by default", so it's just "number of report in the selected time period"?
<mpt> seb128, yes
<seb128> mpt, ok, thanks
<seb128> nemo, yeah, seems some people are still running notification-daemon for whatever reason
<seb128> nemo, what do you call "secret bug"?
<nemo> seb128: well. apparently because gnome requires it
<nemo> 11:47 < nemo> and linked to the inaccessible https://launchpad.net/bugs/926583
<ubottu> Error: malone bug 926583 not found
<seb128> nemo, gnome-shell has its own notification service
<nemo> seb128: if I mark notification-daemon for complete removal, synaptic package manager marks gnome and gnome-core
<seb128> nemo, right, those are useless dummy packages coming from Debian
<seb128> nemo, you can remove them
<nemo> ah
 * nemo did not know that
<nemo> one more thing to put in the secret bug :)
<seb128> nemo, they are dummy packages which depends on everything which is "GNOME"
<seb128> nemo, that bug is not secret, it's just that segfault can have private infos in their dump and access is limited to bugsquad by default
<nemo> so. I guess this happens to people who have been upgrading for a long time
<nemo> seb128: sure. I figured. but amounts to same thing. and it has gotten duped a lot :-p
<nemo> oh well. uninstalled notification-daemon. doing same on other machines that I can access over ssh. thanks
<seb128> nemo, nobody is maintaining notification-daemon anyway
<seb128> nemo, yw
<nemo> seb128: well. it says ubuntu developers maintain it, and has the nice logo :)
<seb128> we should probably fix that
<nemo> I'll have to check on my mom's machine when it comes back online - it was also installed a long time ago
<seb128> we recommend notify-osd for years
<nemo> I'm guessing any of my machines that are old may have this issue.
<nemo> which would be... hm. all of them :)
<seb128> nemo, what's the issue? what session do you use?
<nemo> seb128: periodic crash notifications
<nemo> seb128: I'm guessing because notification-daemon is crashing due to the bugs I linked to prior (see debian and gnome ones in gtk3)
<nemo> seb128: and I guess notification-daemon is running 'cause this is an old setup
<nemo> I just checked w/ the MATE guys, MATE just uses dbus, so, should be able to use notify-osd just fine once I clean things up
<seb128> nemo, great
<nemo> My mom's on MATE as well after months of hate against the new tablet interfaces, so similar config. My SO alternates between Unity and MATE but currently is using MATE due to Unity brokenness with virtualbox
<nemo> also her graphics card is a bit wimpy
<nemo> and unfortunately unity2d is kind of broken with multiple desktops
<nemo> really a pain to move apps around
<nemo> also resizing windows in it
<nemo> she did spend a couple of months doggedly learning the interface
<nemo> major props to her
<nemo> virtualbox was the final straw
<seb128> nemo, your bug seems to be bug #926758 btw
<ubottu> Launchpad bug 926758 in notification-daemon (Ubuntu) "notification-daemon crashed with signal 5 in g_return_if_fail_warning()" [Medium,Confirmed] https://launchpad.net/bugs/926758
<seb128> nemo, there is a fix upstream for gtk: http://git.gnome.org/browse/gtk+/commit/?h=gtk-3-4&id=e694bd75f601d4796119b622ba2f2cd13ca86ddd
<nemo> um
<nemo> nooo
<seb128> nemo, we will include it for precise in the next gtk SRU
<nemo> not that one :)
<pitti> cjwatson: autopkgtest fix uploaded
<nemo> seb128: it is the bug I linked to :-p
<nemo> the one that gets 157 hits
<seb128> nemo, they are the same bug?
<nemo> seb128: I'd have to reinstall it to grab another stack trace though
<cjwatson> pitti: thanks
<nemo> oh? huh. the place it crashes seems different
<seb128> "gdk_pixbuf_scale_simple", expression=0xb703839e "dest_width > 0
<nemo> ah. yep. that's the one
<seb128> nemo, that's the one I pointed
<nemo> and yeah. I saw the fix committed in the gnome bug
<pitti> cjwatson: now I go rest my bleeding eyes from the autopkgtest source code :)
<pitti> good night everyone!
<seb128> nemo, we will get the gtk fix SRUed
<seb128> nemo, thanks for pointing it
<seb128> pitti, 'night
<nemo> well. I don't need it anymore :)
<nemo> but good to know. maybe I can skip on nagging family members
<nemo> and/or sshing into their machines
<nemo> seb128: FWIW the debian report has a second git ID as well (last comment)
<nemo> the one from a month ago
<seb128> nemo, thanks
<nemo> BTW, only kind of ubuntu devel related, but I really liked this comment on linux video
<nemo> http://linux.slashdot.org/comments.pl?sid=2927755&cid=40387313
<nemo> guess I'm going ATI next time, esp after their recent announcement.
<nemo> seb128: hey. just curious. because you guys forgot to drop notification-daemon - does that mean you have to maintain it for the entire LTS? :)
<smoser> mdeslaur, you touched clamav last, does https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1015828 make any sense to you?
<ubottu> Launchpad bug 1015828 in clamav (Ubuntu) "package clamav-milter 0.97.5+dfsg-1ubuntu0.12.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<mdeslaur> smoser: http://www.ubuntu.com/usn/usn-1482-2/
<mdeslaur> smoser: dupe of bug 1015337
<ubottu> Launchpad bug 1015337 in clamav (Ubuntu Quantal) "clamav-base fails configure with `/usr/share/doc/clamav-base/examples/main.cvd': No such file or directory" [Undecided,Fix released] https://launchpad.net/bugs/1015337
<smoser> mdeslaur, well, look at the bug.
 * smoser reads that link more closely
<mdeslaur> smoser: he probably needs to uninstall clamav and reinstall it
<smoser> probably, yes, but how did he get there?
<mdeslaur> the .1 release failed to install in the postinst
<smoser> ah. ok.
<mdeslaur> smoser: It's possible the .2 doesn't install over .1 cleanly depending on ordering...not all combinations were tested
<tremolux> hrw: hi! I was just asking in #ubuntu-desktop about a weird graphics corruption issue that we've gotten two reports of for Ubuntu Software Center, bug 1015216
<ubottu> Launchpad bug 1015216 in software-center (Ubuntu) "Graphical corruption in software center" [Low,Confirmed] https://launchpad.net/bugs/1015216
<tremolux> hrw: and Laney mentioned that you had reported seeing this: http://marcin.juszkiewicz.com.pl/~hrw/shots/bad-fonts.jpg
<tremolux> hrw: I just wondered if you've noticed anything similar in Software Center, that is, corruption of the toolbar icons when mousing over them
<seb128> hrw, what video card do you use?
<hrw> seb128: radeon 5430 with open driver
<hrw> tremolux: never used software center
<ogra_> how can you !
<ogra_> :)
<seb128> hrw, thanks, seems like it could be an ati issue
<seb128> hrw, do you still get the corruption issue? do you get it easily?
<hrw> ogra_: using U(unity)buntu on private machine is not a requirement but only suggestion ;)
<hrw> seb128: open gvim with lot of text (:help is enough), scroll and watch for crazy lines
<hrw> seb128: root logged into xterm+kwin+gvim did not had problem
<Laney> hrw: Sarvatt said it might be a driver problem with the current drivers, and that the ones from debian should/might fix it
<Laney> if you can reproduce it easily (I can't) then maybe its worth giving that a go
 * ogra_ thinks its just because hrw never used software center .... its the wrath of mvo !
<mterry> kenvandine, hey buddy!
<hrw> Laney: ok
<mterry> kenvandine, do you have spare review cycles?  I've got a load of update-manager branches that mvo is likely too busy to get to soon, if you can
<tremolux> hrw: ok, no probs, thanks  :)
<hrw> Laney: sarvatt's ppa with xorg-edgers would be fine too?
<Laney> dunno, I just rebuilt x-x-v-ati from sid :-)
<Laney> can give you the debs if you are on amd64
<hrw> Laney: I am
<hrw> Laney: anyway they are building now
<Laney> hrw: http://people.canonical.com/~laney/xserver-xorg-video-ati/
<hrw> thx
<Laney> np
<kenvandine> mterry, i'll do my best :)
<mterry> kenvandine, you're the best!  I think if you start at https://code.launchpad.net/~mterry/update-manager/avail-cleanups/+merge/110914 and follow the chain of pre-req merges, you'll end up at the first one, which should be 'update-at-start'
<mterry> kenvandine, any bits that you can get to are welcome!  I just didn't want to block on mvo if possible
<hrw> Laney: looks like it was that
<Laney> nice
<hrw> good
 * hrw -> off
<kees> infinity: say, slangasek says you're busy. if you don't have anything staged for eglibc, can I upload my changes?
<infinity> kees: Oh, I had planned to actually review that and such, but yeah, I seem to have let it slide.
<infinity> kees: If it's wildly urgent to you, and you're sure it won't break anything, go ahead.
<kees> infinity: yeah, the results pass my glibc regression test suite (fwiw). it's blocking some changes to the security tests suite, so that's why I've been pestering you. :)
<kees> infinity: it's get it done. :)
<kees> er, I'll get it done.
<SpamapS> @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: SpamapS, pitti
<SpamapS> a day early, but looks like I may be too busy tomorrow
<seb128> SpamapS, hey
<seb128> SpamapS, do you know if the SRU team rotation schedule got written somewhere?
<SpamapS> seb128: somebody had a TODO to put it .. somewhere
<seb128> SpamapS, somebody ... somewhere ... sometime ... I see ;-)
<SpamapS> seb128: I'd take responsibility, but that would be unfair to my other responsibilities. ;)
<seb128> hehe
<seb128> SpamapS, no worry, I just want to stop pinging the whole SRU team daily and try to get some reviews of whoever is on duty ;-)
<seb128> slangasek, ^ do you know who has the rotation schedule?
<SpamapS> seb128: there shouldn't be a need for pings.. we process the queue from oldest -> newest daily... unless there's some urgent regression which needs a queue jump.
 * SpamapS hopes we do not have daily urgent regressions :)
<seb128> SpamapS, libreoffice is stucked for over 3 weeks and I raised it to the TB and release team lists
<seb128> SpamapS, but I guess nobody wants to be the one letting a libreoffice SRU in
<seb128> SpamapS, still it's a real issue, we have data lose bugs in the LTS for over a months where fixes are available
<SpamapS> What was the final decision on that?
<jdstrand> seb128: is that the libreoffice on oneiric?
<seb128> jdstrand, no, it's 3.5.4 for precise
<SpamapS> I lost track of the thread.
<seb128> SpamapS, the TB says the SRU team can ack those
<seb128> SpamapS, slangasek said anyone in the SRU team can do it and that he will have a look on friday if nobody does this week, we are getting there...
<seb128> jdstrand, there is no security fix in this one so it's not a security team concern (yet) ;-)
<jdstrand> seb128: ok, the 11.10 Sweetshark told me could be dropped
<jdstrand> s/11.10/11.10 one/
<seb128> jdstrand, 3.5.5 might be in a different category and that's one of the reasons I would like 3.5.4 moving before that happens
<slangasek> seb128: the rotation schedule is in a google doc; we'll get that published ASAP; and today is bdmurray's day
<SpamapS> So we didn't actually try for an MRE yet? I really want to understand upstream's process before I just blindly accept it. :-P
<jdstrand> seb128: /me nods
<jdstrand> I'm fine with having the most up-to-date version in -updates, believe me :)
<jdstrand> (for precise)
<seb128> SpamapS, oh, MRE was asked 3 weeks ago and acked by some TB members, it's purely on the SRU team side
<SpamapS> I saw a bunch of requests for more info.. didn't see the actual +1
<seb128> SpamapS, but MRE doesn't mean we should avoid a SRU team sanity check
<SpamapS> and then angry "if I have to do this I quit" type messages
<jdstrand> (the oneiric one had a regression and is abandoned, and is going to need to be respun anyway very soon anyway)
<jdstrand> s/ anyway)/)/
<seb128> jdstrand, yeah, I followed that one, I though the old version was going to be uploaded with new.is.really.old changelog trick
<SpamapS> https://lists.ubuntu.com/archives/technical-board/2012-June/001309.html
<SpamapS> well here's the tech board +1
<seb128> SpamapS, right
<jdstrand> seb128: I wasn't going to do that since the one in -proposed can just be rejected
<SpamapS> so yeah, it just needs the sanity check on versions and stuff
 * SpamapS takes a look
<seb128> jdstrand, well it means the security issue is still not addressed
<seb128> jdstrand, but if that's fine for you guys I will not say anything ;-)
<seb128> SpamapS, thanks
<jdstrand> seb128: it is addressed, except for someone running -proposed and installing it
<SpamapS> bdmurray: are you already looking at it?
<seb128> SpamapS, my other concerns is that we have trivial items still taking over a week to be reviewed and it's the velocity we would like to see
<infinity> barry: What was the point of uploading libpeas twice in a row? :)
<SpamapS> I didn't do much SRU stuff yesterday, so I'm happy to grab it now
<jdstrand> but our policy is not to try to be tricky with --proposed. we base of -updates and -security
<seb128> jdstrand, oh ok, that was not my understanding
<SpamapS> seb128: we'll need more people on the team if you want that improved.
<seb128> jdstrand, my understand was that oneiric (release) had the issue but the easy fix can't be uploaded because the version would be < proposed
<SpamapS> its been better the last 2 weeks
<jdstrand> seb128: yeah-- once it hits -updates, we use it. if there is something in -proposed at the time we provide the -security update, we mention that the package in -proposed needs to be respun to incorporate the -security fixes
<jdstrand> (in the bug)
<jdstrand> (in the SRU bug that is)
<seb128> jdstrand, does it mean you plan to get a 1:3.4.4-0ubuntu1.1 out with the security fix?
<jdstrand> otherwise all our versions go haywire
<seb128> jdstrand, I'm a bit lost
<SpamapS> seb128: any reason quantal has not seen 3.5.4 yet?
<seb128> jdstrand, that security issue is resolved in neither oneiric, oneiric-updates, nor oneiric-security as I understand it
<jdstrand> seb128: yes. 1:3.4.4-0ubuntu1.2 will be going to -security (1.2 cause I had to respin 1.1 in the security ppa)
<seb128> SpamapS, we target 3.6.0~beta1 directly to quantal and it's still not building thanks due to the new toolchain (taking a bit to resolve the toolchain issues)
<SpamapS> seb128: roger that, I'll waive that req too then
<seb128> jdstrand, oh ok, so you still plan a security update, just note  a weirdly versioned one to deal with proposed issues
<seb128> SpamapS, thanks ;-)
<seb128> jdstrand, I though you were saying you didn't do any update for oneiric
<jdstrand> seb128: sorry for the confusion. I am providing the updates for oneiric based off of 3.4.4.
<seb128> didn't->wouldn't
<seb128> jdstrand, cool
<seb128> jdstrand, thanks ;-)
<jdstrand> seb128: right, I was just saying I wasn't going to use a weird version number for my update :)
<SpamapS> seb128: accepted
<seb128> SpamapS, thanks!
<barry> infinity: stupidity on my part?
<jdstrand> SpamapS: how does one remove a package from -proposed?
<infinity> barry: Check.  Was just a curiosity. :P
<jdstrand> neither StableReleaseUpdates#Removal_of_updates or ArchiveAdministration is helping me
<barry> ;)
<jdstrand> oh, I can just reject it
<jdstrand> duh
<jdstrand> SpamapS: nm
<SpamapS> jdstrand: if its in queue, yeah, just reject. Otherwise I believe it is 'remove-package' but I've actually never done it
<infinity> jdstrand: If you can reject it, it's not in proposed.
<jdstrand> remove-package does way more than I want :)
<infinity> jdstrand: And if it *is* in proposed, remove-package -m "This SRU sucked" -s foo-proposed -S source
<jdstrand> infinity: ah, ok, then it doesn't do too much
<jdstrand> infinity: can I quote you on the "This SRU sucked" bit?
<infinity> Sure. :)
<infinity> Not that I have context.
<jdstrand> :)
<jdstrand> infinity: hmm, why '-S' ("remove source only"). Note, that -S in remove-package is different than -S in change-override
<jdstrand> I want it without -S
<jdstrand> not sure why that was so hard for me to figure out... *shrug* it's done now
<infinity> jdstrand: Oh indeed, I didn't read the help.
<infinity> jdstrand: Though running it would have made that vaguely obvious. ;)
<stgraber> is it just my amrhf build that's weirdly broken or python3 is broken on quantal armhf (at least)?
<jdstrand> infinity: still, you were a great help (I updated the wiki btw)
<infinity> stgraber: Context?
<infinity> stgraber: What's breaking/broken?
<stgraber> infinity: starting python3 (not script or anything) fails and gives me "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb2 in position 23: invalid start byte"
<infinity> stgraber: That seems like the sort of thing that would cause a ton of build failures and we'd surely notice...
<infinity> stgraber: Oh, except that buildds run in LANG=C
<slangasek> except that the buildds don't run python interactively
 * infinity checks here.
<stgraber> infinity: http://paste.ubuntu.com/1053198/
<stgraber> FWIW that image was missing langpacks initially but I fixed that a while ago including a reboot, copy/pasting chinese stuff seems to confirm utf8 is working as expected :)
<stgraber> (and I still wouldn't expect python to blow up that badly even if I was lacking a utf8 locale)
<infinity> stgraber: No can reproduce here, either in C or en_CA.UTF-8
<infinity> stgraber: This is in a clean chroot where I just installed python3, FWIW.
<infinity> stgraber: So, you may have Something Else(tm) blowing up your world.
<infinity> stgraber: And I'd bet it's not ARM-specific, but who knows...
<stgraber> installing debsums now to check what's broken on there :)
<stgraber> it's a clean .img I dded on an sdcard and booted on a panda, so nothing fancy, well except for the fact it's the first time we build Edubuntu for armhf
<infinity> Oh, except in this clean chroot, I don't actually HAVE any UTF-8 locales, so python's probably silently ignoring it.
<infinity> Let me localegen some.
<gr8linux> I need help with webkit and quickly
<infinity> stgraber: Yeah, even with some langpacks installed, can't reproduce either with C or a UTF-8 locale.
<stgraber> infinity: ok, will see if debsums finds anything weird here, I'd be happy to blame the sdcard ;)
<stgraber> but dmesg doesn't seem to confirm it's just a bad media
<infinity> stgraber: I like to blame SD cards for most of my problems.
<gr8linux> It seems that there is a problem with import webkit and quickly
<infinity> stgraber: In this case, though, I suspect it's an actual software bug, since bad media tends to be a bit louder.
<infinity> stgraber: Just a bug that's a bit more subtle than "install python3 and watch it suck".
<gr8linux> I need help with webkit and quickly
<micahg> SpamapS: seb128: IMHO, it seems that sabdfl's +1 of the libreoffice MRE was premature given the poor track record before, but I think there was at least a consensus that 3.5.4 should be given a shot
<infinity> gr8linux: You probably want #ubuntu-app-devel (see the topic)
<SpamapS> micahg: Yes, I think not doing it is a greater risk than doing it.
<gr8linux> infinity:tanx
<seb128> micahg, I asked slangasek about it and he said there was enough "pro" on the TB discussion for the SRU team to pick it up and review it
<micahg> seb128: yep :), I just saw SpamapS quoting the +1 and wanted to comment on that, that's all, everything seems like it's on the right track now though
<seb128> right
<stgraber> infinity: debsums didn't spot anything off on that system, so it's clearly something that's installed (or missing) that's messing with python3...
<infinity> stgraber: Installed seems more likely than missing.  My chroot wasn't particularly polluted.
<infinity> stgraber: Had a bit of junk in it from a previous build, but...
<stgraber> infinity: rm /usr/lib/python3.2/__pycache__/traceback.cpython-32.pyc => fixed
<infinity> stgraber: So, it got miscompiled?
<infinity> stgraber: That's a tiny bit disconcerting.
<stgraber> infinity: looks that way...
<stgraber> barry: ^
<barry> sorry, what's the issue?
<stgraber> barry: http://paste.ubuntu.com/1053198/
<stgraber> barry: that's what I got on a clean daily-preinstalled image on armhf
<barry> stgraber: wtf?
<barry>  ;)
<stgraber> barry: after digging for a while I tracked it down to the .pyc for traceback being broken. Removing it to force it to re-generate fixed it
<barry> stgraber: even with a corrupt .pyc, the crash looks *very* odd
<barry> but okay :)
<infinity> Do we generate those at install time, or runtime these days?
<stgraber> barry: I'm making 100% sure that this .img contains the broken .pyc, if it does, you'll be able to download it and look :)
<slangasek> infinity: install time
<infinity> Kay, so the image SHOULD contain the broken one.
<slangasek> infinity: (at runtime you don't get to write to /usr)
<barry> pycs should never appear in the package, always at install time, even for the interpreter itself
<infinity> But how it got broken, I dunno.
<infinity> slangasek: Oh, err, right.  /usr.. Wasn't really thinking while I typed. :P
<barry> do you have a copy of the .pyc file?  i could inspect it (it's essentially just a marshaled code object with some magic header bytes)
<barry> that may not actually help in any useful way though
<infinity> barry: Well, it would perhaps help to determine if it was either corrupt or miscompiled.
<barry> infinity: any chance you can drop the bogus .pyc some place i can grab it from?
<infinity> barry: I think stgraber's working on doing just that.
<barry> cool
<infinity> barry: Once he confirms that the one in the image is actually broken.
<infinity> barry: (If it's not, I assume the one he rm'd was just corrupted on his SD)
<stgraber> barry: I sadly removed it... writting a new sdcard to reproduce, for some reason reproducing with qemu-arm-static failed here, so I want to reproduce with the exact same setup
<barry> stgraber: no worries.  ping me if/when you have something
<infinity> stgraber: If could just have been a bitflip on your SD card.  Since debsums doesn't know about .pycs, you wouldn't have known.
<jtaylor> SpamapS: re fftw3, which cflags?
<slangasek> barry: when you say you get to the grub screen half the time... is it *about* half the time, or is it *exactly* half the time? ;D
<slangasek> barry: because y'know, grub has handling for doing things differently the second time after a failed boot
<barry> slangasek: interesting.  i think "about" but i'll gather more data points
<slangasek> ok
<stgraber> infinity: yeah, should be able to confirm that shortly... that'd confirm the whole always blame the sdcard rule ;)
<stgraber> I guess I could check the md5sum of the partition post-zcat to detect that (but don't quite like the idea of having to wait 15min ...)
<bryceh> @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: SpamapS, bryceh, pitti
<SpamapS> jtaylor: sorry I went to lunch. ;) http://paste.ubuntu.com/1053382/
<SpamapS> jtaylor: there are numerous changes to cflags in there
<jtaylor> numerous = 1?
<SpamapS> I count all the changes on those 3 lines as numerous :)
<SpamapS> either way, its not clear from the changelog entry why
<SpamapS> 2 lines rather, sorry. ;)
<jtaylor> just to shut up debians built log checks
<SpamapS> jtaylor: actually, the archconfflags is for mpi isn't it?
<jtaylor> I added docs
<jtaylor> yes
<SpamapS> jtaylor: I was moving a bit fast, didn't notice that :-P
<SpamapS> jtaylor: so I still don't understand why CFLAGS was changed
<SpamapS> or rather, added
<SpamapS> jtaylor: the rest looks great btw
<jtaylor> in what way changed?
<jtaylor> its only added to a gcc call that compiles a 5 lines test
<jtaylor> it can be dropped in ubuntu if you like
<SpamapS> Its not really about what I like. I'm just pointing out that I don't know why its there.
<SpamapS> jtaylor: we tend to document all of the delta we have, as merges can get confusing every 6 months.
<SpamapS> forgive me if it seems I'm being pedantic!
<jtaylor> its fine, I was just lazy
<jtaylor> also documented in debian now
<infinity> tumbleweed: Hey, pypy only took 1 day and 19 hours on armel, that's not so bad. :P
<infinity> tumbleweed: (Jury's still out on armhf...)
<infinity> Riddell: Did ktp-contact-applet get superseded by ktp-contact-runner?  The former is the only thing that didn't get updated in the ktp-4.0 napalm upload.
<infinity> Riddell: (And thanks to either your guidance or George's foresight for that being a self-managing library transition with sane dep-waits, so I didn't have to fix it after the fact)
<barry> stupid question i should know the answer to: given debian/changelog, is there a cli for extracting the version number of the top entry?
<micahg> barry: in what context?
<barry> micahg: i'm sitting in the top directory for a native package (a udd source package if it matters, but it should work with `apt-get source).  in the setup.py script i want to extract the version number from the debian/changelog file
<micahg> hrm, I haven't played with the python debian version library yet
<barry> micahg: i could grep it of course, but just though there might be some dpkg-magic command that did it
<micahg> well, there's dpkg-parsechangelog
<barry> micahg: that could work, thanks /me reads the manpage
<infinity> barry: dpkg-parsechangelog --format rfc822 | awk '/^Version:/ {print $2}'
<infinity> barry: Can't think of anything less icky than that off the top of my head.
<barry> infinity: perfect, thanks!
<infinity> Of course, if you're sitting in python, you might want to use python's filthy string manipulations instead.
<infinity> But awk's probably faster. ;)
<StevenK> infinity: grep '^Version' | cut -d\  -f2 ? :-P
<infinity> StevenK: I bet that's slower.
<barry> this is a setup.py file.  speed is not the issue :)
<StevenK> Haha
<infinity> StevenK: Besides, the beautiful inreadability of awk always wins.
<StevenK> infinity: Hang on, sed can do this itself, can't it?
<infinity> StevenK: (Though, in this case, cut's far worse to visually parse)
<StevenK> I will usually reach for grep and cut before awk. If I start chaining tr to cut and then sort, it's probably time to use awk. Or Perl.
<infinity> StevenK: I tend to only use cut if the -d is oddball.
<infinity> StevenK: Plus, I find '-d" "' or '-d\ ' (pick your poison) so wildly unintuitive to parse visually after it's been written.
<StevenK> infinity: That isn't really cut's fault, though.
<infinity> StevenK: No, lots of unintuitive programming isn't the tool's fault, it's the programmer for doing unmaintainable things.
<StevenK> Haha
<SpamapS> @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: bryceh, pitti
<StevenK> infinity: To be fair, I use cut for one liners, nothing that is going to be around for more than 30 seconds.
<mwhudson> StevenK: always a risky attitude that :)
<mwhudson> i wrote some nasty sql once and now it's the trigger that keeps Branch.unique_name up to date in lp :)
<StevenK> mwhudson: You're right, that is pretty horrible.
<micahg> bryceh: please try to remember -v :)
<bryceh> @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
<bryceh> micahg, for...?
<micahg> uploads
<RAOF> Of merges, presumably?
<micahg> yes
<bryceh> well too late now :-)
 * ajmitch does like --package-merge with bzr-builddeb, even if the resulting branch isn't pushed 
<micahg> bryceh: I ignored the first one, figured it was a goof :)
<infinity> micahg: I forget all the time.  Maybe we could put a check in the same dpkg-dev policy checker that bitches about "this looks like it has ubuntu modifications, but you didn't change the maintainer, you naughty naughty developer".
<bryceh> nah, I sponsor merges quite infrequently, I never remember all the myriad switches
<bryceh> -uc -us -S -sa -i -v
<RAOF> It shouldn't be too hard to automate âthis looks like a mergeâ, right?
<RAOF> (Note, NOT volunteering! âº)
<bryceh> well, in fact they're called out as merges in the pilot list, so we already can differentiate between the two
<bryceh> and yeah, for the most part 80% of the steps are mechanical
<micahg> there is sponsor-patch
<bryceh> micahg, more switches to memorize!  ;-0
<micahg> -v is listed as #2 to check
<Valtam> hi folks
<micahg> ajmitch: BTW, --package-merge still needs a sanity check :)
<ajmitch> micahg: of course, everything needs a sanity check
 * ajmitch now hopes that he got recent uploads right :)
#ubuntu-devel 2012-06-22
<robert_ancell> infinity, gentle nudge.. :)
<infinity> robert_ancell: OH MY GOD GET OFF MY BACK.
<infinity> robert_ancell: Wait, what was the nudge about? :)
<infinity> robert_ancell: Oh, right.  New package.  Let me poke it.
<robert_ancell> infinity, thanks!
<infinity> robert_ancell: Remind me which one?
<robert_ancell> infinity, libpwquality, bug 1011361
<ubottu> Launchpad bug 1011361 in Ubuntu "[needs-packaging] libpwquality" [Wishlist,Triaged] https://launchpad.net/bugs/1011361
<infinity> Seriously, someone reinvted this wheel?
<infinity> reinvented, too.
<robert_ancell> yep
<infinity> Is it insanely more awesome than cracklib somehow?
<infinity> Anyhow.  My value judgements about people reinventing wheels don't matter for NEW reviews.  Let me look at the actual packaging. :P
<infinity> W: libpwquality source: package-needs-versioned-debhelper-build-depends 9
<infinity> robert_ancell: The above seems to make some sense, since your debian/compat is 9.
<robert_ancell> infinity, oh, I didn't see that warning
<infinity> robert_ancell: To be fair, your build-dep (8.1.3~) is when compat 9 was introduced, but it was experimental, and changed every second day.
<infinity> Minor nitpick, anyway.
<robert_ancell> infinity, I copied it off another package
<infinity> ;)
<robert_ancell> infinity, I've fixed that in the branch, resubmit or just upload next time?:
<infinity> robert_ancell: Next time is fine.
<infinity> robert_ancell: I have a minor nit with upstream that their dual license doesn't specify WHICH GPL.
<infinity> robert_ancell: And while I'm betting they meant 2+, I could totally dig up a pre-1.0 draft and use it!
<robert_ancell> infinity, yes, they are unclear, but I did find somewhere that indicated it was 2+
<infinity> Well, they include 2, which is a fair hint that it's either "just 2" or "2+".
<infinity> Man, dh7+ rules files are so boring to read. :/
<infinity> robert_ancell: Your short descriptions are also ridiculously long.
<robert_ancell> infinity, yeah, any recommendations?
<infinity> Maybe I'm just an old skooler who likes "package - short_desc" to fit on an 80char terminal.
<infinity> s/and generating random passwords/and generation/ would help a bit.
<robert_ancell> the "(development files)" suffix is a bit of a killer, but that seems pretty standard
<robert_ancell> ok, fixed that for next release
<infinity> robert_ancell: It's also perfectly reasonable to not have the word "library" in the short description of every lib* package in the archive. ;)
<robert_ancell> it seemed to be the convention
<infinity> "password quality checking and generation" would be enough for the lib bits, IMO.
<robert_ancell> ok, will do
<infinity> But yeah.  None of this matters terribly.  I just like to be able to read things. ;)
<infinity> robert_ancell: The million dollar question... Will GNOME be depending on the python module for this?
<infinity> robert_ancell: And if so, when will it be py3?
<robert_ancell> no
<infinity> Alright, I like no.
<robert_ancell> I think technically yes, but no python programs access it
<infinity> Well, "technically yes" is bad if it's on the CD. :P
<infinity> Cause we're trying to ditch python2.
<robert_ancell> yeah, so no package in the archive will depend on it, and dont expect that to change
<infinity> Kay. If you discover that it supports py3, please do build the module. :)
<robert_ancell> ok
<infinity> Also, uscan tells me there's a new upstream for you to merge!
<infinity> Other than that, I'm happy.  Accepting it.
<robert_ancell> yay, cheers!
<infinity> robert_ancell: It's entirely possible this needs zero porting to be a happy py3 camper.
<robert_ancell> infinity, patches welcome :)
<infinity> robert_ancell: I'm the wrong person to ask about python patches. ;)
<TheMuso> heh
<infinity> barry: Care to have a 5-second look at libpwquality and, in your expert opinion, tell us if it's just a matter of a debian/control stanza and a quick change to rules to make it spit out a useful py3 module?
<barry> infinity: sure.  i lied about eod :)
<infinity> robert_ancell: Waaaaaitasec.  I just noticed the build-dep.  This is all just a super fancy wrapper around cracklib? :)
<infinity> robert_ancell: Somehow, that makes me feel a bit better about it.
<robert_ancell> yeah cracklib+a few more functions
<infinity> Maybe this can replace pam_cracklib on my machines some day, if it's extra fancier.
<TheMuso> Cracklib probably wrapped in GObject.
 * TheMuso hasn't looked atht elib so is assuming since its a GNOME lib.
<infinity> robert_ancell: If this is going to be a GNOME dep, do you have an MIR for it somewhere too?
<ScottK> SpamapS: I don't see this python-qt4 SRU you uploaded for Lucid.  If the branch diff in the bug represents what you uploaded, it's not going to solve the problem.  Where can I find the package?
<infinity> TheMuso: It has no external dependencies other than cracklib, so I'm guessing not.
<infinity> TheMuso: GObject kinda requires glib, right?
<TheMuso> Coudl a C++/gcc 4.7 guru please have a look at this FTBFS, and tell me what I should be looking to fix? http://paste.ubuntu.com/1053528/
<TheMuso> infinity: Yet, the glib package contains libgobject.
<TheMuso> s/yetyes/
<TheMuso> gah my typing sucks this morning.
<infinity> TheMuso: Use a c++ compiler?
<infinity> TheMuso: (Or reorder your linking arguments)
<TheMuso> Hrm why did I think it was C++? heh ok, thanks.
<TheMuso> Yay, waf.
<infinity> TheMuso: It is C++.  But the package is doing a manual "cc -lstdc++"
<infinity> Cause it thinks it's clever.
<TheMuso> Ah ok.
<infinity> For reasons I can't fathom.
<TheMuso> Me neither.
<infinity> Anyhow, the real problem is your -l args should all be at the end.
<TheMuso> Yep ok, time to learn about the joys of waf.
<infinity> Which may require mangling some configure or Makefile to put $LIBS or $LD_LIBS or similar at the end of the line.
<infinity> robert_ancell: So, I really should have test-built that before I accepted it.
<robert_ancell> infinity, will do the mir next
<robert_ancell> hmm, which build dep did i miss
<robert_ancell> libpam...
<infinity> robert_ancell: At least libpam-dev.  Passing it through sbuild for another go now.
<robert_ancell> infinity, no worry, i can update directly now right
<infinity> robert_ancell: Yup.
<infinity> robert_ancell: Let me let this build finish. :)
<robert_ancell> it's cheaper to waste server time than people time
<infinity> It's building on a server.
<infinity> robert_ancell: Yeah, libpam-dev makes it happy.
<infinity> robert_ancell: Plus, I stepped out for a smoke.  So, no wasted time. :P
<infinity> robert_ancell: So, this is your big chance to rev to the new upstream, fix debian/control, and then ignore the package forever!
<infinity> robert_ancell: (I wouldn't advertsise the last bit in your MIR)
<robert_ancell> infinity, hah, we never forget about packages on the cd http://people.canonical.com/~platform/desktop/desktop.html
<robert_ancell> infinity, you may also be interested in http://people.canonical.com/~platform/desktop/boot.html and http://people.canonical.com/~platform/desktop/standard.html - that's the boot and standard seeds being tracked
<infinity> robert_ancell: What are the mushroom bugs?
<robert_ancell> infinity, I think that means it needs to be sponsored by someone with main privileges
<robert_ancell> I did it ages ago, and I can't quite remember but the source seems to confirm that
<infinity> robert_ancell: Also, I'm going to assume by your "we never forget" statement that there will be an upload soon that builds. :P
<robert_ancell> infinity, yep
<infinity> robert_ancell: Oh, right.  The mushroom was the logo for the main sponsors group before it was abolished for a generic ubuntu sponsors one.
<infinity> robert_ancell: (Or maybe the mushroom was universe and the star was main, I don't remember now)
<vibhav> bryceh: ping
<twb> Apparently I'm banned from #ubuntu-server.  Anybody know how I'd find out *why*?
<ajmitch> I think #ubuntu-irc is the place to ask
<vibhav> !ban > twb
<ubottu> twb, please see my private message
<twb> Thanks.
<pitti> Good morning
<pitti> cjwatson: ah, so adt-ubiquity is back green
<infinity> ...
<infinity> robert_ancell: Dude.  Another libpoppler ABI?  apw is going to hurt you.
<infinity> robert_ancell: Does this one introduce more incompatible API changes again that require porting, or can we just rebuild all the stuff Andy ported to lib25?
<robert_ancell>  infinity, yeah, they love their abi changes
<infinity> robert_ancell: Seriously, we just spent the last two weeks porting the world to the last one, I really hope this one's just an ABI bump but not a massive API break again.
<infinity> I guess we'll find out. :P
<robert_ancell> infinity, evince built fine with it, haven't checked in too much detail
<infinity> robert_ancell: That's somewhat comforting.
<robert_ancell> infinity, btw, is there a way to make the rebuilds against the new poppler wait correctly, or do you just wait until it hits the mirrors?
<infinity> robert_ancell: I just wait until it's published.
<infinity> robert_ancell: Were you going to do all the 25->26 rebuilds for us?
<robert_ancell> infinity, yup, working on them now
<infinity> robert_ancell: (There were still some 19->25 bits that need porting, if I recall)
<infinity> Oh, might just be libreoffice now.
<robert_ancell> why is publishing sooo slooow
<infinity> robert_ancell: Because you're impatient?
<robert_ancell> I sure am
<infinity> robert_ancell: You'll be happy to know that the last publisher ran overtime, so it's not going to run until :33 :P
<infinity> robert_ancell: Which means your binaries won't land for another hour or so.
<robert_ancell> ok, that's not just impatience.  That's ridiculously slow
<infinity> I only accepted them just before the hour.
<infinity> Just pretend I did it a few minutes later and missed the :03 run. :P
<infinity> robert_ancell: Oh, it's also that time of day when we slow down ftpmaster for some other cronjobs.  THat would be why it's sad.  I/O contention.
<infinity> robert_ancell: I'm watching publisher log files, I'll let you know when cocoplum's good to go.
<infinity> robert_ancell: (Mirrors don't matter, since buildds pull directly from ftpmaster)
<robert_ancell> infinity, ta.  I'm finishing up now but I'll drop in later and upload when it's ready.  No problems so far in cups-filters, inkscape, calibre, xpdf, gdal
<infinity> robert_ancell: Should be less than 30m, if you're around then.
<infinity> robert_ancell: Alternately, you can just queue 'em up, sign them all, and then "sleep 3600 && dput *changes" ;)
<robert_ancell> infinity, nice idea - I'm totally going to do that
<infinity> Oh dear lord, there was a libreoffice upload in that.
 * infinity head->desk.
<infinity> Poor publisher.
<StevenK> Poor cocoplum
<StevenK> Poor buildds
<infinity> robert_ancell: Make that 7200. :P
<infinity> StevenK: cocoplum, in this case.  Dealing with those translations tarballs seems to make the publisher have a sad.
<StevenK> Just one?
<infinity> It's been grinding for 8 minutes on libreoffice_3.5.4-0ubuntu1_powerpc_translations.tar.gz
<StevenK> Oh, a binary upload. Right.
<infinity> Yeah.  I have no idea what, exactly, we're doing there that's so hard, but couldn't that be farmed off to appservers?
<StevenK> No idea about translation tarballs, myself.
<infinity> Yeah, me neither.  I've never peered into that black box.
<infinity> But it's pretty rough.
<infinity> When we get a kde langpack upload, it can be followed with a 6 hour publisher run while it imports them all.
<infinity> Which is speeeeecial.
<TheMuso> About as special as all the kde-l10n packages poluting changes every so often? :p
<infinity> robert_ancell: If you're still around, you might want to skip out on the clever delayed upload idea.  ftpmaster is pitching a fit.
<infinity> And 28 minutes later, the libreoffice translations are finally done.  Wow.
<infinity> robert_ancell: Okay, I retract my warning about delayed uploads, everything's published to ftpmaster, fire when ready.
<dholbach> good morning
<alkisg> Hello, keyboard layout switching is broken for Greek (us,gr) from 12.04 on except for the first user that did the installation, and I'm trying to pinpoint the problem in order to file a better bug report, may I ask a few questions about it?
<alkisg> For the user that everything works OK, in /var/lib/AccountsService/users/alkisg, I have: XKeyboardLayouts=us;gr;
<alkisg> For all the other users, I have: XKeyboardLayouts=
<alkisg> The result is that there's only (en) in lightdm when I select the other users, and when they login, there's no keyboard switching applet.
<alkisg> In /etc/default/keyboard, I have: XKBLAYOUT="us,gr"
<alkisg> So my question is, should accountsservice be returning "us,gr" for newly created users, or returning "unset" is fine, and it's lightdm's fault that it doesn't take the system-wide defaults into account?
<RAOF> alkisg: I guess that accountsservice should be returning "us,gr"; starting off with the system-wide defaults would seem to be the most appropriate behaviour.
<alkisg> RAOF: thank you, so I'll file it against accountservice
<AnAnt> Hello, could someone sponsor LP #1014705 ?
<ubottu> Launchpad bug 1013258 in skype (Ubuntu) "duplicate for #1014705 Please update to new upstream v.4.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1013258
 * alkisg filed LP bug #1016409, thanks again
<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
<melodie_> hello
<melodie_> at the moment it is still a bit difficult to find information related to configuring the launcher panel. I need to have several launchers fixed, so that the users can't remove them at all. For this purpose I put a copy of the desktop files which start them into the ~/.local/share/applications directory. I also configured the order for them in the dconf-editor at the laucher line, then I put a "chattr +i" on the ~/.config/dconf
<melodie_> but it's not yet perfect:
<melodie_> I can still remove icons from the launcher, however when I close/reopen the session the launchers are there again.
<melodie_> is there any known way to stick them so that they can't be removed, even during the session ?
<melodie_> or any way I could try ?
<melodie_> I'll ask again later and will be back
<melodie_> have to go for a moment
<mpt> How can I check whether -proposed is NotAutomatic like -backports is?
<Laney> look in its Release file on a mirror
<Laney> but, it isn't :-)
<cjwatson> $ wget -q -O- http://archive.ubuntu.com/ubuntu/dists/precise-backports/Release | grep NotAutomatic
<cjwatson> $ wget -q -O- http://archive.ubuntu.com/ubuntu/dists/precise-proposed/Release | grep NotAutomatic
<cjwatson> NotAutomatic: yes
<cjwatson> $
<mpt> cjwatson, that's odd, I get the opposite result
<mpt> (but thanks)
<mpt> cjwatson, according to <https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-backports-ui> they both should be NotAutomatic. Where would I report that bug? <https://launchpad.net/ubuntu-seeds>?
<mpt> Hm, no, ubuntu-seeds isn't configured to use LP for bugs
<mpt> ah, <https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta>
<mpt> reported bug 1016454
<ubottu> Launchpad bug 1016454 in ubuntu-meta (Ubuntu) "-proposed isn't NotAutomatic" [Undecided,New] https://launchpad.net/bugs/1016454
<tumbleweed> mpt: Laney raised it on ubuntu-release a while back too https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001380.html
<Laney> I think he is talking about post-release
<tumbleweed> oh
<tumbleweed> precise, duh
<Laney> that should be discussed with the SRU and archive teams, IMHO
<Laney> and should be coupled with a way of notifying users that they might want to get something from there
<tumbleweed> yeah, not usually something we'd change post-release
<mpt> Laney, yes, I'm sketching out a "Contributor Console" (working title) that would let people turn on -proposed; choose which -proposed updates to install; report a bug on something by clicking on it; get the code for something by clicking on it; etc
<Laney> mpt: I was thinking something in whoopsie/apport (or whichever component it is) that can recommend you try a particular SRU. I think this was discussed at UDS.
<Laney> anyway I would say that this other work needs to be done first, before we could think about turning this on for proposed
<Laney> (and of course bug #888665 [this one, again] would need to be fixed)
<ubottu> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665
<mpt> Laney, if you mean the "An update is available to fix the problem you just had", I'm considering that as separate for now
<Laney> I do mean that, and it seems quite tied to turning that flag on for proposed to me.
<mpt> How?
<mpt> It seems to me that would be setting the default expectation that every Ubuntu user is willing to be a beta tester.
<Laney> if they turn on proposed, then that is what they are saying
<mpt> But the fact that -proposed is off by default in the first place suggests the opposite.
<Laney> otherwise they turn it on and nothing happens
<Laney> if we had NotAutomatic and this other way of them finding relevant packages then we should turn it on by default, yes.
<mpt> Yes, but now the place for turning it on would be the same place where you choose which -proposed update(s) you want to install
<cjwatson> mpt: Launchpad itself controls whether a suite is NotAutomatic or not.
<cjwatson>         if (pocket == PackagePublishingPocket.BACKPORTS and
<cjwatson>             distroseries.backports_not_automatic):
<cjwatson>             release_file["NotAutomatic"] = "yes"
<cjwatson>             release_file["ButAutomaticUpgrades"] = "yes"
<mpt> cjwatson, fixed, thanks
<cjwatson> Note the pleasing absence of abject hardcoding there
<mpt> yesssssss
<cjwatson> (No DB column for pockets, which doesn't help)
<cjwatson> Er s/column/table/
<AnAnt> Hello, could someone sponsor LP #1014705 ?
<ubottu> Launchpad bug 1013258 in skype (Ubuntu) "duplicate for #1014705 Please update to new upstream v.4.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1013258
<Laney> Not sure it works like that for partner.
<AnAnt> Laney: who should I ask ?
<Laney> mvo may know
<Laney> but he isn't here. hum.
<cjwatson> You know, it's not actually that often that I notice hardware having got lots faster over the last ten years, because software does kind of tend to keep pace with it.  But I'm sure I remember being pleased with a new laptop on the grounds that it could build groff in 40 minutes or something like that, and my current laptop takes about 4 ...
<nuketro0p3r> I recently migrated from windows to ubuntu and I want to contribute to the OS. Where do I begin o.O ?
<nuketro0p3r> I want to contribute code .
<mpt> nuketro0p3r, https://wiki.ubuntu.com/ContributeToUbuntu has a long list of ways
<mpt> nuketro0p3r, if you want to contribute code, one way to start is to find a bug that bothers you, or a particular package where you'd like to fix something small
<nuketro0p3r> Like empathy?
<mpt> sure
<mpt> nuketro0p3r, https://bugs.launchpad.net/ubuntu/+source/empathy is the list of known bugs for empathy
<nuketro0p3r> tnx ^_^
<mpt> you're welcome
<shnatsel> pitti: hello! I'm the apport-tackling guy from elementary :) I'm getting "W:Failed to fetch http://ddebs.ubuntu.com/dists/oneiric/universe/binary-amd64/Packages  404  Not Found" error every time I'm trying to retrace something. My sandbox config is at https://code.launchpad.net/~elementary-os/elementaryos/apport-retrace-sandbox/ Is that a known bug or I just suddenly started doing something terribly wrong?
<pitti> hey shnatsel; sure, I haven't forgotten you :)
<pitti> shnatsel: we had to drop universe and multiverse for oneiric on ddebs.u.c.
<pitti> so please remove those two components from your config
<pitti> (running out of space)
<shnatsel> pitti: ah, I see. I thought I didn't use Oneiric, but I've grepped now just to be sure and it's there. I'll remove it, thanks!
<pitti> yw
<mpt> TheMuso (or anyone else): Would it be feasible to have a program where someone can click a button, then use a pointing device to click on a string in any *other* program, and the accessibility layer collects that string? (Assuming that it's in a known toolkit, e.g. GTK, Qt, XUL, Nux.)
<mpt> TheMuso, the use case is "I see here a string that's badly translated -- I want to easily find which package it is so that I can fix the translation."
<mpt> (And which string in that package.)
<xnox> mpt: one caveat is that strings have substituition variables in them, and as far as I know those are computed in the code before displaying. Also plugins can hook into programs leading to false detection of the package.
<mpt> true
<xnox> many translations come from a lang-pack separate to the software package (all of main / most things on the cd)
<xnox> i'm guessing that a fuzzy search in rosseta (launchpad translations) with some hints as to which package this might be and whether it is / isn't in main
<xnox> can probably get you to the more correct place, e.g. where the string actually needs to be fixed
<shnatsel> mpt: I'd assume that's possible in GTK2 with parasite module. It was not updated for GTK3 AFAIK.
<mpt> I often find a Google "site:translations.launchpad.net" search useful in telling which package a string is in
<xnox> mpt: what is the reason behind this question: file a bug about the package or correct/propose a translation as a contributor
<shnatsel> mpt: local .mo files can be used for determining the package. Process name of the clicked window also can be tracked down to a package easily.
<mpt> shnatsel, yes, the missing step from that is reading the text you clicked on
<xnox> mpt: note that when my american friend uses my laptop and the locale is set to en_GB.UTF-8 the translations will be 'wrong' to that user due to wrong locale.
<dholbach> iulian, great to see the RMB back in action :-D
<xnox> similar problems with brazillian portugese, dutch, austrian german, etc...
<mpt> xnox, then your friend shouldn't try to correct the text...
<xnox> =)
<cjwatson> process name> To some extent; however consider text that is generated by some backend process and displayed by a frontend.
<mpt> e.g. aptdaemon
<cjwatson> For example, ubiquity's package download progress messages are actually generated by apt, but you aren't going to be able to determine that at the toolkit level.
<cjwatson> (And they're substituted too; I can't think of a way to automatically track down the source, without inventing a new mechanism for tagging strings with the unsubstituted text or something, and making sure that mechanism is passed through all sorts of layers ...)
<cjwatson> But maybe a partial solution would be better than nothing, even so
<iulian> dholbach: Yup.
<glatzor> mpt, you want hunt strings in libapt er even curl?
<glatzor> want to
<shnatsel> glatzor: well, from UX designer standpoint the string should be fixed regardless of its origin :)
<jibel> on 2 of my systems running Quantal, usb keyboard doesn't work in grub. One system is a Mac mini, the other a generic PC with a BIOS and keyboard works fine before grub starts. Should I file a bug against grub, what info do you need ?
<cjwatson> Probably the known bug that it doesn't have EHCI support.
<cjwatson> (I don't know the number offhand.  IIRC it's fixed upstream.)
<vibhav> xnox: ping
<xnox> vibhav: pong
<vibhav> xnox: Are you working on https://bugs.launchpad.net/ubuntu/+source/avogadro/+bug/1016433 or should I try a merge?
<ubottu> Launchpad bug 1016433 in avogadro (Ubuntu) "please merge avogadro 1.0.3-5 from sid" [Wishlist,Triaged]
<xnox> vibhav: nope, not working on it. Merging it would be a great help!
<vibhav> thanks
<xnox> yofel_: are we ok stealing your merge of avogadro ^^^
<xnox> ?
<vibhav> Cool, the ubuntu delta patches are small too. Can be done easily
<xnox> vibhav: any of these: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=boost1.49 would be a great help in debian or ubuntu
<xnox> to finish off: http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
<mpt> glatzor, ideally, but I realize that's probably impractical
<highvoltage> the new square radio buttons look like tick boxes :-/
<mpt> New square radio buttons?
 * highvoltage gets a screenshot
<mpt> What do checkboxes look like, then?
<vibhav> something other than the new square radio boxes?
<mpt> (For screenshot purposes, Time & Date settings includes both)
<vibhav> xnox: Most of the changes are in debian, just the architecture is changed to i386, amd64 and powerpc FYI
<highvoltage> mpt: http://irc.jonathancarter.org/files/ubuntu/square-radio-buttons.png
<xnox> highvoltage: yeah I hate them too
<mpt> wtf
<highvoltage> that's what she said
 * mpt strolls over to chat with Cimi
<vibhav> highvoltage: Thats alien :\
<xnox> mpt: i think there is a serious bug with the theming engine currently
<xnox> mpt: see bug 1015497
<ubottu> Launchpad bug 1015497 in gtk3-engines-unico (Ubuntu Quantal) "Cannot select gtk dropdown list value in multiple applications: ubiquity, landscape client" [High,Confirmed] https://launchpad.net/bugs/1015497
<LordOfTime> is there a mailing list for the developers?
<LordOfTime> (there's a package maintained by "Ubuntu Developers" and I'd like them to take special attention to it)
<xnox> mpt: maybe you want to file another one as well, about e.g. other theming weirdness that you have been noticing.
<xnox> LordOfTime: all packages are maintained by Ubuntu Developers in the whole archive
<LordOfTime> xnox:  any central mailing list?
<xnox> LordOfTime: file a bug on launchpad against the correct package.
<LordOfTime> xnox: its *about* other bugs filed
<LordOfTime> i.e.
<highvoltage> LordOfTime: yep, it's the first result when you google 'ubuntu-devel mailing list': https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
<LordOfTime> there's a TON of crash bugs which refer to the 'cairo' libs
<xnox> that will get the attention of the correct people who are responsible for said package.
<highvoltage> LordOfTime: but if you want to report bugs then https://help.ubuntu.com/community/ReportingBugs may be of more use
<LordOfTime> xnox: if a bug crashes on some 'cairo' lib, then, would you refile *all* those crash bugs against 'cairo'?
<xnox> LordOfTime: yes. and we track those in the crash database errors.ubuntu.com those are automatically filed by apport
<LordOfTime> highvoltage: as an FYI: I'm on Bug Squad and BugControl
<highvoltage> LordOfTime: ok :)
<LordOfTime> i'm not *reporting* a bug, i'm trying to get the people who maintain the libs to check their package in each of these use cases
<LordOfTime> *because* of the influx of crash bugs relating to the cairo libs
<mpt> highvoltage, xnox: So the short answer is, it's Red Hat's fault
<xnox> LordOfTime: we don't refile, best mark duplicate of the master cairo bug, or get in touch to write a bug pattern for the launchpad bug bot to do it.
<ogra_> LordOfTime, raise the bug proirity and ask on the bug how the status is ... thats way more effective than spamming a mailing list about bugs
<mpt> highvoltage, xnox: They have changed GTK to make the radio button radius data private, so that theming engines (like light-themes) can't change it. Supposedly themes should use CSS instead, but there are things CSS can't do yet.
<LordOfTime> xnox: assuming there is a master bug (there isnt one)
<LordOfTime> i'll check on this one though
<ogra_> make one ... you are in bug control :)
<LordOfTime> :P
<xnox> ogra_: LordOfTime: and add bug-pattern-needed tag?
<mpt> highvoltage, xnox: The theme will look like that for a few more weeks at least.
<ogra_> sounds right
<highvoltage> mpt: aah. interesting. for a moment I was scared you were going to say they moved gtk to systemd or something
 * xnox can't remember the tag where bug pattern is needed.
<highvoltage> mpt: ok cool. I'm just glad it's not intentional :)
<xnox> mpt: is there a bug about the radius?
<mpt> xnox, it is a bug.
<xnox> mpt: launchpad bug # ?
<mpt> no idea, sorry
<larsduesing> Hi together
<mpt> Debconf question: I'm reading <http://www.fifi.org/doc/debconf-doc/tutorial.html> and it's not clear whether a Debconf prompt can appear at removal/purge time, or just during install/update. Anyone know?
<larsduesing> could anybody please nominate LP: #1007408 for precise?
<larsduesing> https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu) "aiccu.conf does not need server directive, while upstart script wants it" [High,Fix released]
<tumbleweed> larsduesing: nominated
<larsduesing> thanks tumbleweed :)
<larsduesing> patch is on the way
<larsduesing> oh.. btw... https://wiki.ubuntu.com/StableReleaseUpdates says I should make a debdiff for precise - would it not be more simple if I do a bzr-branch?
<larsduesing> (as I do not have any upload-rights... )
<cjwatson> If you like, sure
<mpt> ... I guess it's possible for a Debconf prompt to come up if removal fails <http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails>
<larsduesing> cjwatson: ok, thanks.
<larsduesing> ahem, cjwatson sorry, question: "Propose branch for merging" should I use the correct "precise-proposed" or "precise"?
<larsduesing> (for a SRU)
<xnox> larsduesing: if there is precise-proposed branch target that, if not target branch precise
<xnox> changelog should say precise-proposed
<larsduesing> xnox: changelog is so
<xnox> many sponsors prefer debdiffs for SRU
<larsduesing> oh
<xnox> because precise, precise-updates and precise-proposed can be easily superseeded by a security update
<xnox> and it's easier to check debdiff and re-apply debdiff in those cases
<larsduesing> ok, doing debdiff...
<xnox> and merge proposals generate a lot of .pc changes (if you add a patch) which is very painful to review for an SRU
<cjwatson> If you already have a branch you can just attach bzr diff output if you like
<cjwatson> Rather than bothering with generating a debdiff as such.  The exact patch-a-like format really doesn't matter much.
<xnox> larsduesing: I do $ bzr diff -rtag:1.0.1-1 | filterdiff -x ".pc*"
<xnox> where 1.0.1-1 is version in e.g. precise
<larsduesing> this was the reason I asked about bzr vs. diff :)
<xnox> to get the debdiff
<larsduesing> ok
<larsduesing> oh, cool... no more creating .dsc and such
<xnox> larsduesing: well I presume you did create .dsc and did clean builds and tested the debs, right? =)
<larsduesing> xnox: YES... :) for quantal
<xnox> it's just that you use vcs tools to create the diff ;-)
<xnox> larsduesing: but you should do the same tests for precise, if you are doing an SRU!
<xnox> ;-)
<larsduesing> xnox: *hiding*
<larsduesing> :)
<xnox> stuff can FTBFS in precise, yet building fine in quantal and vice versa =)
<larsduesing> give me a sec
<larsduesing> :)
<larsduesing> done
<larsduesing> (btw, FTBFS cannot happen, if I only change the upstart-script in debian/ )
<larsduesing> but, I know why I should do it
<xnox> slangasek: i am suspecting that autofs5 merge is expecting newer nfs-utils, as the mount.nfs -V call prints the version string in debian's 1.2.6 but not in ubuntu's 1.2.5-3ubuntu3. I can disable that call in autofs, until nfs-tools are merged
<xnox> this is where the extra forks come in in autofs breaking it's current upstart job
<xnox> unless you are still asleep after posting emails all night long =)
<vibhav> bryceh: ping
<larsduesing> ok... I should now search a sponsor :P
<larsduesing> any volunteer?
<vibhav> larsduesing: Ask the patch pilots
<vibhav> * pilot(s) even
<larsduesing> oh, pitti Hallo :) Would you please be so kind and sponsor my sru: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [Undecided,New]
<larsduesing> thanks vibhav
<vibhav> np
<larsduesing> (I should get accustomed to all this here... )
<vibhav> larsduesing: piiti's busy most of the time, you might want to suscribe ubuntu-sponsors too
<larsduesing> I know, did already
<slangasek> xnox: so which version of nfs-utils do we need? 1.2.6?
<larsduesing> vibhav: oh, should I add SRU- impact, testcase and regression to the description? thanks :)
<vibhav> np
<pitti> larsduesing: may I refer you to today's patch pilots? (SpamapS and cjwatson are on the calendar)
 * pitti waves goodbye, have a nice weekend everyone
<larsduesing> oeh
<larsduesing> pitti: you too
<larsduesing> so topic is wrong, pitti, SpamapS and cjwatson :)
<xnox> slangasek: yeap.
<xnox> pitti: can you do @pilot out ?
<xnox> larsduesing: yes you should all the mandatory sections for an SRU
<larsduesing> SpamapS or cjwatson: would you please be so kind and sponsor my sru https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 ? thans
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [Undecided,New]
<larsduesing> xnox: I did, but not in bug description
<larsduesing> but in a comment
<xnox> slangasek: I think I will upload new autofs, but with workaround to start daemon in foreground. then nfs-tools can wait & I need to patch autofs to support nfs-tools correctly anyway as that introduces extra forks which confuse upstart.
<slangasek> xnox: I can merge nfs-utils today
 * mpt wonders whether a debconf string prompt accepts multi-line input, or just single-line
<xnox> slangasek: ok. then I will see if I can move that fork later without breaking all of it.
<cjwatson> Sorry, I'm going to have to shift my patch piloting for today
<xnox> slangasek: actually it only wants 1.1.1 . My new question is, why does `mount.nfs -V` on ubuntu does not print version string?
<slangasek> xnox: ah
<xnox> yet it does on Debian....
<slangasek> xnox: good question
<xnox> slangasek: furthermore, I just want to patch that code out of autofs because (a) 1.1.1 is acient and pre-dates hardy (b) 2.6.22 kernel is acient as well and pre-dates hardy
<xnox> and I can avoid fork
<slangasek> xnox: ok, sounds good to me
<vibhav> Is it right to call an ubuntu delta a fork?
<vibhav> of the package
<vibhav> in Debian
<slangasek> vibhav: "fork" implies the divergence is long-term, with no (or minimal) fixes flowing back between the two branches
 * xnox used word fork, as in UNIX process fork which is confusing an init system
<slangasek> but yes, xnox means fork() :)
<SpamapS> larsduesing: I don't know if I'll get to it today, but I'll look at it soon. Sponsorship queue is a bit backed up right now.
<vibhav> slangasek: ah, got it. thanks
<larsduesing> SpamapS: take your time (it's near week-end after all :-) )
<xnox> slangasek: and I will file a bug about `mount.nfs -V` not returning a version string =)
<slangasek> xnox: sounds good
<slangasek> xnox: note that the usage says 'mount.nfs remotetarget dir [-rvVwfnsih]'... if you do 'mount.nfs foo: /bar -V' you get a version string ;P
<xnox> wow! https://launchpad.net/~/+upcomingwork
<vibhav> xnox: neat trick
 * xnox head -> desk
<vibhav> xnox: why?
<larsduesing> xnox: all clear... So I do not have anything to do? :-)
<xnox> larsduesing: what's the bug # ? =)
<larsduesing> (what would occur there?)
<larsduesing> which bug # ?
<xnox> larsduesing: for the SRU
<larsduesing> 1007408
 * xnox thought you wanted a sponsor
<xnox> larsduesing: bug 1007408 will print me a link =)
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [Undecided,New] https://launchpad.net/bugs/1007408
<xnox> tadah!
<larsduesing> oh ok... sorry... was about the "upcomingwork"
<larsduesing> ah.. LP: #1007408 doesnt work
<larsduesing> but bug 1007408
<xnox> larsduesing: oh upcomingwork shows bugs & blueprints which you, the logged in user needs to work on.
<larsduesing> won't work too...
<larsduesing> bug 1007408 is boring *ubottu doesn't like me*
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [Undecided,New] https://launchpad.net/bugs/1007408
<larsduesing> oh..
<tumbleweed> meh, need to milestone my blueprints for them to appear in upcomingwork
<larsduesing> sorry for spamming
<xnox> tumbleweed: it doesn't show, *cough* overdue work....
<xnox> larsduesing: i wondering if I should sponsor this into proposed
 * xnox ponders
<larsduesing> as far as I read, yes...
<slangasek> xnox: nfs-utils mount.c has this at the top, so I don't see how this would work any better in debian... http://paste.ubuntu.com/1054411/
<larsduesing> "Upload the fixed package to release-proposed with the patch in the bug report, a detailed and user-readable changelog, and no other unrelated changes. Make sure that:"
<larsduesing> https://wiki.ubuntu.com/StableReleaseUpdates
<xnox> slangasek: is autofs upstream known to be compatible with anything but it's own hand compiled dependencies?
<slangasek> xnox: I have no idea; I haven't used autofs in about a decade
<xnox> slangasek: that's about right when they did last stable release, so you are fairly up to date ;-)
<slangasek> xnox: is autofs 5 not stable yet? :)
<xnox> slangasek: if stokachu is still patching it & I am still patching new upstream.....
<slangasek> heh
<vibhav> slangasek: you there
<slangasek> vibhav: me, here?
<vibhav> slangasek: Im merging aalib (you have touched it last in ubuntu) from sid, is that fine
<zul> pitti: i think i answered your questions in my last email i sent to the tech-board but it needs to be let though the moderated-queue
<slangasek> vibhav: yes, certainly
<vibhav> thanks
<rtg> kenvandine, shall I just let you fix chromium-browser ? I'll go on to something else.
<kenvandine> i'd rather not :)
<kenvandine> i'll send the changes i have to micahg
<rtg> kenvandine, no problem.
<stgraber> zul: I've let them through
<zul> stgraber: thanks
<infinity> Riddell / ScottK: Can either of you tell me if ktp-contact-applet is obsolete (perhaps replaced by ktp-contact-runner?).  It was the only thing not revision bumped for the ktp-common-internals transition, and I'm wondering if it should just be removed.
<ScottK> infinity: That's a Riddell question.
 * infinity throws a cat at Riddell.
<Riddell> infinity: hmm ktp-contact-applet is part of upstream's 0.4, let me investigate
<infinity> Riddell: Kay, then the (really nicely-handled otherwise, BTW) transition was just missing an upload, I suspect.
<infinity> Riddell: Please fix and/or advise. ;)
<AnAnt> Please sponsor LP #1014705
<ubottu> Launchpad bug 1013258 in skype (Ubuntu) "duplicate for #1014705 Please update to new upstream v.4.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1013258
<bdmurray> superm1: do you have an idea of how much space dkms needs in /tmp?
<bdmurray> I'm looking at bug 1011662
<ubottu> Launchpad bug 1011662 in update-manager (Ubuntu) "space requirement for /tmp may be insufficient" [Medium,New] https://launchpad.net/bugs/1011662
 * xnox 0_0
<superm1> bdmurray: i think that should depend upon if DKMS packages are using it at all
<SpamapS> hmm...
<SpamapS> package-import.ubuntu.com doesn't show a juju error, but juju's package branch is out of date in quantal
<ScottK> SpamapS: Did you get my ping about your python-qt4 upload for lucid-proposed?
<SpamapS> ScottK: probably not. ??
<SpamapS> Did I do it wrong? :-P
<ScottK> SpamapS: OK.  In the bug you said you were uploading it, but I don't find it.  Please don't upload that package as I posted the relevant bits of the diff in the bug.
<SpamapS> ScottK: yeah something wrong with the version
<ScottK> OK. Either you can do a revised upload and I'll review it or the reverse.  I agree it's an important bug to fix.
<SpamapS> ScottK: hrm, I missed the two features in my first review. I don't know, is that enough to force a cherry pick?
<SpamapS> ScottK: this is where I hate having discretion. ;)
<ScottK> SpamapS: It's not just that, it's all the doc regeneration and such.
<ScottK> If the actual fix weren't obvious, I'd say go for it, but since it is in this case, I think a patch to fix the actual problem is better.
<ScottK> The feature changes are small extensions and low risk, so I wouldn't mind those, but SRU are supposed to be minimal.
<SpamapS> ScottK: yeah I agree.
<SpamapS> ScottK: and the reason I missed the features was that I was filtering the diff aggressively. Exactly the kind of thing I usually refuse to do in SRU review :)
<ScottK> I'd prefer you upload and I review if that's OK.
<bdmurray> superm1: could you elaborate?
<glatzor_> mpt, hopefully apt will get a better error message handling in the next years
<glatzor_> mpt, there is also intrest from upstream, since raised errors are block boxes internally too
<glatzor_> black boxes
<adam_g> ice
<slangasek> xnox: fwiw, the mount.nfs -V looks to be broken in 1.2.5 and fixed in 1.2.6
<bdmurray> slangasek: how can find the version of apt for the lucid upgrader?  comment #18 in bug 541595
<ubottu> Launchpad bug 541595 in dpkg "[Master] package failed to install/upgrade: package is already installed and configured" [Undecided,New] https://launchpad.net/bugs/541595
<xnox> slangasek: yeah same conclusion here, but I didn't dwell too much into it.
<slangasek> bdmurray: not sure I understand the question... you're not asking for the version numbers from /var/log/dist-upgrade/main.log, I guess?
<slangasek> oh, you're referencing my own comment, heh
 * slangasek reads
<bdmurray> trolling through the dupes I found one or two with 0.8.16~exp12ubuntu6~upgrade1
<bdmurray> er upgrader
<bdmurray> and I wonder if that is the most recent
<slangasek> bdmurray: the source packages in lucid-updates are release-upgrader-apt and release-upgrader-python-apt; release-upgrader-apt is at version 0.8.16~exp12ubuntu6~upgrader1
<bdmurray> hmm
<slangasek> bdmurray: only one or two, though, out of 8 billion duplicates?
<bdmurray> 2 man!
<slangasek> bdmurray: might be worth forking those off to a new master bug?
<slangasek> since it kinda sounds like the issue is *mostly* fixed in the new version
<bdmurray> both are from the same person so I am getting skeptical
<bdmurray> slangasek: the first error is:
<bdmurray> dpkg: dependency problems prevent configuration of libgcc1:i386:^M
<bdmurray>  libgcc1:i386 depends on libc6 (>= 2.2.4); however:^M
<bdmurray>   Package libc6:i386 is not configured yet.^M
<bdmurray> dpkg: error processing libgcc1:i386 (--configure):^M
<bdmurray>  dependency problems - leaving unconfigured^M
<slangasek> bdmurray: erm, that's a strange error to be hitting
<slangasek> bdmurray: which bug # is this on?
<bdmurray> bug 969536
<ubottu> Launchpad bug 541595 in dpkg "duplicate for #969536 [Master] package failed to install/upgrade: package is already installed and configured" [Undecided,New] https://launchpad.net/bugs/541595
<bdmurray> that really wasn't very helpful
<melodie_> hi
<slangasek> bdmurray: so libc6 and libgcc1 have a circular dependency relationship; that probably has something to do with it
<slangasek> bdmurray: and the bit triggering the "already installed and configured" is the hostname package, which has a pre-dependency - I think this is the same symptom but a separate bug
<bdmurray> slangasek: okay, I'll pull the two of them out then and think about the pattern for these
<SpamapS> slangasek: if we build mysql with debug symbols, (-DWITH_DEBUG=ON) will the binaries be stripped into dbgsym packages properly?
<SpamapS> I've never fully grasped how that works exactly
<SpamapS> dh_strip -a is called..
<slangasek> SpamapS: dh_strip will strip them, yes, and pkgbinarymangler will ensure that when dh_strip is called, the symbols are saved off
<SpamapS> but isn't that just for normal symbols, not full "-g" debugging symbols? or does that result in the same thing?
<SpamapS> "typing it out loud"
<SpamapS> I think I get it
<SpamapS> slangasek: ok, so I think we should probably just do that then.
<ScottK> SpamapS: I like that diff a lot better.  Thanks.
<SpamapS> ScottK: NP, I like it better too. :)
<SpamapS> shocking how long that package took to test build
<SpamapS> Starting to think I should invest in a local build machine with some ridiculously fast i7 CPU's
<xnox> SpamapS: use cloud VM
<SpamapS> I do
<SpamapS> a lot actually
<SpamapS> c1.medium is usually enough
<SpamapS> its often a lot slower than my Core2Duo 2.53Ghz cpu's though..
<xnox> SpamapS: due to I/O - instance storage?
<SpamapS> no, due to the CPU being about half as fast
 * xnox has an i5 but not enough RAM =(
<SpamapS> I have 4GB .. which is fine
<rtg> infinity, what is the difference between 'Section: restricted/metapackages' and just plain 'Section: metapackages' ? Does it have any relevance in Ubuntu?
<infinity> rtg: Yes, the bit before the / indicates the component.
<infinity> rtg: And, while we have some pretty wildly fun bugs surrounding how we deal with that, our upload queue is meant to respect it, so I don't have to do as many manual overrides. :P
<infinity> rtg: (cjwatson is working on fixing those bugs)
<rtg> infinity, herton noted that the linux-powerpc, linux-powerpc64-smp and linux-powerpc-smp meta packages are all in the restricted component.
<infinity> rtg: In the archive, or in the packaging?
 * infinity looks.
<rtg> infinity, in the packaging
<melodie_> have someone noticed something strange with the completion in gnome-terminal, in Precise ?
<melodie_> I was using a gnome/openbox session and I could not get correct completions on the path of the directories...
<infinity> rtg: Right, that was correct back in hardy, when those packages depended on LRM (and were, in fact, in the restricted component), it's certainly wrong now, when they're in main.
<melodie_> ie : "cat /home/user (here a blank whereas I was hitting tab to get more)
<rtg> infinity, ok, I'll get that fixed.
<melodie_> I am asking because I can't check again now at home, I was in an enterprise for a sort of "test week", before entering a training next autumn
<melodie_> I don't have the same setup here.
 * xnox changelogs are alive!!!! =)))) YEAH!
<melodie_> :p
<melodie_> is there anyone here who likes openbox ? (this type of question can't hurt I suppose)
<kees> hallyn: if I make changes to /etc/cgconfig.conf, what do I need to to do get those reflected on the running system?
<xnox> is there a bug number on launchpad for fixing changelogs.ubuntu.com?
 * xnox has many reports to file as duplicates
<xnox> as in mark as duplicates
<hallyn> kees: not sure.  it'll be moot soon, libcgroup in debian just disabled all of the initscripts
<hallyn> kees: hm, depending on the changes you can try 'restart cgconfig'
<hallyn> but some changes in composition of cgroups, the kernel won't allow without a reboot
<kees> hallyn: hrm... I'm getting:
<kees> Loading configuration file /etc/cgconfig.conf failed
<kees> Cgroup mounting failed
<kees> I'm so confused :P
<kees> I don't feel like this /etc/cgconfig.conf is very complex at all.
 * xnox found it.
<hallyn> kees: can you pastebin the new cgconfig.conf?
<hallyn> kees: check syslog.  my guess is that you're changing the cgroup composition...
<kees> http://pastebin.ca/2163955
<kees> I've isolated it to the browser ... memory {} section
<kees> the failure output from that tool is not great :)
<kees> "memory.memsw.limit_in_bytes" seems to be the bad line
<kees> which makes no sense to me... I see it there.
<hallyn> kees: is 3G valid?
<hallyn> you might have to enter it in bytes, for real
<kees> it works for memory.limit_in_bytes but not memory.memsw.limit_in_bytes ?
<hallyn> (can test on thecmdline)
<hallyn> <shrug>
<kees> how do I test on command line?
<hallyn> not inconceivable,
<hallyn> mkdir /cgroup/ab;  cd /cgroup/ab; echo 3G > memory.memsw.limit_in_bytes
<hallyn> yeah fails here
<kees> worked fine for me
<hallyn> works for me with memory.limit_in_bytes, failed with memsw
<kees> oh how odd...
<kees> so
<kees> 2G worked, 3G didn't
<hallyn> oh is memsw swap?  maybe i just don't have enough :)
<kees> er, other way around
<kees> AH
<hallyn> to the kernel code, batman
<kees> this is bizarre
<kees> I bet memory.memsw.limit_in_bytes must be >= memory.limit_in_bytes
<hallyn> kees: yup, comment in code says /* We have to guarantee memcg->res.limit < memcg->memsw.limit.
<kees> memory.memsw.limit_in_bytes needs to be set first.
<kees> the cgconfig.conf file seems to not be able to handle ordering?
<hallyn> uh, no,
<hallyn> you mean memory.limit_in_bytes must be set first
<hallyn> else it is (unsigned)-1, and memsw.limit_in_bytes can never be > it
<hallyn> kees: so reverse the order of your entries, and make sure memsw is >, not >=
<hallyn> i'm not guaranteeing that libcg will honor the ordering :)
<hallyn> i *am* guaranteeeing that soon it won't matter unless you hand-reenable the initscripts
<kees> heh
<kees> but 3G works on the command line...
<kees> /sys/fs/cgroup/memory/browser# echo 3G > memory.limit_in_bytes
<kees> /sys/fs/cgroup/memory/browser# echo 3G > memory.memsw.limit_in_bytes
<hallyn> huh, ok :)  i was going based on the comment in the code (not even the code itself), so you win :)
<kees> regardless, libcg appears to continue to fail :(
<hallyn> yup works for me too
<kees> well now /usr/sbin/cgconfigparser doesn't work at all, even with that memory section removed
<kees> Cgroup mounting failed
<kees> wtf does that mean?
<hallyn> kees: i have some work to do to look at it, but jbernard was mentioning incorporating the cgroup-lite startup in cgroup-bin.  It sounds like you need something more flexible.  Perhaps we should talk next week about making cgroup-lite's startup more flexible
<kees> sure
<hallyn> well do you still have memory cgroup mounted?
<hallyn> (apart from cgconfig's mount)?
<kees> ah, my shell was messing with it.
<hallyn> it works now?
<kees> as long as I keep memory.memsw.limit_in_bytes commented out of cgconfig.conf, yes
<hallyn> <frown>
<hallyn> actualy if you want the user/group stuff like you're showing, then you'll always need to re-enable the libcgroup daemon (which is inherently buggy), so no sense talking about cgroup-lite flexibility
<kees> I really don't understand what's going on here at all.
<kees> I renamed "browser" to "monkey", and it won't load again.
 * kees just adds manual mkdir and echo to the pre-start ...
<hallyn> kees: are you wanting every task you own to end up in browser group?
<hallyn> (i'm not even familiar enough with cgconfig.conf go know if that's what you're doing, but it looks like it to me)
<kees> hallyn: no, I'm trying to define the "browser" group, so that my cgrules.conf line works:
<kees> kees:chrome memory browser/
<dobey> barry: around?
<barry> dobey: hi
<dobey> barry: https://plus.google.com/103117938079967018309/posts/2CET5s46EXa
<barry> dobey: you say that in py2 it's a unicode but in py3 it's a str.  isn't that the same thing? ;)
<barry> or did you want it to be a bytes in py3?
<barry> in which case, use os.environb.get()
<dobey> it's unicode in py2 because i added the unicode_literals future import i guess. so it didn't used to be unicode, but a str in python2 also
<dobey> but os.environb doesn't exist in python2
<barry> dobey: i guess the question is, what do you want? :)  obviously, consistency b/w 2 and 3, but bytes or unicodes?
<dobey> barry: well i need to return something encoded in utf-8. internally i don't really care, as long as it works in both pythons
<barry> dobey: so, maybe something like this:
<barry> try:
<barry>   env = os.environb
<barry> except AttributeError:
<barry>    env = os.environ
<barry> path = env.get(key)
<barry> blah blah...
<dobey> not sure that works
<infinity> Riddell: Thanks for the new ktp-contact-applet .. If only it built. ;)
<alkisg> Hi, which component is responsible for showing the user name in the upper panel in gnome-session-fallback? It's not working in LTSP fat clients, and I'd like to look at its source...
<infinity> alkisg: It only shows the username if the user switcher sees more than one available account.
<infinity> alkisg: On a default Ubuntu install, that's your user, and "guest".
<alkisg> infinity: ah, thank you, that explains it
<infinity> alkisg: If you disable guest, it goes away (until you add more users)
<alkisg> So the only way around it would be to add a fake guest user for ltsp fat clients?
<infinity> alkisg: If they're all logging in with the same userid, it wouldn't matter anyway, would it?
<infinity> alkisg: And if they're not (but you're using network auth, perhaps?), exporting a user list to the client would suddenly make it populate.
<infinity> Riddell: (ktp-contact-applet Fixed, BTW)
<alkisg> infinity: we're using ssh for authentication, and we're copying only the user entry from the server passwd
<infinity> alkisg: Ah.  Right, then the user switcher just isn't going to be useful in that case, I suspect.  Not without some hacking.
<alkisg> Displaying the username is very useful for classrooms, so that the teacher can see the pupil names
<alkisg> infinity: which source package is that in?
<infinity> alkisg: It's part of indicator-session, I believe.
<alkisg> Thank you very very much :)
<barry> kenvandine: ping
<infinity> barry: Say, did you ever find 20 seconds to see if libpwquality was py3-able with minimal effort?
<infinity> barry: Not looking to have it ported, just enabled if it's trivial.
<barry> infinity: i did not, sorry
 * cjwatson wonders how exactly translations_* (DDTP) uploads manage to get into the archive
<cjwatson> They appear to be constructed as more-or-less-sourceless binary uploads
<xnox> does live-cd has all the packages installed, or does it contain packages which are not installed but available from the cd?
<cjwatson> Oh.  Wow.  Apparently you're allowed to do that if the upload has precisely one custom upload file and nothing else.
<cjwatson> Some packages are only conditionally installed and aren't installed in the squashfs.
<cjwatson> Language packs are a good example.
<infinity> cjwatson: Cute trick.  I suppose we just assume these uploads are their own source?
<infinity> cjwatson: Which is true for translations tarballs, of course.
<infinity> (more or less)
<bdmurray> slangasek: looking at bug 969536 some more I found some corrupt package error messages
<ubottu> Launchpad bug 969536 in xserver-xorg-video-vesa (Ubuntu) "package xserver-xorg-video-vesa 1:2.3.0-7build2 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/969536
<cjwatson> infinity: They have no SPPH at all
<cjwatson> infinity: I didn't even know that was possible
<cjwatson> infinity: I care because this means I can't easily fix bug 827941 (the copier really kind of wants there to be an SPPH), so I think I'll have a word with mvo next time I see him and find out if we can reorganise this
<ubottu> Launchpad bug 827941 in Launchpad itself "Copy ddtp-translations uploads to new distroseries" [High,In progress] https://launchpad.net/bugs/827941
<slangasek> bdmurray: oh?
<slangasek> ah, so there are
<bdmurray> bryceh: do you find the auto tagging of regression-update by your package hook to be accurate?
 * xnox may have been not passing -vW.X-YubuntuZ before uploading merges....
<infinity> xnox: I forget occasionally too.  We won't kick you out of the club just yet.
<xnox> infinity: ok. thank you.
 * xnox was getting really worried now
<bryceh> bdmurray, it's doing that based on Q&A from the user, so accuracy is subject to pebkac.
<bryceh> bdmurray, however I haven't run across any problems so far (knock on wood)
<bryceh> bdmurray, the kernel used to ask the user if it was a regression, and presented them with a list of different types of regressions
<bryceh> bdmurray, my approach is a bit better in that I can examine the system to see what class the reporter fits in, so don't need to present so many choices.  I think this is a better way of doing it.
<bryceh> redundantly, I think I am being redundant
<bdmurray> I ask because we are looking at subscribing the ubuntu sru team to bugs tagged regression-update and regression-proposed
<bdmurray> and I saw bug 1016771 tagged regression-update
<ubottu> Launchpad bug 1016771 in xorg (Ubuntu) "Xorg freeze" [Undecided,New] https://launchpad.net/bugs/1016771
<bdmurray> bryceh: ^ and that seemed incorrect to me afaict
<bdmurray> I wonder if there is a way to see if the pacakge is from -updates
<bryceh> bdmurray, you thinking like parse apt-cache policy?
<bryceh> of course in this particular case that would lead us astray; the regression wouldn't be in the 'xorg' package, but rather the kernel (or maybe mesa or -intel)
<bdmurray> bryceh: well you have all those packages in the description â¦
<bdmurray> so if none were -updates remove the tag regardless of what they say
<bryceh> hmm, maybe
<bryceh> bdmurray, I'll give it some thought and rework it to be more sensible
<bdmurray> bryceh: well if there isn't a terrible volume of false positives I wouldn't work too hard on it
<bryceh> bdmurray, heh, well do you want me to work on it or not?  ;-)
<bryceh> actually independent of this it would be helpful for debugging purposes to better identify what packages were updated during the time frame
<hallyn> kees: so for what you're doing, would you be happy with a chrome wrapper which sticks itself into the right cgroup?
<bryceh> bdmurray, do you happen to know if there are a lot of regression-update X bugs ?  I used to have a report that showed this but seems I'm not running it now.
<bdmurray> bryceh: no, not really
<bdmurray> what in the world?
<bdmurray> bug 1012195
<ubottu> Launchpad bug 1012195 in compiz (Ubuntu) "[needs-packaging] Wishlist: Missing plug-In: Photoweel" [Wishlist,New] https://launchpad.net/bugs/1012195
<bdmurray> how is that regression-everything
<bdmurray> and of course there are dozens of missing plug-ins tagged this way
<xnox> stgraber: can you look at https://bugs.launchpad.net/ubuntu/+source/qpid-cpp/+bug/945365/comments/1 it's an IPv6 test failure
<ubottu> Launchpad bug 945365 in qpid-cpp (Ubuntu) "qpid-cpp version FTBFS 0.14-2&armhf, 0.16-6&amd64" [High,Confirmed]
<kees> hallyn: yeah, but that means messing with packaging. I've got it working fine with mkdir/echo stuff now. *shrug*
<kees> hallyn: seems like this is a regression from lucid where that file is valid.
<infinity> xnox: Those are, arguably, two bugs (though, I suppose fixing them both at the same time would be nice)
<infinity> xnox: Oh, and the ARM alignement bug seems to have been fixed, which makes adding your comment to it even more confusing.
<xnox> infinity: right so, i'm gonna rename that bug back and close it, and file a new one
<xnox> infinity: and i should be less gready and open bugs instead of piggy-back
<infinity> xnox: It's entirely possible the buildds just can't resolve ::1
<infinity> xnox: Though, shouldn't that be resolvable at the glibc level without any help from anything else?
 * infinity pokes this with a stick.
<xnox> infinity: and debian's buildd pass fine
<infinity> xnox: Indeed.
<xnox> https://bugs.launchpad.net/ubuntu/+source/qpid-cpp/+bug/1016778
<ubottu> Launchpad bug 1016778 in qpid-cpp (Ubuntu) "qpid-cpp version FTBFS ipv6 test case fails" [Undecided,Confirmed]
<hallyn> kees: have you filed a bug?  i'm not a big fan (an dit's in universe) but i'm interested in taking a look at some point
<hallyn> (again, it'll be short-term since we're nixing it :)
#ubuntu-devel 2012-06-23
<kees> hallyn: haven't filed one. if it's changing, it's probably not worth it.
<hallyn> not changing in precise though
<hallyn> so there it may be worth fixing
<infinity> xnox: Well, comfortingly, it fails in my fresh sbuild chroot here too, so it's not something specifically broken with my buildd chroots.
<xnox> infinity: we knew that. my bug comment is from my pbuilder
<infinity> xnox: pbuilder?  Ew.
<xnox> infinity: personal scripts & hooks & break out shell
 * xnox nom nom
<stgraber> xnox: will check later (at the pub)
<xnox> it is slow, I will migrate to mk-sbuild
<xnox> stgraber: ok. new bug number bug 1016778
<ubottu> Launchpad bug 1016778 in qpid-cpp (Ubuntu) "qpid-cpp version FTBFS ipv6 test case fails" [Undecided,Confirmed] https://launchpad.net/bugs/1016778
<infinity> stgraber: You mean, you'll check at the pub, or you're at the pub now and he should piss off? :)
<stgraber> infinity: the later
<hallyn> stgraber: bottoms up!
<infinity> xnox: Further data point for your bug, an sbuild run on a debian chroot (on my Ubuntu system) works fine.  So, it's definitely not the base system's network (or lack thereof) in any way.
<xnox> infinity: ok
<infinity> xnox: Which might make this a glibc bug... Cause I'm not sure what else would be involved in address resolution once we know the network itself is fine.
<xnox> infinity: can you decruft rheolef on armel and armhf. It no longer builds for those arches and I want to get rid of boost1.48
<xnox> or shall we keep them around until all other boost packages are transitioned to boost1.49
<xnox> boost1.46 that is, well all old boosts
<infinity> Leaf package, no rdeps.  Sure.
<xnox> infinity: thanks.
<infinity> xnox: Done.
<infinity> xnox: Of course, the right answer would be to fix the friggin' package to compile on ARM again, but I can't be bothered to argue with some random leaf node in universe that we're autosyncing.
<xnox> infinity: true. can't wait for my arm hardware =)
<xnox> i have yet to do any arm development
<infinity> Chroot, qemu-user-static, go.
<infinity> Hardware isn't required for most bugs.
<xnox> ?
 * xnox goes to search for armhf chrrot
 * xnox goes to search for armhf chroot
<infinity> xnox: ubuntu-core works.
<infinity> xnox: Unpack core, apt-get install qemu-user-static, cp /usr/bin/qemu-arm-static chroot/usr/bin/qemu-arm-static && chroot chroot su -
<infinity> xnox: And then note that you're in an ARM chroot, running ARM binaries.
<infinity> xnox: And rejoice.
<xnox> nice
<hallyn> that is cool :)
<hallyn> (presumably smaller than a arm lxc container too)
<infinity> It's pretty slick when paired with sbuild and such too.
<hallyn> (as that's a debootstraped image)
<infinity> Although, if you have real hardware, a PandaES still outperforms any shiny new i7 with emulation.
<infinity> The Intel box will come close, though.
<infinity> hallyn: Core is "debootstrap --variant=minbase", not sure what lxc's default is.
<infinity> hallyn: Probably bigger, since it likes to have a functional init system and things.
<infinity> Though, maybe similar.
<hallyn> i think we dropped minbase
<infinity> "we" being the lxc setup?
<hallyn> yeah i've tried a huge ec2 image emulating arm.  was ...  tolerable :)
<hallyn> yup
<infinity> Yeah, I should probably fiddle with lxc more sometime, but I so rarely need that level of isolation.
<infinity> And chroots just feel cleaner when you don't actually need the process isolation.
<xnox> infinity: wow!
<xnox> i'm loving it!
<infinity> xnox: Note that mk-sbuild will do that automagically for you (if you mk-sbuild --arch=armhf [...]) if the host can't run the target requested, it uses qemu-debootstrap, and gives you the shiny.
<infinity> I assume lxc does the same.
 * xnox likes mk-sbuild
<xnox> but that will not work for kfreebsd will it?
<xnox> but still freaking awesome
<infinity> xnox: Won't work for non-linux, no.  For that, you need a full qemu, so you can boot another kernel.
<infinity> xnox: qemu-user-static is just some really clever syscall trapping and emulation.
<xnox> infinity: how does one become an archive admin?
<infinity> xnox: We invite you to be trained and help out, based on how awesome we think you are.
<infinity> Ish.
<xnox> well, I am very green to do that yet.
<xnox> I have never done a security update yet for a stable release.
<xnox> infinity: can I steal sinfo merge?
<xnox> tbh what is the expiry date on TIL
<xnox> and is TIL: last upload or last merge
<infinity> xnox: TIL is last upload, from the POV of automated tools, but I prefer to informally say it's last merge if it's something we carry a significant delta for.
<infinity> xnox: YMMV.
<infinity> xnox: On the other hand, the previous upload was also just a minor bugfix.
<xnox> infinity: if bzr merge gives no conflicts and it's in universe and we only carry patches for --as-needed..... i'm just gonna do it.
<xnox> nmu to debian =) kidding. needs forwarding.
<infinity> I wish doko had fixed the non-RC as-needed bug in his RC gcc-4.7 NMU. :P
<infinity> Given the upload history, I'd be tempted to NMU for the as-needed bug too, and just sync it.
<infinity> But that might make someone grumpy.
<xnox> btw for as-needed usertag is the user debian-gcc@ or some random guy's email address
<xnox> and why is it not a release goal for debian!
<xnox> wheezy+1?!
<infinity> Because Debian's toolchain doesn't default to as-needed.
<xnox> ok, but the usertag question is still valid
<infinity> I might just NMU for Debian bug 638598.
<ubottu> Debian bug 638598 in sinfo "sinfo: FTBFS with ld --as-needed" [Normal,Open] http://bugs.debian.org/638598
<infinity> The maintainer is unresponsive.
<infinity> xnox: Hrm, what's wrong with the usertag?
<xnox> well there are two
<infinity> User: debian-gcc@lists.debian.org
<infinity> Usertags: ld-as-needed
<infinity> Seems reasonable.
<infinity> You're not filing a bug that's already filed, are you? :P
<xnox> http://wiki.debian.org/ToolChain/DSOLinking
<xnox> says User: peter.fritzsche@gmx.de
<infinity> as-needed and no-add-needed aren't the same thing
<infinity> But yeah, weird that different tags are using different addresses.  Whatever.
<infinity> xnox: Meh, on second thought, I won't bother NMUing.  Just merge.  If this maintainer ever wakes up, we'll know, and if he doesn't, it doesn't matter. :P
<xnox> mia ping
<infinity> When as-needed becomes RC in Debian, I'll NMU the next day.
<infinity> Don't much care for starting a potential flamewar right now if some pedant notices the upload on -changes and whines about NMUs for non-RC bugs.
<infinity> Especially if it's someone Ubuntu-hostile who goes off about "why are we NMUing for things that only affect Ubuntu's toolchain?!"
<xnox> well let's not go into the gcc4.7 'acceptance' by some
<Kano> hi, did anybody really test secure boot yet? maybe using the intel testing platform
<infinity> tumbleweed: Man, pypy sure hates armhf.  Still building.  Is it doing crazy on the fly optimisations or something, and having a field day with the realisation that armhf has 16 more registers to play with than armel?
<tumbleweed> infinity: it doesn't jit for ARM yet
<tumbleweed> the build is presumably not fitting in RAM at all
<tumbleweed> do all the panda buildds have the same amount of RAM?
<infinity> tumbleweed: Well, I'm just curious why the armhf build would be taking so much longer than the armel one.  Same hardware.
<tumbleweed> no idea :/
<infinity> tumbleweed: Identical hardware.  The only difference is toolchain (armv5t, float=soft, versus armv7-a, float=hard)
<infinity> Oh well.  It's a curiosity more than anything else.  If it doesn't timeout and eventually completes, yay.
<tumbleweed> this stage of the build translation is just converting the python to C which should be identical between armel and armhf
<tumbleweed> quite
<tumbleweed> (should be, but we know it's not a predictable build so, probably isn't)
<infinity> I was a 68k porter, waiting a week for a GCC build was the norm, this doesn't bug me.
<penguin42> infinity: Are you sure the same set of front ends are enabled on both of them?
<infinity> penguin42: For pypy?  I have no clue about it at all. :P
<penguin42> infinity: Oh sorry, I came in half way - I assumed it was the build of the toolchain you were comparing
<infinity> No.
<penguin42> infinity: in that case, hmm - same optimisation levels? Same gcc versions?
<infinity> It's the pypy build that's still trudging along on armhf a day after the armel one finished. ;)
<infinity> And yeah, they started at the same time (ish) with the same GCC and glibc and such.  And pypy itself appears to have no arch special casing for armel/armhf.
<infinity> So, I guess it just comes down to GCC on armhf being slower (which it is, because it thinks a bit harder), and ridiculong builds really exposing that.
<penguin42> yeh it was the 'thinks a bit harder' I was curious about; does the hf build have some of the optimisations on by default? I hadn't thought the hf v el itself should make much difference
<infinity> hf is v7, vfpv3-d16, hard-float, el is v5, soft.
<infinity> So, there's a fair difference there.
<infinity> From all the v7 optimisation, to suddenly, like, having a VFP, to oh hey, having 16 new registers to play with, etc.
<tumbleweed> thing is, it probably hasn't spent that time with gcc yet
<tumbleweed> that much time
<infinity> Oh, and thumb2 by default on hf.
<penguin42> infinity: Yeh, although I wouldn't have thought the vfp stuff would make that much compile time difference for most code unless it's all heavy fp;  hmm thumb2 might a bit
<infinity> tumbleweed: Could be that python's grumpy on hf, but I've not noticed that in other contexts.
<infinity> Anyhow.  I need sleep.  I'm sure the build will finish some day, and we can do a post-mortem.
<infinity> If only it had timestamps, so we could see where it spent most of its time and use it as the ultimate toolchain benchmark.
<penguin42> infinity: You have timestamps on th e.o's
<penguin42> the .o's
<cjwatson> penguin42: Only if those are preserved - we don't keep build trees
<cjwatson> They wouldn't be in final executables/.sos would they?
<penguin42> true; also I wasn't sure from the bit of the conversation that I saw whether the builds were on the same host; ARM boards vary quite a bit in pretty much every measure of performance
<cjwatson> Same type of board AIUI but not the same physical host
<Kano> cjwatson: what do you think about grub 2.00 / bzr
<Kano> cjwatson: it would help for better uefi support, mdadm/dmraid support
<Kano> cjwatson: mdadm even for isw (intel raid)
<Kano> also it is hard to get support for 1.99, the first comment is try latest beta or bzr
<melodie_> hi
<melodie_> I was wondering if someone could help me learn how to package configuration files for a program, one of these coming days ?
<penguin42> melodie_: There is a #ubuntu-packaging that might be more help for that
<melodie_> hi penguin42 : thank you very much !
<hippiehacker> https://gist.github.com/2978542 # live-build precise iso creation issue on precise... aany thoughts/direction?
<vibhav> bryceh: ping
<ClientAlive> Hi
<ClientAlive> I'm wondering about internships with Ubuntu. Can anyone help me with this?
<penguin42> ClientAlive: Canonical is the company behind Ubuntu, see www.canonical.com
<ClientAlive> right on
<ClientAlive> I know sometimes the listings/ information is pretty... err, eloquently worded. This is all new to me and sometimes I find it a bit challenging to translate the information to whether I'm really qualified to apply (or if I'd just be wasting people's time). Anyone here actually done an internship or is working with Ubuntu?
<tumbleweed> infinity: pypy failed :/
<alazare619> is ubuntu built with live-build?
<alazare619> or some other means?
<alazare619> what method of image creation does ubuntu and the respins use for making of there iso's
<alazare619> do you guys use live-build or some other for the respins and stuff
<alazare619> anyone in here!!!
<directhex> alazare619, the relevant people aren't around on a saturday night
<alazare619> dang :(
<infinity> tumbleweed: Aww.
<Debolaz> alazare619: The disadvantage of having a community composed of people with social intelligence; They tend to be social. :-)
<infinity> Debolaz: You take that back right now.
<Debolaz> :O
<infinity> ;)
 * Debolaz ponders starting to blog about stuff he finds annoying with ubuntu development. Which granted, isn't a very long list. But its still bloggable. :)
 * stgraber reads scrollback and pretends not to be around
<infinity> stan: *grin*
<xnox> infinity: stop talking to my housemate stan, instead of stgraber !
<xnox> =)
<infinity> xnox: Hahaha.  Oops.
<infinity> People shouldn't be allowed to have st<tab> nicks.
<xnox> infinity: yeah i get confused by that. I have switched xchat to autocomplete nicks based on last talked to instead of alphabetically
<xnox> so I don't have that problem, as much...
<penguin42> oh that's a neat trick
<infinity> Oh, I should see if irssi has a setting for that.  Probably does.
 * xnox goes back to reading weekend emails....
<infinity> Ahh, I probably just need to crank up the value of completion_keep_publics
<infinity> Or stop talking to more than 50 people between stgraber chats.
<xnox> =)
 * xnox wonders if I should start using irssi .... does it have emacs and remote messaging menu integration?
<stgraber> not sure for the emacs part (not an emacs user), for the messaging menu integration, I believe there are some scripts around for that and notify-osd integration
#ubuntu-devel 2012-06-24
<jtaylor> what is the reason gzip is not m-a foreign?
<larsduesing> are "Bugs" which are more a wishlist-item ok in launchpad? or how to handle them?
<larsduesing> (after reading https://dev.launchpad.net/BugTriage I'm not really sure..
<penguin42> larsduesing: Feel free to come over to #ubuntu-bugs for bug triaging
<badfox> i have .deb pkg and i wanna upload it into my launchpad
<larsduesing> oh, sorry.. :)
<SpamapS> badfox: do you mean a PPA?
<badfox> SpamapS,  No i am not its owner
<badfox> well lemme arrange it
<badfox> i have posted in #ubuntu-motu too
<badfox> SpamapS,  https://launchpad.net/ubuntu/quantal/+source/accountsservice/ now its version of Ubuntu is accountsservice 0.6.15-2ubuntu9 but i have its latest version accountsservice_0.6.21-1_i386.deb with me and how can i upload it .
<SpamapS> badfox: you are out of date, debian has 0.6.21-4
<SpamapS> badfox: all of that Ubuntu specific delta may be important too
<badfox> SpamapS,  No they have 21-4 patch
<badfox> but  source belongs to 21-1
<badfox> so deb came out as 21-1
<badfox> please tell me how can i upload it
<SpamapS> badfox: to Ubuntu?
<badfox> yes
<SpamapS> badfox: you need to explain why we can drop all of the extra Ubuntu changes
<badfox> Sp4rKy,
<badfox> Sp4rKy,  sorry wrong ping
<SpamapS> badfox: try 'requestsync accountsservice'
<Sp4rKy> :)
<badfox> Sp4rKy,  Thank you :)
<badfox> SpamapS,  i am new to all these
<badfox> SpamapS,  actually in launchpad i have seen that version difference is there between Ubuntu and Debian version
<SpamapS> badfox: but please look at the changelog of 0.6.15-2ubuntu1 through 0.6.15-2ubuntu9 to see what has been changed in Ubuntu
<badfox> so after taking source from Debian with grab script i have created .deb for it
<badfox> SpamapS,  ok so you saying that i cant upload it into Ubuntu but at least to my launchpad ?
<badfox> SpamapS,  Not possible ?
<slangasek> SpamapS, stgraber, bdmurray, RAOF: bug #1017001 is looking pretty serious; in addition to the two duplicates there, I think this matches another bug that bdmurray identified the other day about mishandling of circular dependencies on upgrade.  Do any of you know of recent SRUs of packages in the base system that might explain what's happening here?
<ubottu> Launchpad bug 1017001 in apt (Ubuntu Quantal) "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed] https://launchpad.net/bugs/1017001
<slangasek> bdmurray: ^^ this also means it would really be helpful if we could safely get apt clone data again for upgrades :/
<slangasek> bug #969536 being the other bug
<ubottu> Launchpad bug 969536 in apt (Ubuntu) "package xserver-xorg-video-vesa 1:2.3.0-7build2 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/969536
<slangasek> not as recent, and may or may not be the same root cause
<SpamapS> slangasek: looking now
<slangasek> ok
<SpamapS> slangasek: frankly, the flow of SRU's has been so intense, its hard to recall any single SRU :-P
<slangasek> SpamapS: unfortunately I'm going afk now for most of the day... if you can think of anything relevant though, highlight me and I'll try to look this evening
<SpamapS> slangasek: indeed, I will disappear soon too, but I'll dig around a bit
<slangasek> fwiw looks like jenkins doesn't see this issue. https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/
<slangasek> there are some upgrade failures on the lucid-universe test, but those are unrelated (the upgrade itself doesn't fail)
<SpamapS> slangasek: seems like its circular.. upstart depends on initscripts depends on upstart ...
<stgraber> slangasek: hmm, can't recall verifying any SRU that introduced a dependency change except for lxc and lxc just started depending on cloud-utils or something like that, so quite unlikely to be the cause
<stgraber> slangasek, SpamapS: wondering if these bugs are related to what we say in bug 937196 a while back (and never managed to figure out exactly why it's happening only in some cases and never on my machine...)
<ubottu> Launchpad bug 937196 in ifupdown (Ubuntu) "10.04 LTS -> 12.04 upgrade failed: ifupdown depends on upstart and initscripts but they are not configured" [High,Confirmed] https://launchpad.net/bugs/937196
<SpamapS> stgraber: its possible. Perhaps we should reason about it a bit and figure out which one should be pre-depends of the others
<BetaArk> H!
<IdleOne> BetaArk: This being the weekend and all it may take some time to get an answer. Just ask and be patient :)
<BetaArk> Anyone can help? I'm trying to compile ubuntu-gtk3 to have the overlay-scrollbars on my Archlinux-setup. I got gtk2 working with the overlay-scrollbars, but not with gtk3. How can I compile the latest gtk3 version and enable the overlay-scrollbar?
<BetaArk> IdleOne: Thanks :)
<ScottK> BetaArk: Wouldn't that better be asked on some Archlinux channel?
<BetaArk> ScottK: yes and no.. I want to ask if ubuntu still patches or patch diff in newer versions..
<alazare619> anyone in here
<alazare619> im trying to get a fresh chroot enviorment of ubuntu newest kernel in the chroot to compile into a iso
<alazare619> i suppose i could net install into a vbox and rsync it out of it to a chroot on my main drive but that seems hackish at best
<penguin42> alazare619: Do you know debootstrap?
<alazare619> yea i tried to debootstrap but it fails with the argument precise
<penguin42> what version are you running?
<alazare619> precise
<alazare619> sudo debootstrap --arch=i386 precise chroot
<alazare619> it failed
<alazare619> should i use pae instead of i386 since the new kernel is linux-image-generic-pae?
<penguin42> hmm, I'm not sure I have a precise install to hand, my quantal version certainly has it
<penguin42> no, I don't think that's any different for a debootstrap - but can you explain what you're trying to do with the kernel
<penguin42> alazare619: Do you have /usr/share/debootstrap/scripts/precise ?
<alazare619> iwell im trying to make a iso
<alazare619> same way xubuntu kubuntu etc are all made
<alazare619> from scratch wich requires a chroot
<alazare619> ive used live-build wich is similar for debian based before no problems  it uses debootstrap as well
<alazare619> i just want an iso wth just gnome-shell and my hand picked apps etc just for gnome-shell
<alazare619> nothing else no unity no nothing else but gnome-shell
<penguin42> alazare619: Hmm I don't know how the ISO builds work
<alazare619> https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
<alazare619> ooo now it resolves with arch i386
<alazare619> heh go figure
<KeithW> Hello -- I maintain the mosh package in Debian. Would Ubuntu entertain a request to sync the "testing" version into precise (universe), or are sync requests (for new versions) only for not-yet-released series of Ubuntu?
<infinity> KeithW: The latter.
<infinity> KeithW: Also, have you noticed the build failure with gcc-4.7 in precise on ARM?
<infinity> KeithW: I just saw that last night, haven't had a chance to look into it.
<KeithW> Yes, it's a bug in glibc that there is (I think) an open bug in Ubuntu for. It's been fixed upstream.
<infinity> KeithW: Oh, point me at the bug?  (I'm the eglibc maintainer)
<KeithW> https://bugs.launchpad.net/eglibc/+bug/1016349/
<ubottu> Launchpad bug 1016349 in eglibc (Ubuntu) "htons() returns wrong type on non-{i386,amd64} platforms" [Undecided,Confirmed]
<infinity> KeithW: Thanks.
<KeithW> Pleasure doing business with you!
<infinity> KeithW: Why do you want the sync to precise, BTW?  For the security/DoS issues, or just for new shiny?  I'm sure we can backport the DoS fix.
<KeithW> Just for the UI improvements and better error messages in 1.2, mostly. We didn't consider the repeated escape sequence issue to be a security-sensitive bug (and didn't do an emergency release on Debian either).
<micahg> KeithW: if there are new features in mosh, you can request a backport to precise with the requestbackport script in ubuntu-dev-tools (also available in Debian)
<infinity> (Which goes to precise-backports, not precise-updates)
<infinity> KeithW: Kay, yeah.  That would qualify as "new shiny", and not SRU-worthy. :)
<KeithW> The hassle is just that we get people with support requests for stuff that we made smoother in 1.2 (but they're running 1.1.3 from the precise repo). Would be more convenient for us if we could get everybody up to 1.2, but I understand that's not the way it works. :-) Thanks for explaining.
<infinity> KeithW: And thanks for the pointer to the glibc bug.
 * micahg has to try to process some of the backport backlog tonight
<KeithW> Anytime.
<micahg> KeithW: well, once it's in precise-backports, you can let people it's available there and that they can select the newer version in the Ubuntu Software Center (through a drop down) or their favorite package manager tool
<micahg> *people know
<infinity> And thanks for mosh, for that matter.  It's friggin' magic.  Love it.
<KeithW> Awesome!
<infinity> KeithW: One question, since I'm too lazy to read docs.  Can I get mosh to stop adding itself to my xterm titles?
<KeithW> Yes, in mosh 1.2. :-)
<infinity> Hah.
<KeithW> Set the MOSH_TITLE_NOPREFIX environment variable.
<infinity> Kay.
<KeithW> Mosh 1.2 was the "oh shit now we have a zillion users and they all want things" release.
<infinity> Hahaha.
<infinity> Yeah, it got widely publicised around 1.1ish.  Not sure where I heard about it.
<infinity> reddit via G+, or some other strange roundabout way.
<micahg> FWIW, 1.1 got backported all the way to lucid
<KeithW> Yeah, I think broder took care of all that.
<infinity> Right, so, same thing can be done for the current precise package.
<micahg> well, 1.2.2 is in quantal, but yes, it can go to whatever releases someone's willing to test it on
<infinity> Err, I meant quantal.
<KeithW> I think 1.2.2 is what will be in Debian (7?), and I'll be satisfied if that's what quantal ends up with. If we can get 1.3 out by then, that would be awesome, but not sure we'll make it. (I also don't know exactly when your freeze is.)
<micahg> KeithW: we can always backport 1.3 later if it misses the freeze
<KeithW> Ok.
<infinity> KeithW: Our Debian Import Freeze (as in, when we stop autosyncing) is July 5, Feature Freeze is August 23.
<KeithW> Hooboy. Well, we'll see.
<infinity> KeithW: But if it doesn't make it for Q, it can always be in R, and get backported from there.
<micahg> KeithW: feel free to use requestsync (from ubuntu-dev-tools) between Debian Import Freeze and Feature Freeze, and past feature freeze, if it's important, use requestsync -e and explain why it's important
<KeithW> Thanks!
<KeithW> I have to say, as a developer, Ubuntu is a half-step ahead of Debian as far as well-built tools go, and then after Debian there is maybe a step or two to Fedora, and then there is a wide, wide gulf for every other platform.
<infinity> KeithW: Alternately, ping me, cause I actually use the thing.  You know, if self-service tools that report bugs annoy you. ;)
<KeithW> I used requestsync just yesterday or the day before to get 1.2.2 in quantal and it went through maybe yesterday. Now I am high on my newfound capabilities. :-)
<infinity> Hahaha.
<infinity> That may have been coincidence, I think Colin did an autosync run recently.
<infinity> (Unless someone replied to your bug, then not coincidence)
<KeithW> It's not normally an 18 hour response time?? Too bad. :-)
<infinity> Oh, it can be minutes.
<infinity> But not always. :P
<infinity> Real humans on the other end of the line and all.
<infinity> stgraber: Good news.  Your natty-running Panda hates me as much as the buildds, so debugging this (or hackishly working around it) shouldn't be too much effort.  I hope.
<stgraber> infinity: cool :)
<infinity> Oh, crap.
<infinity> I was using "fall back to gcc-4.5" as a workaround to avoid the new 64-bit atomics in newer GCCs.
<infinity> But we haven't rebuilt gcc-4.5 for armv5t.
<infinity> So, I'm generating v7 binaries.
<infinity> Bother.
 * infinity head -> desk.
<toabctl> i'm getting a "bus error" when i try to load images with clutter on 12.10 . see http://paste.ubuntu.com/1058035/
<alazare619> can someone get me a copy of the preseed file for xubuntu
<alazare619> what they use for the packages etc
<jbicha> KeithW: the bug was good as it pointed out that the Ubuntu diff wasn't needed anymore
<infinity> Ugh.
<infinity> Dearest mono, why is your build system so ridiculously fragile?  No love, Me.
<ScottK> Think about the mischief you'd be up to if you weren't distracted by mono's build system.  Perhaps it's a win for society?
<ScottK> ;-)
<infinity> ScottK: But.  But.  But...
<ScottK> :-)
<ScottK> Have a nice day.
<infinity> ScottK: Would calling you a jerk be a CoC violation?
<ScottK> Only if it weren't true.
<infinity> Heh.
<ScottK> Gotta run.  I hope you get it sorted.
<infinity> Probably not today, now that I've been slowed down by having to build a compiler to build my compiler.
<infinity> Maybe I'll go do something socially destructive while I wait on that.
<infinity> Just for you.
<nigelb> all the love :)
<toabctl> filled a bug with a test program for the mesa stuff (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1017243)
<ubottu> Launchpad bug 1017243 in mesa (Ubuntu) "Program received signal SIGBUS, Bus error." [Undecided,New]
<robert_ancell> infinity, can I get you to have a look at the vala-0.18 upload?  It's just a new version of vala, I haven't opened a bug for it though as it's pretty standard
<robert_ancell> hang on, RAOF and StevenK are also members of ubuntu-archive, can I haz cheezburger?
<robert_ancell> ^^^
 * RAOF is not an AA; no NEW for you!
<RAOF> Also, is the new vala going to generate different C code, making SRUs a tedious business of filtering out thousands of lines of mostly useless diff? </bitter>
<robert_ancell> RAOF, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages says ~archive-admin is fine, and https://launchpad.net/~ubuntu-archive/+members#active says you are in there!
<RAOF> Ok, that wiki page lies; there are now a couple of members of ~ubuntu-archive who aren't archive admins, but *are* SRU people.
<robert_ancell> RAOF, well, a logical build system wouldn't pointlessly distribute all that C code
<RAOF> I'm also down with that.
 * robert_ancell beats his head against (pointless in my opinion) paperwork
<robert_ancell> StevenK, I see you hiding there.  Are you also going to claim immunity like RAOF
<RAOF> StevenK is a valid victim :)
<robert_ancell> why are we so scared of new packages?  If you've got main, you should be able to upload to dev releases and just pull them back if there's a problem
<RAOF> Could we rebuild everything with the final vala as a prophylactic measure? I just recently looked at an SRU that had last been uploaded when a 0.15 vala was current, and there was a huge amount of noise vs the 0.16 that ended up in the precise archive.
<RAOF> robert_ancell: At least copyright-review; it's not trivial to pull packages that shouldn't be distributed, because we've got a huge mirror network.
<robert_ancell> RAOF, don't get me started on how pointless debian/copyright is...
<robert_ancell> RAOF, don't you just ignore the .c files by default?
<infinity> robert_ancell: Same packaging as the previous vala?  Like, can I trust you, or should I review this? :P
<robert_ancell> infinity, it's pretty much a sed replacement from 0.16 to 0.18.  It's the same quality as any other point release update I'
<robert_ancell> d make
<RAOF> robert_ancell: If they were guaranteed to be unused by the actual build system, yes (and we just shouldn't ship the damn things in the tarball). But that's not always the case, is it?
<robert_ancell> we kind of need a different category between versioned sources in new and really new packages
<RAOF> That I can agree with.
<robert_ancell> 'cause this is going to happen next cycle, and the cycle after, and ...
<infinity> robert_ancell: Yeah, yeah.  It's not a big deal. :P
<robert_ancell> RAOF, oh yeah, it's a bit of a review nightmare then.  Can we automatically strip them out of the tarballs somehow?
<infinity> robert_ancell: I assume there will be things in main {build-,}depending on this soon?
<infinity> robert_ancell: Or should I dump it in universe for now?
<robert_ancell> infinity, yep, if you can go straight to main that's great (baobab needs it now), or I'll do the MIR next
<infinity> No need for an MIR for new versions of already-mainy stuff.
<infinity> Off to main it goes.
<infinity> Is there any hope that we'll be able to completely transition and dump all the old versions out? :P
<robert_ancell> infinity, oh, so we could have done that for libpwquality?
<RAOF> robert_ancell: Can you strip them in the debian/rules clean target?
<robert_ancell> infinity, all of GNOME 3.6 should build with vala-0.18
<robert_ancell> so practically yes
<infinity> robert_ancell: libpwquality didn't have a previous version in main...
<robert_ancell> ok
<infinity> (But sure, if the MIR comes before the NEWing and is approved, there's no reason for an interim "dump it in universe first" step)
<robert_ancell> ok, I'll do it that order next time
<robert_ancell> RAOF, I guess we could
 * infinity sees vala 0.14, 0.16, and now 0.18 in main and sighs.
<infinity> And valac is still from 0.14
<robert_ancell> infinity, it should be in the alternatives system now
<robert_ancell> and we can probably drop 0.14 or are very close to being able to do so
<jbicha> ooh, you could sync vala-0.16 to get 0.16 as the default vala
<infinity> jbicha: I'm assuming that would also require a new vala-0.14 that no longer generates the valac package?
<robert_ancell> jbicha, hey, I was confused by the alternatives numbering - if you know what we should be doing please do so
<jbicha> infinity: it looks like Debian didn't bother doing that, but it's probably a good idea
<jbicha> robert_ancell: I don't know what the numbers mean
<robert_ancell> jbicha, I think they're priorities, but I don't know how we pick them.  We should probably copy Debian, but they're standardising on 0.16 for their release and we want 0.18
<jbicha> I think we still want 0.16 as default until 0.18 settles a bit more though
<infinity> I'd recommend using the version (minus decimal) as the default priority (so, 14, 16, 18, etc), and then make your selected default 50 or 100 or something.
<robert_ancell> infinity, good idea
<infinity> So, if you wanted 16 as the default, you'd have 14, 100, 18.
<infinity> But you could also do the gcc-defaults/python-defaults route and have valac be generated from a separate source package that just drops symlinks in instead.
<robert_ancell> damn, the MIR team is tiny.  And all outside my timezone I think
<infinity> Obviously incompatible with an alternatives system, though.
<infinity> doko_: Hey, add me to ~ubuntu-mir already. ;)
<robert_ancell> bug 1017285
<ubottu> Launchpad bug 1017285 in libpwquality (Ubuntu) "[MIR] libpwquality" [Wishlist,Triaged] https://launchpad.net/bugs/1017285
<infinity> robert_ancell: There, and your binaries are all through NEW as well now.  Cheers.
<robert_ancell> infinity, thanks!
#ubuntu-devel 2013-06-17
<vipzrx> hello ,I want to boot the panadboard using the ubuntu core 12.04 by nfs , what should I to set for the boot.scr ?
<pitti> Good morning
<pitti> hm, do we still have a powerpc porter box somewhere?
<vipzrx> pitti: hello
<StevenK> pitti: davis
<StevenK> Which seems to not love the world
<pitti> StevenK: that's what I thought, but it seems broken
 * pitti is using partch.debian.org
<tvoss_> didrocks, good morning :)
<didrocks> hey tvoss_, how are you?
<tvoss_> didrocks, pretty good :) you?
<didrocks> tvoss_: I'm fine, thanks! Quite a little bit of backlog though :)
<tvoss_> didrocks, ah okay :) I have a question for you: do you have an eta when Mir/system comp will land in universe?
<didrocks> tvoss_: see #ubuntu-mir, let's not get the discussion in two channels :)
<tvoss_> didrocks, yup, thx :) my bad
<didrocks> no worry ;)
<Noskcaj> Daviey, ping
<Daviey> Noskcaj: hey
<Noskcaj> Daviey, i sent you a PM yesterday, did you see it?
<dholbach> good morning
<seb128> dholbach, hey, wie gehts?
<dholbach> hey seb128 - sehr gut - et toi? comment Ã§a va?
<seb128> dholbach, Ã§a va bien merci ;-)
<dholbach> :)
<Daviey> Noskcaj: Yes, I'll have a better answer for you latr.
<Daviey> +e
<pitti> mvo: hey, how are you?
<pitti> mvo: I already handled https://code.launchpad.net/~seb128/sessioninstaller/handle-parsing-errors/+merge/168970, including the tighter except:
<mvo> pitti: hi, thanks! yeah, I nocticed after I answered, was on vac for a couple of days and worked on the mail sequentially :)
<seb128> mvo, hey! thanks for the review anyway ;-) I hope you enjoyed your vac days!
<mvo> seb128: I did, it was very nice, thanks!
<dholbach> hey mvo
<mvo> hey dholbach!
 * pitti sends some water bubbles to dholbach
 * dholbach hugs pitti
<xnox> memtest86+ fails to upgrade for me, in an ubuntu-cloud image launched under lxc, due to calling update-grub2 unconditionally, which fails in ubuntu-cloud image under lxc.
<xnox> memtest86+ seems to have a mariod of upgrade/install bugs on launchpad due to failing at the update-grub2 call. Should it have "|| true" added?
<pitti> xnox: because the update-grub2 command doesn't exist, or does it fail?
<pitti> if it doesn't exist, a [ -x ] test sounds more appropriate to me
<xnox> pitti: there is already a -x test, it's just that lxc container has grub2 package install, /boot/ mounted&present (from the ubuntu cloud preinst image), yet lxc container cannot successfully run update-grub2, as it fails to identify boot device.
<xnox> and well, one doesn't actually boot lxc containers with grub.
<xnox> I guess memtest postinst should check if it's in a container/lxc and do nothing with grub even if that's present.
<pitti> wouldn't that logic be better placed in update-grub then?
<pitti> otherwise we'd have to fix a lot of packages in the same way?
<xnox> pitti: yeah. It looks like there is a generic command "running_in_container" command already which can be recycled.
<xnox> /bin/running-in-container shipped by upstart, perfect.
<cjwatson> xnox: The right fix is to add [ -e /boot/grub/grub.cfg ]
<cjwatson> Though actually a running-in-container test is fine too
<cjwatson> /etc/kernel/postinst.d/zz-update-grub has both
<xnox> cjwatson: /boot/grub/grub.cfg is present in ubuntu-cloud images, which are then booted as an lxc container =(
<xnox> cjwatson: http://launchpadlibrarian.net/142639886/memtest86%2B_4.20-1.1ubuntu4_4.20-1.1ubuntu5.diff.gz
<cjwatson> Yeah, that occurred to me afterwards
<cjwatson> Just make the logic match /etc/kernel/postinst.d/zz-update-grub
<xnox> i think it matches now, despite using different syntax for the same thing.
<cjwatson> Looks like it, thanks
<luv> Hey, just reported a bug in launchpad and the status was changed to "incomplete" so I provided more info as asked, should I now change the status back to "New" ?
<cjwatson> That's reasonable
<luv> ok, thanks
<ev> Daviey: could you please approve my post to the ubuntu-server list?
<ev> and whitelist my address? :)
<zyga> mvo_: ping
<Daviey> ev: ack
<ev> mpt: briefly going back to the crash reports for Firefox and Chrome discussion, I forgot that I wrote this a while back: https://wiki.ubuntu.com/ErrorTracker/BreakpadApplicationSupport
<ev> so we're not without some work on this, albeit small
<mpt> ev, huh, I didn't know they used the same crash reporting system
<ev> yeah, we considered breakpad, but you need to link the world against it
<mvo_> zyga: sorry, busy day today, could you send me a quick mail? I gtg to a meeting in some minutes
<zyga> mvo_: sure, thanks
<pitti> stgraber: FYI, this could remotely affect LXC: http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html
<stgraber> pitti: soounds like it won't make things much worse. As it currently is, it's almost impossible to run systemd in a container. Some Fedora users have been trying for months, sent a dozen patches to LXC but all of it is just trying to workaround silly limitations put in place by systemd (like it refusing to start getty on pts devices or indeed messing with cgroups in a way it shouldn't)
<pitti> stgraber: yeah, I rather meant the upcoming changes to the kernel side of cgroups
<stgraber> the bit about assigning resources to users may indeed be problematic (assuming that's done in logind and not systemd), though that's something we need to deal with at some point anyway if we want unprivileged containers
<stgraber> ah yeah, we're aware of the upcoming kernel changes, hallyn has been following those discussions for a while now
<pitti> stgraber: ah, good; nevermind them
<hallyn> stgraber: yeah we'll need to update lxc to use 'cgroup.procs' instead of 'tasks' soon
<mardy> kenvandine, seb128, didrocks (and anyone else :-) ): would you please endorse me? https://wiki.ubuntu.com/AlbertoMardegan/CoreDeveloperApplication
<seb128> mardy, hey, sure!
<mardy> pitti: oh, you too :-) ^
<didrocks> mardy: hey, will do :)
<pitti> oh, so where was that magical UDD page about "what did I sponsor for X?"
<pitti> mardy: ^ if you happen to have a list, I'd appreciate :)
<pitti> (back in 30)
<kenvandine> mardy, will do
<mardy> pitti, kenvandine, seb128, didrocks: I renamed the page to https://wiki.ubuntu.com/AlbertoMardegan/ContributingDeveloperApplication
<didrocks> mardy: making more sense, thanks!
<seb128> mardy, great ;-)
<mardy> pitti: there's a couple of links here: https://wiki.ubuntu.com/AlbertoMardegan/ContributingDeveloperApplication#Examples_of_my_work_.2BAC8_Things_I.27m_proud_of
<Laney> pitti: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
<pitti> mardy: hm, seems I didn't actually sponsor anything from you?
<pitti> Laney: thanks
<Laney> thank the awesomebar!
 * Laney hands out "Firefox by default" buttons
<ogra_> make it work usable on arm
<ogra_> then we can talk
<pitti> Laney: +1 :)
<mardy> pitti: I corrected my application wiki: I'm actually applying as contributor, not core-dev anymore
<hallyn> arges: just fyi, we do need the previous 14.9 changelog entry and need to debuild -v1.0+noroms-0ubuntu14.8 to build the qemu precise package - but i'll do that.
<arges> hallyn: oh ok, let me know if you  need anything from me then
<hallyn> arges: pushed to precise-proposed with http://people.canonical.com/~serge/qemu-kvm.debdiff as the debdiff
<hallyn> arges: (now we just need an SRU admin to accept it)
<arges> hallyn: thanks
<xnox> Laney: I'm not Australian, but I support chromium by default!
<hallyn> np :)
<didrocks> Riddell: hey, are you monitoring the libical transition? you started it and it seems to be stuck in proposed for quite a few days
<didrocks> Riddell: as you bump the build-deps on it, this makes some of our components like indicator-datetime stalled
<didrocks> sil2100: ^
<Riddell> didrocks: hmm yes, that's on my todo for today
<sil2100> Riddell: could you poke me once that's pushed further?
<sil2100> Since I'd like to unblock indicator-datetime then
<didrocks> thanks Riddell for looking at it :)
<jbicha> sil2100: bug 1191792 is the remaining blocker for the ibus transition, I worked around openchange's build problem
<ubottu> bug 1191792 in kmymoney (Ubuntu) "kmymoney fails to build on saucy" [High,New] https://launchpad.net/bugs/1191792
<seb128> jbicha, "ibus transition"?
<jbicha> s/ibus/ical
<jbicha> too many i's
<seb128> k
<Riddell> sil2100: the indicator-datetime failure doesn't have anything to do with libical
<sil2100> Riddell: the indicator-datetime failure I have been encoutering while trying to get my branch merger in did have, since it was failing because of: Depends: libical-dev (>= 1.0) but 0.48-2 is to be installed.
<Riddell> jbicha: hmm new libaqbanking probably the culprit there
<Riddell> sil2100: you need to enable -proposed to get 1.0 installed
<sil2100> Riddell: we know that, but mergers do not have -proposed, and the CI team has some reasons for why it cannot be enabled there
<sil2100> Riddell: but I merged that in manually already
<jbicha> Riddell: yes I believe so
<sil2100> Since this way we can unblock everything, as libical can move from -propose to saucy now that indicator-datetime will be re-built
<cjwatson> sil2100: That's going to be "interesting" in the case of transitions
<cjwatson> Your CI team is probably wrong :)
<sil2100> We've been hearing that a lot lately ;)
<cjwatson> (Speaking as the person who manages proposed->release migration)
<mterry> jbicha, btw, uploaded new deja-dup with your g-c-c panel name fix
<jbicha> mterry: cool, thanks :)
<andyrock> \msg Laney ping
<andyrock> ops.... sorry
<jbicha> andyrock: you can just ask your questions in the channel, you probably don't need to privmsg people
<Laney> the secret world of privmsg!
<andyrock> Laney, hey good morning/afternoon/evening
<andyrock> i still can reproduce https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1182307
<ubottu> Launchpad bug 1182307 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_type_check_instance()" [Medium,Fix released]
<Laney> can you file a new bug?
<Laney> I would say if you have the fixed package it's more likely to be a different one with similar symptoms
<andyrock> Laney, sure
<Laney> andyrock: From the commandline: apport-bug /var/crash/_usr_bin_nautilus.<whateveritis>
<andyrock> brb
<alexbligh1> Do we know what version of qemu is going in saucy yet, and/or is there a packaged version around somewhere? (not according to packages.ubuntu.com)
<alexbligh1> ok ignore me - packages.ubuntu.com is playing up. The answer is 1.5.0
<Riddell> jbicha: got kmymoney compiling, all the fault of something called gwenhywfar
<cjwatson> we should have more Celtic-language-family package names
<jbicha> sounds ominous enough
<slangasek> I was going to go with WelshOS
<cjwatson> (IIRC that one is the Welsh for "Guinevere")
 * slangasek nods
<jbicha> Riddell: while looking around for a fix, I noticed that Fedora backported about 15 patches to fix various issues
<jbicha> you can grab the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=421621 if you're interested
<chiluk> Daviey, slangasek, cjwatson can I get some SRU love on the precise unity upload https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=unity
<andyrock> Laney, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1191883
<ubottu> Launchpad bug 1191883 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_type_check_instance()" [Undecided,New]
 * andyrock had some issues with apport
<Riddell> sil2100: so new indicator-datetime will be going in?
<slangasek> chiluk: yep, I can have a look this afternoon
<chiluk> awesome thanks.
<slangasek> barry: fyi, the python2.7 SRU for bug #1058884 is currently stalled out because there's an existing SRU in -proposed that needs sorted (bug #1088771 failed verification); maybe you can help get that un-stuck?
<ubottu> bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [High,In progress] https://launchpad.net/bugs/1058884
<ubottu> bug 1088771 in python-defaults (Ubuntu Precise) "dangling symlink /usr/lib/pkgconfig/python2.pc" [Low,Triaged] https://launchpad.net/bugs/1088771
<barry> slangasek: sure, i can take a look
<slangasek> cjwatson, stgraber: ok... correction, the parted in the recovery image does *not* recognize the partiton table correctly :P
<slangasek> GNU Parted 1.8.8.1.179-aef3
<cjwatson> I'm working on the necessary backports in any case
<slangasek> well, this is the parted from the android build ;)
<slangasek> one wonders why it's there at all if it's in such a dire state
<cjwatson> Yeah, but presumably it would help to have a working parted somewhere
<slangasek> generally speaking!
<cjwatson> Adding http://paste.ubuntu.com/5774631/ seems to do the trick
<seb128> cjwatson, if a software migrated from qt4 (where is was available on ppc) to qt5 (where it's not), is deleting the ppc binary from the old version the right thing to do to unblock the proposed->archive migration?
<cjwatson> seb128: Probably, yes, but check its rdepends
<seb128> cjwatson, https://launchpad.net/ubuntu/+source/signon-ui/0.15daily13.06.12-0ubuntu1 is the source
<seb128> hum, that's going to make the ppc desktop quite unhappy I guess
<seb128> kenvandine, ^
<kenvandine> :/
<ogra_> you think we have users of unity on PPC ?
<seb128> no
 * ogra_ would expect them to use lubuntu or so 
<kenvandine> without unity, signon-ui won't get used
<kenvandine> since we only show the signon panel on unity
<seb128> the issue is that it will likely make the desktop not installable on ppc
<seb128> not sure how to deal with it
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<seb128> out of starting rebuilding stuff without uoa on ppc
<ogra_> but if we are sure that there are no unity users, why doe we bother to make it installable ?
<cjwatson> The rdepends stack is fairly large, but is it possible that it just makes some unity scopes and account plugins uninstallable (indeed those would need to be removed too)?
<cjwatson> It *looks* that way to me
 * JanC wonders how often PPC is still used?
<cjwatson> The side discussion is unlikely to be productive here
<ogra_> surely there are quite some server users
<kenvandine> it looks like empathy and shotwell are the real problems
<seb128> cjwatson, can we just delete the binary and see what happens and fix fallouts later (or wait to see if anyone care enough to fix those)?
<barry> slangasek: i cannot reproduce lp: #1167177 in a chroot.  what am i missing?
<ubottu> Launchpad bug 1167177 in python-defaults (Ubuntu Precise) "package python-dev 2.7.3-0ubuntu2 failed to install/upgrade: tentative de remplacement de Â« /usr/lib/pkgconfig/python2.pc Â», qui appartient aussi au paquet python2.7 2.7.3-0ubuntu3.1" [High,Triaged] https://launchpad.net/bugs/1167177
<kenvandine> empathy and shotwell depend on libsignon-glib1
<cjwatson> seb128: Please don't, that makes proposed-migration more fragile
<kenvandine> which depends on signond, which depends on signon-ui
<seb128> shrug
<slangasek> barry: "luck" in the unpack ordering in your local test?
<slangasek> barry: you may want to dpkg -i /path/to/python-dev.deb explicitly
<kenvandine> we just had the discussion about how we can make empathy not depend on it last week
<seb128> kenvandine, <seb128>  not sure how to deal with it,  out of starting rebuilding stuff without uoa on ppc
<cjwatson> seb128: Its constraint is that the total *number* of uninstallables not decrease - so every extra uninstallable in the archive gives it more wiggle room, and not in a good way
<kenvandine> which was "not easily"
<barry> slangasek: could be.  let me try that
<seb128> same for shotwell
<seb128> kenvandine, well I guess we can stop enabling uoa for those on ppc
<cjwatson> empathy's involvement here seems to be a Recommends
<cjwatson> Ah, Build-Depends
<kenvandine> not really
<kenvandine> internally it's private lib links to it
<kenvandine> and is hard to unravel :/
<cjwatson> No, it's a build-depends leading to signond which only Recommends: signon-ui
<kenvandine> oh
<seb128> right
<cjwatson> shotwell doesn't seem to show up in the Depends stack
<kenvandine> then that shouldn't break
<seb128> same for shotwell
<seb128> shotwell depends on libsignon-glib1, which depends on signond which recommends signon-ui
<cjwatson> As I say, there's a certain amount to unravel here and I'd like us to remove some subset that keeps things consistent (and preferably that won't reappear next rebuild)
<cjwatson> But it doesn't seem intractable
<ogra_> and since the whole thing came up due to ubuntu touch testing, note that ubuntu touch images build with --no-install-recommends still ...
<ogra_> (just as a side comment wrt recommends)
<sil2100> Riddell: it should, but... jenkins is preparing for a shut down
<sil2100> So I'll take care of that tomorrow
<seb128> kenvandine, going to be fun dropping those...
<seb128> on that note, need to go for dinner
<seb128> bbiab
<jbicha> libsignon-glib1 doesn't need to depend on signond though, so empathy & shotwell should be fine if signon-ui is the only thing that's broken
<barry> slangasek: okay, forcing the order allowed me to reproduce the problem, and the proposed fix look right.  should i apply this to a new version of python-defaults 2.7.3-0ubuntu2.1 and get the one in proposed bounced, or prepare a -0ubuntu2.2?
<slangasek> barry: python2.7/2.7.3-0ubuntu3.2 is the version already in -proposed; you can reupload python2.7/2.7.3-0ubuntu3.3 with both fixes - and in that case, please make sure to build the source package with a -v option pointing to the last version in precise-updates
 * barry nods
<barry> slangasek: actually, the fix is in python-defaults, but i understand what you mean :)
<slangasek> barry: ah right :)
<barry> slangasek: uploaded
<slangasek> barry: ta
<Laney> andyrock: ta
<andyrock> yw
<slangasek> cjwatson: so, parted also isn't happy with the N7 partition table... completely different behavior though :)
<slangasek> Error: /dev/block/mmcblk0: unrecognised disk label
<slangasek> cjwatson: where should I start with this?
<slangasek> Jan  7 00:49:56 ubuntu-phablet kernel: [    3.495050] Primary GPT is invalid, using alternate GPT.
<psusi> cjwatson: doh... heh, I fixed the gpt thing this morning too ;)
<slangasek> psusi: any thoughts on my new parted issue (above)? :)
<psusi> slangasek: parted does not complain about this but the kernel does?
<slangasek> psusi: the opposite; the kernel is "happy" with the alternate GPT, parted doesn't read it at all
<psusi> slangasek: and this is with the proposed fix it looks like cjwatson just uploaded a few minutes ago?
<slangasek> psusi: yep - different device
<slangasek> different crazy-wrong partition table
<psusi> slangasek: you seem to have pasted a kernel error message?
<slangasek> psusi: well, I wouldn't call it an error, but a warning
<psusi> slangasek: right... so the kernel is saying the primary is corrupt, and it's using the backup... does parted agree with this assessment?
<slangasek> psusi: http://paste.ubuntu.com/5774883/
<slangasek> psusi: no, parted says 'Error: /dev/block/mmcblk0: unrecognised disk label
<slangasek> '
<psusi> slangasek: which version of parted?  the one cjwatson just uploaded to fix the nonstandard gpt size issue?
<slangasek> psusi: yes
<slangasek> 2.3-13ubuntu2
<psusi> slangasek: did it fix the problem with the other system?
<slangasek> psusi: actually haven't tested that one yet... let me do that now
<psusi> slangasek: and how about gdisk?
<slangasek> psusi: http://paste.ubuntu.com/5774895/
<slangasek> psusi: so... the /kernel/ likes it this time, but nothing else does :)
<psusi> slangasek: looks like the kernel doesn't bother checking the version number
<psusi> slangasek: so it looks like your primary is corrupt, and the backup has the wrong version number, which the kernel fails to notice
<slangasek> psusi: so, what's the correct solution here?  Should parted be bug-for-bug compatible with Linux?  Should there be some tool I can use to "repair" the alternate GPT/
<psusi> slangasek: did the new version at least fix the problem with the first machine?
<slangasek> psusi: note that this device is the Nexus 7, which I'm told is notorious for being bricked if one fiddles with the partitioning... I suspect that writing to the primary GPT might be a bad idea :)
<psusi> you may be able to use gdisk to repair it, or you might just have to hex edit it by hand... linux probably should be fixed to check the version number
<slangasek> psusi: yep, new parted works fine on the other device (N4)
<psusi> I thought mmc devices had their own low level partition scheme?
<slangasek> psusi: I'm wary of "fixing" the kernel because I suspect the firmware's partition support (fastboot) of being a house of cards that may explode if I touch anything I shouldn't
<slangasek> rsalveti: ^^ what do you think of the above? (N7 GPT is invalid from parted's perspective, and barely passes the kernel)
<psusi> last time I tried fiddling around on my android phone, it looks like mmc has its own low level partition table, and there is no msdos or gpt
<slangasek> mmc is just a storage medium, and the particular partition table used is implementation-dependent
<slangasek> so far, the Nexus devices seem to be GPT
<psusi> I'm pretty sure when I looked at the kernel mmc code, it had its own low level partition table that all mmc devices must have
<slangasek> psusi: well, the N4 was the device with the other non-checksumming GPT, and it was also /dev/mmcblk0
<stgraber> psusi: what you describe sounds like mtd, which some android device use, but AFAIK not the Nexus ones we're looking at
<psusi> slangasek: it also looks like this new device has no protective MBR?  can you confirm that with fdisk?
<psusi> ahh, right, mtd is what I was thinking...
<slangasek> psusi: fdisk also bombs out spectacularly, yes
<slangasek> Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
<bdmurray> pitti: should we turn on apport opening bugs on Launchpad now?
<psusi> slangasek: then the kernel shouldn't be recognizing it either
<cjwatson> I'll leave you two to the parted investigation, since I'm mostly meant to be childcaring now :)
<psusi> unless... there's a kernel command line "
<psusi> "gpt" option to force it to use gpt without a valid protective mbr
<psusi> but the mbr is required by the efi standard, which says you shall not treat it as gpt without it
<stgraber> how is EFI relevant on ARM?
<psusi> because EFI is the standard that defines GPT
<cjwatson> We do already bend that rule for Apple, of course ...
<cjwatson> (In a fairly evil way, but still)
<psusi> why is that?
<slangasek> psusi: well, let's see. 'gpt gpt_sector=30535679'
<cjwatson> Because Apple bent it before us and we had to play along in order to work there
<cjwatson> They have a legacy MBR rather than a protective MBR
<psusi> legacy or hybrid?  no type ee or ef?
<cjwatson> See gptsync.patch
<cjwatson> No time to explain now
<slangasek> right; similar issues apply here, I need to be able to work with the partition tables that come on the device, waving the text of a standard at my phone isn't going to help me read/edit the partitions
<cjwatson> I might mean hybrid, I forget which adjectives settled down into meaning which things
<psusi> slangasek: say, if you don't want to mess with the goofy partitions this device comes with, why do you care about what parted thinks about it?
<rsalveti> slangasek: hm, that's kind of unexpected
<rsalveti> just flashed my n10, let me check that as well
<slangasek> psusi: I want to repartition the device; I want to do so in a way that won't brick the device in the process, by, say, writing to a new location that the firmware is doing something funky with
<psusi> slangasek: it seems that they have patched their kernel to handle some funky stuff... I'd start by seeing what they patched in block/partitions/gpt.c
<slangasek> ah, the pain
<slangasek> ok
<psusi> hehe
<psusi> err, it's efi.c, not gpt.c
<stgraber> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=history;f=fs/partitions/efi.c;h=30546cc8d03faa14f9fc0e05df307e24db006371;hb=grouper
<stgraber> not seeing any weird patching in there
<stgraber> slangasek: might be interesting to dd the table to a USB stick and try it on a standard Ubuntu machine, see what a clean kernel thinks of it
<slangasek> hmm, possibly.
<slangasek> how do I find the table? :P
<slangasek> gpt_sector=30535679 - how does that translate to a dd command?
<slangasek> looks like sectors are 512 bytes
<slangasek> 0-indexed?
<stgraber> hmm, that'd mean the table is pretty much at the end of the flash then?
<psusi> that's why I said they seem to have patched their kernel... because I don't see any gpt_sector kernel argument
<stgraber> slangasek: dd if=/dev/mmcblk0 of=gpt.img bs=1K count=32 seek=30535679 ?
<stgraber> hmm * 512
<stgraber> psusi: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=commit;h=2311e2e994b86a4d9592ba9cc63e9d877fe270f6
<slangasek> stgraber: in fact, total disk size is 30535680 sectors
<stgraber> slangasek: hmm, so that'd be 512 bytes for the table? sounds rather short. How big is that flash 16GB?
<slangasek> Disk /dev/block/mmcblk0: 15.6 GB, 15634268160 bytes
<psusi> slangasek: the header is one sector... it describes how long the table itself is, which normally is 128 bytes x 128 entries, but the other device you had only had 9 entries
<slangasek> so if the header is 1 sector, where does it put the table? :)
<slangasek> because it claims to be reading it from the last sector on the device
<psusi> slangasek: immediately following for the primary, and preceeding for the backup
<stgraber> psusi: confirmed that we have this kernel in the grouper kernel but it's not an upstream patch and likely isn't in our desktop kernel
<slangasek> psusi: "preceding" -hah
<slangasek> ok
<rsalveti> slangasek: nexus 10: http://paste.ubuntu.com/5775036/
<psusi> slangasek: so in your case it should be the 3 sectors leading up to the last one, then the last one itself is the backup header
<slangasek> rsalveti: well, that's nice enough :)
<psusi> kind of odd that it passes the kernel override argument and points it to the last sector, which is where the backup is suppoed to be anyhow
<slangasek> psusi: yeah, beats me :)
<psusi> though it is also weird that the device doesn't seem to have a primary
<stgraber> rsalveti: wow, that one looks valid, nice and short, that's a change ;)
<rsalveti> stgraber: :-)
<slangasek> hmm, so does adb handle sparse files? :P
<stgraber> slangasek: that may explain why some people bricked their device while messing with gpt. Some editors may be able to see the backup table, load that, do the change and then write the master table, possibly overwriting part of the bootloader in the process
<rsalveti> right
<slangasek> yes, that's exactly my concern
<slangasek> dd if=/dev/block/mmcblk0 of=gpt.img bs=512 count=4 skip=30535676
<psusi> slangasek: dd count=4 if=/dev/mmcblk0 | xxd?
<slangasek> psusi: http://paste.ubuntu.com/5775052/
<slangasek> $ sudo kpartx -lv /tmp/gpt-full.img
<slangasek> $
<slangasek> so... a stock kernel doesn't seem to like it very much?
<stgraber> what's gpt-full.img?
<slangasek> stgraber: reconstituted sparse image from 'adb pull /data/gpt.img && dd if=gpt.img of=gpt-full.img bs=512 count=4 seek=30535676'
<psusi> slangasek: it looks like the stock kernel will do the same thing since the backup is actually at the end of the disk ( you did say that right? ), and it doesn't bother checking the version number
<slangasek> psusi: it is at the end of the disk; still, kpartx doesn't do anything useful with such an image, but maybe that's kpartx's fault
<psusi> it may also be checking the version and rejecting it because of that being wrong
<slangasek> psusi, stgraber: so I definitely see an android patch on fs/partition/efi.c: StrawberryMountain:~/ubuntu-saucy$ git log fs/partitions/efi.c
<slangasek> 2311e2e994b86a4d9592ba9cc63e9d877fe270f6,     fs: partitions: efi: Add force_gpt_sector parameter
 * slangasek eyes the pasting
<psusi> at any rate, this device appears to be a hack job where they have something else ( boot loader? ) at the start of the disk, and rely on a mal-formed backup gpt at the end... there's just no clean way to deal with this
<slangasek> psusi: so you would consider a parted option to "only write the table back where you found it" to be uncleas?
<slangasek> unclean
<psusi> yes... that and you still have the problem of the version number being wrong
<stgraber> slangasek: so I'm starting to wonder if we wouldn't get more reliable results if we were to ship a copy of the original and new partition table in the recovery image for each device where we support re-partitioning. That way we would basically just checksum the existing one, if it matches the backup we have, we dd the new one and do the opposite to restore.
<stgraber> slangasek: that'd give us way more insurance that we won't screw things up and would allow for possibly pretty weird hand-hacked table to be put in place without relying on heavily patched tools
<psusi> that sounds like a good idea
<slangasek> psusi: I'd be willing to try binary patching the alternate GPT here to fix the version, if you could guide me through that; but that still leaves the problem of being able to adjust the partition tables without corrupting the bootloader.. which maybe stgraber's idea solves, yes
<slangasek> stgraber: well, I wasn't expecting "heavily patched", I was expecting "let's address these incompatibilities upstream"
<psusi> safer all around.. the way if you brick your device you can deal with it, and users only get a partition table that has been tested and known to work
<psusi> for that matter, you could just say to hell with partitioning and use a loopback file ;)
<stgraber> that's our plan for the devices we don't have a custom partition table for
<stgraber> for the 4 devices we fully support, we'd prefer to avoid the performance and power impact of loop mount though
<stgraber> (power impact is ~5%, performance is a bit random but appears to be at least 10%)
<slangasek> loopback file - doesn't provide read-only control at the lowest level, doesn't let us leverage the space on the system partition, has a silly performance penalty
<slangasek> psusi: so how can I fix the version number here (or where should I read about the table layout to figure this out for myself)?
<psusi> slangasek: efi.h defines it in the kernel sources.. 64bit signalture followed by a 32 bit version number that should be 0x00010000, but I don't think changing it is what you want to do... parted will still overwrite the primary copy
<psusi> though if yuo're just trying to hack this up and then restore the original contents at the start, that should work
<slangasek> psusi: well, we have several devices to be supported and I don't want to have to *generate* the binary deltas for the whole table by hand
<psusi> yea... so for that purposes, dding a value of 0x0001 to offset 8 may get it going, then you just have to throw out the primary and put back the original contents there, and change the 1 back to a zero later
 * slangasek nods
<psusi> err... endienneess probably makes it the other way around
<psusi> damn liliputians
<slangasek> mm?
<slangasek> so 0x00000100 instead?
<psusi> should be whatever 0x00010000 is in little endien format
<psusi> upper word is major revision, lower word is minor
<slangasek> ok
<rsalveti> slangasek: http://paste.ubuntu.com/5775132/ for galaxy nexus
<slangasek> rsalveti: ok, thanks.  Can you get these to me as binary dumps of the partition tables?  (First 512k of the disk on each, to be safe)
<rsalveti> slangasek: sure
<slangasek> fortunately, the partition layouts are reasonably similar in all cases and let us grow the system partition without moving anything besides cache and userdata
<slangasek> psusi: so the other reason I wanted to use parted for this was to be able to shrink+move the userdata partition... instead of having to reformat it.
<psusi> slangasek: you mean using resize2fs + my recent parted patches that ubuntu isn't yet carrying to resize the partition?
<slangasek> psusi: hmm, are there patches not yet in Ubuntu for this?  I thought parted already had good support for resize/move :)
<psusi> slangasek: no, which is why upstream killed the functions entirely ;)
<slangasek> heh
<psusi> it only really worked on fat and hfs
<stgraber> slangasek: so much for that
<psusi> but I have some patches I'm still trying to get applied to add a resizepart command so you can at least manually run resize2fs to resize the filesystem and parted to resize the partition
<slangasek> psusi: note that we also need to be able to move the partition for this to be any good... is /that/ supported?
<psusi> it was removed upstream as well, but I think is still supported in our version
<slangasek> ok
<slangasek> well
<slangasek> that still means we would need a parted that can deal with this partition table
<psusi> of course, that just amounts to a dd
<slangasek> except that, I hope, it can deal with the case where the partition moves back by a distance less than the new partition size
<psusi> right
<slangasek> memmove(), not memcpy() :P
<psusi> of course, some day we are supposed to upgrade and then move goes away
<psusi> although I do have some patches for e2image in e2fsprogs to allow it to do an in place move
<psusi> and only of the used blocks
<rsalveti> slangasek: http://people.canonical.com/~rsalveti/mmc/
<slangasek> rsalveti: ta
<cjwatson> rsalveti: Would it help phablet-flash to actually detect saucy if I created a saucy -> . symlink in http://cdimage.ubuntu.com/ubuntu-touch-preview/ ?
<cjwatson> Seems like a bug that it doesn't find it though so that's probably the wrong answer
<rsalveti> not sure, but that would be a question for sergiusens
<cjwatson> sergiusens: ^-
<cjwatson> Hm, mind you, doesn't look like phablet-flash wants to install *any* daily
<rsalveti> well, latest should already flash the non flipped image by default
<ogra_> yeah
<rsalveti> the saucy one, I mean
<rsalveti> I just flashed 2 devices
<ogra_> pahblet-flash -l iirc
<rsalveti> saucy is already default
<ogra_> without the typo :)
<rsalveti> just phablet-flash
<ogra_> ah
<cjwatson> ogra_: That claims to only know about quantal and raring
<cjwatson> Hence my confusion
<rsalveti> right
<ogra_> i thought he re-introduced the -l switch
<rsalveti> that's the tagged versions
<rsalveti> that's why
<ogra_> right, they are milestones
<rsalveti> saucy is the dev release, and we don't yet have any tag for it
<cjwatson> It'd be nice if --list-revisions showed everything
<ogra_> it should show all milestones
<rsalveti> right
<cjwatson> Bit opaque at the moment
<ogra_> once we switched fully to the flipped image everything will change anyway i guess
 * ogra_ must admit that he never used phablet-flash :)
<cjwatson> But, indeed, phablet-flash on its own seems to be doing the right thing.  Thanks
<sergiusens> cjwatson: -l has been revamped to latest tagged image which is raring
#ubuntu-devel 2013-06-18
<slangasek> cjwatson: feel free to redirect to jibel, who's not currently online :)  The u-m autopkgtest is failing on amd64, apparently because it's managing to be run while the dependencies aren't consistent on amd64 in -proposed.  What's the right fix for this? https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-update-manager/ARCH=amd64,label=adt/37/
<slangasek> psusi: so, if I change the version number field, the kernel rejects the partition table ;)
<psusi> slangasek, ohh fudge... you also have to update the crc ;)
<slangasek> hm!
<slangasek> well
<slangasek> that will be a challenge, won't it
<slangasek> considering android's dd doesn't even want to write to a block device
<slangasek> https://bugs.launchpad.net/touch-preview-images/+bug/1190792
<ubottu> Launchpad bug 1190792 in touch-preview-images "ueventd in a busy loop on container-flipped image" [Undecided,New]
<slangasek> oops, ECHAN
<slangasek> psusi: right, so I'm even less enthusiastic now about doing this all by hand rather than being able to use parted for the task ;)
<slangasek> however, I did manage to reset the bit to 0, so the N7 is bootable again
<psusi> slangasek, then I'd say just comment out the version check in parted and build a local version for hacking purposes ;)
<slangasek> mmmk
<slangasek> psusi: but you won't want these patches in the Ubuntu build, I take it
<slangasek> because this is code that's meant to be part of the Ubuntu Touch bootstrap
<psusi> well, it would be a dirty hack that you would have to key to the dmi of the device or something, and wouldn't be accepted upstream that's for sure
<slangasek> what about a patch to support writing only to the alternate gpt?
<psusi> I don't think so
<slangasek> blah
<psusi> I think if you really want ubuntu's parted to work on this thing it would take a dmi specific hack to notice that the existing partition is this screwed up thing with version 0 and mo primary, and set a flag to remember to write it back with 0 version and only to the backup
<psusi> that really is terribly dirty of them not to have a primary at all... should at least have it located somewhere else
<psusi> then at least it would be somewhat sane for parted to find the backup, and just note that hey, the primary is in a weird place, but otherwise looks valid, so ok... I'll leave it there
<slangasek> well, arguably the kernel patch they have declares that this *is* the primary gpt
<slangasek> ... and it just happens to be located in the defined location of the alternate gpt :P
<psusi> I think the error gdisk gave would be different if that were the case
<psusi> you can tell for sure by looking at the value of mylba and altlba in the header...
<slangasek> my_lba: FF EF D1 01; alternate_lba:  00 00 00 00
<slangasek> er, sorry
<slangasek> my_lba: EF EF D1 01  00 00 00 00; alternate_lba: 01 34 00 00  00 00 00 00
<psusi> there was someone who was working on a patch lately that had to do with arm needing u-boot in sector 2 so the primary needed relocated
<slangasek> so that translates to 30535663, which is 17 sectors before the end of the disk?
<slangasek> (30535680 total sectors)
<slangasek> 16 sectors, rather
<psusi> but that at least still had a pmbr and primary header in sectors 0-1, and the table started in sector 3 instead, which is odd, but valid
<psusi> hrm.. it should be the last sector of the disk I thought?
<slangasek> dunno
<slangasek> this gives me a whole lotta zeroes: dd if=/dev/block/mmcblk0 of=/data/gpt-primary.img bs=512 count=4 skip=30535663
<slangasek> is there some reason that would be offset from somewhere other than sector 0?
<psusi> no, all offsets have to be relative to the start of the device
<slangasek> well, then I guess that field's invalid too ;)
<slangasek> I wonder what I'll find at offset 13313?
<psusi> you sure you are looking at the right fields?  one of them sure as shit should be the block number where you actually found the thing, which you said before was the last sector of the drive ;)
<slangasek> 00000600   45 46 49 20  50 41 52 54  00 00 00 00  5C 00 00 00  EFI PART....\...
<slangasek> 00000610   30 21 A2 EE  00 00 00 00  FF EF D1 01  00 00 00 00  0!..............
<slangasek> 00000620   01 34 00 00  00 00 00 00  00 3C 00 00  00 00 00 00  .4.......<......
<psusi> and if it didn't, it looks like the kernel would reject it
<slangasek> FF EF D1 01 -> 30535663, which is 16 sectors short
<slangasek> and the kernel is booted with gpt_sector=30535679
<psusi> that is weird
<slangasek> yeah, and I can confirm that this kernel has a check for my_lba == lba
<slangasek> is is_gpt_valid()
<slangasek> (branch 'grouper' on git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git, fwiw)
<slangasek> oh, y'know what
<slangasek> I'm not sure how, but I got the hex->dec conversion wrong
<slangasek> FF EF D1 01 -> 30535679 after all
<slangasek> so - yes, it claims to be the primary gpt, not the alternate
<slangasek> and the address given for the alternate GPT is empty
<psusi> iirc, that's actually what the alt is supposed to look like... it says my_lba = wherever it's at, and the alt points to the *other* copy
<slangasek> oh, then how can you tell the difference between the primary and the alt anyway?
<psusi> whether you found it at the beginning of the disk, or (end of disk, or what the primary says is alt_lba)
<psusi> so if the primary was just in an odd place, but the backup was at the end, then you could at least find the primary by what the backup says is the alt, and at least decide the situation is sane, just weird
<psusi> but it looks like this guy just flat how has no primary
<slangasek> it has the "primary", which is at the end, which is where the kernel argument says to look for it
<slangasek> I don't see the point in calling it an alternate when it's not an alternate to anything
<psusi> kernel argument just says find *one* here... not which it is
<psusi> the other thing about the backup is that the header follows the table, instead of the other way around.. but really, which one is which is just semantics
<slangasek> well, but that's convention; the GPT header *could* point anywhere for the GPT entries, and in the case of a GPT header in the last sector, it will always point somewhere earlier
<psusi> right... and in this case, it points to the normal location of 0, only there isn't another header there
<psusi> err, wait... no...
<slangasek> nah, it points to 13313, which is empty
<psusi> ahh... man... this just gets weirder and weirder...
<psusi> they bothered pointing it somewhere, but didn't actually put a copy there
<slangasek> psusi: ok, so as near as I can tell, libparted doesn't actually care about the version field either
<slangasek> it only objects if the value is too new
<psusi> weird.. looks to be that way
<psusi> I wonder why it's rejecting it then...
<slangasek> dunno, checking now
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Good morning
<pitti> bdmurray: traditionally we have done it for alpha-2, but with our changed devel process that doesn't apply much any more; I'll ask the team TLs (Daviey, seb128, cjwatson) later today when they are online, and also ev
<tjaalton> anyone know what 'unix-zany' refers to on libpam-cracklib's pam-config Conflicts?
<dholbach> good morning
<pitti> hey dholbach, guten Morgen
<dholbach> hey pitti
<infinity> seb128: Hey, guess whose compiz has crashed twice in the last two days? :/
<seb128> infinity, not me!
<infinity> seb128: :P
<seb128> infinity, I think Trevinho fixed the issue, but there was no bamf landing since...
 * infinity loves how it resizes and scatters all his windows.
<seb128> sil2100, ^ do you know what's blocking that fix to land?
<sil2100> seb128, infinity: hi! Sadly, bamf is part of the indicator stack, and it would be safest to land both unity and indicators together, since otherwise there is a chance things might get broken
<seb128> sil2100, what is blocking unity and indicator from landing? ;-)
<sil2100> And we still had a lot of regressions in Unity due to HUD, but I guess there's a chance that today we'll be able to land
<seb128> sil2100, oh, and hey ;-)
<seb128> great!
<sil2100> Let me just check the stacks status right now, I'm hoping for the best :)
<didrocks> sil2100: hey! FYI, as you forced the merge of indicator-datetime yesterday, everything was stuck this morning (as libical is still not in the release pocket)
<didrocks> sil2100: so I added -proposed to the daily-build ppa (but we'll still need to convince upstream to add it to their CI)
<sil2100> didrocks: wait, so -proposed was not enabled for daily-build as well?
<sil2100> didrocks: my understanding was that it was missing from CI, but not from our PPA
<didrocks> sil2100: no, I didn't know that was possible, just checked this morning with infinity and enabled
<didrocks> sil2100: that's why https://jenkins.qa.ubuntu.com/job/cu2d-indicators-head-2.1build/216/console took so long
<didrocks> (however libdbusmenu FTBFS)
<didrocks> hum, seems to be a failure to upload, lauchpad issue then
<didrocks> launchpad*
<zyga> barry: is your python3 dbus tree in active development?
<didrocks> sil2100: so, I guess for libdbusmenu, you would need to retry the build in launchpad and then rerun with "foo" to take it into account
<sil2100> didrocks: ACK, will do that, since I'm anyway doing the stackzz now
<tvoss> pitti, can you jump over to #ubuntu-mir? got a question around logind/systemd
<seb128> tvoss, he said he had to go out for some errands half an hour ago, he might not be back yet
<tvoss> seb128, okay, thanks
<cjwatson> slangasek: That update-manager autopkgtest run predated the proposed-migration integration; it should probably just be retried, which perhaps jibel can take care of (I'm not sure whether me abusing adt-britney to do so would have strange side-effects)
<jibel> cjwatson, retrying update-manager
<cjwatson> Thanks
<cjwatson> jibel: Did you get anywhere with making the jenkins integration return running autopkgtests?  I'm waiting to see that working properly before announcing this work
<jibel> cjwatson, I'm on it this morning, expect something early afternoon.
<cjwatson> Brilliant
<m4n1sh> ev: looks like there is a segfault due to some weird reason. I have updated the MP with the backtrace. Even rico had the same segfault, but none of these segfaults happen on clean VMs. but they crash when used on regular installs (being used for some long time)
<ev> m4n1sh: yeah, I saw the MP. Working through it myself, but temporarily pulled over to some deployment work
<m4n1sh> ev: no issues, just thought of asking in case you were free. Anyway I need to sleep
<ev> m4n1sh: enjoy :) I'll have something done for you to review in your morning
<pitti> tvoss: I'm back
<tvoss> pitti, hey there, can you hop over to #ubuntu-mir, we have got some systemd questions about seat management
<asac> cjwatson: i assume there has been quite some discussion in debian etc. about maintainerscripts. do you remember a good overview what classes of things are done in maintainerscripts in practice?
<asac> from top of my head i see: initrd and bootloader poking, dkms, VM/bytecode compile, apt migration hacks/magic ... anything big missing?
<ogra_> alternatives ...
<ogra_> diversions ?
<cjwatson> asac: I don't really have an overview.  The main class of things you're missing is things that are handled by debhelper autoscripts, typically system integration hooks of various kinds
<cjwatson> So things like updating icon caches when icons are installed
<cjwatson> Lots and lots and lots of special cases, e.g. generating sshd host keys
<cjwatson> Configuration file migration between versions
<cjwatson> Adding system users
<pitti> in a nontrivial number of cases, also configuring servers to the user's wishes (debconf)
<pitti> (postfix, databases, wordpress, ...)
<maxb> asac: everything to do with dynamically created system users/groups
<Laney> doko: are you looking at p11-kit?
<doko> Laney, no, not yet
<doko> Laney, do you want to?
<Laney> not particularly :-)
<asac> cjwatson: pitti: maxb: thx!! guess have a good picture now
<asac> ogra_: ^^
<asac> u2
<ogra_> :)
<maxb> asac: In particular, chowning of files to dynamically created users happens in maintainer scripts too (since they can't be shipped that way in the package tarball since the users may not exist at unpack time)
<maxb> Which surprised me when I encountered it at first
<asac> maxb: what class of packages does system user/group shuffling? i feel thats mostly server stuff, right?
<cjwatson> Nah, all sorts of things, anything that needs a degreee of isolation by way of a dedicated user for instance
<cjwatson> e.g. whoopsie
<cjwatson> I mean, server packages yes, but I don't think it can really be pigeonholed
<maxb> libuuid is one of the more unexpected ones which does it
<cjwatson> click-package is notably not server right now and does it :)
<cjwatson> avahi-*, colord, dbus, hplip, pulseaudio, speech-dispatcher, ...
<xnox> cups
<cjwatson> virtualbox, wpasupplicant, bluez, lightdm
<xnox> any daemon one might be running, and not as root
<xnox> samba
<cjwatson> only the server side of samba I think
<xnox> ok.
<jibel> cjwatson, r195 makes 'collect' return the list of running tests.
<cjwatson> jibel: Great, thanks.  Deployed.  Let's see how it does on the next run ...
<jibel> cjwatson, when you announce this work, could you mention that uploaders will be notified on first failure and I'll turn this feature on? Or you prefer if I do it separately
<cjwatson> jibel: Oh, is that ready at the IS side?
<Laney> oh yay, that sounds cool
<pitti> yes, ATM these mails go to a list, jibel, and me
<jibel> cjwatson, yes, it is since a week or so and tested it works. For the moment the blamee is copied in the notification message. There a variable to change to add it to the list of recipients.
<cjwatson> jibel: If it's ready to enable, go for it
<Laney> does it blame the right person for rdep breakage?
<zyga> barry: ping
<jibel> Laney, it blames the uploader of the package that broke, if the package is broken because of an rdep, I have no way to automatically identify the source of the breakage.
<pitti> I guess he means if we upload libfoo to -proposed, this triggers the test of the rdep bar
<pitti> if bar fails, then the uploader of libfoo shold be notified
<xnox> and how is uploader calculated? e.g. for syncs from debian & sponsored uploads.
<jibel> pitti, that'd mean for example it'd blame doko for all the broken packages depending on python or libc ;)
<doko> never!
<pitti> jibel: well, if a new python3.3 breaks ubiquity, that would be kind of right?
<pitti> or libc breaks apache, or what not
<doko> libc -> infinity
<xnox> pitti: but it's me who has irc highlights for "ubiquity" =) ubiquity -> ubuntu-installer team
 * xnox would still blame bar, apache, ubiquity, etc. As that's the person who TIL and should either fix it or punt it to the rdep uploader.
<barry> zyga: in a meeting
<zyga> barry: ok, when can I ping you next?
<jibel> pitti, that's very difficult to determine the cause automatically. For example if symbols are deprecated in a lib and a package depending on this lib fails because warning are considered errors, then the uploader of the lib shouldn't be notified, should he?
<barry> zyga: 50m
<pitti> xnox: then perhaps notifying both? if I upload a new pygobject that breaks ubiquity, then first and foremost I are to blame
<pitti> it's still a matter of investigation and negotiation whether ubiquity should be adjusted to a new API or whatever, of course; same with glib or python
<xnox> pitti: maybe =)
<zyga> pitti: or maybe you can help me instead
<zyga> pitti: I wrote some very cool code for python3-dbus, I was looking for some upstream devs to help me upstream it
<pitti> jibel: I think he should be, to know why/that his package won't land in saucy in the usual 30 minute timeframe
<zyga> pitti: I improved over the basic code to add support for properties with introspection, in a generic manner
<pitti> zyga: I'm not a python-dbus developer I'm afraid
<zyga> pitti: I'm about to work on ObjectManager interface
<zyga> ok, thanks
<pitti> zyga: hm, wouldn't that fit better with using the Gio (introspected) bindings, not python-dbus?
<zyga> pitti: gio? gobject introspection?
<zyga> pitti: we're not using any gobject code in our app and the bindings could very well offer native python equivalent
<pitti> zyga: then perhaps you mean something else with ObjectManager than I do
<pitti> (as that's a GDBus concept in my world)
<zyga> pitti: I meant the std dbus interfaces: org.freedeskto.DBus.{Properties,ObjectManager}
<jibel> pitti, also when several rdeps are tested simultaneously, we do not trigger a package test with depA then depB and depA+depB but just depA+depB, in that case we don't know which is responsible for the breakage, who should be notified?
<pitti> zyga: ah, ok
<zyga> pitti: python3-dbus does not support exporting propeties (you have to code everything manually)
<pitti> jibel: I think we shold notify all affected packages
<zyga> pitti: nor object manager (which is a recent addition IIRC but simplifies stuff a lot)
<pitti> jibel: even if the problem is in the rdep, one point of that notification is to tell that your upload won't land in Ubuntu without further investigation
<pitti> effing powerpc -- you skip one failing test case, now the next one fails !?
<ev> has policykit changed in some subtle way? I would expect perm = Polkit.Permission.new_sync('com.ubuntu.apport.root-info', None, None); print perm.get_can_acquire(); to return True.
<pitti> $ pkcheck --action-id com.ubuntu.apport.root-info --process $$
<pitti> Authorization requires authentication and -u wasn't passed.
<pitti> with --allow-user-interaction it indeed succeeds
<pitti> ev: polkit hasn't really changed in saucy, just that it switched from CK to logind for session tracking; the client-side behaviour shold be identical
<ev> pitti: it's entirely my fault
<ev> was running through a shell not in a desktop session
<ev> and failed to recall why that obviously wouldn't work :)
<pitti> oh, do we only allow active sessions?
<ev> it appears so
<pitti> hm, no, we don't
<pitti>       <allow_any>auth_admin</allow_any>
<pitti>       <allow_inactive>auth_admin</allow_inactive>
<pitti>       <allow_active>auth_admin</allow_active>
<pitti> sounds like it still requires the calling process to be in _some_ session
 * pitti goes to debug suspend, away from IRC for a bit
<stokachu> xnox: should i ping ftpmaster again? i havent seen any activity since youve uploaded it
<xnox> stokachu: package count in NEW: 245 - see http://ftp-master.debian.org/new.html
<stokachu> ah
<xnox> stokachu: i would not hold my breath.
<xnox> stokachu: you are more than half way up the list =)
<stokachu> xnox: lol ok ill keep my eye on this list
<zyga> barry: reping
<barry> zyga: hi.  i think i'm recovered from my kernel panic now :)  what's up?
<zyga> barry: I was looking at someone to contact wrt python3-dbus
<zyga> barry: I recall you have a repo on github with that, is that correct?
<zyga> barry: I wrote a number of improvements over the stock thing, I've got working @dbus.service.propery + Get/GetAll/Set + Introspection XML
<barry> zyga: long ago merged into their trunk
<zyga> barry: and I'm writing ObjectManager code
<zyga> barry: I would like to contribute that all upstream
<barry> zyga: awesome.  simon is very responsive to contributions.  i'm also happy to take a look if you do a pull request
<jamespage> is there a nice way to detect as an upstart event when all network interfaces configured in /etc/network/interfaces have been started?
<zyga> barry: how can I get in touch with simon and where is the real upstream repo for that?
<barry> zyga: let me track some stuff down for you
<zyga> barry: thanks a lot!
<barry> zyga: oy, it's been a long time since i poked at this.  http://cgit.freedesktop.org/dbus/dbus-python/
<barry> zyga: https://bugs.freedesktop.org/index.cgi
<zyga> barry: thanks a lot!
<zyga> barry: I'll see how my code stacks on top of that
<barry> zyga: probably the best thing to do is to file a bug against dbus-python with the feature request.  simon usually responds pretty quickly.  you can also probably dig up his @debian.org address for direct contact
<zyga> I'll start with the bug report
<zyga> cool, my first contribution upstream :)
<barry> zyga: \o/  send me the bug url and i'll subscribe
<zyga> barry: ok
<seb128> cjwatson, sorry to bother you about that again, but we have having an hard time to have a grasp on what we should check for/verify/do to be able to move signon-ui from saucy-proposed to saucy
<seb128> kenvandine, ^ moving the discussion here
<zyga> barry: looking at https://bugs.freedesktop.org/enter_bug.cgi I don't see python-dbus, just dbus, is that the appropriate component
<barry> zyga: yes, i think so.  here for example is one of my still open bugs: https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailreporter1=1&emailtype1=exact&email1=barry%40python.org&field0-0-0=bug_status&type0-0-0=notequals&value0-0-0=UNCONFIRMED&field0-0-1=reporter&type0-0-1=equals&value0-0-1=barry%40python.org&list_id=312978
<barry> oh lovely
<barry> https://bugs.freedesktop.org/show_bug.cgi?id=55594
<ubottu> Freedesktop bug 55594 in python "Documentation should mention that signatures of empty dicts cannot be guessed." [Normal,New]
<barry> zyga: so product dbus component python
<zyga> barry: got it, filing bug now
<kenvandine> seb128, actually let me see if i can make it buildable on powerpc too
<seb128> kenvandine, it will not work, that's cheating... :p
<kenvandine> well it still has the non-qml code path there
<kenvandine> so if i don't build with use-webkit2 config it might work
<seb128> cool
 * kenvandine sets up a ppc pbuilder
<seb128> kenvandine, have no fear ;-)
<zyga> barry: https://bugs.freedesktop.org/show_bug.cgi?id=65900
<ubottu> Freedesktop bug 65900 in python "Python bindings should offer @dbus.service.property and automatically build proper introspection data" [Enhancement,New]
<cjwatson> seb128: I'll have a look at it after this call
<seb128> cjwatson, thanks
<cjwatson> You caught me pretty near EOD yesterday
<barry> zyga: subscribed, thanks
<zyga> barry: thank you!
<pitti> seb128, cjwatson, Daviey, ev: What is your feeling about turning on apport crash reports in Launchpad for saucy? and when?
<pitti> I get pinged about that from time to time
<cjwatson> I'm agnostic on that
<seb128> pitti, no strong opinion either, somebody was asking about it last week I think (bdmurray iirc) so maybe it's time for that?
<pitti> we can certainly say at some point "errors.u.c. is the thing", depends on how intensive we want to deal with crash reporters this cycle?
<zyga> hmm, working on upstream python-dbus requires dbus-1.6, I guess I need to try saucy or something recent
<barry> zyga: rolling releases! :)
<pitti> zyga: saucy loves you!
<barry> or maybe now they should be called sauntering systems
<zyga> pitti: I'm on 12.04 again, since my daily work is really only about 12.04
<zyga> pitti: I guess vagrant is the way forward for me :)
 * psusi can't wait for HAL to die
<sil2100> Hi guys, hm, we seem to get some strange errors on the indicator stack when we enabled -proposed
<sil2100> RuntimeError: the sip module implements API v10.0 but the PyQt4.QtGui module requires API v9.2
<sil2100> Do you think it might be related to some recent changes in -proposed? Or unrelated?
 * sil2100 would need someone from the AP team
<xnox> sil2100: new upstream release of sip4 was uploaded 3 hours ago, it is possible that python-qt4 needs a rebuild.
<sil2100> oh
<sil2100> xnox: hm, thanks for the info
<sil2100> didrocks: ^
<didrocks> cjwatson: this is what happens when enabling -proposed for running the tests, not sure how we can safely get transitions while avoiding those ^
<sil2100> ;/
<cjwatson> you could check installability before starting the test
<rbasak> infinity: any progress on bug 1187722 please? If not, can we apply a less complete workaround to dpkg-shlibdeps to get the golang FTBFS through?
<ubottu> bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Confirmed] https://launchpad.net/bugs/1187722
<cjwatson> and treat uninstallability separately from test failures
<xnox> didrocks: well, case in point python-qt4 is missing a dep8 test which depends on sip4 which would catch the above problem and present sip4 from migrating to -release. So actually -proposed is not the problem here. As saucy-release is borked as well at the moment.
<didrocks> cjwatson: it's installable though
<cjwatson> if it's uninstallable and busted that's a problem in itself!
<cjwatson> er, installable and busted
<infinity> rbasak: The fix needs to be in golang (well, and dpkg-shlibdeps, but that's trivial), not something we just "work around".
<didrocks> cjwatson: yep, but still this kind of issue will block our testing anyway, I have no idea how we can fallback to a safer bet in that case
<xnox> didrocks: we do know that uploading foo can break tests of rdeps bar. and either foo or bar needs fixing.
<infinity> rbasak: If we just work around it, half the archive will end up with a dependency on libsfgcc1. :P
<didrocks> xnox: not in proposed, after proposed, right
<rbasak> infinity: for now, why can we not just assume that if "readelf -A" returns nothing, then the binary's ABI is the same as the host ABI? I understand this breaks for multiarch cross-compile, but that's an edge case on top of an edge case.
<xnox> didrocks: but you will not be able to land. as you have to land via proposed. so a safer bet is to fix python-qt4 asap, and add measures to prevent this breakage in the future.
<xnox> sil2100: didrocks: where are the logs for this API version missmatch?
<infinity> rbasak: We could just fix golang.  It's not rocket science to do so.  This isn't quite something worth panicking over yet, is it?
<sil2100> xnox: you mean, from our side?
<Laney> where did you see that message?
<xnox> sil2100: i mean the full log where " implements API v10.0 but the PyQt4.QtGui module requires API v9.2" error is visible.
<sil2100> xnox: one moment
<didrocks> xnox: right, but just enabling -proposed for the first time shows that we are getting an issue, I'm not sure if it's bad luck or that will make the tests failing too regularly
<rbasak> infinity: we'll have less time to test any other issues caused by the 1.1 bump. Given that the built binary works, I'd prefer to see it in the archive. But it's a good question. I'll try and find out if there's a reason we should fix it sooner. So that I understand the situation right, are you saying that my workaround would work, but you'd prefer to only put it in if we need golang into saucy sooner?
<xnox> didrocks: sip4 migrated to saucy-release, so by enabling -proposed you saw the issue 3h earlier.
<didrocks> xnox: right, but it's just one issue, on potentially a lot :)
<infinity> rbasak: Your workaround could have unintended side effects.  As noted, if we just ignore the HF bits entirely, half the archive will end up depending on libsfgcc1.  This isn't a theory, it happened once and I had to rebuild after fixing dpkg-shlibdeps. :P
<xnox> didrocks: of course. but testing against release pocket, then uploading into -proposed pocket, then failing testing in -proposed, and blocking release is much longer, than doing it in -proposed straight away.
<didrocks> xnox: depends, we have a lot of components to land everyday, if the instability for us to retry too much, that's not going to scale
<xnox> didrocks: as there were initial teething problems with just daily landing, there will be teething problems with using -proposed. But we can flag them up, resolve and minimise to gain an overall improvement.
<infinity> rbasak: But the workaround is also a waste of time when we could just fix the problem.  I only diagnosed this on Friday night, and spent most of Monday in a hospital, 1 working day seems like a pretty short timescale to go from "oh, hey, look, a bug" to "we need hackish workaround now".
<rbasak> Sorry, I didn't realise your perception on the problem was so short. I'd been looking at it since before I filed the bug a couple of weeks ago.
<didrocks> xnox: the only issue with using -proposed is that it's not one time breakage, it can be regular breakages :)
<cjwatson> didrocks: Well, it's a classic velocity vs. quality trade-off; but I don't know how we can do effective quality checks if we aren't testing at least some things from -proposed
<cjwatson> didrocks: Perhaps the CI tests should have -proposed enabled in apt sources, but pinned in apt preferences such that it's only used when necessary
<cjwatson> didrocks: That way transitions would be possible in a useful way but you wouldn't pull in *everything* from -proposed
<cjwatson> didrocks: However I agree with xnox that in this case it seems to have made no practical difference
<rbasak> infinity: can I help with the fix? Or shall I leave it to you? I'm not sure I understand the specifics of the ELF header change you're using (as opposed to the eabi section tags), but am happy to catch up.
<cjwatson> Or very little, anyway
<Laney> Seems weird to be having this argument when it wasn't actually a problem with proposed
<didrocks> cjwatson: in that case, we are quite stuck, as there is the sip transition (until qt4 is fixed), and indicator-datetimes can't be tested with new libical, right
<cjwatson> But the sip transition is in release, so you'd have been stuck anyway.
<cjwatson> And if sufficient attention had been paid, this could have pointed out that (it sounds like) sip4 is missing a Breaks field and we could have caught that before it affected users ...
<infinity> Hrm.  I haven't had a kernel panic in a long time.  That was exciting.
<didrocks> cjwatson: ah ok, I missed that one (I thought it will transition soon, just not yet)
<cjwatson> Damnit, I want 'dak rm -Rn' for this signon-ui thing
<didrocks> cjwatson: I think I a Ken who will be really interested as well :)
<cjwatson> seb128: Were we going to rebuild empathy without signon support on powerpc to simplify this?
<cjwatson> seb128: (I could take care of that if it would help - the fewer dependencies I need to trace by hand the better)
<seb128> cjwatson, if that helps we can
<seb128> cjwatson, we are bit lost on where to start
<seb128> looking at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/rdepends/signon-ui/signon-ui is hard
<cjwatson> I'm starting by tracing the rdeps back with checkrdepends -a powerpc
<cjwatson> Unfortunately it doesn't distinguish Depends and Recommends, so some manual checks too
<cjwatson> And for each binary package working out what tearing out all binaries from that package on that architecture will do, recursively
<seb128> quite tedious :/
<xnox> didrocks: sil2100: let me fix the python-qt4 problem. And I will ping you once it's uploaded.
<cjwatson> Like I say this is a really boring way to spell 'dak rm -Rn -a powerpc -b signon-ui'
<cjwatson> But oh well
<didrocks> xnox: thanks a bunch :)
<sil2100> xnox: thanks! We'll re-launch our machinery then
<cjwatson> seb128: I'll sort out empathy now
<seb128> cjwatson, would it help if we start by building empathy without uoa support on ppc?
<seb128> cjwatson, ok, thanks, let me know if we can do anything to help
<seb128> kenvandine, ^
<cjwatson> seb128: Yep, that was my plan
<kenvandine> cjwatson, great, thanks!
<ev> mpt, bdmurray: a heads up. We're going to have to purge reports from the database that don't have a DistroRelease field. I'll have it increment a counter for the day period that these were written, so we have some history of how many such (bogus) reports we were getting
<ev> (in a critical disk space situation on the cluster)
<mpt> ev, how much time will that buy? :-)
<ev> mpt: barely any
<ev> suggestions welcome on how we can further define a bogus report that can be sent to the abyss
<ev> this is in parallel to bringing up some more nodes in production
<cjwatson> kenvandine: Something like http://paste.ubuntu.com/5777580/ look vaguely right?  I'm going to test that shortly
<ev> to further spread the load
<kenvandine> cjwatson, close
<kenvandine> +  DEB_CONFIGURE_EXTRA_FLAGS += --enable-ubuntu-online-accounts=yes
<kenvandine> you want that to be =no for powerpc
<kenvandine> unless you meant ifneq
<cjwatson> I have that on the wrong side of the if, indeed
<cjwatson> Is that the right set of build-deps to disable, and is removing that set of binary packages correct?
<kenvandine> cjwatson, ues
<kenvandine> yes even
<sil2100> kenvandine: can you approve some changelog-modding branches?
<sil2100> kenvandine: https://code.launchpad.net/~sil2100/bamf/add_bug_number/+merge/170134
<sil2100> kenvandine: https://code.launchpad.net/~sil2100/gnome-control-center-unity/add_bug_number/+merge/170114
<kenvandine> sil2100, sure
<sil2100> kenvandine: thanks!
<kenvandine> np
<kenvandine> seb128, to get signon-ui to build on ppc, even without qtdeclarative, we'd need libqt5webkit5-dev for powerpc
<kenvandine> which isn't available for powerpc either :/
<seb128> kenvandine, :-(
 * kenvandine scratches the goal of building signon-ui for ppc
<seb128> so we just need to kick uoa use out of desktop on ppc
<kenvandine> seb128, yes
<cjwatson> Now if cdbs would stop being appalling I might be able to disconnect empathy from this
<kenvandine> it isn't useful anyway, since we only show the settings panel in unity
<xnox> sil2100: didrocks: rebuilding python-qt4 resolves the sip api missmatch error. I have added an autopackage test in python-qt4 to literary do "python -c 'from PyQt4 import QtGui' " thus if sip breaks python-qt4 in the future, we would know about it straight away. It's building at the moment: https://launchpad.net/ubuntu/+source/python-qt4/4.10.1-1ubuntu2 so once that is published and the new autopkgtest pases it should be green light to restart everyt
<xnox> hing that has failed.
<didrocks> xnox: excellent, thanks! :)
<cjwatson> For clarity I consider removing signon-ui from powerpc to be agreed and will do it; I'm just trying to minimise the complexity
<seb128> cjwatson, +1
<kenvandine> cjwatson, +1
<kenvandine> thanks!
<kenvandine> cjwatson, i just took a stab and making it easier to deal with... but failed
 * cjwatson nods
<xnox> didrocks: i wonder if it makes sense to check reverse-dependancy autopkg tests for green light, before starting CI. As if reverse-dependancies are borked, there is little point in testing something higher up in the dependancy chain.
 * xnox is not entirely sure about that atm.
<cjwatson> Looks like setting DEB_ARCH_PACKAGES this way doesn't work - may have to settle for the crappy explicit list of architectures
<AugustVento> test
<AugustVento> when i start ubuntu ,it give me some message, "[    15.117693] INFO @wl_cfg80211_attach : Registered CFG80211 phy"
<AugustVento> i just know, it about wireless hardware, how to fix it ,or hide that message
<sarnold> AugustVento: you can set the loglevel kernel command line parameter to show only messages of a certain importance and higher: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
<bdmurray> ev: there is also that extra data in Counters for release source package crash counts
<bdmurray> ev: we only "need" two weeks of data so stuff before that could go
<AugustVento> ok sarnold ,i try it.
<bdmurray> pitti: I don't think errors is ready to be the thing until we have those server side hooks
<slangasek> pitti: yay, thanks for the g-s-d fix
<sil2100> xnox: thanks! Do you have any reverse-feedback on when it would be released? I would love to know when I can re-build stuff
<lool> cjwatson: I think you can just pass -Npkg in some arg that gets passed to dh_*; digging that up
<cjwatson> lool: There's no way to get cdbs to pass it to dh_listpackages, but I suppose it's possible that DH_OPTIONS := -Nblah would help
<lool> cjwatson: Yeah, I think that's what I used
<cjwatson> The problem is make doesn't re-export to $(shell)
<cjwatson> Which is apparently a well-known bug
<ev> bdmurray: noted, thanks!
<cjwatson> dh doesn't suffer from this because it doesn't use $(shell) in that way
<ev> first looking at the Stacktrace CF, which most certainly doesn't need ProcEnviron and friends
<xnox> sil2100: just wait until https://launchpad.net/ubuntu/+source/python-qt4/4.10.1-1ubuntu2 is published in release. Probably in 2h-3h or so. python-qt4 is huge to build.
<sil2100> Uuuh ;)
<sil2100> Ok!
<lool> maybe DEB_DH_BUILDDEB_ARGS is enough; I can't find a package doing this anymore
<sil2100> I'll re-run stuff in that time then, keeping an eye on that
<andyrock> Laney, hey I got a fix for the nautilus crash
<andyrock> do you want me to update your .patch or add a new one?
<seb128> andyrock, update the patch
<seb128> andyrock, submit upstream as well please ;-)
<andyrock> seb128, maybe I can change the name?
<andyrock> seb128, nautilus 3.8 can't have that issue
<andyrock> seb128, they refactored "a bit"
<cjwatson> lool: The problem is that cdbs runs each package independently with -p
<cjwatson> Rather than doing single bulk runs with -a/-i
<seb128> andyrock, oh ok, just update the patch in a way that fix it and write as a comment that it's fixed upstream in 3.8
<xnox> cjwatson: i would have thought, it should be possible to filter the internal cdbs DEB_ARCH_PACKAGES and DEB_INDEP_PACKAGES to exclude whichever one you don't need. The rest of cdbs machinery works against packages from that list.
<andyrock> seb128, i still need to check that nautilus 3.8 is not affected hang on
<xnox> but i'm not entirely sure, didn't have to do anything like that before.
<seb128> andyrock, ok
<seb128> cjwatson, just port it to dh9 ;-)
<xnox> .... or that =)
<cjwatson> seb128: No, it runs into https://savannah.gnu.org/bugs/?10593
<cjwatson> Er
<cjwatson> xnox: No, it runs into https://savannah.gnu.org/bugs/?10593
<seb128> speaking of make we should maybe update our version one cycle ;-)
<cjwatson> it's deliberately held back
<cjwatson> the new version breaks a LOT apparently
<lool> cjwatson: adding -Npkg before or after -ppkg should still skip it (seems to work with dh_listpackages); I can't find a package doing that, but DEB_DH_BUILDDEB_ARGS += -Npkgname would possibly work
<lool> you probably would have to skip dh_install and dh_builddeb at least; I don't see anything simpler with cdbs right now
<lool> seb128, kenvandine: Believe it or not, some IBM folks stepped up to port v8 to powerpc!  :-)  they are based on a newer version than the one in the qtwebkit source we have, and they have 88% of the tests passing
<seb128> lool, nice ;-)
<lool> https://github.com/andrewlow/v8ppc/blob/master/README.md
<lool> they are based on a september snapshot, qtjsbackend-opensource-src has an april 2012 snapshot
<seb128> lool, though qtdeclarative is moving to its own js engine as you said
<seb128> so not sure how useful that will be
<lool> seb128: yeah, but that's probably longer term
<lool> it might mean that qtdeclarative does *not* support powerpc in the end  :-/
<lool> IIUC from Zoltan qtdeclarative could be built against multiple JS engines so far, and that was a source of headache and they weren't performing well given the constraints on QML objects
<lool> a new JS engine might perform better, but might have its own set of features/bugs and the JIT might only be ported to this or that architectures
<cjwatson> lool: I've tried a few variations and nothing works.  TBH I'm fed up and am just going to hit it with "Architecture: amd64 armhf arm64 i386" ...
<cjwatson> I only have so much time to spend on this
<lool> cjwatson: sorry  :-/  I know it aint fun to reverse engineer the cdbs weirdnesses
<gotwig> how can I install a glib schema with autotools
<tedg> Hello, looking for an archive admin.
<tedg> Need to add a new package to daily builds, and apparently it has to be whitelisted?
<tedg> Not sure exactly, first time :-)
<tedg> The package is upstart-app-launch
<infinity> tedg: Pulled the new configs.
<tedg> infinity, Cool, thanks!
<Laney> andyrock: you still here? nautilus 3.8 definitely does still have that crash
<Laney> I filed it upstream; see https://bugzilla.gnome.org/show_bug.cgi?id=702546
<ubottu> Gnome bug 702546 in Crashers "Crash in in nautilus_trash_bar_dispose at nautilus-trash-bar.c:109" [Critical,Unconfirmed]
<tjaalton> slangasek: hey, what does 'unix-zany' mean on libpam-cracklibs pam-auth-update config?
<slangasek> tjaalton: that's a good question... that looks like an example that leaked into production ;)
<tjaalton> hehe
<tjaalton> yeah I thought so :)
<tjaalton> so I'll drop it from the file for libpam-pwquality then..
<slangasek> tjaalton: yeah, probably should :)
 * Noskcaj is away: school
#ubuntu-devel 2013-06-19
<cjwatson> Hm, that was interesting, experimentally forcing signon-ui so that I could see which uninstallables it created said no new uninstallables and let it in
<cjwatson> I suspect partial-NBS doesn't behave the way I think it does
<infinity> cjwatson: testing-ports seems to pick it up.
<infinity> cjwatson: although, wait, all those problems exist for primary arches too.
<infinity> (p11-kit promoted, BTW, don't bother doing it again)
<cjwatson> ack
 * cjwatson fixes a few more blockages in proposed-migration
<cjwatson> gvfs (1.17.1-0ubuntu1 to 1.17.2-0ubuntu1)
<cjwatson>     Maintainer: Ubuntu Developers
<cjwatson>     autopkgtest for gvfs 1.17.2-0ubuntu1: FAIL
<cjwatson>     Not considered
<cjwatson> woo, progress
<infinity> cjwatson: Speaking of partial NBS, we don't actually have a useful report for that, do we?
<infinity> (Other than britney blocking migration, potentially)
<cjwatson> I think http://people.canonical.com/~ubuntu-archive/testing/saucy_outdate_all.txt should cover it
<infinity> Oh, fair point.
<cjwatson> Along with other stuff
<infinity> Just lacks the mind-numbing autopilot of the NBS report.
<infinity> DON'T MAKE ME ACTUALLY THINK WHILE READING REPORTS!
<cjwatson> But cantor there looks like partial NBS to me
<infinity> (Then again, I didn't even know about the NBS report for ages, and used to always work from outdate)
<infinity> Yeahp, that backend does indeed look gone from ppc/arm
<infinity> Though, with no changelog mention of same...
<infinity> control agrees, though.
 * infinity knocks it out.
<ScottK> xnox: I think your autopackagetest for python-qt4 is pretty pointless.  The more usual problem is sip4 has been updated and python-qt4 hasn't.  autopackagetest on python-qt4 doesn't really help.  One for sip4 that notices it's got a different API version would be useful.
<ScottK> xnox: You'll also probably want to merge the new python-qt4 from Debian since it's needed for PyQt5, which I think is wanted in Debian.
<ScottK> Debian/Ubuntu
<ScottK> Also, it needs rebuild against the new sip4 again since the API version wasn't set right on the first one.
<andyrock> Laney, yeah i can reproduce it too with nautilus 3.8
<andyrock> not sure about nautilus trunk
<pitti> Good morning
<dholbach> good morning
<m4n1sh> didrocks: ping. as you requested me to file  a bug for zeitgeist sponsorship for saucy https://code.launchpad.net/~zeitgeist/zeitgeist/saucy-packaging-0-9-14/+merge/170244
<m4n1sh> here is the full MP (thanks to ricotz)
<halfie> hi, are there any plans to turn on "-fstack-protector-strong" in Ubuntu ?
<didrocks> m4n1sh: excellent! it should appear on the sponsoring list, people getting their patch pilot shift should sponsor it!
<didrocks> thanks :)
<pitti> halfie: happened like 4 years ago
<pitti> oh, -strong; not sure
<pitti> mdeslaur_: ^
<halfie> pitti, heh ;)
<m4n1sh> didrocks: that is great
<rbasak> mdeslaur_: please could you consider bug 1192367? Seems valid to me - don't we support Lucid on server for another couple of years? puppet was in main then. Although it's a really old version - perhaps it's not vulnerable?
<ubottu> bug 1192367 in puppet (Ubuntu) "No security release provided in Lucid for CVE-2013-3567" [Undecided,New] https://launchpad.net/bugs/1192367
<mardy> tyhicks: ping
<cjwatson> ScottK,xnox: An autopkgtest in pykde4 would be run whenever sip4 changes (or should, anyway), so it could be used to effectively enforce constraints on sip4's behaviour from the point of view of pykde4
<cjwatson> ScottK: (I'm still finishing putting the pieces of the proposed-migration work together ... planning to announce it shortly)
<cjwatson> didrocks: So, signon-ui landed, but now we have unbuildable images because qtwebkit-opensource-src is in universe and there's no MIR
<cjwatson> didrocks: Given webkit there is no way I'm going to move that without signoff from security :)
<didrocks> cjwatson: right, I understand. Is it an new dependency? (or we didn't transition to Qt5 before?)
<didrocks> the publication was manual if there was any packaging change, not sure why ken acked it without the MIR
<cjwatson> didrocks: AFAIK it's a new dependency
<didrocks> I know that ken already talked with the security team about qtwebkit, but I'm not on top of latest outcomes
<cjwatson> https://launchpad.net/bugs/1157732 is the MIR bug for other chunks but I don't really see an unambiguous statement there that qtwebkit-opensource-src is OK, and there's no bug task for it
<ubottu> Launchpad bug 1157732 in ubuntu-ui-toolkit (Ubuntu) "[MIR] circle of friends" [Undecided,Fix committed]
<cjwatson> didrocks: Indeed, signon-ui 0.14-0ubuntu2 was on Qt4
<cjwatson> Which was the version in the saucy release pocket until last night
<seb128> urg :/
<didrocks> cjwatson: yeah, it has been acked manually when we were using the next ppa
<didrocks> I have no good clue of what we can do apart if a revert is possible for now
<didrocks> and check with ken/jdstrand when they are online
<seb128> I think the security team didn't like much having another webkit in main when that was discussed before raring, dunno if that changed since though
<cjwatson> If you're considering a (partial?) revert then please keep a note on https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog
<didrocks> right, but then PS started to use that as their supported html5 stories, when I told yesterday to them to ensure things can be MIRed before starting dep on it
<didrocks> cjwatson: do you mind waiting on kenvandine? he would know more if we can revert safely or not
<cjwatson> I don't mind, it just means you owe me a few hours of patience the next time you have a problem that you want me to fix ;-)
<didrocks> cjwatson: ken owes you if you want to make the count rights :p
<cjwatson> Next time you have a problem *that I didn't cause* that you want me to fix anyway ;-)
<didrocks> heh, right :-) (well, I'm not sure I rang the bell alarm too much on you for stuff to be fixed right away IIRC)
<didrocks> I just prefer to ensure that the revert will not create more issues that we didn't know of
<cjwatson> Quite so
<cjwatson> Especially since we did other things to prepare for moving forward
<didrocks> cjwatson: or can we upload it to -proposed and block it?
<cjwatson> I entirely appreciate it's not a simple revert
<didrocks> so that it's quicker to take a decision once ken is back
<cjwatson> I think just having the packages ready would be fine
<didrocks> ok, let me prepare it, just in case
<seb128> cjwatson, sorry about the extra work created there, I didn't think to check the new build-depends/depends and the MIR state when Ken pinged about it :/
<cjwatson> Nor did I in fairness
<didrocks> we'll figure it out :) still quite stressed about all this extra load on qtwebkit and the push there is in PS to use that as our main html storyâ¦
<didrocks> mardy: hey, you are around! do you know if we revert to the previous signon-ui (0.14) using Qt4, we'll get any issue? ^
<seb128> didrocks, the reason Ken wanted the new version out of proposed is that the old version was broken on the touch image, but I don't know the specific of the breakage
<seb128> didrocks, you can't use online account on touch with 0.14, it works with 0.15 though
<didrocks> seb128: ok, we can still mitigate that with the "armhf" double builds if upstream supports that
<didrocks> hum, no we can't, ignore me
<didrocks> (as it's a build-dep, even if we set the armhf binary in universe)
<didrocks> cjwatson: do you know if it's possible/desirable to have britney making this sanity check as well?
<cjwatson> possible, arguably desirable, but very difficult
<cjwatson> it'd be very significant reengineering of a bit of the code I really don't understand
<didrocks> ok, let's hope we don't have that much "humman review errors" and let's put that on the count of all the drastic changes we have under way to try paying more attention to it :)
<RAOF> pitti: Can we have a talk about logind and VTs and such?
<RAOF> pitti: Or, rather more specifically, do you have any free cycles to do the finangling?
<didrocks> cjwatson: seb128: ok, at least, old signon-ui still builds, and the g-c-c interface is working after some tests. So, the package is ready once ken is up
<cjwatson> didrocks: So, I'm trying to tear out the remaining bits related to signon on powerpc, but I want to make sure that any binaries I remove won't just come back (uninstallable) on the next build
<didrocks> cjwatson: they will come back I'm afraid with Qt4 and arch: any, should I list the archs to prevent that?
<cjwatson> This is at higher levels, not in signon-ui
<didrocks> ah ok, so this won't impact it
<mardy> didrocks: hi! can you brief me on the reasons?
<cjwatson> didrocks: ... actually, never mind, in gathering more data for the question I was going to ask you I realised it was moot :-)
<cjwatson> I think, anyway
<mardy> didrocks: the latest version should be buildable on Qt4 just fine, anyway
<didrocks> cjwatson: ok, if you have this list of packages you are removing to put me into the context (I wasn't close to that topic, ken was handling it), FYI signon is building on powerpc: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3315384/+listing-archive-extra
<cjwatson> didrocks: Yeah, I was just looking at that
<cjwatson> didrocks: I think maybe an arch restriction in signon would make sense?
<didrocks> cjwatson: I think so, I'm digging in why https://launchpad.net/~ubuntu-unity/+archive/daily-build/+files/libsignon-qt5-1_8.52daily13.06.19-0ubuntu1_powerpc.deb is even possible as there is no powerpc Qt5â¦
<didrocks> ah maybe that part doesn't use qtscripts
<cjwatson> There is a powerpc Qt5, just not the v8-dependent stuff
<didrocks> cjwatson: why should we restrict it then?
<cjwatson> Maybe we shouldn't, that's why I'm asking :)
<didrocks> mardy: ok, I'll try that as well, the issue is that you are depending on qtwebkit and it's in universe, not in main
<cjwatson> I'm trying to work out how to neatly tear out the stuff that depends (recursively) on signon-ui
<didrocks> mardy: so we can't get it on the iso by default (and as we don't have the old version, we can't even build the iso)
<didrocks> isn't the other way around? signon-ui dep on signon? /me checks
<cjwatson> And I get to gnome-control-center-signon which depends on libaccount-plugin-generic-oauth and libaccount-plugin-google which depend on signon-plugin-oauth2 which depends on signon-plugin-oauth2
<cjwatson> ... which depends on signon-ui, I mean
<cjwatson> But there are no build-dependency relationships there so I can't remove those binaries without them coming back on the next build
<mardy> didrocks: I'd vote for dual builds, and generate signon-ui-qt4 and signon-ui-qt5, both providing signon-ui (virtual)
<mardy> didrocks: but I'm no expert in this stuff, so feel free to ignore me :-)
<didrocks> (ah, it's a recommends for signond -> signonui)
<pitti> RAOF: sorry, in between some appointments, today is a bit crazy
<didrocks> mardy: won't work, it's a build-dep anyway, so the source would need to be in main
<cjwatson> Right, the Recommends isn't enough to justify removing signond
<pitti> RAOF: so the bottom line is, logind needs to grant ACLs to processes which have a $DISPLAY, but don't have a controlling terminal
<pitti> RAOF: is that XMir process in a session cgroup at least?
<pitti> RAOF: i. e. /proc/pid/cgroup/ has it in a session? if not, it's going to be difficult
<didrocks> cjwatson: so, we should "just" ensure that gnome-control-center-signon, libaccount-plugin-generic-oauth and libaccount-plugin-google, signon-plugin-oauth2 doesn't build on powerpc?
<pitti> RAOF: at any rate, would you mind filing a bug about it with the summary?
<pitti> RAOF: I can have a look at it this afternoon in the train
<cjwatson> didrocks: Possibly webaccounts-browser-extension as well
<RAOF> pitti: Will do.
<Noskcaj> roaksoax, kirkland: would you guys mind lurking in #ubuntu-quality so it's easier for smartboyhw and i to talk to you.
<pitti> RAOF: can you please include the loginctl output, /proc/pid/{status,cgroup} bits?
<RAOF> Will do.
<pitti> RAOF: or some pointer how to install xmir to test it end to end :)
<pitti> RAOF: thanks
<RAOF> I'll do both :)
<didrocks> cjwatson: do you think that captures everything?
<didrocks> https://code.launchpad.net/~didrocks/gnome-control-center-signon/dont-build-powerpc/+merge/170273
<didrocks> https://code.launchpad.net/~didrocks/account-plugins/dont-build-powerpc/+merge/170274
<didrocks> https://code.launchpad.net/~didrocks/webaccounts-browser-extension/dont-build-powerpc/+merge/170276
<cjwatson> didrocks: I think so.  Consider pre-emptively adding arm64 too
<cjwatson> (On the perhaps optimistic assumption that v8 will work there, I guess ...)
<didrocks> cjwatson: ok, let's be optimistic, pushing those :)
<didrocks> cjwatson: ok, done, IIRC, I've handled the case of archs not existing in ubuntu but listed in daily release (at least, the unit test pass ;)), I'll see with next dailies
<didrocks> mardy: mind having a look and approving those 3 MP? ^
<didrocks> cjwatson: HUD under publish, finally (tests pass and components build)! no more julius* recommends, phewâ¦
<cjwatson> oh, yay
<xnox> ScottK: cjwatson: i thought that python-qt4 autopkgtest would be triggered by sip4 uploads, due to sip-api-9.2 dependency. or did I get that wrong?
<RAOF> pitti: Sorry, everything's being terrible here. I'll get the info and file that logind bug tomorrow.
<mdeslaur_> rbasak: puppet isn't on the list of packages we still support for lucid: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/lucid-supported.txt
<rbasak> mdeslaur_: I understand that, but I think there may be a problem with that list.
<mdeslaur_> rbasak: even if it were, it's so old, that it's pretty much impossible to fix the few latest security issues, as upstream has rewritten a whole lot of the code
<rbasak> mdeslaur_: I understand that it may not be possible, or may be hard. But that specific issue aside, I'm confused as to our support policy for Lucid on Server. AIUI, it's supported, and puppet was seeded, so should be on your list. So the bug reporter seems to have a valid point. Have I got that part wrong? Why does puppet not appear on your list?
<mdeslaur_> rbasak: I suggest using the package upstream provides
<mdeslaur_> rbasak: I does't appear on our list because it was deemed one of the packages that we couldn't possibly support for 5 years
<rbasak> Was that decision published anywhere that I can point the bug reporter to?
<cjwatson> xnox: It should do.
<cjwatson> xnox: But that's all very new and unannounced and I can forgive developers for not being aware of it :-)
<xnox> ok.
<rbasak> mdeslaur_: so the policy is that it is supported, but puppet is an exception? Are the exceptions documented anywhere, and are there any more?
<mdeslaur_> rbasak: that list is the authoritative source, as used by the security team. Whatever  is not on the list is no longer supported.
<rbasak> mdeslaur_: OK, thanks. It sounds like there's a disconnect between the security team's authoritative source and what we communicate with the outside world. I think that's probably more of an issue on the Server side, so I'll take that up there. Thanks for explaining this to me.
<mdeslaur_> rbasak: is there a place where this is communicated?
<xnox> rbasak: well, there are plenty of corner cases like that. hence the push/desire to have archive-reorganisation and flexibly define what's supported, security-support only, and in main only due to build-depends.
<mdeslaur_> xnox: +1
<rbasak> mdeslaur_: everywhere. We say that Server has 5 year LTS for Lucid.
<mdeslaur_> rbasak: I'll see if I can add a link to wiki.ubuntu.com to clarify where the authoritative list is
<mdeslaur_> rbasak: yes, the list contains server packages
<rbasak> mdeslaur_: I appreciate that technically we need to work from an authoritative list. But what we communicate is that it has 5 year support, period. And that doesn't hold true if we have exceptions.
<mdeslaur_> rbasak: As I said, I'll add the list to the wiki
<mdeslaur_> rbasak: even if I added puppet back to the list, it's unfixable
<mdeslaur_> thankfully we won't have this problem with precise, as it's 5 years across the board
<rbasak> mdeslaur_: I feel that 1) in every single place we claim 5 year support, we should make it clear that some "server" packages aren't included, and list them (so a diff against the seed, rather than a list of what is supported), and 2) for where something is unfixable but not in that published list, that this can happen of course, but we should declare and justify this in the security announcement.
<mdeslaur_> rbasak: ok, it's wiki, feel free to modify as you see fit
<ScottK> xnox: Could be.  Sip-api-10.0 is in saucy-proposed now, so if it was going to be, it would have.
<xnox> ScottK: i don't see python-qt4 adt job in jenkins at all.... either it's not been picked up yet or i added it wrong.
<cjwatson> Hmm
<cjwatson> jibel: doesn't look like the reverse-dep handling is working?
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sip4 should at least mention a pykde4 job
<jibel> cjwatson, looking
<mlankhorst> could some sru move mesa from raring-proposed to -updates?
<cjwatson> jibel: ah, I wonder if it doesn't deal with virtual packages?
<cjwatson> jibel: the dep in pykde4 is on sip-api-9.2
<cjwatson> mlankhorst: I'd normally wait for it to age 7 days, so tomorrow according to http://people.canonical.com/~ubuntu-archive/pending-sru.html
<mlankhorst> cjwatson: yeah but it's also been in saucy for a while
<cjwatson> sure, but that's the baseline state for SRUs
<cjwatson> or at least is supposed to be
<cjwatson> so, put another way, I can do it but you'll need to explain why I need to waive the waiting period :)
<mlankhorst> I want to upload a fix for https://bugs.launchpad.net/ubuntu/+source/mesa-lts-raring/+bug/1175533
<ubottu> Launchpad bug 1175533 in linux (Ubuntu Quantal) "[HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] " [Critical,New]
<xnox> cjwatson: pykde4 doesn't have autopkgtest?! but python-qt4 does. https://launchpadlibrarian.net/142758139/python-qt4_4.10.1-1ubuntu2.dsc unless I misspelled it somehow. But yeah the dep is on a virtual package. Could check reverse build-deps as well, since that has "real" package.
<xnox> jibel: tells me that britney should have had requested test result for python-qt4, back when it was initially uploaded with added autopkgtest. but that didn't happen?
<mdeslaur_> halfie: we're considering it, but need to evaluate it properly. We're pretty busy with app confinement at the moment, so it definitely won't be soon.
<mdeslaur_> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur_
<jibel> xnox, it might be a problem with handling of virtual packages in rdep resolution, that's what i'm verifying
<cjwatson> xnox: Oh, well, OK.  Either way.
<halfie> mdeslaur_, cool, what exactly is this app confinement thing? is it related to selinux and mac stuff?
<mdeslaur_> halfie: it's related to confining apps with apparmor: https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
<halfie> mdeslaur_, ah I see, is apparmor ubuntu only or have other distributions adopted it. (I know Fedora doesn't use it?).
<mdeslaur_> halfie: suse uses it, and it's available in a whole bunch of other distros, including debian, gentoo, arch, etc.
<halfie> mdeslaur_, cool, I am working on doing some benchmarking on this new strong stack protector patch.
<mdeslaur_> halfie: care to join #ubuntu-hardened if you want to talk about security?
<halfie> mdeslaur_, sure
<jibel> cjwatson, is there a log of the requests submitted by britney?  I generated a request file on lillypilly and see this line:
<jibel> "python-qt4 4.10.1-1ubuntu2 NEW python-qt4 4.10.1-1ubuntu2" which means that python-qt4 will be tested because 4.10.1-1ubuntu2 has been uploaded, but I do not see any request on jenkins side, hence no job.
<pianogmx> is there someone who can point me towards a project / team that would teach me some stuff of linux software development?
<cjwatson> jibel: It should spit out a line with the substring "Requested autopkgtest" in its own log (~/proposed-migration/log/$date/$time.log)
<cjwatson> But apparently isn't doing so ...
<cjwatson> I mean not for this one at least
<jibel> ok, that's the location I checked
<asac> doko: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-android-builds-revisited ... the two work items for 13.05 in there are done?
<cjwatson> I didn't make it log all packages it was requesting because there was a lot of verbosity there
<cjwatson> Since it basically re-requests all packages that are valid candidates and lets adt-britney sort it out
<doko> asac, yes, but afaik ogra_ doesn't use these yet, so we don't have any feedback, if these actually work
<asac> doko: what did you do for validating?
<ogra_> doko, xnox took over the android packaging
<xnox> doko: asac: Ogra and I are in progress of verifying that the said toolchain produces binaries that do run.
<asac> please set your work items to done and add work items for ogra to test and ack that they work :)
<ogra_> right
<asac> if you want him to do something
<asac> (at least that feels like the obvious way to go)
<ogra_> asac, i'm fully out of that spec apart from lending a hand
<asac> ogra_: you are the owner
<cjwatson> jibel: I'll attack it with pdb, I guess
<asac> so you are responsible that this happens
<ogra_> (well, i might keep the "schedule a discussion for 14.04)
<asac> through talking and escalation etc. in case you dont do engineering work :)
<asac> and helping
<xnox> ogra_: doko: asac: updated workitems.
<asac> cool
<ogra_> asac, right ... no need for me to kick any butts atm ... it all goes smoothly forward
<asac> xnox: thanks a bunch
<asac> ogra_: the work items were not properly cleared up at end of 13.05 :)
<ogra_> and xnox didnt know about the blueprint until a few mins ago
<asac> so yes, you just need to kick your own butt :)
<asac> lol
<ogra_> ascteh WIs arent done yet
<asac> what?
<asac> never seen ascteh :)
<ogra_> there is no bionic in the archive yet
<ogra_> yeah, my tab key messed it up apparently :)
<pianogmx> are there any devs that can mentor me into learning how to develop for the ubuntu project?
<asac> ogra_: ok, but bionic is on track?
<ogra_> it is in a PPA
<ogra_> i think xnox is on getting it into the archive once we know it produces usable binaries
<ogra_> (which we are in the middle of)
<cjwatson> mlankhorst: mesa/raring released now
<mlankhorst> thanks
<cjwatson> pianogmx: Probably best to read through https://wiki.ubuntu.com/ContributeToUbuntu, chase links for things you're interested in, and then ask questions about specific things that confuse you
<cjwatson> (one of those links is https://wiki.ubuntu.com/UbuntuDevelopment which may be more specifically relevant)
<cjwatson> jibel: The file given to adt-britney request includes the line "sip4 4.14.7-2" (in full: http://paste.ubuntu.com/5780463/).  The output contains only headers.
<cjwatson> jibel: The logging output includes "2013-06-19 13:34:18,563 WARNING "The cache has no package named 'sip-api-9.2'"", which seems possibly relevant
<roadmr> hey folks! A code reorganization in my project (checkbox) means that the debian directory is not in the top level of the source branch (it's under checkbox-legacy). Can this be uploaded to lp:ubuntu/checkbox? are specifications for source branches documented somewhere? FWIW I can generate and upload the source packages from that subdir just fine
<cjwatson> roadmr: I don't know if it's documented but that would very definitely violate my expectations of lp:ubuntu/foo.  If you're doing that then I think you should use some other branch outside the lp:ubuntu/ namespace, and consign lp:ubuntu/checkbox to the auto-importer.
<cjwatson> Part of the point of lp:ubuntu/foo was for it to be roughly the same shape for every package.
<cjwatson> If you tried to push that to lp:ubuntu/foo I would expect the importer to blow up in interesting ways and/or overwrite your branch.
<roadmr> cjwatson: ok, that makes sense, but I wanted to check first
<jibel> cjwatson, there are 2 issues in adt-britney 1) virtual packages are not considered, 2) a logical error when matching the list  dependencies in the request file to the list of packages with tests. I'm on a fix for both
<cjwatson> Righto, sounds good, thanks
<jibel> (1 causes the warning in the log)
<ScottK> xnox: Would you please figure out if we should keep your python-qt4 autopackagetest or not as we need to do a merge from Debian.
<xnox> ScottK: i'll keep it for now, and will deal with merging python-qt4 in a moment.
<ScottK> xnox: Thanks.
<rbasak> What does TIL actually stand for?
<mdeslaur_> rbasak: "Touched It Last"
<mdeslaur_> as in "Sucker! You TIL!!!!"
<doko> barry, just to mention it here ... cross-building the base system was a goal for raring and is a goal for saucy. please don't drop any cross-build support when merging things from debian
<barry> doko: i'm not going to drop it, but i just want to express caution.  until debian supports it, we will fall increasingly behind unless we have enough manpower to do more manual syncs.  i guess we'll see if that's a real problem or not
<cjwatson> Debian's been taking quite a few cross-building patches
<cjwatson> IME
<cjwatson> In fact we're getting near the point where in some cases I'd consider NMUing for them
<cjwatson> I might go on a delayed-NMU spree this weekend :)
<barry> cjwatson: this came up with me wanting to sync zope.interface.  the delta we carry is that we b-d on python{,3}-all-{dev,dbg}:any.  if we do more of these, and can't get those changes back into debian, then we may find ourselves getting increasingly behind debian, which i really want to avoid.  autosyncs ftw!
<doko> barry, that's life. being able to cross-build is needed for us
<barry> cjwatson: if/when we *can* get those changes into debian, then i will be happy again
<cjwatson> Oh, yeah, the :any bit is a bit unfortunate; I was hoping to talk with buildd maintainers at or before debconf about that
<cjwatson> It will be sorted out eventually
<barry> cjwatson: cool, thanks.
<doko> btw, where does debian policy state that shared libs have to be installed without x permission?
<cjwatson> doko: 8.1
<cjwatson> It's a "should not", and the rationale is because it usually doesn't work; I think it would be reasonable to make exceptions for cases where the library authors have gone to special lengths to make it work (e.g. ld.so)
<doko> cjwatson, ok. that was the thing that did break lto in 4.8
<doko> searching only for files with the x bit set
<cjwatson> you certainly mustn't expect *all* shared libraries to be installed executable - that would be an unreasonable amount of work to change, if nothing else
<sil2100> didrocks: I jump out now for practice, I'll be back later when I'm back - I'll chase down robru then ;)
<cjwatson> if something thinks all shared libraries should be executable then it's just wrong :)
<didrocks> sil2100: ok, thanks!
<cjwatson> didrocks: Any decision on the signon-ui vs. qtwebkit-opensource-src deathmatch?
<seb128> cjwatson, it's being worked, kenvandine opened a MIR bug and jdstrand will comment soon
<didrocks> cjwatson: from what I heard kenvandine and jdstrand agreed on promoting qtwebkit for now
<didrocks> so basically, no revert
<ScottK> This is qtwebkit for Qt5?
<seb128> cjwatson, https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567
<cjwatson> OK, I didn't see the MIR bug on component-mismatches so I guess it's recent
<ubottu> Launchpad bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New]
<cjwatson> ScottK: yeah
<cjwatson> Oh, the MIR team isn't subscribed
<seb128> the MIR is going to be temporary most likely
 * jdstrand will be commenting in the bug soon
<seb128> cjwatson, jdstrand said he wanted to comment and talk the MIR team when he was done with meetings
<cjwatson> kenvandine: You have to subscribe ubuntu-mir to MIR bugs or else they aren't visible in component-mismatches
<cjwatson> FWIW
 * ScottK isn't sure how QtWebKit for Qt5 will work in the long run with needing to support both upstream and Ubuntu APIs in the archive, but that's, at least, not an immediate problem.
<cjwatson> I found it encouraging that the intent expressed in the bug was to have it in sync with Debian
<kenvandine> cjwatson, whoops, was focused on security and forgot that
<kenvandine> cjwatson, that was the plan for the whole qt5 stack
<mardy> tyhicks: ping
<tyhicks> hey mardy
<mardy> tyhicks: hi, I wanted to ask you about the apparmor-dbus stuff
<mardy> (for online accounts)
<tyhicks> sure
<mardy> tyhicks: I see that the apparmor team has a dbus-dev PPA
<tyhicks> yes
<mardy> tyhicks: should I use that?
<tyhicks> mardy: Yeah, you could use it.
<tyhicks> mardy: I had hoped that all of the changes would be in the archive by now, but we've got a few more things to wrap up
<mardy> tyhicks: np
<mardy> tyhicks: what method should I call to check if the peer has certain permissions?
<tyhicks> mardy: I'm trying to remember what exactly you need for online accounts
<mardy> (or to find out the security context of the peer)
<tyhicks> right, I was thinking that you only needed the label of the peer
<mardy> tyhicks: basically, the one which creates the account sets the ACL, and then I have to check against it when someone wants to authenticate
<tyhicks> yeah
<tyhicks> mardy: So you would just call org.freedesktop.DBus.GetConnectionAppArmorSecurityContext
<tyhicks> mardy: it takes a string which is the peer connection name and returns a string which is the label of the process
<zyga> cjwatson: hey
<rbasak> mdeslaur_: aha. Thanks :)
<zyga> cjwatson: I have a question about what ubuntu branches are for, for example, lp:ubuntu/checkbox
<ogra_> they are created from the uploaded source packages
<zyga> ogra_: so we never have to touch them?
<cjwatson> They're supposed to be a uniform representation of source package history in bzr
<zyga> ogra_: or can the reverse also happen?
<cjwatson> You *can* commit to them directly, but if you prefer to manage your package VCS some other incompatible way, you can do so, just don't put it in that namespace
<zyga> cjwatson: okay
<zyga> cjwatson: so as a packager
<cjwatson> For example, you could use lp:checkbox for upstream development and keep that separate
<zyga> cjwatson: I just keep uploading my source packages
<zyga> cjwatson: and everything ends up being added to lp:ubuntu/$package
<zyga> cjwatson: but I don't care about that and it's not helping me in any way, just people that might need to repackage it for example?
<cjwatson> Yeah, I mean, once you go into auto-import lp:ubuntu/checkbox will probably become rather less useful because it won't be mergeable
<cjwatson> But you can just ignore it if it doesn't fit your workflow
<zyga> cjwatson: I wonder how it could help us though
 * ogra_ uses these trees just to pull from usually ... 
<zyga> cjwatson: so I'm trying to understand the concept
<cjwatson> The goal was to make it work for everyone, but there's only limited attention for it at the moment so I think you should not stress about it
<zyga> cjwatson: how do we 'go into auto-import'?
<cjwatson> I certainly have a number of packages where I ignore it
<cjwatson> zyga: Upload something that doesn't match the latest tag on the branch
<zyga> cjwatson: I see
<zyga> cjwatson: (something == source package), right
<cjwatson> That's the only thing you can upload (to the archive)
<zyga> right, just double checking I understand correctly
<mardy> tyhicks: thanks! does it return the same string that would be returned by the aa_getcon() family?
<zyga> cjwatson: if we wanted to use the feature directly, could we stop uploading source packages?
<tyhicks> mardy: yes
<mardy> tyhicks: we have the long-term plan of migrating to a dbus p2p connection, so it may be that at some point we'll switch to getting the context from the fd of the peer
<mardy> tyhicks: great, then there won't be any problems
<tyhicks> mardy: That's where the context is coming from
<tyhicks> mardy: When a DBus connection is made, I do a aa_getpeercon() call on the socket fd and then store that on the DBus connection
<cjwatson> zyga: No
<zyga> cjwatson: ok
<cjwatson> zyga: The project never got that far
<zyga> cjwatson: so I guess that's all I need for now, many thanks, that does clear stuff up for us
<evilissimo> hmm lintian is giving me postrm-does-not-call-updaterc.d-for-init.d-script
<xnox> evilissimo: did you use dh_installinit ?
<evilissimo> yeah
<evilissimo> actually it's automatically used
<evilissimo> debian/packagename.upstart is present
<cjwatson> Known when dh_installinit is running in Ubuntu mode; ignore it
<xnox> ah, ok.
<evilissimo> cjwatson: so I should just ignore this one?
<cjwatson> Yes
<evilissimo> k
<cjwatson> $ lintian openssh-server_6.2p2-4_amd64.deb
<cjwatson> E: openssh-server: postrm-does-not-call-updaterc.d-for-init.d-script etc/init.d/ssh
<cjwatson> ^- you're in reasonable company
<cjwatson> of course check that your package is actually starting the upstart job correctly
<geofft> Perhaps the Ubuntu-patched dh_installinit should also install an override?
<mdeslaur_> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<roadmr> cjwatson: hey, sorry to keep pestering with this. So for checkbox, all I would need is to dput a source package, if that doesn't match a tag in lp:ubuntu then the auto-importer takes over? and I don't have to do or upload anything else?
<roadmr> (just want to triple-check so I don't mess things up)
<psusi> cjwatson: I've sent you an updated bundle for parted including the fix you uploaded the other day, and two more I've added
<cjwatson> roadmr: To repeat: if your VCS layout no longer matches that of lp:ubuntu/checkbox, then just push it somewhere else, forget about lp:ubuntu/checkbox, and upload source packages
<cjwatson> psusi: Thanks, sorry for being slow about this - I'll try to get to it this weekend
<roadmr> cjwatson: ok, gotcha. Thanks so much!
<mterry> Are ddebs enabled for ports.ubuntu.com?
<infinity> mterry: Yes.
<infinity> mterry: ddebs.ubuntu.com hosts all arches.
<mterry> infinity, oh, I looked in the wrong place then, thanks
<mterry> infinity, http://ddebs.ubuntu.com/dists/saucy/main/ seems short
<infinity> mterry: Indeed it does.
<infinity> pitti_: No ports indices on ddebs?  Que pasa?
<infinity> mterry: Most of the right files should be there (other than things pitti purged when he was low on disk space :/ ), but indeed, he doesn't seem to be generating indices...
<nfm> I'm writing a program and I was thinking of licensing it under the WTFPL just because that sort of reflects my style (I'm not trying to be Stallman here). However, in the future if I'm looking for a programming job I'd like to be able to point to it and the rest of my projects as examples. Would having the WTFPL in there be a strike against my "professional image" in the eyes of potential...
<nfm> ...employers or would they not care?
<kees_> infinity: say, back in quantal I had asked you to carry some eglibc patch... but I can't find any record of a bug or anything for it.
<infinity> kees: Was it the patch(es) you uploaded for?
<kees> I'm trying to find it...
<infinity> 2.15-0ubuntu15
<kees> yeah, that's the one
<kees> but that patch is missing now?
<infinity> https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu15
<infinity> Is it?
<kees> Oh! it's in the ubuntu/ directory, not the any/ directory
<kees> did you not want it for debian?
<infinity> I was undecided for Debian while upstream discussions were going on, and probably have never revisited since.
<kees> the "discussion" upstream was "meh, no"
<kees> and didn't take into account any kind of local suid attacks, etc
<kees> infinity: errr... it's back into any/ for saucy?
<infinity> ./debian/patches/ubuntu/submitted-no-stack-backtrace.diff
<infinity> kees: ^-- Looks to be in ubuntu/ to me...
<kees> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/eglibc/saucy/view/head:/debian/patches/any/submitted-no-stack-backtrace.diff
<infinity> kees: That branch is.  Uhm.  A filthy lie.
<kees> hah
<infinity> I should just wipe it out completely.
<infinity> It's probably stuck on precise or something.
<kees> okay, cool.
<slangasek> s/wipe it out completely/get it in sync/
<infinity> slangasek: Tomayto, tomahto.
<tvoss> slangasek, ping
<slangasek> tvoss: hey there
<tvoss> slangasek, hey, how goes?
<slangasek> tvoss: it's a-goin' :)  what's up?
<infinity> slangasek: Something akin to "just wipe it out and get it reimported" would work best for my workflow, which doesn't involve bzr for eglibc, cause that's painful madness when syncing with Debian's SVN.
<tvoss> slangasek, just saying hello :
<tvoss> )
<infinity> slangasek: If it can be in whatever shape required so that the imported just DTRT when I upload, then I can blissfully not care about it.
<slangasek> right, which means an importer fix
<seb128> do we still have anyone caring about import issues?
<seb128> or rather "caring enough to fix those"
<robru> sil2100, hey sorry I'm late, wasn't feeling well this morning. gonna make up the hours tonight.
<tjaalton> slangasek: what do you think, should libpam-pwquality conflict with libpam-cracklib as it provides the same functionality, or should the pam config conflict. having both works, but it asks the confirmation password twice (use_authtok doesn't seem to help)
<tjaalton> having both installed and enabled, that is
<sil2100> robru: hi!
<sil2100> robru: did you fix the webapps stack already?
<slangasek> tjaalton: well, if you make the packages conflict, a user can't use both modules for different services, maybe that's a use case you want to support?  In that case, pam profile conflicts seem reasonable
<tjaalton> slangasek: they only support the password stack
<tjaalton> oh I see
<tjaalton> there's more than common-*
<bdmurray> slangasek: I ran into bug 1142843 when I forgot I was logged into a system over ssh and ran update-manager.  Is there anything to be done in update-manager about this?
<ubottu> bug 1142843 in update-manager (Ubuntu) "update-manager crashed with RuntimeError in __init__(): Gtk couldn't be initialized" [Medium,Confirmed] https://launchpad.net/bugs/1142843
<slangasek> bdmurray: could be fixed to exit with a more friendly message instead of throwing a backtrace, but I'd say that's probably low priority?
<bdmurray> slangasek: yes re low but there is an errors report for it with ~785 duplicates
<slangasek> bdmurray: hmm. in spite of that I guess most of the users encountering it understand afterwards what they did... but, well, maybe it's quicker to fix than argue the priority, by adding a suitable try/except?
<tjaalton> slangasek: could pam-auth-update grow to support enabling configs that are not enabled by default? like injecting the to-be-enabled config to libpam-runtime/profiles. that would allow having a non-default config for pam_mkhomedir easily enabled
<tjaalton> and more
<slangasek> tjaalton: I would gladly consider patches, but I don't see having time to write this myself anytime soon
<tjaalton> slangasek: sure, I'll file a bug so I won't forget :)
<robru> sil2100, yes, webapps stack is in excellent shape.
<robru> sil2100, just gonna fix up that webbrowser-app thing about the assets today.
<sil2100> robru: did you publish it?
<sil2100> robru: thanks :)
<robru> sil2100, no, I don't think I'm set up for that. need you/didrocks to publish still.
<sil2100> robru: let me check that
<robru> I hate CMake.
#ubuntu-devel 2013-06-20
<zul> can someone de binary new python3-wsme please?
<psusi> bloody hell, cdparanoia is complicated and poorly documented
<m4n1sh> ev: when you are free please have a look at LP # 1192777
<m4n1sh> I have sent you a mail with more details
<pitti_> Good morning
<pitti> infinity: eek! added now, but I'm afraid it'll only start collecting them from now on
<pitti> or rather, from a month ago on
<infinity> pitti: Oh, was it actually not collecting either?  I thought I saw ports stuff in pool, but maybe I was seeing things from previous releases, I didn't look too closely at versions. :/
<pitti> infinity: collecting yes, but they time out after 30 days
<infinity> If not referenced.  Right.  Ugh.
<pitti> as there hasn't been any index to refer to them
<infinity> I wonder just how much of the archive will be rebuilt by 14.04.  Probably all of main, at least.
<infinity> I'd really like our ports dbgsym story to be mostly fixed by then.
<pitti> infinity: indeed; what's the current status of that, OOI?
<infinity> pitti: Which "that"?
<pitti> "that" == ddebs in librarian
<infinity> Hah.
<infinity> We're pretty much ready to roll, just need to be sure the SAN won't explode.  Which I think it might, from last I heard.
<infinity> pitti: But from our (soyuz) side, we're ready to flip the switch as soon as we have a green light.
<infinity> pitti: It should already be working on dogfood (and maybe staging; wgrant?), so you can prototype new and improved ddeb-retriever behaviour, perhaps.
<wgrant> Yeah, librarian disk space is the issue now
<wgrant> It might be a while until that's resolved
<wgrant> We're sorta bursting at the seams atm
<infinity> wgrant: Does dogfood actually have some ddebs published in the primary archive somewhere, so pitti can play with what that looks like?
<didrocks> infinity: hey, is there any code to detect some potential arch publication mismatch causing FTBFS and retrying for us?
<wgrant> It's enabled on the DF primary archive, and can be on the stagings, but staging has no Soyuz
<didrocks> infinity: since I enabled -proposed in the daily releases, we keep getting failures due to that
<wgrant> I think DF's primary archive should still have some ddebs
<wgrant> Whether you can actually get them out of it without timeouts is another question entirely.
<infinity> didrocks: As in, arch all/any skew causing build-dep failures?
<infinity> didrocks: If there was code that detected that, it would be awfully mean of me to not let your PPA use it, right? :)
<didrocks> infinity: exactly (libgtk3-dev this night for instance)
<didrocks> infinity: heh, that's my guess, but it can be as well hackish code that you won't want launchpad to have :p
<infinity> (I actually had something in the works to turn those into proper dep-waits, cause that's what they should be, but never finished it up)
<didrocks> agreed, they should be treated as dep-waits
<infinity> Anyhow, your best option right now is just to retry.
<didrocks> I guess the case to reliably detect that is not that easy :)
<infinity> didrocks: Well, the thing is you need to drill down to find out WHAT to dep-wait ON.
<didrocks> infinity: yeah, it's failing all my stacks though, so monkey work in the morning to relaunch everything
 * didrocks wonders if he shouldn't turn proposed off, and only turn on when we have a desired transition
<didrocks> for the time being
<infinity> didrocks: Which isn't too terribly hard, wouter wrote a resolver-reduction algorithm that drills down to first causes of apt failures, but I never got around to tying it into sbuild.
<didrocks> (and have otto supporting turning otto on and off on demand)
<infinity> didrocks: It shouldn't fail everything all that often... If skew was that huge a problem, the whole archive would be FTBFS constantly.
<infinity> didrocks: Perhaps you just turned this on at a particularly tumultuous time.
<didrocks> infinity: yeah, maybe we are just unlucky since we turned in -proposedâ¦ but for the past 3 days, it's not fun, I can tell you :)
<infinity> Anyhow, your call.  The arch skew dep-wait bug has been on my TODO for something like six years, so I imagine I won't be fixing it tomorrow.
<infinity> Maybe I'll put it on the project hacking agenda for our release engineering sprint.
<didrocks> infinity: yeah, I'll give it a chance for still some days and see if it's better to turn on and off (but I need to ack the testing to ensure we can have it on and off conditionnally)
<didrocks> infinity: that would be great! But I'll try to base my decision as if this doesn't exist :)
<dholbach> good morning
<xnox> infinity: if that's your wish i can do full-wipe-resync for lp:ubuntu/*/eglibc branches.
<xnox> bdmurray: if gtk fails to initialise and we have a terminal, do-release-upgrade interface should be invoked instead?!
<jibel> cjwatson, r202 fixes virtual packages and rdeps checking when a request file is specified.
<jibel> cjwatson, I need to improve virtual package support and not expand it to the list of providing packages when a direct dependency also provides this virtual package.
<jibel> otherwise results are sometimes odd, for example sbuild test is triggered when citadel is uploaded because it provides mail-transport-agent
<ev> manish: yeah, that's not intended to work yet. It should be greyed out though. I'll fix that much :)
<seb128> cjwatson, didrocks: so, jdstrand gave a security team +1 to qtwebkit-opensource-src as a temporary solution until we have our own bindings
<seb128> (https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/1)
<ubottu> Launchpad bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New]
<didrocks> yeah, saw that, nice! ;)
<seb128> but we probably need MIR review still before promoting
<didrocks> I remember to have cleanswap/reviewed the package before NEWing
<didrocks> so it's good to me, but as I participated to it, not sure of the conflict of interests I'm usually trying to avoid
<didrocks> but not sure as well we should wait for mterry to be up
<seb128> who else can help here? doko?
<didrocks> yeah, I guess
<doko> how?
<seb128> doko, can you help reviewing bug #1192567
<ubottu> bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New] https://launchpad.net/bugs/1192567
<seb128> doko, that's currently blocking saucy CD builds since the qt5 version of signon-ui made it to the archive
<seb128> doko, we don't want to revert because it would be non trivial and would break touch images (qt4 doesn't work on there)
<doko> ok, will look at it today
<seb128> doko, thanks
<seb128> doko, didrocks did a first review at upload time and was ok with them, but since he's one of those who worked on the package and got it uploaded he said he would prefer having a second review (to avoid acking his own package)
<henrix> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: henrix
<cjwatson> didrocks: For something outside Launchpad, perhaps edos-distcheck would do the job for you
<cjwatson> jibel: Deployed r202, thanks!  Yeah, I can see that glitch being confusing but it isn't too horrible
<m4n1sh> ev: I have been working on https://bugs.launchpad.net/activity-log-manager/+bug/1192778 but all I am getting is segfaults, since you know your way around the code, can you have a look at it too
<ubottu> Launchpad bug 1192778 in Activity Log Manager "Diagnostics tab doesn't show in standalone mode" [Medium,Confirmed]
<ev> sure, I'll have a look today
<m4n1sh> thanks a lot
<pitti> jibel: wrt. the current nova adt failure, do we actually mail these notifications to the actual uploaders?
<pitti> jibel: (I don't think we do)
<jibel> pitti, I made the modification but it is not deployed.
<jibel> pitti, now it is
<pitti> jibel: ah, thanks
 * pitti bounces the notification to zul then
<cjwatson> Riddell,ScottK: Is anyone working on the way that plasma-widget-networkmanagement Breaks the version of kde-workspace-data currently in saucy?  It looks like it's been making all your images unbuildable for a few days.
<cjwatson> Urgh, gtk+3.0/3.8.2-0ubuntu5/armhf isn't happy, is it
<cjwatson> Threading tests or something?
<Riddell> cjwatson: no don't think I've seen that, I'll take a look in a bit
<cjwatson> Riddell: ta
<cjwatson> Riddell: I thought you were auto-mailed on image build failures - is that not working?
<seb128> cjwatson, I'm doing a build on a porter box to try figuring the gtk issue out
<cjwatson> (That isn't meant as a passive-aggressive "why aren't you reading your build failure mail" thing, btw)
<Riddell> cjwatson: yesterday's e-mail only says  kubuntu/dvd: precise-dvd-amd64.iso oversized by 2436018176 bytes (3509760000)
<cjwatson> Riddell: Not the health checks
<cjwatson> 15187   T Jun 20 CD Image               LiveFS kubuntu/saucy/amd64 failed to build on 20130620
<xnox> cjwatson: gtk+3.0 still building only started 40 minutes ago... so another 2h to go or so.
<cjwatson> xnox: this time round, yes; it's been tried several times
<cjwatson> seb128: *nod*
<xnox> ah
<xnox> i see....
<seb128> cjwatson, it seems to be tests failing on "Cannot animate property 'background-image'"
<Riddell> cjwatson: I don't think I get any other e-mail about the images
<seb128> cjwatson, xnox: well, maybe there is a real problem, but we had flacky test issues before so I retried a build while debugging, in case that make it work this time
<cjwatson> Riddell: /msged you the relevant headers.  Mail filter problems maybe?  It should be using the same address for both health checks and image build failures
<yofel> cjwatson: plasma-widget-networkmanagement needs kde-workspace >= 4.10.80, that will be uploaded in the next days (today or tomorrow I guess)
 * yofel thought that britney would've held that back...
<cjwatson> proposed-migration doesn't check arbitrary combinations of coinstallability
<cjwatson> In this case plasma-widget-networkmanagement doesn't depend on kde-workspace-data so there's nothing to cause it to enforce them to be coinstallable
<yofel> ah ok, I guess that makes sense then as it doesn't really need kde-workspace
<yofel> ok, thanks
<cjwatson> If in doubt you can feel free to ask the release team for preemptive blocks (though too late now for this one)
<lifeless> win 67
<seb128> hum, I can't reproduce the gtk test issue on porter-armhf :/
<vipzrx>  http://paste.ubuntu.com/5783426/ the tftp error log
<vipzrx>  who can help me ?
<free> pitti: so perhaps part of the questions are not strictly SRU-related. One question is if we should keep branching lp:ubuntu/<release>/<source> when preparing a new SRU (or any upload in fact). Afair the idea was that one would then merge back into lp:ubuntu/<release>/<source>, and upload would be automatically triggered. Not sure if this is accurate, or the plan has been dropped. Thoughts?
<free> cjwatson: ^^^ you might know too
<pitti> free: there are no automatic uploads
<pitti> free: if you have an existing lp:ubuntu/release-updates/pkg branch, you are welcome to use it for MPs
<dobey> free: generally speaking, you should pull from lp:ubuntu/<release>-proposed/<source> or lp:ubuntu/<release>-updates/<source>, and lp:ubuntu/<release>/<source> as a last case, for doing an SRU.
<pitti> free: if you are doing the first SRU for a package, then the -proposed/-updates branch doesn't exist yet, and you better don't push it to LP and leave it to the auto-importer
<dobey> and uploads go into <release>-proposed first, and for stable releases, lp:ubuntu/<release>/<source> will basically never change again
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: henrix, Laney
<free> pitti: is there any preference re LP branches vs. debdiffs? (as details in the SRU bug) to me branches are superior to debdiffs, but not sure if there's some recommendation
<pitti> free: most sponsors get along with both these days; personally I prefer debdiffs, but you shouldn't worry too much about that
<free> pitti: okay, I guess they have both pros and cons. Now, one last question..
<pitti> free: also, if you run into a package which has an outdated UDD branch (in my last sponsoring shift this applied to about a third of the packages I've touched), you better use apt-get source and debediffs
<free> pitti: oh
<free> pitti: that's unfortunate
<pitti> but "bzr branch ubuntu:foo" will tell you
<pitti> CURRENT vs OBSOLETE
<pitti> or "OUTDATED", I think
<free> pitti: has the number of out-of-date UUD branches increased in recent time? if so, it almost feel folks do not care about this workflow/feature anymore? Asking just to understand the situation here
<pitti> free: could be; I don't think there's anyone actively working on them
<free> pitti: I see
<pitti> free: but as I said, as long as the UDD branch works, feel free to use it
<free> pitti: yeah, apparently they've been broken for landscape-client, but still looking at it
<free> pitti: the last thing is about bugs, https://wiki.ubuntu.com/StableReleaseUpdates#Fixing_several_bugs_in_one_upload recommends to avoid "Please SRU this"-type of bugs. But in case of landscape-client (which has an SRU exception that allows to add new features) I think it actually makes sense to have a "meta" bug. We've been doing that since ever, e.g. https://bugs.launchpad.net/landscape-client/+bug/1004678. Are we good in keeping doing
<free> that?
<ubottu> Launchpad bug 1004678 in Landscape Client "Please update landscape-client to 12.05" [High,Fix released]
<pitti> free: unless you don't want to use an actual bug report, I think it's still ok (but that's more a question for the current SRU team)
<didrocks> cjwatson: edos-distcheck is maybe the solution, right! It's a little bit convoluted to need that to detect the FTBFS in the ppa for that component is due to archive skew and it should just relaunch later on (with a timeout), but that can work. Just not as easy to integrate when we have multiple releases and so on :)
 * didrocks just did some trials locally
<free> pitti: thanks
<cjwatson> free: I rarely find it worth bothering with branches for SRUs since there are too many weirdnesses (e.g. if there's been no upload to -proposed yet)
<free> cjwatson: I see, then we probably want to update our procedure to use debdiffs
<cjwatson> didrocks: or you could scan the PPA build log for "The following packages have unmet dependencies:" and flag those for "somebody needs to work out what the dep-wait here is"
<cjwatson> Debian's archive/buildd system is better at this :-/
<free> cjwatson: any take on the "Please SRU this"-type of bug for landscape-client? (see just above)
<didrocks> cjwatson: yeah, I think that's a viable option, knowing that the other case will be dep-wait (like no Qt5 on powerpc), so will do that scanning, and maybe can retry after an hour, after 2 retrials, will abort.
<cjwatson> free: it's not too unreasonable if there's something complex about the SRU itself, indeed
<free> cjwatson: typically we address many bugs in every SRU, since we're introducing new features
<henrix> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: Laney
<free> cjwatson: kind of unrelated, but in light of these discussion is it fair to conclude that the Ubuntu Distributed Development project is kind of paused/abandoned?
<cjwatson> free: maintenance mode
<free> cjwatson: I see, thanks
<cjwatson> free: there are some people responding to issues but it's not being actively development
<cjwatson> *developed
 * Laney pokes bdmurray about bug #1142947 at the top of the queue ;-)
<ubottu> bug 1142947 in webkit (Ubuntu Raring) "webkit--epiphany-browser crashed with SIGSEGV in Decoder()" [High,Triaged] https://launchpad.net/bugs/1142947
<smoser> does anyone *not* see this bug on saucy
<smoser> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1191951
<ubottu> Launchpad bug 1191951 in unity (Ubuntu) "clicking on entry in 'Run a command' (alt-f2) menu shows "No image available"" [Undecided,New]
<smoser> to test, just hit 'alt-f2' and try to launch something by clicking
<sil2100> Damn this heat, I need a fan!
<pitti> didrocks: the CI test failure in https://code.launchpad.net/~pitti/autopilot-gtk/testsuite/+merge/170607 gave me an invalid rebuild link; what's the real URL?
<pitti> didrocks: ("http://s-jenkins:8080")
<pitti> didrocks: or will it re-try automatically after my followup commit?
<didrocks> pitti: I think that's more a question for mmrazik, they make you configuring the "s-jenkins" host in /etc/hosts AFAIK
<didrocks> pitti: yes
<pitti> ah, good; so I just need to wait?
<didrocks> if you pushed something else, it will be retriggered
<mmrazik> pitti: yes. you just need to wait
<mmrazik> pitti: re s-jenkins -- I checked with IS and they don't want us to unnecessarily publish our private IPs
<mmrazik> (even though they most likely leaked here couple of times)
<mmrazik> so yes, we modified our /etc/hosts
<cousteau> any reason for latex2rtf to be incredibly outdated?
<pitti> mmrazik: ah, so perhaps this shouldn't say "click here", but "tests will be retried on new commits"?
<cousteau> (other than it being ported from Debian)
<cousteau> (...I guess I should just ask debian)
<mmrazik> pitti: the "click here" is mostly there is there is some jenkins/launchpad/bzr hiccup and you want to re-trigger the build without adding a new revision
<Laney> but most people don't even have permissions to do that
<mmrazik> pitti: but yes. Let me add a note that if you push a new revision a new build will be performed
<cjwatson> cousteau: saucy is up to date with upstream
<pitti> mmrazik: thanks
<cjwatson> cousteau: it was updated in Debian (and hence in saucy) by way of non-maintainer uploads, suggesting that the maintainer isn't terribly active
<cousteau> well, the progression I saw was   lucid: 1.9.19 precise 1.9
<cjwatson> https://launchpad.net/ubuntu/+source/latex2rtf
<cjwatson> http://packages.qa.debian.org/l/latex2rtf.html
<cjwatson> I think raring was behind because nobody noticed the pending merge
<cousteau> .1.9.19   quantal 1.9.19   raring 1.9.19   so I assumed s* wouldn't reach 2.3.3
<cjwatson> oh, actually because 2.3.1/2.3.3 initially went to experimental due to the Debian freeze
<cjwatson> anyway, saucy's up to date now
<cousteau> would it be possible to request a backport?
<cousteau> (I installed it from source, it was easy to compile; but maybe such an old software should be avoided)
<cjwatson> cousteau: I'm not on the backports team, but I guess so ...
<cjwatson> cousteau: https://wiki.ubuntu.com/UbuntuBackports
<ScottK> cjwatson: I get the emails about the failed images.  I just haven't had time to look into it the last few days.
<pitti> mmrazik, didrocks: indeed, passed now \o/
<didrocks> pitti: sweet! Time for ice-cream then? :)
<pitti> didrocks: my wife should get home in 30 minutes; then, for sure!
<cjwatson> Oh, hey, it's Debian import freeze today isn't it
<cjwatson> I'll turn off auto-sync tonight
<Laney> huh, that crept up
<cjwatson> Didn't it just
<cjwatson> Unnecessarily early nowadays in my opinion, but
<mmrazik> pitti: is this better?
<mmrazik> https://code.launchpad.net/~mrazik/jenkins-launchpad-plugin/rebuild-note/+merge/170632
<pitti> mmrazik: thanks!
<pitti> hm, that's the second autopkgtest that fails to install its dependencies in -proposed in two hours
<pitti> perhaps the pending gtk
<seb128> pitti, I disabled tests for gtk on armhf, it just finished to build
<seb128> does anyone know if there is a way to downgrade packages on porter's chroots?
<pitti> that shouldn't affect i386/amd64 installability in -proposed, though
<seb128> pitti, it does
<seb128> oh, no
<seb128> not those arch, only armhf
<pitti> anyway, I'll retry them in a couple of hours
<seb128> hate gtk
<pitti> quotes page :)
<seb128> I can reproduce the test issue on a porter box
<seb128> it doesn't like the css it gets from a gresource
<cjwatson> I think you have to ask IS for downgrades
<seb128> but extracting that same css with the gresource shows it's not corrupted
<pitti> seb128: try it on the n7?
<seb128> pitti, I guess I'm good to do that, I was trying to avoid messing up my touch image
<seb128> gtk didn't change
<seb128> glib didn't change
<seb128> what changed is gcc and binutils
<seb128> so I wonder if that's a toolchain issue
<pitti> heh, mess up even more? I got a daily build from Friday, that has a black screen
<seb128> pitti, mine has a week old working image I use to test system settings
<seb128> so I'm trying to keep it working until daily is back to be working
<seb128> otherwise if I screw it I'm without a test device
<seb128> oh well, let's see
<ogra_> pitti, brave people use flipped :P
<Laney> you should still be able to install sbuild
<Laney> without risking the rest of the system
<seb128> yeah, let me try
<cjwatson> does it have overlayfs now?
<Laney> nope
<cjwatson> aufs?
<xnox> nexus7 sure did have overlayfs for a while now.....
<Laney> oh, maybe it was aufs it didn't have
<Laney> whatever mk-sbuild sets it up to use by default
 * xnox needs to reflash to check in a second.
 * Laney is still using the trusty panda
<seb128> I gave my panda to chrisccoulson
<seb128> I should get him to debug gtk for me :p
<xnox> seb128: i'm not sure how the two correlate, surely he will simply give the panda back to you :P
<seb128> xnox, that's not worth the trip to France :p
<ogra_> cjwatson, no, and it wont get it (per discussion)
<xnox> chrisccoulson: FYI, i can always take a quick eurostar trip to knock on seb128 door with a pandaboard
<bdmurray> xnox: what about do-release-upgrade?
<xnox> bdmurray: i might be wrong, was the fails to initialise gtk bug in update or upgrade manager?
<ogra_> xnox, nexus7 only has overlayfs on the desktop kernel, which is bitrotting in universe
<xnox> ogra_: *sigh*
<bdmurray> xnox: update-manager is the command I ran
<ogra_> and there are no pans to add any union fs capabilities to the touch kernels
<xnox> ogra_: so which kernel are we using on touch/phablet images then?
<ogra_> *plans
<ogra_> xnox, linux-grouper
<ogra_> (desktop is linux-nexus7)
<xnox> bdmurray: ah, then ignore me. executing do-release-upgrade over ssh is no replacement for update-manager.
<slangasek> ogra_: bitrotting in universe> ah, let me see about correcting that then
<Quintasan> Why is the systemd package kind of useless?
<slangasek> ogra_: we're no longer building the n7 desktop images, right?
 * Quintasan can't find /lib/systemd/systemd binary anywhere
<slangasek> Quintasan: Ubuntu does not support systemd as init.
<xnox> slangasek: not since 2nd of May.
<Quintasan> slangasek: Is that a proper reason for crippling the package?
<slangasek> xnox: righty-o
<slangasek> Quintasan: yes
<ogra_> slangasek, community people do though ... as long as it does no harm i thought we can just keep it around
 * Quintasan grabs Debian package then
<slangasek> since the alternative to "crippling the package" is "having users make their machines unbootable"
<slangasek> ogra_: community people do what?
<xnox> Quintasan: only certain parts of the systemd package were carefully prepared and integrated, e.g. logind. and not _all_ of it.
<Quintasan> slangasek: That actually kind of implies that everyone will install it when it's in the repositories even if you tell them not to
<ogra_> slangasek, roll home brewed nexus7 images
<ogra_> using that kernel package
<slangasek> ogra_: you specifically said "bitrot"; we have a sunsetting policy on no-longer-maintained kernels in the archive to avoid precisely this
<slangasek> so unless someone else in the community is taking ownership of the package, it should go away
<slangasek> Quintasan: no, not everyone, just a non-zero number of them who will then be upset with us
<ogra_> slangasek, well, then be it  ... we'll see who screams ... i think shadeslayer was building plasma-active images with ti though
<Quintasan> slangasek: And now you have non-zero number of people who are upset because they can't break their system if they really want to :P
<ogra_> *it
<shadeslayer> ogra_: the issue is not the image
<shadeslayer> but things like X11
<slangasek> ogra_: maybe shadeslayer would be happier with the -grouper kernel anyway?
<shadeslayer> which I'll try and work on next week
<ogra_> slangasek, nope, you wont like that kernel with a desktop install and without any android userspace (and all the hacked in groups and GIDs in the rootfs etc)
<slangasek> well, ok
<slangasek> shadeslayer: so, linux-nexus7 is not maintained by the kernel team - do you want it? :)
<xnox> Quintasan: logind is in the default installs of most desktopy variants in saucy and is part of standard task. So at the moment, the number of people who want to continue be able to boot their machines is far larger than people who experiment with systemd.
<xnox> Quintasan: *systemd-init that is.
<shadeslayer> slangasek: probably
<shadeslayer> slangasek: but I'm no kernel dev
<Quintasan> xnox: That kind of makes me wonder why are we still using upstart
<slangasek> Quintasan: because upstart does its job, in spite of systemd upstream's attempts to embrace and extend init
<shadeslayer> slangasek: feel free to drop it from the archive though, but would be nice to have the git repo still up so that I have something to stand upon
<xnox> Quintasan: i don't understand why logind was ever added to "systemd collection of daemons", since well most of them have nothing to do with "systemd init" daemon.
<slangasek> xnox: "embrace and extend" :)
<slangasek> ogasawara, apw: ^^ hi, do you have any opinion on the above discussion wrt keeping the linux-nexus7 git tree around for community use?
<Quintasan> You had to carefully prepare and integrate parts of systemd into upstart booting process where apparently upstart does it's job?
 * Quintasan kind of does not follow that
<Quintasan> Is logind kind of mandatory with newer kernels or something?
<apw> slangasek, desktop is not using -mako, but using -nexus7 still?  why ?
<slangasek> apw: see ogra for $reasons :)
<xnox> apw: desktop does not exist in saucy, though. so raring, yes still is same since release.
<slangasek> apw: (grouper not mako, fwiw)
<apw> slangasek, point indeed
<ogra_> apw, there are community people that do home brewed images using this kernel ...
<apw> ogra_, well we won't be changing it ... ever i shouldn't think
<ogra_> but i'm not sure thats a reason to keep it .. i mean they can use the raring one
<apw> linux-nexus7 probabally is the raring one, and has nothing for saucy in it
<ogra_> right
<xnox> Quintasan: gnome project decided to mandatory depend on logind instead of consolekit, among with a few other projects.
<apw> really that should move to a nexus7 branch in the raring repo to be consistant
<apw> though we have no intent to like update it or anything
<xnox> Quintasan: which is unrelated to systemd-the-init.
<ogra_> dont we have a raring branch for it already ?
<ogra_> the one it was built from
<ogra_> just freeze that
<Quintasan> xnox: So what's the exact problem of shipping systemd binaries and saying "Don't install, if you do - no support" and let people toy around?
<apw> ogra_, yeah it is already in the raring repo as 'grouper' like in saucy, so i think there is nothing in the linux-nexus7 which is worth keeping; it is duplicative
<slangasek> Quintasan: what's the problem with people who want to shoot themselves in the foot having to do so from source? :)
<slangasek> "carefully prepare and integrate" - you make this sound like an ordeal.  Integrating logind with upstart was not particularly difficult
<apw> ogra_, and the same applied to linux-nexus4
<Quintasan> slangasek: I'd rather use Ubuntu than Gentoo if you know what I mean
<apw> slangasek, i think linnux-nexus7 and nexus4 are both redundant copies of the branchs in raring
<slangasek> Quintasan: no, you'd rather use systemd, and Ubuntu does not support systemd
<slangasek> apw: right, probably true
<shadeslayer> slangasek: btw did anyone experiement with X11 + Nexus 10 like they did with the Nexus 7?
<ogra_> apw, wait, raring grouper is not the same as nexus7
<Quintasan> slangasek: Neither does Debian I believe and they didn't cripple the package.
<xnox> slangasek: integrating logind across the rest of packages was more work =) but yeah, just uploading logind was not particularly difficult.
<ogra_> apw, i think -nexus7 could evan be from quantal
<apw> ogra_, are you sure ?
<xnox> Quintasan: debian's systemd is not as up to date as ubuntu one though.
<ogra_> apw, -nexus7 has definitely all android bits disabled and carries some ubuntu patches
<ogra_> along with a config thats synced up with panda
<apw> Ubuntu-3.1.10-10.28 and Ubuntu-3.1.10-10.28
<mdeslaur> Quintasan: is there a specific reason you want to use systemd?
<ogra_> they are from the same base
<apw> ogra_, linux-nexus7/master and raring/grouper have the exact same version number
<ogra_> but i think -nexus7 had overlayfs, it definitely has all android bits disabled
<apw> ogra_, and the exact same sha1
<Quintasan> mdeslaur: I have a device which boots off a kernel that has this in init and I'd rather not tamper with that. But that's not my point here
<ogra_> apw, hmm, then we lost the original n7 tree
<ogra_> apw, the binaries are massively different
<mdeslaur> Quintasan: ok, sounds like a very specific use case
<ogra_> and you wont be able to run a desktop on the grouper kernel
<apw> which version are you comparing with
<ogra_> the linux-nexus7 package
<apw> ogra_, right and you are coping that forward from quantal right?  we don't build it
<ogra_> it is a desktop kernel
<ogra_> well, it got copied forward, i didnt do anything :)
<apw> linux-nexus7 | 3.1.10-10.28 | raring/universe | source
<ogra_> right
<apw> the _only_ version of linux-nexus7 in the archive is that one, and that has the tag on that raring branch
<apw> so that really is the one
<ogra_> ok
<apw> i am sure we dropped the config when we move to saucy repos
<ogra_> i remember we had it in a PPA for a few months before ... might be that this is what i remember
<apw> you may have been pulling those into raring images of course, but they are saucy kernels
<ogra_> oh, if it doesnt have the desktop config it is useless
<slangasek> shadeslayer: not that I'm aware of, the N10 hardware has been less prevalent within the team
<shadeslayer> oh :(
<apw> ogra_, i am saying i think this raring one is the desktop one, the one you had in raring on the touch images was the saucy source codebase built in android land
<apw> and we have been keeping that in our saucy repo, not raring
<ogra_> what we had in saucy images was always called -grouper
<apw> ogra_, right but what about all those raring-* images we had until like this week
<apw> ogra_, those were raring yes?  but using the -grouper kernel, which is saucy regardless of the prefix
<ogra_> apw, not sure what kernel they used, it might have even come from the android tree
<apw> so we stoped using the raring/grouper branch long before you moved to saucy- base for your system
<apw> ogra_, then if it iwasn't in our tree we don't have it, but the raring/grouper is the linux-nexus7 source regardless of the name
<ogra_> ok
<jibel> several autopkgtest failed because python3-pykde4 is not installable. The version of the sip api in pykde4 must be bumped from sip-py3api-9.2 to sip-py3api-10.0 I guess.
<xnox> jibel: known issue, rebuilds are in progress to migrate sip4.
<xnox> jibel: transition is happening in -proposed and eventually they should all be able to run.
<jibel> xnox, ok, thanks
<roadmr> cjwatson: hello! I uploaded the checkbox 0.16.2 source package yesterday, it made it into the archive, we were expecting lp:ubuntu/checkbox to show some change but there's been none. Maybe we misunderstood something about the auto-importer?
<xnox> roadmr: failed, due to tags missmatch: http://package-import.ubuntu.com/status/checkbox.html#2013-05-15 21:45:35.640192
<roadmr> xnox: oh great, let's see
<xnox> roadmr: would like to wipe & replace lp:ubuntu/checkbox afresh. Or keep it forever out-of-date in current state?
<ScottK> jibel: I'll be upload a pykde4 rebuild in ~an hour to fix that.
<roadmr> xnox: I think we'd be OK with replacing it altogether. Better than keeping the old out-of-date branch there for all eternity..
<jibel> ScottK, np, we deployed a new interface between britney and autopkgtest this week, and wanted to make sure the problem was not on this side. Thanks!
<doko> Daviey, jamespage: seeing "The information on this page is private." on https://launchpad.net/builders is still not nice. can you avoid that kind of copying?
<jamespage> doko, ah - yeah - sorry
<jamespage> I've not got to that yet
<roadmr> xnox: is that something I can do somehow?
<cjwatson> doko: we should really just fix that LP bug rather than regarding it as the uploader's problem
<doko> mehh, yes ...
<zyga> roadmr, xnox: I'm eagerly interested in how that importer works
<xnox> zyga: an instance of lp:udd is running that tries to work out package ancestry and correct bzr import-dsc them in the right order and right history.
<cjwatson> doko: (it's probably bug 760303, although if you know of a different condition that triggers it, do mention it ... fancy some LP hacking?)
<ubottu> bug 760303 in Launchpad itself "builders page inaccessible if a private recipe build is building" [High,Triaged] https://launchpad.net/bugs/760303
<xnox> zyga: if it's view of the world doesn't match the reality based on the archive and lp:ubuntu/* and lp:debian/* branches it throws an exception.
<doko> I was trying to avoid that ...
<xnox> roadmr: nah, needs access to that instance.
<cjwatson> doko: Though I'm curious, you said "copying" and that doesn't seem to match the "private recipe build" condition in that bug?
<xnox> and launchpad.net/builders is back.
<doko> cjwatson, jamespage: I think that was another issue, but there should be an open issue for that as well
<Daviey> doko: How long was it blocked for?
<doko> Daviey, I'm not looking at it every hour, just need to check if buildds get stuck during the test rebuild
<Daviey> doko: I'm thinking, that if it was only blocked for the copy action.. which is a few mins.. it doesn't seem that much of a problem?
<doko> like that geant build on aaxte
<cjwatson> doko: Which specific operation of jamespage/Daviey's were you referring to?
<jamespage> cjwatson, two ops I think
<cjwatson> It sounds like you know which one it was and I'd like to know
<jamespage> 1) source package copy from public ppa to private ppa
<maxiaojun> http://www.omgubuntu.co.uk/2013/06/minor-updates-arrive-in-libreoffice-4-0-4-release
<jamespage> 2) binary copy from private -> private
<doko> binary copy wouldn't take that long
<cjwatson> binary copy doesn't trigger builds so I doubt that could have rendered /builders 403
<maxiaojun> still don't understand why ubuntu cannot always have latest minor releases of libreoffice
<jamespage> OK - so its just 1) then
<cjwatson> /builders has no interest in the act of copying as such
<cjwatson> jamespage: by "source package copy", do you mean with include_binaries=False?
<cjwatson> jamespage: Actually if you could tell me the source package name I can look it up in the logs
<jamespage> cjwatson, swift in this case
<jamespage> cjwatson, for reference we use copy-package from archive-tools - without --include-binaries for 1)
<Daviey> (because the private PPA must build on bare metal, but the public one doesn't need to be)
<cjwatson> I'll see if I can write a test case that exposes it, because it annoys me that we have to spend any time thinking about this
<cjwatson> Should finish my current copier extension first though
<Daviey> that sounds super cjwatson
<jamespage> cjwatson, we have a whole load more to copy over....
<cjwatson> jamespage: I'm certainly not going to be done before you want to proceed, and I don't think you should block on this
<cjwatson> It's hardly a new problem
<jamespage> okay
<ev> manish: apologies, I haven't had any time to look at those today. I got caught up in an critical operations issue. I should have more time tomorrow though.
<infinity> xnox: Please do, that would be lovely.
<xnox> infinity: context - blow away lp:ubuntu/eglibc and reimport?!
<GunnarHj> Laney: Hi, I see that you are piloting. Any chance that you can merge https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214 before your shift ends?
<Laney> GunnarHj: I already pinged about that one
<slangasek> xnox: why would a full-wipe be needed?
<Laney> I expect cyphermox will approve once all the requested reviews come in
<GunnarHj> Laney: There are two approvals now.
<Laney> Usually if you request multiple reviews it's because you want them all
<Laney> GunnarHj: So if you don't care then maybe ask cyphermox to approve it now
<Laney> I don't have such permissions ...
<GunnarHj> Laney: Well, Charles seems not to have been around for quite a while.
<GunnarHj> Laney: Aha, right, it's upstream ... Will ask cyphermox.
<xnox> slangasek: ..... or sql database surgery to match up tags & revision-ids, as per all branches you've force pushed =)
<xnox> slangasek: do you want a dump of that db of there btw?
<slangasek> xnox: yes, half of those weren't even force-pushed, the importer has somewhere along the way started lying
<infinity> xnox: That was the context, yes. :)
<charles> GunnarHj: the issue is, the gmenuification of i-datetime just landed
<slangasek> xnox: it's not "force-pushed", it's "pushed at all" from what I see lately
<charles> GunnarHj: I'm not sure this patch is going to go in it cleanly, reading it onw
<charles> *now
<slangasek> xnox: anyway, yes, I would like to get this fixed on the importer side so that it respects my authoritah
<charles> GunnarHj: hmmm
<xnox> slangasek: i wonder if there is command to shoot udd in the head and foget about package tags, instead of shooting the branches in the head.
<slangasek> xnox: I don't know, but I would like there to be one :)
<slangasek> xnox: actually, I would like it to be automatic if the contents match :P
<xnox> slangasek: given how non-matching content of your branches at times is......
<slangasek> xnox: erm?
<xnox> upstart upstream .orig tarball  & some .gmo files =)
<slangasek> xnox: if you're talking about upstart, that's because I was trying to clean up after a prior mangling
<slangasek> a unique case
<charles> GunnarHj: so, the actual conversion of datetime fmt strings -- ie, the call to g_date_time_format()
<charles> GunnarHj: for the header, and for the first menuitem, it's still done in the datetime service
<charles> GunnarHj: but for locations and appointments, it's now done in IDO in its location and appointment menuitems
<charles> and even then, ido is just for the gtk+ frontend
<charles> since we've de-gtk+-ified indicator-datetime, we now ship out menus that have custom logic like strftime format strings
<charles> instead of the actual date
<charles> so that the other side can update the menuitems on their own, and we don't have to ship out new timestamps every second or every minute
<charles> unfortunately that makes a little more work for this patch; you'll need to split it into ido and the gmenuified datetime
<GunnarHj> charles: Hi Charles, was just getting some coffee...
<charles> GunnarHj: that said, I'm neutral-to-positive on the feature itself and don't mind it going in. If you revise the patch and ping me on it, I'll be happy to review
<GunnarHj> charles: Think I'd need some more guidance about how the new design affects the patch.
<charles> GunnarHj: looks like you added me to this review some time ago and I didn't see it. I'm sorry about that; that's my bad
<charles> GunnarHj: sure
<charles> so, two main ideas here
<stokachu> Laney: pingaling
<charles> 1. we want the indicators to be able to work everywhere, not just on gtk+ environments
<Laney> hello stokachu!
<charles> so we're removing gtk+ from the indicators, and shopping out the rendering to other code
<charles> which is where IDO comes in, for the gtk+ side it's got new gtkmenuitem subclasses that handle the custom menuitem logic that used to be in indicator-datetime
<stokachu> Laney: hey there! :D ive got a bug that I believe we have in shape for sponsorship, bug 962046
<ubottu> bug 962046 in python-boto (Ubuntu Quantal) "EC2 metadata retrieval fails with spaces in a resource name" [Medium,In progress] https://launchpad.net/bugs/962046
<Laney> stokachu: OK let me look
<stokachu> Laney: thanks!
<Laney> You just sneaked in before I was going to sign off
<charles> GunnarHj: for example, look at http://bazaar.launchpad.net/~indicator-applet-developers/ido/trunk.13.10/revision/131
<stokachu> Laney: lol sorry man
<charles> and http://bazaar.launchpad.net/~charlesk/indicator-datetime/gmenuify/view/head:/README
<Laney> stokachu: fixed in raring?
<Laney> Or do you not want to SRU it there?
<stokachu> Laney: its fixed in saucy.. ah yea i need to add the nomination for that series
<charles> GunnarHj: 2. the other side to this, is trying to send out time format strings to the clients, rather than actual time strings
<charles> that way the client can update periodically in-house without us having to keep shipping new updates over the bus
<Laney> stokachu: Also, I'd like it if the regression potential section listed places for testers to focus on
<GunnarHj> charles: Thanks; seems like I have some reading-up to do.
<charles> that's why some of the g_date_time_format() calls have been moved out of indicator-datetime
<stokachu> Laney: ok lemme get back with the openstack guys and see what I can gather
<Laney> stokachu: See https://wiki.ubuntu.com/StableReleaseUpdates#Procedure 3.3.3
<stokachu> Laney: thanks for looking
<Laney> I'll build/upload in the meanwhile
<stokachu> ok
<charles> GunnarHj: does that make sense?
<sil2100> Anyone from the SRU team around?
<GunnarHj> charles: Is the code you just pointed at not in the Ubuntu archive yet?
<charles> GunnarHj: the IDO code is already landed
<charles> GunnarHj: indicator-datetime should be landing today / tomorrow
<GunnarHj> charles: Ok.
<stokachu> Laney: im speaking to the openstack people now to get that stanza updated
<Laney> great
<GunnarHj> charles: Guess I'll need to study the new code then, and try to figure out what needs to be modified.
<GunnarHj> charles: Thanks for the clarifications!
<charles> GunnarHj:  it doesn't use dates, but if you're interested in the GMenu indicators as compared to the earlier gtk+ ones, the new indicator-power's been merged
<GunnarHj> charles: Hmm... "it doesn't use dates" - what do you mean by that?
<charles> GunnarHj: I mean that i-power might be useful if you're wanting to read some code to get up to speed on how the new indicator code is laid out
<charles> GunnarHj: but it's not directly relevant to your patch / your ticket wrt date formatting
<charles> GunnarHj: i-power's already merged
<GunnarHj> charles: Ok.
<charles> datetime, sound, and session are in the pipeline and should happen this week
<charles> ...should :)
<Laney> stokachu: I'll have to fix your version numbers. You can't have the same one in both Q and R.
<stokachu> Laney: sorry missed that in my checks, im kind of mentoring some of the openstack guys
<stokachu> ill make a note of that
<Laney> stokachu: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging (linked from StableReleaseUpdates) is a good document
<stokachu> Laney: ok cool this is helpful, im writing a document for my department to hopefully get everyone on the right track
<charles> GunnarHj: actually I think maybe there's a simpler way for your patch to get through
<charles> GunnarHj: let me write it up in your MP
<GunnarHj> charles: Sounds nice. ;-) Thanks in advance!
<Laney> stokachu: all uploaded
<Laney> thanks!
<charles> GunnarHj: https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214/comments/380144
<manish> ev: no issues. tomorrow is fine
<psusi> so it looks like gstreamer transitioned from 0.10 to 1.0 and we currently have both source packages.  If there's a bug that was fixed in upstream 0.11, do we update 0.10, say it's fixed in 1.0, or is it a wontfix since we're in the process of dropping 0.10 anyhow?
<slangasek> psusi: ought to be a wontfix and an added incentive to get revdeps moved off of gstreamer 0.10
<Laney> psusi: 0.11 was a development release leading up to 1.0
<Laney> 0.10 is EOL upstream even for bugfixes so we really should be pushing people off it
<psusi> Laney: did 0.11 ABI break with .10?  Why didn't we ever upgrade to that?  why the jump to 1.0, skipping the version in between?
<seb128> psusi, we did
<seb128> psusi, 0.11 was the 1.0pre serie, as Laney said
<seb128> psusi, e.g https://launchpad.net/ubuntu/+source/gstreamer1.0/0.11.94-1
<seb128> psusi, oh, and yes, 1.0 (and 0.11) broke abi/api
<seb128> they have been a multiple year refactoring effort
<highvoltage> win 29
<seb128> highvoltage, loose 30
<highvoltage> story of my life.
<seb128> cjwatson, I know you were TIL on mlocate, but it's a good idea to check the sponsoring queue in case before doing merges nowadays, https://code.launchpad.net/~logan/ubuntu/saucy/mlocate/0.26-1ubuntu1/+merge/169559 was waiting for sponsoring for some time
<psusi> seb128: so upstream really screwed up by calling it 0.11 in the first place then?  it should have been 1.0?
<Laney> psusi: Not really. It was always known to be the development series: http://gstreamer.freedesktop.org/releases/gstreamer/0.11.0.html
<Laney> 0.10.x was maintained for ages
<seb128> Laney, does GNOME screw by calling 3.<n> beta serie 3.<n-1>?
<seb128> ups
<seb128> psusi, ^
<seb128> Laney, sorry ;-)
<seb128> doko, I guess you didn't have a free slot for https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567 today?
<ubottu> Launchpad bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,New]
<seb128> doko, do you think you will have time tomorrow? that's sort of blocking saucy work atm...
<seb128> mterry, ^ sorry to bother you, but any chance you could help there?
<seb128> mterry, those are non trivial, but didrocks reviewed pre-upload and was fine with it, he just didn't want to ack them because he was involved in the upload and we usually don't ack own uploads
<slangasek> cjwatson: more partial upgrades out of update-manager today... libunity-core-6.0-6 and libunity-core-6.0-5 each have a strict versioned dep on unity-common, so the lib gets removed because of an unsatisfied dep, not because of breaks/replaces.  How should we handle this?
<slangasek> cjwatson: I think I would argue there's nothing "common" about unity-common in this case...
<slangasek> cjwatson: bug #1193120 filed for this, fwiw
<ubottu> bug 1193120 in unity (Ubuntu) "unity-common is not common" [Undecided,New] https://launchpad.net/bugs/1193120
<bdmurray> hallyn: your patch in precise proposed for libcgroup is called libcgroup_sumlinked_bin.patch and you may have wanted to name it symlinked.  I'll reject it or approve it - your call.
<doko> jbicha, are you sure the texinfo merge is correct?
<doko> https://launchpadlibrarian.net/142958668/buildlog_ubuntu-saucy-i386.gcc-4.8-powerpc-cross_0.4_FAILEDTOBUILD.txt.gz
<doko> at least it works in debian unstable
<jbicha> doko: I believe I preserved the Ubuntu diff correctly but fixing that is well beyond my abilities
<jbicha> oh it built correctly (which is why I didn't get a failure email) but your cross build didn't; I still don't know as I've never done cross-building
<RAOF> @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: RAOF, Laney
#ubuntu-devel 2013-06-21
<vipzrx> hello
<stokachu> doko_: do you have plans on merging puppet 3.2.1 into saucy?
<RAOF> @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: Laney
<pitti> Good morning
<didrocks> doko_: hey! did you get any time to have a look at bug #1192567? Seems mterry did for one, but the iso will still be blocked by it
<ubottu> bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,Incomplete] https://launchpad.net/bugs/1192567
<m4n1sh> pitti: when you are free, please check your @debian or @ubuntu mail
<pitti> m4n1sh: in general I'm happy to help out with Debian sponsoring; but my new GPG key still isn't updated in Debian, so I can't actually upload :/
<pitti> m4n1sh: so, what I can do is look over the package and see whether I spot anything weird
<m4n1sh> pitti: it is a dead simple package, a bunch of python scripts and a desktop file. Can you review it and refer it to someone else whom you know can help me upload it to debian?
<m4n1sh> yeah. that would be better. referring it to someone whom you know is willing to help would be appreciated
<pitti> m4n1sh: replied
<didrocks> cjwatson: trying to fix the dep (invalid .pc file included) pointed by mterry, but we got no feedback on other ^
<didrocks> cjwatson: not sure about the tests, will ask Mirv to get them run during build once he's back from holidays
<didrocks> cjwatson: if doko can't review the others today, I would propose that my +1 takes action once qtwebkit-dev fixed and promote it, but your pick :)
<dholbach> good morning
<pitti> apw: hey Andy
<apw> pitti, yo
<pitti> apw: I did some investigations for bug 1108082 and I think I found the option which we disable
<ubottu> bug 1108082 in linux (Ubuntu) "coredump_filter omits build IDs" [Medium,Confirmed] https://launchpad.net/bugs/1108082
<pitti> apw: so this is now a mere matter of resetting our config value to the default one
<pitti> apw: is there some way to mark the bug so that it gets in the kernel team's queue?
<apw> pitti, where is affected, is this devel or everywhere
<pitti> apw: all releases, but it's not something we want to change in stables; so saucy only
<tseliot> apw: the kernel available here doesn't have drm (the latest from the mainline ppa does though): https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<apw> pitti, ok put that on my plate and i'll do it now, mostly get it to me or jsaulisbury is the normal way, he has a tag he uses, but i forget -- i don't have one :(
<pitti> apw: ah, I thought about assinging it to someone appropriate, or set a milestone, or whatever you use in the kernel team to manage the bug queue
<pitti> apw: but if "bother you on IRC" is the accepted way, that WFM :)
<apw> pitti, for me, probabally the safest :)
<tseliot> apw: so I don't think that kernel will work with any graphics driver
<apw> tseliot, yep i'll look next
<tseliot> apw: ok, just please don't upload it or hell will break loose ;)
<apw> tseliot, the previous build worked as i am running it, so that is odd
<tseliot> apw: maybe drm was accidentally disabled in the config
<apw> tseliot, given how they are made i would be supprised, but will look shortly
<tseliot> apw: yes, the config looks fine here. It's just that the package is missing the actual modules
<didrocks> cjwatson: FYI: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/5
<ubottu> Launchpad bug 1192567 in qtwebkit-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,Incomplete]
<didrocks> cjwatson: so, just tell me how you want to proceed for the other deps
<apw> tseliot, which packages did you install specificially
<apw> tseliot, did you install linux-image and linux-image-extra ?
<tvoss> I'm having problems creating a saucy chroot on Hardy, the process bails out when trying to extract libglib-2.0. Is there something known about the issue?
<apw> tseliot, as the drm modules seem to be in there:
<apw> -rw-r--r-- root/root    476924 2013-06-17 13:48 ./lib/modules/3.10.0-0-generic/kernel/drivers/gpu/drm/drm.ko
<tseliot> apw: linux-headers-3.10.0-0-generic_3.10.0-0.5_amd64.deb linux-headers-3.10.0-0_3.10.0-0.5_all.deb linux-image-3.10.0-0-generic_3.10.0-0.5_amd64.deb
<tseliot> are the modules in the -extra package?
<apw> tseliot, ok so you only installed '-virtual' basically, the thin part.  a full -generic pulls -extras as well
<tseliot> apw: so the modules are in -extra?
<apw> tseliot, no, some of the kernel is in linux, some is in -extras,  drm happens to be in extras but not because it is a module because you don't need it on a server VM
<apw> tvoss, hardy?  really ?
<tseliot> apw: ok, I had no idea
<RAOF> apw: tvoss_ is in the enviable position of trying to work out why a build wedges on the buildds.
<doko> jbicha: nothing to do with the cross build, gcc-4.8 fails too
<cjwatson> didrocks: OK ... I'm not an MIR reviewer so my word doesn't mean much, but FWIW I guess I'd be happy to proceed temporarily without tests as long as we get a cross-my-heart-and-hope-to-die promise that it'll be sorted out once Mirv is back.  However I do think we need the other deps reviewed
<cjwatson> doko: ^- we need to get this sorted out today, FWIW, since image builds being blocked for days is a big deal, so can you either make time for this or make sure somebody else on the MIR team does?
<Daviey> doko: ipxe seems to think that gcc 4.8 has a bug (as shown in the rebuild) - https://github.com/ipxe/ipxe/commit/238050dfd46e3c4a87329da1d48b4d8dde5af8a1 .. If it is indeed a gcc bug, i assume it will not be fixed this cycle?
<ev> mpt: http://www.engadget.com/2013/06/21/apple-publicly-charts-ios-fragmentation/
<davmor2> ev: is that because apple push the updates, in comparison to google where the phone manufactures do, and they want you to buy new hardware not upgrade your existing?
<mpt> Ah, the pie chart, William Playfair's biggest mistake
<ev> I have no idea, but I'm surprised there are that few first generation iPads out there
<ev> heh!
<doko> cjwatson, didrocks, yes, looking at it now
<doko> Daviey, is there a test case somewhere?
<ev> all hail the doughnut chart!
<mpt> ev, so when do we see the area chart for Ubuntu? :-)
<cjwatson> Now I'm hungry
<Daviey> doko: Not as far as i know.  the rebuild you did exposed it to me, and referring upstream who believe it to be a bug.
<Daviey> (in gcc)
<ev> mpt: I had a conversation about this, but I cannot for the life of me remember why we decided against it for now.
<ev> I should stop talking to people in the kitchen and exclusively use email
<ev> or maybe just email them in the kitchen
<mpt> That's why we need Ubuntu on fridges!
<ev> LOL
<ev> mpt: quick, lets find a venture capitalist
<mpt> Huh, fridge.ubuntu.com still exists
<ev> icebox.ubuntu.com? :)
<doko> Daviey, believing in a gcc bug is the easiest thing ;p
<Daviey> doko: Yeah, lets switch to LLVM - it's bug free.
<doko> Daviey, sure, as long as we don't use clang
 * cjwatson mutters something about bad workmen and tools :)
<Daviey> doko: What i am trying to find out is if you think it is a gcc bug, and if we work around it now.. should we be aware to undo this workaround later in the cycle.
<xnox> ev: they measured last two weeks of accessing "apple store", guess what, one no longer can access latest apple store on the first gen / older devices!
<doko> Daviey, understood, it's asm syntax, so I have to look into it too
<xnox> ev: maybe we should generate ubuntu version fragmentation based on errors.ubuntu.com and point out that everyone is on precise and up =)
<ev> xnox: I'm not sure I understand what you mean. I have a first-generation iPad and can access the App Store fine.
<ev> xnox: :)
<xnox> ev: really?! /me clearly remembers error messages 'you must buy newer apples to continue'
<xnox> ev: and is there much to install on a first-gen iPad still?
<xnox> what's the highest iOS it can get?
<ev> 5.1.1
<ev> there are still updates to things like Chrome
<ev> Google Currents cannot be updated
<xnox> google are generally good, e.g. chrome only recently dropped lucid support.
<Laney> oops
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<cjwatson> doko,Daviey,jamespage: The /builders 403 bug is now bug 1193057.  I have a test which is appropriately failing, so it shouldn't be too difficult to fix from here.
<ubottu> bug 1193057 in Launchpad itself "Copies of public source to private archives owned by private teams causes /builders to 403" [Undecided,In progress] https://launchpad.net/bugs/1193057
<jdstrand> jodh: hi!
<jdstrand> jodh: while you were away, we discussed getting a new upstart with the apparmor patchset into Ubuntu
<jdstrand> jodh: and it was decided that we would wait on your return, because there was something else you wanted to have included
<jdstrand> jodh: we want to have the apparmor patches in as part of the application lifecycle (a multi-team effort), and as soon as is reasonable for you
<jodh> jdstrand: sure. we're in the process of putting a new Upstart release together that will include the Apparmor feature.
<jdstrand> jodh: what are your plans with uploading a new upstart?
<mdeslaur> jodh: I have a distro patch for the new upstart that needs to go in the distro upload
<jdstrand> jodh: awesome. can you coordinate with mdeslaur? he has a distro patch that will need to go with your upload, aiui
<jodh> jdstrand: I was imagining early-mid next week.
<jodh> jdstrand: ack.
<mdeslaur> hehe
<jdstrand> jodh: thanks! :)
<xnox> mdeslaur: please propose them against lp:ubuntu/upstart it's a "'fully mergeble with lp:upstart" branch.
<jdstrand> ricmm: fyi ^
<Riddell> doko: ICE in GCC on arm in kde4libs? any thoughts?
<Riddell> ../../khtml/svg/SVGStyledLocatableElement.h:45:27: internal compiler error: in extract_insn, at recog.c:2154
<Riddell> https://launchpadlibrarian.net/143010200/buildlog_ubuntu-saucy-armhf.kde4libs_4%3A4.10.80-0ubuntu1_FAILEDTOBUILD.txt.gz
<mdeslaur> xnox: ok
<mdeslaur> xnox: it doesn't have the new upstart now though, right?
<doko> Riddell, please open an issue, *including* the preprocessed source
<doko> Riddell, can this already be cross-built?
<mitya57> Riddell: hi, I've uploaded some fresh Qt 5 merges to saucy, can you please add me to ~kubuntu-packagers so that I can commit it?
<Riddell> doko: an issue in gcc bug tracker?
<xnox> mdeslaur: not yet, but soonish. What are the distro patches?
<Riddell> mitya57: oh cool, sure
<mitya57> (namely qttools, qtgraphicaleffects and qtmultimedia)
<Riddell> doko: I've never tried any cross building so I don't know
<doko> Riddell, yes, a reproducible ICE always is a gcc issue
<mitya57> Riddell: thanks
<mdeslaur> xnox: a couple of added distro-specific stuff in the apparmor_available() function, and a fail-open when apparmor fails in job_process.c to emulate current ubuntu behaviour
<mdeslaur> xnox: let me know when all the apparmor stuff hits lp:ubuntu/upstart, and I'll propose a merge
<xnox> i see.
<mdeslaur> jjohansen: are your /sys/module/apparmor/parameters/enabled permissions relaxed yet in saucy's kernel?
<jjohansen> mdeslaur: no I haven't given the kt a pull request that fix yet
<mdeslaur> jjohansen: soon? like, before the new upstart hits? :P
<jjohansen> mdeslaur: the dbus ppa kernel should have that fix
<jjohansen> mdeslaur: when will the new upstart hit?
<xnox> jjohansen: "<jodh> jdstrand: I was imagining early-mid next week."
<hallyn> bdmurray: gah
<jjohansen> xnox: okay, I'll pull together a kernel pull request
<mdeslaur> actually, it doesn't matter as long as we don't use the new stanzas
<xnox> by default that is.
<xnox> still would be interesting to play with this feautre.
<jdstrand> mdeslaur: things are landing fast-- upstart-app-launch is in the archive already. the unity team is working to get those bits too
<mdeslaur> yep
<jdstrand> mdeslaur: that said, upstart-app-launch doesn't have the stanza yet
<hallyn> bdmurray: I don't actually have upload rights to that, so if you reject i'll need to bug someone else over it...  so i'm tempted to say approve it.
<jdstrand> but the goal is to have it all together soon. cherrypicking the one patch for the pull request seems reasonable
<mdeslaur> jdstrand: what are you referring to?
<jdstrand> jjohansen: the pull request jjohansen mentioned
<mdeslaur> oh, yes, definitely
<jdstrand> iirc, it was just a teeny little patch
<mdeslaur> it needs to happen asap when the new upstart is available
<jdstrand> ok
 * jdstrand nods
<mdeslaur> I just meant stuff won't explode if upstart gets uploaded a day before that patch goes in
<jdstrand> ok, yes, agreed
<jdstrand> we won't add the stanza to upstart-app-launch until the other bits are in place
<xnox> jdstrand: mdeslaur: sounds like we'd want a versioned depends anyway...... but then again there is no way to define one for _all_ kernels......
<mdeslaur> xnox: it's not important enough for a versioned depends...I don't want to prevent someone from testing older kernels
<xnox> also considering the case where we are booted into old kernel, yet upstart is upgraded and statefully re-execed, how badly things greak?
<jdstrand> well, we'll need to handle that gracefully, cause people use test kernels without apparmor,e tc
<mdeslaur> it just won't allow user session apparmor switches
<jdstrand> (or disable, etc, etc)
<jdstrand> mdeslaur: yeah, your patchset already handles all that, right? that is your distro patches, correct?
<mdeslaur> xnox: it will fail gracefully, no issue
<xnox> mdeslaur: fair enough.
<mdeslaur> jdstrand: not the distro patches, the upstream upstart will simply not start user jobs that require an apparmor switch
<jdstrand> ok-- I thought I remembered it was all handled, couldn't remember where
<mdeslaur> sorry, it will start them, just without the switch
<jdstrand> we probably want upstart-app-launch to have a versioned depends on the upstart that has the apparmor patches when we add the apparmor stanza
<jdstrand> but that is different
<mdeslaur> doko: are you going to merge puppet, or can I go ahead?
<doko> mdeslaur, please go ahead
<mdeslaur> doko: ok, thanks
<tedg> jodh, hello, it seems that we're ending up in a situation where the unity job isn't starting.  It actually seems to be hanging.
<tedg> jodh, Any ideas for debugging that?
<jodh> tedg: anything in ~/.cache/upstart/unity.log ?
<tedg> jodh, No, it isn't even created
<tedg> jodh, xsession is blocking on initctl emit xsession
<xnox> tedg: racing against gnome-session? e.g. it has been started outside of upstart and hence now the upstart's unity dies whilst re-spawning?
<xnox> tedg: are there any unities running?
<xnox> in like $ ps output
<tedg> xnox, No, no instances of compiz.  And I'm not getting any flicker of the compositor turning on and off.
<tedg> I took out the waiting on the xsession event.  And the pre-start script that we had, but it seems to be roughly the same (except that xsession-init doesn't block)
<tedg> Basically the job never leaves "start/starting"
<jodh> tedg: can we see the updated .conf somewhere?
<tedg> The one I stripped down to debug is here: http://paste.ubuntu.com/5786760/
<tedg> But then one you have on your system does the same.
<tedg> I was just trying to remove variables
<jodh> tedg: does that compiz build run from the command-line ok? also why have we lost the post-start and pre-stop?
<tedg> jodh, Yes, it runs from the command line.  And I was cleaning things up a bit thinking they might be the issue.
<jodh> tedg: also, on my hardware, respawn is absolutely essential :)
<tedg> Heh, sure.
<tedg> I need to set it up to put some limits on that.
<tedg> I ended up with a bug a couple weeks ago where compiz was restarting so fast I thought my CPU was going to melt :-)
<infinity> tedg: Say, you're a desktop guru.
<tedg> It'll never catch on.
<infinity> tedg: What bit hinders my ability to reboot from the gear menu if I've logged in on another console?
<infinity> tedg: And, more pressingly, why does that bit continue to hate me even if I've logged in *and out* on another console?
<tedg> infinity, Well, we get that info at different points, so it might be broken in either indicator-session or the gnome bits.  But we get the info from ConsoleKit/LoginD.
<tedg> infinity, Are you not getting the prompt or is it not working once you're rebooting?
<xnox> infinity: logind?!
<xnox> infinity: for me logind usually proactively kicks it and kills everything for me. Btw. open a terminal and execute "$ stop" =) it's left as an exercise to the reader to work out what that does.
<jodh> tedg: I've disabled unity.conf on my system, yet something (the panel service?) is starting it anyway.
<tedg> jodh, It's gnome-session.  You need to edit: /usr/share/gnome-session/sessions/ubuntu.session
<tedg> jodh, Make it look like: http://paste.ubuntu.com/5786806/
<infinity> tedg: When you ask it to reboot, it logs you out instead.  Which is arguably correct behaviour if I really am logged in on another console (though it would be swell if you could somehow pass a message to lightdm that would print a "Reboot prohibited due to active sessions on another console" message or something)
<infinity> tedg: But yeah, I've noticed the same behaviour if I logged in on another console and logged out again.  Not a race condition, as that login could have been days ago, so perhaps a refcounting issue in something.
<didrocks> doko: any progress on the review for qtwebkit?
<tedg> infinity, That sounds like a gnome-session issue as I think we pass the command directly to them.
<seb128> infinity, did you try today?
<seb128> I just go a "another user is logged in, enter your admin password to reboot anyway"
<infinity> seb128: Nope, although I did just do an upgrade on a text console today, so we're about to find out when I try to reboot. :P
<seb128> I'm wondering if the gnome-session 3.8 update from yesterday fixed that
<seb128> you need to start a new session to get that gnome-session running though
<infinity> Maybe this is a fixed problem as of this week.  We'll see.
<seb128> but yeah
<infinity> Well, we'll see when I'm in a position to reboot and test.
<seb128> infinity, but yeah, known issue other: https://bugs.launchpad.net/indicator-session/+bug/861171
<ubottu> Launchpad bug 861171 in indicator-session (Ubuntu) "Shutdown from greeter does nothing when multiple accounts open" [High,In progress]
<seb128> infinity, we almost got a fix, robert_ancell had a vcs branch: https://code.launchpad.net/~robert-ancell/indicator-session/lp-861171/+merge/137085
<seb128> infinity, http://imgur.com/K3CzMrV
<infinity> tedg: While I'm whining about desktop things, has anyone reported and/or fixed a bug about unity-panel-service spinning out of control, stealing focus, and making their desktop useless for seconds/minutes?  Is that another bug I should expect is fixed as of today and I just need a reboot? :P
<seb128> but then the unity guys replaced the indicator-session dialogs by unity ones
<tedg> infinity, There were some issues there with people who have indicator-network installed, is that you?
<seb128> infinity, I didn't read any bug like that one you just described
<infinity> tedg: Nope.  The only non-standard indicatory thing I have installed is pidgin.
<infinity> tedg: Which may well be the problem, dunno.
<tedg> infinity, Seems unlikely.
<tedg> infinity, Hmm, so no, haven't seen anything like that.  Not sure how the panel service could steal focus though....
<infinity> Alright, I'll finish up this upgrade, reboot to make sure I'm in clean and upgraded sessions, then see if I can reproduce and file a bug.
<infinity> tedg: I'm not sure how it steals focus either, but it does.  Hangs on to both mouse and keyboard while it's spinning a core to oblivion, and sometimes for several minutes.
<seb128> tedg, charles: btw it could still be useful to get https://code.launchpad.net/~robert-ancell/indicator-session/lp-861171/+merge/137085 merged in
<doko> didrocks, I'm looking at it currently, but not exclusively, started an hour or two ago
<seb128> those dialogs are still used in e.g the greeter
<infinity> tedg: If I can come up with a useful reproduction recipe, I'll aim a bug at you.
<infinity> tedg: The part where you've never heard about it before is a bit disconcerting, I wonder if I've done something terrible locally.
 * cjwatson pushes up https://code.launchpad.net/~cjwatson/launchpad/builders-visibility/+merge/170818 - hopefully that'll sort out all the remaining /builders 403 bugs
<seb128> infinity, the flickering is usually a segfault, did you try to attach gdb to it?
<infinity> cjwatson: Oh, shiny.  I'd asked wgrant to look at that and tell you not to waste your time on it, but I'll happily accept your fix anyway. :P
<infinity> seb128: I've not attempted any debugging yet, first step was to ask people if it was already known/in-progress.
<cjwatson> Yeah, too slow, and I was interested anyway :)
<infinity> seb128: I'll try to reproduce after my next reboot and see if I can get anything useful out of it.
<seb128> infinity, no, but if that's a segfault of the service any indicator could cause it, stacktrace would help to say if that's known
<seb128> infinity, thanks
<infinity> cjwatson: Does that fix both the copy-from-public-to-private bug and the private-recipe bug?
<infinity> cjwatson: (The private recipe one being lower priority, since it's only for a few seconds at a time instead of potentially hours, but I figured the fix would probably be similar)
<cjwatson> infinity: I believe so.  It wasn't actually private-recipe as such, it was a recipe built from public branches for an archive owned by a private team
<infinity> cjwatson: Oh, I note you have both bugs linked from the branch.
<cjwatson> Ever since wgrant's fix for bug 728673, those two cases have gone through identical formatter code
<ubottu> bug 728673 in Launchpad itself "BuilderSet:+index crash (/builders)" [Critical,Fix released] https://launchpad.net/bugs/728673
<cjwatson> So in both cases it's "ooh, shiny, the PackageBuild is visible, let me try to render archive.owner.name"
<cjwatson> *splat*
 * infinity nods.
<cjwatson> At least as far as I could work out
<Daviey> cjwatson: super, thanks!
<bdmurray> hallyn: okay
<seb128> shrug
<seb128> doko, something in the gcc-4.8 4.8.1-2ubuntu1 -> 4.8.1-3ubuntu1 or binutils 2.23.2-2ubuntu3 -> 2.23.52.20130612-1ubuntu1 broke gtk on armhf
<seb128> doko, is there any known issue in those updates?
<seb128> Laney, pitti, didrocks: ^ fyi
<Laney> you tested with the old versions?
<seb128> the failing test doesn't fail if I rebuild with those downgrades
<seb128> Laney, I downgraded both and tested on my n7
<Laney> are they tied together such that you can't isolate which one it is?
<seb128> will update binutils and try again
<Laney> cool
<seb128> Laney, no, it's just that it takes 3 hours to build gtk on this thing
<Laney> thanks for investigating
<seb128> so I went for "let's see if that's the toolchain"
<Laney> is porter-armhf faster? ...
<didrocks> seb128: thx
<seb128> Laney, I can't downgrade packages on porter-armhf
<Laney> oh yeah
<seb128> Laney, sudo give you apt but not dpkg or edit of sources.list
<Laney> I forgot about that restricted apt business
<ScottK> seb128: kde4libs broke too.
<infinity> seb128: binutils seems like the more likely culprit, given all that's changed in that snapshot.
<seb128> ScottK, thanks, that's useful information ... did anyone figure out what exactly change/broke? do you have a bug about it?
<ScottK> seb128: No, there was an ICE in the build overnight.
<ScottK> Since ~none of the involved people have working arm hardware that's anything other than really, really slow, we didn't get far with it.
<seb128> yeah, I'm fighting that was well
<seb128> the porter box I've access to doesn't give me enough rights to downgrade packages or install custom debs
<seb128> the nexus is sloooow
<Laney> I could give you ssh to my panda if you want it
<infinity> The Nexus7 is faster than a Panda.
<ScottK> xnox has some really fast hardware apparently, but no time to operate it.
<infinity> (except possibly for storage I/O)
<Laney> It's got a USB disk attached for better IO
<Laney> so only takes 1h46 to FTBFS gtk
<infinity> ScottK: He does?
<infinity> xnox: You have fast ARM hardware?
<ogra_> highspeed pandas :)
<ScottK> He claimed to.
<seb128> Laney, thanks but that's ok, I can "just" make clean in the gtk/ subdir and rebuild that part, which should take less than 1h
<ScottK> But then he said something about Friday and going to the beach.
<Laney> k
<seb128> infinity, the issue is I/O indeed
<infinity> seb128: Don't forget to -j4 for your N7's cores. :P
<seb128> yeah
<Riddell> looks like qtwebkit-source has a similar arm gcc internal error
<Laney> always with the minimal reproducers :P
<xnox> infinity: not what you think.
<xnox> infinity: i have nexus7 (currently in flux testing cross-compiled flipped images), panda, and in-ram qemu across 8 ivy-bridge cores (which apparently cannot build kde*).
<xnox> infinity: have you got the actually fast ARM hardware for us in launchpad yet? =)))))
<charles> seb128: right, I'm going through i-session's merge requests today
<seb128> charles, thanks
<charles> seb128: actually there are also a couple of patches already merged that I need to retrofit for the GMenu code
<infinity> xnox: We're still burn-testing our Calxeda kit.
 * xnox ponders why pull-debian-source e2fsprogs unstable pulls something old, instead of what launchpad thinks it should be for about 4 hours now. Does pull-debian-source talks to something else to query latest/greatest version numbers for debian?
<charles> seb128: after that, I can finally mark those merge conflicts as resolved on the gmenu branch, and finally let CI run it... :)
<xnox> infinity: ack.
<seb128> charles, \o/
<didrocks> jdstrand: seems mterry wants a quick security audit for qtscript-opensource-src
<didrocks> cjwatson: FYI ^
 * ScottK LOLs at "quick security audit" and Qt in the same sentence.
<jdstrand> didrocks: ack, but I can't today. added to todo for monday
<didrocks> cjwatson: ^ not sure how this is going to end for the ISO :/
<mdeslaur> gah! another unmaintained javascript engine, how awesome
<jdstrand> mdeslaur: that is supposed to only be temporary-- ie related to qt5webkit
<xnox> didrocks: something did build today... http://cdimages.ubuntu.com/daily-live/20130621/
<didrocks> mterry: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/11
<ubottu> Launchpad bug 1192567 in qtscript-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,Incomplete]
<didrocks> xnox: interestingâ¦
<didrocks> mterry: looking at qt3d now, the fix should be the same
<mdeslaur> jdstrand: nothing else uses qscript yet?
<mterry> didrocks, cool
<infinity> jdstrand: Do we have a long-term plan for webkit that actually makes sense?  I saw you mention it in passing, but I'm curious if whatever we do will end up being reusable by all the flavours that need a webkit, or if it'll end up being vaguely UbuntuDesktop/Touch-specific.
<jdstrand> mdeslaur: it is being pulled in because of the signon changes needing qt5webkit, and qt5webkit needing it, so no
<jdstrand> infinity: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-webkit-maintenance
 * infinity is pretty non-plussed with the trend of embedding webkit and v8 all over the world.
<jdstrand> infinity: the plan is being formed. we think we have come up with something reasonable, so 'yes'
<infinity> "Package Chromium Content library and develop Ubuntu SDK bindings for the Chromium Content library."
<jdstrand> but the plan does not include maintaining all the various bindings (webkit-gtk, qt4webkti and qt5webkit)
<jdstrand> the plan is create our own bindings that others can use
<infinity> jdstrand: So, this means we'll be tied to v8 (while Qt was planning to move to a new JS engine that might actually work on more than 2.5 platforms)
<jdstrand> if you are referring to QML, that is different
<jdstrand> we'll follow upstream Qt on that
<jdstrand> the javascript that is in the webview and the javascript used for interpreting QML are different now and will continue to be
<ScottK> infinity: The Ubuntu webkit stuff will be Ubuntu specific.  It won't help us any.
<infinity> ScottK: Yeah, I just got through the proposal and came to the same unfortunate conclusion.
<jdstrand> ScottK: that is a rather pessimistic view. we will be making our bindings available to upstream
<infinity> Sadly, I'm not sure I see a better option other than "make all the upstreams get along"... This certainly isn't a situation of our making. :(
<jdstrand> if upstream upstream qt wants to take that and help, great, if not, they can continue to do as they've always done
<infinity> jdstrand: Given that we could never get people to merge and collaborate on webkit codebases before, I doubt offering them a third option will get anywhere.
<ScottK> jdstrand: When the proposal was announced we talked to rekonq upstream about supporting it and got told they weren't going to do distro specific webkit variants.
<infinity> (Or a fourth option, now that Google has forked too)
<ScottK> So I'm not guessing.
<jdstrand> that is a valid point. toolkit upstreams have different requirements than we do
<jdstrand> ScottK: I am not talking about rekonq. I am talking about qt upstream
<ScottK> If you can sync up with them, then yes, that helps us a lot.
<ScottK> (and it's no longer distro specific)
<ScottK> The plan I saw was for an Ubuntu specific stabilized/maintained version.
<mdeslaur> just to be clear, we're not doing webkit, we're doing blink
<jdstrand> well, we're doing the chromium content api, which includes blick underneath
 * xnox .... which was discussed before blink
<jdstrand> blink*
<xnox> right.
<jdstrand> the webkit landscape is unfortunate and depressing in general. we can't solve that (google and apple couldn't solve it either)
<jdstrand> so we are working with the available options
<infinity> jdstrand: Yeah, I'm not sure the plan qualifies as "sane", but I'm equally unsure that there's a better option that we can drive.
<mdeslaur> it's not a sane plan, it's the less insane plan we could come up with
<infinity> And given everyone's reluctance to stabilise a One True Webkit upstream, there's not much we can do.
<mdeslaur> webkit's future is in flux
<infinity> mdeslaur: That statement's been true for years.
<mdeslaur> with google gone, apple's been removing all the platform specific stuff
<mdeslaur> it's gotten worse
<infinity> If Apple and Google would just hand over the reigns to a third party (Collabora comes to mind?), this could all be cleaned up, but they don't like giving up their toys.
<infinity> s/reigns/reins/
<didrocks> mterry: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/12. So I guess only qtscript is the remaining blocker one.
<ubottu> Launchpad bug 1192567 in qtscript-opensource-src (Ubuntu) "[MIR] qt5webkit " [Undecided,Incomplete]
<mdeslaur> whoever controls the web controls the ad revenue, so I doubt they will give up their livelyhood for the sake of the greater good
<didrocks> doko: I think mterry has beat you :)
<infinity> mdeslaur: But if there's anything the Linux kernel has taught people, it's that the greater good is also the individual good, with a well-managed and non-biased upstream.
<jdstrand> didrocks: if it helps, I'll give the ok to pre-promote (in this case it doesn't make a lot of sense to block on a security audit that is temporary-- I'll make the same comment on it too)
<infinity> mdeslaur: But, yeah, a hard sell, when it's the sort of thing that needs to go all the way to the top of the management chains at the US's two most powerful tech companies, nevermind the two large open source stakeholders than also can't get along.
<didrocks> jdstrand: yeah, I'm not sure what we built as an image, but at least, that would be awesome to do that, do you want me to keep the bug status for qtscript as opened?
<mdeslaur> infinity: I'm not sure...the kernel is pretty much a commodity...it's not the differentiating factor that makes your product better than the competitors
<didrocks> jdstrand: oh btw, you did see that it's similar for libhybris, right?
<didrocks> jdstrand: you were on holidays when it happened, I assigned it to you IIRC
<didrocks> (but had to prepromote, and it's only used in the touch image which was already installing it)
<didrocks> jdstrand: https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1188213 FYI
<mdeslaur> but yeah, in an ideal world we'd get a single browser engine that everyone would use
<ubottu> Launchpad bug 1188213 in libhybris (Ubuntu) "[MIR] libhybris" [Undecided,New]
<infinity> mdeslaur: That's not true at all in the case of Android, for instance.
<infinity> mdeslaur: Where Google's finally been upstreaming all their fancy for the greater good (and, more importantly to them, reduced maintenance burden).
<mdeslaur> infinity: I don't purchase my phone based on kernel capabilities
<infinity> mdeslaur: And the webkit landscape is an absolute mess for maintenance burden.  The merging between the (now four) major forks is insane.
<infinity> mdeslaur: You don't purchase your phone based on how shiny the web browser is either. :P
<infinity> mdeslaur: And only the nerdiest of the nerdy choose their desktop browser based on killer features too.  Normal people really don't.
<jdstrand> didrocks: I didn't, thanks
<mdeslaur> infinity: normal people choose whatever seems to work best
<didrocks> jdstrand: seems you already have a fun schedule for next week :p
 * jdstrand always has a fun schedule :P
<didrocks> heh
<infinity> mdeslaur: Right, which has little to do with shiny new features, but rather stability and some combination of standards and quirking.
<mdeslaur> infinity: but google wants chrome to get the shiny new features first
<mdeslaur> which work with the coolest websites
<mdeslaur> which makes people want chrome
<mdeslaur> etc.
<infinity> mdeslaur: A blessed upstream and downstreams maintaining feature branches would solve that need.
<mdeslaur> perhaps
<infinity> mdeslaur: (Much like Linux distributions will often land features before committing upstream, just to have that tiny head start).
<didrocks> jdstrand: mterry: kenvandine: seb128: cjwatson: ok, promoted all components as per discussion and fixes and prepromoted qtscripts. I set the qtscripts task to NEW and all other to fix committed. We should be back to normal iso building
<cjwatson> xnox: The ISO parts built today, but the livefs parts didn't.  Look at the timestamps on *.manifest
<cjwatson> didrocks: Thanks
<didrocks> cjwatson: thanks to mterry for the MIR reviews (and jdstrand for the future security review ;))
<xnox> cjwatson: ah.
<mterry> :)
<cjwatson> didrocks,mterry: looks like the two of you raced setting the status of the qt3d-opensource-src task on that bug?
<mterry> cjwatson, aye, fixed
<didrocks> cjwatson: indeed! mterry you are too slow! :p
<didrocks> thanks
<didrocks> cjwatson: even if qtwebkit-opensource-src entered -proposed as 5.0.1-0ubuntu3 in universe, it will get into main once copied to the release pocket (as 5.0.1-0ubuntu2 is)?
<cjwatson> There are some bugs around override handling with copies
<cjwatson> Keep an eye on it; it's possible you may need to repeat the override
<seb128> infinity, doko: seems it's on of the changes in gcc-4.8 4.8.1-2ubuntu1 -> 4.8.1-3ubuntu1  that broke gtk on armhf, any idea which one could create issues?
<infinity> seb128: Have you tried with -4ubuntu1?
<infinity> seb128: (And no, I'm afraid I'd have no idea, but doko might)
<seb128> infinity, no, let me try that ... I started those builds yesterday
<seb128> shrug and there is new svn version in 4ubuntu2
<seb128> can try directly I guess
<infinity> seb128: -4ubuntu2 would be more interesting, but it's still building. :P
<seb128> will take another 9 hours or so to have it available it seems
<seb128> that's a job for monday then
<seb128> let me try ubuntu1 still
<infinity> Oh, hey, all the things I was waiting for are done, I can reboot now and see if unity-panel-service still hates me.
<doko> there shouldn't be that many changes
<doko> seb128, what did break?
<seb128> doko, I'm not sure to understand what's happening, css parsing in gtk return an assert when building with that gcc version
<seb128> like if the datas were corrupted
<seb128> the css is embedded in the binary as a resource
<ScottK> doko: There's an ICE on armhf with kde4libs, not sure what it's about.
<seb128> but extracting it with gresource (the command line utility to deal with those) gives a valid file
<ScottK> It's the first attempt on a major new version, so I don't know if it's a new issue on gcc 4.8 or newly exposed due to upstream code failing.
<doko> ScottK, preprocessed source needed. Riddell told me
<doko> seb128, -3 had the linaro toolchain update, so yes, it could be ...
<ScottK> ENOHARDWARE
<seb128> doko, is there any kind of testing I can do that would make figuring out what change is creating the problem easier?
<doko> seb128, maybe open an issue for gcc and gtk, to collect more information?
<seb128> doko, yeah, I will do, it took me a day to figure out it was gcc that changed for the issue to start
<seb128> doko, I'm just going to test with your new uploads from today first
<doko> seb128, well, try to lower the optimization level in the gtk build, then try to combine object files from a O1 and O2 build until you find something odd
<seb128> doko, ok; thanks
<doko> but I'm afk now
<seb128> that can wait next week
<seb128> doko, have a good w.e
<saiarcot895> If I need to fix a build failure on Ubuntu, do I create a branch and merge it into the saucy-proposed version of the branch?
<cjwatson> I usually just use saucy even though that's technically arguably a bit incorrect
<cjwatson> It'll usually be correct soon enough
<saiarcot895> Thanks cjwatson
<hallyn> infinity: would you mind taking a look at https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=qemu-kvm ?  the .10 is a better fix by/for arges than the .9 which is pecolating in precise-proposed right now.
<hallyn> (then i need to get to work on a 1.0 stable upstream tree based on the patches in our package)
<ricmm> jdstrand: ping
<ricmm> jjohansen: any update on the patches?
<jjohansen> ricmm: sorry, yeah I am currently reworking my audit shim, and then I will rebuild and test again.
<ricmm> great, thanks
<ricmm> did you get to reach maguro?
<jjohansen> ricmm: The backport for all 4 are done, besides the reworking the shim and any other errors I might yet find
<ricmm> awesome! great work
<jjohansen> ricmm: I am will send out pull requests for all of them today
<ricmm> jjohansen: great :) can you cc me in any email? to be in the loop
<jjohansen> ricmm: sure
<ricmm> ricmm@c.c
<wgrant> cjwatson, infinity: Right, recipes themselves can't be private, and recipes can't use private branches, so "private recipe build" just means "recipe build in a private archive"
<wgrant> cjwatson: Thanks for fixing that. Had it planned for Monday, but this is easier :)
#ubuntu-devel 2013-06-22
<TripWIki> hi
<ScottK> doko_: kde4libs still FTBFS on armhf with that latest gcc-4.8, but now it says, "The bug is not reproducible, so it is likely a hardware or OS problem.".
<ScottK> Suggestions?
<doko> ScottK, try again
 * ScottK does.
 * Noskcaj is away: I'm either at school or soccer. or i just don't like you.
<Noskcaj> stupid xchat
<hacktus0> how can I pubblish my apps
<hacktus0> ?
<mitya57> hacktus0: you probably want #ubuntu-app-devel or something like that
<hacktus0> OK
<nonickname2> slangasek: regarding #1187318 and #1173320 : i assume you read in my report (the latter one, comment #8) that it's (at least here and at the time i tested) depending on the plymouth theme if text is shown or not (so these might be something to look at, too)? also: yes, i was using/installed from i386 .isos - obviously don't know about the commenting people though ...
<infinity> Oh joy, now bamfdaemon crashes and takes out my desktop.  So many exciting ways to kill my workflow.
<optimisme> hi, do you know wich signal is emited when a menu_item is shown in gtk/indicatorwidget ? i want to pisition the "popup window" properly after the submenu is shown but it moves back to its original position using "show" or "focus" signals ... or prevent its repositioning to defaults overwitting a method, i can position it properly when allocating
<optimisme> nevermind, I found a workarround, thanks
#ubuntu-devel 2013-06-23
<Noskcaj> roaksoax, kirkland_ Have either of you got a time for testdrive yet
<vlad_starkov> Emergency Question: just changed disk in RAID1 in Ubuntu 12.04 Server. After that mdadm recovered new disk. After reboot the system does not load. Only blinking cursor appears. Is it possible that it needs to reconfigure GRUB?
<vlad_starkov> Emergency question: Could anyone look at this `boot-repair` output http://paste.ubuntu.com/5791662/ and point me why the system does not boot? (I changed failed HDD in RAID1 and after that the system does not boot)
<vlad_starkov> Emergency question: Could anyone look at this `boot-repair` output http://paste.ubuntu.com/5791662/ and point me why the system does not boot? (I changed failed HDD in RAID1 and after that the system does not boot)
<hsn> whats vim command for copying character from line bellow cursor
<hsn> CTRL-something
<hsn> CTRL-E in INSERT mode
<prahlad> Just installed ubuntu 13.04, have an issue with network-manager (nm-applet crashes). Can anyone help ?
<prahlad> I'm running the amd64 version..
<jbicha> hey, could someone retry https://launchpad.net/ubuntu/+source/gcr/3.8.2-3/+build/4728126
<stgraber> jbicha: done
<hearit> my voice up today for Nelson Mandela
<ScottK> doko_: kde4libs has now failed with the not reproducible, probably a hardware or OS problem on every single type of armhf buildd we have (most more than once).  Suggestions on how to proceed?
#ubuntu-devel 2014-06-16
<p0s> where can i speak to the person who packages eclipse for 14.04?
<bluezone> p0s, oh lord :P
<p0s> bluezone: are you the one?
<bluezone> no, but i would always use the official site of eclipse :P
<infinity> bluezone: Are you aware of specific bugs in the packaged version?
<bluezone> infinity, eclipse has 50 different versions and plug-ins and it is known to break often, my opinion would be to use the distributions on the official website so at the very least you won't have to spend time figuring out what you're getting in the eclipse package
<p0s> bluezone: if you think having a *distribution* of software is wrong and people should assemble their own system, why are you in #ubuntu-devl? :)
<infinity> bluezone: ^-- What he said.
<bluezone> you don't have to assemble anything
<bluezone> you download, extract and double click the executable
<p0s> bluezone: and then you manually update it whenever updates arise because you have no package manager. and then you forget about it when there are security issues. and then you are back at something like the windows world where every machine is compromised because it takes years until everyone has a certain security update
<p0s> anyway, if someone could tell me the channel where the packager of eclipse likely is present or even his nickname, i would be glad. thanks in advance! :)
<bluezone> p0s, if you are talking about "help->update" then yes you have to do it manually, but it is a small price to pay
<infinity> p0s: We sync it from Debian, so the packagers are the folks listed in 'apt-cache show eclipse' (or on http://packages.qa.debian.org/e/eclipse.html)
<infinity> bluezone: Assuming single-user systems, etc.
<bluezone> that's true
<infinity> bluezone: The point is that, in a distro channel, saying "don't use the distro-packaged software" isn't the most helpful of things.
<infinity> bluezone: If you can offer constructive criticism, bugs are welcome.  If it's just a "distros suck, use upstream" opinion, I'm not entirely sure this is the best place for that.
<p0s> infinity: this part of the apt-cache output? "Original-Maintainer: Debian Orbital Alignment Team <pkg-java-maintainers@lists.alioth.debian.org>"
<infinity> p0s: Aye, or the Uploaders, but I guess that doesn't make it into the binary package, only the source package.
<infinity> p0s: But that mailing list would be a good start.
<p0s> infinity: and given that debian has a very slow release cycle, it is unlikely for them to update it to the latest version any soon, right?
<infinity> p0s: Nah, we pull from unstable, so if they updated unstable, we'd get that for "free".
<p0s> infinity: i had to distupgrade because the previous ubuntu version which i was on isn't supported anymore, and now i ran into this https://bugs.launchpad.net/eclipse/+bug/1241101  ... it breaks my complex development environment, and i work for a donation funded organization, and i don't feel like billing them hundreds of euros for me to manually re-setup eclipse to a downloaded version.... and i feel like given that 113 people are affected by this
<ubottu> Ubuntu bug 1241101 in gtk+2.0 (Ubuntu) "Java crash in libglib-2.0 after upgrade from 13.04 to 13.10" [High,Triaged]
<p0s> bug and 11 duplicates have already been filed, it is rather very questionable why ubuntu still ships an eclipse version from 2012...
<infinity> p0s: I suspect there's a #debian-java channel on freenode where those sorts of people might hang out.
<p0s> infinity: so i am considering to bribe someone to update the eclipse package...
<infinity> p0s: Have you tried upgrading to 14.04 and same issue?  13.10 is EOL in a month.
<infinity> Whereas 14.04 is supported for 5 years.
<p0s> infinity: yes, i am on 14.04
<infinity> p0s: Kay, didn't read the bug yet, just the title. :P
<p0s> infinity: i also tried ALL workarounds in the launchpad bugtracker entry, in the eclipse bugtracker entry and in the KDE one... only thing left to try is the latest version, which someone recently said in the launchpad entry fixes the issue
<p0s> infinity: #debian-java redirecty to ##debian-java which is empty
<infinity> Oh, annoying.  That was just a guess. :P
<infinity> p0s: So, if it's an issue with menuproxy, that's Ubuntu-specific, but if you say disabling all of that still breaks it, certainly mailing the debian java packaging list and/or debian-java@debian.org and asking about newer versions might not go amiss.
<infinity> p0s: If the new upstream *does* fix it, perhaps someone can find the commits that fix it and backport to 14.04
<p0s> infinity: people of all kinds of different distributions have said they suffer the same issue
<p0s> infinity: i will try the debian list then if nobody in the ubuntu bugtracker responds
<infinity> p0s: Well, a fair two-pronged approach regardless.
<infinity> jamespage: Do we have anyone who cares about eclipse in Ubuntu?
<p0s> infinity: i really feel like nagging everyone this time because it stops me from working :|
<p0s> infinity: it crashes like every 10 minutes
 * bluezone rests his case
<infinity> p0s: Probably worth trying the upstream non-package to see if you can reproduce the crash, as a useful data point.  That bug log is a mess, and probably several different bugs, so it's hard to say if one person saying it's fixed means much for others.
<psusi> cjwatson, hah, cool.. upstream git guys were able to reproduce and fix the git rebase --skip bug... seems it happens any time you have two consecutive conflicting patches
<p0s> infinity: i will probably end up having to try the latest, yes. nevertheless i will idle here overnight, waiting for you or jamespage to figure out whether ubuntu has an eclipse maintainer...
<pitti> Good morning
<darkxst> pitti, hi
<pitti> hey darkxst, how are you?
<darkxst> pitti, good, apart from all the rain!!!!
<pitti> darkxst: heh, I wish we'd get some again :)
<darkxst> we have plenty! I will send you some ;)
<darkxst> pitti, do you know if its possible to pass through environment variables to schroot hooks, when using sbuild?
<pitti> darkxst: I'm not aware of anything except --preserve-environment
<darkxst> only want 1 variable not everything!
<dholbach> good morning
<pitti> ogra_, cjwatson: are "live" and "desktop" just cruft in ubuntu-touch.utopic? touch, desktop, and live all have langpack sets, but I suppose I only actually need to change "touch"?
<didrocks> pitti: from what I can remember, yeah, only touch counts
<pitti> bonjour didrocks
<pitti> didrocks: merci
<didrocks> Guten Morgen pitti :)
<zyga> good morning :-)
<didrocks> hey zyga
<pitti> didrocks: so I can "bzr branch lp:ubuntu-system-settings", add the langpack flag, debcommit -r (for tagging), and dput?
<didrocks> pitti: exactly :)
<didrocks> it was designed for that ;)
<pitti> didrocks: nice! I'll start with that as it has the most translations in that list
<pitti> didrocks: there will be some days when system-settings becomes untranslated, until it appears in the LP exports
<pitti> but I set up the cron jobs, etc.
<michagogo> 5:54:24 <infinity> bluezone: The point is that, in a distro channel, saying "don't use the distro-packaged software" isn't the most helpful of things.
<michagogo> Well, there are some exceptions to that
<michagogo> For example, 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
<ogra_> pitti, no, they are the base of desktop-next
<ogra_> if you do changes in touch please do them in desktop too
<didrocks> oh, Laney reput them on the touch seed instead of creating a new one after all? (I remember that was under discussion)
<pitti> ogra_: ah, I see; so replacing hte langpacks with language-pack-touch-* should only be done in "touch"
<ogra_> pitti, why ? i guess we want the desktop translated too ?
<pitti> ogra_: FYI, I put the toucuh langpacks on another diet by dropping unimportant translations, that halved their size again (35 MB for  28 languages)
<ogra_> whee !
<ogra_> you rock !
<pitti> ogra_: right, but desktop-next should use the full langpacks, not just the touch ones?
<ogra_> not sure ... will they have the same translations ?
<ogra_> (plus extra cruft)
<pitti> ogra_: well, "extra cruft" == "translations for all packages in main", but they of course *also* have the phone/touch packs
<pitti> err s/packs$/translations/
<ogra_> well, then it is up to Laney to decide i guess ... image size is his authority for that flavour
<ogra_> leave them for now and he can decide
<pitti> ogra_: I won't change it today yet anyway; first we need to rebuild these ~ 20 projects with the langpack control flag so that the langpacks will make actual sense :)
<ogra_> yeah, i saw the dsicussion
<pitti> doing that now for system-settings to have a guinea pig (these are also the biggest ones)
<pitti> ogra_: I'll file a block-proposed bug so that the untranslated rebuilds stays in -proposed until wednesday when we'll get a new LP translation export with the system-settings translations
<ogra_> ++
<pitti> bug 1330360 FYI
<ubottu> bug 1330360 in ubuntu-system-settings (Ubuntu) "mark for language pack use" [Undecided,Fix committed] https://launchpad.net/bugs/1330360
<pitti> didrocks: argh! I can't push to https://code.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk
<pitti> "You cannot upload to this branch. Members of Ubuntu Touch System Settings can upload to this branch. "
 * pitti moves to dialer-app instead
<didrocks> pitti: something you should, but sometimes, upstream changed team after we setup the CI system and drop commit access. Not sure for that one
<pitti> ok, dialer-app pushed and uploaded
<smb> stgraber, Hi morning. I was looking at my ppu list this morning and think I only got rights on virt for utopic. Somewhat having those for P, S, and T would be helpful. Were those omitted intentionally or just an oversight?
<Noskcaj> dholbach, How can i try and prevent conflicts in my merges? They all seem to be random upstream files
<dholbach> Noskcaj, it might be just a matter of unapplying d/patches before committing?
<Noskcaj> I try to have the same ones applied as when i branched it
<Noskcaj> should i just have none applied in future?
<dholbach> Noskcaj, it's the only thing I can imagine going wrong to cause conflicts
<dholbach> try it out :)
<Noskcaj> ok
<darkxst> Noskcaj, do you see a bunch of .pc/* files in the conflicts?
<Noskcaj> darkxst, just a random file (not .pc), it happens a bit
<Noskcaj> dholbach, The patches are all dropped
<darkxst> Noskcaj, some branches has patches applied, and some don't
<Noskcaj> I think my cheese merge will need a patch de-commited now
<dholbach> Noskcaj, the following will result in text conflicts: bzr branch ubuntu:gtkspell3; cd gtkspell3; bzr merge lp:~noskcaj/ubuntu/utopic/gtkspell3/3.0.6
<dholbach> Noskcaj, even if I    quilt pop -a; bzr commit -m "unapply patches"   before the merge
<seb128> shrug
<Noskcaj> dholbach, strange
<seb128> dholbach, Noskcaj: that cheese update uses CSD, it should be reverted to 3.10
<Noskcaj> I've no idea how to fix that
<Noskcaj> seb128, I'll leave it broken then
<Noskcaj> (my merge, not cheese itself)
<seb128> hum, Laney updated it
<darkxst> Laney patched cheese
<seb128> Noskcaj, in fact it got patched, so ignore my comment
<Noskcaj> seb128, could you look at my libgweather merge? It's been sitting there for some timenow
<seb128> Noskcaj, not really, I've been skipping it because I don't know enough about the topic to know if the provider change is something we want
<Noskcaj> seb128, ok. I'd only assumed it was ok as it had been put in debian and darkxst had told me to merge it, so i don't know either
<seb128> Noskcaj, yeah, it's fine, ignore my comment ;-)
<dpm> hi pitti, I've just read your last message re: touch langpacks - do you have a new list of domains after further filtering? And does that imply that perhaps more languages are above the cut-off?
<pitti> dpm: yes, it's now 28 languages with >= 70%
<pitti> dpm: the packs are now ridiculously small, we really need to do these X-Use-Langpacks thingies to make them useful
<pitti> dpm: basically just colord, webbrowser-app, lightdm, unity
<pitti> although, hmm, that sounds like a bug; e. g. apport should be there, too
<dpm> pitti, ok, great.
<dpm> pitti, what about the indicators? And why is colord there?
<pitti> dpm: I'm still working on this, and I uploaded dialer-app to get its translations imported/exported
<dpm> ack
<pitti> dpm: colord has prio 7000
<dpm> oh, really? I should fix that
<pitti> dpm: argh, I know what happened, it just downloaded the current update tarball
<pitti> locally I built with the base tarball
 * pitti rebuilds
<pitti> dpm: so in my local builds it shrank by 1/2 and lost some 20 domains; hang on, I'll build you an updated list
<dpm> pitti, ok, cool. Shall we request a full export in LP for the next langpack?
<pitti> dpm: not necessary
<dpm> ok
<pitti> dpm: stats: http://paste.ubuntu.com/7652243/
<pitti> dpm: ca is at 68% almost over the limit :) (but we can also slightly lower the treshold)
<pitti> dpm: domains for -es: http://paste.ubuntu.com/7652244/
<pitti> dpm: so e. g. gdb is gone, and glib
<pitti> dpm: gtk20-properties.po really ougth to be lower these days too?
<pitti> dpm: can you move that from 7400 to perhaps 1000?
<pitti> dpm: and in turn, bump gtk30-properties?
<dpm> ok
<dpm> pitti, done
<seb128> dpm, pitti: gtk2 is still used in e.g firefox or libreoffice, so it shouldn't be ranked too low
<pitti> seb128: we use neither on touch, though?
<seb128> pitti, is the ranking specific to touch?
<pitti> seb128: btw, it's not gtk2 itself, just gtk20-properties
<seb128> k
<pitti> seb128: no, it's not; but it's still an obsolete version, so translators shouldn't translate that before gtk30-properties
<seb128> right
<bluesabre> mdeslaur, infinity: is there anything that needs to be done to move these bugs to trusty-updates?
<seb128> well, as long as it's still mark as "useful to translate"
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1326741
<ubottu> Ubuntu bug 1326741 in light-locker-settings (Ubuntu Trusty) "[SRU] Please backport light-locker-settings 1.2.1-0ubuntu2 to trusty" [Undecided,In progress]
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1326740
<ubottu> Ubuntu bug 1326740 in xfce4-power-manager (Ubuntu Trusty) "[SRU] Please backport xfce4-power-manager 1.2.0-3ubuntu6 to trusty" [Undecided,In progress]
<dpm> pitti, I've also lowered the priority of libgweather-locations
<pitti> dpm: exiv2 is huge and can also be lowered IMHO; it has tons of not-really-translated camera models, hmm
<dpm> seb128, yeah, that won't make it go away
<pitti> dpm: oh, but we still want that on touch, I figure?
<dpm> pitti, you mean that we want exiv2 in touch? I know gallery depends on it, but I'm not sure we show any translations for camera models in the UI
<seb128> bluesabre, they are in the SRU unapproved queue (https://launchpad.net/ubuntu/trusty/+queue?queue_state=1)
<pitti> it's not like they'd actually get translated :)
<pitti> msgid "EOS Rebel T2i / 550D / Kiss X4"
<pitti> msgstr "EOS Rebel T2i / 550D / Kiss X4"
<seb128> somebody from the SRU team needs to review/accept them
<pitti> dpm: but anyway, this file also has a lot of (what looks like) human visible strings
<pitti> dpm: I'm not sure whether it actually does display any string from the library, or just has its own
<dpm> pitti, let me ask nerochiaro. I've seen exiv2 being used in camera and gallery, but my hunch is that we don't display any strings
<dpm> pitti, it seems we only use exiv2 to read metadata
<pitti> dpm: ok, thanks; so it seems we can trim these packags quite some more :)
<pitti> exiv2 is 700 kB alone per language
<pitti> dpm: anyway, uploading fixed langpacks now
<pitti> dpm: actually, I think I do want a -base refresh soon, so that I can remove the really badly translated desktop langpacks
 * pitti requests
<dpm> ok, I see you were quicker than I :)
<dpm> pitti, which priority value are you using?
<pitti> dpm: 1500
<pitti> dpm: I made a few experiments this morning, and between 1500 and 2000 was already stuff that we want
<dpm> ok, cool
<pitti> dpm: ok, and on Wednesday the packs hopefully contain dialer-app :)
<dpm> cool :)
<mapreri> sil2100: ping
<sil2100> mapreri: pong
<mapreri> sil2100: here https://bugs.debian.org/750148 you stated that you want to package lucene++ for debian. That mean I can change the bug to an ITP and set you as owner? (I'm doing a wnpp cleanup)
<ubottu> Debian bug 750148 in wnpp "RFP: liblucene++ -- Shared library for Lucene++" [Wishlist,Open]
<dpm> pitti, I've made some notes on the list of domains. I think we should still be able to further filter out, but we'd be reaching the limits of priority-based filtering, as we cannot just lower down the priority of all the packages without affecting the desktop priorities too. I think what we've got now might be a good start and we can look at more filtering on the next ones. Perhaps filtering on priority + a static blacklist might be an option? In any ca
<dpm> se, here is the list of current domains you gave me, with the comments: http://pad.ubuntu.com/touch-domains
<sil2100> mapreri: sure :) I might even do some work today for that one
<mapreri> sil2100: good. The persone who report that bug made a gread "disaster" (a RFS bug for every binary package -.-)
<sil2100> mapreri: yeah, I saw that, but then I saw that someone renamed the lucene++0 one to lucene++
<pitti> dpm: thanks; I'm afraid I can't immediately answer most of these, but we should also consider their size; i. e. it doesn't make much sense to carefully maintain blacklists for 5 kB files, but for things like exiv and gtk[23]0-properties that's certainly worth it
<sil2100> So I decided to comment on that particular one
<mapreri> sil2100: he reneamed from liblucene++0 to liblucene++, I'm going to rename it again to lucene++.... Anayway good choice.
<sil2100> mapreri: ah, ok, I missed that one... thanks for working on that!
<dpm> pitti, yeah, I agree, but I'm more concerned about domains that are generally not translated affecting the stats and thus the languages included in the langpacks than the size per se
<dpm> e.g. as exiv2
<pitti> dpm: ah, right
<pitti> ogra_: I uninstalled German langpacks on my phone, verified that indicators and some other things are untransalted, installed language-pack-touch-de, and all back to normal
<ogra_> cool !
<pitti> ogra_: hence I'd like to commit http://paste.ubuntu.com/7652390/ ; can I just do that or does that need an MP? also, do I need anything else?
<pitti> ogra_: (except for the obvious double *, fixed locally already)
<ogra_> pitti, just go ahead ... we usually dont do MPs for seed changes since you need to manually update -meta anyway
<pitti> ogra_: right, I'll do that afterwards
<ogra_> pitti, we probably want to only have langpacks for the langs we have keyboards for ...
<ogra_> (just strikes me ... )
<pitti> ogra_: well, don't we use some IM for e. g. Chinese?
<pitti> I had assumed they'd use an English keyboard with some IM on top
<ogra_> might be, not sure
<pitti> ah, ubuntu-keyboard-chinese-pinyin
<ogra_> ubuntu-keyboard-chinese-pinyin
<smb> apw, Can you remember whether you sponsored drbd8 for precise for me (well actually whether only the *12.04.2 or *12.04.3 combined). Somehow the pending sru report oddly shows the bug addressed in the combined one but it seems only the initial version was uploaded
<ogra_> ah, you beat me :)
<pitti> ogra_: so, I'm fine either way; we can always adjust it further, of course
<ogra_> we can seed them all for now ... but i think in the end we should tie them to kbd layouts
<pitti> ogra_: languages where we have langpacks, but no keyboard, FYI: Greek, Gaelic, Galician, Indonesian, Japanese, Latvian, Norwegian, Slovenian, Serbian, Ukrainian
<pitti> ogra_: many of those can be done on an English or Russian keyboard, but certain not e. g. Greek
<ogra_> right, some of these might prefer english kbds ...
<pitti> or Japanese
<ogra_> iirc greek people usually use english
<ogra_> not sure about others
<pitti> well, you wouldn't have Greek letters anywhere?
<pitti> ogra_: well, I'll upload that for now; it already shrinks from 135 MB -> 32 MB, and with dpm's priority adjustments even more
<ogra_> awesome
<pitti> but indeed it's also a presentation matter, i. e. we might not offer some languages like Greek if you can't type them
<ogra_> right, or we might just want to create kbd layouts for them
<ogra_> i dont think it matters in tteh short term for now
<dpm> pitti, awesome. Could we upload the 'ca' one for me to test it too?
<pitti> dpm: how do you mean?
<pitti> dpm: I uploaded all of them to utopic, and currently adjusting the touch seeds
<pitti> (done)
<pitti> dpm: ah no, -ca; sorry :)
<dpm> pitti, yeah it didn't seem to make the cut-off
<dpm> although the phone is very well translated
<apw> smb, i cannot rembmer at all :)  but it is the sort of thing we would do together
<pitti> dpm: http://people.canonical.com/~pitti/tmp/langpack-touch/
<smb> apw, Yeah, unfortunately I see a bit of confusing data on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<smb> apw, Somehow .2 waits for verification and would be good if not somehow having the second bug referenced which cannot e verified with that version
<dpm> pitti, awesome, thanks
<apw> smb, seems i didn't sponsor either of them
<pitti> dpm: I started with http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/revision/478
<pitti> dpm: maybe that's already enough to bring it over the hump :)
<dpm> pitti, ah, nice, thanks :)
<dpm> I think exiv2 will be the one to make the difference, yes
<pitti>   caribou 5883 (90%)
<pitti> WTF
<pitti> dpm: "ca  5883 (90%)" :)
<pitti> caribou: sorry, I was pasting ca<tab>
<dpm> :)
<dpm> (yay!)
<pitti> dpm: so, I'll build fresh ones on Wednesday, with (hopefully) dialer-app
<dpm> sounds great, thanks a lot
<smb> Ok, looks that actually the drbd8 package uploaded is a merged version from what I had prepared (including my .2 and .3 and merging the changelog).
<Laney> doko: know about this ld segfault? http://paste.ubuntu.com/7652533/
<caribou> pitti: no worry
<caribou> pitti: there's a package called caribou as well
<Laney> doko: (filed #1330451)
<doko> Laney, do you build with these malloc settings by default?
<Laney> comes from the test harness somewhere
<doko> "the"?
<Laney> in glib
<Laney> which uses automake's AFAIK
<Laney> doko: ah no, glib sets it itself
<Laney> still ld, shouldn't crash
<Laney> (that comma slipped across one word)
<LocutusOfBorg1> sil2100, sorry I read some news about lucene++ but I joined the chan when you said the last reply
<LocutusOfBorg1> any progress on debian side?
<LocutusOfBorg1> :)
<sil2100> LocutusOfBorg1: hi! Will make some progress today, in the morning we only had some paper-work discussion
<LocutusOfBorg1> ah ok :)
<LocutusOfBorg1> I read just a few words when I joined today
<cjwatson> doko: does https://launchpad.net/ubuntu/+source/sogo/2.2.5-1/+build/6081133 make any sense to you?  is gobjc just entirely broken right now or something?
<doko> cjwatson, I assume this is the 4.8/4.9 version mismatch ... so once we default to 4.9 again, that should go away. couldn't reach tvoss today, but this should be done today or tomorrow
<tvoss> doko, ping
<doko> tvoss, yes ...
<tvoss> doko, around. MR'd the dbus-cpp change, checked on process-cpp
<doko> "MR"?
<tvoss> merge request
<doko> tvoss, including the versioned b-d?
<tvoss> doko, yeah, I added g++ (>= 4.9). Is that correct?
<smb> Ok, I did a quick verification of the missing part (second bug number) for the drbd8 backport in precise-proposed. So sooner or later it should move to updates anyway. But if someone could do it sooner, I think people currently broken will appreciate.
<doko> tvoss, no
<tvoss> doko, what is the correct version line, then? g++-4.9?
<LocutusOfBorg1> can anybody please point me to the libav transition tracker?
<LocutusOfBorg1> I uploaded hedgewars in debian, I would like to track the ubuntu sync, to make sure it doesn't fail to build somewhere
<doko> tvoss, g++ (>= 4:4.9.0-3ubuntu6)
<mantiena-baltix> Hi, maybe someone could sync new meld package from Debian experimental - current meld package in Ubuntu Utopic is completely broken, see LP bug #1298266
<ubottu> Launchpad bug 1298266 in meld (Ubuntu) "Meld 3.11.0 completely broken - please sync meld 3.11.1-1 from Debian experimental" [Undecided,Confirmed] https://launchpad.net/bugs/1298266
<seb128> you should subscribe ubuntu-sponsors to the sync request
<LocutusOfBorg1> done
<mantiena-baltix> seb128: thanks\
<seb128> yw!
<doko> tvoss, please let me know when you are done
<tvoss> doko, updated: https://code.launchpad.net/~thomas-voss/dbus-cpp/bump-so-name-and-major-version/+merge/223224
<pitti> xnox: hey Dimitri, how are you?
<pitti> xnox: I'm afraid I'm a bit behind: where do we stand wrt. startpar these days?
<shadeslayer> pitti: https://bugs.launchpad.net/debian/+source/abi-compliance-checker/+bug/1330481 < could you have a look at that
<ubottu> Ubuntu bug 1330481 in abi-compliance-checker (Ubuntu) "dh-acc should depend on debhelper" [Undecided,New]
<pitti> shadeslayer: yes, that makes sense; let's see what the Debian maintainer says?
<pitti> otherwise it'll need to become a test dep
<shadeslayer> pitti: haven't heard back from the debian maintainer in forever
<stgraber> smb: it takes a bit of work to copy the packagesets to old series and grant matching rights to it so we don't do that by default. Can you e-mail devel-permissions about it? (I'm off today and about to leave now)
<smb> stgraber, ack. thanks
<brendand> what's the command to delete a chroot? or is it done some other way?
<pitti> brendand: is that schroot, or plain chroot?
<pitti> brendand: with a plain chroot, just rm -rf; but make double sure that you unmount all bind mounts before :)
<brendand> pitti, well i'm using schroot
<pitti> brendand: "sudo schroot -e --all-sessions" is quite useful for cleaning up a pile of leftovers
<pitti> brendand: otherwise, sudo schroot -e -c <session name>
<pitti> -e == --end-session
<cjwatson> brendand,mvo: https://code.launchpad.net/~cjwatson/cupstream2distro-config/click-tests/+merge/223240 - flying a bit blind so hopefully not totally broken
<brendand> pitti, --list still shows things though
<mantiena-baltix> Hi again, gnome-main-menu package isn't synced from Debian, see http://packages.qa.debian.org/g/gnome-main-menu.html and https://launchpad.net/ubuntu/+source/gnome-main-menu
<pitti> brendand: you mean --list --all-sessions ?
<pitti> brendand: oh wait, this is for removing sessions, not the underlying chroot, sorry
<cjwatson> brendand: end all sessions, check nothing's mounted from that chroot, then "rm -rf --one-file-system" the chroot files in /var/lib/schroot/chroots/ and the configuration file in /etc/schroot/chroot.d/
<brendand> cjwatson, i'll get fginther to have a look at it. he's the expert
<cjwatson> brendand: ta
<pitti> brendand: end all sessions for it, then rm -rf the directory (or tarball), and remove the config in /etc/schroot/chroot.d/
<cjwatson> brendand: where would this actually end up?  https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/ClickPackage/ doesn't look current
<mantiena-baltix> It seems this is because gnome-main-menu was removed from Ubuntu at ~11.10, but now this package is actively maintained by mate team. Should I report a bug and subscribe ubuntu-sponsors to that bug?
<brendand> cjwatson, s-jenkins
<mitya57> mantiena-baltix: See http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<mitya57> You should probably contact pitti (or release team) to get it removed from blacklist.
<mitya57> Better release team, I think.
<cjwatson> no, archive team.  file bug with rationale, subscribe ubuntu-archive
<cjwatson> brendand: ah, I guess https://jenkins.qa.ubuntu.com/view/Utopic/view/All/ is the public one
<cjwatson> brendand: (digging through private jenkins instances is a pain and not community-friendly so I try not to if I can avoid it)
<brendand> cjwatson yeah
<cjwatson> https://jenkins.qa.ubuntu.com/view/Utopic/view/All/job/url-dispatcher-utopic-amd64-ci/ seems to be an example with coverage
<fginther> brendand, what am I the export for?
<fginther> hmmm, that should have been expert. I'm not sure I can export anything useful
<brendand> fginther, that's funny. i almost mispelled it 'export' myself
<brendand> fginther, cupstream2distro
<brendand> fginther, cjwatson just submitted an MP to have a job for click
<fginther> brendand, I'm checking that out now. does the build already create a coverage.xml file?
<brendand> fginther, yes it should
<fginther> cool
<doko> Laney, the ld issue is known upstream. should be fixed with the next upload
<Laney> doko: ok, do you know when?
<Laney> any chance of a cherry-pick?
<Laney> can't build glib until it's fixed
<doko> there seem to be many cherries to pick ...
 * Laney is trying a build with some tasty looking cherries right now as it happens
<ogra_> yum, cherrres
<ogra_> *cherries
<Laney> tee: ../binutils_2.24.51.20140612-0ubuntu2_amd64.build: No space left on device
<Laney> bad cherry :(
<mantiena-baltix> cjwatson: against which ubuntu package/component I should report bug about missing gnome-main-menu?
<cjwatson> mantiena-baltix: you can just report it against gnome-main-menu even though that's been removed; it doesn't matter as long as ubuntu-archive is subscribed
<mantiena-baltix> Is this bug correctly reported? LP Bug #1330500
<ubottu> Launchpad bug 1330500 in gnome-main-menu (Ubuntu) "Please sync gnome-main-menu from Debian (remove from sync-blacklist.txt) - it's actively maintained by MATE team now" [Undecided,New] https://launchpad.net/bugs/1330500
<jdstrand> @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: jdstrand
<Laney> doko: I took c72f2fb2bb6a3e1850b081dbfce4040970fae8e6^..d495ab0d843def702a6641fa4fc31708d7fc97b1 and it doesn't segfault on that example now
<doko> Laney, can you upload? not sure if I will make it today. there is one more ARM issue I'd like to look at
<Laney> doko: well I want to fix glib in experimental too, not sure I'm brave enough to upload binutils there :)
<doko> well, then please wait a day
<Laney> I can wait for your next snapshot
<doko> ok
<Laney> it at least confirms that this issue should be fixed with that
<mitya57> Noskcaj: Your jquery and jquery-goodies uploads dep-wait on node-uglify (which is not in main, because we don't want nodejs in main)
<mitya57> Hm, no, jquery-goodies is not your upload, it was autosynced. But anyway, please fix jquery (and add back recommends on javascript-common).
<cjwatson> manjo: yes
<cjwatson> manjo: sorry
<manjo> cjohnston, no worries
<cjwatson> ha, touchÃ©
<manjo> cjwatson, ^ ooops
<Laney> haha
<cjwatson> mantiena-baltix left apparently
<ogra_> lol
<LocutusOfBorg1> LOLOLOL
<LocutusOfBorg1> please loook at this bug report
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/boinc/+bug/1330507
<ubottu> Ubuntu bug 1330507 in boinc (Ubuntu) "QCN sensor graphcis crashes on sleep" [Undecided,Invalid]
<LocutusOfBorg1> how the fuck they report windows bugs on launchpad?
<rbasak> LocutusOfBorg1: you could be more polite. What if boinc hosted their upstream bug tracker on Launchpad, for example? Then it would only be a minor error.
<rbasak> LocutusOfBorg1: maybe point the reporter to http://boinc.berkeley.edu/trac/?
<LocutusOfBorg1> reload the page
<LocutusOfBorg1> :)
<LocutusOfBorg1> I already did this
<LocutusOfBorg1> I was writing
<rbasak> Thanks
<LocutusOfBorg1> no, boinc doesn't use lp as upstream bug tracker
<LocutusOfBorg1> I just replied with the "seriously", but I was already writing the correct answer :D
<seb128> sil2100, tvoss: net-cpp fails to build on ppc with a test failure, is that something being worked?
<sil2100> !
<tvoss> seb128, got a build log for me?
<seb128> tvoss, sil2100: https://launchpadlibrarian.net/177394289/buildlog_ubuntu-utopic-powerpc.net-cpp_0.0.1%2B14.10.20140611-0ubuntu1_FAILEDTOBUILD.txt.gz
<sil2100> seb128: ok, I need to apologise for this one, it seems that citrain does not inform of such failures in case of NEW packages (as it has no 'archs available' from the archive)
<sil2100> seb128: so it slipped my eyes completely :|
<seb128> sil2100, no worry
<sil2100> seb128: I was unaware it failed for ppc...
<sil2100> I remember the unit tests had some issues once in net-cpp, not being entirely reliable, but I wonder if it's the same thing still
<seb128> sil2100, tvoss: source package looks good for NEW, I'm going to accept it, but please look at/fix the ppc build
<sil2100> seb128: thank you! And sorry for missing this one out
<seb128> that happens, no worry
<p0s> did you guys find out where you have an eclipse maintainer? :)
<dobey> p0s: if eclipse is in the archive, then information about who maintains it, is also in the archive
<p0s> dobey: where is that?
<dobey> pbn: "apt-cache show eclipse"
<p0s> dobey: yea someone suggested that already, only results in mailing lists (Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> / Original-Maintainer: Debian Orbital Alignment Team <pkg-java-maintainers@lists.alioth.debian.org>)
<dobey> so what is the problem? that seems pretty clear to me
<p0s> dobey: well i was hoping to find someone which could talk to live on IRC
<dobey> you should mail the debian java maintainers list probably. there are no changes in ubuntu to eclipse. we are just including the package from debian right now
<p0s> dobey: the problem is that its unusably broken and someone needs to update it to the latest version available, and i wonder whether debian will do that, being a conservative distro...
<p0s> dobey: i might try my luck in the debian channel though :|
<dobey> p0s: i would hardly call debian conservative
<manjo> in d-i are proxy's setup done before NTP setup ?
<p0s> dobey: ok well thanks :)
<dobey> p0s: i'm sure the maintaienrs will appreciate help to get a newer version in if there is one; but it will only go into experimental/unstable at first. at some point can go to testing. but it's not likely to get updated in stable
<dobey> but once it's in unstable, you can ask for it to be synced to ubuntu, and it will be included in the archive for the next release of ubuntu
<p0s> dobey: well the version in ubuntu is from 2012, and the bug which breaks it has 114 people claim to be affected, which is something which i haven't seen in any other bug reports, so its rather very likely that it doesn't work for anyone...
<p0s> dobey: and there has been a new version in june 2013 which is claimed to fix the issue...
<dobey> p0s: well, i guess packaging of eclipse is also pretty complex, as upstream likes to do their own thing
<p0s> dobey: FYI https://bugs.launchpad.net/eclipse/+bug/1241101
<ubottu> Ubuntu bug 1241101 in gtk+2.0 (Ubuntu) "Java crash in libglib-2.0 after upgrade from 13.04 to 13.10" [High,Triaged]
<dobey> ok
<hallyn> is there a way for me to kill ppa builds (that i know will time out eventually) msyelf?
<infinity> hallyn: Do you not have a cancel button on your builds?
<hallyn> infinity: d'oh.  not if i dont' log in...  thx
<infinity> hallyn: We can change the permissions to anonymous users can kill any build owned by you (and only you), if that makes your life easier. :P
<infinity> s/to/so/
<hallyn> i miss the innocent internet
<infinity> Yeah, 1993 was a good year.
<infinity> Well, I guess 1992.  It all went to hell in a handbasket in 1993.
<xnox> pitti: latest status from UOS was to make blueprint to start tracking stuff properly.
<xnox> startpar is not enabled yet, still had a few packages to fix / upload.
<xnox> don't like the task patch, thus want to enable without startpar learning about tasks
<tedg> xnox, What was the PPA you gave me for upstart with cgroups?
<dobey> hmm
<tedg> xnox, slangasek, using the daily upstart PPA it seems that my phone/emulator don't finish boot. Is that known or should I investigate enough to file a bug?
<slangasek> tedg: I don't know anything about it; most of the time all I see of the daily upstart PPA is build failures.  Please investigate :)
<tedg> Heh, okay. Was hoping for a different answer ;-)
<infinity> tedg: The pheasant has no agenda.
<infinity> rcj: That open-vm-tools-lts-trusty in precise-proposed looks suspect to me.
<infinity> rcj: You can't both have a transitional package *and* have the package it's transitioning to conflict/provide that same package.
<infinity> rcj: Erm.  By which I mean open-vm-tools in trusty-proposed.
<hallyn> infinity: say would it be possible to get a process listing on  chindi06 where a ppa build is hanging?
<infinity> rcj: What you want here is "foo-lts-trusty, Depends: foo" and "foo, Breaks/Replaces: foo-lts-trusty (<< transitional version)"
<infinity> hallyn: Nope.
<hallyn> infinity: drat.  thanks.  will just keep bisecting then
<rcj> infinity, okay.  I'll correct it.
<infinity> rcj: Did that make sense?
 * infinity goes for lunch.
<rcj> infinity, it did make sense
<tedg> slangasek, I filled bug 1330692, went to the end of my understanding. Hope it helps some :-)
<ubottu> bug 1330692 in upstart "Upstart nightly doesn't boot Ubuntu Touch" [Undecided,New] https://launchpad.net/bugs/1330692
<brentwal1her> How do new versions of packages become updated in the repositories?
<brentwal1her> I'm curious because the i3 package is behind many versions and the maintainer is "Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>"
<sarnold> brentwal1her: it depends if the package needs a sync or a merge -- a sync is just a copy from debian, a merge is needed if there are ubuntu-local changes to the package
<sarnold> brentwal1her: this is a useful place to start learning about it: https://wiki.ubuntu.com/SyncRequestProcess
<brentwal1her> Thank you sarnold
<cjwatson> In this case it's in sync with Debian, and the version of i3 in utopic was updated yesterday to the latest version from upstream.
<cjwatson> We don't normally update stable releases to new upstream versions, only cherry-pick important bug fixes as needed.
<cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates describes that process.
#ubuntu-devel 2014-06-17
<xnox> tedg: it does boot here. Is that x86 or armhf? which rev # & channel?
<xnox> (well it did, whenever i last re-initialised emulators locally ~ friday)
<xnox> i guess i didn't catch pitti.
<rcj> infinity, you said 'What you want here is "foo-lts-trusty, Depends: foo" and "foo, Breaks/Replaces: foo-lts-trusty (<< transitional version)"'
<rcj> infinity, for the other transitional packages they have Conflicts/Replaces rather than Breaks/Replaces and only the conflicts limits the package by providing the transitional version number.
<rcj> Not sure what is needed.
<infinity> rcj: Which "other transitional packages"?
<infinity> rcj: The proper way to do file overwrites is a versioned Breaks/Replaces.  It used to be a versions Conflicts/Replaces many years ago, and some people are resistant to change. :P
<rcj> infinity, okay.  The open-vm-tools package had a open-vm-dkms transitional package when I picked it up.
<rcj> infinity, and the breaks and replaces both will specify the version, correct?
<infinity> rcj: Yeahp.
<rcj> infinity, thank you.
<infinity> rcj: Yeah, ignore the ickiness of that old transitional package, it's a little goofy.
<rcj> infinity, I'll leave that alone as I add the new ones
<hamiltont> cjwatson: online?
<TheMuso> hamiltont: He is likely asleep atm, you may want to try in 5-6 hours if you are around.
<hamiltont> thanks! No rush
<pitti> Good morning
<pitti> xnox: thanks for the heads-up; I can't say I much like the startpar task patch either, I just really wonder why it doesn't work
<pitti> infinity: FYI, I see the bug with eglibc's autopkgtest failure, fixing now; sorry about that
<slangasek> hrm.  Why does 'dch -r' think the current target release is called 'the'?
<dholbach> good morning
<didrocks> hey dholbach!
<dholbach> salut didrocks
<pitti> hey dholbach
<pitti> bonjour didrocks
<dholbach> hey pitti
<dholbach> @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: dholbach, jdstrand
 * pitti hugs dholbach
<didrocks> Guten Morgen pitti :)
<pitti> dholbach: morning gymnastics^Wsponsoring, eh? :-)
<dholbach> yeah :-)
<pitti> does anyone know, where can I find a list of supported frameworks for a click's "framework" field?
<pitti> ah, found https://wiki.ubuntu.com/Click/Frameworks after some googling
<pitti> that still doesn't explain how they are related, i. e. if ubuntu-sdk-14.04-qml-dev1 is a subset or a superset of ubuntu-sdk-14.04
<pitti> cjwatson: how can I map a click framework name such as ubuntu-sdk-14.04-qml-dev1 to a set of packages that must be installed (like ubuntu-sdk-libs)? I don't see this in Provides: or the touch seeds
<pitti> cjwatson: or, I figure a click package's autopkgtest should perhaps just have the correct one in its test deps
<mapreri> pitti: what do you mean with "if pencil2d's programs/CLI is the same as pencil2d's?"
<pitti> mapreri: if pencil's programs are called the same way (option names, file formats, etc. -- I don't know what it is) as pencil2d's, then a transitional package makes sense
<pitti> mapreri: if it's something different, then we should just drop the pencil package
<pitti> mapreri: so in this case, as it's a GUI app, it's mainly about file format compatibility
<mapreri> pitti: pencil2d is the pencil fork. For now the interface is quite similar. The file format is the same, yes (as far as I can see they are moving to a new file format, but keeping backward-compatibility)
<pitti> mapreri: right, then making the pencil source build a transitional pacakge to pencil2d only makes sense to me
<mapreri> Withe commit like https://github.com/pencil2d/pencil/commit/23f40954299c77730e37b8e83bca0c2555035f27 but the old format is keep
<pitti> mapreri: note that you will also need some Breaks:/Replaces: on pencil2d
<pitti> mapreri: which you can do on the Debian side (htey are harmless there)
<mapreri> pitti: do you know of a way to have an ubuntu-specific control file on debian? (like the series.ubuntu for the patches)
<pitti> mapreri: in principle you could even add the transitional package to the Debian pencil2d source and only build that binary on Ubuntu; but it's a bit of a hack, and we can just keep the pencil source until the next LTS
<pitti> mapreri: no, that doesn't work; but you can do something like: if dpkg-vendor --is ubuntu; then export DH_OPTIONS=-Npencil
<pitti> mapreri: then the pencil transitional will only be built on Ubuntu, not on debian
<mapreri> uh, great. in the meantime I file a bug for the pencil removal
<pitti> mapreri: for conditional dependencies you could use substvars, but IMHO it's not worth the effort; having the Breaks/Replaces: on Debian is no big deal
<tvoss> cjwatson, doko seems like the symbols for std::once and std::once_callable have changed and libstdc++ has been updated in the archive to 4.9
<Mirv> it'd seem to me the new gcc-4.9 4.9.0-6ubuntu1 breaks phone
<Mirv> I mean 4.9.0-7ubuntu1. apt-get dist-upgrade + reboot from the morning's image (includes gcc + pulseaudio updates) gives me just google logo, downgrading to 4.9.0-6ubuntu1 and it works again
<doko> tvoss, is this using the package in -proposed?
<doko> Mirv, is this a runtime issue, or a build issue?
<tvoss> doko, I don't think so, -proposed is not enabled by default
<ogra_> tvoss, in silos it was accidentially disabled ... if that build is from a silo PPA you might want to re-try (all silo PPAs now use proposed by default again as they should)
<tvoss> thostr_, ^
<doko> tvoss, ARM only?
<Mirv> doko: this what I'm seeing is a runtime issue. everyone with a phone should be able to reproduce it by flashing the latest image and upgrading it to the latest gcc
<tvoss> doko, seems so
<tvoss> thostr_, is https://launchpadlibrarian.net/177744514/buildlog_ubuntu-utopic-armhf.unity-scope-click_0.1%2B14.10.20140616-0ubuntu1_FAILEDTOBUILD.txt.gz from a silo build?
<thostr_> tvoss: yes
<thostr_> can try to rebuild now however.. ogra_ when did you change the setting?
<doko> there is a binutils issue reported yesterday by Laney, which is fixed by the current upload. so please lets see wait for this build
<ogra_> thostr_, robru did last night (at least he was supposed to, i didnt check all silos) ... which silo was that i can take a look
<pitti> dpm: hm, do you know why https://translations.launchpad.net/ubuntu/utopic/+source/dialer-app is still empty? shouldn't that have the template from yesterday's upload?
<pitti> dpm: or does this again need to be approved?
<thostr_> ogra_: silo 18 that is
<pitti> dpm: oh indeed - https://translations.launchpad.net/ubuntu/utopic/+source/dialer-app/+imports -- can you hit the magic buttons there?
<ogra_> thostr_, has proposed on right now
<pitti> dpm: (I hope it will still make today's full LP export, otherwise we'll need to wait a week or so)
<ogra_> (i sadly cant tell *when* it was switched on)
<thostr_> ogra_: so, can I trigger a rebuild now?
<ogra_> yep
<thostr_> ogra_: building...
<Laney> doko: yay
<ogra_> :)
<Laney> did you upload it to sid too?
 * ogra_ crosses fingers
<dpm> pitti, argh, yes, every new template needs to be approved (just did that now). I had followed the conversation on ubuntu-phone, but I hadn't realized the upload had already happened
<dpm> pitti, let me chech when the export is scheduled to start
<doko> Laney, yes
<mapreri> pitti: like this? http://anonscm.debian.org/gitweb/?p=collab-maint/pencil2d.git;a=commitdiff;h=9620a0cf477847f221b9ee0bc1f9493bb4bfc4ed
<ogra_> sil2100, see above :)
<ogra_> (the translations, not my PPA conversation)
<dpm> pitti, so the export starts at 10:30 UTC today and we should be good to go
<pitti> dpm: *phew*, thanks :)
<cjwatson> pitti: use "click chroot -aARCH -fFRAMEWORK create" to create the chroot - it knows which packages are supposed to be used
<pitti> cjwatson: ah, thank you
<doko> tvoss, is this reproducible with the unity-scope-click package in utopic?
<cjwatson> pitti: not currently exported otherwise
<pitti> mapreri: "Ubuntu has had"
<tvoss> doko, best to ask thostr_
<mapreri> uh, right...
<pitti> mapreri: Replaces/Breaks versions need to be (<< version_of_transitional_package), not these old ones
<doko> thostr_, ^^^
<thostr_> doko: yes, IIRC
<tvoss> thostr_, could you share the respective MP that triggered the build failure in the silo?
<pitti> mapreri: also, the debian/changelog in that commit is a total mis-match
<pitti> mapreri: this is perhaps using git-dch and you forgot to revert, or something?
<mapreri> pitti: yes, the changelog isn't related, I commit it without thinking (commit -a -.-)
<thostr_> tvoss: for click that is https://code.launchpad.net/~dobey/unity-scope-click/merge-devel/+merge/223276
<pitti> mapreri: otherwise LGTM, but the B/R versions need fixing
<sil2100> ogra_: I must say I'm a bit confused with this
<seb128> ev, bdmurray: hey, https://errors.ubuntu.com/?package=unity8&period=year ... that seems buggy to me, is there a known issue? 1 unity8 report as a total over all releases seems too low?
<seb128> even with the db change, we for sure got more than 1 report of issue since
<ogra_> sil2100, the translation files are not exported yet by the app packages
<ogra_> so we might be missing more than just dialer atm
<seb128> tvoss, hey, do you know if that's a known issue? http://paste.ubuntu.com/7657512/
<tvoss> seb128, nope, haven't seen that before. ricmm ^
<seb128> tvoss, sorry, ricmm just replied on -touch, I asked there before noticing you were not on the channel
<tvoss> seb128, ah, xchat keeps on forgetting about my channels :(
<ogra_> doko, could it be that we get C++ issues with the new libgcc ?
<ogra_> i see several reports of phnes stopping working after upgrading only that package
<doko> ogra_, I think it's a libstdc++6 issue, but will have to confirm
<ogra_> oSoMoN, ^^
<doko> so just replacing libstdc++6 with the old one should be enough
<oSoMoN> ogra_, doko: upgrading libgcc1 triggers the upgrade of libstdc++6 too, so that sounds right
<tvoss> doko, the issue with the missing symbols for std::*once is reproducible with https://code.launchpad.net/~thomas-voss/dbus-cpp/bump-so-name-and-major-version/+merge/223224
<tvoss> too
<tvoss> doko, see https://jenkins.qa.ubuntu.com/job/dbus-cpp-utopic-armhf-ci/17/console
<Wellark> I'm also seeing these: https://launchpad.net/~ci-train-ppa-service/+archive/landing-002
<Wellark> libprocess-cpp in the archive is broken
<Wellark> or missing symbols that is
<ogra_> doko, looks like more fallout ^^
<tvoss> Wellark, it's not process-cpp missing symbols, but the underlying libstdc++
<Wellark> tvoss: well, sure. but my trail ends with process-cpp :)
<tvoss> Wellark, sure
<Wellark> but that would mean that the archive is broken..
<tvoss> Wellark, yup
<ogra_> one lib is ...
<dholbach> @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: jdstrand
<doko> tvoss, ogra_: do you have a fast arm machine for a build? I only have porter-armhf which is a slow dual core
<tvoss> doko, I'm building on the phone
<tvoss> doko, my chromebook is in use by the family
<ogra_> i use chroots since a while and my chromebook is collecting dust in the basement
<ogra_> (and on saucy or something, would need a few hours for updating etc)
<sil2100> dholbach: o/ just reminding about adding me for next month!
<ogra_> doko, if sil2100 has a spare silo you could use distro builders for that inside a silo PPA
<doko> no, havingPPA's myself
<sil2100> ogra_, doko: for such occassions we always have landing-000 PPA
<ogra_> doko, using HW builders ?
<cjwatson> ogra_: yes
<cjwatson> (~ubuntu-toolchain-r)
<ogra_> ah
<doko> Laney, new binutils in -proposed, can you recheck?
<Laney> ok
<Laney> doko: looking good so far
<Laney> doko: yep, worked
<Laney> ta
<doko> tvoss, ^^^so rechecking with the updated binutils would be good. still doesn't solve the libstdc++6 issue, my test build is however running
<tvoss> doko, ack. thostr_ could you kick a rebuild of your ppa? should get the new binutils from proposed
<shadeslayer> pitti: did you fix something with autopkgtest? :) seems like debhelper is being installed by default now
<pitti> shadeslayer: I fixed build-depends-indep: handling this morning; but this would have entirely crashed the test very early unless it happened to have a trailing comma
<pitti> shadeslayer: debhelper isn't installed by default
<pitti> shadeslayer: which test was that?
<shadeslayer> https://jenkins.qa.ubuntu.com/job/utopic-adt-killbots/2
<shadeslayer> https://jenkins.qa.ubuntu.com/job/utopic-adt-killbots/1 was the one that failed
<pitti> shadeslayer: that didn't fail due to debhelper, but UTF-8 in debian/control
<pitti> shadeslayer: I fixed that two days ago, and rolled it out this morning
<pitti> i. e. handling UTF-8 files under C locale (argh)
<shadeslayer> ah ok then
<jdstrand> @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:
<seb128> arges, hey, could you review the libgphoto SRU for trusty? it's a follow up to fix a typo in the current proposed version
<seb128> if somebody from the SRU team could also do copies to updates that would be nice
<seb128> some items at 13 days old and validated
<seb128> slangasek, bdmurray, infity, stgraber, ...: ^
 * cjwatson does a few
<seb128> cjwatson, thanks
<tvoss> doko, so the binutils change did not help. Seems like we need to rebuild process-cpp
<doko> tvoss, ?
<tvoss> doko, thostr_ tried rebuilding his silo with only the changed binutils from proposed
<doko> cjwatson, tvoss: now explicit deps on g++-4.9 ?
<cjwatson> doko: Yes, it gives them control over when to switch given that it appears they need to change SONAME at the same time
<cjwatson> doko: We've made it clear that it's not carte blanche to stay with old GCC versions
<cjwatson> It's just timing control
<doko> ok
<cjwatson> And limited to those cases where this control's actually needed - i.e. we know we're using experimental features
<shadeslayer> pitti: btw I don't suppose you know of any dep 3 parser
<shadeslayer> for patches
<arun_> hello guys !!! I am having some verification problem with reprepro thing !!!1
<Saviq> lool, hey, do you think you could package doxyqml 0.2.0 please https://github.com/agateau/doxyqml/releases ?
<Saviq> lool, you seem to be the maintainer :)
<lool> Saviq: hehe
<lool> Saviq: sure
<Saviq> lool, got a source built if you want it :)
<Saviq> lool, only change in packaging seems to be tests are split into unit and functional
<pitti> shadeslayer: no, I don't know of any
<arges> seb128: ok i'll look at libgphoto2
<seb128> arges, thanks
<pitti> thanks arges; sorry for the typo
<arges> : )
<doko> Laney, can I close 1328838?
<shadeslayer> pitti: thx
<Laney> bug 1328838
<ubottu> bug 1328838 in gcc-4.9 (Ubuntu) "Can't x-build ubuntu-system-settings with 1.0.4ubuntu1: /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'" [Undecided,New] https://launchpad.net/bugs/1328838
<Laney> doko: yep
<bdmurray> seb128: I don't know of any issue that would make the unity8 numbers low
<Laney> wait
<Laney> oh yes, since the revert
<Laney> yes
<bdmurray> seb128: looking at the old database the highest occurring crash over the year only has 43 occurrences
<doko> well, we need to keep these in sync for cross building
<Laney> yep
<Laney> you made that true again
<seb128> bdmurray, hum, ok, that seems weirdly low, seeing the number of mentions we get on IRC for example
<mlankhorst> darktama: it seems to be caused by the i2c support
<Laney> mlankhorst: !!!
<Laney> I forgot to try your thing
<Laney> do you still want me to?
<mlankhorst> oops wrong window :P
<mlankhorst> go for it, not sure how useful it is though
<bdmurray> seb128: "number of mentions we get on irc"?
<Laney> umm
<Laney> if not useful then I won't bother
<seb128> bdmurray, we have people mentioning unity8 crashes and reporting them
<seb128> bdmurray, I just wonder where they end up if not on e.u.c
<mlankhorst> Laney: yeah I did some fixes that went in the right direction, but threading's hard :P
<bdmurray> seb128: In utopic whoopsie now logs the OOPS ID of a reported crash in /var/log/syslog so we could ask for the OOPS ID and from them and figure it out.
<bdmurray> seb128: there is a pending SRU for that in Trusty too
<seb128> bdmurray, ok, thanks
<doko> cjwatson, so my gcc-4.9 test build is ok. can we copy the binaries from the ubuntu-toolchain-r/ppa PPA into -proposed once the i386 build finishes?
<doko> tvoss, thostr_, ogra_, Mirv: the ubuntu-toolchain-r/ppa PPA has a fixed gcc-4.9
<brendand> stgraber, why am i getting these errors? http://paste.ubuntu.com/7658715/
<thostr_> doko: so, ci should work now again?
<doko> it is not yet in -proposed
<stgraber> brendand: either because lxcbr0 doesn't exist or because your kernel somehow lacks veth support
<stgraber> brendand: the latter tends to happen when you haven't rebooted your machine in a while + flushed all kernels from disk as veth.ko is no longer there to be loaded
<brendand> stgraber, if lxcbr0 is supposed to be in ifconfig, then no i don't have it
<brendand> stgraber, i did delete a lot of kernels recently
<stgraber> brendand: ok, what LXC and Ubuntu version is that?
<brendand> stgraber, utopic
<stgraber> brendand: sudo status lxc-net
<brendand> stgraber, lxc-net start/running
<cjwatson> doko: Yes, should be fine, go for it
<tvoss> doko, what was the issue in the end?
<brendand> stgraber, version: 1.0.3-0ubuntu5build1
<stgraber> brendand: can you pastebin /var/log/upstart/lxc-net.log?
<stgraber> brendand: that version is a tiny bit old (I uploaded 1.0.4 last week) but that really shouldn't matter so we may as well figure out what happened before you upgrade
<brendand> stgraber, doesn't seem to exist
<stgraber> brendand: hmm, ok, odd. Can you try "sudo stop lxc-net && sudo start lxc-net" then, see what happens?
<brendand> stgraber, whoops - just needed sudo: http://paste.ubuntu.com/7658732/
<stgraber> brendand: ah, ok
<stgraber> brendand: do you have bind9 or some other DNS server installed on that box that'd bind port 53 on all interfaces?
<brendand> stgraber, yeah. for whatever reason i do have bind9
<brendand> stgraber, remove it?
<stgraber> brendand: yeah, remove it, make sure it's no longer running, then restart the lxc-net job, that should fix things.
<stgraber> brendand: basically LXC starts a dnsmasq service for DHCP and DNS on lxcbr0, so if another daemon already claimed all interfaces, that fails, which in turn makes the rest of the job fail
<stgraber> you're the second one reporting this happening though, so I'm starting to wonder if we somehow pulled bind9 into our base install by accident...
<stgraber> not according to cdimage.u.c at least
<tseliot> bdmurray: are you around?
<bdmurray> tseliot: yes
<tseliot> bdmurray: I have two packages associated with some SRUs. Can you help please? nvidia-prime (precise-proposed) [LP: #1326257, LP: #1296020], ubuntu-drivers-common (trusty-proposed) [LP: #1306928, LP: #1296020, LP: #1310023]
<ubottu> Launchpad bug 1326257 in ubuntu-drivers-common (Ubuntu Trusty) "[nvidia-prime] Cannot adjust brightness in guest session and results in black screen while changing the resolution" [High,In progress] https://launchpad.net/bugs/1326257
<ubottu> Launchpad bug 1296020 in ubuntu-drivers-common (Ubuntu Trusty) "[Asus U36JC] Non-existent display detected in both intel driver and nvidia driver (Optimus Laptop) (ubuntu trusty 14.04)" [Critical,In progress] https://launchpad.net/bugs/1296020
<ubottu> Launchpad bug 1306928 in ubuntu-drivers-common (Ubuntu Trusty) "Broadcom STA driver gets autoinstalled on BCM4313, where it's no longer needed" [High,In progress] https://launchpad.net/bugs/1306928
<ubottu> Launchpad bug 1310023 in ubuntu-drivers-common (Ubuntu Trusty) "14.04: Nvidia Prime is unable to switch to the Nvidia card" [High,In progress] https://launchpad.net/bugs/1310023
<rcj> stgraber, Would you have time to look at a updated open-vm-tools for trusty for that SRU?  It's been uploaded to fix a breaks/replaces problem.
<rcj> stgraber, or I can ask infinity since he raised the issue.
<stgraber> rcj: looking
<bdmurray> tseliot: I'm still a bit swamped with the error tracker, but I'll try and have a look.
<tseliot> bdmurray: thanks
<stgraber> rcj: accepted
<rcj> stgraber, excellent
<thostr_> doko: any estimate when things should be finally fixed/landed in ci?
<doko> thostr_, just copied
<doko> tvoss, some binutils change between Jun 04 and Jun 12, feel free to pick one
<thostr_> doko: so, rebuild should now work?
<doko> thostr_, you need to wait until the package is published
<thostr_> doko: once published, can you ping #ubuntu-ci-eng?
<doko> thostr_, I'm afk now, please have a look yourself. they are published but not yet mirrored
<tjaalton> cjwatson: hey, it's probably a normal feature that grub2 menu gfx operates very slowly on a highres framebuffer?
<tjaalton> takes a while to redraw the screen
<tjaalton> like on a 3200x1800 screen..
<cjwatson> tjaalton: sometimes hard to get suitable acceleration in place
<cjwatson> I improved some of that a while back but no doubt it could do with somebody sitting down for another profiling/optimisation pass ...
<tjaalton> alright
<tjaalton> I might have a go at some point
<ddsss> when packaging a .deb - is there a special directory I should use for an example config file?
<jtaylor> using dh_installexamples is probably not wrong
<infinity> ddsss: If it's an example strictly for the user's interest, /usr/share/doc/<package>/examples/ (which is where dh_installexamples will put it), if it's going to be used by the package (ie: a postinst does "cp example.conf /etc/example.conf"), it needs to be in /usr/share/<package> as the doc directory is pruged in some setups.
<ddsss> infinity, does the same goes for an example upstart script?
<infinity> ddsss: An example is an example, not sure the content makes a difference here. ;)
<ddsss> infinity, gotcha. thanks!
<infinity> ddsss: It's the intended use that matters, if the PACKAGE is referencing it, it can't be in doc, if it's just for the user's reading and learning pleasure, it belongs in doc.
<ddsss> infinity, awesome. awesome to the max.
<bdmurray> popey: do you have another test case for bug 1278780? I'm specifically looking to crash unit8.
<ubottu> bug 1278780 in apport (Ubuntu) "apport takes too long to write crash report, appears to lock up phone" [High,Triaged] https://launchpad.net/bugs/1278780
<sergiusens> slangasek jdstrand no rush on this one, but am I good to migrate back to gc golang? Or is the recommendation still being worked on?
<slangasek> sergiusens: we have a long term plan to migrate to gc; I don't think we had settled whether we should start using it today in the absence of dynamic linking support
<slangasek> I think I would prefer to see us continue with gccgo for right now, unless you're running into specific problems
<sergiusens> slangasek: no, no problems at all on my side
<popey> bdmurray: thats a while back, not had that recently, sorry.
<bdmurray> popey: okay, thanks
<popey> ogra_: looks like my booting got significantly worse after doing a completely clean install (and adding full disk encryption) http://people.canonical.com/~alan/bootcharts/deep-thought/deep-thought-trusty-20140616-4.png
<ogra_> popey, heh, well, encryption ... gotta pay a price for that
<ogra_> the gren grass on the right looks seriously worrying though
<ogra_> your disk seems to be doing mad stuff there
<popey> yeah, its bonkers
<popey> might reboot a few times to get some more stats, later, after dinner
<ogra_> yeah
<ogra_> is it actually taking 1:30 til you have a desktop on screen ?
 * ogra_ doubts that ... looks like it simply doesnt go into idle which keeps bootchart going on until it times out after 1:30
<popey> ogra_: sometimes it is fine http://people.canonical.com/~alan/bootcharts/deep-thought/deep-thought-trusty-20140616-1.png
<popey> <30s
<popey> it may have been sat at the login screen#
<ogra_> right
<ogra_> well, that disk stuff deserves examination for sure ... you got something that peaks it every few seconds
<hallyn_> xnox: hey, did you get a chance to look at http://people.canonical.com/~serge/netcf-src-0.2.4/netcf_0.2.4-1.dsc ??
<hallyn_> (for debian upload)
<ddsss> are most ubuntu packages  - source packages? or binary ones?
<infinity> ddsss: They're all both.  Source packages produce binrary packages.
<ddsss> im trying to build a source package - sort of stuck.
<infinity> ddsss: You probably want #ubuntu-motu
<ddsss> infinity, what's that - beginners channel?
<infinity> ddsss: They deal with beginner packaging issues there, yes.
<ddsss>  .deb source packages are not directly installable - right?
<jpds> ddsss: Build the .deb with 'debuild'.
<ddsss> jpds, what's the difference from c++ source files and deb-src sources?
<jpds> ddsss: deb-srcs include the debian/ directory which explains how the .deb is built.
<ddsss> jpds, so then someone else compiles deb-srcs packages for each platform?
<jpds> ddsss: Someone else?
<jpds> ddsss: We don't crowd-source the .deb building.
<ddsss> jpds, I mean - isthere some automated UBuntu build-server or something?
<jpds> ddsss: https://launchpad.net/builders
<jpds> ddsss: build serverS - is the term you're looking for.
<ddsss> jpds, aha - I see.
<ddsss> jpds, so whebever someone "dputs"new source package - that triggers a build for various architectures?
<jpds> ddsss: Yes.
<ddsss> jpds, but people can also upload binary packages as well - right?
<jpds> ddsss: No.
<jpds> ddsss: Everything must be built from sauce.
<ddsss> jpds, aha. I see.
<ddsss> jpds, when building source package  - does it matter if program is using cmake instead of automake?
<dobey> no
<dobey> well unless you're trying to use autotools to build a cmake source
<dobey> how to build the thing is defined in debian/rules
<dobey> ddsss: you should probably be asking these questions in #ubuntu-packaging or #ubuntu-motu though
<dobey> as was suggested earlier
<ddsss> dobey, thanks. switching to  #ubuntu-packaging :)
<hallyn> xnox: zul: all right i have a working libvirt-with-cgmanager.  jsut a few more tests then i intend to push to utopic.
<jtaylor_> hm is the backport builddepending on backports issue fixed now?
<jtaylor_> ah found the bug in my too large email archive, seems fixed, thx infinity  :)
<stgraber> oh, is it? neat
<jtaylor_> bug 888665
<ubottu> bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Fix released] https://launchpad.net/bugs/888665
<bluesabre> mdeslaur, I was wondering if there is anything holding these up?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1326740
<ubottu> Ubuntu bug 1326740 in xfce4-power-manager (Ubuntu Trusty) "[SRU] Please backport xfce4-power-manager 1.2.0-3ubuntu6 to trusty" [Undecided,In progress]
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1326741
<ubottu> Ubuntu bug 1326741 in light-locker-settings (Ubuntu Trusty) "[SRU] Please backport light-locker-settings 1.2.1-0ubuntu2 to trusty" [Undecided,In progress]
<bluesabre> let me know if you need anything additional from me :)
<sarnold> bluesabre: someone needs to verify the SRUs https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
<Unit193> sarnold: A bit hard to do if it isn't in proposed yet.
<sarnold> Unit193: oh :)
<sarnold> I just saw the verification-needed tag and jumped straightaway to a conclusion..
<Unit193> Can blame bluesabre for trying to confuse you. ;)
<bluesabre> Ah, sorry about that, the SRU steps are a bit confusing :)
<xnox> hallyn: \o/
<xnox> hallyn: I thought i uploaded netcf, let me check my mails
<hallyn> xnox: was that a "boy it's late i oughta be in bed' stretch?  :)
<hallyn> xnox: rmadison -u debian didn't seem to show it, but maybe it's hung somewhere
#ubuntu-devel 2014-06-18
<mdeslaur> bluesabre: someone from the SRU team needs to push the packages to -proposed. I'm not in the SRU team, so it's out of my hands.
<hallyn> xnox: thanks!
<hamiltont> I'm having trouble specifying vga=XXX as a kernel param. None of video modes match tables I've found
<hamiltont> See http://imgur.com/LmYoe6o for example
<hamiltont> (for the table of video modes I'm seeing output)
<hamiltont> Also I entered vga=774, and the kernel seems to think I've entered video mode number 306
<tarpman> hamiltont: 0x306, probably
<tarpman> (no idea about the rest of your question, sorry)
<hamiltont> No worries. Not sure I understand your reply. The modes are specified in hex, and I should try vga=0x306?
<tarpman> "the kernel seems to think I've entered video mode number 306" -- hex 306 corresponds to the decimal 774 you entered
<hamiltont> ah awesome
<hamiltont> That shoudl let me specify any of the values listed in the table, which is really all I need to get it working
<hamiltont> just curious why it doesn't correspond to any tables I can find, but I don't need to know
<hamiltont> thanks
<hamiltont> Does anyone know if it's possible to access a root shell during debian-installer? The shells on alt-F2 and alt-F3 do no appear to allow root
<hamiltont> They are both busybox-based
<hamiltont> and I can't run scripts owned by root
<sarnold> you can't? o_O what error do you get?
<hamiltont> permission denies
<hamiltont> ed*
<hamiltont> script I'm looking at is marked +x, and owned by root:root
<hamiltont> I'm trying to run by doing ./script.sh
<sarnold> what interpreter is it trying to use? does that interpreter exist? do all the libraries needed for that interpreter exist?
<hamiltont> Using "sh script.sh" reports no permission error, but does not seem to run the script either
<hamiltont> trying to use /bin/sh
<hamiltont> I'd guess I'd see an error about libraries if they didn't exist
<sarnold> I think last time I saw missing libraries needed for an interpreter, "permission denied" _was_ the error :)
<hamiltont> Hmmm, interesting
<sarnold> course that was back in the mists of time
<hamiltont> perhaps that's a busybox failing, I tried to run this on another machine under bash and it prompted reported library problems
<hamiltont> but I do seem to be root...just created a new file and it's also owned by root:root
<hamiltont> so you're probably correct...the error is misleading me
<sarnold> it's a long shot.. any chance you have strace available? strace is worth its weight in gold when debugging problems..
<hamiltont> No luck :-/ It does have "set -x", so that's something, but the error is the same with that turned on
<sarnold> how about ldd /bin/sh  ?
<hamiltont> no luck on ldd either, just tried :-p
<hamiltont> busybox can be a pita!
<RAOF> bluesabre: Those SRUs are now testable in trusty-proposed, or will be once the buildds catch up.
<bluesabre> oh, thanks a lot RAOF!
<hamiltont> Does anyone have a sample of bash for detecting debug/verbose/etc from /proc/cmdline?
<pitti> Good morning
<tvoss> doko_, good morning
<dholbach> good morning
<pitti> dpm: \o/
<pitti> ./es/LC_MESSAGES/dialer-app.po
<dpm> awesome :)
<pitti> dpm: so the export worked fine; I'll build fresh packs then
<dpm> pitti, excellent
<infinity> pitti: Dude, email me some of those strawberries.  They look fantastic.
<pitti> infinity: hehe -- that's a quality you can only get when plucking yourself :) (and eating a ton right on the field)
<infinity> pitti: So very jealous and hungry now. :P
<pitti> infinity: I'd love to keep some and bring them to the next sprint, but they might not be as enjoyable as today any more :/
<pitti> haha! https://plus.google.com/u/0/+YonatanZunger/posts/EAZcFMeCRrG
<pitti> unicode FTW
<pitti> man, all these times when I was looking for a "man in business suit levitating" glyph and didn't find one..
<xnox> hallyn: i'm west coast USA today =)
<xnox> hallyn: please fix the symbols file though.
<OdyX> tkamppeter: you could sync gutenprint 5.2.10-2
<brendand> anyone know where to get ahold of jonathan lange or rob collins? this bug https://bugs.launchpad.net/testtools/+bug/1331358 in testtools is impacting on phone test results
<ubottu> Ubuntu bug 1331358 in testtools "skip decorated tests still have setUp and tearDown run around them" [Undecided,New]
<brendand> i could try and fix it myself of course
<pitti> brendand: lifeless is rob collins
<brendand> lifeless, hello?
<pitti> brendand: might not be the best time for him, he's in Australia
<RAOF> NZ, actually, which makes it a worse time :)
<brendand> pitti, yeah i knew that. but he's marked active, and you never know - it's only 8:30pm
<doko> tvoss: ?
 * ogra_ sighs ... the new inline comments feature in LP is sending annoyingly big emails in MP mails ... 
<ogra_> would be nice if it wouldnt always attach the full patch for a one line comment thats somewhere in the middle
<infinity> ogra_: It's a work in progress, attempting to be more intelligent about context is in the plans.
<ogra_> cool
<ogra_> then i'm willing to live with the annoyance for a while
<pitti> dpm: Skipping domain dialer-app with too low priority 0
<pitti> dpm: can you please fix?
<dpm> pitti, argh, yes
<pitti> dpm: also, there's a lot of programs with prio 0 which are wrong: http://paste.ubuntu.com/7662665/
<pitti> dpm: perhaps for now I should treat priority 0 as "unset" and include them?
<dpm> pitti, if I do this quickly, this priority change will be in the next .json files export. I've fixed dialer already
<dpm> I'Ve got a few minutes, bbiab
<pitti> dpm: sorry, de-duped: http://paste.ubuntu.com/7662669/
<dpm> pitti, ok, thanks. I see that none of these affect the touch langpacks, so I've just fixed dialer for now. It should be in the next json export in the next few minutes. The other ones might take me a bit, but I can fix them all today
<pitti> dpm: me too, need to disappear for ~ 2 h
<pitti> dpm: thanks muchly
<dpm> well, thank you for the list :)
<Saviq> Mirv, https://code.launchpad.net/~saviq/ubuntu-ui-toolkit/new-qt-dep-names/+merge/223522
<tkamppeter> OdyX, does your Gutenprint package contain all the recent Ubuntu changes, especially "debian/rules: Touch the *.ppd-updater files in override_dh_fixperms, as
<tkamppeter>     in override_dh_install-arch the change does not stay." from 5.2.10~pre2-0ubuntu2?
<OdyX> tkamppeter: kinda. It's installed by "install" directly instead of a .install file AFAIK. Also see the preinst for that case.
<tkamppeter> OdyX, so I can sync without regression?
<OdyX> tkamppeter: I think you can. :)
<OdyX> tkamppeter: also, what is blocking cups 1.7.3-3 ?
<rbasak> infinity: any progress on the juju-core power ftbfs please? I created bug 1329295 to track this. Mind if I assign this one to you?
<ubottu> bug 1329295 in juju-core (Ubuntu) "juju-core 1.18.4-0ubuntu1 FTBFS on powerpc in utopic-proposed" [High,Triaged] https://launchpad.net/bugs/1329295
<infinity> rbasak: I might a little, yeah.  Given I know exactly nothing about Go. :P
<infinity> rbasak: But I will play with reproducing a bit more.
<infinity> rbasak: Or, rather, reproducing the failure to fail on the porter, which is what's really odd.
<rbasak> infinity: yeah, without reproduction on the porter I have no chance to even begin to look at it :-/
<bdrung_work> cjwatson, i saw that you committed to the debian sbiuld git repo. can you have a look at the patches attached to Debian bug #714883?
<ubottu> Debian bug 714883 in sbuild "sbuild: Support --add-repository to add an apt source for just one build" [Wishlist,Open] http://bugs.debian.org/714883
<tkamppeter> OdyX, gutenprint I have synced now, thanks for your package. CUPS 1.7.3-3 got auto-synced, but probably only very recently, so that it does not appear in the updates of Utopic yet.
<Chipaca> ogra_: low-priority ping, about ppu, when you've got 5
<ogra_> sure
<Chipaca> ogra_: is that an "I have 5 right now"?
<ogra_> yeah
<Chipaca> ogra_: so, I need sponsors for my PPU application, and AIUI you've reviewed some of my packaging of ubuntu-push. If that is correct, could you add yourself to https://wiki.ubuntu.com/Chipaca/PPU and lie^Wsay nice things about me?
<ogra_> sure, no prob, when is your meeting ?
<Chipaca> ogra_: I haven't asked for one yet
<Chipaca> ogra_: AIUI I need to get a couple of sponsors, *then* ask
<Chipaca> of course, i might be wrong -- i'm rather dense when it comes to this particular kind of bureaucracy
 * Chipaca can neither confirm nor deny being dense about anything else at all
<ogra_> heh, i'll add something, no worries
<Chipaca> ogra_: thanks!
<kgunn> doko: cjwatson hey guys....i hope its us doing something wrong, but we don't think so...
<kgunn> https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1331435
<ubottu> Ubuntu bug 1331435 in gcc-4.9 (Ubuntu) "Build problem: error: âsize_tâ does not name a type" [Undecided,New]
<kgunn> would one of you wanna work with camako on our team to help figure it out ?
<kgunn> we've ground to a halt, its effecting our ci builds on our devel branch too
<doko> kgunn, which version?
<kgunn> doko: i'm sorry...which version of what ?
<kgunn> doko: lemme grab a build log
<doko> yes, build log would help
<kgunn> https://launchpadlibrarian.net/177856545/buildlog_ubuntu-utopic-armhf.mir_0.3.0%2B14.10.20140618-0ubuntu1_FAILEDTOBUILD.txt.gz
<kgunn> doko: sorry about that...thot it was in the bug, i added it there....link as well ^
<doko> kgunn, is <cstddef> or <stddef.h> included?
<camako> doko: (taking over from kgunn, who has a meeting) This is not something that failed until today. Haven't made any changes. Nevertheless adding those headers anyways, does not help.
<camako> doko, we had other weird problems of this sort due to 4.8 to 4.9 changeover
<doko> camako, afaics from the build log, your are still using 4.8, aren't you?
<kgunn> camako: he knows :)
<kgunn> doko: that log is from build silo 16....so it'd be whatever is in utopic
<doko> camako, where can I get the source for this package?
<kgunn> doko: lp:~mir-team/mir/0.3
<camako> We had CI guys mess with this silo and switch it to 4.9
<doko> xnox, ^^^ are the android headers mucking around with standard types?
<asac> ricmm: rsalveti: ^^ you might know too
<ogra_> right, thats an rsalveti question
<sil2100> I acutally wanted to check that, but my armhf chroot takes ages to build mir
<Saviq> sil2100, can I help with that?
<camako> sil2000, cross_compile reproes the issue
<camako> sil2100, you can use the cross-compile-chroot.sh in lp:~mir-team/mir/0.3 to repro it under a min
<sil2100> camako: cross-building for the win then
<sil2100> My chroot should just die...
<doko> camako, so this is built using 4.8 if no other dependency ppa's are used
<camako> doko, you 're probably right... I got word from robru that it was pointed to 4.9 though...
<camako> it == silo
<camako> sil2100, if it's your first time, it'll take a bit longer though... See "cross_compile" section in http://unity.ubuntu.com/mir/building_source_for_android.html
<dholbach> pitti, how can I find out more why "ubuntu-bug bla.crash" does not file a bug for me? :)
<pitti> dholbach: because we haven't turned LP bug submission back on
<dholbach> aha!
<pitti> dholbach: sorry, bogus
<pitti> dholbach: that's only for crashes, not bugs
<pitti> dholbach: any stderr?
<pitti> dholbach: ok, engaging brain: it's ubuntu-bug, but a crash :)
<pitti> dholbach: you can comment out the problem_types line in /etc/apport/crashdb.conf
<kgunn> doko: camako on the 4.9 vs 4.8 thing
<dholbach> pitti, no, nothing on stderr
<kgunn> i learned from slangasek y'day that the 4.9 lib was what is being used...but that the libstdc++-dev was 4.8
<pitti> seb128: WDYT, time to enable apport for LP on utopic?
<kgunn> so the logs show the build against 4.8....but in reality the lib is 4.9
<kgunn> doko: i assume you knew that tho ?
<doko> kgunn, yes, the runtime library, but that wouldn't explain any issue with a header file
<kgunn> ...this was based on the _original_ idea that ABI hadn't broken
<dholbach> pitti, thanks!
<dholbach> pitti, I already thought I was doing it wrong ;-)
<seb128> pitti, +1
<pitti> dholbach, seb128: ^ uploaded
<pitti> dholbach: thanks for the reminder :)
<seb128> pitti, danke
<dholbach> excellent!
<Saviq> ricmm, https://code.launchpad.net/~saviq/unity-mir/new-papi-dep-name/+merge/223560
<Saviq> ricmm, for the future: transitional packages need to be Arch: any and Multi-Arch: foreign
<Saviq> ricmm, otherwise cross-building breaks
<ricmm> sorry, updating that build-dep must've escaped me... somehow
<ricmm> Saviq: landeded it
<Saviq> ricmm, tx
<rsalveti> morning
<ricmm> Saviq: will you silo that yourself?
<Saviq> ricmm, yeah
<Saviq> ricmm, unless you have somewhere for it to hitch a ride?
<ricmm> I dont, sorry
<Saviq> ricmm, like silo 15?
<ricmm> thats not landing yet
<Saviq> ok, then whenever
<rsalveti> kgunn: is that build failure only happening on armhf?
<rsalveti> I did rebuild mir yesterday, but only armhf failed but due a different issue
<kgunn> rsalveti: i believe, camako ? ^
<camako> rsalveti, kgunn, yes
<rsalveti> I don't get why armhf only though
<rsalveti> as we're building the android backend on x86 as well
<rsalveti> /usr/include/c++/4.8/mutex:779: undefined reference to `std::__get_once_mutex()'
<rsalveti> this is the issue I had yesterday
<rsalveti> just armhf as well
<kgunn> rsalveti: that was fixed as part of https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1331242
<ubottu> Ubuntu bug 1331242 in gcc-4.9 (Ubuntu) "libstdc++6: missing symbols std::__once_functor, std::__get_once_mutex(), `std::__set_once_functor_lock_ptr(std::unique_lock<std::mutex>*)" [Critical,Fix released]
<camako> yea this is a different issue
<kgunn> rsalveti: so once that was cleared, we saw this new issue
<rsalveti> weird, wonder why my build didn't use latest gcc, but anyway
<rbasak> ScottK: is a clamav merge on your radar? I see that you only uploaded to Debian yesterday, so no rush - just checking as I'm going through the whole list that ubuntu-server is subscribed to.
<dholbach> seb128, do you know which package to install to make qt4 apps look less "funny" on utopic? :)
<seb128> dholbach, I don't, sorry, maybe ScottK or Riddell or Mirv know?
<Riddell> I recommend kubuntu-desktop
<dholbach> right...
<Riddell> although qt4 should magically detect it's running under gnome and use the gtk theme I think
<Mirv> :)
<Mirv> dholbach: what's funny about them?
<Mirv> dholbach: kubuntu-desktop would surely work fine, but other than that the only thing that comes to my mind is checking appmenu-qt is installed which gives you global menu bar menus
<doko> rsalveti, kgunn, ricmm, camako: blame android-headers please for that case, updated the bug report
<dholbach> Mirv, looks like some theming engine is missing or something: http://people.canonical.com/~dholbach/tmp/screenshot.png
<dholbach> Mirv, it looks like an ancient gtk theme
<rsalveti> yeah, this is not a toolchain issue, still not sure why only happens on armhf though
<rsalveti> probably on x86 the proper headers get included in the include chain
<tvoss> rsalveti, or a missing define somewhere?
<rsalveti> kgunn: camako: see that the error only happens when building the test
<rsalveti> tvoss: size_t
<rsalveti> missing a include
<rsalveti> /usr/include/android/system/graphics.h:269:5: error: 'size_t' does not name a type
<camako> rsalveti, so have the android headers changed in the last day or two? This wasn't a problem before..
<rsalveti> camako: changed that yesterday, requested by kdub, to include some new entries added in android 4.4
<camako> rsalveti, ok android headers changed, things got moved around, Mir fails, and probably needs additional headers now... gotcha
<rsalveti> camako: one quick way to fix that is to include the missing header in the test case
<rsalveti> itself
<tvoss> rsalveti, yup, just tried that
<rsalveti> tvoss: did it work?
<tvoss> rsalveti, yup, seems so :) but the test case compile works now
<rsalveti> tvoss: great, kgunn camako then please do the same
<camako> rasalveti, tvoss, will do thx
<rsalveti> tvoss: what did you include, stddef.h?
<rsalveti> can probably change the header itself as well
<Mirv> dholbach: hmm, my Spotify looks good at least
<dholbach> you're right - for me it was skype and musique looking funny
<doko> rsalveti, yes, stddef is needed in graphics.h
<rbasak> stokachu: fancy merging keepalived again, please?
<rsalveti> doko: yeah, saw the bug, just uploaded the fix
<rsalveti> thanks
<rsalveti> camako: kgunn: also fixed android-headers, once that lands in release you can try rebuilding mir
<camako> rsalveti, sounds good
<tvoss> rsalveti, stddef.h should do it, trying cstdlib in the test-case only now
<tvoss> rsalveti, just for cross-checking
<rsalveti> sure
<seb128> is there an easy way to get the upstart env from a running user session in a vt?
<seb128> like I logged in unity8 and I want to start/stop jobs from a vt
<seb128> I can get the /proc/`pidof unity8`/environ UPSTART_.... definition and export it manually, that works but I was wondering if there was some less-manual way to do that
<cjwatson> That's what I was about to suggest :)
<cjwatson> It's basically just the same as attaching to a dbus session somewhere else, which to the best of my knowledge there's never been a non-manual tool for
<seb128> k
<seb128> so stupid command line question ... ;-)
<seb128> if I "strings /proc/`pidof unity8`/environ | grep UPSTART" ... how can I redirect that to an export command?
<cjwatson> export `...`
<seb128> I know how to do it by putting in a file and editing the file to do an export, but i'm sure there is simpler way :p
<seb128> oh, that easy?
<seb128> cjwatson, thanks ;-)
<stgraber> seb128: there's also /run/user/<uid>/upstart/sessions/<pid>.session
<seb128> I was trying to "| export" with some use of xargs even, without luck
<seb128> stgraber, thanks
<cjwatson> can't use xargs because that would put it in a subshell which immediately exits
<stgraber> though note that if you already have the init process pid anyway, you can just as well build the socket path yourself ;)
<seb128> stgraber, well, same trick needed for dbus and other things
<seb128> cjwatson, stgraber: thanks
<cjwatson> also if you're doing it manually rather than using the file in /run/, "export `grep -z ^UPSTART_SESSION= /proc/PID/environ`" is easier than using strings
<cjwatson> (grep -z leaves a trailing \0, but the shell ignores that so whatever)
<seb128> good to know as well, thanks ;-)
<hallyn> xnox: giving it a shot, this bit is black magic to me.  should i then bump the version?  (you've pushed the first it looks like?)
<hallyn> really i wonder why it has that at all.  i didn't put it there...
<hallyn> xnox: so should i be running dpkg-gensymbols against all the old versions to get the full historical list?
<infinity> hallyn: If you want versioned deps to be as precise as possible, that would be the way to go.
<infinity> hallyn: Otherwise, you'll get everything depending on your latest version, as you'll claim all the symbols appeared there.
<hallyn> infinity: it's not some huge faux-pas to have version 2.4 change the .symbols contents for earlier packages?
<hallyn> (doesn't break package builders or somesuch)
<hallyn> ok, will do, thx
<infinity> hallyn: Nah.  If you're generating a correct .symbols now, what you had before doesn't really matter.
<infinity> hallyn: The basic idea is that if a package uses symfoo but not symbar, and symfoo appeared in upstream v1.2, but symbar appeared in v1.5, you want packages to depend on >= 1.2
<infinity> hallyn: If you introduce a symbols file that claims everything appeared in 1.5, the deps are annoyingly a bit wrong (though it's not world-ending).
<infinity> This is so much easier with libraries that version symbols sanely (like glibc), since you can just generate on the fly.  Sadly, very few do.
<hallyn> (lessee if i can do something that can be described 'sane'.  looks simple enough...)
<shadeslayer> bdmurray: how do I group together the same backtraces?
<shadeslayer> bdmurray: in errors.ubuntu.com
<shadeslayer> https://errors.ubuntu.com/problem/1a794f4f0b1fa61aa9916353ae643de6085125fc and https://errors.ubuntu.com/problem/2bb11f5013b5638956cbb06a6f822d811fde60a4 are the same
<bdmurray> shadeslayer: there isn't a way at this point in time
<shadeslayer> oh
<mdeslaur> xnox: so, in the apparmor postinst script, I was doing invoke-rc.d apparmor reload, now that I'm adding an upstart job, I need to do something like "start apparmor ACTION=reload", but what if the user is running systemd? Is there a way for me to detect what init system is currently running?
<mdeslaur> xnox: I can't just use invoke-rc.d, because I need more than 'start'
<jdstrand> mdeslaur: slangasek mentioned that we may not want use the upstart job in that way, though I wasn't entirely clear why. I mentioned we could move the logic of the job out to a script and then have the job call the script and the postinst call the script
<jdstrand> I can't recommend that we should do that, just mentioning it for background
<mdeslaur> jdstrand: hrm interesting
<slangasek> jdstrand, mdeslaur: the point there was that if anything referenced apparmor in its own 'start' condition (which we had discussed at one point), this would deadlock the upgrade
<slangasek> given the current proposal, that's not an issue
<slangasek> but as for passing different options to the upstart job... hmm
<slangasek> this can probably be autodetected in the job, by checking UPSTART_EVENTS ?
<slangasek> (and then you can just use invoke-rc.d)
<mdeslaur> slangasek: I want to detect which init system is running in a postinst
<slangasek> why's that?
<slangasek> that's somewhat contrary of the general design of invoke-rc.d and friends
<mdeslaur> of course, I'm not sure if adding custom ACTION commands is something that will be easy to port to systemd anyway, so perhaps it would be best to have a separate helper
<slangasek> ... of?  contrary beside
<mdeslaur> slangasek: the postinst needs to make apparmor invalidate the cache and rebuild policies, so it can't just be a 'start' command
<mdeslaur> slangasek: so I'm not sure it fits well with invoke-rc.d
<slangasek> mdeslaur: I'm not sure why it can't be
<slangasek> that's what I'm saying, using $UPSTART_EVENTS you can detect the difference between "started at boot" vs "started from postinst"
<slangasek> and have different behavior accordingly
<slangasek> now, how you do the equivalent on systemd, I don't have an answer for offhand
<mdeslaur> slangasek: hrm, where is $UPSTART_EVENTS documented with regards to being run in a postinst?
<slangasek> mdeslaur: init(5), in the case of a manual start from a postinst it will be empty
<mdeslaur> slangasek: oh! I understand now, thanks
<lifeless> brendand: pitti: oh hai.
<brendand> lifeless, hi!
<brendand> lifeless, i filed a bug in testtools
<brendand> lifeless, i'm glad to look at it myself if needed, but maybe you have an immediate answer
<lifeless> the skip decorator decorates the method, setup and teardown are run by the framework, which means that that isn't a bug, its how the design works
<lifeless> but I see the docs you quote
<lifeless> so, will have to go and look at the python implementation
<brendand> lifeless, yes - it does change the expected behaviour from the point of view of someone familiar with unittest
<lifeless> oh man thats so ugly
<lifeless> so sure, please do implement this for testtools
<brendand> lifeless, any pointers?
<brendand> lifeless, if i don't have to start from step 0, that would be appreciated
<lifeless> you'll need to read the cpython implementation in Lib/unittest/case.py and then in testtools there is testtools/runtest.py where we pulled that logic sideways - you'll need to do the analogous thing there
<lifeless> brendand: if you get stuck, gimme a shout
<brendand> lifeless, that's definitely enough info, thanks
<brendand> lifeless, so will __unittest_skip__ be present - i assume so?
<lifeless> brendand: you know, I have no idea :)
<doko> freetype and fontconfig -dev packages not multiarch? bad ...
<slangasek> doko: see the longstanding bug report on the Debian BTS for freetype - freetype-config is part of the upstream build interface, and no one has yet given me a ready-to-apply patch for it
<slangasek> I'll happily apply a fix if someone gives it to me, but so far the only people who care about multiarch coinstallability of freetype-dev are people building their own wine, and we have packages for that :)
<doko> slangasek, isn't that just a sed removing the -L ?
<slangasek> doko: bug log has details, I really can't remember right now :)
<doko> pfff
<doko> two ctte members as uploaders ...
<slangasek> anyway, I don't need someone to tell me how to fix it, I need someone who cares to actually provide a patch, or else it'll remain a low priority for me
<slangasek> doko: Keith has never, ever uploaded the package and I need to remove him from the Uploaders field
<cjwatson> Riddell: looks like a bunch of KDE is stuck behind nepomuk-core - seems like just a missing "abi1" in rules?
<cjwatson> (ignore if you already noticed)
#ubuntu-devel 2014-06-19
<bluesabre> good evening/morning/other sponsors and SRU team :)
<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> Can we upload this to trusty-proposed and begin verification, or are there additional details needed?
<bluesabre> I have one other as well, please let me know if there are any blocking issues.
<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]
<ScottK> rbasak: I'll take care of it.
<pitti> Good morning
<jono> morning pitti
<pitti> jono: hey collea^Wargh free software pal! :)
<jono> pitti: :-)
<jono> howdy!
<jono> hows things there?
<pitti> jono: you now need to work late? :-)
<jono> sometimes it seems
<jono> :-)
<jono> figuring out my new world
<pitti> jono: quite fine, thanks! visiting my family for a few days
<jono> oh nice!
<pitti> jono: already building space ships? :-)
<jono> pitti: hah, not quite yet
<jono> focused on another project you will hear about next month ;-)
<jono> very, very cool
<pitti> jono: sounds exciting!
<jono> pitti: yeah, it is going to be fun :-)
<pitti> Riddell: the kde-runtime autopkgtest shows a file conflict between khelpcenter4 and kde-runtime-data on /usr/share/kde4/apps/khelpcenter/plugins/browsercontrolmodules.desktop
<jono> alright, bed for me
<jono> night all!
<pitti> bye jonmasters
<pitti> err, jono
<pitti> jonmasters: hey :) (sorry, tab completion fail)
<Unit193> Howdy.
<hamiltont> WooHoo just put in my first merge request!
 * hamiltont celebrates
<dholbach> good morning
<LocutusOfBorg1> Hi does anybody know why wxwidgets is not sync'd from debian? The new release has been uploaded yesterday
<LocutusOfBorg1> I don't see in ubuntu, neither in merges.u.c
<LocutusOfBorg1> wxwidgets3.0 is the package
<LocutusOfBorg1> (reboot time)
<LocutusOfBorg1> back :)
<LocutusOfBorg1> nobody?
<infinity> LocutusOfBorg1: MoM just hadn't caught up yet.  Merged anyway, it was trivial.
<LocutusOfBorg1> thanks infinity
<LocutusOfBorg1> yes it was trivial, I was wondering MoM wasn't working correctly
<LocutusOfBorg1> when does MoM run? I can see debian dinstall, there is something similar for ubuntu?
<infinity> LocutusOfBorg1: I don't recall the precise schedule, but it's not like that upload's been in unstable for very long.
<LocutusOfBorg1> it was in unstable since 1+ day
<LocutusOfBorg1> the problem was that it was here https://launchpad.net/debian/+source/wxwidgets3.0 since yesterday morning
<LocutusOfBorg1> so I was wondering about a MoM failure (don't know why, the patch was clean), or something else
<LocutusOfBorg1> anyway thanks for the help
<LocutusOfBorg1> :D
<LocutusOfBorg1> I'll ask for a backport today
<cjwatson> MoM runs every two hours
<cjwatson> Sorry, no, it tries to run every half an hour
<cjwatson> Let me see if it's broken
<cjwatson> ValueError: process failed 25: dpkg-source -x lazarus_1.2.2+dfsg-1.dsc /srv/patches.ubuntu.com/unpacked/l/lazarus/1.2.2+dfsg-1
<cjwatson> yup
<LocutusOfBorg1> ok thanks colin, that was my worrying about, and it was right :D
<infinity> cjwatson: That's sort of extra special, since lazarus is in sync...
<infinity> cjwatson: Anyhow, I stole your trivial wxwidgets merge.
<infinity> cjwatson: (After testing it still breaks)
<LocutusOfBorg1> what breaks?
<cjwatson> odd though, unpacks fine when I do it by hand
<cjwatson> infinity: sure, np
<infinity> LocutusOfBorg1: The precompiled headers cause an ICE on arm64.
<LocutusOfBorg1> oh.... I wonder what is the root of the problem
<infinity> At least with gcc-4.8 ... Might need retesting when we flip the default to 4.9 again.
<LocutusOfBorg1> yes, I think doko__ is going to make 4.9 default soon, right? at least on debian, I heard this week
<LocutusOfBorg1> IIRC
<cjwatson> ... but not when I point it at that target directory, wtf
<cjwatson> dpkg-source: error: expected ^--- in line 5 of diff `/srv/patches.ubuntu.com/unpacked/l/lazarus/1.2.2+dfsg-1/debian/patches/add_proper_shbang_to_scripts.patch'
<infinity> LocutusOfBorg1: We already made it the default on Ubuntu, then reverted it in a panic while hunting some C++11 issues.
<cjwatson> ah, well that patch is clearly broken
<infinity> LocutusOfBorg1: Hence the "again" in my sentence. :P
<LocutusOfBorg1> cjwatson, how did it merge a broken patch? so MoM break and somebody sync'd it after?
<LocutusOfBorg1> infinity, I heard that too, but I was thinking it was solved
<cjwatson> LocutusOfBorg1: nothing to do with the *output* of MoM, the package in Debian is broken
<cjwatson> I'm filing a Debian bug
<LocutusOfBorg1> yes, but why the package has been built in ubuntu?
<LocutusOfBorg1> that was my question
<LocutusOfBorg1> so buildd don't have this problem?
<infinity> dpkg seems to unpack it fine...
<cjwatson> I don't know how it managed to build, probably depends on the exact unpack environment, don't care
<cjwatson> it fails to unpack it in some environments
<cjwatson> maybe depends on whether quilt is present when you try to unpack
<cjwatson> anyway, I've nuked it from MoM's pool so it should be able to proceed
<LocutusOfBorg1> quilt on trusty doesn't break
<LocutusOfBorg1> wonderful
<cjwatson> if you look at the patch it genuinely is malformed
<cjwatson> so honestly I don't care too much about the precise details
<cjwatson> I've filed a bug, nuked it, moving on
<LocutusOfBorg1> two questions: why is it broken? (I'll see the bug report), why it was in MoM list? shouldn't MoM process packages only if there is an ubuntu delta?
<infinity> cjwatson: That's a bit flip or similar corruption on your local machine.
<infinity> cjwatson: The patch isn't malformed in the package.
<infinity> --- a/components/chmhelp/packages/help/design/lazhelpchm.sh
<infinity> +++ b/components/chmhelp/packages/help/design/lazhelpchm.sh
<cjwatson> MoM goes through the whole pool to generate diffs, regardless of whether there are Ubuntu changes
<cjwatson> it's an auxiliary function
<cjwatson> infinity: huh
<infinity> cjwatson: Which makes me curious how it managed to unpack at all, but... Whee.
<cjwatson> seriously WTF
<LocutusOfBorg1> http://sources.debian.net/src/lazarus/1.2.2%2Bdfsg1-1/debian/patches/add_proper_shbang_to_scripts.patch
<LocutusOfBorg1> exactly
<LocutusOfBorg1> the patch isn't malformed at all
<LocutusOfBorg1> even quilt refresh looks fine
<cjwatson> seriously it goes wrong every time when I run "dpkg-source -x lazarus_1.2.2+dfsg-1.dsc /srv/patches.ubuntu.com/unpacked/l/lazarus/1.2.2+dfsg-1" not when I run without the target directory
<LocutusOfBorg1> lol
<cjwatson> oh, I see, subtly different version
<LocutusOfBorg1> cjwatson, wrong version
<LocutusOfBorg1> exactly
<cjwatson> 1.2.2+dfsg-1 != 1.2.2+dfsg1-1
<LocutusOfBorg1> 1.2.2+dfsg1-1
<LocutusOfBorg1> yep :p
<cjwatson> but MoM still cares because it goes through to generate diffs; it's occasionally necessary to clear out broken versions from its pool
<infinity> cjwatson: Oh.  Yeah.  Different version.  Derp.
<LocutusOfBorg1> and the previous version was broken indeed
<LocutusOfBorg1> http://sources.debian.net/src/lazarus/1.2.2%2Bdfsg-1/debian/patches/add_proper_shbang_to_scripts.patch
<infinity> cjwatson: I got there around the same time, when cutting and pasting your command and getting ENOFILE.
<infinity> Confusing versions are confusing. :/
<LocutusOfBorg1> please mail 752066-done :)
<cjwatson> LocutusOfBorg1: yes this isn't my first rodero
<cjwatson> *rodeo
<infinity> cjwatson: But it's your first time typing rodeo?
<cjwatson> Apparently
<cjwatson> Anyway done
<LocutusOfBorg1> :) thanks for the help
<LocutusOfBorg1> almost built wxwidgets :D
<ari-tczew> cjwatson: hi. seems m-o-m to be broken?
<ari-tczew> "Generated at 2014-06-15 21:45:09 UTC."
<cjwatson> ari-tczew: scroll up
<ari-tczew> cjwatson: ok
<rbasak> ScottK: thanks!
<tkamppeter> Anyone knows why cuips-1.7.3-3 does not make it from utopic-proposed to utopic (it has built on all platforms)?
<seb128> tkamppeter, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ... seems it's part of the gnutls28 transition
<cjwatson> Stuck behind gnutls28 transition, complex, will take some time
<cjwatson> Fixing things on http://people.canonical.com/~ubuntu-archive/transitions/gnutls28.html would help
<tkamppeter> seb128, cjwatson, thanks.
<tkamppeter> seb128, cjwatson, OdyX, looks like that we have to wait for the gnutls28 transition to complete.
<seb128> tkamppeter, yes
<Laney> You don't have to just wait. :)
<seb128> cjwatson, is the transition "just" to rebuild things with 26->28?
<cjwatson> Wait, maybe that's the wrong transition page
<cjwatson> I was thinking of http://people.canonical.com/~ubuntu-archive/transitions/html/libgnutls-deb0-28.html, but that's complete
<cjwatson> Ah yes, the problem is that libgnutls-deb0-28 is snarled up with the libav10 transition
<cjwatson> Sorry for misleading
<cjwatson> So http://people.canonical.com/~ubuntu-archive/transitions/libav10.html is the right thing to push
<cjwatson> There may be some low-hanging rebuild fruit left there, but I think it mostly requires porting now :-/
<cjwatson> siretart: Do you have any effort available to continue with this?
<caribou> mvo: ping
<mvo> caribou: pong
<infinity> https://wiki.libav.org/Migration/10 may prove helpful for the libav transition.
<infinity> apw: Were you planning on doing +1 this cycle?
<MS4Life> mark shuttleworth why would you make love to me then deny everything!!?!
<MS4Life> u
<MS4Life> cant ban me i just reset the modem
<ikonia> cjwatson:
<MS4Life> ikonia unity sux
<MS4Life> ikonia unity sux
<ikonia> I don't like it either, so I don't know why you are telling me
<MS4Life> Matthew Darcy what do you run on your desktop?
<MS4Life> windows?
<ikonia> Palm OS
<MS4Life> i said desktop
<ikonia> yes, I run palm OS on my desktop
<MS4Life> what do you do for a living
<ikonia> I make goats cheese
<MS4Life> same
<ikonia> there we go
<WombleWasaCattha> I love unity
<infinity> ikonia: Looks like you get to k-line an entire subnet? :P
<cjwatson> (not ideal but I assume they'll get bored)
<mlankhorst> could gline new zealand ;D
<cjwatson> might be a bit of collateral damage
<Unit193> His ident stayed the same.
<cjwatson> I'll refine it if it's a problem but usually this sort of troll has a short attention span
<cjwatson> just don't feed them
<cjwatson> yay I can start landing livefs-in-LP
<zyga> hi, just curious, not a problem really, I was wonderinf if all Qt apps are borked theme-wise for anyone else on utpic?:
<seb128> zyga, dholbach mentioned such issues yesterday
<seb128> not sure if he managed to get them resolved
<infinity> zyga: I had noticed that with mumble, yes.  Hadn't gotten around to whining loudly.
<zyga> seb128, infinity: thanks
<zyga> seb128: should I open a bug on that?
<seb128> zyga, check with dholbach, I guess he had one
<zyga> dholbach: ^^
<siretart> cjwatson: I'm at a conference right now (USENIX ATC, Philadelphia), and I fear that i'm unlikely to find time before end of next week. sorry
<cjwatson> OK, thought I'd at least ask
<siretart> thanks
<siretart> with 'pushing', do you mean removing blocking binary packages from utopic?
<infinity> siretart: Ideally fixing rather than removing, unless there are some that are lost causes.
<infinity> siretart: Do you have a list of stuff that was demoted in Debian to force libav into testing?
<siretart> mplayer and xine-lib seem rather lost causes
<cjwatson> There are way too many right now to be considering removing, IMO.
<siretart> both were removed from testing in favor of mplayer2/mpv and xine-lib-1.2
<cjwatson> xine-lib-1.2 FTBFS in utopic :P
<siretart> k3b disabled its ffmpeg plugin
<siretart> zoneminder was removed from testing
<cjwatson> (something to do with libcaca I think)
<cjwatson> I'm happy to remove/demote the odd one once we get to the end, but we don't appear to be near the end yet
<siretart> sure
<cjwatson> I might sic sil2100 on it next week
<rbasak> pitti: about bug 1329049. I haven't uploaded juju-quickstart to utopic yet. I wanted to get juju-core migrated first. I guess I could throw it into utopic-proposed though.
<ubottu> bug 1329049 in juju-quickstart (Ubuntu) "quickstart fails, hardcodes /var/lib/lxc/ somewhere" [Undecided,New] https://launchpad.net/bugs/1329049
<rbasak> juju-quickstart 1.4.0 that is.
<rbasak> pitti: do you need it right now, and/or do you know if 1.4.0 (it's in PyPI) is also affected?
<pitti> rbasak: hey! No, I symlinked /var/lib/lxc to /scratch/lxc as a workaround
<pitti> rbasak: I didn't try 1.4.0
<dholbach> zyga, no, I didn't have a bug
<dholbach> zyga, and still no idea what triggered it - I got busy yesterday and stopped looking into it - my use-cases were musique and skype, for spotify it works fine, as Mirv pointed out
<dholbach> ^ seb128
<seb128> dholbach, k
<doko__> Riddell, Unpacking nepomuk-core-runtime (4:4.13.2-0ubuntu2) over (4:4.13.0-0ubuntu1) ...
<doko__> dpkg: error processing archive /var/cache/apt/archives/nepomuk-core-runtime_4%3a4.13.2-0ubuntu2_amd64.deb (--unpack):
<doko__>  trying to overwrite '/usr/share/dbus-1/system-services/org.kde.nepomuk.filewatch.service', which is also in package nepomuk-core-data 4:4.13.0-0ubuntu1
<zyga> dholbach: I just noticed it on qbzr
<Riddell> doko: tsk, thanks
<OdyX> tkamppeter: ah, yeah, thanks.
<Mirv> a friendly core dev around to ack/nack packaging changes for mhr3? mainly containing unity-scopes-api version upgrade to 0.5.0 (also unity-api to 7.82)
<Mirv> https://ci-train.ubuntu.com/job/landing-014-2-publish/33/ <- the packaging_changes links
<Mirv> (the packages are at https://launchpad.net/~ci-train-ppa-service/+archive/landing-014/+packages)
<seb128> Mirv, that's from mhr3? nack!
<seb128> (nor fun, he's not on this channel)
<seb128> not*
<seb128> looking
<Mirv> hehe
<LocutusOfBorg1> infinity, do you know why wxwidgets3.0 hasn't move to release yet?
<LocutusOfBorg1> still in proposed so far
<seb128> Mirv, could be get libunity-scopes split in a lib and a binary? having the lib containing unversionned binaries and doing this conflicts/replaces on the old soname is suboptimal
<infinity> LocutusOfBorg1: Looks like a bunch of rdeps need transitioning.
<infinity> LocutusOfBorg1: We'll get to it.  Patience is a virtue. :P
<Mirv> (thanks seb)
<seb128> (yw!)
<LocutusOfBorg1> infinity, thanks, I was wondering about a bug :)
<LocutusOfBorg1> do you have any page where I can see the rdeps of a particular package?
<LocutusOfBorg1> I mean, I see hedgewars in proposed because of libav10 transition
<LocutusOfBorg1> while I don't know where to look for wx3.0, evenmore because the upload seems API/ABI compatible, so I don't even know why a rebuild should be issued
<infinity> LocutusOfBorg1: Looks like libalien-wxwidgets-perl needs a rebuild.  Uploading now.
<LocutusOfBorg1> mm ok, but why?
<LocutusOfBorg1> I'm trying to learn what might cause a rebuild when API/ABI doesn't change
<infinity> LocutusOfBorg1: Because it has exact deps on the version it was built with.
<cjwatson> LocutusOfBorg1: reverse-depends(1)
<LocutusOfBorg1> infinity, cjwatson so the question is: why debian didn't rebuilt it?
<infinity> LocutusOfBorg1: They did.
<LocutusOfBorg1> https://buildd.debian.org/status/package.php?p=libalien-wxwidgets-perl&suite=unstable
<LocutusOfBorg1> I don't see in changelogs
<infinity> LocutusOfBorg1: The upload was timed so that -2 built after wxwidgets on most arches, s390x missed, and got a binNMU.
<LocutusOfBorg1> last rebuild 13 days ago, and wx has been uploaded 2 days ago
<infinity> Err, oh.
<infinity> No, they'll need more binNMUs.  You're right.
<infinity> You'll note it hasn't migrated to testing yet. :P
<LocutusOfBorg1> ok so wx won't reach testing until they binNMU it?
<infinity> And it won't until those binNMUs are done.
<infinity> Yes.
<LocutusOfBorg1> ack, thanks
<LocutusOfBorg1> so why doesn't show this on excuses? package too young?
<LocutusOfBorg1> https://release.debian.org/migration/testing.pl?package=wxwidgets3.0
<LocutusOfBorg1> I think I should see something like "makes 1 package uninstallable or  blabla"
<LocutusOfBorg1> or not?
<infinity> LocutusOfBorg1: Those tests aren't run intil it's up-to-date on all arches.
<infinity> LocutusOfBorg1: And a valid candidate (so, 5 day wait over, no RC bugs, etc)
<LocutusOfBorg1> ack thanks for the full explanation
<LocutusOfBorg1> so the problem is that ubuntu doesn't have this "transition time"
<infinity> Well, that's not so much a problem, from our point of view. :P
<LocutusOfBorg1> yes, of course it isn't :D
<LocutusOfBorg1> the problem is in my mind, I want to know everything I can :)
<roaksoax> can we declare dependencies like: Depends: syslinux-common, syslinux-dev | , <other>
<roaksoax> ?
<cjwatson> not sure what that means
<roaksoax> cjwatson: so in trusty syslinux-common used to ship pxelinux.0. In utopic it is being shipped on syslinux-dev, so we are trying to figure out a way for packaging to work both in utopic and trusty, since we need syslinux-common in both, and syslinux-dev in utopic+
<cjwatson> sure, I just don't understand the syntax you're using above
<cjwatson> how about "syslinux-common, syslinux-dev | syslinux-common"?
<cjwatson> or perhaps "syslinux-common, syslinux-dev | syslinux-common (<< 3:6.00~pre4+dfsg-5)" would be more exact
<cjwatson> (if I've got that version right - based on http://metadata.ftp-master.debian.org/changelogs/main/s/syslinux/unstable_changelog)
<roaksoax> cjwatson: yeah I think something like that would work! Thanks!
<infinity> roaksoax: Err, syslinux-dev?  Really?
<infinity> roaksoax: I think you want pxelinux, not syslinux-dev
<infinity> roaksoax: Oh, I see.  It's in both.  Brilliant.
<psusi> so the bzr repos for git appear to be out of date.  Is the auto importer broken?
<Mirv> heads up that Qt 5.3 has been published to archives, and there'll be fun to be had for the next few hours with them most probably. http://pastebin.ubuntu.com/7670340/
<Mirv> there are 8 packages that should start building shortly, ie. direct syncs from Debian that were already waiting in utopic-proposed for the base modules to come to them
<seb128> ev, bdmurray: https://errors.ubuntu.com/?release=Ubuntu%2014.10&package=webbrowser-app&period=day shows no report from webbrowser-app but https://errors.ubuntu.com/oops/b0a749da-f7d3-11e3-b432-fa163e707a72 is one, is there any way to debug why it's not showing in the summary?
<seb128> bdmurray, since it's your SRU day, could you have a look to libdbusmenu in the trusty queue? Should be an easy diff to review, and it's blocking a landing silo so it would be nice to get in
<bdmurray> seb128: querying the db reveals it is waiting to retrace and may be retracing now
<mitya57> Mirv: \o/
<mitya57> Mirv: Thanks a lot for your work on 5.3!
<Mirv> you're welcome!
<mitya57> Mirv: qt5-doc now depends on non-existent qtpositioning5-doc, can I fix that?
<mitya57> (should be qtlocation5)
<Mirv> mitya57: AFAIK I already fixed that already in the https://launchpad.net/ubuntu/+source/qtdoc-opensource-src/5.3.0-2ubuntu1 but if there's something missing yes surely go ahead and fix (I'll be away for some time anyhow after today)
<Mirv> mitya57: yeah, you're correct. so, go ahead :)
<mitya57> Mirv: you fixed only build-depends, not depends.
<Mirv> indeed
<seb128> bdmurray, thanks, it's still waiting/being retraced, or did that fail for some reason?
<bdmurray> seb128: hmm, it says it is still waiting. I'll keep an eye on it.
<seb128> bdmurray, ok, no worry, let's see if it's retraced by tomorrow, thanks for checking
<seb128> bdmurray, I'm asking because I'm suspÃ®cious there might be an issue there, I'm surprised that e.g unity8 is having 0 reports on the daily reports, we for sure have testers running into errors
<bdmurray> seb128: the queue was quite large for a while since we were starting over
<bdmurray> seb128: we had to retrace everything to create crash signatures
<seb128> bdmurray, well, https://errors.ubuntu.com/?release=Ubuntu%2014.10&package=unity8&period=day still has "no data to display"
<seb128> same for the week view
<seb128> it only has url-dispatcher errors
<seb128> that seems wrong
<bdmurray> seb128: the amd64 queue still has 1000 crashes in it
<seb128> hum, k
<bdmurray> I'll see if I can get some more retracers added temporarily
<seb128> bdmurray, don't worry, it's not a big issue if that's just backlog, I'm trying to make sure we don't have an infrastructure issue which means we discard reports
<seb128> because it looks like this way
<seb128> but that could be a side effect of the backlog
<bdmurray> well, it should be easy to add some more retracers and get the queue to a more managable size
<seb128> that would be nice
<hamiltont> Is anyone from the installer team online?
<cjwatson> hamiltont: I've seen your branch but have had a bit much to do today to review it; will try to look tomorrow
<hamiltont> Awesome, an update was all I was looking for
<hamiltont> thanks
<cjwatson> hamiltont: however are you aware that kickseed's real upstream is actually in a Debian git repository?
<hamiltont> No - I looked but couldn't find it
<hamiltont> I'll happily submit there if you link me
<cjwatson> hamiltont: I'm very likely to redirect you there (which'll still be me reviewing, but it's easier to manage) and ask for you to split up your branch into logically-separate patches
<hamiltont> Yea, that's fine
<hamiltont> Git's easier for me. Where is the project located? I couldn't find it
<cjwatson> http://anonscm.debian.org/gitweb/?p=d-i/kickseed.git, patches would go either as bugs in the Debian BTS or as mail to debian-boot@lists.debian.org
<cjwatson> but I'm fine with proxying, it'd just help to have it spli tup
<cjwatson> *split up
<cjwatson> there are a couple of remaining Ubuntu deltas, I think it's just RAID and LVM handling
<hamiltont> Well how about I wait until you have time to read/respond on launchpad, and then for the next set of changes I'll put them through debian's tracker
<cjwatson> sure, I can give you a first pass review
<cjwatson> just not tonight :)
<hamiltont> Yea sure thing - you seem pretty busy ;-)
<hamiltont> Just want to get these fundamental changes in so I can use them for working on other stuff
<cjwatson> yup, understood
<hamiltont> cool. talk to you later then
<Ryan52> Hi, I'm trying to debug an issue with the proposed archive.. it seems to be missing the autofs-ldap binary package for some reason?
<Ryan52> The version in proposed here https://launchpad.net/ubuntu/trusty/amd64/autofs/5.0.7-3ubuntu3.1 shows autofs_5.0.7-3ubuntu3.1_amd64.deb under Downloadable files, which is also the only one listed in the Packages file on the mirrors.
<Ryan52> However when I click on the build, it shows built files for autofs-ldap_5.0.7-3ubuntu3.1_amd64.deb and autofs-hesiod_5.0.7-3ubuntu3.1_amd64.deb too.
<Ryan52> So what would have kept them from getting into the archive?
<Bluefoxicy> oh for.
<Bluefoxicy> I just tried to delete 4 rows in calc, and it crashed.
<Bluefoxicy> crash recovery recovered an empty document.
<Bluefoxicy> :|
<cjwatson> Ryan52: They're there, you just need to look in universe instead of main.
<Ryan52> cjwatson: ahah, thank you so much! I was misled since they weren't listed on https://launchpad.net/ubuntu/trusty/amd64/autofs/5.0.7-3ubuntu3.1 (I'm still kinda curious why that is)
<cjwatson> because that's the page just for that single binary package
<Ryan52> OK, thanks!
<cjwatson> you want https://launchpad.net/ubuntu/+source/autofs/5.0.7-3ubuntu3.1 instead
<cjwatson> sigh
<cjwatson> was talking :P
#ubuntu-devel 2014-06-20
<hallyn> stgraber: bug 1321854 (in shadow) patch looks good to me.  (you've done the recent uploads so i don't wanna step on toes...)
<ubottu> bug 1321854 in shadow (Ubuntu Trusty) "useradd doesn't add the default shell to /etc/passwd entry" [Medium,Triaged] https://launchpad.net/bugs/1321854
<pitti> Good morning
<infinity> stgraber: "int i1;"... Do they not have j where you come from?
<pitti> *chuckle*
<stgraber> infinity: that's odd, I see that code in there, but I have no recollection of writing it, i1 clearly isn't my coding style (but I'm pretty much the only one who ever touched that code, so I'm likely to blame...)
<infinity> stgraber: Maybe someone snuck into your place in the middle of the night and changed all your variables?
<dholbach> good morning
<didrocks> hey dholbach!
<dholbach> salut didrocks - comment Ã§a va?
<didrocks> dholbach: Ã§a va bien, et toi ?
<dholbach> trÃ¨s bien, merci :)
<mpt> Whatever happened to the âtrivialâ bug tag?
<mpt> Ah, it became âbitesizeâ
<xnox> bah, my irc proxy lost the game
<xnox> and doko is not here now =(
<xnox> dholbach: "less funny qt4 apps" how funny are they? do they look like windows 95?
<xnox> hallyn: the version symbol doesn't matter, but there are two new functions. Find out which upstream release they appeared in, and add it to symbols file with that version e.g. "2.4"
<xnox> dholbach: when qt4 apps look that funny, it most likely means that unity-settings-daemon (or gnome-settings-daemon) are not operational.
<xnox> mdeslaur: and in systemd unit file, one can declare what reload command does as a script...
<Laney> guten tag xnox
<Laney> it's certainly not a lack of *-s-d, you'd notice that way quicker
<xnox> Laney: guten tag =) Ich kann nicht sechen wenn ich IRC verlassen habe.
<seb128> xnox, welcome back!
<ogra_> lol
 * seb128 assumes you were off, I don't see I saw you active on IRC this week
<Laney> haha
<xnox> seb128: yeap.
<xnox> but i had to restart the proxy this morning, thus working off irclogs.ubuntu.com
<Laney> no logs?
<xnox> i have some logs.... not all
<seb128> well, just assume that if people need something they are going to ping you again
<xnox> seb128: but i like reading about funny breakages over the past days =)
<Laney> mumble's theme is indeed wrong
<Laney> hrm
<seb128> yeah, I noticed as well with virtualbox
<Laney> how does that work?
<seb128> not sure
<seb128> shrug, https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.6+dfsg-1ubuntu1
<seb128> 30M diff.gz, who wants to review it?
<seb128> Laney, do you look at it? I start looking but I don't want us to dup work
<Laney> seb128: was looking, yeah
<Laney> Riddell: mitya57: do you know how qt4 gtk theming it supposed to work?
<Laney> It's "Desktop Settings (Default)" in qtconfig-qt4, if I set it to "GTK+" then things look normal
<Laney> so maybe it's not detecting right?
<Riddell> maybe, it detects the window manager I think to work out what theme to use
<seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1305294
<ubottu> Ubuntu bug 1305294 in qt4-x11 (Ubuntu) "QT uses incorrect theme when GNOME_DESKTOP_SESSION_ID is unset" [Medium,Confirmed]
<seb128> get the source, grep for GNOME_DESKTOP_SESSION_ID?
 * seb128 is downloading, but it's taking a bit
<Laney> seb128: indeed, that is correct
<Laney> what was setting that before?
<seb128> Laney, that is still set in utopic for me
<Laney> not here
<Laney> seems it's set by gnome-session
<seb128> OH
<seb128> it's set in /proc/pidof gnome-session/environ
<seb128> not in compiz
<Laney> hahaha
<seb128> I bet it's the move to start compiz from an upstart job
<seb128> xnox, !!!
<Laney> yes
<xnox> isn't GNOME_DESKTOP_SESSION_ID the deprecated one?
<seb128> it is
<xnox> or is that current?
<Laney> it needs to be set
<seb128> but see https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1305294
<Laney> to anything, for this qt detection
<ubottu> Ubuntu bug 1305294 in qt4-x11 (Ubuntu) "QT uses incorrect theme when GNOME_DESKTOP_SESSION_ID is unset" [Medium,Confirmed]
<Laney> or we could change Qt ...
<xnox> we had an upstart job that sets it to bogus value for Qt.
<seb128> right
<Laney> where?
<Laney> I have no such job
<xnox> in /usr/share/upstart/sessions/gnome-session.conf
<seb128> well, that's only for gnome-session
<seb128> compiz/unity doesn't get it set
<xnox> right. hm
<seb128> which means when you start apps from unity you get no theme
<Laney> oh yes, the ordering is wrong
<xnox> i thought we did do $ initctl set-env
<seb128> what ordering?
<seb128> dholbach, ^ btw, your theme issue is being discussed
<Laney> it needs to be set-env but also unity can start before gnome-session I think
<seb128> that issue is not really new
<seb128> well it is for unity since it didn't have it when gnome-session was running compiz, rather than having an upstart job
<seb128> bug the bug I listed just before describe a similar issue when using indicator-sound in trusty
<xnox> Laney: seb128: should we just stick a GNOME id into e.g. /etc/X11/Xsession.d/ or whatever it is called?
<Laney> could just put it in xsession-init.conf
<xnox> but i guess, then we will set it too many times. Do we actually want that always set?
<xnox> or e.g. it shouldn't be set on Kubuntu?
<seb128> we don't want it see under non gnome-session sessions
<Laney> [ "$SESSIONTYPE" = "gnome-session" ] && initctl ...
<xnox> seb128: hm, and xubuntu/lunubuntu etc also want it, no? there is no gnome-session running but it does want gtk styling?
<xnox> (well maybe not lxqt)
<seb128> well, historically it was gnome-session setting it
<Laney> it's set by gnome-session
<Laney> so let's just keep that keying
<seb128> so if we want to get back to that
<seb128> it's only a qt4 thing anyway
<seb128> qt5 doesn't have that issue
<Laney> will upload it to xsession-init.conf
<Laney> xnox: confirm/deny
<xnox> Laney: i think that should be fine.
<xnox> Laney: long term, I thought we wanted to patch qt4 to not care about that variable.
<Laney> yeah I can't think of a better one off the top of my head
<xnox> on my desktop url-dispatcher was held back, instead of removing upstart-app-launch & installing ubuntu-app-launch
<dholbach> seb128, thanks - I'll have a look at the bug
<Laney> xnox: grh, test failed in test build
<Laney> "104 - ensure job gets given default environment"
<Laney> and it's left a stray process
<Laney> naughty
<seb128> dholbach, well, the bug is not that informative, just take it as "it's being worked by some our best people, so no worry it's going to be resolved" ;-)
<seb128> cjwatson, xnox: is anyone looking at the daily-live isos not having a boot menu since syslinux 6?
<cjwatson> seb128: I've spent some time looking at it but not got very far yet
<xnox> cjwatson: should broken cd be stashed and syslinux reverted to 4?
<cjwatson> I can see that it gets into gfxboot-theme-ubuntu, since I can insert trace statements there and have them take effect
<cjwatson> xnox: I think that would be very intrusive at this point
<seb128> is there a workaround to start the install mode?
<cjwatson> Now that I'm emerging from the livefs work I'll have another look at it today
<seb128> you can hit enter and it boots in the live session
<seb128> cjwatson, thanks
<xnox> cjwatson: can maybe-ubuntu become the default boot option? cause at the moment the current default ends up as "nothing" e.g. boot into live session
<xnox> cjwatson: i didn't manage to trace where "maybe-ubiquity" is set as the default.
<xnox> (on most products)
<Laney> grump
<Laney> xnox: can you build upstart in sbuild atm?
<xnox> Laney: typically yes, one must disable eatmydata & not build on top of overlayfs.
<xnox> Laney: just commit things to lp:ubuntu/upstart and I can pull / upload.
<Laney> oh okay, the latter could be me
<xnox> hence i have e.g. utopic-plain-amd64 schroot config that disables overlayfs & eatmydata.
<shadeslayer> I don't suppose there's a way to pull all the latest build logs for a package?
<cjwatson> xnox: no, would rather not attempt workarounds, shouldn't be too hard to fix
<cjwatson> shadeslayer: easy enough with launchpadlib
<shadeslayer> right, so nothing pre written then :)
<cjwatson> there's a build_log_url attribute on builds
<cjwatson> don't know of one
<shadeslayer> ok, I shall write one
<dholbach> seb128, I like the sound of "it's being worked by some our best people, so no worry it's going to be resolved" a lot
<seb128> dholbach, ;-)
<Laney> I gave up building locally and uploaded to a PPA
<xnox> Laney: builds fine here.
<xnox> Laney: virt PPA may fail, due to old kernel.
 * Laney unleet powers
<xnox> ion: Built successfully
<xnox> Laney: push to lp:ubuntu/upstart, and I'll test build & upload.
<Laney> what is ion?
<xnox> Laney: it's "I: built successfully" with color-code from sbuild, copy&paste artifact
<Laney> I see
<Laney> xnox: okay, pushed
<infinity> xnox: By "color-code" you mean "it contained a tab". ;)
<infinity> Or, not even.
<infinity> "i: foo" in many clients will auto-expand "i:" as if you tab-completed.
<xnox> infinity: "i believe what i see" =))) i've copied green text, hence I called it color coded =))))
<infinity> xnox: Yeah, I think it was just auto-expansion messing with you.
<infinity> (Since ion is in this channel and all)
<xnox> infinity: right, silly xchat =)
<xnox> shouldn't mangle pastes
<GunnarHj> pitti: ping?
<dholbach> elopio, happy birthday! :)
<Laney> xnox: did actually build in $ppa ;-)
<Laney> xnox: uploading myself then
<seb128> Laney, is that something we should SRU as well?
<Laney> Could do I guess
<seb128> Laney, oh, and seems like xnox already uploaded
<Laney> oh
<Laney> that little terror
<Laney> he took the Changed-By :P
<Laney> anyway if they're preparing an upstart SRU then I suppose it could go in there
<seb128> right
<seb128> xnox, can you make that happen?
<Laney> jodh: got a trusty upstart sru in the works?
<xnox> Laney: i have a few things that need cherry-picking into trusty. enough by now to make an SRU release.
<xnox> Laney: does this actually affect trusty as well? didn't think compiz was spawned as upstart job back then.
<Laney> it affects the indicators there
<Laney> see the bug report, that's from a trusty user
<xnox> aha.
<xnox> yeap, i remember that.
<Laney> but same root cause
<Laney> environment not set early enough
<xnox> (vlc staring looking odd)
<xnox> Laney: "=== modified file 'debian/upstart.cron.daily' (properties changed: +x to -x)" -> why is that?
 * xnox skipped that in the review, but now noticed it when cherry-picking into trusty
<Laney> didn't do that on purpose
<xnox> ack.
<xnox> Laney: for trusty, do we also want adding "unity8-x11" & "unity8-mir" to upstart-xsessions?
<xnox> Laney: no bug reference in the utopic upload.
<Laney> xnox: hrm, don't think that's worth it
<Laney> I think the trusty unity8 sessions are what they are
<xnox> Laney: well, pretty crappy without upstart, no?!
<Laney> xnox: It ran some script to start unity8 manually
<Laney> so it did work
<Laney> I don't know if other jobs will require modification too
<xnox> right, and I don't want to be testing that. alright.
<Laney> xnox: you know the executable bit isn't preserved in the source package?
<xnox> Laney: correct, because of source 1.0 format.
<Laney> jus' sayin'
<Laney> :-)
<xnox> Laney: we typically use $ bzr bd -S, to build the source package.
<xnox> Laney: you are the first one to touch it "differently" =)
<Laney> it's because I modified it in a source package then cp-ed it back in
<xnox> ah, even more obscure.
<xnox> #1317727, #1305294, #1174272 enough for an SRU
<xnox> Laney: can you add tescase/impact/description/etc SRU bits to bug #1305294? Or should i?
<ubottu> bug 1305294 in upstart (Ubuntu Trusty) "QT uses incorrect theme when GNOME_DESKTOP_SESSION_ID is unset" [Undecided,In progress] https://launchpad.net/bugs/1305294
<pitti> hey GunnarHj
<GunnarHj> pitti: Hi Martin!
<GunnarHj> pitti: Since you didn't respond instantly, I just sent a mail to you and dpm_.
<pitti> GunnarHj: ah, good
<seb128> hey pitti, wie gehts?
<Laney> xnox: there we go
<xnox> ta
<pitti> hey seb128; gut, danke! et toi ?
<seb128> pitti, je vais bien, merci !
<dpm_> thanks GunnarHj for the e-mail, I'll try to reply with my thoughts asap
<GunnarHj> dpm_: Ok, great!
<tkamppeter> OdyX, I have fixed Debian bug 752146 in the GIT of cups-filters. Can you upload it to Debian, so that it syncs in Ubuntu? Thanks.
<ubottu> Debian bug 752146 in cups-filters "[cups-filters] Missing rastertopdf filter" [Normal,Open] http://bugs.debian.org/752146
<xnox> cjwatson: i have a "fix" for isolinux =)
<xnox> cjwatson: our bootlogo cpio archive only has init, without all other files.
<xnox> if all other files are included inside it, then all is fine
<xnox>  sudo cpio -ivd < bootlogo
<xnox> ls init *.tr *.hlp *.pcx back.jpg gfxboot.cfg langlist | cat | cpio -o > bootlogo
<xnox> it appears that file access outside of the bootlogo archive is no longer operational and there is upstream discussion about it
<xnox> http://www.syslinux.org/archives/2013-July/020398.html
<xnox> not sure where repacking of "bootlogo" file should happen.
<cjwatson> xnox: ah, that's a hassle
<cjwatson> xnox: thanks for tracking that down, I should be able to sort it out in debian-cd or something
<xnox> cjwatson: right, i'm working out on which files to include, cause one also needs *.fnt and maybe others.
<xnox> cjwatson: but not just $ ls -1 * | cpio -o > bootlogo, cause then one gets options one shouldn't see. E.g. "back..." -> which does nothing / crashes the installer
<cjwatson> Well, that I can probably work out by grepping gfxboot-theme-ubuntu code
<xnox> cjwatson: and "Help" button, which i've never seen before, like ever. It has explanation text about each of the Fn keys etc.
<cjwatson> Fairly limited number of operators that open files
<cjwatson> Yes, I know about all of this :)
<xnox> =)))) ok
<xnox> cjwatson: i rest my case, and handing over to you =)
<cjwatson> This is pretty problematic because a lot of this stuff we're relying on not having to duplicate in and out of the bootlogo archive.
<cjwatson> I'll look at it but it's at least somewhat tempting to patch those functions back in.  Will have to have a design think.
<cjwatson> I'm particularly concerned about having to have things like gfxboot.cfg duplicated inside and out.  It will confuse the hell out of anyone trying to customise the image.
<xnox> yeah, it is ugly.
<cjwatson> And the assertion about GRUB in that mailing list post is just bizarre.  GRUB needs no such thing, it has all the filesystem handling code you might ever want.
<xnox> the mailing list thread ended with "anyone please step up and tell us if you need this functionality" shame it only took us a few years to spot the problem.
<cjwatson> Is that mailing list available in mbox form somewhere so I can reply to that usefully?
<xnox> cjwatson: what are our chances to switching to pure grub2? does it have any gfxboot prettiness we can leverage on par with current theme?
<cjwatson> I tried a while back but ran out of time
<cjwatson> I'd prefer that ultimately, but it will take a while
<cjwatson> Oh yikes, it's the whole COMBOOT API?
<cjwatson> Argh
 * cjwatson finds the mbox archives
<xnox> wgrant: please join #ubuntu+1-maint for idling & mentoring folks =)
<bdmurray> seb128: https://errors.ubuntu.com/oops/b0a749da-f7d3-11e3-b432-fa163e707a72
<bdmurray> seb128: that now has a link to the bucket / problem in it
<bdmurray> seb128: although the retrace failed
<bdmurray> seb128: http://pastebin.ubuntu.com/7674870/ <- missing debug symbol packages
<xnox> cjwatson: it's milestone week for flavours next week, and we'll need working images. hence tracking the above regression down =)
<seb128> bdmurray, thanks
<hallyn> netcf - fix symbols
<hallyn> ask for sync of netcf from experimental
<seb128> bdmurray, weird, those packages are not in the bt I think, they shouldn't fail the retrace
<hallyn> huh
<hallyn> my insert key is ging mad
<cjwatson> xnox: Yeah, thanks for the effort.  I'll get a workaround in place before I leave this evening, if at all possible
<bdmurray> seb128: iirc apport also does a look of stuff in procmaps and install those packages too
<seb128> bdmurray, k, I'm unsure why that failed, I'm going to try to submit it again to see
<cjwatson> xnox: Right, that's hopefully sorted; with any luck I'll even have time to test that end-to-end before I leave, although I'm racing against the clock
<cjwatson> I think there's one remaining bug, namely that the "Other Options" menu will have changed contents for live images, I think
<cjwatson> But that isn't fatal and I can sort it out next week
<xnox> yeah, not fatal at all, given that one can specify those by typing anyway.
<xnox> (well those that are listed there in e.g. trusty images)
<cjwatson> The rest seems to work again in my hacky test harness thing
<desrt> hi.  is there a recommended board config (qemu switch -M) to use for an arm machine that's SMP capable and supported by the kernel (ie: no abort due to unsupported board on startup)?
<cjwatson> xnox: Thanks again for tracking that down.  Would've taken me ages
<xnox> np
<manjo> Riddell, there is a fix in upstream debian for the k3b build break in utopic https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739312#51 can you please merge that change ?
<ubottu> Debian bug 739312 in src:k3b "FTBFS with libav10" [Serious,Fixed]
<Riddell> manjo: yeah I'll take a look when I can (may be monday, hope not)
<manjo> Riddell, would you like me to open a bug with info and assign to you ?
<Riddell> manjo: sure
<manjo> Riddell, https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/1332591
<ubottu> Ubuntu bug 1332591 in k3b (Ubuntu) "[Utopic] Build failure in k3bffmpegwrapper.cpp" [Undecided,New]
<Riddell> thanks manjo
<jamespage> stgraber, whats your opinion on bug 1068756 ?
<ubottu> bug 1068756 in procps (Ubuntu) "IPv6 Privacy Extensions enabled on Ubuntu Server by default" [Undecided,Confirmed] https://launchpad.net/bugs/1068756
<jamespage> stgraber, IMHO this creates alot of complexity if not disabled on server
<cjwatson> xnox: OK, it's kind of wonky but we at least get something on server now
<cjwatson> kicking a desktop respin, won't be around to watch it finish
<cjwatson> I'll have another look on Sunday/Monday and see what remains
<manjo> Logan_, there is an upstream fix for kradio4 build failure https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748147#12 can you please sync or merge that change ?
<ubottu> Debian bug 748147 in kdelibs5-dev "Breaks compilation of kradio4" [Important,Fixed]
<stgraber> jamespage: right, we had a chat about that during vUDS I think (or something), thing is, privacy extensions do make sense on some kind of servers and clearly don't on other (say a mail server) and it's hard to have it set to the right value everywhere...
<jamespage> stgraber, it becomes complex in environments with firewalls with egress filtering
<stgraber> jamespage: but I think I agree that for cloud instances and default server install, we probably want privacy extensions off. Making sure that we however don't change the behavior for people upgrading.
<jamespage> stgraber, +1 on that approach
<stgraber> jamespage: personally I have it disabled on all my servers (specifically for the egress firewalling bit) and on for all desktops and test systems, though representing that through packaging may be tricky (because the definition of server and desktop itself is pretty lburry)
<catbus1> Hi, anyone know the difference between the server images downloaded on http://www.ubuntu.com/download/server/ and http://www.ubuntu.com/download/cloud?
<hallyn> xnox: hey, so i'm trying to make sense of libnetcf1.symbols.  each new version of libnetcf1 puts ncf_{get,put}_aug in private symbols (using src/netcf.syms) for the very latest version.  Am I right in assuming that's a problem upstream?
<xnox> reading
<jamespage> stgraber, where does it get configured from?
<stgraber> jamespage: procps
<hallyn> xnox: eh, well they are private symbols so i guess it doesn't matter
<xnox> hallyn: well. yes and no.
<stgraber> jamespage: /etc/sysctl.d/10-ipv6-privacy.conf
<xnox> hallyn: it's marked private & thus can change, but it is public since it's exported and I can link against it.
<xnox> hallyn: thus the same method should be employed as for e.g. eglibc private symbols. Strict version control on (>= 0.2.4 & << 0.2.5~)
<hallyn> so they're doing the right thing
<xnox> hallyn: since you want to force rebuilds, upon new upstream release.
<xnox> hallyn: yeap, such that things that used NETCF_PRIVATE (0.2.3) symbol will have to be rebuild with (0.2.4), and 0.2.5, and etc.
<hallyn> cool.  should have a debdiff soon adding symbols to libnetcf1.symbols
<hallyn> hm, sitll have one error (though pkg finished building)
<hallyn> i guess it doesn't like empty sections
<xnox> hallyn: checkout e.g. /var/lib/dpkg/info/libc6:amd64.symbols, it has example of how to version control private symbols at the very top.
<xnox> well actually multiple examples.
<hallyn> xnox: oh ok - i'd looked at eglibc but it seemed to have nothing
<xnox> hallyn: source package has build machinery to gererate common arch & OS specific patches and then generate symbols files based on that.
<peba> https://launchpad.net/ubuntu/trusty/armhf       #should this link work ? currently I get just timeout error ?
<xnox> hallyn: thus it's best to look at the resultant contents generated in the binaries themself.
<hallyn> xnox: what I have so far is:  http://paste.ubuntu.com/7675612/
<xnox> no, that's not quite what you want.
<hallyn> feh
<xnox> the whole symbols file looks odd, as debian revvision shouldn't be present.
<xnox> (symver)NETCF_PRIVATE_0.2.4 1:0.2.4
<xnox> is one thing you want
<xnox> and then you want to define alternative dependency template & ask to use that for private symbols.
<xnox> hallyn: i think that's more correct http://paste.ubuntu.com/7675655/
<xnox> hallyn: not tested, just going off libc6 example and $ man deb-symbols which explains the grammar of the symbols file
<xnox> at the moment, anything that uses NETCF_PRIVATE_0.2.3 symbol ends up with a dependency "libnetcf1 (>= 1:0.2.3)" but should end up with an upper restriction as well.
<xnox> due to private, yet exposed symbol, thus infact public.
<hallyn> xnox: so what, the package's symbosl file will be autogenerated by merging that file with src/netcf.syms?
<xnox> hallyn: huh, no. src/netcf.syms is used to generate the symbols file of the library. debian/libnetcf1.symbols is used by dpkg-gensymbols & etc tools to correlate that you as a maintainer have assigned desired dependencies for a given symbol usage.
<hallyn> hm, how come https://wiki.debian.org/UsingSymbolsFiles doesn't point ot deb-symbols((5)? thanks )
<xnox> expanded debian/libnetcf1.symbols is stored inside the deb of libnetcf1.deb and on disk at /var/lib/dpkg/info/*.symbols
<xnox> and when other things link against libenetcf1, symbols are cross-checked to generate substitues in the ${shlibs:Depends}
<xnox> previously people had to write out ${shlibs:Depends} by hand =) now, only library maintainer has to do it once, and everyone gets correct deps.
<xnox> hallyn: i think that debdiff is correct, but do check that by e.g. building a dummy package which uses ncf_put_aug symbol
<xnox> hallyn: it's shlib:Depends should end up with >> 0.2.4 << 0.2.5
<dobey> how do i get the requisite upstart processes running on the user's session bus, without starting a whole new X session? just dbus and upstart only?
<xnox> hallyn: and other packages just >> 1:0.2.2
<xnox> dobey: i'm not sure what you mean, you can trivially join existing upstart session. All you need is the matching UPSTART_SESSION variable which are a in /run/user/$UID/upstart/sessions/
<dobey> xnox: i don't have an existing upstart session
<dobey> xnox: i'm trying to test some stuff in an lxc and it requires upstart
<xnox> dobey: oh, i see. You can start a new user upstart session by spawning $ init --user
<xnox> dobey: it does need e.g. XDG_RUNTIME_DIR and HOME set.
<dobey> won't init --user try to start x and everything?
<dobey> and probably cause horrible problems inside an lxc?
<xnox> dobey: that will emit startup event and start everything that keys on it in /usr/share/upstart/sessions, which doesn't start X, display manager starts it for us.
<dobey> because with lxc, the $HOME from my host is bind mounted inside the lxc as the home
<xnox> dobey: you can choose to pass --no-startup-event
<xnox> dobey: then nothing will be running, unless you manually do $ start job-name
<xnox> dobey: i'm talking about environment variable. so you can do e.g. HOME=$(mktemp -d) XDG_RUNTIME_DIR=$(mktemp -d) init --user --no-startup (that should work)
<xnox> dobey: can you explain what you are trying to test, and why you need a new upstart user session?
<xnox> dobey: and minimal lxc container has no user session jobs installed, thus actually in a typical lxc container spawning a new user session will do nothing.
<dobey> xnox: i'm trying to test pay-service and i need an upstart user session because it starts the ui via ubuntu-app-launch
<xnox> dobey: won't you need a bit more than just upstart user session to start ui? you will need X or Mir as well, no?
<xnox> dobey: i'm not quite sure how testable UIs are started via ubuntu-app-launch, since they will be contained.
<dobey> bug i keep getting errors like error getting unix process id for org.freedesktop.DBus: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get PID of name 'org.freedesktop.DBus': no such name
<xnox> dobey: look into autopilot code, it has code to start apps via ubuntu-app-launch I belive.
<xnox> dobey: well, you need dbus started as well. so do $ start dbus
<dobey> xnox: i have X bound to my host X
<dobey> dbus is running
<xnox> check your environment.
<xnox> you may have inherited to much of environment variables from your host.
<xnox> dobey: how did you enter the lxc container?
<xnox> what's your $ env
<xnox> before starting anything?
<dobey> ** (process:29958): WARNING **: Unable to find job 'application-click': GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.ubuntu.Upstart was not provided by any .service files
<xnox> you don't want to be doing lxc-attach --keep-env
<dobey> anyway
<dobey> entered lxc via ssh
<dobey> com.ubuntu.Upstart is not on the session bus, which is my current problem
<xnox> dobey: how did you start session dbus? (note not the system one)
<xnox> let me do a quick script to make it clear
<xnox> cause after spawning session dbus, session upstart should join it.
<smoser> can i get an archive admin to NAK cloud-init in
<smoser>  https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=cloud-init
<xnox> dobey: via initctl notify-dbus-address "$DBUS_SESSION_BUS_ADDRESS" in the post-start of the session dbus
<smoser> i'm wnting to re-upload with fix for bug 1325746
<ubottu> bug 1325746 in cloud-init (Ubuntu Trusty) "dpkg-reconfigure doesn't work as expected" [Medium,Triaged] https://launchpad.net/bugs/1325746
<dobey> xnox: i killed everything and "start dbus"
<xnox> dobey: that will start system dbus in the lxc container, unless you sourced and set UPSTART_SESSION environmental variable to operate agains the session init you spawned in the lxc container.
<xnox> cause you need a session dbus to be started via session upstart
<dobey> xnox: i didn't run it as sudo, so it would be impossible for it to start a system bus without being root
<dobey> but it started a session bus
 * dobey kills everything
<dobey> xnox: do i need to init --user -- zsh or something?
<xnox> dobey: well $ init --user &
<xnox> dobey: that will give you pid of session init.
<xnox> dobey: next you need to fine the session file in the XDG_RUNTIME_DIR of the session init. which will have something liek UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/18004 in it
<dobey> whee, that sucked. did pkill -9 ssh in the lxc and it killed my host X
<xnox> then you need that variable in your environment.
<hallyn> xnox: (of course that debdiff should use 1:0.2.4-2 rather than 1:0.2.4-1ubuntu1 :)  building a test.  i've read through a few more readings on the symbosl stuff and it still doesn't maek sense to me, but
<xnox> once you have that variable in your environment, you will be operating against session init by default.
<hallyn> oh, now i see
<dobey> hmm
<hallyn> so the debian/libnetcf1.symbosl file lists all the symbol versions which are in this library
<dobey> life was so much simpler when all you had to do was `eval something`
<xnox> then $ start dbus, or to be sure UPSTART_SESSION=unix:abstract=/..... initctl start dbus
<hallyn> that's why it cant' have the private symbols for older versions.  gotcha
<xnox> hallyn: right, well "the debian/libnetcf1.symbols file lists the minimal version constraints one must have on this library when using a particular symbol"
<xnox> when one starts out, one typically slaps ITP version number on all of them, or if there is good historical documentation as to what/when/where was introduced one can accurately set correct minimal versions.
<xnox> thus e.g. ensuring that fairly conservative software can be still installed on older releases.
<xnox> e.g. ubuntu-emulator-bin can be compiled on utopic, yet installed on precise. As only a handfull libraries are used and only stable/old symbols from there.
<xnox> on all symbols files are properly maintained/versioned.
<seb128> xnox, you still plan to upload that upstart fix before the w.e right?
<xnox> dobey: in upstart test-suite we have python scripts to spawn user session for testing et.al. you might want to look into that.
<xnox> seb128: yes.
<seb128> thanks
<dobey> xnox: i want our reliance on mir for security on the phone to not make it such a pain to actually develop and test our stuff on a normal system :)
<guest27497> how to make an os like ubuntu ?
<guest27497> #ubuntu how to make an Os
<xnox> dobey: one should be able to launch things and UI without using ubuntu-app-launch.
<xnox> dobey: and without user-session init.
<dobey> xnox: yes, i can just run any app directly with qmlscne foo.qml normally
<xnox> dobey: and i'm sceptical of dbus service launching UI.
<dobey> xnox: the problem is that pay-service always launches the UI with ubuntu-app-launch
<xnox> dobey: how is that not sufficient for testing? you'd test pieces individually.
<dobey> and i don't know how to test the full process of the service without that
<xnox> dobey: sounds very odd, can you not mock it out?
<dobey> xnox: because i'm writing code that uses the pay service, and i'm trying to test that my code behaves correctly in response to what the pay-service sends it
<dobey> xnox: in unit tests sure, but i'm trying to do live testing
<xnox> dobey: oh, so you are not even testing the ui? so yeah, payment service should be better and not try to do silly things with ui, when it's only used on api level....
<xnox> dobey: i'd talk to payment-service folks about it.
<dobey> well i'm not trying to test the UI, but the UI coming up is part of the process
<dobey> there is no way to test my code without that UI coming up
<xnox> dobey: discuss it with tedg and the like people.
<xnox> dobey: cause it sounds like getting a better testing interraction between the two would be better.
<xnox> dobey: e.g. in ubiquity i did make adjustments and made it behave different when driven by testability framework, instead of launched normally, without taking a significantly different code-path.
<xnox> But rather provide hooks for a service to plug into ubiquity.
<dobey> xnox: yes i've been moaning about these issues to ted all morning too
<dobey> but i don't think there is anything specifically for pay-service to make this easier
<dobey> it's a general problem, not a pay-service problem
<xnox> dobey: well if you are writting gui stuff you can (abuse) autopilot. If your unit-tests are executed from python autopilot stuff, you have a full blown thing to make things work.
<xnox> dobey: also why are you using an lxc container?
<dobey> xnox: because i want to keep my production environment on lts
<xnox> ..
<xnox> dobey: i thought you work in R&D =) and not in stable maintenance support teams. I find it's easier to spin up stable releases in VMs, containers, etc. Rather than the other way around.
<dobey> xnox: i wish i worked in R&D. we don't have any R&D :) we have D
<dobey> xnox: i find it's easier to keep my system working correctly, on lts releases :)
<xnox> dobey: working with ubuntu-app-launch only sounds strange, especially when one should be able to launch things on unity7/legacy desktops
<xnox> dobey: and I understand that ubuntu-app-launch can only do launching on the converged stack.
<xnox> dobey: hehe. I tend to believe that I am in R&D =)
<dobey> xnox: i work in stress management ;)
<hallyn> xnox:  yeah, success i think.  symbols for pkg not accessing ncf_get_aug: Depends: libc6 (>= 2.2.5), libnetcf1 (>= 1:0.2.2)
<hallyn> (s/symbols/deps, obviously)
<hallyn> xnox: for pkg with such access: Depends: libc6 (>= 2.2.5), libnetcf1 (>> 1:0.2.4), libnetcf1 (<< 1:0.2.5)
<xnox> \o/
<xnox> hallyn: i think that's exactly what we need =)
<hallyn> xnox: do you mind then updating the version for debian and pushing to experimetnal?
<xnox> hallyn: nah, i provided the patch to the maintainer, he can do the rest =)
<hallyn> xnox: haha, but i don't have the rights to push :)  but ok, i'll integrate and ask someone else to sponsor (who may then find somethign else i messed up while he's at it :)
<hallyn> xnox: thanks
<xnox> hallyn: well, you can push to the git repo right? and dput .dsc onto mentors.debian.net?
<xnox> hallyn: i'm happy to do the sponsoring & upload it into experimental and/or sid.
<xnox> hallyn: but I don't want to like NMU it, nor take credit for testing, I threw that together without even test-building it.
<hallyn> xnox: another thing wrong in the pkg i think - there isnt' actually a git tree for the packaging
<hallyn> I'll remove that
<xnox> hallyn: oh, yeah. Better to not point anywhere, if that's not up-to-date / actually really used.
<hallyn> perhaps i should request a tree on git.debian.org.
<hallyn> xnox: thanks again :)
<dobey> well finally managed to get upstart and dbus in the lxc
<dobey> but launching the app fails with a SIGABRT :(
<xnox> dobey: yeah \o/ and no /o\
<dobey> ah
<dobey> because aa-exec-click :(
<hallyn> barry: hi!  would you mind sponsoring http://people.canonical.com/~serge/netcf-src-0.2.4-2/netcf_0.2.4-2.dsc into debian experimental?
<xnox> dobey: which brings us back to -> payments service should be able to avoid things.
<dobey> xnox: i still don't think this is a pay-service issue
<xnox> dobey: replace aa-exec-click with e.g. #!/bin/sh \n exec $@ ?
<xnox> dobey: lxc container, may not be capable of apparmor confinments, unless set up to work with those. I'm not sure which capabilities the container should have for apparmor to be operational.
<xnox> and well, debug aa-exec-click itself, as to find out what's failing. Missing installed policies? or some such.
<sarnold> xnox: you guessed it exactly, apparmor doesn't yet do nested profiles
<stgraber> xnox: currently apparmor doesn't support profile stacking, so containers can't set a profile for things running inside them. It's something jjohansen1 has been working on for a while though and we should have this finally implemented for 15.04.
<stgraber> xnox: until then, you may be able to run a contained app inside an LXC container if you turn off apparmor for the container (lxc.aa_profile = unconfined), set "lxc.cap.drop =" (so that mac_* aren't dropped) and then in theory apparmor in the container will be allowed to load new profiles into the kernel and move tasks to using it
<jjohansen1> xnox: so currently its an either OR situation. Either lxc has apparmor enforcing on the container (current situation), OR you can disable the lxc mediation on the container, and set up an apparmor namespace for the container and have apparmor mediation in the container.
<jjohansen1> the second option isn't directly supported atm, so it takes a little work
<xnox> stgraber: or like fix payment-service to be testable without requiring (A) upstart user session (B) session dbus (C) graphics (D) ubuntu-app-launch (E) apparmor (F) doing all of above on LTS machine using development trunks.
<dobey> xnox: i'm ok with exec $@, but one can't just do exec $@, as the arguments to aa-exec-click are in fact arguments to it. what to actually run is passed after --
 * dobey doesn't quite remember how to deal with that in shell
<xnox> dobey: man getopt
<stgraber> dobey: loop through $* and call shift until you see --, then exec with $* ?
<xnox> yeah, ^ sounds better
<stgraber> for arg in $*; do
<stgraber>     [ "$arg" != "--" ] && shift && continue
<stgraber>     shift && break
<stgraber> done
<stgraber> exec $*
<dobey> eh, but i'm still back to the problem of the click not finding the included c++ module; the same as if i just run qmlscene foo
<dobey> yay, finally got it
<dobey> or not :-/
<dobey> u-a-l still aborts when it tries to launch the app
<ion> stgraber: I think you want to use "$@" (also: âfor arg in "$@"â is equivalent to âfor argâ).
<stgraber> ion: shouldn't really make a difference in this case, but yes, $@ is usually better
<ogra_> using case instead of [] too :)
<stgraber> ogra_: I wanted it to be compact, case, entry, default, esac is pretty long for the same result :)
<ogra_> true ... if its only one thing you match it wont make much of a difference
<dobey> sigh
<slangasek> stgraber: you certainly should be using "$@" here instead of $*; for anything that takes arbitrary arguments you can't assume there are none that require quoting (e.g., arbitrary filenames)
<slangasek> and therefore one should always use $@ in such constructions instead of $*, because people are prone to cargo-culting bad habits ;)
<ScottK> rbasak: I think if someone merged pycurl, then python-tornado could be a sync.
#ubuntu-devel 2014-06-21
<bluesabre> 1
<mitya57> Laney: sorry, was offline. Looks like you already fixed that :)
<Laney> mitya57: yeah, thanks
<joey_> hi
<joey_> There is this thing called Infinality
<joey_> But I think it as been abandoned
<joey_> how would I update it ?
<Noskcaj> joey_, link to it?
<joey_> That's the website : http://www.infinality.net/blog/ , but I use this https://github.com/chenxiaolong/Debian-Packages currently
<joey_> It's only packaged officialy in Fedora
<joey_> And I would love to package it "upstream", but since there has been freetype updates, etc... And I honestly do not have the skill to do that yet
<Noskcaj> https://launchpad.net/~no1wantdthisname has a ppa for it
<joey_> oh yeah i know
<joey_> oh bohoomil
<joey_> I tried to deal with that one
<joey_> but its a arch linux build scripts
<joey_> I have no idea how to deal with this
<Noskcaj> Just so you know, the debian bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739842
<ubottu> Debian bug 739842 in wnpp "RFP: fontconfig-infinality -- The purpose of these patches is to freely provide the nicest font rendering of any operating system. The second goal is to provide customization so that the end user is able to adjust the settings to his or her taste." [Wishlist,Open]
<joey_> Uh what is this ?
<Noskcaj>  Someone in debian asking for it to be packaged
<joey_> Ah :)
<Noskcaj> If you ant to maintain it in debian. Change the bug title from "RFP" to "ITP" (request for package to intent to package)
<joey_> I see
<joey_> I do that by replying ?
<Noskcaj> There's some special email command. i forget it
<Noskcaj> To package this, first get http://www.infinality.net/fedora/linux/zips/fontconfig-infinality-1-20130104_1.tar.bz2
<Noskcaj> joey_, I'll make up some basic packaging for it now
<joey_> What ? Really ?
<Noskcaj> 10 minute job, is easy
<Noskcaj> joey_, A half finished version is at https://launchpad.net/~noskcaj/+archive/build/+packages
<Noskcaj> download the source from there and finish packaging it. Then make that bug "itp" and upload this to debian mentors
<Noskcaj> contacting the debian font team might be good too
<joey_> ooo there is a debian font team
<Noskcaj> https://www.debian.org/doc/manuals/maint-guide/ has all the packaging info you could need
<Noskcaj> https://wiki.debian.org/Fonts could help too
<joey_> ok
#ubuntu-devel 2014-06-22
<hjd> I wonder why http://packages.qa.debian.org/e/efl.html is not in Ubuntu. I didn't find it listed in the sync blacklist.
<ogra_`> hjd, https://launchpad.net/ubuntu/utopic/+source/efl ... seems it didnt build on all arches
<cjwatson> hjd: should be heading into the archive nowish; it wasn't synced earlier IIRC because it overwrote some Ubuntu-modified binaries elsewhere and so required manual attention
<mitya57> Hmm, can somebody explain me why xserver-xorg-video-openchrome-lts-saucy precise upload (which I just sponsored) is in NEW?
<cjwatson> LP's ancestry calculation is buggy for things introduced post-release
<cjwatson> Makes little practical difference though whether it's in NEW or UNAPPROVED
<mitya57> Thanks cjwatson.
<hjd> ogra_`: cjwatson: Ok, I see.
<andrewrk> how does one get a package to go from "proposed" to accepted in the next release?
<cjwatson> andrewrk: https://wiki.ubuntu.com/ProposedMigration is probably what you're looking for
<cjwatson> andrewrk: What package?
<andrewrk> cjohnston, I'm looking at https://launchpad.net/ubuntu/utopic/+source/libgroove  but I realized that the answer is probably because it is waiting for libav10.1
<cjwatson> andrewrk: Yes, that's right, it's in that very large cluster
<andrewrk> is anything blocking libav10, by the way?
<cjwatson> Yes, a ton of stuff
<cjwatson> If nothing were blocking it it would go in automatically
<cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/libav10.html
<andrewrk> why does this look so different than https://release.debian.org/transitions/html/libav10.html ?
<cjwatson> andrewrk: Various reasons; in some cases we may just need no-change rebuilds; in some cases we have Ubuntu deltas that need merging; in some cases the package fails to build in Ubuntu and doesn't in Debian for some reason unrelated to libav; in some cases we may have fixed something in Ubuntu and forwarded the change to Debian but it hasn't been applied there yet
<cjwatson> All the usual things
<andrewrk> ah interesting
<andrewrk> it seems like there's nothing else to do on that transition, and we're pretty much waiting on package maintainers to upload new versions
<cjwatson> Those are contradictory :-)
<cjwatson> There's plenty left to do on that transition, exactly involving uploading fixes ...
<andrewrk> but I think all the fixes have been coded
<andrewrk> e.g. no mysteries left, just waiting for some chores
<cjwatson> That's not at all obvious
<andrewrk> I may very well be misunderstanding the situation. Here's one thing I'm looking at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739079  at the bottom it says the debian transition is at 100% and all that is left is to remove old libraries from testing
<ubottu> Debian bug 739079 in release.debian.org "transition: libav10" [Normal,Open]
<cjwatson> I just fixed renpy, for example, which was not a matter of uploading a new upstream version
<andrewrk> ah
<cjwatson> You're misunderstanding the situation
<cjwatson> Debian and Ubuntu aren't the same
<cjwatson> And it doesn't always follow that if Debian has ported everything that that means Ubuntu only has chores left to do
<cjwatson> Anyway, it's more productive for me to fix things than to argue about semantics, I guess :)
<andrewrk> yes, apologies
<andrewrk> really, I'm just excited that progress is being made, thanks for your contributions to the effort.
<cjwatson> vtk isn't obvious either, hmm
<cjwatson> Possibly a link order issue, but unfortunately cmake is not very verbose here
<andrewrk> make VERBOSE=1  ?
<cjwatson> Yeah, just not in the packaging
<andrewrk> ah
<cjwatson> I'll poke it locally
<cjwatson> libav is often a case where Ubuntu requires more work than Debian because for historical reasons we have a chunk of extra multimedia-related packages which haven't tended to be excellently maintained
<andrewrk> I see - Debian is removing things and Ubuntu continues to support them?
<cjwatson> Debian never had them in the first place
<andrewrk> ah
<cjwatson> We imported a load of stuff from debian-multimedia.org back in the day
<cjwatson> I thought it was a bad idea at the time but lost the argument :)
<cjwatson> I'll probably end up demoting some things to utopic-proposed (equivalent of removing from testing) that aren't fixed in Debian and are hard to fix, but I'd prefer to wait until everything else that can reasonably be done has been done
<andrewrk> I'm wondering if libav10 is likely to make it into utopic
<cjwatson> Yes
<cjwatson> Practically certain, we'll get it sorted
<andrewrk> Glad to hear that :)
<cjwatson> It would be far too painful for us to abort now
<cjwatson> And there's plenty of time
<andrewrk> Well. DebianImportFreeze is August 7, which is my cutoff date for getting the package I'd like to see in Utopic into Debian Unstable
<cjwatson> Sure, but (a) that's still plenty of time (b) that's not a cut-off date for finishing migrations from utopic-proposed to utopic
<andrewrk> understood
<cjwatson> All that means is that I turn off the auto-sync cron job on that date
 * andrewrk nods
<cjwatson> Riddell: Could you please merge opencv, or would you like me to do it?
<cjwatson> Riddell: (for libav)
<zyga> anyone in Budapest today?
<ari-tczew> can someone help with FTBFS? "dh_doxygen: Doxygen documentation not found"
<ari-tczew> however, only i386 builds fine, the rest archs are FTBFS
<cjwatson> Suggests that something's in Build-Depends-Indep when it should be in Build-Depends
<ari-tczew> cjwatson: there are no B-D-Indep :(
<jtaylor> if dh_doxygen is like dh_sphinxdoc you must not call it during binary-arch
<Riddell> cjwatson: I'll take a look
<ari-tczew> jtaylor: dropping it from d/rules fixes FTBFS, thanks!
<ScottK> ari-tczew: Does dropping it from b-d mean the documentation doesn't get rebuild now?
<cjwatson> Riddell: ta
<ari-tczew> ScottK: it has not been dropped from b-d, merely from d/rules
<ScottK> OK.  The question stands.
<cjwatson> There's an "override_dh_sphinxdoc-arch:" (no rule content) idiom that's used in some dh_sphinxdoc packages
<ScottK> That would probably be better.
<jtaylor> if its even the issue
<jtaylor> I was just guessing, that sphinxdoc does not work in indep is probably just a bug
<infinity> Erm, that was fixed.
<infinity> Oh, sphinxdoc was fixed, dh_doxygen has the same bug?
<cjwatson> siretart: Hm, shouldn't libavfilter-dev depend on the right -dev packages to match the Requires.private entry in its .pc file?
<cjwatson> siretart: Seems odd that something that requires libavfilter apparently has to independently b-d on libavresample-dev ...
<cjwatson> infinity: Could you merge xbmc for libav 10 support?  (Or let me know and I can do it)
<infinity> cjwatson: Meh, my TIL was just a rebuild, go nuts. :P
<cjwatson> infinity: OK, will do, thanks
<infinity> Those weird "nexus7" patches sound a lot more like "armhf" patches.
#ubuntu-devel 2015-06-15
<pitti> Good morning
<Unit193> Heya.
<Unit193> Miiight be good to merge pbuilder, due to things like 788580? (Linked earlier.)
<dholbach> good morning
<TheMuso> bdrung: Had bug 1464913 filed against portaudio19... I thought things were supposed to be installable alongside either jack version. Am I missing something here?
<ubottu> bug 1464913 in portaudio19 (Ubuntu) "portaudio19-dev can't be installed without conflicts " [Undecided,New] https://launchpad.net/bugs/1464913
<pitti> wgrant: OOI, do you know how far we are with ppc64el scalingstack support?
<wgrant> pitti: https://dogfood.paddev.net/builders/dogfood-bos01-p8-1/+history
<wgrant> pitti: I pushed a few hundred builds through it over the weekend, and identified a few issues that we need to fix this week.
<pitti> wgrant: oh, that sounds promising!
<wgrant> I don't have a reliable ETA, but it should be just a few weeks at this point.
<pitti> slangasek: ^ FYI (as we talked about it last week)
<pitti> wgrant: I'm resurrecting my wolfe nodes for the umpteenth time now, which keeps reminding me about cloudifying those :)
<wgrant> pitti: We're pretty close :)
<pitti> wgrant: do you know about the status of armhf?
<wgrant> pitti: Only two blocking issues have been identified with ppc64el. Then it's a matter of cleaning it up, getting the various fixes landed to charms and the distro, and redeploying it in a productiony way.
<wgrant> pitti: arm64 hardware is in place, but the networking is still being sorted out.
<pitti> wgrant: sounds like I should ask for scalingstack credentials nowish, to set it up for x86 testing and gain some experience with it
<wgrant> The status of our OpenStack on arm64 is not well known, but it should work once we have a working ovmf.
<zyga> pitti: hey, would you have the time to meet with me later today
<zyga> pitti: I've sent you an invite
<wgrant> I don't expect work to start on arm64 scalingstack until ppc64el is just about done.
<wgrant> Best to focus on one thing at a time.
<pitti> zyga: you mean later than the "in 50 mins" that my calendar says?
<zyga> pitti: yes
<zyga> pitti: no, not later :)
<zyga> pitti: later when the schedule says
<pitti> wgrant: right; there's lots for me to do to get x86 running, I'd like to start with that; I assume that's working reasonably well by now?
<zyga> pitti: though we can move if you want :)
<pitti> zyga: 11:00 works fine for me
<zyga> pitti: thanks, I'll see you then
<pitti> still sorting out the over-weekend backlog
<wgrant> pitti: Yep, though there's probably not enough capacity right now to move the full load over. We'll be substantially boosting the capacity in the coming weeks as we move the x86 bare metal builders into scalingstack.
<pitti> wgrant: ack, but for setting up the system and experimenting with it, getting two or three instances would suffice; is that possible?
<pitti> wgrant: the controlling nodes and swift would be in prodstack anyway
<wgrant> pitti: Yup, no problem with that at all. An RT can get you creds.
<cjwatson> wgrant: Looks like you did a bunch of copies from trusty to vivid or something, which explains some of the weirder failures there?
<wgrant> pitti: You'll need the ability to run against multiple scalingstack regions (we have two regions in London that do amd64 for both i386 and amd64, and soon to be a region in Boston that does separate ppc64el, powerpc and arm64/armhf instances.
<wgrant> cjwatson: Which?
<cjwatson> wgrant: partman-base, say, and possibly perl
<wgrant> Ohhh
<wgrant> I thought some of the failures were weird.
<wgrant> --from-suite doesn't imply --to-suite in populate-archive, I guess.
<cjwatson> I guess not ...
<wgrant> Anyway, the main purpose of this test was to test the OpenStack setup.
<wgrant> And it failed, so the test worked :P
<cjwatson> What were the failures?
<wgrant> vbuilder-manage fell over totally about 26 hours ago, not in any of the usual ways. I suspect a less intermittent form of the cloud flakiness we were seeing during early testing on Friday, but wasn't able to debug further today.
<wgrant> And lots of builds have hung during build-dep installation, which may just be the virtio issue.
<wgrant> But instance resets were at least reliable until the entire thing fell over.
<xnox> pitti: anything i can do to debug bug 1465196 ?
<ubottu> bug 1465196 in systemd (Ubuntu) "NetworkManager-wait-online job deleted to break ordering cycle" [Undecided,New] https://launchpad.net/bugs/1465196
<xnox> Bug #1465196
<xnox> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1465196
<xnox> NetworkManager-wait-online job deleted to break ordering cycle
<pitti> xnox: hm, is that the entire journal for this? there should be some more output showing the actual cycle
<pitti> xnox: can you please attach the whole journalctl -b?
<zyga-phone> Pitti: rebooting
<pitti> zyga-phone: in HO now, but no hurry
<xnox> pitti: like this? http://paste.ubuntu.com/11718410/
<pitti> xnox: ex-actly
<pitti> xnox: so, something in open-iscsi; odd, I thought I fixed these already
<xnox> pitti: open-iscsi is the culprit?!
<pitti> xnox: ah, maybe not open-scsi + NM
<xnox> pitti: i have it installed.... but i'm not using it.
<pitti> # Required-Start:    $network $remote_fs
<pitti> xnox: right, same old -- rcS init scripts being overly demanding on $remote_fs
 * xnox will just purge it.
<pitti> that can't work with NM
<pitti> xnox: thanks, will adjust the bug
<xnox> pitti: do we keep init scripts installed, even when there is native systemd job for them? shouldn't we purge them?
<xnox> .... i guess we should switch phone first, and release an lts.
<pitti> xnox: meeting now, brb
<pitti> xnox: yes, we keep the init scripts installed, but if there's a unit it gets ignored
<pete-woods> MacSlow: hi, could you point me to the test plan you normally use when making changes to unity-notifications?
<pete-woods> I
<pete-woods> I've got a silo together, but can't find the test plan
<MacSlow> pete-woods, I of course run the unit-test that come with it...
<pete-woods> MacSlow: well obviously, but is there a CI train test plan for *integration* testing
<pete-woods> ?
<pete-woods> if not, I guess that's fine, I'll just try out a bunch of things that use notifications, e.g. indicator-network
<MacSlow> pete-woods, and then there is the notification-related autopilot-tests and a bunch of manual tests I run locally or on the device (lp:unity-notifictaions/examples)
<pete-woods> autopilot tests sound good
<pete-woods> do you know where they live? I can't see them in the notifications source tree
<MacSlow> pete-woods, the notifcation ap-tests live in the lp:unity8/tests/autopilot/unity8/shell/tests
<pete-woods> MacSlow: cool, thanks!
<MacSlow> pete-woods, you can restrict the ap-testruns to the notifications ones by doing "autopilot3 run unity8.shell.tests.test_notifications"
<MacSlow> pete-woods, otherwise it takes ages to go through the whole suite
<pete-woods> MacSlow: hmm, for some reason unity8-autopilot won't install on my phone
<bdrung> TheMuso: good question.
<jamespage> cjwatson, do you have a nice way of translating tags from bzr to git during a migration?  Seems I need to translate invalid characters in some way but can't figure out quite how
<cjwatson> jamespage: In all the serious migrations I've done, I've used reposurgeon, which gives you a domain-specific language for applying whatever arbitrary transformations you like.
<arges> hallyn: hey, bug 1464175 is in need of sponsorship. are you batching up libvirt updates? otherwise I can push this one
<ubottu> bug 1464175 in libvirt (Ubuntu Vivid) "virObjectUnref() libvirtd killed by SIGSEGV" [Undecided,In progress] https://launchpad.net/bugs/1464175
<hallyn> arges: there is also https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1455608
<ubottu> Ubuntu bug 1455608 in libvirt (Ubuntu Vivid) "upstart job state switched to running before the sock file created" [High,In progress]
<arges> hallyn: yup, do you want me to merge and sponsor those?
<arges> hallyn: or whatever would be more helpful for you
<hallyn> arges: i think t and u still have pkgs awaiting verification, but ye splease i fyo umerge those that'd be great
<arges> hallyn: ok will do
<hallyn> thanks
<dgadomski> hey pitti, could you please shed some light on how gvfs works? From what I see I suspect there is a single gvfsd-fuse filesystem mounted under /run/user/<uid>/gvfs and it can map all sorts of other "filesystems" (e.g. samba shares) as directories under that fuse, is that right?
<seb128> dgadomski, it would help if you had specific questions, or stated what you try to achieve/figure out. On #ubuntu-desktop you asked a mtab question, which I replied to saying that pitti might know, but now you changed to ask about gvfs fuse handling, which is a different topic (pitti might still know but I'm less sure for that one)
<dgadomski> seb128: alright, the reason for those question is to determine if it is possible to enable ACL on samba shares mounted via nautilus (i.e. gvfs)
<LocutusOfBorg1> hi, can somebody from MIR team enlight me about bug 1461517 and bug 1464853?
<ubottu> bug 1461517 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Incomplete] https://launchpad.net/bugs/1461517
<ubottu> bug 1464853 in libjsoncpp (Ubuntu) "Sync libjsoncpp 0.10.2-3 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1464853
<dgadomski> seb128: for "normal" shares (e.g. mount.cifs) this could be done by passing the cifsacl option to mount
<seb128> dgadomski, is your issue with real gvfs access through gio, or with the compat fuse mounnts?
<dgadomski> seb128: that's what I'm trying to understand :) I don't entirely get how this works, but the scenario looks like this: 1. user opens a samba share with nautilus, 2. Opens a file there with e.g. gedit, which mechanism is used in that case? gio or the compat fuse mounts?
<seb128> dgadomski, gedit = gio
<seb128> but it you use e.g libreoffice it might be the fuse mount
<dgadomski> seb128: so the actual problem is that the samba share the user want's to use has some ACL rules applied and I would like those acl rules to be respected when the share is mounted via nautlius just like it is if the user mounts it via mount.cifs -o cifsacl
<seb128> dgadomski, is that bug impacting both gio and compat mounts?
<dgadomski> seb128: yes, both mechanims seem to be acl-unaware
<seb128> dgadomski, https://bugzilla.gnome.org/show_bug.cgi?id=623161 ?
<ubottu> Gnome bug 623161 in gio "file ACL are not preserved when saving file in gedit" [Normal,New]
<seb128> hum, that bug is about windows though
<seb128> dgadomski, is that specific to smb or with any protocole? like ssh
 * smb is innocent
<dgadomski> seb128: I did not try anything else beside smb, give me a sec
<pitti> dgadomski: that's right; that's mostly a legacy program interface, i. e. CLI tools etc. which don't use GIO themselves
<pitti> dgadomski: so you can e. g. attach an MTP mobile phone or a PtP camera and have a real fs for cp/mv/exiftran, you name it
<slangasek> wgrant: "once we have a working ovmf" - ok, where are we at with /that/? :)  I saw a build failure of edk2 over the weekend, so somebody gave it back...
<pitti> dgadomski: I don't know how well fuse works with ACLs
<pitti> dgadomski: gedit, like all GNOME apps, uses GIO, not the fuse file system
<dgadomski> thanks pitti, and is gio capable of working with ACLs?
<pitti> dgadomski: I don't know
<pitti> dgadomski: server-side ACLs should be totally transparent to the client
<pitti> dgadomski: and client-side ACLs should not matter, as this is all per-user, not system-wide
<pitti> dgadomski: so I don't quite understand what ACLs have to do with this
<dgadomski> pitti: what if a user want's to modify ACLs on the server smb share?
<pitti> dgadomski: that's the thing I'm not sure about -- i. e. if that's mapped through GIO
<pitti> or if you need smbclient or a similarly specialized tool for that
<dgadomski> pitti: one way to do it is to mount the share with mount.cifs -o cifsacl and use getfacl/setfacl or a GUI tool (like eiciel)
<dgadomski> pitti: but those tools are unusable with GIO / gvfs fuse, so the question is: is there a possibility to enable it?
<pitti> dgadomski: anything is possible, it's free software :) so it mostly depends on finding someone who is interested in adding this support
<dgadomski> pitti: can you give me a hint which layer would be appropriate to implement such thing?
<pitti> dgadomski: I support GIO for adding the general set/get ACL API, and gvfs' smb-browse module for implementing it for samba/CIFS
<dgadomski> pitti: sounds like quite amount of work, thanks for the info
<LocutusOfBorg1> mterry, are you sure about fix-double-parsing.patch?
<mterry> LocutusOfBorg1, not 100% but the code that it changes is still there in debian
<mterry> LocutusOfBorg1, and that patch is relatively recent -- it wasn't in our packaging back when Debian grabbed all our changes
<LocutusOfBorg1> oh I see
<LocutusOfBorg1> yes, right
<LocutusOfBorg1> I checked, but I made a mistake
<LocutusOfBorg1> so mterry while you are merging it, do you think for a MIR having the symbols file is a must=
<LocutusOfBorg1> ?
<LocutusOfBorg1> I need that package into main, because cmake 3.2.2 is waiting for it
<mterry> LocutusOfBorg1, not a must, just a strong preference.  But I see the comments about upstream checking ABI
<mterry> LocutusOfBorg1, that's what brought me to your sync bug
<mterry> LocutusOfBorg1, I'll try to sort this today
<LocutusOfBorg1> ok, so if we can forward the patch to Debian we can just sync on the next run
<LocutusOfBorg1> (I would like to avoid maintaining a delta there)
<LocutusOfBorg1> specially because symbols have been dropped here http://anonscm.debian.org/cgit/collab-maint/libjsoncpp.git/commit/?id=21f33b218735398db17c50e09b46d7fefa39bec8
<mterry> LocutusOfBorg1, agreed, deltas suck
<LocutusOfBorg1> I sent a mail with the patch to Peter
<mterry> LocutusOfBorg1, oh, OK.  I would have used submittodebian when I'm done merging, but that works too.  Was it a debian bug or just an email to him directly?
<LocutusOfBorg1> direct mail, but feel free to open a bug
<dobey> LocutusOfBorg1: is that my patch?
<LocutusOfBorg1> I wasn't aware of the submittodebian tool, how does it work=
<LocutusOfBorg1> yes dobey
<Mirv> Qt 5.4.2 is now in wily, but will be blocked from migration due to existing KF5 autopkgtests failures
<dobey> LocutusOfBorg1: if it still applies it is still relevant, yes. i intended to push it upstream, but i my have been really busy, had difficulty finding where exactly to submit it upstream, and totally forgotten about it
<LocutusOfBorg1> dobey, https://github.com/open-source-parsers/jsoncpp
<LocutusOfBorg1> they moved to github :)
<dobey> LocutusOfBorg1: ah ok, thanks
<mterry> LocutusOfBorg1, oh submittodebian is just a little helper for when you're patching ubuntu (or doing a merge with patches) and will automatically open a bug and submit a patch for you (with chances to explain/edit the patch)
<dobey> LocutusOfBorg1: i'll see about getting that upstream then, but we do need to keep that patch around
<LocutusOfBorg1> so I can't use it :(
<LocutusOfBorg1> yes dobey, I hope Peter will merge it in Debian, and then we can sync it (and forget)
<dobey> ok
<dobey> well, now i need to get lunch. :)
<LocutusOfBorg1> have fun!
<LocutusOfBorg1> so mterry please use the submittodebian tool then, I would prefer a bug instead :)
<LocutusOfBorg1> and thanks for the hard work
<mterry> LocutusOfBorg1, my pleasure.  I like converging on no deltas  :)
<mterry> LocutusOfBorg1, I've got other work I'm in the middle of, but will try to finish this stuff out / review the MIR today
<LocutusOfBorg1> thanks! I started working in Debian to avoid deltas, and now I'm mostly a DD
<LocutusOfBorg1> I hope to become an ubuntu developer soonafter DAM processes my nm application
<mterry> LocutusOfBorg1, oh nice  :)
<arges> hallyn: was trying to verify bug 1425619, but looks like the patch to qemu/trusty got dropped.
<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: so we'll need to re-apply the patches for qemu before verifying that one before verifying libvirt etc...
<arges> hallyn: i can re-apply that patch and push an update
<hallyn> arges: great, thanks
<hallyn> wonder how i dropped that
<arges> hallyn: i think the security update overrode it
<arges> anyway test building
<hallyn> ah, ok
<Mirv> FYI I'm running Plasma 5 just as good after the Qt 5.4.2 update as before. it seems the same KF5 5.10.0 autopkgtests fail as have failed since the 5.10.0 was uploaded, but now the transition is starting to block non-Kubuntu packages too. if there's someone available from Kubuntu during my sleep hours please discuss how to migrate to release pocket.
<Mirv> the list of autopkgtests is at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src - maybe the failing kf5 5.10.0 packages could be overridden
<Mirv> (running Plasma 5 == running wily-proposed versions of Qt 5, KF5 etc)
<arges> hallyn: /quit
<arges> whoops
<ScottK> Any idea why http://www.ubuntu.com/legal claims the Canonical contributor agreement is needed " before you begin contributing to Ubuntu"?
<ScottK> Seems wrong.
<lifeless> define contribution I guess?
<lifeless> submitting code to Canonical repositories vs running an ubuntu user group vs patching debian packages to work better on ubuntu...
<ScottK> For anything that's Ubuntu (the Linux distribution) such a thing isn't needed.
<ScottK> I'd buy if it said something like ... some aspects of ...
<lifeless> sure
<ScottK> As it is, it's plain wrong.
<lifeless> just like some packages require CLAs and patches to them ned to be done directly upstream (or be debt forever)
<ScottK> Some upstreams require CLAs.
<ScottK> Ubuntu the distro doesn't.
<ScottK> Unfortunately, the term Ubuntu is so overloaded it's almost meaningless.
<infinity> ScottK: Yeah, the wording there is clearly too broad.  Needs to be vague with something like "before contributing to certain Canonical projects" and a link to the list.
<infinity> slangasek: ^-- Can you sort out who to escalate that to?
<slangasek> infinity: can you file a bug against https://bugs.launchpad.net/ubuntu-website-content ?
<infinity> slangasek: Sure.
<infinity> https://bugs.launchpad.net/ubuntu-website-content/+bug/1465430
<ubottu> Error: ubuntu bug 1465430 not found
<infinity> slangasek: ^
<infinity> Err, really, why is that private by default?
<infinity> There.
<infinity> ScottK: ^ does that look like an appropriate appraisal of the situation to you?
<ScottK> Thanks.
 * ScottK looks
<sarnold> everything on the website is private by default :/ it's annoying to try to file bugs on behalf of others that way :(
<ScottK> infinity: Perfect.
<wgrant> slangasek: RT is still a total mess due to the PS4 debacle, so I'm reluctant to throw a bare metal sbuild upgrade ticket at it. If it becomes a blocker, we can build it in a PPA and copy it in.
<sladen> sarnold: +1
<infinity> wgrant: It's a 1-line hack to make the old sbuild build edk2, we could just get someone to cowboy one of the nonvirts. :P
<infinity> wgrant: But I also assume we'll want it backported to the cloud archive.
<slangasek> wgrant: ok
<infinity> slangasek: Hrm, I see pesign in the queue synced from Debian.  Should we be looking to replace sbsigntool?
<slangasek> infinity: AFAIK the only benefit of pesign over sbsigntool is nss, which is a questionable benefit
<infinity> slangasek: I would assume the other benefit is active maintenance.
<slangasek> infinity: I'm happy to revisit that question when someone points to an actual feature we're missing out on :)
<infinity> slangasek: Oh, and no dep on gnu-efi, which means it builds on more arches.  Like ARM/ARM64.
<infinity> slangasek: arm64 support might be the killer feature.
#ubuntu-devel 2015-06-16
<slangasek> infinity: shim itself build-depends on gnu-efi, so if gnu-efi is missing on arm64, pesign isn't terribly relevant
<infinity> slangasek: Well, unless you want to sign grub yourself.  But yes, that does put a kink in the shim->grub->kernel way we do things.
<slangasek> oh right, we don't actually need shim on arm64 because no signing regime
<psusi> eh?  I thought that "windows certified" arm hardware *required* signing
<slangasek> sure it does
<slangasek> with a key that Microsoft will not use to sign anything from third parties
<infinity> psusi: None of which is a target for us currently.
<pitti> Good morning
<robert_ancell> RAOF, have you ever removed a package from the archive? I want to clean out all the old vala packages. Wondering if there's anyone I should check with first
<RAOF> robert_ancell: You're not an archive admin, right? You *can't* remove a package from the archive :).
<pitti> robert_ancell: there's two things to check: (1) all reverse dependencies must be gone, and (2) the package should also be removed in Debian, or we should blacklist it
<StevenK> Removing packages from the archive was one of my favourite things.
<pitti> these checks can be done by anyone
<RAOF> But the way to do so is to file a bug against all the various packages and subscribe ubuntu-archive.
<pitti> StevenK: ~ubuntu-cruft-busters! \o/
<RAOF> Also that.
<robert_ancell> RAOF, ah, I was reading https://wiki.ubuntu.com/ArchiveAdministration and thinking I just needed core perms
<robert_ancell> RAOF, pitti, OK I have the bugs and I've chased down the reverse-deps so I'll sub ~ubuntu-archive
<RAOF> robert_ancell: I'm pretty sure that needs LP privs. (Same as you can't accept things into foo-proposed).
<StevenK> pitti: Represent!
<Unit193> pitti: Upgraded to vivid just so I could get systemd user units (yes I'm aware upstart had them.) :P
<infinity> pitti: Didn't that all start from the two of us sitting at a table in Montreal, whining about duplication in the archive?
<infinity> Although, the cruft-busters team is much newer than our spec. :P
<pitti> infinity: I can easily whine about it on any table in the world
<infinity> pitti: You're so versatile.
<infinity> pitti: This must be why you have a fan club.
<robert_ancell> mterry is the last thing blocking Vala 0.16 (via vala-dep-scanner which looks like it too should be removed from the archive)
<pitti> robert_ancell: sorry, we can't possibly remove mterry from wily
<infinity> Wait, vala-0.16 is still in the archive?
<infinity> It's been removed from Debian since last year.
<robert_ancell> infinity, yes, I was surprised too
<pitti> $ reverse-depends -b src:vala-0.16
<infinity> pitti: If we remove him, he'll just MIR himself back in.
<robert_ancell> Bug 1465486, bug 1465487 and bug 1465488 for Vala 0.18, 0.20, 0.24
<ubottu> bug 1465486 in vala-0.18 (Ubuntu) "Remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1465486
<ubottu> bug 1465487 in vala-0.20 (Ubuntu) "Remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1465487
<ubottu> bug 1465488 in vala-0.24 (Ubuntu) "Remove from archive " [Medium,Triaged] https://launchpad.net/bugs/1465488
<robert_ancell> I figure we don't need six versions of Vala...
<infinity> I suspect you're right.
<StevenK> Maybe it's trying to make Python jealous
<infinity> Does vala-dep-scanner have any rdeps?
<pitti> vala-dep-scanner has zero reverse deps
<infinity> Jinx.
<pitti> so maybe we shuld just drop that along?
<pitti> it's never been in Debian either
<robert_ancell> v-d-s looks like an experiment that went nowhere
<infinity> Yep, agreed.  Punt it, if someone likes it, they can resurrect it with a newer vala.
 * pitti sharpens the knife
<robert_ancell> See bug 1465484 and bug 1189642
<ubottu> bug 1465484 in vala-0.16 (Ubuntu) "Remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1465484
<ubottu> bug 1189642 in vala-dep-scanner (Ubuntu) "Update vala-dep-scanner for vala-0.28 or remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1189642
<infinity> pitti: Are you all over this?  I was just about to start the abuse, but you're welcome to have the honours.  I know how much you love deleting things. :P
<pitti> infinity: we can share the love -- we have four bugs, nicely splits in half :)
 * pitti is on 0.16 ATM
<infinity> pitti: No, no.  Go ahead.  I'm trying to make Mirv happy.
<infinity> Which is, apparently, really difficult.
<pitti> -16: history
 * robert_ancell gets the marshmallows
<pitti> -18 is gone as well
<pitti> robert_ancell: -20 has rdeps, I followed up to bug 1465487
<ubottu> bug 1465487 in vala-0.20 (Ubuntu) "Remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1465487
<pitti> err
<pitti> sorry, it seems UDD or so is out of date
<robert_ancell> pitti, I've updated all those, not sure if they've flowed through yet
<pitti> all gone
<pitti> removing 4 compilers on one day? it's too good!
<StevenK> pitti: Up next, gcc?
<pitti> and python 2
<sarnold> and how many awks do we really need?
<robert_ancell> Thanks pitti!
<StevenK> pitti: Python 2 isn't a compiler, why is it on that list? :-P
<StevenK> pypy on the other hand ...
<robert_ancell> I did a few packages to help move python2 off the image...
<robert_ancell> bye all
<LocutusOfBorg1> good morning
<LocutusOfBorg1> does anybody know why gdb-arm-none-eabi is built for debian but not for ubuntu?
<LocutusOfBorg1> I mean, where the hell does the gdb source come from in debian buildds?
<cjwatson> gdb-arm-none-eabi build-depends on gdb-source, which is a binary package built by the gdb source package.
<cjwatson> The gdb-arm-none-eabi build failure in Ubuntu just looks like it's because the patches it carries are out of sync with Ubuntu's gdb.
<dholbach> good morning
<LocutusOfBorg1> thanks cjwatson :)
<LocutusOfBorg1> hi dholbach 1
<dholbach> hey LocutusOfBorg1
<tjaalton> is wily "safe" to use yet? :)
<seb128> tjaalton, no issue here or that I saw others report
<seb128> so I would say "yes"
<tjaalton> cool
<tjaalton> will switch my laptop to it then
<seb128> :-)
<tjaalton> @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: tjaalton
<tjaalton> ugh
<seb128> bdmurray, hey, is that a known issue that e.u.c "channels" category stopped listing channels?
<seb128> it only has "all channels" option
<seb128> same for "rootfs" or "device image"
<zyga> hey
 * zyga filed a bug about those python packages that use PEP440 incompatible versions
<zyga> https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1465549
<ubottu> Ubuntu bug 1465549 in PlainBox (Toolkit) "Plainbox tests are broken by PEP 440 incompatible Debian/Ubuntu packages" [Undecided,Confirmed]
<zyga> I can fix all three easily but I don't have any rights to upload them
<zyga> what should I do? attach debdiffs to the bug?
<zyga> juliank: can the fixed package be uploaded to vivid-updates?
<juliank> Oh, I'm online.
<davmor2> juliank: or are you?
<juliank> zyga: Well, vivid needs the commit cherry-picked, that'd solve the issue. There are some other commits that should be cherry picked as well, though.
<juliank> The others are the same I'll propose for a stable update in Debian. They fix crashes on LFS .deb files, and a memory leak.
<zyga> juliank: can you do that? I can only prepare debdiffs / patches but I have no upload rights
<juliank> I have no upload rights either, but mvo has.
 * juliank should work on getting upload rights
 * zyga feels the same
<zyga> mvo: how can I get upload rigths for command-not-found?
<juliank> Apply for PPU
<mvo> juliank, zyga: what needs sponsoring?
<mvo> zyga: yeah, what juliank said
<zyga> juliank: thanks, I'll check what that is (personal package uploads?)
<juliank> mvo: We'll need to cherry-pick some patches from python-apt 1.0 beta to the vivid version (and the one in wily, or just push the 1.0 beta there)
<zyga> mvo: I'd like to see a few PEP440 violations fixed, juliank was thinking about python-apt
<cjwatson> per-package upload permissions.  Ubuntu has a bad acronym habit.
<zyga> is there a spec for PPU, I see lots of wikis for people (that I know) that have applied
<juliank> Not sure how urgent this is, we could try to get a python-apt 0.9.3.12 uploaded to Debian stable and then merge that release + the versioning fix into vivid-updates
<zyga> juliank: one by istself is not urgent but those versions do break tests in our team so we'd like to fix that over time
<juliank> Let me prepare the list of other patches for python-apt (aka create a branch), so we now what we're dealing with. (It'd be useless to do two uploads)
<zyga> juliank: thanks
<juliank> mvo: I pushed three branches into the python-apt repository (they might still need some rebasing though). debian/jessie contains fixes for crashes and the memory leak, debian/jessie-pu fixes 2 multi-arch and 1 .dsc parsing issue (all small, but not sure whether we'll get that into Debian jessie). And finally, ubuntu/vivid, based on debian/jessie-pu, that also contains the setup.py versioning fix.
<juliank> If 0.9.3.12 would get all fixes from debian/jessie-pu, then the diff for vivid-updates would be http://paste.debian.net/231237/
 * juliank probably should also strip ~ubuntu... in setup.py, but that's not needed for stable updates anyway
<mvo> juliank: neat!
<juliank> The LFS patches for tarfile do not work entirely correctly, because the size members are not actually long long yet, but they still catch too large allocations instead of crashing
<juliank> OK, the version number should probably be different, not sure about Ubuntu stable release update versioning
<juliank> (in the paste)
<infinity> 0.9.3.12ubuntu1 is sane versioning for an ubuntu update to a native package.
<juliank> OK, great
<infinity> Should be vivid instead of vivid-updates, but that's easy enough to fix.
<juliank> OK
<juliank> it was just to give an overview anyway, not final yet.
<juliank> I'd use my email address for an Ubuntu update, anyway.
<juliank> s/email/Ubuntu email/
<rbasak> Is there any easy way for me to detect in a maintainer script whether dpkg considers certain conffiles to have been modified?
<rbasak> I know I could just scan for known md5s or something. Is there an easier way?
<juliank> Back soon
<rbasak> pitti: can you tell me how systemd integrates with dh_installinit please? If I use dh_installinit with --error-handler, will the error handler get called if it's actually a systemd unit that fails to start? I can't see how that would happen, nor where else I could put --error-handler.
<pitti> rbasak: AFAIK there is no special integration -- this is simply expanded to invoke-rc.d .. || error_handler
<pitti> rbasak: I have never used it myself, but according to the manpage and the template you just define a myerror() { ... } in your postinst and then dh_installinit --error-handler=myerror; this will then generate invoke-rc.d myservice start || myerror
<rbasak> pitti: I'm confused because the invoke-rc.d ... start call is wrapped in if [ -x "/etc/init.d/#SCRIPT#" ] || [ -e "/etc/init/#SCRIPT#.conf" ]
<rbasak> pitti: so if there weren't init.d or upstart scripts, then it wouldn't get called? So I wondered if systemd services are started from elsewhere, but I couldn't see where.
<pitti> rbasak: ah, so you have a package which only ships a systemd unit, but no corresponding init script?
<rbasak> pitti: in this case I think there is an init script. I was wondering about the safe thing to do in the general case.
<infinity> rbasak: Given that Debian policy requires an init script, that shouldn't matter.
<rbasak> Or if that meant I was missing something.
<rbasak> Ah, OK. Thanks.
<infinity> rbasak: Though, that may not always be true.
<pitti> rbasak: the "main" service from a package should always be accompanied by an init script, by Debian policy
<pitti> rbasak: for some "auxilliary" units, that's why dh_systemd_start exists
<rbasak> I will write an error handler then. Thank you!
<pitti> rbasak: e. g. for timers, sockets, or if the units are more fine-grained than the init script
<juliank> mvo_: I asked for permission to update jessie's python-apt in https://bugs.debian.org/788928. After 0.9.3.12 gets accepted, we can merge it into vivid.
<ubottu> Debian bug 788928 in release.debian.org "jessie-pu: package python-apt/0.9.3.12" [Normal,Open]
<juliank> (I'll rebase the vivid branch in that case, and prepare the upload, you just need to sponsor it)
<juliank> This way, everyone should be happy :)
 * juliank really needs to work on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU2 so he can upload himself
<juliank> BTW, IIRC, It's called DeveloperApplication-PPU2 instead of DeveloperApplication-PPU due to a wiki issue (I think I could not rename it)
<mvo_> juliank: awesome, thanks a bunch
<juliank> zyga: mvo_: I'd like to talk about command-not-found. Debian's still at 0.2.38, and Ubuntu has seen tons of ubuntu... releases on top of 0.3. A sane new upstream release would be appreciated, in case I need to update it. (I also have or had a much faster (but slightly limited) version in C somewhere I might push instead, and PackageKit has its own handler, although it's not installed yet)
<juliank> I uploaded that thing 5 years ago, so it will probably be hard for me to merge the new release, as I have a bunch of changes in there.
 * juliank needs to find his bzr branch from 2009
<zyga> juliank: so there are a few options that we can explore
<zyga> juliank: first of all, a reboot of the current ubuntu package, it has lots of issues and I wasn't a very effective upstream
<zyga> juliank: but that was largely caused by my lack of effective way to release it to ubuntu
<zyga> juliank: a C version would be appreciated (speed and ctrl+c support)
<juliank> I need to see if I can find it and bring it up to the current standards.
<juliank> Or just restart, it's not going to take longer than a week.
<tjaalton> @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:
<zyga> juliank: I'm breaking for lunch, let's talk about this later
<juliank> OK, I also need to do university work
<caribou> Does someone have a minute to help out with a merge (rsyslog) ?
<caribou> I need to remove a dependency to liblogging-stdlog since it is a Universe package
<caribou> but the new version introduce a slew of unit tests where some of those tests rely on that package
<caribou> our previous version did not implement unit tests at all
<caribou> should I just strip out each test that rely on this dependancy ?
<caribou> I also have other FTBS caused by some of the tests race conditions (according to upstream's statements)
<rbasak> I don't see liblogging-stdlog
<rbasak> Is it new? Should it stay in universe or should it be pulled into main?
<caribou> rbasak: yes, it's new in the 8.0 stream
<rbasak> Ah it's liblogging-stdlog0
<caribou> rbasak: sorry, I cnp the --enable statement
<caribou> rbasak: maybe, I just sorta followed what had been done before for other dependancies not into main
<rbasak> I've read up on what liblogging is. Sounds like it's very much a client thing, so presumably rsyslog is using it to run tests only, and it doesn't form any part of the function of rsyslog itself.
<rbasak> So I guess it doesn't make sense to pull it into main unless it's necessary.
<juliank> mvo_: Can you sponsor a python-apt sync for me (syncpackage -s juliank python-apt)? I'd like to see python-apt 1.0.0~beta2 in wily now, the fix from 0.9.4ubuntu1 is contained in it as well (well, I rewrote it, but achieved the same in the end). The earlier we sync, the better.
<caribou> rbasak: mmnormalize, kafka, rsyslog-mongodb are also dropped because of Universe dependancies
<mvo_> sure
<rbasak> caribou: I'd say drop the tests from build time. If possible, you can add dep8 tests since those can depend on stuff in universe.
<caribou> rbasak: well, it is now enabled by default so I suppose it does use it somehow
<caribou> rbasak: all tests or only those specific to that lib ?
<rbasak> caribou: in that case I'd like to understand the consequences of not building with it, since that might have a bearing on whether we want it in main.
<caribou> rbasak: ok, I'll dig a bit deeper into this
<rbasak> caribou: preferably specific to that lib. If that's really awkward then maybe better to remove all and have dep8 do the full test instead? I'm not really sure about this though, would prefer a +1 from someone else.
<mvo_> juliank: done
<mvo_> juliank: lots of great fixes/features!
<juliank> mvo_: Yeah, thanks. I still need to work out the new Files API for ~beta3 (or ~rc1, depending on how I feel)
<caribou> rbasak: here is a short discussion b/w the debian maintainer & upstream about what that library is meant to be : http://lists.adiscon.net/pipermail/rsyslog/2014-February/036448.html
<mvo_> juliank: :)
<zyga> re
 * zyga added another patch to https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1465549
<ubottu> Ubuntu bug 1465549 in PlainBox (Toolkit) "Plainbox tests are broken by PEP 440 incompatible Debian/Ubuntu packages" [Undecided,Confirmed]
<zyga> juliank: about command-not-found, I'd like to iterate on the python version
<zyga> juliank: to fix some annoyances
<zyga> juliank: and get the UI better
<zyga> juliank: and then work on the C rewrite
<zyga> juliank: (c/rust/go/$shiny)
<zyga> juliank: to improve performance
<zyga> juliank: but I'd like to keep the python API as strangely enough, some things call it
<juliank> zyga: The patch looks wrong, is c a valid Python alternative to ~rc?
<zyga> yes
<zyga> juliank: it's part of PEP486
<zyga> juliank: no, wait, wrong pep :)
<juliank> 440
<zyga> juliank: a - alpha, b - beta, c - candidate (rc only for python itself)
<zyga> juliank: (there's another pep, I think, that defines this, apart from 440)
<zyga> one sec
<zyga> 386
<juliank> PEP440 only defines a b and rc
<zyga> those x86 names :P
<juliank> Oh no, it says Installation tools SHOULD interpret c versions as being equivalent to rc versions (that is, c1 indicates the same version as rc1 ).
<zyga> that's more what I remember
<zyga> https://www.python.org/dev/peps/pep-0386/#id18
<zyga> rc and c are equivalent
<zyga> and c is more recommended
<zyga> AFAIR
<juliank> 386 is superseded, I would not refer to it.
<zyga> thanks, I need to read 440 then
<zyga> I should patch python-versiontools to support this
<zyga> oh, and I'm always happy to see packages accepted in debian :-) woot
<zyga> juliank: do you think I should keep 'rc' as rc?
<zyga> juliank: I can regenerate the pathc
<caribou> rbasak: reading more about it, looks like liblogging-stdlog will be more and more in use with rsyslog; might be a better choice to MIR the lib
<zyga> patch
<juliank> zyga: I (would) do that. The function I use for python-apt does it. It even maps ubuntu to +ubuntu, so that information is not lost either
<zyga> juliank: perhaps I should move your function to python-versiontools and start patching all of those to just import it, right now that's just three packages (that I see) but if the same code needs to be copy-pasted around it doesn't look too good
<rbasak> caribou: sure, if you think that's appropriate. I can't find much in rsyslog 8.9.0-3 that would be lost if built without liblogging, but maybe in the future.
<caribou> rbasak: looks to me like rsyslog upstream is also the author of that library so I wouldn't be surprised if he was to make more usage of it. I'll ping him
<juliank> zyga: Something like that might be a good idea (I suggested to move it to dh-python, but its maintainer was not that happy about the idea). The ~exp thing is a bit python-apt specific, though, but the rest is generic.
<juliank> zyga: Also, normalized versioning now uses 1.0.alpha1 instead of 1.0a1 (with an added dot before the a), AFAICT
<juliank> Not sure if a or alpha is standard
<juliank> probably a
<zyga> juliank: .alpha1?
<juliank> so 1.0.a1
<zyga> I think a
<zyga> yes, that's more like it
<juliank> Oops, I might be wrong
<zyga> 1.0a1
<juliank> It's far too complicated
<zyga> it's not much different from pep386 -- I'm still reading 440
<zyga> it's more liberal from what I remember
<zyga> but not incompatible with 386
<juliank> The dev releases have ".dev", but alpha and beta have "a" and "b" without a dot
<zyga> 440 adds different version types
<juliank> in the normalized version
<juliank> but 1.0.a1 is accepted to
<juliank> too
<zyga> yes, .devN and .postN are different
<juliank> just like 1.1-a1
<juliank> It's crazy
<zyga> well, I think that -a1 should be different
<zyga> at least if it's debian's -a1
<zyga> I would strip those out enitrely
<zyga> as this fact (debian version) is almost never relevant
<zyga> in fact, in all the patches that was my intent
<zyga> though those are debian native packages with weird non-pythonic conventions
<zyga> (e.g broken setup.py that only works via debian/rules)
<juliank> Well, in native packages we don't really have the issue with -. But I prefer keeping, for example, the Ubuntu part, and map it to a local label, by prepending a + to it
<zyga> yeah, it seems that local version is "debian version" in generic temrs
<zyga> terms
<zyga> Source distributions using a local version identifier SHOULD provide the python.integrator extension metadata (as defined in PEP 459 ).
<zyga> I need to catch up on PEPs
<juliank> Summary is good https://www.python.org/dev/peps/pep-0440/#summary-of-permitted-suffixes-and-relative-ordering
<zyga> juliank: I agree it's complicated but it seems that the goal was to capture everything sensible that is done in reality and just standardize that
<juliank> Debian version numbers are much more simple and capture more of the domain
<zyga> juliank: I don't know, I'm too corrputed by exposure to both over years :-)
<zyga> juliank: go ahead explain ~ : + and - vs _ to a novice ;)
<juliank> I really need to work on university stuff now, I have to hand in things tomorrow.
<zyga> juliank: good luck, thanks for the help!
<juliank> No problem. I'll now hangout with python-ldap and see how that works....
<zyga> juliank: is that your university stuff?
<juliank> Part of it
<juliank> Learning ldap
<juliank> zyga: One thing I do today is for a lecture about distributed systems. Part of it this week is LDAP.
<zyga> juliank: when does it start? ;-)
<juliank> distributed systems is a fun lecture, much like networks I had last year.
 * zyga makes silly distributed systems what-time-is-it jokes
<juliank> zyga: Well, that's just the homework.
<juliank> I also need to do university work work stuff sometime, though
 * juliank works 10 hours / week at university. Could use something else 10 hours a week instead ...
<zyga> juliank: working at the university or remotely?
 * zyga likes his university days
<juliank> zyga: I'm helping students with programming an Android app 4 hours a week at the university (aka sit around and wait for a question, last week I worked on python-apt during work time), and the rest I'm at home and don't have much work to do.
<juliank> It's a boring job :)
<juliank> Gives me some time to work on open source
<zyga> juliank: perhaps, I cannot relate to that -- though I think some questions may be eye-opening :)
<juliank> s/open source/free software/
<juliank> I'm happy that I can solve the LDAP exercise in Python (although only Python 2, unfortunately) and don't have to use Java.
<juliank> Oh, there's a python3-ldap3 package.
<juliank> Because two threes are better than one?
<zyga> juliank: because apis and packages perhaps
<juliank> Ah entirely different software.
 * zyga updates his RTM phone to vivid, \o/
<bdmurray> seb128: The channels don't display if you are not logged in.
<kamal> @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: kamal
<LocutusOfBorg1> mterry, seems that unity-scope-click is blocking libjsoncpp migration
<mterry> LocutusOfBorg1, https://code.launchpad.net/~mterry/unity-scope-click/missing-iostream/+merge/262035
<LocutusOfBorg1> holy sh*t you rock man
<LocutusOfBorg1> I was downloading the source
<LocutusOfBorg1> thanks!
<LocutusOfBorg1> dholbach, do you mind syncing libserial from debian? :)
<mterry> LocutusOfBorg1, :)
<LocutusOfBorg1> or kamal if you are patch piloting ;)
<kamal> LocutusOfBorg1, I'm on patch pilot duty, but I don't have upload rights (afaik!), so afraid I can't actually do so
<dholbach> kamal, just for the kernel packages, right?
<kamal> dholbach, correct (I only have upload rights for kernel)
<dholbach> ok... the review/pilot duties are then a special case as discussed with the kernel team ages ago :)
<kamal> dholbach, yup, I'm just here because my calendar says I'm supposed to be here :-)
<dholbach> LocutusOfBorg1, looking at it now
<caribou> rbasak: turns out that the one test is easily fixed with conditionals so I can still use it.
<caribou> rbasak: I sent an email upstream to know is future plans
<dholbach> LocutusOfBorg1, done
<dholbach> LocutusOfBorg1, I won't have time to look into other sponsoring items today though
<LocutusOfBorg1> no problem dholbach, thanks!
<dholbach> anytime
<rbasak> caribou: great. Thanks!
<caribou> rbasak: wow, Rainer has already replied
<juliank> mvo__: Oh I see, python-apt failed the autopkgtest because of deprecation warnings in the test you added for checking that the deprecated argument works :( - They're somehow shown by default during autopkgtest
<juliank> Python3 has assertWarns, but Python2 does not
<juliank> I'm fixing it
<juliank> mvo_: Fixed in debian/sid
<juliank> It now uses catch_warnings to catch the warning and record it, and then asserts that the use of the md5 parameter caused a DeprecationWarning
<juliank> :)
<juliank> My editor misdetected the indentation , I'll fix that too
<juliank> I can either push a ~beta3 to unstable and we resync, or we just push out an ~beta2ubuntu1 release for now
<juliank> We should make our testing more strict to also fail on stderr during package build, I believe the buildds showed the warning too
<juliank> No they did not. Strange.
<juliank> That is, we could use warnings.simplefilter('error') or something in test_all
<juliank> Oh well, an error filter does not allow me to use catch_warnings.
<juliank> and it does not raise any exception if used in a catch_warnings block
<juliank> ...
<zyga> juliank: for python2 you can use unittest2
<zyga> juliank: it has assertWarns and the zoo of new features
<juliank> Well, I used catch_warnings manually. Better than adding a build-time dependency.
<zyga> juliank: yep, it's typically something upstreams should adopt
<zyga> juliank: for command not found in debian, I'm scared of building the hints database
<zyga> juliank: for ubuntu I did it manually on my machine after downloading 50GBs of the archive
<juliank> zyga: Well in Debian, we download Contents files and build from that with a command in the package.
<zyga> juliank: and I'd like that process to be separate from the upstream hacking on the tool itself
<zyga> kgunn: oh
<zyga> juliank: oh
<zyga> juliank: contents is insufficient
<juliank> zyga: That's true, but it's all we get for now.
<zyga> juliank: you need postinst scripts and metadata (symlink, mode) that is AFAIR not there
<juliank> zyga: ftpmaster did not want the hints thing packaged
<zyga> juliank: ah, ok
<zyga> juliank: what?
<zyga> juliank: why not
<juliank> Well, I split it into its own package, which probably was the main factor (so we could have shared the main c-n-f package), but even in the same package, I'm not sure they would have liked it, because it gets outdated to quickly.
<zyga> juliank: I somewhat agree with them
<zyga> juliank: ideally, it would be a bit of meta-data that one can harvest easily
<juliank> So, only contents files for now, until we have the proper metadata in the archive.
<zyga> juliank: and declarative
<juliank> That's WiP
<zyga> juliank: not just random insanity like guessing from postinst scripts
<juliank> zyga: Adding metadata is ximion's show
<zyga> ximion: tell me about it, I'm very interested in this
<ximion> metadata what? metadata where? ;-)
 * ximion reads backlog
<zyga> ximion: declarative list of executables per package
<Laney> X-Metadata-Lover: ximion
<zyga> ximion: and handling stuff like vim using alternatives
<zyga> ximion: and divertions
<zyga> ximion: so that common (but hard) cases are supported
<zyga> juliank: one other thing that is problematic is knowing the right package to install
<zyga> juliank: often a -bin or -common package is the one that has the executable
<zyga> juliank: but the foo (not foo-bin) should be installed for good upgrades
<zyga> juliank: I'd love to have this at the meta-data layer as well
<zyga> juliank: and lastly, I want "gcc", there are 1234 versions of gcc avaialble and the hint should be smart there, the "smarts" should be declarative
<zyga> (coffee)
<juliank> Well, it should simply install the default gcc, obviously. Which is in the gcc package
<zyga> juliank: or mabe pentium-builder
<zyga> juliank: or maybe the package names are not a hint at all (gcc is a symlink or something like alternative)
<zyga> juliank: obviously is not good, it has to be an algorithm :)
<zyga> juliank: or if it's manual, it has to be a packaging-level declarative hint
<ximion> zyga: about gcc I agree with juliank. About binary-fetching, that is in-scope for DEP-11/AppStream, and could be added to it at a later stage (we need to see how much overhead it would be to add this information to every metadata)
<zyga> ximion: I read dep 11 a while ago, how close is that to reality?
<juliank> I do *not* want pentium-builder if I ask for gcc. The algorithm should take the command - package name distance into account when finding a package
<zyga> ximion: (I actually had some of that in one of my first packages but my sponsor asked to remove the meta-data)
<juliank> distance to package names is always a good idea.
<zyga> juliank: that's google's business
<zyga> juliank: it's hard problem
<zyga> juliank: and gcc is the bad example as some packages are widely different
<ximion> zyga: at Debian: very close, I am running the data generator there, and I hope I can soon switch it to automatic mode. The remaining bits are archive integration then (pull the data into the apt repo) and Apt integration, where all the groundwork has already been done by mvo's GSoC student a while ago, AFAIR
<zyga> juliank: and command and package names will actually worsen the result (suggesting other packages)
 * zyga has gone that way 
<ximion> at Ubuntu, I have no idea yet
<zyga> ximion: wait, I'm lost one one thing, can I use the new provides syntax today or not?
<juliank> zyga: You just need to calculate the Levenshtein distances between the command and the package names and choose the smallest as the best option
<zyga> ximion: and do I understand that it's still needed to patch all the packages to declare this correctly
<zyga> juliank: it's crap, I tried that
<zyga> juliank: really
<zyga> juliank: I spent a year just on this part of c-n-f
<zyga> juliank: and it's utter crap in the end
<zyga> juliank: you need way more context to produce hints that are not silly
<zyga> juliank: and you want to still have fast lookup
<juliank> What? *If you know* that the file is in a few packages, choosing the one with the closest distance is the best idea.
<zyga> juliank: (though I'm sure there are structures that answer this quickly)
<zyga> juliank: I see what you mean but the problem is that it's not good in general
<ximion> zyga: no, it's not yet usable to the full extend. It's enough though to power GNOME-Software, if you do a little bit of manual work
<zyga> juliank: gcc is just one example
<zyga> ximion: ok, so I can use it today?
<juliank> It may fail on some cases, but in most it should work just fine.
<zyga> ximion: and then this gets aggregated by some archive
<ximion> zyga: no, a lot of data can be extracted automatically - but for really rich metadata, you need to drop a little bit of XML into /usr/share/appdata
<zyga> ximion: (cnf should also be offline, if it is online we can just ask google each time)
<juliank> awk is a silly example, because both mawk and gawk have the same distance
<zyga> juliank: I think this is highly subjective but the value is in _useful_ hints, not theory, IMHO non-declarative or weighted declarative approaches for that are not worth the trouble as the advice is just poor and the extra cost is large
<zyga> ximion: ok, for the trivial cases dep-11 is not an improvement
<juliank> It's extracted from packages and XML in packages, and put into a YAML (?) index that APT will download. You/It then parse the index and create a database
<juliank> The difficult cases need to be declared manually then
<ximion> zyga: https://github.com/ximion/dep11 - careful though, the code has some very awkward bits which I intend to improve soon. Reason is its past as integral DAK component and GSoC work
<zyga> ximion: it is an improvement for cases like vim, that are actually quite complex and rely on alternatives
<zyga> ximion: and that naive harvesters cannot process
<zyga> ximion: the harvester in cnf is one level above naive
<zyga> ximion: so dep11 has to be better in practice if it can be adopted as a data source
<ximion> zyga: for the immediate use, I'd stick to c-n-f - it does a reasonably good job :) (don't have enough backlog to fully understand the issues you have with it)
 * zyga looks at the link
<juliank> zyga: Try taking popcon into account as well, that might help. Algorithms. Get a few drunk Google search people to help you.
<zyga> ximion: the issue is that 1) harvesting requires the full archive 2) it's a heruistic as many "interesting" packages use scripts to actually create executables and simple scans don't reveal those
 * juliank is not sure if you can drink and develop search algorithms
<zyga> juliank: is popcon data available offline
<ximion> zyga: the python-dep11 stuff just generates the metadata. To access it, you can use "appstream-index search <blah>", or whatever the tool hughsie wrote for appstream-glib is called
<juliank> zyga: You'd obviously fetch it once.
<zyga> juliank: I strongly oppose online searches as this basically turns cnf into a different product/service (which is not bad, just different)
<juliank> and from time to time
<zyga> ximion: I see, so ...
<juliank> that is, when apt-get update runs
<zyga> ximion: so to get a replacement dataset for cnf
<zyga> ximion: I'd still have to do this locally and then regenerate a big -data package
<zyga> ximion: (well not big but non-trivial)
<zyga> ximion: and that would work for debian and ubuntu down the line later
<zyga> ximion: I'd preferrably have a python or ctypes python api though I can probably make that (gi should work)
<juliank> Well no, APT get will download the DEP-11 metadata. You'd parse it in a post-download hook and generate a cache locally on the client (or use the appstream library)
<juliank> s/APT get/APT/
<zyga> ximion: do you accept pep-8 clenup patches?
<ximion> zyga: I accept all reasonable patches
<ximion> ....and PEP-8 cleanup is highly welcomed!
<ximion> need to fire it at the code again soon anyway, after the dust has settled
<juliank> We need a newer pep8 version in the archives
 * ximion plans to rip out some really bad design issues and dak-isms to make it nicer to use by 3rd-parties outside Debian
<juliank> zyga: barry: Any idea how to translate 1.0~ubuntu1 to PEP440 version numbers? Not really possible, right?
<juliank> 1.0 and the 1 just chosen as an example
<zyga> juliank: hmm, perhaps to 1.0c1
<zyga> juliank: but yeah, .preN doesn't exist, I think
<zyga> ximion: as a good sanity check, make the package pip-installable on something totally non-debian
<juliank> What I am saying is: I miss a local label for sort of pre-versions
<ximion> zyga: and APT will later know about DEP-11 and will download it on-demand. We can then read the data directly, or use the cache which will be automatically updated (Xapian is fast as hell \o/)
<zyga> juliank: I'd just ignore it TBH
<zyga> juliank: most of the time it's not relevant
 * zyga hatex xapian 
<zyga> slow as hell to update
<barry> 1.0rc1 i think
<juliank> ximion: Downloading code is in.
<zyga> brb
<juliank> in DonKult's branch
<juliank> For arbitrary indices
<juliank> in an archive
<ximion> zyga: then you haven't met the appstream-index tool ;-)
<ximion> juliank: I know, mvo told me :)
 * juliank does not like xapian either, because C++
<juliank> which is not good for minimal solutions.
<juliank> But otherwise, it's good.
<barry> at least there are rumors that xapian is now py3 compatible
<juliank> barry: Is Python 3 all you can think about?
<juliank> ;)
<zyga> ximion: I think that xapian should warrant the move to online queries
<zyga> ximion: but if you look at other OSes xapian is very bad in comparison :/
<zyga> barry: yeah, I heard that too
<barry> juliank: what else is there in life?
<zyga> but it's still slow and bloated
<juliank> barry: Music
<zyga> for what it does
<barry> juliank: my bass is py3 compatible
<juliank> zyga: Well, you could parse the indices yourself and generate your own database.
<juliank> zyga: It'll be cool and awesome.
<zyga> juliank: I still think that offline package generated by something like the repo itself (replace repo with something on the server side) is better
<ximion> zyga: if you think of apt-xapian-index, it might be slow, but appstream-index beats most other tools in performance and memory usage (it's also 99% C code). Richard's appstream-glib uses the XML/YAML directly without cache, implementing a custom XML parser which does some pretty crazy things to be really, really fast
<zyga> juliank: as downloadin a small update vs computing this over and over on memory-constrained devices (and slow devices) feels like the wrong tradeoff
<juliank> There's no large difference between a package an an index.
<juliank> With such an index, computation is not an issue
<zyga> ximion: I haven't played with a-i, I'll check it out
<ximion> so, no matter how you access AppStream/DEP-11 data, it will not really take long ;-)
<zyga> ximion: cnf is slow
<zyga> ximion: I'd like to give hints in 30ms
<zyga> ximion: that would warrant rewrite to C
<zyga> ximion: (rust/go/$shiny)
<juliank> cnf is slow. TheC version takes < 10 ms IIRC
<zyga> ximion: and proper databases
<zyga> juliank: yeah, python start-up is just slow for that
<ximion> yes indeed, C would be a much better fit for cnf
<zyga> juliank: no doubt about that
<zyga> I think one of the oldest versions of CNF were written in C
<zyga> but I didn't publish that
<zyga> then I rewrote it to vala
<juliank> It's more crazy on HDDs and uncached.
<zyga> but one of the bits were missing a .vapi and I didn't know how to make the lacking parts
<zyga> the last thing I did is a dbus service
<zyga> where it would spawn and sit around
<juliank> Oh god, no dbus
<zyga> that was actually neat
<zyga> but yeash
<zyga> and then it was impossible to shutdown dbus services reliably
<zyga> on idle
<juliank> Just a simple hash db like now, and a C frontend.
<zyga> now with systemd it is, but that was long ago
<zyga> juliank: some things (spell checks) are cpu and db heavy
<zyga> juliank: I think the current DB is not good for that
<zyga> juliank: or the hash db has to have misspellings but that's crazy
<juliank> Well, then you need either xapian or sqlite3
<zyga> juliank: a hybrid db would be better (hybrid == different DBs)
<juliank> those can match related words
<zyga> juliank: I wasn't aware sqlite has that feature, do you have any hints?
<ximion> can KyotoCabinet match similar phrases?
<zyga> (currently cnf just generates more queries0
<juliank> KyotoCabinet might be nice too
<zyga> juliank: looking at the api it doesn't seem to
<zyga> juliank: unless you want to just walk the keyspace and run conversions
<juliank> Well, it's a B+ Tree
<zyga> yeah
<zyga> I did a project a decade ago
<zyga> that has some value
<zyga> but it does require an offline processed database index
<zyga> though
<zyga> one small observation
<zyga> even if each debian package has 10 executables
<juliank> I think sqlite3's full-text-search engine has a feature to match misspelled words, but I'm not sure
<zyga> that is still _very little_ data to compute
<juliank> But I think it's overkill and the current version works well enough.
<zyga> and I think just runing a very fast routine on _everything_ is faster than anything else fancy
<juliank> People won't run command-not-found on phones
<zyga> a list of just the keys (executable names)
<zyga> that list is probably around a meg or two
<zyga> juliank: try raspberry pi
<zyga> juliank: slow CPU, slow IO
<juliank> I'm basically happy with the state I have in Debian's 0.2.38.
 * zyga hasn't used cnf on debian yet
<juliank> zyga: Why would you want to run stuff there in an interactive terminal?
<zyga> juliank: I do all the time :)
<juliank> You should just deploy your finalized container there....
 * juliank had to mention containers once in his lifetime
<zyga> juliank: I use it for tinkering and on-device hacking, different use case, it's not a server
<zyga> heh :D
<juliank> I think Vala is a good language, but it's a bit overly complex for something as simple as command-not-found.
<juliank> No need for object orientation and friends.
<juliank> zyga: The hard-core version is to create a domain-specific library in C++ and then create C++ code from the archive and compile the entire database into the executable.
<juliank> That would be insanely fast.
<zyga> juliank: with my love for C++ that's not likely, I'll probably use C for the fast version
<zyga> juliank: for the database, not sure
<juliank> We don't want something exotic.
<juliank> It should be priority: standard or important or required
<zyga> juliank: I agree
<zyga> juliank: I think just running the exact same stuff in C will be great
<juliank> It will.
<juliank> There are not many alternatives anyway. You could switch to berkeley db, sqlite3 or xapian.
<jrwren> zyga: i remove xapian. :)  Who needs it?
<juliank> Nothing is going to improve a lot.
<zyga> separate problem, first let's revive the upstream code
<zyga> and dedupe forks and whatever
<zyga> so that there's one code to work on
<juliank> zyga: BTW, The thing with the spelling corrections is: The DBs use stemming algorithms for it. That won't work well on packages.
<zyga> juliank: ah, yeah, package names can be hostile
<juliank> or well, command names.
<juliank> zyga: Just take the 0.3ubuntu15.1 release and call it 0.3.1? Then move the data out of the package, so mvo or a bot can update it automatically
<zyga> juliank: yep, that's a good first step
<juliank> That is, have a command-not-found source package and a command-not-found-data package.
<juliank> source package.
<zyga> juliank: oh, that is true today
<zyga> juliank: but those are binary packages
<zyga> juliank: I think what you are asking for are source packages
<zyga> juliank: that would make sense
<juliank> Right, yes
<juliank> Then you have sane releases of code.
<zyga> juliank: one thing I don't know how to do is where to keep the git tree, I'm used to svn based python workflow in debian
<zyga> and I love git
<juliank> And can just version the data in a sane way, such as 15.10.20150403
<zyga> but I don't know how to get a collab maint git repo in debain
<zyga> debian
<juliank> zyga: Launchpad also has limited git support now.
<zyga> juliank: I know that very well (using it)
<juliank> zyga: But collab-maint is easy. You just need to join the group in alioth
<barry> zyga: it's pretty easy
<barry> zyga: well, alioth is
<zyga> give me a sec
<juliank> And then you ssh to alioth and run a command
<zyga> ok, I've sshd to alioth
<zyga> now what?
<juliank> https://wiki.debian.org/CollaborativeMaintenance
<juliank> zyga: cd to /git
<barry> zyga: if it's dpmt: https://wiki.debian.org/Python/GitPackaging
<juliank> No wait.
<juliank> There was a shell script somewhere
<juliank> https://wiki.debian.org/Alioth/Git
<kamal> zyga, juliank: https://wiki.debian.org/Alioth/Git
<kamal> yeah.  that.  :-)
<zyga> daughter emergency
<juliank> zyga: Easiest way: Run gbp create-remote-repo from your source tree
<zyga> crying because jurrasic world is not good for 6 year olds
<zyga> juliank, barry, kamal: thanks, I'll give that all a try in a sec
<zyga> as soon as I can :)
<juliank> Oh cool, my 0.2.38-1 package has proper patches.
<juliank> zyga: My idea would be to have the code + update from Contents file thing upstream, and installing update-command-not-found on !ubuntu (depending on command-not-found-data in Ubuntu instead). This way, we can have one command-not-found package synced between Debian and Ubuntu.
<juliank> Not even have to merge it.
<juliank> Ubuntu just provides the additional command-not-found-data source and binary package and everyone is happy.
<juliank> (Maybe also ship update-command-not-found in Ubuntu for third-party repositories)
<zyga> juliank: that sounds good to me (still not here yet)
<mhall119> cjwatson: pitti: mdeslaur: and any other dual Ubuntu/Debian developers, I've been asked for somebody from the Ubuntu side to comment on https://lists.debian.org/debian-derivatives/2015/06/msg00021.html about how we manage the same process (porting patches back to Debian)
<mdeslaur> mhall119: I use submittodebian, I don't have anything further to contribute to that discussion beyond that
<mhall119> mdeslaur: is that an ubuntu-specific tool?
<mdeslaur> mhall119: yeah, it's in the ubuntu-dev-tools package
<mhall119> mdeslaur: you might just mention that it exists and what it does, maybe it's something rasbian can use
 * mdeslaur googles "rasbian"
<mhall119> raspbian actually
 * mdeslaur googles "raspberry pi"
<mhall119> it's Debian for Raspberry pi
<mhall119> what rock have you been under?
<dobey> a securely reinforced one, i hope
<mdeslaur> mhall119: I'm old. When I was in school, our boards had 6809's on them.
<mhall119> when I was in school, our boards were black and required chalk :-P
<mdeslaur> hehe
<zyga> mhall119: ah, the best kind
<mhall119> zyga: meh, the I/O throughput left a lot to be desired
<zyga> mhall119: I'll take that over whiteboards any day
<sarnold> that "new chalk smell" tho
<mhall119> some classrooms even had dual-board technology: http://aarco.com/05B.gif
<sarnold> banked memory! sweet!
<mdeslaur> wow, fancy :)
<mdeslaur> you went to one of those expensive schools by the looks of it :)
<mhall119> only problem was that whenever you tried to delete something, you invariable ended up with data all over your hands
<jrwren> i/o throughput on rpi isn't that great either ;)
<mhall119> jrwren: so I've heard :)
<kamal> @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:
<juliank> Guys, anyone still here (barry?? I'm not sure what's happening: Our Python extension is producing a DeprecationWarning. I want to catch that in the unittests (did not check previously). Now, on the build daemons, the warning is not issued (those the new assert fails), but on autopkgtests it is (previously failed because warning was printed)
<juliank> What's the best way out this? Pass -Wall to our test script in both enviroments?
<juliank> I mean, I'm not entirely sure why the DeprecationWarning is issued on autopkgtest, but not on the build servers. That does not make sense to me
 * juliank just got the report from the daily PPA build, that's why he's asking now
<infinity> juliank: The warning is so issues on the build daemons.
<juliank> so issues?
<infinity> juliank: The only difference here is that you can spew whatever you want to stderr in a build log and we don't care, but autopkgtest's default is to fail on stderr.
<ogra_> some ?
<ogra_> :)
<infinity> s/issues/issued/
<infinity> /build/buildd/python-apt-1.0.0~beta2/tests/test_paths.py:46: DeprecationWarning: Using the md5 keyword is deprecated, please use 'hash' instead
<infinity>   md5="abcdef")
<infinity> I see that in your build log.
<infinity> The same warning that's killing adt.
<juliank> infinity: No, it does not show at all. Python disables it by default, but the autopkgtest server seems to enable it.
<juliank> infinity: Well, strange. On the PPA, the build failed, because no warning was issues: https://launchpadlibrarian.net/209249914/buildlog_ubuntu-vivid-amd64.python-apt_1.0.0~beta2%2B866~ubuntu15.04.1_BUILDING.txt.gz
<infinity> juliank: I'm staring at a build log right now with the warning in it...
<juliank> This assertion checks that a warning was issued.
<infinity> https://launchpadlibrarian.net/209219612/buildlog_ubuntu-wily-amd64.python-apt_1.0.0~beta2_BUILDING.txt.gz
<juliank> Right. That was the old version. We did not catch the warning there. We catch now, and the PPA build fails.
<infinity> juliank: Okay, so this isn't about a difference between a buildd and adt, this is about your code changing. :)
<infinity> juliank: And catching warning implies not printing them, I suspect.
<infinity> Just like any other caught exception.
<juliank> Yes, that's the point. I'm not sure why it cannot catch the warning (I assume it does not produce two warnings, I check for len(warnings) == 1)
<juliank> if it was issued previously, it should be now
<juliank> Anyway, I think I'll just add -Wall everywhere and it should work
<infinity> juliank: Okay, maybe I'm misunderstanding.  I assumed you were talking about the production adt, which was printing the same warning as the production buildd on the same version.
<juliank> Or does someone have a better idea?
<infinity> juliank: And the PPA build, of course, is catching and not printing the warning, but asserting instead, which seems to be what you asked it to do.
<juliank> infinity: The autopkgtest on 1.0.0~beta2 failed because it wrote the warning. Now I'm trying to fix that. I catched the warning and assert that it's there. But during the build, it suddenly is not there anymore according to the PPA builder (or 2 warnings were issued inside the block, which seems unlikely).
<juliank> I checked that precisely one warning is issued and that it has the type deprecationwarning
<infinity> juliank: Okay, but this has nothing to do with how buildds are calling/building it, as can be seen by the version in the archive whose output matches the adt run.
<juliank> But how do those buildds and adt call it to enable the warning? Maybe there's a difference to PPA builders (Debian buildds do not show the warning either)
<infinity> juliank: They do nothing special.  It's just dpkg-buildpackage
<juliank> But it's strange. On 1.0.0~beta2, the same version. The Ubuntu buildds show a DeprecationWarning and the Debian ones don't
<juliank> Let me check how previous PPA builds went
<juliank> The old PPA build issued the warning too
<infinity> juliank: Debian buildds appear to skip your testsuite entirely because sources.list isn't readable.
<infinity> juliank: So, not a useful datapoint.
<juliank> True
<juliank> But still, that commit http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=12b0e06cb6db76e60455d13269e6ff3fedab5812 should catch precisely the warning and check for it.
<juliank> Is there any danger in passing -Wall to python?
<infinity> I'm not a python guy, don't know.
<infinity> juliank: So, if I'm reading https://docs.python.org/2/library/warnings.html right, the warning filter ignores DeprecationWarning by default.
<juliank> Yeah, but it somehow shows up on the buildds and on autopkgtest
<juliank> That's the reason I'm wondering
<infinity> juliank: Not a python guy, but I assume they mean the fancy filter, ie: the one you just added to catch your warnings.
<infinity> Maybe not, though.  I dunno.
<juliank> If I run it locally, it works with -Wall (the warning is issued and catched (previous behavior as it was on buildd)). Without -Wall, the warning is not issued and not caught
<juliank> But now, it is not caught on the buildds, despite being printed in previous builds.
<juliank> Which is crazy
<infinity> I would have assumed that's a byproduct of you importing the class and mucking with it.
<infinity> juliank: 28.6.4 seems relevant on that page.
<infinity> juliank: I think you just need a 'warnings.simplefilter("always")' before you trip your warning.
<infinity> juliank: But that exact code example is exactly what you want to do, so a bit of copy and paste should do it.
<infinity> https://docs.python.org/2/library/warnings.html#testing-warnings
<juliank> Ah right
<juliank> Missed that bit
<juliank> Thanks, infinity
<juliank> Fixed in git. Started an import in launchpad, and will then trigger a PPA build again.
<juliank> If it works, I'' do a beta3 tomorrow
<robert_ancell> How to I get valac-0.28 into main? Since nothing explicitly depends on it is there some override that brings it in like valac-0.26?
<juliank> Oh yes, it build!
<infinity> robert_ancell: You don't.
<infinity> robert_ancell: Not until the default vala version (defined by who builds the valac binary) changes.
<robert_ancell> infinity, that already appears to have changed
<robert_ancell> infinity, I'm getting build failures e.g. https://launchpadlibrarian.net/209188618/buildlog_ubuntu-wily-amd64.zeitgeist_0.9.14-2.2ubuntu5_BUILDING.txt.gz
<infinity> robert_ancell: Oh, so it did, apt-cache and I were having a small argument there.
<infinity> robert_ancell: So, the answer is "ask".  I'll do it now.
<robert_ancell> infinity, thanks!
<infinity> robert_ancell: Fixed after ~30m of publisher churn.
#ubuntu-devel 2015-06-17
<pitti> mhall119: that sounds a bit like our merge-o-matic?
<pitti> Good morning
<pitti> infinity, Laney: can we please ignore the broken tests for linux 4.0.0-2.4 as well?
<infinity> pitti: It's broken for other reasons, we're not letting it migrate right now.
<infinity> pitti: But if you want to ignore it for something waiting on it, sure.
<pitti> infinity: ok; but it blocks other packages
<infinity> pitti: Fixing.
<pitti> infinity: cheers!
<pitti> jdstrand: I'm merging libseccomp2 again (it's rather trivial), I need Debian's -2 to unbreak separate /usr; I hope you don't mind?
<sarnold> pitti: that's almost certainly fine, the last changelog entry looks like there's not many local changes remaining
<pitti> sarnold: no, just adding the autopkgtest
<pitti> and the only change in -2 is to move the library from /usr to /lib
<sarnold> pitti: at least, jdstrand's usually good about keeping his changelogs precise and accurate :)
<pitti> sarnold: yes, and the patches.u.c. diff agrees with him :)
<sarnold> pitti: are the 'new' library paths still covered by the apparmor <abstractions/base> file?
<pitti> sarnold: oh, do we do per-library paths in apparmor? /me checks
<pitti> grep -r seccomp /etc/apparmor*  â no hits
<sarnold> pitti: not usually.. I ust wanted to make sure that these weren't going someplace unexpected :)
<pitti> no, just the standard /lib/x86_64-linux-gnu/ (or whatever the architecture is)
<sarnold> pitti: how have I been here nearly three years and never seen patches.ubuntu.com??? this is awesome. thanks. :)
<pitti> like libc.so.6 or libdbus and stuff
<pitti> sarnold: heh -- it's a by-product of MoM (merges.ubuntu.com)
<sarnold> this is cool, I've thought before that relying upon the changelog to keep track of the ubuntu/debian delta was prone to mistakes. this is great :)
<pitti> sarnold: but you did see MoM, I hope? that also gives you both diffs
<sarnold> pitti: I think I've only ever seen the summary universe.html and so on there..
<dholbach> good morning
<dkessel> good morning dholbach
<dholbach> hey dkessel
<dholbach> mitya57, did you upload ubuntu-packaging-guide already?
<mitya57> dholbach, oops, I forgot :/
<mitya57> Will do now :)
<dholbach> awesome, thanks!
<mitya57> dholbach, uploaded (will be in NEW queue though)
<dholbach> thanks a lot mitya57!
<mitya57> Sorry for forgetting :)
<dholbach> no worries :)
<infinity> pitti: What's the state of the art on reproducing adt failures locally?
<pitti> infinity: hasn't changed in a long time -- easiest is to use the qemu runner
<pitti> infinity: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<pitti> infinity: the biggest difference is the internet proxy that we (have to) use in production
<pitti> otherwise it's pretty much exactly the same
<infinity> pitti: Kay.  Can I run a single test there, or will it just run everything in debian/tests/control unconditionally?
<pitti> infinity: you can use --testname to run a single test
<infinity> pitti: Shiny.  Thanks.
<pitti> adt-run --testname mytest1 mysrc
<pitti> infinity: and usually you want -s too
<pitti> (--shell-on-failure)
<infinity> pitti: I think I had all this going at one point, then new laptop happened.
<pitti> infinity: well, it's really just one "adt-buildvm-ubuntu-cloud" command away :)
<pitti> infinity: and yeah, getting new laptop beats destroying a throwaway VM any time :)
<infinity> Apparently, cloud-images.ubuntu.com is connected to the internet with a bendy straw.
<pitti> oh, is it slow for you?
<infinity> pitti: Around 1MB/s, looks like.
<infinity> pitti: So, slow for me.
<pitti> up to vivid it was reasonably fast here, then in April/May it was ridiculously slow, and now it magically fixed itself again to be as moderately-fast as before
<pitti> infinity: so, best not to look at it :)
<infinity> A watched image never downloads?
<Odd_Bloke> infinity: Are you connected to the VPN; I've sometimes seen image downloads routed through that.
<Odd_Bloke> s/the VPN/the Canonical VPN/
<Odd_Bloke> Which is obviously sloooow.
<infinity> pitti: If I'm just experimenting with debian/tests, I assume I want something like '--unbuilt-tree foo-1.2.3-1 -B'?
<infinity> Odd_Bloke: Yeah.  Until we fix it to allow me to be connected to both endpoints, that's probably my issue.
<infinity> Odd_Bloke: I do occasionally forget I have that issue, though. :P
<pitti> infinity: put the -B before (it only applies to the next test argument), but in principle yes
<pitti> infinity: I usually use something like "adt-run ./ --- qemu ...", typing laziness
<pitti> infinity: <dir>/ is an abbreviation for --built-tree <dir>
<pitti> and <dir>// for --unbuilt-tree <dir>
<pitti> greetings from iwj from 9 years ago :)
<infinity> pitti: Hahaha.
<infinity> pitti: FWIW, --testname isn't documented in the manpage.
<infinity> pitti: Erm, and my first derp.  Clearly this isn't performing exactly how prod does...
<infinity> Source Package Version: 4.0.0-2.4
<infinity> Running Kernel Version: 3.19.0-20.20
<infinity> ERROR: running version does not match source package
<pitti> infinity: man> thanks, fixed in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=16eb56eac
<pitti> infinity: well, production gets called on a source package; I assume your test that does this comparison is newer than the binaries in wily?
<pitti> infinity: i. e. if your --built-tree is newer, you also need to include the newer .debs in the adt-run to run against those instead of wily's binaries
<infinity> pitti: I'm running against a source package that matches the binaries in wily-proposed.  Which means the testbed needs to upgrade and reboot.  Which I assume it does in prod.
<pitti> infinity: or enable proposed
<infinity> pitti: proposed is enabled on the commandline.
<pitti> infinity: yes, that's mentioned on http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<infinity> Oh, wait, maybe I missed -U
<infinity> Let's see if that fixes it.
<pitti> infinity: yes, --apt-pocket only adds the apt source, doesn't run apt-get
<infinity> pitti: Yeah, bad copy-pasta on my part.
<infinity> Ahh, lovely.
<infinity> adt-run [02:36:44]: rebooting testbed after setup commands that affected boot
<infinity> That looks more promising.
<mardy> mvo: hi! Do you have some minutes to help me investigate bug 1454210?
<ubottu> bug 1454210 in webapps-sprint "accounts are lost each time the app is updated from the store or run on the device from qtc" [High,Triaged] https://launchpad.net/bugs/1454210
<mvo> mardy: let me have a look
<mvo> mardy: that bug is confusing, so it only removes evernote accounts but nothing else? click does not touch userdata (yet) on upgrade. it will stop the app though
<mardy> mvo: so, we have a click hook in OA, which has a pattern to copy some files to ~/.local/share/online-accounts-hooks/
<mardy> mvo: then we have a hook processor which reads these files and generates a more elaborated version under ~/.local/share/accounts/providers/
<mardy> mvo: this hook processor also takes care of removing stale files and accounts, when the corresponding app gets removed
<mardy> mvo: the way it works, is that it scans ~/.local/share/accounts/providers/, and then it tries to find the corresponding originating file in ~/.local/share/online-accounts-hooks/
<mardy> if it doesn't find it, then it deduces that the app has been removed, and therefore removes the file in ~/.local/share/accounts/providers/ and any created accounts
<mardy> mvo: does this sound correct to you? ^
<mardy> mvo_: did you miss some lines?
<mvo_> mardy: sorry, network issues, the last I got was "seconds)
<mvo_> <mardy> mvo: this hook processor also takes care of removing stale files and accounts, when the corresponding app gets removed"
<mardy> mvo_: ok, I'll repaste
<mardy> mvo_: the way it works, is that it scans ~/.local/share/accounts/providers/, and then it tries to find the corresponding originating file in ~/.local/share/online-accounts-hooks/
<mardy> mvo_: if it doesn't find it, then it deduces that the app has been removed, and therefore removes the file in ~/.local/share/accounts/providers/ and any created accounts
<mardy> mvo_: does this sound correct to you? ^
<mardy> mvo_: the files are named after the short app id (that is, without the version number)
<mvo_> mardy: yes, makes sense
<mvo_> mardy: so one fix would be for click to behave differently I guess - I need to look first why its doing what its doing
<mardy> mvo_: mmm... actually, wait... the hook pattern we use keeps the version number
<mardy> mvo_: ok, I guess that I have something to fix there, I should try to match the unversioned file
<mvo_> mardy: ok, thanks. let me know how it goes and good luck :)
<mardy> mvo_: ok, if you don't here from me, then all it's good on your side :-)
<mvo_> :)
<mvo_> ok
<jamespage> please could an archive-admin merge lp:~james-page/+junk/sync-backlist-openstack into the sync backlist - some updates for openstack projects
<jamespage> thanks
<cjwatson> jamespage: I remain confused why we're blacklisting these at all.
<cjwatson> jamespage: Surely we have "ubuntu" substrings in our versions.
<jamespage> cjwatson, I'm happy just to drop them all tbh - I just tripped on trying to sync a client package from debian
<jamespage> cjwatson, you are quite correct - they would always show as a merge
<jamespage> cjwatson, ok I've dropped all openstack packages from my branch - ok to go with that?
<cjwatson> jamespage: The only one there might be any justification for would be openstack-meta-packages
<cjwatson> jamespage: Do you want that to pop into wily?
<jamespage> cjwatson, let me check on openstack-meta-packages
<infinity> jamespage: openstack-meta-packages probably conflicts conceptually with the "openstack" package that I'm waiting on stokachu to reupload.
<infinity> jamespage: It doesn't actually conflict, but I imagine confusion if we ship both.
<jamespage> infinity, ok - lets leave that blacklisted still - I think it relies on a load of features in the debian versions of those packages we don't support in ubuntu
<jamespage> infinity, cjwatson: lp:~james-page/+junk/sync-backlist-openstack updated
<caribou> Q: When adding an upstart job to an existing package, does the sysVinit script get automatically inhibited or we need to add the 'init_is_upstart' override ?
<ogra_> caribou, for what release ?
<caribou> ogra_: Trusty
<ogra_> upstart is gone (for system statup)
<ogra_> ah
<caribou> ogra_: yeah, I know it's for a Trusty SRU
<caribou> ok, I think I found the answer :
<caribou> when the package is installed with an upstart job, the sysVinit script is installed but not enabled
<caribou> I'll put the override, in case someone enable the script by accident
<cjwatson> jamespage: merged; give it 5min or so to propagate before you try syncpackage again
<cjwatson> caribou: You should follow https://wiki.ubuntu.com/UpstartCompatibleInitScripts
<caribou> cjwatson: thanks for the URL
<jamespage> cjwatson, thankyou
<rbasak> infinity: around? docker.io backports incoming. Preview in https://launchpad.net/~docker-maint/+archive/ubuntu/staging/+packages - do you want me to just throw all of this at the SRU queues?
<rbasak> infinity: bug is https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1454719 - shall I create a task for each package being backported?
<ubottu> Ubuntu bug 1454719 in docker.io (Ubuntu Vivid) "docker.io update to 1.6.1" [Wishlist,Triaged]
<infinity> rbasak: Should be tasks for everything, yes.
<rbasak> infinity: OK bug updated and everything is in the queue now
<infinity> rbasak: Ta.
<LocutusOfBorg1> Hi Folks, I see libjsoncpp still in universe pocket, is it normal?
<LocutusOfBorg1> talking about bug 1461517 and comment #3
<ubottu> bug 1461517 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Fix committed] https://launchpad.net/bugs/1461517
<LocutusOfBorg1> there is a serious bug against libjsoncpp and I merged in Debian the relevant delta
<LocutusOfBorg1> so I would like to ask a plain sync ASAP
<LocutusOfBorg1> but I don't know how this deals with the MIR request
<infinity> LocutusOfBorg1: I'll have a look at both.
<LocutusOfBorg1> infinity, it's almost dinstall time in debian
<LocutusOfBorg1> so the sync is not possible (yet) I guess ;)
<LocutusOfBorg1> thanks!
<doko> wgrant, stealing your ustr merge
<mhall119> pitti: I'm not familiar with merge-o-matic
<infinity> LocutusOfBorg1: Where's this new cmake that the MIR talks about?
<LocutusOfBorg1> -proposed I guess
<infinity> Oh, so it is.
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/cmake/3.2.2-2ubuntu1
<infinity> component-mismatches-proposed isn't showing the promotion.  Grr.
<LocutusOfBorg1> (I feel guilty for the cmake merge, this is why I'm bothering so much :p )
<infinity> LocutusOfBorg1: Guilt is a good motivator.
<LocutusOfBorg1> :)
<LocutusOfBorg1> and the love for cmake is a good motivator for a merge
<infinity> LocutusOfBorg1: Tell me more about this "broken shlibs file" fixed in -4...
<infinity> LocutusOfBorg1: Is it so broken that we don't want things building against -3?
<infinity> LocutusOfBorg1: Should I remove it from -proposed?
<LocutusOfBorg1> yes, exactly
<LocutusOfBorg1> that would be awesome
<LocutusOfBorg1> it isn't generating the shlibs:depends correctly, so packages built against libjsoncpp-dev won't depend on libjsoncpp0
<infinity> LocutusOfBorg1: Oh, that's quite unfortunate.  Do we know if anything's been built with that breakage so far? :/
<LocutusOfBorg1> please look at the debian bug in -release
<LocutusOfBorg1> I can do something similar for ubuntu
<LocutusOfBorg1> anyway I guess the answer is "nothing"
<infinity> LocutusOfBorg1: If you could check the rdeps and see if anything was built against the broken version, that would be great.
<infinity> LocutusOfBorg1: Hopefully, the answer is no, but best to know.
<infinity> LocutusOfBorg1: And I've removed it from -proposed for now.  -4 can be synced when LP learns about it.
<LocutusOfBorg1> sysdig is built against the old jsoncpp
<LocutusOfBorg1> thanks
<infinity> LocutusOfBorg1: sysdig is broken on ARM anyway, can kill two birds with one stone by just deleting it and waiting for a new Debian sync that fixes that. :P
<infinity> LocutusOfBorg1: Anything else?
<LocutusOfBorg1> much stuff built against the old version
<LocutusOfBorg1> kopete was a lucky case, uploaded the day before libjsoncpp, but I looked at all the build logs and they are fine (picked up the old one everywhere)
<infinity> LocutusOfBorg1: Just so I'm sure I'm parsing that correctly: the only broken package was sysdig, then?
<LocutusOfBorg1> no
<infinity> LocutusOfBorg1: Which I've just removed wholesale, since it was FTBFS on ARM anyway, so meh.  No need to rebuild it.
<LocutusOfBorg1> broken is anything depending on 0.10.2-1+
<LocutusOfBorg1> and nothing is built against it
<LocutusOfBorg1> many packages are built against the old 0.6 who was fine
<infinity> LocutusOfBorg1: Okay, that's what I said. :)
<LocutusOfBorg1> I just had a trouble for kopete, uploaded on the day before, but it built quickly
<LocutusOfBorg1> and with the old version
<LocutusOfBorg1> so I guess syncing it, and MIRing it would be fine
<infinity> LocutusOfBorg1: MIR already sorted.
<infinity> LocutusOfBorg1: Can sync when LP knows what's up.
<LocutusOfBorg1> so now cmake starts building?
<infinity> Should do soon, yeah.
<infinity> Assuming it can build against 0.6
<infinity> (If it can't, it should have a versioned build-dep, which it doesn't, so...)
<LocutusOfBorg1> wow, yes, actually I built and tested against 0.6
<LocutusOfBorg1> I got the trouble because my ppa had universe enabled
<LocutusOfBorg1> the only problem is actually than the old jsoncpp wasn't versioning correctly
<LocutusOfBorg1> infinity, is that a problem?
<LocutusOfBorg1> bug 1218220
<ubottu> bug 1218220 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Won't fix] https://launchpad.net/bugs/1218220
<LocutusOfBorg1> this is why I was trying to merge the new one
<pitti> Laney: in case you are interested, the udisks2 regression is tracked in bug 1466081
<ubottu> bug 1466081 in systemd (Ubuntu) "[udev] no uevent when block devices change" [High,Triaged] https://launchpad.net/bugs/1466081
<infinity> LocutusOfBorg1: I don't recall what I meant by that, since it was two years ago...
<LocutusOfBorg1> it was lacking of a sane versioning ABI
<infinity> LocutusOfBorg1: Okay, well, it's still libjsoncpp0, I don't see how that solved the problem. :P
<LocutusOfBorg1> and this is fixed with the new one, I would like to cancel cmake builds and wait for the new jsoncpp, but you are the boss, not me :)
<LocutusOfBorg1> this is "fixed" because upstream tracks ABI changes closely now
<LocutusOfBorg1> http://upstream.rosalinux.ru/versions/jsoncpp.html
<doko> tracking ABI changes closely and keeping the soversion?
<LocutusOfBorg1> yes, I should bother them to bump the soversion
<doko> infinity, can you do the dpkg merge?
<jdstrand> pitti: re seccomp, I don't mind at all. merge away :)
<pitti> jdstrand: ack :)
<jdstrand> pitti: fyi, I also did submittodebian on the autopkgtests and I'm discussing that with Debian
<pitti> jdstrand: yes; I asked kees yesterday and he seemed to think the nature of these tests is more like "upstream test suite", not a package integration one
<infinity> doko: Yeah, I think 1.18.1 has probably cooked enough by now.
<jdstrand> yes, he does. I think he is right about some but not all :) we'll figure it out
<LocutusOfBorg1> is cmake https://launchpad.net/ubuntu/+source/cmake/3.2.2-2ubuntu1 still building on armhf?
<LocutusOfBorg1> I'm getting oops
<infinity> LocutusOfBorg1: LP bug.  Under investigation. :P
<infinity> LocutusOfBorg1: I might have hit a button too hard.
<LocutusOfBorg1> is that your hand? http://ecx.images-amazon.com/images/I/41fXAZENBZL.jpg
<doko> pitti, could you have a look at https://bugs.launchpad.net/ubuntu/+source/sessioninstaller/+bug/1440368 ? or find somebody from desktop (although this is foundations)
<ubottu> Ubuntu bug 1440368 in sessioninstaller (Ubuntu) "sessioninstaller should be ported to Python3" [Undecided,New]
<Laney> pitti: thanks for looking, seems like a real real regression - yay for tests
<cjwatson> LocutusOfBorg1: DB row fixed, that build is (I'm told) intentionally cancelled.
<barry> slangasek: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1324391/comments/19  (thanks bdmurray!)
<ubottu> Ubuntu bug 1324391 in python-pip (Ubuntu Trusty) "pip 1.5.4 import an invalid dependencies " [High,Fix committed]
<hyperair> hi. could someone let banshee into vivid-updates please? the bug has been marked verified-done for a while now
<bdmurray> looking
<LocutusOfBorg1> yes cjwatson it should be cancelled, thanks!
<bdmurray> hyperair: its been released
<hyperair> yay thanks
<hyperair> bdmurray: launchpad doesn't seem to have updated yet though
<cjwatson> hyperair: https://launchpad.net/ubuntu/+source/banshee/+publishinghistory -> pending publication
<hyperair> ah, thanks
<LocutusOfBorg1> infinity, syncpackage libjsoncpp ?
<LocutusOfBorg1> still not good
<infinity> syncpackage: Error: Debian version 0.10.2-4 has not been picked up by LP yet. Please try again later.
<LocutusOfBorg1> requestsync doesn't show the error
<LocutusOfBorg1> but syncpackage does
<infinity> LocutusOfBorg1: It does if you pass -V
<LocutusOfBorg1> strange
<infinity> Oh, requestsync.  I never use that, for obvious reasons.
<infinity> And it might be buggy with rmadison returning multiple versions in unstable.
<infinity> I was just knee-deep in that code a couple of days ago, perhaps I should dive back in.
<LocutusOfBorg1> infinity, some hours ago it was failing at the begin with "ubuntu has an higher version", now seems to go a little after
<LocutusOfBorg1> syncpackage: D: Source package libjsoncpp is temporarily blacklisted (blacklisted_current). Ubuntu ignores these for now. See also LP: #841372
<LocutusOfBorg1> syncpackage: Source libjsoncpp -> wily/Proposed: current version 0.6.0~rc2-3.1ubuntu1, new version 0.10.2-4
<ubottu> Launchpad bug 841372 in Launchpad itself "Incorrect auto-blacklisting in DSD?" [Low,Triaged] https://launchpad.net/bugs/841372
<LocutusOfBorg1> I see it there https://launchpad.net/debian/+source/libjsoncpp/0.10.2-4
<LocutusOfBorg1> lol I asked at the same time
<LocutusOfBorg1> now should be fine
<infinity> synced.
<LocutusOfBorg1> <3
<LocutusOfBorg1> the whole borg community thanks you
<ogra_> LocutusOfBorg1, i thinnk he'd be happy with only 7of9 :)
<infinity> ogra_: But why rule out 1 through 6?
<LocutusOfBorg1> ogra_, I would be happy too :D
<ogra_> haha
<pitti> arges: oh, you are doing SRU today?
<arges> pitti: yes... why? : )
<pitti> arges: could we release utopic/vivid for bug 1461425 today? there's already the next round of updates in bug 1464669
<ubottu> bug 1461425 in postgresql-9.4 (Ubuntu Vivid) "New upstream microreleases 9.1.17, 9.3.8, 9.4.3 - fixes regression in previous update" [Undecided,Fix committed] https://launchpad.net/bugs/1461425
<ubottu> bug 1464669 in postgresql-9.4 (Ubuntu Vivid) "New upstream microreleases 9.1.18, 9.3.9, 9.4.4" [Undecided,In progress] https://launchpad.net/bugs/1464669
<pitti> sorry about that, this was a bit crazy
<pitti> shold be back to one update every 3 months now
<arges> pitti: ah perfect i see you went through the jenkins 'failures'. I'll work on releasing that then reviewing the next round
<pitti> arges: cheers!
<LocutusOfBorg1> pitti, do you think libjsoncpp is good for a cmake rebuild?
<LocutusOfBorg1> I mean, rebuilding cmake should pick the proposed one, right?
<cjwatson> I don't think the new binaries are entirely published yet; at least rmadison doesn't show them
<cjwatson> But once they are, a rebuild will pick them up
<LocutusOfBorg1> automagically?
<LocutusOfBorg1> seems it is restarted
<seb128> stgraber, hey http://iso.qa.ubuntu.com/user/register?destination=qatracker "Have you forgotten your password?" points to http://iso.qa.ubuntu.com/user/password which is invalid
<cjwatson> LocutusOfBorg1: I don't know what you mean by automagically.  Builds in -proposed fetch build-dependencies from -proposed.
<seb128> stgraber, do you know what would be the right url to use?
<seb128> also I'm trying to log through sso and it tells me that a seb128 user already exist
<cjwatson> Hopefully whoever retried those builds checked.
<LocutusOfBorg1> it was on "build cancelled" state, do the retry happen automatically?
<cjwatson> LocutusOfBorg1: No, only manually.
<LocutusOfBorg1> ack thanks
<stgraber> seb128: it's all Ubuntu SSO, no local accounts
<stgraber> seb128: and yeah, we can't disable those links, the best we can do is make them fail
<cjwatson> LocutusOfBorg1: The master site has the new versions at the moment, so it's hopefully OK.
<seb128> stgraber, well, sso fails telling me that "The name seb128 is already taken."
<stgraber> seb128: ok. We had that happen ocasionally with old accounts, I can nuke your account in the DB which will solve that, just need to reown the data you have in the DB first
<seb128> stgraber, I guess I've an account from the before sso time but I don't remember the password
<seb128> stgraber, thanks
<stgraber> manually doing the SSO link is something I haven't figured out yet, so nuking the old account is easier :)
<stgraber> well, I could also rename the old account, that should work
<seb128> you can nuke it as far as I'm concerned
<stgraber> seb128: try now
<Laney> stgraber: after you fix his account, can you see why the rebuild I just requested failed? :)
<Laney> (see the email)
<Laney> perhaps it needs tweaking to do a cron.preinstalled build or something
<seb128> stgraber, "
<seb128> Error message
<seb128> The e-mail address seb128@ubuntu.com is already registered. Have you forgotten your password?"
<stgraber> damn, let me change that too :)
<seb128> ;-)
 * Laney screams at the rain - washing is out
 * Laney runs
<stgraber> seb128: try now
<seb128> stgraber, works! thanks ;-)
<stgraber> Laney: looking
<stgraber> Laney: desktop next I assume?
<Laney> oui
 * Laney is damp
<stgraber> ok, so I see 3 requests (one for each product) 10min ago
<stgraber> DB state is 3 which means, built according to nusakan but not published yet
<Laney> I got failure emails
<stgraber> ah, must have removed them without reading them, can you bounce them back to me?
<infinity> LocutusOfBorg1: cmake seems to have happily built against the new libjsoncpp.  Cheers.
<LocutusOfBorg1> cheers!
<Laney> stgraber: It needs to have SUBPROJECT=system-image and run cron.daily-preinstalled
<Laney> (bounced)
<infinity> Curiously, it tried to build them on the old livefs builders instead of on LP.
<infinity> Didn't even know that codepath still existed.
<stgraber> infinity: yeah, still happens when there's no LP project setup in the config
<stgraber> likely to fail horribly as we drop those old builders though :)
<dobey> does anyone know how to do the equivalent of "python3 -m testtools.run discover" using python3-covearge?
<pitti> LocutusOfBorg1: sorry, what about libjsoncpp? (I have no idea about C++ or cmake, what was the problem there?)
<infinity> pitti: It's all sorted.
<infinity> pitti: Also, I fixed the linux autopkgtests.  Merry Christmas.
<pitti> infinity: I saw, great job!
<infinity> pitti: The best part was that after I fixed it all, I noticed Brad had (most of) the same changes staged in another branch he just hadn't gotten around to merging.
<infinity> pitti: So, yay for duplicated work. ;)
<pitti> erk
<infinity> (This is really, really, really not our week for kernel stuff)
<pitti> utlemming: wrt. bug 1262951, I noticed that this is incompatible with what Debian's ifupdown now does: they include all files in /etc/network/interfaces.d/ which *don't* have a suffix, and that cloud specific change only includes *.cfg files
<ubottu> bug 1262951 in Ubuntu "cloud-images /etc/network/interfaces shoud source-directory interfaces.d" [Medium,Fix released] https://launchpad.net/bugs/1262951
<pitti> utlemming: what would I report this against?
<infinity> pitti: I'd guess cloud-init and curtin, at least, probably use that facility.
<infinity> pitti: And the only sane way forward would be to merge the two behaviours, including no-suffix and *.cfg, but nothing else.
<infinity> pitti: IMO.
<pitti> yeah, I guess so; I. e. additionally have the source-directory /etc/network/interfaces.d/ which Debian does
<infinity> Cause trying to mangle things on upgrade might end in tears.
<pitti> one doesn't usually dist-upgrade cloud instances, so that shouldn't be such a big deal
<pitti> (i. e. mangling /etc/network/interfaces)
<infinity> pitti: Lots of people dist-upgrade cloud instances.
<infinity> pitti: If you're not a hip and cool "my whole life is ephemeral" cat, starting with a cloud image and dist-upgrading is perfectly reasonable.
<infinity> pitti: But also, I'd be willing to bet curtin uses the same bits (maybe not, but worth a check), and maas+curtin for base installs is generally less cloudy.
<pitti> well, at least appending that line to /e/n/i on upgrade is not that big of a deal, but as it isn't really owned by any package it still bears the question where to put that
<pitti> (ifupdown presumably)
<infinity> pitti: Oh, if it's only included in the config file, not a default include in the source, it might be just as valid to just start doing this on new installs only.
<infinity> pitti: It's not like old installs will (as a general rule, anyway) start growing new interfaces that people expect to configure that way?
<infinity> pitti: But, YMMV, I dunno.
<pitti> yeah, hence my original question what to report this against -- is that cloud-init? or some cloud-image-builder-thingy?
<pitti> the bug above is against "Ubuntu"
<infinity> pitti: Probably cloud-init has the affected code.
<infinity> pitti: And maybe curtin, like I said.  And who knows what else.
<infinity> d-i uses interfaces snippets now too, I thought.
<infinity> Yeah, d-i does, and also writes out 'source /etc/network/interfaces.d/*'
<infinity> Which seems like neither of the behaviours you described...
<infinity> netcfg (1.127) unstable; urgency=medium
<infinity>   * Add support for /etc/network/interfaces.d/ by adding a "source"
<infinity>     directive (Closes: #770078). It can be replaced with a
<infinity>     "source-directory" one during the next release cycle.
<infinity> netcfg (1.127) unstable; urgency=medium
<infinity>   * Add support for /etc/network/interfaces.d/ by adding a "source"
<infinity>     directive (Closes: #770078). It can be replaced with a
<infinity>     "source-directory" one during the next release cycle.
<infinity>  -- Cyril Brulebois <kibi@debian.org>  Sun, 04 Jan 2015 22:48:47 +0100
<infinity> Oops, stutter paste.
<infinity> pitti: So, netcfg in Debian hasn't caught up to the new world order.  d-i still sources *, rather than source-directory.
<infinity> pitti: In conclusion, this is all a bit of a mess right now.
<pitti> yay consistency
<infinity> pitti: So, I think the right answer here is "hunt down all installers, and change what they do"... What ifupdown does is irrelevant, since 99% of the time, it's not writing interfaces(5)
<infinity> pitti: And if it's trying to change any old config files on upgrade, that would be massively wrong.
<infinity> Also, yes, yay consistency.
<infinity> netcfg still appears to write everything to interfaces(5) too.  It could really use a rewrite to write per-interface to the .d directory.
<hallyn> do-release-upgrade -d -f noninteractive.  should work?
<sarnold> hallyn: are you hitting this? https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1452238
<ubottu> Ubuntu bug 1452238 in apt (Ubuntu) "Failed to upgrade system from 14.04" [Medium,Confirmed]
<hallyn> sarnold: nah, nothing so drastic.  it just isn't being noninteractive, sits and waits for me to hit y/enter/ several times.
<sarnold> ahhhhh
#ubuntu-devel 2015-06-18
<infinity> sarnold: I sure hope no one's hitting that, given that I fixed it...
<sarnold> infinity: oh! I missed that bit :)
<sarnold> infinity: awesome, thanks :)
<pitti> Good morning
<sladen> good morning pitti
<sladen> pitti: I've taken the liberty of cross-posting (shudder, I rarely, rarely do it)  https://lists.ubuntu.com/archives/ubuntu-community-team/2015-June/000612.html
<sladen> pitti: I think that has hit the TB moderation
<pitti> sladen: hey Paul, good morning!
<pitti> sladen: I moderated your post
<pitti> infinity: I went through the dozen regressions in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 and none are gcc's fault; could we do the make-it-go-in-anyway magic?
<pitti> infinity: perhaps I really should join ~ubuntu-release to do this myself
<dholbach> good morning
<LocutusOfBorg1> nothing pitti everything is good, somebody already retried cmake and now it is on -release pocket
<LocutusOfBorg1> :D
<LocutusOfBorg1> can anybody please "syncpackage sysdig" ? it doesn't build everywhere, but at least should be build against libjsoncpp on -release
<LocutusOfBorg1> it was kicked out yesterday, and the auto import didn't pick it again?
<cjwatson> LocutusOfBorg1: syncpackage won't do it, because it was already in Ubuntu - it needs a build1 upload.  I've done that now
<LocutusOfBorg1> thanks cjwatson
<LocutusOfBorg1> whenever debian uploads a -2 revision, is the sync automatic?
<Unit193> build1 will be, yes.
<LocutusOfBorg1> thanks! so buildN are sync'd, while ubuntuN are conserved
<cjwatson> LocutusOfBorg1: The substring "ubuntu" in a version inhibits auto-sync; that's its sole technical purpose
<LocutusOfBorg1> seems legit, thanks!
<cjwatson> Nothing is special about buildN except that such versions don't normally contain "ubuntu"
<cjwatson> Oh and that it's << ubuntuN
<LocutusOfBorg1> yes of course
<LocutusOfBorg1> thanks
<doko> pitti, could you have a look at https://bugs.launchpad.net/ubuntu/+source/sessioninstaller/+bug/1440368 ? or find somebody from desktop (although this is foundations)
<ubottu> Ubuntu bug 1440368 in sessioninstaller (Ubuntu) "sessioninstaller should be ported to Python3" [Undecided,New]
<juliank> Can somebody reassign https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1448394 to the correct package (some unity one I suppose)
<ubottu> Ubuntu bug 1448394 in python-apt (Ubuntu) "lauch icon distort in ubuntu 15.04" [Undecided,New]
 * juliank is not sure which, but it's definitely not a python-apt bug
<seb128> juliank, done
<juliank> seb128: thanks
<pitti> doko: not familiar with sessioninstaller and swamped, so I can't promise that I can get to it in the next two weeks or so
<doko> ok
<pitti> seb128: ^ do you know, are we still actually using sessioninstaller?
<seb128> juliank, yw!
<seb128> pitti, I don't think we changed anything in that area so likely yes
<juliank> barry: Did you ever manage to reproduce https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1220013?
<ubottu> Ubuntu bug 1220013 in python-apt (Ubuntu) "python-apt can SIGSEGV when encountering Packages stanzas with no Description field (was: update-apt-xapian-index crashed with SIGSEGV in File())" [High,Triaged]
<infinity> pitti: I don't think anyone would object to you (re)joining the release team.
<barry> juliank: no, never did.  i wonder if mvo__ has taken a look.  iirc we needed a reproducer
<juliank> barry: Because I cannot reproduce it in Debian unstable by dropping that package without description into /var/lib/dpkg/status and then trying to get a description. It just raises an Exception, as expected
<barry> juliank: maybe it's fixed by now?
<jamespage> doko, what's the timeframe around having python3.5 as the default python3 ?
<doko> jamespage, -> barry
<jamespage> doko, ta for the redirection
<barry> jamespage: maybe this cycle.  if i can find some time where i don't have to hack on system-image, i am working on the transition.  first step is to do a partial test rebuild in a ppa and address any problems that come up.  then we can do a full archive rebuild on all arches.  if that looks good, we can at last make it supported, then hopefully default by the rc time frame (august)
<jamespage> barry, ack - we're enabling py3 across the openstack clients - started hitting a few py3.5 issues - just figuring out how to deal with them upstream as 3.5 is not on the 'even trying' list yet
<barry> jamespage: very cool.  how can i follow the issues and resolutions (well, without being avalanched by email ;)?
<jamespage> barry, I'll figure that out and let you know :-)
<Daviey> jamespage: Are you using a tag for py35 issues?
<jamespage> Daviey, tbh I only just started thinking about this - thats a nice idea
<rbasak> jibel, pitti: I'm confused by the juju-core dep8 failure. It looks like an environment issue, but failed on both amd64 and i386 (ie. two separate runs)? It passes locally on amd64. Please could you take a look?
<barry> jamespage: cool :)
<xnox> is it me, or is docker lxc exec driver totally broken on 15.04?!
<pitti> rbasak: hm, will investigate in a bit (meeting now)
<pitti> rbasak: locally it fails differently for me: http://paste.ubuntu.com/11735834/
<rbasak> pitti: is that with LXC? I used qemu, since the test actually exercises Juju+LXC and I didn't want to turn it into a test for nested LXC.
<pitti> rbasak: it's QEMU, standard adt-buildvm-ubuntu-cloud image
<pitti> with -proposed
<rbasak> Oh. I don't think I used proposed
<rbasak> Let me try again locally.
<rbasak> (with proposed)
<infinity> pitti: Will the autopkgtesting move to scalingstack happen hand-in-hand with killing jenkins from the workflow, or are those two different goals?
<pitti> infinity: I'm rebuilding this entirely from scratch with just AMQP and swift, so it'll all go away in one stap
<pitti> step
<pitti> or rather, we don't need to touch jenkins and the static machines to run the new stuff in parallel, and can switch over once we are satisfied
<infinity> pitti: SO MUCH YAY.
<barry> pitti: i'm (slowly) working on the python3.5 transition.  first step is test rebuilds in a ppa.  after that i'd like to run dep-8 tests on any of those packages that have them.  what are your thoughts about infra to do that?  can we reuse some bits of prodscalingcanonistack?
<TJ-> Any ideas about this strange issue with libvirt on 14.04? Got a VM image in $USER home directory that has previously worked (many months ago) but now when I try to start the VM (from Virtual Machine Manager) it reports "Access Denied". I check and find that the file ownership keeps being changed from '$USER:$USER' to 'root:root', despite that libvirt runs as user libvirt, which means that libvirtd (running as root) is changing ownership preventing itself fro
<TJ-> m opening the image!
<pitti> barry: in a week or so perhaps; I just started today with setting up the clouds and some baby steps :)
<barry> pitti: cool, np!  thought i would put it on your radar.  "a week or so" is probably when i'll be ready to try it anyway
<mdeslaur> TJ- do you have "user" configured in/etc/libvirt/qemu.conf?
<mdeslaur> TJ- are you using the real ubuntu libvirt/qemu packages?
<TJ-> mdeslaur: to your 2nd: yes ... let me check on the 1st
<TJ-> mdeslaur: to the 1st. no changes to qemu.conf. I worked around the issue by moving the image to /var/lib/libvirt/images/
<mdeslaur> TJ- weird, sorry, no idea
<mdeslaur> oh, actually, all my images are root:root too
<mdeslaur> looks like it's normal
<mdeslaur> did you change the permissions on your home directory?
<TJ-> mdeslaur: that was my reaction, too :)   I've always had this issue whenever libvirt opens an image it takes ownership. Used to annoy the heck out of me when I was writing/altering those images manually or by script
<TJ-> mdeslaur: No, standard permissions on $HOME
<mdeslaur> not sure why you're getting access denied on them
<TJ-> mdeslaur: Ahhh, yes, the $HOME is 710 so that'd stop libvirt traversing
<TJ-> I wish I knew why libvirtd needs to take ownership when it's running as root
<arges> hallyn: bug 1425619, is now a verification-failed and blocking qemu/libvirt SRUs. How would you like to proceed?
<ubottu> bug 1425619 in ubuntu-cloud-archive "Migration fails between QEMU 1.5 and QEMU 2.0" [Undecided,New] https://launchpad.net/bugs/1425619
<dpm> mvo, cjwatson, would you be able to help with some guidance on bug 1466432? It seems to be quite difficult to find anyone who is familiar with click
<ubottu> bug 1466432 in unity8-lxc (Ubuntu) "Cannot install click packages on the unity 8 desktop session" [Undecided,Confirmed] https://launchpad.net/bugs/1466432
<hallyn> argefeh
<hallyn> arges: feh
<arges> foo
<hallyn> arges: but,
<hallyn> he only shows his qemu pkg version.  it requires both qemu and libvirt to fix this
<arges> hallyn: i think he upgraded both, i spoke with him this morning. In addition I tried it myself and couldn't get it to work
<arges> hallyn: not sure if there is something special that needs to be done other than 'virsh migrate'
<arges> hallyn: it would be great if the original reporter tried it again. but I think we may want to skip this for now so we can get other fixes in
<hallyn> agreed
<hallyn> checking the changelogs
<hallyn> so qemu had no other colocated bugs.  so yeah i'd say revert it and push 2.0.0+dfsg-2ubuntu1.15 with whatever you were wanting to sru there
<hallyn> libvirt's more of a pain
<hallyn> hm, do you have anything for qemu that you want to sru to trusty?
<hallyn> I see two or libvirt perhaps, 1455608 and 146417
<arges> hallyn: gotta look through the list. i think right now its just libvirt
<hallyn> bug 1448205
<ubottu> bug 1448205 in libvirt (Ubuntu Trusty) "Crash when removing <filterref> from interface with update-device" [High,Fix committed] https://launchpad.net/bugs/1448205
<hallyn> weird, wouldn't work for me through pad.lv
<hallyn> arges: ok so those two are verifiaction-done.  let's rush the next libvirt with just those two for a clean confirmation
<hallyn> do yo uwant me to push the new libvirt version, or were you already on it?
<arges> hallyn: i haven't done anything yet, so have at it, and I can push the next batch with those two fixes
<hallyn> ok
<hallyn> arges: pushed
<arges> hallyn: ok i'll reivew
<hallyn> (i left the patch in but commented out in series;  maybe someone will want to take another look at some point...  )
<hallyn> (if you think i should drop it altogether for cleanliness lemme know)
<arges> hallyn: i think that's fine for now.
<hallyn> cool.  thanks as always for all your sru work :)
<arges> no problem
<apostoj> Anyone familiar with the "static-network-up" upstart signal?
<hallyn> stgraber: do you happen to know whether, for a task upstart job A that has a script section, if job B starts on started A, will it start when A's script section has started or finished?
<hallyn> apostoj: been awhile since i've looked at it, but several ppl here should be able to help
<hallyn> (guess i'll just test;  just need an upstart machine to do so :)
<hallyn> answer: as soon as it starts :)
<sarnold_> I thought there was  a way to wait for the script to have finished
<hallyn> start on stopped ?
<hallyn> sarnold_: was looking for best suggestion for bug #1466103.  i went with 'start on stopped'
<ubottu> bug 1466103 in dnsmasq (Ubuntu) "dnsmasq runs unconfined due to starting before apparmor on boot" [Critical,Triaged] https://launchpad.net/bugs/1466103
<hallyn> you may have another suggestion...
<sarnold_> hallyn: hmm. I don't see any output from grep -r apparmor in the dnsmasq source packages
<sarnold_> oh durrr that'sfrom apparmor-profiles
<sarnold_> uh
<hallyn> :)
<hallyn> yeah especiallythe mentoin of libvirt threw me for a while
<sarnold_> especially since the fix there is 100% not going to help here.
<hallyn> right
<hallyn> he hasn't yet said which dnsmasq he wants running
<doko> bdmurray, https://bugs.launchpad.net/bugs/770766 ?
<ubottu> Ubuntu bug 770766 in morse (Ubuntu Oneiric) "morse version 2.2-1 failed to build on amd64 with GCC-4.6/oneiric" [High,Fix released]
<infinity> doko: THe patch was accepted in Debian 2.4-3 and mentioned in the changelog, and that upload is a backport of same, hence the bug closure 4 years later. :P
#ubuntu-devel 2015-06-19
<robert_ancell> infinity, is clutter-gst-3.0 going to be promoted to main? The MIR is complete (bug 1466251) and totem is sitting in depwait (https://launchpad.net/ubuntu/+source/totem/)
<ubottu> bug 1466251 in clutter-gst-3.0 (Ubuntu) "[MIR] clutter-gst-3.0" [Medium,Fix committed] https://launchpad.net/bugs/1466251
<infinity> robert_ancell: Sure.
<robert_ancell> infinity, thanks
<shadeslayer> doko: ping
<shadeslayer> doko: is there a ETA for debian bug 787689
<ubottu> Debian bug 787689 in g++-4.9 "[armhf] Internal compiler error while building qtbase (qt5)" [Serious,Open] http://bugs.debian.org/787689
<pitti> Good morning
<saiarcot895> When running dpkg-buildpackage, is there any way to skip checking the files in the tarball with the files in the working directory?
<saiarcot895> (Especially with large packages)
<infinity> saiarcot895: How do you expect it to produce a diff or know if anything's changed if it doesn't?
<infinity> saiarcot895: Unless you have no intention of building a source package, and you're just iterating binary test builds, then you want -b or -B (check the manpage to see the difference).
<saiarcot895> infinity: The only changes I'm making are in the debian directory (and maybe adding a patch). Upstream sources themselves aren't being changed. I'm making a source-only package.
<work_alkisg> tjaalton: 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]
<tjaalton> alkisg: sorry, midsummer here and i'm far from my desk :)
<tjaalton> though when you step outside it feels like october..
<alkisg> tjaalton: thank you, np, slangasek maybe you could do it as the backup SRU manager?
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hey seb128
<seb128> cyphermox, hey, remember that nm-applet segfault you upstreamed a bit before vivid, there is a redhat bz pointing to this commit as fixing it, https://git.gnome.org/browse/network-manager-applet/commit/?id=98dc7a7657b2609fcac05134db99455a9de6610a
<seb128> cyphermox, could you have a look and maybe test/backport the fix?
<juliank> zyga: The PEP440 fix for python-apt is in wily now. I hope to get a 0.9.3.12 release out soon upstream (waiting from Debian stable release team ACK), then we can fix it in 0.9.3.12ubuntu1 for vivid. If that takes to long, we can also have a 0.9.3.11ubuntu1 before that.
 * juliank only closed the other bug report as fixed and kept your bug report open, because he can't do release-specific things in the bug tracker
<zyga> juliank: thanks, let's wait and see, for the immediate problem that we were facing the affected developers just applied the debdiff locally
 * zyga wonders how to track a bug differently for different releases of ubuntu 
<juliank> zyga: Oh, there's an option in launchpad for that if you have the right access level (I don't)
 * zyga looks
<juliank> zyga: See https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1132918, that has per release bug status
<ubottu> Ubuntu bug 1132918 in python-apt (Ubuntu) "Ubiquity crashes with UnicodeDecodeError in apt_pkg.size_to_str" [High,Triaged]
<zyga> hmm
<zyga> I wonder how one does that
<zyga> I might just not have enough access
<zyga> but that doesn't help to make the gui discoverable
<juliank> Hmm, bdmurray should know, he filed that one above
<zyga> yeah, I think I'd have to be a ubuntu-devel member or something
<juliank> I wonder if this works for PPU too
<zyga> juliank: ohhh, I would love that
<zyga> that would actually allow me to work on maintaining the package I care about across ubuntu
<zyga> mmm
<juliank> It might also be a release managing thing, though
<smb> pitti, Hi just noticed something odd on a Wily server VM and filed bug 1466790. Would that be more a systemd issue or ifupdown, you reckon?
<ubottu> bug 1466790 in Ubuntu "dhclient not started on boot" [Undecided,New] https://launchpad.net/bugs/1466790
<LocutusOfBorg1> please can anybody sponsor the patch on bug 1297849?
<ubottu> bug 1297849 in network-manager-vpnc (Ubuntu) "[SRU] Virtual private network connection fails after distribution upgrade due to outdated Network Manager configuration files" [High,Triaged] https://launchpad.net/bugs/1297849
<pitti> smb: is this a fresh install? qemu/virtualbox etc? can you please check with "ip a" that there actually is an "eth0"?
<smb> pitti, not fully fresh install but updated regularly. A second with ip a, but ifdown eth0 and ifup eth0 does work and also start the dhcllient
<smb> pitti, So yes there is a eth0 and its KVM VM
<smb> pitti, Also it somehow uses dhcp to get its address initially and is up and working. Just not running the dhclient which then fails to renew the lease
<jamespage> doko, pitti: I've been scratching my head about what todo with junit4 in wily
<jamespage> my only current feasible fix is to re-upload the previous 4.11 release as 4.12 - 4.12 drops ant build support upstream.
<smoser> wgrant, https://bugs.launchpad.net/ubuntu/+source/cloud-utils/+bug/1285197 horay!
<ubottu> Ubuntu bug 1285197 in gdisk (Ubuntu) "growpart failed in ppc64el guest" [High,In progress]
<jamespage> meh - might has a slightly less nasty alternative
<flexiondotorg> Anyone here who could do a little sponsoring for Ubuntu MATE please?
<sladen> slangasek: apologies for the delay in replying
<sladen> slangasek: it's often easier to get people talking by starting with topics that aren't like to be contraversial
<sladen> slangasek: there is an update from mhall119 on the perception at http://irclogs.ubuntu.com/2015/06/18/%23ubuntu-meeting.html#t17:49
<sladen> slangasek:I'm hopeful that it might be something that a personal on the techboard might be able to talk about with passion/enthusiasm/first-hand information
<apostoj> hallyn: thanks for the reply. Sorry for just getting back to this. I'll just describe what I'm seeing and maybe someone can help:
<apostoj> In /etc/network/if-up.d/upstart:37.  The comment in the all_interfaces_up function seems to indicate that a true value will be returned if the interfaces are found to be up...
<apostoj> But the return values look swapped, zero will actually be returned if all are up
<apostoj> This causes "static-network-up" to not be emitted. Boot then hangs until the failsafe Upstart job kicks in.
<smoser> maybe a dumb question.
<smoser> launched a wily instance. did 'apt-get install open-iscsi'.
<smoser> that includes /usr/share/initramfs-tools/hooks/iscsi
<smoser> initramfs did not get updated
<smoser> shouldn't it?
<infinity> smoser: Only if the postinst runs upadte-initramfs.  initramfs-tools doesn't have a watch trigger (though, maybe it should).
<smoser> hm..
<smoser> i guess one way or another .
<infinity> smoser: apw and I have had long discussions about how much initramfs-tools triggering is suboptimal, we're working on improving life.
<infinity> smoser: But yeah, as it stands, anything shipping hooks should be calling update-initramfs -u in postinst.
<ogra_> hmm
<infinity> And postrm.
<ogra_> there useed to be a trigger in the past
<infinity> ogra_: The trigger is on the binary.
<infinity> ogra_: Not on the directories.
<ogra_> ah, k
<ogra_> i just remember i had to suppress it for some arm stuff in the past
<smoser> "on the binary" ?
<infinity> smoser: We trigger on calls to update-initramfs.
<infinity> (And then attempt, poorly, to batch them, so you don't get 7 runs)
<smoser> ah. ok. that makes sense.
<smoser> and yeah, i agree on 'poorly'
<smoser> :)
<ogra_> yeah, ususally you end up with three then or some such :)
<smoser> is that something you're hoping to fix in wily?
<infinity> Well, part of the problem is that the kernel forcefully skips the trigger.
<infinity> But it has to because the trigger is suboptimal.
<smoser> silly kernel
<infinity> We have this all specced out to fix it.
<smoser> link ?
<infinity> <a href=apw.brain#infinity.brain />
<infinity> That implies by brain is a node of Andy's brain, but maybe that's not entirely untrue.
<infinity> s/by/my/
<smoser> hm... infinity.brain: no such file or directory
<smoser> :-)
<infinity> Don't start with me, or we'll have some CoC violations to deal with. ;)
 * infinity shakes his fist.
<smoser> thanks, infinity. i'll file a bug on openiscsi
<infinity> smoser: But yeah, this is something we've dealt with in conversation and rehashed over and over until we're sure we're right, but it was pending a merge and some other bits, and you know how that goes.
<smoser> yeah. do you want me to open a bug for you ?
<smoser> so that you can at some later point fill it in with information ?
<infinity> Nah, we're good.
<infinity> I think Andy might have a bug already somewhere, but if not, we still know it needs fixing.
<smoser> do you *mind* if i open a bug ?
<infinity> You can if you want.
<smoser> just so that at some later point, when someone asks "why did update-initramfs get called 17 times and take 3 minutes?" i can point them at that bug.
<infinity> Sure.
<hallyn> tych0: apostoj it's a shell script, return 0 means true :)
<tych0> hallyn: ?
<hallyn> sorry,
<hallyn> your name wasn't supposed to be there :)
<hallyn> just,
<hallyn> apostoj: it's a shell script, return 0 means true :)
<tych0> although i can use all the help with shell scripting i can get
<hallyn> you're just a golang fanboy and that's that
<infinity> hallyn: Harsh.
<apostoj> hallyn: Ok that makes sense. But line 51 has "if all_interfaces_up ...", so if 0 would evaluate as false, right?
<infinity> apostoj: 0 is always true in POSIX shell, !0 is false.
<apostoj> Oh, I see. Thanks for the help.  :)
<infinity> apostoj: If this confuses you, instead of cursing shell, you can trace this back to C, where "exit(0)" is the "I didn't have an error, yay." way to end a program.
<infinity> apostoj: From there, it follows that shell must treat 0 as good and !0 as bad.
<infinity> (since shell's entire raison d'etra for decades was to execute a bunch of C programs and operate on the returns)
<infinity> s/d'etra/d'etre/
<apostoj> Yes this makes sense now.
<apostoj> Now that I think about it, all shell conditionals I have used were of the form [ -f $x ],  or maybe [ $x == $y ]. I need to work on my shell skills...
<hallyn> (lots of places - like kernel source - also treat 0 as success in c fwiw.  you only need one success value, many error values :)
<smoser> feel free to re-assign infinity https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1466965
<ubottu> Ubuntu bug 1466965 in initramfs-tools (Ubuntu) "update-initramfs runs more often than necessary" [Undecided,New]
<infinity> apostoj: For the record "==" is a bashism, you want "=" up there. :)
<infinity> hallyn: Well, the traditional Cism of "1 is success, everything else isn't" works fine too, except for the confusion between C and shell, since you're off-by-OMG-CONFUSED.
<infinity> hallyn: The whole confusion could have been avoided in 1975 (or so), if they'd just matched 'if', 'return', and 'exit' to all use the same semantics.  But I'm fresh out of flux capacitors.
<infinity> Though, apparently, I'm good on 80s references.
<slangasek> sladen: Mark did raise the question on the TB of whether we would be willing to be a backup "change of venue" in case of a conflict of interest.  It was not represented as individual TB members standing in for individual CC members, as mhall119 says in that IRC log.  In any case, I don't feel that really answers the question I asked by email...
<mhall119> slangasek: I thought that was mark's intention (individualls sitting in for other individuals), perhaps we should ask him for clarification on that point
<hallyn> infinity: very good, the world needs more nostalgia :)
<infinity> mhall119: Sitting in for individuals who choose to recuse themselves makes no sense, IMO.
<infinity> mhall119: Since if one person recuses themselves, you guys can still vote without a standin.
<infinity> mhall119: And, arguably, someone who is self-aware enough to recuse themselves is the least of your problems in a conflict of interest.
<infinity> mhall119: As I read the thread, it was if the CC as a whole (or in large part) has a conflict of interest with the case at hand, another body should be brought in.
<mhall119> infinity: makes sense, I just wanted to make sure that is what Mark had in mind
<infinity> mhall119: I think that's the only way to read his mail, based on him already mentioning that individuals recusing themselves works today, but systemic conflict doesn't.
<infinity> mhall119: I guess one could read that "if 3 people recuse, you need 3 standins", but I think if it's that systemic, you need an outside body, not fill-ins.  YMMV, etc.
<sladen> slangasek: well, the 10 lines above are probably an even more useful result!
<shadeslayer> is there a dh var for figuring out what the build dir is
#ubuntu-devel 2015-06-20
<hjd> Hi, a new version of scala was recently packaged in Debian, along with related new dependencies scala-parser-combinators and scala-xml. Unfortunately these packages have circular dependencies and won't build unless they themselves are available. (search "scala" on http://qa.ubuntuwire.com/ftbfs/ for details). Is there some process or approach for boostrapping such packages?
<hjd> bug 1126035 might be relevant
<ubottu> bug 1126035 in scala (Ubuntu) "Scala 2.10.0 needs packaging" [Wishlist,Triaged] https://launchpad.net/bugs/1126035
<infinity> hjd: Is this a one-time thing, or will it be required for every major version bump or something equally awful?
<infinity> hjd: If it's a one-time thing, I can bootstrap them sometime this weekend and fix it up.  If it's an ongoing concern, you might want to come up with a clever way to iterate bootstrap uploads in the future, since it's entirely possible that Debian will go source-only soon too.
<hjd> infinity: I don't have full overview, but I note that scala version 2.10 and 2.11 both depended on itself.  So maybe the latter...
<infinity> Huh.  It really does build-dep on itself.  Cute.
<hjd> In the bug report, there's a link to an upstream ticket, so people are talking to upstream and trying to make it better (see for instance https://github.com/scala/scala-lang/issues/295)
<infinity> hjd: Commented on the upstream ticket at https://issues.scala-lang.org/browse/SI-9299
<infinity> hjd: I might bootstrap this current version as a show of good faith, but it's definitely not a process I want to have to repeat every 6 months.
<hjd> infinity: Thank you :) That's perfectly understandable.
<ScottK> tumbleweed: It might be kind of interesting to track the total number of uploaders for each release over time in http://people.ubuntuwire.org/~stefanor/ubuntu-activity/ - I assume that's each to get from the data set you're using.
<tumbleweed> ScottK: yeah, probably is quite easy
#ubuntu-devel 2015-06-21
<shadeslayer> xnox: ping
<shadeslayer> xnox: did you have a look at that cmake patch?
<Logan> wgrant: yo, around to field a UDD question?
<wgrant> Logan: Hi
<Logan> hey
<Logan> so there are a ton of packages that failed with 403s
<Logan> do they need requeues?
<wgrant> Damn, someone noticed.
<Logan> :P
<wgrant> I was hoping we could leave it broken and it would slowly fade away into oblivion.
<wgrant> Is it actually useful to you?
<Logan> I sent a message to the list and filed a bug a few days ago
<Logan> UDD is only useful for me in terms of doing merges
<Logan> because I don't like MoM
<Logan> and I prefer a VCS workflow for merging
<Logan> I know Robie posted his git workflow to the list, but it's a bit convoluted
<wgrant> I also prefer a VCS workflow, but I prefer one that works for most packages more :)
<Logan> with MoM, it's not easy to diff against Debian
<Logan> also, it leaves patches in a weird state in my experience
<Logan> for example, I just tried to merge cinnamon using MoM, and it was a mess
<Logan> if you try it, you'll see what I mean
<wgrant> 276.942  Imported [PackageToImport(cinnamon, 2.6.7-2, debian, sid, release, ), PackageToImport(cinnamon, 2.6.7-3, debian, sid, release, ), PackageToImport(cinnamon, 2.6.7-3, debian, stretch, release, ), PackageToImport(cinnamon, 2.6.8-1, debian, sid, release, )]
<wgrant> Logan: Fixed.
<Logan> cheers
<Logan> just 27963 to go ;)
<Logan> if I can get access to the box, I can try fixing up the import failures
<Logan> but as far as I can remember, only Canonical employees can do that
<wgrant> Bazaar-based UDD is on life support. We're not putting effort into fixing it, as it's extremely fragile and simply cannot work for many interesting packages.
<wgrant> We thoroughly discourage its use.
<Logan> and the recommended alternative is MoM for merging?
<Logan> because the packaging guide currently advocated for UDD-based development
<wgrant> Correct.
<wgrant> Yes, the packaging guide is... misguided.
<Logan> is there work on Git-based UDD?
<Logan> if so, can I help?
<wgrant> UDD has never worked reliably for all packages, so it was a somewhat odd choice to default to it in the packaging guide.
<wgrant> We haven't started on Git-based UDD, specifically. But it's something we are investigating.
<Logan> ok
<wgrant> The current vague plan is that we'll improve dgit to meet Ubuntu's needs.
<wgrant> But that's by no means set in stone.
<Logan> also, I'm wondering if you could shed some light on the future of packaging
<wgrant> I'd really like to solve the 3.0 (quilt) problem, but that's Very Hardâ¢.
<Logan> because I'm a bit confused by how DEBs and snappy will go together
<Logan> like, will there still be a role for MOTUs?
<wgrant> Deb-based systems will exist for the forseeable future, but I don't know of any detailed roadmap.
<Logan> and how will we go about merging from Debian and stuff?
<Logan> hmm, alright
<wgrant> For example, developer desktops can't exactly use snappy in the way that a phone does.
<wgrant> And snaps have to be built from something -- in a lot of cases they'll probably be built from debs.
<wgrant> I'm not completely up to date with the latest snappy plans.
<Logan> ok, thanks for shedding some light
<Logan> I wish there would be more communication from Canonical to Ubuntu community devs
<linux_hacker> ,What features do you think Ubuntu 15.10 will have upon release?
<ari-tczew> micahg: ping
<ari-tczew> micahg: I just took a look on merging blueman and noticed that there is obexd 0.47 needed, wich is not at the moment in our archive reachable.
<ari-tczew> Maybe you know already, I was trying to merge obexd more than 1,5 years ago, but without result. More info on bug 1263260.
<ubottu> bug 1263260 in obexd (Ubuntu) "Merge obexd 0.48-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1263260
<ari-tczew> GL & HF.
<sergio-br222> hi
<sergio-br222> I'm trying to understand why there's libqt5opengl5-gles-dev in utopic and up
<sergio-br222> in trusty I was using libqt5opengl5-dev to build ppsspp for ARM, do I need this GLES version on utopic and vivid?
<sergio-br222> debian 8 does not has this package (and others GLES as well), so it's little confuse
<RAOF> sergio-br222: That's a build against GLES rather than desktop GL; if you want to use GLES rather than desktop GL, you'll need to use that one.
<sergio-br222> hum, but why trusty and debian does not have it?
<RAOF> Because they didn't care about GLES? :)
<sergio-br222> but it works
<RAOF> Alternatively, if you don't mind depending on a mesa implementation detail, you can use GLES from the desktop version :)
<sergio-br222> hum, so I can use libqt5opengl5-dev for GLES support, in vivid for example?
<sergio-br222> I came here because I have no idea what to do with these deps, for vivid, in my PPA
<RAOF> Do you use GLES? If so, you should probably be building against the GLES headers (and you won't work reliably work on the desktop, because GLES doesn't work reliably on the desktop).
<sergio-br222> I use GLES, in my odroid U3 board
<RAOF> (Particularly: GLES support from the binary drivers is really new)
<sergio-br222> it uses Mali
<RAOF> Build against the GLES version; that's guaranteed to be not-incorrect ;)
<sergio-br222> ok
<sergio-br222> so I'll need to fork the debian folder to these new ubuntu versions
<RAOF> ...Yeah, probably.
<sergio-br222> but it's weird why ubuntu do this, and debian doesn't
<RAOF> Debian doesn't have to care about GLES-only hardware.
<RAOF> Mostly.
<sergio-br222> wait, these GLES packages, there's only for amd64 and i386 ?
<sergio-br222> http://packages.ubuntu.com/vivid/libqt5opengl5-gles-dev
<RAOF> Hm, wait?
<RAOF> sergio-br222: Ah, right. My mistake, sorry.
<sergio-br222> dunno if this page shows armhf package
<RAOF> sergio-br222: The qt5opengl packages *are* built for GLES on armhf and desktop GL on x86. The problem that the -opengl-gles packages are solving are that the android emulator is (a) x86 and (b) only supports GLES.
<RAOF> sergio-br222: So the *correct* answer is âjust use the opengl5-dev packages, and know that if you care about !armhf you'll need to conditionally use GL/GLES depending on build archâ.
<sergio-br222> not sure if I understood
<RAOF> sergio-br222: We use Qt on the phone, which uses android kernelspace, so we need a build that works in the android emulator, which is x86 but has no desktop GL support. So we need to build Qt twice for x86 - once with desktop GL, once with GLES.
<sergio-br222> ahh
<sergio-br222> so these gles packages are for cross compile?
<RAOF> No; they're for use in the android emulator.
<RAOF> Although I guess you could use them for cross-compile, too, now that you mention it.
#ubuntu-devel 2016-06-20
<pitti> Good morning
<cpaelzer> good morning
<pitti> mvo: good morning!
<pitti> Preparing to unpack .../snap-confine_1.0.30_ppc64el.deb ...
<pitti> Unpacking snap-confine (1.0.30) ...
<pitti> dpkg: error processing archive /var/cache/apt/archives/snap-confine_1.0.30_ppc64el.deb (--unpack):
<pitti>  trying to overwrite '/lib/udev/rules.d/80-snappy-assign.rules', which is also in package ubuntu-core-launcher 1.0.29+1ubuntu1
<pitti> mvo: ^ known?
<pitti> this serial-kills workers during dist-upgrade, I'll see to turning that into a proper failure
<pitti> +Breaks: ubuntu-core-launcher (<< 1.0.29)
<pitti> +Replaces: ubuntu-core-launcher (<< 1.0.29)
<pitti> ^ this isn't enough, must be << 1.0.30
<mvo> pitti: uh, thank you! sorry for this, will fix right away
<pitti> I deployed the autopkgtest fix now, should go from "in progress" to "failed" in the next run
<mvo> ta
<seb128> SRU team, is there any reason the glib/xenial SRU is not copied to updates? it has been marked verification-done at the start of the month and didn't move since ... is that because of the "regression in autopkgtest"?
<seb128> Laney, ^ did you look at those/got pinted about them?
<Laney> no
<Laney> i retried them
<seb128> now or before and they failed again?
<Laney> 4 minutes ago
<seb128> k, let's see if that improves things
<Laney> but nobody told me they don't release it because of this
<seb128> nobody from the SRU team pinged you saying the SRU was on hold because of that?
<seb128> I'm assuming that's why they didn't copy over but I'm not sure
<pitti> presumably that, yes; i. e. needs confirmation that the regressions are unrelated and just because of flakiness; some of them might need overides in xenial
<rbasak> nacc: I already sent it in Debian bug 825079
<ubottu> Debian bug 825079 in icinga2-ido-mysql "Package links against libmysqlclient_r" [Normal,Open] http://bugs.debian.org/825079
<cpaelzer> RAOF: rbasak: as last uploaders I wanted to check with you if it is ok if I start a merge of dovecot  2.2.22 -> 2.2.24 and then look again into bug 1524526 as we discussed
<ubottu> bug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/1524526
<rbasak> cpaelzer: go ahead. Thank you!
<seb128> pitti, thanks for copying the verified SRUs over!
<pitti> no worries!
<cpaelzer> rbasak: I asked via mail a while ago, but I can't even find my own mail so no chance to complain :-) - but could you usd-import dovecot for me?
<rbasak> cpaelzer: I'm trying. I've not actually done an import before but it's about time that I did. Just figuring out getting a working environment.
<cpaelzer> rbasak: any luck with the env to import?
<rbasak> Still on it, sorry.
 * rbasak is installing usd-import dependencies
<cpaelzer> rbasak: not a problem, just needed to check
<cpaelzer> I'm prepping myself by parsing through debdiffs - so I'm ready to go then
<cpaelzer> already found a "changelof only" change :-)
<mdeslaur> chiluk: did you see ted's comment in bug 1592862? could you re-check and see if we can just sync it now?
<ubottu> bug 1592862 in e2fsprogs (Ubuntu) "Merge e2fsprogs from Debian 1.43.1-1" [Wishlist,New] https://launchpad.net/bugs/1592862
<cpaelzer> rbasak: I'd have my prep by debdiff analysis ready - a lot cruft to clean up in that package already - without git helping me to identify more
<cpaelzer> rbasak: I'm going for a bit of soccer with my son which should give you more time to get the import ready - if not when I'm back I'll try to pick something else for the rest of the day
<rbasak> cpaelzer: OK. The import's been going for a while. Now up to Natty.
<rbasak> cpaelzer: dovecot import pushed
<rbasak> nacc: ^^
<rbasak> Hope I did it right!
<cpaelzer> rbasak: thanks a lot for th eimport
<Laney> seb128: it's magically all cleared
<Laney> let's see if it more magically gets copied now
<seb128> Laney, \o/
<cpaelzer> rbasak: nacc: did something on the workflow change dastrically? - I easily able to identify and tag my old/debian, new/debian, old/ubuntu; but when I want to rebase from old/ubuntu to old/debian to start breaking into reconstruct and logical things fail
<cpaelzer> rbasak: maybe the history is broken (or other than I expect) - maybe one of the few algo rewrites is not yet in my mental process
<cpaelzer> rbasak: in the tree you pushed rebasing from ubuntu/yakkety to import/1%2.2.22-1 (which is old/debian) tries to give me the full history into the rebase -i
<rbasak> cpaelzer: use "usd-merge reconstruct old/ubuntu". Not a drastic workflow change but it makes things rebaseable again so the old workflow will still work once that's done.
<cpaelzer> rbasak: thanks
<cpaelzer> rbasak: I should just forget all old I had in mind and follow the new doc at https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow to ensure I'm not on old tracks
<rbasak> cpaelzer: it's very similar. I think "deconstruct" and the need for "usd-merge reconstruct" first are the only major changes.
<chiluk> mdeslaur: will do..
<pitti> Laney: FYI, in case you check: I disabled the autopkgtest workers on cyclops (armhf Calxeda nodes) on purpose
<pitti> Laney: there are now three lxd-armhf[123] arm64 instances on bos01 driven by the autopkgtest-lxd-worker/0 service
<pitti> Laney: last week we found some workarounds how to make bug 1531768 a bit less devastating, so I'd like to see how they are holding up
<ubottu> bug 1531768 in Auto Package Testing "[arm64] lockups some time after booting" [Medium,Triaged] https://launchpad.net/bugs/1531768
<Laney> pitti: okay --- your last post in the bug doesn't sound good though
<Laney> will you bring up arm64 workers if this is good now?
<pitti> Laney: yeah, but at least with nohz=off they seem to survive for hours instead of minutes, and I have the auto-reboot watch dog in place
<pitti> Laney: arm64> this works in principle (I tested it last week)
<pitti> Laney: however, we don't have enough capacity ATM
<pitti> Laney: and I filed an RT about reboot being broken on arm64
<pitti> that's kind of a hard blocker
<pitti> well, I commited some workaround to autopkgtest to do "nova reboot --hard" after 5 minutes timeout, but this is both ugly and also utterly slow
<Laney> heh
<pitti> Laney: but I also want to collect some experience wiht the new lxd runners in general
<Laney> surprised nobody else has pressured for reboot to be fixed
<pitti> Laney: e. g. this morning I noticed that internet access through proxy was broken (fixed now)
<pitti> and there might be some tests that behave differently under lxd than under lxc
<pitti> if that works, I'll ask for opening the firewall between PS and the two s390x nodes, and convert them to the new lxd structure
<pitti> Laney: not sure if you saw the autopkgtest-lxd-worker/0 service box yet; it's fairly similar to the cloud worker box, except that it talks to LXD remotes instead of nova
<pitti> Laney: I just put it onto a new service as autopkgtest-cloud-worker is already fairly loaded with 60 parallel tests
<Laney> pitti: I think I saw this before
<Laney> how are the SS instances themselves managed?
<Laney> cloud-worker starts X and then each one can have Y containers?
<pitti> Laney: the three lxd-armhf* SS  instances are created manually by me, by nova boot'ing with userdata https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/tools/armhf-lxd-slave.userdata
<pitti> Laney: and then adding their IP and number of parallel LXD containers to credentials/lxd-remotes.conf on wendigo
<pitti> Laney: and then juju set autopkgtest-lxd-worker lxd-remotes="$(cat credentials/lxd-remotes.conf)"
 * Laney blinks
<pitti> Laney: this tells the autopkgtest/lxd-worker instance about the new lxd remote, and it'll start running workers on it
<pitti> Laney: (deploy.sh uses this file automatically)
<pitti> Laney: I'll wikify all this soon, once it proves itself in production
<pitti> and I'm sure we can automate this some more
<pitti> Laney: blinks> what's unclear? happy to explain (I don't like bus factor == 1..)
<Laney> pitti: Initially all of the configuration in that file - seems painstakingly worked out, and then the list of stpes that I'm not sure I'd get right. :)
<Laney> wiki will help
<pitti> Laney: yeah, the userdata file is a horrible collection of bug workarounds and lots of black magic to create a btrfs partition
<pitti> Laney: we don't have cinder on scalingstack, so no volume-create and friends
<LocutusOfBorg> dpkg: error processing archive /var/cache/apt/archives/snap-confine_1.0.30_amd64.deb (--unpack):
<LocutusOfBorg>  trying to overwrite '/lib/udev/rules.d/80-snappy-assign.rules', which is also in package ubuntu-core-launcher 1.0.29+1
<LocutusOfBorg> wow
<pitti> LocutusOfBorg: told mvo this morning, the Breaks/Replaces: has the wrong version
<LocutusOfBorg> thanks
<LocutusOfBorg> from time to time I upgrade my yakkety machine :)
<pitti> LocutusOfBorg: err, you have -proposed enabled?
<LocutusOfBorg> yes
<pitti> *shrug*, you get to keep both halves
<pitti> seriously, never EVAR do this
<LocutusOfBorg> pitti, virtual machine
<LocutusOfBorg> I'm not *that* crazy
<LocutusOfBorg> :)
<mvo> hehehe
<mvo> thanks, another reminder to fix this silly bug
<LocutusOfBorg> sorry for the dup :)
<mvo> no worries
<coreycb> arges, mind rejecting my dh-python upload to wily?  it has some cruft in it.
<pitti> coreycb: done
<pitti> arges: ^
<coreycb> pitti, thanks
<nacc> cpaelzer: ack, that's the major change; it has to, if you care, with the fact that all imports are now git-merge commits. git-rebase will try to replay the merges, which won't work. So we first have to break the git-tree into a 'reconstruct' tree that is a sequence of linear commits with only one parent.
<nacc> rbasak: ack, thanks!
<nacc> can someone re-trigger the autopkgtests for phpseclib -> php-horde-mapi (new version has landed in yakkety)
<pitti> nacc: doing
<nacc> pitti: thanks!
<nacc> pitti: i think almost all of php has cleared out of excuses now :)
<cpaelzer> nacc: yeah thanks for the extra explanations
<cpaelzer> nacc: worked fine after I adde the two new stages
<cpaelzer> nacc: I'm just starting to build my newly merged package
<nacc> cpaelzer: great! sorry for that confusion
<cpaelzer> nacc: you are totally innocent for me starting as I did before instead of re-reading the new doc :-)
<cpaelzer> s/innocent/unblamable/
<nacc> cpaelzer: i hope that's mentioned on the new doc, and if not, i'll go fix that now :)
<cpaelzer> nacc: it is there, working fine
<nacc> cpaelzer: ok, good :)
<cpaelzer> nacc: what is missing thou and I wanted to discuss that - is that if just following the doc you get missing references
<cpaelzer> nacc: after the clone at the step of usd-merge tag
<cpaelzer> nacc: as soon as you check out or at least fetch those you are good and usd-merge wrks fine
<nacc> cpaelzer: ah, that's true, there is aw orkaround
<nacc> let's say you named your remote usdi
<cpaelzer> nacc: something for that would be nice to be added to the doc
<nacc> then you can do `usd-merge tag usdi/ubuntu/yakkety usdi/debian/sid`
<nacc> and it will dtrt
<nacc> but yes, i'll clarify that! i wrote it from the persepctive of i have the imported trees locally that i'm pushing :)
<cpaelzer> nacc: true, I don't mind what way gets added to the doc, also I expect most to find a way around like me - but "something" in the doc would surely be nice
<nacc> cpaelzer: yep, fixing now
<cpaelzer> nacc: also I tihnk section 7 mght be incomplete subject is "Tag, push and review.", but there is no tagging involved :-)
<cpaelzer> nacc: in the long past we called that thing to be tagged archive/version, but I'm sure you have something new matching the remaining tests in a better way
<cpaelzer> nacc: maybe just new/ubuntu ?
<cpaelzer> until we know it is accepted and uploaded we can't really give it a version tag - that was the discussion back then
<nacc> cpaelzer: yep, that's the discussion rbasak and i are still going through
<nacc> cpaelzer: but from a MR perspective, that's ok
<nacc> cpaelzer: just don't tag (just checkout -b merge or whatever) and push your branch
<rbasak> Which tag are you talking about?
<nacc> reviewer reviews the branch, and if uploader, they'll tag
<nacc> rbasak: i think the 'proposed' new version
<nacc> rbasak: as a result of the merge
<nacc> proposed strictly from the submitter's perspective, not the archive
<rbasak> ATM that appears as the MP's proposed branch, right? So no need to tag, but do need a branch name.
<rbasak> In the past, we didn't technically need a branch.
<cpaelzer> nacc: I'm fine with a brnach only, just drop the "tag" from the subject in section 7
<rbasak> Though "new/ubuntu" is handy.
<rbasak> But that'll move upon addressing review comments, so maybe we should stop using it and focus on a branch tip instead.
<cpaelzer> nacc: and if you rewrite section 7 you might add to push tags as well, otherwise we don't have to discuss how to name them :-)
<cpaelzer> no matter if we follow the branch (which is nice as it moves) or add a tag, uploading tags will surely help for logical/reconstruct and such tags
<nacc> cpaelzer: updated, take a look?
<nacc> cpaelzer: yep, i forgot to include the tags to push as well, you're right, fixed now
<cpaelzer> nacc: a bit wide, but yeah good now
<nacc> cpaelzer: yeah, i'll figure that out :)
<cpaelzer> nacc: not to say that 99% of screens on the world would have enough screen-estate to jsut display it wide :-/
<nacc> cpaelzer: now it's a little scrolly box :)
<cpaelzer> nacc: it losts its index as #2 by that
<cpaelzer> nacc: I'd vote for \ and indented follow up line
<nacc> cpaelzer: check now?
<cpaelzer> nacc: I don't want to be a pixel mover, but since we are at it anyway - the distance between "git push" and the line above is too small and the distance to the following line is too huge
<cpaelzer> nacc: but feel free to just keep it as-is - it  is good
<nacc> doko: question on openjdk-9-jdk (two questions, actually). 1) openjdk-9-jdk is uninstallable in 16.04 because it and openjdk-9-jdk-headless provide the same file (and -jdk depends on -jdk-headless). 2) openjdk-9-{jdk,jre} provide {java*-sdk,java*-runtime}, which causes some dependency issues (LP: #1584118). Any ideas on what the right way to resolve those are?
<ubottu> Launchpad bug 1584118 in openjdk-9 (Ubuntu) "16.04 incorrectly installs openjdk-9 to satisfy java8-runtime dependency" [Undecided,Confirmed] https://launchpad.net/bugs/1584118
<nacc> cpaelzer: it is a wiki :-P
<nacc> cpaelzer: i don't know why the wiki formats that way, but it's not something i'm specifying, fwiw
<sil2100> cyphermox, BenC, rbasak: hey guys! I won't be able to make it for todays meeting sadly
<nacc> slangasek: could you take a look at LP: #1592890? it will clear out two more excuses entries (php7cc and php-pimple itself)
<ubottu> Launchpad bug 1592890 in php-pimple (Ubuntu) "Fix autopkgtest failure for php-pimple" [Undecided,New] https://launchpad.net/bugs/1592890
<nacc> slangasek: i've already sent the same patch to Debian, if you want to just wait for that to get accepted and sync
<nacc> mdeslaur: you added a patch to php-horde-http during 16.04 which turned a non-fqdn into a fqdn in a test case. But afaict, the test passes w/ or w/o it (and it's not in Debian still). There is no bug report linked, so I'm not sure if you know specifically why/if it's needed?
<nacc> jbicha: thanks for the advice and pointers on the zend{,-}framework stuff!
<nacc> let's say i'm providing a fix for a package which has received a security update, but my fix is not itself a security update. The current version of the package is 7.0.4-7ubuntu2.1. Would my package be versioned 7.0.4-7ubuntu2.2 or 7.0.4-7ubuntu3 ?
<nacc> I guess not the latter, only in case there was a 7.0.4-7ubuntu3 published in the development release that it might conflict with?
<mdeslaur> nacc: it was failing it's autopkgtest
<mdeslaur> nacc: feel free to drop it if the autopkg test now works without it
<jbicha> nacc: using the version numbering recommended on https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation is a good standard regardless of whether the sru is "security" or not
<jbicha> 2.2 is fine
<nacc> jbicha: ack, thanks!
<jbicha> I think there's a little bit of flexibility as long as the number is less than it could be in a future release
<nacc> mdeslaur: ok, i'll double-check again and request a sync if it works
<nacc> jbicha: ack, that makes sense
<jbicha> for instance I gave my https://launchpad.net/ubuntu/+source/abiword SRU 3.0.1-6ubuntu0.16.04.1
<jbicha> but strictly following the rules I think it should have been 3.0.1-6ubuntu0.1
<nacc> yep, i think i was just clarifying on if those rules applied to non-security updates and then how strictly they were followed :)
#ubuntu-devel 2016-06-21
<cpaelzer_> good morning
<pitti> Good morning
<pitti> +gnome-software (3.20.1+git20160617.1.0440874.ubuntu-xenial-0ubuntu1~16.04.1)
<pitti> Laney: ^ triggering buffer overflows in dpkg and apt? :-)
<didrocks> and then, people complained about CI train versionning scheme! :-)
<pitti> Laney: rejecting your ubuntu-themes xenial SRU, it doesn't have an SRU bug
<rbasak> pitti: mysql-5.7 dep8 is failing on ppc64el on both xenial and yakkety due to a latent bug. Has something changed in the way tests on ppc64el are run - such as parallelism?
<rbasak> pitti: Skuggen has kindly provided http://bugs.mysql.com/bug.php?id=81923 upstream, but that is a while from being fixed. Would it be acceptable to ignore the test positive as it is not a regression over Xenial?
<rbasak> (it's blocking progress for us right now and we don't have a fix; apparently it's a race)
<rbasak> Or should we disable the affected tests?
<rbasak> mwhudson: with bug 1591021, I'd go as far as Won't Fix. We've tried to fix things up in the past and maintaining that delta was more painful than it was worth. If upstream aren't interested in fixing it, that's Won't Fix for us.
<ubottu> bug 1591021 in docker.io (Ubuntu) "upgrading docker does not restart daemon" [Wishlist,Triaged] https://launchpad.net/bugs/1591021
<rbasak> Otherwise there's the implication that the bug could make progress and/or that we'd take a patch, which isn't true.
<mwhudson> rbasak: fair enough
<Laney> pitti: ffs, the train is supposed to add that
<seb128> Laney, did you commit --fixes lp:<nnn> or have the bug linked to the merge request?
<Laney> don't know
<Laney> don't worry seb128, I can manage fixing it :)
<seb128> yeah
<seb128> it might be a train regression, please let them know if you had one of those and it failed to create the correct changelog
<pitti> rbasak: sorry, was OTP; no, there were no recent changes from my side
<pitti> rbasak: but it could certainly be that some underlying library or hte kernel or whatnot changed
<pitti> rbasak: http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/yakkety/ppc64el/ doesn't look new, though, it has always been fairly flaky
<pitti> rbasak: and http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/xenial/ppc64el/ didn't regress, it's alwaysfail
<rbasak> pitti: it seems to consistently fail now, but I'm told the bug existed from the start of 5.7, and we didn't hit the issue in Xenial.
<pitti> (like on http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mysql-5.7)
<rbasak> pitti: though if you look at the actual failure log, you'll see that it is intermittent - but since there are a number of tests affected, at least one of them tends to fail.
<pitti> yeah, the latest xenial run is something different
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mysql-5.7 is just marked red because of the ruby-mysql2 regressino
 * pitti retries that
<rbasak> They're all different.
<rbasak> The problem is that there are some essential fixes I want to land in Xenial after some testing in Yakkety.
<rbasak> But this is blocking those.
<pitti> # very flaky
<pitti> force-badtest mysql-5.7/5.7.12-0ubuntu2/ppc64el
<pitti> hah
<pitti> so this just needs to be bumped
<rbasak> Oh
<rbasak> I didn't know that was there!
<pitti> done
<rbasak> We think it could all be http://bugs.mysql.com/bug.php?id=81923 so add that as a comment if you like?
<rbasak> Thanks!
<Skuggen> \o/
<pitti> feel free to hit retry on http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mysql-5.7 again if the currently running one fails again
<Skuggen> We're pretty sure this problem has been there for all of 5.7, so was a bit odd that the tests are failing more often now
<rbasak> Will do, thanks.
<rbasak> Skuggen: looks like the failure was being ignored before (due to being flaky)
<Skuggen> Ah, maybe it used to be "Always failed", but then a fully green build passed through?
<Skuggen> I seem to remember two platforms listed as "Always failed" for 5.7
<pitti> yeah, it happened to succeed four times
<rbasak> Skuggen: I filed bug 1594716 so we leave a trail for anyone hitting this.
<ubottu> bug 1594716 in mysql-5.7 (Ubuntu) "InnoDB: Failing assertion: it != chunk_map->end()" [Medium,Triaged] https://launchpad.net/bugs/1594716
<Skuggen> Bug: Random test successes
<caribou> pitti: any reason why https://cloud-images.ubuntu.com/yakkety/current/yakkety-server-cloudimg-amd64-disk1.img doesn't exist ?
<pitti> caribou: the -disk1 suffix was dropped
<caribou> pitti: any relation to your new autopkgtest 4.0 release ?
<caribou> pitti: which means that one cannot run yakkety dep8 tests on Xenial...
<rbasak> "Inconsistency for the sake of consistency", as smoser put it.
<pitti> caribou: this was already fixed in 3.20.7
<pitti> caribou: install the version from xenial-backports
<caribou> pitti: ah, ok : apt-get update && apt-get -y dist-upgrade
<caribou> pitti: yeah, backport is better
<caribou> pitti: thanks!
<Odd_Bloke> rbasak: caribou: pitti: The .img in yakkety is intended to boot in both UEFI and traditional manners; it is actually different to what the -disk1 image was. :)
<juliank> mvo: Could you leave some endorsement on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU please?
<juliank> pitti: you probably do not recall any upload you sponsored (I see two ndiswrapper ones from 2008 and 2014) and could add something?
<juliank> and infinity wanted to write something too...
 * juliank hates bureaucracy
<mvo> juliank: happy to do that
<mvo> juliank: more than happy
<pitti> juliank: indeed only these two: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Martin+Pitt&sponsor_search=name&sponsoree=Julian+Andres+Klode&sponsoree_search=name
<pitti> which was a simple sync
<pitti> juliank: I'll add a recommendation, though!
<juliank> pitti: syncs are mostly what I do :D
<pitti> good thing :)
<juliank> That's what I want the PPU for, to get rid of the sponsorship step for the syncs
<juliank> Mostly I work around the normal procedure a bit and just ask someone like mvo or infinity to sync something - that's way quicker than filing a sync request in lp ... - but it does not get the same "publicity"
<mvo> juliank: let me know if I should expand it more
<juliank> mvo: it's great
<xnox> mvo, juliank, recommended for Ubuntu Core Dev
<juliank> xnox: Well, we can do that too...
<juliank> (but that's a PPU applications)
<xnox> juliank, i went from "contributing member" -> core-dev in one step.
<xnox> juliank, yes, but in practice mark said "any debian developer is ubuntu developer" thus you should have effective PPU anyway, and you are good enough for coredev =) no need to reapply for everypackage. and you can and know how to fix stuff.
<juliank> Oh, there is a less formal procedure for adding/removing packages for Debian developers.
<juliank> But I can also go the core dev road, if that's OK with everyone
<juliank> That is, if you think I'm OK for that, I'd prefer that
<juliank> xnox: I just wanted to play safer this time, a few years ago, I applied for MOTU and was rejected. :/
<xnox> bah, silly DMB members
<caribou> pitti: any reason why dep8 tests would run then adt-run would report that there were no test ? http://pastebin.ubuntu.com/17636513/
<xnox> juliank, i was on DMB for a little while, but i'm not any more =(
<pitti> caribou: that looks like a bug indeed; what's the exit code?
<caribou> pitti: 8 as expected
<pitti> well, 0 or 2 would be expected
<caribou> pitti: I'm running the latest in xenial-backports
<pitti> as there *are* tests
<rbasak> May I have a review of https://github.com/ltangvald/mysql-5.7/commit/fa6ea034692 from an experienced dev please? The mechanics are simple but I want to make sure the approach is correct (seddery of conffile)
<caribou> pitti: yes, but since it reports SKIP, then 8 is to be expected
<caribou> pitti: I'll retest on Yakkety & let you know
<pitti> caribou: right, please file a bug about it with the full command line
<caribou> pitti: sure
<juliank> xnox: well, I'd be happy with core-dev membership. The MOTU thing was way back before 2010 even, I think. Kind of depends what mvo and infinity think, as those two are the ones I worked most with longterm/recently. I gtg to university in a few minutes, but will be back in about 20 minutes.
<juliank> You're not the first to suggest this
<juliank> IIRC
<juliank> Someone suggested the same when I applied for bug control...
<xnox> !dmb-ping please give juliank core-dev, based on the fact that he is a dd, and lands apt into ubuntu, properly.
<ubottu> xnox: I am only a bot, please don't think I'm intelligent :)
<xnox> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<xnox> ^^
<mwhudson> argh
<sil2100> uh oh!
<mwhudson> can someone delete https://launchpad.net/ubuntu/+source/golang-defaults/2:1.6.1+1ubuntu2~ppa1 ?
<xnox> mwhudson, added "block-proposed" tag on https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1508122
<ubottu> Launchpad bug 1508122 in dh-golang (Ubuntu) "please transition to shared libraries" [High,In progress]
<juliank> xnox: If I miss anything in the next twenty minutes, let me know when I rejoin
<mwhudson> xnox: it's in NEW, luckily
<xnox> mwhudson, and affects golang-defaults
<mwhudson> but yes, thanks!
<xnox> mwhudson, well it's in proposed already, and "block-proposed" is the mere-mortal accessible emergency stop handle =)
<Trevinho> bdmurray: as for these regression mails... It seems I'm not getting them anymore, but I think the update can be fired to everyone. These are not related to SRU.
<xnox> mwhudson, usually ask for package removals like that on #ubuntu-release
<xnox> mwhudson, people with powers monitor that.
<mwhudson> ah good point
<rbasak> xnox: how does not giving juliank core dev hinder progress? I think I'm settling that as a general criteron now.
<rbasak> (while also slowly forgetting how to spell and otherwise construct sentences)
<xnox> rbasak, the fact that foundations doesn't have an active apt maintainer, and juliank has been effectively maintaing apt in ubuntu, for ubuntu specific stuff for a while now =)
<rbasak> xnox: so that's an excellent reason to give juliank apt PPU.
<xnox> rbasak, the list of PPU packages he requests are fine. However, he also finds things and fixes bugs in other dependant packages, and is capable of being an effective core dev =)
 * xnox wants juliank as a core dev, cause he would be a good core dev =)
<rbasak> The first part of that reason is a good reason. The second part is a good endorsement but not in itself a reason :)
<rbasak> Please put your reasons in your endorsement ;)
<juliank> xnox: I'm back!
<juliank> xnox: Nice excerpt in the wiki
<sil2100> ;)
<juliank> I must say that xnox is very enthusiastic about this whole thing
<juliank> I like that.
<rbasak> juliank: so I was saying while you were out. I'm new on the DMB. But I'm slowly settling on wanting a reason for people to have particular upload access. For core dev, often that's "I keep needing sponsorship and that slows down my work", for example.
<rbasak> That is: I'm more likely to +1 a request if not doing so will hinder someone somehow, and so I'd like that explained.
<rbasak> Since anyone uploading to Ubuntu is doing us all a favour, and I want to "get out of the way".
<juliank> rbasak: Yes, isn't that the reason for everyone? I listed "so I can sync new bugfix releases when needed." - I can expand on that obviously
<rbasak> juliank: right, but apt (and apt-related packages) PPU would suffice for that.
<rbasak> juliank: it does seem to me that apt (and related) PPU is a no-brainer for you BTW.
<juliank> Yes, for the APT stuff, it probably would. The other packages are unrelated to APT, but also need syncing in import freeze times to get new bug fixes in
<juliank> Apart from the technical component, there's also the social component with core-dev.
<juliank> Also, it could easily happen that I NMU a debian package for some RC bug and then want to sync that during freeze and stuff like that
<rbasak> Yes, there is. I'm aware of that being documented, though AIUI there's quite a high bar for that. I've not seen it done before, and as a DMB newcomer, I'm less confident around that.
<rbasak> Before I was an uploader, I found that people were more willing to sponsor things for me as time went on, because they knew that it was likely to be right and not take much time.
<rbasak> And they checked less and less.
<juliank> I really only do syncs these days, I don't think there's a whole lot of checking going on when someone sponsors them...
<juliank> It's like: Hey I need this synced, and 3 minutes later I hear done
<cjwatson> I find it difficult to imagine somebody who's suitable for apt PPU who wouldn't also be suitable for core-dev.
<cjwatson> (FWIW)
<rbasak> If you have needed sponsorship for a bunch of syncs in random packages, that's also a good reason I think.
<juliank> cjwatson: With apt PPU rights I can basically do just as much damage as with core-dev permissions..
<rbasak> Well, technically you're root in a user's postinst with any upload :)
<pitti> the threat of "any package you touch will belong to you for a long time" should be high enough,  too :)
<cjwatson> juliank: Quite.
<rbasak> cjwatson: I appreciate your opinion, thanks. Forgive me for being cautious. I'm new to this ;)
<pitti> rbasak: FWIW, you got elected on the board because people trust your opinion, so don't apologize :)
<rbasak> pitti: thanks :)  But still, subjective decisions are hard to make, and there will always be someone who falls on the wrong side of one and suffers undue hassle. So I'm still happy to apologise for that.
<caribou> pitti: FYI the SKIP autopkgtest report was not a bug but my misuse of the adt-run command
<caribou> pitti: was running adt-run makedumpfile --unbuilt-tree . and there is no DEP8 tests in the package in the archive
<pitti> caribou: oh, you are running *two* tests here
<caribou> pitti: yep, just found out :
<caribou> :)
<pitti> caribou: that's the confusing scenario that autopkgtest 4.0 fixes :)
<pitti> well, "fixes" â "does not allow any more"
<caribou> pitti: I prefer the new syntax better
<LocutusOfBorg> does anybody know where I can find mirv?
<mitya57> LocutusOfBorg, try /query'ing him, he's here on freenode
<LocutusOfBorg> yep, I did that, even if I prefer a public discussion
<LocutusOfBorg> well, the public discussion is now on #ubuntu-x FWIW
<LocutusOfBorg> qtbase-opensource-src is broken on arm64
<LocutusOfBorg> a transition is needed because gles has been enabled there
<LocutusOfBorg> I found it while rebuilding calibre on arm64, failing because of missing symbols (rebuilding pyqt5 is helping)
<mitya57> OK. FWIW you can also ask me about Qt related questions :)
<LocutusOfBorg> mitya57, https://irclogs.ubuntu.com/2016/06/21/%23ubuntu-x.html
<LocutusOfBorg> can you please take care of it then? :)
<mdeslaur> infinity: I'd appreciate your thoughts on the best way to address bug 1584485
<ubottu> bug 1584485 in samba (Ubuntu) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
<mdeslaur> infinity: that approach doesn't look sane to me, do you have any suggestions for something better?
 * mitya57 is back and looks
<mitya57> LocutusOfBorg, I can rebuild pyqt5 and calibre. Will it solve your problem? :)
<LocutusOfBorg> mitya57, I'm doing that
<LocutusOfBorg> the problem is: does anything else needs a rebuild?
<mitya57> LocutusOfBorg, I suppose anything build-depending on libqt5opengl5-dev may need a rebuild.
<mitya57> But I assume Timo is/was intending to take care about most of that himself.
<mitya57> I.e. he filed bug #1586026 for packages that don't build with the new version.
<ubottu> bug 1586026 in vite (Ubuntu) "Remove arm64 binaries for packages failing to build with Qt compiled with OpenGL ES" [Undecided,New] https://launchpad.net/bugs/1586026
<LocutusOfBorg> thanks mitya57
<LocutusOfBorg> following up there
<mitya57> FWIW there was also a thread on ubuntu-devel about this
<coreycb> pitti, hi, I commented on bug 1586900 if you can take a look please
<ubottu> bug 1586900 in python-keystoneauth1 (Ubuntu Xenial) "[SRU] keystoneauth1 2.4.1 for Xenial/Mitaka" [Medium,Triaged] https://launchpad.net/bugs/1586900
<pitti> coreycb: yes, but they were added to the binary deps too
<coreycb> pitti, only python-requests-kerberos was added to the binary Suggests
<pitti> ah, these are *all* Suggests?
<pitti> sorry then, I missed that
<coreycb> pitti, the only d/control changes from 2.4.0 to 2.4.1 is additions to Build-Depends-Indep
<coreycb> pitti, I can upload that again if you agree. thanks for reviewing btw.
<pitti> coreycb: that would be good, sorry for the trouble
<coreycb> pitti, np :)
<rbasak> May I have a review of https://github.com/ltangvald/mysql-5.7/commit/fa6ea034692 from an experienced dev please? The mechanics are simple but I want to make sure the approach is correct (seddery of conffile)
<pitti> rbasak: nitpick: I'd add a '^ *' at the front of the regexp, or at least a \b, to ensure that you aren't catching a partial word
<pitti> like some otherthing_key_buffer
<infinity> mdeslaur: The proposed fix is certainly not reasonable.  I'll ponder the problem over breakfast.
<infinity> mdeslaur: Is it a question of ABI breaks, or ABI additions?  It seems the real issue is bad dependencies between libnss-winbind and its deps.
<rbasak> pitti: good point, thanks. Is the general principle of handling it OK? Backup file left if changed with sed's --in-place option, dropping the backup if sed left the file unchanged, guarded by version comparison for upgrade only, etc - is there anything else we should be doing that we've missed?
<infinity> Oh, because samba-libs is a big blob os libraries that shouldn't be packaged together.
<infinity> Whee.
<pitti> rbasak: seems good enough to me
<rbasak> Great. Thank you for the review! I didn't want to do this badly since fixing it later would be painful :-/
<rbasak> Skuggen: ^
<mdeslaur> infinity: if the abi changes, running processes die because they're running with the old version of libnss-winbind
<mdeslaur> infinity: I guess abi additions should be fine, but I'm not sure how careful samba preserves abi between versions
<infinity> mdeslaur: Running processes should be fine, it's new processes that explode miserably.  (Well, or running processes calling into NSS anew, but that's still "new", from my POV)
<infinity> mdeslaur: But yeah, the problem is clearly a lack of sane ABI versioning on "samba-libs" and, thus, incorrectly weak deps between libnss-winbind and samba-libs.
<infinity> mdeslaur: Doesn't look like something one can properly fix in an SRU, since the fix is to actually version the *#^)! libraries correctly.
<mdeslaur> oh, right, new processes in that specific case
<infinity> mdeslaur: But having samba-libs Break libnss-winbind << Binary-Version, and disable/reenable winbind on preinst/postinst would "work".  Though, gross.
<mdeslaur> I thought I saw a bug where existing processes were crashing because of an incompatibility with a newer winbind service
<infinity> Existing processes will also explode if they call into NSS fresh, NSS is effectively a dlopen().
<infinity> But yeah, I consider dlopen "new processes" from the POV of hunting library ABI issues. :P
<infinity> Otherwise my head hurts.
<mdeslaur> hehe
<infinity> Anyhow, any solution that halts upgrade with "we notice you have packages installed and you're actually using them correctly; please stop using them" is not sane.
<infinity> If it can be automated to disable/reenable, that's vaguely okay, though if their setup relies on winbind resolution working, there's a gap there where the world sucks.
<infinity> But better that than crashing, I suppose.
 * infinity -> breakfast run.
<mdeslaur> infinity: but what happens when an existing process is running with an old libnss-winbind, and the windbind package gets upgraded to a version that is not compatible with the old libnss-winbind?
<mdeslaur> perhaps that's not a problematic scenario
<infinity> mdeslaur: After taking a walk, it occurs to me that in the absence of proper library versioning, the more robust solution might just be for nss-winbind and pam-winbind to be statically linked to samba-libs.
<infinity> mdeslaur: That would eliminate the problem, and have the added bonus of not having to pull in a massive samba-libs package just for the small bits that the nss/pam plugins need.
<mdeslaur> hrm, that does sound reasonable
<mdeslaur> infinity: please add your infinite widsom to the bug?
<infinity> mdeslaur: I have a face full of breakfast.  Feel free to copy and paste. ;)
<mdeslaur> ack
<mdeslaur> infinity: thanks for your input
<nacc> rbasak: thanks for the various MR reviews, will respond shortly
<tinoco> mdeslaur: infinity: should i work on the statically linked pam-winbind version debdiff ?
<tinoco> totally agree on being a better solution
<infinity> tinoco: pam-winbind and nss-winbind.
<mdeslaur> tinoco: perhaps file a debian bug also?
<tinoco> definitely. the proposal was to bring the discussion only
<infinity> tinoco: Only statically linked to samba-libs, of course.  You still want to be dynamically linked to any properly-versioned system libs (like libc).
<tinoco> i wasn't supper happy about the approach either
<tinoco> infinity: definitely. gotcha
<tinoco> i'll work on it and provide a new sru suggestion
<tinoco> tks!
<infinity> tinoco: But yes, in the absence of properly-versioned samba libs, I don't see a better solution.
<tinoco> infinity: yep, me neither. there would be always a time window for things to go bad
<infinity> tinoco: The best solution would be for upstream to properly version all those little libs in samba-libs, and then break them out into individual packages.
<infinity> tinoco: But I don't see that happening any time soon, if ever.
<tinoco> ok. i'll document this for future reference (if they ever go that way)
<tinoco> and will fix it on debian also
<tinoco> tks infinity
<infinity> tinoco: The "disable in samba-libs preinst, reenable in samba-libs postinst" approach would also work, but it's (a) potentially very brittle, and (b) likely next to impossible to do for pam-winbind (which probably suffers the same issue as nss-winbind).
<tinoco> infinity: my hope was that pam-auth-update (or any other mean) could remove/re-add winbind to nsswitch
<tinoco> but then.. if customer had a taylor made change of nsswitch.conf.. it would be no good
<tinoco> other choice would be to remove.. but then, if user doing the installation was coming from NSS
<tinoco> things would go bad also
<infinity> tinoco: Right, nsswitch isn't too hard, but /etc/pam.d/* is an order of magnitude worse.
<tinoco> just like you said before
<tinoco> infinity: definitely
<tinoco> i think statically compiling it for now is the best approach
<tinoco> only way without dealing with infinitive possibilities coming from pam.d/nss
<nacc> jbicha: re: php-horde-http (LP: #1594618), at least one of the two test failures in Ubuntu are skips in Debian; trying to figure out why
<ubottu> Launchpad bug 1594618 in php-horde-http (Ubuntu) "Sync php-horde-http 2.1.6-3 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1594618
<infinity> nacc: Differences in name resolution, perhaps?  (blind guess without looking at the failures)
<nacc> infinity: yeah, i think that must be it (and why mdeslaur had patched the old version). But the older version was also failing :)
<infinity> nacc: Debian buildds can generally resolve the world, even if they can't reach it.  Ubuntu buildds have a restricted bind view that won't even resolve outside names.
<nacc> infinity: is it possible for me to reproduce exactly the env that it's used for autopkgtest?
<infinity> nacc: Oh.  This is autopkgtest, not buildds?
<infinity> nacc: In that case, ignore my above comment.  Out autopkgtest infra can resolve everything.
<nacc> infinity: ok :)
<infinity> nacc: Though, given mdeslaur's patch, it's possible the autopkgtest infra has a * entry for the base domain, which would be silly...
<infinity> nacc: But this is what example.com is for.  doesnotexist.example.com would be a sane default for that test.
<nacc> infinity: yep, agreed, it's just not obvious what exactly is failing from the current output :)
<infinity> nacc: Indeed.  And even with the patch in play, those same two tests were failing before.
<infinity> So, hrm.
<nacc> infinity: yeah, it's confusing :) I am wondering if it's actually a deps issue; i'm going to see if we can sync a few of the pecl http packages and see if that fixes things
<infinity> nacc: Those tests have been flaky forever, it seems.  I'm more confused about why they passed.  Exactly once.
<nacc> infinity: agreed, it seems like that's really an outlier/fluke and we actually didn't fix anything :)
<nacc> infinity: heh, that test passed, because we skipped the two failures
<nacc> infinity: probably because php-curl was uninstallable transiently or something
<nacc> infinity: same for peclhttp2 -- so was a false positive, of sorts (although matching Debian)
<mdeslaur> stgraber, infinity, kees, slangasek: tech board?
<nacc> infinity: hrm, strange! running locally, i get 'Assertions: 22, Skipped: 15'
<infinity> mdeslaur: Wha... Did someone delete it from the calendar?
<mdeslaur> which calendar is it supposed to be in?
<infinity> mdeslaur: It was on the Fridge calendar, and we all had invites.  Seems it's been removed.  Grr.
<mdeslaur> crap, I hope I didn't do that
<infinity> mdeslaur: Is it likely that you might have? :P
<mdeslaur> my thunderbird plugin went on a rampage a couple of weeks ago and killed a bunch of stuff
<infinity> Oh my.
<mdeslaur> but, hopefully I didn't have rights on that one
<stgraber> oh, didn't get a notification for some reason
<stgraber> well ^ may be the reason :)
<mdeslaur> crud
<mdeslaur> if it was me, sorry about that
<infinity>    * linux: Implement secure boot state variables (LP: #1593075)
<ubottu> Launchpad bug 1593075 in linux (Ubuntu) "linux: Implement secure boot state variables" [Medium,Triaged] https://launchpad.net/bugs/1593075
<infinity>      - SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl
<infinity> cyphermox: ^
<infinity> cyphermox: That should have landed in -proposed, if you want to double-check that userspace matches.
<cyphermox> xenial you mean?
<infinity> cyphermox: yakkety would be a good start.
<cyphermox> I uploaded shim-signed 1.15 for that
<infinity> cyphermox: Ahh, shiny.  Then I'll validate the combination myself later and get back to you. :)
<cyphermox> cool
<cyphermox> I'm looking at precise and trusty atm; the stuff that was already in proposed
<slangasek> mdeslaur: tech board > hmm why is it not on my calendar?
<mdeslaur> slangasek: it got removed by mistake, possibly by me
<slangasek> ah doh
<mdeslaur> slangasek: infinity is adding it back
<capum321> hello
<capum321>  I am trying to compile mono-addins package as dependency to build a monodevelop 6.0 which doesn't exist in repositories. get this error http://dpaste.com/2PBR989 - - - the package is https://launchpad.net/ubuntu/+source/mono-addins/1.0+git20130406.adcd75b-3 ->  mono-addins_1.0+git20130406.adcd75b-3.debian.tar.gz
<nacc> capum321: an unaltered source package?
<capum321> hello
<capum321> nacc:
<capum321> are you there?
<capum321> dan
<nacc> capum321: hello
<nacc> jbicha: hey, just tried to reply to you and gnome mail said 'mail forwarding loop' and rejected it?
#ubuntu-devel 2016-06-22
<capum321> nacc sorry , i am back
<capum321> nacc what do you mean by that?
<nacc> capum321: you're rebuilding the existing binary package w/o modifications?
<capum321> yes
<capum321> i just downloaded it from the launchpad site
<nacc> capum321: can i ask why you're rebuilding it? why not just it as a dependency?
<capum321> because of this http://www.monodevelop.com/developers/building-monodevelop/#linux
<nacc> capum321: that's a long page, can you just explain?
<capum321> it is a dependency for building monodevelop
<nacc> capum321: it says it needs mono.addins 0.6; ubuntu is at 1.0?
<nacc> capum321: and even so, what would rebuilding get you?
<capum321> yes you are right
<capum321> to install latest monodevelop
<nacc> capum321: no, you misunderstand; you've got 1.0+git20130406.adcd75b-4; rebuilding the same from the source package will just get you 1.0+git20130406.adcd75b-4. So just use the existing binary package as the dep
<capum321> I don't think I am aware of how to do this? do you mean using the tar.gz file as dependency?
<nacc> capum321: i mean, just install the package (mono-addins-utils or whatever)
<nacc> capum321: as that page says, use the distribution packages wherever possible
<capum321> libmono-addins-cil-dev    libmono-addins-gui-cil-dev    libmono-addins-gui0.2-cil    libmono-addins-msbuild-cil-dev    libmono-addins-msbuild0.2-cil    libmono-addins0.2-cil    mono-addins-utils
<capum321> these?]
<capum321> install one by one you mean?
<capum321> the parental package mono-addins doesn't have a .deb. one should build it. is that it?
<capum321> not sure if I am following you correctly
<nacc> capum321: no, i think you're confusing source packages and binary packages
<nacc> capum321: mono-addins (the debian/ubuntu package) is just a source package
<capum321> yes
<nacc> capum321: it's what is used to build binary packages
<capum321> ok
<nacc> capum321: but you are running ubuntu/debian, so just install the binary pacakges
<capum321> there are no binary packages since i have to build them at first place?
<nacc> capum321: i mean, you *can* build the source package yourself, but the result is exactly what is provided by debian/ubuntu; so why would you?
<nacc> capum321: what?
<capum321> look inside the file
<nacc> capum321: no, the src:mono-addins package makes several binary pacakges, as you said
<capum321> there are no binaries
<nacc> capum321: that's not how source pacakges work
<capum321> oh i think i have understand
<nacc> capum321: in this case, src:mono-addins makes 7 binary packages: libmono-addins-cil-dev, libmono-addins-gui-cil-dev, libmono-addins-gui0.2-cil, libmono-addins-msbuild-cil-dev, libmono-addins-msbuild0.2-cil, libmono-addins0.2-cil, mono-addins-utils
<capum321> continue
<nacc> those 7 packages are available from Ubuntu, you don't build them yourself, unless you have need of a modification or something
<nacc> capum321: afaict, you don't need to modify mono-addins per that page, you just need to install those packages (i don't know precisely which ones)
<capum321> so i should install them one by one as i said
<capum321> you're saying
<capum321> no?
<nacc> capum321: i mean, you can just install them all at once, i guess
<capum321> off course
<capum321> all in one line
<capum321> like apt-get install libmono-addins-cil-dev libmono-addins-gui-cil-dev libmono-addins-gui0.2-cil libmono-addins-msbuild-cil-dev libmono-addins-msbuild0.2-cil libmono-addins0.2-cil mono-addins-utils
<nacc> capum321: yes, but i genuinely don't know which of those you actually need
<capum321> let me check
<capum321> is there a ppa I could use to install simply mono-addins using this launchpad repo?
<capum321> to makes simpler things
<nacc> capum321: what?
<nacc> capum321: mono-addins is *not* a binary package name
<capum321> i see
<capum321> not natively
<nacc> capum321: what? what do you mean "natively"?
<capum321> native... you should buid the source i you want the bin?
<nacc> capum321: no
<nacc> capum321: you never need to build a source package unless you're doing some Ubuntu development
<nacc> (maybe too general, but good enough for now)
<nacc> capum321: the binary packages mentioned already contain the binaries built from building src:mono-addins
<capum321> i see
<capum321> i move on. now installing cmake
<nacc> capum321: a major point of a distribution (well, other than gentoo) is so you, as the user, don't have to build stuff yourself, IMO
<nacc> capum321: you should not have any need for source packages if you're just trying to build some random sourcecode
<capum321> not sure if I get this... how would you build something if you don't have it?
<nacc> capum321: have you used ubuntu before?
<capum321> source packages are full of binary packages
<capum321> is that it?
<nacc> capum321: when you `apt-get install <pkgname>` do you build it?
<nacc> capum321: source packages are full of *descriptions* of how to build binary packages
<nacc> capum321: source packages are just that, source
<capum321> no you don't build like that; debuild builds it
<nacc> capum321: so you're saying you've built every package for your ubuntu yourself? no, you use the archives that contain binary packages.
<nacc> capum321: that page you linked to said use Mono.Addins 0.6, which has been package for Ubuntu since 12.04; so what made you think you need to build that yourself? is it because of the name?
<capum321> actually would be compile a better word?
<nacc> capum321: build, compile, it's the same -- you don't do that for any other package, I don't think
<nacc> capum321: let's say some website said "please make sure you have libc development files installed", would you go get the libc source package and build it yourself? No, you'd `apt-get install libc6-dev`. Why is this any different?
<nacc> capum321: you're not building the dependencies, you're building monodevelop itself, afaict
<capum321> yes, i guess because i read on monodevelop page, i should have thought was the same for its dependency, in particular mono-addins, which was on a deb.tar.gz format with bunch of files in it
<capum321> yeah but I can't do that with `apt-get install mono-addins` because i thought it would install as a usual package likewise
<nacc> capum321: i don't know what file you're referring to (deb.tar.gz format), that sounds like something to ask mono about (not #ubuntu-devel).
<nacc> capum321: that's because mono-addins is a *source* package, as I just spent some time explaining
<nacc> capum321: "Mono.Addins" is the upstream project name, it has no relation, in and of itself, to the binary package names that you need
<capum321> yes, it is getting clearer
<nacc> capum321: but in the end, this whole long conversation has nothing to do with Ubuntu development; I would suggestion asking future questions in #ubuntu
<capum321> deb.tar.gz is on of the four files that trusty supports
<capum321> just a fun fact i spent the whole afternoon trying to solve this in unimagenable channels. including ubuntu, there people who were quiet start to tell me i should use auto-completions plugin + some editor and change to windoze and the hell came up
<nacc> capum321: i don't parse that first sentence, but ok.
<capum321> where should i seek assitance for installing libssh2? is it $ apt-cache search libssh = libssh-4 - tiny C SSH library
<teward> capum321: #ubuntu is the support channel
<cpaelzer> good morning
<ubuntu__> Only thing i would imagine that would cause problems in manual extracting the kernel headers from the kernel to the /usr/src directories is either the folder structure is a little different or  you miss uses the wrong versions
<ubuntu__> Other then that the includes should be exactly identical
<pitti> Good morning
<ubuntu__> linux kernel headers are only useful for LKM creation thats all i can see them for. having to install different versions of them for different LKM versions thats about it... because the headers are also self contained in the linux kernel as well
<dholbach> jbicha, nice one!
<cpaelzer> I have a .service file of clamav and wonder why it isn't startign anymore on newer releases
<cpaelzer> the service files are bit identical throughout the releases, but obiously systemd is newer
<cpaelzer> things work on jessie, but fail on xenial, yakkety, sid
<pitti> cpaelzer: what does "sudo systemctl status clamav" say?
<cpaelzer> on the newer systems it comes as "inactive (dead)" after being installed
<pitti> so it either died or wasn't started at all -> systemctl status please
<cpaelzer> ... need to convince pastebinit ...
<cpaelzer> it hates the utf chars in systemd's output
<pitti> uh? not here
<pitti> http://paste.ubuntu.com/17686364/
<cpaelzer> might be a missing dependency in my container
<cpaelzer> I'll push it through an editor to get on for now
<pitti> wrong locale perhaps?
<pitti> copy&paste into http://paste.ubuntu.com :)
<cpaelzer> sid (broken) http://paste.ubuntu.com/17686435/ and jessie (working) http://paste.ubuntu.com/17686449/
<cpaelzer> all the log content in the sid case is from former start/stop/install/uninstalls
<cpaelzer> at first it had no entries at all in the broken case
<cpaelzer> a simple "systemctl start clamav-freshclam.service" gets things working fine - so it is not broken config or so
<cpaelzer> thereby (working when stared manually and no log) I'd expect it never got started
<cpaelzer> Test is as easy as "apt-get install clamav-freshclam; systemctl status clamav-freshclam.service" on anything recent
<cpaelzer> pitti: are there any other obvious next levels of debugging that could help - like attaching to something like a systemd monitor of event or any logs ?
<pitti> cpaelzer: is that service actually enabled? in your pastebin it was started and stopped
<cpaelzer> pitti: Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled; vendor preset: enabled)
<cpaelzer> the starts were manual ones where I checked if it would start (it did) and stops are from uninstalling the package
<pitti> cpaelzer: for me it doesn't start right after package install, but it does start after a reboot
<cpaelzer> pitti: yeah, exactly - why doesn't it after install is more or less my question?
<pitti> supposedly some breakage in the postinst
<cpaelzer> pitti: ok I'll check for diffs if you assume it is there
<pitti> it apperantly only calls dh_systemd_enable, but not dh_installinit or dh_systemd_start
<pitti> instead it does some really complicated manual code dance
<cpaelzer> pitti: I'd have expected the systemd version change as the service file was bit-identical
<pitti> but it calls invoke-rc.d *before* enabling the unit
<pitti> so this stuff needs to move after #DEBHELPER#
<pitti> cpaelzer: probably more likely to be a side effect of an invoke-rc.d fix
<cpaelzer> pitti: I wonder if it wasn't broken back in the jessie version - I'll look into that - thanks a lot for the pointer
<pitti> it must be enabled first, then started
<pitti> invoke-rc.d does not start disabled stuff
<pitti> maybe it did in earlier versions
<blut> where can i find the busybox configuration of the 16.04 netboot image?
<blut> or maybe, where would be the right place to ask this question?
<cjwatson> blut: It's in the busybox source package in 16.04; debian/config/pkg/udeb
<blut> thank you
<xnox> caribou, hey about https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1583563 why did you steal assignment for it for xenial?
<ubottu> Launchpad bug 1583563 in multipath-tools (Ubuntu Xenial) "System will not start with multipathd enabled" [High,Confirmed]
<xnox> is https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=multipath not enough?
<juliank> thanks pitti
<pitti> juliank: thanks to you, good luck!
<rbasak> cpaelzer: I thought it wasn't starting because of the condition - because freshclam hasn't run?
<rbasak> That's just from memory though I didn't look much deeper.
<cpaelzer> rbasak: it is a bit more complex
<cpaelzer> rbasak: I updated the bug if you want to read into the full analysis
<cpaelzer> rbasak: TL;DR - we discussed the "freshclam doesn't start" part here - but there is also an "daemon should start after install, but only once db is ready" part
<cpaelzer> rbasak: the first is an actual regression - the second always was that way, yet I came up with suggestions that I'll present to the debian maintainer
<rbasak> cpaelzer: sounds like you're on top of it. Thanks :)
<rbasak> cpaelzer: meet ScottK. He used to look after clamav in Ubuntu.
<rbasak> ScottK: this is bug 1590688, which AFAICT affects sid also.
<ubottu> bug 1590688 in clamav (Ubuntu) "clamav-daemon doesn't start after installation" [High,New] https://launchpad.net/bugs/1590688
<cpaelzer> hi ScottK - I'm currently wrapping things up for a proper Debian bug - but I'm gonna test my suggestion first :-)
<flexiondotorg> pitti, I was just asked if there is any intention to change the default systemd timeout from 90s on shutdown in 16.04.1?
<pitti> flexiondotorg: no, this isn't planned
<flexiondotorg> ty
<pitti> this doesn't appear like a safe change for an SRU
<pitti> some stuff like mysql or whatnot might actually need a lot of time during shutdown
<pitti> i. e. *after* we went through services which legitimately need a long shutdown time and add stop timeouts to their *.services, then we can think about lowering the global limit
<pitti> we already got burned with imposing default nproc limits and KillProcesses=, not gonna do this exercise in stable :)
<caribou> xnox: 'cause I'm about to SRU another Xenial fix so I thought I'd do them both
<caribou> xnox: got discussed during the server team meeting yesterday & then I bailed out for the day & just came back so didn't have time to ping you about it
<xnox> caribou, right, if you trump my sru with more fixes, pull mine package from -proposed, add your things on top, and use proper -v to include all changelog entries since xenial-release.
<xnox> caribou, or maybe just ship these. What are the other bug #s to SRU?
<xnox> are they as urgent as multipath-tools are utterly borken?
<caribou> xnox: broken to the point where, with LVM2 devices will be claimed by LVM before multipath gets them
<caribou> xnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817940 was fixed in debian but for some reason the Xenial package has the wrong fix
<ubottu> Debian bug 817940 in multipath-tools "multipath-tools: multipathd is not linked to libsystemd, fails to notify systemd when ready" [Normal,Fixed]
<caribou> xnox: opening a bug for this atm
<caribou> xnox: lp: #817940
<ubottu> Launchpad bug 817940 in Mahara "Session directories are created on every init" [Wishlist,Won't fix] https://launchpad.net/bugs/817940
<caribou> meh: lp: #1595141
<ubottu> Launchpad bug 1595141 in multipath-tools (Ubuntu) "Debian bug #817940 incorrectly fixed in Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1595141
<xnox> caribou, my SRU fixes not linked to libsystemd.
<xnox> caribou, # ldd /sbin/multipathd  | grep systemd
<xnox> 	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fc6df0e1000)
<xnox> caribou, can you retest the lvm bug in yakkety?
<xnox> the not linked to libsystemd is what is causing the 3 bugs mentioned in the changelog, and this lvm thing too.
<caribou> xnox: yakkety has the correct target
<xnox> caribou, and that's included in my sru.
<xnox> caribou, so that pending sru should cover everything, no?
<xnox> caribou, please check http://launchpadlibrarian.net/266780737/multipath-tools_0.5.0+git1.656f8865-5ubuntu2_0.5.0+git1.656f8865-5ubuntu2.1.diff.gz
<caribou> xnox: yep,
<caribou> xnox: just did a debdiff on xenial .vs. yakkety & your SRU brings in the fix
<caribou> xnox: ok, I duped my bug on yours
<xnox> pitti, could you please partially release https://bugs.launchpad.net/ubuntu/+source/gcc-5-cross/+bug/1572613/comments/64 ?
<ubottu> Launchpad bug 1572613 in gcc-mingw-w64 (Ubuntu) "GCC stack access scheduled after stack deallocation" [Wishlist,Triaged]
<xnox> pitti, just the packages mentioned in that comment that have non-regressed autopkgtests?
<pitti> xnox: yes, will do; thanks
<pitti> xnox: done
<ouroumov> Hi. pitti, you've got a sec to talk about https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1457400 ? - Specifically, do you know if there is movement on the subject of changing the default timeout for Desktop Ubuntu?
<ubottu> Launchpad bug 1457400 in systemd (Ubuntu) "reduce 90s session kill timeout if the session does not shutdown cleanly" [Low,Confirmed]
<pitti> ouroumov: see backscroll from an hour ago, flexiondotorg already pinged above
<ouroumov> ok
<pitti> pitti | this doesn't appear like a safe change for an SRU; some stuff like mysql or whatnot might actually need a lot of time during shutdown
<pitti> pitti | i. e. *after* we went through services which legitimately need a long shutdown time and add stop timeouts to their *.services, then we can think about lowering the global limit
<cpaelzer> IRC deja-vu
<ouroumov> Thanks pitti.
<juliank> mvo: What do you think about moving my application from PPU to CoreDev? xnox and pitti seem to be excited about that
<Laney> I'm sure it can gracefully fall back to PPU if the DMB doesn't like the core-dev bit
<mvo> juliank: +1 for core-dev
<caribou> xnox: btw, I didn't *steal* your assignment, it was unassigned when I took it : "assignee:	nobody â Louis Bouchard (louis-bouchard)"
<caribou> :)
<mvo> arges: is there anything I can do to help move #1590434 foward? its a new build-dep in snapd and it would be great to see this landing as its currently blocking some people in the team from moving there code forward. should be no risk as its a) just source b) nothing uses it yet. but if there is anything missing or anything I can do please let me know
<juliank> OK, I moved the application to https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-CoreDev
<mapreri> pitti: is 'dh_installchangelogs: Do not install upstream changelog in compat level 7.  This floods packages with huge upstream changelogs which take precious CD space.' actually still a problem?  did anybody tried to see what happens without that patch?
<mapreri> I don't think it would make stuff much biggerâ¦
<juliank> xnox: OK, it's official now, I sent out a core-dev application!
<juliank> Someone really should fix https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda, the next meeting most definitely is not on "Monday June 20th, 2016 19:00 UTC"
<juliank> that was two days ago
<xnox> mapreri, full debian/changelog, when gzip compressed is 193k, and things from 1994 are entirely pointless.
<rbasak> juliank: go ahead and add it to the agenda with a date. Then you'll be first in line.
<xnox> mapreri, throw in everything in minimal and one has more than a meg of useless stuff.
<rbasak> juliank: https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda?action=recall&rev=565 is an example of what it usually looks like when there are applicants lined up.
<rbasak> We appear to have none right now.
<rbasak> micahg: ^
<juliank> rbasak: OK, added
<rbasak> Thanks!
<mapreri> xnox: we're talking about *upstream* changelog, which not everything has them, and they tends to be a little smaller than d/changelog from my experience.  and even if we get like 2/3 MB more I think we can live with that.  I agree they are useless for ~everybody, though, but it's a delta less from debian.
<juliank> rbasak: Do I now have to monitor that page to find out when the meeting is?
<juliank> or should that be 4th of July at 19:00 UTC?
<rbasak> juliank: sorry, I didn't explain this properly. The date in your entry in the agenda should be the date of the meeting you want to attend, not the date you entered the entry.
<rbasak> Right
<juliank> OK
<juliank> I'll just reformat my entry as well and make my name link to my application
<rbasak> juliank: the meeting on 4 July will be at 1430 UTC according to my calendar unless I'm mistaken.
<rbasak> Uh, 1500.
<juliank> rbasak: OK, I'm at DebCamp anyway, so I can manage any time
<juliank> s/Camp/Conf/
<rbasak> I have my calendar entry include 30 minutes to remember to show up and read applications, etc.
<rbasak> http://fridge.ubuntu.com/calendars/fridge/ seems to have duplicates but I think it is correct.
<juliank> Wonderful.
<xnox> mapreri, pretty sure those are huge and utterly useless.
<xnox> too
<xnox> we did ignore/reduce both. e.g. limit number of entries and/or not have them at all.
<xnox> mapreri, no, we cannot live with 2/3MB more.
<rbasak> I added future meeting dates to the agenda.
<xnox> mapreri, that's huge increase for containers and snappy, target there is about 40MB
<rbasak> I remember it being a pain when I applied to the DMB in the past to find the dates of the meetings. We should keep the upcoming meeting dates updated in the agenda.
<rbasak> micahg: ^
<juliank> Laney: The date parsing issue is now fixed in apt 1.3~exp3, should be syncable in half a day or something
<juliank> (just uploaded it to Debian)
<juliank> SRU for 1.2.14 is also prepared in bug 1595177, I'm just waiting a day or two before turning that bug live
<ubottu> bug 1595177 in apt (Ubuntu) "[SRU template] Update apt/xenial to 1.2.14" [Undecided,New] https://launchpad.net/bugs/1595177
<juliank> Note that 1.3~exp3 now allows you to use weak repositories with the correct setting for your source
<juliank> We might be able to backport that to 1.2 for next year for the SHA1 kill release, once we have a sensible amount of translations
<juliank> but not entirely sure
<caribou> question to SRU team members : I got two regression bugs for the libapache2-mpm-itk SRU (LP: #1286882) on trusty, both caused by the same issue
<ubottu> Launchpad bug 1286882 in mpm-itk (Ubuntu Trusty) "libapache2-mpm-itk postinst failed" [Medium,Fix committed] https://launchpad.net/bugs/1286882
<caribou> a bug in a2query + misconfiguration of the apache2 server
<coreycb> arges, good morning, if you have a moment can you review our xenial horizon sru?  it's a hot one for bug 1594249
<ubottu> bug 1594249 in openstack-dashboard (Ubuntu Xenial) "[SRU] Update of dashboard fails on Xenial" [Critical,Triaged] https://launchpad.net/bugs/1594249
<caribou> is there a way we can unblock this SRU which is blocking another apache SRU (LP: #1286882)
<ubottu> Launchpad bug 1286882 in mpm-itk (Ubuntu Trusty) "libapache2-mpm-itk postinst failed" [Medium,Fix committed] https://launchpad.net/bugs/1286882
<caribou> coreycb: I thinkg that arges is off this week
<coreycb> caribou, ah thanks!
<coreycb> bdmurray, would you be able to look review that? ^
<elopio> pitti: hello! I'm having a problem with autopkgtests and the proxy. Do you have a minute?
<pitti> hey elopio, what's up?
<elopio> pitti: pass -e http_proxy, https_proxy and no_proxy, but it fails when during the package build the network is accessed.
<elopio> like: http://paste.ubuntu.com/17698405/
<elopio> *I pass.
<pitti> elopio: do you actually have localhost in $no_proxy?
<elopio> pitti: yes, this is the call: http://paste.ubuntu.com/17698490/
<elopio> notice that the error is during the package build. Everything that accesses the network during the test execution gets the environment variables alright.
<pitti> elopio: oh, package build -- that might not actually get proxy vars
<elopio> so I'm guessing that the package is build before the -e is set. And I don't know how to set up the proxy earlier.
<pitti> you sholdn't need to
<pitti> a package build should not have proxy vars
<pitti> elopio: if you don't specify -e, does the package build?
<pitti> elopio: so I guess your problem is rather the inverse -- proxy vars *are* already set during package build
<pitti> as using the nova setup scirpt for this does that for *all* commands
<pitti> elopio: so something in your test isn't respecting $no_proxy
<pitti> (test during package build, I mean)
<elopio> pitti: ah, I think I understand what you are saying. If the package build doesn't get the http_proxy, then it shouldn't fail when accessing localhost.
<elopio> hum, let me try without -e.
<pitti> elopio: I think ssh runner's -e is a bit ill-conceived
<pitti> at least for using proxies
<pitti> rbasak: in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804992#15 you said that you already dropped the initscripts dep from mysql-server-5.7 in your git
<ubottu> Debian bug 804992 in mysql-server-5.6 "mysql-server-5.6: Please drop dependency on initscripts package" [Normal,Open]
<elopio> it gets weirder because we have another branch failing trying to access pypi, which has a proxy exception. So for some reason it doesn't respect no_proxy, but also doesn't work with the http_proxy. :/
<elopio> anyway, I'll collect more data points.
<pitti> rbasak: however, it's still there in https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/tree/debian/control
<pitti> rbasak: is that still just not pushed, or in some branch?
<pitti> rbasak: background: I'm currently mopping up the last few stragglers on https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintainers@lists.alioth.debian.org;dist=unstable;tag=initscripts-dep
<pitti> rbasak: the other 5 look simple enough, but I suppose I shouldn't just upload mysql-5.7 for this to not disrupt your vcs etc.
<rbasak> pitti: sorry I hadn't pushed that yet. There are so many loose ends for mysql right now I'm focusing on only a few at a time. No need to block on that now though, so I've just pushed it to Debian VCS in the 5.7 branch.
<rbasak> pitti: I need to prepare an upload to Debian experimental next, and I'll be able to sync that into Yakkety (Ubuntu is almost exactly the same as the Debian 5.7 VCS branch already)
<pitti> rbasak: nice, thanks
 * pitti updates the Debian bug accordingly
<rbasak> Oh, not a sync, but a really trivial merge, to drop a universe dependency.
<pitti> rbasak: you might want to use substvars and drop it for an ubuntu build, to keep the packages in sync?
<rbasak> pitti: yeah, I need to look into that.
<rbasak> It's a build dep, but they're allowed now :)
<rbasak> So I think I can just conditionally compile without support, but have the build dep present all the time.
<pitti> rbasak: ah yes, and conditionally add a --disable-foo?
<rbasak> Yes. Also it's a plugin, so I may be able to have a binary that ships universe dependency plugins in universe. I'm not sure how to do that in a unified way with Debian without it getting ugly though, because Debian shouldn't really have a separate binary package for that.
<pitti> yeah, that's much harder, this probably warrants a delta then
<pitti> still doable with some conditional -N magic, but still "eww"
<rbasak> That's sort of why I haven't got round to it yet (yet another loose end). Thank you for confirming that I'm not missing something :)
<pitti> rbasak: so I guess the simpler thing would be to just conditionally --disable it, and then ponder how to make this thing available in Ubuntu as step 2
<bdmurray> coreycb: I'm out today but will look tomorrow
<coreycb> bdmurray, ok thankx
<coreycb> thanks
<Laney> juliank: cool beans
<blut> !mir
<ubottu> Mir is the next-generation display server currently under development by Canonical and Ubuntu. It's slated for inclusion in Ubuntu 14.04. For more information on it, see https://wiki.ubuntu.com/Mir/Spec . For code, see https://launchpad.net/mir
<nacc> rbasak: hey, i was looking at a bug you had fixed/worked for mysql +dbconfig-common, re: empty port values. I saw it was fix released for mysql, but bacula still fails to configure bacula-directory-mysql; is that because dbconfig-common hasn't been fixed yet?
<nacc> rbasak: LP: #1563274
<ubottu> Launchpad bug 1563274 in dbconfig-common (Ubuntu) "dbconfig-mysql sets blank port in config" [Undecided,Confirmed] https://launchpad.net/bugs/1563274
<rbasak> nacc: the "fix" for MySQL was to allow empty port values again, but they'll be dropped again in 5.8. But it does emit a warning. I've seen dbconfig-common failures but I'm not sure if that's because of the warning or because of some other problem.
<rbasak> The other day I was debugging a pdns dep8 failure which seem to be related to dbconfig-common and postinst ordering.
<rbasak> But the problem went away by itself (non-deterministic)
<nacc> rbasak: i think it's that any warning gets emitted
<nacc> rbasak: http://paste.ubuntu.com/17702876/
<rbasak> elbrus may be able to help.
<rbasak> That's actually a warning followed by an error.
<rbasak> It seems to me that the error (can't connect to socket) is unrelated.
<rbasak> nacc: try experimenting with the ordering of installation of mysql-server, the dbconfig packages, and bacula.
<rbasak> Just a hunch.
<nacc> rbasak: yeah, that might be because it got into a bad state the first time
<nacc> rbasak: this is a relatively important bug, no? bacula consistenly fails to install because of it (and requires manual intervention)
<brendand> has anyone seen this when using autopkgtest-buildvm-ubuntu-cloud: 'qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory'
<brendand> this is being run inside a kvm instance
<nacc> brendand: are you out of memory on your host? :)
<nacc> brendand: nested kvm?
<brendand> nacc, i suppose I *could* be, but I do have 16GB
<brendand> nacc, nested, yeah
<brendand> i suppose i really don't need to do this inside the vm anyway
<rbasak> nacc: yes, it is.
<nacc> brendand: right, but does your guest have 16GB assigned to it?
<nacc> brendand: meaning, does your nested host have sufficient memory?
<brendand> good point. i just used a default, so probably only 1GB
<brendand> i'll change that and try again
<nacc> brendand: yep, that'd be the issue, i'm guessing -- so the second level guest was ENOMEM'ing, as expected :)
<brendand> 500M, heh
<nacc> rbasak: could i put a default value for dbport in /etc/dbconfig-common/config to workaround it?
<LocutusOfBorg> robru, you there?
<LocutusOfBorg> hi
<robru> LocutusOfBorg: yes, I am here in athens on my vacation.
<LocutusOfBorg> sorry for bothering, quick question
<LocutusOfBorg> the new python-coverage broke ubuntuone-dev-tools
<robru> LocutusOfBorg: ok
<rbasak> nacc: if it works, but it would cause a conffile prompt. Is there another way?
<LocutusOfBorg> the fix I propse
<LocutusOfBorg> http://paste.ubuntu.com/17704325/
<LocutusOfBorg> I can upload BTW
<nacc> rbasak: not sure, just learning about dbconfig-common now :)
<LocutusOfBorg> error is: AttributeError: 'module' object has no attribute 'erase'
<robru> LocutusOfBorg: I don't understand why you're talking to me about this.
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/u/ubuntuone-dev-tools/20160622_153920@/log.gz
<LocutusOfBorg> robru, you are the last uploader
<robru> LocutusOfBorg: of what? I generally don't upload much
<LocutusOfBorg> ubuntuone-dev-tools
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/ubuntuone-dev-tools/13.10-0ubuntu4
<LocutusOfBorg> you are almost the only uploader here, even if it was a long time ago
<robru> oh god why
<LocutusOfBorg> err, you are the only one :)
<nacc> heh
<LocutusOfBorg> so, before uploading my "fix" I would like you to ack it
<LocutusOfBorg> it should be just a matter of defining a variable, but I prefer you to ack it ;)
<LocutusOfBorg> and for sure the testsuite will give us another answer
<cjwatson> LocutusOfBorg: err, I think you are confused by "Robert" and "Rodney" looking quite similar
<cjwatson> LocutusOfBorg: robru has uploaded it exactly once, dobey did all the other uploads that I can see
<robru> cjwatson: but indeed mine is the latest
<dobey> what's up?
<dobey> oh hmm
<LocutusOfBorg> cjwatson, I clicked on the email
<LocutusOfBorg> and it bringed me to robru profile
<LocutusOfBorg> not sure what I'm confusing, anyway, if a python developer can acknowledge this http://paste.ubuntu.com/17704325/
<LocutusOfBorg> I'm fine :)
<dobey> cjwatson, LocutusOfBorg: can we just remove ubuntu-sso-client, software-center, and ubuntuone-dev-tools from yakkety?
<cjwatson> LocutusOfBorg: the most recent one would do, but all the other uploads in https://launchpad.net/ubuntu/+source/ubuntuone-dev-tools/+changelog are not robru
<cjwatson> dobey: hey, I'm just attempting to drive-by unconfuse LocutusOfBorg here
<cjwatson> removing software-center would be a desktop team thing
<robru> dobey: +1
<dobey> Laney: ^^ ? :)
<Laney> Dunno
<Laney> ask the list
<Laney> I would upload the fix to unblock whatever is currently stuck
<Laney> No need to couple the two things IMO
<LocutusOfBorg> well, indeed cjwatson :)
<dobey> LocutusOfBorg: fix looks ok to me. if it unblocks, go ahead and upload it
<LocutusOfBorg> dobey, yes, it is building correctly
<LocutusOfBorg> lets upload and see the testsuite
<LocutusOfBorg> thanks
<LocutusOfBorg> done! :)
 * LocutusOfBorg leaves shortly, train is approaching station
<Laney> you probably could have run adt locally
<Laney> oho
<dobey> Laney: well, if it's ok to remove them, then we should do it now, rather than waiting for the next failure :)
<LocutusOfBorg> Laney, it works
<Laney> dobey: I recommend you start the thread now then
<Laney> I can't decide that alone
<LocutusOfBorg> it wasn't compiling, and it started building correctly
<LocutusOfBorg> the failure was on rebuild, and it seems fixed
<LocutusOfBorg> and the runner is called the same way on adt and build testsuite
<LocutusOfBorg> so I guess no issue expected ;)
<LocutusOfBorg> but I'll keep an eye until coverage and ubuntuone-dev-tools migrates
<LocutusOfBorg> dobey, thanks for removing the binaries eventually ;)
<dobey> yes, if the source tree builds it should be fine
<LocutusOfBorg> thanks a lot
 * LocutusOfBorg leaves
<dobey> the autopkgtests just run the same build :)
<nacc> rbasak: hrm, i changed bacula's dbconfig file, it avoids that error, but then it says it can't connect, although i can using the same credentials from the cli command-line
<semiosis> hi all.  i'm working on bug 1565985 and think I have a good strategy to solve it.  anyone around to discuss?
<ubottu> bug 1565985 in livecd-rootfs (Ubuntu) "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,Confirmed] https://launchpad.net/bugs/1565985
<semiosis> copying what i wrote in #ubuntu-server.  i think this may be a better forum.
<semiosis> what i want to do is move 42-vagrant.binary to 40-vagrant.binary and, instead of having it use the vmdk produced in 40-vmdk-image.binary, use the disk image produced by 32-disk-image.binary. that way we can mount the disk image, install the extra packages needed for a vagrant base box, then call create_vmdk and continue with the rest of the vagrant packaging stuff.
<semiosis> the source files i'm referring to are here: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/files/head:/live-build/ubuntu-cpc/hooks/
<nacc> rbasak: ok, here's what i figured out so far: if i just do a `apt-get install bacula` first, it will use sqlite3 (contradicts https://help.ubuntu.com/lts/serverguide/bacula.html), but it succeeds. If I then install `apt-get bacula-director-mysql bacula-common-mysql`; that install throws a warning and error (http://paste.ubuntu.com/17707954/) but it does not fail to install (unlike if I try to just
<nacc> `apt-get install bacula-director-mysql` as the first package)
<infinity> semiosis: Discuss it on the bug, the right people might not be paying attention here.
<rharper> hallyn: around ?  on yakkety, non-root access to /dev/kvm doesn't work;  http://paste.ubuntu.com/17708681/
<semiosis> infinity: i'm going to try that strategy out and if it works i'll push a branch.  then there will really be something to discuss.  just wanted to throw out the idea here too.
<rharper> hallyn: of course adding kvm group works;  just wondering why it works without the group on xenial I suppose
<hallyn> acl not being set?
<hallyn> are you logging inthe same way to both?
<hallyn> on xenial an acl gets set on login
<hallyn> for the desktop user
<infinity> I've never noticed non-root access to /dev/kvm working without being in the group...
<infinity> Why would that work?
<sarnold> o_O
<hallyn> bc http://paste.ubuntu.com/17708894/
<hallyn> i never really liked that, but desktop ppl did
<infinity> So, it's part of the desktop session?
<infinity> Or..?
<hallyn> grep -nr kvm /lib/udev
<hallyn> i actually forge the details, looking,
<hallyn> yeah it's some combination of udev and consolekit
<hallyn> /lib/udev/rules.d/70-udev-acl.rules is the key .  is that different in yakkety?
<infinity> It doesn't exist in yakkety.
<hallyn> ships with consolekit...
<hallyn> rharper: ^ there you go, were you going to track down what changed? :)
<infinity> Which we don't install.
<rharper> hallyn: interesting, yakkety is a ssh session, my xenial is my laptop/desktop session
<rharper> infinity: I don't know that I've verified that either... I think group access has always been required as well ; I was just surprised that it worked on my laptop without it.
<rharper> hallyn: looking
<infinity> rharper: Okay, so if this is set for local sessions, that ssh one wouldn't work anyway.
<infinity> (I'm not a big fan of people's extrapolation that because you have physical access, you may as well be allowed to do scary things, but whatever...)
<ubuntu__> curious does /dev/kvm does that device need to exist for uses of virtualbox ,quem , bochs ,...etc or is that just for type 1 virtualization like hypervisor analogy for windows
<rharper> I do think something changed;  I've been running some qemu based tests on my yakkety host via ssh and I've not seen this before;
<infinity> ubuntu__: It's for kvm-accelerated VMs so, no, not for full-emu qemu, bochs, etc.
<infinity> ubuntu__: Also, pick a better IRC nick? :P
<rharper> ubuntu__: any virt software that wants to use hardware virt provided the platform needs it
<sarnold> /dev/kvm is likely only used by kvm-accelerated qemu and kvmtool. bochs probably not, virtualbox probably can't work with the module loaded..
<infinity> rharper: s/hardware/kvm/ :P
<infinity> sarnold: vbox and kvm can coexist, but the former doesn't use the latter.
<rharper> infinity: yeah;  vbox loads it's module instead IIRC
 * infinity nods.
<sarnold> infinity: intersting, I thought I recalled rmmodding the one to use the other many years back
<infinity> sarnold: I flip-flop between the two when bug-hunting specific oddities, they seem to coexist fine these days.
<sarnold> infinity: nice, it was an annoying compliction back in the day
<infinity> sarnold: Well, the better option is always just to burn vbox in fire.
<infinity> sarnold: Yet another example of the importance of UI design, I suspect.  Doesn't matter if the underlying tech sucks a bit if the package is pretty and usable.  Which qemu/kvm sure as heck weren't for ages (and still aren't, a lot of the time).
<hallyn> sarnold: i think that's in the past.  yeah they used to not work together
<hallyn> infinity: personally i hate vbxo bc i never have a gui and hte cmdline sucks ass
<infinity> A nice VM UI that sat on top of kvm, hyper-v, and whatever the native MacOS interface is, and just did the right thing in a pretty and consistent way would probably have users flock to it in droves.
<Unit193> hallyn: ...phpvirtualbox. :P
<hallyn> yeeaaah
<sarnold> lalalalalalala can't hear you lalalala
<infinity> hallyn: I've never even attempted to use vbox from the CLI.  And, on the flipside, any attempt I've made to use qemu from a GUI has drive me *back* to the CLI.  Clearly a gap there in both directions. :P
<hallyn> yup
<hallyn> rharper: inthe past when it worked for you in yakkety, which user were you using?  was it not inthe kvm group?
 * juliank used vbox cli stuff a few years ago. but vbox sucks big time, it made the machines fairly crashy
<rharper> hallyn: correct
<hallyn> bc typically on my nested vm usage, user ubuntu is in group kvm
<rharper> like last week, it worked without group kvm
<hallyn> that sounds like a fixed regression then :)
<rharper> yeah
<hallyn> it shouldn't have
<juliank> infinity: Do you have some endorsement to share on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-CoreDev ? That would be nice, perhaps even useful :)
<rharper> I agree
<rharper> which makes me thing I'm bonkers
<hallyn> as you get more datapoints please ping me - or raise a bug
<hallyn> \o
<rharper> because how would something fundamental like group access fail ?
<hallyn> negative acls
<rharper> hallyn: well, I can't reproduce it working *without* the group now
<rharper> that's a new term to me
<hallyn> without the group and without the acl?
<hallyn> please do open a bug then, this is too convoluted a set of data to keep straight in my head or in an irc conv
<rharper> ok, I'll open
<elbrus> nacc: I can try to help with bacula, but your pastebin gives too little information
<nacc> elbrus: ack, will reproduce, what all do you need?
<nacc> elbrus: it happens immediately on trying to install bacula + mysql in 16.04
 * nacc starts up a fresh container
<elbrus> nacc: is the mysql-server installed and configured before?
<elbrus> if mysql-server is not yet configured, you can expect this I guess
<nacc> elbrus: not necessarily; it's the first configuration that came up this time (not sure if it's consistently/repeatably so)
<elbrus> I had to order this correctly for cacti autopkgtest as well, if the order is wrong, things fail
<elbrus> this can't be properly detected by dbconfig-common, as the mysql-server may very well live on a different host, so nothing to test before the admin told us what to expect
<elbrus> well, I think detection is correct ...
<elbrus> it fails...
<nacc> http://paste.ubuntu.com/17710725/ is the typescript
<nacc> elbrus: note that time, it threw the same warning and then an error ("invalid default value for 'CleaningDate'")
<nacc> but it finsihed that time too :/
<ubuntu__> ok lsmod gives me all the LKM in uses. Tracking down only audio i have http://pastebin.com/KpMy9NXp
<elbrus> nacc: but the invalid value for CleaningDate looks like a bug in bacula with respect to MySQL not accepting zero-date anymore
<ubuntu__> using lspci i have that the audio hardware is associated to this LKM snd_hda_intel
<elbrus> I had to fix that in cacti as well in a SRU.
<nacc> elbrus: ah could be, do you have a pointer to the corresponding cacti fix?
<elbrus> nacc: let me look that up
<nacc> elbrus: and i think the result is actually a failure, btw (i have to ignore the bacula-director-mysql errors to proceed) as trying to then install the test packages from my ppa fails due to various tables existing
<ubuntu__> so kind of wondering what the other snd* LKM are for am i right in saying the snd_hda_intel is the lowest level LKM in the sense of does the most lowest level control of the sound card hardware?
<nacc> elbrus: so let me add your fix :)
<nacc> ubuntu__: wrong channel?
<elbrus> http://anonscm.debian.org/cgit/pkg-cacti/cacti.git/commit/?id=b94dd8459080d242f24d900786d4ab5052526545
<elbrus> and
<elbrus> http://anonscm.debian.org/cgit/pkg-cacti/cacti.git/commit/?id=82150a56c51cbdb82e9f6f8e7136b1a939d7dffe
<elbrus> so effectively
<elbrus> http://anonscm.debian.org/cgit/pkg-cacti/cacti.git/tree/debian/patches/make_cacti_sql_mode-strict_compatible.patch
<nacc> elbrus: great, thank you! let me try and do the same to bacula
<elbrus> which basically sets the session sql_mode to exclude the NO_ZERO_DATE
<elbrus> because upstream doesn't want to fix it "properly" as it is using it by design
<nacc> ok :)
<nacc> elbrus: it seems like bacula uses a script to create the tables; would i run that set in their script then?
<elbrus> nacc: I guess there, and upon calls involving this column
<nacc> elbrus: yep
<elbrus> as in my patch, I set it in cacti.sql (which is used to fill the database) and in lib/database.php, which is used to connect the web-app to the database
<nacc> elbrus: got it
<nacc> elbrus: thanks for the pointers, all of this is foreign to me :)
<elbrus> nacc: np
<elbrus> this is more related to the late move of Ubuntu to MySQL 5.7
<elbrus> but glad I could help
<nacc> elbrus: yeah, i am gathering as much
<nacc> elbrus: since bacula is in sync w/ debian right now, i'll send up whatever fixes i find as well
<elbrus> nacc: Debian hasn't moved to MySQL 5.7 yet last time I looked
<elbrus> but yes, patches welcome
<elbrus> I assume
<nacc> elbrus: yeah, i guess it'd be eventual
<nacc> elbrus: there are some functional issues with the code too, i think
<nacc> elbrus: working through our bugs now
<nacc> elbrus: hrm, so another attempt to install bacula-director-mysql, and got: http://paste.ubuntu.com/17713797/. THe mysql-server configuration finished first
<elbrus> nacc: looks like you chose an other password for the bacula user than the previos time
<nacc> elbrus: this was a fresh lxc container
<elbrus> (there is an existing bug that the password does not get replaced)
<nacc> elbrus: link to that bug?
<elbrus> hmm, ${db_name} should have been replaced with a name
<nacc> elbrus: yeah, i would ahve thought so
<elbrus> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439078
<ubottu> Debian bug 439078 in dbconfig-common "passwort of db user is not updated during reinstall" [Normal,Open]
<elbrus> but you mean, fully clean lxc before THIS install of bacula?
<nacc> elbrus: yep, i'm starting from scratch each time
<elbrus> or clean before you started to try install
<elbrus> ok
<nacc> elbrus: it's super-inconsistent :/
<elbrus> can you please "dbc_debug=true" before the apt-get incantation?
<elbrus> be carefull with copy/paste, passwords are exposed
<nacc> elbrus: let me reproduce it and do so
<nacc> elbrus: there are all throw-away containers
<nacc> *these
<nacc> elbrus: but will do so and ping you when i have output
<nacc> elbrus: e.g., `dbc_debug=true apt-get install bacula-director-mysql` ?
<nacc> elbrus: or does it need to be exported in teh env?
<elbrus> indeed
<elbrus> the first one
<nacc> elbrus: thanks
<nacc> elbrus: http://paste.ubuntu.com/17714692/
<elbrus> nacc: can you log into mysql and verify that the bacula database exists and that the bacula user exists? maybe even try to log in manually as bacula user with the password in your copy?
<nacc> elbrus: yep, one sec
<elbrus> oh, and maybe grep for db_name in the bacula code? I can't find that string in dbconfig-common, so it looks like it comes from bacula
<nacc> http://paste.ubuntu.com/17714862/
<nacc> elbrus: ack, one sec
<nacc> elbrus: http://paste.ubuntu.com/17715004/ heh, i wonder if that sed fix isn't complete
<elbrus> well, the variable end up in MySQL as a string '${db_name}' as the name of the database, which doesn't exist of course, because the name is 'bacula'
 * elbrus is nearly going to bed.
<nacc> elbrus: yep, i'll dig, thanks!
<marlinc> What would be a good package to check out that is not being compiled? I'm trying to create a deb for a application that is not being compiled
<jbicha> marlinc: please be more specific about what kind of package you're looking for
<marlinc> I'm sorry, this is the first time I'm trying to package up a application. I think I found out was going wrong..
<dobey> marlinc: compiled is irrelevant. python isn't necessarily compiled, for example
<dobey> what are you trying to package exactly?
<Unit193> Some scripts are just popped into place, I have a package like that.
<marlinc> ipsilon, its a identity provider written in Python. Kind of a companion to FreeIPA
<dobey> marlinc: does it have a setup.py script?
<marlinc> it does, yes
<marlinc> And it has a Makefile to run tests etc
<dobey> then you can grab almost any other python based tool's source package to learn from. pep8 or pyflakes are probably some of the simplest ones
<marlinc> Cool, thanks
<dobey> marlinc: there's also #ubuntu-packaging which is a channel specifically for such packaging questions :)
<marlinc> Ah, thank you :)
<jbicha> marlinc: https://wiki.debian.org/Python
<marlinc> I'll look at that jbicha, thanks
<nacc> elbrus: rbasak: fyi, i found (a/the) bug, i think, /etc/bacula/scripts is not subsituting db_name
<nacc> elbrus: rbasak: hrm, maybe not
<nacc> can anyone say if messages like this: http://paste.ubuntu.com/17722065/
<nacc> come from the package itself, or some (well-known) helper tool?
<nacc> found it, it's in dbconfig-common
<nacc> rbasak: elbrus: ok, it's the postinst that's emitting the error ("Access denied for user 'bacula'@'localhost' to database '${db_name}'). still debugging
#ubuntu-devel 2016-06-23
<smoser> i'd really appreciate it if someone could take a look at the cloud-init upload in xenial-proposed.
<smoser> I dont intend to be quick about moving it out of proposed at all, but would like it to get *in* to proposed to further testing.
<smoser> bug 1577872
<ubottu> bug 1577872 in curtin (Ubuntu Xenial) "[SRU] curtin in yakkety to supported releases" [Medium,Fix committed] https://launchpad.net/bugs/1577872
<smoser> bah. bug fail
<smoser> bug 1595302
<ubottu> bug 1595302 in cloud-init (Ubuntu Xenial) "[SRU] xenial cloud-init update" [High,In progress] https://launchpad.net/bugs/1595302
<smoser> better
<ubuntu__> here something i don't get in /proc/iomem the sound is apparently using this mmap  address  f7d30000-f7d33fff : ICH HD audio doing out the math you only have 16 KB of memory for the buffer of audio . If your sampling  at 32-bit, 192 kHz how is this buffer going to be large enough. Maybe i am misunderstanding something
<mgedmin> that's probably just the control registers
<mgedmin> I would expect audio buffers to be DMAed from the main memory
<cpaelzer> good morning
<Skuggen> nacc: Just in case it wasn't clear, it does mean it's actually trying to connect to a database named "${db_name}"
<Skuggen> nacc: http://paste.ubuntu.com/17732610/
<Skuggen> nacc: And that the user is valid, or you wouldn't see the Â«to databaseÂ» bit
<pitti> Good morning
<pitti> rbasak: mysql-server-5.7 is now the only remaining rdepends of initscripts in the whole yakkety archive; sooo tempted to cherry-pick that upload to finally finish it off..
<pitti> rbasak: would that actually get in your way somehow?
<ubuntu__> So i am wondering about how this acpi works for advanced configuration power interface really confused
<ubuntu__> curious anybody familar with how these ports work
<ubuntu__>   0400-0403 : ACPI PM1a_EVT_BLK
<ubuntu__>    0404-0405 : ACPI PM1a_CNT_BLK
<ubuntu__>    0408-040b : ACPI PM_TMR
<ubuntu__>    0410-0415 : ACPI CPU throttle
<ubuntu__>    0420-042f : ACPI GPE0_BLK
<ubuntu__>    0450-0450 : ACPI PM2_CNT_BLK
<ubuntu__> I have these ports for it
<ubuntu__> And  d9ff9000-da2f9fff : ACPI Non-volatile Storage
<ubuntu__> da35b000-da5dafff : ACPI Non-volatile Storage
<ubuntu__> da5db000-da5dffff : ACPI Tables
<ubuntu__> da5e0000-da622fff : ACPI Non-volatile Storage
<ubuntu__> for the mmap
<ubuntu__> I understand it is made some how platform independent uses some type of bytecode though  don't really get it at all there are like  tons of tables with in the ACPI TABLE 20kb address space  like DSDT SSDT XSDT ...
<ubuntu__> Anybody good with this stuff
<rbasak> pitti: an upload to Yakkety? That's fine if you want to upload it.
<pitti> rbasak: yes, that; ok, thanks
<LocutusOfBorg> pitti, please try ubuntuone-dev-tools against python-coverage in proposed? :) thanks
<LocutusOfBorg> or the opposite is even better
<pitti> LocutusOfBorg: err, python-coverage pulls in ubuntuone-dev-tools? that sounds strange
<pitti> LocutusOfBorg: running: http://autopkgtest.ubuntu.com/running.shtml#pkg-ubuntuone-dev-tools
<LocutusOfBorg> ubuntuone-dev-tools has a test with coverage
<LocutusOfBorg> and the coverage in proposed is fixed, together with ubuntuone-dev-tools in proposed
<pitti> but it seemed to me that the new python-coverage regresses
<pitti> oh, ok, great
<LocutusOfBorg> :)
<pitti> mvo: btw, I uploaded https://launchpad.net/ubuntu/+source/ubuntu-core-launcher/1.0.30ubuntu1 last night, it broke too many things
<LocutusOfBorg> so, I guess you can retry the one against python-coverage, make python-coverage migrate, and then I can retry the one on ubuntuone-dev-tools and see it migrate too :)
<LocutusOfBorg> or you can retry them both, as you like
<pitti> mvo: still makes stuff uninstallable (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt), but I'll leave that other transition to you :)
<LocutusOfBorg> I'm leaving, thanks pitti
<mvo> pitti: thanks and sorry, we meant to release a new version but there were some hickups there too
<LocutusOfBorg> thanks pitti it worked flawlessly
<pitti> nice
<flexiondotorg> Anyone able to review a trivial merge proposal for indicator-session that would really help out Ubuntu MATE? https://code.launchpad.net/~ubuntu-mate-dev/indicator-session/mate-compatibility/+merge/297183
<kmadac> Hello, I would like to ask where to find ics-dhcp-client package repository for ubuntu xenial. I tried to make "bzr branch ubuntu:isc-dhcp-client isc-dhcp-client.dev", but I get Invalid url error. Thanks
<Odd_Bloke> kmadac: UDD (which provides bzr branches for packaging) is not used for xenial, so AFAIK your best is to use pull-lp-source in the ubuntu-dev-tools package.
<kmadac> Odd_Bloke: Thank you :)
<Odd_Bloke> pitti: Good morning!  https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1584393 looks like an ifupdown/SSH systemd deadlock/race condition on xenial; do you have the time to dig in to it?
<ubottu> Launchpad bug 1584393 in ifupdown (Ubuntu) "systemctl restart networking hangs reloading ssh.service" [Undecided,New]
<pitti> hey Odd_Bloke
<pitti> Odd_Bloke: I can't reproduce this in a VM, but yes indeed, looks like a deadlock
<pitti> Odd_Bloke: it could be fixed in openssh's if-up.d hook to reload asynchronously
<pitti> or in invoke-rc.d to make all reloads async, but this is prone to break other things which expect it to block until it's actually done
<Odd_Bloke> pitti: (If you do want a system to look at, I've `ssh-import-id pitti`'d on ubuntu@104.155.74.34)
<pitti> also, utterly low-prio -- restarting networking has never worked at all under upstart, and now it at least seems to work most of the time
<Odd_Bloke> pitti: Yeah, I'm only asking because we're beginning to hear from partners about it.
<pitti> Odd_Bloke: works on your system too
<Odd_Bloke> ... It didn't before.
<Odd_Bloke> Weird.
<Odd_Bloke> pitti: Thanks for the bug comment. :)
<Unit193> jbicha: Howdy.  Do you plan to package numix-gtk-theme as well?
<Unit193> Ah, #827792 I see.
<mwhudson> i'm sure i'm missing something obvious (and i'm tired and my brain isn't working)
<mwhudson> but can someone explain to me why golang-defaults is not migrating?
<mwhudson> it says "golang-any-shared-dev/amd64 unsatisfiable Depends: golang-any"
<mwhudson> but golang-any is made by the same package...
<mwhudson> and the package installs fine
<Unit193> jbicha: Also FWIW Shimmer/Xubuntu may look into the GTK-3.20 patch here soon, but since Ubuntu is standing still on that it's not a high priority in Greybird, at least last I knew.
<Unit193> ...It'd be weird for the GTK theme to dep on the icon theme, I'd believe.  Recommends or suggests would be better.
<shemgp> is this where i ask for help in fixing an ubuntu bug in a package?
<shemgp> bzr branch ubuntu:tomboy tomboy.dev from http://packaging.ubuntu.com/html/udd-getting-the-source.html#branching doesn't seem to work in my machine
<shemgp> says: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/tomboy/".
<brendand> has anyone here ever tried configuring virsh/kvm to run an ipv6 (only) network? i'm a bit lost as to why it won't work
<pitti> rbasak: yay, mysql-5.7 went in, with it the new sysvinit, so initscripts is history now \o/
<infinity> pitti: Do you have some armhf autopkgtest machines running trusty kernels and some running xenial kernels?
<infinity> pitti: I'm seeing a regression on glibc/wily that looks suspiciously related to running kernel.
<pitti> infinity: ah, in fact I do; have one with t/w/x each, to bisect bug
<pitti> the "old" LXC nodes on cyclops all run xenial
<pitti> but I also have some new scalingstack ones
<infinity> pitti: I guess there's no way to direct a job at a specific machine? :P
<pitti> infinity: but this is actually obsolete, it's not due to the VM guest kernel; so I can bring them all up to xenial again
<pitti> infinity: there is with some hand-holding
<infinity> pitti: Of course, if the goal is to bring them all to xenial, that doesn't help me here. ;)
<pitti> infinity: we record the kernel version, so it's easy enough to check
<pitti> infinity: oh, you are saying xenial's is *worse*?
<infinity> pitti: Since it's the xenial builds that fail, all the green ones are trusty.
<pitti> 'cause that's all we've ever had
<pitti> *all*?
<infinity> Well, the random sampling of green that I've looked at.
<infinity> They all look to be 3.13
<infinity> Only those select few reds were 4.4.0
<infinity> But I've not been patient enough to download *all* the logs.  If you can prove me wrong, I'm all for it. :)
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/armhf/g/glibc/20160610_025954@/log.gz
<pitti> that indeed was a trusty kernel, yes (green)
<pitti> ooh!
<pitti> infinity: right, the cyclops boxes run trusty kernels on xenial userspace as newer kernels don't work on those any more
<pitti> I forgot, sorry
<infinity> "cyclops" being... highbanks?
<pitti> yes
<infinity> If highbank regressed in xenial, we should fix that.
<pitti> (Calxeda nodes)
<infinity> It's meant to work, so the bug is likely downstream.
<infinity> Anyhow.
<pitti> yeah, may just be a config issue
<pitti> AFAIR, it doesn't boot because it doesn't find the root fs, maybe missing driver
<infinity> None of this is your problem.  I don't care what kernels the autopkgtest machines run (well, I care for kvm ones, but for lxc runners, whatever), just making sure my hypothesis that tst-signal6 regresses on newer kernels indeed matches your data.
<pitti> yes, I agree
<infinity> apw: ^-- On armhf, tst-signla6 is going to flap based on which node you land on, if you grep the log for "running kernel", 3.13 should be fine, 4.4 is bust.  That's not a new regression.
<apw> infinity, ack thanks
<roadmr> Hello folks! Firefox 47.0 breaks Selenium, is there a way to get the immediately previous version (46.0)? on Trusty, the only other one I see is 28.0 which is too old :(
<nacc> Skuggen: yep, it's something screwed up during the build, I'm just trying to backtrack with dbconfig where it's getting that database name from. Thanks for the tip!
<nacc> roadmr: is there a bug filed?
<nacc> ubuntu__: i think i mentioned this to you earlier this week; that's not really a question for this channel. Ask in #linux or find an ACPI related channel using alis
<roadmr> nacc: not on Ubuntu, I think. There's this: https://github.com/SeleniumHQ/selenium/issues/2110
<nacc> roadmr: ok, it may help to file a bug in LP and explain. You can see from the changelog (http://changelogs.ubuntu.com/changelogs/pool/main/f/firefox/firefox_47.0+build3-0ubuntu0.14.04.1/changelog) that many versions have been published in trusty.
<nacc> rbasak: ugh, this bacula bug is teaching me quite a bit about dbconfig :) ... but not making much progress
<nacc> elbrus: oddly, in /var/log/dbconfig-common/dbc.log: "populating database via sql...  done.", but http://paste.ubuntu.com/17749799/
<nacc> elbrus: that's the the dbconfig output with set -x enabled in the common file
<cjwatson> roadmr: you can get older versions by manually downloading the .debs, starting from https://launchpad.net/ubuntu/+source/firefox/+publishinghistory
<roadmr> cjwatson: awesome!!! thanks! I'm sure I can hack something to use that for my broken tests. Cheers!
<nacc> roadmr: i would try the immediately preceding one first and then it's obviously a regression, etc.
<roadmr> nacc: it is; Firefox 46.0 works just fine
<nacc> roadmr: ah ok
<nacc> rbasak: elbrus: found it: http://paste.ubuntu.com/17750447/
<nacc> rbasak: fyi, i might need some assistance from you eventually if bacula needs actual mysql changes (they do some db upgrade stuff in the debian pacakging, and i don't think it's been updated for 5.7) (the last upgrade file mentioned in the contents is 5.2.0)
<rbasak> Sure
<nacc> rbasak: still trying to figure out how dbconfig generates files like '/usr/share/dbconfig-common/data/bacula-director-mysql/install/mysql'
<nacc> ah
<nacc>         $(foreach db,$(VARIANTS),$(shell debian/scripts/install-dbconfig $(db)))
<nacc> i totally see why dbconfig is better for maintainers, but quite difficult to debug :)
<doko> apw, is linux-hammerhead still a supported kernel?
<apw> i don't think it ever was supported, that was an rsalveti job i think no ?
<apw> rtg ^ ?
<ogra_> cjwatson, is https://twitter.com/launchpadstatus dead (LP just told me to check it in the "Uh Oh" message)
<cjwatson> ogra_: it's alive, but having it be updated for a random unscheduled firewall failure would rather depend on there being any Launchpad staff around for whom it's a reasonable timezone and who aren't on leave.
<jbicha> Unit193: https://github.com/numixproject/numix-gtk-theme/issues/488
<ogra_> cjwatson, ah, i thought it is a bot
<semiosis> hmmm launchpad is not working.  probably due to the flood of replies to the comment I left on bug 1565985 earlier today!
<ubottu> bug 1565985 in livecd-rootfs (Ubuntu) "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,Confirmed] https://launchpad.net/bugs/1565985
<semiosis> heh, it just started working again
<semiosis> aww, there weren't any replies to my comment
<infinity> semiosis: We had a datacenter spontaneously reboot.  You didn't break it. :P
<semiosis> ouch.  good luck with that
<elbrus> nacc: your last message is it...
 * elbrus means http://paste.ubuntu.com/17750447/
<nacc> elbrus: yeah, i'm trying to work through dbconfig's generator to see why that's happening
<elbrus> nacc: dbconfig-common taks that from bacula
<nacc> i think it's a bad variable subsittution in the bacula build
<elbrus> nacc: I thought you figured that out yesterday while I was still on-line
<elbrus> isn't /usr/share/dbconfig-common/data/bacula-director-mysql/install/mysql in the bacula package, no mistery there I think
<nacc> elbrus: i'm fully new to dbconfig, so i didn't realize that; or which particular file it was
<nacc> elbrus: now i know, and am trying to work out what's generating that file
<elbrus> did you read the documentation?
<elbrus> especially the design document
<elbrus> only about 3 pages IIRC
<nacc> elbrus: yep, after realizing this, reading that now
<nacc> *read
<nacc> elbrus: so bacula has this debian/scripts/install-dbconfig file; which contains the lines: extract_here("src/cats/make_".$longdb."_tables", "debian/bacula-director-$db/$DBC/bacula-director-$db/install/$db");
<nacc> but that source file is a shell script, and it seems like it's getting parsed somehow
<nacc> because what ends up in install/mysql is just SQL syntax
<elbrus> what do you mean with "parsed"?
<elbrus> during build?
<nacc> elbrus: let me show you the contents
<elbrus> it's not shell, it's perl
<elbrus> see the first line
 * elbrus doesn't read perl...
<nacc> elbrus: http://paste.ubuntu.com/17755004/
<nacc> elbrus: yes, install-dbconfig is perl, but not he file it's installing
<nacc> (src/cats/make_mysql_tables)
<elbrus> nacc: where does your /bin/sh point to?
<nacc> elbrus: dash, the default in ubuntu, i think
<nacc> yeah
 * elbrus has to attent to a little girl, back in an hour or so
<nacc> elbrus: np, thanks
<nacc> elbrus: ah i figured it out
<nacc> elbrus: the perl script snips out everything between the two herefile markers
<nacc> this can't ever have worked...
<nacc> elbrus: ah, and at some point, debian did manually sed this file
<nacc> argggh
<nacc> elbrus: rbasak: upstream bug, fixed in the latest upstream git
<nacc> elbrus: also that datetime issue fixed upstream too :)
<nemo> What's wrong with bugs.launchpad.net ?
<sarnold> nemo: I understand a datacenter lost power
<nemo> sarnold: huh. hosted in california or something?
<nemo> but aight. can wait
<sarnold> nemo: I think this one is in london
<nemo> sarnold: huh. the power shutdowns and decent into mad max chaos weren't supposed to happen until 21:00 UTC
<sarnold> nemo: funny thing about descents into mad chaos..
<elbrus> nacc: great
<Unit193> jbicha: Gotta say, not seen that one.  It only happen in MATE?
<jbicha> Unit193: AFAIK, MATE's theme chooser is the only thing that cares about a gtk theme setting an icon theme
<jbicha> if no icon theme is set, it won't even show up in the chooser
<jbicha> and if an icon theme is set but that theme isn't available, it'll show up but with a warning
<Unit193> Well, recommends are installed both in Debian and Ubuntu, so might make sense to be able to install one without the other, no?
<nacc> Unit193: only if you use `apt`; `apt-get` doens't install recommends by default (iirc)
<Unit193> nacc: False, both get recommends.
<nacc> Unit193: ah you're right sorry, i chagned my local config :)
<jbicha> I don't think it helps any thing to demote it from depends to recommends
<Unit193> Hah, that's fine.  Only flavor that doesn't get recommends is Lubuntu.
<Unit193> jbicha: It'd give the user the option to uninstall it if the user doesn't plan on using it, while still being able to use the GTK theme.  Was just asking as it doesn't actually require it to run, I've been using it for a while and never noticed a thing (or message.) :)
<jbicha> so for MATE's benefit, we need to depend on some icon theme: probably numix or adwaita
<jbicha> who uninstalls icon themes?
<nacc> elbrus: re: zero date. Upstream bacula (as well as the version in debian/ubuntu, did this: http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4&id=36d647345df3c98a2cc1ad24af31e73aaff4a2e9)
<nacc> why doesn't that work?
<nacc> is it an implicit 0 now?
<bdmurray> coreycb: There is a version of horizion already in xenial-proposed.  Should that be verified and release first?
<coreycb> bdmurray, the version in the queue fixes a bug found in testing of the proposed package
<coreycb> bdmurray, that doesn't answer your question but maybe it does indirectly
<bdmurray> coreycb: it did, thanks
<coreycb> bdmurray, ok, thanks
<bdmurray> coreycb: oh hrmph, the bug (1594249)  didn't have any horizon tasks so didn't get commented on
<coreycb> bdmurray, I see a comment from you.  it may be confusion between the source package being horizon and binary package being openstack-dashboard.
<coreycb> bdmurray, thanks for the review
<bdmurray> coreycb: launchpad tracks bugs about source packages not binary packages
<bdmurray> coreycb: there's nothing here https://launchpad.net/ubuntu/+source/openstack-dashboard
<coreycb> bdmurray, that is weird, I wonder why it's valid as a target for the bug
<coreycb> bdmurray, awesome we have a bunch of bugs here too: https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard
<coreycb> bdmurray, alright let me retarget that
<bdmurray> coreycb: I think it used to be a source package
<coreycb> bdmurray, ok.  I'll chat with jamespage about it and see if we can clean things up.
<bdmurray> https://launchpad.net/ubuntu/+source/openstack-dashboard/+publishinghistory
<bdmurray> Oneiric!
<coreycb> bdmurray, that's like half an alphabet ago :)
<Unit193> ...Any chance 1562358 / 1582713 will get in through a SRU, or should I just try and backport it?
<krytarik> jbicha: Honestly, I'd just follow what the Debian policy lays out there: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
<jbicha> krytarik: since recommends are not always installed and since it's broken on MATE if the icon theme isn't installed, I believe a depends is the right choice
<seb128> jbicha, what package/what sort of breakage?
<jbicha> seb128: https://github.com/numixproject/numix-gtk-theme/issues/488
<jbicha> I'm just having numix-gtk-theme depend on numix-icon-theme
<seb128> that feels wrong
<jbicha> I could set IconTheme=Adwaita and depend on adwaita-icon-theme instead
<seb128> well, a gtk theme doesn't depends on icons
<seb128> recommends seems about righ
<seb128> right
<Unit193> Thanks, seb.
<jbicha> they used to, MATE has a lot of old tech
<roadmr> hey folks, where can I learn more about the process a package needs to go through to make it out of https://launchpad.net/ubuntu/xenial/+queue and into the archive?
<jbicha> apt depends light-themes
<jbicha> apt depends mate-themes
<nacc> roadmr: https://wiki.ubuntu.com/ProposedMigration ?
<seb128> jbicha, if you had numix-theme I would say add the depends
<roadmr> nacc: awesome! reading, thanks!
<seb128> but you have -gtk-theme
<jbicha> but it's broken in MATE, did you see the screenshot?
<nacc> roadmr: np, it links to several other pages, etc
<seb128> jbicha, broken like missing from the theme selector?
<seb128> or like not working if selected in a manual config?
<Unit193> Sounds like a but in MATE to me.
<jbicha> it looks bad in the theme selector
<seb128> well, the theme selector is only one UI
<seb128> if the gtk theme runtime is fine when manually selected then it's not a depends
<seb128> recommends as "should be there"
<seb128> are*
<jbicha> ok, how about I just change IconTheme to Adwaita and not depend or recommend on any icon theme
<jbicha> GTK3 depends on adwaita-icon-theme so it won't be broken
<seb128> wfm
<krytarik> jbicha: Well, you can still leave it set like that - Greybird does that too, for example.
<jbicha> krytarik: that's a bug for MATE users then, I recommend it be patched in Ubuntu
<elbrus> nacc: I don't know those internals of MySQL, but I guess you'll have to set a different default then?
<nacc> elbrus: yeah, i'm not sure; your cacti change did work, so maybe i'll just do that, but it seems like it shouldn't have complained at all (aiui). I'll ask rbasak  :)
<nacc> elbrus: reading the mysql pages about this, i think we just do what you did with cactui
<nacc> *cacti
<krytarik> jbicha: I see no reason to make a difference between Debian and Ubuntu there.
<ubuntu__> Does anybody know where this driver is located 0 inteldrmfb its for /dev/fb0  cann't find it under lsmod so not a module and cann't find it in kallsyms so doesn't look like its a built in kernel function so where the heck is this driving program for the framebuffer?
<nacc> ubuntu__: you've been doing this for days now. Please stop asking non-Ubuntu development questiosn here.
<nacc> ubuntu__: ask in #ubuntu or #linux
<Unit193> (##linux)
<nacc> Unit193: thanks! :)
<Unit193> Sure thing!
<jbicha> krytarik: sure, Greybird should be packaged for Debian too (in Ubuntu, it's in shimmer-themes currently) :)
<Unit193> In Ubuntu it's in the src:shimmer-themes and pkg:greybird-gtk-theme, in Debian it's in src/pkg:murrine-themes...
<jbicha> Unit193: cool, thanks for the pointer
<Unit193> jbicha: Sure, it's certainly not ideal, and I wouldn't recommend it in Debian as the last update was in June, and since then 3.20 has come out.  You have seen the Fedora patch that fixes Greybird for .20 I believe, though.  Done much testing on it?
<jbicha> no I haven't tried the greybird patch yet
<Unit193> Ah, OK.  Testing feedback could likely be useful if you were inclined, but that's more GNOME's stuff.
<krytarik> jbicha: To be clear, I'm referring to your 'Numix â Adwaita' icon theme change in Debian and back in Ubuntu - imo should be Numix in both.
<ubuntu__> well think i figured out what /proc/fb  comes from this line in kernel code  strcpy(info->fix.id, "inteldrmfb");
<ubuntu__> all leave it at that kind of a dump thing to but into inteldrmfb how does that string help anything in finding the driver and code its not any name corrosponding to anything
<jbicha> krytarik: I changed numix-gtk-theme in Debian new to just use Adwaita by default (for MATE) and not depend on any icon theme
<jbicha> and it'll be synced to Ubuntu
<ikonia> ubuntu__: you've been told - this channel is not for this discussion
<ikonia> ubuntu__: please do not start up in here after you've been told not to use this channel
<ubuntu__> but i will leave it at that i have found the built in driver code so its not an LKM  so lsmod won't list it  kallsyms has it but as   intelfb_create the real name for it . And this is where i stop thanks  goodbye
<nacc> rbasak: elbrus: alright, bacula-director-mysql does install now (my last test build), but does require mysql-server to be fully installed & configured first (ordering isn't working if installed as part of the bacula install)
<nacc> rbasak: should we pre-depend on mysql-server?
<nacc> rbasak: in the bacula pacakge, that is
<elbrus> nacc: the issue with MySQL (and other databases) is that it may not be running on the same host
<elbrus> so if you add a (pre) depends, you are annoying admins that don't want the MySQL server on the same host
<nacc> elbrus: oh right, you mentieond this, sorry!
<nacc> elbrus: yep, and i think that's why the ubuntu wiki specifically mentions having the sql server alrady configured
<elbrus> that is why in general packages that need MySQL have dependecies on the client, but not on the server
<nacc> right, makes sense
<nacc> elbrus: well, i think bacula with these 3 changes is in a much better state; continuing to debug the remaining bugs
<elbrus> unfortunately, the Debian dependency system does not facilitate this
<nacc> elbrus: yep, understood (or learning to understand.. :)
<elbrus> one of the reasons why dbconfig-common exists...
<elbrus> to make sure that packages don't need to invent this all
<elbrus> again and again
<elbrus> it isn't easy
<nacc> yep, i am learning that! :)
<elbrus> also dbconfig-common doesn't get it all correct
 * elbrus tries to still fix some difficult bugs before the next Debian release
<nacc> elbrus: thanks for all your help, again!
 * elbrus is off to bed...
<nacc> Pharaoh_Atem: can you take a look at LP: #1571436 ?
<ubottu> Launchpad bug 1571436 in wordpress (Ubuntu Xenial) "Needed update to nginx example config file due to dependency change" [Low,Triaged] https://launchpad.net/bugs/1571436
<nacc> teward: --^ maybe you too
<teward> nacc: that's a Universe package right?
<teward> !info wordpress xenial
<ubottu> wordpress (source: wordpress): weblog manager. In component universe, is optional. Version 4.4.2+dfsg-1ubuntu1 (xenial), package size 3403 kB, installed size 16968 kB
<nacc> teward: yeah :)
<nacc> teward: feel free to say no :)
<teward> take a torch to it
<teward> and burn the package with flame
<teward> 4.4.2 is ancient
<teward> at least according to WP
<teward> riddled with many security holes
<teward> 4.5.3 is latest
<teward> and between 4.4.2 and 4.5.0 i think there were six security patch updates?
<teward> foo i broke my fileshares
<teward> nacc: probably an easy fix... if someone goes and looks at the example php-fpm configs in the nginx package currently
<teward> or my blog for that matter
<nacc> teward: yes, well, i'll probably sync it for yakkety
<teward> nacc: http://dark-net.net/?p=125
<nacc> teward: but our goal should be working packages, even if they are out of date (or so it seems)
<nacc> teward: thanks, i'll refer to it
<teward> nacc: true, but i'm not going to go poking every php package that happens to break OOTB when nginx isn't even listed in rdepends
<teward> (for either suggest or recommends)
<teward> nacc: fastcgi_pass unix:/run/php/php7.0-fpm.sock;  <-- socket for the conf file
<nacc> teward: ack, hence you can say no :)
<teward> nacc: i'm not touching it
<teward> :P
<teward> Pharaoh_Atem: ^ if you want to, you can refer to the nginx default conf currently, or the blog post I linked (http://dark-net.net/?p=125), it's the migration that broke it :)
<teward> (from 5.x -> 7.0)
#ubuntu-devel 2016-06-24
<mwhudson> can anyone explain to me why golang-defaults is not migrating? http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html
<infinity> mwhudson: Yes.
<mwhudson> infinity: do you think they could manage to do so?
<infinity> mwhudson: Absolutely.
<infinity> mwhudson: It's amazing the sorts of things people are capable of.
<mwhudson> infinity: i'm bored of this game now
<infinity> mwhudson: (What that's trying to tell you, but poorly, is that golang-any-shared-dev is in main, but golang-any is in universe, which I've now fixed)
<mwhudson> infinity: aaaah
<infinity> mwhudson: See the "binary only movements to main" section in http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<mwhudson> what, how did that happen? golang-any being in universe?
<mwhudson> was it just left out when the rest of the binary packages were moved?
<infinity> mwhudson: Because it was always in universe (had no rdeps in main), but a new main package now depends on it.
<mwhudson> oh ok
<infinity> http://www.bbc.com/news/politics/eu_referendum/results is not filling me with glee.
<mwhudson> i'd definitely be being more productive if that was going better :(
<ScottK> Looks like I should have shorted the pound.
<xnox> FUCK
<xnox> Yakkety Yak
<Unit193> Don't talk back.
<chiluk> xnox you had better have voted.
<xnox> i have
<chiluk> damn 71.8% turnout... crap, we only get that kind of turnout for the superbowl!
<chiluk> xnox infinity is archive.ubuntu.com abnormally slow right now or is it just me?
<pitti> Good morning
<infinity> pitti: It's a dark, sad morning.
<pitti> infinity: yeah, was just reading the news :(
<pitti> go populism
<infinity> http://finance.yahoo.com/echarts?s=GBPUSD%3DX+Interactive#{%22range%22:%225d%22,%22allowChartStacking%22:true}
<infinity> Good day for a trip to the UK.
<Skuggen> Hehe, yeah. Wonder how this will turn out
<juliank> infinity: next days might be cheaper, unless parliament suddenly votes to stop the brexit
<juliank> Let's wait until it hits $1
<juliank> (it was at $1.50 yesterday, now it's at $1.36)
<juliank> or a "let's ask again, the vote was too close"
<maswan> well, they overrode the Boaty McBoatface vote, surely the ycan override somethig with this thin margin
<Skuggen> They've declared this will be binding, though
<xnox> oh shit
<xnox> apperantly cameron might resign in a minute.
<sil2100> eh
 * xnox wants to move to scotland
<xnox> sil2100, good morning brexit =) GBP is down to 1985 value
<RAOF> xnox: Before they secede? âº
<xnox> he emerged from Nr 10
<xnox> listining now.
<xnox> rehearsed speech, very monotonic.
<xnox> no immediate change to the eu freedoms
<xnox> resigning, no later than October ~= 3 months.
<xnox> oh and he spoke to the queen this morning. Knock Knock at 4am, lol =)
<juliank> xnox: You have two years (max) to move to Scotland, start preparing
<juliank> That's how long there can be exit negotiations.
<Skuggen> Unless they delay handing in their exit notice
<juliank> Two years after a request to leave, you're out.
<juliank> Skuggen: yep
<Skuggen> So I suspect they won't do that until Cameron is gone, at least
<juliank> They need to negotiate a deal first, otherwise their position is far too weak
<RAOF> How does that improve their negotiating position? Their position *is* far too weak.
<pitti> Skuggen: no, it's not legally binding -- but of course it is practically
<pitti> Cameron called for this referendum, he cannot in good faith ignore it now
<juliank> RAOF: Once they invoke article 50, they *have* to leave within 2 years, regardless if anything was negotiated.
<juliank> So, the EU could just say no to everything, the UK gets nothing, and still has to leave, which they surely don't want.
<RAOF> juliank: So the negotiating position is âif you don't give us a good enough deal, we won't leaveâ?
<Skuggen> pitti: Well, he's kind of just dumping the result on his successor :)
<Skuggen> The UK is a big economy, so the EU will still want to deal with them
<juliank> RAOF: That makes sense. The UK can just block or delay decisions now in the EU to get what they want
<Skuggen> If they give notice, they lose voting rights
<juliank> No, only on their exit deals
<RAOF> juliank: Oh! So the negotiating position is âif you don't give us a good enough deal, we'll deliberately destroy the EU from withinâ? Also a winning negotiating position âº.
<juliank> That's their only option.
<juliank> It'll be interesting to see if northern ireland and scotland will leave the UK
<maswan> I hear irish unification has gotten a big push now
<juliank> One Ireland
<juliank> Re-uniting Ireland would be easier than establishing an independent Scotland.
<Skuggen> Maybe Scotland can join Ireland too :D
<Skuggen> The Irish Isles!
<juliank> Sinn FÃ©in already demanded a unity voite
<juliank> s/voite/vote/
<juliank> One things for sure: If Scotland leaves the UK, the current Doctor will be the last Scottish one
<rbasak> nacc: so what would be the consequences of not pre-depending? I think we need to engineer things (in Ubuntu and also Debian) so that the maintainer scripts do not fail if the ordering is off.
<elbrus> rbasak: please read my response: the MySQL server may be on a different host
<rbasak> elbrus: yeah, I get that part.
<rbasak> elbrus: but if it is on the same host, the maintainer script should still not fail.
<elbrus> it "doesn't"
<rbasak> That's fine then :)
<elbrus> it will ask the admin how to resolve the situation
<elbrus> so doesn't fail unless the admin wants that
<rbasak> OK that sounds good.
<elbrus> and in non-interactive mode it never fails
<elbrus> at least: that is the design
<elbrus> or I should say, it fails, but the admin can opt-out of failure
<rbasak> That may lead to excessive bug reports. We essentially get an automated bug report for every maintainer script failure.
<elbrus> you then already have them.
<rbasak> Though if there's something in the report that allows us to detect the reason (eg. a stderr string) we can redirect the report to an existing bug, such as one marked Invalid with an explanation.
<elbrus> this behavior exist for > 10 years
<elbrus> and yes, the error is always reported
<pitti> xnox, tinoco: this time aupkg01 (10.100.0.12) went AWOL; I think/hope I installed kdump on both (so far .13 was the problem child), could you please have a look?
<tinoco> pitti: hopefully kdump worked this time
<tinoco> pitti: i'll have to install 3270 on the machine i am right now
<tinoco> it will take sometime to reboot it (fyio)
<Saviq> pitti, hey, any idea about why my ttys would become empty after a while after boot (maybe after suspend/resume or something)? do you know if there's a bug filed?
<xnox> bdmurray, pitti, arges, slangasek - althrough d-i in xenial-proposed is now validation libdebian-installer for the bug 1582320 is not. Once that is validated d-i can be released.
<xnox> s390-tools is now validated please release that.
<ubottu> bug 1582320 in libdebian-installer (Ubuntu Xenial) "libdebian-installer uses a different detection method for EFI than efivar" [Critical,Fix committed] https://launchpad.net/bugs/1582320
<xnox> cause i need to do s390-tools SRU + d-i again now for the now resolved FBA bug =)
<xnox> bug #1582320
<Saviq> seb128, any idea why this is still stuck in proposed https://requests.ci-train.ubuntu.com/#/silo/41 ?
<Saviq> all of them are Valid candidates
<seb128> Saviq, seems like they went through in the previous publisher according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<seb128> Saviq, is there a specific package you were looking at?
<Saviq> seb128, just waiting for this silo to land
<seb128> Saviq, I think it's in transit, wait a bit and it should be good
<Saviq> seb128, ack
<Saviq> thanks
<Saviq> yup, it's merging right now :)
<seb128> great
<semiosis> i just proposed a merge for bug 1565985.  i'll be around for the next several hours if anyone wants to review/discuss it.  thank you.
<ubottu> bug 1565985 in livecd-rootfs (Ubuntu) "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,Confirmed] https://launchpad.net/bugs/1565985
<pitti> Saviq: "empty"? no, no idea; maybe they don't survive a suspend, I never checked TBH
<Saviq> pitti, yeah just black
<Saviq> pitti, anything I could restart to see if they come back? neither console-getty or system-getty seem to be running according to systemctl status
<Saviq> and I do have the console right no
<Saviq> w
<Saviq> http://pastebin.ubuntu.com/17801155/
 * Saviq suspends
<Saviq> hmm now the prompt is there, but all of them say tty1 and I can't type anyway
<Saviq> so they're stuck
<Saviq> restarting system-getty.slice didn't help (right, it's a .slice, that's why systemctl status wasn't doing well)
<seb128> Saviq, pitti, I had a similar issue on thursday, my vt1-6 had no login prompt until I rebooted (xenial)
<Saviq> ok /me files a bug
<seb128> thanks
<seb128> btw did you get the lockscreen issue since yesterday?
<pitti> Ã§a va seb128 !
<seb128> pitti, oui, et toi ?
<pitti> seb128: too much sad politics today and it's utterly warm, but otherwise okay :)
<seb128> yeah, don't have election results on trollday :-/
<Saviq> seb128, pitti, bug #1595963
<ubottu> bug 1595963 in util-linux (Ubuntu) "vt1-6 getting stuck or blank" [Undecided,New] https://launchpad.net/bugs/1595963
<pitti> probably more likely to be a systemd/kernel issue, but I'll look at that; thanks for the bug report
<seb128> Saviq, thanks
<Pharaoh_Atem> teward: ?
<nacc> rbasak: yeah, i'm still trying to understand exactly what should happen/ when it works/doesn't work.
<nacc> Pharaoh_Atem: there was a bug we were discussing, LP: #1571436
<ubottu> Launchpad bug 1571436 in wordpress (Ubuntu Xenial) "Needed update to nginx example config file due to dependency change" [Low,Triaged] https://launchpad.net/bugs/1571436
<nacc> Pharaoh_Atem: fpm configuration / documentation
<Pharaoh_Atem> ah
<Pharaoh_Atem> I didn't know we even shipped any nginx configs in Ubuntu
<nacc> Pharaoh_Atem: i think it's an example config
<Pharaoh_Atem> ah
<nacc> Pharaoh_Atem: may not be something super urgent, but if you could glance, see if it's reasaonble to fix (might need fixing in Debian too) and let me know, that'd be great
<Pharaoh_Atem> nacc: sure
<Pharaoh_Atem> chances are good it probably needs fixing in Debian
<pitti> doko: http://launchpadlibrarian.net/267449474/bash_4.3-14ubuntu1.1_source.changes â please build Ubuntu uploads with the ubuntu dpkg-source
<slangasek> xnox: bug #1582320> test case is in the bug, perhaps you can run it?
<ubottu> bug 1582320 in libdebian-installer (Ubuntu Xenial) "libdebian-installer uses a different detection method for EFI than efivar" [Critical,Fix committed] https://launchpad.net/bugs/1582320
<xnox> slangasek, let's see if i can do that on the running system.
<jbicha> nacc: for bug 1582340, do you want me to go ahead and add the php-xml dependency?
<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
<jbicha> and since I'm doing that, I might as well pull in 7.44 too for xenial?
<nacc> jbicha: yeah, i guess that's probably reasonable; i['ll work on the php7 issues right after i finish fixing/testing bacula
<slangasek> pitti: why is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/o/openafs/20160624_174535@/log.gz (linked from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb for the moment) not listed on http://autopkgtest.ubuntu.com/packages/o/openafs/yakkety/armhf/ ?
#ubuntu-devel 2016-06-25
<Logan> nacc: you might be interested in Bug 1571534 (not that you don't probably already have enough on your plate :P)
<ubottu> bug 1571534 in zabbix (Ubuntu) "PHP Fatal error in zabbix-frontend-php" [Undecided,Confirmed] https://launchpad.net/bugs/1571534
<abhishek> hi
<abhishek> Stuck at this bug, please help. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1588428
<ubottu> Launchpad bug 1588428 in linux (Ubuntu) "PCI bus error on startup while booting into login screen (Kubuntu 16.04)" [Medium,Confirmed]
<infinity> xnox: Grr, you didn't commit your d-i upload.
 * infinity amends history a bit.
<ScottK> Apparently lots of people would like to do that today.
<sladen> mmmm
<teward> Pharaoh_Atem: wrt https://launchpad.net/bugs/1571436 it's a documentation-example-shipped NGINX config that doesn't work out of the box.  Nothing PHP in the repos that I'm aware of default-installs to an nginx directory
<ubottu> Launchpad bug 1571436 in wordpress (Ubuntu Xenial) "Needed update to nginx example config file due to dependency change" [Low,Triaged]
<teward> ssory for a real late reply to your ping, I saw nacc followed up but I got busy :p
<infinity> ScottK: I'm keen on rolling back 2016 en toto.  It's not been a winner so far.
#ubuntu-devel 2016-06-26
<Unit193> infinity: Looking forward to the American election too, eh?
<teward> for my own reference, if I update a package in the repositories that another relies on, and the package that relies on mine depends on it, how would a rebuild be issued, or what would be the most sensible way to approach that?  Hypothetically.
<infinity> teward: Why would a rebuild be necessary?
<infinity> teward: Are you talking an SONAME bump in a library, or similar?
<infinity> teward: Anyhow, if there's a library transition in play, you do something like "pull-lp-source foo && cd foo-* && dch -R", enter a changelog entry like "Rebuild for the libbar transition.", and upload.
<infinity> teward: But first, I'm curious about specifics, rather than hypotheticals.  We don't rebuild rdeps unless there's a reason.
<teward> infinity: with regards to https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-June/016654.html, https://lists.ubuntu.com/archives/ubuntu-server/2016-June/007360.html, and https://lists.ubuntu.com/archives/ubuntu-server/2016-June/007361.html
<teward> infinity: basically, it's on the discusison list - if there is a package with a .so dynamic module built against 1.10.1 and we release 1.10.2 for bugfix/security reasons, a package with the .so dynamic module would need a rebuild
<teward> reading up on the thread may make the reasoning more clear?
<teward> more or less to try and understand weird edge cases
<teward> granted, i've not yet merged in Debian's dynamic module handling yet, which might be a pre-req
<teward> rbasak: fyi ^
<infinity> teward: Having the server ABI tied to version is madness.
<teward> I told nginx upstream their dynamic modules approach doesn't work well in downstreams
<infinity> teward: But, if we're stuck with that for now, then any rdeps in the archive would need a rebuild on upgrade, yes.  And they better have proper dependencies based on some nginx-signature-12345 provides or something.
<teward> got a reply "Yeah we know, we'll work on it but it's not a short-term goal"
<infinity> teward: It's not hard to fix.  All they need is an ABI tracker that bumps signature if and only if the ABI breaks.  Which means some rebuilds, but not on every version.
<infinity> (This is basically the PHP approach)
<infinity> teward: Anyhow, does nginx actually have rdeps in the archive right now?
<teward> infinity: for now, no.  come next LTS, probably.
<teward> or sooner, if people start putting things into Debian for third-party modules
<infinity> So, let's solve this properly before then.  For both Debian and Ubuntu.
<infinity> Modules need to have a specific exported ABI to depend on, so they don't have to depend on nginx (>> foo), nginx (<< bar) | nginx-foo (<< foo) ...
<infinity> You can see how that gets ugly quickly.
<teward> indeed
<teward> I think this is something that should be deferred until nginx can fix things?
<teward> because the way they've got things done, at least AIUI, there's no ABI-based handling
<infinity> You can fake one.
<teward> infinity: guidance on that would be appreciated
<infinity> Remind me when it's not... Today.
<teward> works for me :)
 * teward looks back at the nagios page saying all his Ubuntu Server VMs are down, and figures he should probably fix them instead of worrying about nginx :P
<teward> (at least for right now)
<infinity> teward: As for upstream, they need to track ABI, but what they do with that information is another question.  They *could* export an ABI define somewhere, that people could test against.  Or, they could go the sane route, and promise ABI stability in a major.minor (or even just major) series.
<infinity> teward: The latter would be much better, but it means checking for ABI breaks in upstream commits and blocking them or backing them out of people oops.
<infinity> s/of people/if people/
<teward> infinity: I think ABI breakage is more prone in mainline (1.9.x as an example) than 1.10.x which basically doesn't change once released
<infinity> Well, "basically doesn't change" isn't a promise. ;)
<teward> except for bug fixes, and I think that nginx is smart enough to make notices about it
<teward> well, with dynamic modules being a 'new' thing with 1.9.x, 1.10.x, I think they'd put "This may break third party dynamic modules" over the lists i'm on
<teward> and that'd prompt the need to poke rebuilds or 'fake' an ABI change
<infinity> Not if the ABI signature checked at load time is based on the version, they won't. :P
 * teward yawns
<infinity> Cause, in their mind, they break modules regardless.
<teward> infinity: I get what you're saying, i'm basically dead here.
<infinity> Anyhow.  Another time.
<teward> um, clarify "they"
<teward> there's nginx upstream, Google PageSpeed upstream, and us :p
<infinity> They, upstream.  They're not going to inform you if a change may break modules, because their "ABI" breaks on every version change anyway.
<teward> (there's two upstreams)
<infinity> nginx upstream. :P
<teward> :P
<teward> well
<teward> i have an evil painful workflow that I currently do for a few home-grown packages which depend on others
<teward> basically a shell script that builds one, pulls in for the build env on a separate package, and tests.
<teward> but eh
<infinity> We can talk more later.  I have a hot date with a shawarma.
<teward> could potentially adapt, but CBA to bother now
<teward> heheheh, enjoy infinity
<teward> i'm going to go find coffee...
<teward> and fix my servers... (I think the hypervisor powercycled...)
#ubuntu-devel 2017-06-19
<KurousagiMK2> Hi to all. I have a problem when updating dbus https://paste.ubuntu.com/24895832/ it should be?
<jbicha> KurousagiMK2: you probably should not have proposed updates enabled during the development cycle
<jbicha> but thanks for mentioning the issue, it should be fixed soon
<jbicha> https://launchpad.net/ubuntu/+source/dbus/1.10.18-1ubuntu2
<KurousagiMK2> no problem
<pitti> jbicha: argh, again? I just fixed it for 1.6
<pitti> jbicha: ah, seems to be simple enough, but a bit awkward as the type is version specific
<infinity> jbicha: They don't have both installed...
<infinity> jbicha: Unless you mean gcc-7-base, which isn't gcc-7 at all.
<infinity> jbicha: And gcc-7-base is there because gcc-7 builds libcc1, libstdc++6, etc.
<pitti> jbicha: fixed in https://github.com/martinpitt/python-dbusmock/commit/763d0b3 and I also added a G_DEBUG=fatal-warnings,fatal-criticals
<rbalint>  jamespage: thanks!, merged
<cpaelzer> pitti: does the cockpit i386 test timing out after Barney BÃ¤r ring a bell ? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/i386/c/cockpit/20170619_084158_c430e@/log.gz
<cpaelzer> I don't think I could have affected this particular test, but at least 2/2 retries now blocked on that
<cpaelzer> pitti: starting local repro now, but if something seems to be a known issue to you let me know
<sil2100> smoser: hey!
<sil2100> smoser: I'm reviewing curting right now for xenial and I see it has a change to the new-upstream-snapshot script that's not in any other series - was wondering why is that so?
<sil2100> smoser: is the tarball only removed on file cleaning on xenial?
<pitti> cpaelzer: hm no, I haven't seen this before
<cpaelzer> pitti: thanks for the reply, I'll let you know what I find debugging this
<pitti> cpaelzer: consistently only on 32 bit?
<cpaelzer> I didn't rerun the others that worked
<cpaelzer> but I had it locally with adt on 64 bit
<pitti> cpaelzer: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/c/cockpit/20170615_142334_6e4d7@/log.gz looks similar, so smells like a race, not a regressino
<cpaelzer> I'm currently trying to identify if it is 100% repro locally and if so what change it could have been
<cpaelzer> yeah that looks the same, that was network manager  ... hmm
<sil2100> chrisccoulson_: hey! Just a quick question - the firefox armhf FTBFS is a known issue I guess, right? Is there a bug for that one?
<sil2100> chrisccoulson_: I see all the SRUs were released with the build failure so I assume it's known and identified, just wanted to get some context
<pitti> jbicha: 0.16.9 now released and uploaded to debian, so it should clear itself up from here on
<cpaelzer> pitti: it was a transient issue after all, but with a >50% hit rate at the moment as it seems
<pitti> cpaelzer: http://autopkgtest.ubuntu.com/packages/c/cockpit/artful/amd64 looks much better than 50%, but indeed as I said this isn't new
<pitti> so retry button short-term for unblocking
<cpaelzer> yeah that is what i have chosen for now
<pitti> I'll try to reproduce it and see what's wrong
<cpaelzer> pitti: maybe scalingstack is busy atm and this increases the chance
<cpaelzer> locally I'm pretty much swapping 2-3G already - so when I say reproducable locally it is under constrained conditions
<jbicha> pitti: thank you! btw, autosync from sid seems a bit delayed, probably because of the stretch release and so on
<pitti> jbicha: at least dbusmock isn't the final/only blocker of NM :)
<jbicha> pitti: are you partially responsible for nplan's flaky tests too? ;)
<pitti> not any more :)
<pitti> they were quite robust when I handed stuff over
<jbicha> http://autopkgtest.ubuntu.com/packages/n/nplan/zesty/amd64
<jbicha> I think they've always been flaky, at least on a.u.com
<jbicha> it does look like they were less flaky in December, convenient! ;)
<seb128> wgrant, hey, when do you think we can get artful open for translation on launchpad?
<seb128> jbicha, ^
<cjwatson> jbicha: Should start in a few hours.  It was delayed because of needing to upgrade debian-archive-keyring before it could verify the signature on dists/stretch
<cjwatson> stgraber: Is there some way to ask lxd to abort an image download in progress, or do I have to restart the daemon?
<jbicha> cjwatson: thanks!
<cpaelzer> jamespage: would you mind looking at http://paste.ubuntu.com/24899381 for a short review before I upload?
<cpaelzer> jamespage: the openvswitch-testcontroller dependency is still needed in the test, it really is about stopping the default service to avoid conflicts
<xnox> juliank, reading https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863859 does this mean unattended-upgrade needs to grow more options?
<ubottu> Debian bug 863859 in apt "apt: runs unattended-upgrades in debug mode" [Normal,Fixed]
<xnox> and we need to sru them?
<juliank> xnox: Yes, one additional option, but it's a tiny change. If we don't apt downloads upgrades in the install service, rather the download service
<juliank> xnox: We could have used the apt dist-upgrade -d code path, but that might have downloaded updates that were not going to be installed with unattended-upgrades anyway.
<juliank> xnox: There's a patch somewhere
<xnox> hm.
<xnox> imho dist-upgrade -d would have been fine.
<juliank> xnox: It's a tiny diff: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=863911;filename=unattended-upgrade.diff;msg=5 - in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863911
<ubottu> Debian bug 863911 in unattended-upgrades "unattended-upgrades: Needs a --download-only mode" [Important,Open]
<juliank> xnox: The diff contains the change twice, because symlinks...
<juliank> That said, the changes are independent, so we can go ahead with one without the other
<xnox> yes and no.
<xnox> we want an sru of everythings to solve everything =)
<jamespage> cpaelzer: +1
<juliank> xnox: Well, at least the change is just three logical lines long :)
<juliank> It's literally just an early exit
<juliank> xnox: I wasn't not sure if we want to split the unattended-upgrade part into its own bug RE bug verification, I think I asked that a few weeks ago
<xnox> juliank, i'm ok with a massive bug, then again i'm not ~ubuntu-sru team member.
<xnox> juliank, bdmurray can advise as to how to keep him sane =)
<juliank> I think we left sane territory a long time ago
<nacc> slangasek: looks like we should have synced on python-django's merge :) LP: #1605278
<ubottu> Launchpad bug 1605278 in python-django (Ubuntu Artful) "Merge python-django 1:1.11-1 from Debian unstable" [Wishlist,In progress] https://launchpad.net/bugs/1605278
<doko> jbicha: they don't, unless you b-d on gcc-7 explicitly
<jbicha> ok, it's just confusing right now, looking at the build logs
<slangasek> nacc: ah hmm. I picked it off because it was blocking other packages in proposed-migration; 1.11 has been pushed to unstable now and should be an easy sync.  But why are django syncs blocked by maas? I see no failing autopkgtests
<elopio> infinity, sil2100: can one of you let snapcraft and click into -updates please?
<nacc> slangasek: functionality not reflected in a dep8 test :/
<sil2100> elopio: which series?
<nacc> slangasek: they use it and when django updates, their UI breaks :)
<elopio> sil2100: xenial, yakkety and zesty.
<sil2100> hm, I don't remember seeing it as ready when I was scanning pending today
<slangasek> nacc: so... when are they adding dep8 tests for this?  roaksoax
<sil2100> elopio: was it recently verified?
<elopio> sil2100: I marked snapcraft verified yesterday. I've just marked click.
<slangasek> nacc, roaksoax: because the last delta that was still there when I did the merge is unexplained and serves no purpose I can discern, so this *almost* became a sync, and then what would we do?
<sil2100> elopio: is there any exception for snapcraft? Since it's not aged for 7 days yet
<sil2100> Same for click
<nacc> slangasek: :) right, that's why i haven't merged it since I started :)
<sil2100> elopio: for almost all packages there's a usual 7-day aging period in -proposed after which we release the update to users
<nacc> slangasek: openstack also has dependencies not reflected in dep8 tests, i believe, and jamespage already tested 1.10 (still waiting on testing on 1.11)
<sil2100> I never released snapcraft or click before so I don't know if there's some special case here? Was it usually released earlier?
<elopio> sil2100: we have an exception for snapcraft: https://wiki.ubuntu.com/StableReleaseUpdates#Snapcraft
<sil2100> elopio: ok, see it being mentioned that it can be released earlier
<elopio> sil2100: we don't have one for click, but the change is only a rename on the python package, and I've tested both for more than 7 days now. It would be great if we could land it soon.
<sil2100> elopio: I'll release the snapcraft one and look at click, but considering the lack or real consumers of that package I might just release it as well
<slangasek> sil2100: nack, click has to be released *first*
<sil2100> slangasek: snapcraft depends on it?
<slangasek> the click rename is done so that the snapcraft upgrade doesn't go pear shaped
<slangasek> the snapcraft SRU introduces a dep on the /other/ click; the move of the python module in click is so we can lift the conflicts, so that upgrades will work for people who have click installed
<sil2100> Ah, ok, so there's a dep change in snapcraft too, makes sense
<sil2100> elopio: btw. the zesty autopkgtest snapcraft regressions are known?
<elopio> sil2100: all the failures I looked at were because the proxy was not working nicely. Which one are you looking at?
<sil2100> elopio: the zesty ones, there's a lot of failures, indeed from the logs I see those are network errors - please make sure to re-run them in this case so that we make sure they're passing
<sil2100> Like, in the future I mean
<elopio> sil2100: we run them in the pull request, and don't proposed until we are sure there are no test regressions in x, y, z and a.
<elopio> last week it was hard, but we got all greens.
<sil2100> Ok, hm, I also see ubuntu-image autopkgtests in zesty failed with the new snapcraft, looks like some of our unittests failed, looking into that
<elopio> Not all at the same time, because the proxy was not happy. But all good there.
<sil2100> Those could be because of networking, but hm, not entirely straightforward from the logs as those are our unittests failing
<sil2100> Looks unrelated to snapcraft anyway
<sil2100> elopio: for click, could you also verify/find someone to verify https://bugs.launchpad.net/ubuntu/+source/click/+bug/1696402 ?
<ubottu> Launchpad bug 1696402 in click (Ubuntu Zesty) "chroot configuration strictly depends on overlayfs" [Undecided,Fix committed]
<sil2100> elopio: looks like the yakkety and zesty click updates also had this fix in them
<sil2100> I don't want to release something without any testing
<sil2100> elopio: actually, since the autopkgtests passed, I'll just mark it as verified myself
<elopio> sil2100: ah, right. I keep forgetting about that one. I already verified everything last week. I was just waiting for today, in case somebody else wanted to give it a try. That one in particular is just a test fix, so we checked that the tests are green.
<elopio> sil2100: I don't see how those unit tests of ubuntu-image are related to snapcraft.
<sil2100> elopio: yeah, true, just be sure to poke people to re-run or investigate any test failures and document them on the SRU bugs
<elopio> sil2100: do you know who is in charge of ubuntu-image now?
<sil2100> elopio: me and slangasek basically
<sil2100> elopio: now that I know about this I'll investigate tomorrow
<sil2100> ;)
<slangasek> I've just retried that failed ubuntu-image test; the errors don't make sense, it could be test runner flakiness
<sil2100> Yeah, most probably, although I've never seen those to be flaky, which made me a bit worried
<sil2100> Still, not related to snapcraft
<sil2100> elopio: anyway, done
<elopio> sil2100: :D thank you!
<elopio> thanks everybody who helped here. It was a long journey.
<sil2100> yw! :)
<stgraber> cjwatson: you have to restart the daemon. We have a pull request currently in flight which adds the ability to cancel background operations, so LXD 2.15 or 2.16 should finally let you cancel those with a good old ctrl+c.
<cjwatson> brilliant, thanks
<cjwatson> yeah, I restarted lxd in the end and it recovered
<jbicha> yay, autosync from sid :|
<jackpot51> How would this be rolled out? It appears that gnome-control-center depends on it
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<jbicha> slangasek: I'm going to do a libepc upload today, is "Ubuntu Developers" ok for the maintainer?
<jackpot51> How does this look - GNOME initial setup with encrypted home: http://imgur.com/a/Bbzp2
<jackpot51> It has been themed, but that is not part of the change ;)
<slangasek> jbicha: glom is Ubuntu Desktop Team; is that appropriate for libepc as well?  Because I don't think saying 'ubuntu-devel' is the maintainer is in practice much of a committment
<jbicha> jackpot51: It may be a little more complex, but what about moving the Encrypt Home switch to the Privacy page?
<jbicha> slangasek: thanks, I'll ask the Desktop Team tomorrow if they're ok with that then
<jackpot51> No, I can't really do that simply.
<jbicha> ok
<jackpot51> The issue is that the setting is utilized when adduser is called, or immediately after. I could move it to the password page, or leave it on the account page
<jbicha> I think the Privacy page comes first so it might still be doable, just more complicated
<jbicha> I believe the order is at https://git.gnome.org/browse/gnome-initial-setup/tree/gnome-initial-setup/gnome-initial-setup.c#n67
<jbicha> (some pages are skipped in some modes)
<jackpot51> I need to work on the implementation as well - so maybe come back to where it should be?
<acheronuk> mapreri: you about?
<acheronuk> https://launchpad.net/ubuntu/+source/libkf5kface/16.12.3-0ubuntu2
<acheronuk> changes like that, could you maybe let kubuntu know when such uploads happen on our packages?
<Laney> I don't think glom should be maintained by the desktop team
<acheronuk> we keep our packaging in git, and use automation tools to do application uploads, so unless we know of and incorpoate such changes, they might get lost in our next apps release upload
<acheronuk> think there is some scripting in the pipeline to check consistency against the archive to catch stuff like that, but not implemented quite yet
<acheronuk> clivejo: read up ^^^ ;)
<jbicha> slangasek: what if the Desktop Team doesn't want to be listed as the glom maintainer either?
<slangasek> jbicha: well, then why would glom be kept in the archive either if they're not willing to maintain its dependency?
<slangasek> jbicha: perhaps listing ubuntu-desktop as maintainer of glom is also a bug; if there is some other team that is going to maintain both glom and libepc, that's fine too
<jbicha> glom is probably maintained about as well as anything else in universe
<jbicha> meaning the packaging itself is pretty good but nobody reads the bug reports (but upstream is subscribed :) )
<mapreri> acheronuk: yap
<mapreri> sorry, missed the highlight
<nacc> cyphermox: fyi, i'm very close to having isns upstream dep8 tests
<cyphermox> nacc: cool, thanks for the update
<cyphermox> I'm trying to figure out why ubiquity isn't removed from the desktop image after install, and kinda stumped
<nacc> cyphermox: in all releases?
<cyphermox> just in the artful desktop images
<cyphermox> it's a side-effect of some of the changes in livecd-rootfs, but not sure yet how to fix it, things looks like they "should" work
<jackpot51> jbicha: I have a patch for gnome-control-center and gnome-initial-setup to add encrypted home, but it requires a breaking API change for accountsservice
<jackpot51> What should I do?
<jackpot51> ls
<mapreri> Unit193: care to send https://bugs.launchpad.net/bzr-fastimport/+bug/1014291 debian's way at least?
<ubottu> Launchpad bug 1014291 in bzr-fastimport (Ubuntu) "Export from bzr / Import to git results in a deleted file re-appearing" [Undecided,New]
<mapreri> acheronuk: ah, and now I read that you actually wrote something after a pingâ¦
<Unit193> mapreri: That's to say, I looked for it and didn't see the Ubuntu one, just where I went upstream and had also poked bzr/Debian maintainers, so thanks for asking.  I mean I suppose I could look into it, not had the best of luck with him in the past...
<jbicha> jackpot51: open an Ubuntu bug with the attached patches and then you can ping the Desktop Team during Europe work hours
<mapreri> acheronuk: ack, I'll notify you next time.  FWIW, I also uploaded digikam, you might want to sync that too.
<mapreri> acheronuk: even if "you"â¦ where should I go write, evenâ¦
<jbicha> jackpot51: there's a bzr branch https://code.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/ but I don't think Initial Setup or accountsservice are currently in a VCS
<mapreri> acheronuk: I can dump a line #debian-qt-kde @ oftc, dunno whether that's what you mean
<mapreri> Unit193: I know what you meanâ¦  but still, I'd try to file a bug with the patch, could also happen you catch him in a moment he is bored and he just upload itâ¦
<mapreri> acheronuk: actually, I'm happy to work on git myself, if you can point me at those git repos (for the next time I'll have upload something like that).  Also, are you interesting in having those commits for no-change rebuilds?
<bdmurray> sarnold: I heard you had some questions about some openssl apport-package bug reports. Could we look at one together?
<sarnold> bdmurray: sure
<bdmurray> Do you have one at hand?
<sarnold> bdmurray: here have thirty :) https://bugs.launchpad.net/ubuntu/+source/openssl/+bugs?orderby=-date_last_updated&start=0
 * bdmurray drowns
<sarnold> this one's in english https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1698113
<ubottu> Launchpad bug 1698113 in openssl (Ubuntu) "package libssl1.0.0:i386 1.0.2g-1ubuntu4.6 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration" [Undecided,New]
<bdmurray> so the DpkgTerminalLog.txt shows it being a follow up error
<bdmurray> and DpkgHistoryLog.txt shows openssl first being upgraded on 2017-06-13
<sarnold> I think the ones I inspected looked similar
<bdmurray> apport trims DpkgTerminalLog.txt to the most recent package activity so we don't have a log of what happened on 2017-06-13
<bdmurray> You could ask the reporter for their log dpkg log file which covers that period.
<bdmurray> Or search to see if the reporter reported other reports. Roger?
<sarnold> bdmurray: is this one a 'live' bug? https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1696799
<ubottu> Launchpad bug 1696799 in openssl (Ubuntu) "package libssl1.0.0:i386 1.0.2g-1ubuntu4.8 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration" [Undecided,Confirmed]
<sarnold> that one's got some unfortunate bleachbit nonsense that makes me want to disregard the bug entirely, but its log does include "Preparing to unpack ..."
<bdmurray> sarnold: the dpkghistorylog.txt shows an upgrade of openssl and then later "apt-get -f install ..." so no "not live"
<sarnold> :(
<bdmurray> I'd expect some dpkg bug reports given "Error: Sub-process /usr/bin/dpkg exited unexpectedly"
<sarnold> the dpkg bug list is overwhelmed with the "is already installed and configured" bugs; 1692322 is a half-installed bug but that's for dpkg itself. hehe.
<bdmurray> sarnold: I think just asking for people's full /var/log/apt/term.log file is the best idea. I'll have a look to see if the dpkg deaths are getting surpressed somehow.
<sarnold> bdmurray: will do. thanks.
#ubuntu-devel 2017-06-20
<sarnold> juliank: indeed it does look awful; I don't think we've got any ideas either so all advice welcomed
<juliank> sarnold: Unfortunately no idea :/
<sarnold> :(
<bdmurray> sarnold: have you heard of lp-bug-dupe-properties?
<sarnold> bdmurray: nope
<bdmurray> sarnold: http://pastebin.ubuntu.com/24911326/
<sarnold> bdmurray: well that's cool
<bdmurray> I don't know how helpful that specifically is but the tool is neat.
<sarnold> that indeed answers a question I had :) I was hoping there'd be a way to see releases affected and relative weights
<bdmurray> well there you go!
<sarnold> it might be skewed towards new releases because I only manually duped bugs that were filed this month. it might be identical cause with earlier bugs bug something changed "recently" to make this far worse
<sarnold> there's always a trickle of half-installed failed upgrades but this is a real river..
<bdmurray> It looks like there is a bug with lp-bug-dupe-properties since getting RelatedPackageVersions doesn't work. It might be worth fixing that to find the versions of apt and dpkg.
<bdmurray> This "NULL: ConfigurePending" is weird too.
<infinity> sarnold: The "is not a symbolic link" thing would imply to me that they have a second libssl.so.1.0.0 in their library path, and ldconfig wants to symlink to it, but can't, because the real file exists.
<infinity> sarnold: But why that would suddenly have become an issue is a bit of a mystery.
<sarnold> bdmurray: hrm I think I see loads of NULL: ConfigurePending
<sarnold> it doesn't feel unique here
<sarnold> infinity: oh ewww.
<bdmurray> sarnold: oh you mean across all bugs?
<infinity> sarnold: Though, ldconfig doesn't exit with an error code in that case, so that could be a red herring.
<sarnold> bdmurray: yeah, I know I've seen it in many other bugs
<sarnold> it might still be a contributing factor here, like I said, no ideas..
<infinity> sarnold: http://paste.ubuntu.com/24911399/
<infinity> sarnold: I'd posit those postinsts are failing for other reasons that aren't giving you useful terminal output.
<sarnold> :(
<infinity> sarnold: Oh and, indeed, they can't be failing postinsts, because the packages haven't gotten that far.
<infinity> Hrm.
<bdmurray> sarnold: I've confirmed your statement about NULL: ConfigurePending existing in other bug reports
<infinity> sarnold: Plus, libssl-doc and libssl-dev are both represented here.
<juliank> Aren't ldconfig triggers?
<infinity> juliank: Yeah, the ldconfig thing is a red herring here.
<infinity> The real problem is that the packages are half-unpacked.  Which is probably why there's a second libssl in the library path.
<sarnold> does this mean dpkg isn't spitting out an error for one of its operations?
<infinity> It could well be a dpkg bug.  Are you seeing this on all releases, or...?
<sarnold> infinity: of the ones filed this month, it's 90% 16.04 LTS and 10% 16.10 http://pastebin.ubuntu.com/24911326/
<infinity> Looks like at least xenial and zesty.
<bdmurray> Preparing to unpack .../libssl1.0.0_1.0.2g-1ubuntu4.8_amd64.deb ...
<bdmurray> Unpacking libssl1.0.0:amd64 (1.0.2g-1ubuntu4.8) over (1.0.2g-1ubuntu4.6) ...
<bdmurray> Log ended: 2017-06-11  18:51:11
<bdmurray> Should the log have just ended there?
<infinity> Ideally not, but that could be an apt logging bug. :P
<infinity> Which log was that?
<infinity> Unpacking libssl-doc (1.0.2g-1ubuntu4.8) over (1.0.2g-1ubuntu4.6) ...
<infinity> Log ended: 2017-06-08  17:32:24
<infinity> ^-- From the one that later complains about libssl-doc being half-installed
<bdmurray> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1692981/comments/8
<ubottu> Launchpad bug 1692981 in openssl (Ubuntu) "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]
<infinity> bdmurray: Yup, so that would explain the ldconfig output on that one.
<infinity> bdmurray: If dpkg was interrupted mid-unpack, you'd have libssl.so.1.0.0.dpkg-tmp sitting there.
<bdmurray> Also the other full term log file show libssl-doc being unpacked and ending.
<infinity> And, thus, two versions of the same SONAME.
<infinity> So, in both cases, it looks like dpkg is just dying (or being interrupted by the frontend)
<infinity> Well, s/interrupted/killed/, cause I think a SIGINT would actually unwind gracefully.
<bdmurray> HistoryLog.txt shows "/usr/bin/dpkg exited unexpectedly"
<infinity> Indeed it does.  Shame it doesn't log a signal.  Though I'm not sure that would be illuminating.
<juliank> Were the upgrades unattended?
<infinity> Commandline: aptdaemon role='role-upgrade-packages' sender=':1.3320'
<infinity> update-manager, maybe?
<infinity> I suppose there's a super tiny chance it could have been OOM killed.  But I wouldn't expect that to be extra bad this week compared to last.
<infinity> Unless we recently shipped a memory leak or two.
 * infinity looks at dmesg.
<bdmurray> All the openssl bugs are amd64 fwiw
<infinity> bdmurray: Could also be a red herring, just because most of our users are amd64.
<bdmurray> right
<infinity> Nothing remotely fun in dmesg.  Like, at all.
<infinity> I wonder if they rebooted before apporting.
<sarnold> oh? I thuoght I saw :386 in many of them
<bdmurray> Oh hey - what's this? https://errors.ubuntu.com/problem/fbab11d5ffef5f64e1affa33c6e5bf0330075104
<slangasek> log on to the internerr
<sarnold> ermagerd internerr!
<bdmurray> sarnold: ack there are some i386 ones
<slangasek> can we kill dpkg-split already
<infinity> I'm blind.  Where's the indication that that crash is the same as the bug we were looking at?
<bdmurray> infinity: its not I went looking for dpkg crashes since it died unexpectedly and found this.
<bdmurray> I mean there is no clear indication.
<bdmurray> But if dpkg is crashing on a stable release it wouldn't by default end up in LP.
<infinity> Of course, related or not, that's a whole lot o' crashes.  What's the process for getting non-Canonical people access to their crash data?  I think guillem should have a poke at that.
<bdmurray> fill out a form somewhere
<bdmurray> https://forms.canonical.com/reports/
<infinity> Though, that one seems to be fixed in >> xenial?
<infinity> Which means it's probably *not* the bug we're looking at.
<juliank> That error tracker bug looks weird
<bdmurray> only 3 of the reports are using dpkg 1.18.10*
<infinity> That's 3 more than 0.
<infinity> Wait, which reports?
<bdmurray> 3 of the duplicates of the openssl bug in Launchpad
<infinity> For the error tracker, I see everything being <= 1.18.4
<infinity> The openssl bug, I saw a few in newer releases, yeah.
<infinity> Hence my guess that it's not the same issue.
<juliank> It can't be related because it's a crash that only occurs when formatting an error message when dpkg-split failed. In which case there is nothing to partially unpack
<slangasek> it's not a crash when formatting; it's an abort with message
<slangasek> but still, dpkg-split
<juliank> Ah yes, that makes more sense, it calls abort() there
<infinity> Anyhow, still obviously unrelated, since dpkg-split isn't involved in dpkg --unpack :P
<juliank> Yes, and fixed in newer dpkgs
<juliank> Well, it does not abort() anymore, just logs an error
<bdmurray> Still worth fixing in 16.04 though.
<slangasek> it's worth suppressing those crash reports
<slangasek> it's not really worth fixing; if dpkg-split was invoked at all, your real problem is somewhere upstream
<mapreri> how do you ask autopktest to use multiple triggers?  I remember doing so in the past but I seem unable to now
<slangasek> bdmurray: dpkg-split is the tool used to reassemble floppy-disk-sized fragments of a .deb into a single file on your hard drive for installation.  It's slightly obsolete
<mapreri> with `&trigger=pkg1/version1,pkg2/version2` it says it's malformed
<infinity> mapreri: trigger=&trigger=&trigger=
<juliank> slangasek: That's dpkg.git commit 521e84da3a2b9ad62d5dbab0f4e1794aef149996
<slangasek> &mushroom=&mushroom
<mapreri> infinity: ah, thanks
<infinity> SNAKE, AND A SNAKE.
<juliank> https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=521e84da3a2b9ad62d5dbab0f4e1794aef149996
<juliank> It was fixed in 1.18.5, so should probably apply easily
<slangasek> bdmurray: so if the best way to suppress the garbage being sent to errors.u.c is by SRUing dpkg, ok - but "fixing" that won't actually benefit users
<infinity> More to the point, we've still got no idea what's eating dpkg on those libssl logs.
<infinity> Which I imagine isn't related to libssl at all.  Has anyone found dupes elsewhere?
<bdmurray> infinity: yes
<bdmurray> bug 1692996
<infinity> Given it's happened to libssl1.0-dev (which is a metapackage), libssl1.0.0 (a library package), and libssl-doc (static docs), it seems like just a timing coincidence.
<ubottu> bug 1692996 in apport (Ubuntu) "package apport 2.20.4-0ubuntu4 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration" [Undecided,Confirmed] https://launchpad.net/bugs/1692996
<infinity> bdmurray: Okay, that's mildly "comforting".
<infinity> bdmurray: I wonder if the common thread here is that it's all aptdaemon.  Though, again, could be a red herring just due to how many aptdaemon upgrades happen.
<infinity> Also, unless we can correlate some actual dpkg *crashes*, it really feel more like something's just murdering it.
<infinity> s/feel/feels/
 * bdmurray checks his cache o' bugs
<infinity> Fine time for a server to explode.
<infinity> mapreri: What was your full request URI?
<infinity> mapreri: Here's an example of a working on (don't click it :P)
<infinity> mapreri: http://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=amd64&package=snapd&trigger=linux-meta/4.10.0.20.22&trigger=linux/4.10.0-20.22
<infinity> mapreri: You might just need to urlencode your + and/or ~ in those versions.
<nacc> yeah that's what i've hit in the past (urlencoding)
<infinity> I don't recall the encoding for either of those chars because I haven't done web devel for decades, but I suspect Google can help. :P
<sarnold> mapreri_:  <infinity> mapreri: You might just need to urlencode your + and/or ~ in those versions.
<infinity> + = %2B and ~ = %7E
<sarnold> hah excess flood kills too. he probably saw none of this.
<infinity> Oh well.
 * infinity pokes mapreri tentatively.
<infinity> mapreri: Alive this time?
 * infinity gives up for now until freenode gets over itself.
<mapreri> http://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=amd64&package=visp&trigger=visp/3.0.1-2build1&trigger=opencv/3.1.0%2Bdfsg1-1%0Aexp1 still says "malformed trigger" :\
<mapreri> yeah, even if my client says it has quite some lag
<mapreri> I should probably tell my bouncer to try to join channels slower than ~30 at once.
<mapreri> luckily it happens rarely enough ^^
<juliank> Did nobody write a request-autopkgtest script yet? :D
<sarnold> heh 88 second ping to mapreri :)
<infinity> mapreri: %0A is \n
<infinity> mapreri: Not surprised it doesn't like that. ;)
<infinity> mapreri: ~ = %7E
<bdmurray> infinity: should I be looking for bugs where dpkg exited unexpectedly and aptdaemon is not in use and the package is in an inconsistent state?
<infinity> bdmurray: If it's easier to prove a negative than a positive, yeah.
<infinity> bdmurray: I mean, we want to know one way or the other if *all* related bugs involve aptdaemon, cause then we might have a clue that aptdaemon is murdering its children.
<bdmurray> but if the package is already installed and configured that's not the same issue?
<infinity> bdmurray: But, again, we do so much automagic upgrading with aptdaemon, it could still be a red herring. :/
<infinity> bdmurray: already-installed-and-configured is a different bug, yes.
<mapreri> Test request submitted.
<mapreri> triggers
<mapreri> ['visp/3.0.1-2build1', 'opencv/3.1.0+dfsg1-1~exp1']
<mapreri> \o/
<mapreri> infinity: â¥
<slangasek> aptdaemon could still be a particular cause of some kinds of failures, e.g. apt debconf pre-configuration
<infinity> bdmurray: This bug would key on half-installed in the terminal log, or dpkg exiting unexpectedly in the dpkg log.
<slangasek> but that would only apply if it were really always libssl1.0.0 getting the axe
<slangasek> ... also libssl1.0.0 has no config script, so nevermind
<infinity> bdmurray: What I really want to know is if we have any dpkg crashes that match the same systems/times as these bugs.  If not, then it's more likely a parent committing infanticide.
<infinity> slangasek: It's happened to libssl1.0-dev, which is just a transitional with no maintainer scripts or triggers at all, which I think rules out any packaging issues other than dpkg/frontend being derp.
 * slangasek nods
<bdmurray> infinity: There's not an easy way to do that but we could ask people to check their whoopsie logs or give us their system identifier.
<infinity> I kinda want to find out that it's actually a memory leak shipped in compiz a week earlier and dpkg is being OOM-killed, just because that would be almost as much fun as Can't Print on Tuesdays.
 * infinity tries to find one with an intact dmesg that wasn't obviously rebooted before the report was sent.
<infinity> The fact that all of them (so far I've been through about 10) seem to have been rebooted before the report was sent.  Is that coincidence due to how/when apport runs, or could that be indicative of a larger issue that forced a reboot?
<infinity> bdmurray: ^
<infinity> Cause another suspicion here is that weird "cannot fork" thing I saw on my machine a while back.
<infinity> Which would, indeed, lead to dpkg bailing during unpack.
<sarnold> infinity: you ran into a 'cannot fork' in the wild? as root?
<infinity> sarnold: Hard to say if I ran into as root, given that I couldn't execute anything to elevate privs.
<infinity> sarnold: So, "maybe"? :P
<sarnold> infinity: hehe
<sarnold> infinity: I thought maybe that was apt/dpkg ...
<infinity> Anyhow, every one of those dupes has a fresh dmesg.  Which might mean something, or might just mean apport doesn't do useful things until reboot.
<infinity> In which case, sending dmesg instead of kern.log.* seems mostly useless.
<sarnold> I'm not sure about the relative merits of kern.log vs dmesg but I close a ton of bugs are hardware related thanks to dmesg errors
<bdmurray> An interesting thing about apport and whoopsie bug reports is that they add what's in /var/crash and I'm not seeing any dpkg crashes there.
<infinity> bdmurray: Which might well imply that dpkg is being killed, not crashed.
<sarnold> Bug #1699356 is libgcc1:i386 -- the dpkg history log shows "Sub-process /usr/bin/dpkg returned an error code (1)
<ubottu> bug 1699356 in gcc-6 (Ubuntu) "package libgcc1:i386 1:6.2.0-5ubuntu12 failed to install/upgrade: package libgcc1:i386 is not ready for configuration cannot configure (current status 'half-installed')" [Undecided,New] https://launchpad.net/bugs/1699356
<sarnold> .. before the "Sub-process /usr/bin/dpkg exited unexpectedly"
<mapreri> could anybody merge doxygen?  doxygen-latex is uninstallable in proposed due to latex being rude at the world, and uninstallable doxygen-latex makes me sad.
<mapreri> (happy to provide debdiffs and all, but `grab-merge doxygen` gets it right by itselfâ¦)
<mapreri> actually, grab-merge is not enough, as the latest upload is not yet there
#ubuntu-devel 2017-06-21
<slangasek> mapreri: are you fixing mldemos for the new opencv?
<Logan> jbicha: do you remember why you stopped building qmmp-plugin-projectm on arm64 with this change? https://launchpad.net/ubuntu/+source/qmmp/1.1.3-0ubuntu1
<Logan> trying to determine whether to drop/keep that delta
<cpaelzer> nacc: glad I could help serving a few bugs for the importer :-)
<cpaelzer> nacc: looking at the new tree now
<LocutusOfBorg> jbicha, is the xmonad patch retro-compatible with an older gnome-settings-daemon? I would like to upstream it in Debian too
<lag> Can anyone help me access a private PPA (which I have access to) please?
<cking> lag, ^ if you explain the exact issue it may help somebody figure out what's wrong
<lag> W: The repository '<REMOVED_FOR_SECURITY> zesty Release' does not have a Release file.
<lag> N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
<lag> E: Failed to fetch <REMOVED_FOR_SECURITY>/ppa/ubuntu/dists/zesty/main/source/Sources  401  Authorization Required
<mapreri> slangasek: actually, I wanted to ask for removal of mldemos.  It FTBFSed even before opencv 3.1.
<mapreri> (well, new opencv caused a different failure too, but still)
<mapreri> In that transition I already have 2 packages that FTBFS but didn't during my build tests, so if you want to fix one or 2 go ahead :)
<jbicha> LocutusOfBorg: no, g-s-d was split into separate binaries in 3.24; I believe RequiredComponents means that all listed binaries must be running
<jbicha> Logan: maybe it failed to build? if it builds, syncing is fine with me :)
<mwhudson> lag: stupid questions would be, you did get your password right? the particular ppa does actually have publications for zesty?
<lag> mwhudson: Stupid answer would be, yes, I copied and pasted the PPA deb lines directly from LP to sources.list
<lag> mwhudson: Yes, Zesty is published/tested
<lag> mwhudson: FYI: This is dja's PPA
<mwhudson> lag: huh then i don't know :/
<mwhudson> i guess you could try poking around in the browser
<lag> mwhudson: On subsequent issue of `sudo apt-get update` it's now professing a GPG error, but the key is not --recv-keys gettable
<mwhudson> !/
<mwhudson> !? rather
<lag> mwhudson: A1CC0926363E55AB -- is that your experience?
<mwhudson> lag: --keyserver keyserver.ubuntu.com ?
<mwhudson> aka "the one that works"
<mwhudson> (i fetched the key fine from there)
<lag> mwhudson: Oooo
<lag> mwhudson: Nice, thanks
<lag> mwhudson: Interesting that they are not propagated to other servers?
<mwhudson> lag: i don't know that that is deliberate...
<lag> mwhudson: Same error though -- still saying the key is not available -- do I have to give `apt-get update` any further args?
<mwhudson> oh
<mwhudson> you need some apt-key invocation
<lag> The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A1CC0926363E55AB
<mwhudson> apt doesn't care about your keyring :-)
<lag> mwhudson: :)
<mwhudson> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $fingerprint
<mwhudson> this reminds me i have some keys to sign but i'm not sure i have enough whisky in the house to deal with caff
<lag> mwhudson: :)
<lag> mwhudson: Is caff a person?
<mwhudson> https://wiki.debian.org/caff
<lag> mwhudson: I have a nice little script that helps me to sign keys
<lag> mwhudson: Ewww, good luck with that :(
<ginggs> has anything recently changed with the way 'hardening=+all,-pie' is handled in Ubuntu?  I thought we are now doing things the same as Debian.  p4vasp FTBFS in artful, but builds fine in Debian unstable
<jbicha> pitti: hi, I believe you're sponsoring meson 0.41.1? it fixes build failures for some vala apps
<rbasak> Is it just me or has various things sent to ubuntu-devel@ started arriving twice?
<pitti> jbicha: I am, yes; I just saw jussi's sponsor request mail
<dja> lag/mwhudson - I'll copy it to a public ppa in a couple of hours
<dja> just have some cleaning etc to do
<lag> dja: It's fine -- I have it now, thanks
<dja> lag, ah excellent
<lag> dja: Just installing now
<dja> I will save the effort for housework then :)
<lag> dja: Actually I'm looking for your Grub entry (did you send that via mail)
<dja> oh
<dja> I sent 1 line of it
<dja> let me see what I sent you
<lag> dja: Found it, rebooting
<dja> ah good
<dja> you can also examine it interactively in grub when you're booting
<dja> the commands are printed somewhere on screen :)
<dja> anyway, housework time
<lag> dja: Ya, I do that a lot
<lag> dja reaches for his feather duster and pinni
<rbasak> nacc: some of our tooling (eg. queue sync) doens't work with a locally imported tree any more by default, since it's looking for a remote for pkg, rather than at local importer/ prefixed branches. Not sure how to resolve this. I think I'm happy with where we're putting things, so perhaps tooling needs to be able to look in the right places, or else we need some code abstraction to find them?
<nacc> rbasak: can you file a bug or pastebin an example so i can debug?
<rbasak> nacc: I know where the bug is, it's a just the architectural question of how to resolve.
<nacc> rbasak: can you point me at a line?
<rbasak> nacc: queue.py:215
<rbasak>                 devel_head_ref = repo.lookup_reference('refs/remotes/pkg/ubuntu/%s-devel' % series)
<rbasak> But for a local import, it's refs/heads/importer/ubuntu/%s-devel
<rbasak> I could look for both for example
<nacc> rbasak: i think that's only a problem for the queue code, which doesn't use the git_repository functions
<nacc> rbasak: oh wait, i see what you mean
<nacc> rbasak: it *could* happen elsewhere
<nacc> rbasak: but i meant that line, at least, explicitly is looking at a remote ref
<rbasak> Yeah - so what should it do instead?
<rbasak> Look for both?
<rbasak> Or require an option for local? Etc.
<ginggs> <ginggs> has anything recently changed with the way 'hardening=+all,-pie' is handled in Ubuntu?  I thought we are now doing things the same as Debian.  p4vasp FTBFS in artful, but builds fine in Debian unstable <-- fixed by no-change rebuild of fltk1.3
<nacc> rbasak: let me look a bit more after the call
<nacc> rbasak: ok, so contextually, sync() is trying to find the -devel branches for all possible series?
<nacc> rbasak: what should it do if both pkg/ubuntu/*-devel and importer/ubuntu/*-devel are present?
<rbasak> nacc: that's right. And yes - what should it do?
<rbasak> Perhaps favour the local branches?
<rbasak> Or fail and ask?
<nacc> rbasak: well, it's your subcommand :) I'm trying to think out loud a bit
<rbasak> Sure. What about the general case though? Are there other subcommands that need to look at the imported trees (rather than HEAD), and what should they do
<rbasak> ?
<nacc> rbasak: yeah, so I think what we should do is write a wrapper in git_repository.py that takes a series name and returns the 'later' (or possibly sorted by version, all) branches that are devel pointers of that series
<rbasak> What if we need things that aren't devel pointers? :)
<nacc> rbasak: series parameter
<nacc> rbasak: *pocket parameter
<rbasak> I mean I need to see all the pointers. For example in my lint tool, to figure out the SRU version number.
<rbasak> Also, what should the return type be? pygit2.Reference?
<nacc> rbasak: well the linter should be using get_heads_and_versions
<nacc> rbasak: which will give you all of them in a given namespace
<rbasak> Ah, OK. Thanks
<nacc> rbasak: i think it can be made more flexible to allow no namespace, etc. (and not insert '/' if not provided)
<rbasak> That makes sense
<nacc> rbasak: i think it's ok to have two APIs for now, they probably can consolidate eventually
<nacc> rbasak: the consolidation being a third parameter to get_heads_and_versions which also takes a suffix (or well-defined 'pocket' argument)
<nacc> rbasak: that i think you could actually use in the queue code too, just need to peel the head to get the ref object
<nacc> rbasak: but i think you're right, you'd need to do both in the queue code, and have some sort of prioritization (or query to the user) -- i think favoring local imports (or 'later' version?) would work to start?
<rbasak> nacc: yeah. I'll file a bug. In queue sync, I can workaround with my new --series, --no-trim, --no-fetch, --parent and --source options.
<rbasak> LP: #1699541 for reference. Leaving for now.
<ubottu> Launchpad bug 1699541 in usd-importer "subcommands fail when only a local import exists" [Undecided,New] https://launchpad.net/bugs/1699541
<nacc> rbasak: ack, thanks
<ogra_> cyphermox, yo ... regarding netplan in the core snap ... we dont build from proposed ... so nplan should be copied to the snappy image PPA to be picked up by edge core builds
<cyphermox> it will be in updates soon
<nacc> rbasak: also, i think we had previously said that only the importer would know about importer/ ... obviously that can't be true for 'offline imports'
<nacc> rbasak: so we might need to rethink other bits
<ogra_> cyphermox, ah, cool, for the next time we can copy from proposed to https://launchpad.net/~snappy-dev/+archive/ubuntu/image ... in case there is testing needed just give me a ping when you have some package for it
<nacc> rbasak: i'm triggering the assertion at git_repository.py:941 with websockify (0.5.1+dfsg1-1 specifically)
<rbasak> nacc: on origin/master I don't see an assertion on 941 but there is one nearby.
<nacc> rbasak: err, right, 937 in master
<nacc> rbasak: sorry was on the wrong branch locally (but the bastion import is what shows it, so it's in master too)
 * rbasak is reminding himself of the code
<nacc> rbasak: i'm getting us some more debugging output as well
<nacc> rbasak: pygit2.TreeEntry('include', blob, f5030fe889982444316aa710b12026d377e187e0)
<nacc> rbasak: that's the tree_entry variable before the assertion triggers
 * rbasak tries to reproduce
<nacc> rbasak: thanks
<rbasak> I can reproduce
<bdmurray> juliank, infinity: Looking at apt and those 'dpkg exited unexpectedly' bugs - is there some additional information we could gather here? https://git.launchpad.net/apt/tree/apt-pkg/deb/dpkgpm.cc#n2078
<nacc> rbasak: ah tests/include -> ../include
<nacc> rbasak: another symlink issue?
<rbasak> Ah
<rbasak> os.path.isdir returns True for a symlink to a directory.
<nacc> rbasak: yeah, i think you have to explicilty check for a symlink
<rbasak> Better to use lstat and check using S_ISDIR I think.
<nacc> rbasak: as you see fit :) the python docs basically say isfile/isdir will be true for symlinks (it doesn't mean 'regular file'/'regular dir')
<rbasak> Yeah, my mistake
<nacc> rbasak: oh not meant as criticism :) i find it surprising too
<nacc> rbasak: so the fix is changing _add_missing_tree_dirs to not use isdir, but lstat and ISDIR?
<rbasak> Yep. https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/326084
<nacc> rbasak: so that we only recurse on directories
<rbasak> (filed just this moment)
<nacc> rbasak: ack, reviewing
<juliank> bdmurray: I guess we could at least log the status code or something. AFAICT, the branch is entered on signals that are not SEGV, but I'm not sure it's really useful, you'll see the type of signal anyway
<nacc> rbasak: merged, thanks!
<bdmurray> juliank: Can you elaborate on "see the type of signal anyway"?
<slangasek> mapreri: removal is also fine! are you requesting its removal from Debian or Ubuntu, and can I get a more formal paper trail?
<juliank> bdmurray: Well, in the error tracker you saw that it was calling abort() anyway
<juliank> But we can add it, I just wouldn't do an out-of-band release for that, it seems really low priority
<bdmurray> juliank: I was trying to get more information than "Error: Sub-process /usr/bin/dpkg exited unexpectedly" as seen in https://launchpadlibrarian.net/320875815/DpkgHistoryLog.txt
<juliank> Ah, yes in that log file it would be more helpful. But at least you know it's not a segfault or a error exit
<bdmurray> Oh yeah, that's true.
<juliank> bdmurray: I guess we should (1) add a return _error->Error(_("Sub-process %s received signal %u."),Name, WTERMSIG(Status)); branch and (2) just print the waitpid status as is somewhere in the unexpected path
<juliank> There are three users of that string in the apt code, I'd obviously prefer generalizing this for all of them
<smoser> sil2100, still there?
<smoser> i'm on holiday at the moment. i just was going to check in for a cuople hours.
<sarnold> dangerous thing to do on holiday :)
<smoser> the new-upstream-snapshot change was done in one of the branches, i'm not sure which.  it was a result of bzr insisting that a file had changed been fully removed and then added again with 100% the same contents.
<smoser> i'd seen this in other places in the past...
<smoser> 'bzr diff' between two branches will show you 100% difference on 100% equal files.
<smoser> the end result is that it doesn't matter as long as it was correct.
<smoser> its really just an 'upstream revision control management' thing. i'm looking forward to it being replaced by one that uses git in the future.
<nacc> cyphermox: systemd-resolve question -- lxd has a /etc/systemd/network/lxd.network with DNS=10.0.4.1 and Domains=lxd. But systemd-resolve <container>.lxd does not query 10.0.4.1. What am I missing?
<cyphermox> xnox: slangasek: ^
<slangasek> haha
<cyphermox> we were just discussing that
<nacc> heh
<nacc> I have been reading lots of manpages ... which are eye-bleeders
<slangasek> what did xnox say was the right bit? '[DHCP] UseDomains=yes' into the systemd-resolved config?
<cyphermox> nacc: systemd's defaults for UseDomains= break that
<cyphermox> yep
<nacc> cyphermox: ah i see
<cyphermox> to be precise, UseDomains=route would fix this; UseDomains=yes would fix this and make <container> work too
 * cyphermox goes to verify this
<nacc> cyphermox: ok, that goes into /etc/systemd/resolved.conf in the [Resolve] section? it's not in the manpage :)
<cyphermox> nacc: no, it goes into /etc/systemd/network/lxd.network
<nacc> cyphermox: oh ok
<slangasek> cyphermox: is that by convention, or is that actually a different config namespace than the other bits read for resolved?
<cyphermox> slangasek: it's a DHCP setting, so it goes with each interface
<nacc> cyphermox: well, clearly i don't know which services i need to restart/reload (and which can be). Rebooted after mucking with the files and I do now get resolution of <container>
<nacc> cyphermox: but not <container>.lxd, is that expected too?
<nacc> cyphermox: hrm, worked for one container, rather, but not another, debugging
<cyphermox> what setting did you use? it's probably something else
<cyphermox> you'd want to check what systemd-resolve --status reports, I suppose
<nacc> cyphermox: weird, it works for some random subset -- UseDomains=yes in /etc/systemd/network/lxd.network
<nacc> cyphermox: should status indicate which domains, if any are being used?
<cyphermox> nacc: I don't know. Right now I'm not able to make lxc work correctly on my system
<nacc> cyphermox: excellent :)
<cyphermox> status should indicate everything
<nacc> cyphermox: ok, there are some domains in "Global", but none per-link
<nacc> http://paste.ubuntu.com/24918979/
<cyphermox> ... and nothing lxc there.
<nacc> cyphermox: oh an interesting, no 'DNS Servers" entry at all (whereas my wifi entry does have it (but no domain, which is ok): http://paste.ubuntu.com/24918987/
<nacc> cyphermox: sorry, i'll stop pinging you random pastes until you're in a working state yourself :)
<cyphermox> won't be long, I fallback to another system that does work
<nacc> cyphermox: cool, last paste of partial resolution, correctly on per-link basis (I think), and that all three should resolve: http://paste.ubuntu.com/24919010/
<cyphermox> nacc: what is in resolv.conf?
<cyphermox> because by default you might well also have dnsmasq running, the one from NM, and things in resolv.conf which may or may not have been picked up by systemd-resolve
<nacc> cyphermox: nameserver 127.0.0.53
<nacc> cyphermox: which, iiuc, is just systemd-resolved?
<cyphermox> yes
<nacc> cyphermox: i do have dnsmasq running for NM, that's true
<cyphermox> ok, in that case, what is in /run/systemd/resolve/resolv.conf?
<nacc> cyphermox: that contains 'nameserver 192.168.1.1'
<nacc> cyphermox: interesting
<cyphermox> well, that's expected
<cyphermox> that would be your wifi
<cyphermox> (I guess)
<nacc> cyphermox: yep
<nacc> cyphermox: how does systemd-network know to map 'lxd.network' to lxdbr0? Is that perhaps what's missing? e.g., Name=lxdbr0 in a [Match] section?
<nacc> cyphermox: or does the lack of [Match] mean it will always be tried?
<nacc> cyphermox: nm, answered my question by finishing the manpage section :)
<xnox> nacc, cyphermox, slangasek: one is missing [Match] Name=eth0 [DHCP] UseDomains=true as a /etc/systemd/network/usedomains.network
<xnox> nacc, it's a per-link / .network configuration. Not a resolved daemon option.
<nacc> xnox: right, so i added [DHCP] ... to lxd.network
<nacc> xnox: the manpage says no Match is match all
<xnox> yeap. or whichever you need =)
<xnox> sure.
<nacc> xnox: but it still doesn't work :)
<nacc> xnox: well, not fully, at least
<nacc> i get partial resolution, which is weird
<xnox> nacc, it does for me here. $ sudo systemctl restart systemd-networkd systemd-resolved
<xnox> nacc, what doesn't work?
<nacc> xnox: one sec, let me grab the paste
<xnox> and what is your /etc/resolv.conf?
<nacc> xnox: /etc/resolv.conf is pointing to just systemd-resolved, /run/resolvconf/resolv.conf is pointing to my wifi nameserver
<xnox> nacc, also who are you trying to resolve, from where, and where the target actually is. For me I get container <-> container resolving each other.
<nacc> xnox: i want host resolving container
<nacc> xnox: http://paste.ubuntu.com/24919010/
<xnox> nacc, we do not do that at all. because that would conflict when one has multiple container bridges.
<nacc> xnox: sure, but i don't.
<nacc> xnox: so i should be able to configure something to do it, right?
<xnox> nacc, what we do provide and support, is one container resolving the other container, with search domains. e.g. cuty-animal resolving ugly-animal.
<xnox> right, yes you should be able to.
<xnox> however, you need to have a dhcp client for your host, running on that bridge, and specifying that to resolved.
<xnox> i do not think we feed that on the host.
<xnox> (by default)
<xnox> not sure how to configure that properly.
<xnox> what is your lxd.network on the host?
<nacc> xnox: confirmed that the containers do see other properly (i hadn't even tested that before)
<nacc> xnox: http://paste.ubuntu.com/24919186/
<xnox> nacc, i think i want your output of $ systemd-resolve --status
<xnox> too
<xnox> right, that would not work.
<xnox> as that unit makes no sense at all.
<xnox> what you do want is dhcp network file that will get an ip address on the bridge.
<nacc> xnox: the only thing i added was the last two lines, the others were there already
<xnox> hm. but that's very backwards.
<xnox> o_O
<xnox> where did the first two come from?
<nacc> xnox: http://paste.ubuntu.com/24919194/ (--status) and the frustrating part is: http://paste.ubuntu.com/24919190/
<nacc> xnox: oh wait, nm, i probably added it tryign to get this all to work
<nacc> xnox: so i will admit to PEBCAK :)
<nacc> xnox: but i'd also like to understand what i should be doing instead ... it feels like my host has all the information it needs to resolve everything, i just don't know how to tell systemd to use 10.0.4.1 to resolve *.lxd
<xnox> nacc, i think on the host, you simply want to adjust /etc/systemd/resolved.conf and change DNS= to have the whatever dnsmasq on the lxd bridge binds to (10.0.4.1) and then Domains=lxd in that file too
<xnox> then restart systemd-resolved
<xnox> and then it should work for host to resolve cute-animal
<xnox> this is basically hand tuning the host.
<nacc> xnox: right, but that ends up putting it global, instead of per-link?
<xnox> a more generic way, is to write .network files for systemd-networkd on the host to get a dhcp lease, just like a container would, and then resolve names as if host is one more containers.
<nacc> xnox: e.g.: http://paste.ubuntu.com/24919212/
<xnox> correct.
<xnox> you can do per-link via dbus api.
<nacc> xnox: the issue i found was that it ended up pegging my cpu eventually :)
<nacc> xnox: as in immediately afterwards (it's doing so now)
<nacc> *after restarting systemd-resolved
<xnox> please file a bug with output of /proc/<pid>/stack
<xnox> when it does.
<nacc> lol
<nacc> [<ffffffffffffffff>] 0xffffffffffffffff
<xnox> nacc, i think you may be able to create a decent enough .network file to do per link resolution.
<xnox> soemthing like
<xnox> [Match] Name=lxdbr0 [Network] DNS=10.0.4.1 Domains=lxd
<xnox> instead of changing /etc/systemd/resolved.conf
<xnox> restart systemd-netwrokd, restart systemd-resolved
<xnox> then look at status of $ systemd-resolve --status
<xnox> and it should have that DNS/domains at a per-link under lxdbr0
<xnox> does above make sense? i haven't tried this, just going by the manpages.
<nacc> xnox: yep it does, testing it now
<nacc> xnox: nice! i think that does it
<nacc> xnox: well that makes --status show it
<nacc> xnox: but systemd-resolve still doesn't resolve it? odd
<nacc> xnox: oh it made it ipv6 only
<nacc> xnox: ok, i think i can tweak it from here
<xnox> it should just work.
<xnox> e.g. $ getent ahosts cute-animal
<xnox> should return ipv6 and ipv4 for cute.animal.lxd
<xnox> should return ipv6 and ipv4 for cute-animal.lxd
<nacc> xnox: agreed, but it doesn't :) ... trying to figure out why
<nacc> xnox: http://paste.ubuntu.com/24919265/
<nacc> xnox: and still some running containers resolve and some don't
<xnox> that's weird.
<xnox> your setup looks very odd.
<xnox> i'll play with things locally, to see if i can configure it to do what is needed right.
<xnox> and what is your current output of systemd-resolve --status?
<nacc> xnox: sure, i'd appreciate it! (i'm on artful, fwiw)
<xnox> and did you restart both networkd and resolved?
<nacc> xnox: yep, restarted both
<nacc> xnox: http://paste.ubuntu.com/24919275/
<nacc> xnox: note that beofre, lxdbr0 had LLMNR/IPv4 and IPv6
<xnox> that looks correct to me.
<xnox> nacc, now I see you have _both_ lxd and lxc, are the names that are not working are for the lxc containers, rather than lxd containers?
<xnox> e.g. containers that are running, in the output of $ lxc list -> should be resolvable as short names, and hopefully as long names too.
<cyphermox> nacc:
<cyphermox> are you connected to the VPN?
<cyphermox> s/the/a/
<nacc> xnox: no, only lxd containers
<nacc> xnox: i have no actual lxc containers (that bridge config is legacy)
<nacc> cyphermox: not currently
<cyphermox> ok
<nacc> xnox: i agree 100% with your earlier statement: "containers that are running, in the output of $ lxc list ..." but sadly that has never been the case for me (i believe mwhudson also experiences this)
<cyphermox> nacc: after you restarted systemd-networkd/systemd-resolved, did you restart lxd as well?
<cyphermox> ie. do you have an IP for lxdbr0?
<mapreri> slangasek: actually, I was thinking of demoting it from release to -proposed, not a complete removal.  I believe at some point the maintainer is going to fix what he caused not so long agoâ¦
<slangasek> mapreri: demoting instead of deleting clutters update-excuses.  If we're not fixing it, I'd like a bug ref and to delete it, and then bring it back when it's reuploaded to Debian with the fix
<mapreri> slangasek: what I "fear" is that once deleted, nobody is going to notice that it's fixed in debian, and the auto-syncer is not going to bring it back by itselfâ¦
<mapreri> then, for a package with popcon 12 in debian I probably won't care much
<mapreri> slangasek: I'll file a bug later in the process if no fix comes out of nothing, just for a change.
<slangasek> mapreri: that's a bug in the autoimporter in my view, which I intend eventually to fix; and I do run the importer manually in the meantime to make sure we pick those up
<mapreri> oh, cool, that's nice to hear
<nacc> cyphermox: heh, so restarting lxd also causes systemd-resolved to peg cpu
<nacc> cyphermox: interesting, restarting the containers is causing them to show up as resolve-able. Which makes sense, I suppose, they have to re-issue their dhcp requests.
<nacc> cyphermox: let me reboot
<nacc> cyphermox: urgh, on reboot, my systemd-resolved --status changed back to not be per-link somehow...
<nacc> cyphermox: restarting both networkd and resolved, the per-link DNS and domain come back
<nacc> cyphermox: hrm, but the 'Current Scopes' is now "none"
<nacc> cyphermox: well, i'm not sure what changed, maybe the last lxd restart did it, but now the scopes is "DNS LLMNR/IPv4 LLMNR/IPv6" but and 2 of 3 freshly started containers resovle from the host, but systemd-resolved is pegging cpu ...
#ubuntu-devel 2017-06-22
<nacc> xnox: cyphermox: am i correct in understanding htat in a working environment (which I have yet to consistenly make), the scopes for lxdbr0 would be DNS LLMNR/IPv4 LLMNR/IPv6? Does everyone else just have working host -> container lookups of their LXDs and not hit this at all? :)
<nacc> stgraber: --^ :)
<nacc> xnox: cyphermox: i wonder if this is all because lxd itself doesn't start a boot ... so possibly that boot-time race i saw earlier was just relative to when the dns records were cached/recorded?
<Unit193> mwhudson: There's regressions http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#golang-github-jacobsa-crypto
<sarnold> that line-wrapped here at cry\npto and my brain turned that into "cry potato"
<Unit193> Heh, it just pushed the url to its own line for me, I think I like your version better though.
<Unit193> Also, you lost identification to services during the splits.
<sarnold> :(
<sarnold> wait how am I here? I thought this channel forbid joins by unregistered?
<Unit193> That was disabled since the spam hadn't been hitting elsewhere.
<sarnold> ah nice :) it was always annoying to discover I'd been parted from this channel for a day or several
<Unit193> More so since ubuntulog did too.
<sarnold> bdmurray: interesting, the cancer spreads beyond openssl -- 1699630 -- openssl has trouble, and then nothing else makes sense, and then other packages get stuck half-way too
<bigon> is ubuntu somehow shipping a  policy-rc.d file by default? I'm asking because of https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1646015
<ubottu> Launchpad bug 1646015 in audit (Ubuntu) "update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults" [Undecided,Confirmed]
<pitti> bigon: mk-sbuild does, but certainly not normal installs
<bigon> idd
<bigon> apparently it's a docker thing (after some quick googleing)
<cpaelzer> mitya57: ping
<mitya57> o/
<cpaelzer> mitya57: saw you replying so you are awake :-)
<cpaelzer> mitya57: tell me how I could help once you read my reply to the s390x issues
<mitya57> oh, thanks a lot
 * mitya57 reads
<mitya57> cpaelzer, how difficult is it to get the stack trace of the hung process?
<cpaelzer> mitya57: like while hanging - or in advance while it runs into it ?
<mitya57> while hanged
<cpaelzer> easy I'd think, let me rekick it into the case
<cpaelzer> but it doesn't seem to spin so we likely get only one - the poll it is hanging on
<cpaelzer> anyway - it started - I'll ping you once it is hanging so we can joint debug it then
<cpaelzer> mitya57: and nobody on the mail said no - but at least from my experience I have not seen s390x specific hangs so far on any other builds
<Laney> cpaelzer: actually I noticed one yesterday ;-)
<Laney> https://launchpad.net/ubuntu/+source/clutter-1.0/1.26.0+dfsg-4/+build/12556836
<mitya57> cpaelzer, also it would be even more interesting to check https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/12784776, there all Qt test processes have exited, so the hang happens in make or some other part of the build system.
<cpaelzer> mitya57: sure I just picked the first one in your set of links
<cpaelzer> mitya57: once we looked at the strace of the one now runnign I can trigger the multimedia one
<cpaelzer> interesting Laney - and also on/after tests
<mitya57> cpaelzer, thank you again! The first one is also interesting, maybe it will uncover some bug in Qtâ¦
<xnox> nacc, dns only starts with the first container....
<Laney> cpaelzer: yeah, although this is the first upload of that pkg where tests are run
<cpaelzer> Laney: mitya57: maybe something in whatever test framework they use changed and now hangs (almost) all test son s390?
<mitya57> cpaelzer: Our test frameworks are completely different.
<cpaelzer> :-/
<cpaelzer> so much for the theory
<Laney> could be a coincidence
<mitya57> One thing in common is the GLib main loop, though.
<Laney> it didn't hang in debian but all the tests failed early there: https://buildd.debian.org/status/fetch.php?pkg=clutter-1.0&arch=s390x&ver=1.26.0+dfsg-4&stamp=1494334721&raw=0
<cpaelzer> mitya57: the strace isn't great because we don't see the actual call of the program but instead that it was stopped and continued http://paste.ubuntu.com/24923578/
<cpaelzer> which means I'd need a way to atatch earlier :-/
 * Laney tries some backports
<seb128> Laney, you should try some hangout :-)
<Laney> ffs
<cpaelzer> maybe with follow forks to an interim one that stays a while
<seb128> we are waiting for you :p
<mitya57> cpaelzer, maybe you can attach gdb instead of strace?
<Laney> :/
<Laney> wait a minute
<mitya57> cpaelzer, actually by stacktrace, I meant one from gdb
<mitya57> (though it may be also not very interesting)
<cpaelzer> mitya57: it is just as borked http://paste.ubuntu.com/24923590/
<cpaelzer> whatever it is it already happened
<cpaelzer> I'm starting the qtmultimedia one to avoid this being a complex red herring
<mitya57> :(
<mitya57> cpaelzer, yes, maybe qtmultimedia would be different
<cpaelzer> Attached strace with -ff and such to  "/usr/bin/dh build" while it was running /usr/bin/dh_auto_build
<cpaelzer> That way it should track whatever follows
<cpaelzer> And it is now in debian/rules override_dh_auto_test-arch - so who knows maybe we find something
<cpaelzer> but obviously this is a huge slowdown-fest now :-)
<cpaelzer> mitya57: hmm maybe - does that match your qtmultimedia hang http://paste.ubuntu.com/24923618/ ?
<cpaelzer> hmm seems similar - this time ./tst_qdeclarativemultimediaglobal
<mitya57> cpaelzer, yes, it does
<cpaelzer> full process chain http://paste.ubuntu.com/24923623/
<mitya57> cpaelzer, I wonder how make[4] has exited if a child process is still running?
<mitya57> Do you have the full log? (stdout/stderr, not strace)
<cpaelzer> well I have my console and buildlog
<cpaelzer> so yes
<cpaelzer> in any case the follow fork strace workd here FYI http://paste.ubuntu.com/24923638/
<cpaelzer> that is the haning pid
<cpaelzer> here also the build log so far http://paste.ubuntu.com/24923644/
<sil2100> Laney: hey! I'm a bit of an autopkgtest noob - I triggered a test run through an explicit command through the request.cgi URL, I saw the test running and now that it's finished, where can I see the logs for it? I don't see it in http://autopkgtest.ubuntu.com/packages/matlab2tikz/artful/amd64
<Laney> sil2100: for a PPA?
<sil2100> Laney: yeah
<mitya57> cpaelzer, thanks, so maybe the issue is actually somewhere in Qt test runner.
<Laney> https://wiki.ubuntu.com/ProposedMigration/#Testing_against_a_PPA
 * sil2100 reads up
<sil2100> Laney: thanks!
<mitya57> here we also have this:
<mitya57> QWARN  : QDeclarativeMultimediaGlobal::test_convertVolume() file:///usr/lib/s390x-linux-gnu/qt5/qml/QtTest/TestCase.qml:1781: TypeError: Cannot read property 'tag' of undefined
<cpaelzer> mitya57: the gdb backtrace looks just the same
<cpaelzer> as in the former case
<mitya57> If the test runner was in C++, I would like to add a breakpoint on the line where that TypeError is printed, but it is in QML so that would be difficult.
<cpaelzer> FD 5 which it polls on seems to be eventfd
<mitya57> That doesn't say anything to me :(
<cpaelzer> I wonder that the full starce has no open/socket/... that returns =5
<cpaelzer> usually that is what I expect for those FDs
<mitya57> cpaelzer, what do you think about trying valgrind? bad idea?
<cpaelzer> bad idea
<cpaelzer> valgrind needs to rewrite code so you need to atatch upfront
<cpaelzer> if I would set that up working I'd attach gdb
<cpaelzer> the hard part is to "catch" it in between all the build systems complexity
<cpaelzer> that is why the strace -ff was neat to track at least a bit
<mitya57> cpaelzer, I can tell you how to run the test process directly
<cpaelzer> well lets try
<mitya57> Then you should be able to set up gdb
<cpaelzer> but for that I'll first kill my sbuild and do a debian/rules build locally in the dir
<cpaelzer> I hope that this hangs as well then
<mitya57> You can use the already built files
<cpaelzer> this is the most default sbuild setup - not sure if it leaves something around if I kill it now
<mitya57> You can chroot to it?
<cpaelzer> already searching the id
<cpaelzer> hrm the mountpoint it had in the buildlog is gone
<cpaelzer> and I don't want it to still hang with the sbuilds hanging processes
<cpaelzer> even cleanup is not set and it said it didn't
<cpaelzer> weird
<cpaelzer> but that reproduces pretty fast - I should soon have one ready
<cpaelzer> making build deps and all that avail ...
<cpaelzer> I'll ping you then mitya57
<cpaelzer> once ready or once I've given up to screw my system into a non working state :-)
<mitya57> cpaelzer, thanks once again for your efforts :)
 * cpaelzer has a mainframe heart
<mitya57> cpaelzer, in any case, something like this http://paste.ubuntu.com/24923708/ should allow you to run the test directly
<mitya57> (replace PKGBUILDDIR with /path/to/qtmultimedia-opensource-src-5.9.0/)
<mwhudson> Unit193: ugh
<cpaelzer> ok will let you know then
<cpaelzer> ah 12 cpus, now this should be faster :-)
<cpaelzer> mitya57: if that is any relive - at least repro-wise - /usr/bin/debuild -eDEB_BUILD_OPTIONS=parallel=12 -us -uc runs just into the same hang
<cpaelzer> so all the sbuild is not needed to trigger - ehading to try the test manually now
<cpaelzer> mitya57: ok all complete I can trigger jsut the broken test now
<mitya57> \o/
<cpaelzer> gdb atatched and running
<cpaelzer> mitya57: http://paste.ubuntu.com/24923770/
<cpaelzer> I might need to make the libs debuggable
<cpaelzer> did you have dbgsyms in your ppa enabled?
<mitya57> cpaelzer, not much interesting, the dbgsyms won't help.
<cpaelzer> mitya57: I'll have a longer lunch break soon'ish - you can then plan what you'd need from me when I'm back
<cpaelzer> anything that would help to make that plans to exec immediately?
<mitya57> I don't have many ideas :(
<mitya57> Maybe my question about valgrind again?
<cpaelzer> It is too QT'y for me to have much ideas - most thing look like "Uh desktop?" to me
<Laney> cpaelzer: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2835/+packages looks like s390x is hanging on zesty and artful but passing earlier
<cpaelzer> I can run it, although I'd not expect a lot from valgrind here - we are not looking for leaks do we?
<mitya57> cpaelzer, Or maybe catch writes to stderr and get a stacktrace of the point where the warning is print?
<mitya57> *printed
<cpaelzer> you mean the one about the tag?
<mitya57> Yes
<cpaelzer> yeah - can try that after lunch
<mitya57> Sure
<mitya57> Laney, interesting, with Qt we didn't get anything like this on Zesty.
<Laney> although...
<Laney> again on y and x the tests are just failing
<Laney> mitya57: I guess something different
<cpaelzer> valgrind also thinks the program is exited yet hangs
<cpaelzer> maybe the main thread went away
<cpaelzer> pasting valgrind log for you and then back after lunch
<cpaelzer> mitya57: http://paste.ubuntu.com/24923957/
<cpaelzer> if we want other valgrind tools later let me know
<mitya57> I would expect some invalid read/write warnings right before that QWARN, but there are none
<mitya57> cpaelzer, a question for after lunch: can you edit /usr/lib/s390x-linux-gnu/qt5/qml/QtTest/TestCase.qml? Maybe some debug prints there would give more information
<Judge> Hi everyone. How can I see how an application in an Ubuntu package was compiled?
<Judge> ... or configured for compilation?
<pitti> Judge: easiest is to check the build log
<pitti> e. g. https://launchpad.net/ubuntu/+source/cockpit -> select version -> select architecture -> buildlog
<xnox> Judge, pull-lp-source $srcpackage -> read debian/rules that should clearly show any non-default options.
<xnox> and patches applied from debian/patches
<Judge> pitti: Perfect, thanks
<cpaelzer> mitya57: is there anything in qt like a "set -x" in shell?
<mitya57> good question
<mitya57> *maybe* QT_FATAL_WARNINGS=1
<mitya57> But with that variable it will fail on the "JIT is disabled for QML. Property bindings and animations will be very slow." warning
<Unit193> mwhudson: Thanks for looking into it. :>
<mitya57> cpaelzer, the debug symbols in my PPA are enabled, so you can install libqt5core5a-dbgsym and break on QMessageLogger::warning
<mitya57> cpaelzer, but first please tell me if you can edit /usr/lib/s390x-linux-gnu/qt5/qml/QtTest/TestCase.qml
<cpaelzer> mitya57: already adding the 7th debug statement
<mitya57> haha
<mitya57> cpaelzer, for reference, this is how successful test output looks like: http://paste.ubuntu.com/24924174/
<mitya57> It somehow passes for linear -> linear and linear -> cubic, but does not like linear -> logarithmic even though it is very similar.
<cpaelzer> the row object is non existant in the error case
<cpaelzer> the subsequent access to an element under that object makes it hang
<cpaelzer> it doesn't reach the line afterwards
<cpaelzer> is there a "is_defined" or anything like it?
<cpaelzer> might need to skip the whole thing
<cpaelzer> in case it is not existing
<mitya57> try âfoo !== undefinedâ
<cpaelzer> but also - why is this arch dependent
<mitya57> it may be endianness dependent, as s390x is the only big endian arch in Ubuntu
<cpaelzer> code uses "=== undefined"
<cpaelzer> will go with that
<mitya57> yes, !== is the opposite to ===
<cpaelzer> seems reasonbale :-)
<cpaelzer> it goes into table[index] and gets an undefined
<cpaelzer> so isn't that an out-of-bounds in some way
<cpaelzer> need to check what that table holds
<mitya57> right
<cpaelzer> seems to hold about 100 entries (the tests parameters I guess)
<cpaelzer> but on index 10 it breaks
<cpaelzer> from the good test is the order of the testcases up to that the same?
<mitya57> Yes, the same
<cpaelzer> -1.0 from linear to logarithmic
<cpaelzer> that is what we would expect
<mitya57> cpaelzer, the table should contain the entries defined in tst_qdeclarativemultimediaglobal.qml from line 68
<mitya57> yes
<mitya57> cpaelzer, what is table.length?
<mitya57> It should be 88 if I count right.
<cpaelzer> 88
<cpaelzer> all index above 10 are undefined
<cpaelzer> I can "finish" the tests by skipping
<cpaelzer> mitya57: http://paste.ubuntu.com/24924216/
<mitya57> cpaelzer, and what does that print?
<cpaelzer> just a sec, modifying the testcase def to see its influence
<cpaelzer> mitya57: http://paste.ubuntu.com/24924234/
<cpaelzer> that is with two tests taken out of the def
<cpaelzer> and it proves it is not the definition of the case
<cpaelzer> but always test #10
<cpaelzer> so I have a table of length 88 that I can only access 0-9
<cpaelzer> the other issues might just as well be such out of bounds access
<mitya57> cpaelzer, that is very strange, but also very interesting
<cpaelzer> and it seems it can survive the first out of bounds - asnering with an undefined object
<cpaelzer> but the access to an element  of that undefined object then kills it
<cpaelzer> it creates the QWARN we saw and hangs on there
<cpaelzer> mitya57: the fact that these lists are broken might be arch specific (maybe endiness as you suggested) - and the other part that the error hangs might be whatis new in artful
<mitya57> cpaelzer, if you change the order of tests in tst_qdeclarativemultimediaglobal.qml, is behavior the same?
<cpaelzer> mitya57: yes
<cpaelzer> mitya57: always #10
<cpaelzer> mitya57: so it depends on size if anything
<cpaelzer> mitya57: http://paste.ubuntu.com/24924267/
<cpaelzer> updated debug code
<mitya57> cpaelzer, minor nit: you need to wrap the two lines after âif (!row.tag)â in {...} otherwise the second line does not belong to if.
<cpaelzer> it is wrapped in the updaet
<cpaelzer> update
<cpaelzer> I got that a few minutes ago
<mitya57> Noâ¦
<cpaelzer> ah this one
<cpaelzer> yeah same logic - right
<mitya57> I think we already have enough material that I can report to Qt upstream.
<cpaelzer> yeah that is the only thing that comes to my mind
<cpaelzer> mitya57: let me make updates diffs and output
<cpaelzer> that you can then report
<mitya57> But maybe it will be a good idea to try creating a normal array and checking if indices >=10 work there.
<cpaelzer> mitya57: you can write some basic code that I can run while I collect the logs
<mitya57> cpaelzer, try adding this somewhere:
<cpaelzer> mitya57: be aware that it might dpeend on the size of the elements
<mitya57> I think it is an linked list rather than a vector
<cpaelzer> what ot add somewhere?
<mitya57> So how about this? var a = [0,1,2,3,4,5,6,7,8,9,10,11]; warn(a[10])
<mitya57> and also warn(a["10"])
<mitya57> When you use âfor (var i in array)â construct, i is a string rather than a number
<mitya57> cpaelzer, ^^
<cpaelzer> yeah just on that
<cpaelzer> I found iteration examples and will use those
<cpaelzer> just a fe wmins
<mitya57> Ok
<cpaelzer> for (var i = 0; i < states.length; i++)
<cpaelzer> like that is the recommende daccess
<cpaelzer> That is it mitya57
<cpaelzer> let me send latest diff and output
<cpaelzer> the fix becomes clear now
<mitya57> cpaelzer, In this case i would be an integer. But in the TestCase.qml index is a string. *That* might be broken.
<cpaelzer> http://paste.ubuntu.com/24924309/ http://paste.ubuntu.com/24924307/
<cpaelzer> mitya57: look at the arr iteration
<cpaelzer> with the for i in it is broken as soon as it is double digit
<cpaelzer> and with the alternative iteration on numbers it works
<mitya57> Oh oh oh we found the bug!
<cpaelzer> yeah
<mitya57> Thanks a lot!
<cpaelzer> I'll code up the fix for this case and try with that
<cpaelzer> you likely can apply that to about everywhere you block then
<mitya57> I think I can try to write a patch myself.
<cpaelzer> fix: http://paste.ubuntu.com/24924317/ - good case log http://paste.ubuntu.com/24924318/
<cpaelzer> mitya57: done
<mitya57> \o/
<cpaelzer> mitya57: but as I said this has to be fixed in many places for sure - maybe way more than the few hangs you had
<cpaelzer> mitya57: you can use all the output I pastebinit'ed before as example on your upstream contrib then
<mitya57> Either I or Qt upstream should figure out why array["10"] does not work â it should be supported
<cpaelzer> I think I reply our IRC log of the last hours onto the ML so that nobody spends time about thinking what might be wrong on LP-infra or s390x
<cpaelzer> mitya57: are you ok with that?
<mitya57> cpaelzer, OK!
<mitya57> But I still have no idea why this bug does not occur on Debian s390x
<cpaelzer> array["10"] really might be the place where endieness hits
<cpaelzer> I assume the warning for them is not having this blocking behaviour
<cpaelzer> mitya57: do they have the QWARN in their log?
<mitya57> cpaelzer, no
<cpaelzer> uuuh
<cpaelzer> ok well, I need to go on to the next package
<cpaelzer> glad I could help that far mitya57
<mitya57> cpaelzer, sure, your debugging helped me a *lot*
<cpaelzer> back to my beloved systemd/ntp error again ...
<mitya57> cpaelzer, tsimonq2: FYI https://bugreports.qt.io/browse/QTBUG-61579
<cpaelzer> thanks for the info mitya57
<nacc> xnox: right, I understand that -- but it doesn't *always* do that, even then (it seems).
<slangasek> infinity: #ubuntu-meeting?
<juliank> xnox: Does it even make sense that you self-assign the apt tasks when I already uploaded everything? Seems a bit odd ;)
 * juliank should probably have assigned that some time ago.
<juliank> But it certainly makes sense for you to do the u-u part :)
<xnox> juliank, yes it is odd.
<xnox> juliank, i was doing that, such that people keep asking me for updates on it.
<xnox> juliank, and such that it disappears from many reports of un-assigned bugs.
<xnox> thus it's mostly cosmetic change to pacify reports.
<juliank> :)
<juliank> We should also open another bug for improved reliability of network availability (apt-helper wait-online and automatic restart of service).  I think I know what to write, but we need a tracking bug for that anyway.
<juliank> I guess Ill do that once I'm on my laptop again.
<juliank> xnox: We especially have to pick a nice exit value for the helper.
<juliank> ;9
<juliank> exit(42) or something
<rbasak> slangasek: would you mind commenting on bug 1690228 please? I remember you saying that you considered ethtool to be deprecated, but I'm not sure I understand exactly why.
<ubottu> bug 1690228 in ethtool (Ubuntu) "Make ethtool installed by default in Ubuntu" [Undecided,Incomplete] https://launchpad.net/bugs/1690228
<rbasak> (or did I misunderstand?)
<nacc> rbasak: fyi, not sure if you saw, but folks are saying LP: #1590799 is not actually fixed
<ubottu> Launchpad bug 1590799 in nfs-utils (Ubuntu Yakkety) "nfs-kernel-server does not start because of dependency failure" [Medium,Fix committed] https://launchpad.net/bugs/1590799
<rbasak> Thanks nacc
<rbasak> tinoco: ^ could you investigate please?
<tinoco> rbasak: sure, adding to my list (next week most likely)
<nacc> tinoco: thanks -- had a user in #ubuntu also hit it (most likely)
<tinoco> i'm afraid it is another race (not the initial one) hopefully i'll reproduce (or will just ask for systemd logs)
<rbasak> Thanks. Yeah it looks like it may be multiple bugs.
<juliank> xnox: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1699850
<ubottu> Launchpad bug 1699850 in apt (Ubuntu) "Reliable network connectivity for apt-daily" [Undecided,New]
<juliank> Summary: Wait for up to 30 s for network connectivity, and retry every 15 minutes if not online yet.
<xnox> juliank, this might be easier on ubuntu, than on debian. in e.g. artful. by calling networkd-wait-online.
<juliank> xnox: That might have network online but no internet connectivity or stuff. The apt-helper will check if the hosts we actually need are online.
<juliank> xnox: The pseudo code is effectively optimized for the case where the first host is reachable, BTW.
<juliank> I assume there's no non-blocking alternative to getaddrinfo()?
<juliank> (Then we could just issue all DNS requests at once, potentially reducing wait time if first host is permanently offline - but how likely is that anyway)
<mitya57> What is the status of checkbox-converged? Currently it seems to be the only package in main still using ubuntu-ui-toolkit. Will it be ported?
<juliank> xnox: I'm unsure if we should just wait for one remote host, or maybe a majority
<juliank> If you configured localhost or something it might come up to early
<juliank> I guess we can exclude loopback addresses, though
<juliank> So, exclude 127.* and the IPv6 equivalent, and 1 successful connection, and we should be good to go IMO
<juliank> We'll try http hosts on port 80 or specified, https on 443 or specified, and either ignore the other ones (ftp, rsh, torrent, whatever) or just try 80 or something (or well, only DNS)
<slangasek> rbasak: what is this about it not being installed by default?  it's in the server and cloud-image seeds
<slangasek> rbasak: I think we may have talked about moving it out a layer or two in the packagesets from where it was earlier, but doesn't seem to have been moved any farther than that
<juliank> tkamppeter: I was looking for you recently. I got a Brother HL-2130 and that's working mostly fine with HL-2140 drivers (hpijs-pcl5e or hl2150, slightly different rendering). Maybe it's worth it adding them as HL-2130 ones too?
<nacc> slangasek: aiui, it shouldn't matter that user is netbooting to install ubuntu server vs. iso installing, as far as the packages that get installed, right?
<juliank> tkamppeter: You might have seen a message from me in a Debian bug about the device
<juliank> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635157
<ubottu> Debian bug 635157 in openprinting-ppds "Brother HL-2130 laser printer support" [Wishlist,Open]
<juliank> Stuff like manual duplex is not working (duplex checkbox does nothing), and one of the drivers fails at the highest setting (1200x600), but apart from that, it seems to work fine.
<juliank> (That's why I bought it in the first place, thanks to the Arch wiki, and it only costing me 25â¬ used with a toner with unknown capacity included)
<nacc> slangasek: rbasak: ok, that's the root cause of this bug, I'll respond in-bug
<slangasek> nacc: the netboot image isn't a "server" image, it's a generic "d-i" image, so comes with no default task selection
<gpiccoli> nacc, slangasek, rbasak : just commented there on LP 1690228
<ubottu> Launchpad bug 1690228 in ethtool (Ubuntu) "Make ethtool installed by default in Ubuntu" [Undecided,Incomplete] https://launchpad.net/bugs/1690228
<gpiccoli> Not sure if got mirrored already...
<gpiccoli> I'm here too, if you prefer more dynamic conversation than launchpad posts heh
<gpiccoli> slangasek, so what is a generic "d-i" image?
<gpiccoli> If iproute2 got installed, why ethtool shouldn't be, for example?
<cjwatson> iproute2 is in the minimal set (i.e. what debootstrap installs) but ethtool isn't; that's not a statement of intent, just an observation of current reality
<cjwatson> but I would hope developers would think hard before adding feature creep to minimal
<cjwatson> it isn't in general intended for the output of debootstrap to contain everything you might need to operate a server
<cjwatson> and personally I don't think it's a bug when the result of a netboot install is missing just about any package you might name; netboot installs are intended to be absolute bare minimum, and you can add more packages by preseeding or whatever
<gpiccoli> cjwatson, thanks! I partially agree with you
<gpiccoli> I agree with the part: " I don't think it's a bug when the result of a netboot install is missing just about any package you might name"
<gpiccoli> Problem is that: after the boot, how could I fix this, I mean, install this package, if I have no network?
<gpiccoli> hehehe
<gpiccoli> egg/chicken issue...you might need the troubleshoot tooling to allow you fix network in order to use machine
<cjwatson> Except if netboot works at all then by definition it can install things from the network.
<cjwatson> So that isn't valid.
<gpiccoli> Sometimes, the 'issue' is on switch you don't have access, like it's refusing some configuration your NIC sends...ethtool might come handy to fix this, by configuring NIC
<cjwatson> It must always be possible to nominate additional packages using preseeding, at the very least.
<gpiccoli> Yes, makes sense
<gpiccoli> but then, we can raise the follow-up discussion: would it make sense to have ethtool on installer itself?
<cjwatson> I agree it's useful to have some minimal set of configuration utilities; every additional package has incremental cost, so it's a judgement call.
<gpiccoli> For netboot installers, I do believe we need it. If not, we might not be able to progress the installation
<gpiccoli> cool cjwatson, agree with you
<gpiccoli> let's what will be this judgement heheh
<cjwatson> If it's needed in d-i, then I think it needs some thought to define exactly what the possible requirements might be in order that netcfg could support them.
<cjwatson> Just the tool being present is only of limited use.
<cjwatson> Note that netcfg already contains an ethtool-lite.
<cjwatson> Which is very cut-down and I think mostly read-only; but I think that indicates a design direction, i.e. just have netcfg implement the ioctls it needs to do the job rather than shipping ethtool.
<cjwatson> (netcfg's ethtool-lite is mostly just for detecting link presence at the moment, I think.)
<nacc> slangasek: ack, just commented to the same effect after thinking about it in the bug
<gpiccoli> oh, i wasn't aware of this ethtool-lite
<cjwatson> Like I say it's mostly just link presence, but I think it would be weird to end up in a situation where we had both ethtool-lite and ethtool in the installer - it would indicate not having thought things through globally, IMO.
<gpiccoli> exaclty, it makes sense
<gpiccoli> no need for ethtool0lite if we can have the full ethtool
<gpiccoli> By the way, how do I invoke ethtool-lite cjwatson ?
<gpiccoli> during installer, I mean
<cjwatson> also no need for ethtool if we work out the relevant bits and add them to ethtool-lite.  ethtool has a bunch of quite sophisticated stuff that won't be needed during installation.
<cjwatson> (or add them to netcfg directly.  whatever.)
<cjwatson> I don't recall, sorry.
<cjwatson> Look at the netcfg source package
<gpiccoli> yes, we might add the features to ethtool-lite..could be difficult though to map all stuff we need
<nacc> gpiccoli: but for making a core change that is absolutely what is going to be required
<nacc> gpiccoli: it can't be hand-wavy we need ethtool because we need ethtool :)
<cjwatson> Yep.  And in order to add installer UI it will be necessary to define the specific features that are needed.
<cjwatson> Seems that if we ended up with a system where we knew that some people were going to have to drop to a shell to use ethtool in the middle of the installation, we'd only have done half the job at best.
<gpiccoli> "it can't be hand-wavy we need ethtool because we need ethtool" <- what do we need to justify here?
<gpiccoli> Help me wording the request hehehe
<sarnold> a list of features that are preventing you frmo installing? :)
<cjwatson> Specific features that are currently provided only by ethtool that might be strictly required in order to get a system's network up.
<gpiccoli> for me, miss a tool to configure NICs in a small installer that only can work if network is fine, is a dangerous thing
<cjwatson> Most systems don't require ethtool.
<nacc> gpiccoli: just be specific as to what you can't do now
<gpiccoli> cjwatson and sarnold, thanks a lot! I'll raise such list
<nacc> gpiccoli: it can't be a theoretical list (IBM historical problem :)
<cjwatson> Try to keep it minimal.
<gpiccoli> great nacc, it's a good point!
<cjwatson> Don't just go over the man page and enumerate everything that looks kind of useful.
<cjwatson> It has to be actual things that definitely hit real systems.
<gpiccoli> I'll keep minimal, of course I won't say "I cannot see statistics of how much packets delayed more than X ms, so I cannot install" hahah
<cjwatson> And I would recommend a solution-neutral problem statement.
<gpiccoli> yes, I have a use case already, for i40e. i'll improve it
<gpiccoli> solution-neutral aka not say "I-need-ethtool-please" ?
<gpiccoli> heheh
<cjwatson> In each case, there might be some other sensible solution that doesn't involve people having to drop to a shell mid-install to use ethtool: kernel sorting it out by default, installer UI to configure things, embedding a couple of ioctls in some other tool, ...
<cjwatson> Having to manually configure network devices is pretty 1990s and we should be able to do better.
<gpiccoli> ok cjwatson, it does make sense. i got your point here, all you folks said are really valid and I'll take into account. Thanks a lot for the great feedback
<cjwatson> Thanks for listening :)
<gpiccoli> 90s was the best, I'm oldschool =D
<gpiccoli> Yw, thanks for your patience!
<mwhudson> watching vim build is hard on the eyes
<nacc> mwhudson: fyi, LP: #1571967 seems relevant to our earlier *.lxd discussions
<ubottu> Launchpad bug 1571967 in lxd (Ubuntu) ".lxd domain resolution not working after standard installation" [Wishlist,Won't fix] https://launchpad.net/bugs/1571967
<nacc> mwhudson: i've yet to actually get what we both wanted to 'just work', but stgraber's suggestion in there does make ssh work, at least
<mwhudson> wow that ssh suggestion is both awesome and terrible :)
<nacc> mwhudson: :)
<Unit193> mwhudson: Oh hi!  Are you active in the server team?  Do you know why python-moinmoin is needed in main?
<mwhudson> Unit193: i'm foundations theses days, and, no
<Unit193> OK.
<mwhudson> doesn't seem to have any rdeps in main though...
<mwhudson> so i guess it's seeded?
<nacc> mwhudson: not that i can see
<Unit193> (LP 586492 didn't say specifically why it was needed.)
<ubottu> Launchpad bug 586492 in parsedatetime (Ubuntu) "[MIR] parsedatetime" [Undecided,Fix released] https://launchpad.net/bugs/586492
<nacc> Unit193: oh good thinking -- if moin can be in universe, then parsedatetime would migrate?
<Unit193> nacc: They'd both have to go to universe, but yep.  And I don't see why moin is in main anyway.
<Unit193> 22371 seems to be as close as it gets, discusses main.
<nacc> Unit193: yeah that's the bug i was just reading
<nacc> slangasek: --^ are you able to help us determine this?
<nacc> Unit193: I *wonder* if the ubuntu wiki or something is moin
<nacc> Unit193: and so it's manually being held in main by request
<Unit193> nacc: Ubuntu wiki is moinmoin.
<nacc> Unit193: that might be why?
<nacc> Unit193: presumably we'd want to support our own infra :)
<Unit193> nacc: Heh, well by the name I thought it was a python module for interacting with it, would have expected the source to be 'moinmoin'.  Didn't look too closely at that.  We should just move to mediawiki to solve this then! :P
<nacc> Unit193: I am curious where that gets expressed. I wonder if it's an AA thing
<Unit193> nacc: So, this sounds like a problem then.
<nacc> Unit193: ok, moin shows up here: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/all+extra.sources
<nacc> Unit193: foudn it ... supported-misc-servers seed http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/supported-misc-servers.seed
<nacc> now why didn't seeded-in-ubuntu tell me that?
<Unit193> Because it doesn't like you.
<Unit193> nacc: But yes, we did find out why.  Now, how does one move forward?
<nacc> Unit193: i think we need to look at MIR'ing python-future -- that was the revdep, right?
<Unit193> Yeah, new parsedatetime also builds python3-parsedatetime too.
<infinity> MIRing python-future seems like a sane thing to do.
<infinity> Actually a bit shocked it's avoided main this long.
<nacc> infinity: yeah, i think it seems reasonable
<nacc> Unit193: do you want to file the MIR?
<Unit193> nacc: That'd be better coming from a team member, wouldn't it?
<nacc> Unit193: well, it was your upload request :)
<nacc> Unit193: i can file it, though, probably not til tmrw
<Unit193> nacc: Correct, but I'm not in the team so can't subscribe them to the bug mail, and making a MIR request on behalf of a team that I've not discussed it with seems bad form.
<nacc> Unit193: which team do you mean?
<Unit193> Server team.
<nacc> Unit193: oh, i am :)
<nacc> Unit193: i am in that team, i mean
<nacc> infinity: is it normal that seeded-in-ubuntu doesn't show the misc-server seed? e.g., above it didn't show that python-moinmoin and it's not showing me, e.g. that src:nagios3 has several packages seeded in supported-misc-servers
<Unit193> nacc: FYI, this is all for the new gcalcli, which my sponsor is interested in pushing it to unstable rather than experimental.  It was ported to py3.
<nacc> Unit193: sure, but this other revdep path shows that the new parsedatetime would have gotten stuck anyways (and so python-future needs the promotion). So given that, I'll file the MIR :)
<Unit193> nacc: Right, which was why I wasn't too stressed about my request for it.
<infinity> nacc: It's normal that seeded-in-ubuntu isn't a perfect tool, I believe.  I'm sure the folks who run it would appreciate patches.
<Unit193> I thought all Ubuntu tools were perfect and ported to py3. :3
<infinity> Unit193: Fairly sure neither of those things is true.
<Unit193> infinity: Yep. :)
<Unit193> (https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1099537)
<ubottu> Launchpad bug 1099537 in ubuntu-dev-tools (Ubuntu) "ubuntu-dev-scripts should be ported to Python 3" [Medium,In progress]
<nacc> infinity: sure, i just noticed that particular quirk. I'm happy to work on it! :)
<nacc> infinity: and sometimes what i perceive as a quirk is really PEBKAC
<infinity> nacc: I have a 100% track record for blaming myself when the software's at fault, and vice versa.
<nacc> infinity: heh
<slangasek> nacc, Unit193, infinity: FTR, branch archaeology tells me moin is grandfathered into main from the original server seed and that this was last revisited only in 2009 when we moved it from server CD to supported.  It may be worth asking IS and/or the product manager if it still belongs
<nacc> slangasek: yep, i've filed a note to review that whole misc-servers seed
<nacc> slangasek: as there are some other old entries in there
<Unit193> Might be nice to get pdt into universe, yeah.
<nacc> Unit193: yep, i've made a trello card (our newer tracking mechanism) for server and i'll review it with the team
<Unit193> nacc: Thanks!
<nacc> https://trello.com/c/rr2vMcsr for documentation publicly
<nacc> rbasak: doing some more refactoring to `git ubuntu build` but i should have a pristine-tar version working tmrw, i think
#ubuntu-devel 2017-06-23
<mwhudson> does anyone see what happened here? https://launchpadlibrarian.net/325167198/buildlog_ubuntu-artful-s390x.vim_2%3A8.0.0197-4ubuntu3_BUILDING.txt.gz
<sarnold> no idea. but I got a giggle out of this "Test BufferLength and BufferAssSlice"
<tsimonq2> hah
<slangasek> so who's blindly retrying haskell package builds to punish me? :)
<sarnold> ugh
<sarnold> I don't know what you did to deserve thjat but that's a mean thing to do to someone
<slangasek> sarnold: what I did was upload no-change rebuilds for the transition, now someone's retrying them without looking at the build logs ;)
<tsimonq2> slangasek: I've been getting emails on artful-changes.
<tsimonq2> slangasek: he-who-is-never-on-irc :P
<rbasak> slangasek: ah. So you think it's appropriate to be there, just not in the minimal seed? I must have got you confused with someone else saying it was deprecated and should be removed altogether.
<sil2100> Hey! Anyone here could force ignore octave-io's failing armhf test? Checking the logs it's been failing for longer and from the logs (and one re-run) I see that random tests seem to be failing, not the same ones everytime
<sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#octave-io
<ginggs> sil2100: i cannot even see where it was ever successful, but britney seems to think it was
<ginggs> sil2100: i don't know if it matters, but #ubuntu-release is usually the channel for that
<sil2100> ginggs: thanks!
<flexiondotorg> Any MOTUs or core devs here who could take a look at LP: #1699333 and LP: #1699334 please?
<ubottu> Launchpad bug 1699333 in Ubuntu "[needs-packaging] vala-panel" [Wishlist,Confirmed] https://launchpad.net/bugs/1699333
<ubottu> Launchpad bug 1699334 in Ubuntu "[needs-packaging] vala-panel-appmenu" [Wishlist,Confirmed] https://launchpad.net/bugs/1699334
<flexiondotorg> I'd like to include there in Ubuntu MATE 17.10 Alpha 1. Ubuntu Budgie are interested in the packages too.
<seb128> flexiondotorg, how come you are not MOTU yet? ;-)
<flexiondotorg> Long term I'll ask the DMB to add them to my packageset so I can maintain them.
<flexiondotorg> seb128 I know right.
<flexiondotorg> On the long list of "stuff I should do".
<seb128> flexiondotorg, replying to your direct question, I can try to have a look on monday but today is just too busy with things I've to do already
<flexiondotorg> seb128 Thanks.
<flexiondotorg> If anyone is able to improve on seb128's kind offer, I'd appreciate it :-)
<jbicha> flexiondotorg: apply to be a Debian Maintainer too :)
<flexiondotorg> jbicha In progress :-)
<slangasek> rbasak: I think I may have said at one point that it was deprecated, but I may have been wrong ;)
<rbasak> slangasek: no problem. I think we're all clear on it now. Well, to be clear, ethtool is staying seeded, but not in minimal since it doesn't need to be in minima.
<rbasak> l
<mapreri> somebody know what's wrong with https://launchpad.net/ubuntu/+source/opencv/3.1.0+dfsg1-1~exp1ubuntu1/+build/12795080 ?
<mapreri>  sbuild-build-depends-opencv-dummy : Depends: libvtk6-dev but it is not going to be installed
<mapreri> not really geared to test installation issues of !x86 in ubuntu (and I don't use dose, etc)
<oSoMoN> awe_, hey, I see that you did some extensive testing on bug #1585863 a while back, would you be able to test Aron's packages in https://launchpad.net/~happyaron/+archive/ubuntu/nm-oem/+packages to confirm the fix on xenial by any chance?
<ubottu> bug 1585863 in OEM Priority Project xenial "WiFi malfunction after suspend & resume stress - sudo wpa_cli scan required to fix it." [Critical,Triaged] https://launchpad.net/bugs/1585863
<awe_> oSoMoN, I can take a look, but from my recollection, the bug was considered fixed when a new version of network-manager was SRU'd
<awe_> so Aaron's patches weren't required
<awe_> see comment https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1585863/comments/94
<ubottu> Launchpad bug 1585863 in OEM Priority Project xenial "WiFi malfunction after suspend & resume stress - sudo wpa_cli scan required to fix it." [Critical,Triaged]
<awe_> four dollars re-opened the bug based on two comments with zero details
<oSoMoN> awe_, yeah, after reading all the comments in the bug it wasn't clear to me either that the patches were required
<oSoMoN> if 1.2.6-0ubuntu0.16.04.1 that's in xenial already fixes the issue, then perfect
<oSoMoN> FourDollars: I know it's EOW for you, but when you get a chance would you mind commenting on bug #1585863 to clarify the situation?
<ubottu> bug 1585863 in OEM Priority Project xenial "WiFi malfunction after suspend & resume stress - sudo wpa_cli scan required to fix it." [Critical,Triaged] https://launchpad.net/bugs/1585863
<oSoMoN> thanks!
<awe_> oSoMoN, I added an additional comment to the bug
<awe_> which provides a method for checking whether the bug has been hit or not
<awe_> the problem is that sometimes when coming out of S3
<awe_> NM failed to initiate  WiFi scanning
<awe_> and if it doesn't scan
<awe_> it can't detect APs
<awe_> which means it's re-connect to APs
<oSoMoN> awe_, thanks, thatâs very helpful! Hopefully 1.2.6 did fix the issue, and no more work will be needed on that one
<oSoMoN> letâs see if F_ourDollars can clarify the situation
<awe_> willcooke might also be interested to hear that this has been re-opened
 * willcooke reads
<awe_> (maybe "interested" isn't the right word)
<awe_> ;)-
<willcooke> hqa
<willcooke> ha
<willcooke> Yeah, so I /think/ it is fixed.  But I was confused by that bug as well
<willcooke> Pretty sure we'd be hearing a lot more about it if it was still broken.  But good to be sure
<FourDollars> oSoMoN: Aron's patch is still needed. Please check the bug comments again.
<oSoMoN> FourDollars, thanks mate, Iâll work on the SRU then
<awe_> based on what evidence?
<FourDollars> oSoMoN: Thx a lot.
<awe_> willcooke, can we bring jbicha into the conversation?
<willcooke> awe_, I don't think he'll know about this one, he's only done the merge from Debian (n-m 1.8)
<awe_> the bug doesn't even say *which* patch is required
<willcooke> yeah, I think this might be a red herring
<oSoMoN> I gotta take off for today, Iâd appreciate if relevant bits of the conversation could be saved to the bug report
<willcooke> oSoMoN, sure thing
<oSoMoN> thanks!
<awe_> I think my comments says it all
<awe_> we need proof something is broken before we decide a patch is needed
<mapreri> somebody can guess what's wrong with https://launchpad.net/ubuntu/+source/opencv/3.1.0+dfsg1-1~exp1ubuntu1/+build/12795080 ?    â slangasek ?  (given you seemed so interested ^^)
<slangasek> mapreri: you might be able to decipher it using chdist to see why it might be uninstallable on that arch
<mapreri> ok, it's due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865465
<ubottu> Debian bug 865465 in src:openmpi "openmpi FTBFS on s390x: undefined reference to opal_atomic_*" [Serious,Fixed]
<nacc> mapreri: http://paste.ubuntu.com/24933694/
<nacc> mapreri: it's uninstallable with artful-proposed on s390x
<mapreri> yeah, got to it
<mapreri> eventually
<mapreri> pity, but should be fixed by the next autosync, theoretically
<slangasek> mdeslaur: have you seen LP: #1700079 ? I am unconvinced from the description that it's a regression vs. a race-condition in the systemd unit
<ubottu> Launchpad bug 1700079 in openvpn (Ubuntu) "openvpn broken after unattended security upgrade" [Undecided,New] https://launchpad.net/bugs/1700079
<rbasak> slangasek: that's from adac and/or frickler in #ubuntu-server earlier today. Two people reported the same thing, so I asked for a bug report.
<sarnold> slangasek: btw mdeslaur is out for the weekend
<slangasek> sarnold: ok.  would someone else from security look at this, should I assign the bug to him so he sees it on his return?
<sarnold> slangasek: probably best to assign it to him, none of us spotted anything in postinsts or unit files or elsewhere. :/ I'm not even sure if this is expected or not. Is it?
<slangasek> sarnold: it is not expected that restarting the server on upgrade fails?
<sarnold> slangasek: hrm. I read too quickly I thought that was the hanging clients that everyone experienced.. hrm.
<sbeattie> slangasek: the curious thing is it only happening with unattended upgrades, both reporters in #ubuntu-server last night were unable to reproduce it outside of that. Though it could just be unattended upgrades making it easier to lose whatever race is happening.
<slangasek> sbeattie: how many times did they try outside of unattended-upgrades?  sample size of 4 isn't much to draw conclusions from
<sbeattie> slangasek: unknown
<LocutusOfBorg> hello apw, how do you feel about suricata sync/merge?
#ubuntu-devel 2017-06-24
<jbicha> I got LP email for 2 comments made today on LP: #1305122 but now I don't see those comments in the web UI at all
<ubottu> Launchpad bug 1305122 in gnome-photos (Ubuntu) "GNOME Photos will not start." [Undecided,Confirmed] https://launchpad.net/bugs/1305122
<cjwatson> jbicha: They've been hidden, probably by the person who made them.
<cjwatson> (They're not abusive so I don't see why they'd have been administratively hidden.)
<jbicha> oh I didn't realize I could hide my own comments
<jbicha> thanks
<egonsen> hi. where do i start if i want to contribute code to ubuntu? i thought of starting with small bug fixes
<jbicha> egonsen: when you've fixed a bug, you can ask for sponsorship of the bugfix: https://wiki.ubuntu.com/SponsorshipProcess
#ubuntu-devel 2017-06-25
<hggdh> folks, please see bug 1700373
<ubottu> bug 1700373 in intel-microcode (Ubuntu) "Please update microcode to version 20170511 on all supported platforms" [Undecided,New] https://launchpad.net/bugs/1700373
<hjd> Could someone please trigger a rebuild of jabref in artful? Not sure why it failed the last time, but it built successfully for me when I tried in a vm. TIA :)
<ginggs> hjd: retrying
<CasW> Hey guys, if I recall correctly, Ubuntu had a list of a hundred or a thousand "paper cuts", right? Do they still have that, and where would I be able to find it?
#ubuntu-devel 2018-06-18
<doko> jamespage, coreycb: there are some oslo related autopkg failures in proposed ...
<jamespage> doko: yes on my list for today - I'm just shoving a load of py3 enablement into a PPA for testing and I'll switch onto those
<jamespage> one of them had me baffled so need to dig in a big
<rbasak> mvo: around? /snap/bin isn't in PATH in a non-interactive shell, eg. via ssh. So for example "ssh <host> lxc profile set default ..." fails. AFAICT, snapd packaging only drops in /etc/profile.d/apps-bin-path.sh which only affects login shells. For non-login shells, only /etc/environment applies. Is this intended, and/or any suggestions on fixing it?
<rbasak> It feels like a wart when using snaps on servers.
<rbasak> bug 1771858 seems relevant
<ubottu> bug 1771858 in snapd (Ubuntu Cosmic) "/snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH" [Undecided,Confirmed] https://launchpad.net/bugs/1771858
<ogra_> xnox, is that a black/white rainbow you added to your email address ?
<xnox> ogra_, full bleed colors here, on recent bionic, with all the emojis installed.
<xnox> ogra_, if you see black/white it means emoji support is borked.
<ogra_> ah, i live in the past ... (cant really let unity go)
<ogra_> (16.04 here)
<xnox> e.g. launchpad.net/~xnox renders correctly on e.g. android phone
<xnox> ogra_, mostly did it to see how much stuff is broken. doko & bdmurray reported that thunderbird is broken.
<xnox> ogra_, and i see some breakage in some web-browsers too. Imho, if one cannot see colored emojis right, it's not a desktop worth having anymore.
<ogra_> they are just holding it wrong :P
<rbasak> mvo: I filed bug 1777445.
<ubottu> bug 1777445 in snapd (Ubuntu) "/snap/bin isn't in PATH in a non-interactive shell, eg. via ssh" [Undecided,New] https://launchpad.net/bugs/1777445
<xnox> ogra_, can you open launchpad.net/~xnox in firefox and check if that is colorful or black & white?
<ogra_> xnox, FF renders it fine on xenial
<ogra_> rbasak, there is also https://bugs.launchpad.net/snappy/+bug/1659719
<ubottu> Launchpad bug 1659719 in livecd-rootfs (Ubuntu) "ssh can't call a binary from a snap without the full path" [Medium,Fix committed]
<ogra_> (which made us add it to /etc/environment in core images)
<rbasak> ogra_: ah. That's exactly the bug I just filed. But no bug against the snapd package? I can dupe and add that task.
<ogra_> rbasak, well, i only wanted you to be aware, perhaps yours is better (newer, not so rotten ... and better title)
<ogra_> when i brought up /etc/environment recently with the core team i was told thats too ubuntu specific and the generators will eventually solve it in 18.04#
<rbasak> xnox: ^ do you know if the generators will solve it in the ssh non-interactive case? Does ssh involve systemd in that case?
<rbasak> ogra_: I agree it's Ubuntu-specific - hence the task on the snapd packaging in Ubuntu. mvo's problem :-P
<rbasak> I don't know of a good way of solving this though, if systemd generators won't work.
<rbasak> /etc/environment isn't .d-ized.
<xnox> rbasak, so there are user-environment-generators as well as system-environment-generators, reading openssh code, i was hoping that it may solve this, if the sshd's environment PATH= variable is correct. But testing here locally I do not believe that to be the case.
<rbasak> xnox: AFAICT, ssh is using PAM and pam_env which reads from /etc/environment only.
<xnox> rbasak, i believe that user-environment-generators are executed by user-session systemd and children, therefore by pam_systmed (logind).... but not sure if all that works in practice.
<xnox> rbasak, hm. i thought you are hitting this because pam is not used / full login shell is not setup....
<rbasak> I could be wrong
<xnox> rbasak, cause if pam is running /etc/profile.d/* would be process, and /snap/bin should be in $PATH
<xnox> (not "is runing" but "was used")
<xnox> rbasak, i see that openssh has _PATH_STDPATH too.... which is fixed.... and in some cases appears to be used.
<rbasak> systemd-logind does show a new session when I run ssh non-interactively
<rbasak> pam_unix(sshd:session): session opened (etc)
<xnox> can't tell if that is customizable, and if it is used by shells when used non-interactively
<xnox> hmmm.
<xnox> rbasak, you can try dropping:
<xnox> #!/bin/sh
<xnox> PATH=$PATH:/snap/bin
<xnox> as an executable binary into /usr/lib/systemd/user-environment-generators/ and reboot; retest?
 * xnox doesn't want to drop my user session here =)
<xnox> i guess i can try this in lxd container
<rbasak> Trying
<rbasak> I'm using a VM
<rbasak> No effect
<rbasak> Hang on. If that's an executable, how will systemd ever see what it set?
<rbasak> Should it be echoing something?
<xnox> hmmm
<xnox> yes it should be an echo
<xnox> good point, me fails at typing
<rbasak> Still nothing
<xnox> /* read $HOME/.ssh/environment. */
<mvo> rbasak: aha, thank you. we where looking into providing a systemd environment generator
<mvo> rbasak: aha, I see you discussed this, sorry in a meeting, I will read backlog
<xnox> mvo, well, but that's to fix something else. which looks like will not fix the usability issue over non-interactive ssh.
<mvo> xnox: meh, yeah, just read backlog, this looks tricky
<cjwatson> rbasak,xnox,ogra_: Having to ever touch /etc/environment would be pretty poor.  I wonder if a good approach might be to provide a pam_snap session module which would add itself to PATH in the environment, and plug that in via /usr/share/pam-configs/ ?  You'd want to discuss that sort of thing with slangasek though.
<cjwatson> In fact let me suggest that in the bug
<Laney> There's an /etc/environment.d generator thing
<cjwatson> Maybe, but generating /etc/environment is terrible
<Laney> I think it reads /etc/environment and then runs all of the generators to update those variables
<cjwatson> Well, that isn't going to work with the pam_env config as-is
<cjwatson> And I'm not sure it would be particularly straightforward to make it do so, absent ... a PAM module
<cjwatson> /etc/environment was AIUI always meant for admin overrides and I think it's a fundamental misunderstanding for people to try to use it as the baseline for distro configuration
<Laney> Fine if it doesn't work for some reason, I'm just saying that editing /etc/enviornment is not the configuration mechanism you'd use.
<Laney> You can also use /usr/lib/environment.d/ (environment.d(5))
<cjwatson> It just seems like a fundamental category error
<cjwatson> This is about PAM-using service session behaviour so it belongs in a PAM module IMO
<Laney> I think the idea is you get a systemd --user from pam_systemd which ought to run these generators.
<Laney> Annyway.
<slangasek> cjwatson: I would much prefer to put it in /etc/environment than add more moving parts at runtime
<slangasek> "meant for admin overrides" - I don't know that this is historically accurate
<cjwatson> Hasn't it been widely advertised as something to be edited by admins?
<cjwatson> I get severe twitches when people propose mixing admin-editable things and stuff that the distro fiddles with
<slangasek> well, yes it's user-editable
<slangasek> but we don't have a non-config-file default environment
<cjwatson> Laney: But the context of this bug is individual commands started by ssh in place of a full-fledged user session, and AIUI those don't involve systemd --user
<cjwatson> sshd execs those commands directly using execve()
<cjwatson> So the PAM environment needs to be right or it won't work; a systemd generator cannot help, unless I suppose something like pam_systemd ran it and stuffed the answer back into the PAM environment
<cjwatson> (I assume that would be a bad idea for other reasons, but don't really know)
<rbasak> cjwatson: do you consider PAM as the solution then for both the interactive and non-interactive cases?
<rbasak> Or just non-interactive?
<cjwatson> rbasak: I don't know if I care if more than one thing handles it in the interactive case
<rbasak> OK. That's what I was wondering :)
<cjwatson> If slangasek prefers to hack /etc/environment (presumably in libpam-modules, since I see that has similar hacks today), then I won't stand in the way of that; that would be sufficient
<xnox> cjwatson, slangasek - i dislike modifying distro to fit around snapd; I would prefer for snapd to ship a new pam module and activate that on all distros to inject /snap/bin -> as that would work across all distros.
<smoser> is there a known issue with keyserver.ubuntu.com over the past few days ?
<teward> smoser: IS would probably be where that question has to go, they run the keyserver.  Laney mentioned something about that in #launchpad a couple hours ago as well, maybe follow up with IS?
<smoser> teward: yeah. i am doing that too, just wanted to avoid the higher escalation if it was known.
<smoser> slangasek: aroudn ?
<slangasek> smoser: off today, sorry
<slangasek> xnox: "modifying the distro to fit around snapd" - snapd is an integral part of our Ubuntu platform, and we shouldn't have to add extra pam modules to have the path correct.  A PAM module may make sense for other distros for whom snapd is optional
<smoser> slangasek: no worries. thanks for responding. i followed up on your locale mp
<slangasek> smoser: ack. the idea of putting this in base-files is not unappealing to me :)
<smoser> i'm interesetd in the justification of "cloud-init should do it but it should not be in ubuntu proper"
<smoser> (and /me is really afk now)
<slangasek> smoser: yeah, I don't have any justification for cloud-init continuing to own it, I was just trying to fix the code where it is - but having taken a step back, I do think it would be a good idea to move this elsewhere, so that e.g. we DTRT even on non-cloudinit systems
#ubuntu-devel 2018-06-19
<xnox> slangasek, only if we drop games from $PATH
<tseliot> xnox: hi, I've finally backported a couple of patches for systemd to fix LP: #1777099 . What's the best way to get them into Cosmic and Bionic?
<ubottu> Launchpad bug 1777099 in systemd (Ubuntu Bionic) "[backport] DRM devices opened by logind stay referenced indefinitely by PID 1" [High,In progress] https://launchpad.net/bugs/1777099
<xnox> tseliot, attach a debdiff and i include it in the next upload shortly? i need to fix up broken postinst too in systemd.
<xnox> tseliot, of, if they are cherrypicks and apply cleanly then just commit ids.
<xnox> tseliot, and well, cosmic will be getting v239 soon.
<xnox> tseliot, cause there is helper scripts which make it trivial to cherrypick upstream commit ids.
<xnox> tseliot, did you get those patches backported into the stable tree by the way?
<tseliot> xnox: I had to adjust the commits, since they wouldn't apply cleanly, and no, I haven't talked to upstream about the backport, if that's what you mean
<xnox> tseliot, cool attach the diff / patches to the bug, and i can upload it with the next update.
<xnox> and then sheparhd the autopkgtests / validation / releasing it
<tseliot> xnox: ok, thanks
<doko> chrisccoulson: cargo probably needs a version bump, because dh-cargo in proposed doesn't migrate
<tseliot> xnox: ok, I've just attached the debdiff to LP: #1777099
<ubottu> Launchpad bug 1777099 in systemd (Ubuntu Bionic) "[backport] DRM devices opened by logind stay referenced indefinitely by PID 1" [High,In progress] https://launchpad.net/bugs/1777099
<tseliot> I'm available to attach the single patches too
<coreycb> sil2100: hi, can you check on the artful-proposed and binary-proposed packages for bug 1772681? it seems they didn't make it to the archive.
<ubottu> bug 1772681 in Ubuntu Cloud Archive "[SRU] python-swauth package dropped but not removed" [Undecided,New] https://launchpad.net/bugs/1772681
<coreycb> sil2100: it may have something to do with the addition of a transitional package, python-swauth
<sil2100> Oh
<sil2100> coreycb: looking o;
<sil2100> coreycb: indeed it was! Now accepted
<coreycb> sil2100: thanks!
<dosaboy> sil2100: will that takes some time to appear?
<dosaboy> sil2100: guessing it still needs to build so will wait
<dosaboy> sil2100: note that its artful and bionic
<sil2100> dosaboy: it should be fairly quick, since this basically just needs a publisher run to get the binaries published now
<sil2100> As those were already built but not accepted
<sil2100> (stuck in NEW)
<dosaboy> sil2100: ack
<dosaboy> they're not there yet fwiw but i'll check back in a few
<rbasak> doko: do you know if clamav needs any action in Ubuntu? It's marked "Do _not_ merge 0.100" in MoM.
<rbasak> Something to do with LLVM I think - but do we know who knows about it or if the current status is documented?
<doko> rbasak: my upload was a no-change rebuild
<rbasak> doko: sorry, I'm not trying to imply it's your responsibity or anything. I'm just trying to gather general status of server-owned packages in terms of planning merges if required.
<rbasak> I thought you might know because of the llvm side
<dosaboy> sil2100: i still dont see the packages fyi
<doko> rbasak: well, I know that it needs porting for every new llvm version
<dosaboy> sil2100: https://paste.ubuntu.com/p/87hvSsM53x/
<sil2100> dosaboy: it takes a while, depends on how much work the publisher has
<sil2100> dosaboy: rmadison says now that the new package should be there
<dosaboy> sil2100: ack thanks
<dosaboy> sil2100: ill check
<dosaboy> sil2100: all good, thanks for helping
<ddstreet> sil2100 can you take a quick look at my follow on debdiff for ebtables lp #1774120 https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120/+attachment/5151443/+files/lp1774120-cosmic-v2.debdiff
<ubottu> Launchpad bug 1774120 in ebtables (Ubuntu Bionic) "ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to 2.0.10.4-3.5ubuntu2.18.04.1 on WSL" [Low,In progress]
<ddstreet> if that addresses the concern you had for the bug, i'll get it uploaded to cosmic, and then upload for srus
<ddstreet> but i want to make sure it LGTY before uploading to cosmic again
<rbasak> mdeslaur: looks to me that nghttp2 can be synced in Cosmic now. Please could you glance at it to see if you agree and I'll sync it?
<mdeslaur> rbasak: sure, sync ahead
<sil2100> smoser: hey! I'm looking at the netinfo_to_netplan changes in initramfs-tools for bionic SRU right now
<sil2100> smoser: to get this approved for bionic I would need at least a test plan and possibly regression potential
<sil2100> smoser: the bug is a 'tracking bug' for all the resolveconf removal, but maybe you could at least get a comment with the steps needed to validate initramfs-tools upload?
<sil2100> smoser: since otherwise if I accept it into bionic-proposed, what would be the criteria that one would judge the upload to be good to go?
<sil2100> smoser: I see netinfo_to_resolv_conf is still there so I assume regressions aren't a big problem, but I guess it could regress at some point?
<sil2100> smoser: the bug is https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1713803
<ubottu> Launchpad bug 1713803 in open-iscsi (Ubuntu) "replacement of resolvconf with systemd needs integration" [High,Triaged]
<sil2100> cyphermox, slangasek: ^
<rbasak> mdeslaur: done, thanks
<smoser> sil2100: cyphermox did the  integration on that, and the test of what was uploaded to cosmic. i'd prefer that he come up with the test plan. but i'm happy to review that.
<smoser> it could definitely regress someone's behavior.
<tomreyn> i've got gnupg2 (gpg2) on xenial segfaulting. there doesn't seem to be a -dbg package as there is for gpg v1. how can i create a backtrace?
<sarnold> tomreyn: looks like there's a -dbgsym package on ddebs.ubuntu.com -- at least I spot Package: gnupg2-dbgsym in http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/Packages
<tomreyn> sarnold: is ddebs.ubuntu.com a 'new' thing then? how do you install those packages, and how do they relate to the -dbg packages?
<ahasenack> tomreyn: https://wiki.ubuntu.com/Debug%20Symbol%20Packages
<sarnold> tomreyn: some instructions on using it at https://wiki.ubuntu.com/Debug%20Symbol%20Packages
<sarnold> but .. I'm not loving the apt-key adv bit of the instructions :(
<ahasenack> I don't know why some debug packages are in ddeb, and others are in the normal archive
<sarnold> as I understand it the dbgsym packages in ddebs are generated automatically as part of the build; the -dbg packages in the archive are generated because the package maintainer set it up to be generated
<tomreyn> and the average user is going to know and understand this how?
<tomreyn> maybe it was in some release notes and i missed it.
<tomreyn> but i guess not. :-/
<ahasenack> tomreyn: the average user definitely would not try to get backtraces
<tsimonq2> sarnold: IANAE on this but iirc -dbg packages are discouraged for most packages in favor of -dbgsym.
<ahasenack> he/she would let apport report the crash and that's it
<tomreyn> ok, lets say the somewhat advanced user who is not a canonical employee.
<tsimonq2> *cough*
<ahasenack> I found that wiki by googling, fwiw
<tsimonq2> tomreyn: s/a canonical employee/an Ubuntu developer or a Canonical employee/ ;P
<tsimonq2> Anyway, I'm being picky.
<tomreyn> thanks for fixing this for me.
<tomreyn> you're right.
<tomreyn> sure, i can always google. but ideally my preferred linux diustro would tell me about relevant changes on its own.
<cjwatson> In this case the problem with that is that it's been a gradual change across thousands of packages not all at the same time
<cjwatson> So difficult to put in a single set of release notes
<tomreyn> this may seem picky, but it's my feeling that this is happening more and more lately. probably a result of lack of personnel. just sad.
<cjwatson> ddebs.ubuntu.com has been around since something like 2006 FWIW
<sarnold> heh, it's apparently not particularly new :) here's instructions for feisty, gutsy, and hardy :) https://wiki.ubuntu.com/DebuggingProgramCrash?action=diff&rev1=57&rev2=58
<tomreyn> ok, ok
<tomreyn> this is not -discuss so i won't push this further. thank you for helping me out.
<slangasek> xnox: is /usr/games empty in the archive? that's surely a precondition for dropping it
<sarnold> I have to admit that hearing about Clear Linux's fuse filesystem to automatically grab dbg symbols when needed made me envious..
<pjotr> Hi, there's currently a serious bug in Firejail 0.9.38 (xenial) and 0.9.52 (bionic):
<pjotr> https://bugs.launchpad.net/ubuntu/+source/firejail/+bug/1776175
<ubottu> Launchpad bug 1776175 in firejail (Ubuntu) "No Internet connection when starting 'firejail firefox' since firefox 60" [Undecided,Confirmed]
<pjotr> I have attached the fixed profiles to the bug report
<pjotr> Can somebody please fix this?
<pjotr> cjwatson: maybe you know who can commit the fix?
<ddstreet> tomreyn ahasenack fyi you can get ddebs also by 'sudo apt-add-repository ppa:ddstreet/ubuntu-dev-tools ; sudo apt update ; sudo apt install ubuntu-dev-tools' to get my ubuntu-dev-tools fork, then just use 'pull-lp-ddebs' for any pkg you like (at any version you might have installed).  no need to add ddebs as apt repo or install the key (and it will get ddebs from old versions that aren't on ddebs.ubuntu.com anymore)
<sarnold> pjotr: probably best to prepare a debdiff with the changes that you need, and get it sponsored; see https://wiki.ubuntu.com/StableReleaseUpdates for some guidelines
<tomreyn> thanks for the suggestion, ddstreet (i'll stick to the 'original', though)
<tsimonq2> It was going to get merged in at one point (/me kicks mapreri :P)
<ddstreet> tomreyn yep using ddebs.u.c is rather easy and works as long as you have the latest pkg version installed
<ddstreet> yeah he finally did offer to merge it all, after i gave up and moved my ongoing work into a forked ppa...i'll get around to preparing it for merging back eventually
<tomreyn> yes, seems easy enough to use it.
<infinity> stgraber: You're the chair for today's TB meeting.
<infinity> (If we're having one)
<infinity> mdeslaur: TB?
<mdeslaur> whoops
<tomreyn> this surely stands for table boredom.
<Unit193> sarnold: 'not loving apt-key adv', I did not read the wikipage but from context I'm thinking that's getting the key for the ddeb archive?  Just install ubuntu-dbgsym-keyring, it was added with bionic finally! \o/
<cjwatson> oh is it now
<cjwatson> Unit193,sarnold: added to the wiki, thanks
<Unit193> cjwatson: Oh, thank you!
<cjwatson> thank *you*
<nacc> heh
<Unit193> Just closed LP 643623 too.
<ubottu> Launchpad bug 643623 in ubuntu-keyring (Ubuntu) "Should ubuntu-keyring include the debug archive key?" [Undecided,Fix released] https://launchpad.net/bugs/643623
<xnox> sarnold, yes, that is nice.
<xnox> sarnold, i think we should be able to generate similar metadata, and install packages ondemand, by have everything autodiscoverable.
<xnox> Unit193, cjwatson, sarnold - yeah, sorry about non-updating all the bugs / documentation that it's now generally available keyring snippet.
<xnox> slangasek, there are two packages, i'm happy to fork them. to ship the binaries in /usr/bin instead
<xnox> slangasek, cause if we are going to touch /etc/environment it's best to update it once to sensible path, without games.
<sarnold> Unit193,xnox,cjwatson, beautiful, I hadn't seen ubuntu-dbgsym-keyring yet! :) much better!
<slangasek> xnox: are you going to SRU those packages, back to all releases in which /etc/environment's path declaration is broken wrt snapd?
<xnox> slangasek, deal.
<slangasek> xnox: hmm ;)  from my POV I would prefer not to entangle the two issues, and I think properly version-guarded upgrade handling is fine to deploy for each /etc/environment change separately
<Unit193> Where did the number of '2' packages that use /usr/games/ come from?  `apt-file` is telling me a much higher number.
<bluesabre> slangasek: do you know who to reach out to for review of https://code.launchpad.net/~xubuntu-dev/debian-cd/xubuntu-base/+merge/347414, https://code.launchpad.net/~xubuntu-dev/livecd-rootfs/xubuntu-base/+merge/347319, and https://code.launchpad.net/~xubuntu-dev/ubuntu-cdimage/xubuntu-base/+merge/347320 ?
<bluesabre> (sorry for the random ping :))
#ubuntu-devel 2018-06-20
<slangasek> bluesabre: I'd suggest talking to infinity, as I believe he had the context of previous iterations here
<derick_> I am trying to bring some packages from ubuntu to debian.
<derick_> downloaded the source. renamed it _ in place of - and origÂ before format. checked if all necessary files and folder are present in /debian. then a mk-build-deps -i debian/control. finally dpkg-buildpackage
<derick_> Am I missing any steps? as deb file is created and able to install too. but I dont see anything about the application. So I think something is wrong.
 * Faux points at the topic, about how this is off-topic.
<derick_> faux : Okay. Can you point me to right irc channel to ask this question?
<Faux> There's some packaging channels for debian on otfc, but I don't know, no.
<derick_> Thank you.
<Unit193> #debian-mentors I'd think, if the goal is to get it into Debian proper.
<cpaelzer> hmm, I just now realized that the autopkgtest of chrony doe reach out to github
<cpaelzer> I realized by that failing since end of may (but formerly working)
<cpaelzer> is that a temporary thing or did we shut down more outbound connections intentionally
<cpaelzer> I know it is not recommended to reach out, but as I said I wasn't even aware until now
<cpaelzer> so I need understand priorities and that requires to see what changed in the test-infra
<Laney> cpaelzer: There was a bug in cloud-init or something where the proxy environment wasn't being set up properly; try retrying one arch and see if it works now
 * cpaelzer just got some hope to not have to SRU this evywhere just for the test :-)
<cpaelzer> thanks Laney will try
<Laney> ubuntu@juju-prod-ues-proposed-migration-machine-11:~$ ssh -o StrictHostKeyChecking=no ubuntu@10.44.40.9 cat /etc/environment
<Laney> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
<Laney> http_proxy=http://squid.internal:3128
<Laney> https_proxy=http://squid.internal:3128
<Laney> no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,changelogs.ubuntu.com,ddebs.ubuntu.com,ppa.launchpad.netbash: warning: setlocale: LC_ALL: cannot change locale (en_GB.UTF-8)
<Laney> that looks Ok at least
<cpaelzer> seems to work now, at least the log snippet I see in autopkgtest/running seems to be after the fail I had
<Laney> :>
<cpaelzer> will check them and if working retrigger all of them to avoid several package maintainers needin to realize whats going on in their proposed-migration
<cpaelzer> "Cloning into 'clknetsim'..." LGTM now
<Laney> great
<cpaelzer> thanks for the hint Laney
 * cpaelzer is shy to just hit retry buttons all over the place without any idea why it should be better
<Laney> That's good, usually if retrying works it means the test is flaky in some way and should be improved anyway
<Laney> (in this case it was a bug in the base image though)
<cpaelzer> yep
<cpaelzer> can I do in d/control something like
<cpaelzer> Architecture: linux-any, !ppc64el, !s390x
<xnox> cpaelzer, nope
<xnox> cpaelzer, it's a space separated field i believe, additive only.
<xnox> https://www.debian.org/doc/debian-policy/#s-arch-spec
<xnox> bah no
<xnox> this
<xnox> <xnox> https://www.debian.org/doc/debian-policy/#s-arch-spec
<xnox> https://www.debian.org/doc/debian-policy/#architecture
<rbasak> smoser, cyphermox: looking at initramfs-tools in the SRU queue. I can guess at why you're SRUing it, but I see no mention of what you're actually fixing in the linked bug? The bug looks like everything is already resolved.
<rbasak> I think you either need to extend the bug to also cover the case you're fixing here, or use a different bug.
<cpaelzer> xnox: thanks, so to achive the above I have to extrapolate all potential values that Debian concerns about
<cpaelzer> and then drop ppc and s390x
<xnox> cpaelzer, yeah this describes what you can do https://www.debian.org/doc/debian-policy/#architecture
<rbasak> Oh, wait.
<rbasak> You're additionally doing this for Xenial and Artful?
<xnox> cpaelzer, sadly yes. we had to do that for like open mpi
 * rbasak is quite confused
<cpaelzer> xnox: I guess I don't need to list more than thos elisted in https://www.debian.org/releases/stable/i386/ch02s01.html.en
<cpaelzer> because dpkg-architecture -L is an uncfortably long list
<cpaelzer> om
<cpaelzer> :-)
<cpaelzer> it is so uncomfortable that is misses chars
<xnox> cpaelzer, debian arches + ubuntu arches + debian ports (optional) - broken
<xnox> cpaelzer, so clicking buildd logs on tracker.debian.org is a good list https://buildd.debian.org/status/package.php?p=systemd
<xnox> cpaelzer, so skip hurd & kfreebsd; but keep all others, unless you know it to be broken. so something like 16 arches to list, no?
<xnox> amd64 arm64 armel armhf i386 mips mips64el mipsel alpha hppa ia64 m68k riscv64 sh4 sparc64 x32
<ddstreet> sil2100 hi, for lp #1774120 I asked slashd to review and sponsor my cosmic debdiff, as I think it addresses your concerns; please let me/him know soon if it doesn't.  I'll upload to SRUs once it's in cosmic.
<ubottu> Launchpad bug 1774120 in ebtables (Ubuntu Bionic) "ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to 2.0.10.4-3.5ubuntu2.18.04.1 on WSL" [Low,In progress] https://launchpad.net/bugs/1774120
<cpaelzer> xnox: yeah going through the debian buildds is good for my case
<cpaelzer> thanks for that hint
<cpaelzer> I can sort arch by arch which one has actually built the .so I look for
<xnox> ddstreet, sil2100 - i'd rather not upload that ebtables SRU, and even possibly revert the fix in ebtables. The bug is not with ebtables, or its init.d script, but that init.d script was called at all in environment without PID 1.
<xnox> commented on the bug as such.
<xnox> rbalint, ^^^^
<xnox> rbasak, slangasek - should we change /lib/lsb/init-functions.d/40-systemd to have _use_systemctl=1, always?!
<mapreri> tsimonq2, yes, I offered up to blindly merge it if ddstreet prepares something I can just git merge cleanly.
<mapreri> because it became clear I am not going to review it, nor anybody else willâ¦
<xnox> rbasak, slangasek - i guess the downside there is, that currently some daemons are possible to be started via init.d scripts on WSL; and with that change in place, it will be hard to do so.
<ddstreet> xnox i think that's a different bug actually, you're talking about the debhelper bug right?
<xnox> ddstreet, no.
<xnox> ddstreet, executing "service foo stop" calls /etc/init.d/foo stop, which sources /lib/lsb/init-functions, which sources /lib/lsb/init-functions/40-systemd, and by default redirects the call to systemctl stop foo. Such that init.d scripts are executed and managed as systemd units.
<xnox> ddstreet, the redirection does not happen on WSL; but does on more normal Ubuntus.
<xnox> (lxd, lxc, kvm, baremetal, etc)
<ddstreet> ok, but that isn't what's causing the stop to fail
<ddstreet> but sure, if you have a better way to fix it, please do
<xnox> ddstreet, well, at that point when 40-systemd is sourced, it would realise that there is no systemd, and the script would bail / exit 0.
<xnox> ddstreet, meaning that stop) portions of init.d script are never executed, init.d script is innert, and thus does not fail.
<xnox> (ditto for start)
<xnox> ddstreet, the bits that fail, should not have been attempted to be executed in the first place - on wsl. Just like they are not executed in chroots.
<ddstreet> are you adding that as part of the debhelper/systemd bug?  should i make the ebtables bug a dup of that?
<sil2100> ddstreet: hey! Sorry I missed your ping yesterday, I have a very fragmented week this week
<xnox> ddstreet, i've only added this to the ebtables bug.
<xnox> ddstreet, i have no idea what debhelper/systemd bug you are reffering to.
<xnox> ddstreet, url?
 * xnox is only talking about ebtables
<sil2100> ddstreet: I was supposed to look at your patch and actually answer you but then it somehow just eh, slipped
<ddstreet> https://bugs.launchpad.net/bugs/1748147 i assumed you were referring to <
<ubottu> Launchpad bug 1748147 in debhelper (Ubuntu Bionic) "[SRU] debhelper support override from /etc/tmpfiles.d for systemd" [Medium,In progress]
<ddstreet> xnox if WSL needs a more general 'never run init scripts' fix in 40-systemd, i'll let rbalint take that over, since he has WSL access and I don't
<xnox> ddstreet, nope, that is also all wrong, differently.
<xnox> ddstreet, that would be fix in 40-systemd on ubuntu.
<xnox> in systemd package
<xnox> i think
<xnox> and not related at all.
<ddstreet> xnox as you seem to have the plan to fix this ebtables (or not ebtables) bug on WSL, can you (or rbalint) take it over?
<ddstreet> or, we can push the ebtables change in, and fix it how you're suggesting later
<xnox> i have an opinion what should be done in general. I don't know if it is sensible or not. hence the ping to rbalint etc.
<Bluefoxicy> what if... for each package... Ubuntu released a jigdo file
<Bluefoxicy> and you take the base packageâthe original release for the distro versionâand ran a bsdiff against the base package and each revision
<xnox> Bluefoxicy, that would be worse than existing ddebs implementation, which was proven to be too slow to be useful.
<Bluefoxicy> xnox:  ah
<xnox> Bluefoxicy, and there is a better ddebs implementation in the works by apt upstream; maybe talk with juliank
<Bluefoxicy> xnox:  binary patching is slow?
<juliank> Bluefoxicy: binary patching is fast
<juliank> binary diffing is slow
<Bluefoxicy> oh yeah, no kidding.
<juliank> well, the existing binary patching is slow
<Bluefoxicy> juliank:  I was considering that you can roll back to $ORIG, then patch forward to $NEW
<juliank> Bluefoxicy: here's the spec https://wiki.debian.org/Teams/Dpkg/Spec/DeltaDebs
<xnox> Bluefoxicy, current ddebs implementation, tries to reconstruct new .deb then install it, which is slow end-to-end. new one i believe replaces changed files, or something rather, which is actually usable.
<juliank> names are not final
<Bluefoxicy> juliank: and also that you can assemble the uncompressed archive from its shell and installed files
<Bluefoxicy> so you can skip downloading much of the original package file by validating the SHA256 of installed files, patch them down to original version, grab the remaining files individually from online
<juliank> I'm not sure what you're saying
<juliank> Let's be clear
<Bluefoxicy> juliank:  are you delta patching in every direction or only from one version?
<Bluefoxicy> ah you are
<juliank> delta patches are supposed to be release->updates, updates->updates, security->security and so on
<Bluefoxicy> juliank:  nod.  So you have to generate a patch from every update to every other update, or chain them and patch several times
<juliank> Bluefoxicy: So essentially, you are saying I should generate two deltas instead: update->base, and then base->new update
<juliank> this would mean that every delta exists in two directions
<Bluefoxicy> well, the way you have it is viableâdelta patches are small, after all
<Bluefoxicy> hmm.  Delta patches don't apply in reverse?
<juliank> no, of course not
<Bluefoxicy> heh.  diffs reverse, binary deltas don't.
<Bluefoxicy> ok
<Bluefoxicy> juliank:  Mostly, I'm suggesting you can actually generate the full, signed deb for any version by reassembling patched installed files, downloaded individual pristine archive contents, and the hollowed out shell of a signed archive
<juliank> you can't
<Bluefoxicy> Why not?
<juliank> well, not reliably
<juliank> also you don't want to
<juliank> Reliably because compression algorithms change
<Bluefoxicy> ah
<Bluefoxicy> I thought the archives were signed before compression, then compressed
<juliank> And because they are compressed, even if the algo is the same, you have to recompress them, which is slow, and is what kills debdelta
<Bluefoxicy> yeah you use xz over there and it's slower than hell
<juliank> Bluefoxicy: They are not signed at all. We hash the entire .deb and essentially (transitively) sign a hash of that
<Bluefoxicy> ah
<Bluefoxicy> I thought the deb was an archive with two files and a hash on top, all compressed arbitrarily
<juliank> BTW, signing (only) uncompressed content is a bad security model, as it allows exploiting decompressor bugs
<Bluefoxicy> nod
<juliank> Bluefoxicy: Anyhow, with my delta approach, the delta deb simply contains a tarball of deltas for all installed files
<juliank> rather than a delta of the tarballs
<juliank> or something
<juliank> you can regenerate the original tarball from it
<juliank> you can likely regenerate the original deb (unless compressor changed in the meantime)
<Bluefoxicy> "If files match dpkg db hashes; pick the delta, otherwise full deb"
<juliank> yes
<Bluefoxicy> heh
<juliank> So essentially, dpkg records hashes for all files
<Bluefoxicy> trying to store all the individual files unpacked up on the mirror would be murderous.
<juliank> we calculate the id = hash((path, hash) of all files of a package)
<juliank> (excluding conffiles)
<juliank> so essentially sha256sum(/var/lib/dpkg/info/apt.md5sums)
<juliank> then recalculate the hashes in there, sha256sum the new list
<juliank> and check that they match
<Bluefoxicy> I guess you could store the individual files for the base version and then chain patch an individual miss instead of getting the whole package
<Bluefoxicy> but that might also be excessive
<Faux> A couple of people (including me) have looked at offering a mirror based on something like casync, so you get package dedup and strong hashing.
<juliank> Faux: it does not work
<Faux> Not in the mood for discussing it right now.
<juliank> Faux: And I forgot what my argument was, as I investigatd casync for something months ago
<Bluefoxicy> why does everyone always say stuff Lennart Poettering designed does not work?
<juliank> Bluefoxicy: Oh, I meant the whole block-wise thingy does not work for binaries
<Bluefoxicy> I know I know :P
<Bluefoxicy> in any case, this looks good
<juliank> Bluefoxicy: One thing I want to do is find windows in binary files and run the bsdiff algorithm on those windows
<Bluefoxicy> juliank:  do you have a method to transplant kernel binaries and headers with this?
<juliank> that would be nicer.
<Faux> casync has windowing, not blocks.
<juliank> Faux: I vaguely recall adding multiple versions of uncompressed packages or something and it failing to achieve useful results.
<juliank> Note this was last year
<juliank> Bluefoxicy: What do you mean?
<Faux> There are issues, like openjdk being a source package full of gzip files, but generally I found it worked very well without too much prodding.
<juliank> Bluefoxicy: Patch /boot/vmlinuz-4.15.0-20-generic using /boot/vmlinuz-4.15.0-19-generic and firends?
<Bluefoxicy> juliank: Kernel images don't patch in place; they install a whole new kernel
<Bluefoxicy> yeah
<juliank> Right
<juliank> I'm not entirely sure yet
<juliank> We could have simple regular expressions to sanitize paths
<Bluefoxicy> plus kernel modules and headers are huge
<juliank> or we could try to find the closest match
<juliank> but I think path sanitization works best
<juliank> I want to generate deltas without having to unpack the debs I'm deltaing
<juliank> which relies on the fact that the list of packages is ordered
<Bluefoxicy> eh, I'd think you could say "X file in $PACKAGE is the basis for Y file in this package"
<juliank> s/packages/files/
<juliank> Bluefoxicy: well, yes, you'd say, given new filename, s/vmlinuz-.*/vmlinuz/
<Bluefoxicy> hm
<juliank> so it would basically treat /boot/vmlinuz-4.15.0-20-generic as /boot/vmlinuz and /boot/vmlinuz-4.15.0-19-generic too
<juliank> you don't want to have to encode this for each new pair of packages
<Bluefoxicy> nod
<Bluefoxicy> probably more useful for /lib/modules than /boot
<Bluefoxicy> since vmlinuz is compressed
<Bluefoxicy> thus is subject to chaotic entropy
<juliank> Also likely, s/(lib.*.so).*/\1/
<juliank> so you can patch libfoo2 using libfoo1
<juliank> Bluefoxicy: Yes, vmlinuz delta is bigger than vmlinuz
<Bluefoxicy> what about headers?  They're not binary, and diff might work better than bsdiff
<juliank> I think bsdiff works optimally for everything
<juliank> diffs are far bigger
<Bluefoxicy> fair enough
<juliank> bsdiff is built for diffing binary files, and that's strictly more complex than diffing text files
<juliank> so it performs well on those too
<juliank> we also need to do the same for package names, so linux-$foo-$ver1-generic diffs against linux-$foo-$ver2-generic
<juliank> and so on
<juliank> But I guess we can just do delta by source package
<Bluefoxicy> hmm
<juliank> and then for each binary package, find the binary in the old package with the shortest distance in name
<Bluefoxicy> all I know is I've been waiting forever to not have to download 600MB of crap for a one-line LibreOffice exploit fix
<juliank> essentially find the old package subject to min Levenshtein distance(old name, new name)
<juliank> should be fine I guessd
<juliank> otherwise, encode again
<juliank> using regex
<xnox> Bluefoxicy, .deb may have arbitrary number of archives, thus we have to hash/sign the whole .deb, not it's archives. as then one may be able to append extra archives to it, bypassing security.
<juliank> I think when generating deltas we could also just extract file lists from control.tar, and then build pairs using shortest distance
<juliank> this would handle the whole versioning case of kernels, libraries and stuff
<Bluefoxicy> juliank:  is there a way to know with certainty the impact of installing packages?
<Bluefoxicy> or is it something you can't evaluate without completing the install?
<juliank> what do you mean?
<Bluefoxicy> let's say I tried to background upgrade LibreOffice by mounting a FUSE filesystem over / such that if I tried to perform an operation on a file altered by the 30 or 40 packages queued in the update process, it would delay that access and move the package affecting that file to the front
<Bluefoxicy> would I be able to solve for whether or not a particular file is affected by the update process, or is that strictly unknown until all installations are complete?
<juliank> that sounds scary
<ali1234> quick question about the dpkg locking email: does this mean i can run apt on the command line while eg synaptic is running (but not doing anything)?
<ali1234> and what does it mean for eg bootstrapping a chroot where i run "dpkg --configure -a" non-interactively from a script on the chroot?
<Bluefoxicy> yeah, old stuff I thought up in 2006
<juliank> the assumption is that none of the files currently installed might change while the upgrade is running
<juliank> as usual, excluding conffiles
<juliank> ali1234: no you can't, that's the point
<juliank> ali1234: and there is no change with dpkg --configure -a
<ali1234> i already can't though so what changed?
<juliank> ali1234: you could
<juliank> ali1234: So the problem is that before we run dpkg, we need to drop its lock so dpkg can acquire it, leaving a short time window where you could in fact run apt
<ali1234> if i try to run apt while synaptic is running it will fail because it can't aquire the lock - it has done that for years and years
<ali1234> ah, i see
<ali1234> so this just closes that race condition?
<Bluefoxicy> juliank:  I've thought of a lot of scary things, mostly around hiding update processes and protecting the base filesystem
<juliank> ali1234: yes
<juliank> Solving the race condition is all it does
<ali1234> got it, thanks
<juliank> And dpkg --configure -a does not change, but I see that this is misleading
<juliank> I mean to say that if you run dpkg manually _in your apt frontend_ while you hold the lock as you should, then you need to tell dpkg that the lock is held already
<juliank> if you just run dpkg on your own, and not as part of any frontend that holds the lock, you of course don't have to set the variable
 * Bluefoxicy heads off to do other things
<cpaelzer> Laney: I was just checking back on the tests that failed before, in the meantime all arches passed ont he two fails they had in proposed
<rbalint> ddstreet, i'm ok with the latest proposed patch of yours and disagree with xnox regarding masking a lot of funcionality from the app which i'll detail in a moment in LP: #1774120
<ubottu> Launchpad bug 1774120 in ebtables (Ubuntu Bionic) "ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to 2.0.10.4-3.5ubuntu2.18.04.1 on WSL" [Low,In progress] https://launchpad.net/bugs/1774120
<ddstreet> rbalint ok thnx, i will get that uploaded to cosmic and then sru the change
<rbalint> ddstreet, thank you i guess sil2100 was just busy, this is why he did not comment
<sil2100> This week I am a bit unreliable so to say
<xnox> doko, https://lists.ubuntu.com/archives/ubuntu-release/2018-June/004512.html see request to the release team to document hints-merge-proposals
<rbasak> xnox: you know that https://wiki.ubuntu.com/ProposedMigration is a wiki, right? That anyone, including xnox, can edit? :)
<xnox> rbasak, proposedmigration is owned by release team; and my request is specifically because there is lack of documentation; and i do not have the knowledge as to what is supported in hints.
<xnox> rbasak, did you read all of my email? is it not clear, that it's unknown what is supported.
<doko> rbasak: disagreed. that should be done by the release team, or we make the hints owned by the core-devs and then we can document and patch it
<rbasak> doko: documentation can be written by anyone. While it'd be nice if the release team does it, I don't think it's appropriate to demand that they do when someone else easily can. We certainly need the release team to make any necessary decisions, but I don't think there are any decisions that need making here.
<doko> rbasak: no, because I don't know what to document
<rbasak> I do (roughly, and I can read the source to make sure), and I'm not on the release team.
<doko> if you're volunteering, nice!
<rbasak> I can't volunteer for everything, sorry.
<rbasak> My point is that I don't think it's appropriate to demand work from any particular Ubuntu team.
<rbasak> Especially when the work isn't exclusive to that team (anyone can do it)
<doko> so ubuntu-release enforces things on migration, but doesn't say what needs to be done for migration?
<rbasak> They do say what needs to be done. If you ask they'll tell you. You're demanding (unreasonable) that it be documented in a particular (perfectly reasonable) way.
<rbasak> When you could just do the documenting yourself!
<xnox> rbasak, currently the branch is owned by them; and only they know what works in that branch; and neither me nor doko nor you know the brintney hints syntax as supported by britney as deployed by the release team.
<doko> I told you, I don't know how things should be done
<xnox> rbasak, or do you?
<xnox> rbasak, are you on the release team?
<rbasak> 15:48 <rbasak> I do (roughly, and I can read the source to make sure), and I'm not on the release team.
<xnox> rbasak, cute. i think release team can speak for themselves, and reply to my email, and don't need you =)
<rbasak> I know the britney hints syntax because I read the code when I wanted to find out how it was done and how to submit something.
<xnox> rbasak, i don't think that needs to be done by everybody; and release team don't actually accept all the hints that are possible, and have specific requirements emposed by them as to the type of things they accept.
<rbasak> Honestly I'm quite astonished that you either don't seem to consider yourself capable of that or think it needs to be somebody else's job to sort it out.
<rbasak> i don't think that needs to be done by everybody> agreed - so learn it and document it
<xnox> rbasak, i've submitted a few hint merge requests; and frequently the syntax of my hints was valid; but ineffective as it didn't match anything.
<rbasak> xnox: so ask for help and document the result.
<xnox> rbasak, they are not-trivial to wildcard. and take a while to see that they ddidn't work.
<xnox> rbasak, that's what i'm doing lol
<rbasak> No, I don't think you are.
<rbasak> You're asking that someone else use their crystal ball to learn your edge cases and document those.
<rbasak> If someone tries and is successful then great.
<rbasak> But I honestly think it'd be far more productive for someone like you to start some skeleton documentation and fill it out with the edge cases you know about to start, or at least ask for clarification on specific edge cases you're unsure about.
<juliank> Dear Kubuntu, Mate, and Gnome flavour folks: Please also fix bug https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1750465 in stable releases.
<ubottu> Launchpad bug 1750465 in ubuntu-mate-artwork (Ubuntu Xenial) "upgrade attempting to process triggers out of order (package plymouth-theme-ubuntu-text 0.9.2-3ubuntu17 failed to install/upgrade: dependency problems - leaving triggers unprocessed)" [High,Confirmed]
 * juliank just raising awareness
<tseliot> xnox: hi, how is the next systemd release in bionic going to be versioned?
<xnox> tseliot, with your debdiff stuff included it should be 237-3ubuntu10.2
<tseliot> xnox: ok, as I was thinking of including my patches in a temporary PPA. I'll version the package something like 237-3ubuntu10.2~ppa1, so that it doesn't clash with yours
<cjwatson> If anyone fancies a bit of initramfs-tools work, https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1667512 came up on ubuntu-users recently and I'm pretty sure there's an easy fix for it, though I don't have time to prepare it myself.  See my comment #14
<ubottu> Launchpad bug 1667512 in initramfs-tools (Ubuntu) "update-initramfs hangs on upgrade, dpkg unusable, unbootable system" [Undecided,Confirmed]
<slangasek> cjwatson: hi, do you have time to talk about grub-pc + grub-efi-amd64? https://code.launchpad.net/~sil2100/ubiquity/+git/ubiquity/+merge/348201
<cjwatson> slangasek: Not quite right now, I need to go out soon.  Tomorrow?
<slangasek> cjwatson:
<slangasek> cjwatson: ok.  I'll braindump a little here anyway
<slangasek> cjwatson: what I've tried to design here is that the user always gets shim-signed + grub-efi-amd64-signed + grub-efi-amd64-bin + grub-pc + grub-pc-bin; since the binary bits come from grub-efi-amd64-signed + shim-signed in the secureboot case, it seems unnecessary to also have grub-efi-amd64 present to also run grub-install, rather than have it run when the unsigned binaries are updated; if you
<slangasek> want grub-pc + grub-efi-amd64 to be made coinstallable, that seems possible but unnecessary
<cjwatson> slangasek: I think it's more logically coherent for them to be coinstallable, honestly.  Otherwise you've set up a situation where in the future some user thinks "hm, I don't use BIOS booting, lemme remove grub-pc", and then their system keeps working fine for a while until some time later it doesn't
<slangasek> cjwatson: ok.  I've suggested addressing that piece by having grub-efi-amd64-signed depend on grub-pc | grub-efi-amd64 fwiw
<cjwatson> grub2 maintenance has had quite a few of these kind of timebombs before and I want to design them out
<cjwatson> That's a really weird contortion just to avoid removing the Conflicts
<slangasek> ok
<slangasek> removing the conflicts> they share a conffile currently, the all-important kernel postinst hook
<slangasek> anyway, happy to talk more tomorrow :)
<cjwatson> All right, I can see that that might involve a bit of fiddling.  Still think it's the better path
<cjwatson> That could probably be moved to the existing grub2-common without too much difficulty
<cjwatson> (Obviously with some care to ensure it doesn't do anything if none of the "owns boot" packages is installed)
<cyphermox> +1
<cyphermox> fwiw I suggested moving some of these things (like the /etc/default/grub generation) to grub2-common
<cjwatson> I don't think it's necessary to move that bit
<cyphermox> my concern right now is what happens when you try to have both installed on MBR; I'd expect -efi to just fail
<cjwatson> If both postinsts try to do that work, that isn't significantly different from two successive versions of the same postinst doing it
<cyphermox> cjwatson: it was to fix an issue caused by not removing the conflcits, etc. -- not necessary
<cjwatson> Right
<cjwatson> OK, so you're trying to have the EFI bits installed even if the installer is running on MBR?
<cyphermox> no, we're trying to have the EFI and MBR bits installed when you do an EFI install
<cyphermox> which I guess means it should also happen when the installer is running on MBR
<cjwatson> Well, if that's only a side benefit, then you could just not do that bit
<cjwatson> installer on UEFI -> grub-pc + grub-efi-amd64; installer on BIOS -> grub-pc
<cyphermox> sure sure
<cjwatson> (Also, are you sure grub-pc won't fail on some UEFI systems?)
<cyphermox> of course not ;)
<cyphermox> but I'm also not the instigator of it, nor am I actually doing the implementation
<cjwatson> English is crap, I meant you plural
<cyphermox> heh
<cyphermox> well, I can't think of why grub-pc would fail on x86 UEFI; but that doesn't mean it can't
<dpb1> how yous doin
<cjwatson> Writing to arbitrary bits of the start of the disk is probably unspecified on UEFI.  I certainly don't know that it *will* fail
<cjwatson> dpb1: Yeah, I use that in spoken English but it still feels weird in print
<cyphermox> cjwatson: even on a GPT with nothing special you should be able to write to LBA0
<cjwatson> probably my problem
<cjwatson> cyphermox: Yeah, maybe it's OK, and I guess youse have time to work out the kinks
<cyphermox> yu[
<cjwatson> sibh
<cjwatson> anyhow, I can certainly work on moving the kernel hook over
<sil2100> cjwatson, cyphermox, slangasek: ok, so is the consensus now that it's ok to install both grub-pc and grub-efi-amd64-bin on EFI installations? Or do you actually want to go the mentioned path of making grub-pc and grub-efi-amd64 coinstallable first?
<sil2100> i.e. should I trash the MP I prepared?
<sil2100> Would be nice if we could get a consensus this week, sucks to have cosmic unbootable for EFI for so long
<psusi> sil2100: are you talking about #1668148?
<sil2100> psusi: no, that's a different thing, it'll be worked on here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1766945
<ubottu> Launchpad bug 1766945 in ubiquity (Ubuntu) "(EFI on top of legacy install) choosing "replace" or "resize" options in partitioning may lead to an install failure" [Critical,Confirmed]
<sil2100> psusi: we're talking about LP: #1775743 now
<ubottu> Launchpad bug 1775743 in ubiquity (Ubuntu) "[regression] Cosmic daily images 20180606-11 install but boots only to grub prompt on EFI systems" [Critical,In progress] https://launchpad.net/bugs/1775743
<slangasek> sil2100: it's certainly not /possible/ today to install both grub-pc and grub-efi-amd64.  And I think the changes to ubiquity were only about not removing grub-pc, so it should still be per se correct to drop that code?
<sil2100> slangasek: yeah, was just asking if maybe you want the grub-pc not being purged wait for when they're co-installable - ok, then I'll poke cyphermox to maybe merge my ubiquity change and then release it to cosmic (or I can release it, but I have no powers over the git branch)
<slangasek> sil2100: AFAIK we've done all the other packaging changes such that the ubiquity change can land as-is, and if we want to revisit particular details of the grub packaging, we can do that independently.  At the end of the day, we will be installing grub-pc.
<rbasak> tsimonq2: what's the status of bug 1777205 in cosmic please?
<ubottu> bug 1777205 in python-acme (Ubuntu) "python-acme to start crashing on June 19th" [Undecided,New] https://launchpad.net/bugs/1777205
<tsimonq2> rbasak: Fixed already.
<rbasak> tsimonq2: thanks. I updated the bug.
<tsimonq2> rbasak: (The bug description says it's fixed in 0.25.1, which has been in Cosmic since the 14th, ftr.)
<tsimonq2> rbasak: Thank YOU. :)
<psusi> ok, so I guess do-release-upgrade is being kept from offering 16.04->18.04 until after 18.04.1 to get the bugs out... but how do you test to find the bugs when it won't even offer with do-release-upgrade -p ( check -proposed pocket )?  How about getting it in -proposed?
<Odd_Bloke> psusi: You may want -d.
<psusi> Odd_Bloke: nope... that goes to 18.10
<slangasek> bdmurray: ^^
<bdmurray> psusi: You need to fix your prompt= line in /etc/update-manager/release-upgrades -d should work. http://changelogs.ubuntu.com/meta-release-lts-development
<bdmurray> psusi: You can read more here http://www.murraytwins.com/blog/?p=147
 * Odd_Bloke just ran that in a xenial container and it offered bionic.
<slangasek> bdmurray: right, sorry for highlighting, I confirm as well here that it works as expected
<slangasek> but if Prompt=lts is not set, then do-release-upgrade should have already been offering an upgrade, to an obviously earlier release?
<slangasek> confirmed this as well ;P
<slangasek> everything working as designed
<psusi> bdmurray: ahh, thanks.
<rbalint> doko, xnox, rbasak: https://wiki.ubuntu.com/ProposedMigration now suggests creating merge requests for hints â®  :-)
<rbasak> rbalint: thanks!
#ubuntu-devel 2018-06-21
<seb128> rbasak, Robert got the fix from SRU bug #1722185 merged upstream (mentioning it here since I don't know if you guys get emails for the SRU followups)
<ubottu> bug 1722185 in packagekit (Ubuntu Bionic) "Crash installing packages using debconf" [High,In progress] https://launchpad.net/bugs/1722185
<xnox> tseliot, i have questions about your backport for bug #1777099
<ubottu> bug 1777099 in systemd (Ubuntu Bionic) "[backport] DRM devices opened by logind stay referenced indefinitely by PID 1" [High,In progress] https://launchpad.net/bugs/1777099
<xnox> tseliot, can you talk now?
<tseliot> xnox: sure
<xnox> tseliot, first hunk appears to be this commit https://github.com/systemd/systemd/commit/51ead3e3774aa9306d637723d92bbddf2258d2cb
<xnox> tseliot, then this commit does not appear to have been cherrypicked https://github.com/systemd/systemd/commit/8b983cc74a85bda4d662fd822b433327fc568d40 but rather got squished into
<xnox> https://github.com/systemd/systemd/commit/1bef256cf5838d4bbc55654206aa6254d7fddb59
<xnox> but these are the things that need to be backported right?
<tseliot> xnox: I think the first patch failed to apply, but I probably should've cherrypicked the 2nd commit instead
<xnox> ack, no worries, just trying to collect history. Plus upstream changed ids upon merging (they do that a lot)
<xnox> tseliot, but as far as I can tell nothing needs to be done for cosmic, as proposed has v238 with all of these things in already.
<xnox> (it hasn't migrated to release pocket, but that's a different story)
<tseliot> xnox: yes, 238 has those commits
<tseliot> xnox: but yes, those are the commits we need
<xnox> tseliot, cool. thanks. I'm preparing the bionic upload now.
<xnox> probably will be accepted into proposed on monday the earliest, due to the other critical upgrade bug.
<tseliot> xnox: thats' great, thanks, so that I can finally fix this LP: #1778011
<ubottu> Launchpad bug 1778011 in ubuntu-drivers-common (Ubuntu Bionic) "PRIME Power Saving mode draws too much power" [High,In progress] https://launchpad.net/bugs/1778011
<xnox> ouch
<tseliot> exactly
<xnox> tseliot, hm.... there are more code changes before & after (with a few more additions and reverts) and i think i may want to backport the whole lot of commits.
<xnox> which should fix a few more issues around opening/closing/passing those device fds around
<xnox> and should make the code in bionic, match more closely that is now shipped in v238 and later
<xnox> i'll prepare the stack of commits that i want to cherrypick, will attach on the bug for you to re-review. It's all of those, plus more.
<tseliot> xnox: ok, whatever works best for you. Just keep in mind that I'll be off next week until Wednesday, and I'll be back on Thursday
<xnox> tseliot, ah, i see. ok.
<seb128> is there a known issue with ppc64el/cosmic? I see a bunch of things blocked on ppc64e lines on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<Laney> seb128: you just see one architecture there even if there's a problem on multiple
<Laney> the first entry is probably https://launchpad.net/ubuntu/+source/plastimatch/1.7.0+dfsg.1-1build1 for example
<Laney> Not sure why it's chosen ppc64el given the "Arch order" list at the top, mind you
<seb128> Laney, it was always like that? I though it used to have lines for every arch
<seb128> Laney, thx
<Laney> You see all arches when it tries hints (at the end of the file)
<seb128> Laney, I'm looking at network-manager and there is no section where it has more than ppc64el
<seb128> let me see in a pbuilder on amd64 though
<seb128> to see if I get an issue there
<Laney> yes, that wasn't tried by the hinter
<Laney> the output just refreshed and now it says amd64 again
<Laney> go figure
<seb128> ah, yeah
<seb128> Laney, thx
<Laney> seb128: I think your problem is probably that nm-applet isn't considered
<Laney> Jeremy dropped that pkg in his latest upload
<Laney> gir1.2-nmgtk-1.0
<seb128> Laney, I never remember, can I hint britney to try them together? or is that something I need to ping you to do for me? ;)
<Laney> seb128: a hint's not going to solve that one, it is not a candidate on update_excuses
<Laney> but no, that's release team only
<Laney> that problem looks like component-mismatches to me
<Laney> for some reason libnm-gtk-dev is in main in cosmic-proposed but universe in cosmic
<seb128> Laney, thanks for pointing that one, that's something I can change if needed
<Laney> seb128: it's also trying to put the ayatana indicator stuff in main...
<Laney> unless network-manager-gnome can get demoted too
<seb128> ah, that's a Debian change to revert until that stack gets MIRed
<seb128> I'm going to look into that
#ubuntu-devel 2018-06-22
<doko> tjaalton: xserver in proposed for 30 days ...
<tjaalton> doko: waiting for nvidia update, maybe next week
<rbasak> cyphermox: do you know abut bug 1476769?
<ubottu> bug 1476769 in Fedora "When activating OpenVPN without DHCP6, random traffic will be routed without VPN" [High,Confirmed] https://launchpad.net/bugs/1476769
<rbasak> Feels very much like a desktop UI issue to me (in Network Manager), so not really a server thing. But it seems important, yet has languished.
<rbasak> nacc: I think pkg-php-tools can be synced, but thought I'd just check with you first.
<didrocks> bdmurray: hey! I think I answered your question on the g-c-c SRU, but I was unsure to have understand it, please keep me posted as we need the new strings to be translated for .1
<ahasenack> hi, I see ldb is stuck in migration because samba needs a rebuild with that package (otherwise samba-dsdb-modules won't install)
<ahasenack> I'm prepping a samba 4.8.2 merge that requires that particular ldb version that is in proposed
<ahasenack> is this where a "transition" comes in? If yes, how do I set one up?
<ahasenack> I verified that just rebuilding samba with that version of ldb is enough to adjust the Depends of samba-dsdb-modules and then both can be coinstalled
<cyphermox> rbasak: I didn't, but it looks very much like things are working exactly as intended
<cyphermox> for one thing, I no longer look at NetworkManager bugs
<cyphermox> (I think that's jbicha now)
<xnox> tseliot, https://launchpadlibrarian.net/375563583/systemd_237-3ubuntu10.1_237-3ubuntu10.2.diff.gz this is the debdiff i'm uploading.
<xnox> tseliot, you may want to try systemd from ppa:xnox/nonvirt to test that the extra fixes, do not break drm/nvidia-prime stuff. they shouldn't... cause otherwise it means that either v239 is broken; or i cherrypicked things badly =/
<tseliot> xnox: ok, let me test that
<tseliot> xnox: it works correctly here
<xnox> tseliot, yeay =)
<tseliot> :)
<xnox> thank you
<tseliot> thank you
<nacc> rbasak: checking
<nacc> rbasak: i have a serious backlog on php
<nacc> i havent' done the diff yet, but by changelog you seem right
#ubuntu-devel 2018-06-23
<tsimonq2> Just in case anybody isn't in #launchpad and are wondering where their !x86 builds are: https://twitter.com/launchpadstatus/status/1010308652438351872
* tsimonq2 changed the topic of #ubuntu-devel to: arm64/armhf/powerpc/ppc64el/s390x builders offline due to temporary datacenter outage Archive: open | 18.04 released | Devel of Ubuntu (not support or app devel) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | #ubuntu-app-devel for app development on Ubuntu
<tsimonq2> Huh, so I can change the topic. Cool.
* tsimonq2 changed the topic of #ubuntu-devel to: arm64/armhf/powerpc/ppc64el/s390x builders offline due to temporary datacenter outage | Archive: open | 18.04 released | Devel of Ubuntu (not support or app devel) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | #ubuntu-app-devel for app development on Ubuntu
<tsimonq2> There.
<tomreyn> not just you ;)
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> True.
* tomreyn changed the topic of #ubuntu-devel to: arm64/armhf/powerpc/ppc64el/s390x builders offline due to temporary datacenter outage <tsimonq2> Â¯\_(ã)_/Â¯ | Archive: open | 18.04 released | Devel of Ubuntu (not support or app devel) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | #ubuntu-app-devel for app development on Ubuntu
<tomreyn> whoops
* tomreyn changed the topic of #ubuntu-devel to: arm64/armhf/powerpc/ppc64el/s390x builders offline due to temporary datacenter outage | Archive: open | 18.04 released | Devel of Ubuntu (not support or app devel) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | #ubuntu-app-devel for app development on Ubuntu
<tsimonq2> hahahahahahahahaha
<tsimonq2> Â¯\_(ã)_/Â¯
<tomreyn> :)
<Unit193> Debian 902167, well that seems very unideal.
<ubottu> Debian bug 902167 in distro-info "distro-info: ubuntu-distro-info incorrectly lists the development release in --supported" [Normal,Open] http://bugs.debian.org/902167
<Unit193> (By that I mean fixing it will break things for me. :D )
<sladen>  
#ubuntu-devel 2018-06-24
<tsimonq2> .tiouc
<tsimonq2> woaaah
<tsimonq2> That's what happens when you don't look at your keyboard and try to type /topic but your fingers are off. :P
* tsimonq2 changed the topic of #ubuntu-devel to: Archive: open (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic
<tsimonq2> Suggestions for tweaking that are welcome.
<bluesabre> Seeking a cosmic (and eventually bionic) sponsor for https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1762595, anybody interested? Also noticed that package is chilling in proposed for a libcdio soname change
<ubottu> Launchpad bug 1762595 in gvfs (Ubuntu) "Thunar incorrectly thinks USB storage device hasn't finished ejecting" [Undecided,New]
<tsimonq2> WCOREDEVNEEDED
<jsqkldhf> Hi
<jsqkldhf> Is there a dev staff for PR / ubuntu.com ?
<jsqkldhf> I'd like to share my experience of showing "How to install Ubuntu" to my nephew
<jsqkldhf> I have installed Linux hundreds of times myself, so no problem for me, but when showing it to someone unexperienced, I have noticed
<jsqkldhf> a lot of small things that could be improved on the website, easy to fix, but that would make it a loooooooot easier "for the average Joe"
<jsqkldhf> tsimonq2 any idea of who I could talk with?
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> Perhaps https://github.com/canonical-websites/www.ubuntu.com/issues/new
<jsqkldhf> tsimonq2: thanks!
<tsimonq2> No problem.
<jsqkldhf> tsimonq2: I spent the last 30 minutes to do this ;)
<jsqkldhf> https://github.com/canonical-websites/www.ubuntu.com/issues/3440
<tsimonq2> Thanks.
<jsqkldhf> I just slightly updated it
<jsqkldhf> What do you think about it?
#ubuntu-devel 2019-06-17
<seb128> fginther, hey, I think you mentioned recently ps-jenkins recetly ... did you do any change around that? I started receiving list moderation emails when commenting on/approving mps on some unity components now
<tenplus1> hi folks, anyone got the insider info on the chromium-browser snap switchover ?
<tenplus1> seems the chromium snap is running very slow on startup and uses more memory, damn
<sarnold> tenplus1: it might be worth reporting to the folks in #snappy
<sarnold> I'm not sure if they'll be able to do anything, but they might be able to suggest where to send bug reports
<tenplus1> hi sarnold, was hoping someone in here would shine a light on why the sudden change to snaps, the .debs were a lot faster
<tenplus1> if it's to save devs creating debs for each new release I'd rather they didnt for a browser
<juliank> tenplus1: like for a browser it's really important, the rest you don't really need to keep up-to-date
<tenplus1> very true, but for a browser loading times and memory use are also very important
<tenplus1> and using snaps messes with all that
<rbasak> tenplus1: I can't speak for chromium specifically, but I am aware of the ever increasing rather ridiculous amount of work involved in maintain a "deb" for a browser in a stable distribution release when the browser upstream bumps dependencies more than is possible in the distro release.
<juliank> Star time is basically irrelevant for a browser, as it's usually running continuously
<rbasak> tenplus1: eg. Firefox's introduction of Rust
<tenplus1> it takes 20 seconds to load the browser, and that's from an ssd... not good
<rbasak> tenplus1: I wouldn't call it sudden. It's been brewing for a very long time.
<juliank> In any case, there's always Chrome which Google provides a deb for
<rbasak> Probably with everything bundled :)
<tenplus1> *shudder* never chrome :P  I use chromium because it's open source
<juliank> It's the same thing, with different branding, and a flash and a drm plugin
<juliank> rbasak: mostly yes, and they only build one deb for all releases
<juliank> So it's like a snap in a deb
<rbasak> juliank: sounds little different from a snap, except for the lack of sandboxing
<rbasak> snap :)
<tenplus1> I always thought that chromium didnt have all the google crap running in the background that reports home
<juliank> tenplus1: hint: it allows sync with Google accounts. It also has telemetry options
<sarnold> flash and drm plugin were all I ever heard were the substantial changes
<tenplus1> would probably be easier getting chromium-ungoogled then ?
<juliank> Use Firefox if you want to report home to Mozilla instead
<juliank> :)
<tenplus1> lol... ff isok but slow
<juliank> I also have opera installed
<juliank> I was testing debconf prompts with it....
<tenplus1> do you find that better to use ?
<juliank> No I have not even started it!
<juliank> I was just testing installing it :)
<tenplus1> ahh :)
<juliank> Also, it's just Chrome, but reporting home to Opera instead
<juliank> Soon well have Edge I guess, in case you want to report to Microsoft instead
<tenplus1> basically most browsers report home to someone eh ?
<juliank> I guess the WebKit ones don't, but get no security support.
<sarnold> I haven't extensively looked, but w3m probably doesn't :)
<juliank> netsurf is fun too, if you like static web, but with graphics
<tenplus1> I did try midori but kept crashing
<tenplus1> and kubu had a nice browser at one point that ran well, then they renamed it and it's buggy now
<juliank> Basically, you can only have www or privacy, pick one
<tenplus1> yeah, kinda sucks considering it's one of the most important tools today on desktops
<tenplus1> who knows, maybe ubuntu will go chro9mium-ungoogled one day :) a big marketing plus point for them :D
<tenplus1> o/
<sil2100> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<sarnold> teward: woot :)
<sarnold> ddstreet: congratulations :)
<sarnold> teward: congratulations :)
<teward> sarnold: thank you!
<ArchaicLord> Hi everyone, I been using Ubuntu for a while and have dabbled with programming. ( I worte a function and it worked) I would really like to make an effort and learn a lot more and get involved. I found some pages but I started going round in cicrles and some links to videos are not avalible.The developers at my work use Node.js and was wondering if there is anything I can do to learn this along side helping Ubuntu in my
<ArchaicLord> out of work time? Any suggetions?
<sladen> ArchaicLord: what you could do, is to install Node.js under Ubuntu.  And in doing so, check that the documentation is 100% correct
<sladen> ArchaicLord: if anything did not work perfectly, it could be reported as a bug, to help improve the documentation
<ArchaicLord> is there an offical place for Ubuntu Documentation? Node.js itself provides documentation should I not use this ?
<sladen> ArchaicLord: find a set of instructions (eg. the Node.js-provided instructions).  Follow those instructions exactly.  Do those instructions work?  Are any steps missing, or unclear.  Report bugs (in this case to Node.js)
<ArchaicLord> sladen done :) easy install.  THe hard but though was working out what instruction to use in the first place lol
<teward> connor_k: you alive?
<connor_k> teward, i think so
<connor_k> teward, what's up?
<teward> connor_k: an ubuntu forums guy prodded me (since my coredev application was approved) asking if I could take a look at #1613837 where it suggests changes to rtl8812au's dkms.conf for older kernel compat
<teward> in Bionic you TIL and it's still in proposed for 4.19, 4.20 and 5.0 compat with the kernel, what's the status on that?
<teward> or is there someone dedicated kernel team side that i should point this at?
<teward> and I try and avoid DKMS and kernel like the plague where I can so looking for where I should point this next
<infinity> teward: cascardo might be a good starting point on the kernel team, he's even touched that one in the past.
<teward> infinity: makes sense, was poking connor specifically on the bionic proposed one.  as i said i try and avoid touching the kernel heh
<teward> or DKMS stuff
<teward> i'll poke #ubuntu-kernel thanks infinity
<connor_k> teward, sorry, what do you mean by "TIL"? heh. I don't know if any one of us has been marked for DKMS fixing but maybe #ubuntu-kernel
<infinity> teward: I'm not really sure I see an actionable bug there, though.
<teward> infinity: nor do I, but i want a second set of eyes on this
<teward> infinity: AIUI though the bug SUGGESTS that for newer kernels it's not building
<infinity> teward: Given that trusty is out of community support.
<teward> I can't even confirm this in a VM
<teward> infinity: #ubuntuforums guy says Xenial, Bionic affected
<teward> i can't repro
<teward> infinity: i'm wondering if 14.04 -> 16.04 upgrade triggered this - DistroRelease: Ubuntu 16.04 <-- in the bug
<teward> so at least 16.04 seems affected
<sarnold> connor_k: TIL --> "touched it last", the name that shows up on eg https://merges.ubuntu.com/main.html?showProposed=true&showMergeNeeded=true
<Unit193> sarnold: TIL TIL.
<sarnold> Unit193 :D
<teward> infinity: i'm tempted to mark as "Incomplete" and say we need more evidence this happens on newer *buntu, but it's DKMS stuff that I try and tread lightly around
<Unit193> sarnold: Also that Ruby/openssl thing keeps hitting, I think I'm calling that one an undefined regression. :/
<connor_k> sarnold, oh thank you. I only know that to be "today i learned"
<teward> heh
<sarnold> Unit193: most of the regressions so far were nailed down to "don't use a self-compiled openssl", "if you're going to download packages from pip you may need to rebuild them" and "maybe running a three year old version of ansible has downsides :)
<infinity> teward: The log clearly shows it trying to build the 4.4 module against the 3.13 headers.  So, yeah, there might be a bug here in that it should specify its target more sanely.
<Unit193> sarnold: Hah, nice..And yeah, most certainly don't compile openssl yourself. :3
<connor_k> teward, infinity yeah, I'd like to take a look at this.
<connor_k> it'll be a good break from
 * connor_k looks up from other DKMS issues
<connor_k> other DKMS issues
<teward> heh
<sarnold> poor connor_k :)
<teward> sarnold: so how about that postman code review or w/e it was that massive one? :P
<sarnold> teward: I don't want to talk about it
 * sarnold hides
<connor_k> that's weird, he was /just/ here
<teward> lol
<teward> sarnold should never have shared that was what they were working on, and that it's a pain, because I now just poke them with that regularly xD
<sarnold> heheh
#ubuntu-devel 2019-06-18
<xnox> jibel:  didrocks: uploaded grub2-signed to match the grub2 upload. Note each time one uploads grub2 it creates a side-tarball for signing, which launchpad then signs and publishes in the archive like a custom upload (similarish to e.g. d-i)
<xnox> jibel:  didrocks: then one has to upload grub2-signed such that it would fetch those signed blobs, and repackage them into .deb and ship it in the archive, to make grub2 securebootable.
<xnox> anyway, uploaded
 * xnox hopes to get d-i buildable and migratable.
<jibel> xnox, thx
<didrocks> xnox: ah, good to know! Thanks! Is it documented anywhere?
<didrocks> so that I can add a bookmark for my own self next time :p
<cjwatson> Have these ZFS patches been sent upstream?
<xnox> didrocks:  no idea. but watch out for things that produce signing tarballs like: linux shim grub2 s390-tools
<xnox> all of which have linux-signed shim-signed grub2-signed s390-tools-signed matching packages
<xnox> jibel:  didrocks: also cyphermox is in the middle of rebase on top of 2.04 =)
<cjwatson> An entire new script in util/grub.d/ is a significant maintenance commitment if it's downstream-specific.
<didrocks> cjwatson: there is a card for this, we'll do it once zsys enters the distro
<didrocks> and we separated the ubuntu-specific things in following patches (like the "recovery" translations)
<didrocks> so that we only have in the first patch what can be upstreamed
<didrocks> xnox: got it, thx ;)
<cjwatson> I really recommend doing the upstreaming first next time.  From experience.
<cjwatson> We can end up in unfortunate situations where we have to maintain interfaces in perpetuity that have been changed in the review process upstream.
<didrocks> cjwatson: noted down, we wanted to testproof it a little bit, but that makes sense as well
<didrocks> what interfaces? I don't think we added anything in any lib (no new API)
<cjwatson> I don't think that multiple 10_linux_* scripts is a good pattern to follow, *at all*.
<cjwatson> The interface between the boot loader and the installed system is an interface.
<cjwatson> Dataset naming patterns, that sort of thing
<didrocks> we initially got it as 15_, but thought 10_ would be better as it override for zfs 10_linux and is really similar, we can rename it + add the conffiles transitions
<cjwatson> You misunderstand me.  My objection is not to the 10
<cjwatson> We need to work out how to integrate this properly so that we don't have to have multiple scripts for booting Linux.  The existence of 20_linux_xen is bad enough but really shouldn't be perpetuated
<cjwatson> Anyway, this isn't a veto since I no longer maintain Ubuntu grub2, but I wouldn't be willing to take this patch in Debian grub2 as it stands, and I'd be surprised if it were upstreamable (but I could be wrong)
<cjwatson> IMO to be upstreamable it must be integrated into 10_linux properly
<cjwatson> (Also, a minor point: zfs_enhance_support.patch shouldn't patch the autogenerated files Makefile.in and Makefile.util.am)
<didrocks> If it could be merged with 10_linux, that would be great, but I really doubt about it or it means 10_linux will need to be really refactored a lot to be properly testable (as we do with 10_linux_zfs) and in functions. The intersection of commonality is quite small, but happy to discuss this upstream
<cjwatson> Right, so start with preliminary patches to refactor it?
<cjwatson> I imagine that would be a good thing anyway
<didrocks> if my manager acks some time to do this, yes
<didrocks> (and ack on Makefile.in, will fix this)
<cjwatson> Ideally this would be laid out in such a way that the history handling could be shared by e.g. a btrfs implementation
<cjwatson> Not saying you actually have to implement that, but if there were obvious slots for doing so, to me that would be a good indicator that the code layout is about right
<didrocks> we have intermediate representations in memory of system layout and machines, so it can be generic enough (with in linux_entry() have switch cases for specifity in each file system)
<cjwatson> Anyway, don't get me wrong, I'm glad to see work being done here, the particular shape of it just caught me by surprise as somebody who cares about the packaging being long-term sustainable
<didrocks> We thought having a separate script will make it more maintainable, but I get you. Anyway, upstreaming is part of the plan and we'll ensure we have most of it upstream. Then, I will need to have official work time on merging with 10_linux as this will mean: more tests to write (we have 396 only on 10_linux_zfs) and I guess a month of refactoring for 10_linux
<cjwatson> Sorry, if anyone had asked me earlier I would have said a separate script would make it less maintainable, without a second's hesitation
<cjwatson> Some kind of upstream test framework for the grub.d scripts would be fantastic
<cjwatson> I know there's been some talk upstream about a project to rewrite the whole grub-mkconfig structure (again), but I don't know how far it's got
<didrocks> cjwatson: if I don't include Makefile.in and Makefile.util.am, debian/rules clean (and so debuild -S) is failing due to those files being modified before creating the source package
<cjwatson> didrocks: Only if you've first done a build in-tree
<cjwatson> In fact I think only if you've run ./autogen.sh in-tree
<cjwatson> If you do it via the debian/rules machinery then clean should revert those changes, via dh_autoreconf_clean
<cjwatson> It is not standard practice in this package to patch the autogenerated files, so it definitely works in general
<didrocks> cjwatson: hum, I have a clean git checkout (without any modifications), I modified debian/patches/zfs_enhance_support.patch to remove those 2 files patches and I run debuild -S
<cjwatson> See e.g. restore-mkdevicemap.patch
<cjwatson> Did you actually revert the patches too rather than just removing them from the patch file?
<cjwatson> Anyway, just telling you what standard practice is
<cjwatson> You can look at the other patches for proof
<didrocks> cjwatson: no patch is applied, no local modification, I remove Makefile.in and Makefile.util.am from debian/patches/zfs_enhance_support.patch, and then debuild -S, what is wrong in that workflow?
<cjwatson> I don't know, sorry, you'll have to work it out yourself.  I use git-dpm in Debian which may not be in use for the Ubuntu packaging
<cjwatson> Sounds like your local tree isn't quite clean
<didrocks> let me try a fresh checkout, maybe the file which triggers this behavior is in .gitignore
<didrocks> but I was told by cyphermox to use the git-dpm branch, but to build the source package with debuild -S
<cjwatson> That's what I do in Debian
<cjwatson> You don't need a fresh checkout
<cjwatson> Look at git ignored files
<didrocks> yeah, that's what I will try to purge and not only rely on git st
<cjwatson> e.g. git clean -dfx will probably sort it out
<cjwatson> Assuming you have nothing uncommitted that you want to keep in that tree :)
<didrocks> well, I did my cp first ;)
<didrocks> git clean -dfx doesn't do it, let me try to inspect any ignored files directly
<cjwatson> So wait, you're using git-dpm but you hacked the .patch file directly?
<didrocks> just for testing before committing
<cjwatson> That seems unlikely to work well.
<cjwatson> The files will still be modified in the working tree.
<cjwatson> Use git-dpm properly
<didrocks> why, "debuild -S" has no idea of git dpm?
<cjwatson> You have a category error
<cjwatson> It doesn't work that way
<didrocks> and cyphermox told me that for this package, just use debuild -S to build the source package
<cjwatson> Which is correct, but not if the working tree has been deliberately made out of sync with debian/patches/ ...
 * didrocks is more familiar with gbp
<cjwatson> git-dpm is a patches-applied workflow
<cjwatson> Things will not go well if you modify .patch files by hand in a way that makes them not be in sync with the working tree
<didrocks> ah? so debuild -S knows about git dpm and the applied commits?
<cjwatson> No, it doesn't have to
<cjwatson> The working tree has patches applied
<didrocks> ah, indeed, even in the ubuntu branch, I thought it was only after a checkout-patched command
<cjwatson> git-dpm checkout-patched; git rebase -i <whatever the corresponding upstream ref is>; edit the patch in question using git; git rebase --continue; git-dpm update-patches
<didrocks> ok, makes sense then, so I'll refresh the patch even for testing
<cjwatson> OK, that explains the confusion if you didn't realise it was patches-applied
<didrocks> yeah, I was thinking with the gbp model, which is different
<didrocks> ok, so let me rebase and test
<didrocks> cjwatson: ok, so all good now. I was really at 100 feets of thinking the ubuntu branch would be patch-applied (I thought only patched-ubuntu was, after checkout-patched). No more issue know. let me just stage that in tree. Thanks and sorry for the confusion
<juliank> not sure if I want to fix goplay on ppc64el (spurious? uninitialized variable error) or just ask for removal
<juliank> like last update in debian was me nmuing it in 2015
<cjwatson> didrocks: Cool, thanks
<juliank> Qt question:
<juliank> No rule to make target 'string', needed by '.ui/ui_debtagssettingswidget.h'.  Stop.
<juliank> packagesearch fails to build like that
<juliank> Anyone has an idea?
<juliank> hmm
<juliank> it's written like that in the Makefile
<juliank> that qmake generated
<juliank> why would qmake make that file depend on set and string, standard C++ headers?
<juliank> there are includes for that in the .ui file, but it seems like a bug in qmake to turn   <include location="global" >string</include> into a <file>: string depends
<juliank> nvm, I removed the include lines and it worked
<seb128> bdmurray, hey, do you have any idea why bug #1820130 is showing on https://people.canonical.com/~ubuntu-archive/pending-sru.html for disco but not bionic?
<ubottu> bug 1820130 in modem-manager-gui (Ubuntu Disco) "[SRU] modem-manager-gui fails to start after modemmanager is upgraded to 1.10.0-1" [Undecided,Fix committed] https://launchpad.net/bugs/1820130
<bdmurray> seb128: looking
<seb128> bdmurray, thx
<bdmurray> seb128: there's nothing obvious I'll run the report locally and see if I can sort it out
<seb128> bdmurray, thx
<seb128> juliank, bug #1766890 has been assigned to you since august 2018 ... do you still plan to work on it? if not it might be worth wontfixing it or unassigning as appropriate?
<ubottu> bug 1766890 in gnome-menus (Ubuntu) "package gnome-menus 3.13.3-6ubuntu3.1 failed to install/upgrade: triggers looping, abandoned" [Critical,Confirmed] https://launchpad.net/bugs/1766890
<juliank> seb128: closing as invalid
<seb128> juliank, thx
<bdmurray> seb128: I don't know what happened but it self resolved.
<mdeslaur> infinity, stgraber, vorlon, kees: TB meeting in 6m
<seb128> bdmurray, thx for checking, good that it autoresolved :)
<vorlon> mdeslaur: sorry for missing, feeling a bit under the weather today :/
#ubuntu-devel 2019-06-19
<seb128> bdmurray, hey, I'm unsure how you keep up with SRU bugs comment, so please have another look to bug #1832457 (also would be nice to not block SRUs in such cases when it's clear that the new serie isn't going to miss the update/fix)
<ubottu> bug 1832457 in glib2.0 (Ubuntu Disco) "[SRU] 2.60.4" [Undecided,In progress] https://launchpad.net/bugs/1832457
<juliank> This KDE phabricator thing is crazy
<juliank> When submitting it rewrites your last commit
<juliank> It's like it's written for a single commit
<ahasenack> hi, is there precedent in transforming a native ubuntu package into a non-native in ubuntu? Both in a devel release, and in srus?
<ahasenack> is that frowned upon?
<ahasenack> by sru, I mean a package that is native currently in a stable release, becoming non-native via an sru (there are other changes in the sru though, not just this)
<ximion> hey Laney :)
<ximion> I was just made aware that the LMDB dependency of AppStream is actually an issue for Ubuntu, as LMDB isn't in main (yet?)
<Laney> correct
 * Laney has tried to shift the paperwork onto acheronuk 
<ximion> Laney: of course in my opinion LMDB should be in main (you could enable it for bind9, postfix etc. as well then), but if there's anything I can help with, let me know
<ximion> (in the very worst case, AS could also run without cache, but that would be significant effort to make it work for terrible performance and memory usage)
<ximion> fortunately, LMDB is tiny, depending only on libc
<Laney> usually the main problem is if the MIR team decides to ask for a security review
<Laney> then it can take a while
<Laney> ximion: it's fine, we have this semi frequently, but it may delay any updates to appstream for a long while
<Laney> so in general (if you want to care about this situation), making new runtime deps conditional is nice
<ximion> Laney: I don't forsee any additional dependencies for AppStream - the library should really be quite small, all the annoying stuff (like font rendering and image scaling) should end up in asgen anyway
<ximion> a security review is sensible - I was just looking on whether RHEL has it yet, but it's only in EPEL there, at least for the current version
<Laney> I think suse has a similar procedure?
<ximion> jup - SUSE already has LMDB in the trusted zone (at least for openSUSE) though due to KDE depending on it
<ximion> (also RPM has a LMDB backend)
<ximion> I couldn't find any info on what SLE does though, which is more relevant
<sil2100> Laney: hmmm, it looks like britney dies for xenial since over a week: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2019-06-19/13:46:56.log
<sil2100> Laney: do you, by any chance, know this part of britney?
<Laney> sil2100: not off the top of my head, but I think we have a FauxPackage for snapd if the message just before the traceback is relevant
<Laney> those are in b1
<sil2100> Laney: ah, indeed! You think removing the faux package might help? I guess I can try that, since snapd now builds on powerpc
<sil2100> (at least it provides 'some' powerpc binaries)
<Laney> is that what changed around the time it started breaking?
<sil2100> Laney: yeah, that would fit, since the new snapd landed on the 11th, which was when the last time britney ran without crashing on xenial
 * sil2100 reverts and hopes for the best
<sil2100> Laney: do you know if such britney crashes are sent somewhere when they happen? Like some notification
<Laney> sil2100: probably the mailbox on snakefruit that nobody reads
<Laney> We just find out when someone notices :(
<sil2100> vorlon: hey! Do you know what could be the reason for this? https://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2019-06-19/16:09:59.log
<sil2100> I removed snapd from the FauxPackages because britney on xenial was crashing
<sil2100> And now it's just crashing totally
<vorlon> whee
<vorlon> checking
<sil2100> I feel strange because I thought I just reverted the snapd addition from some time ago ;p
<vorlon> sil2100: did you make your change locally or in the bzr branch?
<vorlon> because there's a conflict in the checkout
<sil2100> vorlon: ugh, I did a fresh bzr branch of lp:~ubuntu-release/britney/britney1-ubuntu, modified and bzr pushed
<sil2100> https://code.launchpad.net/~ubuntu-release/britney/britney1-ubuntu
<vorlon> rather strange, the branch history looks like all the changes should've been commits, not cowboys
<vorlon> anyway, I've resolved it now
<Laney> bet someone cowboyed and then committed the same thing
<sil2100> I only pushed this to the bzr branch
<sil2100> Can we kick britney for xenial somehow manually? Or should I find a xenial kernel to publish to -proposed ;p?
<sil2100> Since I wanted to see if this change makes xenial not-crash
<sil2100> vorlon: I already poked La_ney about that, but I guess it would be nice for us to get some kind of a notification whenever britney crashes, or maybe even something more sublime like 'no successful britney run after x days' or something
<sil2100> vorlon: I guess I could write something up quickly for our stable series
<sil2100> Since for devel it's easy to notice, but for stable we rarely look directly at excuses
<sil2100> Right now for instance, because of this we could have published some xenial updates that didn't have their autopkgtests ran and might have regressed
<sil2100> And it's the second time I see such a situation
<sil2100> Anyway, let me card it
<sil2100> vorlon: hmmm, so britney now is crashing for gnome-shell apparently - I wonder if maybe the gnome-shell fauxpkg entry should also be checked?
<sil2100> vorlon: I wonder though why it is failing now suddenly, but maybe there were some local changes cowboyed that now got removed?
<sil2100> vorlon: latest log: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2019-06-19/16:45:31.log
<sil2100> vorlon: what were the changes that were conflicting in the production branch? Was that something that could explain the issue here?
<sil2100> Laney: ^ you're probably EOD as well, right?
<sil2100> Do we have fauxpackages per-series?
<vorlon> sil2100: the conflicts were between snapd being shown as locally added and gnome-shell being added to the merge source, which didn't make any sense in the end
<vorlon> sil2100: is it possible it's crashing because gnome-shell/s390x exists as a real package in xenial?
<vorlon> sil2100: otoh gnome-shell has been in fauxpackages since april, without problems
<vorlon> sil2100: this is what ends up in xenial-proposed/Packages_s390x; I don't understand why the architecture string is what it is, I don't recall this detail of fauxpackages
<vorlon> Section: faux
<vorlon> Version: 3.18.5-0ubuntu0.3
<vorlon> Architecture: all
<vorlon> Package: gnome-shell
 * Faux twitches again.
<xnox> Faux:  sorry for all the highlights!
<infinity> vorlon: Oh, I just noticed the backscroll WRT fauxpackages.  I did indeed cowboy removal of the gnome-shell one when eoan opened and we realised it was breaking xenial.  I should have committed that, but I was hoping to dig deeper and figure out why.
<infinity> I think.
<infinity> Memory is fuzzy.
<vorlon> ah
<vorlon> Laney: ^^
<Laney> makes sense
<Laney> so let's commit removing that
<infinity> I think I may have cowboyed instead of comitted because I feared I'd need to flip it back in and out if it was needed for a larger migration.
<infinity> (but also, Debian seemed on the cusp of fixing gnome-shell on s390x at that point)
<infinity> Anyhow, removing it should just render a couple of things uninstallable on s390x-only, which is fine.  If it causes migration issues for newer versions of those same things, I'll reevaluate.
<infinity> The real problem here comes from our clever use of one britney base and multiple config files to handle N releases.  Maybe we could extend FauxPackages to have a series filter, if we cared, but we use it so infrequently...
<infinity> Laney: Did you want me to commit the revert, or was "let's" you saying you were doing so?
<Laney> infinity: Go for it
<infinity> Laney: Done.
<Laney> Ta
<GunnarHj> bdmurray: Still there?
#ubuntu-devel 2019-06-20
<bdmurray> GunnarHj: I am here now
<GunnarHj> bdmurray: I got a mail about ibus-libpinyin and libpinyin being listed at http://people.canonical.com/~ubuntu-archive/phased-updates.html . Not sure what "further phasing of this update has been stopped" means.
<bdmurray> GunnarHj: https://wiki.ubuntu.com/PhasedUpdates
<sarnold> GunnarHj: my expectation is that that means there's been too many reported errors
<bdmurray> or new errors which have been identified as new crashes about the package
<bdmurray> https://errors.ubuntu.com/problem/ef61e64ad08074140fed7545e9bc282fa19062e6
<bdmurray> there are crashes about the version of the package in -updates for 18.04 but not the release pocket
<bdmurray> the same is true about this crash
<bdmurray> https://errors.ubuntu.com/problem/0b1adaf6716f4f5bc62767caf11b5ada486b9ebb
<sarnold> hmm 1.11.0-1 is also marked as having problems
<bdmurray> but only in 19.04?
<sarnold> ahh, thanks
<sarnold> 0b1ada has 1.10.0-1 in 18.10 and 19.04, and 1.11.0-1ubuntu0.18.04.1 in 18.04..
<GunnarHj> bdmurray, sarnold: Ok, thanks. I think I'd better talk with Åukasz tomorrow to start with. He accepted it to -updates and knows the background well. Actually the whole purpose with the upgrade is to prevent too frequent crashes...
<bdmurray> this one is similar but still no 18.04 release pocket package verison https://errors.ubuntu.com/problem/0235922c2d31495d6a59c4dbef5f7b678710905e
<sarnold> that looks really similar, just with less garbage memory :)
<bdmurray> GunnarHj: I believe he is out the next couple of days.
<GunnarHj> bdmurray: Ah, not good. Then I'll try to explain more in an email to both of you.
<bdmurray> GunnarHj: Okay, sounds like a plan.
<GunnarHj> bdmurray, sarnold: Just a quickie. This is an example of the situation we are trying to get away from. 17000+ crashes with the old version.
<GunnarHj> https://errors.ubuntu.com/problem/cd3fa9b145c79364f535cede0267ffe384b9ced8
<sarnold> GunnarHj: oouucchh
<tmhoang> How to create a repository for .ddeb ? I tried dpkg-scanpackages but it cannot detect .ddeb packages. Thanks.
<cjwatson> apt-ftparchive
<cjwatson> not sure quite where it'll put them in the resulting repository, but it can certainly detect them
<cjwatson> (also, dpkg-scanpackages just needs -t ddeb)
<tmhoang> -t ddeb works. Thanks
<LocutusOfBorg> xnox, good morning, you want to merge intel-microcode? we have few cve fixes there...
<LocutusOfBorg> also, forwarding the delta might be beneficial, its a two line patch, right?
<LocutusOfBorg> I can open a merge request if you want
<xnox> LocutusOfBorg:  merge request was closed before, i need to resubmit it together with matching patch for amd64-microcode and initramfs-tools.
<xnox> LocutusOfBorg:  probably after release....
<xnox> LocutusOfBorg:  and to be honest, i'd rather wait for security team to pick it up for all releases.
<ddstreet> xnox apologies if i targeted/commented lp #1831296 wrong
<ubottu> Launchpad bug 1831296 in systemd (Ubuntu Eoan) "__main__.SeccompTest is failing on Ubuntu CI" [Undecided,New] https://launchpad.net/bugs/1831296
<xnox> ddstreet:  it will do, there is no great place for those.
<GunnarHj> Hi bdmurray, did you see my email about ibus-libpinyin? How do you look at it?
<bdmurray> GunnarHj: Reading it now
<bdmurray> GunnarHj: Okay, I'll override the ibus-libpinyin increased rate of crashes and crash 0b1ada given how bad the current version in bionic is.
<GunnarHj> bdmurray: Thanks! I think - and hope - that it is the right thing to do.
#ubuntu-devel 2019-06-21
<TiCPU> Hi, the package pulseaudio-esound-compat seems to be missing from Disco, there's no bug open about it and it still build and install without error using the Cosmic sources. How can I make a request for the package to be included in the next release?
<sarnold> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561780
<ubottu> Debian bug 561780 in src:pulseaudio "pulseaudio-esound-compat: leaves empty /tmp/.esd-1000 directory behind on exit" [Wishlist,Fixed]
<sarnold> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1807079
<ubottu> Launchpad bug 1807079 in pulseaudio (Ubuntu) "Merge with Debian pulseaudio 12.2-2" [Wishlist,Fix released]
<sarnold> TiCPU: it's pretty thin on reasons, but those are the bugs
<jamespage> Laney: good morning
<jamespage> Laney: any chance you could take a look at the bionic backport I uploaded to address https://bugs.launchpad.net/charm-ceph-osd/+bug/1818680 ?
<ubottu> Launchpad bug 1818680 in Bionic Backports "booting should succeed even if vault is unavailable" [Undecided,In progress]
<jamespage> pretty please :)
<sbeattie> xnox: hi, I'm trying to do a local test rebuild of a package currently in eoan-proposed, but my schroot is taking a long time (enough time that I thought it had hung) at 'Setting up lvm2 (2.03.02-2ubuntu4) ...' any idea what's going on? pstree gives "apt-getâââdpkgâââlvm2.postinstâââvgcfgbackup"
<sbeattie> (this particular bionic system does not use lvm)
<sbeattie> (behavior reproduces with the version that made it out of eoan-proposed)
<Laney> jamespage: done!
<xnox> sbeattie:  what package are you rebuilding?
<xnox> sbeattie:  and it build-depends on lvm2? (which is a bit odd, given that doesn't have headers or anything, well i guess a test-time dep)
<xnox> sbeattie:  in a chroot..... it shouldn't. do you bind mount /run & /dev from the host as well?
<xnox> sbeattie:  so e.g. eoan on eoan rebuilding libvirt is fine.....
<teward> vorlon: if you get 3 minutes, can you drop me a PM please?  Got a question to ask off-channel
<sbeattie> xnox: was trying to rebuild glibc, but can reproduce it rsnapshot.
<sbeattie> xnox: /dev and /run/shm get mounted into the schroot
<sbeattie> xnox: I attached strace to the vcfgbackup running in the schroot and got http://paste.ubuntu.com/p/5wCqNvqW5R/
<xnox> teward: I believe vorlon is mostly away from keyboard.
<teward> xnox: not a rush :)
<xnox> sbeattie: please open a bug.
<sbeattie> xnox: ack
<vorlon> teward: the normal way to do that is that you send your question in a PM...
<teward> vorlon: was having problems with Freenode rejecting :/
<vorlon> I don't think that would get better as a result of me initiating the PM :)
<teward> no, but Freenode is weird :|
<teward> i ended up just redoing my IRC connection (AndroIRC I think busted things?) to here and it worked :|
<dreamcat4> hey there i seem to be having a rather basic packaging dilemma. is this something i can ask about here ?
<dreamcat4> basically i am unsure whether to disribute the config file as .sample, and then use a postinstall script to copy it to the real name (if the file does not already exist). with cp --backup. to backup the old one
<dreamcat4> but then the true config file cannot be marked as such in my pkg, because it isnt being distributed within the package under that name
<sbeattie> xnox: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1833758
<ubottu> Launchpad bug 1833758 in lvm2 (Ubuntu) "lvm2: vgcfgbackup in postinst takes several minutes" [Undecided,New]
<sarnold> ow
#ubuntu-devel 2019-06-22
<teward> anyone on who can take a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/k/kopano-webapp/20190621_153010_3daca@/log.gz and see if this is something NGINX related?  It sounds to me like their test is just bad
<LocutusOfBorg> vorlon, xnox FYI, I'm trying a mono sync from Debian, to see how far the s390x patches went
<LocutusOfBorg> (in my ppa: https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/17181194 )
<LocutusOfBorg> will sync if build is good
#ubuntu-devel 2019-06-23
<tsimonq2> teward: kopano-webapp> Message: unknown error: Chrome failed to start: crashed
<tsimonq2> Yeah, so that's probably their issue, unless nginx has become an Electron app or something crazy like that. :P
<RAOF> dreamcat4: policy would typically suggest that you so the config file *as* a config file (optionally with UCF  helpers in the maintainer scripts)
<RAOF> dreamcat4: So, barring extraordinary circumstances, I would not do any copy-in-postinst shenannagins
<vorlon> ucf and conffiles are mutually exclusive
<teward> tsimonq2: well the tests us their apache2 plugin not NGINX
<teward> tsimonq2: so wrt NGINX it's not really NGINX's bug, but since it relies on httpd that's pulled into the tests
<teward> tsimonq2: but given that it's got that kind of an error I'm pretty sure that this is going to be a failure in the test.
#ubuntu-devel 2020-06-15
<ahasenack> sil2100: hello, just you and I in +1 maintenance today?
<sil2100> ahasenack: hey! I guess so, yes, I only recently started with real +1 work as I had a backlog of stuff from my holidays last week
<ahasenack> sil2100: and it's my first time doing this
<ahasenack> sil2100: I plan to go over the wiki and latest report emails to see what's going on, and then pick something to work on
<sil2100> ahasenack: yeah, that works!
<sil2100> If you could give me a sign here once you start something so that I know I should take something else
<sil2100> For now I look at NBSes
<ahasenack> ok
<ahasenack> sil2100: I'll check https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#golang-testify could be an easy win
<ahasenack> sil2100: after that, I might look at some node-* packages being stuck, as I'm starting to get involved in node packaging, for hysterical reasons
<jdstrand> bdmurray: hey, fyi bug #1872118. quite a few people are seeing dhcpd crash in certain configurations. can someone from your team look at it at whatever priority makes sense to you?
<ubottu> bug 1872118 in isc-dhcp (Ubuntu) "DHCP Cluster crashes after a few hours" [Undecided,Confirmed] https://launchpad.net/bugs/1872118
<jdstrand> bdmurray: and https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872106 which may be a duplicate
<ubottu> Launchpad bug 1872106 in isc-dhcp (Ubuntu) "isc-dhcp-server crashing constantly [Ubuntu 20.04]" [Undecided,Confirmed]
<bdmurray> jdstrand: noted
<jdstrand> bdmurray: thanks!
<bryyce> teward, just wanted to let you know I've picked up the nginx merge with debian and will be working on it this week
<teward> bryyce: glad to hear, thank you for the heads up
<bryyce> teward, we have a tool called git-ubuntu that is handy for organizing the ubuntu delta and reapplying it to debian, I'll be restructuring your work using it to perform the merge.  This should hopefully also make future merges more straightforward to perform, though it's not required of course.
<teward> yep
<teward> i CBA to get git-ubuntu working on my side but we will see more merges in the future, Debian's got new attention/uploaders so they are actually taking from the deltas we've arleady added.  It'll be nice to reduce our deltas heh
<teward> bryyce: though i'll thank a crash-course to make the merges easier.  Even with git-ubuntu My plate's full of things right now heh.  :P
<bryyce> teward, no worries :-)
<rbasak> teward: FWIW, you can do the merges using the git-ubuntu workflow but without the git-ubuntu tool. Though the instructions are geared towards the tool, so maybe a bit harder to pick it up initially. But if you really don't want to use the tool, you should know that it's perfectly possible to do it without.
<rbasak> The tool just saves some typing and smooths over some edge cases
<teward> Yep.  Tool or not the merge is still not something i have sparr cycles for at the moment.  Redeply of a firewall without backups for a client is a painnnnnn
<rbasak> Sure np.
#ubuntu-devel 2020-06-16
<mwhudson> hmhm the right fix for https://bugs.launchpad.net/ubuntu/+source/installation-guide/+bug/1876151 in focal involves removing a package
<ubottu> Launchpad bug 1876151 in installation-guide (Ubuntu Focal) "Ubuntu Documentation says 20.04 can be installed on i386" [High,Triaged]
<mwhudson> i guess we should make installation-guide-i386 empty in focal-updates instead?
<mwhudson> vorlon: ^
<vorlon> mwhudson: yeah, I'm ok with making the package empty
<mwhudson> now if only i could remember my trick for that
<mwhudson> i think it was snapd on powerpc that i did it for before...
<knocte> do gtk2 apps have the same theme as gtk3 apps in ubuntu 20.04? or is that a known issue?
<guiverc> knocte, see https://manual.lubuntu.me/stable/3/3.2/3.2.2/appearance.html for setting GTK2 and GTK3 theme (they are different entities)
<xnox> jibel:  could you please fill out the SRU template on https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1880869 ?
<ubottu> Launchpad bug 1880869 in ubiquity (Ubuntu) "Use persistent device name for vdevs" [High,Fix released]
<xnox> also https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1875045 ?
<ubottu> Launchpad bug 1875045 in ubiquity (Ubuntu) "Ubiquity 20.04 exports existing ZFS pools" [Low,Fix released]
<jibel> xnox, sure, will do
 * guiverc says sorry, I thought my last reply was in room #lubuntu  (sorry knocte)
<kswoboda> hello everyone :)  I've got a question regarding proposing a patch to a Ubuntu package. Would it be possible to somehow fork the repository and create a request to accept the patch? Are there any guidelines available or smth?
<seb128> kswoboda, hey, depending of the package but if the package has a Vcs then you can do a merge request, otherwise a .patch or debdiff attached to a launchpad bug report works
<kswoboda> seb128 thanks for the answer ;)  the package has a vcs - https://launchpad.net/ubuntu/+source/collectd, but it seems like only "Members of Ubuntu Server Dev import team can push to this repository."
<seb128> kswoboda, https://help.launchpad.net/Code/Git could help
<seb128> no nice UI to fork but you can checkout and push to your from the command line
<kswoboda> ok, thank you
<ahasenack> sil2100: hi, I uploaded a fix for the go package from yesterday (golang-go.uber-zap) which should unblock golang-testify
<ahasenack> sil2100: now I'm looking at https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#golang-yaml.v2 which should also unblock others when fixed
<ahasenack> I'll update the wiki
<sil2100> ahasenack: thanks!
<sil2100> ahasenack: I'm still working on NBS stuff :)
<sil2100> So baiscally https://people.canonical.com/~ubuntu-archive/nbs.html
<sil2100> ahasenack: hey! I'll be looking at pytest that's in -proposed right now, as it's related to an NBS I'm seeing
<ahasenack> ok
<ahasenack> sil2100: I *may* look at dovecot later, found out by accident it's a sync done by my team and is an ftbfs at the moment
<vorlon> mdeslaur, kees, stgraber: unless there's an indication we'll have quorum for TB today, I expect to be afk for the meeting
<seb128> bdmurray, thanks for the wpa review (I had uploaded a newer revision to G so the version used would have worked but your tweaked one works as well)
<bdmurray> seb128: it would have worked but then if there was another SRU it would have had to be ubuntu5.1 which would have looked weird to me.
<seb128> bdmurray, fair enough :)
#ubuntu-devel 2020-06-17
<mwhudson> anyone happen to know how grub finds its configuration when booting under uefi?
<stgraber> there's normally a minimal grub.cfg alongside grubx64.efi in /boot/efi/EFI/ubuntu/ which has enough logic to source the main config from whatever partition has /boot/grub.cfg
<mwhudson> stgraber: thanks, turns out i was not testing the thing i thought i was testing, sigh
<teward> bryyce: rbasak: when the nginx package has been git-ubuntufied can you give me the location to git-ubuntu clone it?
<teward> (thank you!)
<bryyce> teward, sure.  It'll be findable at https://code.launchpad.net/ubuntu/+source/nginx, or just run 'snap install git-ubuntu; git ubuntu clone nginx'
<bryyce> teward, I finished importing it to git ubuntu today, but need to make sure what remains is accurate, and build/autopkgtest it.
<teward> cool.  i have git-ubuntu installed already so i'll just git ubuntu clone it as you indicated.
<teward> and again if there's anything you want me to peek at let me know, there's a few changes also in the works - moving some of the SSL components to a conf.d snippet instead of keeping in nginx.conf (been requested many times)
<teward> s/SSL components/default SSL components/
<teward> so that's a packaging level change but i'll let the merge happen first :)
<bryyce> teward, thanks, yeah would be helpful to get your eyes on the result to make sure I haven't messed any important bits up :-)
<bryyce> teward, btw I noticed debian seems to have some of the php version stuff under /run rather than /var/run, so wondered if that's led to any issues with anyone, or if it's just a theoretical issue
<teward> bryyce: it's more of an issue when we do backports to releases where everything isn't in /run or /var/run or such isn't symlinked to /run or a few other cases - i haven't heard of it causing any issues in Debian so long as the configuration is updated properly to know the different locations.  The NGINX PPA has been a direct-from-debian sync since eternity and has not had any issues with /run vs. /var/run so long as the PID config is done
<teward> right.
<teward> but i'll take a look after i wake up
<teward> 01:46 local and last night I didn't sleep well so i need to get to bed heh
<bryyce> teward, sleep well
<teward> bryyce: ideally what we're going to do here is match the Ubuntuisms with the configs (php paths, etc.) so if you want to do me a solid and see where php-fpm in Groovy ends up dropping its socket, that'd be great, I *think* it's a /var/run path, but I forget exactly.  :P
<teward> i'm also thinking of moving the PHP configs to a snippets/ config snippet for easier inclusion into other configs as well, just as a heads up for future planned ideas/changes that are minor but make things look nicer and easier for end users heh
<bryyce> teward, that'd be great, thanks
<bryyce> yeah I can look into what php-fpm does
<teward> bryyce: I don't have upload / push privs it seems, heh.  not sure whether that's an issue, but I can just dump merge requests if necessary
<bryyce> teward, Mp's are fine, that's basically our standard procedure already.  afaik push privs are just == core dev
<teward> heh.  well i am coredev so xD
<teward> alls good.  actually going to sleep now.  /off
<bryyce> night o/
<knocte> do gtk2 apps have the same theme as gtk3 apps in ubuntu 20.04? or is that a known issue?
<seb128> rbasak, hey, if you doa  SRU shift today could you review the gnome-shell stack in the focal queue? it's waiting for 10 days and including some fixes we would like to see landing
<seb128> rbasak, also for an easier one gnutl28/focal would be nice
<seb128> rbasak, gnutls28 uploaded to bionic as well, would be nice to also review, it's a simple patch but it should fix connection failing to yahoo/aol/verizon emails servers (following server changes so it used to work and recently stopped working in bionic/focal)
<rbasak> seb128: sure - if I get to my SRU shift today I'll look at those.
<cpaelzer> hi doko, if I'd file a LP bug to get a fix for https://sourceware.org/bugzilla/show_bug.cgi?id=23465 into Bionic is ther any chance this will happen or should I stop right away?
<ubottu> sourceware.org bug 23465 in gas "wrongly scale non-8-bit x86 displacements" [Normal,Resolved: fixed]
<cpaelzer> fnordahl: ^^ FYI
<cpaelzer> well I blindly assumed binutils would usually be you doko, let me actually check the changelog  ...
<doko> cpaelzer: including the referenced commit in the bug report?
<cpaelzer> doko: yeah I guess that is what would need to be backported
<cpaelzer> mostly changing the self tests afaics
<cpaelzer> I think the effective functional change would just be https://sourceware.org/git/?p=binutils-gdb.git;a=blobdiff;f=gas/config/tc-i386.c;h=b8042ba434207efe9d70c9de9654a2ff110a2c9d;hp=cd69321bdb25f698f7764e5648d10253472724a3;hb=4e518864c879be2e6af4c64415e8775d9a20deaf;hpb=e521dc888158a6cdbdccef0397e663c437450a80
<fnordahl> cpaelzer: ta for heads up
<cpaelzer> sure fnordahl - if doko says it appears to be generally doable I'd file a proper LP bug for it and reply that to the mail
<cpaelzer> asking them to chime in on the bug for e.g. testing
<mantas-baltix> Anyone noticed, that Snap store launcher is untranslated in Applications menu (Activities Overview)? I've registered a bug #1882929 , but no answer from developer in 7 days :(
<ubottu> bug 1882929 in snap-store "Ubuntu Software (Snap Store) desktop launcher Name isn't translated in Ubuntu 20.04" [Undecided,New] https://launchpad.net/bugs/1882929
<cpaelzer> doko: I'll file a bug as that will be quick - could you state ther eif you consider this doable or not?
<cpaelzer> that will also serve as a single place to unite communication on the topic
<cpaelzer> doko: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880 it is
<ubottu> Launchpad bug 1883880 in binutils (Ubuntu Bionic) "fix non-8-bit x86 displacements breaking AVX512 builds on Bionic" [Undecided,New]
<cpaelzer> fnordahl: ^^ for you to subscribe to
<seb128> rbasak, thanks!
<ahasenack> seb128, doko: hi, I'm starting my day, +1 maintenance for the whole week. I updated the wiki with what I have going on
<seb128> ahasenack, ack, thanks, I'm about to start as well, I will check what you put there and update the channel as needed
<doko> ahasenack, seb128: manually cleaned up some NBS binaries in -proposed, now working from the bottom, on ftbfs. lib3mf
<ahasenack> doko: did you happen to see mail-stack-delivery (from dovecot) in those nbs?
<ahasenack> it's not in the report yet, I think because current dovecot (a sync) is an ftbfs
<doko> no
<ahasenack> ok
<ahasenack> one thing I'm noticing with this +1 rotation is that my inbox is getting out of control
<ahasenack> since I'm not focusing on other tasks
<ahasenack> https://github.com/golang/go/issues +5000 issues open
<ahasenack> what chance to I have
<ahasenack> *do
<ahasenack> xnox: about that golang issue from yesterday, should I file a bug upstream with go? I fear a rabbit hole if I keep digging, like starting a matrix of tests with multiple versions of unpatched go (i.e., not from ubuntu, but straight upstream)
<ahasenack> I could file that issue upstream, and upload the yaml.v2 package with that crazy patch of mine with a link to that issue
<ahasenack> that would unblock our migration, and help prometheus to migrate as well I'm told
<ahasenack> doko: do you have an opinion? Do you fancy go? :)
<ahasenack> crazy patch is https://bugs.launchpad.net/ubuntu/+source/golang-yaml.v2/+bug/1883770/comments/4
<ubottu> Launchpad bug 1883770 in golang-yaml.v2 (Ubuntu) "Tests fail on s390x and go >= 1.13" [Undecided,New]
<doko> ahasenack: you should ask mwhudson ;p   but yes, I think we need a more general solution for all the go packages
<ahasenack> it's the first I see of this, can't say it's affecting others
<ahasenack> mwhudson is many hours away
<ahasenack> I'll file the upstream bug, see how they respond over this week while I'm still on +1 maint
 * ahasenack thinks we need an acronym for "+1 maintenance"
<rbasak> POM
<rbasak> When there are two people on rotation, you would therefore have POM POM.
<ahasenack> sounds like PAN PAN
<ahasenack> inside airplane pilots joke
<ahasenack> xnox: I filed https://github.com/golang/go/issues/39651
<ahasenack> xnox: I also just tried upstream's s390x build and the test fails in the same way, so it doesn't look any of our patches are the culprit
<cpaelzer> doko: the upsream people already chimed in on bug 1883880 to help wit ha testcase
<ubottu> bug 1883880 in binutils (Ubuntu Bionic) "fix non-8-bit x86 displacements breaking AVX512 builds on Bionic" [Undecided,New] https://launchpad.net/bugs/1883880
<cpaelzer> doko: that should make an SRU easier
<sforshee> LocutusOfBorg: dkms 2.8.2-1ubuntu1 is breaking building dkms builds in our kernel packages, and it looks like the change which breaks us has been reverted upstream - https://github.com/dell/dkms/commit/885f8275aa65fb11be1e17bc28a0b0ea734dc585
<sforshee> can we get that reverted in our package too?
<sforshee> apw: ^
<apw> utter shit
<apw> oops :) applogies
<LocutusOfBorg> ohhhhhhhhhhhhhh
<LocutusOfBorg> thansk sforshee
<LocutusOfBorg> I was trying hard to find that commit!
<LocutusOfBorg> thanks a lot!
<LocutusOfBorg> damn, I didn't look at irc :/
<LocutusOfBorg> I have another possibly breaking change, lets see how far we go
<ahasenack> I have a curious go test problem. In a PPA, it fails because it cannot download a certain go module
<ahasenack> but locally in lxd, with network *disabled*, it doesn't try that, and it works
<ahasenack> https://pastebin.ubuntu.com/p/G3FprRXztN/
<ahasenack> any ideas?
<ahasenack> same package, version, proposed enabled
<ahasenack> ah, wait, I don't have proposed enabled in the lxd container
<LocutusOfBorg> sforshee, looks really better now :D
<sforshee> LocutusOfBorg: great, let me retry these kernel builds and see how it goes
<ahasenack> hm, no change with proposed
<ahasenack> for some reason, locally it doesn't reach out
<ahasenack> I wonder if it's about a controlling terminal during the build, if it behaves differently in each case
<ahasenack> aha!
<ahasenack> it was the terminal
<ahasenack> if I run dpkg-buildpackage -uc -us > ../log 2>&1
<ahasenack> then it fails locally as well
<ahasenack> sneaky!
<ahasenack> hm, scratch that
<ahasenack> mwhudson: hey, saw you are online
<mwhudson> ahasenack: hi
<ahasenack> mwhudson: if you have an idea, I have this problem: in a ppa, the go test tries to pull in a module from the internet
<ahasenack> but locally (lxd), it doesn't: https://pastebin.ubuntu.com/p/G3FprRXztN/
<ahasenack> https://launchpad.net/ubuntu/+source/golang-github-fsouza-go-dockerclient/1.6.5-1/+build/19442767 is the package/build in question
<ahasenack> and locally I tried without a network (used lxc exec to enter the container, and disabled eth0)
<mwhudson> does the package depend on golang-golang-x-crypto-dev?
<mwhudson> but hm yeah that's strange
<ahasenack> mwhudson: no, we don't even have that package
<mwhudson> oh i bet golang-github-docker-docker-dev depends on golang-golang-x-crypto-dev in debian but not ubuntu
<ahasenack> mwhudson: looks like it was added by http://paste.ubuntu.com/p/23vMxTBWCV/ once upon a time, and upstream took it
<ahasenack> mwhudson: oh, so golang-golang-x-crypto-dev provides that ssh/terminal bit?
<mwhudson> yes
<ahasenack> but still wouldn't explain why it works locally
<mwhudson> that's true that is strange
<ahasenack> hm, so I have that installed
<ahasenack> but the builder log doesn't show it being installed
<ahasenack> I'll investigate that
<ahasenack> mwhudson: indeed, the debian build log shows golang-golang-x-crypto-dev being installed
<ahasenack> ours doesn't
<ahasenack> interesting
<ahasenack> mwhudson: I have enough to go on now, many thanks
<mwhudson> ahasenack: it'll be related to the golang-docker-*-dev stuff
<mwhudson> in any case, if the package imports it directly, it should be in b-d, iow that debian patch should have come with a change to control as well
<ahasenack> mwhudson: check out this fun golang bug I filed today, btw: https://github.com/golang/go/issues/39651
<mwhudson> ahasenack: mundaym is pretty good at fixing this kind of stuff
<mwhudson> ahasenack: did you try 1.15beta1 fwiw? it's available as a snap now
<ahasenack> mwhudson: I noticed he is from ibm, and he mentioned he fixed a similar bug in the past
<ahasenack> mwhudson: I didn't, I just tried the upstream binary tarball for s390x, I saw they had one
<mwhudson> ahasenack: yeah, he did the s390x port
<mwhudson> ahasenack: https://dl.google.com/go/go1.15beta1.linux-s390x.tar.gz is a thing too, might be worth a try if you have an environment set up
<ahasenack> oh, I do
<ahasenack> let me fetch that
<ahasenack> mwhudson: 1.15b1 failed the same way
<mwhudson> ahasenack: ah well
<ahasenack> worth a try
<mwhudson> leave it to the ibm elves then :)
<ahasenack> hehe
<mwhudson> (unless you want to start staring at disassembly)
<ahasenack> mwhudson: there is a shocking diff between the Depends of golang-github-docker-docker-dev in debian and ubuntu: https://pastebin.ubuntu.com/p/9d8XmsfGqT/
<ahasenack> we have all that stuff vendorized?
<mwhudson> ahasenack: ah hah um yeah
<mwhudson> i don't know, tbh
<ahasenack> we don't use dh-golang to build
<ahasenack> and debian declares a *lot* of manual Depends packages
<ahasenack> ok, something for later
<ahasenack> let me fix this build
<ahasenack> mwhudson: https://code.launchpad.net/~ahasenack/ubuntu/+source/golang-github-fsouza-go-dockerclient/+git/golang-github-fsouza-go-dockerclient/+merge/385957
<ahasenack> confirmed fixed in https://launchpad.net/~ahasenack/+archive/ubuntu/fsouza/+packages
<mwhudson> ahasenack: +1
<ahasenack> mwhudson: can you do a quick +1 in the mp?
<xnox> ahasenack:  we have outofsync containerd/docker-dev stuff between debian and ubuntu
<xnox> ahasenack:  i think we are newer, and that's causing divergence in the build-depends.
<ahasenack> mwhudson: awesome, thanks
<xnox> because stuff got reorged
<ahasenack> xnox: it's quite the divergence
<ahasenack> I filed a bug to investigate that
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1883978
<ubottu> Launchpad bug 1883978 in docker.io (Ubuntu) "Possibly missing dependencies in golang-github-docker-docker-dev" [Undecided,New]
<ahasenack> xnox: it was a difference in depends, not just build-depends
<ahasenack> haven't checked b-d
<mwhudson> also the debian maintainer has a king sized pair of jfdi boots
<ahasenack> it's weird to have golang.*-dev packages as depends
<ahasenack> rbalint: doko: osomon: seb128: hello fellow +1maintainers for tomorrow (18th), I kept my wiki entry up-to-date under the "Progress" title
 * ahasenack -> EOD
<sarnold> ahasenack: nice find
#ubuntu-devel 2020-06-18
<doko> ddstreet: I see you touched knot-resolver before. would it be possible to look at the merge? currently fails autopkg tests with the new knot version
<doko> xnox: did you follow-up on https://github.com/ntop/nDPI/pull/840 ?
<xnox> doko:  i have not
<xnox> doko:  i failed at configuring wireshark and inspecting packets to understand if nDPI is broken, or if the test data is broken (and is endian specific), or both.
<danboid> didrocks: Will zsys handle spare disks ie automatically replacing dead disks with spares?
<danboid> I've not had any luck getting this to work with zed
<ahasenack> good morning
<danboid> In my experience, when a disk fully gives up the ghost, zfs sees it as REMOVED, which is when it would ideally be auto-replaced with a hot spare
<danboid> At the moment I'm having to replace failed disks manually when they fail with my proxmox RAID2 array
<danboid> RAIDZ2
<ahasenack> danboid: is zed running? afaik it's the one responsible for the replacement actions
<ahasenack> maybe it's missing a config
<ahasenack> sorry, just jumping in on what you said last, no idea about context
<danboid> ahasenack, Yeah its running bu I've read reports of others having this issue with zed
<danboid> claiming it doesn't actually work for swapping spares. Have you got zed to work?
<ahasenack> I remember having to do something with in to enable hot spare
<danboid> I have attempted to configure it according to the docs and a guide I found
<ahasenack> back when I tested this, in an older system
<danboid> Don't suppose yoiu still have your zed config do you?
<ahasenack> no
<ahasenack> I'm trying to remember
<ahasenack> I think it had to be told to listen to this particular event
<ahasenack> I'm checking the default config to see if something rings a bell
<danboid> OK thanks
<danboid> I'm wondering if zsys may expand to cover this
<ahasenack> danboid: do you have autoreplace=on in the pool?
<ahasenack> zpool get autoreplace
<danboid> ahasenack, No! That could be my problem then. I'll enable that
<danboid> Thanks!
<ahasenack> hope it works
<ahasenack> more details I don't have at the moment
<doko> sforshee, apw: looking at https://launchpad.net/ubuntu/+source/gkrellm2-cpufreq/0.6.4-6/+build/19239466 is libcpupower-dev something which should be built from the kernel sources?
<LocutusOfBorg> tjaalton, http://debomatic-amd64.debian.net/distribution#unstable/renderdoc/1.7+dfsg-3.1/buildlog do you care about debian?
<LocutusOfBorg> I uploaded in groovy the fix
<ahasenack> doko: upstream golang fix for that s390x issue :) https://go-review.googlesource.com/c/go/+/238628/
<didrocks> danboid: this is rather a built-in ZFS feature. But we'll propose in the future built-in raid and spare in the installer
<xnox> ahasenack:  so obvious!
<ahasenack> xnox: I'm confused, in which timezone are you in again? :)
<ahasenack> I thought UK
<ahasenack> but then I saw you online at like 10pm my time
<xnox> i have midnight weekly calls
<danboid> didrocks: Yes, adding spare zfs disk suppport to the installer would be a very nice feature to have
<danboid> didrocks: Any idea when the installer will better support zfs ie creating zfs partitions, RAIDZ etc?
<danboid> Might we see any of this in 20.10?
<ahasenack> xnox: ouch
<oSoMoN> I doubt this is going to collide with anyone else doing +1 maintenance, but just in case, I'm looking at rocksdb FTBFS (bug #1884072)
<ubottu> bug 1884072 in rocksdb (Ubuntu) "FTBFS in groovy" [Undecided,New] https://launchpad.net/bugs/1884072
<oSoMoN> ha, just saw rbalint's comment on the bug, okâ¦
<oSoMoN> so IÂ guess I'm not working on this any longer :)
<oSoMoN> python-cogent autopkgtests pass locally, can anyone please retry https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=python-cogent&trigger=python-cogent%2F2020.2.7a%2Bdfsg-2 , https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=arm64&package=python-cogent&trigger=python-cogent%2F2020.2.7a%2Bdfsg-2 , https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=ppc64el&package=python-cogent&trigger=python-cogent%2F2
<oSoMoN> 020.2.7a%2Bdfsg-2 and https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=s390x&package=python-cogent&trigger=python-cogent%2F2020.2.7a%2Bdfsg-2 ?
<seb128> oSoMoN, I clicked those
<oSoMoN> thanks!
<oSoMoN> seb128, looks like they're failing again, at least on arm64 (didn't catch the output on other arches and the logs aren't there yet), but one difference with my local run is that I was using all of groovy-proposed, including pytest=4.6.11-1, can you rerun with that additional trigger?
<seb128> oSoMoN, done
<oSoMoN> thanks!
<seb128> np!
<oSoMoN> still failed, bleh
<oSoMoN> seb128, are you looking at the libvorbis autopkgtest failures? if not I'll take it
<oSoMoN> (the fix looks trivial)
<oSoMoN> seb128, I'll take the answer to my first question as a no :) I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963082 and submitted https://salsa.debian.org/multimedia-team/libvorbis/-/merge_requests/1, will share a debdiff for an ubuntu upload in a moment
<ubottu> Debian bug 963082 in src:libvorbis "libvorbis: Autopkgtests depend on pysycache-i18n which was removed from testing and unstable" [Normal,Open]
<oSoMoN> there we go: https://people.canonical.com/~osomon/+1maintenance/libvorbis.debdiff
<oSoMoN> core devs: sponsoring welcome ^
<rbasak> bryce: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/386013 is ready for an initial look please
<rbasak> I expect this will take you quite some time
<bryce> rbasak, ok noted
<rbalint> oSoMoN, thanks, sponsoring libvorbis
<oSoMoN> cheers
<rbalint> oSoMoN, also upstreaming the fix to Debian
<oSoMoN> rbalint, done already
<oSoMoN> https://salsa.debian.org/multimedia-team/libvorbis/-/merge_requests/1
<rbalint> oSoMoN, merging then as well :-)
<oSoMoN> thx
<oSoMoN> gmenuharness was removed in focal (bug #1866434), but is back (and FTBFS) in groovy, IÂ guess it should be removed again? (and how did it manage to creep back in?)
<ubottu> bug 1866434 in gmenuharness (Ubuntu) "Please remove gmenuharness from Ubuntu" [Undecided,Fix released] https://launchpad.net/bugs/1866434
<rbalint> oSoMoN, usually I prefer updating the changelog with gbp dch in a separate commit
<oSoMoN> rbalint, feel free to break that up in two commits (or keep only the functional changes part)
<rbalint> oSoMoN, ok, doing that
<seb128> oSoMoN, sorry i was too slow to reply :)
<oSoMoN> seb128, no worries, it's all handled now
<oSoMoN> do you know what happened with gmenuharness (see my question above)?
<seb128> oSoMoN, no, I don't know, https://launchpad.net/ubuntu/+source/gmenuharness/+publishinghistory is weird
<seb128> it was deleted from focal on 2020-04-01.
<seb128> but on 2020-04-24
<seb128>  Copied from ubuntu focal in Primary Archive for Ubuntu  to G
<seb128> but ye
<seb128> but yeah, it should be removed again I guess
#ubuntu-devel 2020-06-19
<oSoMoN> seb128, now that libvorbis's autopkgtests are fixed, can you please retry http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=libvorbis&trigger=glibc/2.31-0ubuntu10 , http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=arm64&package=libvorbis&trigger=glibc/2.31-0ubuntu10 , http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=armhf&package=libvorbis&trigger=glibc/2.31-0ubuntu10 , http://autopkgtest.ubuntu.com/
<oSoMoN> request.cgi?release=groovy&arch=i386&package=libvorbis&trigger=glibc/2.31-0ubuntu10 and http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=s390x&package=libvorbis&trigger=glibc/2.31-0ubuntu10 ?
<seb128> oSoMoN, done!
<ahasenack> good morning
<ahasenack> rbalint: oSoMoN: morning, fellow +1maintainers
<ahasenack> starting today's shift
<ahasenack> my entries in the wiki page are up-to-date, I expect to land the 64bit aligntment fix of one of those golang packages, and follow up on the integer overflow on armhf on the other, and see if we can apply the golang-go (compiler) patch already to our golang 1.14 groovy package
<oSoMoN> thanks seb128
<oSoMoN> good morning ahasenack
<ahasenack> hello oSoMoN
<rbalint> ahasenack,o/
<ahasenack> hi rbalint
<rbalint> i'm proceeding with r stuff
<ahasenack> rbalint: oSoMoN: I'm looking at yara and golang-golang-x-tools now (yara I'm almost sure the correct trigger will fix it, just tested with s390x)
<teward> rbasak: can you let bryan who's working on the nginx merge know everything looks OK they just have to identify which bits have been included in Debian and alter the changelog for Ubuntu when they do the merge?  I think a lot of changes were incorporated in Debian now so the delta should be smaller now.  Some will still exist though
<rbasak> bryce: ^
<bryce> teward, yep I need to cleanup the changelog and verify autopkgtests but hoping to get through that today
<teward> ð
<teward> awesome.  (Wasn't sure if you were the same bryce i worked with before
<teward> UNRELATED phone autocorrect sucks ass.
<teward> COmputers master race >.>
<bryce> :-)
<teward> rbasak: bryce: thanks again to the Canonical team helping with the merge
<teward> FINALLY made a dent in the work for my job thanks to being *on site* again
<teward> so starting to get back to 'normal' heh
<bryce> teward, using git-ubuntu for splitting out all the history into individual commits helped a lot with organizing the delta.  There's a couple items I need to review where debian did things a tad bit differently than us.
<oSoMoN> ahasenack, rbalint: FYI I'm looking at dh-python, I've identified one commit that fixes one failure (https://salsa.debian.org/python-team/tools/dh-python/-/commit/e289c25c861ae65ae9e7b52ebc09cf1f56061fa7), but there's another failure to address
<ahasenack> fun
<ahasenack> oSoMoN: I'm using the wiki page as my diary basically, striking out things that are done, and will use that content as my report later
<oSoMoN> I tend to prefer offline notes :) but will update the wiki page with any ongoing items when IÂ log off
<oSoMoN> I attached a debdiff that fixes the dh-python autopkgtests to bug #1883297 (https://launchpadlibrarian.net/484997506/dh-python.debdiff), thanks in advance for reviewing/sponsoring
<ubottu> bug 1883297 in dh-python (Ubuntu) "dh-python's autopkg tests fail with python3.8 as the only supported python3 version" [Undecided,In progress] https://launchpad.net/bugs/1883297
<oSoMoN> the autopkgtest queues for arm* are almost empty, at long last \o/
<oSoMoN> IÂ asked yesterday but got no answer:Â could an AA please remove gmenuharness from groovy? it was removed in focal but somehow crept back in
<teward> bryce: right, that's just because of the difference between Debian and Ubuntu.  But a large portion of the deltas (nginx-core being added, ss and iproute2 deps being added, etc.) can probably drop, we'll still have a few but it should be reduced substantially
<bryce> ok
<seb128> oSoMoN, I will do it for gmenuharness yes
<oSoMoN> thanks
<ahasenack> hi, can someone check if this dep8 job is stuck? http://autopkgtest.ubuntu.com/running#pkg-dropbear
<ahasenack> the details show it's been running for just 7min, but since 2020-06-16
<ahasenack> or am I reading that incorrectly, and that's when the job was requested
<rbalint> please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/386127 for the r transition
<xnox> doko:  i think i was one of the people who said "we will never need libc6-armel:armhf just drop it" well, here i am, using it.
<xnox> so thank you for keeping it
<sarnold> xnox: between that and my saucy hung task bug report, you sound like you're in a rough spot..
#ubuntu-devel 2020-06-20
<xnox> hahahhahahhaha
<nanthencodeneeth> echo "Subject: sendmail test" | sendmail -v smidhunraj@gmail.comsmidhunraj@gmail.com... Connecting to [127.0.0.1] via relay...smidhunraj@gmail.com... Deferred: Connection refused by [127.0.0.1]
