#ubuntu-devel 2005-01-10
<lamont> daniels: heh
<_nexus_> qualche italiano?
<_nexus_> ERROR[ogle_nav] : faild to open/read the DVD <_nexus_> callbacks.on_opendvd_activate(): DVDSetDVDRoot: Root not set
<Kamion> #ubuntu, unless you have a patch :-)
<_nexus_> ?
<_nexus_> io devo settare il dvd in dvdroot come il comando?
<lamont> daniels: it almost looks like (from debian/rules) that the minimum requirement is met with simply 'mv MANIFEST.hppa.new MANIFEST.hppa.in', yes>
<lamont> >
<lamont> ?
<lamont> well, minus fonts
<daniels> lamont: modulo anything in MANIFEST.all.in, yeah
<lamont> grep -F MANIFEST.all MANIFEST.hppa.new > zz && mv zz MANIFEST.hppa.in
<daniels> yeah
<lamont> interesting... that makes an empty file... :(
<daniels> oh
<lamont> grep -Fv -f MANIFEST.all MANIFEST.hppa.new > zz
<lamont> much better.
<daniels> grep -F -v -f ... yeah
<lamont> daniels: any current plans for a ubuntu9 version once you're back?
<daniels> lamont: yeah, fo'sho.  fixing glx module loading, tweaking the way we create xc-xserver-xorg-dbg.
<daniels> couple of other minor fixes.
<lamont> daniels: OK.  I'll just toss you a new MANIFEST.hppa.in then.
<lamont> since it certainly doesn't warrant _2_ xorg uploads. :-)
<daniels> lamont: heh, cool :)
<daniels> lamont: yeah, I'll probably do it on the 4th
<bluefoxicy> uh
<bluefoxicy> Martin Pitt
<bluefoxicy> I need to talk to him
<mdz> bluefoxicy: = pitti
<bluefoxicy> ok
<bluefoxicy> trulux said he's been talking to him
<bluefoxicy> so I want to see what's going on :)
<bluefoxicy> mdz:  should I e-mail him or wait for him to come on
<Kamion> it's kind of holiday season at the moment
<bluefoxicy> so e-mail would be rude then?
<daniels> bluefoxicy: if it's not urgent, try email.
<daniels> no, not at all
<bluefoxicy> it's not urgent but I dn't want to bother his holiday :)
<mdz> and even during more normal working time, he's not generally around until about 0800 UTC
<Kamion> wasn't referring to e-mail, just telling you not to expect him around necessarily any time soon
<daniels> thom: please make mutt on amnesiac stop segfaulting ;)
<bluefoxicy> ok
<daniels> thom: (~daniel/core, if you're interested)
<bluefoxicy> so I'll e-mail then  :)
<lamont> daniels: ubuntu8.1 build scheduled, I expect it'll work - but it is behind a gcc-3.3 build, so that just means it'll be a few hours before it's actually done.
<daniels> lamont: sure, that's fine.
<lamont> daniels: before dying in MANIFEST check, Build needed 02:58:19, 3106716k disk space
<daniels> that's not too bad
<daniels> of course, it's no concordia (32min)
<daniels> hey, I'm sure someone said 'San Andreas'
* daniels migrates downstairs.
<Kamion> San Andreas?
<daniels> Kamion: GTA: San Andreas
<daniels> the only game where you get to hear 'I THO' YO' WAS REPRESENNIN'
<Kamion> aha
<daniels> it's *way* too much fun, and totally worth having bought a PS2 for :)
<Kamion> suits you down to the ground then :)
<daniels> of course
<daniels> young black American from tha ghetto
<daniels> they picked their demographic fo'sho
<mdz> anyone else getting loads of old mail via Ubuntu lists?
<daniels> mdz: jdub presumably just did moderation
<daniels> mdz: (yes)
<ogra> mako is moderating ;)
<daniels> Kamion: you can also dress them, get haircuts, and buy bling!
<Kamion> sort of Barbie for the 2000s
<daniels> my homie has some dogtags
<ogra> Kamion: LOL
<lamont> daniels: I think I have my dad's dogtags around here somewhere.
* Kamion wanders off for a whisky and a book
<mdz> mako: http://err.no/pictures/2004-12-Mataro/thumbnail/dsc00372.jpg
<daniels> mdz: dude, http://photos.jonmasters.org/albums/canonical_conference_mataro_2004/dscn4515.thumb.jpg
<daniels> or, even better, http://photos.jonmasters.org/canonical_conference_mataro_2004/dscn4515
<daniels> that is *frightening*.
<mdz> that's nothing
<mdz> http://err.no/pictures/2004-12-Mataro/slides/dsc00337.html
<bluefoxicy> when is Hoary scheduled?
<mdz> bluefoxicy: http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule
<bluefoxicy> damn
<bluefoxicy> february feature freeze will mean no more exploration of SSP
<bluefoxicy> guess that rules out trying to push for getting anything trulux has done into Hoary
<Kamion> one of the great benefits of a six-monthly release cycle is that you don't have to do the dysfunctional thing of trying to push absolutely everything for the current release
<Kamion> (dysfunctional because the behaviour tends to push releases back and make them less stable)
<bluefoxicy> Kamion:  I don't know if trulux has SSP completely ready so that package regression can be searched for yet
<bluefoxicy> if you compile a package with SSP, and it has an internally triggered buffer overflow, it will break
<Kamion> sounds like an excellent reason to target hoary+1 ;)
<Kamion> (the former)
<bluefoxicy> I don't think you could build and test every package in Ubuntu's core (not in Universe) by February
<bluefoxicy> then again, maybe I'm using odd values for "test"
<bluefoxicy> although, would that type of breakage really preclude SSP from being used?  It's basically SSP exposing existing bugs . . .
* bluefoxicy shrugs
<Kamion> there are plenty of programs where you wouldn't care
<Kamion> I'm all for exposing bugs in server processes, but that's a limited subset
<Kamion> I'm also all for not pissing users off about one-byte overflows in programs where it doesn't really matter :)
<Kamion> either way, rushing into something this complex doesn't sound like a good plan; I prefer the "careful consideration" approach
<bluefoxicy> Kamion: it's not complex is it?
<bluefoxicy> Kamion:  and what about overflows in mozilla?
<bluefoxicy> one bad .png file and you're suddenly dealing with the FBI coming to your door to examine your worm-based child porn trafficing activities.
<bluefoxicy> Kamion:  also, a lot of attacks are local privilege elevation
<bluefoxicy> if an attacker can't exploit Mozilla, he can't get local access, thus he can't use a local exploit to freeze the machine (floating point register corruption) or get root access
<mako> mdz: i look slightly insane in that picture
<ogra> mako: but ubercool in this one (february-calendar) http://www.grawert.net/mataro/img100.jpeg
<mako> ogra: that one is great :)
<bluefoxicy> btw
<bluefoxicy> what's a hedgehog?
<ogra> http://www.glaquarium.org/scans2/hedgehog.jpg
<mdz> dict hedgehog
<ogra> bluefoxicy: google picture search is your friend
<bluefoxicy> that doesn't look like the image of the warthog that Ubuntu had up on the amin page for a while
<bluefoxicy> but it's cute.
<mdz> a warthog and a hedgehog are different animals
<Kamion> bluefoxicy: dude, relax, I'm not having a go at the value of it in general, merely saying that rushing into a change that will make programs crash when they would previously have worked (not all buffer overflows are fatal or security exposures, remember) is unwise.
<Kamion> mozilla is obviously a network client and therefore on a security boundary
<Kamion> same as server processes
<Kamion> not everything is on a security boundary
<bluefoxicy> heh
<bluefoxicy> Kamion:  all libraries are on a security boundary by default though
<Kamion> the most important thing about security engineering is knowing where the boundaries are ...
<bluefoxicy> unless YOU want to trace and catalogue every network-side program and every library they call, and every plug-in they can use that calls other libraries :)
<bluefoxicy> but yeah
<bluefoxicy> I don't want to rush
<Kamion> let's take non-networked games; they're rarely on a security boundary, and they're often poorly written
<Kamion> but it doesn't really matter if they overflow an array here or there
<daniels> *very* poorly written.
<bluefoxicy> right
<bluefoxicy> non-networked games we don't care about
<bluefoxicy> Kamion:  but in cases where you don't expose bugs, the protection is pretty much harmless
<Kamion> and if they start crashing on Ubuntu when they don't crash on other distributions, I know who users are going to blame, and it won't be the game authors
<bluefoxicy> so it becomes that it's not really worth the effort to decide which packages don't need the protection
<Kamion> so I feel quite strongly that the change ought to be made only selectively
<bluefoxicy> because it's visible when they break things (you NEED to test when you build a package)
<Kamion> I disagree
<bluefoxicy> howso?
<Kamion> I've already explained
<Kamion> I'm not going to do so twice :)
<bluefoxicy> I already poked the gentoo-dev mailing list with this question once
<bluefoxicy> and they couldn't decide where was and was not appropriate
<daniels> just because it's a hard question doesn't mean it shouldn't be asked
<bluefoxicy> it's hard to make a policy for this stuff :)
<Kamion> many things are hard
<bluefoxicy> daniels:  well, it becomes a hard question with certain answers
<bluefoxicy> I run a fully stack smash protected base here. . .
<Kamion> finding a sane middle ground between security engineering and release management is hard
<bluefoxicy> gimme a minute
<Kamion> doesn't mean it shouldn't be done
<bluefoxicy> I'll count how much stuff ejects stack smash protection thatI have installed
<Kamion> I'm not convinced that's relevant
<Kamion> you're a security type, therefore it's a skewed sample :)
<crimsun> we all agree that it's relevant for hoary+1, correct?
<daniels> (anyone on #u-d will skew a sample)
<sivang> Kamion: hello, I am interested to know if you could provide d-i sources that support installing using a preset language, that is for example, a d-i which would install ubuntu using the hebrew translation of d-i, and would then pull a deb package which would set all the needed fonts and set up hebrew input in GNOME Kbd Selector. is this possible?
<crimsun> (because there's not much sense in pushing it in now)
<bluefoxicy> Kamion:  I don't control what has and does not have SSP disabled
<Kamion> sivang: preseed the language choices in your bootloader configuration
<Kamion> as for the rest we haven't got the infrastructure for that yet, hopefully we will have soon with language packs
<Kamion> crimsun: it seems fairly clear to me it should happen at the beginning of a release cycle, same way X.Org did
<bluefoxicy> Kamion:  but the point of the check is that if there are, say, 10 packages in the world that break, and 100,000 packages total, and 70% of them are security boundaries, you have 30,000 packages to dredge through when only 10 really matter.
<daniels> there will be a lot more than 10
<daniels> you're a factor of ~100 off
<bluefoxicy> daniels:  yeah
<bluefoxicy> I know there's going to be a lot more than 10
<Kamion> so why choose an exaggerated example? :)
<bluefoxicy> but it's not that significant that it should be selectively applied rather than selectively removed, I believe.
<sivang> Kamion: some folks over the huji have set up to create a localized hebrew distro, now I told them we should probably wait when we have the infrastructure available. How would you suggest going on with this?
<sivang> Kamion: huji = Hebrew University Of Jerusalem
<Kamion> bluefoxicy: I don't believe I was necessarily arguing for either selective application or selective removal; merely selection ...
<bluefoxicy> Kamion: it gets the point accross better while letting me get away without having to explain that the example is hypothetical?  :)
<bluefoxicy> Kamion:  heh
<Kamion> sivang: I don't really have an answer for you as yet, sorry, I hope I will have in a while
<Kamion> it's an important issue but the work just hasn't been done yet
<Kamion> most of it is targetted at hoary though
<bluefoxicy> Kamion:  RedHat selectively applies things.  When they started out, they had 100% of everything wide open with an executable stack and heap.  Now there's something like 1-5% of packages (estimate) that have an executable stack but don't need it
<bluefoxicy> wihch means there's a hole in their policy at those points
<Kamion> like I say, you're arguing against a strawman; I didn't say we wanted selective application
<bluefoxicy> not a problem right now, but it's a potential place for you to start looking if you want ot hijack an RHEL server.
<bluefoxicy> heh
<bluefoxicy> Kamion:  and i never said I wanted to leave broken things to break
<bluefoxicy> <bluefoxicy> Kamion:  I don't know if trulux has SSP completely ready so that package regression can be searched for yet
<bluefoxicy> <bluefoxicy> if you compile a package with SSP, and it has an internally triggered buffer overflow, it will break
<Kamion> however, it will easily take a full release cycle to determine what the things that users care about are that break, and whether fixing them or disabling SSP for them is appropriate
<bluefoxicy> SEarching for regressions implies that somebody has to do something about them.  You have two choices:  Remove the protections, or fix the bugs.  I didn't specify which, and I don't expect you to suddenly become code janitors  :)
<bluefoxicy> eh
<Kamion> we're coming up to our second release, and that's a fairly critical time as regards community confidence
<Kamion> if the second release is a "let's break the world" release, people are just going to shrug and go find something else
<Kamion> so, caution is advised :)
<bluefoxicy> Kamion:  disabling SSP for breaking things if you're crunched for time is acceptable, since you in the worst case wind up back where you started, and in the best case wind up with at least some protection
<Kamion> indeed so
<bluefoxicy> and I never implied that I wanted a broken release
<Kamion> right, the only reason I said anything was that you sounded annoyed about the date of the feature freeze :)
<bluefoxicy> if there's simply not enough time to definitely say that SSP can be supplied in SOMETHING without breaking ANYTHING, then it doesn't go in.  Same with anything else :)
<Kamion> people with an interest in release management tend to have hot buttons about this kind of thing ...
<bluefoxicy> Kamion:  yes, because that means there's little time for testing, and I don't know if the testing would need to show acceptable results before or after the freeze (if it's defferred to after the freeze, it means that at freeze time we don't know if it's going in or not)
<bluefoxicy> heh
<bluefoxicy> I actually didn't mean to discuss this here and now you know :)
<Kamion> fair enough :)
<Kamion> (apologies for going off on one :-))
<bluefoxicy> it's ok
<bluefoxicy> I like talking :P
<bluefoxicy> just not wasting everyone's time with excess channel noise.
<bluefoxicy> Kamion:  i think having added security in release 2 would be impressive though
<bluefoxicy> but that's not my motivation.
<bluefoxicy> if these things go in successfully, it will bring attention to their viability in default installs, which means others will mimic that behavior and increase the general security of their own operating environments :)
<Kamion> we're adding a scary amount of stuff in release 2 ... :)
<bluefoxicy> that's good :)
<bluefoxicy> it's called progress
<Kamion> back in the early planning stages for warty, we used "hoary" as a notional dumping-ground for everything future
<Kamion> we've been trimming the list down ever since ...
<bluefoxicy> have you seen my analysis of the USNs?  It's just statistics (I'm not yet scholarly involved in security; it's hobbyist level for me)
<bluefoxicy> but it shows what could have been controlled :)
<Kamion> like I say, I don't dispute the value. :)
<bluefoxicy> either way it's an interesting read :)
<Kamion> WRT adding security in release two, note that we're adding authenticated package retrieval, which is a major headline security feature in itself
<bluefoxicy> gpg signatures?
<Kamion> yeah
<bluefoxicy> cool.
<sivang> bluefoxicy: where can I read about those?
<bluefoxicy> sivang:  https://www.ubuntulinux.org/wiki/USNAnalysis
<bluefoxicy> I pointed out that the last bit left over is going to be at best containable with a MAC system, though this is not a full solution; kernel exploits I imagine would be able to get past SELinux in some cases, and then there's local attacks that may not rely on whatever the MAC restricts.
<bluefoxicy> still those are special cases
<Kamion> the grub password thing is interesting, although somebody else gets to argue with Mark about the extra question in the installer; I've done my share of arguments like that :)
<bluefoxicy> uh
<ogra> hmm, you loose the edit ....
<bluefoxicy> those kinds of protections are probably better for server environments, though your kids at home might be smart enough to init/
<bluefoxicy> those kinds of protections are probably better for server environments, though your kids at home might be smart enough to init=/bin/sh
<bluefoxicy> or stuff
<ogra> which is a big advantage in grub over lilo
<ogra> or knoppix.....
<Kamion> sadly grub doesn't work in all environments
<ogra> its still young
<bluefoxicy> then again, you know, if the home user isn't able to handle a password getting in their way, they're probably not going to need the functionality that entering the password gives in the first place.
<sivang> young but _very_ promising.
<ogra> yep...but still....
* ogra loved milo
<ogra> or rather the arch it ran on
<Kamion> bluefoxicy: chances are we'd only ask if they opted to turn on selinux
<bluefoxicy> yeah
<bluefoxicy> Dan's Guardian should be looked at for the child safety thing.
<bluefoxicy> https://www.ubuntulinux.org/wiki/IdeaPool
<bluefoxicy> You can hijack certain users' connections and force them through a squid that uses Dan's Guardian as a parent
<daniels> 'You down to represent, baby?'
<daniels> elmo: GTA:SA.
<srbaker> yo
<fabbione> morning guys
<crimsun> re
<fabbione> ubuntu/pool/universe/l/linux-source-2.6.10
<fabbione> does anybody spot something SLIGHTLY wrong with it?
<crimsun> looks ok to me. I see reiserfs EA made it in.
<fabbione> crimsun: yeah i did put them in..
<fabbione> but that's not the problem
<fabbione> the kernel landed in universe
<fabbione> while it should be in main
<crimsun> I was wondering about that
<mdz> night
<fabbione> night mdz
<fabbione> mjg59: [   ]  linux-source-2.6.10_2.6.10-1_20041230-0427-i386-successful    
<fabbione> this was 4 minutes ago
<Treenaks> zenrox: please make up your mind :)
<zenrox> sorry hoary has it probs when a progam breaks and the only way to fix it is reboot
<Treenaks> zenrox: that's only if the kernel breaks
<crimsun> just remove #ubuntu* from your autojoin channel list ;)
<zenrox> i tride 3 dif ways to kill gnome
<zenrox> and that dont work
<zenrox> then frezes gdm
<Treenaks> zenrox: go to the console, whip out ps aux | less and kill -9 along ;)
<zenrox> i did dint help
<Treenaks> strange
<Mithrandir> pitpong
<Mithrandir> hm, no pitti
<mvo> Mithrandir: he's on vacation 
<Mithrandir> he pinged me yesterday or the day before.
<mvo> he worked one (or two?) days to keep up with all the security stuff that pilled around christmas 
<fabbione> hey Mithrandir 
<fabbione> Mithrandir: i think it is something to do with mailman
<fabbione> Mithrandir
<fabbione> do you still host planet.d.n?
<HcE> fabbione: you mean planet.s.n, if yes, it's a yes
<fabbione> .s.n?
<HcE> maybe the d is just yet another alias
<HcE> samfundet
<fabbione> debian.net ?
<fabbione> or .org..
<HcE> hihi
<HcE> he got a machine at Samfundet with a name planet too
<fabbione> planet.samfundet.net doesn't resolv
<HcE> planet.samfundet.no resolves
<HcE> totally different machine
<HcE> I always presume .n == .no
<HcE> and s is close to d
<Mithrandir> fabbione: no, planet.d.n is on gluck.
<Treenaks> sid's Sources.gz is 1337 Kb today...
<garnacho> mvo: ping?
<abelli> garnacho: what's up
<garnacho> hey abelli :)
<garnacho> howdy?
<abelli> ...de puta madre
<abelli> any news on mini-gnome?
<jordi> Treenaks: hah
<garnacho> abelli: only that I have to get some time to finish the list... all my vacation days went to the conference, and there is missing stuff I wanted to add to gst before the gnome feature freeze... :/
<Treenaks> jordi: so today, Debian's sources are 1337.. beat that, Gentoo! :P
<jordi> nothing can
<abelli> garnacho: take your time.
<abelli> sup Treenaks 
<Treenaks> abelli: yo!
<garnacho> abelli: thanks :)
<elmo> jesus christ, 2.6.10 for all 4 arches is nearly half a Gb
<Treenaks> g'morning Elmo :)
<elmo> morning Treenaks
<Treenaks> elmo: you should've seen fabbione... 2.6.10-almostvanilla FTBFS on 5 out of 5 arches
<lifeless> Treenaks: woohoo good score :)
<mjt> what are the problems with 2.6.10?
<mvo> hi carlos
<carlos> mvo: hi
<abelli> ciao carlos
<carlos> hi
<siretart> anyone using pbuilder on hoary? I'm having trouble to build packages because "WARNING: packages cannot be authenticated". Is there a solution to that?
<mvo> siretart: you can use the "--allow-unauthenticated" switch in apt
<mvo> this is equivalent to setting: "APT::Get::AllowUnauthenticated=true" in your apt.conf
<siretart> hm new to bpuilder, and I dont see a config options for that. gotta search..
<mvo> siretart: I copied my /etc/apt dir to /etc/pbuilder/apt.config, added the APT::Get::AllowUnauthenticated=true to /etc/pbuilder/apt.confif/apt.conf.d/50allow-unauth and set APTCONFDIR=/etc/pbuilder/apt.config (in /etc/pbuilderrc)
<siretart> ah, thank you very much
<siretart> I'm trying to recompile evolution, because dependencies in hoary seems to be broken atm
<mvo> siretart: really? seems to be ok here on my hoary ...
<mvo> what kind of error message do you see?
<siretart> evolution depends on libegroupwise1.2-0 (>= 1.1.1) which is unavailable
<siretart> I find only libegroupwise1.2-1
<siretart> mvo__: you where right, I was wrong, evolution is installable. aptitude was doing very weird things with my pinning config
<mvo__> siretart: good to hear that it works for you again
<siretart> mvo__: well, the actual problem still exists: evolution from hoary segfaults at start in my system. I'm still trying to find out why
<fabbione> jeee i crashed
<fabbione> i feel really really bad
<fabbione> elmo: did you sync it from germinate (universe -> main)?
<elmo> fabbione: not yet, still catching up on seed changes from the last week
<fabbione> ok
<fabbione> no rush :-)
<fabbione> mvo: updrade-notifier is FTBFS
<mvo> fabbione: shit
<fabbione> (0.37-1) missing build-dep
* mvo checks build-logs
<fabbione> hecking for gtk+-2.0 libgnomeui-2.0 libglade-2.0 gconf-2.0 gamin hal dbus-glib-1... Package dbus-glib-1 was not found in the pkg-config search path.
<fabbione> Perhaps you should add the directory containing `dbus-glib-1.pc'
<fabbione> to the PKG_CONFIG_PATH environment variable
<mvo> hm ... I was sure I added it :/
<mvo> thanks for pointing this out
<fabbione> np
<abelli> sorry but i cant download universe's headers
<Kinnison> bahnoseb
<garnacho> mvo: ping?
<mvo> garnacho: pong
<garnacho> hi mvo :)
<garnacho> remember we talked about adding isdn support to gst?
<mvo> hi carolos 
<mvo> oh yes
<mvo> I send you a mail about some ideas 
<mvo> I hope it made it to you?
<garnacho> hmmm, no :/
<garnacho> where did you send it?
<mvo> I can resend it. i had some trouble with my isp recently :/
<garnacho> please resend :)
<mvo> send it to garparr@teleline.es
<mvo> is this the wrong one? 
<garnacho> ouch, that address is quite old... try carlosg@gnome.org
<garnacho> (I should that address from everywhere...)
<mvo> resend
<mvo> thanks!
<garnacho> thanks to you
<garnacho> mvo: I began implementing some isdn support in gst, but I've got some doubts
<mvo> what exactly troubles you?
<garnacho> 1) do ippp interfaces show in ifconfig even when disconected (unlike ppp ones)
<garnacho> and 2) the url you sent me has a bit unsecure method for password, does isdn support pap/chap?
<garnacho> or am I forced to put it in the ppp options file?
<mvo> it supports pap/chap 
<garnacho> cool, it's easier then, gst already supports this :)
<mvo> about 1) i don't know, but with the capi based isdn support we really shouldn't need ipppd anymore. the stock pppd with the appropriate plugin should do
<mvo> garnacho: most of the stuff needed for capi based isdn seems to be supported already :)
* lamont looks around for daniels
<garnacho> mvo: hmmm, but there has to be an interface name, regardless of using ipppd, right?
<mvo> garnacho: I'm not sure if I understand you but the interface name should be just ppp0 and it should behave like a normal ppp device from the systems point of view
<garnacho> mvo: ok... so I'll have to find a way to distinguish between plain ppp interfaces and isdn ones :)
<garnacho> mvo: but the rest is easy, and some work is already done
<mvo> garnacho: what about checking for pppdplugin.so in existing one and /proc/capi/controller for new ones?
<mvo> (just a idea)
<mjg59> If someone could shove http://www.srcf.ucam.org/~mjg59/vbetool into Hoary, that would be great
<garnacho> mvo: makes sense :)
<zul> mjg59: what is it?
<mjg59> zul: Lets you run various bits of video BIOS code
<zul> cool
<mjg59> Handy for ACPI
<mvo> garnacho: cool! I owe you (at least) one beer on the next conference :)
<garnacho> :P, who could refuse a beer? :)
<srbaker> mjg59, what's vbetool?
<mvo> garnacho: tell me once there is something for me to test (I assume you don't have isdn yourself :)
<garnacho> mvo: cool! you're right :)
* garnacho feels better coding things that can actually test...
* mvo too
<sivang> garnacho: we should maybe have a logger on #gst, so you could chat there and it would then reach all people who are involved in gst?
<sivang> garnacho: :-)
<mvo> where can I find the #gst channel?
<garnacho> mvo: in irc.gnome.org
<garnacho> sivang: not a bad idea...
<mjg59> srbaker: <mjg59> zul: Lets you run various bits of video BIOS code
<mvo> mjg59: I can upload it for hoary
<srbaker> ahh
<srbaker> cool
<srbaker> oh, put ruby in main.
<srbaker> because ruby is kick ass
<mjg59> mvo: Rock, thanks
<mjg59> Then we can sort out the userspace acpi stuff
* lamont hugs ccache.  xorg now takes only 1:11 to fail instead of 2:58 :-)
<srbaker> haha
<srbaker> lamont, you should work for microsoft.
<srbaker> lamont, things break faster now!
<lamont> srbaker: trying to build xorg on hppa.
<lamont> not because I want to use X on hppa, but because everything and it's mother build-depends something from x
<lamont> off for more vacation fun today
<mdz> Kamion: I very much like the idea of being able to tell someone who has messed up their package selections "install ubuntu-base and ubuntu-desktop" and have that make things OK
<Kamion> the question is deciding what "messed up" means
<mdz> yes
<mdz> my general feeling is that it should bring them back to what we chose for them
<Kamion> given that part of the idea of the MDA-only thing was to make it easier for server admins to install postfix without having to figure out how to uncripple it, I feel that that ought to be an exception
<mdz> but it's clear that the current approach is less than ideal for many users
<mdz> we could introduce Recommends
<mdz> that seems fairly close to the semantics we want
<mdz> "install this per default, but if the user wants to change it, that's OK"
<Kamion> Depends: mail-transport-agent; Recommends: mda-only?
<Kamion> (or postfix, currently)
* Kamion wonders what the tools will do with that
<mdz> I was thinking Recommends: postfix
<mdz> (and no Depends)
<mjg59> Argh.
<mjg59> Module paramaters are broken in the kernel's ibm-acpi module
<Treenaks> WTF? Evo now depends on mozilla-psm which depends on mozilla-browser?
<Treenaks> (if you want SSL)
<mjg59> Arse. intelfb only works on LCDs if the video mode is set at boot time
* Treenaks kills the Evolution devs
<mvo> what do I have to kill if my gnome hangs on futex() on login? 
<sladen> mvo: try  ctrl+alt+backspace
<mvo> sladen: that brings me back to gdm and when i try to login in again it hangs 
<Keybuk> login on console, kill -TERM -1
<Keybuk> that usually fixes it
<Keybuk> generally a wedges gnome-something-or-other
<Keybuk> "iz gtk bug"
<seb128> on login ? details ?
<seb128> the panel and nautilus ? or on the splash screen ?
<Treenaks> seb128: panels + nautilus. still.
<Treenaks> seb128: and kill evolution upstream for me, please.
<Treenaks> seb128: slowly, and painfully
<seb128> the depends have not changed in evo
<Treenaks> seb128: then SSL just Broke
<seb128> and the freeze question was for mvo who has the problem
<mvo> seb128: panel is visible (and some applets) but nothing else and no mouse/keys work
<seb128> not a GNOME pb if you don't even get events
<seb128> probably xfree or kernel
<seb128> you should at least get a pointer and move it
<mvo> I have a pointer, sorry for not telling you. and click on the available applets (weather applet) work
<mvo> if I strace e.g. nautilus it hangs on "futex()"
<seb128> ok
<mvo> any idea :) ?
<seb128> killall gnome-panel nautilus gnome-vfs-daemon trashapplet
<seb128> and drive... (don't remember the exact name) too if you use the drive applet
<seb128> that's #4794
<seb128> if you can get details ...
<mvo> works again, nice :)
<seb128> I thought it was due to the hal support, but it's turned off now 
<mvo> thanks seb128 
<seb128> np
<mdz> mvo: https://bugzilla.ubuntu.com/show_bug.cgi?id=4794 ?
<mdz> ah, seb already pointed you to it
<mvo> yes, thanks
<_rene_> mvo: btw, sorry, no idea wrt that bug. maybe firestarter started doing something stupid with network (loopback etc.)?
<_rene_> mvo: (I don't use and maintain it anymore, so I don't really know and care ;) )
<mvo> _rene_: thanks anyway :)
<abelli> plovs: your needed in ubuntu-doc..
<elmo> mjg59: vbetool definitely i386 only?  just looking to P-a-s it
<Kamion> note to self: when replacing an initrd in a CD image, try actually changing it
<mjg59> elmo: Yup
<mjg59> elmo: It uses vm86
<calc> anyone know why linux-image-amd64-k8 wasn't updated to depend on 2.6.10 when it was uploaded?
<Kamion> calc: because 2.6.10 isn't our default kernel yet, it's experimental
<calc> ah ok
<calc> that would be a very good reason :)
<Kamion> linux-meta will get switched over en masse when 2.6.10 is in better shape
<elmo> mjg59: k
<Kamion> OK, who can take a language that build-depends on _emacs21_ seriously?! ;)
<zul> nothing wrong with that os
<zul> er...editor
<ogra> Kamion: lisp ?
<Josephus> prolog?
<Kamion> ogra: python
<ogra> ugh 8-O
<sivang> zul: well, emacs is a computing paltform by now..:)
<lifeless> Kamion: what language build-deps on emacs ?
<Kamion> lifeless: python
<lifeless> garh
<janc> which python do you use ?  :-p
<Kamion> the python2.4 source package, in this case
<janc> that's something debian-specific or what ?
<Kamion> no, grep emacs Doc/Makefile
<Kamion> lots of stuff under Doc
<janc> ah, the LaTeX-based documentation stuff probably  :-/
<Kamion> info files
<janc> python documentation source is in a special LaTeX-based format
<daniels> mjg59: so, how's videopost coming along? :)
<calc> hahaha
<calc> so does that make emacs required now? ;)
<Kamion> *build*-dep ...
<calc> oh i forgot build-dep doesn't have to be inclusive
<janc> you only need it to build the documentation...
<calc> i guess it typically because things you build-dep on you end up depending on as well, except in doc building case
<janc> most programs build-dep on gcc or similar, but they don't need it to run  ;-)
<Keybuk> actually, most programs don't build-dep on gcc as it's build-essential </pedant> :p
#ubuntu-devel 2005-01-11
<Kamion> Keybuk: s/pedant/build-essential-maint/
<mjg59> Kamion: Damn you for getting back before me
<Keybuk> *sigh* weather applet has gone into a cyclone of hate
<Kamion> mjg59: and I even had time for a glass of orange juice to absorb the BEER
<Kamion> and it just took me three goes to type "absorb"
<Keybuk> drunk :o)
<daniels> Kamion: the orange juice didn't contain vodka, did it?
<daniels> that can certainly negatively impact your ability to type 'absorb'
<Keybuk> mmm... vodka
* daniels hugs duty-free.
<Keybuk> heh, alright for some.  none for us from Spain
<Kamion> daniels: negatively impact your ability to absorb, for that matter
<daniels> Kamion: (how many goes?)
<Kamion> just the one that time
* Kamion fondly remembers a friend of his claiming that she "wasn't very bosber right now" on IRC
<daniels> Kamion: i'll smack you if hoary-changes (amusingly, I typoed both 'changes' and 'typoed', quite badly [and 'badly'] ), I'll smack you
<daniels> er
<daniels> that sentence reads like it's I that's just come back from the pub.  so let's just pretend this never happened, I'll go back to GTA:SA, and we can all move on. :)
<Kamion> was there going to be a point to that sentence? :)
<daniels> Kamion: if hoary-changes lights up with your name, I'll smack you ;)
<Kamion> ah
<daniels> public service
<daniels> that was the point I was lamely attempting to convey
<Kamion> fortunately I uploaded python2.4 before leaving for the pub
<daniels> heh
<Kamion> no, I'm just surreptitiously poking at cdimage behind the scenes. that can do no harm at all, can it? :)
<Kamion> little things like the cdimage signing key
<daniels> heh
<daniels> at least elmo will know where to look ;)
<Keybuk> it's when he starts fiddling with germinate you have to worry
<Kamion> Keybuk: yeah, only FREAKS work on germinate
<Kamion> basic regular expressions suck. no '+'?!
<Kamion> (not surprised, just discover new dimensions of hate every time I run into that lack-of-feature)
<daniels> the kamion cyclone of hate
<Kamion> beer-powered cyclone
* Keybuk teaches Kamion about "egrep"
<Kamion> unfortunately it's sed, and busybox sed doesn't have -r
<Keybuk> aww
<davyd> bug report for the latest installer image
<davyd> you are depending on the python module UserDict
<davyd> which you don't have
<Kamion> davyd: fixed earlier today
<davyd> Kamion: are the CD images rsyncable ?
<Kamion> yes
<davyd> excellent, is there an appropriate URL ?
<Kamion> there isn't a new CD image with that fix yet though, wait 9 hours or so
<davyd> aah right
<davyd> I'm already going to not have a working system when I go to work... ;)
<Kamion> rsync://cdimage.ubuntulinux.org/cdimage/daily/current/
<davyd> the fix, it's quick and nasty, is to netcat it off another Ubuntu machine
<davyd> or I guess python installation in general
<Kamion> I just moved UserDict into python2.4-minimal, that's the correct fix
<davyd> Kamion: doesn't help if all you have is a bad CD image though ;)
<Kamion> since os.py depends on it
<Kamion> shouldn't use dailies if you need something that works :)
<davyd> Kamion: I know that, but it seemed like the fastest way to get Hoary
<Kamion> that's what the Array CD series is for
<davyd> array series?
<Kamion> the installer in the dailies might be arbitrarily broken
<Kamion> search for "Subject: Array CD 2" in ubuntu-users
<Kamion> hm, I can roll a new CD image now if it'd help, but it'll take an hour or so
<davyd> nah, I got it installed
<Kamion> ok
<davyd> like I said, I copied the module across via netcat
<Kamion> heh. could also have extracted it from python2.4_*.deb, which is on the CD
<davyd> Kamion: yeah, I had wondered about that, but I just wasn't sure of the specifics
<davyd> why is it done with a minimal and the real thing?
<Kamion> or indeed an easier fix, 'nano /usr/lib/debootstrap/scripts/hoary' and add 'python python2.4 libbz2-1.0 libdb4.2 libssl0.9.7' to the end of the required= line
<Kamion> because we have a goal for hoary to put python into Essential, i.e. the minimal set of stuff required for the packaging system to work
<davyd> also, there really needs to be a simple netinst CD that will suck all these packages off the net for me, is there any chance of ever seeing one?
<davyd> Kamion: aah, I see
<Kamion> there's a netboot image
<davyd> I couldn't find it, so maybe it's nicely hidden
<Kamion> yep
<Kamion> http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/current/images/netboot/mini.iso
<davyd> not just a little hidden, really very hidden ;)
<Kamion> not hugely keen on advertising it too widely at the moment because it isn't well-tested, and particularly in the development branch it's very fragile
<davyd> Kamion: *nod*
<Kamion> but you're right, we should probably advertise it more widely for the hoary release
<Kamion> not to mention making it work better
<davyd> oh well, hopefully I can at least rsync my home directory back onto this machine before I have to go to work
<davyd> then I can finish setting it up at work ;)
<davyd> that's not pretty
<davyd> filesystem type unknown 0x7
<davyd> hmm, grub had decided that all partitions were on /dev/hda1
<Kamion> you may need to do this in /boot/grub/menu.lst:
<Kamion> map (hd0) (hd1)
<Kamion> map (hd1) (hd0)
<Kamion> (in the Windows chainloader section)
<Kamion> I'd make that happen automatically if I had a clue how to detect the systems where it's needed
<Keybuk> isn't it needed wherever Windows is on a different drive?
<Kamion> non-hda/sda you mean? how do you tell which of IDE and SCSI is first if both are present?
<tseng> only if windows isnt on the first master drive
<davyd> also, why does it want to run aptitude?
<romspaceni> is unbutu like debian?
<Kamion> davyd: the full aptitude UI? probably because the ubuntu-desktop task was uninstallable in the image you downloaded
<davyd> Kamion: nice
<Kamion> which http://cdimage.ubuntu.com/daily/current/report.html would tend to support
<davyd> can I installed it and get it to finish the config process?
<Kamion> yes, go down to tasks, drill down 'til you see ubuntu-desktop, install that, ignore broken stuff
<Keybuk> yeah, current hoary is uninstallable
<Keybuk> elmo sucks and hasn't processed NEW
<Kamion> romspaceni: "Ubuntu"; in many ways yes, in some ways not, depends what you're asking about :)
* davyd sighs
<Kamion> I thought he had, I saw stuff in my hoary seed diff mail
<davyd> perhaps I should have installed warty and dist-upgraded
<Keybuk> davyd: same problem
<Keybuk> install of ubuntu-desktop's deps except evolution
<Keybuk> The following packages have been kept back:
<Keybuk>   evolution evolution-data-server libebook1.2-0 libedataserverui1.2-0
<davyd> oh right, I can build evo debs
<davyd> work time though
<davyd> later all
<Kamion> Keybuk: what's it waiting for?
<Keybuk> not sure, some evo dep
<Keybuk> evolution-exchange hasn't been updated yet, so probably something under that
<Keybuk> ask seb
<Keybuk> in fact, it looks to me like seb was mistaken and he hasn't uploaded evolution-exchange
* Kamion attempts to understand tzsetup
<Kamion> maybe I should just create a zoneinfo-udeb
<Kamion> it would be kind of nice if the timezone question came right after language and country, but that's Hard
<daniels> elmo: I have so much respect that I can now run a three-man gang.
<mjg59> daniels: Haha
<mjg59> How long have you had it?
<lamont> daniels: you around>?
<daniels> lamont: got your email
<daniels> mjg59: two days
<lamont> daniels: cool
<moquist> is there a mailing list I can query about finding a mentor so I can learn to create ubuntu packages?
<moquist> (I think I saw one mentioned here once)
<tseng> moquist: actually, you should know a good bit before you try and get a mentor
<tseng> start reading the new maintainer handbook and the deb policy
<tseng> http://www.debian.org/doc/maint-guide/
<moquist> tseng: I've been through much of the deb policy doc.  The deb maint-guide looks great; I'm still looking for the new maint handbook.  Thanks for your help, btw.
<tseng> that is the new maint guide
<moquist> tseng: Oh; I assumed it was an ubuntu doc.
<tseng> it covers almost everything around package creation + maintainence
<tseng> ubuntu does a few things a little different on the backend of things, but i dont think there is a comprehensive doc
<moquist> tseng: btw, the package I'm interested in is the LTSP.  Do you know if anyone is already working on it?  I know it's on Mark's list of things to do for Hoary.  (It could be done for all I know - I've been on vacation for a week and haven't checked.  ;)
<tseng> there is a debian page of packages on the wishlist
<tseng> its mentioned in the new maint guide, i believe
<sivang> moquist: there isn't such, at least not yet.
<moquist> sivang: k; thx.
<sivang> moquist: there are plans to extend the ubuntu set of new maint docs, but there is a new page on the wiki with some starters for interested people.
<moquist> sivang: that's where I found myself while looking for a new Ubuntu maintainer handbook.
<moquist> sivang: it's already helping.  :)
<sivang> moquist: eh ok :) great, the doc team intends to invest some effort into that matter eventually :)
<tseng> moquist: oh also
<tseng> install and read the docs for cdbs
<moquist> tseng: am doing.  thx.
<sivang> tseng: there are docs now? :)
<tseng> sivang: enough to get started at least
<sivang> tseng: what's the pkg name?
<sivang> tseng: (for docs)
<tseng> cdbs
<sivang> eh :0
<sivang> :)
<sivang> k, thanks
<tseng> i dont recall if they were packaged or on the site
<tseng> https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS
<sivang> tseng: I can't see no doc dir , probably on the wiki..
<jbailey> Err, did I fail to include the docs in the package?
<sivang> jbailey: if you would, it would have appeared under /usr/share/cdbs/doc  no?
<jbailey> I know we generate some basic docs.
<jbailey> /usr/share/doc/cdbs, but yeah.
<sivang> jbailey: eh ok :) it's there.
<sivang> my abd
<sivang> *bad
<daniels> jbailey: hey dude.  good somewhere-other-than-work period?
<jbailey> daniels: Nope, still working evenings.  This should be the last one.  If you /msg, I'll answer but a bit lagged.
<daniels> jbailey: Ah, nice one.
<jbailey> sivang: While I'm around, I'll try to answer cdbs questions.
<sivang> jbailey: eh nice , I have one for you!
<sivang> :)
<sivang> jbailey: I have a couple of docs files I want to register against docbase or scrollkeeper (well, mostly scrollkeeper as I want them to appear in yelp) how can I use cdbs to do that?
<sivang> jbailey: so after I install the pacakge, I would have the docs viewable from yelp. those are DocBook XML sources.
<jbailey> I think there's a debhelper module for that, no?
<jbailey> The best bet when there's a debhelper module is to set those files up and just use debhelper.mk
<sivang> jbailey: ok, I have tried setting them up and called debhelper class - guess my omf is not complete or wrong. tnx anyway.
<srbaker> anyone know where i can get ant and other jakarta utils packaged for ubuntu?
<sivang> jbailey: from the man pages of the dh_scrollkeeper command, I don't quite understand where it exepcts the files to be, could you toss a hint here?
<jbailey> Oh, oy.  I haven't used dh_scrollkeeper.  Might best ask some gnome hackers.
<crimsun> sivang: debian/$package/var/... if you're using dh_scrollkeeper
<crimsun> gnome.mk calls it
<sivang> crimsun: could you offer a better way then using the gnome build class? it exepcts autotools and others, which I can include int he docs pkg but would prefer to pass, or is it compulsory for registering dobook docs using cdbs?
<crimsun> sivang: afaik it's the preferred method. seb128 would be the one to ask.
* sivang thinks of throwing in the autotools just for sake of gnome and cdbs class compatibility.
<sivang> crimsun: tnx
<crimsun> np
<davyd> arrg, ubuntu-desktop is still uninstallable
<Treenaks> davyd: gnome-related brokenness?
<davyd> Treenaks: evolution-exchange is uninstallabe
<Treenaks> blame seb128 :)
<Treenaks> we do
<davyd> I can do that
<davyd> Kahn!!!^WSeb!!!
<davyd> I'm trying to work out how to work around the missing dependancy
<Treenaks> apt-get -f install?
<Treenaks> or recompile ubuntu-meta ?
<davyd> someone should upgrade the kernel to include Orinoco 0.15, rather then 0.13e
<davyd> magic will happen, like working AP scanning
<Treenaks> davyd: poke fabbione 
* Treenaks feels like a redirector-bot
<davyd> heh
<davyd> I might have a swing at packaging it later, although I suspect this will require some magic, like perhaps learning how to do diversions
<davyd> since I'll want to install using filenames already in the tree
<Treenaks> fabbione updated loads of drivers for 2.6.10
<davyd> is that packaged now?
<crimsun> hm. I'm thinking bittorrent* in hoary needs to be recompiled against current python2.4
<Treenaks> I think so
<davyd> quick question, what's the incantation ubuntu uses for wireless cards?
<davyd> I saw it earlier
<davyd> but this time I installed off ethernet
<Treenaks> uh isn't it all in /etc/network/interfaces ?
<Treenaks> iface eth0 inet dhcp
<Treenaks>         name Wireless LAN card
<Treenaks>         wireless_essid youressid
<Treenaks>         wireless_key yourwepkey
<davyd> Treenaks: it didn't write it there for me
<davyd> there is a whacky mappings section too
<davyd> which is what I'm vague on
<Treenaks> oh I have that too :)
<Treenaks> it's there so when you hotplug the card it gets ifupped
<Treenaks> mapping hotplug
<Treenaks>         script grep
<Treenaks>         map eth0
<davyd> it has similar sections for ethernet as well?
<Treenaks> ppp0 in my case, but yes
<Treenaks> but I don't hotplug my ppp connections ;)
<abelli> kamion: ping
<fabbione> morning
<abelli> ciao
<fabbione> ciao
<Treenaks> fabbione: you've been poked by davyd 
<davyd> morning fabbione 
<davyd> I was wondering if you were going to package Orinoco 0.15 with your kernels any time soon?
<fabbione> guys i am really sick today
<fabbione> i am not working since yesterday
<fabbione> just checking emergency emails before crashing again
<davyd> that's cool
<Treenaks> fabbione: well, good luck then
<fabbione> davyd: please send me all the details of the driver including upstream url and stuff like that
<fabbione> this wlan stuff should die
<davyd> fabbione: ok, I'll get around to it once I unfuck my laptop
<fabbione> they don't deserve all this attention
<davyd> it might have been merged into 2.6.10... I haven't checked
<fabbione> please do
<fabbione> humpf
<fabbione> there is a big regression in 2.6.10
<fabbione> pcmcia_core has been renamed to pcmcia
<Treenaks> urgh
<mvo> 2.6.10 has some problems with my system ... I got two hangs at startup so far
<Treenaks> I had a nice one with my Via X driver.. it starts fine, but as soon as the first windows needs to be filled X crashes with "Inappropriate ioctl for device"  (this is Debian sid)
<fabbione> mvo: 2.6.10 isn't the best we could get from upstream
<mvo> yeah :/
<fabbione> uh yeah
<fabbione> pcmcia udebs are cracked
<lupusBE> jdub: http://bugzilla.gnome.org/show_bug.cgi?id=162414 what do you think :)
<fabbione> hmmm no
<fabbione> pcmcia_core is still there
<fabbione> these gratuitos CONFIG_* rename are really a pain in the ass
<pitti> Hi folks
<Treenaks> hey pitti
<sjoerd> pitti: morning
<ogra> hi pitti
<lupusBE> daniels: how is xcb doing?
<Kamion> abelli: pings should include content :)
<abelli> Kamion: ping foreach (hoary's grub-instal)  do-es (break grub)
<Kamion> well, if you know how to fix it ... :)
<Kamion> it's been working for me
<abelli> Kamion: i tried to install array-2 hoary and then at reboot-time it prints the word "GRUB" endlessly
<abelli> Kamion(it's been working... ;): im happy for you :)
<Kamion> you'll need to (a) file a bug rather than doing this on IRC (b) dig down a bit into what grub-installer is doing
<abelli> Kamion: i'd love to... may be can you tell me how?
<Kamion> normal shell tracing tools, 'set -x', then look at how it's calling grub and do that by hand, etc.
<Kamion> I can't teach you how to debug, though :)
<abelli> Kamion: why not Her Professor ;)?
<Kamion> (that would be "Herr")
<abelli> oops.. sorry 
<abelli> like miyagi and daniel san
<abelli> :) you teach.. i "wax on".. "wax off" :)
<Kamion> we really need somebody else on the team who's better at dealing with bootloader problems
<Kamion> no, I simply can't teach how to debug, it's like teaching how to walk or something :)
<abelli> well birds follow other birds to learn how to fly..
<abelli> ;) can i follow you ?
<Kamion> bit hard considering you're not in the same place
<Kamion> the only way to learn is to try
<Treenaks> abelli: just compile something with debugging symbols and run it in gcc
<Treenaks> abelli: uh gdb
<Treenaks> abelli: then get out the gdb manual and start poking around :)
<Kamion> (grub-installer is shell so doesn't need debugging symbols)
<abelli> Kamion: that's what i was talkin about
<Treenaks> Kamion: oh wait.. it's shell..
<abelli> Treenaks: Perl Debugger power ;)
<Treenaks> abelli: perl debugger is scary.. I debug perl with warn()s
<Treenaks> abelli: and I debug XS modules using gdb :)
<Kamion> abelli: anyway, regardless, please file a bug about bugs rather than asking me about them on IRC, thanks. :)
<abelli> Kamion: ups sorry i just thought this was the 2nd part of the discussion we had...mmm... yesterday
<fabbione> hey Kamion 
<davyd> can someone paste the magic -mapping- lines from /etc/network/interfaces please?
<Treenaks> davyd: again? :)
<Treenaks> mapping hotplug   
<Treenaks>         script grep
<Treenaks>         map eth0
<davyd> Treenaks: I kinda lost it ;)
<davyd> perhaps I suck ;)
<Treenaks> davyd: "DOH" :)
<fabbione> does anybody know if ipw2200 firmwares require any special naming?
<fabbione> apparently they have been renamed recently and i would kinda like to avoid to break
<mjg59> fabbione: Ok, I haven't managed to break 2.6.10 yet
<fabbione> mjg59: good for you :-)))
<fabbione> pcmcia is broken because of pcmcia_core being compiled in instead of module
<mjg59> fabbione: Oh. Whoops.
<mjg59> Anyone here running on the vesa framebuffer?
<davyd> gah, where is the SSL in Evolution gone?
<Treenaks> davyd: #5093
<Treenaks> davyd: and http://bugzilla.ximian.com/show_bug.cgi?id=70895
<davyd> interesting
<davyd> and here I was blaming Ubuntu
<davyd> although, I'm still tempted to, I think it might be fixed in cVS
<lupusBE> if the bugreport is set to fixed
<lupusBE> it is in cvs
<davyd> good point
<lupusBE> :)
<davyd> I'll rephrase
<davyd> when building CVS, I did not notice that
<robtaylor_> hmm, is the fastbootup stuff in hoary now?
<davyd> hmm, seb was complaining recently about the AC adapter not sendings events properly
<davyd> now that I'm running Ubuntu on the same hardware... this is a damned Ubuntu bug
<davyd> only I don't know where
<shaya> anyone using evolution w/ ssl?
<davyd> shaya: it's broken
<davyd> I've already complained about it
<lupusBE>  XInternAtom
<lupusBE> davyd: and http://bugzilla.ximian.com/show_bug.cgi?id=70895
<lupusBE> copy paste :)
<shaya> sigh
* shaya goes off to look for older packages
<shaya> fsck
<shaya> downgraded and now it crashes on startup
* shaya very annoyed
<davyd> shaya: evolution-data-server will need downgrading too
<davyd> I should downgrade, but I'm not sure I can arsed
<shaya> I did
<davyd> and restarting?
<shaya> Version: 1.1.1-0ubuntu1
<shaya> yes
<shaya> slay'd me
<shaya> restarted d-bus
<davyd> ok, apparently Ubuntu sucks ;)
<shaya> what I dont get is why in the world do package upgrades require me to restart
<davyd> because you can't replacing running shared libraries easily?
<shaya> breaking out thunderbird
<siretart> shaya: ah, I'm glad to see I'm not the only one with that problem :)
<pitti> mvo: can I tell apt-get to ignore failed signatures? I would like to install some packages from woody (for upgrading tests)
<fabbione> pitti: it's almost the end of 2004
<pitti> fabbione: indeed
<fabbione> you are supposed to be out getting drunk and having fun
<pitti> fabbione: I go to our party in about an hour
<davyd> 2004 was like an hour ago
<pitti> davyd: happy new year!
<fabbione> davyd: 2005 is a few hours ahead here
<fabbione> ;)
<pitti> fabbione: what about you, when you will leave?
<fabbione> pitti: i won't
<fabbione> <- doesn't feel good
<pitti> oh?
<fabbione> i will have some quiet dinner here at home
<fabbione> that's it
* pitti feels sorry for fabbione's conditin
<pitti> fabbione: I wish you a nice evening anyway!
<fabbione> pitti: nah don't worry
<pitti> and everybody else, too
<fabbione> i hate all these holidays anyway
<fabbione> ;)
<fabbione> have fun man
<pitti> I will
<fabbione> and see you next year
* pitti already bought some firework ;-)
<ogra> pitti: guten rutsch ;)
<fabbione> ehhe
<pitti> .. and I prepared lots of food
<pitti> ogra: Dir auch!
<fabbione> fooood.. hmmm
<fabbione> i am hungry
<pitti> fabbione: I prepared fish with vegetables and potatoes, salad and chocolate pudding with vanilla sauce
<fabbione> hmmmm
<fabbione> not bad
* pitti watches fabbione getting envious and nervous
<fabbione> i am going to have "fondue"
<fabbione> basically it's a big pot of boiling oil
<pitti> fabbione: oh, I like fondue, too
<fabbione> ah ok.. so you know what it is
<fabbione> with salad, vegetables
<fabbione> and garlic bread
<pitti> hmmm
<fabbione> + some kind of sweets
<fabbione> i still have to decide which ones
<pitti> fabbione: just take all :-)
<fabbione> thanks god i only have some fever
<fabbione> and i didn't lost appetite :PO
<pitti> fabbione: if you are still hungry, that's a good sign
<fabbione> pitti: yeah i know
<fabbione> but i never loose my appetite
<fabbione> even with 40 of fever
<pitti> so long, I wish everybody a happy evening! See you next year!
<fabbione> cya pitti!
<ogra> ciao
* pitti cares for his gf now and goes to party :-)
<fabbione> happy new root hole
<pitti> ciao
* pitti laughs
<fabbione> ogra: have fun too
<davyd> * pitti cares for his gf now and goes to party :-)
<davyd> <fabbione> happy new root hole
<davyd> mmm, context
<fabbione> davyd: pitti is our security release guy ;)
<ogra> fabbione: you too ;) have a nice silent one
<fabbione> the one that does the USN :-)
* pinhead STARTS A NEW HELL WHERE TO BURN SOME SOULS RIGHT AT 12:00
<davyd> it occurs to me, it's probably only funny if you're Australian
<davyd> never mind
<ogra> *g*
<Treenaks> fabbione: kernel souls? ;)
<fabbione> Treenaks: SOULS
<davyd> oh, I think my laptop boots
<fabbione> all our users souls
<davyd> I only had to rebuild the kernel exporting symbols I shouldn't
<Treenaks> fabbione: KERNEL SOULS?
<davyd> and build a 10 month old nvidia driver
<fabbione> USERS SOULS
<Treenaks> fabbione: even better :)
<fabbione> ehehhe
<fabbione> including your
<fabbione> Uha UHA UHA
<Treenaks> fabbione: I'm a UBUNTITE
<Treenaks> (or something)
* fabbione prepares the last upload of the year
<fabbione> Treenaks: something :-)=
<fabbione> the queen is talking on the radio
<fabbione> boring
<Treenaks> fabbione: queen of what?
<fabbione> Denmark
<Treenaks> they have a queen there?
<Treenaks> hm.
<fabbione> yeah they do
<davyd> is she Australian?
<davyd> or is that the princess
<davyd> or is that the Dutch?
* davyd can never recall
<fabbione> the princess is from australia
<fabbione> the big fat wedding was like in Aug
<fabbione> or something like that
<Treenaks> davyd: no, the Dutch crown prince married Argentinian woman.. daughter of a minister from $oppressinggovernment..
<Treenaks> +an
<fabbione> bah it's all the same crap
<fabbione> they just eat and live with our money (taxes)
<fabbione> and don't tell me they do something important more than a few speeches here and there
<fabbione> because i really find them useless
<fabbione> i am off guys
<ogra> ciao
<fabbione> for you lifeless creatures that will stay on the net....
<fabbione> 2.6.10-2 is on the way and it should fix some regressions
<fabbione> have fun
<fabbione> ciao ogra 
<ogra> :)
<Treenaks> yay.. Walking Bookmark Repository strikes again (ubuntu-users@)
<ogra> Treenaks: Walking Bookmark Repository ?
<Treenaks> ogra: see my mail on -users (about shell scripts ;))
<Treenaks> ogra: people sometimes  call me a walking bookmark repository
<Treenaks> ogra: because of the URLs I keep shouting at them :)
<ogra> ah, not here yet ;)
<ogra> did you send a abs-howto link ;)
<Treenaks> ogra: not quite
<Treenaks> Message-ID: <20041231171436.GB24291@facecrime.net>                              
<sladen> okay.  looks like o#ubuntu we have a widely found issue of the GDM panels starting but nothing more getting loaded
<sladen> only fix seems to be reboot;  but with me it's currently 100% failure rate.  Any GNOME people want to give me a hand in what to hunt down?
<Treenaks> sladen: killing gnome-vfs-daemon and blocking programs also fixes it 50% of the time for me
<sladen> blocking programs?
<Treenaks> sladen: programs that hang
<Treenaks> sladen: the panel, nautilus etc.
<ogra> sladen: it often happens for people that ran nautilus as root....
<Treenaks> ogra: I didn't do that, it still happens
<ogra> Treenaks: i didnt say you did that, and i assume you got hoary anyway.....
<sladen> ogra: okay, we can discount that theory then
<Treenaks> ogra: oh this is a warty thing?
<ogra> Treenaks: afaik a chown -r can solve it on warty
<sladen> I (think) I've had it under Warty.  However it'd been getting worse (1 in 6 say) and now with a full dist-upgrade 1 hour ago it's 100% (so far) failure
<Treenaks> ogra: oh that's the ICEAuthority thing? from running K3B as root?
<ogra> Treenaks: nope, thats running nautilus as root for editing the "system" app menu.....
<Treenaks> ah ok
<ogra> which is kind of nonsense
<sladen> interesting.  Left it five minutes.  Reappeared at the GDM login screen (presumbley a watchdog).  Loged in again and it came up immediately
<Treenaks> yikes.. ruby looks like the evil mutant child of perl and python
<sladen> Treenaks: correct :-)
<ogra> sladen: anything in ~/.xsession-errors ?
<sladen> gnome_execute_async_with_env_fds = -1
<sladen> wonder if it's related to session handling.  Lets try and break it again
<sladen> progressive.  Background *and* show-all-windows applet
<ogra> sladen: tried with a fresh user ?
<trulux> hi!
<sladen> ogra: interesting idea
<ogra> sladen: ...to divide between config and program errors
<Treenaks> ogra: unless the program writes b0rken config files
<ogra> Treenaks: true :)
<sladen> fresh new user comes up great with only an error 'no volume control elements or devices found', which I presume is Audio rather than Disk related
<ogra> sladen: a group thing, new users have less group permissions
<sladen> logout, login as me again == failure
<ogra> sladen: so i assume its something in your config
<sladen> gdm restart && login as 'fred flintstone' brings up ''I've detected a panel already running and will now exit''
<sladen> leaving poor 'fred' with nothing but a background
<ogra> sladen: thats a known one...kill the running panel.....
<sladen> sudo pkill -u fred
<ogra> yep....
<davyd> woo! it only too a custom kernel, 8 month old graphics drivers, and a magic xorg config
<davyd> but I think I have my laptop basically working again
<sladen> login again as 'fred'  and failure (show-all-windows and background only)
<davyd> hmm, it likes to spend time configuring network interfaces, which I think it a little silly
<ogra> sladen: looks like Treenaks is at the right track....
<Treenaks> or it is just plain random hanging.. i.e. a race condition somewhere
<sladen> ogra: I'm inclined to agree
<sladen> what's puzzling me is that sometimes zero, one or two of  (show-all-windows applet and background come up)
<ogra> Treenaks: but it works the first time fine.....
<sladen> are they just the first two items in the load order
<Treenaks> ogra: always? or sometimes?
<ogra> Treenaks: good question.... i was guessing....
<sladen> sudo -u fred rm -r /home/fred/.gnome*  && it works again
<sladen> logout, login, okay
<Treenaks> why is mutt "stuttering" when I browse my mail over IMAP?
<Treenaks> sladen: I really think it's race thing, as it happens here 50% of the time
<Treenaks> (because mail_check == 5)
<sladen> cya?
<sladen> Treenaks: what's because mail_check == 5 ?
<ogra> sladen: <Treenaks> why is mutt "stuttering"
<Treenaks> sladen: what ogra says :)
<sladen> okay.  Just got excited there for a moment
<davyd> who here cares about power management in Ubuntu
<davyd> besides seb
<Treenaks> all laptop owners :)
<Treenaks> mjg59 too
<davyd> I mean from a dev point of view
<Treenaks> mjg59 then
<davyd> I think I've solved Seb's problem of never receiving ac_adapter events
<davyd> the script is too long, so the event arrives about 30 seconds late
<davyd> or sometimes it seems, not at all
<ogra> 30 second ? lol
<mjg59> Eww
<mjg59> How does it do that?
<davyd> mjg59: events aren't forwarded on the socket until after the script has done processing on them
<davyd> I think it's so you can jam them
<davyd> and do other things
<davyd> your script takes forever and a day to execute
<davyd> I managed to improve interactivity by wrapping it in power_script() { }
<davyd> and going power_script & at the end
<davyd> this at least causes things like the battery applet to update immediately
<davyd> however, the script does execute too slow
<davyd> so other things I'm doing, like changing LCD brightness happen much after I expect them
<mjg59> davyd: Hrm. Where is it actually taking the time?
<mjg59> Adding a set -x to the top and tail -f /var/log/acpi.log ought to show you that
<davyd> mjg59: hang on, I'm just changing other things
<davyd> you are able to use, if on_ac_power; then
<davyd> on_ac_power is a program provided by something or other
<davyd> should be quicker then grepping I feel...
<shaya> yay
<shaya> evolution works
<mjg59> davyd: It's a shell script that greps :)
* shaya does a jig
<shaya> davyd: it's been fixed
<mjg59> on_ac_power actually does /more/ greps than power.sh
<davyd> mjg59: does it?
<davyd> what else is it doing?
<mjg59> Which? on_ac_power?
<mjg59> It greaps for on-line and then greps again for off-line
<mjg59> No idea why
<davyd> interesting...
<mjg59> davyd: Sometimes the xscreensaver stuff seems to take some time if the user isn't logged in
<davyd> mjg59: I've taken that out, it's still slow
<mjg59> Very odd.
<mjg59> If you could try set -xing it and then tailing the output, that would help a great deal
<davyd> I'm playing with that now
<davyd> there is an f-ing sleep 5 in there...
<davyd> I wonder what that is meant to do?
<mjg59> Yeah, that was to work around an acpi bug where the status wasn't always updated the moment the event appeared
<mjg59> (IIRC)
<davyd> nice...
<davyd> ok, well I'm removing that, and a lot of other cruft
<davyd> I recommend that you wrap the entire script in a function() { }
<davyd> and call function & at the end
<davyd> to stop it blocking events
<davyd> that should unfuck things like battstat
<mjg59> Yeah, but it'd be nice to know /why/ it's blocking events
<davyd> mjg59: because acpid is a POS?
<mjg59> Ah, sorry, not that - I know that it serialises everything
<davyd> you can probably use exit codes to eat events or somesuch
<mjg59> But why the script is taking so long
<davyd> mjg59: the sleep 5 can't help ;)
<davyd> I've taken that out, and the X probing stuff and the x screensaver stuff
<davyd> and now it's nice
<mjg59> The X stuff is fairly necessary, until we get HAL love
<davyd> I don't need any of those things anyway ;)
<mjg59> Was someone working on battery support for HAL?
<davyd> sergey I think
<Treenaks> that would rock
* davyd swaps out powernowd for cpufreqd which seems to actually do stuff
<mjg59> Hrm. We tended to find that powernowd behaved a lot better.
<davyd> many people have said so
<davyd> I haven't managed a lot of joy with it
<davyd> I hate them both
* davyd installs cvs
<davyd> mjg59: http://live.gnome.org/PowerManager
<mjg59> davyd: Yeah, that sort of thing
<davyd> mjg59: that's my grand vision
<mjg59> Mm. Nice.
<davyd> as soon as HAL gets it's act together I'm writing it
<davyd> along with weather.gnome.org
<davyd> which we should have reading for 2.12
<Treenaks> davyd: as long as PowerManager doesn't become the useless bloated PoS that NetworkManager is becoming...
<davyd> Treenaks: I haven't got that working yet
<davyd> is it in Hoary now?
<Treenaks> davyd: ask Thom about it
<mjg59> NetworkManager /was/ going to be the default in Hoary
<davyd> but?
<Treenaks> mjg59: until the authors smoked some BAD crack
<mjg59> It, uh, doesn't really work
<davyd> aah
<mjg59> It's a mess of scary race conditions internally
<davyd> nice...
<Treenaks> it doesn't save its state to /etc/network/interfaces. it doesn't use /etc/network/interfaces to READ state
<Treenaks> it doesn't use ifup/ifdown, but re-implements everything
<davyd> Treenaks: that's by design
<mjg59> netapplet is entirely and utterly the wrong answer, but has the side effect of working
<davyd> although it should wrap ifup and ifdown
<Treenaks> davyd: it doesn't.. they implented their own DHCP client
<Treenaks> (and we know how well RedHat DHCP clients work *cough*pump*cough*)
<davyd> heh
<davyd> the basis behind not using everyones network config system is a good idea
<davyd> non of them work well in the desktop space
<Treenaks> davyd: /etc/network/interfaces + mapping would
<davyd> network/interfaces is great for machines that never change IPs
<davyd> and fantastic for things with routers
<davyd> and sysconfig is simply not good for anything
<Treenaks> davyd: maybe a /etc/network/interfaces.d with a file for each network (by name)
<davyd> Treenaks: or maybe not trying to hack a solution together ;)
<davyd> and instead let users control it
<Kamion> /etc/network/interfaces is the thing that installers understand, though, and everything else in the distribution
<Treenaks> davyd: yes, read the BOF notes from the conference
<Treenaks> davyd: this was discussed there :)
<Kamion> if you don't give a damn about integration with distributions, NM's approach makes sense; unfortunately integration is kind of important if you happen to be the distribution
<mjg59> Having two methods for working with network configuration is pain
<davyd> I mean, the idea behind PowerManager is to get rid of those hokillion daemons
<davyd> and the config crack
<davyd> and have no more random shell scripts
<mjg59> davyd: Yeah, that makes sense
<davyd> and just have an applications, with some nice plugins, that knows ALL the state
<davyd> no unix sockets, not constantly polling proc and blocking the kernel up
<davyd> beautiful and clean
<davyd> and dbus
<Treenaks> davyd: that's different.. power has a set amount of states and configuration is broken atm. networks already have a configuration interface
<mjg59> Abstracting at that level is the right thing to do
<davyd> lots of dbus
<mjg59> But network interfaces are already abstracted at about that level
<Treenaks> davyd: unless PowerManager is going to aim to replace acpid, then I'll personally kill the devs
<davyd> Treenaks: that's part of the plan yes
<davyd> acpid is a piece of shit
<Treenaks> davyd: as long as I don't need f'ing gconf to configure it I won't mind too much
<davyd> Treenaks: nah, that sounds painful
<davyd> although users might have gconf settings they feed to it via dbus
<Treenaks> davyd: that's the case with NM if you're not running X
<mjg59> Per-user config probably ought to have stuff in gconf
<davyd> mjg59: indeed
<mjg59> But really, what you want is:
<davyd> need to think of a way to do global config sanely
<mjg59> 1) a daemon that listens for events and propagates them
<mjg59> 2) a system-wide client that is small and does important stuff
<mjg59> 3) a per-user client that integrates nicely with their desktop
<davyd> problem with 3 is permissions of course
* Treenaks praises mjg59
<mjg59> Yeah. 
<davyd> in my current sketch
<mjg59> We need a good way of figuring out who is actually physically in front of the machine
<davyd> 3 would receive dbus events from the daemon
<davyd> and then send back requests
<davyd> and assuming the permissions model allows it
<mjg59> Because currently, all solutions suck
<davyd> will complete them
<davyd> mjg59: we're too damned multi user ;)
<davyd> perhaps we should just run in single user mode ;)
<mjg59> Haha
<mjg59> lindows has it easy
<mjg59> But this is a problem when it comes to things like scanner access, too
<davyd> we have some terminal server clients that run in single user mode or something vaguely like it
<davyd> they work nicely
<mjg59> Actually, it's not /too/ hard to figure out who's at the console
<mjg59> PAM can do that for you
<davyd> mjg59: I thought there were issues with that module?
<mjg59> davyd: The issue isn't that you have no idea who's at the console at this moment in time
<mjg59> The issue is that the last person at the console potentially still has open filehandles
<davyd> evil hack of the day... installing CVS gnome-applets into /opt and then convincing bonobo to use them
<davyd> so Ubuntu can give me development GNOME
<davyd> and I can have the bleeding edge applet-love I crave
* Treenaks prefers his edge non-bleeding
<mjg59> If the kernel had a revoke() call, this would be much easier
<davyd> Treenaks: you kinda should run CVS when you're the maintainer
<davyd> not that I've been much of a maintainer lately
<Treenaks> davyd: that sounds like a valid reason :)
<Treenaks> davyd: I'm not a maintainer though ;)
<ogra_dinner> Treenaks: yet ? :)
<Treenaks> ogra_dinner: not gnome upstream.. PLEASE NOT GNOME UPSTREAM
<Treenaks> ;)
<ogra_dinner> heh
#ubuntu-devel 2005-01-12
<usual> will hoary gstreamer be able to play dvd's
<gsuveg> i would ask from rosetta. i cant send mail a lead maintanert
<trulux> pitti, ping
<pitti> trulux: pong
<trulux> pitti, happy new year btw!
<trulux> :)
<pitti> trulux: you too!
<pitti> trulux: I will look at the SSP packages next week
<pitti> trulux: unless there are not 20 security updates again... :-/
<tseng> pitti: any luck with that patch?
<pitti> tseng: I did not yet try it
<pitti> tseng: I had some holidays the last week
<tseng> heh, holidays are good
<trulux> hey pitti
<trulux> tseng, happy new year
<tseng> thanks.
<pitti> tseng: happy new year!
<tseng> and you, trulux and pitti 
<trulux> :)
<trulux> tseng, btw, i really want 2.6.10 with pax
<tseng> trulux: do you have the rc patches?
<trulux> but i don't know when pipacs could get it done
<trulux> tseng, nope :(
<tseng> check your status window.
<Treenaks> does anyone know a good URL explaining that Outlook is broken, not PGP/MIME?
<Q-FUNK> hello
<Q-FUNK> I'm just wondering if we're gonna have any ubuntu-calendar package for this month?
<Mithrandir> I guess jdub just haven't gotten around to uploading one yet.
<Q-FUNK> ok
<Q-FUNK> I was starting to think that maybe the criticism Ubuntu received from those nudes might have gotten Mark to decide against continuing the tradition in 2005.
<tseng> most people dont have a problem with them being available, or even installed in most cases
<tseng> it was having them come up as the default
<Q-FUNK> hm
<bluefoxicy> I don't see how to change the theme
<bluefoxicy> and I"m curious
<bluefoxicy> because the main page has a picture of the log-in screen that I don't have
<bluefoxicy> and I'm like "??????"
<Mithrandir> bluefoxicy: run "login configuration" (it's called something like that) and select the Human theme
<bluefoxicy> i think that's the default theme.
<bluefoxicy> HumanCircle
* bluefoxicy edits gdm.conf with vim
<bluefoxicy> holy crap that man has no nipples
<tseng> he lent them all to the chick in red
<bluefoxicy> lol
<bluefoxicy> tseng:  reminds me of quagmire from family guy
<tseng> me, or the picture
<bluefoxicy> the picture
<tseng> giggity giggity
<bluefoxicy> the guy looks like "Sweet I'm gonna have a 3-way with a black chick!"
<bluefoxicy> hm
<bluefoxicy> nuvola isn't available.
<bluefoxicy> i like that theme.
<tseng> apt-get install gdm-themes
<bluefoxicy> no, gtk theme
<tseng> i have it.
<bluefoxicy> huh.
<bluefoxicy> I don't have it on ubuntu
<bluefoxicy> it's on gentoo thouhg.
* bluefoxicy has ubuntu-desktop merged
<janc> there is a package that includes nuvola
<janc> gnome-themes-extra
<janc> in universe
<bluefoxicy> heh
<janc> but next time better ask such things in #ubuntu  ;-)
* bluefoxicy juggles whether he wants to add universe or not
<bluefoxicy> I should retheme ubuntu in blazingly blue hues
<Q-FUNK> naaa
<Q-FUNK> those brown shades are cool
<bluefoxicy> I hate brown
* bluefoxicy prefers cool colors  :>
<Q-FUNK> those earth colours are cool.
<bluefoxicy> wtf
<bluefoxicy> gimp
<bluefoxicy> has a my documents quickbutton
<bluefoxicy> awesome.
<mxpxpod> fabbione: ping
<bluefoxicy> http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda
<bluefoxicy> Traceback (most recent call last): File "/home/zope/instances/ubuntu/Products/ZWiki/plugins/Fit.py", line 29, in ? from fit.Parse import Parse ImportError: No module named fit.Parse
<ChrisH> Has anyone managed to get a "pbuilder create" in Warty to make a clean Debian build environment? I have dependency problems and wonder whether that's ubuntu-specific.
#ubuntu-devel 2005-01-13
<Kamion> ChrisH: which distribution?
<ChrisH> Kamion: sid
<ChrisH> Kamion: Perhaps pbuilder/debootstrap are just plain broken atm... (?)
<Kamion> there's a bug about that, pppoeconf is broken
<Kamion> disallowed dependency change in base system
<Kamion> (*ahem* *removes Debian RM hat*)
<ChrisH> I have problems with bash depending on passwd which is not there. :(
<Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285496
<Kamion> hm, really?
<Kamion> oh, warty
<ChrisH> Yes, plain Warty with a local Debian mirror.
<Kamion> warty is older than sarge/sid, and in general you must have a version of debootstrap at least as new as the version you're trying to bootstrap
<Kamion> try with hoary's debootstrap
<Kamion> debootstrap (0.2.39.1) unstable; urgency=low
<Kamion>   * NMU
<Kamion>   * add passwd to sid.buildd,sarge.buildd as bash depends on them
<Kamion>  -- Junichi Uekawa <dancer@debian.org>  Fri,  9 Jul 2004 09:07:28 +0900
<ChrisH> Is warty too old for that? Shouldn't debootstrap get everything from any debian distribution?
<Kamion> debootstrap | 0.2.39ubuntu22 |         warty | source, amd64, i386, powerpc
<Kamion> no, doesn't work that way I'm afraid
<Kamion> debootstrap has a hardcoded list of base packages which needs to be changed from time to time as the distribution changes
<siretart> is hoary's bootstrap beeing held uptodate to install all distributions and versions from both ubuntu and debian? are there any drawbacks with installing hoary's debootstrap in a sarge system?
<Kamion> we're merging Debian changes into hoary's debootstrap until upstream version freeze in just the same way as we're doing with any other package.
<Kamion> installing hoary's debootstrap on sarge should be fine
<siretart> ah, ok. thanks for explanation.
<Q-FUNK> really nice to see Ubuntu actively support amd64.
<Q-FUNK> it's a nice architecture
<bluefoxicy> does the formation of a new group have to be cleared with the Technical Board, or can it be recommended directly on the CommunityCouncilAgenda?
<bluefoxicy> I'd imagine there's at least some process for this?
<sivang> bluefoxicy: which group?
<bluefoxicy> sivang:  I'm recommending on the TechnicalBoardAgenda currently to discuss one of the enhancements on the IdeaPool and clear the formation of the ParentalControlGroup or something
<bluefoxicy> sivang:  there was an idea to create a "child-friendly" mode which would "disable web" and such
<sivang> bluefoxicy: so basically you want to create a new ubuntu community team?
<bluefoxicy> I put a bunch of comments under it on the IdeaPool about Squid and Dan'sGuardian
<sivang> bluefoxicy: I've read your stuff there :)
<bluefoxicy> sivang:  I . . want a new team to be formed :)
* bluefoxicy dodges the 'are you volunteering' question.
<Q-FUNK> how queer. 
<sivang> bluefoxicy: ok, so CC is the address if I'm not mistaken - also country teams and others..
<sivang> bluefoxicy: (CommunityCouncil)
<bluefoxicy> sivang:  alright.  I'll recommend discussion and *potential* creation of a team.
<bluefoxicy> "MastersOfTheUniverse team"  XD
<bluefoxicy> too much heman
<sivang> bluefoxicy: hehe, I think this has been already discussed and ways are searched to see how to take this further.
<bluefoxicy> sivang:  :)
<ChrisH> Kamion: You were right. pbuilder works perfectly in Hoary. My misconception... I thought debootstrap was a bit too magic. :)
<bluefoxicy> sivang: https://www.ubuntulinux.org/wiki/CommunityCouncilAgenda
<sivang> bluefoxicy: interesting. I wonder how much this could make ubuntu attractive to school and orgs.
<bluefoxicy> sivang:  websense is dog shit.
<bluefoxicy> so I'd say fairly attractive.
<bluefoxicy> Jessie used to surf porn all day in school, just hit spanish porno sites :P
<smurfix> Gah
<bluefoxicy> I think DG has various language support, so it should probably be able to filter unexpected URIs in various languages, instead of just what your administrators have located.
<Kamion> by the way, to form a team you should have at least a couple of people interested in doing the work
<smurfix> Forgive me for being blunt, but whose stupid idea is that?
<Kamion> the team-forming process is not a way to recommend that something should be done
<Kamion> it's a way of saying "we want to do this thing, please bless it"
<bluefoxicy> Kamion:  . . . which is why I was originally aiming at putting that stuff on the tech board agenda page  -.-
<bluefoxicy> should i move it?
<Kamion> frankly it doesn't really sound appropriate for either body until you have people interested in doing the work
<bluefoxicy> Kamion: I'm only suggesting to discuss the idea and determine if it's a worthy endeavor, and if a team should be formed
<usual> will gstreamer in hoary support playing dvd's?
<Kamion> no, getting interested people is not supposed to be the hard bit
<Kamion> do that first
<bluefoxicy> I didn't get that part across clear did I?
<bluefoxicy> Kamion:  I thought discussing it in CC was how you determined if people were interested in it
<Kamion> nope, discussing it in the community at large is how you determine if people are interested in it
<Kamion> the CC is only four people
<bluefoxicy> smurfix: " A child-friendly option on Ubuntu so parents can turn on/off functionlity + browsing web - LouiseMcCancePrice?"
<sivang> Kamion: doesn
<bluefoxicy> smurfix:  I'm just supplying half the answers :)
<sivang> Kamion: doesn't a "member" considered to have voting rights in the CC?
<Kamion> no, only voting rights to *appoint* the CC
* sivang not sure he understood...
<bluefoxicy> Kamion:  should i take this to #ubuntu-users or #ubuntu-devel?
<bluefoxicy> or both
<Kamion> "Community Council meetings are open to all interested parties, but the Council seeks only to find consensus amongst Council members and representatives from the Team that submitted the proposal."
<Kamion> #ubuntu-devel's fine
<smurfix> Turning off web browsing is a bit different from implementing a content filter
<Kamion> oh, the proposal? I'd suggest posting it on ubuntu-devel@lists and finding people who are interested in working on it
<smurfix> The latter, frankly, is NOT something I'd want Ubuntu to have.
<sivang> Kamion: ok, so, since I was agreed to become a memebr last CC meeting as per my contribs, what does this entails me?
<Kamion> sivang: members elect the community council
<sivang> Kamion: ah ok :)
<Kamion> there might occasionally be other votes, but (a) I'd hope that would be rare and we can work on the IETF principle of rough consensus and working code and (b) we haven't really laid that down yet
<Kamion> bluefoxicy: once you have a set of people interested, you can turn to the CC to make it an official team (which basically means you get to call it "Ubuntu <blah>", and get a bit more credibility in that section of the codebase)
<Kamion> bluefoxicy: if there's a technical dispute, or if you think the technical direction of Ubuntu as a whole needs to be modified, you can make a representation to the TB
<Kamion> the TB will consult teams if/when issues relevant to those teams come up
<bluefoxicy> Kamion:  it's modular
<bluefoxicy> you could develop this stuff and install Ubuntu with or without it.
<Kamion> right, so shouldn't involve a change of technical direction
<bluefoxicy> things like the security stuff is more for the TB
<bluefoxicy> since that requires major examination and touches everything in the system
<Kamion> the TB is also responsible for packaging standards, release goals, and package selection
<bluefoxicy> cool
<Kamion> although the last of those tends to be handled more informally by the mdz/jdub diumvirate
<bluefoxicy> diuwtf/
<bluefoxicy> use real words plzkthx
<bluefoxicy> :)
<Kamion> actually duumvirate
<Kamion> see dict
<bluefoxicy> "The union of two men"
<Kamion> triumvirate is a more common word, for three people in the same office
<bluefoxicy> . . . dude stop XD
* Kamion recommends thinking of the mathematical sense rather than the nuptial sense. :)
<bluefoxicy> heh
<daniels> jdub: ping
<daniels> or, even better, Kamion
<Kamion> daniels: yep?
<bluefoxicy> <smurfix> Turning off web browsing is a bit different from implementing a content filter <smurfix> The latter, frankly, is NOT something I'd want Ubuntu to have.
<bluefoxicy> smurfix:  you'd prefer filter=* instead of filter=*slut*?
<bluefoxicy> smurfix:  tihs isn't big brother coming to sodomize your ass for having an opinion of your own and liking naked genetalia rubbing together.  It's simple policy.
<Kamion> ah, scunthorpe
<smurfix> Even hard AI isn't good enough to find out whether any particular parent is going to think a site'd be "harmful" to their kids
<Kamion> did PICS basically entirely stop being useful, or what?
<smurfix> Teaching responsible internet usage isn't going to be accomplishable with a content filter.
<Kamion> (or was it ever useful?)
<lifeless> PICS is entirely useful
<smurfix> Kamion: Lots of sites don't bother
<Kamion> smurfix: personally I think content filters are stupid, but local policy often requires them, and it can be a barrier to acceptance
<lifeless> but... the spam-funding|funded sites don't categorise themselves
<lifeless> also the referrer-revenue sites, where income != return custom, and is rather based on how many popups they can drive
<bluefoxicy> smurfix:  i've hit a few issues with DG, but it's really good.
<bluefoxicy> i've had it let me into a porn site, but not onto a page that had any questionable content
<bluefoxicy> I surfed into a gallery and it was like "WTF NO"
<lifeless> does it let you into a breast cancer site ?
<smurfix> My issue is that _I_ am responsible for educating my kids how to use the Internet
<bluefoxicy> lifeless:  maybe?
<Kamion> yeah, false positives are often more the issue than false negatives
<bluefoxicy> smurfix:  then don't enable the content filtering.
<Kamion> or anything to do with sex education
<smurfix> I am not going to fend that off to some sort of program, and neither am I willing to facilitate anybody else to do so, because I think it's ultimately harmful.
<bluefoxicy> lifeless:  find me a breast cancer site
<Kamion> or, as previously mentioned, Scunthorpe :-)
<smurfix> bluefoxicy: google for it.
<lifeless> bluefoxicy: you so should be able to find that yourself.
<bluefoxicy> smurfix:  you don't just tell children not to look at porno
<bluefoxicy> they get curious
<Kamion> smurfix: bluefoxicy has said that he was opposed to it being on by default ...
<lifeless> I mean, imagine you are in school, studying cancer.
<smurfix> bluefoxicy: So what?
<bluefoxicy> smurfix:  "My 9 year old daughter ordered a double ended anal probe from cumfucking.com"
<Kamion> bluefoxicy: (they can do the same thing without using the internet, if they find a dodgy magazine under dad's bed)
<bluefoxicy> yeah
<lifeless> bluefoxicy: and ? - see Kamions answer, and the fact they won't have a clue what it really is - or if they do have a clue, the internet is /not/ the problem.
<bluefoxicy> but dad usually locks those in the closet
<bluefoxicy> lifeless:  I got most of my clues from the internet
<bluefoxicy> :)
<smurfix> bluefoxicy: Nice of her. Explain to her that she shouldn't do that on multiple grounds, none of which have anything to do with sex, and take away net access for a few.
<bluefoxicy> the whole bdsm-s&m thing you know
<lifeless> bluefoxicy: what does a d-e-a-p have to do with bdsm/s&m ?
<bluefoxicy> you think I know what a buttplug is or what clover clips are or what a ring gag was designed for because they had those in school?
<bluefoxicy> d-e-a-p?
<lifeless> double-ended...
<bluefoxicy> oh
<bluefoxicy> nothing
<Kamion> I think good parenting is kind of orthogonal to whether some people will demand content filtering regardless of whether it's a good idea or not, TBH
<bluefoxicy> it was something from something else
<smurfix> Kamion: The problem is that too many people are willing to use one as a substitute for the other.
<Kamion> and I'm not sure Ubuntu is necessarily in the business of deciding what good parenting is
<bluefoxicy> ok DG won't let me google breast cancer
<bluefoxicy> smurfix:  yeah but look on the other end
<smurfix> ... and I don't want to facilitate that.
<lifeless> (old man mode) - when I was in school, there was no internet, but buttplugs & ring gags were openly discussed by the students.
<bluefoxicy> you wouldn't use it even if it was there
<bluefoxicy> but most parents who would use it already have a problem
<bluefoxicy> either A) They're too lazy to deal with their kids, or B) they simply don't have time, or C) they don't know how.
<lifeless> and TBH, with enough ignorance and stupidity, *more* education would have been a Good Thing.
<Kamion> if it's there, at least you can file bugs on the filtering to make it less stupid
<bluefoxicy> in any of those cases or any combination thereof, they'd let them get whatever the hell they want
<bluefoxicy> you don't think that I'm gonna do my work just because you don't give me a way to push it off on someone else do you?
<Kamion> and it's better than having people resort to a closed-source filter, where the company filters out sites run by people they don't like and won't tell you why.
<bluefoxicy> I just won't do it.
<lifeless> far too much is blamed on the net these days.
<bluefoxicy> and
<lifeless> Kamion: penguinfeet.org
<bluefoxicy> there are other reasons beyond parenting.
<bluefoxicy> It's not your place to decide that "What most people think is inappropriate should be up to the child to avoid" etc etc for one
<bluefoxicy> schools for example must follow a certain metric
<Kamion> lifeless: indeed, but if we select the least bad then we can try to keep it the least bad and have it be the thing people pick first, *if* they decide that they want something like that
<bluefoxicy> a 6 year old can surf porno when he gets home if his parents don't do anything about it; but if the school lets him do it, and the parents don't approve, BAM
<bluefoxicy> $50,000,000 lawsuit
<bluefoxicy> taxpayers' money out the ass
<Kamion> it's not so much making the world better as trying to stave off the worst of the crap that's going to be flowing in anyway
<bluefoxicy> taxes go up
<bluefoxicy> school quality goes down
<lifeless> bluefoxicy: the parents chose a bad school.
<bluefoxicy> next generation becomes stupider than this one.
<bluefoxicy> lifeless:  and who chose to not give the school the tools they need to make themselves a good school?
<lifeless> Kamion: not arguing against cf/domain blocking. Swelltech sell filtering to school, and did before I became fulltime @ Canonical.
<lifeless> *schools*
<bluefoxicy> then there's businesses
<bluefoxicy> ever seen someone sue a business for stupd reasons?
<bluefoxicy> . . . "Eenie meenie moinie moe" . .  . . . 
<bluefoxicy> how much you wanna bet what's on the next coworker's screen can get your business sued for several hundred thousand if not a few milion?
<lifeless> there is a big difference between collaborative database based blocking - which penguinfeet.org enables - or cerberian - and heuristic AI filtering such as dansguardian.
<lifeless> bluefoxicy: how did you go with your breast cancer search ?
<smurfix> lifeless: I agree
<bluefoxicy> lifeless:  google got blocked.  :/
<Kamion> lifeless: (razor versus spamassassin? :-))
<Kamion> or maybe razor versus bogofilter
<lifeless> Kamion: in a nutshell, yes. tried to get a email-report on viagra past spamassassin ?
<bluefoxicy> lifeless:  yeah, colaborative database based blocking is inadequate and reacts to "uh oh somebody got something they shouldn't have, 'damage' done"
<Kamion> nope, but I can imagine
<lifeless> bluefoxicy: you just missed the point.
<bluefoxicy> while DG and heuristics react to "oops.  Well that's stupid.  I'll unfilter that."
<bluefoxicy> http://article.gmane.org/gmane.linux.ubuntu.devel/2840
<Kamion> lifeless: on the other hand I've been on the receiving end of a server being inappropriately blocked by RBLs *shrug*
<bluefoxicy> lifeless:  No, I don't think I did.
<bluefoxicy> you're complaining about filtering things that are harmless
<bluefoxicy> which is a "fail-unsafe"
<lifeless> Kamion: is razor a single-report blocker? or do they need confirmation/review ?
<bluefoxicy> while I'm complaining about failing to filter things that are indeed against policy
<bluefoxicy> er.
<bluefoxicy> that's a fail-unsafe
<Kamion> uh, I don't think it was razor as such, and I don't remember what razor's policy is
<bluefoxicy> the other is a fail-safe
<lifeless> Kamion: ok.
<Kamion> bluefoxicy: um, that depends what "unsafe" means; as lifeless' cancer example demonstrates, the desired failure mode is variable
<bluefoxicy> if you can easily correct the situation with no lasting effects it's a fail safe.  If policy is violated in an irrevocable way it's a fail-unsafe.
<lifeless> well, can I suggest that if a content reviewing team is being established, that it works with an existing team - such as penguinfeet.org - rather than inventing a wheel from scratch.
<bluefoxicy> Kamion:  Yes and i believe that the desired failure mode for most people who would actually enable this stuff is going to be fail-safe, i.e. block things that shouldn't be blocked
<Kamion> bluefoxicy: that sounds like a coded way of saying "false positives don't matter"
<bluefoxicy> Kamion:  no, false positives matter, but can be corrected
<smurfix> bluefoxicy: Unblocking isn't always that easy.
<bluefoxicy> false negatives however expose content which you wanted filtered, which you can't undo
<bluefoxicy> once you've seen it you can't un-see it.
<bluefoxicy> for example, you hit goatse.cx
<bluefoxicy> and decide that that should be filtered.
<lifeless> bluefoxicy: fail-safe == 'I failed my assignment because I couldn't look up X' or fail-safe == 'my daughter saw a page which meant nothing to her, once'.
<Kamion> I think any content reviewing team ought to conduct a survey of the available technologies and pick either one or a combination of the most appropriate
<bluefoxicy> now how do you clense the image of this guy's wide open ass from your brain.
<Kamion> I certainly don't think they should be writing a content filter from scratch; that's been done
<Kamion> they might want to optionally glue a couple together, and work with the relevant upstreams
<bluefoxicy> lifeless:  "My daughter saw a page with some girl sucking som eguy's dick. . . jimmy's mom called me up the next day. . . uhhh. . . "
<lifeless> Kamion: of course not.. but I'm not talking technology.
<bluefoxicy> "I explained it to her and told her not to until she was like, older. . . but she didn't listen. . . "
<Kamion> bluefoxicy: although images != text to some extent here
<bluefoxicy> Kamion:  true, but normally images are associated with text
<bluefoxicy> you'd expect to find porno on a porn site yes?  :)
<smurfix> Trying to solve social problems with technology is no fun.
<bluefoxicy> smurfix:  of course it isn't.
<lifeless> bluefoxicy: my god, you've got a low opinion of your daughter. in one shot, you're saying that shes sexually promiscuous, knows enough of whats going on that seeing a photo of a blowjob is all it takes to tip her over the edge..!!
<Kamion> lifeless: a content filtering team needs to talk technology though, and the people they choose to work with will be selected depending on what seems to be best
<bluefoxicy> smurfix:  but then again, you can't really explain a social problem can you :)
<smurfix> ... and I'd rather not start down that road in the first place.
<bluefoxicy> lifeless:  I don't have a daughter.
<smurfix> Well, I do. (More than one, in fact.)
<bluefoxicy> lifeless:  I'm just saying children are curious and do not have a full grasp on these things
<lifeless> bluefoxicy: you can't have it both ways.
<bluefoxicy> and most parents I don't expect to actually go through this with their kids.
<bluefoxicy> I understand cause and effect fairly well, considering I find it thrilling when i can manipulate somebody's thoughts and actions just by nudging them around
<smurfix> bluefoxicy: "cause and effect" is not nearly as simple
<Kamion> children are naturally sexually curious with or without the internet (if it weren't that, it'd be playground talk and swapped magazines), it's just a matter of what people blame
<lifeless> bluefoxicy: well, in your 'fail safe' mode, standard spammer tactics will get past text, and from what I recall image recognition is still pretty hit and miss. I'm damn sure I can make pages that you'd consider 'unsafe' that dansguardian will miss.
<smurfix> Young people *have* on occasion been looking at rotten.com with no lasting ill effect
<bluefoxicy> lifeless:  yeah, intentionally I bet you can
<Kamion> I think we need to recognise that content filters have no chance whatsoever of saving the world or children's souls; they're filling a demand, pure and simple.
<bluefoxicy> Kamion:  yes
<Kamion> And talk about how dreadful life would be without content filters inevitably misses the point.
<bluefoxicy> which is primarily my concern in the first place, why the hell am i arguing about children
<lifeless> bluefoxicy: if many folk use dansguardian, the folk that are a problem (that is primarily non-PICS advertising based sites) will resort to such tactics to get their sites past the filters.
<bluefoxicy> I've never used a damn content filter seriously, just poked with 'em.
<smurfix> bluefoxicy: you started it ... you explain it
<lifeless> the same as happens with spam.
<bluefoxicy> smurfix:  i'm confused already
<lifeless> Kamion: full ack.
<bluefoxicy> I didn't enter this conversation with a constructed argument
<smurfix> bluefoxicy: Good for you.
<Kamion> anyway, night all
<bluefoxicy> not about children anyway
<bluefoxicy> more about business
<lifeless> Kamion: night.
<bluefoxicy> http://article.gmane.org/gmane.linux.ubuntu.devel/2840
<lifeless> bluefoxicy: you posted that before.
<bluefoxicy> did you read it?
<lifeless> yes.
* smurfix needs to vanish for now
<bluefoxicy> ok then
<lifeless> its largely orthogonal to the discussion here.
<bluefoxicy> be.cause that's about all I intended to say.
<bluefoxicy> orthagonal
<bluefoxicy> orthogonal
<bluefoxicy> what the hell does geometry have to do with coherant thought
<bluefoxicy> ugh
<bluefoxicy> I told dad to get me beef lo mein
<bluefoxicy> and he got me beef and vegetable lo mein or something
<bluefoxicy> my stomach hurts  x.x
<crimsun> bluefoxicy: the other major definition of 'orthogonal' :)
<bluefoxicy> lifeless:  <@MadMethod> or... say that part of teaching responcibilty is keeping tabs on your children so that you can punish them thusly when they disobey.. dansguardian is capable of only logging naughty sites and not expliticly blocking
<bluefoxicy> lifeless:  does that work for you then?  :o
* lifeless shrugs
* bluefoxicy shrugs as well.
<thully> hi - does anyone know if Ubuntu does any special detection during the install to enable subpixel for LCDs?
<chrisa> By that do you mean subpixel rendering?
<thully> yes
<thully> I wondered what exactly it did to get the fonts how they are - hoary in particular, as for some reason hoary's fonts are superior to warty's
<crimsun> thully: X.Org's truetype module is more current; fontconfig is also configured differently, I presume.
<thully> so, is subpixel being enabled by default?  If so, for all machines or for only a few?
<crimsun> I haven't looked at the dexconf logic; daniels probably knows better.
<thully> IS this Ubuntu-specific, or is it in debian as well?
<crimsun> I presume it's currently matched for Ubuntu but easily set for Debian.
<daniels> xtt is deprecated in favour of freetype2
<crimsun> daniels: so just load "freetype", correct?
<daniels> crimsun: yeah
<thully> I'm wondering specifically if subpixel rendering is ever used in Ubuntu, and if so what triggers it's use
<crimsun> daniels: thanks.
<chrisa> thully: dpkg-reconfigure fontconfig, or check /etc/fonts/fonts.conf
<chrisa> make that local.conf
<thully> I've looked there - see nothing of subpixel being used under any circumstances - is it ever used in Ubuntu
<thully> when? under what circumstances?
<crimsun> give me 3 minutes to walk to another lab and I'll see.
<crimsun> well, upon inspection of local.conf on a machine that was upgraded from warty->hoary, neither subpixel nor autohinting are enabled
<crimsun> thully: did you upgrade to or install hoary directly?
<bluefoxicy> mmm autohinting
<thully> no - I installed hoary directly
<bluefoxicy> 5/3 3 5|
<bluefoxicy> nice.
<crimsun> welp, I suppose that leaves us with "it's enabled if the user runs dpkg-reconfigure"
<thully> so, in other words - it's not enabled by default?
<crimsun> not that I can see on my upgraded machines
<thully> Because, I installed hoary clean on a laptop and had clean fonts with no miscoloring by defaultn 
<daniels> i believe sub-pixel hinting is enabled per default
<daniels> on laptops
<daniels> but I could be wrong.
<thully> I wonder how it is done, though?
<daniels> what do you mean?
<fabbione> morning 
<thully> how is it detected
<daniels> thully: laptop-detect
<thully> I wonder if it is 1)run laptop-detect 2) if is a laptop is true, install local.conf w/subpixel, etc 3) if laptop is not true, do nothing
<daniels> that's certainly how it used to work
<thully> how does it work now?
<daniels> yes, that is exactly how it still works
<thully> OK - thanks
<thully> One more question - I think I'm not going to continue running hoary, but I've reported some bugs involving hoary.  How do I make it clear on these bugs that I can't provide further feedback?
<fabbione> daniels: back in au?
<daniels> fabbione: yo dude, yeah
<daniels> fabbione: how's things?
<fabbione> daniels: could be better
<crimsun> feeling better, fabbione?
<fabbione> crimsun: yeah
<crimsun> excellent.
<fabbione> i think i am just getting older
<fabbione> yesterday i woke up that i couldn't move my neck at all
<crimsun> damn
<fabbione> today is a bit better
<crimsun> :)  let's hope for a speed recovery
<fabbione> well yeah
<fabbione> i am tired of spending my time in bed
<crimsun> I can imagine that would become old rather quickly
<crimsun> got wireless?
<fabbione> yeah
<daniels> fabbione: ugh :\ yeah, hope you get better soon
<fabbione> daniels: it sucks to be me :-)
<fabbione> daniels: are you up to prepare a new l-k-r-m for 2.6.10 (tomorrow.. not now ;))
<daniels> fabbione: yeah, sure
<fabbione> afaik 6629 from nvidia doesn't build on 2.6.10
<fabbione> so they will never be done ;)
<fabbione> ops
<crimsun> this url is useful then: http://sh.nu/t/5hucy
<crimsun> (RE: Nvidia & 2.6.10)
<daniels> heh
<daniels> cheers :)
<crimsun> :)
<daniels> seeeeeebbbbbbbb
<sjoerd> poor seb
<Treenaks> sjoerd: he deserves it ;)
<sjoerd> watch out of you might deserve the ``wrath of seb'' in the future :)
<fabbione> don't even think about touching our seb!
<fabbione> or you will be damned forever
<daniels> i just want to bitch at him about gtk :)
<fabbione> oh you mean that kernel core dump?
<fabbione> yeah it has to be a gtk bug
<daniels> clearly :)
<fabbione> actually
<fabbione> there is a gtk bug in the kernel :-)
<fabbione> #5029
<fabbione> = segfault
<mjg59> daniels: Is there any sane way to hook xresconf into the thing that munges the video BIOS for i855 systems with weird layouts?
<fabbione> hey mjg59 
<mjg59> Hi
<daniels> mjg59: 855patch/855wrap/whatever?  dunno
<mjg59> daniels: What happens if you run xresprobe on one of those machines?
<bob2`> apache2 sucks because it gets very confused by large files
<bob2`> that is all
<daniels> mjg59: it will report the size of the panel
<daniels> mjg59: afaik
<daniels> mjg59: or maybe it will just report 1024x768
<daniels> i actually don't know
<daniels> does anyone here own a machine with one of the wacky 16:9 LCDs?
* Riddell pokes sladen's libretto
<mjg59> edd has one
<mjg59> It needs to be one of the ones without the native resolution in the BIOS, though
<bob2`> does the livecd have whatever tool you need said 16:9 owner to run?
<daniels> mjg59: yeah
<daniels> bob2: nope, just xresprobe; it's an install system thing
<bob2`> ah, dang
<mjg59> Problem is, we need to run the 855resolution thing on resume
<mjg59> And it would be nice if it could be run in install, too
<bob2`> hrm, evolution doesn't actually seem to let you specify a port for an imap server
<mjg59> Put :foo after the hostname
<bob2`> tried that, seems to not be able to connect
<mjg59> Hrm. Weird.
<bob2`> ah, my fault
<trulux> hey pitti
<daniels> mjg59: oh christ
<daniels> mjg59: this is why I hate 855*
<daniels> mjg59: problem is, which one to run and with which options is utterly indeterminate
<pitti> Hi trulux 
<pitti> trulux: btw, I'm currently compiling 2.6.10-grsecurity :-)
<trulux> pitti, nice
<sladen> Riddell: libretto...  mmm, 
<sladen> Riddell: 800x480, trouble is, the in-chipset magic describes the LCD as being 800x600
<daniels> sladen: oooh.  so xresprobe i810 reports it being as 800x600?
<sladen> it's a neomagic.  Haven't tried it recently---it's in London and I'm in Nottingham
<daniels> ahr, neomagic
<sladen> daniels: lack of anything except PCMCIA and no PXE makes installing Ubuntu somewhat fun
<daniels> heh, whoops.
<sladen> daniels: what happened to your leet bootspeed magic.  I'm playing with ACPI and the continual rebooting-after-lockup could do with a speed boost
<daniels> sladen: the xorg stuff is in there, gdm is waiting for me to return from holiday
<daniels> anyway, got to run now
<daniels> bbl
* sladen needs a PCMCIA card with a PXE bootrom on it
<mjg59> daniels: The alternative is to package 855resolution, add a config file somewhere, get users to configure it manually and then use that on the resume pathway
<daniels> mjg59: true.  i could do that.
<daniels> maybe I could package it with vbetool ;)
* Treenaks prods kernel people with 2312
<Treenaks> #2312 even
<mjg59> Treenaks: Are you sure the card supports channel 13?
<mjg59> Sounds like a firmware issue rather than a driver one
<Treenaks> mjg59: yes
<Treenaks> mjg59: in windows the same card works fine (someone else's machine)
<Treenaks> mjg59: also, it shows up on scans
<mjg59> Ah. Possibly the included firmware won't work on channel 13?
<Treenaks> US vs EU firmware?
<mjg59> It could be european firmware
<mjg59> Yeah
<Treenaks> hm
<Treenaks> that'd suck :)
<Keybuk> isn't EU firmware the one that works on more channels?
<mjg59> It might be possible to extract the firmware from the windows drivers
<Treenaks> Keybuk: EU has 2 more channels (12, 13)
<Treenaks> it works fine on my other (atmel_cs) card
<Treenaks> (by that card needs an iwpriv call)
<Keybuk> yeah, sounds right; I remember a friend having an EU AP and wondering why his card couldn't see it (wrong channel)
<Treenaks> by=but
<Treenaks> yay.. more people with the bug: http://prism54.org/forums/viewtopic.php?t=652
<mako> jdub: for you: http://mako.yukidoke.org/copyrighteous/reflections/20050102-00
<sladen> mjg59: can you add to your wishlist, turning the fans up to maximum during hibernate (to get rid of excess heat)
<Keybuk> any particular reason?
<pitti> seb128: Hi, happy new year 2005!
<seb128> hey ! Happy new year :)
<pitti> seb128: btw, do you have any idea why the clock applet crashes and doesn't start any more?
<seb128> could you start /usr/lib/gnome-panel/clock-applet in a gt
<seb128> then add the applet to the panel
<seb128> and look on the log in the gt
<pitti> ah
<pitti> /usr/lib/gnome-panel/clock-applet: error while loading shared libraries: libplds4.so: cannot open shared object file: No such file or directory
<seb128> that's it :)
<pitti> seb128: a dependency problem?
<seb128> mozilla-firefox: /usr/lib/mozilla-firefox/libplds4.so
<seb128> hum
<seb128> WTF
<pitti> /usr/lib/openoffice/program/libplds4.so
<seb128> libnspr4: /usr/lib/libplds4.so
<_rene_> and mozilla should have too
<pitti> seb128: I don't have this package
<seb128> install libnspr4 ?
<pitti> seb128: that should be a dependency then
<seb128> yep
<pitti> seb128: I use to keep my system clean with deborphan :-)
<seb128> dunno why it's not automagically added
<pitti> seb128: shall I file a bug?
<_rene_> because it has no shlibs beacause its versioning is broken I guess
<seb128> $ ldd /usr/lib/gnome-panel/clock-applet | grep libplds4
<seb128>         libplds4.so => /usr/lib/libplds4.so (0xb72e2000)
<pitti> seb128: btw, what does it do with the netscape library anyway? sounds a bit odd...
<seb128> _rene_: ? I thought it was doing a ldd and a query on each dep to know the Depends
<_rene_> seb128: yes, and what does it do when there's no .shlibs?
<_rene_> seb128: just add it?
<pitti> I think it uses shlibs files
<seb128> pitti: good question, let me ask
<seb128> _rene_: why does it need a shlibs ? I mean ldd, dpkg -S ... no need of a shlib to get this 
<_rene_> dpkg-shlibdeps gets its infos from .shlibs
<_rene_> no idea what it does if there isn't one
<pitti> seb128: installing the package helps btw, clock works again. thanks
<_rene_> and since libnspr4 is a mozilla library it is broken
<_rene_> not correctly versioned, yada, yada
<pitti> seb128, _rene_: it uses shlibs file to get the package version dependency right
<pitti> seb128, _rene_: ldd does not tell you which version of a library package you have to depend on
<seb128> yeah, but no version should -> no versionned depends
<seb128> but still a depends
<seb128> BTW that's probably a depends due to evolution-data-server
<seb128> pitti: please fill a bug as reminder, thanks
<pitti> seb128: I'll do
<pitti> seb128: #5135
<seb128> ok
* sivang is wondering who should get the copyright for the ubuntu documentation produced by the ubuntu documentation project/team. Does canonical want copyrights over it?
<sivang> we are polishing some build and source files so it would be good to know...
<wasabi_> So, I was pondering ways to deploy do corporate deployment of updates with Ubuntu... in a nice, UI, PHB friendly manner.
<wasabi_> s/do//
<wasabi_> actually that entire sentence sucks.
<wasabi_> Do most people just make their own archive mirror, and copy packages from main over into it as they are 'tested'?
<wasabi_> Sounds like a waste of space. =(
<trulux> pitti, SELinux is now updated for 2.4.28
<trulux> i've backported it
<trulux> ;-)
<wasabi> so who knows a lot about apt authentication?
<pitti> wasabi: mvo
<pitti> wasabi: and mdz
<pitti> trulux: nice
<pitti> trulux: so you enhanced your kernel hack skills now? :-)
<trulux> pitti, seems working out-the-box
<trulux> a bit ;D
<pitti> trulux: I still compile my third grsec attempt
<trulux> what's up with it?
<pitti> trulux: my previous package does not work really good
<trulux> tell me about it
<pitti> trulux: I compiled in chroot restrictions, but that gives a lot of errors
<pitti> trulux: I think that it clashes with the initrd
<pitti> trulux: because the initrd chroots the actual system (I suppose)
<pitti> trulux: I get a lot of "linking foo to bar denied" errors
<pitti> trulux: and the framebuffer does not work (normal vga works, however)
<trulux> umm, have you enabled linking restrictions? fifo restrictions? symlink-hardlink restrictions?
<trulux> pitti, tell me the steps to reproduce it
<trulux> i would try to test my new skills ;)
<pitti> I disabled linking restrictions again in the 2nd attempt, but that did not help
<pitti> I still have fifo
<pitti> now I completely disabled chroot restrictions for testing
<pitti> if that still does not work, I will cry out for help :-)
<trulux> ok
<pitti> probably I will just drop the initrd, I don't like initrds anyway
<trulux> i'm preparing the tissues
<trulux> initrd sux
<pitti> my very first custom kernel (without initrd) works perfectly
<pitti> even with linking restrictions
<wasabi> am i the only one who thinks initrd is badass?
<pitti> so I suppose the initrd's chrooting makes trouble
<tseng> there are issues with the currecnt 2.6.10 pax rcs and smp
<pitti> wasabi: no, I don't like it either
<crimsun> wasabi: I like them. I used to despise them.
<wasabi> bad ass = good
<pitti> wasabi: oh, sorry
<tseng> just fyi.
<trulux> pitti, it's quite possible
<pitti> wasabi: what is good about an initrd?
<wasabi> I think it's a very elegant way to solve the problem... actually.
<pitti> wasabi: which problem?
<wasabi> dynamic kernel modules for automatically detected devices.
<wasabi> like, my raid card.
<trulux> tseng, like openbsd smp ones?
* trulux grins evily
<tseng> trulux: ...
<trulux> i was kjust joking
<trulux> no net-offense
<trulux> :D
<tseng> tere is a pax bug with kernexec on smp in the 2.6.10 patches, has 0 to do with openbsd or their immature smp support
<wasabi> pitti, it allows for the (not yet used apparently) scenario of third party ISV's distributing kernel modules for impoirtant boot devices (raid cards) without recompiling the kernel.
<pitti> wasabi: hmm, okay
<pitti> wasabi: for me it only loads the relevant root fs driver
<wasabi> What if your root fs driver wasn't in Linus' tree
<pitti> wasabi: but root fs drivers (including raid) can just be compiled in statically, not?
<pitti> wasabi: yes, that's a point
<wasabi> Well, that's the scenario I just laid out. WHen you can't compile it in.
<wasabi> Like, you know, every other OS in the world.
<wasabi> Windows, OS X, etc.
<wasabi> We've done pretty well not worrying about that so far though.
<wasabi> Anyway, the ISV simply has to package his module up, provide a .deb for it, that rebuilds the initrd.
<wasabi> Of course, that's impossible for other reasons. :0  (no stable module interface)
<pitti> Hi mdz_!
<trulux> hey mdz_
<mdz_> good morning
<seb128> hello mdz
<lifeless> morning y'all
<wasabi> i think i found my killer mono app. muhaha.
<pitti> lifeless: buhuu! Do you have a minute to help me with a baz problem?
<pitti> $ baz commit
<pitti> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<pitti> $ baz lock-revision -b pkg-postgresql-private@lists.alioth.debian.org--2005/postgresql--devel--8.0--patch-2
<pitti> lock-revision: illegal lock state for pkg-postgresql-private@lists.alioth.debian.org--2005/postgresql--devel--8.0--patch-2
<pitti>   consult an admin or arch expert (this shouldn't happen)
<lifeless> funky cool.
<lifeless> try
<pitti> lifeless: there is no ++lock-revision directory in the archive
<lifeless> oh, someone was fiddling then.
<lifeless> probably someone committed a patch 3 and manually removed it.
<pitti> only a directory ++revision-lock-held--patch-2--martin@piware.de--2dade7a66e1cd in the version directory (not in a patch-XX dir)
<Keybuk> right, I've had a bottle of nice wine, time to play with dpkg :o)
<lifeless> oh, ok thats alright then.
<lifeless> still unusual.
<Keybuk> wasabi: which?
<lifeless> mv  ++revision-lock-held--patch-2--martin@piware.de--2dade7a66e1cd to patch-2/++revision-lock
<wasabi> Keybuk, making it.
<pitti> lifeless: done; now: arch_commit: unable to acquire revision lock (lock held or revision already committed)
<wasabi> Keybuk, an XSP application to partially mirror an apt repository, allowing the admin to approve or disprove specific updates.
<pitti> lifeless: again, this ++revision-lock-held--patch2... dir was created again
<wasabi> With a pretty interface and stuff.
<lifeless> pitti: check the permissions
<lifeless> do you have the ability to mkdir patch-3 ?
<Keybuk> wasabi: oh right; mine's tomboy
<pitti> lifeless: the moved dir in patch-2 was removed entirely
<mdz_> mjg59: what is supposed to happen with the clock when restoring from swsusp?
<pitti> lifeless: yes
<mdz_> on my T42 it seems to be the same as when it went to sleep, and needs to be reset
<lifeless> pitti: actually it was renamed into the ++revision-held--...
<lifeless> pitti: ok, lets clean this up to be 100% sure.
<lifeless> remove the ++revision-lock-held dir tree
<pitti> I removed patch-3 again
<pitti> done
<lifeless> mkdir a ++revision-lock dir under patch-2, mod 755
<lifeless> under that, make a +contents dir, mod 755
<pitti> done
<lifeless> is this local or on alioth ?
<pitti> costa :-)
<pitti> yes, alioth
<lifeless> yah yah.
<lifeless> ok, so you have an sftp registration for the archive ...
<pitti> yep
<lifeless> do you have a revision library? and do you have an arch cache ?
<pitti> neither
<lifeless> ok.
<lifeless> in your working tree, ls {arch}/++pristine-trees
<pitti> I just committed into the 7.4 archive, that worked fine, bTW
<pitti> this is the 8.0 branch
<pitti> martin@donald:~/debian/psql8$ ls \{arch\}/++pristine-trees/
<pitti> unlocked
<lifeless> ls unlocked
<pitti> $ ls \{arch\}/++pristine-trees/unlocked/postgresql/postgresql--devel/postgresql--devel--8.0/pkg-postgresql-private@lists.alioth.debian.org--2005/postgresql--devel--8.0--patch-2/
<pitti> {arch}  postgresql8.0-7.9+8.0.0rc2
<pitti> (always just one dir below unlocked and further)
<lifeless> ok.
<lifeless> try the commit again.
<pitti> lifeless: worked fine now
<pitti> lifeless: now patch-3 exists and has a ++revisoin-lock subdir
* lifeless shrugs
<pitti> lifeless: so somehow it used the other lock directory method?
<lifeless> would love to know how it got wedged
<lifeless> there is no other lock directory method..
<pitti> I did not touch the repo recently
<lifeless> pitti: I believe you.
<pitti> and there is no sign that oliver did
<pitti> however, I recently moved around some stuff
<pitti> well, if I ever encounter it again, I tar it up
<lifeless> that would be great.
<pitti> cool, thanks
<pitti> I will test my new grsec kernel now and go to bed then
<pitti> Have a good night everybody!
<lifeless> np. have fun
<zul> night pitti
<trulux> pitti, it's urgent for me to find a good docbook wysiwyg editor, any idea?
<pitti> no idea
<lifeless> conglomerate
<zul> trulux: http://wiki.docbook.org/topic/DocBookAuthoringTools
<trulux> zul, thanks
<zul> np
<trulux> zul, Lyx looks weird on my ubuntu warty
<zul> trulux: havent tried it
<zul> been fighting to re-install my system all weekend
<trulux> :( sounds worst than having weird-looking fonts in Latex docs
<trulux> i'm installing a few xft fonts for lyx
<zul> yeah gave wife old hard drive bought shiny new hard drive for me
#ubuntu-devel 2005-01-14
<zul> almost there though
<srbaker> is adam di carlo a canonical employee?
<daniels> srbaker: no
<srbaker> know his irc nick?
<daniels> aph
<srbaker> oh
<Keybuk> what a random question
<__daniel> hai
<robertj> hi
<__daniel> maybe someone of you can point out my mistake, i'm trying to write a library (depends on glib) and i get: 
<__daniel> In file included from ../Data/data.h:25,
<__daniel>                  from main.h:25,
<__daniel>                  from main.c:21:
<__daniel> /usr/include/glib-2.0/glib.h:30:26: glib/galloca.h: No such file or directory
<__daniel> and i wonder, if there's something wrong with my system or me :-)
<crimsun> this is a user question, really
<__daniel> sorry crimsun
<crimsun> you have libglib2.0-dev, installed, right?
<__daniel> crimsun: yes and i see, it's my mistake, libgda (depending on glib too), builds fine
<__daniel> i'll have to review the makefiles and configure-scripts
<daniels> crimsun: you need to include $(pkg-config --cflags glib-2.0)
<__daniel> daniels: i already use PKG_CHECK_MODULES([PKG] , [glib-2.0] )           AC_SUBST([PKG_CFLAGS] )        AC_SUBST([PKG_LIBS] )
<daniels> __daniel: but do you do AM_CFLAGS = $(PKG_CFLAGS)?
<__daniel> daniels: and add PKG_LIBS to the Makefile.am 's "INCLUDE = "-section
<daniels> you need AM_CFLAGS = $(PKG_CFLAGS)
<__daniel> *REJOICE*
<__daniel> thanks alot, danisl
<__daniel> daniels
<__daniel> :-)
<daniels> no worries
<__daniel> daniels: spotting the "obvious" gave me quite some worries :-)
<robertj> your a daniel series model, you should upgrade your firmware to that running on daniels
<robertj>  /ctcp daniels version
<__daniel> robertj: i'm working on it
<Keybuk> how confusing
<Keybuk> the AC_SUBST bit is sucky
<__daniel> hmm, i don't know how to do better
<__daniel> good night
<thully> hi - does anyone here know where in Ubuntu is the setting to have subpixel rendering stored?
<daniels> /etc/fonts/local.conf
<thully> whether it's on or off is always stored there - what is changed for on vs. off?
<daniels> what?
<thully> is that where the detected subpixel setting is stored
<thully> The installer detects if it is running on a laptop, and then enables subpixel, correct?
<thully> What is done after that is detected?
<whiprush> <!-- Uncomment below to enable subpixel rendering -->
<whiprush> right below that
<thully> OK
<thully> So, why isn't the setting in GNOME turned on for subpixel by default?
<whiprush> probably because it looks like crap on CRTs I would imagine
<thully> Well, why isn't it turned on on laptops?
<thully> the GNOME subpixel setting, that is
<daniels> elmo_away: please sync docbook-xml
<thully> whiprush: what does your local.conf look like
<whiprush> it's commented out
<thully> what does the whole file look like?
<whiprush> sec
<whiprush> http://pastebin.arslinux.com/836
<whiprush> fresh install, so that's the default.
<Kamion> (minor pedantry: the installer doesn't detect laptops, the X maintainer scripts do)
<thully> what scripts would these be?
<thully> I see -I'm on a laptop - that line is not commented out for me
<Kamion> xserver-xfree86.{config,postinst} for Warty, xserver-xorg.{config,postinst} for Hoary
<thully> OK
<Kamion> they live in /var/lib/dpkg/info
<thully> So, how come GNOME has subpixel rendered fonts if the option isn't enabled in GNOME by default?
<Kamion> I tell a lie, it's /var/lib/dpkg/info/fontconfig.{config,postinst}
<Kamion> there is no one "default", it depends on your hardware
<Kamion> whiprush's paste is evidently from a non-laptop install
<thully> I know - why then, on laptops, is the GNOME subpixel option not ON by default
<whiprush> yes, my desktop
<Kamion> I have absolutely no clue. Is that a non-fontconfig thing (and if so, why on earth ...?)
<Kamion> ?
<thully> yes - in GNOME fonts control panel applet
<Kamion> shrug, bug
<whiprush> and, that paragraph is uncommented on my laptop, so that makes sense.
<Kamion> I guess
<whiprush> didn't know it did that, cool.
<daniels> oh my god
<daniels> the original iMacs report full EDID information through OF
<daniels> but they're actually DDC-incapable
<daniels> it's just hardcoded into OpenFirmware
<Kamion> one hardware platform ... :)
<daniels> WHY ARE ALL THESE STUPID CORNER CASES APPLE?!?
<thully> does this do anything (the font setting in GNOME)
<Kamion> haven't the foggiest, you could try it and see :)
* Kamion not desktop type, just replying to exonerate the installer :)
<whiprush> daniels: btw I upgraded to 2.6.10 and now lid-closing suspend to ram broke on my x40.
<Kamion> thully: by the way, I'm doing a big rearrangement of how the installer's timezone stuff works for other reasons, that should have the indirect effect of fixing your weird timezone bug
<thully> because curiously, on a standard Debian system, I have these same font config files w/KDE and I have to turn on subpixel specifically in KDE to have subpixel rendered fonts
<Kamion> at least I hope so ... if not everything is far too weird
<daniels> whiprush: gnar.  i'm still on 2.6.8.1, tbh.
<thully> Are the suspend scripts in Ubuntu's main archive yet - or do you still have to add mjg59's source to it - I've been running debian for a while, so I don't know myself
<daniels> thully: not in the archive yet, i've been on holiday
<whiprush> daniels: disregard, only when docked.
<thully> I've seen some info about a Kubuntu project (Ubuntu w/KDE) - where do you get the KDE packages to test for this?  Is this an official Ubuntu project or not?
<daniels> whiprush: ah yeah, the dock is, um, problematic
<daniels> thully: it's in hoary.
<whiprush> yeah I noticed. :-/
<Kamion> thully: #kubuntu
<thully> daniels: kubuntu is in hoary?
<Kamion> the Kubuntu guys are currently doing their work in the Ubuntu repository
<daniels> thully: as Kamion said, #kubuntu
<daniels> thully: (and please note that this is a development channel)
<thully> what's the exact definition of "development" in this case?  I thought my questions fit this definition.
<Kamion> most were, but "where do I get such-and-such packages" clearly isn't
<thully> well - it's a new, testing type thing - so I thought I'd ask here
<Kamion> thully: this channel's really for contributions to the development process, rather than support for developmental code
<Kamion> it's our primary work channel
<Kamion> not personal, it's just an attempt to keep work channels fairly clear for talk about active development work; not that there's much of that going on at the moment since it's vacation time for many people :)
<Kamion> anyhow, bedtime ...
<daniels> night dude
<bob2> jdub: http://sablevm.org/wiki/Eclipse
<bluefoxicy> hey
<bluefoxicy> can http://archive.ubuntu.com/ubuntu/dists/ have a symlink current* -> warty*, devel* -> hoary*?
<bluefoxicy> then I wouldn't have to mess with sources.list (neither would confused n00bs who would rather pay the kid next door to do it)
<fabbione> morning
<fabbione> doko:
<fabbione>  did the last python2.4 upload fixed the install problem?
<doko> which install problem? the module dependencies are fixed.
<fabbione> Setting up python2.4 (2.4-2ubuntu4) ...
<fabbione> 'import site' failed; use -v for traceback
<fabbione> Traceback (most recent call last):
<fabbione>   File "/usr/lib/python2.4/compileall.py", line 15, in ?
<fabbione>     import os
<fabbione>   File "/usr/lib/python2.4/os.py", line 397, in ?
<fabbione>     import UserDict
<fabbione> ImportError: No module named UserDict
<fabbione> dpkg: error processing python2.4 (--configure):
<fabbione>  subprocess post-installation script returned error exit status 1
<fabbione> this is on a clean chroot
<fabbione> that is version ubuntu4 
<doko> ubuntu5 is the current and should have fixed that.
<fabbione> goody
<fabbione> i still hva eto build ubuntu5
<fabbione> amen
<fabbione> have to
<fabbione> but i didn't want to push back 30 packages ;)
<doko> btw, I now have a powerpc biarch gcc-4.0, which whould work, but needs a powerpc64 glibc to build. so it's enough for kernel experiments, if you can install it somewhere ...
<fabbione> doko: cool
<fabbione> where is it?
<fabbione> no.. let's make it simpler
<fabbione> mail elmo and me :-)
<fabbione> so we can prepare a chroot specifically for it
<doko> ok, will do.
<fabbione> doko: perhpas... you might want to write in the main also where to grab what you already have?
<fabbione> humpf
<fabbione> what was the option in apt.conf to disable packages authentication?
<fabbione> found it
<jdub> whiprush: oh ars.linux, re: ubuntu... "The distribution is targeted squarely at the desktop"
<jdub> whiprush: gar. :-)
<fabbione> hey jdub 
<jdub> morning
<fabbione> jdub: somebody was wondering where is the artwork for Jan "only" 22 hours after midnight ;)
<jdub> :-)
<Treenaks> Wehr si teh nekkid pron artworkz?!!!!!1111oneoneone
<Treenaks> 8)
<pitti> Hi mvo!
<mvo> hi pitti 
<mvo> happy new year :)
<fabbione> hey pitti
<pitti> mvo: Gesundes neues! :-)
<fabbione> hi mvo
<mvo> hi fabbione!
<pitti> Morning fabbione 
<mvo> how is 2.6.10 doing :p ?
* Treenaks wanders off to stand behind the fire-proof blast doors
<fabbione> n/me sets mvo on fire
* mvo burns
<fabbione> argh
<fabbione> i dunno
<fabbione> test it
<fabbione> and let me know
<fabbione> it works for me
<mvo> :)
<fabbione> that means that it can be the default kernel for Hoary
<fabbione> ;)
<mvo> lol
<mvo> so the kernel for hoary is ready ... let's release
<fabbione> exactly
<fabbione> my god...
<Treenaks> ?
<fabbione> 2 hours and i am still catchinig up on emails
<crimsun> (I'm just waiting on a l-r-m-2.6.10-1-686-smp)
<crimsun> fabbione: 2.6.10-1-686-smp works fine on two hoary P4s at work
<fabbione> crimsun: thanks :-)
<fabbione> crimsun: daniels is working on l-r-m for 2.6.10
<pitti> Mithrandir: ping
<crimsun> fabbione: thanks.
<pitti> sjoerd: here?
<sjoerd> pitti: jep
<pitti> sjoerd: Happy new Year!
<sjoerd> thanks 
<sjoerd> same too you
<pitti> sjoerd: could you please have a look at https://bugzilla.ubuntulinux.org/show_bug.cgi?id=4767?
<pitti> sjoerd: (without the last question mark)
<sjoerd> hrm, my hack fails to work for him it seems
<pitti> sjoerd: what do you think about respecting camera.access_method ?
<sjoerd> it looks like it's not a ptp camera
<pitti> sjoerd: either ignore the value "storage" or only pop the dialog if the value is "user"?
<pitti> sjoerd: my camera has camera.access_method = "user"
<pitti> sjoerd: for now, ignoring "storage" seems safer to me
<Treenaks> sjoerd: my PTP camera (Canon Powershot A75) does not make g-v-m pop up for me either..
<sjoerd> Treenaks: that's another bug then :)
<Treenaks> sjoerd: my CF reader does, but gthumb can't cleanly import from CF into its nice 'yyyymmdd-hh.mm.ss' dir. structure
<Treenaks> sjoerd: I'll file one tonight
<sjoerd> Treenaks: check if the usb id's of your cam are mentioned in it's usermap
<sjoerd> Treenaks: please remind me tomorrow and we'll dig into your problem...
<Treenaks> sjoerd: OK
<sjoerd> aaaaaaaaargggggggggghhhhhhhhhh
<sjoerd> fucking stupid fdi files..
<sjoerd> pitti: we should stop shipping 20freedesktop/sony_dsc.fdi
<sjoerd> and then his problem will disappear
<sjoerd> those camera setting fdi's are useless anyway
<pitti> sjoerd: oh, right
<pitti> sjoerd: I thought we eliminated them all long ago...
* sjoerd too
<sjoerd> seems at least one slipped through
* pitti looks closer
<pitti> sjoerd: it seems that this is the last one
<pitti> sjoerd: will you do a new upload soon?
<sjoerd> yeah
<pitti> cool
<sjoerd> waiting for feedback from a bugreporter
<sjoerd> probably tomorrow
<pitti> brb
<sjoerd> pitti: just got feedback from the reporter i was wainig on.. So there will definitely be a new hal package tomorrow
<pitti> sjoerd: good to hear!
<jordi> yay for the utopia dudes
<jordi> sjoerd: did you see md's post in which he said "ooh, good I got howl installed"? :)
<sjoerd> yeah
<sjoerd> jordi: debian's gnome team rocks ;)
<jordi> yeah, THOSE DUDES KICK ASS
<jordi> :P
<sjoerd> just 4 more days and it'll be in testing \o/
<sjoerd> gotta go now, later
<Treenaks> sjoerd: 4 more months, more likely
<sjoerd> Treenaks: be in testing, not sarge release
* sjoerd afk
<pitti> Hi carlos! Happy new year!
<pitti> carlos: do you have time to attend the meeting tonight?
<carlos> pitti: hi!, same for you
<carlos> pitti: which meeting?
<mvo> hey carlos! happy new year
<carlos> hi * and happy new year * :-D
<carlos> robtaylor: ping?
<pitti> carlos: I thought there should be a Hoary status meeting today 2200 UTC
<mvo> i think it's tomorrow
<mvo> 4.1.2005 IIRC
<pitti> carlos: we still need lang pack integration and I think we need some feedback from Rosetta guys
<pitti> oops, if it is tomorrow, then fine
<carlos> yes, seems to be tomorrow
<carlos> pitti: ok, will be there
<carlos> 22:00 UTC?
<pitti> carlos: yes, tomorrow
* carlos adds it to his calendar
<Treenaks> there needs to be an ubuntu webcalendar thing...
<Treenaks> loadable in evo
<jordi> what's the January pr0n like?
<jordi> I haven't seen it yet.
<carlos> jordi: I think it's not yet released :-P
<jordi> bleh
<jordi> JANUARY 3RD AND NO PR0N YET
<jordi> I fear it will be MALE PRON
<bob2> jeff is the pr0n meister now
<Treenaks> jordi: I can show you Bandwidth Man, but you'd have to poke your eyes out with blunt rusty spoons and clean the sockets with acid
<Treenaks> jordi: after that
<jordi> Bandwidth man.
<jordi> Is that the next chapter of goatse, tubegirl and "DontLookAtThis"?
<Treenaks> jordi: uh.. not officially
<bob2> bandwidth man is Treenaks in lycra???
<Treenaks> bob2: no.
<bob2> so, yeah
<bob2> don't ask Treenaks for the url of the bandwidth guy
<Treenaks> I won't give it!
<bob2> good!
<bob2> unless you want to start a derivative distribution called Intimidatinguntu
<jordi> Bandwidth guy IS intimidating.
<Treenaks> bob2: only difference: -artwork packages ?
<fabbione> hey d3vic3 
<bob2> hah
<d3vic3> lo fabbione
<pitti> yay
<pitti> Linux donald 2.6.10-hardened #1
<pitti> the first version that actually boots
<mdz> morning
<mvo> good morning mdz 
<lupusBE> seb128: about http://bugzilla.ubuntu.com/show_bug.cgi?id=2749 should I open an enhancement request on gnome-vfs then?
<mdz> so wet here
<pitti> Hi mdz 
<seb128> hey mdz 
<mdz> fabbione: how are you feeling about 2.6.10?
<mdz> the new ipw2200 driver seems much happier on my laptop
<seb128> lupusBE: lemme check, but I think that gnomevfs guys know about it
<lupusBE> k
<pitti> fabbione: 2.6.10 runs fine for me, too
<fabbione> hey mdz
<fabbione> mdz: i only had one not-so-good thing on my laptop.. i am trying to see if it happens again.. otherwise i am fine with it
<fabbione> mdz: but i would definetely wait to make it the default kernel
<mdz> going to upgrade the desktops now that I am home again
<fabbione> i read a couple of scary story on LKML
<Treenaks> fabbione: scary in what way?
<fabbione> scary on ext3+lvm2+raid5 = dataloss
<fabbione> but only one person has been reporting it
<fabbione> so when i read stuff like that i tend to wait a few days to see if anybody has the same problem
<Treenaks> hm.. glad I'm not using lvm2 then
<fabbione> i use all that stuff
<fabbione> not a problem yet
<lupusBE> daniels you killed all my enhancement requests :p
<mdz> bear in mind that upstream version freeze is very close
<mdz> so we'll need to make a decision on whether to go with 2.6.10 as default
<fabbione> mdz: i know that.
<fabbione> mdz: we have still 2 days to decide
<fabbione> but the point is that to make 2.6.10 by deafult it means also testing d-i
<fabbione> if that's not an issue for you (to switch it later)
<lupusBE> daniels: are you sure that no manufactures is using those hid settings for there keyboards
<fabbione> gimme these 2 days to see if there is any other weird report
<lupusBE> s/is/are
<Treenaks> lupusBE: hid settings for keyboards?
<mdz> has elmo been around recently?
<fabbione> mdz: i saw him the 30th
<fabbione> today is free in UK
<lupusBE> Treenaks: http://lists.freedesktop.org/pipermail/xorg/2004-August/002472.html
<lupusBE> really pisses me off 
<lupusBE> that they don't use it
<Treenaks> lupusBE: I've tried 5 USB keyboards, all report "00: Unknown" for that value (lsusb -v shows it)
<mdz> fabbione: yes, I know about today.  But I have been away for a few days, remember, and was wondering about that time
<fabbione> oh yeah
<daniels> lupusBE: yeah ... as you said in that post, no-one uses it
<daniels> so we can't detect it if there's nothing to detect
<lupusBE> pff really
<lupusBE> stupid manufactures
<lupusBE> create open source keyboard? :p
<Treenaks> lupusBE: not only USB keyboards are buggy in That Way.. lots of PCI cards have wrong subsystem IDs
<mdz>  As of midnight Saturday, downtown Los Angeles had received 13.53 inches of rain since July 1, according to Seto, who said the figure is 9.66 inches above normal for that area.
<mdz> if I go offline for an extended period, I have probably been washed away
* pitti fears about mdz drowning
<Treenaks> mdz: can you swim?
<pitti> mdz: we had a flood here two years ago; it wasn't funny
<mdz> yes, but my computers cannot
<Treenaks> mdz: teach them
<lupusBE> daniels and there is no way to motivate manufactures to use this function somehow
<daniels> lupusBE: not really, no
<daniels> mdz: yow. we had a night where we got 10x the average monthly rainfall in about 2 hours once; that was fun.
<daniels> they had to send boats down the eastern fwy to rescue people stuck in their cars
<mdz> The 5.55 inches of rain that fell in Los Angeles on Dec. 28 made that day -- last Tuesday -- the third-wettest since the Weather Service started keeping records in 1877
<bob2> wow
<mdz> it has been raining for several days consecutively; that never happens
* fabbione hands a swimming pool plastic duck to mdz
<mdz> anyway, going to bed (on the second floor)
<mdz> night all
<fabbione> night :-)
<seb128> 'night mdz 
<daniels> mdz: night dude
<daniels> seb128: how good are you with gtk's input method? :)
<daniels> seb128: i've been trying to add a compose sequence to gtk, but adding it to gtk_compose_map in gtk/gtkimcontextsimple.c doesn't seem to have done much good
<seb128> daniels: never played with that in fact
<daniels> (it's not work stuff, something I was doing when I was bored lastnight)
<bob2> xchat in ubuntu defaults to #ubuntu, not #debian, right?
<seb128> should yes
<seb128> why ?
<seb128> (should = that has been changed, but dunno if that works in hoary or is bugged)
<bob2> just checking
<cartman> I have a bug filed a week ago with a working patch
<cartman> how could I get it applied for Hoary?
<mvo> cartman: what bugnumber?
<cartman> mvo: 5095
* mvo checks
<cartman> I am testing the patch for a week here, working fine
<cartman> mvo: so?
<mvo> cartman: impatient, ey? ;) 
<cartman> yup :-)
<mvo> hehe, give me some time, I would like to know why python2.4 changes the semantics of http_open
<cartman> alright
<pitti> Hi ogra 
<pitti> ogra: btw, are you still interested in hwfu?
<pitti> brb
<pitti> seb128: can you tell me the page that shows the build/install status of all your debian packages? The one you showed me in Mataro?
<Treenaks> why aren't Debian and Ubuntu in this list: http://www.cve.mitre.org/compatible/organizations.html
<Treenaks> oh wait
<Treenaks> they're on the OTHER page
<seb128> pitti: http://people.debian.org/~igloo/status.php
<pitti> seb128: cool, thanks
<seb128> np
<cartman> anyone knows why grub is the default boot loader?
<seb128> why not ?
<cartman> it has problems with old bioses
<cartman> aka "Error 18"
<seb128> dunno about this, but grub is fine most of the time
<mvo__> cartman: check your bios hd settings 
<cartman> http://www.google.com/search?q=grub+Error+18&ie=UTF-8&oe=UTF-8
<cartman> google doesn't say so ;-)
<cartman> mvo: what part of bios settings?
<mvo> lba, chs
<cartman> wonder if I got those settings
<cartman> lilo has lba32
<cartman> grub needs that too :/
<cartman> mvo: and what am I looking for exactly?
<mvo> I saw this before on a bios that was not set to lba mode 
<cartman> "lba mode" let me search for that in bios settings
<cartman> brb
<abelli> jdub: ping
<whiprush> jdub: that wasn't me, I was on vacation, but I'll pass it on.
<cartman> mvo: its set to LBA in bios
<cartman> but also "Large" mode available as an option
<mvo> have you checked if it works with one of them? 
<pitti> carlos: when I want to import a pot file (and some existing translations) into Rosetta, what shall I do?
<cartman> nope
<cartman> mvo: how can I reinstall grub? I got lilo now
<Treenaks> cartman: grub-install
<Treenaks> cartman: and purge lilo once that works :)
<cartman> Treenaks: hmm is it auto? :)
<carlos> pitti: do you have the product created?
<Treenaks> cartman: grub-install has a man page :)
<cartman> Treenaks: I know :P
<pitti> carlos: not yet
<carlos> pitti: first create the product
<carlos> pitti: then, search that product from rosetta
<carlos> pitti: and it will let you upload a .pot file
<Treenaks> cartman: how about existing translations?
<pitti> carlos: ah, cool
<carlos> and finally, you need to upload one by one the .po files
<cartman> Treenaks: hmm? btw man grub-install doesn't tell about boot device
<pitti> Treenaks: stumbled about xchat's stupid autocompletion? :-)
<carlos> pitti: we are finishing a way to upload all at the same time
<Treenaks> pitti: no, irssi
<Treenaks> pitti: <Tab>
<carlos> pitti: but until that I could give you a cheat to do it with a script
<Treenaks> cartman: grub-install /dev/bootdevice ;)
<pitti> carlos: no worry, I want to import the pmount pot and just one po
<pitti> calc: I can do that by hand
<pitti> carlos: ^
<trulux> pitti, http://selinux.tuxedo-es.org/2.4-backport/
<carlos> ok
<pitti> calc: sorry, that wasn't for you
<Treenaks> carlos: you should really send everyone who has a project in rosetta a mail to upload the PO files as well or something
<Treenaks> carlos: None of them have uploaded Dutch translations :(
<carlos> Treenaks: are there translations into dutch for those projects?
<Treenaks> carlos: yes
<cartman> Treenaks: thanks, brb
<Treenaks> carlos: Dutch is pretty much complete for most projects
<carlos> Treenaks: I'm planning to add a note about uploading all po files to prevent it
<carlos> will send a request to the old imported projects
* daniels is deholidayed: 13:06 -!- Irssi: 3122 new messages in awaylog:
<Treenaks> carlos: I've seen the new translations from rosetta, and to be honest, they're crap compared to what's already in the .pos :)
<Treenaks> wb daniels
<pitti> carlos: I now have the product and uploaded the pot file
<pitti> carlos: how can I upload the po? This is not obvious
<pitti> carlos: ah, got it
<carlos> pitti: it's not too user friendly for the maintainers
<carlos> we are trying to improve it
<pitti> carlos: I uploaded the German po now
<pitti> carlos: I now wait for some minutes for it to appear
<carlos> it's there already
<cartman> ok grub sucks
<jordi> not :)
<cartman> well rather "lilo works , grub not"
<cartman> hmm new bittorrent pack on hoary
<cartman> mvo: thanks!
<Treenaks> at least it's not Cantorrent ;)
<cartman> now to report some unicode bugs ;-)
<Treenaks> yay for unicode bugs 8)
<cartman> :/
<mvo> cartman: np, thanks for reporting about the bittorrent problem
<cartman> np
<cartman> what package should I report a bug for "Can't use turkish characters in tty consoles"
<cartman> although $LANG is tr_TR.UTF-8
<Treenaks> console-sometihng?
<cartman> lemme see
<cartman> console-common maybe
<pitti> elmo: Hi! Happy new year
<pitti> elmo: can you please remove debstriptranslations from the archive?
<pitti> elmo: we now have pkgstriptranslations
<sivang> pitti: HI! Happy new year!
<elmo> pitti: done
<pitti> sivang: Hi! You too
<pitti> elmo: thanks
<pitti> brb, off to another new kernel test
* sivang waves to everybody
<ogra> hi sivang
<sivang> ogra: hi :)
<pitti> fabbione: are the kernel configs shipped somewhere in some package?
<pitti> fabbione: I did not find them, so right now I copy them from the linux-source package
<tseng> pitti: they get intsalled to /boot
<pitti> fabbione: but it could be nice to take your standard configs and just patch in my grsec variables
<pitti> tseng: no, I need all variants (k7, i386, etc.) at compile time
<tseng> hrm right
<tseng> id apt-get source a few, stuck on dialup =/
<pitti> tseng: i. e. on the buildds I want to take the config of the linux-source package, not the config of the host
<tseng> yep, i only build it for myself
<fabbione> Mithrandir: 5029.
<fabbione> it's 2 bugs in one
<fabbione> i have the gconfig (kernel side) fixed
<fabbione> but there is a qt/amd64 specific part that needs love
<seb128> fixed properly ? 
<fabbione> and you are in the position to fix/test it
<fabbione> seb128: i am using Kamion's patch
<seb128> you have icons in the toolbar ?
<Mithrandir> fabbione: I'm not near any amd64 box atm, and my DSL is _shitty_ here.
<seb128> the bar is empty here with the patch
<fabbione> seb128: ah....
<Mithrandir> fabbione: so if it could wait a week, it would be a lot better for me.
<fabbione> Mithrandir: i have no rush.. it's not a stopper or anything important
<Mithrandir> cool
<fabbione> seb128: if you can cook up a patch it is fine for me
<fabbione> i can push it upstream
<seb128> fabbione: first, does it work on your box ?
<seb128> and then, do we want to spend time to fix that properly ? I feel that's not a big deal and we should just wait for upstreams :p
<fabbione> seb128: well perhaps upstream did not notice...
<fabbione> how complex is it to fix?
<seb128> probably not really
<seb128> but still, there is a lot to do and that's better to put time in useful places
<fabbione> i agree...
<fabbione> it was more a nice to have it fixes
<fabbione> fixed even
<seb128> ok, use Kamion's patch for the moment, at least it doesn't crash
<seb128> I'll have a look to fix the rest a bit later and let you know
<fabbione> seb128: sighs.. i just killed it from the tree....
<fabbione> i will wait for a final patch
<fabbione> no point in having half fix
<fabbione> i can achive the same just commenting the code out :-)
<fabbione> and it will take less time to build :P
<robertj> has there been any talk about an esd => polypaudio transition?
<fabbione> robertj: yes. in mataro
<fabbione> during the last ubuntu conference
<fabbione> there are notes on the wiki
<seb128> fabbione: right :)
<robertj> I see it mentioend on DrainingTheLinuxAudioSwamp
<fabbione> robertj: we had a bof about audio and the notes should be there
<fabbione> if they are not you should probably ask jdub 
<Treenaks> DrainingTheLinuxAudioSwamp _are_ the BOF notes
<fabbione> mjg59: ping
<Yann2> hi 
<mvo> ping jamesh 
<ldng> Is that a bug or a feature that desintalling xscreensaver suppress the logout menu entry instead of the lock-screen menu entry ? O:-
<ldng> (hoary)
<seb128> fabbione: proper patch attached on #5029 for the gconfig issue, it fixes the crashes, the toolbar icons and the callback on the buttons
<fabbione> seb128: cool
<fabbione> too bad i uploaded -3 not too long ago
<seb128> as said before that's not a big issue, I'm not sure than a lot of people use make gconfig
<seb128> s/than/that/
<fabbione> yeah
* mvo__ test 2.6.10 now
<mvo> fabbione: 2.6.10 crashs in the fritz isdn module and after that in the floppy module :(
<mvo> (fritz is isdn)
<ogra> hmm, floppy works for me....didnt try isdn....
<mvo> floppy is probably just a side-effect after the isdn crash
<fabbione> mvo: ok. how does it crash? is that the misdn stuff?
<ogra> nope
<fabbione> mvo: do you have a kernel oops? can you run ksymoops on it?
<ogra> fritz is the old i4l module
<ogra> hisax to be exact....
<fabbione> hmmmm
<mvo> "unable to handle kernel paging request at virtual adress". it looks a lot like it's from avmfritz (mISDN)
<ogra> oh, avmfritz....sorry
<fabbione> mvo: i need details...
<fabbione> check dmesg or something
<fabbione>  /var/log/kern.log
<mvo> I can give you the complette crash traceback from kern.log
<mvo> should I open a bug about it and attach it to it?
<fabbione> mvo: + i need you to pass that to ksymoops
<fabbione> without ksymoops is useless
<pitti> mvo: AFAIU CD-based upgrades now work automatically?
<mvo> pitti: yes
<pitti> mvo: do you use the autorun feature for that?
<mvo> pitti: no, I hook into hal and look for cd-insert events
<pitti> mvo: ah cool. #1956 is still open and should eventually be discussed
<pitti> mvo: if autorun is not necessary for upgrades, we have one argument less for it
* mvo looks at the bug
<mvo> if upgrade-notifier is runing (that will be the default for hoary) we don't need autorun for upgrade
<mvo> we'll have to put a "upgrade.sh" script on the hoary cd to make it easy for warty users to upgrade 
<pitti> mvo: I just followed up on the bug
<pitti> mvo: this could still be executed with "sh /cdrom/upgrade.sh"
<pitti> mvo: since this probably needs sudo rights, I would cry if this was executed automatically
<mvo> sure :)
<mvo> if a ubuntu cd is found right now it will ask kindly if it can scan it and start the package manager
<seb128> lamont: hum about mono. http://people.ubuntu.com/~lamont/buildLogs/m/mcs/1.0.4-1/mcs_1.0.4-1_20041224-1957-i386-failed
<seb128> lamont: it depends on mono-assemblies-base which is a part of mcs  ... 
<fabbione> that has to be funny :-9
<lamont> seb128: right.  and I tried bootstrapping it and the compile failed with errors.
<lamont> thereby ending my effort.
<lamont> I could certainly take another run at it.
<seb128> have you planned to try again ?
<seb128> it's in debian, it should work for hoary too :p
<Treenaks> lamont: btw, when are you going to sign my key? :)
<lamont> "should" being the operative word...
<zul> lamont: see 5052
<lamont> Treenaks: once I dig out my pile of keys-to-sign
<Treenaks> lamont: ah, RSN ;)
<lamont> seb128: I'll stab it today
<seb128> thanks
<seb128> and for abiword, any idea of why there is no build log for 2.2.2-1ubuntu1 which has been uploaded like one week ago ?
<lamont> gnome/abiword_2.2.2-1ubuntu1: Dep-Wait by buildd+mcmurdo [optional:out-of-date] 
<lamont>   Dependencies: libnautilus2-dev
<seb128> ok, thanks
<lamont> see people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.i386
<seb128> oh, didn't know about this
<seb128> cool
<lamont> yeah, it's <distro>.<state>.<arch>, although all is everything, and therefore most interesting...
<seb128> grumpf
<seb128> my debian/control has no libnautilus2-dev reference
<seb128> grrrr, I've uploaded from the wrong dir ...
<lamont> it's quite possible that it's a stale dep-wait - if you need it cleared, just say so.
<seb128> oh
<seb128> yes please, 2.2.2-1 has this problem
<seb128> 1ubuntu1 was supposed to fix it
<lamont> seb128: ok
<lamont> btw, you know about gnome-doc-utils_0.1.1-0ubuntu1, yes?
<lamont> cleared
<seb128> 0.1.1-0ubuntu2 is in the archive for some hours
<lamont> figures
<lamont> I only see failures, not successes. :(
<fabbione> lamont: ehhee
<seb128> bah, that's not a bad thing if you don't want to be flooded :)
<lamont> seb128: yeah - but it makes stale failures more work to track if I'm not going to just report them (like I just did... )
<lamont> well, lightweight reporting
<sid77> hi
<lamont> fabbione: Kamion: the other task for the day is to get the cyclades hooked up, and configure a bounce host for you guys to come through
<mxpxpod> jdub: ping
<cartman> daniels: ping
<davyd_> kudos to whoever packaged yelp so quick
<davyd_> and built it with info support ;)
<kagou> hi
<sensebend> hi
<kagou> i'm playing with grub install problem on AMD64 :(  I don't understand why installer freeze, and under the console and after a chroot grub-install works ?!
<kagou> it(s very disapointed
<davyd_> I blame GRUB
<kagou> i'm searching how to finish properly the installation
* Treenaks blames Canada
* cartman suggests lilo
<ogra> kagou: as i asked in #ubuntu before (where this talk belongs btw) which filesystem do you use for the system partition ?
<kagou> ext3
<ogra> hmm, ok
<kagou> ogra, hd0,0 NTFS hd0,1 swap   hd0,2 ext3 on /   hd0,3 ext3 on /home
<zul> Treenaks, you only blame canada for corrupting america's youth
<sensebend> this is making me want to go and watch the southpark movie :)
<kagou> why grub-install is not the LAST thing managed by the installer ?
<kagou> how to properly finish the installation after grub crash
<davyd_> kagou: it's the last thing done before you have to reboot
<Treenaks> zul: only if cartman is here :)
<cartman> hmm?
<kagou> davyd_, mmmh are you sure ?
<davyd_> kagou: no
<kagou> :D locales are not configured before grub
<ogra> Treenaks: heh you scared him
<Treenaks> ogra: yeah, a Canadian came in and he leaves.. suspicious ;)
* Treenaks blames BradB 
<ogra> LOL
<ogra> Treenaks: if this works you are alone after 76 balmes ;)
<Treenaks> balmes?
<kagou> apt-get insatll mc
<Treenaks> oh blames
<Treenaks> kagou: wrong window ;)
<kagou> oups
<kagou> lol
<ogra> Treenaks: yeah, balmes....didnt you know ? .....
<kagou> Treenaks, wrong PC !!! ;)
<kagou> ++
* amu looks for tester's for the new liveCD http://source.rfc822.org/pub/local/gnoppix/gnoppix/beta/hoary_0.9.2b1-i386.iso
<mxpxpod> when are the boot time patches worked on at the conference going to be worked into hoary?
<amu> hmm guess they are right now in it. My Sys boots faster :) 
<mxpxpod> hmm
<mxpxpod> amu: i386?
<amu> yep
<mvo__> amu: I'm downloading, but it will take a while ...
<mxpxpod> I wonder if they've gotten to ppc yet
<mvo__> will probably test tomorrow
<ogra> mxpxpod: on my imac they werent (at least this weekend)
<mxpxpod> ogra: ok
<amu> mvo: thx
<mxpxpod> ogra: I figured as much since I just booted up about 3 hours ago and it was about the same as before
<ogra> so it looks like we have to wait for ppc.....
<mxpxpod> ogra: wonder why that is...
<fabbione> lamont: sounds good
<ogra> hmm, no idea, i had to switch my imac back to hoary anyway, because xorg didnt like it
<lamont> ogra: you mean to warty?
<mxpxpod> fabbione: ping
<ogra> lamont: no i meant from hoary *g* thanks
<fabbione> mxpxpod: i am here.. no need to ping
<lamont> ogra: ah
<fabbione> ogra: you can run xfree86 on hoary
<mxpxpod> fabbione: sorry... where's the ibook-g4 patch for the linux-source packages... you said you shipped it, but I can't find that
<fabbione> ogra: i did leave the xserver-xfree86 in hoary for these kind of problems
<ogra> fabbione: i know... but i wanted to help out daniels.....
<ogra> fabbione: i dont use the mac.....just for packaging.....
<fabbione> mxpxpod: the patch is in debian/patches. you need to add it to debian/patches/00list-<highest_num> and recompile
<fabbione> mxpxpod: using dpkg-buildpackage or whatever way you prefer
<ogra> fabbione: and it seems its got a serious prob with the monitor detection, so its a fine piece of crap to run tests.....
<mxpxpod> fabbione: I normally use make-kpkg
<fabbione> ogra: ah ok
<fabbione> mxpxpod: just build the kernel the same way you would build other packages
<fabbione> lamont: if you want me to get hppa kernel support for hoary we need to be very fast
<mxpxpod> fabbione: is that patch only in the 2.6.9 kernels?
<fabbione> lamont: specially if there is an external patch that needs to be added
<fabbione> mxpxpod: it's in both 2.6.9 and 2.6.10, but for the latter i didn't even have the time to check if it applies
<lamont> fabbione: hppa isn't ready, and probably won't be...
<mxpxpod> fabbione: ah, ok
<lamont> there certainly is an external pathc
<fabbione> lamont: ok. so we will defer hppa for hoary+1
<lamont> but gcc-3.x and db4.3 are ftbfs due to kernel/glibc issues
<lamont> otoh, I found some hoary bugs watching the builds run over the break
<mxpxpod> fabbione: so, I just get the source with apt-get source linux-image-blah and then dpkg-buildpackage -b -uc -us -rfakeroot?
<fabbione> lamont: ok....
<fabbione> mxpxpod: yes. apt-get source linux-source-2.6.9
<fabbione> edit debian/patches/00list-<blabla>
<fabbione> and add the name of the patch
<fabbione> and than build
<fabbione> brb
<mxpxpod> fabbione: thanks
<sivang> Anybody know when silbs will be back online? I have some trademark issues to discuss..
<fabbione> sivang: mostlikely tomorrow
<sivang> fabbione: k, thanks :)
<fabbione> np
<fabbione> elmo: are you anywhere around?
<srbaker> yo
<mdz> morning
<sivang> morning mdz
<ogra> [22:07:14]  <mdz> morning
<ogra> hmm
<ogra> morning :)
<mdz> morning (n.), the time when one arrives online
<sivang> ogra: I also have times when it's morning for me around 18:00 :)
<mako> does someone who has recieved their CDs have their package with them?
<sivang> mako: not me :)
<carlos> mako: I have it
<mako> carlos: you were high priority, right?
<carlos> I think so
<mako> carlos: i was too.. i think i'm looking for a normal order
<carlos> ok
<sivang> mako: any eta for the new shipment to arrive? 
<mako> i need to know where the cds appeared to be coming from
<mako> sivang: i dunno.. i sent the db last week
<sivang> mako: ok, I'll wait then again.
<mako> i need to fill out this slightly crazy invoice for maritius so the government there doesn't trash a few hundred unbuntu cds
<ogra> mdz: hmm, what does one say who never goes offline ?
<ogra> mako: wait a sec
<mako> i know basically nothing about this
<mako> the high priority orders only list the sender account and not the origination.. which is kind of weird
<ogra> got it here
<ogra> same for a ten cd bag....there is only my address
<carlos> mako: I have a field that says 'Canonical'
<carlos> mako: then the sender (MediaMotion)
<carlos> mako: and finally my address
* carlos -> dinner
<mako> yeah, but that's the sender, not the country of origen
<mako> ogra: so no address?
<mako> ogra: people said stuff about switzerland
<ogra> nope nothing....and mine came from belgium
<mako> dude, belgium, switzerland/netherlands
<mdz> mako: mine say Zurich
<abelli> ciao mako
<sensebend> mine was from the netherlands
<ogra> mako: www.grawert.net/030105%20005.jpg and www.grawert.net/030105%20006.jpg
<mdz> gah, my ubuntu-meta update script improvements got lost
<fabbione> mdz: blame gtk :P
<zul> or canada
<mako> jdub: do you know about optimystic ?
<mdz> fabbione: any luck reproducing that 2.6.10 problem you had?
<fabbione> mdz: no. i think it was just a lunar ray hitting the power cable on a mars eclipse
<mdz> I haven't yet rebooted my primary desktop to go to 2.6.10, but the other machines are running well with it
<fabbione> i think we can go 2.6.10 as default for hoary
<haggai> mdz: what did you do to fix the loopback+devmapper problem?
<mdz> haggai: un-broke it with respect to the 2.6 blockdev stuff
<haggai> mdz: so it was a devmapper bug?
<mdz> no
<mdz> cloop
<mdz> it basically didn't use the API properly
<haggai> ah. Well done for finding it
<mdz> fabbione: I think so, too
<ogra> fabbione: what was about the isdn stuff..... sorted out ? else i got a hoary 2.6.10 and a fritzcard here to test...
<fabbione> mdz: i would say we push it to default with the option to revert to 2.69 in case of a disaster
<fabbione> ogra: if you can test it would be nice. 
<mdz> ogra: mvo was looking into it
<fabbione> i didn't get anything from mvo
<fabbione> ogra: but having 2 reports is better than only one
<fabbione> specially to see if it is reproducible
<ogra> fabbione: hrm...grr...got the pci card in the office...only ISA here....so tomorrow, sorry
<fabbione> ogra.. dude.. i am not asking you to walk on water.. if you can it would be really nice.. otherwise i can wait
<ogra> fabbione: i will have it here tomorrow....
<fabbione> no problem.. even in 2 days from now
<fabbione> otherwise you will know the pleasure of pain from bottom up
<fabbione> MUHA MUHA MUHA
<ogra> hehe
<fabbione> well guys
<fabbione> i am heading to sleep
<fabbione> mdz: tomorrow 22:00 UTC confirmed?
<Yann2> hi :)
<fabbione> + 16:00 UTC????
<fabbione> mdz: you want me divorced even before getting married, don't you?
<Yann2> we've got a french forum/site, does anyone know a way to get it added to http://www.ubuntulinux.org/support/local or http://www.ubuntulinux.org/community/forums/ ?
<fabbione> night people
<ogra> night 
<mdz> fabbione: yes. I forgot that tech board would be the same day; that's unfortunate
<mdz> fabbione: you can skip tech board if it's problematic for you
<calc> gnome in hoary still seems a bit buggy wrt plugging usbkeys
<calc> the first time i plugged it in it was detected and showed an icon along with popping up the nautilus window, the second time only the window was popped up and there was no way to unmount it without sudo
* calc considers filing that as a bug, but its nots narrowed down very much :\
<mdz> calc: any plans to get the new libogg in soon?
<calc> i'll try to take a look at it later tonight
<mdz> calc: the fact that it wasn't unmountable I think is already filed as a bug; for some reason fam/gamin hold onto it, but only sometimes
<mdz> if an icon didn't appear, I haven't seen that before, and it should probably be filed
* sivang would like to bring the attention to a rather interesting fact. Did an upgrade using net, from warty release to hoary, used d-i to have both /home and / under lvm.  (on the dell laptop). After seemingly slow performance when firing up a lot of java apps, I realized the machine doesn't use a swap partiton although it existed. Something must have gone bad with the d-i setup. bug?
<mdz> sivang: existed before or after you partitioned the disk in d-i?
<mdz> unless you told d-i to use the swap partition, it won't be used
<sivang> mdz: existed before, and I told it to reuse it.
<sivang> mdz: that is, reassigned it's mount point as /swap etc..
<sivang> (in d-i)
<mdz>  /swap?
<mdz> I was fairly certain that swap devices were treated specially, and wouldn't have a mount point
<jdub> fabbione: 2.6.10 includes all our 2.6.9 patches?
<sivang> mdz: ssorry you're right , I just choose "use as swap"
<mdz> jdub: no, many of them were obsolete
<mdz> well, either way I interpret the question it's only half right :-)
<mdz> fabbione carried everything over, if that's what you mean
<jdub> heh
<mdz> some of it went upstream, others rediffed, others unmodified, etc.
<jdub> as long as the dsdt patch is there ;-)
<mdz> should be fully functional, except for restricted-modules
<jdub> sweet
<mdz> and that bit in the changelog
<mdz> where fabbione threatens your first born if you report a bug or something
<mdz>   * ATTENTION/WARNING/SOS/THE IF YOU OPEN A BUG ON THIS YOU WILL BURN ALIVE
<mdz>     ->>>>>> Disable emu10k1 build on ppc because it is broken <<<<<<-
<jdub> haha
* jdub is protected by having no ppc machine with pci slots-- oh, that's a lie. i do too.
<sivang> jdub: what about the israeli mailing list? ubuntu-il
<sivang> jdub: there is some people who want to go boom and start their own derived distro, also, doesn anyone know what is the state of the derivation tools?
<calc> mdz: ok
#ubuntu-devel 2005-01-15
<lamont> Kamion: you around?
<robtaylor_> mdz: how's the live-cd cloop fun coming on?
<mdz> robtaylor: I squashed the big bug in Mataro, and then more or less took a holiday since
<mdz> amu has been doing some work on it during that time
<mdz> gah, workrave is busted
<mdz> though it hasn't changed in forever
<jdodson> jdub: who do i talk to about being mentored for "package maintainer" status.  the wiki mentions that as a suggestion.
<jdub> jdodson: we haven't got a full-on mentorship program or anything, but you can always punt questions here while you're learning
<jdub> jdodson: a good place to start is the debian new manitainer guide and fixing bugs in universe packages you like
<jdodson> jdub: ok
<jdodson> jdub: i volunteer on the ubuntu forums and wanted to help out as a maintainer.   
<jdodson> jdub: thanks for the advice.
<jdodson> jdub: do you do much with the gnome foundation anymore?  slashdot noted you were not in the last round of elections for the foundation.
<jdub> i didn't run for election this year - i will write about that more at some stage.
<jdodson> jdub: thats cool, when they mentioned it on slashdot, i did a good search and found out you were working for ubuntu.  
<daniels> mdz: l-r-m is my first priority after xorg, so should be tomorrow by the time I've run it around all the buildds
<daniels> mdz: (i also have an engagement tonight, so losing a couple of hours off today, making it up tomorrow, so probably won't quite get to a new upstream l-r-m, especially as it needs patches for nvidia)
<mdz> daniels: great, thanks
* lamont ponders whether libatomic-ops should be set to i386 ia64 in PaS, or if  it makes sense to work on porting it to ppc/amd64
<daniels> lamont: can you please install a reasonable subset of build-depends on halley so I can get l-r-m on ia64 going?
<daniels> mdz: oh, that's right
<lamont> daniels: no
* lamont has no root on halley
<daniels> mdz: we'll have fglrx on amd64 soon enough, too
<daniels> elmo_away: ping
<lamont> libatomic-ops already has a patch in the bts for amd64 support... hrm.
<lamont> mono friends.. mcs is still ftbfs
<daniels> lamont: priority #6 or so
<lamont> daniels: yeah - there's a build log for it now, for those who might care to loo,
<lamont> k
<daniels> lamont: cheers
<daniels> lamont: so, with p.u.c/~lamont/daniels/, does xorg-6.8.1 contain the full build-tree?
<daniels> i.e. can I just grab the files I need from there instead of grabbing the diff?
<lamont> xorg-6.8.1 is the old one from ia64, IIRC
<daniels> ahr, ta
* lamont generates a diff
<lamont> people.ubuntu.com/~lamont/daniels/xorg_6.8.1-1ubuntu8.5.diff
<lamont> is only 44kb
<lamont> and is a diff -urN vs 1ubuntu8
<daniels> ahr, ta
* lamont needs to go buy a fan for his computer rack tonight
<mdz> lamont: what happened with alsa-driver?
<mdz> (and didn't this happen before?)
<lamont> before was a 'just use debian' that I can't see how I would have asked for
<lamont> this time, dunno - about to look at that
<lamont> as well as 72 MB of diffs
<daniels> mdz: btw, #2542 may never be solved
<daniels> mdz: unfortunately with most cards, you need to probe for their amount of video ram
<daniels> mdz: istr one ranging between 16 and 128MB with a single PCI ID
<mdz> has anyone seen thom around?
<mdz> daniels: probing for it would be no worse than what xresprobe already does
<daniels> mdz: dude
<daniels> mdz: probing for video RAM involves doing what the drivers do
<daniels> open()ing /dev/mem and poking at random bits
<Riddell> when running debuild -S on a package I get "cannot represent change to khtml/java/kjava.jar: binary file contents changed" is there a way to get round that?
<daniels> mdz: the problem isn't with newer cards, because they typically have one PCI ID per configuration, which includes video RAM
<daniels> Riddell: uuencode the new version, and unpack it over the top in your configure/build sequence, and either restore it or delete it in clean
<Riddell> daniels: that sounds a bit over-complex to me, I can't just tell it to ignore that binary file?
<daniels> Riddell: well, if you managed to do that, diff would ignore that binary file, and your changes would be lost
<daniels> how did you change it, anyway?
<Riddell> daniels: it's the konqueror java vulnerability, the updated kjava.jar file is from the "patch" (just a tarball) they made
<sladen> Riddell: unzip the new jar and the old jar and compare the contentses
<mdz> daniels: dude, xresprobe does this already
<mdz> it lets the X server do its driver-specific magic and munges the log file
<mdz> seems like the same could be done for video memory size
<Riddell> sladen: I have the .java sources, but the .jar file is kept in CVS (and hence this patch) to stop people needing the java compiler to make khtml
<daniels> mdz: it doesn't invoke the X server unconditionally, but I suppose it could be done, as much as I dislike the idea
<sivang> mdz: does it allow for detection of high refresh rates on capable devices?
<daniels> Riddell: right, so you need to uuencode it
<mdz> daniels: it would be nicer if the server itself would fall back more sanely
<daniels> sivang: that's already solved in xorg
<sivang> daniels: I never managed to get my display to do 100hz...
<daniels> mdz: well, it's trying its best to obey our command, to be fair
<daniels> sivang: then you probably need to enter your sync ranges manually, because your monitor is lying
<mdz> daniels: but we have to be way too specific in what we ask of it, IMHO
<daniels> sivang: either that, or lower your resolution a bit
<daniels> mdz: oh, agreed, the current infrastructure is total crap
<daniels> mdz: but pretty much the only way to properly fix it is to start from scratch; the entire server infrastructure is terminally broken
<mdz> calc: https://bugzilla.ubuntu.com/show_bug.cgi?id=4597
* lamont pukes at the alsa-driver upload
<sivang> lamont: that bad? :)
<lamont> sivang: I have NFC what drugs I was on when I did the upload
<lamont> mdz: alsa-driver_1.0.7-2ubuntu2 uploaded, mutes on stop
<mdz> lamont: does it also resurrect the patches which vanished?
<lamont> yes
<mdz> great, thanks
<mdz> lamont: was that an overlooked _dropped.patch or something?
<lamont> and kills the regressions that were in the patch
* lamont needs to not work on alsa when he's being distracted by a BOF
<aj> Next week on CSI: "Grissom! About time you got here. Looks like drug addled youths have been on an NMUing spree again."
<mdz> I was wondering if we should have a BIG RED FLASHING thing there if there are dropped patches
<lamont> aj: lol
<aj> lamont: stay tuned as Grissom finds a twiddled bit in the uploaded package, and proves that whoever did the NMU is an albino tiger from west africa!
<lamont> mdz: I have NFC where the source for -2ubuntu1 came from
<lamont> mdz: fortunately, all of the patches came in during the 1.0.5a-1 vs 1.0.5a-1ubuntu6 timeframe... I ported that patchset forward to 1.0.7-2
<lamont> we may not have correctly cleaned up the mess from the previous borked merge.
<lamont> all of the ubuntu uploads after 1.0.5a-1ubuntu6 say 'resync with debian'
<lamont> if one of those has something in it that is more than a resync, then I just dropped it.. :-(
<mdz> lamont: perhaps we should ask Keybuk to keep old MOM output around for cases like this
<lamont> mdz: that could help.. I have been making use of the ubuntu and debian morgues
<mdz> lamont: drop him an email, if you would
<crimsun> what are the major changes for it?
<crimsun> from the changelog, it seems like they're mostly 'unmute setting X'
<mdz> crimsun: yeah, it's mostly just some changes to the init script
<lamont> crimsun: that and changing the output format
<lamont> (of the init script)
<crimsun> yep, from 1.0.5a-1ubuntu1, gotcha.
<mdz> I think the bugfix portions have been merged into Debian
<crimsun> the modprobe stuff from 1.0.5a-1ubuntu5?
<lamont> mail sent to scott, cc mdz
<mdz> daniels: whycome my right Alt key stopped being Alt_R recently?
<mdz> lamont: thanks
<mdz> crimsun: yes
* lamont screams, bangs head on table
<crimsun> mdz: I see a || true, so yes.
<lamont> crimsun: current diff is only to control (depends), alsa-base.postinst, and alsa-base.alsa.init
<lamont> and changelog, of course
<crimsun> mdz: erk, apologies. I was looking at the ubuntu diff.
<crimsun> lamont: right.
<lamont> and actually, I think we might be able to lose the postinst piece
<lamont> I fail to see the advantage to simply modprobing some modules during postinst...
<lamont> they don't survive past the next reboot that way...
* lamont drops that patch
<crimsun> also, the "mixer" in "pcm mixer seq" was redundant, because modprobing snd-pcm-oss pulls in snd-mixer-oss
<lamont> well, /etc/modprobe.d/alsa-base does it now.
<daniels> mdz: what is it now?
<thully> Hi - I've reported some bugs in Hoary.  However, I don't think I'm going to run Hoary any more (I just don't have the time to deal with the bugs that come from it being an unstable distribution).  What should I do in Bugzilla about this?
<mdz> daniels: ISO_Level3_Shift
<daniels> mdz: ?!?
<mdz> thully: that creates a difficult situation for us if we can't reproduce the bug
<mdz> thully: if we can, then it's no problem
<daniels> mdz: looks like you have ralt:lv3_shift somewhere
<thully> Most of these bugs were reported some time ago
<daniels> mdz: what's your gnome keyboard setup look like?  anything bong in xkboptions/xkbvariant/whatever?
<mdz> daniels: like hell I do :-P
<mdz>         Option          "XkbRules"      "xfree86"
<mdz>         Option          "XkbModel"      "pc104"
<mdz>         Option          "XkbLayout"     "dvorak"
<daniels> i blame dvorak
<mdz> no xkboptions, no xkbvariant
<mdz> it worked fine until December sometime
<mdz> now I'm back in xmodmap hell
<daniels> if you just run sudo Xorg :1 -novtswitch -ac && xterm -display :1.0, and then run xev, does it give you Alt_R, or ISO_Level3_Switch?
<daniels> could be some weird thing in the GNOEM applet
<daniels> ugh
<daniels> no-one deserves xmodmap
<mdz> hey, -novtswitch comes in handy
<thully> Is there any way to just remove my bugzilla account, or just remove myself from the bugs?
<daniels> mdz: well, you'll still need to switch later
<daniels> actually, there was no real point to -novtswitch here
<daniels> but I use it a lot to test
<mdz> yeah there was
<mdz> I don't want it to switch, because I want to start the xterm first
<daniels> sudo Xorg :1 -ac && xterm -display :1.0 && DISPLAY=:1.0 xev
<mdz> and need to wait for the server to start up
<daniels> ah yeah
<daniels> if you do it with &, xterm usually waits
<daniels> this is one thing the current server doesn't do horrifically badly :P
* lamont ponders 4674 - what's the best way to get the locale, and is it even set on initial install before libpaper1.config runs?
<mdz> KeyPress event, serial 23, synthetic NO, window 0x400001,
<mdz>     root 0x40, subw 0x0, time 96512, (44,118), root:(46,120),
<mdz>     state 0x0, keycode 113 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
<daniels> mdz: that's on :1.0?
<mdz> daniels: correct
<mdz> so, doesn't look like GNOME's fault
<mdz> lamont: yes, it should be set when libpaper1.config runs
<mdz> you might need to source /etc/environment, not sure
<mdz> Kamion would know
<daniels> mdz: hm, so it does
* lamont will pester Kamion when he sees him next
* daniels attempts to remember the Dvorak sequence for 'xev'.
<daniels> something like bdn.
<mdz> ./symbols/dvorak:    key <RALT>  {       [     Mode_switch,       Multi_key  ]        };
<mdz> that's wrong, too, but an entirely different keysym
<mdz> daniels: how can I ask xkb "wtf are you using"?
<crimsun> (bd.)
<daniels> mdz: setxkbmap -print, IIRC
<mdz> xkb_keymap {
<mdz>         xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
<mdz>         xkb_types     { include "complete"      };
<mdz>         xkb_compat    { include "complete"      };
<mdz>         xkb_symbols   { include "pc/pc(pc104)+pc/dvorak"        };
<mdz>         xkb_geometry  { include "pc(pc104)"     };
<mdz> };
<daniels>         xkb_symbols   { include "pc/pc(pc104)+pc/us+ctrl(nocaps)+compose(ralt)" };
<daniels> yeah, so Mode_switch is what's forcing it into l3 in this case
<mdz> daniels: bd.
<daniels> mdz: bd?
<mdz> daniels: 'b', 'd', '.' is xev on dvorak
<mdz> us->dvorak
<daniels> mdz: oh, right, ta
<mdz> dvorak should have the same alt key definitions as us, IMO
<daniels> mdz: hm, as far as I can tell, it's Always Been That Way
<daniels> agreed
<mdz> there seems to be a bunch of stuff in symbols/dvorak that has no business there
<mdz> it should really only modify alpha and punctuation keys
* lamont tries to figure out which package creates /etc/kernel-img.conf
<mdz> anad yet it has entries for Escape, shift and crap in there
<mdz> and
<mdz> the right way for it to work is for dvorak to be a variant of a real keyboard layout
<mdz> but xkb makes my eyes hurt
<daniels> mdz: afaict, the canonical dvorak xkb definition has always done this
<daniels> ! This file was automatically generated on Wed Nov  2 10:29:07 1994
<daniels> ! by Ryszard Mikke with XKeyCaps 2.11;
<daniels> ! Copyright 1991-1994 Jamie Zawinski <jwz@lucid.com>.
<daniels> [...] 
<mdz> daniels: I swear this behaviour changed in the past 30 days
<daniels> ! The "Alt" key generates Mode_switch
<mdz> a bit longer than that, potentially
<mdz> my ~/.Xmodmap.old has keycode 113 = Alt_R
<mdz> but I renamed that sometime around when I upgraded this box to pre-Warty
<mdz> because it seemed to be unfucked
<daniels> daniels@catsby:~/tmp/dvoraksucks/meh/etc/X11/xkb/symbols% grep Mode_switch dvorak
<daniels> zsh: exit 1     grep Mode_switch dvorak
<daniels> hm.
<daniels> ah, hold on
<mdz> what's that tree?
<daniels> does it work if you do 'dvorak(basic)'
<daniels> oh, sorry, ECONTEXT; that was xfree86
<mdz> setxkbmap 'dvorak(basic)'?
<mdz> don't bother?
<daniels> setxkbmap -symbols 'dvorak(basic)'
<daniels> or change it in xorg.conf and spawn a new server
<mdz> daniels: dvorak(basic) gives me no alt keys, no windows keys, and one control key
<mdz> (NoSymbol)
<daniels> arse.
<mdz> what I want to say is, I have a pc104 keyboard with a us layout, plus these bits changed for dvorak
<daniels> mdz: try with us(pc104)+dvorak(basic)
<mdz> omg
<mdz> you are my hero
<mdz> seems perfect
<daniels> i sure am
<daniels> do I get a pay rise? :)
<mdz> better
<mdz> you get a cooper's when I come to .au
<daniels> ooo, shiny
<sivang> mdz: what's a cooper? :)
<mdz> supposedly it's a decent beer
<sivang> mdz: american ? :)
<mdz> australian
<sivang> mdz: eh
<sivang> mdz: why, supposedly?
<daniels> mdz: i have five in my fridge; they are my preferred drop
<daniels> mdz: (as long as it's the pale ale -- green label; the sparkling, which is red, isn't that great)
<mdz> sivang: because I'm taking their word for it
<mdz> having not tried it myself
<daniels> it is very, very decent
<sivang> hehe
<sivang> daniels: was it monty python's that had a joke about non english/au beer? ;-)
<lamont> is "decent beer" syntactically similar to "edible tripe"?
<daniels> sivang: no, that was US beer
<daniels> it's like making love on a canoe
* lamont could never stand beer....
<lamont> daniels: in the canoe would be safer...
<sivang> daniels: I was trying to be gentle :)
<daniels> lamont: it's very close to water
<lamont> daniels: ah, ok
<sivang> lamont: http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus
<daniels> (actually 'fucking close to water', but this is a family channel ;)
<sivang> daniels: :)
<mdz> jdub: ubuntu families
<sivang> on freenode? 
<daniels> mdz: no dude, grove street families
<JanC> why drink only "decent" beer?
<JanC> here in Belgium we have lots of fantastic beers   :-)
<lamont> ENOSEB
<thully> Is there a way to remove yourself from bugs you've reported on bugzilla, or remove yourself from bugzilla entirely - as I'm not going to have time to test hoary any more
<davyd_> what does the package for Ubuntu CDs look like?
<davyd_> and does it come from Switzerland?
<lamont> thully: I think you can tell bz to never send you mail - which isn't quite the same thing, but close
<thully> I wish Ubuntu had a "testing" distro like debian - so I could get updates but not have a huge risk of catastrophic system breakage
<daniels> thully: with a six-month release cycle, it's pointless
<lamont> thully: what daniels said
<lamont> daniels: although I suppose that if we had 3x the people, we could have a release always in upstream-version-freeze, and release every 3 months.... :-)
<lamont> but that's really getting silly
<davyd_> what's the point, GNOME only releases every 6 months
<lamont> davyd_: there's the rest of sid, too
<lamont> s/sid/ubuntu-main/
<davyd_> and we already spend half of that in freeze, I wouldn't want to spend any more
<lamont> davyd_: and that's why I said 3x the people for 2x the releases/year.
<lamont> it's well beyond the point of diminishing returns
<davyd_> I am a big fan of 6 month releases
<davyd_> but I wish feature freeze wasn't on Monday
<thully> does that mean Thunderbird will be stuck at 0.9 if 1.0 isn't in by Mon?
<thully> (in hoary)
<lamont> davyd_: my box-o-cds says 'NL BREDA' for the last line of sender address.
<lamont> which fits with my recollection that they ship from the netherlands
<davyd_> thully: GNOME feature freeze, not Ubuntu
<lamont> davyd_: feature freeze isn't monday.
<davyd_> lamont: I don't have the box yet, I just got email from work saying mail had arrived for me
<davyd_> lamont: it is for GNOME
<lamont> davyd_: ah.  somehow that doesn't surprise me.
<davyd_> lamont: what does that mean?
<lamont> thully: after tomorrow they're not allowed to add new features to mozilla-thunderbird if they want to ship it in march
<lamont> they're supposed to be fixing the bugs after taht date.
<lamont> davyd_: ubuntu's upstream version freeze is this week as well.
<davyd_> lamont: yeah, probably because it syncs with GNOME
<lamont> given that the ubuntu release model is somewhat patterened off of gnome, there is little surprise in that
<davyd_> guess who designed them both ;)
<lamont> thully: since moz-thunderbird is coming through gnome (yes?), it has until march to be ready from hoary's perspective
<davyd_> there are reasons they are similar
<sivang> thully: I use hoary and apart from some trouble with gnome-applets now and then, I don't stumble into real serious trouble. [yet :)] 
<thully> so - does anyone know to what this means to thunderbird 1.0 in hoary?
<davyd_> sivang: what's wrong with the applets?
<thully> It would be a shame if Hoary shipped with Thunderbird 0.9
<lamont> thully: it means that thunderbird needs to meet the gnome schedule, assuming that it comes from there...
* lamont ponders what thunderbird is...
<jdub> thully: unless we explicitly accept an update, it will stay at whatever version is released at UVF time
<jdub> lamont: thunderbird is mozilla mail stuff, not gnome
<lamont> jdub: so it doesn't come through gnome. check.
<sivang> davyd_: eh, they are working great now :) I was just to note that this is still the biggest breakage I had, oh that and 2 weeks ago some with CUPS that got fixed
<thully> Thunderbird 1.0 has been out for several weeks - but isn't in debian unstable yet
<lamont> thully: is it even in debian experimental?
<sivang> jdub: regarding country teams, what about the ubuntu-il mailing list? :)
<jdub> given that 1.0 is already out (but just not in debian) it's reasonably likely that we'd accept a 1.0 package after UVF
<jdub> sivang: haven't done it yet
<thully> lamont: don't know about that
<lamont> thully: nope/
<thully> one question: Are the OpenOffice.org GNOME integration packages going to be included by default in Hoary?
<lamont> thully: generally speaking, you can expect to see ubuntu ship with whatever the latest released code for FOO was 3 months prior to the release
<lamont> thully: with gnome being the notable exception to that at this time.
<lamont> thully: in specific, if there's a good case for taking a new upstream version after upstream version freeze, then it might make it through, depending on the apparent stability of it.
<jdub> thully: they've been proposed for inclusion, yes.
<thully> As i've installed from Array 2 and by default, these aren't included - making an extremely ugly default openoffice configuration
<lamont> jdub: but will I get my ^*(_^&(B mouse focus fix in metacity, that's my question...
<thully> Does laptop suspend support look to be on track?
<jdub> lamont: more focus work still happening
<lamont> jdub: but will it include strict-pointer-focus, that's the real question
<lamont> jdub: (really not trying to troll, mind you)
<JanC> anyone know what version of wxPython will be in hoary?
<crimsun> 2.5.x will be in hoary/universe
<daniels> thully: yes
<crimsun> currently that's 2.5.3.2
<thully> will it be configurable (suspend, that is)
<daniels> thully: maybe
<thully> If a GNOME applet is impossible, one solution that would allow suspend to be configured is to have each ACPI action (lid, sleep, powerbtn etc) call symbolic links to the actual suspend / hibernate / screen blank scripts
<thully> then you just change the symlinks to change the settings
<JanC> okay, that's good, because more and more programs & libraries that use wxPython need 2.5.x   :)
<daniels> thully: a gnome applet will not be done in the time until hoary, unless someone writes it
<daniels> thully: and you do realise that /etc/acpi/*.sh are conffiles, so they won't get overwritten if you modify them?
<thully> I actually didn't modify these - I modified the files in /etc/acpi/events to call scripts in /etc/acpi/actions that are actually symlinks to the real suspend scripts
<daniels> well, you can do that too.  and they won't get changed.  but the effect is the same.
<thully> so, /etc/acpi/events/sleep calls /etc/acpi/actions/sleep.sh, which calle /etc/acpi/sleep.sh
<thully> correction /etc/acpi/actions/sleep.sh points to /etc/acpi/sleep.sj
<thully> sj=sh
<thully> Why doesn't this work?  I've done this and it seems to work for changing suspend actions
<daniels> what do you mean, 'why doesn't this work'?
<thully> I'm a bit confused at what you were saying about conffiles - can you elaborate?
<daniels> so, everything in /etc is registered as a configuration file
<daniels> if you change it, your changes will be respected, and you won't lose them every update
<daniels> so you can change /etc/acpi/lid.sh yourself if you want
<thully> yes - I know - doing it the symlink way just makes it a bit cleaner and easier
<daniels> after a fashion
<thully> I was just a little confused when you were talking about "conffile"
<thully> and what exactly you meant
<bob2> 'conffile' is the name of the class of files that dpkg considers to be user-modifiable and will not fuck with
<thully> Will Hoary be in a more stable state after UpstreamVersionFreeze?
<lamont> thully: churn will certainly reduce
<jdub> thully: stable meaning it won't change much, or do you mean robust?
<thully> both, to an extent
<jdub> it will stop changing to a large extent (gnome will continue to change)
<jdub> because everything stops changing, bugs are more easily fixed, so it will become more robust
<thully> Do you think it will be better than debian unstable in the stable-as-in-robust department - how about testing?
<jdub> dude
<crimsun> yes. It has a 3 month frozen period before release.
<lamont> thully: instantly? of course not
<jdub> it's going to be released in march as a preview and april as final supported
<crimsun> hmm, march.
<thully> OK
<jdub> so if it's not releaseable by then, we will have serious problems
<thully> daniels: will suspend be enabled by default?  Will the user be able to disable suspend?
* jdub begins the hoary cd download treadmill...
<lamont> jdub: new arrays?
<lamont> I really wish our stupid web directory listing would show the mtime of files...
<jdub> pulling a daily
<jdub> for rsyncage
* lamont likes that idea, although is ubuntu mirror is still 75 files behind
<lamont> mdz: for giggles, 287614 should be imported, and applies to hoary (and probably warty...)
<lamont> and is already imported.
<lamont> sigh.
<fabbione> morning
<lamont> morning fabbione 
* lamont decides to go to bed and finish fixing gtkmm2.0 tomorrow morning
<fabbione> ehhe
<fabbione> night lamont 
<lamont> 45 minutes to get to the failure... kinda boring
<lamont> and the kids are back in school tomorrow, so I have to get up early again.
<fabbione> welcome back to the real life ;)
<lamont> heh
<lamont> in addition to being an RC bug, gtkmm2.0 is holding up the majority of 111 d-w packages in stage 1
<fabbione> actually... gtk2.0-bin or something like that is an issue for sparc too
<fabbione> it doesn't install
<lamont> gtkmm2.0 needs net access in order to build.
<fabbione> argh
<lamont> funny thing is that debian/rules has a "fix" for it, just not in the right place.
<fabbione> lol
<lamont> warty bug #5173, debian 287614
<lamont> so I changed the place that is dying, plus the other possible place... in the morning (or if I wake up in the middle of the night), I'll try a build without the second one (or at least look at the log and see...)
<fabbione> hmmm
<lamont> hrm... maybe throttling the rsync of the iso to 8kbps was a bad plan.
<lamont> 124 hours eta
<fabbione> how could you build gnome-doc-utils?
<fabbione> it fails here
<fabbione> http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd:166: parser error : XML conditional section not closed
<lamont> built fine on my machine (which has no net access)
<lamont> although if it's actually trying to go to www.oasis-open.org, that's an RC bug in debian.
<fabbione> hmm i am getting errors installing Setting up libgtk2.0-bin (2.6.0-0ubuntu1) ...
<fabbione> no i don't think it is
<lamont> there's a 0ubuntu2
<fabbione> of libgtk2.0 ?
<lamont> don't think it's trying, or don't think it's a bug?
<lamont> gnome-docutils
<fabbione> even if it was trying my machine has net access
<fabbione> yeah that one fails with that error
<lamont> yes, but if the doc is bad on the website, and it's failing over gracefully with no net access...
<fabbione> hmmm make sense
<lamont> I wish python2.4 built on hppa (2.6.8) without me killing each of the thread tests..
<fabbione> argh.. that sucks
<lamont> stage 2 has 562 needs-build, 27 d-w
<fabbione> dude.. let me try to give you a kernel
<lamont> yeah - that's a factor in me saying that hppa ain't ready for hoary
<lamont> yeah - need to get you a machine...
<lamont> hrm.. 15minute build time... my bad
* lamont uploads a new gtkmm2.0
<doko> good morning all!
<fabbione> this is pure horror
<fabbione> libgtk2.0-bin in chrootA doesn't install
<fabbione> the same on chrootB that is a copy of chrootA installs fine
<fabbione> difference is the console
<lamont> lol
<fabbione> lamont: you were right about gnome-doc-utils
<fabbione> it tries to access the net if it can
<lamont> that's a bug
<fabbione> yup
<fabbione> lamont: filing one
<fabbione> lamont: can you check on one of your chroot if /usr/share/icons exists?
<lamont> both stage1 and 2 have that directory present
<fabbione> HMMM
<fabbione> mine don't
<fabbione> and that's apparently the reason why libgtk2.0-bin fails to install
<lamont> interesting - I did nothing special to create it
<lamont> sounds like yet-another-bug time
<lamont> g'night
<fabbione> probably a left over?
<fabbione> i bootstrapped a new buildd chroot 2 days ago...
<jdub> Kamion: when you're around -> pretty smooth hoary install from today, but didn't get an fb console (using an nvidia card on this machine).
<jdub> Kamion: otherwise pretty smooth and, well, uneventful. ;-)
<davyd_> jdub: so not like mine then ;)
<davyd_> when I had to netcat UserDict onto my machine
<jdub> Kamion: ... until the final packages are installed
<jdub> Kamion: then i get a "type 'exit' to return to base-config" prompt
<jdub> Kamion: which attempts to return, but doesn't ;)
<jdub> Kamion: ah, nothing in the menu after "execute a shell".
<fabbione> hey pitti
<fabbione> Mr. DeRoot
<pitti> Morning
<pitti> fabbione: Hi Mr. Kernel patcher! :-)
<fabbione> ehehhe
<Treenaks> hmm.. do we enable the "Video" ACPI stuff in 2.6.10?
<Treenaks> (ChangeSet@1.2131, 2005-01-02 11:45:13-08:00, torvalds@evo.osdl.org)
<jdub> lamont: ubuntu-calendar* haven't gone in because we need james to accept them or something, right?
<fabbione> Treenaks: k7-smp:CONFIG_ACPI_VIDEO=m
<fabbione> Treenaks: and a changeset AFTET 24-12-2004 is mostlikely not in our tree
<fabbione> AFTER
<fabbione> Treenaks: full URL to the changeset?
<crimsun> fabbione: another vote of confidence for linux-image-2.6.10-1-686-smp (2.6.10-3): finally ACPI works correctly.
<bob2> how about swsusp?
<crimsun> bob2: me? haven't tested.
<fabbione> crimsun: cool
<crimsun> (ACPI has never worked across 2.4 or 2.6 til now)
<Treenaks> fabbione: uh.. don't know.. I'm reading the -bk6 changelog
<Treenaks> fabbione: how do I find out?
<fabbione> some website.. i think it's bitkeeper.com or something like that
<bob2> linux.bkbits.net
<Treenaks> fabbione: http://linux.bkbits.net:8080/linux-2.6/cset@1.2131?nav=index.html|ChangeSet@-2d
<Treenaks> fabbione: even better, a diff: http://linux.bkbits.net:8080/linux-2.6/gnupatch@41d84f49Gbzesf6EsPI73plRgr2MbQ
<fabbione> yeah thanks
<Treenaks> speaking of nasty one-liners: http://linux.bkbits.net:8080/linux-2.6/gnupatch@41d832117seXnnx2qbN-FpUvnmLRuQ
<fabbione> what's that about?
<Treenaks> ipt_ECN checksum corruption
<fabbione> yeah
<pitti> sjoerd: hey, new hal upstream release
<pitti> sjoerd: time for tarball.mk? :-)
* fabbione does the evil step and install bitkeeper
* cartman fears biatchkeeper
<pitti> lamont: here?
<cartman> btw "UPLOADPENDING" status means that a new package will come to Hoary soon?
<fabbione> pitti: he went to sleep a while ago
<pitti> oh, ok
<cartman> new version of a package that is
<fabbione> cartman: yes. that fix that bug
<fabbione> pendingupload btw ;)
<cartman> fabbione: cool thanks
<cartman> then daniels accepted my patch
<fabbione> could be
<froud> Hello, I am working in doc team. I would like to know if the "sounder" be using in the future or can we depreciate citation to it in the docs?
<froud> 'sounder' will be used ..
<Treenaks> 'array' for hoary, afaiki
<froud> Treenaks, thanks. Can anyone confirm that the "sounder" will be used for  Ubuntu 5.04 (The Hoary Hedgehog): April 2005
<fabbione> froud: "Array"
<froud> sorry what does array mean?
<crimsun> correct me if I'm wrong, but it's a codename
<froud> ok so this is a name instead of sounder :-)
<froud> cool
<froud> thanks
<Treenaks> no, a group of warthogs is  "a sounder of warthogs". a group of hedgehogs is an "array" of hedgehogs
<crimsun> ah, there you go
<Treenaks> afaaik
<froud> Hmmm, very cute :-)
<lifeless> Treenaks: spot on
<froud> Hoi, lifeless said something. lifeless never does that on #ubuntu-docs
<bob2> this is #ubuntu-devel 
<froud> yes, but lifeless also tunes to  #ubuntu-docs. Ok going back to work, thanks
<seb128> morning
<mvo> hi seb128 
<Treenaks> morning
<pitti> Morning seb128, mvo
<fabbione> hey seb128 
<fabbione> seb128: totem is FTBFS
<seb128> ok
<seb128> let me catch up with the ton of mail of the night first :p
<seb128> but thanks for noticing :)
<mvo> morning pitti 
* fabbione gets full diff control over bk
<fabbione> now.. changeset will not be scary anymore ;)
<seb128> grumpf, why does it try to link with libhal
<seb128> oh, libnautilus-burn.la
<Treenaks> totem can burn now?
<seb128> no
<seb128> this lib has also a part for the CD/DVD drives detection
<seb128> and totem read CDs and DVDs
<Treenaks> ah
<davyd_> yay! 1kg of Ubuntu kds
<davyd_> cds
<Treenaks> davyd_: how many? ;)
<davyd_> 19 or so
<davyd_> I ordered enough for to give everyone at work one
<davyd_> and some others who wanted them
<davyd_> and have some spare to for when I do some presentations on GNOME 2.9 tech later on
<ogra> mvo ?
<mvo> ogra: ?
<Treenaks> ogra? mvo?
<ogra> how did your isdn tests go ?
<ogra> *g* Treenaks
<mvo> you notic that I login and out :)
<mvo> well, not too bad. gnome-system-tools has basic isdn support (for capi cards) now (yeah!) but it's still a bit buggy 
<ogra> ah, ok....i just dug up all my isdn fritz cards....so i'll have pci,pci2.0 and a ISA one at home tonight....
<mvo> 2.6.10 still oops with mISDN
<mvo> ogra: cool!
<ogra> thats what i menat
<mvo> I would love to hear if 2.6.10 breaks for you as well
<ogra> so lets nail this down tonight....(got no isdn at work unfortunately
<mvo> a ISA one? *urggghh*
<ogra> hehe....from ancient times :)
<ogra> but it should get tested too...i just have to find a board with ISA....thats a bit tricky
<Treenaks> I have an ISA USR ISDN TA
<mvo> ogra: tonight sounds cool, also we have a meeting and I will play some hockey in between. if I can't make it we will have to check it tomorrow (hope that's ok)
<ogra> yep, sure
* mvo runs away from ISA hardware
<ogra> hehe
<fabbione> mvo: can you send the info i asked you yesterday please?
<mvo> dosn't microsoft call there web-proxy something with ISA?
<fabbione> there are no updates on the mISDN cvs..
<mvo> fabbione: yes
<ogra> heh, do they ? (M$ ?)
<Kamion> sheesh, I am so behind it's unbelievable
<davyd_> mvo: Internet Security Architecture
<ogra> haha
<Treenaks> davyd_: the irony 8)
<davyd_> actually, I seem to recall the world Accelleration is in their too
<davyd_> *there
* mvo chuckles
<davyd_> perhaps its Internet Security and Accelleration Server
<davyd_> I think that's correct
<davyd_> it's an absolute whore
<Treenaks> uh.. why is gluck.debian.org doing a HEAD / on my server?
<robtaylor> mdz: amu: seen this? http://www.atconsultancy.nl/cowloop/ ?
<Kamion> Treenaks: planet?
<Treenaks> Kamion: I don't blog, so I'm not on planet
<jdub> robtaylor: using dm seems like the saner solution
<abelli> jdub: hi there
<jdub> morning
* jdub goes to bed
<jdub> :-)
<thom> night jdub
<fabbione> hey thom
<thom> hey hey
<davyd_> jdub: are you really going to sleep at 10pm?
<Treenaks> gluck is  doing a HEAD / on "www.foodfight.org" every day around 10:35-10:40 UTC ... hmmm...
<fabbione> mumble
<fabbione> sort problem..
<fabbione> http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.10-bk6.log
<Treenaks> starting from 20-dec-04
<fabbione> all Changeset in that file can be extracted with something like:
<fabbione> cat patch-2.6.10-bk6.log |grep ^Change | cut -d "," -f 1 | cut -d "@" -f 2
<fabbione> now..
<fabbione> how do i sort the result?
<fabbione> LC_ALL=C sort -rn -t\. -k1rn -k2nr -k3gr -k4nr
<fabbione> sorts correctly the first 3 keys
<fabbione> but not the 4th one...
<fabbione> 1.2034.116.20
<fabbione> 1.2034.116.2
<fabbione> 1.2034.116.19
<fabbione> and this is plain wrong...
<fabbione> it should be like .20 .19 .2
<fabbione> according to the numeric value...
<fabbione> actually.. that's just plain wrong...
<fabbione> also key3 is not sorted properly.... HMMMM
<Treenaks> (ah, found the gluck thing:  http://people.debian.org/~djpig/urlcheck/devel.en)
<crimsun> fabbione: ever looked at http://www.dt.e-technik.uni-dortmund.de/~ma/linux/kernel/lk-changelog.html ? That's what Linus & Marcelo use.
<fabbione> crimsun: that's not what i need
<fabbione> that script creates a changelog
<crimsun> fabbione: just wondering you can pull the sorting logic from it
<crimsun> wondering if^
* seb128 kicks daniels 
<seb128> daniels: "all bugs are gtk bugs", that's it ? :p (before reassigning a bug on gtk you could ask in which app that happens, perhaps that happens in a xterm too)
<Treenaks> seb128: is this about the compose/i/j bug (Dutch "y") ? :)
<seb128> yes
<Treenaks> that should be fixed in the X compose map, and shouldn't GTK use that?
<seb128> dunno but daniels has reassigned it too gtk
<seb128> s/too/to/
<Treenaks> hm.. I see
<seb128> does it happen in a xterm ?
<seb128> or the compose work in a xterm ?
<seb128> BTW in gtk widgets you can change the compose method in the right click menu
<seb128> Cedilla is the default here
<seb128> perhaps you need to use the X one
<seb128> or the Default
<Treenaks> it doesn't work anywhere yet (except for the ctrl+shift+133 trick in GTK apps)
<Treenaks> seb128: if I use the "X input method" I can use compose fine, it's just that that combination is not in the Xorg compose map yet
<seb128> ok, so I reassign on Xorg instead of gtk
<seb128> thanks
<fabbione> ahhh even easier
<fabbione> bk doesn't need 2 revisions to make a diff
<fabbione> if only one is specified it assumes you want the diff with the previous one...
<Treenaks> seb128: you could paste this IRC conversation as a comment on the bug..
<seb128> Treenaks: already done
<seb128> but thanks :p
<mvo> ping amu
<robtaylor> jdub: agreed.. just pointing it out ;)
<thom> AAAARGH
<thom> how can it be this hard to get a phone line reconnected
<fabbione> thom: ahah poor you!
<robtaylor> thom: in argentina it ttook 2 months =)
<Treenaks> thom: they're hardware engineers..
<fabbione> thom: wanna come here in dk for sometime?
<thom> robtaylor: it's getting that way with BT
<robtaylor> thom: ee
<robtaylor> k
<thom> robtaylor: requested Dec 1
<robtaylor> thom: i assume the physical line is already there? ;)
<thom> yup
<robtaylor> heh. my (rather new) flat doesn't even have that. i've decided that it just isn't worth having a landline =)
<thom> previous tenants had it disconnected when they moved out, just want it turned back on *sigh*
<thom> robtaylor: dsl is rather critical when working from home ;-)
<robtaylor> thom: ah, yeah i forget most people have to use copper ;)
<thom> yeah, the free wifi stuffs in london don't make it out to us, sadly
<Treenaks> thom: ... yet?
<robtaylor> thom: naa, i'm in cambridge - i've got a connetion to Cambridge Broadband's Cotares network..
<thom> Treenaks: dunno if ever
<thom> ahh
<seb128> elmo: pike7.2 sync please
<robtaylor> thom: do BT actually have an excuse?
<seb128> fabbione: #5188 ?? I've a network connection and it does FTBFS ... any detail ?
<thom> robtaylor: they're BT... think they need one? :-(
<thom> oooh, a human!
<pitti> elmo: please sync nasm, tiff, tetex-bin
<fabbione> seb128: it simply should never depends on a network... 
<fabbione> seb128: if you remove the net it will build
<seb128> it build with the net here !
<fabbione> so the resulting package can be mangled either by fetching from the net or reverting to the local default
<seb128> hum, ok, let me look on the package
<seb128> do you know what it gets by the net ? a dtd ?
<fabbione> sec...
<seb128> you could have past a build log or something like that in the BR :p
<robtaylor> seb128: ugh, thats pretty damm ugly =)
<fabbione> seb128: i have the entire log.. you know that...
<seb128> yeah, and I've a bug without any details, you know that ? :)
<fabbione> seb128: we all know you have mental power
<seb128> shuuush, that's a secret :p
<ogra> fabbione: probably its also multiple personalitys....nobody can work _this_ fast
<fabbione> ogra: i think he is like the "One million dollar man" with cybernetic fingers to type faster
<thom> it doesn't take much typing to reassign all your bugs to Xorg ;P
<ogra> yep, thats what i always think....its simply impossible for one person to match this many tasks....
<fabbione> thom: ahha
<fabbione> hey trukulo 
* fabbione goes and gets some food
<trukulo> hi fabbione 
<trukulo> i'm learning to make good debs :P
<trukulo> fabbione: bon appetite
<fabbione> trukulo: that's good :-)
<fabbione> thanks ;)
<trukulo> but i'm getting crazy with manpages :P
<ogra> trukulo use pbuilder and lintian.....helped me a lot to get my packages clean
<trukulo> i use lintian (not pbuilder, yet)
<trukulo> problem is i've included manpages
<Kamion> jdub: *any* help with fb console problems is appreciated; at the moment I'm assuming kernel bugs
<trukulo> but don't know why they aren't included
<ogra> trukulo where do you put them ?
<trukulo> i'm making graveman package, a frontend in gtk2 for cdrecord
<trukulo> ogra: EVERYWHERE !!! i'm getting crazy
<ogra> trukulo: hmm, you should read the mailing list....
<trukulo> i put them on debian directory
<trukulo> i use to read it
<ogra> trukulo: i already did graveman last week
<trukulo> i'm making this for sarge :)
<ogra> ah, ok...
<crimsun> in debian/$package/man/* ? are you calling dh_installman?
<trukulo> just commenting fabbio
<trukulo> ah, one thing
<crimsun> err
<crimsun> debian/$package/usr/man/*
<trukulo> graveman doesn't work well in warty with your package
<Kamion> usr/share/man please, never usr/man
<ogra> trukulo: you should put it in the debian subdir....
<trukulo> i'm calling it
<trukulo> i did
<crimsun> Kamion: err, yes.
<crimsun> Kamion: dunno why I left out share
<trukulo> i've read mantainer guide, lintian explanations, docs...
<Kamion> if you're using debhelper, set DH_VERBOSE=1 to see what it's doing
<ogra> trukulo: it does work fine for me....as long as nobody sends bugs to me, i must assume its working for others too
<jdub> Kamion: it sat for a moment 'waiting for /dev/fb/0'
<trukulo> ogra: do you use scsi emulation?
<ogra> trukulo: nope
<ogra> trukulo: thats deprecated in 2.6
<trukulo> problem is in my computer, graveman (of your package) doesn't recognize cdrecorder
<Kamion> jdub: yeah, same bug as I see in places
<Kamion> jdub: check whether /proc/fb has any content once the UI starts up
<ogra> trukulo: i wrote a lengthy mail about that particular prob....i'm also in contact with the graveman author about that....
<trukulo> me too, my package for sarge is in his page
<trukulo> i didn't read that email, i'll look on mailing archives
<ogra> trukulo: change the dev= line in your ~/.graveman/graveman.conf to the actual device name
<Treenaks> c
<Treenaks> argh
<ogra> trukulo: like: dev=/dev/hdc (if your writer is hdc)
<trukulo> oh, ok ogra
<trukulo> it's not elegant, but i supose as it's a frontend of cdrecord, it's the only way
<jdub> Kamion: at the risk of bringing up an old discussion, how about 'base' instead of 'server'? :)
<ogra> trukulo: i would _love_ to patch the nautilus-cd-burner detection stuff in there....it uses hal and seems to work perfectly 
<trukulo> yeah, using libburn isn't it?
<jdub> Kamion: nothing in /proc/fb when the choose language screen is up
<ogra> trukulo: nope.....just cdrecord...but it detects with hal
<Kamion> jdub: talk to Mark, the name is his choice, I was overruled.
<jdub> Kamion: what was your suggestion?
<ogra> trukulo: i tried something similat with mrburns.....works quite well there
<Kamion> I'm pretty fed up of having installer stuff dictated to me :-/
<ogra> similar
<jdub> (server at least implies ubuntu can do server)
<Kamion> jdub: custom was my name
<jdub> yeah
<Kamion> jdub: /proc/fb> kernel bug then
<Kamion> (probably ... vesafb sucks)
<trukulo> ogra: that woudl be great
<jdub> fbcon is loaded
<Kamion> jdub: I bet there's an error message in syslog about vesafb
<jdub> as is vesafb
<Kamion> vesafb appears not to necessarily fail to load when it should
<trukulo> ogra: and it would be very well to include graveman.desktop and graveman.png too
<ogra> trukulo: is already in my package ;)
<jdub> found:
<jdub> vesafb: probe of vesafb0 failed with error -6
<trukulo> ogra: superb
<ogra> trukulo: and a postinstall that makes it the default burning app in g-v-m
<jdub> ogra: that sounds ugly
<ogra> trukulo: ....and changes it back with prerm to nautilus if you uninstall.....
<ogra> jdub: it was the quick hack for impatient ppl, before i had the time to make a .desktop file....i'll consider removing it again
<jdub> ogra: packages shouldn't really futz with other packages stuff :-)
<trukulo> ogra: what i sugest to sylvain, is to add a "directory add" button
<trukulo> i know it's in the menu
<ogra> jdub:  i'll keep it in mind...even gconf is so tempting to do such things...they are so easy
<jdub> ;)
<Kamion> jdub: I get the same
<ogra> trukulo: if you would like to take over the package, just garb it from my src repo...deb-src http://www.grawert.net/ubuntu/ warty universe
<ogra> grab even
<fabbione> vesafb problem????
<trukulo> thanks ogra, but i'm doing this essencially for learning
<fabbione> it must be a GTK bug
<trukulo> :) so i want ALL the problems and no easy solutions
<ogra> trukulo: heh, me too....but the packaging graveman probs are solved for me.....now the patching graveman probs start ;)
<robtaylor> carlos: pingetty-pong?
<carlos> robtaylor: hey, ;-)
<carlos> robtaylor: I was trying to ask you where the hell your arch archive was hosted but I found it yesterday (finally)
<robtaylor> carlos: hey :) strange that there's no listing, sure i made it with -l. oh well, i'll fix this as soon as i get home :)
<carlos> happy new year :-D
<robtaylor> carlos: heh, strange you couldnt find it in irc logs =)
<carlos> robtaylor: yeah
<carlos> robtaylor: you should add it to the supermirror list
<robtaylor> carlos: yeah will do. The only reason i havn't is I thought jblack was working on automagic supermirroring..
<robtaylor> (for sourcecontrol.net)
<trukulo> ogra: yes, but i'm not a programmer :)
<robtaylor> carlos: so what are you thinking of using it for at uni?
<trukulo> ogra: i think we need three things for graveman
<trukulo> 1) format cdrw option
<trukulo> 2) "add directory" button on gui
<carlos> robtaylor: I need to do a development to finish my studies and the project I planned to do has disappear so I'm thinking on accessd 
<trukulo> 3) hal drive recognising
<trukulo> carlos: accessd ?
<carlos> trukulo: a project rob & I are developing
<trukulo> carlos: what is about?
<carlos> authentication and priviledge elevation
<trukulo> like sudo?
<trulux> hey pitti
<trukulo> (remember i'm a little membrillo)
<pitti> Hi trulux 
<pitti> trukulo: -hardened kernel works fine on ppc!
<trukulo> pitti: you mean trulux?
<pitti> trukulo: yes, sorry
<carlos> trukulo: something like that, but without setuid bit
* pitti hates this silly xchat autocompletion
<trukulo> carlos: umm, cool
<pitti> seb128: can you please tell me again to teach xchat a sane autocompletion?
<pitti> seb128: s/to/how to/
<carlos> pitti: I'm not sure if I will be able to attend todays meeting :-(
<seb128> set completion_amount 0
<pitti> seb128: ah, thanks
<carlos> pitti: how long will be it?
<pitti> carlos: neither meeting?
<pitti> carlos: we have both the regular TB and the hoary goals meeting
<carlos> pitti: tonight one
<pitti> carlos: okay, maybe we can discuss it right now
<pitti> carlos: I actually wanted to know about the status of automatic translation deb generation
<pitti> carlos: is this possible right now?
<trulux> pitti, great
<trulux> there are no major arch issues
<carlos> pitti: Rosetta is not going to do automatic debs
<trulux> in fact
<trulux> ;)
<carlos> pitti: what's your ide?
<carlos>  /s/ide/idea/
<pitti> trulux: framebuffer is still broken on i386, but works fine on ppc
<pitti> carlos: we need a server that daily pulls new pos from rosetta, builds an update deb (if anything changed) and puts it into the archive
<carlos> pitti: we could prepare an URL with a package of .po files
<carlos> for every hoary package
<carlos> so you could do it automatically
<carlos> is that enough?
<pitti> carlos: I think the rosetta server should already decide which files were touched since the last pull
<pitti> carlos: otherwise you will have a lot of redundant traffic
<pitti> carlos: is that possible?
<carlos> yes, we know that
<carlos> well, we know last time it was touched
<carlos> we need then a way to say "it was merged into main stream on ...."
<pitti> carlos: the interface could be an URL where you can download all po that were touched on a given day
<pitti> carlos: http://rosetta/updates/20050110/ or so
<carlos> so you will get all translations  updated since 20050110 ?
<carlos> ok, it sounds better
<pitti> no, all translations updated _at_ 20040110
<carlos> hmmm
<pitti> I don't want older ones
<pitti> oh yes
<pitti> newer ones are okay, too :-)
<elmo> pitti/seb128: done
<pitti> elmo: thanks
<seb128> thanks
<pitti> elmo: I sent you an email about this a while ago, you can disregard that now
<carlos> pitti: it's easier for me that way, so I don't need to store the exported time
<pitti> carlos: right
<carlos> I think it's doable
<pitti> carlos: so, this URL delivers all PO files whose modified time stamp is younger/equal than the URL given one
<carlos> but it should be done for product
<carlos> the export process is not fast
<carlos> and you could get a timeout
<pitti> carlos: you mean per-package?
<carlos> yes
<pitti> carlos: this would mean a lot of additional GET requests
<carlos> yes
<pitti> but I think it should work
<pitti> carlos: another idea
<carlos> I need to do some checks, I think stub told me that we could start serving a zip stream while we export new data at the same time
<pitti> carlos: http://rosetta/cgi-bin/get-updates?date=20050110
<carlos> if that works, I could give you only one file with all po files
<pitti> ^ this will deliver the list PO file URLs
<pitti> okay, ZIP stream sounds cool, too
<pitti> if that is not possible, then I think the CGI script that gives me the URL list of new PO files is fine, too
<carlos> pitti: yes, it's another option
<carlos> pitti: we need also to agree on the directory structure you want/need
<pitti> carlos: well, I don't really care
<pitti> carlos: it should avoid too many small GET requests
<pitti> carlos: it should only transmit changed po files
<carlos> if I give you a zip with all po files
<pitti> carlos: and I must be able to tell which package a po file belongs to
<carlos> you need to know if a es.po is from synaptic or nautilus...
<pitti> ^ that's point 3 :-)
<carlos> ok
<pitti> the zip file could contain the po files in per-package directories
<pitti> as long as above three conditions are met, I don't think that the concrete structure/transport format matters too much
<pitti> so I would set up a nightly cron job which pulls the pos and assembles update debs
<carlos> pitti: the "problem" is that usually a product in rosetta does not maps directly to a Debian/Ubuntu package
<pitti> carlos: ugh, why not?
<fabbione> hey elmo
<azeem> happy new year, ubuntu dudes
<pitti> azeem: happy new year to you!
<pitti> carlos: my Cannelonis are ready, see you in half an hour :-)
<carlos> pitti: ok, see you later
<trukulo> bon apetite pitti 
<sjoerd> pitti: oh, great timing from davidz then :) (hal upstream release)
<fabbione> cya later for the meeting
<elmo> hey fabbione 
<lamont> jdub: I expect so
<lamont> pitti: yes?
<pitti> lamont: Morning
<pitti> lamont: postgresql FTBFS, probably because build-dep mmv is missing
<lamont> gah.  nuke mmv usage from the source
<pitti> lamont: mmv is universe currently, but shouldn't it be germinate'd to main automatically?
<lamont> it's a _USELESS_ waste of packaging
<Kamion> mmv's nice
<Kamion> for users, at least
<pitti> I agree, mmv is very nice
<lamont> I'll grant for users.
<azeem> it's quite un-unixy though
<Kamion> not seeded though
<lamont> but in debian/rules?  come on.
<pitti> Kamion: I thought it should get in via germinate?
<pitti> lamont: it's not in debian/rules
<pitti> lamont: its used in an obscure upstream source patch
<pitti> lamont: of course I can modify it not to use mmv
* lamont gags
<pitti> lamont: it is used to properly rename the sections of manpages
<lamont> promotion from universe to main has a manual step, and I would hope that elmo would scream before promoting mmv.
<pitti> lamont: not a big deal, but I decided to eventually get it right
<pitti> lamont: well, I remove it again for now
<lamont> not because it's insecure, but because it's silly. :-)
<pitti> lamont: why do you think it's silly?
<pitti> lamont: having the functionality just with mv, sed, for, and tr is ugly
<lamont> ISTR it was ftbfs on one architecture back when, and it struck me as a very non-sensible API
<lamont> bind9? was using it at the time, in a way that was trivial to recode without it
<lamont> I freely admit that there could be use cases where it makes more sense
<Kamion> pitti: yeah, what lamont said, germinate will *say* it's in main but that doesn't immediately make it so
<pitti> Kamion: well, okay, I change the patch to do without mv
<pitti> mmv, that is
<pitti> Kamion: btw, it used mmv for ages, but the build-dep was missing
<lamont> heh
* lamont must go get ready and drive kids to school.  back on in a while
<fabbione> lamont. later :-)
<lamont> Kamion: email sent
<lamont> fabbione: I'll build that chroot once I'm back on.
<jdub> ahr, d'oh
<jdub> can't stay awake
<mjg59> fabbione: You were looking for me last night?
<stockholm> Kamion: did we talk about config file rewriting (especially concerning slapd.conf) for transparent upgrading of backends?
<stockholm> Keybuk insists it was you  and not him
<Kamion> backends?
<Kamion> it may not have been him but I don't remember it being me either
<stockholm> ok
<stockholm> to bad.
<daniels> seb128: there are two bugs
<daniels> seb128: one is on X, the other GTK.
<seb128> daniels: there is not even a gtk app mentionned in this bug
<daniels> seb128: i added ij (U0133) and IJ (U0132) to the X compse map, but that doesn't matter
<Keybuk> GTK+'s compose map needs an overhaul
<daniels> so now if I right-click in gedit, hit Input Methods, and select X Input Method, I can compose ij and IJ with multi-key
<daniels> seb128: but, stupidly, GTK's default mapping is *not* this, and has its own compose handling
<seb128> ok, so that's good
<Treenaks> you mean  and  ;)
<daniels> seb128: the table is in gtk/gtkimcontextsimple.c
<daniels> Treenaks: (yeah, can't be arsed restarting gnome-terminal, and my utf8-fu is broken for irc anyway)
<daniels> seb128: so { GDK_Multi_key, GDK_i, GDK_j, 0, 0, 0x0133 }, needs to be added to the table, presumably
<seb128> ok
<daniels> but that didn't work when I was trying something else, so I dunno if it will be any good
<daniels> so I've fixed my bug, now you get your half :)
<seb128> you could provide some details in the bugs
<Keybuk> there's a huge patch for gtk/gtkimcontextsimple.c in Bugzilla that adds a few hundred new mappings
<Keybuk> (GNOME Bugzilla, that is)
<seb128> ie: giving the xorg fix so I can apply it to test gtk :p
<Treenaks> Keybuk: what's wrong with using the X mapping by default?
<Keybuk> Treenaks: I've no idea why GTK+ has it's own default input method
<Keybuk> http://bugzilla.gnome.org/show_bug.cgi?id=155010
<Keybuk> ^ that's quite sexy too
<seb128> yep, I was just reading this one
* daniels punts the bug back to seb.
<seb128> who is taking care of this part of gtk ? owen ?
<daniels> i wasn't just blindly reassigning to gtk to annoy you, y'know :)
<seb128> yeah, but you could have added some details :)
<Keybuk> yeah, Owen seemed to think this all belongs in some super-shared-common-IM-method
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=88639
<elmo> straw poll: what do folks do for laptops and their mail domain?  I set mine to a random mail domain I own/control, but what does anyone do who doesn't do that?
<Kamion> I use the house domain
<lamont_r> elmo: ditto
<Kamion> er, not literally "house"
<lamont_r> Kamion: not familiar with .house... :-)
<Treenaks> .local?
<Kamion> .lab.dotat.at actually
<elmo> I wonder what folks who don't have a handy mail domain are meant to do tho?
<elmo> (other than: get one)
<Keybuk> elmo: I use the name of the laptop when it's at home
<azeem> I am using SMTP-auth to get my mail delivered by my MSP, if you mean that
<Treenaks> I set my laptop postfix to use my own server as a smarthost (using SASL and TLS).. and it adds "@foodfight.org" to unqualified addresses
<lamont_r> interesting... my house appears to have dropped off the net.
<Treenaks> lamont_r: again?
<Treenaks> lamont_r: (press F10?)
<lamont_r> Treenaks: well, it is cold and snowing today
<Treenaks> and USA ;)
<lamont_r> nah - not the F1 borkage.  the '18 miles of 802.11 is sometimes flaky' borkage
<Treenaks> ah
<sivang> anybody seens silbs here?
* lamont_r watches the iso eta in rsync bounce around between 2 minutes and 6 hours
<lamont_r> last night, I noticed that rsync does integer math for % as well...
<Treenaks> that's bad?
<lamont_r> that is, it doesn't say 1% until > 1%, rather than for anything from .5-1.5
<lamont_r> not necessarily
<lamont_r> Treenaks: the f1-b0rkage only affects email.  the wifi-and-weather b0rkage is more complete.
<Treenaks> lamont_r: so it seems (No route to host)
<lamont_r> yeah
<lamont_r> it's really foggy and cold out there - that'll mess with things
<Treenaks> so now  the real lamont is gone we can gossip about him!
<daniels> elmo: could you please sync docbook-xml?
<lamont_r> heh
<elmo> done
<daniels> elmo: cheers
<elmo> how evil would it be to use foo.local for mail fqdn's for a laptop?
<daniels> elmo: also, could I please get linux-headers-2.6.10-* on davis, halley, and concordia?
<elmo> gar, I need history exclusion so that commands with the words 'halt' or 'reboot' don't get stored in there
<daniels> elmo: as well as libxxf86misc-dev, libxtst-dev, libxxf86vm-dev, libxinerama-dev and libqt3-mt-dev on concordia
* lamont_r chuckles in sympathy
<robtaylor> hey, out of interest, when do the selection of core packages for hoary freeze?
<ogra> http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule
<Kamion> technically it froze some time ago
<ogra>  November 29th, SeedFreeze ?
<Kamion> that'd be the one
<fabbione> mjg59: yes... 
<sivang> and UVF is 12th Jan right?
<fabbione> mjg59: LKML: [PATCH]  swsusp: properly suspend and resume *all* devices <- do we need that?
<elmo> daniels: done
<fabbione> elmo: *cough*sparc*cough* :P
<robtaylor> Kamion: i noticed that, hence why i ask :)
<daniels> elmo: cheers dude
<elmo> fabbione: right
<fabbione> whooooo! this 8 lines bash script to parse bk output is so raaad!
<fabbione> i can get to see upstream changes almost as fast as they commit
<lamont_r> fabbione: ENOTPYTHON?
* sivang politely asks fabbione what is bk :)
<lamont_r> bitkeeper
<sivang> lamont_r: tnx
<fabbione> lamont_r: not for cd linux-2.6; bk pull and a couple of grep
<lamont_r> fabbione: anything besides kernel-wedge and build-essential for that chroot?
<lamont_r> and l-s b-d's of course
<fabbione> as output i get each single changeset in a separate diff -ru file
<fabbione> lamont_r: no. only kernel-wedge from ubuntu
<fabbione> all the others do not matter
<lamont_r> you're going to want to dpkg-buildpackage, no?
<fabbione> hmmm yes
<lamont_r> ok
<pitti> mvo: ping
<fabbione> they have included UML support in 2.6.11
<pitti> fabbione: hey, finally?
<pitti> fabbione: it took me a while to get UML running for 2.6.7 back then
<lamont_r> fabbione: any xen patches?
<daniels> christ svn is slow
<daniels> it's almost making arch look good :P
<mvo> pitti: pong
<fabbione> pitti: it looks like a tons of patches went in in bk7
<fabbione> lamont_r: checking...
<fabbione> apparently no
<elmo> I don't think of all xen is getting merged any time soon, there's been lots of discussion over it
<lamont_r> elmo: yeah, figured that part.
<Kamion> daniels: highly server-dependent - you using bdb or fsfs?
<lamont_r> it's almost as bad for part of it to get merged, depending on the speed of both sides, and how ugly the split between accepted and not is...
<fabbione> elmo: btw did you get the mail from doko for the gcc ppc64?
<fabbione> i am holding a bunch of patches for ppc64 kernel
<elmo> fabbione: no?
<fabbione> elmo: Subject: powerpc chroot
<elmo> fabbione: sent when/where to?
<azeem> "But the only free GNU/Linux distro I know of is UTUTO" -- Richard Stallman
<fabbione> elmo: you and me
<fabbione> elmo: elmo@c.c
<daniels> Kamion: dunno, whatever Overfiend uses
<fabbione> daniels: hmm i don't have problem with svn on necrotic....
<lamont_r> azeem: I don't think he's referring to us - we include non-free stuff, you see.
<azeem> lamont_r: he doesn't know I guess - jdub once told him you were not
<lamont_r> azeem: it's not in main, but it's available
<daniels> fabbione: getting diffs is arse-slow
<azeem> yeah, I know. But RMS is incredibly slow on news in the Free Software world
<daniels> i'll tell you exactly how long it's taken, once it finishes
<daniels> which could be any time from now until 2016 :P
<fabbione> ahhaha
<fabbione> daniels: are you sure you are not on a 28.8k modem?
<daniels> yeah :)
* sivang notes that thanks to poland, EU is supposed to be software patent free.
<Keybuk> sivang: it would be more accurate to describe the current situation as "software patents discouraged"
<lamont_r> azeem: www.ututo.org
<azeem> oh
<sivang> Keybuk: ok :) noted.
<lamont_r> and rms is visiting them
<azeem> lamont_r: I honestly though he forgot the spelling :)
<azeem> thought
<lamont_r> nah - he's better than tat
<lamont_r> that
<fabbione> lamont_r: did you notice that your cupsys upload is FTBFS?
<lamont_r> azeem: the question comes down to: do you want to include only free software in the distribution, or do you want it to "just work" for users.
<lamont_r> the first one is great once you own the market, until then, users will just install windows.
<lamont_r> fabbione: sigh
<daniels> fabbione: a bit over 5 minutes to do a single diff.
<azeem> lamont_r: well, I thin restricted is a nice idea, dunno whether multiverse has anything interesting in it to warrant its existence
<fabbione> daniels: can you give me the command?
<fabbione> i want to check from here
<azeem> lamont_r: in any case, I just thought it was a nice typo, didn't want to start a non-free discussion :)
<daniels> fabbione: svn diff -r 2011:2017
<lamont_r> fabbione: WTF is there a patch patching the debian directory?  GAH!
* fabbione isn't suprised...
<daniels> lamont_r: that's not fabbione's fault, to be fair
<lamont_r> daniels: I know that
<fabbione> daniels: i didn't take it personally...
<lamont_r> worst part is that one of us added it.
<daniels> heh
<Keybuk> yeah, people who make patches that do that should be hung, drawn and quartered
<Keybuk> *eyes pitti with the meat cleaver in hand*
<lamont_r> Keybuk: how did you know I was gonna accuse him?
<fabbione> Keybuk: using dpatch is so easy to get caught in that shit...
* pitti gets out his asbesto trousers
<fabbione> no guys you are all wrong
<fabbione> it's GTK FAULT!
* lamont_r fetches cupsys to shoot it
<Keybuk> to be honest, I'm pretty unhappy with patching the source tree in general
<pitti> if cupsys had a sane way of patching in the new japanese stuff (instead of doing weird things in debian/rules and with uudecode), I wouldn't have to do these weird things in the first place...
<lamont_r> Keybuk: dpatch or otherwise?
<Keybuk> lamont_r: patches in debian/patches patching the .orig.tar.gz
<fabbione> Keybuk: hey.. that's cool.. you can get to maintain the kernel with no patches :-)))
<Keybuk> you end up with debris in .diff.gz, or worse, non-functioning patch or unpatch targets
<lamont_r> Keybuk: ah, that complaint
<Keybuk> (or amusing patches-containing-themselves)
<pitti> lamont_r: if you want to directly modify debian/, then please do further syncs yourself
<Keybuk> fabbione: doesn't the kernel use a dbs-style patches-patch-a-tarball
<lamont_r> pitti: plan o
<fabbione> Keybuk: no. dpatch
<lamont_r> plan to
<fabbione> Keybuk: see quotes
<pitti> lamont_r: after spending hours to sync cupsys I just had to separate the ubuntu changes into their own patches
<fabbione> Keybuk: i would love to make it dbs...
<pitti> lamont_r: this makes it _much_ easier
<Keybuk> pitti: m-o-m seemed to sync cupsys ok to me
<lamont_r> debian/cupsys.init.d just doesn't change that much
<pitti> Keybuk: when I synced it back then, it was a mess
<pitti> Keybuk: OTOH the current packaging is a mess in itself
<pitti> Keybuk: so it cannot get much worse by patching 
* lamont_r decides to keep pitti happy instead
<Keybuk> which reminds me
<Keybuk> elmo: when you get a free moment or two, could you look over my proposal at http://www.dpkg.org/NewSourceFormat and be critical?
<fabbione> i can't even get to connect to dpkg.org
<mdz> tech board meeting starting in #ubuntu-meeting
<lamont_r> fabbione: works for me
<mjg59> fabbione: Yeah
<mjg59> fabbione: We probably want the O(n) swsusp stuff, too
<lamont_r> pitti: so WTH do I use to edit ubuntu-init.d.patch?
<fabbione> daniels: it took 10 minutes here
<fabbione> daniels: i will talk with OF
<daniels> fabbione: so it's not just my modem ;)
<pitti> lamont_r: copy the source tree and use diff -u?
<daniels> fabbione: this is merging back all the relevant debian changes (typo fixes) to xorg
* lamont_r pukes
<pitti> lamont_r: sorry, with a proper packageing system (like dbs or cdbs+tarball) you get better tools
<lamont_r> pitti: it uses cdbs
<Keybuk> fabbione: I think thom's IPv6 route has gone down, so you probably have to wait for timeout and fallback to IPv4 :p
<fabbione> Keybuk: make sence
<daniels> mjg59: ping
<mjg59> daniels: Yo
<daniels> mjg59: so, how's vbetool coming along?  if it still uses x86emu, wouldn't mind stealing it to do ddc probes at some point in time so we can get ddc over vbe on amd64
<fabbione> mjg59: yeah but i lost the mail with the patch O
<mjg59> fabbione: Haha
<fabbione> mjg59: can you forward it to me again?
<mjg59> I'll try to dig that out at some point
<fabbione> thanks
<mjg59> daniels: vbetool is basically done, but doesn't use x86emu
<mjg59> I could probably write a small layer that munges lrmi stuff onto x86em
<daniels> mjg59: ahr.  weren't you doing one with x86emu at some stage, or have I been smoking too much of the good stuff again?
<mjg59> video_post used x86emu, but Mike Harris said that vm86 mode was less crackful
<daniels> ah, right
<daniels> yeah, vm86 is less cracktastic
<daniels> but about 100% less amd64-friendly
<daniels> if you don't have time, i'll probably have to get to it sometime pre-hoary, so I'll do it before then
<mjg59> It's pretty easy to do, you just need to replace the lrmi calls with x86emu ones
<daniels> mmm
<fabbione> daniels: it took me only 49 seconds now to do the same diff
<mjg59> Oh, and you ought to get in touch with scisoft and try to find out if there's a newer version of x86emu that they can provide
<fabbione> (after i stopped saturating my bw)
<daniels> fabbione: weird
<daniels> fabbione: my bandwidth is untouched, this aside
<mjg59> The one on their ftp site is ancient, and xfree and xorg have both diverged in different directions
<daniels> (well, I have the Ubuntu mirror trickling in at 15kb/sec, but this is a >1.5MBit line)
<daniels> mjg59: the one in X.Org was allegedly from Kendell and SciTech
<mdz> doko: if you are available, please /join #ubuntu-meeting
<daniels> (i.e. one of the 6.7 items was resyncing x86emu from upstream)
<daniels> but yeah, I'll probably give him another poking
<mjg59> Ok, in that case grabbing it is probably the best bet
<daniels> yah
<mjg59> Oh, I need to figure out why vbetool vbemode get returns wrong stuff
<mjg59> But I think that's probably me fucking up with the specs
<daniels> heh
<daniels> i was agonising for ages over why the dtimings in ddcprobe were broken
<daniels> thinking i'd screwed up the formula
<daniels> but once I threw away the code to get it out of the EDID block and rewrote it, it was fine
<daniels> hm, have to be up in 3.5 hours.
<daniels> 'night
<lamont_r> fabbione: your chroot is ready.  dchroot sid
<fabbione> lamont_r: cool. i will start on it tomorrow
<lamont_r> thanks
* lamont_r really wants focus-follows-eyes
<lamont_r> fabbione: well, dchroot -c sid, or just plain 'dchroot'. 
<fabbione> lamont_r: ehhee.. did you install distcc ???
<lamont_r> in the chroot?
<fabbione> ggg was mentioning it.. or otherwise ccache
<fabbione> yeah
<fabbione> if there is space i would prefer ccache
<lamont_r> uh, yeah.  and ccache in a second
<lamont_r> just chain the 2 together.. :-)
<fabbione> i am not sure you actually can...
<fabbione> but anyway make-kpkg doesn't fork
<fabbione> that's why i prefer ccache
<lamont_r> fabbione: ccache installed
* fabbione hugs lamont 
<lamont_r> ggg is mostly doing 'make', not make-kpkg
<fabbione> yeah that's why....
<mdz> is workrave fucked for anyone else?
<ogra> doe that thing still exist ?
<ogra> does even
<ogra> oh....confused it with workman :)
<lamont_r> hell.  hoary goals meeting is right on top of 'pick up the kids'
<thom> mdz: i can try upgrading, but my laptop is basically ~mataro level hoary right now
* lamont_r uploads cupsys, proud of his changelog entry
<lamont_r> well, maybe 'proud' overstates it a bit.
<mdz> thom: welcome back
<thom> mdz: thanks, kinda. i'm on my parents dialup curreently :(
* lamont_r heads home to find out why it dropped offline
<mdz> elmo: I think we're about due for a seed/archive resync
<pitti> elmo: is there a i386 hoary dchroot out there with linux-tree-2.6.10 installed?
* mvo leave to play some hockey before the meeting tonight
<pitti> mvo: have fun
<mvo> I will :)
<mvo> see you later pitti (and the others)
<pitti> mvo: I look forward to go to Taekdowndo again after four weeks :-)
<mvo> I wonder if I will manage to hit the ball after 4 weeks without any practise :)
<thom> urk, speaking of seeds i need to write that BOF up and update the seed lists
<elmo> mdz: hum? I did one this morning
<mdz> thom: "so, about those pending seed updates" is on the agenda :-)
<elmo> pitti: err, possibly not, I think the i386 machine got morphed into the librarian
<thom> mdz: heh
<elmo> I'll look into creating another one
<mdz> elmo: oh, good.  I hadn't bothered checking since last night
<pitti> elmo: okay, thanks
<elmo> pitti: what was the final consensus on mmv ?
<pitti> elmo: I change the patch to do without
<mdz> pitti: you don't have an i386 hoary chroot?
<pitti> mdz: i have
<pitti> mdz: my desktop is hoary i386
<elmo> pitti: I'm not particularly fussed either way
<pitti> mdz: but compiling the full suite of i386 kernels takes veeery long on my machine
<mdz> pitti: using ccache?
<pitti> elmo: I know that it is not a nice solution, but it was a quick fix for Debian
<pitti> mdz: doesn't work, because each kernel has different processor targets
<pitti> mdz: no problem, after all
<pitti> mdz: I can do it on my server, too
<mdz> pitti: eh?
<pitti> mdz: -k7, -686, -386 and so on
<mdz> pitti: yes, but once you've built them all once, you have them in cache
<mdz> assuming the cache is large enough
<pitti> mdz: but as soon as I change a configuation option I have to rebuild anyway
<pitti> mdz: as I said, it's not a big problem
<pitti> mdz: I have amd64 and ppc chroots
<pitti> mdz: and I can do i386 on my own
<mdz> pitti: when you only change a configuration option, ccache should be a big win
<pitti> mdz: sure, might be worth a try
<mdz> pitti: I use it all the time
<pitti> mdz: me too, for other projects
<mdz> especially for the kernel
<pitti> mdz: what is required to make it work for the kernel?=
<pitti> mdz: it is not automatically used for me if I build the kernel
<mdz> pitti: nothing
<mdz> oh
<mdz> I use PATH=/usr/lib/ccache:$PATH
<wasabi_> I need to be educated on the ubuntu version names. I see ubuntu1,2 are added at the end. This makes debchange behave right, and the versioning work.
<pitti> mdz: me too
<mdz> so, for everything
<wasabi_> What if *I* wanted to fork my own package.
<mdz> works for me with the kernel
<wasabi_> 1.2-0ubuntu1me1
<wasabi_> ?
<mdz> wasabi_: this is a difficult question
<pitti> mdz: hmm, I look into this again
<pitti> mdz: oh right, now my ~/.ccache is 1.6 GB :-)
<pitti> mdz: it was empty the last time I looked. My fault
<wasabi_> I think ubuntu1me1 will work out right, if it's alphabatized...
<azeem> wasabi_: why not ubuntu1.1?
<wasabi_> Im not sure what happens in the processing if I add another . to the version
<mdz> wasabi_: if you want it to be greater than ubuntu1, but less than ubuntu1.2, yes, that's what you want
<wasabi_> oh. does that work?
<azeem> dunno :)
<mdz> wasabi_: it's just a matter of choosing a version number which compares the way you want.  you can test it with dpkg --compare-versions
<mdz> wasabi_: but things get complicated when you consider that there are already multiple versioning schemes in use, in Debian and in Ubuntu
<mdz> brb, reboot
<mdz> seb128: hmm, System->Logout is hanging for a long time
<mdz> seb128: the System menu is still highlighted, but there is no logout dialog yet
<seb128> it's going to pop up in 30s
<pitti> Ubuntu - nothing for the impatient :-)
<seb128> you probably have an app which registred in the session in a wrong way
<mdz> hmm
<mdz> this happened on my last logout, too
<seb128> not easy to find which one
<mdz> it has been 2 minutes and it is still not up
<mdz> I am not running anything strange in this session
<mdz> the same things I always do
<seb128> there is a timeout, I thought it was 30s, perhaps 1min
<mdz> gnome-terminal, gaim, firefox, xchat
<seb128> these apps have not changed for week
<mdz> 3 minutes now
<seb128> neither gnome-session
<seb128> hum
<mdz> hmm
<mdz> gnome-session is not running
<mdz> I imagine that is not normal
<ogra> fabbione: hisax oopses...mvo is right....
<mdz> so now my panel is hung due to the menu still being active
<seb128> mdz: nop, not normal
<seb128> not normal at all
<mdz> seb128: I am using a session which I saved a long time ago (warty timeframe), could that be a factor?
<mdz> do I need to re-create it?
<seb128> should not
<seb128> you can try to move ~/.gnome2/session away
<seb128> just to see if that helps
<mdz> how do I get out of my current mess?
<mdz> zap the X server?
<seb128> what's hanging ?
<seb128> the panel ?
<mdz> I can't log out; System menu is still highlighted
<mdz> and gnome-session doesn't seem to be running
<seb128> killall gnome-panel
<seb128> that's weird
<mdz> try logging out again?
<seb128> yep
<mdz> oh, gnome-session is running
<seb128> but you are sure that session is not running ?
<mdz> it is called x-session-manager
<mdz> second attempt to logout is hanging also
<seb128> $ ps ax | grep session
<seb128>  4392 ?        Ss     0:00 /usr/bin/gnome-session
<mdz> mdz       7162  0.0  0.4  18548  8796 ?        Ss    2004   0:02 x-session-manager
<mdz> lrwxrwxrwx  1 root root 22 2004-11-30 15:34 /etc/alternatives/x-session-manager -> /usr/bin/gnome-session
<seb128> how do you start your session ? 
<seb128> gdm ?
<mdz> logging into gdm
<mdz> I must be using 'default system session' or whatever, rather than GNOME
<seb128> what happen if you run gnome-session-save ?
<seb128> probably yes
<mdz> it exits instantly
<seb128> and creates ~/.gnome2/session ?
<mdz> err
<mdz> my gnome-terminal became unresponsive
<mdz> I launched a new gnome-terminal, and that is unresponsive too
<mdz> my keystrokes do nothing
<mdz> other applications are fine, though
<seb128> WTF
<mdz> I launched an xterm from a text console
<mdz> ~/.gnome2/session does not exist
<seb128> ok, so it doesn't save correctly ... something running is broking it
<mdz> I wonder if it's workrave
<mdz> my workrave is fucked
<mdz> I have no idea why
<mdz> oh, hey, there is a dialog open
<mdz> these windows do not support "save current setup" etc.
<seb128> saying what ?
<mdz> it opened behind a window
<mdz> I closed it, and got a dialog saying that my session was saved
<mdz> and I can talk to gnome-terminal again
<seb128> ok
<mdz> and ~/.gnome2/session exists
<mdz> that dialog should probably open on top, considering that it freezes everything
<seb128> yep, one more candidate for #3159
<mdz> I killed workrave, it is not running at all
<ogra> i think i read about a metacity focus bug anywhere last week
<mdz> so that can't be it
<mdz> seb128: anything else I can try before killing X?
<seb128> not really
<mdz> ok, brb
<seb128> mdz: something registred wrongly in the session and fucked it probably, killing the app doesn't help (the session waits for some informations that the app should provide or something like that ... killing the app doesn't help to get them)
<mdz> seb128: I noticed something strange; in the Add to Panel dialog, the Add button has a '+' on it, but when I highlight one of the applets to add it, the '+' disappears and the button just reads [    Add ] 
<seb128> yep, that's #4999 (gtk bug, fixed upstream now)
<mdz> ah, thanks
<mdz> I wonder if workrave will work again now
* pitti goes to Taekwondo. See you later at the meeting
<pitti> mdz: I should return 5 minutes before 2200 UTC
<mdz> seb128: hmm, workrave works again
<mdz> seb128: I wonder if these two things were related
<mdz> seb128: the logout dialog works properly also
<seb128> no idea
* ogra still would blame metacity.......
<seb128> I hate this kind of bugs, most of the time that's impossible to find the root
<seb128> ogra: for what ?
<ogra> for breakage like not bringing windows to front if they should have been....for probs with workrave at the same time.....
<ogra> sounds suspicious like a WM prob
<mdz> ogra: I think I agree with you
<mdz> the workrave problems seemed WM-related, now that I think about it
<mdz> it would hang at exactly the time when it should have opened a window
<mdz> i.e., when the timer ran down
<ogra> it probably has opened a window.....behind another like gnome session did.....and blocked the desktop ....
<seb128> that's not a metacity bug
<seb128> that's an app bug
<seb128> the app has to update its timestamp
<abelli> seb128: do you know anything about the kb's layout thing?
<seb128> oups, sorry, I've forgotten the other chan
<seb128> better to highlight me :p
<ogra> seb128: even if i program a gtk window as popup i have to update a timestamp to get my focused win to top ?
<seb128> you have to specify than the app has to take the focus yes
<seb128> that's the principe of the "focus stealing prevention"
<seb128> = don't steal the focus if not needed
<lamont> hrmpf.  gonna have to get another fan
<seb128> and the way to do that is to not steal the focus if an app doesn't ask for it
<ogra> sure, but i thought it is a property i set in the sourcecode.....(especially for a blocking app like the "save apps that are not session aware" or workrave)
<seb128> http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00306.html
<seb128> read this for details
<ogra> thnks :)
<seb128> that's some code example and all the details
<seb128> np
<ogra> hmm, i understand the focus thing, but it still doesnt explain why "on top" windows dont get on top (i.e. my gaim windows pop up above all others, they just dont grab the focus...
<ogra> )
<ogra> and thats a WM thing imho
<mdz> ogra: I don't think it had a window open; I killed it and restarted it
<ogra> <mdz> it opened behind a window
<ogra> <mdz> I closed it, and got a dialog saying that my session was saved
<mdz> ogra: that was the gnome-session-save window
<mdz> workrave didn't open anything
<ogra> thats what i'm talking about....
<ogra> workrave too...but in first place i meant this message from you...
<seb128> ogra: the app define if the dialog if toplevel or not
<seb128> s/if toplevel/is toplevel/
<ogra> yup
<seb128> so I don't get why you think that's a wm bug
<mdz> the workrave dialogs always stay on top
<mdz> and even so, I looked around
<mdz> workrave was somehow in a very broken state
<mdz> and also the logout functionality
<mdz> both were fixed when I restarted
<ogra> seb128: becaues the WM is the app that recives the definition....and if more then one app is behaving faulty in this direction i would suspect the reciever here, not the sender
<seb128> ogra: the app has to said if the dialog should take the first plan/the focus
<seb128> gnome-session doesn't do that correctly
<seb128> metacity has nothing to do with that
<ogra> k
* lamont finds his opinion of someone affected by their reply of "Cool. Thanks for the 411 LaMont!"
* Kamion kicks the kernel
<Kamion> 411? heads-up?
<cartman> is there a way to see packages in "pendingupload" state?
<seb128> select the pendingupload state in the bugzilla search form ?
<cartman> that should work. thanks
<lamont> Kamion: US-ism: 411 is the phone number for directory assistance, aka "information"
<Kamion> lamont: aha
<lamont> Kamion: it's one of those "only popular in marketing circles" kind of phrases
<wasabi_> How in the world can ant be in multiverse, when a ton of it's build-deps are
<wasabi_> aren't that is
<Kamion> hm? multiverse's dependencies and build-dependencies are allowed to be in other components
<Kamion> unless you mean *reverse* build-dependencies
<lamont> wasabi_: the builddeps can be in main, restricted, universe, or multiverse
<Kamion> and the answer to that is that dep/build-dep closure is only enforced for main and restricted
<lamont> Kamion: debian contrib/ went into universe?  or only as requested?
<elmo> contrib -> multiverse
<elmo> +what we could of non-free
<wasabi_> well... it's not in any of em
<wasabi_> ant 1.6 is in multiverse, but it's missing a ton of deps... that I can see anyways
<elmo> ant is in multiverse, it just didn't build
<wasabi_> and some how, one of it's binaries (ant itself) is missing... or I can't find it. Or Im stupid.
<wasabi_> Just trying to rebuild it. ;0
<wasabi_> guess I could just grab it all from hoary and backport it, if it works there. =/
<wasabi_> nope.
* fdhgfhgf slaps seb128 around a bit with a large trout
<Treenaks> yay! more seb-slapping ;)
<ogra> huh ?
<Treenaks> ogra: he came in. slapped seb, and left.. must've been a hoary user ;)
<ogra> i saw it .... :)
<wasabi_> There should totally be some sort of .revoke file for archive uploads.
<mdz> lamont: marketing circles and 12-year-old girls
<Treenaks> s/and/of/ ?
<ogra> Treenaks: i was wondering if mark is in .za .......
<lamont> mdz: hadn't encountered the second case.
<lamont> this person was "working on compiling postfix on another linux distro"
<mdz> lamont: maybe a regional difference
<lamont> yeah - mostly a bi-coastal thing, iirc
<mdz> Kamion: when a bug turns out to be a duplicate of a Debian bug, I just add the deb<num> alias, which imports the comments from debbugs and links it for debzilla
<lamont> mdz: awesome thing to know
<mdz> yeah, should be much easier than nagging me to import bugs
<mdz> since I was in the habit of importing bugs myself, I didn't think to do it this way until I saw doko do it
<sladen> mjg59: regarding your note from the other day, what were you saying about framebuffer during hibernate/resume?
<mjg59> Oh, yeah
<mjg59> Ok. We have framebuffer issues.
<abelli> quit
<mjg59> Before any userland code is run, the kernel will try to printk "Back to C"
<sladen> mjg59: riiight.  You were saying it might be possible
<lamont> mdz: so basically, you're a copy cat?   I'm shattered. :-)
<mjg59> This is likely to confuse vesafb
<lamont> mdz: mind you, I'd have never thought of it either
<sladen> mjg59: what's the 'Back to C' for?  is that C as in the language, or C as in the processor state/
<mjg59> C as in the language - it gets printed once we're back in the kernel
<sivang> mjg59: when I snap my laptop from the suspend, it does produce some kernel messages now in text mode but never goes back to X properly, that is it starts it up and screen=blank, and I disabled the framebuffer in the Xorg conf.
<mjg59> sivang: And you've tried pressing keys?
<mdz> isn't the mono VM called "CLR"?
<mdz> the mono packages say "CLI"
<sivang> mjg59: yes
<mjg59> What happens if you suspend from a text console?
<sladen> mdz: clr == runtime  cli == interpreter (?)
<sivang> mjg59: it never displays the text messages, and nothing happend.
<mjg59> sivang: ?
<ogra> sladen: are you still the man for the cpufreq detect stuff ?
<sivang> mjg59: the sleep.sh work only from within Xorg
<mjg59> sivang: In what way?
<mjg59> Does anything appear in dmesg?
<sladen> mdz: sorry, cli == infrastructure
<sivang> mjg59: in a way that I can see the kernel messages when it awakens
<mdz> ah
<Kamion> mdz: oh, it does that automatically?
<sladen> ogra: what issue are you having?
<mjg59> sivang: It sleeps but doesn't resume?
<Kamion> mdz: rock
<sivang> mjg59: yes, as opposed to sleeping from Xorg in which it resumes into some text messages and get stucks.
<mjg59> sivang: That's very odd. The first thing the sleep script does is switch to a text console.
<sivang> mjg59: when I do it from a text console when  Xorg is not running, it won't resume in a way that I can see the kernel messages again.
<ogra> sladen: looks like the speedstep modules are all compiled without the coppermine option....they all complain about "no such option" 
<Kamion> Keybuk: there were a load of changes to doc/manual/build/ in debian-installer that got dropped with the latest merge (20041227); how come they didn't show up in a -dropped file?
<mjg59> sivang: What hardware is this?
<ogra> sladen: but your script uses it on all my coppermines just fine here ;)
<Keybuk> Kamion: I don't know ... will have to look
<Kamion> Keybuk: some of them appeared, but the cases where the files to which the patches applied had been moved didn't get -dropped files
<mjg59> sladen: The only framebuffer we stand any real chance with is vesafb
<sladen> ogra: that was from an unconfirmed report I had.  you can pass  relax_check=1  to force it try regardless of whether it finds the correct magic or not
<Keybuk> interesting ... could be a bug :)
<sivang> mjg59: ergh, don't ask :)
<mjg59> sivang: It's difficult to help otherwise
<Keybuk> I definitely didn't take into account the patch failing because the file didn't exist
<Keybuk> maybe it doesn't notice
<mjg59> sladen: Well, with the possible exception of vga16fb
<sivang> mjg59: I will have all details for you later tonight if you'll still be online.
<mjg59> sladen: What level of framebuffer functionality do you want?
<mjg59> sivang: Yeah, should be
<sladen> mjg59: I'm fine with vesafb the PC99 & legacy specs /require/ a VESA interface that can do 800x600x256 anyway
<sivang> mjg59: k.
<ogra> sladen: i just wanted to point it out... if its a option you can set by make menuconfig and has probably been forgotten.....
<mjg59> sladen: Problem with vesafb is that it doesn't actually use the vbe calls to do the screen setup
<sladen> mjg59: s/legacy/& free/
<mjg59> Which breaks on some hardware
<sladen> mjg59: oh geeze, why ever not?  surely that's what interfaces are for
<mjg59> Oh, no, hang on
<mjg59> I'm thinking of vga16fb
<mjg59> vesafb should work fine
<mjg59> But it still doesn't call things neatly
<mjg59> If you ask what vesa mode you're in on a vesafb console, it'll say "3", which is 80x25 text mode
<mjg59> So the issue is basically the following:
<mjg59> 1) We need to get the video hardware back into the state that vesafb is expecting
<mjg59> 2) We need to make sure vesafb doesn't explode everything first
<sladen> mjg59: while we're on the subject, what is the bios=irq doing;  is that called the BIOS to configure IRQ routeing instead of ACPI or is it just leaving the mapping as it was found
<sladen> mjg59: stupid question, can we unmodprobe and re modprobe vesafb?
<mjg59> sladen: Linux used to enable interrupts even if hardware hadn't asked for them to be routed
<mjg59> That worked fine over suspend/resume
<sladen> mjg59: ''vesafb0 does not have a release() function and needs to be fixed''
<mjg59> Now it only does so if asked, which /should/ work fine over suspend/resume, except that the /old/ state of the interrupt router was restored, without the hardware configuration actually being changed
<mjg59> sladen: rmmod/modprobe will "work" as in stuff won't necessarily break, but it's unlikely to actually /do/ anything
<mjg59> pci=routeirq restores the old behaviour, which works round it
<mjg59> But there's a better patch that actually does the interrupt setup properly
<sladen> righto
<mjg59> I'll make sure it goes into the 2.6.10 stuff
<sladen> pci=routeirq != irq=bios ?
<mjg59> Correct
<sladen> oh ''better patch'', good good
<mjg59> If we're lucky, having stuff printed to vesafb while it's in the wrong state won't actually break anything
<mjg59> But that's not too good a hope
<sladen> mjg59: well, if it doesn't work, that's called a bug and can be fixed until the point that it does
<mjg59> Ok. In that case, we want to do the following:
<mjg59> Work out what VESA mode we're in. Save the state using a VBE call. Suspend. Resume. POST the video. Restore the state. Possibly then restore the mode, though we /may/ not need that.
<mjg59> At that point, if we're lucky, vesafb is alive again.
<mjg59> Though we may not have X at this stage.
<mjg59> Oh, this is probably unneeded for swsusp - the bootloader will have put things in the right mode for us
<Kamion> mjg59: vesafb doesn't currently work on several bits of hardware I have
<Kamion> d-i has to fall back to vga16fb
* lamont wanders a couple miles to snarf bandwidth for a bit
<mjg59> Kamion: Mm? d-i never uses vesafb
<Kamion> it SO does
<mjg59> It's either vga16fb or nothing
<mjg59> It so doesn't
<Kamion> incorrect, sorry
<Kamion> it certainly tries
<Kamion> perhaps it never succeeds, but :)
<mjg59> It tries to modprobe it, but syslinux never passes the kernel a mode=
<Kamion> ah, so we agree vociferously then
<mjg59> So if you have any framebuffer at any point during the install, it's vga16fb
<Kamion> I thought you meant it never even tried
<Kamion> can we fix that in syslinux?
<mjg59> Which breaks on various bits of hardware, because it programs stuff directly
<mjg59> No idea, I'm afraid
<mjg59> I'd guess so - it should just be an option in syslinux.cfg
<Kamion> I don't think many d-i hackers actually know about this, because we wouldn't be using vesafb if it never worked
<Kamion> did it work in 2.4 perhaps?
<mjg59> Nope
<Kamion> hmph
<mjg59> vesafb as a module can /only/ work if the bootloader has set up the video mode already
<mjg59> wakeup.S in the kernel records the video mode, and vesafb checks that when it's inserted
<Kamion> do you happen to know roughly where grub does this? I can't see it
<wasabi_> So how do I go to get ant in multiverse imported properly?
<Kamion> vga= maybe?
<wasabi_> It builds with all free stuff now I believe.
<fabbione> Keybuk: you here?
<mjg59> Yeah, vga=
<Kamion> wasabi_: can we get the Debian maintainer to move it to main if it builds with entirely free code? that would be great for all concerned
<mjg59> I can't remember if that'll work as a kernel boot paramater or not
<wasabi_> Kamion: Hmm. I'll do some research.
<mjg59> Kamion: vga=0x301 should give a 640x480x256 colour screen
<Kamion> syslinux *appears* to try the same kind of stuff grub does
<mjg59> But there'll be no output whatsoever until vesafb is modprobed
<mjg59> Just a black screen for a while
<Keybuk> fabbione: yup
<Kamion> oh, I see
<fabbione> Keybuk: i read the newsource proposal... 
<mjg59> Oh, might be vga=301
<fabbione> Keybuk: wanna talk about it?
<mjg59> Uh. vga=769 
<sladen> mjg59: that functionality needs moving from the kernel-commandline to insmod innovocation so that initrd can select it
<mjg59> (hex->decimal)
<Keybuk> yeah, gimme a few seconds though
<mjg59> sladen: Can't.
<fabbione> Keybuk: since it's time for changes perhaps we can enanche also other bits
<sladen> mjg59: cya?
<mjg59> It's not vesafb that does the mode change. It's the bootloader.
<sladen> mjg59: YOU.  ARE.  KIDDING.
<mjg59> Haha. No.
<Kamion> vga=769 works here, and I get vesafb in d-i. interesting.
<Kamion> except I get a red screen rather than the blue one
<Keybuk> Kamion: ok, fixed that bug :p
<Kamion> Keybuk: thanks
<Keybuk> fabbione: right, ready
<Keybuk> lay into me, baby :p
<mjg59> Kamion: That ought to actually make things work better on the machines where vga16fb doesn't work
<fabbione> Keybuk: ahaha
<fabbione> Keybuk: i think the layout is ok, and i would instead enforce the control files in the top level directory.
<fabbione> Keybuk: since it kills debian/, the presence or not of that directory can act as a flag for old and new format
<mjg59> sladen: To do the mode change in kernel, you need to make real mode calls. There's no vm86 support.
<Keybuk> fabbione: that's a reasonable idea, actually
<mjg59> And there's no decent interface in the kernel to make real mode calls
<fabbione> Keybuk: also.. since we are developing a new layout.. i would add a dirctory parallel to build-tree
<fabbione> Keybuk: that i would call src-dep-unpack.
<Kamion> is this a Mark-inspired proposal?
<mjg59> Kamion: Arguably, vga=769 ought to be the default
<Keybuk> oh?  what would you put in that?
<fabbione> Keybuk: rationale: a good bunch of packages shares the same source...
<fabbione> Keybuk: why not introducing a Build-Dep: src:foo (>= 2.0-2) ?
<fabbione> Keybuk: that directory will contain the source for foo unpacked and patched
<Kamion> I think that should be a different field name, not an overloading
<Keybuk> fabbione: my theory on that was that you'd just share the same file in the tarball
<Kamion> Source-Depends: is the traditional name used in proposals for that field
<fabbione> Kamion: sure.. i am just firing the ideas.. improvements are more than welcome :-)
<Keybuk> feel free to comment on the Wiki as well
<fabbione> Keybuk: not another wiki account please!
<mjg59> sladen: So, uh, suggestions for how we do this sanely? :)
<Keybuk> Kamion: not exactly, the debian directory fell out with my own plans -- but it'd certainly keep Mark happy :p
<fabbione> Keybuk: i am not sure how you want to share the same tarballs
<Kamion> yers
<fabbione> Keybuk: i might have a package (like Xprt) that needs some code on its own and Xorg source....
<fabbione> Keybuk: how would the layout  looks like?
<Keybuk> interesting, I hadn't realised there was that requirement
<Kamion> gcc-ssp might be a good test case too
<Keybuk> it'd want the patched Xprt source?
<fabbione> well this is one that pops to my mind...
<Kamion> or binutils-hmwhateverthehellitis
<Keybuk> uh, Xorg source even
<fabbione> Keybuk: Xprt is really a special case.. but it touches a corner case.. it needs xfree86+patches and xprg from xorg patched...
<fabbione> Keybuk: yes.. i am talking about source...
<fabbione> + the normal Build-dep
<Keybuk> it'd cause a huge increase in the amount of disk space you'd need for those packages (if you were building both anyway)
<fabbione> and yes.. also what Kamion said... gcc+ssp is another more common case
<fabbione> or the kernel+PAX
<fabbione> Keybuk: no.. in the specific there is no need to build all of X to get Xprt...
<Keybuk> yeah, but if you were building X anyway, you'd have to unpack X twice
<fabbione> Keybuk: but if all the source is not there, some extensions are not compiled...
<Keybuk> another thing to do would be to require source-depends are unpacked alongside
<Keybuk> so for each, check that ../<package>-<version>/build-tree exists
<fabbione> Keybuk: that's why you need a special dir where to unpack them
<fabbione> but it's not your problem to unpack them
<sladen>           /* Video mode selection support. What a mess!  */
<sladen>           /* NOTE: Even the word "mess" is not still enough to
<sladen>              represent how wrong and bad the Linux video support is,
<sladen>              but I don't want to hear complaints from Linux fanatics
<sladen>              any more. -okuji  */
<fabbione> you only need to do the apt-get source dance in there
<fabbione> or something similar considering that you might not have net access at build time
<fabbione> but that can be worked out easily
<fabbione> and it would still be the top level source responsability to unpack the Source-Build-Dep
<fabbione> that's not a dpkg or whatever problem
<Keybuk> *nods*
<fabbione> so you are not binded to have a unpacked/patched target in debian/rules.. and all the problems that comes with it
<fabbione> does it make any sence to you?
<fabbione> actually..
<fabbione> do i make sence?
* fabbione ponders smoking some more crack..
<fabbione> Keybuk: also.. have a very well defined format for the patches...
<Keybuk> the current proposal just has an unpack target to unpack tarfiles and apply patches
<fabbione> like they must apply with patch -p1 to the source
<Keybuk> I've been considering instead going with a list of instructions
<fabbione> yeah.. i read it...
<fabbione> but my original request was to add a directory where to do certain stuff.. like Source-Build-Dep :-)
<fabbione> if that's standardize we will not see 1000 of different implementations later
<fabbione> that will require another change to get fixed
<fabbione> leading to a more complete and adopted standard ;)
<Keybuk> yeah, I know :)
* fabbione is impressed of his own words....
<Kamion> I have a suspicion that if you restrict patch formats too much you'll see reimplementations, but I can see the benefits of requiring -p1
<fabbione> boys.. this crack is good... anybody wants a bit?
<Kamion> but it does mean that people can't always just take patches from upstream verbatim and drop them in
<fabbione> Kamion: -p1 was an example.. it can -p2 or -p0 or whatever
<sladen> mjg59: have you seen the raw Hercules (0xb800) debugging in acpi/wakeup?
<fabbione> Kamion: otherwise let's define a patch header...
<mjg59> sladen: Yeah. It's a bit sick.
<fabbione> Kamion: like #!/usr/bin/patch -p$X
<fabbione> # mandatory header that explain wtf is the patch about
<fabbione> # origin
<fabbione> # notes:
<fabbione> <patch>
<thom> can't we just use dpatch? (/me runs away)
<Keybuk> dpatch is evil
<Keybuk> patches should *not* be shell scripts
<thom> seriously though, storing some metadata in the patch would seem more reasonable than mandating a patch level
* fabbione hangs thom on a wood cross full of benzin and lights the fire
<sladen> mjg59: not to mention if you happen to have a SCSI controller there
<fabbione> Keybuk: no no.. i don't want shell scripts...
<lamont_r> bandwidth. yum
<fabbione> Keybuk: but you can still add a metadata to define the level
<daniels> Keybuk: no, they should be vi scripts, or ed scripts
<Keybuk> then the question comes, how do we put metadata for the tar files?
<Keybuk> daniels: you know diff can create ed scripts, right? :p
<fabbione> Keybuk: what kind of metadata do you need from the tar file?
<fabbione> md5sum? sha1? size? MANIFEST?
<Keybuk> fabbione: name under build-tree (for multiple tar files), origin, notes, etc.
<mjg59> sladen: We should probably strip them, I guess. They do nothing of any use and they might break stuff.
<daniels> Keybuk: yeah
<thom> my brain just suggested uuencoding the tar balls and embedding them in xml
<fabbione> Keybuk: extensions to contents?
* thom goes to get the bleach
<fabbione> Keybuk: where there is an automatically generated part and a manual one for unpacking....
<fabbione> or whatever operation you would like to do
<fabbione> thom
<fabbione> HAHAHA
<Keybuk> thom: perhaps a holiday?
<thom> Keybuk: no, i think those are bad for me
<fabbione> Keybuk: how would you address the flavour problem with one single build-tree directory?
<fabbione> Keybuk: like we do for apache now... we unpack and patch in build-tree
<fabbione> than we clone the dir N times and apply specific patches to each tree
<fabbione> and then we build...
<thom> then we cross our fingers and pray
<Keybuk> fabbione: unpack the tarball multiple times under build-tree and apply different patch sets to it
<fabbione> no actually.. that would be addressed in Source-Build-Dep
<fabbione> because i could make the common package
<Keybuk> fabbione: you'd split the source package?
<fabbione> and upload the 3 different flavour source-dep on it
<fabbione> also
<fabbione> all solutions are valid...
* fabbione tries to think to more corner cases...
<fabbione> we will lose on very small upstream sources....
<fabbione> like the ones that comes out with one 300B .c file...
<Keybuk> for those you'd have to "cd pkg-ver/build-tree" rather than pkg-ver
<Keybuk> basically debian/ and ./ get flipped
<fabbione> putting it in a tar.gz would increase the size ;)
<Keybuk> aren't they already in .tar.gz ?
<Keybuk> there's only one lunatic I can think of who uploads 0-byte .orig.tar.gz with all the package in the .diff.gz
<fabbione> Keybuk: ahahhahahaha
<fabbione> Keybuk: nahh i was thinking to these upstream that do not ship a tar.. but a single 200 bytes .c file
<fabbione> because Debian has sources like this....
<Keybuk> there's no loss over the existing source format though
<Keybuk> you still have to stick the .c file in a tarball
<fabbione> probably a few bytes of overhead..
<fabbione> anyway.. very small detail...
<fabbione> ~<jvw>   libxerces2-java_2.6.2-1warty0.diff.gz
<fabbione> in debian incoming?
<jvw> fabbione: yeah... but there was a problem with it
<jvw> fabbione: so it wasn't accepted
<fabbione> i really don't think it is coming from any of us
<fabbione> since we don't use the warty extension since ages..
<jvw> aborted by a confused ubuntu developerer?
<fabbione> probably we had 2/3 packages that way
<Kamion> we'd be unlikely to be working on libxerces2-java anyway
<fabbione> jvw: when was that?
<jvw> just in
<Kamion> jvw: I don't see that file anywhere in newraff's queue
<fabbione> nope.. that's definetely not from us
<Kamion> oh, upload queue
* fabbione evily thinks that someone is trying to create some kind of debian <-> ubuntu war
<lamont_r> jvw: who signed the changes?
<Kamion> ENOCHANGES
<jvw> .changes is missing I see on second thought
<Kamion> there's a .dsc, but it's only readable by debadmin because it's in the upload queue
<Keybuk> we wouldn't use either "warty" or "0"
<fabbione> mjg59: 5162 <- can you look at this bug?
<mjg59> fabbione: It's pretty much as it says - the vesafb probe fails, but it doesn't return -ENODEV (or whatever)
<Kamion> -ENXIO
<fabbione> mjg59: let me rephrase.. can you cook up a patch for it? ;)
<mjg59> fabbione: Haha
<Kamion> I'm not *totally* convinced it worked properly even in 2.6.8.1 looking at the source; it's hard to tell
<fabbione> Kamion: i don't even want to go there :-)
<Kamion> it's not high-priority because I've worked around it now
<fabbione> that code is so.. hmmm interesting...
<mdz> Keybuk: we did use 'warty' for a time
<Kamion> (so downgrading)
<Keybuk> mdz: only very briefly, and not on that package
<mdz> Kamion: I can't even find that error in the 2.6.10 source tree
<mdz> jvw: there are folks who have started to maintain repositories of backports for Warty; it's possible that they mis-uploaded
<Kamion> mdz: drivers/base/bus.c
<Kamion> search for 'probe of'
<jvw> mdz: backports?! And you release every 6 monhts...
<fabbione> Kamion: we are going to switch to 2.6.10 anytime soon anyway....
<jvw> *sigh*, people are never happy, it seems...
<Kamion> fabbione: from the source it looks to me like it will have exactly the same problem.
<fabbione> jvw: people are happy when you can serve them a slice of your butt.. slaugthed very thin and close to the bone (like we say in italy)
<Kamion> you can see it in drivers/base/bus.c, it just throws away the error
<fabbione> Kamion: i will look at it as soon as a bit more awake...
<mdz> jvw: yeah, I didn't say it was sensible :-)
<Kamion> like I say, not urgent
<fabbione> i have approx 210 patches pending to review for the kernel + hppa
<lamont_r> jvw: yes, backports.
<fabbione> and an increasing amount of bug numbers....
<lamont_r> the same people ask "when will that be in warty"
<lamont_r> fabbione: you know where to get the current hppa kernel from?
<jdub> hi all
<mjg59> mdz: I think that error is only in Xu's patch
<fabbione> lamont_r: bitkeeper?
<mdz> mjg59: it looks like it's part of the vanilla sources, just in a much more generic place than I expected
<mjg59> Ah, ok
<fabbione> bbk in 10 minutes...
<fabbione> time to put my gf to bed...
<lamont_r> cvs.parisc-linux.org.
<lamont_r> let me find the url for you
<mjg59> Bleah. It'll be because Herbert hasn't worked out what fb drivers need in the device model, or something.
<lamont_r> fabbione: http://cvs.parisc-linux.org/download/linux-2.6
<ogra> fabbione: hisax oopses here too.... :(
<ogra> fabbione: no ksymoops.....but i can send a dmesg, lsod, lspci as you like.....
<ogra> +m
<ogra> jdub :)
<mdz> lamont_r: I swear that mcs build log wasn't there when I looked
<lamont_r> mdz: heh
* lamont_r brb
<mdz> ogra: ksymoops is obsolete; the kernel decodes the stack now
<ogra> mdz: so where do i find something helpful then to send to fabio 
<fabbione> lamont_r: thanks.. i really really needed another RCS for the kernel :-)
<fabbione> ogra: ok.. i will check the mISDN site again.. but last time there were no updates...
<ogra> fabbione: anything i can do to help ?
<fabbione> ogra: you will help me testing :-)
<ogra> yep :)
<mvo_> ogra: isdn stuff?
<fabbione> i don't have such card.. so i will need to build some stuff and test
<ogra> mvo_: ahh, great, youre back :)
<mvo_> yes, in time for the meeting :)
<lamont_r> moof
<ogra> it oopses with both pci cards i have here....in one or two weeks i probably can get a teles and a sedlbauer too
<fabbione> ogra: afaics there is only one error in the module init code
<fabbione> lamont_r: that patch is BIG
<lamont_r> fabbione: yeah.
<fabbione> and it touches some bits of common code...
<pitti> Hi guys
<seb128> lamont: could you kick totem build ?
<lamont_r> about 20k or so of it is from the last week or two
<lamont_r> seb128: kick how?  is it d-w?
<fabbione> it's 172K .gz
<lamont_r> mdz: that log file arrived at 02:26 london time
<seb128> lamont_r: dunno, it FTBFSed this morning
<seb128> lamont_r: libnautilus-burn-dev was missing a dep on libhal-dev, I've fixed that
<seb128> now I need a totem kick :p
<mdz> Hoary devel meeting in #u-m in 5 minutes
<Kamion> oh, arse, need food
<lamont_r> ah, so kick == retry.  got it
<Kamion> can you cope with me being ~10 minutes late?
<mdz> Kamion: as long as you bring some food for the rest of us ;-)
<Kamion> ah, the old dcc sendmatter
* Kamion runs
<fabbione> lamont_r: some bits of this patch will need rework.
<fabbione> i can't apply it as is for all arches
<lamont_r> fabbione: no surprise there... :-(
<fabbione> even if dpatch supports patching per arch...
<fabbione> i need to think about it
<fabbione> --- LINUS_2_6_10/mm/shmem.c     2004-12-24 16:36:00.000000000 -0700
<fabbione> +++ CVS2_6_10_PA5/mm/shmem.c    2004-12-04 00:03:09.000000000 -0700
<fabbione> -static void shmem_truncate(struct inode *inode)
<fabbione> +/* static gcc-3.3 OPD bug - GGG */ void shmem_truncate(struct inode *inode)
<mdz> meeting starting
<fabbione> stuff like that...
<Simira> seb128: I have some serious problems with Gnome (GDM, I think), and no clue about what causes it
<seb128> like ? since when ?
<Mithrandir> Simira: I doubt it's gdm, actually.  More like gnome-panel, nautilus and any other gnome components completely freezing?
<Simira> seb128: I told you some time ago as well. Since middle of Dec., I think. When I log in, nothing happens (the login disappears, and I get only a blank blue screen), or else I get a desktop but no menus.
<Simira> very irritating
<Simira> I've tried logging in in failsafe mode and other (all session alternatives), but it's still the same
<seb128> really weird
<Simira> sometimes reboot works. Sometimes not.
<Gaaruto> hi all
<Simira> killing all user processes doesn't work
<Mithrandir> ogra, seb128: I guess this is not meeting material; it will still have to go through NEW though.
<Mithrandir> Simira: doesn't pkill -u simira work?  Used to, didn't it?
<Mithrandir> or is that just when I'm looking? ;P
<seb128> Mithrandir: http://lists.debian.org/debian-gtk-gnome/2005/01/msg00007.html
<seb128> there is a link to the package
<Simira> Mithrandir: no, it doesn't work, mostly. It has happened, yes.
<Gaaruto> i would like to know when the debian installer will be available for ubuntu, and if that will be on hoary or an other ?
<seb128> Mithrandir: probably just a matter to upload them ...
<Mithrandir> seb128: yeah, I have that patch already.  I've been running with those packages since mataro.
<seb128> oh ok
<Mithrandir> Gaaruto: Ubuntu already uses the Debian installer.
<Mithrandir> seb128: I'll just check that they still look fine and upload to hoary.
<seb128> Mithrandir: feel free to close #3959 if you upload :)
<seb128> thanks
<Simira> seb128: I got a fairly heavy update today though (last two days), it might work now.
<seb128> ok, let me know, but I don't have any really idea on the problem
<Simira> seb128: I'll try make some more out of it if it still doesn't work. I know the feedback is hopeless, but I can't see anything that should cause it.
<Kamion> what a strange question
<Mithrandir> seb128: I've seen similar problems if dbus/hald is upgraded -- gnome needs to be slain before I can continue working.
<seb128> still ?
<seb128> I've turned the hal option to off in gnome-vfs 10 days ago
<Mithrandir> ok, my upgrading has been spotty since then, since the DSL here is _sucky_, I'll tell you if I see it again
<Keybuk> seb128: what did "the hal option" do?
<seb128> ok, thanks
<seb128> Keybuk: cool name and icons for the devices mainly
<seb128> = not a lot according to the bugs going with it :p
<Keybuk> ah, that explains why my cool name and icons vanished then
<sid77> hi
<Simira> Mithrandir: will you try to kill me if I run a little upgrade just now? Just a small one?
<fabbione> Simira: i was just kidding before..
<Mithrandir> Simira: what is "small"?
<Mithrandir> Simira: I surely won't kill you, but I might come down and be a bit angry.  This line _SUCKS_. :/
<fabbione> when Mithrandir offered to maintain thunderbird.. my first tought was.. Simira uses it ;)
<Mithrandir> heh
<Mithrandir> Simira: do you, atm?
<Simira> fabbione: actually not. She still struggles with Evolution and sticks mostly to Outlook Express when things should work effective.
<Simira> Mithrandir: nope
<Simira> just some updates synaptic wanted that apt didn't, for some reawson
<Simira> *updates*
<Simira> Mithrandir: another three mins ok
<Mithrandir> Simira: paaain
<thom> lamont_r: LSB bugs heading your way
<lamont_r> thom: thanks
<lamont_r> much
<thom> enjoy ;-)
<jdub> Kamion: can't set up degraded raid1 arrays in warty installer?
<Kamion> I'd be surprised
<jdub> yeah, it really wants two devices
<thom> 26 frickin' firefox bugs. blah
* daniels stares at thom.
* daniels beats thom with a stick.  Repeatedly.
<daniels> 26?!? luxury!
#ubuntu-devel 2005-01-16
<lamont_r> -DDO_YOU_KNOW_WHAT_YOUR_ARE_DOING=1
* lamont_r giggles
<daniels> hmm.  after merging all the debian xsf typo fixes to our packages:
<daniels> daniels@catsby:~xap% find debian/ -name \*.rej | wc -l
<daniels> 37
<daniels> daniels@catsby:~xap% wc -l $(find debian/ -name \*.rej) | tail -1
<daniels>  2114 total
<pitti> elmo: please sync cdbs
<jordi> daniels: I know it's a bit early, but I think I won't be around when it's the 6th in .au.
* jordi clears his throwat.
<jordi> err
<jordi> throat
<jordi> ~ happy birthday to you, happy birthday to you, happy birthday little daniel, happy birthday to you!
<thom> jordi: you've gone southern on us?
<elmo> pitti: done
<pitti> thanks
<daniels> heh
<daniels> jordi: thanks dude
<jordi> thom: uuh?
<fabbione> oh... finally daniel is turning 18...
<fabbione> daniels: now i can take you to the red light copenhagen area ;)
<fabbione> without getting arrested
<jordi> 18? I thoight thias was 19
<jordi> elmo: heeey
<jordi> elmo: today I became a debianppc user.
<daniels> fabbione: dude, already 18 :P
<jordi> elmo: well, I'm a potential debian ppc user right now, because I can't install it yet.
<ogra> daniels: hey, happy b-day :)
<elmo> jordi: ubuntu ppc user, shurely? :p
<daniels> ogra: not yet, it's on thursday
<ogra> daniels: ahh, oh, sorry then :)
<daniels> no worries; i blame jordi
<sjoerd> daniels: what time is it over there ? 
<jordi> elmo: I guess it'll have a partition :)
<jordi> but dude, I'm still a Debian guy. Unless something radical happens. ;)
<daniels> sjoerd: 10:39am at the moment
<Mithrandir> is it tla add "file with space" or tla add 'file\(sp)with\(sp)space'?
<Keybuk> Mithrandir: if it's not the former, someone deserves FLAMING PLASTIC ANAL VIOLATION
<pitti> elmo: please sync xine-lib
<Mithrandir> Keybuk: ok :)
<elmo> pitti: done
<fabbione> pitti:
<fabbione> Applying   1 revisions to security/commoncap.c  
<fabbione> Applying   1 revisions to security/dummy.c  
<fabbione> i think they just committed the fix for the capability
<pitti> oh, nice
<pitti> so maybe we can take it for Warty?
<fabbione> i will be able to tell you tomorrow at 14:00 UTC :-)
<jordi> elmo: oh, I couldn't get the fast HD on time, but anyway.
<fabbione> pitti: yeah i am pretty sure...
<pitti> fabbione: can you please mail herbert the fix and have him have a review at it?
<pitti> fabbione: ah, you mean you don't get the patch before this time?
<elmo> jordi: sucks
<fabbione> pitti: the script that extract the patches from bk run at that time ;)
<elmo> jordi: like it generally tho?
<jordi> elmo: I know :/
<pitti> fabbione: ah, ok.
<jdub> warty bootup is surprisingly slow once you're used to hoary ;-)
<jordi> elmo: sure. MacOS is pretty. :)
<jordi> elmo: a HD is not that hard to replace eventually
<fabbione> pitti: and it needs the daily log from bk generated patches..
<elmo> heh, I never even booted macos
<jordi> I have nothing else right now :)
<jordi> I think downloading a netinst iso sounds like a plan right now.
<Kamion> I booted it briefly, d-i didn't work well enough at the time and I had no other CD-burning equipment
<Kamion> you can also bootstrap the installer straight from MacOS if you try hard enough and know the runes
<Kamion> I mean, putting files on the MacOS partition and then boot straight from Open Firmware
<elmo> seb128: why are the -omg packages separate?
<jordi> ugh. I don't know the runes. It's more or less a new adventure for me, I've never been out of the x86 cage before. :)
<jordi> "oh my god" packages? :)
<Kamion> elmo: does cdimage@ubuntu.com exist yet?
<seb128> ELACKOFCONTEXT
<elmo> Kamion: err, no, one sec
<seb128> which packages ?
<elmo> seb128: pyorbit, Debian NEW
<elmo> chanabuse, I know
<Kamion> jordi: CD will be way easier for now, trust me :)
<Kamion> but it's interesting that you can do it
<fabbione> pitti: patch on the way soon.. i just figured another bt bit :-)
<jordi> Kamion: nod :)
<elmo> Kamion: done
<Kamion> elmo: thanks
<zul> pitti: is your hardened kernel just the grsercurity stuff?
<pitti> zul: right now yes, but there will be more patches in the future
<pitti> zul: trulux suggested some that he wnats to apply
<zul> pitti, ok cool im trying some other patches as well
<pitti> zul: if you have suggestions, please mail me :-)
<zul> *cough* realtime linux security module
<zul> *cough*
<pitti> zul: NOT the one from jack, or?
<pitti> zul: the thing that grants CAP_SETPCAP?
<zul> pitti: yep
<seb128> elmo: oh that. The maintainers for the others python-orbit bindings have done most of the work. In fact that's to avoid to deal with alternatives. All the package provide a orbit binding, the files in the standard path are in the -omg which conflicts with the other -omg ...
<seb128> not sure I'm clear
<pitti> zul: over my cold dead body
<zul> pitti: http://kerneltrap.org/files/jeremy/realtime_lsm.patch
<pitti> zul: this kernel should become more secure, not less :-)
<zul> true
<pitti> zul: granting caps to other processes is insane, and jack's design is just broken in that regard
<pitti> zul: sorry :-)
<crimsun> ubuntu kernels already include user mlock()
<seb128> elmo: simple version: "we have several -omg conflicting with the other ones, the installed one define the default orbit binding"
<zul> pitti: no problems
<pitti> zul: however, I'm not opposed to providing a -realtime kernel in universe
<crimsun> so it's not absolutely necessary to use realtime_lsm
<pitti> crimsun: yes, that helps a lot to drop setuid bits, e. g. from gpg
<fabbione> pitti: did you get my mail?
<zul> brb
<pitti> fabbione: yes, I did
<pitti> fabbione: hey, nice and easy patch
<fabbione> pitti: but let's wait tomorrow when i can compare all the changesets
<pitti> fabbione: sure, we still have some days anyway
<jdub> whoa, gigE is fasssssst
<daniels> is it safe to use ~ in hoary?
<daniels> (in version numbers)
<trulux> pitti, i will maintain my own brand of selinux kernels
<elmo> daniels: no, katie will bitchslap you
<daniels> i have xorg 6.8.2rc1 to pacage
<daniels> (or 6.8.2~rc1, rather)
<daniels> elmo: arse
<fabbione> jdub: gigE are slow... 10G are FAST
<elmo> if you can get consensus from the toolchain guys that it's safe, I can fix katie
<elmo> packaging toolchain, that is
<daniels> elmuh, toolchain?
<daniels> ah, right
<daniels> mdz: ?
<daniels> Keybuk: ?
<Keybuk> hmm?
<Keybuk> I'd suggest we use them
<Keybuk> to avoid +thom-woz-ere+ version numbers
<daniels> heh
<daniels> +rentboy7
* thom throws antimatter peanuts at Keybuk 
<Keybuk> thom: which reminds me, I owe you $1
<daniels> Keybuk: give him $1 worth of peanuts
<thom> Keybuk: hm?
<daniels> Keybuk: (or fifty opinions)
<Keybuk> thom: some wide-arsed slack-jawed faggot australian teenager bought a t-shirt ;p
<thom> rofl
<fabbione> AHHAHA
<thom> quel surprise
<Keybuk> then again, you owe me 25 anyway :p
<elmo> hey, are we doing a mass order of cafepress stuff at any point?
<elmo> or does it not save you much?
<daniels> elmo: au contrare, it can ruin you
<daniels> elmo: get over $x, where x is the magical customs limit, and welcome to the world of import duty and vat
<daniels> elmo: they changed the customs limit down by about $200 shortly before we ordered once, so we got absolutely raped ($au180 duty+gst on a $au440 order) wit a group order
<daniels> elmo: it doesn't really help much
<Kamion> which all reminds me
<Kamion> 23:06 < Keybuk> Kamion: mind out, floor's a bit slippy
<Kamion> Keybuk: what was that about? :)
<Keybuk> someone mentioned the "L" word just before your retort
<Keybuk> and we know what happened last time
<Kamion> ah, heh
<daniels> heh
<pitti> fabbione: essentially you just need to install pkgstriptranslations in the build chroot
<jdub> so i was thinking about the server stuff
<jdub> (the "ubuntu is a desktop os" problem)
<pitti> fabbione: and enable it in /etc/pkgstriptranslations.conf
<jdub> and the big thing that bites me with my new ubuntu server at home is a lack of webmail
<pitti> fabbione: this should be everything that's necessary
<pitti> fabbione: testing appreciated, though :-)
* thom pumpkins
<fabbione> pitti: is pkgstriptranslations in universe?
<pitti> fabbione: oops, yes
<pitti> fabbione: I thought it was already seeded
<fabbione> ok .... i need to pull it in manually... if it is _all.deb
<pitti> mdz: we need to seed pkgstriptranslations to supported
<pitti> fabbione: yes, it's only a shell script
<sivang> jdub: having some sort of hardened linux into it plus making it run on low end hardware is already a big step, I am going to reinstall my router with it when I know sarg-->ubuntu upgrade is error free :)
<fabbione> pitti: ok.. installed and configured
<fabbione> pitti: from the next package it should be there
<pitti> fabbione: can you test it with a small package?
<pitti> fabbione: whcih actually has translations?
<fabbione> pitti: the buildd will test for us...
<pitti> ok
<fabbione> pitti: at the first package that it will hit 
<pitti> hey, my i386 hardened kernel build is ready
<jdub> Kamion: hrm, openssh-client borkage
<jdub> hrm, perhaps it's base-config
<fabbione> ok.. i am off..
<fabbione> i need some sleep badly
<pitti> night fabbione 
<fabbione> pitti: i will let you know tomorrow what packages will build with pkgstriptranslation
<daniels> night fabbione
<fabbione> and we will check the debdiffs with the previous
<ogra> fabbione, night
<Mithrandir> thom: I guess you were happy to get rid of those m-t bugs. :P
<fabbione> night ladies ;)
<fabbione> Mithrandir: ask for beer!
<fabbione> ;)
<jdub> oh wait
<jdub> never mind
<jdub> it's this whackass installer breakage
<Mithrandir> fabbione: he owes me a british beer, actually.  Which he forgot to bring to Mataro.
<fabbione> ehehhe
<Mithrandir> fabbione: so he'll have to bring one to .au instead.
<Kamion> jdub: que?
<thom> Mithrandir: strangely enough, yes
<jdub> Kamion: when i installed hoary yesterday, the last item on the stage 2 menu was "execute a shell" -> there was no "finish installation"
<pitti> Night everybody
<jdub> Kamion: only now (having rebooted numerous times, and got stuck with stage2 on tty1) the menu has it
<Kamion> oh, you mentioned that, I wonder if it's merge breakage
<Kamion> finish got split into two pieces recently
<Kamion> aha!
* Kamion whacks m-o-m
* mvo_ goes to bed 
<jdub> oh crap, it's still cycling anyway ;)
<Kamion> stupid non-preserver-of-+x-bits
<Kamion> jdub: try chmod +x /usr/lib/base-config/menu/exit
<Keybuk> hmm?
<Keybuk> it shouldn't drop a +x bit
<jdub> finish dumped me back to the menu
<pitti> Keybuk: any idea what went wrong with http://people.ubuntu.com/~scott/ongoing-merge/samba/ ?
<Keybuk> define "went wrong" ?
<pitti> Keybuk: all patches are in the order of 10 MB
<Kamion> Keybuk: it does, in native packages; has happened to me several times and I think I mentioned it to you before
<Kamion> Keybuk: in the specific case where the +x-bit-file is new
<Keybuk> Kamion: shouldn't do ... unless files are added on one side?
<pitti> Keybuk: not quite the size appropirate for manual review
<Keybuk> oh
<Keybuk> yeah, that's just patch not adding the +x bit
<Kamion> would be nice if mom could go check on that after patch
<pitti> Keybuk: even worse, I tried to extract the Ubuntu changes manually; there is no 3.0.9-1 version on the Debian mirrors (any more?)
<Keybuk> pitti: looks like they generated the docs
<pitti> Keybuk: I think I will merge it manually using the changelog entries to find what changed
<Kamion> jdub: yeah, you're at low priority, finish is no longer the last item in sequence
<Keybuk> --- samba_3.0.8-2/docs/Samba-Developers-Guide.pdf	2004-10-25 17:18:24.000000000 +0100
<Keybuk> +++ samba_3.0.10-1/docs/Samba-Developers-Guide.pdf	2004-12-15 16:26:14.000000000 +0000
<Keybuk> just strip the bits of patch that are docs
<Keybuk> the rest of it looks sane
<Kamion> jdub: you'll need to restart base-config completely after the chmod +x
<Kamion> anyway, fix uploaded
<pitti> Keybuk: okay
<pitti> night then
<Keybuk> in fact, it looks like it's done most of that work for you
<Keybuk> dropped seems nearly all docs
<jdub> whoa
<Keybuk> Kamion: mail me, easy enough I think
<jdub> now it's asking me heaps of questions
<pitti> Keybuk: btw, why can't mom prefer the Debian changes?
<Kamion> it's at low priority :)
<Kamion> jdub: DEBIAN_PRIORITY=high base-config, or something
<jdub> low priority makes baby jesus cry
<pitti> Keybuk: it seems more sensible to me to take the Debian hunk if Debian and Ubuntu both patch the same thing
<jdub> Kamion: it's cycling, i don't really have the opportunity :)
<mdz> pitti: go ahead and seed it
<jdub> yay
<jdub> Kamion: i got an 'exit baseconfig' :)
<pitti> mdz: in the wiki?
<mdz> pitti: in arch
<pitti> mdz: okay, I will learn about this tomorrow
<mdz> amu: still here?
<pitti> n8
<mdz> pitti: good night
* lamont gets home for a few minutes before his meeting for the evening
<Keybuk> pitti: it does?!
<Keybuk> (I think)
<Keybuk> it prefers which ever set of changes drop less
<Kamion> Keybuk: done
<jdub> Kamion: thanks :)
<Kamion> jdub: tomorrow's CD should be fixed
<pitti> Keybuk: I meant, there is a debian-dropped instead of an ubuntu-dropped one
<Keybuk> that means it picked the debian patch
<pitti> Keybuk: anyway, prefering the smaller drop might be the better default in general
<Keybuk> that's what it does :)
<Kamion> pitti: ubuntu-devel@lists.ubuntu.com/seeds--hoary--0 is the relevant archive
<Keybuk>     if winning_dropped is None or winning_dropped > dropped:
<Kamion> http://www.ubuntulinux.org/wiki/SeedManagement
<amu> mdz: yep
<mdz> amu: can you send me your latest diffs?
<jdub> so, we don't want resolvconf?
<daniels> so, screen sucks
<Kamion> would resolvconf not require interesting netcfg changes?
<amu> mdz: hmm i'm just upgrading to 20041227ubuntu1 :) 
<daniels> setting defutf8 on with LC_CTYPE=en_AU.UTF-8 and an unset LANG, doesn't give me UTF-8
<daniels> surely defutf8 on means 'make the default UTF-8, seriously'
<Kamion> can we make screen honour LC_CTYPE =~ /\.UTF-8$/ and set defutf8 on by default in that case?
<Kamion> interesting, defutf8 on works for me
<amu> mdz: letme know if you want the "old one   
<jdub> hrm
<jdub> ber, aptitude is annoying
<lamont> Kamion/anyone: any locales other than *_US that should use letter instead of A4?
<lamont> well, ??_US*, to be more precise
<daniels> Kamion: to be fair, this is screen on freebsd
<mdz> daniels: do I understand correctly that you are going to try to sneak in a new X.org before UVF?
<mdz> amu: I would like the old one now (the same thing you sent to Kamion?), and the new one when you've finished merging it
<daniels> mdz: ish
<amu> mdz: ok  
<daniels> mdz: what we have now is 6.8.2rc1, by virtue of religiously tracking CVS's 6.8 branch
<lamont> mdz: I hope he makes it
<lamont> daniels: my patch gonna make it?
<daniels> mdz: 6.8.2 is expected to go out with very few changes soon, so basically all that's involved is dropping 000_stolen_from_6.8_branch.diff, creating a new tarball, and bumping the version; no actual code changes of any weight whatsoever
<daniels> lamont: i've already merged your hppa stuff locally, if that's what you mean
<lamont> kewl
<daniels> mdz: my understanding was that this was fine -- is this still the case?
<daniels> mdz: it's really just cosmetic from what we've had since matar
<mdz> daniels: upstream version freeze is, well, tomorrow
<jdub> elmo: when will we get sync mails on *-changes?
<daniels> mdz: hm
<daniels> 23:04 < daniels_> jdub: fwiw, wouldn't mind an xorg exemption from uvf, especially since we're already totally up-to-date on 6.8.x branch anyway
<daniels> 23:07 < jdub> daniels_: xorg is a feature goal, and packaged by us - just a matter of having upgrades confirmed, etc.
<daniels> i probably should've been more clear
<daniels> so, yeah, to clarify: we're talking a cosmetic version number bump, and replacing tarball+large patch with a tarball
<daniels> the code changes are minimal and very few of them actually even affect us; it's about 20% of the patch churn you would find in a typical xorg upload, probably less
<daniels> maybe 10
<daniels> would that be ok?
* jdub is happy with it.
<lamont> mdz: any objection to me uploading the daily live-cd filesystem uncompressed (and compressing it in the build process)?  Then again, I wonder if it'd actually be rsyncable even then...
<lamont> probably not
* lamont assumes ext2 fs
<jdub> daniels: what happens if you load the nvidia module, but continue to use the nv x driver? anything scary?
<mdz> daniels: when is it going to be uploaded?
<mdz> lamont: why is it a problem to do the compression?
<mdz> lamont: oh, for rsync
<mdz> lamont: I don't think we should invite people to mirror it anyway
<Kamion> nicer for the developers though
<mdz> which developers?
<mdz> we'll be building the live CDs in the data center
<Kamion> the live CD developers
<mdz> lamont: yes, ext2 fs
<mdz> the only issue is that the compression takes a long time, so it would be nice for it to be done in advance
<mdz> also, the uncompressed filesystem will be comparatively huge
<daniels> mdz: i'll do 6.8.1-1ubuntu9 today, but as for 6.8.2, it depends when the tarball is rolled.
<lamont> mdz: thinking about it, it's probably downhill even without compression
<daniels> mdz: i believe it's scheduled for next week or so
<daniels> jdub: nope, it's fine
<jdub> daniels: perhaps we should be hotplugging nvidia in preference to nv.
<jdub> or dropping in a "prefer me" hint with the nvidia-glx package or something
<jdub> so people don't have to keep editing /etc/modules
<daniels> jdub: they shouldn't have to; it should get loaded by the nvidia driver automatically
<daniels> i have an nvidia card now, so i'll check that out later on in the week
<jdub> i just tried on hoary; didn't work
<jdub> (2.6.9-k7)
<daniels> craptastic
<daniels> 01:19 < nrubsig> daniels: I can answer that after this weeks r/w call, it's still a moving target (and to avoid that you ask
<daniels>                  this question each day: "... at the end of january..." :-)
<daniels> (r/w -> release wranglers)
<Kamion> mdz: first weekly-dvd attempt building now; in the meantime I'm off to bed
<lamont> Kamion: something told me it wouldn't require much work...
<jdub> Kamion: ROCK!
<lamont> although the dvd should also include the complete openCD.... :-)
<mdz> Kamion: great, thanks
* lamont wonders if the package list for ubuntu-{desktop,base} is hiding anywhere useful, so he could feed it to debootstrap
<Kamion> lamont: yeah :) although putting sources on it will be a bit more complicated than just producing a DVD build with supported
<mdz> lamont: Task: ubuntu-base and Task: ubuntu-desktop, respectively, but you really don't want debootstrap to try to install all of that stuff
<mdz> lamont: it would be nice if debootstrap had the option to install some extra packages with apt
<mdz> like rootstrap does
<Kamion> base-installer does
<Kamion> in fact debootstrap also does
<mdz> it so doesn't
<Kamion> oh, no, --include doesn't do it with apt
<Kamion> you can at least list the deps
<mdz> hardcoding all of the deps for ubuntu-desktop would be a nightmare
<Kamion> yeah
<mdz> jdub: isn't that what the script in nvidia-glx does?
<mdz> jdub: don't tell me you didn't follow the howto ;-)
<usual> will gstreamer be updated to a version capable of playing dvd's in hoary before release?
<lamont> Kamion: so debootstrap hoary, and then chapt-get install ubuntu-desktop/ubuntu-base?
<lamont> btw, what was the syntax to apt to say 'task foo'?
<jdub> mdz: oh man...
<Kamion> aptitude install ~tfoo
<lamont> ~t. ok.
<Kamion> lamont: yeah, that should work (note ubuntu-base is already in debootstrap)
<lamont> nice
* lamont noted this last week that the depends for ubuntu-desktop on ia64 are b0rked.  (empty)
<mdz> lamont: if you like, you should be able to just chapt-get install ubunut-desktop
<lamont> Kamion: any other ~ escapes?
<mdz> rather than using the task
<mdz> ubuntu-desktop, that is
<lamont> mdz: yes.
<lamont> execpt for ia64, that is
<mdz> ia64 doesn't have metapackages yet?
<mdz> should be trivial to fix
* lamont didn't investigate at all - just noticed it when I was rewriting my partial-mirror script
<Kamion> lamont: "Search Patterns" in the aptitude manual documents them, I don't know any others offhand
<lamont> losetup et al in udeb, no problem.
<Kamion> there are quite a few thoug
<Kamion> h
<lamont> Kamion: cool
<Kamion> better losetup in busybox, see mail
<lamont> Kamion: haven't seen your reply et
<Kamion> better => smaller ;)
<lamont> and less work for that util-linux maintainer..
<Kamion> need to sync up available options etc. though.
<Kamion> weekly-dvd build 2, might work this time
<Kamion> CD 1 will only be filled with 1737329326 bytes ...
<Kamion> CD 1 will have 1934 packages.
<Kamion> (i386)
<lamont> Kamion: for extra credit, put i386/ppc/amd64 on one dvd that boots on all 3...
<lamont> or not.
<Kamion> I cunningly escape because 1.7GB*3 is more than a single-sided single-layer DVD ;)
* lamont looks at the clock, screams, runs to fire meeting
<lamont> arch all to the rescue.
<Kamion> good point
<lamont> must flee
<Kamion> mad debian-cd patches welcome ;)
<lamont> mtg in 8 minutes, 10 minute drive
<lamont> lol
<lamont> I know it can be done for (i386,ia64,hppa)
<lamont> since the 3 boot loaders all look at different places to load the boot loader....
<lamont> later - back in 1-3 hours
<jdub> so in windows
<jdub> "turn off computer" shows a dialogue with
<jdub> "stand by" (suspend to ram)
<jdub> "turn off" (halt)
<jdub> "restart" (reboot)
<jdub> if you hold down shift, "stand by" changes to "hibernate"
<jdub> and the suspend to ram works really nicely
<jdub> "log off" gives you the choice between switch user and log off
<jdub> which is kind of "do this... no really!"
<sivang> jdub: well, suspend doesn't work no more on the dell inspiron, xp sp2 has b0rked it's modem driver and thus it can't. :-) (gigles)
<bob2> haha
<bob2> does it work on ubuntu now?
<sivang> bob2: as soon as gf leaves the laptop, I will test :)
<bob2> hah
<sivang> bob2: ok, she left it, on to testing! :)
* sivang really hopes that switching to the free nv driver will do the trick
<sivang> mjg59: ping
<mjg59> Hello?
<sivang> mjg59: I'm back with my laptop :) I am now using the nv free driver
<mjg59> Ah, cool
<sivang> mjg59: sleep works much faster now,
<sivang> mjg59: however it doesn't seem to resume. :-( 
<mjg59> Hrm. Irritating.
<sivang> mjg59: one time I tried it, and it just slept and cam back after a sec.
<mjg59> Hrm. Normally means a driver failed to suspend correctly.
<sivang> mjg59: I have nvidia-glx installed, can this be the problem? I modprobe -r nvidia before trying to sleep
<mjg59> Hrm. shouldn't make any real difference.
<mjg59> I'll see if I can work out what's going on.
<sivang> mjg59: let me know what info you require from me :)
<sivang> mjg59: it worked!!!!!!!!!!!!!!!!!!!!1
<mjg59> Ooh
<mjg59> What did you do?
<sivang> mjg59: I remarked nvidia bin driver from my /etc/modules
<mjg59> Ha!
<mjg59> Damned nvidia scum
<sivang> mjg59: and rebooted
<sivang> mjg59: now, nefore that I also dpkg-reconfgiured xserver-xorg to us nv instead of nvidia, and unckech the glx and GLcore
<sivang> mjg59: because for some strange reason , it couldn't find GLCore when I left it on...
<mjg59> Rock
<sivang> mjg59: btw, GLCore is the open implementation of the opengl right?
<sivang> mjg59: now antoher problem is, that your scripts doesn't recongnize when I close the lid as a sleep eevent...:-/
<mjg59> It's the module that lets the X server do opengl, yeah
<mjg59> sivang: Yeah, that'll be configurable in hoary
<mjg59> We need to redo some of the scripts
<mjg59> If you want, try hacking /etc/acpi/lid.sh
<sivang> mjg59: I want to :) but am not sure I Know enough :)
<mjg59> Ha
<sivang> mjg59: I can try.
<sivang> mjg59: how do I detect a close lid event?
<sivang> is it something like a keystroke?
<mjg59> sivang: /etc/acpi/events/ has stuff in to detect events
<sivang> mjg59: and another trouble now, that I lost all my resultions from the prior conf file, it now only accepts 640x480..
<mjg59> They then run scripts in /etc/acpi/
<mjg59> sivang: Heh. dpkg-reconfigure xserver-xorg should let you choose higher ones
<sivang> mjg59: that whay I tired wrt resolutioins, still cannot choose any hight using the gnome menu
<sivang> mjg59: also, very important to note that I disable fb 
<mjg59> Hrm. Take a look at /var/log/xorg.log?
<mjg59> sivang: Yeah, framebuffer won't work at the moment
<sivang> mjg59:  I will, debian made me very comfortable with it :)
<sivang> sorry, with xfree86config-4
<sivang> :-)
* sivang used to run sid
<lamont> moof
<mdz> lamont: I didn't get Colin's reply about the live CD stuff, either
<lamont> mdz: still no joy here.  dunno
<mdz> Kamion: if you sent a reply about the live CD / udeb stuff, we didn't receive it
* lamont decides to maybe make tonight an early night.  no school run in the morning, etc, etc.
<lamont> mdz: is UVF tomorrow morning, or is tomorrow's katie run the last?
<lamont> it has to be either today's or tomorrow's katie run that is the last
<mdz> lamont: Debian's katie run, you mean?
<mdz> what time is that?
<mdz> depends on whether elmo wakes up before or after, I suppose
<lamont> 11:54 PST
<lamont> or 11:52 - never really was sure on the exact minute of that one.
<mako> erghg.
<mako> can someone look at: http://people.ubuntulinux.org/~mako/ubuntu-traffic/
<mako> looks like apache is not doing the UTF8 right to me
<lamont> I see a string of 6 A's with accents
<mako> yeah me too :-/
<mako> also, if you click on archives, it does weird things
<Clint> mako: yeah, apache is saying it's 8859-1
<mako> like, it doesn't take me there
<mako> thom!!!!!!
<lamont> speaking of which, I need a mention or two in ubuntu traffic
<lamont> my page rank dropped to 2.
<mako> lamont: i have anohter one (or two) out tomorrow :)
<mako> Clint: i am doing the <?xml THIS IS UTF8!?> thing
<mako> does teh archives link for anyone
<mako> it is bogus for me
<mako> and i can't figure out whyy
<lamont> archives gets me to the archives page
<lamont> still lots of funky A characters.
<lamont>  - 
<Clint> it doesn't matter; browsers are going to listen to the http server
<Clint> get the apache config fixed
<mako> for some reason, when i click on the archives page, i get an error that it can't be found
<mako> but from mozilla, not apache
<Clint> I don't have that problem.
<mako> yeah.. i don't in links
<mako> i'll leave that for tomorrow
<lamont> bbiab
<mjg59> mako: apache will default to sending 8859-1, and I don't think that can be overridden in the page
<mjg59> I can't remember if .htaccess is sufficient, or if the central config has to be changed
<mako> mjg59: yeah.. and the config is set to not allow me to change this in an htaccess
<mako> it is sufficient
<mako> but only if i have perm to do it :)
<mjg59> Haha
<mako> AddDefaultCharset utf-8 should work
<mako> can be called from a .htaccess
<mako> just tried that
<mjg59> Everyone should use utf-8
<mako> DUDE I KNOW
<mjg59> For everything
<mako> DUDE I KNOW
<Clint> the correct solution would be to drop AddDefaultCharset from the main config
<mako> *iso-8859-1*
<mjg59> Hrngh.
<mjg59> 5AM and I'm still at work.
<mako> who needs euro symbols!
<mako> no wait.. 
<mako> who needs ANYTHING ELSE IN UNICODE
<mako> no interrobangs fo rme
<whiprush> hey mako, I'd like to run an ubuntu-traffic idea by you ...
<mako> whiprush: cool
<whiprush> have you considered a total community roll up, including the forums?
<mjg59> After the two hours of HOT SCIENCE ACTION RUSH, I'm back to waiting for irritatingly slow webservers
<whiprush> not just the lists.
<mako> whiprush: i do the lists and as much irc as i can
<mako> whiprush: that takes a couple days a week to do well
<whiprush> well put me to work.
<mako> whiprush: dude, if you send a list of stuff from the forums each week, i *promise* it will get in
<whiprush> I've been mulling something like fedoranews.org for a few days.
<whiprush> or maybe some kind of tip blog or somethign
<whiprush> but I don't want to replicate anything.
<whiprush> maybe tie it in with announcements, like freezes and whatnot.
<mako> i'm happy to integrate independently produced content, forum summaries, etc
<mako> well, i already get that stuff :)
* whiprush nods
<mako> i'm open to anything
<whiprush> do you keep a working copy of it someplace?
<mako> whiprush: i have a copy in a tla/baz repository
<mako> whiprush: it's not mirrored anywhere publicly accessible yet but if you want a stab, we can work from that
<whiprush> k, I'm rusty on tla, but I can brush up on that tomorrow.
<mako> whiprush: well, we should do baz
<whiprush> I can do that
<mako> i need to to tag into a new archive anyway
<mako> because this archive has some other stuff that i don't want to mirror
<mako> so i'll tag into a new archive and then convert it to baz
<mako> whiprush: what timezone are you in?
<whiprush> well, one thing I've noticed is the duplication of forum and list content, maybe plopping major things in a common u-t will alleviate that
<whiprush> EST.
<mako> whiprush: cool.. me too where are you at?
<whiprush> detroit
<mako> detroit is in EST?
<mako> wow.. i thought it was kind of west
<whiprush> or EDT, whatever we're at now, but yeah, eastern.
<mako> do you like detroit?
<whiprush> wouldn't live here if I didn't.
<whiprush> more metro
<whiprush> not like, detroit detroit. 
<mako> there are tens of thousands of FREE HOUSES in detroit
<whiprush> actually, downtown isn't too bad lately.
<whiprush> since they built the new tiget stadium
<mako> i know. this is the opportunity
<mako> cause the houses are still free. the warehouse spaces are SUPER cheap.. i want to create free software community there
<mako> in free houses
<mako> got that everyone? we're all moving to detroit.. fuck rent
<whiprush> live in houses like in fight club
<whiprush> sounds great!
<mako> yeah man :)
<whiprush> I am jack's buildd, I keep jack up all night.
<mako> whiprush: alright then.. i'm really tired.. but i'm working on traffic all tomorrow so just poke me and i'll tag a new archive and dump it somewhere
<whiprush> is this u-t template available anywhere?
<whiprush> some xml build thing?
<mako> yeah, it's a crazy xml build-system
<mako> it's *ugly*
<whiprush> k, I will poke. I'll probably drag another guy to work on this with me.
<whiprush> oh yeah, that will rule.
<mako> xml + perl + lots and lots of xslt
<mako> it's rough
<mako> i've been slowly improveing it
<whiprush> do all the kernel-cousins use it?
<mako> yes
<whiprush> k
<mako> the good news is that KT upstream is super responsive and a good friend of mine
<whiprush> alright, I'll ping via email tomorrow or so
<whiprush> oh ok, so they are all centralized
<mako> AND, he's totally into arch :)
<whiprush> I thought it was some kind of mad xml template gone wild.
<mako> it is
<mako> but it's mostly just html
<whiprush> k
<mako> everything within the <section> tags is basically pure xhtml
<mako> lately, i've actually been writing it first in ReST and then doing rest2xhtml and then just editing the xhtml into the kt-xml
<whiprush> where are you at btw? location wise?
<mako> nyc
<whiprush> k
<bob2> oh man, you drank the rest koolaid?
<mako> bob2: dude, TOTALLY
<mako> bob2: my blog is *all* rest
<mako> bob2: i had to switch severs to one that could actually process all that ReST on that page fast enough :)
<bob2> hahahaha
<mako> 20-40 rest documents.. DUDE
<mako> and i'm *sure* pyblosxom called python, loaded docutils, etc 20-40 times
<mako> *positive*
<mako> whiprush: as far as i can tell. zb isn't work on the kt scripts very much upstream
<mako> whiprush: which means i'm the center of development..
<mako> whiprush: there are new some new features i want to add in terms of coding.. but i *really* don't want to it to be a mess of xml, xsl, perl AND python.. 
<mako> whiprush: but the perl is pertty small, totally undocumented, and not always working very well
<whiprush> I've got some friends who would help.
<whiprush> but me myself, I'm just an info hound more than a coder.
<mako> well, i can write python just fine
<mako> perl too actually
<whiprush> And I know plenty of perl monks if you need help
<whiprush> some even looking for projects.
<mako> but i think mark would have a heartattack if he knew i was writing perl on company time :)
<mako> perl is actually my best language :)
<whiprush> k, tomorrow I'll tell them all they just volunteered
<whiprush> is there a KT homebase?
<mako> but yeah.. 
<whiprush> with all the code and whatnot?
<mako> nope.. not yet
<mako> i've been poking zb about it a bit.. but not in the last couple months
<mako> which means we'll be it
<mako> but really, the biggest help will just be writing traffic
<mako> i'm about at the limit of the number of places i can track
<mako> i have basically full coverage on english-language ubuntu lists and major meetings in the IRC channel
<whiprush> yeah I'm a linkwhore.
<whiprush> I think I can help with the forums especially
<mako> that would be *huge*
<mako> it would be really really great to get regular contributors to traffic
<mako> it appears we will also get an italian translation soon
<mako> which is pretty exciting
* whiprush nods
<whiprush> I've been looking at some way to get involved for a while. So I need some gruntwork.
<mako> i mean, with the forums since there's no coverage at all.. it's great
<mako> you can simply just note threads you think are interesting
<whiprush> yeah
<mako> and then make a top 3-5 at the end of the week and there ya go
<whiprush> a good 80%+ are just help requests
<whiprush> but there's a good 10-15% that's pretty good summary-wise.
<mako> right, i flagged *6* messages out of nearly 1000 on the last UT fro -users
<mako> that was just users
<mako> -devel and -doc and -news and -announce are all varying levels of more highly relevant
<whiprush> yeah it's odd. My guess was most new users would come from debian or some other distro.
<whiprush> I hadn't anticipated the sheer amount of brand new users.
* mako nods
<mako> did you see we won some recognition as "best community"
<mako> the forums did!
<whiprush> On Ars.
* whiprush writes for Ars
<whiprush> why else would I be here? :p
<mako> ah, ok :)
* mako shrugs
<mako> i don't write for ars :)
<whiprush> heh
<whiprush> jdub invited me around sounder 4 or 5 iirc. So by the time it was out I had the hype machine in full force.
<whiprush> do you follow a schedule?
<whiprush> for ut I mean
<mako> yeah, the conference screwed me up a bit
<mako> and the shipment of cds
<mako> i should be caught up by the end of the week
<whiprush> yeah I was kind of following it, then noticed the conference blew everything up
<mako> pre-december
<whiprush> yeah just give me deadlines and I should be set. I check the forums probably 10-15 times a day at least.
<whiprush> plus a guy or two on the west coast that can cover me when I sleep. It could rule.
<mako> i summarized every thread from the week previously (ending friday) with no additional traffic by the time i look monday
<mako> the idea is, i give things 2-3 days to cool off
* whiprush nods
<mako> so i only summarized threads that were really dead
<mako> but you can do it however you want for the forums
<mako> mdz had asked me to switch things around a bit so i put UT on tuesday of the week
<whiprush> well, I've noticed a certain "style" for -cousins ...
<mako> which i'm ok with
<whiprush> k I'm off to bed, I'll email you tomorrow so we can get some arch love going.
<mako> whiprush: msg me on irc if youre around
<whiprush> okey
<mako> whiprush: i only check canonical mail 1-2 times a day usually
<whiprush> k, I log this channel so just holler at me likewise
* mako passes out
* whiprush does also
* lamont makes a note (in case anyone forgets) that driving a cougar out onto the ice on a lake is probably not a good idea.
<jdub> mako: ut has weird encoding b0rkage
<lamont> jdub: he was bitching about that earlier
<whiprush> jdub: I've got some ideas about this "just a desktop distro" thing. Posting on -devel in a few minutes.
<jdub> whiprush: cool, ta.
<jdub> whiprush: if it involves making our desktop TOTALLY SUCK, here's my "no" response in advance. :-)
<whiprush> no no. 
<whiprush> just some observations
<whiprush> I noted it this evening actually at the bar.
<whiprush> I told all my friends what they thought of ubuntu as a server distro
<whiprush> 6 of them where like "ummmm, never even considered it."
<jdub> wait a sec
<jdub> that's evidence of a problem
<jdub> not a solution!
<jdub> we're being tricked
<whiprush> I'm writing
<whiprush> sec sec
<jdub> hrm
<jdub> so now i can log in to messenger with gaim but not messenger itself
<plovs> jdub what is the name of the new frontend to synaptic?
<fabbione> morning
<jdub> plovs: the application installer? gnome-app-install?
<fabbione> lamont: you around?
<fabbione> lamont: i installed the translation strip thingy on the sparc buildd... 
<fabbione> it seems to work fine..
<fabbione> i will anyway check later with pitti
<plovs> jdub: i am running warty at the moment, so I can't see, what is the name gnome-app-install shows in the menu and title-bar (for the docs)? gnome-app-install is kind of ugly as a name
<jdub> that's just the package/binary name
<jdub> "Add/Remove Programs"
<jdub> the title bar says "Application Installer"
<jdub> but that's what it is currently, and those are bugs :)
<plovs> jdub: ok, then i'll just write REPLACEME for now, thanks!
<fabbione> lamont: i can't chroot on hppa...
<fabbione> Executing shell in 'sid' chroot.
<fabbione> Unknown id: fabbione
<fabbione> dchroot: Child exited non-zero.
<fabbione> dchroot: Operation failed.
<fabbione> elmo: -su: /dev/null: Permission denied
<fabbione> davis hoary chroot...
<fabbione> if you updated the chroot please check udev...
<fabbione> mjg59: can u push me the swsusp O whatever patch please?
<mjg59> fabbione: Urgh. Sure - I haven't slept yet, so it may have to wait for a bit :)
<mjg59> Need to get this report finished within the next hour or so
<fabbione> mjg59: ok.. thanks..
<fabbione> i am not in complete rush...
<fabbione> i stil have hmmm 200 and more bk patches to review....
<fabbione> and some chroots are broken so i can't test compilation
<fabbione> BAH
<fabbione> misdn is dead upstream...
<fabbione> WOW there is actually an update!
<fabbione> ogra, mvo: can you send me the lsmod when you try to load the fritz driver?
<ogra> fabbione: mail sent....sorry i'm in a hurry.....
<fabbione> ogra: thanks, np
<daniels> good god.  three or four days into my archive rsync, and I'm up to multiverse (and this is excluding amd64)
<fabbione> ehehhe
<Kamion> mdz,lamont: my outgoing mail doesn't work very late at night, 'cos I smarthost through chiark and chiark's MTA stops accepting mail during backups
<Kamion> mdz,lamont: you should have the mail now, though
<daniels> Kamion: Irritated.
<Kamion> daniels: that applies more to the rest of the Internet than it does to systems on chiark's VPN :)
<pitti> morning
<cartman> daniels: any ETA for new X.org upload. And yes I am impatient ;-)
<daniels> Kamion: heh :)
<daniels> cartman: sometime tonight -- I'm just cleaning up a couple of bits now
* cartman hugs daniels 
<cartman> daniels: is it X.org cvs or branch?
<daniels> cartman: 6.8 branch
<cartman> better than nothing
<cartman> Composite is too crashy
<daniels> the branch doesn't fix composite being crashy, I'm afraid
<daniels> but neither does HEAD
<cartman> well at least my keyboard patch will be in
<daniels> there's virtually nothing on HEAD aside from a) patches from Ubuntu I've committed but not got on the branch, b) patches from Fedora committed but not on branch that we have anyway, c) minor tweaks that don't affect us
<cartman> okies
<fabbione> who was asking about sparc framebuffer a couple of days ago?
<fabbione> crimsun: was it you?
<Xof> I've heard that ubuntu maintainers are having difficulty with sbcl (which would unblock a wodge of cl-foo dependencies).  Is this right?
<Xof> (I am upstream for sbcl)
<fabbione> Hi Xof
<daniels> Xof: i believe so
<fabbione> do you happen to know what kind of problems?
<Xof> trouble building it, and also trouble getting amd64 working
<daniels> something about too many predicates?
<fabbione> http://people.ubuntulinux.org/~lamont/buildLogs/s/sbcl/1:0.8.18-1/sbcl_1:0.8.18-1_20041230-0411-i386-failed
* daniels is searching.
<fabbione> Xof: that's the most recent build-log
<fabbione> one dir up and you can see other logs as well
<Xof> fabbione: that's impressive.  If you'd asked me before, I'd have said that wasn't possible :)
<fabbione> mvo, ogra: i am build a new avfritz module with some extra debugging info...
<fabbione> Xof: ehehe
<fabbione> well the dir up has other arches ;)
<fabbione> powerpc fails in a differnt way..
<fabbione> so it's worth to look at it
<ogra> fabbione: fine :) tell me if its ready for downlad anywhere (i think just exchanging the .ko should be fine)
<Xof> is there something screwy with the build environment?  Insanely small ulimits or something?  Weird kernel memory maps?
<fabbione> ogra: it should.. yes
<fabbione> Xof: the buildd have no ulimits
<fabbione> Xof: and nothing like strange memory mapping...
<fabbione> just plain vanilla kernels + security fixes...
<daniels> elmo: do we have a working i386 chroot on concordia?
<Xof> and how certain are you about the hardware?  (sbcl building is better at finding bad hardware than kernel compiles or gcc compiles)
<fabbione> Xof: in any case i suggest to show up in 6/8 hours from now...
<fabbione> when lamont is here...
<fabbione> Xof: well.. they builded a few 1000K packages...
<fabbione> so i guess they are reliable
<Xof> OK.  I'll hang on in here
<fabbione> Xof: lamont is our buildd admin
<fabbione> and he can for sure give you more info that i can
<pitti> lifeless: here
<pitti> lifeless: ?
<fabbione> pitti: a bunch of packages have been built with the translation strip thingy
<pitti> fabbione: cool, everything went well?
<fabbione> pitti: i think so...
<fabbione> do you want the list to check?
<fabbione> you can debdiff on people in my home/public_html/sparc
<pitti> fabbione: if they don't contain *.mo files any more in /usr/share/locale, then everything is alright
<pitti> fabbione: yes, I'll do that against previous versions
<fabbione> pitti: i am not sure which of them should have .mo files generally
<pitti> fabbione: do you have the previous version around there, too?
<pitti> fabbione: can you send me a list of recently built packages?
<fabbione> pitti: ok.. get some: evolution-data-server, gdm, gtk, hal, libgphoto, nasm, tetex-bin tiff, tspc
<fabbione> pitti: yes.. there is the entire build of sparc from day0 to now
<fabbione> i think gdm has .mo files..
<pitti> fabbione: looks perfect
<fabbione> 2964 -rw-r--r--    1 fabbione warthogs  3028614 Dec 29 05:33 gdm_2.6.0.6-0ubuntu2_sparc.deb
<fabbione> 1328 -rw-r--r--    1 fabbione warthogs  1354038 Jan  5 08:23 gdm_2.6.0.6-0ubuntu3_sparc.deb
<bob2> pitti: lifeless is out a-drinking
<pitti> fabbione: i debdiffed these two
<fabbione> did we really strip THAT much?
<pitti> oh, I don't think so
<pitti> or?
<fabbione> almost 50% of the gz is WAY too much
<pitti> fabbione: debdiff says only the mo files are away
<fabbione> than.. that's it
<fabbione> pitti: want to check for file sizes as well?
<pitti> fabbione: my gdm mo files are 5.2 MB
<fabbione> that makes sence
<fabbione> 1.5M compressed...
<pitti> fabbione: cool, this really gains much
<daniels> fabbione: if you have the resources space, could you please grab xorg_6.8.1-1ubuntu9* from ~daniels/xorg on either concordia or davis, and give it a spin 'round sparc?
<fabbione> daniels: what did you mess up this time? ;)
<daniels> fabbione: heh :) just the usual updates
<daniels> fabbione: including a complete resync back with XSF, a couple of new patches for XKB and stuff, a small loader tweak, etc
<daniels> the debian sync sucked
<daniels> remind me not to get that backlogged again
<fabbione> daniels: btw.. Overfiend was doing a dist-upgrade yesterday
* thom is not looking forward to the firefox merge he needs to do
<fabbione> that's why it was so slow
<fabbione> daniels: anyway i will build in a few minutes..
<fabbione> the buildd is idling atm
<daniels> fabb	oh, heh
<daniels> fabbione: cool, cheers
<daniels> fabbione: hold on, isn't necrotic supposed to be in a data centre or something?
<daniels> i thought redwald was local and necrotic was remote
<fabbione> daniels: yes and?
<fabbione> he still did a dist-upgrade...
<crimsun> fabbione: hmm, sparc? no. (I only have x86 unfortunately.)
<daniels> fabbione: i just thought it would have a bit more bandwidth if it was colocated or such
<fabbione> crimsun: than it wasn't you.. sorry
<crimsun> np
<fabbione> daniels: it wasn't a bw problem.. 
<fabbione> it was choaking on the cpu/ram
<bob2> fabbione: how fast is your sparc buildd?
<daniels> fabbione: oh, right
<fabbione> bob2: enough to keep up main...
<daniels> elmo: could I please get rman in halley's hoary chroot, and screen either in it, out of it, or both?
<fabbione> bob2: i will start building universe once i can free resources to manage the archive locally
<Treenaks> what is it with people and their obsession with "firewalls"
<bob2> omg lolz I have open portz!11
<Treenaks> bob2: yeah like that
<Treenaks> "I'm not stealthed!!!!11111oneone
<daniels> SHIELDS UP
<pitti> Morning seb128 
<seb128> hello
<pitti> Hi carlos, my friend
<pitti> carlos: yesterday night, when I tried to fall asleep I realized a reasonably big problem
<carlos> pitti: hi!
<carlos> how was the meeting?
<pitti> carlos: loooong
<seb128> hey carlos 
<pitti> carlos: but pretty good otherwise
<carlos> seb128: hey seb!, happy new year!
<carlos> pitti: just tell me ;-)
<pitti> I thought about how to get our translations into rosetta
<Keybuk> bob2: "glxgears is not an intrusion-detection system"
<bob2> hahahaha
<seb128> carlos: oh yeah, happy 2005 year :)
* daniels stares at Keybuk.
<daniels> ... no, it's not ...
<pitti> carlos: can you automatically import all hoary packages into rosetta now? or soon?
* Keybuk stares lovingly back
<haggai> Keybuk: uh, I meant hct not hcf in my mail :)
<carlos> pitti: I have a script to do it
<carlos> pitti: so don't worry
<pitti> carlos: do you import po files from source packages or mo files from debs?
<carlos> It's not finished to import the whole archive, but will be on time
<carlos> dude, forget the .mo files
<pitti> carlos: we need to import all packages really soon now
<carlos> pitti: I told you that they don't work as you think
<pitti> carlos: dude, the mo files would be the best for this :-)
<carlos> pitti: no, because you lose information
<pitti> carlos: the problem is that too many packages _patch_ po files 
<carlos> pitti: comments, headers, code references, etc...
<carlos> pitti: that's why the script is not finised
<pitti> carlos: so if you only look at the source package and get the po files, you get wrong data
<carlos> finished
<carlos> pitti: at this moment the cdbs packages are imported with all patches applied
<pitti> ah, so you try to apply patches before copying the pos?
<carlos> yeag
<Keybuk> haggai: I guessed :)
<carlos> yeah
<daniels> elmo: if you could fix davis's hoary chroot too, that'd be fantastic.  /dev/null being read-only kind of kills the build a little. :P
<pitti> carlos: and dpatch/dbs/other solutions?
<carlos> pitti: I'm importing po files with patches applied and po files for the deb templates
<daniels> (itmt, anyone with a powerpc who wants to try an xorg build on hoary, please grab the files out of davis:~daniels/xorg)
<daniels> dinnertime now
<carlos> pitti: need to look at those, see how they work and fix my script
<pitti> carlos: okay, fine
<pitti> carlos: yesterday it was proposed to get the mo files from the autobuilders and make translation debs of them
<pitti> carlos: but that's not possible since we cannot rebuild the whole archive 
<carlos> pitti: if you want good translations, forget the .mo files
<pitti> carlos: this was only meant as an intermediate hack until rosetta is finished
<pitti> carlos: when do you think rosetta has all packages and is ready for nightly automatic deployment?
<carlos> pitti: Mark asked us to import the whole archive as soon as Hoary freezes
<pitti> carlos: that's too late
<carlos> so you need it _now_
<pitti> carlos: at the point hoary freezes I need to have the whole structure ready
<pitti> carlos: mdz asked me to have everything ready by Feb 1
<pitti> carlos: I need some time to develop the deb building
<carlos> ok
<pitti> carlos: so interface-wise, I can expect a ZIP file of updated po files?
<carlos> pitti: I need to talk with daf about it
<carlos> but yes, I think that will be the final solution
<pitti> carlos: I would just like to start thinking (and coding) the deb creation
<carlos> ok
<pitti> carlos: so I can expect something along "here is a ZIP file with po files newer than the given timestamp"?
<carlos> yes
<pitti> carlos: cool
<carlos> but as I said, I need to confirm it with daf
<pitti> carlos: btw, I don't really need to know which package they belong to
<pitti> carlos: because we ship a big monolithic deb anyway
<pitti> carlos: how do you store the po files?
<fabbione> gmmmm
<pitti> carlos: i. e. how are they named?
<fabbione> well i guess i will keep stripping packages
<pitti> carlos: are they product/de.po or product_de.po or how?
<carlos> pitti: in fact... I think I could try to give you a set of .mo files so you don't need to compile them
<fabbione> until sparc will not hit archive there is no point in getting crazy
<pitti> carlos: well, only if it is easy
<pitti> carlos: I don't mind compiling them myself in the script
<carlos> pitti: we do it already so it's the same give you a set of .mo files or a set of .po files
<pitti> carlos: if it's already done, then mo is better, yes
<pitti> carlos: you have one mo per product and per language, right?
<carlos> pitti: right
<pitti> carlos: do you store them as product/de.po or de/product.po?
<carlos> pitti: it's stored inside a database, so I create them as you need them
<pitti> ah
<carlos> fabbione: what do you need then?
<Kamion> I must go and talk to the d-i translation coordinator about how on earth to deal with keeping rosetta translations in sync
<pitti> carlos: well, ideally I get de/product.mo
<fabbione> carlos: nothing...
<Kamion> (for which, obviously, I'll need po)
<fabbione> carlos: i just enabled the first buildd to strip translations, if lamont didn't do it this night
<carlos> pitti: not really. de/translation_domain.mo is what you need, believe me
<pitti> carlos: right, I mean that
<Kamion> fabbione: it doesn't strip translations from udebs, does it? <panic>
<pitti> Kamion: ahem...
<fabbione> Kamion: let me check...
<Kamion> please make sure it doesn't :)
<fabbione> i did build a few udebs
<pitti> Kamion: it currently strips away all mo files in directories which have a DEBIAN subdir
<Kamion> fuck
<elmo> uh, WTF broke /dev/null?
<fabbione> Mo.. not po
<pitti> Kamion: how can I tell apart an udeb dir from a deb dir?
<Kamion> I thought I mentioned that udebs weren't language-pack-able
<fabbione> elmo: udev
<pitti> Kamion: right, we strip _mo_ files, not _po_, if that makes a difference
<Kamion> no, it doesn't
<elmo> fabbione: this is a known bug?
<fabbione> Kamion: is debootstrap udeb ok?
<Kamion> debootstrap-udeb isn't translated
<Kamion> try anna
<fabbione> elmo: i experienced it only once inside the sparc chroot.. so i wasn't really sure it was just me
<pitti> Kamion: my current test for a debian package dir is the existance if DEBIAN/control
<fabbione> Kamion: i don't have anna rebuilt yet...
<pitti> Kamion: how can I tell if this dir becomes an udev and skip it?
<pitti> Kamion: s/udev/udeb/
<Keybuk> fabbione: is that on first-time udev installation?  or after boot?
<Kamion> pitti: give me a second I'm trying to find the canonical method
<fabbione> rootskel? no... archive-copier?
<Kamion> neither
<Kamion> main-menu?
<pitti> carlos: okay, fine for me then. 
<fabbione> Kamion: sorry i don't have any than...
<pitti> carlos: then I build a script expecting a bunch of <LANG>/<DOMAIN>.mo files
<fabbione> Kamion: with the new setting i did build:
<carlos> pitti: as soon as I prepare a small document with your requirements and talk with daf I will tell you the status of your request
<pitti> carlos: thanks
<Kamion> pitti: you can't tell reliably from just the build tree
<pitti> carlos: shall I write this small text smipped
<fabbione> archive-copier, busybox-cvs, console-tools, cupsys, d-i, openssh, rootskel
<pitti> carlos: snippet, I mean
<fabbione> Keybuk: first time installation afaict
<pitti> Kamion: so I have to lookup the directory name and grep it out of debian/control?
<elmo> okay, why would a device be busy if fuser and lsof can't find anything using it?
<Kamion> you can't get it reliably from debian/control either
<elmo> err, device, directory
<fabbione> Keybuk: like when you have a running system and you install udev for the first time.. permissions on some devices seems to be fuxked
<pitti> elmo: something mounted into it?
<carlos> pitti: as you want, I have it already in my xchat's logs
<Kamion> you have to look for the filename being built
<pitti> carlos: ah, ok
<Kamion> and check for .udeb
<Keybuk> fabbione: how recently?  udev certainly had real problems with that once-apon-a-time.  They're supposed to be fixed now though
<elmo> pitti: anyway to check what?
<Kamion> pitti: however, checking for 'Section: debian-installer' in DEBIAN/control would actually be a nearly-good-enough heuristic
<fabbione> Keybuk: i think it is related to the last change Md did to udev in order not to have to reboot the machine at first install
<Kamion> pitti: so yes, please exclude any build trees with Section: debian-installer in DEBIAN/control
<pitti> Kamion: how do I find out the final deb file name?
<fabbione> but again.. i am not sure 100%
<pitti> Kamion: okay, I can implement that quickly
<Kamion> pitti: you probably can't at the point when you're running pkgstriptranslations
<pitti> fabbione: can you disable stripping for now?
<fabbione> Kamion: nothing rings a bell out of that list?
<pitti> Kamion: yes, that's the problem
<Kamion> fabbione: none of those build translated udebs AFAIK
<fabbione> pitti: yes i can... do i need to rebuild the packages that have been done already?
<fabbione> Kamion: ok...
<pitti> fabbione: probably?
<Kamion> pitti: sorry for the last-minute alarm, I thought I'd brought this up
<fabbione> pitti: you know.. you really suck? ;)
<pitti> Kamion: thanks, about the right time
<pitti> fabbione: yes, I know :-/
<elmo> hmm, it only happened on davis, concordia is ok
<fabbione> elmo: is davis fixed now?
<elmo> fabbione: no, I think dev is bind mounted
<fabbione> elmo: ok....
<elmo> and I'd kind of like to figure out how/why udev broke the chroot
<fabbione> daniels: xorg is building... i will let you know how it goes
<Kamion> fabbione: out of those: archive-copier has no translations, busybox-cvs doesn't have .po files, console-tools cupsys debian-installer don't build any udebs, openssh doesn't install templates files in its udebs, and rootskel doesn't have .po files
<fabbione> Kamion: sorry that i couldn't help more...
<fabbione> but if you really want me to try i can do it manually
<fabbione> but it would take you the same time as for me
<Kamion> fabbione: it's ok, I was trying to say that none of those need to be rebuilt :)
<fabbione> ogra, mvo: http://people.ubuntulinux.org/~fabbione/avmfritz.ko for 2.6.10
<fabbione> Kamion: eheh ok thanks :-)
<pitti> fabbione: seems to be my lucky day :-)
<fabbione> it only adds some extra printk for debugging.. it doesn't fix anything..
<elmo> aha, /dev/pts and /dev/shm were also bind mounted
<fabbione> ogra, mvo: dmesg is welcome
<fabbione> ogra, mvo: oh btw.. ASAP thanks ;)
<elmo> why the heck didn't this kill everything else
<Mithrandir> fabbione: is that the Fritz! DSL driver thingy?
<fabbione> Mithrandir: yes
<fabbione> ISDN..
<fabbione> DSL is luxury ;)
<Mithrandir> ISDN isn't interesting, I want the DSL one. :P
<Mithrandir> for ISDN, I use hardware routers.
<fabbione> Mithrandir: so do i...
<fabbione> c801 ;)
<fabbione> with ipv6 support
<Mithrandir> the 801 has ipv6 support?
<fabbione> Mithrandir: with proper IOS.. yes
<Mithrandir> nice
<fabbione> too bad it doesn't support BGP
<fabbione> or ospf iirc
<Mithrandir> I only have a large pile of 7xx routers
<fabbione> but rip is ok ;)
<fabbione> oh yeah.. i gave the 7xx to my friends in italy
<Mithrandir> they're horrible to configure, though
<bob2> fabbione: oh, woo, sleep patch. thanks!
<fabbione> bob2: given that it compiles on 2.6.10
<fabbione> a lot of bits from that patch have been merged upstream or so..
<bob2> ah, right
<fabbione> and again.. for me ppc is "it compiles.. it's ready for stable release"
<bob2> hah
<elmo> anyway, davis is fixed now
<fabbione> elmo: thanks dude
* fabbione tests per arch dpatching
<fabbione> it adds a Build-Dep on cpp...
<fabbione> but who cares..
<elmo> cpp is build-essential?
<fabbione> elmo: it wasn't with zgrep cpp /usr/share/doc/build-essential/*
<pitti> fabbione: yep, build-essential depends on gcc depends on cpp
<fabbione> ok
<fabbione> i can kill it...
<fabbione> someone should FILE ANOTHER BUG ON DPATCH MAN PAGE!
<fabbione> DPATCH MUST DIE!
<pitti> yeah
<pitti> fabbione: why do you use it anyway?
<fabbione> if i had 48 hours a day i would have redone the kernel patcka...
<fabbione> package
<fabbione> pitti: because i found the kernel in that way already...
<fabbione> you know.. i was only supposed to do 2.6.8 -> 2.6.9 transition
<azeem> famous last words
<pitti> fabbione: I know, is it very hard to convert to quilt or simple patch?
<fabbione> azeem: exactly
<fabbione> pitti: it's a royal pain..
<pitti> fabbione: there is this monolithic patch building thingy
<fabbione> i was considering dbs...
<pitti> fabbione: this is probably the harder part to convert, right?
<fabbione> pitti: exactly..
<pitti> fabbione: oh, dbs could be nice for the kernel
<fabbione> so i guess we will survive to it for hoary
<fabbione> and if i will still maintain the kernel after i will spend a few days to convert it to something sane
<pitti> fabbione, Kamion: I uploaded version 2 of pkgstriptranslations which now ignores packages in the debian-installer section
<Mithrandir> the OOo patch system is _really_ nice.
<pitti> fabbione: and I updated the seeds so that the package should now be in main
<fabbione> pitti: out of curiosity.. how do you determine debian-install section?
<fabbione> +er
<pitti> fabbione: I read ^Section: from <build-directory>/DEBIAN/control
<pitti> fabbione: that's what Kamion suggested
<fabbione> HMMM
<pitti> fabbione: I tested it with the udev package (which also produves an udeb)
<pitti> fabbione: what's wrong with that?
<fabbione> Kamion: are we sure that all the udebs have these information in place and not from the overrides?
<fabbione> pitti, Kamion: given that i didn't fuck up anything in my ipv6 stats: http://debdev.fabbione.net/cgi-bin/getlist?5+nopri+nosec
<fabbione> these are packages that have no Section and Priority entry.
<fabbione> but cross checking a couple of them should be easy
<Kamion> fabbione: I think most of them do, but the ones that aren't are easily fixed
<Kamion> fabbione: more importantly I know of no better test at that point in the build :-/
<pitti> fabbione: do you know of any better way to detect an udeb before it is actually built with dpkg-builddeb?
<fabbione> Kamion: yup.. it was just a warning
<fabbione> pitti: no. Kamion is our god here.
<fabbione> AVE O SOMMO KAMION
<pitti> Kamion: should a package break because of that, it shouldn't be too hard to upload another one with an explicit Section, right?
<pitti> Kamion: this would trigger rebuilding and everything should be okay afterwards again
<Kamion> 'XC-Package-Type: udeb' is sometimes used in newer packages, but that field only shows up in debian/control and the .changes file, not DEBIAN/control
<Kamion> pitti: right, exactly
<Kamion> <cjwatson@cairhien ~/src/debian/debian-installer/trunk/debian-installer/packages
<Kamion> >$ find -path \*/debian/control | xargs grep -L ^Section:
<Kamion> <cjwatson@cairhien ~/src/debian/debian-installer/trunk/debian-installer/packages
<Kamion> >$
<Kamion> looks good to me
<Kamion> er, oops
<Kamion> <cjwatson@cairhien ~/src/debian/debian-installer/trunk/debian-installer/packages
<Kamion> >$ find -path \*/debian/control | xargs grep -L '^Section: debian-installer'
<Kamion> ./kernel/kernel-wedge/debian/control
<Kamion> those two are build helpers
<Kamion> ./packages-build/debian/control
<Kamion> there'll be other udebs too, of course
<pitti> Kamion: udev-udeb's debian/control has no sign of it being an udeb
<pitti> Kamion: however, it has a proper section
<Kamion> how do you mean, no sign?
<pitti> Kamion: oops, sorry
<pitti> Kamion: it has this XC-Package-Type field
<Kamion> indeed, most udebs are that way
<Kamion> not all, though
<Kamion> none of them have any *more* sign than udev-udeb does
<pitti> Kamion: I can parse debain/control in addition, if necessary
<pitti> Kamion: debian/control is a little more complicated than DEBIAN/control because I have multiple packages
<Kamion> pitti: I think it's probably ok as it is; I'm comfortable I can catch any exceptions
<pitti> Kamion: but it shuold be possible
<pitti> Kamion: okay
<fabbione> COOL the dpatch per arch is broken on the only arch on which i need it!
* Mithrandir snickers
* fabbione hugs dpatch author and kisses him with the tounge
<fabbione> bah.. food time
* mvo_ get's the wrong mental images
<fabbione> mvo_: let's see if this is better
* fabbione covers the dpatch author with a lot of napalm love and lights a cigarette
<mvo_> fabbione: no, not really. but a lot cleaner :p
<Kamion> <cjwatson@riva /mirror/debian>$ for x in `zcat dists/unstable/main/debian-installer/binary-i386/Packages.gz | grep-dctrl -nsFilename ''`; do dpkg -f "$x" Section; done | grep -vx debian-installer
<Kamion> <cjwatson@riva /mirror/debian>$
<Kamion> pitti: looks good
* Kamion loves Unix, incidentally
<Treenaks> mvo_: imagine Reservoir Dogs
<Kamion> same goes for hoary/i386
<pitti> neat
* Mithrandir likes $( ) better than ` `, but otherwise agrees with Kamion
<Kamion> yeah, haven't quite kicked that habit yet
<Mithrandir> it's a keypress less and a lot more readable. :)
<Mithrandir> (` being dead here)
<pitti> Mithrandir: could you take a look at mailman?
<carlos> pitti: I just sent the mail about your request with CC to you, could you review it in case I forgot anything?
<Keybuk> for vs. xargs, discuss.
<Mithrandir> pitti: yes, it's on my list for today.
<pitti> carlos: I do
<carlos> pitti: thanks
<Kamion> Mithrandir: ah, $() is a keypress more for me, so ...
<Mithrandir> Kamion: it's more of a habit than anything else, though
<Kamion> actually two keypresses, or four if I have to press shift separately for each one
<Mithrandir> shift isn't a keypress :P
<Mithrandir> I tend to have a finger above shift anyhow :)
<pitti> carlos: fine by me
<pitti> carlos: do we also have a possibility to create a base package?
<pitti> carlos: i. e. get a file of _all_ translations? (ugh)
<pitti> carlos: or can I just use timestamp 19700101 for that?
<pitti> carlos: ^ this seems to be too much overhead for this purpose
<fabbione> mvo_: can you test the driver please?
<mvo_> fabbione: sure
* mvo_ downloads the kernel now
<Kamion> hm, I forgot to put supported+build-depends rather than supported on the DVD image
<fabbione> mvo_: no no..
<mvo_> fabbione: ?
<fabbione> just the driver from people.u.c
<fabbione> <fabbione> ogra, mvo: http://people.ubuntulinux.org/~fabbione/avmfritz.ko for
<fabbione>            2.6.10
<fabbione> <fabbione> it only adds some extra printk for debugging.. it doesn't fix
<fabbione>            anything..
<fabbione> <fabbione> ogra, mvo: dmesg is welcome
<fabbione> just try that one..
<fabbione> it will help me to track the bug down
<fabbione> there is no need to download a kernel
<fabbione> because there is no new kernel
<ogra> great....i can test it tonight (am at the office currently)
<fabbione> that one is for 686 build
<fabbione> ogra: ok thanks
<mvo_> fabbione: ok, will do it now
<fabbione> mvo_: ok.. 
<fabbione> remember -> 686 <-
<mvo_> fabbione: yep
<carlos> pitti: the 19700101 think will work
<carlos>  /s/think/thing/
<pitti> carlos: it doesn't produce too much overhead? which could be avoided by another solution?
<carlos> pitti: samething
<pitti> carlos: exporting all pos don't require comparing timestamps and so
<carlos> pitti: well, perhaps you could remove some sql queries
<pitti> carlos: well, if it works, then it is probably okay
<carlos> but I think it's not a big improvement
<pitti> carlos: we do this only very seldom
<pitti> carlos: I'm more concerned about people doing these queries maliciously to DoS the server
<pitti> carlos: or google accidentially trying this over and over again
<carlos> pitti: that url will be restricted by user + password
<pitti> carlos: ah, cool
<carlos> and we could restrict it to a concrete user + password so only people we want are able to do it
<pitti> carlos: I should create a dedicated "export" account and use that in the auto deb builders
<carlos> pitti: it's an option
<seb128> elmo: libbonobo sync please
<thom> seb128: um, why would my panel lose it's menus? (how do i debug this usefully?) pkilling gnome-panel or gnome-session doesn't help, and it was working earlier today with no changes
<thom> (i also can't right click on the panel to add applets etc)
<seb128> only the menu ? the rest of the panel/nautilus/... work ?
<seb128> ok
<thom> the bottom panel (ie, workspace switcher and app list) is fine
<seb128> killall gnome-panel gnome-vfs-daemon nautilus trashapplet drivemount_applet2
<seb128> ?
<seb128> weird
<thom> yep, that fixed it
<seb128> ok
<thom> trashapplet and drivemount_applet2 aren't running
<seb128> still #4794 ..
<thom> ahr
<seb128> BTW, you have already worked on the xscreensaver package ?
<thom> a while ago, yes
<seb128> #3042 #3044 need sombody to fix them, you are not interested in doing that by luck ? :p
<thom> i'll have a look
<seb128> thanks :)
<seb128> elmo: gnome-gv sync please
<thom> 3044 looks like a bit of a minefield
<seb128> yeah ...
<ogra> isnt that common with this bug reporter ?
<Kamion> hm, I suppose I should cycle my arch archives
<seb128> but 3042 would be nice to fix
<Kamion> ogra: :-)
<thom> ogra: a minefield is usually safer than said reporter's usual bug files
<robtaylor> carlos: ping!
<bob2> fgod msn is useless
<bob2> I really cannot imagine designing a less useful chat protocol
<carlos> robtaylor: pong!
<robtaylor> carlos: well i recreated my mirror yesterday, 
<robtaylor> http://sourcecontrol.net/~rtaylor/robtaylor@fastmail.fm--2004--accessd/
<robtaylor> is .listing still missing?
<bob2> god
<robtaylor> i've got a sneaking suspicon i might need to recreate my main archive with -l too :/
<robtaylor> bob2: whats bugging you?
<robtaylor> carlos: make that, .listing seems to be missing to me...
<robtaylor> and i definitly used -l when creating the mirror :(
<carlos> robtaylor: no, don't think you need to recreate your archive, only the mirror...
<carlos> robtaylor: http://sourcecontrol.net/~rtaylor/robtaylor@fastmail.fm--2004--accessd/.listing
<carlos> it's there
<carlos> apache is hidding it, that's all
<robtaylor> carlos: ah good :)
<robtaylor> well, there you go, test it out. i think i have a couple of uncommitted local mods at home i forgot about, but if you look in accessd/test you should get an idea for running it
<seb128> elmo: gnome-pilot and gnome-pilot-conduits sync please
<robtaylor> (the test code currently hardcodes my username and the uncommitted changes fix that)
<bob2> "echo it sure does > =meta-info/http-blows" on the mirror
<trulux> pitti, hey
<robtaylor> might be good to get someone to do a new rev from cgvs of dbus, as my changes are now in
<pitti> hi trulux 
<trulux> pitti, http://wiki.debian-hardened.org/Development_layout_organization
<seb128> elmo: and ghfaxviewer too :)
<carlos> robtaylor: will look at it this weekend
<carlos> robtaylor: good work 
<carlos> :-)
<robtaylor> carlos: thx :)
<thom> seb128: although i guess we could wimp out and just provide xscreensaver-for-us; rss-glx-for-us; and then some more packages for the rest, and then have a screensavers metapackage
<robtaylor> carlos: I'll try and build a hoary dbus package from current cvs tonight if i get the chance..
* robtaylor pokes daniels
<carlos> robtaylor: I think daniels said hoary's one is from CVS so it should get your changes soon, right?
* carlos is using warty atm
<thom> he was certainly planning to do so
<carlos> will test it in my laptop
<robtaylor> carlos: yep, whenever he does the next pull (my patch went in about 8 days after the last pull)
<robtaylor> carlos: if your're on warty then just use my packages on sourcecontrol.net/~rtaylor
<sjoerd> robtaylor: i'm preparing a new package for debian, so daniels will probably sync with that 
<carlos> robtaylor: ok
<robtaylor> sjoerd: cool :)
<seb128> thom: yep, that's an idea
<thom> not quite in the spirit of the thing, but close
<robtaylor> sjoerd: will only python2.4 bindings be produced, or both 2.3 and 2.4?
<sjoerd> robtaylor: for debian 2.3, for hoary is up to daniels
* robtaylor hopes for both on hoary
<sjoerd> how's the accessd thingy going ?
<lamont> good morning world
<mvo_> ping haggai 
<haggai> mvo_: pong
<mvo_> haggai: do you have a idea about ubuntu #5020? 
<haggai> mvo_: not without digging deeply.  We turned off the file picker by default in unstable because it has several problems
<haggai> mvo_: so a merge from debian would solve it for now
<mvo_> haggai: ok, thanks
<ogra> mvo_: gnome-vfs probably needs the lo interface, could it be that firestarter bolcks this somehow ?
<mvo_> ogra: that would be silly of firestarter. I got another report today about problems with the file-picker and he claims that he does not run any firewall software
<haggai> mvo_: he claims he doesn't run firestarter, not any firewall software
<ogra> mvo_: ah, ok, was just an idea....(i've seen weird FW software in my life ;) )
<haggai> mvo_: he might still have a filewall
<haggai> uh, firewall
<mvo_> haggai: correct
<ogra> lol
<fabbione> hey lamont 
<mvo_> I'll ask to be sure
<fabbione> lamont: please read the scrollback...
<fabbione> lamont: i can't access the chroot on hppa
<fabbione> lamont: it complains that it can't find my id
* lamont grumbles
<thom> are we doing ubuntu/hppa now? :P
<fabbione> thom: go back to test ia64 kernels please ;)
<thom> fabbione: not at home :/
<fabbione> thom: when you will be at home :)
<fabbione> thom: the only sure thing is that they compile...
<fabbione> that's all i know
<thom> i won't have a connection at home until next week
<lamont> fabbione: try now
<fabbione> Executing shell in 'sid' chroot.
<fabbione> crimsun: Authentication service cannot retrieve authentication info.
<fabbione> (Ignored)
<fabbione> ops
<lamont> fabbione: the ia64 kernel in yesterday's daily build boots far enough to get to anna segv'ing...
<fabbione> s/crimsun/su
<haggai> mvo_: I'll write the workaround to the log
<mvo_> haggai: that's nice, thanks a lot
<fabbione> lamont: nice...
<fabbione> for the kernel.. poor anna
<lamont> fabbione: once you say 'dchroot' and it says 'can't retrieve auth info', say ls -lid /
<Kamion> lamont: oh yes, is that box in a state where I can play with it now?
<lamont> what's the inode of the root dir...
<lamont> Kamion: sitting at a shell prompt with anna lying on the floor
<fabbione> 2850829 drwxr-xr-x  20 root root 4096 Jan  4 15:16 /
<lamont> fabbione: that'd be chrooted.
<fabbione> lamont: yes.. i could see that.. without the inode :-)
<fabbione> i was just reporting the warning
<lamont> I bet it's pam related, or something.
<fabbione> lamont: iirc elmo knows what it is
<fabbione> did you configure shadow and stuff like that?
<fabbione> if so.. is my account there too?
<fabbione> i think that shadow on/off would do
<fabbione> lamont: but i need to workaround yet another dpatch bug to have hppa in.
<fabbione> lamont: since patch x arch is broken
<lamont> ew
<fabbione> i just figured with ppc...
<fabbione> so i will need to do some blackmagic woodo to get it done
* lamont goes to make breakfast
<cartman> hmm anyone here working on KUbuntu?
<lamont> fabbione: you around?
<fabbione> yup
<lamont> do you have an ipv6 enabled host with postfix 2.1.5-x installed on it
<lamont> ?
<fabbione> lamont: checking...
<lamont> and could you see if 2.1.5-4 works in your environment, or just fails to deliver mail at all?
<Treenaks> 2.1.5-x is hoary-current ?
<lamont> yeag
<fabbione> lamont: from debian or ubuntu?
<Treenaks> works for me :)
* lamont is looking at 288728
<Treenaks> works fine... I think this has to do with people who use CNAMEs or IPs as MXes
<Treenaks> (which is b0rken)
<lamont> stp.dias.ie. doesn't appear broken...
<fabbione> lamont: checking with hoary...
<Treenaks> Received: from localhost.localdomain (laptop.foodfight.org [IPv6:2001:960:70e:1:204:e2ff:fea5:d988] )                      
<Treenaks>         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))                                                       
<Treenaks> works great..
<lamont>  localhost.localdomain
<fabbione> Treenaks: try to send a mail to something that doesn't have ipv6...
* lamont beats gethostbyname
<fabbione> i think that's the whole point
<lamont> lamont@mmjgroup.com would fit that bil.
<Treenaks> fabbione: ubuntu mailing lists work
<lamont> bill.
<fabbione> hmm
<daniels> lamont: we've had weeeeird issues on fd.o
<daniels> lamont: but that's mainly due to wildcard afaict
<daniels> lamont: prometheus.infradead.org (IIRC -- the primary MX for infradead, in any case) is IPv6-only
<daniels> lamont: and fd.o had a wildcard
<daniels> lamont: so it would fail an A on the infradead.org MX, and end up delivering to localhost
<daniels> creating a loop
<lamont> interestingly, stp.dias.ie. has MX but no A
<daniels> so I had to hardcode one of its IPv6 MXes in to the transport table
<Treenaks> try mailing me at my "@treenaks.tk" address.. that's a wildcard MX
<fabbione> BAH
* lamont wants l@tk
<mjt> what's the problem?
<mjt> Hi Lamont! ;)
<Treenaks> lamont: that's going to be hard :)
<mjt> oh, I haven't played with ipv6 in postfix yet...
<lamont> Treenaks: yeah,
<Treenaks> lamont: (and I know, because I could give you this with one INSERT INTO probably ;))
<lamont> and it's quite possible that I broke the ipv6 patch in 2.1.5, although that may not be it...
<lamont> Treenaks: it's already taken?  I, um, need it for testing postfix.  yeah. that's it.
<fabbione> lamont: i think you got a mail from me...
<Treenaks> lamont: it's not yet taken, but I kind of like the steady amount of money my employer gives me every month
<fabbione> but that one went out via my smarthost
<lamont> gah.  looks to be PEBKAC
<fabbione> PEBKAC?
<Treenaks> fabbione: en.wikipedia.org/wiki/PEBKAC
<mjt> "Problem Exists Between Keyboard And Chair:
<fabbione> ahh
<fabbione> lamont: i did send you a second mail directly from an ipv6 host
<fabbione> according to my logs it has been delivered correctly
<lamont> fabbione: got it.
<lamont> I was running down the list of things it could be (in their setup), you see....
<Treenaks> lamont: what's their problem?
<lamont> "I fixed the DNS and it now seems to be happy."
<lamont> summary: "Postfix is horribly broken!!!" "oh wait, it was just our DNS.  never mind."
<lamont> fabbione: on the hppa patch - it might be good to see what arch-indep patches there are, and see if they still need to be...  If you make a list, I'll pester.
<fabbione> lamont: i need to make a workaround to apply patches per arch first...
<fabbione> lamont: plus i don't understand why all this stuff is not pushed upstream
<lamont> it's being pushed - they're manically working on things
<lamont> the one you commented on yesterday was a gcc-3.3 workaround that may well not need to be there any more
<fabbione> lamont: yeah... but tbh i am not that expert in gcc on hppa to be able to say that it is still required or not....
<fabbione> i can make notes.. that's for sure..
<lamont> fabbione: exactly - I was just gonna poke grant on that one... :-)
<Kamion> is there an ia64 porting box in the LAN that I can compile stuff on?
<fabbione> Kamion: halley
<Kamion> thanks
<daniels> Kamion: i'll fight you for halley
<daniels> daniels@catsby:~/canonical/xorg/arch/pristine% scp xorg_6.8.1-1ubuntu9.diff.gz xorg_6.8.1-1ubuntu9.dsc halley.ubuntu.com:xorg/
<daniels> elmo: thanks for fixing davis and halley, btw
<daniels> fabbione: btw, if you were building on sparc, you want to grab the sources again
<daniels> the old one was, uh, a little broken
<daniels> (wouldn't pass manifest)
* lamont goes after low-hanging merges
<fabbione> daniels: OH CHRIST
<fabbione> it is still building and you already ask for a rebuild?
* daniels coughs.
<lamont> doko?
<fabbione> are you serious?
<daniels> well, you can sorta hack around it
<fabbione> daniels: it's pointless to hack around...
<daniels> once the install target's done, move koi8rxterm.1x and lxterm.1x to .1 in usr/X11R6/man/man1
<daniels> then re-run binary, so you'll just work through the rest of the install
<daniels> i've already fixed it locally
<fabbione> daniels: where are the new sources?
<fabbione> no i will just rebuild...
<daniels> concordia/davis/halley
<daniels> ~daniels/xorg
<daniels> quicker to snarf from there than my home dsl
<daniels> uplink is slow as hell
<lamont> daniels: you don't know hell
<daniels> lamont: sure I do
<lamont> heh
<fabbione> i will give hell to daniel if this upload will fuck sparc :-))))))
<lamont> fabbione: but what would he do with it?
<fabbione> hmmm good question...
<fabbione> i have some ideas.. but i can't tell them here
<daniels> fabbione: see, better you having to rebuild it than me totally breaking it, no? :)
<fabbione> daniels: time you buy a sparc?
<daniels> fabbione: i have a u5 under my desk
<daniels> fabbione: my downstream is still totally saturated with everything else though
<daniels> fabbione: i have a pegasos to upgrade from debian to hoary (only turned it on once), and the u5 to install
<daniels> but both of those are lower priority than xorg and lrm, both of which I'm working on now ;)
<fabbione> daniels: time to upgrade downstream? ;)
<daniels> heh
<robtaylor> sjoerd: ah, missed your message earlier, its seems to be going pretty well, written all the basics and one backend now..
<mjt> btw, is there any help "wanted" for xorg? any outstanding probs?
<daniels> FRIG.
<robtaylor> sjoerd: next up i want to do a LDAP backend, but that requires a bit more knowledge of LDAP admin than i currently have :)
<robtaylor> daniels: did you catch my poking earlier?
<daniels> elmo: vim on halley pls
<sjoerd> robtaylor: could you announce it somewhere :) 
<daniels> robtaylor: can't say I did, sorry
<daniels> mjt: not hugely, no
<daniels> mjt: unless you want to bring the modular packages up to date ;)
<sjoerd> robtaylor: i'm seeing the need for it on the hal list on a regular basis, so it would be nice if other people start looking at it i guess (and not starting with other solutions)
<robtaylor> daniels: just requesting a new cvs pull on hoarys dbus packages for some new python binding stuff..
<mjt> uh-oh... fsvo "want" ;)
<robtaylor> sjoerd: Guess i should. i was kinda waiting for at least one other person to look at it and tell me its not crack yet :)
<daniels> robtaylor: sure, won't happen hugely soon tho
<robtaylor> daniels: np, just wanted to make sure it happens at some point :)
<daniels> robtaylor: sure :)
<daniels> poke me in a week if i haven't done it
<vinsci> is the source for malone available somehwere?
<robtaylor> sjoerd: are you familiar with the design? what sort of usages are you seeing?
<robtaylor> daniels: sure :)
<sjoerd> robtaylor: i've discussed it with carlos and pitti somewhat in mataro
<robtaylor> sjoerd: cool
* robtaylor ponders where he should host the project...
<sjoerd> robtaylor: for stuff like powermanager (http://live.gnome.org/PowerManager) 
<robtaylor> monkey power?!
<robtaylor> right so powermanager would just make requests to accessd for authorisation, groovr
* robtaylor notes to write an example glib client
<carlos> robtaylor: freedesktop is the right place to host it. Until that moment, we could use my personal server
* carlos leaves
<carlos> see you later
<robtaylor> carlos: later :)
<Kamion> daniels: halley's hoary chroot has vim
<mako> thom, elmo: i need apache utf8 love
<sladen> echo AddCharset UTF-8 .html
<sladen> echo AddCharset UTF-8 .html > .htaccess
<Treenaks> AddDefaultCharset UTF-8 ?
<daniels> carlos: what do you want to put on fd.o?
<daniels> fabbione: also, edit debian/xterm.install and s/*.1x/*.1/, sorry
* mjt wonders why ubuntu xorg package does not want to build on his sarge system...
<Kamion> hm, I wonder if I can squeeze a man-db fix for Turkish in under the UVF
<mjt> xorg build fails at the very end, telling the manifest filelist is too different...
<thom> mako: um, where, when, and why?
<ogra> Kamion: why should this be affected by UVF... as long as you dont change the whole man-db to a new version its only a patch or not ?
<Kamion> "upstream" => Debian
<mako> thom: i switched traffic to utf-8.. apache on rookery seems to still be serving it as iso-8859-1
<Kamion> ogra: the point is that automatic syncs from Debian stop at UVF
<thom> yes.
<mako> thom: http://people.ubuntulinux.org/~mako/ubuntu-traffic/
<Kamion> if I wait until after UVF I have to go to more effort to get the fix through :P
<ogra> Kamion: but manually is still possible ?
<Kamion> yes
<mako> thom: and aparently, i can't .htaccess the problem away
<thom> nope
<mako> so.. can i get at least the default charset for my homedir set to utf-8?
<Kamion> also on principle I don't want to have to branch man-db for Ubuntu, because I've used it as an example of the sort of package that shouldn't need to be branched :)
<ogra> Kamion: oh :)
<thom> we probably ought to do it for the whole machine, since we're pimping UTF-8
<mako> thom: that would be my suggestion :)
<mjt> oh oh, no utf-8 please!....  It slows down things like grep VERY significantly...
<mjt> about 50 times difference
<Kamion> we should fix that not ignore it
<mako> mjt: are you serious?
<Kamion> like it or not we *are* switching to UTF-8
<mjt> mako: unfortunately yes
<Kamion> the benefits of interoperation are far too significant to ignore
<mako> mjt: webpages to not take 50x longer to download on utf-8
<Kamion> #181378 et al
<mjt> webpages aren't, but using utf8 for the whole system is something differemt
<mjt> different
<mjt> $ time grep -r 'a+b' /usr/include 
<mjt> user    0m0.190s
<mjt> $ time LANG=ru_RU.UTF-8 grep -r 'a+b' /usr/include
<mjt> user    0m10.032s
<ogra> mjt: hmm 3x the amount of bytes in the chars results in 50x slower performance ?
<mjt> go figure
<mjt> that's not about number of bytes
<Kamion> #181378 includes a patch
<Kamion> perhaps try that out
<mjt> the prob is in glibc
<ogra> mjt: i understand that its about conversion, but anyway....this is not caused by utf8, rather by the bad conversion
<mako> mjt: in any case, the choice of locale if you care about this stuff is up to you
<Kamion> certainly we're not deleting old locales
<mako> mjt: but utf-8 is the only sane default at this point
<mjt> yes, i understand
<mako> mjt: latin-* is *insanity*
<ogra> mjt: and for the future ;)
<Kamion> the thought of trying to make encoding transliteration over ssh sessions work "properly" (for whatever value of properly you want) makes my head hurt
<mako> i mean for traffic, there's no way i could do it correctly in w/ a non-unicode encoding
<sladen> mjt: can you knock up a shell script/ test example that shows the difference between UTF-8 and C for grep (if that's where you think a problem is)
<Kamion> sladen: see the bug I referred to
<mjt> sladen: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181378
<mjt> sladen: and I just pasted `time' results from my system
<mjt> 0m10.032s vs 0m0.190s
<mako> thom: should i send mail to admin or are you just going to handle it?
<thom> send mail to admin
<mjt> hm...  10 vs 0.1 is 100 times difference, not 50!.. :(
<mako> mjt: ITS WORTH IT :)
<mako> actually, imo, it is
<mjt> that patch attached to #181378 is for grep itself.  However I think grep does nothing wrong in the first place
<mjt> grep calls mbrtowc() for every input char to determine it's width
<Kamion> caching that sounds sane to me
<mjt> and this is where it is slows down.  mbrtowc() (from glibc) is the routine which is the problem. 
<mjt> if you look at the implementation of mbrtowc().. oh well.. ;)
<mjt> it is loading/initializing/unloading gconv module each time it is called.
<fabbione> daniels: another change??????
<ogra> mjt: other apps that could prove this theory ?
<sladen> Kamion: one of the beatiful things about the UTF-8 is the charater width can be obtained entirely from the first character with nothing more than a mask
<mjt> theory?
<daniels> fabbione: yeah, now builds to completion on amd64 and powerpc
<daniels> i386 and ia64 are still churning their way through
<mdz> mako: please file a bug about that apache charset thing if you haven't already
<fabbione> daniels: ok.. where and what do i need to change?
<daniels> fabbione: do you want to test nvidia-glx with 2.6.10? :)
<daniels> fabbione: debian/xterm.install, change koi8rxterm.1x and lxterm.1x to koi8rxterm.1 and lxterm.1
<fabbione> daniels: sure.. hook me up the packages..
<mako> mdz: wait.. a bug against the apache2 package in ubuntu?
<mako> mdz: i haven't
<mdz> mako: yes
<mako> mdz: doing it now
<mdz> anything which isn't expecting a UTF-8 world out of the box is a bug in hoary
<thom> oof
<mako> ubuntu rocks
* thom shakes his fist at mako 
<mako> thom: so.. isn't there a way to hae apache parse the <?xml line of xhtml and then set of the charset appropriately?
<fabbione> daniels: is the MANIFEST.sparc ok for these 2 files?
<daniels> fabbione: cool, hold up a sec
<daniels> fabbione: yeah
<vinsci> is any of the launchpad source code available somehwere? Looking specifically for Malone, for possible use in another project
<fabbione> daniels: ok. updated.. let see what we happen
<thom> mako: GACK!
<fabbione> daniels: i won't test the packages until tomorrow
<fabbione> so take your time...
<thom> (yes, you could write a filter to do so)
<fabbione> BECAUSE I WIN AGAIN!
<fabbione> ibook go to nap DIE DIE DIE DIE
<mako> thom: i think that would be very slick and very sane.. it would Do The Right Thing most/much of the time
<fabbione> it took me only 5 hours to rediff that patch
<fabbione> i wonder if it can compiles...
<mako> thom: but mdz is right.. for non-xml where we can't tell, it should default to utf-8
<daniels> fabbione: suits me, i want to sleep soon
<daniels> fabbione: let me know how sparc goes and i'll upload it in the morning if it's all alright
<fabbione> daniels: i need to stop soon or tomorrow i will never wake up from suspend to bed
<Kamion> vinsci: not currently, I'm afraid
<daniels> fabbione: i know the feeling
* daniels is getting old. ;)
<ogra> heh
<thom> daniels: you wish
<trukulo> hi ogra
<mako> dudeadude, i forgot my bugzilla password ONCE A WEEK
<ogra> hi :)
<trukulo> made a new version of the package for sarge/sid :)
<trukulo> (graveman)
<ogra> yay
<daniels> thom: not as ancient as you, mind
<vinsci> Kamion, ok thanks.  Whom should I approach to discuss that?
<daniels> thom: i'm not decrepit yet
<thom> pfft, so you claim
<ogra> trukulo: did you include a .desktop file 
<ogra> ?
<Kamion> vinsci: #launchpad would probably be a better place to start than here
<trukulo> ogra: how do you put cdrecord? as recommend or dep ?
<daniels> thom: never did find a copy of never, never land with a 'proper' extra cd, btw
<trukulo> no, i'didn't, i want to do it in the next version of the package
<trukulo> i can use yours
<daniels> thom: so got one today (among many others) with just the one cd
<ogra> trukulo: dep, for sure....it wont work without it
<vinsci> Kamion, ah, dind't know about that channel
<trukulo> ok, i wasn't sure about it
<ogra> trukulo: grab what you need ;)
<trukulo> so : cdrecord, mkisofs readcd ans sox as deps ?
<mako> thom: right now, the default is iso-8859-1, which is pretty crap character encoding.. not yoyo symbol even
<mdz> thom: a filter?
<trukulo> ogra: wanna talk with you to help in the package
<trukulo> we can share resources (man page, icons, docs... )
<daniels> mdz: a2 lets you chain together filters, which let you perform arbitrary transformations
<daniels> mdz: e.g. php processing, compression, whatever
<ogra> trukulo: yup....later, if i'm home....currently i'm at the office....sitting around and waiting for the end of the day to start the important work ;)
<daniels> hm.
<mako> mdz: i want one that will parse the xml line and set the charset to whatever the xml claims it is
<trukulo> not today, olivier, another day we can talk about this, now i have to go for 2 days
<trukulo> ok ?
<ogra> trukulo: ok, np.
<daniels> at this rate, i won't have finished rsyncing the i386+source+powerpc archive by the time my amd64 turns up
<trukulo> perf.
<mdz> mako: I thought we were talking about a directory listing
<mjt> mako: what apache bug?
<mdz> not the contents of a file
<mako> mjt: well, i'm filing it
<mako> mdz: no.. files
<mjt> here, apache works with utf8
<mako> mdz: i just moved traffic to utf-8 yesterday.. and it looks crap
<mdz> eek
<mako> because it is not, in fact, utf-8
<mdz> that sounds much harder :-)
<mako> no, no
<thom> mdz: AddDefaultCharset UTF-8 
<mjt> if there's no other defaultCHarset ;)
<mdz> thom: I was thinking that it would be a relatively safe assumption to assume that filenames were UTF-8 encoded, since we're going in that direction
<mako> mdz: but my other suggestion was to parse the first line of xml/xhtml documents.. where the charset is declared
<mdz> but switching the default charset for the contents of files sounds like the upgrade problem from hell
<mako> mdz: and then to have apache send that as the charset for that document
<mdz> that'd be nice
<mako> mdz: but we *need* a default charset and it shouldn't be iso-8859-1 
<trukulo> umm, i can't make a sid pbuilder, passwd fails
<mjt> that's what Meta charset tag is for
<mako> mdz: we can not switch it for old installations
<mako> mjt: does help me for text files
<trukulo> don't worry, i'll ask on #ubuntu
<mako> mjt: sorry.. DOESN'T
<mjt> yeah
<thom> mjt: helps not at all for packaging
<thom> mako: hrm, doing it for new installs only is relatively trivial
<mjt> but "upgrading" the content to utf8 may indeed be a problem
<mako> mdz: the parsing thing would at least not break any correct xhtml anywhere :)
<mako> thom: right, of course.. i think that's kind of the reality of the whole utf-8 everywhere upgrade
* mjt tries to imagine the "upgrade to utf8" process on his sytems... *shrug*
<mako> we're better off not daeling with our mistakes of the past
<mako> OTHER people can deal with our mistakes of the past
<sladen> mjt: okay.  UTF-8 is actually /faster/ to process than several others types of encodings.  The problem is that the current code does not assume ''only UTF-8'' encodings, which would be fast as greased cheese.  It processes everything in a hugely generic way including checking the environment hasn't changed encoding /at every single call/
<thom> mako: yeah
<mako> latin-* is totally like a venereal diesase
<ogra> hmm, greased cheese
<sladen> mjt: there are few problems.  UTF-8 is true goodness is a marmite sandwich/
<mjt> sladen: the "generic way" here isn't really the cause of slowness.  It's thwe way *how* that generic way is done
<mako> sladen: i was with you up to marmite sandwich
<thom> i think most of the world will agree with the marmite comparison
<daniels> vegemite > marmite
<thom> windows > vegemite
<daniels> warm beer < vegemite
<ogra> mako: https://www.debianshells.de/ubuntu_explode/
<sladen> ''Ubuntu goes so fast it will blow your computer apart''
<ogra> hehe
<mako> ogra: how did that happen?
<ogra> actually its too fast for me....if i wanna login at the console while the system boots i always type my pw in the middle of "starting postfix..."
<ogra> mako: no idea...someone posted this to #ubunut today
<ogra> ubuntu
<ogra> indeed
<ogra> mako: was not his, he dug it up himself as a joke...dunno where it originally comes from
<mako> it's just the live cd :)
<krix> hey
<mako> Kamion: so
<mako> Kamion: :)
<srbaker> hey everyone
<srbaker> mako, are you still the debian donation guy?
<mako> srbaker: hola! :)
<mako> srbaker: i'm one of them.. robster is much more active
<srbaker> okay.
<mako> Kamion: someone wants to put ubuntu on the front a cd by next week
<srbaker> i either need to find a home for this PA-RISC D-Class, or find a donation of some RAM, so i can set up a PA-RISC buildd
<krix> hm. anybody knows some bug in hoary with xorg and nvidia binary drivers ?
<srbaker> in fact, i was thinking of using it as an ubuntu buildd.  but i need RAM and disks
<krix> xorg cannot load the GLX module it says no such module
<srbaker> i have disks offered, but i need ram.
<krix> i heared on #ubuntu that it is a know bug and it will be fixed today 
<krix> but when? :)
<mako> lamont: you interested/know anything about such things ^^ ?
<srbaker> the ram is just too expensive for me to afford right now
<mako> Kamion: sort of next-weekish.. 
<mako> Kamion: so... how hard would it be to make a warty+security updates image?
<mako> Kamion: or do you advise against this?
<Kamion> mako: I thought Mark had decided against that
<Kamion> mako: probably not hard, I haven't looked at it because we decided not to do it :)
<mako> Kamion: right, we did
<Kamion> but I'll have a look if you like, just won't publish it anywhere particularly obvious for now
<mako> Kamion: but someone else is going to printing up a gazillian cds :)
<mako> Kamion: and they had requested that
<Kamion> ok
<Kamion> mako: warty-security and warty-updates (e.g. calendars) or just warty-security?
<mako> the updates could go, or not.. i don't think they'd notice if they weren't there :)
<mako> Kamion: i'll send an email to this guy again and cc you
<Kamion> ok, please
<mdz> Kamion: did you get the rescue mode in the installer working to your liking?
<thom> mako: DefaultCharset on rookery is UTF-8 now
<mako> thom: traffic is beautiful again :)
<mako> thom: thanks!
<fabbione> impressing...
<fabbione> the ibook go and get a nap is compiling...
<Kamion> mdz: it's tolerable; hm, I suppose I should get that in before UVF, shouldn't I?
* Kamion builds quickly
<fabbione> Kamion: i will have a few ppc kernels to test for you tomorrow.. do you think you can allocate time?
<fabbione> Kamion: it's for the ibook sleep patch..
<fabbione> before i will upload it in a couple of days or so...
<Kamion> fabbione: should be able to yeah
<fabbione> Kamion: cool. i will hook up elmo too since he bitched about them :P
<Kamion> mdz: rescue-{check,mode} uploaded and added to installer seed, but it's in Debian NEW
<lamont> sorry - fire call
<sjoerd> fabbione: if you've got a ppc sleep patch that builds against vanilla 2.6.10, could you throw it in my direction too :)
<mdz> Kamion: UVF hasn't happened yet?  elmo?
<lamont> srbaker: we can certainly get you some RAM
<fabbione> sjoerd: i have the one from benh manually rediffed on top our 3 or 4 tons of patches...
<lamont> fwiw, ia.mmjgroup.com/ubuntu/quinn-diff/list.stage[12] .hppa has the status of my bootstrapping effort.
<fabbione> sjoerd: and that one is only for ibook g4 AFAIK
<mdz> Kamion: does that mean you're waiting for them to come in from Debian?  If so, please upload directly to Ubuntu instead
<Kamion> too late, but I could upload 0.1ubuntu1 with no changes
<sjoerd> fabbione: if that's based on the one i originally send you, then it works on albooks too
<fabbione> sjoerd: check 4759
<fabbione> that's the one i have
<fabbione> and well.. it compiles on 2.6.10.. no idea if it works
<fabbione> i can't test it
<lamont> srbaker: I don't really think that debian needs another buildd right now - the one we have is idle most of the time
<fabbione> lamont: 403
<srbaker> lamont, i want to port ubuntu
<lamont> fabbione: somehow, I'm not surprised.
<fabbione> srbaker: what arch?
<srbaker> fabbione, parisc
<fabbione> ah ok
<froud> seb128, I belive you are doing the packaging?
<seb128> for ?
<lamont> srbaker: 334 pkgs from main in needs-build in stage2,  5 on stage1
<Kamion> lamont: speaking of, how come hppa hasn't built charmap.app? :)
<froud> do you package the docs
<seb128> which docs ?
<srbaker> lamont, can ubuntu use another buildd?
<thom> yes, seb does everything. we just watch and laugh
<seb128> there is plenty of doc in the archive
<froud> seb128, ubuntu
<seb128> yeah, I do the whole ubuntu
<sjoerd> fabbione: that works on albooks too.. I started rediffing it against 2.6.10 myself, but it got tiresome really fast :)
<seb128> all the other guys here are useless bot
<seb128> look at thom :p
<lamont> srbaker: well, I figure I'll have stage2 happy before weekend  at the rate it's going.  There is certainly some development work needed for a parisc port
<thom> seb128: i'll reassign my firefox bugs to you then
<fabbione> sjoerd: i have it for the ubuntu kernels. no idea if it applies on vanilla 2.6.10
<srbaker> well, i'm wanting to play with the parisc box.   i might like to help
<froud> seb128, I am writing OMF files for scrollkeeper
<seb128> thom: just reassign the gtk, people tend to like that :p
<fabbione> seb128: COOL! i can give you the kernel
<lamont> srbaker: right now, the biggest benefit from the hppa buildd I have running is that it's finding a bunch of bit-rot ftbfs's
* seb128 hides
<srbaker> i just know i have a big, heavy sonofabitch that i can't use without ram and disks.
<seb128> was a joke dudes :p
<srbaker> and i'd like to see it put to good use
<froud> seb128, need to know what category to define
<sjoerd> fabbione: could you send it this way, then we'll know fast enough :)
* seb128 doesn't want to do anything with firefox or the kernel
<seb128> froud: in fact thom did the doc-base/omf/yelp integration
<froud> seb128, <subject category="System|Other"/>
<fabbione> sjoerd: i am already building ppc kernels.. but yes.. if you want to make your ppc die faster... be my guest
<froud> OK
<froud> thom, you here
<seb128> but I can try to reply, just ask your question
<froud> do you understand OMF files
<froud> I need the value for <subject category="System|Other"/>
<thom> for what?
<froud> what category do we use
<froud> thom, ubuntu documents
<fabbione> sjoerd: people.u.c/~fabbione/ibookg4-sleep-7.dpatch
<sjoerd> fabbione: thanks :)
<thom> good grief. about what?
<froud> thom, I am writing docs and preparing scrollkeeper stuff
<froud> in OMF files
<froud> we must define <subject category="System|Other"/>
<froud> what category do we put Ubuntu User Guide, FAQ Guide, QUICK Guide
<froud> into
<lamont> srbaker: I can certainly provide a list of packages with issues, there seem to be some kernel issues that crap out the db4.3 and python2.4 builds, wrt mutexes and threading (which could well be mutexes again)
<thom> General|Linux|Ubuntu would seem reasonable, but have you read the OMF documents that describe how you choose? if you've not, please do so
<froud> thom, yes but that does mean I will be right :-)
<froud> thom, better to ask IMHO
<froud> thom, do you think we need a seriedid for each doc or one for all
<thom> no, much better to read rather than waste other people's time.
<thom> please, PLEASE read the docs
<froud> strange, I thought of a different category
<froud> thna you and read the docs
<froud> well I wont WASTE YOUR TIME. THANKS
<fabbione> ChangeSet@1.2097, 2005-01-04 21:31:38-08:00, jamagallon@able.es
<fabbione>   [PATCH]  make gconfig work with gtk-2.4
<fabbione> amen :-)
<fabbione> seb128: you were faster tho :-)
<seb128> ah ah
* lamont migrates the quinn-diff stuff to ia.mmjgroup.com/~lamont/quinn-diff
<lamont> and then cron.hourly gets run
<lamont> woot.  more packages installed in stage 2 than needs-build :-)
<Keybuk> mdz: answer to your mail is that ltmain.sh and libtool.m4 are out-of-sync most likely
<mdz> Keybuk: hmm, they're both unchanged from upstream
<fabbione> lamont: congratulation
<fabbione> and i am off for dinner
<fabbione> cya tomorrow guys
<lamont> later fabbione 
<Keybuk> mdz: grep "^TIMESTAMP" ltmain.sh && grep "serial.*LIBTOOL" *.m4
<mdz> TIMESTAMP=" (1.1220.2.94 2004/04/10 16:27:27)"
<mdz> # serial 46 AC_PROG_LIBTOOL
* lamont goes back to his strafing run of merges
<Keybuk> mdz: yeah, that looks totally off-kilter to me :p
<Keybuk> needs libtoolize, aclocal and autoconf to be run
<lamont> Kamion: because we don't likes it.
<lamont> Kamion: which is to say, dunno completely yet - I gave it back last night, but still no build love.
<mdz> Keybuk: as long as I have your ear, I have a very strange problem in the same tree, where ldd says that flac is linked with both libFLAC.so.4 and libFLAC.so.6, but there is only a NEEDED for libFLAC.so.6
<Keybuk> mdz: something deeper in the dep tree linking with .so.4 ?
* lamont beats doko with expect
<Keybuk> ldd traverses the tree, objdump doesn't
<lamont> Kamion: buildd happier now, it'll get to charmap.app sometime soonish
<mdz> Keybuk: nothing even mentions it; I grepped the entire tree
<mdz> Keybuk: it gets weirder
<Keybuk> odd
<mdz> Keybuk: if I move libFLAC.so.4 out of the way, it runs just fine
<mdz> Keybuk: and ldd quits mentioning it
<Keybuk> no LD_PRELOAD or anything?
<mdz> nope
<Keybuk> oh, hang on
<Keybuk> where's .so.4 ?
<mdz> /usr/lib
<Keybuk> ok
<Kamion> lamont: thanks
<mdz> I have v4 installed on the system and am building a new release which bumps to v6
<mdz> the flac binary was linked with a gcc command line which does not mention libFLAC.so.4 or -lFLAC anywhere; it explicitly links with the versions in the tree (via libtool)
<Keybuk> there was a libtool bug where it linked the wrong thing, are you sure it's really linking the right things?
<mdz> Kamion: what would be a good time to set up a weekly cron job to rsync the DVD image?
<Kamion> mdz: not entirely sure yet :)
<Kamion> mdz: Sunday afternoon pretty much guaranteed, though
<Kamion> (UTC)
<mdz> Keybuk: I wonder if it isn't related to the libtool weirdness
<mdz> I'l try re-libtoolizing it
<lamont> Kamion: looks like ~1hour or so (python2.3 is ahead of it)
<Kamion> lamont: ok; if it could make today's dinstall so the gnustep transition in testing can happen that would be fantastic
<lamont> Kamion: should
<mdz> elmo: what's your timeline for UpstreamVersionFreeze?
<mdz> (if it isn't done already)
<thom> mdz: can i sneak mozilla in under the wire? (it's building now) (fixes a security vuln)
<azeem> mako: is there a mailing-list I can subscribe to in order to get a text version of Ubuntu Traffic, similar to debian-news WRT DWN?
<mako> azeem: ubuntu-news
<mako> :)
<azeem> how convenient :)
<azeem> cheers
<mako> that list is undersubscribed
<ogra> mako: you dont shout loud enough.....
* ogra subscribes.....
<azeem> "You can sign up for any of the mailing lists summarized here at http://lists.ubuntu.com."
<ogra> :)
<azeem> mako: maybe you could add: "Signup for ubuntu-news to recieve Ubuntu Traffic via mail weekly"
<sjoerd> fabbione: seems you left out one function from the old patch, but otherwise the patch worked... time to reboot and kill the machine :)
<fabbione> sjoerd: what function?
<fabbione> if a function is missing gcc would complain...
<sjoerd> dfs_get_cpu_speed
<sjoerd> yeah, build failed here the first time
<fabbione> it doesn't here
<mako> azeem: good idea.. i will
<sjoerd> maybe it's in one of the other ubuntu patches then
<sjoerd> fabbione: it's a ppc only function btw
<fabbione> sjoerd: could be. i have a big fat acpi patch applied that is not upstream yet
<ogra> fabbione: dmesg log is on its way
<fabbione> ogra: thanks for the test!
<ogra> lol
<fabbione> ogra: it's not a FritZ bug...
<ogra> but ?
<fabbione> it's the mISDN core that is buggy
<ogra> ahh, thats what i thought when i saw the DEBUG stuff
<fabbione> Dive into mISDN_register
<fabbione> kobject_register failed for fcpci (-17)
<fabbione>  [<c01ad695>]  kobject_register+0x57/0x59
<fabbione> BUM
<ogra> yup
<fabbione> that Dive is calling a more general mISDN function.
<ogra> it will try to shuffle the modules around a bit....lets see
<fabbione> no i need to add more debugging stuff
<fabbione> there is no point in shuffling
<ogra> the hisax shouldnt get loaded there (which is done by default)
<mako> azeem: i added a whole paragraph about getting ubuntu traffic to traffic
<mako> azeem: email, rss, web, etc
<fabbione> sjoerd: actually powerpc isn't built yet. only power3 and 4
<ogra> fabbione: https://www.ubuntulinux.org/wiki/IsdnHowto
<mako> azeem: it will go out with the next issue.. hopefully later today
<azeem> cool
<azeem> so I need to hurry up to subscribe :)
<ogra> fabbione: it shouldnt oops, but still the wrong modules are loaded by default
<fabbione> ogra: hmmmm do you have the other modules blacklisted?
<fabbione> i think that the 2 modules can't be loaded at the same time
<fabbione> and that might cause the oops
<ogra> fabbione: nope, but also this shouldnt oops
<fabbione> ogra: it might oops if there is some kind of crappyness in both the drivers
<ogra> fabbione: it should just complain and stop loading
<fabbione> ogra: not necessarely
<ogra> true
<fabbione> i have seen really weird stuff when it goes to modules
<mvo_> fabbione: have you seen my additon to the bug? the output of your debug module?
<fabbione> like alsa and oss loaded at the same time sharing the same card
<ogra> i'll go and try....but mvo is already doing dialin tests...
<fabbione> mvo_: no thanks.. ogra's one is enough
<mvo_> fabbione: I added a new attachment to #5193
<Kamion> elmo: I'm going to need that gpgv-udeb soon; have you had a chance to look at the patch?
<fabbione> HMMM
<fabbione> ogra: i think i will need you to test another fritz module...
<ogra> k
<fabbione> mvo_: is that from what? it doesn't show the oops..
<fabbione> that one seems to load fine...
<ogra> DEBUG: AVM Fritz: err = pci_register_driver(&fcpci_driver);
<mvo_> fabbione: it may be a additonal data-point. inserting the module once gives that output (it dosn't detect the card and exits). inserting it a second time crashs the machine hard
* Treenaks kick the login "no response" bug
<fabbione> mvo_: yeah... 
<fabbione> i think i know the problem
<fabbione> and the solution
<mvo_> fabbione: cool!
<ogra> :-D
<fabbione> rm -f debian/patches/misdn.dpatch
<fabbione> whoops
<ogra> hehe
<fabbione> EWINDOW
<mvo_> :-D
<fabbione> actually..
<fabbione> most of the mISDN work is in german
<fabbione> what about you 2 germans writing to upstream?
<fabbione> and ask for info?
<fabbione> i don
<mvo_> fabbione: I can certainly do that
<fabbione> i don't get a clue of what happens on 3/4 of the mailing list
<fabbione> because it's crypto encoded in a strange way
<mdz> thom: if elmo hasn't locked it down yet, go for it
<ogra> you mean like italian ?
<sivang> anybody have an idea why my Xorg won't let the gnome resolution chooser choose more then 640x480 on the laptop? I have tried several times to dpkg-reconfigure xserver-xorg and check all the possible resolutions and nothing works..
<fabbione> ogra: like german
<fabbione> ;)
<ogra> mdz: i looked at pittis current version of hwfu....the detection stuff is easy done....how many of the interfaces have to be in place in feb ?
<ogra> fabbione: :)
<mdz> ogra: which interfaces are possible?
<fabbione> sjoerd: right.... arch/ppc/platforms/pmac_cpufreq.c:462: error: `dfs_get_cpu_speed' undeclared (first use in this function)
<fabbione> but now... I DIFFED ALL THESE FILES MANUALLY TO NOT LOSE ANYTHING
<fabbione> WTF IS WRONG
<ogra> hmm, hard to evaluate...
<sjoerd> fabbione: and it goes into suspend, but never gets out :)
<sjoerd> maybe you missed something else too...
<mdz> ogra: when you speak of interfaces, are you talking about PCI, USB, etc.?
<ogra> sivang: are you still interested in building the Web-based hardware database ?
<ogra> mdz: nope, i mean the cross references to X, hotplug etc
<fabbione> sjoerd: no. i am afraid we need to wait for benh
<sjoerd> fabbione: well it was a nice try :)
* fabbione kills the patch
<fabbione> it's not worth one day of my time
<sjoerd> fabbione: how's sparc and 2.6.10 coming :)
<fabbione> sjoerd: dunno.. haven't tested yet.. but the ffb on sparc is broken
<fabbione> i read the patch today
<fabbione> that marks it as such
<mdz> ogra: hotplug and X (discover1's X info) would be the most important
<mdz> ogra: the important part as far as the release process is to get the data collection piece into hoary
<ogra> mdz: ok, but for both i cant promise anything, but i'll do my best... :)
<mdz> ogra: with the ability to submit data from the user's system
<ogra> mdz: as i said, the data collection stuff is easy.... pitti prepared it _very_ well
<mdz> ogra: ok, as far as the freeze is concerned, we can be more flexible with the server side
<mdz> which includes the cross-referencing
<Kamion> oh, can somebody be assigned to work on making sure that everything necessary from discover1's database is in hotplug?
<mdz> because that isn't going into the distribution
<lamont> Kamion: charmap.app uploaded
<Kamion> it would be a shame if we regressed hardware support
<sjoerd> fabbione: i'm not using that, so that's not the problem
<Kamion> lamont: great, thanks!
<ogra> mdz: ah, fine :)
<mjt> hotplug does not contain a "hardware database" as discover does
<Kamion> mjt: yes, I know, but the kernel still has big lists of PCI ids and we should make sure that anything that needs to be added there is added
<mjt> hotplug uses a "database" from built from modules in current kernel
<Kamion> when I said hotplug I meant the kernel side
<mdz> Kamion: I still have the program I wrote which compares them
<ogra> Kamion: i think the hotplug side can be done with hwfu ...
<Kamion> in particular there have been some drivers during hoary so far found to be missing MODULE_DEVICE_TABLE
<mdz> there are only 145 entries which need manual examination
<Keybuk> Kamion: I would be shocked if there was missing stuff in the kernel
<Keybuk> as discover wouldn't be any use for those devices either
<Kamion> Keybuk: there has been a mere matter of months ago
<mdz> Keybuk: not all drivers support hotplug yet
<Kamion> Keybuk: nope, discover worked fine
<Keybuk> (the module wouldn't bother configuring the device)
<Kamion> Keybuk: it was sk98lin if you want to go back and look
<mjt> if a module misses pcimap for example, it will not work
<Kamion> Keybuk: worked fine, I have the hardware
<Keybuk> a PCI device?
<Kamion> yes
<Keybuk> how did the module know what device you wanted it to use when you loaded it?
<Kamion> it listed the PCI ids in the module, but didn't export them to hotplug
<mdz> Keybuk: skge didn't, until we patched it, but it's now fixed upstream
<Keybuk> oh, that's a bit odd
<mdz> it used the old method
<Keybuk> ahh, legacy driver, that kinda makes sense
<mdz> which didn't integrate with hotplug
<Keybuk> (it doesn't export to hotplug, but rather depmod)
<Kamion> it seems not entirely unlikely that there are more such drivers kicking around
<mjt> speaking of pci, there's no support for "legacy drivers" in 2.6 anymore
<Keybuk> mjt: hmm, such as?
<mjt> if a module is a driver for some pci device, it have to export module_pci_map
<Keybuk> oh, you mean the "keep up with the kernel API or loose" controversy? :-/
<mjt> or to implement half a pci subsystem internally ;)
<mdz> mjt: look at the sk98lin driver in 2.6.8.1
<mjt> driver model changed alot in 2.6
<Keybuk> kobjecty pci drivers are pretty easy to write
<mdz> Kamion: do you need to do a d-i upload to get the rescue mode stuff in?
<Kamion> mdz: yes, but there'll be plenty of d-i uploads between now and featurefreeze at least, anyway
<mdz> Kamion: just wondering if I could try it out
<Kamion> ah
<mjt> ugh, that's a large driver...
<Kamion> I'll do the d-i upload as soon as it's NEWed
<Kamion> will need bootloader tweaks too
<mdz> speaking of which, was elmo around while I was asleep?
<Kamion> at least if you want to get into rescue mode in a way that doesn't involve explicitly booting with rescue/enable=true :)
<Kamion> I haven't seen elmo since this morning UK time
<mdz> I don't suppose he mentioned anything about the freeze
<Keybuk> are we freezing?
<fabbione> Keybuk: yeah...
<Kamion> he was wrestling with udev breakage in chroots
<Kamion> Keybuk: upstream version freeze
<fabbione> Keybuk: mind to turn on the heating?
<mdz> I hope that elmo did the freeze, because I just uploaded a very broken version of flac to sid
<Keybuk> would you like mom to stop filing bugs?
<mdz> I figured we'd do it at the same time as executing the freeze, but I don't suppose it truly matters
<Keybuk> ok, just say when
<mdz> they ought to be fairly close, though
<mdz> waiting for elmo to reappear
<Keybuk> just start talking about him, that usually works
<mdz> Keybuk: I've been trying that for hours :-P
<Keybuk> but are you being insulting?
<mdz> not particularly
<Keybuk> ahh, well there you go then
<fabbione> elmo: SPARC!
<fabbione> :P
<lamont> linhwc.c:63:36: X11/extensions/xf86dga.h: No such file or directory
<lamont> linhwc.c:64:38: X11/extensions/xf86vmode.h: No such file or directory
<lamont> what F^*()^ build-dep is it missing?
<fabbione> libext-dev ?
<lamont> hrm libxext-dev is there...
<fabbione> xlibs-static-dev
<fabbione> but hell...
<fabbione> my Contents-i386 hasn't been updated since Oct..
<fabbione> wait
<fabbione> libxxf86dga-dev libxxf86vm-dev
<fabbione> lamont: these 2
<lamont> thanks
<fabbione> elmo: can you please update the Contents at least once a week please?
<fabbione> they are very useful to track build-dep
<lamont> fabbione: but they take too long... :-)
<mdz> mjg59: my laptop just shit itself when a GL screensaver activated after having resumed from swsusp
<mdz> mjg59: is that normal?
<fabbione> lamont: my sparc that is almost a doorstopper can manage the sparc archive in less than 2 minutes...
<fabbione> lamont: with all the power in the DC it should take less than that :P
* lamont heads out to the gym for a bit
<Keybuk> "Writing spam ..."
<Keybuk> ^ absolute proof that mutt is evil
* lamont grumbles at xine-lib, which Build-Depends a universe package.
* lamont really wanders off
<Kamion> hm, obviously nobody's tested today's daily CD yet ... :)
* Kamion fix0rs
<lamont> Kamion: the cute part is watching the daily build logs as it retries every half hour.
<Kamion> lamont: my comment was orthogonal :)
<lamont> ah, was wondering how xine would break the daily CD...
<Kamion> tzsetup-udeb/base-config screwed; bloody hard to test that combination :-/
<Kamion> at least before uploading
* lamont heads to town before his wife kills him
<lamont> Kamion: after the gym, I'll upload a new libpaper... will be interesting to see what that does on the daily CD when en_US is selected
<lamont> anyway, must run.  back in a couple hours or so
<mjt> "Ubuntu as an ideal Entreprise Linux solution"... wtf is that?!
<mako> mjt: its business speak
<mako> mjt: it may not actually mean anything :)
<mako> mjt: but a lot of people think it does
<mjt> oh well, business speak... ok when ;)
<jdub> elmo: ping
<mjt> is rsync:archive.ubuntu.com for official mirrors only?
<mjt> getting Packages and Sources using rsync is more efficient than http, but there's a small limit on concurrent rsyncds running on the server - much less than ftp/http
<mjg59> fabbione: http://www.codon.org.uk/~mjg59/patches/swsusp-speedup.dpatch
<mdz> seb128: any idea why I'm experiencing bug #1234 again?
<mjg59> fabbione: Plus http://www.codon.org.uk/~mjg59/patches/swsusp-platform-devices.dpatch
<mdz> fabbione: any reason to delay switching to 2.6.10 as default?
<kezz> anybody tell me if there's a public cvs for ubuntu?
<mdz> Kamion: is there an easy way to skip the first CD scan?  I'm curious as to whether it is actually pessimizing things
<jdub> kezz: we're not using version control for most of our work at this stage, public code versioning is in the package repository :)
<kezz> how bout the source?
<jdub> the package repository includes source
<jdub> source packages
<kezz> ah cool
<kezz> thanks a lot
<seb128> mdz: nop, nautilus-cd-burner has not changed for weeks. Perhaps the news dbus/hal ?
<mdz> seb128: I first noticed it happening again in early Dec
<mdz> see #1234
<mdz> it was fixed in Warty, but has regressed somehow
<seb128> oh right, I've not checked the dates
<seb128> will investigate on it
<seb128> jdub: have you read this desktop file/security issue stuff ?
<mjg59> fabbione: Ok, current state of things with respect to swsusp on PPC is that there's no sane patch
<jdub> seb128: yeah
<seb128> mdz: the patch got dropped somewhere 
<mdz> aha
<mjg59> fabbione: And benh needs to release a StR patch for 2.6.10 - his last one comes nowhere near applying
<seb128> there is no debian/patches in the package
<seb128> mdz: fixing it right now
<mdz> seb128: great, thanks
<seb128> np
<seb128> jdub: any opinion on it ?
<mdz> Kamion: your DVD image worked for me, at least up to the partitioner (which is as far as I could take it at the moment, not being prepared to wipe it again quite yet)
<mdz> (i386)
<jdub> seb128: mail sent :)
<stvn> anyone know if ubuntu supports the 'Science' application category? (from the fd.o menu-spec)
<seb128> jdub: thanks :)
<seb128> mdz: in fact the feature is in the new upstream version of ncb, that's why I dropped the patch. I've just tried here, it works fine. I've included instruction to get the debug log in the bug report, let me know if there is something useful in the log.
<mdz> seb128: ok, I'll try it again
<mdz> seb128: I followed your instructions, but did not see any debug output (the nautilus process exited immediately after opening a window)
<seb128> you need to close all the nautilus windows
<seb128> or it keeps running
<seb128> so doesn't attach in the console
<mdz> ok
<mdz> seb128: ok, it runs in the foreground now, but still no debug output
<mdz> seb128: /appse/nautilus-cd-burner/debug = true
<mdz> s/appse/apps/
<seb128> even when you launch the CD burning ?
<mdz> yes
<seb128> weird
<mdz> up to the point of the 'Disc is busy' dialog anyway
<mdz> which is as far as it can go unless I unmount it by hand
<seb128> ok, perhaps it doesn't log at this point
<seb128> it log about the iso creation and the cdrecord output
<seb128> basically mkisofs/cdrecord outputs in fact
<seb128> (looking on the code)
<seb128> sjoerd: here ?
<sjoerd> seb128: yeah
<seb128> any idea on this issue ? 
* sjoerd reads backlog
<seb128> sjoerd: nautilus-cd-burner doesn't want to umount the device before recording
<sjoerd> it uses gnome-vfs for unmounting right ?
<seb128> mdz: in hal-device-manager, for the CD, what values do you have for volume.disc.type ?
<seb128> sjoerd: correct
<seb128> cd-recorder.c -> unmount_drive () in the ncb sources
<mdz> seb128: dvd_plus_rw
<seb128> hum
<seb128> 	case CD_MEDIA_TYPE_CD:
<seb128> 	case CD_MEDIA_TYPE_DVD:
<seb128> 	case CD_MEDIA_TYPE_DVD_RAM:
<seb128> 		return FALSE;
<sjoerd> seb128: which version ? (in 2.8.6 it does the unmounting itself)
<seb128> 	case CD_MEDIA_TYPE_DVD_PLUS_RW:
<seb128> 		return TRUE;
<seb128> sjoerd: 2.8.6, I thought it was using gnomevfs, but perhaps not ...
<sjoerd> seb128: no it isn't
<seb128> oh yes
<seb128> I should add a pumount in the list
<sjoerd> right
<seb128> why is that working here ?!
<sjoerd> seb128: because your cdrom is in fstab
<sjoerd> mdz: can you umount your driver as user with umount ?
<mdz> sjoerd: no, only pumount
<seb128> ok, that's it so
<mdz> seb128: maybe you have an entry in fstab?
<seb128> mdz: yep
<mdz> ah
<sjoerd> seb128: please patch it in debian too :)
<seb128> sjoerd: I'm patching in debian and waiting for the sync :)
<sjoerd> even better ;)
<seb128> mdz: ok, bug found so, thanks
<seb128> thanks sjoerd too (I've pinged a bit fast, but speaking about an issue always help :p)
<sjoerd> seb128: np
<seb128> oh, taaz is connected
<seb128> cool :)
<amu> hmm, isnt it possible to preconfigure Xorg with a shell-script, ex. with "chroot /mnt/ Xorg -configure" this line is just ignored ?!?     
<amu> if i put a chroot /mnt/ strace -o /tmp/X.out Xorg -configure to it, also ignored. No output from strace in /tmp/
<ogra> amu: what about /mnt/tmp ?
<amu> nix 
<ogra> hmm
<ogra> amu: apt-cache show dchroot ?
<amu> ogra: hmm but i'm root  
<ogra> amu: hmm, true
<amu> ogra: what's about this, i call from the livescript, a sript in the chroot which starts the command?  
<ogra> amu: hmm, if this works, then  Xorg -configure should work too
<ogra> amu: does xorg need /proc or /sys ? i think they are not exported automatically to the chroot
<amu> i mount them before calling the command :) 
<amu> PATH is also fine ... 
<amu> ogra: a final chroot /mnt & | && Xorg -configure will also not work.
<mdz> & | && ??
<ogra> rather: chroot /mnt && Xorg -configure 
<amu> mdz: | == or 
<amu> mdz: chroot /mnt & Xorg -configure or chroot /mnt && Xorg -configure 
<mdz> | == pipe
<mdz> you want "chroot /mnt Xorg -configure"
<amu> yep 
<ogra> mdz: yep, thats the prob
<amu> mdz: the command give null output  
<ogra> amu: chroot /mnt touch /tmp/blah ?
<ogra> is the file created ?
<amu> ogra: work  
<ogra> strange
<amu> ogra: correct
<ogra> amu: you also tried Xorg with full path (even if PATH is set) ?
<amu> ogra: i've no other idea, than calling it in an other script inside the chroot. But the mainproblem is why it isnt executed.   
<ogra> amu: what did daniels say yesterday ?
<amu> ogra: yep, it's the same with or without ... another idea is i've to use '  
<ogra> amu: would have been my next guess :)
<amu> maybe chroot thinks -configure is another argument ?!? i thought i'll ask here before stupid trying :)  
<amu> ogra: and google say nothing about :( 
<mjt> works here... ;)
<bluefoxicy> http://www.netsplit.com/software/gnome-space-chart/  Ubuntu needs this the release after it goes pubilc  :P
* bluefoxicy idly says, having wanted something like this for a while. . . him and his 97% used disks which he tries desparately to trim. . .
<bluefoxicy> but anyway
<bluefoxicy> anyone know about how big Gnome itself is?
<amu> mjt: could you send me please a strace of it 
<ogra> amu: i dont think chroot thinks -configure is another argument according to the infopage
<mjt> amu: no i can't: because i've no xorg here really, only xfree86... ;)
<ogra> mjt: so how do you know it works for you ?
<amu> mjt: xfree would be also fine 
<ogra> amu: can you do it manually step by step ? (first chroot and the run Xorg ?)
<mjt> it's more than 800meg
<amu> ogra: yep that works :) 
<mjt> and the only difference between chroot and non-chroot is the chroot call itself
<ogra> amu: even with the -configure ?
<mjt> (i mounted /proc and /dev in the jail.. jfyi)
<ogra> hmm, dev
<amu> mjt: yeah a diff woould be enough 
<mjt> there's NO diff
<mjt> ie, if i do chroot strace XFree... and just strace XFree
<mjt> sure if i do strace chroot XFree.. there's an extra chroot+exec call
<mjt> there's alot of differences in timestamps and pids
<amu> ogra: yeah, i did it manually before and it works 
<amu> mjt: you run a -configure ? 
<mjt> lemme look..
<mjt> yes.
<mjt> but it failed... ;)
* mjt makes /dev/mouse symlink...
<amu> mjt: the problem isnt starting X, sorry if I did not explain myself correctly 
<jdub> thom: ping?
<mjt> now it completed successefully -- Xfree wants /dev/mouse to be here
<amu> ..oo00 
<ogra> amu: -allowMouseOpenFail
<amu> mjt: but good idea i've a new hoary chroot for myself :) i didnt checked it on my local system :)  
<mjt> good idea? wich one? ;)
<amu> both ;) 
<amu> ogra: mjt: thx ... 
<mjt> hmm
<mjt> either way, strace should not produce no output
<amu> somethimes it helps if you just tell your problem to other, meanwhile you get other ideas ;)    
<ogra> :)
<amu> mjt: right
<sensebend> thanks Ubuntu devs for the new GAIM and k3b in the hoary repo :)
<amu> mjt: ex. set an exit before the command is executed, running it by hand, so i can watch what happen, the script just die's   
* mjt can't understand what "set an exit" means... ;)
<amu> mjt: exit0 to the shell  
<mdz> Kamion: did you get my message about cdrom-detect not doing what we expected?
<mdz> Kamion: never mind, I think I'm on crack
#ubuntu-devel 2006-01-09
<mdz> doko: for example?
<doko> mdz: python-2.4.2, OOo-2.0.2, ...
<mdz> doko: it makes sense to have them on the radar, but we won't make a decision until they're actually released and we know what is entailed
<Kamion> daniels: xkb/console> no
<Kamion> doko: live CDs are produced daily
<Kamion> doko: if you're asking about Flight CD releases, you keep asking me this, but I'm sorry, no. In general I'll try to announce a few days in advance when I want to get one out.
<Kamion> if I haven't said something, I generally don't have one planned.
<doko> Kamion: ok, just still trying to find the OOo build failure on powerpc :-/
<Kamion> I still have some flight 1->2 installer regressions to fix, not to mention a giant pile of ubuntu-express code to write
<Kamion> as a rough guide, maybe near the end of next week? that's about the best I can do for you
<doko> Kamion: just wanted to know, when I have to be ready not to block others ;)
<daniels> Kamion: http://lists.alioth.debian.org/pipermail/pkg-kbd-devel/2005-September/000004.html http://lists.alioth.debian.org/pipermail/pkg-kbd-devel/2005-October/000013.html
<daniels> Kamion: i'm thinking about specing it up, because the console keymaps are shit
<jdub> "Supporting basicly dead chips is a waste of resources." <- on ubuntu-devel, *not* in that thread
<ijuz> is there an easy way to deactivate the validation of packages in the debian-installer?
<daniels> Kamion: (that would mean that the d-i keymap stuff could just pick an xkb map, and then everyone could stfu about differences in the installer and x map; the only problem would be an incorrect map)
<Seveas> ijuz, why would you EVER want that?
<ijuz> Seveas: i'm experimenting with using a different compression for the packages and therefore the md5 sums changed
<Seveas> then update the md5sum lists :)
<elmo> oh, that reminds me, I need to post about 7zip compression, it's kinda scarily good
<ijuz> hehe...
<ijuz> really good
<daniels> elmo: actually it's far from the best
<daniels> elmo: pales in comparison to dpkg v3's algorithm
<elmo> daniels: har har
<daniels> the downside is that you need flash and a jvm in the installer
<Robot101> dpkg v3? :P
<jdub> elmo: you'd pimp 7z for dapper+1?
<daniels> doogie ftw
<elmo> seriously, 7zip-ing the entire archive would save 2.3Gb _per-arch_ in breezy
<ijuz> elmo: full 7zip isn't so easy
<daniels> jdub: 7z for d+1 would require 7z support in d?
<jdub> wow
<elmo> err, actually not per-arch strictly speaking because  it includes arch: all, but still
<jdub> daniels: urgh, yeah
<elmo> and it's better than bzip2 in cpu and memory too, IIRC
<elmo> I did stats and graphs and stuff
<jdub> elmo: sshot!
<daniels> elmo: are they BLING?
<jdub> elmo: blog!
<ijuz> 7zip (only lzma) breezy install CD is: 245601 extents written (479 MB)
<daniels> elmo: i want the graph in chrome
<elmo> ijuz: why not?
<ijuz> lzma is easy, i'm just doign this
<ijuz> you first have to compile all the 7zip stuff and get it working in debian-installer
<jdub> elmo: actually, while i've got you, how doable are the firewall changes for humboldt->rookery (http)?
<ijuz> elmo: did you try the "executable" encoding?
<elmo> jdub: oh, that's find
<elmo> ijuz: I just did '7z a' :P
<elmo> jdub: fine
<ijuz> elmo: that doesn't give you all the possible benefit, so you can as well use just lzma
<jdub> elmo: doable soon without being in the dc?
<elmo> jdub: yeah, I'll do it in a bit
<jdub> thanks!
<jdub> ELMO SAVES PLANET FROM UNCOMFORTABLE DOOM-LIKE SITUATION!
<ijuz> one cool thing that brings extra benefit is that 7zip can "transcode" binaries platform specific so that they are better compressable
<daniels> jdub: starring THE ROCK as James Troup
<jdub> haw haw haw haw
<jdub> is zakame a member?
<jdub> oh, he has @ubuntu
<slomo> ijuz: how does this "transcoding" work?
<ijuz> slomo: it reorders the code somehow, i'll look it up
<slomo> ijuz: but how is it possible that the compression ratio is better when doing some magic for some platforms? or do you mean (un)compression speed on that specific platform?
<jdub> jsgotangco: ping
<jsgotangco> jdub, pong, good morning
<jdub> yo!
<jdub> jsgotangco: you're happy with your current planet subscription?
<jsgotangco> jdub, sure it seems to work unless you want me to change it
<jsgotangco> should i send you my hackergotchi?
<psusi> god I love simple fixes
<jdub> jsgotangco: url?
<psusi> spent several hours reading hundreds of lines of kernel code to finally solve the problem by adding two lines
<whiprush> jdub: pls add mpt to planet!
<jdub> whiprush: have to get a request from him, but i'll ping him about it
* whiprush nods
<ijuz> slomo: the author doesn't get specific, but says it's very fast, you have to tell the compiler the architecture for this, so no idea how it reacts to !binary files
<jsgotangco> jdub, http://69.60.114.104/planet/images/heads/jsgotangco.png
<Seveas> jsgotangco, finally :)
<ijuz> btw. debootstrap doesn't write the logfile to /target/var/log/debootstrap.log *sigh*
<jsgotangco> heh..i finally graduate from looking like a chess pawn!
<jsgotangco> (with a jdub-like beard)
<jdub> tseng: ping
<tseng> jdub: pong
<jdub> tseng: what's up with your blog?
<tseng> its gone
<jdub> ~brandon doesn't exit
<jdub> exist
<tseng> i was using my friends server
<tseng> and the guy kept getting owned over and over
<jdub> "smarter" IT solutions...
<tseng> i moved some stuff
<tseng> i havent been motivated to blog since
<jdub> got a new location?
<tseng> linode baby
<jdub> url me
<tseng> i setup typo, but theres no content
<jdub> oh
<tseng> ill write you an entry
<tseng> and find a feed
<jdub> ok, i'll update the url, and you'll reappear when planet is moved
<tseng> moved?
<robertj> I have the world's most getto hosting plan. No backup, $12.13/year with MySQL
<jdub> tseng: changing hosts
<jdub> for great justice, etc.
<tseng> oh
<tseng> i have a good idea for a post
<whiprush> jdub: kamion's last entry doesn't appear to be on planet btw.
<daniels> tseng: post about malibu and coke
<daniels> the wonder drink
<jdub> whiprush: he's never been on it :)
<whiprush> oh
<whiprush> well dang dude.
<jdub> (he actually requested it a few days ago though, so i assume his last entry is interesting)
<whiprush> yep
<daniels> p.d.o, yo
<jdub> whoa, i have't read pdo for ages
<whiprush> since I'm being a planet nazi lately, I think it would be cool if you blogged about the new X crack daniels. :)
<jsgotangco> add mjg59 for p.u.c spice!
<daniels> whiprush: what new X crack?
<daniels> it's just an extension of the old
<daniels> anyone who's been associated with ubuntu since any time after june 2004 will know exactly what's going on ;)
<daniels> i was harping on about it then, and even had packages
<whiprush> daniels: we masses want to know about this XGL tarball and how it won't even come close to making dapper. You know, so we don't get our hopes up. :p
<daniels> why would I lie to the masses?
* HiddenWolf buys daniels coffee so he can stay up late and put xgl in dapper still
<whiprush> word.
<daniels> HiddenWolf: dude, where I am at the moment, I have numerous excellent bags of single-origin beans, a grinder, and a nice espresso machine
<whiprush> daniels: I think an X update would be cool.
<daniels> this is grating quite badly against my no-caffeine policy
<HiddenWolf> daniels, :)
<whiprush> daniels: I mean, a blog entry about X, not an X update as in, software.
<daniels> whiprush: i'll try to fire one off that doesn't piss p.fd.o and p.d.o off
<daniels> heh
<jdub> whiprush: "no you can't have a pony" only ever comes after "can i have a pony", not before.
<daniels> i'm working on an x update
<daniels> jdub: PONIES FOR ALL
<HiddenWolf> jdub,can I have a pony?
<psusi> daniels, aren't you the kernel maintainer?
<tseng> psusi: erm.
<HiddenWolf> psusi, no, benc is
<psusi> ohh... he around?
<HiddenWolf> we could put x in the kernel of course. ;)
<whiprush> jdub: nah, I just want to know where the ponies lie in the field. No need to attempt at owning one ... just admire from afar or somesuch.
<tseng> jdub: http://blog.brandonhale.us/
<daniels> HiddenWolf: you laugh, but we're working on that
<psusi> I've been working on https://wiki.ubuntu.com/PacketCD and found two bugs in the kernel and patched them... one in the pktcdvd driver and one in the udf filesystem
<HiddenWolf> daniels, ehm, unk!
<tseng> daniels: i threw the malibu and coke bit in for you
<psusi> so I need to know what to do to get the patches into the next dapper kernel
<psusi> they are very small and simple
<daniels> HiddenWolf: well, the bits that need to be, anyway.  like stomping all over the PCI bus.
<daniels> psusi: file bugs
<psusi> hrm.... file a bug and attach the patch to it?
<daniels> yeah
<HiddenWolf> daniels, hm. Cool.
<whiprush> there's a kernel mailing list also
<BenC> psusi: just email them to me
<whiprush> or do what ben says. :)
<BenC> btw, when is the great bugzilla->malone conversion going to happen?
<psusi> oh?  a kernel mailing list?  hrm... I should get on that
<HiddenWolf> psusi, ubuntu-kernel list
<BenC> I'm starting to get bug reports in malone, and bug maint for the kernel is hard enough without dealing with dual bug systems
<daniels> BenC: november 2004
<psusi> what's wrong with bugzilla?  I like it
<BenC> I don't
<BenC> I hate bugzilla
<psusi> why?
<HiddenWolf> malone is cute, if they ever get the interface right.
<BenC> because it doesn't have an email gateway
* psusi likes functional better than cute
<seth_k|lappy> I demand a way to change the bug and add a comment in ONE STEP via malone, without using the e-mail interface :P
<BenC> so far debbugs is still my favorite bug system, despite its short comings
<daniels> seth_k|lappy: word to that
<BenC> seth_k|lappy: file  a bug on malone :)
<BenC> seriously, they love that stuff
<BenC> but I think we already discussed that particular problem at UBZ
<seth_k|lappy> alright. I'll grok the buglist to make sure it's already there
<psusi> ok... so... patch to benc, or ubuntu-kernel?
<BenC> bcollins@ubuntu.com
<psusi> ok
<BenC> and it's kernel-team@lists.ubuntu.com
<BenC> for future reference
<psusi> I'll have to sign up for that one...
<BenC> psusi: know anyone that has tested DVD+R DL writing?
<BenC> my new powerbook has a DL
<psusi> BenC, nope...
<HiddenWolf> BenC, I should have, on x86
<psusi> my drive supports it but I've never bothered ot get any dvd media
* HiddenWolf checks
<BenC> guess I need to get some disks and try it out
<BenC> now I can copy DVD's without losing the bonus material! :)
<infinity> BenC: I burned some dual layer DVDs on my i386 laptop just fine.
<infinity> BenC: Can't recall if it was +R or -R, though, since I have a +/- drive, and I don't pay much attention to what media I buy.
<BenC> infinity: nice
<BenC> I have a +/- driver too, but for DL, it only supports DVD+R
<jsgotangco> jdub, pia online?
<jdub> jsgotangco: not atm
<psusi> BenC, ok... bombs away... should I also mail the diff to the lkml?  or just let you review it first?
<floam> psusi: sending it to LKML, if anyone notices it, will get you some very critical feedback
<floam> they don't seem to mind hurtin feeling :)
<floam> hurting
<psusi> aye...
<psusi> well, at least it's only 6 lines of code to fix 4 bugs ;)
<psusi> can't be TOO much wrong with it right? :)
<floam> I had no idea what your patch was
<floam> , psusi 
<psusi> huh?
<floam> I had no idea what your patch was, psui
<psusi> ohh... right... fixes a few bugs with pktcdvd and udf
<floam> if it's that small it should be fine
<psusi> you don't remember how to get emacs to insert a hard tab rather than spaces to the default indent level do you?
<floam> C-q tab
<psusi> thanks
<floam> C-q is the 'quote' key; it quotes whatever you type next.
<psusi> ahhh, good to know
<BenC> anyone know why nautilus wont view my webdav folder (davs://)?
<BenC> just says try another viewer
<infinity> BenC: Kernel bug, clearly.
<BenC> so obvious, I can't believe I missed it :)
<infinity> :)
<whiprush> daniels: awake?
<daniels> whiprush: ?
<whiprush> daniels: hey how long has xorg looked at ~ for a xorg.conf?
<whiprush> I totally just wasted 45 minutes thinking my X was busted, so I've been grepping the log for EE. Turns out one of my old backup xorg.conf's in ~ was being read first.
<infinity> Is it '~', or '.' it's looking in?  I don't recall.
<elmo> oh, yeah, most annoying feature ever
<whiprush> I know that seems like expected behavior, but man, that kind of sucks.
<infinity> Anyhow, it's done it for a long while.
<whiprush> infinity: ~
<whiprush> didn't know X did such a thing.
<daniels> whiprush: yeah, that shits me off too
<whiprush> cool, as long as I'm not the only one. :)
<daniels> i'm tempted to just smash the established behaviour in favour of behaviour that makes bloody sense
<infinity> It would probably make perfect sense if it was a dotfile instead (~/.xorg.conf)
<whiprush> agreed 
<whiprush> that would at least follow a convention of sorts.
<infinity> And be less prone to blunders, and give less ~ clutter if you actually WANT a user-defined config.
<infinity> And make your hair smell nice.
<infinity> Etc.
<whiprush> heh
<dilinger> xorg gives my hair volume, bounce, and shine!
<daniels> i don't want user-defined configs
<daniels> not while it's suid
<daniels> i want the search path to be $(sysconfdir)/X11/xorg.conf, that's it
<daniels> ideally the thing wouldn't have to *exist*
<daniels> but that comes later
<whiprush> it's hard to think of a use case where a normal user account would need a specific xorg.conf
<psusi> infinity, hey... what was your real name again?  I was looking for someone the other day and can't remember who now... but someone said their nick was infinity
<infinity> psusi: That's what /whois is for. :)  (Adam Conrad)
<psusi> ahh.... hi... now why was I looking for you? hrm...
<whiprush> psusi: he's got a cool hat 
<psusi> infinity, ahh, right... I have a bug that has been pending since breezy was released for dmraid support... it's currently assigned to you for some reason, I guess because you maintain mkinitramfs
<psusi> infinity, could you glance at the attached scripts to see if they look ok, and reassign the bug to the dmraid package sometime?
<psusi> bug #15897
<infinity> Probably little need for me to glance at all.  The bug definitely belongs to dmraid.
<psusi> I think that the idea is that those packages are supposed to go into the dmraid package rather than mkinitramfs... once that's done, next task is to get the package moved to main and added to the seed I think
<psusi> s/packages/scripts
<infinity> dmraid-in-main (and in the installer, oh my) are entirely different issues, but initramfs integration would certainly be nice.
<infinity> I believe fabbione was maintaining (or fiddling with) dmraid in Ubuntu.
<psusi> aye...
<infinity> If you're looking for a scapegoat to harass and reassign your bug to. :)
<psusi> yes, please do ;)
<psusi> I understand he has such hardware, but doesn't have it working for some reason... works fine for me though and 3 or 4 others who have spoken to me
<infinity> I just bought a dmraidable controller recently, but I dunno if I'll have time to do anything fun with it.
<psusi> it sure is nice to boot directly from a raid0 between two 10,000 rpm drives ;)
<psusi> and be able to dual boot with winxp no less ( not that I ever use it any more )
<psusi> but I've been hoping for dapper to be able to install normally instead of having to debootstrap from the livecd
<psusi> though... I guess if dapper is going to have a combined install/livecd, an apt-get install dmraid is easy enough
<pitti> Good morning
<desrt> hello.
<desrt> how are you?
<Keybuk> hey desrt
<desrt> hey.  haven't heard from you in a while.
<desrt> i actually had a question you could have helped with the other day... someone was here asking about how hotplug works
<pitti> hi desrt 
<desrt> i was able to explain it all except for one point (which i told him my guess)
<desrt> does udev call modprobe with some tag like usb-id-1234-5678 and modprobe does the lookup?
<Keybuk> yes
<Keybuk> pretty much exactly like that
<desrt> that's really nice.
<Keybuk> the tag comes from the kernel and is known as a "MODALIAS"
<desrt> sweet
<desrt> udev and the kernel both get to be oblivious
<desrt> i love that :)
<Keybuk> and the lookup table comes from the modules themselves (they have alias config options, use modinfo on one) and is stored in modules.alias by depmod
<desrt> oh wow.  big file.
<Keybuk> descent scott% modinfo tg3
<Keybuk>   :
<Keybuk> alias:          pci:v000014E4d00001644sv*sd*bc*sc*i*
<Keybuk> alias:          pci:v000014E4d00001645sv*sd*bc*sc*i*
<Keybuk>   :
<Keybuk> etc.
<desrt> i assumed that it parsed all of the modules/modules.*map files each time
<Keybuk> nah, that's how we used to do it in breezy
<desrt> oh well
<desrt> this is really neat :)
<Keybuk> in breezy, the kernel provided a bunch of information about the device in various environment variables; we then had a shell script that collected those up, called grepmap to find the modules using the modules.*map files, and then loaded the modules
<Keybuk> the dapper way is MUCH easier
<desrt> indeed.
<Keybuk> ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -Q $env{MODALIAS}"
<desrt> seems like there might be some benefit to pre-parsing/caching all of the modprobe.d files and the alias map into a single quick binary format...
<Keybuk> possibly, though I expect most of the time is spent on string matching, rather than file parsing
<desrt> right.  i mean a hash or a tree of some kind
<Keybuk> that'd mean you'd need to know the format of the modalias, no?
<Keybuk> the nice thing currently is that it's just a random string
<desrt> i mean take all of the modprobe files and make a hash table (or such) of all of the aliases
<Keybuk> you can stick "alias desrt-cd-* mod_foo" in there, and modprobe desrt-cd-wibble, etc.
<desrt> oh.
<desrt> wildcards in alises?
<desrt> no thx :)
<Keybuk> right
<Keybuk> that's how they work
<desrt> oh man.  ok.  much harder problem.
<Mithrandir> nah, not really.  You can do glob trees.
<desrt> true.
<Mithrandir> it's just a state machine.
<Keybuk> the module declares something like usb:v0499p100Ed*dc*dsc*dp*ic*isc*ip*
<desrt> and it looks like for most of these aliases here the beginning part is almost unique
<Keybuk> and the device has a much longer string
<Keybuk> desrt: often the first couple of fields are vendor/device ids ... but not always
<desrt> so you could do alookup of the part before the first * real quick then do a quick-check for if it is a real match
<Mithrandir> Keybuk: does it do best-match or first-match?
<Keybuk> Mithrandir: all matches
<Mithrandir> ah, ok
<Keybuk> if a device matches multiple module aliases, all of the modules are loaded
<desrt> actually
<infinity> For better or worse.
<Keybuk> so you can get usbmouse, usbhid, usbcore, etc. for a device
<Keybuk> and evbug, which we blacklist :p
<desrt> if we were going for maximum speedup we could add modprobe/insmod functionality to udevd :)
<Mithrandir> we don't blacklist usbmouse?
<Keybuk> desrt: that would be the way to do it, have udevd parse and cache modprobe.d and modules.alias, and watch with inotify for changes
<Keybuk> pretty much like we do for rules.d
<Keybuk> Mithrandir: shush, I was examplifiying
<Mithrandir> heh
<desrt> Keybuk; i filed a bug about loading modules against alsa recently.  don't suppose that's anything you're involved with?
<Keybuk> what was your bug?
<desrt> the order in which the sound modules are loaded needs to be changed
<infinity> Ooo.
<infinity> Keybuk: This should make you happy:
<infinity> The patch creates sysfs device links for athX interfaces and changes
<infinity> the ARP type of the wifiX interface to ARPHRD_IEEE80211. This is
<infinity> needed by tools like NetworkManager or SUSE's ifup for proper
<infinity> operation, and hopefully fixes tickets #70 and #205.
<desrt> infinity; ship new fglrx!!!!
<infinity> desrt: s/new/fixed/ you mean?
<desrt> infinity; yes.  fixed would be new :)
<infinity> desrt: Working on LRM right now (hence the above quote)
<Keybuk> pitti: btw, I have a /etc/udev/rules.d/libsane.rules ... why?
<desrt> Keybuk; http://bugzilla.ubuntu.com/show_bug.cgi?id=21801
<infinity> Keybuk: Of course, that's in the madwifi-ng branch, which we've not switched to because it scares me (we're still shipping madwifi-old, cause, well, it works, and I don't have atheros hardware to test the new stuff on)
<Keybuk> infinity: I don't get what that does?
<pitti> Keybuk: oh, ouch - it should be 45-libsane.rules, right?
<Keybuk> sounds like they just fixed madwifi-ng to actually show up the card as a wifi card
<desrt> infinity; i have an atheros -and- a powerpc if you need testing on anything
<Keybuk> pitti: yes, and it shouldn't call /etc/hotplug.d/usb/libsane.hotplug, cause that doesn't exist? :p
<pitti> Keybuk: I'll ask Mithrandir about it; he did the change and he is able to test it (no scanner here)
<Keybuk> in fact, it still ships things in /etc/hotplug which it should not do
<desrt> oddly i think the atheros is in my coat pocket...
* desrt pads off to find it
<Mithrandir> Keybuk: probably because I suck, then.
<infinity> Keybuk: You were complaining that your atheros and NM didn't get along.  I'm assuming from that log message that (with madwifi-ng), they should.  <shrug>
<pitti> Mithrandir: oh, heh - I think the RUN rule can safely be removed
<Keybuk> infinity: nope, that won't fix it
<Keybuk> allegedly madwifi-ng fixes it out of the box anyway
<infinity> Ahh.
<pitti> Mithrandir: it seems to set mode and group just fine
<Keybuk> the problem is that the madwifi driver doesn't do "background scanning"
<Keybuk> if you instruct the card to scan for new networks, it has to leap off the one its on
<Keybuk> not good when n-m does a scan every 13 seconds :p
<infinity> Keybuk: Well, if I can get a good response on a call for testing, I'll happily switch to -ng.  I'm just not keen on shipping code I can't test and finding out that it's broken after we press CDs. :)
<Keybuk> infinity: give me a package and I'll test away
<Keybuk> I'm Atheros-encumbered
<Burgundavia> infinity, several of the laptop testing people of atheros, including myself
<Mez> grr - what was the command to find out which package a file belongs to 
<desrt> infinity; here's your response :p
<Keybuk> Mez: dpkg -S
<StevenK> dpkg -S
<infinity> Alright, cool.  I'll roll up -ng in the next day or two, then.
<StevenK> (Or dlocate)
<Keybuk> do they have different module names, or did they helpfully use the same ones?
* Mez gets annoyed at stupid things using qmake
<Mez> hmm
<Mez> apparently not found
<Keybuk> what's the file?
<infinity> Keybuk: Looks similar enough.
<Burgundavia> infinity, post a call on the laptop-testing mailing list
<Mithrandir> pitti: I can't really test it here, since I need a patched sane-backends, as I need the genesys backend.  I was going to fix that at some point in dapper, but ENOTIME so far.
<Keybuk> infinity: bah; if they used different, we could've shipped both and just blacklisted one :p
<Mez> Keybuk, /usr/bin/qmake
<infinity> Keybuk: I can do that anyway.  <shrug>
<StevenK> Mez: Is it a symlink into /etc/alternatives ?
<Keybuk> http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=qmake&searchmode=searchfiles&case=insensitive&version=breezy&arch=i386
<infinity> Keybuk: I already do something similarly evil with nvidia/nvidia_legacy (which are both originally "nvidia")
<Mez> StevenK, nvm- I found out I had to use dpkg -S qmake not dpkg -S /usr/bin/qmake
<infinity> Keybuk: Given the changes between the two, though, I'd rather just switch wholesale to -ng if it works for most people.
<Mez> oh wait - yes it is :D
<Burgundavia> infinity, -ng doesn't work for USB atheros devices
<infinity> Keybuk: ath_pci has never worked for EVERYONE anyway, so maintaining a smilar status quo is fine by me.
<Keybuk> infinity: yeah, gimme a package and I'll see if it works for me
<infinity> Burgundavia: The one we ship now does?
<Burgundavia> infinity, not certain, don't own one, but I imagine that is implied
<Keybuk> no, it doesn't
<Keybuk> grep usb:.*ath /lib/modules/*/modules.alias
<infinity> Burgundavia: I thought it never did, and USB was on the -ng radar.
<Keybuk> <g>
<infinity> Burgundavia: They mention is as a deficiency, not a regression.
<Burgundavia> infinity, ah, ok
<sivang> morning all
<infinity> Keybuk: After tomorrow's LRM release, I'll put up parallel LRM builds that are identical, but use -ng instead of -old, and ask for ath testing.
<sivang> woof, OO upgrade
<desrt> Seveas; ping
<sivang> yay, evolution back installable
* sivang goes back to using dapper for the office
<Keybuk> infinity: cool
<infinity> Ooo, and we get sparc64 support with -ng
<Keybuk> man, I need some of those magic tablets that kick-start your day :-/
<infinity> Which I'm sure no one will test or use.
* desrt gives Keybuk a few dozen cups of tea
<Keybuk> mmm, tea
<Mez> tea :D
<Mez> and cherry coke
<Mez> and cigarettes and mints! and hotdogs
* Mez is lisitng what he's had for breakfast
<Keybuk> heh
<Keybuk> I had coffee, orange juice, bran flakes and a banana
<sivang> the banana is the good part, it provide lots of energy to jump start the day
<lifeless> Keybuk: on a diet ?
* Amaranth had cream of wheat
<Amaranth> good stuff
<Keybuk> lifeless: no, just my usual breakfast
<Amaranth> and it would be good for me, if i didn't add 2-3 tbsp of sugar :P
<Keybuk> I find anything larger sends me to sleep, and anything less leaves me asleep :p
* infinity looks at the time and realises he needs to run off for "farewell to the family/topics" dinner.
<Mez> is there  away to find out whether theres a file in a package if I dont have the package installed on my system
<CarlFK> mez - I use http://packages.ubuntu.com
<lifeless> Keybuk: ah ;0
<Keybuk> Mez: use the web interface
<Mez> It has a search files?
<Keybuk> lifeless: and I am vaguely trying to get fit again this yeear
<Amaranth> Mez: apt-file?
<Mez> is it bad of me to be using initng ?
<Keybuk> yes, you fool
<Mez> why ? It makes my boot up time nice ;d
<Mez> and is actually working quite well
<Keybuk> because you're running scripts at the same time that are designed to follow each other
<Keybuk> mounting the root filesystem before it's been fsckd, etc.
<pitti> mjg59: sorry, I couldn't review pam_foreground yesterday any more, my head exploded (I still suffer from a cold)
<pitti> mjg59: I'm reviewing it now
<pitti> mjg59: shouldn't the package activate the module in pam somehow (conffile/postinst)? if not, where do you intend to do that?
<Keybuk> pitti: meh, could you start an audit of libsepol for me
<Keybuk> when I pointed out it wasn't needed, RH's response was to provide the missing call into it
<pitti> Keybuk: could you please create an initial report for it? QA and bug research, etc.
<pitti> Keybuk: I'll do the source review and security history research
<pitti> Keybuk: but it should be in the MainInclusionQueue so that I don't forget
<Keybuk> yeah, it's just going to block further udev uploads
<Keybuk> including the one I need to do today
<pitti> Keybuk: btw, could you make sense of that ppc hang?
<Keybuk> yes, today's upload would fix that, if it wasn't going to block on libsepol :p
<Keybuk> do you want historic CVEs?
<pitti> Keybuk: I can do that myself, but if you want do look for that, sure :)
<Keybuk> (not that there are any, but I thought I'd check)
<pitti> Keybuk: I'm just interested about how vulnerable a new package was in the past, to see how much of a burden it will be
<Keybuk> https://wiki.ubuntu.com/MainInclusionReportLibSepol
<pitti> Keybuk: are you fine with the package's quality in general?
<seb128> pitti: did you and Keybuk discussed floppy?
<pitti> Keybuk: i. e. does it do what it's supposed to, does it have many upstream bugs, an active upstream, etc.?
<seb128> pitti: any reason to have /dev/fd0 640 instead of 660? It makes gfloppy unhappy, it wants writing to format
<pitti> seb128: no?
<seb128> Keybuk said you requested that change, so to ping you about it :)
<pitti> seb128: hm, we keep plugdev devices r/o for the user, but I don't particularly mind
<Keybuk> pitti: no idea, haven't looked at it; it's part of the great selinux beast
<pitti> seb128: 0640 would be consistent to USB sticks and the like, and I quickly discussed that ages ago with mdz
<seb128> floppy group members should be allowed to format a floppy no?
<Treenaks> pitti: also when we want to format USB sticks?
<Keybuk> write access to a device allows formatting
<Treenaks> pitti: people keeps asking that too
<pitti> seb128: if we want to allow that, then we should allow plugdev members to format their usb sticks, too, IMHO
<seb128> fine with me
<pitti> with me, too
<pitti> it shuold just be consistent
<seb128> k, so please do it 660 consistant :)
<pitti> the problem with that is that it would allow users to circumvent permissions on e.g. ext2 drives
<seb128> how?
<Kamion> only if they're in the group that owns the disk device
<pitti> seb128: well, of course you can already read the whole device, so it's not a strong point
<jk_work> mjg59: Is "seamless" wireless wpa support on the agenda?
<jk_work> comments to https://bugzilla.ubuntu.com/show_bug.cgi?id=16551
<pitti> it's mainly how we want to consider usb/fw devices - entirely untrusted, or we want to enforce r/o file permissions on file systems that support them
<jk_work> point out that wpasupplicant is in universe
<crimsun> jk_work: I've already fixed that in Dapper.
<Keybuk> pitti: meh, don't worry about it actually; false alarm, was a different bug in selinux, it doesn't need libsepol
<crimsun> jk_work: it now uses ifupdown
<jk_work> nice
<pitti> Keybuk: that means you don't need the package at all, or it isn't from selinux?
<Keybuk> don't need it at all
<crimsun> I need to consider the case where there are multiple wireless interfaces, but the single case is handled already
<Keybuk> well, not yet anyway
<pitti> Keybuk: cool :)
<jk_work> crimsun: will wpa support be included in ubuntu proper, or will it remain in universe?
<crimsun> jk_work: that I don't know
<Keybuk> pitti: *shrug* if you're in plugdev, you theoretically have physical access to both disk and machine
<Keybuk> is formatting a disk a root operation?
<Treenaks> Keybuk: not for floppies
<Keybuk> Treenaks: why not?
<Keybuk> why are floppies treated differently to USB keys
<Keybuk> if I'm not root, should I be able to format a floppy?
<pitti> Keybuk: I don't understand - why does plugdev membership imply physical access?
<Keybuk> pitti: because it's the access you give people so they can plug things in? :p
<Keybuk> if they don't need to plug it in, they don't need plugdev
<pitti> Keybuk: if you use an USB drive on e. g. a kiosk system, then the user can't write onto the raw disk
<pitti> Keybuk: ok, true
<Keybuk> I wouldn't give the user plugdev to solve that, they don't need to write to the raw disk
<Kamion> pitti: has anyone asked you to look at notify-daemon?
<pitti> Keybuk: such things are corner cases anyway, and as I wrote above, I'd be fine with 066
<Keybuk> 660 you mean? :p
<Kamion> pitti: I'm not certain whether it needs an inclusion report or not; it's a next-generation version of notification-daemon, but I'm not sure whether it's a continuation of the cdebase
<pitti> Keybuk: I'm in a mirror mood today
<Kamion> codebase
<Keybuk> pitti: ok, 660 it is
<pitti> Kamion: it's just a renaming, I'm fine with it
<Kamion> ok, promoted
<pitti> thanks
<Kamion> that should make ubuntu-desktop happier, and thus the live CD etc.
<mvo> Kamion: thanks a lot! I wanted to edit the seeds yesterday but didn't managed to
<mvo> (timewise)
<sivang> guten morgan dholbach :)
<dholbach> hello everybody
<dholbach> Guten Morgen, Sivan! :)
<pitti> mjg59: I reviewed pam_foreground.c; I found a few small issues, I wrote them down on the report page
<mvo> hello dholbach 
<dholbach> hellas mvo
<Keybuk> yay, found a good name for today's udev \o/
* pitti looks forward to reading the changelog
<mvo> Keybuk: is it "guten morgen dholbach" :P ?
<Keybuk> mvo: that wouldn't fit the naming scheme
<pitti> Keybuk: btw, do you know which package is responsible for the lack of automatic ifup/ifdown invocation?
<Keybuk> pitti: the "keybuk" package
* pitti files a grave bug against Keybuk
<Keybuk> I haven't written any new code for that yet, might actually tackle it this afternoon
<Keybuk> there's plenty of dup bugs about it already
<pitti> 'Keybuk does not type 'ifdown wlan0' for me any more if I pull out my USB wireless'
* pitti hands Keybuk some chocolate cookies to bribe him to do that again
<pitti> Keybuk: actually, I always need to go over to my gf (who sits at my laptop) whenever she needs the wireless :)
<hunger> Is it possible not to compress all those X manpages that contain only ".so man3x/something"? They actually grow when compressed.
<hunger> By the may: They point to non-existing files. The stuff moved to man3/something.
<Kamion> hunger: it doesn't matter that they grow because they'll still be less than one filesystem block
<Kamion> but you could file a wishlist bug against debhelper on bugs.debian.org asking for dh_compress to skip them, I guess; joeyh might do that
<hunger> Kamion: I think it does in reiserfs... but that is a good point:-)
<Keybuk> where the buggery-bollocks does selinux matchpathcon_init_prefix come from?!
<hunger> Kamion: The wrong path is rather annoying though... I get mails complaining about that each night.
<Kamion> sure
<Keybuk> hmm
<Keybuk> is there any particular reason that we're behind Debian on libselinux versions?
<Keybuk> we have 1.26-1, Debian has 1.28-1
<Keybuk> 1.28-2 in fact
<Kamion> libselinux |     1.28-1 |        dapper | source
<mdke> jdub, another suggestion for Ubuntu planet: give the links a different css, atm they are hidden
<Kamion> it will have failed to build due to libsepol not being in main
<pitti> so we do need it after all
<maswan> Heh. About half the boottime for my flight-2 test seems to be waiting for modprobe.
<Keybuk> yup, seems we do need it after all
<Kamion> dunno why we haven't synced libselinux 1.28-2 yet though; it was uploaded on 1 Jan
<Keybuk> dunno either, changelogs.debian.net doesn't see it either
<ajmitch> it's not still in NEW, is it?
<ajmitch> due to python bindings being added
<Kamion> ajmitch: no
<Keybuk> looks like it escaped NEW yesterday
* hunger is off reporting bugs about man pages.
<Kamion> ajmitch: oh, it could have been in Debian NEW for a while, ok
<hunger> I'd report way more bugs if I wasn't so confused by malone all the time!
<hunger> "Report a bug" gets   you to several different pages depending on where you were when clicking it:-(
<hunger> How can I find out the source package for some package installed/
<crimsun> apt-cache showsrc, or apt-cache madison, etc.
<pitti> slomo_: ping
<hunger> crimsun: thanks!
* hunger thinks that malone should be able to figure out the source package itself when given a packagename.
<pitti> seb128: do you know how/where I can reach lennart on IRC?
<seb128> nop
<janimo> crimsun, you were saying something about changing xfce4-terminal name in the desktop file?
<janimo> right now it is xfce4-terminal not Terminal
<crimsun> janimo: Exec=xfce4-terminal?
<Seveas> desrt, pong
<janimo> crimsun, lemme see
<janimo> yes not it is xfce4-terminal
<janimo> now it is
<crimsun> janimo: ok, that's good. Thanks.
<janimo> same in debian upstream
<janimo> great
<slomo_> pitti: pong
<pitti> slomo_: nevermind, sorry
<slomo_> pitti: you can reach lennart in #avahi (here on freenode) as mezcalero
<pitti> ah, thanks
<pappan> hi BenC
<Kamion> BenC: 2.6.15-11 NEWed
<pitti> slomo_: ok, I found a small potential issue in avahi, I contacted lennart
<pitti> slomo_: but otherwise the package seems fine now
<slomo_> pitti: cool, thanks :)
<koke> there is a problem with releases.u.c
<pitti> slomo_, seb128: avahi approved, please germinate it
<koke> http://releases.ubuntu.com/kubuntu/5.10/kubuntu-5.10-install-powerpc.iso gives me "Banned extension: .iso  "
<slomo_> pitti: germinate?
<pitti> slomo_: seed, or make it a dependency of a main package
<koke> ups, sorry it's my company firewall
<seb128> pitti: thanks :)
<seb128> I'll rebuild gnomevfs with it
<slomo_> pitti: ah ok
<seb128> but some binaries probably probably need to be seeded
<seb128> like the server part
<pitti> right, avahi-daemon, etc.
<seb128> apps will only Depends on the libs no?
<pitti> pelase don't seed libs
<seb128> don't worry
<seb128> slomo_: could you make a list of what could use avahi and what need to be promoted out of the libs which will be triggered by Depends automatically? :)
<pitti> seb128: do you know librsvg a bit? can we build it against firefox-dev?
<seb128> a bit. No pb to build against firefox afaik, I've a version update planned, I change that in the same time
<seb128> s/I change/I'll change
<pitti> cool, thanks
<seb128> np
<seb128> BTW is anybody working on eclipse?
<seb128>   libswt3.1-gtk-java: Depends: mozilla-browser (>= 2:1.7.0) but it is not going to be installed
<seb128> some users asked if anybody is working on that :)
<slomo_> seb128: sure, i'll make a list... and afaik only avahi-daemon needs to be promoted... libavahi-{core,common,client,glib,qt} will be pulled in as dependencies... and maybe we want avahi-utils / avahi-discover seeded but it's not needed...
<pitti> seb128: to settle this finally, shall I try to build evo and e-d-s against libdb4.3 and check whether everything still works? (I strongly think it will, but it shoudl be tested)
<pitti> seb128: or do you plan to merge with Debian anyway?
<hunger> OK, bugs about all my mandb warnings (several X debs, perl, evo) are reported in malone.
<seb128> pitti: no plan to merge with Debian, I wanted to speak with lool about that first, but if you want to give it a try you are welcome :)
<pitti> seb128: there are no transaction logs in my ~/.evolution, just .db files; i. e. it seems that evo uses in-memory transactions only, which is fine
<pitti> seb128: oh, evo b-deps gstreamer0.8 *sigh*
<Mithrandir> elmo: please sync apr1.0 and apr-util1.0 from unstable, they aren't in Ubuntu yet, afaik.
<hunger> pitti: May I nag you about my malone bugs #563, #6216 and #6257? (first is my cryptsetup init script, the latter two oneliners to pam_mount to deal with LUKS volumes more sanely).
<pitti> hunger: nag yes, but I'm afraid I won't really have time to deal with this stuff
<pitti> hunger: if they are assigned to me, then I won't forget at least :)
<hunger> pitti: Is there anything I can do to help with these issues?
<slomo_> seb128: it's only rhythmbox, gnomemeeting (in cvs), a patch for vino exists, gnome-games afaik in cvs too... no idea about kde stuff
<hunger> pitti: Like send a patched deb or anything?
<pitti> hunger: oh, if there are properly tested patches, I'll take a look :)
<pitti> hunger: no, a debdiff or normal patch is fine; no debs please :)
<seb128> pitti: that's for a stupid plugin, the Build-Depends will not stay for dapper don't worry
<seb128> slomo_: k, I'll build gnomevfs with it
<seb128> slomo_: rhythmbox/gst0.10 daap code doesn't work fine atm
<hunger> pitti: One is a init-script I use since way before breezy, the others are not really patches but one-line changes to mount.crypt.
<pitti> Riddell: is it possible to build libakokde-dev without jack? it's the only package that wants jack in main again
<slomo_> seb128: ok, fine :)
<tepsipakki> kamion: grub-install fails on daily dapper-netboot
<pitti> Keybuk, Kamion: libsepol approved
<seb128> infinity, lamont-away: could you give a retry to evolution-exchange build?
<Kamion> Keybuk: any bzr branch for your pcmciautils, or shall I merge it by hand?
<Kamion> pitti: and promoted (apart from sepol-utils, unless we actually need that)
<Kamion> tepsipakki: fails how?
<tepsipakki> kamion: hmm, because there's unmet dependencies.. so not really grub-installers fault?-)
<tepsipakki> kamion: lang-support-en can't be installed so this fails
<Kamion> tepsipakki: oh, ubuntu-desktop's just uninstallable at the moment *shrug*
<tepsipakki> yes
<Kamion> the single-stage installer causes this to show up at a different point from where it used to
<Kamion> though I'm surprised you didn't get a failure in pkgsel
<tepsipakki> where can I edit the seed? is it preseedable?
<zyga> morning folks
<ijuz> are the udeb's not unpacked by udpkg?
<sivang> mornign zyga 
<Riddell> pitti: done
<pitti> Riddell: thank you
<Nafallo> mjg59: ping
<pitti> Keybuk: heh, so you liked the movie 'Chicago', too? :)
<maswan> Keybuk: hmm.. wouldn't it be interesting with a bootchart:y thingie from login to default desktop ready?
<martink> doko: any idea what went wrong with openoffice.org2-l10n?
<mjg59> pitti: PAM configuration is through conffiles. One package shouldn't fuck with the ones produced by another package.
<mjg59> pitti: So integration needs cooperation with libpam - see my mail to ubuntu-devel
<mjg59> jk_work: With luck
<mjg59> Nafallo: Hi
<pitti> mjg59: ah, so you'll modify pam proper to use the new module?
<pitti> ok
<mjg59> pitti: Thanks for the comments - I'll fix and reupload
<Nafallo> mjg59: hi! :-), I found something strange that I don't know if it's known... after hibernate/wakeup my brightness up and down keys works as both up and down (i.e. I press on it to its at max, then it goes to minimum and then back up to max etc).
<mjg59> Nafallo: Hmm. Weird.
<Nafallo> agreed ;-)
<mjg59> Nafallo: Just the once, or always after wakeup?
<Nafallo> reproducible aswell, only after wakeup.
<mjg59> Sorry, I meant - once you've woken up, does it happen once and then start working properly?
<Nafallo> hmm, works now
<Nafallo> strange
<mjg59> What sort of hardware?
<Nafallo> http://www.magicalforest.se/darkelf/
<Nafallo> ehm
<Kamion> ijuz: mostly they're unpacked by udpkg, yes, apart from those in the initrd which are unpacked by dpkg on the build system
<Nafallo> it's back
<lucas> hi
<Nafallo> mjg59: stranger yet... it worked when you asked me to test and now (few seconds after) it's reproducible again :-P
<lucas> while trying to edit on the wiki: "/!\The authentication database is temporarily unavailable. Anonymous access only.
<lucas> You are not allowed to edit this page."
<Nafallo> mjg59: any idea what I can do to debug this? :-)
<mjg59> Nafallo: Haha. Afraid not right now.
<mjg59> I'll think about it
<Kamion> lucas: the key word being "temporarily", indicating that you should do something else for a while during maintenance
<lucas> ok, just wanting to make sure you were aware of it
<Kamion> lucas: when you see that machine, it means that an admin is working on the machine, and therefore they're already aware of it unless they're sleepadmining
<mdke> actually I'm not sure it is intentional, authentication is working on launchpad, but not on the wiki
<mdke> was there an announce about it?
<lucas> Kamion: note that the message doesn't say that the admins are working on it
<Nafallo> mjg59: weirdest.bug.ever! I'll try to reboot :-P
<pappan> Kamion: hi
<pappan> Kamion: hi
<maswan> dholbach: Should it be solved? I'm not sure I feel motivated enough to install flight-2 and upgrade it just to check that.
<Kamion> pappan: hello?
<dholbach> maswan: yes, i think it is - i thought you had an installation, where you could check, at hand
<dholbach> maswan: nevermind, if you don't
<maswan> dholbach: No, we played around a bit and I submitted a bunch of bugs I found, but now we have a FAI-installed breezy with a bunch of modifications and custom kernel
<dholbach> right
<dholbach> i'll keep the bug open and see if people still have that bug
<maswan> dholbach: thanks. my collegue is still on vacation, so if it is important I could reinstall his workstation this week. :)
<dholbach> nono, don't bother :)
<maswan> dholbach: We mostly ran and tested flight-2 since that was the first distribution we found that installed on these machines, rather new sata chipset or something like that.
<Lathiat> sata_sil24?
<Lathiat> or another new one?
<maswan> Lathiat:  [SiS]  5513 IDE chipset with some sata stuff, or something like that.
<Lathiat> ah ok
<maswan> Fujitsu-Siemens shipped it with a fedora core 4 dvd that didn't find a disk to install onto either. :)
<Lathiat> haha
<maswan> Since we asked for no windows
<HiddenWolf> hah, you're kidding?
<highvoltage> it would be nice if they sent an ubuntu dvd.
<maswan> well, they don't actually support linux, so nothing preinstalled
<maswan> highvoltage: well, suggesting them to bunlde flight-2 is kind of icky too
<maswan> and support for the ide/sata stuff came with 2.6.15
<highvoltage> maswan: better than fedora core :)
<maswan> highvoltage: :)
<maswan> Actually, I think you could tinker aroudn in bios and make it hide as an ide drive that you could install on
<maswan> but then you couldn't access the cd/dvd-drive
<highvoltage> yep, enable ide emulation in bios.
<highvoltage> you should just emulate as another controller.
<highvoltage> if you emulate your sata disks as hda and hdb, and your cdrom is on hda, then it wont work.
<highvoltage> so you can just emulate your hard disks as a second or third controller, instead.
<maswan> highvoltage: well, I didn't try it personally, just that it didn't work
<Pygi> not that I haven't mentioned this for like 10 times (and no one replied :P) But I'll try once more :)
<Pygi> Keyboard layout changing does NOT work :/
<HiddenWolf> Pygi, if a bug is filed it'll be fixed.
<Pygi> HiddenWolf: not sure if there's bug
<Pygi> reported
<HiddenWolf> then report one.
* Nafallo screams at his VERY random brightness up/down keys!
<dholbach> there are bugs reported on it, it depends on what your issue is EXACTLY, please try to follow up on existing ones, if they match your problem
<HiddenWolf> developers like bugs, so they can keep track of things, unlike things reported on irc.
<Pygi> dholbach: k, I'll track the following bugs
<Pygi> reported
<dholbach> thanks
<mdke> seb128, evolution-exchange is blocking ubuntu-desktop, is this known?
<seb128> yep
<Nafallo> dep-wait: builddadmin :-)
<seb128> you can assume than un-installability on dapper for desktop are always know
<seb128> no need to have a zillion on people pinging me by mail/bugzilla/IRC every time a soname change, thanks
<seb128> :)
<Nafallo> :-)
<mdke> seb128, sorry
<seb128> np, I know that people doesn't want to bother, but I've to reply to mails about that, saying the same things and different chans and to close some bugzilla bug already today
<seb128> men, that's an unstable distro, stuff move, few a couple of hours :)
<mdke> i should have looked on bugzilla
<seb128> s/few/wait
<mdke> i did wait 24 hours first tho ;) problem with searching bugzilla is that usually only open bugs come up, i guess
<seb128> yep
<mdke> anyway, i'll assume that uninstallability is known from now on
<jdub> seb128: dude, you or dhbuild noticed that evo exchange is blocking u-d today?
<mdke> lol
* seb128 slaps jdub
<jdub> ;-)
* jdub hugs seb128 
* seb128 hugs jdub
<Nafallo> :-)
<dholbach> . o O { it must be REAL love }
<seb128> mdke: in fact evolution-exchange waits for buildd admin to retry the build, nothing we can do about it
* jdub fears cool Keybuk-crack uploads!
<Nafallo> jdub: I rebooted with them :-)
<jdub> Nafallo: you obviously survived. did your laptop?
<Nafallo> yepp :-)
<jdub> lucky ;)
<Nafallo> hehe
<Nafallo> new kernel aswell :-P
<Nafallo> and gdm ;-)
<Nafallo> risky today :-)
<doko> martink: no idea, it builds fine, when I build it by hand
<jsgotangco> its pretty sweet
<ijuz> Kamion: i wondered if there is something else than udpkg, one of my problems is that anna complains about wrong md5sum despite i have updated the Packages file
<Kamion> ijuz: well anna's at a different layer from udpkg ...
<Kamion> ijuz: perhaps you forgot to update Release with the new md5sum/sha1sum/size of Packages
<ijuz> Kamion: what programm does generate the Release file? manually is a bit annoying
<tseng> ijuz: man apt-ftparchive
<ijuz> tseng: thank you
<raphink> dpkg-scanpackages and dpkg-scansources
<raphink> ijuz: 
<raphink> you can use that too
<raphink> dpkg-scanpackages /dev/null ./ | gzip -9 > Packages.gz
<raphink> and same with sources
<raphink> for small repos ;)
<tseng> (he said release)
<raphink> oh sorry
<Keybuk> Kamion: it was such a trivial change that I figured it'd be easier for you to just take it by hand
<Keybuk> pitti: heh, isn't the movie so much ... they're all lyrics from broadway/west end musicals
<Keybuk> maswan: it'd be interesting to seb128, I guess, and easy to do; just put bootchart into the Xsession ... though you'd need a "stop" point for it
<Keybuk> jdub: if it makes you feel better, I've been booting with them for weeks
<Kamion> Keybuk: fair enough, already done
<Keybuk> Kamion: I couldn't remember off the top of my head where your bzr branch for it was
<Keybuk> one day, I suspect, launchpad will tell me :p
<ijuz> does somebody know if bzip2 support in dpkg/apt really works?
<Keybuk> ijuz: yes
<Keybuk> we've been using it since hoary
<ijuz> Keybuk: for Package files, but not for the deb packages themselfes
<Keybuk> bzzzt!  wrong!  but you can try to double-your-money in the ready-money-round
<ijuz> uhm, i decompressed all data.tar.gz from breezy with gzip, that was something like an indicator for me that they are compressed with gz ;)
<Keybuk> *sigh* you so should have asked for the RETURN ticket from wrongland :)
<Keybuk> descent scott% apt-cache policy language-pack-en
<Keybuk>  *** 20051011 0
<Keybuk>         500 http://archive.ubuntu.com breezy/main Packages
<Keybuk> descent scott% aptitude download language-pack-en
<Keybuk> descent scott% ar tf language-pack-en_20051011_all.deb
<Keybuk> debian-binary
<Keybuk> control.tar.gz
<Keybuk> data.tar.bz2
<Keybuk> *gasp*
<Keybuk> bz2 ... well I never
<Keybuk> :D
<ijuz> odd
<ijuz> but on the CD they are with .gz
<Kamion> no, they aren't
<Kamion> the CD takes packages verbatim from the archive; it doesn't recompress anything
<maswan> seb128: so, do you want to do desktop bootcharting? in our experience, default desktop startup is almost as bad as bootup times
<Keybuk> it's just really not your day, is it? :)
<Keybuk> descent scott% cat /media/cdrom0/README.diskdefines
<Keybuk> #define DISKNAME  Ubuntu 5.10 "Breezy Badger" - Release i386
<Keybuk> descent scott% ar tf /media/cdrom0/pool/main/l/language-pack-en/language-pack-en_20051011_all.deb
<Keybuk> debian-binary
<Keybuk> control.tar.gz
<Keybuk> data.tar.bz2
<ijuz> 126751a2dc5528c2f9044d9e4ee36d61  ubuntu-5.10-install-i386.iso
<ijuz> is that the right one?
<ijuz> well, i have it from cdimage.ubuntulinux.org
<Keybuk> Kamion: uh, where are the breezy CDs? :)  they're not on cdimage
<Kamion> releases.u.c
<Keybuk> duh, silly me
<Keybuk> 126751a2dc5528c2f9044d9e4ee36d61  ubuntu-5.10-install-i386.iso
<Keybuk> ijuz: yup, same CD I have
<ijuz> ar tf /media/cdrom0/pool/main/g/gcc-4.0/gcc-4.0-base_4.0.1-4ubuntu9_i386.deb
<ijuz> debian-binary
<ijuz> control.tar.gz
<ijuz> data.tar.gz
<ijuz> most stuff is still gz
<Keybuk> yes, that's nice
<ijuz> BUT, that's excellent
<Keybuk> that's because most stuff compresses better with gz
<Kamion> cjwatson@little:~/cdimage/www/simple/breezy$ isoinfo -R -i ubuntu-5.10-install-i386.iso -x /pool/main/l/language-pack-en/language-pack-en_20051011_all.deb > ~/language-pack-en_20051011_all.deb
<Keybuk> look at the package I showed you
<Kamion> cjwatson@little:~/cdimage/www/simple/breezy$ ar tf ~/language-pack-en_20051011_all.deb
<ijuz> that means even more soace saving
<Kamion> debian-binary
<Kamion> that's on the master cdimage system
<Kamion> control.tar.gz
<Kamion> data.tar.bz2
<ijuz> s/soace/space
<Keybuk> we hand-picked which debs are bz2-compressed
<Keybuk> because for most of them, there's no point
<seb128> maswan: "our" beeing? Sure it would be nice but I'm probably too busy to do that myself atm, but if you want to work on it you are welcome
<seb128> maswan: dapper should be better regarding to desktop startup time, we changed quite a bunch of stuff (xrdb call, merged gconf, delay the startup of some stuff to after the login, etc)
<Keybuk> descent scott% /bin/ls --block-size=4096 -ls gcc*
<maswan> seb128: Well, just me and my collegue, spending time watching the startup time of various gnomey stuff after login before you get a usable desktop in flight-2
<Keybuk> 44 -rw-r--r--  1 scott scott 44 2005-10-01 15:20 gcc-4.0-base_4.0.1-4ubuntu9_i386.deb
<Keybuk> 44 -rw-r--r--  1 scott scott 44 2006-01-04 14:32 gcc-4.0-base_4.0.1-4ubuntu9_i386.deb-bz
<Keybuk> ijuz: on most modern filesystems, those two files are the same size with gzip and bzip2 -- and bzip2 is significantly slower and more resource hungry
<ijuz> there is no size
<Keybuk> ijuz: the "44" bit
<HiddenWolf> maswan, to be expected, some of what was done before login is now done after.
<ijuz> Keybuk: what unit is that?
<Keybuk> ijuz: when talking about archive or cd space saving, it's only useful to talk in terms of number of filesystem blocks
<Keybuk> ijuz: filesystem blocks
<ijuz> the base package is a bad example
<ijuz> -r--r--r--  4 root root 5106876 2005-10-01 16:20 /cdrom/pool/main/g/gcc-4.0/libgcj6_4.0.1-4ubuntu9_i386.deb
<ijuz> -rwxr-xr-x  1 ijuz ijuz 3644880 2006-01-03 21:38 libgcj6_4.0.1-4ubuntu9_i386.deb
<ijuz> bytes
<ijuz> bytes or blocks are the same in the end
<maswan> HiddenWolf: Ok. Well, I don't care that strongly about it. We ended up not running the default desktop session anyway.
<Keybuk> ijuz: dude, if you really think that, you need to stop this discussion now
<ijuz> over n files it's the same
<Keybuk> no its not
<Kamion> it's the same on a CD image, but not in the archive
<ijuz> ok, i take back "bytes or blocks are the same in the end"
<Keybuk> ijuz: I contest your size finding for that file ...
<Keybuk> 4988 -rw-r--r--  1 scott scott 5106876 2005-10-01 15:20 libgcj6_4.0.1-4ubuntu9_i386.deb
<Keybuk> 4924 -rw-r--r--  1 scott scott 5040668 2006-01-04 14:40 libgcj6_4.0.1-4ubuntu9_i386.deb-bz
<Keybuk> barely any difference
<ijuz> for bzip2, maybe
<Keybuk> where did you get your 3.4MB figure from?
<Kamion> I think he's using 7zip or lzma or something
<Kamion> and that this discussion is extremely confusing
<ijuz> Kamion: yes, lzma
<Keybuk> ijuz: we weren't discussing lzma, we were discussing bzip2
<Keybuk> dpkg doesn't (currently) support lzma
<ijuz> my dpkg does :)
<Keybuk> I have the patches to do it here too
<ijuz> i wondered about bzip2 because the question is if the cases in the different apt parts are working for bzip2
<Keybuk> apt and dpkg are different things
<Keybuk> apt only concerns itself with Packages files and the like
<Keybuk> (well, except for the ftp archive bits, but in general that's true)
<ijuz> well, apt-extracttemplate or something
<Kamion> apt-extracttemplates only cares about the control.tar.gz member, not the data member
<Keybuk> ah yes, of course
<ijuz> you are right
<ijuz> it outputs only a warning
<Kamion> the only thing in apt I can see that cares about the data member is apt-ftparchive's contents generation
<ijuz> i'm a bit confused today, sorry
<Kamion> there's a .deb extractor in apt-inst but as far as I can see it's unused by apt itself, although it might be used by other users of libapt
<Keybuk> jennifer, maybe
<Kamion> yes
<mvo> python-apt proivdes some additional support for the data extraction
<Diziet> dholbach: I wanted to talk to you briefly about your change to ffox's debian/rules.  Your comment says `commented out, broke on everything but i386'.  Can you say in what way ?
<ijuz> i just wondered about lzma in ubuntu because space should be soon a contraint with the same package set for 1 CD
<Keybuk> ijuz: we've briefly looked into it, it needs a thorough investigation though
<Keybuk> in particular, how much space is gained broken down into package groups
<Keybuk> difference in resources (cpu, memory, time, etc.) to unpack and pack
<Keybuk> etc.
<Keybuk> for dapper we still have wiggle-room on the CD, though
<Keybuk> there's still some WinFOSS and language-packs that can be tossed :p
<dholbach> Diziet: it didn't build, let me try to find the buildlog
<Mithrandir> ijuz: I'm working on squashfs, possibly with lzma for the live cd.  It saves quite a bit, but needs unionfs, which is problematic on ppc
<ijuz> uhm, i did that 1 year ago for knoppix
<Mithrandir> ijuz: there aren't any debian packages of mksquasfs-lzma that I could find at least.  Anyway, it's not something we just jump at, we need to investigate it a bit
<ijuz> for a live-cd it is a slightly speed problem on slow boxes
<dholbach> Diziet: http://people.ubuntu.com/~lamont/buildLogs/f/firefox/1.4.99+1.5rc3.dfsg-1ubuntu6/
<dholbach> Diziet: it only built on i386
<ijuz> Mithrandir: but i don't get the unionfs requierement
<Mithrandir> ijuz: oh?  How else would you make the CD writeable?
<Mithrandir> ijuz: you can do apt-get install $whatever on the ubuntu live cd.
<Mithrandir> +s
<seb128> Diziet: I did change the -X"*nspr*" to -Xnspr (same for some other stuff than nspr too), I think I mentionned the change on a malone bug
<ijuz> Mithrandir: sure, but don't you need that too for what you are using now?
<Kamion> ijuz: no, with cloop you can use device-mapper snapshots
<Mithrandir> ijuz: no, devmapper with a writable snapshot doesn't need it.
<Kamion> but they don't work with squashfs because squashfs is a fundamentally read-only fs
<ijuz> oh, didn't know this
<Mithrandir> ijuz: so our current live cd is ext2+cloop with devmapper writable snapshots, while squashfs would be squashfs+unionfs
<ijuz> yes, sure, have you allready tried using squashfs?
<Mithrandir> ijuz: yes, non-lzma.
<ijuz> i think one of the problems is that squashfs still has no metadata about the used compressor
<ijuz> Mithrandir: 2.2r2?
<Mithrandir> yes
<elmo> mmk, so I installed a laptop without network, have no put a wireless PCMCIA card in, but gnome refuses to see it in the panel - how do I beat some sense into it?
<elmo> s/no/now/
<mvo> Kamion: ok if I change notification-daemon -> notify-daemon in the desktop seed?
<Kamion> mvo: yes
<Diziet> dholbash: Yes, but why did what you do fix it ?
<jdub> elmo: add the network status applet? switch the network interface in the status applet prefs?
<Diziet> Err, I mean:
<Diziet> dholbach: Yes, but why did what you did fix it ?
<dholbach> Diziet: that's a very good question
<dholbach> Diziet: i'm afraid, I have no answer :-(
<Diziet> I'm talking about the one where you unwrapped the seddery.
<dholbach> Yeah, i don't know. It was a matter of trial and failure. :(
<Diziet> You didn't _change_ the seddery, did you ?  You just removed various instances of   tab tab \ lf tab tab  .
<Diziet> It's a bit hard to tell because of the formatting change :-).
<Diziet> I should thank you from clearing up my mess, though, so thanks.
<dholbach> No problem, I always hoped I didn't produce more mess. :-)
<Diziet> Do non-i386's have different /bin/sh, or different make ?
<Diziet> I know this seems optimistic, but I want to understand it so that I can fix the root cause (whether that's in my head or somewhere else ...)
<Kamion> make had a related change recently
<Kamion> I think it may have been reverted, but can't remember exactly; check the recent changelogs
<Kamion> I know Joey had to make a similar unwrapping change in debconf (in fact I think he moved the seddery complete with backslash-newlines into a define)
<Diziet> Joy.
<Diziet> And that fixed it ?
<Kamion> yes
<Diziet> Cripes.
<Kamion> perhaps i386 built firefox with a different version of make due to timing
<Kamion> the top of the build log should say
<Diziet> I think I'll try a test build with dholbach's change reverted and see.
<psusi> does this lzma squashfs use a larger block size than the normal squashfs?  imho, using a larger block size has far more impact on compression than lz vs lzma
<Kamion> bah, no, the build log doesn't list that
<Kamion> lamont-away: it'd be nice if make were listed among "Toolchain package versions"
<Diziet> Lots of the stuff in make is completely crackheaded.   Recently I discovered that  $(shell $(variable))  after  define variable  splits variable up by newlines into separate arguments and appends that argument list to  sh -c  .
<psusi> iirc, squashfs defaults to a 4 KB block size... you can get significantly better compression by increasing that to 64k or more, but it has more overhead for small random io
<Mithrandir> psusi: it defaults to 64k in my tests.
<psusi> Mithrandir: so both normal and lzma you have set to use 64k?
<psusi> and lzma is significantly better compression with equal block size?
<Mithrandir> yes
<psusi> wow
<seb128> Diziet: I did that change to firefox: https://launchpad.net/distros/ubuntu/+source/firefox/+bug/5999 (the formatting of the patch is screwed by launchpad)
<Diziet> seb128: Right.
<ijuz> Mithrandir: when are you going to build a new live cd? :)
<Diziet> I RTFM'd dh_install earlier and you were right.
<Diziet> Although I don't understand why it ever worked.
<Diziet> Maybe dh_install has changed its behaviour to match the docs ?
<seb128> not sure
<seb128> it was doing "find mozilla-firefox ! \( -regex .\*\*nspr\*.\* \)" with the '-X*nspr*'
<Mithrandir> ijuz: we need to change the build infrastructure a little for squashfs, but I'm hoping that we'll have something ready early next week
<ijuz> Mithrandir: ok
<lamont-away> Kamion: anything besides make?
<lamont-away> @toolchain_regex = ( 'binutils$', 'gcc-[\d.] +$', 'g\+\+-[\d.] +$', 'libstdc\+\+', 'libc[\d.] +-dev$', 'linux-kernel-headers$', 'dpkg-dev', 'make' );
<Kamion> *could* be related to the change in debhelper 4.9.4 I suppose ...
<Diziet> Well, I can't be bothered tracking that one down :-).
<Diziet> Since it's all fine and dandy now.
<Kamion> lamont-away: nothing else comes to mind right now
<lamont-away> Kamion: it'll be in the next round of updates, as yet unscheduled
<Kamion> thans
<Kamion> +k
<Kamion> can I call gtk.main() from within a gtk signal handler?
<Kamion> hmm, I suppose gtk will block until the signal handler finishes
<mvo> Kamion: what is your use-case/goal?
<Kamion> mvo: I'm trying to start up a debconf coprocess from a GtkNotebook switch_page handler to drive the logic of the new page
<Kamion> mvo: when that coprocess gets an INPUT command, it needs to wait for more gtk events to find out whether to back up or not
<Kamion> the problem is that when I try to do that, the new page doesn't get drawn
<mvo> Kamion: would a  "while(gtk_events_pending()) do gtk_main_iteration(); " help you there?
<zyga> Kamion: coprocess? 
<Kamion> zyga: too complicated to explain right now
<mvo> (or the python equivalent)
<Kamion> mvo: I don't see how, since gtk.main() doesn't get around to drawing the page so I'd guess repeated iterations won't either
<Kamion> and inside debconffilter, I need to actually wait for user interaction, not just draw the page
<Kamion> hmm, perhaps I can do gtk.main_quit() in the switch_page handler and start up debconf outside that
<zyga> Kamion: all sounds fishy, while I don't know the problem I'd opt for a longish clean solution
<sbalneav> Hello all!  Can anyone point me at some docs for adding launchers to the panel in Gnome 2.12 in some scriptable way?  The latest Gnome Administrator's guide is from 2.6, and it seems that most of the gconftool-2 keys have changed about.
<elmo> jdub: only 'lo' appears in the properties of the network status applet, that's the problem
<Kamion> zyga: I'm not sure what you mean
<tseng> elmo: if the other interfaces are down they dont show in the drop down
<elmo> tseng: eth1 is up, and in use
<Kamion> zyga: it's similar to oem-config; I'm basically filtering the debconf protocol in order to implement a pretty interface on top of questions asked by debconf (specifically, UbuntuExpress calling d-i code)
<zyga> Kamion: well if you need gtk.main() and main_quit() voodoo around the app needs redesign IMHO
<zyga> Kamion: hmm, cannot you spawn a subprocess to get the input and report back?
<zyga> I don't know debconf internals but it seems to be ask-and-wait, right?
<Kamion> zyga: no, because the subprocess won't exit
<zyga> Kamion: why not
<Kamion> the flow is that the debconf confmodule (the script running under debconf) calls the INPUT command, and at that point the user interface needs to do stuff
<zyga> Kamion: subprocess like simple text dialog for example
<Kamion> and then report back to debconf whether to go back or forward
<zyga> Kamion: but why cannot that input command simply spawn a UI process, wait for it to exit and report back?
<Kamion> zyga: because then I can't keep the UI for the whole thing within a single unified window
<psusi> pitti: you around?
<Kamion> and several questions from debconf may correspond to a single piece of UI
<elmo> partman (68/76ubuntu1+1): in main - skipping.
<zyga> Kamion: ah, you need plug into existing window
<elmo> baseconfig-udeb (1.04/1.04): in main - skipping.
<pitti> psusi: yes
<zyga> Kamion: you can spawn ui daemon that can show and hide windows
<elmo> Kamion: any of those safe for removal yet?
<psusi> pitti: you seen the spec page I made?  https://wiki.ubuntu.com/PacketCD
<zyga> Kamion: and use something like DBUS to talk to
<Kamion> elmo: partman is different and needs to stay permanently; baseconfig-udeb can go
<zyga> this would really rock btw
<Kamion> zyga: ok, you just got way beyond the complexity I'm prepared to deal with in the time available. maybe later.
<pitti> psusi: wow, no, I didn't
<elmo> Kamion: ok, thanks
<psusi> pitti: I'm looking for ideas on how to make the hal fdi policy look up the type field from the track info on the disc and key on that... think that's possible? 
<zyga> org.debian.DConf.TextInput :-)
<zyga> Kamion: I see :)
<zyga> (then various daemons/services) could implement that interface and spawn text based ui or gui :)
<Kamion> zyga: I don't disagree that something involving dbus would be the right solution long-term, but I just don't have time
<sivang> dbus in Debconf?? ;-)
<lamont-away> mdz: ping
<mvo> Kamion: you need to interact with the user at this stage (when switch_page is called)? or "only" with gtk and debconf?
<Keybuk> \o/
<Keybuk> SCORE!
<zyga> sivang: no, dbus in one of debconf interfaces
<Keybuk> it seems that ifup --allow=auto works already
<Kamion> mvo: not at that particular stage, I just need to kick off debconf
<Kamion> interaction will be later
<Kamion> I'm trying turning the code upside-down at the moment
<psusi> anyone know how to kick the wiki and make it treat attachments as text/plain so they can be properly viewed?
<mdke> psusi, what extension did you give it?
<psusi> mdke: .fdi
<mdke> maybe the wiki doesn't recognise that
<psusi> you're not supposed to key on the name though, it should allow you to specify the mime type, or auto detect it based on the contents.. but there doesn't seem to be a way to specify the mime type
<mdke> no, you can't specify the mime type
<psusi> damn wiki!
* psusi shakes his fist
<mdke> dig around at http://moinmoin.wikiwikiweb.de
<mdke> you'll find a soltion or a bug, or you can file a bug yourself
<HiddenWolf> mdke, that must be the weirdest url I ever saw. :)
<psusi> lol.. yea
<mdke> ok...
<ijuz> how retro, breezy automake is still default to 1.4
<Keybuk> same as Debian
<ijuz> yes, still retro :)
<Keybuk> the maintainer likes it that way
<mdz> lamont-away: pong
<lamont-away> mdz: wondering if mysql 5.0 is supposed to land in dapper, or if I should switch back to libmysqlclient14-dev for a package or 2.
<Diziet> Aaargh!  Why do we throw stuff out of our archive so quickly ?
<ijuz> Mithrandir: you may be interested in this: http://christian-leber.de/~ijuz/advancecompsquash-2.2r2.tar.gz
<Diziet> Is there some magic history site somewhere I just don't know about ?
<fabbione> Diziet: it's fun!
<tseng> Diziet: http://snapshot.archive.ubuntu.com/ubuntu/ like this?
<lamont-away> Diziet: morgue.ubuntu.com
<lamont-away> tseng: there's a snapshot?  kewl;
<lamont-away> morgue is kinda unindexed, which can annoy would-be users...
<Kamion> lamont-away: except that hasn't actually been updated since April
<lamont-away> Kamion: morgue? oh, yeah. that.
<Diziet> snapshot.archive contains what exactly ?
<Diziet> For example, it contains only firefox ubuntu4 and 9 and not 6.
<Kamion> err ... snapshot.archive.ubuntu.com is just one of the *.archive.ubuntu.com wildcard DNS, AFAIK
<ijuz> Mithrandir: it is a mksquashfs that uses the gzip compression of 7zip and compresses a bit (2-5%) better than the normal zlib while staying completly compatible, you don't have to change anything else
<tseng> hm i was sure there was a snapshot at one point
<Kamion> I suspect you'll find it's identical to archive
<tseng> (maybe not here)
<Kamion> Diziet: if there's a particular version you want, I can fish it off jackass for you
<Diziet> Never mind.
<Diziet> /dev/vg_davenant/lv_mirror 180G  137G   43G  76% /export/mirror
<Diziet> I'll just set up magicmirror to keep me a some versions.
<Diziet> Shame I'll still miss some because I don't want to run the mirror more than about once per day.
<Diziet> -1s/me a/me/
<psusi> why not more than once a day?
<Diziet> I don't know exactly what I want.  I was hoping to grobble around in pool to find it.
<Kamion> Diziet: dead packages stay in the archive for a day anyway
<Kamion>   StayOfExecution 86400;
<Diziet> psusi: magicmirror needs some work to improve the performance during the `update mirror target area' step.
<psusi> can you sync the archive with rsync?  then you can use rsync snapshots to keep previous versions
<Diziet> kamion: Oh, good.
<psusi> ahhh
<Kamion> /srv/ftp.no-name-yet.com/morgue/rhona/2005-12-21/firefox_1.4.99+1.5rc3.dfsg-1ubuntu6.diff.gz
<Kamion> /srv/ftp.no-name-yet.com/morgue/rhona/2005-12-23/firefox_1.4.99+1.5rc3.dfsg-1ubuntu7.diff.gz
<Kamion> /srv/ftp.no-name-yet.com/morgue/rhona/2005-12-24/firefox_1.4.99+1.5rc3.dfsg-1ubuntu8.diff.gz
<Kamion> etc.
<Diziet> The following URL could not be retrieved: ftp://ftp.no-name-yet.com/morgue
<Diziet> Squid sent the following FTP command:
<Diziet> RETR morgue
<Diziet> and then received this reply
<Diziet> Err, with a /, I get
<Kamion> it's not accessible, but as I say I can fish stuff out
<Diziet> CWD morgue
<Keybuk> heh, why do our servers STILL call the archive "ftp.no-name-yet.com" :)
<Diziet> Oh, right.
<Diziet> Why can't it be accessible ?
<Kamion> probably in case people mirror it and cane our datacentre's bandwidth
<Keybuk> diz: http://morgue.ubuntu.com/
<lamont-away> Keybuk: because changing it is a royal pain.
<Kamion> Keybuk: out of date
<Keybuk> oh, is it?
<Keybuk> bah
<lamont-away> Keybuk: ENOSPC
<Kamion> it used to be mirrored there; IIRC rookery ran out of space
<lamont-away> Kamion: that's my memory too
<Kamion> the morgue is HUGE
<lamont-away> Kamion: well, of course it is... all those dead bodies piled up...
<Kamion> 191823204       /srv/ftp.no-name-yet.com/morgue/
* lamont-away stops short of making really bad jokes.
<Kamion> hmm, not as big as I thought, but still non-trivial to push around
<Diziet> What's our mirror turnover like ?  Eg, if I kept a copy of every day for the past month, would I have to buy another disk ?
<Diziet> (Files the same in all copies are hardlinked.)
<Kamion> for comparison, the archive proper is 144073008       /srv/ftp.no-name-yet.com/ftp
<Diziet> Oh, that's helpful.  And morgue goes back forever ?
<lamont-away> Kamion: how pre-warty-release does the morgue go? day 1?
<Kamion> Diziet,lamont-away: I'm not sure actually. I don't *think* elmo's ever purged it.
<Kamion> I'm just trying to drive the stats program now
<lamont-away> Kamion: hrm...
<lamont-away> I suppose it's possible that it only dates back to oxford....
<lamont-away> archive events can make for ugly morgues
<psusi> I was under the impression that the morge only contains packages that have been removed from the archive, not each superceeded version
<lamont-away> psusi: they get removed from the arvhive when superseded
<Kamion> psusi: nope
<lamont-away> --> morgue
<psusi> hrm.... what's that url then? ;)
<lamont-away> morgue == everything that was ever in the archive, but isn't now.
<Kamion> psusi: people have abused the word "morgue" in a confusing way, which gave you that impression
<Kamion> that's why I wish people would just say "remove" when they mean "remove from the archive" rather than inventing new inaccurate verbs
<lamont-away> psusi: morgue.ubuntu.com is frozen as of ~april 2005, which kinda limits its usefulness these days
<psusi> yea... so is there an active usefull morgue?
<lamont-away> psusi: not that I know of that is publicly reachable
<Kamion> 20060101 570 533
<Kamion> 20060102 499 855
<Kamion> 20060103 697 1121
<Kamion> 20060104 307 1196
<Kamion> ^-- date, packages, size in megabytes
<Kamion> that's the amount installed into the archive
<psusi> total, or new on that day?
<Kamion> total
<Kamion> I mean, each time a package gets installed, the size gets increased
<psusi> hrm.... only 1 gig as of today?
<Keybuk> no, that means 1 gig got added today
<Kamion> neither
<Keybuk> bah
<psusi> 1 gig worth of new packages today?  holy shit!
<Keybuk> 1 gig got removed today
<Kamion> no, STOP
* psusi is confused
<Kamion> 1GB of packages got installed by kelly, the program that installs .debs, source packages, and so on into the pool
<Kamion> it doesn't mean net increase or decrease of the total size of the pool
<Kamion> (because removals aren't counted there)
<psusi> what's the pool?  and how much is in the archive?
<Kamion> psusi: http://archive.ubuntu.com/ubuntu/pool/
<Kamion> those figures are purely turnover
<Keybuk> the pool is what the developers piss in
<Keybuk> uh, I mean, ... :p
<Kamion> psusi: 16:00 < Kamion> for comparison, the archive proper is 144073008       /srv/ftp.no-name-yet.com/ftp
<psusi> lol
<mdz> mvo: what's the reason for notification-daemon->notify-daemon?
<psusi> that is kb?  so the archive is ~144 gb?
<Kamion> psusi: yes
<psusi> wow... that's a bit larger than I expected
<pitti> hi mdz
<lamont-away> psusi: and smaller than I expected by a shade
<mvo> mdz: upstream changed the name
<psusi> oh, that's for all releases, not just dapper right?
<Kamion> Diziet: taking 2005-11 as a reasonably normal month when we weren't all off on holiday, total turnover was 28482KB, so you shouldn't have to buy a new disk
<Kamion> psusi: yes
<psusi> ahh... ok... 
<Kamion> er, 28482MB, duh
<psusi> 28 gigs of new packages in a month?  wow
<lamont-away> Kamion: it's those wonderful weeks when kernel, toolchain, and oo.o all upload twice. :0)
<lamont-away> psusi: those 28GB were probably accompanied by 27+GB moving to the morgue.
<Kamion> Diziet: if you skip some architectures, it'll of course be considerably less
<psusi> lamont-away: but the morgue is no longer active?
<lamont-away> Kamion: those are jackass numbers?
<Kamion> psusi: morgue.ubuntu.com isn't (the mirror), but the master morgue on jackass certainly is
<lamont-away> psusi: the visible morgue is not current.
<Kamion> lamont-away: yeah, from /srv/ftp.no-name-yet.com/log/
<lamont-away> ok.
<xhaker> hey.. somehow.. a new version of initscripts showed up for upgrade.. i don't even see the source package for that on dapper-changes and it breaks the shutdown procedure
<lamont-away> so those include all 6 architectures
<Kamion> and a hacked copy of saffron
<psusi> ohh... why is the active morgue not publically accessible?
<Kamion> psusi: we just did this
<lamont-away> psusi: ran out of disk space.
<psusi> ohh... so will be be public at some point?
<Kamion> I think we've just encountered the middle of this conversation.
<lamont-away> heh
<ogra> set a mark :)
<psusi> lol
* psusi hushes up
<lamont-away> although I don't think anyone has committed to fixing the disk space and shlepping all the data to a reachable place, it would be nice...
<mdz> pitti: morning
<trulux> pitti: hey
<mdz> lamont-away: I have a note from the devel meeting saying that infinity wanted to discuss that with me (mysql 5.0)
<lamont-away> ok
<lamont-away> meantime, I'll just (a) make it say libmysqlclient15-dev|libmysqlclient14-dev, and (b) hug Kamion for making that work for me back in oxford.
<pitti> hi trulux 
<lamont-away> then a simple rebuild is all that's needed when 5.0 is there
<Keybuk> ROFL @ The "Ben got a PowerBook for Christmas" Release.
<Keybuk> BenC got a powerbook, sabdfl got a Mac, I got a powerbook, did anyone NOT get an Apple over xmas?
<ogra> *giggle*
<Nafallo> me! :-/
<Nafallo> I got a BED :-P
<Kamion> lamont-away: s/Oxford/Mataro/ IIRC :)
<lamont-away> Kamion: 'twas orginal ogre-model --> oxford (pre-warty)
<psusi> I got scuba diving lessons ;)
<Nafallo> woohoo Keybuk rocks! :-D
<mdx> I do?
<Nafallo> mdx: no, not you. Keybuk :-).
<lamont-away> Kamion: hrmpf.
<Nafallo> now you do! :-)
<Nafallo> atleast if that ntpdate-thingie works :-)
<lamont-away> patch was committed 8 dec 2004.  damn.  and here I could have sworn it was oxford
<Kamion> lamont-away: was a bug you discovered in the ogre model and commented on in the quiet room in Mataro loudly enough for me to offer to fix it. :)
<Keybuk> works for me
<lamont-away> Keybuk: my daughter got an iPod, does that count?
<Kamion> having a highly visual memory is handy sometimes - I remember the way the room looked and can mentally zoom out until I see the Cristal ballroom and thereby remember which conference it was. :)
<lamont-away> Kamion: ah, yes.  although I seem to recall some mild begging was involved before you offered to shut me up.
<ijuz> Nafallo: is ntpdate now less annoying when net doesn't work?
<xhaker> ijuz, it should
<Nafallo> ijuz: init.d -> ifup.d :-)
<xhaker> Nafallo, init.d/rc file has a bug
<xhaker> "bug"
<Keybuk> xhaker: it does?
<ijuz> Nafallo: excellent, i really should install dapper on my laptop, so that i can retry pppoeconf
<xhaker> Keybuk, first_step is not set for runtime.... can't remeber
<xhaker> i'll check
<elmo> Kamion/etc.: the morgues actually migrating to hutte now, I finally did run out of space with dapper
<elmo> jackass only has the last 8 months or so
<Kamion> ah, that would explain it ...
<xhaker> Keybuk, had to fix it to be able to shutdown the machine cleanly
<elmo> pending my copious freetime, I'll make tghe complete copy on hutte public
<Keybuk> xhaker: could be, can you file it ... I wasn't my most awake when I wrote that stuff
<Kamion> I think this is a good sign; espresso just showed up its first bug in d-i
<xhaker> Keybuk, ok.. i'll attach a patch hihi
<xhaker> single line tho
<Nafallo> hmm, that bittorrent tracker thing is ugly on shutdown :-P
<Riddell> pitti: do you know if any other distro uses cups 1.2?
<pitti> Riddell: I don't know for sure, but I doubt it
<Riddell> pitti: guess I have to port KDE to cups 1.2 myself then
<pitti> Riddell: oh?
<Nafallo> pitti: oh! that cups thing always have to wait 5 seconds and then gets killed on shutdown :-P
<pitti> Riddell: gnome-cups worked fine with 1.2
<dmk> Riddell: there has been problem with cups 1.2 and kde in fedora
<xhaker> Keybuk, what package is it in? binary please
<Keybuk> PostgreSQL is my shutdown hate
<Keybuk> xhaker: sysvinit
<pitti> Nafallo: cupsd is incredibly hard to kill :(
<Riddell> pitti: it works fine as long as you have a printer setup but if you start with a fresh install and no printers set up it doesn't connect
<psusi> pitti: ohh.. say... I've noticed people complaining lately about removable media, most notably, usb memory sticks, not being properly unmounted due to the icon vanishing right away when they choose eject, but the syncing continues in the background
<pitti> Keybuk: ?
<Keybuk> xhaker: actually, binarywise might be sysv-rc
<Nafallo> hmm
<Keybuk> pitti: if postgresql isn't running, but there's a pid file lying around, it waits a metric week before letting the shutdown finish
<psusi> pitti: have any thoughts as to how to fix that?  I'm thinking some kind of progress indicator during the sync would be nice... but I don't think the kernel provides any means of getting that kind of info
<pitti> psusi: https://bugzilla.ubuntu.com/show_bug.cgi?id=13169
* Nafallo apt-get sources his favorite shutdown-hate-objects :-P
<pitti> psusi: I forwarded this to upstream, and  that's in fact what they will do
<pitti> psusi: http://bugzilla.gnome.org/show_bug.cgi?id=313639
<Nafallo> food now though :-P
<pitti> Keybuk: well, that shouldn't be the common case :)
<pitti> Keybuk: but I'll look at it
<pitti> Keybuk: can you please file a Debian bug?
<pitti> Keybuk: (postgresql-common)
<Keybuk> bah, filing debian bugs is such hard work
<psusi> I htink it is caused by the kernel removing the entry from /proc/mounts before the sync is done... I'm not sure if that can be considered a bug in the kernel or not
<pitti> Keybuk: hm? it's so much easier than filing an Ubuntu bug, at least for me
<pitti> Keybuk: s/easier/faster/
<Keybuk> reportbug sulks because I don't have an MTA
<pitti> Keybuk: I don't use reportbug any more, I just write a mail to submit@b.d.o
<Keybuk> then I have to get the dev-ref out to remember the silly fields you need for that now <g>
<pitti> Package: postgresql-common\nVersion: 38, that's enough for me
<zakame> gaah
<pitti> Keybuk: Severity: wishlist if you want, but I'll care for severity inflation myself usually :)
<zakame> pitti: out of curiousity, how do you handle X-Debbugs-CC: ?
<Keybuk> right, I think that's one filed
<pitti> zakame: I don't explicitly set it, I rely on submit@ to DTRT
<jm_> where can I download the Flight CD 2 ? Thanks
<Riddell> pitti: how come we're using cups 1.2 when it's not had any sort of release yet?
<Riddell> jm_: cdimage.ubuntu.com
<jm_> thanks Riddell 
<Riddell> releases/dapper/flight-2 or something like that
<pitti> Riddell: it was promised for December...
<Riddell> ah :)
<zakame> pitti: ah :)
<pitti> Riddell: it behaves much better with USB printers, that's why we wanted it in the Printer spec
* Diziet finishes fiddling with the mirror.  I think that'll work now.
<psusi> pitti: I think a simple workaround to the problem would be to first remount the filesystem as r/o, then umount it.. that would keep the icon there while the dirty pages are flushed.. might be worth considering if a better solution is taking too long
<pitti> psusi: unmount waits until sync is complete, too
<pitti> psusi: I think the problem is rather that g-vfs calls pumount asynchronously and doesn't wait until it's finished before removing the drive
<psusi> pitti: umount does, but the problem is that the kernel immediately removes the entry from the list in /proc, causing gnome-vfs to remove the icon... I believe... doing a remount first will keep the icon until the dirty pages are flushed, then it's safe to umount
<psusi> I don't htink so because you can umount it from the command line and the icon goes away immediately... I believe it is in response to what the kernel lists in /proc/mounts
<psusi> even though the umount blocks for some time
<pitti> oh, right, I see
<Keybuk> whoah
<Keybuk> this libsane stuff is total crack
<Keybuk> it has a script to convert a usermap into a rules file
<Keybuk> WHY WHY WHY
<Diziet> Maybe I need an even more sophisticated fs.  cp -al on my local mirror seems to take quite a while.
<psusi> I'm not sure if it can be considered a kernel bug or not... that it removes the mount from /proc before it is done flushing
<psusi> but I'm fairly sure that is what causes the icon to go away before the umount completes
<mdz> mvo: I saw a note in JaneW's status report that you wanted to talk with me about the upgrade tool
<mvo> mdz: can I come back to you about it in ~1h? I need to look at my notes what it was about first
<mdz> mvo: ok
<xhaker> Keybuk, http://bugzilla.ubuntu.com/show_bug.cgi?id=21899  ;)
<Mithrandir> ijuz: I'll take a look at it
<psusi> another thing I've found very annoying about the kernel mount mechanics is that there is no umount --i-really-mean-force-it-right-now-and-damn-the-dirty-buffers option
<psusi> it's really annoying when there's a problem writing to the disk and you can't umount the damn thing because the kernel keeps trying to flush the dirty buffers and failing
<ogra_ibook> umount -l isnt enough for you ? 
<psusi> no... that just makes it not block the umount program
<psusi> you still can't eject the disc from the drive ;)
<psusi> and your syslog grows to 50 MB from all the error messages
<mdz> doko: are you aware of this?  trying to overwrite `/usr/lib/openoffice2/help/en/swriter.idx/DICTIONARY', which is also in package openoffice.org2-help-en-us
<doko> mdz: yes, working on updated packages
<mdz> doko: ok, thanks
<mdz> seb128: I find the on-the-fly spell checking in xchat-gnome to be very distracting; is it a good idea to have it enabled by default?
<Kamion> woo
* Kamion gets user-setup successfully integrated into espresso
<Diziet> Can I do a quick survey ?
<seb128> mdz: probably not, especially that the list of language is not configurable from the interface and it underline every english word on a french installation :) I'll speak with upstream about that
<Diziet> update-alternatives --display x-www-browser   who sees it showing up as manual, set to /usr/bin/mozilla-firefox ?
<Diziet> And who sees it as auto, set to /usr/bin/firefox (which is correct) ?
<mdz> seb128: agreed, thanks
<mdz> Kamion: nice!
<seb128> np
<mdz> Diziet: mine was manual until I fixed it earlier in dapper (after it broke everything)
<xhaker> mdz, will it be in main? xchat-gnome?
<seb128> mine is set manual/galeon ...
<mdz> I've been using it instead of xchat for months now, and I think it's ready.  seb128?
<seb128> xhaker: waiting on pitti to review it for promotion
<Diziet> Hrm.  Earlier in dapper ?  How early ?  My dapper chroot here doesn't have it as manual but I probably haven't booted it since dapper.  The testbed dapper machine has manual and is broken.
<seb128> mdz: yeah, it just wait for pitti to review it for main promotion
<xhaker> mdz, i've said so before here in this same channel.. they don't listen to me.. hehe
<pitti> seb128, mdz: it's approved since last year, just needs to be germinated :)
<seb128> hum, weird
<mdz> Dec 06 09:37:57 <mdz_>   link currently points to /usr/bin/mozilla-firefox
<mdz> Dec 06 09:37:57 <mdz_>  /usr/bin/firefox - priority 70
<mdz> Diziet: ^^
<pitti> seb128, mdz: xchat-gnome still sucks as long as it can't split windows, but I'd only keep one, not both
<Diziet> Hrm.  December.
<seb128> pitti: did you review 0.7 or 0.8?
<mdz> seb128: feel free to make the seed change
<seb128> mdz: will do
<seb128> that and avahi :)
<pitti> seb128: dunno, whatever was current in the end of december
<pitti> seb128: at Dec 13 to be exact
<Diziet> I think I'll just have to do a clean install (eg, breezy, dapper upgrade) and see if and when it breaks.
<mdz> Keybuk: what's the correct first_step value in rc for runlevels 0 and 6, so I can fix it locally?
<seb128> pitti: oh, I said to wait on 0.8, which is from Dec 21 which is probably much better (they stopped to ship the xchat sources for text, gtk, etc ... they just have the common folder from it now)
<pitti> seb128: well, doesn't make much of a difference, review-wise
<seb128> pitti: anyway, that does the trick too, new one is just better, thanks :)
<pitti> seb128: I didn't audit the source for this one
<seb128> k
<mdz> xhaker: it's something we've discussed for a long time; it's just been a matter of choosing the right time to switch
<mdz> pitti: split windows?
<pitti> mdz: watch two channels at the same time
<xhaker> pitti, xchat allows that?
<pitti> mdz: in xchat I can split off a channel window
<pitti> xhaker: for ages, yes
<pitti> it's a feature I love
<mdz> pitti: oh, the attach/detach tab thing
<pitti> how else can you follow two channels at once?
<pitti> mdz: right
<seb128> I just switch between chans :)
<pitti> every minute?
<mdz> me too
<mdz> no, just when it's highlighted
<pitti> that's too distracting for me
<mdz> so every 5 minutes approximately
<pitti> #u-d{esktop,devel} highlight every 10 seconds...
<seb128> pitti: when I'm busy I switch when somebody speaks to me
<pitti> hm
<xhaker> pitti, but it goes to the taskbar
<pitti> maybe I need to change my working style then, I just got used to the feature
<seb128> otherwise I read the log every few and then
<xhaker> i thought you were talkink about something like split view.. like in IDE's
<seb128> I have like 20 chans anyway, I could not get them all at screen
<pitti> seb128: http://people.ubuntu.com/~pitti/shots/crashrep-gui.png <- that's how I do it
<pitti> seb128: (this shot has a different purpose, but shows off xchat as well)
<seb128> pitti: anyway: http://bugzilla.gnome.org/show_bug.cgi?id=323486
<Kamion> mm, I'm with seb on this one
<xhaker> they should do it then
<xhaker> i like Guillaume option
<pitti> me too, sounds nice
<xhaker> like in eclipse, or any word processor
<pitti> or vim's :split
<jm_> bye
<xhaker> hehe.. i should really try vim more
<pitti> xhaker: /me <3 vim 
<pitti> xhaker: /me <3 vim 
<xhaker> oh crap
<xhaker> how dows one reattach a channel window?
<xhaker> i just parted the channel trying to do that :P
<Riddell> Keybuk: what's the status of network manager in ubuntu?
<Keybuk> universe
<Keybuk> I could explain now, but it'd ruin the surprise for the status meeting
<xhaker> surprise surprise
<seb128> hum
<seb128> $ bzr get sftp://chinstrap.ubuntu.com/home/warthogs/archives/seeds.ubuntu.com/ubuntu/seeds/dapper
<seb128> bzr: ERROR: Not a branch: sftp://chinstrap.ubuntu.com/home/warthogs/archives/seeds.ubuntu.com/ubuntu/seeds/dapper
<Kamion> I think it's a bzr bug, best ask on #bzr
<seb128> k, thanks
<Kamion> I just haven't upgraded my currently-working daily build of bzr from a month or two ago ...
<Kamion> what do you need to change?
<pitti> Keybuk: you want to motivate us to get up at 3 am? :)
<seb128> right, works with the dapper version
<seb128> s/xchat/xchat-gnome
<pitti> seb128, Kamion: no, it's actually a bug fix
<seb128> and list avahi-daemon
<Kamion> oh, if you've got a checkout with the dapper version then go ahead
<pitti> seb128, Kamion: try with ... .com/%2Fhome/warthogs
<seb128> yeah, seems to be fine with dapper version
<seb128> pitti: hum, why?
<pitti> seb128: the sftp:// specification says that the URL is relative to the home dir
<pitti> seb128: so sftp://host/foo refers to ~/foo, not to /foo
<seb128> ah
<pitti> seb128: older bzr versions didn't respect that
<ajmitch> which really does get annoying
* Kamion thinks the specification's insane, but there you go
* ajmitch came across that same sftp issue a couple of days ago
<Mithrandir> you don't have to escape the /, though.  sftp://host//wherever should work
<jbailey> Yup, just double the /
<pitti> Mithrandir: maybe, I just followed the advice in the bug report
<jbailey> (if you're using my nightly snapshots)
<pitti> but so much the better
<Kamion> that's a little less horrible at least
<Mithrandir> it's utterly insane.
<Mithrandir> or arcane
<jbailey> But who is to blame?
<jbailey> mpool is his name!
<jbailey> (sorry, I'll stop the rap now)
<Mithrandir> he wrote the sftp spec?
<pitti> http://bugzilla.gnome.org/show_bug.cgi?id=322394, btw
<jbailey> AFAIK, the IETF spec wasn't actually approved
<jbailey> It's just better than nothing.
<pitti> it's not a bzr bug, but that's where jamesh pointed to
<pitti> http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-03.txt <- spec
<Kamion> None of the secsh specs are RFCs yet
<Kamion> although that one isn't even in the editor's queue, true
<seb128> dholbach: you said you would make a promotion page for libsexy no? xchat-gnome builds with it atm
<jbailey> libsexy?
<dholbach> seb128: i can do that, yes
<dholbach> jbailey: "doing naughty things to widgets" :)
<jbailey> lol
<seb128> dholbach: thanks
<stratus> btw libsexy is cool!
<stratus> oh, there's sexy-python too
<Diziet> dholbach: Your symlinks for /usr/include/mozilla-firefox:
* pitti shakes his head about gnome's naming scheme; -plugins-ugly, libsexy, ...
<Kamion> pitti: libwnck
<Diziet> Firstly, you didn't fix up the transition yet, did you ?  I mean, where you can end up with both directories because of dpkg/symlink transition issues ?
<Diziet> Secondly, these links are needed for the embedders, not for the libnss/libnspr users, right ?
<pitti> I think libaqbanking-plugins-libgwenhywfar17 is my most favourite package name, though
<seb128> rofl, that's a real package
<Mithrandir> pitti: looks like somebody who has taken my advice of using pwgen-generated names to heart.
<pitti> I couldn't type that without tab completion...
<ijuz> Keybuk: i tried it, on a 2 Ghz Athlon XP the decompression of the packages on the breezy cd (compressed with lzma) took 107 sec that results in about 15 MB/s of decompressed data; memory usage is sligtly over 8 MB when you compress with 8 MB dictionary
<dholbach> Diziet: I didn't think of the transition issue, when i added the symlink. Kamion told me afterwards. About your second point: I don't know - aren't embedders libns{s,pr} users? :-)
<dholbach> Diziet: Somebody, I think it was Kamion, gave me a small script for the transition, let me try to find it and send it to you in a query.
<Diziet> dh: Yes, embedders are libns{s,pr} users.
<Diziet> But libnss/nspr users just look in the .pc file which has the /usr/include/mozilla path and should just work.
<Diziet> It's the embedders (and the firefox binary itself) which look in /usr/lib/mozilla-firefox.
<Keybuk> pitti: if I'm getting up, you are
<Diziet> (It's a bit schizoid because the ffox build system wasn't meant to do this.)
<Kamion> mdz: I take it you want to have that talk after the management meeting now?
<Diziet> transition script> 'sok, I can roll my own.
<mdz> Kamion: yeah
<pitti> Keybuk: I'm already afraid enough of JaneW's whip :)
<Diziet> There's an attempt in the bug report even :-).
<mdz> Kamion: assuming you'll be around
<Kamion> yeah, although I'm having dinner soonish
<Diziet> OK, well, I'll put it in the firefox-dev package and see what breaks.
<dieman> heh
<dieman> i had one user get cranky about us going to UTF8
<mdz> Keybuk: ok, I'm guessing 50
<dieman> grep is slower (at least in hoary)
<dieman> need to check if newer versions are appreciably faster.
<pitti> Riddell: still here?
<Keybuk> mdz: 50?
<Keybuk> or do I need to take your tab key away? :P
<mdz> Keybuk: <mdz> Keybuk: what's the correct first_step value in rc for runlevels 0 and 6, so I can fix it locally?
<Keybuk> ahh
<Keybuk> sorry
<Keybuk> I have no idea why x-chat didn't hilight that, strange
<Keybuk> 0 I would guess
<Riddell> pitti: yo
<Kamion> dieman: I think that got fixed eventually upstream, but it took a while
<pitti> Riddell: I'm currently reviewing the patch, and I will do the patching and exploit testing tomorrow
<Kamion> grep was using the libc multibyte functions, which were a bit too generic and slow for what it was doing; Markus Kuhn mentions the issue on one of his Unicode pages
<Riddell> pitti: ok, need me to do anything?
<pitti> Riddell: however, since this is really not funny any more, maybe you could build koffice and kpdf against poppler in dapper?
<Kamion> http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod
<pitti> Riddell: it's really pretty easy, you just have to tickle the build systems a bit; it was pretty easy for tetex-bin and xpdf-utils
<Riddell> hmm
<pitti> Riddell: using /usr/include/poppler and linking against -lpoppler is all it should take
<Riddell> if we get libgs.so in we can use okular which is the kpdf replacement that uses poppler
<pitti> Riddell: well, maybe do some small adaptions (s/GString/GooString/)
<Kamion> oh, crap, it's tonight's meeting that's 2am
<martink> kpdf has some enhancements to the Xpdf code that are not in poppler yet (or so its author says)
<pitti> Riddell: I leave that to you :) I Just wanted to point out the possibility
<Kamion> can somebody send an ubuntu-devel-announce@ reminder please? it's a bit late, but might help
<Diziet> *snort*
<pitti> JaneW pointed to it in her last report, but of course another one shouldn't hurt
* pitti writes one
<dieman> Kamion: yeah, im reading the bug, #1148
<dieman> Kamion: looks like it was fixed, reverted, then fixed again
<dieman> Kamion: appears dapper has the version with the patches
<pitti> Kamion: sent
<Kamion> pitti: thanks
<Kamion> (approved)
<pitti> Riddell: btw, http://scary.beasts.org/security/b0dfca810501f2da/CESA-2005-003.txt has some shiny exploits for testing
<Kamion> Diziet: should #1148 be closed?
<Diziet> I don't know; I haven't tested on our end.
<pitti> mdz: could you please take a short look at the status whiteboard of https://launchpad.net/distros/ubuntu/+spec/gstreamer-audio-backend ?
<Diziet> I don't know of any reason why we would disagree with Debian.
<pitti> mdz: everything is implemented from our side, and the missing upstream bit doesn't actually conflict with our changes; would you be fine if I set this to implemented?
<mdz> pitti: meeting now, but will take a look later
<pitti> oh, sorry
<Kamion> Mithrandir: is there a way I can get at the unmodified CD filesystem from the current live CD?
<Mithrandir> Kamion: I could arrange that.
<Kamion> please - need it for u-e
<Kamion> (per https://wiki.ubuntu.com/UbuntuExpress/CopyFileSystem
<Kamion> )
<Mithrandir> sure, I'll fix that.
<seb128> pitti: hum? distro meeting at 2am? previous one was at 2pm no?
<pitti> seb128: previous one was 1400, but the 2000 was skipped due to holidays
<seb128> oh, skipped, not shifted
<seb128> grumpf
<seb128> are you sure? :)
<pitti> seb128: JaneW wrote the date in her last report
<pitti> seb128: I'd prefer 2000, too, believe me
<seb128> bah
<ogra_ibook> sigh
<seb128> k, I'll stop working now for a bit so, or I'll no keep until 3am
<pitti> seb128: I will sleep before :)
<seb128> I don't want to try that
<seb128> waking up after 2 hours of sleep ... not for me
<psusi> pitti: do you think it would be rather easy to patch pumount to remount r/o first, then really unmount?  or would that not be so simple?
<pitti> psusi: that's what I had in mind when we do that
<psusi> cool... the progress bar would be nice ( especially if it were actually accurate ) but the remount should be a much simpler fix... if it is a simple bug fix, can't it even be back ported to breezy?
<pitti> psusi: let's see, maybe the gnome guys will figure out a nice progress bar or sth
<pitti> psusi: I doubt that it will be backported, but for dapper it's an easy alternative, right
<psusi> well, like the author of gumount said, the kernel doesn't export enough information
<pitti> right, progress bar is probably hard
<pitti> but at least a warning dialog would be sufficient
<psusi> hell, as long as the icon doesn't vanish until the flush is done, that would keep people from yanking the drives early and corrupting their data
<pitti> (well, more of a 'monolog' :) )
<psusi> though they might wonder WTF it isn't going away when they chose eject
<ogra_ibook> pitti, make it a game ... to keep the user busy until he can unplug ;)
<psusi> lol
<zul> ooh tetris would be my vote
<zakame> haha
<psusi> I say pong
<marcin_> marcin: jestes ?
<ogra_ibook> if you integrate pmount with n-m, you could make a netris session :)
<pitti> psusi: yes, you could shoot the dirty blocks into the USB device, and you'll lose all data that miss the target in the game :)
<marcin_> hmm
<marcin_> nvm
<psusi> roflmfao
<marcin_> :D
<marcin_> freenode is beautifull :D
<psusi> I used to know a crazy programmer who said the only game worth playing was one where it blew away random clusters on your hard disk as you took damage ;)
<Treenaks> </sarcasm>, I hope?
<marcin> :>
<marcin> :P
<marcin> bye
<dholbach> seb128: report written
<Keybuk> right, dinner time I think
<Keybuk> see everyone at OHMYGOD am
<wasabi> There a trick to getting vmware compiling on 2.6.15-10?
<HiddenWolf> jdub, is there any way that the fridge can show where it links to instead of those node links?
<HiddenWolf> jdub, call me paranoid, but I'd like to know what I'm clicking on.
<Treenaks> HiddenWolf: http://www.w3.org/Provider/Style/URI you mean? :)
<HiddenWolf> Treenaks, just that when I see a link pointing to fride.ubuntu.com/bla, I expect to end up at f.u.c and not at eweek. If it points to eweek, I want to know that before I click on it.
<xhaker> new libsane package tryed to do some wierd shit
<xhaker> it's trying to remove /etc/hotplug dir
<xhaker> that's not a good idea
<xhaker> it does fail.. it's a rmdir
<ogra_ibook> nope, since this dir shouldnt exist on dapper
<xhaker> blaccklist.d is in ther
<ogra_ibook> dpkg -S /etc/hotplug/blaccklist.d ?
<ogra_ibook> -c
<Kamion> xhaker: it was probably just the last package on your system owning /etc/hotplug, so dpkg tried to remove it; nothing to worry about
<Kamion> note that stuff created by maintainer scripts is not generally known to dpkg
<ogra_ibook> ogra@aleph:~$ dpkg -S /etc/hotplug/blacklist.d
<ogra_ibook> hotplug, alsa-base, linux-sound-base: /etc/hotplug/blacklist.d
<ogra_ibook> mine is cleaver :)
<ogra_ibook> -a
<Kamion> oh, what do you know, it is the maintainer script doing it
<Kamion> it doesn't matter though, it's || true'd and it doesn't try to force it
<Kamion> it should really use rmdir --ignore-fail-on-non-empty though
<Kamion> (which would suppress the error message too)
<Kamion> I'll go clean that up
<Kamion> (done)
<xhaker> ;)
<mhz> fabbione: ping
<fabbione> mhz: pong
<lamont> hrm... /me will miss the distro-team meeting tonight
<fabbione> OH CRAP
<fabbione> it's already THAT thursday of the month!
<pitti> fabbione: yes :(
<ogra> yup
* fabbione ponders
<fabbione> pitti: why #ubuntu-devel????
<fabbione> we always did it in #ubuntu-meeting
<Burgwork> fabbione, likely a typo
<Burgwork> jdub, ping
<pitti> fabbione: oh, sorry, that was a typo
<fabbione> eheh
<fabbione> elmo, Kamion: would you be so nice to NEW the sparc kernel when  you have a minute? so i can kick l-r-m
<elmo> fabbione: it's not in NEW
* fabbione scratches his head...
<elmo> does anyone know if it's safe to take home from an amd64 box and copy it across to an i386 one?  i.e. any common apps which store stuff in 32/64 sensitive format in ~/
<fabbione> elmo: thanks... i missed the mail of ACCEPT :(
<fabbione> elmo: it should be. i share my /home with all our 7 arches..
<fabbione> make that 6..
<fabbione> m68k doesn't count :)
<elmo> fabbione: any 64 vs. 32 tho?
<elmo> I suppose endian switching should be guarantee enough
<fabbione> elmo: amd64/hppa/i386/sparc64/ia64/ppc
<fabbione> i use all of them..
<fabbione> same /home
<elmo> fabbione: k, thanks
<fabbione> i didn't notice anything...
<fabbione> ... hmm.. hold on.. where is my GPG key???
<fabbione> :P
<maswan> work has $HOME in afs, shared between amd64, i386, AIX.. hmm.. no sparc/solaris anymore though
<maswan> I'd consider it a fairly big bug to have things break because you switch arch
<elmo> yeah, I'd assume it would work, but I've never tried it before, esp. on a desktop, so I thought I'd ask
<fabbione> elmo: are you just tarring up the data? or moving the disk?
<elmo> rsyncing from backup
<elmo> I'm trashing an amd64 laptop, reinstalling it as i386
<fabbione> nah no problem than
<fabbione> elmo: why?
<ogra> oh, have fun with the fans then :)
<fabbione> elmo: do you have userland or kernel problems?
<elmo> fabbione: userland, need proprietary crap to work
<fabbione> elmo: as proprietary drivers for the kernel i assume
<elmo> no, proprietary userland
<fabbione> ah
<fabbione> ok
<fabbione> elmo: than let me give you a suggestion
<fabbione> install whatever release you want with standard kernel
<fabbione> grab the the proper amd64 kernel .deb
<fabbione> dpkg -x blabla.deb .
<fabbione> dpkg -e blabla.deb
<fabbione> in DEBIAN/* there are only 3 or 4 references to amd64
<fabbione> that changed to i386
<fabbione> + a dpkg-deb -b
<fabbione> will give you a nice amd64 kernel for an i386 userland .deb :)
<fabbione> elmo: sounds crack, but it works perfectly
<fabbione> and you get all the hw support from amd64 with 32 bit userland
<ogra> oh, thats nice to know ...
<maswan> or just not bother about it, sounds unlikely that you need 64-bit adressing on a laptop
<elmo> fabbione: hmm, nice idea, but I'm going for maximum stability + simplicity, as this laptop's going on the road with a new-to-linux-user and needs to Just Work
<sivang> elmo: is that a light weight laptop?
<maswan> and the rest of it is just performance
<ogra> my fans always freakout if i use a 32bit os on this amd64 lappie
* sivang wanted to get one sometime ago
<fabbione> elmo: ok.. in that case it makes sense, be sure the i386 kernel can control fans and so on..
<fabbione> maswan: well. not only. there are some chipsets that are not supported by x86
<fabbione> the one that are specific for x86_64 only
<fabbione> like dunno.. thermal control?
<ogra> yup
<fabbione> cpu_freq?
<fabbione> otherwise the battery on that laptop will last approx 10 minutes
<fabbione> elmo: i think we will ship such a kernel in universe.. BenC and I didn't agree yet on how to build it :)
<ogra> mine hovers 1m above the ground on i386 kernel... i never tried it on byttery
<spacey_ki> :)
<spacey_ki> quite impressive with that weight :)
<ogra> heh
* ogra really hopes elmo has no acer in front of him
<elmo> no, it's a compaq
<elmo> presario v2200 or something
<maswan> fabbione: oh, I didn't know that
<ogra> ah, that leaves some hope
<elmo> I'll check the fans etc. work once it's installed
<fabbione> maswan: ehehe
<elmo> wow, that's impressively confused
<elmo> the wireless stack thinks the pcmcia card is both eth1 _and_ eth2
<dilinger> heh
<dilinger> someone else saw this earlier
<dilinger> <flamingcow> 08:22:23.908402 00:30:48:51:88:c3 > Broadcast, ethertype ARP (0x0806), length 42: arp who-has 209.123.2.10 tell 209.123.2.10
<dilinger> let's hear it for confused kernels
<fabbione> elmo: is that an aironet/cisco card?
<psusi> rofl
<psusi> ohh, that's probably an anti collision check
<elmo> fabbione: yeah it is
<fabbione> elmo: i was that problem only with the airo pci version of the card and only with .15. I didn't have time to bisect the kernel, but unload and reload the module seems to do the trick
<fabbione> and it doesn't even happen all the time
<elmo> it didn't happen with an amd64 kernel :(
<fabbione> s/was/saw
<fabbione> yes.. i386 only it seems
<fabbione> ppc doesn't do that either
<elmo> yeah, this is the cisco from my powerbook, and I never saw it there
<fabbione> elmo: i guess that one is .12, isn't it?
* fabbione wishes elmo will say it's .15
<ogra> for a newbie on the road ? 
<fabbione> ogra: i think that laptop is new enough that needs .15
<ogra> but that breaks a lot with breezy ...
<maswan> it's just a sign that the release cycle is way too long, it should be a new release every 3 weeks!
* maswan ducks
<fabbione> ahah
<fabbione> actually releasing every month or two is almost doable, if you can live without new features and no new crack :P
<ogra> 3 weeks is fine, then the freezes would only be 2 weeks max :)
<lifeless> moin
<maswan> fabbione: actually, I'd love to see a breezy backport of 2.6.15. we currently run a hacked-together kernel.org on our workstations, but it lacks some stuff, like alsa. :)
<maswan> fabbione: flight-2 wasn't quite up to it for my main workstation at work. :)
<fabbione> maswan: you can't.. you will need too much from dapper to make it worth a backport
<maswan> fabbione: yeah, I know
<maswan> fabbione: that's why it's a kernel.org and not dapper kernel
<fabbione> ehm...
<fabbione> well whatever you say :)
<maswan> "it's" - the thing we run now
<maswan> would have been neat if there was an ubuntu 2.6.15 to run though
<maswan> but I'll guess we'll just wait until dapper releases
<fabbione> iirc the udev requirements between ubuntu and kernel.org are the same
<maswan> ah
* sivang uses dapper on his workstation since ~month now, all is good except for evo disappearing one day, and coming back after :)
* sivang should switch to mutt at work as well
<sivang> anyway, I'm off - night everyone
<maswan> fabbione: well, it works mostly fine for us as it is
<maswan> fabbione: just saying that it was rather annoying finding breezy and all other relaesed distributions uninstallable. :)
<fabbione> maswan: you lost me...
<fabbione> maswan: what do you mean other released distros uninstallable?
<fabbione> what workstations do you have?
<Burgwork> how do I debug gnome-session hanging?
<maswan> fabbione: fujitsu-siemens athlon64 x2 with a new enough sis chipset to need 2.6.15 to find the sata disk
<psusi> can mutt generate mbox indexes, or does it have to read and parse the entire thing every time like pine?  that doesn't work too well on 50 MB mboxes
<fabbione> maswan: ahhhhhh ok
<maswan> fabbione: the bundled fedora core 4 dvd didn't install either. :)
<mdke> psusi, #ubuntu can help
<fabbione> maswan: that's something similar to what i had to do to install my ppc
<psusi> heh... sivang mentioned he uses mutt... figure'd pose the question... I don't think it can, and i"m happy with thunderbird... was just curious
<maswan> fabbione: we just hacked together something out of kernel.org sources though, and it works. lacks some stuff, like alsa sound and possibly hal/dbus stuff. and splashy thingies. but it works. :)
<ogra> Burgwork, easiest is probably to run a failsafe terminal session and run gnome-session manually
<ogra> Burgwork, or run it with gdb if you have a -dbg package around
<fabbione> maswan: you could try installing .15 from dapper on one of them.
<maswan> fabbione: We have installed flight-2 on them. Installing the dapper kernel seemed to want to pull in a bit too much from dapper though.
<maswan> fabbione: we have test-installed flight-2 I mean
<fabbione> ok
<elmo> fabbione: fyi, that tricked didn't work too great for this laptop, pcmcia doesn't come up at all
<elmo> or at least airo_cs doesn't work
<elmo> and I've got "APIC error on CPU0" in the logs 
<fabbione> hold on
<fabbione> cat /proc/cmdline 
<fabbione> root=/dev/mapper/Ubuntu-root ro quiet splash noapic
<fabbione> try adding the noapic to the boot options
<fabbione> or disable it from the BIOS if you can
<fabbione> apic makes baby jesus cry
<elmo> this laptop is making me cry
<fabbione> do you also have airo loaded?
<fabbione> or only airo_cs ?
<ogra> i thought thats only the liar apic or lapic :)
<fabbione> i know mine is airo..
<fabbione> the module i unload and reload
<elmo> fabbione: ok, got rid of the APIC errors with no apic,but still no cisco love
<elmo> modprobe-ing airo or airo_cs runs without  error, it just doesn't find the card
<fabbione> oh
<fabbione> did you try to stop and start pcmcia from init.d?
<elmo> that generated a bunch of ioctl32(cadmgr:7557): Unknown cmd fd(3) cmd(c0146402){00} arg(0806f388 on /var/run/cm-7557-1 (deleted) in dmesg
<elmo> I think/guess 32-bit cardmgr doesn't work with 64-bit kernel (anymore?)
<fabbione> ehm
<fabbione> i thought you were using a 32bit kernel?
<ogra> he tried your suggestion
<fabbione> elmo: it's possible that compat_ioctl are broken
<fabbione> there are not that many people using that setup
<fabbione> i guess you win the biscuit for finding one of them
<fabbione> elmo fabbione: fyi, that tricked didn't work too <- i guess this one was referred to amd64->i386
<fabbione> anyway
<ogra> thats how i understood him 
<fabbione> time to boot into the new kernel
<fabbione> brb (hopefully)
<elmo> ok, not feeling the ubuntu love on turion laptops, it has to be said
<ogra> cant you run the proprietary app in a 32bit chroot on the 64bit os ? 
<ogra> since i guess the amd64 version runs fine
<elmo> argh, how do I convince gnome to use run a damn shell script and not throw up a confusing prompt?
<ogra> you reate a launcher to launch the script
<ogra> *create
<elmo> how do I do that?
<ogra> right click on the desktop
<seb128> elmo: you mean the "show" "launch" ... dialog?
<seb128> there is a nautilus preference to always open them as text or always run them
<elmo> seb128: ah, thanks
<ogra> ah, yes, that too
<elmo> I'll try a launcher tho, that sounds fun
<lifeless> seb128: an actual preference? or a gconf hidden flag ?
<seb128> lifeless: UI preference
<ogra> lifeless, actual preference iirc ...
<lifeless> wow
<lifeless> sabdfl: btw LOVED your warthogs mail ;)
<fabbione> this wasn't such a great jump
<ogra> :(
<fabbione> cups doesn't stop properly
<fabbione> there is a typo somewhere in the init scripts at shutdown
<fabbione> that gives a syntax error on /etc/init.d/rc
<fabbione> reboot asked me for a root/maintain passwd after that error (i assume they are related)
<fabbione> (line 210 of that file)
<fabbione> at boot we have "Setting system clock" twice
<fabbione> a postfix reload error
<fabbione> and the worst thing is the new gdm logout screen that seems to be written by m$ :P
<ogra> oh thats in already ? 
<fabbione> imho it's horrible
<fabbione> it did really scare me
<ogra> i havent upgraded for some days
<fabbione> this is a 30 minutes ago dapper
<lamont> fabbione: hwclockfirst.sh and hwclock.sh
<fabbione> lamont: is that wanted?
<lamont> I suppose I could make the messages slightly different
<lamont> iz necessary
<fabbione> ok
<lamont> it's always been there, but I cleaned up a bunch of bugs by merging the files
<fabbione> i think it would be a good idea to see 2 slightly different messages
<lamont> so now hwclockfirst.sh is a sed command to generate it from the other
<lamont> fabbione: ok.  file a bug in bz and assign it to me?  (or at least make me a cc)
<fabbione> lamont: sure :)
<fabbione> it's nothing urgent
<lamont> what was the postfix reload error?
<fabbione> for people used to read what happens at boot, it seems an error
<fabbione> lamont: dunno... it's masked by the boot thingy and lsb
<fabbione> it happens immediatly after network comes up
<fabbione> so i *think* it's that script you put in /etc/network/if-up.d or something
<fabbione> i assume the error is due to the fact that postfix isn't running et
<fabbione> yet
<fabbione> and it attempts to stop/start it again
<lamont> fabbione: actually, the old hwclockfirst.sh didn't print anything
<lamont> ew
<lamont> I suppose I'll have to track that down
<elmo> holy COW this is annoying
<elmo> is there anythingmore I have to do in gnome to get it to change the keyboard, beyond selecting the layout in keyboard preferences?
<elmo> maybe I'm going insane, but I'm sure this worked for amd64 and is no longer working on the same machine in x86 mode
<seb128> what is not working?
<elmo> it's stuck in UK mode, and I want it in Canadian French
<elmo> (seriously :P)
<seb128> did you select different layouts or only one?
<elmo> I've still got UK in there, it's just not marked as default and is at the bottom
<ogra> and did you use the anguage selector ? 
<elmo> I'll try removing it entirely
<seb128> it's xorg bog
<ogra> *language
<elmo> ogra: no! I only want the keyboard changed
<elmo> seb128: oh, really?
<seb128> yep
<elmo> is there a workaround?
<seb128> do you use breezy or dapper?
<seb128> having 1 layout only is a workaround
<elmo> seb128: breezy
<elmo> ok, 1 layout works
<elmo> seb128: thanks a lot
<seb128> np
<seb128> that's supposed to be fixed with xkeyboard-config from breezy-updates, daniels fixed that after the 5.10 freeze
<elmo> hmm, it doesn't seem to fixed, and I've got breezy-updates installed
<seb128> does "setxkbmap -layout 'ca,gb' -model pc105 -option '' | xkbcomp - :0.0" returns some error after the list of warnings?
<elmo> oh dear god, it's STILL in UK mode
<seb128> pc105 to replace by your pc10n variant
* elmo STABS this stupid montrealian laptop
<jdub> fabbione: you're famous! :)
<jdub> elmo: quebecistani :)
<fabbione> jdub: ?
<jdub> fabbione: your interview -> FRIDGE TIME!
<ogra> i'd still check the input methods column in the language selector .... :)
<fabbione> jdub: dude HALT!
<fabbione> jdub: only if you add one NOTE
<jdub> yeah?
<fabbione> jdub: it's not my ITAGLISH in there
<fabbione> i was asked to answer in italian
<jdub> hahaha
<fabbione> somebody did translate it
<jdub> ok, will do
<fabbione> and missed some stuff
#ubuntu-devel 2006-01-10
<fabbione> at least the concepts were not expressed in the same terms/words i would have used in english :)
<seb128> elmo: if you don't want to bother, "setxkbmap -layout 'ca' -model pc102" should do the trick
* jdub is tempted to make the title, "Fabio: The Most Beautiful Server Team Leader in the World"
<elmo> seb128: I tried that xkbcomp thing, and it said:
<elmo> sytntax error: line 1 of stdin
<elmo> Errors encountered in stdin; not compiled.
<elmo> setxkbmap directly kills the UKishness, but it's not quebicistani
<jdub> fabbione: do you want me to make that 10k icon the server team icon on the fridge?
<fabbione> jdub: use the one from LP
<fabbione> that's acutally the same :P
<jdub> ok :)
<seb128> elmo: ups, it lacks a -print
<fabbione> jdub: btw.. remind me to send you 10 quid
<seb128> elmo: setxkbmap -layout 'ca,gb' -model pc105 -option '' -print | xkbcomp - :0.0
<elmo> ok, no errors, just warnings
<seb128> hum, weird that it bugs from GNOME, that's basically what the keyboard configurator should do
<seb128> I'll give it a try on a breezy box later
<elmo> ok, and X's idea of a .ca keyboard is realy not jiving with this laptop
<seb128> for the moment you should be in ca keyboard
<elmo> seb128: yeah, I am after running that command
<fabbione> jdub: btw.. where did you find out about the interview? i didn't really make it public
<Burgwork> fabbione, it just hit osnews
<jdub> fabbione: i have spies. but it also hit osnews.
<fabbione> ah
<seb128> elmo: could you run "gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd" ?
<jdub> fabbione: which means you're going to be flamed ;-)
<fabbione> i don't care :)
<elmo> holy cow
<elmo> X really does not have a keymap which is even close to this one
<elmo> quebicistan: 1, x.org: 0
<Mithrandir> you have a quebec.ca keyboard?
<elmo>  layouts = [ca] 
<elmo>  model =
<elmo>  options = [grp grp:alts_toggle] 
<elmo>  overrideSettings = true
<elmo> seb128: ^--
<elmo> Mithrandir: one of the laptops from UBZ
<seb128> elmo: setxkbmap -layout 'ca,gb' -model pc102 -option 'grp:alts_toggle' -print | xkbcomp - :0.0
<seb128> elmo: does that work
<elmo> oh, no, errors!
<seb128> k, so it's xorg bog
<jbailey> elmo: X does have it, but you have to install in French to get it, IIRC.
<seb128> it doesn't like the 'grp:alts_toggle' option combined with 2 keymaps
<elmo> jbailey: say what now?
<jbailey> elmo: I had the problem that I install in french and had to beat it to give me US layout.
<seb128> that's bugzilla http://bugzilla.ubuntu.com/show_bug.cgi?id=15372
<seb128> and is fixed with dapper xorg it seems (works fine on my box)
<elmo> oh the one half the world is Cced on, including me, I remember that bug
<elmo> jbailey: how does installing in french open up more keymaps?
<jbailey> elmo: No, it seemed to default to French.
<jbailey> elmo: Which was particularily annoying.
<jbailey> I've never tried installing in English when I wanted a French Canadian keyboard.
<jbailey> So I don't know how to find that layout.
<fabbione> jdub: i love you!
<lucas> be careful, such claims could end up in a topic ;)
<elmo> jbailey: I'm entirely confused
* jdub hugs fabbione 
<fabbione> jdub: that note on the itaglish is perfect
<sabdfl> Mithrandir: any movement on t-bird 1.5?
<fabbione> jdub: you forgot the logo on the fridge ;)
<fabbione> for the server team :)
<jdub> fabbione: it only uses the logo of the first category, and atm the 'interviews' category doesn't have one ;)
<Mithrandir> sabdfl: infinity has taken over thunderbird, I think he was waiting for something, but I can't remember what.
<fabbione> jdub: oh i see
<Mithrandir> sabdfl: he should be around soon though, so ask him then?
<maswan> fabbione: nice interview. just remembered one thing for server candy stuff, deadline or cfq as default io scheduler, perhaps? I'm off for bed now though, so just a bit of a placeholder idea to you. :)
<fabbione> maswan: the schedulers are there. user should decide the one he wants
<fabbione> maswan: it's a boot parameter :)
<fabbione> but yes, we could mention it somewhere
<Mithrandir> fabbione: antipacitory isn't a good default choice for servers, imo.
<maswan> fabbione: sure, I know, but isn't part of ubuntuism to provide good defaults?
<elmo> fabbione: IMNSHO anything other than deadline for server is madness
<HiddenWolf> ubuntuism, better watch it, or that'll be in the dictionary shortly.
<elmo> and in any event AS is insane, cfq might be arguable
<elmo> but I really do think choosing deadline as default makes sense for server
<fabbione> ok
* fabbione notes
<elmo> seb128: I guess I should reopen this bug then?
<ericf>  against what package should I file installer-bugs in the dapper flight2 cd?
<seb128> elmo: copy the  " setxkbmap -layout 'ca,gb' -model pc102 -option 'grp:alts_toggle' -print | xkbcomp - :0.0" and the error to a comment ... not sure if it should be open, it's fixed with dapper
<seb128> elmo: depending of if daniels wants to get a fixed version to breezy-updates too
<elmo> yeah, do we want it fixed in breezy tho?
<elmo> there seems to be a lot of angry users
<seb128> would be nice
<seb128> yep, quite a bunch of dups, would be really nice to get it fixed
<elmo> ok, reopened
<seb128> elmo: thanks
<seb128> elmo: could you sync poppler from Debian?
<elmo> seb128: done
<seb128> thanks
<sistpoty> elmo: please sync fpc from unstable, which has been removed from ubuntu. thx.
<uenyioha> does anyone know if there's a problem with this syscall
<uenyioha> getpgid
<uenyioha> i've included the right header file but the compiler keeps throwing an "implicit function declaration" error
<Kamion> elmo: on home directories, at Zeus I used to NFS-share a home directory between maybe 20 or so different machines on about 10 different Unix variants
<Kamion> with some fairly wildly different architectures. worked fine, as long as you don't count the total weirdness necessary in .bashrc to deal with things like getting a freaking sane terminal on HP-UX
<sistpoty> uenyioha: no, works fine here... but I guess that's a little offtopic for -devel
<Kamion> uenyioha: the man page is a little lacking; getpgid() is an extension over some older standards, so you need special feature defines to get it
<Kamion> uenyioha: any of 1) '#define _XOPEN_SOURCE' and '#define _XOPEN_SOURCE_EXTENDED' 2) '#define _XOPEN_SOURCE 500' 3) '#define _GNU_SOURCE' will do the job
<Kamion> uenyioha: see "info libc 'Feature Test Macros'" for more information
<uenyioha> Kamion: thx...it seems to work in a test proggy i wrote
<uenyioha> Kamion: sans the info you just mentioned
<Kamion> it's only a warning, not an error, unless you're using -Werror
<Kamion> and you won't get it at all unless you're compiling with -Werror-implicit-function-declaration (or just -Wall)
<uenyioha> Kamion: yeah thats true...im using -Wall -Werror actually
<Kamion> you have to be prepared to be moderately pedantic then :)
<uenyioha> Kamion: thx...you saved me a few hours of hair pulling
<Kamion> uenyioha: ah, it actually is in the man page, just not in the usual place - look down in the NOTES section near the bottom
<Kamion> I guess they put it there because there are a few alternative ways to get the prototypes
<uenyioha> Kamion: see why mama said always read the notes in the manpage :-)
* lucas sees that ubuntu dapper has both openoffice 2 and openoffice 1.1.3
<lucas> is that on purpose ?
<raphink> huh?
<Amaranth> is one in universe?
<lucas> yes
<Amaranth> there you go then
<lucas> debian's openoffice.org package is 2.0.0-5
<lucas> while ubuntu's is 1.1.5-0ubuntu1
<HiddenWolf> lucas, openoffice.org2 is what you're looking for.
* raphink sees openoffice.org-1.1.5 and openoffice.org2-2.0.1
<lucas> HiddenWolf: I know, I was just thinking that having openoffice 1.1.5 on the mirrors might be useless
<HiddenWolf> people might still want to use it.
<HiddenWolf> they might not think ooo2 is cool, or whatever.
<lucas> also, it's one of the most used packages in universe according to popcon
<Kamion> it's been demoted to universe because Debian still has it; in general we don't go around proactively removing stuff, we just demote it to universe
<lucas> ok
<lucas> but then,what should be done about it ?
<Kamion> lucas: dude, it was in the default installation in warty/hoary ... of course it'll be widely used
<Kamion> nothing?
<lucas> just sync it from debian ? (which would sync 2.0.0-5)
<lucas> ok
<Kamion> I imagine doko wants to handle that fairly carefully
<HiddenWolf> dude, 2 is in ubuntu already
<lucas> HiddenWolf: I know that
<doko> yes, the sync is coming. the reason I still stick to the "2" naming scheme is to provide an update for breezy
<hunger> Why was the chmod 1777 /tmp removed from the bootclean.sh script?
<slomo> elmo: can you please remove the gtk-sharp2-unstable source package? it has been renamed to gtk-sharp2 some weeks ago
* hunger is wondering whether to expect trouble when rebooting since he formats /tmp on each reboot.
<HiddenWolf> Diziet, ping
<hunger> libsane does not upgrade cleanly here since /etc/hotplug.d/usb does no longer exist on my system.
* hunger reboots.
<slomo> hunger: same for /etc/hotplug.d/usb and /etc/sane.d/usb ;)
<Kamion> heh, d'oh, my fault, will fix
* mvo tries to nap a bit until the meeting
* Kamion isn't risking that
<Kamion> hunger: fix uploaded, thanks
<hunger> Kamion: /etc/init.d/rc is borked!
<hunger> Kamion: Shutdown stops in line 210 of said script. The last var used there is undefined and thus the expression does not compute.
<hunger> Kamion: Plus my mounts no longer work, thus my homedir vanished. Might be a local problem though, I am still investigating.
<Kamion> hunger: not my fault
<Kamion> and I'm not in a position to investigate at the moment
<hunger> Oh, one more thing: mdadm complains loudly about the devices it wants to create being there already.
<Kamion> hunger: these are all Keybuk problems; file bugs
<hunger> Kamion: That is a bit hard without a GUI:-(
<hunger> Kamion: malone sucks even more with lynx than it normally does:-(
<ogra_ibook> livecd ? 
<hunger> pam_mount is completly borked as well.
<hunger> ogra_ibook: Nah... I do not want to download and burn that without GUI apps.
<ogra_ibook> oh, you dont have any ...
<HiddenWolf> ouch, ubuntu nearly won the lugradio biggest letdown of the year award. :P
<Kamion> hunger: you shouldn't be filing bugs about Ubuntu main in Malone yet anyway
<hunger> ogra_ibook: So far I had no need for that:-)
<ogra_ibook> oh, yes, that too
<Kamion> they are almost guaranteed to be overlooked
<HiddenWolf> Kamion, if you want to make that clear, put a big red notice up for main packages in malone for now.
<HiddenWolf> otherwise, people will keep doing it.
<hunger> Kamion: Not? Last time I was told to file malone bugs after breezy.
<HiddenWolf> hunger, that _was_ the plan
<hunger> Good to know that! I reported several issues in malone already.
<Kamion> hunger: an announcement will be made when we switch, and bugzilla will be made read-only with a big notice
<Kamion> HiddenWolf: I don't administer Malone and have no particular wish to do so. We'll pick up the bugs eventually
<hunger> Kamion: How about making malone readonly for now?
<ogra_ibook> hunger, its used for universe
<Kamion> hunger: the universe guys would get kind of upset, since they're using it :-P
<hunger> Kamion: Or at least give a warning that it shouldn't be used for main?
<Kamion> hunger: anything cleverer will take away time from the Malone developers that they could be using to finish the transition from Bugzilla.
<hunger> Kamion: Well, at least I do understand now why my bugreports tend to get ignored if I am not pestering people here:-)
<Kamion> I think it's a waste of time tweaking it now because from what I can see the transition plan is fairly close to completion now
<Kamion> it might have made sense to tweak it last year sometime
<Kamion> hunger: the way they didn't get assigned to anyone might have been a clue :-)
<Kamion> or have people auto-subscribed to them, or whatever the Malone terminology is this week ;)
<hunger> Kamion: Well, I used gentoo for a while... never saw a bug getting assigned there;-)
<hunger> Outch... mounting no longer works since I lost the keys to my partitions.
<ogra_ibook> seb128, did the default for the panel clock change ? my date is gone after an upgrade ...
<seb128> nop
<seb128> oh, the default setting
<seb128> yep
<ogra_ibook> ahuman01, k
<ogra_ibook> oops
<seb128> that's an option of the applet, easy to change :)
<ogra_ibook> silly tab completion
<ogra_ibook> yup
<ogra_ibook> i just noticed it
<ogra_ibook> why was it changed ? 
<ogra_ibook> i find the date very helpful there ...
<seb128> probably because it takes some space on the panel which is expensive :p
<ogra_ibook> sure
<seb128> and you don't need the date all the time
<seb128> and the tooltip has it
<ogra_ibook> but one thing i noticed was that windows users are often positively impressed, its a very noticeable difference that you dont have to move your mouse over it to see the date like you have to do in win ...
<HiddenWolf> agreed, having the date there is good.
<ogra_ibook> sad that its gone from the default ... but i agree it takes panel space ...
<seb128> we can still change the default if that's what users want
<seb128> let's wait for some bugs or list mail about that
<ogra_ibook> i dont really care, i'll enable it myself ... i just noticed the recation of some win users 
<jdub> seb128: upstream default change?
<seb128> jdub: yep
<jdub> seb128: let's unfuck that :-)
<ogra_ibook> heh
<jdub> (and flame upstream)
<jdub> seriously
<seb128> 2005-12-30  Vincent Untz  <vuntz@gnome.org>
<seb128>         * clock.schemas.in: don't show the date by default. Fix bug #313524.
<seb128> vuntz !!
<seb128> Untz Untz Untz
<ogra_ibook> lol
<jdub> one of the first things my MIL said when she started using ubuntu on her laptop was, "oh, i like how it shows the date all the time, that is really handy!"
<jdub> vuntz: YOU ARE IN BIG TROUBLE, MISTER!
<jdub> hrm, we should get ubugtu here
<ogra_ibook> *giggle*
<seb128> he wrote
<seb128> "I always wondered why there's the date by default too. So I remove it
<seb128> for now. Let's see if someone is unhappy ;-)"
<hunger> Could someone pretty please fix /usr/bin/mount.crypt to handle LUKS volumes again?
<seb128> Dear Vincent, jdub cried last night because of you
<hunger> I can send a working copy of that script to whoever does it.
* jdub reopens bug
<hunger> It is just two lines that need changing...
<seb128> hunger: speak to who changed it :)
<hunger> seb128: It never worked AFAICT:-)
<ogra_ibook> hunger, open a bug, attach a patch ;)
<seb128> hunger: so why do you say "again" :p
<hunger> ogra_ibook: I opened two for it in malone. They are even assigned to pitti, but he said he does not have the time to look into them right now.
<jdub> seb128: i reopened the bug :)
<hunger> seb128: It used to work for me... but thinking about it I did not use LUKS back then:-)
<seb128> hunger: ping pitti when he's around he did work on g-v-m/luks IIRC
<seb128> jdub: nice comment :)
<hunger> seb128: He said he does not have the time to do it... but I'll pester him some more:-)
<ajmitch> hunger: it's in cryptsetup? if so, that's universe
<seb128> I'm sure ajmitch will fix it for you :)
<ajmitch> so I wouldn't blame pittit for not having time to hack on universe much ;)
<ajmitch> seb128: yeah, I have other cryptsetup bugs, I just started playinh with LUKS a couple of days ago :)
<hunger> ajmitch: It is part of libpam-mount.
<ajmitch> still universe :)
<marcin`> seb128: I vote for clock without date !
<ajmitch> hey dholbach !
<hunger> ajmitch: I got a new cryptsetup init script. Works way better for me... see malone #564
<dholbach> re ajmitch :)
<marcin`> seb128: hiding date is the first thing I always do on 'fresh' ubuntu installation
<ajmitch> hunger: um
<hunger> ajmitch: Aehm... #563
<ajmitch> hunger: surely not 564 :)
<ajmitch> ok, I'll take a look at them
<ajmitch> once I get a new laptop that I can use this usb flash disk with  ;)
<seb128> marcin`: there is no way to have everybody happy on that, that's why that's a setting :)
<ajmitch> marcin`: I love having the date shown, it saves me wondering what month it is ;)
<marcin`> ajmitch: but you always can turn it on...
<Burgundavia> marcin`, options are nice, better defaults are king
<ajmitch> but you can turn it off...
<ajmitch> as Burgundavia says, it's a matter of sane defaults
<ajmitch> I'm crazier than most & have the clock on 2 panels, 1 per screen
<ajmitch> but I doubt we'd have that as default
<marcin`> ok then I know what should you all do :)
<marcin`> write small script that will install with gnome-panel and will report to some remote sever
<marcin`> what users got on their desktops :)
<marcin`> just get their gconf key
<seb128> do a fridge pool :p
<ogra_ibook> yeah
<hunger> ajmitch: You want to checkout malone #6216 and #6257 if you want to play with LUKS and pam_mount.
<ajmitch> I looked at them
<hunger> ajmitch: Just added proper patches.
<marcin`> kind of - something simmilar to ubuntu popularity-contest package
<marcin`> rotfllll :)
<marcin`> because of this discussion I turned on date on my clock applet
<ogra_ibook> mdz, vagrant has some nice modifications to multiarch and some other fixes http://llama.freegeek.org/~vagrant/bzr-archives/ltsp/ubuntufixes/
<marcin`> to see how it looks and.. found "UTC time" option :)
<marcin`> and now I got correct time on my clock :D
<sistpoty> elmo: pleasy sync rfb from unstable, ubuntu override ok. thx.
<Kamion> what's the best glade editor/viewer around at the moment?
<Kamion> I can't get gazpacho to display any tabs of a GtkNotebook other than the first, which makes it unusable for me
<SEJeff> any thoughts on putting libpam-encfs n main for dapper if the broken encfs gets fixed?
<SEJeff> having on the fly home directory encryption is a great feature for laptop users
<hunger> SEJeff: What makes this better then pam-mount?
<seb128> Kamion: glade itself :)
<psusi> I wish someone would build something that could do on the fly file encryption like windows' efs, rather than encrypting the entire filesystem at the block layer
<mdz> devel meeting in 10 minutes on #ubuntu-meeting
<hunger> psusi: reiserfs4?
<psusi> hunger, maybe some day...
<Kamion> seb128: how do you get it to actually display what the glade looks like?
<hunger> psusi: Yeah, I wouldn't trust my data to it at this time.
<Kamion> I'm assuming glade-2 is the same thing here
<hunger> Good night.
<psusi> hunger, I'd use it if it were in the official kernel
<seb128> Kamion: glade-2 ui.glade
<seb128> you have a list of windows from the .glade, double click on one
<hunger> psusi: Not till suse had it as default FS for a couple of month:-)
<SEJeff> psusi, libpam-encfs
<psusi> I make backups, and don't have anything THAT important... I'd love to play with it
<psusi> SEJeff, that encrypts the entire filesystem at the block level
<psusi> doens't it?
<SEJeff> psusi, it encrypts the files and obsfucates the filenames
<SEJeff> psusi, no
<psusi> hrm...
<pitti> hi
<psusi> interesting... I'll have to look at it
<SEJeff> psusi, so that you can do rsync backups on encrypted filesystems that are transparently decrypted when you login through gdm
<mdz> pitti: good morning
* psusi waves at pitti 
<seb128> "morning", hum hum
<pitti> well, "middle of night" :)
<Kamion> seb128: ah, righto, got it, thanks - I was trying to double-click on the widget tree which helpfully does absolutely nothing
<psusi> pitti, hey... can a hal fdi policy invoke an external utility somehow to decide if it should match a rule?  I could probably figure that out of I could find some actual docs on it.. heh...
<seb128> Kamion: np
<ajmitch> hi pitti 
<SEJeff> hunger, I have 0 experience with pam-mount so I can't really tell you. I would just like to see some sort of option in the installer to encrypt each users files to protect files incase of laptop theft
<mdz> 5 minutes
<pitti> psusi: hm, no idea, I never saw such a rule
<hunger> SEJeff: It can be used to mount an encrypted filesystem.
<psusi> pitti, do you know of any documentation for the policy file format, or am I just going to have to dive into the source some more? ;)
<SEJeff> hunger, an encrypted filesystem... thats it's limitation. libpam-encfs encrypts per user, not per filesystem
<hunger> SEJeff: It is actually rather comftable to use once you have set it up. Works no the fs only though.
<hunger> SEJeff: All users are on a separate LVM volume here...
<SEJeff> hunger, so libpam-encfs has a huge anvantage on a multi-user system over it. Unless you make /home/$USER a different volume. that can get ugly
<SEJeff> hunger, I use lvm too, but that is suboptimal
<psusi> hunger, outch.... what a pain
<hunger> SEJeff: How does it protect the user's keyphrases.
<hunger> psusi: Well, there is only me on this laptop plus a couple of test users:-)
<psusi> yea... that means you have to allocate a fixed amount of space to each user... and that filesystem will tend to get fragmented on account of being mostly full
<pitti> psusi: http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD
<SEJeff> hunger, phone call. brb
<hunger> SEJeff: lets talk tomorrow then... awfully late here.
<hunger> Good night everybody.
<psusi> night
<Riddell> Keybuk: what is madwifi-ng and what's the status of network-manager for dapper?
<Kamion> Mithrandir,mdz: direct svn URL to the X->console keymap conversion tool I mentioned is svn://svn.debian.org/svn/pkg-kbd/people/zinoviev/console-setup
<Keybuk> madwifi-ng is the "new" Atheros drivers
<Keybuk> network-manager is currently blocked and "won't go in for dapper" because it doesn't work on Atheros cards
<Keybuk> madwifi-ng *may* solve this, and unblock n-m again
<mjg59> Keybuk: Did you see my pointer to the openhal stuff?
<mjg59> (Probably not useful in this case, but still)
<Keybuk> mjg59: yeah, I've tried openhal before, and it's terrible
<mjg59> Keybuk: Heh. Fun.
<Keybuk> supports fewer cards and features than the real one
<mjg59> Fair enough
<mjg59> If you can try madwifi-ng, that would be ridiculously helpful
<mjg59> We can push it into l-r-m for dapper and see how it goes
<Keybuk> infinity is going to package it up in lrm tomorrowish
<mjg59> Oh, cool
<mjg59> Replacing madwifi?
<Keybuk> yeah
<milli> nice
<Keybuk> (in ~infinity, and then the real archive if testing goes well)
<daniels> hi all
<daniels> Keybuk: (~adconrad, surely)
<fabbione> Keybuk: so it's you i need to blame for the root passwd at shutdown/reboot? ;)
<Keybuk> well, yes, but it's 2:30am here and I'm asleep
<Keybuk> fabbione: apparently; it works for me for some reason *shrug*
<fabbione> Keybuk: do you need the full error
<fabbione> ?
<Keybuk> already fixed
<fabbione> ok
<Riddell> is the hal in openhal anything to do with HAL?
<mjg59> No
<Riddell> thought not, mildly confusing
<pitti> doko: bah, /usr/lib/openoffice2/help/en/smath.idx/DICTIONARY seems to be in all oo.o packages and -help-en-us, so there are a lot of file conflicts. known bug?
<doko> pitti: -0ubuntu3 ...
<pitti> doko: ok, if it's known, great
<pitti> seb128: I saw the new logout dialog this evening; shiny :)
<seb128> yep, it's nice (but still requires some work) :)
<fabbione> doko: dude.. can we have a couple of words? :P
<fabbione> doko: gcc-* + OOo2* can tank my poor buildd ;)
<doko> fabbione: wait with oo*, wait with gcc-4.0/gcj-4.0 for the next upload (amd64 biarch update)
<fabbione> doko: i am already building ubuntu3
<fabbione> same as gcc-4.0 and gcj-4.1
<doko> ubuntu3 should be ok, that will hopefully stay some time
<fabbione> doko: yes, we need to know as well if it is FTBFS
<Mithrandir> mdz: yay, I have a media-integrity-check thingy that works on the live cd as well.
<mdz> Mithrandir: cool
<mdz> Mithrandir: just text output for now?
<Mithrandir> mdz: no, no text output for now.  Just usplash.
<mdz> excellent
<mdz> I thought that was waiting for infinity to get back
<Mithrandir> no, that's for the regular casper initramfs thingy.
<Mithrandir> I'm seriously abusing both casper and usplash here, but it works quite well
<Kamion> you know, doing a really basic espresso-partman integration doesn't actually look that hard at all
<Kamion> even after the first level of analysis
<Kamion> making it fit mpt's proposed UI is trickier, but that's for later ...
<whiprush> Riddell: according to the network-manager list, RH just got a madwifi card /today/ for testing purposes. Pity I missed keybuk.
<Lathiat> whats keybuks email?
<Mithrandir> scott@ubuntu
<Lathiat> cheers
<Mithrandir> grrrr
* Mithrandir kicks usplash in the nuts.
<infinity> Grrr indeed.
<Mithrandir> hiya infinity 
<Mithrandir> how's life?
<infinity> I came home to a shiny new DSL connection that's... Not quite right in the head.
<infinity> But at least it's connected now.
<infinity> Slow.  But connected.
<Mithrandir> infinity: you had some usplash fixes?  I'm pondering uploading a new version, since the current version is broken when you fill the FIFO
<Mithrandir> infinity: so if either you want my fixes or the other way around, that'd be useful.
<infinity> You have a fix for that?
<Mithrandir> yes
<infinity> Yay.
<Mithrandir> I needed it, so I coded it.
<infinity> Just upload.  The archive is our RCS for usplash.  AFAIK, Matt doesn't have a repo for it, and I know I don't.
<Mithrandir> actually, I have two fixes for that.  One correct and one hackish.  The hackish being smaller, but does a lot of 1-byte reads.
<infinity> Correct sounds good to me.
<Mithrandir> true, he doesn't.
<jdub> daniels: do the xorg fglrx drivers not depend on the kernel driver version?
<infinity> No, but they probably should.
<daniels> how?
<infinity> The thing is that the nvidia and fglrx packages build from LRM descended from the seperate Debian packaging efforts of each.  nvidia did the glx->kernel dependency, fglrx didn't.
<jdub> oh, yeah, i meant technically not packagearily :-)
<jdub> they definitely don't with our packages
<daniels> 'yes'
<infinity> Oh.  Technically, they do.  Yes.
<jdub> right
<jdub> hard to do that without pissing people off, though, i guess
<infinity> dpkgily, they don't, but probably should do like the nvidia drivers attempt to (though it's a poor solution anyway, since you can have multiple modules packages installed, providing different module versions, and no guarantee you're booting the right kernel)
<Burgundavia> daniels, is there a known but with i810 not currently doing direct rendering?
<jdub> infinity: mmm.
<jdub> infinity: ugh.
<jdub> infinity: bleh.
<seth_k|lappy> Burgundavia, my fglrx stuff isn't doing direct rendering either, so I suspect it's everything
<daniels> Burgundavia: no
<infinity> seth_k|lappy: No, the fglrx problem is a different issue (and will be fixed in the next upload)
<daniels> seth_k|lappy: errr ... fglrx replaces libGL entirely
<daniels> infinity: don't forget to make it a Suggests, in case they've built their own kernel
<daniels> or Recommends
<Burgundavia> daniels, what sort of debug information do you need?
<infinity> It's a hard dependency in the nvidia case, IIRC.
<infinity> Depends: nvidia-kernel-1.0.8174
<daniels> Burgundavia: LIBGL_DEBUG=verbose glxinfo, look at the first few lines and see if it can't find i810_dri, or if XF86QueryDRICapable returns false, or something else
<daniels> infinity: ugh
<infinity> The theory being that if you installed the glx package, you probably also built the module package.
<infinity> It's always been like that.
<Burgundavia> daniels, I will file a bug tomorrow
<infinity> (note that it suggests nvidia-kernel-source as a big blinking hint as to how to make the kernel-module package)
<daniels> Burgundavia: if XF86QDC returns null, look at Xorg.0.log
<Mithrandir> pretty, pretty progressbar.
<Burgundavia> ugh, this should be simple. How the heck do I rsync the i386 daily install cd again?
<SEJeff> Is the latest kernel update supposed to make the boot not find init :) I guess I am asking if that is a feature rather than a bug
<Mithrandir> Burgundavia: rsync -av --progress cdimage.ubuntu.com::cdimage/daily-live/current/dapper-live-amd64.iso dapper-live-amd64.iso with the obvious substitution. :-)
<Mithrandir> infinity: new usplash uploaded.  I'm off to bed.
<infinity> 'Night.  Thanks.
<Burgundavia> Mithrandir, cheers
<jdub> BYE BYE BASE-CONFIG
<desrt> thank god
<desrt> hello acid-config!
<infinity> Argh, jbailey picked a fine time to leave.
<Lathiat> hrm, upgraded to dapper and my root on lvm doens't come up on boot
<SEJeff> Lathiat, I've had this problem. Want me to walk you through how to access your files?
<jsgotangco> man that update is scary
<SEJeff> jsgotangco, the initial 2.6.15 update when the initramfs was broken was scary
<SEJeff> http://nanokron.info:8000/PICT0004.JPG this is what the latest dapper kernel update did to me
<jsgotangco> woohooo
<jsgotangco> libselinux1?
<ajmitch> jsgotangco: what about it?
<jsgotangco> i just saw it updating now.
<ajmitch> right
<ajmitch> just another sync from debian :)
<infinity> SEJeff: If I had to guess, I'd say it was the klibc update that screwed you, and the initramfs-tools I just uploaded 5 minutes ago will fix it.
* infinity needs to do some reboot testing and stuff.
<jsgotangco> lunch brb
* desrt notices another abi bump, re-re-compiles fglrx
<desrt> ... :)
<jdub> why are you building fglrx?
<daniels> jdub: beta program, I think
<desrt> jdub; so i can use my computer
<desrt> using it with the r300 dri results in some rather fantastic crashing
<jdub> eh, rad, ocean's thirteen to be made
<daniels> so don't use dri
<jdub> wrong channel ;)
<SEJeff> BenC, http://nanokron.info:8000/PICT0004.JPG was infinity correct in stating a klibc update caused this? I'm afraid to reboot right now and don't have a livecd available to chroot/fix things
<infinity> SEJeff: I assume you can still boot with your -10 kernel?
<SEJeff> infinity, I am on the dapper desktop right now and don't have ubuntu installed on my Sparc :) I need x up ATM
<SEJeff> infinity, I'll reboot in a few days
<infinity> SEJeff: If so, download this ( http://people.ubuntu.com/~adconrad/initramfs-tools_0.40ubuntu9_all.deb ), install it, run "sudo update-initramfs -u -k 2.6.15-11-686" and reboot.  The new kernel should boot fine now.
<infinity> SEJeff: Updates won't magically fix your broken initramfs if you're booted into your old kernel, so you'll pretty much have to fix it with a manual "update-initramfs" invocation at some point.
<infinity> (Cause initramfs-tools updates will just update your current RUNNING kernel, which is probably -10)
<SEJeff> infinity, yes, I did that before when the first 2.6.15 fiasco happened
* infinity heads out for lunch/dinner...
<SEJeff> infinity, thanks
<desrt> daniels; as a direct result of me not using dri during the breezy release cycle dri with my videocard was broken for breezy final
<desrt> daniels; everything needs to be tested.
<daniels> the fglrx thing?
<daniels> testing wouldn't have helped much there
<desrt> the mtrr thing
<daniels> ah
<desrt> it went unnoticed because i wasn't using dri
<jdub> infinity: rebooting now :)
<jdub> whoa, fast-boot-a-rama
<jdub> daniels: what do i want, xorg-driver-synaptics, or xserver-xorg-input-synaptics?
<BenC> SEJeff: appears to be correct
<jdub> daniels: 'cos currently i have the latter, but no touchpad love at all
<jsgotangco> wow xorg love
<daniels> jdub: the latter
<daniels> jdub: Xorg.0.log?
<jdub> sec
<jdub> hrm, will have to restart X which will probably result in the machine crashing
<jdub> oh
<jdub> it already has
<jdub> hrm, no it hasn't
<CarlFK> what java package is top of the list for dapper users ?
<CarlFK> as in, which one should get some attention 
<vuntz> jdub: re: "YOU ARE IN BIG TROUBLE, MISTER!"
<vuntz> jdub: the clock change is a test
<vuntz> just to see how I get flamed :-)
<Burgundavia> vuntz, better get out the asbestos suit
<desrt> the clock changed?
<ajmitch> he dared to remove the date
<desrt> oh.  defaults pfah
<vuntz> I DARED!
<vuntz> last time I changed a default for the clock, I got flamed, so I expect some reaction again ;-)
<desrt> i see.
<desrt> time-only is best
<desrt> panel space is precious
<Burgundavia> desrt, umm, how so?
<desrt> anyone in their right mind moves the bottom task-switcher to the top panel so it's best to save space
<Burgundavia> desrt, most users never change defaults
<lifeless> what about people with integrated minds ?
<desrt> right.  as i said.
<desrt> :)
<desrt> alas.  it is getting late.  (twilight to starlight)
<desrt> farewell and goodnight!
<vuntz> desrt: dude, you can't let me be flamed alone!
<lifeless> anyhoo, I only change things when some update borks my settings, which I got happy with in 98 or so
<desrt> vuntz; tell me.  where is your window switcher?
<vuntz> desrt: I don't have a window list. Just the window selector in the top right corner
<desrt> how macos classic.
<desrt> i went through that phase too
<desrt> your panel space is -not- at a premium.  why do you want to eliminate the date?
<vuntz> I used to have a window list in a autohide, but I didn't use it, so I kill it
<vuntz> desrt: never found it useful and the default format is ugly, imho
<desrt> so fix it?
<vuntz> default date format
<vuntz> fix it would make it too long
<vuntz> but that's just my opinion. That's why the removal is a test :-)
<desrt> oh well
<whiprush> let's be honest people. We want the date back because we're all too drunk most of the time to know what day it is.
<desrt> nobody here has any right to flame you
<desrt> after all, you're Upstream :)
<ajmitch> desrt: and upstream never makes mistakes? :)
<ajmitch> whiprush: pretty much
<vuntz> ajmitch: exactly
<vuntz> :-)
<whiprush> as an aside, today when I booted my dapper laptop the ntp thing on boot didn't work
<whiprush> so I was at work until 9pm, thinking it was 7pm
<whiprush> boy ... did that suck.
<ajmitch> aw
<vuntz> ajmitch: you know, I always blame Ubuntu when replying to bug reports ;-)
<Burgundavia> whiprush, ouch. They moved the ntp thing to inside ifup
<desrt> 'packaging error.  file downstream.  FIXED -> INVALID'
<ajmitch> vuntz: sure, blame seb & daniel :)
<vuntz> (and I blame GNOME upstream in Malone/Ubuntu bugzilla)
<whiprush> Burgundavia: looks like I was one apt-get upgrade behind, heh.
<desrt> 'gnome bug.  file upstream.  -> UPSTREAM'
<desrt> vuntz; you must be a very conflicted individual :)
<vuntz> ahah
<desrt> vuntz; did you port the gnome-panel applets to use the new API?
<vuntz> yes
<Mez> hey desrt :D
<desrt> uhoh.
<ajmitch> heh
* desrt restarts panel, tries again.
<ajmitch> hello Mez 
<desrt> Mez; word.
<Mez> hey andrew! hows things?
<desrt> http://en.wikipedia.org/wiki/Orange_Pekoe
<desrt> 'SFTGFOP (Super Fine Tippy Golden Flowery Orange Pekoe)'
<desrt> classic.
<ajmitch> alright
<desrt> vuntz; indeed my fault.  i was running a panel out of /opt
<desrt> everything is copacetic and now i really must go to bed.
<ajmitch> night desrt 
<Mez> ooh, big word
<Mez> night Ryan!
<fabbione> morning
<pitti> Good morning
<pitti> hi carlos 
<carlos> morning
<fabbione> hey pitti
<zakame> elmo: please sync octave2.1 from Sid, overriding Ubuntu ok, thanks :-)
<zakame> heya pitti , carlos , fabbione :)
<floam> holy carpfish
<floam> what's with the new log out dialog?
<floam> I've just got a bunch of buttons, and I can't even tell that they are buttons
<floam> that's got to violate HIG in many ways
<fabbione> floam: welcome to the team :)
<CarlFK> where do I report problems with gij?
<CarlFK> not a ubuntu problem but a .. core? problem
<fabbione> CarlFK: doko
<jsgotangco> hehe
<jsgotangco> its too KDE'ish
<fabbione> M$'ish
<floam> plus these icons looks like they were stolen from XP or KDE or somesuch
<jsgotangco> yeah
<jsgotangco> actually they really do look M$'ish
* floam will have to read up on wtf is going on
<floam> I hope it's a joke or a early prototype or something
<Treenaks> floam: maybe they're tango icons ?
<floam> doubtful
<Treenaks> floam: anyway, I guess it's work in progress
<jsgotangco> yeah
<sivang> morning all
<jsgotangco> the box looks too big too
<jsgotangco> just a proof of concept i guess
<floam> there had better be more than just buttons when it is done, the user has no idea what the dialog does
<floam> and I'm not trying to be rude or anything, I know it's not easy to make stuff
<floam> but it's not like the old dialog sucked
<CarlFK> fabbione: the doko that is here?
<fabbione> CarlFK: yes
* CarlFK pokes doko with a stick
<Burgundavia> Treenaks, not tango
<Burgundavia> floam, see the ubuntu-desktop mailing list
<orhs_> hey guys i need help with this "3com officeConnect wireless 11g pc card" the driver version of the hardware is 3.0.7.2. i use kernel ver 386
<Burgundavia> orhs_, please use #ubuntu , as this is not a support channel
<orhs_> oh srry i must have mistaken :P
<Burgundavia> orhs_, hey, np
<sivang> woof, just finished reading last night's meeting backlog
<jdub> vuntz_: :-)
<Keybuk> my god it's quiet today; I guess 2/3am meetings really take the fighting spirit out of everyone? :)
<zakame> hehe
* pitti yawns while attacking another round of xpdf security updates
<infinity> s,2/3am ,,
<Keybuk> infinity: btw, how are you intended to do splashdown?
<Keybuk> I'm mucking around with /etc/init.d/rc right now and might be nice to get it right
<zakame> wb zyga 
<zyga> morning guys :-)
<Keybuk> infinity: right now, it'll PROGRESS 0 thru 100 for rc0 or rc6
<infinity> Keybuk: Make rc[06]  start at 100 and count backwards.
<infinity> Keybuk: But I was too lazy to do that in the quick "ack, my machine doesn't reboot" upload.
<Keybuk> ok, so you'd like them to go downwards
<Keybuk> infinity: gah, dude!  I was working on that
<Keybuk> *sigh*
<Keybuk> can you close the bug? :p
<infinity> Did I not?
<Keybuk> btw, your fix will make it only do 0 thru 50, no?
<infinity> My "fix" was just a bandaid to make machines reboot without stopping haflway, since that kinda sucked.
<infinity> And yes, it would do 0-50.
<Keybuk> it'd been broken for 3-4 weeks ;)  I figured another few hours wouldn't hurt
<infinity> I only saw it today.
<infinity> Did sysvinit not build until recently?
<infinity> (I update near-daily)
<Nafallo> it was installed for me late yesterday evening.
<zyga> infinity: just curious, what has gone wrong with the reboots?
<Keybuk> oh, you did close the bug ... I was clearly asleep when I read that folder ;)
<infinity> Keybuk: Yeah, it was FTBFS until a give-back yesterday.
<infinity> Keybuk: Hence why it was suddenly an issue.
<Keybuk> ahh
<Keybuk> fair enough, I'll just copy your changelog entry into my upload
<Keybuk> as I've done a merge and most of the s-b changes at the same time too
<infinity> Ahh, cool.
<infinity> Didn't want to step on toes, I just don't dig computers that don't reboot. :)
<infinity> I'm picky.
<Keybuk> about time you fixed one of my bugs, anyway
<Keybuk> after all of yours that I've fixed for you ;)
<infinity> I have big, inviting toes.
* Nafallo have broken one to some days ago :-/
<Nafallo> damn sofa!
<Nafallo> so I have one toe blue :-/
<ogra_ibook> *yawn*
<dholbach> hellas
<Keybuk> morning *hugs*
* dholbach hugs Keybuk
<ogra_ibook> huggers
<Keybuk> infinity, jbailey: for your amusment:
<Keybuk> http://ehlo.org/~kay/?p=linux/hotplug/udev.git;a=commitdiff;h=f75002a3dd39ccc740ac586ef352d3f2a45b2ff4
<infinity> Keybuk: Nice variant of the "replaced with a very small shell script" threat.
<tepsipakki> can I request for another try at building OO.o2 (it failed because of libsane 1.0.17-1ubuntu2)? :)
<Keybuk> libsysfs is evil, I for one would be glad to see it die
<infinity> tepsipakki: It's already building.
<tepsipakki> infinity: ok, great!
<Mithrandir> smurf: do you have any kind of developer docs or something for keymapper?  I need it to give out X11 keyboard map names instead of linux console ones.
<smurf> Mithrandir: that's a question of "you get what you put in"... ideally you'd want to analyze X11 maps instead of console maps
<smurf> code for that should be in there, though I haven't done a particularly good job of understanding X1 keymaps. :-/
<Mithrandir> smurf: hmm, yes, I see that code, but I guess I need to pick more at it to actually understand what's going on in there.
<smurf> Mithrandir: The basic principle is easy -- find out which keys a symbol appears on and how much magic you need to invoke it, put it through the wringer of a "thse symbols look the same" table, generate decision tree
<smurf> the "how much magic" part is important, otherwise I'd ask people for something which is only on shift-altgr-whatever which they have no idea where it is
<Mithrandir> smurf: yeah, I understood that much from the readme.
<smurf> Mithrandir: I don't quite remember how much I actually wrote in there. ;-)
<fabbione> oh boys
<fabbione> installing on USB is SLOOOOOW
<Mithrandir> fabbione: get a faster USB drive?
<pitti> fabbione: even with usb 2.0?
<pitti> fabbione: my old 1.1 stick is indeed slow, but the 2.0 stick of my gf runs nicely
<fabbione> Mithrandir, pitti: it's usb2
<fabbione> still takes too long :)
<Mithrandir> fabbione: *shrug*, I get 15-20MB/sec to my USB2 drive.
<Lathiat> fabbione: you making usb installs work?
<fabbione> Lathiat, usb install d
<fabbione> Lathiat, usb install DOES work
<Lathiat> oh, cool
<fabbione> i need to check a few things
<Lathiat> i thought there was a problem
<fabbione> one: can it boot?
<Lathiat> like not waiting logn enough for root to appear
<Lathiat> and then fails to boot
<fabbione> two: if i move the disk and change the name how bad is going to die
<fabbione> three: how much it takes to fix all of the above
<Lathiat> *and* change the name?
<fabbione> the problem you mention should be already fixed
<fabbione> Lathiat, if you install with one usb device, that one will be named sda for example
<fabbione> if you add another device
<Lathiat> ah right
<fabbione> you have no guarantee that it will still be called sda
<doko> who does take care of php in ubuntu/edubuntu? ogra?
<fabbione> so fstab becomes .. pointless
<Lathiat> thats the point of LABEL based mounting yeah?
<Lathiat> LABEL=/ /
<ogra_ibook> doko, infinity
<Lathiat> can also be an issue if you have two /
<fabbione> we need something more than just LABEL
<Lathiat> could use some kind of random id i guess
<Lathiat> hrm ok
<fabbione> Lathiat, read the specs
<ogra_ibook> if he didnt drop it out of frustration :)
<Mithrandir> Lathiat: all devices have an uuid
<fabbione> s/devices/filesystems
<fabbione> and not all of them
<doko> infinity: what will be the php "default" for dapper?
* ogra_ibook guesses 5 will stay the default
<infinity> PHP 5, as it was in breezy.
<fabbione> hey infinity 
<doko> infinity: 5.0 or 5.1?
<infinity> 5.1.x, I assume.
<infinity> Unless they ship a 5.2 really soon.
<infinity> 5.1.1 is sitting on my hard drive, waiting for me to hit one or two more bugs before I upload it.
<fabbione> aRGH
<fabbione> now i see why it's taking so loooong
<fabbione> all the install was moved to stage 1
<fabbione> ROCKING
<ogra> heh :)
<pitti> saves this incredibly time wasting archive-copier step :)
<fabbione> till you discover that the bootloader is borked :)
<Keybuk> Lathiat: the initramfs will wait up to 3 minutes for scsi disks to settle
<Keybuk> where scsi includes usb storage, firewire and sata these days
<Lathiat> ah ok
<Mithrandir> deboostrap should install the debs in file-system order. :-P
<Keybuk> if only parallel-ide would hurry up and get libata'd
<Keybuk> then we could do away with the nasty CASE/ESAC
<Keybuk> /usr/share/initramfs-tools/scripts/init-premount/udev is farrrr too choicey for my liking
<ogra> Keybuk, btw, could you extend the usplash timeout dynamically in such cases (scsi delay) ?
<Keybuk> ogra: I'm going to ask infinity for a "yeah, I'm still alive" PING command to reset the timeout
<Keybuk> I haven't got around to it yet though
<infinity> There is one.
<ogra> that'd be cool
<Keybuk> oh, there is?
<infinity> Oddly enough, PING works.
<Keybuk> lol
<ogra> hehe
<Keybuk> serves me right for not reading the documentation
<Keybuk> OH WAIT, THERE ISN'T ANY
<Keybuk> <g>
<infinity> (In reality, any command usplash doesn't understand, of which PING is one, will work as a ping)
<Keybuk> rofl
<ogra> wow, you could write little stories in the sourcecode then :)
<ogra> programming arts :)
<Kamion> pitti: archive-copier isn't entirely gone, but now it only copies ship and isn't strictly required; I wouldn't be totally opposed to killing it altogether, but it needs some discussion
<pitti> Kamion: ah, it copies ship - desktop?
<Kamion> pitti: right
<pitti> Kamion: that's nice
<Kamion> hmm, anyone know a way to convert a-z to 0-25 in shell?
<pitti> so actually the CD apt source isn't required any more
<Kamion> or any way to get the ASCII value of a character
<Treenaks> Kamion: od
<Kamion> Treenaks: not available
<janimo> Kamion a very long tr using octal codes?
<dholbach> Kamion: g_ascii_digit_value or in which context do you ask?
<Kamion> dholbach: dude, shell. not glib.
<Kamion> installer context, what else? :)
<dholbach> you were asking about gazpacho yesterday, that's why i asked, dude! :)
<Treenaks> Kamion: no od? hmm.. then janimo's suggestion (though that's potentially not locale-aware)
<Kamion> the only thing I can think of is echo "$char" | case $char in [a-j] ) sed 'y/a-j/0-9/' ;; [k-t] ) sed 'y/k-t/0-9/; s/^/1/' ;; [u-z] ) sed 'y/u-z/0-5/; s/^/2/' ;; esac or something equally gross
<Kamion> don't care about locales
<dooglus> you've got 'sed' but not 'od'?
<Kamion> yes
<dooglus> got awk or perl?
<Kamion> no
<dooglus> bc or dc?
<Kamion> no
<dooglus> echo $((36#a-10)) $((36#z-10))
<dooglus> ==> 0 25
<Mithrandir> not in dash
<dooglus> you don't have bash available?
<Kamion> yeah, looks like a bashism unfortunately, though it's nifty
<Kamion> dooglus: this is in the installer. no.
<Kamion> it's all busybox
<Kamion> I could write a C helper, but it's massive overkill for figuring out the indexes of IDE/SCSI drives from their device names ...
<pitti> Kamion: reading the minor device id isn't sufficient?
<Kamion> pitti: not the partition number - hda -> 0, hdb -> 1, hdc -> 2, etc.
<Kamion> using device numbers for that is a pain
<pitti> right, they mix majors and minors
<pitti> for IDE controllers at least
<dooglus> Kamion: how about this: printf "%d\n" "'a"
<dooglus> prints 97
<Mithrandir> yeah, printf + arithmetic should work
<Kamion> busybox printf doesn't understand that 'a trick
<Kamion> although good try, I'd forgotten about printf
<Mithrandir> or just have a map file you can grep
<Mithrandir> which is just a:0\nb:1\nc:2, etc
<Mithrandir> silly, but should work
<dooglus> Kamion: dash's printf does
<Treenaks> Mithrandir: it's even possible to generate that on the fly
<dooglus> atoi() { echo $(($(printf "%d" "'$1") - 97)); }
<Kamion> partman's nasty enough as it is, but if I have to ...
<Kamion> <cjwatson@cairhien ~>$ busybox printf '%d\n' "'a"
<Kamion> 'a0
<dooglus> Kamion: you said you have 'dash'?
<Kamion> no
<Kamion> busybox ash, which is related but not identical
<dooglus> oh, it was Mithrandir who said that sorry
<Mithrandir> no, I didn't.  I said that $((36#a-10)) didn't work in dash (and thereby wouldn't work in the installer)
<dooglus> how can I get busybox to try this?
<Kamion> apt-get install busybox (on dapper)
<Kamion> or busybox-cvs on breezy
<Mithrandir> it's in /usr/lib/initramfs-tools/bin/busybox in dapper, at least
<dooglus> i tried.  it told me "After unpacking 422MB disk space will be freed."
<Mithrandir> Treenaks: sure, that's easy enough to do.
<dooglus> (on dapper)
<pitti> dooglus: it's designed to save space :)
<Kamion> the ' trick you mention is in POSIX so I could add it to busybox
<Treenaks> we need perl or python in  the installer :)
<Kamion> no, we don't
<janimo> who can delete unused packages from the archive?
<pitti> Treenaks: at least you didn't say 'mono'
<Treenaks> Kamion: it'd solve a lot of issues like this :)
<Treenaks> pitti: ooh! that too! :)
<Treenaks> pitti: shiny
<Kamion> Treenaks: and make many more issues a lot worse
<janimo> I'd like xffm4-icons to be removed, it confuses some users
<Treenaks> Kamion: hmm.. yeah, lowmem would be impossible
<janimo> elmo, if it's you who deletes packages from the archive please do so with xffm4-icons. It is replaced by a newer package and some users still try to install it and then file bug reports. thank you
<Kamion> right, I'm just going to make busybox printf support the syntax dooglus suggested, thanks
<pitti> Riddell: btw, please do test all the demo exploits Chris provided - I had to modify the patch for xpdf a bit
<jbailey> Keybuk: Nice. =)
<zyga> mvo: new update manager? :)
<mvo> zyga: yep, some fixes
<irvin> mvo, looking forward for your scripts for nonbroadband users
<fabbione> hey jbailey 
<mvo> irvin: thanks, it's in dapper 
<mvo> at least a simple version :)
<irvin> package name?
<mvo> irvin: it's part of synaptic, File/Generate package download script
<irvin> i see
<zyga> mvo: msgid "http://packages.debian.org/changelogs/pool/%s/%s/%s/%s_%s/changelog" is this supposed to be translatable?
<zyga> (from u-m)
<mvo> irvin: you can later import the stuff File/add downloaded package
<mvo> zyga: right, we talked aobut it
<mvo> zyga: needs to be fixed
<mvo> zyga: the idea was to make it possilbe to have translated changelogs some day. but that's not going too happen too soon :)
<mvo> maybe/probably never
<zyga> ah, remember that 
<zyga> okay
<mvo> I think I'll just remove it again for now
<zyga> mvo: I'll send you updated pl.po, please wait
<mvo> zyga: great, thanks
<jbailey> Heya fabbione!
<sivang> hey jbailey , morning =)
<jbailey> Heya Sivan!
<ogra_ibook> Keybuk, before i forget about it: https://wiki.ubuntu.com/ThinClientAudioSupport and the implementation is on: http://people.ubuntu.com/~ogra/bzr-archive/ltsp/sound/
<fabbione> Keybuk, is there are a reason why initramfs doesn't include USB storage modules?
<fabbione> ^ jbailey for you too :)
<Lathiat> so it *doesnt* work? ;p
<ogra_ibook> fabbione, it does ? 
<jbailey> fabbione: I think it used to.
<ogra_ibook> it still does ...
<ogra_ibook> at least it did yesterday
<fabbione> no it doesn't
<fabbione> otherwise my scsi devices would come up
<fabbione> scsi/usb...
<ogra_ibook>         for x in md raid0 raid1 raid5 raid6 ehci-hcd ohci-hcd uhci-hcd usbhid usb-storage ext2 ext3 isofs jfs nfs reiserfs xfs af_packet dm_mod; do
<jbailey> fabbione: It could be that they're there and not being plugged correctly.
<ogra_ibook> looks like it does 
<fabbione> jbailey, what do i need to look for?
<ogra_ibook> /usr/share/initramfs-tools/hook-functions has the module code
<ogra_ibook> look if your initramfs.conf shows something different to MODULES="most"
<jbailey> fabbione: Unpack it, see if the module is there.  Otherwise, have to poke keybuk.  I don't yet understand the new udev setup enough to guide you.
<fabbione> jbailey, ok
<Kamion> anyone know how to convert from /dev/sd* device node names to SCSI bus/target/lun?
<Kamion> I'm assuming the host is just the index (sda => 0 etc.), but would welcome correction if I'm wrong
<jbailey> Kamion: I don't think lanana naming has lun.
<fabbione> Kamion, hmm not sure..
<Kamion> hmm, I think I'm wrong about the host too
<fabbione> jbailey, usb-storage is not loaded.. otherwise it works.
<Kamion> jbailey: I know it may not be encapsulated in the name; looking it up in /proc or /sys is fine
<fabbione> Linux ultra60 2.6.12-9-sparc64 #1 Mon Oct 10 11:02:28 UTC 2005 sparc64 GNU/Linux
<fabbione> new sparc up and running!
<jbailey> fabbione: I don't suppose this one has less than 2 seconds of latency to get to it? =)
<fabbione> jbailey, it's about 20 inches far away from the other one
<jbailey> fabbione: The one in your bedroom, or the one in North America? =)
<fabbione> the one in my bedroom :)
* hunger always wanted to have a sparc in his bedroom too.
<fabbione> hi zuk
<fabbione> zul
<fabbione> Dear Zul, please grub not to suck as an hoovering machine
<fabbione> +fix
<fabbione> kthxbye
<janimo> do auto-syncs from debian happen with predictable schedule at certain hours?
<zul> fabbione: whats wrong with grub, grub is your friend
<Kamion> looks like basename "$(readlink -f /sys/block/$name/device)" is my friend
<pitti> Riddell: ping
<pitti> BenC: are you here?
<nequeo> Is anyone else completely unable to run anything Firefox/Mozilla related under Dapper?
<Treenaks> nequeo: remove the mozilla-firefox-locale-* packages and it'll magically work
<pitti> nequeo: let me take a guess - you have installed a language pack?
<nequeo> It's gone.
<nequeo> Still doesn't work.
<dholbach> Any held-back packages?
<pitti> nequeo: blame Diziet then :)
<nequeo> Not at the moment, no.
<nequeo> Ephiphany doesn't run. Mozilla-browser won't install at all.
<nequeo> If it's a language pack problem, would I see error messages?
<Treenaks> nequeo: just a window with an XML error
<pitti> nequeo: yes, there should be a yellow error box
<nequeo> Then it ain't that.
<nequeo> I get nothing. 
<pitti> nequeo: try to run 'firefox' in a console
<nequeo> Fails silently after about half a second.
<pitti> nequeo: the output could point to the reason
<Riddell> pitti: hi
<nequeo> If I run /usr/lib/mozilla-firefox/firefox-bin directly it complains it can't find libmozjs.so  
<pitti> Riddell: I'm almost done with the xpdf/poppler/cupsys/tetex-bin patch-o-rama; what's the status of koffice/kdf?
<nequeo> Which is sitting there in the same directory.
<pitti> Riddell: do you want to do this soon and do a common USN, or a followup USN with the KDE packages?
<nequeo> If I create a symlink to it in /usr/lib it complains about other missing libs. If I symlink them all then it, once again, just fails silently with nothing printed to the console.
<pitti> Riddell: (btw, those xpdf itches really piss me off... :( we should make sure to build everything against poppler in dapper)
<Riddell> pitti: still working on it, ok to wait a couple of hours?
<pitti> Riddell: yes, sure
<pitti> Riddell: do the exploits work for you?
<Mithrandir> pitti: can you please tell me what AltGr-q and AltGr-o outputs on your box?  (In X)
<pitti> Mithrandir: AltGr+Q == @
<pitti> Mithrandir: AltGr+O == 
<pitti> Mithrandir: (that's de-nodeadkeys)
<pitti> (but I normally use us layout)
<Riddell> pitti: still testing, sorry been busy with kubuntu CDs this morning
<pitti> Riddell: oh, I didn't want to hurry you, I just want to know the schedule :)
<Kamion> Mithrandir: I think it might be a good idea to preseed cdrom-checker/start=true for the check boot option; do you agree?
<Riddell> pitti: I can confirm that all those PDFs do nasty things, I'll get on with the patches
<Mithrandir> pitti: excellent, thanks.
<Mithrandir> Kamion: agreed.
<Kamion> also a shame that it flickers so much with long filenames due to the dialog box size changing; perhaps it might be a good idea for cdrom-checker to list only the basename
<Kamion> although I guess that doesn't give you so good an indication of how far through the disk it is
<Mithrandir> the progress bar should give you that. :-)
<Kamion> Mithrandir: actually, rather than me doing that preseed in the boot option, perhaps just do it in cdrom-checker-menu
<Kamion> true that :)
<Mithrandir> I'll look at it, but not now.
<Kamion> sure, no rush
<pitti> Riddell: *all*? bad6 and bad7 were already fixed by the previous patches in xpdf and poppler
<Mithrandir> Kamion: please do file a bug and assign it to me, though
<Riddell> pitti: all bad for original breezy, those two are fine for current breezy-security but that patch from KDE is against the original
<Kamion> Mithrandir: done for the menu confirmation question; the flicker is already filed upstream
<Mithrandir> Kamion: good, thanks.
<pitti> Riddell: ah, I see
<pitti> Riddell: that sounds correct
<janimo> elmo, please sync thunar and orage (both NEW for ubuntu) from sid. thank you
<elmo> janimo: you don't have to ask for NEW to ubuntu packages to be synced, it's done semi-automatically
<tseng> yay thunar
<janimo> elmo, ah ok. I knew they are in sid but still did not show up so I was wondering what is wrong with them
<zakame> w00t
<janimo> elmo, if you have time , jani@ubuntu.com GPG-key for main. thanks
<elmo> janimo: right, sorry
<janimo> pitti, I am sure you too are very busy, but if you can estimate when you have time to review some of the xfce packages in the queue would be nice. You can do just one a day, fine with me  ;)
<pitti> janimo: right, I'm swamped in security updates ATM; I'll promise, I'll try to get better :)
<janimo> ok, thanks
<Riddell> pitti: apparantly poppler with kpdf is not hard, but will add back rendering bugs they've fixed https://bugs.kde.org/show_bug.cgi?id=119455
<Riddell> pitti: and poppler with kword is hard beause it uses xpdf 2 and poppler is xpdf 3
<pitti> 2???
<pitti> OMG
<pitti> Riddell: can't we fix the rendering bugs in poppler then?
<pitti> and for kword it seems that upstream needs a serious kick then?
<Riddell> pitti: as that bug says he has trouble getting the other poppler developers to agree to changes
<Riddell> pitti: and I don't think that import filter for kword has a maintainer
<pitti> Riddell: if that's difficult, we could at least apply the fix in Ubuntu and Debian
<seb128> Riddell: if there is some rendering bug, poppler upstream will agree they need to be fixed for sure, no?
<pitti> Riddell: fixing rendering bugs would be beneficial for evince, too
<Riddell> you would think so
<Riddell> I don't know the specifics of what he's tried to get in
<seb128> that's some subjective rendering difference and they don't agree that's a bug?
<pitti> I talked to the poppler people this morning, they seemed to be pretty open
<seb128> they are usually
<seb128> pitti: BTW they took the poppler-utils change we have upstream
<pitti> yes, they told me
<pitti> seb128: also, Ondrey already fixed Debian (he applied my patch within 2 hours or so :) )
<seb128> pitti: yeah, we have talked on #gnome-debian about using splash or cairo too
<pitti> Kamion, Mithrandir: do you have a minute for a small sudo security discussion?
<Keybuk> fabbione: usb-storage gets loaded by modules.alias iirc
<ryanpg> quick question, xserver-xorg seems to depend on xserver-xorg-driver-*, is it the goal to eventually be able to install only the drivers needed for specific hardware? should I file a bug/feature request or am I jumping the gun...
<doko_> Kamion, mdz, elmo: please promote gcj-4.0-base to main. this is fallout from the gcc-4.0/gcj-4.0 package split
<Riddell> pitti: hmm, the kpdf patch for breezy only fixes bad6 and bad7, the rest are still affected
<pitti> Riddell: that's what I meant, I had to do a slightly different patch for xpdf and poppler
<pitti> Riddell: can you please compare it with https://bugs.freedesktop.org/attachment.cgi?id=4247 ?
<pitti> Riddell: (that patch is relative to the previous patches CVE-2005-3191/2/3)
<pitti> Riddell: and it's the patch against poppler, but it shouldn't really matter
<pitti> Riddell: this is the patch I sent to the poppler upstream guys
<Kamion> pitti: yes, although I'm rather behind since I didn't really follow the last discussion in the TB
<pitti> Kamion: oh, it's an entirely different topic :)
<pitti> Kamion: I just fixed a sudo vuln in stables that filter out PERLLIB, PERL5LIB, RUBYPATH, etc.
<pitti> Kamion: i. e. when granting limited sudo access to perl or ruby scripts, setting these variables to own libs woudl give you full root access
<pitti> Kamion: for stables I just filtered out a whole bunch of perl, python, ruby, zsh variables, but this is pretty silly
<pitti> so for dapper I tend to use Joey's approach of a whitelist
<pitti> http://bugs.debian.org/cgi-bin/bugreport.cgi/x?bug=342948;msg=20;att=1
<pitti> Kamion: i. e. he filters out all but a small set of known good variables
<pitti> Kamion: do you see any potential breakage in this? it's too hot for stable updates, but for dapper it coudl be worthwhile
<pitti> Mithrandir: ^ in case you want to read it, too
<pitti> slomo: 'check' - what a dull package name...
<slomo> pitti: not my fault ;)
<pitti> I know :)
<Kamion> pitti: it would be real hassle for me; I often do 'SOME_RANDOM_VARIABLE=foo sudo blah' when testing things, and I'd be amazed if I were the only one
* Keybuk does
<Kamion> it would piss me off mightily if sudo started filtering that
<pitti> sudo env VAR=foo bla?
<pitti> well, anyway, I see the point
<pitti> but this way it's just playing catchup with programming languages
<Keybuk> does LD_LIBRARY_PATH=... sudo work?
<Kamion> I suppose that works, and I can see the argument; but if sudo goes this way it would be nice for it to have a way to disable it if you have sufficient sudoers power
<pitti> Kamion: bdale changed Debian to use 'reset_env' by default when creating a new /etc/sudoers, but that will probably never apply to us, I guess
<Kamion> oh, if it's a switch in sudoers then that would be ok
<Keybuk> *nods* if it's a switch, I can just turn it off <g>
<Keybuk> or, more likely, train myself to use sudo env instead
<Keybuk> though doesn't that have exactly the same flaw?
<Keybuk> oh, I guess you wouldn't give people access to run env :p
<pitti> Keybuk: yes, all LD_* variables are killed
<pitti> Keybuk: that would be a feature
<pitti> Keybuk: with unlimited access, variable filtering is no issue anyway, and with limited access you probably want to keep it limited :)
<Keybuk> is there any particular reason it filters if you have blanket root anyway?
<pitti> i. e. not allow to circumvent it
<pitti> Keybuk: no
<pitti> Kamion: just if you restrict access to e. g. a Perl script
<pitti> then creating your own library with the same name as a module that is included by the script, and passing the path to it to PERL5LIB would give you r00t
<Keybuk> giving most perl scripts any input containing ` gives you root :p
<pitti> Kamion: do you how and where the initial user is put into sudoers?
<pitti> Kamion: if we don't use whitelisting, I would at least go with bdale's approach and enable reset_env for new installs
<Kamion> pitti: formerly passwd.config, now user-setup
<Kamion> pitti: I don't see the point; the initial user is given ALL=ALL anyway
<pitti> Kamion: hm, that sounds as if it would create the file before sudo's postinst runs?
<mdz> Kamion,pitti: I'd say that sudo should filter the environment only if the command is restricted
<Kamion> no, it's run from prebaseconfig well after the base system is installed
<pitti> ok
<pitti> mdz: sudo doesn't support that ATM :(
<Keybuk> hmm, you said it filters zsh stuff?  that would annoy the hell out of me ... I use sudo -s a lot, and expect all my zsh gadgets to work there too
<pitti> bah, there are just too many ways to shoot yourself in the foot
<pitti> Keybuk: NULLCMD, READNULLCMD, ZDOTDIR, TMPPREFIX - these are the variables that will now be filtered; would that affect your use case?
<mdz> pitti: sudo -s will do what he expects unless HOME is changed
<Keybuk> ZDOTDIR would
<mdz> Keybuk: you set it to something other than $HOME?
<Kamion> doko_: gcj-4.0-base promoted
<Keybuk> mdz: I had problems with sudo changing HOME on me ;)
<Keybuk> sudo -s would have HOME=/root for some reason
<Keybuk> which meant all my zsh gadgets went missing
<Keybuk> it doesn't seem to currently though
<pitti> Keybuk: but changing HOME is a feature, not a bug...
<mdz> mizar:[/tmp]  sudo -s
<mdz> Password:
<mdz> mizar# echo $HOME
<mdz> /home/mdz
<mdz> it's always done that
<janimo> elmo, I still get REJECT from main upload, key C5AA2301. Does it take more time after you enable it?
<pitti> Keybuk: otherwise you probably want sudo -s, not -i
<Diziet> For unrestricted sudo you want `really' which is far simpler.  For restricted sudo you need userv, because restricted sudo is like a swiss cheese.
<mdz> -i changes home
* Diziet whistles in the wind.
<Keybuk> pitti: I still don't see why sudo feels the need to fuck up my environment if I have effective root access anyway
<Keybuk> sure, I could put some elaborate hack with ZDOTDIR to run something as root ...
<Keybuk> ... or I could just sudo and do it
<pitti> Keybuk: erm, what mdz says; I swapped that
<mdz> Keybuk: yes, ideally it shouldn't mess with the environment unless you're only privileged to run certain commands
<mdz> I'm amazed it doesn't work that way already
<pitti> but such changes are not really appropriate for stable-security...
<mdz> the fact that it's using a whitelist fills me with dread
<Keybuk> I can definitely understand and support an environment whitelist for "sudo foo" if you're only allowed to run foo
<mdz> er, blacklist
<Keybuk> but not if you're allowed to run anything ;)
<Kamion> lamont-away: can you give-back openoffice.org2 please? it only failed due to my libsane screwup
<mdz> Keybuk: that's what I said (both times)
<Keybuk> mdz: then we agree ;)  you take his arms, I'll take his legs ... the canal beckons
<pitti> mdz: well, at least I'd like to fix stables soon, and my current patch just extends the blacklist; I think we won't get around with doing even less
* pitti runs
<mdz> pitti: yes, for stable
<mdz> pitti: but we should fix it forever for dapper
<pitti> mdz: agreed - whitelist for limited access, unfiltered for unlimited access
<fabbione> Kamion, Keybuk, mdz: can we have a very fast meeting for booting-from-usb ?
<mdz> this gives me a chilly feeling about sudo upstream
<mdz> fabbione: ok
<Kamion> sure
<fabbione> #ubuntu-meeting?
<Keybuk> fabbione: sure
<fabbione> great
<pitti> hi jdthood, how are you? happy new year
<jdthood> pitti: Cheers to you too!
<janimo> elmo, please sync newer thunar from debian (looks like it entered after todays autosync although the date is Jan 4).Anyway it fixes an amd64 FTBFS. thanks
<elmo> janimo: please stop asking me for no-op syncs
<elmo> thunar is unmodified, it'll be synced automatically as when the archive can
<elmo> and try your main upload again, it really should work now
<janimo> elmo, ok. I checked to make sure it's not a no-op. debian has newer version here http://ftp.debian.org/debian/pool/main/t/thunar/
<janimo> theirs is -3 ours -2
<elmo> janimo: dude, it's no-op
<janimo> meaning?
<elmo> unless there's an 'ubuntu' in the version, it'll be automatically synced
<elmo> there's no ubuntu in the version ==> you don't need to ask me to sync it
<janimo> ok, I asked because I wanted it now :)
<janimo> so I don't modify something in it (fix FTBFS) and then have to ask for override anyway tomorrow
<janimo> I misunderstood what you meant by no-op
<elmo> you can't have it now
<elmo> debian's key changes have broken the sync scripts
<elmo> just assume it'll be synced eventually, and move onto something else
<janimo> ok, thanks
<Diziet> Where can I find where Gnome keeps its mapping from file extensions to mime types ?
<Diziet> Something thinks that a `.deb' is an `application/x-deb'.  The canonical and obviously more correct answer seems to be `application/x-debian-package'.
<Keybuk> /etc/mime.types
<Diziet> Nope, looked there.
<Diziet> That has the right info.
<Diziet> But in Nautilus, right-click menu / Properties, I see the wrong MIME type.
<Diziet> In fact I grepped /etc.  I could grep /usr too ...
<Diziet> And there isn't already a database of `safe' mime types, is there ?  Ie, ones that we can safely double-click on in Nautilus or `open' from a browser, without executing them.
<Keybuk> Diziet: shared-mine-info package?
<janimo> does not use fd.o mime info?
<janimo> in  /usr/share/mime/packages/freedesktop.org.xml
<Diziet> Ah yes, there it is.  Excellent.  Now I know where to fix that one :-).
<Diziet> Dammit, how do I make a file un`open'able in Nautilus ?
<Diziet> I mean, I want to fool Nautilus into thinking it doesn't know how to open it.
<Diziet> Or some other technique would be OK too, but the user still has to be able to copy the file about
<Keybuk> properties, remove all the apps associated with it?
<HiddenWolf> Keybuk, I don't think you can remove the default when there is no other app set.
<Diziet> This is getting quite out of hand.  I wanted to defend the user from unwise clicking.  Ie, make it impossible for the user to install or execute software just by constantly clicking on stuff to `see it'.
<Diziet> So eg if you visit a page which has some executable on it, you can't execute it by downloading it and then double-clicking on the copy on the desktop.
<Diziet> But to do this properly will need serious effort.  Eg, what if it's in a zipfile ?
<Diziet> Maybe MAC labels would do it.  How about it ?  Everything from the web (and we patch the mailreaders too) gets tagged with `may not be opened other than by blessed programs'.  That'd put a spanner in the `rich user experience'.
<Diziet> I think I'll go back to solving solveable bugs.
<Keybuk> Diziet: you shouldn't be able to anyway
<Keybuk> the executable won't be, err, executable
<Keybuk> if it's a zip file, or some other file handled by an application, what's wrong with it being opened
<Keybuk> if I downloaded a jpeg, and couldn't double-click it to see the porn in better detail, I'd get annoyed
<Diziet> Right.
<Diziet> But there are file types that don't need to be +x to be `executed'.
<Keybuk> there are?
* Keybuk can't think of any off-hand
<Diziet> For example, application/x-debian-package.  Which is only safe because in our firefox the debian-view program runs in the terminal where you can't see it, and Nautilus gets the file type wrong and runs file-roller on it which can't cope.
<Keybuk> if you really want to fix a major bug, you can fix the one where you can get a user to download a .desktop file that can run anything
<Diziet> Right.  That's another example.
<Keybuk> Diziet: I thought mvo had written a program to run on those
<Diziet> keybuk: mvo> I wouldn't be surprised, but it's not plubmed in.
<lamont-away> Kamion: given back
<Diziet> But you hardly want it to pop up a thing offering to install it !
<Kamion> lamont-away: thanks
<Keybuk> why not?
<Kamion> Diziet: I've been arguing that with people for the last year and a half
<Diziet> Because the user thinks that `click' means `show me what this is'.
<Keybuk> afaik mvo's thing tells you what it is, and offers to let you install it if you type in your password and ignore all of the "THIS IS DANGEROUS" signs
<Diziet> And always answers `yes' to all confirmation dialogues because they're always `[Yes]  (work) or [No]  (don't work)'
<Keybuk> there's lower hanging fruit
<Keybuk> the .desktop problem is a real one
<Diziet> It's the _same problem_.
<Keybuk> no it isn't
<Keybuk> the .desktop one is that nautilus has built-in handling that assumes they're all safe
<Keybuk> and that they can be customised to look like whatever you want
<Keybuk> like innocuous text files
<Keybuk> that's a problem
<Diziet> Yes, it is.  The problem is that you can download some random file and firefox (which is what knows that it's not safe) ought not to leave it lying around in a way that clicking on it is dangerous.
<Keybuk> the fact that files can be opened with helper programs is not a problem, that's design
<Diziet> Obviously whether a file is dangerous depends on the file.
<Keybuk> if we have file-type helper programs that act immediately, that's the bug
<Diziet> In particular, it depends on what Nautilus will do when the user clicks.
<Keybuk> not that you can double-click files and have the right program loaded for them
<Diziet> Err, I'm not saying you shouldn't have the right program run - if the file and the program is supposedly safe.
<Diziet> Eg, an image viewer.
<Diziet> We consider it a security bug if an image viewer executes the image.
<Keybuk> what isn't safe though?
<Diziet> There has to be a whitelist.
<Keybuk> the mime type handling list is the whitelist
<Mithrandir> pitti: (I was off eating dinner)  I do FOO=whatever command once in a while and it would be very annoying if that broke, like Colin said.
<Keybuk> we just shouldn't put dangerous things in that
<Diziet> But it's full of stuff like `run wine on this .exe'.
* mvo just noticed his nick highlight and would like to add that there is a deb-installer available now
<Keybuk> now that's a valid bug ;)
<Diziet> But if you have the .exe installed on your machine and double-click on it it _ought_ to run it with Wine !
<pitti> Mithrandir: <pitti> mdz: agreed - whitelist for limited access, unfiltered for unlimited access
<pitti> Mithrandir: do you agree with that?
<slomo> wine on every *.exe is wrong anyway
<Keybuk> Diziet: perhaps you could hook the nautilus "this file may be unsafe, do you want to FOO or BAR thing?"
<Keybuk> it does that for shell scripts, etc.
<Keybuk> lets you open them in a text editor instead
<Mithrandir> pitti: that works for me, since I have full access where I have sudo, at least generally. :-)
<Kamion> .exe files should just be made executable and use binfmt-support
<Diziet> keybuk: How can I signal to it ?
<Keybuk> dunno, sure it's possible
<Kamion> then if you drop the MIME handling for them, non-executable .exe files are safe
<pitti> Mithrandir: I also did a followup to http://bugs.debian.org/342948
<Kamion> and executable ones work as expected
<Diziet> kamion: That would be a reasonable approach.
<Keybuk> Kamion: that's how you have to do it for the mono ones already
<Kamion> Keybuk: indeed so
<Diziet> So 18701 is a bug in the wine package ?
<Kamion> Diziet: in whatever does the MIME handling, I'd've thought
<Diziet> Err, wine presumabely specifies its own mailcap entries or what have you.,
<Kamion> I don't know the layout
<Kamion> but if so, I'd think so, yes
<Diziet> What's the mime type of a .desktop file ?
<Keybuk> there isn't one, is there?
<Keybuk> that handling is hard-coded into nautilus
<slomo> application/x-desktop
<Diziet> Firefox ought to think harder about the extensions on files it downloads, anyway.
<Mithrandir> Keybuk: except that the dialog is stupid enough that it can't differentiate between "shell script" and "text file which accidentially got its executable bits twiddled", so it gets annoying after a while.
<Keybuk> Mithrandir: didn't they fix that?
<Keybuk> would be easy enough, open it, read(,2) and strcmp("#!")
<Kamion> Keybuk: help, udev-udeb seems to be linked against libsepol1
<Runix> hi
<Runix> i would like to say thank to Mark Shuttleworth
<Kamion> udevplug: error while loading shared libraries: libsepol.so.1: cannot open shared object file: No such file or directory
<Keybuk> Kamion: yes, it would be
<Runix> can i ask?
<Keybuk> selinux dragged it in as a new dep
<Mithrandir> Keybuk: possibly, I just know I've been annoyed aobut it in the past.
<Kamion> Keybuk: udev-udeb shouldn't be linked against selinux though
<Keybuk> Kamion: meh, that'd involve compiling udev twice, differently
<Keybuk> and I'd hate you for that
<Keybuk> and sulk
<Keybuk> and stuff
<Kamion> Keybuk: yes; I'd hate you for having to put together selinux udebs for no reason though
<Runix> i'm italian ubuntu user
<Keybuk> isn't there an selinux udeb? :p
<Keybuk> after all, udev-udeb has always needed that anyway, no?
<Mithrandir> Runix: talk to sabdfl, then.
<Kamion> Runix: he may not be around, but we can always accept your thanks on behalf of Canonical, I suppose :)
<Kamion> Keybuk: never has before
<Mithrandir> Kamion: he's in the channel, at least.
<Keybuk> has since UBZ
<Runix> i don't speak english very well
<Runix> sorry
<Kamion> Keybuk: no, it really hasn't
<Kamion> this is new breakage
<Keybuk> Kamion: it deps on sepol, but not selinux?
<Runix> yes
<Keybuk> this could be just shlibs breakage
<Runix> i say tahnk you for all team around ubuntu
<Kamion> Keybuk: hmph, it does seem that it's been depending on selinux for a bit, but not actually caring that it isn't there
<Kamion> OH
<Kamion> headdesk
<Kamion> d-i is pulling in libselinux.so.1 from the .deb in its initrd build process, because it's clever that way
<Keybuk> I think it's been depending on both for ages ;)
<Kamion> yeah, sorry, you're right
<Runix> i would like to see in ubuntu desktop a program like yast
<Runix> why is not possible?
<Kamion> Runix: we like to maintain only one program for each task where possible; in this case, we'd prefer to put effort into improving gnome-system-tools.
<daq4th> and the only thing in yast which works is the frontend ...
<Keybuk> Kamion: I could make a no-selinux compile for the udeb ... but I've so far been cautious about making custom compiles for things, as it means they behave slightly different
<Keybuk> having the same udevd in the initramfs, main system and installer has been a bonus for debugging
<Kamion> Keybuk: ok, it would be absolutely lovely to fix this, but in the meantime I can sort of work around it I think
<Keybuk> there's no clean way to package it though :-/
<Keybuk> you can't out-of-tree build udev
<Kamion> this is why the Debian package does that hardlink tree thing
<Keybuk> which means you need to make clean, and make again in one of the binary targets
<Keybuk> which SUCKS
<Runix> thank you Kamion, there is a fronted like yast on ubuntu?
<Keybuk> I'd be more tempted to just disable selinux in general :p
<Runix> i mean control center for hardware
<Kamion> Keybuk: or you could copy the whole source tree
<Keybuk> that seems ugly to me
<Kamion> so does installer code depending on selinux ...
<Kamion> the hardlink tree thing seems to work fine in Debian though
<Keybuk> the Debian package is dbs, remember
<Keybuk> so has the tarball inside it, and can just unpack two build trees
<Kamion> it doesn't rely on that for the udev-udeb build though
<Keybuk> doesn't it, can't say I've looked for a while
<Kamion> it has an lndir.sh script which builds a hardlinked copy of the source after unpacking the upstream tarball and patches and such
<Keybuk> hmm
<Keybuk> I'd actually have to rewrite the entire source anyway
<Kamion> Runix: I'm not familiar enough with YaST to answer that, I'm afraid
<Keybuk> I hate d-i
<slomo> was debhelper or better po-debconf broken earlier today and is this fixed now (i can't reproduce it at least)? fontforge and theora failed because of it " debhelper: Depends: po-debconf but it is not going to be installed"
<Keybuk> it's soo damned invasive to other packages
<Kamion> Keybuk: why a rewrite?
<Keybuk> Kamion: because I build the udeb by copying things out of the real one's tree
<Keybuk> I'd have to rewrite it to run make install, and copy them from the source tree
<Kamion> so you'd have to rewrite debian/rules, yeah
<Keybuk> meh
<Keybuk> this seems like TOO MUCH WORK
<Kamion> or at least the udev parts of it
<Keybuk> I'm so just going to disable selinux
<Keybuk> we don't use it anyway
<Kamion> don't the selinux guys need udev to support it?
<Keybuk> probably
<Keybuk> but then won't they also need the installer to support it?
<Kamion> no
<Kamion> at least nobody's ever said that, and I can't see why they would
<Kamion> I'll just shove workaround build-deps in d-i for now
<Keybuk> dunno
<Keybuk> I know more about the ancient marital practices of outer-mongolian tribes than I do about selinux
<Kamion> cool
<pitti> btw, am I the only one who loves nickserv messages? "[pitti]  has been killed"
<dilinger> pitti: noticing the latest sudo update.. why doesn't sudo just filter all variables except those it considers valid, instead of the other way around? :P
<pitti> dilinger: I love you for that statement :)
<pitti> dilinger: for stables it's too hot, but I'd love to go this way for sid and dapper
<Kamion> dilinger: we discussed that above ...
<pitti> dilinger: please write that to Debian #342948 :)
<dilinger> Kamion: hm, no longer in my scrollback buffer :/
<doko_> Kamion: are you going to upgrade groff before UVF?
<Kamion> doko_: no, see Debian bug #196762, please leave it
<Kamion> unless you fancy helping to forward-port the Japanese support patch of course ...
* mvo goes for dinner, bbl
<dholbach> mvo: bon appetit
<pitti> Riddell: what's your ETA?
<Kamion> argh, need to make oo.o2 build somehow
<Kamion> and cron.sync doesn't work due to the Debian archive key changes
<Seveas> pitti, are you going to pastebin all USN's? :)
<pitti> Seveas: just the ones I want review for :)
<elmo> Kamion: I'm working on it
<Riddell> pitti: still some time yet, if you're ready with your stuff I'd say do them separately
<pitti> Riddell: yes, it's ready for some hours now
<pitti> Riddell: ok, a separate update doesn't hurt
* Kamion promotes libgcj6-jar, which looks like it'll help
<Keybuk> I wanted to write a Java application called pickle once
<Kamion> drawback of the simplified live CD is that kernel ABI transitions require an installable desktop before the live CD can be rebuilt
<Kamion> and until that happens, it's toast
<Mithrandir> Kamion: I guess that's an incentive to keep the desktop installable a bit more
<Mithrandir> we should become better at that anyway, imo
<Kamion> yes
<dilinger> pitti: sent
<Riddell> pitti: I've applied all the changes as they appear in that patch you pointed me to and it still doesn't fix any more bad PDFs
<Keybuk> right, dinner time
<mdz> dholbach: around?
<dholbach> mdz: yes
<nekohayo> anyone knows what could cause a segfault when doing a mkdir ? I'm trying to use checkinstall to make a deb for gnonlin and I get a segmentation fault when trying to do mkdir -p "/usr/share/doc/gnonlin-0.10.0.4"
* Kamion gives back openoffice.org2 again
<Kamion> maybe this time it'll work ...
<pitti> Riddell: hm, screwy... the patch worked fine for me; what is the embedded xpdf version, 3 or 2?
<pitti> Riddell: I can send you a patch for xpdf 2 if you need
<Kamion> ... nope
<Burgwork> Kamion, if we are not calling it UE, are we calling it Espresso now
<Burgwork> ?
<Kamion> Burgwork: yes
<Burgwork> ugh, rebranding sucks
<Kamion> Burgwork: I'm not making much of a big deal out of it yet because I don't want somebody else to decide that it would be great if they implemented Espresso first and called it that, again :P
<Kamion> Burgwork: you're welcome to continue to call the *project* Ubuntu Express, but this implementation is called espresso
<Burgwork> ok
<Burgwork> is css broken on planet.u.c for anybody else?
<Kamion> the name ubuntu-express has become the village bike and is now functionally unusable as a package name without confusion
<Kamion> we should make a note in the future never to use project names as spec titles
<Burgwork> plus it violates the don't have ubuntu in our names
<Kamion> indeed
<Kamion> (another reason I was, in the end, happy enough to rename)
<Kamion> doko_: still around?
<Burgwork> Kamion, for those on the forums, what sort of timeline do you expect to have the first working version out there?
<Kamion> doko_: there are uninstallables due to the libgcj6-common -> libgcj6-jar rename; can you deal with them?
<Kamion> Burgwork: I'm not going to answer that yet
<Kamion> I have enough pressure from the team without the forums too, thanks :-)
<Burgwork> Kamion, I told them wait, but people never get that
<Kamion> just ignore "are we there yet"
<Burgwork> as long as you meet UI freeze, me as doc team guy won't hunt you down
<tseng> Burgwork: forums are intrinsically over-eager to an extreme degree
<Kamion> doko_: oh, hey, you could just make libgcj6-jar Provides: libgcj6-common; that would sort everything out
<Burgwork> tseng, they are great for free marketing, but yes, a little over-eager
<Kamion> my best answer right now is "the more people ask about it, the later it'll be"
<pitti> NOOOOO - the world seems to hate me *sniff*
<doko_> Kamion: already done, should be gone away with the java-gcj-compat sync tonight
<pitti> I just finished to patch 4 xpdf vulns in 8 packages, and now a SuSE dude comes along and finds another one???
<Kamion> doko_: oh, done in Debian?
<doko_> Kamion: and yes, I think I forgot to ask for promotion in main as well
<pitti> Riddell: ^ more phun ahead (but no patch yet)
<doko_> Kamion: yes
<tseng> pitti: they want to steal pmount away from you also :P
<tseng> pitti: with the new hal
<Kamion> elmo: any chance you could sync java-gcj-compat from incoming? I badly need a working live CD
<pitti> tseng: oh, pmount has a lot of non-gnome users, I'm not concerned about 'stealing' at all
<Kamion> doko_: there's also ecj-bootstrap
<pitti> tseng: but apart from that the current upstream development is frightening and insane
<doko_> can anybody remember, why we do have vnc4 in main, and not tightvnc? vnc4 includes a copy of Xfree86-4.2
<doko_> Kamion: oops, will do as well
<Kamion> thanks
<Riddell> pitti: it's xpdf 3
<pitti> hi daniels 
<tseng> daniels: nice work with x-crack-o-the-day
<daniels> ta
<Kamion> doko_: if you could let lamont/infinity know when all the gcj/ecj fixes are in the archive so that they can give-back openoffice.org2, that would rock ... I'll be going out for the evening soon
<doko_> Kamion: will do. is libgcj6-jar promoted?
<Kamion> doko_: yes
<elmo> Kamion: done
<Kamion> thanks
<\sh> Kamion: what is linux-kernel-di-{i386/powerpc}-2.6 in universe? I see you made some changes and merges for it
<doko_> pitti: make sure you fix them in poppler as well ;-P or is this a seb task
<\sh> grmpf...12h disconnect
* Diziet nails the download manager bug.
<Diziet> Finally !
<jbailey> daniels: Is the upstream changelog for xserver-xorg-driver-ati found in a different package?
<daniels> Diziet: yaay! :)
<daniels> jbailey: everything before 7.0RC4 can be found at http://cvs.freedesktop.org/xorg/xc/ChangeLog
<Diziet> To add insult to injury, it's a two-line fix (well, a one-line fix duplicated in two places).
<daniels> jbailey: before mid-Dec, the module ChangeLogs were only used for logging changes to the build system, and even then not always.
<jbailey> daniels: Ah, okay.
<jbailey> daniels: Just given the problems I've had with X, I went to go look for them and didn't know where to find.  IS this a good place to check ongoing?
<daniels> jbailey: in terms of ongoing stuff, yeah.  it's not a useful retrospective, but that's all changed now.
<jbailey> Cool, thanks.
<HiddenWolf> daniels, is dapper at the final xorg version now?
<daniels> HiddenWolf: except for the proto modules, which I'm finishing up now
<janimo> daniels, do you know if r300 is going into X upstream soon?
<mjg59> janimo: It's in X upstream
<daniels> janimo: 'four months ago'
<janimo> do we have it in ubuntu?
<mjg59> In Dapper? Yes
<janimo> hmm
<jbailey> janimo: I'm using it.
<janimo> oh, ok. Is it 3d acceled nicely?
<janimo> I have to try it out myself too then
<daniels> it's either nicely 3d accelerated, or your computer hangs
<janimo> is x.org being imported into bzr soon?
<doko_> dholbach: distrowatch thinks abiword 2.4.2 is available
<daniels> janimo: ask the bzr guys?
<dholbach> doko_: oh, hm
<dholbach> doko_: if i knew from where... :)
<daniels> janimo: the repository is ... interesting.  years of creative branching and people running rcs against the repository (not that I would ever do that, noooo ...).
<dholbach> and hub's not here... hmm :)
* mvo grumbles that his r300 is one of the "hangs computer" kind
<Burgwork> dholbach, abisource sitll says 2.4.1
<dholbach> Burgwork: that's where i looked
<lamont-away> daniels: 0000:01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5954
<daniels> mvo: r350 in particular and ppc is still hairy
<lamont-away> should I expect that to cause X to call a null pointer under certain acceleration thigns?
<daniels> lamont-away: RUN AWAY
<lamont-away>     Option          "NoAccel" "true"
<daniels> radeon xpress stuff is crack, but airlied got himself one for christmas, so its issues should hopefully be fixing themselves shortly
<janimo> daniels is it now possible to hack on X without having the whole tree?
<daniels> lamont-away: breezy, or dapper?
<lamont-away> ah, cool.
<daniels> janimo: yes
<lamont-away> breezy
<daniels> lamont-away: 'yes'
<lamont-away> should dapper be better?
<daniels> lamont-away: Option "Accel" should fix it, and dapper is better
<daniels> (don't ask)
<lamont-away> daniels: Option "Accel" "true" ??
<daniels> the "true" is redundant, but yeah
<lamont-away> uh, ok.  that's sick
<daniels> yes
<janimo> daniels, by radeon xpress you mean PCIE R300 cards?
<doko_> daniels: vnc4 includes a copy of Xfree86-4.2, what should be done with that? tightvnc might be an alternative
<daniels> janimo: no, I mean radeon xpress cards
<daniels> doko_: wooooooooo security holes!
<janimo> I saw on r300 sf page they have problems with pci express
<daniels> doko_: the answer there is 'christ almighty, don't do that'
<daniels> janimo: that's true
<doko_> daniels: ok, so we should demote vnc4 to universe and promote tightvnc to main
<daniels> doko_: almost certainly
<daniels> but don't quote me on that
<daniels> (personally I think VNC is crack in general and would rather not have to attempt to support it, but eh)
<janimo> freeNX misses dapper too is seems
<daniels> yes, and for good reason
<daniels> that thing needs serious, serious, changes before it can get into dapper
<dholbach> daniels: not even in universe? :)
<Burgwork> daniels, what specifically is wrong with freenx?
<daniels> they just took the monolithic tree and threw in massive chunks of code
<lamont-away> daniels: maybe we need a new component called 'bendover' or something....
<daniels> it takes a herculean effort just to produce a diff relative to the original tree
<Burgwork> daniels, you telling me freenx includes code from 6.8 and earlier?
<daniels> Burgwork: well, given it just replaces your libX11, has a whole new X server, etc -- yes
<janimo> daniels, I assume this is accurate enough if I want to start on X 7.0 stuff, right ? http://wiki.x.org/wiki/ModularDevelopersGuide
<Burgwork> daniels, ok, that is very crackful
<janimo> if I want to only work on say ati drv is it ok to have only that fromCVS and the rest of deps from ubuntu packages
<janimo> ?
<daniels> the second statement is true, don't know about the first
<daniels> MDG used to be the canonical guide
<daniels> yeah, looks pretty accurate from a brief skim
<Diziet> daniels: Hello.  Do you want to talk about 20763 ?
<Diziet> Need anything from me ?  etc.
<daniels> Diziet: er
<daniels> i'm going to go out on a limb and say that's a firefox issue
<daniels> given the little yellow window with the red source code is what firefox throws up when it goes 'holy crap xul is all bad'
<pvanhoof> There's a line being drawed underneat my mouse cursor since last week (and todays xserver upgrades didn't remove it) ... will it go away sooner or later?
<pvanhoof> :p
<Diziet> Isn't that xul in the locale packages ?
<pvanhoof> I'm on dapper of course
<daniels> (i don't know who flo1987@gmx.net is, nor why he assigned it to me)
<daniels> pvanhoof: Option "SWCursor" will fix it, but I have no clue what driver you're using, sooo ...
<daniels> Diziet: i guess.  i didn't know I was the firefox maintainer?
<pvanhoof> fglrx, but I think it's falling back on ati atm
<Kamion> \sh: I last changed those before the warty release
<Kamion> \sh: they're obsolete
<daniels> pvanhoof: what?  fglrx never 'falls back' to ati
<\sh> Kamion: thx :)
<pvanhoof> oh, well .. it's not finding a fglrx module in the kernel
<pvanhoof> so whatever it does when it's not finding that module, is happening :)
<\sh> Kamion: so elmo could morgue them or move it into the trash directly?
<Diziet> daniels: Err, I'm missing something here.  You're responsible for mozilla-firefox-locale-all, or aren't you ?
<Kamion> \sh: the verb is "remove", but yes
<daniels> pvanhoof: which is probably MMIO, but still fglrx
<daniels> Diziet: absolutely not
<daniels> Diziet: if you look at the bug activity log, some random just assigned it to me
<pvanhoof> daniels, I'll switch to ati ;) and if it still happens add that SWCursor option
<\sh> elmo: can you please remove linux-kernel-di-{i386/powerpc}-2.6 from universe? thx :)
<Diziet> daniels: Oh.  How annoying.
<daniels> Diziet: indeed
<daniels> Diziet: enjoy
<Kamion> elmo: you might as well just kill linux-kernel-di-*
<Kamion> none of them build anyway
<Diziet> How helpful.  I did `reassign to QA contact' and it assigned it to `debzilla bug importer' !
<Diziet> Who is in charge of langpacks then ?
<lamont-away> pitti, iirc
<Kamion> pitti has historically done a lot of that
<pitti> heh, yes :)
<lamont-away> W: bind9: package-has-a-duplicate-relation depends: libisccc0, libisccc0 (= 1:9.3.2-1)
<lamont-away> stupid debhelper
<Kamion> although Adam Conrad did the last upload
<pitti> Diziet: which bug?
<pitti> Kamion: of langpacks?
<Diziet> 20763
<Kamion> pitti: mozilla-firefox-locale-all
<pitti> Kamion: ah, *these* :)
* Kamion -> pub
<pitti> Diziet: just close it as dup of 21159
<pitti> Diziet: or the other way round, I don't mind
<pitti> Diziet: I'm 100% sure that locale-all worked with the firefox that was current at that time
<pitti> Diziet: something broke it; I want to investigate this for days now, but I didn't get to it
<Diziet> I really need to stop working today.  Can I leave it with you to either take this or reassign it to me or something and you can have my help tomorrow ?
<pitti> Diziet: yes, I'll care for it
<Diziet> Thanks.  Let me know if you want me to do anything.
<pvanhoof> Hmm, SWCursor leaves "traces" of my mouse cursor when things on the screen happen and my cursor is at the same position
<pvanhoof> but ... it's less irritating than a line underneat my cursor
<pvanhoof> :)
<tenco> hi
<tenco> how is nvidia tls linking handled in dapper? same as in breezy (generating links on each startup)?
<mjr> (so _that's_ why there's that module tmpfs... :]  )
<xhaker> -rw-r----- 1 root slocate 1320337 2006-01-05 19:59 /var/lib/slocate/slocate.db
<xhaker> slocate segfaults.. strace reveals it doesn't have access to the .db
<tenco> mjr: do you know what are the gains of such a method?
<mjr> tenco, no, not really
<xhaker> subtle
<mdz> Diziet: debzilla is the default assignee for all packages which wouldn't otherwise have one (bugzilla doesn't allow for it to be blank)
<mdz> xhaker: you can't strace a setgid program for obvious reasons
<mdz> it has been segfaulting for me too, fwiw
<xhaker> mdz, so that is not the reason.. it sometimes outputs some results and then segfaults
<mdz> xhaker: yes, it is.  that is the reason why it didn't have access to the database when you ran it under strace, and that is unrelated to the segfault
<xhaker> mdz, if you can.. i need to talk with somebody about something.. a python script needs to use some commands with su permissions.. i've tryed seting +s but it doesn't really work
<mdz> linux doesn't support setuid scripts; try #python for help
<xhaker> so if i used C it would work?
<mdz> yes
<xhaker> hmm.. i think i'm going to code a daemon for gtkwifi then.. in C
<Burgwork> mdz, are we seeding gnome-power-manager now?
<mdz> Burgwork: now?  no, I'm not aware of anyone making seed changes at this moment
<Burgwork> mdz, sorry to bug you. I realized I was being an idiot  about 3 secs after I hit enter
<daniels> i'm making a seed change right now
<Nafallo> hehe
<zul> whoa..what happened to planet?
<shaya> is there a web page anywhere on how NetworkManager is supposed to work w/ ubuntu?  there seems to be a disconnect b/w normal ifupdown usage and NetworkManager?
<tseng> zul: jdub said it was moving to a new box
<zul> ah ok...it looks weird though
<daniels> zul: yeah, no css
<daniels> pitti: you may not have noticed it going in, but all the drivers now provide xserver-xorg-driver or xserver-xorg-input, as appropriate
<pitti> daniels: ah, cool
<seb128> is "bzr push sftp://..." supposed to work with bzr 0.6.2 ?
* lucas prefers to use rsync
<seb128> lucas: that's for vuntz :p
<lucas> seb128: ?
<seb128> that's not for me, I just wanted to know if sftp:// is supposed to work
<seb128> in fact it works with boxname:path
<vuntz> I blame seb128 for everything!
<delire> hi. i'm considering making a bounty proposal but would first like to find out whether the problem has already been forwarded/approached in another form.
<seb128> Hi
<lucas> delire: summary please :-)
<Riddell> seb128: I've not got bzr push to work
<seb128> you need bzrtools if you use dapper version probably
<delire> rural areas typically rely on non-broadband connections. some households/farms/schools have one machine connected via dialup, with this connection shared across a lan. internet connection sharing is not trivial in linux as it stands (req. iptables etc). 'internet connection sharing' would be a killer app.
<seb128> if you use jbailey's snapshot it works just fine
<daniels> sigh.  i hate that the seeds take an hour to download.
<janimo> delire, somebody us working on a spec called firewall
<delire> i encountered this in a remote part of new zealand recently. as it evolved, we needed to retain a windows machine to share the PPP connection to the Ubuntu machines on the LAN. this was something of a defeat for a rural household moving over to Ubuntu.
<daniels> lifeless: is 0.7pre supposed to be performant?
<janimo> that should cover connection sharing
<delire> janimo ahah, interesting.
<dholbach> Have a nice evening - I'm off.
<delire> ciao
<janimo> it's low prio for dapper but there is hope
<janimo> he's carstenh you may want to get in touch with him
<janimo> I am interested in this as well
<delire> janimo Ubuntu is tricky for networks on the end of a dialup connection as it stands i feel. 
<janimo> sadly yes
<delire> .. and this is the case for rural areas housing millions of people worldwide.
<janimo> am being reminded by frieds on dialup who I gave ubuntu and went back to win out of frustration :)
<janimo> s/:)/:(/
<delire> janimo precisely..
<janimo> there's a dial up spec also for a while but receives no love
<daniels> there's been a dialup spec since specs existed, and dialup was often mentioned in the warty cycle, even
<delire> well great to know this is on the way. as if support for non-serial-port modems wasn't enough of a problem..
<janimo> do you want to help do it if I understand correctly?
<daniels> it really needs someone with some amount of time to really take it and make it work
<daniels> unfortunately the itch factor is low -- i went to use a modem the other day when my DSL didn't exist, and discovered I didn't own one, outside of the seemingly non-functional one in my laptop.  i suspect this is not abnormal.
<delire> daniels alot of folk would like to run Ubuntu in rural areas, but as it stands, Ubuntu is ironically better suited to the financially well off, those that can afford a DSL connection.
<janimo> I think the issue of softmodems is one too, not?
<delire> janimo truly. this is a big problem.
<daniels> delire: this is fully understood, it's just a matter of time, resources and motivation.  it needs someone with all three to step up and own the spec.
<HrdwrBoB> yes, none of the developed, none of the tested use a dialup connection
<lucas> my grandmother uses ubuntu on a RTC modem
<lucas> s/on/with/
<HrdwrBoB> *developers
<lucas> she doesn't encounter problems
<janimo> delire you mentioned a bounty?
<delire> janimo: yes, considering it.
<lucas> well, when she'll start understanding copy/paste better, I might try to learn her how to code :)
<delire> lucas: hehe
<janimo> as in working for a bounty or offering one? :)
<delire> janimo possibly offering one. i will look into this 'firewall' script with connection-sharing functionality you mentioned. who did you say is responsible?
<janimo> carstenh
<janimo> look it up on launchpad
<delire> ok, cheers
<delire> right
<lifeless> daniels: not for network efficiency, no
<janimo> https://launchpad.net/distros/ubuntu/+spec/firewall
<delire> janimo thanks :)
<janimo> I talked to him a few days ago and he said he should have something by the end of this week
<janimo> is there a way to search for specs on LP besides loading up the page with all 260 of them and searching in that page?
<daniels> lifeless: i see
<lifeless> daniels: just keep a copy of them and pull when you need to make more changes
<lifeless> that will be faster than a old start
<daniels> well, I had the seeds downloaded, and made a change
<daniels> but then the archive drifted, so I tried to pull, but after twenty minutes it smacked me down and told me to merge, and then merge failed very non-specifically
<daniels> so I just gave up and tried again
<delire> thanks for your help all. i'm going to tail this development. i think something along the lines of an 'Internet Connection Sharing' app for Ubuntu would really open it up to rural/underprivileged demographics, and even geographically remote SME's/SOHO's.
<daniels> there's no arguments there, it just needs to actually get done
<lifeless> daniels: ok
<delire> have a good night.
<janimo> delire, as for dialup go to wiki.ubuntu.com and type dialup in the search box
<lifeless> daniels: for reference, if you make a change and I make a change, one of us *has* to merge the other and commit before you can pull again.
<janimo> night
<Burgwork> jdub, css on planet appears to be borked
<daniels> lifeless: right.  but merge just completely bombed and left me with a tree that was ostensibly up to date, but the delta from my tree to upstream was exactly as it was before I ran merge
<lifeless> daniels: argh. If that happens again, please take a tarball of that tree for me to examine
<daniels> lifeless: 'kay
<lifeless> daniels: thanks!
<daniels> i'm aware it's probably completely useless, but anyway:
<daniels> daniels@ephemera:~/canonical/seeds/dapper% bzr merge sftp://chinstrap.ubuntu.com/home/warthogs/archives/seeds.ubuntu.com/ubuntu/seeds/dapper
<daniels> bzr: ERROR: Channel request for unknown channel 1
<daniels> 0 conflicts encountered.
<daniels> do I need to run commit and then merge, maybe?
<xhaker> suid doesn't work in python scripts would it be reasonable to make a C app just to launch the script with su permissions?
<darte> is there any repository-sync going on now?
<lifeless> daniels: it merged fine, just commit
<lifeless> that error is noise and I think eliminated these days
<daniels> lifeless: bzr diff output was the delta between upstream at my last pull and upstream now
<daniels> so I would've reverted the entire changeset bar my one-liner
<lifeless> so 'bzr diff' was saying 'hey, you have all the changes from upstream' 
<daniels> i see
<pitti> seb128: it depends on whether you have bzrtools installed or not
<CarlFK> Kamion: setup - hda1 as /, hdb1 as / - OK... mkfs whacks both, then setup says "dupe mountpoints.. no good.. go fix" - shouldn't that happen before the mkfs?
<seb128> pitti: yeah, we figured since, thanks :)
<rw> I installed ubuntu 5.10 in a dell d510 notebook with this sata chipset, 0000:00:1f.2 IDE interface: Intel Corp. 82801FBM (ICH6M) SATA Controller (rev 03). It is featuring a weird noise that seems to come from the hard disk. It came with windows and I haven't noted this noise. Does anyone imagine what might be going on and what solutions I may take? I was thinking maybe about the hd frequency. Ideas?
<elmo> Kamion: around?
<Burgwork> rw, please file a bug. This is not a support channel
<robertj> is the blackness around the notification window in dapper a known issue?
<mvo> robertj: do you run composition externsion without a composition manager maybe?
<robertj> that's probably it
<mvo> just start xcompmgr and enjoy nicely shaped windows
* robertj tries to figure out how to force another notification bubble
<robertj> mvo: hehe, and very laggy window resizing
<mvo> robertj: :) what card do you have? I found that using "exa" to accelerate works very well on my ati
<daniels> exa + composite + xcompmgr -a, makes your system stupid fast
<daniels> robertj: use xcompmgr -a, not xcompmgr
<robertj> intel integrated garbage
<Treenaks> oh speaking of ati :0
<Treenaks> daniels: I'm going to try the ati driver on my crack ATI card
<daniels> the firegl?
<robertj> I think exa was putting me into a deathspin a few weeks ago
<darte> sorry ppl .. i have
<darte> a problem with ubuntu-desktop ..
<darte> (dapper) ive got a server install .. and it doesnt let me install it.
<Treenaks> daniels: and it's still broken :) but in another interesting way
<kent> what is exa?
<Treenaks> daniels: It now gives me a black screen (and tells me it found a CRT as the default display, instead of my laptop LCD)
<Treenaks> daniels: if I set Option MonitorLayout "LVDS", I get the old breakage back
<robertj> wait nevermind
<robertj> it's a ProSavage8
<daniels> Treenaks: eep
<daniels> kent: new acceleration architecture
<Treenaks> daniels: want the log? :)
<daniels> Treenaks: sure
<kent> daniels, nothing that would work on an old tnt2? :) Besides the GPU my computer is very fast.  But composite made my computer slow last time i tried.. 
<jdahlin> how do I find out if my card supports exa?
<Treenaks> daniels: see PM for links
<robertj> visit the ubuntu harw..err nevermind ;)
<daniels> kent: don't use normal xcompmgr
<daniels> jdahlin: 'it doesn't'
<kent> daniels, you meen use it with xcompmgr -a like you said above?
<daniels> jdahlin: only works out of the box for radeons at the moment.  at http://xorg.freedesktop.org/wiki/ExaStatus you can find patches for i810, nv, savage, tdfx, etc
<daniels> kent: yeah
<kent> will try for the fun of it. thanks.
<jdahlin> daniels: that page says sis is supported though
<daniels> jdahlin: oh yeah, sis too, my bad
<HiddenWolf> what is going on with p.u.c?
<Treenaks> HiddenWolf: Pure, Authentic Breakage
<HiddenWolf> Treenaks, sweet. :)
<robertj> hrmm. psychadelic
<shaya> anyone seen adam conrad?
<Burgwork> shawarma, he is infinity, who is not here  right now
<Kamion> CarlFK: please file a bug with full details rather than abbreviated ones; component "partman-target"
<Kamion> elmo: yes?
<kent> daniels, just out of curiosity.  When using xcompmgr -a   I get no eyecandy at all. Whats the use of that?  
<CarlFK> Kamion: will do.  just making sure it was worth the post and later reading
#ubuntu-devel 2006-01-11
<daniels> kent: it enables server-side compositing, which means that instead of having to do a round-trip to the client and asking it to repaint itself please, when you expose it (e.g. move another window out from in front of it), it's just always there
<daniels> kent: try dragging windows around
<daniels> kent: (the effect is infinitely more pronounced with exa)
<kent> daniels, so using xcompmgr -a is a way of accelerating the desktop?  I meen, i thought composite was about eyecandy.. ?
<mjr> kent, no, it's not
<mjr> it's certainly useful for eyecandy, but it's more than that
<Kamion> CarlFK: it's just something in a non-optimal place in partman
<hunger> Is the synaptic driver currently broken in dapper?
<daniels> install xserver-xorg-input-synaptics
<hunger> daniels: Ah, yes! I had installed the old one and that confused me:-)
<hyperactivecrond> can i talk to an admin for the website... i need my account de-permanently deleted...
<Burgwork> hyperactivecrond, which website?
<hyperactivecrond> the wiki
<hyperactivecrond> apologies. the wiki
<hunger> daniels: did you notice my bugreports about broken manpages in the X debs in malone?
<hunger> daniels: The man-pages got moved into .../man3 while the .so entries referencing them still claim stuff to be in man3x.
<daniels> hunger: hm?
<daniels> hunger: you know there's no /usr/share/man/man3x, right?
<seb128> jbailey: around?
<hunger> daniels: Yes. Some manpages reference others and they list man3x there.
<jbailey> seb128: Yup
<hunger> daniels: Check XShape* in /usr/share/man/man3/
<seb128> jbailey: do you have a dualhead setup?
<jbailey> seb128: Not currently, no.
<hunger> daniels: mandb sends me mails about this each night:-)
<seb128> ah, I thought
<jbailey> seb128: I used to.  I'm on a cinema display now.
<seb128> somebody with a such config? :)
<daniels> hunger: ah, I see
<seb128> jbailey: did you notice something like http://bugzilla.ubuntu.com/show_bug.cgi?id=21628 ?
<jdub> http://www.flickr.com/photos/badroucha/82634154/
<jbailey> seb128: No, my setup was Xinerama./
<seb128> jbailey: oki, thanks anyway :)
<daniels> seb128: when i had a mergedfb setup, I used that in lieu of workspaces, so
<jdub> http://www.flickr.com/photos/86444323@N00/81971182/
<jdub> whoa :)
<tseng> hey now
<tseng> can I get that in gdm
<daniels> (nsfwish)
<hyperactivecrond> lol
<jdub> tseng: i'm, ah, thinking of doing something like that...
<Seveas> jdub, how about a very winXP like gdm login op april 1st :)
* daniels raises an eyebrow at jdub.
<hyperactivecrond> no admins for the wiki here then..
<jdub> Seveas: heh
<jsgotangco> whoa
<jsgotangco> hmm
<jsgotangco> jdub, planet css is missing?
<jdub> jsgotangco: the fact that it's tagged and titled ubuntu is what gets me :)
<jdub> jsgotangco: ugh, probably changes on the main website breaking it
<jdub> yeah, i think the website has been redone or something
<jdub> i don't know
<jdub> yikes
<jdub> it's moin now
<jdub> that's remarkably sane
<jdub> but not good for planet ;)
<tseng> yay moin
* Kamion fixes the openjade1.3 build and goes to bed; night all
<lucas> does somebody has a cool Ubuntu-colored HEADER.html I could use ?
<tseng> yeah i put the snippet in REVU
<lucas> HEADER.html = file put before the file list by apache when there's no index.*
<tseng> grab it
<lucas> ah good idea
<jsgotangco> yeah the website is in moin now (most of it)
<jsgotangco> nice kannel is in universe this should come in handy at work
<Burgwork> jsgotangco, kannel?
* mvo goes to bed
<jsgotangco> Burgwork, its a wap/sms gateway i use it heavily at work, we used to do it in fedora but we're switching servers =)
<jsgotangco> Burgwork, its a very popular app used by telcos and mvnos
<jdub> daniels: ping
<daniels> jdub: respecognise
<jdub> heh
<daniels> wassgoinon?
<jdub> daniels: ati in a laptop, unknown device 5a62, only works with fglrx atm, ati driver makes the screen all flashy and wonky
<jdub> daniels: know what it is and if xorg supports it, and how we can fix autodetect?
<HrdwrBoB> that's the technical term
<daniels> ah, xpress 200
<daniels> jdub: if it's running breezy, try Option "Accel" or Option "NoAccel"
<daniels> this has been fixified in dapper
<jdub> daniels: dapper
<daniels> bugger
<daniels> does Option "MonitorLayout" "LVDS,NONE" help?
<daniels> (device section)
<jdub> also i'm still not getting synaptics love :)
<daniels> yeah, I only fixed that like this morning
<daniels> so the seeds won't have been updated yet
<jdub> monitorsection didn't work
<jdub> er, monitorlayout
<daniels>  frig
<daniels> i have no idea
<daniels> can you please email me both xorg.0.logs? i need to write a tool for treenaks on monday to get the information to fix it
<jdub> with and without the monitorlayout option?
<daniels> just without
<daniels> both -> ati and fglrx
<jdub> oh right
<jdub> funny - only reason i bothered trying again was because fglrx still crashes the crap out of it ;-)
<daniels> god
<daniels> airlied got himself one of those for christmas, so hopefully they're working soon
<daniels> nightmare devices
<jdub> daniels: this quebecistani craptop is pretty evil all 'round :)
<daniels> heh
<mjg59> daniels: Is this the same thing that fucks the Firegl V5000
<mjg59> ?
<daniels> mjg59: maybe, who knows
<mjg59> daniels: We had that failing on the HP 8240
<daniels> mjg59: xpresses are screwed in general, though.  shared vram, yay.
<daniels> mjg59: oh? well, I'll pass you the program too
<mjg59> I think this has discrete memory
<mjg59> daniels: There's an open bug about it in bugzilla - hang on
<jdong> I wasn't able to get a meaningful answer in #ubuntu, but what on EARTH is prat.ubuntu.com?!
<seth_k|lappy> It works!
<daniels> mjg59: i won't be around on the weekend (in bendigo), but basically you want to read RADEON_FP_*, particualrly the syncy bits
<Burgwork> daniels, that i810 no dri bug seems to have fixed itself as of today
<daniels> jdub: one half of archive.ubuntu.com
<daniels> Burgwork: okay
<mjg59> Gah, can't find it now
<daniels> mjg59: RADEON_FP_CRTC_H_TOTAL_DISP, RADEON_FP_CRTC_V_TOTAL_DISP, RADEON_FP_H_SYNC_STRT_WID, RADEON_FP_V_SYNC_STRT_WID, RADEON_TMDS_PLL_CNTL, RADEON_TMDS_TRANSMITTER_CNTL, RADEON_FP_HORZ_STRETCH, RADEON_FP_VERT_STRETCH, RADEON_FP_GEN_CNTL
<mjg59> http://bugzilla.ubuntu.com/show_bug.cgi?id=14043
<daniels> mjg59: also RADEON_LVDS_GEN_CNTL, RADEON_PIXCLKS_CNTL, possibly also RADEON_BIOS_[456] _SCRATCH
<mjg59> daniels: Ok - I probably won't have time to deal with this myself for now
<daniels> mjg59: okay, I should get to it on monday then
<Burgwork> jdub, css messed on planet.u.c? my issue or the worlds?
<daniels> Burgwork: world's
<daniels> jdong: 01:02 < daniels> jdub: one half of archive.ubuntu.com
<jdub> Burgwork: wuc changed, broke planet
<jdong> daniels: oh, so some packages are hosted on there?
<Burgwork> jdub, ah, ok
<jsgotangco> moin rules!
<jdub> moin's great, i totally approve of switching wuc to it, but would have been good to have any idea whatsoever in advance
<daniels> jdong: ... it's one of the servers in the a.u.c rotation.
<jdong> daniels: ok, thanks, that clears it up!
<lucas> it also broke the CSS on popcon.u.c
<jsgotangco> argghhh
<elmo> planet should work now
<elmo> if jdong ever comes back, someone point him at http://www.comnap.aq/comnap/comnap.nsf/P/StationsByName/CLnava
<daniels> CONCORDIAH
<jdub> elmo: planet is pointing to shitty old css from the plone site
<jdub> elmo: we need to get it onto humboldt so i can actually fix it and stuff :)
<jdub> yay for http
<jdub> elmo: i'll fully prep it now, given that i have http love
<elmo> jdub: um, thanks for like telling us.  after complaining about not being told stuff :-P
<elmo> (about the CSS)
<jsgotangco> chile?
<jdub> elmo: i found out like, minutes ago
<jdub> elmo: and it shouldn't be your responsibility to fix
<elmo> jdub: eh?
<elmo> yeah it is
<elmo> planet isn't the only thing that points at the css on www.u.c
<elmo> it needs fixed, and  who else is going to?
<jdub> well, the web people should've told you that, then
<jdub> before changing it all
<jdub> same as i
<jsgotangco> who are the other web people (aside from henrik)?
<jdub> http://www.flickr.com/photos/kittyfish/82737624/
<jsgotangco> jdub, yahoo has this neat widget that retrieves images from flickr based on tags...on windows and osx though...
<jdub> i have a neat shell script ;-)
<jsgotangco> ohhh
<jdub> i just use rss, and a shell script to modify it for inclusion on the fridge
<whiprush> we need a slick rss/flickr/web2.0whatever screensaver badly.
<jsgotangco> you really have to call it web2.0? heh
<whiprush> I tried to say that with a straight face, heh.
<hyperactivecrond> man heh
<\sh> infinity / lamont: ping
<psusi> anyone ever used hal callouts before?
<\sh> infinity / lamont: if you have time please have a look on atom4...it builds nicely in a pbuilder but FTBFS on all archs on our buildd ...think it's a "cons" problem...thx 
<infinity> s/cons/scons/?
<infinity> Oh, cons indeed.
<\sh> cons 
<infinity> Yeah.  Let me poke it with a stick.
<\sh> Many thanks :)
* hunger wishes for a more unique naming scheme for the logfiles and their rotations.
<hunger> Some are gziped others are not, sometimes the first rotated file is called .0, sometimes .1.
<lifeless> hunger: I think you mean less unique
<lifeless> hunger: or even homogenous
<hunger> lifeless: homogenous sounds like it might fit, yes.
<hunger> Hmmm... is the initscript for cups broken? logrotate complains about it here.
<infinity> \sh: Should be fixed now.  We'll see in ~30 mins.
<\sh> infinity: great :)
<jouston> Hi all
<jouston> Anyone see Malcolm or Mark?
<elmo> BenC: is the -ubuntu<n> suffix to the package name a linux-source thing or a kernel-package thing?
<nekohayo> anyone know when gst plugins base multiverse, and gstreamer development files might appear in the repositories?
<nekohayo> I'm pretty much stuck without them I cannot fully compile pitivi, gnonlin and gst-python
<fabbione> elmo: the -ubuntu<X> comes out only if you compile your kernel manually.
<fabbione> elmo: it's the EXTRAVERSION in the toplevel Makefile of the kernel to distinguish from vanilla kernels on kernel.org
<elmo> oh, ok, I never even thought to check that
<elmo> I thought it was the LOCAL_AUTO_VERSION config maybe
<elmo> thanks
<fabbione> elmo: it doesn't appear on our packages because there is an override
<fabbione> if you really hate it, you can override it
<fabbione> export UBUNTUBUILD=1
<fabbione> and it will clear the EXTRAVERSIOn
<elmo> or just edit the Makefile? :)
<fabbione> elmo: that would do too :)
<psusi> have we any hal gurus about who might shed some light on having hal invoke a callout when it detects a cdrom?
<jsgotangco> is anyone aware that grub is still borked in the daily builds?
<pitti> hey folks
<jsgotangco> hi pitti 
<ajmitch> hi pitti 
<Mez> morning all
<infinity> Hey pitti.
<Keybuk> morning Mr Pitt
<Mithrandir> moo
<pitti> hi infinity 
<pitti> hey Keybuk 
<Keybuk> infinity: any progress on madwifi-ng packaging?
<infinity> LRM is taking a back seat to some apache/php stuff today, but it's likely a weekend thing to get madwifi-ng happening for testing.
<Keybuk> ok
<Mithrandir> infinity: we were going to discuss livecd-squashfs too
<infinity> And that.
<infinity> Good thing I have my secretary here.
* infinity gives Mithrandir a raise.
<Mithrandir> infinity: I just need a filesystem.squashfs on the cd, but we don't want it for ppc yet, just for amd64 and i386 (I don't know what ia64, hppa, sparc wants).
<fabbione> Mithrandir: there is no sparc livecd yet
<fabbione> Mithrandir: so don't worry too much about it
<fabbione> probably next week if i feel like hacking on it
<Mithrandir> infinity: we also want to be able to go back by flipping a switch, if possible.
<Mithrandir> or at least, mdz would want that
<dholbach> good morning
<infinity> Switch flipping is easy enough.
<Mithrandir> infinity: is there anything else you need from me on that matter?
<infinity> Well, some sort of "how do we build these squashfses" would be nice. :)
<Mithrandir> mksquashfs, in squashfs-tools
<Mithrandir> mksquashfs /path/to/live/chroot foo.squashfs
<infinity> Is it one command?  Are we re-ordering files before (with a config file), or after (with rsync)?  Do we need to do stupid block-zeroing magic, or will they always be as small as possible?
<Mithrandir> I think we'll look at the reordering later, no we don't need a block-zeroing thing.
<infinity> Oh, wait, we can't reorder after with rsync, cause it's readonly.
<Mithrandir> at least, I didn't and got decent results from rsync with a changed fs.
<infinity> So, we'll need to order the files on fs creation.
<infinity> Yeah, but you didn't change the fs THAT much.  I'm betting it'll get pretty mucked up after a few days of development, when I try to rsync, say, Friday-to-next-Thursday.
<Mithrandir> quite possibly, but rsync will just see inserted and removed chunks, which it should handle pretty well, shouldn't it?
<infinity> Meh.  Time will tell, I guess.
<infinity> As long as the file order doesn't change, life is good.
<infinity> If the order changes, we're up shit creek.
<infinity> If squashfs is deterministic in how it creates filesystems, this may be a nonissue.
<infinity> ext3 is (intentionally) non-determinstic, hence the rsync-over-the-image trick to reorder files.
<Mithrandir> it didn't change much when I removed a bit and inserted a bit, at least.
<Mithrandir> if it's a problem, we'll just do a find /chroot | sort and use that as an input file (at least initially)
<trappist> is there a maintainer for iptables or are we just using debian's package?
<infinity> Well, the best test would be for you to debootstrap two chroots, squash them both, then rsync a over b and see how different they are.
<infinity> Mithrandir: If you have a reasonably speedy mirror and disk subsystem there, you could do that test.  Otherwise, I'll eat a buildd for a while doing it.
<infinity> (I have no local mirror in my house right now, so those sorts of tests at home are... painful)
<Mithrandir> you don't need to test with a mirror, just do it with /usr/share/doc or something, then with a copy of it, then rsync?
<infinity> Oh, fair point.
<Mithrandir> you probably want something with a bit of size, but ~100-200M should be plenty.
<infinity> Assuming a "cp -a" won't be drastically different from two debootstrap/dpkg runs.
<infinity> My /usr/share/doc is 137MB, that should do.
<infinity> Did we decide on a compression method to use for squash?
<Mithrandir> well, it's doing stuff in directory order, so it might be different, but then, two debootstrap runs should be doing stuff in the same order as well, so.
<Mithrandir> I haven't investigated -lzma properly yet, so we'll just use the stock one so far.
<Mithrandir> there's no packaged mksquashfs-lzma yet, for instance. :-)
<infinity> Not when package dependency loop breaking kicks in.  As the archive changes, packages get installed in different orders.
<Mithrandir> sure, so cp in a few directories by hand afterwards or something.  It'll be equivalent to two debootstraps immediately following each other. :-)
<infinity> Heh.
<infinity> We'll see.
<infinity> Should be some fun tonight.
<infinity> I expect I'll have prototype squashfs livefs builds working by Monday morning/afternoon.
<Mithrandir> nice
<infinity> The Monday dailies should be squash, if all goes well.
<infinity> (only amd64/i386 for now, yes?)
<Mithrandir> infinity: yes
<infinity> Oh, I'll have to hit up the cdimage scripts too, to deal with multiple fs types, if you/Colin haven't already.
<infinity> So maybe not Monday.  Though the buildd side will (should) be happy by then.
<Mithrandir> ok, I hand-munged a /u/s/d a bit, and ended up with:
<Mithrandir> sent 52545 bytes  received 56952 bytes  5918.76 bytes/sec
<Mithrandir> total size is 66011136  speedup is 602.86
<Mithrandir> so it _looks_ good at least.
<trappist> O
<Mez> can someone please tell me I'm right in thinking to set this bug as "WONTFIX" - http://bugzilla.ubuntu.com/show_bug.cgi?id=21959
<trappist> I'd like to ask again, because the netfilter code has undergone some huge revisions and the package doesn't seem to have changed to accomodate them.  do we have a maintainer for iptables?  am I in the right channel for this question?
<infinity> trappist: Please, file a bug.
<trappist> infinity: I was looking into fixing bug 16831 - of those who've responded to it so far none seem the think the package needs work.  I don't know if one of them is the maintainer.
<infinity> Okay, so a rebuild could magically fix it, according to that bug.
<infinity> Err.  It's there in dapper.
<infinity> (base)adconrad@cthulhu:~$ dpkg -L iptables | grep recent
<infinity> /lib/iptables/libipt_recent.so
* Mez growls @ katapult being in main
<trappist> infinity: try iptables -A INPUT -s 1.2.3.4 -m recent -name test --set
<fabbione> and it is in breezy
<fabbione> you need to use -updates
<fabbione> a fixed iptables has been uploaded to -updates a while ago
<trappist> sigh.  thanks :)
<jsgotangco> infinity, hi are you aware that grub install in daily is borked?
<fabbione> jsgotangco: it's not because of grub
<jsgotangco> ahhh
<fabbione> OOo2 was uninstallable
<fabbione> that breaks apt
<jsgotangco> its because of 00o2?
<fabbione> and when grub-installer calles apt-get install grub
<fabbione> it fails
<fabbione> it could have been any other package
<jsgotangco> ahhh
<fabbione> for today is OOo2
<fabbione> or yesterday
<jsgotangco> i tried 4 and 5
<fabbione> yes..
<Mithrandir> infinity: btw, sabdfl wondered about m-t 1.5.  Any idea when you'll have that? :-)
<fabbione> as i said.. yesterday
<infinity> Mithrandir: Yeah, he mailed me.  asac and I need to sit down and get it done.
<infinity> -ETODOLISTTOOLONG
<pitti> ogra... you smuggled nbd into breezy main without a main inclusion report...
<fabbione> and it is FTBFS afaict
<fabbione> or was
<triceratops> Does anybody knopw how to have web lookup for online dictionaries like dict.leo.org in dict-applet 2.13.4 as it was in the former versions?
<Keybuk> . o O { I thought the point of modularising X is that you'd only need to upload one or two components at a time ... }
<Burgundavia> Keybuk, nah. The point was to increase the amount of email traffic. Sinister plot by ISPs really
<infinity> Keybuk: With 7.0 final, I suspect that will be true, yes.
<infinity> Keybuk: Some of the smaller apps may never see an update again.  Ever.
<Keybuk> my "next unread e-mail" finger hurts
<whiprush> hey Keybuk 
<Keybuk> hey whiprush *hugs*
<Keybuk> how's things?
<whiprush> good good
* Keybuk hugs dholbach
<whiprush> http://mail.gnome.org/archives/networkmanager-list/2006-January/msg00009.html
<whiprush> you probably saw that by now
<dholbach> re Keybuk
<Keybuk> whiprush: no?
<whiprush> they got their ath card just yesterday apparently
<Keybuk> lol
<whiprush> Keybuk: I've also tried to replicate your 30 second network skipping problem, and I can't at all.
<Keybuk> whiprush: you have an Atheros?
<whiprush> I seem to have an inverse problem
<whiprush> yeah.
<whiprush> x40.
<whiprush> when I try to switch off the network it picks, it doesn't
<Keybuk> whiprush: run "sudo iwevent", network-manager and nm-applet
<Keybuk> every 13s or so, you'll see it do something like "New AP: 00:00:00:00:00:00"
<whiprush> it always tries, connects, then decides "nope, I want this other network" and it goes off and tries to go to it.
<whiprush> my laptop is at work, I will test it when I get in though
<Keybuk> sounds like the same bug
<Keybuk> it'd connect to the new network, and leap off it again when the next scan request comes in
<Keybuk> mine does much the same, the laptop won't hold on a network if there's a stronger/shinier one nearby
<whiprush> you pick a specific AP and it seems to just want the strongest signal
<whiprush> or, the open one.
<whiprush> right.
<Keybuk> sounds totally like the same bug ;)
<whiprush> Keybuk: have you filed a bug upstream?
<whiprush> because I looked, and I don't see any.
<whiprush> and I find it kind of surprising that the fedora or suse guys don't seem to have the same problem.
<Keybuk> it's because the Atheros driver can't do a "background scan"; in order to scan all channels for networks (just to update the list of available ones) it has to leave the one it's connected to
<Keybuk> Fedora don't ship madwifi
<Keybuk> not sure what the SuSE guys do, I suspect they have the same problem
<Keybuk> it's a madwifi bug, not a network-manager bug
<jsgotangco> whiprush, go to sleep!
<whiprush> jsgotangco: heh
<Keybuk> and it's allegedly fixed in madwifi-ng, which we're going to try
<whiprush> oh, cool.
<jdub> N.G.
<infinity> Yeah.  Time will tell if it stands for "Next Generation" or "Not Good"
<whiprush> heh
<Den> Can anyone tell me how to get the latest Dapper kernel installed on Breezy? I know changing /etc/apt/sources.list from B to D, then apt-get update, then apt-get install linux-386 does NOT work - it only dl's about 23kB, &doesn't change the kernel.  Any suggestions?
<whiprush> Keybuk: anything else blocking n-m? 
<Keybuk> Den: DON'T EVEN TRY IT
<Keybuk> Den: SERIOUSLY
<Keybuk> whiprush: nope
<Den> It has been suggested to me to see if a bug is fixed
<Nafallo> Keybuk: looks like there is troubles with madwifi-ng according to nm-mailinglist :-P.
<Keybuk> Den: a better thing would be to download a dapper Live CD and test that
<Nafallo> morning btw :-)
<Den> See bugzilla bug 21565
<Keybuk> Nafallo: that bug was fixed recently, wasn't it?  I saw a commit on madwifi-ng to expose the right things in sysfs
<Nafallo> ah, nice. must have been then :-).
<Den> I have also tried the flight2 dapper cd - it fails to boot - it drops me to a busybox console.
* Nafallo have to get an AP SOON to test things with :-)
<Den> I'd love any suggestions.
<Keybuk> Den: upgrading to the dapper kernel will mean you also have to update much of userspace because you'll need new udev, initramfs-tools, module-init-tools, hal, d-bus, gnome-volume-manager, probably then libgtk+, libgnome, et. al.
<Den> I don't care
<Den> I only want to see if the bug is fixed with the new kernel
<whiprush> Keybuk: so basically, laptop network magic is blocked by this one bug.
<Keybuk> Nafallo: will find out next week I guess
<infinity> whiprush: Well, that and NM being fundamentally not Debian/Ubuntu/infinity friendly.
<Den> Ben Collins who responded when I submitted the bug said to try the latest kernel.
<whiprush> infinity: tell me which wall your banging your head against, so I can join you.
<infinity> whiprush: But if Keybuk can get hacking on NM (after I get him a madwifi that actually works), maybe I can file a mess of wishlist bugs. :)
<infinity> whiprush: My biggest issue with it is the complete lack of central (system/root) configuration.
<Nafallo> Keybuk: what's the plan btw, we already have the latest "stable" version. should we try cvs soon? in that case we need libnl :-)
<Den> Keybuk: any further suggestions?
<Nafallo> (next stable will need it anyway since head does now) ;-)
<infinity> whiprush: So, if you configure your network with NM, you (a) don't have a network during boot... You only get it when you log in, and (b) if you configure the network under your profile, your mom will log in and not be able to use the internet.
<whiprush> infinity: Its amusing to me that the guys that work on this stuff all have thinkpads ... with atheros cards.
<infinity> We could live with (a) (though I'd rather not), but (b) is just plain wrong.
<infinity> People who can become root should be able to set "system defaults"
<whiprush> infinity: I can see where that could be a problem.
<Den> Anyone - is the Dapper flight 2 cd supposed to boot up properly?  Or, is it in a development state where it only boots to a busybox console?
<infinity> whiprush: I'm a Thinkpad user with ipw2200, but my plate is too full to even look at NM right now.
<Nafallo> Den: the former ;-)
<infinity> Den: It won't boot if you have an SATA CDROM.
<whiprush> infinity: fc4 and 2 suse releases have shipped with it, it just sucks that we kind of got stuck with the short end of the stick.
<infinity> Den: Otherwise, it should work for most pepole.
<Den> I have a ieee1394 firewire CD, SCSI on top of that 
<Den> That all works fine with the Breezy live cd
<infinity> Den: Oh, yes.  That won't work with flight2 either.
<jdub> Den: you have a firewire CD drive?
<infinity> Den: A more recent livecd daily build should work.
<Den> but the Dapper live cd doesn't boot - just to busybox console
<Keybuk> whiprush: yes, because the person the spec is assigned to is affected by that bug ;)  I can't do anything with n-m if it doesn't work for me <g>
<whiprush> infinity: thanks for your efforts though.
<infinity> Den: (Flight 2 forgot to load SCSI CD modules)
<whiprush> Keybuk: you too.
<Den> When will a fixed cd be available?
<infinity> Keybuk: Well, dude, if I'm blocking specs, by all means, whip me harder to get madwifi working for you. :)
<Keybuk> infinity: you'd enjoy it too much
<infinity> Yes, and..?
<Den> jdub: yes
<jdub> Den: rad ;)
<Keybuk> and I haven't got to the point of starting on that spec yet either
<Keybuk> it's blocked by jbailey too
<infinity> Den: http://cdimage.ubuntu.com/daily-live/20060106/
<whiprush> jdub: this is one of those situations where I totally rip off one of your sayings.
<Keybuk> and he'd definitely enjoy a whipping too much
<infinity> Den: No idea if today's daily works, but I see no immediate reason why it shouldn't at least boot.
<whiprush> "Ladies and Gentlemen, the Linux Desktop!!!" <self-trepanation>
<jdub> whiprush: and i correct your spelling? :)
<whiprush> always. :)
<Den> infinity: So this daily cd is basically as complete as the flight2 cd?
<infinity> Den: Same software, just newer (and completely untested, where flight2 had some testing before we announced it to the world)
<infinity> Den: Anyone willing to test dailies and file bugs gets a cookie, though.  So, that's something to look forward to.
<Den> Does anyone know if the daily live cd fixed the problem of loasing the scsi cd modules?
<jdub> infinity: how's rsync going with the dailies, btw?
<infinity> Den: Yes, that was fixed quite a while ago.
<Den> Thanks everyone - I'll try the daily cd.
<infinity> jdub: ETOOVAGUE
<jdub> infinity: is rsync allowing us to update CDs without stressing the tin cups and string?
<infinity> jdub: "Yes, rsync works fine", "Yes, we're keeping the diffs minimal through crazy tricks on the buildds", "Your mom"
<Den> As a final note, back to the original question, anyone know of a way to just pull the latest kernel, plus anything necessary for it to work, into a Breezy system on the hard disk?
<infinity> Yeah, our diff minimizing antics work pretty well for that (assuming you're updating from a reasonably recent ISO.. I image breezy-final -> dapper-daily might be a bit of a pain)
<pitti> Den: the latest kernel requires a lot of userspace changs
<infinity> Den: Your best (?) bet at that point is just to upgrade to dapper.  Which I don't recommend, unless you really like bugs.
<jdub> infinity: yeah, just wondering if it was still doing well during dapper (i was around for the antic development)
<pitti> infinity: I tried that, btw, and I got a speedup of 1.02
<Den> so, is there a simple way to acquire all the necessary userspace changes, or is that a nonsimple task?
<pitti> Den: the latter
<Den> infinity: thanks for the info.
<infinity> jdub: Seems to hold up well.  There've been some tweaks to it (late in the breezy cycle, went into production for dapper dailies) that make it a bit nicer still.
<Den> Thanks everyone. :)
<infinity> jdub: And it'll all go out the window when we switch to squashfs and have to develop new antics. :)
<infinity> (Which could be as early as Monday...)
<jdub> heh
<jdub> i'll dodge the download, then ;)
<jsgotangco> ahhh
<infinity> Den: Actually, I'm not sure if firewire CD drives will work... We fixed the SCSI issue, but we may not be including everything required to make your setup go.  I'd still appreciate it if you could test, though.
<infinity> Den: And if it doesn't boot, file a bug report on the "casper" package, pretty please (with sugar on top)
<jsgotangco> bye bye coaster
<Burgundavia> pitti, how do I say "If you speak German", in German?
<pitti> Burgundavia: "Wenn Sie Deutsch sprechen, ..."
<pitti> Burgundavia: but don't you need a sensible 'then' clause?
<Burgundavia> pitti, https://wiki.ubuntu.com/EdubuntuCommunity , see chat with us on IRC
<pitti> Burgundavia: ah :) that's fine as it is
<Den> infinity: gotch - will do.
<Den> Everyone - thanks for your work on ubuntu!
<Burgundavia> pitti, excellent, thanks
<Den> Anyone - Would Ubuntu consider creating a daily version that is "light" - ie, just the basic kernel, gui, etc, so it is much smaller than 600MB?  Is that a reasonable, workable possibility?
<Treenaks> Den: You can rsync the images. you'll only have to download a few MB each day that way
<infinity> Den: http://cdimage.ubuntu.com/livecd-base/20060106/
<Den> Can I rsync the daily to the flight 2 cd iso?
<infinity> Den: That won't even have a GUI, mind you.  Just the base system.  Should dump you at a console after it boots.
<infinity> Den: Yes, you can definitely rsync from flight-2 to the current daily.  Should save some time.
<Den> Ive never done rsync - would you give me a web page pointer on how to sync the flight2 iso to the daily?  If there is no such page, could someone put one up on the wiki in a day or so?
<Treenaks> Den: it's 1 command line.
<Den> Treenaks: do tell!
<Treenaks> Den: https://wiki.ubuntu.com/GettingUbuntu
<Treenaks> Den: at the bottom
<Treenaks> Rsync to get the latest ISO
<infinity> rsync rsync://cdimage.ubuntu.com/cdimage/daily-live/current/dapper-live-i386.iso ./my_old_iso.iso
<Treenaks> maybe -v or --progress in there somewhere
<Treenaks> if you want pretty progress meters
<infinity> And --partial if you don't want to cry if you lose your connection.
<Den> Thanks again, everyone!
* dholbach -> dogwalk
<Treenaks> pitti: is the blender USN screwed, or is it the same as the nbd one (except for the package name)?
<pitti> Treenaks: hm?
<Den> Does the daily, and also the flight 2 cd, not have the gui?  They are only console mode?  (That is what I'm concluding from your latest responses.  But, I had thought flight2 had everything the complete Breezy cd had.)
<Treenaks> pitti: the blender advisory in my inbox has a details section about NBD, not about blender
<Treenaks> (USN-238-1)
<pitti> Treenaks: oh, fuck, thanks for pointing out
* StevenK wonders how he can install his laptop with no removal media.
<Treenaks> StevenK: can it netboot?
<mvo> StevenK: boot with dhcp/tftp
<Treenaks> StevenK: (or use an USB something)
<StevenK> I can install using a USB flash disk?
<StevenK> I have a 1Gb flash disk, so I can mirror the CD. :-)
<pitti> Hey seb128 
<seb128> hi pitti
<Den> infinity: Will you please clarify this confusion you have caused me:  You said "That wont have a GUI, just the base system. Should dump you at a console.", but on the DapperFlight2 web page, it says that includes "aster GNOME start up times, improvements to the user interface, a shiny new optimized kernel, GNOME 2.13.3, OpenOffice.org 2.0.1 RC2, Firefox 1.5 and much more"
<Den> infinity: So, the synced daily should have the GUI, yes?
<Nafallo> lamont, infinity: could one of you clear the dep-wait on bsdgames, thanks :-).
<pitti> Treenaks: sent an update, thank you
<Treenaks> pitti: np
<pitti> Treenaks: *brown paperbag*
<infinity> Den: No, the URL I pointed at for "live-base" images is just the base system.  If you're downloading "daily-live", it will be just light Flight-2 (with a GUI)
<infinity> Den: You must have missed the URL I pasted right before I said "that one won't have a GUI". :)
<Den> infinity: OK, thanks for the clarification, I'll go back & reread what you'd said.
<Keybuk> weird, have there really been no uploads for 6 hours?
<Keybuk> or is something broken
<Treenaks> or both :)
<Keybuk> jdub: anything up with the lists servers?
<Keybuk> elmo: anything up with the archive?
<Znarl> Keybuk : Why do you ask?
<Keybuk> Znarl: because the last message to -changes was 6 hours ago
<StevenK> Znarl: By the way, I mailed in a admin ticket just over 3 weeks ago, about my ubuntu.com address ...
<Znarl> StevenK : Do you have the RT number handy?
<StevenK> Znarl: Sure. #1217
<Znarl> StevenK : Thanks, I'll chase elmo about it for you.
<StevenK> Znarl: Thanks.
<jdub> Znarl: btw, the mailman template customisations were lost during the transfer, so our archives don't look like LOVE
<Znarl> jdub : LOVE is important, I can fix that.  Can you create an RT request for archives LOVE to be restored?
<jdub> Znarl: yo
<jdub> mjg59: ping
<Keybuk> ok, my BAD brain just gave me the phrase "HOT BROWN LOVIN'"
<Znarl> Keybuk : Sorry. :(
<jdub> Keybuk: the train company in GTA:SA is called "brown streak"
<Keybuk> Kamion: well, I for one welcome our new HP overlords
<jdub> Keybuk: it always reminds me of, well, us.
<jdub> ubuntu: a series of six month brown streaks
<ogra> pitti, nope, i didnt, that was matt
<Kamion> Mez: 21959 shouldn't be WONTFIX; not entirely sure where the bug is though, but I think it must be either dpkg or coreutils
<Kamion> Mez: though adept could probably trivially work around it by doing chdir("/") right at the start
<Kamion> Mez: actually, apt does that, so let's say adept should too for consistency
<Kamion> dpkg can't do that itself across the board because it might be asked to install files from the current directory, although perhaps it should take more care when executing subprocesses that don't depend on that
<Kamion> it looks to be a relatively complicated problem from dpkg's point of view
<Keybuk> it should probably exec scripts in /
<jpetersen> hi
<Kamion> ah, and rm's fixed now too
<Keybuk> I like it when bugs do that
<Diziet> Kamion: I disagree.  I think that ought to be WONTFIX.  dpkg is entitled to assume that the world is sane, and dpkg (which runs as root) failing to have access to any relevant bit of filesystem is not sane.
<Diziet> Although coreutils isn't entitled to assume that so if that's the only problem then it's a real bug.
<Kamion> with any luck that's the only problem, and it's fixed in dapper
<Kamion> I do think adept and apt should be consistent though
<Kamion> either both should chdir(DPkg::Run-Directory), or neither should
<Kamion> particularly since adept uses libapt ... I wonder is it calling dpkg itself in some cases
<Kamion> Diziet: also, I think the current directory is only a "relevant bit of filesystem" to dpkg if it's installing a .deb with a relative path
<Kamion> in normal cases I don't want dpkg to depend on what cwd I happen to be executing it from
<Diziet> I think the cwd is always relevant.
<Diziet> For the purposes of it needing to be sane.
<Kamion> Only if you don't change it first. :-)
<Kamion> Of course I suppose you could be installing lots of .debs, some in a relative path and some in the current-directory-at-startup, so I can see how it would be messy for dpkg to try to handle that.
<Kamion> er, "some in an absolute path" I mean
<ogra_ibook> Keybuk, did you get the urls yesterday ?#
<Kamion> jbailey: does grub2's new scripting language support (aargh, MADNESS, but anyway) allow us to figure out the kernels available on any given filesystem on the fly rather than having to precalculate them?
<Keybuk> ogra_ibook: no, did you mail me them?
<ogra_ibook> nope i posted them here
<Keybuk> IRC is a lossy medium
<Keybuk> I don't keep more than ~50 lines of scrollback
<ogra_ibook> https://wiki.ubuntu.com/ThinClientAudioSupport and the implementation: http://people.ubuntu.com/~ogra/bzr-archive/ltsp/sound/
<Keybuk> can you mail those please
<ogra_ibook> Keybuk, not before tomorrow ... 
<ogra_ibook> my mailserver is broken, i'll replace it today
<Keybuk> ok
<Kamion> infinity: any idea why openoffice.org2 failed to build on powerpc? it got SIGABRT apparently
<Kamion> infinity: it built before, but mysteriously didn't get uploaded (maybe we gave it back before the uploader ran or something)
<seb128> Kamion: could you promote "libavahi-client-dev libavahi-glib-dev" so gnome-vfs2 builds again?
<seb128> (avahi has been accepted for promotion by pitti 2 days ago)
<Diziet> Hmm, my testbed only has room for another 3 installs (I give them 10GB each).  Maybe I should garbage-collect some of them.
<Kamion> pitti: xmltoman doesn't seem to have an inclusion report, so if I promote avahi, we won't be able to build it any more
<Kamion> build avahi, that is, until xmltoman's promoted
<pitti> *sigh*
<pitti> how many different implementations of xml->man converters do we have already?
<Kamion> p.s. somebody please fix jack-audio-connection-kit not to need type-handling, or akode not to need jack-audio-connection-kit, or something
<StevenK> pitti: As many as Debian?
* StevenK ducks.
<pitti> Kamion: I'll review it
<Kamion> pitti: also libdaemon has no report
<pitti> it's just a simple arch:all perl script anyway
<pitti> Kamion: xmltoman is fine, I'll write a report now and approve it
<Kamion> pitti: ok, stick it straight in the promoted section
<pitti> yep
<infinity> Kamion: Gah, you gave it back?  Meh.
<Kamion> infinity: I asked lamont to do it
<Kamion> I guess he didn't check
<Kamion> but either way, upshot is it's not in the archive :(
<pitti> Kamion: I already asked Riddell to dop jack from akode, and he said he already fixed it
<infinity> Grr.
<pitti> Kamion: we should keep jack in universe to leave it uncrippled
<infinity> Kamion: He gave it back RIGHT when it finished, so the buildd purged the files before it could move them to the upload directory.  Fine (and whacky) timing.
* infinity sets off to build it again.
<Kamion> pitti: ah, sparc is lagging on akode so anastacia still thinks it needs jack
<fabbione> Kamion: it will take no less than 12 hours to get it there
<fabbione> i can't build anythinig till gjc-4.0 is done
<fabbione> assuming it can finish
<fabbione> the circular depends between po-debconf/gettext/libgjc is a pain
<pitti> Kamion: libdaemon looks reasonable, I'll write a report, too
<pitti> Kamion: in fact such a lib is a nice idea
<pitti> Kamion: I'll put it right into promoted as well, shall I?
<Kamion> pitti: yes
<Kamion> seb128: ok, promoted now
<seb128> Kamion: thanks
<jbailey> Kamion: I can ask, but from the things they've shown me, yes.
<jbailey> Kamion: Part of what they had talked about was going through and putting a file or something that was unique in each filesystem and just searching for it.
<jbailey> Kamion: If you can search for files and construct arbitrary paths, looking in a directory and constructing arbitrary filenames seems like a logical step.
<Kamion> that would significantly improve boot menu usability on multiple-boot machines of which more than one of the installations is frequently upgraded
<jdub> mjg59: ping
<rikai> later all , to bed with me o/
<Den> Is there a way to boot into an ubuntu cd iso image on the hard disk?  ie, I'm running ubuntu, i have an ubuntu cd iso in /hda5/home/me/ubuntu.iso, now can I boot into that cd iso image?
<Treenaks> Den: burn it to CD, boot from Cd
<Den> Treenaks: yeah, I know that option
<Den> Treenaks: but how about what I asked about?
<Treenaks> Den: impossible / VERY hard
<Den> ok thanks
<Gagatan> Den: qemu -cdrom <iso-image> -boot d    slow as hell
<Gagatan> if you want to test e.g. a livecd
<Kamion> note that that emulates a machine booting that CD, though
<Kamion> it won't test whether your machine can boot it
<Den> so, as of today, in the linux world, there's no way to just plain boot like i described, right?
<Kamion> no
<Den> thanks
<ogra_ibook> i be you could do it with decent knowledge of the initramfs internals ...
<Kamion> ogra_ibook: it would need significant bootloader cooperation as well
<ogra_ibook> boot into busybox, mount the iso and boot into it ... but you wouldnt know if the kernel and booting in the iso works
* jdub pushes Kamion's stack for dapper+1 ;-)
<Kamion> jdub: bugger off
<ogra_ibook> s/in/of/
<jdub> heh
<jdub> Kamion: that bcm driver port just saved you from that mol userspace driver feature ;-)
<ogra_ibook> pfft 
<Kamion> I'm owed a release cycle of being able to clean stuff up as it is; was hoping it would be this one but that so didn't happen
<ogra_ibook> if it would work stable in any way
<BenC> bcm is stable for me
<ogra_ibook> if i go 10m away from my AP it hardlocks my system
<Treenaks> ogra_ibook: bcm43xx ?
<BenC> I haven't tried going out of range yet
<ogra_ibook> and if i run it at 54mbit my left knee melts
<BenC> are you running 2.6.15-11?
<ogra_ibook> Treenaks, yup
<ogra_ibook> not yet
<ogra_ibook> i'm still at -10
<BenC> you have yours working at 54M?
<ogra_ibook> yes, but it heats up heavily
<BenC> mine wont even link past 24M
<ogra_ibook> i have to drop to 11M
<BenC> this is in your ibook?
<segfault> is there any planned date for flight3?
<Kamion> segfault: I hope sometime next week
<ogra_ibook> BenC, yup
<BenC> Kamion: I'll try to keep the kernel ABI at -11 for you
<BenC> now that 2.6.15 is final, it shoudn't be such a moving target
<Kamion> good, thanks
<segfault> upstreamfreeze means universefreeze too, or just main?
<ogra_ibook> both
<segfault> humm, ok
<ogra_ibook> it was long announced that we'll do it this way this release because of the 3/5 year support cycle ...
<ogra_ibook> all MOTUs should know about it
<dholbach> although we should try to wangle a week or two more for universe - the motu crew had a bad time catching up on merges and were waiting on main merges in some cases as well
<segfault> how about new packages? like those listed in UniverseCandidates
<sistpoty> dholbach++
<ogra_ibook> if you can guarantee they'll get enough testing for being 3-5 years supported by motu ...
<ogra_ibook> dholbach, i thought that was clear anyway ...
<ogra_ibook> dholbach, i think we event talked about two weeks back then ...
<sistpoty> ogra_ibook: freezing upstream would be ok... but revu contains really many packages, I guess we'll never get these done in 9 days
<dholbach> ogra_ibook: there's enough time after that - we're talking about a week or two and universe is (although we'll try to take care of it) not supported anyway"
<ogra_ibook> 9 days ?
<dholbach> sistpoty: january 19th
<ogra_ibook> dholbach, sure
<sistpoty> dholbach: phew... thought of 15th for some reason :)
<segfault> i'll try to finish packaging dspam this weekend, it's a nice tool
<dholbach> but we should really do a hardcore review day soon
<seb128_> dholbach: you should get a system which makes easy for people to review quickly a package :p
<dholbach> seb128_: revu2 is in the works :)
* sistpoty hides in a dark corner and thinks that /me should do some revu2 hacking
* dholbach hugs sistpoty
<sistpoty> hehe
<dholbach> we should take the point to the next TB meeting
<dholbach> it's urgent our release team knows about our request
<ogra_ibook> ??
<Kamion> 'bzr shelve' rocks
<ogra_ibook> dholbach, it was already agreed on that universe might delay up to two weeks
<sistpoty> dholbach, ogra_ibook: maybe we should also do a motu-meeting again?
<ogra_ibook> no need to bring it up again
<ogra_ibook> sistpoty+++
<dholbach> Kamion: can you confirm this point? universe uvf == main uvf +2 weeks?
<Kamion> dholbach: https://wiki.ubuntu.com/DapperReleaseProcess explicitly contradicts that, but we'll be flexible with exceptions for universe
<ogra_ibook> it was topic in the discussion we had before dapper started and agreed on in a TB meeting ... as well as in the BOF at ubz
<Kamion> We have found in the past that newer universe packages tend to demand newer dependencies in main. Accordingly, universe will enter UpstreamVersionFreeze at the same time as main, in order to reduce dependency tension between newer versions of packages in main and universe. The exact details of sync and merge schedules will be the decision of the MOTU team. As in main, syncs and merges to universe after UVF must be verif
<mjg59> jdub: Hi
<Kamion> ^-- from the UBZ spec
<Kamion> having universe UVF later was brought up in the discussions, but we decided against it in favour of simply being flexible with exceptions
<ogra_ibook> hmm, you cut off the intersting part :)
<dholbach> How do we decide about NEW packages?
<Kamion> dholbach: that's the next sentence
<Kamion> ogra_ibook: where did it cut off?
<Kamion> dholbach: please read the spec
<dholbach> Kamion: merci beaucoup
<dholbach> yes
<ogra_ibook> As in main, syncs and merges to universe after UVF must be veri
<Kamion> must be verified to build and install on current Dapper (or exceptions granted for new or updated dependencies).
<ogra_ibook> thats all i got 
<Kamion> ogra_ibook: you could go and read the spec too though, it's just a copy/paste from that
<ogra_ibook> i'm just doing :)
<dholbach> Kamion: because that's what i need to know for AptGetOrg :-(
<mvo> dholbach: will we have to update our script again?
<dholbach> mvo: yes, it's broken atm :)
<dholbach> rejoice! :)
<mvo> dholbach: you broke it again :P ?
<dholbach> er err erm, must be err apt-get.org ;-)
<dholbach> i'll poke it
<mvo> let's setup a bzr archive for it and poke it together
<dholbach> mvo: later, food now, but i look forward to working on it
<Kamion> infinity: is there any way that, when downloading a new live CD cloop from cdimage, I could automatically find out the kernel version for which its initramfs was built?
<infinity> You could peer inside the initramfs and look at the /lib/modules/ directory...
<infinity> Or I could give you a manifest of some sort.
<Kamion> peering inside the initramfs involves mounting the cloop/squashfs or otherwise poking inside it, and generally is Hard Work
<Kamion> oh, no, I download the initramfs separately, don't I
<infinity> Well, no, cause I'm including the initramfs alongside the cloop...
<infinity> Yeah.
<Kamion> still kinda hard work though
<Kamion> oh, hey, it's in the .manifest already, isn't it
<infinity> I'm sure it's a one-liner with cpio.
<Kamion> cjwatson@little:~/cdimage/scratch/ubuntu/live$ grep ^linux-image-2.6 i386.manifest
<Kamion> linux-image-2.6.15-11-386 2.6.15-11.16
<infinity> Oh, duh.
<infinity> Also, DUH.
<infinity> Did I mention *DUH*?
<Kamion> ok, so in my copious free time I can make cdimage refuse to build images if the ABI of the kernel it's trying to use differs from that
<infinity> I'm just glad someone other than me didn't really think clearly for 2 minutes.
<Kamion> which will save a few coaster-quality images
<infinity> Oh, hrm.  You need the kernel when building?  Of course.
<infinity> Why don't I just dump the kernel in the same directory, solving the problem?
<infinity> And you can build with that one.
<infinity> Either a raw kernel or the .deb, or whatever you need.
<Kamion> that's a good plan, yes, just the vmlinu* will do
<Kamion> it's vmlinux on some architectures and vmlinuz on others, I think
* infinity nods.
<Mithrandir> you want the initramfs as well, don't you?
<infinity> I'll just cp -a /boot/vmlinu*
<infinity> Ish.
<Kamion> Mithrandir: already have it
<Mithrandir> 'k
<infinity> Mithrandir: Having the initramfs is the whole problem, really, since he needs a kernel to match. :)
<Kamion> yeah, will be some fiddling around when finding the kernel image, but it's the right thing to do
<Kamion> thanks, I'm glad *you* were thinking clearly for this one ...
<infinity> It's rare, but it happens.
<infinity> Any naming scheme you'll want for those, or just ${image-prefix}-${basename}?
* infinity hits royal to poke the whole "we have two kernels" thing and make sure he doesn't bugger it this time.
<Kamion> hmm, I think $image_prefix.kernel; my scripts need to know whether it's a vmlinux or a vmlinuz for each architecture *anyway*, so there's no loss in forgetting that information temporarily
<Kamion> but it can be .vmlinux/.vmlinuz if that's too icky for you
<infinity> Well, I was going to have the full kernel name, so you can quickly see the ABI/flavour, etc...
<infinity> Unless that's useless info to you.
<Kamion> it's awkward because I have to download it
<infinity> lftp does wildcards. :)
<Kamion> ... automatically
<infinity> (and is scriptable)
<Kamion> I don't mind the ABI/flavour being in the filename as long as there's a symlink with a consistent name
<infinity> Oh, yeah.  That's the sane way.
<infinity> Damn sanity.
<infinity> Actually, screw it.  The ABI isn't in the initramfs I copy, I'll take it out of the kernel too.
<infinity> And, as pointed out, the manifest has it.
<Kamion> "/usr/share/debconf/confmodule: line 40: return: set: numeric argument required"
<Kamion> Mithrandir: ^-- that's between "Shadow passwords are now on." and "Generating locales..." in live CD startup; don't know where the bug is
<Mithrandir> Kamion: can you run it with DEBCONF_DEBUG=. ?
<Mithrandir> I'm wondering if it's the debconf-communicate going awry
<Kamion> I think it must be after that given that it's after shadowconfig on
<Kamion> which is called by user-setup-apply
<Kamion> oh ... shadowconfig on writes to stdout. maybe that's confusing debconf
<Mithrandir> hmm, actually, I don't do any debconf-ish things between before user-setup-apply and long after locale-gen
<Kamion> oh, it *is* the debconf-communicate
<infinity> Kamion: Okay, testing on royal right now.
<Kamion> I think your shell syntax for newlines is off - the newlines are ending up in the value of passwd/user-uid
<Kamion> Mithrandir: you need a real newline rather than \n, I think
<Mithrandir> Kamion: I probably should use printf
<Kamion> Mithrandir: use a here-doc
<Kamion> debconf-communicate <<EOF
<Kamion> ...
<Kamion> EOF
<Mithrandir> ah, point.
<Mithrandir> I tend not to remember about heredocs
<Mithrandir> Kamion: I'll fix that and the make rofs mount visible to you after I've gotten the keymapper stuff working.  Might not be today.
<Mithrandir> heredoc fix done, though
<Kamion> Mithrandir: thanks
<jbailey> seb128: Why does gnomevfs2 now bring in avahi?
<Kamion> Mithrandir: you also need to >/dev/null debconf-communicate
<Mithrandir> Kamion: I know
<Kamion> ok
<Mithrandir> (done, committed)
<Mithrandir> Kamion: keymapper is causing me grief, though.  I can't get it to give me sane decision trees. :-(
<seb128> jbailey: because it's built with it? :)
* jbailey yars at seb128
<seb128> jbailey: it does dns-nd
<seb128> jbailey: you can automatically get the shares listes by nautilus then by example
<jbailey> seb128: Does it automatically find other machines / listen to mdns traffic?
<jbailey> seb128: Neat.  Does it do that by default, or do we still do no listeners by default?
<jbailey> I've had a few questions about networking machines together, so this'll be lovely to have.
<seb128> I don't really know the details (for mdns by example)
<seb128> it should list _ftp._tcp / _webdav._tcp / _webdavs._tcp / _sftp-ssh._tcp by default though
<Treenaks> seb128: how is this different from libnss-mdns?
<mvo> stupid question maybe, but why does it have this funny names "_ftp", "_webdav"?
<Treenaks> mvo: they are SRV records
<Treenaks> mvo: those have names like that, by convention
<seb128> Treenaks: I don't know, I've not really played with zeroconf stuff, I've no setup for that and I don't know how it works exactly
<mvo> Treenaks: aha, thanks
<infinity> Kamion: http://royal.buildd/~buildd/LiveCD/dapper/base/current/
<infinity> Kamion: That'll do?
<jk_work> on what kind of network could I expect to find actual zeroconf services?
<Treenaks> jk_work: any network with a mac on it ;)
<infinity> Kamion: (Arches with only 1 flavour get the convenience symlink, just like they do for the initrd)
<Kamion> fabbione: new rescue uploaded to Debian
<Kamion> infinity: perfect
<jdub> mjg59: still there
<jdub> ?
<mjg59> jdub: Hi
<jdub> yo
<infinity> Kamion: Okay, rolled out all over.  Should start working for you as things become installable.
<infinity> Kamion: Which, it looks like, I may need to dedicate a day or two to again...
<Kamion> infinity: ubuntu-desktop is installable, at least
* Mithrandir kicks the x11 keyboard parser in the nuts.
<Kamion> as is kubuntu-desktop. edubuntu-desktop is uninstallable though
<lamont> morning all
<slomo_> Treenaks: libnss-mdns is only for resolving hostnames... the gnome-vfs zeroconf support lists published services (at least the ones seb128 has said above) in "network"... similar to the samba support
<Treenaks> slomo_: ok.. so you still need both?
<Kamion> infinity: thanks! could you start off some builds with that now so that I can test out the cdimage side?
<infinity> Kamion: I can, but I dunno how many things other than base build right now...
* infinity goes to look at logs.
<infinity> Oh, actually, the world doesn't look that broken.
<infinity> Shock.
<mjg59> infinity: madwifi-ng crack kthxbi
<infinity> Kamion: I'll give you ubuntu on all arches to play with.  You don't need {ku,edu} too, do you?
<slomo_> Treenaks: depends on what you want to do :)
<Kamion> infinity: nope
<Kamion> yeah, I kicked various bits of the world last night
<zul> hey
<ogra> Kamion, hmm, i dont see anything that holds back edubuntu-desktop in dapper_probs.html or the cdimage report
<infinity> mjg59: It's a weekend project, I think.
<infinity> mjg59: Bug me on Monday if you've heard no news.
<mjg59> infinity: No problem
<Kamion> ogra: I haven't looked. If you want to, debootstrap a clean chroot with only main and restricted in sources.list and try to apt-get install edubuntu-desktop.
<Den> Den: Actually, I'm not sure if firewire CD drives will work... We fixed the SCSI issue, but we may not be including everything required to make your setup go.  I'd still appreciate it if you could test, though.
<Den> [01:10]  <infinity> Den: And if it doesn't boot, file a bug report on the "casper" package, pretty please (with sugar on top)
<Den> infinity: It didn't boot.
<ogra> Kamion, i will tonight... have ti rush to the DC now to replace my mailserver
<ogra> s/ti/to/
<Den> Anything you want me to do befor filing a bug report
<infinity> Den: Yeah, talk to Mithrandir.  He maintains casper. :)
<infinity> (and it's 1am for me, so I care about this much --><-- right now...)
<Den> Mithrandir: Dapper doesn't boot on my sony vaio laptop with cdrom in the base station.  cd is 1eee1394 firewire, using scsi to access.  DO you want a bug report filed?
<Mithrandir> Den: what module do you ordinarily use to access the firewire stuff?  I don't have any such beast here, so it'll be a bit hard for me to debug. :-)
<Den> Mithrandir: the Breezy llive cd boots fine] 
<Den> Breezy installed fine to my HD also, and that boots fine off the HD.
<fabbione> Kamion: great
<Mithrandir> Den: sure, but I need to know what modules to add.  If you give me that, I can fix it.  (And I'll need it if you file a bug as well as if you talk to me on IRC. :-)
<Den> I haven't loded any modules by hand - Breezy just worked.
<infinity> Den: Yes, but breezy used an entirely different method.
<Den> Be specific about what you want - yuo want me to boot breexy & do an lsmod?
<infinity> Den: It had a full debian-installer on the livecd, which would probe/load everything in existance.
<infinity> Den: The dapper setup is much.. Slimmer.
<Den> tell me specifically what info you need
<infinity> An lsmod in breezy would be a good start, yeah.
<infinity> We can spot cdrom/sr_mod in the lsmod output, and track up to see what's using it.
<tuhl> is there a specialized IRC channel for  ubuntu-server ?
<infinity> tuhl: Yes, #ubuntu-server.
<zul> yeah #ubuntu-server
<Mithrandir> Den: yes, the output of lsmod from an installed system which can access the ieee1394 drive should be enough for me to dig through
<Den> I was told a while ago (erm, this was on Debian testing from `1 yr ago, with a 2.4 kernel, that all that has to be done is 1st load ieee1394 firewire support, then load scsi on top of that, then the linux kernel will see the cdrom drive
<infinity> Den: Sure, but neither of us knows precisely what that entails, not having such a setup at all.  So, the lsmod output should be enough to know what we need.
<Den> Is Dapper live cd loding the ieee1394 firewire, then loading scsi (on top if firewire)?
<infinity> Mithrandir: Incidentally, we probably want this for USB CD drives too.
<Mithrandir> Den: it's probably not loading ieee1394.
<Den> is it easy to put ieee1394 into the daily build of Dapper - if so, I'll try it out asap
<Mithrandir> infinity: do we need more than usb-storage, [eou] hci-hcd?
<Mithrandir> Den: yes, it's easy.  My weekend is almost here and I'm dead tired, so I'm probably not going to upload any such changes until monday the earliest, but if I gave you an ISO, could you test it for me?
<Den> yes - but "give me an iso" how?
<Mithrandir> I can make one and you can download it over HTTP?
<infinity> Kamion: Looks like it's only going to succeed on i386/amd64, since OOo2 is still building on powerpc, and ia64 just looks completely horked.
<Den> can I rsync it from todays iso?
<infinity> Kamion: So, hopefully you can test on one of the former. :)
<Mithrandir> Den: that's a bit hard over HTTP. :-)
<Kamion> infinity: yeah, normally using i386/amd64 at the moment
<Mithrandir> Den: I could nuke the live part of the image, though, so it won't be a huge download?
<Mithrandir> Den: it won't _work_ that way, but we can check if it would have if it could have mounted the image
<Den> noo problem, just let me know where to get it from & I'll dl it, burn it & try it & tell you what happens
<Den> Mithrandir:  when will you have it ready
<Mithrandir> Den: give me 30 minutes or so
<infinity> 28326 pts/2    D+     0:00 dpkg --status-fd 8 --configure --pending --force-configure-any --force-depends
<infinity> Why.  The.  Fuck.  Is that in D state?
<fabbione> infinity: is that amd64 k8?
<infinity> Kamion: Does debootstrap hate me?
<Den> Mithrandir: I've gotta get ofline now, can you email me a msg as to what I need to do?
<infinity> fabbione: No, i386.
<Mithrandir> Den: sure, /msg or email?
<fabbione> infinity: o
<fabbione> k
<Mithrandir> Den: if email, I need your mail address
* infinity just wants to go to bed...
<Den> Mithrandir: hereon1@fastmail.us
<Mithrandir> Den: cheers. :-)
<Den> Mithrandir: do you still want the lsmod from my booted Breezy?
<Mithrandir> Den: yes, please.  tfheen@ubuntu.com
<Mithrandir> or /msg
<Den> Mithrandir: what is "/msg"?
<Mithrandir> if you do /msg Mithrandir you'll get a window where you can give me information privately.  Just so you don't flood the channel.
<Mithrandir> just type it into the window
<Den> I'll get you the lsmod in about 15 -30 min
<Den> thanks, bye
<Mithrandir> thanks
<infinity> Hrm, okay, maybe if another build hadn't been stuck in an infinite loop, the world may have been happier.
<Kamion> infinity: seems a bit unusual, that
<infinity> Kamion: Yeah, nevermind, the machine has half hosed, due to some retarded debian/rules looking for CPAN a few billion times per second, or something.
<Kamion> heh
<Den> Mithrandir: Ok, I got the lsmod in a  file - my nick isn't registered on freenode, so I don't thnk I can msg you, unless you turn on that capability from a nonreg nick.  You want to do that, or hae me email the lsmod to you?
<Mithrandir> Den: just mail it to me.  I thought I had turned it on, but freenode seems to turn it off nilly-willy
<Den> Mithrandir: It should be in your email now
<infinity> Kamion: amd64 is ready.  i386 is lagging due to the aforementioned infinite loop.
<Mithrandir> Den: great.  ISO is available at http://err.no/tmp/live-test.iso
<Den> I'm dling it already
<Den> thanks all, gotta get to sleep
<Den> bye
<Mithrandir> I'm off for the weekend.
<Den> Mithrandir: is ubuntu employer or volunteer for you?
<tseng> he's off :)
<Mithrandir> Den: I'm paid to work on ubuntu
<Den> Mithrandir: cool -n thanks for yuour help
<Den> bye
* infinity heads off to bed, finally.
<zul> why its only 1 am :)
<infinity> Thpt.
<pitti> elmo: please sync rus-ispell from sid
<infinity> Kamion: i386 done.  Now I'm gone for good. :)
<pitti> Kamion: 'check' approved as gst 0.10 build dep
* seb128 hugs pitti to make GNOME building again
<pitti> seb128: any other urgent reviews needed?
<Kamion> promoted
<seb128> pitti: urgent nop
<seb128> pitti: xchat-gnome uses libsexy but we can build without it and there is no hurry
<Diziet> I just got a random internal server error from bugzilla.  It went away when I reloaded.
<mdz> infinity: we shouldn't need to worry about file ordering with squashfs except as an optimization
<mdz> infinity: each file is compressed separately, as I understand it
<doko_> infinity: is openoffice.org2 still building on amd64?
<Kamion> doko_: it built ages ago
<Kamion> openoffice.org2 | 2.0.1-0ubuntu3-1 |        dapper | amd64
<pitti> doko_: you mean powerpc?
<doko_> Kamion: I can't see the build log on p.o.c/~lamont
<Kamion> doko_: were you looking in openoffice.org2 rather than openoffice.org2-amd64 by mistake?
<Kamion> it's there, under the latter
<doko_> and it's still the 2.0.0m143-0ubuntu3 in the archive
<Kamion> only for sparc
<Kamion> openoffice.org2 | 2.0.0m143-0ubuntu3 |        dapper | sparc
<doko_> Kamion: no, openoffice.org2 builds native packages on amd64 and suffixes them -experimental
<doko_> that will go away for the release, when we decide which packages we ship
<Keybuk> mdz: I have SUCH an elegant redesign of readahead :p
<pitti> Keybuk: dd > /dev/null? :)
<Kamion> doko_: amd64's excluded for openoffice.org2 in Packages-arch-specific
<Keybuk> every package that includes an init script should stick a file in /var/lib/readahead listing the things it reads from, or causes to be read, etc.
<lamont__> Keybuk: I don't think you're allowed to use the words "elegant" and "readahead" in the same sentence
<Kamion> doko_: you need to get elmo or lamont or infinity to update that if you want it to build there
<Keybuk> and in postinst call update-readahead if it exists
<Keybuk> and that looks through rc*.d and builds up early, middle and late lists and sorts the files by block on fs
<Keybuk> is shiny
<lamont__> doko_: %openoffice.org2: i386 sparc powerpc
<lamont__> and note that ubuntu uses the debian file, so changing it will mean that debian also tries to build oo.o2...
<doko_> Kamion: ok, just wondering why it built before ...
<Kamion> doko_: it didn't
<Kamion> cjwatson@jackass:~$ ls queue/done/openoffice.org2_*_amd64.changes
<Kamion> ls: queue/done/openoffice.org2_*_amd64.changes: No such file or directory
<Kamion> at least not as far as I can see
<doko_> lamont__: debian doesn'tz have ooo2 anymore
<doko_> apt-cache show openoffice.org2-core-experimental
<doko_> Package: openoffice.org2-core-experimental
<doko_> Priority: optional
<doko_> Section: universe/editors
<doko_> Installed-Size: 118164
<doko_> Maintainer: Debian OpenOffice Team <debian-openoffice@lists.debian.org>
<lamont__> ah, kewlness
<doko_> Architecture: amd64
<doko_> Source: openoffice.org2
<doko_> Version: 2.0.0m143-0ubuntu3
<doko_> lamont__: be we'll have the problem again when we rename the package
<mdz> Keybuk: tell me about it
<Kamion> doko_: ah, ok, last month before the last clear-out of queue/done then
<Kamion> maybe P-a-s was different then
<Keybuk> mdz: just did ;)
<doko_> btw, what version number should I use for breezy-updates?
<mdz> and I just read it ;-)
<lamont__> Kamion: if we built it, PaS didn't say not to
<mdz> I should increase my sliding response window
<Keybuk> oh, and it'll include an audit-me program you stick in your init script while testing and builds that list for you
<Keybuk> that daemonizes, loops reading the process table and maps for everything under its own parent process until its parent dies
<Keybuk> (where its parent = the init script)
* Diziet diverts bash to replace it with a strange wrapper.
<sabdfl> seb128: fyi, links in email are still not opening up firefox
<mdz> Keybuk: will that give high enough resolution to catch small files?
<jsgotangco> good evening
<Keybuk> mdz: should do; the other option is to strace, but that doesn't tell us (reliably) how the file is being used
* Keybuk wonders whether he can inotify /proc :p
<lamont__>  Diziet I just do that with gnome-session
<mdz> Keybuk: hmm?  the syscall arguments should make that clear enough
<Diziet> My mirror seems skew.  When do Release* etc. get updated ?
<Keybuk> mdz: true
<lamont__> Diziet: every 30 minutes or so
<Keybuk> easy enough to trace parent as well
<lamont__> at somewhere between :10 and :20, and again 30 min after that, roughly.
<seb128> sabdfl: what does "gconftool-2 -g /desktop/gnome/url-handlers/http/command" say?
<lamont__> depends on archive processing times.
<mdz> Keybuk: could also inotify everything which might be worth readaheading; it's only 20k or so directories ;-)
<mdz> Keybuk: or vm.block_dump
<Keybuk> doesn't block_dump indicate writes?
<sabdfl> seb128: mozilla-firefox %s
<mdz> is it only writes?
<Keybuk> dunno
<Keybuk> that's lower-level than I usually like to get
<Keybuk> at least, without protection, anyway
<mdz> When this flag
<mdz> is set, Linux reports all disk read and write operations that take place, and
<mdz> all block dirtyings done to files
<Diziet> lamont__: Hmm, tedious.
<Keybuk> does it say what asked for that though?
<lamont__> Diziet: yeah - I wrote a script that just smashes itself against the wall until the Release file is consistant with all the Packages/Sources files.
<mdz> I think it may have a pid
<seb128> sabdfl: what does "grep firefox ~/.gconf/%gconf-tree.xml" say?
<mdz> Jan  6 07:27:31 localhost kernel: [4786666.135000]  zsh(27642): dirtied inode 145441 (var) on sda1
<mdz> you would have to map the inode numbers back to files though
<mdz> since it doesn't provide the path
<Keybuk> of course it doesn't, that'd be helpful ;)
<lamont__> mdz: so /var/ is sda1?
<lamont__> or is var the inode on sda1
<mdz> lamont__: var is the name of a file in some directory on the filesystem on sda1
<mdz> e.g. Jan  6 07:27:30 localhost kernel: [4786665.979000]  workrave(6163): dirtied inode 2711137 (todaystats) on sda5
<lamont__> ah, ok
<mdz> that's /home/mdz/.workrave/todaystats
<sabdfl>                                         <stringvalue>firefox_launcher</stringvalue>
<sabdfl>                                 <dir name="firefox_launcher">
<sabdfl>                                                         <stringvalue>firefox_launcher</stringvalue>
<sabdfl>                                                 <dir name="firefox_launcher">
<sabdfl>                                                 <stringvalue>mozilla-firefox %s</stringvalue>
<sabdfl> ... repeat the last line 3 times
<seb128> sabdfl: seems you played once with the setting (from the GNOME capplet to set the default browser by example) and it's set as an user setting now, nothing we can change on upgrade from GNOME
<sabdfl> seb128: seems that we definitely we want to do something extra here
<seb128> sabdfl: firefox should really ship a mozilla-firefox to firefox link to avoid such breakage
<sabdfl> surely the postinst can find and correct these?
<seb128> postinst go visit all the user directory and change user datas... hum
<seb128> I would rather ship a mozilla-firefox compatibility link with firefox
<seb128> mdz: what do you think?
<seb128> mdz: some user have "mozilla-firefox" as default browser (user setting), and we changed the binary name to firefox since
<mdz> seb128: if it has the value mozilla-firefox and there is no mozilla-firefox in the default PATH, we should migrate it to firefox
<infinity> mdz: Ahh, slick.  (re: squashfs compression)
<mdz> oh, it's in the home dirs
<mdz> ick
<mdz> compat symlink sounds ok
<seb128> mdz: it's an user gconf setting, they changed it with the preferred app capplet ...
<infinity> Kamion / doko: openoffice.org2 got amd64 added to P-a-s a while back, but elmo probably needs a ping to sync.
<infinity> elmo: P-a-s sync, please.
<seb128> mdz: k, thanks
<seb128> sabdfl: are you ok with having a symlink mozilla-firefox/firefox to fix the issue?
<lamont__> keyboard chooser is still borked in the presence of no keyboard
<sabdfl> seb128: only partly. mdz, this is a good example of stuff the upgrade tool should be able to sort out
<mdz> sabdfl: yes, eventually, but it's beyond the scope of the first iteration we've specified
<Diziet> I'm currently trying to figure out whether this binary name change is anything to do with the x-www-browser breakage, btw.
<Diziet> Also, wasn't someone going to talk to Mozilla upstream to ask them if it was OK for us to call it mozilla ?  That would save a fair amount of pain.
<mdz> Diziet: does firefox even try to migrate the alternative?
<mdz> Diziet: jdub, please ping him on it
<Diziet> The maintscripts will remove the old alternative and provide the new one.  Which ought to migrate it.
<infinity> (If it hasn't been thrown into manual, due to a danling alternative link along the way)
<Diziet> jdub: AYT ?  Have you talked to mozilla about {mozilla-,}firefox ?
<infinity> Yay, update-alternatives.
<Diziet> infinity: I tested it and it didn't seem to mind dangling alternatives.
<infinity> Ahh, maybe the dangle is only a problem when creating an alternative.
<Diziet> Is the mirror update at :10 or :20 ?
<infinity> I know there's a dangling situation that will magically shove you into manual mode.
<infinity> Which sucks.
<Diziet> I mean, the ftp site update.
<Diziet> That's pretty crappy.
<Diziet> I'm about to test an instrumented upgrade.  As soon as I can get my mirror back into shape.
<infinity> Diziet: Starts at :03 and :33... Lasts as long as the cronjob runs, then triggers mirrors.
<infinity> Diziet: Roughly :20 and :50 for most mirrors, I'd suspect.
<Mithrandir> hmm, I think I gave Den an amd64 iso.. hope he has an amd64. :-P
<Diziet> I'm getting directly from archive.ubuntu here atm.
<infinity> Diziet: Right, which is a round-robin of mirrors, based on the real ftpmaster behind them.
<Diziet> The problem I have is that my mirroring program downloads md5sums at the beginning and Release* near the end (due to the way the alphabet happens to fall).
<Diziet> By the time it gets to downloading the Release* they don't match up any more.
<Diziet> Specifically, they refer to files not in the md5sums.
<infinity> Diziet: Fix your mirroring program to grab Sources/Packages/Release last.
<Diziet> The mirroring program currently doesn't have any Debian-specific knowledge.
<Diziet> It also assumes (not unreasonably) that there will be a quiet time for you to take the snapshot.
<infinity> Ahh, shame.
<Diziet> I could take a day to fix it to construct the mirror out of Release I suppose.
<Diziet> That would make mirroring specific suites possible too.
<infinity> The "anonftpsync" script used by most Debian mirrors works pretty well in the face of Debian/Ubuntu mirror processes.
<Mithrandir> infinity: yeah, or debmirror.
<infinity> Or that.
<Nafallo> apt-proxy wfm ;-)
<Kamion> sabdfl: on root-squashed NFS, of course, an upgrade tool running as root won't even be *able* to change user settings ...
<slomo_> infinity: please give-back gst-plugins-base0.10 on i386, thanks :)
<mdz> Kamion: I: Found additional base dependencies: modutils
<mdz> Kamion: do you know what's causing that?
<infinity> slomo_: Rebuilding.
<Diziet> In fact, my program downloads things in the order of the supplied md5sums.gz.  But the order listed is pessimal.
<janimo> elmo, please delete the xfprint and xffm4-icons source packages from the archive. They are deprecated by xfprint4 and xffm4 and cause needless confusion for users. thank you
<Kamion> mdz: various packages have Depends: modutils | module-init-tools; switching the order of the alternatives should make that go away
<janimo> weird, since latest ffox update I can't connect to the wiki
<Keybuk> modutils must die!
<doko_> infinity: do you know any reason that the bittorrent package is that behind in debian/ubuntu compared to upstream. you did the last sync ...
* Keybuk shakes his fist at it
<Kamion> Keybuk: alsa-base, alsa-utils, bluez-utils, pcmcia-cs
<Kamion> I'll fix pcmcia-cs now
<infinity> doko_: Not sure, no.  Haven't had a chance to poke the Debian maintainer about it.
<infinity> slomo_: Failed anyway.
<infinity> slomo_: Looks like an underlying library needs a rebuild before gst-plugins-base can build.
<slomo_> infinity: i'll take a look at it... it failed previously because of gstreamer0.10 FTBFS on x86
<infinity> slomo_: In this case, it's some build-dep referencing /usr/lib/libavahi-glib.la, which doesn't seem to exist.
<infinity> slomo_: So, install the build-deps, grep for that in /usr/lib/*.la, rebuild the package that owns the offending file, profit.
<slomo_> infinity: must be gnome-vfs2... seb128?
<Keybuk> Kamion: alsa-* are on my hit list at the moment
<infinity> slomo_: Or mail me about it (or bug me tomorrow) and I'll fix it.  It's too late for me to pretend to think right now.
<slomo_> infinity: np :) i'll take care of it and when it isn't fixed until tomorrow i'll tell you
<seb128> infinity: right, gnome-vfs2, I'll fix it
<slomo_> ok
* infinity again expresses his urge to remove all .la files from the distribution.
<mjg59> lala
<mjg59> libfoo.dipsy
<infinity> Maybe I'll just sneak a filter into dpkg, and see if anyone notices.
<pitti> infinity: pkgstriplafiles, we know the pattern :)
<zul> infinity: didnt you say you were going to bed :)
<janimo> infinity what's the problem with shipping .la files?
<infinity> zul: I did.  I got up again.
<janimo> I just recently had to relibtoolize a package
<janimo> because of missing libXft.la
<infinity> janimo: They're completely useless on GNU/Linux, and they break the world when they appear/disappear from version to version.
<infinity> Best if they're just never there in the first place.
<janimo> why do debian ship them?
<janimo> shouldn't this be a policy if they are useless and break stuff?
<infinity> Because "make install" generally installs them, and most people don't know/understand why they're evil/useless.
<infinity> I'd love to push .la stripping into some tool like cdbs, so it becomes a defacto policy overnight, then slip it into Debian policy.
* jbailey looks the other way.
<doko_> infinity: libltdl uses them to dlopen libs
<Keybuk> infinity: they're not useless
<Keybuk> they're required
<Keybuk> if you ship the .a file, you need to ship the .la file
<Keybuk> if you remove the .la file, you also need to remove the .a file
<pitti> so much the better :)
<Keybuk> and they're not evil
<pitti> I doubt that we need static libs for the majority of libs
<Keybuk> show me a problem with a .la file, and I'll show you a problem with the library
<infinity> Oh, feh.  The static case.  Right.
<infinity> Also, you're not supposed to care about libtool anymore, you gave it up.
<infinity> Anyhow, I guess I need to remove the part of policy about including static libs, while I'm being subversive.
* infinity wanders off to drug Manoj.
<Keybuk> I still care about being able to compile and link stuff ;)
<Keybuk> and I still know how it all works
<janimo> so is there another reason to remove .la files?
<janimo> I know libXft.la being recently removed caused a FTBFS
<infinity> According to Keybuk, we need more of them, not less. :)
<janimo> and needing to patch the upstream debian package
<janimo> daniels, you know why libXft.la is gone?
<infinity> janimo: At a guess, I'd say because Xorg now uses pkg-config to determine library dependencies.
<infinity> (which doesn't have the nasty side effect of telling you to depend on .la files, but instead tells you to depend on libraries...)
<Keybuk> hmm
<Keybuk> if there's a .la file with another .la file in its dep list, that's usually a bug
<lamont__> if I'm stupid enough to install xorg-server on a headless box, why does it ask me questions, I wonder...
<Keybuk> I went on a crusade about 18 months ago to purge most of those
<Keybuk> they should only occur if the other library comes from the same source
<infinity> Keybuk: That happens all the time.  That's the reason for the FTBFS that just happened.
<Keybuk> infinity: then somebody needs braining and being taught how to use libtool
<infinity> Keybuk: Package A builds against Package B when Package B has a .la file.  Package A's .la get B's .la listed in it.  Then Package B drops the .la file, and Package A is broken.
<Keybuk> Package A should only get -L/path/to/B -lB in it
<infinity> Keybuk: All of GNOME is apparently broken.  We ran into this time and again during the breezy cycle.
<Keybuk> where the -L would be dropped
<mjg59> Why has gedit vanished from the menus? Surely it's an application that people want to use to create things?
<Keybuk> GTK+ uses an infamously broken version of libtool
<seb128> mjg59: ls ~/.local/share/applications/gedit* ?
<mjg59> /home/mjg59/.local/share/applications/gedit.desktop
<mjg59> "NoDisplay=true"
<seb128> that's it
<mjg59> So why did that get set?
<seb128> that's the question
<seb128> some app must write it
<janimo> Keybuk, are platforms as varied today as 10 years ago as to be such a need for libtool?
<janimo> and autotools?
<mjg59> Hm, Odd.
<Keybuk> janimo: it's an interesting thought
<seb128> did you change the association for some mimetype with nautilus by example?
<Keybuk> sadly it's still true
<Keybuk> Solaris STILL doesn't have a decent link loader
<seb128> mjg59: BTW I just figured what was causing the nautilus crasher on partial upgrade you had
<seb128> mjg59: nautilus Depends on libnautilus-exnensions need to be updated
<mjg59> seb128: Ah, cool
<Keybuk> janimo: automake we'll need for ever, because it takes the pain away of writing decent Makefiles
<janimo> Keybuk,I'd hoped Makefiles would go away too ;)
<Keybuk> for a while, I vaguely linkered with building libtool directly into Automake, so it produced .c.o make rules, etc.
<Keybuk> janimo: what would you use instead?
<Keybuk> something has to specify how to build things
<janimo> one of the newer build systems
<Goshawk> hi, as you know the ubuntu-desktop package depends from a lot of packages, in particular it depends from usplash. now, can we change this dependece and set it to be usplash || upower. so upower can be installed without loosing upgrades
<Keybuk> you need a "this goes here, that goes there, use these switches, etc."
<janimo> scons/jam etc
<Keybuk> imnso, the newer systems are HORRIBLE
<Keybuk> with a syntax that came directly from the 18th level of hell
<janimo> they may be more horrible than make but not more horrible than make with auto*
<Keybuk> *shrug* I think they are
<Keybuk> auto* are easy
<Keybuk> autoconf is "write a bunch of shell code, and sprinkle in well-documented macro names"
<stratus> Goshawk, upower?
<janimo> to me it's the most ugly non-easy tool I have used
<Keybuk> automake is "write your makefile, and sprinkle in well-document variables to get the magic"
<janimo> including tla
<Keybuk> ?!
<Goshawk> stratus, yep, even more people in ubuntu use it
<pitti> janimo++
<Keybuk> bin_PROGRAMS = foo    (foo is a program that goes in .../bin)
<janimo> automake is ok
<Keybuk> foo_SOURCES = foo.c bar.c  (build it with foo.c and bar.c)
<janimo> but autoconf sucks
<Keybuk> that's easy
<Keybuk> autoconf's fine
<stratus> Goshawk, what's the source package name?
<Keybuk> a small file listing things your program need
<Goshawk> stratus, it's not in the default ubuntu report
<janimo> generating 800Kbyte file for a  30 Kb C project
<janimo> that's fun
<Goshawk> stratus, www.nanofreesoft.org
<Keybuk> if you have an 800KB file, you have someone who doesn't know what they're doing
<stratus> Goshawk, oh i see so it makes no sense to list it as a Depends, IMHO.
<Goshawk> stratus, or look for "upower" on ubuntuforums
<pitti> janimo: and it really bites your testicles off if you ever have to change anything in a > 6 month old package...
<Keybuk> the most important feature of auto* is that you don't need it to compile the programs
<stratus> Goshawk, by default you can't satisfy it.
<Keybuk> which just about every other "my first build system" fails on
<Goshawk> stratus, i suggest usplash || upower
<stratus> Goshawk, you should try merge upower changes back into usplash (if possible), if not you can try upload upower
<psusi> you don't?  you need it to generate the makefile so you can compile the programs
<pitti> Keybuk: I'd consider that a bug, not a feature
<janimo> Keybuk, I am sure it's a powerful tool, but it's so complicated most people (yes developers) don't really grok it
<janimo> myself included
<stratus> Goshawk, but (by default) you can't satisfy the upower part of this depends.
<Keybuk> pitti: why?
<janimo> and a lot of time is wasted on fixing this crap instead of the program itself
<Goshawk> stratus, so you suggesto to upload upower on the ubuntu repo?
<stratus> Goshawk, i bet that you'll receive this response but you can try open a bug against ubuntu-desktop through bugzilla
<Keybuk> imagine the hell if you got "Sorry, this source needs foobuild 1.0 and you have 1.1 installed"
<Keybuk> etc.
<Keybuk> which I have seen
<Keybuk> *cough* ant
<stratus> Goshawk, yes, let me look what's it
<Goshawk> stratus, it's like usplash but more eye candy
<pitti> Keybuk: there is a lot of redundant and big stuff, and updating it for bug fixes is painful and breaks too often
<Keybuk> Goshawk: and less working
<janimo> auto* is used so that every software can run on all old IRIX/AIX/HPUX whatever old PDP machines
<janimo> dictatorship of minorities as drepper sais it
<Keybuk> pitti: I agree, but I've never seen a replacement that solves that
<pitti> Keybuk: and autoconf/make is an great example of how backwards compatibliity should *not* look like :/
<janimo> it pulls the whole rest down
<Goshawk> Keybuk, until now all the signed bugs have been solved
<janimo> linux/bsd/solaris
<infinity> Goshawk: ubuntu-desktop will never depend on something outside of ubuntu/main.  Don't bother filing the bug report, please.
<stratus> Goshawk, talk with usplash folks and if they don't plan to merge the 'eye candy' stuff from upower, talk with MOTU folks and ask upower upload.
<janimo> for the rest handmade makefiles if they have users :)
<pitti> Keybuk: if it were backwards compatible, then it wouldn't even suck so hard, so maybe that's the actual source of my grief
<stratus> thanks infinity 
<Keybuk> Goshawk: does it work on all of the architures, and support every single graphics card out of the box?
<Keybuk> pitti: that's more Debian's fault.  auto* have been backwards compatible for years; Debian just have never used the versions that they fixed those problems with
<pitti> Keybuk: (although I still ask myself why I need a 500 byte patch for configure.in, and then a 1.2 MB patch for the resulting changes)
<Goshawk> Keybuk, it support all the vesa compatible cards, but it will broke the suspend mode right now
<psusi> I don't understand why people don't just write portable code that doesn't need hacks to work on various platforms
<stratus> Keybuk, is usplash supporting every single graphics card out of the box?
<Goshawk> Keybuk, many people have problem with upslash, try to look at ubuntuforums
<psusi> cause that's basically what auto* does... detect what hacks need enabled on your platform
<pitti> Keybuk: btw, that's one (of the few) things I really like about Java :)
<Keybuk> pitti: yeah, I agree
<Keybuk> pitti: one day I promised myself I'd write an automake-replacement that was as simple, but didn't need autoconf or libtool
<Keybuk> IN MY COPIOUS FREE TIME
<pitti> that you basically don't need a build system
<Keybuk> because I don't care about anything other than Linux
<pitti> Keybuk: *after* you finished wig&pen :)
<Goshawk> stratus, thanks for your support
<infinity> stratus: It supports any card that you can run a framebuffer on (unlike upower, which requires vesafb), so yes, close enough to supporting everything.
<Keybuk> pitti: meh
<stratus> Goshawk, you're welcome
<Keybuk> pitti: that'd involve me not resigning from Debian at some point ;)
<pitti> Keybuk: that would indeed be nice; I always looked for that kind of replacement, but it seems that scons is not the answer
<stratus> infinity, oh thanks.
<janimo> Keybuk oh and I forgot about automake-1.{X} but I think pitti said it
<Goshawk> infinity, not, it do not use modern framebuffer it uses vga16fb (and old one)
<infinity> Goshawk: It can use vesafb too.
<Keybuk> pitti: fancy designing it with me at the sprint? ;)
<infinity> Goshawk: We just use vga16fb by default (intentionally, no we won't change this)
<Goshawk> infinity, try to put vga=792 on your grub sources.list
<pitti> Keybuk: I basically have the same problem - I so much want it, but ENOTIME :(
<Keybuk> *nods*
<pitti> Keybuk: let's make it a high urgency dapper+1 spec goal :))
<Goshawk> i did not appair on my system with vesa framebuffer
<infinity> Goshawk: I run usplash with vesafb.  I also hack usplash, and co-maintain it.
<Keybuk> anyway, gonna go hack on laptop for a bit, otherwise I'm not gonna finish this stuff today <g>
<Keybuk> ping me if anything urgent, otherwise downstairs
<Goshawk> ok so it may be my fault
<stratus> infinity, what do you think is easier to hack to run on sarge, usplash or upower?
<infinity> Goshawk: If you have bugs to file, file them.  If you want to get upower included in universe, talk to an MOTU and get your packages reviewed.  If you just want to start software wars, please don't do it here.
<Goshawk> infinity, sorry ,starting a war was (and is not) my target
<Goshawk> this is why now i'll leave from this channel
<Goshawk> regards to everyone
<Goshawk> bye
<mdz> Lathiat: ping
<hunger> Isn't pcmcia-cs obsolete with dapper?
<hunger> Starting its init-script gives a message to use pcmcia-utils instead.
<hunger> bluez-pcmcia-support depends on pcmcia-cs (which in turn *-deskop depends on).
<Kamion> hunger: it will be obsolete, but not everything has been moved out of it yet
<Kamion> hunger: erk, the scripts in bluez-pcmcia-support really do require pcmcia-cs (/etc/pcmcia/shared); they'll need non-trivial porting
<Kamion> that said, I think bluez-pcmcia-support should eventually go away entirely
<hunger> Kamion: That is what I had thought. Just stumbled over this when upgrading.
<\sh> short question: where can I host some "official bzr archives" for ubuntu packages? is there any way for me to rent space on people.ubuntu.com?
<hunger> Kamion: Isen't one of the goals for dapper to trim down main? Somehow the Packages file does not seem to shrink:-)
* Simira got this nice old book from the library today called "Commodore 64 on adventure". An ancient book about how to write your own adventure game for C64.
<Simira> it was so old that the lady on the library gave it to me for free
<\sh> Simira: my own "adventure game" is named "turbo assembler" running on on c64 or vice  :) quite good to do some nice VIC and SID hacking again in my old days in 6510 :)
<\sh> so please welcome xterm-208...hope it's in the archive soon
* hunger tries to remember where he put his ZX81 manual after moving house.
<hunger> Ah... the good ol' days;-)
<lamont__> smurf: you around?
<Kamion> hunger: that's one of the goals, but there are others
<Kamion> \sh: people.ubuntu.com is behind the firewall and is accessible to employees only
<Kamion> \sh: I believe there's work progressing on hosting bzr archives on the supermirror
<smurf> lamont: ?
<lamont__> mad at dappers kbd-chooser
<Kamion> \sh: I hear xterm-208's in Debian unstable now; are we nearly at the point of just being able to sync it?
<Kamion> well, it's in incoming, anyway
<smurf> lamont: anything I can/should help with, or are you just venting? ;-)
<lamont__> smurf: installing on a headless system, it gives me the option to say no keyboard present (what it detects), although the default answer is 'type some keys' - which makes you reboot...
<\sh> Kamion: that's why I packaged this now again for ubuntu alone...well, i'll try to catch up with the debian maintainer
<lamont__> if I select 'no keyboard present', then it exits non-zero, which causes postinst to exit (set -e), which causes that step to fail.
<lamont__> smurf: if you're in a position to make it not fail postinst, that'd be cool.
<lamont__> for extra credit, if we don't find a keyboard, then 'no keyboard' should be the default answer, not 'type some keys'
<Mithrandir> lamont__: there's no way to detect a keyboard on most arches..
<smurf> lamont: well, that should be doable
<lamont__> Mithrandir: well, there is that...
<lamont__> Mithrandir: what are there besides USB keyboards? :-)
<Mithrandir> lamont__: however, not defaulting to type some keys probably makes sense on serial installs
<smurf> lamont: There's always the "oops, I'd better plug in the keyboard now" use case
<lamont__> Mithrandir: that'd work.
<lamont__> rivbht
<lamont__> right, even
<lamont__> but when the user says 'no keyboard here, kthxbye', we shouldn't die.,
<Mithrandir> sure
<lamont__> because that pushes me back into expert mode, which makes for lots and lots of questions...
<jsgotangco> good night
<\sh> Kamion: well...our xterm is a native package...could we sync it somehow? and after all debian is missing some patches...i'll file some bugs when I uploaded my bzr archive to tiber
<toresbe> janimo: A well-written makefile can be cross-platform. Auto* just ...automates that. In a horrid way, of course.
<Kamion> \sh: we can merge that by uploading a package built with -sa based on the Debian package, or else sync it once all our patches are in Debian
<\sh> Kamion: k....I'll check again the xterm-208 package from debian incoming 
<\sh> or at least I will sync it to debian with 209
<Kamion> xterm_208-1.tar.gz != xterm_208.orig.tar.gz so there's no fundamental problem with syncing
<Kamion> or merging
<Kamion> it's only when filenames actually clash and have different contents that there's a problem
<\sh> Kamion: so let's do it for 209...
<Kamion> \sh: ok, but why 209 in particular?
<Kamion> as in, why do you particularly need a new upstream?
<\sh> Kamion: because I want to see if upstream fixes some troublesome bugs...e.g. http://bugzilla.ubuntu.com/show_bug.cgi?id=20037
<\sh> Kamion: I actually don't know if it's a "daniels" bug or Thomas' bug
<Kamion> ok, fair enough, just making sure it wasn't due to imagined sync problems :)
<\sh> Kamion: he isn't quite sure if it's really an xterm or an xorg bug
<\sh> Kamion: and right now, debian is not ready for modular xorg...so we are alone at this stage
<jblack> Just so you guys know... I just lost my gnome-terminal during apt-get dist-upgrade
<Kamion> \sh: not for long
<Kamion> (see planet debian)
<\sh> Kamion: yes I read it :) but Thomas and/or daniels should have a look at this problem...
<Diziet> What a lot of effort to prove that a bug doesn't exist any more.  Oh well.
<mdz> Mithrandir: have you thought about how we might deal with network configuration in the live CD if network-manager falls through?  its future is a bit uncertain at the moment
<mdz> jblack: you lost it, or it didn't redraw for a whitle?
<mdz> s/whitle/while/
<\sh> Diziet: you mean /usr/lib/X11/app-defaults? well the prove to do is to install hoary, then upgrade to breezy and then with luck to dapper :) and see if it's magically gone..and it is :)
<jblack> It didn't redraw. After approximately 60 seconds I typed blindly, did a ctrl-alt-backspace, and everything came back fine.
<jblack> ran apt-get -f install, things seem fine
<jblack> firefox still ran, the menus still ran, the task switcher worked.
<\sh> Diziet: and therefore I reported the bug, and nobody else could reproduce it, so I think it was my stupidity or something else happened...anyways it's gone..
<Diziet> No, not app-defaults.  x-www-browser.
<\sh> Diziet: oh :) 
<Diziet> And compreg.dat too.
<Diziet> I can't reproduce that one but I don't understand where it's coming from so I'm not closing it just yet.
<Diziet> Frustrating to spend all afternoon setting up a test rig and then draw a blank.  Oh well, that's software development for you.
<\sh> well...I should get up and find something to eat. in the last couple of days I'm alive in the night..looks like that I transform into a vampire or my night life gives me a hint to search a job in the states or canada
* Diziet offers \sh a nice bulb of garlic.
<Diziet> (a) wards of vampirism (b) is food.
<Diziet> s/of/&f
<\sh> Diziet: when the garlic is on a pizza together with a lot of spinach I'll eat it :)
<\sh> oh well and it looks like gajim has some troubles with our new dbus...or upstream is not up2date somehow
<\sh> anyways...I need to get up and grab some food...laters
<Diziet> Damn, this computer is too smart for me.  I tried to crash it with the power switch but it's all ATX.
<Diziet> And it managed to shut down before I'd held it long enough.
<jbailey> Diziet: You don't have a hard on/off switch on the power supply in the back?
<Diziet> Not on this one.
<Diziet> This time I'm pulling it out of the 4-way.
<psusi> press and hold the power button for 6 seconds
<Diziet> Yes, but 6 seconds is too long.  It's managed to shut enough stuff down cleanly enough by then.
<Diziet> (More like 4 on this motherboard I think.)
<psusi> ohhh.... you're trying to simulate a power failure?
<Diziet> More or less :-).
<Diziet> firefox used to have a stale lockfile bug.
<psusi> if your kernel has magic sysreq enabled, hit alt+printscreen+b to instantly reboot
<Diziet> Which I think has gone but I want to check.
<Diziet> Mains lead is easier :-).
<psusi> then try to just kill -9 firefox silly ;)
<Diziet> It has more than one process sometimes.
<Kamion> kill -9 -1
<Kamion> but of course you'll probably need to reboot then anyway, so may as well pull the power in the first place
<Diziet> Quite so.
<Diziet> Besides, it's a scratch install so I don't care if I break it.
<slomo_> infinity, lamont: please give-back gst-plugins-base0.10 on x86... it really works now ;)
<Kamion> Is it safe to remove a widget from a GtkContainer while iterating over the items in that container with foreach? (If not, how do I remove all the widgets from a container?)
<Kamion> hmm, I could iterate over get_children I suppose
<slomo_> you could add all widgets to a list with foreach and delete them afterwards ;)
<Kamion> well, that's pretty much what get_children does anyway, so I'll do that
<janimo> Diziet I get a weird error after todays ff update: It cannot connect to ubuntu wiki, other sites work fine. It says I should make sure Personal Security Manager is installed
<janimo> and This might be due to a non-standard configuration on the server.
<janimo> I guess something to do with ssl? links connects fine to same site
<dholbach> mdz: ping
<Burgundavia> janimo, it might be the wiki. The site changed last night. If you are trying to go to ubuntulinux.org/wiki, it is going to fail
<janimo> from links it works
<mdz> dholbach: pong
<tuhl> seb128: When will we see GNOME 2.13.4 pakcages?
<dholbach> tuhl: all tarballs have been packaged and uploaded to dapper already
<dholbach> tuhl: gnome-session was just announced, so you can expect that soon too
<dholbach> I'll call it the day - have a nice evening.
<janimo> night dholbach
<sivang> hi all
<janimo> Diziet, ping
<Riddell> Kamion: any schedule for the next flight CD release?
<mdz> not as yet
<seb128> tuhl: 4 days ago?
<tuhl> seb128: the lastest are 2.13.4 - aren't they?
<seb128> tuhl: Ubuntu has current upstream tarballs yep, why?
<tuhl> seb128: ok my fault..
<seb128> tuhl: I don't get your question to be honest, what is wrong?
<tuhl> I was looking for the latest packages - now I see them in synaptic
<seb128> k
<\sh> re
<lamont__> slomo_: done
<thierry_> raphink : I've got a problem with my package, the makefile doesn't install the .so file (for shared librairy), I'm using CDBS, how could I fix this?
<jbailey> thierry_: Usually the best way is to fix the Makefile and send the patch upstream.
<jbailey> thierry_: If it's reasonable that the .so file be installed by default, it's best to make the package actually do that.
<segfault> seen mvo?
<AstralJava> Hi all, I apologize for a question that is a bit of support-nature, but is there anyone who has battled with irda? If that's the case, would that someone be willing to help just a bit with a problem loading irda modules? Once again, I'm sorry to bother you in this room.
<Tm_T> hehe, gnome/gtk filedialog segfaults :p
<Tm_T> that means, no artwork... oh well, not yet february ;)
<rikai> brb, installing memory <.<;
#ubuntu-devel 2006-01-12
<Den> Hi - 12 hours ago Mithrandir gave me a special distro that hopefully fixed a bug "no ieee1394 support loaded at boot time to access cdrom".  Then he left for the weekend. But he sent me a not 32bit version. Anyone here who can make the 1eee1394 firewire change & get me a new cd iso today?
<Lathiat> mdz: pong
<tseng> mako: there is a disgusting ammount of wikipedia data on the transformers
<tseng> mako: including a national guardsman who legally changed his name to Optimus Prime
<Burgwork> tseng, speaking of crazy fans, you seen Memory Alpha?
<tseng> Burgwork: no.
<Burgwork> tseng, think Wikipedia for Star Trek
<tseng> oh my
<Burgwork> my GF is a trekkie, so I have found myself being sucked back into that world
<tseng> I'm sorry
<Lathiat> Burgwork: memory alpha is cool :)
<Burgwork> Lathiat, I didn't say it wasn't. I was merely pointing it out the dedication to create that is a little crazy
<Lathiat> Burgwork: ya :)
<Mithrandir> mdz: well, assuming that we can do dhcp without bootup speed penalty, I think just default-configuring all network interfaces to dhcp should work well.
<Burgwork> Lathiat, why are you not on planet?
<Kamion> Mithrandir: except lo ...
<Mithrandir> Kamion: well, sure, but lo should be handled outside of /etc/network/interfaces, AIUI?
<Kamion> it isn't right now
<Kamion> but sure
* Kamion -> bed, just here briefly reading mail
<Mithrandir> Kamion: well, the parallell boot isn't here either, yet, so.. :-)
<seth_k|lappy> raphink, you about?
<raphink> testing wesnoth
<Simira> :)
<seth_k|lappy> could you archive http://revu.tauware.de/details.py?upid=1377 for me? :) \sh nagged
<Simira> wesnoth's fun
<seth_k|lappy> Simira, he means "play^W^W^W^Wtesting"
<raphink> hehe
<raphink> wanna play?
<dabaR> Hi. What is a good python+GTK tutorial?
<seth_k|lappy> raphink, sorry, but I have a dinner date in 30 min
<raphink> ah nice :)
<Simira> hmm... I think I didn't notice the amount of users in this channel for some time... it's grown!
<raphink> Simira: wanna play?
<Simira> raphink : it's bed-time (way past, really) here in Norway. Maybe another day?
<raphink> well here too I'm in France Simira ;)
<raphink> but tomorrow is saturday ;)
<Simira> hehe
<raphink> hehe
<Simira> well, I have a somewhat normal dayrythm now, and starts in a new job on monday, so I intend to keep it
<raphink> ok
<Simira> so, good night all!
<raphink> good night
<ispiked> who committed this? http://daniel-robitaille.blogspot.com/2006/01/whats-new-in-dapper-1.html
<desrt> oh man
<desrt> that hurts a lot.
<ispiked> desrt: you did that?
<desrt> i wouldn't have done such a thing
<slomo_> what exactly do you mean? the blog entry or the notification bubble?
<ispiked> yeah. whoever did needs to get slapped.
<ispiked> slomo_: sorry, the bubble.
<desrt> the bubble
<desrt> it looks ridiculous
<ispiked> complete waste of time. 
* desrt chooses to believe the blog entry is an early april fool's joke
<tseng> ispiked: next time you want to come and tell a developer they need "slapped" and about a "complete waste of time"
<tseng> ispiked: please run it through your filter a few more times.
<ispiked> tseng: that is my opinion that that dialog.
<slomo_> desrt: it's no joke... but i actually like it ;)
<crimsun> oh, so _that's_ why I haven't seen. I purged update-notifier.
<desrt> crimsun; me too :D
<tseng> ispiked: what if someone said your opinion was useless and you need to be slapped
* desrt got sick of donating all of his spare CPU cycles to it
<ispiked> tseng: then let them.
<Tm_T> ispiked: I partly even agree with comments
<ispiked> tseng: all that matters is that my opinion is heard.
<slomo_> ispiked: it's by the devs of notify-daemon / libnotify probably... tell them that it's bad and make a constructive propose what would be better...
<tseng> there are plenty more constructive ways
<tseng> to express an opinion
<ispiked> tseng: like?
<ispiked> tseng: commenting in that blog isn't going to do anything.
<tseng> of course not
<ispiked> tseng: I really came here to figure out who did it.
<ispiked> tseng: so I could ask them why.
<tseng> we have a bug tracker for problems with bad software ideas
<desrt> "<ispiked> i do not like the look of the new notification bubbles.  although i respect the developer who committed the change i call into question the judgement associated with making such a change."
<desrt> :)
<ispiked> heh.
<ispiked> there is no way this is in bugzilla.
<ispiked> someone would've caught it before it got in the tree.
<desrt> search for dups.
* ispiked gives up.
<HiddenWolf> I have to agree it's not pretty
<HiddenWolf> not my taste at all. :)
<slomo_> well, the tango icons are not my taste *shrug* ;) it's all a matter of taste...
<tseng> slomo_: they are alot cleaner than gnome, just a dumb pallet :)
<ispiked> it appears this is what did it: http://changelogs.ubuntu.com/changelogs/pool/main/n/notify-daemon/notify-daemon_0.3.1-0ubuntu2/changelog
<slomo_> tseng: maybe... i like the gnome ones better than the tango ones with the dump pallet ;) maybe i change my oppinion if they change the pallet...
<slomo_> ispiked: yes, the new upstream release ;) as i told you some time ago, better talk to the authors of notify-daemon or libnotify...
<HiddenWolf> slomo_, the icons are ok, the notification bubble is so, well, cartoonish. :)
<ispiked> e-mailed the guy who made the commit.
<nekohayo> anyone know if liblame0 will get into dapper soon? gst plugins ugly multiverse depends on it
<Tm_T> hm?
<Tm_T> gstreamer0.10-plugins-ugly is already the newest version
<Tm_T> installed here
<nekohayo> and there is a bunch of development packages for gstreamer missing
<nekohayo> no, there's gstreamer0.10-plugins-ugly-multiverse
<nekohayo> I think I saw that in the repositories
<Tm_T> that installs too
<nekohayo> ... huh? *checks again*
<crimsun> liblame0 _is_ in dapper/multiverse.
<Tm_T> btw looks like gst10 causes interesting problems
<Tm_T> *** glibc detected *** free(): invalid pointer: 0x08338ec8 ***
<Tm_T> anyway, sleep ->
<nekohayo> woah, I'm an idiot. Forgot to add multiverse in my sources list. Very sorry
<\sh> infinity: ping
<infinity> pong
<\sh> infinity /  lamont: if you have time please have a look at http://people.ubuntu.com/~lamont/buildLogs/liba/libaqbanking/1.6.1-1ubuntu1/ and tell me why the libchipcard2-0c2 not installable is? :)
<Riddell> \sh: it's libsysfs I think
<\sh> because it is
<Riddell> infinity: could you give back ksudoku, xlibmesa-gl-dev dependency has been removed
<\sh> Inst libchipcard2-0c2 (1.9.15.99+1.9.16alpha-1 Ubuntu:6.04/dapper)
<\sh> Riddell: this is in a dapper amd64 chroot
<\sh> and this version is needed by libaqbanking but libchipcard2-dev on our buildd doesn't know it that it's installable :)
<Riddell> \sh: it's something which depends on libsysfs1 but now we have libsysfs2 and it won't build against that
<Riddell> I just can't remember what the something is just now
<infinity> Riddell: Done.
<Riddell> yeah, it's libchipcard2
<\sh> Riddell: but it's installable..updated dapper chroot etc. pp.
<\sh> let me try again
<infinity> \sh: Is it installable WITH the other build-deps?
<\sh> infinity: give me 2 mins
<Riddell> \sh: and which libsysfsX do you have installed?
<infinity> (none, if it's a clean chroot)
* infinity is testing this right now, but "dselect update" is taking forever on his slow-ass DSL...
<\sh> well actually I have two...libsysfs1 and 2...but it's the same behaviour on i386...and there i have a clean one...moment
<\sh> well..pbuilder said it's installable...and builds...let me check the chroot
<infinity>   libchipcard2-0c2: Depends: libsysfs1 but it is not installable
<infinity> E: Package libsysfs1 has no installation candidate
<infinity> In other words, your chroot it dirty.
<infinity> Any other questions?
<\sh> but my pbuilder should be clean
<Riddell> and libchipcard won't build against libsys2, it fails on sysfs_open_device_tree
<infinity> Should be a small patch to fix for the API change, no?
<Riddell> dunno, need to find out what the API change is
<infinity> diff the headers, make educated guesses. :)
<Riddell> doing so :)
<\sh> oh yes
<\sh> Riddell: what about sysfs_open_device_path?
<Riddell> \sh: I think sysfs_get_bus_devices is the one
<Riddell> (advised from upstream)
<\sh> cool
* Riddell patches
<\sh> why don't they write something like that in the documentation when they're changing the API..
<Riddell> \sh: I think that assumes they have documentation for their API
<\sh> Riddell: somethings is in the sources in the docs dir
<\sh> a plain textfile
<mako> tseng: dude, a national guardsman changed his name to optimus prime.. that's awesome
<Burgundavia> mako, you have any experience with docbook?
<mako> Burgundavia: lots
<mako> Burgundavia: i did a bunch of stylesheet hacking in previous days :)
<mako> Burgundavia: whats up?
<Burgundavia> mako, having some issue with building a minimalist test case to test PNG in SVG in Docbook in yelp
<mako> Burgundavia: is this somewhere i can get to it?
<Burgundavia> mako, can I email you?
<fabbione> hey mako!
<fabbione> siretart: ping?
<Burgundavia> mako, does @ubuntu.com still work
<mako> fabbione: hey dude
<mako> Burgundavia: yesk, of course
<mako> Burgundavia: although i usually tend to get to the @atdot where you've been seeing mail recently more quickly
<Burgundavia> mako, ah, oops. Sent to @ubuntu.com already
<mako> Burgundavia: that's fine
* Burgundavia is reminded he needs to get writing for next week
<mako> Burgundavia: have you done anything yet?
<Burgundavia> mako, extensive outlines
<mako> Burgundavia: ahh, good 
<mako> Burgundavia: i'm not much better
<Burgundavia> mako, a year of experience with the source material is going to make the writing easier
* mako nods
<mako> Burgundavia: ok.. what are you using to build this?
<mako> Burgundavia: i cleaned up the XML so it's at least validating
<Burgundavia> mako, my test case?
<mako> Burgundavia: yes
<mako> Burgundavia: just using yelp, right?
<Burgundavia> mako, yep
<desrt> Burgundavia; thesis or something?
<mako> i did my undergrad thesis in docbook
* desrt did his in notepad.exe
<mako> you only make that mistake once
<desrt> hah
<mako> well, you usually only *get* to make that mistake once
<desrt> unless you do 2 undergraduate degrees for some reason
<mako> but if i were to go back now and write another undergrad thesis...
<Burgundavia> desrt, no, some technical writing
<desrt> tex seems popular in this part of the world
<mako> desrt: i think now that i'm working on a graduate degree, that would be unlikely
<desrt> well
<desrt> i'm working on my undergraduate thesis this term
<desrt> and i'm using abiword + a typesetter
<desrt> it works very well
<Burgundavia> mako, have you managed to figure out how I was being dumb?
<fabbione> Burgundavia: you are really really tempting me to say "by nature" :P
<Burgundavia> fabbione, explains why I am sales drone and not a developer
<fabbione> Burgundavia: ehhe a marketroid
<Burgundavia> no, not a marketroid, those are inferior. I am a Sales Drone!
<mako> Burgundavia: umm.. it's not yopu
<LaserJock> desrt: in my lab all of the dissertations, etc. are done with tex, being able to keep track of references is nice
<Burgundavia> mako, is it yelp?
<mako> Burgundavia: i'm not displaying ANY svgs
<mako> Burgundavia: pngs are working fine
<Burgundavia> mako, hmm, regression since the warty days then
<mako> Burgundavia: your XML was a little sloppy ;)
<Burgundavia> it was a little cut and paste
<mako> :)
<mako> in any case, PNGs are working fine but yelp on this ubuntu system does nots do SVGs
<Burgundavia> dapper or breezy?
<mako> breezy here
<mako> my gf is alseep in the room with the dapper box
<mako> and quite honestly, i probably should be too :)
<Burgundavia> http://bugzilla.gnome.org/show_bug.cgi?id=161374
<Burgundavia> mako, mind attaching what you found that bug?
<mako> Burgundavia: i'd like to try it against the version in dapper first
<mako> Burgundavia: i'll paste you somethhing useful though
<Burgundavia> my dapper box is currently not functional, due to the daily cd
<Burgundavia> and a small OO.o bug killing grub install
<mako> Burgundavia: ok.. i'll try this tomorrow
<mako> alright, off
<mako> 'night
<fabbione> night mako!
<Burgundavia> mako, thanks
<Den> Mithrandir: Did you get my email that the iso you gave me was not for 32 bit?   Do you have a 32 bit iso with the fix>
<Den> Anyone here who maintains anything about the boot process?
<Den> Anyone here at all?
<Den> BenC: Are you here?
<Den> ubuntu-devel has gone to bed.
<fabbione> Den: it's weekend.. most of the people are resting :)
<Den> Ah! a living thing!
<fabbione> no
<Den> fabbione:  Are you a developer?
<fabbione> i am a bot answering machine
<Den> Please don't be telling the truth!
<Den> Do you know anything about the boot sw?
<fabbione> Den: it depends.. just ask
<Den> So, yesterday Mithrandir  made a fix to try to enable ieee1394 firewire, and gave me a url to dl an iso, but it was not for 32 bit, & didn't work.
<Den> Are you able to access the relevant code, fix it, & get me some code to see if the firewire scsi boot can be made to work?
<fabbione> no
<fabbione> you need to wait for Mithrandir 
<Den> I see Mithrandir is showing up as online for this channel 0 do you know if he'll be around?
<Den> PS, what ubuntu devel stuff do you work on?
<Amaranth> i wonder if he'll try to get the squashfs-lzma change in for dapper...
<fabbione> Den: again.. it's saturday :) people might not be around till Monday.
<Amaranth> Mithrandir has been idle over 6 hours
<Amaranth> yeah, i know seb128 isn't around on weekends
<Den> Is there some info about who does what for ubuntu development?  A wiki or regular web page, perhaps?  An article, or interview online???
<fabbione> Den: all these questions are FAQ. please use #ubuntu
<fabbione> or read up on wiki.ubuntu.com
* fabbione declares weekend time
<fabbione> cya on monday guyes
<fabbione> guys
<Amaranth> bye
<Amaranth> have fun
* Mez uses Keybuk in an example
<Mithrandir> Den: yes, or rather, I remembered on my way home.  It's a bit awkward for me to make a new one from home, so if it's ok with you, I'll wait until Monday to create a new one for you.  Is that ok?
<pitti> moo
<infinity> You really need to stop showing up 10 seconds after I upload imagemagick..
<Mithrandir> hi infty
<infinity> Hey Toilet.
<Mithrandir> pft
<infinity> :)
<pitti> infinity: heh, bad timing?
<infinity> pitti: For dapper, you probably shouldn't worry too much about imagemagick security anyway.  Looks like the most frequent NMUer (korbas) has been hacking on several patches recently, and he told me he'd be uploading, incorporating my NMUs, pretty soon.
<infinity> pitti: Of course, that still leaves us on our own for warty/hoary/breezy, but whatever.
<infinity> pitti: So, I'm just going to request a sync of my most recent upload, and let autosync sort out dapper.
<pitti> ok, thanks for notifying
<pitti> sounds good
<infinity> (And no, I will NOT be joining any imagemagick teams in Debian, this was a one-time NMU...)
<infinity> Hey Ben.
<infinity> Or is that just connection bouncing?
<infinity> Probably.
<pitti> infinity: BenC does that all the time
<infinity> Yeah.  Of course, occasionally, it's actually him. :)
<jdub> does anyone build/maintain breezy+xen kernels?
<crimsun> hunger may.
<Mithrandir> infinity: did you find a round tuit to get the initramfs-usplash-changes uploaded?
<infinity> No, but I'm excavating the yard for tuits tomorrow.
<infinity> Should get a bunch of work done, despite it being a Sunday.
<Mithrandir> uhm, it's sunday at your end?  I thought you only were ~10 hours ahead of me?
<jdub> hrm, i should totally visit clarkson university
<jdub> they do lots of ubuntu stuff
<Mithrandir> jdub: where is that?
<jdub> new york
<jdub> state
<Mithrandir> ahkay
<infinity> Mithrandir: No, but tomorrow is Sunday, and I was talking about finding tuits tomorrow. :)
<jdub> http://xen.cosi.clarkson.edu/?page_id=8
<jdub> you guys seen this? it was a summer of code project
<Mithrandir> infinity: ah, point.
<jdub> d-i support, kernel images, etc.
<Lathiat> cool
<Mithrandir> jdub: I've seen it a tiny bit, at least, yes.  I think the guy who did them has been around here a bit, but I can't remember his IRC nick.
<jdub> there is a dude called jeremy bongio working on it
<jdub> that is the coolest name EVER
<Burgundavia> jdub, ed despard was supposed to be paid by Ubuntu for that work
<jdub> looks like he got paid by google
<Burgundavia> jdub, he was dropped by google for non-responsiveness but then appeared in Sept. with his finished work
<jdub> ahr
<Burgundavia> jdub, seen this? http://pim.kde.org/playground/osnabrueck4/
<jdub> nup
<Burgundavia> http://www.kdedevelopers.org/node/1732
<Lathiat> 
<ulaas> hi! any idea whats wrong with monodevelop and deps?
<tseng> yes, im fixing it
<tseng> check in an hour or two
<ulaas> tseng, oh great thanx man
<tseng> np.
<jdub> BenC: dapper kernels are built from tarballs of the ubuntu git branch, right?
<infinity> jdub: Pretty much, yep.
<Simira> jon_kare : norsk?
<jon_kare> Simira: ja
<Simira> jon_kare : hyggelig. Kan ikke huske  ha sett deg i ubuntu-sammenheng fr. Jeg er kontaktperson for Ubuntu Norge.
<Gagatan> hei jon_kare - lenge siden sist :)
<jon_kare> hei
<jon_kare> (realname var forstelig)
<Gagatan> traff p en annen tidl. kollega oppi lypa her ogs.. skalvise.. Ole Enge
<Gagatan> og Magne kommer p middag.. fr vel forberede litt snart
<hunger> Gagatan: Could you please switch to english? Your language causes my irc client to beep:-)
<Gagatan> haha :)
<Gagatan> hunger: sorry.. just said hello to some former co-worker of mine :)
<jon_kare> 
<hunger> Gagatan: No problem:-)
<hunger> Hi pitti.
<Gagatan> hunger: and I met a second former co-worker also skiing cross-country
<pitti> hi again
<hunger> jon_kare: Your text is displayed properly.
* hunger marvels at the wonders of character encodings once again.
<Simira> hehe
<zakame> elmo: please sync linkchecker from Sid, overriding Ubuntu changes ok, thanks :)
<azeem> so Ubuntu changed xmakemol's xlibmesa-dev B-D to "libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev", while Debian did "xlibmesa-gl-dev"
<azeem> is there a common denominator?
<zakame> hm why is lesstif2 not in dapper yet?
<zakame> (after its split from lesstif1-1, I mean)
<pitti> zakame: s/yet/any more/
<pitti> zakame: because it's crack, and we don't want/need it
<pitti> zakame: btw, we threw it out in breezy already
<zakame> pitti: indeed... well, was asking 'coz xmakemol seems to need it
<pitti> zakame: that's universe too, so it shouldn't be a problem?
<sebest> hi, when a bug in malone is target to be fixed in ubuntu without a specific release, should we close it if it's fixed in dapper?
<sebest> i'm talking about bug 5690
<pitti> sebest: yes, unless it's a security bug
<sebest> it's just a typo in a manpage
<sebest> so i close it
<pitti> sebest: yes, thanks
<zakame> pitti: chninkel has been trying to merge that package, and thus hit that snag
<pitti> Kamion: here?
<Kamion> pitti: yes
<pitti> Kamion: is the current failure of live CD known? "User not known to the underlying authentication module" - and ubuntu doesn't autologin (gdm loop)
<Kamion> no - that would be Mithrandir's problem I guess
<Kamion> oh, gdm doesn't refuse to log in system users, does it?
<pitti> Kamion: no idea, but the VCs don't work either, so I can't login
<Kamion> we now set the ubuntu user to uid 999 to help out espresso
<pitti> hm, maybe it's that
<infinity> "not known to the underlying authentication module" sounds like PAM told GDM "nu uh" to me.
<Kamion> MinimalUID=1000
<Kamion> hmm
<pitti> Kamion: I'll file a bug then and talk to him
<Kamion> assign it to Mithrandir
<pitti> yep, thanks
<infinity> Or, GDM has crappy error messages. :)
<pitti> infinity: that message is from VC1 (syslog, I guess)
<pitti> gdm only tries to login and respawns without any message
<Amaranth> pitti: what's wrong with lesstif2?
<pitti> Amaranth: oh, we just got fed up with fixing security bugs in it, and we don't need it any more
<pitti> Amaranth: we just needed it for xpdf
<Amaranth> ah
<Amaranth> well, less work for you, that's always good :)
<zakame> ah indeed
<irvin> pitti, must really have a boring job ;)
<zakame> thanks pitti , Amaranth :)
<azeem> pitti: so why didn't it get demoted to universe?
<pitti> azeem: erm, I did?
<pitti> oh, wait, hmm
<pitti> azeem: it was in universe in breezy, I didn't touch it since then
<azeem> well, people claimed it is not available, which sparked the discussion
<pitti> no idea why it was removed completely
<azeem> AIUI, it is built from a new source package now, which never got synced
<azeem> but that is only from looking at IRC in passing
<Kamion> lesstif2 is on the sync blacklist
<Kamion> I imagine this is because the binaries were previously in a different source package, which tends to break syncs
<Kamion> now that the binaries have been removed from lesstif1-1, it can probably be synced again
<Kamion> talk to elmo to get the blacklist modified
<Amaranth> so, maybe lesstif2 on monday, but still lots of security issues
<Kamion> gtk-smooth-engine libxrender pygame xffm4 gnotime ispell-fi gcc-3.3 kgeography gnunet-gtk gutenprint initrd-netboot kde-icons-nuvola kde-style-lipstik mysql-dfsg-5.0 renderext zopeinterface allegro4.2 lesstif2 octave2.9 gal firefox-locale-ca firefox-locale-eu
<Kamion> ^-- current sync blacklist
<pitti> mysql-dfsg-5.0? ah, now I know why it isn't there
<Amaranth> gutenprint :(
<Amaranth> i thought gimpprint got dropped with the first sync
<Kamion> generally all those are there because they broke for some reason, usually binaries also in other source packages
<Amaranth> wait, i think seb128 was going to wait until after flight 1...
<infinity> pitti: Yes, we need to get it unlisted on Monday, so I can start the transition. :)
<pitti> infinity: I assume it was blacklisted due to mysql-common; I made 4.1 build -common right before the breezy release AFAIK
<infinity> pitti: Yeah.  We'll sort all that.
* infinity heads to bed.
<pitti> sleep well
<pitti> hmm, install CD asks me for a proxy although I told it to leave network unconfigured...
<Kamion> known bug, reported many times, in Flight CD 2 release notes
<Kamion> it's a consequence of the shift to apt-setup (although not unfixable)
<pitti> ah, known
<doko_> Kamion: wondering why gcc-3.3 is on the blacklist
<Kamion> doko_: don't ask me
<Kamion> I said above why (to my knowledge) packages are added to the blacklist
<chninkel> where can we find the sync blacklist ?
<Kamion> chninkel: I pasted it into IRC about twenty lines back
<chninkel> Kamion: I saw, but I mean if I want to have the last sync blacklist
<Kamion> it's not in any public location
<chninkel> Kamion: ok
<Kamion> maybe when the archive switches to launchpad it will be; there's no intrinsic reason for it to be private
<zul> heylo
<hunger> Hmmm... http://www.zegeniestudios.net/ldc/index.php claims ubuntu is not suitable for beginners.
<tseng> people claim many things
<jpatrick> pieces of land, etc
<HiddenWolf> hunger, check their reasons, if they are logical and solvable, discuss.
<HiddenWolf> hunger, things we can do nothing about, that can't be helped. and can just be that a fanboy wrote it.
<HiddenWolf> there are a thousand of these things every month.
<hunger> HiddenWolf: It is a distro-test recommended by prolinux.
<jpatrick> hunger: that site recommends Gentoo to me
<jon_kare> "Failed these criterias:" (sic!)
<jon_kare> May require prior Linux knowledge
<jon_kare> Not suitable for beginners
<jon_kare> Requires partitioning knowledge
<jon_kare> Exactly the same as for Debian.
<jon_kare> When I answered honestly, it recommended Ubuntu *and* Debian
<jon_kare> I suspect the test doesn't know the difference
<LaserJock> sorry, what is the URL for that test?
<pitti> good night
<chninkel> does someone know why GLw was dropped in mesa packages ?
<Amaranth> chninkel: GLw?
<chninkel> Amaranth: seems to be opengl for lesstif
<chninkel> Amaranth: from mesa changelog
<chninkel> mesa (6.4.0-0ubuntu1) dapper; urgency=low
<chninkel>  * Resynchronise with Debian; drop GLw (lesstif) and DirectFB support.
<Amaranth> is it in another package?
<chninkel> I didn't find
<\sh> elmo: please sync omnievents from debian, dropping ubuntu changes thx
<nekohayo> does anyone know the *reason* why gecko-based browsers are borked? (I'm just waiting patiently for a fix, but in the meantime I am curious)
<nekohayo> oh wait.. the browsers started working again.. hurrah :) nevermind
<marcin`> hello guys
<marcin`> texinfo package in dapper is currently broken
<zul> please open a bug
<marcin`> postinst script says that there is no `update_ls_files` command
<marcin`> could someone tell me what is this command from?
<tuhl> when will be see a working beagle nautilus integration in drapper?
<HiddenWolf> tuhl, it's dapper
<HiddenWolf> tuhl, and ask upstream
<Burgundavia> tuhl, not for dapper
<tuhl> ok
<tuhl> while updateing I just saw a deinstallation on beagle
<Burgundavia> tuhl, I believe the nautilus stuff is already there, we are just not going to ship beagle by default
<slomo> tuhl: that's another problem... i'll fix it now, thanks for noticing :)
<tuhl> slomo: can I reinstall beagle right now?
<slomo> no, not yet
<tuhl> slomo: ok I wait
<slomo> maybe already in one hour :)
<tuhl> slomo: will you raise the version number?
<tuhl> tu ubuntu3?
<tuhl> what kind of search mechanism is used without beagle? find and grep?
<slomo> tuhl: no, it will raise the version number of gmime2.1 / libgmime2.1-cil
<jbailey> Anyone know how edubuntu solves the swap-over-nfs/nbd problem?  Or do they just not bother with swap?
<neuralis> Burgundavia: i seem to recall there were plans to ship beagle with dapper, weren't there?
<Burgundavia> neuralis, yes, but then we went for stability
<Burgundavia> and less memory leaks
<Burgundavia> I expect dapper+!
<Burgundavia> 1
<neuralis> Burgundavia: probably fair, beagle isn't quite the shining beacon of stability
<tuhl> NLD 10 will contian it
<tuhl> contain
<Burgundavia> when is that due?
<\sh> NLD?
<neuralis> \sh: novell linux desktop
<\sh> ah...
<jbailey> Burgundavia: Stability good, occasionally. =)
<jbailey> Burgundavia: Of course that means all the pent up frustration would be let out for +1. =)
<Kamion> hmm, must figure out if I can get user_xattr turned on by default in the dapper installer
<Kamion> that request's been on the table since Sydney
<\sh> then it makes sense to have something like this in .... they need to increase their support fees ,)
<Burgundavia> jbailey, I expect xen and beagle and all the crackish things to fly
<Kamion> (and is needed for beagle, I'm told)
<jbailey> Burgundavia: Dapper +1 also has major toolchain love planned for it.
<Burgundavia> Kamion, don't think it is needed anymore
<neuralis> Kamion: it's not strictly required, but there's hellpain without it.
<Burgundavia> jbailey, dapper+1 is going to be so broken
* Kamion flips a coin and decides to take neuralis' word for it on the grounds that there's more information in that statement. :-)
<\sh> jbailey: major toolchain? what is coming for dapper?
<HiddenWolf> Burgundavia, more than breezy? ;)
<tuhl> NLD : April
<jbailey> \sh: gcc-4.1 bring a pile of new Java love.  glibc-2.4 is a year and a bit of development effort.
<Burgundavia> Kamion, beaglewiki says "optional but recommended", then talks about a fallback sqlite backend
<jbailey> \sh: And so far noone's said anything bad about dropping pre-i686
<Kamion> Has there been any progress on fixing mono/powerpc? I see it's still uninstallable.
<neuralis> Kamion: read that as 'whenever we get around to shipping beagle, we really, really want to have user_xattr turned on' ;)
<jbailey> \sh: With any luck, that will also bring multiarch to the archive.
<Kamion> neuralis: these things being what they are, doing it in advance is good (since fresh-install is the only point when we get to change people's partitioning options)
<neuralis> Kamion: aye, agreed.
<slomo> Kamion: it's most probably a buildd problem... it can't be reproduced on other machines than the buildd, no matter how similar they are
<HiddenWolf> Kamion, afaik beagle (when I tried it) only manages to find things like gaim logs and e-d-s data without xattr
<\sh> jbailey: but it won't be any stress like breezy and gcc3.3 to gcc3.4/4.0?
<slomo> Kamion: and on the buildd even older mono version, even in a breezy chroot ftbfs
<jbailey> \sh: Anytime there's a major toolchain decision, there's always stress.
<jbailey> \sh: The problem is that you can't forsee what the stress will be.
<\sh> .oO(if jbailey says "Yes" now, then I have to find a good weapons shop(
<slomo> jbailey: what major changes are planned for glibc 2.4? :)
<Kamion> slomo: kernel issue? the buildds are running 2.6.8.1, iirc
<doko_> slomo: ssp
<Kamion> HiddenWolf: ok, I'll see if I can turn it on in partman soon, then. Last time I tried it was unduly painful to do, but I could try to make it easier upstream.
<\sh> jbailey: ok so the normal stress...but not "transition stress"
<jbailey> slomo: It will be possible to audit the linker.  We'll drop LinuxThreads.  A bunch of internal cleanups.
<jbailey> \sh: Well, consider that this last C++ allocator transition wasn't expected.
<slomo> Kamion: no idea, i have no way to make extensive tests... i have no ppc64... but tseng has written a mail to lamont and infinity about it
<jbailey> \sh: That's what I mean by it's not predictable.
<\sh> jbailey: well...it wasn't much :)
<jbailey> Sure, luckily.
<HiddenWolf> Kamion, last time I saw beagle in action it caused jdub's ext3 to give out during a badger talk due to xattr mess, so i'm not pushing too hard. :)
<\sh> jbailey: lets see when we can drop python2.3 completly
<jbailey> =)
<Kamion> slomo: oh, hang on, what is it that fails to build?
<Kamion> mono_1.1.9.2-1ubuntu1_powerpc built fine
<Kamion> oh, bleh, ls --version
<Kamion> (-v, rather)
<doko_> \sh: there exists a libstdc++-v7 branch ;-P
<neuralis> Burgundavia: on a related note, has any thought been given to shipping f-spot?
<\sh> jbailey: btw...do you want to talk about cdbs this month in MOTU school?
<slomo> Kamion: mono 1.1.10 and above were tested by mvo on davis (?) and all failed (and 1.1.10 failed in a breezy chroot too)... 1.1.10 worked fine before everywhere... but someone else with an ppc64 could build mono without problems on a ppc64 with flight2 and very similar hardware... the bootstrapping works fine but at the point where the JIT comes into play it segfaults after some time
<jbailey> \sh: IIRC, I suggested March. =)
* \sh gets his holy kruzifix and shows it to doko 
<jbailey> doko_: Are they using it to implement C++0x stuff?
<\sh> jbailey: well..ok...then I will prepare something about pbuilder and chroots maybe
<\sh> or actually about debian development tools 
<doko_> jbailey: didn't look yet, at least it has a new string implementation
<Kamion> ah, well at least davis is a machine I can get at
<jbailey> \sh: If you leave chroots to another month, I'll probably finish my dchroot tools sometime this month. =)
<jbailey> \sh: http://people.ubuntu.com/~jbailey/bzrtree/dchrootmgr/
<slomo> Kamion: if you find something new please tell me :)
<Kamion> sure - I've not touched mono before though, so don't expect too much
<\sh> jbailey: I was thinking about writing something for this as well :) 
<jbailey> \sh: You're welcome to hack on it and feed me patches. =)
<jbailey> \sh: (or do your own and I can abandon it)
<\sh> jbailey: how do you want to include our "non root chroot" stuff? like sudoers and passwd <first user in the admin group?>
<jbailey> \sh: What do you mean?
<slomo> Kamion: well, even upstream have no idea what this could be ;) but as i fails even in different chroots i guess it could only be a kernel problem
<jbailey> \sh: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345488 is a patch I did for dchroot that might also be useful
<\sh> jbailey: this is quite nice for biarch machines :) 
<Kamion> you could depend on user-setup and use /usr/lib/user-setup/user-setup-apply /target or something if you just want to duplicate what the installer does
<\sh> jbailey: but I was talking about http://wiki.ubuntu.com/DebootstrapChroot :)
<Kamion> (substitute path for /target)
<jbailey> \sh: It will copy those files in.  Update them on a regular basis with ch-refresh
<jbailey> \sh: Longer term they can either be synced in automatically with some sort of FUSE code to overlay, or a libnss module could be written that proxies authentication bits to the main system.
<jbailey> (I don't think you can bind mount files)
<\sh> jbailey: I was thinking especially about the sed call to shadow and then sudo tee it to chroot_dir/etc/shadow
<jbailey> \sh: That's what I'm saying is all part of the refresh bit
<jbailey> Oh, if you want a different password in the chroot from normal?
<jbailey> No.
<jbailey> Don't ever give root inside a chroot to someone you don't want to have it outside of the chroot.
<jbailey> It's one of the ways that Linux is horribly broken, it doesn't have a segmented security infrastructure.
<jbailey> If you want that, use Novell, Windows NT or the Hurd.
<jbailey> Novell Netware, rather.
<tuhl> rsbac
<neuralis> jbailey: or xen. 
<jbailey> tuhl: I didn't think with rsbac you could delete root?
<\sh> jbailey: I have other hobbies then using novell netware :) I just abandoned novell netware in 1988
<jbailey> \sh: I still have my Master CNE. =)
<Burgundavia> neuralis, that is jdub's balliwick. I suspect we are waiting for dapper+1 to make the mono hit worth it
<tuhl> jbailey: what do you mean by delete root
<neuralis> Burgundavia: yes, that's what i expected. the mono "killer app" trifecta is tomboy, f-spot, beagle. it'd be nice to ship all three eventually.
<tuhl> i think we need mono 
<tuhl> banshee
<jbailey> tuhl: Meaning that I want a system where I have no single user who ever has access  to everything.  No user should ever be able to see all of the kernels memory, or all of the filesystem, or be able to request access arbitrarily to IO ports.  Inside the kernel itself, these same truths should hold.
<jbailey> tuhl: So that UID 0 means nothing in particular
<Burgundavia> neuralis, yes
<tuhl> jbailey: possible with rsbac as far as i know
<Burgundavia> tuhl, banshee is debatable
<\sh> jbailey: well...when you have ever tried to implement an additional LPT port in novell netware 3 with a different irq then 7 you were fcked, but it should had beed usable in netware 3...and it took me 4 days and 3 netware technicians to tell them netware 3 is not working with the netware certified hardware :)
<\sh> s/beed/been/
<Burgundavia> tuhl, kind of sad actually, to watch both rb and banshee do essientailly the same thing at the same time
<jbailey> \sh: Eh, I did it a number of times.
<jbailey> \sh: I ran some really large operations on Netware. =)
<\sh> jbailey: with netware 3?
<jbailey> \sh: Usually Netware 4.  Netware 3 only went up to 250 users.
<neuralis> Burgundavia: agreed
<jbailey> Not a "large installation" by any stretch of the imagination.
<Burgundavia> neuralis, even the duplication of crazy things like the ipod libraries
<neuralis> Burgundavia: yes, i've been wondering about that
<jbailey> tuhl: Interesting, I'll have to look at that again, then.
<\sh> jbailey: netware 4 i never touched :)
<tuhl> i think ubunto needs mono for being competitive to other distros
<neuralis> Burgundavia: seems like an enormous duplication of effort
<tuhl> jbailey: I know the author of RSBAC
<tuhl> RSBAC is plugable
<jbailey> tuhl: The amount of work it would take to partition up the kernel internally would be huge.
<neuralis> Burgundavia: otoh, i can't stand either rb or banshee, so it doesn't affect me as much.
<Burgundavia> neuralis, muine user myself
<tuhl> you can nearly implement every ACCESS Controll mechanism
<neuralis> Burgundavia: likewise.
<tuhl> jbailey: look a openvz
<tuhl> another low overhead alternative
<tuhl> for separating environments
<\sh> tuhl: no we need something like mono and sharpdevelop for being competitive to other distros
<tuhl> \sh: why like?
<jbailey> tuhl: The trick isn't that I want separate environments.  I want to know that a poorly written driver can't arbitrarily ask for resources that it has no rights to.
<tuhl> jbailey: ok
<\sh> tuhl: because we should think about a ide which runs a) with pure mono and b) it should be useable on linux/unix and windows...
<\sh> tuhl: including a compatible windows.forms interace and ui builder
<\sh> interface even
<tuhl> why not porintg mono develop to windows
<neuralis> \sh: that hardly has anything to do with keeping us competitive with other distributions.
<tuhl> evo runs already
<neuralis> \sh: monodevelop is an application for a highly specific, narrow market segment
<tuhl> GNOME will needs Mono for building Desktop apps faster that in C/C++
<\sh> tuhl: because gtk on windows is evil...I'm using gimp e.g. on every windows machine i had hands on..and it was, to be honest, not comparable with the linux version...it was at least 3 times slower then on linux...
<tuhl> \sh this can be tuned
<neuralis> tuhl: gnome is unsure about embracing mono for political reasons.
<slomo> tuhl: why does it need mono for that? python is good for this too ;)
<tuhl> slomo: no 
<tuhl> one languaga is not fitting to all problems
<\sh> neuralis: well...sharpdevelop gives you a nice interface for vb.net and c# including a very good forms designer
<\sh> neuralis: importing new .net classes and libs is very easy..and it has a wide audience...and it's free
<slomo> tuhl: yes, that's why i prefer having python and mono (for c#, boo, whatever)... but well, not very useful to argue about this *shrug*
<\sh> neuralis: http://www.icsharpcode.net/OpenSource/SD/Default.aspx
<neuralis> \sh: sure, but i'm not sure that adds up to a big argument about being competitive with other distributions.
<tuhl> slomo: that is the reason why I promotet the php4mono compiler
<tuhl> neuralis: we need mono for getting competitive apps on GNOME
<\sh> neuralis: it can make linux/unix in general a competitive development solution for windows and linux/unix apps...forgetting windows xp 
<tuhl> \sh: I agree
<\sh> tuhl: you don't need mono...you could use python as well
<tuhl> no python has a central interpreter lock
<Burgundavia> \sh, yes you could, but people are using mono, so you might as well embrace it
<tuhl> this is a design flaw
<neuralis> \sh: of course, but that has nothing to do with competitiveness with other linux distributions :)
<tuhl> ADA was the latest development language :-)
<neuralis> tuhl: well, it's arguably a design flaw
<tuhl> the last I meant
<neuralis> tuhl: and in any case, getting competitive apps for gnome with mono is still a questionable topic
<tuhl> neuralis: yes and you need to manny library bindings in a non Mono world
<\sh> Burgundavia: ironpython will be the change :)
<slomo> \sh: and it has a not very friendly license iirc... but better ask ajmitch about it, he took a look at it ;)
<neuralis> \sh: pypy will be the change ;)
<tuhl> without mono we will have to provide bindings for all interpreters / langiages separately
<tuhl> this sucks all enegry out of the OSS movement
<tuhl> every year a news language (perl, python, php, ruby, ...) and for all languages a bindung to TK, gtk, motif, Windows, 
<neuralis> tuhl: the community at large, starting with gnome, still isn't convinced mono is kosher.
<tuhl> where is a problem with ISO standardized byte code enviroments
<Kamion> slomo: well, I found that the failure is non-deterministic ...
<mjg59> Red Hat aren't likely to ship Mono unless it becomes a business requirement
<tuhl> I am not speaking of ASP.NET 
<\sh> tuhl: well...whoever invented bindings for gtk or qt to php..he was on crack...
<slomo> Kamion: yes, that is nothing new ;) it fails at compiling one of the first .cs files, but not always the same
<Kamion> ok
<Kamion> you didn't tell me that :)
<\sh> mjg59: most likely they are waiting for the run to the court of MS and Novell ;)
<slomo> Kamion: no, i didn't thought about it... sorry
<tuhl> slomo: what about beagle?
<slomo> tuhl: update your sources and try to install it... should work now unless you're on ppc
<tuhl> slomo: ok
<doko_> \sh: does ooqstart actually work for you?
<\sh> doko_: I'll see tomorrow when I install latest dapper cd
<\sh> doko_: right now I have only one dapper chroot on amd64 and ssh -X to amd64 machine and dchroot to dapper chroot will give me troubles showing remotely the output of X apps
<slomo> tuhl: btw, what exactly do you want? everybody will continue to use the language and runtime enviromnent he likes most and feels best-suited for the problem *shrug* when someone needs scheme bindings for gtk let him do it :) mono definitely isn't the only and perfect solution for everything
<mjg59> \sh: Do you have the same home directory in the chroot as outside it? Is your DISPLAY variable still set in the chroot?
<tuhl> slomo: we will see.... installing beagle....
<\sh> mjg59: yes
<\sh> well..actually I can't install it strange
<\sh> ah yes...it's not build yet for amd64 :)
<\sh> doko_: what is not working?
<\sh> mjg59: this is the error message :)
<\sh> (dapper_chroot)shermann@amd64-home:~/packages/dapper/ooqstart/new$ xterm
<\sh> xterm: Error 32, errno 0: Success
<\sh> Reason: get_pty: not enough ptys
<tuhl> slomo: beagle seems to work - thanks
<mjg59> \sh: Uh. And do any other X apps work?
<\sh> mjg59: give me one moment..I have to break my chroot completly :) 
<\sh> apt-get install ubuntu-desktop *gnarf*
<Kamion> \sh: mount /dev/pts?
<\sh> Kamion: it's mounted correctly
<Kamion> or bind-mount /dev and /dev/pts from the real root
<\sh> sudo mount --bind /home /home/shermann/$MOUNTPOINT/home
<\sh> sudo mount --bind /tmp /home/shermann/$MOUNTPOINT/tmp
<\sh> sudo mount -t proc proc /home/shermann/$MOUNTPOINT/proc
<\sh> sudo mount -t devpts devpts /home/shermann/$MOUNTPOINT/dev/pts
<\sh> where $MOUNTPOINT is set to $whatever chroot I want..example dapper dapper_i386 breezy hoary
<Kamion> you need /dev too
<\sh> Kamion: it's working when i'm directly on the machine with a running x server...
<\sh> Kamion: so when a monitor is attached ... 
<sabdf1> off to uganda - cheers all
<\sh> mjg59: gedit e.g. works 
<mjg59> \sh: You have an issue with /dev, then
<\sh> mjg59: yepp.../dev/pty* are not created
<Kamion> \sh: bind-mounting /dev from the real root should give you /dev/ptmx, which will make Unix98 ptys work
<\sh> Kamion: this should be mentioned as well on the wiki page
<Kamion> go forth and edit the wiki page, then ... I didn't write it
<\sh> Kamion: it's done already right now :)
#ubuntu-devel 2006-01-13
<mjg59> So Xgl with glxcompmgr is really quite nice
<mjg59> Bit flickery, but fast translucency
<\sh> without nvidia or fglrx drivers?
<mjg59> On Intel
<\sh> sounds good :)
<HiddenWolf> weee
<HiddenWolf> we want packages. :)
<dilinger> indeed
<tashiro> Yeah, would be cool to have packages for it
<mjg59> Needs patched mesa at the moment
<HiddenWolf> mjg59, let's hope someone whips it into shape upstream, so distro's start shipping and gnome/kde can depend on it for eyecandy. :)
<\sh> jdub: ping could I request a ML from you? name: kubuntu-de ?
<Riddell> \sh: make sure you tell the ubuntu-de loco team know if you set that up
<\sh> Riddell: jepp...
<lilo> whoops, sorry, I'm good
<Lathiat> must be secretly spying on us!
<ijuz_> that happens when you are in the wrong network!
<infinity> Any Atheros users alive right now?
<psusi> this is weird.... the e2fsprogs package fails to build from source... gets some errors converting texi to html docs
<crimsun> jdub: ping
<jdub> crimsun: pong
<crimsun> jdub: hi, have you had a chance to sign my key (0xC88ABDA3)?
<jdub> crimsun: hrm!
<jdub> crimsun: haven't, mostly because i haven't revoked my gpg key and done all of that silly stuff.
<crimsun> jdub: ok, no rush. Thanks.
<jdub> ha ha
<jdub> "I've been receiving a fair amount of e-mail from people who are sure that I don't know Linux, but their notes are really showing me that they don't know reviewing." - Steven J. Vaughan-Nichols
<desrt> is dvd playback supported?
<infinity> Define "supported"
<infinity> We don't ship libdvdcss, so I don't suppose we support playback of encrypted DVDs.
<desrt> i mean can a user complain that it's not working?
<jdub> yes
<jdub> until
<desrt> and this is something we should care about?
<jdub> we say "but we know it won't work"
<jdub> "sorry, legal issues"
<jdub> "etc."
<jdub> "have a nice day!"
<jdub> "*CLICK!*"
<desrt> right.  but they've already installed dvdread/libcss/whatever
<jdub> ah, then they should eject the CD and stick it in again
<jdub> watch it magically work
<Gman-> 'linux is so not ready for the desktop....grumble...[hang up] '
<infinity> If you can show me that a non-CSS DVD doesn't work, then complain.
<desrt> jdub; ?
<jdub> Gman-: "LADIES AND GENTLEMEN, THE LINUX DESKTOP!!!!111" -> that's what i do
<jdub> desrt: seriously.
<infinity> If you want to complain about a CSS DVD not working, there's not much I can do.
<Gman-> heh
<zakame> jdub: w00t :D
<jdub> desrt: this time, i'm not shitting you.
<desrt> ok well
<desrt> the user is me.
<desrt> so if i put the disc in again, it will work?
<jdub> highly likely.
<infinity> Depends on the problem you're having. :)
* desrt tries :)
<infinity> I've not yet found a DVD I couldn't play with xine+libdvdcss.
<desrt> Totem was not able to play this disc.
<desrt> No reason.
<infinity> Though, some required some serious fiddling with preferences.
* jdub says the magic word ("motherfucker").
* infinity curses Lucasfilm...
<desrt> well
<desrt> i have a dvd here :)
<desrt> it's called "pretty woman"
<desrt> perhaps you've heard of it :)
<desrt> in fact, it was the first one i grabbed.  it may be a fluke or there may be others
<infinity> Some giant-mouthed lady, pretending to be a sex worker.
<desrt> (i know for a fact that some others *do* play)
<infinity> Yeah, sounds familiar.
<desrt> lemme grab some more
* desrt needs a larger sample
<desrt> pretty woman: does not play
<desrt> dave matthews band live ("listener supported"): does play
<jdub> i'd accuse you of only telling us about the good ones
<jdub> but then, you already mentioned pretty woman
<desrt> :)
<desrt> amlie: does not play
<jdub> that's just cheating
<desrt> ?
<jdub> that's the ultimate, "yes, i have taste" dvd
<desrt> :p
<desrt> it's one of the few in this pile that i actually own
<jdub> i think you're going to have to destroy pretty woman
<desrt> (the dave matthews one being another)
<desrt> fifth element: definitely does not play
<desrt> run lola run: does not play
<desrt> this is weird.....
<jdub> when they can't play, are they mounted as filesystems?
<desrt> yes.  they always are.
<jdub> unmount them, try again
<desrt> hold a sec.
<desrt> good morning vietnam: weird
<desrt> ok
<desrt> unmounting has no effect
<desrt> some definitions:
<desrt> 'does play': i get the menu and can play the dvd just fine
<desrt> 'does not play': i get the FBI notices and the studio logo thing but then i get a "make sure you have libdvdcss installed" notice
<desrt> 'definitely does not play': i get the "make sure you have libdvdcss installed" notice immediately
<desrt> weird (good morning vietnam): i get the fbi notices and the studio logo and then totem seems to think the movie is over
<jdub> stick the same CD in twice
<desrt> eject, reinsert?
* desrt disables automount
<desrt> same story
<desrt> fwiw, it's a sony dvd-rw connected with firewire
<desrt> the dave matthews DVD is all-region
<desrt> the rest are region 1 only
<desrt> the drive has had its region code set in windows (to region 1)
* desrt tries usb
<desrt> An error occurred
<desrt> The source seems encrypted, and can't be read. Are you trying to play an encrypted DVD without libdvdcss?
<desrt> same old same old (so it's not firewire causing the problem)
<infinity> Have you tried with xine?
<infinity> totem and I have never agreed on... well... anything.
<desrt> no.  but i have tried with vlc and mplayer.  they both fail in similar ways
<desrt> i get some informing console output
<desrt> something about being unable to crack CSS keys
<infinity> Yeah, xine has more fancy options to change how keysearches are done, which is how I got around my Star Wars DVD problems.
* desrt installs it
<infinity> (Star Wars was dying for me in the "Everything up to the menu works, then the world explodes" way...)
<desrt> libdvdread: Get key for /VIDEO_TS/VTS_01_1.VOB at 0x0002b12c
<desrt> libdvdread: Error cracking CSS key for /VIDEO_TS/VTS_01_1.VOB (0x0002b12c)!!
<desrt> this seems to be the problem.
<Treenaks> infinity: as long as you use libdvdcss, setting the DVDCSS_METHOD env. var to disc
<Treenaks> infinity: should solve a lot of problems
<desrt> DVDCSS_METHOD=disc ?
<infinity> I had to set it to "title" for SW..
<Treenaks> desrt: export, yes
<desrt> libdvdread: Error cracking CSS key for /VIDEO_TS/VTS_01_1.VOB (0x0002b12c)!!
<desrt> :(
<desrt> it successfully cracks the key for some of the chapters
<desrt> which is why i get the intro junk
<desrt> but it always fails on the main title
<infinity> desrt: Use METHOD="title"
<desrt> k
<infinity> (This is assuming that env var is the right one.. I just set this in xine's preferences)
<desrt> DVDCSS_METHOD=title totem dvd:///dev/scd0
<Treenaks> http://wiki.ws0.org/wakka.php?wakka=libdvdcss explains what the different values do
<desrt> hum
<desrt> i wonder what happens if i use METHOD=title directly on the .vob file
<desrt> i find it suspicious that it fails so rapidly when i use the title method
<infinity> Delete your key cache..
<desrt> i -just- did :p
<desrt> it gets a title key of 00:00:00:00:00
<desrt> >:|
<infinity> Neat.
<desrt> libdvdcss debug: cracking title key
<desrt> libdvdcss error: read error
<desrt> libdvdcss debug: 0 of 0 attempts successful, 0 of 0 blocks scrambled
<desrt> libdvdcss debug: title key is 00:00:00:00:00
<desrt> libdvdcss error: fatal error in vts css key
<desrt> 0 attempts?  heh.
<desrt> this feels kinda like a libdvdcss bug
<fabbione> desrt: is that on a new machine?
<desrt> well
<desrt> new dvd drive
<fabbione> ok
<desrt> got it for christmas :)
<fabbione> apt-get install regioncode
<desrt> this is not the problem.
<fabbione> and set the region on the dvd driver.. kthxbye
<desrt> (plus... regioncode does not recognise my drive)
<fabbione> wanna bet?
<desrt> i've set the regioncode using windows.
<fabbione> i had the same problem on the powerbook dvd
<fabbione> same error
<fabbione> region set did it
<desrt> regionset is already the newest version.
<desrt> ERROR: Could not retrieve region code settings of the drive!
<desrt> This could mean your drive is region free and doesn't need any setting.
<desrt> it is -not- a region-free drive
<Treenaks> \o/ entertainment industry.. *sigh*
<desrt> in any case, libdvdcss claims to be able to work without setting the region
<fabbione> desrt: nah.. it can't
<desrt> well.  i have set it
<fabbione> you need to set it, but it might be the driver that needs to be set on each boot
<fabbione> who knos
<fabbione> knows
<infinity> desrt: Can't retrieve code just means it's never been set properly.  You can still set one.
<desrt> infinity; i tried that.  it said that it failed to set it
<desrt> infinity; (and when i checked it windows it was true... it hadn't been set)
<infinity> Curious.
<desrt> i've set it in windows now and the regionset program still thinks that it's unset
<desrt> it really is evil.
<infinity> Maybe you've found a drive that our tools/drivers genuinely hate.
<desrt> Enter the new region number for your drive [1..8] :1
<desrt> New mask: 0xFFFFFFFE, correct? [y/n] :y
<desrt> ERROR: Region code could not be set!
<desrt> it's making a DVD_AUTH ioctl which returns -ENOSYS
<desrt> i've checked the kernel
<desrt> the only code path that could do that is this:
<desrt>                 if (!CDROM_CAN(CDC_DVD))
<desrt>                         return -ENOSYS;
<desrt> it's as if it doesn't even think that it's a DVD drive....
<desrt> (but obviously it can mount it and play the first bits of movies)
<desrt> huh!
<desrt> [4750685.622000]    Vendor: SONY      Model: DVD RW DRU-810A   Rev: 2.0d
<desrt> [4750685.622000]    Type:   CD-ROM                             ANSI SCSI revision: 00
<desrt> so that _is_ the problem
<desrt> ok.  this is a kernel bug.
<infinity> That certainly seems a bit problematic..
<desrt> hah.  benc runs away.
<desrt> http://ubuntuforums.org/showthread.php?t=77219
<desrt> this thread the user says they had one heck of a time getting the drive working in breezy but in hoary it was OK
<desrt> i wonder if this detecting-as-cd business is a regression
<jdub> yes
<desrt> oh?
* desrt starts poking around inside the kernel
<fabbione> desrt: it might be easier if you could test .15
<fabbione> and see if it fixes it
<desrt> i'm running dapper here
<fabbione> hm ok
<fabbione> git-bisect is your friend :)
<desrt> binary search for regression?
<fabbione> it will take you a few kernel rebuilds
<fabbione> desrt: sort of
<desrt> this forum post is questionable at best.... i'm not sure he's talking about the same thing as i am
<desrt> i'm going to take a more direct approach and try and just debug the problem
<desrt> (add printf's to the kernel, etc)
<desrt> figure out exactly why the kernel thinks that it's a cdrom
* fabbione points desrt to git-biset again
<desrt> heh :)
<desrt> ok ok.
<fabbione> bisect even
<desrt> what kernel was hoary?
<desrt> 10, right?
<desrt> ughhh. non gcc-4-safe kernels
<floam> desrt: yeah 2.6.10 according to distrowatch
<floam> warty was 2.6.8.1
* desrt duct tapes BenC to the floor
<desrt> heh
* desrt annoyed that he gave away his last breezy ppc cd >:|
<desrt> ok.  it's a firewire bug.
<desrt> the reason the drive wasn't working when i tried its USB interface was a stale dvdcss cache
<Mithrandir> desrt: ooh, you have a USB/firewire dvd/cdrom?
<desrt> yes
<Mithrandir> desrt: do you want to be my bitch^Wfriend for life? :-)
<Mithrandir> or at least, test the live cd on it
<desrt> does this involve testing?
<desrt> heh.
<Treenaks> Mithrandir: I have a firewire CD-ROM enclosure I can send you..
<desrt> it's not firewire bootable
<Mithrandir> desrt: oh. :-(
<desrt> i have firewire ala audigy 2
<Treenaks> Mithrandir: (works on any IDE hard disk <120GB as well)
<desrt> not onboard
<Mithrandir> Treenaks: I just need to have it tested, and I think it's a one-off job, but thanks.
<Mithrandir> Treenaks: so if you could do that, I'd be very grateful.
<Treenaks> Mithrandir: I have no drive to put in it :)
<Mithrandir> Treenaks: ah, ok.
<Mithrandir> then it's a tad harder.
<Treenaks> :)
<Mithrandir> that is, there's no use in doing it now, since I know it's broken, but I think I have a fix.
<Mithrandir> but having fixes tested is a virtue.  Or so I've heard.
* Treenaks wonders when a Live CD that boots correctly on his Mac Mini will be released
<Mithrandir> Treenaks: get me a mac mini. :-P
<Mithrandir> what's wrong in the boot there ATM?
<Treenaks> Mithrandir: not much really, it drops out of usplash very early and I get a GDM screen ('please log in' :)
<Mithrandir> I have a fix for that in bzr already.
<Mithrandir> it's my fault. :-)
<Mithrandir> (and it's a trivial fix)
<Treenaks> then all I need is a fixed ati driver
<Mithrandir> I can't give you that. :-)
<Treenaks> Mithrandir: nah, I need to poke daniels for that anyway -- it's still broken on my HP laptop
<Mithrandir> but I can get a fixed casper into the archive.  Hopefully, Den will be able to verify that my fix actually fixes his problem and we'll have usb/firewire live cds working too.
<TheMuso> c
<TheMuso> crap...
<Treenaks> ?
<desrt> Mithrandir; an interesting thing to consider which i'm pretty sure is completely unsupported right now is the idea of having the ability to install ubuntu onto a harddrive on one sort of media and use it via another
<desrt> Mithrandir; for example,  install to an IDE harddrive and then remove that harddrive and install it in a firewire enclosure and boot off of that as if nothing changed
<desrt> Mithrandir; won't work right now since the root device has changed from /dev/hda to /dev/sd[something] 
<desrt> even firewire in the presence of various different built-in scsi devices will fail since you'll move from /dev/sda to sdb (or whatever)
<fabbione> whoohhooo
<fabbione> there is a big memory leak somewhere
<daq4th> buy more ram ;-)
<fabbione> daq4th: ehehe
<fabbione> must be some gnome-lib from death
<fabbione> all gnome apps sucking over 300Mb
<fabbione> and stuff like that
<crimsun> seb's gonna love that one
<fabbione> and daniel
<fabbione> 13715 fabbione  15   0  100m 8780 6372 S  0.3  0.9   0:02.48 xmms               
<fabbione> just to start :/
<fabbione> nautilus is at 270M
<fabbione> fresh boot
<fabbione> lovely
<Treenaks> fabbione: virt or real?
<fabbione> Treenaks: it's VIRT, but it doesn't take long to become real
<fabbione> after a few hours i have about 1.5G of swap in use
<fabbione> (with 1GB of real ram)
<fabbione> this smells more like a glibc issue
<fabbione> too many random processes sucking too much ram
<fabbione> system becomes almost unuseable after 45 minutes
<crimsun> sparc?
<crimsun> I know I've been getting lots of libc errors about invalid free()s on app exits
<crimsun> (that's on i686, though)
<csj> hello, I got ubuntu live-base iso from http://cdimage.ubuntu.com/livecd-base/, and I customize it, I installed xorg, gnome,gdm,etc. and then burn it to test, but failed cause I dont have /dev/input/mice, which package should I install to auto produce the device file?
<fabbione> crimsun: i am on amd64 k8
<fabbione> crimsun: sparc seems fine
<fabbione> crimsun: but that's usually an app bug.
<crimsun> fabbione: wouldn't doubt it; it's irssi that's throwing it
<fabbione> crimsun: invalid free() means that irssi is attempting to free memory that's not allocated to it, or no more allocated to it (previously free'ed)
<crimsun> right
<fabbione> hmm foood
<netstar> Can anyone explain where ubuntu sets default file type, application associations (in nautilus), and then locks them so that a selected "elite" are unmovable?  I'm tried editing .desktop MimeInfo and default.list but , however, am still having no luck.
<Burgundavia> netstar, it shouldn't do that
<Burgundavia> netstar, check the permissions on .local. And this is really a support question, and should thus be on #ubuntu
<netstar> Burgundavia, I understand that, sorry, but was finding that the level of explanations were a little too high level.
<netstar> I'll try elsewhere.
<netstar> btw other users are having the same issues.
<tuhl> the beagle search front edn crashes in upstream
<tuhl> beagle-query works
<tseng> do you have and evolution address book
<tuhl> tseng: adressbook, jabber chat, rss feed, files, mails....
<tseng> erm
<tseng> it was a yes or no question please
<tuhl> yes
<tuhl> I have
<tseng> the crash is in evo-sharp, not beagle afaict
<tuhl> tseng: ok
<tuhl> so this appens when beagle search FE tries to access the evo data server
<tseng> eh, it only happens if you have addresses
<tseng> empty contacts list = no crash
<tuhl> tseng: is this bug already addressed by someone?
<tseng> addressed, no
<tseng> do i know about it? yes
<tuhl> bug filed?
<tseng> yes
<tuhl> why are there no start/stop scipts for beagled?
<tseng> because it runs as a user?
<tseng> and there is a stop script
<tuhl> there should be a desktop integration in the control-center
<tseng> patches accepted
<mjg59> tseng: There's the search and indexing thing which seems to appear under accessories - it looks like it should be other preferences
<mjg59> Uh, s/other/under/
<tseng> mjg59: it should actually be removed
<tseng> its suse specific
<mjg59> tseng: Ah
<tseng> it writes ~/.beagle-startup or some such
<mjg59> tseng: Well, that aspect of it. It also writes useful looking config files that beagle then fails to parse (throws an exception in the parsing code)
<tuhl> aha I see
<tseng> one of these days i am going to say to hell with debian and bring back my old package
<tuhl> tseng: ?
<tseng> tuhl: example, beagle wants to be removed in debian because it needlessly depends on dbus-1-utils which i pointed out was unnessicary months ago
<tseng> patch included
<tuhl> tseng: did the debian maintainer not accept you advice?
<tseng> sometimes he does, after some weeks
<tseng> sometimes no reply
<tseng> no fix
<tuhl> tseng: what is the current policy for ubuntu packaging in this cases?
<tseng> i can obviously keep fixing it myself and merging forever
<tseng> i *prefer* to do things properly in debian
<Simira> raphink : I'm up for a round or two of Wesnoth sometime today
<Kamion> slomo_: FWIW the mcs crash always seems to be in System.String:Equals(); I have a backtrace if you need one
<Kamion> under System.Collections.Specialized.ListDictionary:FindEntry()
<Kamion> so I guess the contents of a ListDictionary are getting trashed somewhere?
<Kamion> slomo_: oh ... have any of your attempts to reproduce this been on a multiprocessor box? it smells of a thread-safety bug
<tseng> mjg59: http://bugzilla.gnome.org/show_bug.cgi?id=324904
<tseng> mjg59: i think this is part of your problem
<tseng> mjg59: (fixed in cvs)
<mjg59> tseng: Ah, yes
* Kamion finds http://bugzilla.ximian.com/show_bug.cgi?id=77028 and goes to feed it a backtrace
<raphink> Simira: whenever you want, let me know ;)
<raphink> Simira: esp. now that wesnoth 1.1 is fixed :)
<tseng> mjg59: i backported that, uploading now
<mjg59> tseng: Thanks!
<tseng> mjg59: np
<tseng> argh no im not
<tseng> -S -sa
<tseng> next time im in the same room with elmo he is going to kill me for unsigned orig.gz's
* jdub wrangles wordpress.
<tseng> jdub: did you add my feed?
<jdub> yeah, but we haven't switched to new planet yet
<tseng> oh, i thought thats what all the css fussing was about
<tseng> oh wow
<tseng> Debug: Helper Size: VmRSS=108.3 MB, size=6.62, 140.4%
<jdub> no, that was wuc switching stuff out from under everyone
<tseng> Debug: Process too big, shutting down!
* tseng watches his system swap in to the ground
<tseng> jdub: i thought you were a blosxom guy, anyway
<stratus> jdub, you said that you plan to came for FISL will you give a talk there?
<Simira> raphink : I'll just check if I have Wesnoth installed
<raphink> Simira: are you on dapper?
<Simira> raphink : well, yes,  but I use my Windows XP desktop for Wesnoth ;)
<raphink> oh ok
<raphink> :p
<raphink> beah
<jdub> tseng: i'm looking at / working on converting
<jdub> stratus: i've entered an abstract, so i hope so!
<nix4me> hate to bother, but is there a way to ensure that the bug I filed has been recognized and will get worked on?
<stratus> jdub, good. I'll probably talk about that CDD and with luck we will have a telecentre running there.
<dholbach> hello
<jdub> stratus: rock!
<Pygi> hi dholbach
<stratus> jdub, yes :)
<dholbach> hellas Pygi
<nix4me> guess not
<Mithrandir> desrt: fabbione has a spec on finding the root fs
* psusi needs to figure out why mdadm is freaking out with his hardware in the initramfs and trying to access all kinds of sectors that are beyond the end of the disk
<psusi> Mithrandir, btw... I don't know if you even looked at the malone bug I filed on e2fsprogs yet... but ignore the first upload... I don't know what I was thinking... I sent a new debdiff that is cleaner and actually built
<psusi> Mithrandir, though for some reason some docs failed to build with texi2html, so I had to set the makefile to ignore that failure for the package to build... I know nothing about texi
<Mithrandir> psusi: yes, I've looked at it and forwarded the request to tytso, who is upstream and the Debian maintainer.
<Mithrandir> as I haven't been anywhere near a networked computer since I sent that mail until about five minutes ago, I don't know if I have received a response yet.
<psusi> heh
<psusi> I was up all night playing with my newly built amd64 defrag package ;)
<Mithrandir> I am leaning towards not having __u64 and __s64 in ext2_types.h at all.
<psusi> it's a surprisingly well written program
<Mithrandir> but I'll want to hear what tytso says, it's his program, after all.
<psusi> Mithrandir, that's what I thought... why duplicate what's in asm/types.h?
<psusi> but at least I got it to define them the same way so the compiler doesn't bitch
<psusi> I assume you just refered tytso to the bug and didn't actually send him the debdiff?  
<Mithrandir> psusi: because __s64 / __u64 might not be part of POSIX or C89/C99.  Yes, I referred him to the bug
<psusi> Mithrandir, might not?  they are not ;)
<psusi> as far as I know
<psusi> but asm/types.h I think is a more widely used header than ext2_types.h, so the latter should defer
<Mithrandir> psusi: why __s64/__u64 is needed at all I wonder about, though.  Why can't he use uint64_t and int64_t?
<psusi> what header defines those?
<psusi> and there is code other than e2fsprogs that uses the __ ones... like defrag ;)
<Mithrandir> stdint.h :-)
<Mithrandir> they shouldn't.
<psusi> err... wait. maybe it didn't actually _use_ them
<Mithrandir> stdint.h is C99, I think
<psusi> it just included both headers for other reasons
<psusi> hrm... I really should look at what they added in C99
<Mithrandir> anyway, I'm off to make some dinner.  I'll see what, if anything is in my mail a bit later.
<psusi> manja
<psusi> is there somewhere I can get the previous i386 breezy 2.6.12 kernel package?  the one that came out in the tail end of december seems to randomly hard lock beyond even the reach of magic-sysreq
<psusi> prior to that update, this server had been up for 40 days without a hickup... now it has died 3 times in the last 4 days
<psusi> and the morgue is hopelessly out of date
<Kamion> psusi: asm/* is technically not safe to use from userspace; the correct answer according to the kernel developers is to copy things you need from there into your code
<Kamion> psusi: I imagine that's why it's copied
<Kamion> likewise linux/*
<psusi> why isn't it safe from user space? it is in /usr/include?  thinks that are kernel specific go in the kernel tree don't they?
<Kamion> no
<Kamion> some parts of /usr/include document kernel APIs
<Kamion> those are not guaranteed not to change out from under you with no notice
<psusi> copying is silly though... if the api changes, and you are using a now wrong copy of the declaration, the program will screw the pooch at runtime rather than at compile time when the compiler sees the declaration has changed
<Kamion> no, you don't understand; the kernel is very careful not to break actual userspace programs
<Kamion> i.e. the ABI
<psusi> if the declaration changes, the ABI changes
<Kamion> but the API may change and break you if you're including stuff that's internal to the kernel
<Kamion> that implication does not hold
<psusi> if it breaks though, it is broken in both source and binary
<Kamion> no
<Kamion> it's perfectly possible to change an API without breaking the ABI
<Kamion> for example, you can change a syscall's interface by changing the syscall number but leaving the old one intact for programs built to know about the old syscall
<psusi> hrm... well, I guess in some pedantic cases... like how the 64 bit types are defined... they are all binary compatible 64 bit integers... but declared a bit differently
<Kamion> tytso is a kernel developer, you think he might know? :P
<psusi> but in that case, having the header change won't break anything _unless_ you have your own copy and one changes
<psusi> and you're using both
<psusi> like in the case I ran into
<psusi> yea... and if you recompile those programs, you want them to use the new number
<psusi> that isn't going to happen if they have their own copy of the headers
<Kamion> no, because that sort of thing is exposed through glibc stubs
<Kamion> and no, you don't want them to use the new number, because the new syscall would have different arguments and you couldn't do that just by recompiling the program
<Kamion> things like CD-ROM ioctls are possibly a better example
<psusi> then glibs knows the number... it should get that number from the one place... so when it changes, and you rebuild glibc, it gets the new number, without you having to change it in 3 other headers
<Kamion> since IIRC glibc doesn't wrap those
<psusi> ohhh
<psusi> hrm.... yea... I suppose it does allow you to do that
<psusi> change the api, but keep the same name... and keep two different binary ABIs, the old and the new
<Kamion> it's done in practice all the time
<psusi> heh... I'd just make a new bloody name so as to avoid confusion ;)
<Kamion> http://lists.debian.org/debian-user/1997/02/msg00686.html
<Kamion> read this first
<segfault> does anyone know where can i get pastebin sources?
<Kamion> though there have been later developments than that of course, that being nearly a decade ago
<psusi> heh... this defrag program was written a decade ago... in fact, I remember using it back in '95 on what?  slackware 2 or something ;)
<psusi> and Linus is mentioned in the credits... heh
<psusi> he used the kernel headers
<Kamion> sure, that was a decade ago
<Kamion> and possibly before glibc
<Kamion> things have changed
<Mithrandir> psusi: no response from tytso (yet at least)
<psusi> that's cool
<mdke> elmo, Znarl, just in case you haven't noticed, it looks like the certificates for the websites have expired
<mdke> The security information for Canonical Ltd expired on Fri 06 Jan 2006.
<mdke> jdub, the link to the wiki on the main bar of planet is a dud link, it goes to http://www.ubuntu.com/wiki/
<HiddenWolf> and planet itself is messed up. :)
<mdke> HiddenWolf, not always :)
<HiddenWolf> haven't seen it correctly displayed in days
<mdke> here it sometimes looks fine, sometimes missing css
<Mez> do we not have jack support in ubuntu at all?
<mjg59> What do you mean by "jack support"?
<mjg59> It lives in Universe, but it's there
<Mez> mjg59, I mean gstreamer-0.8-jack :D
<mjg59> It would seem not
<jpatrick> I thought it was gstreamer0.8-jack
<mjg59> http://64studio.com/pipermail/64studio-devel/2005-September/000821.html
<Mez> darn
<Mez> I wanted to use amarok through it instead of having to switch
<mjg59> So it's not supported because the code is broken
<Mez> :(
* Mez installs pygtk
<Treenaks> you're of course free to write working code 8)
<mjg59> Nnngh.
<Mez> lol - if I knew how
<mjg59> The people upstairs have bought an Airport Express and are streaming music over it
<mjg59> Except they've put it on the same channel as my AP
<Mez> lmao
<Treenaks> mjg59: lots of people do that..
<Mez> so - are you going to poke them
<Mez> or change your channel?
<mjg59> (Which takes me up to 5 networks I can see from my bedroom)
<Treenaks> mjg59: every time I change the channel on my AP, my neighbor changes his the next day
<mjg59> No, I'm going to change my AP's channel
<Mithrandir> Treenaks: to the same one as yours?
<Treenaks> Mithrandir: yes
<Treenaks> Mithrandir: annoying git
<mjg59> Treenaks: He seems... confused
<Mithrandir> Treenaks: have your jump about once every six hours, then?
<mjg59> I need to replace the card in mine with one with decent antennae, anyway
<mjg59> Then I may be able to see it from the pub across the road
<Treenaks> Mithrandir: nah, I know him.. I just need to poke him
<Treenaks> Mithrandir: but I keep forgetting :)
<dholbach> have a nice evening
<Treenaks> dholbach: you too :)
<sistpoty> infinity | lamont: could you please clear boson-base from dep-wait? issue is fixed with upload from today. thx.
<sistpoty> elmo: please sync rfb from unstable, ubuntu override ok.
<Mez> does the linux-source image come with a pre-done config file - or do i have to compile it all myself if I want realtime kernel stuff
<desrt> Mez; you can get the config file of your running system out of /boot
<Mez> ah :D yes
<psusi> Ummm... I'm trying to report a bug against the kernel and neither malone nor bugzilla seem to know about linux-image* packages... what gives?
<jpatrick> psusi: linux-source?
<psusi> jpatrick, not listed in bugzilla...
<HiddenWolf> psusi, just plain linux
<psusi> hrm.... well... ok.... I guess I'll just specify which one has the problem in the description
<desrt> so.. uh... the last morgue update was in april of last year
<desrt> anyone know where the recently deceased are?
* desrt seeks, specifically, 2.6.15-8-686
<desrt> ahah!  still installed on muh laptop
<psusi> I really wish someone would fix the morge... the .25 i386 kernel that was released back in december is hard locking daily on my server at work since i upgraded to it this week... I don't know what I would have done if I hand't found the .24 one in an old backup
<kent> psusi, filed a bugreport about it?
<psusi> filing now
<kent> psusi, great.   some one might have fixed it before if you filed it back in december :)
<psusi> I didn't start using the new kenrel until 5 days ago ;)
<psusi> didn't want to reboot the server... it had been up for 40 days
<psusi> since updating, it has hard locked beyond even the reach of magic sysreq 3 times
<Erlang> anyone here managed to build a 32 bits pbuilder chroot on a 64 bit system?
<Nafallo> security is better than uptime in my world :-)
<Nafallo> or wait. it's a dapperserver or something. never mind.
<psusi> Nafallo, it's behind the firewall so I don't really care ;)
<chninkel> ls
* desrt smiles at benc
<Erlang> guess not :/
<desrt> BenC; remember how you reverted your patches to the firewire code between -8 and -9?
<desrt> BenC; you're probably going to need to unrevert those :)
<slomo_> Kamion: thanks for your efforts :) afaik the ppc64 where it couldn't be reproduced was a dual g5 too
<jbailey> slomo_: Is this still the mono problem?
<slomo_> jbailey: yes
<desrt> is it possible to get a detailed revision history of a package?
<desrt> ie: can i somehow get my hands on a patch that used to be in a package but is no longer?
<ajmitch> morning
<Nafallo> morning ajmitch :-)
<slomo_> hi ajmitch 
<ajmitch> hey slomo_ 
<infinity> desrt: Debian has snapshot.debian.net.  Ubuntu is lacking anything quite that useful currently.
<desrt> shucks.
<desrt> oh well.  ben will probably just toss the whole patch back in again for -12
<infinity> slomo_: Did we not come to some sort of conclusion pre-Christmas that it was glib at fault?
<desrt> :)
<infinity> slomo_: Not that we'd done much to test this theory, mind you...
<slomo_> infinity: no... mvo tried it in a breezy chroot on that machine later and it failed too... so imho it could be either a kernel bug or a mono bug
<infinity> Oh, hrm.
<infinity> I must have missed that development.
<slomo_> infinity: and it worked on another ppc64 with flight2... which had glib 2.9 already iirc
<ajmitch> slomo_: you saw that Kamion suspected possibly thread-saferty issues?
<infinity> flight-2 being kernel 2.6.15, which we don't have on either the buildds or on davis...
<slomo_> ajmitch: yes, i read it
<slomo_> oh, but the machine kangaroo tried it on wasn't a dual g5... hm, could be really a threading problem...
<ajmitch> slomo_: only on ppc, right?
* ajmitch sadly doesn't have a dual-g5 with ubuntu on to try
<slomo_> no, it was a ppc64... but only one cpu instead of the two that davis and the buildd have
<Nafallo> slomo_: now that we're talking about mono and glibc together. you saw the output of that banshee debug? :-)
<slomo_> Nafallo: not glibc... glib :P but please file a bug somewhere so i can look at it when i find some free time :(
<Nafallo> slomo_: and ehm, please tell your brother to reproduce it ;-)
<Nafallo> I could do that...
<slomo_> Nafallo: what has to be done to get this bug? nothing?
<Nafallo> slomo_: banshee<enter> ;-)
<slomo_> Nafallo: ok, i'll tell him :)
<Nafallo> slomo_: malone 6557
<ajmitch> morning mpt 
<maswan> Nafallo: hey, what was that site you thought I should go register my duck with? I forgot.
<slomo_> Nafallo: assign it to me, thanks ;)
<infinity> maswan: Register... Your... Duck?
<Nafallo> maswan: probably art.ubuntu.com? Don't remember either though :-P.
<maswan> infinity: I took a decent pic of a duckling, it might be useful/neat for someone: http://www.acc.umu.se/~maswan/bilder/20050706-Ute/index.html?view=IMG_5222.JPG
<Nafallo> slomo_: assigned it to mono ;-)
<infinity> Aww.. Cute.
<HiddenWolf> maswan, heh, I have a friend who'll love this. :)
<HiddenWolf> I might persuade him to turn it into a drawing. :)
<ajmitch> Nafallo: thanks :)
* infinity makes drops the palette on that duckling to 13 colours, and makes it the new usplash.
<Nafallo> HiddenWolf: a friend that will love dapper drake is a good friend? ;-)
<maswan> HiddenWolf: :)
<Nafallo> ajmitch: what not? the bug? :-)
<HiddenWolf> Nafallo, an artist with a sweet spot for little birds. :)
<Nafallo> infinity: yay! :-D
<ajmitch> Nafallo: could you give at least minimal info on how to reproduce, thanks? :)
<Nafallo> baah :-P
<ajmitch> ie, does the UI show first? does it die when playing?
* Nafallo goes to comment ;-)
<ajmitch> before we have to beat you with some bugreporter's guide :)
<maswan> HiddenWolf: I should probably slap a CC license or something onto that pic then
<HiddenWolf> maswan, no licence is fair game. :)
<maswan> any preferences from around here?
<maswan> HiddenWolf: no license is (technically) a copyright violation if you reproduce or publish it or a derivative work. not that I'd care, probably. Probably. Do you feel lucky, punk? ;)
<Nafallo> wow!
<HiddenWolf> maswan, sue me. ;)
<infinity> maswan: I like the one in the middle of 5221 even more.
<HiddenWolf> it's sweet!
<Nafallo> ehrm
<infinity> maswan: Slap a BSD/MIT/X11 license on 5221.jpg, so I can download it and abuse it, kthx.
<maswan> infinity: the one looking towards the camera?
<Nafallo> slomo_: I have a new error for you :-P
<Nafallo> slomo_: Unhandled Exception: DBus.DBusException: No reply within specified time
<infinity> maswan: Yeah.  Pretty much dead centre in the image.
<Nafallo> slomo_: on trying to launch banshee ;-)
<slomo_> Nafallo: wtf?
* infinity is jealous.
<Nafallo> damnit! I can't reproduce my bug because of another bug? ;-)
<infinity> I want a big lawn with ducklings all over it to spend my lunchtime at.
<maswan> infinity: that's in the middle of our university campus
<infinity> maswan: Apparently, I need to move.
<Nafallo> ajmitch: is the bug good enough now? ;-)
<Nafallo> maswan: they must be freezing now :-P
<maswan> Nafallo: ducks are migratory birds.
<Nafallo> oh. they are still here in Eskilstuna anyway :-)
<HiddenWolf> So once we let dapper loose, he'll go away from us! ;)
<Nafallo> lol
<maswan> Nafallo: well, we might have some aronud, but most go south since there isn't much open water aronud
<HiddenWolf> out of control, baby!
<Nafallo> here all of them seems to stay :-P
<maswan> infinity: that ok, or should I chose one?
<Nafallo> but then, they have the whole Eskilstunan ;-)
<maswan> infinity: my intent should be fairly clear though
<Nafallo> slomo_: please check the bug and then bring something heavy when you visit this summer ;-)
<infinity> maswan: Probably less ambiguous if you actually pick a license, and either include the text or link to a rather stable copy elsewhere.
<infinity> maswan: http://en.wikipedia.org/wiki/MIT_License#Text_of_the_license
<infinity> maswan: Fill in the blanks. :)
<maswan> infinity: ok, working on it. :)
<slomo_> Nafallo: tomorrow :) i have some other work to do currently
<Nafallo> slomo_: oki :-P
<maswan> infinity: there
<infinity> MY EYES, NO LINEFEEDS!
<infinity> (But fine, yes, thanks)
* maswan gq:s
* maswan makes no warranties for fitness for any particular uses though
<infinity> Well, sure.  The ducklings could cause a cuteness overload and make my monitor blow up.
<infinity> I understand the risks.
<maswan> and girlfriends might want to prefer staring at ducklings than making out. :P
<HiddenWolf> lol
<HiddenWolf> quite a few gays I know as well, for that matter. :)
<Nafallo> maswan: bad girlfriends then ;-)
<HiddenWolf> omg@l-r-m changelog
<HiddenWolf> a hex editor to change a path? :S
<desrt> :)
<desrt> in libGL?
<HiddenWolf> yup
<desrt> a symlink would have been easier :p
<HiddenWolf> guess so. :)
<infinity> Shh.
<infinity> I want /usr/X11R6 dead.  Dead.
<infinity> (also, it works, don't complain)
<desrt> fair enough
<desrt> please tell me you patched the fglrx module before fixing libGL
<infinity> Read the changelog yourself. :)
<infinity> (Yes)
<desrt> there are going to be a lot of unhappy people otherwise :)
<desrt> awesome.
* desrt can finally reboot :)
<infinity> I'm running fglrx on my laptop right now.
<desrt> hm.  not on my archive yet
<desrt> alas!
<infinity> Console switching is happy, quitting X is happy, etc, etc.
<infinity> Seems all fixed.
<mjg59> infinity: Poor you
<infinity> mjg59: I'll switch back to radeon shortly, I'm just dogfooding it for a bit to make sure it's all good.
<infinity> mjg59: Oh, speaking of my laptop.  Any interest in figure out WTF I'm permanently stuck at 800MHz now?
<mjg59> Plenty of interest, some lack of time
<HiddenWolf> I'm wondering if the new drivers allow me to use nvidia again
<infinity> mjg59: Pretty undergrads?
<HiddenWolf> kernel hardlocks are so well, bad.
<mjg59> Oh christ. Why is texinfo failing postinst?
<mjg59> infinity: Only the one
<infinity> HiddenWolf: I gave something close to 0 testing to the nvidia version bump this time, owing to my girlfriend not letting me near her computer.
<desrt> man
<HiddenWolf> infinity, heh, usually it's the other way around. ;)
<desrt> your girlfriend isn't stupid
<infinity> HiddenWolf: Not much changed, though, so... If you were broken before, you probably still are.
<infinity> desrt: She spent the whole weekend playing video games and glaring at me every time I asked if I could reboot her machine to test something...
<psusi> infinity, would it be possible for a package to cause an alternate initramfs to be build and a new grub boot option to use that or the regular one?
<desrt> oh.  that's different
<infinity> psusi: In theory, yes.
<desrt> i'd have been like "i know if you touch it you'll break it.  no."
<maswan> infinity: you should try waving duckling pics at her for distraction purposes? ;P
<infinity> maswan: Might work.
<psusi> infinity, would it be that hard/require significant changes to things like update-grub and update-initramfs?
<psusi> or just dropping the right config files in place?
<psusi> forget ducklings... use baby pics
<psusi> ;)
<infinity> psusi: Making grub aware of the fact that you want multiple initrds for your kernel would take some hacking.
<infinity> psusi: Building the alternate initramfs with mkinitramfs should "Just Work", if you know what you're doing.
<psusi> infinity, I don't think so... just add another entry to the boot menu that gives a different initrd command
<infinity> psusi: But what are oyu trying to solve?
<psusi> infinity, I was just brainstorming... last night I was fixing the defrag package to build on amd64... and Yagisan asked if you could use it to defrag the root filesystem...
<psusi> I thought sure, if you built it into an initramfs ;)
<infinity> Or if you start a recovery/single session...
<psusi> no... that mounts the filesystem
<infinity> (or can it not even be mounted read-only when defrag runs?)
<psusi> of course not... it's moving stuff around ;)
<psusi> the kernel would get really confused
<infinity> Err, not single, but single,ro
<psusi> nope... can't even be mounted ro
<infinity> But, yeah.  If you can't even do that, then a boot disk or initrd is the way to go, yes.
<psusi> think out it... the defrag program could relocate it's own blocks on disk... and the kernel wouldn't know it
<jmg> hey guys
<jmg> anyone got gnome 2beta packages for breezy?
<psusi> I need to figure out how to get a list of files that are read during bootup, so I can tell defrag to pack them all at the start of the disk
<Burgundavia> jmg, 2.13.4?
<jmg> Burgundavia: yea
<Burgundavia> jmg, in Dapper, yes
<infinity> Meh.  I'm going to have to hunt down this gcj-4.0 failure on ia64, or the whole port will go down in a spectacular fireball.  Pain.
<tuhl> thanks for the beagle workaround
<infinity> psusi: You might get that for free once people re-work the readahead-list package to actually dyanmically figure out what's being read, and readahead accordingly.
<psusi> infinity, yea...
<infinity> psusi: It's meant to track these things and keep a state file.  So, you could use that (once it exists)
<infinity> psusi: I'd imagine you'd want to talk to Keybuk about that.  Or maybe Mithrandir.  Both were interested.
<jmg> Burgundavia: is it wise to be using dapper at this stage?
<psusi> yea... right now it just has a static list of files that it orders into the order their first blocks appear on disk at shutdown
<Burgundavia> jmg, if you can deal with breakage and don't need it to be up 100%
<Burgundavia> jmg, i.e., don't do business critical work on it
<psusi> last night I took that list of files and fed it to defrag to pack them all at the start of the disk
<jmg> i want jingle :)
<jmg> Burgundavia: as long as emacs doesnt break i can still do all the work i need
<jmg> i might upgrade later.. got some work to do now
<jmg> thanks tho
<Tm_T> small question: how installer acts if it can't reach harddisk?
<Tm_T> I have interesting problem here
<psusi> is it just me or do e2fsprogs use an insanely large journal size?  why would you need a 122 meg journal for a 10 gig partition?
<Nafallo> minus 5% reserved for root?
<psusi> huh?  what's that got to do with anything?
<psusi> the journal inode is 122 megs on this 10 gig partition
<psusi> I would think that 4 MB would be more than sufficient
<Nafallo> ah. we had someone on #ubuntu.se that forget the 5% reserved today so that's why I instantly replied here aswell ;-).
<Nafallo> (he checked in diffrent ways though :-P)
<psusi> ahh
<HiddenWolf> jdub, fridge has some weird css, links on top of the fridge picture
#ubuntu-devel 2006-01-14
<daniels> hm
<Burgundavia> daniels, ?
<daniels> what's going on with hal and g-v-m? they don't appear to have made the dbus transition yet
<jmg> danny do you know when we get X11r7?
<daniels> jmg: dude, you've had it for a while now
<jmg> PERHAPS BONG HITS WILL FIX MY KEYBOARD EXTENSION
<daniels> xkb needs a lot more than just bong hits
<jmg> lsd25
<maswan> jmg: is that half an ld50 of lsd?
<jmg> nah
<jmg> that would be ld25
<jmg> the ld50 dose of acid is 12,000 ug
<daniels> (possibly somewhat offtopic ...)
<maswan> so, how much would that be in donations to x.org to fix xkb?
* maswan ducks
<daniels> maswan: just bribe my friends to stay clear of me for a couple of weekends and most of the braindamage should disappear
<HiddenWolf> daniels, don't make us lock you up. ;)
<HiddenWolf> dangerous ideas... :)
<nekohayo> has anyone achieved compiling audacity 1.3 or from cvs?
<mjg59> Why does apt-get install gcc suggest libc6-dev-amd64?
<lifeless> gcc needs the libc headers to compile C code ?
<elmo> he means on i386
<mjg59> I'm not on amd64
<lifeless> oh. fucked if I know
<infinity> mjg59: To compile with -m64
<mjg59> infinity: Ah
<Hobbsee> Do we have an ETA for dapper flight cd 3?  I cant seem to find anything relevant on the wiki about it
<daniels> Hobbsee: no
<Hobbsee> ok
<crimsun> elmo: please sync amule, efax-gtk, and gauche-gtk from Sid, overriding Ubuntu changes, thanks.
<Tm_T> Hobbsee: sir
<shaya> infinity: you here?
<infinity> shaya: Yes (but you know that already... <glances at /msg>)
<elmo> umm, how good is resizing of partitions these days?  and short of rebooting the installer, what's a good tool to do it with?
<Mez> elmo - parted :D
<Mez> and depends on what type of partition you're resixing
<mjg59> elmo: Decent, and yeah, parted ought to be the same code
<Mez> though you might wanna use a GUI - gparted/qtparted - as parted itself is amazingly annoying :D
<elmo> it's NTFS, I'd like to resize - tho if there's any danger of it eating the disk, I'd rather re-boot to the installer and resize my / ext3
<daniels> Mez: you seem to be using ':D' as punctuation, rather than something with actual meaning
<Mez> elmo - the installer uses parted for resizing etc. 
<psusi> anyone understand udev well?  I need to fix it to create the control device /dev/pktcdvd/control and have it owned by the cdrom group
<Mez> daniels-  have you not heard - it's the new full stop
<mjg59> elmo: I've resized multiple NTFS partitions without any problems so far
<psusi> elmo, I have resized by NTFS partition with ntfsresize several times without incident
<elmo> hmm, gparted won't do NTFS
<psusi> nope, it won't
* Mez is sure it did for me
<psusi> it also doesn't do non standard disks/partitions, like lvm and dmraid
<mjr> gparted will do NTFS with the ntfs utilities if they are present
<psusi> so I just had to use ntfsresize + fdisk from the command line
<elmo> mjr: good call
<crimsun> psusi: erm, it's already that way according to /etc/udev/rules.d/{20-names,40-permissions}.rules
<elmo> Error: Attempt to read sectors 128-128 outside of partition on /dev/hda
<elmo> if you guys make me reinstall windows IN FRENCH for the 3rd time this evening, I WILL HUNT YOU ALL DOWN
<psusi> crimsun, I think I figured it out... there are two lines... the first is matching on "pktcdvd" and only sets MODE=644
<psusi> I think that's what is applying... it sets the mode on the control node to 644... I changed it to GROUP="cdrom" like the line under it
<psusi> think that should work?
<crimsun> psusi: the rules are applied sequentially. There's no reason why line 36 wouldn't work.
<psusi> crimsun, yea.. there is... because it specifies [0-9] *
<psusi> wait... maybe I should just change the * to a +?  that means match 0 or more right?
<crimsun> * means match 0 or more
<psusi> hrm...
<psusi> what's + then?
<crimsun> has no meaning in that context
<psusi> it isn't a regular expression?
<crimsun> (i.e., invalid)
<psusi> I can never remember which was which, but in regex, one means 1 or more, and the other means 0 or more
<psusi> in any case... /dev/pktcdvd/control is created with mode 644 and owned by root.root
<Mez> elmo - any reason it's in french (and any reason you're installing windows?)
<elmo> o2#%"#%"%"#T%R"
<Mez> O_o
<elmo> ok, gparted has entirely SNAFUed this drive
<Mez> FUN
<mjg59> elmo: Hm. How?
<psusi> well, going to reboot and see if that fixed the control file perms... brb
<elmo> mjg59: it created a /dev/hda4, which is at the end of the partition  table according to dmesg, but fdisk -l thinks it starts before the swap and has 0 blocks
<mjg59> elmo: Being at the end of the partition table doesn't preclude it coming before other partitoins
<mjg59> The length of 0 is more interesting
<mjg59> What does /proc/partitions say?
<elmo> 0 blocks too
<elmo>  (and 3 4 major/minor)
<elmo> aksim /u dib;t th
<elmo> err, also I don't think the ntfsresize worked
<elmo> the NTFS partition looks to still be 39G
<elmo> which would explain the 0 size new partition
<mjg59> elmo: Have you rebooted?
<elmo> yes
<psusi> yep, that fixed it
<mjg59> Ok
<psusi> udev now correctly creates the device
<crimsun> psusi: submit a patch for udev
<psusi> will do
<psusi> bug it in bugzilla?
<crimsun> sure
<psusi> ok
<psusi> hrm... now I need to figure out how to get the pktcdvd module to auto load
<psusi> normal users can't load it
<psusi> I guess add it to /etc/modules?  or is there a better way?
<psusi> oh crap
<psusi> hal runs with no permissions
<psusi> well this is a problem then...
<Robot101> psusi: mjg59 is working on the unpriveleged hal thing
<mjg59> "working"
<mjg59> I know what needs doing, I may do it soon unless I can convince pitti to do it
<psusi> well, I need hal to have some privs... so its callouts can do things... the hal user is listed in the cdrom, floppy, hal and plugdev groups in /etc/groups, only the process doesn't belong to ANY groups
<psusi> shouldn't it be in those groups?
<mjg59> psusi: You need to wait for privilege escalation code
<psusi> eh?
<psusi> shouldn't it at least be in the hal group?  and preferably cdrom since it's listed in /etc/groups?  that would be sufficient for my needs
<mjg59> psusi: We've made a policy decision that hal will run without priveleges
<psusi> without ANY privs?
<psusi> I understand not wanting it to be root... but... at least the hal group? ;)
<mjg59> So now we need to write a small amount of code to allow it to run things with privileges when necessary
<mjg59> You'll have to ask pitti precisely what it's doing right now
<mjg59> I haven't checked what changes he's made
<mjg59> psusi: But by the looks of it (checking in /proc), it's running with access to cdrom, floppy, plugdev and hal
<psusi> mjg59, hrm... yea... looks like hald is... but the callout it runs doesn't seem to be... because it's trying to access a devnode owned by the cdrom group and group read/write and failing... and the GROUPS environment variable is empty
<mjg59> Hm. No idea, I'm afraid.
* desrt hugs infinity 
<minghua> hello, is there official words for the dummy package xlibs-dev in dapper?  is it going to be removed?
<minghua> I am working on a package and noticed it build-depends on xlibs-dev (only), such is RC bug in debian now
<minghua> as Xorg 6.9 in unstable got rid of xlibs-dev
<daniels> it won't be removed for dappper because colin will bludgeon me to death
<daniels> but you should be removing all references to xlibs-dev and replace them with the alternatives which have been available since xfree86 4.3
<daniels> it'll disappear early in dapper+1, i assume
<minghua> daniels: thanks
<minghua> daniels: it's not my package (I was just trying to fix a FTFBS), so I probably won't fix it myself, I'll file a debian bug though (if there isn't one already)
<daniels> minghua: there's going to be a mass-filing soon, so don't worry about it
<minghua> oh okay, thanks
<ajmitch> looks like the mass-filing has started
<elmo> can I get rid of the auto-icon-ing of partitions on the desktop somehow?
<mjg59> elmo: While still mounting them?
<elmo> mjg59: yeah
<mjg59> elmo: gconf-editor apps/nautilus/desktop/volumes_visible
<elmo> mjg59: cheers
<elmo> grr, how do I change device ownership in our new udev world order?
<desrt> add to the /etc/udev/rules.d
<desrt> MODE= GROUP= and USER= actions
<elmo> desrt: thanks
<elmo> BUS=="ide", KERNEL=="hda2", MODE="0644", GROUP="group", USER="user"
<elmo> that in a separate file at the end of rules.d should work right?
<desrt> that seems right.
<elmo> well, it doesn't :/
<desrt> BUS isn't required here
<desrt> did you restart udevd?
<desrt> it runs as a daemon these days
<elmo> I rebooted for good measure
<desrt> heh :)
<desrt> some earlier rule might be matching it
<desrt> i'm not sure what the rules are about who gets priority
<elmo> hmm, even putting it first doesn't work
<psusi> oh FFS... can someone just kick __George from #ubuntu?  My god what a twit
<psusi> err... George__
<Burgundavia> mjg59, did infinity get madwifi-ng packaged?
<mjg59> Burgundavia: Not that I'd seen so far
<mjg59> Burgundavia: You could just ask him :)
<desrt> Burgundavia; no mention of it in the l-r-m changelog
<infinity> Easier to ask others.
<Burgundavia> mjg59, wondered if I had missed it. He did say he would get to it "soon". I won't bug him
<infinity> It's sitting on the side of my plate, near a blob of mustard.
<infinity> Should get done this week.
* desrt dons his madwifi card
<desrt> with any luck i won't need this guy soon
<Amaranth> daniels: no problem, help is (almost) always useful :)
* desrt eyes the bcm driver
<daniels> Amaranth: i live to give
* psusi wishes pitti were here to discuss hal permissions issues
<desrt> psusi; oh.  i'm all over that discussion
<Burgundavia> psusi, he has a weekend too
* psusi was up all day and most of the night ( 4 am ish ) all weekend working on ubuntu.... does that indicate insanity?
<dman13> I noticed a copy-and-paste error on http://ubuntulinux.org/support.  Anyone here have privileges to change it?
<Mez> I'm assuming a pakage that needs multiverse stuff is fine for ubuntu ? if not for debian
<daniels> not for any suite other than multiverse, obviously
<Mez> daniels - yeah - but theres no "issues" other than it needs to go in multiverse
<floam> hi, has anyone figured out the when-using-evdev-gnome-settings-daemon dies thing yet?
<floam> it's still happening to people
<daniels> floam: there's a patch for g-s-d but it doesn't quite work
<floam> daniels: oh, interesting
<floam> where's that at?
<floam> I thought I was watching all the bugzilla's and mailing list discussions
<floam> daniels: if it works even slightly better than it does now, that's good enough for me ;)
<daniels> it's on some bugzilla bug somewhere
<floam> right now I'm wrapping gsd to start itself and then STOP it .1 seconds later
<floam> so that at least most stuff get set up for me
<floam> daniels: recall if it's gnome or ubuntu?
<floam> or freedesktop
<floam> oh, I think I found it
<floam> http://bugzilla.gnome.org/show_bug.cgi?id=323724
<floam> daniels: if that patch is the same one, how doesn't it work?
<daniels> floam: i dunno man, all I know is what I've read in bz
<floam> heh, ok
<floam> hm, looks like control-center is missing build-depends for dbus headers
<LaserJock> I was watching Mark's Debconf5 talk the other day and I believe he said that there was a place that has all of the Ubuntu patches where DDs can get them. Do any of you know what the URL is?
<daniels> http://people.ubuntu.com/~scott/patches/
<floam> daniels: it does look like the patch worked
<floam> at least enough for it to run and not crash
<floam> I get a bunch of stuff spammed to my terminal but that's pretty normal for GNOME and GTK apps I think.
<LaserJock> daniels: thanks
<Amaranth> floam: shouldn't happen, but yeah, lots of glib warnings seem to be the norm
<floam> Amaranth: yeah.
<Amaranth> not for long though
<floam> I've learned not to be even slightly alarmed by scary stuff like "GDK-CRITICAL!!!!!!"
<Amaranth> iirc as of january first something got flipped on in gnome-session that makes apps die on critical warnings
<floam> Amaranth: oh, awesome
<Amaranth> was supposed to happen anyway
<floam> maybe people will be a bit more careful now :)
* netjoined: irc.freenode.net -> brown.freenode.net
<wasabi> So is there work progressing on the ro root front?
<wasabi> I love you guys for including jffs2.
<wasabi> Ya know, I would sure not mind if the kernel modules were split into more finer grained packages, like X.
<wasabi> As I start work on more embedded stuff, I realize it would be nice to be able to pick and choose which modules I had installed, while not having to build it all myself.
<desrt> hello pitti
<pitti> Good morning
<desrt> psusi wants to talk to you about hal permissions :)
<pitti> hi desrt 
<pitti> hm, not online as it seems
<desrt> (a good start to any monday morning!)
<pitti> indeed :)
<jsgotangco> good morning pitti 
* desrt looks at gnome-terminal annoyed
<desrt> ubuntu has spoilt me to the point that i'm annoyed that i have to wait for gtk to compile
<zakame> heya pitti :)
* StevenK glares at moin.
* StevenK wonders if he cares enough to debug why dh_python adds a python2.3 dependancy for the third time, or just give up, ignore dh_python and upload a debdiff.
<zakame> waah
<Keybuk> I've taken to ignoring dh_python, it seems to nearly always do the wrong thing for me too
* desrt makes bed while waiting
<StevenK> It seems to work okay for Linda, but like that's a litmus test.
<pitti> desrt: there's a gtk version we don't have yet? :)
<sobersabre> oh!
<sobersabre> does anybody here work with amd64 ?
<Burgundavia> desrt, better file a bug. seb will be annoyed at that
<desrt> pitti; seb packaged a bogus vendorpatch
<desrt> pitti; so i was testing a patch i wrote to unbreak it
<desrt> Burgundavia; i did :p
<pitti> elmo: can you please backport postgresql-{common,8.0,8.1} ?
<sobersabre> hello, dear developers. I have tried to use gdb on amd64 breezy, but got into problems with it. Does anybody here develop software ... and debugs it on amd64 ?
<Burgundavia> sobersabre, nah, we are all m68k people here
<sobersabre> Burgundavia, I see. no commodore guys ? 
<wasabi> Any you experienced with Fuse?
<wasabi> Trying to figure out how to use standard 'mount' to use it.
<wasabi> (and thus pmount)
<pitti> sobersabre: can you be a bit more specific, please?
<sobersabre> pitti, I can: gdb dies with SIGSEGV  on hello world.
<pitti> oops
<sobersabre> it dies with ANYTHING
<pitti> sobersabre: is there already a bug open?
<sobersabre> I found nothing on this over www, and nobody seems to be a developer and an owner of amd64 machine.
<pitti> I can take a look at it when I'm back at my amd64 box
<sobersabre> pitti, I have browsed bugzilla, and added comment to an existing bug.
<Keybuk> sobersabre: we have several developers who use amd64
<pitti> sobersabre: which one?
<sobersabre> Keybuk, and do those developers use ubuntu ? and do they develop ?
<Nafallo> sobersabre: rather we use amd64 but are running dapper on them :-)
<Keybuk> sobersabre: obviously
<sobersabre> Keybuk, I also 'oviously' installed a release and gdb is broken... what do you say ?
<sobersabre>  :)
<Keybuk> Lathiat: waaah!  libnss-mdns recommends zeroconf, so aptitude pulled it in
<Keybuk> sobersabre: WORKSFORTHEM
<dholbach> good morning
<Keybuk> so clearly there's something about your machine/setup/install/etc. that breaks gdb
<sobersabre> breezy ?
<Keybuk> dholbach: morning *hugs*
* dholbach hugs Keybuk
<sobersabre> Keybuk, breezy ?
<Lathiat> Keybuk: heh
<sobersabre> If you say dapper is functional - I reinstall now.
<Lathiat> Keybuk: because anand maintains libnss-mdns, and anand wrote zeroconf
<Lathiat> zeroconf is fine but apparently has a nasty bug
* pitti hugs dholbach 
<Lathiat> apparently caused issues at UBZ?
<dholbach> hey pitti :)
<sobersabre> would somebody hug me, I cannot debug!!!!!
* pitti hugs sobersabre 
<sobersabre> thanks.
<pitti> sobersabre: gdb gdb :)
* zakame hugs sobersabre 
<Keybuk> Lathiat: yeah, it caused massive issues ... and it interferes with network-manager and ifupdown
<Keybuk> e.g. you can't ifup an interface that's been zeroconf'd
* desrt hugs the universe
* desrt hugs main and restricted too
<sobersabre> desrt, you have long arms......
<desrt> no love for multiverse
<sobersabre> hehe
<Keybuk> Lathiat: we don't need libnss-mdns right?
<Lathiat> libnss-mdns is nice
<Lathiat> lets you resolve .local addresses
<Keybuk> "nice" ?
<Keybuk> it's in universe ... :p
<Lathiat> perhaps do a local mod of it to drop zeroconf to Suggests ?
<Keybuk> that's what I was going to do
<Keybuk> drop libnss-mdns to suggests, as that's the one in universe
<Keybuk> or should we promote that one, and then drop zeroconf?
<Lathiat> 'drop' zeroconf?
<Keybuk> hmm, libnss-mdns looks useful to me, maybe drop zeroconf to suggests
<Keybuk> drop to suggests
<Lathiat> yeh, libnss-mdns is good
<sobersabre> Burgundavia, I meant: 'Burgundavia, I see no commodore guys' 
<Keybuk> any reason libnss-mdns isn't in main?
<daniels> Keybuk: at a guess, 'mdns'
<Keybuk> daniels: ?
<Keybuk> daniels: avahi is in main now
<sobersabre> guys. does dapper allow you to work with not much fuss ?
<Lathiat> Keybuk: because no one asked for it to be promoted?
<jdub> Keybuk: we should have libnss-mdns by default :-)
<Lathiat> sobersabre: dapper may at any time break horribly, it also may work
<Seveas> sobersabre, until release the answer to that is no
<jdub> sobersabre: yes, it's designed to be dogfoodable for developers and testers
<desrt> Seveas!
<sobersabre> I need gdb on amd64.
<Seveas> desrt
<desrt> 'sup dude?
<Keybuk> jdub: yeah, looking at it I think I agree -- it's the gubbins that let's you adhoc DNS on your adhoc network, right?
<jdub> yes
<jdub> .local lovin'
<Keybuk> sounds cute to me
<jdub> mdz had concerns about adding it to nsswitch by default
<Lathiat> it means your hostnames published by mdns, e.g. archer.local, can be used by anything
<Seveas> desrt, waking up is up (just waking up after 4 hours sleep and a terrible nightmare involving schaaaaakes)
<jdub> which is the only reason why it hasn't been included before
<Lathiat> it doesnt let you resolve anythign non-.local by default
<Seveas> schnaaaaakes
<Lathiat> so helps a bit in regards to security
<desrt> is that like a snake?
<Keybuk> start an ubuntu-devel discussion
<Lathiat> e.g. i can't just go and publish some random hostnames in mdns to steal your passwords
<sobersabre> Seveas, I stopped watching nightmares... it's boring.
<desrt> Lathiat; can you put 'local' as your search domain in resolv.conf?
<Keybuk> I remember talking about it a year or so ago, I expect things are better since then
<desrt> Lathiat; or is resolv.conf below the nss level?
<Lathiat> desrt: ya
<Lathiat> nope
<desrt> neat.
<Seveas> mdns-nss would rock the 'it all works' huggy feely feeling Ubuntu has :)
<desrt> ya.  it's very ubuntuish
<desrt> what would really be neat, though, would be out of the box file sharing
* desrt looks cautiously at pitti 
<Seveas> ROFL!
<Seveas> that is just the most bizarre coincidence ever
<desrt> ahem.  perhaps not.
<sobersabre> Keybuk, as for gdb: I may have some mess in my prev. breezy on amd64, let's assume there is a problem with the package. how do I make it to be resolved ?
<sobersabre> desrt, how about a nice out of the box remote root ?
<desrt> sobersabre; only if it makes things easier for the user :)
<Keybuk> sobersabre: file a bug, and provide as much information about your system and how to replicate it
<Keybuk> sobersabre: a bug along the lines of "IT DOESN'T WORK! FIX IT NOW! WAAH WAAH!" isn't that helpful
<sobersabre> Keybuk, the bug is filed. replication is quite easy: run gdb on hello world.
<Keybuk> but "I have the following system: xxx, with the following package versions (of gdb, etc.): xxx, I have this binary: xxx, and when I run gdb on it, this happens: x"
<daniels> except when talking about udev, because you have no idea which of the fifty critical bugs is biting you
<Seveas> Keybuk, the amount of that type of bugs in $(RANDOM_BUGZILLA) suggests otherwise ;)
<Keybuk> sobersabre: clearly that doesn't replicate it, otherwise other amd64 users would have the same problem
<desrt> pitti; was the shock too much for you?
<sobersabre> Keybuk, do I sound like: ohhhh it doesn't work fix it aasdasjgkdhajdgfsd!~!!!
<sobersabre>  ?
<Keybuk> sobersabre: yes ... you're failing to assume that just because it doesn't work for you, it doesn't mean it also doesn't work for everyone else
<pitti> desrt: sorry, X crash - did you ask me anything?
<Keybuk> daniels: grow up
<sobersabre> Keybuk, maybe most of the 'users' don't use gdb.... is it possible ?
<Keybuk> sobersabre: users maybe, but we have many developers on amd64 as I said
<desrt> pitti; just something about having filesharing ala zeroconf setup out of the box :)
<Seveas> pitti, http://www.ubuntulinux.nl/quotes?minid=49
<sobersabre> OK that had some kind of convincing power...
<pitti> daniels: hmm, I tried the "EXA" option, now the screen parts that were scrambled before work; unfortunately some parts that worked before are now scrambled
<pitti> desrt: /quit vomit
<desrt> pitti; see the quote.  it was quite funny :)
<daniels> pitti: sounds about right ...
<pitti> hehe
<sobersabre> ok.. I am rebooting. I will be in touch.
<pitti> daniels: means you expected that? it's not exactly what I call 'mitigate' :)
<daniels> pitti: ati in general is pretty screwed, and there's not a lot we can do, short of you sending benh your laptop for a while, or ati actually sinking some time into the driver
<daniels> argh, 7pm already
<pitti> hi mvo
* pitti hugs mvo
<Keybuk> morning mvo *hugs*
<dholbach> hellas mvo
* pitti changes computer, brb
<mvo> good morning pitti, dholbach, Keybuk
<zakame> heya mvo :)
<mvo> hello zakame :)
<Burgundavia> mvo, is automatic updates a go for dapper? What about the dist-upgrade tool?
<mvo> Burgundavia: automatic security updates is in, needs testing (I backported it to breezy to get more people using it). dist-upgrade tool is worked on, I'm pretty sure we'll get it
<pvanhoof> aaah, fresh morning .. fresh dapper packages
<Burgundavia> mvo, cool, thanks
<pvanhoof> Just love the smell of them
<pvanhoof> (yea, it's morning in europe)
<Burgundavia> pvanhoof, it is morning here too, by 8 min
<pvanhoof> good morning then, Burgundavia  ;)
<pvanhoof> urk .. nautilus is less stable :)
<Tm_T> in what situation dapper installer gives black screen and "Killed" flood? happens every time when installer reaches partitioning step
<Mithrandir> Tm_T: hmm, do you have very little memory in that system?
<Tm_T> Mithrandir: very little, only 64
<Tm_T> I think
* Tm_T is trying to get shell server running
<Mithrandir> Tm_T: it should work with 64, but probably not with 32.
<Tm_T> aye
<Tm_T> I tried two breezy install-cd and now flight-2, all crashes when should partition HD
<Tm_T> Mithrandir: soo, any idea where's the problem and what I can do for it
<Tm_T> there's anything I can test?
<Mithrandir> Tm_T: you might have more luck with trying a lowmem install
<Tm_T> aye, will try it
<Tm_T> haha, this server has as much displaydriver men than system ram =)
<Keybuk> hmm
<Tm_T> Mithrandir: ok, how I get lowmem install, I haven't slept for awhile and I'm bit confused ;(
<Keybuk> Planet Ubuntu is showing the same "Dude, where's my CSS?" bug as the website
<zakame> waah
<jdub> Keybuk: puc used the plone stylesheets.
<jdub> Keybuk: they disappeared. (once planet shifts machines, it'll be fine.)
<Mithrandir> Tm_T: hmm, it appears it should autodetect, which means our numbers are off.  Just try to boot the installer with the framebuffer turned off and see if that helps.  "linux debian-installer/framebuffer=false" on the syslinux command line
<Tm_T> ah, yes, thank you sir
<freeflying> How to patch configure file 
<dholbach_> hellas koke
<koke> hi there!
* mvo waves to koke 
<Tm_T> o7
<jsgotangco> hey
<Tm_T> Mithrandir: sir, that's the trick =)
<Tm_T> Mithrandir: thank you :)
<Seveas> jdub, I have better stylesheets for planet.ubuntu.com if you want them
<Mithrandir> Tm_T: yay, great. :-)
<Seveas> they display OK in IE and other crap browsers :)
<Mithrandir> Tm_T: can you file a bug against "lowmem" and tell us that we need to revisit the memory limits?
<Tm_T> Mithrandir: sure, just if I manage to install this ;)
<jdub> Seveas: that'd be handy, seeing as i'll have to redo them without the plone layout/css - thanks :)
<Seveas> jdub, i'll tar.gz up my planet templates and send them to you
<Seveas> (yes, you need another template, less plone-ish but looks the same)
<Seveas> see planet.ubuntu-nl.org
<jdub> great, i hated the plone html
<Seveas> :)
<Seveas> i'll fix them up a bit, expect them in your mailbox in a few hours :)
<jdub> thanks
<Treenaks> hmm
<Treenaks> I'm supposed to kick daniels today
<Treenaks> but he isn't here
<Amaranth> "glxgears -iacknowledgethatthistoolisnotabenchmark" <--go daniels! :D
<Treenaks> Amaranth: nah, he was going to tell me how to make a register dump of my ATi card (fglrx works; ati/radeon driver doesn't)
<Amaranth> oh, i didn't even see that bit
<Amaranth> i just saw ubotu tell someone to do that to make glxgears show fps numbers
<Tm_T> aye
<Mithrandir> I was hoping he'd push that fps-removing patch upstream, but apparently, he hasn't
<Amaranth> fed up with people using glxgears to show how the latest ATI drivers are 3 fps slower than the old ones?
<zakame> heya seb128 
<Mithrandir> Amaranth: yes, since it's not a benchmark.
<Amaranth> hey seb128 
<Mithrandir> Amaranth: flipping a coin to decide which is faster is just as useful
<mdke> they spoil it for the rest of us who want to see the difference between 1000 and 100
<Amaranth> Mithrandir: It does have one use though.
<Amaranth> what mdke said
<mdke> it depends how you define benchmark really
<seb128> hi zakame Amaranth
<Mithrandir> mdke: it's useless as a benchmark, since 3d apps doesn't OpenGL that way.  3d apps are usually games and they are just pushing zillions of triangles to the screen as fast as possible.
<mdke> Mithrandir, what does it do?
<Mithrandir> it doesn't use shaders and texture mapping, for instance
<mdke> except for looking pretty
<Mithrandir> well, that's the difference of an old card and a new one.  You can do the pretty graphics with the new one.
* jdub can run gta:sa at 1920x1200 with his new card. :o
<fabbione> jdub: only?
<jdub> :)
<Mithrandir> mdke: also, textures and such aren't just "looking pretty".  It's more a question of being reasonable at all or not.
* fabbione points jdub to his 3 heads gaming station ;)
<mdke> Mithrandir, sure, I meant "why does the app exist?"
<Mithrandir> mdke: hysterical raisins, I guess. Possibly also so people who want to play with and learn opengl has a starting point.
<Mithrandir> it's just a sample application, just like the apps which come with gtk
<Amaranth> mdke: fun tech demo
<Nafallo> pitti: I have a debdiff for three CVEs in drupal, but all translations in UTF-8 got added when I did dpkg-buildpackage -S :-P. should I touch debian/rules in this case?
<mdke> Amaranth, Mithrandir, fair enough
<Nafallo> pitti: http://paste.ubuntu-nl.org/6831 <-- from the top of debian/rules :-P
<pitti> heh
<lucas> hello
<freeflying> looking for reviewers for this http://revu.tauware.de/details.py?upid=1434
<lucas> freeflying: please ask on #ubuntu-motu if you really want to ask somewhere. But stopping to spam about review requests and working on merges/syncs might be a much better idea
<freeflying> lucas: got it .thx
<Seveas> pitti, ping
<pitti> Hey Seveas 
<Seveas> pitti, usn 235-239 are not yet on ubuntu.com
<Seveas> that breaks the links in the RSS feed :)
<Seveas> btw: ubuntu.com on moin looks uglier then the plone based site :)
<pitti> Seveas: I'm aware of that; the website was recently migrated to a new system
<pitti> Seveas: Henrik migrated the existing USNs, but I can't yet log in to add the recent ones
<Seveas> k
<pitti> I lure for him, as soon as I can grab him, I'll add them
<Seveas> thanks
<Seveas> why the plone -> moin move?
<mdke> it is easier to edit
<Seveas> ah
<mdke> ironically, given what pitti just said ;)
<Seveas> :)
<mdke> btw, uglier in what way?
<mdke> any difference was probably intentional, so feedback is nice
<Seveas> the footer has a too small font, the menu font is too lightgray, I miss the mini ubuntu logo in said menu, the tabs are smaller which I don't like
* mdke nods at all of those
<Seveas> the search bok has black edges/font instead of the less intrusive grey
<mdke> most are intentional tho
<Seveas> the 'Related Projects' text is unreadable
<Seveas> the news is missing from the frontpage
<Seveas> the footer misses its background image
<Seveas> the footer still says 2005, where it should be 2005-2006 ;)
<Treenaks> Seveas: 2004-2006? :)
<mdke> blimey, good catches
<mdke> Seveas, file em as bugs maybe
<mdke> certainly the ones which are obviously wrong
<Seveas> will do
<Amaranth> the footer text is also microscopic here
<mdke> the tabs are now different sizes on the various websites (wiki, fridge, planet), unfortunately
<mdke> Seveas, rather than filing bugs, perhaps just collect them in an email to henrik
<Seveas> http://bugzilla.ubuntu.com/show_bug.cgi?id=22176
<mdke> Seveas, that'll do :)
<Seveas> jdub, poke
<jdub> Seveas: pong
<Seveas> jdub, nvm, already mailed it :)
<Keybuk> infinity: dude, your patch is fucked ;)
<Keybuk> you don't define progress_size unless there's a /dev/.initramfs
<Keybuk> infinity: uh, in fact, what the buggery bollocks does this patch *do* ?!
<infinity> Keybuk: Oh, I see your "it's fucked" comment.  The progress_size definition should come outside the if block, just in case you have no initramfs state.  Feh.
<infinity> Keybuk: Of course, I didn't test that code path, cause I had proper state. :)
<Keybuk> what I can't work out is what the numbers mean
<Keybuk> you divide the bits of the progress bar up wrong
<Keybuk> did you mean for 2/3 of the bar to be used for initramfs AND rcS
<infinity> Nope, I divide them just fine.
<Keybuk> or did you mean for 2/3 of the bits of the bar after initramfs to be used for rcS ?
<infinity> No, I mean for "2/3 of what initramfs didn't use" to be used for rcS.
<Keybuk> right
<infinity> Which is what the patch does.
<Keybuk> ok
<infinity> Just one line needs to move, to fix the partial upgrade / backward compat problem, that's all.
<Keybuk> so if I make it just use 2/3 of the whole thing if no initramfs state, that should be fine
<Keybuk> needs to move?
<infinity> Asleep at the wheel when I stuck it in the if.
<infinity>                 progress_size=$(((100 - $PROGRESS_STATE) / 3))
<Keybuk> I've put the progress_size bit below the if
<Keybuk> yeah
<infinity> ^-- Move that doen outside the if, and it's unbroken.
<infinity> Yeah.  All fixed.  Since 100 - 0 is conveniently 100.
<Keybuk> indeed
<infinity> Anyhow, stuff moved to .initramfs to minimise people thinking the other directory should exist for more than a day.
<Keybuk> have mixed that in with my code to do the "count down from 100 to 0 in rc0/rc6"
<Keybuk> ok
<Keybuk> I'll change this to use .initramfs too
<infinity> And the above bug not fixed, since you pointed it out about 2 seconds after I pulled the upload trigger. :)
<infinity> But that's okay, I should attempt to sleep anyway.
<infinity> Had a 2 hour nap this evening, after being up for 40+ hours :/
<infinity> Need to go have more.
<Keybuk> you just LOVE uploading beneath me, don't you
<infinity> AND HOW!
* Kinnison gets very very wrong mental images
<Kinnison> I still assert this is too early in the working year for this kind of thing
<infinity> Well, to be fair, I'd rather be on top, but.  <shrug>... I'm not too picky when I'm tired.
<Simira> Kinnison : what? I thought you were like that?
<Kinnison> Simira: eh? wha? buh? umm... it's 01:15@2006, I'm not ready for this yet
* Kinnison had a lovely holiday
<Keybuk> 01:15 ?!  dude, it's 10:37am and most of us have been at work for a week already
<Keybuk> slacker
<Keybuk> ;)
<Simira> 1:15? Where in the world are you?
<Kinnison> Keybuk: I had a large amount of holiday stored up
<Kinnison> Simira: it's 10:40am nearly
<Kinnison> Simira: I was referring to how much I had been at work in 2006
<Simira> ah
* Kinnison is still getting used to typing 2006 rather than 2005
* Simira don't like 2006
<Kinnison> no?
<Keybuk> I like 2006 so far
<Seveas> 2006 so far sucks
<Simira> nothing has gone well for me yet this year
<Kinnison> So far, 2006 hasn't been much except resting and reading of books
<Seveas> fiancee has a brain concushion (sp?)
<Treenaks> concussion ?
<Kinnison> Seveas: concussion, and erk *hug*
<Keybuk> *hugs*
<Seveas> :)
<Seveas> thx
<Keybuk> a concushion would be the opposite thing ... hitting your head on something soft
<Seveas> lol
<Kinnison> Keybuk: or a concussion obtained in derby or the cotswolds
<mpt> speaking of putting one's head on something soft, bedtime for me :-)
<Kinnison> night mpt
<mpt> night
<Seveas> night
<seb128> Nafallo: around?
<Nafallo> seb128: yes
<seb128> Nafallo: is network-manager known to be broken with dapper (a GNOME guy is asking me that)?
<seb128> "<gicmo> it tells me that it doesnt find the necessary resources and just doesnt startup"
<Nafallo> ehrm, I know Keybuk have troubles with it, but it works just fine for me.
<seb128> k, thanks anyway
<\sh> seb128: it just works with dapper on my laptop :)
<fabbione> siretart: ping?
<Nafallo> nm-applet to the session is the only manual step :-)
<Kinnison> yeah, that's a really annoying step too
<Kinnison> you'd think it'd save itself in your session automatically, wouldn't you?
* fabbione hugs Kinnison 
<Kinnison> hey fabbione
* Kinnison hugs
<Kinnison> fabbione: come va?
<Nafallo> pitti: ping
<Mithrandir> do we support nubus pmacs at all?  As in, is there any way to get them working?
<fabbione> Kinnison: everything is almost fine thanks and you?
<Kinnison> fabbione: it's almost all good :-)
<infinity> Mithrandir: If you use a custom kernel that supports the hardware, we'd RUN on them, but there's no way we SUPPORT them..
<infinity> Mithrandir: I don't even think we support my Oldworld PCI Powermac, technically.
<Mithrandir> infinity: ok, so I'll just tell the user that "no, we don't support that old hardware, I'm afraid".
<infinity> Mithrandir: There's no way we could install to a Nubus Mac, and even if he got it on there, I'm pretty sure he couldn't use our kernels, so he'd have a fairly unsupported setup.
<infinity> Mithrandir: But that doesn't stop the software from working, if he shoehorns a working ppc32 kernel on there.. <shrug>
<Mithrandir> infinity: he doesn't appear to be that much of a technical person.
<infinity> Right.  Then "no, we don't support it".
<infinity> Unless you want to be his support monkey.
<Mithrandir> I don't. :-)
<infinity> It'd be disapointingly slow on a Mac that old anyway.
<Mithrandir> he wanted to use the live cd too..
<Nafallo> Seveas: I should edit debian/rules to stop being silly, right? :-)
<infinity> Mithrandir: Ouch.
<infinity> Mithrandir: There are some serious suckers for punishment out there...
<Seveas> Nafallo, you need to stop using php to stop being silly ;)
<Mithrandir> infinity: I don't think he knows how bad it'd be
<pitti> Nafallo: pong
<Nafallo> pitti: may I take "heh" as edit debian/rules to stop being silly? :-)
<infinity> Mithrandir: I have a general idea.  Nubus PMacs only came in two varieties "slow", and "really slow".
<Mithrandir> heh
<Nafallo> in that case I reapply all the patches and stuff and send a new diff ~16:00 CET.
<pitti> Nafallo: oh, if it works, fine for me :)
<Nafallo> pitti: which is fine? the enormous debdiff with UTF-8 or the small one with edited debian/rules? :-)
<pitti> Nafallo: no idea about the big one, but the rules file looked fine to me
<Nafallo> pitti: check security-review for the big diff and add your opinion please? :-) I really, REALLY have to run now :-P.
<pitti> oh, ok
<Nafallo> thanks and bye ;-)
<csj> hello, If I want to make a Ubuntu LiveCD from http://cdimage.ubuntu.com/livecd-base/current/ i386.cloop, I extracted it and chroot into install xorg, gnome,etc, but failed cause lack of /dev/input/mice, what package should I install to autodetect my mouse or some method to solve this problem ?
<Mithrandir> csj: X will be reconfigured anyway on boot
<csj> Mithrandir, is some package to do this work? because I read /etc/X11/xorg.conf , It is correct, but I dont have /dev/input/mice  :(
<csj> although I installed 'discover' but still failed start X
<Mithrandir> csj: casper is currently broken a bit, I'm going to fix that today.
<csj> Mithrandir, ok, I'll try again later, thanks a lot :)
<Mithrandir> csj: it should be ok tomorrow, so if you don't mind waiting, that's the easiest way to get it fixed.
<Mithrandir> csj: if you need it more urgently, build a casper package from http://people.ubuntu.com/~tfheen/bzr/casper/trunk and install that, then use the /boot/initrd-2.6.15-11-386 as the initrd for the cd.
<csj> Mithrandir, ok, I will try it today, and see if it works, thanks :D
<seb128> Nafallo_away: 
<seb128> <gicmo> gicmo@picco cache/apt/archives % /usr/bin/nm-applet
<seb128> <gicmo> ** (nm-applet:15409): WARNING **: Icon nm-stage01-connecting01 missing: Icon 'nm-stage01-connecting01' not present in theme
<seb128> <gicmo> (nm-applet:15409): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
<seb128> Nafallo_away: idea on that?
<seb128> Nafallo_away: it was a gtk cache not updated...
<janimo> seb128, is shutdown/PM still being done through gdm?
<pitti> infinity: ouch, mysql 5.0 built 4.1 server/client, too? that sounds hackish...
<lifeless> yewwww
<janimo> ogra, how easy would it be to have xscreensaver unlock screen look like in breezy (passwd field mostly)
<janimo> now i't ugly ******
<seb128> janimo: we switched to gnome-screensaver so we dropped the Ubuntu specific hack for xscreensaver
<seb128> janimo: yep, action are made by gdmflexiserver
<infinity> pitti: s/hackish/wrong/ .. I stopped it on the buildd before it could produce the wvil binaries in question.
<segfault> will xscreensaver still be the default of dapper?
<janimo> seb128, but is power handling supposed to be taken over by some power-daemon through dbus at some point in dapper?
<janimo> segfault, no see what seb said
<janimo> but it will be used for xfce
<seb128> janimo: gnome-power-management, why?
<janimo> seb128, I thought mjg59 was working on such a thing
<janimo> maybe I misunderstood
<segfault> nice
<janimo> having it though gdm is a bit of a hack
<seb128> janimo: still gnome-power-management
<seb128> janimo: why?
<janimo> it's dispplay manager not a power manager :)
<janimo> it's the wrong place to have such code
<seb128> ?
<janimo> mjg59, around?
<seb128> janimo: it has a daemon and some frontend
<janimo> yes, and such a dedicated power daemon could replace it
<janimo> so powering down the machine would not depend on having gdm running
<janimo> common for gnome/kde/xfce /console
<seb128> janimo: https://wiki.ubuntu.com/PowerManagementConfiguration
<janimo> thanks, I'll have a look
<seb128> janimo: again, that's gnome-power-manager
<janimo> oh, then why does gdm come into it?
<seb128> janimo: why don't you look on the stuff instead of saying the same thing again and again?
<seb128> janimo: because atm we use gdm and not gnome-power-manager ...
<janimo> finally.that's my question then
<seb128> ?
<janimo> rephrase: are you switching to g-p-m in dapper?
<janimo> instead of patching gdm to do pm
<seb128> I think that's the plan
<seb128> but Depends on how gnome-power-manager comes, if it's good enough, etc
<pitti> Seveas: I added the recent USNs, so your links should work again :)
<Seveas> pitti, muchos gracias
<Seveas> pitti, wouldn't it be nice to offer the rss feed from ubuntu.com? It's used quite a lot according to my logs :)
<pitti> Seveas: sure
<Seveas> shall I send you the script or do you prefer to link to the existing feed?
<pitti> Seveas: I have no idea about RSS; maybe we can just use your feed for now?
<pitti> Seveas: I ask our web page guru
<Seveas> pitti, k, I have no problems with either option :)
<Seveas> the script is simply subscribed to the security mailing list and parses all incoming messages
<Treenaks> Seveas: does it do gpg verification yet? *hides*
* Seveas slaps Treenaks 
<pitti> Seveas: what's the url?
<Seveas> pitti, ubuntulinux.nl/files/usn.xml
<Seveas> Treenaks, find me a python gpg module that actually *works*, then it will
<Kinnison> Seveas: well, pyme works
<Treenaks> Seveas: open some pipes, invoke gpg, read pipes
<Kinnison> Seveas: it's just ugly as sin
<tseng> Seveas: there actually is a USN feed on the site
<tseng> Seveas: but its really hard to find
<Seveas> Treenaks, that won't cooperate with the python mail lib
<Treenaks> Seveas: it accepts plain text strings! of course it cooperates
<pitti> Seveas, meet hno73, our webmaster
<Seveas> hi hno73 :)
<hno73> Seveas: hi :)
<sobersabre> hi... as promised I've installed breezy on my amd64 machine... and gdb does suddenly work.
<sobersabre> :)
<Seveas> tseng, care to give a clue to the location?
<tseng> Seveas: http://planet.ubuntu.com/news/ is subscribed to it
<tseng> Seveas: so jdub could remind us
<sobersabre> I have a q. is there a breezy libjavahl package for amd64 ?
<tseng> or, it was
<sobersabre> (I tried to build it myself, but something is wrong with it... )
<hno73> Seveas: you were wondering about RSS feeds from the new website?
<hno73> niemeyer has actually written an RSS macro for moin: http://labix.org/irss that I'd like to try
<mdke> hno73, yo
<Seveas> hno73, I have an rss feed of the USN's which was broken due to the site reorganization, that's fixed but I asked Pitti if it would be nice to offer this thing from ubuntu.com
<mdke> hno73, do you have access to add macros to the wiki?
<Seveas> it's used by quite a few people :)
<Seveas> hno73, btw, seen http://bugzilla.ubuntu.com/show_bug.cgi?id=22176 yet? :)
<hno73> mdke: happy new year!
<mdke> hno73, same :)
<hno73> mdke: not directly, but it can be arranged
<hno73> Seveas: yes, thanks. I've fixed about half of them
<pitti> Mithrandir, fabbione: Matt urged me to upload the sudo change soon ('give a pointer to sudo in /etc/profile until sudo is successfully executed the first time')
<hno73> some are more tricky, and some I don't agree with :)
<Mithrandir> pitti: wasn't this going to be discussed by the tech board?
<pitti> Mithrandir, fabbione: would you like to discuss this in TB? or shall I just do it for now so that we can test it?
<Seveas> hno73, that's all your call :)
<fabbione> pitti: bah
<fabbione> pitti: i would like to discuss it at the TB meeting
<pitti> Mithrandir: yes, we can do that of course, but TB is next week
<Seveas> hno73, but please make the tabs consistent and fix "Related Projects" :)
<Mithrandir> pitti: I'm not worried about the implementation, as I've said before.  I'm worried about the rest of it.
<hno73> Seveas: like I think the new tabs are nicer, but they need to be pushed onto the other sites as well
<pitti> Mithrandir, fabbione: hm, ok, I add it to the agenda now
<hno73> Related projects font was too weak right? see now
<Seveas> hno73, they're too small
<Seveas> fontsize +10% or maybe +20% and I'd agree :)
<hno73> hm, can try
<pitti> BenC: ping
<Seveas> related projects is more readable, but still "doesn't look right"
<Seveas> hno73, how about fount-weight: bold and border-bottom: solid 1px $color?
<hno73> border bottom of what? the tabs?
<Seveas> no, "related projects"
<mdke> hno73, mailed you the macro
<hno73> mdke: thanks
<mdke> thank _you_
<Seveas> tabs are cool now, maybe 1px/2px more whitespace below the text, the 'p' in developers is too low
<hno73> Seveas: can you please email me a screenshot of what it looks like for you and one where it 'looks right'? ;)
<Seveas> hno73, sure :)
<hno73> henrik@ubuntu.com
<hno73> Seveas: btw, there is a limit to how much I want to play with the layout on the live site ;) Font size and colour are ok, but when you start playing with spacing in CSS things can break. The tab spacing is a bit fragile. Needs testing in multiple browsers, etc.
<mdke> infinity, any progress on the ubuntu-docs update for breezy?
<janimo> mdke, what does it take to get a svn account for xubuntu docs?
<dholbach> infinity: could you give back gnome-terminal, when you have the time?
<dholbach> infinity: ...please... :-)
<mdke> janimo, at the moment there are none. Afaik, it's just the docs from upstream
<janimo> so there's not ubuntu docs repo? that'w what I thought so far
<mdke> janimo, there is an ubuntu docs repo (https://wiki.ubuntu.com/DocumentationTeam/Repository) but we do not work on any xubuntu docs as yet, or ship any in dapper
<juliux> anyone who wants to make a ubuntu-dev talk at the linuxtag 2006 in wiesbaden/germany ?
* martink tries not to make a comment wrt juliux' 2005 talk...
<juliux> martink, no
<fabbione> juliux: you might want to ask doko/mvo/pitti/
<juliux> fabbione, yes i know, but i want ask all devs
<fabbione> juliux: when is that?
<mdke> janimo, were you thinking of including some xubuntu specific docs in dapper?
<mantiena> Hello all
<juliux> fabbione, 3-5 mai
<juliux> h 3-6 mai
* fabbione can't
<juliux> more information at http://www.linuxtag.org/2006/
<fabbione> juliux: thanks for the offer, but i can't
<juliux> fabbione, ok 
<fabbione> it's while i promised myself to go back in .de :)
<pitti> juliux: AFAIK that's the time of our next conference, so we can't
<juliux> pitti, i think a week later
<fabbione> ohj true
<juliux> pitti, so you have time ;)
<fabbione> there will be UbuntuSomeWhere
<Treenaks> UbuntuUpYours ;)
<juliux> fabbione, but i think i will be 2 weeks after dapper
<fabbione> juliux: dapper is due to 20 apr
<fabbione> + 2  will hit exactly that weekend
<juliux> ok shit
<pitti> juliux: no, www.linuxtag.org/2006 says it's 3-6 May, not a week later
<ogra> juliux, i was invited
<juliux> hi ogra 
<juliux> ogra, has you send something to the cfp ?
<fabbione> specially if we need to travel to <insert_here_remote_island_in_the_middle_of_no_where_and_far_from_any_civilizated_city>
<ogra> i already told the guy we have an overlap in the dates
<juliux> yes i know but i have to try it
<ogra> no chance to get one of the core devs for it, except if our next conference is in wiesbaden ;)
<juliux> and i could be that there is no overlap ;)
<juliux> it doesnt must bee a core dev ;=
<dholbach> juliux: ask the german motus in #ubuntu-motu :)
<mantiena> Kamion, hi, do you have some time to talk about ubuntu-express ? I've got your email from bugzilla, I've fixed several ubuntu-express bugs, did few improvements, also translated to Lithuanian language and I wanna work together ;)
<juliux> i want a dev no motu -D
<juliux> :-D
* dholbach tsssssssss
<dholbach> juliux: and we do have 'core developers' (if you refer to the launchpad team), that are in #ubuntu-motu (and are from germany)
<juliux> dholbach, i know
<Kamion> mantiena: http://people.ubuntu.com/~cjwatson/bzr/espresso/ubuntu/
<juliux> dholbach, but the talk could also be in english so i ask here
<Kamion> I don't want to take translations yet; too much stuff is changing
<Kamion> and I'm essentially rewriting most of it, just using the Guadalinex code as a basis
<mantiena> Kamion, hehe, I understand you ;) some parts of guadalinex work are really bad
<Kamion> I don't particularly want to judge, but they had different goals; it is essential for our live installer to reuse code from the regular installer, otherwise we run into serious maintenance trouble further down the line
<Kamion> I'm currently working on making espresso reuse partman
<mantiena> Kamion, I don't think, that they had different goals, on guadalinex ubuntu-express worked some students, etc. and from my conversations to them I understod, that integrating debconf with ubuntu-express was too hard for some of them ...
<mantiena> it's sad to tell, but for me too :-/
<Kamion> it's certainly not easy; I don't blame them for having trouble with it
<Kamion> but it's worthwhile
<Seveas> hno73, <aol>You've got mail :)</aol>
<mantiena> Kamion, could you tell me what is current status of your ubuntu-express code ? is installer working ? At least partially ?
<Seveas> Kamion, 'espresso' is named after the beverage you need a lot while writing it i guess :)
<dholbach> elmo: could you please sync texinfo from sid? ok, to override.
<Kamion> mantiena: it starts up and the user/password/hostname screen works, but beyond that it's pretty broken. I've agreed with mdz that my target is to get something basically working by the time of the distro team sprint in London at the end of this month.
<Kamion> Seveas: pretty much, yeah ...
<fabbione> elmo: could you please fix network-console override? according to w-b it's a pkg main, but that's not true.. source & bin are in universe. thanks
<mantiena> Kamion, hehe, it seems your target is simmilar to me - I need working installer to the end of this month ;)
<mantiena> Kamion, so, I want and can help with Ubuntu-express. I know guadalinex code, most bugs, etc. I could code/fix some simple parts
<ogra_ibook> any reson why there are no edubuntu liveCds since friday ?
<infinity> dholbach: Done.
<infinity> mdke: Can you bug me incessantly about it tomorrow?
<dholbach> infinity: merci beaucoup
<Mithrandir> ogra_ibook: edubuntu-desktop isn't installable?
<Kamion> mantiena: my problem is that my targets are sufficiently tight that I don't have time to bring anyone else up to speed on the code or rely on contributions from other people right now; I hope for that to change once espresso's looking healthier
<ogra_ibook> it is on the install CD according to the daily report file
<Mithrandir> ogra_ibook: I presume you know about http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html ?
<Kamion> mantiena: you're welcome to check it out of bzr at the URL above and poke about with it; you'll need to be running very current dapper
<Kamion> but I won't have any time to support you for the next month or so, I'm afraid :(
<Kamion> I hadn't been planning to solicit contributions until February
<ogra_ibook> Mithrandir, yes, but that report is from today, yesterday must have been fine according to http://cdimage.ubuntu.com/edubuntu/daily/current/report.html
<Kamion> please don't rely on the cdimage report to try to figure out why live CDs aren't building
<Kamion> it's obviously as of a specific point in time rather than current, and it only covers the packages on the install CD which isn't always sufficient for live CD builds anyway
<Mithrandir> ogra_ibook: the dapper_probs has listed edubuntu-desktop as being broken for at least half a week
<ogra_ibook> i was relying on edubuntu-desktop installability ...
<Kamion> also sometimes the install CD can just fluke it due to weirdness
<ogra_ibook> ok
<Kamion> so use dapper_probs.html instead please
<ogra_ibook> yup, will do
<stockholm> is mdz around when awake?
* stockholm waves to ogra_ibook 
<Mithrandir> stockholm: usually
* ogra_ibook waves back to stockholm 
<stockholm> Mithrandir: so he should be on in about 4h?
<Mithrandir> stockholm: yes
<ogra_ibook> likely
* ogra_ibook glares at the output of ybin ...
<ogra_ibook> ybin: Blessing /dev/hda2 with Holy Penguin Pee... ????
<mdke> infinity, i'll try
<ogra_ibook> *giggle*
<Seveas> ogra, wtf?
<Treenaks> Seveas: that's yaboot :)
<janimo> mdke, sorry was away
<janimo> yes I'd like to have xubuntu docs in dapper
<janimo> of course not as part of the ubuntu-docs package but I thought if you have collaboration infrastructure set up
<janimo> the xu documenters could use it too
<mdke> janimo, yes of course, we were not aware that they existed
<mdke> janimo, perhaps they could post to the ubuntu-doc mailing list?
<janimo> 'they' indeed do not exist :)
<mdke> oh
<janimo> I was hoping if a more formal procedure is provided 'they' would come out of the woods
<janimo> there were people ocasionally sending me bits of doc
<janimo> or showing interest in helping
<janimo> so they definitely are willing just misguided (as am I in this area)
<mdke> janimo, the first thing that needs to be sorted out is the relationship with the upstream docs, are there enough changes to xfce in Ubuntu to warrant separate documentation?
<janimo> but I'll announce on xubuntu-devel and pick them up and direct them to you r list
<janimo> not really many changes
<janimo> but we'll probably have to describe the deafult config (panel/menu)
<mdke> ok
<janimo> and the selction of apps since xfce is just the desktop not as many blessed apps as gnome
<janimo> it is mostly so they have a common repo they can commit to
<janimo> instead of sensing me diffs of html docs ;)
<mdke> i think we should be careful about making documents which overlap with the upsream ones tho
<mdke> the xfce docs are already quite good, i think
<janimo> they are indeed
<janimo> we'll just need to doc the additional changes we make
<janimo> in separate docs
<mdke> okay
<janimo> right now we have the ff start page
<janimo> maybe that would do for dapper too, but still it needs people working on it concurrently
<janimo> and I can package it from time to time
<mdke> janimo, ubuntu-doc won't work on the firefox start page for dapper, it will be replaced by start.ubuntu.com afaik
<mdke> not sure how that will work for derivatives
<janimo> mdke, so instead of local page people will go to the net on first start?
<mdke> yeah
<mdke> jdub can tell you more
<doko_> mvo: isdn ping
<mdke> the spec is at wiki:BrowserDefaults
<janimo> mdke, thanks.
<mdke> np
<BenC> pitti: pong
<zakame> hi stockh0lm :)
<zakame> hello devs :)
<lguerra> ogra: PING
<ogra_ibook> lguerra, pong
<lguerra> ogra, how i report any error in launchpad http server ?
<fabbione> lguerra: launcpad is having an upgrade
<fabbione> relax :)
<lguerra> ohhh
<lguerra> tks
<ogra_ibook> file a bug in malone 
<ogra_ibook> ah
* ogra_ibook didnt know
<janimo> ogra_ibook, how hard would it be to get xss unlock screen dialog back to what it was in breezy?
<janimo> now it's ugly :)
<tseng> install gnome-screensaver
<ogra_ibook> janimo, we drop xss
<janimo> guys, xubuntu
<ogra_ibook> janimo, the patch is in breezy as dpatch, i guess it would be minimal work to adjust it for the current package, so if its important for you to have xss instead of gss it should be easy ...
<janimo> I assume gss brings in all gnome deps,otherwise I'd be happy to go with it
<tseng> apt-cache depends
<ogra_ibook> but note that you'll loose power management capabilitys with xss ... gss will be much better integrated with the power manager
<allee> pitti: libghoto2-2.  Can you look at http://bugs.kde.org/show_bug.cgi?id=119769 ?   I know nothing about hal config yet, but in case your are busy I can try to compare with SuSE to fiddle out what's wrong.
<janimo> ogra_ibook, yeah too bad for pm :(
<doko> Diziet: firefox-dev/mozilla-dev ping ...
<janimo> ogra, is power-manager deprecated? uses old dbus does not install
<ogra_ibook> use gnome-power-manager
<janimo> that has both the back and the frontend?
<ogra_ibook> power-manager will either disappear or being rewritten by mjg59 as dbus backend ... not sure which path he goes 
<pitti> hi allee, I'm back from lunch
<allee> pitti: np 
<allee> pitti: the gphoto problem are not a bug in KDE mediamanager but in the hal config not generated by libgphoto
<pitti> allee: hmm, works fine for me
<pitti> Hi BenC
<allee> pitti: uh, when you plugin a gphoto2 supported camera the camera config settings returned by hal are correct?
<pitti> allee: can you reproduce the problem?
<pitti> allee: yes, I get 'camera.access_method = 'ptp' and 'info.category = 'camera' 
<allee> pitti: yes. 'cause I wrote the bug report ;)
<pitti> allee: and info.capabilities = {'camera'}
<pitti> allee: can I debug this with you right now?
<pitti> I'll /msg you
<allee> 'k
* allee searches the camera
<kikidonk> dholbach: ping
<Diziet> doko: Hello.
<dholbach> kikidonk: pong
<kikidonk> dholbach: hey, i have a problem with dapper, eclipse seems broken
<kikidonk> dholbach: eclipse-jdt and eclipse-jdt-common are dependeing on each other
<dholbach> kikidonk: I never touched eclipse, I have no idea :-/
<kikidonk> seb told me you were the 'responsible' :P
<dholbach> kikidonk: he did?
<dholbach> seb128: ^^ :)
<kikidonk> who is in care of java packages ? 
<dholbach> doko worked on eclipse every now and then
<doko> Diziet: some things: are some plugins built without -fPIC on amd64? i.e. xpcom and gtkmozplugin? 
<mjr> hmh, I don't think so:s without -fPIC are supported on amd64? (I might be wrong, but I've gotten that impression)
<seb128> kikidonk, dholbach: I said I will ping dholbach if he knows who is working on that, etc
<doko> Diziet: could you prepare an installable mozilla-dev package?
<dholbach> :)
<kikidonk> hehe
<seb128> kikidonk, dholbach: doko did an eclipse upload since
<seb128> but it didn't build yet
<kikidonk> aha
<seb128> I assumed he's working on it so didn't bother dholbach
<seb128>  eclipse (3.1.1-8ubuntu1) dapper; urgency=low
<seb128>  .
<seb128>    * Synchronise with Debian unstable.
<kikidonk> ah ok :)
<seb128> ...
<mjr> (come to think of it, I got that impression while trying to link non-fPIC code into a .so)
<kikidonk> perfect
<mjr> didn't delve further into it to find out if some magic would allow that still
<Diziet> doko: Err, I have no idea about -fPIC or not on amd64 I'm afraid.  I could check it out but not for a few days because I want to do something other than firefox maintenance.
<Diziet> And, um, mozilla-dev ?
<Diziet> Wouldn't that be part of mozilla ?
<Mithrandir> Diziet: all shared libs should be built with -fPIC, both on i386 and others
<Diziet> mithrandir: Certainly.
<Diziet> I didn't change the way they were built though.
<Diziet> I'm prepared to believe that it's wrong.  If it's wrong then please do file a bug, P1, and I'll deal with it in my next batch.
<doko> Diziet: mozilla-dev has a versioned dep on the exactly same version, which is now broken, because libnspr-dev and libnss-dev are built from the firefox sources
<Diziet> Why use mozilla-dev at all ?
<Diziet> For that matter, why this versioned dep ?  Why a dep at all ?
<doko> Diziet: because eclipse doesn't work with firefox yet
<Diziet> What's eclipse ?
<ogra_ibook> nvu (universe) neither
* Diziet 's ignorance knows no bounds.
<doko> Diziet: yes, that's true
<Diziet> `doesn't work' ?
<Diziet> Or you mean upstream eclipse is incompatible with the embeddable firefox ?
<Diziet> The point of having nspr and nss in firefox was to make firefox-dev 
<Diziet> Err, I mean,  to make mozilla not need to be in main.
<doko> Diziet: apparently firefox 1.5 did introduce an incompatibility, which didn't exist with 1.0.x
<Diziet> Nice.  And it's not fixed upstream yet ?  So presumably it's nontrivial.
<Diziet> I still don't understand why mozilla-dev has a dependency on firefox at all.
<mantiena> doko, hi
<seth> yeah, the eclipse thing has been bugging me too :) glad to know it's been noticed, though
<Diziet> Surely it should provide its own versions of everything, if it's being an alternative to ff.
<mantiena> Kamion, still online ?
<doko> Diziet: will you fix the mozilla-dev dependency? at least you did brake when you started to build libnspr-dev and libnss-dev from firefox
<Kamion> mantiena: yes, but working
<Diziet> The whole point of this nss/nspr thing was to be able to move mozilla to universe.  Why is it still in main ?  And, I did this at the request of Ubuntu mozilla people.
<Kamion> packages are only promoted/demoted to main/universe semi-automatically
<Kamion> mozilla is still in main because stuff still depends/build-depends on it
<Diziet> Ah.  I thought the seed system would do that bit ?
<Kamion> it tells us what to do, but the actual moving is done by ftpmaster by hand to provide a sanity check
<Diziet> Right.  https://wiki.ubuntu.com/SeedManagement doesn't seem to say where the germinate log goes.
<Kamion> DeveloperResources has a link to it
<Kamion> I'll add it to SeedManagement too, thanks
<Diziet> The requested URL /~cjwatson/germinate-dapper-output/ was not found on this server.
<Diziet> http://people.ubuntu.com/~cjwatson/germinate-output/dapper/  now it seems
<Kamion> yeah, I just independently fixed the link on DeveloperResources
<Kamion> rdepends/mozilla/ is probably the place to start looking in there
<mantiena> Kamion, just one question: Why you told me, that I need very current dapper to work on Ubuntu-express?
<Kamion> mantiena: because it requires new features in debconf and new packages produced by bits of the installer
* stockholm eats lots of chocolate instead
<Diziet> Hrm.  Mainly, it seems to be mozilla-psm.
<Diziet> I have no idea why mozilla-psm is in the seed.
<Kamion> http://people.ubuntu.com/~cjwatson/germinate-output/dapper/rdepends/mozilla/mozilla-dev indicates two extant build-dependencies on mozilla-dev
<pitti> Kamion: librsvg2 is scheduled to be built against ffox-dev by seb128's next update
<Kamion> mozilla-psm needed to be there while we supported mozilla, but no longer does; I've removed it
<pitti> Kamion: and for enigmail it's a matter of splitting the package for mozilla and tbird
<Kamion> we need to drop mozilla-locale-* too
<mantiena> Kamion, thanks for explanations
<Diziet> Indeed.
<Diziet> Yes, thanks, Kamion.
<Kamion> ok, mozilla-locale-* dropped too
<Diziet> enigmail for mozilla needs to be built against mozilla-dev ?  That's tiresome.
<SteveA> mjg59: hello
<pitti> Diziet: apparently, yes; but we can either just drop enigmail for moz completely, or split the package
<mantiena> Could anyone tell me why ubuntu-desktop depends on various python-xxx packages, for example on python-mysqldb, python-dictclient, etc ? There are no other packages, depending on these python packages in standard ubuntu-desktop installation... Are such python-xxx packages really needed to be in ubuntu-desktop ?
<pitti> \sh: ping
<\sh> pong...wine..i know
<pitti> \sh: heh, how could you know? :)
<Kamion> mantiena: explicit request from Mark
<\sh> pitti: well..I'm good and working on it...
<pitti> \sh: yay, thanks
<pitti> \sh: do you have the patch?
<\sh> pitti: http://article.gmane.org/gmane.comp.emulators.wine.patches/20976
<pitti> \sh: exactly
<Kamion> mantiena: AIUI, he wants to pitch Python as a desktop development language for Ubuntu in much the same way as Visual Basic is for Windows
* pitti giggles that wine is so compatible to even run windows' security exploits
<SteveA> mantiena: iirc, the idea is that someone can install ubuntu, and then get cracking writing useful python thinggies
<Nafallo> pitti, smurf, Seveas: the debdiff looks better now, doesn't it? :-)
<Kamion> so it makes a certain amount of sense to flesh out the desktop seed with useful Python packages; also the ones that are there aren't particularly big anyway ...
<Kamion> (we got rid of the biggest ones last time we hit serious CD space pressure)
<Seveas> Nafallo, it's still icky
<\sh> pitti: which distros? from warty on, or hoary breezy dapper?
<Nafallo> Seveas: where?
<Seveas> Nafallo, the mini html tutorial
<Seveas> that simply is not a security patch
<pitti> Nafallo: no idea, I see your second mail twice, but I don't see a new patch
* pitti syncs mail again
<Seveas> and there is new functionality (html enabled)
<Nafallo> pitti: there is a third now that I'm home :-)
<pitti> \sh: whatever you want; breezy would be nice, earlier universe packages are a lost cause anyway
<Seveas> pitti, 15:48
<pitti> Nafallo: ah, you started a new thread
<\sh> pitti: ok...will bring a new version including patch to dapper (0.9.5) then breezy and eventually hoary
<Nafallo> sorry for the double mail, I hate outlook :-P
<pitti> Nafallo: hmm, but *removing* stuff from debian/rules is not really appreciated either
<pitti> Nafallo: it's true that we don't care for woody compatiblity in breezy, but if it's there, it shouldn't be touched
<pitti> \sh: you rock, thanks
<mjg59> SteveA: Hi
<Nafallo> pitti: you did see the debdiff before? :-) I'll go with what you say anyway. if it's more than "heh" this time ;-).
<doko> mvo: isdn ping
<mvo> doko: pong
<pitti> Nafallo: why did you remove all the security checks?
<pitti> Nafallo: the patch almost looks like being applied backwards
<\sh> pitti: do you have the cve number for that bug?
<pitti> \sh: CVE-2005-4560
<\sh> pitti: thx :)
<Nafallo> pitti: I compared to upstream patches and it looks the same.
<pitti> odd
<Seveas> Nafallo, the security checks are moved, not removed
<pitti> -  return check_url($uri);
<pitti> +  return $uri;
<Seveas> pitti*
<pitti> Seveas: (that's fine, I highlight on 'security', too :) )
<Seveas> the uri is checked later with the xss function
<pitti> ok, I see
<Seveas> but the patch adds all kinds of html posting functionality
<SteveA> mjg59: my laptop running breezy went a bit insane on unsuspending, like it did a while ago at UBZ.   what i think happened is i told it to suspend by pressing the standby button.  it didn't, so i told it again.  then it did.  on awaking later, it would send itself to sleep about 1 min later.
<Seveas> which is just icky in a security patch
<SteveA> the logs indicate a bunch of ACPI events being sent, with no obvious cause, just before the unrequested sleep
<mjg59> SteveA: Uhm. That should have nothing to do with the kernel.
<mjg59> SteveA: Oh, sorry, misread seveas as you
<SteveA> i fixed it by commenting out lines in the /etc/acpi/ scripts
<mjg59> SteveA: Hm. Odd.
<Nafallo> I hate php :-P
<SteveA> and waiting a while, and then uncommenting them
<SteveA> are the logs any use to you?
<pitti> Nafallo: phew, does that patch ever end? it's huuuuge
<Seveas> Nafallo, so do I :)
<Nafallo> pitti: hehe, three upstream patches so... ;-)
<pitti> Nafallo: could you test the package thorougly? did you see any apparent regressions?
<pitti> Nafallo: I wouldn't accept this patch for main, but if you feel confident about it, it's upstream for a while now without any regressions, fine for me
<Nafallo> I haven't been able to yet. was at "work-like place" without internet ;-)
<doko> mantiena: pong
<Nafallo> Seveas: the "HTML tutorial" being that stuff in filter.module? :-)
<Tm_T> where should I file a bug/wish about installer?
<Seveas> yes
<Seveas> Tm_T, bugzilla.ubuntu.com
<Tm_T> Seveas: ah, thanks
<mantiena> doko, I have one question about OOo 2.0.1 for ubuntu breezy. There are packages at people.ubuntu.com/~doko/. Do you plan move these packages to breezy-updates ?
<doko> mantiena: not yet decided. looks like there are regressions in -base
<doko> mantiena: do you want to look at it?
<mantiena> Kamion, wouldn't be better to create ubuntu-desktop-python metapackage for various python-xxx and make ubuntu-desktop depend on this package?
<mantiena> doko, I'm installing OOo 2.0.1 in my system, based on ubuntu breezy now ;) Do you know bug numbers of these regressions ?
<Kamion> mantiena: I don't see that that would make any significant difference to users, and it would be more work
<Nafallo> Seveas: hmm, I don't like upstreams patches anymore ;-)
<doko> mantiena: just search for openoffice ...
<doko> mantiena: in bugzilla
<mantiena> doko, in bugzilla.ubuntu.com ?
<mantiena> Kamion, there is difference for users and developers, because now there is unclear which packages are really needed for desktop user and which are only for developing with python
<zakame> mantiena: yep
<Kamion> mantiena: for developers, that's documented in the seeds
<doko> mantiena: yes
<mantiena> doko, ok, thanks, I will look at this tomorrow
<doko> Kamion: could you shed som light on the non-existance of unrar, built from the unrar-nonfree source in dapper?
* Nafallo starts listening to doko and Kamion ;-)
<Tm_T> Mithrandir: filed, I think I'm too poethic mood to file bugreports though...
<Kamion> Rejected: file 'unrar_3.5.2-0.1_i386.deb' has unknown component 'non-free'.
<Kamion> doko: ^--
<Kamion> dunno why it's not overridden to multiverse; you'd have to ask elmo
<jsgotangco> Kamion, OT do you know Hande?
<Kamion> jsgotangco: no
<jsgotangco> ok tnx
<Kamion> well apart from knowing that she works for Canonical
<jsgotangco> ah ok so Hande is a she
<jsgotangco> that's what i was about to ask
<jsgotangco> thanks =)
<Kamion> I had to look it up; I had been about to say "he/she/er-how-embarrassing"
<pitti> hunger: can you please forward the libpam_mount patches to Debian?
<pitti> hunger: I'll apply them now, but for the future Debian should fix them as well
<lotusleaf> Will Dapper resolve the issue of some programs not showing up in menus but only in the add-on 'Debian' menu?
<\sh> doko: ping
<\sh> doko: I have a problem with the last fontforge upload to breezy from 2005-09-21...I can't compile wine anymore...because it produces a nice fontforge problem
<\sh> doko: before this upload of fontforge wine was build without any problems :)
<\sh> well..actually it was a sync
<Keybuk> "Excuse me, you sent me an e-mail to say my credit card was declined; now you've just sent me an e-mail to say my order has been dispatched.  Err?"
<Keybuk> "Oh yes sir, that always happens."
<Keybuk> *blink*
<mdke> lotusleaf, no. even more applications will not show up in menus for dapper
<lotusleaf> mdke, well, at least that menu is available. :-)
<mdke> lotusleaf, see https://wiki.ubuntu.com/MenusRevisited if you'd like to read and comment on the proposals
<mjg59> Keybuk: Minor downside with madwifi-ng - it needs userspace crack to actually give you a usable interface
<lotusleaf> mdke, great, thanks! :)
<Keybuk> mjg59: oh?
<Keybuk> does it not work with iw* ?
<mjg59> Keybuk: It gives you something that sends raw packets, then you need to wlanconfig it to give you an actual useful interface (which then speaks iw*)
<Keybuk> kooky
<mjg59> But that can probably be wedged into post-modprobe for the common case
<Keybuk> can you make multiple interfaces
<Keybuk> yeah, easy enough in a udev rule
<mjg59> Yeah
<Keybuk> reminds me that I need to turn those ugly alsa modprobe install hacks into udev rules
<Keybuk> err @ mom
<Keybuk> "new changes have occurred" ... no they haven't
<Keybuk> YOU'RE HALLUCINATING
* desrt blinks
<Keybuk> wonder if that's just because new changes in Ubuntu have occurred
* Keybuk sends mom off to rehab
<elmo> jsgotangco(/kamion): FYI, Hande is sitting 3 feet away from me, your questions caused quite some amusement in the office ;-)
<doko> \sh: why does wine need fontforge at all at build time?
<elmo> jsgotangco: and for future ref '<name> gender name' in google is often helpful ;-P
<jsgotangco> elmo, heh thanks
* desrt blinks a bit more
<\sh> doko: because of some fonts faces ...which are turned magically via fontforge into something I don't have a clue about...but it is font related
<Kamion> mostly if I don't know the gender of a name I just don't care until I suddenly have to use a pronoun and then my brain stops for a bit. :)
<desrt> Keybuk; wtf?
<mdz> stockholm: ?
<Keybuk> Kamion: "them"
<siretart> sb goto 4:34
<siretart> argl, sory
<\sh> doko: but it's annoying to have a ftbfs in a stable archive ;)
<stockholm> mdz: did you get the mail about uml?
<stockholm> mdz: there is a guy that wants to adopt it
<Keybuk> *+
<stockholm> mdz: he was recommened to me from peopel on #uml
<mjg59> Has asf been disabled in our gstreamer0.10-ffmpeg?
<hunger> pitti: Thanks for looking into the mount.crypt issues I had!
<Kamion> Keybuk: my internal grammar pedant sometimes rebels
<pitti> hunger: you're welcome, thanks for the fixes
<pitti> hi mdz
<mdz> stockholm: I get mail about someone adopting UML every month or so; I always tell them to go ahead, but so far no one has actually uploaded anything
<mdz> pitti: good morning
<mdz> stockholm: but what does this have to do with ubuntu?
<desrt> so.... question of questions
<desrt> will dapper have mp3 support on the cd?
<doko> \sh: AFAIK fontforge was just updated to a new major version, which was needed for some fonts (dejavu), which we did move to main 
<elmo> desrt: no
<desrt> elmo; what is preventing it from happening?
<elmo> desrt: patents
<desrt> elmo; are you aware of the fluendo announcement?
<elmo> desrt: yes
<dman13> I'm looking for someone with write access on ubuntulinux.org to report an error to.  Anyone want it?
<wasabi_> File a bug.
<Keybuk> elmo: doesn't the fluendo binary mean it could go in restricted
<Keybuk> that has a patent licence
<dman13> It's not that big of an error (just a copy-and-paste item)
<dman13> :-)
<elmo> Keybuk: that falls well outside of the scope of restricted
<desrt> Keybuk; ubuntu can even sign a contract with fluendo and gain the ability to compile their own patent-compliant binaries
<wasabi_> Well nobody is going to remember it any other way.
<dman13> true, unless they have write access and spend ~20 seconds fixing it now
<dman13> I was hoping to make the process shorter by finding the right person :-)
<wasabi_> File a bug, the right person will find it.
<desrt> i mean... it's great to encourage users to use vorbis... but when you install your brand new dapper system and it can't even play an mp3 file it sort of leaves a sour taste
<desrt> if given the ability to include mp3 support on the main cd... it seems like something to do
<mjr> desrt, that, as they say, is too bad, and a legilative problem
<lotusleaf> ogg > mp3
<desrt> mjr; no.  it's really not.
<desrt> lotusleaf; i know.  users don't care.
<lotusleaf> desrt, therein lies the problem then
<desrt> lotusleaf; users don't want you to tell them what they want
<desrt> lotusleaf; they just want it to work
<wasabi_> Too bad.
<desrt> lotusleaf; _therein_ lies the problem
<dman13> so teach users to not expect it to work ...?  ;-)
<lotusleaf> desrt, users want many closed formats to work on many linux distros out of the box like wmv, the problem lies not with the FOSS distro but with the users over-reliant suckling on the virtual nipples of closed formats
<wasabi_> Who cares where the problem lies.
<mjr> the users can be told how to easily add the capability while subtly educating them about the choice :] 
* desrt sighs
<dman13> wasabi_: you can't fix it unless you know where to start making changes (ie where th eproblem lies)
<wasabi_> I think this conversation is quiet old and well traveled.
<dman13> IMO the problem is lack of cooperation -- or IOW the closed formats
<desrt> wasabi_; i think so too.
<mjr> wasabi_, probably
<desrt> wasabi_; and i thought that everyone agreed that it was best to make things as easy as possible for the user
<dman13> I'm happy enough that the additional formats are a trivial 'aptitude install' away
<Kamion> desrt: I looked through the Fluendo licence and it didn't help us; in fact it would impede the ability to distribute things we currently distribute in main if we included that plugin on the CD
<lotusleaf> desrt, right, by choosing a free OS rather than a bea$tly one
<Kamion> this may or may not be true if we bought a patent licence ourselves; I'm not sure
<desrt> Kamion; right.
<desrt> Kamion; we have many GPL gstreamer apps on the cd?
<Kamion> rhythmbox was mentioned as one, yes
<desrt> Kamion; i'm fairly sure it's getting relicensed soon
<wasabi_> desrt: it is, without doing stuff we can't do.
<Kamion> I wouldn't presume to comment there
<desrt> Kamion; appropriate :)
<wasabi_> The question then becomes a simple one. Can we distribute the gst mp3 stuff in main or not?
<Kamion> wasabi_: no, it's certainly not main-able
<wasabi_> Then we're done.
<wasabi_> Moving on!
<dman13> wasabi_: add 'AAC' to it if we want people to be able to put their CDs on their iPod
<Kamion> perhaps it *may* be restricted-able under some circumstances which are not in place at present
<wasabi_> I don't care.
<Kamion> but I'm not convinced
<dman13> ('it' being the list of stuff under consideration)
* desrt doesn't understand the distinction
<wasabi_> I mean, I care, but there are simple issues that won't disappear while talking about it on IRC.
<desrt> i mean... both go on the CD, right?
<Kamion> yes
<wasabi_> restricted isn't enabled by default though, right?
<Kamion> yes, it is
<wasabi_> Oh really.
<mdz> seb128: this is interesting; I have two copies of rhythmbox open (one local and one remote over ssh); one of them has the normal panel icon, while the other has the sunny icon from the weather applet
<Kamion> there may well be derivative distributions that disable that, of course
<wasabi_> Well, if somebody can do something to put it in restricted, then super. Somebody go talk to that person and get it done. ;)
<seb128> mdz: interesting :)
<desrt> this whole GPL thing is confusing and possibly annoying
<mjr> (incidentally, didn't the fluendo distributor agreement only cover desktop computers, which would complicate things somewhat even in restricted...)
<desrt> mjr; no.  i don't think that's right
<Kamion> mjr: the fluendo source is MIT-licensed; the distributor agreement only covers you if you're using their binaries, so I can imagine that it might not apply if somebody negotiated a different patent licence
<desrt> Fluendo hereby provides to the Distributor the Plug-in to be bundled within the software Distribution that Distributor makes available to the public from time to time (including new releases, updates, new versions, etc.) in any way (CD-ROM, DVD, internet download, etc.), as well as the Plug-in Source Code, subject to the terms of this Agreement.
<Kamion> however it's entirely possible (and wouldn't surprise me) that the terms of the fluendo distributor agreement derive directly from terms in the patent licence
<desrt> Kamion; no.  that's not right.
<desrt> Kamion; if you use their binaries you need not sign the agreement at all
<mdke> jdub, any luck with the ubuntu-customised yelp stylesheets?
<mjg59> desrt: You have no permission to redistribute their binaries without signing the agreement
<desrt> Kamion; you need to sign the agreement in order to gain the ability to compile binaries for yourself that are 'patent safe'
<Kamion> desrt: irrelevant; if you're *redistributing* the binaries (as we would be) you do
<Kamion> there's a distributor agreement on their web site
* desrt is reading it
<desrt> mjg59; ah.  right.  ok
<seb128> mdz: is that reproducable? do you need 2 copies running?
<mdz> seb128: http://people.ubuntu.com/~mdz/temp/rhythmbox-icon.png
<Nafallo> pitti: works fine. didn't build with the debian/rules edits, so I upload something very much like the first debdiff ;-).
<mdz> seb128: whoa, weird, the icons in the rhythmbox UI are the same
<mdz> seb128: reload the png
<Nafallo> lol
<mdz> seb128: it is the remote copy which is weird; that one is running on a breezy system while the local system is dapper
<psusi> pitti: hal question for you: it seems that hald runs with uid=hal, gid=hal, floppy, cdrom, plugdev... only I wrote a callout script and it seems to invoke it without the group memberships... is that intentional?
<pitti> psusi: no, sounds more like a bug
<seb128> mdz: you just ssh -X the other box and run it? is that reproducible?
<pitti> psusi: it probably forgets to call initgroups() somewhere
<mdz> seb128: I will try
<desrt> seb128; have you heard anything about the rhythmbox relicensing?
<mdz> seb128: it is behaving normally now
<psusi> pitti: good... then do you think I am going about this in the right way?  I'm making a hal fdi policy that invokes a callout for each detected cdrw drive which calls pktsetup to create a pktcdvd device associated with the drive, and store the path to it as a new property on the cdrw device
<seb128> mdz: weird one ...
<seb128> desrt: I've read quickly the mails on the rhythmbox list, why?
<desrt> oh.  that's something
<HiddenWolf> desrt, I'm not a rhythmbox developer, but I guess it's not going to happen too soon.
* desrt finds the list :)
<seb128> desrt: and doctau (rhythmbox maintainer) mailed ubuntu-devel today
<seb128> (James Livingston)
<desrt> has anyone heard from colin?
<Mithrandir> desrt: as in Kamion or as in somebody else?
<seb128> nop
<psusi> pitti: then another policy will act on media inserted into the drive by checking if it is formatted for packet mode, and if so, override the block.device, block.major, block.minor, and block.sysfs attributes to point to the pktcdvd device
<desrt> colin walters
<desrt> the person who has majority stake here
<Mithrandir> yeah, got that fairly soon
<psusi> pitti: hal needs these entries changed so it thinks the media is mounted when it looks in /proc/mounts, and it gets g-v-m and pmount to mount it read/write
<seb128> desrt: not on the list and not on IRC chan while I was connected/reading it ...
<HiddenWolf> desrt, rhythmbox really wants to stay gpl-compatible so they can use the epiphany plugin system and other cool things, afaik
<desrt> HiddenWolf; lgpl apps can link against gpl libraries
<pitti> psusi: sounds fine, if permission to access the device is all it needs? it doesn't need root for anything?
<pitti> psusi: (the pktsetup call in particular)
<Kamion> personally I'm not wild about the precedent of putting pressure on authors of GPL applications to un-GPL things
<psusi> pitti: I fixed a udev rule so that /dev/pktcdvd/control is owned by group cdrom like it should be... as long as the callout is in that group, it should work
<desrt> Kamion; ya.  it is kinda creepy, isn't it?
<Kamion> yes
<pitti> psusi: ok
<desrt> someone told me that some random kernel developer sued ubuntu for shipping fglrx linked against the GPL kernelk
<psusi> pitti: and I patched pktsetup so that it can auto assign a new virtual device rather than being told the name of one to create, and prints the dev number to stdout so the callout can grab it and store it in the hal cdrw device property list
<HiddenWolf> Kamion, I agree with that feeling
<mdke> hi, with kernel -11 my system stops at the "Detecting and Activating Hardware" stage. I can ctrl C out of it but nothing works. Is this known? Works fine with -9 kernel
<desrt> this whole situation underlines how badly broken the idea of software patents is :(
<desrt> can't ubuntu  just refuse to ship in the US? :)
<psusi> desrt: I think they didn't know what they were talking about
<HiddenWolf> desrt, it'd make nice press, but would be utterly unwise and unworkable
<desrt> and therein lies the problem
<psusi> AFAIK, there has not been a test case yet to test if modules are considered derived works, and thus, are bound by the gpl
<desrt> the people making the laws know the least about exactly what they're legislating
<psusi> aye
<psusi> pitti: so if I were to try and debug the missing groups tonight, what should i be looking for?  you mentioned initgroups?
<lotusleaf> desrt, you've inspired me to make a t-shirt that reads: ogg > mp3
<desrt> lotusleaf; good for you.  it will make absolutely no different
<desrt> lotusleaf; but be sure to feel good about yourself for wearing it
<psusi> lotusleaf: I'll take one ;)
<lotusleaf> desrt, that's the spirit! no wonder we have so few Gandhis
<pitti> psusi: yes, but hald itself already calls that, so I'm not sure where it's missing
<lotusleaf> psusi, sold! for one karma point
<lotusleaf> desrt, I'd rather do good than feel good
<mdke> desrt, lotusleaf, please take it elsewhere
<psusi> pitti: hrm...
<lotusleaf> :P
<desrt> mdke; ?
<lotusleaf> mdke, apologies, I haven't had my coffee yet this morning
<psusi> pitti: btw... on the linux terminal server project... gnome-volume-manager isn't run in each terminal session is it?
<pitti> psusi: not sure about the group preserving semantics of exec(2), but maybe hald calls setgroups() explicitly before executing a callout?
<pitti> psusi: no idea
<psusi> hrm... ok... I'll look around for setgroups calls then..
<jsgotangco> good night
<pitti> mdz: do you have some minutes? can we walk through the neglected *-updates uploads in the accepted queue and accept or remove them?
<elmo> woah, WTF
<elmo> Setting up libc6 (2.3.5-1ubuntu12) ...
<elmo> dpkg: relocation error: /lib/tls/i686/cmov/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
<LaserJock> so is base-config used anymore?
<mdke> its removed
<LaserJock> ok, I removed it to get locales upgraded but I didn't know if that was something I did or something that was planned ;-)
<mdke> mdz, just so that you're aware, the ubuntu-docs update that we discussed a while back was uploaded but is currently on standby because it needs some fixes to avoid clashing with edubuntu-artwork. infinity is handling it (it was while you were on holiday i believe)
<mdz> mdke: ok, thanks
<elmo> this has entirely destroyed this server
<elmo> is there like a bash builting for mv or rm?
<elmo> or some other way to get this rogue /lib/tls/i686 dir out of my path without a working C library
<Mithrandir> elmo: LD_ASSUME_KERNEL=2.4.1 mv /lib/tls /lib/tls.broken might work
<elmo> Mithrandir: oh, good call
<Keybuk> or LD_PRELOAD the libc that works
<Mithrandir> elmo: libc's optimization used to be borken on amd64, so I had to do that a fair bit.
<Mithrandir> it won't work for complex stuff such as perl, but shoudl work for just mv
<Mithrandir> should, even
<elmo> meh, except sudo is being paranoid about the environment
<elmo> WHINE
<Mithrandir> oh, you don't have a root shell?
<elmo> no, so I'm screwed
<Mithrandir> the /lib/ld-linux.so.2 hack probably doesn't work either, then.
<Seveas> elmo, do you *need* to move it? Can't you simply echo '' > /lib/tls...
<elmo> Seveas: I only have an unprivileged shell
<Mithrandir> Seveas: without a root shell?
<elmo> it's okay, I'll invoke the znarl bot
<Seveas> elmo, ah, I thought sudo was just not letting LD_ASSUME_KERNEL through
<Mithrandir> elmo: I guess you don't have ssh-with-root-privs into the box either?
<Mithrandir> if so, that could possibly work, unless bash croaks
<elmo> Mithrandir: ssh dies immediately
<elmo> anything that forks is screwed
<Seveas> ugh :/
<Mithrandir> yeah, Znarl bot time, then.
<Keybuk> does sudo kill sudo env LD_ASSUME_KERNEL=2.4.1 mv ... ?
<Keybuk> or double the LD_ASSUME?
<lamont> elmo: please sync bind9_9.3.2-1
<Diziet> You need to have installed `really' instead of sudo.
<lamont> er, when you have time that is...
<Keybuk> meh, no, bash has no env builtin
<Keybuk> elmo really needed a stashed, statically linked shell somewhere :)
<Nafallo> busybox-initramfs? :-)
<Mithrandir> sash has mv and stuff, but that doesn't help now, I guess.
<Keybuk> wonder whether those klibc utils would be useful?
<Keybuk> /usr/lib/initramfs-tools/bin/busybox rm ... ? :p
<Mithrandir> Keybuk: no mv, but there's dd in there..
<Diziet> So the problem is that sudo runs bash -c but bash -c fails, and you can't fix the LD_ASSUME_KERNEL, so nothing sudo execs will work.
<Diziet> So if sudo is the only thing which you can get root with it's doom.
<Diziet> Because sudo insists on calling exec and it insists on doing it without LD_ASSUME_KERNEL, so the exec will fail on any dynamically linked binary.
<Mithrandir> no, just anything linked to glibc
<Diziet> Oh, then all you need is a klibc utility which can either fix the problem or set an environment variable and run some program ...
<Mithrandir> so LD_ASSUME_KERNEL=2.4.1 sudo /usr/lib/klibc/bin/dd if=/dev/zero of=/lib/tls/libc.so.6 might work
<Mithrandir> since ld will then, hopefully, see that it's an invalid binary and skip it
<Diziet> Does LD_ASSUME_KERNEL work on set-id programs ?
<Mithrandir> I don't see why it shouldn't
<Keybuk> LD_ASSUME_KERNEL=2.4.1 sudo /usr/lib/initramfs-tools/bin/busybox rm /lib/tls/libc.so.6
<Keybuk> that should work, that busybox ain't linked to any libc
<Diziet> Ummm.  I suppose ld.so is using a whitelist rather than a blacklist.
<Diziet> Dinner.
* mvo goes to play hockey
<Keybuk> riiight
<Keybuk> that should be another 15s
<Keybuk> it is for me, anyhoo
<pitti> Keybuk: startup speedup?
<Keybuk> yeh
<pitti> yay
<HiddenWolf> Keybuk, way cool
<Keybuk> plus /dev/pts is actually mounted now
<Keybuk> always useful
<Keybuk> <g>
<Keybuk> (it actually was before for everyone except elmo)
<Keybuk> tomorrow I tackle alsa
<Keybuk> and then I make network again
<Nafallo> :-)
<Keybuk> there's a few cosmetic quirks during boot which I _think_ we just inherited from Debian, and not introduced by me
<Keybuk> I'll look into those too
<Keybuk>  * /dev/hda1
<Keybuk>  * on
<Keybuk>  * /boot
<Keybuk> etc.
<Keybuk> anyway, gone-time
<stockholm> mdz: i just tried to get ahold of you.
<mdz> stockholm: when someone speaks to me in any channel, it is highlighted and my client beeps
<stockholm> mdz: oh, i did not want to overprioritize this
<mantiena> could someone help me to catch the bug ? I'm compiling some gtk2 stuff and it seems bug is somewhere in ubuntu -dev packages - I get error /usr/include/gtk-2.0/gdk/gdkcolor.h:30:19: error: cairo.h: No such file or directory
<mantiena> but cairo.h is installed on my system
<sistpoty> infinity: around and have some time for fpc bootstrapping?
<allee> pitti: hal output of not recognized camera is in #22212 as requested.  I've a usb massstorage camera that misses the camera identifications too.  Add to 22212, create new or wait?
<mhz> elmo: ping
<elmo> mhz: ?
<mhz> elmo: any chances I can have mhz@ubuntu.com enabled?
<elmo> mhz: not unless it's urgent, not really, I'd rather spend the time fixing the script that got broken
<mhz> elmo: or you are not the one to talk about it?
<mhz> elmo: okis, I can wait then
<pitti> allee: that's a new bug
<allee> pitti: 'k
<csj> Mithrandir, hello, does the new casper conflict with usplash?
<allee> pitti: done #22216
<pitti> allee: thanks
<allee> pitti: np, I have to thx you!
<Mithrandir> csj: it needs a newer usplash if it's going to work.
<Mithrandir> csj: but since it mostly works fine without usplash, a Depends is not the right thing
<csj> Mithrandir, thanks , I've  packed and installed the new casper and chroot into extracted_fs installing something now
<csj> Mithrandir, I just installed xorg and gdm to test the livecd-base and see if it works, and you mentioned that I have to replace the extracted_cd/install/initrd.gz with initrd.img-2.6.15-11-386 ?
<Mithrandir> csj: correct.
<csj> and modify extracted_cd/isolinux/isolinux.cfg to use initrd.img-2.6.15-11-386 ?
<Mithrandir> no, just rename initrd.img-2* to initrd.gz
<Mithrandir> or change the config, either works, but the former is less work
<csj> thanks, I am going to try it 
<chninkel> elmo: it seems lesstif2 isn't in dapper universe anymore 
<chninkel> elmo: I was told you could remove it from the sync blacklist
<St-> hello folks ;)
<elmo> it's not on a blacklist, it's on a broken list
<chninkel> elmo: why ?
<elmo> dunno, orig.tar.gz clash, trying to overwrite packages in main, could be a bunch of things
<chninkel> elmo: this bug can be fixed or do we have to patch debian pakcage to use lesstif1 where possible ?
<chninkel> elmo: I compiled and installed lesstif2 on my ubuntu, didn't notice problem
<chninkel> elmo: (I mean from the debian source package)
<elmo> I've synced it, it's been unbroken in the meantime
<chninkel> elmo: ok thanks
<chninkel> elmo: it will shows up tomorrow ?
<elmo> chinkel: probably before then, but yeah
<chninkel> elmo: ok, thanks
<hunger> Would it be possible to add a "chmod 1777 /tmp" to the bootclean.sh init script?
<dholbach> elmo: regarding #19891, gutenprint can be synced from sid - ubuntu gimp-print changes can be overwritten - does anything else have to be done to make this change complete (apart from removing the gimp-print source from the archive after it built)?
<eruin> when gaim fails to work with msn and their devs blame it on the msn servers, there's always amsn to save the day, no matter how ugly it is! :)
<eruin> meh. wrong channel, sorry
<Kamion> dholbach: any chance you could resurrect the GraphicalPartitioningTool gparted patch for me?
<dholbach> Kamion: it won't apply any more
<Kamion> yes, I understood that from the changelog
<dholbach> Kamion: but let me try to dig it up
<Kamion> I can dig it out from the morgue myself - I was sort of hoping somebody might be able to update it for me :)
<Kamion> 'cos I only just realised it's been disabled - it's needed for ue-partitioning-tool
<dholbach> Kamion: http://home.versanet.de/~d-elstner/gparted-installer.diff
<dholbach> Kamion: danielk's problem was the naming of mountpoints and predicting the /dev/something<n> device they'd get assigned (you might remember the queue-like interface of gparted)
<Kamion> I don't really know gparted at all
<Kamion> I don't understand though, mountpoints don't get assigned /dev/* devices
<Kamion> you assign devices *to* mountpoints, but you don't need to predict that, it's something the user does
<dholbach> Kamion: ok, you can tell it things to change like "resize this partition to bla settings", "add this partition", ... and they get added to a queue which is worked on, if you hit "apply"
<dholbach> the UDU spec wanted to implement an interface for mount points as well
<Kamion> ah, the sane approach there is to associate mountpoints with internal concepts of partitions rather than with what the partitions currently happen to be on the disk
<dholbach> this is the part of the spec where danielk tried and failed
<Kamion> yes, mount points are a requirement - although if I have to I can kludge around that, Guadalinex already have code for said kludge
<hunger> Kamion: Can't you use labels for that?
<Kamion> hunger: that has other problems and is basically orthogonal anyway
<Kamion> please don't conflate issues on me :)
<hunger> Kamion: Both are readily available with the new udev;-)
<Kamion> it would be much nicer to avoid the Guadalinex kludge (a separate screen) though
<Kamion> hunger: whatever
* hunger shuts up.
<Kamion> please let me get through this issue without derailing me
<Kamion> the patch doesn't seem to fail to apply all that badly
<Kamion> four failed hunks out of lots
<Kamion> at least some of which are due to unnecessary whitespace patching
<Kamion> dholbach: ok, I have it applying perfectly for me now apart from offsets, I'll test it tomorrow and upload it if it works
<dholbach> Kamion: wow, cool.
<bryanf> why would I not have /dev/rtc on dapper?
<dholbach> good night guys
<crimsun> night daniel
<dholbach> night daniel
#ubuntu-devel 2006-01-15
<dholbach> elmo: can you please sync texinfo from sid? ok to override, we can talk about gutenprint tomorrow, i'm off to bed
<poningru> mako: left a post on your blog, not sure it got posted
<poningru> s/post/comment
<moret> hi all
<moret> please, help, I need reconfigure locales, but when I execute sudo dpkg-reconfigure locales happens nothing, I use Dapper
<Burgwork> moret, please use #ubuntu as this is not a support channel, even for dapper
<Riddell> what's the default DPI used by GDM?
<desrt> BenC; ping?
<desrt> Riddell; whatever your X server is configured to
<BenC> pong
<BenC> desrt: looking into the ieee1394 thing
<Riddell> hmm, I thought it was set to a fixed 100 dpi
<desrt> BenC; i was about to ask if you could send me the patch you had before
<desrt> BenC; so i can give it a test
<BenC> desrt: don't have a patch, but there's a git tree www.kernel.org/git/
<BenC> look for ieee1394
<desrt> awesome
<desrt> do i just do like 'git checkout'? :)
<desrt> k.  i'll let you know how it goes
<BenC> ok
<BenC> if you have an ubuntu git tree, you can just do a pull from the ieee1394 tree to get the changes
<desrt> i know 3 things about git:
<desrt> 1) it's a revision control system
<desrt> 2) the kernel guys use it a lot
<desrt> 3) it has a cute name
<desrt> this is all i know :)
<BenC> https://wiki.ubuntu.com/KernelGitGuide 
<desrt> ahah!
<BenC> use that to get the ubuntu git treee
<desrt> k thx.
<BenC> cd ubuntu-2.6
<BenC> git-pull rsync://rsync.kernel.org/pub/scm/linux/kernel/git/scjody/ieee1394.git master
<BenC> fakeroot debian/rules binary-debs flavours=686
<BenC> or whatever flavour you use
<BenC> .deb will end up in debian/build/
<desrt> could i just use the git-patched sources of ieee1394 against linux-headers to cook myself a fresh set of firewire modules?
<LaserJock> does anybody know how http://people.ubuntu.com/~scott/patches/ are generated?
<BenC> desrt: possibly
<desrt> BenC; do you ever get a problem where after you do the download you have nothing except ubuntu-2.6/.git/
<desrt> ie: nothing in the ubuntu-2.6 dir except for .git
<BenC> desrt: cd ubuntu-2.6; git-checkout
<desrt> excellent.
<desrt> odd system
<jdub> BenC: you heard of machines not being able to install without DMA enabled?
<zul> BenC: uh...did you do a pull from my tree?
<desrt> BenC; your tree contains conflicts with his :)
* desrt tries to figure this out as a way of learning about git
<infinity> Has anyone been looking for me for the last two hours?  My new ISP decided to muck with my line with no warning.
<mjg59> infinity: Nope
<Lathiat> infinity: dont you love that :)
<infinity> For some value of "love" that I haven't previously discovered...
<Lathiat> i had an upstreaam provider unplug the wrong cable on me yesterday
<Lathiat> fortuantely fibre was only out for 15 minutes
<Lathiat> apparently labelled two ports the same, idiots
<desrt> oi vey
<jdub> mdz: xchat-gnome!
<desrt> BenC; some bad news.  i did what i believe to be a correct merge of the latest ieee1394 code with ubuntu's git tree and loaded up the firewire modules.  no love.
<desrt> BenC; i guess(?) the problem is in some other part of the tree that the ieee1394 maintainer has patched.  conflicts in the scsi layer are a lot more difficult to resolve, though :/
<mdz> jdub: it's looking good
<mdz> jdub: once I fixed the keyboard shortcuts, that is
<mdz> infinity: I'm getting spurious "Cannot update" messages from update-initramfs; have you seen this?
<mdz> there's no file in /var/lib/initramfs-tools for my 2.6.15-11-k7
<infinity> No, it's completely silent for me.  A bug report would be nice.  A trace of what it's trying to do would be nicer.
<infinity> Oh.  That's special.  Did /var/lib/initramfs-tools get cleaned on your machine at some point?
<infinity> kernel-packages (and hence the linux kernels) have been "correctly" creating initramfs (and populating that directory) for ages...
<BenC> desrt: there's scsi merges in the ieee1394 git?
<desrt> BenC; yup
<BenC> that's not the code I got then
<infinity> mdz: I've not (yet) had anyone else report this to me, so I'd suspect it was a local issue that led to you not having the right file there...
<desrt> BenC; there are serial-ata changes even.  very odd.
<BenC> they must be tracking the scsi git
<mdz> infinity: I've done nothing with it but normal upgrades through linux-meta, and this has happened twice since 2.6.15
<desrt> BenC; is there a way i can checkout the source as it was at -8 release and then the source at -9 and diff them?
<BenC> try the for-linus branch
<BenC> desrt: hold a sec
<infinity> mdz: Great.  Then either you really are alone, or no one else is bothering to report bugs about this and I've just been lucky enough to not have it happen here.
<desrt> k.  i'm just reviewing a patch right now.  i'll be a minute anyway :)
<mdz> infinity: perhaps it's related to the fact that packages other than the kernel are invoking it now
<infinity> mdz: I assume purging the kernel and reinstalling it magically makes it come back.
<mdz> not sure; haven't tried that
<mdz> I will try a reconfigure first
<infinity> mdz: Packages other than the kernel invoking it is the whole reason why that file is there (and why initramfs-tools needs to "own" the image)
<BenC> desrt: try git-diff-tree -p 2.6.15-8.10 2.6.15-9.11 > foo.diff
<BenC> that will diff the entire tree, but you should be able to pull the ieee1394 stuff out of that
<mdz> infinity: hmm? why should it care who is invoking it?  I thought the file was there to support local modifications to initramfs
<infinity> BenC: Have you seen or heard of this yet?  (kernels getting installed with an initramfs that doesn't appear to be "owned" by initramfs-tools correctly)?
<mdz> infinity: (which I don't find to be a valid use case, by the way)
<mdz> anyone hand-hacking their initramfs can also point grub to a different pathname
<infinity> mdz: Well, the file is there to make sure the one we're updating is our own, but yes, same thing.
<desrt> BenC; running
<mdz> I think it would be perfectly reasonable to disable this complexity entirely and just do it
<infinity> mdz: We could remove that sanity check entirely and your problem would go away, but I'm not sure how many people would cry about such a change.
<desrt> my what a big diff you have
<mdz> infinity: I would be amazed if anyone cried
<mdz> it's not documented as far as I know
<infinity> mdz: I imagine most of the crying would be in Debian, not Ubuntu.  So I'd be happy to make the change in our tree.
<infinity> Our users aren't that low-level, most of the time.
<mdz> infinity: aha, found the problem
<mdz> an old kernel-img.conf with ramdisk = /usr/sbin/mkinitramfs
<mdz> from before we switched over the official kernels
<mdz> so it gets generated correctly the first time and never thereafter
<infinity> Ahh.
<infinity> That would be a problem only you, jbailey, and ogra would have.
<infinity> I can't think of too many people who played with that setting manually before we switched kernel-package.
<mdz> still, I don't think it's necessary to treat initramfses as conffiles
<infinity> In that case, I'm inclined to say the feature is working as expected.  Custom ramdisk= stuff shouldn't be overwritten willy-nilly.
<infinity> (Though, I suppose custom stuff really should use a different filename, if people don't want it touched)
* infinity waffles.
<mdz> anyone who tested the early thin client stuff would also have this problem within the client chroot
<infinity> Alright, I'll disable the check for now, and let update-initramfs overwrite mkinitramfs stuff.
<mdz> thanks; I'm not worried about the kernel-img.conf thing really, but I think that overall it's more reasonable to have update-initramfs always generate a new image
<infinity> In the world of "user-friendly" versus "what I think is technically correct", the former probably wins here.
<infinity> I'll put a blinking comment in there, though, so Max doesn't blindly sync the change to Debian.  I can imagine most Debianers would be on my side on this one (users be damned, the feature is right!)
<mdz> mkinitrd never behaved this way
<infinity> We never regenerated initrds with mkinitrd either.
<infinity> Only by hand.
<mdz> eh?  they were regenerated during kernel upgrades
<infinity> I think it's the automation here that scares people.
<infinity> Oh, I suppose they were, at that.
<infinity> Kay.  Fixing.
<infinity> Unfortunately, we use that state dir to get the version list too, but I can hack around that.
<infinity> Or only allow arbitrary overwrites for the running kernel.
<infinity> Or, I can compromise.  Instead of refusing to act, I'll just print a warning and plow through.
* infinity edits.
<infinity> I'll just treat it as an implicit -t(akeover)
<mdz> sounds good
<desrt> BenC; success is mine
<desrt> BenC; i have a patch that applies to the current git tree and fixes the bug
<desrt> BenC; probably does a lot of other stuff too though (32kline patch) so i'm gonna try and isolate a bit more
<BenC> desrt: excellent
<desrt> BenC; down to 5klines now.  i messed up and had a lot of non-firewire stuff in there :p
<mako> poningru: hm.. what happened with your post?
<mako> poningru: several people have commented today so i don't think there's anything systemic wrong.. but i'd like to know if my blog is keeping people from posting
<BenC> desrt: you should use git-bisect, save you some time
<BenC> desrt: you could use 2.6.15-8.10 and 2.6.15-9.11 as start/end points and go from there
<desrt> BenC; fabbione tried to sell me on that the other day :)
<desrt> k.  i can unscrew my copy of the tree by rm -rf * and git-checkout -f, right?
<desrt> ie: take it back to what the .git files say
<BenC> or just git-checkout -f
<BenC> git-status to make sure nothing lingers
<desrt> i have to admit this whole concept confuses me.  how can i bisect you nuking an entire patchset in the ubuntu git?
<BenC> desrt: hmm...maybe best if you found where I merged the ieee1394 tree, and bisect around that so you can catch the commit that fixed it
<desrt> BenC; when you resynched to mainline you added support for a couple of new drivers, it seems
<BenC> desrt: obsolete drivers that can be ignored
<BenC> cmp and amdtp are old and broken
<desrt> BenC; then let's just sync back up to the development branch?
<desrt> BenC; my only concern was that this patch killed those drivers... but if that's a good thing anyway....
<BenC> there was a reason I reverted back to stock code
<BenC> I can't remember why though
<desrt> it was me :)
<desrt> and it turned out to be a bogus reason :)
<desrt> my cdrom drive wasn't working in its enclosure... the revert didn't help issues
<desrt> but a new cdrom drive did
* infinity claps.
<BenC> ah, then I'll pull it back
* desrt drops the patch on bugzilla
<desrt> ok.  it's there
<desrt> thanks for the info about git :)
<BenC> no problem
<poningru> mako: sorry to bother you dude, it was my problem, I didnt allow the cookie to be placed on my browser
<poningru> mako: I posted it again and this time it worked
<poningru> thanks for your concern, its good to know you care
<daniels> poningru: he's only pretending to care
<daniels> really he has a cold black heart
<floam> no need to get into race
<poningru> rofl
<daniels> just as a heads up, nvidia and fglrx will possibly be broken indefinitely from later today onwards; put xserver-xorg-core 1:1.0.1-0ubuntu1 on hold if this doesn't sound like a winning idea.  hth k thx bye.
<psusi> lol
<LaserJock> daniels: what does indefinitely mean? Like for a few weeks or forever or you really don't know?
<daniels> LaserJock: until they rebuild against a newer xorg-server, which may be never
<LaserJock> hmmm, bummer
<psusi> hernel hacking question... this pktcdvd driver requires CAP_SYS_ADMIN to set up and tear down devices... this apparently is because it takes the device nr as a parameter so no other security checks are performed
<psusi> would it be a good idea to modify that to instead take an fd in the ioctl, and accept it from non root users if they have write access?
<infinity> daniels: Joy!
<daniels> hooray for unavoidable ABI breakage
<infinity> "unavoidable"?
<infinity> Would it not be best (for dapper, at any rate) to keep our X packages vaguely in line with what the upstream 6.9/7.0 release called release versions, since that's what 3rd party folk will most likely build against?
<psusi> surely you can get that square peg into that round hole if you apply enough elbow grease? ;)
<daniels> infinity: hopefully we can convince nvidia/ati to build against the xorg-server 1.1.0 that I'm sure will be released sometime before dapper
<daniels> ironically, half the reason for the breakage is for Xglx, which is generally used on proprietary drivers
<infinity> That is rather wicked irony, yes.
<daniels> well, Xgl in general, but no-one uses Xegl, aside from airlied
<psusi> suid executables are a no-no aren't they?
<daniels> psusi: in general, yes
<infinity> psusi: In general, yes.  If they absolutely can't be avoided, then...
<psusi> well, I've got two choices here... make pktsetup suid so hald can call it... or patch the kernel so it doesn't require CAP_SYS_ADMIN for the ioctl
<infinity> What is pktsetup?
<psusi> making pktsetup suid and not world executable, and owned by the cdrom group would be easiest
<infinity> And why does non-root need to run it?
<psusi> infinity, a program in the udftools package that controls the kernel pktcdvd driver to associate virtual read/write devices with cdrom devices
<mjg59> psusi: Or we can sort out the hal root callout stuff
<psusi> non root needs to run it because hal runs as non root
<psusi> mjg59, well, it's sorted.... hal doesn't run as root ;)
<mjg59> psusi: No, but hal needs to execute stuff as root
<mjg59> That's a requirement before dapper
<psusi> hrm.... another possibility is to add rules for the hal account to be able to sudo specific commands
<mjg59> Ngh.
<mjg59> While that work work, it's also less than ideal
<psusi> how come?
<mjg59> sudoers is a conffile
<psusi> so?
<mjg59> We can't rewrite it
<psusi> why not?
<mjg59> Because it's a conffile
<mjg59> Policy forbids it
<psusi> ok... patch sudo so it uses rules from a non conf file we can write to ;)
<infinity> That doesn't make it any less sick.
<psusi> why is it so sick?
<psusi> you need a suid root program to gate the privs hal needs... that's what sudo does
<mjg59> Or we could do what upstream want to do, which is to add a separate daemon running as root that listens for requests from hal over dbus
<psusi> why is that any better?
<mjg59> Because it's the way upstream want to do it
<psusi> it certainly is more complicated... so what advantages does it have?
<psusi> well if upstream smokes crack, do you? ;)
<mjg59> I don't find it any less offensive than any other solution, and it avoids the wheel being reinvented
<mjg59> Uh, more offensive
<psusi> writing a new daemon from scratch using dbus and who knows what is complex... complex = high probability of bugs... bugs = possible root exploit
<mjg59> It's not complex
<psusi> isn't dbus somewhat complex?
<mjg59> There's already dbus-using stuff running as root
<mjg59> That's somewhat unavoidable
<psusi> well, if you can't avoid it you can't avoid it... but if you can, it's a good idea to keep it simple
<mjg59> So what we actually end up with is a 20 line app plus some generic dbus code
<psusi> and sudo is prety darn simple
<psusi> it also can probably be implemented before upstream gets around to writing this new daemon ;)
<psusi> i.e. in time for dapper
<mjg59> No, the idea is that either me or pitti write it for upstream
<mjg59> That way it gets done :)
<mjg59> If all else fails, yeah, we go with some other hacky solution
<psusi> hehe.... 
<psusi> if you really don't want to use sudo, you could just write another gatekeeper program that would be suid and execute only to hal
<infinity> That's what the daemon would be (though not suid)
<infinity> Is it just the "pass messages over big, scary, dbus" part you have a problem with?
<infinity> Cause that's unavoidable at this stage.  Every second system management tool written for GNOME (hi, NetworkManager!) is using that daemon<->dbus<->frontend approach.
<psusi> infinity, it's more complex to send messages via dbus ( can't that be inter machine? ) to have things run as root, rather than executing a suid wrapper directly
<daniels> (which is actually a good approach)
<psusi> and all else being equal, less complexity is good
<daniels> yes, but less suid is good also
<lifeless> psusi: but its not all equal
<infinity> Overall complexity goes down as more people use the same approach and dbus gets more and more audited.
<lifeless> psusi: perhaps get it to be all equal, then you can argue the dbus component
<psusi> it's still more complex than just executing the thing you need directly
<infinity> Whereas hacking sudo to do weird things would be Ubuntu-specific, with no real external auditing.
<psusi> true... but a simple suid wrapper program would be easily audited as it would only require like 10 lines of code
<psusi> with no complex deps
<daniels> yes, but then when upstream goes and does the dbus thing anyway, you'll have to throw that way and deal with the dbus stuff regardless
<daniels> so what's the point?
<psusi> lol... I did a nohup nice 7z over an hour ago to recompress this full system backup for the fun of it... .tar.gz was 796M, .tar.7z is 546M.... wow!
<psusi> daniels, well, you won't have to if upstream sees the light and just uses your simpler method
<lifeless> psusi: so go talk to upstream
<daniels> psusi: odds are stunningly low
<psusi> they are really hell  bent on dbus eh?
<daniels> this sort of privsep is one of the things dbus was designed for
<infinity> (reinventing the privelege separation wheel every time you write something is not as "simple" as people make it out to be)
<infinity> dbus getting you this sort of stuff for free, even if it is "complex" is a good thing.
<psusi> true....
<psusi> well.... I guess I'll leave it to pitti and mjg59... and in the mean time I'll just make pktsetup suid as a work around
<psusi> what permissions are required to do hal-set-property?
<freestone> Mithrandir: Are you there?
<Mithrandir> freestone: now I am
<fabbione> morning guys
<ajmitch> morning fabbione 
<freestone> Mithrandir: Hi - I was on as 'den' last friday when you got me the iso for the firewire fix.  I got your emails.  Thanks for making a new iso.  I'm wondering if you can make a small iso - like you or someone (infinity?) was saying was for just a base system.l  Maybe 10-50MB. Would that be possible?
<freestone> Mithrandir: I probably have to log off for a short while - I'll try to come back in about 10 min, If I don't, it would be great if you would email me your answer. Thanks!
<Mithrandir> freestone: yes, I can do that.  Note that it won't work as a live system, just as a test to see if the full CD will work.
<psusi> hrm... that's interesting... looks like the hal has a race condition with its callouts... it isn't initialized enough yet to accept incoming connections from things like hal-set-property when it spawns the callout... have the callout sleep for a few seconds, and life is good
<Mithrandir> freestone: I'll have it ready in a few hours, it's still very early morning for me here and I don't have the setup to make CDs at home.
<freestone> Great
<Mithrandir> freestone: I'll drop you a mail when it's ready.
<Mithrandir> (unless you're around on IRC then)
<freestone> You can get me the small one?
<Mithrandir> yes
<freestone> Thanks - I'm about to get off irc, & won't be on the net till 12+ hrs from now, more likely about 20+.
<Mithrandir> ok, that's fine.
<Mithrandir> I might or might not be around then.
<freestone> Mithrandir: someone pointed me to read the ubuntu wike re: who are the kernel maintainer for ubuntu.  I read the logs of the past 2 developers meetings.  It was informative. So, I know that much.  Question: who maintains the  kernel for ubuntu?  & are they volunteers or paid?
<Mithrandir> freestone: Ben Collins does most of the kernel work.  He's a paid employee.
<freestone> Mithrandir: One reason I ask is cause there seems like there might be some bug with the "external disk drive" code, which causes a disk to get disconnected even during a file copy. & I'm wondering if someone on here would be the oerson responsible for that type of code.
<Mithrandir> (I don't understand why "who is paid and who isn't" is interesting, but there's nothing secret there, so.. )
<freestone> Oh  - It was ben who told me to try the latest kernel, when I submitted my bug.
<mjg59> Whoops
<Mithrandir> freestone: BenC has also worked on ieee1394 a fair bit upstream, so he should be in a good position to help you debug.
<freestone> Mithrandir: just curioous. 
<freestone> Mithrandir: I've been a debian user, where, i've assuned, all were volunteers.,
<freestone> Mithrandir: other than using red hat many years ago, I haven't interacted with (knowingly) paid linux developers online before.
<freestone> Is BenC the person who was the DPL?
<Mithrandir> freestone: people are paid to work on Debian too, they're just not paid by Debian.
<Mithrandir> yes, BenC has been DPL
<freestone> The _same_ benc?
<Mithrandir> yes
<psusi> freeflying|away, what do you mean it causes it to get disconnected?  the only way the drive gets disconnected is if you unplug it
<psusi> freestone, even
<freestone> psusi: I do a cp file1 file2 on the exsternal hd, a 10GB file, and 80% of the time the copy fials cause the external disk becomes unseen by linux
<freestone> psusi: Ask me if you want to read the bug report 0 It will take me a few minutes to look up the #
<psusi> freestone, it thinks you unplugged it but didn't?
<psusi> but YOU didn't even
<freestone> No, I didn't unplug it - I just told it to copy a 10GB file, & it keeps failing
<psusi> weird... and you didn't ask for it to be unmounted or anything either right?
<psusi> that's a strange problem alright
<zakame> hi devs
<freestone> I only gave a cp command, it starts copying, and then 80% of the time it fails
<freestone> psusi: external hard disk disconnects (firewire ieee1394 over SCSI) during file copy 'Read-only file system' 'Device offlined'
<freestone> psusi: Bug 21565
<psusi> freestone, the drive didn't happen to power itself down did it? ;)
<freestone> This happens with 2 different hdds, from two different companies. I don't think it powerd down.  IIRC, the drive light stayed on on both drives.
<jdub> mdz: i haven't even tried it yet; hrm, well, for a long time.
<fabbione> hmm /29 is an 8 ip network, right?
* fabbione can't calculate that on the fly anymore
<mjg59> fabbione: Yeah
<fabbione> mjg59: danke
* jsgotangco wonders if our daily image is now working nicely
<dholbach> good morning
<dholbach> infinity, lamont: could one of you please give back devhelp and blender?
<infinity> dholbach: No.
<infinity> :)
<dholbach> infinity: Are the buildds on vacation or something? :)
<Keybuk> infinity: I've finished playing with sysvinit for now ;)  so you can upload freely
<infinity> dholbach: No, I'm just being a jerk.  (given back, BTW)
<dholbach> infinity: thanks a lot. :-)
* Keybuk tries to figure out what S.S01glibc.sh actually does
<Keybuk> as far as I can tell, it's entire purpose is to print a message under usplash which nobody will ever see
<Nafallo> will we have xserver-xorg-driver-synaptics on amd64 before dapper releases? ;-)
<Keybuk> hmm, must get around to filing that bug about my synaptics ... pad drags don't work anymore
<Nafallo> s/driver/input/
<mdke> infinity, *here begins the bugging about the {k,ed}ubuntu-docs update in breezy*
<infinity> mdke: Yay, thanks for the annoyance.
<mdke> infinity, any time
<mdke> Kamion, awake?
<fabbione> soooo ok
<fabbione> who decided to stick xchat-gnome in main and replace xchat?
<infinity> fabbione: mdz?
<dholbach> fabbione: yes and it doesn't 'replace' xchat :)
<fabbione> dholbach: they conflicts
<fabbione> and xchat is kicked out
<fabbione> xchat-gnome UI sucks
<fabbione> it's completely different and inconsistent with xchat
<fabbione> without considering extremely incomplete
<fabbione> this was a really unwise choise
<infinity> Time to switch to irssi...
<fabbione> time to go back to BitchX
<jdub> oh, reminds me, i should try it
* jdub uses irssi.
* infinity just switched from BitchX to irssi, like, last week.
<desrt> infinity; late bloomer
* Nafallo agrees with fabbione
<Nafallo> atleast make it xchat-gnome | xchat so I won't have to throw ubuntu-desktop away?
<Keybuk> uh, why do these packages conflict?!
<Keybuk> they're both installable at the same time
<Keybuk> oh, even better
<Keybuk> it's just xchat that conflicts xchat-gnome
* Keybuk gets the clue-by-four out
* desrt waits for the sparks to start flying
* fabbione goes back fixing grub-installer
<Keybuk> looks like an old Debian hang-over from an old xchat-gnome
<Keybuk> right, that can go bye-bye then :p
<Keybuk> fabbione: right, as soon as infinity's babies do their work, you can have xchat again <g>
<Mez> morning Keybuk - apologies for using you in an example :D
<whiprush> howdy Keybuk 
<Burgundavia> jdub, any thoughts on the FC5/mono thing?
<dholbach> hellas whiprush
<whiprush> hi daniel
<whiprush> dholbach: I owe you 2 MOTU fridge things
* dholbach hugs whiprush
<dholbach> take your time :)
<Keybuk> Mez: which example?
<dholbach> Keybuk: "Everybody was dancing naked on the table, Keybuk for example." ;-)
<fabbione> Keybuk: thanks :)
<Mez> Keybuk: http://forums.lugradio.org/viewtopic.php?p=18333#18333
<Mez> lol - dholbach that would probably work to
<Keybuk> dholbach: no, that was you dreaming ;)
<dholbach> haha :)
<Keybuk> Mez: no worries, examplify me away
<csj> Mithrandir, hello, thank your new liveCD-base, I have tried and  start X server corectly, but when user ubuntu  try to auto login in gdm, occur message "user not known to the underlying authentication module"
<csj> does something about sudo or passwd stuff?
<Mithrandir> csj: did you pull from bzr?
<csj> Mithrandir, no, I dl the livecd-base 1hr before from http://cdimage.ubuntu.com/livecd-base/current/
<csj> and I see that casper is 1.25
<csj> the same with that in bzr dir?
<Mithrandir> csj: hmm, it ought to work, then, yes.
<csj> Mithrandir, could I ask a stupid question, if I type "ubuntu" in gdm user name, then what is the password? just push enter?
<Mithrandir> csj: there's no password, it's disabled.
<Mithrandir> csj: does it at any point say "shadow passwords enabled"?
<csj> Mithrandir, I am not sure, I am going to add some more package (locales, laptop-detect) and try to see more messages then
<Mithrandir> csj: make sure user-setup is in the live image
<csj> if I passwd in console firstly and then login gdm in normal way, will it work?
<Mithrandir> csj: you won't get a shell in the console either, I'd imagine?
<csj> no getty? Mithrandir, what do you mean "user-setup is in the live image" ?
<Mithrandir> is the package "user-setup" installed?
<Mithrandir> if you're basing your code off an old live fs, it won't be.
<csj> Mithrandir, oh, I found I didn't install user-setup, I installed it now, and try again :)
<Mithrandir> csj: it should work, then.
<Keybuk> infinity: btw, after you changed to /dev/.initramfs, did you make sure the initramfs was updated? :)
<fabbione> dholbach:  did you notice that almost all the last gnome-* uploads are FTBFS in the attempt of linking against libdbus?
<sivang> MOrning all
<dholbach> fabbione: some of them, yes - i'll talk to seb about it as soon as he appears, i personally suspect some broken gnomevfs/avahi/dbus pkg-config require.private thingie
<fabbione> ok
<dholbach> fabbione: thanks for telling me.
<fabbione> np
<fabbione> Riddell: ping?
<zakame> hi all
<\sh> but it's not a qt problem at all...the patch works
<\sh> (without the quiet patch)
<\sh> i think we have to recompile katapult..
<Mez> \sh - it doesnt work for me aftera recompile either
<\sh> yeah see it...
<Mez> the katapult icon ?
<seb128> carlos: around?
<csj> Mithrandir, I have install 'user-setup' but still got the same message "user not known to the underlying authentication module", I am now add new user 'csj' and later then login as csj to try
<Mithrandir> csj: uhm, you get a shell on tty1?
<csj> Mithrandir, no, I remaster the filesystem.cloop now
<csj> Mithrandir, should shadowconfig on or off by default?
<Mithrandir> csj: please do, since this should work (and worked with casper from bzr about five minutes ago for me)
<Mithrandir> csj: that's done through user-setup
<csj> Mithrandir, oh, should I replace initrd.gz or vmlinuz like yesterday?
<csj> cause I failed use 2.6.15-11 yesterday by replacing initrd.gz and vmlinuz
<Mithrandir> csj: you need to replace initrd.gz each time you do something with casper
<csj> ok. I try replace it again
<zakame> hm can cdbs deal with multiple tarballs?
<Mithrandir> csj: you need an initrd.gz which is less than 24 hours old, since that's when I fixed casper. :-))
<csj> Mithrandir, where to get it? extracted it from daily-live-i386.iso?
<csj> I mean which in the daily-live dir
<Mithrandir> csj: that, or just install dapper in the live image you have and then pull out /boot/initrd*
<csj> Mithrandir, should I copy out vmlinuz,too ?
<Mithrandir> csj: that should be the same version as is on the live cd already, but it won't do any harm.
<csj> Mithrandir, ok ,thanks, I go to try
<sladen> Keybuk: amusing.  glibc.sh seems to (potentially) call 'dpkg' quite alot, which would likely not work in the situations it's trying to warn about...
<Keybuk> sladen: hmm?
<Keybuk> I made glibc.sh go away
<lifeless> wave that wand
<infinity> Keybuk: Erm, yes?  The initramfs is updated on every upgrade of initramfs-tools or usplash.  Unless you created it manually with mkinitrd (which I'm "fixing" in the next initramfs upload)
<Keybuk> hmm, because it looks like that didn't happen to me <g>
<sladen> Keybuk: good
* StevenK glares at his fileserver.
* StevenK hugs backuppc. Yay it for having a program to get files from it's special format back to normal.
* \sh grrrs towards qt and immodule crap
<\sh> KeyRelease event is not working correctly after applying this immodule patch...now lets see what the patch for the patch is doing
* Nafallo grouphugs with StevenK and backuppc.
<\sh> Nafallo: has someone replied to this strange problem with gajim and dbus?
<Nafallo> \sh: yepp, there is a patch now :-)
* Nafallo still have the workaround :-)
<Nafallo> http://trac.gajim.org/ticket/1347
<\sh> cool...I'll make a new package :)
<Nafallo> yay! :-)
<Nafallo> oh, did you ever publish your bzr-archives btw? :-)
<\sh> I'm doing it right after I fixed this libnotify thingy..
<\sh> url will be revu.tauware.de/~shermann/packages/gajim
<\sh> there will be several branches 
<Nafallo> kewl :-)
<carlos> seb128, hi
<nikol> hi
<seb128> hey carlos
<seb128> Hi nikol
<nikol> i install apps etc and i can't find the executable
<nikol> where i can find to run the app?
<seb128> carlos: is .pot upload broken on rosetta atm? xchat-gnome upstream asked because it doesn't work fomr him for a week (OOPS page)
<seb128> nikol: please use #ubuntu for user questions etc
<carlos> seb128, yes, it's broken but also fixed I hope the fix will be applied today to production
<seb128> carlos: thanks
<carlos> seb128, btw, the suggestions are not showing fuzzy messages anymore
<carlos> well, when the patch is applied on production.
<carlos> I hope it will happen today.
<seb128> cool
<\sh> yahoo...the patch works...qt is fixed :)
<crimsun> \sh: does it need to be applied to qt4-x11, too?
<fabbione> seb128, dholbach: ping?
<\sh> crimsun: I have to check
<seb128> fabbione: pong
<\sh> crimsun: actually can you test something like katapult with qt4?
<\sh> or wait...
<fabbione> seb128, dholbach: would it be possible to patch gaim so that it doesn't start more than once? It's really annoying if you start it twice by mistake that it restarts all the connections
<crimsun> \sh: ok, because I've merged 4.1.0-1ubuntu1 (it just finished building)
<\sh> crimsun: if you want to have a look: http://lists.freedesktop.org/archives/immodule-qt/2005-June/000732.html
<crimsun> ok
<\sh> crimsun: there is a test app as well...you can try to test the qt4 stuff with this test application if the KeyRelease event works with applied immodule patch
<\sh> crimsun: if not, you have to apply the patch from this guy
<seb128> fabbione: seems a reasonable request, could you open a bug about that? :)
<fabbione> seb128: sure
<seb128> thanks
<ulaas> new usplash is nothing but black. is that ok? should i file ?
<infinity> ulaas: ls -l /usr/lib/usplash/usplash-artwork.so
<ulaas> /usr/lib/usplash/usplash-artwork.so -> /etc/alternatives/usplash-artwork.so
<infinity> update-alternatives --display usplash-artwork.so
<ulaas> usplash-artwork.so - status is auto.
<ulaas>  link currently points to /usr/lib/usplash/usplash-default.so
<ulaas> /usr/lib/usplash/usplash-default.so - priority 10
<ulaas> Current `best' version is /usr/lib/usplash/usplash-default.so.
<infinity> Kay, that's fine then.
<infinity> When did it start going "all black" for you?
<ulaas> infinity, yesterday there was new usplah and initscripts update. today i made a reboot. i noticed.
<ulaas> infinity, want me to reboot one more time just to be sure?
<Mithrandir> hmm, can block devices have labels, not just file systems?
<infinity> ulaas: Can you run "update-initramfs -u", tell me if there's no output (if not, good), then reboot again?
<ulaas> infinity, i did. no output. now rebooting. will get back to you soon
<ulaas> infinity, now worked. do you want me to report further issues with usplash to you?
<infinity> ulaas: Filing bugs works for me, but I end up having to care about them. :)
<ulaas> infinity, ok then first i will try to mention to you. if not available i can file a bug.
<crimsun> elmo: please sync pstoedit, soap-lite, octave2.1, anjuta, balsa, openbox, wmfire, and rxvt-unicode from Sid, overriding Ubuntu changes. Thanks!
<dholbach> elmo: could you please sync texinfo (dropping changes is ok), and could we talk about gutenprint? I'm not quite sure, what else is to be done apart from asking for the sync (which seems ok to me) and removing the old gimpprint source from the archive.
<raphink> elmo: it seems the superkaramba source package (which is marked as to be merged) should be nuked since superkaramba is now provided by the kdeutils package
<blue-frog> hi guys. want to fill in things I find that goes wrong with dapper but am not sure about where and how i should proceed. For example if i find out that video i810 is slower than in breezy, it's not what we can call a bug or is it?
<ogra_ibook> how do you define "slower" ?
<lifeless> 'less fast'
<ogra_ibook> haha
<lifeless> boom-tish
<blue-frog> 400K against 1000k with glxgears
<Treenaks> blue-frog: you said the magic word
<ogra_ibook> blue-frog, how did you get the frame output from glxgears ? 
<blue-frog> glxgears -printfps
<blue-frog> in breezy and in dapper
<Mithrandir> blue-frog: glxgears is not a benchmark.  It's a sample application.
<ulaas> blue-frog, i am sure you have checked you had dri enable right?
<ogra_ibook> oh, has daniels changed it back again ? 
<ogra_ibook> former you needed also -iacknowledgethatthisprogramisnobenchmarkofanykind or something like this ...
<blue-frog> ok let's forget video then.. about sonypi failing on a vaio, is that conisedered a bug?
<ogra_ibook> i wonder why he took it out again
<Mithrandir> blue-frog: quite possibly, feel free to file a bug in bugzilla
<blue-frog> it's just am not sure what a bug is, i don't want to start filling plenty of bugs if they are not considered as bugs. don't want to waste your time and mine
<raphink> blue-frog: a bug is a small animal, like an insect. If you like collecting them, you can get a net and get some around, then file them in a book.
<blue-frog> interesting
<raphink> ;)
<Mithrandir> blue-frog: a bug is a when a program doesn't behave as it should.  An example here is sonypi not working on your vaio
<blue-frog> k ty
<raphink> or my keyboard not wanting to print ^ accents the right way :@
<raphink> this is a bug, too
<blue-frog> right now am in https://launchpad.net/distros/ubuntu/dapper/+bugs-all, right place to fill in bugs, correct?
<raphink> yes blue-frog if you're using dapper
<blue-frog> not using testing...
<raphink> ?
<jbailey> seb128: This x-chat gnome is strange to get used to. =)
<ogra_ibook> jbailey, fully agreed
<raphink> weird things on my system today
<seb128> jbailey: any particular issue with it? 
<seb128> jbailey: I used it for some months and I've no issue, but I'm an easy client ... I just need a list of chans and a good notification system (which xchat-gnome has, it opens notify bubble with who talked to you want what he said)
<jbailey> seb128: The ones that have come up so far: The triangle to expand the topic shouldn't be there if there's nothing to expand.  I spend a good 30 seconds playing with it trying to figure out what it was doing when I clicked it in another channel. =)
<jbailey> seb128: Once I've clicked on the userlist to see the users, it would be nice to have the old equivalent of double clicking on them or something as an equivalent of /wii FOO
<seb128> jbailey: right, the topic stuff is not optimal :)
<jbailey> A right click action would be fine.
<jbailey> seb128: I seem to have a <none> channel or server in my serverlist that I can't get rid of.
<seb128> jbailey: serverlist, like the properties dialog?
<jbailey> seb128: The window immediately to the left of this chat window.
<dexem> jbailey: are you the maintainer of "locales"? I've seen this: http://bugzilla.ubuntu.com/show_bug.cgi?id=16216 and I would like to know if it could be corrected for breezy...
<infinity> jbailey: Right-click on the <none> and "close"
<infinity> jbailey: At least, that's how I got rid of mine just now.
<seb128> hum
<jbailey> dexem: Locales changes are rarely changed in released versions.  People may have setup their machines to compensate for that and it could break things to change it now.
<jbailey> dexem: It should already be fixed in Dapper, I think, but I haven't been able to check it.
<raphink> hmm
<jbailey> infinity: Ah that works, but the 'x' when I clicked on it didn't work, thanks.
<raphink> there's no use of debconf in locales anymore? o_O
<dexem> jbailey: aham, ok. Thanks :)
<jbailey> seb128: In this channel with the larger topic, I tend to associate the 'x' with the topic rather than the window, so I might be inclined to click on it to shrink the topic.
<jbailey> seb128: You can see that these are all minor UI nits.
<jbailey> seb128: But it does leave me with the feeling of 'weird'
<seb128> yeah
<seb128> jbailey: do you have some autoconnect ?
<jbailey> seb128: I don't.  I keep separate accounts for work and home and choose the one I want at startup.
<seb128> jbailey: those are small things, nice than you point them now so they can get fixed for dapper :)
<jbailey> I have to be able to get away from y'all sometimes. ;)
<koke> jbailey: it's not fixed in dapper, I've just attached to that bug a patch for breezy glibc and another for dapper langpack-locales
<seb128> jbailey: oh, is there some profile? or you just set a nickname and pick some chans at every startup?
<seb128> jbailey: right, I've the <none> too with no autoconnect
<jbailey> koke: Ah, okay.  Thanks.
<jbailey> I'll ping MArtin when he's around next.  i'm not actually sure how to update the locales now. =)
<infinity> seb128: Really?... When I start and pick a network, it connects to it... I only have <none> while the network in question can't be connected to.
<koke> jbailey: any ideas on which's the best option for fixing that in dapper
<jbailey> seb128: I have server profiles that I defined.  So  00Home Servers  and  00Ubuntu Servers  are in the list, and I just double click on the one I want.
<infinity> seb128: Which happened cause I picked a network that wouldn't let me on. :)
<koke> we are working on a derivative, but versioning glibc... not a good idea
<jbailey> koke: Is the dapper one in that bug report, or is there a different one?
<seb128> jbailey: oh, oki
<koke> jbailey: the dapper one is http://bugzilla.ubuntu.com/attachment.cgi?id=5632
<jbailey> seb128: It means I still get all my automatic nickserv'ing and all that with a minimum of hassle.
<koke> but I haven't tested yet
<seb128> infinity: when there is no autoconnect it puts a <none> by default here, and I've connected a server it has opened a new entry ...
<jbailey> seb128: There's alot that I like.  The server list being on the left out of my field of vision is nice, and the "random conversation" icon doesn't pull my eye at all.
<infinity> seb128: Oh, weird.
<jbailey> seb128: Having the reduced window for clicking on links is also lovely.
<jbailey> koke: Ah, which derivative?
<seb128> jbailey: you mean the URL plugin?
<jbailey> seb128: The old x-chat did that until recently, and then they started replacing the NULL window with the first server openned.
<jbailey> seb128: They changed tht in the last month, I think.
<jbailey> seb128: I have no checkboxes in any of my plugins.
<jbailey> seb128: Since there's no description of what they do, I didn't want to enable any of them.
<seb128> jbailey: what is "the reduced window for clicking on links" ?
<jbailey> <koke> jbailey: the dapper one is http://bugzilla.ubuntu.com/attachment.cgi?id=5632
<dexem> jbailey: we are working on Tirwal Linux (a small spanish local distribution). We are using ubuntu and guadalinex as our starting point
<jbailey> seb128: When I put my mouse over that URL, it underlines, like in old x-chat.
<seb128> auto-away set you away when gnome-screensaver starts
<seb128> ah, ok
<jbailey> seb128: When Iright-click, I only have "Open in browser", and "Copy URL".
<seb128> notification is a notify area stuff
<jbailey> seb128: Which is very nice, thanks.  It even correctly defaults to ephy for me, so it's good.
<seb128> osd uses libnotify to open bubbles when somebody talks to you on a chan or in query
<jbailey> dexem: Nice!  Did you just fork glibc for the locales stuff?
<jbailey> seb128: Ahahah, really?
* jbailey tries.
<jbailey> I wonder if my screensaver still hangs my machine.
<dexem> jbailey: Well... we haven't decided anything yet. We have discovered the problem (and its solution) today
* jbailey tries.
<jbailey> dexem: locales is no longer from the glibc source in dapper.
<koke> jbailey: the distro is based on breezy
<jbailey> koke: Right.  More to let you know that you can sidestep that pain in the future. =)
<jbailey> koke: Having to touch glibc just to fix minor locale issues is a bit excessive.
<koke> jbailey: yep, but having calendar starting on Sunday is not good for us
<jbailey> koke: It would be easy enough to update in Breezy, but that's my concern - that people may have worked around the problem.  I'd hate to have calendaring or scheduling start to go wrong for people just because we fixed a bug that's been there for many years.
<raphink> anyone has an idea what a problem linked to the ^ key system-wide might be linked to?
<jbailey> seb128: Funky popout bubble.
<koke> jbailey: according to the gtk cvs logs it's likely to have been made visible around september
<raphink> not only it does not work properly, but when I type ^+e for example, several times, I get nothing ; but then if I try to use the backspace key, it deletes the prompt!
<seb128> jbailey: yeah :)
<koke> so, the clock applet (amongst other software) shows a wrong calendar
<hunger> What is the nick of Scott James Remnand? He is on IRC, isen't he?
<jbailey> koke: I'd have to punt the question to mdz (bug#16216 for breezy for your nick hightlight, Matt).  As I said, I'm not thrilled about it, but doing the patch and upload is easy enough.
<raphink> anyone knows where I shall report a ^/ key issue?
<infinity> hunger: No, Keybuk doesn't IRC.
<sivang> infinity: he's not? I thought he was, that's a shame.
<hunger> Oh, Keybuk is scott? great:-)
* hunger is confused by developers hiding behind their real name in changelogs:-)
<sivang> infinity: IIRC he usually shows up in here , no?
<Kamion> sivang: YHBT, YHL, HAND
<sivang> Kamion: ?
<Kamion> http://www.catb.org/jargon/html/Y/YHBT.html
<sivang> doh! :-)
<jbailey> seb128: Other observations.  It doesn't seem to be possible to set my other-highlights, which I guess might not be a common enough feature for others (I usually highlight on my package names as well), and when a highlight is triggered, it no longer flashes the button in the panel.  I suspect that behaviour should come back, since it's consistant with when firefox or evo have popped up a menu or something that needs your i
<jbailey> mmediate attention.
<phlax> hi there - ive upgraded to dapper, and my second xinerama screen (os radeon driver) has ceased to work. I was wondering if anyone knows of changes in X that might have caused this, or should i file a bug?
<Treenaks> phlax: file a bug
<Treenaks> there have been LOADS of changes in X
<jbailey> There have been STORES of changes, too...
* jbailey hides.
<jbailey> =)
<phlax> right - i was just wondering if there was an obvious conf change.
<seb128> jbailey: for the notification there is the "notify" plugin which use the notification area
<jbailey> seb128: Yeah..  On a 20" cinema display, a little icon popping up is no where near my field of vision.
<seb128> jbailey: use the osd plugin to get bubbles? :)
<seb128> jbailey: BTW how do you customize you highlight list with xchat?
<HiddenWolf> jbailey, I manage with a 24" widescreen. The trick is to unglue your nose from the monitor. :)
<seb128> that's a preference option?
<jbailey> HiddenWolf: That just means enlarging my fonts even further..  Or finding my glasses.  I haven't seen them in over a year. =)
<HiddenWolf> =)
<jbailey> seb128: There's a comma separated list of words to use for highlights in one of the preferences boxes.
<sivang> jbailey: you need anew pair then!
<jbailey> seb128: I'm more arguing that if other apps are using flashing panel button for urgent notification, perhaps this one should too.
<jbailey> seb128: Which is also what old x-chat did.
<jbailey> I think it's arguable that someone talking to you is as urgent as the fact that I need to type in a username/password for a web page/
<seb128> jbailey: I'm not sure that everything using the urgent flag is nice
<seb128> jbailey: gaim/xchat which do that are not GNOME apps ... :)
<jbailey> seb128: Right.  I often wish that other things wouldn't. =)
<seb128> the GNOME way would rather be to use the notification area
<jbailey> seb128: But interactive conversations do tend to require urgent response. =)
<jbailey> Ah okay.
<jbailey> So more that things are migrating to the notification area.
<seb128> "'notification area", it's in the name :p
<jbailey> seb128: True.  Although it generally seems to be a holding place for things rather than a notification area.
<jbailey> seb128: (thinking rhythmbox, evo, gaim here...)
<seb128> right, apps tend to abuse of it instead of using applets
<jbailey> i thought everyone was told not to use applets awhile back.
<HiddenWolf> perhaps it will change if the applets system gets overhauled, like was planned an age ago and now possibly revived by the bonobo-free port of panel+applets
<seb128> jbailey: I doubt of that, people were told to not abuse the notification area for applets job though :)
<jbailey> seb128: =)
<seb128> the issue with applet is they are not dynamic atm
<seb128> users have to add them
<seb128> jbailey: I've just opened a few bugs upstream according to what you pointed :)
<jbailey> seb128: Thanks.
<seb128> np
<jbailey> It'll be interesting to watch this package evolve.
<sladen> seb128: where's your gnome-panel Applications Menu/gam_server disappearing bug?  I have a patch
<seb128> sladen: http://bugzilla.gnome.org/show_bug.cgi?id=323064
<seb128> there is a patch upstream too
<seb128> but according to the comment they want to drop inotify code from gam_server since gnome-vfs does inotify directly now
<seb128> I've to patch/rebuild gnome-menus to use gnome-vfs API instead of gam one
<tseng> that doesnt make sense to me
<sivang> sladen: wow, what was the problem, how did you find it? 
<seb128> sivang: the issue is well known for ages, maybe he read the bug? :p
<seb128> sivang: gam_server send a wrong signal on broken symlink
<seb128> tseng: what?
<tseng> seb128: that just gives fam apps crappy dnotify polling
<sivang> seb128: /me goes to read that interesting bug, reckon much has changed there since I last glanced at it.
<tseng> no one is going to automatically start using gnomevfs
<sladen> seb128: http://www.paul.sladen.org/ubuntu/bugs/gnome-panel_2.13.4-0ubuntu3.applications-menu-disappearing.deb.diff
<sivang> seb128: I deserved the :p :)
<sivang> sladen: or better, read your patch :)
<sladen> if seb128's patch is in, it wasn't working as of an hour ago
<seb128> tseng: if you want to step to maintain gam_server/inotify you are probably welcome
<sivang> sladen: nice
<seb128> sladen: the patch is not in, it breaks the testsuite somewhere, I was waiting on them to sort that
<seb128> tseng: nothing out of gnome-menus from the GNOME desktop uses gam API ..
<zul> heylo
<seb128> tseng: and gnome-menus has a patch
<tseng> hm ok
<seb128> gnome-vfs was using gam_server before
<seb128> that's why everything use it
<seb128> apps usually just use gnome-vfs functions for that
<tseng> my apps are using inotify directly atm
<ulaas> i have lots of jittering movement while moving windows
<tseng> so cool
<seb128> vuntz_: any opinion on http://www.paul.sladen.org/ubuntu/bugs/gnome-panel_2.13.4-0ubuntu3.applications-menu-disappearing.deb.diff ? That's for the app menu issue. The bug is due to gam_server but maybe that change for the panel is correct anyway, if you want to have a look on it
<sladen> seb128: I think there maybe two bugs;  one that gamin is sending the notify;  and the other is that gnome-panel/menu.c is hosing the menu and then scheduling an update (rather than getting the function doing the update to take care of the destorying).  I approached that patch from the second PoV
<ulaas> seb128, i had that issue on my laptop. which was dapper as well
<seb128> ulaas: the issue is well known and due to /var/lib/menu-xdg/menus/debian-menu.menu not beeing here (which breaks /etc/xdg/menus/debian-menu.menu)
<seb128> sladen: I've pointed it to vuntz who is upstream for gnome-panel, let's wait on his comment 
<ulaas> seb128, ah ok.
<sladen> seb128: nod
<seb128> ulaas: it'll be fixed rsn
<raphink> my ^/ key stopped working properly. Any idea what think can be linked to guys?
<ulaas> seb128, not a problem for me anymore i dont have that problem for a long time..
<raphink> hmm hello ! major encoding bug here, anyone interested?
<raphink> :s
<Treenaks> raphink: looks like valid UTF-8 to me
<Treenaks> raphink: that's the ^/[umlaut or trema]  key?
<raphink> Treenaks: my problem is not with printing ^ or 
<raphink> I can't use them with voyels anymore
<raphink> I can't type ^e or e
<raphink> or any kind of stuff like this
<raphink> and whenever I try to in a tty and use backspace afterwards, it deletes my prompt ;)
<Treenaks> raphink: locale charmap gives UTF-8 ?
<raphink> yes
<Treenaks> hmm
<raphink> I've used UTF-8 as my default for months
<raphink> without a pb
<raphink> I began to have system-wide problems with that yesterday evening
<seb128> maybe an xorg issue?
<raphink> it seems each time I use ^+anykey, it deletes a char
<raphink> seb128: nope it does it in tyys
<raphink> ttys
<seb128> ah
<raphink> for example
<raphink> I type 
<raphink> the following series of keys in a tty
<raphink> ^ a ^ a backspace backspace
<raphink> and it deletes the $ in the end of the prompt
<vuntz_> seb128: patch looks weird :-)
<ulaas> anjuta crashes on startup on dapper
<raphink> each ^+anykey+backspace will delete one more char in the prompt
<raphink> beginning with the space following the $
<vuntz_> sladen: what's the first function where you move the code?
<raphink> what do you think seb128 ?
<jbailey> seb128: I'm surprised they kept the lag indicator in the lower left, with no other information in the status bar.
<seb128> raphink: I've no idea on the issue
<jbailey> Seems like a waste of space.
<ulaas> ah great LP is down for maint.
<raphink> seb128: where do you think I should report it?
<seb128> raphink: bugzilla? dunno on what package though
<raphink> that's my question actually , which package ;)
<seb128> jbailey: hum, that's right!
<seb128> raphink: try to figure what you updated between the moment it worked and the moment you started getting the issue
<raphink> hmm
<sladen> vuntz_: handle_gmenu_tree_changed() -> submenu_to_display()
* raphink goes to look at dapper-changes
<vuntz_> sladen: I don't get it, sorry
<vuntz_> sladen: handle_gmenu_tree_changed() should not be called when the menu opens
<jbailey> seb128: Oh hey, there's a big highlighting box in the middle of the preferences page which I had somehow completely skipped over.
<jbailey> seb128: *sigh*  One day I'll have to ask mpt why that happens. =)
<vuntz_> sladen: if it happens, then there's another bug somewhere
<seb128> jbailey: ah, right :)
<vuntz_> hrm
<sladen> vuntz_: "There's half a bottle of milk in the fridge.  I need to get some more tomorrow, but I'll throw away the current one now, even though the shops don't open for another 14hours"
<vuntz_> sladen: in fact, the way we're doing stuff right now is broken, to be honest
<sladen> vuntz_: whether or not is should be, it is getting called.  GDB and debug build got me that far :)
<vuntz_> we should not remove the items, but update them
<vuntz_> sladen: the question, is why is it being called? :-)
<blue-frog> in xchat-gnome 0.8 my logged in user shows up with my IP (n=admin@81...) while I can use another name in Xchat IRC (n=james@81...). Will this be change in future Xchat-gnome?  
<vuntz_> I understand the patch fixes the symptom, though
<seb128> vuntz_: the bug is due to gam_server/inotify as said, which sends wrong signal, it's going to be fixed
<ogra_ibook> seb128, wouldnt the right patch be to not have the broken symlink in menu-xdg ?
<ogra_ibook> s/patch/fix
<seb128> ogra_ibook: no, the right fix would be for gam_server to no shock on broken symlink
<sladen> vuntz_: how long does a build of libgnome with symbols take?
<seb128> 1 min
<sladen> oh, okay
<ogra_ibook> seb128, i guess both should be done ...
<seb128> ogra_ibook: ok, I'll open a bug and assign it to you for the menu-xdg/menu issue, one beeing universe not the other, good luck to fix it
<sladen> gam_server shouldn't send crap.  gnome-panel shouldn't barf on getting crap.
<tvo> anyone knows which pkg provides /usr/include/GL/gl.h in dapper atm? (or should provide)
<sladen> either would be fine, both is correct
<ogra_ibook> seb128, if it can wait until after feature freeze, i'm all open for it ... feels odd to have packages installing dangling symlinks ...
<seb128> ogra_ibook: seems you don't have any real bugs to bother with that :)
<ogra_ibook> i expect it to becomme a bit more silent post feature freeze :)
<vuntz_> sladen: so
<vuntz_> sladen: gnome-panel doesn't do anything
<vuntz_> sladen: gnome-menus is getting the crap
<vuntz_> not gnome-panel
<vuntz_> then gnome-menus tells the panel: "stop! something changed!"
<sladen> okay.  I just couldn't see a separate applet called  gnome-menus (which is what I was expecting)
<Keybuk> mvo: ping?
<sladen> could it be that  handle_gmenu_tree_changed()  is getting called because it _itself_ changes the  contents of the menu (by deleteing it) and therefore schedules a signal, which calls itself, ... et al
<vuntz_> sladen: I hope not: handle_gmenu_tree_changed() deletes the contents of the menu, not the .desktop files
<vuntz_> so there shouldn't be any loop there
<vuntz_> if there is, then something is really broken
<mvo> Keybuk: pong
<sivang> sladen: interestingly related, I haven't been able to reproduce the menus bug on my office dapper, any idea why?
<mdke> infinity, ping #2 on ubuntu-docs
<seb128> sivang: did you read the bug ?
<mdke> Kamion, get my /query? hope that is ok
<seb128> sivang: do you have "menu" installed? ls -l /var/lib/menu-xdg/menus/debian-menu.menu ?
<Kamion> mdke: yes
<mdke> Kamion, thanks a lot
<infinity> mdke: Gah.  I knew there was something I was forgetting.  Seriously.  Okay, before I go to bed, I'm writing a note in a REALLY BIG FONT on my desktop.
<mdke> infinity, thanks :)
<blue-frog> when filling in a bug at https://launchpad.net/distros/ubuntu/+filebug do I have to precise for dapper or is implicite?
<sivang> seb128: I didn't have it, I installed it, gnome-session-remove'd gnome-panel, then restarted it, still can't reproduce. applications menu works as expected.
<Keybuk> oooooh
<Keybuk> you can drag folders of mp3s onto Totem
<Keybuk> \o/
<Keybuk> seb128: btw, can evolution's pointless little clock n-icon go away?
<dexem_away> I have a problem with breezy... http://img297.imageshack.us/my.php?image=pantallazo5cg.png, and I was going to fill a bug, but I don't know if I should do it on Ubuntu bugzilla (I don't know if it's a distro problem) or on gnome bugzilla... The most weird thing is that with LANG=C it doesn't happen: http://img300.imageshack.us/my.php?image=screenshot4rg.png
<dexem_away> anyone have seen this problem before?
<ogra_ibook> Keybuk, thanks for ltsp sound approval btw ...
* ogra_ibook grumbles at bzr
<elmo> seb128: ?
<elmo> or that french gnome guy will do, what's his name... dholbach?
<dholbach> hahahaha
* dholbach hugs elmo
<ogra_ibook> lol
<elmo> do we want librsvg source from debian?
<dholbach> elmo: i have to have a look
<jbailey> mvo: ping?
<mvo> jbailey: pong
<vuntz_> dholbach: oh, you were promoted from german to french? :-)
<Treenaks> Dutch, you mean ;)
<dholbach> vuntz_: elmo was the one who said "bon jr" every day to me at UBZ :)
<Keybuk> elmo's subtle like that
<Kamion> elmo: yo? #ubuntu-meeting
<Kamion> aha
<dholbach> elmo: i need to ask seb about that, we'll need to do a merge, but in general it's preferable to have the librsvg source package
<dholbach> elmo: can you sync texinfo please, if you find the time (ok to override)
<dholbach> elmo: and about gutenprint: i'm ok with the sync, i checked the packaging and the files in the packages - i just wasnt sure, if there would be any other magic involved (apart from removing the gimp-print source from the archive afterwards)
<sivang> hmm, what's the thing with the dict applet that won't close it' swindow after usage? :)
<sivang> it sticks there in the face and won't go away ..
<elmo> dholbach: ok, synced both - thanks
<sladen> vuntz_ / seb128 : ~/.config/....  not existing seems to be causing a DELETED event to be sent?
<dholbach> elmo: cool
<dholbach> elmo: so i can close two bugs :)
<seb128> elmo: I'll update librsvg/sync with Debian this week
<vuntz_> sladen: looks like a bug :-)
<infinity> elmo : Did you catch my sync request in #-toolchain?
<seb128> Keybuk: it'll go away for dapper, upstream have been bugged several times about it already :)
<elmo> infinity: yeah
<infinity> elmo: Spiffy.
<sistpoty> infinity: do you happen to have some time for fpc bootstrapping?
<infinity> sistpoty: It's 2:30am, so no, not today, but email me (adconrad@ubuntu.com) with the details, and I can ping you when I have a moment.
<sistpoty> infinity: ok, will do... should be ease (it works with debian packges on i386)... thx!
<sistpoty> elmo: please sync rlog from unstable, ubuntu override ok. Thx.
<mdz> jbailey: the first_weekday stuff wouldn't actually change any calendar events, right? just the display of the calendar?
<Keybuk> mvo: I see your point
<Mithrandir> mdz: we have persistent live cd support now.
<blue-frog> everytime i fill in a bug it insists in assigning it to ubuntu, then i target dapper and i reject ubuntu. is there a way i can aasign it right away to dapper (thus not making duplicates)?
<sladen> vuntz_: yes, the extranous upate is coming from a symlink existing, but not its destination sending a _CREATED notify
<sladen> vuntz_: but why that is being sent only when the menu is shown, I don't know
<vuntz_> sladen: maybe because we're trying to read the symlink?
<sistpoty> elmo: please sync zipios++ from unstable, ubuntu override ok, thx.
<Mithrandir> Keybuk: you said earlier that multiple copy_exec calls for the same binary should work?  In my testing, it doesn't; update-initramfs gives an error
<Keybuk> I did?
<Keybuk> I don't ever remember saying that
<dexem> mdz: do you think first_weekday calendar thing could be fixed for breezy?
<Keybuk> are you sure it was me?
<Mithrandir> Keybuk: fairly
<mdz> Mithrandir: cool!
<Keybuk> I bet you it wasn't
<Mithrandir> mdz: it needs a bit of UI work (so it's selectable in the bootloader and there needs to be some docs on how to prepare the USB drive), but it's mostly there.
<Mithrandir> mdz: also, it doesn't work on ppc, since block devices don't have labels, filesystems have labels.
<Mithrandir> Keybuk: I can't find it at least, so it probably wasn't.
<sladen> vuntz_: every interation, it's sending  "/home/paul/.config/menus/applications.menu":DELETED, "/etc/xdg/menus/debian-menu.menu"CREATED
<vuntz_> is gamin sending this?
<sladen> vuntz_: and I wouldn't expect the _DELETED to be sent more than once ...unless ...we're reregistering for it by creating and destroying the menu
<sladen> vuntz_: which makes it even more chicken and egg-ish
<vuntz_> we're keeping the GTree object, AFAIK
<vuntz_> GMenuTree
<mindlace> debian and ubuntu have quite outdated versions of openldap that contain a bug that causes slapd to run extremely slowly. I am compiling openldap 2.3.11 for myself, and believe I'm at least following the LSB. What is my concrete next-step to getting a more recent LDAP into ubuntu?
<dholbach> bbl
<Mithrandir> mdz: if you could, at some point, look at if you're happy with the live cd.  The version in the archive doesn't have usplash integration working correctly yet, and keyboard chooser is missing.  Apart from that, I think it's fine.  If you could look at it and verify, I'd be happy.
<mdz> Mithrandir: the last version I tried, which was about a week ago, looked great except for the two items you mention
<mdz> Mithrandir: thanks for getting it into shape
<Mithrandir> mdz: ok, the usplash should be there tomorrow, I'm less sure about the keyboard stuff.  Colin wants keymapper to spit out X keymaps and switch to using that in d-i instead of having two sets of data, but I haven't gotten keymapper to actually work correctly with X keymaps yet.
<jbailey> mdz: It changes which day of the week is first.  So I think it should theoretically just change the display.  I don'
<Keybuk> http://people.ubuntu.com/~scott/restart-req.png
<Keybuk> \o/
<jbailey> 't know that someone wouldn't have done something silly like use the altered value as the index to an array or something.
<jbailey> mdz: So it's unlikely to be a problemm, but it's not zero-risk.
<mdz> jbailey: if a simple sanity test works, I'm happy with it
<LaserJock> Keybuk: how are ~scott/patches/ generated?
<HiddenWolf> Keybuk, that is so "the sims"
<jbailey> mdz: YezBoss. =)
<Keybuk> HiddenWolf: yeah, I hate the new ugly notification popups
<Keybuk> LaserJock: by a system called NDA
<Keybuk> basically for PKG in *; do diff debian/$PKG ubuntu/$PKG > ~/patches/...; done
<mvo> is anyone of you sitting behind a proxy that delivers the data in "chunked" encoding?
<LaserJock> Keybuk: ok, thanks
<HiddenWolf> mvo, how do you know?
<Keybuk> LaserJock: was there anything in particular you wanted to know, or any problem you had?  that was a rather open question
<mvo> HiddenWolf: a quick way to figure out is to run: "sudo apt-get install --download-only -o Debug::Acquire::http=true 3dchess" and lookinto the http headers for "chunked"
<LaserJock> Keybuk: I have been trying to interact with some Debian folks and some of them get a little hot about Ubuntu not giving back patches to DDs and I thought I remembered in Mark's Debconf5 talk something about patches so I was just wondering how they were created, etc.
<HiddenWolf> mvo, hm, can't help you then.
<mvo> still thanks for checking :)
<HiddenWolf> no trouble.
<HiddenWolf> and oh, pick a package without dependencies instead. :)
<mvo> HiddenWolf: right. it's my standard testpackage (because it used to be on top of the synaptic list) so I have all dependencies already :P
<mvo> nowdays we have 2vcard on top, but that was only added a short while ago
<HiddenWolf> hah. :)
<mdz> Mithrandir: do we have it guessing the layout based on the locale selection from the bootloader yet?
<Mithrandir> mdz: yes
<Mithrandir> mdz: it works-ish, but frequently gets it wrong.
<mdz> Mithrandir: leaving the user to configure it using the GNOME layout selector, which is not so bad
<ogra_ibook> mdz, Keybuk approved ltsp sound, do you want to merge it or should i merge and upload ?
<Mithrandir> mdz: true, but we don't get it set in the console (at all) yet.
<mdz> we can't do too much better non-interactively; I think selecting locale and keymap both from the boot loader would probably result in too many menu items
<mdz> ogra_ibook: go ahead, thanks
<Keybuk> LaserJock: the patches for all of the packages we've modified are available there
<ogra_ibook> thanks :)
<Mithrandir> mdz: Kamion seems to think it's sensible, can you to battle it out? :-)
<Keybuk> we've even worked with Debian to get that linked from the Debian Package Tracking System
<mdz> Mithrandir: what, selecting the layout from the boot loader?
<mdz> if we could somehow narrow it to only the ones which are usually ambiguous, that would be ideal
<mdz> ogra_ibook: do hwdb submissions include the locale?
<Mithrandir> mdz: yes, Kamion wants to be able to select keyboard there.  I think it would be better to have it in the bootloader, but it works to not have it there too.
<Mithrandir> mdz: yeah, that'd be really sweet.
<Keybuk> LaserJock: so, e.g. http://packages.qa.debian.org/s/sysvinit.html has a "Packages from ubuntu for version FOO" link on the left
<ogra_ibook> mdz, nope
<LaserJock> Keybuk: oh, that's right. I think I have seen that before.
<ogra_ibook> but i can add it
<Mithrandir> Kamion: can we narrow it down to a reasonable set for the language selected?  So if you chose french you get a selection of french, swiss and possibly some other keymaps?
<LaserJock> Keybuk: thanks, I think I've got what I need to do some reply's ;-)
<mvo> mdz: what is your general opinion about a (optional) curl based fetcher method for apt?
<mdz> mvo: for what purpose?
<mvo> mdz: the idea was to not have to maintain the http/ftp downloders ourself, but let libcurl take care of it
<mdz> Mithrandir: have you or Kamion looked into the xkb->console keymap widget?
<Mithrandir> mdz: I have begun looking at it.
<mdz> mvo: I like the idea of using an externally maintained implementation in principle
<mdz> mvo: however, I think libcurl's http client is less featureful than apt's
<mvo> mdz: in what particular respect? pipelining?
<Keybuk> LaserJock: you'll encounter a come-back of "oh, but those aren't in the right format" / "they did things the wrong way, how can I accept that?!" etc.
<mdz> mvo: for example
<Kamion> Mithrandir: I think that would be achievable, yes
<LaserJock> Keybuk: well, as long as I do what I can I will feel better about ignoring those come-backs :-)
<Kamion> even if we didn't, though, the keymap menu would be smaller than the locale menu is now
<Mithrandir> Kamion: excellent.  I am going to further investigate what's wrong with keymapper tomorrow, I think.
<Kamion> so I don't think it's a big deal; I'm happy to hide keymap behind "Other Options" if we don't want to display it by default
<Kamion> or perhaps only show the reduced set of keymaps until you select "Other Options", or something like that
<Mithrandir> Kamion: that'd be really nice, since we will have people who want their computer to speak mongolian to then, while they do in fact have an italian keyboard.
<Mithrandir> though, having those use the keyboard selector in gnome is fine, I think
<Kamion> yes, I don't think it's essential
<Kamion> RAH, working gparted embedding in espresso
<ogra_ibook> wohoo
<HiddenWolf> Does it make coffee too? :)
<ogra_ibook> only the strong italian one :)
<Kamion> looks pretty dreadful as yet, but at least it's there: http://people.ubuntu.com/~cjwatson/tmp/espresso-gparted.png
<Kamion> (and ignore the typos at the left, all that text will probably be replaced)
<HiddenWolf> Kamion, can you get rid of the numbers in the location bar?
<mvo> Kamion: how do you do it? use GtkSocket/GtkPlug?
<dholbach> looks like a good start :)
<Kamion> mvo: yes
<Kamion> HiddenWolf: you mean the breadcrumbs at the top?
<HiddenWolf> yeah
<Kamion> sure, a lot of it's inherited from Guadalinex and it's all very rough as yet
<HiddenWolf> Kamion, the text alone should be enough. otherwise, start at one, but I'm guessing users can count. :)
<Kamion> HiddenWolf: *nod*
<HiddenWolf> Kamion, details, sorry. Looks like a sweet start :)
<hunger> Kamion: What are those lock-icons signifying?
<hunger> Kamion: encrypted partitions?
<Kamion> hunger: um, no idea :)
<HiddenWolf> hunger, can't be changed at present?
<hunger> Why is cups getting started all the time when upgrading?
<hunger> It wasn't running before I upgraded, so it shouldn't run afterwards I think.
<Kamion> hunger: oh, I think it means "busy", i.e. currently in use
<Kamion> so the swap partition is in use and thus the extended partition is too
<segfault> express renamed to espresso?
<hunger> Kamion: Yes, that is possible... an extended encrypted partition wouldn't make much sense:-)
<psusi> lock icons mean you don't have write access
<HiddenWolf> psusi, odd to put them there.
<psusi> ohh, in gparted?  hrm...
* psusi thought he was on the #ubuntu tab for a second ;)
<Kamion> segfault: yes, 'ubuntu-express' was a project codename, but it became too confusing because lots of people outside Ubuntu were implementing stuff we weren't going to use in that form and calling it 'ubuntu-express'
<segfault> nice, at least in portuguese means the same thing.
<psusi> that could be... but I thought if ANY partitions on the disk were in use, you got an EBUSY trying to refresh the partition table
<segfault> and now is a native word.
<segfault> heh
<hunger> Is it OK to change permissions of stuff in /usr in a init-script?!
* Keybuk giggles as for the 100th time he searches for "GNOME HUG"
<ogra_ibook> Kamion, did you drom ltsp-client-builder from the edubuntu installer ? 
<ogra_ibook> according to anastacia it wants to go to see the universe ...
<ogra_ibook> s/drom/drop
<Kamion> no ...
<Kamion> ltsp-client-builder |    0.1.0-5 |        dapper | source
<Kamion> ltsp-client-builder |       0.62 |        dapper | all
<Kamion> hmm, that's very odd
<Kamion> oh, it's built from ltsp now
<ogra_ibook> yup
<Kamion> ogra_ibook: anastacia's just talking about the old ltsp-client-builder source package, not the binary
<ogra_ibook> since quite some time already
<ogra_ibook> ahuman01, fine, thanks :)
<Kamion> ogra_ibook: you might as well ask elmo to remove that old source
<ogra_ibook> elmo, please remove the ltsp-client-builder source package from the archive 
<pryzbyj> Keybuk: there?
<Keybuk> pryzbyj: 'sup?
<pryzbyj> i don't understand why you said that the normal sed on dpkg status database won't work
<hunger> Keybuk: Did you do the recent updates to the initscripts?
<hunger> Keybuk: Would you mind adding a chmod 1777 /tmp to the cleantmp function?
<Keybuk> pryzbyj: "normal sed" ?
<pryzbyj> as on dpkg.org/conffilehandling
<Keybuk> hunger: did you unchmod it?
<Keybuk> pryzbyj: because you were doing it in postinst, and the md5sum of the old configuration file is gone by then
<pryzbyj> yes i understand that
<hunger> Keybuk: No, I get a fresh /tmp each reboot:-)
<pryzbyj> hold on ..
<hunger> Keybuk: I have /tmp on an encrypted partition which changes keys each reboot.
<hunger> Keybuk: So I have to format it each startup and whenever I do that the permissions get reset.
<Keybuk> hunger: sounds like you're responsible for the hole in your own foot then ;)
<hunger> Keybuk: OK, just thought I'd ask.
<hunger> Keybuk: I'll just add my own fixes if you do not think it worth doing in the standard scripts.
<pryzbyj> Keybuk: i mean the last script that i gave, for 'transferring conffile ownership', not the correction to the first one ..
<pryzbyj> which is presinst
<pryzbyj> preinst
<pryzbyj> if [-e]  if ["$md5sum"="$oldmd5sum"]  rm -f
<pryzbyj> Keybuk: http://justinpryzby.com/tmp/keybuk
<Kamion> HiddenWolf: ok, numbers removed in my local tree
<Kamion> thanks for the suggestion
<HiddenWolf> Kamion, yay. :)
<pryzbyj> in the worst case i would expect the sarge md5sums to be hardcoded in the maintscripts until etch release ..
<Keybuk> pryzbyj: right, where do you get the old md5sum from?
<pryzbyj> stats
<pryzbyj> status
<Keybuk> it isn't in there
<Keybuk> which was kinda my point
<pryzbyj> i don't understand why; this is preinst!
<Keybuk> that's the new md5sum
<Keybuk> your mail says that's postinst
<pryzbyj> no the 2nd script; not the first
<Keybuk> oh, right
<pryzbyj> this works, no?
<Keybuk> possibly right
<Keybuk> except it doesn't allow for aborting
<pryzbyj> right
<pryzbyj> and it doesn't preserve removal
<pryzbyj> but is an improvement anyway
<Keybuk> it is?
<Keybuk> looks the same to me
<pryzbyj__> bah
<pryzbyj__> did i miss sth?
<Zomb> hi
<Zomb> I had problems installing Breezy on amd64 from a Philips/Benq DVD-RW drive. A bad checksum was reported while reading the CD, and I saw messages about "Block size 65534 not supported on this drive." among IO errors in the kernel log.
<Zomb> anyone seen that before?
<Zomb> the number 65534 looks weird
<Zomb> and 2.6.15 with Sid has no problems with the drive
<pryzbyj__> Keybuk: i'm going to mail maintainers w that shscript
<Keybuk> "maintainers" ?
<pryzbyj> ssh, firefox, OO.org, mysql
<pryzbyj> presently affected by sarge => testing upgrades
<Keybuk> if you're going to mail it to a wide audience, I'd wait until it's finished
<pryzbyj> finished how though
<Keybuk> in particular, make sure it supports failed upgrades
<Keybuk> so have a postrm bit that takes care of putting things back
<ogra_ibook> mdz, could we demote ltsp-utils to universe ? i dont understand why its still in main, apt-cache rdepends says its needed by ltsp-client which in fact only has a replaces/conflicts on ltsp-utils ...
<ogra_ibook> so there should be nothing keeping it in main
<pryzbyj> Keybuk: i don't understand maintscript options that well :/  abort-install?
<Keybuk> like I said, look at the Ubuntu udev package
<Keybuk> it has improved versions of both rm and mv
<pryzbyj> i am
<Keybuk> prep_{rm,mv}_conffile in preinst, {rm,mv}_conffile in postinst and undo_{rm,mv}_conffile in postrm
<Keybuk> I also have new versions that honour user-removed-conffiles in mv
<pryzbyj> ok .. it will take me awhile
<mdz> ogra_ibook: it's in main because it's seeded
<ogra_ibook> oh... sure ... why am i always expecting to see a metapackage dependency for all stuff in main ...
<ogra_ibook> will fix that
<pryzbyj> "# Remove a conffile directory if it's not empty
<pryzbyj> "  :)
<Keybuk> (in prep_mv add 'else\n\ttouch "$CONFFILE".dpkg-gone', in undo_mv add 'rm -f "$CONFFILE".dpkg-gone' and in mv add 'elif [ -f "$OLDCONFFILE".dpkg-gone ] ; then\n\techo "Preserving user removal of $OLDCONFFILE"\nmv -f "$CONFFILE" "$CONFFILE".dpkg-new"
<HiddenWolf> Kamion, some guy on -devel list announcing a project for a windows-based installer, doing basicly the ubuntu-express thing.
<psusi> that would be a rather large project
<jpatrick> yep
<psusi> would take several man-months I'd say
<psusi> need a lot of code just to be able to manipulate ext3/reiserfs partitions from windows to copy the files
<Burgwork> psusi, http://www.fs-driver.org/
<Kamion> HiddenWolf: *shrug* there are a million live installers out there, the thing that's different about the one I'm doing is that it integrates tightly with d-i so that we don't have to maintain the same complex code in two places
<psusi> Burgwork: that's for windows isn't it?  not usable for installing ubuntu
<psusi> can't use the existing ext windows drivers because they don't preserve posix semantics
<Burgwork> psusi, it allows you to create and copy the filesystem for completely within windows
<psusi> you'd have to manipulate the block device directly
<Burgwork> psusi, but I agree with you that it is an icky mess to implement
<psusi> Burgwork: it doesn't preserve posix semantics... 
<psusi> i.e. it ignores the mode bits and owner
<psusi> those need to be preserved to correctly install the system
<mdz> BenC: what's your take on the iptables/patch-o-matic thread on kernel-team?
<BenC> mdz: sounds like we need to do something, but I don't know enough about it to give a good opinion of what that something should be
<zakame> early morning devs :)
<BenC> mdz: I'll research it over the weekend when I have some time
<psusi> BenC: you get a chance yet to have a gander at that tiny kernel patch I sent you?
<psusi> ( it's only 4 lines )
<mdz> BenC: thanks
<fabbione> mdz: most of the patches that are in patch-o-matic are crack.
<fabbione> they are not upstream because not ready to be in the kernel
<fabbione> but having the support for userland is almost costless
<fabbione> i think the iptables maintainer has been adding all that stuff just because it's partially already there 
<trappist> the recent patch, for one, has moved upstream, but the patch-o-matic addition in userspace isn't in agreement with the new kernel code, so it doesn't work
<fabbione> trappist: that's not what i said.
<fabbione> there is more than just "recent patch"
<trappist> recent is the only one I've taken a close look at in dapper
<fabbione> the issue imho are all the other crack modules that upstream is not taking because not ready yet
<fabbione> exactly
<fabbione> an analisys of one module can't talk for all the others
<fabbione> you need to look at all of them
<fabbione> one by one
<trappist> dropping the whole patch-o-matic thing would be fine, but we're still building the userspace iptables against an old enough kernel tree that a lot of stuff that now exists in the kernel won't work because userspace doesn't know about it, or is compiled against an obsolete version of it
<fabbione> do you realize that iptables are in sync between 2.4 and 2.6?
<trappist> I realize that the same iptables source will build against both trees, if that's what you mean, with a very different list of features
<fabbione> trappist: the basic and most important features are all there in both trees
<fabbione> the fancy modules might not be
<trappist> you can build a functional firewall with the iptables in dapper.  but quite a lot of fancy features have made their way into the linus tree that we don't have because we don't build it against a modern kernel.  I might never have noticed, but there's a bug filed against one of those features, and I took an interest.
<fabbione> do you have an example of such ipt_ that's in the kernel and not fully supported by our iptables userland?
<BenC> psusi: which one is that?
<trappist> just recent, the one in the bug (16831)
<fabbione> trappist: you saw one bug, that has been fixed in an -updates. that's all you know
<fabbione> and the problem was a path to the kernel headers
<psusi> BenC: the pktcdvd and udf fixes
<fabbione> that has been fixed
<Riddell> Mithrandir: today's kubuntu live CD gives me "user not known to underlying authentication module" is that known?
<trappist> fabbione: it hasn't been fixed.  the file that was missing is now there, but a rule with -m recent still throws an error.
<BenC> psusi: I replied I believe
<fabbione> Riddell: kdebase is FTBFS :)
<BenC> psusi: my main question was, does it break current userspace at all
<fabbione> trappist: ./kernel/net/ipv4/netfilter/ipt_recent.ko
<fabbione> trappist: this is from .12
<Riddell> fabbione: yeah, I know
<fabbione> trappist: and iptables Userland has been fixed for that
<Riddell> where is daniels when you need him
<fabbione> trappist: did you upgrade your system?
<trappist> yes
<Mithrandir> Riddell: what's the date of it?
<Riddell> 2006-01-10
<Mithrandir> Riddell: I thought I fixed that bug before then, bug me if it's not ok tomorrow
<psusi> BenC: nope... it just fixes a bug where udf wasn't saving the owning uid/gid of a file to the disc, fixes a bug where pktcdvd overflowed values > 128 for the packet length from the track info on disc, and allowed a larger maximum packet length
<Riddell> Mithrandir: ok, will do
<Mithrandir> Riddell: also, make sure that kubuntu-meta is installable.  If that breaks, you might get random old initrds which may or may not work in interesting ways.
<fabbione> trappist: works fine here
<fabbione> root@trider-g7:~ # iptables -A FORWARD -m recent --name badguy --rcheck --seconds 60 -j DROP
<fabbione> root@trider-g7:~ #
<Riddell> Mithrandir: looks to be fine
<fabbione> Riddell: afaik imake has been replaced. i think you only need to change your B-D
<fabbione> anyway.. time to head offline
<fabbione> good night everybody
<Mithrandir> Riddell: good, make sure to keep it that way. :-)  I know ubuntu-meta was broken this morning, so we had an extra run for me to debug some stuff.
<Mithrandir> Riddell: that was python-netcdf, so I imagine kubuntu was broken too
<csj> Mitario, hello, I am in the LiveCD now and if I want to disable auto login  gdm, I delete /usr/share/initramfs-tools/scripts/casper-bottom/15autologin but no effect :(    
<csj> are all files in  /usr/share/initramfs-tools/scripts/casper-bottom/ will be run when booting?
<Kamion> night all
<mdke> night Kamion 
<zakame> gn8 Kamion :)
<dholbach> good night Kamion
<psusi> BenC: how long ago did you reply?  because I have no gotten it yet
<BenC> psusi: like a day after you sent it, but no matter, the patch generally looks good to me
<BenC> psusi: have you sent it to linux-kernel yet? I'd be interested in their feedback. I think jens Axboe handles that code, so CC him
<mdke> elmo, Znarl, any chance of getting LaserJock docteam svn access soon?
<blue-frog> is it usefull to fill in a bug concerning totem not starting up in dapper? I have the feeling you are already working on that.
<Burgwork> blue-frog, have you looked for  a bug?
<blue-frog> Burgwork, haven't seen any looking like this one but after an update, the error msg changed that's why I had the feeling someone was already fiddling with it
<mdke> doesn't load here either
<mdke> "Could not close supporting library"
<Burgwork> file a bug
<blue-frog> that's before the update
<blue-frog> mdke after update there's something else, ok filling in it a bug
<mdke> blue-frog, do a search first :) i'm up to date tho
<mdke> not dist-upped tho
<Burgwork> it is always better to file
<blue-frog> talking to me about multimedia system selector, can't seem to find it, any hint?
<mdke> i think blue-frog was right to ask, it's probably part of a gstreamer transition or something
<mdke> blue-frog, gstreamer-properties
<blue-frog> coming from a failed to construct pipeline for xwindows
<mdke> blue-frog, #ubuntu can help more maybe
<blue-frog> not interested in solving it in #ubuntu, am testing dapper to see if i can help
<blue-frog> by finding things that don't work
<mdke> blue-frog, bugzilla then
<blue-frog> k
<blue-frog> last thing, is there a way in bugzilla to assign the bug directly to dapper? so far it creates it in ubuntu then i target fix to dapper and i reject the one for ubuntu, am i doing right?
<dholbach> blue-frog: just mention it's dapper
<dholbach> do you have gstreamer0.10-x installed?
<blue-frog> yes
<dholbach> ok
<psusi> BenC: ok, will do
* fabbione would like to have a word with the guy that did break networking....
<Nafallo> fabbione: is network-manager broken? :-P
<fabbione> Nafallo: no i don't talk about network manager
<fabbione> on 4 machines here.. not even lo is coming up
<fabbione> and i can see a lot of clutter at startup
<fabbione> the entire net is borked
<Nafallo> hmm
<Nafallo> sounds like I shouldn't reboot :-P
<Nafallo> fix coming tonight? :-)
<fabbione> Nafallo: sure.. do you have a patch?
<Nafallo> well, seems infinity fixes every trouble I would have had while I'm sleeping ;-)
<zakame> hm is LP down?
<Burgwork> zakame, so is the wiki
<zakame> gaah
<zakame> wb TheMuso 
<Nafallo> where is the artwork for printing my own Ubuntu business cards? :-)
* Nafallo found http://www.ubuntu.com/community/processes/newmember :-P
<Burgwork> Nafallo, no idea
<Nafallo> would be totally kewl to link it from that page or something? :-)
<HiddenWolf> And *who* is going to check that nobody is going to print those cards if he's not a member?
<Nafallo> sabdfl ofcourse :-)
* Nafallo ponders who the contact for those cards would be :-P
<Nafallo> jdub? :-)
<Burgwork> Nafallo, likely
<Nafallo> jdub: ping :-)
<Nafallo> BenC: btw, had any reports about machine freezes on amd64-k8? :-/
<mvo> elmo: can you please sync python-apt from debian/incoming? (override ok)
<BenC> Nafallo: yeah, from breezy
<Nafallo> BenC: nothing on dapper since the UP/SMP-kernels became one?
<BenC> Nafallo: nothing specific to amd64-k8, no
<BenC> Nafallo: is it reproducible?
<Nafallo> oki. I've had them since I installed the test-kernel and later the real deal. I don't know what else to blame.
<Nafallo> well, it's still happening daily if, but I have no idea how to make it happen :-P.
<Nafallo> s/\ if//
<BenC> Nafallo: have you been able to get a backtrace of any kind?
<Nafallo> nope. right of a sudden things just freezes and I have to kill the laptop with holding down power.
<BenC> tried sysrq?
<Nafallo> nope
<BenC> can't really do much unless I have some sort of back trace
<Nafallo> I should probably read about that. first time the kernel freezes for me on this laptop :-).
<Nafallo> so never needed to even use that :-P
<BenC> There's a page on the wiki about using it
<Nafallo> oh! kewl :-)
* Nafallo goes to find it :-)
<mdz> Nafallo: DebuggingProcedures
<Nafallo> mdz: thanks :-)
<Tm_T> does gnash (http://www.fsf.org/news/gnash.html) be included to ubuntu?
<HiddenWolf> Tm_T, it's just out man, give everyone a few days to check it out and make up his mind.
<Tm_T> HiddenWolf: yes, my point was to raise interest ;)
<HiddenWolf> Tm_T, it was sent as a global notice to everyone on freenode.
<HiddenWolf> Tm_T, I'm *quite* sure people know.
<HiddenWolf> And the first request is on the mailing list too. :)
<Tm_T> ...oh, true, I'm bit slow today
<Tm_T> HiddenWolf: =)
<ajmitch> putting new software requests in the right places helps too
<HiddenWolf> =)
<HiddenWolf> That too.
<Tm_T> ajmitch: true, I'm not requesting
<ajmitch> we get too many requests dropped in the motu channel & then left
<Tm_T> ajmitch: =)
<Tm_T> ajmitch: yes, asking but not helping with it, hurts sometimes
<dholbach> I'm off guys - have a nice evening.
<lifeless> night
<HiddenWolf> s/evening/night
<HiddenWolf> Goodnight. :)
#ubuntu-devel 2007-01-08
<Wikipedia-Gast> I want to ask a question
<hunger> Wikipedia-Gast: Shoot.
<Wikipedia-Gast> what should I ask?
<hunger> Wikipedia-Gast: Dunno. You wanted to ask a question.
<Wikipedia-Gast> why?
<gnomefreak> hunger: its a bot
<Wikipedia-Gast> poor gnomefreak
<jmr> Wikipedia-Gast is a long time troll, so you know
<bhale> yeah this is boring
<gnomefreak> its banned from all otehr ubuntu channels
<bhale> Wikipedia-Gast: please ask a question or move on
<Wikipedia-Gast> why is everything a bot, when it's not fitting in your picture`?
* mode/#ubuntu-devel [+o tseng]  by ChanServ
<tseng> gnomefreak: yeah?
<gnomefreak> go for it
<gnomefreak> :)
* mode/#ubuntu-devel [+b *!*@84-72-46-98.dclient.hispeed.ch]  by tseng
* Wikipedia-Gast was kicked off #ubuntu-devel by tseng (tseng)
<gnomefreak> s/bot/tro;;
<gnomefreak> troll even
<gnomefreak> tseng: you should have been able to +o under bhale
<tseng> gnomefreak: hm how?
<tseng> i didnt link the nicks
<tseng> too lazy
<gnomefreak> oh
<tseng> I should
<tseng> [notice(NickServ:NickServ@services.)]  Your nickname is now linked to [bhale] 
<tseng> rock
* mode/#ubuntu-devel [-o tseng]  by tseng
<gnomefreak> :)
<gnomefreak> makes life simple whne there are trolls that dont stop typing
<jc-denton> shawarma: thx, but i just need a config, so /boot i s fine too
<shawarma> jc-denton: Cool.
<mdke> bhale: tseng was a great nick!
<mdke> will he come back?
<bhale> mdke: no sorry
<mdke> :(
<Kryczek> hi there
<Kryczek> hoping to get a better response than in #ubuntu :)
<Kryczek> Firefox is unusable since the last updates
<Kryczek> the menubar is totally gone
<Kryczek> and yes I reset my settings and tried -safe-mode
<sistpoty> Kryczek: filed a bug report yet? (or looked if one is already there)?
<Kryczek> I searched google :p
<Kryczek> came to ask if you heard about that
<somerville32> Kryczek, try searching http://launchpad.net for the bug :] 
<theveginator> lots of activity going on here
<LaserJock> party central
<theveginator> everyone must be developing instead of talking about it
<Hobbsee> quite likely
<Hobbsee> and it's a sunday in most countries
<theveginator> true
<theveginator> so.....
<zul> which reminds me i have to go watch family guy
<Hobbsee> zul: *grin*
<Hobbsee> zul: how's xen coming along?
<_ion> Yay, new episodes are finally airing?
<zul> Hobbsee, almost done the base stuff
<Hobbsee> zul: nice :)
<tmh__> how does ubuntu create ready module .debs from the kernel source packages?
<tmh__> when I created my package with dh_make using the kernel module package type, it gave me a application.deb and an application-source.deb but now I have to install application-source and modules-asssistant -compile it on every one. I want a ready package.
<sladen> tmh__: they are rebuilt when a new kernel is rebuilt
<tmh__> so what? I have to rebuild the kernel itself as well?
<tmh__> can I do that in pbuilder?
<johanbr> tmh__: "fakeroot make-kpkg --initrd kernel_image" in the kernel source dir works well for me.
<tmh__> but I wouldn't want to install all the -dev stuff on my machine. can I run make-kpgk in pbuilder or does it run like that on itself?
<johanbr> It doesn't need pbuilder or anything like that, its dependencies are pretty light.
<tmh__> why didn't debuild / pbuilder include the library.so that was with the application? it's missing from the final .deb
<tmh__> I mean, is this a feature or have I screwed something?
<tmh__> nevermind.
<fabbione> morning
<Hobbsee> morning fabbione!
<somerville32> Morning! :)
<pitti> Good morning
<keescook> hiya pitti
<keescook> Dang, I must be up late.  :)
<fabbione> hey kees
<keescook> hiya fabbione 
<fabbione> keescook: once again? :)
<keescook> heheh
<keescook> was out at the bookstore getting a transit map for Sydney.  :)
<pitti> hey keescook 
<pitti> keescook: well, I got up pretty early
* keescook checks clock... yeah 7:40 there.  wow!
<fabbione> keescook: are you going to LCA?
<keescook> fabbione: yeah.  I'm not speaking, but IBM wanted me to go
<fabbione> keescook: ok...
<keescook> I've never been to Sydney; looks like a lot of fun.
<fabbione> keescook: yeah it's a nice city but i was disappointed by the opera house
<keescook> perhaps it was only built for postcards.  :)
<fabbione> cjwatson: did you ever get around to upload that module alias for anna?
<pitti> keescook: we had spent a week of holiday in Sydney, was pretty nice
<pitti> keescook: I had my first surfing lesson there at Bondai beach :)
<infinity> keescook: Going to swing by Melbourne and say "hi" while you're down here?
<pitti> hey infinity, how are you?
<keescook> pitti: nice!
<infinity> pitti: Alive, back at work...  Sort of.  You? :)
<infinity> (Well, already off for the day, actually)
<keescook> infinity: sure!  Only like 600km or something, right?  :)  You're not gonna come up for LCA?
<infinity> keescook: I was planning to speak at LCA, but Real Life got the better of me, and I'm not sure I'm keen on actually attending the conf.
<keescook> infinity: cool.  I was going to meet up with a few of the aussie Inkscapers; you should come on up.  :)
<infinity> keescook: Isn't Inkscape development based at Monash, in Melbourne?
<keescook> ???
<pitti> infinity: still waking up, but fine
<keescook> most of the dudes I know are in Brisbane
<infinity> Pehaps I'm thinking of some other equally funky open source app.
<Lathiat> not keen on lca? pfeh ;)
<jdub> not keen on lca?!
<jdub> Lathiat: more "thwack" than "pfeh"
<jdub> ;)
* mneptok jumps up and down on jdub 
<lifeless> pitti: haven't seen a reply from you on the apport discussion
<lifeless> pitti: just reminding you ;)
<pitti> lifeless: hi
<pitti> lifeless: which discussion?
<dholbach> good morning
<lifeless> pitti: handling crashes in e.g. cron-apt and apache
<pitti> lifeless: ah, right, bug 62316
<Ubugtu> Malone bug 62316 in apport "Provide GUI access to crash reports from root programs" [Wishlist,Confirmed]  https://launchpad.net/bugs/62316
<pitti> lifeless: the only idea I have is to check whether the current user is an admin, and if so, call gksu apport-gtk for him (the usual way through update-notifier); do you have something better in mind?
<fabbione> cjwatson: i took the freedom to upload d-i to catch up with the latest kernel, but can you confirm that there are no bzr branches for that package? i couldn't find it on code.l.n
* fabbione grins evily
<fabbione> ~ # ./bus /dev/sda1
<fabbione> disk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 :a
<fabbione> now we can modify sparc BIOS from d-i :)
<pitti> cjwatson: do you have some minutes today to sort out the approvals/accepting of the tzdata and gnome-system-tools SRUs?
<pitti> cjwatson: (status: tzdata/edgy uploaded, waiting for accept; tzdata/dapper waiting for approval; updated g-s-t with additional gksu fix awaiting approval)
<lifeless> pitti: did you see my email late last week ?
<fabbione> pitti: tzdata in dapper was already a separate package or was still part of glibc?
<lifeless> pitti: I think the use case we should aim for is 'apache crashes, the user [perhaps requiring the user to be an admin user]  gets a spider icon in the notification area, which when clicked takes them into apport [perhaps needing gtksudo there] 
<pitti> lifeless: I don't have a mail from you about that in my ubuntu folder
<pitti> fabbione: right, in dapper it was in langpack-locales
<pitti> fabbione: jbailey agreed to prepare a breezy update (where it was in glibc)
<fabbione> pitti: ok perfect thanks
<fabbione> cjwatson: glibc SRU doesn't need to wait for pitti :)
<pitti> cjwatson: so sorry, s_tzdata/dapper_langpack-locales/dapper_
<lifeless> pitti: it was to you, not ubuntu. 
<lifeless> pitti: one of the things I asked was, 'should we take this to ubuntu-devel' :)
<pitti> lifeless: right, 'martin.pitt@ubuntu.com' lands in my ubuntu folder
<lifeless> ah
<pitti> lifeless: u-devel@ WFM, although I'd also like to have it in the bug report
<lifeless> pitti: forwarded the last mail to you anyway
<pitti> lifeless: thanks
<lucas> [POLL]  What do you think of Christer Edwards' posts on Planet Ubuntu ?
<lucas> [A] You like them
<lucas> [B] You don't read them and find them annoying
<Fujitsu> C.
<lucas> [C]  You don't read them and don't care, there's no policy after all
<Fujitsu> Ah, B, then.
<lucas> what would be your C ? :-)
<Fujitsu> Something more negative than B :P
<Mithrandir> I'd go for D; I don't read them, but I could see them being useful.
<Mithrandir> so, I don't read them, but I like them. :-P
<cjwatson> fabbione: not only did I upload it, I told you at the time when I did.
<cjwatson> fabbione: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2006-12-21.html and search for preseed
<somerville32> I need a hug.
<Fujitsu> Mithrandir, I don't really find them suitable for planet.
<cjwatson> fabbione: latest kernel> fine if it's just the usual build/config/ changes. There are no bzr branches yet
<fabbione> cjwatson: sorry.. i forgot you did... 
<fabbione> cjwatson: it wasn't meant to be a rant.. 
<cjwatson> pitti: yeah, will do
<cjwatson> fabbione: glibc> noted
<fabbione> cjwatson: thanks a lot
* fabbione updates the spec
<somerville32> cjwatson, I fixed the patch for the SRU for mousepad. When might you have time to review it again?
<cjwatson> somerville32: I'll do it this morning
<somerville32> cjwatson, Thanks :)
<cjwatson> somerville32: bug number?
<pitti> mpt: I just had a quick talk with seb128 about the new 'Report a bug...' help menu entry in feisty; do you think that makes it 'too easy' for users to report bugs?
<pitti> mpt: it currently calls apport in bug mode, which collects the usual data and redirects the user to the /source/+filebug page
<pitti> mpt: it's what I understood from the BugReportingTool spec page
<Amaranth> eww, apport opened firefox instead of epiphany
<Amaranth> or does launchpad-integration do that bit?
<seb128> apport
<pitti> Amaranth: fundamental problem is that gnome-open doesn't allow you to specify 'open a new window'
<seb128> that's a "fix" from pitti
<seb128> I told I would send a patch but I didn't do it yet ;)
<Amaranth> you could read from gconf ;)
<pitti> Amaranth: if anyone gives me the shell rune for remotely open an epiphany window with an url, I'm happy to apply t
<mpt> pitti, if Ubuntu is getting more bug reports than you can keep up with, then I think you probably don't want to make it easier
<cjwatson> pitti: how does that deal with attachments?
<cjwatson> pitti: since AIUI the Malone cloakroom isn't there yet?
<pitti> cjwatson: that's why I develop it as a branch so far and didn't upload it yet
<pitti> cjwatson: the idea is to get it working at the sprint when we have Bjorn on board
<cjwatson> hmm, I thought you said it was in feisty
<pitti> cjwatson: yes, the launchpad-integration change is in feisty
<cjwatson> ah
<lifeless> hmm, what else did we do in december, qa wise.
<pitti> cjwatson: in feisty you can already report bugs, but with the usual 'please attach this file' dialog
<cjwatson> somerville32: approved, see bug
<somerville32> cjwatson: Awesome. Thanks :] 
<fabbione> cjwatson: thanks for glibc approval.
<Mithrandir> pitti: postgresql 8.2 binaries finally accepted, sorry it took so long
<pitti> Mithrandir: ah, thanks!
<cjwatson> seb128,pitti: updated bug 59946, approving patches
<Ubugtu> Malone bug 59946 in gnome-system-tools "Admin tools require admin group membership" [High,Fix committed]  https://launchpad.net/bugs/59946
<cjwatson> pitti: could you please reupload tzdata to edgy-proposed using debuild -v2006m-1ubuntu1, for a complete .changes?
<cjwatson> pitti: (rejecting so that you can)
<pitti> cjwatson: done; sorry
<lifeless> gnight
<Riddell> ooh, dholbach is back
* Hobbsee hugs dholbach in greeting
<bhale> wasabi: http://bugzilla.gnome.org/show_bug.cgi?id=392307
<Hobbsee> yay, dholbach!
<Ubugtu> Gnome bug 392307 in General "Beagle should not store indexes in users home directory" [Normal,Resolved: wontfix]  
* dholbach hugs hobbsee back
<dholbach> hiya Riddell
<dholbach> nightie lifeless
<bhale> wasabi: good read for you
<Riddell> dholbach: I changed libbtctl and kdebluetooth to compile against the new libopenobex, would be good to check it still works by someone who actually has bluetooth hardware
<Hobbsee> hrm.  i've only got one piece of bluetooth hardware, sorry..
<dholbach> Riddell: libbtctl works nicely
<dholbach> Riddell: i can try kdebluetooth too
<dholbach> Riddell: but both libs seem to be still in main, right?
<Riddell> dholbach: yes, it can be demoted now that nothing depends on it though
<dholbach> alrighty
<dholbach> good work!
<Riddell> dholbach: and if someone wants to see if everything that uses it in universe compiles against the new one we could get rid of it altogether
<dholbach> maybe a task for the ubuntu bluetooth team
<doko> Mithrandir (, cjwatson): does the recent bash upload hang somewhere?
<mod3d> hi
<Mithrandir> doko: 11:17:05 DEBUG   Verifying signature on bash_3.2-0ubuntu2_source.changes
<Mithrandir> 11:19:05 DEBUG   UploadError escaped upload.process                                                                                                                                                                   -> http://librarian.launchpad.net/5630561/joCPne6QYpIuSjlFRYCitl9jRPI.txt (GPG verification of bash_3.2-0ubuntu2_source.changes failed: No public key)
<mod3d> feisty currently very bugy or is it ok for a test installation on a half production system?
<crimsun> "feisty" and "production" are a very bad mix currently.
<mod3d> ah ok 
<Hobbsee> mod3d: please see #ubuntu+1, which is hte channel for development releases.
<crimsun> (and will continue to be until approximately the second week in Feb)
<mod3d> ok
<doko> Mithrandir: thats my usual key, used for the libglade-java upload today as well ...
<Mithrandir> doko: let my try to reinject it, then
<cypher1_> Keybuk: hi are you there
<Hobbsee> cypher1_: probably more helpful if you actually say what you want
<cypher1_> Hobbsee: hi.. no it was about the genpower and /usr/include/initreq.h issue
<cypher1_> Hobbsee: do you remember it ?
<dholbach> Riddell: kdebluetooth doesn't work for me - it'd probably help if somebody with a complete kde environment could have a look
<Hobbsee> dholbach: send me a bluetooth phone, then we'll talk :P
<StevenK> I have a bluetooth phone, but no bluetooth in my laptop
<cypher1_> i was doing merge of genpower.. but genpower depends on sysvinit..
* mnepton can test from the cert lab in ~18 hours
<Mithrandir> cypher1_: so it probably needs porting to upstart, then.
<cypher1_> StevenK: bluetooth dongle should be cheap
<mnepton> Bluetooth, check. Bluetooth phone, check.
<Hobbsee> StevenK: quick, drive over :P
<StevenK> Which involves having some spare cash.
<cypher1_> Mithrandir: that means making source code changes right ?
<StevenK> Hobbsee: :-P
<cypher1_> StevenK: :)
<Riddell> dholbach: ok, thanks, I'll try and find someone who can look at that
<Mithrandir> cypher1_: correct.
<cypher1_> Mithrandir: if we make the source code changes.. will that still be considered as merge ??
<dholbach> Riddell: thanks... if you need anything more of me, let me know.
<cypher1_> Mithrandir: i meant the lot of changes that *may* happen
<Keybuk> cypher1_: genpower uses the /dev/initctl socket?
<cypher1_> Keybuk: sorry have not checked
<Mithrandir> cypher1_: you'd probably want to talk to genpower upstream about making it possible to compile with upstart support (and if necessary add the support for what it needs to upstart)
<cypher1_> Mithrandir: ok..so if i make changes for making it work with upstart.. will it be acceptable ?
<cypher1_> Keybuk: i will check it when i am back at home. hope that is fine :)
<Keybuk> cypher1_: to make it work with upstart, you want to use the libupstart library found in the upstart source
<Mithrandir> cypher1_: well, it's not a merge per se, but I wouldn't get too hung up about that.
<cypher1_> Keybuk: ok thanks :) i will try using it
<cypher1_> Mithrandir: ok :)
<cypher1_> Is there any way to know the amount of downloads for a package in universe
<dholbach> BenC: did you hear about something like http://pastebin.com/854212 before?
<StevenK> popcon.u.c can give some vague numbers.
<geser> cypher1_: genpower uses /dev/initctl
<cypher1_> geser: thanks..
<cypher1_> geser: i will check it when i am back @ home
<geser> dholbach: hello, as the last uploader of devscripts, can you have a look at the debdiff in bug #76916?
<Ubugtu> Malone bug 76916 in devscripts "Add support for Ubuntu versioning to dch" [Undecided,Unconfirmed]  https://launchpad.net/bugs/76916
<Fujitsu> That's a very good idea, geser :)
<dholbach> geser: did you talk to julian about that?
<dholbach> geser: i'm quite sure he'd add it :)
<geser> dholbach: not yet
<dholbach> geser: i'm about to go out for lunch - i'll take a look at it afterwards
<geser> thanks
<tepsipakki> how big resolutions can usplash support?
<Keybuk> tepsipakki: any supported by svgalib
<tepsipakki> Keybuk: it uses VESA driver?
<Keybuk> yes
<tepsipakki> Keybuk: we have 24" and 30" monitors more and more, so it would be nice to see usplash on them :)
<tepsipakki> but maybe usplash just lacks a suitable theme
<Keybuk> it probably just lacks the theme
<Keybuk> you can do vesa at silly resolutions
<tepsipakki> is the artwork-team responsible for those? I can file bugs
<tepsipakki> 2560x1600 is pretty silly
<Keybuk> yes
<pitti> cjwatson: g-s-t uploaded, thanks for review
<ogra> ooooh
* ogra just found liubflashsupport 
<ogra> -u
<pitti> ogra: a working flash lib for amd64 and ppc? *cantbelieveit*
<ogra> http://pulseaudio.revolutionlinux.com/PulseAudio
<ogra> looks neat ... just building it here
<ogra> oh crap ... the package is full of .ex files, no copyright etc etc ... meh
<Mithrandir> pitti: gnash's in the repos.
<ogra> Description: <insert up to 60 chars description>
<ogra> grr
<Treenaks> Mithrandir: where? feisty? or only Debian?
<Mithrandir> Filename: pool/universe/g/gnash/gnash_0.7.2-1_amd64.deb
<Mithrandir> in feisty at least.
<pitti> Mithrandir: ah, is it any better than libflash-mozplugin?
<Treenaks> Mithrandir: ok.. I'm still on edgy here.. I'll wait a bit longer ;)
<Treenaks> (say, a month)
<Mithrandir> pitti: no idea, I don't like flash.
<pitti> me neither, but some sites just need it :(
<Mithrandir> none I've come across so far.
<Mithrandir> as in, none I care about.
<ogra> lucky you
<ogra> my users play children games online ....
<Treenaks> ogra: so make them grow up ;)
<Treenaks> wait..
<Mithrandir> I don't admin any desktops but the ones I use myself.
<ogra> haha
<ogra> Mithrandir, me neither, but i still get the bug reports and complaints if it doesnt work
<pitti> gnash is as crappy and non-working as libflash-plugin
<Treenaks> pitti: it works some of the time..
<Treenaks> pitti: which is better than not at all
<pitti> except that it crashed ffox after ten seconds
* pitti purges again
<Treenaks> ok, that's bad
<ogra> pitti, if you could prioritize mbr on your MIR todo list that would make the CD builds very happy :)
<pitti> ogra: ok, I'll have a review session today or tomorrow
<ogra> cool
<pitti> please ping me again tomorrow morning if I forget today
<ogra> its breaking lilo ... not a major thing, but important to fix before the herd
<ogra> BenC, kylem, didnt you release a fix for bug 62308 ?
<Ubugtu> Malone bug 62308 in linux-source-2.6.17 "Permission Denied on nfs clients for only some files" [High,In progress]  https://launchpad.net/bugs/62308
<ogra> (seems weird that people start using third party kernels to fix it)
<Hobbsee|NotHere> keescook: sydney is fun :)
<Hobbsee> lucas: B.  definetly B.  or perhaps D.
<Hobbsee> lucas: but then, waht's the target audience for planet anyway?  devs or users, or both?
<Hobbsee> seems like hsi posts belong more in forums than anything
<gnomefreak> is there a place i can search for packages in debian new?
<cjwatson> gnomefreak: 
<cjwatson> http://ftp-master.debian.org/new.html
<gnomefreak> ty
<fabbione> cjwatson: if you have a minute could we look at one bit of sparc64-installer together?
<Riddell> mvo: the dist-upgrade tool doesn't seem to run the gtk mainloop
<mvo> Riddell: oh? I will check that. are you working on the qt version of it?
<Riddell> mvo: yes
<Riddell> mvo: I mean it works, I just can't see any call to gtk.main()
<Riddell> there's a few gtk.main_iteration()
<cjwatson> fabbione: yes
<fabbione> cjwatson: network-console on CD is the last bit of that spec to go implemented (modulo the evaluation phase). is there anything i need to do to get it on server CD?
<fabbione> i am a bit afraid of breaking the seed magic when touching that stuf
<fabbione> +f
<cjwatson> fabbione: that's already done; it's in the installer seed, which is all you need
<fabbione> cjwatson: ok perfect. thanks
<mvo> Riddell: a gtk mainloop is run implicitely if a dialog is run (for example when information() or error() is called)
* fabbione moves sparc64-installer to implemented
<Riddell> mvo: aah, ok
<Mithrandir> pitti: can you update the script making language-support packages?  It still refers to ubuntulinux.org and has Copyright (C) 2004 Canonical Ltd.
<pitti> Mithrandir: oh, sure
<pitti> Mithrandir: however, I assume you don't want me to upload new versions for all of them just for that? 
<cjwatson> cjwatson@lithium:~$ isoinfo -lR -i ~/cdimage/www/full/ubuntu-server/daily/current/feisty-server-sparc.iso | grep network-console.\*deb
<cjwatson> -r--r--r--   2    0    0           54796 Nov 23 2006 [  41599 00]   network-console_1.9_sparc.udeb
<cjwatson> fabbione: ^--
<Mithrandir> pitti: nah, no need for a new upload.  Just noticed when I looked at the source package.
<fabbione> cjwatson: cool.. i did trust your word from the seeds :)
<pitti> yup, this affects the language-pack*, too
<pitti> Mithrandir: what's wrong with the copyright? should it rather be '2004, 2005, 2006, 2007'?
<Mithrandir> pitti: or 2004-2007, since the package is from 2007
<pitti> ok, WFM
<pitti> Mithrandir: committed; thanks for noticing
<Mithrandir> my pleasure
<iwj> mvo: Thanks for that url for the resulting menu data, btw.  Just what I needed right now, in fact.
<_ion>  would be a more correct dash than -, i think.
<mvo> iwj: cheers, glad to hear that
<ogra> hmm, what do i set as upstream author for sourcecode thats not GPL and has its copyright assigned to a company and no trace of an upstream author anywhere ? do i set the company name as upstream author ? or do i just leave it out ?
<Mithrandir> there's nothing stopping a company from being the copyright holder.
<cjwatson> (companies are legal entities)
<ogra> right, but what do i do with the author field in the debian/copright file ? 
<ogra> just ignore it ?
<cjwatson> it's just informational. Set it to the company, probably.
<ogra> ok
<ogra> to sad ... freely available source but adobe license so its forced to multiverse :(
<jdub> http://blog.secondlife.com/2007/01/08/embracing-the-inevitable/ <-- woot.
<Mithrandir> jdub: nice.
* Treenaks looks for the RFP
<seb128> for what?
<Treenaks> seb128: http://blog.secondlife.com/2007/01/08/embracing-the-inevitable/
<Treenaks> seb128: 2ndlife :)
<seb128> ah, k
<Mithrandir> doko,pitti: is db4.5 targetted for main or should I put it in universe for now?
* pitti has no particular urge for 4.5, unless being told so
<Mithrandir> source is universe, so it's universe then
<lucas> Hobbsee: I've mailed him privately, suggesting that he creates another planet targetted at tutorials, and that he posts weekly summaries on p.u.c
<Hobbsee> lucas: smart
<Hobbsee> lucas: tutorial planet and developer planet, type idea?
<lucas> well, we will see what he answers :-)
<Hobbsee> hehe
<Hobbsee> oh yes, which reminds me....i planned to get added to planet...
<Mithrandir> .. 19 NEW source packages.  I guess I won't get many more of those done today.
<zul> cool...big pointy stick block?
<Hobbsee> heh
* Hobbsee playfully pokes zul with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
* Mithrandir tickles Hobbsee, then goes to see to simira
<Hobbsee> hehe
* Hobbsee waves to simira 
<doko> Mithrandir: universe seems to be ok
<bddebian> Heya
<iwj> Strange.  My Mum's new laptop has a weird failure: after working with an SD card (builtin cardreader) and saying `unmount' and ejecting, the card doesn't work if reinserted.  Jan  8 14:46:55 friesland kernel: [17179790.484000]  generic_make_request: Trying to access nonexistent block-device mmcblk0 (248192)
* Mithrandir hugs seb128 
* seb128 hugs Mithrandir
<seb128> Mithrandir: what did I do? ;)
<Mithrandir> uploaded tracker.
<Mithrandir> like, five minutes ago
<seb128> ah right
<seb128> it's up to you to get it out of NEW now ;)
<Mithrandir> working on it.
<seb128> excellent
<ogra> hmm, intresting ... if i enable universe in my pbuilder it immediately installs console-common ... i wonder why 
<tepsipakki> does the recent d-bus security-update really need a reboot to get it in use?
<iwj> SD card problem> Hmm, it seems that this is already known as bug 53268.
<Ubugtu> Malone bug 53268 in linux-source-2.6.15 "On Thinkpad X60s and Z60 SD card reader doesn't work" [Undecided,Confirmed]  https://launchpad.net/bugs/53268
<pitti> tepsipakki: it is actually enough to /etc/init.d/dbus restart and restart your session
<tepsipakki> pitti: thanks a bunch.. I don't want to reboot 200+ machines just for that :)
<tepsipakki> pitti: it doesn't harm running sessions much?
<pitti> tepsipakki: it does, you'll break their gnome-vfs-daemons and in turn the volumes they display
<pitti> and probably two tons of other things that connect to dbus or hal
<tepsipakki> ok, well, that I can live with
<elmo> if you use n-m, that can also break
<elmo> I wish someone would beat some sense into d-bus upstream - requiring this kind of restart and/or reboot is utterly insane
<tepsipakki> these are desktops, so no n-m thank god
<_ion> elmo: Indeed.
<Keybuk> elmo: I've tried before, I was told it's not easy to transfer state of open file descriptors, etc.
* _ion uses n-m on his desktop boxes.
<Keybuk> I pointed them at the fact init is perfectly able to be restarted, but to no avail
<_ion> Irssi also does that. :-)
<tepsipakki> _ion: well, _static_ desktops :)
<_ion> /upgrade execs a new irssi, while keeping network connections open.
<cjwatson> and unfortunately losing scrollback
<Mithrandir> seb128: tracker rejected, but it should be relativetly easy to fix my points.
<_ion> cjwatson: There's a script for that.
<cjwatson> _ion: ooh. I wonder if it would work for a sarge->etch upgrade
<cjwatson> which is the next upgrade this irssi here will undergo
<seb128> Mithrandir: what are the points?
<_ion> cjwatson: /usr/share/irssi/scripts/buf.pl in the irssi package
<Mithrandir> seb128: wrong debian/copyright ; missing full text of the LGPL in the orig.tar.gz.
<Mithrandir> seb128: I just sent you an email about it.
<_ion> Tracker, as in Meta Tracker? Yay
<cjwatson> _ion: thanks
<Mithrandir> _ion: tracker as in beagle, but without the memory usage, yes.
<jdub> or the, you know, searching.
<_ion> ...and with a generic metadata database that apps can use to create a more integrated environment.
<Mithrandir> jdub: pft!  Who needs that?
<zyga> mvo_: ping
<_ion> There should be a generic "tag" widget just like the one in f-spot. Apps could then have shared tags for files.
<_ion> Using tracker as the database, of course.
<jdub> there should be a generic "amihotornot" widget. you could apply it to everything in the interface. using tracker as the database.
<_ion> That, too.
<Mithrandir> jdub: I think most of my files would be tagged cold, then. :-P
<jdub> gtk+ not using X dpi -> NOT!
<jdub> calendar on gnome panel clock -> HOT!
<_ion> It's not gtk's fault. Gnome-settings-daemon breaks it.
<jdub> it's mildly more complicated than that, but still unfortunate
<jdub> but it was more interesting than "crash report -> NOT!"
<heno> sfllaw: did you have a look at improving the ISO testing documentation? I've written some here: http://www.ubuntuforums.org/showthread.php?t=331123 but I'm sure it could be improved
<mvo_> hey zyga! 
<mvo_> zyga: happy new year to you :)
<iwj> mvo_: There's no problem with me making getMenuData read and edit existing menu-data/*.desktop files as well as merely sometimes overwriting them, is there ?
<mvo_> iwj: there shouldn't be, that is what addPopconData.py is doing 
<iwj> Oh, yes, so it is.
<mvo_> why would you overwrite them?
<iwj> My thing wants to be in getMenuData because getMenuData is already churning through all the .debs.
<mvo_> right. it should be fine to just mangle the extracted desktop file
<mvo_> in fact, add popcon data could/should probably be part of that run too
<iwj> getMenuData is written to overwrite any of the existing entries in menu-data which disagree with the package's data.
<mvo_> oh, I now see what you mean. what would be the reason to read/edit instead of overwriting? fix wrong mime types in the desktop file in the archive?
<iwj> Well, in my case I want to add a field even to existing desktop files.
<iwj> So I merge the field value (which I get from the .deb) with the rest of the desktop file from menu-data.
<persia> Mithrandir: geser suggests I should ask you to give-back rapidsvn.  It built locally for me, although all the buildds failed last month due to an insufficient version of libsvn (which has since been fixed).
<sfllaw> heno: Thanks.  I have.
<mvo_> iwj: the getMenuData code adds some field (X-AppInstall-Package for example) already after the extraction. why would you need to read the old desktop file first before writing the new one? the only reason I can think of is to correct incorrect data in the desktop file of the package
<mvo_> or am I missing something?
<iwj> The gnome-app-install source contains a directory menu-data with a bunch of desktop files for packages which don't have their own, right ?
<iwj> So those desktop files I have to read (to find which package they belong to) and perhaps edit.
<mvo_> iwj: the ones that do not have a desktop file in the package are in menu-data-additional/
<iwj> And given that, it's easier to just edit all of the desktop files in menu-data near the end rather than treat differently the ones getMenuData generated.
<iwj> mvo_: Err, right.
<heno> sfllaw: cool! Are you ready for a flood of ISO testers from the forums? :)
<mvo_> iwj: menu-data are all from the archive (also some overwrites are applied there)
<Mithrandir> persia: given-back.
<heno> sfllaw: you should probably register an account there, btw
<iwj> Oh, I see.  You mean that I only have to read the ones in menu-data-additional since the others are autogenerated.
<mvo_> iwj: oh, so you where talking about menu-data-additional all the time :) ? let me re-read the disussion then 
<mvo_> iwj: yes
<iwj> I thought that the distinction between menu-data and -additional was something to do with main/universe.  Evidently I was wrong :-).
<persia> Mithrandir: Thanks.
<mvo_> iwj: sorry for that misunderstanding, I will put it in the README file 
<sfllaw> heno: Will do.
<iwj> So err, I can fix up the menu-data ones fine but I need to edit menu-data-additional too as I say.
<iwj> So getMenuData doesn't currently know anything about the menu-data-additional directory.
<mvo_> iwj: yes, the m-d-additional dir is maintained manually (by-hand) because it is rather small. 
<iwj> Right.  But I do want to add this extra field automatically.  May I do that ?
<iwj> I suppose I mean: is it OK if I make   getMenuData menu-data   edit stuff in menu-data-additional too, or is that too horrid ?  Otherwise the cron job has to change.
<mvo_> iwj: that should be fine as long as it edits only the parts that it is concerned with (X-AppInstall-Codec)
<iwj> Right.
<iwj> cdbs -= SHORT_MAX
<zyga> mvo_: hey, thanks :-)
<zyga> mvo_: I had some minor patches to command-not-found and I was wondering if you could merge them to feisty?
<mvo_> zyga: certainly. I uploaded a new version recently, if your patches were in your bzr tree at friday, it is already in feisty 
<zyga> mvo_: yeah they were :-)
<zyga> mvo_: cool, thanks :-)
<zyga> mvo_: I registered the branch at lauchpad, if you used the same branch then everything is okay
<mvo_> zyga: I think the version in feisty is now pretty complete and really rocks 
<mvo_> zyga: I used the one in lp, but I will double check just to be sure
<zyga> mvo_: it still has one fixable (easy) bug that I plan to work on but not for feisty probably
<mvo_> zyga: you may want to merge from my branch as well to get the latest changes
<mvo_> zyga: which one is that?
<zyga> it does not cover cross package symlinks as it used to
<zyga> I recently noticed that many packages actually used those :P
<zyga> mvo_: I'll merge as soon as I'm at home
<mvo_> right. I always thought those are s a corner case :)
<zyga> mvo_: cross package symlinks add proper packages for gcc for example 
<mvo_> I see
<iwj> python--
<iwj> ';'.join([x where x in codeclist] 
<iwj> )
<iwj> I mean, really.
<Keybuk> hmm?
<Keybuk> s/where/for/ surely?
<Keybuk> and you can omit the [ ] s, and make it a generator expression
<Keybuk> and x for x in makes no sense unless you also have if :p
<iwj> Sorry, yes.
<Keybuk> ':'.join(codeclist)
<iwj> Oh, that does work.  I mistyped it when I tried it earlier.
<iwj> iwj--; python++
<Keybuk> [x for x in ...]  can be used to "turn something into a list"
<Keybuk> but for that list(...) makes it far more obvious :p
<Keybuk> that's only useful where you have an odd function that expects a real list, not an iterable
<iwj> Keybuk: Right, but I mistook an earlier error message for complaint from join that it wasn't getting a real list.
<_ion> I wish someone invented a programming language with all the cool stuff from Lisp, without the syntax looking like a data structure. It's probably not possible, tough. :-(
<iwj> Actually it was just a bug in my test case.
<iwj> _ion: Sounds like a contradiction in terms to me - Lisp's biggest feature is that its code can be data for manipulation by Lisp.
<_ion> Hence the second sentence.
<_ion> s/tough/though/
<pitti> ogra: mbr approved for main
<ogra> pitti, thanks !
<iwj> X-AppInstall-Codecs=0.10:decoder-audio/x-sid;0.10:element-mpegdemux;...
<iwj> Yay!
<pitti> iwj: first time it works? congrats!
<pitti> getting this to work will be rad
<twb> Mithrandir: nag, nag
<iwj> Well, that bit of it is what I've been doing today.  There are gaps in the chain of stuff still.
<pitti> iwj: so the codec packages have a new debhelper bit that register their shipped codecs somewhere and this list ist then put into some gstreamer lib?
<iwj> Yes, they have to call dh_gstscancodecs which is in gst-tools.
<iwj> Err, gstreamer-tools.
<iwj> That leaves a dropping in /usr/share, which getMenuData.py picks up and puts into the .desktop files in menu-data* and now I have to edit setup.py to build a gdbm like for the mime map.
<iwj> But I have to rush off for dinner now.  Goodnight all :-).
<pitti> iwj: bye Ian
<cjwatson> Mithrandir: do you think we could move each of Herd 4 and Herd 5 one week later? at the moment they collide with seb128/dholbach upload-fests of new GNOME releases
<cjwatson> the other dates seem fine
<dholbach> if freeze set in on 11th or 12th, I think we should be fine
<dholbach> "herd2 freeze"
<Mithrandir> yeah, I guess we could.  I talked with seb128 about it and he seemed fine with them working madly on monday to make it in and freeze on tuesday, but if you prefer to move it, that's ok with me
<cjwatson> dholbach: like I say, Herds 2 and 3 seem fine as they are ...
<cjwatson> or maybe you mean 11th February for Herd 4
<cjwatson> Mithrandir: if seb is happy and the freeze is short, that's OK - just wanted to make sure it had been taken into consideration
<cjwatson> since there have been problems in the past
<cjwatson> Mithrandir: I've linked to the GNOME release schedule from ours
<dholbach> oh ok
<mdke> dholbach: hi!
<dholbach> hiya mdke!
<Mithrandir> cjwatson: the idea was "see how it goes" and adjust if it blows up, basically.
<mdke> dholbach: can you do an ubuntu-docs upload for feisty (freezes permitting, not sure what's happening atm)? I sent you a mail during the vacation
<dholbach> mdke: i thought i responded to that, no?
<dholbach> mdke: i will do an upload now, no problem
<mdke> dholbach: I didn't get it :( Was there a problem with it?
<dholbach> mdke: I'll have another look and see what happened
<mdke> thanks dude. Tomorrow is fine if you are finishing up
<dholbach> mdke: no problem - i scripted a part of it and have another build running anyway
<mdke> dholbach: scripted something for ubuntu-docs?
<dholbach> mdke: check sources out, delete unnecessary parts, download the old package for comparison, stuff like that
<mdke> dholbach: oh, brilliant
<LaserJock> mdke: yet another "big brain" kinda guy ;-)
<mdke> Canonical is full of em
<dholbach> mdke: i changed the version number to 7.01.1, ok?
<dholbach> mdke: only change i did
<mdke> dholbach: sure ting
<dholbach> rock
<cjwatson> automation> habits of the busy ... at some point you just can't do it all by hand any more
<dholbach> mdke: it FTBFS - i'll have a look at it tomorrow - is that ok with you?
<cjwatson> Mithrandir: ok, let's please remember to squeeze in a review of how it went between Herds 4 and 5 in order to avoid making the same mistake twice in a row
<mdke> dholbach: sure... I'll have a look myself too
<cjwatson> there's some slack in the schedule there
<dholbach> mdke: cp: canno stat ubuntu/menus/C/*.xml': No such file or directory   - probably easy to fix
<mdke> dholbach: oh, absurdly, yes. I'll have it done this evening for you tomorrow
<mdke> sorry about that, some changes since I mailed you
<dholbach> no problem
* dholbach hugs mdke
* mdke hugs back. Happy new year
<dholbach> thanks a lot - to you too! :)
<Lure> Mithrandir: when do you plan to freeze for Herd 2
<Mithrandir> Lure: tomorrow.
<Lure> Mithrandir: thanks, will work then tonight to get new kde powermanager in ;-)
<dholbach> Mithrandir: it'll depend on when you're going to freeze if we get 2.17.5 in or not - there are still some tarballs on the list
<Mithrandir> dholbach: any idea when you'll get to them?  Tonight or tomorrow?
<dholbach> i'm about to finish for today
<dholbach> seb128 too
<dholbach> and I don't know how many tarballs are still being rolled
<dholbach> good night everybody
<mdke> night
<seb128> Mithrandir: when do you want to freeze?
<seb128> Mithrandir: GNOME 2.17.5 will be packaged by tomorrow end of the afternoon, not today, they have not rolled all the tarball yet
<Mithrandir> seb128: ok, so if we freeze everything but gnome tomorrow mid-day (UTC), that should work.
<seb128> that should be fine, yep
<seb128> most of GNOME should be done by midday too
<Mithrandir> cheers.
<twb> Mithrandir: nag, nag
<Mithrandir> twb: can you nag me in the morning instead, like in 12 hours? :-P
<Adri2000> seb128: (I think you are the right person to ask) fam dependencies should be replaced with gamin, right? perhaps gamin | fam is better?
<twb> I can surely try
<seb128> Adri2000: what package is that for?
<seb128> Adri2000: a | looks about right, though an app should not have to Depends on the daemon
<Adri2000> doodle (universe), bug 78497
<Ubugtu> Malone bug 78497 in doodle "doodled package can't be removed" [Medium,Confirmed]  https://launchpad.net/bugs/78497
<seb128> Adri2000: well, if the app links with libfam it has to Depends on it
<Adri2000> the binary package doodle depends on libfam-dev and the binary package doodled depends on fam
<seb128> whatever links with libfam should Depends on it
<Adri2000> when I try to install fam, it wants to remove a bunch of packages
<Adri2000> gamin Conflicts: fam
<seb128> you should build with libgamin rather than libfam
<Adri2000> ok
<Adri2000> (in fact, the source package build depends on libfam-dev, a binary package doesn't depend on a -dev usually :)
<cjwatson> build-depend on libgamin-dev then
<cjwatson> if you do that then libgamin0.shlibs will produce a libgamin0 | libfam0 shlibdep for any object needing libfam
<cjwatson> (as opposed to the libfam0 shlibdep you get by build-depending on libfam-dev -> libfam0)
<Adri2000> :%s/fam/gamin/ in debian/control seems to fix the bug indeed :)
<mdke> heno: hi! around for a chat?
<heno> mdke: sure
<martii> ho folks noone was able to help me on #ubuntu
<martii> I do net install
<martii> how can I force proxy? for installation?
<martii> as I was not asked about proxy during installation
<lifeless> Mithrandir: got a second ?
<Mithrandir> lifeless: sure
<lifeless> https://wiki.ubuntu.com/LiveCDShareThisCD <- has anything been done on this ?
<cjwatson> martii: putting mirror/http/proxy=http://foo.bar:8080/ on the kernel command line at boot time should do it
<lifeless> Mithrandir: Looking to get livecd netbooks working for LCA, dont care about booting of the CD to share it, just about the clients booting live and then installing locally
<martii> do i need all of those or just one?
<cjwatson> martii: or use expert mode
<martii> I mean mirror http
<cjwatson> martii: all of what?
<Mithrandir> lifeless: no, not really.  There are some patches in the Debian casper package to make it easier, but I haven't merged them yet.  Hoping to do so tomorrow.
<cjwatson> that's a single argument
<martii> in expert mode it asks me too much questions
<martii> ok thanks
<lifeless> Mithrandir: and for some reason your name came up w.r.t. to it
<cjwatson> martii: mirror/http/proxy=URL_OF_YOUR_PROXY
<bddebian> Folks is there somewhere in the Debian policy about requiring manpages??
<martii> just checking it now
<mjg59> bddebian: Yes
<cjwatson> martii: please pass that on to #ubuntu so that they know next time
<martii> ok
<cjwatson> bddebian: section 1.2
<lifeless> Mithrandir: what do they do, do I need to roll a custom casper right now to consider this ? (the clients will want to be running and installing edgy)
<cjwatson> bddebian: er, section 12.1
<lifeless> Mithrandir: I'll be doing the work to make this happen, so I'm just gathering intelligence right this second :)
<martii> cjwatson: doesn't work
<bddebian> Thanks mjg59, cjwatson
<martii> cjwatson: I gave it IP:port
<martii> and I got info about bad archive mirror
<Mithrandir> lifeless: you need to change the script scripts/casper in the casper package to mount the root fs (probably based on some kernel param you get from /proc/cmdline) and then unionfs mount a tmpfs on top.
<Mithrandir> lifeless: so yeah, you need to make a custom initrd.
<lifeless> ah, its doesn't use initramfs ?
<Mithrandir> it does.
<Mithrandir> casper is just a custom initramfs.
<lifeless> ok
<lifeless> np
<Mithrandir> if you don't pass boot=casper to a casper initramfs, it'll behave just like a normal initramfs (but is a little bit bigger)
<lifeless> so, add boot=casper to the tftplinux configuration, and have the script scripts/casper altered to know the nfs path to the root fs.
<Mithrandir> yeah.
<Mithrandir> and hope unionfs and nfsroot doesn't blow up too badly.
<lifeless> yah
<lifeless> I'm going to do a few test installs today I hope, see if its fucked or not.
<bddebian> cjwatson: Though I have an upstream author that refuses to do a manpage because it has a gnome help page in docbook.  What do I do about that?
<lifeless> if its totally fucked, I'm wondering about having root use the iso image over NBD
<bddebian> And docbook-to-man pukes :-(
<lifeless> as a way to work around the unionfs issues
<mdke> bddebian: that's no reasoning at all!
<Mithrandir> lifeless: yeah, that should work too.
<lifeless> ok cool, I was wondering if I was on crack there or not.
<Mithrandir> lifeless: you get the additional joy of doing dhcp &c in the initramfs too, but I presume you know that.
<bddebian> mdke: Well his thinking is that it's a Gnome only app so why a man page?
<Mithrandir> including having loads of network drivers there.
<lifeless> Mithrandir: bringing up dhcp is done via ip=dhcp to the kernel? or does the casper initramfs know enough ?
<mdke> bddebian: you could recommend to him that it would help his app get used in non-Gnome installations.
<martii> cjwatson: works :( sorry I must have mispelled something
<martii> cheers
<lifeless> Mithrandir: yes, I knew that that would be an issue
<Mithrandir> lifeless: kernel doesn't do dhcp for you when you're using initramfs, AIUI?
<Mithrandir> so the casper script must do that.
<lifeless> Mithrandir: https://help.ubuntu.com/community/Installation/OnNFSDrive has been updated for dapper and reckons that you can have the kernel do it with stock dapper initramfs
<bddebian> mdke: Well it's a gui app regardless so I'm not sure I'll win that arguement :-(
<mdke> bddebian: fair enough. That's a much better argument
<lifeless> Mithrandir: that said we have udev to get network cards, probably just need to add dhcpclient to the initramfs
<Mithrandir> lifeless: it's probably a matter of copying and pasting stuff from the nfsroot script, yes.
<lifeless> yay copy n paste
<Mithrandir> if it's a one-off, there's no real point in refactoring to extract common bits and such.
<lifeless> Mithrandir: well, no point in wasted effort either.
<bddebian> mdke: So what do I do about it, anything?  Add a lintian override?
<lifeless> s/wasted/duplicated/
<mdke> bddebian: fraid I have no clue about Debian policy
<bddebian> Me either :-)
<bddebian> Well I have a "clue" but certainly don't know it all :-)
<bddebian> cjwatson: You have any thoughts sir?
<cjwatson> bddebian: do not add lintian overrides unless it's a case where lintian is generally right but this is an unusual exception. This is not such a case.
<cjwatson> bddebian: if you can't write a man page for it, then just leave the lintian warning there so that somebody else is more likely to notice and write a man page in future. Don't ever hide real problems under lintian overrides.
<cjwatson> bddebian: but ideally, write a man page; it's not hard
<bddebian> I know it's not hard but it seems superfluous.. But hey, what do I know :-)
<lifeless> bddebian: why would it be superfluous?
<cjwatson> it's not superfluous if you're in the habit of typing "man thing" to find out how thing can be invoked
<cjwatson> (many GUI applications can usefully be invoked from the command line)
<mdke> bddebian: suggestion for the contents: "See the manual in yelp"
<cjwatson> bddebian: if upstream disagrees, fair enough, but it would hardly be the first time that a distribution has written a man page when upstream didn't want to bother
<cjwatson> mdke: it's usually possible to write something more useful than that with minimal effort
<mdke> cjwatson: I didn't mean "entire contents"
<cjwatson> ohhh, sure
<cjwatson> s/ohhh/oh/
<cjwatson> bddebian: you don't have to argue it with upstream if it is hopeless; you can just shove it in the debian/ directory
<bddebian> cjwatson: I know, I know, I have written several.  It just torks me :-)
<cjwatson> deal :-)
<mdke> cjwatson: thanks for your SRU review today, btw.
<cjwatson> np
<laurelin> why
<mdke> laurelin: can you be more specific?
<_ion> laurelin: mu
<laurelin> muh says a cow
<laurelin> why
<laurelin> why
<mdke> laurelin: enough now, for queries on existence you can use #ubuntu-offtopic
<laurelin> poor mdke
#ubuntu-devel 2007-01-09
<keescook> has anyone played with the vmware player in feisty?  All the fonts are busted, and I can't figure out why.  :(
<ogra> keescook, i tried it some (6 probably) weeks ago ... worked flawless back then 
<keescook> ogra: I'm convinced it's my own fault somehow.. but I don't even know how to debug it.  I've tried messing with locale settings, etc.  no luck.
<keescook> but, it's only the player itself, so I just lick on all the "OK" icons, and I've got my VM running.  :)
<ogra> i know mvo packaged it in dapper, he probably has an idea or knows someone to point you to
<keescook> (heh: breezy VM image update: "210 new updates found")
<keescook> ogra: cool, thanks, I'll see if I can catch him tomorrow morning.
<lifeless> anyone around who knows how to make an initramfs have all modules ?
<HrdwrBoB> it does already..
<HrdwrBoB> or it used to
<ogra> lifeless, initramfs.conf has a variable for that iirc
<ogra> (in /etc/initramfs-tools/initramfs.conf)
<lifeless> ogra: thanks!
<ogra> lifeless, btw, wats planned wih the website of hwdb.ubuntu.com ... its not working at all ... is that wanted by you and mdz or should i try to fix it ?
<ogra> i understand that we dont want full access until the data is stripped ... 
<ogra> but the page used to show some basic info like CPU, RAM and graphcs adapter ...
<lifeless> ogra: problem is that there is no 'all', just partial solutions :(
<ogra> and some people seem to use it 
<ogra> right ... 
<lifeless> hmm, I'll try comma separated, see if that works...
<ogra> but the partial solution suddenly just stopped working from a user POV
<lifeless> ogra: I'm still talking initramfs sorry
<ogra> ah, ok
<lifeless> ogra: w.r.t. the hwdb I understand cr3 is working on something with a real db
<lifeless> its not desired to be completely functionless, but until we sort out the privacy aspects, the site cant really work - which is why the data is moved to a different machine, where the ubuntu core folk can login and grep the reports
<ogra> ... /usr/share/initramfs-tools/hook-functions has the module loading functions it should be easy to modify them to just load all modules ... (i even think the "most" option dos it )
<ogra> ok, understood ...
<lifeless> most doesn't :)
<lifeless> still, net will do, I just need to get the magic invocation to preserve my personal initramfs
<lifeless> - building a LiveNetBoot
<ogra> ah
<ogra> well, netboot should be what you want then ... actually LTSP should e what you want
<ogra> :)
<lifeless> ogra: ah, but I want to boot the regular livecd, not edubuntu ;)
<lifeless> ogra: that is, run out of the squashfs etc. So I need casper and so on
<ogra> well the initscript of an ltsp client is pretty similar to casper :)
<lifeless> really, unionfs etc ?
<lifeless> because, I have this working except for ethernet detection. Something funky with udev.
<ogra> no, unionfs doesnt like nfs ...
<ogra> its readonly mounted nfs root where we bind mount the writeable parts to a tmpfs
<Lathiat> i was using unionfs to join 4 mounted hard drives together to save hunting around one ach one and it died quite often especially when writing
<ogra> then run similar scripts to casper that configure X, sound etc ...
<lifeless> ogra: yeah, the nfs gets mounted readonly to reduce unionfs<->nfs flitches
<ogra> well, initially we mounted it readonly out of security reasons ... 
<ogra> https://wiki.edubuntu.org/LTSPFatClients should give you a netbooted workstation ... 
<ogra> (drop the edubuntu-auth-client parts and just make sure t copy over your servers /etc/passwd to the chroot if you dont want to set up ldap ...
<ogra> )
<ogra> (look at the code section at the bottom)
<lifeless> yah
<ogra> oh, and LTSP != edubuntu ;)
<lifeless> ;)
<ogra> ltsp is ubuntu stuff ....
<ogra> edubuntu is just the reference implementation where i prove that its possible to have it properly running right away out of the box ....
<ogra> hmm, where is m reciept mail for the upload i did 30 min ago ... 
<bhale> ogra: i havent been getting mail from -changes since this morning
<ogra> ah, k then i blame LP and wait until tomorrow
<ogra> its not urgent anyway ... its just that i'm german .... we're reciept addicts :)
<Hobbsee> ogra: soyuz probably ate it again
<ogra> https://launchpad.net/ubuntu/feisty/+queue shows it, so i'm fine ...
<keescook> good evening folks, I gotta go make dinner.  :)
<bddebian> Heya
<_ion> From deskbar-applet's changelog.Debian:     - Prevents binding of keys a-z and shit-a-z.
<_ion> :-)
<lifeless> I wonder if calling udevtrigger from initramfs is very evil, or just mildly evil.
<lifeless> ogra: so its working anyhow, just needed to get the net devices detected.
<lifeless> ogra: what does ltsp use to trigger that? udevtrigger + udevsettle ?
<ogra> udev, yes 
<ogra> i didnt touch that area specifically, it just works :)   
<bhale> Ubugtu: seen geser
<bhale> !seen geser
<bhale> yawn
<Hobbsee> bhale: [15:04]  [Notice]  -SeenServ- I last saw geser (n=michael@85.25.108.73) 3h 37m 15s ago, quiting: "Leaving"
<Fujitsu_> bhale, it's ubotu that does the !seen stuff, and it's not meant to be in #-devel.
<bhale> hm ok
<bhale> sorry.
* bhale hugs Hobbsee 
* Hobbsee hugs bhale 
<Hobbsee> :)
<Solarion> heya bhale
<bhale> hello
<fabbione> morning
<somerville32> morning
* Hobbsee drops icecubes down fabbione's back in greeting
* fabbione wakes up
<Hobbsee> hehe :)
<_ion> summon dholbach
* somerville32 shakes a circle of salt around himself.
<hype> http://kmwarren.imarichkid.hop.clickbank.net
<cjwatson> lifeless: ?
<lifeless> hi
<lifeless> so I have implemented a manual version of https://wiki.ubuntu.com/LiveCDShareThisCD for LCA
<lifeless> that is, I have a machine which serves out netboot casper with the squashfs from the edgy CD
<lifeless> everything except ubiquity seems to work ok. ubiquity fails to copy over the running image - it goes straight from 'formatting partition' to 'applying language'
<lifeless> and languageapply fails because /etc/default is missing
<cjwatson> the latter is a red herring, of course
<cjwatson> ok, so there are several things you need to do
<lifeless> where should I look to find out what is going on, so I can fix it. the install is rather opaque :(
<cjwatson> firstly, is this edgy?
<cjwatson> oh, yes, it is
<cjwatson> so in edgy, there's a kernel bug which means that you can't just leave the image mounted on /rofs
<cjwatson> which is what ubiquity used to use as a copy source
<lifeless> hmm, I'm not sure that its being left on /rofs anyway
<cjwatson> instead, you have to teach ubiquity how to mount it for itself; it's in scripts/install.py:mount_source (and umount_source)
<cjwatson> it won't be - we changed that at the 11th hour before release
<lifeless> oh
<lifeless> so the install.py mount_source is trying ot mount the cd rather than knowing to go to the NFS share ?
<cjwatson> there are also a few places in scripts/install.py that look for manifests in /cdrom/casper/; you'll have to teach those to look elsewhere
<lifeless> is the source the squashfs ?
<cjwatson> correct, it has no idea of how to do it over NFS
<lifeless> I can make the cd be on /cdrom, thats easy
<cjwatson> if you make the CD be on /cdrom, that will save you a fair amount of pissing about
<lifeless> doing...done
<cjwatson> the kernel bug in question was to do with multiply-mounted squashfses; I don't think your approach will trigger that
<lifeless> I have 17-10-generic anyhow, is that fixed ?
<cjwatson> that's edgy's kernel. no.
<cjwatson> we had to work around it literally the day before release
<cjwatson> anyway, with a fake /cdrom it should all be happy - let me know if it isn't
<cjwatson> #ubuntu-installer maybe, as it's quieter
<lifeless> k
<lifeless> not that this is a riotous place right now ;)
<cjwatson> true, but it will be later :)
<lifeless> jdub: craptop just installed via the net thanks to cjwatson's pointer :)
<lifeless> jdub: 7 minutes end to end
<macd> is there any ETA on edgy w/xen supporting more than one domU >?
<lifeless> macd: it does now ?
<macd> yes but 2 domUs locks dom0.
<macd> its a known issue, Im wondering if there is a ETA in a fix
<macd> on*
<fabbione> macd: you want to talk to zul on ubuntu-kernel
<macd> tyvm
<dholbach> good morning
<somerville32> Whats the e-mail address for rt again?
<fabbione> rt@admins.c.c
<somerville32> thanks
<fabbione> admin.c.c
<fabbione> sorry
<lifeless> jdub: https://wiki.ubuntu.com/LiveCDShareThisCD
<fabbione> this is interesting...
<fabbione> i need to hit partioner a few times before i can actually use it..
<lifeless> try moving the mouse outside the window and back into it
<lifeless> does that make the button respond more easily ?
<fabbione> cjwatson: i have a strange bug in d-i.. i would love your help to look at it when you are awake
<fabbione> lifeless: i am in text mode..
<lifeless> fabbione: ! oh
<lifeless> cjwatson is heading to London
<fabbione> lifeless: yeah it's ok.. i am not in a hurry
<fabbione> and i think it happens only in a specific case
<fabbione> mount /dev/hdc /cdrom
<fabbione> mount: /dev/hdc is write-protected, mounting read-only
<fabbione> mount: Mounting /dev/hdc on /cdrom failed: Invalid argument
<fabbione> doh!
<dholbach> heya Zdra
<Zdra> hello :)
<pitti> Good morning
<Mithrandir> pitti: could you make all the language-support source packages contain a full copy of the GPL, please?
<Mithrandir> the packaging there is licenced under the GPL, but they don't contain a copy of it, which they should.
<Mithrandir> also, good morning. :-)
<pitti> hi Mithrandir 
<pitti> Mithrandir: why do they need a full copy, when a pointer to /usr/share/common-licenses/GPL suffices for all other packages?
<pitti> oh, *source*
<pitti> Mithrandir: sure, will do
<Mithrandir> yes, source package.  The binaries are fine.
<pitti> Mithrandir: committed to langpack-o-matic; thanks!
<Mithrandir> pitti: cheers.
* pitti uploads some new support packages
<pitti> Riddell: do you plan to upload a new amarok and/or new qt3/4 soon?
<pitti> Riddell: I need to do some rebuilds for libpq4 -> libpq5 transition
* dholbach hugs pitti
<Mithrandir> pitti: can you hold those until after herd-2 is out?
<pitti> Mithrandir: hm, already uploaded the first one...
<pitti> (cyrus-sasl2, shoulnd't be on the CD)
<Mithrandir> pitti: ok, please leave it at that, then?
<pitti> Mithrandir: sure, I can stall them
<Mithrandir> thanks.
<pitti> Mithrandir: when is h2 planned?
<Mithrandir> thursday.
* Mithrandir points pitti to the release schedule. :-P
<doko> Mithrandir: please could you sync ttf-dejavu before h2?
* pitti admits being lazy
<ivoks> in two days :)
<Mithrandir> doko: sure, that should be possible.
<Keybuk> ... well, it *almost* resumed from suspend
* Mithrandir wonders a bit about libflashsupport.
<lifeless> Keybuk: hey, with udev, in initramfs, whats the voodoo to say 'please find network cards for me'
<lifeless> Keybuk: I'm looking for a smaller hammer than 'sbin/udevtrigger && sbin/udevsettle'
<Keybuk> lifeless: which release?
<lifeless> Keybuk: edgy
<lifeless> udevtrigger -Cnet doesn't seem to find them, which was my first attempt
<Keybuk> lifeless: no, that'd only bring up network interfaces that already existed
<Keybuk> udevtrigger -bpci -Iclass=0x06*
<lifeless> Keybuk: thanks!
<lifeless> Keybuk: do I need a settle still ?
<Keybuk> personally I'd just run "udevtrigger" without any arguments
<Keybuk> it only takes a nanosecond or two
<Keybuk> assuming udevd is running, the interface turns up
<lifeless> oh, I'm tunning without args at the moment already
<lifeless> if its ok to do so, then I'll just leave it as is
<Keybuk> yeah
<Treenaks> If my sound card mixer has weird labels.. is that a kernel bug or an alsa bug?
<Treenaks> (weird = incorrect, actually)
<Keybuk> yes
<Treenaks> Keybuk: *sigh*.. which one is it?
<Keybuk> well, technically it's an alsa
<Keybuk> but it may the alsa driver, which is in the kernel
<Keybuk> as apposed to the alsa userland
<jdub> lifeless: cool!
* jdub hugs Keybuk 
<lifeless> jdub: extremely. 7 minute noodles
<thom> ta
<thom> gar, silly window manager
* dholbach hugs thom
<thom> hey hey. happy new year!
<dholbach> to you too! :-)
* dholbach hugs thom ecstatically
<seb128> hey thom, happy new year
<thom> hey seb!
* StevenK waves to thom
* StevenK watches the English cricket team fail to cover themselves in glory in the Twenty20 match.
* thom is sadly not shocked
<StevenK> Heh
* fabbione fixes yet another parted breakage
<sivang> hey all
<sivang> does anybody recall the name of the program that indexes your chunks of codes and can then provde answer to questions like "which class implements this interface" etc?
* sivang can't recall the package name
<StevenK> ctags?
<sivang> StevenK: does it work on python too?
<lifeless> night all
<lifeless> sivang: etags works on python
<sivang> lifeless: cool dude, thank you
<pitti> sleep well lifeless 
* sivang hugs pitti 
<StevenK> exuberant-ctags does, yes
<pitti> hi sivang!
<sivang> hey pitti , how you doing? 
* sivang scratches head trying to figure etags pakcage name
<pitti> sivang: I'm great, how are you?
<sivang> pitti: fine as well.
* pitti uploads a new hal, closes nine bugs manually and yearns for changelog-closes-bugs
* seb128 hugs pitti for the bug fixing ;)
<pitti> seb128: I felt it's time to start attacking my pile of 40 'in progress' bugs :)
<seb128> pitti: :)
<seb128> brb
<ogra> in case any archoive admin is fancy doing some NEW reviews, i'd appreciate a look at edsadmin and libflashsupport (the latter for multiverse because of the adobe license)
<fabbione> * Mithrandir wonders a bit about libflashsupport.
<fabbione> ogra: ^
<ogra> Mithrandir, why ?
<ogra> its the connection layer between older sound systems and flash9
<ogra> needed for things like esd and pulseaudio ...
<ogra> which in turn are used in ltsp ...
<seb128> ogra: new gnome-screensaver for you
<ogra> oh, finally
<ogra> seb128, thanks
<Mithrandir> ogra: wondering where to put it, mostly.  And I'm not sure it's possible to distribute at all, since it links with openssl and lgpl-ed libs which in turn link to gpl-ed libs.
<StevenK> Eeek, that's a mess.
<Mithrandir> StevenK: it's flash, what do you expect?
<StevenK> Yeah, well. :-)
<crimsun> ogra: which older sound systems do you plan to support wrt Flash 9? (I'm not entirely convinced libflashsupport is necessary for alsa [see recent alsa-utils changes for asoundconf to support pulseaudio in an asoundrc]  -- or is alsa just one in many players?)
<Mithrandir> ogra: what's the status wrt edubuntu-server?  It's uninstallable.
* pitti -> lunch, bbl
<ogra> Mithrandir, i'm waiting for info on schooltool ... worst case i'll take it out of the seeds temporary for herd2
<ogra> crimsun, ltsp uses esd (breezy/dapper/edgy) and pulseaudio (feisty ...) i need the soundserver support there
<ogra> plain alsa wont help ...
<Mithrandir> ogra: "waiting for info", as in?
<ogra> when will it work with the new zope 
<ogra> according to doko a simple rebuild isnt enough ...
<ogra> (rebuild with new deps)
<Fujitsu> ogra, it works with it now, AFAIK. There just isn't a release.
<ogra> Fujitsu, right, so i'm waiting for a release ...
<doko> Fujitsu: schooltool works with zope3.3???
<Fujitsu> doko, I'm fairly sure it works with the latest.
<crimsun> ogra: Understood for pre-Feisty. Which pulseaudio packages are you using for Flash9? I don't need any additional libflashsupport in Feisty for pulseaudio and alsa.
<doko> Fujitsu: did you look at the debian reports?
<ogra> crimsun, the problem are the users that dist-upgrade their system but not their ltsp chroot, they will still have the esd client side ...
<crimsun> ogra: ah, and no plans to migrate them to pulseaudio, I presume?
<ogra> crimsun, migration without upgrade ?
<crimsun> right
<crimsun> (I understand now)
<ogra> if they dont touch their ltsp "because it works" ...
<ogra> pulse should be able to implement the code libflashsupport has directly ... libflashsupport is only an API layer inbetween 
<ogra> (if its needed at all for pulse)
<crimsun> libflashsupport isn't at all needed for flash9 and pulse; the alsa-lib pulse plugin routes that
<crimsun> (the alsa-lib pulse plugin is in 'libasound2-plugins', which unfortunately is in universe)
<ogra> mneptok, i'm packaging the latest gnome-screensaver and want to apply your patch, why did you use the slieshow screensaver instead of the floaters one ?
<ogra> *slideshow
<slomo_> ogra: does pulseaudio work for you with the 2.6.20 kernels?
<ogra> slomo, yes, apart from a small glitch with the flash packkage we need to fix it works fine for me
<ogra> (flash still creates /tmp/.esd/socket, that makes pulse not start the esd module)
<slomo_> ogra: hmm... it doesn't work on any of my machines with .20 but works with .19... all device detection methods return no card with .20 although alsa and oss work :/
<ogra> er, ohg, wait a sec
<crimsun> slomo_: that's the hal module issue, no?
<ogra> i'm still using .19 ... ignore me ...
<slomo_> crimsun: which hal module issue? :)
<crimsun> slomo_: /etc/pulse/default.pa's "load-module module-hal-detect"
<Riddell> pitti: I have no plans for amarok or qt uploads
<crimsun> I can't use that; I have to comment that out (and the if block) and use "load-module module-detect" instead
<slomo_> crimsun: hm works... i wonder what broke hal from .19 to .20 :/ thanks
<crimsun> np
<Mithrandir> seb128,dholbach: you'll tell me when your gnome uploads are done so I can spin cds?
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main frozen for Herd 2
<ogra> Mithrandir, time to promote mbr (if you didnt already)
<Mithrandir> mvo: can you please do a g-a-i desktop database update?
<Mithrandir> ogra: done hours ago
<ogra> oki
<ogra> Mithrandir, edsadmin rejected ? do we have our "bad licenses day" today ? :/
<Mithrandir> ogra: yeah, I think we're at about 5:1 of rejects:accepts for the archive lately.
<Hobbsee> Mithrandir: ouch!
<ogra> i hate licenses
<Treenaks> ogra: everything pd!
<Mithrandir> Hobbsee: yeah, especially for me who get to review the packages again and again until they're good.
<seb128> ogra: are you already working on the gnome-screensaver update?
<Hobbsee> Mithrandir: indeed.
<ogra> seb128, yeps
<seb128> Mithrandir: ok, most of it is done, only a bunch to do
<ogra> seb128, why ? anything i should add ?
<seb128> ogra: no, just trying to get 2.17.5 for herd-2 and that's one of the remaining packages to update ;)
<Mithrandir> Hobbsee: also fun stuff like the flash support library probably being undistributable due to linking with openssl and indirectly with GPL-ed libs.
<ogra> Treenaks, lets just drop licensing altogether ... 
<Hobbsee> Mithrandir: ugh
<Mithrandir> as long as people stay with standard licences like the GPL or BSD/MIT/X11, things are fine, but not so much when there's no COPYING in the orig.tar.gz, etc.
<ogra> Mithrandir, i have no clue if or how it works without ssl ... but i'll try to drop the dep ... if that doesnt work it doesnt work...
<ogra> or do you think linking it against libesd and libpulse will also be illegal ? 
<Mithrandir> the licence looks GPL-compatible, but I think I'll run it past elmo, who has way more experience than I.
<Mithrandir> mvo: have you had any luck with 75882?
<crimsun> Mithrandir: (I'm aware that main's frozen) Are my uploads (scorch3d and teg) failing in soyuz?
<crimsun> scorched3d, even
<Mithrandir> crimsun: they're probably ending up in unapproved, but I just approve stuff going to universe.
<Mithrandir> but yeah, they failed.  If you actually signed them, I can reprocess them
<crimsun> I did. Twice for each.
<crimsun> (meaning I've reuploaded each)
<Mithrandir> crimsun: hmm
<Mithrandir> let's see if it works this time around, if not, I'll prod cprov 
<crimsun> upload again?
<Mithrandir> nah, I moved them
<crimsun> ok, thanks!
<Mithrandir> as in, moved them back to incoming
<seb128> Mithrandir: did you already approve the new liboobs? if not maybe wait
<Mithrandir> seb128: no, I haven't
<seb128> ok, wait then
<Mithrandir> wait or reject?
<seb128> wait
<Mithrandir> ok
<seb128> new g-s-t has UI changes to time-admin
<seb128> and I'm wondering if that could be a problem for ubiquity
<seb128> maybe would be better to get after herd-2
<Mithrandir> ah, ok.
<seb128> cjwatson: does ubiquity cares about time-admin changes?
<Mithrandir> so I should hold g-s-t back, too?
<seb128> Mithrandir: I've not uploaded that one yet 
<seb128> liboobs has a soname change anyway
<seb128> so it shouldn't break current g-s-t even if accepted
<Mithrandir> I always read liboobs as lib-boobs, I'm sure it's deliberate.
<Mithrandir> and I go "huh?" every time too.
* StevenK plants a "Male" sticker on Mithrandir's forehead
<jdahlin> Heya, I have a problem booting from an edgy cd. It fails during the unpacking of the initrd image. Any clues?
<seb128> Mithrandir: yeah :)
<seb128> hey jdahlin
<jdahlin> It's an offical cd, eg pressed, not burned
<jdahlin> bonjour seb128 
<seb128> jdahlin: happy new year
<seb128> jdahlin: dunno about the CD question
<jdahlin> seb128, happy new year too
<jdahlin> seb128, okay
* jdahlin pokes cjwatson and Keybuk 
<Keybuk> jdahlin: we're somewhat busy today - what's up?
<jdahlin> Keybuk, I'm unable to boot the official edgy cd, something happens when the initrd image is unpacked
<jdahlin> okay, just wanted to know if there are any known workarounds
<Keybuk> not without further information on what the problem is
<Keybuk> "doesn't boot" is a little vague
<Keybuk> have you performed a CD check?
<jdahlin> no, I assumed the pressed CD was okay. But I'll do that
<pitti> doko: ++(syncing from etch until feature freeze)
<Keybuk> from the sound of it, it could be boot-loader related; Mithrandir may be able to help
<Mithrandir> jdahlin: what error do you get?
<jdahlin> extracting initrd.gz from the CD directly seems to work
<Mithrandir> also, what kind of machine/cpu/motherboard?
<jdahlin> Mithrandir, let me reboot and test
<jdahlin> Mithrandir, intel something / celeron 400
<Mithrandir> ok
<Mithrandir> you could try removing quiet and splash from the kernel command line to see if that helps
<jdahlin> thanks, that'll probably show a bit more
* ogra ponders to buy a dedicated dual opteron with 4gig of ram for evolution, so he can actually do some work again ...
<seb128> ogra: it's not that bad
<seb128> is it?
<ogra> currently it is
<seb128> evolution works fine on my desktop
<seb128> I'm wondering if I'm just being lucky with it :p
<pitti> seb128: yay for latest evo not crashing any more in todo list :)
<seb128> it works fine on my laptop too
<seb128> pitti: ah, I didn't notice, thank you for pointing it ;)
<ogra> my inbox has ~22000 mails and i recieve 120 mails since 2h ... filtering takes ages with imap and tls
* pitti can tick TODO items again without vi'ing ~/.evolution stuff
<pitti> ogra: 22000 mails in one mailbox are a PITA with every program, even mutt
<ogra> and i still didnt find the time to set up offlineimap
<ogra> pitti, thats only my inbox
<pitti> ogra: I can give you a quick walkthrough on offlineimap if you wnat
<ogra> my ubuntu-users mailbox is bigger :P
<ogra> s/mailbox/folder/
* pitti proposes a trade: pitti->ogra: offlineimap, ogra->pitti: answers to some hwdb questions
<ogra> heh, ok
<jdahlin> Mithrandir, the error I get is "isolinux: Disk Error 80, AX = 4200, drive 9F"
<jdahlin> I can also add that it's not possible to do the media check because of the same error
<Mithrandir> jdahlin: it looks a lot like a dirty CD-ROM drive.
<Mithrandir> jdahlin: can you try with another?
<jdahlin> Mithrandir, sure. but it seems to work fine under windows
<Mithrandir> jdahlin: afaik, isolinux isn't very heavy on the error recovery.
<Mithrandir> jdahlin: it's a first shot at least.
<Mithrandir> jdahlin: you can also try booting while holding down shift, that should put isolinux into safe-mode.
<Mithrandir> Riddell: can you start testing your live images?  I'll spin you alternate ones now that mbr is in main.
<Riddell> Mithrandir: already testing
<Mithrandir> Riddell: great. :-)
<Mithrandir> Riddell: I'm spinning new alternate CDs for you now so you get the ones with mbr on them.
<crimsun> Mithrandir: do you need xubuntu testers for 20070109?
<Mithrandir> crimsun: yeah, testing of -live for xubuntu would be good.
<crimsun> on it
<Mithrandir> I'll spin alternate as soon as the kubuntu ones are done
<mvo> Mithrandir: 75882 should be fixed in feisty, but I haven't investigated why it will reinstall the packages later again
<spike> hi there
<spike> is there any option I can use with preseeding to specify additional options for grub?
<spike> I'm lookint at https://help.ubuntu.com/6.10/ubuntu/installation-guide/amd64/preseed-contents.html , Boot loader installation section
<spike> but cant see anything useful
<spike> what I want to is to add "console=ttyS1,57600" - that's all I need
<spike> I can do it postinstall before rebooting with sed obviously, but was wondering if there was a better way within preseeding
<pitti> hi zul
<zul> hi pitt how is it going?
<pitti> pretty well, thanks!
<jdahlin> Mithrandir, I get an identical error with another CD drive.
<Mithrandir> jdahlin: hmm, ok.  You've tried booting while holding shift down too?
<jdahlin> Mithrandir, yes, that didn't help much either
<Mithrandir> jdahlin: then I'm not sure. :-(
<jdahlin> Mithrandir, I'll do some googling. It could be a very broken BIOS
<Mithrandir> Riddell: alternate done
<Riddell> cjwatson: seems like qt4 ubiquity has a couple of crashes in it still.  I'm stuck on one of them..
<Riddell>   File "/usr/lib/ubiquity/ubiquity/frontend/kde-ui.py", line 1654, in set_summary_device
<Riddell>     if not device.startswith('(') and not device.startswith('/dev/'):
<Riddell> AttributeError: startswith
<Riddell> but device is definately a str at that point, so I don't understand how it doesn't have startswith
<ogra> do you need a backslash for '(' ?
<Riddell> not according to a quick test on the python interpreter
<ogra> hmm
<jdahlin> Riddell, it can't be a string, it's probably None
* jdong absolutely HATES Edgy's GTK file dialog
<ogra> what if you force it to a string with str() ? does it work then ?
<Riddell> device is: <type 'str'>
<Keybuk> jdong: what changed about it?
<Riddell> it's definately a str
* Keybuk doesn't remember the file dialog changing
<jdong> Keybuk: the autocomplete tries to fill things in as you type
<jdong> destructively
<Keybuk> it's always done that, no?
<jdong> no
<jdahlin> edgy has gtk 2.10, some things changed betweeon 2.8 and 2.10
<jdong> it's displayed the highlighted portion
<jdong> and continued letting me type
<jdong> but not chose things without my permission
<jdong> i.e. I'd type in /tmp and end up with /tmp/media/play
<Keybuk> press Delete
<jdong> grr and I can only get it to happen part of the time....
<jdong> ok, now it's magically working
<jdong> but I swear three minutes ago it was on an autocompleting rampage
<jdong> Keybuk: ok, it's doing it again
<jdong> I restarted firefox and now the open dialog is completing things as soon as there is only one completion
<jdong> pressing delete does nothing
<Keybuk> ah, well, Firefox
<Keybuk> that uses its own implementation, I suspect :P
<jdong> I've had it happen elsewhere too
<jdong> grr
<jdong> oh well, enough being angry with a stupid dialog :)
<bddebian> Heya
<Mithrandir> crimsun: alternates ready for xubuntu too.
<Mithrandir> note that if you end up with trouble mounting the CD, I know the fix for it, but it means we need a workaround for your arch.
<bddebian> Mithrandir: I'm going to have to go upstream to fix libparagui?
<seb128> Mithrandir: is control-center waiting approval?
<Mithrandir> bddebian: just a second.
<Mithrandir> seb128: doesn't look like it, no.
<Mithrandir> liboobs is the only thing in unapproved
<seb128> Mithrandir: hum, weird, I've uploaded it 1h30 ago
<seb128> Mithrandir: and it's not listed anywhere apparently
<Mithrandir> seb128: it seems like something is making soyuz eat half the uploads.
<seb128> Mithrandir: no fun :/ Should I ping somebody from the launchpad team or could you look at what is going on ?
<Mithrandir> seb128: no need, I've already pinged cprov
<seb128> ok
<cjwatson> seb128: I ripped all use of time-admin out of ubiquity a couple of days ago; feel free to modify it
<seb128> cjwatson: ah, thank you
<seb128> Mithrandir: approve liboobs please then :)
<seb128> Mithrandir: I'm going to upload the new g-s-t and then we should be good for GNOME 2.17.5
<Mithrandir> seb128: ok, excellent
<Mithrandir> accepted.
<pitti> seb128: were there any patches left for ipv4ll support?
<seb128> pitti: no
<pitti> great
<cjwatson> Riddell: does python-qt4 do truly evil things to Python's core classes?
* pitti hugs gazpacho
<seb128> pitti: try the upstream variant when available pelase :)
<seb128> please
<pitti> seb128: of course
<cjwatson> Riddell: that's the only reason I can think of for that sort of breakage
<cjwatson> jdahlin: device isn't None because the line immediately above the one Riddell mentions is "if device is not None:"
<Riddell> cjwatson: it doesn't as far as I know
<Mithrandir> Riddell: does alternate work for you so far?
<Riddell> Mithrandir: still on desktop, I'll burn alternate now
<Mithrandir> ok.
<Mithrandir> you saw my caution against it not being able to mount the cd above?
<dholbach> pitti: did you mean garnacho? :)
<pitti> dholbach: yes, probably :)
<dholbach> hehehehehe
* dholbach hugs pitti
<Hobbsee> heya pitti 
<pitti> hi Hobbsee|NotHere 
<crimsun> Mithrandir: thanks
<Hobbsee|NotHere> :)
<crimsun> hmm, on 20070109 (xubuntu daily-live) ubiquity appears to do some very strange screen corruption things after I select US English as the keymap
<crimsun> I'm able to ctrl+alt+backspace to restart the X Window session, however
<cjwatson> known bug, see console-setup
<crimsun> ok
<cjwatson> crimsun: it's bug 73955
<Ubugtu> Malone bug 73955 in console-setup "Clobbered X screen state during installation" [High,Confirmed]  https://launchpad.net/bugs/73955
<Mithrandir> gnr, we either need new d-i or new kernel for amd64 too.
<cjwatson> crimsun: I can't reproduce it here; do you think you could dig into it based on the reduced test case I posted there?
<cjwatson> Mithrandir: we need new d-i on all architectures for the {storage,fs}-core-modules breakage, I think
<fabbione> Mithrandir: isofs?
<Mithrandir> fabbione,cjwatson: yes.  Just trying to decide.
<cjwatson> I don't see why that should be arch-specific unless there are dependencies on fs-core-modules
<fabbione> the kernel would be cleaner but you will still need a d-i upload to catch it up
<crimsun> cjwatson: I'll attempt
<Mithrandir> fabbione: yeah, so I think I'll just work around it in d-i
<cjwatson> crimsun: thanks, I'd appreciate it
<Mithrandir> while wrong, it's not that bad.
<fabbione> Mithrandir: we can clean it up immediately after
<Mithrandir> sure
<Commander-Crowe> hi where can i find Ubuntu 7.04 checksum?
<seb128> cjwatson: just curious, why did you stop using time-admin?
<crimsun> Commander-Crowe: http://cdimage.ubuntu.com/daily-live/current/
<Commander-Crowe> haha thanks
<Commander-Crowe> god is it buggie
<Commander-Crowe> but nice
<Commander-Crowe> tehcore
<Riddell> Mithrandir: kubuntu amd64 alternate does indeed fail to mount the cd
<Mithrandir> Riddell: ok, I'm rolling a new d-i.  Once it's in, I'll roll new images.  How are your live images looking?
<Riddell> Mithrandir: not so good, the power manager crashes on startup and the whole thing seems to freeze at 71% installed
<Riddell> cjwatson, Mithrandir: patch for ubiquity http://muse.19inch.net/~jr/tmp/ubiquity.diff
<Mithrandir> Riddell: hm, ok
<astan> hello folks. how can i help with/request a feisty package to go into edgy-backports? (python-sqlalchemy)
<Mithrandir> (to the power manager and freeze; I'm looking at the diff now)
<cjwatson> seb128: way too many small issues to be worth it; people can set the time post-install
<seb128> cjwatson: ok
<cjwatson> Riddell: thanks, will apply; BTW I believe you're supposed to use 'is not None' rather than '!= None'
<Mithrandir> Riddell: I was just typing what cjwatson typed, apart from that looks good.
<Mithrandir> cjwatson: you're planning on another ubiquity upload tonight?
<cjwatson> can do one today
<cjwatson> Riddell: what about the other issue?
<Mithrandir> thanks.
<Riddell> cjwatson: still investigating the curious device string issue
<Commander-Crowe> My system crashed when I tried to open up "about ubuntu"
<cjwatson> Commander-Crowe: please report bugs in the bug tracking system rather than here; we need to use this channel for developer coordination
<Commander-Crowe> oh ok
<Commander-Crowe> I did btw
<cjwatson> Riddell: applied, thanks
<cjwatson> Commander-Crowe: ok, then that's generally sufficient; we only need to know here if it's an all-consuming showstopper for an upcoming release
<Commander-Crowe> um
<Commander-Crowe> is there any developing I can do via python or shell scripting?
<cjwatson> Commander-Crowe: http://www.ubuntu.com/community/participate
<sfllaw> pitti: Can you please include the debdiff for bug 72125?
<Ubugtu> Malone bug 72125 in tzdata "Daylight Saving changes in Western Australia" [High,In progress]  https://launchpad.net/bugs/72125
<pitti> sfllaw: I included the diff of the included tarball
<pitti> sfllaw: apart from that, it's just the changelog
<pitti> sfllaw: the debdiff is changelog + 'binary files differ' for the single tzdata2006p.tar.gz
<sfllaw> pitti: Ah, I see.
<sfllaw> That was not clear from my reading of the bug.
<sfllaw> Thanks.
<pitti> sfllaw: not sure whether cjwatson already approved the dapper counterpart (langpack-locales), I don't think so; but for that it's the same story, updated included tarball
<Commander-Crowe> does the live CD of Ubuntu not run XGL/Beryl/Compiz?
<Commander-Crowe> but does run in the installed verison
<Commander-Crowe> nativly that is
<ogra> Mithrandir, i just uploaded a new gnome-screensaver, please approve
<Pierre> hello
<Pierre> about #78476, did I use the right channel or is there a more appropriate way to inform the pkg maintainers?
<Pierre> hm mabye -bugs :)
<seb128> Pierre: launchpad is the right place for bugs usually ;)
<seb128> Pierre: no need to ping on IRC for them
<Pierre> seb128: yes, my question was whether it is a bug or I should post that somewhere else. But as long as it is a bug, I will be quiet :)
<Pierre> +if
<Pierre> question answered, thanks :)
<Riddell> cjwatson: http://muse.19inch.net/~jr/tmp/ubiquity.diff updated with fix for device string issue too, seems it was a QString not a str
<ogra> lifeless, ping
<_ion> Hi dholbach
<_ion> dholbach: See anything weird in /usr/share/doc/deskbar-applet/changelog.Debian.gz? ;-)
<_ion> Hint: 2.17.5-0ubuntu1, key binding
<dholbach> haha
<dholbach> i doubt that was my mistake ;)
<dholbach> " * Prevents binding of keys a-z and shit-a-z." from ./NEWS
<dholbach> ;-)
<_ion> Perhaps they have different keyboards where the upstream authors live.
<dholbach> I'm sure :)
<Nafallo> haha
<mneptok> ogra: ping
<ogra> mneptok, pong
<mneptok> ogra: chose sshow for the lowest cpu usage
<pitti> carlos: can I nag you again about bug 68646? it's high time for new langpacks for stables
<Ubugtu> Malone bug 68646 in rosetta "Russian l11n in tsclient is broken" [Undecided,Confirmed]  https://launchpad.net/bugs/68646
<mneptok> ogra: floater smells heavier *shrug*
<carlos> pitti: oh, right. I forgot it completely
<carlos> I will do the upload later today
<ogra> mneptok, its ... but only minimally
<carlos> pitti: thanks for remind me it
* mneptok isn't married to any idea except a saner default ;)
<pitti> carlos: thanks
<ogra> i defaulted to the floating ubuntu logo from bug #59365 now ... if you think thats to heavy we can still switch
<Ubugtu> Malone bug 59365 in gnome-screensaver "ubuntu theme" [Wishlist,Fix committed]  https://launchpad.net/bugs/59365
<ogra> just waiting for the ACCEPTED message from soyuz to close the bugs :)
<mneptok> ogra: i think whatever the crappiest driver can display with minimal cpu or further dev cycles is best
<ogra> well, i think a tradeoff for beauty is valid ... so some percent of CPU may be used for animation imho :)
<ogra> (apart from that i only have to uuen/decode a single pc instead of a whole directory :) )
<ogra> s/pc/pic/
<mneptok> <girlfriend_voice>whatever you think is best, dear</girlfriend_voice>
* ogra kisses mneptok thankfully
<ogra> :)
<cjwatson> Riddell: muse.19inch.net won't talk to me
<cjwatson> Riddell: presumably it's just unicode() in on_advanced_button_clicked?
<Riddell> cjwatson: that's it
<Riddell> hmm, ubiquity getting stuck at 71% installed was fixed by burning to a new CD, but now it's stuck on 22gnome_panel_data
<kanzie> Is this a good place to report tiny bugs?
<pitti> kanzie: usually not; the bug tracker is
<kanzie> ok, so a mapping-problem that is easy to work around in gparted and a dialogue error in Sharing in edgy is nothing to discuss here but to write formal reports on?
<cjwatson> Riddell: can you find out if that script is actually running, or if the next thing is running but just hasn't updated the progress bar yet?
<Riddell> cjwatson: the script isn't in ps output
<cjwatson> perhaps something else is? ps axf is often helpful to see the process tree
<Riddell> cjwatson: /usr/bin/python /usr/share/ubiquity/install.py is the bottom of the ubiquity tree
<Riddell> top says it's using 94% CPU, so it's doing something
<cjwatson> Riddell: hmm. can you lsof that to find out if it has any interesting files open?
<Mithrandir> Riddell: kde-guidance needed for herd-2?
<Riddell> Mithrandir: yes please
<Riddell> fixes crash on startup of live CD
<Mithrandir> Riddell: accepted
<Riddell> thanks
<cjwatson> Riddell: (holding off upgrade until we dig into this)
<cjwatson> er, upload
<ogra> Mithrandir, there is an edubuntu-meta upload that fixes -server waiting for approval ...
<ogra> pitti, rmemeber that du -hcs i started when we were in priv ? it just finished now :)
<pitti> ogra: ouch
<ogra> 3.6G
<pitti> ogra: seriously, you should archive your mails from time to time instead of keeping them around forever in your active mailboxes
<ogra> well, then searching old stuff gets so painful ...
<pitti> zgrep :)
<ogra> but i should probably have a db backend *g*
<pitti> well, your choice of course
<Mithrandir> seb128: s-t-b, evo-webcal, intltool, gnome-icon-theme are all targetted for herd-2?
<Mithrandir> if searching in multiple folders is painful, use another client for that
<ogra> well, i thought about that ...
<ogra> but somehw i feel i should use what our users use as well to see where they suffer ...
<keescook> mornin' folks
<Mithrandir> ogra: but you know what?  They probably don't keep 22k messages in a single folder.
<Mithrandir> so they don't see those problems.
<ogra> nah, really ? :)
<spike> were debian-installer/locale=en_US.UTF-8 kbd-chooser/method=us available in breezy?
<ogra> it would be nice if mutt could just use my .evolution maildirs folder ... 
<spike> or what was the equivalent? there's no "installation manual" with a preseeding section for breezy :(
<thom> ogra: just point it at them, then? if they're real maildirs, i don't see what the problem would be
<ogra> hmm, i never tried that ...
<seb128> Mithrandir: yep
<ogra> (didnt know mutt is capable of reading maildir format)
<thom> only for the last hundred million years or so ;-)
<_ion> thom++
<Mithrandir> apart from being a bit slow, evo seems happy with my 20k mail folders here.
<ogra> Mithrandir, its only the filtering thats slow
<pitti> ogra: I have used mutt with maildir for a long time, works fine; I can point evo to those without any problem
<ogra> i.e. overnight i recieve about 300 mails, then around the morning my net connection drops ... if i come to my machine in the morning it takes 1-2h to get them all filtered
<Mithrandir> use server-side filtering and imap, then.
<ogra> i use server side SA for tagging and sort the spam locally after tags ...
* pitti uses postgrey+spamassassin+procmail+dovedot = 
<Riddell> cjwatson: 
<Riddell> http://kubuntu.pastebin.ca/311195
<pitti> ogra: but if you sort spam on the server side, you save the download
<ogra> so i dont have to rely on my server being vailable if i want to recover a mislead spam mail ...
<Ng> what is likely to be deciding that the "User" button on my keyboard == suspend?
<_ion> pitti: Same but s/procmail/maildrop/
<pitti> ogra: ok, if that's an issue, then you are right
<ogra> pitti, right, but i always need the server 
<Mithrandir> ogra: no, you don't.  Just make sure to mark all folders available for offline use.
<seb128> Mithrandir: gedit for herd-2 too if you want to accept it and we are uptodate for GNOME
<Mithrandir> seb128: hooray!
* ogra builds some ltsp client roots to make sure they work on the CD 
* spike shrugs
<spike> if an installation process never asked you for a user/password, how's the default account supposed to be created?
<pitti> spike: it does ask you
<spike> believe me it didnt... I'm having serious issues with this breezy installation... *serious*
<ogra> pitti, unless you choose oem :)
<spike> there's no way to get preseeding to work, and when it drops to manual install ti will just behave weirdly 
<pitti> ogra: that still asks for a password
<ogra> oh, right
<spike> it looks like it loaded half of the answers from the preseed file, some from manual questions
<spike> but the end result is totally unconsinstent :(
<kanzie>  Im trying to find the best way to install Eclipse environment on my Ubuntu Edgy system. I want it for developing php and Java... any ideas?
<pitti> kanzie: apt-get install eclipse?
<pitti> kanzie: -> #ubuntu, btw
<kanzie> pitti, tried there... no success
<User65> hey
<User65> can someone help me
<User65> err theres only one person
<User65> bye bye
* pitti blinks
<LaserJock> ... ok
<_ion> Right.
<_ion> These composited windows for the eject/volume keys are really nice.
<pitti> _ion: hm, they exist for ages... breezy or so
<_ion> I'm sure they do, but i haven't used a compositing window manager for that long. :-)
<pitti> oh, with compositing
<cjwatson> spike: it's on archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/doc/manual/ or thereabouts
<cjwatson> Riddell: doesn't look significant; does strace show anything much?
<cjwatson> Ng: hotkey-setup IIRC
<pitti> _ion: I still cannot understand how people can live with using compiz' totally f**ed workspace handling
<pitti> (not even to mention the eye-hurting fade effects in menus etc.)
<seb128> pitti: if you don't use workspaces it's actually nic
<seb128> nice
<Nafallo> pitti: :-)
<_ion> pitti: You haven't tried to configure it?
<_ion> pitti: It's unusable with default settings.
<seb128> pitti: well, a smooth fade-in is actually nice
<pitti> _ion: there are only two settings for me: 'workspace on cube' and 'wobbly windows'
<pitti> seb128: maybe, but it should be faster IMHO
<seb128> pitti: wait for next version, I'm working on an update based on changes from some contributor working on it
<_ion> TBH, i use beryl. Its configuration program is *awful*, but at least i don't have to configure it with gconf-editor.
<pitti> seb128: new compiz, now with 58.3% more love? :)
<seb128> well, new compiz has not that many change
<thom> i could care less about love, but having some workspaces would be nice ;-)
<seb128> we will try setting the number of viewport to 1
<pitti> thom: well, it has, but you don't see the other workspaces in the switcher
<Riddell> cjwatson: strace doesn't seem to work attaching to the install.py process, it just outputs read(0," and nothing more
<seb128> to have a workspace behaviour similar to the current one
<thom> pitti: yeah
<seb128> pitti: and the guy has written some compiz-GNOME keybinding sync plugin
<pitti> thom: not breaking my settings == love enough for my taste for now
<seb128> pitti: which should make the keybindings work the same way
<cjwatson> Riddell: that's not strace being broken - that's just that install.py is waiting for something
<pitti> \o/
<thom> yeah, keybindings is the other suck
<cjwatson> Riddell: are you sure it doesn't have a subprocess somewhere?
<_ion> The only thing really keeping me from switching from beryl to compiz is the lack of the 'state' plugin in the compiz package.
<cjwatson> Riddell: I think I'll upload this now, TBH - this sounds pretty nebulous :(
<seb128> _ion: what is "state"?
<Riddell> cjwatson: http://kubuntu.pastebin.ca/311211
<cjwatson> Riddell: sort of seems like one of its subprocesses has died but it didn't notice
<carlos> pitti: hi, could you check again tsclient?
<Riddell> cjwatson: on my powerpc it gets stuck on 32_gnome_power_manager.  (the i386 one gets stuck on 22gnome_panel)
<cjwatson> Riddell: might be worth rebooting and running it again using 'ubiquity --debug'
<_ion> seb128: It allows me to say "set *all* windows' brightness to 70%, but set mplayer's brightness to 100%". I crank my monitors to their brightest setting and compensate for that with the state plugin, but videos aren't too dark anymore.
<cjwatson> (you don't need any manual kdesu stuff nowadays)
<seb128> _ion: looks like a corner usecase
<_ion> seb128: I think many people would love that if there was a simple checkbox that configured things so.
<seb128> checkbox to configure what?
<pitti> carlos: oh, 'used elsewhere still has the screwed strings, but that's okay I think'
<carlos> pitti: yeah, I cannot remove them easily
<pitti> carlos: I requested a download; easier to check than the web pages
<carlos> pitti: ok
<carlos> pitti: btw, that's not a Rosetta bug, but a translation error done by someone, so the bugs should be agains the language pack
<carlos> pitti: that's why I rejected the task in Rosetta
<carlos> pitti: I fixed it, but usually, that's a task for the translation team
<_ion> "Click this to darken all windows but Xv and OpenGL ones. Remember to increase your monitor's brightness." I know many people who always manually change their monitor's brightness when they're watching a movie.
<pitti> carlos: I'm not sure; it seems it misinterpreted the po files from the source packages
<seb128> _ion: weird
<carlos> from what I saw, someone got the .po file, changed the encoding field but didn't recode the file
<seb128> _ion: I don't think I know anybody doing that
<ogra> me neither
<carlos> pitti: we don't change encoding randomly
<Riddell> cjwatson: the good news is it all works fine if I delete those two scripts
<keescook> agh, can an ubuntu-devel moderator white-list .*kees@outflux.net ?  Looks like Mailman is using my envelope-from for filtering...
<_ion> Applications are too bright if i use them with the brightness movies are most enjoyable with.
<pitti> carlos: hmm, the exported file is still totally screwed
<pitti> carlos: does the export use older data than the webui?
<carlos> pitti: unfortunately  that's another bug
<carlos> pitti: danilo has already a fix
<carlos> let me force a an update
* pitti reviews the strings in the webui
<cjwatson> Riddell: they're in casper; perhaps casper-reconfigure needs to be taught to skip packages that don't exist
<cjwatson> Mithrandir: ^-- could you comment?
<pitti> carlos: strings look fine now, thanks! will they make it into tomorrow's tarballs?
<carlos> yeah
<carlos> they should
<pitti> great
<pitti> carlos: thanks
* pitti -> dinner
<carlos> np
<gpocentek> hum, the latest xubuntu daily image fails to mount the cd (after hardware detection)
<gpocentek> does this happen with other *buntu isos?
<cjwatson> gpocentek: yeah, that's being sorted
<gpocentek> cjwatson: ok, thanks
<cjwatson> gpocentek: (recent debian-installer upload)
<Mithrandir> cjwatson: I thought it did already.
<cjwatson> Mithrandir: hmm, it is supposed
<cjwatson> to
<cjwatson> Mithrandir: OH
<cjwatson> if [ -z "$version" ] ; then
<cjwatson>     echo "$0: package '$package' is not installed"
<cjwatson>     exit 0
<cjwatson> fi
<cjwatson> Mithrandir: please make that echo >&2 kthxbye
<cjwatson> otherwise it pisses about with the debconf communication channel
<cjwatson> hooray, that fixes some really obscure bugs, I suspect
<jdahlin> Mithrandir, I arrived here and my xchat tab was blue, can you repeat the last thing you said?
<cjwatson> Mithrandir,Riddell: Fix in casper bzr, I believe; can you look at it? There are some other changes in bzr (which are overdue to be uploaded) and I have to go and get on a train nonw.
<cjwatson> now.
<[Kork] > hi
<nixternal> cjwatson: the Ubiquity crash bug I filed that you just fix released (thanks btw), is this tied to the issue I have with alternate CDs not mounting the CDROM?
<[Kork] > some feedback: would it be possible to drop "totem-mozilla" from "ubuntu-desktop" in feisty? it interferes with "mozilla-mplayer", which i prefer to use. removing "totem-mozilla" means removing "ubuntu-desktop", which is kind of suboptimal.
<seb128> Mithrandir: did you figure what happened to that control-center upload?
<seb128> Mithrandir: I've uploaded libbonoboui 2.17.0, nothing really interesting to it, should be fine to accept if you want it, fine to delay for after herd too
<Tonio_> Mithrandir: ping ?
<Tonio_> Mithrandir: I just upload another fixed guidance (packaging issue this time, my fault), latest should be okay
<Tonio_> Mithrandir: files conflicting during package installation, so that would highly impact the livecd if not aproved.... sorry for the inconvenience....
<gnomefreak> what time today are we starting the freeze?
<keescook> gnomefreak: looks like it already started.  :)
<ogra> gnomefreak, 10 am UTC ;)
<gnomefreak> oh darn im all kinds of behind ty
<mdke_> mdz: around?
<Seveas> elmo, mako, cjwatson: CC meting in T minus 3 minutes
<sfllaw> Fridge Editors: There's some broken HTML in http://fridge.ubuntu.com/node/708
<mdke> sfllaw: thanks. Although pure chance I saw it, email is best
<mdke> sfllaw: what's the broken HTML?
<sfllaw> mdke: Man, now I have to look.
<sfllaw> Line 78.
<sfllaw> alt="Ben Collins" " />
<sfllaw> That's totally wrong.
<mdke> oh yeah
<mdke> is that better now?
<sfllaw> mdke: I won'jt be able to tell for a while.
<sfllaw> But I think that's the only thing.
<sfllaw> Running it through a validator will give you bonus points.
<mdke> sfllaw: ok, thanks
<lifeless> moin
<lifeless> ogra: pong
<Chipzz> anyone read this: http://jongsmamm.blogspot.com/2007/01/gdb-slowness.html
<ogra> lifeless, you didnt tell me you implement https://wiki.ubuntu.com/LiveCDShareThisCD
<ogra> you reimplement 80% of ltsp in that spec
<lifeless> ogra: I did link that to the channel a few times ogra :)
<ogra> the spec ? 
<lifeless> yes
<ogra> hmm, then i missed it ...
<ogra> strange ... 
<ogra> but anyway, all of the dhcp and tftp stuff is already handled by ltsp-server ... 
<lifeless> anyhow, I am sure there is large overlap, netboot is netbooting after all.
<lifeless> ogra: phone call, brb.
<ogra> do you want to provide / as nfs root  ? 
<ogra> or do you want to offer a separate chroot ? 
<lifeless> brb, gotta reboot.
<glatzor> ping Riddell: you want software-properties in kubuntu?
<twb> Mithrandir: nag, nag
<lifeless> ogra: back
<lifeless> ogra: / is the squashfs from the cdrom unioned with a ramdisk
#ubuntu-devel 2007-01-10
<lifeless> ogra: the nfs mount offers the cdrom image only
<twb> lifeless: you want to unite a read-only NFS root with a ramdisk?
<ogra> lifeless, so you simply need ltsp with the chroot replaced by the iso image ? 
<ogra> do you need to loop mount it before the nf export or do we have it mounted anywhere visible (below the union) ?
<ogra> s/nf/nfs/
<twb> If you're talking about a read-only NFS root merged casper-style with a tmpfs ramdisk, debian-live currently does that, and I'm hassling Mithrandir to dupload my code so that feisty will do it, too.
<twb> Currently, Ubuntu does not support it.
<ogra> twb, actually the spec was about providing ltsp from a livecd ... 
<ogra> somehow it mutated ... 
<twb> OK, ignore me then.
<ogra> whyt lifeless wants to provide is not the unionfs merged piece but only the iso ...
<ogra> *what
<twb> I see.
<ogra> so your clients boot the iso like its attached locally ... 
<ogra> twb, yur code would enable real ltsp thin clients from liveCDs if i understand t right
<ogra> (which is a very bad idea wrt disk access ... apart from demoing with a single client)
<lifeless> ogra: I need what I've put together
<twb> What my code does is allow up to, say, 100 1GHz diskless clients to boot from a single read-only NFS export.
<lifeless> twb: yes, its casper. Read the spec
<twb> And strictly speaking, it's not my code.
<twb> Actually 100 is probably a rather modest ceiling for a 100baseT network.
<ogra> 100 1 Ghz clients ? from a single CDrom ? 
<ogra> what kind of cdrom do you have attached there ? a 300x one ?
<twb> ogra: what CD-ROM?
<lifeless> https://wiki.ubuntu.com/LiveCDShareThisCD
<twb> It's NFS, not a CD.
<lifeless> twb: ^ have you read that ?
<twb> Oh, you want to boot the server off the same CD.  I"m not doing that.
<lifeless> twb: eventually. Read the manual prototype down the bottom.
<ogra> its a liveCD with the opportunity to booot thin clients from
<lifeless> ogra: the point is that they are not regular thing clients, they are casper clients
<ogra> which turned into a liveCD with the opportunity to boot full diskless workstations from ;)
<ogra> lifeless, right
<lifeless> ogra: so you can boot the machine, and then install locally
<lifeless> and dont need any writable network area
<ogra> yep understood
<lifeless> now, in fact, for what I needed, booting the server off the ISO is irrelevant
<twb> I don't understand why any of this is confusing.  I've been doing it with Knoppix for two years.
<lifeless> but that spec was the best place to document what I did.
<lifeless> twb: Its not confusing me ;)
<ogra> neither me :)
<twb> I wish people wouldn't use unbound personal pronouns on wiki entries.
<twb> "For linux.conf.au I setup a machine that shared out a liveCD, perhaps called a LiveNetboot ;)."
<lifeless> twb: thats me, sorry.
<twb> lifeless: were you the guy asking for g3 mac keyboards on the luv list?
<lifeless> nope
<lifeless> fixed that to say who I am ;)
<twb> Good, good.
<ogra> twb, were you the guy i discussed the ltsp liveCD with one year ago in #ltsp ? 
<twb> I dunno
<twb> Possibly.
<lifeless> ogra: where I'd like to go from here is getting all the software changes done, so that doing this manually is easy: merging casper changes, adding the udevtrigger too, fixing pxelinux GFXBOOT support
<ogra> look at ltsp-update-kernels for the pxe and tftp stuff
<twb> lifeless: um, the syslinux people (who maintain pxelinux) are adamant that GFXBOOT is the devil, and you should use vesamenu instead.
<lifeless> ogra: then while its still not automated, as long as we include the relevant packages on the livecd, you can manually do livecd sharing at a conference starting with just a livecd and no net
<twb> ...just FYI
<ogra> (and use a maintained tftp server :P)
<lifeless> twb: I know
<lifeless> twb: however, our isolinux is patched with gfxboot
<lifeless> pxelinux shows splash screens ok, but doesn't show the graphical 'loading vmlinuz' progress bar
<ogra> well, it shouldnt be to had to have some hardcded things you can force through a bootoption to get a running tftp server that offers you netbooting
<twb> lifeless: really? I couldn't get it that far.
<ogra> i heard grub2 should be able to do netboot but i never looked deeper ...
<lifeless> twb: splash.rle and splash.pcx need to be in / 
<twb> lifeless: you mean in the tftp server's root directory?
<ogra> that should be able to give you the progress bar
<lifeless> twb: yes
<twb> i.e. /tftpboot, typically
<ogra> if thats no option you probably need to hack up gfxboot to be network aware
<twb> I tried that and it still didn't work.
<twb> ...IIIRC, anyway
<ogra> oh, please use FHS compliant dirs ...
<lifeless> twb: try with the edgy syslinux package copy of pxelinux.0 perhaps
<ogra> /var/lib/tftpboot is the right one
<twb> I apologize; I'm being forced to use RHEL against my will
<lifeless> twb: its a single file :)
<lifeless> twb: just copy it out ;)
<Riddell> glatzor: hi, why do you ask about software-properties?
<Riddell> glatzor: we do yes
<twb> I tried it with the Debian syslinux package, because it was newer.
<lifeless> twb: all I can say for sure is that if you follow the recipe I documented, it will work :)
<twb> Fairy nuff.
<lifeless> ogra: gfxboot is a patch to syslinux, need to find why the patch is not affecting pxelinux.0, but syslinux FTBFS for me
<ogra> hmm
<ogra> i know cbx33 worked with bootmenus in PXE and syslinux, try to catch him tomorrow :)
<ogra> he probably knows more
<glatzor> Riddell: since I am a co author. I offered you to write s-p in a desktop neutral way at Paris, since we reworked the user interface :)
<lifeless> ogra: I've worked with them before :). 
<ogra> ltsp doesnt hide the uncompressing stuff .... 
<lifeless> ogra: had the hardware build process for embedded routers running stripped woody driven completely via pxe 
<ogra> it gets graphical once usplash kicks in
<glatzor> Riddell: currently the code is very gtk centric.
<lifeless> ogra: do you have the splash screen ?
<lifeless> ogra: or no pretty stuff at all ?
<ogra> on my thin clients ? yes
<lifeless> ogra: yeah, the pxelinux one.
<ogra> all the pretty stuff :)
<lifeless> ogra: so you just dont have teh 'uncompressing progress bar' as a gui - you get ...... instead ?
<Riddell> glatzor: times have changed a bit since paris, and the spec we were looking at then didn't happen, so for feisty the plan is to look at software-properties again
<ogra> if you boot a thin client, you see the PXE transfer and after thats done initramfs kicks in with usplash
<glatzor> Riddell: So generally I could move all the GTK parts to a not yet existing class SoftwarePropertiesGtk and make it an inheritance of SoftwareProperties
<lifeless> ogra: right, we are agreeing vigourously
<ogra> yep
<Riddell> glatzor: that sounds lovely
<Riddell> glatzor: did manchicken contact you?
<glatzor> Riddell: do should also correct the spec :) it talks about system-properties and not software-properties by the way :)
<glatzor> Riddell: not yet. mvo told me about your plan
<Riddell> glatzor: I blame mvo for not reviewing it properly :)
<glatzor> Riddell: the alias sounds funny :)
<glatzor> Riddell: so manchicken will do the python-qt part?
<Riddell> glatzor: he's looking at it yes
<Riddell> glatzor: he has commented that it's quite tied to GTK
<glatzor> Riddell: Ii changed a lot in software-properties recently. but the new bits are only available in my local repository, since we need some new build deps in ubuntu before
<Riddell> glatzor: you don't have a branch on launchpad?
<glatzor> Riddell: the source tree of update-manager ist already splitted. 
<glatzor> Riddell: AFAIK there is not even yet a product for software-properties
<Riddell> ah, well that's a good start at least
<Riddell> glatzor: make one make one!
<ogra> isnt that part of synaptic ? 
<Riddell> ogra: it only maskerades as a part of synaptic
<ogra> ah
<Riddell> ogra: synaptic in ubuntu uses software-properties if it's installed, else it uses its own editor
<glatzor> ogra: the source code of the software-properties is currently part of update-manager
<ogra> ah, right, update.manager, not synaptic ...
<glatzor> ogra: Riddell: there will be even a third package in the future: python-aptsources
<ogra> glatzor, btw there is a new g-ss package up ... i think we should put the debian dir into bzr and on LP ...
<glatzor> it provides the abstraction of the sources.list
<ogra> yep, there is a spec for that
<glatzor> ogra: oh, I am not so familiar with the specs for feisty
<glatzor> I mainly work on my stuff :)
<ogra> https://blueprints.launchpad.net/ubuntu/+spec/software-channels
<glatzor> ogra: oh no. it abstracts the content of the sources. list :)
<glatzor> this was a misunderstanding
<glatzor> aptsources determines the current used distribution and which compoents and sub repository are used
<ogra> ah
<glatzor> Riddell: in which time zone does manchicken live?
<ogra> woah, is there still the CC going on ? 
* mdke nods sadly
<sladen> win 103
<dsas> ogra: Still a quarter of the member applicants to go through
<mdke> whoa.
<mdke> 103?
<mdke> that's serious business
<Riddell> glatzor: US I think
<ogra> mdke, well, there was a significant backlog ...
<mdke> yeah
<mdz> BenC: are these "usbdev...resume from 0, parent...still 2" messages normal?
<mdz> BenC: I see them when hibernating my thinkpad
<alex-weej> is there ever going to be printed CDs for non-LTS releases again?
<alex-weej> (for free :P)
<ogra> the marketing gods might know :P
<glatzor> Riddell: I hope that I can work on the desktop neutrality of software-properties next week. so it would be nice if manchicken could get into contact with me.
<alex-weej> when is the next LTS due?
<alex-weej> October?
<glatzor> bye
<Riddell> gnomefreak: great, I'll poke him
* okaratas iyi geceler..
<BenC> mdz: Never seen them before
<Riddell> cjwatson, Mithrandir: fix to casper-reconfigure works well
<mdz> BenC: OK, dmesg via mail or bug?
<BenC> mdz: bug, to make sure I don't let it get lost in my inbox
<mdz> BenC: bug 78634
<Ubugtu> Malone bug 78634 in linux-source-2.6.20 "usbdev4.1_ep00: PM: suspend 0->1, parent usb4 already 2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78634
<BenC> mdz: Thanks
<sirpingalot> hey.. does anyone know of any Xwin equivalent of the console "dialog" command?
<cge> sirpingalot: zenity?
<sirpingalot> cge: hmmm.. looks like wht i'm looking for .. tnx :)
<Nafallo> time to sleep
<Hobbsee> anyone around?
<_ion> Somewhat.
<LaserJock> not that I know of
<Hobbsee> i thought MOTU's were supposed to be able to post to ubuntu-devel
<LaserJock> they should be
<Hobbsee> i've just got an email that my message is waiting to be moderated
<LaserJock> but I think you have to use your preffered email on LP
<Hobbsee> you're kidding...right?
<LaserJock> no
<Hobbsee> you should be able to use any email that's linked to your gpg key
<Hobbsee> i cant put my standard @ubuntu.com ro @kubuntu.org address in as the preferred address, because then LP breaks.
<LaserJock> I think it uses your preferred email, but I could be wrong
<LaserJock> actually, I'm not sure that it does break, now
<LaserJock> I haven't tried to email -devel so I don't know if mine works either
<LaserJock> cause I'm in the same situation you are in
* ajmitch just doesn't post to -devel
<LaserJock> me neither
<Hobbsee> oh *neat*
* Hobbsee merges the two launchpad accounts
<LaserJock> you have 2?
<Hobbsee> yes, hobbsee and hobbsee-ubuntu, as i had to take the @ubuntu.com address out of my normal account, but used it to uplaod
<twb> Hmm, does casper clobber /etc/nsswitch.conf?
<twb> ...or maybe my code isn't writing to it properly :-/
<lifeless> twb: it shouldn't. You can see all of casper in /usr/share/initramfs-tools/
<fabbione> morning
<Hobbsee> morning fabbione!
<fabbione> yo yo
<twb> Has anyone gotten ldap authentication working on top of an netbooting casper system?
<pitti> Good morning
<_ion> 'ning
<somerville32> :] 
<fabbione> Mithrandir: i am doing a refresh of some cluster packages. They are not critical for Herd 2 so they can just wait in the queue.
* jdub hugs fabbione 
<fabbione> hey jdub 
* fabbione hugs jdub too
<fabbione> jdub: how is your sparc treating you?
<Mithrandir> Riddell: rolling you new livefs-es.
<dholbach> good morning
<Mithrandir> Riddell: new -desktop images ready for you
<somerville32> :)
<twb> Mithrandir: nag, nag
<Mithrandir> twb: thanks.
<jdub> http://www.youtube.com/watch?v=ZzDN3YPucpU
<somerville32> jdub: Serious spamming going on in #ubuntu. You have ops :P
<fabbione> jdub: <no comment/>
<fabbione> somerville32: who is spamming?
<somerville32> [04:40]  <somerville32> [Infeliz]  (i=Infeliz@adsl-85-217-21-167.kotinet.com): Kimmo Suokas
<somerville32> [04:41]  <somerville32> [alumno03]  (n=alumno03@62-43-33-240.user.ono.com): alumno03
<somerville32> [04:41]  <somerville32> It appears alumno01 and alumno02 are the same people as alumno03
<somerville32> [/snippet from -ops] 
<mneptok> fabbione: what's the process for getting channel ops?
<fabbione> mneptok: no idea.. i was given..
* mneptok could have dealt
<somerville32> fabbione: and Infeliz was swearing and telling people to stfu and stuff
<fabbione> somerville32: did he stop? 
<mneptok> fabbione: mind throwing me a +o until one of the regular ops unidles?
<somerville32> fabbione, He was just doing it minutes ago. 
<fabbione> mneptok: not at all.. not sure chanserv will allow you
<mneptok> fabbione: we'll see. i'll annoy Seveas later.
<mneptok> (well, "annoy more than usual")
<fabbione> there
<somerville32> Awesome. Thanks a bunch fabbione 
<fabbione> np
<mneptok> fabbione: thanks. i'll keep watch until one of the regulars unidles.
<fabbione> mneptok: sure.. no problem man
<mneptok> grazie, padrone :)
<fabbione> mneptok: non c'e' problema consigliere... e' tutto in famigghia
<mneptok> si ;)
<cjwatson> 18:38 < nixternal> cjwatson: the Ubiquity crash bug I filed that you just fix released (thanks btw), is this tied to the issue I have with alternate CDs not mounting the CDROM?
<cjwatson> nixternal: no, different bug
<cjwatson> Riddell: casper-reconfigure> excellent
<jdub> http://www.youtube.com/watch?v=DQ113000uQg <-- the warty dance
<pitti> carlos: there is no edgy-updates tarball for today
<carlos> let me check...
<carlos> pitti: I think it's still running...
<fabbione> jdub: OH MEN
<pitti> carlos: oh
<pitti> carlos: shall I move the cronjobs to a later hour then? It currently runs at 0700 rookery time
<carlos> pitti: yeah, still running
<pitti> carlos: alright, will check later then; thanks
<carlos> pitti: I don't really know why... I have mine running at 8:45 (it should be rookery time too)
<fabbione> jdub: how drunk were we?
<pitti> carlos: oh, then I better move it to 1000 or so, otherwise I'll always use an old tarball
<carlos> pitti: let me check again when the DB is ready and I will move my script start
<pitti> carlos: that's even better; thanks
<carlos> pitti: atm, Edgy tarball finishes around 9:30
<somerville32> Is that mdz in the middle?
<fabbione> somerville32: yes
<mneptok> that cross-dressing woman on the right is *hot*
* mneptok towels off
<fabbione> mneptok: ahaha
<somerville32> It is really too bad that I don't have sound with flash :/
<somerville32> jdub: Whose the girl in the Ubuntu Videogram Screentest?
<jdub> somerville32: you're not willing to guess? :)
<mneptok> "Flash technolgies allow the seamless delivery of media-rich content to an arbitrary selection of platforms!"
<mneptok> PIA! *WAUGH*!
<somerville32> jdub: I rather not, lol
<mneptok> *F I N I S H   H I M*
<cjwatson> Mithrandir: ubiquity's in the queue now
<Mithrandir> cjwatson: excellent.  I'll byhand the publisher once this run finishes.
<jdub> http://www.youtube.com/watch?v=BoqZEZuUzhI <- hotel at first super secret debian startup meeting :-)
<somerville32> ...
<Mithrandir> pitti: is the new gnome-mount needed for herd 2?  It doesn't look like it.
<pitti> Mithrandir: no, not crucial, thus I didn't ping you
<pitti> but I wanted to upload it so that I don't forget it
<pitti> can't hurt, of course, fixes two bugs
<Mithrandir> oh, sure, it might be useful, but I'll leave it for now
<pitti> ack
<fabbione> cjwatson: 
<fabbione>    * Track silo-installer 1.07ubuntu2 changes (install device2obp, tweak
<fabbione>      PATH).
<fabbione> is there anything i can do in silo-installer to make it less manual for you?
<somerville32> It appears the gtk2.0+ update has some serious regressions
<somerville32> https://launchpad.net/ubuntu/+source/gtk+2.0/+bug/78665
<Ubugtu> Malone bug 78665 in gtk+2.0 "FEISTY: libgtk2.0 upgrade broke things in gtk apps such as mousepad and gedit" [Undecided,Unconfirmed]  
<carlos> pitti: I'm running my script now at 6:00 
<carlos> that should be 6:00 UTC
<carlos> 2 hours and 45 earlier than before
<dholbach> Mithrandir: the libgda2 is not urgent
<Mithrandir> kthx.
<dholbach> on the ppc server cd it fails to mount the CD :-(
* dholbach tries ppc install
<cjwatson> fabbione: not really; I generally have to track changes to included source packages in ubiquity. it's not a problem
<fabbione> cjwatson: ok.
<Mithrandir> dholbach: that's fixed in the new d-i upload, but something went screwed there between the package and the archive, so building CDs fail on i386.
<dholbach> Mithrandir: ahh thanks. I'll install edgy for now, so mvo can do some tests and try herd2 tomorrow again
<pitti> btw, folks, I have been on ISDN all the day, so I cannot help with CD testing today; I'll start doing so as soon as my main network is back (I reported the problem this morning)
<gpocentek> Xubuntu daily-live i386 worked fine, except bug #77978
<Ubugtu> Malone bug 77978 in ubiquity "Crash before partitioning" [Undecided,Confirmed]  https://launchpad.net/bugs/77978
<mvo> Mithrandir: we do not test the server in Testing/Current ?
<incorrect> where would be the right place to talk about backports especially prevu ?
<Mithrandir> mvo: we don't?  It's on the list, see ubuntu 10, 11, 11.1
<mvo> oh, sorry
* mvo goes and adds a server-upgrade test as well
<Mithrandir> :-)
<somerville32> gpocentek, Do you know why there isn't there an Xubuntu test page?
<gpocentek> somerville32: because we didn't wrote it?
<somerville32> We're so slack ;] 
<gpocentek> :)
<cjwatson> gpocentek: d'oh, thanks
<cjwatson> Mithrandir: fix for 77978 is needed for Herd 2 IMO
<somerville32> gpocentek, I'm going to whip something up
<cjwatson> Mithrandir: so I wouldn't stress about publishing the current ubiquity in accepted
<gpocentek> somerville32: thanks!
<Mithrandir> cjwatson: oh well, ok.
<Mithrandir> cjwatson: can you do the fix and get it uploaded then?
<Mithrandir> I'll just turn the publisher back on auto again.
<cjwatson> yeah, working on it
<maxb> pitti: Hello. I found your contact info via launchpad. Would you possibly be able to review and give your opinion on apache2 bug https://launchpad.net/bugs/62748 when you have a moment? Thanks!
<Ubugtu> Malone bug 62748 in subversion "2.0.55-4ubuntu4 update causes svn failure" [Undecided,Confirmed]  
<pitti> maxb: not really my speciality (rather Mithrandir's), but I can have a look
<maxb> ah, right, just found you as uploader. Thanks for looking, though
<pitti> well, I was the poor soul that requested the sync, yes :)
<cjwatson> blink, something's very weird with python's tarfile module
<cjwatson> Mithrandir: this d-i unpack thing is reproducible
<Mithrandir> cjwatson: crack.
<Mithrandir> just what we needed.  Good thing it's not release. :-)
<cjwatson> tar.list() genuinely does stop at that point
<cjwatson> there's another bug in the d-i handler I've noticed, but that's not this problem
<pitti> last time I reported a tarfile bug upstream, it got fixed within a day, but I guess that doesn't really help us now
<Mithrandir> I wonder why this suddenly surfaced with ubuntu10.
<cjwatson> possibly because the names all got longer
<cjwatson> the tar format gets strange for long names
<cjwatson> well, I say "the" tar format. pick one.
<Mithrandir> no longer than debian-installer_20060711ubuntu13, which presumably worked.
<cjwatson> might have been an upgrade since then? dunno
<Mithrandir> oh, true, drescher was dapperised some time back, wasn't it?
<cjwatson> I'm waiting for it to download so that I can test it a bit more thoroughly
<pitti> maxb: doesn't tell anything to me; is it still an issue in feisty with apache 2.2?
<cjwatson> Mithrandir: I'd suggest leaving the publisher on byhand for the moment, TBH
<maxb> I don't know. I don't really have a spare machine around to install feisty on to check.
<Mithrandir> cjwatson: ok, disabled again
<maxb> As far as the launchpad bug is concerned, I was really hoping for some sort of semi-official comment along the lines of "This is bad, we'll consider an edgy update" or "Oops, but we don't have the resources to test a stable update properly now that the world has moved on to apache 2.2"
<cjwatson> maxb: I'd consider that for a stable update, if a core developer took it up and ran with it
* cjwatson <- stable update approver
<dholbach> Mithrandir: the vte update is nice to have, but not urgent either
<cjwatson> Mithrandir: ubiquity 1.3.10 in unapproved
<maxb> In an ideal world, there'd be an apache2 stable update, but I can certainly respect that re-familiarising with apache 2.0 in order to do the necessary testing might be more trouble than it's worth. Either way it'd be nice to have an acknowledgement in the bug noting what the decision is.
<Mithrandir> cjwatson: accepted; I'll byhand the publisher now
<Riddell> Mithrandir: the CD build this morning didn't do kubuntu feisty desktop i386?
<Mithrandir> Riddell: no, we found an interesting bug in python which made it blow up.
<Mithrandir> Riddell: and ubiquity went AWOL in the queue, so until that's published, no need to test.
<pitti> carlos: no ru tsclient.po in today's edgy-updates tarball :(
<geser> Mithrandir: before I close bug #78550: are you happy with the description now?
<Ubugtu> Malone bug 78550 in gnome-chemistry-utils "incorrect description" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78550
<carlos> pitti: fucking cache bug...
<carlos> pitti: let me check with danilo whether he fixed that bug. I thought that wouldn't affect us, but seems like I'm wrong...
<Mithrandir> geser: sure, looks good to me
<Hobbsee> Mithrandir: blowing up python bugs?  COOL!!!
<somerville32> gpocentek, https://wiki.ubuntu.com/Testing/Xubuntu/Current
<geser> Mithrandir: could you please give-back gchempaint? thanks
<Mithrandir> Hobbsee: you have to love the tar file formats.
<Hobbsee> Mithrandir: yep :P
<Mithrandir> geser: given-back.
<Mithrandir> Hobbsee: who needs more than 100-char long file names anyway?
<Hobbsee> Mithrandir: hehe, exactly
<Hobbsee> is jono the only moderator for ubuntu-devel?
<elmo> no, the whole distro team is
<Hobbsee> oh right.  if they could approve my post, i'd be greatful
<heno> Mithrandir: what is the canonical place to notify people to start testing new builds? the wiki page, this chan?
<heno> I mean Herd candidates
<carlos> pitti: could you wait until tomorrow to do the language pack upload?
<pitti> carlos: sure
<carlos> pitti: seems like later today, the cache problem would be deployed in the server where we generate language packs
<carlos> so tomorrow you would get fixed language packs
<pitti> carlos: ok, I'll check out tomorrow's
<Mithrandir> heno: I tend to ask for testing here, but it's not an ideal place.
<Mithrandir> Hobbsee: approved.
<carlos> pitti: thank you
<heno> Mithrandir: perhaps we need a testing-announce list
<Hobbsee> Mithrandir: thanks.  i'm still figting with LP over emails, and accepted stuff.
<gpocentek> somerville32: great, thanks
<Hobbsee> Mithrandir: apparently not all the addresses on the keys of -dev and -core-dev are allowed to post, just those in LP
<Mithrandir> heno: email is kinda async, often images are like "please test $image" then five minutes later "or not, it's broken like $blah".
<heno> right
<heno> Mithrandir: the testing wiki page is kept reasonably up to date though right?
<somerville32> gpocentek, np
<heno> It should in theory always list the latest candidates
<Mithrandir> heno: yes.
<Mithrandir> heno: but it sometimes (like now) lists candidates that, well, aren't.  If people start caring about the versions there and taking them as cues to when to begin testing, I'll try to remove versions when they're known-broken
<heno> cool, or mark them as known broken in some way until a new one is actually built, whatever
<somerville32> elmo: Is there anyway I could check the status of my rt ticket?
<elmo> somerville32: the RT interface isn't public I'm afraid, but you can ask a sysadmin, here on #canonical-sysadmin
<ogra> Mithrandir, is there a blocking reason why there are no new edubuntu isos or are they just not there because i didnt request them yet ? 
<Mithrandir> ogra: they're not there because d-i is fucked ATM.  I could spin you livefs-es.
<Mithrandir> (that was a question even with the lack of a question mark)
<ogra> if they are known to be half way sane 
<Mithrandir> I believe they are
<ogra> then shoot :)
<Mithrandir> running
<cjwatson> er
<cjwatson> Mithrandir: Edubuntu needs the same ubiquity fix as is pending publication now ...
<cjwatson> so livefses will need to be rebuilt anyway
<cjwatson> Mithrandir: d-i is happy now
<cjwatson> modulo mirroring and stuff
<ogra> Mithrandir, uhm ... seems my edubuntu-meta upload from yesterday didnt end up on the CD ...
<ogra> colins daily CD report still shows schooltool and lilo as broken ...
<cjwatson> did you get a mail acknowledgement for it
<ogra> drop the CDs for now, i have to look whats wrong after the edubuntu meeting
<cjwatson> ?
<ogra> i got an accepted mail ...
<ogra> To: 	ogra@ubuntu.com, feisty-changes@lists.ubuntu.com
<ogra> Subject: 	Accepted edubuntu-meta 1.23 (source)
<cjwatson> it should end up on the next round of CDs, then
<cjwatson> might not have been in the previous round, but that isn't important
<ogra> looked fine to me
<Mithrandir> cjwatson: press reload in your web browser.
<Mithrandir> s/cjwatson/ogra/
<Mithrandir> cjwatson: ah, point.
<ogra> Mithrandir, i'm getting the cd healthreport by mail ...
<cjwatson> ogra: the mailed report was based on CDs that don't matter any more
<ogra> ah, ok
<cjwatson> who cares if it wasn't on the *last* one :-)
<Lure> Mithrandir: is it known that kubuntu daily-live i386 is missing?
<ogra> then ignore my previous words :)
<cjwatson> Lure: yes
<Mithrandir> Lure: yes, it's a python bug which made a d-i upload blow up.
<cjwatson> Lure: it should be fixed very shortly
<Lure> cjwatson: ok, no pb will download then later
<heno> Riddell: are you using this page for testing https://wiki.ubuntu.com/Testing/Kubuntu/Current or just https://wiki.ubuntu.com/Testing/Current
<Hobbsee> heno: which one's better for us to use?
<heno> I'd like to put them all on the form https://wiki.ubuntu.com/Testing/Current/*buntu
<heno> so there is some consistency
<Hobbsee> heno: sure, OK
<heno> I'll move it there and just put a forward
<heno> Riddell: please ACK when you are around ^
<Riddell> heno: second one
<Riddell> heno: https://wiki.ubuntu.com/Testing/Current is the one I'd expect to be used
<heno> Riddell: ok, I'm about to splitt that up into separate *buntus
<Hobbsee> Riddell: i suspect that we're all using different sections of the wiki :P
<heno> which is bad :)
<Riddell> heno: good with me
<heno> ok, cool
<Mithrandir> Hobbsee: the tuxguitar licence bug seems to have been fixed in Debian, so feel free to reask for a sync.
<Hobbsee> Mithrandir: right
<incorrect> is this the right place to talk about backports especially prevu ?
<bhale> incorrect: probably fair enough, but you need jdub 
<bhale> ugh
<bhale> you need jdong 
<incorrect> jdub?
<bhale> no.
<incorrect> is that a package?
<bhale> jdong is the person behind prevu
<Amaranth> jdong is a person
<incorrect> ah
<incorrect> sorry
<incorrect> my bad
<Lathiat> ppor jdong ;)
<Lathiat> *poor
<incorrect> sorry i didn't know :S
<jdub> heh
<Hobbsee> incorrect: jdong.  and not here.  we dont deal in prevucrack here
<Hobbsee> :)
<incorrect> wibble
<Hobbsee> wobble
<Amaranth> hobbsee: I thought prevucrack was official stuff now
<Hobbsee> Amaranth: i never heard that
<Amaranth> official tool of the official backports team ;)
<Hobbsee> ah
<Hobbsee> dunno about that
* Hobbsee isnt on that team
<Amaranth> either way, seems harmless enough
<Amaranth> it just automates what the backports team does anyway, it doesn't hack packages to work on older versions or anything
<Hobbsee> heno: i moved the content of /testing/kubuntu/current to https://wiki.ubuntu.com/Testing/Current/Kubuntu - hope that's what you wanted to do
<Hobbsee> Amaranth: true.  i've just seen people attempt to backport crack with it :P
<Hobbsee> like, dbus, then whine that the deps dont work
<Amaranth> but that crack ftbfs so it's all good :)
<heno> Hobbsee: Yes, I was merging if from Testing/Current too. I think we even had an edit conflict :)
<Amaranth> someone i know tried using it to backport hal and dbus and rhythmbox to dapper for ipod support
<Hobbsee> heno: argh, sorry!
<Hobbsee> Amaranth: yeah.  silly people.
<heno> np
<Hobbsee> Amaranth: and someone tried to backport the feisty kernel to dapper with prevu
<Amaranth> *headdesk*
<thom> rofl
<Hobbsee> hehe
<Hobbsee> hey thom 
<Hobbsee> Amaranth: which is why i would suggest that they should have kept prevu private
<Amaranth> as long as it doesn't _do_ it i don't see the harm
<Amaranth> i think the hope is people will try it on their own before filing a bug asking for it
<cjwatson> it can't without archive admin approval, which wouldn't be given
<Hobbsee> cjwatson: was that related to kernels and the like?
<Hobbsee> Amaranth: true. 
<Amaranth> although if they do that and it works i bet they wouldn't file a bug
<Hobbsee> evening sabdfl 
<cjwatson> Hobbsee: regarding direct uploads from prevu to *-backports
<cjwatson> i.e. Amaranth's comment "as long as it doesn't _do_ it"
<Hobbsee> cjwatson: ahh, right
<sabdfl> hi Hobbsee
<Hobbsee> :)
<jdub> sabdfl: oh, you might dig some of the old school videos i put up on youtube -> youtube.com/jeffwaugh
<jdub> happy memories
<Treenaks> http://foodfight.org/movies/Ubuntu%20Fanpeople/Jeff%20Waugh.ogg
<jdub> oh yeah!
<jdub> dude, can i put that up?
<jdub> it'll go well with the other one :)
<Treenaks> jdub: sure
<sabdfl> jdub: damn, that JUST PLAYED!
<sabdfl> (plus it's a cool vid ;-))
<jdub> i think that's 'cos treenaks has something special on his site -- cortado?
<Treenaks> jdub: no
<Treenaks> jdub: it's just ogg files with the right mime-type
<sabdfl> is that some sort of feisty ogg player plugin we install?
<jdub> ah, so it does the proper totem plugin foo
<jdub> yes, totem is now fully awesome
<Treenaks> sabdfl: There is a totem-firefox-plugin thing that works really great in edgy (and feisty) for me
<jdub> it mimics quicktime and wmp
<jdub> RAW POWER.
<Treenaks> I'm having some sound problems on amd64 though
<Treenaks> But that bug is going to be fixed :)
<Mithrandir> *sigh*; powerpc still oversized.
<EmxBA> (msg sabdfl there?
<EmxBA> :)
* Mithrandir wonders what he should throw off the PPC CD.
<Hobbsee> Mithrandir: the biggest package?
<Mithrandir> Hobbsee: ooo? :-P
<Hobbsee> Mithrandir: there's a good start
<Hobbsee> Mithrandir: the logic being, that if you throw off one of the biggest ones, you wont have to deal with ppc being oversized again for a long while :D
<Mithrandir> Hobbsee: that's a nice theory.
<jdub> Treenaks: hrm, what's the original date on that sucker? :)
<Mithrandir> cjwatson: got any suggestions?  I've gone through the list of changes from herd1 and there's nothing which has really changed there, just new versions, etc.
<alex-weej> is feisty+1 LTS?
<alex-weej> and can i order some free CD's NOW so i'm first in line? :P
<Mithrandir> alex-weej: it has not been announced, but my personal guess is no.
<mneptok> alex-weej: the official Canonical crystal ball is out being cleaned ATM ;)
<alex-weej> hehe
<alex-weej> the printed CD's were a great way to convince would-be users that ubuntu isn't just some bedroom project
<mneptok> (even though it is)
<mneptok> oops. inside voice, mnep. :/
<Hobbsee> mneptok: even though it is what?
<thom> hah.
<mneptok> Hobbsee: a "bedroom project," Miss Sexy.
* mneptok woggles an eyebrow at Hobbsee 
<Treenaks> jdub: probably 2005-10-18 (as it was my birthday..)
<Hobbsee> mneptok: oh, right.  thought you were saying it was a LTS.
<Hobbsee> mneptok: and no, i'm not interested in your bedroom.
<mneptok> it is, if LTS = Let's Talk *SEXY*!
<mneptok> Hobbsee: you are obviously a woman of taste and discretion ;)
<Hobbsee> mneptok: :P indeed
* mneptok weeps gently
<jdub> Treenaks: :)
<Hobbsee> poor mneptok 
<mneptok> Hobbsee: my cup of insincerity is already full, but thanks anyway :)
<Hobbsee> :P
<mneptok> jdub: ping
<jdub> mneptok: pong
<mneptok> jdub: mind a /query ?
<jdub> mneptok: ok
<cjwatson> alex-weej: no future LTS schedule has been set yet
<Mithrandir> please test i386 and amd64 alternate ubuntu cds.
<Mithrandir> (PPC is going for a respin soon)
<pitti> Riddell: I'm sure that there was a bug for the recent 'hal upgrade kills automounting for users with the 3rd party KDE packages'. bug 74236 is a dup of that, but I cannot find the original one; do you happen to know it?
<Ubugtu> Malone bug 74236 in hal "Kubuntu: HAL doesn't automount USB devices on KDE 3.5.5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/74236
<Riddell> pitti: https://launchpad.net/bugs/72869
<Ubugtu> Malone bug 72869 in kdebase "Latest hal update breaks USB stick mounting in kubuntu dapper kde 3.5.5" [Undecided,Confirmed]  
<Riddell> pitti: I did make an updated hal version for that archive but the guy who was poking me never got back to confirm it
<pitti> Riddell: ah, splendid; thank you!
<Keybuk> is there any way to start f-spot without dbus?
<Mithrandir> -desktop and -alternate ready, all arches.
<Mithrandir> Riddell: doing kubuntu live ISOs now, livefs-es built fine
<Mithrandir> ogra: building edubuntu livefs-es now.
<ogra> yay
<ogra> alternate isos would also be fine if they work now ...
<Mithrandir> ogra: yeah, going to once the kubuntu live ones are finished.  No point in competing for IO on lithium
<ogra> yep
<ogra> i didnt want to be pushy ;)
<jdong> incorrect: if you still need to talk about prevu, we can take it to #ubuntu-motu
<incorrect> thanks jdong
<Mithrandir> Riddell: shiny new -desktop images for you
<Riddell> ooh, thanks Mithrandir 
<seb128> pitti: it looks like there is no -dbgsym for -proposed, is that a known "could be better"? ;)
<jdong> what are the chances that feisty's HAL would work with Edgy?
<jdong> I wanna test the patch for bug 60989 but don't have a feisty install on the particular machine
<Ubugtu> Malone bug 60989 in hal "HAL reports incorrect battery percentages" [Undecided,Needs info]  https://launchpad.net/bugs/60989
<Mithrandir> Riddell: shiny alternate too.
<Mithrandir> ogra: edubuntu install spinning
<Riddell> bling bling
<Hobbsee> bling!
<Mithrandir> ogra: install CDs for you; please test.
<bddebian> Heya
<heno> Mithrandir: Mind if I move the Ubuntu matrix to a sub-page too or is this a bad time?
<Mithrandir> heno: feel free
<bddebian> Mithrandir: Hi, sorry bug you again, but I'm not sure if you ever got a chance to get back to me about what to do about libparagui?
<Mithrandir> bddebian: you need to make sure the LGPL and the GPL are in the orig.tar.gz.
<Mithrandir> easiest way is to get upstream to add them
<bddebian> That's what I was afraid of.  Thanks.  They just need to add it to COPYING?
<Mithrandir> iirc, the copying file there was nonexistent or just contained the gpl blurb, didn't it?
<bddebian> Aye, just gpl
<pitti> jdong: just building the source on edgy should work
<Mithrandir> if it goes in a new file or COPYING or LICENCE or something else isn't something I care that much about.  The main point it needs to be there.
<pitti> seb128: it seems that the relevant buildd chroot does not have pkg-create-dbgsym installed
<Mithrandir> ogra: live images ready too
<seb128> pitti: iz infinity bog then? ;)
<pitti> seb128: yes
<seb128> ok, ta
<ogra_> Mithrandir, TA, rsyncing ...
<jdong> pitti: ok, cool, thanks
<jdong>  -> Cannot install libvolume-id-dev;
<jdong> what's the edgy name for that again?
<jdong> libvolumeid-dev, nvm
<iwj> seb128: Have you seen the mails between Tim Mueller and me ?  I wondered if you had a comment about what order to ship this stuff in.
<crimsun> Mithrandir: please respin xubuntu (daily + daily-live) at your convenience, thank you
<seb128> iwj: hi, yes, I've read those mails. The logical order seems to be to patch gstreamer0.10 and gst-plugins-base0.10 fisrt. Then g-a-i, totem, etc can be updated
<seb128> no?
<jdong> pitti: the hal patch works, awesome :)
<pitti> jdong: !
<pitti> jdong: that's great
<Riddell> Mithrandir: the kubuntu desktop CDs don't seem to have cjwatson's casper patch
<seb128> slomo: around? 
<jdong> pitti: heck yeah, you bet it is :) no more rebuilding hal for us :)
* pitti smells a backport coming
<jdong> pitti: is the patch trivial enough for a SRU?
<pitti> jdong: not really trivial
<seb128> iwj: we should probably do a CVS snapshot for gstreamer and gst-plugins-base0.10, that's the easiest way
<jdong> :(
<jdong> pitti: how often does HAL get hit with some sort of security bug
<seb128> iwj: we will have new version before feisty so that's not an issue to have a snapshot packaged for now
<pitti> jdong: no security updates so far
<jdong> ok, cool
<jdong> well, it needed a libvolumeid-dev build-dep rename
<jdong> so a developer has to upload it to edgy-backports
<pitti> jdong: but the issue is that intrusive patches need proper testing, so if you think about sneaking in the patch into some security update, I have to disappoint you
<jdong> no, I wasn't thinking to sneak it into a security update
<jdong> I was more weighing on the risks of backporting it
<pitti> ah, I see
<pitti> jdong: I can add the alternative build-dep if you want me
<jdong> pitti: yes, that'd be very helpful, thanks :)
<pitti> jdong: I have some fixes pending in bzr head anyway, I'll upload them after the herd-2 freeze
<jdong> cool
<iwj> seb128: OK.  Do you want to do that or do you want to leave it to me ?  If you have a standard approach it's probably better if you do it, but I'm happy to attack it myself.
<geser> Mithrandir: Please give-back kdesvn. Thanks
<iwj> OK, I give up.  How do I do, in Python, the equivalent of strtoul(,,0) ?
<pitti> jdong: libvolume-id-dev | libvolumeid-dev -> that looks correct?
<seb128> iwj: I can do it
<iwj> seb128: Thanks very much.
<seb128> np
<jdong> pitti: yes sir
<seb128> I've to upload the libgimme-codec thing too
<iwj> Do we have local patches to gstreamer packages ?
<Hobbsee> who would i ask about libdvdread3?
<iwj> We need to add dh_gstscancodecs to gstreamer-tools.
<iwj> dh_gstscancodecs> currently sat around on my disk here.
<pitti> jdong: committed; thanks for testing!
<jdong> no prob :)
<Riddell> geser: what's up with kdesvn?
<slomo> seb128: one moment
<Nafallo> Hobbsee: ask and see who answers? :-)
<seb128> iwj: not that many, we have a few of them for ltsp and sinks priorities to use by example
<seb128> adding a new patch is fine
<geser> Riddell: the last try to build failed because subversion was old
<seb128> iwj: could you mail me that patch?
<iwj> seb128: OK.
<ogra_> seb128, i belive the ltsp gstreamer patches are actually dropped now ...
<Hobbsee> Nafallo: true.  trying to see if there's any interest in it.  (keeping one of our patches, instead of saying "if you want libdvdcss2, use an unofficial repo, like debian multimedia)
<Nafallo> Hobbsee: I like that script back fwiw ;-)
<ogra_> (if now, we can drop them as soon as pulse is approved for main and moved)
<seb128> ogra_: that was some random example, the point is that we have a few patches and having an extra one is no problem :)
<ogra_> s/now/not/
<ogra_> seb128, yeah ...
<slomo> ogra_, seb128: the only patches left are priority setting of sinks... i.e. pulse > alsadmix > esd > alsa ...
<Hobbsee> Nafallo: me too -but i didnt want to reintroduce it without someone saying something about it first.  besides, i'd need a sponsor
<seb128> slomo: ok
<ogra_> slomo, well, i'm not yet sure if i use plain pulse or pulses alsa emulation layer for ltsp ... probably the pulse stuff can be dropped as well
<slomo> oh, and a patch for biarch by doko
<seb128> slomo: ok
<iwj> seb128: YHM.
<slomo> ogra_: well it makes sense this way even if you don't use pulse imho... as people who have pulse isntalled will get this used, other's don't see a difference
<crimsun> ogra_: I'd have a wishlist request for pulse that I'll work on shortly (fixing .desktop Comments and) possibly hiding the unnecessary components
<iwj> seb128: Also we have to change some of the gstreamer plugin packages to call dh_gstscancodecs.
<ogra_> crimsun, great ...
<iwj> The only one which g-a-i can install atm is -ugly, and I have a tiny diff for that.  Do you want that too ?
<sivang> dh_getscancodecs... yummy
<seb128> slomo: we need CVS snapshots for gstreamer0.10 gst-plugins-base0.10 and some patching, I'll work on that if that's fine with you
<iwj> s/getscan/gstscan/
<ogra_> slomo, well, i'm only saying that i wont be the one that forces the patches to stay for ltsp :)
<seb128> iwj: yes please
<slomo> seb128: sure, that's fine
<crimsun> ogra_: how does hiding the menu entries for most desktop entries (since one really only needs the applet) sound to you?
<seb128> slomo: ok, thank you
<ogra_> crimsun, how evil do you consider using /etc/asound.conf with 
<ogra_> pcm.!default {
<ogra_>         type pulse
<ogra_> }
<ogra_> ctl.!default {
<ogra_>         type pulse
<ogra_> }
<ogra_> ??
<ogra_> crimsun, sounds good ...
<slomo> seb128: but be aware that the cvs snapshots use -Werror... might be that stuff fails to build on some archs or after some random library update, no idea
<crimsun> ogra_: not at all evil; that's what I added (well, per-user) to asoundconf in the most recent alsa-utils upload
<iwj> seb128: Oh, re that patch: since it edits a Makefile.am you have to run automake too.
<ogra_> ah, cool but we wont have a package providing a system /etc/asound.conf ?
<seb128> slomo: don't worry, I've already packaged CVS snapshots and that's feisty, we can fix things ;)
<iwj> seb128: But the patch I sent you doesn't include the results of running automake.
<crimsun> ogra_: currently we don't; asoundconf only touches per-user asoundrcs and not the system-wide /etc/asound.conf
<seb128> iwj: ok, noted
<ogra_> crimsun, perfect ... then ltsp-client can install it in the client chroot and i'm set :)
<crimsun> ogra_: great :)
<crimsun> ogra_: oh, that will require the promotion of libasound2-plugins, btw
<ogra_> oki, i'll wirte a MIR
<crimsun> great, thanks!
<ogra_> *write
<iwj> seb128: YHAM
<ogra_> crimsun, eeek ... "Depends: libasound2 (>> 1.0.12), libc6 (>= 2.5-0ubuntu1), libjack0.100.0-0 (>= 0.101.1) ..."
<crimsun> ogra_: hmm, that's kinda nasty, since it pulls in libjack0.100.0-dev
<ogra_> can we compile it without jack without breaking it ? 
<seb128> iwj: "YHAM"? what does that one mean? ;)
<crimsun> ogra_: we could try dropping the jack plugin
<ogra_> i'll do a test compile if i'm done with iso testing
<iwj> You Have Another Mail :-).
<seb128> ah ok ;)
<iwj> seb128: Thanks for your help.
<seb128> np
<dholbach> can we make a new policy: everybody who uses an abbreviation and it's not in /usr/bin/wtf will patch bsdgames to include it? ok? ;-)
<seb128> I'll have a look on that and let you know if I need anything else
<iwj> seb128: Right.
<iwj> seb128: (I'm not very IRC-attentive right now so if you don't get me on IRC try email or feel free to phone +44 1223 561028 and we can continue on IRC or I can phone you back.)
<seb128> iwj; ok, noted, thank you
<Nafallo> dholbach: is it in universe? ;-)
<dholbach> Nafallo: yes
<Nafallo> nice :-)
<ogra_> feisty-live-i386.iso            10-Jan-2007 14:42  699M 
<ogra_> geez, i didnt even notice that ... living on the edge :)
<crimsun> ogra_: http://www.sh.nu/~crimsun/alsa-plugins/alsa-plugins_1.0.13-3ubuntu1_source.changes  (builds & works fine)
<ogra_> crimsun, do you think we need to split the package to still provide an libasound2-plugins-jack ?
<ogra_> or do we simply not care ? 
<ogra_> (i personally don care, but ubuntustudio might get unhappy)
<heno> jdong: see new version of the testing guide
<heno> http://www.ubuntuforums.org/showthread.php?t=331123
<crimsun> ogra_: I'll have a chat with the ubuntustudio folks; I don't see the jack alsa-lib plugin being all that serious since jackd -d alsa -d hw:foo would be used anyway, bypassing said plugin
<ogra_> ah, cool ...
<iwj> Today's my day for programming questions.  Maybe some pygtk expert can help me.  I have a program which is basically a subclass of SimpleGladeApp.  I want to be able to set it to be transient for some other application whose XID I know.
<iwj> I can find the gtk.Window for the application and call set_transient_for, but gtk.Window.set_transient_for expects a gtk.Window.
<iwj> I can make a gtk.gdk.Window out of an XID with gtk.gdk.window_foreign_new.
<iwj> But I don't seem to be able to (1) find the gtk.gdk.Window inside a gtk.Window or (2) construct a gtk.Window which is just a wrapper around a gtk.gdk.Window.
<jc-denton> hi all
<jc-denton> hi all
<jc-denton> i tried to compile 2.6.19 with the ubuntu .config
<jc-denton> however it does not find the root fs
<jc-denton> i thought first that i just have to compile the ide driver in the kernel instead of as module
<pitti> jc-denton: you need a matching initramfs
<jc-denton> i think so too
<jc-denton> how can i do that
<jc-denton> i never used initramfs
<pitti> jc-denton: or additionally compile in the file systems you need
<pitti> jc-denton: but that's really an #ubuntu question, btw
<pitti> jc-denton: please look at update-initramfs(8) and followup in #ubuntu
<jc-denton> ah the file systems are also as module
<jc-denton> heh
<jc-denton> thx
<jc-denton> i just ask here
<jc-denton> cos people on #ubuntu don't have a clue normally
<jc-denton> ext2 and 3 is in the kernel
<cjwatson> iwj: (1) there's a gtk.gdk.Window for each widget, so it's listed in the gtk.Widget docs
<cjwatson> iwj: .window attribute on the widget (including the top-level gtk.Window if you like)
<cjwatson> iwj: for (2), gtk.Plug may help, although I don't recall whether set_transient_for works properly with a Plug as the parent; try it and see :-)
<cjwatson> but certainly Plug is the way to get at window IDs from other processes in terms of GTK widgets
<cjwatson> but failing that, perhaps w.window.set_transient_for(gtk.gdk.Window) will DTRT well enoughh
<iwj> gtk.Widget.window> Oh, yes, that's exactly what I want.
<cjwatson> enough
<iwj> I think it will, yes.
<iwj> Plug is obviously not the right answer.  If I tell it to make the window transient for a Plug then it'll probably eat its own small intestine after crawling through the large intestine.
<iwj> spammers--
<cjwatson> giggle, although Plug is not entirely broken since ubiquity uses it
<cjwatson> I have seen transience issues there, but it was the other way round - I was trying to make child windows of the Socket end up properly transient on the Plug
<iwj> I had to call w.realize() but that hardly seems too bad.
<mvo_> iwj: SoftwareProperties.py has a example for the tranisent stuff you need, but it seems you have figured it all out already :)
<crimsun> ogra_: splitting the source is my recommended approach upon consultation with the UbuntuStudio and JACK devs (to avoid a feature regression)
<Mithrandir> Riddell: that'd be weird
<Riddell> Mithrandir: the alternate CD says no kernel modules found
<MagiqueM> hi all
<Mithrandir> Riddell: are you sure you're grabbing the latest ones?
<MagiqueM> where can i find ubuntu kernel patches?
<MagiqueM> i mean the patches that ubuntu ships with its kernel
<kylem> MagiqueM, www.kernel.org/git/
<MagiqueM> thanks a lot
<MagiqueM> that page takes a lot to load :)
<Riddell> Mithrandir: definately synced to daily/current and daily-live/current
<Riddell> Mithrandir: casper-reconfigure still has "echo "$0: package '$package' is not installed" without the needed redirect
<Riddell> Mithrandir: I don't see an upload of casper in feisty-changes
<Mithrandir> nobody has asked for an upload of casper; I saw you needed a new ubiquity.
<MagiqueM> kylem: it tells me "Generating......" but nothing happens
<MagiqueM> nor www.kernel.org works :(
<Riddell> Mithrandir: kubuntu (and xubuntu I guess) need cjwatson's latest change to casper, could you upload it?
<Mithrandir> Riddell: which bug # is this?
<Riddell> Mithrandir: it doesn't have a bug number as far as I know
<kylem> MagiqueM, try www2.kernel.org/git
<Mithrandir> Riddell: what's the bug, then?
<Riddell> Mithrandir: if casper-reconfigure is called on a package that isn't installed it outputs an error message to debconf which gets confused, it needs redirected to stderr
<Riddell> Mithrandir: it's a 1 line commit to casper by cjwatson
<Mithrandir> hmm
<Mithrandir> I wonder why we haven't seen that before.
<iwj> mvo_: Thanks :-).
<iwj> mvo: Would you care to take a look at http://www.chiark.greenend.org.uk/~ian/bzr/gnome-app-install--codecs/ ?  (Pushing as I write.)
<jdub> ha ha --
<iwj> I haven't given it a thorough test yet - in particular I worry that I might have regressed the MIME stuff and I haven't tested it.
<Mithrandir> Riddell: I'm on my way out the door, I'll do it in a couple of hours.
<iwj> But I thought that since I had something which at least doesn't bomb immediately with a syntax error I should pass it on.
<iwj> Jesus H Christ!  80Mb!
<mvo_> iwj: I'm happy to have a look, let me know when the push finished
<iwj> I'm going to do some thing with rsync or something first.  An 80Mb upload with bzr push won't finish any time soon.
<ogra_> crimsun, ok
<mvo_> ok
<cjwatson> Mithrandir: I mentioned it yesterday on IRC but you may have missed it
<MagiqueM> i can't find ubuntu kernel patches...
<cjwatson> Mithrandir: I think we have seen it before, but only intermittently
<MagiqueM> where can i find them?
<cjwatson> Mithrandir: I've certainly heard of similar issues before, but this was the first time I figured out the cause
<MagiqueM> ???
<MagiqueM> kylem i can't find ubuntu patches there
<MagiqueM> :(
<iwj> mvo_: That upload has finished.
<mvo_> iwj: I'm bzr getting it now
<Riddell> Mithrandir: powerpc also complains about no kernel modules.  my seeds and meta package are up to date
<Riddell> Mithrandir: alternate CD that is
<MagiqueM> does Ubuntu kernel have some cpu-related patches applied?
<MagiqueM> none answering?
<iwj> mvo_: I'm going to go and catch the train to climbing soon, so if you want to talk about my crazy g-a-i changes send me mail or catch me tomorrow.
<mvo_> iwj: ok. have fun climbing!
<mvo_> bzr is stll checking out
<iwj> Heh.
<iwj> mvo_: Thanks, and goodnight.
<cjwatson> MagiqueM: you could always get the Ubuntu source package (apt-get source linux-source-2.6.17, or whatever version is appropriate) and diff it against the corresponding upstream kernel yourself
<cjwatson> Riddell: argh, somebody forgot to update the installer seed ...
<cjwatson> fabbione: you need to update the installer seed when you change the kernel version in debian-installer
<cjwatson> note for the future
<Riddell> cjwatson: at least it's not me going mad then
<MagiqueM> cjwatson: but is simplier to have a diff file or a patch-set
<Keybuk> aren't all the ubuntu changes under ubuntu/ now?
<cjwatson> MagiqueM: for 2.6.17, http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.17/linux-source-2.6.17_2.6.17-10.33.diff.gz
<cjwatson> it's not packaged that way for all kernel versions (for some of them it's just a .tar.gz)
<cjwatson> Keybuk: only new drivers
<MagiqueM> thanks a lot
<Keybuk> alternatively just use git?
<fabbione> cjwatson: i see .. ok.. they were not updated since .19-7 and we did have a .20-X installer..
<cjwatson> fabbione: which you uploaded :)
<fabbione> hem.. no
<fabbione> debian-installer (20061102ubuntu7) feisty; urgency=low
<fabbione>   * Move to 2.6.20-2 kernels.
<fabbione>   * Add block-modules and message-modules to hd-media images.
<fabbione>  -- Colin Watson <cjwatson@ubuntu.com>  Mon, 18 Dec 2006 17:02:03 +0000
<fabbione> so i did grep for -20-2 and there was no match
<fabbione> anyway
<fabbione> noted :)
<cjwatson> ah, true, I missed it that time
<cjwatson> you uploaded the switch to 20-5, though. :)
* fabbione 5^s cjwatson 
<cjwatson> anyway, done now
<cjwatson> Riddell: please merge?
<Riddell> cjwatson: doing
<cjwatson> ogra_: ^--
<cjwatson> I'll do Xubuntu I gues
<cjwatson> s
<gpocentek> cjwatson: will do
<gpocentek> (xubuntu)
<cjwatson> gpocentek: ah, thank you
<cjwatson> I forgot you'd changed nick
<MagiqueM> cjwatson: does diff.gz it contain the applied patch list?
<cjwatson> MagiqueM: well, I don't know where else it'd go. but please don't ask such questions here; this is a developer coordination channel
<cjwatson> people asking questions here are expected to be developers and to have done extensive research themselves already
<MagiqueM> i googled a lot before aking here
<Riddell> MagiqueM: #ubuntu-motu for packaging questions
<MagiqueM> *asking
<cjwatson> MagiqueM: research> e.g. reading and understanding the structure of the .diff.gz
<MagiqueM> ok i'll try
<MagiqueM> thanks
<cjwatson> I'm sorry, but we need to keep this channel reasonably clear
<MagiqueM> i understand
<Riddell> cjwatson: merged
<cjwatson> thanks
<gpocentek> cjwatson: xubuntu merged too
<cjwatson> thanks; I'll do Edubuntu for expediency's sake
<cjwatson> ogra_: cancel the above ping; I've merged the Edubuntu seeds
<mvo_> can someone of archive-admins please reject my app-install-data-commercial upload to edgy-proposed? there is a minor bit missing
<mvo_> nevermind
<cjwatson> mvo_: it got auto-rejected anyway because you uploaded source+binary
<mvo_> yes, just got the mail 
<Riddell> cjwatson: can I respin kubuntu alternate CDs?
<cjwatson> Riddell: yes, the HTTP mirror on bazaar.launchpad.net has updated so it's safe
<Riddell> cjwatson: done kubuntu, should I do u, ed and xubuntu too?
<ubuntu-l1nux> Hey all
<ubuntu-l1nux> I have a problem
<ubuntu-l1nux> Anyone can help me?
<azeem> ubuntu-l1nux: please ask in #ubuntu
<jdong> heno: that looks beautiful
<ubuntu-l1nux> Hmm, it is a kernel problem. Is there any kernel room here?
<jdong> heno: I actually would not advise opening that thread up for any commenting; in about 2 days you'll have 20 pages
<jdong> ubuntu-l1nux: if there was a ubuntu kernel channel, what would you name it?
<heno> jdong: hm, ok so a separate questions thread then
<ubuntu-l1nux> jdong: ubuntu-ker?
<jdong> heno: right. Keep the directions clean and clear
<cjwatson> Riddell: sure, please do
<ogra_> cjwatson, thanks
<Riddell> ubuntu alternate CDs done
<Riddell> gpocentek: xubuntu alternate CDs done
<gpocentek> Riddell: thanks
<Riddell> ogra_: edubuntu done
<ogra_> thanks !
<Mithrandir> cjwatson: hm.  Do you think we need new ubuntu livefs-es too, then?
<Keybuk> someone name me an editor that breaks hardlinks, or has an option to turn it on
<Mithrandir> Keybuk: doesn't emacs?
<Keybuk> not by default, afaict
<Keybuk> I get IN_CREATE(.#wibble) ... IN_MODIFY(wibble) ... IN_DELETE (.#wibble)
<elmo> Keybuk: vi is traditionally the one that does
<maxb> I just tried vim. It did not.
<elmo> hang on, what?
<elmo> emacs does break hardlinks
<elmo> at least here
<Keybuk> isn't here
<Keybuk> -rw-r--r-- 2 scott scott 75 2007-01-10 19:38 wibble
<Keybuk> -rw-r--r-- 2 scott scott 75 2007-01-10 19:38 wobble
<Keybuk> still hardlinked to each other
<elmo> -rw-r--r-- 1 james james  9 Jan 10 19:38 bar
<elmo> -rw-r--r-- 2 james james 19 Jan 10 19:37 foo
<mjg59> elmo: You were looking for me earlier?
<Keybuk> weird
<elmo> mjg59: yeah, do you have a macbook pro?
<mjg59> Nope
<mjg59> No Apple portables
<elmo> duh
<mjg59> I've got an iMac that's supposed to be going to Colin when he has time to look at it
<maxb> Keybuk: vim's behaviour can be controlled with the backupcopy option.
<Keybuk> maxb: changing it made no difference
<Keybuk> it still didn't break the hardlink
<maxb> The docs say it should, and it did for me. What exactly did you do?
<Keybuk> ln /tmp/foo/wibble /tmp/foo/wobble
<Keybuk> vi /tmp/foo/wibble
<Keybuk> :se backupcopy=auto,breakhardlink
<Keybuk> edited some thing
<Keybuk> :w
<Keybuk> still hardlinked to each other
<maxb> worksforme
<Keybuk> flat out doesn't for me
<Keybuk> you using feisty?
<maxb> edgy
<Keybuk> doesn't work on dapper or edgy for me either
* Keybuk isn't being strange
<Keybuk> paperboy scott% ls -l /tmp/foo
<Keybuk> total 8.0K
<Keybuk> -rw-r--r-- 2 scott scott 29 2007-01-10 19:49 wibble
<Keybuk> -rw-r--r-- 2 scott scott 29 2007-01-10 19:49 wobble
<Keybuk> paperboy scott% vi --cmd ":se backupcopy=auto,breakhardlink" /tmp/foo/wibble
<Keybuk> paperboy scott% ls -l /tmp/foo                                              
<Keybuk> total 8.0K
<Keybuk> -rw-r--r-- 2 scott scott 36 2007-01-10 19:51 wibble
<Keybuk> -rw-r--r-- 2 scott scott 36 2007-01-10 19:51 wobble
<gpocentek> yay, xubuntu daily iso is OK (amd64) :)
<cjwatson> Mithrandir: the installer seed doesn't affect livefses
<cjwatson> mjg59: re the imac, it's blocked until I get my car repaired; sorry for forgetting to tell you
<cjwatson> mjg59: with any luck that'll be worted out tomorrow
<cjwatson> er, sorted
<mjg59> cjwatson: Yeah, no problem
<mjg59> cjwatson: I'm leaving the country on Friday, back a week on Monday
<mjg59> Ought to be around Friday afternoon until 4 or so
<cjwatson> ok, I'll make sure to pick it up before then
<cjwatson> is it carryable, in extremis?
<cjwatson> I really don't actually *want* to lug a computer around Cambridge on foot, but if I have to ...
<Mithrandir> cjwatson: no, but the casper package does.
<cjwatson> Mithrandir: oh, in that case yes
<mjg59> cjwatson: In extremis, but I wouldn't recommend it
<Mithrandir> cjwatson: in extremis, take a cab?
<cjwatson> good plan
<Mithrandir> casper source publishing run going.
<Mithrandir> then I'll kick the queueu builder, then wait for it to build, then new livefs-es, then new live isos.
<Keybuk> mjg59: what flight you on?
<Amaranth> Keybuk: that trick in your blog is evil
<Keybuk> Amaranth: gotta go with what works <g>
<Amaranth> heh
<Amaranth> i'll probably end up using it
<Amaranth> but wow
<mjg59> Keybuk: Singapore Airlines
<mjg59> Whichever one arrives at 07:15 on Sunday
<Keybuk> heh, that's 25 mins after my flight leaves
<mjg59> Leaves?
<Keybuk> I'm on a QF flight, that's probably a BA code share, but doesn't admit to being so
<Keybuk> for Sydney
<mjg59> Ah
<mjg59> So you'll be there Tuesday?
<mjg59> Or late Monday?
<Keybuk> hmm, sorry, misread you
<Keybuk> mine leaves Heathrow 0650 on Friday
<Keybuk> and arrives 1930 on Saturday (AU time)
<mjg59> Ah, right
<Keybuk> you have a long stop-over?
<mjg59> Couple of hours
<Keybuk> how come you arrive at an odd time?
<mjg59> Leaving about 12 hours after you
<Keybuk> oh, I see
<Keybuk> duh
<Keybuk> my brain is not in gear, clearly
<mjg59> Worked out that if I stay awake until we hit Sinagpore and then sleep, I'll be on .au time
<mjg59> Which is, coincidentally, roughly where I am anyway
<mjg59> So it's all good
<LaserJock> is Universe also frozen for Herd 2?
<dsas> LaserJock: No, just requires manual poking.
<siretart> LaserJock: according to the announcement to u-d-a, no
<siretart> upload of ubiquity to edgy? is there a release of 6.10.1 planned?
* gnomefreak thought only LTS was gonna have point releases
<LaserJock> gnomefreak: no, I think any release can have them if it's needed
<Mithrandir> casper binary publishing run running
<sacater_> hi all, just re-installed ubuntu (dont ask why :P), but i want to disable grub, how do i do it?
<Treenaks> sacater_: a) you don't want to disable grub; b) this is a development channel, please ask on #ubuntu
<sacater_> okies
<sacater_> ty
<sacater_> :P
<lifeless> moining
<BenC> can I get an archive person to process linux-backports-modules-2.6.20 through NEW please?
<Mithrandir> BenC: is it urgent?
<BenC> Mithrandir: Oh, right, we are in freeze for Herd 2, it can wait
<Mithrandir> thanks. :-)
<BenC> Mithrandir: are we in a state where we can do uploads and it wont bother you, or is that functionality not working yet?
<Mithrandir> BenC: they end up in a queue where I can ignore them, so as long as you don't upload a zizzillion packages, I don't care.
<Mithrandir> and anything to universe is just shoved through when I see it
<BenC> Mithrandir: ok
<somerville32> Mithrandir: Oh, can you approve pyNeighborhood then? :)
<Mithrandir> somerville32: no, it's not in unapproved, it's in new and since I'm busy and NEW takes time (and it's 22:47 here now), I'm not going to do it until herd 2 is out.
<somerville32> Mithrandir, alright then :)
<somerville32> If anyone is interested in helping to write the Heard 2 Announcement, we're on Gobby.
<mdke> somerville32: make sure you spell it "Herd"
<mdke> :)
<somerville32> :D
<somerville32> I have <g>
<Treenaks> hearth?
<LaserJock> somerville32: and not Hurd
<somerville32> :P
<lifeless> hUrd is the new fisty
<somerville32> Does the sister projects usually write their own?
<LaserJock> yeah
<LaserJock> I think so
<bddebian> Someone say Hurd? :-)
<mc44> Hurd II: Die Hurder
<LaserJock> :-)
<LaserJock> mc44: or is that "Revenge of the Hurd"?
<mc44> :)
<ajmitch> Ubuntu 2050
<LaserJock> man, Debian will need Toy Story 5 to come out or something
<LaserJock> to get enough release names, either that or they'll have to slow down that mad pace of a release cycle
<ajmitch> I'm sure they can dig up names
<cjwatson> siretart: bug 67130 is worth a point release to fix, I think
<Ubugtu> Malone bug 67130 in ubiquity "mount points preparation locked - "No root file system"" [Critical,Fix committed]  https://launchpad.net/bugs/67130
<LaserJock> Debian 10.3 "3rd Sheep"
<cjwatson> gnomefreak: we first did a point release for 6.06, it's true, but we had contemplated one for 5.10 - it just turned out not to be worth the effort, whereas for 6.06 it was
<ogra> Mithrandir, still around ? edubuntu doesnt look good, seems i merged a patch from debian that breaks the mirror handling for non-networked installs ... i'll prepare a fixed ltsp now
<ogra> :(((
<msikma> Hi everybody. I don't think that #ubuntu can do anything about this, but maybe you can: the download toold Ubuntu 4.04 release seems to lead to a 403 error.
<msikma> http://old-releases.ubuntu.com/releases/warty/warty-release-install-i386.iso This one, that is.
<cjwatson> msikma: one moment
<elmo> cjwatson: heh, no .pool ;-)
<cjwatson> there is on lithium
<elmo> ah, ok, sorry, our bad, one sec
<msikma> If it could be fixed at some point, that would be great! The torrent link also seems to be inoperable. I realize 4.04 is officially obsolete, but I'm going to use it on an old computer on which it used to run faster than 6.06.
<elmo> torrent won't work, I'm fixing http/ftp/rsync
<mdke> elmo: quick question about torrents. Does it make a difference from which mirror a user downloads a torrent from (I know nothing about em, but need to know to fix a website issue)
<elmo> mdke: no
<mdke> great
<mdke> elmo: thanks. were you able to view that md5sum bug, btw?
<elmo> yeah, I'll try and reply in a bit
<mdke> elmo: great, I wait with baited breath. thanks again
<HrdwrBoB> bated
<ogra> cjwatson, can you approve an upload of ltsp for me so i get the package fixed for tomorrow morning ? 
<elmo> cjwatson: eh, dapper's in the old-releases tree?
<cjwatson> elmo: .0, yes
<cjwatson> elmo: .1 is on releases.u.c
<mdke> HrdwrBoB: my breath is baited, dammit
<elmo> cjwatson: duh, sorry
<cjwatson> is a touch confusing
* HrdwrBoB makes a point to stay away from mdke's breat 
<cjwatson> ogra: if it's in the queue right now
* mdke nods at HrdwrBoB 
<cjwatson> 'cos I've been up at 0630 last two days and need my ugly sleep
<ogra> cjwatson, uploaded 1min ago ... 
<msikma> Just wondering, does anyone know of any other location from where I can get 4.04? I can't seem to find too much on Google except for reviews.
<ogra> its only commenting out three lines ...
<msikma> Oh wait, it isn't 4.04, it's 4.10.
<elmo> 4.04 would be impressive, Canonical didn't even exist then ;-)
<msikma> Stupid me.
<elmo> msikma: anyway, it's syncing now, try again in 30 mins or so and it should be there
<cjwatson> well, not named Canonical, anyway ...
<cjwatson> elmo: thanks
<msikma> elmo: thanks very much. :)
<cjwatson> ogra: can you explain the fix to me?
<cjwatson> ogra: for example why 'add_mirror "$MIRROR"' isn't commented out but the lines around it are?
<ogra> cjwatson, vagrant wrote a unctionn that adds additional mirrors to the clients sources.list ... apparently i only get empty lines on a non networked system  ... i commented the call of the function that does it for now
<ogra> 'add_mirror "$MIRROR"' adds the default mirror ... which is the CD in our case
<ogra> that needs fixing post herd2 indeed ... but for now this workaround is enough (gets us back to the former variant of the mirror plugin as we had it in edgy)
<cjwatson> ogra: well, no, it doesn't, as manage-mirror didn't change from edgy to feisty
<ogra> hmm
<cjwatson> ogra: is it to do with the ltsp-client-builder/build-client-opts stuff?
<msikma> Seems that the ISO is there.
<ogra> let me see ... thats a new one ...
<cjwatson> ogra: this shouldn't block Herd 2 if you've tested this workaround, but I thought it was worth mentioning now anyway
<cjwatson> ogra: (have you tested this workaround?)
<ogra> yes, several times
<ogra> its the add_multiple_mirrors call that breaks it ... 
<cjwatson> ok, I've accepted it, but please make sure there's a bug filed with milestone 'later' or '7.04' or similar strength
<ogra> i was always for just copying the sources.list from the server during CD installs ... but debian freaked out about it ...
<cjwatson> to get it fixed properly
<ogra> i hate the debian "optionitis" some days ...
<ogra> cjwatson, will do
<cjwatson> I'm not familiar with the issues, and it would take some thought, so I don't want to comment on that
<cjwatson> ogra: I'm going to bed now, so you'll probably have to wait until the morning if anything else needs archive admin attention, unless Tollef drops by; you should have the access you need to rebuild Edubuntu CD images
<ogra> right :)
<ogra> thanks for the help :)
<cjwatson> should be ready around 0030 UTC
<cjwatson> np
* ogra wonders why cjwatson is always right ... tsk ... indeed the cause is the debconf value for ltsp-client-builder/build-client-opts
#ubuntu-devel 2007-01-11
<mdke> elmo: still awake?
<elmo> mdke: unfortunately
* mdke nods
<mdke> elmo: I can restrict that wiki page, if you give me the wikiname of the relevant user you think should have access
<ogra> elmo, btw, seems all my mails to edubuntu-devel are swallowed ... 
<elmo> eh, you can?
<elmo> ogra: yes, I know
<mdke> elmo: yes
<elmo> ogra: mail RT - I'll hack on mailman in the morning
<mdke> or rather, I think I can.
<ogra> elmo, so its not a misconfiguration or something ? 
<mdke> elmo: I seem to recall myself and henrik being hardcoded as admins on that wiki
<elmo> ogra: no - the mails are being swallowed and there's no useful reason given
<elmo> mdke: ah, yeah, looks like someone is
<ogra> RichEd maintained the MLs for the last few months ... he might have changed a setting 
<elmo> mdke: I didn't realise ACLs were enabled
<Riddell> Mithrandir: all three kubuntu alternate CDs are good
<ogra> ok, i'll file an RT
<elmo> mdke: anyway - |I don't know who should have access, that's why I was asking you ;-)
<mdke> elmo: oh. I thought it would be a sysadmin
<elmo> mdke: well, see the problem is moin ACLs are about as useful as a burred screw driver
<Laser_away> lol
<elmo> mdke: if you already have admin powers, then it might as well be you
<elmo> because admin powers are binary in moin
<elmo> you either have them for the whole site, or you don't
<elmo> short of chattr +i-ing the file on disk, I can't stop you editing the page, IYSWIM
<mdke> elmo: beneath that it can be page by page though, right?
<elmo> mdke: no, it can't
<elmo> mdke: anyone with 'admin' privs can change the perms on a page
<mdke> yes, that's right
<mdke> elmo: who is hardcoded in there? Is newz too?
<elmo> mdke: whoever's listed on the 'AdminGroup' page
<elmo> so you and newz
<mdke> hmm.
<ogra> Keybuk, still around ? 
<Keybuk> ogra: what's up?
<ogra> Keybuk, cjwatson said he approved ltsp 0.130 but i dont see it on LP anywhere 
<ogra> could you have a look ?
<Keybuk> he did indeed approve it
<ogra> strange ...
<Keybuk> why?
<Keybuk> publisher is on manual
<ogra> https://launchpad.net/ubuntu/+source/ltsp doesnt show it anywhere
<Keybuk> it won't actually get processed until Mithrandir runs it
<ogra> oh
<Keybuk> standard procedure during releases
<ogra> can you do it ? so i can trigger my CDs tongiht or is that an exclusive Mithrandir thing ? 
<Keybuk> no, Mithrandir holds a lock on the publisher
<Keybuk> if he's not here to check, I won't run it in case he's deliberately got it on manual
<Keybuk> and if here's here, he can run it :)
<ogra> well ...
<ogra> Mithrandir, ping, please trigger a build of ltsp, needed for new edubuntu install isos
<ogra> Mithrandir, ltsp 0.130, sorry
<lifeless> mdz: around ?
<mdz> lifeless: yes
<lifeless> got time for a short chat ?
<RedStamp> hello
<RedStamp> If at first you don't succeed, destroy all evidence that you tried
<jdong> is there any way to coerce/bootstrap ubiquity into unpacking into a filesystem that I already mounted?
<jdong> just for fun I'm gonna attempt a Ubuntu install into ntfs-3g
<jdong> because I managed to get a minimalist embedded linux setup working out of NTFS
<mjg59> It's possible
<mjg59> Just miserable
<mjg59> Oh, i see what you mean
<mjg59> jdong: best wait for Colin to wake up
<jdong> mjg59: yeah, it's too late for me, too... worst comes to worst I'll just manually install it
<jdong> next question... how do I modify the initramfs script that finds/mounts the root?
<jdong> where is that script located and what is the safest way to edit it
<keescook> jdong: would a direct debootstrap work for that?
<lifeless> jdong: /usr/share/initramfs-tools/scripts/
<lifeless> jdong: thats where the initramfs is built from 
<jdong> keescook: yeah but then I don't get the fully configured base system :)
<jdong> unless there's another way to activate the hostname and such 
<jdong> heck I'll just rsync an existing installation
<keescook> jdong: really?  I mean, I guess I haven't tried it too much, but installing ubuntu-desktop always seemed to work.  :)
<jdong> is rsyncing / on the livecd and removing casper equivalent to ubiquity? :D
<jdong> lifeless: thanks
<keescook> heh, dunno.  :)
<lifeless> jdong: no
<lifeless> (the rsyncing / question)
<lifeless> jdong: on the livecd, / is not the cd root
<lifeless> jdong: its a unionfs of the squashfs from the cd rom
<jdong> right, but for all intents it's a bootable ubuntu environment, right?
<lifeless> jdong: errr
<lifeless> jdong: FSVO 
* jdong pulls up slang dictionary and feels more culturally depressed
<lifeless> jdong: check /usr/share/initramfs-tools/scripts/casper to see whats involved in mounting / on it
<jdong> ok
<jdong> then I shall just untar one of my root backups onto an ntfs drive :D
<jdong> one more crackpot question....
<jdong> is it technically feasible to have initramfs pivot_root into a subdirectory of a filesystem, if I don't feel like partitioning to dual boot?
<lifeless> jdong: probably via bind mounting
<jdong> i.e. install feisty into /feisty, then modify initramfs to treat /mnt/feisty as /
<jdong> yeah, bind-mount home and the typical virtual fs'es
<jdong> but it looks good in my head :D
<jdong> something keeps on saying in the back of my head that it's a stupid idea though
<lifeless> why are you doing this ?
<jdong> lifeless: I'm working on a bold and reckless idea of installing linux to a pre-existing NTFS drive via ntfs-3g
<jdong> like install ubuntu to c:\Linux and use LILO to boot off it
<jdong> that cuts out the "I don't ubuntu because I don't wanna partition" excuse
<lifeless> scarwee
<jdong> lol yes
<jdong> does the initramfs environment have an awk or something like that?
<jdong> I wanna modify root=/dev/foo syntax to support root=/dev/foo:/Linux
<jdong> an arbitrarily specified subdirectory
<jdong> maybe I should use a separate rootsubdir=/Linux option instead...
<jdong> the scariest part is ntfs-3g doesn't have any permissions support.... other than mounting the entire drive with a uid/gid/umask
<jdong> that'll likely ruin the practicality of this and just make it a digg story :D
<fabbione> morning
<Hobbsee> hey fabbione!
<mneptok> arr!
<fabbione> Mithrandir: if we are still in time, that partman-base upload will allow to install on Niagara again. thanks
<pitti> Good morning
<Hobbsee> heya pitti 
<fabbione> pitti: do you have any clue on what's generating this error: end from FAM server connection
<fabbione>  ?
<fabbione> i can see it on some apps like gthumb or gtkam
<fabbione> when i save stuff in ~/Desktop they don't appear anymore
<pitti> fabbione: uh, fam? that's so prehistoric
<fabbione> or remove and they don't disappear
<fabbione> pitti: yeah but i have ubuntu-desktop installed
<pitti> fabbione: never saw it, and gnome doesn't use either fam or gamin any more
<fabbione> and i am 100% sure i didn't play with anything there
* fabbione wonders wth
<pitti> fabbione: hm, no idea; I assume it is not a translatable string we could grep for
<fabbione> Binary file libfam.so.0 matches
<fabbione> Binary file libfam.so.0.0.0 matches
<fabbione> Binary file libgamin-1.so.0 matches
<fabbione> Binary file libgamin-1.so.0.1.8 matches
<fabbione> well something is still using it
<fabbione> let's figure
<pitti> fabbione: where did you see that, .xsession-errors?
<fabbione> xterm
* pitti greps /usr/bin
<fabbione> pitti: there is tons of stuff that still depends on libgamin0
<fabbione> directly/indirectly
<fabbione> After unpacking 240MB disk space will be freed.
<fabbione> Do you want to continue [Y/n] ? 
<fabbione>  |libgnomevfs2-0
<fabbione>   libgamin-dev
<fabbione>   gamin
<Hobbsee> fabbione: yes, not all of the kde stuff ever got rebuilt
<fabbione> these 2 looks
<fabbione> Hobbsee: rebuilt with what? i didn't follow the transition
<fabbione> if there was any
<Hobbsee> fabbione: rebuilt to lose the dep on libgamin0
<fabbione> ok
<Amaranth> i once rebuilt my desktop to not need libgamin0
<Amaranth> it's like 3 packages
<Amaranth> apparently less now, just gnomevfs
<Amaranth> there is a problem with removing gamin
<Amaranth> right now all the polling happens in the gam_server
<Amaranth> when you use gnomevfs to do it each app does it on their own
<pitti> Mithrandir: uh, do we really use https://wiki.ubuntu.com/Testing/Current/Ubuntu? that looks so empty
<Hobbsee> pitti: i believe we're migrating there/
<Hobbsee> ?
<pitti> I meant, using the pages for herd-2 testing
<Mithrandir> pitti: that's the idea, yes.
* pitti is surprised that there were so few results yesterday
<Mithrandir> but I need to build a new desktop before it's meaningful to test it.
<pitti> Mithrandir: I got network back and stuff is rsyncing; as usual I grab powerpc and some amd64?
<fabbione> Mithrandir: can we get the new partman-base in?
<pitti> oh, good warning; alternates are ok?
<Mithrandir> pitti: I think so, I haven't had the time to test any yet.
<Mithrandir> fabbione: I'm looking at it now.
<fabbione> Mithrandir: ok thanks.
<pitti> Mithrandir: ok, I start with alternate
<fabbione> Mithrandir: if we can't .. ok.. i will just netinstall as soon as you unleash it
<fabbione> but it's not in initrd
<fabbione> so we don't need new d-i
<fabbione> just cd rebuild
<Mithrandir> fabbione: and it seems like sparc is the only one bitten (though I think the code's buggy on all arches)
<Mithrandir> so I'll just rebuild sparc.
<fabbione> Mithrandir: if that's possible it would be wonderful
<Mithrandir> everything's possible.  Impossible stuff just takes a little bit more time.
<fabbione> acutally only Niagara is bitten but the code is randomically buggy
<fabbione> or better
<fabbione> Niagara was the first to show the bug
<Mithrandir> yeah
<fabbione> if you want i also have the kernel patch to debug that stuff :P
<Mithrandir> heh.
<Mithrandir> anyway, publisher running.
<fabbione> danke
<Mithrandir> that should give ogra his ltsp fix too.
<Hobbsee> hey Mithrandir 
<Mithrandir> good morning Hobbsee
<carlos> pitti: hi, I had to run again language pack script
<carlos> pitti: I will ping you once it's finished
<carlos> ok?
<pitti> carlos: ah, thanks
* pitti still gets an autodetected Japanese layout
<pitti> Mithrandir: what's the correct source package for d-i keyboard selection? cdebconf-keystep?
<Mithrandir> probably console-setup
<Mithrandir> depending on what the bug is
<pitti> Mithrandir: the keyboard autodetection in d-i gives me Japanese if I press keys for U.S.
<pitti> Mithrandir: I'm pretty sure I already filed a bug about it last time, but I'd like to check
<dholbach> good morning
<Mithrandir> live ISOs building.
* somerville32 cheers.
<dholbach> Mithrandir: heya Tollef - the alacarte upload is not urgent
<dholbach> Mithrandir: how's it going? how's your dog?
<Amaranth> dholbach: it is if you've got the new gnome-menus
<dholbach> Amaranth: we don't have them yet
<Amaranth> alright, so we still have a settings.menu file
<dholbach> yes
<Amaranth> that was my worst release ever
<Mithrandir> dholbach: he's fun.  He keeps doing minor mischief, but he's absolutely lovely.
<dholbach> come on... we all survived :)
<Mithrandir> dholbach: I'm sure you can see him in Oslo
<dholbach> Mithrandir: sounds like you trained him quite well already - my dog was a pain at that age :)
<Mithrandir> dholbach: Karianne's a good handler.
<Mithrandir> ok, -desktop/-live images up for all arches.
<Mithrandir> and distros
<dholbach> oh... so you're not the dog's handler? :)
<Mithrandir> no, I just play with him and spoil him. :-)
<dholbach> I can imagine that quite well: Tollef's home 4:00 in the morning, dog is scratching on the door and wants to get out, Tollef: "Oh no, it's your dog."
* dholbach knows the feeling well
<dholbach> ;-)
<Mithrandir> dholbach: today he didn't even wake us with scratching on the door.  He's tended to do so before (we just stopped having him in the cage during the night)
<dholbach> woohoo
<Mithrandir> and I've certainly been taking him out in the mornings, but he's still Karianne's dog.
<Mithrandir> publisher running (partman-base and ltsp binaries)
<carlos> pitti: ready
<dholbach> right :)
<heno> sfllaw: around?
<dholbach> hey heno
* dholbach hugs heno
* heno hugs dholbach
<dholbach> how's it going?
<heno> dholbach: dude, we've got 30+ testing volunteers in the forum: http://www.ubuntuforums.org/showthread.php?t=335481&page=4
<heno> how do we organise that? :D
<dholbach> WOAH
<dholbach> good question :-)
<heno> SIMON!
<dholbach> I suppose he's asleep :)
<heno> It would be nice to get help from some experienced testers in here, MOTUs perhaps
<dholbach> we usually use https://wiki.ubuntu.com/Testing/Current - but that might confuse people a bit :)
<heno> I'm sure the testing quality will vary, but it's important to make a start on this IMO
<heno> dholbach: we don't want to flood that at this critical time
<heno> I wrote instructions here http://www.ubuntuforums.org/showthread.php?t=331123
<heno> they will post results in the forum
<dholbach> right
<heno> but someone needs to collate from there
<Hobbsee> heno: good job for the forum ambassadors, but i dont think they'll be decided in time
<heno> Hobbsee: yeah, this will be a bit of a trial run I think (Herd 2)
<Hobbsee> heno: they havent seemed to get their group together at all
<Hobbsee> heno: would be a good trial run though
<heno> yep
<pitti> Mithrandir: do you tell us when new live ISOs are ready?
<Mithrandir> 09:22 < Mithrandir> ok, -desktop/-live images up for all arches.
<Mithrandir> I haven't updated the wiki yet, going to now
<Mithrandir> fabbione: sparc ubuntu-server building
<pitti> Mithrandir: oops, lost that in the dog conversation; thanks
<fabbione> Mithrandir: thanks
<Mithrandir> Riddell: your -desktop images are ready.
<Mithrandir> fabbione: and done.
<somerville32> Are the Xubuntu images ready?
<Mithrandir> xubuntu live images are ready, yes.
<dholbach> Mithrandir: the icon-naming-utils and human-icon-theme uploads are not urgent either
<Mithrandir> I think the alternates are good too, but a test of them would be nice.
<Mithrandir> somerville32: ^^ that was to you
<Mithrandir> dholbach: what about libgnome and evince?
<somerville32> Mithrandir, thanks :] 
<fabbione> Mithrandir: and thanks :)
<dholbach> Mithrandir: libgnome neither - for evince you'd need to ask evince - i didn't read the NEWS file
<dholbach> Mithrandir: ask seb128 of course
<Mithrandir> dholbach: ok.  Since he hasn't prodded me, I blissfully assume they're not needed.  I'd really like to avoid a rebuild now.
<seb128> Mithrandir: nothing is urgent, they are GNOME 2.17.5 late tarball and "nice to have", having them after herd is fine though
<seb128> I assumed that you would prefer do no change at this point
<seb128> that's why I didn't ask :)
<pitti> Mithrandir: btw, http://people.ubuntu.com/~tfheen/unapproved-queue/feisty/ doesn't seem to work
<Mithrandir> seb128: yeah, thanks.
<Mithrandir> pitti: I'll investigate
<seb128> np
<pitti> Mithrandir: not urgent, but thanks
<Mithrandir> pitti: should be fixed in about 30 seconds when my crontab runs.
<Mithrandir> (I shuffled my dotfiles on rookery around, something which meant that ~/dotfiles/ssh got g+w which makes ssh exceedingly unhappy)
<Mithrandir> pitti: there.
<pitti> Mithrandir: rock
<Mithrandir> thanks for noticing.
<somerville32> http://cdimage.ubuntu.com/xubuntu/releases/feisty/ doesn't seem to exist. Where are the Xubuntu herds being placed?
<Mithrandir> somerville32: in that directory.  IIRC, nobody cared to test the xubuntu herd 1 images
<somerville32> There were individuals - I remember them actually doing it in x-devel
<somerville32> They must have have just used a daily build
<somerville32> Mithrandir: Will we be getting it for this herd?
<Mithrandir> somerville32: if somebody tests it and tells me that it works, yes.
<Mithrandir> somerville32: I just don't want to release images I have no idea if works or not. :-)
<somerville32> Of course :] 
<Mithrandir> ogra: fresh images for ya
<ogra> Mithrandir, i fear that wont help me ...
<ogra> cjwatson, ping ...
<Mithrandir> ogra: why not?
<somerville32> Mithrandir: So, just test daily*/current/ and if all is good then you'll release herd 2?
<Mithrandir> somerville32: yes.
<ogra> well, i suddenly have the -generic kernel on my i386 install iso ... that doesnt work
<Mithrandir> ogra: that's a terrible error description.
<ogra> whn i discussed it with colin a while back he told me for i386 alternate that wouldnt change
<Mithrandir> somerville32: and if stuff's broken
<Mithrandir> somerville32: and if stuff's broken, we fix and respin
<somerville32> Awesome.
<ogra> Mithrandir, ltsp needs the i386 kernel ...
<somerville32> Whos is Henrik?
<Mithrandir> somerville32: heno 
<ivoks> a king
<somerville32> heno: Could you please edit your post to include Xubuntu?
<Mithrandir> ogra: well, you have  * Kernel-Version: 2.6.19-7-generic
<Mithrandir> hmm
<Mithrandir> that checkout must be ancient
* Mithrandir updates
<ogra> where are ou looking at ? 
<ogra> *you
<ogra> my i386 iso includes 2.6.20 here
* ogra checks again ...
<Mithrandir> you're using 2.6.20-5-generic in your installer seed.
<Mithrandir> is that what you want?
<Mithrandir> hmm, that's probably just the udebs
<ogra> well, i#d love to but i dont have the space for two kernels 
<ogra> so i fear the server has to run -386 as well ...
<ogra> read: no, thats not what i want under the current circumstances ....
<Mithrandir> that'd require another d-i, I think.
<Mithrandir> or another d-i flavour.
<cjwatson> jdong: ubiquity on existing filesystem> you'd have to hack /usr/lib/ubiquity/ubiquity/validation.py to remove the relevant check
<cjwatson> jdong: actually, not sure if that'd work if it was already mounted; it might still hate you without further hacking
<pitti> ogra: out of curiosity, why are all other kernels named -generic, and the ltsp one i386?
<Mithrandir> pitti: because ltsp needs to run on hardware from the last ice age, so -generic won't work.
<ogra> pitti, the i386 one has 486 compatibility (at least it used to have that)
<pitti> oh, ouch
* somerville32 swears at Freenode for not allowing him to join more then 20 channels at a time.
<ogra> AMD Geode CPUs are *not* from the last iceage ! ;)
<ogra> neither are most of these VIA thingies :)
<cjwatson> pitti: it's on keymapper
* pitti is this --><-- close to finish amd64 alternate testing and got a good deal into ppc/alternate testing -- so do we need new alternates?
<pitti> cjwatson: thanks, will check bug there
<Mithrandir> ogra: well, close enough. :-)
<Mithrandir> pitti: I'd hope not, no.
<ogra> cjwatson, will a seed change suffice or does that need a d-i hack as well ? 
<cjwatson> ogra: I mailed ubuntu-devel announcing the switch to -generic; I suggest you catch up on that
<cjwatson> ogra: are you *sure* the -generic kernel doesn't work on your hardware?
<ogra> cjwatson, we dicussed that after your mail, remember ? 
<ogra> no, i'm not
<cjwatson> why not try?
<ogra> well, i can ... 
<cjwatson> we do have a d-i flavour that does 386, but only for netboot at present
<ogra> BenC, already up ? 
<cjwatson> it seems unlikely at this time
<ogra> cjwatson, i'd ike to hear soething from a kernel guy about that 
<cjwatson> I think it will be considerably quicker for you to try it yourself than to wait for Ben to wake up
<cjwatson> ogra: a seed change will not suffice; it would need extensive changes
<cjwatson> both d-i and debian-cd
<cjwatson> so I'd much prefer that if possible -generic be made to work
<ogra> the 386 kernel sets CONFIG_M486=y
<ogra> the generic one has CONFIG_M586 instead
<Treenaks> ogra: -generic kernels don't work on via cpu's.. -386 kernels do
<cjwatson> ogra: you say you don't have space for the -386 kernel, but your i386 CD is at 682MB
<ogra> yeah, just checking that ...
<ogra> hmm ...
<cjwatson> hmm, but linux-image-2.6.20-5-386 is 22MB
* ogra looks for a big font to drop 
<cjwatson> I assume you haven't tested any of your daily builds for the last month, if you only noticed it now ...
<ogra> i only tested ltsp chroot builds ... 
<ogra> no isos 
<ogra> ... and indeed am bitten by the two only bugs i get with the isos ...
<cjwatson> fabbione: please commit your partman-base changes to bzr
<ogra> cjwatson, you were right with your guess for the debconf setting to be at fault btw ...
<cjwatson> yeah, I saw your comment
<ogra> (indeed)
<ogra> :)
<fabbione> cjwatson: oh.. sure.. what branch is it? 
<cjwatson> fabbione: it's listed on BzrMaintainedPackages
<fabbione> cjwatson: roger
<cjwatson> Mithrandir: I suspect the only way to fix ogra's issue is to switch the Edubuntu install CDs back to the 386 kernel, which requires at least a d-i upload to create a cdrom/386 flavour, debian-cd hacking to use it, and seed changes
<cjwatson> Mithrandir: what's your opinion?
<ogra> cjwatson, well, after the second CD is split out (which i plan to do durng the sprint) i will have space for two kernels ...
<cjwatson> so since it will be solved otherwise for feisty, there's also the option of not releasing the i386 Edubuntu install CD with this milestone
<ogra> there is just not much i can drop at the moment
<Mithrandir> cjwatson: release-note it or drop the alternate edubuntu CD.
<ogra> well, then i wont get much testing, i386 is the most intresting arch ...
<Mithrandir> ogra: ^^ your call?
<ogra> Mithrandir, i'm trying to find something i can drop
<cjwatson> you could release note it as the LTSP server option not working
<ogra> well 
<Mithrandir> cjwatson: yes, that's what I meant.
<ogra> lets just switch ltsp to -generic for now ...
<ogra> and revert that once i have sace for the kernel ... even though that means i might have some installs out there that might not boot
<ogra> s/sace/space/
<Mithrandir> ogra: ok, your choice.  When can you have it uploaded?
<ogra> five minutes ... i need to change a line in ltsp
<cjwatson> needs a release note anyway of course since it's a regression on some hardware
<cjwatson> fabbione: (partman-base change as committed upstream looks fine to me ...)
<fabbione> cjwatson: it's the same commit.. but it was urgent and couldn't really wait a sync
<fabbione> otherwise Niagara is doomed
<gicmo> seb128: hey hey
<fabbione> cjwatson: commited in bzr... Committed revision 35.
<cjwatson> ta
<fabbione> cjwatson: sorry i didn't notice the branch before
* fabbione will pay more attention
<seb128> gicmo: hey!
<seb128> gicmo: Alter! 
<gicmo> ALTER
<seb128> :)
<cjwatson> fabbione: most of the installer's in bzr now, so it's worth checking by default
<cjwatson> (as opposed to some months ago when you probably had a <50% chance)
<dholbach> heno: I'll push ~dholbach/bughelper/bughelper.dev to ~bugsquad/bughelper/bughelper.main - ok?
<pitti> hmm, expert install with LILO doesn't boot
<ogra> Mithrandir, ltsp 0.131 uploaded
<dholbach> heno: (no changes since my last mails)
<fabbione> crap
<fabbione> i forgot a line change in os-prober
<fabbione> oh well
<fabbione> it can wait
<fabbione> screw solaris :)
<fabbione> cjwatson: yeps.. thanks but i hope these to be the last installer hacks i need to do for a while :)
<cjwatson> grr, ubiquity new partitioner is broken as uploaded
<fabbione> cjwatson: are you going to upload a new ubiquity?
<fabbione> if so can i slam an os-prober change too?
<cjwatson> I wasn't planning to, unless Mithrandir wants it
<fabbione> ok
<fabbione> it's not important or urgent for me.. just nice to have
<cjwatson> you can commit the os-prober change to bzr though ;-)
<fabbione> i already did
<Mithrandir> fabbione: we're not at a "nice to have" stage now, so no.
<Mithrandir> cjwatson: uh, how broken?
<Mithrandir> ogra: accepted; publisher running
<ogra> thanks !
<fabbione> Mithrandir: yup.. no problem at all. i would have just abused the same publisher run for ubiquity :)
<cjwatson> Mithrandir: edit dialog breaks. --new-partitioner isn't the default yet though
<Mithrandir> cjwatson: ok, not something we need to have fixed then.
<cjwatson> right
<Mithrandir> ogra: you're testing the -live images, right?
<ogra> just doing that now, yes
<poningru> working on herd2 release notes
<Mithrandir> poningru: yay, great.
<poningru> need some help
<poningru> what was added etc.
<poningru> https://wiki.ubuntu.com/FeistyFawn/Herd2
<Mithrandir> poningru: read the -changes list from herd 1.
<seb128> poningru: GNOME 2.17.5
<poningru> wtf hehe dont know how that became 2.17.4
<seb128> :)
<seb128> poningru: I can have a look and pin-point some of the nice change they made for 2.17.5 if you want
<Mithrandir> cjwatson: i386 is somewhat unhappy in hw-detect since it's trying to modprobe i82365 about five hundred zillion times, but it continues after a little while.
<Mithrandir> cjwatson: do you have a bug about that or do you want it filed?
<poningru> seb128: that would be greatly appreciated :)
<poningru> thank you
<seb128> poningru: np, I'm just rebooting to try something and I'll have a look to that next
<sivang> is there a quick way to know which class an instance is made of in python ? I just want to know the immediate one and not further ancestors
<sivang> anyone idea?
<Mithrandir> >>> f = file("/etc/passwd")
<Mithrandir> >>> type(f)
<Mithrandir> <type 'file'>
<Mithrandir> >>> f.__class__
<Mithrandir> <type 'file'>
<Mithrandir> any of those?
<iwj> __class__ is TRT I think.>>> a.__class__
<iwj> <class __main__.Fred at 0xb7dbfdac>
<iwj> >>> a.__class__ == Fred
<iwj> True
<Mithrandir> iwj: yeah, looks like it.
<sivang> iwj: yep, exactly what I was looking for , thank you!
<sivang> Mithrandir: thanks as well :)
<fabbione> Mithrandir: IF and only IF we need to rebuild alternate/server iso, please allow silo-installer in. Or as soon as you release.. at least netinstall's will not fart on 3rd reboot
<fabbione> Mithrandir: it was wrong parsing of an OBP value (boot-device) and it was set with an insane useless string
<doko> sivang: isinstance(f, file)
<heno> dholbach: ok, please do
<sivang> doko: I wanted actually to have a string of the class name, which class_name = (str(self.__class__)).split(".")[1]  does beautifully :)
<dholbach> heno: done... i'll hopefully start soon on implementing the xml stuff
<pitti> cjwatson: if you have a minute, can you please have a quick look at bug 78777 and tell me whether you might need any more info (before I wipe the install)?
<Ubugtu> Malone bug 78777 in debian-installer "amd64/expert install fails to boot (no root fs)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78777
<fabbione> pitti: did you use LVM or raid?
<pitti> fabbione: no
<sivang> doko: but thanks anyway
<fabbione> pitti: ok
<pitti> argh, ubiquity fails on 'wipe entire disk' on both of my boxes
* pitti files bug
<ogra> pitti: could we hide /target from teh desktop while ubiquity installs ? 
<pitti> ogra: please file a bug against gnome-vfs2 and assign it to me; I'll have a look
<ogra> great ...
<pitti> but it would be an ugly hack
<ogra> hmm
<ogra> i dont think its critical ... but its a bit ugly ...
<Mithrandir> pitti: what's the bug for your wipe disk?
<Mithrandir> pitti: have you had lvm on the disk before?
<pitti> Mithrandir: no lvm, 'assert self.extra_choice is not None
<seb128> poningru: 
<pitti> Mithrandir: on both ppc/real hardware and amd64/vmware
<seb128> - control-center: Make volume up/down keys affect default channel of the applet 
<seb128> - gedit: detect external file modifications
<seb128> - gnome-system-tools: time-admin redesigned GUI
<seb128> - vino: display a notification bubble on connection
<seb128> - epiphany-browser: adblock manager UI
<seb128> - gnome-media: add mp3 profile and make profiles being listed only if the elements for them are available
<seb128> - gnome-utils: Add an "interactive mode" to gnome-screenshot
<Mithrandir> pitti: :-(
<poningru> ooh grazi
<seb128> sorry for the flood
<seb128> poningru: some of changes from GNOME 2.17.5
<pitti> Mithrandir: ok, I'm through with amd64 desktop+alternate, although resizing was never offered to me
<lifeless> gnight
<somerville32> Would it be right to say that if a package is in Main, then it supported officially by Canonical?
<somerville32> *it is
<fabbione> somerville32: s/by Canonical//
<fabbione> it's supported by Ubuntu
<somerville32> Right
<fabbione> some developers for main are not employed by Canonical
<fabbione> and still provide support for their pkgs
<somerville32> So it would be ludicrous to suggest that Xubuntu isn't supported by the core-dev team since all of Xubuntu's packages are in main?
<fabbione> what's the context?
<somerville32> "Yes, of course feel free to test Xubuntu as well (or any other derivative). The core dev team has traditionally not focused on testing it because we don't officially support it."
<fabbione> well the xubuntu main developer is a core-dev last time i checked...
<somerville32> Right
<somerville32> There are 2-3 core-devs who actively contribute to Xubuntu
<fabbione> and Canonical doesn't support xubuntu is slightly different
<fabbione> clearly if i get a bug for the kernel or glibc from xubuntu, it's still a bug
<fabbione> but if i get assigned a bug for xfce.. well that's Xubuntu devel business
<fabbione> me as fabbione as part of core-dev
<fabbione> if you get the point
<somerville32> So, Canonical doesn't "support" Xubuntu?
<somerville32> Not referring to the fact that they build our ISOs, host our website, etc.
<fabbione> somerville32: no Canonical doesn't support Xubuntu directly last time i checked.
<fabbione> tho if things did change while i was in vac.. well
<somerville32> They do support us directly though
<somerville32> They build our ISOs, they host our website, etc.
<fabbione> it's 2 different kind of support we are talking about
<somerville32> Right
<somerville32> They don't "sell" support
<somerville32> Or not yet atleast?
<fabbione> C. doesn't.
<mvo> is there something like sh -x for perl? 
<fabbione> mvo: you wish :P
<pitti> mvo: perl gets compiled, would be hard to do
<ogra> Mithrandir, edubuntu live is fine on all arches
<fabbione> mvo: printf is your best friend
<heno> somerville32: see my answer here: http://www.ubuntuforums.org/showthread.php?p=1997725
* mvo sighs
<Mithrandir> mvo: PERLDB_OPTS="AutoTrace NonStop" and perl -d
<pitti> oh, neat
<mvo> Mithrandir: thanks!
<carlos> pitti: did you check whether latest langpack export is correct?
<pitti> carlos: has it finished?
<carlos> pitti: yeah, I told you it around 3 hours ago...
<pitti> carlos: oh, sorry
* pitti is a bit busy handling three parallel test installs
<carlos> pitti: don't worry
<pitti> carlos: yup, looks good
<carlos> pitti: we got around 100 new files
<somerville32> heno, I am reading the thread you linked to. It appears several people out of the handful of people who replied have volunteered already to test Xubuntu.
<heno> somerville32: yep, thanks for the heads up. It's a community-based testing project and so I will adjust it accordingly
<heno> happy testing! :)
<somerville32> Thanks ;] 
<somerville32> heno: oh wow!
<somerville32> heno: You got quite the response for not including Xubuntu, lol
<heno> yep, more Xubuntu testing seems to be the first measurable success of the forum-based testing setup ;)
<cjwatson> Mithrandir: feel free to file; I suspect it's somewhere between hw-detect and pcmciautils. Was this a machine with PCMCIA hardware?
<Mithrandir> cjwatson: no, it's an amd64 desktop machine.
<Mithrandir> (but i386 alternate installer)
<Mithrandir> file against hw-detect?
<cjwatson> sivang: self.__class__.__name__ woould be better I'd think
<cjwatson> Mithrandir: yeah
<cjwatson> pitti: is there a bug about the broken ubiquity erase-disk bit?
<cjwatson> that seems like potential respin fodder
<cjwatson> pitti: 78777 sounds like the initrd wasn't set properly?
<cjwatson> pitti: fishing out /etc/lilo.conf might be useful
<sivang> cjwatson: hmm, right, will probably be less error prone althought them both achive the same
<Mithrandir> ogra: have you respun your alternate CDs or should I?
<ogra> Mithrandir, i dont see 0.131 in the archive yet
<ogra> but feel free once its there
<Mithrandir> ogra: oh, point, I ran the buildd sequencer, not the publisher.  Running now, I'll spin i386 CDs for you when it's there
<ogra> oki
<pitti> cjwatson: yes, I filed a bug and linked it from Testing/Current/Ubuntu
<pitti> cjwatson: bug 78778
<Ubugtu> Malone bug 78778 in ubiquity "ubiquity crash on 'use entire disk'" [High,Unconfirmed]  https://launchpad.net/bugs/78778
<cjwatson> just found it, thanks
<pitti> cjwatson: for 78777, lilo.conf looked okay; re-running update-initramfs and lilo didn't help
<pitti> cjwatson: I'll attach the lilo.conf
<cjwatson> pitti: 78778> do you recall what the autopartitioning page looked like? were there any choices labelled with disk names?
<pitti> cjwatson: I *think* not
<pitti> cjwatson: if you want I reattempt the whole install again and do a screenshot
<pitti> cjwatson: I can also try installing grub in d-i (install-grub errored out in rescue system since it didn't find the hd)
<cjwatson> pitti: if you wouldn't mind (screenshot) - I can't reproduce it here
<cjwatson> your partman log indicates finding disks
* cjwatson has a horrible thought
<cjwatson> my vmware instance is currently set up with two disks to stress the partitioner a bit more. I wonder if it breaks with one disk ...
<pitti> cjwatson: lilo.conf attached
<Mithrandir> i386 ubiquity seems to work so far for me at least, it's at copying files.
<Mithrandir> (single disk)
<cjwatson> pitti: for your ubiquity crash, could you start it using 'ubiquity --debug' from a terminal and get me /var/log/syslog and /var/log/installer/debug?
<cjwatson> pitti: usual caveat: don't use a valuable password
<pitti> yes, of course
<cjwatson> like Mithrandir, I can't reproduce it here
<cjwatson> pitti: lilo> does an /initrd.img exist?
<cjwatson> pitti: or is it /boot/initrd.img?
<pitti> cjwatson: it was correct IIRC, can check in a few seconds
<pitti> cjwatson: confirmed, correct symlink existed
<pitti> cjwatson: I attached the screenshot of the current partitioner (new installation attempt); that's the shot you want?
<cjwatson> pitti: to which bug?
<pitti> cjwatson: 78777 (expert install boot failure)
<pitti> oh, erm, sorry
<pitti> you wanted the screenshot for 78777
<pitti> nevermind then
<cjwatson> pitti: oh, I'm sorry, I meant for 78778
<cjwatson> although the debug files should be sufficient there anyway
<pitti> ok, so I did the screenshot for the expert install boot failure
<pitti> ok, will do a shot from that
<cjwatson> the screenshot there is primarily for interest's sake, but it might be useful
<cjwatson> if you ever see "Guided - use entire disk" without disk choices below it, that's a bug
<Mithrandir> cjwatson: ubiquity blows up when trying to install the langpacks though.
<Mithrandir> cjwatson: assert cache._depcache.BrokenCount == 0
<Mithrandir> (Norwegian locale)
<Mithrandir> (nb_NO.UTF-8)
<ogra> Mithrandir, hmm, worked for me (german)
<ogra> hmm, but why do i get a fsck on a freshly installed partition ? 
<pitti> cjwatson: ah, you mean that screen; it had exactly one subitem with my primary HD
<pitti> cjwatson: and both 'guided, entire' and that disk was selected (the radio buttons)
<ogra> oh, great and it even failed ...
<cjwatson> Mithrandir: I'd love to know why that is. I have a zillion reports about it and have never seen it.
<cjwatson> I'll see if I can reproduce
<Mithrandir> cjwatson: what can I give you to help you debug it?  ubiquity --debug and the log?
<cjwatson> pitti: ok, in that case I just need the debug files
<cjwatson> Mithrandir: I have lots of logs for it, and --debug probably won't help much - I'll see if nb_NO.UTF-8 is enough to reproduce it
<ogra> Mithrandir, edubuntu ppc install is fine (apart from the fsck on first boot)
<cjwatson> whoa, what the hell, weird erase-disk failure
<incon> cairo on feisty is not built with glitz support? will this happen in this release
<cjwatson> hald: mounted /dev/hda1 on behalf of uid 0
<Riddell> Mithrandir: all three desktop kubuntu CDs are good to go
<Mithrandir> cjwatson: mount-all-partitions race bug?
<Mithrandir> Riddell: yay!
<cjwatson> Mithrandir: I think it must be. What's the spec name?
<cjwatson> mount-all-local-filesystems
<cjwatson> pitti: how do I suppress that?
<pitti> oh, argh
<pitti> cjwatson: quick&dirty way is to kill gnome-volume-manager
<cjwatson> pitti: is there a gconf key? I'm already setting several
<cjwatson> /desktop/gnome/volume_manager/automount_drives and /desktop/gnome/volume_manager/automount_media
<pitti> cjwatson: hm, if g-v-m doesn't respect that, that looks like a feisty regression
<pitti> cjwatson: (mount-all-local-filesystems didn't change anything in g-v-m)
<cjwatson> unless I'm setting them wrongly
<Mithrandir> cjwatson: automount_drives and automount_media are both set here, do you unset and then reset them?
<sivang> I don't suppose anybody knows a ready made auto completion implemetation that can be used in a python program?
<ogra> Mithrandir, 0.131 is done ...
<Mithrandir> ogra: so is your install iso.
<ogra> oh, wow, thanks
<pitti> cjwatson: I attached syslog, debug, and screenshot to bug 78778
<Ubugtu> Malone bug 78778 in ubiquity "ubiquity crash on 'use entire disk'" [High,Unconfirmed]  https://launchpad.net/bugs/78778
* pitti grabs some food before disappearing completely
<heno> cjwatson: can you confirm bug 78722 ? Would that be considered a blocker? It's confirmed by a forum tester as well now
<Ubugtu> Malone bug 78722 in ubiquity "Feisty 20070110 -- Grub fails to list old kernel" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78722
<Riddell> pitti: should ssh advertise itself as an avahi service by default?
<siretart> Riddell: no. you'll have to install a .service file by hand
<Riddell> siretart: what do I need to do besides `sudo cp /usr/share/doc/avahi-daemon/examples/ssh.service /etc/avahi/services/`?
<cjwatson> heno: it's not a blocker, but should be investigated
<heno> cjwatson: ok, so should the test be marked as PASS?
<cjwatson> heno: pass with note, yes
<Riddell> siretart: ooh, that works
<cjwatson> I think, anyway
<Riddell> siretart: but my question is if we should be doing that by default
<cjwatson> sorry, all sorts of shit is exploding in my face and I'm not entirely on top of everything
<francalier> any news on packaging microsoft bob for feisty??
<somerville32> francalier, For sure. We've already got it packaged, approved, uploaded, added to the seeds, and ready to roll by default.
<francalier> will there be a non-free info popup?
<poningru> ...
<siretart> Riddell: you'll have to convince cjwatson of that, because he maintains ssh ;)
<somerville32> francalier, No. Microsoft gave us a big payoff to keep the fact that bob is proprietary a big secret.
<thom> i really, really hope that we don't do ssh mdns advertising by default
<Mithrandir> thom: it'd be against the network policy.  What we allow is listening and using those services by default.
<cjwatson> 'Resolved address "xml:readwrite:/root/.gconf" to a writable configuration source at position 0'
<cjwatson> I think that's the problem - should be /home/ubuntu/.gconf
<Mithrandir> ah, probably.
<cjwatson> investigating a fix now
<cjwatson> Mithrandir: r1800 in ubiquity trunk
<cjwatson> I'll see if the BrokenPackages thing shows up here
<pitti> re
<pitti> Riddell: TBH I'd rather not do that
<Riddell> pitti: why not?  it's useful to know if I can sftp into a machine
<cjwatson> Mithrandir: reproduced your problem
<pitti> Riddell: well, yeah, it's only for the local network, so it's not a general invitation to 'DoS me' (happened on my colo server several times)
<Riddell> pitti: my thinking is that avahi is to make it easy to find things, but if they're not advertised by default there's not much point
<pitti> true
<pitti> Riddell: what's necessary to enable that?
<Riddell> pitti: sudo cp /usr/share/doc/avahi-daemon/examples/ssh.service /etc/avahi/services/
<Riddell> pitti: but that's ssh, it's sftp that's important to advertise for the GUI apps
<pitti> Riddell: ah, I thought sshd could advertise itself or so
<Mithrandir> it could be taught to, I guess.
<Riddell> pitti: doesn't do on my candidate herd 2 installs
<pitti> + eth0 IPv4 Remote Terminal on donald                     SSH Fernzugriff      local
<pitti> woo :)
<pitti> Riddell: ok, if cjwatson is fine with it, we should just ship that file in openssh-server, AFAICS
<\sh> I don't think that is wise to enable ssh for avahi...
<cjwatson> pitti: I'm not overly keen simply because so many of my users are going to throw a massive wobbly about it
<pitti> my main concern is DoS invitation as well, but then again, in the .local range it's easy enough to do a portscan
<cjwatson> and sftp is not useful to advertise in quite the same way as, say, a printer, simply because you generally cannot use sftp without authentication
<cjwatson> avahi seems massively more useful for unauthenticated services than authenticated ones
* pitti nods
<cjwatson> if somebody's creating an account for you, telling you what host they are is the least of their problems ...
<Riddell> I use it all the time for authenticated ones, you still want to connect to local authenticated services
<cjwatson> you can use a hostname for that
<cjwatson> I just see it as a massively niche case, I'm afraid
<cjwatson> also sshing to something whose hostname repeatedly changes means lots and lots of host key confirmation prompts, so I'm not keen on encouraging that configuration
<cjwatson> hostname> or IP address
<cjwatson> simply because people treat the host key prompt too lightly as it is
<Mithrandir> cjwatson: your patch seems to have fixed the mounting problem for me.
<Riddell> all seems like quite a geeky point of view, "how do I get that file off your computer", "type sftp://foo.local/home/me into the file browser" compared to "go to network and browse for foo"
<Riddell> \sh, thom: what's your rationales against it?
<cjwatson> Riddell: the host key prompt is the only defence against certain security problems
<cjwatson> I don't care whether it appears geeky or not; it's important
<cjwatson> Riddell: if people aren't willing to deal with a hostname or an IP address, it seems unlikely that they will be willing to deal with the host key prompt ...
<cjwatson> I'd rather encourage people to share files without authentication than encourage them to share files with broken authentication
<pitti> (yay gnome-user-share)
<cjwatson> Mithrandir: ok, the translation of the BrokenPackages error is:
<cjwatson> The following packages have unmet dependencies:
<cjwatson>   language-support-nb: Depends: mozilla-firefox-locale-nb-no but it is not installable
<cjwatson> now the question is why ubiquity couldn't deal with that
<siretart> seb128: I've noticed that in the past time, you've reassigned many bugs filed against totem to xine-lib, which is great. When reassinging, could you please ask the submitter to include a reference to a file causing this bug?
<siretart> in future, that is
<seb128> siretart: ok, will do
<Riddell> cjwatson: I'm pretty sure in KDE if the fingerprint fails then you can't connect, if it still allows it in gnome I'm sure seb128 would be happy to fix it :)
<cjwatson> Riddell: how were you planning to get people to check the fingerprint?
<cjwatson> Riddell: you know it has to be checked manually for strong security, right?
<Riddell> cjwatson: it pops up with a message when it connects to a computer for the first time, just like on the command line
<dholbach> Mithrandir: deskbar-applet also not urgent
<cjwatson> Riddell: sure, and then you have to check that with the owner of the computer
<cjwatson> Riddell: so given that the owner has to read out the host key fingerprint anyway, reading out the hostname/IP-address (which is considerably shorter) or a URL is not a problem, IMO
<Mithrandir> cjwatson: I'm tempted to release-note it and just get the automount problem in.
<Riddell> cjwatson: right, I see your issue then, thanks
<cjwatson> Riddell: it's not that I'm intrinsically against advertising ssh via avahi - I don't think it causes a problem per se - but I do think that managing the perception of things in such a way as not to weaken ssh's security in practice by (effectively) social engineering of our users is a more difficult problem that it appears at first
<cjwatson> Mithrandir: can I have ten minutes? I feel I'm quite close
<cjwatson> Mithrandir: also pitti's problem is still outstanding and I suspect affects only certain languages; try reproducing it by installing in German?
<cjwatson> I'm guessing it's a str vs. unicode issue
<pitti> cjwatson: I try with English
<Mithrandir> cjwatson: ok, I want to go home now anyway, so you have about half an hour. I'll continue testing when I get home.
<pitti> cjwatson: right, with English it doesn't crash; noted so in the bug
<cjwatson> Mithrandir: fixed, I think - just need to test
<cjwatson> pitti: reproduced
<cjwatson> pitti: fixed
<Mithrandir> cjwatson: tell me when it's the queue?
<pitti> cjwatson: \o/
<cjwatson> Mithrandir: will do - testing the Norwegian fix now
<Mithrandir> yay
<jdong> when would be the next time the archive deities decide to process backports?
<ogra> Mithrandir, edubuntu all arches, all flavors are fine 
<Mithrandir> jdong: whenever a crate of free time comes flying down from the heavens.
<Mithrandir> jdong: sorry, it hasn't been a priority lately, I've concentrated on cleaning out NEW, and that's just about done, once that's cleared again, I'll do syncs and backports.
<jdong> ok, that's not a problem, we all have priorities :)
<Lathiat> cjwatson, \sh, Riddell: i probably wouldnt advertise ssh by default
<Lathiat> cjwatson, \sh, Riddell: i think advertisements should be something that is user confirmed, e.g. "Share my music"
<jdong> "secure file sharing" :)
<cjwatson> cute, that fix has the useful effect that it will install as much of language-support-$LL as it can even if some of it is broken
<\sh> Lathiat: that's what I said...I don't think advertising ssh is a good thing...I mean, normally I don't have openssh-server installed on my desktop box
<Lathiat> \sh: certainly if you *did* advertise it, you would do it when ssh is installed and nto avahi
<poningru> please excuse the intrusion but quick question I dont understand whats the big deal about about advertizing ssh, someone can just nmap on the lan and picks it up so...
<jdong> poningru: I think it's more of a "why does Joe need to know this?" kind of thing
<jdong> same reason why DT_GNU_HASH hasn't been advertised in Kubuntu Feisty yet
<jdong> though it offers a very noticeable performance boost
<\sh> poningru: plain desktop users don't know what nmap is
<Lathiat> plain desktop users arent hackers
<poningru> oh so this discussion wasnt from a security standpoint but UE?
<cjwatson> poningru: at the intersection of the two
<Lathiat> i mean it doesnt really expose alot of info
<Lathiat> that isnt otherwise relatively easily findable
<Lathiat> but there is a certain security point to avahi
<Lathiat> its unsecurity through unobscurity
<cjwatson> poningru: like I say, advertising ssh over avahi is not by itself a security problem IMO, but it does not help the user experience if you are actually trying to maintain security
<poningru> hmm ic
<Lathiat> i also think things shouldnt be advertised because you just installed a package
<Lathiat> i think it should be a case of "click share my music", etc
<Lathiat> *click* i want to host a game
<Mithrandir> Lathiat: while you're certainly allowed that opinion, publishing by default for packages which aren't installed by default is ok wrt our network policy.
<jdong> *click* hey look, free music! oh wait nvm
<Lathiat> Mithrandir: right, true
<Lathiat> i said that was an opinion :)
<Mithrandir> yeah
<bddebian> Heya
<cjwatson> Mithrandir: in the queue now
<ogra_> heno, where are all my edubuntu testing procedures from the links section on Testing/Current gone ?
<dholbach> """
<dholbach> Edubuntu
<dholbach>     *
<dholbach>       See Testing/Current/Edubuntu for the latest test candidates and test results.
<dholbach> """
<dholbach> ogra_: ^
<dholbach> at the top, bold letters :-)
<ogra_> dholbach, yes and that page doent have any of the ltsp testing advises anymore
<gpocentek> Mithrandir: Xubuntu desktop amd64 & i386 are OK (I can't test the ppc isos)
<gpocentek> Mithrandir: amd64 alternate is ok too, testing i386 now
<ogra_> th eold page had a bunch of steps you have to test on edubuntu (actually the only stuff i'm intrested in after testers know they can boot and the installer runs generally)
<ogra_> ahh, found it ... heno nvm ... found that you moved it to Testing/Short
<Mithrandir> gpocentek: yay.
<Mithrandir> gpocentek: are anybody else testing the ppc ones?
<gpocentek> Mithrandir: I don't think so
<fabbione> Mithrandir: did you roll out any new server images since 2007011 ?
<Mithrandir> fabbione: no
<fabbione> ok thanks
<fabbione> are we going to roll out more images today?
<fabbione> i need to coordinate with -certification
<Mithrandir> yes, we are.
<Mithrandir> we need new ubuntu -desktop images
<fabbione> Mithrandir: ok thanks
<pitti> Mithrandir: at least we can be glad that alternates are ok; they are such a pain to test...
<heno> ogra_: sorry did I loose something in the transition? There was a lot of duplicate stuff floating around
<ogra_> heno, no, it just took me a bit to find it, its all fine, thanks for the work
<kevin> Greetings, I am trying to upgrade edubuntu 6.06 to 6.10. When I run gksu "update-manager -c" it says "your system is up to date" with no upgrade message available. I have the latest version of Update Manager and have dapper-updates repositories in my sources.list. I asked about this on #ubuntu and #edubuntu. No one seems to know. Someone then directed me to this channel. Is it a bug?
<ogra_> mvo_, ^^^ any idea ? 
<mvo_> kevin: lets talk about it in #ubuntu 
<azeem> elmo: James, I hope you're not involved in this: http://www.boingboing.net/2007/01/10/meth_smuggled_in_elm.html
<kevin> mov_, going there now, had to step out for a couple minutes
<gpocentek> grr, xubuntu alternate can't detect network harware (on i386)
<gpocentek> hardware*
<gpocentek> but it work just fine with the amd iso
<Mithrandir> gpocentek: sure it's not just very, very slow?
<gpocentek> Mithrandir: after a while, it just turns to a blue screen and does nothing
<gpocentek> I've waited several minutes
<brentcool> wow you got a bsod
<Mithrandir> gpocentek: Alt-F2 enter ps ax ; does it seem to be modprobing?
<gpocentek> Mithrandir: let me restart the whole thing to see this
<gpocentek> Mithrandir: it's modprobing during the hardware detection, I'm waiting the blue screen now
<Mithrandir> gpocentek: please wait, it'll probably take a couple of minutes (at least it did for me)
<gpocentek> ok
<ogra> hmm, thats weird, why didnt i see anything similar in edubuntu ... Riddell did you ? ^^^
<Mithrandir> ogra: seems to be hardware related.
<Riddell> ogra: network is working fine on all three architectures
<gpocentek> ah, blue screen, it's still modprobing and ethdetecting
<ogra> Mithrandir, ah ... right
<Mithrandir> gpocentek: ok, so you're seeing the same as me.  Go and drink a cup of coffee or tea or something and tell me if it's not done when you're done with the beverage. :-)
<ogra> else get a piece of cake as well ;)
<gpocentek> :)
<gpocentek> yay, it works :)
<brentcool> is herd 2 being released today?
<Mithrandir> brentcool: that's the plan, yes.
<cjwatson> brentcool: we ran into a few showstoppers, so it's a little later than hoped, but if Mithrandir thinks he can still do it ... :-)
<brentcool> that's great
<brentcool> i ask because the CD/DVD testing forum appears to be nonexistent all of sudden
<pitti> Mithrandir: do you have an ETA for the new images? I need to leave in 1.5 hours, but would like to do some ppc/amd64 tests
<Mithrandir> pitti: publishing binaries now; just upgrade your live cd and run the tests (once it finishes, about 20 minutes)
<pitti> Mithrandir: 'upgrade your live CD == apt-get dist-upgrade in live system? i. e. it's only new ubiquity?
<brentcool> http://www.ubuntuforums.org/forumdisplay.php?f=201 doesn't appear to go anywhere, just giving you guys a heads up if it was important
<Mithrandir> pitti: yes, do you have other stuff which is broken?
<pitti> Mithrandir: no blockers
<pitti> just the usual small bugs we have since edgy or longer
<pitti> hi mneptok! *hug*
<Mithrandir> pitti: it'd be nice if we could have a "quiet week" at some point where we stamp out flaming ducks^W^Wannoying bugs.
<cjwatson> brentcool: worked for me
<cjwatson> brentcool: and still works
<pitti> Mithrandir++
<brentcool> cjwatson, it takes me to just a blank template, no links to download ISO images
<cjwatson> brentcool: -> heno, or the forums admins, maybe
<keescook> mornin'
<cjwatson> brentcool: but for downloading images, http://cdimage.ubuntu.com/daily-live/current/ (desktop) http://cdimage.ubuntu.com/daily/current/ (alternate) and insert /kubuntu /edubuntu /xubuntu as appropriate after cdimage.ubuntu.com for flavours other than Ubuntu
<heno> brentcool: there seems to have been some technical change in the forum today. http://ubuntuforums.org/forumdisplay.php?f=201 works
<brentcool> thanks cjwatson , I just wanted to make sure that other people wouldn't hit a brick wall with the semi-broken link :)  I've got feisty in vmware with the newest updates, and I'm loving it so far
<brentcool> ahh that's what it is
<brentcool> ok problem solved, thanks heno
<cjwatson> brentcool: ah, sorry, didn't notice the www.
<doko> hmm, power management isn't working out of the box on a new i386 install
<ogra> doko, elaborate ? 
<doko> ogra: cpu stays at fill speed
<ogra> doesnt go to sleep ? doesnt wake up ? 
<ogra> yeah thats a known upstream bug ... already fixed in cvs and reported several times
<ogra> the ondemad governor is missing
<ogra> will be fixed in the next g-p-m release
<ogra> doko, 2.17.5 should fix it
<megatill> deutscher channel?
<pitti> megatill: nein, bitte hier Englisch sprechen
<megatill> pitti: okay where is the german channel of ubuntu?
<silwol> megatill: #ubuntu-de
<megatill> txh
<megatill> good bye
<kevin> Hi mvo, I figured out that the upgrade to 6.10 in Update Manager will only be detected if I exported the http_proxy. Even though I had the proxy set in Preferences->Network Proxy it didn't work there. Just thought I'd let you know. 
<mvo> thanks kevin
<mvo> too late
<pitti> Mithrandir: yay, ubiquity 1.3.11 made it to the archive
<Mithrandir> pitti: indeed.  Rolling livefs-es now
* pitti gets about 3 bytes per second from archive.u.c -- darn
<elmo> pitti: ... file something in RT
<pitti> oh, that's not a problem on my end?
<ogra> pitti, use a hub server thats not in the telecom network to download 
<elmo> pitti: it could be, or it could be your ISP vs Cogent
<ogra> their routing is fucked
<elmo> pitti: try downloading something from durville.c.c - if that's fast, it's your ISP vs. Cogent and we can work around it
<elmo> but generally speaking, the point is please report problems if their reproducable, and I'm pretty sure this isn't the first time I've seen you complain about speed problems to u.c
<elmo> they're too
<pitti> elmo: indeed, I get 400 kB/s from durville
<pitti> elmo: sorry, it's pretty much the first time I notice that; I usually use de.archive.u.c
<pitti> I just noticed because I wanted to test the new ubiquity quickly
<elmo> pitti: ok, maybe I'm misremebering who had sped problems
<pitti> yay, ubiquity doesn't crash for me any more
<cjwatson> hooray
<mjg59> iwj: Most Winmodems nowadays are on a modified ac97 bus called mc97
<iwj> So I don't think it's sensible to spend a lot of effort researching nonfree drivers unless there's a compelling reason to include them, so I think a decision in principle to include nonfree drivers (which I wouldn't support) would need to be taken first.
<Keybuk> iwj: basically, where a modem needs a binary-only driver, firmware blob or binary-only daemon; that's not a blocker for investigation -- find out what hardware we need to obtain, or whether someone in the team already has that modem, and find out what they need to install, etc.
<Keybuk> iwj: the TB will make a decision about the driver once it's packaged and ready to go
<Keybuk> iwj: the compelling reason to include them is to be able to support modems
<Keybuk> this has been identified as a high priority
<mjg59> iwj: slmodem-daemon is the userspace portion
<mjg59> iwj: Note that this /doesn't/ apply to Conexant chipsets, such as the ones found on Thinkpads.
<mjg59> They need a payware driver. 
<iwj> mjg59: Aha.
<iwj> mjg59: I must have been looking at the wrong websites.
<mjg59> Ignore linmodems.
<iwj> mjg59: Ah.
<mjg59> It's full of insanity.
<iwj> Right.
<mjg59> The situation is less good with respect to older chipsets
<mjg59> Especially since most of those drivers don't build on anything even vaguely recent
<mjg59> Almost all of the drivers for them were never officially released
<iwj> Is the LDP modem howto any better ?
<mjg59> Might be a little
<iwj> Where should I be looking ?
<mjg59> That depends on what you're looking for
<mjg59> The hwdb is probably a good plan
<iwj> mjg59: It was clear that linmodems.org didn't have any significant number of useful drivers.
<mjg59> See which PCI chipsets actually pop up
<mjg59> I'd be willing to bet that the number of users with PCI winmodems (other than Conexants) is pretty slim
<mjg59> The only other common one is likely to be Lucent
<mjg59> Which we already ship a driver for
<mjg59> Except it's not SMP-safe. Win.
<iwj> And the Conexant users are out of luck because it's payware, which leaves us supporting only these ac97-like ones.  (AMR?)
<mjg59> Yeah
<kylem> mjg59, groan.
<mjg59> There's a "free" 14.4kb version of the Conexant drivers
<mjg59> When I mailed them ~18 months ago to ask if we could ship them, they never replied
<mjg59> But then, this is the company whose MODULE_LICENSE field reads:
<mjg59> "GPL\0With additional restrictions"
<_ion> Heh.
<mjg59> The kernel does strcmp, hits the null and doesn't taint
<mjg59> I think shipping them would result in hatred
<kylem> i think that was fixed to check the entire length of the string.
<mjg59> iwj: What I'd suggest would be just to bump slmodem-daemon to restricted, and have it check whether there's a Connexant codec
<elmo> kylem: the right fix would have been to oops
<mjg59> iwj: You can do that by looking at some of the registers under /proc/alsa
<kylem> elmo, the right fix would be to sue the company.
<kylem> for being utter cunts.
<_ion> One could claim they're saying it's GPL, because it is supposed to be read until the \0, and the rest is just some meaningless list of bytes. ;-)
<mjg59> _ion: Eh. The driver's a thin shim around a large blob of compiled C++
<mjg59> It's very, very hateful
<_ion> ...and because they've published it until GPL (that's the impression they want the kernel to have  let's play along), sue them for the source. ;-)
<mjg59> Uh. They're the copyright holders.
<kylem> iirc it contains a copy of serial_core.c too.
<_ion> I'm just kidding, don't take the previous lines seriously.
<gpocentek> Mithrandir: installation finished, the i386 alternate is "good" I guess
<gpocentek> just a little slow
<pitti> Mithrandir: for the record, apt-get dist-upgraded ppc/amd64 live systems do not crash ubiquity any more
<pitti> Mithrandir: I'll do full tests of the new ISOs tonight or tomorrow early morning, but it should be well (modulo squashfs bugs and the like :) )
<iwj> download/sl-modem_2.9.10+2.9.9d+e-pre2.orig.tar.gz: POSIX tar archive
<iwj> w3m--
<iwj> Or maybe archive.ubuntu.com--
<iwj> mjg59: Do you know why sl-modem is in multiverse rather than universe ?
<mjg59> iwj: Non-free
<mjg59> The actual modem bit is only shipped as binary
<iwj> ./drivers/amrlibs.o  Aha, I see.
<iwj> Still, much less annoying than a binary kernel driver.
<Lathiat> keescook: are you coming to LCA?
<keescook> Lathiat: I am!  :)
<Lathiat> keescook: awesome, i'll be sure to say hi :)
<Lathiat> (i figured from your mail to attendees)
<keescook> you bet.  are you coming to the keysigning?
<Lathiat> yep
<keescook> perfect.  :)
<cjwatson> pitti: still around?
<cjwatson> pitti: your g-s-t patch as uploaded isn't quite the same as the one in the bug
<pitti> cjwatson: yes, I am. Leaving in 11 minutes
<cjwatson> pitti: in particular the addition of X-KDE-SubstituteUID=true is missing from the upload
<cjwatson> pitti: er
<cjwatson> pitti: never mind me, I'm insane and can't read two-level diffs
<pitti> *phew*
<iwj> insane> That's because you've been reading too many two-level diffs.
<cjwatson> that would do it
<cjwatson> pitti: both your SRU nags from the meeting accepted now
<pitti> \o/
<pitti> thanks
<nags> cjwatson, ?
<cjwatson> nags: not you :-)
<pitti> oh dear...
<nags> cjwatson, ah ! okay :)
<pitti> people should avoid using nicks that are actual language words...
<pitti> :)
<cjwatson> I pitti you if you think that
<pitti> heh
<pitti> cjwatson: Kame on!
* pitti -> off, cu tonight or tomorrow
<ernstp> Iv'e got a 623 Mb (res) beagled running
<ernstp> can I do some usefull debugging before I kill it?
<ernstp> in Feisty
<Riddell> Mithrandir: how are those ubuntu CDs doing?
<Mithrandir> Riddell: they're built, I'm rsyncing now.  Test away.
<doko> Mithrandir: ok to upload packages for main again, so that they get queued?
<gnomefreak> iwj: if your around. would it be ok to change the package of https://launchpad.net/ubuntu/+source/firefox/+bug/14911. it seems to be a flashplugin-nonfree issue not firefox
<Ubugtu> Malone bug 14911 in firefox "Flash plugin problem with ARGB visuals causes crash" [Unknown,Confirmed]  
<iwj> I think it's definitely OK to add a task against flashplugin-nonfree.  But the task against firefox is to have a workaround.
<mdke> is anyone available for some archive administration action? I'd be grateful for ubuntu-docs getting poked through into edgy-proposed as per bug 74555
<Ubugtu> Malone bug 74555 in ubuntu-docs "Stable release update" [Medium,Confirmed]  https://launchpad.net/bugs/74555
<gnomefreak> ok so ill add flash to it
<iwj> gnomefreak: Right.
<gnomefreak> ok cool ty
<Mithrandir> mdke: can it wait until tomorrow?  I'm planning on spending most of tomorrow on archive administration stuff.
<mdke> Mithrandir: that would be great, thanks
<Riddell> Mithrandir: can you look at https://launchpad.net/bugs/77711 tomorrow too?
<Ubugtu> Malone bug 77711 in mailody "Please sync 0.3.0-1 with Debian experimental" [Undecided,Confirmed]  
<Mithrandir> Riddell: tomorrow? :-)  I'll get herd 2 out and then end my day.
<Riddell> I did say tomorrow :)
<Mithrandir> oh, ok.
<Mithrandir> yes, it's has ubuntu-archive subscribed to it, so I'll look at it.
<||cw> not sure where to go with this... but where do I find the "setting preliminary keymap" that happens right after the initramfs scripts.  I want to try and make it faster
<mynameisdeleted> how much bandwidht would it take to run an official ubuntu mirror?
<mynameisdeleted> I have 1gbps internet with dual cpu 2.8ghz
<mynameisdeleted> and 1gb+ ram and sata 
<mynameisdeleted> I'm guessing I'd prob want 2GB+ ram and raid
<mdke> Znarl: question for you ^^
<Znarl> Hello mynameisdeleted. 
<mynameisdeleted> hi
<Znarl> mynameisdeleted : You may like to join #ubuntu-mirrors for assistance with setting up a mirror.
<tormod> heno, is Testing/Current/Ubuntu done for herd-2? It still says 20070111 (not .1) and there's nothing in the i386 column.
<somerville32> mynameisdeleted, Will you setup an Xubuntu mirror for us too? :)
<mynameisdeleted> perhaps
<somerville32> Thanks a bunch :)
<mynameisdeleted> what rsync url?
<Znarl> mynameisdeleted : I'll help you with the xubuntu rsyncs, don't worry.
<Mithrandir> tormod: -desktop is not tested yet.
<tormod> Mithrandir: I am d/l'ing 11.1, will try it soon.
<cjwatson> (I answered ||cw in /msg)
<Riddell> Mithrandir: ubuntu powerpc desktop CD installs fine
<somerville32> Riddell: Want to try Xubuntu powerpc desktop cd? We don't get much powerpc testing :(
<Riddell> somerville32: won't the xubuntu CDs need remade for whatever the ubuntu issue was?
<somerville32> Riddell: I went for a nap. There was a ubuntu issue?
<Riddell> somerville32: a crash in the gtk ubiquity frontend I believe
<somerville32> Mithrandir: ^^
<Mithrandir> somerville32: yes, I believe xubuntu would be hit by it as well; I'll rebuild xubuntu now
<somerville32> Thanks
<gnomefreak> are we still frozen?
<Mithrandir> gnomefreak: yes.
* somerville32 is still very cold, yes :)
<gnomefreak> thought so
<keescook> Mithrandir: are the LP publishing queues on hold?  I'm not seeing my security updates for breezy/dapper/edgy getting into the archives.
<Mithrandir> keescook: yes, they are.  I can byhand the publisher if you want.
<keescook> cool, yes please.
<Mithrandir> keescook: running.
<keescook> Mithrandir: thanks!  (Is there any way to only stop publication for feisty-only?)
<Mithrandir> keescook: not that I know of, no.
<keescook> I wonder if I should open a wishlist item for that, or if it will just naturally happen as a result of the PPA stuff?
<elmo> keescook: no, a bug would be good idea
<elmo> it's unrelated to PPA
<keescook> elmo: okay, adding
<keescook> Seveas: can you change your USN RSS reader to include the "Details" section of USNs?
<somerville32> Mithrandir, Did the Xubuntu rebuild finish?
<Mithrandir> somerville32: yeah, should be done now.
<Mithrandir> http://cdimage.ubuntu.com/xubuntu/daily-live/20070111.1/
<somerville32> Riddell, Would you be able to test? :] 
<somerville32> Mithrandir, thanks a bunch :] 
<heno> somerville32: try recruiting some of the people who reported having ppc hardware in the forums :)
<somerville32> heno: Good idea :)
* somerville32 gets a batch of cookies ready.
<heno> lots of people have signed up, but there is not much actual testing yet
<heno> sfllaw: have you looked at http://ubuntuforums.org/forumdisplay.php?f=201 today?
<heno> any ideas on getting the testing going there?
<somerville32> Maybe there could be some sort of recognition/incentive for people who actually test and make a report?
<heno> I think people also just have to get used to how it works
<heno> It's quite tricky when the relevant image can change several times during a day
<heno> might be tricky if you're not following on IRC
<heno> dunno, we'll have to find out :)
<Riddell> somerville32: downloading
* somerville32 nods.
<somerville32> Riddell: Thanks a bunch :)
<LaserJock> heno: I don't think the subforum is in the right place or has the right name :/
<heno> LaserJock: ok, what would you suggest?
<LaserJock> heno: you should at least have a stick on the Feisty subforum
<LaserJock> *sticky
<tormod> heno, I think the "signed-up" testers understand they have to dl the daily, and not sit and wait for herd-2 to show up, or having CD's coming down from the sky :)
<tormod> have to understand 
<heno> It's not a lack of viewings, which we have hundreds of, or lack of volunteers (45+), but of actual tests
<LaserJock> ah
<heno> tormod: could well be we need to be more clear, yes
<LaserJock> heno: it could be just a matter of time
<heno> LaserJock: there is a green notice on http://ubuntuforums.org/index.php :)
<heno> yeah, could be
<LaserJock> heno: oh, that's cool
<heno> people may just need a release or two to get used to how it works
<LaserJock> heno: there should be a sticky in the fiesty forum though
<LaserJock> heno: well, for instance, I download .isos at work and test at night when I go home
<LaserJock> perhaps it's just taking a while for people to test and get reports made up
<heno> LaserJock: do you have sticking powers?
<LaserJock> heno: no I don't
<LaserJock> jdong probably does
<heno> there is this one: http://ubuntuforums.org/showthread.php?t=333915
<somerville32> heno: Should I post on the forums too? I'm just recording my results in the results matrix.
<heno> somerville32: yes, please post there too, to show people how it's done
<heno> I've done that as well
<heno> ringers :)
<LaserJock> heno: also, you might want to give directions for rsync usage
<LaserJock> it might help a little for people doing multiple tests
<heno> LaserJock: yep, is there a canonical wiki page for that?
<somerville32> Can I modify Testing/Short so that the USB storage test includes unmounting it?
<keescook> say, has anyone considered adding pango to ia32-libs?
<pitti> hi
<keescook> hiya
<ajmitch> keescook: it should be in ia32-libs-gtk at the moment
<keescook> ajmitch: ah-ha!  thank you.
<Mithrandir> pitti: if you want to test -desktop i386.. I'm doing amd64 finally.
<keescook> ajmitch: the pango versions seem mismatched...
<keescook> /usr/lib32/pango/1.5.0/modules/pango-basic-fc.so: cannot open shared object file: No such file or directory
* XBillGates Rocks back and fourth.
<keescook>  /usr/lib32/pango/1.6.0/modules/pango-basic-fc.so
<Mithrandir> pitti: if not, I'll do it once this run finishes
<Mithrandir> keescook: you probably need to preload a hack to work around that, iirc.
<keescook> Mithrandir: I haven't dug into it too hard, but I think it's from pango doing explicit dlopens...
<pitti> Mithrandir: I'm currently updating my amd64 and ppc images
<Mithrandir> keescook: yes, and you need to preload a small hack which tells it to use another config file.
<pitti> Mithrandir: my quota/bandwidth is too bad for downloading i386 :(
<XBillGates> I masterbate over Vista.... (w00t j00 steve balmer)
<keescook> Mithrandir: aaah, okay.  Let me see if a symlink works first.  :)
<Mithrandir> pitti: oh well, I'll do i386 too afterwards, then.
<pitti> Mithrandir: I can do the amd64 ones if that helps you
<Mithrandir> keescook: look at the soffice.bin in the openoffice.org-amd64 source package.
<Mithrandir> pitti: more testing is better, unless you'd rather sleep.
<keescook> Mithrandir: I have been, that's how I ended up looking at the ia32 libs.  :)
<pitti> Mithrandir: doesn't help, my ppc is much slower than my amd64
<XBillGates> do you fellas get paid to work on ubuntu?
<pitti> Mithrandir: I give it the standard 'wipe disk/German' test that failed the previous time, can't hurt
<Mithrandir> pitti: thanks.
<Mithrandir> XBillGates: some do, some don't
<XBillGates> ah ok.
<keescook> Ah-Ha!  This solves my vmplayer busted-fonts problem too.
<pitti> sfllaw: do I need to do anything to require QA testing for bug 59946, or is tagging the bug as 'verification-needed' sufficient?
<Ubugtu> Malone bug 59946 in gnome-system-tools "Admin tools require admin group membership" [High,Fix committed]  https://launchpad.net/bugs/59946
<XBillGates> m|cr05h4ft 0\/\//\5 j00
<Mithrandir> hurrah, install seems to work for me now.
<Mithrandir> I need to finish it and reboot, but it looks good so far.
<Mithrandir> hurrah, amd64 desktop works for me.
<Riddell> somerville32: xubuntu on powerpc works well, except that I can't find a file manager
<somerville32> lmao
<somerville32> Thunar
<somerville32> Riddell: Could you please record your findings at https://wiki.ubuntu.com/Testing/Xubuntu/Current ? :)
<pitti> cjwatson: crap, bloody g-v-m still automounts a new partition despite the gconf keys being off; it doesn't always happen, but it just happened once to me; I'll investigate this soon
<marcheu> pitti: hello
<pitti> hi marcheu 
<pitti> cjwatson: I filed that as bug 78862, FYI
<Ubugtu> Malone bug 78862 in gnome-volume-manager "automatically mounts created file systems on live CD" [Critical,In progress]  https://launchpad.net/bugs/78862
<marcheu> pitti: hmm, so, I should be around over the next couple of days, will you have a little time ?
<pitti> marcheu: oooh, Stephane, nice to meet you
<pitti> marcheu: right now is a pretty bad time (herd-2 release pressure), but maybe we can talk tomorrow or Monday?
<pitti> marcheu: when would be a suitable time for you?
<marcheu> pitti: sure, no problem
<marcheu> sorry, I was not aware of your pre-release dates
<marcheu> pitti: well ping me, or as pm when you're ok
<pitti> marcheu: I will, thank you!
<tormod> I installed 20070111.1 Desktop i386 successfully, updated Testing/Current/Ubuntu
<Mithrandir> tormod: yay
<Mithrandir> I'm just going to finish my install too before blessing those images.
<Mithrandir> that is, I'll bless them tomorrow morning, but they're golden.
<Mithrandir> since it's midnight here and I'd rather be in bed.
<pitti> Mithrandir: I can't seem to get ubiquity offer me autoresize, otherwise amd64/desktop is great now
<Mithrandir> pitti: it offered to me.
<pitti> I tried with various setups, first swap and then large big ubuntu ext3 partition in an extended partition worked pretty well with edgy
<pitti> but I have never really been able to reproduce it reliably
<Mithrandir> 'k
<Mithrandir> anyway, I'm happy with what we have, so I'll do the final release tomorrow.  It takes about an hour and I'd rather do it when I'm more awake.
<pitti> Mithrandir: alright; I'll finish testing ppc now and add results to the wiki
<Mithrandir> thanks.
<Mithrandir> it's been tested by Riddell but more testing is always welcome.
<pitti> oh, he should add his results to the wiki then
<somerville32> Riddle: ping
#ubuntu-devel 2007-01-12
<mdke> somerville32: s/Riddle/Riddell (tab completion is your friend)
<somerville32> hehe
<Riddell> hi somerville32 
<somerville32> Riddell: If you're busy, could you just tell me the tasks you tested on the ppc platform so I can mark them as tested? :)
<Riddell> somerville32: install, log in and try to open file manager
<somerville32> How did you install?
<somerville32> Did you use the live-cd?
<somerville32> Riddell: Erase disk, auto-resize, or manual partitioner?
<teer2> Greetings, angelic developers.  I have a question about official ubuntu repositories.
<teer2> I have an idea for creating a repository for commercial game "demos" that are known to work with a given Ubuntu distribution version.
<Riddell> somerville32: erase disk
<mdke> teer2: sounds familiar :)
<teer2> Perhaps, this could be included into the official repositories.
<teer2> eventuall.
<somerville32> Riddell, And you did use the desktop cd?
<teer2> mdke: Has this been done before?
<mdke> teer2: actually, I may have misunderstood. You know there is a -commercial repository?
<teer2> I was sent up here to ask about it from the #ubuntu channel
<cjwatson> pitti: thanks
<teer2> mdke: I was told they did not have commercial games listed there.  For example, does it have the notorious Doom 3 demo?
<cjwatson> pitti: the partman log will be more explicit now about why it isn't offering autoresize, although not totally explicit
<pitti> cjwatson: I believe it only reads the gconf keys at startup; I'll teach it to always read them when mounting instead of caching the values in internal state
<teer2> mdke: Will the legendary Quake Wars: Enemy Territory demo be hosted there?  These are things I think would benefit Ubuntu if they were offered in a way that was easy for end-users to obtain.
<cjwatson> pitti: in one of your earlier logs, I noticed that it was running into a known parted bug whereby recent ext3 filesystems (including the ones created by current feisty installer images) can't be resized by parted
<cjwatson> or even checked, for that matter
<cjwatson> if you feel like digging into parted code, there's a good project in there :)
<pitti> ah, that would explain it
<lifeless> does anyone enjoy digging into parted ?
<cjwatson> autoresize of ntfs or older ext3 (maybe ext2) should still work fine
<cjwatson> I have enjoyed it upon occasion
<mdke> teer2: things are added as the relevant commercial organisations make them available. But in your case, it sounds like something that is better suited to another existing ubuntu repository, like universe or multiverse
<cjwatson> the code is quite nicely structured - it's just fundamentally rather difficult
<teer2> How can I find out information about setting up an Ubuntu repository, please?
<lifeless> I think its an interesting piece of software, every coder I know has at some point expressed interest in writing defrag/parted/etc
<LaserJock> teer2: why not just get them into the existing repos?
<lifeless> speaking of which, I really should get around to updating defrag to work on current ext3
<mdke> teer2: that's the wrong sort of information, you need information about how to include something into an existing repository, which you can get by asking in #ubuntu-motu
<teer2> LaserJock: How can I do this?  I have the ear of many developers for commercial linux games, and if I can direct them on how to submit their demos to the official distributions, then I am sure they would eb happy to do it.
<cjwatson> lifeless: the main problem with parted is that it seems to have quite a short shelf-life of active developers
<cjwatson> nobody seems to be able to cope with low-level partitioning code for very long
<LaserJock> teer2: well, #ubuntu-motu is the place to start
<cjwatson> but there's nothing else that fills its niche
<teer2> LaserJock: Like, there is this game I think is a great example of a recent Linux multiplayer game, Galcon.  Small demo, three days of online play.  Seems perfect for the official distribution.  Just tell him where to send the demo and he will do it.
<teer2> LaserJock: Okay, I'm off to ask there.  Thanks.
<cjwatson> well, not so much the official distribution, in that the official distribution consists of free software
<lifeless> cjwatson: I have been wondering for a while if its reasonable in a conceptual fashion to recast it into a python main loop/ui and bound C libraries for the bits-on-disk mechanics
<cjwatson> lifeless: the former is trivial, so that's not an interesting project for me; it's the latter that's the actual hard bit
<cjwatson> all the hard problems I'm aware of in libparted are bits-on-disk, and the language is pretty unimportant
<lifeless> cjwatson: I think language is important in so far as what developers will touch it.
<cjwatson> I don't buy that there are a significant fraction of developers who won't touch C yet want to hack on low-level partitioning code
<lifeless> cjwatson: i.e. while writing disk-bits manipulation code in python is easy to do, will the set of developers that know enough about FS internals to write such code consider contributing
<cjwatson> the sort of people who like this sort of thing also like things like kernel hacking
<lifeless> cjwatson: I'm not claiming that, I'm claiming the inverse: that folk prefer to hack on low level partitioning code in C
<cjwatson> oh, right, I definitely think that is the case
<cjwatson> sorry, I misread your comment above
<lifeless> :)
<lifeless> it was rather round about
<cjwatson> what I meant by "the language is pretty unimportant" was that there's very little in the bits-on-disk mechanics that could easily be improved in terms of e.g. readability or maintainability by being recast in a different language
<cjwatson> although more comments in that code certainly wouldn't hurt
<lifeless> mmmm. I disagree, but I dont think the win would be worth the impact in developer-time
<cjwatson> are you familiar with the code in question?
<cjwatson> (since my comment is very much tied to this particular piece of code, not a general statement)
<lifeless> not very, though I have been inside the hood before
<cjwatson> the only thing that I find particularly awkward about its C nature is having to remember to byte-swap stuff
<lifeless> oh yay, gpg gone into lalala land
<cjwatson> that's only really while physically reading and writing, though
<lifeless> have you ever seen apt-get source have gpg dissappear up its own internals ?
<lifeless> its doing 5 thousand read, time, gettimeofday, times, getrusage calls every second
<alex-weej> has anybody made an effort on some kind of Windows user migration help page
<alex-weej> documentation
<alex-weej> explaining what's different and why
<alex-weej> and how it's beneficial
<alex-weej> i get friends going mental trying to compile tarballs they downloaded off some website 'cause they think that's how they get software
<cjwatson> alex-weej: I'm not sure about web pages, but some of the Ubuntu books I've seen have excellent sections on migrating
<cjwatson> my parents are working their way through "Ubuntu Linux For Non-Geeks"
<LaserJock> alex-weej: yes, the doc team is writing a "Switching from Windows" guide for Feisty
<cjwatson> (entirely not at my prompting, but still)
<alex-weej> LaserJock: excellent! i'll keep my eyes open for it :)
<pitti> good night everyone
<davmor2> quick query with the new uuid disk naming does it mean you can rename a usb device and the name will be remembered?
<persia> mdz: I was asked to check with you to verify that the Maintainer fields in source packages in Universe should be modified in line with https://wiki.ubuntu.com/DebianMaintainerField.
<mdz> persia: yes
<mdz> (they should be)
<LaserJock> mdz: we should be doing that as we are merging (for instance)?
<persia> mdz: Thanks.
<mdz> LaserJock: yes, that would be a good start
<LaserJock> mdz: was that said in -devel-announce at some point?
<LaserJock> I know we've been doing binary mangling
<persia> mdz: Does the change belong in the changelog, or can it be assumed from the -ubuntu versioning?
<mdz> persia: like any other change to the package, it should be documented in the changelog
<persia> mdz: Thanks for the confirmation.
<mdz> LaserJock: if it wasn't, it ought to have been
<LaserJock> mdz: I can't find anything grep'ing in ubuntu-devel-announce archives. Would you have time to send one out? I think it'd be helpful for MOTU at least
<mdz> LaserJock: I have to dash for the airport shortly, but you're welcome to send one
<mdz> someone will moderate it
<LaserJock> mdz: ok
<mardi_soir> hello 
<mardi_soir> i have a problem for usink ralink wiki pci card 
<mardi_soir> under xubuntu edgy 
<mardi_soir> rt61pci does not work so .. i put the ralink rt61 driver from the website of ralink 
<mardi_soir> i made a static configuration 
<mneptok> mardi_soir: you want #ubuntu
<mardi_soir> but i m not aable to use the it 
<mardi_soir> mneptok, no one can help me on genezralist chanel 
<mardi_soir> my con is ok 
<mardi_soir> conf 
<lifeless> mardi_soir: what do you think is wrong ?
<mardi_soir> when i make a ifconfig i can see receive packet .. but impossible to ping  the gateway 
<mardi_soir> when i make a iwconfig scan i can sho the wifi lan (no encryption ) 
<mardi_soir> but non ping avaible 
<fabbione> mardi_soir: either file a bug or please move to #ubuntu this isn't a support channel
<mardi_soir> ok ! 
<mardi_soir> so have a nice day 
<mardi_soir> and just know that ralink rt61pci on ubuntu edgy no work well alone :/ 
<mardi_soir> bye 
<mneptok> fabbione: you know who handles default X session stuffs?
<fabbione> mneptok: rodarvus 
<fabbione> gotta go to feed the fattosaurus rex
<fabbione> hopefully he is awake now
<mneptok> does your wife know you call her that?
<fabbione> ahah
<fabbione> bah
<fabbione> he went back to sleep
<fabbione> it's one hour that he goes like that
<fabbione> ahh there he is now
* fabbione &
<fabbione> sfllaw: did you get around to test the glibc SRU?
<Nafallo> morning
<keescook> any archive admins around to kick the security uploads of OOo, dokuwiki through?  (Mithrandir)
<fabbione> keescook: too early probably
<fabbione> they get notified anyway.. so don't sweat it
<keescook> fabbione: yeah... I best get to bed.
<fabbione> keescook: night dude
<keescook> g'night!
<mneptok> keescook: saw you had snow in PDX \o/
<keescook> mneptok: yeah!  It's almost entirely melted now, but the dogs had fun.  :)
<mneptok> keescook: last weekend, YUL *was* PDX in terws of climate
<mneptok> *terms
<keescook> heh
<mneptok> gray, rain, 12C
<keescook> ick.
<mneptok> now -1 and snowing
<Nafallo> I have snow :-P
<keescook> Nafallo: where are you physically?
* mneptok guesses "in a chair"
<Nafallo> keescook: Kungsr, Sweden :-)
<fabbione> i guess it depends on what kind of "snow"
<fabbione> i also have snow.. right on my desk
<keescook> mneptok: gah!  right again!
<keescook> Nafallo: nice.  :)
<Nafallo> fabbione: I have real "outdoor" snow ;-)
<mneptok> fabbione: your cocaine habit is not to be discussed on public channels
<Nafallo> mneptok: lol
<fabbione> Nafallo: yeah.. we are waiting here in dk too
<keescook> okay, seriously...bed time.  :)  cya guys
<mneptok> nighty kc
<fabbione> mneptok: i didn't mention cocaine.. i tend to bake pizza on my desk.. my snow is flavour
<mneptok> romanosnow?
<fabbione> yeps
<fabbione> oh great
<fabbione> the nokia update to my phone did switch it back to danish
* fabbione forsees another hour to find the menu to switch it back to english
<mneptok> http://video.google.com/videoplay?docid=-2561063293686517066&q=the+power+of+cheese
<fabbione> mneptok: same actor as President Logan in 24h and father of one of the actors in Friends
<mneptok> hehehe. behold the power of cheese.
<Mithrandir> doko: do we have anything in particular we recommend as a replacement for toolchain-source?
<doko> gcc-4.1-source, binutils-source, and README.cross in gcc-4.1, nothing more
<Mithrandir> ok, thanks.
<pitti> Good morning
<ajmitch> morning pitti 
<pitti> hey ajmitch, how are you?
<ajmitch> ok, yourself?
<Hobbsee> heya pitti 
* pitti hugs Hobbsee 
<pitti> ajmitch: great!
* Hobbsee hugs pitti back :)
<Mithrandir> morning Martin, Sarah
<Hobbsee> hey Mithrandir!
<pitti> hi Mithrandir, recovered a bit from release stress?
<Mithrandir> pitti: yeah, doing the actual publishing now.
<Mithrandir> once that's done, I'll write the mail to u-d-a, thaw feisty, enable the publisher and all that faff
<pitti> Mithrandir: could you please run the publisher for the OO.o security update?
<Mithrandir> I'll just reenable it
<Mithrandir> (done)
<Mithrandir> it'll run in about ten minutes
<fabbione> Mithrandir: still confirmed the cd versions from Testing/Current/Ubuntu ? I need to pass them to -certification
<Mithrandir> fabbione: the CD versions in releases are the latest ones.
<Mithrandir> fabbione: also, certificationtestingprocess doesn't start until after the images are published. :-P
<fabbione> Mithrandir: yeps. i still want to make triple sure that certification can compare the release with the numbers we did test/release
<fabbione> extra paranoia.. nothing more
<Mithrandir> fabbione: if so, look at the ISO headers in the images once they're released.
<fabbione> ok
<Mithrandir> fabbione: now you can start the certification testing process
<fabbione> yes i can see.. but i don't start.. i just send a ping to Marc
<fabbione> too bad herd-2/ is empty
<fabbione> at least on one of cdimage
<Mithrandir> it takes a little while to copy 10G, even over gigabit
<fabbione> tsk tsk :)
<Mithrandir> can somebody review http://err.no/tmp/herd-2.txt ?
<Hobbsee> Mithrandir: where review means...?
<Mithrandir> Hobbsee: look for bad grammar, typos, factual errors, stuff you think should be there, etc.
<Hobbsee> right
* Hobbsee wonders if very current is correct grammer
<Hobbsee> s/grammer/grammar/
* Hobbsee suspects not - it should just be current
<Mithrandir> Hobbsee: I don't think so either; fixed.
<Hobbsee> s/inclusion of new upstream versions/new versions of programs/
<Hobbsee> Common
<Hobbsee> to all variants, we have upgraded the kernel to 2.6.20
<Hobbsee> ^ dunno if that's not obvious - may be better to say that "notably, the kernel has been upgraded to 2.6.20"
<Hobbsee> Ubuntu and should be Ubuntu, and
<dholbach> good morning
<Hobbsee> s/Among them/Among these/
<Hobbsee> hey dholbach 
<Mithrandir> Hobbsee: fixed
<Hobbsee> :)
<Hobbsee> s/just-partitioned/newly partitioned/
<Mithrandir> fixed
<Hobbsee> (a few posts a week)  <-- doesnt appear to be that frequent, is it?
<dholbach> hey Hobbsee
<Hobbsee> approved specifications, policy changes, alpha releases, <-- invert that order - list from the most important (ie, new release) to least
<Hobbsee> The Testing area of the wiki suggests various tests that can be
<Hobbsee> performed on Herd CD releases to try to catch bugs far enough before
<Hobbsee> the final release that they can be fixed:
<Hobbsee> hrm....
<Mithrandir> Hobbsee: list reversed.
<Hobbsee> Mithrandir: you found a picky native-english speaker :P
<Mithrandir> it can be up to a few posts a week, so it's to avoid people complaining about the frequency.
<Mithrandir> Hobbsee: pickiness++
<Hobbsee> s/far enough before... release / early enough in the release process/
<Hobbsee> ah right
<Hobbsee> s/to Malone:/to our bugtracker, Malone:/
<Mithrandir> fixed, fixed.
<Hobbsee> s/to Malone:/to the Ubuntu bugtracker, Malone:/
<Hobbsee> even better
<Hobbsee> Mithrandir: http://www.ubuntu.com/testing/herd2 404'd
<Mithrandir> yeah, I need to prod the relevant person to fix it.
<Hobbsee> Mithrandir: looks good to me.  didnt check most of the links though
<Hobbsee> oh
<Hobbsee> s/
<Hobbsee> needing a
<Hobbsee> stable system or anyone
<Hobbsee>  /needing a stable system, or anyone/
<Mithrandir> fixed
<Hobbsee> that was all i saw :)
<Hobbsee> </pickiness>
<Hobbsee> Mithrandir: as an aside, maybe mention slightly more explicitly that if you keep doing upgradse from herd 2, you'll have the same release as feisty final.  although yo'uve already got that there, to a degree
<Hobbsee> (there always seems to be heaps of questions in ubuntu about "i got $development version cd, which has now become final, do i need to download the final cd or can i upgrade?"
<Hobbsee> )
<Mithrandir> suggestion on where to put it?
<Hobbsee> between Welcome to Feisty Fawn Herd 2, which will in time become Ubuntu 7.04. and the next paragraph looks good
<Hobbsee>  cant see anywhere else in the structure that it would be logical
<Mithrandir> unsure, I think maybe the end of the first full paragraph's better.
<Hobbsee> argh.  yes, you're right
<Mithrandir> something like that?
* Hobbsee seemed to jump from one paragraph to another 
<Hobbsee> yeah
<Hobbsee> after 
<Hobbsee> They are however recommended for
<Hobbsee> Ubuntu developers and those who want to help in testing, reporting,
<Hobbsee> and fixing bugs.
<Mithrandir> I'm not going to say "identical" since somebody is then going to construct a corner case where something isn't right and we'll go through pain and suffering for that.
<mpt> "To turn it into Ubuntu 7.04, put it in an oak barrel and age it for three months."
<Mithrandir> mpt: heh. :-)
<Hobbsee> hehe
<StevenK> mpt: about-ubuntu! *hint*
<Mithrandir> Hobbsee: is the sentence which is there now ok?
<mpt> StevenK, it's time I faced up to the fact that I don't have any time for it :-/
<mpt> StevenK, would you like to be the maintainer and get it into universe (and main:-)?
<Hobbsee> Mithrandir: yep, looks fine
<StevenK> mpt: Sounds fine to me.
<Hobbsee> mpt: he'll badger you to sponsor him though :P
<StevenK> I need to figure out how to put it in System menu, and then I think it's right for universe.
<mpt> cool
<mpt> Then advertise it for testing
<StevenK> Indeed.
<mpt> StevenK, you're now the driver in Launchpad
<StevenK> mpt: Thanks!
<mpt> Have you noticed that the bottom right label isn't right-aligned?
<mpt> I don't know why that is -- it's right-aligned in glade
<StevenK> I haven't, actually.
* StevenK will take another look at about-ubuntu after he beats python-xlib into submission.
<mpt> The only other tiny UI tweak I see needed is making the cursor a drag cursor when it's over the draggable stuff.
<mpt> But I'm not sure if X actually has a "draggable" cursor.
<Treenaks> mpt: there's the 'hand' thing
<mpt> Isn't that for pointing at hyperlinks?
<mpt> i.e. a pointy hand rather than a grabby hand
<mpt> The one when you drag a window is grabbing, rather than grabby
<mpt> maybe I'm just being too picky ("but the Mac makes this distinction!", etc)
<StevenK> mpt: Humbug!
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Herd 2 released
<StevenK> Mithrandir: Nice!
<Mithrandir> hurrah for us!
* StevenK kicks python-xlib
<\sh> congrats Mithrandir
<glatzor> elmo: hi, I am writing on a best mirror detection function for software-properties.
<Hobbsee> yay Mithrandir :)
<glatzor> elmo: but I am no networking expert. Currently I ping every host and perform a download test of the top ten rtt hosts.
<glatzor> elmo: does sending a lot of pings has got any bad side effects? an early beta tester reported, that he had to restart his router, since the name resolution didn't work anymore after the test
<thom> glatzor: um, you have seen the dynamic-mirror-decision spec, right?
<thom> um, decisions
<thom> https://features.launchpad.net/distros/ubuntu/+spec/dynamic-mirror-decisions
<glatzor> not yet thom
<glatzor> thom: seems to be "enterprise ready" :)
<glatzor> thom: I also would like to support non launchpad based distros like Debian in software-properties.
<thom> fair enough. just making sure you knew about it
<dholbach> mdke: your bug http://bugzilla.gnome.org/show_bug.cgi?id=337252 breaks ctrl-<cursor> in vi!
<Ubug2> Gnome bug 337252 in VteTerminal "ALT + Arrow keys don't work in irssi through gnome-terminal" [Minor,Reopened]  
<dholbach> mdke: :-)
<Mithrandir> dholbach: when requesting syncs from !main, please tell me so in the bug report.  kthx.
<dholbach> Mithrandir: what's the problem?
<Mithrandir> dholbach: libdbus-java is in contrib, we sync from main by default, so it took me a little extra to work out why the sync failed. :-)
<dholbach> Mithrandir: alrighty, now I understand - I'll do so in the future!
<dholbach> Mithrandir: and thanks for libdbus-java
<pitti> mvo: are you fine with me hacking on the u-n ubuntu bzr branch for bug 62316?
<Ubug2> Malone bug 62316 in update-notifier "Provide GUI access to crash reports from root programs" [Wishlist,In progress]  https://launchpad.net/bugs/62316
<mvo> pitti: sure. I plan to do a u-n upload soonish to fix some unrelated problems, just let me know when I can merge something
<pitti> mvo: ok, so I'll work on a branch, and not directly on the ubuntu trunk
<mvo> pitti: if the changes are fairly small, just use the main branch
<cjwatson> heno,dholbach: wow, bughelper is neat
<dholbach> cjwatson: thanks :-D
<heno> heh, cool
<dholbach> cjwatson: i'll be working on https://wiki.ubuntu.com/BugHelper/Dev/ClueFiles - I'll let you know once it's implemented (and makes sense to add more .info files)
<dholbach> cjwatson: i'm open to suggestions :)
* dholbach hugs heno :)
* heno hugs dholbach
<cjwatson> dholbach: *nod* I'm just using it as an attachment-grepper at the moment really
<ogra> tsk ... gnome bugzilla is so confusing ...
<cjwatson> possibly a cache of some kind might be a good idea
<dholbach> probably
<bhale> ogra: hm it is the best bugzilla imo :)
<ogra> bhale, yes, but if i comment to a bug it automatically takes me to the next bug after i hit submit ... i always think i did something wrong until i notice i'm on another bug i'm not intrested in
<StevenK> ogra: So you can comment on that too, obviously.
<bhale> ogra: is that a preference? i dont recall mine doing that
<bhale> i remember gentoo bugzilla doing that way back in the day
<ogra> StevenK, yes, but i would rather like to re-read what i commented
<Mithrandir> tepsipakki: can you please find a ubuntu-dev sponsor for all your sync requests?  (Or apply for ubuntu-dev membership..)
<dholbach> cjwatson: I added it to: https://wiki.ubuntu.com/BugHelper/Dev/WishList
<cjwatson> dholbach: thanks
<cjwatson> bhale: doesn't seem to be a preference
<cjwatson> at least I can't find it, and I experience the same misfeature as ogra
<Mithrandir> ogra: ages ago, we talked about having a clock in the password dialog for gnome-screensaver.  Did you ever get around to adding that (controlled by a gconf key)?
<ogra> Mithrandir, bug # ? i cant remember that particular bug ... all i have is "please add an analogue clock as screensaver"
<Mithrandir> ogra: I don't think it was ever filed as a bug, just discussed on IRC.
<ogra> oh, k
<Mithrandir> ogra: I'll be happy to file it as a bug, tho
<ogra> doit :)
* StevenK pokes launchpad. Where's my accepted mail?
<ogra> even though if i put coding/patching time into g-ss i'll rather care for the broken GL stuff 
<cjwatson> StevenK: package?
<StevenK> cjwatson: python-xlib
<ogra> so it wont be highest prio
<cjwatson> StevenK: ok, just slow mail then, since it was accepted 20 minutes ago
<StevenK> Oh, right. Thanks for checking.
<cjwatson> 11:20:14 DEBUG   Sent a mail:
<cjwatson> 11:20:14 DEBUG      Subject: Accepted python-xlib 0.12-5.1ubuntu1 (source)
<cjwatson> 11:20:14 DEBUG      Recipients: Steve Kowalik <stevenk@debian.org>
<StevenK> Yup, there it is.
* StevenK checks the headers.
<cjwatson> it's worth checking because some keyserver interaction bug has meant we've been silently losing a fair few uploads of late
<StevenK> Neat. :-/
<StevenK> For some reason, master kept hold of the mail for 20 minutes.
<Mithrandir> once I find some free time, I'll write something to double-process that queue.
<ogra> Mithrandir, you have a nikon camera, is it a D50 ? 
<Mithrandir> no, d200
<ogra> ah
<Mithrandir> my brother has a d50, though
<ogra> do you have a tele lens ? 
<Mithrandir> yes
<Mithrandir> (18-200mm and 28-80)
<jsgotangco> wow you're getting into photography eh
<Mithrandir> and 70-210
<Mithrandir> jsgotangco: I got my first SLR when I was 12 or so.
<thom> why the 70-210/18-200 overlap? did you have the 70 already?
<ogra> i bought a D50 recently, it has a 18-55 lens and i'm pondering to get something more "tele" 
* jsgotangco doesn't undestand much of the tele thing
<Mithrandir> thom: yeah, it's just some old lenses from a F601
<ogra> could you bring your cam and lenses to the sprint so i could test with a different lens once ? 
<Mithrandir> ogra: sure.
<ogra> thanks ! :)
<Mithrandir> ogra: tbh, the 18-55 isn't very good lens, so I think I'd recommend the 18-200 or if you don't want to switch, a 70-200 with VR.
<Mithrandir> hmm, the 70-200 is probably expensive, it's f2.8
<ogra> i thought about a 55-200 ... to just have the rest of the range 
<Mithrandir> nikon at least doesn't seem to have anything 55-200?
<ogra> hmm, i think they have a DX lens with that range ...
<Mithrandir> indeed, they do
<Mithrandir> cheap, not very birght
<Mithrandir> bright, even
<Mithrandir> (~250)
<ogra> yeah ... 
<ogra> but 70-200 with 2.8 sunds tempting ....
<ogra> *sounds
<Mithrandir> it's around 800 or so, but has VR too.
<Mithrandir> it's pure love.
<Mithrandir> I have one, so you can try that.
<ogra> urgh ... but 200 vs 1700 is a *slight* price difference
<ogra> (i only fond one starting at 1700)
<Mithrandir> uh, that's not the correct one, then.
<Mithrandir> it's the 18-200 f3.5-5.6 VRII one you want.
<ogra> ah, yeah that one looks better 
<ogra> the 1700 one was quite huge ... 
<ogra> nothing i'd like to carry with me while travelling
<Mithrandir> it's somewhat big, but not huge, and less cumbersome than lots of other things.
<ogra> yeah
<ogra> the big one was at least twice as long ...
<Mithrandir> Adri2000: please get a member of ubuntu-dev to ack your sync requests before subscribing ubuntu-archive to them.  Thanks.
<zul> hi
<pitti> seb128: FYI, in apport bzr head I use gnome-open again (for epiphany love); I found quite a neat solution now
<pitti> (and it only took me two hours to figure out how to call firefox from a 'dropped root privs' program, duh)
<jono> where should distro naming suggestions go?
<StevenK> jono: https://wiki.ubuntu.com/DevelopmentCodeNames
<jono> StevenK: cool
<StevenK> (If that's what you mean)
<jono> yep, thanks :)
<seanh> I'm writing an extension module for Python, and wandering the best thing to do is on Ubuntu. Should I install the Python source from the Ubuntu software channel and work in that, or should I download the Python source from python.org and work on it in my homedir?
<seanh> and what will happen if I download Python and build it in my homedir, will this override the version of Python installed in the package manager? So should I uninstall Python before building it?
<pitti> seanh: if you install it to /usr/local, it should override the Ubuntu one
<pitti> seanh: except for ubuntu shipped programs, since they often hardcode the interpreter path
<seanh> so the ubuntu one is installed somewher other than /usr/local, but a version installed in /usr/local would normally be used instead?
<pitti> seanh: if you just call 'python', or use the hashbang '#!/usr/bin/env python', your version will be used
<pitti> but that's really #ubuntu stuff
<seanh> ok I'll go to #ubuntu, thanks
<sivang> pitti: is everything good with piware.de ? :) I think I have some problems sending emails
<pitti> sivang: seems to work fine for me
<ogra> pitti, whats the status of the pulse MIR ? 
<Riddell> doko: python transition has begun?
<pitti> ugh, MIR
<ogra> i have the ltsp side ready here, but can only upload it if pulse is in main ... (ltsp can only use main packages)
<pitti> ogra: not touched yet; my principle concern is supportability ATM
<doko> Riddell: yes, as fast as packages appear into the archive :-/
<pitti> ogra: i. e. it works *very* poorly on our current kernels
<ogra> works here without probs 
<pitti> has lots of skips here
<pitti> whenever I touch a window, change focus, etc
<Mithrandir> mdke: I can't process https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/74555 until it's been approved by a SRU team member.
<sivang> doko: do we have anywhere tasks to be done for the python transition for folks who wanna help?
<Ubug2> Malone bug 74555 in ubuntu-docs "Stable release update" [Medium,Confirmed]  
<pitti> ogra: because our kernel doesn't have preemption and a small TZ, and pulseaudio's default frame size is too small for that
<ogra> the only thing i saw was the /tmp/.esd/socket from flash blocking esound support, but thats fixed with flash9
<doko> sivang: no
<Riddell> doko: good luck then
<pitti> ogra: but since we do not install it by default this doesn't worry me too much for now
<ogra> please tell me if you dont see it entering main during feisty, so i can focus on other features
<ogra> (i thought it all was ok until now)
<cjwatson> Mithrandir: if it's the earlier diff with the changes described by me in the bug report, it's fine
<pitti> ogra: as I said, I just didn't find time for MIR (or wasn't poked hard enough about pulse); I don't have a compelling argument to deny it
<pitti> ogra: especially if you want it in edubuntu and it does good things for you, then it's fine for me
<cjwatson> Mithrandir: i.e. http://librarian.launchpad.net/5252310/edgy-updates.diff + fix upload target + maybe adjust version number + refer to bugs in changelog
<Mithrandir> cjwatson: ok.
<ogra> pitti, ah, ok, your previous sentences sounded different ...
<pitti> ogra: oh, I just told you the biggest problem I have with it
<ogra> ah, ok
<pitti> it's big enough to not install it by default (amongst breaking compat with oss and multiuser), but shipping in main is fine
<ogra> great
<ogra> :)
<pitti> still, I think we need to do something about the default fragsize
<pitti> at least as long as we don't ship preempting kernels with our desktops
<ogra> well
<ogra> i use the -386 kernel with ltsp (at least i pan to do that again) ...
<ogra> *plan
<ogra> hmm, but that also only sets CONFIG_PREEMPT_VOLUNTARY
<Riddell> pitti: planning to do main inclusion reports any time soon?  I'm after gsmlib
<pitti> Riddell: I just need to be poked hard enough :)
<pitti> ok, I need about 30 more minutes for my current bug fix, then I'll do some MIRs
<giskard> hi ogra 
<ogra> hey giskard 
<seb128> pitti: nice for apport and gnome-open ;)
* pitti yays as he now sees system crashes reported by apport-gtk
<lifeless> pitti: system crashes - kernel faults, or admin processes ?
<pitti> lifeless: the latter
<pitti> lifeless: bug 62316
<Ubug2> Malone bug 62316 in update-notifier "Provide GUI access to crash reports from root programs" [Wishlist,In progress]  https://launchpad.net/bugs/62316
<lifeless> pitti: excellent
* Riddell sets a poke-pitti timer for 30 minutes
<pitti> Riddell: :)
<pitti> self.work_queue.append('attack these MIRs, dude!')
<Mithrandir> hurrah!  less than one screenfull of NEW again.
<seb128> hum
<seb128> "  liblpint-bonobo-dev: Depends: liblpint-bonobo0 (= 0.1.5) but it is not going to be installed"
<seb128> weird
<seb128> (gnome-panel build)
<Mithrandir> seb128: arch skew?
<seb128> Mithrandir: could you give a retry to gnome-panel builds, that error doesn't make sense to me
<seb128> works fine from a fresh pbuilder
<Mithrandir> seb128: given-back
<seb128> Mithrandir: thank you
<pitti> mvo: I committed my update-notifier changes to my branch; shall I pull that stuff into the trunk and upload, or do you want to merge from mine and upload in the near future?
<pitti> mvo_: AYT?
<seb128> grumpf
<seb128> gnome-panel retry failed the same way
<seb128> WTF
<seb128> hum
<seb128> lot of things listed on http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html
<seb128>     * sparc:545
<seb128>     * i386:548
<seb128>     * amd64:548
<seb128>     * powerpc:545 
<seb128> can anybody have a look from the buildd what package is causing that?
<seb128> I've no such problem on my box from a fresh pbuilder using archive.ubuntu.com
<seb128> Mithrandir?
<mvo_> pitti: as you wish
<mvo_> pitti: I don't mind either way, 
<pitti> mvo_: if you are going to do some fixes and an upload today, then please just merge mine; I attached the branch to bug 62316
<Ubug2> Malone bug 62316 in update-notifier "Provide GUI access to crash reports from root programs" [Wishlist,Fix committed]  https://launchpad.net/bugs/62316
<pitti> mvo_: it's not super-urgent
<Mithrandir> seb128: that's a bit on the high side, yes.
<mvo_> I will most likely uplaoded today
* pitti hugs mvo_, thanks
<mvo_> pitti: thanks .) can you give me a quick bzr merge url ? then I can merge right away
<pitti> mvo_: it's attached to the bug
<pitti> mvo_: sftp://bazaar.launchpad.net/%7Epitti/update-notifier/apport-system-crashes/
<mvo_> thanks pitti
* pitti gives a  to bzr
<mvo_> pitti: I get bzr: ERROR: Not a branch: sftp://bazaar.launchpad.net/~pitti/update-notifier/apport-system-crashes/
<mvo_> ?
<Mithrandir> seb128: seems to be python-related.
<pitti> mvo_: wtf??
<seb128> Mithrandir: probably yep, there is no base lib to the list
<Mithrandir> seb128: I think doko just switched the default version to 2.5
<Mithrandir> which blew up the world.
<Mithrandir> doko: ^^ did you? :-)
<seb128> hum
<seb128> what is weird is that it works fine with a fresh pbuilder
<Mithrandir> hmm
<Mithrandir> that's strange.
<doko> Mithrandir: yes, just waiting for the new python-defaults to enter the archive, then I'll mass-upload
<seb128> doko: mass upload what?
<pitti> mvo_: bzr get'ing this WFM
<doko> packages depending on python (<< 2.5)
<Mithrandir> doko: seems to be in the archive now at least.
<seb128> what packages are those?
<Mithrandir>     python | 2.5-0ubuntu1 |        feisty | all
<Mithrandir> python-defaults | 2.5-0ubuntu3 |        feisty | source
<doko> seb128: ronne:~doko/cxx/auto/DONE
<Mithrandir> seb128: I guess liblaunchpad-integration is the one causing massive amounts of failures for you
<seb128> Mithrandir: looks like yep
<mvo_> pitti: a permission problem maybe?
<doko> liblaunchpad-integration is one of them
<pitti> mvo_: oh, I see; it's sftp and ~pitti, not ~u-core-dev
<pitti> mvo_: shall I do the merge myself?
<seb128> doko: that would be nice if you would give a warning before breaking half of main :p
<Mithrandir> I think I'm going home and hope this has gone away by monday. :-P
<seb128> graaa
<doko> Mithrandir: when are the 2.5-0ubuntu3 binaries supposed to enter the archive?
<Mithrandir> (seriously, I'm going home, if it's still broken this evening, tell me and I'll poke at the bits I can)
<mvo_> pitti: yeah, just do it
<seb128> I've uploaded a gnome-menus breaking gnome-panel
<seb128> they were supposed to go together
* seb128 curses doko
<Mithrandir> doko: my guess is they're in this publishing run.
<pitti> mvo_: pushed to trunk
<mvo_> pitti: thanks
<doko> seb128: I did in the meeting yesterday
<bddebian> Heya
<bddebian> Mithrandir: thanks for the syncs and such!
<Mithrandir> I think a switch of the default python version would be appropriate on u-d-a (and not on a friday afternoon)
<Mithrandir> bddebian: np, good to get the count down a bit.
<seb128> doko: you didn't say it was going to break half of main :p
<seb128> anyway that's done now, let's fix everything
<doko> seb128: fix the library packages to support both of 2.4 and 2.5, then they cannot be broken :p
<seb128> doko: well, I just don't like having things broken on friday afternoon because usually it means they are going to be broken for everybody until monday
<doko> seb128: please raise your concerns when we plan such things. the friday afternoon is the time where it hurts not many people.
<ogra> if i cant work on the weekend it hurts me ...
<doko> the weekend didn't start
<seb128> doko: well, you made half of main non-installable, which broke the GNOME builds from this morning, which means gnome-panel is broken for everybody now
<ogra> well, it starts soon :)
<doko> seb128: then please fix gnome-panel
<seb128> doko: I've fixed it this morning, the package doesn't build though :p
<seb128> doko: because the buildd is not able to install the Build-Depends to build it :p
<seb128> doko: anyway no big deal, let's do your massive rebuild, that will probably make launchpad-integration installable again ;)
<pitti> there go another handful of hal bugs
<pitti> Riddell: hmm, gsmlib seems to be a bit dead, and sounds like hard to support hardware-wise
<BenC> is there a place where the feisty release notes are being drafted?
<keescook> morning folks
<kylem> morning kees.
<pitti> hi keescook 
<keescook> hiya kylem 
<keescook> hi pitti
<pitti> Riddell: argh @ gsmlib: prerm script is evil and buggy, so is postinst
<fabbione> hmmm feisty exploded
<fabbione> Totals by arch:
<fabbione>     * sparc:546
<fabbione>     * i386:549
<fabbione>     * amd64:549
<fabbione>     * powerpc:546 
<fabbione> (uninstallable)
<pitti> fabbione: see scrollback; that's due to the python transition
<fabbione> oh ok
<seb128> iz doko bog :p
<fabbione> seb128: so tell me my little friend.. what's the best bluetooth gnome app out there?
<seb128> ask dholbach, he's doing bluetooth things ;)
<fabbione> dholbach: ^^^
<dholbach> fabbione: that depends on what you want to do
<fabbione> dholbach: everything possible.. connect my phone to the lappy.. sync data.. upload/download files..
<dholbach> gnome-vfs-obexftp (which is still in binary NEW it seems) gives you the files on your phone, if you browse to obex:///
<dholbach> gnome-bluetooth (together with nautilus-sendto) is for sending and receiving single files
<dholbach> multisync (dunno if that works - never touched in 2-3 years) is for synchronisation
<azeem> probabyl opensync works better, but has no GUI yet
<dholbach> there's also wammu/gammu - but I don't know how that works
<dholbach> and it's not gnome app either
<dholbach> that's all i can say
<pitti> fabbione, dholbach: I have used multisync a bit, but BT synchronization is only at cvs head and sucks
<doko> seb128: come to Berliiin to fix your bogs
<fabbione> i am told this phone works fine with syncml and eGRoupware...
<fabbione> so i assume we are still with duck tapes and patches
<pitti> fabbione: pretty much, yes
* fabbione thinks...
<pitti> fabbione: using my phone as a GPRS modem is easy, but still requires /etc editing
<fabbione> yeah modem doesn't bother me and i don't usually need it
<azeem> pitti: there's no multisync cvs head AFAIK
<fabbione> plus i don't even have a dial up account
<pitti> it's the single useful thing that is easy to achieve, at least with my phone ;)
<fabbione> pitti: ADSL in denmark are stable :)
<fabbione> nobody has ISDN anylonger
<pitti> fabbione: I'm talking about GPRS
<fabbione> yeah we don't need dial-up :)
<pitti> fabbione: i. e. internet through your mobile phone provider
<pitti> fabbione: but the mobile acts as a modem in that case
<fabbione> pitti: yes.. i know what it is 
<fabbione> it's still a dial-up
<pitti> sure
<fabbione> doko: i assume you did a batch rebuild for all the python pkgs.. 
<fabbione> doko: anything more than just a rebuild?
<fabbione> doko: also.. ocfs2-tools_1.2.2-0ubuntu3_source.changes Rejected
<pitti> what I don't understand is, what's the point of the python-{central,support} fu if it still requires large transitions?
<fabbione> Exception while accepting: This sourcepackagerelease is already accepted in feisty.
<azeem> just got one as well
<doko> fabbione: iz a launchpad bug: I get an Rejected *and* an Accepted message for every package ...
* pitti adds his blessing to pulseaudio MIR to calm down ogra
<ogra> YAY !
* ogra hugs pitti and makes a note to pay a beer in oslo
<pitti> ogra: I added the remark 'not for ubuntu-desktop, just for main'
<crimsun> thanks, pitti :)
<ogra> yep, thats fine ...
<pitti> ogra: oh, so you'll come to Oslo after all? yay
<ogra> pitti, even though it micght end up on the CD as ltsp dependency
<ogra> *might
<pitti> sure, no problem with that
<ogra> great :)
<keescook> hm, any reason there's no /bin/usleep in (Debian and) Ubuntu?  I thought that used to exist?
<sivang> doko: thanks for the rebuild :)
<pitti> argh, apport ftbfs
<fabbione> doko: you win
<doko> pitti: if a package supports both 2.4 and 2.5, then I avoid an upload; unfortunately some packages still hardcode the python version
<Mithrandir> keescook: just use sleep?
<keescook> Mithrandir: oh, hm, you can give sleep a float.  hunh.
<pitti> doko: ah, I see
<stdin> hi, anyone here know why mplayer/mencoder is in multiverse not universe ?
<Lathiat> because it has non-free code
<pitti> stdin: mainly due to patent issues
<Lathiat> well, yeh i guess thats more specific
<pitti> Lathiat: hm, it's all free software AFAIK
<Lathiat> i think it also depends on other stuff in multiverse
<pitti> it's a bit hypocritic, though; xine has more or less the same code and is in main/universe
<Lathiat> which has more patenty fun 
<Lathiat> pitti: hrm i thought some of the libraries it can use is nonfree stuff etc but i could be wrong and am far from authorative on the issue :)
<Lathiat> or that stuff may be left out of the package too
<pitti> well, it can use w32codecs, but doesn't ship it
<pitti> doko: I approved your java libs/jython MIRs, in case you want to shuffle around something
<siretart> Lathiat: mplayer does not contain non-free code, and does not depend on any non-free code
<doko> pitti: thanks
<siretart> Lathiat: I personally don't think it belongs to multiverse, but rather to universe
<stdin> the app itself is under gpl
<Lathiat> doe sit depend on anything in multiverse?
<siretart> nope
<Lathiat> hrm ok
<siretart> not that I knew
<pitti> doko: oh dear, myspell, ispell, aspell, and now hunspell?
<Lathiat> i was completely wrong so please ignore me thanks
<Lathiat> :)
<siretart> Lathiat: in debian mplayer is in main, btw.
<pitti> siretart: uh, since when?
<siretart> Lathiat: the only difference is, that in debian, mencoder was removed
<stdin> it suggests w32codecs and libdvdcss, but it doesn't depend on them
<pitti> ah
<siretart> pitti: since a few months
<Lathiat> lame is in universe
<doko> pitti: trying to drop myspell. enchant already depends on it, OOo will depend on it, firefox needs to be done
<Lathiat> s/universe/multiverse
<Lathiat> lame is in multiverse
<siretart> pitti: there were indeed some remaining licencing issues, like the tremor issue, but they were sorted out upstream
<Lathiat> libmp4v2-0 (faad2) is also
<Lathiat> not to say none of those could move
<pitti> doko: but I assume/hope hunspell uses the same dictionary packages as myspell?
<siretart> pitti: AFAIK debian ftp-master told the maintainer, that he would rather approve an mplayer package without mencoder, but wouldn't reject an mencoder at once either
<doko> pitti: yes
<siretart> pitti: so the maintainer dropped mencoder for getting mplayer into etch
<pitti> siretart: too bad, mencoder is the only sane encoder that actually worked for me
<pitti> apart from thoggen of course, but that takes two years to encode a movie
<Adri2000> Mithrandir: I usually do that, I didn't for atlas3 because it was a rebuild, there was no ubuntu change. I'll subscribe u-u-s to ack it
<siretart> well, its really a pitty, because ffmpeg is in debian/main as well, and does also contain various mpeg encoders
<siretart> and so far, there were no legal problems
<siretart> so I think it might be okay to have mencoder in debian as well, but that's not my call to decide
<siretart> actually, I didn't really investigate our mplayer package enough to ask for promotion of mplayer in ubuntu to universe. I rather care for xine, you know ;)
<pitti> siretart: historically the debate xine vs. mplayer and main has mainly been on a personal flamewar and upstream attitude level, I didn't actually see a compelling legal argument
<siretart> pitti: the legal argument are the mpeg encoders, espec. stuff for mpeg 1 level 3 (aka mp3) and mpeg 4 encoders and aac stuff
<pitti> siretart: what was the argument?
<siretart> pitti: that they were actively enforced patents
<pitti> "it's ok to ship stuff I like in main, and I dislike in universe, although both contain patented algorithms"?
<pitti> ah, and those encoders aren't in xine?
<siretart> in the sense, that fraunhofer (and others) are charging for them
<siretart> pitti: xine doesn't encode
<siretart> it only decodes
<pitti> ok
<siretart> which seems to be a difference to the patent holders
<siretart> and mplayer in debian decodes only as well
* pitti -> brb
<pitti> siretart: hm, but I thought in the case of a patent infringement the GPL says that you cannot distribute the program at all; so what difference does universe and multiverse make in this case?
<siretart> pitti: which part of the gpl mandates that?
<mjg59> 7
<siretart> ah, I remember
<ogra> doko, did you hardcode hwdb to 2.5 or did you just drop all versioning from the deps ? 
<ogra> (i thought i had switched it to "python (>= 2.4)" ages ago)
<pitti> siretart: sorry for my dumb questions, but I'm still horribly confused by all this patent mess
<pitti> seb128: yay for ppc blue screen fix :)
<seb128> pitti: ;)
<jono> where can I get the ubuntu logo used with usplash?
<jono> need it for a presentation slide
<siretart> pitti: I'm no patent expert either, I'm just reading stuff. I think we are not the only ones  who are horribly confused by this mess
<siretart> pitti: e.g. aspectc++. Upstream lately got contacted with an email "how can you redistribute ac++ without paying fees to gregor kiczales?" - the answer is: he didn't sue, and in europe, there are no software patents
<siretart> pitti: it isn't even clear, if their patents are valid at all!
* ogra sees his feisty-devel mailbox explode ....
<ogra> err feisty-changes
<siretart> pitti: for ffmpeg: the debian maintainer is rather conservative, and disables/removes codecs, from which he had evidence of lawsuits. 
<pitti> siretart: they are probably valid in some countries?
<siretart> pitti: most probably valid in us, but not (yet) in europe
<siretart> but even there it is unclear, because no one has gone to court with that case
<siretart> about most potential patents we are facing wrt mencoder, (at least I think so)
<pitti> siretart: hm, but I agree that decoders are more important to have in a distro
<pitti> siretart: since there is ogg, I never encoded anything into mp3 any more
<siretart> pitti: even ogg isn't patent free
<pitti> siretart: and if thoggen wasn't so exaggeratingly slow, I wouldn't need mencoder either any more
<pitti> siretart: I thought it was designed to be? *darn*
<siretart> pitti: according to ffmpeg upstream (from where I have this statement), it is nearly impossible to make any efficient encoding without touching any patents
<pitti> hm, true
<siretart> pitti: as I said, it is unclear if the patents, which mencoder or thoggen or what ever coudl violate, are valid at all, because nobody has sued yet. and very few are interested in finding that out :/
<siretart> so the ffmpeg/mplayer devs are very dissapointed that most distributions refuse to ship their software, or that folks are telling, that their software was non-free.
<siretart> but well, they have a strange attitude anyway :/
<siretart> btw, does anyone know why debian syncs have stalled?
<siretart> no time, technical problems or some freeze?
<MagicFab> ffmpeg2theora has to be worse
<pitti> siretart: sync freeze
<siretart> pitti: huh? - since when?
<pitti> siretart: see FeistyReleaseSchedule
<MagicFab> or vlc
<siretart> pitti: err, I'm talking about manually requested sync via malone
<pitti> siretart: ah, those; they still work
<pitti> siretart: just today Mithrandir did a whole bunch of stuff
<siretart> ah. good to hear
<pitti> siretart: these were stalled due to herd-2 release
<siretart> aren't they announced on feisty-changes or something?
<pitti> siretart: check your mail :)
<ogra> they are :)
<siretart> pitti: wow. good hint! :)
<sladen> jono: apt-get source usplash-artwork or somesuch
<Mirv> siretart: ogg (vorbis) is designed to be "patent-free", but of course in today's world anyone can sue anyone for some obscure software patent
<siretart> Mirv: we were talking about ogg/theora before
<Mirv> siretart: ah, ok, but theora is actually quite good, as there are patents covering it, but the patents are given to all of humankind for eternity (etc.) by On2...
<Mirv> "better" in the sense if it's better in the software patent world that there are some "defending" patents
<siretart> interesting
<ogra> argh ... gst-pulse is a separate package ? 
<ogra> meh .... more MIRs
<ogra> seb128, do you know if there are plans to merge gst-pulse in the normal gstreamer source package ? 
<seb128> ogra: no idea, maybe slomo knows about it
<pitti> gst-plugins-good rather
<ogra> ok
<ogra> i'll ping him if he's here
<ogra> seems silly to keep it separate ...
<doko> mvo: ping
<mvo> doko: pong
<ogra> BenC, ping
<troy_s> jono -- do you mean the same logo that is on the GDM?
<ogra> crimsun, ping 
<doko> pitti: http://librarian.launchpad.net/5714888/buildlog_ubuntu-feisty-i386.pygresql_1%3A3.8.1-1build1_FAILEDTOBUILD.txt.gz
<Mirv> pitti: too bad even hunspell isn't good enough, but hopefully even some of the *spell can be gotten rid of some day
<pitti> doko: that's part of the libpq4->libpq5 transition I'm going to do soon; I'll have a look at it
<doko> thanks
<dholbach> heno: looks like xml info file support is working now
<dholbach> heno: I didn't work on the 'inherits' and 'general clue' part yet, but at least and/or queries work now
<heno> dholbach: excellent!
<dholbach> i'll commit to my branch in a bit and write a mail to bugsquad@
<BenC> ogra: pong
<dholbach> heno: after that we can get to work and spread the word :-)
<heno> cool, I'll need to come up with some test cases now
<heno> yep
<TuxCrafter> Hello guys
<TuxCrafter> I am debugging a problem with my via sound chip
<TuxCrafter> and I believe that the driver is bad and some times when a app want to connect to the sound device the total systems freezes 
<TuxCrafter> I what to confirm this further by not allowing a app access to the sound device  
<TuxCrafter> except for super user apps
<TuxCrafter> how can I do this
<stdin> maybe by changing permissions of /dev/dsp ?
<TuxCrafter> c------r-- 1 root root 14, 3 2007-01-12 08:48 /dev/dsp
<TuxCrafter> should that do it :-D
<TuxCrafter> jup
<TuxCrafter> It can also be a irq bug
<stdin> umm, then you'd get no sound
<TuxCrafter> but that will be vvery bad
<TuxCrafter> indeed
<TuxCrafter> no sound no system freezes I hope
<stdin> crw------- root root ........ would do
<TuxCrafter> and I will run my music with sudo :-P for test
<ogra> BenC, my laptop behaves strange from time to time (stalls completely on input, restarting services takes up to 10min without any apparent reason (load is low, top doesnt show anything worrying, CPU is at 800MHz) and if i look in dmesg i see "APIC error on CPU0: 40(40)"
<TuxCrafter> crw------- 1 root root 14, 3 2007-01-12 08:48 /dev/dsp
<TuxCrafter> done
<ogra> BenC, any hint what i can do there ? 
<TuxCrafter> orga: disable apic for a will
<ogra> TuxCrafter, thats indeed the first thing i try in such cases
<BenC> ogra: /phone, brb
<ogra> (booting with nolapic)
<TuxCrafter> and?
<ogra> doesnt change anything
<TuxCrafter> did you change the grup params
<ogra> else i wouldnt ask ben ;)
<TuxCrafter> tried a vanila kernel
<TuxCrafter> new one
<pitti> hmm, how do I tell python's distutils about custom build switches? I need something like ./setup.py build --backend=backends/dpkg.py
<ogra> no, i wouldnt touch vanilla
<TuxCrafter> or build a kernel for ubuntu specs
<TuxCrafter> pitti: don' know it but maybe you can try the #phyton channel
<TuxCrafter> typo
<doko> ogra: http://librarian.launchpad.net/5715953/buildlog_ubuntu-feisty-i386.hwdb-client_0.6-0ubuntu17_FAILEDTOBUILD.txt.gz
<ogra> TuxCrafter, i have a colleague caring for the kernel ... thats why i ping him ;) (as he would ping me for ltsp or edubuntu problems)
<Amaranth> pitti: i always did a hack that checked to see if you ran 'build' and parsed custom switches on my own
<Amaranth> pitti: then i said 'screw that' and switched to autofoo
<pitti> Amaranth: argh, and removed them from sys.argv()?
<pitti> s/()//
<ogra> doko, you know the rule .... who ever touched it last :P
<Amaranth> pitti: yeah
<doko> Riddell: kdelibs4-dev: Depends: kdelibs4c2a (= 4:3.5.5a.dfsg.1-3ubuntu9) but it is not going to be installed
<doko> any hints?
<Amaranth> pitti: there might be a better way but i don't remember finding one
* pitti can't believe that distutils doesn't provide such a thing, but he doesn't find anything
<doko> ogra: please check; it looks unrelated to python
<Amaranth> that's why i dropped it :)
<ogra> ergh, where does that intltool stuff come from ... i didnt add that
<Amaranth> well, that and intltool
<ogra> Riddell, did you add intltool stuff to hwdb-client ? 
<TuxCrafter> guy's i am laving and sdin: thanks for the feedback
<dholbach> heno: mail sent - yeeeha :)
<heno> dholbach: cool, reading
<doko> pitti: move it in the debian/rules file. no crap in distutils please
<heno> dholbach: great, I'll review and merge
<dholbach> heno: gracias!
* dholbach hugs heno
<pitti> doko: 'crap'? I just want to define a custom option at setup.py install and use it to install a particular backend
<heno> dholbach: Thank you!
<pitti> doko: that should not really go into debian/rules; rules should just supply the correct backend value
<dholbach> heno: oh... sorry let me remove the "#"s
<dholbach> heno: done
<heno> k
<doko> pitti: ohh, I thought some kind of custom compilation flags ... ;)
<geser> doko: kdelibs4c2a depends on launchpad-integration which depends on python (<< 2.5) and the rebuild launchpad-integration isn't on the archive yet
<sladen> that sounds a bit strong.  to what extent does it really /depend/ ?
<doko> geser: I see, looking at l-i
<cjwatson> mdke: could you update the installation-guide on help.ubuntu.com? I think it's at least one revision back from what's in edgy
<cjwatson> since apparently the devfs fix isn't in there
<gnomefreak> is the python problem coming from kdelibs LP-I and py2.5 related 
<gnomefreak> people cant update python is holding back all kinds of packages
<ogra> yeah, doko is in the middle of a transition
<gnomefreak> ok cool
* dholbach high-fives doko
<gnomefreak> big mess in #ubuntu+1 atm :)
<dholbach> doko: GO DOKO GO
<ogra> add it to the topic ;)
<gnomefreak> i did
<gnomefreak> in a very scary way but i did :)
<seb128> doesn't boot?
<seb128> WTH?
<seb128> what is broken?
<seb128> lot of packages are not installable or what to be removed
<seb128> but that should not break the world
<gnomefreak> downgrading python seems to work atm. seb128 it boots for most people atm but we are leaving it there waiting on X adn usplash and stuff
* ogra wonders what seb128 is referring to with "doesn't boot"
<seb128> ogra: 
<seb128> "Feisty is very broken at the moment - prepare to chroot in if any of the updates have broken your system so it doesn't boot. Please DO NOT UPDATE YOUR FEISTY TODAY!!!"
<seb128> that's from the topic of #ubuntu+1
<ogra> oh, the topic
<gnomefreak> yep
<ogra> well it should still boot ...
<gnomefreak> atm for most it does but very early it didnt boot
<dholbach> doko says something about the atheros chipset?
<thom> madwifi causes the kernel to BUG
<ivoks> so does kvm-intel here too :)
<seb128> gnomefreak: I would be curious to know what breaks the build still, that need to be fixed, I doubt that's the python transition
<gnomefreak> seb128: the bigggest issue today is python 2.5 but i havent been hit by that bug (not real sure why)
<ogra> but the python stuff is very very unlikely to prevent you from booting
<gnomefreak> seb128: the kernel boots on most of the systems but there are still a few people saying they cant boot it
<gnomefreak> ogra: differnt issue
<ogra> right
<ogra> but unidentified yet it seems
<seb128> gnomefreak: well; the topic is scary and I don't have the feeling that feisty is that broken
<gnomefreak> the python has nothing to do with booting. i dont know who added the non booting line but im leaving it because some people still cant
<gnomefreak> python is affecting X it seems though 
<gnomefreak> all i added was dont do updates today
<ivoks> maybe 'doesn't boot' is derivation from 'gnome-desktop is broken'
<gnomefreak> iirc the non booting was due to initramfs-tools that was already fixed (atleast here)
* gnomefreak not gonna assume its fixed everywhere without knowing it is
<doko> Mithrandir: please requeue python-kde3, kdebindings, kde-guidance on all archs
<mdke> Mithrandir: Colin has approved it, no?
<mdke> cjwatson: yes, but I don't have access to the server, it will have to go through RT
<geser> Mithrandir: could you please give-back gnomesword on sparc? it was successfully retried on all arch except sparc today. thanks
<Riddell> ogra: mvo added intltool support, and I enabled it for the qt version
* LaserJock hugs Mithrandir 
<LaserJock> thanks for all the archive work
<bddebian> heh
<cjwatson> mdke: ok
<cjwatson> mdke: will you file (or have you filed) that?
<mdke> cjwatson: I'll need to prepare something for them to slot in
<mdke> cjwatson: on the todo list for this weekend :)
<cjwatson> ta
<livingdaylight> hi
<livingdaylight> what is the process of getting an application added to repositories?
<dsas> livingdaylight: https://wiki.ubuntu.com/MOTU/Packages/New
<crimsun> ogra: pong
<ogra> crimsun, pong
<crimsun> ogra: hi
<ogra> hey
<ogra> i switched my ltsp clients to pulse 
<ogra> using an asoundrc with pcm and ctl entries
<ogra> but apparently the asa mixer doesnt work 
<ogra> *alsa
<crimsun> as in `alsamixer'?
<ogra> no as in the panel applet
<crimsun> err, which panel applet, pulse's?
<ogra> no, gnomes
<ogra> gnomes volume control applet ...
<crimsun> ok, these are thin clients that lack local audio devices, correct?
<ogra> no, they have local audio devices
<ogra> thats where the sound comes out 
<ogra> the user logs via ssh -X into the server from the client 
<ogra> gnome-session is running on the server and ssh -X forwards the display to the client 
<ogra> pulse is started on the client and PULSE_SERVER is set to point to the client on login
<ogra> gstreamer is set to alsa
<crimsun> instead of pulse?
<ogra> and alsa uses the asoundrc (in ~/ for the testing, but that shouldnt have any influence i think)
<ogra> works perfecttly fine ... apart from volume control
<ogra> the asoundrc has:
<ogra> pcm.!default {
<ogra>     type pulse
<ogra> }
<ogra> ctl.!default {
<ogra>     type pulse
<ogra> }
<crimsun> and ``aplay /usr/share/sounds/startup.wav'' is audible, correct?
<ogra> hmm, i didnt try 
<ogra> but the login sound (gstreamer) works and i can listen to radio through rhythmbox just fine
<ogra> the gstreamer-properties testsound works as well
<crimsun> right, GSt should work fine if you've installed and selected the pulse sink and source for it
<ogra> i just cant adjust the main volume through the mixer applet
<ogra> i didnt
<ogra> i used the alsasink and the asoundrc
<ogra> but i tested with the pulsesink and indeed that wors as well
<ogra> *works
<crimsun> ok, so two tests: 1) Does that aplay command above work? (it should)  2) Does selecting a different [pulse]  device in Volume Applet> Preferences affect the situation?
<ogra> ok, i'll try that, i'm sadly not near any thin client now, thanks for the hints i didnt think about changing the mixer device 
<crimsun> what I recommend using instead of the Volume Applet is Pulse's Device Chooser applet
<crimsun> you can use that and choose pulse's Volume Control
<ogra> hmm, i dont want to tweak the defaults of the desktop if possible 
<crimsun> ok
<ogra> users may log in on thin clients as well as directly on the server ... so the settings should be the same as much as possible 
<ogra> thats why i try to only tweak stuff in the lowest leve
<ogra> *level
<crimsun> I know the Volume Applet works here, so it sounds like there's at least an environment variable difference if not also the fact that I'm not logging into an LTSP server
<ogra> well, the volume applet would work if i played sound on the server ... it just doesnt seem to work over the network ... but i'll try changing the settings first and then see how i can achieve such a setup witout breaking on non-ltsp desktops
<crimsun> keescook: that's a good question RE: acroread.
<keescook> can any archive admins shed some light on why acroread has vanished from feisty?  :)
<geser> I would guess it's the solution for bug 43780
<Ubugtu> Malone bug 43780 in acroread "Acroread: Redistribution may not be allowed" [Low,Fix released]  https://launchpad.net/bugs/43780
<keescook> geser: oh! heh
<crimsun> welp, less work for us. We win.
#ubuntu-devel 2007-01-13
<mdke> openoffice broken?
<mdke> I can't install latest ubuntu-desktop
<geser> mdke: because of the python 2.5 transition
<geser> python-uno (source openoffice.org) needs a rebuild which is current happening (https://launchpad.net/ubuntu/feisty/+source/openoffice.org/+builds)
<gnomefreak> mdke: python issues
<gnomefreak> mdke: doko has been building his butt off fixing it
<_ion> When apt-get upgrading, a bunch of openoffice packages have been kept back for weeks or so.
<mdke> thanks chaps
<gnomefreak> _ion: language packs i believe
<mdke> also some conflict between gnome-menus and gnome-panel, looks like
<gnomefreak> mdke: thats one im not real sure python will fix
* gnomefreak checking to seee waht has been uploaded (god i love smart)
<dsas_> gnomefreak: I think there's been an upload to fix it, but it couldn't get all of the build-deps to build it due to python fallout
<dsas_> gnomefreak: Something like that anyway.
<gnomefreak> its still mess
<gnomefreak> dsas_: http://gnomefreak.pastebin.ca/314686
<dsas_> gnomefreak: Yeah it is, I'm sure it'll be sorted soon.
<gnomefreak> looks like most of py is fixed but now massive rebuild on other packages
<gnomefreak> im expecting it mon.-tues. but hoping before i leave in morning
<dsas_> gnomefreak: Ok, cool. I have no idea how long these things take...
<gnomefreak> but it really doesnt matter when it gets done. thats all part of testing
<gnomefreak> he/they are working hard to get it done
<maxamillion> any plans for ubuntu to adopt the debian "testing" graphical installer option for the ubuntu alternate cd image?
* maxamillion is just curious ...
<Hobbsee> maxamillion: when we have ubiquity?  why would we?
<Hobbsee> maxamillion: for alternate?  no.  alternate's for people without the specs to run the desktop cd
<Hobbsee> (well, once ubiquity's finished, anyway)
<Hobbsee> that's what i hear to be the case
<somerville32> maxamillion, screenshot?
<maxamillion> somerville32: just a moment
<maxamillion> somerville32: http://shots.osdir.com/slideshows/slideshow.php?release=724&slide=1 <---screenshot walk through .... 
<maxamillion> somerville32: http://shots.osdir.com/slideshows/slideshow.php?release=724&slide=1 <--- old article
<somerville32> cool :] 
<maxamillion> Hobbsee: i don't think you understood what i was talking about ... its a gui installer that doesn't require the specs of the desktop cd and it is just an option that is passed at boot time for the installation cd, so if on the alternate install a user would like to use a gui installer, they can ... it would be a more inviting installer even for those with older hardware
<maxamillion> the only reason i bring this up now is because I have recently been playing with the alternate image on a range of machines and the text based installer seems to randomly not have the ability to scroll on some machines and i figured if that could either be fixed and/or given an alternative, it might be nice
<maxamillion> Hobbsee: any thoughts?
<somerville32> Hobbsee think? Thats ludicrous! 
* maxamillion snickers
* somerville32 huggles Hobbsee 
<manchicken> Anybody here familiar with building from bazaar?
<manchicken> I'm working on this adept program, and it won't build straight out of bzr.
* Hobbsee smashes somerville32 
<somerville32> Ouch
* somerville32 is smashed.
<cypherbios> Hobbsee: can you take a look when you have some time? http://revu.tauware.de/details.py?upid=4015
<cypherbios> wrong channel :) jump to #u-m :P
<manchicken> Anybody here familiar with the dh_install process?
<LaserJock> manchicken: you might want to try #ubuntu-motu for that
<somerville32> cypher1, #ubuntu-marketing ? ;] 
<somerville32> cypher1, sorry
<somerville32> cypherbios, #ubuntu-marketing ? ;] 
<cypherbios> somerville32: no no... ubuntu-motu ;)
<manchicken> Okay.  I'm working on an "official" package though.
<somerville32> manchicken, Thats ok
<manchicken> I'm just looking for someone who knows the build process.
<LaserJock> manchicken: #ubuntu-motu is where we do that
<manchicken> Then that may be where I want to discuss it ^_^
<manchicken> Normally I just bother Riddell ^_^
<cypher1> somerville32, he he
<cypher1> bye all
* somerville32 waves.
* cypher1 waves back
<Cashel> Are you folks aware that the last update broke gnome? 
<Hobbsee> yes
<Hobbsee> doko_: is, anyway
<Hobbsee> and kde
<Hobbsee> Cashel: just dont upgrade python2.5
<Cashel> Ahhh good to know... 
<Cashel> ahh so thats the evil one... I just started lookin for it :)
<Cashel> thanks for the tip... before this I've been impressed with the level of dependability, you guys do good work :)
<Hobbsee> does anyone know where i could find jono's mobile number?
<Hobbsee> oh, probably off elky
<elkbuntu> um, how about his webpage, the contact section
<Hobbsee> point
<elkbuntu> s/page/site/
<Hobbsee> didnt think he'd have his mobile on there - cool
<ajmitch> oh that's right, jono is invading sydney
<ajmitch> poor people
<elkbuntu> ajmitch, you're just jealous
<ajmitch> not at all :)
<elkbuntu> lies, all lies.
<Hobbsee> haha
<ajmitch> just because I have to sit at work for the week...
* elkbuntu hands ajmitch a violin.
<ajmitch> thanks
<elkbuntu> we promise to show you lots of photos of us having a really awesome time too :)
<ajmitch> I'll send you exciting photos of my desk at work in return, how's that for a deal?
<Hobbsee> hehe
<Hobbsee> sounds great
<Hobbsee> !
<Mithrandir> doko_: given-back
<somerville32> Mithrandir: Have you started processing new again? :)
<Mithrandir> somerville32: I did a fair amount of it yesterday, yes.
<somerville32> Is it true that you start at the bottom? ;] 
<Mithrandir> it's a FIFO, but not completely.  I sometimes skip stuff for a while.
<somerville32> Sorry to bug you about it but I'm just eager to get pyNeighborhood approved. It is my first package. Unfortunately it would already be in Feisty if it wasn't for a small issue with the licensing. Taflo (sp) already reviewed it and I had to modify debian/copyright to say that only GPL 2 can be used, not GPL 2 or later.
<Mithrandir> somerville32: correct.  If I remember correctly, it's the next one in the list so I'll get to it on Monday.
<somerville32> Mithrandir: Awesome. :)
* somerville32 hugs Mithrandir 
<mdke> gnome-panel has broken dependencies... anyone know a workaround in order to be able to login?
<mdke> I may have to resort to installing xubuntu at this rate
<somerville32> Weee! :)
<somerville32> mdke: Are you on Feisty?
<tsmithe> resort to xubuntu?! resort!!! it's good!
<mdke> somerville32: sure
<mdke> tsmithe: it involves downloading quite a lot of stuff
<tsmithe> indeed :P
<somerville32> mdke; Not too much
<somerville32> Xubuntu is awesome though ;] 
<mdke> I tried it already, it is quite good actually. Much more reasonable menu layout than Gnome :)
* mdke downloads away
<somerville32> mdke: Also, if you didn't know, they uploaded python 5
* tsmithe has it customised too much...
<somerville32> So everything is rebuilding
<tsmithe> snazzula
<somerville32> tsmithe: I'll donate $10 to your fund
<tsmithe> yay!
<somerville32> How much money have you raised so far?
<tsmithe> little
<tsmithe> go to the page
<mdke> somerville32: still rebuilding?
<tsmithe> somerville32, but i have a couple of projects in the pipeline...
<tsmithe> let's take this out of -devel
<somerville32> Crimsun said it would take a few more business days
<mdke> shit. Is xubuntu working at least?
* somerville32 is afraid to upload and find out.
<somerville32> I have 285 updates pending
<mdke> ok, we'll see when it downloads all this stuff
<mdke> somerville32: xubuntu works like a dream
<mdke> thank god for that
<somerville32> :)
* mdke immediately goes to file a bug
* somerville32 takes some scissors and cuts that out to put on a quote page someday about Xubuntu.
<mdke> well, finding a bug in 10 seconds is pretty impressive, thanks
<somerville32> In Xubuntu, lol?
<mdke> somerville32: yeah. What package defines the names for the sub-menus?
<somerville32> mdke: Whats the bug?
<mdke> there are some confusing names for the menus
<mdke> xfce-panel?
<somerville32> Yeah
<somerville32> I can't seem to find a separate package for xfce4-menu-plugin
<mdke> there is an xfce-panel-menu-plugin
<somerville32> Thats what you want then
<somerville32> And the issue is because it isn't fully freedesktop spec compliant
<mdke> Mithrandir: somerville32 has identified a typo in the release announcement, no idea if you can change it now, but still - (Edubuntu) should be (Xubuntu) in the last item in the list of links
<somerville32> mdke: You can fix the one on the fridge
<somerville32> Oh
<mdke> i have done yeah
<gnomefreak> with version numbers does < mean the same as <<
<doko> Mithrandir: please requeue gnome-panel (should build now with the updated launchpad-integration)
<mdke> yay!
* mdke hugs doko 
<gnomefreak> like depends package (<5.0) is same as depends pacakge (<<5.0)
<crimsun> yes, < is deprecated in favour of <<
<crimsun> likewise with > and >>
<gnomefreak> ah ok cool
<Mithrandir> gnomefreak: no, < 5.0 is the same as <= 5.0
<gnomefreak> well maybe ill get lucky and smart will be synced and upgraded by wednesday and i would have to figure out how to build it
<Mithrandir> gnomefreak: smart was synced yesterday
<gnomefreak> cool
<Mithrandir> ftbfs, tho
<gnomefreak> thats bad
<gnomefreak> maybe due to the python breakge?
<Mithrandir> not really
<crimsun> gnomefreak: sorry, misparse (http://www.debian.org/doc/debian-policy/ch-relationships.html )
<gnomefreak> ty
<Mithrandir> I think we should make dpkg-dev fail to build packages with < and > dependencies.
<incon> gnome-menus: Breaks: gnome-panel (<= 2.16.2-0ubuntu3) but 2.16.2-0ubuntu3 is to be installed
<incon>   ubuntu-desktop: Depends: openoffice.org but it is not going to be installed
<incon> E: Broken packages
<incon> known issue ?
<Hobbsee> incon: please check for a bug.  if it's nto there, please file one.
<incon> read the helpingwithbugs wiki ?
<gnomefreak> its fixed just waiting for it
<Amaranth> I've been telling people to wait until Tuesday before filing a bug on that one
<mdke> I think the general rule with broken dependencies is that the developers check them via the automatically generated page, so you don't need to file bugs
<Hobbsee> mdke: sometimes ;P
<mdke> but whinging about it in here is permitted, AFAIK
<incon> Any tips/wiki on using launchpad search ?
<incon> example search "gnome-menus: Breaks: gnome-panel" brings up nothing
<roxlu> hi all
* Hobbsee aves
<Hobbsee> *waves
<roxlu> I was wondering about why some things haven't been implemented in ubuntu....
<roxlu> 1) I've installed a dualview, but it took me 2 - 3 hours read up about how all this works... Why ain't there a central database for xorg.conf config settings per monitor? Would be quite handy
<Amaranth> roxlu: feisty+1 will have display hotplug
<concept10> Why is Python popular for developing apps in Linux, and Ubuntu in particular?
<Hobbsee> ...because of the libraries it has for it...
<poningru> and it is very easy to dev in python
<poningru> you can go from begginer to intermediate in about a month
<Amaranth> still takes years to get to expert :)
<concept10> Thanks guys.  I have been looking at the source for a fairly new music app, and since I dabble in Ruby, Python doesnt look that difficult
<concept10> this project should really replace Rhythmbox, imho
<concept10> I cannot remember, is Rhythmbox a python app?
<evand> concept10, no, it's C
<Hobbsee> concept10: you could have checked it's dependancies for that :P
<incon> concept10, you should look into http://www.exaile.org/
<concept10> incon, thats the project im talking about
<concept10> its great
<incon> concept10, python based so you can hack in it
<incon> in = on
<concept10> incon, yeah, ive had the app for a couple of hours and already managed to add some stuff to it and I don't know one bit of python
<doko> Mithrandir: last one for the weekend: please requeue openoffice.org on all archs (updated java-gcj-compat is now in the archive)
<doko> ohh, python-omniorb2 may be requeued as well
<persia> mdz: A discussion of the correct implementation of the DebianMaintainerField spec came up on #ubuntu-motu, and I was referred to you for an authoritative answer.  The specific question is what value should be in debian/control to provide the desired behaviour.  Should it be "XBS-Original-Maintainer", which results in "Original-Maintainer" in the .dsc and .deb files (although control differs from .dsc and .deb), should it be "
<evand> persia, that got cut off at the end of ".deb), should it be"
<persia> Buffers :(  breaking up:
<persia> The specific question is what value should be in debian/control to provide the desired behaviour.
<persia> Should it be "XBS-Original-Maintainer", which results in "Original-Maintainer" in the .dsc and .deb files (although control differs from .dsc and .deb),
<persia> should it be "Original-Maintainer" which requires patches to dpkg to properly process this field,
<persia> or should it be "X-Original-Maintainer", which causes no dpkg-deb warning, but also does not appear in .dsc or .deb files?
<Lure> doko: do you plan to upgrade python-dbus to 0.80 version (currently rc3)? It seems to implements proper hooks for qt loop...
<doko> Lure: upgrade the package, put the package somewhere for review, file a bug report and add me to the subscribers
<Lure> doko: ok, I will test first to confirm we can use it and it really give us some benefits for kde-guidance
<pitti> marcheu: hi!
<fbenites> hi!
<fbenites> does someone use uml: user-mode-linux?
<Mithrandir> doko: ooo and python-omniorb2 given-back.
<pitti> hi Mithrandir 
<Mithrandir> hiya Martin
<Adri2000> Mithrandir: there is a SRU for obconf you may want to approve today... :) if not I'll wait until monday
<Adri2000> (in -proposed)
<Mithrandir> Adri2000: doing trivial give-backs in the weekend is fine, but I try not to work too much outside work hours, so I'll look at it on Monday or so.
<Adri2000> ok
<geser> Mithrandir: could you please give-back score-reading-trainer on all arches except sparc? thanks
<mdke> heh, poor Mithrandir 
<Mithrandir> geser: given-back.
<Mithrandir> mdke: nah, it's fine, it takes me ten or so minutes per weekend total and is useful to keep the engine ticking, so I don't mind.
<mdke> :)
<doko> Mithrandir: hmm, are you able to remove python2.4-minimal from the buildd chroots? looks like it is still installed there
<doko> by default
<Mithrandir> doko: no, it requires a dist-upgrade/rebuild afaik.  I can ask Adam for it.
<doko> Mithrandir: ok, I'll add a workaround then, OOo still ftbfs, I think that is the reason
<Mithrandir> doko: ok.  I'll ask for an upgrade.
<tsmithe> bug 2461
<Ubugtu> Malone bug 2461 in xdm "xdm package is missing libXdmGreet.so" [Medium,Fix released]  https://launchpad.net/bugs/2461
<tsmithe> wrong place...
<synic> I've been watching this: https://launchpad.net/ubuntu/feisty/+queue.  If the package "exaile" has dissappeared from this list, does that mean it has been approved to be in Fiesty?
<dsas> synic: Possibly, or there's been error
<dsas> synic: see https://launchpad.net/ubuntu/+source/exaile
#ubuntu-devel 2007-01-14
<dsas> Riddell: Could you tell me how many people are subscribed to the ubuntu-uk list? We're trying to think of ways to increase the number of active particpants, so the number may be useful...or let me know of another list admin I can bug :)
<Riddell> dsas: 341
<dsas> Riddell: Wow. Didn't realise it was that high. Thanks a lot! :)
<bobesponja> hey all
<bobesponja> I just did an update on edgy, and now my ipod is only mounted as read-only
<bobesponja> not even as root
<bobesponja> and I'm not the only one
<dsas> bobesponja: Has there been a bug report filed?
<bobesponja> dsas: no idea
<dsas> bobesponja: Any idea what packages have been updated? Was it an update released today? do you have the edgy-proposed repository enabled?
<bobesponja> dsas: I have a clean install, didn't add any other repository
<somerville32> Hobbsee, ping
<Hobbsee> somerville32: pong
<Hobbsee> somerville32: contentless ping warning
<somerville32> Hobbsee, Can you take a look at this? https://bugs.launchpad.net/ubuntu/+bug/78841
<Ubugtu> Malone bug 78841 in Ubuntu "System crashes if disconnected from network" [Undecided,Unconfirmed]  
<somerville32> And do you know anyone who is good with IPT crack? :)
<Hobbsee> somerville32: right.  looked.  and?
<Hobbsee> no
<Hobbsee> somerville32: could be a kernel thing - that's where i'd guess
<somerville32> Try - I'm rather disturbed by it. :(
<somerville32> s/Try/Yeah
* somerville32 can't type today.
<TuxCrafter> Hi guy's
<TuxCrafter> I have been testing feisty
<TuxCrafter> and I have some small comments: first good job it installed ok under vmware and did beheave as aspected (unlike the 3 other distro's i have tested this week (zenwalk, dreamlinux, debian stable, debian unstable)
<TuxCrafter> issue 1: The menu element create folder has a to big icon image
<TuxCrafter> not the one predicted by the gnome standard
<TuxCrafter> i believe that was 16x16
<Mithrandir> TuxCrafter: please file bugs in the bug tracker.
<TuxCrafter> I dont now if it is a bug
<Mithrandir> then ask about it in the question tracker?
<TuxCrafter> It could be a new usability feature 
<TuxCrafter> I have one more thing :-D
<Treenaks> TuxCrafter: just file it as a bug. if it's not a bug, it'll get closed...
<TuxCrafter> If there is a new feature introduced like the new GNOME Control Center. Don't remove the old way of the settings menu
<TuxCrafter> just some small comments, keep up the good work! 
<mdke> that's the best change so far this release, the old menu was hideous
<TuxCrafter> You can have it both 
<TuxCrafter> and just call it Control Center instead of GNOME Control Center
<mdke> I filed a bug about that yesterday
<mdke> feel free to confirm it
<mdke> but no, you can't have both, it would be too confusing
<mdke> bug 79164
<Ubugtu> Malone bug 79164 in control-center "More user-friendly menu entry" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79164
<TuxCrafter> If you want to change the screen resolution for example, now you have to press a lot more mouse clicks to get there
<TuxCrafter> I don't say it is bad hell no
<TuxCrafter> but you could just put the old menu beneath it
<mdke> there is probably a gconf key or something to use the old style. both at once would be really confusing, imo. And having a coherent preferences dialogue is one of the biggest steps ahead Gnome has made in this release cycle, I think
<TuxCrafter> Ok, i can see the points
<TuxCrafter> I will comfirm the name bug
<Amaranth> there is no gconf key
<Amaranth> the settings.menu file isn't even shipped by gnome-menus anymore
<mdke> ah
<mdke> Amaranth: do you know if the category list is ours, or upstreams? It would be nice to get rid of the "Other" category
<Amaranth> TuxCrafter: can you explain "<TuxCrafter> issue 1: The menu element create folder has a to big icon image"?
<Amaranth> mdke: it's based on the categories set in the .desktop files
<TuxCrafter> The Main menu editor should indeed be under Look and Feels
<Amaranth> mdke: alacarte, for example, has DesktopSettings in it's categories in gnome svn so it doesn't go into "Other" anymore
<mdke> where does it go?
<Amaranth> i think Look & Feel
* mdke nods approvingly
<mdke> we need to do something like that for all of the "Other" chaps
<Amaranth> yeah, DesktopSettings makes the icon go in Look & Feel
<Amaranth> and the categories are defined upstream
<mdke> ok. Does that mean it's a bit late to do anything about them?
<Amaranth> oh, settings.menu is shipped in gnome-menus, dang
* Amaranth got confused about that when vuntz explained it
<Amaranth> oh, settings.menu just has the control center in it now
<Amaranth> mdke: you can define the categories by modifying /etc/xdg/menus/preferences.menu
<mdke> I'll suggest that mpt has a hack at those categories, maybe he can come up with something
<Amaranth> i think just getting Other items sorted properly will fix it all
<TuxCrafter> question: does ubuntu have a new policy about the kernel versions used? It now says 2.6.20-5-generic
<mdke> yes, and maybe "System" :)
<Amaranth> although things like Network Tools should be in Network and Internet
<TuxCrafter> www.kernel.org
<TuxCrafter> Ubuntu made a big jump then form kernel
<TuxCrafter> is this correct?
<Amaranth> TuxCrafter: I don't understand what you're saying
<TuxCrafter> uname -r
<Amaranth> what about it?
<mdke> jump? we've got the latest one
<TuxCrafter> nice, in the past ubuntu never used the latest one but always a few steps behind. therefor the question about the new kernel policy ?
<Amaranth> TuxCrafter: In the past whatever kernel was the latest when development started was used
<mdke> we stop updating programs at a certain point in the release cycle, any later releases don't get updated
<TuxCrafter> weird I believe the version of edgy was tree version behind
<TuxCrafter> but I like it!
<Amaranth> edgy was 2 versions behind
<Amaranth> edgy has 2.6.17, 2.6.19 came out right around when edgy was released
<Seveas> later
<TuxCrafter> with this kernel It will at-leased boot. I have a via epia en12000 and the edgy kernel does not work
<Seveas> and feisty will have .20 because of paravirt-ops and other nicenesses
<Amaranth> kvm + paravirt would be nice
<Amaranth> but that's 2.6.21 stuff
<stdin> kvm is in 2.6.20
<Mithrandir> Amaranth: BenC is talking about backporting some of the 2.6.21 bits.
<Amaranth> cool
<Amaranth> stdin: this stuff still exists in patch form
<TuxCrafter> my system froze
<TuxCrafter> did i miss some response?
<Amaranth> stdin: it's an addon to kvm to do paravirtualization (sort of like Xen) using some of the Intel VT extensions to do the work
<stdin> ahh, nice :)
<Amaranth> I/O is like 5000% faster than regular virtualization with kvm
<stdin> I'm having a small problem with 2.6.20, well, not so much a problem, as an annoyance 
<stdin> my /dev/hda is now /dev/sda 
<Mithrandir> that's intentional
<TuxCrafter> guestion: how do i debug total system freezes
<TuxCrafter> can I see any logs?
<mdke> yay, ubuntu-desktop is working again
<Amaranth> mdke: that was a quick transition
<TuxCrafter> or is there a tool that i can test irq test with
<stdin> Mithrandir: can you tell my why, or point me to a link explaining? :)
<Mithrandir> stdin: https://blueprints.launchpad.net/ubuntu/+spec/libata-for-all-ata-disks
<stdin> thanks :)
<TuxCrafter> were should I post a bug for feisty
<TuxCrafter> https://bugs.launchpad.net/ubuntu ?
<mdke> yes
<doko> Mithrandir: ctypes should not be built for 2.5, it's included in the standard library
<Mithrandir> doko: bah, ok, sorry.  Something or another here depended on it and it wasn't upgraded properly.
<doko> Mithrandir: I'll look at it tomorrow
<Mithrandir> doko: and your xen upload seems to have exposed some bug in soyuz; it has never had builds scheduled.
<Mithrandir> doko: please file a removal request too.
<doko> Mithrandir:  for xen-3.0?
<TuxCrafter> https://bugs.launchpad.net/ubuntu/+bug/79200
<Ubugtu> Malone bug 79200 in Ubuntu "new folder menu icon item is too big not following the gnome specs" [Undecided,Unconfirmed]  
<TuxCrafter> this ok\?
<TuxCrafter> Ubugtu: you are fast :-D
<Mithrandir> doko: yeah
<TuxCrafter> I have to go now, thanks for the help and the info bye
<fabbione> Mithrandir, cjwatson: you want to look at #79107 and #79109. I still need to confirm them tho
<megatill> hi
<megatill> hab keinen zugriff die festplatte bzw. kann sie nicht aktivieren udn kein ubuntu installieren, kann mir jemand sagen was ich machen kann?
<ivoks> you can try in english on #ubuntu
<bhale> or #ubuntu-de
<ivoks> or german in #ubuntu-de
<Enola_Gay> hi all
<Enola_Gay> The kernel frequency governors have a huge bug in all kernel versions. They only put frequency to maximum on user cpu usage not on system. If you transfer something to usb you have 100% cpu usage but the cpu has still the lowest frequency. Could please someone fix this. I don't understand why now other one has made a bug report or has fixed it.#
<mdke> Enola_Gay: please make a bug report yourself if someone hasn't already
<Enola_Gay> mdke: Ok, but I think it will be ignored.
<Treenaks> Enola_Gay: what makes you think that?
<mdke> Enola_Gay: you're more likely to be ignored posting off topic here on a Sunday
<Enola_Gay> Treenaks: Experience ;)
<mdke> for bugs, you must use the bug tracker
<Enola_Gay> mdke: Bugs of Ubuntu are offtopic?
<Treenaks> Enola_Gay: no. but reporting bugs is
<Enola_Gay> Ok, it seems to be a general kernel bug.
<Ng_> Enola_Gay: in that case registering it upstream may be an idea too
<Enola_Gay> I am going to report it.
<Enola_Gay> I think there have to be a reason for it because it happens since I am useing cpu scaling on linux.
<Enola_Gay> I just wanted to know the reason :)
<Treenaks> Enola_Gay: file the bug already
<Enola_Gay> Treenaks: https://launchpad.net/ubuntu/+source/linux-meta/+bug/79232
<Ubugtu> Malone bug 79232 in linux-meta "kernel does not scale cpu on system usage (only on user)" [Undecided,Unconfirmed]  
<doko> Mithrandir: please requeue libhdate, opencv, hocr (should build with the updated swig)
<Megatill> german channel? ubuntu-de?
<Mithrandir> doko: given-back
* Treenaks pokes some bugs
<Lathiat> 
<enrico> apparently yesterday's edgy update broke nautilus and logging in just have a bug reporting tool opening and getting stuck on 'collecting info from the system'
<enrico> however the computer is some tousands km away from me and I can't ssh into it, so I can't give more insight
<mdke> enrico: you should contact the technical board and sfllaw about something like that
<bhale> you shouldnt contact the technical board with conjecture about a bug and no details
<bhale> if you can gather some and get a detailed bug report filed, it is worth poking sfllaw 
<mdke> well, sounded like a serious regression to me, obviously if it's "conjecture", then no
<Lure> doko: pykdeextensions as in archive does not buld anymore - I would like to get it and python-kde3 in resonable state so that we can fix kde-guidance for python 2.5
<doko> Lure: sure, fix it ;)
<Lure> doko: not sure if in my power ;-) first time hacking there... ;-)
<sfllaw> enrico: Ping?
<sfllaw> enrico: Was this from edgy-updates or edgy-proposed?
<sfllaw> enrico: Also, when was the lsat time you did an update?
<enrico> sfllaw: update yesterday, only from edgy updates
<enrico> sfllaw: but that is my conjecture: ignore me if you don't see screams from other people as well
<enrico> sfllaw: I'll have no access to that machine for another 12 days anyway
<BenC> Mithrandir, Aramanth: I have a kvm + paravirt host/guest running on a Core2Duo right now
<BenC> I think kvm+paravirt will be in stock kernels on the next upload
<Amaranth> BenC: ooh
<Amaranth> BenC: have my babies
<BenC> stock-ubuntu I mean
<Amaranth> BenC: sound a lot louder now? :)
<BenC> If Xen's domU code (xen core + paravirt) wasn't so damn huge, I'd include that too
<BenC> but it's like 480k patch
<Amaranth> heh
<BenC> Amaranth: sound is great right now
<Amaranth> awesome
<BenC> Only problem with kvm right now is that it doesn't support real-mode 32-bit
<BenC> so booting the livecd is broken because the bootsplash is real-mode 32-bit
<Amaranth> yeah, can't boot ubuntu isos on it
<BenC> you have to boot the alternate CD
<BenC> alternate and server works
<Amaranth> alternative bombed on me too last time i tried
<Amaranth> i ended up installing etch to test it out
<BenC> hmm, maybe it's because I used dapper alternate...I thought that edgy would be the same
<Amaranth> i used dapper too
<BenC> I've downloaded the Intel VT docs, and got some tips from kvm-devel, so I'm going to work on real-mode 32-bit in my spare (HAHAHA) time
<kylem> you're nuts, chief :)
<bSON> hi
<BenC> kylem: I've never been accused of sanity :)
<kylem> BenC, have you been able to test it with svm?
<BenC> Hmm...I wonder if my AMD64 chips has that
<BenC> do you remember the svm cpu flag?
<BenC> is it svd?
<Amaranth> BenC: i think it has to be am2
<Amaranth> or whatever that new socket is
<BenC> Ok
<zul> BenC: im officially the sane one now
<BenC> zul: You work on xen, you lost all claims to sanity a long time ago
<Amaranth> doesn't xen actually sit under the host linux?
<kylem> BenC, i think it's "svm" :P
<kylem>                 /* AMD-defined (#2) */
<kylem>                 "lahf_lm", "cmp_legacy", "svm", NULL, "cr8legacy", NULL, NULL, NULL,
<BenC> Nope, my amd64 is crap :)
<kylem> same here.
<kylem> i need to upgrade my windows box soon anyway.
<BenC> Odd thing is, I had to upgrade my BIOS on the Supermicro Xeon box so kvm-intel would work
<BenC> the BIOS reported the VT was enabled, but it didn't really set the enable bit
<kylem> cute.
<BenC> those whacky BIOS writers
<BenC> I know they did it just for me, because I'd get the joke
<maswan> BenC: over the last 3 clusters we've bought, all have had that behaviour wrt ECC
<BenC> maswan: I my need a reminder to context that correctly :)
<maswan> BenC: reporting it to be enabled when you switch it on, but in reality it is still turned off
<BenC> ah, ok
<BenC> wow, I need more coffee
<BenC> I just used "apt-get install acpi_cpufreq" when I mean "modprobe acpi_cpufreq"
<kylem> lol.
<BenC> apt was terribly uncooperative with that request
<BenC> DWIM damnit!
<Mithrandir> BenC: just make a "do" package. :-P
<BenC> I'll be like the guy on wedding crashers
<BenC> "do it!"
<kylem> lol.
<bhale> does kvm do something useful w/o xen or vmware on top?
<BenC> bhale: kvm is meant to be an alternative to xen/vmware
<bhale> BenC: oh, i must have it mixed up with the shared paravirt code
<BenC> bhale: Yeah, paravirt is just an API, but so far vmware, kvm and xen offer paravirt ops for linux guests
<giskard> kvm needs new processor with VT supports
<giskard> xen can work with VT but it's not necessary. (vmware afaik doesn't support VT)
<ivoks> giskard: kvm can work without VT too
<ivoks> slow, true, but it can
<Treenaks> why did I parse that as 'without a vt'
<ivoks> Treenaks: ?
<Treenaks> ivoks: virtual terminal.. Alt+F1 etc.
<ivoks> :)
<ivoks> i don't understand why people claim that xen works without VT, and KVM doesn't
<ivoks> truth is oposite
<ivoks> kvm can run unmodified OS without VT enabled processor (very slow, but it can)
<ivoks> while Xen can't run unmodified OS without VT processor
<bluefoxicy> atheros :(
<bluefoxicy> if I load any atheros drivers at all, my system decides it's time to shit itself.
<bluefoxicy> oopses everywhere, X stops working, etc.
<bluefoxicy> in 2.6.20-[45] -{generic,lowlatency}
<bluefoxicy> Can I submit just one giant bug report with all the oopses gathered, or do I have to figure out which are which and split them up?
<ivoks> i think this is a known issue
<bluefoxicy> someone needs to teach gnome's syslog viewer to group lines like oopses and bug()s so I can just say "give me XXX" and cherry-pick (make all our lives easier)  :D
<ivoks> we use vi
<ivoks> :] 
<bluefoxicy> ivoks:  is there actually a way to switch which sound card is being used for playback :|
<ivoks> i don't think there is a gui for that :/
<bluefoxicy> can I spend a hint coin and get a command :|  I'm considering offing my SB Audigy for on-board realtek sound but right now I'm thinking the onboard sounds like trash :|
<ivoks> i think that should be done in /etc/asoundrc
<ivoks> but i never even think about that (i have only one card - onboard)
<bluefoxicy> heh
<simira> is it any more official information about the distro sprint coming up?
<giskard> ivoks, because of Intel-based hosts (requires VT capable processors)
<giskard> taken from kvm.sf.net
<ivoks> well, yes, for faster work you need kvm kernel module which requiers VT enabled proc
<ivoks> but you can use qemu aka kvm userland tool wihtout kvm module
<delire> is the fastest means to get my software into the Ubuntu repos to first begin maintaining it for Debian Unstable?
<bhale> that is probably slower, but ideal.
<delire> bhale: right
<delire> bhale: there are perhaps three packages i'm considering maintaining.
<lakin> I'm looking into this bug, https://launchpad.net/ubuntu/+source/usplash-theme-ubuntu/+bug/67545 ,  but I could benefit from knowing which package is responsible for telling usplash the desired resolution? (I think this is stored in /etc/usplash.conf)
<Ubugtu> Malone bug 67545 in usplash "usplash appears black and white (grayscale) on amd64" [Low,Confirmed]  
<Mithrandir> lakin: don't bother, it's mostly fixed and has a very non-obvious solution.
<lakin> Mithrandir: ok ... are there packages I can test for it, or is it not yet fixed?
<lakin> errr. not fully finished.
<Mithrandir> lakin: grab usplash bzr, make it use libx86 instead of the embedded one and make amd64 as well as i386 use svgalib.
<lakin> Mithrandir: thanks
<Lure> doko: python-kde3 needs another small patch to get built with python 2.5: bug 79191
<Ubugtu> Malone bug 79191 in python-kde3 "no python2.5 modules" [Undecided,In progress]  https://launchpad.net/bugs/79191
<bluefoxicy> ffs.
<bluefoxicy> Does it count as "a bug that causes data loss" if, say, accidentally double-clicking Deskbar or trying to click the arrow (history of commands) to close the command history list activates the "Shutdown the system" event from the recent actions list, causing everything to hard-close instantly?
<bluefoxicy> without asking?
<bluefoxicy> (firefox even came back up and said it crashed when I rebooted)
<Seveas> bluefoxicy, no, it counts as user silliness ;)
<bluefoxicy> hey I didn't expect it to happen :(
<bluefoxicy> although I think it's significant that shutdown seems to hard-kill (SIGKILL) everything under Gnome (you get an INSTANT log-out, without a confirmation dialog)
<Seveas> hopefully upstarts shutdown will grow ways of preventing that, just like gnome-power-manager can be inhibited from hibernating or responding to powerbutton presses
<bluefoxicy> can't someone just fix deskbar's list of system actions :/
<bluefoxicy> it's a GNOME applet, it should know how to properly ask GNOME to quit rather than telling init to reboot and letting /etc/init.d/gdm stop do it; at the very least it should also have an option to confirm any system actions like "logoff" or "reboot"  x_o
* bluefoxicy is going to file a bug on SOMETHING here.. he just isn't sure what
<bhale> im not seeing how you even manageed this debacle
<Treenaks> deskbar, for being silly about Gnome actions
<bhale> execute 'shutdown' doesnt work as a user
<delire> bluefoxicy: yes i think that is a design bug.
<Nafallo> bhale: deskbar-applet has "system actions". among them shutdown.
<bluefoxicy> bhale:  in deskbar, set its options to include "computer actions" and "history"; then type "shutdown" and pick "Shutdown the machine" (this will kill everything immediately)
<bhale> well then its not enabled by default
<bluefoxicy> bhale:  later, click the drop-down arrow (top option is now "Shutdown the machine"), then try to click it again and it'll... instantly kill your entire gnome session, run the shutdown sequence, and turn the machine off.
<bhale> no
<bhale> its not
<bhale> why dont you turn it off
<bluefoxicy> yeah, I did now.  (the entry is still in the history menu)
<delire> oh, so it's not enabled by default?
<bhale> no, its not
* delire coughs
<bhale> and neither is deskbar
<bluefoxicy> argh.
* bluefoxicy disables alt+q too
<bluefoxicy> bhale: it's not enabled by default; it's still part of Main and it still acts immature.
<bhale> you clicked "shutdown"
* bhale sighs, goes elsewhere
<bluefoxicy> by accident :(
<bluefoxicy> there, I've filed TWO bugs.
* mdke pats bluefoxicy 
<Keybuk> mmm, bugs
* bluefoxicy patted
* bluefoxicy goes through Malone and begins assigning all bugs to Keybuk :D
<bluefoxicy> Since you like them so much :D
<Keybuk> bluefoxicy: I'll just delegate them to my staff <g>
<bluefoxicy> you have a staff?
<bluefoxicy> I'm jealous.  I just got a TSR job.
#ubuntu-devel 2008-01-07
<TheMuso> c
<TheMuso> ugh wrong tab
<lamont> slangasek: you want that new util-linux for the next alpah?
<lamont> alpha, even
<lamont> slangasek: so... do I grab the new pofiles and make it util-linux_2.13.1~rc2-1, or do I leave them out and make it 2.13-15?
<lamont> er, s/$/ubuntu1/, of course.
 * lamont decides to fess-up in debian/changelog
<Chipzz> IceKiller: I would strongly recommend *against* shipping version 2.2.0 of the intel driver; it has some serious issues
<Chipzz> IceKiller: default acceleration architecture was changed (to EXA iirc) which is causing lots of troubles
<Chipzz> I would suggest reading up on the xorg mailing list
<chirva> hey there... i have a stupid question i don't know where to ask... how do i list a directory in C?
<Fujitsu> chirva: This isn't a support channel.
<Chipzz> chirva: not the right place; but try man glob
<chirva> thanks
<Chipzz> also, scandir apparently
<Chipzz> chirva: may I suggest google? the exact terms (C list directory) you used to ask your question turned up a valid result in the first 10 results...
<Chipzz> also, opendir/readdir/closedir (first hit on google...)
<Chipzz> IceKiller: http://lists.freedesktop.org/archives/xorg/2007-December/031244.html ; http://lists.freedesktop.org/archives/xorg/2007-December/031128.html
<TheMuso> c
<TheMuso> ugh wrong tab
<Chipzz> TheMuso: again ;)
<chirva> didn't try (C list directory)... indeed... the first result seemed good. I eventually found the libc docs on gnu.org
<chirva> thanks anyway
<Chipzz> yw :)
<slangasek> lamont: totally indifferent for the alpha, I was just reminded by the discussion about Essential packages that I hadn't filed that bug yet
<lamont> heh. ok
<lamont> anyway, 2.13.1~rc2-1ubuntu1 just uploaded
<lamont> hrm... that reminds me... if I want to sync the latest version of a package from sid, to a component where I have upload privs, there should just be a &*%_)V button
<lamont> especially when _I_ just signed the changes file in debian.
<lifeless> Agreed
<Fujitsu> lamont: But it's LP, what do you expect? Though there is a spec for doing that, IIRC...
<StevenK> lamont: Make puppy dog eyes at slangasek? :-)
<ScottK2> lamont: Look in pitti's directory on people.ubuntu.com.  There's a script for that.
 * Fujitsu chastises ScottK2.
<ScottK2> The script is publically available and findable via Google.  Using it can't be too horribly wrong.
<lamont> ScottK: there's a script for requesting the sync...
<Fujitsu> Soyuz specs seem very bouncy at the moment. I'm sure private-ppas was targetted at 1.2.5 last week..
<lamont> there was a time when we just did build1 uploads... but then they fixed the syncer
 * lamont only uses his superpowers for good, you see.
<Fujitsu> lamont: https://blueprints.edge.launchpad.net/soyuz/+spec/sync-workflows
<StevenK> Fujitsu: private-ppa is targetted at 1.2.1
<Fujitsu> StevenK: That was my point.
<Fujitsu> StevenK: It got promoted by 4 months.
<Fujitsu> And it was 1.2.2 or so before it went to 1.2.5.
<StevenK> Fujitsu: Ah, I see your point.
<ScottK2> lamont: There's also a script for mangling your locally generated .changes file to look just like the upload was synced.
<ScottK2> Which I would never ever use unless pitti told me it was OK.
<lamont> ScottK: except that the resultant changes file is signed by you, instead of the autosyncer
<ScottK2> True.
<lamont> and manually munging changes files is bad.
<ScottK2> Which is why there's a script.
<lamont> and I almost never do it much
<lamont> I'll let my packages age at least until the dinstall run tomorrow, and request the syncs tomorrow night after work
<lamont> speaking of which, bed time,  I think
<Fujitsu> Night lamont.
<ScottK2> Good night lamont
 * lamont is switching to virtual -0400 - makes things work better.
<ScottK2> Fujitsu: Have you had a chance to look into perl-modules any more?
<Fujitsu> ScottK2: Ergh, forgot about that, sorry. Was working.
<ScottK2> No problem.  I'm heading to bed.
<ScottK2> See you all tomorrow
<Fujitsu> Night.
<nxvl> i need a given-back for bioperl
<dmb> would there be a reason a package wouldn't be built and uploaded to the repositories after being uploaded?
<dmb> http://archive.ubuntu.com/ubuntu/pool/universe/i/inspircd/ its been like that for a while, does it just take a while, or is there something wrong?
<StevenK> If it's in source NEW
<dmb> StevenK: is was synced from debian manually
<StevenK> Ah, the source is there.
<StevenK> It's in binary NEW.
<dmb> StevenK: is there a place to check that statuses of that stuff?
<dmb> like in debian?
<StevenK> dmb: https://launchpad.net/ubuntu/+source/inspircd/1.1.15+dfsg-1
<dmb> oh
<Sefram> is it possible to install ubuntu without the cd's installer?
<dmb> Sefram: you can manually debootstrap?
<Sefram> dmb: i dont know howto do that, i ask because i always end up in initrd's ash and dont know how to continue from there...
<dmb> Sefram: i think these questions are for #ubuntu
<Sefram> hmm in #ubuntu is noone answering, but thx anyways...
<dmb> am i the only one who finds debootstrap to be an amazing thing?
<pitti> Good mornin
<pitti> g
<StevenK> Morning pitti
<StevenK> pitti: A few stupid questions, if I may? :-)
<pitti> StevenK: sure
<StevenK> pitti: I've uploaded a few repacks to satisify your issues. The tasks are currently set to Incomplete, what should I set them to?
<pitti> StevenK: just set them back to NEW, I think
<dholbach> good morning
<StevenK> pitti: I suspect this will also let cheese into main, shall I leave it at Triaged?
<pitti> StevenK: yes, that's fine
<StevenK> pitti: Cool. Bug commented on, and tasks twiddled.
<StevenK> pitti: Could I prod you to process bug 180905?
<ubotu> Launchpad bug 180905 in webkit "Please sync webkit (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/180905
<pitti> StevenK: synced
<StevenK> pitti: Thanks!
<pitti> np
<StevenK> Yay for NBS work.
 * pitti yays StevenK for NBS
<StevenK> The only thing that pulls in libicu36 is OO.o
<StevenK> And I'm not touching that. :-)
<StevenK> pitti: Could you glance at moko in source NEW? Does it have a hope of reaching the archive.
 * StevenK wonders if pitti has reached the conclusion that he was lying in wait for him.
<pitti> sth. like that :)
<pitti> StevenK: what's the problem with moko?
<StevenK> pitti: I uploaded it today, and I'd like a second pair of eyes on it.
<pitti> ah, ok
 * StevenK tries to brutalise gnome-games on lpia.
<StevenK> May seb128 forgive me
<pitti> StevenK: moko's package description could be a bit more verbose (what is moko, etc.)
<pitti> StevenK: out of curiosity, what is 'gaston'?
<StevenK> pitti: gaston is Moblin's release name.
<pitti> ah
<StevenK> pitti: Is the description grounds for being rejected?
<pitti> StevenK: no, it's not a reject reason
<pitti> just mentioning it
<StevenK> I'll look at writing a better one.
<pitti> StevenK: moko looks fine to me, accepted
<StevenK> Yay!
 * StevenK hugs pitti 
<StevenK> pitti: I've added a note about the description to my todo list, I'll fix it soonish
<StevenK> Awww. gnome-games blows up.
<StevenK> sol-window.o: In function `aisleriot_window_init':
<StevenK> /build/steven/gnome-games-2.21.4/aisleriot/window.c:2336: undefined reference to `launchpad_integration_set_sourcepackagename'
<StevenK> /build/steven/gnome-games-2.21.4/aisleriot/window.c:2337: undefined reference to `launchpad_integration_add_ui'
<dholbach> pitti: what do you think about bug 111791?
<ubotu> Launchpad bug 111791 in langpack-locales "Wrong mon_decimal_point for locales/pt_PT" [Medium,Confirmed] https://launchpad.net/bugs/111791
<StevenK> pitti: Could you be convinced to let inspircd out of binary NEW?
<dholbach> hey lloydinho_ :)
<lloydinho_> good morning, dholbach :-)
<dholbach> pitti (or some other archive admin): can you please sync gnome-specimen? (no ubuntu changes, new upstream version in debian)
<pitti> StevenK: NEWed
<pitti> dholbach: sounds sensible
<pitti> dholbach: synced
<seb128> hey pitti
<pitti> Monsieur Bacher! *hug*
<StevenK> pitti: Thanks
 * seb128 hugs pitti
 * StevenK waits to see if he has brutalised gnome-games enough
<seb128> StevenK: what about it?
<StevenK> seb128: Trying to get it to build the hildonised aisleriot on lpia
<seb128> ah ok
<StevenK> seb128: I'll clear the patch with you first.
<StevenK> Just trying to get it to build.
<seb128> ok
 * Fujitsu verberises StevenK.
<seb128> the upstream hildon code is buggy?
<StevenK> Nah, it's more updating the 01_lpi and 99_reautoconf patches to also add launchpad-integration to the platform hildon bits, and a few lines in debian/rules.
<StevenK> Fujitsu: Quiet you
<seb128> ok
<StevenK> Way cool. scrollkeeper is in the Build-Depends, but ./configure is run with --disable-scrollkeeper
<StevenK> seb128: ^ :-)
<seb128> StevenK: either the Build-Depends is not required or the configure is buggy and look for it anyway
<kmap_lab> Ubuntu devels, I was just wondering how to request an automagic sync of my Debian package in Lenny to Hardy...
<StevenK> seb128: I don't think the Build-Depends is required.
<seb128> StevenK: ok
<kmap_lab> It should have happened already, but didn't happen this time. I did read up, but am a bit new... so help is appreciated. The source package is libitpp on Debian Lenny
<StevenK> seb128: Based on my reading of the build log, it installs scrollkeeper, and then it isn't mentioned.
<kmap_lab> StevenK: Hey! You touched libitpp last on Hardy. Could you please help?
<StevenK> kmap_lab: Hum?
<kmap_lab> StevenK: Please look at the changelog for libitpp on Hardy. That's you in the last entry, right?
<StevenK> seb128: I can get it to build, but dh_install fails. I daresay because the only game that is hildonised is ailseriot
<StevenK> kmap_lab: What about it?
<kmap_lab> StevenK: I was requesting an update to the new version in Lenny. Is that possible?
<kmap_lab> StevenK: I mean Lenny version -> bring it to Hardy
<StevenK> kmap_lab: Can you justify why the update is needed?
<kmap_lab> StevenK: Er, actually, it's not for me. But upstream just wanted to know if the version in Debian can appear in Ubuntu as well due to changes and feature additions.
<seb128> there is wiki page about sync requests
<kmap_lab> seb128: Ah, I see.
<StevenK> seb128: Can I get you to look at what I've done, and tell me if I'm on crack, or if there's a better way?
<seb128> StevenK: sure, but not right now, I'm just back from holidays and trying to catch up with lot of things
<kmap_lab> seb128: There's LP135942, but it doesn't seem to be happening...
<kmap_lab> seb128: Oops. LP135492
<Chipzz> kmap_lab: launchpad #135492
<ubotu> Launchpad bug 135492 in libitpp "Update to latest version in Ubuntu" [Wishlist,Fix released] https://launchpad.net/bugs/135492
<kmap_lab> Chipzz: I am aware, but it isn't happening. Should I wait for more time?
<Chipzz> kmap_lab: if you mention bugs that way ubotu will give a short summary ;)
<kmap_lab> Chipzz: Oh, I see. Thanks! :-)
<kmap_lab> launchpad #135492
<kmap_lab> Er, that didn't work?
<Chipzz> kmap_lab: which may be handy for people not immediately aware of what the bug is about
<kmap_lab> ubotu: launchpad #135492
<ubotu> Launchpad bug 135492 in libitpp "Update to latest version in Ubuntu" [Wishlist,Fix released] https://launchpad.net/bugs/135492
<Chipzz> kmap_lab: not immediately for me either, I guess ubotu is lagging a bit
<kmap_lab> Chipzz: Appreciated. Thanks.
<Chipzz> now, let's stop playing around with the bot :P
<kmap_lab> I notice that there are Ubuntu specific changes to that package, which could be why the sync has stopped. But I have merged the changes back into Debian, so I guess auto-sync can start again?
<seb128> kmap_lab: the bug is closed
<kmap_lab> seb128: I know! But autosync is not happening, which is what I wanted to know about.
<seb128> kmap_lab: archive-admins don't look at closed bug, if you want a new version sync you need to open a new bug
<kmap_lab> seb128: Oh, I see. Thanks. Is there a provision of reopening that bug?
<seb128> kmap_lab: autosyncs have been stopped in december, look at the hardy schedule
<kmap_lab> seb128: Oh, OK. I'll have a look
<kmap_lab> seb128: Oh, that answers my query. Thanks.
<kmap_lab> seb128: DebianImportFreeze, I guess...
<seb128> you are welcome
<seb128> kmap_lab: right
<kmap_lab> Perfect. :-)
<dholbach> pitti: thanks a lot
<dholbach> hey thekorn!!! happy new year!
<dholbach> thekorn: it's time that bdmurray merges your patches :)))
<geser> Hi dholbach
<dholbach> hey geser :)
<dholbach> good to see you all again!
<ogra> hey dholbach, happy new year ...
<dholbach> heya ogra - all the best to you!
<ogra> :)
<dholbach> ogra: can you take a look at bug 177126?
<ubotu> Launchpad bug 177126 in xscreensaver "please merge xscreensaver 5.04-2 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/177126
<TheMuso> c
<TheMuso> wrong tab
<ogra> dholbach, yep, btw, i'm not maintaining gnome-screensaver and g-p-m anymore, thats ted now
<dholbach> ogra: OK, it's just that this is a request for review which I subscribe canonical-distro team members (that can upload) too on a round-robin basis
<dholbach> s/too/to
<ogra> no, xss is fine, i havent found a successor here yet ... just gpm and gss
<dholbach> still Ted cannot upload yet :)
<ogra> oh, crap, indeed :)
<dholbach> ogra: also bug 177631 please
<ubotu> Launchpad bug 177631 in gnome-power-manager "Please merge gnome-power-manager 2.20.2-1 (main) from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/177631
<seb128> dholbach: check with ted that he's not working on the 2.21 update
<dholbach> ogra: ^ are you in touch with ted about that?
<ogra> dholbach, sory, was onteh phone ... no, i'm not since he made the last merge ...
<ogra> but i'll ping him and ask if he needs an upload bitch :)
<dholbach> ogra: can you liaise between the guy who did the merge and ted so no work gets dropped? thanks a lot :)
<hairulfr> Hey all, was wondering if the dual names icons for desktop / trashcan will be changed in upcoming release? They are called both user- and gnome-fs so in reality you need two sets of icons.
<seb128> hairulfr: what icons name are you speaking about exactly?
<seb128> hairulfr: it's likely that user- is the new naming and applications not using it should be updated
<hairulfr> seb128: Yeah, probably, I remember messing about with it, but just renaming to user-fsXXXX.png didn't work, so needed two sets, as far as I remember
<hairulfr> Incidentally, where do I find the default icons?
<seb128> what do you call default icons?
<hairulfr> I'm talking about thrashcan and desktop icon
<hairulfr> 'trash
<seb128> look to the human icon theme and gnome icon theme
<seb128> hairulfr: nautilus uses user-trash and user-trash-full apparently
<seb128> hey Hobbsee
<Hobbsee> heya seb1281
 * Hobbsee wonders where her special keys have gone again
<Fujitsu> Hobbsee: I haven't lost mine for a couple of days.
<hairulfr> seb128: Ahh! Yeah, that's the one :)
<Hobbsee> right.  have keys back now
<Hobbsee> Fujitsu: have you searched for a bug on that yet btw?
<Fujitsu> Hobbsee: I've little idea where to look.
<Hobbsee> Fujitsu: this is where you rely on LP search being accruage
<Hobbsee> er, accurate
<Fujitsu> accruage. Nice one.
<Hobbsee> Shockwave Flash 9.0 r31
<Hobbsee> hmm.  wonder just how date that is.
<ogra> hmm, did anythng in sed's handling of special chars change ? my sed commands that use \t in them all produce a t instead of a tab
<persia> ogra: Seems -e is more required than it once was, but I don't know why.
<ogra> hmm, i couldnt find anything in the changelog, starnge
<ogra> *strange
<persia> \d also stopped working for some reason, causing at least one get-orig-source failure.
<Hobbsee> Fujitsu: i don't see a bug
<tkamppeter> I have found a big problem: I cannot se my time zone with time-admin, I have it reported as bug 181015
<ubotu> Launchpad bug 181015 in gnome-system-tools "time-admin gives always "The configuration could not be loaded", even if started as root" [Critical,Confirmed] https://launchpad.net/bugs/181015
<tkamppeter> I am in the "admin" group and even with a root console ("sudo -s") I cannot run time-admin.
<seb128> tkamppeter: no need of sudo in hardy, the system tools are using policykit
<tkamppeter> seb128, and how do I get it working then?
<seb128> tkamppeter: you wait until the bug is fixed or write a patch for it
<tkamppeter> seb128, so policykit is not yet implemented for time-admin?
<seb128> it is, you can click on "unlock", but there is a bug somewhere which makes it not work as expected
<seb128> I've no details yet, I'm just back from holidays and didn't look into that yet
<tkamppeter> seb128, where can I click on "unlock"?
<pitti> tkamppeter: there's a button in time-admin
<tkamppeter> seb128, there I cannot get yet.
<seb128> is your system uptodate?
<seb128> looks like you have an another bug than the one I was thinking aobut
<seb128> maybe a dbus issue
<tkamppeter> seb128, so how can I set my time zone (and also do this "unlock") via config file editing and daemon restarting?
<tkamppeter> seb128, I updated 3-4 hours ago.
<seb128> you can try to restart the system-tools-backends
<seb128> otherwise I don't know, that looks like a bug and require debugging but I'm busy without other things at the moment
<seb128> tkamppeter: also don't confirm your own bugs, that defeat the purpose of the status
<seb128> the point is to have somebody else confirming the issue
<seb128> not to have the submitter confirming he has the bug
<thekorn> hi dholbach, happy new year, all the best for 2008!
 * dholbach hugs thekorn
<geser> thekorn: are you the master of python-launchpad-bugs?
<geser> I'm working on a version of requestsync which uses python-launchpad-bugs to file the bug. It there a common place where to look for the authentication cookie?
<pitti> geser: I think .mozilla/*/*/cookies.txt is a good first approximation
<pitti> geser: you have to actually search if there are multiple, of course
<pitti> grep -l launchpad.net .mozilla/*/*/cookies.txt
<pitti> maybe
<geser> hmm, that might work as p-lp-bugs wants a file
<thekorn> geser, sorry, was away, but pitti is right, just do something like: Bug.authentication=<path to current mozilla cookie-file>
<dholbach> geser:      curl -b ~/.lpcookie -c ~/.lpcookie -d loginpage_email=XXX password=XXX https://launchpad.net/+login         would work too
<gicmo> seb128: dude
<gicmo> ALTER
<seb128> gicmo: alter!
<seb128> gicmo: happy new year ;-)
<geser> dholbach: I've used now pitti's suggestion and used some code from his buildd.py script to find the cookie. I'll give it some more testing and attach it to bug #147994 to get some more testing before I include it in the ubuntu-dev-tools package. Currently it
<ubotu> Launchpad bug 147994 in ubuntu-dev-tools "requestsync should have a command line switch to use python-launchpad-bugs (instead of mailing)" [Wishlist,New] https://launchpad.net/bugs/147994
<geser> it's a separate script
<dholbach> geser: ok great
<dholbach> I never found out if pylpbugs worked for konqueror cookies
<Kmos> i've enabled pkgstriptranslations in pbuilder and when I start a build it give me this error
<Kmos> ups
<Kmos> [14:27] <Kmos> grep: debian/control: No such file or directory
<Kmos> [14:27] <Kmos> /usr/bin/pkgstriptranslations: Error: not in source package directory
<Kmos> [14:27] <Kmos> EtienneG: pbuilder-satisfydepends failed.
<Kmos> i'm on gutsy
<tkamppeter> seb128, how do I restart the system-tools-backends?
<seb128> tkamppeter: restart dbus that will do it
<pitti> blunt :)
<pitti> seb128: why do you need to restart it at all? I thought the only long-running daemon was the smal thing that just launches the real apps?
<pitti> s/apps/backend/
<tjaalton> pitti: hi, would you have time to look at the openchrome promotion before alpha3? I'm doing merges of xorg and xorg-server (discover is gone!), and would add it to the default set of installed drivers as discussed with bryce
<seb128> pitti: bug #181015, I've no real idea about the issue but that could be a dbus issue, I'm just curious to know if that's still there after a dbus restart
<ubotu> Launchpad bug 181015 in gnome-system-tools "time-admin gives always "The configuration could not be loaded", even if started as root" [High,New] https://launchpad.net/bugs/181015
<pitti> tjaalton: yes, that should be possible; please just add the dependencies, then the archive checks will remind us
<tjaalton> pitti: cool
<pitti> seb128: hm, no idea; t-a just works here
<seb128> pitti: works here too
<tkamppeter> seb128, now I get the main window of time-admin, but with everything except Help, Synchronize Now, and Close grayed out. Especially Unlock is also grayed out.
<seb128> tkamppeter: looks like a policykit issue
<seb128> tkamppeter: does "polkit-grant --gain org.freedesktop.systemtoolsbackends.set" work for your user?
<tkamppeter> Does not work:
<tkamppeter> till@till-laptop:~/printing/system-config-printer/trunk$ polkit-grant --gain org.freedesktop.systemtoolsbackends.set
<tkamppeter> Attempting to gain the privilege for org.freedesktop.systemtoolsbackends.set.
<tkamppeter> ** (process:26987): WARNING **: Error doing GetSessionForUnixProcess on ConsoleKit: org.freedesktop.DBus.GLib.UnmappedError.CkManagerError.Code0: Unable to lookup session information for process '26987'
<tkamppeter> ** (process:26988): WARNING **: Error doing GetSessionForUnixProcess on ConsoleKit: org.freedesktop.DBus.GLib.UnmappedError.CkManagerError.Code0: Unable to lookup session information for process '26987'
<tkamppeter> ** (process:26988): CRITICAL **: polkit_session_get_ck_objref: assertion `session != NULL' failed
<tkamppeter> polkit-grant-helper: cannot get session ck objpath
<tkamppeter> Failed to gain the privilege for org.freedesktop.systemtoolsbackends.set.
<tkamppeter> till@till-laptop:~/printing/system-config-printer/trunk$
<seb128> tkamppeter: that's a policykit issue then, maybe pitti has an idea about it
<tkamppeter> None of the process numbers mentioned here appears in the "ps auxwww" output.
<pitti> tkamppeter: does ck-list-sessions have a session for you?
<tkamppeter> pitti. seb128, ck-list-sessions has no output at all for me.
<pitti> tkamppeter: ah, that happens sometimes (bug); restarting your X session will help
<pitti> tkamppeter: if you know how to reproduce this situtation (not getting a ConsoleKit session), that would be great
 * ogra sighs about CK as well ... giving me a hard time in ltsp
<pitti> ogra: how did you work around it in gutsy?
<ogra> it didnt restrict e there
<ogra> *me
<ogra> iirc we didnt even have it in the install
<ogra> but i need to make ldm somehow set up the session ... which isnt easy since ldm doesnt run on the server
 * ogra misses a python binding to make that easier :P
<pitti> we did install it by default in gutsy, for f-u-s-a at least
<ogra> ldm isnt used to talk to the servers dbus
<pitti> ogra: python bindings? python-dbus :)
<tkamppeter> pitti,seb128, now after restarting X I could gain the privileges with "polkit-grant --gain org.freedesktop.systemtoolsbackends.set". This step should be automated for users who update to Hardy (for all users in "admin") and also for all new users created with admin privileges. Most users (even advanced ones) will not know about Policy Kit and also nop about this complicated command to gain privileges.
<pitti> tkamppeter: no, it shouldn't be automated, and you shouldn't need to type it in
<ogra> pitti, import consolekit ... consolekit_register()
<ogra> :P
<tkamppeter> pitti,seb128, thanks for your help.
<pitti> tkamppeter: that's what the "Unlock" button of the UI does
<pitti> tkamppeter: it was just a testing command to check whether the bug is in PK or the UI
<tkamppeter> pitti, and that button was grayed out before I gained privileges via the command line.
<pitti> tkamppeter: that would be a UI bug then
<ogra> pitti, actually i'd expect ssh to handle it through pam ... ldm shouldnt be involved at all, if DISPLAY is set in any manner ssh should care ... thats the part that bothers me about all this
<tkamppeter> pitti, why the Unlock button at all? Can the program not simply do the Unlock action whenever it is started and so everything stays transparent?
<pitti> tkamppeter: it's primarily meant for non-admins to get readonly access
<pitti> it certainly could do it, of course
<pitti> of course it is a bit pointless to not unlock if you can unlock without a password
<pitti> that should indeed be fixed
<pitti> tkamppeter: feel free to file a bug about it
<seb128> tkamppeter: the button was not activate until you restarted your session rather?
<seb128> s/activate/active
<seb128> the command line action was to determine why it was not active, and it was due to the consolekit bug
<ogra> pitti, oh, f-u-s-a had a ltsp specific patch that disabled user switching anyway in gutsy, so we didnt have any CK related issues back then
<ogra> i only have probs since all the admin tools ask CK for permission ... is there any chance that we'll see the CK pam module in main ?
<ogra> looks like it would solve my probs if integrated with ssh
<pitti> there is one for VT sessions; I haven't tried it yet, but it uses pam
<ogra> libpam-ck-connector is in universe it seems
<tkamppeter> pitti, seb128, the time-admin problem is still not solved. Now I get everything ungrayed by clicking Unlock, but when I chabge the time zone, the change is ignored.
<seb128> tkamppeter: right, that one is the known issue I was speaking about this morning which is a gnome-system-tools bug and need to be debugged
<tkamppeter> seb128, so the gnome tools are still not able to write new configs? So the policy kit stuff only gets read access for now?
<seb128> no
<seb128> there is just a bug somewhere
<seb128> dunno the details before looking at why it's not working
<tkamppeter> So I should better edit /etc/timezone for now?
<pitti> tkamppeter: sudo tzselect
<ogra> sudo dpkg-reconfigure tzdata
<pitti> that's better, yes
<tkamppeter> Thank you, now my time zone is corrected.
<vlowther> hmmm... anyone else notice that /lib/modules/2.6.24-3-generic/volatile is not being created with the latest kernel upgrade?
 * vlowther is back on 2.6.4.24-2 for now.
<vlowther> well, it would help if the linux-restricted-modules package had been pushed at the same time as the rest of the kernel updates. :)
<jdong> it should?
<jdong> for me until they all show up linux-generic gets held back
<jdong> or maybe I'm losing my mind
<infinity> Indeed, unless you installed the kernel and LRM "by hand" without the metapackages, that can't happen.
<vlowther> that could be the case -- this install has been upgraded and hacked on since approx. hoary.
<vlowther> that, and I ahve a habit of dist-upgrading during development cycles instead of just upgrading.
<jdong> what's up with Hardy's kernel with respect to cstates?
<jdong> /proc/acpi no longer shows the active cstate, /sys no longer has the max_cstate parameter...
<jdong> and the system feels overall sluggish after the upgrade
<jdong> macbook core 2 duo
<vlowther> no clue there.  Hardy seems to be doing just fine on my Dell Latitude D820. :)
<vlowther> heck, even the headphone jack works correctly again, which was not the case in Gutsy.
 * vlowther grumbles something about alsa and ad-hackery in the hd audio drivers
<vlowther> it looks like the /sys hierarchy got messed around with.  Again. This script should gather the cstate info on your box, tho:
<vlowther> for x in /sys/devices/system/cpu/cpu?/cpuidle/state?/*; do echo -n "${x}: "; cat ${x}; done
<vlowther> on my box, it looks like the procs are spending most of their time in C3 like they should.
<jdong> vlowther: ah, the structure changed
<jdong> vlowther: ok, that's good to know then
 * vlowther thought /sys was supposed to be vaguely stable...
<jdong> haha... linux... stable... hahaha
<tkamppeter> pitti, new s-c-p, bifff, fixes 4 bugs for Alpha3.
<pitti> slangasek: ah, Debian now builds cyrus-sasl2 against db4.6, too, my patch was accepted
<pitti> soren: are you planning to merge dpkg today or tomorrow? if not, I'll fix the gcc-4.2 build dep to make it buildable
<soren> pitti: Tomorrow.
<slangasek> pitti: cool
<pitti> soren: ah; just wondering, because bug 177917 is RC for alpha-3
<ubotu> Launchpad bug 177917 in dpkg "64bits libs installed on i386 systems" [High,Fix released] https://launchpad.net/bugs/177917
<pitti> soren: well, hm, since gcc-4.2 has to build either way, it takes a while, and I have the upload ready, I guess I just upload it
<soren> pitti: That would be great.
<pitti> and takes the pressure off you :)
<soren> Oh, i didn't even think of that.
<soren> </sarcasm>
<soren> :)
 * pitti only just now recognizes what he has just done -- becoming TIL for gcc-4.2; ARGH!
<soren> Muhaha!
<Mithrandir> pitti: you win.
<geser> slangasek: have you time to review bug #180669? or is this post-alpha3 stuff?
<ubotu> Launchpad bug 180669 in fakeroot "[Merge] fakeroot 1.9 from Debian unstable (includes also a fix for the FTBFS)" [Undecided,New] https://launchpad.net/bugs/180669
<slangasek> geser: I probably have time for it today
<geser> ok, thanks
<hunger> Is there a trick to create a gnome user in hardy? After adduser all I get when logging into gnome is a white screen.
<keescook> is there a pythonic way to do the same as "dpkg --compare-versions" ?
<keescook> ah         res = apt_pkg.VersionCompare(ver1, ver2)
<mdz> keescook: the 'apt' module is a more pythonic API
<mdz> though for that particular function I doubt it matters
<keescook> mdz: okay, good to know.  In my case, I've already got apt_pkg imported, so I'll stick with this
<el_cubano> How would i go about requesting inclusion of a package from Debian for Hardy?
<slangasek> el_cubano: a package that's already present in hardy and needs updated, or a new package?
<el_cubano> slangasek: new
<el_cubano> source package name is tbb
<slangasek> el_cubano: file a bug against "ubuntu" in launchpad (https://bugs.launchpad.net/ubuntu), requesting that it be synced; then subscribe "ubuntu-universe-sponsors"
<slangasek> el_cubano: https://wiki.ubuntu.com/SyncRequestProcess has more details
<el_cubano> slangasek: thanks
<slangasek> tjaalton: so 180806 was actually a bogus sync, the Debian maintainer reverted a key Ubuntu change that put lib32bz2-1.0 in /usr/lib32 instead of in /emul/ia32-linux.
<slangasek> tjaalton: I'll follow it up with a sourceful upload.
<tjaalton> slangasek: oh crap
<tjaalton> slangasek: sorry for not checking that, and thanks
 * slangasek nods
<slangasek> tjaalton: it was infinity's catch, actually; I read the changelog and strolled blindly by
<slangasek> anyway, fixed package on its way now
<tjaalton> cool
<slangasek> soren: please mark sync requests as 'confirmed' when you're acking them and subscribing ubuntu-archive (#180371)
<soren> slangasek: Ah, right. Sorry about that. I did feel like I was missing something, but couldn't quite put my finger on it.
<slangasek> soren: no worries :)
<soren> :)
 * soren wishes the good people of #ubuntu-devel good night
 * slangasek waves
 * calc ponders eating dinner since he is hungry but feels like he is going to vomit :-\
<ScottK> That's easier with food in your stomache.
<calc> yea sounds like a plan to me
<calc> whats funny was the last time i was sick i was running 102F and didn't even feel sick (probably couldn't think straight) but now i am only running mid 99F and feel really sick
 * calc goes to get some food and then lay down :-\
<ion_> 102 coulomb/volt
<jdong> ion_: not those kinds of F ;-)
<jdong> ion_: if so I want him in my trunk next to my amp.
<LaserJock> do we need to file sync request bugs for new packages in Debian that are not in Ubuntu?
<ScottK> Since we're past DIF, yes.
#ubuntu-devel 2008-01-08
<LaserJock> that's what I thought, just wanted to make sure
<swj> anyone know when linux-generic linux-image-generic linux-restricted-modules-generic xserver-xorg-video-all is coming down? Thanks!
<slangasek> what do you mean, "coming down"?
<swj> i.e., ready to apt-get upgrade
<crimsun> swj: in hardy, linux-meta has already built and points to the 2.6.24-3-generic packages.
<swj> those packages are held back on my system for some reason...
<swj> thus breaking nvidia
<swj> switched to nv
<crimsun> they're blocked on linux-ubuntu-modules-2.6.24-3-generic.
<StevenK> slangasek: Could I convince you let something out of binary NEW?
<slangasek> StevenK: you can try!
<LaserJock> swj: in general it's good to wait until everything is ready to install (not held back) before upgrading the kernel :-)
<StevenK> slangasek: Heh. If you feel so inclined, could you let moko out of binary NEW?
<ScottK> StevenK: Did you see my missive on perl-modules on ubuntu-devel?
<StevenK> I didn't.
<swj> crimsun: thanks.  I sure I need to just wait for them; however, I was wondering how long it usually takes...
<slangasek> StevenK: pff, you can try harder than that to convince me, I'm sure
<slangasek> swj: "until your mirror catches up"
<swj> crimsun: I usually do...but today I was in a hurry and this is a test machine; however, I do play games from time to time
<swj> thanks
<swj> oh so I can possibly change mirrors and get them?
<StevenK> slangasek: Puhhleeease? :-)
<slangasek> oh, ok
<crimsun> swj: see https://launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=linux-ubuntu
 * ScottK pokes StevenK to see if he can be tortured into confessing knowing something about Perl.
<StevenK> Nope.
<ScottK> OK.
<ScottK> I guess I'll start ripping perl-modules apart then.
<StevenK> Have you asked bod?
<ScottK> No.  Who or what is bod?
<swj> thanks
<StevenK> They were pulled into perl-modules for a reason, I suspect the seperate packages want to bugger off, and the source in perl-modules updated?
<StevenK> ScottK: Original-Maintainer: Brendan O'Dea <bod@debian.org>
<ScottK> Ah.
<ScottK> No.  I haven't.  But in the mean time we've got stuff the won't build.
<StevenK> But I suspect they shouldn't exist seperately.
<jtt> can anyone tell me how to retrieve an svn trunk one level down i.e. latest trunk is 100 i want 99
<StevenK> ScottK: I'm still unconvinced they need to be seperate.
<ScottK> StevenK: So you'd suggest updating the packages in perl-modules instead?
<StevenK> Right.
<ScottK> That'd work too, but seems like more effort in the long run (new perl upload each time the module is updated).
<StevenK> Then don't update them? They're part of perl, they'll get upgraded when Perl does.
<ScottK> Right.  Then the separate module packages should all be removed?
<StevenK> If they're part of perl-modules, they need to die. All they cause is confusion.
<ScottK> And other perl packages that depend on newer versions don't get uploaded?
<StevenK> ScottK: Do any exist?
<ScottK> Yes.
<StevenK> Oh, grumble.
<ScottK> mime-tools and libmail-box-perl at least
<ScottK> For mime-tools it's a new dependency, but libmail-box-perl last built in Edgy because of this problem.
<StevenK> You have proved quite suctinctly why they shouldn't be seperate. I'm not in favour of ripping apart perl-modules since the next time a core-dev looks at merging Perl, they'll have a heart attack.
<slangasek> StevenK: why does moko contain a shared lib but no sane lib packaging?
<ScottK> StevenK: Well we currently have them both in perl modules and separately.  I think we either need to update the code in perl-modules, rip it out, or figure some easy way for sbuild to know the version a virtual package provides.  Which would you pick?
<StevenK> Version Provides aren't supported, and probably aren't going to be.
<StevenK> Er, versioned
<ScottK> OK.  That narrows the choices.
<slangasek> well, there's been talk in the past of versioned provides
<Robot101> why can't the other package just depend libfoo-perl > x | perl-modules > y ?
<ScottK> Because sbuild will believe it already has it installed (because it does - just not in sufficient version) and still fail the build later on.
<Fujitsu> Should sbuild perhaps not let Provides fulfill a versioned dependency?
<StevenK> Fujitsu: Which will break packages that currently build
<Fujitsu> Probably, yes.
<slangasek> Robot101: sbuild specifically gets confused by versioned depends on virtual packages
<slangasek> so I'd say that's an sbuild bug, but it seems to be a fairly long-lived one
<ScottK> So then what's the least painful work around?
<ScottK> It doesn't seem to be about to go away at all (the bug)
<slangasek> either pull the newer modules into perl-modules and have a versioned build-dep on that, or split the modules into their own packages (that part's done) and make perl-modules depend on them instead of providing its own copies, dropping the Provides
<slangasek> I'm ambivalent on the choice, but those are the only two solutions I see that work right
<minghua> I think ScottK proposed exactly the second in his mail?
<StevenK> slangasek: Which means those packages need to be sucked into the minimal set.
<ScottK> minghua: Yes.  That's what I proposed because seemed easiest to maintain
<ScottK> StevenK: Done by making perl-modules depend on them
<slangasek> StevenK: which isn't onerous IMHO, the content is already there but in a different form
<slangasek> even without the sbuild bug, I think the current situation of having two copies of the modules in the archive is Bad Mmkay
<ScottK> slangasek: What would vorlon have to say about this do you think?
<slangasek> probably the same thing
<slangasek> :)
<ScottK> OK.  Just checking.
<slangasek> vbrfix is an improbably small package
<StevenK> Oh, twitch.
<StevenK> lrwxrwxrwx 1 steven users   67 2008-01-08 12:38 missing -> /scratchbox/tools/autotools/automake-1.7/share/automake-1.7/missing
<StevenK> Thank you for shipping that *useless* symlink.
<slangasek> eh, where's that?
<bddebian> heh
<StevenK> slangasek: Bomberman for the N800
<StevenK> I'm unsure if I should rename the package, too
<StevenK> ("Bomberman" might be a trademark)
<bddebian> Just fix clanbomber to build with clanlib 0.8 instead will ya? ;-P
<slangasek> StevenK: trademarks lapse if you're not trading on them
<StevenK> Cool
<slangasek> (IANAL, TINLA, TMTOWTDI, YHTBT, YHBT)
<StevenK> Any more choice acroynms you want to throw out there?
<slangasek> TINC
<ScottK> SNAFU
<ScottK> BOHICA
<StevenK> slangasek: HAND
<slangasek> the last of the bohicans
<Romney08> GOVERNOR ROMNEY: "And further, if I were fortunate enough to be elected your President, I'd call for a National Summit of Nations to create a new partnership â a Partnership for [Progress] and Prosperity."
<Romney08> "This Partnership would assemble the resources of all the nations of the world to work to assure that Islamic states that are threatened with violent Jihad have public schools that are not Wahhabi madrasas; that they have micro-credit and banking, the rule of law, human rights, basic health care, and competitive economic practices." (Governor Mitt Romney, Remarks At Yeshiva University, 4/26/07)
<Vorian> !ops | Romney08
<ubotu> Romney08: Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<Hobbsee> meh.
 * Hobbsee doesn't have enough access
<elkbuntu> thanks
<nenolod> there's a windows virus going around that has strings concerning ubuntu in it -> http://projectshadow.randomsonicnet.org/misc/trueman_virus.txt
<dmb> yes, indeed
<dmb> i'll pastebin them
<dmb> http://pastebin.da4.org/231
<slangasek> did someone finally write the "antibodies for Windows" virus?
<dmb> here's the whole strings thing: http://pastebin.da4.org/232
<nenolod> slangasek, no, it just seems to not nicely use ubuntu mirrors for speedtesting
<slangasek> oh, lovely.
 * StevenK chokes.
<StevenK> OH. MY. GOD.
<StevenK> http://paste.ubuntu.com/3363/
<slangasek> tasty
 * StevenK senses some new livergrams
<ion_> stevenk: :-D
<nenolod> StevenK, is that a debian/rules ?
<nenolod> i mean you can technically do a debian/rules like that (hopefully it would be rejected)
<StevenK> That's a "package.sh" I found in the tarball of a game.
<nenolod> ar -rc ../sokoban_2.00-1_armel.deb debian-binary control.tar.gz data.tar.gz
<nenolod> this seems especially interesting
<nenolod> :D
<StevenK> If you did a debian/rules like that, it *would* be rejected.
<nenolod> StevenK, i saw one in zsh script once
<nenolod> StevenK, it was in some upstream tarball
<StevenK> Twitch
<nenolod> actually, there's an idea
<nenolod> have a contest as a teaching tool to come up with the most perverse debian packaging you can think of
<Hobbsee> use yada.  problem solved.
<nenolod> (the only rule that would apply is "must install")
<Hobbsee> although that is quite special too
<nenolod> Hobbsee, i make all of my debian packages with checkinstall
 * nenolod nods
 * Hobbsee adds to her little black book
<nenolod> Hobbsee, i must wonder what people's obsession with yada and checkinstall are
<nenolod> i don't see what's really hard about making a debian package, it takes what? 10 minutes for most packages and you only really have to do it once?
<nenolod> oh yes
<nenolod> Hobbsee, yada's documentation looks absolutely disgusting
<Hobbsee> yeah....
 * nenolod writes a tool to make a debian package from an RPM spec file
<nenolod> haha! i win ;)
<StevenK> That's been done. Ho hum
<nenolod> really?
<ion_> apt-get says â1min29sâ while downloading packages. Didnât it say â1m29sâ before, or are my synapses on drugs?
<nenolod> StevenK, from a .spec file?
<ion_> Ah, it changed in 0.7.9ubuntu2.
<nenolod> StevenK, alien, sure
 * ion_ writes a tool to make a debian package from a WindowsÂ® Installer file.
<nenolod> ion_, aren't those DRM'd somehow?
<Chipzz> nenolod: I think debian/rules are *required* by debian policy to be a Makefile
<Chipzz> and they should support multiple targets
<nenolod> Chipzz, yes. like i said "hopefully it would be rejected" ;)
<nenolod> Chipzz, i have seen debian/rules as other things though in upstream tarballs
<Chipzz> god I hate OPN's nickserv at times
<nenolod> they're supposedly replacing it with my implementation of Services soon
<nenolod> (atheme-services in debian experimental)
<Chipzz> you don't notice getting disconnected, get unidentified from nickserv, start chatting with someone and then wonder why they're not responding
<highvoltage> tomboy, tomboy, tomboy, tomboy, tomboy, tomboy
<nenolod> Chipzz, hehe, see PM sometime ;)
<nenolod> hmm
<nenolod> i think a package should be created outlining what NOT to do during packaging
<nenolod> e.g. "if your debian/ looks like this, you've messed up even if it builds correctly"
<dholbach> good morning
<Fujitsu> Hi dholbach.
<dholbach> hiya Fujitsu :)
<nenolod> hi
<dholbach> hey nenolod
<nenolod> dholbach, one suggestion for your MOTU Q&A sessions would be to go through how to NOT make a debian package
<nenolod> you know, do insane things like write debian/rules in bash
<nenolod> (of course making it clear that doing these things will earn an instant REJECT)
<dholbach> nenolod: we could make it a fun session collecting ideas on how to make a package really crackful for like 5 minutes, then take every point on the list and try to think of ways to avoid it - cool idea - see you on friday ;-)
<ion_> Hi dholbach
<nenolod> dholbach, i'll have to find the upstream tarball i was looking at which had a debian/rules in zsh.
<nenolod> dholbach, yada and checkinstall are givens clearly
<dholbach> hehe, let's see what we can come up with :)
<dholbach> hi ion_
<nenolod> dholbach, StevenK found this work of art: http://paste.ubuntu.com/3363/
<pwnguin> heh
<Hobbsee> dholbach: make sure you include "do a package named automatix3, and ask Mithrandir to review it"
<Hobbsee> oh, and make sure you're in a different country at a time
<StevenK> Morning pitti
<dmb> <Chipzz> you don't notice getting disconnected, get unidentified from nickserv, start chatting with someone and then wonder why they're not responding // i'v done that multiple times :D
<pitti> Good morning
<pitti> hey StevenK
<Chipzz> dmb: me too, on several occasions; which is why I was whining :P
<StevenK> pitti: I wonder if the kernel can be NBS'd out
<ion_> Hi pitti
<pitti> StevenK: if everything from -3 built, yes
<StevenK> pitti: However, libtinymailui-mozembed-1.0-0 and libtinymailui-mozembed-dev can be NBS'd out at your leisure.
<pitti> StevenK: well, we still need to rebuild d-i, but that has to happen anyway
<pitti> StevenK: great
<StevenK> pitti: libopenscenegraph4, libopenthreads4, and libproducer4 can all go, too.
<pitti> cjwatson: I moved the seeds to the 2.6.24-3 kernels and merged them all
<pitti> so we just need a d-i rebuild now
<Hobbsee> guten morgen pitti
<pitti> hey Hobbsee!
<Hobbsee> :)
 * Hobbsee wonders when keybuk will turn up
<pitti> StevenK: ok, I NBS'ed the kernel, the libs you gave me, everything without rdepends, and all *-dev packages
<dholbach> Hobbsee: it's 7:40 now where he lives :)
<StevenK> pitti: You rock! *hugs*
<StevenK> pitti: The list on rookery is up to date, or I need to wait for a publisher cycle and a regen?
<pitti> StevenK: the latter
<StevenK> Okay
<Hobbsee> dholbach: ahhh.
 * Hobbsee wonders what 7.40 is.
<StevenK> Another name for 10.04
<StevenK> :-P
<Hobbsee> oh right.
<Hobbsee> does that work for both am and pm?
<StevenK> Hum? I think you took my joke seriously
 * Hobbsee got it, and took it both ways.
<Hobbsee> assuming you're having a go at me for how mornings and i don't mix, when on an au-timezone.
<StevenK> I'm not
<Hobbsee> then i missed it :(
<StevenK> 7.40 -> 40th month of 2007; 40 months is 3 years, 4 months -> 10.04
<Hobbsee> right
<soren> I should probably hold back the dpkg merge until after tha alpha?
<pitti> soren: might be a good idea, yes
<pitti> depending on how intrusive the merged changes are?
<soren> pitti: Not sure yet. I was only just about to start working on it.
<slangasek> might be a good idea anyway? :)
<soren> slangasek: That was what I was thinking, too. dpkg uploads still scare the fsck out of me :)
<slangasek> yes, I have a bottle of antacids earmarked for dpkg uploads
<soren> :)
<StevenK> And another for OO.o uploads?
<Fujitsu> StevenK: You need worse than that for OOo.
<slangasek> nah, OOo uploads take long enough that I can use prescription preventatives
<StevenK> Muahaha
<TheMuso> 5~/c
<TheMuso> argh
<Richard_> gdb vmlinux, why will list start_kernel command lead to time.h?
<slangasek> lamont: curious that gmetadom ftbfs with an ocamlfind problem in hardy, but didn't in sid...
<slangasek> lamont: the trick seems to be that "ocamlfind install" is being treated as a request to run some program named "install", but it's supposed to be an ocamlfind subcommand instead -- recognized on other archs... http://launchpadlibrarian.net/11187736/buildlog_ubuntu-hardy-hppa.gmetadom_0.2.5-3ubuntu1_FAILEDTOBUILD.txt.gz
<slangasek> lamont: btw, I'm chasing this because the old version of gmetadom is the last reverse-dep of libgcc2 in main ;)
<\sh> moins
 * slangasek waves
<\sh> looks like whitelisting fglrx for compiz is not enough to get actually fglrx working with a card which should be supported
<tjaalton> pitti: vmmouse is now fixed, so it can be promoted to main. it should now be used by default on vmware installs
<tjaalton> pitti: no fix for the resolution issue yet :/
<tjaalton> apparently the driver tries to use 1024x768, but doesn't get a valid mode for it
<kelmo> hi. I'd love to discuss an extension of Ubuntu's sendsings.omit interface in initscripts package (to be more similar to debian's initscripts). who is appropriate developer and/or automated ticket system to contact ?
<pitti> tjaalton: right, I thought the reason was that the default sync rates were too small?
<geser> good morning
<pitti> hi geser
<rzr> hi, snd app review welcome : https://bugs.launchpad.net/ubuntu/+bug/160732
<ubotu> Launchpad bug 160732 in ubuntu "[needs-packaging] Jaaa (JACK & ALSA Audio Analyser)" [Wishlist,In progress]
<rzr> let's try motu 1st ..
<pitti> tjaalton: hm, didn't you say you filed MIR bugs for the video drivers? I don't see them on https://bugs.edge.launchpad.net/~ubuntu-mir/+subscribedbugs
<pitti> StevenK: libhildonfm> what's debian/changelog1 good for?
<tjaalton> pitti: oh, I subscribed ubuntu-archive :/
<StevenK> pitti: Ummmmm
<StevenK> pitti: Ah, right. Just think of it as changelog.old
<pitti> StevenK: yeah, no problem; just pointing out in case you want to clean up cruft
<StevenK> I don't think it's worth it, it still shows history
<tjaalton> pitti: ok, ubuntu-mir subscribed to those bugs
<pitti> tjaalton: thanks
<pitti> StevenK: ah, seems that you don't use the libhildon i18n yet?
<pitti> StevenK: if you can live with entirely breaking all l10n when moving libhildon to main, it's fine
<pitti> depends on whether being in main or i10n'ed is more important
<ogra> is the final metapackage upload for alpha3 already done ? i need an installer seed change i'd like to see in there
<pitti> ogra: we didn't get a rebuilt d-i yet, so go ahead
<ogra> great, thanks :)
<pitti> ogra: I recently merged the kernel ABI change to the seeds, FYI
<pitti> StevenK: bug 149275 updated; please let me know if I should promote libhildon and its rdepends
<ubotu> Launchpad bug 149275 in osso-gwconnect "First cut of source packages for -mobile promotions" [Undecided,Fix committed] https://launchpad.net/bugs/149275
<pitti> tjaalton: hm, shouldn't something in main (-input-all or so) depend on xserver-xorg-input-vmmouse? ATM it doesn't
<tjaalton> pitti: 10ubuntu2 should
<tjaalton> of xorg
<pitti> ah, seems that's not built yet
<pitti> or rather, not published
<tjaalton> yep
<pitti> tjaalton: ok, thanks
<tkamppeter> hi ptti
<pitti> hi tkamppeter
<pitti> tkamppeter: the gnome-system-tools PK bug is fixed now
 * Hobbsee waves again
<tkamppeter> I have put up a new system-config-printer now, can you upload it into Alpha3?
<pitti> yes, I'll get to it
<tkamppeter> pitti, great, so then  one can use the GUI config tools in Alpha 3 again.
<geser> Hi Hobbsee
<tkamppeter> pitti, is Henrik Nilsen Omma around?
<pitti> tkamppeter: not ATM, no; ("heno")
<pitti> tjaalton: hm, now we just need a working patch for building the vmware modules on 2.6.24 :)
<tjaalton> pitti: good point :)
<tjaalton> pitti: hmm, does the client need those? I mean shouldn't it be possible to run hardy vmware client on gutsy host
<pitti> tjaalton: right
<tkamppeter> pitti. do you know whether he is on vacation? I need to talk with him because of the participation in the Sprint in London
<pitti> if only I had a gutsy install :)
<tjaalton> pitti:  same here.. I can't test those :)
<tkamppeter> Where is the web site for the sprint?
<pitti> tkamppeter: he's not listed as being on vac, so he should turn up today
<pitti> tkamppeter: maybe just mail him?
<tkamppeter> pitti, I sent mail to him on Friday and he did not answer up to now. I have sent a reminder today.
<ScottK> pitti: Since you touched Perl last (asked for the sync) and because it involves a MIR, I wanted to check with you and see if you had any comments on my mail to ubunt-devel about perl-modules?
<pitti> ScottK: I haven't got to that mail yet
<pitti> ScottK: is it about the virtual packages it provides and thus breaking versioned b-deps?
<pitti> in that case it is an sbuild bug which should be fixed
<pitti> but I'll read it in a bit (still doing MIR)
<ScottK> That's the one.
<pitti> that's an infinity-ism then, I think
<ScottK> Agreed its an sbuild problem, but in general I don't think we want two copies of the same code in the archives
<ScottK> And also unlikely to get fixed in the near term.
<pitti> right, we don't want code duplication, but getting rid of the b-deps and the separate packages should be done in Debian then
<Hobbsee> oh noes, it's cprov!
<Riddell> siretart: are you planning to package xine 1.1.9?
 * cprov tries to hide 
<ScottK> Would you be willing to accept doing it here first if I work to push it back into Debian?  So far they don't have any FTBFS since they generally do binary uploads of arch all packages?
<ScottK> It's less of a rush for them.
<ScottK> pitti: ^^
<Hobbsee> cprov: you cannot hide!
<pitti> ScottK: of course;
<cprov> Hobbsee: heh, too late. How are you doing ?
<Hobbsee> cprov: taking over the world.  and trying to find someone from the tech board
<ScottK> pitti: OK.  I'll contact the Debian Perl maintainer and continue working out the details then.
<Hobbsee> cprov: i haven't killed anyone yet today, either.
<cprov> Hobbsee: :)
<ScottK> It's early yet (at least here)
<pitti> ScottK: awesome, thanks
<Hobbsee> ScottK: there is that.
<ScottK> pitti: When you get to it if you could make some reply to the mail on ubuntu-devel, it would be nice ...
<pitti> ScottK: yes, I absolutely planned to
<ScottK> Great.
 * Fujitsu preemptively kills Hobbsee.
 * Hobbsee dies.  yay!
 * Hobbsee haunts Fujitsu
<ogra> Hobbsee, could you first get your corpse out of the way ? it will start to smell soon
<Hobbsee> ogra: dead people can't lift things
<Fujitsu> Damn.
<Fujitsu> Can't you haunt yourself away, or something?
<Hobbsee> not really, no
<ogra> heh
<Fujitsu> Pfft.
<Hobbsee> that would be too easy
<tjaalton> pitti: vmmouse failed to upload, "duplicated ancestry"?
<Hobbsee> if i'm going to create hell, i should at least do it properly, and create some inconvenience too!
<pitti> tjaalton: probably because I promoted the source while the binaries weren't there yet
<pitti> tjaalton: let's wait until after the next publisher, then I'll give it back
<tjaalton> ah
<ScottK> pitti: I see from my bugmail you are indeed working on MIRs.  Thanks for the approvals.  I've got about 4 more to go I think to get amavisd-new done ...
<pitti> ScottK: amavis itself sounds a bit more scary :)
<siretart> Riddell: yes, we have 1.1.9 already packaged in our hg branch
<pitti> there; everything in the MIR queue is processed now
<siretart> Riddell: we could upload soon, but we wanted to wait until the current xine package transitions to testing
<siretart> Riddell: do we need xine 1.1.9 in ubuntu soon?
 * siretart meeting
<pitti> asac: did you notice that ffox 3 always moves to the current desktop when you open a new link? that drives me crazy (ffox 2 didn't do that); is that a 'feature' or a bug?
<soren> cjwatson: Last week I stumbled upon a note saying that I should pester you about the debconf bug we worked out about a month ago (debconf-apt-progress and stale file descriptors and such) .. It would probably be good to get it in in time for alpha 3. My note says the fix is in r2249, but I may have just noted that for SRU purposes.
<Fujitsu> pitti: Hm, doesn't do that for me.
<pochu> I can confirm that, and I can confirm it's annoying :)
<Riddell> siretart: it contains some important fixes needed for KDE 4.0 (due friday)
<Nafallo> I bet ff3 wouldn't do that for me.
<Nafallo> devilspie would move it all the time :-)
<Hobbsee> Nafallo: devilspie ftw!
 * Hobbsee can't get devilspie to set something once, then ignore it, though.
<Nafallo> :-)
<pitti> tkamppeter: can you please fix http://www.linux-foundation.org/~till/tmp/ubuntu/hardy/system-config-printer/system-config-printer_0.7.78+svn1799-0ubuntu1_source.changes ?
<StevenK> pitti: Bug 149275 updated, answering your question.
<ubotu> Launchpad bug 149275 in osso-gwconnect "First cut of source packages for -mobile promotions" [Undecided,Fix committed] https://launchpad.net/bugs/149275
<StevenK> pitti: I daresay it's been long enough, would you mind regenerating the NBS list?
<pitti> StevenK: done
<pitti> cron is due in 45 minutes, but triggering now
<pitti> tkamppeter: don't bother about avahi-utils MIR
<pitti> tkamppeter: the source is already in main, I promoted avahi-utils some hours agao
<pitti> ago, even
<pitti> well, not that long ago, but it should move to main in an hour or two
<pitti> ogra: ltsp> yay no i386 kernel any more \o/
<ogra> pitti, well, lets see how that turns out :)
<ogra> on the 10 thin clients i have tested here it worked ... but i'm still ready to roll back
<tkamppeter> pitti, too late, I completed the MIR now. How did you see that I was working on it?
<pitti> tkamppeter: I'm subscribed to all MIR wiki pages
<pitti> tkamppeter: also, please don't use the UbuntuMainInclusionQueue wiki page any more; see the comment at the top
<tkamppeter> pitti, then you have seen it only in the moment when I completed it (triggered by my saving of the page). So I know that this one is done for Hardy.
<pitti> StevenK: cron.NBS finished
<StevenK> pitti: Thanks, I refreshed about a minute ago and saw that it was updated.
<tkamppeter> pitti, I have read https://wiki.ubuntu.com/UbuntuMainInclusionRequirements, this page is obsolete then, it either needs to be updated or removed and linked to https://wiki.ubuntu.com/MainInclusionProcess.
<pitti> tkamppeter: oops, thanks; someone added the steps to the Requirements page, which is wrong; fixing, thanks
<tkamppeter> pitti, one suggestion to simplify the MIRs: As we now announce them via bug reports, why not do away with the Wiki pages for the MIRs and putting the MIRs directly as initial description of the bug reports.
<pitti> wiki is easier to edit and for long-term keeping
<pitti> and for including links, etc.
<tkamppeter> pitti, the initial description of a bug report can also be edited and it can also contain links. Also closed bug reports are not deleted. If one leaves them subscribed to ubuntu-mir one can still all the time find them (by searching closed bugs subscribed to ubuntu-mir).
<StevenK> pitti: Oh yes. Look at the gem I found earlier today: http://paste.ubuntu.com/3363/
<asac> pitti: not sure if i noticed that .... let me try
<pitti> asac: it's bug 175904, I just confirmed it
<ubotu> Launchpad bug 175904 in firefox-3.0 "Firefox-3.0 window moves to current workspace" [Medium,Confirmed] https://launchpad.net/bugs/175904
<pitti> StevenK: WTH is that??
<StevenK> pitti: A script called package.sh I found in a tarball -- it looks to build a .deb by hand.
<asac> pitti: indeed
<asac> thats fun ;)
<StevenK> pitti: I nearly choked on my tea.
<Mithrandir> StevenK: win.
<StevenK> Mithrandir: Oh yes.
<thom> it's cross platform!
<thom> obviously much better than this crappy os specific system we've adopted
<pitti> StevenK: *cough*
<StevenK> thom: Bah
 * thom is not at all bitter about the fact that work uses something very similar for our java packages
<thom> honest
<pitti> tjaalton: vmmouse built/uploaded now
<pitti> asac: do you plan to switch to ffox 3 by default for alpha-3 or after?
<StevenK> Gahh. Scons in Hardy looks busted
<StevenK> Well. More busted. :-P
<asac> pitti: I planned to start that after alpha-3
<ScottK> pitti: Agreed that amavisd-new will need a much closer look than these Perl modules.  I think it's a hopeful sign that many of the security issues (rare as they are) that existed against the Perl libraries were identified by the primary amavisd-new developer
<siretart> Riddell: okay, so you want me to upload a xine-lib_1.1.9-0ubuntu1 RSN?
<siretart> Riddell: I mean, the packaging is ready in our hg branch
<Riddell> siretart: yeah, that would be handy
<asac> pitti: bug 180628 ... flashplugin on amd64 appears to be broken because of that
<ubotu> Launchpad bug 180628 in ia32-libs "[Hardy wishlist]libsepol1 and libselinux1 needed to run skype 2" [Wishlist,Confirmed] https://launchpad.net/bugs/180628
<nenolod> asac, duplicate of 180478
<asac> bug 180478
<ubotu> Launchpad bug 180478 in ia32-libs "pulseaudio support, broken nspluginwrapper/flash" [Undecided,New] https://launchpad.net/bugs/180478
<nenolod> i missed sepol1
 * nenolod updates description
<tjaalton> pitti: great, thanks
<pitti> mvo_: oh, new update-notifier icons, eh? :)
<StevenK> They're blue now?
<pitti> mvo_: now I have an alert triangle which doesn't want to go away; what does it want to tell me?
<mvo_> pitti: what does the tooltip say?
<Hobbsee> pitti: it's got an update
<dholbach>  http://people.ubuntu.com/~dholbach/sponsoring/  PING!
<mvo_> pitti: not really new icons, but more consistent icon theme usage
<pitti> Hobbsee: that was the explosion-like thingy
<Hobbsee> pitti: oh wait, alert triangle is it thinks it's out of date, as it's got a broken package
<pitti> mvo_: right, it says it's out of date; two packages cannot be upgraded
<Hobbsee> (which stays there indefinetly, till you fix it by apt)
<persia> pitti: I'd like to defer to you for bug #177175, as I have only a weak understanding of python.
<ubotu> Launchpad bug 177175 in python-distutils-extra "FAQ mentions "build_l10n", but it is actually "build_i18n"" [Low,Triaged] https://launchpad.net/bugs/177175
<siretart> Riddell: ok, I've added it to my todo list for today
<pitti> persia: well, it's just a typo in the FAQ file :)
<StevenK> Hobbsee: The triangle is adept's icon for updates, by the way.
<mvo_> pitti: do you have broken packages? or is /var/lib/apt/lists/periodic not touched in a while?
<persia> pitti: True.  There's also the bit about me not being able to upload directly :)
<Hobbsee> mvo_: when i saw it earlier, it was broken packages.  pitti answered that earlier too
<pitti> mvo_: yes, there is libhsqldb and some xorg packages which don't upgrade
<Hobbsee> StevenK: ah right
<pitti> persia: I hope that Sebastian will just fix it upstream
 * Hobbsee adds to her gripes of update-manager
<persia> dholbach: mind if the assignment for that gets changed?
<mvo_> Hobbsee: I think its ok if it tells you about broken packages
<Hobbsee> mvo_: yes, but surely it's got a little of a strange error message for it
<dholbach> persia: assignment?
<mvo_> pitti: packages not upgrading != broken packages. if it tells you that its out of date, then that is a new feature that is meant to nag^Whelp people
<Hobbsee> mvo_: why doesn't it let you install new packages to satisfy the current one's depends, like i believe apt's safe-upgrade does?
<Hobbsee> mvo_: sure, but 10 mins doesn't mean out of date.
<pitti> mvo_: it nags me when my package index is (OMG!) 20 minutes old?
<persia> dholbach: "Responsible" in your sponsoring page, for python-distutils-extra
<dholbach> persia: hm, what do you want me to change?
<persia> dholbach: Oh.  Right.  That's autogenerated.  Do we just subscribe the person who would fix it upstream?
<mvo_> pitti: no, it shouldn't nag for 20min (7days currently)
<dholbach> persia: I think that'd be glatzor
<Hobbsee> mvo_: iz bug.
<pitti> mvo_: right, apt-get update, now it's gone
<persia> dholbach: Me too, I'm just asking about procedure :)
<mvo_> Hobbsee: that is one of the things I want to fix, its currently whining instead of helping when broken dependencies are discovered
<Hobbsee> mvo_: my other gripe - why wait for someone to hit close on the "updates are done" dialog, and then close on the original dialog?
<mvo_> pitti: there might be a transient problem, the new apt-get from yesterday was required to make it reliable enough
<Hobbsee> why not only show an error dialog, and shut up and leave me in peace if it all worked fine?
<dholbach> persia: yeah, that's fine
<mvo_> Hobbsee: fixed in bzr, I think this can be uploaded today
<Hobbsee> (and why does it keep insisting on stealing focus, even between "iv'e downloaded everything" and "i'm starting to unpack"
<tkamppeter> why is bug 180628 a duplicate of bug 180478, at least the ia32-libs task should not be a duplicate.
<ubotu> Launchpad bug 180628 in ia32-libs "[Hardy wishlist]libsepol1 and libselinux1 needed to run skype 2 (dup-of: 180478)" [Wishlist,Confirmed] https://launchpad.net/bugs/180628
<ubotu> Launchpad bug 180478 in flashplugin-nonfree "pulseaudio support, broken nspluginwrapper/flash" [Undecided,Won't fix] https://launchpad.net/bugs/180478
<mvo_> Hobbsee: for the focus stealing I blame metacity/compiz
<StevenK> Which is your problem too!
<StevenK> Enjoy!
<Hobbsee> mdz: quick ping?
<mdz> Hobbsee: yes?
<Hobbsee> mdz: any chance you can renew my membership of launchpad-buildd-admins?  it appears i'm the only one on an expiring membership.
<mdz> Hobbsee: fixed
<Hobbsee> mdz: thanks muchly.
<ogra> pitti, slangasek, do you plan to do a test iso today already ? i'd like to test ltsp inclusion a bit in advance
<ogra> (for ubuntu alternate)
<pitti> no idea, I haven't planned it personally
<ogra> well, i have access and can do one myself
<ogra> i just dont want to get into anyones way
<Hobbsee> ogra: slangasek is a scary beast.  he'll come and decapitate you.
<ogra> pfft, who needs a head
<Hobbsee> he might remove your fingers, too
<ogra> eek, then i need to build my brain to Pc interface first
<Hobbsee> where do you keep your brain then?
<ogra> separate USB case indeed
<Hobbsee> ahh
<lamont> slangasek: I thought gcc-3.4 had the same issue... :-)
<ogra> probably firewire as its a tad faster :)
<nenolod> whose oliver grawert?
<ogra> lamont, another friendly poke about bug 179130 :)
<ubotu> Launchpad bug 179130 in livecd-rootfs "Typo in argument parsing and unknown sanitize command" [Undecided,New] https://launchpad.net/bugs/179130
<ogra> nenolod, me
<Hobbsee> nenolod: a scary person.  you don't want to go near him.
<nenolod> ogra, you completely misunderstood bug 180478
<ubotu> Launchpad bug 180478 in ia32-libs "pulseaudio support, broken nspluginwrapper/flash" [Undecided,New] https://launchpad.net/bugs/180478
<ogra> lamont, do you have the sanitize command anywher or shall i just drop it ?
<nenolod> ogra, and triaged it in a way that has made me not happy. :(
<ogra> nenolod, did i ?
<ogra> nenolod, well, its a bug in flash, not in ia32-libs
<nenolod> ogra, bug 180478 is a bugtask i opened for working towards making libflashsupport usable in 64bit userland
<torkel> Hobbsee: with head, body and fingerar separated he can't be that scary :-)
<nenolod> ogra, as such, it's a bug in ia32-libs, as i need additional libraries added to accomplish this.
<ogra> and the only way to work around it until adobe fixes it is libflashsupport atm
<nenolod> ogra, which does not work on amd64 because ia32-libs is missing the needed libraries
<nenolod> ogra, which is what bug 180478 is about
<ubotu> Launchpad bug 180478 in ia32-libs "pulseaudio support, broken nspluginwrapper/flash" [Undecided,New] https://launchpad.net/bugs/180478
<ogra> nenolod, feel free to revert it i'm not the ubergeek here :) i just happened to take care of libflsahsupport and pulse for the last few releases (due to its usage in ltsp since edgy)
<nenolod> ogra, as for libflashsupport, that's next on my hitlist
<nenolod> ogra, but i have to get ia32-libs fixed first
 * Hobbsee kills this right-click share folder thing
<Hobbsee> Could not apply changes!
<Hobbsee> Fix broken packages first.
<Hobbsee> there are no broken packages, you silly dialog.
<nenolod> ogra, i have debian/rules tweaks done, but, i need ia32-libs fixed in order to build a working binary which can be loaded by the flash plugin on amd64.
<nenolod> ogra, once i have these two things, i'll send a debdiff your way, ok? :)
<ogra> sure
<ogra> my ltsp users will be happy to get something better than gnash on amd64 (even thogh that seems to be pretty stable)
<nenolod> ogra, and sorry if i seemed a little cross on the bug, but to my eyesit looked like "oh hey some crackhead screwed over my bugtask"
<nenolod> ;)
<Hobbsee> nenolod: it happens.
 * Hobbsee still has to lart a guy about the same thing
<ogra> dont worry, i'm only human as others (excluding Hobbsee who is a ghost) so i make mistakes or misread stuff :)
 * Hobbsee is a green alien, tyvm!
<nenolod> no, Hobbsee is the flying spaghetti monster
<nenolod> ;)
 * Hobbsee throws cjwatson_ at ogra
<nenolod> which reminds me
<ogra> Hobbsee, he'll jump on me early enough anyway ;)
<nenolod> pitti, do be sure to look at bug 180478
<ubotu> Launchpad bug 180478 in ia32-libs "pulseaudio support, broken nspluginwrapper/flash" [Undecided,New] https://launchpad.net/bugs/180478
<nenolod> so that people will stop complaining about flash
<nenolod> :D
<Hobbsee> ogra: why so?
<ogra> he's my boss
<Hobbsee> oh, right
<lamont> ogra: just drop 'sanitize' if infinity doesn't know what/where it is... I don't have a copy that I can find
<cjwatson> geser: thanks for the fakeroot fix; sorry I was on holiday and didn't get to it
<siretart> can someone from the TB check bug #181244
<ubotu> Launchpad bug 181244 in libcdio "libcdio GPL/license violation" [Undecided,New] https://launchpad.net/bugs/181244
<cjwatson> Hobbsee: what am I supposed to land on ogra for?
<ogra> lamont, thanks
<Hobbsee> cjwatson: because he makes mistakes.  you were a good target.
<Hobbsee> er, a good missile.
<cjwatson> soren: I've released debconf 1.5.18 and synced it into hardy; thanks for the reminder
<soren> cjwatson: :)
<pitti> tkamppeter: s-c-p uploaded
<cjwatson> pitti,slangasek: d-i uploaded for 2.6.24-3 kernels
<pitti> cjwatson: cheers
<shaya> anyone else having java crashes in xcb?
<soren> mvo_: We agreed bug 180105 was fixed by the most recent kvm upload, right?
<ubotu> Launchpad bug 180105 in kvm "unhandled vm exit" [Undecided,New] https://launchpad.net/bugs/180105
<mvo_> soren: yes
<mvo_> soren: well, I agreed :)
<soren> mvo_: Great. Thanks.
<soren> mvo_: That's good enough for me :)
<seb128> shaya: I think that's a known issue, maybe ask on #ubuntu-x for the bug number
<Kmos> https://edge.launchpad.net/ubuntu/+source/oscache
<Kmos> http://packages.qa.debian.org/o/oscache.html
<Kmos> it now belongs to multiverse, I'm right ?
<gaspa> freeflying: you assigned to yourself bug #103492, can i take care of the feisty part, instead?
<ubotu> Launchpad bug 103492 in scim-bridge "[can-not-install] file overwrite error" [Undecided,In progress] https://launchpad.net/bugs/103492
<Kmos> pitti: ?
<soren> Kmos: Er.. why?
<Kmos> soren: it's now in contrib/libs at debian and currently FTBFS in hardy at universe
<Kmos> it also needs glassfish-javaee, that's in multiverse
<soren> Right.
<soren> Yeah, it should probably get demoted.
<dholbach> Kmos: it ftbfs because libhibernate3-java is missing
<dholbach> libhibernate3-java should go into multiverse it seems
<Kmos> dholbach: and also needs libjgroups-java
<seb128> dholbach: multiverse packages can build-depends on packages in main and universe
<dholbach> seb128: right... in this case it's a package build-depending on something in multiverse
<geser> seb128: libhibernate3-java is in debian contrib so multiverse would by the right component
<Kmos> I have another one.. but should be moved to universe.. bug 181083
<ubotu> Launchpad bug 181083 in checkstyle "Please move checkstyle from multiverse to universe" [Wishlist,New] https://launchpad.net/bugs/181083
<seb128> geser: I didn't discuss that ;-)
<seb128> open bugs and subscribe ubuntu-archive
<seb128> no need of IRC pings those are processed often enough
<Kmos> just to make sure about it =)
<calc> can someone take openoffice.org out of manual depwait on the various archs, its depends are now in main
<geser> calc: shouldn't that happen automatically?
<calc> geser: i don't think it does when it is in 'manual depwait
<calc> vs automatic depwait
<geser> calc: afaik there is no automatic depwait
<geser> all packages waiting on other packages automatically get into manual depwait
<geser> and also out of it
<calc> oh i thought there was, maybe it will retry on its own, but i am not certain
<Kmos> it will retry automatically on manual depwait. I asked that a days ago to pitti =)
<calc> well it says it did retry today after jfreereport was moved to main but that it was depwait on jfreereport...
<calc> maybe it retried before the packages file was updated or something odd like that
<geser> calc: I see libjfreereport-java is an arch:all package. perhaps it got eaten by bug #178102. I can't check here
<ubotu> Launchpad bug 178102 in soyuz "(Pro|De)motion loses arch: all binaries" [Critical,Fix committed] https://launchpad.net/bugs/178102
<calc> geser: oh ok
<dballester> hi to all
<calc> fun stuff
<dballester> may be off-toppic but I'm experimenting an 'strange' behaviour when resizing emulated terminal windows ( both compiz/emerald and metacity )
<dballester> via shell script I open an interactive ssh connection, runs ook until i resize the window ( I can minimize and restore without problems ). When I resize, the shell script dies
<dballester> someone has pointed that maybe is something related to SIGWINCH signal ( http://en.wikipedia.org/wiki/SIGWINCH )
<soren> Maybe it doesn't deal very well with SIGWINCH
<geser> calc: can you check on drescher(?) if libjfreereport-java is still listed by dak ls?
<dballester> maybe soren but at least, is a basic shell script and is strange for me that this problem ( if it's really a problem ) did not raise before
<zul> have you tried without compiz?
<dballester> zul, yes
<dballester> and same result
<dballester> well, in fact, is not a ssh connection, is a ssh connection called via script command
<dballester> may be is /usr/bin/script falling
<dballester> i will try to make the true ssh connection without the script command
<Kmos> ffig # pitti, does not work with current ghc, request of upstream author, LP#134037
<dballester> seems that using ssh directly runs well
<Kmos> the package misdn-user shouldn't be blacklisted, like misdn-kernel package ?
<dballester> zul, soren thanks for your tips, they gided me to the root of the problem
<dballester> http://marc.info/?l=util-linux-ng&m=119157164704789&w=2
<dballester> thanks again
<dballester> i've downloaded the source code for util-linux-ng v 2.13.1, may i obtain the debian package dialog to create a deb package from this source?
<geser> cprov: can you check if libjfreereport-java and libjfreereport-java-doc got eaten today by bug #178102 (libjfreereport got promoted today) and resurrect them?
<ubotu> Launchpad bug 178102 in soyuz "(Pro|De)motion loses arch: all binaries" [Critical,Fix committed] https://launchpad.net/bugs/178102
<cprov> geser: yes, it was eaten. But /no/ I can't resurrect them right now.
<Kmos> geser: ask infinity =)
<jdong> can I beg an archive manager to clear the NEW queue? (primarily mpeg4ip)
<jdong> a good chunk of the media stack is waiting for that
<seb128> jdong: I'll have a look later today if nobody else does it before
<jdong> seb128: thanks in advance :)
<infinity> ScottK: Around?
<ScottK> Yes
<ScottK> infinity: ^^
<infinity> ScottK: Regarding your -devel thread.  I just had a private conversation, using kmos as a wall to bounce some bug-fix ideas off of, and I'd really rather fix the perl-modules/sbuild thing in sbuild.
<infinity> ScottK: This "bug" will crop up again in the future, and I think forking perl-modules harder and harder each time isn't really the answer.
<ScottK> infinity: I agree that's the best way to solve the build problem.
<ScottK> There's still a code duplication problem even if sbuild is fixed.
<ScottK> There's also a ~1 month until feature freeze and there's stuff I want to get into Main for Hardy that can't be build right now problem.
<ScottK> infinity: What would be the timeline for an sbuild solution?
<ScottK> build/built
<infinity> ScottK: which code duplication problem is that?
<infinity> ScottK: Anyhow, I'm looking at fixing it sometime this week.
<ScottK> Currently we have two copies of several perl modules in the archive.
<ScottK> That sounds great.
<ScottK> There's one copy in perl-modules and another (generally newer) copy in a separate package
<ScottK> Not the ideal way to run a railroad.
<infinity> ScottK: Yes, this has happened historically for ages.  Perl policy not only allows it, but makes sure it "Just Works".
<ScottK> OK.  So absent the sbuild problem that's the way it's supposed to be?
 * ScottK knows more about Python policy than Perl.
<infinity> Yeah, perl and python modules routinely bounce between separate and bundled packages.
<infinity> Typically, they go the other way (external -> bundled), which is why sbuild behaves the way it does.
<ScottK> Makes sense
<infinity> But I'm pretty sure I can fix it to DTRT, regardless of the direction of the move.
<infinity> (This is where kmos made a good wall to bounce from)
<ScottK> That'd be great.
 * ScottK is more used to trying to bounce kmos off a wall, but whatever works for you.
<ScottK> infinity: Thanks.  I'll hold off on ripping perl-modules apart and go on on the assumption that sbuild will get solved shortly.
<infinity> Well, the whole point of a wall is just to have somone go "mmhmm, mmhmm" as you describe possible solutions.
<infinity> I used to use my cat.
<Kmos> ScottK: lol
<infinity> Now I don't have a cat. :(
 * ScottK wasn't particularly kidding.
<Kmos> infinity: I need to give you one =)
<Spads> infinity: you could just visit http://icanhascheezburger.com/ and tell all your problems to the images there
<jdong> infinity: the same works with dolls actually
<infinity> jdong: TMI.
<jdong> infinity: sometimes I use my little sister's stuffed animals to explain NADP phosphorylation...
<jdong> it kinda looks strange I guess
<jdong> I need a pet...
<LaserJock> ...
<geser> calc: you need to wait till the eaten jfreereport packages find their way back into the archive for the openoffice.org build to start
<seb128> ogra: how busy are you today?
<mvo_> slangasek: how deeply frozen is main currently? are uploads like vte still ok ? or will it disrupt your work
<seb128> mvo_: standard updates should be alright
<mvo_> thanks seb128
<seb128> mvo_: well, that's only my opinion, not an authoritative response ;-)
<slangasek> yes, as long as you're uploading vte for a good reason, that should be ok
<mvo_> is "new version" a good enough reason ?
<mvo_> oh, it also fixes bugs :)
<seb128> mvo_: having GNOME uptodate is always a good reason ;-)
 * mvo_ hugs seb'sebmaster'128
 * seb128 hugs mvo_
<slangasek> ogra: there should be isos available already today that you can test; they won't have the new d-i yet, but I suppose that's not relevant for your test?
<ScottK> slangasek: You'll be glad to know that Samba has been certified secure, so you can relax: http://www.news.com/8301-10784_3-9843682-7.html?tag=nefd.top
<evand> ...php is on that list.
<DarkSun88> Hi all
<slangasek> evand: that just means that whatever part of php they tested doesn't have any buffer overflows ;)
<evand> heh
<slangasek> (... OpenPAM?  WTF)
<ogra> slangasek, well, i need the ltsp builder udeb which i added to the seed around 12:00 UTC ... the current isos are from last night ... but i think i can wait until tomorrow
<slangasek> ogra: oh.  well, we could probably use a fresh build today anyway; ubuntu alternate is the one you're looking for?
<slangasek> The following packages have unmet dependencies:
<slangasek>   xserver-xorg-core: Conflicts: xserver-xorg-video-1.0
<slangasek> tjaalton: ^^ is this you? :)
<ogra> yep, ubuntu alternate is the one
<bigon> could someone make a give-back for decibel?
<slangasek> tjaalton: xserver-xorg-video-chrome Provides: xserver-xorg-video-1.0 instead of xserver-xorg-video-2
<slangasek> tjaalton: s/chrome/openchrome/, of course. so either the Provides: needs changing (if it's ABI compatible) or the package needs updating some other way?
<slangasek> ogra: so the above xserver conflict is going to make any CDs I reroll somewhat unusable until they're fixed; you should probably go ahead and plan for very late tonight, or just tomorrow
<infinity> bigon: Done.
<bigon> infinity: thx
<ogra> slangasek, yeah, i was already planning to ... i would anyway only have started a vbox install before going to bed something i can easily do tomorrow morning as well
<slangasek> ok
<tjaalton> slangasek: really? I've changed that once already
<tjaalton> I'll fix that if the change was dropped
<slangasek> yeah, must have been dropped
<tjaalton> slangasek: also, xorg-server merge is ready. a new git pull from upstream stable branch, and of course the patch to use openchrome instead of via
<tjaalton> that's the last upload I have
<tjaalton> for alpha3
<slangasek> landing a little late if you're aiming for alpha3, isn't it? :)
<slangasek> 2:1.4.1~git20071212-1ubuntu2 2:1.4.1~git20071212-2 2:1.4.1~git20071212-1
<slangasek> these version numbers give me a headache
<slangasek> but I guess you weren't referring to a Debian merge anyway
<tjaalton> a little, yes :)
<tjaalton> I can just add the patch to the current package if that's ok
<slangasek> that would be my own preference since we're starting to take a bite out of our testing window
<tjaalton> ok, I'll do that
<slangasek> thanks
<tjaalton> the changes in the new version were minimal anyway
<slangasek> oh, well, if you think that's the better option still, go for it
<ScottK> slangasek: Another solution to my perl-modules problem would be to update hardy to Perl 5.10.  It's got perl-modules in sufficient version to fix the problem packages that have been identified so far.
<ScottK> Of course actually fixing sbuild will be really cool.
<slangasek> ScottK: heh.  well, there's talk of perl landing in sid soon, but I don't know exactly when
<Mithrandir> 5.10 is in experimental, but not unstable yet.
<ScottK> As I understand it 5.10 is now 'released'.
 * ScottK wonders how supportable Perl 5.8 will be 5 years from now with 5.10 already released.
<slangasek> Mithrandir: yes, bod was on IRC yesterday asking about binNMUs for everything using perlapi-5.8.8
<ScottK> I'd imagine that's a lot of rebuilding.
<slangasek> only 208 binary packages
<Mithrandir> not too bad, then
<teprrr> hi and excuse me, but can anyone point me where to find the changelogs of the packages?
<tjaalton> slangasek: in total six upstream commits, of which one was already included as a patch.. ok, I'll upload the merge then, thanks!
<teprrr> without installing the package first and then looking if it has a changelog..
<ScottK> teprrr: Look for the package on packages.ubuntu.com  There's a link to debian/changelog
<teprrr> ScottK, ahh. thanks
<tjaalton> slangasek: xorg-server & openchrome uploaded
<slangasek> tjaalton: cheers
<slangasek> TheMuso: you say that the -rt metapackages and restricted-modules are needed for UbuntuStudio alpha3, but weren't they missing for alpha2 already?
<TheMuso> slangasek: Yes they were, but the metapackages are more important than LRM atm I think.
 * cjwatson looks puzzledly at http://launchpadlibrarian.net/11220812/buildlog_ubuntu-hardy-i386.openoffice.org_1%3A2.3.1-1ubuntu1_MANUALDEPWAIT.txt.gz
<cjwatson> E: Couldn't find package libjfreereport-java
<cjwatson> but:
<cjwatson> libjfreereport-java | 0.9.0-05-4 |         hardy | all
<cjwatson> that build is just half an hour old, and according to the bug jfreereport was promoted 13 hours ago
<Kmos> cjwatson: bug 178102
<ubotu> Launchpad bug 178102 in soyuz "(Pro|De)motion loses arch: all binaries" [Critical,Fix committed] https://launchpad.net/bugs/178102
<cjwatson> ah, just cherrypicked a few hours ago; that would explain why the publisher is stopped
<cjwatson> Kmos: thanks
<Kmos> np :)
<infinity> cjwatson: The publisher is stopped for other insidious reasons, see #soyuz.
<ScottK> #canonical-soyuz
<slangasek> #ÑÐ¾Ð¹ÑÐ·
<ion_> :-)
#ubuntu-devel 2008-01-09
<Kmos> http://linux-foundation.org/weblogs/openvoices/linus-torvalds-part-i/
<hunger> Running htop I see ~70 console-kit-daemons running... I guess that is due to htop not noticing multithreading. Isen't that a bit excessive?
<tjaalton> slangasek: actually, there's need for one more upload.. openchrome lacks a patch to extract pci-ids in a text file, but fortunately the patch for via applies and works..
<slangasek> tjaalton: ok.  at least it's now installable, so we can move ahead with test images :)
<tjaalton> sure
<tjaalton> I can put it on hold until tomorrow if needed?
<slangasek> as long as that's the only change you're making, it doesn't sound like it would disrupt anything, and it would certainly help get better feedback from openchrome users on the alpha
<slangasek> so please go ahead
<tjaalton> ok, thanks
<Sefram> why is the Gusty installer CD olny working with the pnpacpi=off option as a boot parameter on my machine?
<Sefram> any ideas?
<Sefram> without pnpacpi=off i get an error about 8139cp is not right for my RTL-8139C PCI network card and that i should use 8139too instead??
<Burgundavia> Sefram: no idea, but file a bug
<cjwatson> ... on the kernel (linux-source-2.6.22 package)
<Sefram> what have i to regard while installing when it works only with pnpacpi=off??
<Sefram> i got the tip from here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/22575   seems to be an address ressoure conflict in pci address space...
<ubotu> Launchpad bug 22575 in linux-source-2.6.15 "ISAPNP grabbing I/O region reserved for PCI device on 2.6.12  (regression from 2.6.10)" [Medium,Confirmed]
<Sefram> Ubotu: smarty lol
<ubotu> Sorry, I don't know anything about smarty lol - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<calc> Hobbsee: does chrootwait go away automatically?
<Hobbsee> calc: not necessarily
<calc> Hobbsee: hmm can you fixup openoffice.org to retry, i think the reason it failed was due to the archive being updated when it tried to build
<calc> unless something really did break the chroot's due to unauthenticated debs?
<Hobbsee> calc: given back
<calc> ok
<calc> Hobbsee: thanks :)
 * Hobbsee wonders what the chroot problem actually is
<slangasek> I wouldn't be surprised if it was just a case of the mirror being in an inconsistent state due to having to futz around with the rsyncing and so forth
<bddebian> slangasek: Hey, I have a new asc upstream in games SVN if you'd rather upload that? :)
<_MMA_> Does the package gdm 2.20.2-1ubuntu2 include the changes from upstreams 2.20.3 release?
<alephant> Please forgive my being slightly off-topic: How are updates to packages indicated to apt?  Is there a datastream which sez "foo-1.2 upgraded to foo-1.3"?  Or does apt simply compare the most-recent copy of the package as indicated by Packages.bz to the locally-installed package?
<slangasek> bddebian: mutter mumble if someone would fix paragui then we could upload asc to Debian and sync it...
<bddebian> slangasek: What's up with paragui?
<slangasek> bddebian: it ships a .la file that has references to a crapload of other .la's that it doesn't depend on
<bddebian> Ah the SDL "team" :)
<slangasek> bddebian: and indeed, the asc upload FTBFS on all archs because of this, so sure, I'll take a new upstream that I can sync after
<bddebian> Hmm, 2.0.1 didn't FTBFS on unstable for me
<bddebian> asc 2.0.1 that is
<slangasek> the build failures are entirely paragui's fault
<slangasek> well - no, the latest one is my fault, because I didn't verify first that directfb-dev still ships a.la
<StevenK> Which it doesn't
<slangasek> yes, which is why things Broke
<emgent> launchpad died
<slangasek> bddebian: so where's this asc package that needs sponsorin'?
 * bddebian does another build of asc out of curiosity
<bddebian> slangasek: I just removed it from mentors
<bddebian> Damnit, now it's puking trying to pull in libbz2-dev
<bddebian> I have another issue while my pbuilder updates.  I've built a new stormbaancoureur.  However, one file (engine.tga) is rendered from a 3D model that the author purchased.  He claims he has copyright but is that possible?
<bddebian> F**k, is libbz2-dev broken now too?
<lifeless> bddebian: its possible and there is no way to tell; have him assert the appproporiate copyright statement and you're good
<slangasek> bddebian: it wouldn't ftbfs on unstable because the paragui binaries in unstable were built against a good libsdl, and the ones in hardy were built against a bad libsdl
<slangasek> libbz2-dev... broken how?
<slangasek> installed cleanly for me
<bddebian> uninstallable in my sid pbuilder
<StevenK> The libsdl in Hardy is bad?
<slangasek> not anymore
<slangasek> all about the Timing!
<bddebian> libparagui is in universe still?
<slangasek> it should be somewhere else?
<bddebian> Hmm, and 1.0 or 1.1? :)
<slangasek> well, 1.0 is the one it's been building against, beyond that I have no idea
<bddebian> I wonder if 2.0.1 would build against 1.1
<bddebian> Gah wtf, libbz2-dev installs fine if I pbuilder-login
<LaserJock> hmm, should the topic be changed for the Alpha 3 freeze?
<bddebian> E: Failed to fetch http://ftp.debian.org/debian/pool/main/b/bzip2/libbz2-dev_1.0.4-1_i386.deb: 404 Not Found
<bddebian> E: Unable to correct for unavailable packages
<bddebian> gaaahh
* slangasek changed the topic of #ubuntu-devel to: Archive: main soft-frozen for Hardy Alpha 3 | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> LaserJock: yes, thanks :)
<emgent> keescook, ping
<LaserJock> slangasek: np ;-)
<keescook> emgent: pong
<emgent> keescook, wordpress diff 2.1 is ready
<keescook> emgent: cool, make a bug report for it and get it attached.  nice work.  :)
<emgent> ok thanks :)
<slangasek> bddebian: libparagui1.0 fixed, so where did asc go after it was removed from mentors?
<bddebian> slangasek: I'm throwing it back on mentors as I type
<bddebian> I can't test build in on unstable though for whatever the fsck is going on with my pbuilder. (I switched the build-deps to libparagui1.1)
<slangasek> I'm... less likely to sponsor a package with library changes that haven't been tested
<bddebian> Well I wanted to test it but I can't build it.  I can switch it back if we want to get it in
<slangasek> switching it back would be good if you want me to look at sponsoring it; otherwise I can just get the already-uploaded asc given back on the buildds to take care of the bug I was after
<bddebian> Let me switch it back.  I've been trying to get this in forever
<bddebian> pabs3: !?
<pabs3> hi bddebian :)
<bddebian> Man, I can't hide anywhere anymore :)
 * pabs3 was wondering who to contact about patches.ubuntu.com
<pabs3> :)
<bddebian> pabs3: lifeless suggested we might get away with the engine.tga thing in stormbaancoureur if he provides copyright.  Would you disagree?
<pabs3> that'd be offtopic here, perhaps #debian-games is better?
<pabs3> about patches.ubuntu.com, would it be possible to remove changelog-only patches? for eg http://patches.ubuntu.com/s/synfig/synfig_0.61.07-1build1.patch
<bddebian> Oh, build1 versions aren't really patches, just rebuilds
<pabs3> yeah, but they do show up on packages.qa.d.o, which can be annoying when I go to check for a patch and find it only bumps the changelog
<bddebian> Ah yes, makes sense
<bddebian> slangasek: http://mentors.debian.net/debian/pool/main/a/asc/asc_2.0.1.0-1.dsc
<slangasek> bddebian: downloading gradually
<bddebian> NP, I gotta get my old arse to bed anyhow
<sam__> can any one guide me in streaming??
<calc> how do i search for a file in hardy?
<calc> there are still no contents files?
<calc> i'm getting this error: /usr/include/mono-1.0/mono/metadata/threads.h:17:41: error: mono/metadata/threads-types.h: No such file or directory
<calc> and need to know where that file is
<sam__>  i am getting RTSP/1.0 461 Unsupported Transport from rtsp server ..?????
 * calc wonders if libmono-dev is just fscking buggy
<calc> yep mono is a just buggy
<calc> pochu: ping
<calc> pochu: bug 181422
<ubotu> Launchpad bug 181422 in mono "thread-types.h is missing" [High,New] https://launchpad.net/bugs/181422
<dholbach> good morning
<sam__> i guess no one wanna help me ... ok..
<torkel> sam__: wrong channel for that kind of question, try #ubuntu
<pitti> Good morning
<emgent> pitti, good morning :P
<pitti> hi emgent!
<hunger> The hardy gcc gets an ICE when building kdeedu her.
<viviersf> is there anywhere i can get a list of all packages are used for the live cd ?
<pochu> calc: pong, looking
<evand> viviersf: http://cdimage.ubuntu.com/daily-live/current/hardy-desktop-i386.manifest
<viviersf> evand, the manifest is ubuntu-desktop + live cd components
<pitti> calc: OO.o FTBFS> "mcs not found" -> missign build dep?
<viviersf> evand, i need a list of just the stuff thats extra, i can do it manually, i just want to see an easy way
<pitti> viviersf: you can look at the 'ship-live' seed, but that does not include dependencies which are pulled in by those and which are not needed by ubuntu-desktop
<viviersf> pitti, cool, is that a package ?
<pitti> http://codebrowse.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.hardy/files
<viviersf> thanks pitti, that will do
<geser> good morning
<seb128> hey geser
<pitti> hi geser
<coyctecm> hey guys :)
<geser> Hi seb128, pitti
<pochu> calc: I'm merging mono 1.2.6+dfsg-5 from Debian which fixes this (in -4):
<pochu>    * debian/patches/fix_threads.h.dpatch:
<pochu>      + Don't include threads-type.h in threads.h and moved functions to the
<pochu>        correct header, fixes compiling of OpenOffice.org's Mono bridge.
<pochu>        (taken from upstream SVN revision 91687 + 91817)
<seb128> pitti: do you know if there is any hardy language pack upload scheduled?
<pitti> seb128: the guys are working on it, but I haven't heard a concrete deadline
<pitti> carlos: ?
<carlos> pitti: let me check it with jeroen...
<seb128> I'm wondering if we will ever have a cycle where rosetta is ready and language packs uploaded early ;-)
<seb128> apport is all broken here for weeks now and I was waiting for translation updates before investigating
<pitti> seb128: oh? what's wrong with apport?
<carlos> seb128, pitti: danilo is working on a small problem that affects Slovenian translations since long time ago and that requires to be fixed before opening Hardy
<Tonio_> hi there
<seb128> pitti: http://people.ubuntu.com/~seb128/Capture-apport-gtk.png
<Tonio_> is there someone here familiar with gcj/ecj packages except doko ?
<carlos> seb128, pitti: He expects to get a script run later today that should fix the data so we are ready to start with imports
<seb128> pitti: basically the text is invalid utf8
<seb128> carlos: ok, thanks
<pitti> seb128: ah, you mean the translations are broken? ok, since it works just fine here
<seb128> carlos: happy new year btw
<seb128> pitti: well, I was wondering if that's the translations or the code but was waiting on a language pack update before investigating
<carlos> seb128: same for you, did you enjoy your vacations? :-)
<seb128> carlos: yes, was nice to spend some time away from the computer ;-)
<carlos> :-D
<seb128> carlos: how was your honeymoon?
<carlos> seb128: 'short'
 * carlos hides
<seb128> ahahah, good one ;-)
<carlos> the only problem was when we went to Paris, we moved from 30 degrees to -2 degrees....
<seb128> you have been lazy enough, fix rosetta now!
<seb128> cold is better, isn't it? ;-)
<carlos> seb128: not yet, next month, this month I'm not working in translations :-)
<carlos> seb128: not really ;-)
<pitti> carlos: reminds me about my transition from vacation in Nice to distro sprint in Oslo (25 -> -12 degrees)
<carlos> wow
<carlos> that's even worse
<pitti> the guys at the airport to Nice wondered why I brought thick sweaters, gloves, scarf, etc :)
<Fujitsu> Going from Australian summer (it was 42 the day I left) to -4 is quite bad, I find.
<soren> Hm... Rhythmbox core dumps after 10.6-10.7 seconds. Every time. Very annoying.
<seb128> soren: backtrace?
<Fujitsu> soren: Regardless of what you've told it to do beforehand?
<soren> Fujitsu: Yup.
<soren> Fujitsu: Regardless of whether or not it's playing anything, too.
<soren> seb128: I'll report it with apport in a bit.
<seb128> good
<Fujitsu> It works fine for me, though at one stage I did make it segfault on start every time by disabling Cover Art.
<Fujitsu> soren: The time is seemingly arbitrary and uniform?
<soren> Fujitsu: Yup.
<soren> Fujitsu: Minimum observed: 0m10.652s, maximum observed: 0m10.702s.
<soren> Fujitsu: I've done it ~10 times.
<seb128> soren: maybe it's shocking on a file and is consistent on how long it needs to reach it
<soren> seb128: Could be. However, with 4 GB of RAM and a not too impressive music collection, I doubt it could take as much as 10 seconds to go through it.
<seb128> RAM doesn't really matter there
<seb128> that's rather IOs
<soren> seb128: WEll, if everything is cached, it does.
<soren> ..and it is. My hard drive is idling.
<seb128> it needs to go through the library to know if it changed
<soren> *drives
<seb128> weird
<Fujitsu> soren: strace isn't useful?
<seb128> send the bug using apport that will give us some idea about the crash ;-)
<soren> seb128: I'm trying... It's something like /usr/share/apport/apport-gtk -c /var/crash/_usr_bin_rhythmbox.1000.crash, isn't it?
<soren> seb128: Ah, it's just taking forever to upload, probably.
<seb128> soren: double click on the crash in nautilus
<seb128> soren: you should get the apport window about the crash before having it sending anything
<pitti> seb128: apport -c will do the same, so that's fine
<pitti> (double click is just more comfortable :) )
<soren> seb128: It tells me I should have an up-to-date system before doing anything. I'd better obey.
<soren> pitti: Well, except that you have to fire up nautilus and all that jazz first.
<soren> pitti: If you happen to have nautilus open in /var/crash anyway, then yes :)
<seb128> having a parameter to not require the uptodate system would be nice
<seb128> I often have whatever package which doesn't matter for the backtrace not uptodate
<pochu> calc: mono merge ready, but I'll have to wait for slomo to come back unless some else wants to volunteer :)
<geser> pitti: should pkg_create_dbgsym honour the -X option from dh_strip?
<geser> see bug #180364
<ubotu> Launchpad bug 180364 in ocamlnet "ocamlrpcgen no longer works on Gutsy. Probably a wrongly stripped binary" [Undecided,New] https://launchpad.net/bugs/180364
<pitti> geser: I don't think so, why?
<pitti> pkg_create_dbgsym does not strip anything off the original binaries
<geser> have you then an explanation for this bug?
<pitti> geser: not really; I think it should be tested with a local build of ocaml, both with and without pkg-create-dbgsym installed
<geser> in my pbuilder debian/tmp/usr/bin/ocamlrpcgen works as intended but the one from debian/libocaml-ocaml-bin (or the deb) doesn't
<pitti> ah
<pitti> geser: does your pbuilder have pkg-create-dbgsym installed?
<geser> when I set NO_PKG_MANGLE or add -Nlibocaml-ocaml-bin to the dh_strip call the one from debian/libocamlnet-ocaml-bin works too
<pitti> the only thing p-c-d does to the original binary is adding the .gnu.debuglink section so that gdb can find the separate symbol files
<geser> pitti: it has
<pitti> aha, then it seems it is the culprit
<geser> so adding -Nlibocaml-ocaml-bin to the dh_strip call the right fix?
<pitti> no, that just sounds like a workaround
<pitti> if it works correctly without p-c-d, we should fix the latter
<geser> I checked now where the binary breaks. Adding .gnu_debuglink breaks it.
<pitti> ugh
<pitti> but.. that's just an innocent extra elf section... *whine*
<pitti> geser: ok, does 'file <original binary>' say anything special?
<pitti> geser: or even better, can you tell that it must not be touched from the readelf -h output?
<geser> ocamlrpcgen.working: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
<pitti> ok, that's not useful then
<pitti> or an 'ocaml_bytecode' section in objdump -x or so?
<pitti> geser: I added a p-c-d task to this bug (the ocaml task is for the no-change rebuild then) and added this question
<geser> pitti: objcopy -R .gnu_debuglink ocamlrpcgen seems to be enough to break it
<pitti> geser: ok, so we must not do that then
<pitti> geser: I think the best fix is to make p-c-d not touch the binary at all if it has ocaml bytecode
<pitti> so I just need to get a good test for that
<pitti> something objdump -x binary | grep -q '\.ocaml_bytecode' like
<geser> pitti: http://members.ping.de/~mb/tmp/objdump.output
<soren> seb128: The rhythmbox bug was already reported by pochu: bug 179205
<ubotu> Bug 179205 on http://launchpad.net/bugs/179205 is private
<pitti> geser: thanks; I think I'll go with caml_release_bytecode
<pitti> geser: just for final verification: objdump -x binary | grep -qw caml_release_bytecode
<pitti> ?
<seb128> soren: alright, and it has been fixed upstream already apparently
<soren> seb128: Orly?
<seb128> soren: ?
<soren> "orly" = "oh, really"
<soren> :)
<seb128> soren: look at the upstream task on the bug
<seb128> ah, ok
<pitti> geser: is objdump -t enough?
<soren> seb128: Oh, upstream bug of the duped lp bug. Right.
<seb128> soren: no, of the non dupped bug (the one which is Fix Commited)
<seb128> but right ;-)
<geser> pitti: objdump -t ocamlrpcgen | grep -qw caml_release_bytecode exits with 0
<soren> seb128: Er.. Um.. Yes, you seem to be right :)
<pitti> geser: cool, thanks
<soren> seb128: Do you intend to upload a fix or should I do it?
<seb128> soren: you are welcome to do it since you can test the fix ;-)
<soren> seb128: Will do. It's not in bzr or anything, is it?
<seb128> soren: no, just grab the patch from svn, copy to debian/patches and upload
<soren> seb128: Alright.
<seb128> soren: http://svn.gnome.org/viewvc/ is handy to get diffs for GNOME modules
<pitti> anyone running Kubuntu here? does "x-terminal-emulator -e dpkg -l" work, i. e. runs dpkg -l in a new terminal?
<pitti> I'm not sure whether the KDE alternative of x-terminal-emulator correctly recognizes -e
<pitti> xterm and gnome-terminal do
<geser> pitti: is it intended that "objcopy -R foobar binary" modifies the binary even if the section doesn't exist? because the filesize changes from 1248876 to 269652
<pitti> geser: I'm not sure whether it's intended, but I noticed that a thing like that gets rid of a lot of cruft
<soren> seb128: Oh, I used the bzr import from launchpad instead. Thanks, though.
<pitti> at least it has done that for years
<\sh> pitti: konsole does know about -e
<\sh> pitti:  -e <command>              Execute 'command' instead of shell
<pochu> calc: do you need mono for alpha-3?
<pitti> \sh: so if you do "x-terminal-emulator -e dpkg -l" it opens a Konsole window with dpkg -l output?
<pitti> and closes it again when it's finished?)
<\sh> pitti: well, running gnome right now so I'm on gnome-terminal, but "konsole -e dpkg -l" works like a charm
<\sh> pitti: kde3 that is
<Riddell> pitti: works for me
<pitti> Riddell, \sh: great, thank you
<\sh> mvo: pingeling...did you hear about my fatal experience when dist-upgrading from dapper to gutsy via edgy/feisty?
<geser> pitti: thinking about the pkg_create_dbgsym bug again: does it make sense to want to add a .gnu_debuglink for binaries which aren't going to be stripped?
<pitti> geser: not really, no
<geser> what about passing the -X option from dh_strip to pkg_create_dbgsym to not add those links for the listed binaries as they are stripped anyway later?
<geser> this would fix it for the ocaml problem and any further binaries which don't like to be stripped
<geser> argh, there is a not missing in the first sentence: as they aren't stripped anyway later
<pitti> geser: that would work, yes; we already have a flag $nodebuglink which is passed to pkg_create_dbgsym but it only gets enabled if dh_strip builds a -dbg package on its own
<pitti> we could extend this to pass down a "don't touch" blacklist
<mvo> \sh: no, did you file a bug?
<jsgotangco> mvo!
<mvo> \sh: I would be very interessted in the logs
<mvo> hey jsgotangco
<ogra> hmm, tasksel fails on the current daily ... known fact ?
<ogra> ah, missing language-pack-en
<ogra> hmm
<\sh> mvo: there are no logs...but evms is the bug
<ogra> weird, langauge-pack-en in on the CD
<ogra> *is
<ogra> i wonder why its not found
<\sh> mvo: we used a root server from strato, dapper lts installation...and evms is installed by default, but it wasn't running...after upgrading from dapper to edgy to feisty to gutsy, our two swap spaces were not there anymore, but locked by a process, which you don't see even with lsof...
<\sh> mvo: I was fighting with it several hours, till soren told me to remove evms from the system...after that it worked...
 * Fujitsu got that on a number of systems, and thought the distupgrader was meant to handle that.
<\sh> mvo: evms on dapper is still being enabled by /etc/init.d/ and now it's got enabled with udev I think...so we need to check what happens with dapper -> hardy directly...
<mvo> \sh: could you send me the logs please (if you used the release-upgrader) - it should automatically remove evms on feisty->gutsy
<mvo> \sh: logs in /var/log/dist-upgrade/*
<\sh> mvo: I didn't ;) I used apt-get dist-upgrade
<mvo> \sh: aha, ok :)
<\sh> mvo: but I think many people dealing with debian/ubuntu on servers will not use release-upgrader ,-)
<mvo> \sh: we have a text-frontend!
<torkel> \sh: probably depends on if they know about it or are using apt-get dist-upgrade because they allways had
<\sh> torkel: that's what I meant
<mvo> \sh: I'm not a expert on the evms stuff, but afack we can not just unconditionally remove it
<mvo> \sh: we definitely need to release note it
 * mvo wonders if we have a expert on evms
<Tonio_> anyone has an idea where I can download https://edge.launchpad.net/ubuntu/+source/gcj-4.2/4.2-20070707-1ubuntu2 please ?
 * Mithrandir hides from mvo 
<\sh> mvo: if we can determine if it was in use on dapper or not .. it could help...
<Fujitsu> mvo: Release noting and perhaps modifying Dapper's apt to screech if somebody tries to do it directly...
 * mvo catches Mithrandir
<Tonio_> links are dead and since now the package build-depends on itself, this version is the only one I can use to build the package on feisty
 * Mithrandir plays dead
<\sh> mvo: if evms is being enabled by some magic variable in /etc/default/evms or something ... we could use this info during the update
<mvo> \sh: the release upgrader does that, it checks if evms is in use by looking into /proc/mounts and if not, removes it
<\sh> Fujitsu: well, as canonical explained, that dist-upgrades from lts to lts is working without any problem...it's likely to happen
 * ogra tickles Mithrandir 
 * Fujitsu stabs Mithrandir to make sure he isn't just playing dead.
<mvo> but I don't know the details, why evms causes this trouble if it is not used
<\sh> mvo: no other way possible outside dist-upgrader? some magic in udev to determine the state of evms?
<mvo> Mithrandir: is there some bugreport about this to figure what the probelm is ?
<mvo> \sh: I think if we could solve it at a package level instead of working around it in the release-upgrader, that would be the best course of action
<Mithrandir> mvo: the problem is evms tries to grab all discs and partitions whether they're evms volumes or not.
<geser> Tonio_: LP still has the debs; click on the package you need, open the "Published as" portlet, select the architecture you need, download the deb
<Fujitsu> And causes much confusion when one tries to work out why only the non-LVM /boot partition won't mount.
<Tonio_> geser: sure but I need to build this on feisty
<Tonio_> geser: that's why I really need the source package...
<Fujitsu> Tonio_: The broken links are a bug I filed a couple of weeks back.
 * Fujitsu grabs links.
<\sh> mvo, Mithrandir: I'll file a bug against emvs...(but I'm not sure if it's a bug in evms) but I wonder why evms is being used when it wasn't running at all...
<soren> Tonio_: Eh?
<soren> Tonio_: The source is right there on the page you linked to?
<persia> soren: librarian doesn't have those files :(
<Tonio_> Fujitsu: AHHHHHHHHHH, great
<Fujitsu> persia: Librarian does have those files. kiko's code is dodgy when the packages aren't published anywhere.
<persia> Err.  Right.  s/:($/At that location./
<soren> persia: Oh, right.
<soren> #  Removed from disk  on 2007-07-21.
<Mithrandir> \sh: it's being run from the initramfs
<Fujitsu> soren: The files are still in Librarian, just not on drescher.
<soren> Fujitsu: You're probably right.
<\sh> Mithrandir: hmm...more difficult
 * soren lunches
<geser> Tonio_: http://mirror.linux.org.mt/mirror/ubuntu/pool/main/g/gcj-4.2/gcj-4.2_4.2-20070707-1ubuntu2.dsc
<Tonio_> geser: thanks a lot !
<bigon> could someone makes a give-back for gossip (with libloudmouth1-dev >=1.3.3-1)
<Mithrandir> bigon: given-back
<geser> Mithrandir: is it safe to ask for give-backs of the packages in CHROOTWAIT?
<Mithrandir> geser: in general, they should be given-back automatically.  Any in particular?
<\sh> mvo / Mithrandir: bug #181491 for the evms problem
<ubotu> Launchpad bug 181491 in evms "dapper -> edgy -> feisty -> gutsy update fails " [Undecided,New] https://launchpad.net/bugs/181491
<geser> Mithrandir: if they are given-back automatically then I can wait
<bigon> Mithrandir: thx
<pitti> mvo: if I have an apt.Cache() object, is there a fast method to update it after I installed a package? (for .isInstalled) or do I need to regenerate it from scratch?
<mvo> pitti: cache.open() should do
<pitti> mvo: hm, that seems to take as long as generating a new apt.Cache()
<pitti> I used c.open(None)
<mvo> pitti: it needs to generate the binary cache after a install, it should be possible to speed it up a bit (for installs), I can look into that. you may consider showing some progress informration if that is a UI issue
<pitti> mvo: ok; no, please don't spend any effort on this, I was just curious
<mvo> pitti: ok :) I may still, I got a interessted idea that I would like to test
<calc> pochu: yea there was more wrong with OOo that I uploaded than just the missing header but I ran into that while fixing it on my box
<calc> pochu: i think it is probably too late for alpha-3 at this point :\
<cjwatson> calc: right now, openoffice.org is uninstallable in hardy; we can't release alpha-3 with it like that
<cjwatson> it needs to be fixed
<cjwatson> (one way or another)
<pitti> good morning calc
<azeem> did Ubuntu officially evaluate the Liberation Fonts license?
<azeem> mjg59: ^^ do you know, maybe?
<mjg59> Not to the best of my knowledge
<mjg59> My recollection is that it's free but GPL incompatible
<azeem> I heard today OOo upstream added the fonts recently
<azeem> mjg59: well, fonts don't need to be GPL compatible, do they?
<mjg59> Only if embedded in GPLed works
<mjg59> So, not generally
<azeem> I had a chat with aj about it earlier, as the debian-legal thread last May immediately got hijacked by nutcases
<calc> cjwatson: ok i can do the mono merge then upload new OOo that I have on my box
<azeem> so there's two exceptions, one is the official FSF-recommended font exception
<azeem> the other is some sort of anti-tivoization restriction it seems
<cjwatson> calc: what are the changes in the new OOo?
<mjg59> Yeah, I told the people involved I wasn't really happy with describing an additional restriction as an exception
<mjg59> But, still
<calc> cjwatson: very few changes mostly to deal with the way mono was split over the holidays, mono was broken over the holidays as well see bug 181422
<ubotu> Launchpad bug 181422 in mono "thread-types.h is missing" [High,In progress] https://launchpad.net/bugs/181422
<calc> pochu: ping
<calc> seems pochu didn't include his merge work for mono on the bug report :\
<azeem> mjg59: and then there is the strange IP discaimer plus "Title to the Software and any component, or to any copy, modification, or merged portion shall remain with [Red Hat]"
<mjg59> I don't have a freedom issue with that (others might)
<mjg59> But it's still weird and potentially unenforceable
<mjg59> Unless it simply means "We are still copyright holders, even if you modify it", in which case, that's kind of obvious
<broonie> But then lawyers often like pointing out the obvious.
<calc> pochu: i need the merge where is it
<calc> well he seems to not be here right now so i can look into remerging mono from debian
<geser> calc: try http://emilio.pozuelo.org/~deb/mono_1.2.6+dfsg-5ubuntu1.dsc
<calc> geser: ah great :)
<geser> that one he asked slomo to sponsor
<azeem> mjg59: if I read this right, they own the copyright of the changes I make, even if I don't distribute them; is that something Ubuntu thinks is alright?
<cjwatson> calc: ok, thanks
<ogra> cjwatson, pkgsel seems broken as well atm
<cjwatson> ogra: what's up with it? I hadn't heard
<ogra> i had a file not found with it ... let me reproduce (my virtualbox just crashed and took the kept error with it, somethig about pre-pkgsel.d being empty)
<cjwatson> hmm, sounds plausible
<calc> pochu: nevermind geser gave me the url above to sponsor :)
<mjg59> azeem: The QPL has similar issues, but I'm not sure that's what it means
<mjg59> azeem: It may well just be "Red Hat are still a copyright holder even if you modify it"
<mjg59> But clarification might be nice - RH legal are friendly people, IME
<cjwatson> ogra: odd that that would be a fatal error (rather than just syslog noise), though
<ogra> i had a proper red screen ...
<ogra> install stopped
<ogra> i'm in base-install gimme 10 min
<azeem> mjg59: do you know a good contact address for that, by chance?
<azeem> mjg59: (I thought the QPL was an issue and was mostly ignored cause all important code is bi/tri-licensed to sane licenses)
<mjg59> azeem: We still ship QPL-only code
<cjwatson> ogra: I'm rsyncing a current image, but it'll be a while
<azeem> ok
<ogra> i'll get you the syslog
<mjg59> azeem: Indeed, we *have* to ship Qt under the QPL as well - otherwise only GPL-compatible code can link against it
<ogra> its easily reproducable
<azeem> hrm, right
<mjg59> (debian-legal seem to conveniently ignore this)
<azeem> however, the QPL doesn't claim to be the GPL+exceptions
<azeem> oh well
<azeem> mjg59: anyway, thanks
<mjg59> No problem
<cjwatson> ogra: can I get syslog?
<cjwatson> my rsync is at 49%, so this is probably faster
<ogra> cjwatson, http://paste.ubuntu-nl.org/51357/
<ogra> copying the full log to p.u.c
<cjwatson> ogra: the tasksel failure is the real problem, I think
<ogra> cjwatson, http://people.ubuntu.com/~ogra/syslog
<ogra> (sorry, german)
<cjwatson> tjaalton mentioned the same error yesterday on netboot but we didn't get into it
<cjwatson> German is fine
<ogra> to me it looks more like the language pack triggers it though
<cjwatson> nah
<cjwatson> well, probably isn't helping, but being unable to find the standard task is the real blow-up I think
<cjwatson> the log ordering is a bit screwed but so it goes
<cjwatson> de.archive's Task headers look ok
<cjwatson> I wonder if the CD is screwed
<hunger> Is there a known bug wrt. creating users? I used useradd to create one and then used it to log into gnome and all I got was a white screen.
<ogra> i added the ltsp-client-builder udeb to the installer seed could it be that this broke anything (i didnt do anything additionally but adding it)
<cjwatson> hunger: you should use adduser, for starters
<cjwatson> ogra: shouldn't think so, it hasn't run yet
<ogra> right
<hunger> cjwatson: Aehm... right that is what I used:-)
<ogra> its run right after pkgsel
<ogra> (and needs preseeding to actually run)
<hunger> cjwatson: It would be cool if only one of useradd and adduser would get installed:-)
<cjwatson> hunger: since adduser uses useradd internally, I don't think that's likely
<azeem> move useradd to libexec!
<cjwatson> azeem: GNUisance ;-)
<hunger> cjwatson: Well, it is not the user creation process that gives me a white screen:-)
<cjwatson> right, my guess is that it only works if you're in some group or other - but that would certainly be a bug
<cjwatson> check .xsession-errors
<ogra> audio is a good guess i bet
<hunger> cjwatson: I testet this by deleting all the major config files of an existing user: Now I get a white screen there, too.
<pochu> calc: great. will you sponsor it for me? I pinged slomo about it, so if you are going to upload it let him know so you don't duplicate work :)
<hunger> kde starts fine by the way.
<tjaalton> pitti: I'll test the new cupsys for dapper
<pitti> tjaalton: oh, great! thanks
<cjwatson> ogra: ok, that's really weird, the CD's Packages file looks fine too
<cjwatson> I wonder if this is an apt bug
<ogra> i have the machine still here (snapshotted now)
<cjwatson> can you chroot into /target and run 'apt-get install standard~'?
<ogra> couldnt find package standard~
<cjwatson> ogra: err, sorry, I mean standard^
<ogra> ah :)
<ogra> couldnt find package standard^
<ogra> err
<ogra> s/package/task
<pochu> cjwatson: ok to upload mono 1.2.6+dfsg-5ubuntu1? (currently we have -1ubuntu1). It fixes an issue with the OOo build.
<cjwatson> pochu: yes
<cjwatson> ogra: does 'apt-cache show apparmor | grep Task:' show anything?
<ogra> unable to locate package apparmor...
<ogra> no packages found ...
<pochu> cjwatson: thanks
<pochu> calc: slomo will take care of the mono upload.
<cjwatson> ogra: ...
<ogra> looks like it doesnt find anything beyond the bootstrapped packages that are installed
<cjwatson> my head hurts, need more coffee
<ogra> hmm
<cjwatson> so certainly pkgsel arranges for only the sources added by base-installer to be used at that point
<cjwatson> (to avoid expensive downloads)
<ogra> i cant see the cdrom if i'm chrooted
<cjwatson> but base-installer seems to be doing the right thing, so I'm a little puzzled
<cjwatson> oh
<mvo> pitti: I filed bug #181518 so that we can do dapper->hardy upgrades (small patch to update-manager). this means that we need to attack the dbus restart problem soonish (before this version of u-m is accepted into dapper-proposed)
<ubotu> Launchpad bug 181518 in update-manager "check of LTS dist upgrades" [Undecided,New] https://launchpad.net/bugs/181518
<ogra> hmm, i can but it doesnt appear mounted
<ogra> apt-get update moans
<cjwatson> ogra: good call, I see the problem now
<ogra> i see stuff in /cdrom though
<cjwatson> it's an artifact of fjp's work to make multi-CD installs work
<ogra> ah
<cjwatson> and muggins here got the ordering a bit wrong when merging
<cjwatson> I'll figure out how it's supposed to work and fix it - thanks!
<ogra> :)
<pitti> mvo: oh, right, that
 * calc got mono uploaded
<seb128> calc: <pochu> calc: slomo will take care of the mono upload.
<calc> pochu: sorry i didn't see that since i was working on the upload, did he already do it? i needed it for the OOo i have to do in the next few minutes
<slomo> calc: there were some things that needed changes... well, let's fix it with next upload then, nothing critical
<calc> slomo: oh sorry about that :(
 * calc is now doing the OOo test build with new mono
<pitti> pochu: please use debuild -v <previous ubuntu version> when merging
<pochu> pitti: acked (slomo just told me that :)
 * pitti hugs pochu
 * pochu hugs pitti back :)
<siretart> asac: are we going to stay with network-manager 0.6.5 for hardy, or do we want to go for 0.7.x? I'm asking because I'm curious to know what to do about wpasupplicant
<siretart> read: merge the 0.6.x branch from debian, or stay with 0.5 for hardy
<tjaalton> I've heard that 0.7 supports modems, so n-m support for 3G would be way cool
<asac> siretart: not sure ... we should probably start to implement the debian plugin for the system-settings and publish a preview version to get an idea about its suitability for a LTS release.
<sladen> n-m that /worked/ would be "way cool"
<sladen> or rather, could cope with situations where the PC is not in a state == first boot
<seb128> what bug is that one?
<siretart> asac: I see. well, FYI, the plan for debian is to keep tracking the 0.6 branch of wpasupplicant. need to ask mbiebl about nm
<pitti> lool: I think our remaining avahi change (http://merges.ubuntu.com/a/avahi/avahi_0.6.22-2ubuntu1.patch) is equally relevant for Debian; WDYT, can it be merged?
<asac> siretart: debian should ship the right nm + wpasupplicant combinatino as well imo.
<asac> siretart: but most likely 0.7 will be ready in time for next debian stable release
<siretart> asac: I'd assume so, right. however I haven't heard complaints from the nm maintainers there
 * pitti looks at http://launchpadlibrarian.net/11226590/apt-show-versions_0.12ubuntu1.debdiff
<pitti> is it just me who thinks that maintaining debian/ubuntu-patches is more effort and error-prone than just using MoM? at least for such trivial merges?
<siretart> pitti: I think such patches are best kept in either launchpad or the debian bts
<pitti> siretart: well, it's a patch that doesn't apply to Debian
<pitti> but it's so trivial and obvious, and MoM does it just fine, so I think it's just unnecessary overheade
<pitti> s/e$//
<siretart> It might not apply, but having it around would not hurt there
<siretart> right
<pitti> warp10: anyway, sponsored; thanks
<kkubasik> hey, has anyone been having problems with cairo and firefox?
<kkubasik> http://pastebin.com/m211fcc81
<tjaalton> could someone translate from Spanish to English: "il file con la lista dei file del pacchetto `xserver-xorg-core' contiene un filename vuoto"
<jpatrick> that's italian
<tjaalton> oh :)
<tjaalton> damn me
<jpatrick> if it was spanish, I would have gladly helped you :)
<tjaalton> heh
<tjaalton> I should've known
<pitti> "the rows with the list of the rows of the package ` xserver-xorg-core' contain a filename empty" -- hmm
<tjaalton> it's bug 181530, and doesn't make sense to me
<ubotu> Launchpad bug 181530 in xkbset "package xkbset None [modified: /var/lib/dpkg/info/xkbset.list] failed to install/upgrade: il file con la lista dei file del pacchetto `xserver-xorg-core' contiene un filename vuoto" [Undecided,New] https://launchpad.net/bugs/181530
<tjaalton> at least there is no file conflict
<pitti> tjaalton: maybe the /var/lib/dpkg/info/xkbset.list is empty?
<tjaalton> disk full?
<pitti> possibly
<warp10> pitti: sorry for late response, was away. I tought it was trivial and obvious indeed, but maybe it could be useful someway, so I updated it :)
<pitti> msgid "files list file for package `%.250s' contains empty filename"
<pitti> tjaalton: ^ grabbed from italian dpkg.po
 * pitti pats his unpacked langpack tree for grepping for translations
<slangasek> pitti: "the row" is "la fila", not "il file" :)
<seb128> pitti: can you look in this unpack tree if the french apport translation is valid utf8? ;-)
<pitti> slangasek: good morning
<slangasek> morning
<pitti> slangasek: that was just babelfish; my own Italian is a magnitude worse :)
<pitti> seb128: rookery:/srv/language-packs.ubuntu.com/gutsy-proposed/sources-base/
<seb128> pitti: danke
<pitti> seb128: I can look for you in a bit, off to dinner
 * seb128 learns every day thanks to pitti ;-)
<seb128> pitti: no, I'll manage, thanks
<seb128> *hug*
<slangasek> pitti: no, I think your own italian would only be a magnitude slower, I don't think it's possible to be a magnitude worse ;)
<_MMA_> seb128: Does the package gdm 2.20.2-1ubuntu2 (hardy)  include the changes from upstreams 2.20.3 release?
<tjaalton> pitti: thanks, weird
<seb128> _MMA_: no, but I'll upload 2.20.3 after the freeze
<seb128> _MMA_: why?
<_MMA_> Ahh... Killer. Im looking to see that bug where you can set the background color go away.
<seb128> _MMA_: it's supposed to be fixed in 2.20.3
<seb128> _MMA_: it can probably wait an extra day ;-)
<_MMA_> Oh sure. Just a visual eye-sore when Ubuntu Studio has it set to black but it comes up light brown.
<hunger> Is there a way to not start compiz? I think my white-screen-when-using-gnome problem is compiz related.
<ogra> hunger set /desktop/gnome/applications/window_manager/current and default to metacity
<ogra> (gconf keys)
<hunger> ogra: Thanks!
 * hunger wonders where the config file with those keys is hidden.
<hunger> Sorry, I'm a kde person:-)
<hunger> That indeed helps. I can log back into gnome again.
<sladen> full disk?
 * pitti hugs seb128 back
<pochu> will the hardy cds ship any translation packages? specifically the spanish ones?
<seb128> pochu: depending of the CD space
<seb128> pochu: not easy to say now
<pochu> Right. And do you know whether Gutsy shipped any?
<seb128> gutsy shipped some, dunno the exact list, cjwatson or pitti most likely know
<pochu> maybe the ones in http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.gutsy/live ?
<seb128> pochu: right
<pochu> thank you seb128
<seb128> you are welcome
<pitti> asac: the history substring search in ffox3 is the best thing since slice bread!
<seb128> maybe I should give firefox3 a try just to see what it looks like ;-)
<asac> yeah ;) ... I agree that it rocks!
<cjwatson> it's nice, except that if your mouse happens to be hovering over the area occupied by the substring search results pop-down, it's impossible to type just the substring and not select whatever it was that the mouse is hovering over
<cjwatson> i.e. pressing Enter in the URL bar prefers to select the thing being hovered over by the mouse rather than whatever you typed in the URL bar
<asac> good catch. haven't noticed before
<cjwatson> do you want a bug?
 * cjwatson blinks at bug 180525
<ubotu> Launchpad bug 180525 in firefox-3.0 "firefox-3.0 pornlib resizes images into works of abstract art" [Undecided,New] https://launchpad.net/bugs/180525
<slangasek> "oh, /cubic/ interpolation, I thought you said /cubist/ interpolation"
<asac> cjwatson: yes, please open a bug
<asac> didn't find an upstream duplicate on first attempt, but will have to check again later. bugzilla is sometimes hard to use :/
<seb128> bugzilla rocks ;-)
<cjwatson> asac: OK, I hope bug 181575 is a comprehensible description. I found it quite hard to describe clearly
<ubotu> Launchpad bug 181575 in firefox-3.0 "pressing Enter in URL bar selects mouse hover target in substring-search pop-down" [Undecided,New] https://launchpad.net/bugs/181575
 * asac looking
<asac> cjwatson: thats fine. thanks
<slangasek> tjaalton: is there any chance that your latest openchrome changes could have negatively affected a Radeon chip?
<slangasek> tjaalton: Riddell is reporting (informally) that alpha3 X is screwed up on this chip: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M
<tjaalton> slangasek: Xorg.0.log would help
<tjaalton> sounds strange enough :)
<slangasek> yeah
<slangasek> will have to wait for Riddell to resurface then, I guess
<slangasek> what little other information there is is here: http://iso.qa.ubuntu.com/qatracker/result/1210/50
<slangasek> bryce: unless you happen to have access to something with that chipset and could verify?
<bryce> heya
<bryce> hmm, I just have one ATI based system
<tjaalton> there are reports that ati 6.7.197 has had regressions
<bryce> wait, no two.
<bryce> I think one is an R350, lemme check
<tjaalton> you lucky b.. :)
<bryce> my fiance is thankfully tolerant of my computeraholic issues
<bryce>  Radeon R350 [Radeon 9800 Pro]
<bryce> unfortunately this system isn't on Hardy
<seb128> 01:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9600] (Secondary)
<seb128> that's my desktop and it's running hardy
<seb128> 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600] (prog-if 00 [VGA controller])
<seb128> and it works fine with the current ati driver
<tjaalton> riddell has a laptop apparently
<tjaalton> slangasek: there's a newer driver on wiki.u.c/XorgOnTheEdge
<bryce> is there a LP# for riddell's bug?
<tjaalton> I would've noticed it :)
<bryce> my other -ati is X600
<claude> stgraber: ping
<claude> stgraber: stop talking, please
<stgraber> claude: :)
<slangasek> bryce: no LP#, no; he seems to have taken off ill before he could get to that point
<slangasek> the problem was reported with the LiveCD; I suppose that shouldn't make a difference, but
<bryce> ok, I'll cut a CD and give it a go
<sabdfl> Riddell: thanks for taking care of the geoip sync
<tjaalton> bryce, slangasek: the ati bug is likely bug 180343
<ubotu> Launchpad bug 180343 in xserver-xorg-video-ati "ATI driver update causes Display Corruption" [Undecided,New] https://launchpad.net/bugs/180343
<bryce> thanks
<slangasek> tjaalton: great, thanks
<slangasek> Riddell: ^^
<bryce> (cd's about halfway burned; will test it after lunch.  bbiab)
<tjaalton> bryce: I'll ask alex about that bug
<tjaalton> bryce: ok, I'll compile git master, and ask people to test that
<bryce> booting, bbiaw
<tjaalton> slangasek: new driver attached to the bug, waiting for test results
<slangasek> tjaalton: cheers
<bryce> slangasek: kubuntu booted up just fine on my R350
<bryce> I did find one issue though, but it's unrelated
<bryce> so perhaps the issue Riddell ran into was specific to his R350M?
<Riddell> sabdfl: welcome
<Riddell> bryce: wouldn't surprise me, this laptop is full of odd hardware bits
<tjaalton> bryce: actually that's RS200M
<tjaalton> Riddell: please try the driver from bug 180343
<ubotu> Launchpad bug 180343 in xserver-xorg-video-ati "ATI driver update causes Display Corruption on Radeon IGP 330M/340M/350 " [High,Confirmed] https://launchpad.net/bugs/180343
<bryce> Riddell, slangasek:  I ran into this issue when trying to access the monitor config admin tool:  http://people.ubuntu.com/~bryce/tmp/snapshot1.png
<Riddell> tjaalton: the radeon_drv.so file attached there seems to work ok
<tjaalton> wohoo!
<bryce> :-)
<slangasek> bryce: hrm, curious
<Riddell> bryce: yeah, known issue, I've not had a chance to look at it
<bryce> okie
<bryce> yeah, figured as much
<tjaalton> ok, I've got the commit that fixes this ati issue ()
<tjaalton> RADEON: Make sure all old IGP chips have HasSingleDac set
<tjaalton> duh
<tjaalton> slangasek: should I roll an update with that patch?
<slangasek> tjaalton: sounds good.  Not sure I'll reroll images for it, but if it lands in good time, it'd be nice to have
<tjaalton> ok
<slangasek> and if it doesn't land, and least we've got good info to put in the release notes :)
<tjaalton> yeah :)
<phomes> is there a reason for that gnome-games is stuck at 2.20.1 for gutsy? (and 2.20.0.1 for hardy btw) We are getting a ton of crasher reports that should be fixed from these old versions
#ubuntu-devel 2008-01-10
<StevenK> slangasek: Do you mind if I upload a new upstream of bluez-gnome?
<slangasek> StevenK: better to wait 'til the alpha is done, I think
<StevenK> slangasek: Okay, I'll wait.
<slangasek> updated alternate images available for alpha3 pre-testing, all flavors
<TheMuso> slangasek: DOn't bother re ubuntustudio, we still have kernel issuse.
<TheMuso> slangasek: We aren't bothering about it this time round
<slangasek> (includes a fixed apt that was breaking pkgsel)
<slangasek> TheMuso: understood; sorry that things didn't come together with the right timing for you
<Hobbsee> !ping
<ubotu> pong
<TheMuso> slangasek: Thats alright. Thats the joy of being in a team where only a few of us really try and keep up with things, and when we see these things, normal life stuff gets in the way just enough to prevent timely reporting.
<mekius> What things can I preset in the preseed file on the live cd?
<mekius> I've heard you can't set much
<Hobbsee> slangasek: do you have a major problem if i handhold kde4 into building?
<StevenK> kde4 is too scared to build by itself?
<TheMuso> lol
<Hobbsee> urgh
 * Hobbsee needs access to a local source mirror.
<slangasek> Hobbsee: I don't think so?
<Hobbsee> slangasek: do you have effective ways of dequeuing builds?
<TheMuso> Hobbsee: For what?
<slangasek> dequeuing builds? no
<Hobbsee> slangasek: damn.
 * Hobbsee suspects that slangasek would have a way to get a list of all the kdelangpacks as shown on https://edge.launchpad.net/ubuntu/hardy/i386/+builds?build_text=kde-l10n&build_state=all, in a line though
<slangasek> Hobbsee: um... lynx -dump $url | grep something something ? :)
<Hobbsee> slangasek: you should have been able to give it to me from drescher, and saved using a web browser :)
<slangasek> I don't know anything about getting build states via drescher
<Hobbsee> you shouldn't need to - but you should have been able to get me a list of accepted packages or something
<Hobbsee> it doesn't matter, stdin had a list.
 * Hobbsee keeps resetting the build scores
<slangasek> ah; packages currently go straight to 'done' as far as I've been able to see in the queues, so I guess if that's the same list you're interested in I could have done, but I don't think there's currently a shortcut for 'accepted but not built'
<Hobbsee> hm
<Hobbsee> the done probably would have done it
 * Hobbsee mass uploads, to fix the build failures
<jdong> can I do a bit of prodding about mpeg4ip in source NEW?
<jdong> there's a lot of broken/unmetdeps stuff in Hardy's mp4-playing packages.
<jdong> thanks in advance, gonna sleep now :)
<dholbach> good morning
<pitti> Good morning
<Fujitsu> Hi pitti.
<StevenK> Hey pitti
<carlos> pitti, seb128: morning. Yesterday we started with Hardy imports. I think early next week we will be able to provide an updated language pack (is difficult to give a good estimation about when everything would be imported)
<seb128> carlos: hello, good, thanks
<carlos> pitti: when do you plan to do a new language pack update?
 * carlos talks about stable releases
<pitti> hey carlos; godo to hear
<pitti> carlos: hm, not sure; we missed the 'first Monday in January' over the holidays
<pitti> so I think we'll just do the Feb update again
<carlos> ok
<pitti> I didn't hear about any bad bugs that we need to fix urgently
<carlos> I just got a complain about gcompris
<carlos> that we fixed close to the latest language pack update
<carlos> so it's not included
<carlos> in that version
<carlos> other than that, I'm not aware of any other problem
<carlos> pitti: anyway, seems like your ppa archive shows that we didn't fix the problem completely, so is ok to wait to see whether we could fix the problem before that update..
 * soren *hates* writing debian/copyright files
 * dholbach hugs soren
<soren> :)
 * soren hugs dholbach back
<soren> I somehow always get stuck with the completely impossible packages with 40 source files and 40 different copyright assignments and licenses. Grr...
 * Fujitsu finds some more for soren.
<soren> I mean... COME ON! How difficult is it to get it right?
<soren> Sadly, the answer seems to be: "very". :(
<LaserJock> soren: well, I'm actually impressed all 40 files had licenses ;-)
<soren> LaserJock: Well... They don't.
<LaserJock> figures
<LaserJock> that's fairly common
<LaserJock> "It's GPL because I say so"
<soren> LaserJock: There's a copy of the GPL in the top level, though, so I'm assuming that as a default.
<Fujitsu> Not good enough. That'll get rejected.
<soren> Fujitsu: I know.
<cjwatson> huh? I think that's perfectly sane
<cjwatson> well, maybe not perfectly since I know that fails GNU standards, but it should be accepted
<Fujitsu> cjwatson: I've seen things rejected because a couple of files lacked license headers.
<soren> Oh? I've had packages rejected on those grounds before.
<cjwatson> we haven't historically required every file to have a licence
<cjwatson> disagreement among archive admins, then
<cjwatson> but it is not correct to say "that'll get rejected"
 * LaserJock notes who to ask to look at NEW next time ;-)
<cjwatson> and personally I think we should accept that; the author's intent is quite clear
<mjg59> If files have contradictory licenses, that's a problem
<ogra> LaserJock, was it you who fed the new meeting dates into the fridge ?
<LaserJock> ogra: nope
<ogra> ah
<cjwatson> you'd get laughed out of court if you tried to assert that files in a package with a single licence file and no other licence indication somehow had some other licence
<mjg59> If they're missing a license header but are copyrighted to the author who released it under the GPL, it's pretty obvious what they mean
<cjwatson> mjg59: sure
<ogra> according to it we have two meetings next week :)
<LaserJock> ogra: I think maybe Burger
<LaserJock> ogra: sweet ;-)
<ogra> heh
<soren> Hmm... This is very useful information. :)
<soren> The usual procedure for me used to be: Take the mess from upstream, try to work out what they meant, kindly ask them to make that explicit, wait for new release with this stuff, and only then get it accepted here.
<Fujitsu> That's what most seem to do.
<Fujitsu> That's what we ask people to do
<mjg59> An email from them making it explicit is easily enough
<mjg59> But in general, we don't need licensing per file if there's a global license
<LaserJock> ogra: fixed
<Fujitsu> mjg59: I have been told otherwise on both counts.
<ogra> thanks :)
<Fujitsu> By an archive admin, IIRC.
<mjg59> Email from the copyright holder clearly indicates intent, so isn't a problem any more
 * ogra pokes ScottK gently ... how about a vbox driver update for 2.6.24 ?
<ogra> err
<ogra> damned
<ogra> s/ScottK/StevenK
<Fujitsu> ogra: At least you poked gently :P
<ogra> heh
<cjwatson> Fujitsu: when you next get told that, let me know and I'll argue it with them.
<cjwatson> because I think that is an unreasonable requirement
<LaserJock> hmm, it'd be nice to have some common understanding amongst Ubuntu Archive (especially since it's a bit larger now) when it comes to basic stuff like copyright/license
<pitti> Fujitsu: I don't think it would be reasonable to require copyright headers in every source file. Lots and lots of packages would be invalid otherwise :)
<pitti> Fujitsu: I agree to 'fall back to global copyright/AUTHORS/etc.'
<Fujitsu> We have no written policy on what's needed, nor what gets let into multiverse, etc. It would be nice to have one.
<Fujitsu> (Preferably with proprietary Windows applications being somehow excluded from multiverse, but that's another story)
<mjg59> Fujitsu: Eh. If they're packaged in a way that works with Wine and they're freely distributable, I don't think that's an issue
<Fujitsu> mjg59: Shall I go ahead and upload tens of thousands of them, then?
<mjg59> Fujitsu: If you think they'd provide a significant benefit to Ubuntu users
<Fujitsu> pq passed, and I'm sure a lot of other stuff will if people try. It's a rather slippery slope.
<mjg59> If people take the piss, we stop
<Fujitsu> I guess so.
<mjg59> There's no inherent requirement for us to be consistent on anything other than "Don't be stupid"
<Fujitsu> True.
<soren> While we're on the subject... In many cases, the copyright of each file is assigned to the same person or company, but have different years denoted.. Does debian/copyright need to reflect this in great detail? I've assumed so so far, but I'd be happy to be told otherwise.
<cjwatson> soren: technically debian/copyright should have the aggregation of the lot, but I wouldn't reject on it
<soren> cjwatson: Ok.
<pitti> seb128: WDYT, time for moving deskbar-applet to gutsy-updates?
<pitti> seb128: and tomboy? (in -proposed for 80 days now)
<Fujitsu> tomboy just had a security update, so watch out...
<pitti> seb128: oh, right, seems this needs to be merged to -proposed
<StevenK> ogra: Grr.
<StevenK> ogra: I got sick of the constant "Ohmigod you don't do vbox right" poking on IRC.
<StevenK> seb128_: So, do you have a moment?
<seb128_> StevenK: "so"? if you assume I read a ping or something from you I didn't, my dsl line had some issues
<seb128_> StevenK: depends for what ;-)
<StevenK> seb128_: Nah, just trying to get your attention. :-)
<StevenK> seb128_: Could I get a little help with gnome-games?
<StevenK> seb128_: Aisleriot has been hildonized, but I can't get it to build, since dh_install falls over.
<seb128_> sure
<seb128_> how does it falls over?
<seb128_> the content is not the same in the hildon case?
<StevenK> cp: cannot stat `./debian/tmp/usr/lib/gnome-games': No such file or directory
<StevenK> dh_install: command returned error code 256
<StevenK> seb128_: No, because only Aisleriot builds with hildon.
<StevenK> Maybe I need to do something messy and build twice.
<seb128_> why twice?
<seb128_> you want the normal games and the hildon aisleriot?
<seb128_> or only aisleriot?
<ogra> StevenK, well, we're testing the third alpha release now, many of us run the new kernel, it would just be nice to not have to use m-a to be able to work ... but i'm fine doing it ...
<StevenK> ogra: Sorry, I just annoyed with all of the constant poking about it.
<StevenK> seb128_: Either would be fine
<seb128_> StevenK: but what the current build with hildon option do? Only build aisleriot?
<StevenK> seb128_: The current build with the hildon option says "These games don't support hildon" and then die.
<seb128_> StevenK: I need to have a look myself, your summary is not clear enough
<StevenK> seb128_: I have a debdiff of my work so far if that helps
<seb128_> StevenK: no, what would help is to understand what the hildon configure option does
<seb128_> I understood from what you said that it breaks the build
<seb128_> looks like an upstream bug which should be fixed
<seb128_> not something which should force us to build the package twice or workaround
<pitti> keescook: FYI, I added http://people.ubuntu.com/~ubuntu-archive/pending-sru.html#superseded to show which SRUs have been shadowed by a -security update
<pitti> keescook: just to have an additional automated check
<pitti> slomo: tomboy recently got a security update which needs to be merged to the gutsy-proposed version
<pitti> jdong: any idea about the status of https://edge.launchpad.net/ubuntu/feisty/+source/ktorrent/2.1-0ubuntu2.2 ? should this be killed, or moved to -updates, etc?
<MacSlow> Keybuk, meeting or no meeting today?
<Keybuk> MacSlow: meeting today
<MacSlow> ok
<MacSlow> Keybuk, I'm still missing the reminder email... maybe it just did not get through yet
<Keybuk> I just sent it ;)
<pitti> Riddell: what's the status of verification of bug 176347? there's no test case
<ubotu> Launchpad bug 176347 in kdebase "KDM local DoS with user images" [Undecided,Fix committed] https://launchpad.net/bugs/176347
<mvo> StevenK: do you plan to update the virtualbox-ose-source modules? the current ubuntu ones do no longer compile for me, but the 1.5.4 version seems to be ok
<ogra> mvo, shhh !
<mvo> ogra: ?
 * ogra already got whacked over the head today for that question :P
<mvo> aha, thanks for the warning ogra :)
<ogra> mvo, there is a patch ....
<ogra> let me find it, i filed it in LP somewhere
<mvo> ogra: I'm fine, I fixed it locally already
<cjwatson> mvo: oh, I uploaded apt last night, if you haven't seen it yet; tweak to the APT::Get::List-Cleanup compat code
<pitti> mvo: can you please tell me what I should do about the old SRUs in bug 109216 and bug 109290?
<ubotu> Launchpad bug 109216 in update-manager "upgrade not possible with 0.45.3" [Undecided,Fix committed] https://launchpad.net/bugs/109216
<ubotu> Launchpad bug 109290 in update-manager "update-manager core should support proposed updates" [Medium,Fix committed] https://launchpad.net/bugs/109290
<pitti> (edgy->feisty upgrades)
<Riddell> pitti: doesn't seem like the qa team have looked at it
<mvo> cjwatson: thanks
<pitti> Riddell: you don't know anyone who could test it?
<Riddell> pitti: has to be sru-verification doesn't it?
<pitti> Riddell: well, not necessarily
<pitti> the person needs to be sufficiently credible, of course
<ogra> in case anyone needs to build vboxdrv for 2.6.24 see bug 174213
<ubotu> Launchpad bug 174213 in virtualbox-ose-modules "cant build with 2.6.24 kernel source" [Undecided,New] https://launchpad.net/bugs/174213
<ogra> (patch attached)
<pitti> i. e. if (s)he says "i've isntalled proposed and package still works and bug is fixed", that it's actually true
<Riddell> ah, pedro_, you're on sru-verification
<pedro_> Riddell: yes
<pitti> thegodfather: has bug 120177 in feisty-proposed ever been tested? what shall we do with it?
<ubotu> Launchpad bug 120177 in multipath-tools "dm-multipath not autoloaded causes multipath to fail" [Undecided,Fix committed] https://launchpad.net/bugs/120177
<Riddell> pedro_: could you test bug 176347
<ubotu> Launchpad bug 176347 in kdebase "KDM local DoS with user images" [Undecided,Fix committed] https://launchpad.net/bugs/176347
<pedro_> Riddell: ok, let me see
<thegodfather> pitti: let me check.. i don't remember the status.. i thought it was tested and accepted
<Kmos> Failed to fetch http://ftpmaster.internal/ubuntu/dists/hardy/main/binary-i386/Packages.bz2  MD5Sum mismatch
<thegodfather> pitti: i did the test, but AFAIR we need somebody else to verify it. if my word is enough, i made the patch based on my tests and had running the packages from proposed
<thegodfather> pitti: i can't do much more than that right now
<pitti> thegodfather: yes, that's fine; I'm just insistent about using the actual .debs from -proposed as opposed to a local build
<thegodfather> i did that
<pitti> thegodfather: can you please add that to the bug for the paper trail?
<thegodfather> pitti: sure
<pitti> thegodfather: grazie
<thegodfather> pitti: bitteschen
<thegodfather> done
<mvo> cjwatson: I merged the patch into my main bzr branch now, thanks again and sorry for the trouble
<cjwatson> mvo: no problem
<ogra> btw for the record, pkgsel just finishes here
<ogra> d-i muste be a dirty thing regarding the time it needs to clean up after itself :P
<cjwatson> the cleanup consists of scrollkeeper-update -q; fc-cache -f -v
<ogra> yeah
<ogra> i see a good bunh of xml warnings/errors in the log
<ogra> *bunch
<cjwatson> er, and a bit of update-notifier fiddling and update-initramfs -u
<cjwatson> (I was looking at Debian's pkgsel by mistake first time round)
<ogra> yeah, well, the majority of time is spent for scrollkeeper
<ogra> on my new machine a vbox install is done in about 40min now .... a quater of that s "cleaning up..." atm ...
<mvo> ogra: I generally prefer kvm because it has less fiddling with the kernel modules, generally it just works(tm) for me
<ogra> yay, clinet buiolder starts :)
<ogra> *client-builder *sigh*
<mvo> but the snapshot support is not so good
<ogra> i'm just lazy and use what i'm used to :)
<ogra> i like the easiness of having an internal network and have a thin client ready within seconds
<ogra> hmm
<ogra> why did i never have text output in the edubuntu installer with ltsp-client-builder ....
<ogra> intrestingly ubuntu-alternate shows text
 * ogra wonders if all the probs he every had with the progressbar in edubuntus d-i might be caused by something in the d-i setup itself in edubuntu
<pitti> thegodfather: copied to -updates
<thegodfather> pitti: ok
<thegodfather> thanks
<cjwatson> ogra: sounds hard to credit
<ogra> cjwatson, well, it just struck me that i never looked at that level :)
<ogra> gar ... ltsp failed
 * ogra ARGHS loudly ....
<ogra> damned typos
<emgent> keescook, heya :P
<ogra> seb128_, does tracker have a gconf key i could disable fro ltsp logins ? with 20 users logging it simultaneously tracker forces servers on their knees at login ...
<Keybuk> yes, there's a Disable Indexing thingy
<ogra> Keybuk, thanks i'll dig for it
<Keybuk> I assume that toggles a gconfish
 * ogra heard of ltsp servups with 200 users and nfs homedirs :) imagine that being indexed
<ogra> *servers
<ogra> apart from a missing wallpaper my alpha3 install looks good so far
<seb128_> ogra: what Keybuk said, look to the gconf keys it's likely easy to notice there
<pochu> ogra: tracker stores its preferences in ~/.config/tracker/tracker.cfg . Look at EnableWatching and EnableIndexing.
<ogra> yep, i'll add an xsession script that dis/enables it
<ogra> pochu, a gconf key is enough
<ogra> but thanks for the hint :)
<pochu> ogra: oh, I didn't know that was possible... I thought tracker didn't use gconf :)
<ogra> now that ltsp moves to ubuntu alternate i face probs on the desktop i didnt have in edubuntu since i just adjusted the desktop (edubuntu doesnt have tracker)
 * ogra takes a break
<seb128_> hi _MMA_
 * _MMA_ gives seb128_ a big hug for the gdm upload. :)
<seb128_> _MMA_: did it fix your issue?
<_MMA_> Sure did. Thanx.
<seb128_> you are welcome ;-)
<afflux> Is it just me or isn't apport adding the package and dependency fields to it's reports?
<afflux> s/reports/crash &/
<pitti> afflux: the initial reports don't have them
<pitti> afflux: but after they get processed by the frontend they are added
<afflux> ah
<norsetto> pitti: packages that __build-depends__ on packages in multiverse should also be in multiverse ?
<pitti> norsetto: yes
<norsetto> pitti: danke
<pitti> np
<Silly_Parrot> People I'll tell you, USA never was on the moon, it's fake.
<Silly_Parrot> I know it
<Hobbsee> ...
<Silly_Parrot> Just right i has a call from the White House and some dude told that to me
 * Chipzz whacks Silly_Parrot on the head... hush now
<Hobbsee> Silly_Parrot: do you have anything useful to add?  please see the /topic
<Chipzz> Hobbsee: what's +z ?
<Hobbsee> Chipzz: it's a useful mode.
<jpatrick> Chipzz: ops see muted people messages
<Chipzz> ah
<Hobbsee> or see normal people, when the channel is +m
<Chipzz> and banned people are muted
<jpatrick> Chipzz: and if channels +m too too
 * Hobbsee shrugs
 * Pici shrugs
<Chipzz> btw, what's with the leaving ... "requested by Hobbsee"? why not just kick misbehaving people?
<emgent> keescook, ping
<Hobbsee> Chipzz: removes don't tend to trigger auto-rejoin scripts, and look neater.
<Chipzz> well looking neater is mostly a matter of semantics ;)
<Chipzz> but the auto-rejoin script sounds look a good argument
<emgent> pitti, one question
<pitti> ?
<emgent> can u see xss launchpad bug ID that i found some month ago ?
<pitti> emgent: number?
<emgent> i dont remember who open this bug in launchpad
<emgent> yes number
<emgent> i only notified it to keescook (i remember)
<emgent> but i dont open bug in launchpad
<emgent> pitti, found it? :)
<pitti> emgent: no; please search, meeting now
<emgent> ok sorry ;)
<pitti> np :)
<emgent> i cant search, i'm not subscribed :Â°
<pochu> emgent: https://launchpad.net/ubuntu/+bugs?advanced=1
<emgent> pochu, it was private bug :)
<pochu> oh, ok :)
<pitti> emgent: if it's private, I can't see it either
<emgent> oh ok, np ;)
<mjj29> so, how to I close bugs in launchpad
<mjj29> #58145 was closed ages ago by a debian upload which has since been stolen for ubuntu
<mjg59> Click on the status, set to the appropriate status
<mjj29> do I want committed or released?
<geser> if it's in the ubuntu archive then "fix released"
<mjj29> that doesn't refer to being released in gutsy then, right
<mjj29> thanks!
<BenC> pitti: ping, I'm uploading a new lbm to dapper-updates that fixes a one-liner bug in mptsas
<BenC> pitti: would probably only show on smp testing
<pitti> BenC: ok; we need to respin CDs for that, I assume?
<BenC> pitti: yeah
<pitti> (and -proposed please)
<pitti> BenC: that means redoing the testing, but yeah
<BenC> pitti: -proposed I mean
<pitti> ok
<BenC> pitti: right...it explains why things worked in vmware tests, but will fail in real hardware tests for multi-core systems
<BenC> pitti: there's no bug report...should I create one?
<pitti> BenC: can't hurt, if you have some info; just in case it turns up in verification
<BenC> pitti: ok, it's uploaded now, I'll file a bug in a few
<Riddell> tjaalton: bad news on that radion_drv.so file I tested yesterday, it did actually break X (after I rebooted)
<tjaalton> Riddell: ok, so try setting 'Option "AGPMode" "4"' and see what happens
<pitti> seb128: cdbs gracefully treated with a hammer now and uploaded; happy gnome rebuilding :)
<seb128> pitti: danke
<seb128> pitti: new GNOME on monday that will do ;-)
 * Hobbsee wonders how one gracefully treats something with a hammer
<pitti> seb128: yay
<seb128> Hobbsee: wait next UDS we will show you ;-)
<Hobbsee> seb128: you're going to practice on me?
<Hobbsee> seb128: that does require me being there, though...
<seb128> no practice, just demonstrate ;-)
<Riddell> pedro_: missing step added to bug 176347
<ubotu> Launchpad bug 176347 in kdebase "KDM local DoS with user images" [Undecided,Fix committed] https://launchpad.net/bugs/176347
 * pitti wonders if the @ in front of Hobbsee is a threat on itself
 * Hobbsee hides her wrists from seb128
<Riddell> tjaalton: do you remember the bug number?
<Hobbsee> pitti: oh, thanks, forgot about that
<jdong> pitti: with regards to ktorent, that's gonna be your call. One person other than me has responded positively, but most ktorrent users have moved to the backports versions. In my opinion it should be pushed to -updates as the DHT crash is pretty serious. It allows random noise over its listening UDP port to segfault the program.
<pedro_> Riddell: ok, thanks i'll look at it now
<tjaalton> Riddell: bug 180343
<ubotu> Launchpad bug 180343 in xserver-xorg-video-ati "ATI driver update causes Display Corruption on Radeon IGP 330M/340M/350 " [High,Fix released] https://launchpad.net/bugs/180343
<tjaalton> Riddell: maybe the fix was wrong after all :)
<tjaalton> which would mean that it's unresolved upstream
<Riddell> tjaalton: hmm, I seem to have a blank xorg.conf file
<Riddell> is that normal?
<tjaalton> fresh install?
<tjaalton> generate a new one with 'dpkg-reconfigure xserver-xorg'
<Riddell> tjaalton: no, from alpha 2
<tjaalton> hmm, maybe due to some bug then, should be fixed by now
<tjaalton> there were some issues
<Riddell> tjaalton: when I run 'dpkg-reconfigure xserver-xorg' it doesn't offer me a radeon driver, only ati
<tjaalton> it's the same
<tjaalton> actually, using  'dpkg-reconfigure -phigh xserver-xorg' is preferred
<Riddell> tjaalton: meh, it says error while preparing new Xorg X server configureation file; not attempting to update existing configuration
<tjaalton> hmm
<tjaalton> remove the empty file
<tjaalton> and /var/lib/x11/xorg.conf.md5sum
<Riddell> tjaalton: doesn't help, I'm running a dist-upgrade to see what happens
<tjaalton> that error is from dexconf
<tjaalton> I mean when dexconf fails you get that
<tjaalton> run "dexconf -o /tmp/xorg.conf"
<tjaalton> it should give the real error
<Riddell> tjaalton: dexconf: invalid option -- i
<Riddell> oh, that's my fault
<Riddell> dexconf: error: cannot generate configuration file
<Riddell> xserver-xorg/config/device/driver not set.  aborting.
<tjaalton> Riddell: what version of xserver-xorg do you have?
<tjaalton> uh, seems like a debian bug then
<tjaalton> crap
<Riddell> tjaalton: ok, I dist-upgraded and
<Riddell> +-+
<tjaalton> Riddell: I think I fould the bug already
<Riddell> tjaalton: and now dpkg-reconfigure works and I get a very generic looking xorg.conf
<tjaalton> really?
<tjaalton> hmm, maybe I misunderstood the logic after all :)
<tjaalton> phew
<Le_Vert> hi :)
<Le_Vert> could you tell me if there's a way to use a response file with the graphical installer ?
<Le_Vert> like the way D-I works
<Riddell> tjaalton: the old radeon_drv.so still works, but the one from current xserver-xorg-video-ati and from that bug report breaks
<Riddell> tjaalton: where do I add 'Option "AGPMode" "4"' ?
<Riddell> tjaalton: added it and it seems to fix the issue
<tjaalton> Riddell: great, thanks
<\sh> hmmm....looks like that 91.189.88.45 (resolves to archive.ubuntu.com) has some network problems
<soren> \sh: Or maybe you do?
<soren> wfm..
<\sh> soren: I'm just checking from different locatrions
<\sh> locations even
<soren> \sh: Me too. Just checked from three different places.
<geser> I've no problem to access it with firefox
<soren> \sh: Three different countries, even.
<\sh> soren: right...looks like that my isp has problems between decix and level3
<seb128> soren: works fine for me too
<geser> speaking of mirrors: does somebody know how much time the german mirror is behind archive.ubuntu.com?
<\sh> jesus...ISP router at decix eats at least 3-4 icmp packets
<mathiaz> ogra: is the fridge information about edubuntu meetings still relevant ?
<ogra> yes, but there was an error in the entry for next week apparently
<ogra> 16 Jan 12:00 UTC: Edubuntu meeting,  23 Jan 20:00 UTC: Edubuntu meeting are the next dates
<asac> anyone has a fedora install at hand :) ?
<mathiaz> ogra: ok - anyway there is a meeting every fours weeks scheduled at 20:00 UTC
<mathiaz> ogra: I was looking into the possibility of moving the Server Team meeting to wednesdays at 21:00 UTC
<mathiaz> ogra: which would be one hour after the edubuntu meeting (which is scheduled for 2 hours according to the fridge)
<ogra> mathiaz, we'll need richEd for this discussion, half of the meeting is his, half is mine :) (first hour is usually tech, second community)
<ogra> i'd be fine with 30min for the (for me) late meeting
<ogra> and only have 1h during the 12:00UTC one ...
<mathiaz> ogra: and that'd be only once every four weeks
<ogra> yeah, fine with me
<mathiaz> ogra: hum - it would be every other week actually.
<tjaalton> who is doing the alpha3 relnotes?
<ScottK> I think Burgundavia was working on it.
<ogra> mathiaz, i'm always for shortening meetings :) so i wont stand in your way, but ask richEd
<tjaalton> ok, I think the ati issue deserves to be mentioned
 * ogra has to go for dinner ....
<Burgundavia> tjaalton: I was, but feel free to add something
<Burgundavia> tjaalton: I have no idea what you are talking about
<soren> Burgundavia: There's a CC meeting going on, by the way.
<Burgundavia> soren: I am there, yes
<tjaalton> Burgundavia: ok, I will
<jdong> any archive admins up for the NEW queue at the moment?
<seb128> jdong: yes?
<jdong> seb128: the mpeg4ip thing
<seb128> jdong: ah, looking
<jdong> seb128: thanks :)
<seb128> you're welcome
<jdong> from debian-multimedia, so it's a multiverse thing :)
<seb128> jdong: it's not good
<jdong> seb128: oh what needs to be fixed?
<seb128> message.c: MPL (v1.1)
<seb128> mpeg4ip_utils.h: MPL (v1.1)
<seb128> in lib/utils
<seb128> just starting to looking but the debian/copyright states the source is GPL
<jdong> hmm
<seb128> gnu/getopt.c: LGPL (v2 or later) (with incorrect FSF address)
<seb128> gnu/getopt1.c: LGPL (v2 or later) (with incorrect FSF address)
<jdong> yeah COPYING shows a more detailed breakdown of the licenses, it's not just GPL2 as debian/copyright says
<seb128> right
<seb128> and those license should be distributed in the tarball
<seb128> COPYING has only the MPL
<cjwatson> incorrect address> they probably copied from libc which still has the old address in CVS
<cjwatson> the recommended text in the GPLv3 points to a URL so this should stop happening eventually
<seb128> jdong: the debian/copyright should also list the copyright holders
<seb128> jdong: I've rejected it, could you get the copyright and license issues fixed and reupload?
<jdong> seb128: ok sure, I'll deal with that :)
<seb128> jdong: thanks
<tjaalton> can restricted-manager be run from a script? (like during installation)
<tjaalton> ah, seems like it
<asac> seb128: could you please look at mozilla-devscripts (source NEW) too ... its really a tiny thing for producing mozilla tarballs for a date/branch et al.
<seb128> asac: sure
<pitti_live> bdmurray: confirmed, avahi crashes on amd64 live here, too
<pitti_live> hm, we still don't have a background image on the live system, and neither on fresh installs, I suppose
<bdmurray> pitti_live: okay, I submitted bug 181822 about it
<pitti_live> bdmurray: right, I saw it; thanks
<ubotu> Launchpad bug 181822 in avahi "[hardy] avahi-daemon segfaults when booting LiveCD from 20080109" [Undecided,New] https://launchpad.net/bugs/181822
<bdmurray> pitti_live: doe your update-notifier present an error also?
<pitti_live> yes
<pitti_live> I see a stop sigh
<pitti_live> sign, even
<pitti_live> mvo: ^ known?
<bdmurray> I have not submitted that one yet
<pitti_live> indeed the desktop is still pretty broken
<pitti_live> the tracker notification icon drives me up the wall, update-notifier, desktop background, there's a glitch in drawing the panel, and the desktop starts up horribly slowly
<somerville32> pitti_live, there is no background image?
<pitti_live> but at least it works in general, for alpha3
<pitti_live> somerville32: no, same problem as in alpha-2
<pitti_live>  /usr/share/backgrounds/warty-final-ubuntu.png
<pitti_live> exists, though
<somerville32> pitti_live, I don't see anything in the release notes
<somerville32> What was the problem?
<somerville32> (or is)
<pitti_live> somerville32: I don't know
<somerville32> I think I broke it, lol
<pitti_live> hm, where did restricted-manager go? did someone unseed it?
<pitti_live> seb128: do we deliberately install gparted?
<pitti_live> well, I guess it does make sense in the live system
<somerville32> I use it. it works really well
<cjwatson> gparted was included in live by popular demand
<seb128> pitti_live: yes, it's in the live seed
<cjwatson> bug 93604
<ubotu> Launchpad bug 93604 in ubuntu "gparted is missing in iso image for feisty" [Undecided,Fix released] https://launchpad.net/bugs/93604
<seb128> and it can be handy ;-)
<pitti_live> thanks
<pitti_live> seb128: right
<bdmurray> pitti_live: will you be submitting a bug about update-notifier or shall I?  I don't see one at the moment.
<pitti_live> bdmurray: if you are at it, please do; otherwise I'll do it once I return to my main system
<pitti_live> calc: any luck with OO.o + gcj-4.1? OO.o doesn't work at all ATM; not necessarily a release blocker, but nasty
<seb128> pitti_live: what about desktop background and glitch in drawing the panel and tracker?
<pitti_live> seb128: background> well, there is none by default
<seb128> pitti_live: gconftool-2 --get /desktop/gnome/background/picture_filename ?
<pitti_live> ubuntu-wallpapers is isntalled, and if I open the background dialog the elephant skin is there
<pitti_live> I clicked on it, and it works
<pitti_live> but it's not the default
<pitti_live> seb128: need to reboot, I already set it by accident
<seb128> pitti_live: gconftool-2 --unset /desktop/gnome/background/picture_filename
<seb128> pitti_live: gconftool-2 --get /desktop/gnome/background/picture_filename ?
<seb128> unset should give you the default value
<pitti_live> right, after unset the bg disappears
<pitti_live> /usr/share/backgrounds/simple-ubuntu.png
<pitti_live> ^ default
<seb128> no such image installed?
<pitti_live> nope; it's called /usr/share/backgrounds/ubuntu-simple.png :)
<seb128> pitti_live: grep "simple-ubuntu" /usr/share/gconf/* -r ?
<pitti_live> /usr/share/gconf/defaults/16_ubuntu-wallpapers
<seb128> you get your buggy package
<pitti_live> dpkg -S -> ubuntu-wallpapers
<pitti_live> somerville32: so it's indeed your bug, hehe
<somerville32> no
<pitti_live> seb128: tracker icon> well, it's there permanently, bothers me with notifications, and doesn't go away even if I disable tracker entirely
<somerville32> well, I don't dispute that
<seb128> somerville32: you did the upload which changed that apparently
<somerville32> but simple-ubuntu.png isn't the default background
<pitti_live> seb128: something for the bug tracker, I think I filed one already; nevermind, not RC, just whining
<calc> pitti_live: i hadn't looked into it yet since it was around 3am at the time and slangasek thought it was getting a bit late to wait before releasing the cd
<seb128> pitti_live: are the notification about index merges?
<pitti_live> somerville32: (just kidding, don't worry)
<seb128> somerville32: /usr/share/gconf/defaults/16_ubuntu-wallpapers has /usr/share/backgrounds/ubuntu-simple.png apparently
<pitti_live> seb128: it says 'starting index', 'finished indexing', 'click me', etc.
<seb128> pitti_live: hum, k, yeah better to file that in launchpad for upstream
<calc> pitti_live: and gcj-4.2 worked fine on my box already so i wouldn't be able to tell a difference afaik if 4.1 would fail also...
<pitti_live> calc: ok
<bdmurray> pitti_live: I've submitted bug 181827 about update-notifier if you can confirm it
<ubotu> Launchpad bug 181827 in update-notifier "[hardy] error communicating with backend using LiveCD" [Undecided,New] https://launchpad.net/bugs/181827
<pitti_live> calc: so, let's release-note this instead, shall we?
<calc> pitti_live: yea that will be fine
<seb128> pitti_live: the panel drawing issue looks like an xorg bug? because that code didn't change recently afaik
<calc> pitti_live: whatever is causing the out of memory/ice related issues on amd64/lpia is probably not easily reproducible
<mvo> pitti_live: what version of update-notifier?
<mvo> pitti_live: I fixed one of the issues with the upload of 0.70.1
<pitti_live> bdmurray: I can't; seems you reported an upstream bug, not a distro one
<mvo> pitti_live: what does the tooltip say on the u-n icon?
<pitti_live> mvo: "Error communicating with teh backend"
<mvo> meh
<pitti_live> mvo: u-n is 0.70.1
<bdmurray> pitti_live: it looks like a distro one to me
<mvo> pitti_live: what is the output of /usr/lib/update-notifier/apt-check
<pitti_live> bdmurray: right, sorry; wasn't logged in properly; confirmed now
<somerville32> seb128, I was told that the gconf setting was in another package (which I didn't touch) but it seems that that person was wrong
<somerville32> seb128, It seems more like the first item in in the xml file becomes the default
<pitti_live> mvo: nothing at all
<somerville32> Unless someone else modified the other package
<bdmurray> gdm on the Live CD is also showing hibernate as an option
<mvo> pitti_live: I rsync a CD now and try to reproduce that when its here
<seb128> pitti_live: dpkg -S /usr/share/gconf/defaults/16_ubuntu-wallpapers
<seb128> ?
<pitti_live> seb128: see above, it's in ubuntu-wallpapers
<mvo> pitti_live: I really wonder what might cause that it does output nothing
<seb128> pitti_live: ah right, looks like they are doing something very weird
<seb128> somerville32: debian/wallpapers2gconf.xsl in ubuntu-wallpapers sets the default
<seb128> what a weird and complicated way to do that
<seb128> the normal way is to have one line in debian/binary.gconf-defaults which contains the name of the key and the value
<somerville32> debian/wallpapers2gconf.xsl is the template
<seb128> why do you need a template?
<seb128> you should have
<somerville32> I think the first item in ubuntu-wallpapers.xml.in defines the default
<seb128> debian/ubuntu-wallpapers.gconf-defaults
<seb128> and one line by key there
<somerville32> seb128, I've just started handling this package. I'll ask the previous maintainers if there was a specific reason they did it this way
<seb128> somerville32: right, and this one is buggy
<seb128> somerville32:     <filename>/usr/share/backgrounds/simple-ubuntu.png</filename>
<somerville32> seb128, There was a typo in ubuntu-wallpapers.xml.in
<somerville32> seb128, but I think the first item in ubuntu-wallpapers.xml.in becomes the default
<somerville32> seb128, so I've also switched it around so that elephant is first
<seb128> somerville32: right, the default is simple-ubuntu and the filename on the disk ubuntu-simple
<seb128> somerville32: the bzr version has simple-ubuntu listed first
<somerville32> seb128, I just pushed the new version
<somerville32> rev 13
<seb128> somerville32: ok, thanks
<seb128> somerville32: sorry for not being clear before ;-)
<somerville32> seb128, Do you still want me to migrate how things are done now to the way you described?
<seb128> somerville32: let me know if there is a good reason for the xsl, otherwise I suggest using a standard gconf-defaults file to set the default
<somerville32> seb128, okay
<seb128> somerville32: well, that would be a 1 line setting rather than a whole xsl
<seb128> looks easier and cleaner to me, but feel free to disagree
<somerville32> dholbach, We're discussing ubuntu-wallpapers. Is there any reason why it is setup the way it is now instead of using a standard gconf-defaults file to set the default?
<dholbach> somerville32: it wasn't my change - I think I recall somebody setting it up that way because he key had to be changed for new wallpapers every time
<dholbach> somerville32: I might be wrong though
<seb128> somerville32: if it's working feel free to let it this wya
<seb128> way
<somerville32> I hope it isn't too to get the new wallpapers package into alpha
<somerville32> Otherwise kwwii might beat me with a stick :)
<somerville32> seb128, Are you going to sponsor or should I file a bug in the queue?
<seb128> somerville32: I've to run right now, maybe pitti can sponsor it, otherwise I'll be on IRC in a few hours and look at it then
<phomes> seb128: is there any chance to get gnome-games updated past 2.20.1 for gutsy? There is a frequent crasher when people play chess/sudoku while updating the system
<somerville32> pitti, <3 :)
<pitti> somerville32: where's the source pacakge or debdiff?
<seb128> phomes: I've read the bug, depends of the list of changes, we can still backport the patch otherwise
<seb128> I've to go now but I'll have a look later
<somerville32> pitti, it is bazaar branch
<somerville32> bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-wallpapers/ubuntu/
<pitti> somerville32: right; but can you please build a source package out of it and put it somewhere?
<somerville32> pitti, Yes but I thought the workflow with bazaar was that sponsor just use the nifty bazaar plugin stuff
<pitti> somerville32: takes me longer to check out and build the source, though
<somerville32> pitti, I'll upload to revu
<pitti> (sorry, busy with three other things, trying to optimize)
<pitti> somerville32: put a debdiff into a pastebin, please
<somerville32> pitti, okay
<pitti> that should be quickest
<somerville32> pitti, Will a bzr diff between the two revisions be the same?
<pitti> not sure, the packaging might do some control.in tricks or other stuff
 * pitti doesn't know the artwork packages, sorry
<somerville32> pitti, http://pastebin.ca/849655
<pitti> somerville32: why do the binary files differ?
<somerville32> pitti, renamed it
<pitti> somerville32: ah, I see
<pitti> bryce, tjaalton: hm, my xorg.conf on the live system looks weird; I have empty monitor and device sections (just identifier), and synaptics isn't configured
<bryce> pitti, I believe the new x configures those automatically now so the sections aren't required or listed
<bryce> pitti: the question is, does X work?
<pitti> bryce: right, but why does dexconf write empty sections then? if that's intended, it's all good, but it might point to a bug, thus I asked
<cjwatson> lamont: how come libvirt built on lpia at 0.3.0-0ubuntu2, but appears to be P-a-sed now?
<pitti> bryce: well, it works except for the touchpad not being configurable (no synaptics)
<pitti> bryce: thus you cannot disable tap-to-click in teh mouse prefs, etc.
<bryce> pitti: hmm good point
<lamont> cjwatson: it's lucky??
 * lamont looks
<bryce> pitti: can you file a bug about this?
<pitti> bryce: I can, and I will, I just wanted to discuss what the expected behaviour is
<bryce> ok; I'm not up on all the changes that occurred over the holidays, but timo probably can speak to it.  I think he's afk at the moment.
<pitti> bryce: ok, no problem
<bryce> my guess is that X still needs to have the sections present, but doesn't require anything in them, but that's just a guess
<bryce> for the synaptics issue, that sounds like perhaps an oversight
<pitti> ideally X would autodetect it, I guess
<lamont> cjwatson: which of these need/want lpia:
<lamont> +# xen stuff
<lamont> +%xen: i386                                                           # [ANAIS]
<lamont> +%xen-3.0: amd64 i386                                                 # [ANAIS]
<lamont> +%xen-3.1: amd64 i386                                                 # [ANAIS]
<lamont> +%xen-unstable: amd64 i386                                            # [ANAIS]
<lamont> +%libvirt: amd64 i386                                                 # b-d libxen3.1-dev
<pitti> bryce: right, I just wnated to file a bug about synaptics; the other is just cosmetical (if at all)
 * lamont bets "all"
<lamont> hrm... actually, most of those were just moves
<cjwatson> lamont: I have no clue, but either it should be added to P-a-s or the packages should be NBSed :)
<cjwatson> Mithrandir: ^-- clue please?
<pitti> somerville32: I change the version number to 0.20, ok?
<somerville32> pitti, Any reason why?
<pitti> somerville32: that's the standard versioning scheme so far
<lamont> cjwatson: poke me when you get an answer.  fwiw, libvirt was the only change in that commit
<somerville32> It is a small bug fix. I dunno if it requires an entire new major version but I don't feel strongly about it
<lamont> which happened 23 sep 2007
<somerville32> Did you modify anything else?
<pitti> bryce: ah, it's there already: bug 173411
<ubotu> Launchpad bug 173411 in xorg "[Hardy][Regression] Touchpad vertical scroll does not work" [Medium,Confirmed] https://launchpad.net/bugs/173411
<slangasek> stgraber: there seems to be a problem with the ISO tracker's refresh of bug data
<stgraber> slangasek: I know, it's in Ng's todo list :) basically the LP syncronisation script not running (or crashing for an unknown reason as it works here)
<slangasek> ok
<Keybuk> Mithrandir: you know how you're evil, and know how to do evil things?
<Keybuk> if I have a file created by dd on a disk, how do I mount it ? :)
<spacey> mount -o loop file ./mount
<spacey> after you format it ofcourse
<somerville32> pitti, Let me know when you've uploaded it so that I can double check all is well :)
<pitti> somerville32: sorry, forgot to upload it, thanks for the ping; in progress now
<Burgundavia> slangasek: you around?
<slangasek> Burgundavia: hiya
<tjaalton> pitti: synaptics was ripped off (by debian) hoping that input-hotplug would've been here earlier
<pitti> tjaalton: ah, I see
<tjaalton> pitti: but it's the next thing now that xresprobe & discover are gone
<pitti> you mean switching to input hotplug? yay
<tjaalton> sure
<pitti> tjaalton: that means the keyboard layout will be confirured in a hal fdi, right?
<tjaalton> I'm using it myself on three machines, but unfortunately I don't have a laptop with a touchpad
<tjaalton> pitti: actually, the ultimate solution would be to configure it on the fly
<Burgundavia> slangasek: timeframe on the actual release?
<tjaalton> so no need to duplicate the information
<slangasek> Burgundavia: hour or two, I think.  You still release-noting?
<Burgundavia> I was going to do the Firefox stuff, but I need screenshot, as I don't have hardy running yet
<Burgundavia> alpha 2 did not have firefox 3, yes?
<Burgundavia> evand: you still editing?
<slangasek> hmm, I don't have ff3 installed yet; I can install that quickly enough, what do you need screenshots of?
<Burgundavia> native forms would be nice
<somerville32> slangasek, So alpha 3 won't have a desktop background either? :P
<evand> Burgundavia: done now
<slangasek> Burgundavia: sorry, what are native forms?
<slangasek> dear ff3, don't tell me that firefox needs restarted after install when it wasn't running before I installed it
<broonie> slangasek: Obviously the assumption is that if it's not running that's because it crashed.
<slangasek> somerville32: um... the desktop will have /a/ background, to what are you referring specifically?
<slangasek> broonie: heh
<somerville32> slangasek, I'm pretty sure pitti said that the desktop background was broken for Alpha 2
<somerville32> slangasek, I just uploaded the fix
<Burgundavia> slangasek: ok, ff3 stuff added, please add a picture and you are ready
<pitti> somerville32: well, it's hardly a release blocker :)
<slangasek> somerville32: ok; we don't have any reason yet to reroll the images, so yeah, that won't be fixed for alpha3
<somerville32> I hope kwwii does't notice, lol
<Burgundavia> slangasek: am off for about an hour
<slangasek> Burgundavia: ok, cheers
<somerville32> Also, on http://iso.qa.ubuntu.com/qatracker/build/xubuntu/all, the bug image links to https://bugs.launchpad.net instead of the bug.
<somerville32> bug #181794
<ubotu> Launchpad bug 181794 in totem "Xubuntu's instance of totem fails" [Low,Invalid] https://launchpad.net/bugs/181794
<slangasek> somerville32: yes, that's the issue stgraber and I discussed a half hour up
<Usiu> Does Ubuntu 7.10 installer supports lvm2 ?
<Usiu> When do You plan to release 8.04 ?
<thegodfather> Usiu: yes. on alternate and server CD
<thegodfather> Usiu: sometime in Apr 2008
<thegodfather> https://wiki.ubuntu.com/HardyReleaseSchedule
<Usiu> thegodfather, desktop iso with alternate installer ?
<thegodfather> Usiu: yes. that one should
<Usiu> thegodfather, thanks and sorry for disturbing :)
<thegodfather> np
<slangasek> Burgundavia: is that screenshot what you were looking for?
<oojah> I'm working on a Main Inclusion Request - is this the right place to be asking about that?
<Burgundavia> slangasek: be nice to get the tab theme as well, if possible, plus maybe have a page with more than one button on it
<slangasek> suggested pages?
<Burgundavia> the bug reporting page (the advanced one) maybe
<slangasek> that page seems to have only one form button, though it has other form widgets if that's what you want to show
<slangasek> Burgundavia: better?
<mvo> pitti: I can reproduce the update-notifier problem now, have you filed a bugreport about it already?
<ScottK> pitti: If you have a spare moment, I'd like to ask your advice on my amavisd-new MIR.  No problem to wait if you're busy.
<afflux> time() turned 1200000000, happy new century everyone ;)
<mvo> python -c 'import time; print time.time()'
<mvo> 1200000206.07
<Company> someone using unix time in the gnome clock!
<afflux> no. /join #1200000000 :P
<mvo> pitti: anyway, fixed now
<slangasek> calc: well, I see that OOo built successfully on i386 and was installed.  dunno if we should see about whether the amd64 buildd is tweakable to not OOM?
<pitti> mvo: apt check -> /bin/true -> *chuckle*
<pitti> mvo: didn't we have a casper hook to disable u-n in the live system?
<pitti> mvo: there's a bug report, yes
<pitti> mvo: bug 181827
<ubotu> Launchpad bug 181827 in update-notifier "[hardy] error communicating with backend using LiveCD" [Undecided,Confirmed] https://launchpad.net/bugs/181827
<stgraber> The tracker is syncing with LP again, so you bug infos and bug tagging (iso-testing tag) are working again
<calc> slangasek: i don't know it built fine on my amd64 without failing
<calc> slangasek: so the OOM/ICE issue is flaky
<slangasek> well, yes
<slangasek> it depends on the available memory on the buildd at the time :)
<calc> hmm yea probably so, though it probably shouldn't be using that much ram to begin with
<calc> i only have 2GB memory on my box and firefox eats most of it most of the time
<calc> so the buildd must have been fairly low on ram?
<slangasek> it stands to reason
<calc> does one of the amd64 buildds have more ram than the others, if so we could requeue it for that machine
 * Fujitsu knows the i386 buildds vary somewhat, but isn't sure about amd64.
<slangasek> I'm the wrong person to ask :)
<calc> oh ok
<emgent> keescook, saw #181853 ?
<keescook> emgent: excellent.  please report that to upstream too, if they don't already know.
<emgent> sure, it's 0day
 * keescook nods
<emgent> i will report to debian too
<emgent> i'm writing patch
<emgent> subscribed
<emgent> Fujitsu, try to see
<emgent> keescook, see query :P
* slangasek changed the topic of #ubuntu-devel to: Archive: OPEN | Hardy Alpha 3 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
#ubuntu-devel 2008-01-11
<slangasek> calc: so bug #131526 is fixed in OOo 2.3.1-3ubuntu1, right?  (supposedly fixed upstream in 2.3.1)
<ubotu> Launchpad bug 131526 in openoffice.org "[gutsy] OpenOffice crashes/hangs with some Gtk themes (e.g. Crux)" [Undecided,Fix released] https://launchpad.net/bugs/131526
<calc> slangasek: yes
<calc> it was also fixed in gutsy updates
 * slangasek nods
 * lamont looks to see if alternate ports images were built for alpha3
<slangasek> they weren't published, and I recall seeing some d-i failures which suggested to me it wasn't going to be worth chasing
<lamont> slangasek: yeah - I'll just fetch a current daily and see how bad it is.
<slangasek> that's the same as would've been released with the alpha had we done one, so. :)
<Keybuk> lamont: open office didn't compile on hppa? :)
<lamont> Keybuk: apparently someone is actually working on the ia64 port though
<lamont> sigh.  I need to find a better place to squat for bandwidth.
<calc> it claims hppa built ooo
<lamont> 150KB/s sucks
<StevenK> lamont: That's all I get.
<lamont> calc: it just skips the acutal binary.  ENOTRAMPOLINE
<calc> heh
<slangasek> SIGPOLEVAULT
<calc> failed on amd64, lpia, powerpc, sparc, i know how to fix powerpc build properly, amd64/lpia/sparc are compiler issues afaict
<calc> well technically fixing the powerpc build is thoroughly disabling java
<lamont> calc: skipping all the binaries does make it build better.  OTOH it's not so useful :-)
<lamont> hence hppa builds just fine...
<lamont> StevenK: but you live in the land of no bandwidth, don't you?
<jdong> I'm guessing I'm out of context, but doesn't skipping all the binaries defeat the purpose of building something? :D
 * lamont confirms that StevenK does.
<lamont> jdong: "oo.o built on hppa" is the context
<lamont> it builds because it doesn't build binaries... so you get a package, just not any application.
<StevenK> lamont: Hmph
<lamont> see.  no problem.
<lamont> StevenK: .au.. bandwidth sucks.
<jdong> lamont: meh hppa people don't need OOo anyway :D
<lamont> jdong: if they do, they can run it remotely on a faster comptuer.
<jdong> lamont: can we do the same with eclipse too?
<jdong> :)
<lamont> jdong: nah - we just don't build that
<jdong> even better :)
 * cjwatson unbreaks the d-i powerpc build in bzr
<cjwatson> the other failures are really dep-waits on kernel bits
 * cjwatson trims a couple of hundred megabytes off openssh's build-deps
<lamont> cjwatson: thank you
<cjwatson> Colin Walters told me back in the dawn of time that it needed libgnomeui2-dev to build the GTK2 askpass, and evidently I never bothered to check
<Keybuk> one could argue that GTK2 askpass is deprecated by seahorse
<slangasek> tsk, subversive redhatters trying to make everything use gnome
<cjwatson> Keybuk: one could argue that openssh should build its own stuff even if some other optional component is trying to replace it ;)
<Keybuk> cjwatson: it already has a simple X one though, no?
<Keybuk> it doesn't *realllly* need a GTK2 one as well
<cjwatson> Keybuk: no
<Keybuk> I could get Mirco to knock up ssh-askpass-gl ? :)
<cjwatson> you're thinking of ssh-askpass which was a separate source
<Keybuk> ah
<cjwatson> openssh itself contains GTK1 and GTK2 askpass implementations
<cjwatson> ssh-askpass-gl> go ahead, I'll keep on building ssh-askpass-gnome, you just don't have to include it :)
<cjwatson> it's a separate binary package
<cjwatson> (I do think ssh-askpass-gl would be cool albeit probably total overkill ;-))
<Keybuk> it could look like the movie os "ACCEPTED" when done
<slangasek> haha
<Keybuk> ACCESS DENIED
<Keybuk> oh damn, I just typed sab<tab> to check ...
<Keybuk> quick, need a way to wipe his logs off this conversation ;)
<Burgundavia> Keybuk: if sound juicer does not spin my cd down to 1x when playing a cd, is that an sj or a kernel bug?
<Keybuk> are you sure you haven't just taken speed?
<Burgundavia> Keybuk: pretty certain, but let me check with the gf
<Keybuk> I'd file it as soundjuicer
<Burgundavia> nope, she didn't
<Keybuk> but you'd probably need to debug and fix that one yourself
<Burgundavia> ugh
<Keybuk> since I honestly doubt anyone else anywhere in the universe would be able to replicate it
<Burgundavia> probably
<Burgundavia> oh wait, now she is saying that she didn't think I notice :)
<slangasek> that you were given speed?
<Burgundavia> yep
<Burgundavia> and how would I go about debugging this?
<Keybuk> are you hungry?
<Burgundavia> yes, it is almost dinner time
<Keybuk> then you are unlikely to be on speed
<Burgundavia> right, glad to know, having never done speed, I didn't know that
<probleme> i have a bug
<probleme> http://hiboox.com/lang-fr/resultat.php?img=mj86a8br.png&error=0#
<probleme> (livecd gusty)
<probleme> that's all :)
<Burgundavia> probleme: you need to file it in the bugtracker on launchpad
<Burgundavia> although I am not certain what kind of bug you think you have
<probleme> Burgundavia: don't know how to do this
<Burgundavia> please join #ubuntu-bugs
<probleme> #ubuntu-bugs/j
<gQuigs> references: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/51869, https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/18355
<ubotu> Launchpad bug 18355 in linux-source-2.6.15 "Add the badram patch to the Ubuntu kernel" [Wishlist,Invalid]
<gQuigs> any chance we could see a badram patch package, (not installed by default)
<gQuigs> the whole linux-patch-* thing
<euther> join #ubuntu+1
<dholbach> good morning
 * slangasek waves
<ion_> Hi
<dholbach> hiya ion_, hey slangasek
<pitti> Good morning
<ion_> Hi
<StevenK> pitti: Morning pitti
<StevenK> pitti: So, do I have any chance of getting midbrowser promoted?
<pitti> StevenK: is that thing using the ffox 3 codebase and xulrunner-1.9?
<pitti> hm, I can't see a xulrunner dependency
<pitti> StevenK: eventually it boils down to (1) we need it and promote it and (2) asac will support it
<pitti> StevenK: less a question about 'if', rather 'how'
<StevenK> Right.
<StevenK> pitti: And now liferea build depends on it, because some silly dork uploaded without checking first.
<StevenK> Well, liferea on lpia
<StevenK> pitti: Would you like a bug about it?
<Fujitsu> in 5
<Fujitsu> Gah.
<pitti> StevenK: you mean a bug about 'please migrate midbrowser to ffox3 and xulrunner?
<siretart> against which package should bugs like this be filed? http://paste.ubuntu-nl.org/51536/report/
<StevenK> pitti: No, I mean a bug "Please promote midbrowser"
<pitti> StevenK: we need a MIR bug for that, yes
<scizzo-> any dbus developer or packager for dbus around?
<pitti> scizzo-: what's the problem?
<scizzo-> pitti: well mostly that f-spot does not seem to call on "dbus-laung f-spot"
<scizzo-> pitti: I am not sure if it is f-spot or if it is a dbus error...
<pitti> scizzo-: can you explain further, please? what does dbus-launch have to do with f-spot?
<pitti> dbus-launch is for creating a session bus, but gnome-session takes care of this
<pitti> f-spot shouldn't need to fiddle with that
<scizzo-> pitti: well a normal start of f-spot gives the error: http://pastebin.se/192746
<scizzo-> which in this case state that it is not really launching dbus-launch correctly....however when running dbus-launch f-spot in a terminal f-spot opens and without problems
<scizzo-> well I got one gdk-pixbuf
<scizzo-> (f-spot:1603): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.
<pitti> scizzo-: hm, are you actually using gnome?
<scizzo-> thats about it
<scizzo-> pitti: no I am not....I am running xfce....xubuntu
<pitti> scizzo-: and xfce does not launch a session bus by default?
<scizzo-> pitti: let me check
<pitti> scizzo-: if not, you should install dbus-x11
<pitti> (and Xubuntnu should then do that by default; that's worth a bug report)
<scizzo-> pitti: let me try that
<scizzo-> there are dbus-daemon running not sure if it is the same thing
<scizzo-> also I have dbus-x11 installed
<scizzo-> if I move the old f-spot dir from .gnome2/ I get some other traces
<scizzo-> one sec
<scizzo-> http://pastebin.se/192747
<scizzo-> the outcome is the same though
<pitti> scizzo-: there should be a system dbus daemon, right
<pitti> but if that doesn't work, you'd have much worse problems
<pitti> scizzo-: did you restart your session after installing dbus-x11?
<scizzo-> I am fearing a "scizzo- reinstall the machine" answer
<scizzo-> pitti: it was already installed
<pitti> hm
<pitti> no real idea then, I'm afraid; maybe you can ask the XFCE devs about the lack of a dession dbus
<scizzo-> pitti: I can try with a completely new user....?
<pitti> and file a bug maybe, too
<gpocentek> the dbus session is launched in xubuntu
<pitti> scizzo-: you can try, but there's a high chance that this won't help
<gpocentek> xfdesktop/thunar need it
<pitti> hey gpocentek!
<pitti> good to know
<gpocentek> hello pitti :)
<scizzo-> gpocentek: aaa...right
<scizzo-> I am not really a years of used XFCE user...just trying to error search the f-spot stuff
<scizzo-> seems to be the same result on the test user
<scizzo-> I will check with #xubuntu-devel
<scizzo-> thanks for all the thelp
<scizzo-> s/thelp/help/g
<scizzo-> not really sure what is happening
<pitti> tjaalton: I'd greatly appreciate advice about bug 179638
<ubotu> Launchpad bug 179638 in xfree86-driver-synaptics "Please sync xfree86-driver-synaptics 0.14.7~git20070706-1  (universe) from Debian unstable (main)" [Undecided,Incomplete] https://launchpad.net/bugs/179638
<DktrKranz> Can a buildd admin give-back freesci on i386? Thanks.
<pitti> DktrKranz: done
<DktrKranz> pitti: thanks.
<tjaalton> pitti: huh, hardy has 0.14.7~git20070706-1ubuntu1?
<pitti> no, 0.14.4-1
<pitti> ah, the binary, right
<pitti> tjaalton: the confusion is that Debian builds xserver-xorg-input-synaptics from the xfree86-driver-synaptics source, while we build it from the xserver-xorg-input-synaptics source
<tjaalton> right
<pitti> tjaalton: so I was asking if we could actually use Debian's source and drop our's to reduce the delta
<tjaalton> I've asked mattia if he'd like to rename it, but got no reply
<tjaalton> that works too
<pitti> right, renaming it in Debian would be nicer, of course
<tjaalton> but a sync is not doable
<tjaalton> there are changes
<pitti> tjaalton: right; that's part of the question in the bug: should we merge our remaining delta to the xfree86-driver-synaptics source and forward the rest to Debian/upstream, or go with our own packaging?
<pitti> tjaalton: I'm fine with either (prefering to use the Debian source, of course), but I'd like to remove one of the source packages from Ubuntu to avoid confusion and sync-source.py breakage
<tjaalton> maybe we should merge, and then if the source is renamed we'd get it again
<pitti> yeah
<tjaalton> hmm, so if the only diff between those packages is that the tarball is renamed, it's pretty easy to do :)
<pitti> tjaalton: I guess bug 180539 is ok
<ubotu> Launchpad bug 180539 in xserver-xorg-video-amd "Please sync xserver-xorg-video-amd 2.7.7.4-1  (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/180539
<pitti> the changelog looks reasonable
<tjaalton> yeah, that's fine
<pitti> thanks
<mvo> Riddell: kde 4 release today? is that correct?
<tjaalton> mvo: judging by the flood of blog posts I'd say yes :)
<StevenK> pitti: I daresay the rationale and so on is well known for midbrowser. Do you want to spell it out anyway
<StevenK> ?
<pitti> StevenK: just file the bug and say it's required by mobile; one sentence is enough
<StevenK> pitti: Mmm, you want the paper trail.
<StevenK> pitti: Bug 181959
<ubotu> Launchpad bug 181959 in midbrowser "Please promote midbrowser to main" [Undecided,New] https://launchpad.net/bugs/181959
<StevenK> pitti: And if you could add ppm in source NEW to your things to look at, not urgent.
<pitti> StevenK: yes, still doing syncs; I'll get to NEW later
<StevenK> Oh yeah, Friday is your archive day. :-)
<pitti> *sigh* yeah :)
<\sh> moins
<pitti> hey \sh! welcome back to MOTU
<StevenK> Hey \sh
<\sh> pitti: thx...a wonderful birthday present that is :)
<pitti> ooh! happy birthday! *hug*
<mvo> happy birthday \sh \o/
<sladen> happy neu jahr mvo \o/
<pitti> mvo: can you please advise me about bug 179876?
<ubotu> Launchpad bug 179876 in compizconfig-backend-kconfig "[Remove] Please remove compizconfig-backend-{gconf,kconfig} from hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/179876
<mvo> hey sladen, happy new yeah for you too
<mvo> pitti: meh
<\sh> mvo: thx :)
<mvo> pitti: looking into it now
<mvo> pitti: I will rename out packages to match the debian name,that should fix the issue
<pitti> mvo: right; please let me know when this is done, then I'll remove our obsolete source
<pitti> but better match debian's names for easier merging and syncing
<pitti> mvo: thanks
<mvo> pitti: ok, doing that now, will take a bit to update all depends etc
<pitti> mvo: oh? it's not just about renaming the source package? binary packages, too?
<linuxboy> is Ben Collins hangs around ?
<mvo> pitti: yes, but its not too bad, few dependencies
<linuxboy> I got a kernel issue in gutsy
<dholbach> linuxboy: try #ubuntu-kernel or filing a bug in Launchpad
<linuxboy> dholbach: tried ubuntu-kernel
<dholbach> a bug report is the best place - information on IRC tends to get lost easily
<linuxboy> oh
<Riddell> mvo: certainly is! are you excited?
<Keybuk> *blink*
<Keybuk> our X maintainer is "surprised" when changing a monitor "just works" ?! :)
<Keybuk> worrying
 * Keybuk grins at bryce
<tjaalton> hehe
<mvo> Riddell: yes! I I'm curious to see it
<ion_> :-D
<StevenK> Keybuk: Would you mind renewing my membership in ubuntu-dev?
<Keybuk> StevenK: yes
<StevenK> Keybuk: You would mind? :-)
<Keybuk> we don't renew ubuntu-dev memberships
<StevenK> Oh, right
<Keybuk> they should all be expired
<Keybuk> you'll remain a member via "motu" where you don't expire until 2009-01-16
<StevenK> Okay, fair enough
<Keybuk> although someone seems to have renewed some
<sladen> however, the world is scheduled to end 3 weeks before that, you'll never actually get to /see/ the expiration.
<Keybuk> sladen:  it is?
<Keybuk> are Debian releasing again?
 * StevenK smirks
 * Keybuk cleans up ubuntu-dev
<StevenK> Keybuk: But they can't delete teams, I thought?
<Keybuk> do we need to?
<pitti> seb128: libbeagle binary NEWed FYI
<seb128> pitti: thanks, you can also demote beagle to universe
<pitti> \o/
<seb128> ;-)
<pitti> -- hardy/main build deps on beagle-dev:
<pitti> f-spot
<pitti> that's the last rdep in main
<pitti> seb128: I guess that'll be s/beagle-dev/lib&/ ?
<seb128> pitti: the API has changed it likely needs code changes
<persia> pitti: Re: process-removals.  Does this mean that we don't need to manually chase Debian removals and file bugs anymore?
<pitti> persia: not sure, it seems to lag behind a bit; other removals that I did today didn't turn up there
<pitti> persia: but it might just lag a bit
<seb128> pitti: we can build it without beagle for now though, there is a f-spot sponsor request bug open, maybe that is already changed there
<persia> pitti: How often do you run it?  I can certainly refrain from opening bugs for packages that haven't been removed for > 2 weeks (or some similar rule).
<pitti> persia: I try to remember every week
<pitti> persia: do you have an automated tool to track them in Debian?
<persia> pitti: Thanks.  I'll be sure to only request removals for things pending over two weeks then.  I track http://qa.ubuntuwire.com/multidistrotools/ to identify removal candidates.
<persia> There is also http://ftp-master.debian.org/~joerg/removals/removals.rss, which might be a useful input to something.
<tjaalton> pitti: xfree86-driver-synaptics merge uploaded
<tjaalton> versioned -1ubuntu2 so the binary is newer than what we have
<pitti> tjaalton: thanks, you rock
<pitti> so once this is in I can remove the old source
<pitti> tjaalton: so we did have a remaining delta?
<pitti> or is it just to bump the version number?
<tjaalton> yes we have a delta
<pitti> ok
<tjaalton> couple of patches
<mvo> pitti: compizconfig-backend-{gconf,kconfig} uploaded now along with a new compiz with updated depeendencies
 * pitti hugs mvo
<hunger> When will the ooo l10n debs for version 2.3.1 become available? OOo is installable for days now, yet I can not update since the l10n debs still seem to be missing.
<mvo> pitti: do you want to a abugreport about the removal of the now outdated libcompizconfig-backend-{gconf,kconfig} from hardy
<pitti> mvo: there is one about that topic already, that's fine
<mvo> ok, nice. thanks pitti
<seb128_> re
<seb128> grrr at network restart during upgrade
<pitti> yay nm
<pitti> it should rather restart on resuming from sleep (always have to do that manually)
<mvo> pitti++
<mdz_> pitti: that seems to work fine for me
<mvo> not for me (static configuration)
<pitti> I added it to /etc/pm/sleep.d local for now, but would be nice to fix once and for all
<mdz_> oh, I use dhcp
<pitti> for me neither; fully dynamic configuration
<pitti> but after resuming it just sits there and never tries to detect any wlans
<pitti> mdz: for wifi or eth?
<mdz> pitti: eth
<pitti> ah
<pitti> that might be it then; doesn't check for essids after resuming
<pitti> mdz: I have some other stuff in my pm/sleep.d regarding reducing power consumption; maybe the sprint is a good opportunity to review such issues and fix them
<pitti> TRLS :)
<mdz> mvo: is PackagingToolsUsability intended to cover the release upgrader as well?
<mvo> mdz: it was not discussed at the bof, what in particular would you like to see ?
<mdz> mvo: just the same sort of review of text and UI elements for simple cleanups
<soren> Hm.. I'm working on a bind9 SRU in Dapper. Its current version (dapper-{security,updates}) is 1:9.3.2-2ubuntu1.3. How should I version it? Just 1:9.3.2-2ubuntu1.4?
<pitti> soren: sounds fine
<soren> pitti: Ok. I wasn't sure if the version strings -updates and -security should be distinct somehow. Thanks!
<pitti> soren: there hasn't been a strictly enforced policy about this
<pitti> we started with adding .1 to security in the past
<mvo> mdz: ok, thanks. I will ask mpt about it.
<soren> Should SRU's do the DebianMaintainerField thing? If so, when did we start that? Feisty?
 * soren glances at pitti
<pitti> soren: yes please, since feisty; dpkg-source complaints are correct
<pitti> ... in each release
<soren> Good point.
<soren> pitti: Thanks.
<pitti> yw
<ChrisGibbs> !info dmraid
<ubotu> dmraid: Device-Mapper Software RAID support tool. In component universe, is optional. Version 1.0.0.rc13-2ubuntu5 (gutsy), package size 181 kB, installed size 612 kB
<soren> pitti: One last thing (or so I hope :) ): I'm looking at the StableReleaseUpdates to make sure I got everything right, but the whole nominate-approve process has already been done, but I can't see if ubuntu-sru has even been in the loop on thigs bug (bug 160176).
<ubotu> Launchpad bug 160176 in bind9 "L.ROOT-SERVERS.NET record needs an update" [Low,Fix released] https://launchpad.net/bugs/160176
<StevenK> pitti: Did you get a chance to look at ppm and the midbrowser MIR?
<pitti> StevenK: still doing NEW (taking hours again)
<pitti> StevenK: midbrowser> as I said, I will veto for the moment if this uses ffox 2 code and no xulrunner
<pitti> soren: right, should still be subscribed and ack'ed (feel freel to upload to the queue already for fast inspection; see policy)
 * pitti -> lunch, bbl
<Riddell> mvo: blamo! http://kubuntu.org/
<cj_> is there a way to bring up a stock ubuntu FS without booting a CD?
<cj_> debootstrap doesn't make the same filesystem as does the install CD
<cjwatson> there's an appendix to the installation guide about cross-installing
<cjwatson> installation-guide-i386 package
<cj_> danke
<cjwatson> it may not be bit-for-bit identical to what the install CD gives you but it should be close enough
<Amaranth> Riddell: _nice_
<Amaranth> It's about time ;)
<cj_> ahh!  here is the clincher: sudo tasksel standard && sudo tasksel ubuntu-desktop
<cjwatson> I suspect that's tasksel install ...
<cj_> yeah, that
<cj_> I was not aware of tasksel before :)
 * mvo hugs Riddell
<pitti> StevenK: ppm has been accepted in NEW an hour ago, btw
<soren> pitti: Subscribed ubuntu-sru to the bug, attached debdiffs for dapper..gutsy, and uploaded to -proposed.
<StevenK> pitti: Yay, thanks.
<soren> pitti: Thanks for your help.
<pitti> soren: great
<StevenK> pitti: I was hoping to get midbrowser promoted so Liferea could build, but if you veto it, you veto it.
<cj> thanks, cjwatson
 * Hobbsee checks which country she's in
<Amaranth> Hobbsee: I forget that sometimes too ;)
<Hobbsee> this looks wrong.  it has to be wrong.
<Amaranth> Hobbsee: ?
<Hobbsee> Fetched 108MB in 2min8s (840kB/s)
<pitti> mvo: compizconfig* binary NEWed
<pitti> yay me; NEW is basically empty now again
 * Hobbsee uploads more crap
<Amaranth> pitti: for a couple hours anyway :)
 * Amaranth tries to think of something to send through NEW
<pitti> I won't touch it again today, thanks; 2 hours are enough
<StevenK> pitti: So you'll look at midbrowser, and possibly dash my hopes?
<pitti> StevenK: SRU now, then component-mismatches, then hardy_outdate.txt, then MIR
 * persia is impressed with the volume of work required on archive-admin day, and cheers all archive admins generally, and especially pitti (it's Friday)
<pitti> persia: impressed with volume> heh, me too :)
<pitti> persia: thanks
<Keybuk>       Device Boot      Start         End      Blocks   Id  System
<Keybuk> /dev/loop0p1   *           1        9327    74919096   83  Linux
<Keybuk> /dev/loop0p2            9328        9729     3229065    5  Extended
<Keybuk> /dev/loop0p5            9328        9729     3229033+  82  Linux swap / Solaris
<Keybuk> ...
<Keybuk> there's something very wrong about that
<pitti> soren: please go ahead and upload your bind9 updates
<soren> pitti: To -proposed? I already did.
<pitti> soren: nothing in the queues
<soren> pitti: Ah... I forgot to add my ubuntu-yes-I-am-sure option to dput. :)
<pitti> o_O
<Hobbsee> soren: the yes-i-am-sure option?
<soren> Hobbsee: My default_host_main is a dummy. The "host" that actually uploads to ubuntu is called ubuntu-ja-jeg-er-sikker which means ubuntu-yes-I-amsure.
<Hobbsee> ahhh
<TheMuso> smart
<soren> Hobbsee: I made it so back when I first got upload privileges.. I was a scared little boy back then. I think it's safe to remove it now :)
<Hobbsee> hehe :)
<soren> Yes, this was only slightly more than a year ago. ;)
<Hobbsee> seb128: now i'm finding kde disturbing.  damn you :)
<ion_> hobbsee: ? :-)
<seb128> Hobbsee: ;-)
<Hobbsee> seb128: it's got some really nice stuff in it though
<seb128> KDE4?
<Hobbsee> seb128: yup
<Riddell> seb128: dood, where have you been, it's all over the interweb!
<seb128> Riddell: I've just noticed lot of KDE in NEW didn't read anything about it on the web yet
<mjg59> Hm.
<seb128> I've read some people saying that the coming kubuntu will not be a LTS thoguh
<seb128> is that true?
<mjg59> Someone's complaining that knotify4 is triggering about 800 wakeups a second.
<pitti> yes
<mjg59> Can anyone else reproduce that? (Just run powertop on a KDE4 desktop)
<seb128> shouldn't that be announced on some ubuntu list?
<pitti> seb128: KDE4 is still too fresh to immediately bless it with LTS apparently
<soren> pitti: Hmm... Should I have versioned the gutsy one as ...ubuntu0.1 ?
<seb128> pitti: my understanding from UDS was that hardy would not ship KDE4 by default
<seb128> pitti: that they would have a special KDE4 edition and that the lts would use KDE 3 (like debian will do for lenny)
<pitti> soren: that or ubuntu1, as you prefer
<Fujitsu> Er, Gutsy should be ubuntu0.1, not ubuntu1... That'll get messy if you use ubuntu1.
<soren> pitti: Ok, I named it ubuntu1, so all is well. It won't clash with anything.
<seb128> Fujitsu: why?
<soren> Fujitsu: Well, in some cases it could, but seeing as the version in hardy is based on a newer version from Debian, I don't see any risk of clashing?
 * Fujitsu thought the SRU policy dictated sanity for versions.
<Riddell> seb128: yes, that seems to be the case
<Riddell> mjg59: sorry I don't have any machine where powertop works
<seb128> Fujitsu: why would 0ubuntu1 not be a sane version?
<Fujitsu> If I were looking at versions of a package on my system, and saw that bind9 was on *ubuntu1, I would, without checking, likely assume it hadn't been changed since release. SRU versions should be distinguishable.
<mjg59> Riddell: Mm? How so?
<seb128> Fujitsu: never been like that, GNOME 2.20.1 is versionned 2.20.1-0ubuntu1 for example
<mjg59> It'll work on anything running one of our kernels
<Fujitsu> seb128: Yes, and that was silly, I have to say. That could never have gone into Hardy sanely.
<Riddell> mjg59: needs acpi doesn't it?
<seb128> Fujitsu: hardy has 2.21
<seb128> Fujitsu: and don't call me silly, thanks
<seb128> Fujitsu: I know what I'm doing when I use a version
<mjg59> Riddell: No
<mjg59> Riddell: But hang on. None of your machines boot with ACPI enabled?
<Riddell> mjg59: does wonky things on this R40e
 * Hobbsee has a look
<pitti> soren: do you still care about bug 119908 ? (dovecot in feisty)
<ubotu> Launchpad bug 119908 in dovecot "Dovecot crashes on index files" [Undecided,Fix released] https://launchpad.net/bugs/119908
<mjg59> I could have sworn we fixed the R40e years ago
<Riddell> mjg59: hal takes an age to start up and the keyboard and mouse repeat presses randomly
<mjg59> I mean, sure, no suspend for reasons I never worked out
<mjg59> Riddell: Have you tried with the hardy kernel?
<Hobbsee> mjg59: 92, apparently
<Hobbsee> not 800
<mjg59> Hobbsee: 92 wakeups per second?
<mjg59> That's still 92 too many. What's it doing?
<Hobbsee> mjg59: apparently so.
<Fujitsu> seb128: Most updates use ubuntuX.Y notation. Why don't GNOME updates?
<mjg59> (Hrngh new software should NOT HAVE THESE PROBLEMS)
<Riddell> mjg59: possibly I havn't, I'm that used to adding acpi=off, I'll give it a go in a bit
<Fujitsu> We should have some kind of consistency, surely.
<mjg59> Riddell: Thanks!
<seb128> Fujitsu: what upgrades? what is the of using NMU numbers
<Hobbsee> Riddell: how do i tell what it's doing?
<Riddell> Hobbsee: strace?
<seb128> Fujitsu: if you suggest having a policy to version specially SRU upload that would be fine, but don't rely on NMU number then, you should rather add gutsy or sru to the version
<Hobbsee> Riddell: i thought you generally knew what knotify was doing
<soren> pitti: Hm.... I'm not sure.. Feisty's relevance has dropped significantly since gutsy got released :)
<Riddell> Hobbsee: notifications :)
<pitti> soren: that's why I ask
<soren> pitti: It's still supported, though. Hm..
<Fujitsu> seb128: Looking at *-changes, the vast majority of SRUs use ubuntuX.Y or ubuntuX.Y.MM. I don't see how it's NMU versioning.
<seb128> Fujitsu: adding .Y is what debian does on NMU
<soren> Fujitsu: The SRU policy dictates that the version should not clash with anything. That's pretty much it.
<Fujitsu> seb128: I am aware. But this is after `ubuntu'. Most people follow this rule. It's enforced for security updates.
<seb128> Fujitsu: I don't think it's a clear way to say that the version is a sru upload
<seb128> you should better include sru or gutsy in the version to do that
<Fujitsu> seb128: It means it's an SRU or a security update.
<soren> pitti: I believe we briefly discussed it (the dovecot SRU) on IRC, but I forget the outcome. From the released version in feisty to 1.0 there was a huge bunch of things in the changelog that just said "fix index bugs" or thereabouts.
<seb128> I've to go for lunch, bbl
<seb128> well, adding .Y is the easiest way to make sure it's < new upload
<seb128> but not a requirement if you know hardy will get a newer version
<soren> pitti: ...I'm not sure what I'd update it to, though.
<soren> pitti: And in any case, properly reviewing the necessary patch is a *lot* of work. As I mentioned in the bug report even just the diff from feisty->1.0 is >18K lines.
<pitti> soren: yeah, for that I'd rather take the current experience with 1.0 into account
<pitti> soren: no problem with it to sit in -proposed for four weeks if there are people who are interested in testing and using it
<cjwatson> I concur that it isn't necessary to use ubuntuX.Y versioning if you already know that the next development release didn't clash with the versions you're planning to use
<cjwatson> ubuntuX.Y is one of those cases of something that's often used for convenience that people then misinterpret as a requirement
<Fujitsu> cjwatson: Isn't consistency a good idea, though?
<cjwatson> hobgoblin etc. :-)
<Fujitsu> It's used in the vast majority of cases.
<cjwatson> I don't think it's necessary, "don't clash" is all we need
 * persia thinks not using -XubuntuY (even -Xubuntu0.1) makes it harder to understand that it is ubuntu-specific variation.
<cjwatson> I'm not for an excess of policy when it isn't necessary
<cjwatson> persia: -XubuntuY *is* policy
<cjwatson> (where the package is in Debian)
 * persia reads backscroll again, now confused
<soren> persia: I add "ubuntu1" to the version.
<cjwatson> persia: to rewrite in a way that is compatible with your naming, -XubuntuY.Z for stable updates is the topic
<pitti> soren: can you please put your plan into the bug report, or just mark it as wontfix if it isn't interesting any more?
<soren> pitti: The thing is that most of the changes from 1.0 to 1.0.10 are also bug fixes.
<Amaranth> persia: The argument is whether or not "ubuntu1" or "ubuntu0.1" is 'correct' for an SRU that doesn't currently have ubuntu changes
<cjwatson> (which I think is perfectly reasonable and often sensible but not required)
<soren> pitti: I'll ask for feedback on the bug report. If noone cares, nor will I :)
<pitti> soren: 'most' is the key here, I guess
<persia> Ah.  Right.  I like -Xubuntu0.Z in preference to -XubuntuY for SRUs, for consistency.
<soren> pitti: Point.
<pitti> soren: sounds like a plan; incomplete for a while until some reporter responds
<soren> pitti: I'll do that, then.
 * soren hugs pitti 
 * pitti hugs soren, thanks
<cjwatson> I have certainly myself just incremented Y (in persia's naming) in stable releases when I knew that the first upload to the development branch was of a new upstream
 * Fujitsu might just be used to security stuff, where we have enforced sane version schemes...
<\sh> pitti: do you think it's ok for compiz to default to emerald when it's installed and not honouring x-window-decorator?=
<persia> Fujitsu: What is the security rule?  Should it not be matched for SRU to avoid confusion where a candidate is superceded?
<cjwatson> security is different because it is much more normal for security updates to be prepared by people who don't ordinarily touch that package
<pitti> \sh: that question is above my head, I'm afraid; mvo?
<DktrKranz> persia, currently we adopt Xubuntu0.Y (for packages which haven't been modified) or XubuntuY.Z (for packages with Ubuntu deltas), but there isn't a specific policy about a strict versioning. As it has been said, "just don't clash".
<cjwatson> but SRUs are often prepared by somebody who's as close to the regular maintainer as Ubuntu has
<Fujitsu> cjwatson: Ah, I guess for main it might be a little different.
<StevenK> pitti: Usually termed "is over my head"
 * persia hopes that the algorithm generating http://people.ubuntu.com/~ubuntu-archive/pending-sru.html#superseded understands that
<pitti> StevenK: ah, thanks
<Amaranth> \sh: Hi there, again :)
<pitti> persia: that just compares version numbers in -security vs. -proposed
<cjwatson> Fujitsu: there are packages in universe that I'd consider to have very nearly regular maintainers too
<cjwatson> e.g. wine
<\sh> Amaranth: thx :) good to be back :)
<persia> pitti: That's what I thought, and why I thought consistency would be good.
<dholbach> MOTU Q&A Session in 14 minutes in #ubuntu-classroom!
<Amaranth> \sh: that too but I meant your compiz question :)
<\sh> cjwatson: what's with wine?
<Amaranth> \sh: I don't have an x-window-decorator, where did that come from?
<\sh> Amaranth: ah :) I don't know I have it in the /etc/alternatives/
 * soren goes to lunch
<\sh> Amaranth: and it was set to emerald
<Amaranth> \sh: maybe mvo just added it, i think he is trying to sync the packages closer to debian
<Amaranth> since i have not been available as much to help maintain them (i have no interest in syncing back to debian's broken setup)
<\sh> Amaranth: dunno...but for me it's confusing...reading /usr/bin/compiz it will start emerald by default when it's installed
<Amaranth> right, the idea being you only have it installed if you wanted to use it
<\sh> Amaranth: but I would say, when we have x-window-decorator in place, we should honor it
<Amaranth> but you can override this
<cjwatson> \sh: did you read the whole conversation?
<cjwatson> or did you just highlight on wine and skip the context? :)
<\sh> cjwatson: nope sorry..I just got there when I read wine ;)
<Amaranth> USE_EMERALD=no or some such thing in ~/.config/compiz/compiz-manager
<Amaranth> \sh: Actually I'm not sure how you got the alternatives thing, the latest compiz is not installable yet so even if it's in there you couldn't have it :P
 * Amaranth checks bzr
<pitti> Riddell: is bug 155144 fixed in hardy?
<ubotu> Launchpad bug 155144 in kdelibs "KSelectAction stopped working for custom values" [Undecided,In progress] https://launchpad.net/bugs/155144
<Amaranth> \sh: ok, that doesn't exist at all, i think you must have added it manually or from some unofficial package that didn't clean up properly
<\sh> Amaranth: well, I didn't install anything else as what's in the archives..of course it was an update from gutsy to hardy...
<Riddell> pitti: yes thanks
<Amaranth> gutsy didn't have anything like that either
<pitti> Riddell: thanks, closed
<\sh> Amaranth: hmm...
<\sh> Amaranth: ah wait...I installed on gutsy this envy stuff...could be that this package added it there
<pitti> mvo, asac: is bug 162609 fixed in hardy? (ubufox and apturl) if so, the status of the hardy and upstream tasks need some love
<ubotu> Launchpad bug 162609 in apturl "plugin finder wizard and apturl don't use the same http proxy" [High,In progress] https://launchpad.net/bugs/162609
<pitti> mvo: please upload update-manager for dapper (bug #181518)
<ubotu> Launchpad bug 181518 in update-manager "check of LTS dist upgrades" [Undecided,Confirmed] https://launchpad.net/bugs/181518
<mvo> pitti: thanks, doing that now
<tkamppeter> h pitti
<tkamppeter> hi pitti
<pitti> hi tkamppeter
<tkamppeter> pitti, concerning bug 153152 I have no answer from HP, but HP has released a new HPLIP version in the meantime
<ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Medium,Confirmed] https://launchpad.net/bugs/153152
<tkamppeter> I think I have to remind the HP guys.
<pitti> tkamppeter: so there's no SRU request in it ATM? I'll unsub ubuntu-sru then
<\sh> hmmm...does the build state "done" means: published to the archve and build state "accepted" waiting to be published?
<jsgotangco> \sh: welcome back!
<pitti> \sh: right
<\sh> jsgotangco: thx :)
<pitti>  \sh: well, 'done' is 'published' or 'currently being published'
<\sh> pitti: ok..then I understand why the amd64 version of the package is not on the archive but the i386 is :)
<tkamppeter> Yes pitti, I need a fix fromn HP, depending on HP we have top skip fax support in Gutsy and tell this in the release notes. In some weeks I will make an LSB package of the newest HPLIP, if this does fax on Gutsy, we will announce it as a workaround.
<tkamppeter> But we will naturally tell that it is non-Ubuntu and so not covered by Ubuntu's commercial support.
<ScottK> pitti: Do you have a moment to discuss a MIR conundrum I'm facing?
<pitti> ScottK: what's up?
<ScottK> I'm working my way through the amavisd-new dependencies and build-deps.
<ScottK> I got to build-dep libmilter-dev and stopped.
<ScottK> That's part of Sendmail and I know we don't want to bring Sendmail into Main.
<ScottK> amavisd-new makes two binaries.  amavisd-new and amavisd-new-milter.
<ScottK> It's only amavisd-new we want in Main, not the milter.
<ScottK> Of course, since it's a build-dep, I'm kind of stuck.
<ScottK> So I can think of some options (none of them great);
<ScottK> 1.  MIR Sendmail
<pitti> argh no
<ScottK> 2.  Split amavisd-new into two source packages.
<tkamppeter> pitti, heno, about the London sprint, which days are you there as I want to present to you Tim Waugh, original author of system-config-printer, and Hin-Tak Leung winprinter driver developer.
<ScottK> 3.  Split Sendmail into two source packages.
<pitti> ScottK: why is amavis so insistant on sendmail? can't it use another MTA?
<ScottK> pitti: The milter needs libmilter from Sendmail.
<pitti> tkamppeter: I'll be there all week
<ScottK> It'll work with Sendmail or Postfix, but needs to build against the milter
<ScottK> err libmilter-dev
<_StefanS_> hi there..
<tkamppeter> pitti, are there days where you are booked out with meetings?
<ScottK> Now that Postfix supports milters, I can imagine we may want other milters in Main in the future.
<_StefanS_> does the hardy standard kernel support 4gb memory on 32bit?
<pitti> ScottK: hm, splitting out libmilter seems like the best option to me, without knowing the details; WDYT?
<ScottK> pitti: I think that's the long term best option.
<pitti> tkamppeter: none so far; this is supposed to be a work/hack week, not a meeting week; while we'll have ad-hoc group sessions, we aren't supposed to get into discussion all day
<ScottK> pitti: It does stick us with a maintenance burden since Debian would have no incentive to follow suite, but for our needs, it's probably best.
<pitti> ScottK: or disable milter support in amavis altogether if we don't need it
<ScottK> pitti: We don't NEED it.  I checked and the Ubuntu popcon is 47.  Dunno if that qualifies as significant.
<_StefanS_> BenC: you there?
<ScottK> pitti: But it's in Universe and has been there for a long time.
<ScottK> I know people use our Sendmail packages, so it wouldn't suprise me to find it has at least some user base.
<tkamppeter> pitti, so my guests can choose the day which fits best for them. I will only coordinate that both come on the same day that they also meet each other (I never got Tim Waugh onto a Printing Summit yet).
<StevenK> pitti: ppm is in binary NEW if you want to poke at it.
<StevenK> pitti: (And has built everywhere)
<pitti> ScottK: hm, I'm afraid I'm not qualified to judge about this; I'm fine with either disabling milter support or splitting out libmilter
<pitti> StevenK: poking now
<ScottK> pitti: Thanks.  I'll look into how hard splitting out libmilter would be.  Thanks.
 * pitti gives up hope to do anything else than archive today and goes on with housecleaning
<_StefanS_> so no one can answer my 4gb question ?
<ScottK> pitti: While you're housecleaning, StevenK just uploaded a clamav update to feisty-backports that it would be nice to get accepted.
<pitti> StevenK: E: ppm: unstripped-binary-or-object ./usr/sbin/ppmd (and a lot of others); why?
<realist> Why is there a problem introducing libmilter into main in the first place?
<StevenK> Hum. Drat
<pitti> lintian is your friend :)
<pitti> StevenK: anyway, accepted; feel free to upload a fix
<lamont> realist: it's not a problem, it's a process
<StevenK> pitti: Doing so now.
<BenC> _StefanS_: yeah
<_StefanS_> BenC: does the current hardy kernel have 4gb mem support on 32bits?
<BenC> _StefanS_: pretty sure we've always had that with the i386 -generic kernel
<ScottK> realist: Because Postfix is our primary MTA and we don't want to move all of Sendmail into the supported catagory.
<_StefanS_> BenC: isn't possible to check .config in /usr/src/kernel-ver ?
<StevenK> _StefanS_: The .config is installed in /boot
<ScottK> realist: libmilter is part of the sendmail source package.
<_StefanS_> StevenK: thanks
<realist> ScottK: so you're talking about splitting libmilter from sendmail
<BenC> _StefanS_: CONFIG_HIGHMEM4G=y
<realist> Makes sense now, thanks :-)
<ScottK> realist: Yes, so we could just bring that in.
<ScottK> Then other milters could be promoted to Main if needed.
<StevenK> pitti: midbrowser? Although I suspect you'd veto it and give me more work on Monday. :-)
<StevenK> pitti: Fixed ppm uploaded.
<pitti> still fighting NEW/SRU/etc.; no end today...
<pitti> imbrandon: new falcon still has the .mo file
<StevenK> Poor pitti, drowning in the archive ...
<persia> pitti: Why change "verification-done" to "verification-motu-done"?  I thought the new consolidated SRU procedure shared tags.
<pitti> persia: oh? I'm not aware of this
<lamont> pitti: I don't suppose you want to send me a diff for the bind9 SRU uploads?
<lamont> or I could just go grab it from LP, I suppose
<persia> pitti: Right.  I'll go poke ~motu-sru to make a bigger announcement than just updating the wiki.
<pitti> persia: different tags make it easier to see who is responsible to verify what, though
 * ScottK agrees with pitti
<pitti> lamont: they are all attached to bug 160176
<ubotu> Launchpad bug 160176 in bind9 "L.ROOT-SERVERS.NET record needs an update" [Undecided,Fix committed] https://launchpad.net/bugs/160176
<lamont> yeah
 * lamont adds to his "after work" list
<persia> pitti: I don't disagree (and don't really have a strong opinion about SRUs, as I'm not confident of thresholds), but if you haven't heard about the new procedure, then ~motu-sru needs to discuss it in a wider forum.
<pitti> persia: I did hear about it (in fact it was me who started the process, remember? :) )
<pitti> persia: but I wasn't aware of tag sharing
<pitti> might just be me not reading the wiki page hard enough
<_StefanS_> BenC: sorry but CONFIG_HIGHMEM4G=y is not /boot/config-2.6.24-3-generic :(
<persia> pitti: Yes.  It was you who started, but the total documentation from ~motu-sru was the wiki page update.  I suspect a mail to u-d@l.u.c or something might be helpful to make sure people were more generally aware.
<asac> pitti: thanks for the prodding. I have ubutfox/apturl upload on my list
<pitti> persia: please include the tag issue in the mail, too; thank you!
<pitti> asac: great, thanks
<BenC> _StefanS_: I just checked it in our config files from the git repo...not sure why it wouldn't be there
<_StefanS_> BenC: really odd..
<persia> pitti: I'll ask, but as I'm not a member, it will likely come second-hand, so no promises :)
<BenC> _StefanS_: are you sure that's 32-bit?
<BenC> _StefanS_: I just checked my system, and it's there
<_StefanS_> BenC: argh.. I'm an idiot. I'm on amd64 right now...
<_StefanS_> BenC: sorry for wasting your time :D
<BenC> _StefanS_: no problem :)
<pitti> ScottK: is the libfile-temp-perl MIR still relevant? is there a decision wrt. using perl from experimental with updated modules, or keeping separate ones, etc?
<DarkSun88> Hi all
<ScottK> pitti: There is no decision as far as I know.  I'd appreciate you approving it so the larger Perl question doesn't block my progress on amavisd-new.  I promise I'll let you know if it end up being able to be demoted again.
<pitti> ScottK: ok, I see; in that particular case I don't mind much, it's a pretty harmless package
<ScottK> pitti: Thanks.
 * ScottK is almost done.  I think I've got one more Perl module and then libmilter to deal with.
<Keybuk> pitti: interesting bug with SD card reader ... the card gets mounted twice at /media/disk and /media-disk-1
<Keybuk> /media/disk is /dev/mmcblk0p1 while /meda/disk-1 is /dev/mmcblk0
<Spads> Once for casual, once for formal.
<mjg59> mmcblk0?
<mjg59> How is that mountable?
<pitti> Keybuk: hm, is there a proper partition table on it? sounds like the card has once been formatted without partitions
<mjg59> Yeah, there's something screwed with that card. It shouldn't be possible to mount the entire device if it contains a partition table
<Keybuk> it may be formatted without partitions, yes
<mjg59> If it's formatted without partitions, mmcblk0p1 wouldn't exist
<ion_> If that is the case, there probably shouldnât be a ...p1
<Keybuk> it claims to have a partition table
<mjg59> The blk0 shouldn't be mountable, and if it is there's something screwed with the layout
<ion_> What do e.g. hexdump -C /dev/mmcblk0 | head and hexdump -C /dev/mmcblk0p1 | head output?
<Keybuk> let me try dd if=/dev/zero on the card then
<LucidFox> pitti> Regarding inkblot...
<LucidFox> the files eggtrayicon.c and eggtrayicon.h are "Lesser GPL v2 or later", but v2 is actually Library GPL - it was renamed to Lesser in 2.1. Which version should I include into the orig.tar.gz?
<Keybuk> LucidFox: whatever upstream included
<LucidFox> Upstream only includes the GPL.
<Keybuk> then ask upstream to fix it
<LucidFox> I will.
<LucidFox> (By the way, so does rhythmbox despite also including these files.)
<mjg59> They're not interestingly LGPL if they're in a GPL codebase
<mjg59> So just ignore it
<persia> You could also explicitly indicate that when you are licensing the code to Ubuntu (as the initial packager), the files previously licensed under LGPL are relicensed under GPL, to be safe, and Ubuntu would then license to users as GPL.
<LucidFox> Ah.
<mjg59> LGPL is only compatible with GPL because it contains a clause saying it can be used under the GPL
<mjg59> It otherwise contains restrictions that aren't present in the GPL
<mjg59> So, in the context of a GPLed work, it's GPLed
<mjg59> The fact that it also claims to be provided under some other license is unimportant
<Keybuk> mjg59: doesn't the LGPL require us to change the notices if we do that?
<persia> Keybuk: For the individual files?  Surely we only have to write a note for the work as a whole.
<cjwatson>   3. You may opt to apply the terms of the ordinary GNU General Public
<cjwatson> License instead of this License to a given copy of the Library.  To do
<cjwatson> this, you must alter all the notices that refer to this License, so
<cjwatson> that they refer to the ordinary GNU General Public License, version 2,
<cjwatson> instead of to this License.
 * persia retracts the erroneous statement
<cjwatson> gnulib gets this right
<mjg59> cjwatson: Hm. I wonder if that's actually the intention.
<cjwatson> (well, modulo stupid sed script bugs)
<mjg59> cjwatson: Since surely that means that you'd have to provide an LGPLed version and a GPLed version of a library
<cjwatson> mjg59: if you use gnulib-tool to import library files into a GPLed project, it seds the licence notices to remove "Lesser"
<cjwatson> I believe this is FSF-approved ...
<mjg59> cjwatson: What if they're dynamically linked?
<cjwatson> gnulib isn't
<persia> mjg59: Why?  The LGPL explicitly grants the right to relicense under GPL, no?
<cjwatson> mjg59: but yes, in that case I don't know :-)
<mjg59> persia: Yes, but according to section 3 only if you remove the LGPL header
<Keybuk> persia: it only grants that right if you modify the notices, see above ;)
<mjg59> And if you do that, you can no longer use it in anything other than GPL-compatible works
<ScottK> persia: Additionally, a special license for Ubuntu wouldn't be in the spirit of DFSG.
<persia> Right.  dynamic linking for a "combined work" such as our install CD.
<cjwatson> LGPL 3 seems to fix this bug
<mjg59> In reality, I think the answer is "Ignore the issue"
<cjwatson> it just says:
<cjwatson>    b) under the GNU GPL, with none of the additional permissions of
<cjwatson>    this License applicable to that copy.
 * persia stops contributing to this discussion, glad not to be counsel for this issue.
<mjg59> Since the alternative is misery
<cjwatson> persia: the install CD is an aggregate under the meaning of the GPL
<cjwatson> certain things *on* the install CD might be combined workds
<cjwatson> works
<cjwatson> (indeed, are)
<persia> cjwatson: Even at runtime when it dynamically links?
<mjg59> However, the FSF claim that a binary is a derivative work of any of the libraries it dynamically links against
<Keybuk> I still want the install CD to be "everything normally distributed with the operating system" ;-)
<mjg59> Keybuk: You can argue that, but you don't get any special exceptions for anything shipped on the CD then
<cjwatson> persia: again, certain things on the install CD are. The install CD as a unit is mere aggregation
<Keybuk> cjwatson: the LGPL-3 is delightfully elegant in that it's a patch to the GPL-3
<cjwatson> persia: the whole install CD is not dynamically linked by any reasonable definition
<cjwatson> Keybuk: yes, it's a lot neater than 2.x
 * persia isn't hiding well
<persia> cjwatson: Sure.  The CD is clearly not a violation, and distributing it very likely not.  Using it might be a different issue, but users aren't usually distributing the use, so it might not matter.  Anyway, exactly what would be meant by "distributing the use" is not a question I am currently informed enough to discuss.
<mjg59> persia: No, individual parts of the CD may be violations.
<mjg59> But the install CD is, itself, irrelevant. The only difference between it and the archive is aggregation.
<cjwatson> under the GPL use is explicitly never a violation
<cjwatson> other licences may be different (although obviously I rather hope nothing on the install CD has serious use restrictions!)
<\sh> ogra: ping
<\sh> ogra: you didn't give my mobile number to anybody, let's say a recruiter of your company?
<ogra> \sh, nope
<ogra> you know i'd never do that, right ?
<ogra> well, you obviously dont else you wouldnt have asked :)
<\sh> ogra: just asking...wondering from whom he got my mobile number :)
<Hobbsee> \sh: plenty of ubuntu people probably have your #
<\sh> Hobbsee: nope....
<LucidFox> So, in short... what would be preferable to do for the inkblot package, and what should I tell upstream?
<\sh> hopefully he had used my imprint
<jsgotangco> maybe you added it on facebook heh
<Keybuk> cjwatson: sadly the piece of my soul that cared about licences has now died, since I have released, under Canonical's policy, a piece of software under the GPL-3
<\sh> jsgotangco: nope :) he only could have it from my imprint...
<markvandenborre> I should really have asked over here before sending in https://bugs.launchpad.net/ubuntu/+bug/182028
<ubotu> Launchpad bug 182028 in ubuntu "evince and eog freeze on all printing related actions" [Undecided,New]
<markvandenborre> is there anything that I can do to improve this bug report?
<LucidFox> markvandenborre> I think #ubuntu-bugs would be a better place to ask :)
<markvandenborre> sorry
<LucidFox> nothing to feel sorry for, just saying
<markvandenborre> and thanks for the hint!
<mjg59> LucidFox: Just upload it as is. Upstream are unlikely to be in a position to change the copyright headers on eggtrayicon.c.
<LucidFox> Well, it was rejected as it was - that's why I came asking in the first place
<Keybuk> mjg59: I think we mark that down as "one of those clauses we silently ignore"
<Keybuk> just the that nice one in the GPL about describing every change :)
<mjg59> LucidFox: Who by?
<LucidFox> by pitti
 * mjg59 shrugs
<LucidFox> https://lists.ubuntu.com/archives/ubuntu-archive/2008-January/014051.html
<mjg59> Upstream aren't the copyright holders of the file concerned in this case
<pitti> well, I didn't ask for changing copyright headers
<mjg59> Oh, I see
<pitti> just adding the LGPL to the orig.tar.gz, since the headers refer to it
<mjg59> pitti: If they're incorporated into a GPLed work, they're not under the LGPL
<LucidFox> yes, and I wanted to know which version of the LGPL :)
<pitti> mjg59: ah, so that's an instance of 'GPL swallows LGPL'
<mjg59> pitti: I'd assume so, yeah.
<pitti> LucidFox: ok; let me look at it again
<mjg59> You could argue it's really "GPL plus extra permissions" for those files, but I don't think it's inherently a showstopper
<pitti> LucidFox: ok, fished out of rejected, and accepted
<LucidFox> Thanks!
<pitti> thanks all for the heads-up
 * minghua is further convinced that he shouldn't be giving license-related counsel, after reading the discussion.
<mathiaz> jdstrand: Do you think it's a good idea to enable the mysql test suite by default when building the package ?
<cjwatson> bryce: http://people.ubuntu.com/~bryce/Plots/ doesn't seem to work in firefox-3.0 ... help? is it possible it needs to be declared as XHTML?
<cjwatson> firefox-3.0's view source highlights it wrongly as well
<pitti> mathiaz: oh, that would be nice; maybe add a DEB_BUILD_OPTIONS=nocheck support for the occasional local test build?
<mathiaz> pitti: the new debian version has the test suite enable by default.
<mathiaz> pitti: I just remember that it takes ages to run. But I guess it doesn't matter for the buildd.
<pitti> right
<pitti> that's why 'nocheck' is a good idea IMHO
<Keybuk> that's very pretty output for gnuplot
<mathiaz> pitti: yeah - seems good. I'll add it.
<jdstrand> mathiaz: no-- its known to fail
<jdstrand> mathiaz: I have which test are supposed to fail in package-tests
<jdstrand> mathiaz: s/supposed/expected/
<mathiaz> jdstrand: hum - the debian maintainer enabled them in 5.0.51
<jdong> pitti: thanks for your review of mpeg4ip, I'll get those things fixed up :)
<pitti> jdong: thanks
<jdstrand> mathiaz: maybe they don't have any expected failures in 5.0.51
<jdstrand> mathiaz: that would be great
<jdstrand> (I haven't built 5.0.51 yet)
<mathiaz> jdstrand: I think. I'll give it a try.
<mathiaz> jdstrand: I'm currently merging it.
<jdstrand> mathiaz: if they do not fail, then I am all for enabling the test suite-- though it takes a *long* time
<jdstrand> mathiaz: well-- hold on a sec
<jdstrand> mathiaz: ah yes-- tests are known to fail if run in parallel
<jdstrand> mathiaz: ie if building in chroots on the same machine for different releases
<jdstrand> mathiaz: eg feisty and gutsy are both building and run the tests at the same time, one may cause the other to fail
<jdstrand> mathiaz: s/run the tests/run the test suite/
<mathiaz> jdstrand: ok - is this something that happens often ?
<pitti> that's the same for postgresql
<mathiaz> jdstrand: I mean on the buildds
<pitti> it doesn't happen on the buildds, though
<pitti> mathiaz: no, that's fine; it's just an issue with parallel local builds
<mathiaz> pitti: ok - and that could be solved with a DEB_BUILD_OPTION
<mathiaz> pitti: set to notest
<LucidFox> pitti> inkblot has been published in main...
<LucidFox> notwithstanding the fact that it never underwent a MIR, it depends on a library in universe
<pitti> LucidFox: ah, forgot to override it when rescuing it from rejected; thanks for the ping, fixed
<spacey> bug #133635
<ubotu> Launchpad bug 133635 in ltsp "LTSPFS security is broken" [Undecided,Fix released] https://launchpad.net/bugs/133635
<ScottK> pitti: Would you have a moment to accept clamav in feisty-backports?  It fixes a remote code execution bug in the current package, so I'd like to get it out soonish...
<pitti> ScottK: accepted, thanks
<ScottK> pitti: Great.  Thank you.
<bryce> cjwatson: yea pitti mentioned the ff3 issue with the plots; I just haven't had a spare moment to look into it.  I'll try to get to it today
 * Keybuk beats HAL into a bloody pulp
<Keybuk> STOP MOUNTING THE DAMNED SD CARD TWICE
<selckin> kick it
<sladen> just because HAL capitalised, doesn't mean EVERYTHING ABOUT IT has to be
<sladen> is capitalised
<Keybuk> WHY DO FREEDESKTOP PEOPLE SHOULD ABOUT D-BUS, HAL AND X ALL THE TIME?
<Keybuk> (ok, that last one was kinda cheating :p)
<mjj29> the correct spelling/capitalization is actually D-Bus
<Keybuk> it used to be D-BUS
<ion_> Now itâs BusKit
<pochu> lol
<sladen> "Buskit is a small charity based in Central Scotland"
<sladen> "Google: did you mean:  bizkit dbus"?
<sladen> I like biscuits
<Keybuk> ok
<Keybuk> I'm clearly going to just have to write an fdi file to deal with this
<Keybuk> the GPS won't accept any SD card formatted by anything other than itself
<Keybuk> and the way it formats it confuses HAL
<LaserJock> somerville32: congrats on the breakage ;-)
<minghua> LaserJock: About the spell checking topic yesterday -- no, it doesn't require learning Asian language, but it requires installing input method packages and a hand compiled (i.e. not packaged yet) IM module.
<LaserJock> ewww
<LaserJock> I just started xchat instead
<minghua> LaserJock: And it's not that useful anyway -- it gets in the way of typing too much.
<LaserJock> minghua: perhaps I just need to relearn how to spell ;-)
<cdm10> I'm wondering whether the Update/Upgrade Manager is from upstream or from Ubuntu?
<LaserJock> cdm10: Ubuntu I believe
<cdm10> LaserJock: I noticed some UI issues with it.
<LaserJock> file bugs
<cdm10> ok
<cdm10> should I ask #ubuntu-desktop first to see if it's intentional?
<LaserJock> you could ask here real quick
<LaserJock> I'm not sure how many people are paying attention in #ubuntu-desktop at this hour
<cdm10> alright.
<cdm10> I'm just wondering whether it's intentional that the Distribution Upgrade progress interface is different from the Updates interface.
<cdm10> When you do a Partial/Full Upgrade, you see a box with the steps of the process, and that same window stays there for the entire process.
<cdm10> Normal updates show a window for downloading the packages, and when that's done, it's replaced by a window that shows the installation progress.
<LaserJock> hmm, I *think* that is intentional, but you might ask mvo about it
<somerville32> If it isn't intentional, they were coding with a blind fold on :P
<cdm10> The thing is, it's inconsistent, and doesn't seem to make sense...
<cdm10> mvo?
<LaserJock> http://launchpad.net/~mvo
<LaserJock> the guy that wrote it
<cdm10> LaserJock: Alright, should I directly contact him?
<LaserJock> sure, if you have a question :-)
<cdm10> alright
<LaserJock> it seems like proper behavior to me, but ....
<cdm10> LaserJock: is email or IRC preferred?
<LaserJock> well, he's not on IRC at the moment I don't think
<cdm10> yeah, just checked. I'll email.
<somerville32> I think it is sane to me too
<somerville32> Distribution upgrades is NOT the same thing
<LaserJock> there really different "things" and so to me it makes sense that the windows don't do the same thing
<somerville32> The different UI is a big fat clue that you're doing something different
 * LaserJock notes that wallpaper not being there is a big fat clue too ;-p
 * somerville32 coughs.
<somerville32> Thinking about it, not having the the wallpaper on Alphas might be a good idea
<LaserJock> heh ... suuure
<LaserJock> "I planned it all along"
<somerville32> Helps distinguish it as an Alpha :)
<cdm10> somerville32: about the distribution upgrades not being the same thing... it's fine if it distinguishes it with text, but imo, using an inferior UI to display normal update progress just to differentiate them isn't a great idea...
<LaserJock> inferior?
<cdm10> Well, it uses multiple windows
<LaserJock> why is that bad?
<somerville32> So you think that the normal UI is inferior?
<cdm10> Well, it's a matter of opinion, but yes.
<somerville32> cdm10, You might talk to TheSheep. He is a UI expert :)
<cdm10> The checkbox window used by the dist-upgrade progress box makes it clear that package-downloading isn't the only step in the process... the normal one doesn't indicate that there's going to be another window popping up with a NEW progress bar after the current one is full.
<mjg59> cdm10: The stages listed in the distribution update don't apply to a normal update
<cdm10> mjg59: yeah, but at least two do...
<cdm10> downloading and installing.
<mjg59> Only two
<cdm10> Well, I'm not saying that the exact same UI has to be there... but they should at least be similar.
<somerville32> I don't see why they should be
<LaserJock> heh, they're both gtk ... I thought they were similar ;-)
 * LaserJock obviously doesn't understand the finer points of UI design
<cdm10> LaserJock: I'm not saying that :)
<somerville32> Neither do I, lol
<cdm10> I'm just stating my opinion. The bigger issue, imo, isn't the inconsistency, but the problem of ambiguity in the normal one.
<LaserJock> ambiguity of what?
<LaserJock> rather, what is ambiguous?
<cdm10> LaserJock: when you begin the update process, the main window disappears and a progress window appears. The progress window has one progress bar. When that progress bar is full (indicating that the process is finished), another window comes up, with a new progress bar. That's unexpected, and could be annoying for a user who's expecting their updates to be finished when the progress bar reaches the end.
<cdm10> Also, when the second window pops up, it steals focus.
<LaserJock> the stealing focus part makes sense, I've had problems with that in the past
<LaserJock> the progress bar thing though, I guess I"m just used to synaptic
<cdm10> LaserJock: So am I, so i've come to accept it... but it just seems that the design used in the upgrade progress window makes more sense, and shows a more complete picture of the process to the user. Also, it's closer to the Golden Ratio :) and it solves the problem of focus-stealing by only using one window.
<LaserJock> well, I think there are probably practical reasons why it is the way it is
<cdm10> LaserJock: It probably has something to do with using Synaptic's built-in progress thingies.
<LaserJock> the normal updater is just basically a synaptic-like frontend whereas I think the distribution upgrader is more "from scratch", but I could be wrong
<cdm10> whereas it seems that the Upgrade thingy is original Ubuntu stuff.
<LaserJock> exactly
<cdm10> Anyway, it's just a small nit-picky thing I just noticed :)
<LaserJock> so perhaps synaptic could use some UI changes ;-)
<cdm10> That's probably true
<cdm10> I actually noticed something else. If Ubuntu is going to be using mixed gksudo-PolicyKit for a while, they should be modified to look similar.
<LaserJock> in any case, mvo will be able to give you a much better discussion about it
<cdm10> yep.
<cdm10> I have a question about PolicyKit.
<cdm10> I can see why it can be useful to have an unlock button that unlocks some additional functionality in an application that does both user-specific and system-wide tasks.
<cdm10> However, things like the Network management applet can't function at all without privileges, so I don't see why they don't just try to get themselves unlocked right away, rather than having the user push Unlock.
<cdm10> Did I miss anything about PolicyKit while I was gone?
<Riddell> cdm10: no, pitti the policykit guy isn't here
<LaserJock> Riddell: is adept still used for update notification in Hardy?
<Riddell> LaserJock: yes
<cdm10> Riddell: ah, ok, I'll see if I can talk to him about it
#ubuntu-devel 2008-01-12
<TheMuso> c
<TheMuso> ugh wrong tab
<a_cuozzo> How is everyone?
<a_cuozzo> I have a question regarding package submission.
<pwnguin> no chokeholds
<a_cuozzo> lol
<a_cuozzo> I am interested in making a debian package of Tom Christiansen's Perl Power Tools.
<ScottK> a_cuozzo: #ubuntu-motu is a better channel for how to package questions.
<a_cuozzo> Ah, I know how to make the package.
<a_cuozzo> I was wondering if there would be any interest in submitting it to the repos.
<a_cuozzo> Where can I find out if there would be an interest in submitting it?
<Burgundavia> a_cuozzo: you need #ubuntu-motu
<a_cuozzo> Okay, I will go there. Thank you :)
<kagou> Good morning
<tjaalton> ion_: could you check bug 182237
<ubotu> Launchpad bug 182237 in linux-restricted-modules-2.6.24 "restricted manager does not recognize nvidia 8600M GT on hardy" [High,Confirmed] https://launchpad.net/bugs/182237
<tjaalton> nvidia_supported doesn't work anymore for 169.07
<ion_> tjaalton: Iâll take a look at it.
<tjaalton> ion_: great, thanks
<Usiu> Hi, Do you import additonal packages to 7.10 or its freezed ?
<persia> Usiu: We can import, but evaluate new packages to make sure they don't break anything else.
<StevenK> 7.10 is frozen
<persia> Ah.  Right.  My mistake.  7.10 is frozen.  8.04 is open.
<StevenK> It's released, and finished with, except for critical bug fixes and security updates.
<Usiu> Ok thanks
<scizzo-> I am not sure if it is of any interest to put in ubuntu now but there is a svn package version of inkscape on the website if someone wants to give it a go
<Usiu> StevenK, but ubuntu page states that merg with debian has already been freezed
<Usiu> StevenK, so is it still possible to add packages in this case ?
<StevenK> Usiu: For Hardy, yes, if it's justifiable
<YokoZar> Could I get a quick outside opinion?  I'm worried about starting a conflict in a bug: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-games/+bug/138713
<ubotu> Launchpad bug 138713 in gnome-games "Gnometris uses Gnome foot logo instead of Ubuntu theme" [Wishlist,Invalid]
<persia> YokoZar: It's an #ubuntu-desktop decision.  I can see your point, but it needs to be done in a way that can easily be overridden with a -themes package or similar to support in-distro flavour variation.
<YokoZar> persia: thanks, that makes some sense
<YokoZar> persia: all it is at this point is just changing one file (albeit one part of the gnome-games package)
<persia> YokoZar: still #ubuntu-desktop (gnome-games is main, and gnome)
<ion_> tjaalton: I attached a new version of nvidia_supported to the bug report.
<ion_> tjaalton: Since the PCI ID list isnât the first symbol of the file anymore, i found another consistent thing between all the releases: there are always two subsequent symbols with the identical PCI ID list. So now the script finds that.
<tjaalton> ion_: cool, thanks
<ion_> Has someone planned on working on autoselecting the proper nvidia driver release on startup based on connected hardware?
<tjaalton> without using restricted-manager to fiddle with the xorg.conf?
<ion_> Yep
<ion_> Symlinks instead
<tjaalton> what symlinks?
<ion_> nvidia.o â nvidia-123.45.67.o, libGL.so.something â nvidiaâs libGL for the same driver release
<ion_> Could be updated using the alternatives system.
<ion_> Anyway, if someone feels like implementing that, this program should be helpful. Iâm trying to get it uploaded to Ubuntu. http://revu.tauware.de/details.py?package=hardware-connected
<tjaalton> so you could have all those installed?
<ion_> It can be used almost directly against /usr/share/linux-restricted-modules/$(uname -r)/modules.alias.override/nvidia
<ion_> I was thinking that there would be just a single nvidia-glx that would contain all the releases, and the system would pick the correct one on startup.
<tjaalton> I don't know.. there are plans though to automatically use the binary driver instead of nv, if it's installed
<geser> Hobbsee: Hi, could you please give-back dom4j. Thanks.
<Hobbsee> geser: done
<Kmos> geser: it won't work.. no build records in hardy. - bug 181981
<ubotu> Launchpad bug 181981 in dom4j "Rebuild dom4j to create an hardy build record" [Wishlist,Confirmed] https://launchpad.net/bugs/181981
<geser> argh
<Hobbsee> erm, /me looks
<Kmos> geser: if you want to sponsor the upload to make it building.. :)
<Hobbsee> wow, that's classy
<Fujitsu> That's actually bug #181328.
<ubotu> Launchpad bug 181328 in soyuz "no build records for previously-failed builds" [High,Triaged] https://launchpad.net/bugs/181328
<Hobbsee> Fujitsu: which is listed on there, yes
<Fujitsu> Ah, right.
<Fujitsu> Soyuz isn't actually that bad here, as DEPWAIT and FAILED builds do get new records in the next distroseries...
<Fujitsu> Just CHROOTWAIT doesn't, as far as I can see.
<geser> looks like we really need an upload for a build retry
<Hobbsee> geser: it appears so
<Fujitsu> That would fix it, but is a hack.
<Hobbsee> Fujitsu: yes, but this is soyuz.
<geser> Fujitsu: true, is there any other alternative to waiting till this bug is fixed and the affected packages got retried in hardy?
<Kmos> geser: cprov told me he don't know if he could do it for next version of launchpad, so it can take ages..
<Fujitsu> geser: I doubt it.
<Hobbsee> geser: unless they manually generate build records for all affected packages (who knows how many)..
<Hobbsee> Fujitsu: you really should start working on it, and remove some of the crack.
<geser> I will check then the chrootwait list for gutsy and see how many packages still need a upload for a rebuild
<geser> Kmos: I'll upload it, for the next time: please close your bug in your changelog entry
<Hobbsee> geser: hopefully most of it will be picked up with the autosyncs, where the later versions get tried
<Hobbsee> or users complain
<Kmos> geser: thanks! sorry.. i'll remember that next time..
<persia> Hobbsee: We've hundreds of packages for which neither of those conditions get hit, unfortunately
<Hobbsee> persia: cruft, or actual useful stuff?
<Fujitsu> Builds failing due to chroot failures should very rarely make a release...
<persia> Hobbsee: define cruft
<Hobbsee> persia: okay, so crap that people care about, vs crap that they don't.
<Hobbsee> where people == users, devs, etc
<Fujitsu> Urgh, why wasn't that given back months earlier?
<Hobbsee> Fujitsu: no build records?
<Hobbsee> Fujitsu: oh, originally?
<persia> Hobbsee: Umm.  If it didn't get updated, and nobody complained, I'd think that was obvious :)
<Fujitsu> I mean the gutsy one.
<Hobbsee> persia: right.  true
<Hobbsee> persia: how many packages are we talking about there?
<persia> I'm not sure right now.  Fujitsu, do you still have those scripts around?
<Kmos> also others packages are failing because we don't have right now a locales-all replace, langpack-locales isn't prepared to handle it..
<Fujitsu> persia: Probably. I can easily mangle them to work out any non-superseded chrootwait builds in Gutsy.
 * Hobbsee wonders if the great hardy lot got given back
<StevenK> The simplest way to do is by asking the database. Typical.
<Fujitsu> StevenK: That works too.
<Fujitsu> Hobbsee: We don't seem to have any chrootwait in Hardy at the moment.
<persia> Fujitsu: I think it'd be interesting to see not just only non-superseded chrootwait builds, but also non-superceded FTBFS for any reason.
<StevenK> Which would work if you begged an LP admin
<Fujitsu> persia: Best to run the normal FTBFS script over Gutsy, then.
<persia> Fujitsu: Makes sense.
<Hobbsee> Fujitsu: oh, so it did.  good
<persia> Fujitsu: Wait, won't that also show superceded builds?
<Fujitsu> persia: geser's only lists those failures that are in the last version of each source package, I believe.
<persia> Fujitsu: That would be good.  I'll post it somewhere when it finishes
<geser> Fujitsu: yes, as it doesn't make sense to list FTBFS for package version which might be fixed in the current version
<Fujitsu> geser: Of course, that makes sense.
<geser> I could run the script against gutsy if there is interest
<persia> geser: I'm running with s/hardy/gutsy/ now, but it might be interesting to run against feisty and dapper to see if we missed any FTBFS SRUs.
<persia> Or rather, to catch any FTBFS that haven't been updated in a while.
<geser> FTBFS stats for dapper: http://qa.ubuntuwire.com/~geser/build_status-dapper/
<geser> FTBFS stats for feisty: http://qa.ubuntuwire.com/~geser/build_status-feisty/
<persia> geser: Are all those still outstanding?
 * persia is especially surprised to see 39 packages in main
<Fujitsu> persia: Most of those are fine.
<Fujitsu> They're arch-specific things that appeared before Soyuz had P-a-s.
<persia> Fujitsu: I'd say OOo is really the only one that matters, but I haven't heard a lot of complaints from Dapper OOo users, so it may not be as important as it looks.
<geser> FTBFS stats for gutsy: http://qa.ubuntuwire.com/~geser/build_status-gutsy/
<geser> luckily only 3 packages in chrootwait
<madmac> hi, i would like to know if is possible to create a patch with diff that creates directories
<madmac> i am trying but dont know how
 * persia stops my run, presuming it to be terribly slow for some reason.
<mjj29> madmac: patch should just create the dir if you try and patch a new file in it
<persia> So it is only CHROOTWAIT packages that don't automatically get requeued for the next release, or are there hidden FTBFS issues remaining?  Are the 499 packages identified as FTBFS for dapper in addition to those for gutsy or hardy, or does it only check within a release?
<Fujitsu> persia: depwait and failed builds get new records created, which doesn't leave much.
<Fujitsu> Perhaps upload failures, however.
<persia> I don't think any of the upload failures are much concern.  They seem to be all lpia or hppa (which are both sort of special), except for m17-contrib and ion3, both of which I think are gone now.
<madmac> mjj29: patch tell me "patch: **** Can't rename file /tmp/poXkD8Ax to modules/net/  : Not a directory"
<mjj29> madmac: what does the patch say?
<madmac> because net doesnt exisit
<madmac> patch says that
<mjj29> no, what's the actual patch
<mjj29> can you pastebin it or something?
<madmac> the actual patch is a file inside net directory
<mjj29> madmac: ok, can you spell out exactly what you are doing
<madmac> creating a patch for adding a new file inside a new directory that doesnt exist
<mjj29> I just did: mkdir -p a/b; mkdir newa; echo 'hi' > a/b/c; diff -urN newa a > diff; cd newa; patch -p1 < ../diff
<mjj29> and it said:
<mjj29> patching file b/c
<mjj29> and created the directory b and the file c
<mjj29> madmac: how are you trying to do it?
<mjj29> what commands are you running
<mjj29> what is the text in the diff which you are trying to apply
<mjj29> be more specific or we can't help
<geser> persia: I've upload libswidgets-java to get a build record in hardy
<persia> geser: Excellent.  Thanks.
<madmac> diff -Naur old/modules/net/ new/modules/net/socket.c > patch
<geser> persia: but for libjempbox-java I need someone first who can resurrect checkstyle which got eaten by the move to universe (arch:all bug)
<madmac> then patch -p1
<geser> persia: so (almost) all chrootwait from gutsy are handled now
<Fujitsu> geser: They're back.
<persia> geser: Thanks for digging those out.  Do you think it is worth checking edgy as well?  For pre-Dapper, I think other issues would be more important.
<mjj29> madmac: I assume you can't just do diff -aurN old new ?
<madmac> no, there are binaries and makefiles
<mjj29> madmac:
<geser> Fujitsu: then is the mirror I use a little back behind
<Fujitsu> geser: Oh dear, maybe it got missed.
<mjj29> cd ..; cp -lR new new.orig; rm new.orig/modules/net/socket.c; diff -aurN new.orig new > patch
 * Fujitsu looks.
<Fujitsu> cprov said he'd restored them all.
<madmac> mjj29: thanks i got it
<madmac> mjj29: the problem was that i didnt specified the file in old
<Fujitsu> geser: That was only demoted a couple of days ago. That's really odd.
<mjj29> madmac: oh, right
<mjj29> madmac: yeah, of course that works
<Fujitsu> geser: It was promoted ~2 hours before the code was fixed, so it may not have made cprov's list.
 * Fujitsu is confused as to why there are two universe records there, 5 minutes apart.
 * geser hopes that we have soon all arch:all packages back
<geser> persia: FTBFS stats for edgy: http://qa.ubuntuwire.com/~geser/build_status-edgy/
<Fujitsu> geser: Most of them seem to have been restored, but apparently not all :(
<persia> geser: Wonderful.  No candidates that need a poke.  I suspect that the hardy stats are now up to date.
<persia> (excepting libjempbox-java)
<stgraber> cd
<Kmos> geser: dom4j built with success :)
<MetaMorfoziS> hi all
<MetaMorfoziS> i wanted to try the hardy heron 8.04 cd, and i has a problem, is the good place to say/ask about that?
<MetaMorfoziS> live*
<ion_> Please read the topic.
<MetaMorfoziS> ooh sorry
<tormod> ogra: ping
<Hobbsee> tormod: it's the weekend
<tormod> Hobbsee: so what? :)
<Hobbsee> tormod: canonical employees don't tend to work weekends unless there's a very good reason fro it
<tormod> Hobbsee: they're too healthy I guess. But he's logged in, so it's reasonable to check if he's here.
<Hobbsee> heh
<Hobbsee> true
 * lamont wonders if libcaca should not build-dep on mono-gmcs on hppa, or if that'd just make it ftbfs
<lamont> libapache2-mod-perl2 is d-w locales-all everywhere...
<bigon> is someone working on bug 182155 ?
<ubotu> Launchpad bug 182155 in cli-common "Please sync cli-common 0.5.6 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/182155
<pochu> bigon: you need to wait for an archive admin to sync it.
<bigon> yeah I know, the sync is needed to fix bug 182130
<ubotu> Launchpad bug 182130 in libflickrnet "package libflickrnet2.1.5-cil 25277-5 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,Fix committed] https://launchpad.net/bugs/182130
<pochu> bigon: but archive admins aren't around, as it's saturday... your best bet is to poke Hobbsee when she's back, if that's urgent.
<bigon> ok, I will ask her
 * lamont notes that upx-ucl fails to build these days
<\sh> StevenK: ping inventor...can you describe in a short sentence when you mean with
<\sh>   * Hack libInventorWidget.a to not build MyColorEditor, as it also uses GLw
<\sh>     now.
<choudesh__> Hi all.
<choudesh__> does anyone know how to add dist and pool folders to the liveCD? I am remaster a liveCD but when I add the Dist/Pool folders for apt-cdrom, squashfs fails to load
<lamont> dpatch.  #$&^*(%)_*_$&#%^*(&)^(_... pain.
#ubuntu-devel 2008-01-13
<bigon> any archive admin here?
<TheMuso> !weekend | bigon
<ubotu> bigon: 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.
<__mikem> Does anyone know if wubi is going to come with the next version of ubuntu?
<LaserJock> __mikem: since it was in 7.10 I would think there would be a good chance
<__mikem> LaserJock: I was under the impression that it DIDN'T make 7.10
<__mikem> LaserJock: are you SURE that it is really in 7.10?
 * Hobbsee waves
<__mikem> Hobbsee: you are a dev, could you shed some light on this wubi issue
<bddebian> WTF is wubi?  I don't see it in Gutsy, Hardy or anywhere else
<Hobbsee> bddebian: windows installer
 * bddebian vomits
<Pici> iirc, it was on the Gutsy dvd/cds.
 * __mikem gives bddebian a motion sickness bag
<__mikem> Pici, hold on, let me mount the cd image in windows
<LaserJock> I saw it on Gutsy CDs I thought
<__mikem> Pici, its not on the cd image I downloaded
<__mikem> Pici, where did you see it
<Hobbsee> __mikem: what about ti?
<Pici> __mikem: I never saw it, but I recall someone in #ubuntu mentioning it.
<Hobbsee> LaserJock: i'm not sure if they ever put it on there - it wasn't as good as they watned it
<Hobbsee> yes, i think they shelved it, as it was untested, etc, and was still missing bits
<__mikem> Pici, I found something, It was hidden on the disk
<__mikem> bbl
<Hobbsee> lupin-casper and lupin-support seem to be the packages
<LaserJock> Hobbsee: ahh, I may have checked on an alpha or something
<Hobbsee> LaserJock: i think it was on the alpha's, yeah
<Hobbsee> bigon: you can sync yourself, you know
<__mikem> Okay, there is an exe for wubi in the root dirrectory for the 7.10 cd, but I don't quite know how to use it.
<Chipzz> 04:38 < __mikem> Hobbsee: you are a dev, could you shed some light on this wubi issue >> not all devs know of all software; some focus on a specific set of packages :)
<__mikem> okay
<__mikem> That question is open to anyone here
<somerville32> lol
<Pici> __mikem: run it?
<__mikem> okay
<Pici> Okay then.,
<somerville32> lol
<somerville32> I dunno if that is a good sign or a bad sign
<simplechat> hey everyone
<somerville32> hi
<Hobbsee> bigon: presumably you'll need to rebuild that, according to the debian bug?
<simplechat> i was wondering, at what point can a linux distro be ported over to a new hardware platform?
<simplechat> when it has a usable C compiler? or a usable C++ compiler?
<persia> simplechat: Generally once linux, glibc, and bash work, it's worth investigation.  Getting the special hints into the autotools hint files is a good first step.  This isn't the best forum for that discussion, although I don't know the correct channel.
<Hobbsee> bigon: wait, no, it's fine.  ask me for a giveback if it builds in the wrong order
 * calc2 is working on splitting OOo into tiny bits!
<calc2> so far i have just removed duplication but haven't tried actually seeing if it still builds ok
<Hobbsee> calc2: \o/
<calc2> removed around 100MB compressed code from orig.tar.gz
<Hobbsee> nice work!
<Hobbsee> calc2: so i shouldn't bother upgrading?
<calc2> the rest is going to be a bit harder since i have to figure out what it is
<calc2> Hobbsee: oh i doubt this will be done by hardy release
<calc2> if it is i will be very surprised
<Hobbsee> awww
<calc2> i have to see how well i can split it and probably go to hamburg to convince upstream to implement the split as well
<simplechat> persia, what about compilers?
<calc2> upstream probably wouldn't get it out until 3.0 timeframe if i can get it working
<simplechat> i would need something to cross-compile the kernal, wouldn't i?
<LaserJock> calc: how split?
<calc2> though the throwing away duplicated code could be in ubuntu earlier
<calc2> LaserJock: so far i have been just removing code that shouldn't really be there (since its 3rd party code)
<lamont> simplechat: compiler, libc, kernel, then begin an interesting iterational loop
<calc2> LaserJock: next step is to find a way to separate parts of ooo build into logical subparts
<calc2> LaserJock: and hopefully make i18n build a lot faster in the process as well
<simplechat> brb, thunderstorms
<calc2> LaserJock: since currently the i18n part takes 8hr+ and really shouldn't
<simplechat> yeah, interesting
<simplechat> :( hopefully not utterly painfull
<LaserJock> calc2: wow, that'd be spectacular
<calc2> crap when i reset my router at home i forgot to open up ssh port :-\
<calc2> and the access point i'm leeching off here at the photo shoot only does ~ 16KB/s download
 * calc2 needs to download the alpha-3 amd64 iso for reinstalling his laptop
<__mikem> Apparently I am going to need the alternate install CD, because when I finally got to the part where it boots into X, my screen went a funny pattern of lines and colors. Can the alternate CD be used for a wubi install?
<LaserJock> I don't think for installation
<calc2> mjg59: ping
<calc2> mjg59: any new news about resuming from suspend on intel 965 on amd64 arch?
<__mikem> Okay, before I go wasting a disk, I need to know something. When I tried to get the alternate install CD, I ended up with a file that was exactly the same size, and had the same file name as the regular install CD, how am I supposed to know that this is really the alternate cd?
<persia> __mikem: You can check the md5sum against that listed on the download site.
 * Hobbsee flees the storm
<LaserJock> although having same size and name doesn't sound like you got a different disk
<__mikem> Okay, these disks are identical, and I specifically requested to download the alternate cd, NOW I AM ANGRY
<__mikem> Seriously, how do you download the alternate install CD?
<LaserJock> __mikem: what country are you located in?
<__mikem> USA
<LaserJock> West or East?
<__mikem> east
<LaserJock> __mikem: you might try http://www.gtlib.gatech.edu/pub/ubuntu-releases/gutsy/
<__mikem> laserjock, someone needs to me made aware that clicking on that checkbox on the download page for the ubuntu cd images does absolutely nothing
<persia> __mikem: File a bug against ubuntu-website to report that
<LaserJock> __mikem: well, it worked for me when it first came out, but I can check again
<LaserJock> __mikem: oh, you are right
<LaserJock> I just tried it
<__mikem> LaserJock: also, if it is true that the alternate cd can't be used for wubi installs, something has to be done about that because that means that there is no way to do a wubi install on any of the new hp pavilions
<LaserJock> __mikem: well yeah, that's why it's still under development
<LaserJock> it's a pretty new thing
<LaserJock> and there's always lots of work to be done
<LaserJock> and much of the time by volunteers
<__mikem> and someone needs to do something about the fact that these hp notebooks appear to be designed to make it as painful as possible to run linux on it
<__mikem> well, I am going to give this a shot anyway
<LaserJock> not sure if I should have mentioned that I have a new hp notebook that runs Gutsy beautify ...
<StevenK> LaserJock: You're terrible.
<LaserJock> oh? :-)
<Hobbsee> heya Burgundavia
<\sh> I know it's sunday morning, but if any archive admin is awake, can you please check what's wrong with libming on the buildds? source upload  was accepted, but after compiling successfully, the buildd tells me, that the source is older than that package what's in the archive...(https://edge.launchpad.net/ubuntu/+source/libming/0.3beta1+cvs20051127-1ubuntu1/+build/489662)
<Hobbsee> \sh: reping me about it when i get back
<\sh> Hobbsee: reping :)
<Hobbsee> \sh: repong :)
<\sh> Hobbsee: ok...I did an update upload of libming for libgif transition...source upload went fine, got the accepted message..this morning the buildd mailed me about this issue: 3:46:47 WARNING        libming0_0.3beta1+cvs20051127-1ubuntu1_i386.deb: Version older than that in the archive. 0.3beta1+cvs20051127-1ubuntu1 <= 1:0.3.0-12ubuntu1
<\sh> apt-cache showsrc or apt-get source libming but gives me the 0.3beta1 version nothing else.
<\sh> Hobbsee: the original mail from LP: http://pastebin.ubuntu-nl.org/51746/
<Hobbsee> \sh: erm, ming appears to be the new source.
<Hobbsee> sarah@LongPointyStick:~% showsrc libming | grep Binary                8:29PM
<Hobbsee> Binary: libming-util, libming-dev, libswf-perl, libming0, python-ming
<Hobbsee> sarah@LongPointyStick:~% showsrc ming | grep Binary                   8:29PM
<Hobbsee> Binary: python-ming, ming-fonts-opensymbol, libswf-perl, libming-util, libming-dev, php5-ming, ming-fonts-dejavu, libming0
<\sh> Hobbsee: wtf? why is the old source in the archive still? that's crap
<Hobbsee> \sh: no one filed a removal request?
<Hobbsee> someone's cleraly stuck the new ming in there, without checking
<\sh> there is not even a conflicts/replace  as it looks like ...
<\sh> the c/r section is totally crap of ming...so what's the real package...because libming removed the php extensions on purpose...
<Hobbsee> \sh: assuming that libming and ming are from the same package (and are supposed to match), rather than 2 projects with the same name, ming appears to be the new source, and libming should be nuked, and the conflicts/replaces on ming should be strenghtened.
<Hobbsee> that's what i get, version-wise
<Hobbsee> \sh: i think you want to @lart dAniel hAhler
 * Hobbsee isn't sure if he's a MOTU
<Hobbsee> hm, i think he is.  blueeyed.
<Hobbsee> hm, i think he is.  blueyed.
<\sh> well...reading the changelogs ...
<\sh> libming is old and stinks , ming is younger and agile ;)
<Hobbsee> and, lutin gets the blame for syncing, without checking that it's arleady there.
<\sh> well, I'll tight the c/r section a bit more...and we need to get rid of libming source
<Hobbsee> \sh: go ahead and file a removal request for libming, and do the c&r
<\sh> Hobbsee: will do...this is really confusing...
<Hobbsee> \sh: preferably remind Lutin to check for existing sources, before requesting new syncs, too
<Hobbsee> \sh: want me to file libming removal while i'm here?
<\sh> Hobbsee: I'm filing the report...could you remove libming then? ,-)
<\sh> Hobbsee: outch
<\sh> Hobbsee: why nobody saw that? https://bugs.edge.launchpad.net/ubuntu/+source/libming/+bug/64535
<ubotu> Launchpad bug 64535 in libming "UVF Exception: libming (0.3beta1) -> ming (0.3.0)" [Medium,Fix released]
<Hobbsee> \sh: i can't - no privs
<Lutin> Hobbsee: why did I do ?
<\sh> and the no-pony award goes to : cjwatson_ ;)
<Hobbsee> \sh: strange - that was during a time of freeze, had the filer, and two members of ubuntu UVF at that time, both of whom are MOTU's, and none of them thought about the old source, it appears.
<Hobbsee> Lutin: requested a sync of ming, without dealing with libming at all, it appears.
<Hobbsee> Lutin: they produce a lot of the same binaries.
<Hobbsee> \sh: this is why i tend to think that some of our universe freezes are ineffective - someone, out of 3 people, should have picked that up.
<Hobbsee> okay, 4, because colin did the sync afterwards.
 * Hobbsee suspects the people on the UVF team got complacent.
<\sh> Hobbsee: well, yes, but humans can do mistakes..so soyuz or the sync util should check before what binaries are proposed by the source package and check those names against our binary package archive list
<persia> It's not a matter of making the freezes stronger, it's just a matter of having better tools to check.  I suspect the new source was clean, had a good changelog, built, and worked.
<\sh> bug #182491
<ubotu> Launchpad bug 182491 in libming "[SRC REMOVAL] libming" [Undecided,New] https://launchpad.net/bugs/182491
<Hobbsee> \sh: sure, but 4 humans all making the same mistake is kinda bad :)
<Hobbsee> \sh: there are already scripts that do that
<Lutin> well ok, and what's the correct way to check for issues like that ?
<\sh> Lutin: when you replace a source package, it's likely that the old source package as the same binary packages
<persia> Lutin: Check the binaries from a package, and make sure it doesn't match a different binary name.
<\sh> Lutin: to check that, a simple cat debian/control|grep Package is enough and then feed the result into apt-cache show
<Lutin> yep
 * Hobbsee checked what was creating the binary libming0, and saw two different source packages listed there
<Hobbsee> lifeless has a script somewhere that checks for possible conflicts, too
<persia> Hobbsee: That only checks filename conflicts, not source/binary name conflcts (http://conflictchecker.ubuntu.com/possible-conflicts/)
<Hobbsee> persia: yeah, that.  i was assuming there would be some filename conflicts too
<persia> Hobbsee: Might be, but maybe just /usr/share/doc/*
<Hobbsee> persia: true
<\sh> well, a quickshot could be this...to executed in the debianized source tree
<\sh>  for i in `cat debian/control |grep Package|cut -d " " -f 2` ; do grep-dctrl -F Binary $i /var/lib/apt/lists/*Source*|grep "Package" ; done
<\sh> and result was: libming and ming
<persia> Two sources building the same binary usually indicates a removal is required, as otherwise it's impossible to predict the state of a system when analysing a bug report.
<\sh> persia: the problem here: src libming -> binary versions with an epoch, src ming -> binary versions with an epoch...
<persia> \sh: That's just an extra problem.  The real problem is both ming and libming having a binary with the same name.
<pitti> good morning
<Hobbsee> morning pitti!
<Hobbsee> pitti: seeing as you'r ehere, do you mind nuking libming?
<Hobbsee> er, source, and binaries that are not also in ming
<pitti> Hobbsee: bug#?
<pitti> ah, source package renaming? sure
<Hobbsee> pitti: https://launchpad.net/bugs/182491
<ubotu> Launchpad bug 182491 in libming "[SRC REMOVAL] libming" [High,Confirmed]
<\sh> pitti: the bug existed since 2006 ;) and never raised a problem until yesterday ,-)
<pitti> done
<\sh> thx
<geser> Hi pitti
<Hobbsee> bigon: tha'ts still broken, btw
<bigon> yeah just see that too
 * Hobbsee kills f-spot
<Hobbsee> right, problem solved.
 * bigon doesn't understand, the pkg works when build outside of a pbuilder (probabily a missing build-dep)
<Hobbsee> bigon: it all built.  itj ust doesn't fix the problem
<\sh> how can I tell trackerd to stop spamming me with all this notify boxes
<Hobbsee> purge it.
<pitti> that's what I eventually did as well; even disabling tracker completely in the prefs doesn't help to get rid of the tray icon
<bigon> Hobbsee: it seems that there are two solution to fix the issue:
<bigon> 1) a temporary fix in the flickrnet pkg 2) fix the real issue in the mono pkg
<Hobbsee> bigon: what does each involve?
<bigon> the best is the 2nd: the alternatives of some exec are not correctly created -> rename the postinst and prerm script
<bigon> debian bug 460513
<ubotu> Debian bug 460513 in mono-1.0-devel "mono-1.0-devel doesn't create alternatives" [Serious,Open] http://bugs.debian.org/460513
<Hobbsee> right
<bigon> Hobbsee: patch in bug 182509
<ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
<Hobbsee> bigon: and if you think i'm touching mono, you need a club over the head :)
<Hobbsee> soren might, though.  he likes touching scary things.
<bigon> I'll contact the debian mono team
<bigon> damm the patch is not good
<pitti> sjoerd: hm, I saw that you uploaded PK 0.7 to unstable; does that work for you at all? 0.7 breaks both gnome-mount and g-s-t, and I cannot even get the CLI tools to work
<sjoerd> pitti: dunno, but nothing is build against it so it should be harmless
<pitti> sjoerd: ah, I see
<emgent> hello pitti :P
<pitti> hi emgent
<sjoerd> pitti: but mbiebl is the one to ask, i didn't do any PK related stuff just yet
<bigon> anybody brave enough to have a look at bug  182509 ?
<ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
<Mithrandir> lamont: we don't want Xen on LPIA.
<lamont> heh.  ok
<lamont> I'll take that back out then
<Nafallo> hehe
<Mithrandir> if anybody says we want it, I'll be happy to have words with them.
<Nafallo> hahaha
<Nafallo> :-)
<zul> heh
<flowers> hello! so i was just redirected to this chan to ask some questions about hal, would anyone mind helping me out?
<lamont> Mithrandir: fixe
<lamont> d
<flowers> well, here goes anyway. so i updated my freshly installed kubuntu and afterwards hal wont start at boot. everything points to say that it should be fine but i need to restart it to get things to work properly any ideas?
 * bigon throw bug  182509 at some core-devel
<ubotu> Launchpad bug 182509 in mono "Correctly install alternatives" [High,New] https://launchpad.net/bugs/182509
<Amaranth> mjg59: what's that bit about 0x80 being debug hardware and causing lockups?
<rbs-tito> Is anyone here?
<selckin> you are
<rbs-tito> I'm considering improving a GNOME application, shall I submit my changes to GNOME bugzilla or Launchpad?
<awalton__> rbs-tito, both?
<awalton__> you can link the lp one to the upstream as well.
<rbs-tito> awalton__: Well, if I send it upstream it will come downstream eventually anyway. But is there a proceedure similar to the Debian bugs proceedure, so that it can be linked to the Ubuntu project as a contribution?
<awalton__> not that I'm aware of, but that doesn't count for a whole lot. does there need to be?
<rbs-tito> awalton__: Just checking before I go ahead
<rbs-tito> OK, I'm ready to get cracking
<rbs-tito> (I'm adding an album art preview thumbnail to sound-juicer)
<ion_> doko: Hi
<ion_> doko: Do you think it would be possible to get ruby 1.9.0 from sid to hardy?
<ion_> doko: Judging from the sid changelog, the âAdd -g to CFLAGSâ change in Ubuntu has been applied there. Iâm not sure whether the other lines in the Ubuntu changelog signify a delta in Ubuntu or just list things that have happened in Debian up to the merge.
<ion_> doko: If itâs the latter, a sync should be enough.
#ubuntu-devel 2009-01-05
<seek_therapy> this is way off topic ...but would you happen to know of a good iso burner
<Hobbsee> brasero works nicely, as does the kde one
<Xteven> k3b
<Xteven> thats the kde one that you mean probably
<Hobbsee> ah, yes, that's it
<seek_therapy> welp gonna go and try and fic
<seek_therapy> fix
<soc> hi
<soc> i'm working on that problem: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/157398
<ubottu> Ubuntu bug 157398 in gnome-control-center "GNOME default DPI doesn't match X default DPI" [Wishlist,Confirmed]
<soc> i already asked on #ubuntu-bugs ... but it seems no one has time atm ...
<soc> i'm already debugging the problem
<soc> but from my pov the code looks correct
<soc> so i'm not really sure, what the problem could be ...
<TheMuso> ./c
<TheMuso> bryce_: Re bug 210865 and all the other relevant bugs you triaged, we need to make sure all affected users have the same codecs. I'll go through those bugs in the coming days and check that.
<ubottu> Launchpad bug 210865 in linux "[Intel 82801H] sound card volume inaudibly low unless model=mitac specified" [Medium,Triaged] https://launchpad.net/bugs/210865
<NCommander> hey StevenK
 * StevenK waves
<dholbach> good morning and happy new year!
<pitti> Good morning everyone, happy new year!
<pitti> hey dholbach
<dholbach> hi pitti
<Hobbsee> hey there pitti!
<ion_> Hi all
<agent47a> when i run debuild, i get a signing error.  gpg: can't open `/home/me/.gnupg/secring.gpg' ...  any tips?
<ebroder> debuild -us -uc
<Hobbsee> it has the wrong owner?
<pitti> agent47a: presumably you did not create a GPG key; you probably want what eborder said
<ebroder> Also, the error is harmless so long as you're not actually trying to create signed packages
<agent47a> pitti: thanks!
<agent47a> i'm a noob as you guessed correctly.
<Chipzz> agent47a: also: #ubuntu-motu for these questions please
<agent47a> Chipzz: okay
<tkamppeter> pitti, hi
<pitti> hey tkamppeter, happy new year!
<tkamppeter> pitti, thanks, also a happy 2009
<tkamppeter> pitti, I have a problem with merging ghostscript from Debian. MoM has prepared the merge: http://merges.ubuntu.com/g/ghostscript/ and the problem is that our ghostscript_8.63.dfsg.1.orig.tar.gz differs from the Debian one. Seems that the Debian maintainer has done another selection of non-free stuff to exclude than me.
<pitti> tkamppeter: if you and Debian repackaged the upstream tarball, they will always differ, at least in the date in the gzip header
<pitti> tkamppeter: so you should use Ubuntu's orig.tar.gz for the merging
<tkamppeter> pitti, the two files differ by 2MB (around 20 %) in size.
<tkamppeter> pitti, I suggest that if they are really different by content that the Debian maintainer should re-upload into Debian with version number 8.63.dfsg.2 (as my .orig.tar.gz is the older one) and after that I merge.
<tkamppeter> pitti, another possibility is to wait one month (until 1st of Feb) as then GS 8.64 gets released. Then I make a .orig.tar.gz which meets the needs of both Debian and Ubuntu and this one will be the next Ubuntu upload of ghostscript.
<dholbach> seb128: I sponsored a few desktop items
<seb128> dholbach: thanks
<dholbach> there are still a few around
<dholbach> I'll do some more tomorrow
<seb128> dholbach: I didn't work during holidays and it'll take me a while to read all mails etc today
<dholbach> seb128: same here :)
<pitti> tkamppeter: best is probably to discuss this with the Debian maintainer, to find an approach which allows us to both share an orig.tar.gz
<pitti> tkamppeter: but as long as the current one works for us, you can continue to use it for the merging
<pitti> tkamppeter: it's only really a problem once we want to sync (which isn't possible with differing orig.tar.gz)
<james_w> if an init script implements restart with "start-stop-daemon" --stop then --start
<james_w> then it seems like --oknodo should only be on the --stop invocation, correct?
<tkamppeter> pitti, Debian has also removed the Resource/Font/ directory due to a "minor licensing problem" (which I have also resolved with the GS guys). So I will use our .orig.tar.gz.
 * cjwatson arranges for armel to be taken into account by http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt; hopefully it won't explode ...
 * directhex explodes
<cjwatson> mvo: OK if I remove the app-install-data-commercial *source* from jaunty? seems to be superseded by -partner. You might want to reassign bugs across as appropriate?
<mvo> cjwatson: yes, thanks
<cjwatson> directhex: I assume it's good for libmono-cairo1.0-cil and mono-1.0-runtime to fall out of main; do you know whether mono-dbg is supposed to stay?
 * Hobbsee hugs mvo for unattended-upgrades
<directhex> cjwatson, yes, they should fall out of main. mono-dbg..... i don't know whether we decided whether we wanted to promote the mono debugger, or demote mono-dbg
<cjwatson> they're sort of orthogonal aren't they?
<cjwatson> oh, maybe not, just found the seed comment
<directhex> what's the seed comment?
<cjwatson> I thought we decided that we should promote mono-debugger. Could somebody write a main inclusion report for it?
<cjwatson> supported: * Extra-Exclude: mono-dbg # only useful with mono-debugger, currently in universe
<directhex> i'll see what i can do
<cjwatson> cheers
<directhex> mono-debugger has never been included before because it hasn't actually worked for ~4 years :p
<directhex> hm, all deps in main. good.
<directhex> cjwatson, i think someone once told me all compilers in main are meant to have a debugger. was this imagined?
<cjwatson> slangasek: are you expecting to upload the stuff in lp:~ubuntu-core-dev/pam/ubuntu soon? it'd fix a skewed dependency on libdb4.6 on armel
<cjwatson> directhex: I said something similar, although I wasn't as explicit. What I said was that, as a general rule, we should be shipping debugging facilities for packages in main where they exist.
<cjwatson> doko__: is python2.5's skewed dependency on libdb4.2-dev on non-x86 architectures still necessary? it does funny things to our archive reports, so just wanted to check whether that could be brought back into sync ...
<slangasek> cjwatson: had no immediate plans to do so, but it should be in a state permitting it to be uploaded if you're inclined
<slangasek> otherwise I'll see about getting to it this week
<slangasek> (probably after I merge the pending 1.0.1-5 upload from Debian)
<cjwatson> no rush from my part
<doko__> cjwatson: hmm, didn't check. but I hope 2.5 will go away soonish, and 2.6 uses 4.7 again
<cjwatson> ah right
<tjaalton> requestsync isn't working for me on jaunty, says that I should login to lp first which I've done..
<Hobbsee> tjaalton: what are you trying to sync?
<tjaalton> Hobbsee: x11proto-randr
<RainCT_> tjaalton: With which browser did you log in?
<tjaalton> RainCT_: ff3.x in jaunty
<RainCT_> jpds: ^
<tjaalton> .lpcookie.txt is updated
<Hobbsee> tjaalton: wfm, it appears
<tjaalton> Hobbsee: ok, wonder why it fails here.. I'll try intrepid
<Hobbsee> (that was jaunty I tried on)
<tjaalton> Hobbsee: oh you filed that one, but the version to be synced is from experimental :)
<Hobbsee> tjaalton: oh.  Sorry, i'm not psychic :(
<tjaalton> I'll try it first and dupe then
<Hobbsee> ok
<tjaalton> different error on intrepid
<RainCT> Hobbsee: you aren't? o_O
<Hobbsee> RainCT: not anymore.  My psychic pony vanished :(
<tjaalton> what the hell, it filed the sync request even though it claimed that it failed
<slangasek> asac: you've marked bug #308397 as targeted to 8.04.2; are you expecting to have this fix uploaded this week?
<ubottu> Launchpad bug 308397 in ubufox "localizable general.useragent.locale pref shipped by ubufox breaks mozilla OS usage stats (ubuntu not counted)" [Critical,Fix committed] https://launchpad.net/bugs/308397
<Keybuk> dholbach: when is it?
<Keybuk> what kind of session would you have in mind?
<dholbach> Keybuk: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
<dholbach> Keybuk: I was just thinking - there always was a lot of excitement around upstart - I'm sure that a quick overview, how to make use of it, how to get involved hacking on it, etc would interest people
<tjaalton> ok, the "wishlist, confirmed" part is what failed I guess
<slangasek> asac: (if not, it needs un-milestoned for sure, the last weeks are reserved for cleaning up -proposed and doing ISO vetting, not processing new SRUs)
<Keybuk> I'm not really sure that there's anything to tell people though
<dholbach> Keybuk: hrm - any other topic you'd like to talk about? :)
<Keybuk> I could talk about boot performance?
<slangasek> Keybuk: one can probably assume a relatively fresh audience for each UDW
<asac> slangasek: didnt know that 8.04.2 was scheduled that soon. but yes, if thats the case i would upload it tomorrow
<dholbach> Keybuk: sounds great
<slangasek> asac: ok, great :)
<dholbach> Keybuk: maybe something about how to measure, how to test so it has a bit of a "hands-on experience"?
<asac> slangasek: do you have a query for 8.04.2 milestone so i can clean up other stuff?
<dholbach> Keybuk: do you just want to grab a slot?
<asac> (and push back to .3)
<slangasek> asac: https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.milestone=1425
<asac> thanks
<Hobbsee> interesting.  jaunty doesn't work perfectly.
<Hobbsee> redrawing seems to be quite slow, but scrolling isn't.
<directhex> cjwatson, how does https://wiki.ubuntu.com/MainInclusionReportmono-debugger look?
<Keybuk> dholbach: indeed
<dholbach> Keybuk: rock and roll!
 * dholbach hugs Keybuk
<Keybuk> dholbach: Thursday 1800?
<dholbach> Keybuk: sounds good to me
<dholbach> Keybuk: you rock!
<cjwatson> directhex: seems to be in basically the right style, though I'm not a MIR approver
<gerlumpi_> guten
<gerlumpi_> ubuntu leuft nicht auf einem rechner was tun??
<pitti> gerlumpi_: hello
<Nafallo> !de
<ubottu> In den meisten ubuntu-KanÃ¤len wird nur Englisch gesprochen. FÃ¼r deutschsprachige Hilfe besuchen Sie bitte #ubuntu-de, #kubuntu-de, #edubuntu-de oder #ubuntu-at. Geben Sie einfach /join #ubuntu-de ein! Danke fÃ¼r Ihr VerstÃ¤ndnis.
<pitti> yes :)
<gerlumpi_> thanks
<jpds> tjaalton: You have to delete ~/.lpcookie.txt and rerun the script.
<jpds> tjaalton: Actually, that script should tell you this, it's in the lastest version in the archives..
<tjaalton> jpds: doesn't seem to help
<tjaalton> oh wait, I'll dist-upgrade first
<jpds> tjaalton: Which error do you get?
<tjaalton> jpds: the same, "you must log in to lp"
<tjaalton> but there's a new u-dev-tools available, I'll try with it next
<tjaalton> hmm still the same
<jpds> tjaalton: pastebin please?
<jpds> tjaalton: I'm off for lunch, but free feel to /msg me all the errors you get and I'll fix them later.
<tjaalton> jpds: sure, thanks
<slangasek> mvo: bug #189406 is targeted to 8.04.2; do you agree that this should be fixed for hardy, and do you have time this week to upload it?
<ubottu> Launchpad bug 189406 in update-manager "Update Manager doesn't display package versions anymore" [Wishlist,Fix released] https://launchpad.net/bugs/189406
<cjwatson_> pitti: https://rt.admin.canonical.com/Ticket/Display.html?id=32382 notes that there are lots of files in macaroni:/tmp/ owned by ubuntu-archive; it looks to me as if they're created by ddeb-retriever
<cjwatson> pitti: maybe some more bits of temporary-file-cleanup code need to be done in try: finally: ?
<arthur_l> join #ubuntu-installer
<pitti> cjwatson: I made a TODO item, thanks for pointing out
<pitti> cjwatson: either that, or it's spewage from apt-ftparchive
<cjwatson> pitti: I haven't seen apt-ftparchive spit out empty files or tarballs before :-)
<cjwatson> lots of the files seem to be tarballs containing -dbgsym packages
<mvo> slangasek: I'm not sure if we should do it for 8.04.2 - but if we do, I'm happy to do the upload (the patch is small and safe)
<pitti> cjwatson: ah, I got it; it's tar_install_pool(), which uses urlretrieve without cleaning up
<pitti> cjwatson: I'll add a test for this and fix it, thanks
<slangasek> bdmurray: ^^ you appear to have done the targeting of bug #189406 to 8.04.2; care to comment?
<ubottu> Launchpad bug 189406 in update-manager "Update Manager doesn't display package versions anymore" [Wishlist,Fix released] https://launchpad.net/bugs/189406
<cjwatson> pitti: oh yes, so it does. what about the empty files though?
 * pitti removes tmp*.tar for now
<cjwatson> e.g. -rw------- 1 ubuntu-archive ubuntu-archive         0 Jan  5 11:10 tmpAY2xN1
<pitti> cjwatson: I get that when running the test suite as well, so I can track it down locally and add a test plus fix
<cjwatson> thanks
<davidroderick> every so often my ubuntu hangs the keyboard and the main menu. I can open separate things of toolbar but all I can do is close or minimise the window again.  How can I learn how to do a backtrace or something?  Where to I go to learn what you guys know?
 * Keybuk raises an amused eyebrow at Planet Ubuntu ... some people need to stop reading The Sunday Mail
<directhex> but they can carry on reading The Mail on Sunday?
<directhex> one of the above is some random scottish rag. t'other is britain's second most popular sunday paper!
<davidroderick> I think everybody in here is busy working.  Is there a good book somebody could recommend to learn stuff?
<pitti> davidroderick: "stuff" is very broad :)
<pitti> even in the context of free software development (which I assume you mean)
<directhex> the joy of sex is an enduring favourite
<cjwatson> pitti: (he gave more detail just further up)
<cjwatson> davidroderick: sounds like an X problem; http://wiki.ubuntu.com/X has quite a few resources
<pitti> ah, sorry, I just restarted irc client
<davidroderick> I have a knowledge of ruby and a little C.
<davidroderick> I would like to learn about operating systems
<davidroderick> I turned off HAL in order to use NDISwrapper.  Is this the correct approach?
<cjwatson> people do pop up from time to time with this kind of question, but there's no easy advice to give because it depends so strongly on your area of interest (which is likely to evolve as you learn more, anyway)
<cjwatson> http://wiki.ubuntu.com/ContributeToUbuntu has various bits of specific advice; if you want to learn about the fundamentals of Unix, I can recommend pretty much anything by W. Richard Stevens
<cjwatson> (specifically "Advanced Programming in the UNIX Environment", although it *is* heavyweight (literally))
<cjwatson> directhex: mail> "ongoing project to divide all the inanimate objects in the world into ones that either cause or cure cancer" (pp Ben Goldacre)
<Keybuk> davidroderick: right, that one
<Keybuk> the Sunday version of The Hate Mail
<directhex> cjwatson, i wonder which camp people put Mono into.....
<Keybuk> s/davidroderick/directhex/
<directhex> i thought the general term was "the daily fail", anyway
<pitti> ScottK: just took a look at quassel screenshots, looks quite nice; can you split windows horizontally?
<pitti> ScottK: that's a killer feature of mine, and so far weechat is the only client which can do that (x-chat can detach windows and you can reorder them side by side, but that's inconvenient)
<ScottK> pitti: Here is why mine currently looks like http://kitterman.com/kubuntu/quassel.jpg
<ScottK> why/what
<ScottK> It's pretty flexible, but I'm not sure exactly what it is you're after.
<pitti> ScottK: I want to see two or three channels side by side, below my other windows
<pitti> ScottK: http://people.ubuntu.com/~pitti/photos/pitti-virtual-desktop.png
 * ScottK looks
<ScottK> pitti: Not that I can immediately see in the version I have.  I just finished building a git snapshot.  One nice feature I like is the window you see in the top/middle of my setup is a stream of all the channels I have open.
<pitti> ScottK: that's quite a nice feature as well
<zul> asac: ping
<asac> zul: ?
<zul> asac: is anyone working on that samba/firefox bug yet? I noticed the patch
<asac> zul: not sure ... last merger would be a good candidate to drive this? who was that?
<zul> me :0
<asac> zul: seems like you ;)
<zul> i was thinking for intrepid though
<asac> zul: could you verify that it fixes it?
<zul> asac: sure
<Keybuk> cjwatson: do you think we still need that special ID_TYPE rule?
<pitti> Keybuk: working on udev 130? :-)
<zul> asac: i was going to stick it in my ppa and get them to test it
<cjwatson> Keybuk: I think so, unless the new udev offers something at least as useful?
<apachelogger> pitti: I guess implementing split view in quassel shouldn't be much work, doing it properly in general is ;-)
<asac> zul: that or if the patch seems safe, verify locally and upload to  -proposed directly
<zul> asac: k sounds good to me
<asac> zul: we should get it to jaunty asap in any case
<zul> asac: samba-3.2.7 has been released im going to sync it from debian when its available
<asac> ok
<Keybuk> cjwatson: depends, what are you trying to do?
<cjwatson> Keybuk: I have a call now, but maybe in the meantime you could dig up the log of the last time I justified this for you? :-)
<Keybuk> cjwatson: I can't remember being convinced the last time :p
<cjwatson> but it would remind *me*
<Keybuk> http://people.ubuntu.com/~scott/id_type.log
<ScottK> pitti: Not currently possible - <EgS> ScottK: something like that is spooking in our minds for quite some time, but that's not an easy task
<pitti> ScottK: ah, thanks
<ScottK> They need to do some internal rearchitecting to make that work.
<cjwatson> ArneGoetje: can we get new -base language packs generated for hardy (for 8.04.2)?
<ArneGoetje> cjwatson: sure. Which date would be best?
<Keybuk> Oct 23 01:14:12 <Keybuk>	cjwatson: that logic will bite you later, but it's not this bug ;)
<Keybuk> Oct 23 01:14:27 <cjwatson>	Keybuk: explain that to me later :)
<Keybuk> this is now "later" :)
<cjwatson> ArneGoetje: slangasek could confirm, but I think "nowish" would be fine; what's the usual schedule for delta language packs?
<cjwatson> Keybuk: ... so please do explain :)
<slangasek> ArneGoetje: "nowish" would be best, yes; alternates are currently 11MB oversized going in, so we need to see fairly soon whether the re-basing is sufficient
<slangasek> (or if not, how much is left to scrounge)
<Keybuk> cjwatson: I'm just trying to hook myself into a state where I can remember what list-devices does
<ArneGoetje> slangasek: ok, next one will be ready on wednesday then.
<slangasek> cheers
<cjwatson> Keybuk: you mean at the interface-contract level?
<Keybuk> right
<cjwatson> Keybuk: "give me a list of all disk devices", "give me a list of all partitions", "give me a list of all CD devices"
<cjwatson> possibly one or two other fiddly bits but ...
<Keybuk> though the kinds of interfact contracts that udev makes usually involve someone coming around your house later on to break your legs
<cjwatson> Keybuk: well, in this case isn't it you wanting to remove a custom rule we added, rather than udev removing something? :-0
<cjwatson> :-)
<Keybuk> partially
<Keybuk> in fact, I've removed *all* of our rules
<cjwatson> obviously I'm happy to change list-devices as needed, but I remember agreeing with you at the time that there might well be other things relying on the same interface
<cjwatson> but if there's a new recommended interface then list-devices should use that
<Keybuk> those are likely broken by other changes now
<cjwatson> is DEVTYPE available in any way?
<ArneGoetje> slangasek, cjwatson: full-export request in Rosetta sent.
<cjwatson> catting uevent I suppose
<Keybuk> cjwatson: I think that everything you need is available now ...
<Keybuk> but I'm just checking
<cjwatson> I mean is it in the udevdb?
<Keybuk> I think so
<cjwatson> CDs still seem to have DEVTYPE=disk though
<cjwatson> as previously discussed
<Keybuk> DEVTYPE=disk, MEDIA=cdrom
<cjwatson> aha
<Keybuk> though that might be a sysfs attr instead of an env
<Keybuk> I'll just upgrade this laptop to jaunty
<Keybuk> then install udev 136 on it
<Keybuk> then see what happens ;)
<cjwatson> Keybuk: ps are git hashes really a good thing to put in version numbers? they won't increment sanely ...?
<Keybuk> cjwatson: that's just there to remind myself which one I got to, more than anything else
<Keybuk> anyone building from there deserves everything they get <g>
<cjwatson> oh, you're going to upload it as 136-?
<Keybuk> right, it'll be 136-1 when it's uploaded
<cjwatson> ok
<Keybuk> which is when Kay actually releases 136
<cjwatson> so where would I find MEDIA? I can't find it in this here 2.6.28 instance
<Keybuk> it might be a 2.6.29ism
<Keybuk> which is worrying
<cjwatson> oh dear
<cjwatson> this is the current kernel in jaunty
<Keybuk> ah, it's an IDEism
<Keybuk> meh
<Keybuk> CD/BD-ROM devices are either DEVTYPE=disk, /sys/block/hd*/media=cdrom *or* /sys/block/sr*
<cjwatson> that's (DEVTYPE=disk) && (/sys/block/hd*/media=cdrom || /sys/block/sr*)?
<cjwatson> or (DEVTYPE=disk && /sys/block/hd*/media=cdrom) || /sys/block/sr*)?
<cjwatson> err minus the trailing )
<Keybuk> err
<Keybuk> either ;)
<Keybuk> if it's sr* it can only have DEVTYPE=disk
<cjwatson> so should I just implement that in list-devices now?
<Keybuk> yeah
<cjwatson> ok
<Keybuk> and this can be now considered a stable interface ;)
<Keybuk> cause it's listed in the docs as one :p
 * cjwatson won't hold his breath
<cjwatson> which docs though
<cjwatson> ?
<Keybuk> sysfs-rules
<Keybuk> though typically, the version in the kernel tree is *out of date*! :p
<Keybuk> it still claims /sys/block has things other than symlinks in it
<Tonio_> stupid question, but now feisty/main has been removed, is there a place it's been archived somewhere ?
<cjwatson> Tonio_: old-releases.ubuntu.com
<Tonio_> cjwatson: super, thanks !
<bdmurray> slangasek: It seemed to upset enough people that I thought backporting the gconf key would be worthwhile
<slangasek> ok
<slangasek> mvo: ^^ what do you think?  I don't have a strong opinion on this either way; as long as the change is reasonable, I have no objections to approving it in, but I'm equally happy to drop the milestone
<mvo> slangasek: I'm fine with porting the change, its just some lines (and off by default) - I agree with bdmurray here, it seems to upset some people
<cjwatson> gar, building dm modules into the kernel has silently broken so many random little bits and pieces of the installer :-(
<directhex> d-i in "fragile" shocker?
<cjwatson> err, not normally that bad actually, no
 * NCommander wonders if there is a d-i building instruction manual
<cjwatson> NCommander: depends what you want to change, but I believe there's stuff linked off InstallerDevelopment that's easily adaptable
<NCommander> cjwatson, I want to build a ARM d-i initrid with network console
<NCommander> (essentially the NSLU2 d-i installer on Ubuntu)
<tedg> NCommander: Hmm, would that work for the NAS200 also?
<NCommander> Maybe
<NCommander> If you have a booting kernel ...
<tedg> That would be cool, I got a NAS200 but I haven't gotten Linksys' toolchain working yet.
<tedg> I'd really like to get OpenVPN installed on it.
<NCommander> You might have luck with the emDebian toolchain
 * NCommander uses it on Ubuntu for his NSLU2
 * tedg bookmarks that, thanks NCommander!
<tedg> Hmm, that was my 666th del.icio.us bookmark -- not a good sign...  :)
<_MMA_> \m/
<NCommander> cjwatson, where's the Ubuntu d-i stuff?
<kirkland> slangasek: hiya, are you around?
<kirkland> slangasek: the kernel team says that crypto drivers i need should be built into the kernel now ...  that doesn't seem to be the case in today's daily server build
<kirkland> slangasek: i wanted to understand why that might be the case
<cjwatson> NCommander: apt-get source debian-installer, but isn't it already built?
<NCommander> cjwatson, I can't find one which is just an initrd
 * NCommander can't find any d-i images actually for ARM
<cjwatson> I think they were having some trouble building
<NCommander> the images?
<cjwatson> the kernel
<cjwatson> once that's fixed it's trivial
<superm1> pitti, ping re sru for bug 297543
<ubottu> Launchpad bug 297543 in nvidia-graphics-drivers-180 "Update Package: nVidia 180.11" [Undecided,In progress] https://launchpad.net/bugs/297543
<superm1> pitti, i wanted to ask what's the plan for releasing to -updates?
<directhex> is .11 current?
<directhex> isn't 180 generally beta?
<tseliot> directhex: no, it's not. However we're not talking about replacing any other driver with 180.x
<superm1> i'm not talking at all about 180
<tseliot> I'll work on the latest releases soon. I've been very busy with a few projects
<superm1> i'm talking about 177.82
<superm1> it's in intrepid-proposed, and has been there since dec 7
<tseliot> right
<superm1> that bug was hijacked to be talking about the 180 releases
<Baby> pitti: ping!
<NCommander> cjwatson, you around?
<tkzao> http://www.sexy-lena.com/?uid=36564
<ScottK> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<ScottK> ^^^
<ScottK> Urgh.  To late.
<directhex> the great and powerful scott "sexy beast" kitterman has no +o?
<ScottK> Ah.... No.
<directhex> tsk
<ScottK> If I could kick people I'd get in trouble.
<directhex> heh
<ScottK> Better to not have the temptation.
<Hobbsee> ScottK: is he frequent?
<jpds> Hobbsee: He's still connected, best ban.
<ScottK> Hobbsee: Dunno.  First time I've noticed.
<directhex> i'd say the reverse applies. abusing /kick is less troublesome than letting out frustrations via calling someone a ^%&* ^T&* %%$^
<ScottK> Hobbsee: Thanks.
<ScottK> directhex: I've only really lost it on an Ubuntu IRC channel once.
<Hobbsee> jpds: doesn't seem to be, but he's been there under that nick, on that IP, before
<directhex> ScottK, i find #mythtv-users brings out the worst in me, if i try to actually participate
<directhex> ScottK, oh, and #debian back when i had no regard for my blood pressure
<ScottK> I generally avoid user channels.
<ScottK> That helps.
<directhex> heh
<directhex> so why doesn't my babylon 5 dvd work on my intrepid-based laptop then? :'(
 * ScottK asks directhex to consult /topic for the relevant answer.
<directhex> i blame xorg-blah-intel. it's good for blaming.
<philsf> slangasek: ping?
<slangasek> kirkland: well, it would help then to quantify what the kernel team means when they say the drivers are built in "now" :)
<slangasek> philsf: pong
<kirkland> slangasek: actually, i think i got to the bottom of it ;-)
<slangasek> ok
<kirkland> slangasek: cjwatson is going to turn "on" the encrypt-home option again in the server iso;  hopefully it'll make the next daily and I'll test again tomorrow
<slangasek> ok
<philsf> slangasek: I want to confirm Bug #212098, but I'd like to be sure I'm not missing something here.
<ubottu> Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Fix committed] https://launchpad.net/bugs/212098
<philsf> Does the issue only manifest itself in non-guest shares?
#ubuntu-devel 2009-01-06
<slangasek> philsf: it's a question of the behavior when turning on filesharing for the first time, when packages get auto-installed for you
<slangasek> so a proper test should involve removing the libpam-smbpass package (I think that's the only one)
<philsf> slangasek: I did it, and couldn't reproduce the bug with a guest allowed share
<slangasek> sec, let me review the bug
<philsf> I did purge samba-common and all of its rdepends and logged out to make sure I had a fresh environment, but the shares are in fact created after the installation of samba and libpam-smbpass, and they work without a logout/login cycle. I tried this more than once, in two boxes, both with Hardy.
<slangasek> philsf: purging samba-common probably doesn't remove you from the sambashare group, if you were previously added to it :)
<cjwatson> NCommander: what's up?
<philsf> slangasek: that's probably it, but why isn't the group removed?
<slangasek> philsf: the second part of the behavior only applies to non-guest shares
<slangasek> philsf: because removing guests is wrong, generally
<philsf> removing guests? or groups?
<NCommander> cjwatson, any idea what voodoo will be needed to fix the current d-i/ARM builds?
<cjwatson> NCommander: nothing, wait for the current kernel upload to build?
<cjwatson> I already spoke with rtg about it and it looks like he took that into account
<NCommander> Ah
<NCommander> Cool
<philsf> slangasek: you were right about the group, the package in -proposed works for me. I'm confirming the bug as soon as I test in the second machine
<slangasek> great, thanks!
<philsf> no, thank you. bye
<superm1> tkamppeter_, i was wondering.  is there a particular reason that  "Show printers shared by other systems" isn't enabled by default in the gnome printer tool?
<dholbach> good morning
<LaserJock> hi dholbach
<dholbach> hi LaserJock, hi warp10
<warp10> morning dholbach!
<dholbach> cody-somerville: what do you think about bug 311571?
<ubottu> Launchpad bug 311571 in gnumeric "gnumeric-doc should be a depends for gnumeric in Xubuntu" [Low,Triaged] https://launchpad.net/bugs/311571
<LaserJock> I've been somewhat annoyed by that one in the past
<LaserJock> seems kind of odd to have ${Upstream-Version} on Conflicts
<pitti> Good morning
<tkamppeter> superm1, "Show printers shared by other systems" isn't enabled in s-c-p because it is not enabled in CUPS. pitti, why do we not enable to accept broadcasted CUPS queues from other machines by default in CUPS?
<pitti> superm1: hard to say really, it's full of comments about 180
<pitti> superm1: I don't have a problem with letting 180 move to -updates, since it's completely new
<pitti> superm1: but so far I didn't see a clear statement that the new 178 works
<pitti> tkamppeter: we discussed that in the past, and the prerequisite for that is to change KDE and GNOME to clearly tell apart automatically detected from manually configured printers in the print dialogs, so that you can't lure someone into using a bad printer (or at least it's more obvious)
<tkamppeter> pitti, are bugs reported to KDE and GNOME?
<pitti> tkamppeter: not sure, I don't think I filed them
<tkamppeter> superm1, ^^^
<tkamppeter> pitti, can you do so, otherwise the developers of the dialogs are not aware of the problem. You must report to GTK and Qt, as they provide the currently used dialogs.
<pitti> okay
<tkamppeter> pitti, thanks.
<mdke> dholbach: thanks for your comment on bug 126988, but I don't understand why that is happening. Revisions 735 to 737 introduce quite substantial changes, and Launchpad shows me them in the web interface. Are you sure you have the right branch?
<ubottu> Launchpad bug 126988 in gnome-user-docs "Incorrect text to add logout (exit) button" [Low,Confirmed] https://launchpad.net/bugs/126988
<mdke> dholbach: from the diff you've posted, it doesn't look like the package even has the right version number, I bumped it to 2.24.1+svn20090109ubuntu1 in revision 736
<dholbach> mdke: my mistake - sorry
<mdke> dholbach: ok! No worries
<mdke> dholbach: happy 2009 by the way
<dholbach> mdke: and the same to you :)
<dholbach> mdke: uploading
<dholbach> ... which might take a bit of time :)
<mdke> dholbach: great, thanks
<rniamo> hi
<rniamo> how could i do to redirect a pipe in a socket in both writing and reading ?
<Keybuk> a pipe is one-way only
<Keybuk> whatever you write to it comes out the reading end
<Keybuk> it's not possible to read and write from the same end
<Keybuk> if you want to do that, you need a socket
<rniamo> in fact i want to do a command like this : cmd1 | cmd2 but cmd1 and cmd2 on two diffrent PC
<Keybuk> cmd1 | ssh otherhost cmd2 ?
<rniamo> in fact i have to write a bash-lite
<rniamo> so i can't use ssh
<cjwatson> "have to write"?
<rniamo> my problem is i don't know how to read on the server from the client
<Mithrandir> you're not really explaining what your are trying to do, and I believe what you are trying to do has little to do with Ubuntu development.
<cjwatson> this is sounding a bit like a homework question ...
<rniamo> yes
<rniamo> unix homework
<cjwatson> don't ask those here, please. This is a working channel.
<Keybuk> rmcbride: http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html
<rniamo> where could i ask it please ?
<jpds> rniamo: Try: ##linux.
<cjwatson> rniamo: that really isn't our problem; ask your teacher if you need help
<cjwatson> we're not here to help people pass their CS homework
<Keybuk> (most of us never passed *our* CS homework) :p
<Mithrandir> Keybuk: we didn't?
<StevenK> Speak for yourself
<StevenK> I know I did
<directhex> i passed the fun bits
<rniamo> i just want some help, sorry if it is the bad chan
<StevenK> Sockets programming isn't exactly fun, but it is interesting
<mok0> rniamo: check out netcat
<Keybuk> StevenK: I find it fun
<mok0> rniamo: it does something similar
<rniamo> netcat ?
<mok0> rniamo: yes. Ask Mr. Google
<StevenK> Keybuk: You wrote a replacement for init, this makes you a masochist.
<rniamo> my problem is that socket are ok, pipe are ok but not both together
 * directhex ports init to ironpython
<Keybuk> StevenK: I prefer other people to inflict the pain ;)
<StevenK> cjwatson: Did you follow the jaunty-unr discussion at UDS?
<mok0> rniamo: right. netcat communicates via sockets
<rniamo> my problem is here http://paste.linuxassist.net/169910
<rniamo> i would like to add a close(0); dup(cbCmd->sock);
<StevenK> cjwatson: Essentially, -umpc goes away, and -netbook-remix turns up. I have a uncommited branch in the mobile seeds for this, but it also requires the task name to change, which I recall you saying needs tasksel changes. I looked at tasksel, and I ran away screaming ...
<Keybuk> ugh
<StevenK> cjwatson: Also, I'd like you to sanity check my commit, because I'd like to grow a ship seed, but the one that is in ubuntu.jaunty is perfectly fine.
<Keybuk> random sleep statements in cron.daily makes Keybuk unhappy
<cjwatson> StevenK: unr> no, I didn't
<cjwatson> StevenK: where's your branch?
<StevenK> cjwatson: I'm pushing it to a seperate location right now.
<cjwatson> StevenK: tasksel updates are trivial as long as you realise that almost all of the interesting stuff for us is autogenerated by ubuntu-seeds.pl
<cjwatson> and that you *must* *not* *touch* ubuntu-tasks/ by hand
<StevenK> cjwatson: Yeah, I looked at ubuntu-seeds.pl source and then decided the best step would be to talk to you. :-)
<StevenK> cjwatson: My branch is at sftp://chinstrap/home/stevenk/mobile.jaunty
<ccm> pitti: ping
<ccm> can somebody besides pitti tell, why i cannot find a debug package for "mairix"?
<Keybuk> wow
<Keybuk> just applying the "no legacy ptys" change to the kernel config reduces the average pid by ~1000
<Keybuk> not surprising, but shows just how much we did just for them
<cjwatson> ccm: http://ddebs.ubuntu.com/pool/universe/m/mairix/
<Keybuk> actually
<Keybuk> by ~2000
<Keybuk> because I forgot, each legacy pty had two kobjects
<Keybuk> which means two udev processes per kobject per trigger
<Keybuk> we trigger twice
<ccm> cjwatson: thank you. is it normal that i cannot install this directly via aptitude?
<cjwatson> ccm: you would have to add an appropriate line to sources.list
<cjwatson> that is normal
<ccm> thought I'd that and the dbg package is not listed in packages.ubuntu.com either, but anyway, i can work with the url
<ccm> thank you very much
<pitti> ccm: what cjwatson said; see https://wiki.ubuntu.com/DebuggingProgramCrash
<pitti> for instructions
<cjwatson> packages.ubuntu.com only looks at the main archive
<sebner> pitti: hallo mighty pitty \o/, any plans to merge newest debhelper? :)
<cjwatson> debug symbol packages are intentionally in a separate archive
<pitti> sebner: by default I'm not chasing any merges any more, unless someone asks me with a good reason :)
<sebner> pitti: csharp support for licensecheck \o/ (Asked by me in Debian also) ^^
<StevenK> pitti: Oh, I wanted your opinion on bug 312659?
<ubottu> Launchpad bug 312659 in kfreebsd-5 "Please remove kfreebsd-5 from Jaunty" [Wishlist,Confirmed] https://launchpad.net/bugs/312659
<pitti> "Use the bug subscription, Luke!" :-)
<seb128> pitti: we didn't have retracers running for over a month apparently, do you plan to work on those or should I look at that (I'm busy updating GNOME but I can try to have a look this week)?
<pitti> StevenK: will look in a minute
<pitti> seb128: that's on my TODO list this week (get jaunty retracers up and running, and care for the other ones)
<pitti> seb128: yesterday I fixed the client side apport stuff, now I'm ready to work on the server side
<seb128> pitti: ok thanks, I will let you do that then, I've lot of catching up to do on GNOME
 * seb128 hugs pitti
 * pitti hugs the Gnominator
<pitti> sebner: ok, can do
<sebner> pitti: \o/. besides I think there are a lot other cool improvements since there are some versions between actual ubuntu and actual debian version
<pitti> StevenK: looks fine to me
<StevenK> pitti: Yeah, I think it needs to be shot, too, but wanted to check. As well as wondering if the blacklist can deal with wildcards
<pitti> StevenK: wildcards> not as far as I know
<cjwatson> I would doubt it
<StevenK> That's going to be fun to sort out, then.
<StevenK> I'll remove it and db4.3 tomorrow
<pitti> StevenK: why? blacklist is source based
<StevenK> pitti: Exactly. Just depends how much source packages we're talking
<pitti> so you don't need to care about the bazillion binaries
<superm1> pitti, well i've got a large variety of hardware (including that machine I brought to UDS) working with 177.82 that i've been using since 177.82 was released.  I was one of the original folks affected by it's original bug reported to NV (The long suspends). I'll add a comment to the bug.
<pitti> superm1: thanks; so if you give your ok on the bug, and there aren't any reports about regressions, this is good to go
<pitti> (sorry if that came through twice, I got disconnected)
<superm1> pitti, okay great thanks
<superm1> in the future need to make sure these bugs dont get hijacked by new releases so they are easier to discern and track
<pitti> tkamppeter: I filed cups bug 3052, which is a prerequisite for changing the gtk/qt print dialogs
<pitti> tkamppeter: I just discovered that cups doesn't actually seem to tell locally configured vs. autodetected
<pitti> sebner: sid has 7.0.17, jaunty has 7.0.17ubuntu1 ?
<sebner> pitti: ARGH. sry. I mean devscripts. sry sry sry
<pitti> sebner: ah, ok; I just looked at the experimental debhelper, and that seems a bit delicate to merge
<sebner> pitti: heh, don't worry. I'm only interested in devscripts from sid :D
<pitti> sebner: that's a rather complicated merge; unless you beat me to it and do it yourself, mind to send me an email about it? I won't do it right now
<pitti> or do you want to prepare and test the merge yourself?
<sebner> pitti: I'm afraid that I won't have time besides that's stuff for pros like you :) Just do it anytime you have time and passion for it =)
<cjwatson> StevenK: you sure that inheriting from ubuntu.jaunty (rather than platform.jaunty) is a good idea? you've given the live seed different inheritance than it has in ubuntu.jaunty, which is a bit ... interesting
<cjwatson> though I suppose technically feasible
<cjwatson> StevenK: have you run this through germinate to look at the result?
<cjwatson> StevenK: no netbook-remix-dev?
<StevenK> mobile-dev is dead
<Baby> pitti: ping! :)
<pitti> Baby: hello
<StevenK> cjwatson: We don't need it and decided it was time to kill it at UDS.
<cjwatson> ok
<StevenK> cjwatson: platform.jaunty doesn't have ship.
<Baby> pitti: :)
<cjwatson> StevenK: but ubuntu.jaunty's ship inherits from desktop
<StevenK> cjwatson: I suppose I can drop live from mobile.jaunty's STRUCTURE, and it will sort it out?
<cjwatson> StevenK: did you consider whether you would be better off writing your own ship seed?
<cjwatson> StevenK: do you want live or ship-live?
<cjwatson> I'm not entirely clear on what you actually want, which makes it hard to advise :)
<StevenK> cjwatson: Oh, right. We want the list of packages that are included as .debs on the Live CDs
<cjwatson> that is NOT ship, it's ship-live
<StevenK> Which I think is ship-live
<cjwatson> very important to be clear on the distinction
<cjwatson> what do you want in the live filesystem?
<cjwatson> and do you really want all the stuff that's in ubuntu.jaunty's live and ship-live?
<cjwatson> I wouldn't have thought you'd want ndiswrapper or ISDN utilities, for instance
<StevenK> Well, from this seed base, either mobile-mid or mobile-netbook-remix plus casper and ubiquity
<cjwatson> nor that you would necessarily want the same language packs
<DktrKranz> could a sponsor for main look at bug 254790? It blocks some dietlibc fixes I'd like to upload.
<cjwatson> or even perhaps the same filesystem support
<ubottu> Launchpad bug 254790 in binutils "strip segfaults on dietlibc-built executables" [Unknown,Fix released] https://launchpad.net/bugs/254790
<cjwatson> StevenK: it sounds to me as if you should inherit from platform.jaunty and write your own live and ship-live seeds, just as e.g. Kubuntu does
<StevenK> cjwatson: I said the same thing in the session, and persia talked about threatning to find a MID form-factor device with ISDN. :-)
<cjwatson> otherwise you're going to end up with a bunch of junk you don't want
<cjwatson> and you won't easily be able to control it
<cjwatson> as soon as you want to control it, you're going to end up writing your own live and ship-live seeds anyway
 * StevenK nods
<cjwatson> so you might as well start out that way, I think
<persia> StevenK, I threatened to show you my CF ISDN card that I used on my Zaurus for connectivity for years, rather.
<StevenK> Yeah, makes sense.
<cjwatson> also, if you need different shipped objects one of which is mobile-mid + live and one of which is mobile-netbook-remix + live, you're going to need two live-a-like seeds (and ship-live-a-like, presumably)
<cjwatson> but you can perhaps worry about that later
<StevenK> So fix that, commit that, fiddle with mobile-meta and upload it, and then prod you to fix tasksel?
<StevenK> persia: Woot, two technologies I hate in the same device, Compact Flash and ISDN.
<cjwatson> this is because a seed can only be germinated against a single set of ancestor seeds, and if you germinate live to inherit from netbook-remix and then try to use it with mid, you may well end up with missing dependencies
<cjwatson> StevenK: yes. Note also that your branch doesn't seem to be up to date with current mobile.jaunty
<StevenK> Mmmmm
<cjwatson> so you'll need to merge into mobile.jaunty rather than just pushing over the top
<StevenK> cjwatson: It isn't, on purpose
<cjwatson> well that's a bug :)
<cjwatson> don't lose history even if you want to revert it
<StevenK> cjwatson: Oh, it's from the same base, so it's under control
<cjwatson> fix the things I mentioned and push again, then I can have another look?
<StevenK> Hm. I unbound, commited and push. Now what do I do ...
<cjwatson> commit and push again?
<cjwatson> (what are you trying to do?)
<StevenK> Trying to figure out how to resurrect {,ship-}live
<cjwatson> 'vi live'
<cjwatson> or are you trying to make it have the same file-id as the corresponding files in ubuntu.jaunty so that you can merge? that may not be necessary
<StevenK> I'm trying to get the old files back
<cjwatson> what old files?
<cjwatson> in what branch?
<cjwatson> the live and ship-live seeds haven't been in mobile.jaunty since r1310
<StevenK> {,ship}live used to exist in mobile.{intrepid,jaunty}
<StevenK> Yup, those are what I'm trying to resurrect, since they probably have most of the right content
<cjwatson> so, firstly, you *could* just re-add them afresh; essentially the only thing that will break is merges from ubuntu.jaunty, which are not that important anyway
<cjwatson> however, it is *slightly* more elegant to have them share a file-id I suppose
<persia> bzr revert ship --revision 1310 ?
<persia> Err.  --revision=1310
<StevenK> Ah, that would be the magic
<cjwatson> oh, that works, I was going to suggest get -r1309 and add --file-ids-from
<cjwatson> but persia's approach is shorter
<cjwatson> also, -r1309 not 1310 (1310 is the revision that removed them)
<persia> Oh, right.
<persia> Also probably want to use the correct filenames.
<StevenK> Yeah, I remembered that, and s/10/09/ before running
<StevenK> I did that too
 * StevenK waits for bzr push
<StevenK> cjwatson: Pushed
<StevenK> cjwatson: I didn't change what live inherients from, since I'm still unsure about that bit.
<tkamppeter> pitti, CUPS is already capable of telling whether a queue is locally defined or picked up from a broadcast. CUPS queues have a CUPS_PRINTER_DISCOVERED bit set then. See /usr/include/cups/cups.h, enumeration cups_ptype_e.
<Keybuk> sure
<Keybuk> cjwatson: udev has the same need
<Keybuk> we load modules, but want to silently succeed as cheaply as possible if the module is a built-in
<cjwatson> apw: http://bazaar.launchpad.net/~ubuntu-core-dev/hw-detect/ubuntu/revision/104, http://bazaar.launchpad.net/~ubuntu-core-dev/mdcfg/ubuntu/revision/1072, and http://bazaar.launchpad.net/~ubuntu-core-dev/partman-md/ubuntu/revision/909 are all bodges around this same problem
<cjwatson> apw: the second and third are sane enough actually, but the first is a good illustration of the difficulty
<cjwatson> (the second and third were patches for real installer bugs TBH; it was using has-the-module-been-loaded-yet as a key for rather too much initialisation code)
<apw> ok so why can't we just modprobe, ignore the result
<apw> and then try and use the functionality and blow up then if its not there?
<cjwatson> the installer tries to support a variety of kernels fairly cleanly, partly because of custom kernels (people do in fact do that quite a bit) and partly because the kernel keeps changing under us :)
<cjwatson> and it's much better to be able to report "this facility is unavailable" rather than "thingummyflop blew up with ENOSYS"
<cjwatson> (or EINVAL more likely I guess)
<apw> right, but is not the test in #3 there actualy a 'do we have the function'
<apw> that should be after an ignored modprobe
<cjwatson> probably best look at #1 instead
<cjwatson> the module_probe function there is a wrapper for something that tries to load the module and otherwise fails with a red-screen
<Keybuk> the difficult bit is telling the difference between "module is built-in" and "module is missing"
<cjwatson> and the bodge is that I've had to incorporate a check for whether the function is present
<apw> right, you've done what i am saying
<cjwatson> which is, frankly, a pig to do sometimes; it's not easily possible for dm-round-robin without actually setting up a hardware round-robin multipath, for instance
<apw> just i think you should probe the modules as well
<apw> and ignore any failure
<apw> so it works either way
<cjwatson> I think that would be a straightforward regression in the installer's ability to report errors
<cjwatson> it would fall over much later with a much more obscure error
<apw> not if you do it like
<apw> if ! dmsetup version; then
<apw>   modprobe foo || true
<apw>  if ! dmsetup_version; then
<apw>     ERROR
<cjwatson> so how do I do that for dm-round-robin please? :)
<cjwatson> (I did look, quite hard)
<apw> well there is an issue
<apw> do you always know the kernel before hand?
<cjwatson> and honestly, all this having to putz about with dmsetup is really clumsy
<Keybuk> doesn't that defeat the object of building in in the first place
<cjwatson> that code used to be 'module_probe dm-mod'
<cjwatson> quick and easy
<Keybuk> if it's more expensive to determine whether something is built-in than to load it as a module ?
<cjwatson> right, I definitely want something as lightweight as possible
<apw> ...
<apw> so does the installer CD know the kernel its built with?
<apw> could we extract the information out of the kernel as we build the CD?
<cjwatson> the installer CD might, but I'm not going to hardcode that knowledge into installer scripts!
<apw> so you _know_
<cjwatson> some of this code is run in contexts where that is not helpful
<apw> stupid kernel
<cjwatson> it would be *much* *MUCH* better for it to detect; Keybuk's proposed modprobe option is *exactly* what I'm looking for
<apw> but modprobe simply cannot know
<apw> as things stand, either its =y or =n, but i don't know which
<cjwatson> isn't the presence of the driver exposed in /sys?
<cjwatson> also, BTW, it's not a matter of what the installer CD is built with; the installer loads udebs containing kernel modules into memory at runtime
<apw> that is true of some modules, but like crypto, does that appear as a driver?
<cjwatson> the modular ones do
<cjwatson> the non-modular ones *currently* don't
<cjwatson> but we could just go back to building them as modules until that knowledge is available
<cjwatson> though we'd still have the dm problem
<apw> well you may have a case to back those out if we cant get a sensible fix before JJ releases
<apw> one of the good things is that you have blown up now, before it set in stone
<Keybuk> cjwatson: the presence of a driver is exposed
<Keybuk> not the presence of a module
<Keybuk> you don't pass driver names to modprobe
<Keybuk> you pass module names
<cjwatson> apw: indeed
<apw> module aliases may help here to convert back
<cjwatson> Keybuk: I don't see e.g. dm-mod exposed anywhere in /sys
<Keybuk> right, it wouldn't be
<Keybuk> it's a subsystem
<apw> we do build in the config, into the kernel right?
<apw> so we can get it out in theory
<cjwatson> are you thinking of CONFIG_IKCONFIG_PROC?
<apw> after boot, so we can reconstruct /boot/config-*
<apw> we have half of that turned on
<apw> the half that keeps the stuff in the on disk binary image of the kernel
<apw> i believe
<cjwatson> I would echo Keybuk's comment that grepping a text file (kernel-generated or otherwise) for this is going to be slow
<Keybuk> I have an amusing idea ;)
<Keybuk> you could auto-generate a modprobe.d blacklist file
<cjwatson> you could have /sys/config/FEATURE
<cjwatson> present or absent
<apw> cjwatson, the code you have there is running a depmod -a
<apw> so any single additional grep is free by comparison
<Keybuk> apw: who would own the list of config -> module name mappings?
<cjwatson> that's only because it might have just loaded modules. The same consideration does not apply during boot
<cjwatson> er by loaded modules I mean installed some udebs containing modules
<cjwatson> that is also not the case in every installer context in question
<apw> Keybuk, i wonder if that is expressed in the kernel
<Keybuk> apw: it would have to be
<Keybuk> maintaining a kernel config (kernel maintained) to module name (kernel maintained) mapping outside the kernel is not exactly a plan made of awesome
<Keybuk> from the modprobe pov. we simply need a list of module names that we can silently succeed because they have been built-in
<cjwatson> yeah, I'm not keen on having to name the feature in installer code either
<cjwatson> from my POV the config feature name is a kernel implementation detail that might change at any time; the module names are at least a little more persistent than that
<apw> and none of it is obvious in the source
<Keybuk> implementing the "succeed silently" in modprobe is easy
<Keybuk> we just make the module name an empty alias
<apw> the hard part is getting that list
<cjwatson> could that be exported via depmod then
<Keybuk> so modprobe dm-mod would be equilent to just modprobe ""
<cjwatson> ?
<Keybuk> cjwatson: yeah, I'd append it to modules.alias
<Keybuk> the hard part, as apw says, is getting that list
<apw> what if we did a hybrid approach
<apw> you tell us which modules you are using and somehow we work out the config
<apw> options they represent
<Keybuk> apw: from a udev point of view, everything ;)
<cjwatson> apw: that's really tricky in general, that installer code is dynamic, synced/merged from Debian, etc.
<apw> perhaps that could be kept with the config info so it would be kept up to date
<cjwatson> where does the information that goes into modinfo come from?
<Keybuk> cjwatson: the modules themselves
<Keybuk> it's a section in the .ko that depmod reads
<cjwatson> Keybuk: right, but I mean where in the kernel source
<cjwatson> what's the macro that does it
<cjwatson> or struct or whatever
<apw> the module alaises, are complex
<apw> there are some magic programs which mush it about to make them
<apw> from some of the other structures in the kernel
<Keybuk> actually, that's an interesting point, we'd need the modaliases of the modules that are built-in too
<apw> just been looking at it for MMC
<cjwatson> but at least it is in the C files and not just in the Makefiles
<Keybuk> otherwise we'd waste a lot of time
<cjwatson> which means the problem is tractable
<apw> but you can't tell from the foo.c what the .ko is called
<cjwatson> you just need to make MODULE_* do something useful for built-in drivers
<cjwatson> oh, that is only in Makefile?
<cjwatson> bah
<Keybuk> the name of the module is only in the Makefile
<Keybuk> apw: what happens to MODULE_DEVICE_TABLE for the kernel?
<Keybuk> in fact, can you extract MODULE_* at all for built-ins ?
<apw> there is a a script which converts that into specific format MODULE_ALIAS entries
<cjwatson> you'd have to put a section in vmlinuz that's later stripped
<cjwatson> I think
<apw> which are then compiled and linked with the .o to make the .ko
<Keybuk> apw: yeah, but where do they go when you link the .o into built-in.o ?
<apw> hrmm, you mean is there one in vmlinux
<apw> that we are not looking at
<Keybuk> that's what I mean, yes ;)
<apw> when i was looking at depmod (a long time ago) i think it did read and skip vmlinux for most things
<apw> so it might be in there
<cjwatson> __MODULE_INFO is an empty macro for built-ins
 * apw needs a module which is built in
<Keybuk> unix
<cjwatson> right now, the information is not in the .o files that get linked into built-in.o
<cjwatson> but it could be if you mucked about with moduleparam.h
<apw> yeah, so there is no equivalent
<apw> well you'd need to modpost vmlinux too
<cjwatson> well, I didn't think it could be done entirely without kernel changes, certainly
<Keybuk> cjwatson: the other problem is the kernel developers got clever with Make
<cjwatson> but I was wondering if there was a relatively lightweight set of changes possible
<Keybuk> so the only difference between a .ko compile and a .o one is just whether some variable is y or m ;)
<Keybuk> obj-y += something.o
<Keybuk> vs.
<Keybuk> obj-m += something.o
<cjwatson> yeah, I know
<cjwatson> MODULE is defined for obj-m, though
 * Keybuk can't remember where the ko names are defined
<apw> ok lets look at it the other way round
<apw> we have a probe point 'module_init'
<apw> right now when we load one it makes /sysfs/module/<foo>
<apw> perhaps we could hijack that and have a /sys/build-in/<foo> appear
<Keybuk> couldn't we just have a /sys/module/<foo> for built-ins?
<cjwatson> hm, excuse me, baby needs feeding
<Keybuk> I guess you wouldn't do that actually, because the kobjects would be different
<Keybuk> but /sys/built-in/<foo> would be nice
<Keybuk> apw: actually, where *are* module names defined?!
 * apw is looking at that right now
<apw> there is a MODULE define floating about
<apw> actually the specific line obj-$(CONFIG) += foo.ko
<apw> does give you the mapping from CONFIG_foo to foo.ko
<Keybuk> err
<Keybuk> I don't see that line anywhere?
<Keybuk> it's always
<Keybuk> obj-$(CONFIG) += foo.o
<apw> obj-$(CONFIG_DM_DELAY)          += dm-delay.o
<apw> yeah that one
<apw> and that _is_ the .ko name
<Keybuk> so the ko name is the name of the first object?
<apw> not the first object,
<apw> all objects
<Keybuk> err
<apw> everything on the right there is a real module
<Keybuk> how does it deal with multiple .o files for one module?
<apw> obj-$(CONFIG_BLK_DEV_DM)        += dm-mod.o
<Keybuk> obj-$(CONFIG_HERMES)            += orinoco.o hermes.o hermes_dld.o
<apw> dm-mod-objs     := dm.o dm-table.o dm-target.o dm-linear.o dm-stripe.o \
<apw>                    dm-ioctl.o dm-io.o dm-kcopyd.o
<apw> via _magic_
<Keybuk> oh, I see what you mean
<apw> /lib/modules/2.6.27-10-generic/kernel/drivers/net/wireless/hermes.ko
<apw> yeah all of yours there are real places
<apw> s/places/modules
<apw> Keybuk, it is _possible_ we still have a THIS_MODULE, when we are building in
<apw> if so we migth be able to magic up soimething in /sys/ for the module names
<apw> needs some playing ...
 * apw drops to test a kernel
<soren> Sorry, but I don't see why we can't just grab whatever's in obj-y and put that in the blacklist file as Keybuk suggested (stripping the .o extension, of course).
<Keybuk> soren: I'd put it in the alias file
<soren> Right, or that.
<soren> Is the obj-y variable perhaps not global?
 * soren hasn't really quite worked out the details of the kernel's makefile magic yet
<soren> Oh, right, definitely the alias file.
 * soren was still thinking in installer context, but of course we want this in the installed system as well and have it work with different versions of the kernel installed.
<cjwatson> StevenK: as long as you merge into current mobile.jaunty (should end up with the same output) to preserve history, then I think that's fine
<cjwatson> StevenK: I do think you're likely to want to pare down live and ship-live at some point
<cjwatson> StevenK: but otherwise go ahead
<slytherin> could an archive admin please prioritise the sync of plexus-io (bug #312789) from unstable: it's blocking processing of a host of other syncs for maven support
<ubottu> Launchpad bug 312789 in ubuntu "Please sync plexus-io 1.0~alpha2-2 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/312789
<cjwatson> slytherin: done
<cjwatson> yeesh, enough duplicates? :)
<slytherin> cjwatson: that was due to the bug in requestsync. :-)
<slytherin> cjwatson: thanks.
<Laney> Which release first enabled recommends-by-default? Intrepid or Hardy?
<seb128> intrepid
<Laney> thanks
<soren> Apparantly, I told the update-grub ucf thing the wrong thing at some point, and now my menu.lst is never updated anymore. How am I supposed to fix this?
<soren> I know how I *could*, but how *should* I do it?
<ScottK> File a bug and then complain a lot?
<soren> Not my style :)
<ScottK> Right, mine neither, but it seems the most common approach.
<slytherin> cjwatson: can you please also check the plexus-io binary in queue if you have time?
<cjwatson> slytherin: done
<slytherin> cjwatson: thanks. Now I can lods of sync requests when I go home. :-)
<persia> soren, do an md5sum, and push that to the ucf md5sum file.
<soren> persia: Seriously? That's what we tell users to do?
<persia> soren, man ucf provides detailed instructions on this procedure.
<soren> persia: As I said: I know how I *could* do it. :)
<persia> In practice it's usually something like md5sum foo.conf > md5sum file.
<persia> Since it's a one-liner, it's been historically easy to put on wiki pages, in IRC, etc.
<persia> soren, Feel free to implement --takeover if you prefer :)
<pitti> tkamppeter: oh, cool, thanks; seems that lpstat just does not expose that
<kirkland> cjwatson: okay, so what action is to be taken with respect to the crypto modules?  should that patch be reverted by rtg?
<kirkland> cjwatson: and they be added to crypto-modules?
<kirkland> cjwatson: or are we holding out for a magic modprobe option that --succeeds-if-already-built-in ?
<cjwatson> well, that would be my favoured action for now, although if some magic modprobe option is likely to be feasible in the short term then that would be fine
<cjwatson> rtg: what do you think?
<rtg> cjwatson: I don't have an issue with restoring crypto as modules, but it seems like this is gonna be a generic issue with the installer, i.e., determining what functionality exists in the kernel v.s. modules.
<rtg> its just 3 more modules that have to be installed at boot time
<cjwatson> it is a generic issue, but I think for the sake of expediency I would be happy to work around it elsewhere; it's just that crypto turns out to be rather hard to work around in that kind of way
<cjwatson> apw pointed out that if you're using crypto modules then you're probably going to end up stopping and waiting for a password anyway
<cjwatson> really the only other significant case is dm*, and I've basically already worked around that (albeit with some internal cursing :-) )
<rtg> kirkland: that true? when auto-login is enabled?
<cjwatson> at any rate, I'm not sure the encrypted-filesystem case should be taken as the fast path
<rtg> cjwatson: we made the assumption that any file system that is oft used should be built in
<cjwatson> I understand that, just saying that if you're encrypting filesystems then your system is going to take longer to boot anyway
<rtg> cjwatson: ok, I'll back out those changes, i.e., crypto-fs, CBC, AES, and (something else, can't remember exactly).
<kirkland> rtg: is what part true?
<cjwatson> rtg: thanks, much appreciated; that'll relieve some headaches
<rtg> kirkland: do you have to pause for a crypto passwd during auto-login?
<cjwatson> rtg: I suspect that the modprobe --ok-if-built-in option is the right long-term answer
<kirkland> rtg: ebc
<kirkland> rtg: if you are auto-logging in, on a machine installed on top of lvm+crypt, then yes
<rtg> kirkland: how about encrypted /home or Private?
<kirkland> rtg: you're talking about an encrypted private directory, plus auto-login, you'll get prompted when you open your Private directory
<kirkland> rtg: encrypted home + auto-login are mutually exclusive
<rtg> kirkland: good, thats what I expected :)
<kirkland> rtg: ie, yes, you will need to enter a password to login to a system with an encrypted home
<kirkland> cjwatson: okay, so rtg is going to back out cbc, aes, and ecb of kernel builtin's ...  who's going to make sure that they simultaneously get pushed to crypto-modules?
<cjwatson> that happens automatically, relax :)
<kirkland> cjwatson: :-)
<rtg> cjwatson: it'll take an hour or 2, but I'll get those changes uploaded today.
<cjwatson> crypto-modules is built by the kernel
<cjwatson> rtg: oh, you will need to make sure they're listed in debian/d-i/modules/crypto-modules in the same commit though
<rtg> I also have to remember to get them back into the d-i information
<kirkland> cjwatson: and what about getting the encrypt-home code in the installer to apt-get install crypto-modules?  should i make ecryptfs-utils depend on that?
<cjwatson> kirkland: I already did that
<kirkland> cjwatson: \o/
<cjwatson> the only possible change still required is to have user-setup modprobe some things up-front before chrooting
<kirkland> cjwatson: ah, okay.  i will need those 3 modules loaded, before running ecryptfs-setup-private (aes, cbc, ecb)
<cjwatson> is there any circumstance in which it might want different modules?
<tkamppeter> pitti, I have a question about a possible Intrepid SRU, where the fix is not a small patch.
<kirkland> cjwatson: well, ecryptfs support far more ciphers, but the "Ubuntu Encrypted Private" and "Ubuntu Encrypted Home" setups are fairly constrained to aes
<cjwatson> ok, on its way
<cjwatson> and then that should make partman-crypto automatically start working again
<pitti> tkamppeter: well, ask :)
<alex-weej> does anyone know the status of multiarch?
<alex-weej> i am continuously kicked in the balls for running 64 bit
<alex-weej> wine needs 32 bit pulseaudio ALSA plugin in order to work properly
<alex-weej> and it's not in ia32-libs
<cjwatson> no status to the best of my knowledge
 * directhex summons Mithrandir 
 * alex-weej wonders if it's worth opening a blueprint
<cjwatson> I doubt it
<cjwatson> I mean, you could add to the thousands of blueprints that already exist
<cjwatson> but it won't have any effect on magicking up people to work on it
<alex-weej> of course, but at least it can be tracked better and i wouldn't have to come here asking
<directhex> did you do a search for blueprints before asking?
<cjwatson> only if there's only one canonical (ahem) blueprint for it. In reality I suspect there are several already, none of which have their status updated ...
<alex-weej> directhex: i googled.
<alex-weej> nothing
<cjwatson> items not on the roadmap and without developers working on it simply aren't going to have status regularly updated
<tkamppeter> pitti, it is bug 314018. The GS 8.63 breaks bold text in PS output of OOo when converting to PDF while printing (/usr/lib/cups/filter/pstopdf.
<ubottu> Launchpad bug 314018 in ghostscript "print bold in openoffice gives bad output" [High,In progress] https://launchpad.net/bugs/314018
<tkamppeter> pitti, this problem is fixed in Ghostscript 8.64 (release on Feb 1), see http://bugs.ghostscript.com/show_bug.cgi?id=689970 and http://bugs.ghostscript.com/show_bug.cgi?id=690220
<ubottu> bugs.ghostscript.com bug 689970 in PDF Writer "major artefacts in pdfwriter output" [Major,Closed: fixed]
<pitti> tkamppeter: is this a regression?
<tkamppeter> pitti, yes. In Hardy PS never got converted to PDF when printing.
<tkamppeter> Unfortunately, the fix is not a simple patch, see http://bugs.ghostscript.com/show_bug.cgi?id=690025#c7 which refers to fixes for the above-mentioned two bugs.
<ubottu> bugs.ghostscript.com bug 690025 in Printer Driver "pxlmono driver prints some glyphs as squares when the input is PostScript generated by Ghostscript" [Major,New]
<pitti> tkamppeter: so it's http://ghostscript.com/pipermail/gs-cvs/2008-November/008772.html and http://ghostscript.com/pipermail/gs-cvs/2008-November/008827.html ?
<pitti> tkamppeter: size-wise they are quite big, indeed, but still bearable with lots of testing
<pitti> tkamppeter: however, the second patch changes the API/ABI, which worries me
<pitti> we shouldn't do that in an SRU
<pitti> tseliot: hey, happy new year!
<tseliot> pitti: happy new year to you ;)
<tkamppeter> pitti, and they say that the patches are based on more text rendering improvements.
<pitti> tseliot: we will go through the specs in today's desktop team meeting and take a look at what's realistic for Jaunty; would you like to (and do you have time to) join?
<pitti> tkamppeter: is there an easier workaround?
<tseliot> pitti: sure, when/where is it?
<pitti> changes to ghostscript have a large regressio npotential
<pitti> tseliot: in 9 minutes (1730 CET) in #ubuntu-desktop
<tseliot> pitti: ok, I'll be there
<pitti> great, thanks
<pitti> tseliot: you can lurk, I'll ping you when it becomes interesting for you; shouldn't take more than 10 minutes for you
<tseliot> ok, great
<tkamppeter> pitti, I have done two quick tests with OOo by myself and Bold printing works for me. So the bug seems to occur only with certain fonts (otherwise we must have already received complaints before release of Intrepid). So it seems that the bug is not so severe.
<pitti> Riddell: this print dialog http://people.ubuntu.com/~pitti/screenshots/print_dialog_kde.png -- is this Qt, or KDE?
<pitti> Riddell: I'd like to file the corresponding Qt/KDE bug for bug 314408 upstream
<ubottu> Launchpad bug 314408 in gtk+2.0 "Please separate autodetected from locally configured printers" [Wishlist,Triaged] https://launchpad.net/bugs/314408
<Riddell> pitti: there's no kde dialogue any more, Qt only
<pitti> Riddell: ah, nice, thanks
<tkamppeter> pitti, I have found a simple workaround: When one runs "ps2ps" over the faulty PS file and prints (or converts with ps2pdf) the resulting PS file, the output is correct.
<Riddell> pitti: Qt bugs go to http://trolltech.com/developer/task-tracker
<Riddell> or ask ThomasZ
<tkamppeter> pitti, so one only needs to check whether incoming PostScript is from OOo and if so one massages it with ps2ps, as one already does with incoming PS from encrypted PDFs printed with Adobe Reader.
<dholbach> bryce: will you upload the patch on bug 181948?
<ubottu> Launchpad bug 181948 in exim4 "exiqgrep: error on messages w/o size" [Medium,Triaged] https://launchpad.net/bugs/181948
<bryce> dholbach: I can.  I reviewed it when we were in freeze so assumed someone would take care of it later
<dholbach> bryce: rock on! :)
<sebner> dholbach: may I answer in german if it's only for you? :)
<dholbach> sebner: eh?
<sebner> dholbach: you sent me a mail today about further questinos
<sebner> *questions
<dholbach> sebner: sure, do it if that's easier for you
<dholbach> that's fine :)
<dholbach> thanks in advance
<bryce> dholbach: speaking of which... I do my 1-hr sponsorship each week, however post-freeze it is problematic because you can't upload anything
<sebner> dholbach: I don't care but since we are both native german speakers ^^
<bryce> dholbach: this last go-around I still did it, but just listed my view on patches even if they couldn't be uploaded at the time
<dholbach> bryce: I know - I think it's good to state that, unsubscribe the team and assign it to you, so you can upload it in the next cycle
<bryce> dholbach: however I wonder if it even makes sense to be doing any sponsorship work post-freeze
<dholbach> bryce: it very much depends on the case
<dholbach> if it's important, it should go in
<bryce> dholbach: well I'm usually not one to judge importance, since they're almost always non-xorg stuff
<dholbach> if it has a bunch of duplicates and fixes it, it should go in :)
<dholbach> a simple string fix can wait for release+1
<Keybuk> cjwatson: what's $dh{NOSCRIPTS} all about?
<Keybuk> looking at dh_installudev, it seems to have a block to modify preinst/postinst
<Keybuk> but we don't use that do we?
<cjwatson> $dh{NOSCRIPTS} is set when the -n option is used
<cjwatson> and we certainly do use that block, in that it's active - I have no idea whether it does anything useful for us
<cjwatson> the script fragments in question are in autoscripts/
<cjwatson> and appear to be moving conffiles around
<cjwatson> cf. debhelper 5.0.45 changelog
<Keybuk> right
<Keybuk> but they're moving things in/out of the parent directory of udev
<Keybuk> which is things Debian do, but not us
<cjwatson> might affect sidegrades from old versions of Debian to Ubuntu, but *shrug*. If you want to remove it it's your call. Don't you need similar logic to decide whether to remove or keep files in /etc/udev/rules.d/ anyway though?
<Keybuk> hmm
<Keybuk> looks like it's sidegrade stuff yeah
<Keybuk>   * dh_installudev: Install udev rules directly into /etc/udev/rules.d/, not
<Keybuk>     using the symlinks. MD has agreed that this is more appropriate for most
<Keybuk>     packages.
<Keybuk> matches that changelog entry
<Keybuk> I was thinking of abusing that to handle the automigration yeah ;)
<cjwatson> you could always just extend it; I tend to leave such code there forever
<cjwatson> (but I have the feeling we've had this discussion before ...)
<Keybuk> :D
<Keybuk> well, yes
<Keybuk> as in copying that block a couple more times
<Keybuk> I thought we must have that disabled somehow, but it doesn't look like it
<Keybuk> I can see it in preinsts, etc.
<Keybuk> cjwatson: http://people.ubuntu.com/~scott/debhelper_7.0.17ubuntu2.debdiff
<Keybuk> does that look sane?
<tkamppeter> pitti, I hav now suggested a workaround to the reporters of bug 314018, but if one uses a printer with the pxlmono Ghostscript driver one gets easily bitten by http://bugs.ghostscript.com/show_bug.cgi?id=690025 then. So the workaround is not perfect.
<ubottu> bugs.ghostscript.com bug 690025 in Printer Driver "pxlmono driver prints some glyphs as squares when the input is PostScript generated by Ghostscript" [Major,New]
<ubottu> Launchpad bug 314018 in ghostscript "print bold in openoffice gives bad output" [High,In progress] https://launchpad.net/bugs/314018
<mathiaz> zul: there was discussion about kde requiring mysql 5.1 in jaunty
<zul> is it on a mailing list somewhere
<cjwatson> Keybuk: substituting the same autoscript twice is a bit unusual and perhaps deserves a comment, but it looks like it should be OK, yes
<Riddell> not sure what the context for this conversation is but amarok needs mysql 5.1's embedded library
<Riddell> mathiaz, zul ^^
<Keybuk> cjwatson: ironically, this means our dh_installudev matches udev upstream ;)
<Keybuk> and Debian's changes everything strangely :p
<cjwatson> heh
<zul> Riddell: we are thinking about upgrading mysql 5.1 for jaunty
<mathiaz> Riddell: right - that's what I remember
<Keybuk> and I so keep typing devmapper when I mean debhelper
<zul> mathiaz: 117 packages will need to be updated for the mysql library
<Riddell> zul: who's we?  I believe server team want 5.0 from UDS conversations
<mathiaz> Riddell: and amarok is targeted for main for jaunty?
<zul> Riddell: correct
<Riddell> mathiaz: it would be a big blow if it wasn't
<Keybuk> actually, that's not quite right :-/
<mathiaz> zul: considering that we only want one version of mysql in main, we'll have to decide if we go for 5.1 soon
<zul> mathiaz: im just afraid of things that will break if we do decide to go for 5.1
<Keybuk> cjwatson: http://people.ubuntu.com/~scott/debhelper_7.0.17ubuntu2.debdiff
<Keybuk> that should be much better
<cjwatson> oh yes, of course it would have to be a different fragment
<Keybuk> that'll remove /etc/udev/rules.d/NN-something.rules if unmodified
<Keybuk> because the package ships /lib/udev/rules.d/NN-something.rules anyway
<cjwatson> Keybuk: you should check $old ne $rule for the postinst substitution
<Keybuk> if modified, it'll leave it - udev handles the override
<Keybuk> ah, good point
<Keybuk> rather than $default
<cjwatson> (which can supersede the $default check, I think)
<cjwatson> I'm struggling to figure out why you're moving it about inside /etc in the postinst
<Keybuk> isn't it directly equivalent?
<Keybuk> because if it was previously using the default, it would be 50-foo.rules
<Keybuk> but would now have /lib/udev/rules.d/40-foo.rules
<cjwatson> not directly equivalent if $dh{PRIORITY} happens to be 50 but not $default
<Keybuk> so it moves the one in /etc to 40-foo.rules to match
<Keybuk> err, if $dh{PRIORITY} is 50, then it'll be 50 across the board
<cjwatson> oh, err, right. I think. ok
<Keybuk> so you don't need to do the move
<Keybuk> you only need to do the move because the default changes
<Keybuk> if you're not using the default, no move is required
<cjwatson> oh, yeah, I see how $default is handled above
<cjwatson> I think that debdiff is fine
 * Keybuk tests on a selection of packages
<pitti> tkamppeter: (was in a meeting, will reply in 30 mins)
<Keybuk> hah!
<Keybuk> only two packages in our default install actually use dh_installudev *sigh*
<sebner> Keybuk: ahoi! I heard you are responsible for MoM. What's now with new MoM -> DaD progress?
<Keybuk> sebner: I don't know
<sebner> nah
<sebner> Keybuk: so who knows? ;)
<Keybuk> Adri2000 I guess
<Adri2000> ahah
<sebner> Keybuk: he told me to ask you :P
<Adri2000> bug #192972
<Keybuk> yay loop
<ubottu> Launchpad bug 192972 in merge-o-matic "Comments support" [Undecided,In progress] https://launchpad.net/bugs/192972
<Adri2000> Keybuk: is there something I can do to help get the "server support" ?
<Keybuk> Adri2000: well, the basic problem is your patch relies on mod_python
<Keybuk> MoM is an attractive attack vector if it suddenly has server scripting support
<Keybuk> so any script code should be very paranoid and very well audited
<Keybuk> CGI would be inherently nicer
<Adri2000> ok. well if you really want cgi, given that I don't know much about it, if anyone wants to help out with that, it'd be very welcome
<cjwatson> Keybuk: I was going to make pcmciautils use it in this round
<Keybuk> (elmo is disagreeing with me, which goes to show you should never second guess a sysadmin :p)
<Adri2000> Keybuk: who makes the final decision of whether mod_python is ok or not?
<Keybuk> Adri2000: canonical sysadmin, I guess
<Keybuk> I don't think we have a procedure :p
<LaserJock> Keybuk: armwrestle?
<LaserJock> maybe rock-paper-scissors
<LaserJock> or mao
<jpds> LaserJock: Chess.
<Mithrandir> I think you have to make elmo do his laugh-of-doom
<Mithrandir> nah, too easy.
<LaserJock> heh
<elmo> well, I'm less concerned about CGI vs mod python, than I am about the generic security issues, and honestly, I think someone with a background in web security needs to look at this
<elmo> unless I'm missing something glaring, it does absolutely no filtering on the comments whatsoever
<Adri2000> right
<pitti> tkamppeter: only with certain fonts> that's relieving
<pitti> Riddell: I filed a bug there, but didn't get an URL, nor does it appear in the search; do these tickets get manual approval?
<pitti> tkamppeter: pstops> can this be done in /etc/cups/oopstops.convs, or in the oopstops filter itself?
<pitti> tkamppeter: I replied to the bug report, let's discuss it there (I'm sub'ed now)
<Riddell> pitti: yes they're hidden until someone approves it
<pitti> Riddell: ah, ok; thanks
<tkamppeter> pitti, are you sure that you have posted into bug 314018? You are subscribed there, but there is no comment from, you.
<ubottu> Launchpad bug 314018 in ghostscript "print bold in openoffice gives bad output" [High,In progress] https://launchpad.net/bugs/314018
<pitti> tkamppeter: weird -- seems it ate my comment
<pitti> tkamppeter: anyway, it was just what I asked here in IRC
<slytherin> cjwatson: do you have time for few more syncs?
<tkamppeter> pitti, I have answered to bug 314018.
<ubottu> Launchpad bug 314018 in ghostscript "print bold in openoffice gives bad output" [High,In progress] https://launchpad.net/bugs/314018
<pitti> tkamppeter: ah, thanks; well, if it's easier to implement in pstopdf, I'm okay with it; I looked at the diff, and it looked quite focussed
<tkamppeter> pitti, my only problem with it is that it breaks pxlmono/pxlcolor: http://bugs.ghostscript.com/show_bug.cgi?id=690025
<ubottu> bugs.ghostscript.com bug 690025 in Printer Driver "pxlmono driver prints some glyphs as squares when the input is PostScript generated by Ghostscript" [Major,New]
<pitti> tkamppeter: ah, right, I remember; if it actually breaks existing things, it doesn't qualify for an SRU
<pitti> if it's too hard to fix, we should probably just leave it alone in intrepid and just fix it properly in jaunyt
<pitti> it's not the worst bug in the world
<pitti> kirkland: do you think you can have ecryptfs-desktop-ui drafted by the end of the week? do you think it's a realistic target for jaunty?
<pitti> kirkland: (I wonder if I should put it as a jaunty goal)
<kirkland> pitti: hey
<pitti> happy new year, Dustin!
<kirkland> pitti: same to you!
<kirkland> pitti: hmm, i can draft the to-do doc by the end of the week
<kirkland> pitti: dendrobates- doesn't want me working on ecryptfs for this cycle, though
<kirkland> pitti: so what i have been doing on ecryptfs has mostly been above and beyond
<kirkland> pitti: normal job responsibilities
<kirkland> pitti: dendrobates- has sort of asked kees/jdstrand/mdeslaur (securtiy people) to do ecryptfs maintenance
<kirkland> pitti: and for the desktop team to do the ui aspects
<pitti> okay
<pitti> just asking because you are currently set as the drafter for this spec
<kirkland> pitti: right
<kirkland> pitti: i'll draft the design doc by end of week
<kirkland> pitti: and you can size it
<kirkland> pitti: fair?
<pitti> kirkland: do you think drafting the spec is something that this community person would do as well?
<pitti> kirkland: absolutely
<pitti> ah, Michael
<kirkland> pitti: michael rooney, you mean?
<pitti> right
<kirkland> pitti: perhaps, though I don't mind doing it, especially if it needs to be done asap.
<pitti> kirkland: if you could do the drafting (with the knowledge about what's possible to do), and I'll do some refinement (wrt. desktop integration), that would be great
<kirkland> pitti: sounds fine, i can do that
 * pitti hugs kirkland, thanks
 * kirkland high fives pitti o/*\o
<pitti> Riddell: I set some tentative priorities to the kubuntu specs; please feel free to fix (or yell at me to change it)
<Adri2000> elmo: well, you were right, there is at least one leak where one could easily put its own html/javascript/whatever code on the page that would be intrepreted :p
<Adri2000> elmo and Keybuk : I'm going to fix that (among other things) and push it to my bzr branch
<pitti> good night everyone
<jpds> gute nacht pitti.
<slytherin> Can any of the archive admins please process sync bugs 314470 314487 314505?
<ubottu> Launchpad bug 314470 in ubuntu "Please sync plexus-containers 1.0~beta2-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/314470
<aib> i am getting an assembler segfault during compile which suggests that the assembler uses a different version of libopcodes than which is being linked against.
<aib> and the version of libopcodes on my system is suspciously new. /usr/lib/libopcodes-2.18.93.20081009.so
<aib> http://gcc.gnu.org/ml/gcc-help/2009-01/msg00047.html
<aib> can someone run a test for me to see if this is ubuntu?
<aib> pecl install channel://pecl.php.net/svn-0.5.0   would do it
<aib> i was kicked from #ubuntu for asking someone to help me troubleshoot this
<aib> its potentially a serious issue - not appreciated
<jpds> aib: Try asking in #ubuntu-ops.
<ghostcube> hi guys can i may ask you if its planned to bring back the jackd audio output plugin to the xine-lib package
<Riddell> ghostcube: unlikely, xine is in main, jack is in universe
<ghostcube> hmm Riddell yeah but it i sneeded on kde4 to get jackd to the phonon backend sources to use it with the kde apps
<ghostcube> is there any repackaged version you know of ? with jackd support in ppa ?
<TheMuso> ghostcube: This is also an issue with other packages wanting to work with jack which exist in main. Until the source package of jack-audio-connectino-kit is in main, nothing in main can be built against it.
<TheMuso> gah jack-audio-connection-kit
<ghostcube> ui
<ghostcube> ok :( bye guys
<directhex> hm. what sort of times is dholbach about?
<jnjackins> I have an extra box lying around that I'd like to install jaunty on. Alpha 2 or daily build?
<Laney> kirkland: re: bug #243205, do you have any objections to me doing the new merge (0.9.0)?
<ubottu> Launchpad bug 243205 in mythtv-status "Merge mythtv-status 0.8.1-2 from Debian(Unstable)" [Undecided,Confirmed] https://launchpad.net/bugs/243205
<TheMuso> jnjackins: Probably start with alpha 2 and then upgrade.
<kirkland> Laney: you're welcome to do the merge, but i'd recommend using update-motd to publish that status
<kirkland> Laney: it's better suited to publish mythtv-status
<Laney> kirkland: I know nothing about that
<LaserJock> directhex: dholbach is usually around business hours (little earlier) European time
<kirkland> Laney: i've been meaning to talk to the upstream maintainer about it
<kirkland> Laney: if you'd like to talk to upstream about that, bonus points!
<Laney> do any other distros have update-motd?
<kirkland> Laney: not that i know of
<directhex> LaserJock, right, k. i've cornered meebey, and he's up for a developer week session
<blizzkid> kirkland: you here?
<kirkland> blizzkid: hi
<blizzkid> kirkland: hi, sorry to bother you, but I read your challenge, and I tried it, but every time I try to decrypt the file, I get the message "bad key". Is that because of a wrong passphrase? Or am I missing something else?
<kirkland> blizzkid: this isn't the proper place for this
<blizzkid> can I msg you?
<kirkland> blizzkid: sure
<maxb> I posted https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-December/006560.html, but there's been no reply. Should I just be patient? Repost to ubuntu-devel@? Somewhere else?
<james_w> maxb: the list of packages would have been useful
<james_w> https://launchpad.net/~ubuntu-cruft-busters
<james_w> you can subscribe that team to the bugs
<cjwatson> maxb: if you can write a script which generates a report based on Sources and Packages files from a local archive mirror, I'd be happy to integrate that into the archive team's pool of such reports
<cjwatson> then we would clean them up frequently
<maxb> aha. Now I know what to do with bugs to flag them for the attention of the appropriate people, I shall start filing them
<cjwatson> maxb: seriously I'd rather that we could get this into people.ubuntu.com/~ubuntu-archive and *not* file bugs
<cjwatson> bugs are a more heavyweight way to process this kind of thing than a one-page report that we can just run down
<cjwatson> they will take more ~ubuntu-archive effort and delay other things
<cjwatson> a one-page report would be so much better, as this is a real problem I know
<maxb> A fair proportion of the outdates are FTBFSes - those probably ought to be bugs, no?
<cjwatson> oh, sure, if there's actually a source change to be made
<maxb> Most of the rest are Packages-arch-specific related
<cjwatson> but if the problem is that the packages need to be removed, I would prefer that those were not filed as bugs
 * cjwatson -> bed
<maxb> Is there anything special I should know about making a script suitable for people.ubuntu.com/~ubuntu-archive ? Or should I just leave it set up to download the data from a mirror, and leave it up to the archive admins to tweak it to run on people.ubuntu.com/~ubuntu-archive ?
<TheMuso> crimsun: Yeah we could, would it not make things distorted etc for users who are not affected by  bug 275998
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/275998/+text)
#ubuntu-devel 2009-01-07
<crimsun> TheMuso: i'm thinking more along the lines of providing it as a non-default but available stanza so that users can choose it
<TheMuso> crimsun: Right, I have thought that since you proposed it.
<TheMuso> crimsun: Were you thinking of tweaking the original snippet in any way?
<TheMuso> If not, I can drop it in, and we may even be able to SRU it for intrepid.
<crimsun> TheMuso: yeah, need to investigate what max db should be set to (some "sane value", which means lots of feedback required)
<TheMuso> crimsun: Right.
<maxb> Is there any standard python parser for debian control files that's faster that debian_bundle.deb822 ?
<Adri2000> elmo: I updated my branch of merge-o-matic (and asked Scott to review). it would be cool if you could, with your canonical sysadmin hat on, take a look at it, as I've made changes to address the potential security issues. see #192972 and my latest comment there. thanks
<slangasek> asac: no ubufox upload yet for bug #308397?
<ubottu> Launchpad bug 308397 in ubufox "localizable general.useragent.locale pref shipped by ubufox breaks mozilla OS usage stats (ubuntu not counted)" [Critical,Fix committed] https://launchpad.net/bugs/308397
<slangasek> calc: there are a number of OOo bugs targeted for 8.04.2, but there haven't been any uploads, or indications in the bug logs that most of these are even in progress - should I simply untarget these?  it's certainly too late for a general-purpose OOo SRU to land in time for 8.04.2
<kirkland> Riddell: hi there, i pushed another revision of screen-profiles, this one with a COPYING file in the tarball
<calc> slangasek: yea just untarget them is fine
<slangasek> calc: ok.  are you planning to make time for an OOo SRU at some later time?
<calc> slangasek: perhaps, but i will be very busy at least for the next 1.5 months
 * slangasek nods
<calc> got a 3.0.1 release coming up to get into jaunty this month then sprint and a week in hamburg at sun
<dholbach> good morning
<kees> james_w: where's your ppamadison living?  I'm curious to see the lplib bits
<pitti> Good morning
<directhex> morning, dholbach. i've pencilled in meebey & myself for a session for developer week
<dholbach> directhex: rock and roll!
<dholbach> you guys are heroes!
<directhex> well poopy. looks like another total aircon failure in my machine room
<directhex> that's a couple of million quid of kit offline
<ion_> Hi all
<dholbach> there was a request for having a session about merging at Ubuntu Developer Week - who would like to give it? we still have a few open slots at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
<dholbach> also there was a request about python packaging and how to make your application translate-able
<directhex> pfft, python. who wants that when there's mono?
<directhex> also, aircon failures hurt
 * pitti slaps directhex
<pitti> python â¥! :-)
 * directhex hands pitti ironpython
<directhex> latest release needs mono 2.2 or some backports to 2.0.1 tho
<directhex> and this new ikvm package would be the smallest openjdk at our disposal, at ~35 meg on disk :p
<pitti> tjaalton, tseliot: do you know where the xrandr applet saves its settings?
<tseliot> pitti: in ~/.config
<pitti> tjaalton, tseliot: a friend of mine reports X crashes after he tries to log in, and I want him to reset this
<pitti> ah, monitors.xml?
<tseliot> pitti: yep
<tseliot> pitti: is it this bug? https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/314406
<ubottu> Launchpad bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed]
<StevenK> cjwatson: I find it odd that USUITE in tasksel/Makefile was still intrepid in bzr HEAD.
<pitti> tseliot: I don't know, it just started to happen recently
<pitti> tseliot: (intrepid)
<pitti> tseliot: I asked him some further questions
<tseliot> pitti: ok
<tseliot> pitti: let me know if you manage to get the error output so that I can try to fix it
<Keybuk> persia: where do fridge requests get mailed to now?
<StevenK> tjaalton: xf86-input-evtouch FTBFS, and is uninstallable. It looks like it needs source porting.
<tjaalton> StevenK: yes, and no news from upstream
<tjaalton> which reminds me.. pitti: there are a couple of patches for hal in fedora, making devices that declare input.touch to use evdev (which supports touchscreens now), for instance
<tjaalton> StevenK: hum, that should be easy to fix though
<StevenK> tjaalton: Fix it? :-)
<pitti> tjaalton: which we want, I assume?
<tjaalton> pitti: yep
<tjaalton> pitti: including the patch by mjg59 which he posted on u-d@ in October
<tjaalton> or was it u-d-d
<StevenK> ScottK: Do you think #312659 should be extended to kfreebsd-6 and -7, too?
<tjaalton> StevenK: looking :)
<pitti> tjaalton: http://cvs.fedoraproject.org/viewvc//devel/hal/hal-tablet-evdev.patch?view=markup and http://cvs.fedoraproject.org/viewvc//devel/hal/hal-tablet.patch?view=markup ?
<tjaalton> pitti: yes, and http://cvs.fedoraproject.org/viewvc/devel/hal/hal-joystick.patch?revision=1.2&view=markup
<StevenK> pitti: Do you also think I should kill kfreebsd-6 and -7 and blacklist them at the same time I kill -5?
<pitti> tjaalton: I think our joystick patch is better
<tjaalton> pitti: we have one?
<pitti> tjaalton: http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/annotate/head%3A/debian/patches/07_joystick_detection.patch
<tjaalton> pitti: yeah, saw that now, nice :)
<pitti> tjaalton: so, I'll just review all fedora ones and clean harvest then
 * pitti hugs dholbach for harverst
 * dholbach hugs pitti back
<tjaalton> pitti: great, thanks
<Keybuk> pitti: while you're in there, is there a patch for the udev rules location?
<pitti> Keybuk: not that I can see
<pitti> Keybuk: there is one for hal dbus permissions
<pitti> but debian just fixed that, too, I'll merge from them ASAP
<pitti> (but not today, I finally need to work on the apport retracers)
<Keybuk> ?!
<Keybuk> who shot Marco?
<Keybuk> or do you mean Debian just fixed the dbus permissions?
<pitti> Keybuk: so the idea is that udev itself and packages ship udev rules in /lib now, and /etc/udev/rules.d is solely for the admin's customizations?
<Keybuk> pitti: yes
<Keybuk> however my understanding was that this change was going into Debian "over Marco's dead body"
<pitti> Keybuk: right, they fixed dbus permissions, not udev rules path
<Keybuk> he's also refused to adopt standard upstream udev rules
<pitti> Keybuk: I know a few packages installing udev rules (libsane, libgphoto, etc.); so I guess best is to convert them to use dh_installudev, so that the change can go to debian?
<Keybuk> that's the easiest way
<Keybuk> though from a brief glance, neither libsane or libgphoto actually install udev rules now?
<pitti> I saw your change to that yesterday, so it seems it's supposed to DTRT
<pitti> Keybuk: ah, right. auto-ACL magic, I remember
<pitti> (our change is to *drop* udev rules installation)
<pitti> seems part of my brain is still in holiday mode...
<Keybuk> of course
<Keybuk> ironically
<Keybuk> the FDI becomes a udev rule later on anyway
<Keybuk> which is a significant part of the reason most distros are going to share a single set of common rules
<pitti> heh
<pitti> Keybuk: I hope hal-info will get an fdi2udev script, so that it remains useful for both current and older releases
<Keybuk> I'm honestly not sure how they intend to do that transition
<Keybuk> it's not as if fdi and udev rules are easily translatable
<pitti> well, but all of us distros have long-term releases, so we will need FDIs for the next couple of years still (unless we want to stop updating them)
<pitti> Keybuk: the format of the hal-info rules is relatively straightforward, though, so I guess for a subset it should be possible with some clever XSLT
<Keybuk> yeah
<pitti> many rules are simply "0x1234/0x5678 is a scanner" kind of thing
<Keybuk> you'll need hal-info as long as you have hal
<pitti> I guess an udev rule won't look much different
<pitti> e. g. the hotkey assignments are a different beast, of course
<pitti> since they need an actual backend which processes those
<Keybuk> *nods*
<Keybuk> I still don't think the whole DK thing is entirely well thought out
<pitti> bryce: good morning
<tjaalton> StevenK: bah, iz not that easy to fix I'm afraid
<StevenK> tjaalton: Oh?
<cjwatson> maxb: we can tweak it easily
<tjaalton> StevenK: uses some deprecated stuff
<tjaalton> StevenK: just dropping some obsolete includes and copying xf86OSMouse.h didn't help (like with -mouse)
<cjwatson> StevenK: I just hadn't run a real update since intrepid; fixed, thanks
<cjwatson> meh, now I remember why I didn't convert pcmciautils to dh_installudev - the upstream Makefile installs the rules file
 * cjwatson bodges
<cjwatson> dh_installudev is really only suitable for udev rules shipped as packaging modifications
<pitti> hm, remove it from *.install, and move debian/tmp/etc/udev/rules.d to *.udev won't work?
<pitti> s/move/put/
<Keybuk> pitti: that's a bit evil :_)
<pitti> Keybuk: why?
<cjwatson> pitti: sounds like more effort than reimplementing the necessary bits of dh_installudev!
<Keybuk> cjwatson: your other problem will be that dh_installudev will want to call your file 85-pcmciautils.rules
<Keybuk> so you'll have to deal with the rename in your maintainer scripts *anyway*
<cjwatson> aye
<pitti> cjwatson: sure, you can also change the dest path in debian/pcmciautils.install, but then you'd still need the postinst etc. bits; I don't think it's less effort that moving a line from .install to .udev...
<Keybuk> so for these kinds of packages, unless it's a trivial dhification, I'm just copying the preinst snippet in to remove unchanged rules and changing the debian/rules file to match the new path
<pitti> oh, wait
<cjwatson> pitti: I didn't say it was in .install
<pitti> .udev doesn't *list* the rules files, it *is* the rules file
<cjwatson> I said it was installed by the upstream Makefile
<pitti> so yeah, that won't work then
<cjwatson> plus what you said
<pitti> cjwatson: ah, you are installing directly into debian/pcmciautils/, not debian/tmp?
<cjwatson> yes
<cjwatson> Keybuk: BTW your debhelper modification doesn't seem to have a maintainer script abort path
<cjwatson> of course the original udev stuff didn't either
<pitti> hm, seems like dh_installudev could do with supporting debian/package.udev-files and treat that as file list
<Keybuk> cjwatson: a what?
<Keybuk> pitti: it's modelled after installinit, which doesn't have such a thing
<cjwatson> Keybuk: postrm abort-install or whatever
<pitti> Keybuk: right, I thought it would be like dh_install or dh_installman
<Keybuk> cjwatson: IME very few packages bother with it :-/
<cjwatson> Keybuk: actually I guess it isn't strictly necessary in this case anyway
<Keybuk> then again, it took me a very long time to get it right for udev and dpkg, so I'm not entirely surprised :p
<cjwatson> Keybuk: well, yes, but debhelper getting it right would go a long way :)
<cjwatson> Keybuk: I notice that udev still seds /var/lib/dpkg/status directly; I thought modern practice was to use dpkg-query
<Keybuk> modern practice requires you to know the package name :-/
<StevenK> cjwatson: It seems kubuntu-kde4 needs to get ripped out too
<cjwatson> Keybuk: yes, not hard :)
<pitti> StevenK: kfreebsd-{6,7}> yes, makes sense
<Keybuk> cjwatson: I'm not also convinced that the dpkg-query method is any better
<Keybuk> after all, it still has to sed the output of dpkg-query
<cjwatson> well, it's all based on the theoretical notion that the status file format might one day be changed; but dpkg-query's output could clearly be kept constant across such a change
<cjwatson> StevenK: I guess so
<cjwatson> StevenK: is the mobile branch ready for me to try?
<StevenK> cjwatson: Yeah, it's all commited.
<Keybuk> of course, the *hope* is that now udev rules are standardised between at least Ubuntu, Fedora/RH, SuSE and Gentoo - more upstreams will just ship them in their package
<RainCT> calc: ping
<RainCT> calc: Is bug #66933 really fixed? Because I have that problem on a clean Intrepid install...
<ubottu> Launchpad bug 66933 in openoffice.org "Recent Documents doesn't include files opened from within OOO" [Low,Fix released] https://launchpad.net/bugs/66933
<cjwatson> Keybuk: is there a standard dependency or breaks or whatever for packages shipping new-location udev rules?
<Keybuk> cjwatson: if they dependended on udev before, I've updated it
<Keybuk> but I haven't added one where one didn't exist before
<Keybuk> a lot of things ship udev rules without depending on udev
<Keybuk> which makes it complicated :p
<cjwatson> Keybuk: what should the version be - >> 136-1?
<cjwatson> er >=
<Keybuk> >= 136-1
<cjwatson> ok, pcmciautils done in my local tree then
<soc> hi
<Keybuk> debhelper is 7.0.17ubuntu2
<soc> i have patches against /var/lib/gconf/defaults/%gconf-tree.xml and /var/lib/gconf/debian/defaults/%gconf-tree.xml
<Keybuk> if you use cdbs, 0.4.38 has the dh_installudev call
<soc> whom should i send them?
<cjwatson> StevenK: tasksel updated - any problem with me uploading it now or do I need to wait?
<cjwatson> actually I guess it really ought to be now since the seeds have already been changed
<cjwatson> and I see that mobile-meta has been uploaded
<cjwatson> done
<StevenK> cjwatson: Thanks!
<StevenK> cjwatson: I'll upload livecd-rootfs tomorrow
<ScottK> StevenK: I think extending to the other FreeBSD sources is reasonable.  I only tripped over that one because of trying to get rid of old libdb versions.
<StevenK> ScottK: Yup
<soc> mhh weird
<soc> i tried to create a patch, but the diff is always double the size of the original/changed file
<soc> when i view the diff, it first removes _the whole_ original file and then adds _the whole_ new file, although just a few characters have been changed
<broonie> soc: line endings change, probably.
<soc> but i want to have a diff with just the lines which were changed, not the whole thing
<soc> how can i ingore them?
<soc> it's an xml file, btw
<broonie> You're almost certainly actually changing all the lines in the file.
<broonie> Possibly by changing the line endings, possibly some other way.
<soc> maybe tab to space?
<soc> does gedit make that automatically?
<broonie> Might, but I'd be a bit surprised.
<soc> i hate it ... always the latest step fails for me ...
<soc> :-/
<soc> last step
<soc> maybe something else is wrong... this is my line: diff -E --strip-trailing-cr -a --text -u /var/lib/gconf/debian.defaults/%gconf-tree.xml %gconf-tree.xml > debian.defaults-%gconf-tree.xml.diff
<ahasenack> I wanted to do a distribution upgrade test with some update candidate packages I have for distro+1, is there some option for do-release-upgrade to use an extra repository? I would place my packages in this extra repository
<ahasenack> for example, I want to test an upgrade from hardy to intrepid but I want it to consider my local repository as well
<cjwatson> soc: try viewing the diff in an editor configured to show special characters
<soc> which editor could i use for that?
<cjwatson> soc: well, I use vim but you may not be comfortable with that if you're used to gedit :) do some research
<soc> ok
<cjwatson> soc: or you could run it through cat -A
<soc> ok
<maswan> \sh: Hah. I finally managed to get tickets to karlsruhe. :)
<ahasenack> mvo: hi, is there a way for me to supply an extra apt repository for consideration by do-release-upgrade during a distro upgrade?
<\sh> maswan: when? :)
<maswan> \sh: 13th to early morning at the 16th
<maswan> \sh: No plans for the 13th so far, might be meeting dinners etc at the other days though.
<\sh> maswan: 13th sounds great :)
<apw> so who owns the debian-installer in ubuntu
<cjwatson> apw: *wave*
<apw> cjwatson, heh is there anything you don't own?
<mvo> ahasenack: not easily unfortuntaely. what is the use-case?
<cjwatson> apw: yes :-)
<cjwatson> (fortunately)
<maswan> \sh: see you then, then. :)
<ahasenack> mvo: updating some distro+1 packages, and checking that that distro upgrade from distro to distro+1 doesn't break. I would need do-release-upgrade to consider this other repository with the test packages
<cjwatson> apw: something up that I can help with?
<apw> cjwatson, Hobbsee reported that a dist-upgrade installed a lilo on her grub machine, looking at it it seems that the 32 bit intrepid installs are installing both grub and lilo, but 64 bit is only installing grub ... the initial thought was our recommends were causing it, but not as 32bit and 64 bit differ
<cjwatson> apw: well, whether lilo or grub is installed depends on the installation parameters - for example if /boot is on LVM then lilo's needed
<apw> so i am wondering how d-i decides which to install, and why it might install both?  our kernel recommends do mention both but as i say 64bit cd's don't seem to install lilo but 32bit do
<mvo> ahasenack: there is a good way to test this via the noninteractive upgrade tester in do-release-upgrade. its not exactly greatly documented, but this is probably a good opportunity to change that :)
<cjwatson> I'm very surprised about both being installed, and would like to see the installer log
<cjwatson> (/var/log/installer/syslog)
<ahasenack> mvo: how can I try it?
<mvo> ahasenack: how urgent is it? i.e. can we talk about it a little bit later (~2h)?
<ahasenack> mvo: sure
<apw> my 32bit sample is on a single normal ext3 disk and is using the grub by default
<mvo> ahasenack: its in the update-manager bzr branch
<apw> cjwatson, typically i am remote from that laptop today ... i will get that off and to you
<cjwatson> apw: Recommends are ignored while installing the kernel during initial installation, so it won't be that
<apw> Hobbsee, do you have your 32bit lilo/grub machine to hand?  If so could you get the /var/log/installer/syslog off it and shove it into bug #314004
<ubottu> Launchpad bug 314004 in linux "Lilo gets installed on dist-upgrades, due to the kernel image recommending it. Is this intentional?" [Medium,In progress] https://launchpad.net/bugs/314004
<cjwatson> apw: http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/annotate/head%3A/debian/isinstallable is what controls whether grub or lilo is installed
<cjwatson> apw: if that script exits zero, then grub's used, otherwise lilo
<cjwatson> (approximately)
<apw> thanks, to basically its as expected, only one should be installed
<cjwatson> apw: but that doesn't influence dist-upgrades
<apw> from memory it definatly put both on in the same original install block
<cjwatson> that's incredibly weird
<apw> no i assume Hobbsee got the update just because there is a lilo update in jaunty and it was installed
<cjwatson> I'd be astonished if the discrepancy were really due to i386 vs. amd64
<cjwatson> I think it's more likely to be something more subtle
<Hobbsee> apw: i got it installed at the point where I did the dist-upgrade.
<apw> cjwatson, if Hobbsee isn't able to get her logs, i will try and be where the other laptop is and get it off
<cjwatson> the thing is that the kernel recommends lilo | grub
<cjwatson> not both - either should satisfy it
<Hobbsee> apw: should be http://pastebin.com/f81055d5
<cjwatson> now, I do think the kernel should recommend grub | lilo instead, switching the order
<cjwatson> but that's cosmetic from the point of view of this bug
<directhex> elilo!
<apw> cjwatson, can i tell if there was a lilo update in jaunty
<cjwatson> apw: shouldn't be relevant
<cjwatson> apw: rmadison lilo
<Hobbsee> (i didn't check whether it had installed lilo in the original install of intrepid)
<apw> Hobbsee, i amhappy it installed lilo in the update.  just want to know if it could also have been installed before dist-upgrade and was simply upgraded
<Hobbsee> apw: could have been
<apw> i think pgraner said his 32bit install had both too
<cjwatson> apw: simply changing the version of lilo in jaunty wouldn't cause it to be magically installed
<apw> so its something more than just one or two of us
<apw> cjwatson, right, but it changing would make it upgrade at dist-upgrade which might explain why it was noticed by Hobbsee
<cjwatson> I think this is related to installing with desktop vs. alternate/server
<apw> and yes it is differnt
<apw>       lilo | 1:22.8-4ubuntu1 |      intrepid | source, amd64, i386
<apw>       lilo | 1:22.8-7ubuntu1 |        jaunty | source, amd64, i386
<apw> so ... if she had had the same as me, that both were on, then lilo would be downloaded and installed as part of an update
<Hobbsee> installer log added to bug.
<apw> Hobbsee, perfect
<cjwatson> this is interesting, lilo is installed as part of desktop
<cjwatson> that would explain why ubiquity isn't removing it
<cjwatson> mvo: update-manager might have to arrange to remove lilo :-(
<cjwatson> (if unused ...)
<Hobbsee> Setting up lilo (1:22.8-4ubuntu1) ...
<Hobbsee> right, so i did get it in the intrepid version.
<cjwatson> your initial install was intrepid desktop
<apw> so can we tell from the log what slurped it in?
<mvo> cjwatson: sure, that can be arranged
<cjwatson> not from the log but I can tell in other ways, please wait
<pgraner> apw: it installed it on a Intrepid->Jaunty upgrade
<cjwatson> pgraner: but it was already installed on intrepid, I'm fairly certain#
<apw> pgraner, what he said
<cjwatson> therefore focusing on the upgrade is an error
<apw> there was a new one in jaunty so if you had it already you get eh new one, even though you don't want it
<pgraner> cjwatson: it might have been, I never noticed it. In fact the only way I noticed was when I got the "Configure LILO" screen from apt-get
<cjwatson> oh goodness, yes, you would
<cjwatson> due to the large-memory thing
<cjwatson> yargh, lovely bug that's now enshrined on lots of systems
<cjwatson> apw: I bet your intrepid-installed system without lilo was installed using the text-mode installer, and your system with lilo was installed using the desktop installer
<cjwatson> apw: can you confirm?
<cjwatson> so it's true that the order of the kernel recommends is what caused this, but really, accident ...
<apw> cjwatson, i can confirm the 'broken' one was installed virgin from a desktop CD image
<apw> the working one  i am struggling to remember if it was hardy CD installed and updated or reinstalled from the intrepid 64 bit CD
<cjwatson> let me give you a potted summary of what happened, then
<apw> can i tell at all
<cjwatson> yes, /var/log/installer/syslog will indicate, if only from the kernel version
<cjwatson> in intrepid, we enabled recommends by default; this had some speedbumps but largely appeared to be working OK
<apw> Oct 21 12:47:25 ubuntu kernel: Inspecting /boot/System.map-2.6.24-19-generic
<apw> so hardy then upgraded me thinks
<cjwatson> (therefore any installs from earlier than intrepid are entirely unaffected by this)
<cjwatson> the alternate/server CD (d-i) installs as I described above, by explicitly choosing whether to install grub or lilo depending on installation parameters; no problem there
<cjwatson> however, the desktop installer works quite differently
<cjwatson> we put a "live filesystem" onto the desktop CD, a preinstalled filesystem image with lots of packages on it that's then copied to the target system
<cjwatson> obviously, there are some things on this image that shouldn't end up on the target system, such as the installer itself
<cjwatson> so we copy the filesystem image file-by-file, and then remove unwanted packages using apt (this is still a lot quicker than installing them all from scratch, and allows us to fit an installable live system onto a single CD)
<cjwatson> the set of packages we remove is computed by taking the set-difference between a "desktop install" and the full live filesystem package list, plus one or two other tweaks
<cjwatson> (things like language packs, removing unused kernels if there's more than one available, etc.)
<apw> cjwatson, a sneak solution indeed
<cjwatson> for various reasons, the script that builds the live filesystem (in the livecd-rootfs package) installs the kernel before it says "right, that's it, what I've got now is a desktop install"
<cjwatson> and, due to the kernel's Recommends, the bootloader (in this case lilo) is considered as part of the desktop install, and not removed by the installer
<cjwatson> the installer notices that it needs grub, and therefore arranges for it to stay installed as well
<cjwatson> and voila, two bootloaders
<cjwatson> I recommend three fixes for this, and will update the bug accordingly:
<cjwatson>  1) ubiquity should arrange to remove all bootloaders except for the one it's installing
<cjwatson>  2) linux should switch the order of its recommends to suit the modern age (not required given 1, but probably sensible anyway, and I think there may well be other bugs about this)
<cjwatson>  3) update-manager should clean up this mess on upgrade
<cjwatson> (done)
<apw> ok ... so i can handle the linux(2) side under the linux task
<cjwatson> yep
<apw> will you make tasks for the rest?
<cjwatson> yes, already have
<apw> cool.  will get on it.  does this need doing for intrepid, or is it too late to matter
<apw> (we are going to make new CD's I assume for the intrepid update?)
<cjwatson> too late for intrepid, and we weren't planning new CDs
<cjwatson> we normally only do new CDs for point releases, which are normally only for LTSes
<apw> ok so then i'll just spin the change on jaunty
<cjwatson> and they're a lot of work
<cjwatson> yeah, jaunty will be fine
<apw> heh, yeah i did notice a lot of moaning when they were being spun last time
<cjwatson> Hobbsee: thanks for spotting this
<Hobbsee> cjwatson: glad you can fix it :)
<mvo> cjwatson: is there a bugnumber for this? I can do the work in u-m, just want to know a bit more about the problem (I can read scrollback if it was discussed here of course)
<apw> mvo, bug #314004
<ubottu> Launchpad bug 314004 in linux "Lilo gets installed on dist-upgrades, due to the kernel image recommending it. Is this intentional?" [Medium,In progress] https://launchpad.net/bugs/314004
<apw> cjwatson, thanks for the insight into d-i's guts
<cjwatson> apw: ubiquity's guts in this case
<cjwatson> (you're welcome)
<cjwatson> fixed for next upload, pending testing
<apw> cjwatson, kernel patch out for review
<Keybuk> cjwatson: heh, I spotted it the other day too but hadn't got around to mentioning it yet
<Keybuk> james_w: around?
<james_w> hey Keybuk
<Keybuk> bzr build-deb appears to be ignoring my .bzr-builddeb/local.conf :-/
<Keybuk> quest ubuntu% cat .bzr-builddeb/local.conf
<Keybuk> [BUILDDEB]
<Keybuk> source-builder = dpkg-buildpackage -rfakeroot -uc -us -S -i'(?:/|^)(?:test|\.gitignore)(?:/|$)'
<Keybuk> yet, when I do bzr bd -S I get lots of
<Keybuk> dpkg-source: error: cannot represent change to udev-136/test/sys/devices/virtual/block/loop5/subsystem:
<Keybuk> followed by (eventually)
<Keybuk> dpkg-source: unrepresentable changes to source
<Keybuk> dpkg-buildpackage: failure: dpkg-source -b udev-136 gave error exit status 1
<james_w> Keybuk: could you pastebin the full output please?
<james_w> Keybuk: is the file versioned?
<Keybuk> no
<Keybuk> the full output is ~4 GB
<james_w> ok, the top few lines should do
<persia> Keybuk, ubuntu-news-team@lists.ubuntu.com, I think.
<Keybuk> the files its complaining about are versioned, but not in the tarball
<james_w> sorry, is .bzr-builddeb/local.conf versioned?
<Keybuk> http://paste.ubuntu.com/101665/
<Keybuk> james_w: yes
<james_w> Keybuk: ah, it shouldn't be, it's local overrides
<Keybuk> what file do I put that line in instead?
<james_w> there is no way to set per-package overrides yet currently unfortunately
<james_w> you can either move that file to ~/.bazaar/builddeb.conf
<Keybuk> that means nobody else will be able to build a udev package from bzr other than me though
<Keybuk> no?
<Keybuk> which kinda defeats the object :p
<james_w> or unversion it ("bzr rm --keep")
<james_w> don't put it in the local file then
<james_w> bzr mv .bzr-builddeb/local.conf .bzr-builddeb/global.conf
<james_w> er, default.conf sorry
<Keybuk> Building the package in ../build-area/udev-136, using dpkg-buildpackage -rfakeroot -uc -us -S
<Keybuk> no change
<Keybuk> still ignores it
<james_w> python -c "from bzrlib.workingtree import WorkingTree; print WorkingTree.open_containing('.')[0].path2id('.bzr-builddeb/default.conf')"
<james_w> what does that print?
<Keybuk> local.conf-20081222123037-mhcrh47mqkmhxuj7-2
<lool> james_w: Re debbug #426419 > no patch; did we actually patch this?
<Keybuk> tkamppeter: so I'm looking at hplip's udev rules ... and I'd like to take your crack pipe away
<Keybuk> heh
<Keybuk> in fact
<Keybuk> I can just delete the rules file entirely
<Keybuk> because all it does is put things into the scanner group
<Keybuk> which we, err, don't have
<liw> Keybuk, hmm, I have it
<ogra> tills crack pipe ?
<liw> gid 105, so probably manually created
<Keybuk> liw: it goes away in jaunty
<liw> Keybuk, ah
<james_w> Keybuk: ah, I see the issue. builder commands can't be specified in those files. The rationale was that it was arbitrary code execution, but that doesn't seem like a good one.
<Keybuk> james_w: it should be at least possible to specify the ignore string?
<james_w> Keybuk: yeah, but does everyone's builder command accept that option?
<pitti> liw: it isn't  necessary to be in the scanner group since hardy any more (replaced by automatic ACLs); but of course on upgrades your user isn't removed from it
<james_w> lool: seems we didn't
<james_w> lool: http://patches.ubuntu.com/by-release/ubuntu/a/acpid/acpid_1.0.4-5ubuntu6.patch.bz2 is the patch referred to in the initial debian bug report
<Keybuk> james_w: another option would be files you could not export across to the build area?
<james_w> lool: well, we patched acpid to check for the file, but didn't patch it to fix the ubuntu bug I referenced
<james_w> Keybuk: that could work.
<james_w> I want to do something about the builder command handling anyway, as it's quite irritating, but I'm not sure what the best approach to take is
<Keybuk> cjwatson: you remember how we couldn't figure out why hwclock wasn't working properly?
<Keybuk> well, I just looked at the udev rules
<Keybuk> KERNEL=="rtc", ...
<ScottK> slangasek: Is there any chance of us getting openldap off of db 4.2 in this cycle?  4.3 just got removed (thanks StevenK) and 4.4 is close behind.  I think 4.2 is doable if slapd can move to a later db.
<Keybuk> yeeeeah, that won't work
<slytherin> Can any archive admin please process these bugs - 314470 314487 314505?
<cjwatson> Keybuk: ah, heh
<cjwatson> good catch
<Keybuk> cjwatson: tbh, I should probably just read through all of the hwclock code, including that in the kernel
<Keybuk> and do it from scratch again
<Keybuk> since last time we briefly looked we found that must of it wasn't necessary anymore
<Keybuk> (most of our changes esp.)
<cjwatson> Keybuk: failing all else we can do it at the sprint
<cjwatson> slytherin: done. (no need to ask me about binaries later, we'll do them)
<slytherin> cjwatson: thanks. :-)
<StevenK> If that's removal, I'm guessing NBS is going to be enormous once it regens, and I'll take care of it
<cjwatson> no, syncs
<dholbach> would somebody like to give a session about backtraces and debugging stuff at Ubuntu Developer Week?
<dholbach> we still have some open slots available: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
<Keybuk> cjwatson: ah, you've never experienced the Berlin nightlife ;)
<Keybuk> I'm not expecting this to be a productive sprint <g>
<cjwatson> Keybuk: as far as I'm concerned, Berlin is my chance to spend a week getting uninterrupted nights' sleep; nightlife is not high on my agenda
<Keybuk> cjwatson: :o)
<slytherin> cjwatson: how come the bugs didn't get marked as fix released? Or do you need to do that manually?
<slytherin> oops, I spoke too earley.
<slytherin> early
<cjwatson> slytherin: indeed ...
<cjwatson> (and yes, I have to do that by hand, but I did so before saying anything to you)
<cjwatson> we have a script that deals with bug closures but it doesn't work for requests of syncs of new packages
<slytherin> hmm
<slytherin> cjwatson: do you usually handle 'move to universe' kind of bugs?
<cjwatson> slytherin: ~ubuntu-archive does, I largely do archive work when I'm too tired to program properly :-)
<cjwatson> latching onto me for routine maintenance is a mistake
<slytherin> ok.
<cjwatson> we process the queue. Unless it's super-urgent, there's no need to poke explicitly
<slytherin> ok. it is not super urgent.
<Keybuk> cjwatson: talking of which, since it's generally impolite to shove your own uploads through NEW ... :p
<cjwatson> Keybuk: damn, and I was enjoying the way my jaunty system is largely working at the moment
<Keybuk> I have _tested_ this, you know ;)
<cjwatson> Keybuk: not that it hugely matters, but please set the priorities of the -dev packages to optional for your next upload
<Keybuk> cjwatson: pushed for next tiome
<pitti> Keybuk: so you *tested* that it'll break everyone's system :)
<Keybuk> pitti: :o)
<cjwatson> Keybuk: I think you broke udev-udeb
<Keybuk> cjwatson: oh?
<cjwatson> Keybuk: doesn't it need the libraries?
<Keybuk> shouldn't do, it's built -static
<cjwatson> ah, ok
<cjwatson> Keybuk: what links against libudev0? udev doesn't seem to depend on it
<Keybuk> cjwatson: DeviceKit, HAL, etc.
<cjwatson> ah, but not udev itself?
<Keybuk> right
<cjwatson> ok
<Keybuk> it's built-in to udev itself
<Keybuk> I'm not entirely, honestly, sure *why*
<cjwatson> I'm deliberately going to upload d-i before this so that I have a working d-i to test other things with, mind you :)
<slytherin> cjwatson: do you mind if I bug you for few more syncs after I go home. That will be about 2 hours from now.
<cjwatson> slytherin: don't bother, I'll be away by then
<cjwatson> slytherin: please don't bug me personally
<slytherin> cjwatson: ok.
<slytherin> cjwatson: I hope you will clear all the binaries from new queue before you leave. :-)
<cjwatson> slytherin: not necessarily.
<cjwatson> Keybuk: accepted
<tkamppeter> Keybuk, what do you mean with "and I'd like to take your crack pipe away"?
<Keybuk> tkamppeter: welll
<Keybuk> on upgrade you
<cjwatson> slytherin: (although as it happens I believe that I have done; but I don't really appreciate being treated this way)
<Keybuk> 1) rename the udev rules from a correct name to a bizarre one
<Keybuk> 2) replace the old rules with a dummy file instead of nothing
<Keybuk> 3) install a new dummy file with a name that appears to have never been used
<slytherin> cjwatson: Sorry, didn't mean to.
<cjwatson> I'm doing archive work because it seems to be a bit backed up and because I'm feeling helpful; that doesn't mean that I'm going to rearrange my life to be around at awkward-for-me hours so that non-urgent things can be done today rather than tomorrow, or that I want everyone to pile on and ask me to do such-and-such
<slytherin> cjwatson: I understand.
<cjwatson> thank you
<Keybuk> pitti: I'm not going insane, right?
<Keybuk> neither libgphoto2-2 or libsane actually ship udev rules anymore?
<soc> what do you think of that dpi-widget? the thing looks like crap at the moment, but i hopt the intent gets clear.... http://ochsenreither.de/screenshots/dpi-widget.png
<pitti> Keybuk: confirmed; I dropped them in hardy
<Keybuk> pitti: mind if I drop the /etc/udev/rules.d directory from the packages then?
<Keybuk> cause it keep showing up in Contents.gz/dpkg -S :p
<pitti> Keybuk: they still ship the directory /etc/udev/rules.d
<Keybuk> yeah they do
<Keybuk> mind if I remove that? :)
<pitti> no, not at all
<pitti> probably just a leftover from package.dirs
<Keybuk> it is
<Keybuk> thanks
<pitti> (the misbehaviour of using dh_installdirs together with dh_install is so widespread :( )
<seb128> pitti: did you read about guest session freezing the computer on jaunty?
<cjwatson> it can be reasonable if you're installing other files by hand too
<Keybuk> misbehaviour?
<cjwatson> dh_install creates directories for itself, so dh_installdirs is often unnecessary when you're using it
<cjwatson> indeed pretty much all debhelper commands create directories for themselves
<cjwatson> dh_installdirs is just a shorthand for when you need a manual mkdir for some other reason
<pitti> Keybuk: yes, I often see .dirs containing "usr/bin" and "usr/lib", for example
<cjwatson> that's probably due to dh-make
<pitti> which is generated by upstream make install anyway
<pitti> right
<Keybuk> pitti: ugh, gphoto FTBFS :-/
<pitti> new kernel headers?
<Keybuk> libtoolness
<pitti> yay
<Keybuk> nothing worse than touching a package and having it blow up in a completely unrelated way that you happen to be the best person to fix
<pitti> *chuckle*
<Keybuk> cjwatson: I spotted a udev bug you didn't ;)  libudev0.shlibs was wrong
<cjwatson> *grin* I just looked at the contents TBH
<slangasek> ScottK: moving openldap off 4.2 requires moving to openldap 2.4.12 or later; I don't have any objections to doing this, but the impetus isn't going to come from Debian, which is frozen at 2.4.11 for lenny
<ScottK> slangasek: OK.  It'd be handy, but I suspect it's a fiddly enough update that someone familiar with the package ought to do it.  I think it's the only real blocker for 4.2 removal.
<slangasek> Is sasl migrated?  I remember there was resistance in Debian to getting sasl moved off of db 4.2 as well
<ScottK> Yes.  We did that one.
<ScottK> Debian did too.
 * slangasek nods
<ScottK> I think cyrus imap still needs to be done.
<ScottK> vorian is looking into the other 4.2 rdepends.
<slangasek> ArneGoetje: hardy langpacks don't appear to be updated yet?
<ArneGoetje> slangasek: the tarball is not ready yet...
<ArneGoetje> slangasek: rosetta is a bit slow with exporting.
<slangasek> ArneGoetje: ok. ETA?
<ArneGoetje> slangasek: dunno. anytime soon.
<slangasek> ArneGoetje: is there somewhere I can see the status of the tarball export (i.e., whether it's done or not), and how soon do you think I should escalate to the LP folks if it's not done (i.e., when do we conclude that the export is broken instead of just slow)?
<ArneGoetje> slangasek: https://translations.edge.launchpad.net/ubuntu/hardy/+language-packs
<ArneGoetje> slangasek: when the tarball is ready it will be top of the list and say "Full Export"
<slangasek> ArneGoetje: ok
<ArneGoetje> slangasek: but for us non-LP folks it's impossible to say what the export script is doing.
<ArneGoetje> slangasek: jtv mentioned to me that it might take until Friday morning UTC... I just hope it won't take that long.
<calc> RainCT: hmm looking at it
<calc> RainCT: i believe there a few issues here
<slangasek> ArneGoetje: hmm, that's rather longer than I'm comfortable with; I'll poke to see if there's some way it could possibly be made faster for us
<calc> RainCT: if you open the file via the gnome file dialog inside OOo it should add it to the menu (last i checked anyway)
<calc> RainCT: if you open it via OOo recent documents menu it doesn't (iirc)
<calc> RainCT: and it doesn't resort properly which is another bug report
<ArneGoetje> slangasek: good luck
<asac> slangasek: an update on ubufox. upstream says we get counted. so its not as bad as it seems and can wait until after .2 i think; when is release date for that?
<tjaalton> hum, why does initscripts ship both /etc/network/if-up.d/mountnfs{,.orig}?
<tjaalton> at least on hardy
<asac> tjaalton: without looking i would say that its a merge bug ;)
<slangasek> asac: release date for .2 is Jan 22; I'll unmilestone the bug then, thanks
<asac> cheers
<mkrufky> from within a gnome-based app, how can i tell if we are about to suspend, or have just resumed?
<tjaalton> asac: possibly
<tjaalton> asac: introduced in 2.86.ds1-14.1ubuntu26 (gutsy) :/
<Keybuk> cjwatson: you're doing pcmciautils, right?
<cjwatson> yeah
<cjwatson> probably won't upload 'til tomorrow though, sorry
<Keybuk> np
<Keybuk> I wonder how much of that is needed
<Keybuk> (the upstream diff of the rules, I mean)
<Keybuk> if it's all valid, it should be just pushed upstream, including the move to /lib/udev/rules.d
<Keybuk> oh, drop the -Q from modprobe
<cjwatson> -Q no longer needed?
<Keybuk> right
<cjwatson> upstream already released pcmciautils 015 that I think included most of our changes, but I haven't got round to packaging it
<Keybuk> ahh, k
<cjwatson> well, I did in Debian but haven't merged, oops :)
<cjwatson> still a few Makefile changes actually, I should do something about that
<slangasek> mkrufky: I'm not sure you can; why do you need to?
<mkrufky> slangasek: for instance.... if totem is streaming while the user suspend's his pc, totem needs to stop / start the stream upon resume, in order for it to continue working
<slangasek> mkrufky: "streaming" being a network stream?
<mkrufky> dvb-t / atsc
<mkrufky> digital television
<slangasek> hmm
<mkrufky> the device loses power when in suspend
<slangasek> typically this is handled via suspend/resume hooks for the hardware, not from the GUI
<mkrufky> the device driver reinitializes the device upon resume
<mkrufky> the driver itself does the right thing already
<mkrufky> but the app needs to steer the ship
<slangasek> right; I think the better abstraction is if totem can detect that the device driver has been reinitialized?
<slangasek> since that could in theory happen outside of suspend/resume, and it would be nice if totem were robust against it?
<mkrufky> hmm
<mkrufky> there's currently no way for userspace to determine that fact
<mkrufky> ...but i thought that dbus would provide some messaging system that would broadcast (we just resumed) to all applications
<mkrufky> am i wrong?
<slangasek> I don't know, really
<mkrufky> :-/ okay
<slangasek> you could check with dbus-monitor
<mkrufky> ...or even if ubuntu has a script that is always run upon resume, that would be good enough
<slangasek> but I can't really see too many other use cases for this, the ideal is that apps never need to know a suspend/resume happened
<mkrufky> for the problem that i need to solve right now, even just killing totem after resume from suspend would suffice as a fix
<mkrufky> television applications need to know
<slangasek> oh, sure, you can put any manner of hook in on resume via pm-utils
<ScottK> I know (from doing it by accident) that if I suspend in the middle of compiling a package, on resume dpkg will DTRT and keep right on building.
<slangasek> mkrufky: c.f. /usr/lib/pm-utils/sleep.d
<mkrufky> slangasek: " c.f. "  ?
<slangasek> mkrufky: hmm, properly "cf." - "compare"
<TheMuso> ScottK: I've had a similar experience with a VM in KVM.
<mkrufky> hmm... interesting slangasek -- thanks
<TheMuso> hrm I think dmraid's raid5 implementation is broken somewhat.
<sebner> jdong: siretart: ping, the video runs in a own window in vlc. We had this bug already though
<pitti> good night everyone
 * TheMuso goes to test raid5 for dmraid on real hardware to see if it makes any difference.
<Picklesworth> evand: Any news on that Ubiquity Slideshow thing? I remember you were hoping to get that moving, so I should contribute to the right place :)
<evand> Picklesworth: there's a specification for it (https://wiki.ubuntu.com/UbiquitySlideshow).  I'm currently trying to coordinate efforts between teams, but got caught up in holiday.  Expect progress on that front soon :)
<evand> The hardest part is going to be getting the artwork / text done and signed off by the respective teams.
<Picklesworth> I have been tinkering with SVGs. I think I have a decent path figured out to localizing them, although it'll have to be a tad unusual
<evand> Pango should be able to do the job nicely.  I'm not too concerned with the underlying image format, assuming we can render it or convert it to something we can render.
<Picklesworth> The reason I'm tinkering with SVGs is because I bet artists would like those. Could make it more encouraging to contribute to :) It also means people can be somewhat creative with text (within reason) and it'll still be translatable
<ogra> note that the string length varies massively between localizations
<Picklesworth> Alas, that's true :(
<ogra> SVG is localizable since ages (its just XML in the end) but if you change strings inside an image it might just break because the strings get to long
<evand> indeed, thus Pango.  Give it a box and tell it to fit the text in that.  Though we'd still put restrictions on number of sentences.
<evand> So we don't get ridiculously small text.
<Picklesworth> I guess the trick, then, is finding the right way to describe things visually since the text would have to be used mainly as captions
<cjwatson> yeah, I think anything more than a single sentence would probably be too much in many cases
<evand> Pretty much.  I defer to the art and creative teams for that one though :)
 * TheMuso sighs. The latest upstream release of dmraid cannot recognise the metadata of my gigabyte board/intel controller properly, yet the version in intrepid does. :S
<TheMuso> We have one big piece of crap on our hands folks, at least IMO. :S
<directhex> punishment for buying gigabyte!
<TheMuso> directhex: Not quite, if I were to explain exactly what dmraid was, I would probably destroy everything within reach right now.
<TheMuso> THis has nothing to do with the board itself, and everything to do with bad upstraem regression testing.
<TheMuso> particularly since Intel were involved with some of the coding for dmraid.
<directhex> i thought it was mostly redhat people behind dmraid
<TheMuso> directhex: Yes, but intel have been helping with supporting their own metadata format. Obviously that hasn't worked too well.
<directhex> TheMuso, is it a specific series of ICH*R which doesn't work anymore?
<TheMuso> directhex: I don't know. I have two gigabyte boards here that have intel dmraid BIOSes, but one is my file server, and all of its disks are part of Linux Raid, which is somewhat more sane, and I'd rather not take that offline.
<TheMuso> Both boards have different ICH revisions as well.
<TheMuso> But I doubt that the metadata is that different between them.
<directhex> i've never trusted dmraid. always seen it as more of a concession to windows dual-booters with raid0
<TheMuso> directhex: I don't trust it, and don't like it either. However I am the one who is currently maintaining it, since I had the hardware to test Ubuntu integration on it, prior to dmraid itself being able to write metadata.
<directhex> oh. lucky you :|
<TheMuso> directhex: Damn right. I'd love to hand it off to someone who really cares, but I don't see that happening any time soon.
<ScottK> Especially now that you've announced to everyone how painful taking over would be.
<jcastro> directhex: see pm please!
<TheMuso> ScottK: heh true.
<directhex> jcastro, which PM?
<TheMuso> ScottK: Even if I hadn't, I would tell any prospective maintainers that it would be painful anyway, which is why I say someone who really cares.
<jcastro> the one I sent you ~45 minutes ago?
<directhex> oh, let me check my logs
<soren> asac: I have a couple of packages that provide extensions for Mozilla, specifically the kind that handles some new content types... How do I get firefox to know about these if a user accesses a page that embeds some of these kinds of objects?
<soren> There's something about some Npp-* headers or some such, right?
<cjwatson> Keybuk: http://ext4.wiki.kernel.org/index.php/Ext4_Howto - has the vol_id/blkid debate there been resolved? if so it would be nice if somebody could be persuaded to update the wiki
<Keybuk> cjwatson: Ted has declined to change the text on the wiki, I forwarded the results of my efforts to mdz to follow-up on
<cjwatson> ah
<soren> asac: I think I've worked it out. Who assigns the appliction guid's?
<walters> soren: you just generate one, there's no assignment
<ScottK> TheMuso: Of course you would.  I was kidding.
<TheMuso> ScottK: heh right.
<superm1> siretart, ping.  I was wondering what's going to be the plans for vdpau en ffmpeg whenever the new version eventually floats into ubuntu?  Since it lives in restricted likely, is it not going to be enableable?
<TheMuso> You know there is something wrong with a piece of software that writes directly to your hard disk, when it manages to make your BIOS choak when attempting to boot your system.
<siretart> superm1: I haven't updated ffmpeg yet, but I plan to do so this weekend or next week. Do you have already experience with the vdpau headers? which package ships them?
<sebner> siretart: \o/
<sebner> superm1: does this new nvidia driver works with the new xorg?
<soren> walters: Lovely... What's it used for?
<walters> soren: to uniquely identify extensions
<siretart> does vdpau actually work in jaunty already?
<walters> soren: if you don't like uuids you can also name them like email addresses
<soren> walters: Hmm... Ok. Does it uniquely define the particular version as well?
<walters> soren: no
<walters> soren: this is all documented fairly well here: https://developer.mozilla.org/en/Extensions
<soren> walters: Ah, thanks.
<soren> walters: Do you happen to know if adding the XB-Npp-* headers is all that's needed for firefox to pick them up? I mean... Is there something, somewhere that uses that information to build a mapping from mime-types to package names and the provide that to firefox?
<walters> soren: no idea what XB-Npp headers are; as for mime types, see: http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html
<slangasek> are those what ubufox uses, or are those the fields that Debian implemented independently?
<slangasek> soren: I think you want mvo for answers, here
<soren> mvo? Not asac?
<slangasek> mm, possibly asac :)
<soren> walters: They're headers we apparantly add to our packages that provide plugins for mozilla.
<slangasek> they're also present in Debian
<slangasek> so it's possible that was implemented independently of ubufox
<soren> I think, maybe, ubufox provides the magic that goes to look up the mime-type somewhere.
<soren> ...and then gets a list of plugins back, which is then used to present to the user.
<soren> I could be completely wrong, though.
<soren> It's been known to happen.
<soren> No, really.
<slangasek> anyway, I don't know whether ubufox is using the XB-Npp-* headers, but if anything does in Ubuntu, that's it
<slangasek> if ubufox doesn't use them, they're entirely orthogonal
<slangasek> well- parallel
<soren> Heh :)
<seb128> soren: any plan to update gtk-vnc in jaunty?
<exarkun> Is the wxPython package gravely broken in Hardy?
<exarkun> http://rafb.net/p/Sj1n5Q79.html
<exarkun> I just found the `python-wxversionÂ´ package.  Is that an Ubuntu thing?
<superm1> siretart, i just updated the packaging for them, they're now shipped in nvidia-180-libvdpau-dev  binary package
<siretart> superm1: I'm just skimming over the ffmpeg code in upstream trunk
<superm1> sebner, i dont believe it works unless you use IgnoreABI still, it was mostly uploaded so that stuff that needs the new vdpau API could build against it
<siretart> superm1: it doesn't seem to make sense to compile ffmpeg against these headers yet
<superm1> siretart, due to code maturity, or is it that you get no added functionality?
<siretart> superm1: the code to actually use vdpau has just been submitted one hour ago on the ffmpeg mailing list ;)
<superm1> siretart, ah :)
<siretart> superm1: see, its nice that libavcodec offers access to vdpau, but you still need support in the codecs, and/or in the video output drivers
<superm1> siretart, right, and likely the applications will need to expose a way to change video output too
<siretart> the whole thing seems to need some more months review and integration work. I don't think ffmpeg and mplayer will be ready until feature freeze. but who knows?
<siretart> superm1: well, for mplayer and xine you can already select your video output plugin
<siretart> I expect that you'll get yet another plugin for vdpau just like for xvmc
<siretart> ideally these players would just autodetect if that is avaiable and just use it
<superm1> i'm not even sure the mythtv version that supports it (0.22) will be ready to be released by feature freeze, but in the event it is i wanted to make sure that the packaging side was ready to go with test builds /what not
<siretart> but that isn't implemented yet. and I'm not sure if that makes sense at this point at all anyways
<superm1> yeah mythtv does autodetection and falls back
<siretart> mythtv implements video output itself? I thought it uses mplayer or something for that?
<superm1> it implements itself yes
<siretart> ah, ok
<superm1> it's got an internal playback system based on ffmpeg
<siretart> aah, I see
<siretart> anyway, it seems to me the sanest way to enable ffmpeg with vdpau is to place a copy of vdpau.h and vdapu_x11.h in the ffmpeg-debian source package and make it dlopen the libraries at runtime
<siretart> and hope that the vdpau API and ABI are more stable than ffmpeg's
<sebner> superm1: kk, thx
<sebner> siretart: btw, did you notice that vlc open a further window for the video playing (again)
<superm1> siretart, well i believe the way that things are working is that you link against libvdpau.so which will dlopen libvdpau_nvidia.so later
<superm1> but i'm not positive
<siretart> sebner: no, I'm still on intrepid. I wonder if I should update my laptop to jaunty yet...
<sebner> siretart: heh, anyways. it's happening on jaunty. I didn't want to reopen the old bug but tell you via irc :)
<asac> soren: yes. just add the headers
<siretart> superm1: if I read the source correctly then it seems that you are right and ffmpeg would need to link against the vdpau libraries
<siretart> superm1: would it be possible to rip the vdpau libraries and headers out of the nvidia-glx package into a package on its own suitable for main?
<asac> soren: (if its a plugin) however, will not appear in plugin finder service until i update the plugin db
<siretart> hi asac!
<superm1> siretart, that's what i just did in my last upload
<siretart> superm1: excellent!
<siretart> asac: any news on the sunbird 0.9 front?
<superm1> siretart, (https://edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180) suitable for main i'm not positive, since libvdpau.so is closed however
<lure> last udev seems to break lvm root for me :( - I get just BusyBox
<lure> is this known issue
<superm1> that's what i was worried about, it would likely need to live in restricted too still
<siretart> superm1: is both libvdpau.so and libvdpau_nvidia.so closed?
<asac> siretart: yes. its all packaged
<asac> (i think ;))
<asac> probably an accident that its not uploaded yet
<siretart> asac: cool! where to get binaries? ;)
<asac> iceowl is also ready
<asac> (maybe i uploaded that to experimental)?
 * siretart hugs asac!
<superm1> siretart, unfortunately :(
<siretart> asac: it seems something went wrong with that :(
<lure> uf, ENOKEYBUK :(
<asac> siretart: i guess so
<siretart> superm1: hm. that makes using it challenging :)
<asac> https://code.edge.launchpad.net/~mozillateam/sunbird/ubuntu-0.x
<asac> https://code.edge.launchpad.net/~mozillateam/sunbird/iceowl.debian-0.x
<asac> so havent released the packages yet as it seems ;)
 * asac writes this on his TODO to not forget
<superm1> siretart, i wonder if we could try to ask nvidia to provide source for just that one library
<superm1> it literally is a 4.5k wrapper
<siretart> superm1: that would be indeed helpful
<siretart> asac: thanks!
<asac> thank me after the upload ;)
<siretart> asac: I tried testing the binaries from mozilla, but they don't enable gssapi support for some reason in their binaries :-(
<siretart> so I'm eagerly waiting for the packages, because they do
<asac> oh they do? ... competitive advantage ;)
<siretart> indeed!
<siretart> there is even a bugzilla bug about that open in their bugtracker
<siretart> but being ignored for ages :/
<siretart> anyways. it seems that sunbird still cannot accept iTIP invitations :(
<superm1> siretart, i've got a contact with them that has been involved with vdpau that I sent a note to.  i'll let you know what i hear
<siretart> superm1: excellent! thanks!
<superm1> siretart, already got a response: http://paste.ubuntu.com/101886/
<siretart> superm1: that's great news!
<superm1> siretart, yeah and in the event that the open sourcing doesn't happen "soon", i think that stub idea would work well.
<siretart> superm1: this means that things are going well. do you think it makes sense to target jaunty, or shall we defer this affair to jaunty+1?
<siretart> giving my current available time, I'd vote for jaunty+1
<superm1> siretart, well that all depends on how accepting ffmpeg ends up being for this patchset.  all the other pieces will start to come after that
<siretart> vdpau is currently being actively reviewed and integrated in ffmpeg right now
<siretart> however I have no insight how invasive and how many patches are yet to follow, but things are very promising!
<superm1> siretart, indeed.  i'll be keeping my eyes on it. i'll let you know if i hear more.  i'll be glad to help out should there need to be some more integration pieces and it comes down to crunch time for FF
<pochu> could some core-dev approve the intrepid task in bug 295490 please? TIA :)
<ubottu> Launchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Medium,Fix released] https://launchpad.net/bugs/295490
<kees> hm, that's serious code quality when you compile with -O99999999
<james_w> kees: http://people.ubuntu.com/~jamesw/ppamadison
<james_w> likely to cause injuries to pets if used in anger, as it will open a web browser at every invocation currently
<kees> james_w: cool
<kees> james_w: btw, I tend to use this: http://pastebin.osuosl.org/23183
<james_w> kees: yeah. It would be good to have some standard way of doing that
<bryce> kees, you should use ~/.cache/... and ~/.config/...
<directhex> james_w, do you want to be thanked in my mono transition report, or do you want to hide from the boycottnovell hit list of evil freedom hating microsoft employees?
<james_w> directhex: now there's an offer I can't refuse :-)
<sebner> james_w for freedom \o/
<Hobbsee> robbiew: consider yourself whitelisted on u-d@
<robbiew> Hobbsee: \o/
<Hobbsee> :)
<Hobbsee> so now I can read the team summary :P
#ubuntu-devel 2009-01-08
<Hobbsee> hm.  very cool ftbfs page - it's grown colour!
<sabdfl> Hobbsee: url?
<Hobbsee> sabdfl: http://qa.ubuntuwire.com/ftbfs/
<sabdfl> that is nice
 * ScottK waves at sabdfl and says thanks for the +1 on clamav micro-version updates.
 * directhex waves at sabdfl generally
<LaserJock> Hobbsee: it is pretty nice looking
<sabdfl> np ScottK
<sabdfl> long list
<LaserJock> lots of armel :-)
<Hobbsee> indeed.
 * Hobbsee is looking at the failed to upload ones
<ScottK> hppa isn't so happy either.
<LaserJock> no, I noticed that
<LaserJock> hasn't hppa been around for a while?
<directhex> yeah, but nobody tests on it because they have no simple means to do so
<directhex> they just wait for build fail messages from assorted archives, and often ignore them as unreporducible
<ScottK> LaserJock: Also there's a soyuz bug that causes kde4bindings to get skipped on hppa currently, so the entire rest of the KDE stack is FTBFS.
<ScottK> That's several handfuls of them.
<Hobbsee> NCommander: are you planning to merge across firebird2.0 again, to make it installable this time?
<Hobbsee> ScottK: oh?  what soyuz bug?
<ScottK> Hobbsee: Bug 311952
<ubottu> Launchpad bug 311952 in soyuz "Packages-arch-specific blocking of a single binary blocks the entire source package" [Medium,Triaged] https://launchpad.net/bugs/311952
<Hobbsee> tasty.
<LaserJock> ScottK: interesting
<ScottK> I don't get Medium, but that's just me.  I guess building packages isn't an important function for Soyuz.
<ScottK> ;-)
<Hobbsee> ScottK: well, they can't mark *everything* critical.
<Hobbsee> & high
<LaserJock> no?
<Hobbsee> well, they could, but it wouldn't be so useful.
<LaserJock> that implies it's useful now ... :-)
<Hobbsee> NCommander: ignore that.  merged it myself.
<Hobbsee> NCommander: OTOH, it would be nice if you actually went back and fixed build failures for packages that failed across the board, after your changes.
<NCommander> Hobbsee, actually, I was going to request firebird 2.0 be removed, it didn't fail to build, it just failed to upload
<Hobbsee> that counts, i'm sure :P
<Hobbsee> so it can be removed?
<Hobbsee> it seems debian's designing it to be coinstallable
 * TheMuso should look at powerpc FTBFs later.
<NCommander> brb, need to run to the store
 * NCommander needs a torx screwdriver
<Hobbsee> NCommander: or at least, it counts when it's due to a packaging bug, not a soyuz bug.
<cjwatson> james_w: shame there's no interface to binary publishing records in the LP API yet
<cjwatson> (ppamadison)
<james_w> cjwatson: indeed.
<cjwatson> james_w: I knocked up a similar lpmadison prototype for Ubuntu the other day, but shelved it for the time being as it's not all that useful with just sources
<cjwatson> but source publishing is a fairly recent addition so I imagine it's on the cards ...
 * directhex hands NCommander his xbox moddin' screwdriver set
<borschty> hi, i just noticed, that in jaunty using the intel driver there is an entry missing in /proc/mtrr, but i'm not sure if this a bug or an intentional behaviour (with that new memory management stuff going on etc)
<borschty> adding the entry back gets the ttys working again (those were broken before) and lets glxgears run two times as fast
<borschty> what confuses me a bit is that when i restart xorg by quitting gnome the entry gets removed again, so would that be a xorg driver issue?
<borschty> reg04: base=0x0b0000000 ( 2816MB), size=  256MB, count=1: write-combining
<borschty> thats the entry btw.
<rootard> doko__: how much work would it be to incorporate the OpenSolaris .sh files (from jdk-distros) into the sun-java6 source package?
<Roey> hello
<Roey> This bug still exists in Ubuntu 8.10 for X86_64:  https://bugs.launchpad.net/ubuntu/+source/hal/+bug/211569
<ubottu> Launchpad bug 211569 in hal "xsane won't start unless run as root (Epson Perfection 1240)" [Medium,Fix released]
<NCommander> calc, I summon thy!
<Roey> calc:  whoah, where did you go all these year??
<Roey> years
<StevenK> NCommander: Er, thee
 * NCommander pulls the source package
<ScottK-desktop> NCommander: Even if you have the source package, it's still thee.
<calc> NCommander: eh?
<calc> Roey: huh?
<Roey> calc:  hey
<Roey> remember me?
<Roey> Chris
<calc> Roey: yea iirc from debian-kde?
<Roey> er
<Roey> yes yes
<Roey> Chris what's up??? I didn't know you do Ubuntu now
<calc> Roey: yea i switched to using ubuntu around sept 2004
<Roey> ahh interesting
<calc> Roey: then started working on ubuntu june 2007 on OOo
<Roey> and you don't use KDE then?
<Roey> ok
<calc> not anymore, no
<calc> i'll have to see how kde 4 shapes up over the next few releases :)
<Roey> ahhhhh
<Roey> I was almost ready to give up on this
<Roey> I went to the release party in California last January
<Roey> met a whole bunch of devs
<NCommander> calc, cool, that worked.
<Roey> the "known" names etc.
<NCommander> calc, any idea when OOo in main will be fixed?
<Roey> oh, since you're here, Chris, couldja help me with this
<Roey> This bug still exists in Ubuntu 8.10 for X86_64:  https://bugs.launchpad.net/ubuntu/+source/hal/+bug/211569
<ubottu> Launchpad bug 211569 in hal "xsane won't start unless run as root (Epson Perfection 1240)" [Medium,Fix released]
<calc> NCommander: in jaunty?
<calc> NCommander: once the last two build-depends are fixed, two FTBFS from them for conversion to default-java
<calc> actually xom iirc FTBFS in general even without conversion
<NCommander> davidm, fixed already
<NCommander> davidm, or at least they're built.
<NCommander> er
<NCommander> sorry, calc
<StevenK> calc: But you want stlport4.6 on i386, which is in universe, and has been since dapper
<calc> Roey: cool, i was in california last month at UDS :)
<Roey> :)
 * Roey high-fives calc
<calc> StevenK: ugh ok, i'll have to beat on that for i386, didn't notice it since i use amd64 here
<NCommander> calc, I can look into fixing the issues
<calc> i'm making a 1:3.0.1~rc1-2ubuntu1 build right now
<Roey> calc:  do you work for Canonical now?
<calc> NCommander: there is a mir for the packages
<StevenK> calc: According to NCommander, we had a change to not use stlport4.6 since Hardy
<calc> NCommander: bug 305790
<calc> StevenK: yea but in the sync to debian got dropped probably since 2.4.1 -> 3.0 was a lot of changes in the rules file
<ubottu> Launchpad bug 305790 in suitesparse "MIR - move to main for openoffice.org 3 build-depends" [Undecided,Fix released] https://launchpad.net/bugs/305790
<calc> StevenK: rules file is somewhere north of 3500 lines :-(
 * StevenK shivers
<NCommander> calc, I can look at fixing it
<calc> i'm sure i can fix up the stlport issue for i386
<NCommander> calc, I'm fairly sure where I need to go to disable STLPORT usage
<calc> NCommander: the xom package randomly fails on amd64 at least
<NCommander> define randomly fails
<calc> NCommander: it built for me so i uploaded it, then it failed on buildd, tested on my machine failed, i changed the deps a bit it built, uploaded to buildd where it failed again, heh
<StevenK> Haha
<calc> building inside a chroot
<NCommander> So it builds fine on your machine, and going boom in a chroot?
<calc> NCommander: it built twice on my machine failed once and failed both times on the buildd
<calc> i haven't worked on it in a while though
<StevenK> calc: It's because crested and yellow hate you
<NCommander> can you define the failure for me?
<calc> NCommander: er i don't recall where it failed its in the build log though
 * NCommander grabs the source package
<calc> NCommander: last time i looked at it was before my christmas vacation
<NCommander> xom is universe ....
<NCommander> O_o;
<calc> NCommander: yea i was converting to default-java to get it moved into main
<NCommander> Oh, so its going to main once you can fix this failure bug, right?
<calc> yes
<NCommander> any objections if I take a swing at it?
<calc> NCommander: no problem from me :)
<calc> NCommander: i had ~ 12 other packages to do at the time so didn't look at it too long but it looked really odd the way it was failing
<NCommander> calc, that's impressive
<NCommander> calc, your compiler getting stuck in an infinite loop
<NCommander> calc, is xom VCS packaged, or can I just fire into universe once I get it building?
<calc> NCommander: not sure if there is a vcs for it, i just grabbed it with apt-get
<davidm> StevenK, send me an update before you drop off tonight, I have a status meeting with woei tomorrow.
<ScottK> If anyone is interested in getting experience with Ubuntu processes, apparently libtest-warn-perl needs a MIR so libnet-ssleay-perl will build.
<maxb> I'm writing a script that I hope can become part of people.ubuntu.com/~ubuntu-archive/ reporting. Does that machine have filesystem level (read) access to the ubuntu archive, or should the script download files via http?
<cjwatson> maxb: (a) yes it does (b) don't worry anyway, we'll adjust it as needed
<cjwatson> maxb: (actually the stuff that shows up on people.ubuntu.com/~ubuntu-archive/ is mostly run on the master archive system and rsynced/scped over
<cjwatson> )
<maxb> ok then, there's a script in lp:~maxb/+junk/ubuntu-archive-reporting for consideration. Should I send mail/bug somewhere?
<maxb> erm, and I should probably document it better too
<cjwatson> maxb: mail ubuntu-archive@lists.ubuntu.com please
<StevenK> cjwatson: I've removed you from the changelog in livecd-rootfs, since umpc is going away. (In bzr)
<cjwatson> ok
 * maxb will sleep now, go over it adding comments, and then send mail tomorrow
<StevenK> cjwatson: If I pastebin my diff, will you sanity check it? The changes are mostly harmless
<cjwatson> StevenK: not now (bed), maybe later
 * StevenK checks what time it is in London. 
<StevenK> Eek
 * maxb is being somewhat nocturnal :-)
<davidm> Guys have a look at: https://arm.wiki.canonical.com/Home/Freescale and add drivers and what not that you think we need please.
<cjwatson> maxb: why not use python-apt for version comparison?
<davidm> NM wrong channel
<cjwatson> apt_pkg.VersionCompare I believe
<cjwatson> maxb: you could use it for stanza parsing too
<cjwatson> anyway, bed
<maxb> aha. the apt apidoc is a bit... nonexistent
<maxb> I don't think using it for stanza parsing is an option, if I'm reading the .bz2 files (which is all I have locally)
<maxb> I'll investigate a bit more, anyway
<NCommander> O_O;
<NCommander> Things you DON"T want to see during apt-get dist-upgrade:
<NCommander> Removing xserver-xorg ...
 * ion_ recommends aptitude
<calc> StevenK: ok i got stlport removed from build-dep for new packages i am working on
<calc> is there a way to clear the apt cache in synaptic, a user needs help doing it, but i don't use synaptic
<calc> there download seems corrupt
<calc> er their
<calc> i just told them the apt-get way
<karthik_> hey i need the source of ubuntu desktop
<karthik_> plz help me
<TheMuso> karthik_: What package from the Ubuntu desktop do you want source for?
<karthik_> TheMuso: libwnck and the packages which we use for switching workspaces
<TheMuso> karthik_: Ok I don't know what packages are used for switching workspaces, but you can fetch the libwnck source package by running "apt-get source libwnck" which will download the source package for you, providing you have a deb-src line in /etc/apt/sources.list.
<TheMuso> Note that I am not sure that is the exact source package name, you will have to check.
<karthik_> ok
<pitti> Good morning
<LaserJock> morning pitti
<dholbach> good morning
 * pitti dist-upgrades and hopes that the new udev won't break the world
<dholbach> pitti: it's all going to be good :)
<dholbach> pitti: the changelog looked "this has potential to break everything" too :)
<pitti> argh, "No space left on device" -- see, udev broke everything!!!11!!
<pitti> mvo: wishlist: make sudo apt-get autoclean work while apt-get dist-upgrade is in progress
<pitti> StevenK: if you process NEW today, can you please look at calibre? I uploaded it, so I can't NEW it myself
<StevenK> pitti: Certainly
<tjaalton> pitti: about bug 314772, mountnfs.orig is not listed in conffiles, so does dpkg still handle it as one?
<ubottu> Launchpad bug 314772 in sysvinit "superfluous /etc/network/if-up.d/mountnfs.orig in initscripts" [Medium,Confirmed] https://launchpad.net/bugs/314772
<pitti> tjaalton: oh; hm, one needs to check /var/lib/dpkg/status for that
<pitti> tjaalton: do you have an affected system/
<pitti> ?
<tjaalton> pitti: yes, dpkg --status initscripts doesn't list the file as a conffile
<pitti> tjaalton: so you have the file, and if you upgrade, it goes away?
<tjaalton> pitti: heh, I should probably try :)
<tjaalton> pitti: yep, vanished
<pitti> tjaalton: ok, thanks; bug updated, please upload
<tjaalton> pitti: thanks, done
<tjaalton> pitti: heh, so the version was wrong (older than in the archive). I'll just use ubuntu45.1 then
<lool> pitti: Ah too bad, I started reviewing libproxy as well
<lool> pitti: I found a couple of packaging issues though http://paste.ubuntu.com/102088/
<lool> All easy to fix
<pitti> lool: I didn't give it a big review, just a shallow lintian-like check, to unblock GNOME in jaunty
<lool> Sure
<pitti> lool: oh, good points; please copy them into the MIR
<lool> I'm doing that
<seb128> lool: the am maintainer thing doesn't work nowadays, does it?
<lool> seb128: I don't understand
<seb128> lool: what do you mean by "wrong order"? what revision did you review? I ran autoreconf to update the patch in the current revision
<seb128> lool: <@lool> No AM_MAINTAINER_MODE
<lool> seb128: The patch starts by configure then patches configure.ac
<lool> So there's a chance that configure.ac gets a newer timestamp
<seb128> hum right
<lool> And appears newer and triggers a rebuild of configure
<lool> You can't patch-in AM_MAINTAINER_MODE, so the autoreconf should be a separate patch
<lool> Also the patch(es) should be numbered, but that's minor
<lool> In fact I was about to simply go fix the package instead of listing the issues
<seb128> what do you mean by " can't patch-in AM_MAINTAINER_MODE"?
<seb128> I'm interested because I've similar issues on gvfs
<lool> If you add AM_MAINTAINER_MODE in a patch, you will have an issue in distclean where the configure.ac will have been updated and cdbs runs distclean with the patches unapplied
<lool> You can add AM_MAINTAINER_MODE in a patch if you are careful to distclean with the patches applied
<seb128> it seems AM_MAINTAINER_MODE doesn't do anything nowadays
<seb128> or I got something wrong
<lool> It should work
<seb128> gvfs has a 01_maintainer_mode.patch and a autoreconf change
<seb128> but the configure claims not knowing about the option
<seb128> and I think somebody told me the maintainer mode is deprecated in the new autotools version
<lool> Ok; let me finish dealing with libproxy and I'll have a look and see if I see anything obvious
<seb128> ok thanks
<lool> I wasn't aware of its deprecation
<seb128> I'm not sure if that's true but I think somebody told me that
<lool> automake 1.10 had some fixes for AM_MAINTAINER_MODE; I would expect it's still supposed to work
<seb128> lool: http://people.ubuntu.com/~seb128/gvfs_1.1.3-0ubuntu1.dsc http://people.ubuntu.com/~seb128/gvfs_1.1.3-0ubuntu1.diff.gz http://people.ubuntu.com/~seb128/gvfs_1.1.3.orig.tar.gz
<seb128> lool: if you want to look at the new gvfs, you probably want to disable the webdav option to try to build it, it requires new libsoup using libproxy which is not available yet
<seb128> "libtool: Version mismatch error.  This is libtool 2.2.6, but the
<seb128> libtool: definition of this LT_INIT comes from libtool 2.2.4.
<seb128> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
<seb128> "
 * seb128 kicks libtool
<seb128> I ran autoreconf what else do you want!
<Mithrandir> your soul
<seb128> not going to happen no ;-)
 * seb128 kicks libtool harder
<seb128> doko_: there? you changed gstreamer to "Don't run the testsuite on hppa (hangs the hppa ubuntu buildd, libraries are required as build dependencies)."
<seb128> doko_: what do you mean "libraries are required as build dependencies"
<seb128> that's the only ubuntu change we have
<seb128> did you open a debian bug about that?
<mvo> what is the magic to drop all disk caches (for simple benchmark purposes)? to see how fast a operation would take on a freshly booted system
<elmo> echo 3 /proc/sys/vm/drop_caches
<elmo> echo 3 > /proc/sys/vm/drop_caches   # even
<lool> ISTR Behdad blogged about a way to hide the cache from processes hmm
<lool> I don't recall the specifics
<mvo> thanks elmo
<lool> can't find it
<lool> Must have dreamed it!
<apw> so who owns debootstrap ...
<pitti> apw: closest maintianer is probably cjwatson
<apw> poor colin
<apw> and how about apt
<apw> him too?
<lool> No, mvo rather
<apw> ahh ta
<lool> asac: Hey
<lool> asac: You already discussed this with seb128, but I need to understand the decision to push to Debian
<lool> asac: Hmm let me read the ubuntu-desktop backlog first
<sianis> hi
<sianis> we need your opinion
<lool> asac: I read yesterday's discussion; I didn't find a reason for disabling mozjs, but I might have missed it
<sianis> how english users like to reed remaining time in apt / synaptic?
<asac> lool: reason is that mozjs isnt a real lib because upstream doesnt have a ABI/API policy
<lool> asac: I think it's required for .pac support; when I started using GNOME, it was a big feature missing from the picture: .pac support needed js support and that was overkill for gnome-vfs
<sianis> now this is like: 1h5min32s
<asac> and hence we cannot use it in main
<asac> lool: upstream is working on improving that for js. i think debian tracks the ABI/API on their own. we dont do that
<lool> Ok, so there's a real Debian/Ubuntu difference here; hmm I guess I could lsb-release check and add a configure flag
<asac> so it might be ok to have in debian (though it definitly puts a risk on sec updates)
<sianis> 1h 5min 32s is better? Or 1 h 5 min 32 s is better? Or Is the actually good?
<asac> lool: do you have a debian chroot or something at hand?
<lool> asac: Ah then it's probably a good motivation to disable that support in Debian for now
<lool> asac: I could reboot into Debian
<asac> lool: just check whether libmozjs is packaged in a separate package and shipped with version in /usr/lib
<asac> lool: well. the risk is not on your package, but on the xulrunner package
<asac> lool: i think its safe for you to keep it
<lool> You mean we might discover that it broke ABI without changing SONAME or something?
<asac> lool: if upstream breaks abi/api in a sec update it means that we need to push a new package into stable-security
<lool> Sure
<pitti> thekorn: hello! can I ask p-lp-bugs to use staging?
<asac> lool: the burden is on xulrunner package ... so :)
<asac> lool: do you know what feature gets disabled?
<lool> ISTR galeon was in a similar situation
<thekorn> pitti, hi, yes you can,
<thekorn> >>> from launchpadbugs.lpconstants import HTTPCONNECTION
<thekorn> >>> Bug.set_connection_mode(HTTPCONNECTION.MODE.STABLE)
<thekorn> s/STABLE/STAGING
<pitti> ah, cool
<lool> asac: the mozjs plugin which is used for .pac
<lool> You might be able to use .pac without js, not sure, but I expect it's used with js most of the time anyway
<asac> lool: pac ... is that automatic proxy thing?
<lool> .pac is basically a 3 lines js script saying something like "if ip address is in this range use proxy foo, otherwise direct"
<lool> asac: Yes
<lool> It might be possible to test URLs in the .pac too (if domain is local then direct)
<StevenK> thekorn: Does s/STABLE/EDGE/ work too?
<thekorn> StevenK, yes
<asac> lool: ok. my point is: disable it everywhere to force upstream to either complain more at mozilla about fixing their abi/api issue
<asac> or to notice that they should use something elsee
<apw> i am correct in thinking that packages in main may not depend on packages in other realms like universe
<asac> lool: i know that spidermonkey folks want to fix that abi/api issue. they just werent aware of that. what they need now is more people complaining so they assign proper priortiy to it ;)
<cjwatson> maxb: see germinate, it does this
<cjwatson> maxb: (stanza parsing using python-apt from bz2 input)
<lool> asac: Ok; I guess I see your point; my view on the topic is that I have no idea what this lib is going to gain us, the only thing I know I ever cared about is .pac and it wont work if we don't enable js, but then I don't use PAC personally
<cjwatson> apw: that is correct
<cjwatson> apw: although we often deal with that by promoting packages from universe to main; it depends on the situation
<cjwatson> apw: what's up? (debootstrap)
<asac> lool: yeah. thats why i think that libproxy folks have to know about the issues. maybe they will reconsider their decision to use mozjs then
<apw> hmmm, yeah debootstapping jaunty is failing, it looks like udev depends on libvolume-id1 which seems to be universe
<lool> asac: Do you know of any alternative?
<apw> approximatly
<cjwatson> hm, really? ok will investigate
<cjwatson> I was sure I NEWed that into main
<cjwatson> oh, I bet -2 arrived in the Window Of Confusion
<apw> libvolume-id1 |      136-2 | jaunty/universe | amd64, i386
<asac> lool: not sure what they need exactly
<lool> asac: Simple JS evaluations
<apw> that sounds like a bad place, is that the gap between waking and the first coffee?
<asac> lool: do you have the source again?
<lool> asac: Grab libproxy from the archive and see src/plugins/mozjs.c (the package is small and the plugin is small)
<cjwatson> apw: fixed for the next publisher run; ETA about 1pm for visibility in the archive
<pitti> thekorn: hm, I get a launchpadbugs.exceptions.LaunchpadURLError: ("message: unknown error"), but it does try to talk to staging
<cjwatson> apw: do you care enough about a quick explanation? :)
<apw> heh ... i always like amusing stories
<lool> JS_DefineFunction(self->ctx, global, "dnsResolve", dnsResolve, 1, 0); (to call into C from JS) and others then they run pacutils.js
<thekorn> pitti, is your cookie valid for staging?
<pitti> thekorn: I just freshly exported it
<pitti> so it should be
<lool> They call FindProxyForURL() in the .pac which I understand can use the pacutils.js lib
<pitti> thekorn: .staging.launchpad.net TRUE / TRUE 1234556 staging Bla.Bla
<cjwatson> apw: the component (main, universe, etc.) that a package lands in is determined by "overrides" set by archive admins; when a new package, i.e. one whose name currently doesn't exist in the archive, arrives then archive admins have to override it to the correct component
<cjwatson> apw: now, I did get this right when I first processed it
<mvo> lool: do you happen to know if debian has the totem bbc plugin too? (I assume not but want confirmation :)
<thekorn> pitti, it worked this morning, can you show me some code you are workng on
<cjwatson> apw: unfortunately, there was a second upload in between my initial override and the point when that first upload was fully processed into the archive
<pitti> thekorn: I instantiate a BugList object, too; I'm not using it AFAIK, but maybe I need to do that there, too?
<lool> mvo: I don't think so
<cjwatson> apw: I waved that through without particularly checking it
<lool> mvo: checking
<apw> ahh yes, like you have to NEW all our kernel packages every time cause of the name changes
<lool> mvo: oh we do
<apw> so basically someone uploaded -1 and -2 in that two hour window
<cjwatson> apw: but there's a window where the override is not really quite entirely applied, due to a Soyuz bug; if a new version arrives in that window, it'll show up with the older default overrides, i.e. universe
<pitti> thekorn: http://people.ubuntu.com/~pitti/tmp/launchpad.py -> current code
<lool> mvo: Added 2008-12-06 by sjoerd
<apw> and so you see it the second time instead of it going magically tot he right place
<lool> in experimental
<pitti> thekorn: ded 2008-12-06 by sjoerd
<pitti> sorry
<thekorn> pitti, you have to do it for both objects, it's not global
<pitti> thekorn: http://pastebin.com/f137de67c -> my current diff
<apw> cjwatson, your world is a painful spikey place to live
<asac> lool: i will think about it - guess a few days
<mvo> lool: thanks, I check it out
<lool> asac: Thanks
<mvo> lool: pac> this is a feature request for apt as well, what is the plan there? libproxy?
<pitti> thekorn: still the same if I do that on BugList, too
<lool> mvo: We're discussing the fact that we disabled mozjs which is required for .pac in libproxy
<apw> cjwatson, the effect of the error was most unexpected.  apt-get fails to install things it can install just because it also cannot install some older package which i don't even care about
<mvo> lool: aha, ok
<cjwatson> apw: yeah, apt likes its world to be consistent and gets rather upset when it isn't
<cjwatson> apw: debootstrap probably left you with a system of installed packages whose dependencies weren't resolved
<cjwatson> at which point all bets are off as far as apt's concerned
<apw> yes ... it did
<apw> whats mad is that unrelated dependancy trees are no longer installable
<apw> but i guess thats apt-get stupidness
<apw> cool ... worked round it
<pitti> thekorn: if you have a ~/.lpcookies.txt, the script should just run for you, too (if you have python-apport installed)
<cjwatson> apw: enable universe in sources.list, apt-get update, apt-get -f install
<cjwatson> should resolve it
<lool> asac: There's a webkit plugin which does JS too it seems
<lool> mvo: So actually webkit is still built and should work
<mvo> apw: or just apt-get install -f (that will remove the packages that it can not make happy)
<lool> But webkit is another issue in ubunut
<lool> seb128: ^
<pitti> thekorn: (launchpad.py updated)
<dholbach> james_w: regarding the bash-completion thing: shall we wait for the new version to be released and sync then? or shall I upload the merge?
<lool> So we probably don't lack full .pac support in Ubuntu right now, if we install libwebkit
<cjwatson> mvo: removing udev probably not so good though
<pitti> thekorn: I disabled the writing functions again and just downlaod a bug report; works on production, excepts on staging
<seb128> lool: right
<mvo> cjwatson: *cough* I missed that udev was the bad one
<james_w> dholbach: I'm not sure, I don't know when they plan to release the new version.
<thekorn> pitti, ok, pulling latest apport now,
<pitti> thekorn: the one in intrepid should suffice
<dholbach> james_w: right-o - I'll upload the merge then
<mvo> cjwatson: it will probably make you type "Yes I know what I am doing and I want to do it and I don't care that you (apt) thinks its not a good idea, really!"
<james_w> dholbach: I think two years worth of improvements is probably worth having noew
<pitti> thekorn: I just changed launchpad.py (above URL)
<mvo> (before it lets you removing that)
 * mvo thinks that bzr-handle-patch is *love*
<asac> lool: http://code.google.com/p/google-gadgets-for-linux/source/browse/trunk/extensions/smjs_script_runtime/gen_libmozjs_glue.sh ;)
<cjwatson> mvo: udev isn't *actually* essential :)
<asac> maybe i can reduce that to symbols that are known to be stable
<apw> mvo, in this case it wasn't willing to, but i thing it would have had to remove ubuntu-essential or similar
<dholbach> james_w: the first hunk of the patch - where does it come from? is it from the qdbus thing too?
<cjwatson> ubuntu-minimal is not Essential: yes either
<mvo> cjwatson: aha, right - its kind of essential but not Essential: yes :)
<dholbach> james_w: nevermind
<cjwatson> yeah, it's not to the level where you would need special tools to put it back if you removed it
<thekorn> pitti, which version of py-lp-bugs are you using, the one in trepid or from trunk
<cjwatson> which is the point of essential
<pitti> thekorn: current jaunty (Version: 0.3.1)
<pitti> thekorn: same as in intrepid; let me try trunk
<thekorn> pitti, worked for me, https://bugs.staging.launchpad.net/ubuntu/+source/gzip/+bug/89040
<ubottu> Launchpad bug 89040 in gzip "[apport] gunzip crashed with SIGSEGV in read()" [Undecided,Invalid]
<thekorn> with the version in lp:python-launchpad-bugs
<pitti> thekorn: thanks for trying; I get the same error with trunk, so it's probably a cookie problem then
<dholbach> james_w: uploaded, good work
<thekorn> pitti, did you ever thought about moving to launchpadlib soonish? ;)
<pitti> thekorn: heh, in fact I did, and I reported bugs againts launchpadlib for everything that's missing in order to move to it
<lool> seb128: I don't have time to look at gvfs right now, and I'll probably wait until it's buildable
<seb128> lool: ok, no hurry, thank you
<pitti> thekorn: does p-lp-bugs store cookies or other cache information somewhere, which I could try and delete?
<james_w> dholbach: rock. thanks.
<thekorn> pitti, no, not by default, just if you run Bug.connection.save_cookie()
<thekorn> but I think you don't
<pitti> no, I don't
<pitti> thekorn: I logged out and back in, and refreshed my cookie again, no help
<pitti> thekorn: ok, nevermind; I'll just test on production then, *shrug* (it's not much)
<thekorn> pitti, oh wait, there is ~/.python-launchpad-bugs.conf
<thekorn>  with cookies, weird
<pitti> aah
<pitti> removed, but still the same crash
<asac> lool: is the webkit js plugin  packaged individually or in the main lib?
<pitti> thekorn: it was regenerated, this time without any cookies
<thekorn> pitti, it should only be there when you run the testsuite, will try to find out why this file is there later today
<pitti> thekorn: right, it does write cookies for lp and edge, but none for staging
<pitti> thekorn: does your staging cookie look similar to mine?
<pitti> i. e. it's ".launchpad.net ... edge" vs. ".staging.lauchpad.net ... staging" for me
<thekorn> pitti, sorry, I'm using a FF3 sql cookie
<pitti> thekorn: right, I generated it with cookies-sql2txt
<asac> lool: k found it
<pitti> thekorn: can p-lp-bugs use sqlite now?
<thekorn> pitti, yes, just use the sql one
<pitti> thekorn: ok, that didn't help
<Baby> pitti: ping!
<pitti> hey Baby
<pitti> (it feels so weird saying that...)
<thekorn> hehe
<Baby> :)
<Baby> pitti: I made some corrections to the copyright file, I plan to upload it to NEW this afternoon, will that be OK for you? :)
<Baby> NEW -> Debian
<pitti> \o/
<pitti> Baby: sure
<Baby> cool :) great then!
<pitti> Baby: I need to fix the packaging to use dh_installudev, so that we can sync it to Ubuntu, too (and also because it's cleaner), but that's my only TODO item right now
<pitti> Baby: I can do that after the initial upload, too
<pitti> Baby: please just use dch -r/debcommit -r when you upload, and push
<Baby> will you be online this afternoon?
<pitti> Baby: yes, barring lunch break
<Baby> cool, I'll try to do it when I have you online then :)
<thekorn> pitti, I just has a quick look at apport's launchpad.py, I think the only two things missing in the API are removing attachments and an API for +storeblob
<thekorn> did you already file bugreports for these?
<nnull> why is the inputbox for remote desktop limited to a 8char string?.. seem's silly.. as anything that small is rather crackable?...
<doko_> seb128: I don't expect any uses of gstreamer on hppa, but the libaries are needed as build dependencies for other packages. I don't see the tests failing in debian
<seb128> doko_: any idea why the debian buildds would work fine and the ubuntu ones have issues there?
<seb128> doko_: should we try to sync the current version to see if that's still an issue?
<doko_> seb128: I don't think so, did succeed in Debian before the update as well. there's a kernel patch pending for other threading issues, not sure if/when this will be applied.
<doko_> lamont: ^^^
<lamont> seb128: what's the failure?
<lamont> the biggest diff is NPTL crack, generally
<seb128> lamont: dunno, doko did disable the gstreamer0.10 testsuite on hppa because it hangs the ubuntu buildds apparently
<seb128> lamont: that's the only diff we have on debian and syncing that package would be nice
<doko_> look at the build logs for the failed builds
<seb128> lamont: the same package builds fine on debian hppa apparently
<doko_> lamont: I mean the issue mentioned in http://bugs.debian.org/509555
<ScottK> doko_: Do you have any plans for Python 3.0 support in python-central this cycle?
<seb128> lamont: http://launchpadlibrarian.net/18941051/buildlog_ubuntu-intrepid-hppa.gstreamer0.10_0.10.21-4_FAILEDTOBUILD.txt.gz
<doko_> ScottK: yes
<fasta> After an upgrade to 8.10 pthreads is not being found by ld anymore, even though libc6-dev is installed. When I run ld in verbose mode, I see that it never tries to find it in /usr/lib/. I can only assume that you changed that. Did you and if so, why and what's the solution to the problem?
<lamont> it's possible that kyle fixed some of the bugs and the ubuntu kernel is lacking said fixes
<ScottK> doko_: Great.  One of my Python module packages just released a new upstream with Python3.0 support and I'm interested to get it packaged.
<lamont> 2.6.26-bpo.1-parisc64-smp is what's on the debian buildd
<lamont> and I _KNOW_ we don't have that on the ubuntu buildds
<lamont> doko_: though, to be fair, I'm not far from just saying "let's make intrepid the final release of ubuntu/hppa"
<lamont> doko_: but I need to go do the research and see how much archive traffic hppa has been getting (and subtract out buildds and developers-fixing-bugs-for-the-buildds from the list) to see what, if any actual use/demand there is for it
<directhex> who are the real-world "market" for hppa ubuntu?
<doko_> lamont: how far do you need to be pushed?
<lamont> directhex: the hppa port was done "because we (for a very small definition of 'we') can, and without any business rationale" or words to that effect when we (fabbione and I) announced the sparc and hppa ports
<mok0> It'
<lamont> and the suspicion is that 99% of the hppa packages being fetched are: 1) buildds, 2) devs fixing bugs found by the buildds, and 3) mirrors
<lamont> I'd give it more nines, but I'm not sure we're past 100 unique IPs, either...]
<mok0> It's actually useful to see if code compiles well on hppa and sparc
<ghostcube> hi folks me again and i wanted to ask again why only kubuntu isnt shipping jackd xine-lib support
<lamont> mok0: yes
<ghostcube> its the only kde4 based distrie not doing this
<lamont> hppa is big-endian, and can be made bitchy about alignment issues, etc.
<lamont> ghostcube: that sounds like a #kubuntu question
<ScottK> ghostcube: #kubuntu-devel might be a better place for Kubuntu questions.
<ghostcube> nope
<ghostcube> its a xine-lib problem
<directhex> don't sun ship sparc servers with ubuntu?
<ghostcube> not kubuntu related
<Riddell> ghostcube: because jack isn't in main
<ghostcube> they send me here
<ghostcube> Riddell, i heard this tghe last time too but it cant be that ubuntu is taken this out even if debian and suse ship it
 * lamont defers to Riddell 
<ghostcube> i dont want to change the distrie only for this
<mok0> ghostcube: pls explain the problem
<ghostcube> ok xine-lib normally has an build in jackd output support since 1.1.3  so you can set jackd as an audio output source inside the systemsettings of kde 4
<ghostcube> but it seems that ubuntu has taken this out for a problem in gutsy
<directhex> lamont, IMHO it's hard for contributors to get fired up about an arch they will never ever see. how do you test something on hppa or arm, without a full-on package upload to the archive? you end up with only porting specialists caring
<mok0> ghostcube: do you know why?
<mok0> ghostcube: Is there a bug report or something?
<ghostcube> and i can show u a screenshot from debian and suse where it works i have been to #kde asking for this they told me that this works but only on ubuntu or kubuntu not
<ghostcube> mok0, yes
<ghostcube> moment if i can find it
<Riddell> really, it's not a bug, we don't support jack that's all
<mok0> Riddell: so it's been taken out on purpose?
<ScottK> One of the defining features that differentiates *buntu from Debian is to pick one particular tool for a job and focus support on that and not try to support the world.
<ScottK> Jack isn't the one we picked.
<directhex> moar sound daemons!
<Riddell> mok0: yes, jack isn't in main
<pitti> thekorn: at least for storeblob, yes; I also filed something else
<ghostcube> ScottK, jackd is needed for musicans ok so i know this i just change my distrie to make music with the jackd support on debian
<ghostcube> if this is what u want no prob
<ScottK> ghostcube: Ubuntu Studio supports Jack.
<ScottK> For exactly this reason.
<ghostcube> not working
<ghostcube> its not an studio or kubuntu prob the lins are the same
<ghostcube> *libs
<ghostcube> i tried it
<ghostcube> ui cant check jackd into phonon audio sources with xine backend
<ghostcube> thats fact
<persia> ghostcube, It's a known bug, and the main reason it's true is because we chose to support firewire audio with jack in preference to supporting the xine backend.
<persia> For 9.04, this may no longer be a binary choice, and it can be resolved.
<persia> Testing on this is not yet complete.
<ghostcube> persia, thx for the answer
<ghostcube> its not that i want to blame anyone ion here you do a great job
<pitti> thekorn: I also filed a bug about using it in unauthenticated mode for public read-only operations
<pitti> thekorn: for some strange reason I can't actually find the bugs I filed ATM, though :/
<ghostcube> persia, as i see this screen i tried all to get this done :) and as no one could help the only chance was to get an answer here : http://dot.kde.org/1170773239/1170778900/1170862970/1170863051/kcmphonon5.png
<persia> ghostcube, It's deliberately disabled.  It will be enabled if/when we can be confident of security support for the entire stack on which it depends.
<ghostcube> persia, thx it would be a great thing for all the ones doing music on kde with ubuntu studio libs  :) thx and bye folks
<thekorn> pitti, ok, cool, I've also found bug 302824, but I think I've already done something like this with the API,
<ubottu> Launchpad bug 302824 in soyuz "Need API for listing the current package versions in a particular distroseries" [Undecided,Triaged] https://launchpad.net/bugs/302824
<thekorn> when I find it I will add a comment to this bug
<pitti> ah, they got moved to the particular LP components, not launchpadlib any more
<cjwatson> thekorn: can't you do it with archive.getPublishedSources? that takes a distro_series parameter
<cjwatson> you can only get source package versions, not binary
<thekorn> right, I've done:
<thekorn> [i.source_package_version for i in u.main_archive.getPublishedSources(exact_match=True, source_name="apport", distro_series=ubuntu.current_series)][0]
<cjwatson> right
<pitti> thekorn: neat; could you post that to the bug report?
<pitti> thekorn: thanks!
<mterry> Hello! Any grub people in the house?  If I modify the grub package to add a new kernel option (add to defoptions in update-grub script), how do I make that new option active when update-grub runs during post-install?  update-grub seems to prefer existing menu.lst options.
<stefanlsd> Would anyone mind checking if the debdiff - http://launchpadlibrarian.net/21011138/debdiff-jaunty-1  is a sane fix for a libtool error using autoreconf (never used it before...)
<ogra> wow ... so i have a usb disk i manually mounted as root and untarred something on ... while that was running i plugged another usb disk into the same usb hub ... this caused the first disk to be remounted under /media/disk ... and indeed trashed my untar process
<ogra> pitti, ^^^ ever heard of something like that ?
<ogra> intrestingly the first mount was never really unmounted
<pitti> ugh, "re"mounted?
<pitti> no, never heared that
<ogra> well, mounted
<pitti> well, it was mounted before, wasn't it?
<ogra> yes
<ogra> and the devicename changed
<ogra> i mounted /dev/sdb1 to /home/ogra/tmp
<ogra> then plugged in the second disk to the same usb hub
<ogra> and suddenly had a /dev/sdc1 (which in fact was sdb1 and now was mounted to /media/disk)
<ogra> and a /dev/sdd1 on /media/disk-1
<pitti> ogra: what does dmesg say?
<ogra> additionally the terminal my tar xzvf was running in spilled I/O errors like mad
<pitti> ogra: it sounds like if the first one suffered a temporary power loss or so
<ogra> it has an external power supply
<pitti> can you pastebin your dmesg?
<ogra> pitti, http://paste.ubuntu.com/102215/
<pitti> ogra: you have a disconnect at line 23, way before detecting the new drive
<ogra> well, but that was caused by plugging in the second drive
<pitti> ogra: that was the hub, I presume; line 47 is the actual (old) sdb
<ogra> i could exactly see the tar errors starting the second i plugged it
<pitti> which just went with the hub, I GUESS
<ogra> weird ...
<pitti> right, I don't doubt that
<ogra> so dont buy intel hubs :P
<pitti> it looks like pluggin gin the second disk disconnected the first one
<ogra> actually that was a free giveaway ...
<fbond> Hi, what recent Hardy update might've killed a colleauge's nvidia setup?
<cody-somerville> fbond, not sure but I've heard other people complaining as well
<apw> define killed?
<fbond> apw: He's getting xorg log message that indicate that the a compatible kernel module can't be found ... ?
<fbond> cody-somerville: Is there a package I can recommend he downgrade?
<fbond> I've never dealt with the nvidia stuff so I'm short on answers.
<apw> i woudl file a bug in launchpad with the errors you are getting
<fbond> I get people in #ubuntu saying he should install the vendor driver.  Sounds like a bad idea to recommend that to a newbie...
<apw> oh ... do you have to go into the hardware thing and reenable 'binary drivers' every time you get a new kernel.  i think someone said that to me once
<cody-somerville> slangasek, It appears that there may be a regression. radix and fbond are both reporting issues with nvida after an update.
<superm1> apw, no you shouldn't have to
<fasta> Who decides whether any given piece of code goes into Ubuntu?
<superm1> did lrm for hardy perhaps just not get onto the given mirror at the same time as the kernel perhaps?
<radix> cody-somerville: I just had to reboot before I could restart X
<pitti> apw, fbond: no, it should auto-upgrade
<apw> fasta, the maintainers of the package in question
<radix> cody-somerville: presumably because the new X driver was put into place before the kernel module was there, or something
<cody-somerville> interesting
<fbond> I understand my colleague has rebooted already.
<fasta> apw: and when does someone qualify for being a maintainer?
<apw> generally through the motu process
<apw> just interested in how it works or trying to get something into a package?
<fasta> !motu
<ubottu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<fbond> Okay, so packages hit proposed and the changelog dates are mostly accurate.  But the changelog doesn't get updated when they move to -updates?  How can I tell when a package was released to -updates?
<apw> https://edge.launchpad.net/ubuntu/+source/linux
<apw> fbond, pages of that form exist for every package and i think that contains the info you want
<fbond> apw: From what I can tell the relevant packages haven't been updated recently.  I'm really lost as to what might have caused a regression.
<cjwatson> fbond: the associated bug reports are usually updated when a package moves to -updates
<fbond> cjwatson: Okay.  All of this makes tracking down "what update occured recently that might've broken feature X" a bit difficult.
<fbond> Be nice to have an RSS of SRUs...
<kirkland> Riddell: hiya, could you have another look at screen-profiles, and see if the COPYING file I added to the tarball is sufficient?
<Riddell> kirkland: I approved it yesterday
<Riddell> it's probably in binary new now
<kirkland> Riddell: rock on! thanks ;-)
<Riddell> accepting binaries
<lool> pitti: Re: MIRs, any opinion on promoting packages requiring special hardware (#309635)
<pitti> lool: as you said, if a maintainer has the hw, that's fine (and if we don't want it, we should rather drop multipath-tools as well); however, dendrobates- might enlighten us whether we want to support it?
<dendrobates-> pitti: the plan is to support
<dendrobates-> pitti: the plan is to support  FC cards connecting to a SAN
<pitti> dendrobates-: that translates to "multipath-tools"? (NB that I have no clue about those things)
<pitti> dendrobates-: so if we have the tools, having installer support as well certainly makes sense then/
<dendrobates-> pitti: we do not have installer support yet.
<lool> dendrobates-: We're discussing promoting the installer support
<pitti> dendrobates-: I think that's what bug 309635 talks about
<ubottu> Launchpad bug 309635 in partman-multipath "Please promote partman-multipath, multipath-udeb and multipath-tools-boot to main" [Undecided,Invalid] https://launchpad.net/bugs/309635
<lool> dendrobates-: The question is whether people will be able to test it / support it
<dendrobates-> lool: more is required for installer support, but yes we are working with EMC to make sure we can test an support them.
<pitti> dendrobates-: so what would you advise? wait with the MIR until we have full commitment/capacities/equipment?
<dendrobates-> pitti: is there any harm in promoting it now?
<fbond> cody-somerville, apw, et. al.: Issue resolved.  I can't say this is an Ubuntu regression.  User was installing some 3rd party packages that *may* have interfered with deps causing him to lose l-r-m.
<fbond> Thanks all!
<pitti> dendrobates-: is there any harm in promoting it later, when we can actually test it?
<pitti> dendrobates-: promoting it now means to commit to it without being able to really support it, etc.
<lool> pitti: Do you happen to know when multipath-tools was promoted?  I didn't find the MIR in a quick google
<pitti> lool: ages ago; that was a fabbione-ism
<lool> wow
<dendrobates-> pitti: we can test it now,  Ettienne is going to emc in a couple weeks to start working.
<pitti> dendrobates-: ah, that's my primary concern
<pitti> thekorn: hm, seems I get this LaunchpadURLError in the retracer, too, on production; also sometimes from my own box
<pitti> thekorn: so I guess it's not related at all to p-lp-bugs in the end
<soren> It's kind of hard to test installer stuff that isn't in main, isn't it?
<lool> soren: tjaalton wrote "They are available to test if universe udeb support is preseeded" I understand from that that one can use universe udebs
<soren> I see. I did not know that.
<pitti> thekorn: any idea why this happens? http://paste.ubuntu.com/102228/
<pitti> thekorn: (indeed there is no /home/ubuntu-archive/.python-launchpad-bugs.conf in the chroot, but there shouldn't be; I set an explicit cookie file)
<thekorn> pitti, sorry, connot look at it right now, will look at it later today
<pitti> thekorn: no problem; thanks a log!
<pitti> lot
<thekorn> np. please post all tracebacks you get
<pitti> thekorn: I have no clue about the LPUrlError, but this one at least looks fixable
<slytherin> Can any archive admin please process bug 315081. It will clear solve least one other FTBFS.
<ubottu> Launchpad bug 315081 in maven-ant-helper "Please sync maven-ant-helper 4 (universe) from Debian experimental (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/315081
<Riddell> zul: is this mysql intended for main or universe?
<zul> universe
<superm1> pitti, ping.  regarding bug 314547, it sounds like hal might have started emitting events for some keypresses.  do you know of this functionality sneaking in one of the last RC's in jaunty, or possibly of a configuration option that got added to enable and disable it?
<ubottu> Launchpad bug 314547 in gnome-power-manager "notification daemon shows two popups for fn-f3 event" [Low,Incomplete] https://launchpad.net/bugs/314547
<superm1> bryce, or perhaps is that (^) a side effect of X not taking an exclusive hold on the device anymore?
<bryce> superm1: it's possible
<superm1> if that's the situation, then i guess the proper solution is that gnome power manager shouldn't be intercepting the keypress anymore, but just listening for the dbus event
<superm1> and for all other apps that start doing the same thing
<RainCT> mvo: Hey
<RainCT> mvo: Anything new regarding apturl? (By the way, there are one or two patches -from other people- in Launchpad)
<mvo> RainCT: hello! let me check on them
<mvo> (the patches)
<RainCT> mvo: bug #304950, bug #304925
<ubottu> Launchpad bug 304950 in apturl "Bind translation domain of glade file" [Undecided,Confirmed] https://launchpad.net/bugs/304950
<ubottu> Launchpad bug 304925 in apturl "Description expander is not translatable" [Undecided,Confirmed] https://launchpad.net/bugs/304925
<RainCT> mvo: Do you know if there's anything new on the policykit/packagekit front, or do you have any plans for a future version?
<superm1> pitti, bryce, yeah i'm pretty sure that's what it is. i'm thinking more apps will start to react similarly.  i'm not sure how many different dbus events HAL knows how to send, so i dont know what apps will be affected
<joe-mac> hey guys i was wondering if someone in here could possibly help with a preseed/d-i question? i'm trying to preseed raid, but partman-auto-red
<joe-mac> raid*'s udeb is missing
<joe-mac> i tried dropping it in with the other partman-auto-* udebs, to no avail. i am guessing i need to modify something. could someone opoint me to the doc this is outlined in or if simple enough tell me what to do
<bryce> superm1: it sounds right, I'm also a bit uncertain as to how it all should work, but dbus feels like the way forward
<slangasek> fbond: any luck figuring out what package changed to break nvidia?  as you note, none of the "relevant" packages have been updated recently on hardy
<superm1> bryce, yeah i'm looking, and tons of the hotkeys i've got act that way (play, pause, stop, volume, brightness) where they send dbus events from hal and also keypresses to X
<slangasek> superm1: hal emitting events for keypresses> well, if it's on a ThinkPad, see the hal changelog, yes
<fbond> slangasek: I believe this was caused by a 3rd party package with interesting dependencies.
<fbond> slangasek: No regression suspected.
<superm1> slangasek, these are on dells
<slangasek> if it's not a ThinkPad, I have no idea what changed that would affect it
<slangasek> fbond: ah
<superm1> slangasek, at some point bryce mentioned (maybe only to me, i dont remember  the context), that X doesnt hold an exclusive grab to keyboards anymore
<fbond> slangasek: l-r-m had been removed.
<superm1> so other apps (such as HAL) would allow to do stuff with the input device
<slangasek> superm1: hmm, could be - and users wouldn't have reported this problem, the way it was reported for ThinkPads, if X were handling those keypresses
<superm1> bryce, do you remember where that change was made regarding exclusive grabbing?  Is there anyway that upstream would be able to detect it's presence, so they know whether an app should grab keys or not?
<slangasek> eew abstraction violation
<slangasek> superm1: what we really want to do is fix it so X isn't generating keysyms for those keys
<pitti> superm1: I didn't change any particular hal configs, no
<slangasek> there's no reason for a single event to be propagated via both hal and X
<pitti> superm1: but I noticed that suddenly F9 to F11 now control mute/volume in jaunty; but that got changed recently, something in latest GNOME?
<superm1> slangasek, well the problem is some applications don't actually listen for the dbus events and some do i think
<slangasek> doesn't matter?
<slangasek> anything that doesn't listen for the dbus event needs fixed
<pitti> superm1: AFAIK, hal does not send any key related d-bus events at all; the only thing that it does is to poke updated keysyms into the kernel table
<slangasek> pitti: not true
<superm1> yes i agree there, but that list needs to be made before this change is made for X
<pitti> slangasek: oh? seems I still didn't understand it then
<superm1> pitti, it's a recent thing for jaunty.  look at some of the logs in the bug i pointed above
<slangasek> pitti: https://wiki.ubuntu.com/Hotkeys
<lool> Folks, I just got a rejection in my ppa that "The source imagemagick - 7:6.4.5.4.dfsg1-1ubuntu2 is already accepted in ubuntu/jaunty", but rmadison doesn't list it and I don't see it on -changes
<slangasek> hal-addon-input is still part of the design, it processes key events and produces dbus signals
<pitti> oh, right, that
<lool> And I don't see it in http://ftp.debian.org/debian/pool/main/i/imagemagick/ either
<slangasek> you don't see -1ubuntu2 on a Debian mirror? :-)
<lool> Err http://archive.ubuntu.com/ubuntu/pool/main/i/imagemagick/
<lool> slangasek: :)
<lool> EPASTE from my script
<slangasek> lool: I don't see it in the done or accepted queuest, either; I'd suggest asking the LP folks
<lool> slangasek: Ok thanks
<pitti> slangasek: I thought h-addon-input was the thing that writes the hal-info keymaps into the kernel?
<slangasek> the soyuz folks, specificall
<slangasek> pitti: it may do that, as well - hal-setup-keymap is the component that actually does the poking, I don't know if that's invoked by hal or by hal-addon-input
<mvo> RainCT: patches applied, thanks! I check the remaining ones
<pitti> slangasek: ah, ok; I crawl back into my hole now
<slangasek> pitti: anyway, the fact that some events are meant to be received by all sessions via dbus, and some events are meant to only be received by the current session via X, is covered in one of mjg59's blogs
<slangasek> I unfortunately don't have that integrated into the hotkey documentation in the wiki yet :P
<superm1> ah this is the reason that suspend and hibernate keys started working in jaunty properly now too then
<slangasek> oh no, yes I do.  http://mjg59.livejournal.com/99754.html linked from https://wiki.ubuntu.com/Hotkeys/Architecture
<RainCT> (OT, if someone knows an easy way to put something with transparency and the like on the desktop -preferably with Python, and without using gdesklets or other stuff like that- or knows some page with info on this matter please tell me)
<RainCT> mvo: No problem. Remaining ones?
<mvo> RainCT: remaining open bugs
<mvo> RainCT: the unconfirmed ones, just checking if there is more that can be fixed before I upload
<pitti> argh, what the heck happened to the mixer applet?
<slangasek> superm1: which keys are the ones registering double-events?  it's possible that they don't belong on dbus at all because they should only be applied to the current session?
<superm1> slangasek, right now only battery, but with a newer gnome power manager, it would be battery, suspend, hibernate
<slangasek> right, I guess those are all reasonable to have over dbus
<superm1> what are examples of ones that shouldn't be on dbus at all?
<slangasek> media keys
<slangasek> (I think)
<slangasek> or volume keys; you don't want multiple sessions all trying to adjust the mixer
<superm1> hm i kinda can see that - but what if you had multiple media players?
<slangasek> apps can also listen for X events non-exclusively, I believe
<slangasek> the X/dbus dichotomy is only about "current session" vs. "all sessions"
<tedg> I believe that the new GPM now looks to console kit to ensure that it's in the current session before acting on HAL events.
<tedg> I screwed up the packaging, so it's not packaged yet.
<slangasek> superm1: also, g-s-d grabs a number of X events and turns them into dbus signals anyway :)
<slangasek> but on the session bus where they belong
<superm1> slangasek, yeah i think i like that model the best anyho
<jdstrand> kees, mdeslaur: fyi-- I added README.multipurpose-vm to qa-regression-testing. The idea behind it is to have a multi-purpose server VM that other VMs or tests can interact with
<jdstrand> kees, mdeslaur: this came about with my thunderbird testing, where I wanted to test pop3(s), imap(s), smtp, tls, etc
<kees> cool
<jdstrand> kees, mdeslaur: it just documents the email stuff for now, but I plan to add bind9 today, and kerberos and ldap when I have a chance
<jdstrand> (read: 'not today' ;)
<kees> heh
<jdstrand> kees, mdeslaur: it focuses on hardy for now, because a) it isn't meant to be what is being tested and b) it's LTS
<jdstrand> kees, mdeslaur: please add to it if appropriate
<Cpudan80> Hello all
<Cpudan80> Question
<Cpudan80> I need to pull down a few packages from Jaunty repos
<jdstrand> kees, mdeslaur: it would be particular nice to have the whole VM somewhere too, but somehow I think LP/bzr isn't the most efficient way to deal with a 4G binary blob
<Cpudan80> Into my Intrepid installation
<Cpudan80> How can I do that
<pitti> thekorn: ok, it seems that http_connection.py, line 342, calls self.__config.save(), which unconditionally writes the file; I guess I can get away with just mkdir'ing /home/ubuntu-archive/ in the chroot
<jdstrand> kees, mdeslaur: though a preseed/FAI/kickstart thingy could be very cool...
<calc> doko_: ping
<thekorn> pitti, yes this might me the easiest solution, but I always thought that writing to this config file is disabled by default and has to be enabled explicitly
<doko_> calc: contentless pong
<pitti> thekorn: I guess I just locally patched it out in the earlier chroots, and forgot
<yao_ziyuan> the latest QtCurve 12/29/2008 (http://www.kde-look.org/content/show.php?content=40492) is so good that i recommend it be the default theme in ubuntu and kubuntu
<calc> doko_: have you used db bahn before?
<doko_> calc: db bahn?
<calc> doko_: german train service (i think?)
<pitti> www.db.de
<calc> http://www.bahn.de/
<doko_> calc: sure, it's *working*
<pitti> unless they have to check their ICEs...
<calc> ok, my question is there anything special with respect to luggage?
<calc> i will be going between berlin and hamburg after the sprint
<pitti> calc: no limitation
<calc> ok
<pitti> calc: you just have to find some space for it and not leave it in the aisle
<pitti> calc: they have some special areas where to store bulky luggage, too
<calc> ok i won't have much just a plane carryon plus small backpack
<pitti> thekorn: ok, now I'm back to the LaunchpadURLError with "unknown error" on +editstatus
<thekorn> pitti, can you please post me the traceback, when does it happen, when uploading an attachment?
<thekorn> oh, editstatus
<pitti> thekorn: see bug 300548
<ubottu> Bug 300548 on http://launchpad.net/bugs/300548 is private
<pitti> thekorn: it actually set the status, and added the attachments, an attached the comments
<pitti> but then it crashes
<pitti> thekorn: http://paste.ubuntu.com/102325/
<thekorn> wait, it's a huge comment, if seen this in ubuntu-dev-tools recently
<pitti> thekorn: I'll cut it in half, all the -dbgsym packages shouldn't appear in the comment anyway
<rootard> doko_: I've tried using the sun-java6 source package as a base for the OpenSolaris .sh files. The source now "builds" but fails to produce a sun-java6-bin deb package
<pitti> thekorn: the size of the comment matters? or is it the combination of adding a comment, attachments, and status changes?
<rootard> any pointers on where this might be failing?
<rootard> a debian/sun-java6-bin directory is created and populated
<thekorn> pitti, bug 311289 comment #4 has a reproducer for +file-bug, let me try if it also "works" for comments
<ubottu> Launchpad bug 311289 in python-launchpad-bugs "requestsync --lp is crazy (opens multiple bug reports)" [High,In progress] https://launchpad.net/bugs/311289
<pitti> thekorn: that might be true, it's the first time I add comments of that size
<pitti> hm, anyone who knows python's subprocess pipe handling?
<pitti> $ python -c "import subprocess; subprocess.call(['cat', '/nonexisting'], stderr=subprocess.STDOUT)" > /dev/null
<pitti> this should theoretically redirect cat's stderr to python's stdout and thus I shouldn't see any output
<pitti> but I do see cat's error message on stderr
<sebner> pitti: mind sponsoring some mono-* rebuilds?
<pitti> sebner: I'm currently a bit overloaded, I'm afraid, so not right now
<sebner> pitti: kay, np
<pitti> bah, if I set "stdout=sys.stdout", it works; I thought that were the default anyway..
<cjwatson> doesn't really work, drop the >/dev/null to see the new error
<cjwatson> oh, stdout=sys.stdout not stderr=sys.stdout
<pitti> cjwatson: I tried that, seems to work fine
<pitti> right, stdout=sys.stdout, stderr=sys.stdout blows up
<pitti> but stderr=subprocess.STDOUT properly merges them
<cjwatson> I think that stderr=subprocess.STDOUT means "capture to the same file handle as stdout, but only if stdout is being captured rather than passed through
<sianis> cjwatson: can you commit bug 293356?
<ubottu> Launchpad bug 293356 in scim ".desktop file doesn't contain translation domain info" [Undecided,Confirmed] https://launchpad.net/bugs/293356
<cjwatson> sianis: no
<cjwatson> (well, I can, but why me?)
<sianis> cause you have right
<cjwatson> so do several dozen others
<sianis> and you are the last person in the changlog
<cjwatson> sianis: the proper way to do it is to subscribe ubuntu-main-sponsors, not to hassle individuals
<pitti> sianis: please subscribe ubunt-main-sponsors
<sianis> okey
<sianis> thanks
<cjwatson> then it goes into a queue where people who are in the mood to do sponsorship right now can do it
<cjwatson> rather than somebody who's about to head off and do other things for the evening :-)
<sianis> ok, thank you
<pitti> thekorn: in another bug it already crashed in the Bug() ctor already: http://paste.ubuntu.com/102338/
<pitti> thekorn: it looks like this intermittently happens in LP itself?
<Baby> pitti: hi! :)
<pitti> Baby: hello
<Baby> are you very busy?
<pitti> Baby: actually yes, I'm afraid, but don't hesitate to ask
<Baby> oki, I'm gonna upload the package, but I'm not sure how to update the bzr repo after that
<pitti> Baby: dch -r will change UNRELEASED to "unstable"
<pitti> Baby: then you debuild
<Baby> aha oki :)
<Baby> and after that I push?
<pitti> Baby: and then finally "debcommit -r", which will commit the UNRELEASED->unstable change with a standard comment, and add a tag for the version number; then just 'push'
<Baby> sorry, commit and push?
<Baby> oki :)
<Baby> thanks :)
<pitti> Baby: "debcommit -r" is essentially: bzr commit -m 'release as 0.1.2-3'; bzr tag 0.1.2-3
<pitti> but easier to use
<thekorn> pitti, these tracebacks are ugly, I wish py-lp-bugs could be more verbose there, but I think this looks like "internal server error" or samoething
<pitti> Baby: (and also works with svn, cvs, and whatnot)
<Company> pitti: are there plans to make dbgsym packages contain sources, so that i know more than that the code crashed in gtkrange.c:1242
<Baby> thanks pitti, that should be enough :)
<Company> pitti: in a way that doesn't involve lots of manual labor?
<pitti> thekorn: that happens after while count < self.__attempts: apparently? I. e. after three failed attempts?
<thekorn> pitti, yes, exactly
<pitti> Company: I don't currently plan that, they would get even bigger that way
<pitti> Company: I have a feature for including source in apport, it's just not currently enabled
<pitti> thekorn: it looks like the same happened to me locally with staging; maybe it is a tad slower than production and thus times out more easily
<Company> pitti: i want it for my own debugging - and i'd be happy with some apt config that would make it auto-download/delete sources and put them somewhere sane
<pitti> thekorn: is there any knob I could turn to increase the timeout?
<pitti> Company: I think we should rather make the source links more sane, so that apt-get source'ing into /usr/src or so would DTRT
 * slangasek snorts at edge.  "Your languages: Inuktitut, Spannish, Yiddish"
<thekorn> pitti, sorry, not that I know of
<pitti> slangasek: I *knew* you were good at foreign languages! :-)
<Company> pitti: should i file a bug about it? (and if so, which package?)
<slangasek> pitti: those aren't the languages I selected. :)
<slangasek> meshuggene edge!
<pitti> Company: not sure whether it's doable with the GNU debug links in ELF; but file it against pkg-create-dbgsym for now
<pitti> thekorn: can I raise the default value of attempts=5?
<slangasek> ah, strangely it was showing me those languages because I wasn't logged in. errr?
<thekorn> pitti, no, unfortunatly not
<james_w> pitti: thekorn: http://bazaar.launchpad.net/~james-w/python-launchpad-bugs/urlerror-reason/revision/172
<james_w> that might make the error you are getting more clear
<pitti> oh!
<james_w> launchpad does like to refuse connection from time to time though, often with 502
<pitti> yesterday it worked like charm, and today it's so totally misbehaving
<LaserJock> cjwatson: is people.ubuntu.com/~cjwatson still the canonical branch for debian-cd in Ubuntu?
<pitti> thekorn: the network connection from ronne is utterly slow in general (don't know why), so that might contribute to it
<james_w> staging is also a single machine as I understand it
<thekorn> pitti, my problem right now is: I can't reproduce any of these bugs, so it is hard to debug
<pitti> thekorn: right, and I'm more and more convinced that it's not a p-lp-bugs problem anyway; thanks a lot for your help!
<thekorn> pitti, np, the problem of py-lp-bugs is that is such a hard to debug, non verbose, hackish beast... so thanks for using it ;)
<pitti> james_w: AttributeError: 'exceptions.AttributeError' object has no attribute 'reason'
<james_w> pitti: huh
<thekorn> AttributeError, wtf? - then it's py-lp-bugs
<james_w> that's my fault, sorry
<pitti> thekorn: it just tries whether e.code exists, if not, it's "unknown error"
<james_w> it overwrites the original error when it catches the AttributeError, should have seen that
<pitti> james_w: oh, of course
<pitti> james_w: I'll rename it
<james_w> fixed in my lp branch
<pitti> james_w: you just removed the ", e" in the inner except?
<pitti> right, now loggerhead caught up
<james_w> yup
 * pitti turns the crank again
<pitti> but I bet these are just ordinary LP timeouts
<Baby> pitti: I've made some modifications and added the man pages that were missing, I still don't know how to solve one of the lintian warnings with cdbs
<Baby> W: calibre: desktop-mimetype-without-update-call /usr/share/applications/lrfviewer.desktop
<pitti> Baby: ah, needs call of dh_desktop, I figure
<pitti> Baby: that'll cause postinst code to call update-desktop-database
<Baby> it should give the same error for calibre.desktop too, I guess
<Baby> in any case, with cdbs I don't have a clue where to put the dh_desktop
<pitti> Baby: should go into binary/calibre::
<pitti> I wonder why cdbs doesn't just call it
<pitti> Baby: ah, gnome.mk and kde4.mk call it automatically
<pitti> Baby: but the latter doesn't exist in Debian
<Baby> ah I see
<pitti> (and would be more appropriate for a Qt program)
<pitti> Baby: so please add
<pitti> binary-install/calibre::
<pitti>        dh_desktop
<pitti> that should do
<Baby> dh_desktop or dh_desktop -pcalibre ?
<pitti> Baby: right, your's
<pitti> aah
<pitti> launchpadbugs.exceptions.LaunchpadURLError:
<Baby> oki :)
<pitti>     * message: The read operation timed out
<pitti>     * url: https://bugs.launchpad.net/bugs/303022
<pitti> thekorn, james_w: ^
<ubottu> Launchpad bug 303022 in libjpeg6b "rhythmbox-metadata crashed with SIGSEGV in decompress_onepass()" [Undecided,New]
<pitti> thekorn: so not your fault :) but maybe merge james_w's branch, it's nice for debugging
<james_w> pitti: ouch
 * pitti hugs james_w
 * james_w hugs pitti
<james_w> no launchpad love for apport
 * thekorn hugs pitti , gottseidank
<thekorn> and james_w
<pitti> meh, I just finished the implementation for unbreakable-retracer, and now LP crashes underneath me...
<Baby> pitti: duploading
<Baby> shit, I did the debcommit before adding the new files
<pitti> thekorn: in a way I hoped it was something we could circumvent in p-lp-bugs; now I'm quite at loss :/
<thekorn> pitti, yeah, right :( seriously switch apport over to lplib, it is a lot faster these days, and maybe more stable
<thekorn> maybe I should start an apport branch
<pitti> thekorn: I guess that's what I'll have to do in the end
<pitti> thekorn: I just can't use it on the client side, since it insists on login credentials, but on the server side it should be quite alright
<slangasek> james_w: is there a sane way that we could make bzr builddeb automatically set a "right" -v option to dpkg-buildpackage when doing a merge from Debian via bzr?
<james_w> slangasek: it could guess, but it's not going to be reliable, so it's perhaps best not to rely on it
<slangasek> hmm
<james_w> at least I can't think of a reliable algorithm
 * slangasek nods
<thekorn> pitti, right, anonymous  "read-only" login would be cool
<james_w> it's easy to work out what the -v and -sa should be if you know it's a merge though
<slangasek> unfortunately, that means that presently I lose out on the benefit of MoM's auto-generated genchanges script for packages that I'm merging via bzr, and consequently often fail at passing the correct -v myself
<slangasek> james_w: so if there were an option like 'bzr builddeb --is-merge' or something?
<james_w> it could do it
<james_w> I'm leaning more to restructuring the way it works though, we keep hitting things like this *all the time*
<james_w> often there is nothing stopping you from just using debuild or whatever though
<slangasek> james_w: does debuild automatically exclude .bzr?
<slangasek> <-- lazy
<ScottK> lazy/trying to be efficient.
<james_w> slangasek: debuild does
<james_w> slangasek: I *think* dpkg-buildpackage might even now
<slangasek> ScottK: yes, laziness is a virtue, I didn't mean to imply anything different ;)
<ScottK> OK, just trying to clarify.
<pitti> slangasek: debuild -i
<pitti> slangasek: and -I.bzr for excluding them from built tarballs (native packages)
 * pitti uses alias debuild='debuild --preserve-envvar PATH -i -I.bzr -I.svn -I.shelf'
<superm1> pitti, environment variable form: DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps|\{arch\}|\.arch-ids|\.arch-inventory|\.bzr|\.bzrignore|\.shelf)(?:$|/)' -ICVS -I.svn -I\{arch\} -I.arch-ids -I.arch-inventory -I.bzr -I.bzrignore -I.shelf"
<superm1> someone posted that at some point
<slangasek> pitti: the part where I have to type extra options afterwards is the part that annoys me :)
<pitti> slangasek: which is why I'm using an alias :)
<slangasek> s/type/configure on all my systems/, then
<slangasek> if everyone agrees it's the only sensible thing to do, we should make it the default
<slangasek> we have the source ;)
<pitti> slangasek: well, you are in -core-dev, upload a fixed default :)
<pitti> (snap)
<tjaalton> I've noticed that dpkg-buildpackage no longer excludes .git in jaunty
<slangasek> I guess dpkg-buildpackage has no way to override a -i or -I option once set, though, so it's not the appropriate place to make the change?
<slangasek> (nor dpkg-source)
<pitti> thekorn: argh, while installing launchpadlib as normal user in a small development chroot, I appreciate how easy it is to use/install p-lp-bugs...
<pitti> thekorn: launchpadlib doesn't seem to work at all on ronne's restricted network access; bummer
<calc> cool the OOo bugwatch lp stuff got fixed today it seems
<calc> all of my bugs status got updated
<pitti> I got a flood, too
<pitti> good night everyone
 * pitti gives up and hopes that ronne will behave better tomorrow
<pochu> 'night pitti
<cjwatson> pitti: there's a sensible default now if you just say -I
<slangasek> cjwatson: passing that to dpkg-buildpackage?
<cjwatson> yes
<slangasek> \o/
<cjwatson> well, -i -I
 * slangasek nods
<cjwatson> LaserJock: yes
<LaserJock> cjwatson: k, thanks
<slangasek> kirkland: could you provide a transcript of a session showing bug #305882?
<ubottu> Launchpad bug 305882 in ecryptfs-utils "ecryptfs private wrapped passphrase with wrong password during password change" [Undecided,Confirmed] https://launchpad.net/bugs/305882
<slangasek> the description ("attempt to change", "actually change") is somewhat unclear to me
<kirkland> slangasek: sure, setting it up now
<kirkland> slangasek: hmm, i actually was unable to reproduce 305882, when trying just now ... i marked it "Incomplete", providing a transcript, and asking the reporter to do the same
<slangasek> ok :)
<kirkland> slangasek: my apologies for slinging blame :-)
<slangasek> oh, I don't doubt that we have other bugs there and I accept total blame for them - I just would like to not be trying to fix them blindly :-)
<kirkland> slangasek: fair enough!
#ubuntu-devel 2009-01-09
<NCommander> does anyone know a good hexeditor?
<directhex> bless?
<directhex> (no i don't know if it's any good, but it's installed on here)
<NCommander> is it graphical?
<directhex> yes. is that good or bad?
<NCommander> that's good
 * NCommander needs to write some MAGIC
<directhex> FANTASTIC MAGIC?
<directhex> christ on a bike, i should be in bed
<NCommander> PHOENIX magic ;-)
<directhex> i was busy watching the merriment in #u-motu
 * NCommander notes that trying to cook phoenix meat however is an attempt at futatility
<Hobbsee> directhex: yes, i'm sharpening my stick, just in case ;0
<StevenK> NCommander: If we follow Harry Potter mentality, there is no meat to cook
<NCommander> Hobbsee, do you have a specialized stick sharper, or just use a knife?
<directhex> if we follow the x-men mentality, it's canibalism!
<Hobbsee> NCommander: neither.  I use fire and diamond.
 * NCommander is reminded of some sorta crappy rap song ...
 * directhex gives up; sleeps
<Hobbsee> night directhex
<joe-mac> hi all, i've been desperately trying to get the partman-auto-raid functionality to work in preseeding. i discovered the partman-auto-raid udeb is not in the install tree. i basically just need to know at this point, how do you tell the debian installer to recognize a new udeb, without going through the process of building a whole new install tree?
<StevenK> anna-install or something similar
<TheMuso> Thats if the package metadata knows about the udeb in the first place.
<TheMuso> s/knows/has/
<joe-mac> Thanks for teh response guys, so TheMuso by package metadata you mean the Packages file for that tree under the pool?
<TheMuso> joe-mac: Yes, the file that stores all info about a package, its name, version, MD5sums etc.
<joe-mac> alright, i'll look into this anna-install, and add the package to the Packages file. i really hope that works... won't be able to tell til tomorrow morning, but thanks first glimmer of hope i've had all day
<calc> anyone happen to know the name of the wiki blueprint/spec template?
<persia> calc, https://wiki.ubuntu.com/SpecTemplate ?
<calc> ah yes that's it :)
<persia> For namespace conservation reasons, I'd advocate putting your result at https://wiki.ubuntu.com/Specs/${ camelcase(blueprint_name)}
<dholbach> good morning
<ion_> Howdy
<lukehasnoname> Morning
<roccity_> does any think that there may be a need for a user name generator in ubuntu
<roccity_> for corps and such?
<lukehasnoname> I don't know who would be responsible for this... by default, in .bashrc, the block that loads .bash_aliases if it exists is commented out. 1) Why is that? It seems pointless to have the code in there by default, the way it is designed, if you're going to comment it out. 2) Who could change this?
<roccity_> or is it best to leave that to the techs of the company
<pitti> Good morning
<StevenK> Morning pitti!
<persia> roccity_, Probably best to leave that to organisations: there's far too many different schemes in use.
<lukehasnoname> hm
<thekorn> pitti, hello, I created lp:~thekorn/apport/api.launchpadlib this morning, don't know if this makes sense at this stage, but it's working
<pitti> thekorn: cool!
<pitti> thekorn: unfortunately, as I said, I can't use launchpadlib from ronne (where the retracer lives) until its networking gets fixed
 * pitti hugs thekorn
<thekorn> pitti, yes, so get this networking fixed ;)
 * thekorn hugs pitti back
<fabbione> morning guys
<soren> o/
<fabbione> any archive admin around that could please process NEW for redhat-cluster in jaunty?
<fabbione> hi soren
<fabbione> soren: the last updates to libvirtd in hardy are crap. They overwrote my configurations
<fabbione> soren: got default network back again and all the machines that were supposed to autostart didn't because the autostart symlinks were purged
<doko__> lool: mbr tests fail on 32bit
<lool> doko__: I know; but only on the official buildds; not on my host nor on ppa buildds
<doko__> infinity: ^^^
<lool> doko__: You're welcome if you like to look into it; IIRC it fails in mmap() or something
<cjwatson> fabbione: done
<fabbione> cjwatson: thanks a lot
<lool> So I have an issue with autoreconf -fi in rpm; it ends up replacing po/Makefile.in.in with gettext's, but gettext's doesn't define top_builddir yet uses it
<lool> The build ends up failing not finding "/config.status" because of this target:
<lool> Makefile: Makefile.in.in Makevars $(top_builddir)/config.status @POMAKEFILEDEPS@
<lool> My understanding is that gettext's Makefile.in.in should have a top_builddir = @top_builddir@ snippet at the top
<lool> (e.g. intltool's does it)
<cjwatson> lool: top_builddir is set in Makevars
<cjwatson> or should be - it's in the template
<lool> Aha, after the autoreconf, there isn't the -# Makevars gets inserted here. (Don't remove this line!)
<lool> Ah there is, just saw the removal in the diff
<cjwatson> this can happen when you do gettextize and intltoolize in the wrong order
<cjwatson> (or similar)
<lool> cjwatson: I'm just running autoreconf -fi
<cjwatson> I bet that your po/Makefile.in.in is not really the one from gettext, but is rather the one from intltool
 * lool rekicks the build
<cjwatson> or is some other broken thing
<lool> cjwatson: Well the one from intltool sets top_builddir and this one doesn't
<cjwatson> intltool does because it doesn't have Makevars to do it
<lool> cjwatson: I see the Makevars line, but it doesn't get replaced with a top_builddir
<lool> cjwatson: Actually the line stays in Makefile
<lool> configure.ac has AM_GNU_GETTEXT_VERSION([0.11.2])
<lool> AM_GNU_GETTEXT([external])
<cjwatson> if the "inserted here" line is getting removed from Makefile.in.in, that would seem to be the problem ...
<lool> cjwatson: No it's not
<lool> cjwatson: It's still in the po/Makefile during the build
<cjwatson> but Makevars isn't?
<lool> cjwatson: I see vars, not sure whether these are the Makevars, but no top_builddir
<cjwatson> this source looks broken
<cjwatson> I think, actually, it's from a really old version of gettext
<lool> I see the sed in config.status
<cjwatson> and that attempting to autoreconf it with current tools is liable to blow up
<cjwatson> it needs a decent upstream
<lool> cjwatson: Ok; I wished to fix the FTBFS without going with a new upstream release
<lool> But it seems that's not easy
<cjwatson> have you tried using its autogen.sh (possibly fixing it to use --install where appropriate)?
<cjwatson> that doesn't run autopoint
<lool> Ok; will try that
<Keybuk> cjwatson: so I'm trying to decide whether I need to add Depends: udev to cope with the /etc->/lib transition
<Keybuk> what do you think?
<pitti> seb128: F9 to F11 started controlling volume/mute for me yesterday; do you get that as well?
<cjwatson> Keybuk: to what package?
<Keybuk> all of them
<lool> Keybuk: Did you see #314879 BTW
<Keybuk> none of the packages currently shipping udev rules have any form of dep on udev
<lool> I guess so, but when in doubt
<cjwatson> Keybuk: it seems more like udev Breaks: (everything else)
<Keybuk> which, given the rule files tendancy to change
<seb128> pitti: no but I didn't dist-upgrade yet
<cjwatson> Keybuk: pcmciautils Depends: udev
<seb128> pitti: that's not likely due to a GNOME change though, could be acpi or something?
<Keybuk> lool: no, but I suspect that has more to do with soren
<pitti> Keybuk: but for some packages it might even be justified to not depend on udev
<Keybuk> cjwatson: that's the one package I didn't touch :-)
<pitti> seb128: haven't looked into it at all yet
<lool> Keybuk: downgrading udev fixes it?!
<Keybuk> pitti: you can't not have udev in Ubuntu
<cjwatson> actually the new package definitely Breaks: udev (<< 136-1) surely?
<soren> Keybuk: What did I do now?
<Keybuk> soren: I mean that's what you're looking into, no?
<Keybuk> cjwatson: isn't Breaks the wrong way round?
<cjwatson> which seems like a more appropriate relation
<Keybuk> that deconfigures udev, rather than the package
<soren> Oh, right. I just saw my name mentioned and wasn't caught up on scollback :)
<cjwatson> Keybuk: in practice it forces udev to be upgraded :)
<Keybuk> that sounds sane then
<cjwatson> the alternative is putting Breaks in udev but I can see why you might find that painful to maintain
<Keybuk> hmm
<Keybuk> if I apt-get install one of these packages from jaunty onto intrepid
<Keybuk> will it upgrade udev?
<Keybuk> and if I dpkg -i one, will it complain about udev being too old?
<cjwatson> 1) yes provided apt has a source for the new udev 2) er not sure, worth a test
<Keybuk> hmm
<Keybuk>  installing libmtp8 would break udev, and
<Keybuk>  deconfiguration is not permitted
<Keybuk> if you follow its instruction, it "deconfigures" udev
<lool> soren: Oh you're chasing that boot on lvm udev issue?
<Keybuk> forcing that does complain that you need to upgrade udev
<lool> Keybuk: Did you notice a couple of conffiles show up as obsolete now?  You might want to rm_conffile them
<Keybuk> so other than the language, that looks ok
<Keybuk> lool: example?
<lool> Keybuk: In the bug report
<Keybuk> soren: we should use Breaks then
<Keybuk> lool: which report?
<lool> #314879
<StevenK> cjwatson: So, according to the ubuntu-mid build log, germinate is breaking due to libavcodec being pulled in -- from what I can see, nothing in the seeds should pull it in, could I bug you have a quick look when you can?
<lool> % dpkg-query -W -f='${Conffiles}' udev | grep obsolete /etc/udev/rules.d/05-udev-early.rules 01cc7968762a9a6590801ac94f585d44 obsolete /etc/udev/rules.d/66-persistent-storage-edd.rules 5dc9376604e2266886c6be1c7a467222 obsolete
<Keybuk> those are both very old rules
<Keybuk> 05-udev-early was rm'd in upgrade from feisty to gutsy
<soren> StevenK: Isn't that even blacklisted?
<Keybuk> I didn't think we ever shipped a 66-persistent-storage-edd.rules file
<StevenK> soren: It is blacklisted, which is why germinate is having a hissy fit
<Keybuk> that could have been from a PPA or something?
<cjwatson> the blacklist syntax is pretty crude which is why I discourage it for most purposes (libavcodec is one of the few sensible uses)
<cjwatson> StevenK: will do
<Keybuk> cjwatson: yup, this works
<Keybuk> where we don't have a Depend on udev, we should have a Breaks
<soren> Keybuk: I think I understand the reasoning, but it still looks a bit wierd that all those packages break udev, since it certainly feel sht other way around :)
<cjwatson> ? Package libavcodec51 blacklisted in ship-live but seeded in extra (mpeg4ip-server)
<cjwatson> is what the log says
<Keybuk> soren: all those packages Depend on udev, so it looks weird to me that they don't ;)
<cjwatson> soren: I agree that it's slightly twisty
<soren> Keybuk: Heh :)
<StevenK> cjwatson: Which doesn't exist in mobile.jaunty ...
<cjwatson> in general I do not particularly object to adding udev dependencies in Ubuntu, although respect the case where package maintainers don't want to
<cjwatson> StevenK: extra, by definition, is synthesised by germinate
 * Keybuk still doesn't buy this whole "but I might want to uninstall udev" nonsense
<Keybuk> it obviously makes sense in Debian
<cjwatson> exactly why it's showing up here I haven't figured out yet
<Keybuk> because there's a very good reason to want to uninstall udev in Debian
<Keybuk> but since Marco isn't an Ubuntu maintainer ...
<Keybuk> ;-)
<soren> Keybuk: What might that reason be? Do they still have devfs kernels or some such? Or are you thinking for embedded systems or something?
<cjwatson> I think this is argumentum ad hominem, actually ;-)
<directhex> against whom? d'itri?
<soren> cjwatson: Ah :)
<Mithrandir> udev in Debian generally works fine those days.
<soren> Ok, so the verdict is to add "breaks: udev (<< 136-1)", fix up the paths in the initramfs hook scripts, and nothing else? No dependency on udev?
<Keybuk> soren: if you have a dep on udev, increase it
<Keybuk> lvm needs it put back, I removed it by mistale
<soren> Right.
<Keybuk> I think mdadm should have a Dep too
<Keybuk> since it relies on udev these days
<Keybuk> devmapper needs a Breaks
<soren> Keybuk: lvm still needs the watershed dependency, right? It's gone from udev, AFAIUI?
<Keybuk> right
<Keybuk> after talking with Kay, we opted not to include watershed upstream because the only program that needs it is lvm and our opinion is that lvm is broken
<Keybuk> (lvm needs to grow incremental assembly support)
 * soren nodes
<soren> nods, even.
<lool> Keybuk: these conffiles show up on both of my jaunty systems; installed around gutsy I believe
<Keybuk> lool: *shrug* you upgrade through development releases and probably install test packages I make from time to time
<Keybuk> just rm them and delete the lines from status? :)
<lool> Are you confident they wont be there for regular users?
<Keybuk> yeah
<Keybuk> I've upgraded this machine only on major releases since warty, and they're not there
<lool> Ok, thanks
<cjwatson> StevenK: this is a very interesting little problem. :)
<StevenK> cjwatson: Heh
<cjwatson> I *think* it's a germinate bug
<soren> Keybuk: What if someone (for whatever reason) just installs the new udev (without updating all the other stuff)? That will obviously break, but do we care?
<Keybuk> it won't break
<Keybuk> well, not entirely true; it'll probably ignore some of the rules
<soren> It clearly breaks.
<soren> That's what that bug is about.
<soren> ..and that's why my laptop fails to boot.
<Keybuk> oh, that'll break, true
<Keybuk> upgrade lvm then ;)
<soren> A.k.a.: we don't care :)
<Keybuk> there's no way to express this kind of thing
<soren> Other than inverting the Breaks.
<Keybuk> you can't provide ABIs with dpkg, like you can in RPM
<Keybuk> I'm not having a Breaks in udev listing every single package that ships a udev rule
<Keybuk> that's insane
<soren> I agree.
<soren> But it's possible.
<soren> Just because it's possible doesn't mean we want to do it :)
<Keybuk> just thought
<Keybuk> dmsetup needs a Depend on udev
<cjwatson> you certainly can provide ABIs with dpkg; you can implement this kind of thing with Provides and a bit of creativity
<Keybuk> because it ships an initramfs-hook that assumes udev is installed
<Keybuk> cjwatson: not in a way that would help soren's problem
<Keybuk> well
<Keybuk> Provides: udev-abi-4
<soren> Not now, anyway.
<Keybuk> Conflicts: udev-abi-1, udev-abi-2, udev-abi-3
<soren> If we had done that from the start, sure.
<Keybuk> or maybe Breaks
<lool> I don't think it's insane to add Breaks in udev; we did add Conflicts in libgtk for all gtk 2.4.0 modules
<lool> And we added an ABI provides
<lool> Provides: gtk2.0-binver-2.10.0
<Keybuk> udev doesn't even have a stable ABI
<Keybuk> every package that ships a udev rule should depend on an exact version of udev
<Keybuk> but they don't
 * soren needs lunch
<Keybuk> after some playing around, it doesn't matter which way you put the Breaks
<Keybuk> the net effect is always the same
<Keybuk> if you put the Breaks on udev for lvm, you can't upgrade udev without breaking lvm
<Keybuk> but you can still upgrade lvm without upgrading udev (and hit the same bug from the opposite direction)
<Keybuk> it makes sense to me that the Breaks should be on the "lesser" package
<Keybuk> because people are more likely to backport backinstall those
<Keybuk> so if someone grabs the lvm from jaunty, they'll be forced to upgrade udev
<Keybuk> (which matches the and upgrade libc, etc.) pattern
<Keybuk> whereas people rarely backport udev ;)
<Keybuk> pitti: \o/
<Keybuk> devicekit (002-0ubuntu1) jaunty; urgency=low
<pitti> huzzah :)
<pitti> Keybuk: DK-power is now current as well
<ion_> Yay
<Keybuk> I saw
<ion_> Why 002 instead of, say, 2?
<pitti> I think I properly udevified it, please yell at me if not
<Keybuk> ion_: upstream version number scheme
<pitti> ion_: *shrug* I just took what upstream used
<Keybuk> pitti: question about sane-backends
<Keybuk> why did you remove the code to create the scanner group?
<pitti> Keybuk: because we don't install the udev rule any more, and thus we don't need it in sane-utils
<Keybuk> but the very next line of the postinst assumes the scanner group exists
<Keybuk> and tries to add the user to it
<pitti> !
<pitti> which user?
<Keybuk>     # Create saned user/group if they do not exist
<Keybuk>     if ! getent passwd | grep -q "^saned:"; then
<Keybuk>         echo "Adding saned group and user..."
<Keybuk>         adduser --quiet --system --no-create-home --group saned || true
<Keybuk>     fi
<pitti> argh
<pitti> saned
<Keybuk>     if [ "$SANED_IN_SCANNER" = "true" ]; then
<Keybuk>         adduser --quiet saned scanner
<Keybuk>     else
<Keybuk>         if id saned | grep -q "groups=.*\(scanner\)"; then
<Keybuk>             deluser --quiet saned scanner
<Keybuk>         fi
<Keybuk>     fi
<Keybuk> SANED_IN_SCANNER would appear to be true
<pitti> Keybuk: merge error then, thanks for spotting
<liw> hm, piuparts should catch that kind of error
<Keybuk> we don't put anything in scanner anymore, so it's utterly pointless
<Keybuk> so maybe just remove that bit? :)
<pitti> Keybuk: hm, then saned would not work at all
<Keybuk> why wouldn't it?
<pitti> because it can't access the device?
<pitti> (it's a daemon)
<Keybuk> hmm
<Keybuk> but there's no scanner group anymore ;)
<pitti> right, and it's broken either way
<pitti> just pondering whether we want to do anythign to unbreak it
<Keybuk> well, unbreaking the postinst would be nice ;P
<pitti> Keybuk: do you happen to have some time to do that? I'm in quite a time crunch ATM
<Keybuk> I can add it to my todo
<pitti> trying to get some stuff sorted before I leave tomorrow 6 am for a week..
<Keybuk> np
<pitti> Keybuk: appreciated, thanks
<phix> hey
<dholbach> can somebody massage the ubuntu-devel-announce@ queue? :)
<cjwatson> dholbach: done
<dholbach> cjwatson: gracias!
<Laibsch> Hi
<Laibsch> Can somebody please upload my patch from bug 254228 to intrepid-proposed?  It fixes a quite serious error in sqlite3
<ubottu> Launchpad bug 254228 in sqlite3 "division error in sqlite 3.5.9-5" [High,In progress] https://launchpad.net/bugs/254228
<stefanlsd> lool: still getting that magick/api.h: No such file or directory for imview with new imagemagick
<ogra> tjaalton, any hint for me how to handle evtouch to get it building again ? is there any replacement for xf86Version.h ?
<StevenK> cjwatson: Any news about my germinate issue before I scamper off to bed?
<Laney> slangasek: <slomo> gnome-sharp2 first needs gnome-desktop-sharp2 to be packaged
<tjaalton> ogra: nope, dropping that include doesn't help (it's not needed anymore)
<ogra> well, its one of the issues
<ogra> i understood that there was a evtouch version in experimental, but i seem unable to find it
<ogra> i was hoping that builds
<tjaalton> there isn't
<ogra> weird ... soeone said the new upstrem version was there
<cjwatson> StevenK: oh, sorry, I was working on it and got distracted by ext4 stuff. One minute
<tjaalton> ogra: I doubt 0.8.8 works any better
<cjwatson> StevenK: ok, the last seed in STRUCTURE is special, as documented in germinate(1)
<ogra> yeah, it just includes my changes actually
<cjwatson> StevenK: so ship-live was getting all the build-dependencies added to it which was kind of bad
<ogra> but i would like to get it building
<cjwatson> StevenK: I'll fix the seeds
<cjwatson> coo, ext4 resizing in the installer even works
<StevenK> cjwatson: Okay, cool. Thanks. :-)
<cjwatson> StevenK: (done)
<ogra> cjwatson, btw i think ted mentioned in his ext4 talk that you shouldnt expect the performance gains with a converted ext3->4 fs
<ogra> (you didnt mention that in your mail)
<cjwatson> no, feel free
<cjwatson> I didn't have the reference so didn't want to shoot my mouth off based on hearsay
<ogra> yeah, i only remember it vaguely either from the talk
<ogra> no details in my head
<cjwatson> I would have expected that to be because existing files aren't converted to extents
<ogra> yeah
<Keybuk> soren: ugh, you unequivocally just remove the old udev rules?
<Keybuk> you should almost certainly check whether or not the user has modified them first
<Keybuk> soren: devmapper needs the b-d of debhelper increasing to pick up the new udev behaviour
<soren> Keybuk: I remove the old udev rules?
<soren> Keybuk: Oh, because of debhelper putting them in a different place?
<Keybuk> soren: it looks like it, in the preinst?
<Keybuk> in lvm2/mdadm?
<soren> I haven't touched maintainer scripts at all.
<Keybuk> uploaded devmapper with fixed b-d
<soren> I don't see why it's needed, to be honest.
<Keybuk> well
<Keybuk> if I download this source and build it
<Keybuk> but don't update devmapper
<Keybuk> it'll be a *different* package to the one on the buildds
<soren> "this source"?
<Keybuk> devmapper 2:1.0.27-4ubuntu2
<soren> If you download devmapper and build it, but don't update it?
<Keybuk> if I build this as-is, but don't update *debhelper* (I keep doing that! :p)
<soren> Go on, it might sink it at some point :)
<soren> Ah.
<Keybuk> then I'll have a different package
<Keybuk> it will have different contents
<Keybuk> you could claim that's desired
<soren> Yes.
<Keybuk> *except* the contents won't match the initramfs hook in the package
<soren> Ah.
<Keybuk> so update-initramfs will fail because /lib/udev/rules.d/blahblahblah won't exist
<soren> That's a good point.
<Keybuk> the only justification I can think of for not always bumping build-dependencies is to make backporting less painful
<Keybuk> but I honestly think that the pain is a feature here
<soren> *nod*, but only due to the initramfs hooks.
<soren> Oh, wait.
<Keybuk> I think package contents and maintainer scripts being different if you build it two different ways is a bug
<soren> if the user has put rules in /etc/udev/rules.d to override something... Shouldn't we be putting those in initramfs, too?
<Keybuk> I could switch to a chroot, do dpkg-buildpackage *and never realise* that I had to update debhelper
<Keybuk> soren: honestly?
<Keybuk> no :)
<Keybuk> there's so many things we don't copy into initramfs right now
<soren> That's true, but this could be a regression for some people.
<soren> If they have local changes in the lvm rules, they will be used to having them in initramfs, but that will no longer be the case.
<soren> I can't imagine what they'd be doing in there, but still.
<Keybuk> the whole point of the move to /lib is to *stop* people making local changes to these things
<Keybuk> if you can find someone legitimately doing it, then we'll work out how to make it so they don't need to :p
<lool> stefanlsd: I didn't get that in my ppa, but it's probably because it sees main/universe stuff
<lool> stefanlsd: is this with the current jaunty version or a new one?
<soren> Keybuk: I see your point.
<soren> Keybuk: To get back to the chroot case for a minute..
<stefanlsd> lool: one coming in from debian. 1.1.9c
<soren> Keybuk: I'm still not completely convinced. The versioned dependency (be it explicit or not) is really between debhelper and udev.
<lool> stefanlsd: Ok, then your issue is a different one I would guess; did you diff the configure.in changes?  Can you hand me a .dsc to look at?
<lool> http://ftp.debian.org/debian/pool/main/i/imview/imview_1.1.9c-3.dsc?
<Keybuk> soren: no it's not
<Keybuk> debhelper is a package build tool
<soren> Keybuk: debhelper is the one changing incompatibly
<soren> Keybuk: I realise.
<Keybuk> debhelper is a short-cut for not doing stuff in debian/rules itself
<soren> That's why I said earlier that there really is no sane way to express this relationship.
<lool> stefanlsd: Right, as I suspected there are changes in the configure.in
<stefanlsd> lool: yeah. thats it. I just did get it to compile by uncommenting line 769 of configure.in
<lool> -                       CPPFLAGS="$CPPFLAGS "`pkg-config ImageMagick --cflags`
<lool> +                        MAGICKNAME=$(pkg-config ImageMagick --libs-only-l | sed 's/-l//')
<lool> This is really scary
<Keybuk> right, we don't _really_ have this kind of flexibility
<soren> Keybuk: short of having dh_installdev add a versioned udev dependency to ${misc:Depends} or something.
<Keybuk> but as long as you're always moving forwards, things tend to work out :)
<stefanlsd> so essentially CPPFLAGS="$CPPFLAGS "`Magick-config --cppflags`
<lool> stefanlsd: The configure changes are crackful; they shouldn't be using AC_CHECK_LIB manually with pkg-config calls at the other end of the configure.in
<soren> s/dh_installdev/dh_installudev/ obviously.
<lool> stefanlsd: The configure.in might use AC_CHECK_LIB for compat with very old imagemagick, but I'd recommend simply using PKG_CHECK_MODULES unconditionally
<soren> Keybuk: I feel this discussion is really about choosing the lesser of a number of evils. I see the argument for a versioned b-d on debhelper, certainly. I just wasn't completely convinced by it.
<Keybuk> soren: when I was considering dpkg2, one of my ideas was to take versioned dependencies away again
<soren> OTOH, I'm not insistant against it.
<Keybuk> because they don't actually work in practice
<lool> stefanlsd: Search for Imagemagick in xine-lib's configure.ac for an example; it's not perfect style but it's good enough
<Keybuk> in reality, you want something more like .so versions
<cjwatson> versioned deps are good for some things but not others
<cjwatson> in many cases feature dependencies would be more appropriate, but I'm not sure "many" = "all"
<Keybuk> cjwatson: possibly
 * soren concurs with cjwatson
<Keybuk> there may be situations where they are equally appropriate
<lool> stefanlsd: Is that good enough to get you going?
<Keybuk> it'd be an interesting exercise to think of situations where they are less appropriate
<cjwatson> I've worked with a system where we only had feature dependencies; it wasn't that they were *inappropriate*, but they were kind of cumbersome sometimes
<cjwatson> if it was just for one-off things it was cumbersome; for anything complicated it was great
<Keybuk> the problem with versioned dependencies is you tend to do:
<Keybuk>   Depend: foo (>= whatever-version-I-need)
<cjwatson> a system that supported both would be the best of both worlds, in my mind
<Keybuk> which will always shoot you in the foot if a later version of foo isn't compatible
<Keybuk> and you can't go back in time and undo it
<Keybuk> but then in practice, the dpkg/apt world is always moving forwards
<Keybuk> you move from 8.04 to 8.10 to 9.04
<cjwatson> for udev, that's a very valid concern, but there are plenty of other situations where it's not a problem
<Keybuk> so as long as you stay in that direction, things work out
<cjwatson> and yes, indeed
<Keybuk> cjwatson: all library packages too ;)
<Keybuk> debhelper, cdbs, other build-tools as well
<soren> There's really very little about the package relationships that is in any way guaranteed to be true forever.
<cjwatson> if the reason for your dependency is that you need a feature, you want to depend on the presence of a feature
<cjwatson> if the reason for your dependency is that previous versions were screwed, then it's often a bit too cumbersome to define a feature "not-screwed-any-more"
<cjwatson> bugs will always screw you over ...
<Keybuk> hmm, true
<Keybuk> depending on a version with a known bugfix is compelling
<lool> And then you can also conditionalize which features you want to build in this package and which features in other packages this requires and we have combinatory explosion and useless packages  \o/
<stefanlsd> lool: not a configure expert, but i'll give it a try. thanks!
<Keybuk> lool: we have that now ;)
<cjwatson> lool: oh, I'm not arguing for USE flags!
<Keybuk> "oh, no, that's _only_ a Recommends" *argh*
<lool> erf
<lool> cjwatson: It was too tempting to bend the discussion   :-P
<Keybuk> conary has a kinda cute feature
<Keybuk> for lack of a better term, packages can have flavours
<Keybuk> so you can have foo-with-gnome or foo-with-kde or just foo-with-gtk
<lool> stefanlsd: if you don't manage, I'm happy to try to hepl
<stefanlsd> lool: thanks a lot.
<Mithrandir> lool: sorry about sucking utterly; I have merged your pkg-config stuff, but haven't gotten around to writing up a changelog for it yet.
<doko> pitti, calc: please could you get OOo building today, so that we can include it in the next alpha?
<lool> Mithrandir: Cool, thanks
<pitti> calc: depwaiting on libstlport4.6-dev; can we please build it against libstlport5.1-dev and MIR that?
<lool> Mithrandir: The two things I'd care about after that would be 1) an opinion on using new flags instead of changing the semantics of requires.private and 2) pushing whatever the resulting pkg-config is to Debian/Ubuntu  ;-)
<Keybuk>     Definition Status: Discussion => Drafting
<Keybuk> erp
<Keybuk> lool: I didn't attend that because I thought we'd agreed it was a Bad Idea(tm)
<Keybuk> is that back on the cards
<lool> Keybuk: Assuming you mean squashfs-initrd?  It basically was an idea thrown on IRC which ended up with "Let's discuss it at UDS" for some reason, but with absolutely nobody clueful enough to comment on the feasibility and benefit; the idea was that if you mount a filesystem instead of decompressing a full initramfs you can immediately start running its contents without reading it in full; also it made the thing a tiny bit smaller, but that's uninte
<cjwatson> cut off at "uninte", in case there was more after that than just "resting"
<cjwatson> splitlong.pl++
<Mithrandir> lool: /script load splitlong.pl :-)
<lool> No, just "uninteresting"; thanks for the notice
<lool> Mithrandir: thanks :)
<pitti> seb128: gdm-upgrade spec reviewed, needs some clarification
<seb128> pitti: ok, I noticed that tedg was set a drafter btw, should that be changed?
<Keybuk> I now have images of lool in a corset
<pitti> seb128: if you are happy with drafting it further, sure
<lool> Mithrandir: The plugin doesn't seem to set splitlong_max_length; which value did you set it to?
<seb128> pitti: well I didn't notice that tedg was set as drafter before updating the wiki and changing the blueprint then
<Mithrandir> lool: it's 512 by default, I think.
<lool> Thanks
<Mithrandir> lool: I've never explicitly configured it, but it seems to work for me anyway.
<seb128> pitti: I'm fine editing the spec, I'm not sure about the autologin thing though, that's not something available in ubuntu right now, do you know what team is working on that?
<lool> Oh right there's a default at another place in the script
<lool> $maxlength = 497 - length($server->{nick} . $server->{userhost} . $target);
<lool> Keybuk: Assuming you mean squashfs-initrd?  It basically was an idea thrown on IRC which ended up with "Let's discuss it at UDS" for some reason, but with absolutely nobody clueful enough to comment on the feasibility and benefit; the idea was that if you mount a filesystem instead of decompressing a full initramfs you can immediately start running its contents without reading it in full; also it made the thing a tiny bit smaller, but that's ...
<lool> ... uninteresting
<lool> Works a charm
<lool> Keybuk: I understand from your vision of me in a corset that you don't think that makes any difference?
<liw> mvo, I've edited https://wiki.ubuntu.com/FoundationsTeam/Specs/JauntyCruftRemover -- when you have time, I'd like feedback
<Keybuk> Rocky Horror, innit
<Keybuk> Shiver with anticip
<Keybuk> ation
<lool> Keybuk: ?
<Keybuk> lool: NM :)
<Keybuk> in summary:
<Keybuk> - you can compress an initrd with whatever you like, provided the kernel has built-in support for mounting it
<Keybuk> - initrd is a filesystem
<Keybuk> - initramfs is a compressed cpio file, tagged onto the end of the kernel
<Keybuk> - initrd and initramfs are used at *different points* of the kernel boot process
<Keybuk> (effectively an initrd is used instead of the real root, whereas an initramfs is used instead of much of the kernel's init procedure)
<lool> So far I understood all of that
<Keybuk> the initrd has to be loaded into a ramdisk,
<Keybuk> the metadata examined,
<Keybuk> and it has to be mounted
<Keybuk> that takes X seconds
<Keybuk> the initramfs only has to be uncompressed into a tmpfs
<Keybuk> that takes Y seconds
<Keybuk> I'm not sure anyone's done practical timings of the difference between X and Y
<Keybuk> especially since with the initramfs, Z seconds of kernel code is omitted
<lool> I guess since the bootloader will always load them in full, it probably doesn't make a big one
<Keybuk> it wouldn't surprise me if the speed benefit of not decompressing it first
<Keybuk> is outweight by the fact you have to decompress it all anyway
<Keybuk> and I can't imagine you're talking more than ms difference
<lool> Ok; also I understand we try to get rid of the initramfs completely in jaunty
<lool> How will that work for lvm?
<calc> pitti: already got another build going just have to test the resulting debs this morning before upload
<calc> pitti: and i disabled stlport entirely in it
<pitti> ah, good
<pitti> calc: so the two java libs are the only remaining blockers now?
<calc> pitti: yes afaik
<pitti> calc: ok, I'll promote them to main now and make the bug jaunty blockers, so that the libs get fixed in time
<calc> pitti: ok
<calc> pitti: i'll get the new OOo build uploaded in a few hours, i have to test then it takes around 1.5-2 hr to upload due to my 512kbps upload rate
<Keybuk> lool: if you use LVM, you need to use the initramfs
<pitti> calc: hm, xom is FTBFS
<calc> pitti: yea very strange issue with that one, it worked on my machine then FTBFS when uploaded
<doko> pitti, calc: can we get the OOo related MIR's resolved today? and OOo 3.0 included for alpha-3?
<pitti> calc: I gave it back, just for fun, and promote the old binaries for now (ugh)
<calc> pitti: ok
<pitti> doko: probably not resolved, but tentatively promoted already (just doing)
<calc> doko: well trying the xom FTBFS is very odd at least to me, heh
<calc> doko: but since pitti is just promoting it regardless it should work
<mvo> liw: I have a look
 * calc installing the packages now to see if they blow up still
<doko> mvo: for alpha-3: Notify Michael Vogt to perform a GnomeAppInstallDesktopDatabaseUpdate
<doko> pitti: for alpha-3: Discuss with Desktop team and MartinPitt whether or not to re-enable apport by default.
<pitti> doko: currently enabled now; retracers for jaunty don't work, though
<pitti> doko: I'd say we leave it enabled, and if seb128 drowns in the unprocessed flood, we'll disable it again
<pitti> calc: failed again, hm
<seb128> pitti: if we have no retracers I would disable it, we will just collect bugs which will not be retracable when we restart those anyway, jaunty change quickly so versions will be outdated
<pitti> seb128: okay, I'll disable it; I'm still unable to work around the lp timeout
<pitti> seb128: I'll play with them a bit more, and if I fail, I'll upload a new apport this evening
<seb128> pitti: lpi is broken too, the IRC bot tends to timeout when being asked for bugs, I think that's a launchpad isue
<pitti> seb128: I just wonder why it doesn't affect intrepid crash reports
<seb128> that's weird indeed
<soc> hi
<soc> has that recent openssl/libssl update changed how key unlocking works?
<soc> because since that update, i can't unlock my ssh keys anymore
<seb128> soc: gnome-keyring got updated
<soc> ah nice to know
<soc> and because of that my keys stop working?
<soc> i don't really want to sound angry :-)
<doko> calc: xom doesn't build with gcj either
<sconklin> can anyone point me to a description of the operating environment for init scripts (intrepid)? I'm having a problem that appears to be related to forking and the available file descriptors.
<Keybuk> there is no guaranteed operating environment
<mvo> doko: thanks
<calc> doko: for some reason it built on my machine both times before i uploaded but then failed on the buildd, not sure why it worked on mine and failed on the buildd though
<sconklin> not even for file descriptors 0-2?
<Keybuk> not even for them
<sconklin> sigh. Thanks
<Keybuk> this is one of the bugs that Upstart is intended to address
<Keybuk> (it goes out of its way to ensure every job gets a guaranteed environment)
<sconklin> Then I vote for that.
<kees> Keybuk, soren: so, the new udev rules path... does mdadm need to be fixed too?
<Keybuk> kees: mdadm should be fixed?
<kees> Keybuk: that's what I'm asking.  :)
<Keybuk> no, I mean it should _already_ be fixed, are you disagreeing?
<kees> oh! okay, cool, nm then.  :)
<kees> also, where should the *persistent* .rules files live?
<Keybuk> /etc
<kees> in /etc/udev/rules.d ?
<Keybuk> yes
<kees> okay
<kwwii> seb128: do you know which package the default cursor theme is in?
<kwwii> seb128: I looked in xcursor-themes but it is not in there
<ogra> isnt that dmz-cursor-theme ?
<kwwii> ogra: yes, it is and unfortunately they are all in cursor forrmat
<ogra> even in the source package ?
<ogra> thats bad
<kwwii> ogra: in that package there are only x11 cursor files, and I can#t find another package with any source for it
<ogra> evil
<ogra> though arent there tools to convert cursor files to png ?
<ogra> and back
<kwwii> no, not that I can find...I did find the sources though
<kwwii> on jimmacs website
<seb128> no idea about those
<seb128> soc: could be bug #315398
<ubottu> Launchpad bug 315398 in gnome-keyring "ssh key renamed (possibly) after upgrade" [Low,New] https://launchpad.net/bugs/315398
<seb128> soc: though you mentionned ssl but not ssh before?
<james_w> what's the replacement for "update-modules"?
<calc> ok upload now in process
<kees> Keybuk: out of curiosity, why the dh bump in lvm2?
<soc> seb: yes, i can't unlock my ssh key anymore
<Keybuk> kees: because it uses dh_installudev
<Keybuk> so needs the bump to install the rules in the right place
<Keybuk> otherwise you could build it with a version of dh_installudev that still puts the rules in /etc
<kees> hah, okay
<seb128> kees: hi
<kees> heya seb128
<seb128> kees: did you send your libtop patch upstream after uploading it to jaunty?
<kees> seb128: do you have the bug# handy?  (I don't presently remember)
<seb128> kees: you uploaded a change some weeks ago to fix a leak which were create issue in the system monitor applet
<seb128> let me get the bug number
<seb128> kees: bug #307472
<ubottu> Launchpad bug 307472 in libgtop2 "multiload-applet-2 leaks memory" [Medium,Fix released] https://launchpad.net/bugs/307472
<seb128> kees: https://edge.launchpad.net/ubuntu/+source/libgtop2/2.24.0-0ubuntu3
<kees> seb128: no, I did it as part of my sponsorship workflow, so I didn't file an upstream bug
<seb128> kees: not sure if you know but we try to follow https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines too and make sure we send fixes upstream for desktop changes ;-)
 * kees nods
<seb128> kees: anyway would be nice if you could bugzilla it, thanks!
<kees> I haven't gotten into the habit of requiring that from sponsorees yet
<seb128> since you did the upload I think it's fair you do the forwarding too ;-)
<seb128> well, either we request and we forward the patch for them
<kees> sure, it might result in a gnome patch that isn't ignored
<seb128> hehe
<kees> seb128: btw, do you think that qualifies as SRU material?
<seb128> could be
<seb128> but we didn't get many complain about it and intrepid is not a lts so I'm not sure I would bother
<seb128> I don't think many people do disk monitoring but maybe that's a wrong impression
 * kees nods
<seb128> I usually have network and cpu monitors on my config
<seb128> anyway if you want to do the sru feel free
<kees> seb128: looks like it's already upstream http://bugzilla.gnome.org/show_bug.cgi?id=566611
<ubottu> Gnome bug 566611 in linux "Potential leak in fsusage.c" [Normal,Resolved: fixed]
<seb128> kees: ah good, it was not when you uploaded, I just had this on my list since before the holidays and I didn't check again ;-)
<kees> seb128: cool, yeah
<soren> Keybuk: Your watershed 2 package is vapourware so far.. :/
<Keybuk> heh]
<Keybuk> but I committed it!
<Keybuk> and I tagged it!
<soren> Good for you :)
<Keybuk> uploaded
<soren> For me (and my builds), less so :)
 * Keybuk so wants build-from-tag
<soren> Ta.
 * soren takes a break
<Keybuk> bzr tag --for ubuntu 136-2
<ubottu> Ubuntu bug 136 in baz "baz logs and baz cat-log only work in working tree" [Medium,Invalid] https://launchpad.net/bugs/136
 * Keybuk hands ubottu a cup of FAIL
<kees> hm, can an archive admin accept zsnes into -proposed?
 * directhex puts snes9x there instead, hopes nobody notices
<pitti> kees: done
<Keybuk> cjwatson: you've not uploaded pcmciautils yet, right?
<kees> pitti: thanks!
<kees> pitti: actually, I've got one more: dosemu, which will show up in about 2 minutes
 * pitti boggles
<pitti> seb128: I don't believe it, but using the change-a-thing-and-document it, I found the difference for the lp timeouts
<pitti> seb128: downgrading python-apt to intrepid in the jaunty chroot makes the LP timeouts go away; likewise, upgrading p-apt in the intrepid chroot makes them appear
<pitti> W. T. F. ?
<pitti> thekorn_: ^ FYI
<seb128> pitti: weird
<seb128> pitti: several users commented about getting timeout using apport too in jaunty btw
<pitti> seb128: which kind of timeout?
<pitti> seb128: when uploading reports, timeout displayed in LP in the browser?
 * pitti pins python-apt to intrepid for now and tests the real thing
<seb128> pitti: wait, I'm looking if I find the bug
<seb128> pitti: I don't find it right now
<seb128> pitti: but we asked on some crash to use apport to send the crash and the user replied that was not working but timeouting
<bluefoxicy> okay, hold it.
<seb128> pitti: that's bug #311690 rather
<ubottu> Launchpad bug 311690 in launchpad-foundations "Delay between blob submission and blob availability causes Launchpad to OOPS." [High,In progress] https://launchpad.net/bugs/311690
<bluefoxicy> Mem:   3797552k total,  3746448k used,    51104k free,   101104k buffers
<bluefoxicy> Swap:   787072k total,   786396k used,      676k free,   346060k cached
<pitti> seb128: right, but that's even something else
<pitti> seb128: I saw that
<seb128> right
<pitti> seb128: loading the page again after some seconds works
<bluefoxicy> 3.5G + .75G used?
<bluefoxicy> 11271 bluefox   20   0 1638m 945m  11m S    0 25.5  36:17.50 nautilus
<bluefoxicy> 11594 bluefox   20   0 1175m 674m  19m S   12 18.2   7177:05 firefox
<bluefoxicy> When you guys get done discussing real business, somebody /msg me how to figure this one out, because I  don't even know where to begin filing a bug for this that isn't too vague to matter
<bluefoxicy> (WTF nautilus!?)
<seb128> bluefoxicy: try to find how to trigger it and run those under valgrind
<seb128> bluefoxicy: could be some image you loaded which created the issue for example
<bluefoxicy> seb128: firefox is like this all the time
 * pitti hugs seb128, thekorn, and everyone
 * seb128 hugs pitti
<pitti> IT'S WORKING!!!!!!
 * pitti jumps for joy
<bluefoxicy> nautilus may be a bit iffy after browsing my porn directory; I can only hypothesize the most likely cause involves generating thumbnails for videos
<bluefoxicy> however
<bluefoxicy> clearing it requires killing nautilus
<bluefoxicy> 7ffffc89e000-7ffffc8ba000 rwxp 7ffffffe3000 00:00 0                      [stack] <--- LOVELY
<bluefoxicy> rwx?
<pitti> mvo: so, any idea why jaunty's python-apt causes Launchpad bugs to timeout through python-launchpad-bugs? :-)
<pitti> mvo: (that's veeery high on my list of "weirdest bugs ever")
<mvo> pitti: uh, first time I hear about that
<mvo> pitti: d yo uhave more details?
<mvo> pitti: is there any sort of proxy involved?
<pitti> mvo: not yet, it just took me 2.5 days to find that in the first place...
<mvo> pitti: or a way for me to reproduce it?
<pitti> but I have no idea what p-apt and p-lp-bugs have in common
<pitti> mvo: I have a reproducer in the retracer chroots, I'll try to come up with a very small one which works "at home"
<pitti> mvo: anyway, it was really just a teaser, not "plzfixitnow" :)
 * pitti hugs mvo
<mvo> pitti: hrm, damm. that means I need to back to finish spec reviewing? :P
<mvo> pitti: it sounds definitely quite mysterious (especially now that I understand that its LP itself that times out)
<bluefoxicy> can anyone tell me what /usr/lib/libgmp.so.3.4.2 does?
<bluefoxicy> and why it needs an executable stack?
<cjwatson> Keybuk: oh, sorry, no, needed to upgrade to new udev so I could test it
<pitti> mvo: ok, the reproducer works locally, too; do you want that in a bug report?
<pitti> mvo: (or at all?)
<maxb> bluefoxicy: "dpkg -S /usr/lib/libgmp.so.3.4.2" --> tells you it comes from the libgmp3c2 package. "dpkg -p libgmp3c2" --> tells you about the package
<ogra> and http://gmplib.org/ tells you what it is
<bluefoxicy> maxb:  thanks, that's more useful than google :)
<mvo> pitti: please, I would love to have a look at this
<pitti> mvo: bug 315571 now contains everything I know about this bug
<ubottu> Launchpad bug 315571 in python-apt "[jaunty] causes random Launchpad timeouts with python-apport" [Undecided,New] https://launchpad.net/bugs/315571
<pitti> mvo: can you quickly try the reproducer? it's just an one-line copy&paste shell command
<Keybuk> packages that build-conflict their own binaries are UNHELPFUL
<directhex> Keybuk, but sometimes inevitable
<directhex> i think mythtv does this
<Keybuk> glibc should do it
<Keybuk> just to explain to everyone why it's wrong
<LaserJock> cjwatson: can I have mixed Universe and Main seeds in a "seed pod"? I'm wondering if that creates component mismatches
<cjwatson> err. worldview clash
<cjwatson> you're asking a question whose terms will be undefined in the new world order
<cjwatson> or are you not talking about archive-reorganisation?
<LaserJock> I'm not, no
<cjwatson> oh
<LaserJock> I'm talking for today
<cjwatson> which seed collection are you talking about?
<LaserJock> Edubuntu
<LaserJock> we'd like to make some metapackages for Universe
<LaserJock> and I'm wondering if we should split that out into a different bzr branch
<cjwatson> if you put packages into the Edubuntu seed collection, they will be flagged for promotion to main
<cjwatson> you can create another branch that inherits from edubuntu.jaunty
<cjwatson> that's probably the correct approach
<LaserJock> cjwatson: is there a reasonable ETA on archive-reorganisation? i.e. "it's gonna happen for Jaunty"?
<cjwatson> blocked on LP feature, call due next week to try to figure out what to do
<cjwatson> in short, no
<LaserJock> when we have that reorganization is there going to be a way to distinguish between Universe and Main-type packages within a project?
<LaserJock> would we have to like create two different seed pods (can't remember what the adopted term was)
<cjwatson> I think that will become easier
<cjwatson> although I do not have the precise layout yet
 * ScottK thinks about it and gets a headache.
<jpds> LaserJock: lobe I think.
<LaserJock> what we're shooting for it to be able to define a "fully supported" core set of app but also have a "best effort support" app selection
<cjwatson> LaserJock: remember that in the new world order there is no universe
<LaserJock> I know
<LaserJock> but we want to make our own, essentially
<cjwatson> LaserJock: so it's a lot easier to just say "we're supporting these bits"
<LaserJock> "Education" is such a broad category with such a wide range in software/package quality that we would like to define a core set
<cjwatson> I think it will probably involve two different seed collections since you might well want to have different access control associated with them, but that that will not be a big deal
<LaserJock> ok, cool
<cjwatson> also, if you want to make it be just one seed collection and have only one ACL, I don't think that should be a problem either
<cjwatson> but I still need to work my way through the UDS session video and update the spec properly
<LaserJock> well, I think we may want to have different ACLs
<cjwatson> I think there is a bijection between seed collections and ACLs
<cjwatson> one seed collection defines one package set which is given an ACL in LP
<cjwatson> or thereabouts
<LaserJock> right
<cjwatson> actually that isn't quite true given overlaps but you get the general idea
<LaserJock> how is Canonical then going to define what it supports? will that be independent of seeds?
<cjwatson> I don't see any reason why we would put all this effort into a more expressive infrastructure only to not use it to define what we support :-)
<RainCT> (if someone answered my question, please repeat the answer.. irssi reconnected)
<cjwatson> there has been some talk of something like supported-by: canonical in Packages, and I think we'll probably end up with something along those lines though probably not quite
<ScottK-desktop> RainCT: I don't think we got a question from you.
<cjwatson> I would like to get to the point where synaptic/gnome-app-install can display icons indicating a package's support status, analogous to the current main/universe display
<cjwatson> but for that to not require physically separate Packages files
<cjwatson> we may need pdiffs for this to be sane
<RainCT> evil network-manager..
<LaserJock> right
<RainCT> Btw, what will happen with MOTU? Will it still have the same powers as now, or will applying to additional teams (or requesting sponsorship from them) be necessary in order to upload packages maintained by certain teams?
<cjwatson> err the detailed answer to that question changes every time I look
<RainCT> lol
<LaserJock> I really wish g-a-i wouldn't used "Canonical-maintained applications" for Main, kinda makes me sad :(
<cjwatson> there is no intention to disband MOTU or anything
<cjwatson> (I suspect if there were there'd be a riot!)
<LaserJock> I would suspect the MOTUs "universe" just starts getting smaller
<cjwatson> or bigger - there are things that are in main that don't necessarily need to be core-only
<LaserJock> true
<arthur-> doko: I have a fix for fastjar's make_manifest instead of building it with -O0 on ia64, it's not miscompilation
<arthur-> doko: see in query
<maxb> The nvidia-180-libvdpau stuff... doesn't that need to either be using version-agnostic names, or declare Provides+Conflicts+Replaces of version-agnostic names?
<tvakah> quick question before I jump, is jaunty in a place where someone used to running debian unstable+experimental could get by?
<cody-somerville> tvakah, can you deal with breakage?
<tvakah> cody-somerville: I know how to downgrade and pin packages if that's what you mean
<cody-somerville> tvakah, jaunty should be okay for you
<tvakah> cody-somerville: righto, thanks :)
<cody-somerville> np
<ScottK-desktop> mvo: WRT jaunty backup solution, did you see SuSE just announced http://www.csync.org/
<mvo> ScottK-desktop: thanks, I have not seen this one yet
<ScottK-desktop> mvo: They just announced it yesterday.
<mvo> ScottK-desktop: I'm not sure how useful it is if the primary purpose is sync, but I will try to find out more
<ScottK-desktop> My thought is that backup is potentially a subset of sync and if you can do two things with one tool that another distro is already developing ....
<mvo> ScottK-desktop: yeah, its definitely a good hint and something that we should know about
<pwnguin> how's csync different than a gui frontend to zsync?
<ScottK-desktop> No gui to start with.
<pwnguin> oh
<ScottK-desktop> The description reminds me a lot of unison.
<pwnguin> silly me; i thought "normal user" meant something entirely different than they did
<mvo> ""The implementation of the library will be introduced as a File Synchronizer for a Microsoft Active Directory environment (Roaming Home Directories for Linux Clients). " <- looks like that is the fist target use for the lib
<maxb> Hmm... unison written in a mainstream language? :-)
<pwnguin> hey
<pwnguin> ocaml is neat
<pwnguin> it just lacks a threaded garbage collector is all ;)
<maxb> Maybe I should have another try at learning ML, just for fun :-)
<pwnguin> ive been doing the project euler stuff in ocaml
<pwnguin> but then, I used to grade undergraduate programs in ocaml
<pwnguin> ymmv
<bryce> nenolod: I posted some patches for the crash on bug #188659
<ubottu> Launchpad bug 188659 in audacious "audacious crashed in playlistwin_set_sinfo_font with SIGSEGV 1.4.6-1ubuntu1 seg. fault" [Medium,Confirmed] https://launchpad.net/bugs/188659
<nenolod> bryce: thanks
<nenolod> bryce: http://launchpadlibrarian.net/21065596/null_ptr_fix.patch is wrong, truncation_point is not a pointer
<nenolod> bryce: but i will push an upload to debian with those patches
<tvakah> nvidia binary driver in jaunty: do I hold back all of x11 or is there a version of 180 on ppa or some such?
<tjaalton> you can use it by specifying IgnoreABI or such on the xorg.conf
<tjaalton> so no ppa could fix the driver, only nvidia can
<tvakah> yeah but it's blocking the upgrade currently since nvidia-glx-180 provides xserver-xorg-video-4, which conflicts with xserver-xorg-core
<tjaalton> for good reason
<tjaalton> it can be forced though, but you get to keep both pieces
<tvakah> tjaalton: is this a matter of nvidia upstream, or rebuilding it for the new xserver in jaunty?
<tjaalton> tvakah: we don't have the source, so it's nvidias fault
<tjaalton> also mentioned on the alpha2 release notes IIRC
<bryce> nenolod: right, needs a *
<tvakah> hmmm this may be the final straw that makes me seek an ati graphics module for my notebook
<tjaalton> for a new one you mean?
<maxb> Presumably fglrx is in the same mess
<tvakah> no I have a notebook with discrete graphics that can be replaced fortunately
<tjaalton> strange notebook
<tvakah> asus c90s
<tjaalton> oh, more like a mobile pc :)
<tvakah> pretty much, that's exactly what I wanted :)
<tvakah> so, if trying to force xorg 1.6 + nvidia breaks things into pieces, are the pieces fewer if I hold xorg back on 1.5?
<bryce> tvakah: make sure to get r500 or older
<bryce> tvakah: in which case the open -ati driver supports it quite nicely
<bryce> r600 and newer support is in the works and probably will be there for jaunty+1
<bryce> (_maybe_ sooner, we'll see)
<tvakah> gotcha, I'll see what I can find
<tvakah> hmm yeah, according to the forums the 180.22 driver released yesterday works with some semblance of stability with IgnoreABI on
<tjaalton> 180 always has
<tjaalton> the thing is that they've compiled it against the older stack
<tjaalton> so you need to use the option
<tjaalton> 177 segfaulted when I tried it a ~month ago
<cjwatson> Keybuk: pcmciautils done now, sorry for lateness
<sconklin> Is there a place that userspace packages are usually kept if they're not on launchpad? I'm looking for pm-utils and all I can find on launchpad is "it's not here".
<cjwatson> sconklin: many packages have no revision control as yet and the only place you'll find them is 'apt-get source pm-utils'
<cjwatson> (pm-utils may or may not have somewhere you haven't found, I haven't checked)
<cjwatson> Homepage: http://pm-utils.freedesktop.org/
<cjwatson> Vcs-Browser: http://svn.debian.org/wsvn/collab-maint/ext-maint/pm-utils/trunk
<cjwatson> Vcs-Svn: svn://svn.debian.org/svn/collab-maint/ext-maint/pm-utils/trunk
<cjwatson> that's the Debian revision control rather than ours but might be useful
<cjwatson> information from 'apt-cache showsrc pm-utils' on jaunty
<ubottu> from is not a valid distribution ['dapper', 'gutsy', 'gutsy-backports', 'hardy', 'hardy-backports', 'intrepid', 'intrepid-backports', 'jaunty', 'jaunty-backports', 'kde4-ppa', 'kubuntu-members-kde4', 'medibuntu', 'partner']
 * cjwatson sticks out his tongue at ubottu and waggles it around
 * StevenK waves http://paste.ubuntu.com/102967/ at cjwatson (livecd-rootfs)
#ubuntu-devel 2009-01-10
<sconklin> cjwatson: thanks. So since we'd like to deliver a small change to pm-utils with jaunty in order to support reporting of suspend/resume failures, what's the best way to do that? Sorry, I'm just venturing into ubuntu userspace . . .
<cjwatson> StevenK: remember that the same BuildLiveCD code is used to support older distributions too. I rather suggest that you leave the old names around
<StevenK> cjwatson: And remove support from livecd.sh ?
<cjwatson> sconklin: file a bug on https://bugs.launchpad.net/ubuntu/+source/pm-utils/+filebug, attach patch
<cjwatson> sconklin: and hunt around early next week for somebody to upload it
<sconklin> haha, ok. thanks
<cjwatson> StevenK: livecd.sh lives in the release-specific chroot so doesn't matter so much
<cjwatson> StevenK: rest looks fine
<cjwatson> StevenK: BTW, please commit the substantive changes separately from the UNRELEASED -> jaunty bit
<sconklin> time to put food on my family . . .
<StevenK> cjwatson: Hmm. Why?
<cjwatson> StevenK: it generally produces a more readable log if you go "commit change, commit change, commit change, dch -r, debcommit -r"
<sconklin> sorry, that's a regional joke
<cjwatson> so it's easy to see in 'bzr log' where the upload points were
<sconklin> George W Bush once said "You're working hard to put food on your family"
<directhex> sconklin, the greatest president said many inspired things
<sconklin> maybe so, but GWB said that last one
<ArneGoetje> slangasek: hardy translations export has been finished a few minutes ago. Import into langpack-o-matic is running. ETA in 3.5h.
<ArneGoetje> cjwatson: ^
<BenB> drescher.canonical.com broken: http://pastebin.ca/1304823 - who to contact?
<crimsun> doesn't seem broken, just takes a bit to respond
<BenB> no, it never responds...
<BenB> nevermind, though... it works from another network, so it's local horkage, sorry.
<BenB> yes, my stupid DSL router resetted the MTU.
<ArneGoetje> slangasek, cjwatson: uploading hardy base language-packs to hardy-proposed.
<slangasek> ArneGoetje: ah, huzzah!
<slangasek> ArneGoetje, cjwatson: langpacks accepted
<LordMetroid> Where should I file a bug report that you can not rename files from example foo to Foo in nautilis?
<Adri2000> LordMetroid: bugs.launchpad.net/ubuntu/+source/nautilus
<Adri2000> LordMetroid: on what kind of partition do you have this problem?
<LordMetroid> ext3 I think it is running
<LordMetroid> You mean you do not have this problem?
<Hobbsee> nope
<LordMetroid> I thought it would be an universal occurence
<Hobbsee> do the files show up with locks next to them?
<LordMetroid> no
<LordMetroid> they are like normal
 * Adri2000 has the problem with fat32 partitions
<LordMetroid> It is just that it says that the file already exists if I try to change the capitalization of the name
<Adri2000> but I think it's not a bug, it's just because fat32 is not case-sensitive
<Hobbsee> LordMetroid: well, does it?
<Hobbsee> a Foo?
<LordMetroid> Ahh, I see it does that on Fat32
<LordMetroid> The usb memorystcik must be fat32
<StevenK> fat32 filesystems are case-insensitive
<Hobbsee> ah
<Adri2000> so mv test TEST doesn't work. but mv test test2 and mv test2 TEST works
<LordMetroid> StevenK, should be possible to code a hack for this
<LordMetroid> Bug filed, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/315782 hopefully in the future one can change capitalization on files, making renaming files more intuitive
<ubottu> Ubuntu bug 315782 in nautilus "Change of capitalization in filenames on FAT32" [Undecided,New]
<LordMetroid> That was a neat bot
<cjwatson> Adri2000: while FAT32 isn't case-sensitive, it is case-preserving, and therefore this is a bug
<Adri2000> ok. if it's a bug then mv is affected as well
<theunixgeek> It's success story time! I got a friend to switch her office computer over to Ubuntu. I spent about 7 minutes setting it up to have a more familiar Windows-like look with only one panel, with only the relevant applications in the application menu. Now, she's loving it! Switching over from Vista, she says the interface looks much brighter, cleaner, and easier to use! Thank you, developers! :D
<theunixgeek> and she finds it to be more stable as well
<LordMetroid> Yeah, I am seriously wishing to use Ubuntu for on my dekstop as well... But then I will have problems with games that I wish to run
<theunixgeek> LordMetroid: dual boot? :)
<LordMetroid> Adding dual boot want solve the problem, then I would need to reboot too much and I would just boot into windows cause I know I am going to play games
<theunixgeek> I see :(
<theunixgeek> well, good luck :)
<LordMetroid> Indeed, it suck but little one can do about the gaming industry
<theunixgeek> LordMetroid: what country are you from?
<LordMetroid> Sweden
<LordMetroid> Why?
<theunixgeek> cool. I've been looking into Swedish for a while :)
<LordMetroid> Really, that not something I had expected someone to do
<theunixgeek> I just noticed some different word order, so I knew you were neither American nor British
<theunixgeek> why not? it's a cool language :)
<theunixgeek> besides, it's Germanic, so it'll be relatively easy to learn
<LordMetroid> Yes, indeed... the words will come easy the grammar I hear is relatively complex but that shouldn't deterr you, once you know Swedish you can also communicate, read and understand danish and norweigan and to a certain extent icelandic
<theunixgeek> Jag gillar svenska :)
<LordMetroid> and to a certain extent german
<theunixgeek> I've been studying German for a few weeks now, and I noticed I can understand some Swedish text already
<theunixgeek> I feel like learning Swedish for that reason: it's like just the right stepping stone to Danish and Norwegian
<theunixgeek> I'm averting Norwegian for a while due to the bokmÃ¥l/nynorsk mix
<theunixgeek> for pronunciation, I'm using an online text-to-speech app to hear how to pronounce the words, as well as to practice my listening comprehension (copy/pasting text :P)
<LordMetroid> Sounds cool
<LordMetroid> regarding the bug reports what does "triage" mean?
<theunixgeek> ä¸­å½å¤§ééç»å°æ¹¾çä¸¤ä¸ªåè°çç«"å¢å¢"å"åå"é¡ºå©æµè¾¾äºå°æ¹¾ã
<theunixgeek> whoops sorry. pasted in wrong chat :X
<theunixgeek> sorry
<LordMetroid> np
<ArneGoetje> slangasek: what about the langpacks in the New queue?
<Keybuk> soren: I'm reverse-thinking here
<Keybuk> we should probably just copy of all of /etc/udev/rules.d into the initramfs
<Keybuk> though that might break things since we don't copy hardly any of /lib/udev/rules.d
<Keybuk> or
<Keybuk> copy anything not in /lib/udev/rules.d
<Keybuk> and copy anything in /lib/udev/rules.d *if* it has been copied into the initramfs
<Tenkawa> anyone know offhand why between config-2.6.28-3-generic and config-2.6.28-4-generic of the kernel IPV6 went from module to being compiled in?
<Keybuk> Tenkawa: many things have gone from modules to being compiled in
<Tenkawa> bummer
<Tenkawa> oh well..
<cjwatson> ipv6 seems like a slightly dubious choice for that given the historical problems
<Tenkawa> cjwatson: agreed
<Tenkawa> it still has "hiccups"
<Mithrandir> cjwatson: we should have worked around that for just about all users now, though.
<cjwatson> I think you should file a bug on /ubuntu/+source/linux with details (if there isn't already one)
<cjwatson> Mithrandir: I'm assuming that the fact that Tenkawa is showing up here about it means we haven't
<Tenkawa> yep
<Keybuk> this sounds like a case of allowing users not to file bugs so we don't find out about the real problems
<Tenkawa> no way to turn it completely off
<Keybuk> Bug: please let me disable IPv6 is wrong
<Keybuk> Bug: ipv6 is broken for me *because* is right
<Tenkawa> yeah its not a bug
<cjwatson> one problem here is that some of the problems aren't ours
<Tenkawa> its a preference
<Mithrandir> Tenkawa: are you actually using ipv6 for anything or do you want to turn it off?  What are the symptoms you are getting?
<cjwatson> we've had historical problems with idiotic routers
<Tenkawa> but there should still be a choice
<Tenkawa> Mithrandir: no.. I just wanted to disable it completely
<Tenkawa> Mithrandir: just odd that it got switched to being forced
<Mithrandir> cjwatson: yes, and glibc now doesn't send out AAAA queries unless you have an address with scope >= site defined (and haven't for a while).  (As I think you know)
<cjwatson> (that said I agree with Keybuk, please file a bug about the breakage you're encountering with ipv6 turned on so that we can fix that properly)
<cjwatson> Mithrandir: *nod*
<Tenkawa> no more aliases trick... hehehe
<Keybuk> Tenkawa: the aliases trick is likely to stop working soon anyway
<Keybuk> (sorry)
<Keybuk> (for any module)
<cjwatson> aliases trick?
<Tenkawa> oh really?
<Tenkawa> darn
<Tenkawa> that was fun
<cjwatson> oh, alias ipv6 off?
<Tenkawa> y
<Tenkawa> a
<Keybuk> cjwatson: an ancient method of stopping the kernel being able to load ipv6 when it wants
<Tenkawa> yep
<Mithrandir> Tenkawa: from what I understand, you don't have any problems with it, you just want to disable it because you prefer it not to be loaded?
<Tenkawa> correct
<Tenkawa> the modular way seems more flexible
<Mithrandir> *shrug*; it's effectively disabled unless you configure ipv6 addresses, so the end result should be just about the same.
<Tenkawa> Its nothing to rebuild the kernel for me... was just trying to determine if this was intended
<Mithrandir> which is a fair question, agreed.
<Tenkawa> Mithrandir: no.. once the device comes up it does assign a link local address
<Tenkawa> although it "should" do nothing... it still responds to other api calls for ipv6 functionality
<Mithrandir> Tenkawa: correct.  Link-local addresses don't cause glibc to do lookups for ipv6 names.
<Tenkawa> possibly confusing other apps
<Mithrandir> so unless you do telnet $ipv6_address or some such, it won't actually use ipv6.
<Keybuk> do you have an example of an app confused by an ip6 link local address?
<Tenkawa> but apps that use apis checking for ipv6 capabilities "could" be affected
<Tenkawa> iceweasel I believe is one someone mentioned to me
<Tenkawa> it can be turned off but is a manual process
<Mithrandir> hmm, people reported to me that the glibc patch fixed that, but this was a couple of years ago, so iceweasel might be doing something different today.
<Tenkawa> like I said.. no big deal.. just curious
<Tenkawa> its a hobby/test box anyway... hehehe
<Tenkawa> thanks for the info though... be back later...
<Keybuk> I'm often surprised that my ISP don't do IPv6 yet
<Keybuk> Be seem to be staffed by the kind of techies who'd do it just because
<Keybuk> probably stuck by the fact the routers don't do it or something
<Keybuk> cjwatson: thought for the day http://lwn.net/Articles/313838/
<broonie> Keybuk: There are amusing issues with the BT network, I believe.
<Keybuk> broonie: the BT network doesn't apply in this case
<Keybuk> it's an LLU
<cjwatson> Keybuk: ah, so it sounds like Tenkawa didn't really have an issue then
<cjwatson> OK, less concerned :-) (I mean not a concrete, demonstrable issue)
<slytherin> has anyone else seen a problem on jaunty with permissions for dvd drive node. In my case the permissions (for /dev/hdc) are brw-rw----+. mplayer complains that it can not open dvd device.
<Keybuk> slytherin: err
<Keybuk> can you do ls -l /dev/hdc
<Keybuk> and getfacl /dev/hdc
<Keybuk> (and how the hell is it hdc and not sdc? :p)
<slytherin> Keybuk: ls -l output - brw-rw----+ 1 root disk 22, 0 2009-01-10 18:49 /dev/hdc
<Keybuk> I mean of course sr0
<Keybuk> ok
<slytherin> Keybuk: getfact output - getfacl: Removing leading '/' from absolute path names
<slytherin> # file: dev/hdc
<slytherin> # owner: root
<slytherin> # group: disk
<slytherin> user::rw-
<slytherin> group::rw-
<slytherin> mask::rw-
<slytherin> other::---
<cjwatson> Keybuk: yeah, I noticed Uli mentioning that on his LJ too
<Keybuk> cjwatson: which?
<cjwatson> Keybuk: the setcap on ping thing
<Keybuk> slytherin: cat /sys/block/hdc/media
<cjwatson> Keybuk: do you know if it needs any particular install-time mkfs options?
<Keybuk> cjwatson: I don't think so
<cjwatson> we could do it without any dpkg extensions - it'd just need maintainer script hacking
<slytherin> Keybuk: there is no such file
<Keybuk> slytherin: ?!
<Keybuk> slytherin: uname -a
<slytherin> Keybuk: wait, there is /sys/block/hdc/device/media, the output is cdrom.
<Keybuk> oh, sorry
<Keybuk> right
<slytherin> Keybuk: uname -a - Linux iBook 2.6.27-1-powerpc #1 Fri Nov 7 00:30:26 UTC 2008 ppc GNU/Linux
<Keybuk> slytherin: udevadm test /block/hdc | pastebin
<slytherin> Keybuk: not able to redirect the output to a file.
<Keybuk> slytherin: ?
<Keybuk> udevadm test /block/hdc > somefile.txt 2>&1
<Keybuk> hahaha
<Keybuk> bwahahaha
 * Keybuk spots the problem
<Keybuk> SUBSYSTEM=="block", KERNEL=="hd[0-9]*", SUBSYSTEMS=="ide", ATTRS{media}=="cdrom", GROUP="cdrom"
<Keybuk>                                ~~~~~~
<cjwatson> deliberate mistake, right/
<cjwatson> ?
<Keybuk> I suspect it's a case of nobody's used hd* in so long, it was forgotten they weren't numbered ;)
<slytherin> Keybuk: http://paste.ubuntu.com/103181/
<Keybuk> yeah
<Keybuk> that confirms it
<Keybuk> udev_rules_apply_to_event: GROUP 6 /lib/udev/rules.d/50-udev-default.rules:62
<Keybuk> the later GROUP assignment isn't being used
<Keybuk> slytherin: if you just do chgrp /dev/hdc cdrom
<Keybuk> does mplayer work then?
<slytherin> let me check
<slytherin> Keybuk: it doesn't give me any error anymore. And now it is reading the stream information from DVD.
<Keybuk> sweetness
<slytherin> Keybuk: so should i file a bug for this?
<Keybuk> slytherin: I've already mailed udev upstream
<Keybuk> but a bug on udev would be welcome
<Keybuk> (so I don't forget to hassle/chase/etc.)
<slytherin> Ok. I will file a bug.
<slytherin> Now another completely unrelated problem. I am getting stuttering sound when playing songs or movies. It is very irritating. I am not able to figure out what the problem is. Can it be some buffer overrun?
<Keybuk> slytherin: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=18cff5c3b2e3591fa46107288ea2d7026a15ccf3
<sbeattie> cjwatson|keybuk: actually, apparmor has the (little-known little-used) ability to grant posix capabilities, which would let one remove the setuid bit on ping by writing the apparmor policy and granting within it cap_net_raw.
<cjwatson> sbeattie: true; though that'd introduce a reliance on apparmor for functionality as well as for security, which is a significant step
<Keybuk> sbeattie: why is that better than using xattr?
<sbeattie> Keybuk: does the deb packaging format include xattrs?
<kees> why do we want to drop the setuid bit on ping?
<Keybuk> it includes maintainer scripts
<kees> (xattr and aa both impose greater limitations than just leaving the setuid bit)
<Keybuk> kees: I'd've thought you'd be in favour of dropping setuid everywhere it's not needed? :p
<kees> Keybuk: I'm in favor of it when it's used irresponsibly.  ping (and most of the other setuids) just give themselves a CAP and drop privs
<Keybuk> kees: the suggestion is that you just give them the CAP on the filesystem, so they don't even need to do that
<kees> I mean, I'm in favor of xattrs in general, but it'd mean we could no longer support any filesystems that didn't support xattrs
 * Keybuk waits for the downside :p
<kees> yeah, me too.
<kees> I'm a fan of it, but I just wanted to play devil's advocate for a second
<kees> fscaps are in the kernel now (added for hardy, I think)
<Keybuk> right
<Keybuk> not that we really make any effort to support filesystems other than extN anyway
<cjwatson> we don't? (I get bugs about them and fix them, generally ...)
<Keybuk> all we tend to do for people who report lost data with XFS is not laugh at them in their face
<Keybuk> cjwatson: I suspect we're using different meanings of the term "support" ?
<cjwatson> which filesystems that are supported for installation (which a user could be forgiven for mistaking for "supported") don't support xattr, anyway?
<kees> well, what about the boot-inside-windows thingy?
<cjwatson> Keybuk: yeah, you sound like you're saying "I don't want to support anything other than extN", which is slightly different ;-) (though I acknowledge the way XFS and apt are not friends)
<kees> cjwatson: that's probably the right question. :)
<jdong> isn't the boot-inside-windows thing a fancy loopback image of a standard Linux FS?
<cjwatson> yes, it is
<cjwatson> ext3 loop on ntfs-3g
<cjwatson> except for /boot which is directly on ntfs-3g
<kees> I think /boot isn't, though -- which has caused problems (like, for symlinks) in the past.  ?
<cjwatson> in the context of this discussion that's irrelevant, though
<kees> but we don't need fscaps there :)
<kees> also, this would be a delta from debian -- not strictly bad, just pointing it out
<cjwatson> I think it'd be pretty reasonable to do it for ping in maintainer scripts, and see what follows - unless there's a filesystem commonly used for / or /usr that doesn't support xattrs
<jdong> JFS does xattrs right?
<Keybuk> cjwatson: that is what I'm saying :p
<Keybuk> I was thinking of the way that dpkg and XFS weren't friends
<jdong> oh they only aren't friends if you crash the system at the right time ;-)
<cjwatson> the installer permits any of ext2, ext3, ext4 [jaunty], reiserfs, jfs, xfs as /
<Keybuk> we still permit reiserfs? :p
<cjwatson> yes
<Keybuk> it's kiiinda unmaintained now, no?
 * Keybuk hasn't seen anyone step forward for it
<jdong> is there still that one guy from Novell?
<cjwatson> I have no information
<cjwatson> and I am not interested in creating more grief for myself by removing it
<Keybuk> the people who used to be excited about it seemed to have redirected their efforts to btrfs
<jdong> last I heard novell is having one guy manage reiserfs for bugfixes primarily for their SLES products still supported
<cjwatson> anyway, as far as I can tell, all of the above filesystems have some level of xattr support (i.e. a file matching *xattr* in fs/foo/ ...)
<cjwatson> so the discussion, while diverting, is probably not relevant to whether we can rely on xattr :-)
<kees> sweet.  let's do it!  :)
<cjwatson> that said I do not know whether any of those filesystems need mkfs/mount options to enable xattr
<cjwatson> I know they have user_xattr mount options, but that's only for the user.* namespace isn't it?
<Keybuk> according to mount(8)
<cjwatson> mount(8) says different things for different filesystems, so I wanted to check that the option with the same name actually means the same thing for different filesystems
<elmo> err, how on earth are you planning to handle upgrades?
<Keybuk> xfs has attr2/noattr2
<Keybuk> but that seems to only refer to the format of xattr on disk
<kees> cjwatson: I tried playing with user_xattr on the bus from google, and I got mixed results.
<Keybuk> elmo: is there some special handling that needs to be done?
<kees> Keybuk: potentially adding mount options
<Keybuk> oh, right
<Keybuk> but we were just vaguely concluding there were no relevant mount options
<Keybuk> besides, we've added mount options during upgrade before :p
<cjwatson> elmo: what's the upgrade problem? it looks like all filesystems already permit extended system attributes (which is where this would live) and it would be a matter of disabling the setuid bit and running setxattr or whatever it is in the postinst
<elmo> oh, I assumed it required user_xattr
<cjwatson> obviously we would have to check the first assertion there properly
<cjwatson> I don't think it does
<elmo> (which has eaten my disk several times, so it makes me squirm when people talk about relying on it)
<cjwatson> sorry, setcap not setxattr
<Keybuk> no user_xattr required
<Keybuk> according to http://www.friedhoff.org/posixfilecaps.html
<Keybuk> there do seem to be other patches required
<Keybuk> cp and mv need patching to copy the attributes
<cjwatson> http://www.friedhoff.org/posixfilecaps.html does suggest that if we did that then ping would stop working in systems running dapper kernels
<cjwatson> (yes yes pace Keybuk I know udev won't work)
<Keybuk> likewise tar, rsync, etc;
<Keybuk> cjwatson: I was more thinking that Upstart wouldn't work <g>
<cjwatson> neither upstart nor udev is necessary in a chroot
<cjwatson> at least it doesn't matter whether they really work, even if they happen to be installed
<kees> Keybuk: are those patches not already upstream?  I think a mess of that was done already since selinux support needed it too?
<cjwatson> ping in a chroot is the sort of thing you might well be a bit surprised about breaking though
<cjwatson> and definitely tar
<Keybuk> kees: the doc is old, the patches could very well be applied now that fscaps has gone kernel upstream
<Keybuk> cjwatson raises very interesting questions here
<Keybuk> do we have to limit ourselves to only using kernel features in our oldest supported LTS?
<cjwatson> slangasek and I had this debate a little while ago regarding glibc
<elmo> this seems like a lot of work given the current model is to give itself caps and drop privs
<Keybuk> because we would want to support them running a modern chroot under that LTS
<cjwatson> slangasek reckoned we did, and made glibc only require 2.6.15 for that reason
<Keybuk> cjwatson: glibc has requirements?
<cjwatson> it is my belief that modern chroots under LTS kernel basically work
<cjwatson> Keybuk: yes
<Keybuk> what changes if you up the requirement?
<cjwatson> it uses new syscalls
<cjwatson> and drops fallback support
<elmo> cjwatson: we know they do; our powerpc boxes are still (and have to) run dapper
<Keybuk> but if the requirement is lower, but you *have* the new kernel, does it use the new syscall or still the old one?
<cjwatson> I *think* it uses the new one but you'd have to check
<Keybuk> do you have a syscall example?
<cjwatson> I suspect that may vary between features
<Keybuk> (I'm guessing it's something like pselect or ppoll)
<cjwatson> pselect is one such yes
<cjwatson> there's a header file somewhere with a nice summary
<cjwatson> glibc/sysdeps/unix/sysv/linux/kernel-features.h
 * Keybuk is waiting for bzr
<cjwatson> I think that glibc's bzr is debian/-only :-(
<Keybuk> oh, I see
<Keybuk> __ASSUME_SOCK_CLOEXEC is kinda a cute example
<Keybuk> if defined, it assumes it always exists
<Keybuk> if not defined, it tries with it, then falls back to without
<Keybuk> doesn't __LINUX_KERNEL_VERSION come from the linux kernel headers themselves?
<cjwatson> no in this case it's set by glibc/configure
<cjwatson> I'm not certain that all the features follow the same model
<Keybuk> some seem to change the behaviour of other bits
<Keybuk> like __ASSUME_PACCEPT only changes nscd
<cjwatson> debian/sysdeps/linux.mk:MIN_KERNEL_SUPPORTED := 2.6.15
<cjwatson> is the ultimate source of this in our packaging
<Keybuk> pselect() is really the one that interests me
<Keybuk> since the glibc wrapper for it is an idiotic thing to have anyway
<ebroder> I'm maintaining an apt repository for some site-specific configurations. Is there something I can hook in update-manager so that repo doesn't get disabled in sources.list when my users take a release upgrade?
<Keybuk> I never understood what they were smoking to lead them to believe that having a glibc-implemented wrapper for that was a good idea
<Keybuk> right, in the pselect() case, the fuck-stupid wrapper is used only if you get -ENOSYS
<Keybuk> looks like it doesn't turn off anything that should be on ;)
<Keybuk> the glibc guys are usually pretty awesome about such things anyway, but worth checking
<Keybuk> hmm
<Keybuk> cjwatson: so how strict do we need this policy to be?
<cjwatson> can we talk about this on Monday? :-)
<Keybuk> sure :p
 * Keybuk figured that since you were online and chatting in the channel, you were trying to escape your home life rather than being distracted from it <g>
<cjwatson> I'm interested, but too many other things to do ...
<cjwatson> nah, I was around because I was trying to get my 3G modem to work :-), but now I have nappies to change and such
<cjwatson> (and oh dear god this ZeroCD thing is AWFUL)
<Keybuk> zeroCD?
<cjwatson> some USB 3G modem manufacturers got the bright idea of embedding a flash drive into the device containing drivers
<cjwatson> which would have been fine if they'd also added a USB hub so that both the mass-storage and the modem show up at once
<Keybuk> right
<Keybuk> I thought these were mostly handled in the kernel now?
<cjwatson> but no - what happens on Windows is that the first time you plug in the device, it installs the driver, and subsequently the driver pokes the device to switch to modem mode
<Keybuk> or has someone written a userspace hack for it, because they didn't realise the kernel has a quirks list about this?
<cjwatson> what happens on Linux is that either the kernel's already arranged matters for you, or else you go through godawful userspace hacks
<cjwatson> and what happened to me today was that I went down blind alleys of godawful userspace hacks, and then discovered that Dan Williams had sent a patch recently for nearly the same model which got merged
<cjwatson> (kernel patch that is)
<cjwatson> so I'm trying that out now. Weirdly, Alan Cox vehemently objected to that patch on lkml
<Keybuk> Alan Cox seems to be objecting to a lot of patches atm
<Keybuk> </bitter>
<cjwatson> if it works with the obvious quirks addition over and above Dan's patch, I'll throw it lkml-wards. It just took me rather more time than I'm happy with to figure out that *that*'s where the five lines of code needed to go ...
<cjwatson> the manufacturers are pushing some pile of dodgy udev rules
<Keybuk> yeah
<cjwatson> and object to the kernel defaulting to turning off ZeroCD on the grounds that they might want to put something shiny in there
<Keybuk> iirc they eject the storage device, then poke in sysfs to power off and on the usb device again, thus it represents to the kernel
<cjwatson> yeah, that kind of thing
<Keybuk> yeah I saw that
<Keybuk> the counter to that of course is that the Windows default is to turn it off once the driver is installed
<cjwatson> indeed
<Keybuk> Linux _comes_ with the driver ;-)
<cjwatson> and *obviously* you get a 3G modem so that you can use it as a flash drive
<cjwatson> err
<Keybuk> you could do some insane things with jockey
<Keybuk> first time they insert the device, it appears as a storage device so you can look at their PDFs or something
<cjwatson> I think mine was read-only anyway and contained only Windows drivers
<Keybuk> a bubble appears telling you to click jockey to turn it into a modem
<Keybuk> then jockey turns it into a modem, and installs a udev rule to do it next time
<cjwatson> ... or the modem could just work :;-)
<Keybuk> but that's just insane
<Keybuk> exactly
<cjwatson> :-)
<cjwatson> /usr/sbin/update-grub: line 333: /sbin/vol_id: No such file or directory
<cjwatson> hmm, I thought you put a symlink in?
<Keybuk> err, I thought I did
<Keybuk> this may be a case of "Scott forgot to bzr add debian/udev.links"
<cjwatson> I thought I saw it while NEWing it, but maybe that was only for udev-udeb
<Keybuk> so it worked when I tested it, but bzr bd didn't copy it over
<Keybuk> I think in the udeb, we just copy vol_id into sbin
<cjwatson> I believe the installer generally does PATH=/lib/udev:$PATH vol_id, but wouldn't swear to that being the case everywhere
<Keybuk> nope, it's missing in the udeb too
<cjwatson> maybe you didn't build the one I NEWed with bzr bd?
<Keybuk> maybe
<Keybuk> was certainly having trouble
<Keybuk> the -2 I did, so that could have lost the symlinks again
<ebroder> Is there any way to do site-local hooks in update-manager?
<cjwatson> ebroder: might want to ask during European working hours when mvo's around
<ebroder> cjwatson: Ok, I can do that
<ScriptRipper> I read: https://dev.launchpad.net/OpenSourcing
<ScriptRipper> "We're open-sourcing the code that runs Launchpad.net. The process will be completed by 21 July 2009, coinciding with the 3.0 release (see the schedule of releases)."
<Keybuk> ScriptRipper: ... this isn't twitter
<asac> hmm after todays upgrades Xorg consumes tons of CPU (hardy usable) for me - i am on ati (free)
<asac> bryce: tjaalton: ^^ ... any idea?
<asac> bryce: tjaalton: seems like enabling exa caused this. going for Xaa makes things go back to normal (https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.9.0.91-1ubuntu3)
<asac> bryce: tjaalton: what info do you need? i would love to have this fixed ... but in worst case we have to exclude this card from exa i think. let me knew
<asac> bryce: tjaalton: its #315889
<PovAddict> what just happened to the language packs? http://packages.ubuntu.com/hardy/language-pack-es
<PovAddict> 36KB?
<jpds> PovAddict: I believe the rest is contained in -base.
<PovAddict> I just saw them show up as upgradeable packages in aptitude
<PovAddict> from 3MB to 33KB
<jpds> Hmm.
<PovAddict> http://pastebin.com/d3746efeb
<PovAddict> http://pastebin.com/d2c243f5
<Hobbsee> hrm.  Jaunty X appears to have exploded.  Fun!
<RainCT> oh, X likes explosions.. btw, is it normal that X fail to start if I close the laptop's lid while it's booting?
<RainCT> jcastro: shame on you, how could you fall asleep? :P
<Hobbsee> RainCT: this one's particularly interesting, with things like "failed to allocate frame buffer" and "Failed to allocate EXA offscreen memory" and "[dri] DRIScreenInit failed. Disabling DRI", which i've not seen before
<RAOF> Hobbsee: Hurray for no acceleration!
<Hobbsee> RAOF: indeed!  Well, X just does'nt start at all now
<RAOF> Sounds fun.
#ubuntu-devel 2009-01-11
<Keybuk> Hobbsee: kernel update?
<Keybuk> no, ignore me
<Keybuk> 2.6.29 is current HEAD and that's where the X-related fun is happening
<Keybuk> jaunty only has .28
<Hobbsee> Keybuk: ah.  I have the X log, if anyone's interested in seeing it
<bryce> asac: Xorg.0.log and lspci -vvnn, description of symptoms when running EXA.  Title it something like, "[rNNN] High CPU when EXA enabled; needs XAA quirk" where rNNN is your chip type, r350, r500 or whatever
<bluefoxicy> Is there anything about how to make a repo from source packages?
<bluefoxicy> i.e. build my own copy of main, from source, into debs
<Hobbsee> pbuilder with some extensions + a repository thing?  reprepo / falcon / etc?
<bluefoxicy> is there documentation?
<Hobbsee> i've no idea
<Hobbsee> but that's how i'd go about doing it
<bluefoxicy> a friend of mine wants to build some generalized security stuff into Ubuntu (toolchain modifications, hardened kernels, etc) and the best I can come up with is to rebuild the repos
<ScottK> falcon is broken in Intrepid and later.
<ScottK> bluefoxicy: I know NCommander has done this recently.
<Hobbsee> useful.  why?
<bluefoxicy> Hobbsee: was that for me or scottK?
<Hobbsee> ScottK.
<ScottK> Hobbsee: Not updated for the Django 1.0 api changes.
<NCommander> bluefoxicy, rebuilding the archive is a sheer pain in the ass, and not something trivial to do.
 * bluefoxicy notes to ask NCommander
<Hobbsee> ScottK: ah, darn.
<PovAddict> there you go
<ScottK> Thus NCommander has done it more than once, just for 'fun'.
<bluefoxicy> NCommander:  dude, there is a build server that does this continuously; and since like Hardy all I've ever heard is "it's  really non-trivial"
<NCommander> ScottK, I like pain, 'nuf said
<ion_> scottk: It should depend on the correct version of django then.
<NCommander> bluefoxicy, I assume your referring to UWSA's archive rebuild setup
<ScottK> ion_: It should and if I was the maintainer, I'd fix it.
<bluefoxicy> NCommander: yeah.
<ScottK> seveas has been going to rename falcon and get it fixed up, real soon now, for most of a year.
<NCommander> bluefoxicy, That's not what you want, since it depends on currently existing packages to rebuild the archive. If I read you right, you don't want to use th existing packages, which means bootstrapping the archive
<bluefoxicy> NCommander: what I'm thinking is iterate all of main and get the package source, rebuild every package in main, and stick it in a folder, then generate a packages.gz off it
<bluefoxicy> i.e. let's say I want to install Ubuntu, but build everything with 'gcc -Os' instead of -O2
<bluefoxicy> everything...
<PovAddict> bluefoxicy: to rebuild certain packages you need to build other packages first, so yes what you want is "bootstrapping"
<NCommander> Like I said, non-trivial to redo
<bluefoxicy> yes
<NCommander> bluefoxicy, there is no mechanism in place for automagic rebootstrapping
<NCommander> its a long, slow, and UGLY process
<bluefoxicy> NCommander: hmm.
<NCommander> bluefoxicy, that being said, if its just -O2 -> -Os, you might be able to cheat by using existing packages
<bluefoxicy> PovAddict:  I don't suppose a host ubuntu system can simply install the existing packages and rebuild...
<NCommander> bluefoxicy, wgrant is the guy who runs UWSA archive rebuilds
<bluefoxicy> NCommander: nods.
<PovAddict> bluefoxicy: if you tell ubuntu to build package X from source, it will get *binaries* for packages Y, Z, and W it depends on
<PovAddict> so it can build
<bluefoxicy> NCommander: the actual problem I have in mind is compiling all binaries as PIC, linking executables as PIE, and using a kernel that's patched to load said executables with a randomized executable base and random heap base
<NCommander> bluefoxicy, PovAddict is right, hence the difficulty, bootstrapping Ubuntu is a lot (and I mean *a lot* of grudge work)
<bluefoxicy> ok that makes sense
<NCommander> bluefoxicy, we're already doing that.
<NCommander> bluefoxicy, not for jaunty, but jaunty+1, MAYBE
<NCommander> bluefoxicy, its not trivial, you really do need to rebootstrap to make it happen due to the interdependencies in the base system.
<bluefoxicy> nods.
<bluefoxicy> I have someone that wants to do that plus some other stuff
<bluefoxicy> but the only thing that's stopping him is rebuilding world
<bluefoxicy> from scratch
<bluefoxicy> non-trivial... no kidding.
<NCommander> bluefoxicy, trust me when I say if it was that easy, it would have been done already ;-)
<bluefoxicy> heh
<bluefoxicy> hmm
<kees> bluefoxicy: what toolchain modifications does your friend want to see?
<kees> bluefoxicy: but, if you want, look at "hardening-wrapper" and see how it works.  Then you could do archive rebuilds with it installed and enabled.  see https://wiki.ubuntu.com/Security/HardeningWrapper and/or http://wiki.debian.org/Hardening
<kees> bluefoxicy: the stock kernel in ubuntu already supports PIE load randomization
<bluefoxicy> cool
<kees> bluefoxicy: also, there is a up to a 15% performance loss on 32bit for PIE
<kees> I would recommend only doing this on 64bit.
<bluefoxicy> kees: I can't see that.  Is that theoretical?
<kees> bluefoxicy: it's not theoretical.  I've measured it for certain workloads (like, say all of python)
<kees> as far as 64bit PIE, see https://wiki.ubuntu.com/64BitPIEDefaultSpec
<bluefoxicy> I did a complete system profile once using oprofile and the overall real impact was about 0.02%  <_<
<kees> bluefoxicy: but most stuff isn't .text heavy (like most scripting languages) and in those cases, it's about 5% loss
<bluefoxicy> however, microbenchmarks did allow me to produce a 6% performance impact under special conditions (notably, -fomit-frame-pointer gives a 5% speedup, but it's impossible in PIC text)
<kees> bluefoxicy: 32bit has _very_ few general registers, so stealing one for the relocation thunking really turns up the heat on moving data in and out of memory
<bluefoxicy> right
<kees> but, for some people, it's worth it.
<bluefoxicy> the flip side of  that is you  really  don't spend any time in the main executable :P
<kees> as far as doing an archive rebuild, NCommander knows a great deal more than I do about that.  :)
<bluefoxicy> (except, apparently, with python)
<kees> I gotta split, hopefully the above links will be helpful.
<bluefoxicy> yeah, very, thanks
 * Keybuk likes git reset
<Keybuk> now I've figured it out, it's quite useful
<maxb> Doesn't that sentiment apply to all of git? :-)
<Keybuk> no, lots of git is "ugh", and "wtf", and "why does it behave like *that*"
<Keybuk> other bits are "ok, that's as good as bzr"
<Keybuk> git reset is special in that it's better than bzr, because bzr is sorely missing such a thing!
<jpds> Does git have an "ignore" function yet?
<persia> Oooh.  That is nice.  It's the thing that would make me stop doing everything outside VCS just so I can avoid that sort of mistake.
<StevenK> bzr has uncommit ...
<Keybuk> StevenK: it's not the same
<persia> Not at all.
<persia> StevenK, It resets the VCS info, while not touching your files, so your files stay dirty (with the changes you wanted).
<StevenK> Hmmm
<persia> The bzr workaround is to always push to somewhere on commit, and run bzr diff before each commit, so you can reapply the patch to the last commit to restore the state when you mess up the next commit.
<persia> (which is annoying and painful)
<Keybuk> lool: you didn't commit that watershed change to bzr?
<lool> Keybuk: Hmm I thought I had checked there was no Vcs-Bzr URL, but I missed it in the showsrc output
<lool> Keybuk: Will commit now, sorry
<lool> (I was actually surprized it didn't use Bzr)
<lool> Keybuk: Pushed, but as a single commit
<lool> (and tagged)
<Keybuk> thx! :)
<gsc> What policy is Ubuntu actually using to push updates to the users? Are they toroughly tested or pushed out asap?
<persia> gsc, Depends on the type of update.  For the development release, there's usually only developer testing.  For updates to releases, there is significantly more testing.
<gsc> And for example a zero-day bugfix?
<gsc> persia: I can immagine that sometimes an update can break something and the smaller circle of developers cannot forsee all the possible problems on so many different setups and hardware.
<persia> zero-day bugfix?
<gsc> persia: I mean a very urgent update that fixes a very serious bug or exploit.
<persia> Those go to -proposed, and get tested.  I don't know of anything that went out without testing, although I could be mistaken.  In cases of extreme urgency, I would expect the tests to be performed more quickly, rather than skipped.
<gsc> persia: why not involve the power-users in this regard? An extra option in the dialog 'installation sources' which power-users can select to get the updates a bit earlier than the rest. That way, a fix/update can be tested on a lot more different setups.
<persia> gsc, Anyone is welcome to help test -proposed.  I'd recommend joining #ubuntu-testers and reading https://wiki.ubuntu.com/Testing/EnableProposed
<Laney> gsc: That exists and is called -proposed
<persia> I believe (although I've not checked) that a majority of the people who test the updates are not current developers.
<directhex> gsc, did you file a security bug on launchpad?
<gsc> persia: i'll look at it. Thanks for the info. I'm not using (k)Ubuntu that long. Always been a (Open)SUSE since 2000.
<gsc> directhex: no, I was just curious about the policy.
<persia> gsc, Thanks for your interest.  I do hope you'd be willing to help test.  One of the biggest blockers to getting good updates out is lack of testers, so more are always welcome.
<gsc> persia: I already checked the option for proposed. What is the mean time for tested updates via proposed to go mainstream?
<persia> I'd say a week or two.
<persia> Also, while I'm glad to introduce you to the testing procedures here, it's a bit off-topic for the channel.  I do encourage you to join #ubuntu-testing and ask more there.
<gsc> persia:ok
<ogra> gsc, https://wiki.ubuntu.com/StableReleaseUpdates
<ogra> and https://wiki.ubuntu.com/SecurityUpdateProcedures
<gsc> ogra: checking those, thanks.
<bluefoxicy> hmm...
<bluefoxicy> install security updates without confirmation... seems to not continuously download, or install.  Is it on a schedule?
<Zorry> NCommander, ping
<juliank> documentation makes developers happy. http://people.debian.org/~jak/python-apt-doc/
<PovAddict> <.<
<PovAddict> translations indeed got messed up
<PovAddict> remember yesterday I said the translation packages had gone from 6MB to 22KB?
<PovAddict> now things indeed started showing in English
<PovAddict> reported #316174
<ion_> lssy cmprsson
<bluefoxicy> anyone here good with gdb?
<bluefoxicy> http://rafb.net/p/m1zi2P91.html ok that's a start.
<bluefoxicy> nm, screw gdb.
<PovAddict> type bt
#ubuntu-devel 2010-01-11
<LucidFox> What is Ubuntu's policy on supporting software outside the repositories? I've heard complaints about the removal of GTK1 breaking third-party applications.
<ScottK> LucidFox: It's gone.  It's not coming back.
<ScottK> It's ancient and unsupportable.
<ScottK> I don't know that there's a formal policy, but gtk1 definitely needed to go.
<RAOF> See also: libstdc++5
<ScottK> Yes, exactly.
 * ScottK got some hate mail when he wontfixed the bug to bring it back.
<LucidFox> I wontfixed the bug to bring GTK1 back, saying:
<LucidFox> 'It is not the responsibility of Ubuntu developers to guarantee workable conditions for "commercial linux applications and games" outside the repository; the best solution for such software would be to bundle the required libraries.'
<LucidFox> Now I'm asked a source for that.
<ScottK> LucidFox: What bug?
<LucidFox> bug #478219
<ubottu> Launchpad bug 478219 in gtk+1.2 "libgtk1.2 missing on karmic" [Undecided,Won't fix] https://launchpad.net/bugs/478219
<ScottK> I'll go back you up
<StevenK> Just like people begging for libstdc++5
<LucidFox> Well, it's a security nightmare to keep every obsolete version of every library ever written.
<crimsun> LucidFox: the definitive reference is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520441
<ubottu> Debian bug 520441 in ftp.debian.org "RM: gtk+1.2 -- ROM; deprecated for 8 years, no security support" [Normal,Open]
 * StevenK watches nautilus combust
 * ScottK hands StevenK another log for the fire.
<StevenK> Haha
<StevenK> Like dolphin is any better :-P
<spm> xtree-pro ftw
<StevenK> Oh god, I even remember using that
<spm> you just dated yourself StevenK, +10 years. that is all.
<StevenK> Meh
<spm> :-)
<humphreybc> Hi everyone, who do I need to talk to about Lucid CD contents?
<alkisg> Today teeworlds complains "error while loading shared libraries: libGLU.so.1". I see that it was moved from /usr/lib/libGLU.so.1 to /usr/lib/mesa/libGLU.so.1, should there be a symlink or something now that's moved?
<vish> humphreybc: #ubuntu-desktop
<humphreybc> lol cheers vish i'll pop over there
<vish> humphreybc: probably during work hrs UTC
<ScottK> alkisg: Known breakage.  Hopefully fixed today.
<alkisg> Thank you :)
<didrocks> good morning
<StevenK> didrocks: Morning!
<dholbach> good morning
<dholbach> could it be that libunwind is still in binary new?
<dholbach> erm, never mind
<xaka> is it possible to use more than 1 CPU to build packages? to speed up process...
<ghostcube> xaka: it is
<ghostcube> but dont ask me wheere i read about to config it
<ghostcube> :D
<geser> xaka: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options and read about "parallel"
<tseliot> cjwatson, Riddell: can you approve my nvidia packages in NEW, please? (nvidia-graphics-drivers, -173, -96)
<slytherin> Can someone with upload rights to linux-ports-meta please bump its version for karmic-updates?
<tseliot> seb128: ^^
<didrocks> cjwatson: when you're there, casper ready for sponsoring (bug #505140)
<ubottu> Launchpad bug 505140 in casper "No more autologin in live CD" [High,Triaged] https://launchpad.net/bugs/505140
<seb128> tseliot, ok, I finish something and I will have a look to those
<tseliot> seb128: perfect, thanks
<StevenK> seb128: I've been looking at them, I've shifted them over, I can accept them if you like
<seb128> StevenK, please do
<seb128> StevenK, thanks
 * tseliot thanks both seb128 and StevenK
<StevenK> seb128, tseliot: Accepted
<seb128> thanks
<tseliot> \o/
<ttx> cjwatson, pitti: could one of you trigger a server CD respin, kirkland worked too late (on Sunday night ?) for the daily spin to pick up the latest eucalyptus
<alkisg> Is syslinux going to be updated for Lucid? I've seen a lot of newer PCs unable to boot with the current Ubuntu isolinux/pxelinux versions, but which were able to boot with the debian ones.
<DktrKranz> pitti: I was considering if could be feasible switching from tsclient to remmina (formerly known as grdc) as default RDP client for Lucid. The latter is actively maintained upstream, has the same features implemented in tsclient (but it has more), and is less buggy.
<xaka> how to build packages which has cross-build deps? for example to build package A it need installed package B, but to build package B it need A.
<geser> try to avoid it, as it makes the initial build hard
<xaka> real example is openjade and libosp
<xaka> libosp want openjade and openjade want libosp but how it is possible in same time? :)
<xaka> seems like package maintainers use some "hack" to complete build process and resolve same issues?
<geser> once you have one of the two packages build, you can use it to build the other, and so on. the hard part is the initial build
 * geser hates several java-packages build-depending on itself :(
<xaka> yeap, you are right. I'm about initial build
<geser> you have to figure where is it easier to deactivate something to get it build, build the other one, undo your first changes and rebuild the package
<cjwatson> ttx: running
<cjwatson> didrocks: makes sense, looking at that now
<cjwatson> alkisg: urgh, yeah, we probably ought to :-/
<ttx> cjwatson: thanks !
<cjwatson> didrocks: don't you want a trailing newline on that [daemon]? so echo rather than printf
<cjwatson> (from the dept. of pickiness)
<chrisccoulson> cody-somerville - do you install totem by default in xubuntu?
<mr_pouit> chrisccoulson: yes
<chrisccoulson> mr_pouit: thanks. does screensaver inhibiting work in xubuntu when you play a video?
<mr_pouit> well, it works with mplayer + xscreensaver ^_^. I can try with totem & gnome-screensaver when I'm back at home.
<chrisccoulson> mr_pouit - i've just thought - gnome-screensaver doesn't work in XFCE does it? it gets idletime from gnome-session
<mr_pouit> yeah, it didn't work, but iirc, something was patched in karmic, so maybe it works finally
<mr_pouit> 2.28.0-0ubuntu3.2 I think
<chrisccoulson> mr_pouit - nothing has changed in karmic that would make it work under XFCE. the last update was to fix the legacy interface for inhibiting the screensaver
<mr_pouit> okay, so yeah, still broken
<mr_pouit> we'll probably switch to xscreensaver for lucid
<chrisccoulson> i'd be interested to know if screensaver inhibiting works with totem and xscreensaver
<siretart`> mr_pouit: does xfce use mplayer 'officially'?
<siretart`> mr_pouit: I'm strongly considering dropping the mplayer-gui variant. would that affect xfce in any way?
<mr_pouit> siretart`: no no, we do not use it officially. I'm only using it officially for myself ;)
<siretart`> mr_pouit: what do you think about dropping gmplayer from the package?
<mr_pouit> siretart`: I always use the cli because I found the gui ugly when I tried it (a long time ago). ^^
<mr_pouit> and I think there are probably other guis more friendly such as gnome-mplayer.
<siretart`> mr_pouit: well, I have the impression that more than 2/3 of the bugs in launchpad are only found in the gui variant. moreover it is more or less officially abandoned upstreamâ¦
<siretart`> and I think we should prevent our users using it accidentally
<jussi01> siretart`: this raises a point that I have been thinking about for a while, is there a chance we can set up a PPA or so for items like this that we drop from the archive? I mean theres been a big uproar because we have dropped things like libstdc++5 and gcc3.3 etc, it would be great if we could just say to people, hey! PPA is there, if you need it still? (I dont have skills to create/maintain it, but know anyone interested enough?)
<cjwatson> why not just tell them to install those packages from older releases of Ubuntu?
<jussi01> cjwatson: is that safe?
<cjwatson> it's not like they change much
<jussi01> I mean I can safely go tell people grab libstdc++ from hardy for your karmic install?
<siretart`> jussi01: yes, that should work just fine
<jussi01> siretart`: thanks!
<pitti> DktrKranz: tsclient> wasn't that being deprecated by vinagre as well? perhaps you could mail -desktop@ or -devel@ about it?
<seb128> pitti, it didn't yet
<seb128> some protocols vinagre doesn't do
<seb128> ie rdp I think
<pitti> seb128: question is whether we should support that (especially with the nice integration into empathy now, etc.)
<pitti> hm, RDP is fairly standard in the Windows world, isn't it?
<seb128> yes
<seb128> vinagre has the infrastructure for protocoles to be added
<seb128> somebody need to do it though
<seb128> we decided to keep tsclient until then the previous time we discussed those
<seb128> I don't have the context for the current discussion though
<pitti> *nod*
<seb128> I just read you reply not the question
<pitti> seb128: [11:22:05] pitti: I was considering if could be feasible switching from tsclient to remmina (formerly known as grdc) as default RDP client for Lucid. The latter is actively maintained upstream, has the same features implemented in tsclient (but it has more), and is less buggy.
<pitti> seb128: that was the entire context
<seb128> oh, no opinion about that
<seb128> I neither use rdp nor know about remmina
<seb128> I just use vnc and vinagre for that one
<seb128> but mailing the list seems a good idea to get some user opinions
<pitti> IMHO it would just replace a specialized program with another specialized program
<pitti> maintenance is certainly an issue, of course
<seb128> well if it's better maintained and less buggy and people want to do the work I will not say no
<slytherin> As some4one who has used both vnc/RDP and clients vinagre/tsclient, vinagre doesn't come close to tsclient. I don't know how good is grdc.
<seb128> I've no interest to work on either of those though
<pitti> slytherin: usability wise, performance wise, or in which regard?
<seb128> slytherin, what does tsclient do better? extra option? stability? speed?
<pitti> VNC is utterly slow, but that's a matter of protocol, not implementation (mostly)
<slytherin> seb128: pitti: tsclient is better in all regards. I never faced any problem with both vnc as well as RDP.
<seb128> pitti, depends if that's because compression is not on for some reason
<seb128> slytherin, not very a constructive comment to know what vinagre needs to do better
<slytherin> seb128: pitti: Vinagre did not support compression and low color depth until 2.29.x (which is not available in any stable release)
<slytherin> and no support for low color depth means 'not usable on slow connections'
<seb128> "until 2.29"
<seb128> which means it's fixed in lucid?
<seb128> anything else that needs to get done there?
<slytherin> It is fixed in 2.29.x as per upstream developers. I haven't actually tested it.
<seb128> right, news states that too
<seb128> need to restart my session brb
<pitti> argh, disconnected; I blame the tunnel we just passed through
 * pitti waves until tomorrow; IRC on the train is too clumsy
<StevenK> Haha
<slytherin> pitti: It will be great if you can approve evolution-mapi for karmic-proposed soon. :-)
<mr_pouit> what's the preferred option if we want to add ubiquity slideshow for Xubuntu? Create a dedicated package (ubiquity-slideshow-xubuntu?), or ask for a 'xubuntu' directory inside the current ubiquity-slideshow-ubuntu (will ubiquity know which ones it should use?)?
<didrocks> cjwatson: sorry, I was away. I guess you was prefering printf to echo (even without -e option). You can change it to echo if you prefer (or I can do it if you wish)
<didrocks> cjwatson: do you want me to rebuild on evand's fix?
<DktrKranz> pitti: partly. IIRC vinagre is currently able to access to VNC only, a RDP plugin is planned but still not implemented. I'll send a mail to -desktop with additional info, thanks!
<cjwatson> didrocks: I guess you need to
<cjwatson> didrocks: echo '<string not beginning with - and not containing \>' is fine
<cjwatson> it's only when you have options and/or escape sequences that it all goes nonportable very quickly
<didrocks> cjwatson: I've just pushed the merge with 'echo' and evand's change into my linked branch
<cody-somerville> chrisccoulson, it would be nice if we could get gnome-screensaver to work again with xfce.
<bdrung> james_w: is bug #503169 fixed? I cannot find version 0.9.6.5-4 in the archive.
<ubottu> Launchpad bug 503169 in downloadstatusbar "Sync downloadstatusbar 0.9.6.5-4 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/503169
<slytherin> bdrung: looks like there is some problem even https://edge.launchpad.net/ubuntu/+source/downloadstatusbar lists -2 as latest version.
<barry> hello ubuntu developers!  i'm trying to package my first python library but i'm having some problems.  does anybody have time to help a n00b?
<ev> barry: #ubuntu-motu would be a better starting point.
<barry> ev: thanks! /me -> #ubuntu-motu
<falktx> hi
<falktx> I'm having problems compiling opengl stuff in Lucid PPAs
<falktx> it always fails detecting opengl/glu libs
<falktx> is this a known issue?
<sistpoty|work> falktx: yes, it is
<falktx> ok, thanks
<falktx> at first I though I was doing something wrong
<falktx> then 2 package failed with the same error
<blackxored> hello
<blackxored> why songbird isn't in the repos, anyone working on it???
<directhex> blackxored, it bundles a heavily modified xulrunner, so i doubt it would pass NEW until it builds against "normal" xulrunner
<blackxored> directhex, oh I now I see
<blackxored> it's detached from the xulrunner we have in ubuntu, or it's a fork or something
<blackxored> or just a new version
<blackxored> ?
<directhex> forked
<blackxored> directhex, and the only program using that fork in songbird?
<ScottK> directhex: Given that we're taking chromium in the archive and it essentially bundles a copy of everything, I'm not sure how much we care.
<directhex> ScottK, oh, can i upload moonlight 2.0 then, which bundles mono 2.6?
<ScottK> You can upload it.  I won't be the one that decides if it gets in.
<blackxored> no, I won't encourage bad practices
<blackxored> and that for sure won't get accepted in debian
<blackxored> so I'll wait
<blackxored> is anyone interested in working on this package to get in touch with?
<directhex> ScottK, well, sure. but there remains more hard work to get it finished, and i abandoned it when i hard ftpmaster say it'd get outright refused for bundling. so is there an actual policy difference in ubuntu, or simply a "policy says foo, but... but... but... chromium!"
<ScottK> I think it's more the latter.
<directhex> yeah, i suspected as much
<zul> pitti: when you get a chance can you move landscape-client from -proposed to -updates?
<ScottK> lamont: Looks like whatever you did to artigas yesterday helped, but not enough to actually get it building packages ....
<ccheney> did kdelibs ever get built properly?
 * ccheney needs to know when to retry OOo
<ccheney> hmm looks like it is done on all but arm
<Riddell> ccheney: opengl is still broken as far as I know so it won't work currently
<ccheney> Riddell: oh
<ccheney> :-\
<ccheney> set amd64 to retry but won't bother with the others then
<ccheney> Riddell: did you mean opengl is just broken on arm or that kdelibs won't work generally?
<ScottK> ccheney: It's kdebase-workspace you want to watch.
<ScottK> ccheney: mesa is broken generally.
<ccheney> ok
<ScottK> Also it's kde4libs you want to be watching.  kdelibs is the kde3 one.
<ccheney> oh i see
<ScottK> ccheney: At this point you may want to consider not retrying until after the Alpha given how long the builds take ...
<ScottK> (not sure)
<ccheney> yea
<ccheney> slangasek: ^ looks like due to opengl/kde4libs breakage the OOo upload I did won't be building in time for alpha
<lamont> ScottK: sigh
<chrisccoulson> siretart` - there?
<hyperair> slangasek: by "something like this" do you mean the template script disabled by default, or have a script shipped in pm-utils by default?
<hyperair> i mean have the script enabled or disabled by default?
<kees> pitti: where did the workitems go?  404 on http://piware.de/workitems/
<ScottK> Must mean you're done.
<slangasek> hyperair: well, in /my/ opinion we should figure out how to get it right so that we can enable it by default
<slangasek> hyperair: as a user who frequently swears at his NFS mounts after resuming his laptop in a new location :)
<hyperair> heheh
<hyperair> okay
<hyperair> so we should enable it by default, and let whoever doesn't want it chmod -x it?
<hyperair> slangasek: but what remote filesystems do we have to cater for?
<hyperair> slangasek: there's nfs and cifs for the non-fuse filesystems (i'm not sure if there are any more) but there are also fuse.ssh, among other fuse filesystems. then there are gvfs mounts which a pm-utils script probably won't be able to touch.
<slangasek> hyperair: the same list of fs types that mountall uses; if there are things mountall doesn't handle as network filesystems but needs to, that should be fixed first
<hyperair> slangasek: i thought as much, but when i dug through the mountall code, it seems that all it does upon SIGUSR1 (network device up) is to run through the unmounted stuff from fstab and try mounting them.
<slangasek> hyperair: hmm, I don't think it's possible for mountall to work correctly unless it has a concept of remote mounts, /somewhere/.
<hyperair> slangasek: no, not necessary. upon sigusr1, it just has to mount -a again. everything that wasn't already mounted will be mounted. stuff that didn't get mounted the first round due to lack of network will probably be mounted this round, when there is a network.
<hyperair> slangasek: that said, it doesn't actually call mount -a.
<hyperair> lemme find the code..
<hyperair> no wait
<hyperair> there's a is_remote(mnt) there
<hyperair> lemme go check
<slangasek> hyperair: no, it really does need to know which ones are remote, otherwise it can't behave sensibly wrt deferring them at boot-time and breaking the dependency cycle with network-manager
<hyperair> ah
<hyperair> slangasek: http://pastebin.com/f3e5b6c20
<hyperair> that's the is_remote function.
 * slangasek nods
<slangasek> "smbfs" - obsolete, should be pruned from that list :)
<hyperair> mm
<hyperair> what if the user was using some legacy kernel to boot?
<hyperair> =
<hyperair> =p
<slangasek> then udev would laugh at them
<hyperair> heheh
<hyperair> right
<hyperair> what about the fuse network filesystems?
<slangasek> also, we haven't shipped the userspace tools for mounting smbfs for 3 cycles
<slangasek> fuse> dunno, but it's not a problem specific to this proposed change, mountall also has the problem
<hyperair> yes, agreed
<slangasek> (and we can only sensibly unmount those shares that are listed in /etc/fstab, otherwise we can't remount them from the user afterwards...)
<hyperair> but fuse mounts are less likely to be in the fstab
<slangasek> s/from/for/
<hyperair> fuse mounts are more likely mounted by the user after boot. so mountall isn't as impacted
<hyperair> as for safely remounting for the user...
<hyperair> it is possible to dump /proc/mounts out
<hyperair> just the required filesystems.
<hyperair> how do you handle spaces in fstab?
<hyperair> like spaces in the path to mount, or the mount point
<cjwatson> hyperair: fstab(5) describes how to escape spaces
<hyperair> ah okay thanks
<cjwatson> hyperair: there are actually a few more escapes than that - see getmntent(3)
<hyperair> the output of mount looks pretty hard to parse for a shell script though
<cjwatson> that's at least part of why Keybuk wrote mountall ...
<lool> So my system went to 100% CPU during my last upgrade and hung, had to hard reboot, and is not coming up anymore; it fails with /sbin/init: I/O error
<lool> Oddly, if I try /bin/bash as init I get the same kind of error
<lool> This is with ext4 on a SSD, so I would be surprized if any hardware is involved
<lool> Is there any known bug which could cause this?
<lool> I think I'll boot on an USB key and fsck /
<siretart> chrisccoulson: now, yes?
<hwilde> seen persia
<hwilde> !seen persia
<ubottu> I have no seen command
<hwilde> :/
<Pici> hwilde: also... hes online now
<tseliot> lamont, NCommander: can you rescore the builds for mesa, please? Kubuntu depends on it
<lamont> tseliot: any particular architecture?
<tseliot> lamont: definitely i386 and amd64
<tseliot> nixternal, Riddell: anything else? ^^
<lamont> 7.7-0ubuntu4?
<lamont> (it's these little details that help ...)
<tseliot> lamont: yes, that one
<lamont> tseliot: so it's been building for at least a few minutes everywhere but ia64 and sparc...
<lamont> and funny thing, launchpad.net/builders shows empty queues everywhere except those two architectures...
<lamont> so why did you want it rescored when it's already building???
<tseliot> lamont: oh, fantastic
<nixternal> ScottK: ^^
<nixternal> :)
<tseliot> lamont: I checked that before asking you. Never mind. Thanks anyway. I might need your help later
 * tseliot > dinner (brb)
<NCommander> tseliot, ah, lamont beat me to it
<NCommander> tseliot, ScottK, I'll be looking at kdelibs tonight
<lamont> NCommander: no, build-manager beat both of us
<NCommander> lamont, :-)
<lool> FTR, I managed to fix my laptop with dpkg --root /mnt --force-architecture --unpack /mnt/var/cache/apt/archives/libc6*.deb after I saw that dpkg.log was interrupting in libc6 packages
<lool> Now I'm checking why the new initramfs doesn't have /init
<lool> Hmm it does but I get a cannot run /init error
<lool> FTR again: finished recovering by recreating initrd forcefully after the upgrade with a partially broken libc; boots fine again
<chrisccoulson> siretart - was it you who suggested trying XResetScreenSaver for bug 428884?
<ubottu> Launchpad bug 428884 in gnome-screensaver "gnome-screensaver-command --poke no longer inhibits screensaver" [Medium,Fix released] https://launchpad.net/bugs/428884
<kirkland> pitti: did http://www.piware.de/ die?
<kirkland> pitti: 404
<jiboumans> kirkland: i reported the same; rickspencer's pinged him
<siretart> chrisccoulson: I'm not sure if it was exactly that function, but i remember it was from libxscreensaver
<kirkland> jiboumans: cool, thanks
<chrisccoulson> siretart - XResetScreensaver is just plain xlib, rather than xscreensaver, although I haven't tried to see if it works yet
<chrisccoulson> i was going to credit you in the changelog if it works ok, but i wasn't sure if it was you who suggested it originally
<siretart> chrisccoulson: actually, I first considered XResetScreensaver, but then you've pointed me the various screensaver APIs IIRC
<siretart> chrisccoulson: so does XResetScreensaver reset the idle counter after all?
<chrisccoulson> siretart - i'm not sure yet, i'm just about to try it
<chrisccoulson> but i found some bits in google when i was at work earlier which suggests it may do now
<siretart> if it doesn't, perhaps it could be extended to do so in the xserver?
 * sebner hugs tseliot as he sees his gnome-shell build again :D
<tseliot> sebner: it took a while but it seems that it was worth it ;)
<sebner> tseliot: hmm reminds me about our nvidia testing session :P
<tseliot> sebner: this one was more intense and my filesystem died this time ;)
<tseliot> (without rebooting)
<sebner> tseliot: hahahahaha, mine with rebooting you know .. so we are even now :P
<tseliot> ;)
<chrisccoulson> siretart - looking in the xorg code, lastDeviceEventTime is updated when calling XResetScreenSaver, and I think that is where IDLETIME comes from
<chrisccoulson> so it should work fine :)
<chrisccoulson> but my xorg knowledge is not so great
<chrisccoulson> i'll just try it and see ;)
<tseliot> lamont, NCommander: I uploaded xorg-server and it built against mesa 7.7-0ubuntu3 instead of 7.7-0ubuntu4: http://launchpadlibrarian.net/37745022/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.3.902-1ubuntu4_FAILEDTOBUILD.txt.gz
<lamont> prolly hasn't published yet.
<lamont> patience is a virtue, to quote another wiki page... :-(
<lamont> and it's not somethign I can fix
<lamont> that requires an archive admin
<tseliot> lamont: ok, thanks
<slangasek> what does?
<slangasek> is mesa stuck in new?
<tseliot> slangasek: I don't think it should
<lamont> that or it needs a publisher run?  I'll go with 'prolly new'
<slangasek> no, i386 and amd64 are installed; looks like it was a timing problem
<tseliot> slangasek: can I retrigger the build now?
<tseliot> I'll take it as a yes
<slangasek> yes, please :)
<chrisccoulson> siretart - it doesn't work in lucid :(
<chrisccoulson> but does in karmic
<tseliot> lamont: can you rescore this, please? https://launchpad.net/ubuntu/+source/xorg-server/2:1.7.3.902-1ubuntu4/+build/1441164
<tseliot> this time you can't say that I didn't give you enough details ;)
<lamont> done
<lamont> tseliot: and that was absolutely perfect
<tseliot> lamont: thanks a lot :-)
<ion> The smooth transition from plymouth to X is really nice. Yay to Keybuk for making plymouth work.
<TheMuso> All well and good for those with KMS hardware. :p
<RAOF> And don't have encrypted filesystems ;)
<tseliot> RAOF: I haven't had time to work on that but I should fix it soon
<RAOF> Oh, your the one in charge of that?  Cool.
<ion> Now if i could actually use KMS. It breaks vsync with Xv. (I should really get around to reporting a bug, unless one already exists.)
<chrisccoulson> siretart - http://bugs.freedesktop.org/show_bug.cgi?id=25855
<ubottu> Freedesktop bug 25855 in Server/general "Screensaver not disabled because of a XResetScreenSaver() regression" [Normal,New]
<tseliot> RAOF: I wrote the theme (which is a program written in its own language) and but I didn't take care of the use-case of disk encryption
<tseliot> it looks like Keybuk took care of that nasty vt problem
<tseliot> :-)
<ari-tczew> tseliot, thanks for nvidia-settings, could I later merge package with Debian?
<tseliot> ari-tczew: why do you want to do that?
<tseliot> (just asking)
<ari-tczew> feel clean up between systems
<tseliot> ari-tczew: feel free to try but please contact me before you upload that
<ari-tczew> tseliot: sure of course, now other question: is it possible to provide nvidia driver 190 by nvidia-glx-190 instead nvidia-glx-185?
<tseliot> ari-tczew: it's called nvidia-current now
<tseliot> ari-tczew: it might not work today but it should tomorrow
<ari-tczew> ok
<ScottK> NCommander, lamont, elmo, pitti: Would one of you please rescore xorg-server to build first.  It's the critical path item in getting out of the mesa mess at the moment.
<lamont> ScottK: that'd be what tseliot had me do a bit back
 * tseliot nods
<lamont> and yellow is back in the hunt
<ScottK> lamont: OK.  Just making sure.  Thanks.
 * tseliot -> off for a bit
<ari-tczew> any sponsor for main is working on merges?
<chrisccoulson> slangasek - a recent gnome-screensaver SRU has caused a regression in karmic (bug 505789). i think the best thing to do is back out the patch which caused it and re-open the original bug, as there is no viable solution for fixing the original issue at the moment
<ubottu> Launchpad bug 505789 in gnome-screensaver "gnome-screensaver-command -p triggers keyboard event" [Critical,In progress] https://launchpad.net/bugs/505789
<chrisccoulson> do you think that's the right thing to do?
<slangasek> chrisccoulson: it's a reasonable thing to do, and I trust your analysis wrt the viability of a complete solution
<slangasek> if one shows up later, it's always an option to SRU with a better patch
<chrisccoulson> slangasek - ok, i'll do that. do i need to go through the usual route of uploading to karmic-proposed, and could you process the SRU?
<slangasek> chrisccoulson: you mean bypass karmic-proposed entirely?
<slangasek> I would prefer that the upload go via karmic-proposed, but we don't have to wait 7 days before copying
<chrisccoulson> slangasek - ok, thanks. i'll work on that now
#ubuntu-devel 2010-01-12
<chrisccoulson> slangasek - i've uploaded gnome-screensaver to karmic-proposed now
<TheMuso> ~s/c~s
<silas428> is floodbot an actual bot?
<genii> silas428: Yes
<silas428> genil: k, thought I was getting flooded out of #ubuntu for a second
<genii> Well, no physical incarnation
<silas428> is #ubuntu down or something?
<Pici> no?
<ari-tczew> [01:20] [Uwaga] -ChanServ- [#ubuntu] Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there - This channel is officially logged at
<silas428> I get an error message saying something is wrong with my router
<silas428> Every other chat room works just fine
<Pici> silas428: Then you should read the topic of the channel you were forwarded to
<Pici> silas428: If you have any further questions you can ask in #ubuntu-ops
<silas428> Pici: I did, I just didn't bother updating yet
<ScottK> chrisccoulson: In the event of an SRU related regression, the Tech Board is to be notified.  If you didn't, I recommend writing them with the details of the issue and the resolution.
<chrisccoulson> ScottK - thanks, I'll do that
<ScottK> Good.
<eboyjr> I'm thinking about cleaning up jockey-gtk a little bit.. Where should I start?
<ScottK> eboyjr: Probably by talking to pitti.
<Plagman_> why is libGLU.so in /usr/lib/mesa now?
<Plagman_> shouldn't there by a symlink from /usr/lib/libGLU.so to /usr/lib/mesa/libGLU.so.1 if you're going to do that?
<Plagman_> s/by/be/
<ScottK> Plagman_: It should be OK in the most recent upload.  If you want to discuss it, #ubuntu-x is probably the best place.
<Plagman_> ScottK : alright, thanks
<Plagman_> I'll be sure to check the most recent packages
<Kurlon> Evening all.
<Kurlon> Is the nvidia driver conflict with xorg-server resolved at this point in the lucid repositories, or is it still glitching?
<ScottK> Kurlon: #ubuntu-x is a better channel to ask.
<Kurlon> Ah, ok, figured given I was mucking with an alpha #dev would be the safer start.  I'll ping in there instead, danke!
<jelmer> ScottK, hi
<ScottK> Hello jelmer
<jelmer> ScottK: So, I'm trying to get bzr-svn to understand the KDE svn repository a bit better. Is there a description of the structure of the repository somewhere?
<ScottK> jelmer: Not particularly, but with the exception of the kdebase split, it follows the Debian packages pretty closely.
<ScottK> The getting started page I linked to explained it a little bit.
<ScottK> The other thing you need to know is that there are roughly four catagories of software there:
<ScottK> 1.  KDE core
<ScottK> 2. KDE support (stuff needed to build KDE core, but not KDE specific (akonadi is an example))
<ScottK> 2.  Extragear - Applications that aren't part of KDE core, but have a certain quality, stability, etc.  May or may not follow the KDE release schedule
<ScottK> 4.  Playground - could be anythings.
<ScottK> 2/3 on extragear
<jelmer> ScottK: I'm basically trying to come up with patterns for things that should be considered branches in bzr
<ScottK> For KDE core it's pretty easy
<ScottK> Everything in the branches directory is a branch off of trunk
<dholbach> good morning
<hyperair> how does one get bug triaging powers?
<hyperair> like the power to set the bug status to triaged
<maco> hyperair: join bug control
<hyperair> ah okay
<dholbach> https://wiki.ubuntu.com/UbuntuBugControl
<hyperair> thanks
<hyperair> That you promise to be polite to bug reporters, even if they don't deserve it, by signing the Ubuntu Code of Conduct.
<hyperair> ..oh hey i've violated that already
<hyperair> more than once.
 * hyperair repents
<pitti_> bonjour
<slangasek> b'jou
<ttx> pitti: bonjour
<ttx> pitti: about the new work item reports -- how do you determine someone is in a given team ?
<ttx> pitti: soren is currently on loan in the QA team, and his work items clutter our alpha2 report :P
<pitti_> ttx: it reads the members from LP
<pitti_> ttx: hang on, rickspencer3 doing his opening speech
<ttx> sure
<ttx> He is doing it in French, I hope.
<ttx> mvo: hey, about bug 494499, do you plan to release it for alpha2 ?
<ubottu> Launchpad bug 494499 in update-manager "MOTD shows "run-parts: /etc/update-motd.d/91-release-upgrade exited with return code 1"" [Medium,Fix committed] https://launchpad.net/bugs/494499
<mvo> ttx: yes, I upload today, sorry for the delay
<ttx> mvo: no pb, just making sure it will land, since it's still in the current dailies :)
<ttx> pitti, cjwatson, slangasek: same issue as yesterday, please trigger a server CD respin, newest eucalyptus landed too late
<ttx> slangasek: we now have on servers (hardware permitting) a graphical KSM-flicker-free Ubuntu logo. However it's not replaced by a login prompt at the end. The logo stays there until you swap VTs. I'd say that's a bug, but what should I file it against ?
<slangasek> ttx: as a starting point, 'plymouth'
<slangasek> server respin triggered
<ttx> slangasek: thx
<ttx> slangasek: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/506297
<ubottu> Launchpad bug 506297 in plymouth "Graphical Ubuntu logo enabled on servers, no more login prompt" [Undecided,New]
<ttx> slangasek: I milestoned it to alpha2, I think we should at least try to fix it.
<slangasek> ttx: nack; this behavior change was prompted by serious incompatibilities with plymouth's VT handling prior to this point, and Keybuk has limited availability this week - I'm afraid this is errata territory
<ttx> slangasek: ok, alpha3 it is, then ;)
<slangasek> yep - sorry :)
<ttx> slangasek: anything I should do to make it appear on the errata ?
<slangasek> ttx: add it to https://wiki.ubuntu.com/LucidLynx/TechnicalOverview directly? :)
<ttx> slangasek: right :)
<seb128> hello
<seb128> so today's upgrades are a fail in lucid there
<seb128> the mini10 displays what seems to be plymonth and then no screen
<seb128> no way to vt switch and I don't manage to open the grub2 menu
<seb128> and my laptop has no x cursor displayed
<seb128> it works since I can click on things but I don't see it
<seb128> and compiz is broken
<seb128> did plymouth broke xorg or something?
<seb128> where is Keybuk? ;-)
<slangasek> "don't manage to open the grub2 menu"?
<slangasek> holding down shift?
<seb128> oh, shift
<seb128> I tried esc and tab
<seb128> thanks
<seb128> what was wrong with the good old esc? ;-)
<seb128> hum, booting without splash doesn't fix the issue
<seb128> did the x guy broke the intel driver or something?
<slangasek> there've been mesa changes in the past couple of days
<slangasek> the X driver itself hasn't been touched, and isn't that the kernel's job now anyway? :)
<seb128> it's weird that I don't get vts either
<seb128> can I turn kms off from grub?
<slangasek> yes, i915.modeset=0
<slangasek> (IIRC)
 * alkisg is also interested in this, as he has an intel based thin client which broke with today's updates...
<seb128> Xorg.0.log says that "glx doesn't exist"
<seb128> wth?
<seb128> tjaalton, bryyce: ^
<slangasek> seb128: ls -l /etc/alternatives/gl_conf?
<slangasek> (this is the mesa stuff I mentioned)
<seb128> $ ls -l /etc/alternatives/gl_conf
<seb128> lrwxrwxrwx 1 root root 24 2010-01-12 02:46 /etc/alternatives/gl_conf -> /usr/lib/mesa/ld.so.conf
<slangasek> and that file is present?
<seb128> yes and contains "/usr/lib/mesa"
<alkisg> slangasek: thanks, i915.modeset=0 did the trick for me.
<slangasek> seb128: ldconfig -p | grep libGL?
<MacSlow> bryyce, still/already up?
<slangasek> alkisg: sure thing
<seb128> trying to turn kms off on the mini now
<seb128> $ ldconfig -p | grep libGL
<seb128> 	libGLU.so.1 (libc6) => /usr/lib/mesa/libGLU.so.1
<seb128> ...
<MacSlow> hm... guess I join the right conversation here
<bryyce> MacSlow, are you pinging me?
<seb128> anything special you want there?
<seb128> bryyce, I did
<MacSlow> bryyce, just see all folks here are talking about the GLX-issue
<seb128> bryyce, the mini10 doesn't boot since this night update
<seb128> blank screen
<seb128> and glx is broken on my laptop
<seb128> cf running discussion
<seb128> all intel cards
<seb128> i965 on the laptop
<MacSlow> seb128, here too... what I see/know... apps using dlopen("libGL") work (e.g. chromium with WebGL enabled, doom3) but apps using normal GLX (glxinfo, glxgears, compiz) don't
<MacSlow> seb128, on nvidia-glx-195 here
<bryyce> MacSlow, it is the mesa alternatives system rework probably
<bryyce> https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/258038
<ubottu> Launchpad bug 258038 in xorg-server "Look into feasibility of using an alternatives system rather than diversions" [Wishlist,In progress]
<seb128> good timing with alpha2 freeze today ;-)
<seb128> bryyce, what would be useful in a bug report?
<seb128> I'm not sure what info to provide there...
<slangasek> bryyce: what's supposed to provide the actual GLX /extension/ for X?
<slangasek> is that built into the core server?
<bryyce> slangasek, for open source drivers, mesa provides it; for closed source it is the closed source drivers providing it
<slangasek> bryyce: yah, mesa isn't providing it now
<slangasek> er, no
<slangasek> $ dpkg -S /usr/lib/xorg/modules/extensions/libglx.so
<slangasek> xserver-xorg-core: /usr/lib/xorg/modules/extensions/libglx.so
<slangasek> $ ls -l /usr/lib/xorg/modules/extensions/libglx.so
<slangasek> ls: cannot access /usr/lib/xorg/modules/extensions/libglx.so: No such file or directory
<slangasek> so something deleted my libglx.so \o/
<bryyce> that's weird
<slangasek> by "something" I'm pretty sure I mean "mesa"
<superm1> MacSlow, if you are using a binary package nvidia-glx-195, that means that it wasn't one of the packages that was enabled for that alternatives system yet
<superm1> MacSlow, you should switch to nvidia-current (which is complete in the archive currently)
<MacSlow> slangasek, fyi I'm you example-case for someone using nvidia-glx-195 and being affected by this
<seb128> superm1, and for those who use intel?
<bryyce> xserver-xorg-core.postinst.in:    --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/standard-x11/libglx.so \
<slangasek> MacSlow: ah, ack
<seb128> bryyce, the actual file has been deleted, did it move between binaries recently?
<MacSlow> superm1, oh nvidia-current... didn't know about that new package-name
<seb128> bryyce, hum or not
<superm1> MacSlow, the official packages should have transitioned you over, but -195 was never in the archive (and neither was -190)
<superm1> seb128, for -intel, things should be working ;)
<seb128> bryyce, that code is not in the postinst
<seb128> $ grep glx /var/lib/dpkg/info/xserver-xorg-core.postinst
<seb128> $
<slangasek> seb128: version?
<seb128> ii  xserver-xorg-core                     2:1.7.3.902-1ubuntu4                       Xorg X server - core server
<slangasek> ok
<slangasek> bryyce: are you around to follow that up, or do we need tjaalton ?
<seb128> did somebody forget to update the postinst from the .in?
<slangasek> seb128: well, /usr/lib/standard-x11/libglx.so also doesn't exist here
<seb128> hum
<seb128> xorg-server (2:1.7.3.902-1ubuntu4) lucid; urgency=low
<bryyce> slangasek, following up with tseliot would be best
<seb128> "- Do not install an alternative any more. Mesa will deal with this.
<seb128> "
<seb128> bryyce, slangasek: ^
<bryyce> seb128, what I pasted was from prior to this latest change
<seb128> ok
<bryyce> yeah probably follow up with tseliot when he wakes
<superm1> slangasek, could you see why the mythbuntu live disk job didn't run yesterday? I don't even see a log at http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/lucid/
<seb128> tseliot, !!!
<seb128> hey ;-)
<slangasek> tseliot: which package is supposed to be shipping extensions/libglx.so in the new world order?  Because it isn't
<tseliot> slangasek: xserver-xorg-core
<slangasek> superm1: the CD build job won't run if the livefs build failed; have you looked there?
<tseliot> what happened?
<seb128> tseliot, it doesn't
<seb128> tseliot, libglx.so vanished
<tseliot> let me check
<seb128> tseliot, in yesterday's updates
<superm1> slangasek, ah that's what's up.  i didn't realize that behavior changed. thanks :)
<slangasek> superm1: ah yes, last cycle :)
 * seb128 hates grub2
<seb128> you would think it takes less that 15 tries to get the menu to open on boot
<mr_pouit> superm1: I think I saw some testers write that hal wasn't started automatically in our iso for lucid, so xfce4-session, thunar & xfce4-power-manager were somewhat useless/broken. Did you have a chance to test?
<slangasek> seb128: holding the shift key down?
<slangasek> seb128: (more effective than trying to hit it at the right moment; part of why we the shift key was chosen)
<superm1> mr_pouit, i've been poking at little installer snippets of troubles, so not yet any hal integration tests
<seb128> slangasek, I will try on next boot, I was hitting shit a zillion time there
<superm1> mr_pouit, you might run into a problem that xubuntu-default-settings needs to be reconfigured before you boot for the first time
<superm1> mr_pouit, perhaps a ubiquity post install hook needs to be added
<seb128> bryyce, tseliot: yesterday's update made the mini10v boot with screen off too
<seb128> bryyce, tseliot: it works when turning off kms
<seb128> bryyce, tseliot: which component would be right to bug?
<tseliot> seb128: is it plain ubuntu or the netbook remix?
<tseliot> slangasek: the extensions are definitely there. Can I see an X log, please?
<seb128__> re
<tseliot> I think it's because X looks for them in a different directory first
<slangasek> tseliot: no, the file is physically *not there* on our systems
<seb128__> grrr
<slangasek> I don't have an X log for this, I haven't restarted X yet
<slangasek> tseliot: so something deleted it on upgrade
<seb128__> bryyce, tseliot: did you get my mini question?
<seb128__> today's update make that on have screen off on boot
<seb128__> it works without kms though
<tseliot> seb128__: is it plain ubuntu or the netbook remix?
<seb128__> lucid stock
<slangasek> tseliot: it's still registered with dpkg (dpkg -S knows what package owns it), but something removed it
<seb128__> I use it as a bootchart box
<tseliot> slangasek: I extracted the package and the files are there.
<slangasek> yes
<tseliot> aah
<seb128__> is there an another package Replacing it?
<tseliot> no, I don't think so
<seb128__> could be a replaces, update race
<seb128__> ok...
<tseliot> let me check on my testing box
<seb128__> tseliot, which component is the right one to bug for the mini bug?
<seb128__> tseliot, it's not linux, boot an old version doesn't work
<seb128__> and booting without splash doesn't work
<seb128__> turning off kms does work though
* pitti changed the topic of #ubuntu-devel to: Lucid Alpha 1 released | Archive: open | MoM no longer running, use bzr! - Outstanding merges:http://people.ubuntuwire.com/~lucas/merges.html | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> (removed the locale-gen stuff)
<tseliot> seb128__: what do you mean by "the screen is off"?
<seb128__> tseliot, nothing is displayed
<tseliot> just to be clear
<seb128__> no VT, no xorg
<tseliot> aah
<seb128__> I just see plymonth and then nothing
<seb128__> plymouth
<slangasek> oh, you do see plymouth?
<seb128__> booting without splash I see nothing
<seb128__> slangasek, yes
<seb128__> if I remove the "splash" boot option I see nothing though
* persia changed the topic of #ubuntu-devel to:  Lucid Alpha 2 freeze | Archive: open | MoM no longer running, use bzr! - Outstanding merges:http://people.ubuntuwire.com/~lucas/merges.html | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<seb128__> no text, no xorg
<persia> (mention alpha 2 freeze)
<slangasek> seb128__: "no text" - have you checked your other VTs?
<slangasek> persia: ta
<seb128__> slangasek, yes, as said
<seb128__> <seb128__> no VT, no xorg
<seb128__> slangasek, there are all blank
<slangasek> ok
<tseliot> seb128__: I think it's the same problem that slangasek reported
<lool> tseliot: Hey, got a warning during nvidia-common upgrade yesterday due to some quoting issue in the .config script; I don't know which way to fix it
<lool> Oh great timing
<bryyce> lool, I think that bug was fixed now
<slangasek> tseliot: seb128__ does have the same problem I mentioned, he was the one who brought it to my attention; but that doesn't explain lack of text consoles AFAICS
<lool> tseliot: On line 11 of /var/lib/dpkg/info/nvidia-common.config
<seb128__> tseliot, the glx issue lead to have no compiz on my laptop
<lool> tseliot: It was indeed; thanks
<tseliot> np
<seb128__> tseliot, but the mini get no screen content at all, either xorg or vt
<seb128__> tseliot, and without kms it works...
<lool> bryyce: Uh thank you too
<bryyce> heh
<tseliot> seb128__: I can reproduce it here with -ati
<seb128__> tseliot, the boxes I'm using at all intel
<seb128__> but good
<seb128__> I will let you sort if it you have the issue locally ;-)
<tseliot> I'll let you know when it's fixed
<seb128__> thanks
<tseliot> seb128, slangasek: does reinstalling xserver-xorg-core solve the problem?
<slangasek> tseliot: I'm sure it will; but first I'm trying to see if I can reproduce the upgrade failure path
<slangasek> (so I can understand what happened, which currently I don't)
<tseliot> neither do I :-/
<slangasek> the old prerm should have triggered before unpack of the new package, so there shouldn't have been any weird interaction between update-alternatives and dpkg
<seb128> slangasek, well they moved the alternative handling to a different binary now
<seb128> could that create some races between alternative and xorg upgrade?
<slangasek> seb128: I don't see any alternative handling at all for libglx.so on my system
<seb128> like the alternative is registered first
<seb128> then xorg is update
<slangasek> unless it was in an earlier version of mesa and removed again?
<seb128> and the binary get cleaned?
<tseliot> the alternatives were handled by X while they there are handled by mesa
<slangasek> tseliot: is there still an alternative for libglx.so?
<tseliot> slangasek: no, there isn't.
<tseliot> now what happens is that X looks for extensions in /usr/lib/xorg/extra-modules first and then in /usr/lib/xorg/modules/extensions/
<tseliot> so that when /usr/lib/xorg/extra-modules (which is a link created by alternatives) points to, say, /usr/lib/nvidia-current
<tseliot> the modules in that directory will have a higher priority
<tseliot> while the standard modules remain in their old directory
<tseliot> if the link doesn't exist and/or the modules aren't in /usr/lib/xorg/extra-modules, it falls back to /usr/lib/xorg/modules/extensions/
<tseliot> this, however, doesn't explain why those modules were removed in the first place :-/
<alkisg> apt-get install --reinstall xserver-xorg-core fixed the problems for me.
<tseliot> right
<seb128> pitti, could you run "grep libglx /var/lib/dpkg/info/*" since you didn't upgrade yet?
<tseliot> slangasek: hopefully the apt, dpkg, etc. logs will give us some clues
<pitti> /var/lib/dpkg/info/xserver-xorg-core.list:/usr/lib/standard-x11/libglx.so
<pitti> /var/lib/dpkg/info/xserver-xorg-core.md5sums:465cb23fcebef8712baf1b9c70453d3b  usr/lib/standard-x11/libglx.so
<pitti> /var/lib/dpkg/info/xserver-xorg-core.postinst:    --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/standard-x11/libglx.so \
<pitti> seb128: ^
<slangasek> so far I know that I had xserver-xorg-core 2:1.7.3.902-1ubuntu1 installed when I last restarted X, upgraded to 2:1.7.3.902-1ubuntu4 directly, and the file is now gone; and that mesa and X were upgraded in the same run
<pitti> I have 2:1.7.3.902-1ubuntu2
<slangasek> and that an upgrade of just the X server from 1ubuntu1 to 1ubuntu4 doesn't reproduce the failure
<slangasek> examining my unpack order now
<seb128> pitti, thanks, so maintainer script playing with that on upgrade...
<slangasek> seb128: that's the postinst of the old version
<seb128> slangasek, right, I was try to check if some prerm or something played with that
<slangasek> the relevant script there is actually the prerm of the old version, which doesn't pattern-match because it calls update-alternatives --remove with only the master name (gl_conf)
<seb128> oh right
<seb128> pitti, grep gl_conf /var/lib/dpkg/info/*
<seb128> pitti, can you try that one too?
<tseliot> libglx.so and libdri.so were previously installed in /usr/lib/standard-x11/
<seb128> slangasek,
<seb128> /var/lib/dpkg/info/libgl1-mesa-glx.prerm:  update-alternatives --remove gl_conf /usr/lib/GL/ld.so.conf
<seb128> slangasek, would that delete the file if called after the xorg unpack?
<tseliot> seb128: does reinstalling xserver-xorg-core solve the problem for you?
<seb128> tseliot, let met try on the mini, I want to keep my laptop in broken state to try the official solution
<slangasek> seb128: I don't know yet - I think it /should/ not, because X's own prerm should have already removed it
<slangasek> oh
<slangasek>   if [ ! -f /usr/lib/standard-x11/standard.conf ]; then
<slangasek>     update-alternatives --remove gl_conf /usr/lib/standard-x11/standard.conf
<slangasek>   fi
<slangasek> well that check is going to fail, because it's in the *pre*rm, so the files is still there
<pitti> /var/lib/dpkg/info/xserver-xorg-core.postinst:    --install /etc/ld.so.conf.d/GL.conf gl_conf /usr/lib/standard-x11/ld.so.conf 500 \
<pitti> /var/lib/dpkg/info/xserver-xorg-core.prerm:    update-alternatives --remove gl_conf /usr/lib/standard-x11/standard.conf
<pitti> seb128: ^
<seb128> pitti, thanks
<slangasek> so the xserver-xorg-core old prerm does *not* remove the alternative; instead it gets removed by something else, later
<slangasek> tseliot: this needs to be fixed by adding an update-alternatives --remove call to the xserver-xorg-core preinst
<tseliot> slangasek: ouch, right
<tseliot> ok, I can do that
<slangasek> tseliot: thanks - how soon do you think you'll have it ready?  (I'd like to confirm the result before nodding off :)
<tseliot> slangasek: minutes?
<pitti> StevenK: just to be sure, you didn't rename lp:~ubuntu-core-dev/ubuntu-seeds/unr.lucid/ right? still the same seed
<slangasek> tseliot: cheers :)
<seb128> tseliot, the xserver-xorg-core reinstall solves the issue yes
<pitti> StevenK: nevermind me, found it
<seb128> tseliot, the mini10 no screen issue too
<tseliot> seb128: aah, the joys of KMS... :-P
<seb128> ;-)
<tseliot> slangasek: do you want me to test a particular condition before passing that command?
<slangasek> tseliot: a version check on $2
<slangasek> tseliot: if dpkg --check-versions "$2" lt-nl 2:1.7.3.902-1ubuntu5; then
<slangasek> superm1: what did you learn regarding mythbuntu livefs failures?
<tseliot> dpkg: unknown option --check-versions
<persia> Is it "check-versions"?  I thought it was "compare-versions"
<tseliot> yes, if that's what he meant
<tseliot> to check
<tseliot> I can do what I usually do with nvidia
<slangasek> yeah, that's what I meant
<slangasek> sorry, 2am fingers
<tseliot> slangasek, persia: does dpkg --compare-versions get the version of a package if you pass it a name?
<tseliot> shouldn't I pass it the version instead?
<slangasek> tseliot: the "$2" is a version
<slangasek> dpkg --compare-versions knows nothing about packages, it just tells you how two specified version numbers compare
 * tseliot needs some glasses now ;)
<tseliot> or more sleep
<persia> tseliot: http://women.debian.org/wiki/English/MaintainerScripts
<tseliot> persia: ok, it was as I thought
 * slangasek notes the diagrams on that page didn't load for him today :(
<tseliot> slangasek: http://pastebin.ubuntu.com/355429/
<tseliot> ok?
<tseliot> I'll take it as a yes ;)
<slangasek> tseliot: yes
<slangasek> (I'm a little hesitant about the || true, but as a first iteration this is certaintly fine)
<tseliot> I don't want things to break, but yes
<pitti> StevenK: FYI, we'll use lp:ubuntu/ubuntu-netbook-default-settings and commit stuff there (didn't find an existing bzr for this)
<tseliot> slangasek: uploaded
<slangasek> tseliot: thanks!
<tseliot> oh, I forgot to give credit to you in the changelog
<tseliot> sorry
<slangasek> <shrug> :)
<bryyce> I see we have Recommends: intel-gpu-tools in xserver-xorg-video-intel, and a MIR was accepted for intel-gpu-tools, however:
<bryyce> # apt-cache madison intel-gpu-tools
<bryyce> intel-gpu-tools |    1.0.2-1 | http://us.archive.ubuntu.com lucid/universe Packages
<slangasek> tseliot: my name is in enough changelogs already, don't sweat it ;)
<bryyce> why's intel-gpu-tools still in universe?
<tseliot> hehe
<slangasek> bryyce: because http://people.canonical.com/~ubuntu-archive/component-mismatches.txt - allow me to fix :)
<bryyce> tseliot, slangasek's name is *everywhere*
<bryyce> slangasek, awesome
<tseliot> :-D
<slangasek> bryyce: btw, please don't close MIR bugs upon seeding, it makes it harder for the archive admin to find the bug to reference for promotion :)
<bryyce> oh
<tseliot> then the next ubuntu flavour will be slangabuntu :-P
<bryyce> slangasek, I don't remember closing the bug, but apologies if I did
<bryyce> slangasek, btw what I'm working towards is enabling apport auto-capture of X freeze bugs for -intel
<bryyce> next step is a packaging fix for -intel to install the apport script.  I can wait until post-a2 unless you think it would be valuable to have for the release.
<slangasek> well, I haven't seen an intel kernel freeze myself for quite a while
<bryyce> :-)
<slangasek> so based on my own limited evidence I wouldn't think it's urgent for a2 - does the bug traffic say otherwise?
<bryyce> fair enough, sounds reasonable to leave this until post-a2.  I've not yet confirmed it works.
<bryyce> slangasek, I've decided there exist a band of merry gnomes who simply re-file the same 20 bugs over and over again, with slightly changed wording each time.
<slangasek> (now having the sigsegv handler working, OTOH, /that/ would be nice :)
<slangasek> heh
<bryyce> yeah, I put in a patch to fix that but seems I didn't get something right.  I need to look at that deeper.
<bryyce> the signal code in X changed around quite a bit, and I never really grokked it all the first time
<tseliot> pitti: can you rescore this please? https://launchpad.net/ubuntu/+source/xorg-server/2:1.7.3.902-1ubuntu5/+build/1442023
<pitti> tseliot: done; amd64 too, or already building?
<pitti> oh, built already
<tseliot> it's building already
<pitti> i386 is screwed
<pitti> kdeutils/linux/oo.o
<pitti> ah, kdeutils is purging already
<pitti> so, shouldn't take long then
<tseliot> ah, good
<tseliot> pitti: BTW the new jockey won't be ready in time for alpha2
<pitti> tseliot: due to the pykdeuic4 breakage?
<tseliot> I didn't have the time to test it
<tseliot> yes
<pitti> ah, for nvidia-common support
<tseliot> that too
<pitti> -> release notes, then
<tseliot> but now nvidia-common is in
 * tseliot nods
<StevenK> pitti: That sounds great
<cjwatson> Riddell,superm1: I have an action from the last TB meeting to ask that the ubuntu-core-dev team be added as a member of kubuntu-dev and mythbuntu-dev, to reflect the fact that they can upload to those packages anyway. Would you guys be OK with making that change?
<cjwatson> seb128: what was wrong with esc in grub> I was instructed to make grub not have a delay to wait for a keypress, and on the PC architecture the only keys whose state you can check instantaneously are the modifier keys
<tjaalton> seb128: the blank screen problem was likely due to vesa (=failsafe) not working on top of kms
<seb128> cjwatson, yeah, sorry for the non constructive comment, the new way is not very discoverable and quite frustrating when you try to get the menu to open
<Riddell> cjwatson: ubuntu-core-dev has been invited to join, I guess something else needs to happen to actually join
<seb128> I tried hitting all the side keys quickly and did that for several times without luck
<cjwatson> seb128: I was told to make it undiscoverable, unfortunately :(
<cjwatson> seb128: or rather I was given instructions that left no possible way to make it discoverable ...
<seb128> cjwatson, I'm not sure that those small boot speed wins are an user experience win, but shrug
<seb128> I'm not the one deciding
<cjwatson> seb128: I agree, but ...
<seb128> we have the same issue for desktop
<seb128> we will likely need to drop some nice things to win a 1 second on boot
<seb128> which in my opinion is not a win for user, I prefer to wait an extra second and have a system nicer to use
<tseliot> cjwatson: pressing esc like crazy here doesn't seem to solve the problem i.e. I can't access the grub menu
<seb128> tseliot, shift
<cjwatson> tseliot: like I say, esc has no effect there
<seb128> and you can keep it pressed
<tseliot> oh, shift
<tseliot> I missed that part then. I would have saved me a lot of swearing ;)
<seb128> hehe
<bryyce> tseliot, ditto
<seb128> welcome to the club ;-)
<bryyce> yeah it seems like esc should be supported as well as shift
<cjwatson> Riddell: thanks, accepted
<tseliot> :-)
<cjwatson> bryyce: it's not possible, sorry
<bryyce> cjwatson, why?
<cjwatson> bryyce: 11:10 <cjwatson> seb128: what was wrong with esc in grub> I was instructed to make grub not have a delay to wait for a keypress, and on the PC architecture the only keys whose state you can check instantaneously are the modifier keys
<bryyce> I see
<cjwatson> if you make the delay non-zero, then esc works
<cjwatson> I went through all this in the karmic cycle, this was about the best I could do, sorry
<bryyce> too bad we can't just make ESC into a modifier key ;-)
<cjwatson> pass the time machine
<seb128> cjwatson, nobody is blaming you don't worry
<tseliot> let's just document it then
<tseliot> seb128: +1
<seb128> I'm just blaming that boot speed crazyness
<seb128> working on making sure we boot fast is a good idea
<bryyce> seb128, yeah
<seb128> but it should not be in detriment of the user experience
<bryyce> we had to sacrifice wacom on the bootspeed altar
<tseliot> bryyce: what???
<bryyce> well, wacom-tools at least ;-)
<cjwatson> I think this is a symptom of a broader issue: "user experience" is always taken to mean utter novices
<tseliot> bryyce: because of the halsectomy?
<bryyce> tseliot, yeah
<cjwatson> there's no thought for the upward learning curve, escape hatches, etc.
<cjwatson> seb128: oh, one thing you might like to know: if the system fails to boot, then grub2 will always show the menu next time round
<seb128> right, but user experience should not just be what a new user will see on first boot when everything is working on standard hardware
<bryyce> cjwatson, yep, and customer retention
<cjwatson> seb128: so if you can't remember, just let the system start booting and immediately reboot :)
<seb128> cjwatson, it didn't work in this case for some reason
<cjwatson> seb128: odd
<seb128> cjwatson, I did had to power off the box sitting on the power button to stop it
<pitti> bryyce: hm, wacom was a victim of the hal deprecation, not the boot speed, wasn't it?
<cjwatson> seb128: recent lucid?
<seb128> and next boot didn't show the menu
<pitti> speaking of that, hal is starting in recent lucid again, grr
<seb128> cjwatson, yes, daily updated
<cjwatson> seb128: ok, could be a regression in my most recent grub2 upload then
<seb128> cjwatson, it usually works though, but I expect that video crash leaded to a state where the failed boot was not recorded
<seb128> or the mini was to desktop before the 5 seconds sitting on power
<tseliot> pitti: resistance to hal is futile :-P
<seb128> so it registered as a working boot
<bryyce> pitti, as was communicated to me, it was the bootspeed requirement which was the driver to eliminate hal
<seb128> which is might have been, I just had no screen to see it
<seb128> pitti, and it has a crasher
<seb128> pitti, got an apport crash notification today and some users asked about that on -bugs too
<slangasek> bryyce: halsectomy has been coming for a while; bootspeed made it happen before wacom had adapted
<bryyce> slangasek, as I said :-)
<pitti> bryyce: I thought there was a newer wacom release which doesn't need hal any more?
<pitti> at least that's what the xorg-halsectomy blueprint says
<tseliot> bryyce: if I can implement support for tags with udev and xorg.conf.d in time, things should be easier to deal with
<cjwatson> seb128: it must be the latter - the way it works is that grub registers a failed boot, and that state is then cleared at the end of the boot sequence
<pitti> seb128: "it" == ?
<cjwatson> having to actively register a failed boot in userspace would be too fragile
<seb128> cjwatson, ok
<seb128> pitti, hald-probe-input
<seb128> double free apparently
<seb128> I didn't investigate just had a look to the apport summary
<seb128> the bug was not retraced yet
<bryyce> pitti, unless something changed in the last few days, the release is still "coming soon"
<pitti> ah, fun
<bryyce> pitti, but yeah likely we will get wacom working in time
<seb128> pitti, bug #506260
<ubottu> Launchpad bug 506260 in hal "hald-probe-input assert failure: *** glibc detected *** /usr/lib/hal/hald-probe-input: munmap_chunk(): invalid pointer: 0x080492f9 ***" [Undecided,Confirmed] https://launchpad.net/bugs/506260
<tjaalton> bryyce: did you miss my email to ubuntu-x? ron released xf86-input-wacom
<tseliot> slangasek: X was built 12 minutes ago, just FYI
<tjaalton> with udev hotplug
<tseliot> ah, right
<seb128> pitti, or bug #500723
<ubottu> Bug 500723 on http://launchpad.net/bugs/500723 is private
<bryyce> tjaalton, wasn't there also some issues @ debian to resolve first?
<tjaalton> bryyce: I don't know?
<ion> Yay, iâve been waiting for wacom fixage in lucid. :-) Why *is* there a wacom driver, btw, shouldnât it be merged into evdev? Evdev already gets the coordinate information from my touchscreen perfectly, it would just need to recognize the buttons, touch pressure (and angle for the pads that support it).
<tjaalton> haven't quite understood Thomas' post yet
<bryyce> tjaalton, ok
<bryyce> tjaalton, so "coming soon" in Ubuntu at least ;-)
<tjaalton> ion: evdev doesn't, and never will, support the fancy features
<seb128> pitti, btw new cheese in lucid uploaded
<seb128> pitti, it uses gudev
<pitti> seb128: I saw, thanks!
<seb128> pitti, dunno if you keep a list of those somewhere
<tjaalton> bryyce: yes, need to at least bump the epoch
<seb128> pitti, you're welcome
<tjaalton> otherwise ok
<ion> tjaalton: I was under the impression evdev already contains axes for pressure, angle etc, it just doesnât know how to read that information from a wacom device. I may be wrong.
<tjaalton> ion: yeah, but stylus/eraser etc..
<slangasek> tseliot: great, thanks
<tseliot> pitti: also, can you remove envyng* from the archive, please?
<pitti> seb128: tried to fix the lucid chroot, but new dash is terminally broken with fakechroot, so nevermind for now
<pitti> seb128: (apport retracers)
<pitti> tseliot: what should I put in as rationale? "superseded by jockey" or so?
<seb128> ok
<tseliot> pitti: yes, that would be fine
<pitti> tseliot: done
<tseliot> pitti: would it be possible to add transitional packages to jockey? (just to make sure that users don't keep envyng after dist-upgrades)
<tseliot> thanks
<tseliot> envyng-core was in universe though
<seb128> tseliot, or use a conflicts, replaces, provides?
<tseliot> seb128: whatever pitti prefers
<tseliot> ;)
 * tseliot has no strong opinions on this
<pitti> I'm fine with adding a C/R/P
<tseliot> ok then
<pitti> tseliot: can you please commit?
<tseliot> pitti: sure
<pitti> we can't build it anyway, so no need to upload it right now
 * pitti sighs at pykdeuic4
<tseliot> pitti, Riddell: wasn't that updated ^^
<tseliot> ?
<tseliot> pykdeuic4, that is
<tjaalton> pitti: there's a new -evdev available in unstable (uploaded ~10min ago). it'll work around the nasty problems with accelerometers, so syncing that for a2 is ok
<pitti> tjaalton: please coordinate with slangasek; I have little mental bandwidth here at the sprint
<tjaalton> pitti: ah, ok
<tjaalton> will do
<slangasek> tjaalton: and I'm about to pass out; file a sync request and drop me a pointer to the bug # for me to consider when I'm awake?
<tjaalton> slangasek: ok, sounds good
<Riddell> tseliot: kdebindings needs a new SIP which hasn't been released so I havn't been able to update it :(
<hunger> Is there a reason for shipping /usr/lib/ld.so.conf or is that file just misplaced?
<slangasek> ttx: UEC images are called 'server' now on the uec-images download site?  Is this an intended and permanent change?
<tseliot> Riddell: oh, a new SIP? :-/
<slangasek> ttx: (if so, I think it's unfortunate name collision with the server ISOs; but we at least need to get the ISO tracker and the weather report updated to know this)
<Riddell> tseliot: yeah, it's not ABI compatible and I don't want to take a snapshot incase the final release has any more ABI changes
<tseliot> Riddell: ok, no problem. I know that rebuilding kde every time is not a trivial task ;)
<ttx> slangasek: i'm not sure what triggered it -- if there is no good reason it should be reverted, if only to allow already-written test scripts to continue working
<ttx> slangasek: we'll ask smoser if he knows
<ttx> pitti: arh
<ttx> pitti: I missed your recent changes when uploading apport 1.11-0ubuntu5
<pitti> ttx: np, it was just for setup-retracer; I only use that from the branch itself
<pitti> ttx: please just move my changelog to ubuntu6 then
<ttx> pitti: ok, will merge
<davmor2> pitti: An issue I'm assuming due to plymouth has arisen in that there is no dialogue to press enter to continue shutdown once the install has completed
<pitti> davmor2: the one in X? that shouldn't be related to plymouth
<pitti> ah, the "press enter" after shutdown
<ogra> pitti, the one that used to be in usplash
<pitti> davmor2: can you please file a bug? (sorry, at sprint this week)
<pitti> should be easy to fix, instead of usplash-send use the equivalent plymouth command
<pitti> seb128: yay, I recreated the apport retracer environments in lucid, have working fakechroots now
 * seb128 hugs pitti
<seb128> you rock dude
<davmor2> pitti: no probs I think it is in process now.  Is my assumption about it being plymouth correct and will the dialogue show up on a different tty?
<pitti> I'm not sure; I'm a plymouth n00b
<pitti> seb128: I didn't try retracing something yet; still remember the busted gdb -> busted stack traces that we had in jaunty?
<seb128> yes
<seb128> is that still an issue?
<seb128> I think I downgraded gdb by then no?
<davmor2> pitti: ta
<pitti> seb128: right; I don't know if it's still an issue with latest gdb; I'll try
<ttx> pitti: done, I didn't tag the release since it would be confusing ?
<pitti> seb128: do you reckon we could shutdown the jaunty/karmic retracers for now?
<pitti> ttx: you could tag the revision you uploaded
<pitti> ttx: erm, nevermind
<seb128> pitti, would be fine for me, nobody work actively on jaunty or karmic right now anyway and I doubt we get lot of new crashes there which are of interest
<pitti> seb128: what I thought, but wanted to confirm
<seb128> +1
<persia> cjwatson: Thank you, as always, for the spellcheck.  I'll try to be more careful :)
<zul> pitti: have you seen boris comment on the MIR autofs5 bug?
<pitti> zul: yes, I saw it; seems fine
<zul> pitti: so I should be able to go seed it correct?
<pitti> zul: right; just didn't have time to process it further (I'm on a sprint this week, and was travelling yesterday)
<zul> pitti: ah ok ill go seed it now then
<zul> lool: ping
<lool> zul: pong
<zul> lool: i updated the ctdb package but im not sure how to fix the readdir warning
<pitti> seb128: at least it properly identified 505219 as a dupe, so it can't be too broken
<seb128> pitti, good ;-)
<pitti> meh, so is the next bug
<pitti> give me a fresh one..
<pitti> at least it catches up with the backlog
<lool> zul: Looking
<lool> zul: So if you build ctdb, you see it fails a configure test for readdir
<pitti> seb128: ok, I think gdb still hates me
<lool> zul: Opening config.log and searching for that you'll find the cause of the issue
<pitti> seb128: (bug 506125 )
<lool> conftest.c:182:43: error: ./lib/replace/test/os2_delete.c: No such file or directory
<ubottu> Launchpad bug 506125 in nautilus-actions "nautilus-actions-config-tool assert failure: NA-nact:ERROR:nact-ibackground-tab.c:381:get_folders_treeview: assertion failed: (GTK_IS_TREE_VIEW( treeview ))" [Medium,New] https://launchpad.net/bugs/506125
<pitti> I'll try with the old gdb
<lool> zul: ./lib/replace/test/os2_delete.c doesn't exist, but ./lib/replace/tests/os2_delete.c does
<seb128> pitti, :-(
<lool> (s/test/tests)
<seb128> pitti, let me know how it goes
<zul> lool: ah ok..lemme have a look
<lool> zul: This test is maintained in lib/replace/repdir.m4
<lool> zul: I fixed the macro, but can't easily rerun autoconf for various reasons (apparently they miss some files and some vars) so I fixed configure manually as well; this fixed the warning
<lool> configure:8134: checking for broken readdir
<lool> configure:8160: result: no
<lool> etc.
<lool> zul: So just /os2_delete/s/test/tests/ in the lib/replace/repdir.m4 and configure
<lool> Now it fails to build for me   :-(
<lool> dh_installdocs: You asked that all arch in(dep) packages be built, but there are none of that type.
<lool> I built with -b
<zul> ok ill try it from here
<lool> zul: Will read you in the MIR then; thanks
<zul> lool: thanks for the help
<didrocks> cjwatson: do you plan to do an ubiquity update before alpha2? I've something to fix with une and other derivatives using gdm for default session ppa:canonical-dx-team/release but there is an easy workaround, so it can wait
<cjwatson> didrocks: ev just uploaded one today
<cjwatson> didrocks: I don't know if there's more planned
<ev> didrocks: patch?
<didrocks> cjwatson: ev: ok, it's just that the default session is not available on installed system. (only on the live image) as postinst aren't executed. So, will need to launch a command to update it if want une/xubuntu/mythubuntu as a default after reboot. Nothing important for alpha2 btw
<pitti> didrocks: could you add the workaround to the tech notes?
<zul> pitti: one more thing for psycopg2 you need to confgiure a postgresql database in order to run the testsuite since it tries to login as root
<pitti> zul: as root? that's strange; why doesn't it just connect as your user?
<zul> pitti: no idea
<zul> pitti: anyways we are fixing it in alpha3
<didrocks> pitti: done
<zul> lool: the latest upload fixes the readdir warnings for ctdb
<pitti> seb128: retracers!
<seb128> pitti, waouh!
<pitti> seb128: I leave the jaunty/karmic ones disabled for now, no time to spend on that right now
<seb128> ok
<lool> zul: Ouch, I see you added a patch to hide the gcc warnings, but that's actually worse than the warnings in the first place
<lool> zul: The failures need to be handled; in the case of read/write, it might be interrupted IO and that need to be retried or it might be errors in which case that need to fail the higher order logic
<zul> lool: *sigh*
<lool> zul: If you just hide the warning by adding a dummy var and ignoring it, it's *worse* because we don't even know that the error code is ignored
<zul> lool: ok because some of the comments in the code it doesnt matter if it overflows
<ScottK> lamont: Looks like builds aren't being dispatched on at least sparc and ia64 for some reason.
<cjwatson> if it doesn't matter, arrange for the warning not to trigger in code, rather than by changing gcc options
<lool> zul: Ok; if that's the case, you can add a dummy var /with a comment/ explaining that it's fine to ignore it
<cjwatson> (maybe I'm misunderstanding)
<zul> lool: ok ill go back at it then
<lool> cjwatson: The change is a patch which saves the return code of the failing calls, but doesn't use the value
<lool> cjwatson: http://paste.ubuntu.com/355533/
<lool> zul: IOW what we want is safer software, not less warnings  ;-)
<lool> zul: Thanks for looking into it
<zul> lool: np
<smoser> slacker_nl, ping
<ttx> smoser: fail
<cjwatson> I prefer 'if (read(...) < 0) { /* comment explaining why we're ignoring it */ }'
<smoser> gah
<smoser> slangasek, ping
<smoser> sorry slacker_nl
<slacker_nl> smoser: :)
<ScottK> lamont: Actually flow is OK.  It's just hooker
<ScottK> flow/floe
<smoser> regarding <suite>-uec-<arch>  to <suite>-server-<arch>.tar.gz , the change was intentional, do deal with the fact that we now have 'desktop' image also.
<smoser> i can absolutely change that to <suite>-<build_name>-uec-<arch> though
<cjwatson> pitti: TB meeting?
<pitti> argh, tseliot, help: since the last dist-upgrade I get an error "Failed to submit batchbuffer: Input/output error" and X is black
<pitti> tseliot: could that be related to recent X.org changes?
<pitti> cjwatson: finally managed to get online over CLI; sorry for delay
<tseliot> pitti: does reinstalling xserver-xorg-core help?
<pitti> tseliot: reinstalled, I'll try now
<pitti> tseliot: should that change any files or so? anything I could test before starting X again? (that will mean a reboot and maually getting on the wifi again)
<pitti> tseliot: it happened to didrocks as well
<tseliot> pitti: you should have libglx.so and libdri.so in /usr/lib/xorg/modules/extensions
<tseliot> if they are there, then it's ok
<pitti> tseliot: I do
<pitti> tseliot: ok, trying
<cjwatson> pitti: thanks
<pitti> tseliot: that worked
<pitti> tseliot: thanks!
<tseliot> pitti: good. BTW it's fixed in ubuntu5
<tseliot> np
<pitti> tseliot: I had that before, too
 * tseliot -> dentist
<tseliot> weird
<tseliot> you might want to tell slangasek about that
<pitti> tseliot: dentist> good luck
<pitti> does anyone remember how to force the version of a single binary package? IIRC it was some trick to pass a version as an argument to dpkg-deb or so
<davmor2> Guys on today's iso once installed with eng-uk locale evolution is removed
<seb128> pitti, sudo apt-get install binary=version
<pitti> seb128: no, I mean during source package build
<seb128> oh
<seb128> I don't know
<pitti> ah, dpkg-gencontrol -v
<lamont> ScottK: yeah - sometimes it doesn't like it when I upgrade the buildd... sigh
<cr3> pitti: hi there, if you have a moment, I have a quick dbus problem which I suspect you might've seen already
<pitti> cr3: (on sprint, and in a meeting); perhaps /msg me, and I'll answer later?
<cr3> pitti: this is by no means urgent, so I'll send an email and feel free to answer at your convenience. thanks!
<zul> lool: it should be ok now
<ion> If i have âLP: #NNNNâ in debian/changelog for something thatâs going to be uploaded, and the bug in question has been marked a duplicate of another bug #MMMM, will the upload mark #MMMM as fixed?
<ccheney> wow the kernel really slowed down recently
<ccheney> takes twice as long in the recent bootcharts
<smoser> james_w, does something need to be kicked such that lp:ubuntu/ec2-init get updated? its been a dozen hours at least since the last upload
<smoser> https://code.launchpad.net/ubuntu/+source/ec2-init
<pitti> didrocks: deb http://ppa.launchpad.net/gm-dev-launchpad/ppa/ubuntu karmic main
<tweakt> Is there an all in one tool which combines apt-move and apt-ftparchive?
<tweakt> I'm trying to string together germinate, apt-get (download packages) and apt-move/apt-ftparchive to produce a mirror from a set of dependencies (seeds)
<sladen> tweakt: perhaps germinator -> apt-mirror
<tweakt> ahh, right. I will check it out.
<tweakt> sladen: it looks like it can only produce a full or partial mirror, not accept a specific list of packages (and versions). Where I'm at now, I've already got a directory full of .debs that are needed. I just need to poolify them and generate the Packages files.
<sladen> tweakt: the directory structure of the pool doesn't matter;  you could even have them in the same directory as the Packages files
<tweakt> sladen: even for CD install?
<tweakt> oh, yeah... good point.
<tweakt> just put them all in /pool ?
<superm1> cjohnston, okay i've invited ubuntu-core-dev
<superm1> slangasek, things are sorted out now, it was because some stuff hadn't exited NEW yet
<cjwatson> superm1: thanks
<james_w> smoser: it does, yes. I'm going to try and get to it before the sprint starts this morning
<smoser> ok. thanks.
<kirkland> is anyone else having trouble running today's lucid-desktop-amd64.iso in a kvm?
<kirkland> seems to be hanging the vm hard
<highvoltage> mdz: have most people now at least casted their votes for the developer board?
<ion> http://bazaar.launchpad.net/~ion/ubuntu/lucid/mountall/lucid/revision/259#debian/changelog :-P
<alkisg> chrisccoulson, hi, could I do something more to help in getting the patch for ltsp clients reboot/shutdown accepted? (LP #491940)
<ubottu> Launchpad bug 491940 in gnome-session "Patch for LTSP clients to properly reboot/shutdown" [Undecided,New] https://launchpad.net/bugs/491940
<alkisg> I tested again the patch today, it works fine.
<humphreybc> Hi all - I'm Benjamin Humphrey, head of the Ubuntu Manual project and I've got some questions about the Software Center in Lucid.
<cjwatson> humphreybc: you probably want to wait until European working hours, for either mpt or mvo or both to be around.
<humphreybc> Hmm.. I've only really got one question regarding the roadmap for Lucid - whether Software Center is planning to completely replace Synaptic
<humphreybc> The wiki says "For Ubuntu 10.04 LTS, we plan to: Make the Ubuntu Software Center a viable alternative to Synaptic â presenting non-application packages in an understandable way, and allowing the same fine-grained package control and handling of error cases."
<humphreybc> Whether "viable" means that Synaptic will be removed from the CD or not, I'm not 100% sure.
<cemc> hi. could you take a look at this please? bug #96850 (last comment)
<ubottu> Launchpad bug 96850 in rrdtool "[apport] perl crashed with SIGSEGV in rrd_test_error()" [Medium,Fix released] https://launchpad.net/bugs/96850
<humphreybc> Does anyone know either mpt or mvo's email address?
<cjwatson> humphreybc: should be on the appropriate people pages on Launchapd
<cjwatson> Launchpad
<beuno> humphreybc, https://edge.launchpad.net/~mpt and https://edge.launchpad.net/~mvo
<humphreybc> thanks guys
<humphreybc> Hey he's a kiwi...? .net.nz
<beuno> humphreybc, yes, but living in the uk
<humphreybc> Oh neat
<cjwatson> e-mail addresses aren't necessarily strongly correlated with where people live. :-)
<humphreybc> (I'm a kiwi too)
<humphreybc> heh, well, not many people use a .nz address for no reason :)
<ari-tczew> I'm looking for sponsor for main ...
<Laney> there is a queue for that
<Laney> â¢
<slangasek> smoser: I think server-uec would be preferable.  And in general, please don't change image names without coordination, this information is tracked on https://wiki.ubuntu.com/LucidLynx/ReleaseManifest and used in a number of places
<smoser> sorry for trouble
<smoser> so you'd prefer just {server|desktop}-uec ?
<smoser> or lucid-{server|desktop}-uec
<slangasek> always lucid-*
<slangasek> lucid-(server|desktop)-uec-<arch>
<smoser> ok. i'll make that change.
<komputes> Is anyone available to compare some stacktraces?
<komputes> the crash/bug reports are the following 3:
<komputes> https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/141613
<komputes> https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/178038
<komputes> https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/192270
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/141613)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/178038)
<ubottu> Launchpad bug 192270 in nspluginwrapper "npviewer.bin crashed with SIGSEGV in pthread_mutex_lock()" [Medium,New]
<micahg> komputes: I already said I'd do that later tongiht
<komputes> micahg: yes you did, slangasek told me to post it here as well.
<komputes> micahg: thanks in advance
<TheMuso> argh! Something in lucid is causing my desktop to randomly reset, but I don't know what, and I can't find anything in logs to indicate what happens.
<cjohnston> superm1: im not sure what your referring to?
<superm1> cjohnston, sorry i pinged the wrong person.  there's not usually two people in here that start with cj , so  i can tab complete
<tweakt_> is there any way I can make apt-move respect the overrides so stuff ends up where it's supposed to? I'm getting things in non-free/contrib, etc.
<mdz> highvolt1ge, over 50% turnout now
<highvoltage> mdz: it's kind of disappointing, I would think that more people would care. are you going to send some kind of poll to people who didn't vote so that they could specify why they didn't vote?
<highvoltage> (glad that it's now over 50% at least)
<highvoltage> I guess some people might feel that all candidates are good ones. Or perhaps some feel that they don't know the candidates well enough (which would be weird if they're a developer)
<cjohnston> ok superm1.. thanks
<cjwatson> highvoltage: I know I care and just haven't quite got round to voting yet
<slangasek> zul: can you clarify what you meant in bug #445958 by "no longer being maintained"?  The package was removed from karmic, but has shown back up in lucid via auto-sync because it is maintained in Debian and there was a new version uploaded.  Is there really a reason to blacklist this package, or does it just need to be unseeded from server-ship (...which never happened when the package was removed from the archive)?
<ubottu> Launchpad bug 445958 in libapache2-mod-auth-pam "Please remove from archive." [Undecided,Fix released] https://launchpad.net/bugs/445958
<seb128> hum
<seb128> kees, did you have any bug about the nautilus change you put to bzr?
<kees> seb128: I don't, would you like me to make one for it?
<seb128> kees, not especially, I was going to upload my indicator application change but my push failed now
<seb128> kees, I'm not sure if I should try to squeeze your change in the upload or delay to after alpha now
<kees> seb128: ah, sorry, feel free to bump my revision (it was non-urgent, so I was waiting for the freeze to clear)
<seb128> kees, could you explain what it does exactly, did you send that upstream too?
<kees> nah, just bump my stuff.  I'll be uploading a bunch of packages all for the same thing.  I'll go open a bug.
<seb128> ok thanks
<kees> seb128: upstream will almost certainly not take it -- their dialog is after months of internal debate.  Ubuntu Tech Board happens to just not agree with it.  :P
<seb128> :-(
<seb128> I tend to not like things starting by "upstream will almost certainly not" ;-)
<kees> seb128: yeah.  I tried to deviate as little as possible.
<seb128> I've not looked at the change yet, doing my update and cleaning bzr before
<seb128> but in any case please open an upstream bug with rational
<seb128> to avoid having they unhappy about distro change not sent upstream, etcv
<seb128> if they don't take it fine but at least we did have the discussion there
<kees> I can, but it'll basically be reopening an old bug that they think is fixed already
<kees> okay, I'll do it.
<seb128> is that the "+x is required to run .destkop"?
<kees> yes.
<seb128> that should be fixed since karmic
<seb128> or jaunty
<seb128> in which case that doesn't work?
<kees> their dialog offers a "run anyway" option which is not allowed by Ubuntu policy.
<seb128> why not?
<kees> my patch just drops the buttons.
<kees> because it's useless security.
<seb128> hum
<seb128> why are those discussion not happening in public places?
<kees> uhm...
<kees> it was discussed at UDS for several sessions, and across weeks of tech board meetings.
<seb128> who decided that is an ubuntu policy without discussing it with the people concerned first?
<seb128> first time I read about it
<seb128> but I don't follow security track or TB meetings
<seb128> I do read mailing lists and meeting summaries usually though
<kees> it was in the desktop track 2 UDSes ago
<kees> it took 6 months to get through tech board.  :)
<seb128> waouh
<seb128> I'm quite surprised that a desktop policy got written, approved by tb, etc without me reading about it
<kees> speed there was mostly from me not pushing hard enough
<kees> it's not a desktop policy -- it's an ubuntu policy.
<kees> it affects everything
<seb128> still it impacts on desktop apps
<kees> right
<kees> I don't know why pitti didn't mention it.  it was in about 3 sessions in UDS Barcellona
<seb128> I will talk to him tomorrow
<kees> okay
<seb128> I join them for the sprint
<seb128> I'm not opposed to the change
<seb128> I just think upstream had good argument
<cjwatson> seb128: the TB decision was "this is OK subject to detailed discussion within the desktop team", so relax a little :-)
<seb128> and I'm not sure I like to have desktop team non consulted there
<cjwatson> like the desktop team technical lead? :-)
<seb128> cjwatson, oh, not stressed sorry if it seems so
<seb128> rather surprised
<cjwatson> who is on the TB and has been in all the discussions on the subject
<kees> the key difference is between allowing users to just run the thing anyway with a click vs blocking it.  Gnome came down on the "let them break their system" side, and we came down on the "protect their system" side.
<seb128> cjwatson, point taken, I will talk to pitti
<seb128> we sort have 2 desktop teams
<seb128> one being GNOME who deals with updates, etc, one being the Canonical one where pitti is techlead ;-)
<seb128> seems we have a communication issue between both ;-)
<seb128> kees, I'm not sure I agree with the "break their system"
<seb128> kees, it's rather "don't block them if they really know what they are doing and want to do the action anyway"
<seb128> kees, like the desktop is there for years and being used and has not been +x-ed on upgrade
<kees> seb128: right, agreed.  it's a binary choice for a huge grey area.  ultimately, if they know what they're doing, lacking +x isn't a problem.
<kees> seb128: but, as cjwatson says, it will need more implementation details.
<kees> (for reference, this is bug 506702)
<ubottu> Launchpad bug 506702 in wine "needs to block non-executable files from executing" [Undecided,New] https://launchpad.net/bugs/506702
<seb128> I've the feeling that going to create quite some trouble for users
<seb128> things in user dir they downloaded and use for years
#ubuntu-devel 2010-01-13
<seb128> I think that's the reason why GNOME did it the way it's done now
<kees> I totally hear you, and I understand their reasoning.  I just happen to disagree.
<seb128> do we have any upgrade plan to not let those users down?
<kees> pitti was pondering things like modification time, but that's likely to be fragile.
<seb128> I don't like much dictating things to user without letting them decide if they really have a reason to do what they are doing
<seb128> it's like saying you don't want to let user delete files because they could delete something they don't want to ;-)
<kees> I come down on the side I do because of: http://www.codinghorror.com/blog/archives/000347.html
<jcastro> kees: is there a discussion in upstream gnome someplace that you are aware of?
<kees> jcastro: not this part.  Gnome had their discussion and implemented what's currently in nautilus.  they felt it was a good middle ground.
<kees> It probably is a good middle ground, but it's not one I agree with.
<kees> and note that Gnome is only a small part of this.  it also affects wine, sun-java6, and openjdk-6.
<kees> and probably KDE, but I haven't looked there yet.
<jcastro> well, it's our right to do what we want. I think it just needs to be communicated properly
<jcastro> like, in the patch tags or whatever.
<seb128> well I think we should engage with upstream because deciding we disagree with them without trying to talk to them first
<seb128> because -> before
<jcastro> so that it's clear to an upstream that we think X and Y are better default behaviors
<kees> seb128: yup, agreed.
<seb128> though for the record I'm leaning toward of the side of what GNOME did right know
<jcastro> seb128: really? I personally hate that button
<seb128> your change will just annoy users who have good reason to run things they run
<seb128> and will not stop those who want to run cracks to chmod the files anyway to get there
<seb128> jcastro, why would you click on a .desktop if that's not to use it?
<kees> it's a matter of decided how high to make the barrier to see the dancing bunnies.
<kees> a single button click is way too low.
<seb128> jcastro, or do you get many people who try to screwed you by sending fake softwares this way?
<jcastro> seb128: all the .desktops I click on come with the distro
<seb128> jcastro, so you should never see that button
<jcastro> seb128: no but you get people starting to post random debs on the internet, etc.
<seb128> well the button should not be displayed for system path
<seb128> because if somebody got right to write to usr you are screwed anyway
 * jcastro nods
<seb128> not sure when you get the button display or why you hate it ;-)
<seb128> it should just be there is weird cases
<seb128> those being files you have in your user dir since before the change to make things +x
<seb128> or things people emailed you to trick you in doing something
<jcastro> wel we could argue all day, I just think it needs to be documented in the patch, pointing to rationale, our policy, etc. and also mentioned in the release notes and all that
<seb128> jcastro, I've no personal strong opinion, I don't think I ever got that dialog
<cjwatson> bryyce: is there any revision control for the changes between xorg-server 1.6.4-2 and 1.6.4-2ubuntu4?
<cjwatson> bryyce: (exactly why I want that is a long story ...)
<seb128> but alex is a pretty reasonable guy usually and did the design they have know for a reason
<jcastro> as long as it's clear to people that we've decided to make it behave that way
<seb128> the discussed started because I didn't know about the change and I don't agree with it
<seb128> I've understood by now that I'm going to be overruled there though ;-)
<jcastro> seb128: also, if it's been talked about for like 3 UDSes and no one has had a discussion with upstream then we should fix that
<kees> jcastro: to be honest, there wasn't a decision about Ubuntu's policy until today.
<seb128> jcastro, neither with community desktopers in ubuntu apparently
<seb128> anyway I've annoyed people enough about that
<seb128> kees, sorry for complaining, thanks for getting me updated on that
<jcastro> kees: yeah, we just need to remember that upstreams typicall won't read all our UDS notes, and it doesn't hurt to tell them early when we're considering things
<seb128> I will talk to pitti about communications issues on the change tomorrow
<slangasek> cjwatson: should all be in git, AIUI
<kees> seb128: sure, no problem.  there's still plenty to be further discussed.
<cjwatson> slangasek: I did look and couldn't find that particular set of revisions
<bryyce> cjwatson, I believe so; it should be in our git repo
<cjwatson> bryyce: if you could give me a SHA-1 for the head of that particular series, I'd appreciate it
<bryyce> cjwatson, what's the issue?
<kees> jcastro: right, and seb128's right, I need to open an upstream bug.  that said, i'd like to hear what pitti has been thinking about.
<cjwatson> bryyce: I've got git+ssh://git.debian.org/git/pkg-xorg/xserver/xorg-server.git, but haven't been able to track it down
<cjwatson> bryyce: revision control import for another project
<jcastro> kees: it's a weird line to walk, sometimes they're like "don't bother me with this little stuff" and then it'll be "why didn't you tell me about this?"
<jcastro> kees: so I err on the spammy side. :p
<ScottK> Having been in some of the discussions at various UDS sessions, I think this is a good change.  Part of the evolution from thinking of a secure system as protecting the root to protecting the user data too.
<kees> jcastro: sounds good to me.
<bryyce> cjwatson, a2b67de0ce18b71895ec210b74095f9d41042070 looks like it is the head for the 1.6.4-2ubuntu1 release
<bryyce> cjwatson, hmm looks like I don't have git history for the subsequent changes in 1.6.4
<Bsims> I am trying to launch openvasd it can't download the plugins any help I am on ubuntu and using the packaged debs
<cjwatson> bryyce: ok.  thanks!
<Bsims> should I go ahead and file a bug report
<bryyce> mm e6693c767e1a3fe2f02ae93fa7a6f7886d3fdebd is the ubuntu5
<bryyce> there we go, that's what you probably want; that includes kees' fix to xvfb
<Bsims> openvas-nvt-sync does not exist nor is findable by synaptic or locate
<bryyce> cjwatson, ah nevermind, yes all the 1.6.4-2ubuntuX changes are in there.  that e6693 is what you want
<cjwatson> bryyce: looks like a few revs back from that
<cjwatson> bryyce: 3a4400f0193c413f57c6109afe80c6a1142b31bf AFAICS
<cjwatson> bryyce: but perfect, thanks
<bryyce> great
<slangasek> Bsims: you probably want #ubuntu; this is not a help channel
 * Bsims nods fair enough, just debating filing a bug report on it... and was double checking here first
<functionofxy> hello--I'm a member of ubuntu manual, but I've got a general bzr question
<functionofxy> I branched, edited, committed, pulled, merged, committed
<functionofxy> now do i push or send?
<slangasek> functionofxy: 'push', if you have commit access
<functionofxy> bzr: ERROR: No push location known or specified.
<cjwatson> bzr push :parent
<cjwatson> (the first time; it'll remember it for later tries, so 'bzr push' will be sufficient afterwards)
<functionofxy> fantastic
<functionofxy> thanks
<cjwatson> that rune means "push to where you branched from"
<functionofxy> got it! so easy
<TheMuso> Well you learn something new every day. I didn't know you could do that with bzr.
 * micahg is glad to know that as well :)
<Riddell> pitti, cody-somerville: could you argue over bug 476530 and decide if it deserves an SRU?
<ubottu> Launchpad bug 476530 in bzr-builddeb "mark-uploaded fails with "Unknown target distribution: lucid"" [Undecided,Confirmed] https://launchpad.net/bugs/476530
<genii> Interesting. http://linux.dell.com/files/ubuntu/ has a Lucid directory
<Flannel> Hey guys, why's sreadahead -> ureadahead taking place mid-release in karmic?
<wolter> Hi, I come in behalf of the ubuntu manual project. We would like to know whether there will be or not a synaptic package manager in Ubuntu 10.04 (Lucid Lynx)
<Tm_T> in ubuntu-desktop install or in repositories?
<wolter> In the ubuntu-desktop install
<Tm_T> then I don't know for sure (:
<wolter> Oh, thank you anyway. I will wait around here in case somebody can answer my question.
<micahg> wolter: why don't you post to ubuntu-devel ML?
<persia> wolter: It's very likely to be present, but until FeatureFreeze it cannot be said for sure, and even thereafter there is a chance of a Freeze Exception.
<wolter> oh ok
<wolter> When is FeatureFreeze?
<persia> But last I checked, several other things that are expected to be present depended on synaptic, so it would be some work to have it not present.
<persia> https://wiki.ubuntu.com/LucidReleaseSchedule
<sladen> at /the moment/, synaptic is still pulled in my ubuntu-desktop, and gnome-app-install, and ... and ...  (see  apt-cache rdepends synaptic)
<persia> Yeah.  It's rather unlikely to be removed.
<pitti> Good morning
<StevenK> Hi pitti!
<pitti> hey StevenK
<pitti> cody-somerville, Riddell: replied in SRU bug, waiting for Cody's answer
<dholbach> good morning
<cemc> I saw this bug #96850 on here http://qa.ubuntu.com/reports/sponsoring/ , and make a comment with a debdiff, if anybody wants to take a look.
<ubottu> Launchpad bug 96850 in rrdtool "[apport] perl crashed with SIGSEGV in rrd_test_error()" [Medium,Fix released] https://launchpad.net/bugs/96850
<lucas> hi, does someone make some sense out of https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/498758 ?
<ubottu> Launchpad bug 498758 in ruby1.8 "can't install ri on ubuntu 9.10 (broken dependency)" [Undecided,New]
<MacSlow> slangasek, bryyce, tseliot: any (positive) news on the GL/GLX/mesa issue?
<tseliot> MacSlow: what issue?
<tseliot> bug #506547 ?
<ubottu> Launchpad bug 506547 in mesa "Some GL apps won't run: libGLU.so.1: No such file or directory" [Medium,Triaged] https://launchpad.net/bugs/506547
<tseliot> or maybe something else?
<MacSlow> tseliot, yup and https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/258038
<ubottu> Launchpad bug 258038 in nvidia-graphics-drivers-71 "Look into feasibility of using an alternatives system rather than diversions" [Wishlist,Confirmed]
<persia> lucas: It looks like an incomplete update to me, where the users are trying to install ri1.8 from karmic-updates and rdoc1.8 from karmic
<MacSlow> tseliot, which is related according to bryyce
<lucas> persia: yup, I just figured out that one is in universe and the other in main
<lucas> persia: which could explain
<persia> That would definitely explain it, yes.
<slangasek> MacSlow: 258038> err, that bug number's a little old to be related to the current problems?
<tseliot> MacSlow: 258038 should be fixed. The other bug can be fixed with a symlink until I fix it in the package
<MacSlow> tseliot, I currently cannot run any GL-apps I compiled on my system
<tseliot> MacSlow: what's the error?
<MacSlow> tseliot, "BadMatch"-error when trying to run any compiled GL-apps
 * MacSlow -> conf-call
<slangasek> MacSlow: what version of xserver-xorg-core do you have installed?
<persia> lucas: The confusing bit is that jackerran reports that ri1.8 is hunting rdoc1.8, but a version that isn't available.  I don't understand why someone would have universe-updates enabled and not main-updates.
<tseliot> MacSlow: do they work if you recompile them? We have switched to a new version of mesa
<slangasek> "if you recompile them" - eew? :)
<lucas> persia: user error? :-)
<tseliot> slangasek: BTW I'll fix 506547 and other mesa bugs after alpha 2. I'll focus on the release notes now
<tseliot> slangasek: yes, if he rebuilds them against the new mesa
<MacSlow> tseliot, after two days of getting my system working again (after I upgraded from Karmic to Lucid) I'm a bit (actually very) afraid to pull anything else from the repo... haven't been able to do real work due to all the fixing (not only GL-related though)
<persia> lucas: heh.  Quite possibly.
<slangasek> tseliot: having to rebuild anything would make this a non-starter option
<tseliot> slangasek: I was just asking ;)
<slangasek> tseliot: but if you're fixing 506547, then ok - but how/why is this still broken at all?
<MacSlow> slangasek, xserver-xorg 1:7.5+1ubuntu1
<slangasek> MacSlow: xserver-xorg-core, not xserver-xorg
<tseliot> slangasek: because libGLU was not supposed to be moved to /usr/lib/mesa. When you switch to nvidia, /usr/lib/GL won't point to /usr/lib/mesa anymore and you will lose libGLU :-/
<slangasek> ah
<tseliot> but it's ok with open drivers
<slangasek> tseliot: that sounds like the sort of bug that we ought to have the fix for uploaded before alpha-2 (even if not included on the ISOs), because otherwise we're going to get a lot more noise resulting from users trying to fix it themselves
<slangasek> hmm, maybe not though; I guess dpkg would correctly overwrite the "quick fix" proposed in that bug
<MacSlow> slangasek,  2:1.7.3.902-1ubuntu4
<MacSlow> njpatel, ping
<tseliot> slangasek: as you prefer
<slangasek> tseliot: if the fix for this is solid, I still think getting it uploaded will save a lot of tester / triager time
<slangasek> it's likely to generate a lot of duplicate bugs despite being in the errata
<tseliot> MacSlow: I would like to see the output of "ldconfig -p |grep GL" and ls -l "/usr/lib/ |grep GL"
<tseliot> slangasek: by when should this be ready?
<slangasek> tseliot: getting it right on the first (well... next ;) upload is more important than having it fast; I'm not concerned about getting this on the CD, just in the archive before tomorrow
<MacSlow> tseliot, one sec
<slangasek> MacSlow: you're behind a version on the server, then; you should definitely upgrade to -1ubuntu5, though it may not fix this particular problem
<MacSlow> tseliot, https://pastebin.canonical.com/26466 https://pastebin.canonical.com/26467
<MacSlow> slangasek, when was -1ubuntu5 uploaded?
<tseliot> slangasek: ok
<slangasek> MacSlow: yesterday
<tseliot> MacSlow: what happens if you uninstall nvidia-current-dev and do a "sudo ldconfig"?
<tseliot> MacSlow: also, are the programs that fail compiled for 32bit?
<ttx> ara: hey -- what does the "Started" result mean in the ISO tracker ?
<ttx> ara: are we supposed to set that status when starting a test ?
<AnAnt> Hello, is any of apport devs here ?
<tseliot> AnAnt: maybe ask pitti?
<AnAnt> pitti: ping
<AnAnt> I am trying to make apport-collect be able to read crash report from a file
<pitti> AnAnt: hi
<pitti> AnAnt: and attach it to an existing bug?
<AnAnt> pitti: yup
<pitti> AnAnt: because for reporting a new one you'd just do ubuntu-bug foo.crash
<AnAnt> I am pastebin'ing thd diff now
<AnAnt> Here http://pastebin.com/f3d6ecdbe
<AnAnt> yet I get an error when running it
<AnAnt> that's the error: http://pastebin.com/f651c145
<AnAnt> can you help with what is wrong ?
<pitti> AnAnt: you shouldn't call add_hooks_info() there; it should already be in the .crash file
<AnAnt> ah
<pitti> AnAnt: hm, but still the crash ought to have a ProblemType: field
<pitti> AnAnt: also, apport-collect calls crashdb.download(); it should not do that when reading the info from a file
<pitti> AnAnt: hmm
<pitti> AnAnt: so, usually you need to open a crash file with apport-gtk first, so that it adds Package:/Dependencies:/hook info, etc.
<AnAnt> ok, I removed report.add_hooks_info(None) line
<pitti> AnAnt: if you want to use apport-collect on a freshly produced .crash file, then you'd need to do all of those, not just hooks
<pitti> but then you can only report it from the same machine
<pitti> AnAnt: what's the use case, btw? I didn't get a request for calling apport-collect on a crash report yet
<pitti> since it should all be there in the original report
<AnAnt> pitti: the same use case of reporting a new bug on LP , but this time I want to add info to an already existing bug
<pitti> AnAnt: but this is not a bug, it's a crash report
<AnAnt_> sorry, I got disconnected
<AnAnt_> 11:45 <AnAnt> pitti: it is a report created by manually running: ubuntu-bug <pid>
<pitti> AnAnt_: ah, I see; with --save ?
<pitti> but those also shold have a ProblemType: field
<AnAnt_> pitti: I didn't run it with --save, I just run ubuntu-bug <pid> , then when it asked to submit/view/keep/quit, I chose keep
<pitti> AnAnt_: at some point I wonder whether to completely drop apport-collect and integrate it into apport-bug with a -b/--bug 12345 option
<ubottu> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<pitti> AnAnt_: right, that's the same result
<MacSlow> tseliot, I currently can't "play around" with uninstalling stuff etc. but the failing programs are compiled for 64bit
<AnAnt_> pitti: I just opened the crash file with vim, it does have a ProblemType field: ProblemType: Bug
<AnAnt_> pitti: does the load() method require a full path to file ?
<tseliot> MacSlow: is Badmatch error all you get? Can I see the full error, please? Also does the nvidia driver work for you (with compiz, etc.)?
<AnAnt_> pitti: no, it's not a full path problem
<pitti> AnAnt_: ah, you need to do .load(open(crash_file))
<pitti> it takes an fd
<AnAnt_> thanks !
<MacSlow> tseliot, https://pastebin.canonical.com/26468
<AnAnt_> pitti: it works \o/ thanks a lot !
<tseliot> MacSlow: you shouldn't use LD_LIBRARY_PATH=/usr/lib/mesa because you're using nvidia
<tseliot> and ldconfig should know where to find the right libraries
<MacSlow> tseliot, it does not
<AnAnt> pitti: the result is in LP #492271
<ubottu> Launchpad bug 492271 in compiz "ubuntu 9.10 totally freezes when compiz is enabled" [Undecided,New] https://launchpad.net/bugs/492271
<tseliot> MacSlow: ldconfig -p seems to think otherwise ;)
<AnAnt> persia: thanks to you too for the tip on -bugs
<tseliot> MacSlow: anyway, since you're using that variable, try this: LD_LIBRARY_PATH=/usr/lib/nvidia-current ./gl-particles
<MacSlow> tseliot, ./gl-particles
<MacSlow> ./gl-particles: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
<tseliot> MacSlow: that's where I wanted to get. Which is the bug I was discussing with slangasek
<MacSlow> 1> LD_LIBRARY_PATH=/usr/lib/nvidia-current ./gl-particles
<MacSlow> ./gl-particles: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
<tseliot> MacSlow: there's a quick fix for that
<tseliot> MacSlow: ln -s /usr/lib/mesa/libGLU.so.1 /usr/lib
<tseliot> then try again (there's no need to use LD_LIBRARY_PATH)
<MacSlow> tseliot, ok worked
<tseliot> oh and do a "sudo ldconfig" just in case
<tseliot> good
<AnAnt_> pitti: btw, I've put the patch on LP #506885
<ubottu> Launchpad bug 506885 in apport "Allow user to upload a crash file to a certain bug" [Undecided,New] https://launchpad.net/bugs/506885
<pitti> AnAnt_: can you please assign it to me? Thanks1
<AnAnt_> pitti: done
<ogra> pitti, "Das Programm 'scsi' wurde unerwartet beended" ... is that something from devkit ?
<pitti> ogra: no, sounds like a kernel thread?
<ogra> ok
<ogra> intrestingly scsi works fine :)
<ogra> my rootfs is on a scsi disk
<slangasek> NCommander: what's the status of dove for alpha-2?  bug #505772 is marked critical for a2, but I see no activity on it; and ogra says there are other problems?
<ubottu> Launchpad bug 505772 in linux-mvl-dove "system freezes sometimes after X is up for a while" [Critical,Confirmed] https://launchpad.net/bugs/505772
<ogra> slangasek, it will definately not be fixed in time since nobody really knows what the issue is yet
<ogra> so i guess milestone can be moved already
<slangasek> if that's so, please change the milestone
 * ogra does
<ogra> done
 * jussi01 waves to ogra and wonders if ogra remembers him :D
<ogra> bring my mind up to speed :)
<jussi01> ogra: http://www.flickr.com/photos/8413078@N02/4126318257/in/set-72157622726510357/
<ogra> thats not you ! :)
<jussi01> *g*
<jussi01> no, I was there though...
<ogra> yeah
<jussi01> have you seen that photo set before?
<ogra> yep
<slangasek> pitti, ArneGoetje: language-support-translations-{mk,oc} have deps on the corresponding NBS evolution-documentation-* packages - could this be fixed?  (I'm nuking the evolution-documentation-* packages from the archive, because they break kubuntu DVD building)
<slangasek> language-support-translations-oc has no other deps, perhaps it should just be removed from the archive?
<cjwatson> Flannel: we chose to do that, even though it was outside the usual pattern, because otherwise karmic was a significant boot speed regression from jaunty on many systems
<cjwatson> Flannel: those systems being ones with rotational hard drives, i.e. the most common - and ureadahead was a really dramatic improvement on a lot of those systems with fairly minimal maintenance overhead (unlike readahead-list)
<pitti> slangasek: yes, removing them soudns sensible to me; should I do this now?
<pitti> slangasek: they are orphans indeed, langpack-o-matic doesn't have the packages any more
<pitti> slangasek: removing
<ev> Lucid very much hates me today. Can't get into X with plymouth, lots of graphical corruption in X, random resets, etc. :-/
<pitti> ev: X> do you have /usr/lib/xorg/modules/extensions/libglx.so ? if not -> sudo apt-get install --reinstall xserver-xorg-core
<pitti> ev: corruption> njpatel had that this morning, solved by dist-upgrading (mesa issue)
<ev> pitti: Ill give it a shot. Thanks.
<ogra> mumble, sshd doesnt log me out on reboots :(
<ev> pitti: You're a star. Thanks, that worked.
<yofel> pitti: bash completion for ubuntu/apport-bug updated, anything else you would like? (and is apport-cli broken?)
<didrocks> cjwatson: hey o/ I'm trying to debug the "randomely starting UNE session on UNE". I saw that /etc/gdm/custom.conf file exists on the squashfs and have the good default session bit.
<didrocks> cjwatson: but in the live system, there is no more the default session one. I retested in a sandbox my bottom-scripts 15autologin on casper and it seems to be correct
<didrocks> cjwatson: I changed on that /root/etc/gdm/custom.conf thinking that /root is mounted from squashfs in the initramfs phase. Is that correct?
<cjwatson> didrocks: I think I would benefit from a clear description of the observed bug.  Is there a bug report open for this?
<pitti> yofel: thanks! will look at the bug mail soon
<cjwatson> didrocks: by the time casper-bottom scripts are running, /root is a union filesystem composed of the squashfs and a copy-on-write tmpfs.
<didrocks> cjwatson: not yet, but pitti and seb128 experiences it randomely (sometimes the UNE session is started, other time, we have the default GNOME session, without the DefaultSession key in custom.conf
<cjwatson> didrocks: changes there are preserved for the duration of the live session, but are (of course) not written back on reboot
<didrocks> ok, so, the logic seems good, I'll introspect this a little bit more, so. Thanks :)
<crimsun> is it okay to upload a fix for abiword's FTBFS? (would only affect Xubuntu as far as images are concerned)
<geser> pitti: Hi, I'm attempting to merge fuse and stuck on the .fdi file. I assume that it shouldn't be kept but replaced with udev rules, right?
<pitti> geser: oh, /dev/fuse? this should have stopped working in karmic already
<pitti> geser: is the .fdi a delta of our's, or in Debian? Just drop it in the former case
<pitti> geser: if we need it, we need to fix it in udev
<geser> yes, /dev/fuse and the .fdi file is ours (Ubuntu)
<pitti> geser: great, so this delta can just go away then (until someone complains, anyway)
<geser> pitti: so the remaining change from the previous "Dynamic foreground user access" changes is to keep /bin/fusermount world executable (perms are 4755). As I understand it the .fdi file previously granted access to /dev/fuse and /dev/fuse seems have perms 666 in karmic, so no real access control anymore. It this ok this way and the change should be kept?
<pitti> geser: hmm; I think just keep the debian setup for now
<geser> pitti: so revert all Ubuntu changes for this? If I understand the packaging correct, the user then has to be in the group "fuse" to be able to use fusermount. (but as I'm not familiar with fuse usage, I don't know if this is a problem or not)
<geser> ogra: as you're bug contact for fuse, do you know more if this will cause problems? ^^
<pitti> geser: ah, right, Debian installs the fusermount program as 774 root:fuse, right?
<pitti> geser: right, we should keep it as 4755 then
<pitti> geser: sorry (I'm just here with 1/4 a brain, I'm on a sprint)
<ogra> geser, i havent touched fuse since several releases
<ogra> and i dont see myself mentioned anywhere in the package
<persia> ogra: https://launchpad.net/ubuntu/+source/fuse shows you listed as a bug subscriber.  Perhaps you don't wish to be one anymore?
<ogra> sure i do, but i shouldnt be a default contact
 * ogra checks
<geser> pitti: last question before I unburden your Â¼ brain: The Ubuntu package sets 4755 directly in debian/rules while the Debian package uses 0755 in debian/rules and overwrites it in the postinst to 4754 if it's not listed in dpkg-statoverride. Which way is preferred? The old Ubuntu way or use the Debian way but use 4755 as permissions?
<persia> ogra: You're the *only* default contact :)
<ogra> yeah, i see that
<ogra> i'm intrested in fuse bugs but dont want to be "the contact"
<pitti> geser: I think debian/rules is much easier; the postinst is only necessary because the "camera" (or plugdev?) group isn't a static one
<ogra> the funniest thing is that i see a "subscribe to bugmail" link at the top
<geser> ogra: sorry to question you but as you are listed as "Bug subscriber" I assumed you had some interested in the package and know what's going on with it
<ogra> but apparently no way to unsubscribe at all
<persia> ogra: Click on the little circle with a bar next to your name.
<ogra> there is none :P
<ogra> you mean the yellow one with a pen
<ogra> i only have one at the "subscribe to bugmail"
<ogra> but nothing near my name
<ogra> ok
<ogra> apparently i have to click "subscribe to bugmail" to unlsubscribe
<ogra> *unsubscribe
<ogra> sigh, we're getting worse than windows in some areas
<persia> Yes, there's an invisible {un,} in front of "subscribe" everywhere it appears in LP :)
<ogra> click "start" to stop :P
<persia> Precisely :)
<DktrKranz> mvo: hi! Did you have time to look at the gdebi merge proposal which addresses usage of --always-ask-pass?
<mvo> DktrKranz: not yet, doing that now
<DktrKranz> thanks!
<J_P> hi all
<J_P> people, are there a iso of 10.04 for tests? I have a All In ONE DEsktop (but is not a normal/usual AIO) Is a industrial machine for specific use) and touch scren is not possible to calibrate. I install ubuntu, and after install packagexserver-xorg-input-evtouch, restart machine and try run   gksu /usr/bin/calibrate_touchscreen but show this message : http://189.2.146.45/tmp/touch01.png
<J_P> So I would like to try a develoment version of test..
<persia> J_P: If you'd like to help test candidates for the next release, #ubuntu-testing is the best place to get help getting involved.
<freeflying> ArneGoetje: arounds?
<ArneGoetje> freeflying: yes
<mvo> DktrKranz: it sounds like once this is merge we can upload to debian and do a sync on it? it should work just fine on both then, right?
<freeflying> ArneGoetje: do u think we can use microhei to replace zenhei, for microhei is smaller than zenhei
<ArneGoetje> freeflying: I need to take a closer look at microhei. Last time I looked (and that's already a while ago) the glyph shapes were not consistent.
<mvo> DktrKranz: many thanks for the branch, merged now (with a small simplification)
<freeflying> ArneGoetje: Qianqian is going to release another version
<ArneGoetje> freeflying: ping me when that's the case, then I'll take a look at it again
<DktrKranz> mvo: thanks! I think I'm done with this round of patches. If you think, feel free to upload at your convenience :)
<zul> lool: ping
<mvo> DktrKranz: cool, thanks. I created a team for it now and added you and moved the bzr to a shared upstream trunk branch - it should be much nicer now :)
<mvo> DktrKranz: ~gdebi-developers
<DktrKranz> mvo: yeah, I saw the email, thanks!
<lool> zul: Hey
<lool> zul: debian/patches/99-fix-gcc-warnings.diff last hunk of first patched file has a double free
<lool> -               write(log_state->fd, s, strlen(s));
<lool> +               if (write(log_state->fd, s, strlen(s)) != strlen(s))
<lool> +                       free(s); free(s);
<zul> lool: ok ill fix
<lool> BTW it shouldn't be an error for write() to return less than what was requested ot be written; one is supposed to retry partial writes, they might occur in legitimate conditions
<lool> But it's still better to fail than to not do anything
<lool> -                       write(state->fd[1], &cc, 1);
<lool> +                       if (write(state->fd[1], &cc, 1) != 1)
<lool> +                               break;
<lool> Why not return -1 here too?
<lool> (ctdb-1.0.108/server/ctdb_recover.c)
<lool> same for ctdb-1.0.108/server/ctdb_recoverd.c; you use return in one half of the cases and _exit in the other
<lool> It might be correct, I just don't know
<lool> +       if (system(buf) != -1 ) {
<lool> +               printf("system() failed");
<zul> that break is in a while loop
<lool> Yes
<zul> k
<lool> Which goes to _exit()
<lool> You might want to LOG instad of printf
<lool> In one of the writes you return -errno
<lool> but in plenty of reads you return -1
<lool> zul: Otherwise this indeed looks more like error handling now
<zul> lool: ok ill have another pass at it thanks
<lool> zul: Please subscribe to bug mail
<lool> zul: Please change Vcs-* to XS-Debian-Vcs-* when you diverge from Debian
<lool> (otherwise debcheckout picks the wrong source)
<cody-somerville> Did someone ping me?
 * sebner not but waves at cody-somerville nevertheless :)
 * cody-somerville waves. :)
<Riddell> cody-somerville: yes, you need to argue your case on bug 476530
<ubottu> Launchpad bug 476530 in bzr-builddeb "mark-uploaded fails with "Unknown target distribution: lucid"" [Undecided,Confirmed] https://launchpad.net/bugs/476530
<Riddell> ArneGoetje: I'm told I can save valuable CD space by using ttf-wqy-microhei instead of ttf-wqy-zenhei and ttf-arphic-uming so I'd like to do that if the two better fonts get pulled in when the user installs chinese language support
<Riddell> for Kubuntu anyway
<mathiaz> cr3: does checkbox support autotest?
<cr3> mathiaz: it used to, but it needs to be updated to the more recent code base. ogasawara has also requested this, so I'll try to pull it off today
<mathiaz> soren:
<mathiaz> ^^
<soren> Neat.
<ArneGoetje> Riddell: they do get pulled in with the language-support-fonts-zh-han{s|t} packages. So, feel free to use ttf-wqy-microhei in the seeds.
<pgquiles> I'm following https://help.ubuntu.com/community/LiveCDCustomizationFromScratch (with Karmic) but after boot, ubiquity is not started and I only see the command line. Is there any step missing/wrong?
<superm1> slangasek, 20100113 isn't showing up on the iso tracker for mythbuntu (i just tried it, and the one bug that was reported for 20100112 is fixed)
<slangasek> pitti: cheers!
<slangasek> superm1: yep, 20100113 posted to the tracker now
<superm1> thanks
<pitti> slangasek: good morning!
<slangasek> pitti: morning
<slangasek> pitti: bah; "  language-support-mk: Depends: language-support-translations-mk but it is not installable"
<pitti> slangasek: same for -oc, I take it?
<slangasek> pitti: yes
<pitti> slangasek: removed those, sorry
<pitti> of course it's 2 mins past the publisher, darn
<slangasek> right :)
<pitti> perhaps it's faster to unseed them and only seed a couple?
<slangasek> pitti: only used on DVD builds, and it should be exceptional that the packages are broken, yes?
<pitti> slangasek: right, they just weren't removed in time
<cjwatson> pitti: please tell me we're not going to reset the work items lines any more :)
<cjwatson> pitti: I realise it was probably sort of necessary with the rewritten tracker code, but http://www.piware.de/workitems/foundations/lucid/report.html was really rather more informative than http://macaroni.ubuntu.com/~pitti/workitems/canonical-foundations.html currently is :(
<pitti> cjwatson: lool just pinged me; indeed I stopped those cronjobs for the entire cycle
<pitti> I can start them again
<cjwatson> I know, but the fact that we lost the historical trend is a bit of a problem
<pitti> but I definitively won't add another 50 cronjobs for alpha-3/beta-1/etc
<cjwatson> understood
<pitti> if it's useful in any way I can keep the old tracker for the final
<pitti> or adjust the trend line on the new tracker
<pitti> ^ woudl that actually be enough?
<pitti> or is there more missing?
<cjwatson> moving to the new graphs just makes it much harder to judge whether we need to reprioritise
<cjwatson> maybe, but what would you adjust it to?  it has a quite different list of WIs due to the global scan
<pitti> right
<cjwatson> I think it would be OK to keep the old tracker running for this release as a workaround
<ion> I wonder when Keybukâs gonna come online?
<pitti> reenabled for mobile/server/foundations
<cjwatson> ion: he's on holiday
<cjwatson> pitti: thanks!
<ion> cjwatson: Ok, thanks
<pitti> cjwatson: probably in a month or so the trend line and actual daily work item change will be exact enough to switch to the new tracker entirely
<pitti> but I'll leave them running for now
<cjwatson> yeah, could be
<slangasek> zul: did you see my earlier ping about bug #445958?
<ubottu> Launchpad bug 445958 in libapache2-mod-auth-pam "Please remove from archive." [Undecided,Fix released] https://launchpad.net/bugs/445958
<zul> slangasek: no i missed it
<slangasek> zul: can you clarify what you meant in bug #445958 by "no longer being maintained"?  The package was removed from karmic, but has shown back up in lucid via auto-sync because it is maintained in Debian and there was a new version uploaded.  Is there really a reason to blacklist this package, or does it just need to be unseeded from server-ship (...which never happened when the package was removed from the archive)?
<zul> checking
<milanbv> slangasek: I'd like to talk with you about bug #393854
<ubottu> Launchpad bug 393854 in gdm "Update PAM policy to allow password-less logins set up via users-admin" [Unknown,Confirmed] https://launchpad.net/bugs/393854
<milanbv> I asked seb128 who said me he had no strong opinion about it
<zul> slangasek: i asked it to be removed because of f #130099
<zul> it should probably be blacklisted and removed from the seeds
<NCommander> slangasek, pong, sorry, didn't see your ping. Dove is fairly unstable at the moment, but I've managed to install at least the ARM alternate dailies
<slangasek> milanbv: perhaps you could discuss it with kees instead?  He also weighed in on the question, and I'm rather tied up with alpha 2 right now
<slangasek> milanbv: I begrudgingly concede that the point about being able to still require a password for other services is a valid one, so if kees agrees, I'm ok with the change
<slangasek> milanbv: (though architecturally, I still dislike having a magic group name...)
<slangasek> zul: the corresponding Debian bug has users claiming it works for them, and that there's no replacement available?
<milanbv> slangasek: OK, I'll grab Kees
<milanbv> kees: ping?
<zul> slangasek: hmm ok it should be fine then i havent tested it out myself
<slangasek> zul: ok.  should it still be unseeded?
<zul> slangasek: i think so
<slangasek> zul: ok - could you make that change?
<zul> slangasek: of course
<slangasek> NCommander: ARM alternate isn't what we would include in alpha-2, though; I've posted the desktop images to the ISO tracker for testing
<slangasek> NCommander: when are the new, non-desktop images going to arrive?
<kees> milanbv: I'm fine with it.  I hate the idea of auto-login, but people are set on it.
<kees> milanbv: this actually makes it better in that they actually have a password.
<milanbv> kees: that was my thought when I implemented that
<milanbv> we still need to adress a more general issue with keyrings when password is not typed
<milanbv> but that's not specific to that patch
<milanbv> who should commit that patch?
<kees> milanbv: whoever normally handles gdm, I think.
<milanbv> no idea who does that - I'll look for him
<milanbv> thanks anyway!
<milanbv> kees: oh, and you'll be happy to hear that the new version of the system-tools-backends/liboobs no longer encrypts passwords on its own
<milanbv> we use standard chpass, without the -S option
<kees> milanbv: oh? how?
<milanbv> I've completely changed the D-Bus protocol
<kees> ah, okay.  is that in lucid currently?
<milanbv> we now send passwords in clear text (appears to be fine with D-Bus)
<milanbv> that should be in soon
<milanbv> chris has opened a bug about that
<kees> I thought the bus could be sniffed?
<milanbv> according to people on dbus-list, that's safe
<milanbv> (for local bus)
<milanbv> my main concern is about perl, which doesn't allow clearing memory
<NCommander> slangasek, that was planned for A3 AFAIK. We should be tracking alternates though, it was decided at UDS we were going to do so
<slangasek> NCommander: what do you mean by "tracking"?
<NCommander> slangasek, having alternates on the tracker and testing themper normal
<milanbv> seb128: slangasek is OK with the GDM password-less patch - do you know who's reponsible for committing there?
<seb128> nobody
<seb128> we don't have strict maintainer assignement in ubuntu
<seb128> slangasek can do it if he wants
<slangasek> NCommander: nobody has mentioned this to me up to now; who made this decision?
<NCommander> slangasek, https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-arm-alternate-images
<milanbv> seb128: hmm, I should be more precise
<milanbv> he said he didn't care either, and told me to ask kees, who's OK
<milanbv> :-)
<slangasek> NCommander: oh, right; now I remember catching sight of this outstanding work item in the last release meeting and claiming it...
<slangasek> NCommander: is this alternate for both flavors?
<NCommander> slangasek, as far as I know, but I'm unsure if imx51 alternates work at all. ogra ?
<ogra> NCommander, no idea, GrueMaster is the testing guy ;)
<ogra> NCommander, i'm busy with other stuff, i only test live images
<kees> milanbv: "undef" seems to work for me, experimentally, in perl.
<kees> milanbv: all file descriptors that carried the password should be closed, and then the variable that held it undefed
<kees> milanbv: http://pastebin.com/f39fc278e  when I kill -SEGV the script and look at the core from each shell, the second shell doesn't show the string.
<sebner> kees: wondering about what you bleeding edge session will be about :)
<milanbv> kees: actually, I've found many threads explaining how clearing memory was very hard in perl
<kees> sebner: http://outflux.net/ul07/bleeding-edge.odp <- this, in IRC form
<milanbv> I'll use undef, but I'm not sure that's a 100% warranty
<milanbv> (we don't actually open files, since chpasswd does this for us)
<kees> milanbv: it's hard if you splash the variable around, but if keep it limited, it shouldn't be too bad.  you can experimentally test it by using ulimit -c unlimited; rm core; *run*; kill -SEGV $pid; strings -a core | grep $password
<milanbv> yeah, I'll try that
<sebner> kees: cool, seems a little bit like "for beginners"?
<milanbv> anyway, there's an important security: an attacker doesn't know what he should grep for, since the password is unknown
<kees> sebner: a bit, yeah.  but there are some good bits of advice.
<kees> milanbv: well, that's just to make your test easy.  it's relatively trivia to reconstruct the process memory and find the variable directly.
<sebner> kees: nice, I'll be there then, maybe I hear something new :)
<milanbv> and I suspect the D-Bus binding could be playing with values around, leaving them in memory
<kees> sebner: cool!
<kees> milanbv: if so, it's a bug in the dbus module.  :)
<kees> anyway, give it a try, see what it looks like.
<milanbv> not sure - it seems that as long as you perform some string operations in perl, data hangs around without any way of finding it
<milanbv> I'll try
<milanbv> do you have commit access to GDM?
<milanbv> I mean, in Ubuntu
<sivang> hi all
<sivang> how bad is Lucid right now? can it be used for webapp development and audio ouput on a plani intel borad ?
<chrisccoulson> sivang - you might be better off asking in #ubuntu+1
<sivang> chrisccoulson: ?
<sivang> chrisccoulson: why is that?
<sivang> -devel is no longer for the currently being eveloped branch ?
<chrisccoulson> this channel is for discussing ubuntu development. #ubuntu+1 is the channel where people running the development branch communicate with each other
<sivang> chrisccoulson: ah koay
<sivang> cool
<geser> chrisccoulson: Hi, as you filed bug #427595 and as libipoddevice is back in lucid, do you know if it should be removed again or if it should stay (in that case we would need to re-apply our old Ubuntu change to fix bug #505336)?
<ubottu> Launchpad bug 427595 in libipoddevice "Please remove libipoddevice source and binary from Karmic" [Wishlist,Fix released] https://launchpad.net/bugs/427595
<ubottu> Launchpad bug 505336 in libipoddevice "libipoddevice FTBFS: Missing format specifier" [Undecided,New] https://launchpad.net/bugs/505336
<chrisccoulson> geser - yeah, it seems like it should be removed again
<sivang> anybody know how I can request to renew mu ubuntu membership ?
<jcastro> sivang: you just renew yourself when it sends you the mail
<mneptok> jcastro: i got that e-mail, and i thought "renew yourself" meant a nap and a shower.
<jcastro> yeah but we know you don't shower.
<mneptok> jcastro: that's why i was going to let my Ubuntu membership lapse, and switch to Slackware.
<mneptok> gcc has no personal hygiene requirements.
<sivang> jcastro: I forgot
<sivang> jcastro: that's the problem
<jcastro> I did that once, I just mailed someone on the CC
<sivang> jcastro: I'm nwo more into loco team and talks I'm giving
<sivang> jcastro: okay
<sivang> jcastro: whom to mail ?
<jcastro> no idea, can you join #ubuntu-community-team and we'll sort it
<ScottK> mneptok: That's for the blog on the Google stuff.  Very interesting.
 * mneptok bows
<ScottK> That's/Thanks in any case.
 * ScottK goes to look for moar coffeeeee
<sivang> jcastro: hhehe
<sivang> jcastro: joining now
<ari-tczew> anybody will work on merges for main?
<ari-tczew> there is no support from sponsors
<ari-tczew> thanks!
<Kmos>  /quit
<ScottK> ari-tczew: There are people to do it, but a lot of people are busy with Alpha 2 preps right now.
<ari-tczew> wow
<mathiaz> does anyone see a use case for having / on a raid0 (stripped) array?
<elmo> err, yeah, me?
<elmo> I've done that several times before when I needed space for a machine with trivially replacable contents (e.g. an Ubuntu mirror)
<q3aiml> Would this be the correct place for a packaging question?
<highvoltage> q3aiml: #ubuntu-motu
<q3aiml> thanks
<highvoltage> you're welcome
<elmo> mathiaz: ^--
<mathiaz> elmo: right - so you'd just use raid0 for the whole system instead of raid0 for the partition that hold the replacable data and raid1 for /?
<elmo> mathiaz: it's easier for me to RAID 0 / than to alter my auto-installer to setup a separate RAID 0 partition
<elmo> that may just be me, but *shrug*
<mathiaz> elmo: fair enough - and if you loose one drive, you loose your data anyway - which renders the system unusable
<elmo> right
#ubuntu-devel 2010-01-14
<slangasek> mdeslaur: bug #507148> is /usr/lib/xorg/modules/extensions/libglx.so missing from your system?
<ubottu> Launchpad bug 507148 in xorg "[lucid] xorg fails to start on Thinkpad T30" [Undecided,New] https://launchpad.net/bugs/507148
<mdeslaur> slangasek: hold on, I'll check
<mdeslaur> slangasek: no, it's not missing
<slangasek> hmm
<slangasek> ok, thanks for checking
<mdeslaur> anytime
<slangasek> I'm not sure what would cause that to go black /after/ a gdm login screen, then
<mdeslaur> slangasek: it doesn't go black, it stays at the "flashlight" transition screen and hangs
<slangasek> ah
<mdeslaur> the currentdmesg log is revealing
<slangasek> oh, curious
<mdeslaur> may be a dupe of #478493
<mdeslaur> hmm, maybe not
<slangasek> smoser: did you link the wrong bug # from the ec2 test reports?  I don't think bug #506559 applies to EC2 :)
<ubottu> Launchpad bug 506559 in ubuntuone-client "Ubuntu1 just opens apport whenever I click on the applet" [Undecided,New] https://launchpad.net/bugs/506559
<Drakeson> screen-cleanup is not run, I have to manually do "sudo invoke-rc.d screen-cleanup start" every time I reboot.
<dholbach> good morning
<Usama> hello, I want to report bug but I want suggestions
<Usama> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/451640
<ubottu> Launchpad bug 451640 in linux "[Asus eeePc 1005HA] Suspend to RAM with wifi off deactivate the ethernet on next resume" [Undecided,New]
<Usama> I've the same bug but I want to make usefull report. what is the package name and how to append my report to this open bug
<Usama> I found the bug channel thank you
<pitti> Good morning
 * slangasek waves to pitti
<pitti> hey slangasek
<UbuntuN00B> hello
<UbuntuN00B> I'm probably not in the right place but I need help installing Uuntu 9.10
<Mamarok> UbuntuN00B: support is in #ubuntu
<UbuntuN00B> I know but they havn't really helped :/
<Mamarok> UbuntuN00B: you need to be patient, ask your question and give enough details, if somebody knows the answer, they will reply
<UbuntuN00B> I gave every detail possible and I think after 1hr waiting for an answer its time to try elseware
<Mamarok> well, again, just be patient, it definitely doesn't belong here
<pitti> darn, resuming from hibernation is broken completely now
<hyperair> pitti: what broke?
<pitti> hyperair: apparently the initramfs now doesn't check at all for a swap signature any more?
<hyperair> oh hell, that sucks.
<pitti> it just boots, and mountall/fsck notice that swap has a hibernate siguature and re-mkswaps it
<pitti> and of course it keeps fscking /, since it wasn't unmounted cleanly
<hyperair> ha.
<hyperair> lol
 * pitti files a bug
<hyperair> pitti: check if the resume script's around in /usr/share/initramfs-tools/scripts/local-premount/resume
<pitti> hm, it's there
<smoser> slangasek, i did use the wrong bug. fixed now.
<slangasek> smoser: cheers
<pitti> /usr/share/initramfs-tools/scripts/local-premount/.resume.swp, too..
<DktrKranz> sbalneav: hi! do you have a ETA for sabayon-2.29.5 final on GNOME FTP?
<pitti> hyperair: perhaps it broke with Scott's initramfs scripts reorg
<hyperair> hmm perhaps.
<pitti> hyperair: a lot of those scripts did assumptions which weren't documented/guaranteed
<smoser> slangasek, i was going to go ahead and publish as alpha3 to ec2 unless you object
<smoser> just so i have the ids when i wake up tomorrow
<slangasek> smoser: yes, please go ahead
<hyperair> ouch
<smoser> ok. just started: vbcron publish-build --verbose --add-launch=none lucid server alpha2 /srv/ec2-images/lucid/20100113
<pitti> hyperair: bug  507390 FYI
<ubottu> Launchpad bug 507390 in initramfs-tools "resuming from hibernation broken in lucid" [High,New] https://launchpad.net/bugs/507390
<hyperair> pitti: ah thanks.
<smb> slangasek, Which logs exactly did you like to have from cking and myself?
<slangasek> didrocks: is there an open bug for the UNE/gdm issue that we can link from the errata?
<slangasek> smb: /var/log/dpkg.log
<smb> slangasek, ok a sec
<slangasek> didrocks: (other than bug #507121, that is)
<ubottu> Launchpad bug 507121 in netbook-meta "Netbook Edition Lucid Alpha 2 - After first boot default GNOME desktop instead UNR Launcher" [Undecided,New] https://launchpad.net/bugs/507121
<cking> slangasek, logs sent
<slangasek> cking: thanks - sent where?
<cking> to you
<cking> via email
<slangasek> ok
<smb> slangasek, sendemail too. on its way out
<didrocks> slangasek: not yet, opening it in a minute
<slangasek> didrocks: well, perhaps you can claim bug #507121 then :)
<ubottu> Launchpad bug 507121 in netbook-meta "Netbook Edition Lucid Alpha 2 - After first boot default GNOME desktop instead UNR Launcher" [Undecided,New] https://launchpad.net/bugs/507121
<didrocks> slangasek: yes, it should be ok :)
<didrocks> cjwatson: if you have a minute, about persitency on an USB key: can you confirm that when I reboot, I retrieved persistent data mounted on /root/<something> in casper phases? (seems I don't get previous file, just an empty one)
<pitti> didrocks, cjwatson: we'll debug this after didrocks is back from lunch, with break=casper-bottom
<cjwatson> didrocks: persistent mounts should be set up while casper is putting the unionfs together, so yes
<LucidFox> A Debian developer doesn't want to move upstream source changes out of the diff.gz into a patchset, because "it's tracked in git anyway".
<cjwatson> LucidFox: I sympathise
<cjwatson> LucidFox: actually I'd like to have patches be some kind of automatically exported format, and I believe somebody was working on doing that in git though I haven't seen it done in bzr yet
<cjwatson> but I think saying "I'd like to use the features of my revision control system to deal with merging" is a perfectly reasonable and unsurprising position
<LucidFox> It will make merging into ubuntu a pain, though. :/
<cjwatson> that depends on how merging is handled.  ultimately we should be making use of their revision control in some way.
<pitti> cjwatson: do an ubuntu git branch?
<pitti> sorry
<pitti> LucidFox: do an ubuntu git branch?
<pitti> LucidFox: also, there's nothing wrong with keeping the ubuntu changes in debian/patches onl
<pitti> y
<LucidFox> Hmm. Keeping Ubuntu changes in debian/patches and leaving Debian changes in the diff.gz?
<pitti> sure
<cjwatson> or just applying the Ubuntu changes in the same way as the Debian ones
<pitti> that would be the "ubuntu git branch" style, yes
<slangasek> pitti: is it the lack of explicit verification of the other two bugs that holds up the cryptsetup SRU currently?
<persia> Um, keeping Ubuntu patches in debian/patches and Debian patches unmanaged tends to lead to significant complexity in debian/README,source or stark confusion on the part of those not familiar with the specific package history.
<cjwatson> agreed.
<cjwatson> any particular reason we have so many Ubuntu patches in this case that it's an issue?
<pitti> slangasek: I think it's fine, three weeks and tested by several people
<slangasek> pitti: ok, great :)
<pitti> speaking about SRU; smb, did you get testing for the armel kernels?
<pitti> slangasek: ah, it was the last comment in bug 454898; that's not a regression, though, right?
<ubottu> Launchpad bug 454898 in cryptsetup "cryptsetup starts too early" [High,Fix committed] https://launchpad.net/bugs/454898
<pitti> slangasek: so it seems we can move to -updates, but keep this bug open?
<slangasek> pitti: right, not a regression
<slangasek> pitti: actually, that last comment from me may have been a description of what the SRU /fixes/, rather than an outstanding problem
<slangasek> viz: "the old upstart job"
<pitti> ok; released, thus the bugs are closed now
<slangasek> \o/
<slangasek> thanks :)
<pitti> thanks to you, you did all the work :)
<didrocks> cjwatson: thanks, very weird, when we debug this, seems something is ruining it before 15autologin (right file when we break at casper-bottom and wrong when 15autologin is starting). Still investigating on it. Thanks for the answer :)
<jdstrand> lool: hey, thanks for the ufw fixes :)
<lool> jdstrand: I'm ashamed to say it's the first time I play with it, but let me tell you: it's awesome
<jdstrand> hehe
<jdstrand> lool: glad you like it :)
<lool> I was the guy writing the 7th version of his iptables shell script
 * jdstrand nods
<jdstrand> been there
<lool> Ultimately generating dumps for iptables-load, and now I can just type that in some ufw config if I feel like it but can also use the standard config most of the time
<lool> jdstrand: One thing I wonder about is whether you have any integration with vms -- e.g. libvirt networking awareness
<jdstrand> lool: they are unaware of each other, but also should not get in each other's way because of how I did the chains
<jdstrand> lool: I've been kicking around ideas for that integration, but ultimately ufw needs more FORWARD support
<jdstrand> lool: that is planned, but not this cycle
<lool> jdstrand: Ack
<lool> jdstrand: Anyway, great job!
<jdstrand> lool: thanks! :)
<pitti> cjwatson: so you just pushed lp:~ubuntu-installer/ubiquity/trunk into lp:ubuntu/ubiquity? Did that cause any confusion for the auto-importer? (I'd like to do that for apport and jockey, since people keep doing wrong merge proposals based on the useless auto-imported branch)
<cjwatson> pitti: I did?  I didn't intend to?
<cjwatson> pitti: ubiquity is not yet in a form where it's suitable for lp:ubuntu/... IMO
<pitti> ah, must have mixed that up
<cjwatson> in particular if you check it out from bzr you need to fiddle with it a bit before you can upload a source package
<pitti> ah, it was casper, not ubiuqity, sorry
<cjwatson> Scott did that push
<pitti> ok, thanks
<cjwatson> I don't believe the auto-importer minds as long as there are suitable tags
<pitti> last time I discussed that with james_w he said that it could cause some extra work for him
<cjwatson> I could be wrong, I'm going from design not implementation
<slangasek> AIUI it does require him to manually fix up things on his side after a push has been done, but that this is acceptable
<slangasek> (per james_w himself)
<pitti> james_w: so, I'd like to push the jockey/apport branches into lp:ubuntu/{jockey,apport}; would that be ok for you?
<pitti> (they have proper tags for the uploaded releases, etc.)
<pitti> cjwatson, slangasek: thanks
<tseliot> slangasek: as regards alternatives, do you think the use of --force be better? This would ensure that the slaves are set even if this means overwriting real files
<tseliot> s/be/would be/
<lool> asac: Am with seb128 here and he wondered whether I could look at the libiphone related MIRs -- did you start review of any of libiphone / libplist / usbmuxd?
<slangasek> tseliot: mm, that sounds unpleasant to me :)
<tseliot> slangasek: usually (i.e. if we deal with alternatives correctly) we shouldn't need that. I was asking as in Mandriva  they use a fork of update-alternatives which sets --force by default
<slangasek> ick :)
<tseliot> note: I wasn't suggesting that we use it ;)
<asac> lool: i reviewed libplist
<asac> odd ... where did it go ;)
<lool> asac: Cool; I think the testsuite should be enabled, but we're in sync with Debian so would be nice to ping the Debian/Ubuntu maintainer (Julien Lavergne) when adding that
<lool> asac: I will stop reviewing it now, would be happy to get your comments on that one in the bug
<smoser> what is the posting policy to ubuntu-devel mailing list ?  I always get "awaiting approval" but I'm subscribed to the list.
<elmo> smoser: https://wiki.ubuntu.com/UbuntuDevelModeration
<asac> lool: done
<elmo> smoser: oh, never mind, that page no longer says what i thought it said
<asac> lool: the testsuite doesnt work. i noted it as a nice to have
<asac> lool: the type punning things i also noted and the fread not dealt return values
<asac> i asked for bugs for those, but didnt block MIR
<lool> asac: thanks
<asac> lool: i have my mir slot (set up since this week) in 20 minutes. so if you want me to look at something else let me know
<lool> asac: Actually if you could tend to usbmuxd and libiphone that'd be great
<lool> asac: I'll still do some quick review on them since I started, it should give a better coverage
<asac> ok post your findings
<asac> though i expect your quick review should be good enough ;)
<asac> libiphone done
<sladen> asac: the 1.0 release of libiphone should be out Real Soon Now(tm)
<asac> kk
<sbalneav> DktrKranz: I'm going to cook a new release today
<DktrKranz> sbalneav: excellent! I'll prepare update for Debian, we're close to have it in unstable again :)
<sbalneav> DktrKranz: Excellent!  I've put in a lot of work to get Sabayon working again for Debian/Ubuntu, I'm glad!
<asac> sladen: is usbmuxd running as root?
<sbalneav> I'm basically an upstream now for sabayon.
<sbalneav> DktrKranz: if you or any other debian devs have problems with sabayon, just ping me here, or in #sabayon at irc.gnome.org
<DktrKranz> sbalneav: sure! you already fixed one of my blockers :)
<sladen> asac: it immediately drops to user 'usbmuxd'
<sladen> asac: it presents a FIFO in /var/run/usbmuxd (same place and talking the same protocol as on Mac OSX).
<asac> sladen: where in code is the parsing of input done?
<asac> i mean the input we get from device ;)
<sladen> asac: multiple applications can then request proxy sessions to particular TCP ports on the device(s);  these are wrapped up and encapsulated in Apple's usbmux [sic] wire protocol and bunged over the USB
<rendero> where does drkonqui stores the crashes ?
<sladen> asac: daemon/device.c
<tkamppeter> someone knows what it means if "mkdir -p" exits with status 2?
<sladen> asac: device_data_input() -> device_tcp_input() -> connection_device_input()
<asac> sladen: yeah. commented on bug
<sladen> asac: oh which bug?
<sladen> tkamppeter: not off the top of my head.  Probably lack of permission, or lack of disk space
<cjwatson> tkamppeter: the info documentation simply says "a nonzero value indicates failure".  I would expect to see a more detailed error message to accompany the exit status
<asac> sladen: the MIR for usbmuxd
<asac> not your bug, but you seem to take care for that package :)
<cjwatson> tkamppeter: from a quick glance through the source, I actually don't see any way it could exit 2, but I'm probably just missing something.  I don't expect trying to decode the exit status will be very useful in practice
<tkamppeter> cjwatson, sladen: Thanks, I did not find anything on Googling, and thought that there are perhaps some standard exit codes or missing documentation. With what I found I am wondering how mkdir can exit 2.
<cjwatson> tkamppeter: it's not really important
<cjwatson> documented: zero => success, nonzero => failure.
<tkamppeter> I can even manually do this mkdir (it fails when executed by a web app) on the same server and as the user as which web apps get executed.
<aburch> Could somebody request removal of the `anyevent' package?  See #470560 for the rationale (/me does not use Ubuntu, so I cannot look for reverse dependencies).
<sladen> asac: 'sent' upstream
<sladen> asac: could you sanity check the privilege dropping too?  (grep drop_privileges daemon/main.c
<asac> sladen: that looks good afaict
<asac> sladen: hmm. maybe drop_privileges should default to 1?
<asac> who is running that?
<asac> e.g. who is supposed to use -U?
<sladen> asac: what about the locking and notifying of previously copies over the drop---there's more of it than I'd like
<sladen> asac: A user /can/ it as themselves, if change the FIFO location away from the standard Apple location
<sladen> asac: so -U is basically used from the udev rules
<asac> sladen: the locking?
<asac> or loggin?
<sladen> asac: grep for kill()
<sladen> asac: main() { parse_opts(), set_signal_handlers(), lock file handling,  drop_privs,  usb_init() } ---so there shouldn't be any externally derived data until after the drop
<asac> the killing wont work if not run as root if the previous instance didnt rop privileges
<asac> otherwise i agree
<cjwatson> tkamppeter: use strace or something to figure it out
<tkamppeter> cjwatson: Thanks, I have already found the cause of the problem, was not mkdir by itself.
<mterry> How do I download a package from debian NEW?  (specifically http://ftp-master.debian.org/new/google-gadgets_0.11.1-1.1.html)
<seb128> mterry, you can't
<mterry> seb128, oh.  How do they get accepted then, if one can't see the changes?
<seb128> mterry, who is one?
<seb128> mterry, the archive admin can
<seb128> the archive admins
<mterry> seb128, ah, ok
<mathiaz> ttx: the -server iso have been respun?
<ttx> mathiaz: see -server
<ttx> mathiaz: yes, another day, more ISo testing :)
<sbalneav> DktrKranz: FYI, sabayon-2.29.5.tar.gz just got released.  It'll be working it's way through the usual GNOME mirrors
<DktrKranz> sbalneav: yeah, just got the mail, thanks! :)
<slangasek> luisbg: it appears UbuntuStudio install is broken right now because it wants usplash, which is conflicted by plymouth, which is now standard; do you guys want to try to fix this for alpha-2?
<mathiaz> apw: hi
<mathiaz> apw: is the i386 -virtual kernel flavour supposed to be -generic-pae?
<mathiaz> apw: in the past releases it used to be -server
<mathiaz> kenvandine: hi - are you sponsoring the ubuntuone-client packages usually?
<mathiaz> kenvandine: there is bug 495676 about a karmic SRU
<ubottu> Launchpad bug 495676 in ubuntuone-client "Upgrade to 1.0.3 release" [Critical,Fix released] https://launchpad.net/bugs/495676
<matti> Folks, can somebody update MD5/SHA1 hash for this little fella?
<matti>  W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/pool/restricted/f/fglrx-installer/fglrx-amdcccle_8.660-0ubuntu4_i386.deb Hash Sum mismatch
<cjwatson> matti: I'm pretty certain it's fine in the archive (it's extraordinarily rare for this to be actually an archive-side problem); it's almost certainly a problem on some web proxy between you and the archive, unfortunately
<matti> Hm.
<matti> It is not me actually.
<matti> I am talking on behalf of AlanBell ;]
<matti> cjwatson: And you were very right, indeed ;]
<matti> [18:51:40] < AlanBell> actually it worked now
<matti> [18:51:53] < AlanBell> mobile broadband ftl
<matti> cjwatson++
<mathiaz> jcastro: hi!
<mathiaz> jcastro: is there a standard bug reply for "Forward this patch to Debian please?"
<mathiaz> jcastro: this is for example in bug 229760
<ubottu> Launchpad bug 229760 in devscripts "RFE: allow permanent setting of distribution for dch" [Wishlist,New] https://launchpad.net/bugs/229760
<Daviey> mathiaz: you could just use submittodebian yourself :)
<mathiaz> Daviey: the patch is not the ubuntu package yet
<Daviey> mathiaz: ah
<jcastro> mathiaz: not as far as I know, you could just add one here: https://wiki.ubuntu.com/Bugs/Responses
<jcastro> mathiaz: an adaptation of this one perhaps: https://wiki.ubuntu.com/Bugs/Responses#A bug that should be handled upstream
<mathiaz> jcastro: ah nice. Thanks!
<mathiaz> jcastro: is https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Bugs%20fixing%20small%20details still valid?
<mathiaz> jcastro: are there any other tags/process that should be used bugs that needs to be forwarded to upstream?
<jcastro> mathiaz: having the open task is all you need
<jcastro> mathiaz: however, if would be wise to have someone checking bugs with open upstream tasks and fixed in ubuntu on a regular basis
<mathiaz> jcastro: I've opened an empty Debian task - so it's all good :) thanks
<slacker_nl> hi, what was the irc channel again for canonical sysops?
<Pici> slacker_nl: #canonical-sysadmin
<slacker_nl> Pici: thnx
<mathiaz> kees: Hi! - is export DEB_BUILD_HARDENING=1
<mathiaz> kees: hm- - is ^^ enough to enable-pie?
<mathiaz> kees: in apache2, there is configure option for enabling pie
<mathiaz> jdstrand: ^^ actually you did the last merge
<mathiaz> jdstrand: in apache2 debian/rules enable-pie is no longer there
<jdstrand> mathiaz: I didn't do the merge, I applied a security update
<jdstrand> oh, wait, maybe I did
<jdstrand> mathiaz: https://launchpad.net/ubuntu/+source/apache2 show zul as the last merger
<kees> mathiaz: you need two things: export DEB_BUILD_HARDENING=1 in rules, and hardening-wrapper in debian/control
<mathiaz> jdstrand: right - the package branch is not up-to-date
<kees> mathiaz: upstream removed native pie?
<kees> mathiaz: actually, I didn't think apache2 had that, I thought it was only samba.
<mathiaz> kees: hm well - debian/rules has --enable-pie
<kees> mathiaz: anyway, if you want, try building with  hardening-includes  instead of hardening-wrapper.  I can find an example of that.
<zul> that branch may not be up to date
<kees> mathiaz: ah, okay.
<zul> kees: hardening is there i dont think the branch is up to date
<mathiaz> kees: so apache2 build-depends on hardening-wrapper, export DEB_BUILD_HARDENING=
<mathiaz> kees: and --enable-pie in configure
<mathiaz> kees: should some of this be dropped?
<mathiaz> kees: it export DEB_BUILD_HARDENING=
<mathiaz> kees: it export DEB_BUILD_HARDENING=1
<kees> mathiaz: that's probably correct as upstream probably only does the PIE part, but the wrapper also enables -Wl,-z,now which we do for our PIE builds
<mathiaz> kees: ok - so it should be kept as it is now
<kees> mathiaz: in the off chance that --enable-pie does something additional to support PIE in apache, yeah, I would leave it all as-is.
<kwwii> does anyone here understand what the --priority option for dh_gconf actually does?
<kwwii> I have read the man page but it leaves me clueless
<RAOF> It looks like it'll set the priority of the gconf defaults you install; so packages can override other defaults.
<ScottK> slangasek: I got tired of libicu20, so I've now uploaded all the rebuilds needed to see it go except boost1.38 and I'm closing in on just removing that.
<kwwii> RAOF: yeah, but does a higher number mean more important or less?
<RAOF> More.
<kwwii> I know, I can figure it out by testing but I'd rather not waste the time if anyone knows offhand ;)
<micahg> tedg: are you available?
<tedg> micahg: Sure.
<tedg> micahg: What's up?
<micahg> tedg: I think I sent an email a while back about updating a mozilla bug with some info about libindicate
<micahg> tedg: would you be able to update mozilla 478463
<ubottu> Mozilla bug 478463 in Backend "Add libnotify (+ libindicate) support to Thunderbird" [Enhancement,New] http://bugzilla.mozilla.org/show_bug.cgi?id=478463
<micahg> please :)
<tedg> micahg: I don't have a login there :-/
<micahg> tedg: it's free to create an account :)
<micahg> tedg: or if you give me the info requested I can post it
<tedg> micahg: About the desktop file?  It seems that Thunderbird would have to have one it installs, right?
<micahg> tedg: yes, but not from mozilla
<asac> micahg: you can link the bug
<micahg> tedg: they were looking for API docs
<asac> then the launchpad users can communicate via launchpage
<micahg> asac: already did
<tedg> micahg: Seriously?  They're bitching about us modifying how their apps are seen and they don't even provide the most basic interface for the app.  Wow.
<asac> pad
<asac> tedg: you can use the launchpad bug to talk to them ;)
<asac> use reply to upstream bug
<micahg> ok, right :)
<micahg> forgot
<micahg> bug 334344
<ubottu> Launchpad bug 334344 in libnotify-mozilla "wishlist: integrate libnotify in Thunderbird notifications" [Undecided,Fix released] https://launchpad.net/bugs/334344
<micahg> tedg: the FF bug is worse ;)
<kwwii> duh, sometimes one should go to bed when one is tired instead of making an idiot of oneself
<tedg> micahg: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/334344/comments/43
<ubottu> Ubuntu bug 334344 in libnotify-mozilla "wishlist: integrate libnotify in Thunderbird notifications" [Undecided,Fix released]
<tweakt_> I've created a custom installer cd, but base-installer doesn't seem to be installing any kernels, even though they are available in the packages I've included on the CD. Any hints as to where to start looking?
<tweakt_> In /tmp I see available_kernels.txt and available_kernels.txt.unfiltered, both empty
<tweakt_> looks like apt was never configured, so no apt-cache, no lines in /etc/apt/sources.list nothing in sources.list.d
<tweakt_> nevermind... I haven't preseeded my keyring used to sign the cd
<cjwatson> tweakt_: ... you beat me to it, I was about to start making suggestions but you're ahead of me
<cjwatson> tweakt_: you could just turn off authentication for now
<cjwatson> tweakt_: debian-installer/allow_unauthenticated=true
<tweakt_> whats the best method of getting our key into the system prior to apt-setup? customize ubuntu-keyring?
<cjwatson> that's reasonable, although I've come to believe that signing CDs is a bit of a waste of effort
<cjwatson> the user's booting from the thing - they trust it implicitly
<cjwatson> signing the checksum for downloaders, that's a different matteer
<cjwatson> -e
<tweakt_> ahh true
<cjwatson> so personally, I'd recommend just not signing the Release file on the CD at all
<cjwatson> d-i should be OK with that
<tweakt_> I see, cause if I wanted to inject something I would just replace the key and resign the whole thing
<cjwatson> indeed
<cjwatson> or just remove the key
<cjwatson> or replace the entire CD with something else :)
<tweakt_> We're still going to want a key on the system for custom packages
<cjwatson> you want a key for authenticating network archives
<tweakt_> yes
<cjwatson> apt-setup has some special preseeding for that
<cjwatson> look for things like apt-setup/local0/key in the installation guide
<tweakt_> oh, right. cool.
<tweakt_> btw, ended up using a combo of germinate + reprepro to build things
<tweakt_> germinate output gets pulled into a selections list, used to filter what reprepro mirrors
<tweakt_> works nicely
#ubuntu-devel 2010-01-15
<jono> what is the best of getting a list of apps in the archive written in pygtk that use gtkstatusicon?
<RAOF> Hm.  I _think_ you'll have to grab the sources of all the packages that depend on python-gtk2 and grep for gtk.StatusIcon.
<RAOF> I'd be interested to hear any better solutions, though :)
<slangasek> ScottK: yay, removals are my favorite!
<johanbr> jono, for packages in debian, you can use http://source.debian.net/source/
<jono> thanks johanbr
<johanbr> you're welcome :)
<tweakt_> should I be able to preseed language, country and keyboard settings?
<cjwatson> tweakt_: yes but only using boot parameters
<tweakt_> ahh, that explains it
<cjwatson> the programs that handle file/url preseeding run after language/country/keyboard have been asked
<robert_ancell> jamesh, is there a repository for launchpad-integration? I have a patch for C# support
<cjwatson> johanbr: oh my, I hadn't seen that before.  that's fantastic.
<johanbr> saw that yesterday on a Fedora mailing list, of all places
<cjwatson> this is going to save me a ridiculous amount of bandwidth over time.
<johanbr> :)
<micahg> robert_ancell: https://edge.launchpad.net/lpx
<robert_ancell> micahg, i don't see it there - I'm talking about the package "launchpad-integration" which adds menu items into GTK+ apps help menu
<persia> robert_ancell: launchpad-integration is a native package, so lp:ubuntu/lucid/launchpad-integration might be a reasonable thing to branch
<persia> robert_ancell: Also, apt-cache show launchpad-integration shows an Original Maintainer who tends to be around, you might also contact that individual.
<micahg> robert_ancell: ah, sorry
 * micahg missed the -
<robert_ancell> persia, yes, as far as I can tell jamesh is the original author and seb128 packaged it.  I'm guessing the answer is no (there is not an official repository) but I can bully him into putting it somewhere oficially. (and getting mvo to link it to lpx - thanks michag)
<jamesh> robert_ancell: you should be able to find what you're after here: https://launchpad.net/launchpad-integration
<jamesh> I haven't been involved with it much since the first few versions though.
<robert_ancell> jamesh, is it stored in version control somewhere?  Could I encourage you to make a lp:launchpad-integration branch :)
<robert_ancell> jamesh, ok
<jamesh> robert_ancell: lp:~ubuntu-core-dev/launchpad-integration/ubuntu looks like the trunk
<jamesh> looks like mvo is the one who'd have permissions to make that branch accessible as lp:launchpad-integration
<robert_ancell> jamesh, thanks, that's what I was looking for.  I'll bug mvo to update the LP page
<persia> I'm not convinced we want to encourage the practice of enabling lp:foo for native packages where there isn't a distinct upstream.
<persia> More likely, it would make sense to integrate that into lp:ubuntu/* and update the tags appropriately.
<persia> (unless the content is useful outside the context of the distribution, in which case I question whether it should be a native package).
<jamesh> persia: but if people (like robert_ancell) want to make contributions, they'll want to base them on that branch
<jamesh> that seems like enough reason to set it as the development focus
<persia> (for more thoughts on the matter, read backscroll from about 11 hours ago, talking about ubiq_uity and joc_key
<persia> jamesh: Except I think that branch ought to go away for the new model of distributed development.
<persia> Because either the software is a separate upstream (in which case it doesn't make sense for ~ubuntu-core-dev to be the trunk branch owner), or it isn't (in which case there's little value to the project external to Ubuntu and that branch only exists as a historical workaround until lp:/ubuntu/* worked)
<jamesh> persia: I don't really see what difference it makes though.  If the branch owned by ~ubuntu-core-dev is where the development occurs, then it is the development focus
<jamesh> if development occurs elsewhere, then it is not.
<jamesh> the development focus might also be the branch where the packaging is managed, but that is separate.
<cjwatson> the difference is the same as the difference between a "real" upstream package with independent upstreamish existence, and a native package that exists just for the distribution
<persia> Yes, but my argument is that the current branch is a temporary workaround, and it makes sense to fix that rather than setting focus.
<persia> The two ways to fix it being 1) set an upstream team and branch or 2) use the DistributedDevelopment branch
<cjwatson> which are definitely two different things in distro people's heads - in particular native distro packages aren't particularly expected to be used/usable by other distros
<jamesh> if some other distro shows an interest, then it might make sense to separate things out
<jamesh> but right now, it seems pretty clear that the ~ubuntu-core-dev branch is the development focus in this specific case
<jamesh> that might not always be true, but it is true now.
<cjwatson> what persia is I think arguing is that it does not make sense for there to be a project for it at all
<persia> Or if there should be a project, the trunk branch should be defined differently and the packaging done differently.
* slangasek changed the topic of #ubuntu-devel to:  Lucid Alpha 2 released | Archive: open | MoM no longer running, use bzr! - Outstanding merges:http://people.ubuntuwire.com/~lucas/merges.html | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<didrocks> good morning
<dholbach> good morning
<didrocks> superm1: about bug #507121, I've track it down and it's /usr/lib/user-setup/user-setup-apply which screw up custom.conf in both casper and ubiquity phases. So, I'll push a fix today and ping you so that you can remove your workaround
<ubottu> Launchpad bug 507121 in netbook-meta "Netbook Edition Lucid Alpha 2 - After first boot default GNOME desktop instead UNR Launcher" [Medium,Triaged] https://launchpad.net/bugs/507121
<persia> If I want to ask for non-free (unable to modify) data be moved from multiverse to restricted, is that just an MIR, or does it first require a request to the TB?
<coz_> hey guys.. out of curiosity...for xplash the frames set are 50  I believe... where do I change that setting?
<coz_> also is there a file to change the location of the animated xsplash on the screen?
<arand> coz_: afaik, it must be done in the source before compiling, and it's rather untrivial.
<coz_> arand,  mm  ok    so  essentially 50 frames   I can deal with that :)
<coz_> arand,  thanks
<woozy_> coz_: the framerate can be controlled by giving xsplash a parameter on startup, xsplash --help should tell you which one
<coz_> woozy_,  ah   that may help quite a bit  thanks :)
<dholbach> james_w, kenvandine, sommer, crimsun: can anybody of you please block dav23 from the !ubuntu identi.ca group?
<didrocks> cjwatson: if you have any time to sponsor bug #507121 to fix all that session stuff in persistent usb key and after ubiquity install, thanks :)
<ubottu> Launchpad bug 507121 in user-setup "Netbook Edition Lucid Alpha 2 - After first boot default GNOME desktop instead UNR Launcher" [Medium,Triaged] https://launchpad.net/bugs/507121
<cjwatson> didrocks: in progress
<didrocks> cjwatson: thanks
<jussi01> Hey all, are there any ~ubuntu-archive members about atm?
<seb128> jussi01, you should ask your question
<geser> that reminds me: can an archive admin please check why libxcb in lucid is still 1.4-1 and the both syncs of 1.5 failed in the end? (see bug #492247 and bug #503290)
<ubottu> Launchpad bug 492247 in libxcb "Sync libxcb 1.5-1 (main) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/492247
<ubottu> Launchpad bug 503290 in libxcb "Sync libxcb 1.5-2 (main) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/503290
<seb128> geser, looking
<seb128> geser, 2010-01-15 12:28:19 ERROR   Exception while processing upload /home/lp_queue/sync-queue/incoming/seb128-20100115-122812 (OOPS-1476FTPMASTER1)
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1476FTPMASTER1
<seb128> geser, I'm pinging soyuz guys to know if that's a known bug
<cjwatson> didrocks: merged the user-setup one.  For future reference you don't really need ubiquity tasks when it's just a standard rebuild, but I've merged that branch anyway
<didrocks> cjwatson: oh, ok. I note it down. Thanks :)
<LordMetroid> Alright, I am going to go ahead and break my system
<LordMetroid> See you one the other side of alpha2
<persia> Could someone press the retry button on https://launchpad.net/ubuntu/+source/metacity/1:2.28.0-2ubuntu2/+build/1430446
<cjwatson> persia: done
<persia> cjwatson: Thanks.
<mdeslaur> slangasek: do you know of anyone who can test a libthai security update?
<jdstrand> mdeslaur: actually, ArneGoetje may be able to
<mdeslaur> ah! cool, thanks jdstrand
<jdstrand> mdeslaur: I'm not sure, but he is our lang guy
<mdeslaur> jdstrand: thanks, I'll ask him
<mdeslaur> ArneGoetje: ping
<persia> Seems odd that we don't have an #ubuntu-th
<mdeslaur> persia: we don't? or are you being ironic? :)
<persia> mdeslaur: It's not listed as an official channel
<persia> But you could ask there, because it's *supposed* to be the Thai channel.
<persia> (where official channels are defined at https://help.ubuntu.com/community/InternetRelayChat#Channels , although some might argue that a fairly open wiki is a strange way to define "official")
<mdeslaur> persia: oh, ok. thanks.
<RainCT> pitti: Hey. Seems like you forgot to push your changes to ubuntu-dev-tools to the branch (and you also skipped the 0.88 release :)).
<persia> RainCT: So, based on some discussion about 24 hours ago, there's apparently some procedure that can be done to switch from the current branch to just using lp:ubuntu/${release}/ubuntu-dev-tools .  Do you happen to know who most owns that package?
<RainCT> persia: Oh. No, I haven't looked into any of that VCS stuff yet.
<apw> pitti, does your new burndown data include the kernel wiki page?
<RainCT> persia: It looks like that's handled transparently, though. lp:ubuntu/karmic/ubuntu-dev-tools already exists, and "bzr info" shows lp:~ubuntu-branches/ubuntu/karmic/ubuntu-dev-tools/karmic/
<cjwatson> RainCT: that's probably an automatic import rather than the existing branch, though.  I suspect you'll find it isn't nearly so detailed.
<cjwatson> RainCT: the procedure for switching the branch references is to file a bug on the 'udd' project.
<RainCT> cjwatson: Oh, OK. So it's not ready for mass consumption yet :)
<cjwatson> RainCT: I didn't say that?
<apw> pitti, does your new burndown data include the kernel wiki page?
<cjwatson> RainCT: it's generally fine, but it needs tweaks when people were already using revision control to manage their package
<persia> But it has the excellent super-cool feature of automatically dealing with uploads, so we don't have to pester the forgetful uploader to push to the branch.
<persia> (or at least that's the impression I have)
<RainCT> cjwatson: So you aren't supposed to be able to just pull and push, but need to ask for access to the branch? Or is that just for now (which is what my comment referred to)
<persia> RainCT: It's that the real history of the development branch needs to be merged into the import branch.
<RainCT> OK. So if I take some other package which was't maintained in bzr before I can push there?
<persia> RainCT: https://wiki.ubuntu.com/DistributedDevelopment might be a good primer
<RainCT> persia: Yeah, I was trying to avoid reading all that :)
<persia> heh :)
<persia> But as long as we're managing ubuntu-dev-tools in bzr anyway, it seems reasonable we should use the branches made available in that system.
<cjwatson> RainCT: I believe you've misunderstood me somehow.
<persia> Then again, I don't know the system well enough to drive that (but I hope I've already completed all my ubuntu-dev-tools changes for lucid)
<cjwatson> RainCT: ~ubuntu-branches is magic.  Anyone who can upload the package can edit the branch.
<RainCT> cjwatson: So your comment was only about merging in the old history?
<cjwatson> RainCT: but, as I said above, if you already have a branch with more detailed history, it would be more appropriate to get the lp:ubuntu/... pointers updated to point to that.
<cjwatson> RainCT: my comment was about changing what lp:ubuntu/... points to
<RainCT> cjwatson: OK, I see. Thanks for the clarification.
<cjwatson> I would not recommend merging the old history into the automatically imported branches in the sense of 'bzr merge' - the result is not likely to be pretty.  It is usually more appropriate to ignore the automatically imported branches if you already have better ones, but it *is* still useful in that case to get lp:ubuntu/... updated.
<persia> cjwatson: But if we redirect lp:ubuntu/... will we lose the magic access control and automatic import of uploads?
<cjwatson> persia: probably.
<cjwatson> I'm not sure about access control.
<cjwatson> alternatively you could push --overwrite over the top of the ~ubuntu-branches branch - but ask james_w first, and I'd recommend keeping a copy elsewhere
<persia> Hrm.  I think I'll have to learn more about this before promoting it further.
<kees> cjwatson: oh, btw, can I help at all with debian bug 562048 ?  it's a workitem for the security team, so I'm hoping you might have time to review it.  Do you want me to s/ReportExtraversion/DebianBanner/ on the proposed patch and resubmit?
<ubottu> Debian bug 562048 in openssh "allow for the package-specific version banner to be suppressed" [Wishlist,Open] http://bugs.debian.org/562048
<cjwatson> kees: more hours in day pls; I'm finishing up a task this week, so ask me at the start of next week?
<kees> cjwatson: okay, thanks.  :)
<hwilde> hours++
<LordMetroid> Breakage of my system complete, I am now in Alpha2, just a restart away(*shudders*)
<Incubuss> Can anyone confirm/deny for me that the Interface tab has been removed from Appearance Preferences in gnome?
<seb128> Incubuss, it has
<Incubuss> any idea why or if the options being reimplemented anywhere else?
<seb128> they are gconf keys
<seb128> I think they decided that's something useful in the ui
<directhex> seb128, so there's now no way to revert the ass-backwards "no icons in menus please" behaviour without gconf-editor?
<seb128> no
<Incubuss> Ubuntu-tweak makes it possible to get them back but it still took me a good 5 minutes to find the option
<Sweb> hi need help with ubuntu
<Sweb> any user here?
<LordMetroid> Ohh noes, alpha2 can not even start, it totally locks during bootup
<LordMetroid> Anyone else have this problem?
<slangasek> asac: so, what specs are missing from your report?
<slangasek> pitti: could we get some kind of final run of the alpha-2 burndown charts, to verify that all the unfinished workitems have been postponed?
<asac> slangasek: so on: http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
<asac> 1st. we have like 30% work item loss over what we had on the old one ..
<asac> but i think that was due to the new parser being pickier about the syntax
<slangasek> ok
<asac> i am going through the itesm now to verify everything is fine
<asac> then we have to wait and see if thats good
<asac> 2nd. there are specs that dont belong there ;)
<asac> desktop-lucid-xorg-halsectomy
<asac> foundations-lucid-dropping-sun-java6
<asac> 3rd. similarly i suspect that we lost one or two specs ... will check that after doing 1st ;)
<slangasek> asac: well, they belong there because the work items are assigne to members of your team
<asac> ah ;)
<asac> ok
<slangasek> that's by design
<asac> thats good then
<asac> ok. then maybe 3rd is not the case and the loss of items is due to the syntax
<asac> lets check how it looks on monday then.
<slangasek> ok
<asac> and firefox-support spec obviously too ... ok
<asac> ;)
<slangasek> assign them all to ccheney? :)
<asac> i plan to do that next time pitti is about to deliver a all 100% report ... just to nag him :-P
<asac> ok enjoy weekend
<slangasek> might be more productive if ccheney has more warning that he's responsible for them ;)
<slangasek> you too!
<Nafallo> kirkland: hey. take a look at bug #505909 when you have a moment.
<ubottu> Launchpad bug 505909 in testdrive "When I lanch Test Drive and try to start Ubuntu Netbook Remix (Luicid) the cli closes and nothing happens" [High,Confirmed] https://launchpad.net/bugs/505909
<Nafallo> meh. that wasn't a message. but at least the bot got something to do...
<niktaris> hi,  I am remastering the latest version of ubuntu but can't seem to dist-upgrade it. It keeps failing on kernel and rsyslog. Any Ideas ?
<niktaris> a yes, by dist-upgrade I mean via chroot
<BBHoss> Does anyone remember a bug a while back with tickless kernels? that made the cpu usage go up for things that used timers heavily?
<BBHoss> specifically FreeSWITCH
<mathiaz> kees: hi - I'm writting a blog post to announce the demotion of nis to universe
<mathiaz> kees: what are the main reasons for such a demotion?
<mathiaz> jdstrand: insecure? old? unmaintained?
<mathiaz> jdstrand: ^^
<slangasek> insecure-by-design protocol?
<jdstrand> it's both old and a bad design with better alternatives
<jdstrand> well, a bad design in the modern age, I guess it was the cat's pajamas back in the day
<jdstrand> (always insecure though)
<slangasek> I have never known a cat that would wear NIS pajamas
<jdstrand> you need an old cat
<siretart> slangasek: in combination with kerberos, nis turns out to be pretty useful
<slangasek> siretart: no, it's still insecure.
<slangasek> unless you mean you've found a kerberos-enabled implementation of NIS itself?  which the one we ship isn't
<slangasek> (and then it's pretty much not protocol-compatible)
<siretart> no, at my department, we removed password hashes from our nis database and use kerberos for authenticating
 * kees agrees with jdstrand and slangasek
<slangasek> siretart: that's not secure.  Anyone with access to your network can spoof the maps.
<kees> "my uid is 0!"
<siretart> slangasek: well, true, we have additional measures in our switches. which we would want even if we would switch to ldap anyway
<mathiaz> kees: http://paste.ubuntu.com/357257/ <- does this look ok?
<kees> mathiaz: ieee line wrap ;)  reading...
<mathiaz> kees: sorry :/
<kees> mathiaz: yeah, sounds about right.
<mathiaz> kees: great - thanks for the quick review!
<kees> np
<lamont> I wonder - how long is openclipart supposed to take to build...
<lamont> thallium has been working on it for a while
<sistpoty> create random set of pixels, check if it looks like a clipart, if not -> begin again :)
#ubuntu-devel 2010-01-16
<pH> hey guys
<pH> my new ruby library to implement notify-osd notifications
<pH> http://github.com/pedrofranceschi/notify-osd-ruby
<kees> should debian bug 562048 be merged with the collection in 130876 ?
<ubottu> Debian bug 562048 in openssh "allow for the package-specific version banner to be suppressed" [Wishlist,Open] http://bugs.debian.org/562048
<kees> cjwatson: ^^   sorry, missed prefixing that question.
<cjwatson> kees: certainly not completely.
<cjwatson> kees: I'd rather leave that cluster alone, TBH. :-)
<kees> cjwatson: oh, okay.  how is that different?  Seems to be the same original issue?
<kees> doko_: can you approve my membership to the openjdk LP team?
<cjwatson> kees: huge bugs with lots of people reporting lots of different things.  Not all of them are covered by this and I really don't want to go and unpick them.
<kees> cjwatson: cool, yeah, that's fine by me.  just curious.
<cjwatson> kees: some bits are fixed and some are wontfix.  A task for another day.
<kees> heh, understood.
<bryyce> hmm, I took karmic's miro package, updated it to lucid with no other changes, and put it into a lucid ppa, and it is failing to build now
<bryyce> http://launchpadlibrarian.net/37943965/buildlog_ubuntu-lucid-amd64.miro_2.5.3-1ubuntu2~bryce_FAILEDTOBUILD.txt.gz
<bryyce> /usr/bin/ld: cannot find -lboost_python-mt
<bryyce> ^ anyone have clues on this?
<kees> there's a boost transition, iirc.
<slangasek> there's always a boost transition
<kees> haha
<bryyce> okay...
<bryyce> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,--as-needed -g -O2 -g -Wall -O2 /build/buildd/miro-2.5.3/./build/temp.linux-x86_64-2.6/build/buildd/miro-2.5.3/portable/fasttypes.o -lboost_python-mt -o /build/buildd/miro-2.5.3/./build/lib.linux-x86_64-2.6/miro/fasttypes.so\
<bryyce> how's that going to need changed?
<kees> the build-deps need to be changed most likely.  but in what way, I don't know.
<crimsun> libboost-python1.40-dev: /usr/lib/libboost_python-mt-py26.a
<crimsun> libboost-python1.40-dev: /usr/lib/libboost_python-mt-py26.so
<kees> if you can find what has libboost_python-mt.so in it now...
<kees> oh
<kees> there it is.  :)
<slangasek> yeah, it's not a build-dep problem
<kees> oh ew, really?
<slangasek> the package needs to change the way it looks for libboost-python - see the above name change
<kees> ew
<slangasek> libboost_python-mt-py26, not libboost_python-mt
<bryyce> miro's build-depends include:
<kees> -py26 that's cute.
<bryyce>                libboost-python-dev,
<bryyce>                libboost-filesystem-dev,
<bryyce>                libboost-date-time-dev,
<bryyce>                libboost-thread-dev,
<bryyce>                libboost-serialization-dev,
<bryyce> do I need to make them specify a version, or is this something that needs changed in libboost-python-dev?
<slangasek> neither, see above
<slangasek> the python ABI version has to be specified as part of the linker line now
<slangasek> (we could change it, but this is courtesy of the Debian maintainers, and the last thing you want to do is be responsible for a boost delta ;)
<bryyce> hm
<kees> doesn't it provide a pkgconfig file?  wtf
<bryyce> so leave debian/control as is, and update rules?
 * slangasek nods
<slangasek> kees: have you met boost?
<kees> apparently not.
<bryyce> urf.  miro uses cdbs and doesn't explicitly mention boost anywhere in rules
<slangasek> well, you might have to patch the upstream makefile anyway
 * kees runs screaming from boost
<slangasek> good call
<bryyce> intriguing
<bryyce> miro hasn't any makefile or autoconfage, it does all the g++ stuff from python
<bryyce> which automagically figures out which boost library to use.  mmph
<bryyce> brain hurt :-(
<bryyce> ok well at least I know now the build breakage isn't my own fault :-)
<Sarvatt> bryyce: changing line 308 in platform/gtk-x11/setup.py to return "%s-mt-py26" % s let it build here  locally
<bryyce> Sarvatt, thanks
<hggdh> question: would Debian be insterested on updated debian/patches for coreutils-8.4?
<crimsun> ion: I'm happy to reenable flat volumes for PA, but I don't know a good way of evaluating whether it's suitable for an LTS
<crimsun> ion: my instinct is that it isn't (suitable)
<ScottK> crimsun: If you consider that enabling PA by default was considered suitable for an LTS, I think the bar is pretty low.
<crimsun> ScottK: right, this would be the second LTS
<ScottK> Well whatever the arguments for against PA, I thought an LTS was an odd place to start.
<ScottK> I guess we're trying to do better this time around.
<crimsun> one could say that, yes.
<Dhaval23> can anybodu know how to connect samsung s3310 in ubuntu9.10 for mobile broadband
<Dhaval23> hello
<ulaas> hi. hal is to go away right.? i have upgraded from karmic to give the current devel a look. hal packages stays on the system. is it ok to remove them? including libhal?
<ulaas> or hal only dropped from power management.? so the rest of the system needs it?
<siretart> ulaas: there are still some package that have not been ported to libudev, e.g. pcscd, but there are also others
<ulaas> siretart, so libhal will always be a dependency? or it will also go away?
<siretart> ulaas: eventually, it will go away AFAIUI
<siretart> maybe
<ulaas> siretart, thank you sir. :)
<Guest86434> my glib is latest 2.23.1,. but i git this error in ubuntu 9.10  /x/git2/nautilus/src/nautilus-pathbar.c:1380: undefined reference to `g_mount_get_default_location'
<Guest86434> when i want to compile
<rauch> I would like to participate in some OpenSource project in Team to get skill and knowledge. I know C++ and Java. What can you sugest for me? May be you know that teams? I have now experience.
<rauch> *no experience
<Guest86434> how can i compile nautilus on ubuntu,?
<alkisg> Guest86434: apt-get build-dep nautilus ?
<alkisg> rauch: the #ubuntu-motu channel might be a better place to start...
<slacker_nl> hello everyone, hoe can I create a source package with pbuilder? I've used pdebuild --use-pdebuild-internal, and documenation states that this behaviour doesn't create source packages..
<slacker_nl> is there a way to create a source package even when using --use-pdebuild-internal? or should I use hooks to satisfy dependencies so I don't have to use use-pdebuild-internal?
<Guest86434> alkisg,making....
<Guest86434> alkisg, same problem http://pastebin.com/m461fe7dd
<Guest86434> making nautilus but this errot message, http://pastebin.com/m461fe7dd , i don't know what remain to od
<etuken> hello, I found bug in Alpha2 installer but don't know how to file bug for it
<persia> toruk: We generally discuss bug management in #ubuntu-bugs.  https://help.ubuntu.com/community/ReportingBugs is the documentation on filing bugs.
<lfaraone> Uh, I just realized a package I had gotten sponsored to proposed A) doesn't fix the problem, because I forgot to include simple-patchsys in rules, and B) the patch I created would cause a syntax error on execution.
<lfaraone> When I upload a debdiff to lp that fixes this, should I bump the 0.x rev number, and should I debdiff against the one in karmic or the one in -proposed?
<persia> lfaraone: See -motu
<lfaraone> persia: mk.
<pitti> RainCT: ergh, terribly sorry; I'll fix it up now
<RainCT> pitti: not a big deal :)
<pitti> RainCT: branch fixed, uploaded; thanks for pointing out
<pitti> apw: yes, it does; see http://macaroni.ubuntu.com/~pitti/workitems/canonical-kernel-team.html
<pitti> asac: it's not picker about syntax, but about assignment and team membership
 * persia idly wonders if we ought make `dch -i`have special handling when the target of the previous changelog entry is "UNRELEASED"
<pitti> slangasek: I regenerated all old alpha-2 reports
<pitti> slangasek: about https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-ubuntu-one-symlinks-and-udfs -> that's an OLS spec, it's on http://macaroni.ubuntu.com/~pitti/workitems/ubuntuone-hackers.html
<tweakt> I'm trying to preseed the user creation but with a locked password, and I'm going to automatically install an authorized_keys file for access.
<tweakt> tried "d-i passwd/user-password-crypted password !"
<tweakt> but still prompting
<slangasek> pitti: yes, it's an UbuntuOne spec, but who's responsible for ensuring it's on track for Lucid?  UbuntuOne is an "upstream" team, isn't it?
<slangasek> pitti: regenerated>  thanks!
<sroecker> hi, is there a way to compile the i915 module with only kernel headers?
<siretart> superm1: ffmpeg that build depends on libvdpau uploaded to lucid
<crimsun> slangasek: / cjwatson: do I need an MIR bug report to promote libsdl1.2debian-pulseaudio to main?
<c_korn> what do I have to do to get a package (scilab 5.2.0-1) synced from experimental ?
<geser> file a sync request as usual but also state why it should be synced from experimental
<c_korn> geser: ok, I think I am expected to have tested it. so I first build it in a PPA and test it in the current lucid version.
<geser> yes
<c_korn> geser: ok, thanks.
<neXyon> hi there
<neXyon> crimsun: are you there?
<mkaduk> Hi, how to remove pulseshitaudio without losing volume control applet ?
<mkaduk> Is there a way not to use this buggy software?
<mkaduk> why its forced in distribution ?
<jbicha> mkaduk: try using KDE, but seriously, ask support questions in #ubuntu
<mkaduk> I hope someone wise will remove it soon from Ubuntu official releases
<mkaduk> jbicha, the problem is that when I remove pulseaudio I get no volume control applet
<mkaduk> so its more Ubuntu development releated problem. Why this is forced to use PA, most people dont want it, cause its not working
<jbicha> mkaduk: PulseAudio is the standard for Linux audio these days, at least with GNOME, if you're having sound problems, #ubuntu is really a more appropriate chatroom than here
<neXyon> urgh, pulse sucks
<neXyon> xD
<mkaduk> neXyon, I agree, most of software does not work correctly because of it, is that standard now these days to have not working audio in gnome?
<Hellow> It's a matter of personal opinion.
<neXyon> Hellow: sure, but the default should be pulse OFF as it suits the needs for MOST if not all users
<Hellow> That would break a lot of applications included in the Ubuntu distribution.
<neXyon> one example that might be interesting to read: http://audaspace.wordpress.com/2010/01/08/the-pulseaudio-pain/
<mkaduk> neXyon, is common topic
<mkaduk> Hellow, 99.999% applications are not pure Pulseaudio apps and can use alsa. The problem is that Ubuntu removes volume control from gnome packages so you're forced to use PA if you want that
<mkaduk> and most of people dont want not working software, which is PA in this case. Even with external sound card it does not work properly I have Sound Blaster X-Fi and it has problems selecting device all the time. I blacklisted integrated sound module and removed PA, works fine.
<neXyon> yeah
<neXyon> alsa can do everything I want
<mkaduk> moreover Skype, Empathy does not work properly with it and you need "Perfect Setup" entire website with walkarounds how to make things like flash etc.. working
<neXyon> I even have sound working over hdmi to my TV and I configured alsa to play to my TV as well as to my subwoofer connected to the PC, when watching movies :D
<mkaduk> neXyon, I am guessing even package maintainer is not using it
<mkaduk> neXyon, anyway lets move discussion to #ubuntu
<neXyon> I wonder if ubuntu devs update the openal version to 1.11 on all affected ubuntu versions when it's out
<neXyon> what will be today...
<neXyon> can I somehow check the patches that are applied to a specific ubuntu package when being compiled?
<geser> sure, grab the source package and look at the included patches or look at the .diff.gz for directly applied changes (not every package uses patches)
<Tm_T> or
<Tm_T> neXyon: for example, http://packages.ubuntu.com/source/karmic/qt4-x11
<Tm_T> neXyon: in far right there's links to debian source repository, which contains packaging information and patches
<hspaans> g'day all
<hspaans> is there someone here with an IBM or Lenovo laptop?
<trewq> http://www.pandamailer.de/?bettel=pimbolli
 * YokoZar is logged in from Microsoft's guest network
#ubuntu-devel 2010-01-17
<YokoZar> why is traceroute not installed by default but traceroute6 is?
<persia> My memory is that traceroute went away because it started requiring root.
<persia> Should traceroute6 go away?
<ScottK> I think there's another one.  Tracepath or something
 * maco uses mtr
<persia> Indeed.  tracepath is provided by default.
<lamont> mtr is love
<maco> (which, yes, i think is installed by default)
<persia> maco: Only mtr-tiny is installed by default.
<maco> persia: good enough :)
<lamont> persia: that's good enough for most uses
<lamont> really don't need the gtk version... :-)
<YokoZar> Should we worry that System->Network tools has a table called "traceroute" when it's running (presumably) tracepath?
<maco> ooh wait are you saying i can stop typing -t since i didnt go and install the not-iny version?
<persia> YokoZar: If you want to investigate further, look into the iputils-tracepath package: perhaps traceroute6 shouldn't be there?
<persia> maco: I'm just documenting my memory of the seeds.  How that affects your keyboard input is up to you :)
<maco> heh
<persia> YokoZar: Can you think of a good generic term for the operation?  If so, you could probably make an argument for the change based on HIG.
<YokoZar> persia: Well traceroute is what most people are familiar with (windows users too).  tracepath isn't discoverable precisely because it's renamed.
<persia> If you feel "traceroute" is a good generic term, then the GNOME Network Tools thing probably shouldn't change.
<persia> You could investigate the differences between tracepath6 and traceroute6, and see if you could create an equivalent traceroute to go with tracepath.
<ScottK> There was a reason we preferred tracepath over traceroute.  I don't recall what it was.
<ScottK> Sounds like a potential job for command-not-found.
<lamont> ScottK: better faster harder stronger, obviously
<anon^_^> is there an appropriate channel to ask about backport consideration?
<ScottK> I think it was actually smaller, but I don't recall.
<persia> ScottK: The issue is that command-not-found would recommend installing 'traceroute'
<persia> Rather than recommending the use of tracepath
<ScottK> persia: command-not-found can do multiple things.  It could do both.
<persia> That would need an improvement.  Current behaviour is to recommend installation of traceroute or traceroute-nanog
<ScottK> Right.  Didn't say it was doing the job today, just that it perhaps should.  Then YokoZar's Windows using friends would find out about tracepath when they tried traceroute.
<anon^_^> um hello?
<anon^_^> lol
<persia> Hrm.  Good point.
<ScottK> anon^_^: This is probably as good a channel as any.  #ubuntu-motu might be slightly better.
<anon^_^> Scottk, I was wondering about kernel 2.6.32 and if there was any possibility of it being backported for Karmic
<anon^_^> Karmic has some pretty bad I/O issues which starve desktop responsiveness
<YokoZar> anon^_^: it won't be
<ScottK> Kernel backports aren't done through offiicial backports.  There's just linux-backports-modules (or similar)
<YokoZar> anon^_^: We do have some plans to allow backported kernels in Lucid though, IIRC
<persia> The issue with backported kernels is that often all sorts of odd bits break in unexpected ways.
<YokoZar> Right, it needs lots of testing and so forth.  But without backporting kernels we had no way of enabling newer hardware updates.  So this is a problem, especially for LTS.  At least that was my memory of the discussion,
<persia> Especially with stuff that requires kernelspace-userspace integration, like alsa, firewire, bluetooth, udev, etc.
<anon^_^> Yeah, that's why I was hesitant to add pre-compiled 2.6.32 deb from http://kernel.ubuntu.com/~kernel-ppa/mainline/
<anon^_^> to Karmic
<persia> Well, if the interfaces haven't changed, one could just backport individual drivers, but that's lots more work.
<YokoZar> and interfaces change all the time
<persia> Yep, which is why it's just painful either way.
<spowers> speaking of kernels, is there a minimum kernel required for booting lucid? i just tried a upgrade from jaunty to lucid in a Xen environment and ran into some problems with mountall and think it might have something to do with me running linux-image-2.6.24-24-xen
<persia> Personally, I find it less painful to port a driver than to rebuild large dependency stacks, but then again, I'm not really a kernel person.
<spowers> i think my issues are a good example of how userspace stuff gets tied up with kernel versions
<lamont> spowers: I had serious issues running karmic on a jaunty kernel.. I expect lucid is at least karmic for a kernel base
<persia> spowers: Indeed.  We know lucid boots with 2.6.31, but I'm not sure anything less than that has had significant testing.
<lamont> though non-X stuff might work as far back as dapper even
<persia> lamont: Nope.  Something changed with udev polling recently (.29 or .30, I think)
<lamont> I upgraded a server from dapper to karmic without rebooting and without problems (other than that karmic didn't solve the issue I was having either, so it went back to dapper)
<persia> heh.  "without rebooting" gives more flexibility :)
<spowers> yeah, things were good until i rebooted
<lamont> and trying to find what was wrong with a jaunty kernel on an i386 machine running karmic userspace was sufficiently fail that I installd a jaunty alternate-root and did the bisect there
 * anon^_^ thanks chan for answers
<crimsun> ok, seed change for libsdl1.2debian-foo covered (ubuntu, edubuntu, kubuntu, xubuntu, mythbuntu -- the latter two need explicit bzr merges)
<ScottK> persia: Currently it appears that command-not-found lists traceroute as an alternative for tracepath, but not the reverse.
<LLStarks> hi. i found a crash bug for synaptic. easy to replicate.
<persia> ScottK: heh.  That's probably backwards.
<ScottK> YokoZar: ^^^^ please fix to make your Windows friends happy.
<ScottK> LLStarks: File a bug on Launchpad then.  Preferably using apport to provide a backtrace.
<LLStarks> ubuntu-bug no good?
<ScottK> No.  It doesn't have the backtrace.
<ScottK> It's better than nothing if you can't manage apport
<LLStarks> apport-bug is fine
<LLStarks> i'll fike
<LLStarks> *file
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/508603
<ubottu> Ubuntu bug 508603 in synaptic "Sorting by the unnamed Ubuntu logo column between "S" and "Package" makes Synaptic unresponsive" [Undecided,New]
<LLStarks> how do i collect the backtrace?
<LLStarks> apport screwed up
<persia> For "becomes unresponsive", it's decidedly difficult to obtain a backtrace.
<persia> We usually differentiate "hang" (where an application stops responding), from "crash" (where an application ceases execution and drops from the process list)
<LLStarks> i purposefully didn't use crash
<LLStarks> wait. i did.
<persia> In the bug, you didn't.  In your first message to the channel ("i found a crash bug for synaptic. easy to replicate.") you did.  That's why a backtrace was requested.
<LLStarks> want me to gdb?
<persia> If you know gdb, and can identify the problem, please add info to the bug.
<persia> If you need help using gdb to identify the problem, ask in #ubuntu-bugs
<LLStarks> you read my mind.
<LLStarks> just for the record, ubuntu-devel maintains synaptic, right?
<persia> Well, sure, but that's also true for every package in Ubuntu in some sense.
<persia> synaptic gets more maintenance than some other stuff though.
<YokoZar> Anyone else notice no non-default menu items showing up in lucid?
<slangasek> crimsun: no, MIRs are for source packages
<maco> sladen: ping? could use your help in #kubuntu
<YokoZar> ScottK: https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/508606
<ubottu> Ubuntu bug 508606 in command-not-found "Recommend tracepath for "traceroute" and "tracert"" [Undecided,New]
<LLStarks> persia, stupid question, but how did my nautilus tabs move to the bottom of the window?
<LLStarks> i can't figure out how to get them back on top
<persia> LLStarks: 1) why me?  2) I don't know, and 3) #ubuntu is a better channel for support (or #ubuntu+1 because you're running lucid)
<LLStarks> ah ok
<LLStarks> sorry
<Laney> LLStarks: It was an upstream decision.
<c_korn> can someone help me analyzing the scilab 5.2.0-1 build for amd64 ? it fails but the error log says "Built successfully" https://launchpad.net/~getdeb-package-managers/+archive/ppa/+build/1448702
<persia> c_korn: http://wiki.debian.org/ImplicitPointerConversions
<persia> (extracted from the very bottom of the build log)
<c_korn> persia: oh, thanks. didn't see it.
<wolter> hi, can somebody tell me which is the package that contains the notify-osd actions for volume control?
<wolter> I reinstalled gnome-media and gnome-applets and now i have the old osd for volume control
<wolter> anyway, whoever has an answer for me please leave it to me with memoserv [ /msg memoserv send wolter <your message here> ]
<asac> pitti: really? ... http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
<asac> now it looks good
<asac> not sure if you fixed something ... only thing i did was cleaning up all the Work items labels
<kitallis> is notifyOSD a separate project or does it _depend_ on libnotify?
<ScottK> separate project.
<kitallis> ScottK: how does this little piece of code use libnotify to send the 'new' OSD notifs http://ubublogger.wordpress.com/2009/04/04/using-ubuntu-jauntys-new-notification-system-notify-osd/ then?
<ScottK> I'm guessing it talks to it over dbus.  They use a compatible protocol on the wire.
<kitallis> hm
<dtchen2> is it possible to boot without activating plymouth (in lucid)? I can't diagnose why cryptsetup is failing if I can't see it :-)
<hyperair> nosplash doesnt work?
<dtchen2> no
<hyperair> that sounds troubling
<dtchen2> the problem is that regardless what boot parameters I pass, the modeswitch always occurs
<bigon> is there a way to see the upload permission a user has on the LP?
<geser> yes, through the LP API
<geser> try edit_acl.py from lp:ubuntu-archive-tools
<_Groo_> hi/2 all
<_Groo_> siretart: ping!
<_Groo_> siretart: latest libdirac breaks gstreamer bad plugins.. can you take a look at it when you have the time?
<siretart> dirac hasn't been uploaded since quite some time
<siretart> I've done a no-change upload of gst-plugins-bad to rebuild it against the new dirac, though
<siretart> _Groo_: perhaps you could try to catch slomo on this?
<_Groo_> siretart: dirac was updated a few days ago, the new name convention breaks some package, gstreamer included
<siretart> _Groo_: Published on 2010-01-04
<siretart> that's 13 days ago
<_Groo_> The following packages are BROKEN:
<_Groo_>   gstreamer0.10-plugins-bad  mencoder  mencoder-mt  mplayer  mplayer-mt
<_Groo_> The following NEW packages will be installed:
<_Groo_>   libdirac-encoder0{a} [1.0.2-2]
<_Groo_> The following packages will be REMOVED:
<_Groo_>   libdirac0c2a{a} [1.0.2-0ubuntu1]
<_Groo_> exactly
<ion> Please
<_Groo_> but went live today
<_Groo_> ion: i know... use paste.bin.. but for 4 lines i think is overkill
<siretart> it's not
<_Groo_> siretart: ok, noticed
<siretart> anyway, mplayer needs to be rebuilt anyway as soon as libvdpau is promoted, so that ffmpeg can be built
<_Groo_> mencoder and mplayer are my own packages, no prob there...
<siretart> oh, I see
<_Groo_> siretart: ffmpeg was updated today also
<siretart> ffmpeg-extra was
<_Groo_> exatcly
<siretart> ffmpeg is still waiting for libvdpau
<_Groo_> are you guys gonna add mplayer-mt to lucid?
<_Groo_> and mencoder-mt? since they can live side by side it would be great
<_Groo_> ffmpeg-mt is a ver nice project too
<siretart> in a ppa perhaps. are you volunteering to help out here?
<_Groo_> siretart: sure why not, i do packages for kubuntu anyway
<siretart> ok
<_Groo_> and getdeb :P
<_Groo_> and debian :D
<siretart> do you read the upstream mailing list?
<_Groo_> siretart: nope, i usually send them to revu and bug the hell out of ScottK and Richie
<_Groo_> Riddell sorry not Richie
<Laney> ffmpeg-extra FTBFS :(
<siretart> _Groo_: okay, well in short: upstream now includes symbol versioning since yesterday which is enabled by default if the linker supports it
<Laney> oh no, that was the other one
<Laney> gst-bad
<siretart> _Groo_: this finally allows us to safely update ffmpeg without breaking unrelated applications
<siretart> _Groo_: however I'm pretty sure that with this patch included, mplayer does no longer build against a shared build of libswscale
<siretart> groo_: can you confirm/deny that?
<siretart> Laney: sorry? please elaborate
<Laney> siretart: the gst-plugins-bad0.10 rebuild FTBFS
<Laney> https://launchpad.net/ubuntu/+source/gst-plugins-bad0.10/0.10.17-1ubuntu2
<groo_> siretart: mplayer using latest svn?
<siretart> groo_: post svn r30315
<groo_> siretart: will have to build and see, also im gonna do the mplayer/mencoder-mt in parallel... they work very well with smplayer for ex :)
<groo_> siretart: but it will take me a week or so... since i dont have much time during the week... it depends how my work is :)
<siretart> Laney: bad sdl or gst. needs more investigation, I'd say
 * Laney nods
<sebner> Laney: uhh, nearly removed all the lib stuff that depends on -bad :)
<Laney> hmm?
<sebner> Laney: dist-upgrades updates -bad and then wants to remove all the libs that break because of new -bad
<Laney> bad is bad!
<sebner> better than ugly ?! ^^
<siretart> groo_: actually, my plan was first to do ffmpeg-snapshot and mplayer-snapshot packages, both tracking trunk, and maybe setup some buildbot for them
<groo_> like i said, gstreamer bad plugins is broken since latest libdirac upgrade... changed the package name.. so when you try to dist-upgrade apt tries to remove bad plugins and all apps with it
<groo_> siretart: want to contact me by mail? i might be able to help.. and ive been doing mplayer/ffmpeg own packages for years :D
<siretart> groo_: no, the problem is that gstreamer-bad fails to build from source, if it wouldn't we'd already have fixed packages
<Laney> yes this happens in the life of a development release
<groo_> Laney: true :)
<groo_> siretart: with same source or newer one?
<siretart> groo_: feel free to join the pkg-multimedia list on alioth
<siretart> groo_: see Laney's last link in this channel
<groo_> siretart: i will see if i find the time :)
<RiotingPacifist> are there any problems with launchpad? https://launchpad.net/ubuntu/+search?text=kdm won't load for me today
<ScottK> RiotingPacifist: #launchpad
<bigon> is it possible to know for which pkg I have upload rights?
<geser> try asking LP (through the LP API, e.g. with edit_acl.py) or as last resort: upload and see it if succeeds or not
<bigon> geser: ok :)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/508930 => enough info in bugreport ?
<ubottu> Ubuntu bug 508930 in samba "CIFS mount is offline every x minutes/seconds" [Undecided,New]
<dupondje> added wireshark dump
#ubuntu-devel 2011-01-10
<awesome_guest> well that was annoying.. it seems that libfuse-dev is 2 years out of date
<awesome_guest> how would I go about correcting that?
<awesome_guest> i.e. get them to upgrade from 2.7.4 to 2.8.5
<diwic> awesome_guest, first thing is to file a launchpad bug for it
<Hydrant> hey all... do all projects on launchpad have a mailing list automatically ?
<Hydrant> I want to email a particular project on launchpad, but the interface is a bit confusing on how to begin to participate in a project
<Amaranth> Hydrant: That's a great question for #launchpad (I have no idea)
<Hydrant> Amaranth: thx
<highvoltage> thanks to the archive admins who worked today :)
<JackyAlcine> o//
 * JackyAlcine is pushing a mailing list update to SpeechControl regarding openMary.
 * JackyAlcine has sent a message to SpeechControl's developers. Please check your email.
<AnAnt> Hello, I just tried alpha1, so with unity,  apps that use notification area won't show up ?
<AnAnt> hmmm, sorry, wrong channel
<\sh> moins and happy new year everyone :)
<sladen> \sh: hallo Stephan
<tkamppeter> pitti, hi
<tkamppeter> Anyone around who works on MIRs?
<bmm> I'm making a small maven3 package (dirty for personal use, but published in PPA) and I ran into a conf/settings.xml file which is executable. Lintian tells me to use dh_fixperms, but I already use cdbs. How do I get dh_fixperms to remove the executable flag?
<akheron> bmm: grep the cdbs source to see if there's a flag to enable dh_fixperms or give options to it
<akheron> that's what I do if I have to use cdbs :)
<bmm> akheron: k, will do
<akheron> bmm: I see this line in debhelper.mk: dh_fixperms -p$(cdbs_curpkg) $(call cdbs_add_dashx,$(DEB_FIXPERMS_EXCLUDE)) $(DEB_DH_FIXPERMS_ARGS)
<akheron> so setting DEBDH_FIXPERMS_ARGS might do the trick
<akheron> DEB_DH_... that is
<bmm> akheron: I read that, but it seem to only allow exclusion, not inclusion... and debhelper.mk should already run dh_fixperms on my files.
<bmm> I also read /usr/bin/dh_fixperms but I could not read any trace of a possible "package.fixperms" file to be allowed :(
<bmm> Oh, and my debuild output shows that dh_fixperms is being run (dh_fixperms -pmaven3)
<bmm> Is it possible to quilt patch file attributes?
<bmm> (as it's only a dirty package for myself and my PPA)
<bmm> akheron: ooh, I just realize what you said: add the file as an argument to dh_fixperms... stupid, going to try that now..
<akheron> yep :)
<bmm> akheron: bad luck, it silently ignores the arguments. Tried conf/settings.xml, usr/share/maven3/conf/settings.xml and finally something stupid, output shows:  dh_fixperms -pmaven3  THIS_DOES_NOTHING
<bmm> and has no effect :(
<bmm> I'm going to post the same question in #debian ...
<akheron> Yeah, according to the man page it doesn't take files as arguments
<bmm> akheron: I'm going to try a quilt patch, just for the fun of it. Maybe people over at #debian will find a response in the meantime
<bmm> Quilt won't patch file attributes :(
<akheron> no
<akheron> can't you just chmod after install?
<bmm> akheron: Ooh, could do that... have to add something to my very clean debian/rules though. I'll check...
<bmm> akheron: Thanks you. I added binary-post-install/maven3:: with a chmod a-x debian/maven3/usr/share/maven3/conf/settings.xml and now lintian is much happier!
<akheron> np :)
<akheron> then to the fundamental question: why cdbs?
<akheron> I find pure debhelper 7 and above much better
<bmm> akheron: never really thought about it :) My debian/rules is very simple so I'm a happy hacker ;) http://pastebin.com/i7ZyybMu
<akheron> with debhelper that would be just http://pastebin.com/6JM20789
<akheron> plus the override for chmod :)
<bmm> akheron: seems ok. I'll read up on it the next time I create a package, thanks for the tip.
<Keybuk> what timezone is Dallas in?
<\sh> Keybuk: Monday, 10. January 2011, 08:30:26 CST
<\sh> UTC/GMT -6 hours
<Keybuk> \sh: what value of $TZ is that?
<\sh> Keybuk: US/Central ?
<\sh> dunno
<Keybuk> ah cool, that works
<geser> that's the place where everybody is? that explains why it's so quiet here
<Keybuk> geser: yup
<\sh> Keybuk: btw..thanks for the upstart blog...the howtos and explanations are very useful and welcomed here :)
<Keybuk> glad someone appreciates it :p
<Keybuk> I'm hoping that if I can get enough stuff like that down, it will inspire someone to collect it together in a documentation form
<ari-tczew> cjwatson: is merge elilo on your crosshair? it includes new upstream release
<ari-tczew> (universe)
<dholbach> good morning
<Keybuk> dholbach: afternoon
<highvoltage> dholbach: morning? aren't you in europe atm?
<dholbach> highvoltage, Dallas
<tseliot> not in the US ;)
<tseliot> it's morning there
<highvoltage> dholbach: btw, thanks for updating that Zope wiki page, I was about to do it and noticed you beat me to it :)
<dholbach> highvoltage, it was Gediminas
<highvoltage> ah, great
<Keybuk> I expect they're all in a plenary right now
<bdrung> dholbach: can you merge the proposed branches at https://code.launchpad.net/~ubuntu-dev/ubuntu-sponsoring/trunk/+activereviews ?
<dholbach> bdrung, I'm sprinting - I'll try to have a look later on
<bdrung> dholbach: i reviewed them and found them good. the overview will look like this then: http://people.ubuntu.com/~bdrung/sponsoring/
<dholbach> bdrung, did you merge them? I just need to pull them on qa.u.c
<bdrung> dholbach: locally. you are the owner of lp:ubuntu-sponsoring
<dholbach> bdrung, not any more
<bdrung> ok, then i'll merge it
<dholbach> thanks bdrung
<ScottK> doko: FYI, I test built libreoffice on powerpc over the weekend and it build (unlike our current OOo package).
<doko> ScottK: yes, I know that it does build
<ScottK> doko: OK.  Didn't know you'd already tried it.
<nigelb> Anyone want to take the topic of 'ways to contribute to debian' for the packaging training this week?
<geser> mvo: when you've some time for sponsoring, can you look at https://code.launchpad.net/~geser/ubuntu/natty/python-apt/build-with-py3.2/+merge/45604 ? thanks.
<mvo> geser: sure, let me have a look
<mvo> geser: thanks, indeed, that looks fine
<nigelb> bdrung: hey, poke?
<bdrung> hi nigelb
<nigelb> bdrung: hey, want to talk about contributing to debian this thursday?
<nigelb> packaging training...
<bdrung> nigelb: Thursdays are not the best weekday
<nigelb> bdrung: ouch
<nigelb> bdrung: what day/date is convinient for you?
<tkamppeter> Anyone around who could look at a MIR?
<bdrung> nigelb: depends on the time of day.
<nigelb> bdrung: your choice :)
<nigelb> bdrung: wait
<nigelb> bdrung: dholbach said in mail 12:00 UTC
<pitti> tkamppeter: hello! I'm not in the MIR team any more
<bdrung> nigelb: at 12:00 utc, i am usually in university
<bdrung> nigelb: what kind of talk is it?
<nigelb> bdrung: actually, the door is open for any kind
<nigelb> bdrung: I thought since you recently became a DD, a talk about contributing to debian would be nice
<bdrung> nigelb: rephrasing my question: to what does this talk belong / why a talk?
<nigelb> bdrung: Packaging Training Session
<nigelb> this was one of the requested topics
 * JackyAlcine is up and about; and missed school. O.O
<tkamppeter> pitti, who is in the MIR team? I have reported a MIR (bug 691533) and no one has looked at it. It blocks the upload of Ghostscript 9.01.
<ubottu> Launchpad bug 691533 in jbig2dec (Ubuntu) "[MIR] jbig2dec" [Undecided,New] https://launchpad.net/bugs/691533
<bdrung> nigelb: maybe an other time, but not this week.
<pitti> tkamppeter: https://launchpad.net/~ubuntu-mir/+members
<nigelb> bdrung: sure :)
<ev> pitti: what's the state of pygi in natty?  Should I be trying to make your or dmitrij.ledkov's usb-creator branch work?  The gtk-2.0 bindings seem to be a bit broken.
<ev> err rather, what are the plans for pygi in natty
<tkamppeter> pitti, thanks.
<tkamppeter> doko, asac, kees, can someone of you have a look at bug 691533? It blocks the build of Ghostscript 9.01.
<ubottu> Launchpad bug 691533 in jbig2dec (Ubuntu) "[MIR] jbig2dec" [Undecided,New] https://launchpad.net/bugs/691533
<SpamapS> anybody know how to get natty to use a different default browser than firefox? 
<elif> cjwatson: hi, some days ago you helped me answering that wasn't possible with Preseed to install Ubuntu without partitioning the disk, i.e, install Ubuntu in a previously created (possibly formatted) partition. If want to change this behaviour what would be better place to go ? change partman ? change debian-installer ? Thanks in advance.
<doko> tkamppeter: please can you fix the splix build?
<\sh> micahg: could you do the zf 1.11.2 backports? :) and happy new year, my friend
<micahg> \sh: sure, I'll try to get to it later tonight
<\sh> micahg: thx a lot :)
<cjwatson> ari-tczew: I have a merge in progress - I'll try to get around to finishing it
<cjwatson> ari-tczew: but if you want to take it, I really don't care much.  Just be careful, some of the changes are quite subtle
<cjwatson> elif: partman, but it's really hard.
<tkamppeter> doko, kees, I have uploaded jbig2dec with symbols now.
<kees> tkamppeter: excellent, thanks
<pitti> ev: it's getting better every day; yesterday and today I did a ton of GTK2 patches to fix annotations
<pitti> ev: so maybe try with the gtk2 gir from yesterday?
<ev> from git?
<pitti> ev: I have a pygi branch of u-c myself
<pitti> ev: but I got stuck on the threads locking up
<pitti> the actual UI seemed to work just fine
<pitti> ev: in natt
<ev> hmm, okay
<pitti> ev: I did more fixes in git for language-selector
<pitti> ev: and I just backported a massive fix which enables several dozen functions
<ev> I was trying with dmitrij's branch and I ran into this: http://paste.ubuntu.com/552535/
<ev> with presumably today's gir from natty
<ev> as I'm up to date as of the plenaries
<pitti> weird, it's in the GIR
<pitti> but yes, I can replicate it here
<pitti> ev: in my branch I don't even have a *drawable* match, so that's why I didn't run into it
<ev> ah :)
<Keybuk> When laptop lid is closed: Blank screen ?!?!
<Keybuk> WTF happened to DO NOTHING you option-removing gnome cocks!
<Keybuk> </mjg59 moment>
<pitti> ev: since it's not even working for gtk3, would you mind filing an upstream bug and CC me? I'll try to get it fixed ASAP, but I need an upstream bug for the signoff
<ev> will do
<pitti> ev: I'll be on the GNOME GI hackfest next week; excellent fodder :)
<ev> heh
<bigon> is there something wrong with libusb on natty?
<bigon> http://pastebin.com/SSP1mSxn
<ari-tczew> bigon: looks like missing header
<kklimonda> bigon: there is nothing wrong with libusb, but there were changes to the natty toolchain - you have to pass lib reference after source files
<htorque> kklimonda, just tried it - works fine. :)
<bigon> kklimonda: just discovered that
<bigon> let's fix my package
<ev> pitti: https://bugzilla.gnome.org/show_bug.cgi?id=639173
<pitti> ev: thanks, putting on my radar now
<ev> thank you
<pitti> ev: ah, so you aren't actually using the Drawable yourself
<ev> well, that was just an example
<pitti> Keybuk, slangasek, cjwatson: it seems that plymouth writes boot messages to vt7 in natty now? nessita's machine consistently crashes X at first boot because X gets a SIGQUIT on pressing enter
<pitti> did anything change in that regard in natty?
<pitti> it's the bug we worked around in lucid by forcing X to start on vt7, but apparently that stopped working
<pitti> .. any more
<cjwatson> pitti: the only relevant change I can think of is that we pass vt.handoff=7
<cjwatson> (kernel parameter)
<slangasek> pitti: well, the plymouth code didn't change here AFAIK...
<pitti> cjwatson: would that have worked with the maverick kernel? (she is currently running that)
<cjwatson> pitti: I don't know what it would have done with the maverick kernel; it certainly wouldn't work *properly*
<Keybuk> jdstrand: you rebuild the xf86-input-multitouch driver with use_tapping 0 right?
<jdstrand> Keybuk: in my ppa? yeah
<jdstrand> Keybuk: * memory.c: set #define use_tapping 0
<Keybuk> jdstrand: yeah, I've done that
<Keybuk> and weirdly it's making no difference
<Keybuk> if I lightly tap the panel, it still "clicks"
<jdstrand> Keybuk: maybe the multitouch driver didn't get loaded?
<Keybuk> jdstrand: can I sneak a peak at your Xorg.0.log to compare?
<jdstrand> Keybuk: I had to adjust the event thing
<Keybuk> I had to do odd stuff to make it bind
<Keybuk> (and xorg.conf)
<Keybuk> Section "InputClass"
<Keybuk>     MatchIsTouchpad "true"
<Keybuk>     Identifier "Multitouch Touchpad"
<Keybuk>     Driver "multitouch"
<Keybuk>     MatchDevicePath "/dev/input/event*"
<jdstrand> Keybuk: it isn't my system, but I did log my change, hold on
<jdstrand> Keybuk: yes, that is what I have
<jdstrand> Keybuk: do you have the bcm5974-dkms package installed? (and that driver loaded-- a reboot would do it, but you can also rmmod and modprobe the driver, I forget the name otoh)
<Keybuk> [ 26230.870] (II) config/udev: Adding input device bcm5974 (/dev/input/event7)
<Keybuk> [ 26230.870] (**) bcm5974: Applying InputClass "evdev touchpad catchall"
<Keybuk> [ 26230.870] (**) bcm5974: Applying InputClass "touchpad catchall"
<Keybuk> [ 26230.871] (**) bcm5974: Applying InputClass "Multitouch Touchpad"
<Keybuk> [ 26230.871] (II) LoadModule: "multitouch"
<Keybuk> etc.
<Keybuk> so that seems to be loading
<Keybuk> and
<Keybuk> [ 26231.073] (II) config/udev: Adding input device bcm5974 (/dev/input/mouse1)
<Keybuk> [ 26231.073] (II) No input driver/identifier specified (ignoring)
<Keybuk> and that seems to be Not loading
<jdstrand> hmm
<jdstrand> Keybuk: unfortunately, the person whose laptop I set this up on is offline (and will be this whole week)
<Keybuk> ah, np
<Keybuk> if you get a chance though, I'd love to compare
<Keybuk> because I remember this working much better than it is now
<jdstrand> Keybuk: I can say I recall the synaptics driver wanting to take over if I didn't put that InputClass in xorg.conf
<Keybuk> even click with one finger, drag with the other, isn't work
<Keybuk> +ing
<Keybuk> yeah, I'm sure synaptics isn't being loaded
<jdstrand> Keybuk: yeah, it all works great for her on lucid
<bdrung> smb: can you mark https://code.launchpad.net/~stefan-bader-canonical/ubuntu/natty/e2fsprogs/branch/+merge/43541 as rejected (because it still appears on the sponsors overview)?
<Keybuk> deathspank scott% xinput list
<Keybuk> â¡ Virtual core pointer                    	id=2	[master pointer  (3)]
<Keybuk> â   â³ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
<Keybuk> â   â³ bcm5974                                 	id=10	[slave  pointer  (2)]
<jdstrand> Keybuk: I've not tried maverick or later
<jdstrand> Keybuk: I mention synaptics cause there is a lot of configuration of that in /etc/{lib,share}/x11/xorg.d/
<jdstrand> Keybuk: but, you would clearly see it in the Xorg.0.log
<Keybuk> did you do anything with the fdi file?
<jdstrand> Keybuk: as for the module not loading, that is odd. I didn't have that problem, but made a note to grab her dmesg and Xorg.0.log when she is online
<jdstrand> Keybuk: no. nothing with fdi
<Keybuk> that's the weird thing
<Keybuk> I'm pretty sure the module is loading
<Keybuk> and is being used
<Keybuk> but it's not providing any different functionality
<jdstrand> strange
<smb> bdrung, Hm, status seems only to offer me the options of merged, work in progress or needs review. Which seems not to be helpful
<jdstrand> Keybuk: sorry I couldn't be more help :( (but will get the info when I can)
<Keybuk> that's ok :)
<Keybuk> thanks
<jdstrand> sure
<tkamppeter> In bug #701218 the reporter is adding the "print-server" task. What is that and how does one do that?
<ubottu> Launchpad bug 701218 in foomatic-db (Ubuntu) "openprinting-ppds : Conflicts: openprinting-ppds-extra" [Undecided,Incomplete] https://launchpad.net/bugs/701218
<bdrung> smb: i have these three options too. there used to be a 'rejected' status
<smb> bdrung, I try to grab someone to get it resolved
<bdrung> thanks
<Keybuk> jdstrand: aha! figured it out
<jdstrand> Keybuk: oh!? what was it?
<Keybuk> they changed the output path of the object when you type "make"
<Keybuk> so the one I was using was ... old
<Keybuk> cp obj/multitouch.so ...
<Keybuk> rather than
<Keybuk> cp multitouch.so ...
<Keybuk> fixed it :p
<cjwatson> tkamppeter: tasksel install print-server
<cjwatson> (tasksel --test ..., in case you just want to see what it'll do)
<cjwatson> it comes from the print-server seed
<cjwatson> so in fact, 'sudo apt-get --dry-run -q -y install print-server^'
<jdstrand> Keybuk: ah! cool :)
<tkamppeter> cjwatson, thanks. So if the print-server task contains an obsolete package, against which package I have to report the bug?
<tkamppeter> kees, doko, can someone of you complete the MIR bug #691533? Thanks.
<ubottu> Launchpad bug 691533 in jbig2dec (Ubuntu) "[MIR] jbig2dec" [Undecided,New] https://launchpad.net/bugs/691533
<doko> tkamppeter: sure. can you fix the splix build failure?
<tkamppeter> doko, does this cause a build failure of SpliX?
<tkamppeter> doko, I did not get any notification, thanks for telling me.
<doko> tkamppeter: did you see my email on ubuntu-devel?
<tkamppeter> doko, I am searching for it now, found it. A global test rebuild for Natty. Did not find the time yet to look into it.
<tkamppeter> doko, found it, from my packages it is splix which failed.
<Keybuk> ugh
<Keybuk> colorized
<Keybuk> two opportunities to misspell that one
#ubuntu-devel 2011-01-11
<pitti> StevenK: halp! still online?
<StevenK> pitti: What's up?
<StevenK> pitti: I'm in Presidente if you want to chat face-to-face.
<pitti> StevenK: I published karmic-proposed's linux-ec2 to -updates and -security a while ago, and that worked on cocoplum
<pitti>  linux-ec2 | 2.6.31-307.23 | karmic-proposed | source
<pitti>  linux-ec2 | 2.6.31-307.23 | karmic-updates | source
<pitti> StevenK: but it seems that never actually made it to archive.u.c.
<pitti> rmadison:
<pitti>  linux-ec2 | 2.6.31-307.22 | karmic-updates | source
<pitti>  linux-ec2 | 2.6.31-307.23 | karmic-proposed | source
<StevenK> rmadion lags behind the archive by roughly 6 hours
<kees> pitti: what's up?
<kees> pitti: we just did the linux-ec2 publication
<StevenK> Use madison on cocoplum if you want real up-to-minute data
<pitti> right, but I did that last Wed or so
<kees> I thought you'd said you did that, but it didn't look like it happened, so we just did it now.
<StevenK> Maybe rmadison is broken :-(
<kees> where $now == 1:10 ago
<pitti> kees: oh? ok, that'd explain it
<pitti> kees: weird, I was sure I copied it
<pitti> kees: so, thanks
<kees> pitti: sure thing. :) /me re-thanks jdstrand
<jdstrand> \o/
<Keybuk> jdstrand: I haven't once this evening accidentally selected and deleted everything I'd just typed
<Keybuk> \o/
<Keybuk> thanks for the use_tapping hint :p
<cjwatson> tkamppeter: there isn't really a sensible package for reporting seed bugs.  ubuntu-meta is about the best I can do for you, but you could just tell me (or any core-dev) and we can fix it
<tkamppeter> cjwatson: Thanks. Please remove openprinting-ppds-extra from all seeds where it is still in. Its content moved to openprinting-ppds.
<tkamppeter> doko, thanks for approving jbig2dec to main.
<cjwatson> tkamppeter: looks like Chuck Short / James Page did it just a few minutes ago.  However, please fix that transitional package so that it can actually be installed.  openprinting-ppds should have Conflicts: openprinting-ppds-extra (<< first-version-where-it-became-a-transitional-package) - the unversions Conflicts is a clear bug
<cjwatson> tkamppeter: you can see it showing up in http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html because of this
<cjwatson> s/unversions/unversioned/
 * JackyAlcine be bracck
<Keybuk> ugh, the big circle with an X in on a pidgin tab *DOES NOT* close the tab
 * Keybuk has an mpt moment
<Kano> hi, will somebody update libva to latest git?
<ebroder> man, it's really bizarre that so many people aren't in european/australian time zones this week
<JackyAlcine> lol
<JackyAlcine> how do you cast a void* to a char* and avoid a segfault when cout'ing?
<ebroder> JackyAlcine: this isn't a channel for general programming discussion. if you're building an app for ubuntu, you can try #ubuntu-app-devel, but you're probably better off looking for a C++ channel
<tsimpson> JackyAlcine: don't use char* ;)
<tsimpson> or void* for that matter
<ebroder> yeah, the void* is more of the issue :)
<tsimpson> there is a reason those C++ guys came up with std::string
<tsimpson> if you are using void pointers, you're probably doing something wrong
<JackyAlcine> It's not me, it's cURL!
<tkamppeter> cjwatson, foomatic-db package updated.
<tkamppeter> Any linker expert around?
<geser> what's your problem? (not that I'm an linker expert)
<JackyAlcine> Neither am I.
<JackyAlcine> But I'm willing to help.
<JackyAlcine> tkamppeter: Your issue?
<tkamppeter> tkamppeter, it is already done, I have found the solution. Thanks.
<JackyAlcine> Oh cool.
<JackyAlcine> If you want, you should post it on Ubuntu Forums, just so everyone else can know.
<\sh> stgraber: ping
<anilg> Hi All.. how do I download all the files (dsc, changes, deb, tar.gz, .diff.gz) for a particular package. The task is to grab certain packages from the repo, and build a local repository
<anilg> apt-get source --download-only only gets the source, and not the debs.
<ari-tczew> anilg: there is no any script which does as you like. you have to download manually .deb files. sorry.
<anilg> hmm.. it seems like a regular operation..
<anilg> We did write a script (ndget) for use in the Nexenta project
<anilg> it currently works for local repos
<anilg> perhaps I need to enhance it to grab things over the network
<JackyAlcine> perhaps ;)
<elif> is there a repository to get all related sources for the ubuntu installer ?
<elif> what boot flag do I need to have a ssh server during the install ?
<cjwatson> tkamppeter: thanks
<hyperair> hmm something seems wrong with launchpad's patch detection support.
<hyperair> i upload a patch generated by debdiff and launchpad asks me if i've uploaded a patch because it apparently doesn't look like one
<Laney> #launchpad
<freinhard> just disvocered that telepathy-sofiasip is not useable with empathy without gstreamer-ffmpeg and (in my case) gstreamer-alsa (deinstalled pulse, broke linphone)
<freinhard> agains what do i need to file a bug? empathy? telepathy-sofiasip?
<dholbach> good morning
<JackyAlcine> Morning, dholbach :D
<ari-tczew> please sponsor this branch https://code.launchpad.net/~om26er/ubuntu/maverick/rhythmbox/rhythmbox-bugfixes-maverick/+merge/43558
<dholbach> hey JackyAlcine
<dholbach> \sh, happy birthday!
<\sh> dholbach: thank you :)
<highvoltage> hey happy birthday \sh
<\sh> highvoltage: thank you :)
<jdstrand_> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: jdstrand_
<hallyn> tseliot: hey, is there any ETA on a fix for the natty broadcom fail?  (I was told yesterday you're the one to ask :)
<rmrfslash> I just updated kubuntu and it appears that the desktop is in a bad place. Everything is upside down, text backwards, window frames fragmented, etc. This is after the most recent update. I wanted to update to KDE 4.5.5. Seems that even installing ubuntu-desktop package doesn't fix this. Probably an intel driver issue or Xorg configuration issue. Something along those lines.
<tseliot> hallyn: I fixed it yesterday, well, unless it's a new issue
<hallyn> tseliot: hm, i upgraded this morning, no wireless yet...  lemme re-try
<tseliot> hallyn: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/700176
<ubottu> Ubuntu bug 700176 in bcmwl (Ubuntu) "bcmwl bcmwl-kernel-source 5.100.82.38+bdcom-0ubuntu1 fails to build" [High,Fix released]
<rmrfslash> I get through the login screen just fine, then everything is flipped upside down, backwards, etc. Buttons that should be on the bottom of window panels are on the top and you need to imagine where they should be and click blindly in that location.
<tseliot> hallyn: make sure you have version 5.100.82.38+bdcom-0ubuntu2
<hallyn> tseliot: <shrug> rebooted, and I have wireless!  thanks!
<tseliot> hallyn: np ;)
<om26er> jdstrand_, around?
<om26er> https://code.launchpad.net/~om26er/ubuntu/maverick/nautilus/nautilus-fix-683972/+merge/45849
<om26er> actually https://code.launchpad.net/~om26er/ubuntu/maverick/nautilus/nautilus-fix-683972
<SpamapS> jhunt: 10:30 still good to discuss upstart events?
<jdstrand_> om26er: hi! I am around
<jdstrand_> om26er: let me look at it
<micahg> jdstrand_: bug 695370, thanks
<ubottu> Launchpad bug 695370 in gnome-shell (Ubuntu) "gnome-shell binaries seem to have returned" [Undecided,New] https://launchpad.net/bugs/695370
<micahg> doko: is a bug about someone complaining about libreoffice replacing openoffice useful at all (yes I know about the ubuntu-devel e-mail and will point the user to that)
<doko> micahg: just tag it with lo33
<micahg> doko: will do, thanks
<om26er> jdstrand, building it locally?
<jdstrand> om26er: possibly, got sidetracked for a moment but am pulling the branch now
<jdstrand> SpamapS: hi! if you'd like, I can review your merge request for bug #343870 this morning if you update the changelog as requesting in the last comment of the merge request
<ubottu> Launchpad bug 343870 in mysql-dfsg-5.1 (Ubuntu Karmic) "php-cli segmentation fault with mysql extension" [Medium,Confirmed] https://launchpad.net/bugs/343870
<jdstrand> s/requesting/requested/
<SpamapS> jdstrand: Right I've been putting that off for far too long.
<tokeefe> I'll file a bug report, but my troubles appear to have resulted from the latest Intel driver update. Must have been rolled out within the last week. Here's a screenshot of the effect http://oi56.tinypic.com/4q261u.jpg   I have a VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18) according to lspci/lshw
<cjwatson> Keybuk: mind if I steal the "Fix Plymouth to cope with framebuffer mode change" work item from you?
<Keybuk> oh, I thought you already had
<Keybuk> after all, you very definitely touched plymouth last
<cjwatson> heh, only trivially :)
<cjwatson> (as far as stuff that's actually landed in the archive goes, anyway)
<cjwatson> reassigned the WI
<siretart> doko: I hope you don't mind that I subscribed you to bug #701492
<ubottu> Launchpad bug 701492 in doxygen (Ubuntu) "doxygen's latex output requires sectsty.sty" [Undecided,New] https://launchpad.net/bugs/701492
<doko> siretart: should be fixed with recent doxygen
<siretart> doko: you mean with upstream release 1.7.4?
<doko> siretart: no, dependencies changed
<siretart> doko: oh, I'm not talking about your added latex-xcolor.sty dependency. the sectsty.sty is a similar, but additional issue
<ogra> cjwatson, whats the likelyness of btrfs as default in natty ? (i'm thinking about the preinstalled arm images and the possible advantages of using the SSD mode on SD cards)
<elif> cjwatson: when partman finish its job, how exactly the next stage (five:installing the target system) occurs, cause if I want to skip partman, maybe I just would use a hack to fake it had ran. Thks in advance
<jdstrand> om26er: uploaded. thanks for your work on this!
<cjwatson> ogra: I'm not expecting to ship it by default on x86 architectures; as far as I'm concerned, what you do for the preinstalled arm images is independent of that
<cjwatson> elif: you could write a dummy /var/lib/dpkg/info/partman-base.postinst that does whatever partitioning you want and mounts /target and whichever extra mounts you have under that
<om26er> jdstrand, thanks for the upload, if you have the time, i have an approved merge request too :D
<jdstrand> om26er: yeah, the rhythmbox one. I am already looking at it
<om26er> only a core-dev needed to upload
<om26er> oh nice
<ari-tczew> pitti: ping
<ari-tczew> Riddell: approval from ubuntu-sru? I thought that it's gone
<Riddell> ari-tczew: what?
<ari-tczew> Riddell: bug 653480
<ubottu> Launchpad bug 653480 in python-django-piston (Ubuntu Maverick) "broken dependencies" [Undecided,Fix committed] https://launchpad.net/bugs/653480
<Riddell> 0.2.2-1ubuntu0.1 is in maverick-proposed unapproved queue
<Riddell> it needs the three items I said on the bug to get accepted
<ari-tczew> Riddell: hmm, policy has been changed some months ago
<quadrispro> hi all!
<ari-tczew> now needs only sponsor
<ari-tczew> hi quadrispro
<ari-tczew> pitti accepts without any ACK from ubuntu-sru
<ari-tczew> (I know, he is a member)
<micahg> ari-tczew: you need the test case though
<ari-tczew> micahg: o rly? It is in the bug, just without header" TEST CASE"
<micahg> ari-tczew: right, it needs to be in the description and clearly visible
<ari-tczew> micahg: I'm very curious whether you're that very pedantic in every case.
<micahg> I always add the test case to teh description with a header, it's step 2 of the SRU procedure
<Laney> I don't think policy has changed, stuff is just reviewed in the queue now
<cjwatson> ari-tczew: you've been replying to merge requests commenting that sentences should end with a dot, so I thought you would respect pedantry :-)
<Laney> as opposed to pre-approval we had in universe before
<ari-tczew> cjwatson: it's true
<ari-tczew> to all: very restrictive policy is killing willigness to contributing
<micahg> jdstrand: bug 695728 for sponsorship, thanks
<ubottu> Launchpad bug 695728 in gnome-python-extras (Debian) "python-gtkmozembed should depend on xulrunner" [Unknown,Fix committed] https://launchpad.net/bugs/695728
<ari-tczew> Riddell: debdiff - you have branch
<ari-tczew> in the bug
<ari-tczew> please don't say that I have to create a debdiff - I'll laugh
<Riddell> ok, says so in the bug
<ari-tczew> Riddell: couldn't you find it before commenting? do I have to comment everything?
<Riddell> ari-tczew: I didn't see it, so maybe others won't either
<micahg> ari-tczew: as sponsor, you should make sure that the SRU procedures are followed before uploading (assuming you uploaded it)
<ari-tczew> micahg: wow, you're very perceptive! that's right, I uploaded it because it's very trivial bugfix and there is no much philosophy to reproduce
<micahg> ari-tczew: then the test case should be easy to write :)
<micahg> jdstrand: unping for sponsorship of bug 695728
<ubottu> Launchpad bug 695728 in gnome-python-extras (Debian) "python-gtkmozembed should depend on xulrunner" [Unknown,Fix committed] https://launchpad.net/bugs/695728
 * micahg forgot that there's a -desktop branch for it now
<micahg> chrisccoulson: can you sponsor the above ^^
<SpamapS> jdstrand: I updated the karmic mysql update
<ari-tczew> Riddell: for future: there are only 2 ways to give a patch - bzr and debdiff and I think so that is easy to find. end of topic.
<SpamapS> using recommendations from the Department of Redundancy Dept.
<shadeslayer> jono: pokety poke
<shadeslayer> jono: http://developer.ubuntu.com/create/ << Point 1 has a formatting error : "for new application ... " -> "For new application"
<ari-tczew> micahg: here we go. test case is exist. now you can stimulate your senses.
<micahg> ari-tczew: not for me, for you :)
<ogra> cjwatson, is the blocking based on immaturity of btrfs or on any external factors (i.e. grub2) that wouldnt affect arm ?
<chrisccoulson> micahg - yeah, sure. will do that in a bit
<micahg> chrisccoulson: thanks
<SpamapS> zr
<SpamapS> ls
<pitti> ari-tczew: hi
<pitti> ari-tczew: no, the pre-upload approval on the bug is gone (as a mandatory thing)
<pitti> ari-tczew: but ~ubuntu-sru still of course reviews the diffs and bugs
<pitti> but after the upload
<pitti> (usually)
<ari-tczew> pitti: so what I did wrong on bug 653480 ?
<ubottu> Launchpad bug 653480 in python-django-piston (Ubuntu Maverick) "broken dependencies" [Undecided,Fix committed] https://launchpad.net/bugs/653480
<pitti> ari-tczew: nothing, except for the missing test case maybe (if it's not obvious)
<ari-tczew> pitti: so what
<pitti> ari-tczew: Riddell just isn't in ~u-sru and thus doesn't ack SRUs by himself
<pitti> ari-tczew: so that'll need to wait until I get to review the queue
<pitti> Riddell helps out by accepting approved SRUs (thanks!)
<ari-tczew> pitti: ok
<pitti> Riddell: FYI, debdiffs are now also fairly optinal, as LP generates them from the upload queue
<Riddell> pitti: where's that?
<Riddell> bdmurray: did you really mean to reopen bug 68401 ?
<ubottu> Launchpad bug 68401 in lighttpd (Ubuntu Dapper) "Cannot remove the lighttpd pkg from Edgy Eft" [Medium,Incomplete] https://launchpad.net/bugs/68401
<bdmurray> Riddell: looking
<pitti> Riddell: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= and open the expander
<pitti> Riddell: "diff from ... to ..."
<pitti> Riddell: that's what the queuediff tool downloads and displays
<Riddell> pitti: nifty
<bdmurray> Riddell: fixed, thanks
<cjwatson> ogra: grub2 supports btrfs now.  I'm more worried about things like btrfs' disk utilisation, which I hear is still not great (but I freely admit to not having checked for a while)
<ogra> hmm, that would bite us on SD cards for sure
<ogra> thanks !
<ari-tczew> pitti: could you look how to handle that SRU? https://code.launchpad.net/~clint-fewbar/ubuntu/karmic/mysql-dfsg-5.1/mysql-sru-343870/+merge/42667
<crissi> hello. i have a problem with dm-multipath. it fails with "error adding target to table" errors in initrd when rootfs is readonly but made readwrite with aufs.
<crissi> multipath -d shows my path fine but they cant added to the devicemapper target list because dm has failed
<tetsuo__> hello
<tetsuo__> i've run into a bug with samba, that appears to be fixed upstream
<tetsuo__> its this bug http://www.ubuntu.com/usn/usn-987-1
<tetsuo__> oops
<tetsuo__> sorr
<tetsuo__> this one https://bugzilla.redhat.com/show_bug.cgi?id=651722
<ubottu> bugzilla.redhat.com bug 651722 in samba3x "All samba versions before 3.5.6 fail to "smbclient" to Win7 with Live Essentials" [High,Verified]
<tetsuo__> i want to know what needs to be done in order to get either samba updated, or just that patch backported for ubuntu 10.10
<jdstrand> @pilot out
<ebroder> !sru | tetsuo__
<ubottu> tetsuo__: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<ebroder> tetsuo__: you need to file a bug and run it through the procedure on that page
<tetsuo__> will do thank you
<jdstrand_> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<ari-tczew> pitti: is there any way to join ubuntu-sru?
 * JackyAlcine is now reading trackback.
 * JackyAlcine is all caught up. ;D
<ebroder> JackyAlcine: there's not really any need to post status messages to all of the channels you're joined to
<JackyAlcine> Sorry, ebroder.
<cragdor> Hi Guys, anyone aware of a GTS250 id 10de:0615, having issues with Ubuntu 10.10 (eg nvidia probe failed)
<slangasek> SpamapS: ping
<slangasek> SpamapS: unping
<doko> wgrant: ping
<SpamapS> slangasek: thanks :)
<diwic> +
<diwic> -----------------------------------------------------------------------------------
<diwic> -
<ogra> hmm, does anyone know why update-initramfs -c doesnt take care for bootloader setup while -u does ?
<ogra> that seems like a bad bug to me
<ogra> (the run_bootloader function is never run if the -c arg is used)
 * diwic makes a note not to push any keys when carrying the laptop around ;-)
<ogra> diwic, oh, i thought that was a deliberate attempt of ascii art
<ogra> oh, disregard my cmplaint above, seems cjwatson already proposed a solution in bug 623375
<ubottu> Launchpad bug 623375 in initramfs-tools (Ubuntu) "Skipping the bootloader installation when creating rootfs or installation media" [Undecided,New] https://launchpad.net/bugs/623375
<ogra> (i guess i'll just have to implement it :) )
<jelmer> NCommander: hi
<NCommander>  jelmer hi
<jelmer> NCommander: I hear you're interested in discussing bzr-builddeb - I'd be happy to come by the ARM room to discuss it.
<jelmer> NCommander: When would be a good time - now?
<NCommander> jelmer: that would be good
<cyril> Hello all,
<cyril>  I am running eclipse under ubuntu and started a php project using symfony with doctrine. I would like an advice on which visual modelling tool to use in order to generate yaml files for doctrine...
<cyril> in other words, I want to visually design my database model and then translate it into doctrine yaml files.. What is the most appropriate tool, maybe an eclipse plugin?
<micahg> !support | cyril
<ubottu> cyril: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<pitti> StevenK: do you know why this says "no packages copied?
<pitti> copy-package.py -s hardy -p canonical-kernel-team --ppa-name=ppa -b  --to-suite=hardy-proposed linux
<pitti> StevenK: the package there is newer than the one in hardy-updates, and it's not yet in -proposed
<pitti> StevenK: I did similar things for lucid, karmic, maverick, etc, and it worked
<pitti> sconklin: ^ (FYI)
<StevenK> I suspect because the hardy kernel data is broken
<StevenK> pitti: One of hardy's kernels was uploaded was a different orig, and due to a bug was accepted. So now hardy's kernel has two origs :-(
<pitti> StevenK: is there anything I (or sconklin) can do about this?
<StevenK> pitti: Leave it with me, I'd like to consult my external memory (wgrant)
<pitti> StevenK: thanks
<wgrant> StevenK: We normally fix that by temporarily cowboying out the hash check.
<wgrant> StevenK: However, we should now have a new solution.
<StevenK> wgrant: We should?
<wgrant> StevenK: I think we may be able to expire the old orig.tar.gz.
<wgrant> And things will work.
<StevenK> Awesome. Let's.
<pitti> StevenK: server down, so I lost backscroll
<StevenK> pitti: Is fine, the command line was in backscroll
#ubuntu-devel 2011-01-12
<ebroder> kees: ++ for "block rare net module autoloading: INPROGRESS" :)
<kees> ebroder: hehe :)
<kees> ebroder: https://lists.ubuntu.com/archives/kernel-team/2011-January/013990.html
<lifeless> mathiaz: https://bugs.launchpad.net/launchpad/+bug/650487
<ubottu> Ubuntu bug 650487 in Launchpad itself "Mark new revisions since superseeded merge proposal in code review" [Low,Triaged]
<PetrHH> Hello
<PetrHH> my program is using mysqld and stores data in user's home directories
<PetrHH> so I have to add one rule to /etc/apparmor.d/usr.sbin.mysqld
<PetrHH> but I'm afraid what happens after update apparmor. Will be this file restored with default values?
<PetrHH> May I create my own rule file and put it somewhere? Where?
<PetrHH> Thank you for help.
<soren> PetrHH: Your changes won't be overwritten.
<shankao> I think that you'll be offered to keep, replace or diff the changes
<soren> PetrHH: The user will be prompted about the changes.
<soren> PetrHH: What I recommend instead is a separate file.
<soren> PetrHH: That grants the additional privileges.
<PetrHH> soren, Thank you. Separate file will be better. Do you have any idea where to place it and the name of file? I tried to find it in apparmor documentation but is is huge and very complicated.
<soren> PetrHH: I'd rather leave that to someone who's actually any good with apparmour. jdstrand, perhaps? ^^
<PetrHH> soren, Thank you for your help. I'll wait for jdstrand and will ask him.
<sbeattie> PetrHH: /etc/apparmor.d/usr.sbin.mysqld is a conf file, and so on updates you'd be prompted to keep or drop your changes to that file.
<sbeattie> PetrHH: if you're running maverick, you can make your changes to /etc/apparmor.d/local/usr.sbin.mysqld and it will keep them and avoid prompting you on updates.
<sbeattie> (remember to do /etc/init.d/apparmor reload after making your changes)
<PetrHH> sbeattie, I'm afraid whe user will be prompted, he will click to drop changes and it will be gone :-)
<PetrHH> I'd like to have packages for version 10.04 and newer
<PetrHH> and now using 10.04
<soren> sbeattie: Is it possible to add a completely separate file that grants additional privileges to /usr/sbin/mysqld?
<soren> sbeattie: Or will whichever is loaded last take precedence or something like that?
<soren> sbeattie: ...since this doesn't really seem like "local" modifications. They're modifications that another package wants to make.
<sbeattie> soren: the shipped apparmor policy needs to be constructed to do that, but yes, it's possible to arrange things so that additional packages can drop files into a .d/ directory that gets automatically included.
<soren> sbeattie: Hm... Ok. What were to happen if I just added another file in /etc/apparmor.d/ that also tried to set some rules for a file that was covered by another file?
<sbeattie> soren: we do this right now for the example apache2 profile we ship in (I think) the apparmor-profiles package; it automatically imports stuff from /etc/apparmor.d/apache2.d/
<sbeattie> soren: they'll be treated as separate profiles, and one will be loaded instead of the other (last one wins, probably)
<soren> sbeattie: Ok, that's what I thought.
<soren> sbeattie: Thanks!
<sbeattie> soren: sure
<soren> PetrHH: So, it seems you want to file a bug against the mysql packages, asking for such a directory, and then you'd provide such a file in your package.
<soren> jdstrand: Never mind, we sorted it out.
<PetrHH> I add this @{HOME}/.config/cqrlog/database/** rwk, line to usr.sbin.mysqld
<PetrHH> I'm not sure what you mean. I should add bug to mysql package and ask for add my line to apparmor profile?
<soren> PetrHH: No.
<soren> PetrHH: 12:37 < sbeattie> soren: the shipped apparmor policy needs to be constructed to do that, but yes, it's possible to arrange things so that
<soren>                   additional packages can drop files into a .d/ directory that gets automatically included.
<soren> PetrHH: So, you file a bug asking for such a .d/ directory, and then you adjust your package to drop a file into that directory, granting this additional privilege to mysqld.
<sbeattie> PetrHH: after you file the bug, please add me as a subscriber to it (my launchpad id is the same as my irc nick)
<PetrHH> sbeattie, I just tried to create new file called usr.sbin.mysqld-cqrlog and add my rules to it
<PetrHH> and after that I restarted apparmor
<PetrHH> and it is working
<PetrHH> It looks like no bugs needed
<sbeattie> PetrHH: no, the bug is still needed; in your case, your mysql profile with the added rules happens to be winning (or really, losing) a "race" and if the apparmor int script decides to load the policies in a different order in the future, it will stop working.
<sbeattie> (also, if we ship a mysql update with an update to its apparmor profile, your copied profile won't get the changes.)
<PetrHH> sbeattie, Now I understand. It works because my fire rewrites rules whis were set before
<PetrHH> sbeattie, Is there any way how to do it? I have ask for that directory all distributions using apparmor and wait if they agree and add directory for me
<PetrHH> I don't thing that is good.
<PetrHH> I know that akonadi is also using mysqld
<PetrHH> but it looks they have their own mysqld called mysqld-akonadi
<PetrHH> so they just add their own rule to apparmor.d
<cdbs> Any idea why this FTBFS is happening? http://launchpadlibrarian.net/62113228/buildlog_ubuntu-natty-amd64.haveged_0.9-3ubuntu1_FAILEDTOBUILD.txt.gz Is GCC broken in natty?
<cdbs> doko: ^
<cdbs> Okay thanks, I got it
<cr3> when preseeding, what's the difference between partman-partitioning/confirm_write_new_label and partman/confirm_write_new_label?
<JackyAlcine> cr3: One writes a drive label, while the other a volume label.
<cr3> JackyAlcine: thanks, exactly what I needed to know
<JackyAlcine> No problem.
<cjwatson> JackyAlcine: no, that is not correct.
<cjwatson> cr3: the former exists, while the latter does not (any more).
<cr3> cjwatson: since when?
<cjwatson> cr3: partman-base 114, so hardy.
<cr3> cjwatson: man, someone dropped the ball and that's me :)
<cjwatson> in both cases, "label" refers to the partition table (traditionally called "disklabel" especially by the BSDs)
<cjwatson> (I know they aren't quite the same thing but the abstraction is similar)
<hallyn> tseliot: SpamapS is having broadcom troubles - dkms failed to build the module.  what manual steps can he take to get it up so he can run?
<tseliot> hallyn: I need to see the error
<hallyn> tseliot: he did symlink bcm43xx-0.fw under /lib/firmware/brcm
<hallyn> hm
<hallyn> tseliot: /var/lib/dkms/bcmwl/.../build/src/wl/sys/wl_linux.c: IN function 'wl_attach':
<hallyn> 487:3: error: implicit declaration of function 'init_MUTEX'
<doko> cdbs: look at the config.log?
<cdbs> doko: I got it.
<tseliot> hallyn: that happens without the patch that I uploaded
<cdbs> doko: it was a simple change, the CC var was being set improperly
<hallyn> he just updated this morning
<hallyn> nm,
<hallyn> tseliot: apparently he did not :)
<hallyn> tseliot: thanks
<tseliot> hallyn: np
<hallyn> tseliot: however, i did a dpkg -i of the kernel package this morning (to revert some test changes), and lost the firwmare links again.
<hallyn> tseliot: i just symlinked them and was back up, but assume i shouldn't have lost them
<tseliot> hallyn: firmware links?
<hallyn> /lib/firmware/brcm/bcm43xx-0.fw and bcm43xx_hdr-0.fw
<hallyn> after dpkg -r linux-image; dpkg -i /var/cache/apt/archive/linux-image....deb, they were gone
<tseliot> hallyn: what problem are you trying to solve?
<hallyn> tseliot: what do you mean?  i had a custom linux-image that i wanted to revert (with higher version # than current kernel)
<hallyn> tseliot: point is just that 'dpkg -r; dpkg -i' seemed to kill my broadcom firwmare setup
<hallyn> tseliot: so someone might end up having problems, is all i'm saying
<tseliot> hallyn: the modules that dkms provides should override whatever the kernel has. I'm not sure about firmwares though
<tseliot> this is why I was asking
<hallyn> tseliot: after wireless wasn't working i tried to remove and install 'linux-firmware', but that didn't do it.  So basically I have no idea (a) why the firmware first disappeared, or (b) where it is *supposed* to come from  (am i supposed to do some dkms command?)
<tseliot> hallyn: wait a second, the broadcom package shouldn't have anything to do with that firmware file. It only blacklists bcm43xx when you install it (it also does modprobe -r)
<hallyn> tseliot: i have no idea what removed that firmware file
<hallyn> if/when it happens again i'll try to pay more attention :)
<tseliot> ok
<apw> pitti, hey ... seems a huge hunk of kernel's WIs have gone missing: http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.html
<apw> pitti, aware of the cause ?
<pitti> apw: I wasn't aware of that, no
<pitti> apw: I added some extra textual "over time" report, but didn't change anything in the collector
<apw> pitti, hrm, i wonder if it happened to anyone else
<pitti> so it wasn't just your team dropping WIs for natty
<apw> pitti, not that i am aware of, i see desktop has a smaller drop at the same time, much smaller
<apw> pitti, but perhaps someone broke a work item list during an update
<apw> pitti, so will investigate on that angle for now
<apw> pitti, ok it seems to be all of one of my team members items which are gone, it must be user error, panic over
<micahg> doko: a build error, foo is defined in DSO /usr/lib/bar.so is a no-add-needed error?
<doko> micahg: most likely, yes. build log?
<micahg> doko: https://bugs.launchpad.net/ubuntu/+source/libxml++2.6/+bug/699897/+attachment/1787247/+files/last_operation.log
<ubottu> Ubuntu bug 699897 in libxml++2.6 (Ubuntu) "Packaging request for libxml++ 2.33.1" [Wishlist,In progress]
<micahg> I just want to get the terminology right when upstreaming the patch
<apw> jdstrand, hey .. have you been post-poning work items on n-security-apparmor ?
<SpamapS> Hm, so I just updated to natty and it seems like many of my gnome settings are being ignored
<SpamapS> err. updated to the latest natty, been on natty a while now
<SpamapS> keyboard settings.. gtk theme.. all stuck at default
<doko> micahg: "so try adding it to the linker command line" together with the information that the referenced symbol is not in a library but in examples/dom_build/main.o
<micahg> doko: yeah, that works, I just wanted to know what to call it
<pitti> apw: did your team structure change recently?
<apw> pitti, turns out it is security ... they have posponed a bunch of stuff without marking them postponed, but by moving them over to a new invalid title
<apw> i think i need to get them to copy them back ... will poke
<pitti> apw: ah, that explains it, thanks!
<kees> apw: right, we moved a huge chunk of future work out. we can dup it back as postponed if you want?
<pitti> *phew*
<robert_ancell> ScottK, The recent WebKit build failed due to differing C++ symbols (there is one .symbols file in the WebKit debian/ dir).  I tried the instructions in http://pkg-kde.alioth.debian.org/symbolfiles.html, but it only modifies one symbol and the build failures show multiple symbols that conflict.  Do you know a method of making the .symbols file work in natty?
<pitti> apw: evo says "room to be announced"
<robert_ancell> doko, do you have any ideas about this symbol issue? ^^^
<doko> robert_ancell: use the unmangled name?
<robert_ancell> doko, how do I do that?  I tried the pkg-kde method but it didn't seem to work
<doko> robert_ancell: dpkg-gensymbols(1)
 * SpamapS just gives up and gets back to work on his ugly grey circa 1999 gnome desktop
<robert_ancell> doko, thanks
<mpt> YokoZar, hi, I'm doing the Wine-in-USC spec now. Is there a name for that standard you've come up with for finding+removing "managed" Wine applications?
<ebroder> RAOF: by the way, having dug more deeply into the g-s-d code, it does set a mode when it launches, it just does so using completely different logic from when a monitor gets hotplugged. so the X patch would not be strictly necessary, but would likely make the transition a bit less flickery
<SpamapS> slangasek: I tried 8 nfs mounts with the new portmap/statd and delays inserted in fsck/statd/portmap .. seems to work though I'm not sure why.
<jussi> I remember Scott Remnant was working on android apps natively in ubuntu - does anyone know what happened to this? do they work, are the bits available somewhere?
<RAOF> ebroder: The g-s-d modeset-on-startup is kinda a bug - seb patched it (in Maverick?) to check a gconf key to determine whether or not to actually do that.
<robbiew> jussi: you might try asking rickspencer3
<jussi> robbiew: ok, thanks!
<SpamapS> slangasek: ok I figured it out. The reason it works ok is that mountall blocks *before* forking to run the mount command.
<jhunt_> apw: just noticed that magic sysrq appears to be enabled in natty, although /proc/sys/kern/sysrq is 0... ?
<hockebocke> are there any ubuntu gnome devs channel?
<kklimonda> hockebocke: most of the team responsible for gnome on Ubuntu sits in the #ubuntu-desktop
<ogra> Daviey, http://www.grawert.net:81/rooms/, http://fhem.de/fhem.html and the hw is http://www.elv.de/Sensoren/x.aspx/cid_74/detail_1/detail2_1738 and http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=28194&flv=1&bereich=&marke= .... sorry, all german
<hockebocke> kklimonda: thanks!
<ogra> Daviey, its operating on 868,35 MHz wireless
<Daviey> ogra, thanks!
<kamal> cjwatson, or other GRUB2 folk:  Various references claim that you need to hold the *left* shift key to get the GRUB2 menu to come up, but I find that the right shift key works just as well on the couple of machines I've tried.   Is there any truth to that "left shift only" requirement?
<apw> jhunt_, define enabled?  which thing can you do which you expect to be disabled ??
<cjwatson> kamal: no truth AFAIK
<jhunt_> apw: use magic sysrq keys (ie alt+sysrq+u)
<kamal> cjwatson: ok thanks
<apw> jhunt_, doens't seem to work on mine ... sysrq h works when it is 1 and not when 0
<apw> jhunt_, does h work for you?
<cjwatson> kamal: the code explicitly checks both left and right shift
<jhunt_> apw: The machine is sitting next to me if you're interested.
<cjwatson> +  if (mods >= 0 &&
<cjwatson> +      (mods & (GRUB_TERM_STATUS_LSHIFT | GRUB_TERM_STATUS_RSHIFT)) != 0)
<cjwatson> +    return 1;
<kamal> cjwatson: that's pretty convincing :-)
<apw> cjwatson, heh thanks
<apw> jhunt_, where are you
<jhunt_> apw: alamo 1
<achiang> speaking of grub, is it possible for a system that is already using grub1 to migrate to grub2?
<cjwatson> yes, just install grub-pc
<cjwatson> https://help.ubuntu.com/community/Grub2#Upgrading%20to%20GRUB%202
<achiang> thank you
<achiang> does anyone know where software-properties stores its configuration information, such as frequency of updates, etc.? i'm poking around in there and in python-apt, but nothing is jumping out at me
<achiang> ah, narrowing in
<cjwatson> achiang: /etc/apt/apt.conf.d/ somewhere IIRC
 * achiang finds a write_config() method in software-properties that does indeed write to /etc/apt/apt.conf.d
<achiang> thanks cjwatson
<achiang> oh, and it writes to /etc/cron.daily/apt, etc.
<cjwatson> no, it just makes sure that's executable
<bigon> is there a public list of blacklisted packages ?
<micahg> bigon: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<bigon> thx
<achiang> cjwatson: hm, yeah. actually, i wonder if i made any progress at all on this question
<ScottK> robert_ancell: So far it's worked for me.  Not sure what's up.
<apw> jhunt_, yep after reboot i have the same, and the bug is obvious ... bah
<apw> thanks
<jhunt_> apw: np
* mbarnett changed the topic of #ubuntu-devel to: **Launchpad down/read-only from 23:00 - 00:30 UTC for a code update** Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friend
<bigcx2> hey all
<bigcx2> i have a question about cdbs, namely the autotools makefile
<bigcx2> there's a flag called DEB_CONFIGURE_SCRIPT_ENV
<bigcx2> where the options passed into that can get pushed through to the ./configure script
<bigcx2> is there any way to set the flag without hardcoding it in debian/rules?
<bigcx2> aka passing it into dpkg-buildpackage, pbuilder, etc.
<bigcx2> ?
<cjwatson> you can set an environment variable on calling dpkg-buildpackage and that may be passed through if you're lucky
<bigcx2> what if i'm unlucky :/
<JackyAlcine> bigcx2: Good chances you aren't.
<bigcx2> yea, i'm thinking i'm unlucky
<bigcx2> i'm trying it right now, but i don't think it will work
<bigcx2> i was also thinking of using dpatch, but i don't think that will work for patching debian/rules either...
<cjwatson> no.  why not just change debian/rules?
<cjwatson> also, note that if you're using debuild then you have to pass environment variables in a special way; see its manual page
<bigcx2> the way the source of the package works is you have to pass a special environment variable to ./configure to set it up based on a given directory
<bigcx2> i'd rather not have to have the package builder edit debian/rules if possible
<bigcx2> looks like i'm unlucky
<bigcx2> poop, i don't think there's any other way to get around it
<sconklin> pitti: do you know what happened to the verification tags?
<cody-somerville> cjwatson, re: LP #664115, is there a test case I can perform to verify that removing the 'udevadm settle' call doesn't break whatever it was originally added in for.
<ubottu> Launchpad bug 664115 in OEM Priority Project "chroot loop devices stall for extremely long periods" [High,Confirmed] https://launchpad.net/bugs/664115
<cody-somerville> ?
<pitti> sconklin: I think so; most bugs have them, but I found those which don't: bug 669279 bug 493156
<ubottu> Launchpad bug 669279 in alsa-driver (Ubuntu) "[ICH4 - Intel ICH6] Dell Latitude D610 - Master mixer doesn't affect headphone output" [Low,Fix committed] https://launchpad.net/bugs/669279
<ubottu> Launchpad bug 493156 in linux (Ubuntu Lucid) "Please enable CONFIG_TASK_DELAY_ACCT" [Undecided,Fix committed] https://launchpad.net/bugs/493156
<pitti> sconklin: the problem with those is that these bugs are filed against the wrong package
<pitti> sconklin: the latter was fixed in linux-ec2, not linux
<cjwatson> cody-somerville: not as such.  the original change was for either LVM or RAID installs, possibly both.
<sconklin> it looks to me like none of the lucid ones have them. https://kernel-tools.canonical.com/srus.html
<sconklin> all the ones with the triangle logo don't have the tags
<pitti> sconklin: unsure; I just might have forgotten to run the script for lucid, doing now
<bjf> pitti, if you look at the url sconklin pointed you too, you can see that it needs to be run for maverick as well
<pitti> sconklin, bjf: sorry, LP just pulled the rug underneath me; need to run maverick later
<bjf> pitti, ack
<ogra> cjwatson, can you let ti-omap4-software-channel-0.1 into the archive (its in NEW) so i can close the WI
<StevenK> I'd suggest that isn't now, due to LP being down
<cjwatson> indeed
<ogra> grmbl ... yeah, cant close WIs
<ogra> (though the LP message is "will be down very soon")
#ubuntu-devel 2011-01-13
* mbarnett changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<phizz> anyone know if the new house came on tonight?
<pingbat> hi all, is this a good place to report a potential problem in ubuntu 10.10 ?
<Hobbsee> !bug
<ubottu> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
<directhex> and nobody will remember any bugs you type here in about 5 minutes' time
<pingbat> heh
<pingbat> well in that case i'll file the bug
<pingbat> in the meantime would anyone be in a position to try and reproduce the bug?
<pingbat> you'll need a FT2232D based debugger
<pingbat> JTAG
<hyperair> say, is there any way i can find an ical link for the natty release schedule?
<ari-tczew> hyperair: https://wiki.ubuntu.com/NattyReleaseSchedule
<hyperair> ari-tczew: it's just a listing. i want something i can feed my calendar
<ari-tczew> then dunno
<mok0> hyperair: should be rather easy to generate one using https://wiki.ubuntu.com/NattyReleaseSchedule?action=raw
<hyperair> mok0: but i'm not familiar enough with the ical format. heh
<hyperair> mok0: googling for ical ubuntu release schedule seems to show that hardy had it
 * hyperair brb
<mok0> hyperair: it's quite straightforward IIRC
<mok0> http://reefknot.sourceforge.net/bootstrap-guide/indexs05.html
<mok0> That example covers your needs :-)
<mok0> hyperair: actually, it's called the .ics format
<mok0> hyperair: there's even packaged a python module for it: python-vobject
<soren> It's dreadful.
<mok0> soren: what is?
<soren> python-vobject.
<mok0> soren: ah :-)
<soren> and the format.
<mok0> soren: ... I tend to agree... but it's the standard we have to work with
<soren> I've used it a couple of times, and each time I lose a bit of faith in humanity.
<soren> mok0: True.
<mok0> soren, perhaps you like this better? http://xml.coverpages.org/iCal.html
<slangasek> SpamapS: oh, hmm.  I wonder if that's a bug?
<slangasek> SpamapS: hmmm.  Isn't portmap-wait redundant?  statd only starts when 'started portmap' is emitted
<slangasek> SpamapS: (only noticed this while trying to fix up idmapd in the same way as statd)
<bjf> StevenK, which room are you hanging out in? sconklin and i have a question
<StevenK> bjf: I'll come down
<ogra> cjwatson, do you know what is the reason that tools like fdisk by default still run in DOS compatibility mode ?
 * ogra thinks we should default to having switched it off
<SpamapS> slangasek: statd also starts when mouting TYPE=nfs is emitted, which may be well before portmap started.
<SpamapS> mounting rather
<slangasek> SpamapS: ahhh yes
<slangasek> SpamapS: thanks for the refresher :)
<SpamapS> slangasek: if I didn't already have a headache from a night of reveling w/ the server team, I'd have one now because I have to think about it again.
<slangasek> SpamapS: maybe that means there's a missing comment ;)
<cjwatson> ogra: upstream
<cjwatson> ogra: I mean, I don't know for sure, I imagine it's general conservatism
<superm1> cjwatson, were you aware of console-setup install problems affecting buildd's on natty?  eg: http://launchpadlibrarian.net/62089492/buildlog_ubuntu-natty-i386.mythtv_2:0.24.0%2Bfixes.20110112.2394a9d-0ubuntu0mythbuntu3_FAILEDTOBUILD.txt.gz  I'm not noticing them at all on a home sbuild with a natty schroot though.
<cjwatson> superm1: not previously ...
<cjwatson> the message is from kbd
<cjwatson> hard to say whether those errors are fatal though
<cjwatson> five of them clearly weren't, so was the sixth?  hard to say :)
<Laney> Sorry to prod but could someone in -sru please review/accept the pristine-tar SRU in m/UNAPPROVED? The version in release doesn't work so well with the -proposed tar
<superm1> cjwatson, are those errors from fgconsole leaking through maybe because of a redirected fd for stderr when running in debconf?
<kirkland> siretart: ping
<pitti> cjwatson: FTR, current live cd build failure got fixed this morning
<Riddell> bdrung: ping
<ogra> StevenK, where are you hiding ?
<StevenK> ogra: Elsewhere
<ogra> StevenK, how much beer does it take to get ti-omap4-software-channel out of NEW ?
<StevenK> ogra: More you have access to?
<ogra> ^dunno, there might be multiple barrels in the bar :)
<StevenK> s/\(have\) \(access\)/\1 easy \2/
<doko> mvo: http://launchpadlibrarian.net/62083003/buildlog_ubuntu-natty-i386.aptitude_0.6.3-3.2ubuntu1_FAILEDTOBUILD.txt.gz
<bdrung> Riddell: pong
<Riddell> bdrung: I was doing bug 702493
<ubottu> Launchpad bug 702493 in phonon-backend-vlc (Ubuntu) "amarok crashes on quit when using vlc backend" [Undecided,New] https://launchpad.net/bugs/702493
<Riddell> but it doesn't seem to help for me so I'm not going to upload for now
<Riddell> bdrung: correction, it does work, so I'll upload to natty and maverick shortly
<bdrung> Riddell: patch against phonon-backend-vlc or vlc?
<Riddell> bdrung: vlc
<bdrung> Riddell: please wait with the sru, because we want to release another security fix
<bdrung> tumbleweed: around?
<SpamapS> apw: ping, I understand you added the bit where the kernel commandline is given to upstart in its environment?
<dragorn> I'm trying to make a deb, on one ubuntu64 system with dpkg 1.15.5.6u2 all works as expected, on another ubuntu-server32 install with 1.15.8.4ubuntu1, it goes 'funny':  on the funny system, dpkg -i foo.deb skips all the db_input questions and assumes the defaults, but dpkg-reconfigure works as expected.  Any thoughts as to why the hell it skips during install?  (and I did --purge and confirmed with debconfig-show that the questions are
<dragorn> not in the database)
<dapal> dragorn: dpkg-reconfigure debconf, you should notice different values for "Ignore questions with priority less than: [..]"
<dragorn> dapal: Argh!  That's it.  Thanks, I've been banging my head against that all day.  Ubuntu isn't my standard distro, didn't know that one.
<dapal> dragorn: (I use Debian, heh :D)
<dragorn> dapal: I'm usually a gentoo guy, but I've got enough people wanting ubuntu packages that I'm making the effort... for whatever reason, ubuntu has been packaging my stuff from 2007 and not updating.
<dapal> dragorn: ow :/. Good luck then :)
<dragorn> dapal: This was the last hurdle
<dragorn> dapal: actually got it all behaving, complete with prompting the user to set up capabilities and suid behaviors, just had one system that defaulted one level lower apparently.
<dragorn> dapal: Yup, that solved it.  Thanks a ton, that sucked.
<dapal> dragorn: you're welcome :)
<doko> zul: irqbalance ftbfs, missing b-d on quilt?
<zul> doko: thanks ill look at it
<doko> zul: lp should have sent an email about that
<zul> doko: i might not have seen it
<Riddell> bdrung: bug 668671 has debdiff attached, please upload when you do the vlc update
<ubottu> Launchpad bug 668671 in phonon-backend-vlc (Ubuntu) "Amarok crashes with phonon-vlc backend " [Undecided,New] https://launchpad.net/bugs/668671
<doko> ScottK, Riddell: http://launchpadlibrarian.net/62146624/buildlog_ubuntu-natty-i386.poppler_0.14.5-0ubuntu3_FAILEDTOBUILD.txt.gz
<doko> rebuilt with gcc-4.6, could you add the missing include in the qt3 header file(s)?
<Riddell> doko: why do we still build libpoppler-qt2 ?
<Riddell> doko: no rdepends, probably we should just drop libpoppler-qt2
<doko> Riddell: ENOCLUE. it's still in main. demote it?
<doko> here's another qt3 issue: http://launchpadlibrarian.net/62153402/buildlog_ubuntu-natty-i386.scribus_1.3.3.13.dfsg~svn20081228-2ubuntu4_FAILEDTOBUILD.txt.gz
<Riddell> doko: is everything qt3 going to fail because of that?
<doko> Riddell: looks like so. unixodbc too. but again, this is gcc-4.6. although it would be nice to fix the headers, to look for further g++ related errors in these packages. mvo already fixed apt & libsigc++ headers
<doko> or wvstreams
<geser> gcc-4.6 is for natty+1?
<doko> geser: evaluating ...
<lifeless> bryceh_: we need the oops code ;)
<bryceh_> lifeless, too late.  I manually duped it.
<lifeless> bryceh_: in future, *always* give us the oops please
<lifeless> bryceh_: otherwise we can't tell if its the same cause or a new one etc
<geser> StevenK: can you promote gir1.2-gssdp-1.0 to main please? it's the successor of gir1.0-gssdp-1.0 which was in main. (or should I file a bug for it?)
<tgardner> ev, no joy. still crashes. Is there anything else you like to see?
<StevenK> geser: And source, or just 4 binaries?
<ev> tgardner: can you stick a set -x in the top of /usr/lib/ubiquity/user-setup/user-setup-apply, then run through it again and stick /var/log/syslog on pastebin?
<geser> StevenK: the source (gssdp) is already in main, one binary package got renamed (gir1.0-* â gir1.2-* transition) but it got put into universe instead of main (where gupnp is in DEPWAIT on it)
<StevenK> geser: Confirmed, and promoted.
<geser> thanks
<tgardner> ev, I do have a couple of kernel oops in the filesystem. that can't be a good thing.
<ev> heh
<tgardner> ev, lemme start it over and make sure I've a clean disk.
<ev> okay
<EtienneG> guys, just checking
<EtienneG> is it forbidden by policy for a maintainer script to change a conffile permission?
<SpamapS> EtienneG: IIRC maintainer scripts shouldn't touch conffiles unless it is removing an obsoleted conffile (one that is not in the newly installed version of the package)
<soren> And even then, only if it's unmodified.
<EtienneG> SpamapS, so an unconditional chmod in a postinst would be against policy?
<SpamapS> right, I keep wondering why that logic only exists in a copy/paste snippet in a wiki
<soren> I'm not sure policy specifically says so, but it would be against the spirit of it.
<SpamapS> EtienneG: yeah I'd think so.. the user may have set the permissions a certain way for a reason.
<EtienneG> because, if that's the case, then bug #697792 is indeed valid
<ubottu> Launchpad bug 697792 in fuse (Ubuntu) "permissions of /etc/fuse.conf are reset on upgrade" [Undecided,New] https://launchpad.net/bugs/697792
<EtienneG> I have been reading the policy, but it does not talk about file attributes (like permission), only the content
<EtienneG> nonetheless, gratuitous chmod of conffile should be avoided, I guess
<soren> EtienneG: "local changes must be preserved during a package upgrade, and"
<SpamapS> EtienneG: I would think that the proper place to do that chmod is in the package build, not maintainer scripts.
<soren> EtienneG: It doesn' really say contents or metadata.
<EtienneG> indeed
<soren> EtienneG: What are you trying to do?
<soren> Let's attack it that way.
<EtienneG> soren, see above cited bug
<soren> Oh.
 * soren pays attention
<EtienneG> but generally, I agree with the both of you, I just wanted to clarify with people more knowledgeable than me
<SpamapS> That file doesn't seem to be in the package
<SpamapS> oh ait, it is
<SpamapS> yeah the appropriate place is in the package
<SpamapS> EtienneG: marked as confirmed
 * SpamapS heads to meeting
<EtienneG> SpamapS, thanks a bunch
#ubuntu-devel 2011-01-14
<geser> pitti: Hi, I saw your blog entry about "check-mir". Is it much different than the existing "404main" script in u-d-t? Perhaps they can get merged.
<bdrung> pitti: why did you do three uploads instead of letting review someone your changes? the upload should have done to debian.
<hunger> Anyone looking into #176125 for natty? It was rejected for 8.04 saying that ipv6 was not widely used, but with world ipv6 day coming up that might change.
<virtuald> nat vs ipv6 is the real y2k
<\sh> hmm....unity is very strange regards to the use...updating from maverick to natty gives me a unity where I can't do anything...expect launching nautilus windows, a firefox + tomboy and workspace switcher...strange
<\sh> or I don't get it somehow
<Tm_T> <place joke about the simplicity and gnome here>
<\sh> Tm_T: I just need to poke jcastro about how to use it for real...;)
<Tm_T> I should try it again
<\sh> after dist-upgrade just now...it's broken
<davmor2> \sh: that'll be the default out of the box,  the app launcher from unity in une is still being worked on I hope at which point you will lose the nautilus application launcher you get when clicking on the ubuntu icon
<davmor2> \sh: you can at least add and remove apps from the launcher now though
<\sh> davmor2: right now, the launcher won't even be started
<\sh> (after update this morning)
<\sh> but I think it has something to do with compiz..because classical desktop doesn't show any window decoration, too
<davmor2> \sh: alt-ctrl-f1 and run unity --reset that might fix it for you
<\sh> let's try
<\sh> davmor2: no...it takes me to the console, yes...but I can't type in any characters the console isn't even updated (nvidia card here)
<\sh> ah
<\sh> no wonder
<\sh> unity is not installed anymore, it was removed because compiz-core-abiversion-20101111 is not installable
<\sh> so compiz is the bugger in general
<davmor2> \sh: yeap that would kill it
<\sh> but alas...metacity --replace doesn't work, too ;)
<davmor2> \sh: but you should be able to choose gnome classic from the login for now
<\sh> davmor2: sure...but even that doesn't work, because of compiz...I have to disable the effects somehow...but why does metacity --replace doesn't work..that's more strange
<davmor2> \sh: I don't have compiz-core-abiversion-20110113 installed either but I have unity up and running
<davmor2> \sh: now how ever it's died which isn't so useful for testing :)
<\sh> davmor2: hehe :)
<\sh> well it's an unstable release...so it's with purpose ;)
<davmor2> \sh: I'm safe I have yesterdays image on usbstick,  well you can't make an omelette without breaking a few packages or something like that :)
<\sh> davmor2: don't say that too loud...I have a complete redeployment to do over the weekend..more then 400 servers needs to get lucid and we do a complete FAI redeployment run, and trying to avoid downtimes...;)
<davmor2> \sh: they already broke that lucid package during it's dev cycle you should be safe now :D
<al-maisan> hallo pitti, quick question: will postgresql-9 be in natty?
<geser> al-maisan: unless something changed, no (I asked the same in the past)
<al-maisan> thanks geser !
<ricotz> cjwatson, hello, do mind having a look at https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/702765
<ubottu> Ubuntu bug 702765 in libgcrypt11 (Ubuntu) "Please update to libgcrypt11 1.4.6" [Undecided,New]
<pitti> almaisan-away: I'm not sure myself yet
<pitti> geser: probably just because the name didn't tell me anything :/
<micahg> ricotz: it's usually better to add a debdiff or a branch for merges from Debian to make sure there are no tarball mismatches and so it's clear what the diff from Debian is
<pitti> geser: I agree, they should be merged, I'll put that on my list
<ricotz> micahg, yeah, the debdiff would be https://edge.launchpad.net/~ricotz/+archive/staging/+files/libgcrypt11_1.4.5-2ubuntu2_1.4.6-2ubuntu1%7Ebuild1.diff.gz
<ricotz> micahg, i'll attach it to the bug
<micahg> ricotz: no, I meant between the Debian version and your merge
<ricotz> micahg, ok
<micahg> ricotz: that way the sponsor can grab the Debian package and just add your diff to it
<pitti> bdrung: ubuntu-dev-tools is in Debian? okay, I'll do that next time then
<e01|afk> hello, i am trying to compile smartcam driver, but getting error "smartcam.c:32:27: fatal error: linux/vmalloc.h: No such file or directory"
<pitti> bdrung: but that doesn't seem to work too well then? there were tons of changes which never got uploaded
<e01|afk> i have installed kernel headers, and kernel source
<bdrung> pitti: because two branches are waiting for review and merge.
<bdrung> pitti: you didn't gave me time to review your change.
<pitti> well, I wasn't aware that we are supposed to
<pitti> we don't do that for any other package in Ubuntu
<bdrung> pitti: did you build the package before uploading it?
<pitti> sorry if I broke the custom there, wasn't intended
<pitti> bdrung: sure
<pitti> bdrung: the test case failure didn't happen locally
<pitti> as I do have deb-src lines
<bdrung> pitti: we started to review our changes since some releases.
<bdrung> ok, so "check-mir --help" did the same as "check-mir"
<bdrung> pitti: you forgot to update d/copyright
<bdrung> pitti: and 2. can you add the examples from http://www.piware.de/2011/01/new-tool-to-check-support-status-of-dependencies/ to the man page?
<pitti> bdrung: ack, will do
<pitti> bdrung: but I'll probably just merge it with 404main
<pitti> and then update the manpage accordingly
<pitti> (see convesation with geser above)
<ricotz> micahg, done, thanks
<bdrung> pitti: ah, yes. this was my third point: only one script should stay
<pitti> bdrung: I'd like to keep check-mir as an alias, if you don't mind?
<bdrung> pitti: or we can drop 404main and use check-mir instead?
<pitti> I'll check out whether either is a superset of the other
<pitti> I think 404main works on Packages.gz while check-mir works in a source package tree
<pitti> (i. e. while you package something or do a merge)
<pitti> but it sholdn't be too hard to support both
<pitti> i. .e parse debian/control, or a package name from apt.Cache()
<bdrung> pitti: the man page should mention where the script takes the data from.
<pitti> *nod* (mine does, it says "source package directory")
<apw> pitti, natty seems to be asking to uninstall ubuntu-desktop and unity right now ... is that a transient or are we in trouble
<bdrung> pitti: where do the data about the archive come from?
<pitti> apw: known
<pitti> apw: seb128 and didrocks are working hard on it
<pitti> bdrung: apt
<pitti> (in both cases)
<apw> pitti, thanks
<bdrung> pitti: this should be documented in the man page
<pitti> bdrung: all added to my todo list now
<bdrung> thanks
<pitti> bdrung: (context, this came up as an important thing in this week's "how can we make MIRs suck less" report)
<pitti> s/report/meeting/
<bdrung> pitti: i need to have the apt sources for natty in my sources.list to get a correct report from check-mir, correct?
<pitti> bdrung: for now, yes
<cjwatson> ricotz: I'm not really familiar with libgcrypt11, sorry
<bdrung> pitti: for now? are there plans to change that?
<pitti> I was pondering using LP or apt, but the latter is a lot faster and works offline, and devs shold be using the release they are developing for anyway
<pitti> bdrung: I guess it depends on the feedback
<bdrung> pitti: at least this should be documented. :)
<ricotz> cjwatson, ok, you were the available person who touched it once ;)
<ari-tczew> ricotz: just subscribe ubuntu-sponsors
<ricotz> ari-tczew, already done this
<Riddell> skaet: do we hvae an archive admin meeting now?
<skaet> Riddell, yup, room 512
<Riddell> skaet: now or 10 mins?
<StevenK> I'm heading up now
<skaet> Riddell,   starting at 11:30.   Am in the room now.
 * skaet slaps head, she did it again,  its 514, not 512.  (room change....)
<skaet> ^^Riddell
<hallyn> just curious, does anyone else get a crash when they run 'cal' on their natty system?
<janimo> hallyn, I get a crash indeed
<hallyn> janimo: cool, not just me :)
<hyperair> when uploading an SRU of a package without any ubuntu changes, i.e. something like 1.2.3-4, what should the resulting version be?
<hyperair> also, if i want to upload pretty much the same version to both maverick-proposed and natty, should i just upload it to maverick-proposed and have it copied over to natty, or should i upload it to natty, mangle the version, and upload to maverick-proposed?
<geser> hyperair: 1.2.3-4ubuntu0.1 for the SRU, and I guess about a new upload to natty, don't know if AA do copies in that direction
<Laney> they do if the versions are the same
<Laney> oh, sorry, upload to -proposed only and it will be copied to N
<directhex> now running extended test of banshee on arm
<Laney> is that "Playing Pink Floyd â The Dark Side Of The Moon while dancing in my underpants"?
<kklimonda> Laney: they do? is it a standard practice, or something done only just after release, when there are some SRUs being pushed as soon as possible?
<Laney> kklimonda: It's standard when the versions are the same
<kklimonda> ok, thanks
<janimo> directhex, I have just commented on bug 619981
<ubottu> Launchpad bug 619981 in mono (Ubuntu Natty) "Banshee crashed while sitting idle on omap4" [High,Confirmed] https://launchpad.net/bugs/619981
<\sh> depwaits are rebuild automagically? or does someone have to give it back?
<StevenK> The former
<\sh> StevenK: timeframe? minutes or hours? ;)
<directhex> janimo, i'm seeing some other weirdness with audio - but i don't know who's to blame. possibly pulse... i'm gonna have to upgrade this thing to natty aren't i
<StevenK> The dependant package has to publish first and then it should notice in another hour or so?
<StevenK> I guess?
<\sh> StevenK: ok...just asking because unity is depwait on libdee and libdee was published 26 mins ago ...
<StevenK> libdee might be in universe
<\sh> StevenK: no it'sin main, at least that's what lp tells me ;)
<StevenK> libdee is the source name?
<\sh> StevenK: no...that's bin name, dee is srv name
<\sh> s/srv/src/
<\sh> dear puppet and drbd gods, please let my puppet recipe for drbd be correct
<janimo> directhex, I have heard of audio issues with banshee but did not look into it at all so far
<directhex> janimo, need to install another gstreamer player to see if it's isolated. persists between banshee restarts, so it's weird
<directhex> is exaile gst? i have that
<janimo> directhex, no idea, but I hope it does not have its own codecs :)
<directhex> hm, the file player i tried, parole, is file based. super weird.
<apw> pitti, am i expecting the unity/compiz issue to be untangled?
<apw> pitti, seems to have gotten worse here
<SpamapS> jdstrand: got a second to take a look at the updated cobbler copyright file?
<\sh> apw: unity ftbfsed
<pitti> apw: seems didrocks is uploading like mad, but the local mirror lag of course doesn't help a lot
<pitti> apw: for now I suggest to only use upgrade
<jdstrand> SpamapS: sorry, I was training someone
<hallyn> jdstrand: new vmbuilder version is in lp:~serge-hallyn/vmbuilder-staging/, and in people.c.c:~serge/public_html/vm-builder-0.12.4+bzr462-debs.tgz (has the .debs and the source)
<hallyn> jdstrand: no hurry at all, but when you get a chance could you sponsor that for natty?
<SpamapS> jdstrand: no worries.. its not been uploaed yet
<jdstrand> SpamapS: if you feel it is good, feel free to upload it. we can talk via irc if there is an issue (I really need the whole source)
<jdstrand> hallyn: ok
<hallyn> jdstrand: thanks
<james_w> SpamapS, hi, could you please run "bzr reconfigure --unstacked lp:~clint-fewbar/ubuntu/maverick/moin/merge-1.9.3-1" or delete the branch?
<james_w> SpamapS, I'm trying to delete the branch that it is stacked on and I can't
<SpamapS> james_w: certainly..
<SpamapS> jdstrand: ack .. will do
<SpamapS> james_w: done
<james_w> SpamapS, thank you
<SpamapS> james_w: any chance you can get sysvinit to not fail too? ;)
<SpamapS> http://package-import.ubuntu.com/status/sysvinit.html#2010-06-16 12:21:03.212483
<james_w> SpamapS, hmm, needs some investigation
<james_w> I'll try and escalate it in here
<SpamapS> james_w: is there any way I can help w/ stuff like that?
<jdstrand> hallyn: uploaded
<jcastro> robbiew: Debian meeting! :)
<robbiew> jcastro: yeah...yeah
<kees> jcastro: ooh, I can read your screen
<kees> jcastro: http://wiki.debian.org/Proposals/CopyrightFormat#DifferencesbetweenDEP5andSPDX
<pitti> dpm: hi! maverick ppa cronjob is currently disabled, would you know why we did that?
<pitti> dpm: we don't seem to have any in -proposed right now
<dpm> pitti, probably it was disabled during the testing period of the maverick updates we did recently and was never enabled back
<pitti> dpm: I re-enable them for now
<pitti> *nod*
<dpm> pitti, cool, thanks
<pitti> dpm: I rolled out danilo's po2xpi branch and added a switch to use the old one for lucid/maverick
<pitti> dpm: let's see how this goes
<pitti> dpm: I'll request a full export now, for a2
<pitti> and disable the automatic natty cronjob
<dpm> pitti, ah, cool. I haven't seen danilo since we spoke earlier on. Has his branch been merged into the mozillateam trunk?
<pitti> dpm: not yet, I checked out his branch for now
<dpm> ok
<pitti> cjwatson: my plymouth fix just made it to upstream trunk, so you can drop it if/when you do The Big Merge From Hell
<soren> The fact that we generally start daemons once they're installed (rather than asking users to enable them first)... Is that policy written down anywhere? I can't seem to find any reference (other than the dozens of packages we have that do it).
<StevenK> pitti: Ooooh, can haz diff?
<\sh> soren: which ones?
<pitti> StevenK: apt-get dist-upgrade?
<StevenK> pitti: I just wanted to see the code difference
<soren> \sh: Which ones what?
<\sh> soren: daemons
<pitti> StevenK: http://cgit.freedesktop.org/plymouth/commit/?id=f8874cb4b0725f605dc710cc845e6b5ff52ad539
<soren> \sh: Which ones we start by default? Um... Pretty much all of them? Apache, dovecot, ntp.. Which ones don't we start by default?
<pitti> StevenK: that wasn't actually the cause for the corruption, but it works around the gcc bug, and is a correct thing anyway
<StevenK> pitti: Crumbs, 2 line diff
<pitti> StevenK: as always, the patch is trivial once you found where to stab it :)
<\sh> soren: just asking, because services like tftp-hpa we don't start by default, or dhcpd ;)
<pitti> StevenK: https://bugs.freedesktop.org//show_bug.cgi?id=33129 if you are interested in details
<ubottu> Freedesktop bug 33129 in general "integer overflow in blend_two_pixel_values()" [Normal,Resolved: fixed]
<soren> \sh: dhcpd because there are no good, safe defaults.
<soren> tftp-hpa... I don't know.
<\sh> soren: but I agree, apache etc. should not be started by default until they are configured properly
<soren> I'm not saying they shouldn't.
<soren> At all.
<soren> I think they totally should be started by default.
<soren> If there are good, safe defaults I see no point in adding extra hoops to jump through.
<\sh> oh wow...my 7TB storage is syncing automagically after deployment...I won
<cjwatson> pitti: thanks
#ubuntu-devel 2011-01-15
<pitti> beer o'clock, have a nice weekend everyone!
<RAOF> pitti: https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+build/2153426
<hallyn> jdstrand: thanks!
<hallyn> now who killed my unity when i stupidly updated before going to the airport?  :)
<ebroder> soren: don't know off the top of my head, but i'd maybe check if debian policy has any section on init scripts?
<jzacsh> is this the correct channel to ask about packaging?
<lifeless> #ubuntu-packaging may be better
<jzacsh> lifeless: thanks
<lifeless> but many ubuntu folk have been in a face to face meeting and are now travelling hom
<lifeless> *home*
<lifeless> so right now is less likely than usual to garner helpful replies anywhere :)
<jzacsh> oh
<lifeless> (sorry!)
<jzacsh> well the present nicks in ubuntu-packaging is .. less than 20 it looks like
<lifeless> the few, the brave
<jzacsh> a lot of people here, though. should `dh_make -c gpl` be giving me "gpl3" in its output summary?
<jzacsh> is it reading the COPYING file, and intelligently deciding that i'm wrong?
<lifeless> I don't know ;)
<jzacsh> i'll try -packaging channel first :)
<jzacsh> lifeless: thanks
<jzacsh> anyone here know what the reason is that ubuntu doesn't use readline? (i _think_)
<psusi> jzacsh, what do you mean?
<jzacsh> psusi: hi
<jzacsh> psusi: in my archlinux installation, if i open mysql client or python interpreter, my inputrc seems to be properly inherited
<jzacsh> however, on any ubuntu machine its not. also, (pulling up bug...)
<jzacsh> psusi: you can see the video linked in this issue, for quirky behavior that only happens in ubuntu: http://drupal.org/node/877916  -- ... hmm... seems there was never a bug opened in launchpad for this.
<jzacsh> my fault, i'll do that now
<dgeary2> what needs to happen to get a program i wrote into ubuntu's universe repository? i have never contributed before.
<rickspencer3> hi dgeary2
<rickspencer3> I'm not the expert here, but I think generally you have 2 ways to go:
<rickspencer3> 1. find a motu to package for you
<rickspencer3> or much better
<rickspencer3> 2. package the application yourself, submit it to revu, and then have a motu accept it for you
 * rickspencer3 looks for link
<rickspencer3> dgeary2, here's your best bet for getting started with packaging yourself:
<rickspencer3> https://wiki.ubuntu.com/PackagingGuide
<JanC> rickspencer3: even better is to get it into Debian...  ;)
<rickspencer3> JanC, well, good point, I should have added that as option 3
<rickspencer3> :)
<jzacsh> Riddell: I actually just ran into a whole wiki page just explaining your options: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<Laney> Can a kind buildd admin please bump the score of ghc6? There seems to be a huge queue and it's been at '32 minutes' or thereabouts for hours now
<soren> ebroder: It does. I couldn't find anything about services being enabled by default or not.
<soren> ebroder: That was the first thing I checked: )
<soren> :)
<\sh> do we have somehow a keyboard shortcut list for unity? or any documentation on how about to use it?
<\sh> hmmm...
<penguin42> hmmm?
<\sh> I'm lost with unity and some shortcuts...Super key doesn't work somehow...
<\sh> xev tells me , that my superkey is not a superkey
<\sh> actually only in unity...classical desktop does it right
<bdrung> pitti: your response to bug #701282?
<ubottu> Launchpad bug 701282 in mpd (Ubuntu Maverick) "MPD lacks Mp3/LAME support in Ubuntu 10.10" [Medium,Triaged] https://launchpad.net/bugs/701282
<cjwatson> Laney: done
<ari-tczew> cjwatson: could you drop clementine from lucid-backports?
<ari-tczew> (NEW)
<cjwatson> what's the reason?  is there a bug I can read?
<ari-tczew> cjwatson: I forgot to open bug for backport request.
<ari-tczew> it's my upload, don't worry
<cjwatson> how'd it get into backports then? :)
<cjwatson> oh, you uploaded directly?
<ari-tczew> yes
 * ari-tczew is semi-drunk after yesterdays party.
<cjwatson> ok, rejected
<ari-tczew> cjwatson: thanks
<janimo> ogra, ping
<ari-tczew> cjwatson: could you again reject clementine? it needs more work
<cjwatson> ari-tczew: done, but I won't be around for much longer.  please delay a bit before pressing the upload button on it in future?:)
<ari-tczew> cjwatson: I just received feedback from upstream 5 minutes ago, really sorry.
<ari-tczew> cjwatson: rather before pressing enter for dput :>
<master> hi there
<hasenj> I don't know if this is appropriate here, but the latest kernel update killed the display on radeon video cards https://bugs.launchpad.net/ubuntu/+bug/703352
<ubottu> Ubuntu bug 703352 in Ubuntu "[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !" [Undecided,New]
<geser> cjwatson: sylvestre is asking for the PPU rights for some of his missing packages, I went ahead and compiled a list of missing packages, so you don't have to update his PPU rights to often. See https://lists.ubuntu.com/archives/devel-permissions/2011-January/000146.html
<bdrung> libwebkit and libwebkitgtk can't be installed side by side (the -common package conflict each other). is libwebkit deprecated and should libwebkitgtk be used?
<geser> bdrung: libwebkit-1.0-2 is NBS
 * bdrung will change the B-D for liferea
<cjwatson> geser: can you mail me about it?
<geser> cjwatson: you don't get the devel-permissions mailing list?
<ari-tczew> cjwatson: have you got upload access to ubuntu-desktop team branches?
<cjwatson> geser: I do, but if you want me specifically to act on something, mail me specifically
<cjwatson> ari-tczew: yes, but I'm in an airport
<ari-tczew> cjwatson: I'm asking because I'm preparing merge of system-tools-backends or something
<cjwatson> ari-tczew: I'm not going to commit to it from here - if you need me, you'll have to wait for Monday
<cjwatson> ari-tczew: otherwise, just propose a merge and wait foor a sponsor to pick it up.
<cjwatson> *for
<cjwatson> you don't need me specifically
<geser> cjwatson: ok, forwarded
<jjardon> Hello, I'd like to update some info about glade project in launchpad but I can't. What is the correct channel to get help about this?
<jjardon> I'd like to change the code import from git://git.gnome.org/glade3 to git://git.gnome.org/glade
<jjardon> but git://git.gnome.org/glade is already taken by the glade2 project
<jjardon> https://code.launchpad.net/~vcs-imports/glade-2.old/master
<ari-tczew> cjwatson: I'm pretty sure that you will be faster than ubuntu-desktop to commit it. It's nothing urgent so can wait for Monday.
<ari-tczew> cjwatson: don't you mind if I'll merge perl and sponsor by kees?
#ubuntu-devel 2011-01-16
<psusi> does anyone remember when the toolchain moved to gcc 4.5?  was it after alpha 1?
<penguin42> psusi: From my dpkg.log I'd say I 1st got it 12th December
<psusi> hrm... I be that bug is also what is causing unity to foul up when you right click on it and it tries to display the transparent menu
<psusi> that's about when it started doing that
<GreenRollup> DAMN GIRL. ELKY YOU IN THE DEVEL? well shoot. you have some sexy cards up your sleeve
<GreenRollup> how you doing maco?
<slangasek> SpamapS: restarting portmap doesn't seem to actually cause statd to be restarted (at least in maverick), because 'ON_BOOT=' doesn't match a job that doesn't have ON_BOOT as a variable at all... does this work in natty?
<GreenRollup> you know i head a dream
<GreenRollup> it was some sort of october get together at my school
<GreenRollup> and then nude 3d models were on the sc reen
<GreenRollup> and popcorn all over the place
<GreenRollup> then a shooter starting shooting us
<slangasek> GreenRollup: this channel is for Ubuntu development; please take your comments elsewhere
<GreenRollup> i was shot in the head by a second shooter because i was distracted by a bright light
<GreenRollup> ok
<akshatj> !offtopic ! GreenRollup
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<akshatj> !offtopic | GreenRollup
<ubottu> GreenRollup: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics (though our !guidelines apply there too). Thanks!
<GreenRollup> !bannedfromofftopic | akshatj
<slangasek> SpamapS: got it sorted - requires fixes on both the portmap and statd jobs (env ON_BOOT=; then an order of operations bug in the statd start condition.)
<aalex> I am a Debian maintainer. How can I file a bug to ask for a package's version to be more recent for the next Natty release? (the version at the freeze date contains bugs)
<bryceh> aalex, there is a requestsync script
<aalex> bryceh, in ubuntu-dev-tools ?
<bryceh> aalex, or just file a bug report at https://bugs.launchpad.net/ubuntu/+filebug - "Please sync foobar <version> from debian" against the appropriate package
<aalex> (I'm on Lucid right now)
<bryceh> aalex, yes, that's right
<aalex> bryceh, Or there: https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/toonloop/natty
<aalex> bryceh, $ requestsync -s toonloop natty    ?
<aalex> bryceh, given that GPGKEY=25DAAC75
<aalex> E: No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer.
<aalex> :-(
<aalex> E: Could not connect to fiordland.ubuntu.com:25: No route to host (113)
<nucc1> hi, i get this error while trying to build evolution http://pastie.org/1465981 . anyone know what I'm missing?
<geser> nucc1: install "dh-autoreconf" and "gnome-pkg-tools"
<nucc1> geser, thanks, i sort of guessed the gnome-pkg-tools one though :)
<geser> aalex: does the computer you run requestsync on have a working internet connection?
<aalex> geser, no
<geser> aalex: requestsync can either mail the bug report to Launchpad (with smtp) or file it directly (with http; LP API)
<aalex> geser, ok... how can I get it to work the easiest way?
<aalex> I never got reportbug to work either
<geser> aalex: can you run requestsync from the box you use right now for IRC?
<dupondje> gdm bit broken atm in Natty ?
<nucc1> "pbuilder-dist <release> build ../<package>_<version>.dsc" is there some way to make this command take advantage of multiple cpu cores?  it seems to be doing only one thread
<geser> nucc1: does the package support parallel building?
<nucc1> geser, i'm not sure, and i don't know how to find that out
<nucc1> when building from tarballs, i normally run make -j2 and that does the trick
<nucc1> the package is 'evolution'
<geser> nucc1: check the packaging if it does something similar
<nucc1> packaging?
<geser> the files in the debian/ directory
<geser> more specific debian/rules
<nucc1> geser, i could add -j2 to the #! /usr/bin/make -f on the first line?
<aalex> geser, no, I get that error E: Could not connect to fiordland.ubuntu.com:25: No route to host (113)
<aalex> geser, maybe I can change the server?
<geser> nucc1: don't know if that would work
<nucc1> if it supports parallel building, what would i have found in the file?
<geser> nucc1: packages supporting it, check the value of "parallel" from the DEB_BUILD_OPTIONS env variable and use this for -jX
<geser> aalex: you can use DEBSMTP to specify a different smtp server
<aalex> geser, ok. thanks
<geser> aalex: what about the patch the Ubuntu package of "toonloop" has? and I've tried to build 2.0.4 in Ubuntu natty and it fails to build
<aalex> geser, does it need libboost-system, maybe? I fixed it upstream... need to test it on natty first I guess.
<aalex> geser, I can use pbuilder for that on a maverick box?
<geser> aalex: yes, you can setup a natty pbuilder on maverick
<aalex> geser, I'll make sure to test it on natty first, next I'll upload it to debian, and then ask for the sync
<aalex> (I'm also upstream)
<geser> aalex: the error is "configure: error: libstk is not installed: alsa"
<aalex> oh
<geser> aalex: http://paste.ubuntu.com/554658/ (from config.log)
<geser> the problem is the "-lstk" before the conftest.cpp; this order doesn't with "ld --as-needed" anymore. You should be able to reproduce this with "binutils-gold" in Debian
<aalex> geser, But libstk0-dev is on natty too. http://packages.ubuntu.com/natty/libstk0-dev
<geser> aalex: not the build-dependency is the issue, but configure.ac; you put "-lstk" into LDFLAGS instead of LIBS
<aalex> geser, is there a patch?
<geser> give me a minute
<aalex> geser, great :)
<geser> aalex: http://paste.ubuntu.com/554663/ is needed to get past configure and to start building
<nucc1> geser, is there a shorter means to testing the changes i've made to a package? having to build a .deb and install is quite a long process
<geser> aalex: but it fails later with a linking error about boost_system
<aalex> geser, yeah... that's fixed in both upstream and the ubuntu package
<aalex> here is my fix: http://github.com/aalex/toonloop/commit/750bd649c12e4e23c768b8eec602c950c5af3858
<geser> nucc1: not that I know of if you change source code (ccache might speed up the compilation)
<aalex> geser, so, I should put "-lstk" in LIBS, not LDFLAGS?
<geser> yes
<geser> with "ld --as-needed" (which natty uses by default) the linking order matters: a library gets only linked in when an object file *before* it on the command line uses one of its symbols
<aalex> oh
<geser> if you put "-lstk" into LDFLAGS it gets put before the object file (here: conftest.cpp) while LIBS are put after it by configure
<aalex> geser, http://paste.debian.net/104729/ ?
<geser> yes
<aalex>  geser: thanks a lot! I'll make a new upstream release and try it on natty later on.
<aalex> this could have been done with quilt, but anyways... I'm also upstream, so let's use it.
<geser> bryceh: if I try the new X stack from xorg-edgers, can I keep updating from it once it landed in natty or will I have to manually "upgrade" to the official packages?
<nucc1> geser, how can i build the associated dbg packages?
<geser> evolution-dbg? this one you should get automatically as it's part of the package building process
<nucc1> yea, i can't find it in the pbuilder directory where the .deb packages are
<nucc1> ah, seen it.
<aalex> geser, Fixed and released: http://github.com/aalex/toonloop/commit/cce7f7d4f346c47ddbf9c2e07c6aeac92bea6341
<aalex> later,
<geser> nice :)
<grnd44> greetings. I noticed the async initramfs patchset has been shipping in U for several releases; could you enlighten me on why it's not upstream?
<kaydsoft> Hi ..... would anyone who happens to be workin on natty answer this question .... what is the default python interpretor on natty .... zit 2.x ow 3.x?
<kaydsoft> or am I askin the question in the wrong place?
<\sh> kaydsoft: 2.x
<kaydsoft> <\sh>
<kaydsoft> when will u start support for
<kaydsoft> 3.x
<\sh> most likely when most of all python packages do support 3.x ? more infos can doko give you when he's awake or back from dallas i think
<kaydsoft> k thsnx
<\sh> kaydsoft: but python 3 is also in the archives...and some of the packages are building already python3 bin pkgs
<\sh> afaik...I'm not focussing on py3 right now
<kaydsoft> k
<kaydsoft> so I should tka my focus fwom py3
<kaydsoft> n settle for py2
<kaydsoft> ?
<\sh> kaydsoft: depends on you? :)
<kaydsoft> k
<pavolzetor> hi, why my program reports tihs?
<pavolzetor>  ./xml_parser rss.xml Cannot connect to destination (127.0.0.1)
<pavolzetor> It is written in vala
<pavolzetor> I have ubuntu natty
<pavolzetor> this works http://localhost:59693/_utils/index.html
<slangasek> SpamapS: so now that statd is sorted, I'm trying to work out bug #643289 as well for idmapd... maybe you see an easy way out of this that I've overlooked :)
<ubottu> Launchpad bug 643289 in nfs-utils (Ubuntu) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289
<cxo> There is a "liblastfm0" package provided on ubuntu. Its the (now) official last.fm backed library that uses Nokia QT. I wrote a lastfm library in pure C and I want to package it for Ubuntu. What do i call it?
<cxo> Oh do i need to be in #ubuntu-app-devel?
<Tm_T> cxo: you mean Qt?
<Tm_T> cxo: and you can call it anything you like, as long as it's not "liblastfm"
<cxo> How annoying
<cxo> I wonder if i asked nicely if they would rename theirs to libqt-lastfm
<cxo> So I have no idea what to call it now. Any suggestions?
<Tm_T> liblastfm-c (;
<cxo> liblastfmlib
<Tm_T> or to be witty, "libfirstfm"
<cxo> I remember there used to be a taglib and a libtag., once upon a time
<Tm_T> taglib package is called libtaglib (lib prefix for library package)
<Tm_T> or something
<cxo> The reason i wrote my own implementation is because having to pull in qt for just one silly lib is such drag for people who use gnome
<cxo> http://liblastfm.sourceforge.net/
<cxo> I have the name on launchpad actually
<cxo> Tm_T, in terms of packaging. Can i include a "breaks:" param in the control file to say its not compatible with the other library?
<Tm_T> err, I see no point having it to break the other library
<Tm_T> actually, you have to make sure it doesn't break it
<cxo> Is there an easy apt-trick way to find out which apps in the repo actually use that library?
<Tm_T> apt-cache rdepends liblastfm0
<cxo> So its basically used for one QT/KDE app - Amarok
<cxo> No surprising. Unless you're writing a QT app, no point on using that library.
<cxo> s/No/Not/
<Tm_T> still you must avoid breaking it, installing your library should never break other apps unless it's absolutely necessary
<cxo> Yeah. I'm going to ask them to change their library name to reflect the toolkit bias
<cxo> Thanks for the help
<Tm_T> np
<cxo> I heard that banshee is going to be replacing rhythmbox in 11.04. Is that true?
<micahg> cxo: I think it's already done
<cxo> Does this now make mono an "essential" package?
<micahg> cxo: no, we use seeds for defaults not essential
<cxo> Sorry, what does that mean?
<micahg> cxo: there's a file used to generate the dependencies for ubuntu-desktop
<cxo> So I'm guessing the majority of ubuntu users are now using banshee, thats why the switch?
<micahg> cxo: not necessarily, but it was decided at UDS to switch to it as the default music player
<cxo> hmm
<cxo> What do you use?
<micahg> cxo: I use Xubuntu, but I also use banshee
<cxo> Oh interesting. Don't like Amarok?
<micahg> cxo: Dropped it a while back when I needed ipod support
<cxo> It would be nice to have something like libipod (or whatever its called) hooked into nautilus, so every media player doesnt have to duplicate the code
<micahg> cxo: there's libgpod
<cxo> If you're not too busy, I'd like to see what banshee looks like on Xubuntu. Can you post a screenshot?
#ubuntu-devel 2012-01-09
<pitti> Good morning
<ajmitch> morning pitti
<sladen> morning
<cyphermox> good morning
<ev> hiya
<geser> good morning
<pitti> ev, cjwatson: I've got working GI bindings for libxklavier yesterday; I submitted them upstream, but if you want to work on it soonish, I can create a PPA for you if you want?
<pitti> ev, cjwatson: that's for bug
<pitti> bug 800561
<ubottu> Launchpad bug 800561 in libxklavier (Ubuntu Precise) "No way to add other keymap than english on Live CD" [High,In progress] https://launchpad.net/bugs/800561
<ev> pitti: cheers! I'm happy to wait for it to land in the archive, given that we shipped 11.10 without it
<pitti> ev: upstream already responded yesterday, I hope it'll land RSN; but in case you want to play around with it, I wanted to tell you
<ev> thanks
<mpt> mvo, hi, is robert_ancell around? I'd like to talk with you when you're both free, about recovering from failed upgrades
<mvo> mpt: I check the desktop room
<pitti> mpt: in the desktop room here
<mpt> Hi robert_ancell, are you or mvo on Skype? Or else Mumble?
<robert_ancell> mpt, we can mumble
<robert_ancell> mpt, mvo is busy at the moment, do you want both of us?
<mpt> robert_ancell, ideally.
<robert_ancell> ok, we'll call then
<mpt> thanks
<robert_ancell> (in 15 mins)
<mpt> ok
<cjwatson> pitti: that's great, thank you - what ev said
<mvo> mpt, robert_ancell: I'm ready now, sorry for the delay
<mpt> mvo, robert_ancell was just on Mumble but then left
<mpt> robert_ancell, phone call instead?
<mpt> mvo, sorry, I'm not hearing what you're saying
<mvo> mpt: not hearing at all or in bad quality?
<robert_ancell> mvo, now your mic is stuck on
<mpt> mvo, you sound like a MIDI keyboard
<mvo> mpt: I think we need both, at startup and at the installer level
<mpt> mvo, ok
<mvo> mpt: as the startup maybe in susch a bad shape that it can not recover from the installed system
<mpt> mvo, robert_ancell: So would the UI for the startup variant be inside Plymouth?
<robert_ancell> mpt, I would have thought it would be in grub or failsafe-x
<mvo> we have support in friendly-recovery for recovering from a broken upgrade, but the UI is certainly lacking :/
<mpt> Is it a console UI?
<mvo> yes
<mvo> text ui
<mvo> not even progress bars
<mpt> ok
<mpt> If they were both implemented, would the startup and installer-based recovery systems share code at all?
<mvo> that is a interessting question, it depends on how we do it - but I would image that the installer-based on is very much apt-clone based. I haven't put much thought into how it would be done on startup, but there are certainly area where code can not be shared, like the UI in ubiquity would be different etc
<mpt> mvo, that question was mainly about whether it should be one or two specifications :-)
<mpt> mvo, robert_ancell: so, I'll do sketches for both a Ubiquity-based UI and a console-based UI
<robert_ancell> mpt, ok, so mvo and I talked here and we think you probably just need an ubiquity UI and a software-center UI
<mpt> robert_ancell, why would it go in USC?
<mvo> mpt: and the software-center UI we have (the rapair broken catalouge)
<robert_ancell> mpt, so ubiquity is used for severe corruption cases, and software center for minor breakages (e.g. flash)
<robert_ancell> The stuff we covered at UDS (https://wiki.ubuntu.com/GracefulFailure) is more about detecting failure and notifying the user as opposed to necessarily fixing the problems
<mvo> the console based one would fall right into the middle of this so its probably not worth the effort
<mpt> ok
<robert_ancell> and it's not clear which part of the boot would be able to detect the failure (without side effects of slowing boot) and launch such a console UI
<mvo> for the console UI you would have to have a work kernel, python at least
<seb128> mvo, bug #913719
<ubottu> Launchpad bug 913719 in update-manager (Ubuntu) "gets confused by packages in the dpkg "in" state" [Low,New] https://launchpad.net/bugs/913719
<mvo> thanks seb128
<seb128> mvo, thank *you* ;-)
<mpt> mvo, how long would it take to go through the available partitions on a typical PC, and detect that one of them was a broken Ubuntu installation? Seconds? Minutes?
<mvo> mpt: ev will be able to answer this better, but I think second
<mvo> s
<mpt> ok
<ev> answered out of band
<pitti> cjwatson: are you aware of any recent changes in the live system build? desktop CDs are now 21 Mb oversized, and I think last week they were at 705 MB; but the alternates did not grow, so iso-deb-size-compare won't work
<pitti> cjwatson: hm, then again the health check from an hour ago still says
<pitti> ubuntu/daily-live: precise-desktop-amd64.iso oversized by 5550080 bytes (739553280)
<pitti> so maybe I mix it up with that (wrong?) number
<cjwatson> pitti: not that I know of
<Riddell> pitti, cjwatson: is there a tech board meeting today?
<cjwatson> Riddell: good question, I guess it depends on what the schedule in Budapest is like
<pitti> I guess I can make it
<pitti> who is chairing today?
<pitti> ah, mdz
<MacSlow> pitti, ping
<pitti> MacSlow: hey
<MacSlow> pitti, hey... I just switched to precise on my laptop and not compiling libunity it complains about missing "/usr/lib/i386-linux-gnu/libgio-2.0.la"
<pitti> MacSlow: right, .la files are gone; we don't need them, they only cause unnecessary extra dependencies
<MacSlow> pitti, it's form some part of the linker-work during make... I was wondering if there might be an issue with the packages on precise
<MacSlow> pitti, so what's needed on my side now to make the "make" work again?
<pitti> MacSlow: it might come through a library in between, though; perhaps you can pastebin the last couple of lines of build log?
<pitti> i. e. a faulty .pc file of a library package
<MacSlow> http://pastebin.ubuntu.com/798218/
<pitti> MacSlow: seb128 is coming over to you
<pitti> MacSlow: most probably you have a local broken /usr/local/lib/*.la
<MacSlow> pitti, cool... seb128 thx :)
<barry> ScottK: re: "port to qt" - not sure either, but mvo mentioned it when we chatted.  that was mostly just a placeholder.  if it's available upstream, pending packaging, that's much better
<ScottK> Cool.
<barry> thanks for following up on the blueprint
<ScottK> I played with it a little and it's not 100% straightforward to package, but I think it's doable with a bit of fiddling.
<barry> do you have a branch or other code i can start with?
<ScottK> No.
<barry> k
<ScottK> I'd start with pykde4 in precise.
<barry> yep
<ScottK> barry: The one thing that's not just coercing it to build is figuring out what to do about /usr/lib/kde4/kpythonpluginfactory.so.
<ScottK> Although with the .so name munging in python3, maybe it's OK.
<barry> ScottK: right, it would end up being kpythonpluginfactory.cpython-32mu.so so it shouldn't conflict *although* the import machinery might get confused if they both exist
<ScottK> That would be the tricky part.
<ScottK> Will python3.2 prefer a munged name over an unmunged one?
<ScottK> If it will, it should be ~fine.
<barry> ScottK: i'm checking the source now :)
<ScottK> Cool.
<barry> ScottK: yep, module.soabi.so gets found before module.so, so we should be good (glad i did the right thing and/or used the time machine keys)
<ScottK> :-)
<ScottK> Then it's probably just a matter of build-deps and beating cmake into submission.
<l3on> doko, I looked at libkml, but your patch introduced in bug debian #650525 does not work
<ubottu> Debian bug 650525 in libkml "ld-as-needed patch needs an update" [Normal,Open] http://bugs.debian.org/650525
<l3on> can you help me to understand wath's wrong? :)
<l3on> *what
<barry> cool, now it's in the whiteboard so i'm on the hook :)
<ScottK> Excellent.
<tjaalton> slangasek: got a multiarch-related bug for you, not sure where to put it, bug 874143
<ubottu> Launchpad bug 874143 in libpciaccess (Ubuntu) "package libpciaccess0 0.12.1-2 failed to install/upgrade: ErrorMessage: libpciaccess0:i386 0.12.1-2 (Multi-Arch" [Undecided,New] https://launchpad.net/bugs/874143
<tjaalton> slangasek: so apparently the non-native version of the package got installed before the native one got upgraded
<tjaalton> see the end of apttermlog
<doko> l3on, to reproduce it yourself, you could try to build in a oneiric or precise chroot (debootstrap sets it up for you). do you package a new upstream version?
<l3on> doko, no. I have grabbed merge from debian
<doko> l3on, build log?
<l3on> lost, wait a bit, I'm going to rebuild it
<trism> Is there a reason the debug dbus-daemon binary is installed to /bin? (in both oneiric and precise)
<l3on> doko, http://debomatic64.debian.net/precise/pool/libkml_1.3.0~r863-3ubuntu1/libkml_1.3.0~r863-3ubuntu1.buildlog
<l3on> the current debian package has your patch on board
<doko> l3on,  ../../src/kml/engine/libkmlengine.la ../../src/kml/regionator/libkmlregionator.la
<doko> exchange these two
<slangasek> tjaalton: this is bug #835625
<ubottu> Launchpad bug 835625 in apt (Ubuntu Oneiric) "apt may try to unpack a foreign-arch multiarch library before the native package is at a multiarch version, prohibited by dpkg" [High,Fix released] https://launchpad.net/bugs/835625
<tjaalton> slangasek: cool, thanks, I'll dupe it then
<slangasek> tjaalton: I don't think we're going to backport to 11.04 apt though, because we weren't provisioning multiarch for users in 11.04
<slangasek> tjaalton: so you've been hit by this problem by being an early adopter only
<tjaalton> slangasek: nah it wasn't me, just was going through the bugs against libpciaccess
<slangasek> tjaalton: ok
<semiosis> When/how often does Ubuntu sync from debian unstable?
<cjwatson> This cycle we've been syncing from testing, not unstable
<cjwatson> We just stopped doing so today
<cjwatson> For the first half or so of a release cycle, the sync is roughly daily
<semiosis> cjwatson: when you say stopped doing so... does that mean you've stopped debian syncs altogether or have switched to unstable?
<semiosis> here's my issue, i work with the debian maintainer of the glusterfs project and we just committed a patch that enables the latest version to build.  i'd like to see that latest version included in 12.04.  should I now file a syncrequest?
<ScottK> Yes.
<cjwatson> semiosis: We stop syncs for the second half of every Ubuntu release cycle
<cjwatson> But just the automatic ones - you can still request them
<semiosis> ah ok.  thanks i'll do that.
<cjwatson> So yes, file a sync request if you want it
<semiosis> one more thing... the debian package glusterfs-server includes an initscript, but that causes a bug on ubuntu beucase of upstart/mountall.  i've contriubted an upstart job to the upstream project, but since debian doesn't use upstart, its not in the debian package.
<semiosis> so i'd like to add a merge to ubuntu to add the upstart job to the glusterfs package in ubuntu
<semiosis> does that sound right?
<ScottK> Yes.
<ScottK> Althoguh upstart is in Debian, so there's no reason it couldn't be added there too.
<cjwatson> upstart jobs are a fairly common source of divergence at the moment though, so *shrug*
<semiosis> afaik including an upstart job in the debian package adds a requirement on upstart-job, which causes install to break on debian boxes
<cjwatson> you wouldn't be the first
<cjwatson> depends on how you do it ... but yeah
<trism> When I say debug dbus-daemon, I don't mean unstripped, I mean, has the DBUS_BUILD_TESTS sections enabled. It is copied twice in the build logs, once from build/bus and then overwritten by build-debug/bus
<l3on__> doko, â http://debomatic64.debian.net/precise/pool/libkml_1.3.0~r863-3ubuntu1/libkml_1.3.0~r863-3ubuntu1.buildlog
<l3on__> cp: cannot stat `debian/tmp/usr/share/java': No such file or directory
<semiosis> cjwatson, ScottK: thanks again!
<stokachu> slangasek: I was looking into bug #858122 comment #45 and didn't see anything related in the bazaar revisions that would relate to this. I see wfink has been doing most of the commits would he be able to provide some status on that bug?
<ubottu> Launchpad bug 858122 in sysvinit (Ubuntu Precise) "incomplete migration to /run (shutdown script order has been demolished)" [High,Triaged] https://launchpad.net/bugs/858122
<stokachu> slangasek: if nothing has been done I dont mind picking it up and looking into i
<stokachu> it*
<slangasek> stokachu: wfink is upstream for insserv, he wouldn't have any input on this as it's entirely a distro integration question
<stokachu> ah
<stokachu> i may be looking at wrong package in launchpad then
<slangasek> stokachu: the main thing to do be done is to move insserv off the system path, I believe
<slangasek> stokachu: I think you're looking at an import of the upstream source rather than at the package
<stokachu> ok, so we are thinking move it off system path then help pkg maintainers to fix their packages?
<stokachu> or just provide a technical release note of some sort
<slangasek> which package maintainers do you mean?
<stokachu> these would be 3rd party like turboprint who calls insserv directly
<slangasek> does turboprint call insserv unconditionally, or only if detected?
<stokachu> good question I'd need to get their source packages and look into it
<slangasek> FWIW I wasn't planning on doing any work to fix third-party packages; they're using a non-standard interface, and stopping that interface from being available fixes the critical bug
<stokachu> ok sounds good
<stokachu> slangasek: would I be wrong in suggesting upstart replace/conflict: chkconfig, insserv?
<stokachu> upstart already replaces sysvinit so why not go a bit further
<slangasek> stokachu: I don't know that the chkconfig package is incompatible, is it?  And as for insserv, upstart itself doesn't conflict with insserv at all, and in the long term I actually think we will be using insserv for bridging upstart and sysvinit dependency information
<slangasek> stokachu: so I'd really prefer that we just shunt insserv to a different directory and not diverge from Debian's initscripts package for this
<stokachu> ok
<stokachu> ah yea so update.rc-d uses insserv... i think chkconfig calls insserv directly though, i need to research that more
<cjwatson> mvo: so for https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-lts-upgrades, the way I did this for previous releases was to copy .debs into dists/$CODENAME/main/dist-upgrader/binary-$ARCH/ on the CD - will that still work?
<mvo> cjwatson: it should, yes
<cjwatson> cool, that should be easy then
<mvo> cjwatson: let me know once its there and I will a) re-enable my old code b) test ;)
<Riddell> mdz, pitti, cjwatson: well I need to go out, if there is a tech board meeting I can get home for it fine but please text message me 20 mins before
<Riddell> jriddell.org/contact.html
<mdz> Riddell, I'm expecting to have a meeting; is there talk of canceling it?
<mdz> there is content on the agenda
<ScottK> mdz: It looks like last meeting's content though. I think PAE kernel is done.
<ScottK> PAE/non-PAE
<Riddell> mdz: there's no agenda made and pitti and cjwatson weren't sure if it was happening
<mdz> ScottK, Riddell, two items were just added today
<Riddell> ok I'll assume Kubuntu LTS is being discussed and be back in time for it
<arges> broder, hello. does your backportpackage script allow for first backporting a dependency and then feeding that to backport the original package? or is this something I need to set up in pbuilder? thanks
<psusi> cjwatson: since partman makes an extended partition for you anyhow, why doesn't it just put the root filesystem inside it as well, instead of only the swap partition?
<cjwatson> psusi: Because many BIOSes will refuse to boot if you have no primary partitions at all.
<funkyHat> re. the new version of gnutls (https://lists.ubuntu.com/archives/ubuntu-devel/2012-January/034629.html)... surely LGPLv3+ allows use in GPL2 projects? Surely that's the point of the LGPL (well not specifically GPL, but other licenses, including closed source ones)
<psusi> cjwatson: ahh, so makes sense if you chose the option to use the whole drive, but when installing along side windows...
<cjwatson> psusi: Then it will use logical partitions for both.
<psusi> cjwatson: hrm... from what I've seen it still puts the root in a primary and only swap in logical
<cjwatson> psusi: Happy to look at a partman log, but it's not supposed to do that in general.
<cjwatson> funkyHat: I'm afraid that's not the way it works
<psusi> cjwatson: good to know... will file a bug report with the logs if I see it again
<cjwatson> funkyHat: you can google for "lgplv3 gplv2 compatibility" for instance ...
<cjwatson> funkyHat: http://gplv3.fsf.org/dd3-faq has a compatibility matrix
<funkyHat> cjwatson: thanks. I'll have to re-read the licenses to try to understand why...
<cjwatson> funkyHat: if it helps, the reason for the incompatibility is in the terms of the GPLv2, not in the terms of the LGPLv3
<funkyHat> cjwatson: yeah I found a couple of bits relating to samba that said that. I didn't realise GPLv2 was that restrictive
<cjwatson> funkyHat: GPLv2 says "must distribute under terms of GPLv2 with no additional restrictions" and LGPLv3 has a couple of additional restrictions over GPLv2
<cjwatson> IIRC
<cjwatson> there's the system libraries exception, but we don't get to use that when we're distributing both library and thing-that-uses-library
<funkyHat> So GPLv2 software can't link with libraries under *any* license that is more restrictive than the GPLv2 (with the exception of standard system libraries, apparently)
<cjwatson> right (and even then only if distributed separately from those system libraries)
<funkyHat> I suppose because I've seen GPL software released for Windows I assumed it was ok to link with anything, where in fact it's only ok because of the system libraries exception
<cjwatson> this is also the reason the GPL is incompatible with the OpenSSL licence
<cjwatson> funkyHat: yes
<cjwatson> my understanding is that Microsoft would not be permitted to distribute GPLv2 software together with Windows, although I haven't previously thought about this :)
<cjwatson> I understand that the GPLv3's system libraries exception is broader; I haven't checked how it would work in such a hypothetical situation
<cjwatson> GnuTLS could solve this using an LGPLv3/GPLv2 dual licence, if they wanted to: http://www.gnu.org/prep/maintain/maintain.html#Licensing-of-GNU-Packages
<pitti> nnnn
<StevenK> mmmm
<pitti> oops, sorry
 * ScottK thought bug numbers were up to nnnnnn.
<StevenK> Soon it will be nnnnnnn. :-(
<ScottK> Yep.
<pitti> is there a prize for filing bug #1e6?
<ubottu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<ScottK> That should be "on desktops"
<ScottK> They've got ~5% on smartphones.
<trism> pitti: I think the --exec-prefix=/ is in the wrong spot in the dbus package rules, it is overriding the --prefix flag on the test build, so those binaries are overwriting the main ones (sorry if you're the wrong one to poke, I just notice you did the merges)
<pitti> trism: not sure that I follow -- the package seems to be fine, it ships dbus-daemon and some tools in /bin, as it should?
<pitti> --prefix /usr is actually intended, as we want manpages, pkgconfig, include files and whatnot in /usr
<cjwatson> the claim earlier today was that /bin/dbus-daemon (IIRC) was from the debug build pass rather than the regular one
<stgraber> pitti: around?
<trism> pitti: if you look at the build log, the dbus-daemon is copied twice to debian/tmp/bin, once from build/bus and again from build-debug/bus
<mdz> stgraber, kees, pitti, cjwatson, soren, TB in 5
<trism> pitti: so we get the one with all the DBUS_BUILD_TESTS sections enabled (the binary is twice the size of the one in debian)
<mdz> ish
<cjwatson> yep
<pitti> mdz: o/
<pitti> trism: ah, I see
<pitti> trism: have a meeting now, would you mind filing a bug about it? (or just mail me, but bug is nicer for tracking)
<trism> pitti: sure, I'll file a bug
<pitti> trism: thanks!
<broder> arges: backportpackage can't do that for local builds, but you could upload to a ppa - packages in a ppa can depend on other packages in a ppa
<arges> broder, awesome., i'll give that a try then
#ubuntu-devel 2012-01-10
<L-----D> hi, I'm a java/c# developer, I want to start Unity2D QT dev, where can I start?
<Chester> hola
<Chester> alguien por ahi?
<Chester> hay alguien?
<JuN1x> Chester: Este canal es en ingles
<Chester> some one are there?
<JuN1x> Chester: this channel is for developing
<Chester> i have a question abaut ubuntu, some one can help me?
<JuN1x> Chester: try with #ubuntu channel
<Chester> ok, thx
<JuN1x> here is offtopic
<slangasek> bdmurray: bug #913947 is french for bug #545790
<ubottu> Launchpad bug 913947 in dpkg (Ubuntu) "package libkadm5clnt-mit7 1.8.1+dfsg-2ubuntu0.10 failed to install/upgrade: erreur lors de l'Ã©criture de Â« <sortie standard> Â»: SuccÃ¨s" [Undecided,New] https://launchpad.net/bugs/913947
<ubottu> Launchpad bug 545790 in dpkg (Ubuntu) "package PACKAGE failed to install/upgrade: error writing to '<standard output>': Success" [High,Triaged] https://launchpad.net/bugs/545790
<pitti> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-power-consumption has a WI "Investigate blktrace for reporting issues with excessive disk wakeups" -> it seems you already did that? yesterday I overheared you mentioning it when talking to Chris
<slangasek> pitti: so, I've certainly been using blktrace locally, but its output isn't very consumable for end users
<pitti> cking: just read through your power notes; this is great work!
<cking> pitti, thanks! It's still "work in progress" but I've covered 80%+ of the low-hanging fruit
<pitti> with that it almost seems to me that we should implement the proposed changes first, before sending bigger calls for sending bugs (as there will probably be many dupes)
<pitti> cking: ^ or do you think that would still be useful at this time?
<cking> pitti, yes, there are a load of bugs filed that should be fixed which generally look quite trivial which will give us a sufficient win
<cking> ..and then we can move into phase 2 to ask for users to identify rouge processes for the ones we missed
<pitti> cking: agreed, sounds good to me; want me to look into some of the bugs?
<pitti> cking: are you already working on the pm-utils ones, or want me to help out there? otherwise I'd start with the ubuntuone bug
<robert_ancell> cnd, do you know the best way to provide a patch to the linuxwacom project?
<cnd> robert_ancell, no, I've never touched that project
<cnd> you may want to ping whot on #xorg-devel
<robert_ancell> cnd, thanks
 * cnd is afraid to look at that project
<\sh> hmmm..did anybody ever saw this error: init: udev-fallback-graphics main process (...) terminated with status 1 and then failing to boot?
<ogra_> SpamapS, jodh .... we were just discussing serial consoles in the arm room and i remembered bug 702574, how about we upload the fix before final release ?
<ogra_> ;)
<ubottu> Launchpad bug 702574 in upstart (Ubuntu) "getty should be started automatically on serial port when serial console is set on kernel command line" [Wishlist,New] https://launchpad.net/bugs/702574
<Sweetshark> doko: could you complete/fixup the arm-patch? _rene_ is already reverting this out of upstream with http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=patches/revert-468fe685e3c58c84bce6d9a48b931dcc21682679.diff;h=7b9f67c5dbb85c7f2633234ea40c1226e8d96815;hb=0f0bc4431463d26b45df01995d68c781d87712aa
<doko> Sweetshark, no, -> janimo and/or NCommander
<ogra_> doko, Sweetshark, NCommander is currently (like right now) hacking on it (though at this very moment he is in a meeting)
<Sweetshark> ogra_, doko: thx
<NCommander> Sweetshark: I'm staring at the ARM code right now to try and figure out where in UNO we are breaking in hardfloat
<NCommander> I *think* we're getting through the trampolines into at least cpp_vtable_call, but I'm not sure where we're getting back that
<NCommander> (gdb really hates UN)
<NCommander> *UNO
<NCommander> *getting broken past that
<NCommander> (I think we're exploding in cpp_meditate now that I got my fprintf's in the right places
<micahg> cjwatson: was just wondering if you were planning on uploading xubuntu-meta for the linux-headers change or if I should plan to do that later
<cjwatson> micahg: I can do that
<micahg> cjwatson: ok, thanks
<cjwatson> it wasn't urgent or anything, just cutting down on CD size a bit
<micahg> sure, our alternate is oversized as well
<YokoZar> Is the â character allowed in package descriptions?
 * YokoZar thinks he might just try it and see if Lintian complains
<ogra_> YokoZar, iirc as long as its utf8 it will just work
<cjwatson> YokoZar: anything UTF-8 should be allowed, yes
<YokoZar> cjwatson: I wonder if a package description with stars in the wrong place could mislead about its rating ;)
<sveinse> I'm trying to install some packages to a staging directory. I'm using apt.conf setting RootDir to prefix root into the staging directory. apt-get update downloads the indexes, but at the end it fails as it tries to access the system's /var/lib/dpkg/lock, despite the RootDir setting. I suspect a bug (or some kind of feature). Please see http://paste.ubuntu.com/799261/ to recreate
<sveinse> If I run the script, I notice that apt-get update accesses /var/lib/dpkg/lock while it IMHO is configured not to do so
<sveinse> This is on amd64 Natty
<sveinse> It does work if I call the script as root, since root gives it access to /var/lib, but I was hoping to be able to run the script without being root. And frankly I don't understand what apt is doing outside of its RootDir
<cjwatson> sveinse: the dpkg admindir is set independently apparently; Dir::State::status
<cjwatson> sveinse: or you could set Debug::NoLocking=true
<sveinse> cjwatson: dpkg admindir locking works half ways: Strace tells me that apt is locking within RootDir prior to running apt-get update, but it tries to access the system's lockfile when it's done with update and about to exit
<sveinse> cjwatson: I'll certainly try nolocking, thanks
<cjwatson> I suspect changing that behaviour now would be inconvenient; there is certainly a good deal of code that relies on the current behaviour
<cjwatson> if nothing else by setting a dpkg admindir with rootdir prepended
<sveinse> cjwatson: The Debug::NoLocking works like a charm. Finally! Thanks a lot.
<cjwatson> sveinse: I think it's actually not necessarily unreasonable for apt to handle dpkg and apt metadata separately; I can think of cases where I might want to use my normal apt configuration with a separate dpkg admindir, for instance, and I suspect with a bit more effort I could imagine something the other way round
<cjwatson> it's not documented brilliantly, though
<sveinse> cjwatson: I think there is something not quite all right with the locking mechanism. Not that I can put my finger on it, but I'm not able to get apt-get update to run as-non root even if the locks and status is set inside a staging dir with full permissions
<cjwatson> sveinse: chdist manages it
<cjwatson> (devscripts; config e.g. http://paste.ubuntu.com/799299/)
<cjwatson> (er, I meant to say http://paste.ubuntu.com/799300/)
<sveinse> Great! This might be what I have been looking for...
<sveinse> cjwatson: chdist is definitely what I want, but it doesn't report back command status from apt-get. This makes things a bit harder when scripting though
<sveinse> Think I need to copy chdist and modify it
<cjwatson> sveinse: really?  the version on my system simply execs apt-get, so apt-get's exit status will be the exit status of chdist
<cjwatson> (I don't have any local modifications to that; running precise)
<sveinse> I'm getting "E: broken packages" from apt-get/chdist, but my script (with "set -ex") continues in bliss
<cjwatson> check whether apt-get is actually exiting non-zero ...
<wyuka> hello
<wyuka> i am investigating how wubi and lupin work internally.
<wyuka> where can i get the source code for the initramfs used by ubuntu?
<wyuka> it seems that it supports a "loop" argument to the kernel
<sveinse> cjwatson: FYI apt-get returns status code 100, but this isn't passed on by chdist. Once I've dissected the inner workings of chdist and implemented what I need manually, I've have no need for it, so for me everything is ok now. Thanks for your assistance
<sveinse> (The key seems to be to use apt.conf Dir together with Dir::State::status, and not RootDir as I did)
<stokachu> pitti: ping debug packages generated automatically for updates repo?
<stokachu> pitti: im in the kernel room if you would like to talk more
<pitti> stokachu: they are supposed to be, yes
<pitti> stokachu: this stuff keeps breaking randomly, though, so some are always missing :(
<stokachu> pitti: i was looking for ghostscript-dbgsym, seems to be missing for 8.71.dfsg.1-0ubuntu5.4
<stokachu> on lucid
<stokachu> looks like 8.71.dfsg.1-0ubuntu5 is the only one available atm
<barry> stgraber: https://launchpad.net/~barry/+archive/python/+build/3083012
<barry> stgraber: https://launchpad.net/~barry/+archive/python/+build/3083013
 * mneptok pokes all the Unity devs
<mneptok> https://twitter.com/1990LinuxGuy
<psusi> has there been a shortage of patch pilots lately?  I've had some pending merges for a month now... like https://code.launchpad.net/~psusi/ubuntu/precise/lm-sensors/merge
<micahg> psusi: next round of patch pilots scheduled for next week, there haven't been any scheduled since Dec 23
<psusi> micahg: ahh, I see... thanks
<janimo> mvo, around?
<mvo> janimo: yes
<dholbach> janimo, mvo: I won't be part of the vegetarian caravan later on - we moved out team dinner to today
<janimo> dholbach, me neither, was just pm-ing mvo
<mvo> dholbach, janimo: aha, ok
<doko> kees, ping
<lazka> Will there be another unstable import before the import freeze?
<micahg> lazka: no, that was yesterday
<micahg> lazka: and we were only syncing from testing
<micahg> lazka: feel free to file a sync request (preferably from testing unless there's a reason to sync from elsewhere)
<lazka> oh :(
<micahg> lazka: see requestsync in ubuntu-dev-tools
<lazka> ok, I will do when it hits testing in some days
<lazka> thanks
<l3on> micahg, hey, but what about merge bugs filed before yesterday?
<l3on> I mean, I opened 5 o 6 merge bugs that are still pending
<micahg> l3on: we can still merge/sync, this was only for the autosync
<l3on> ah ok micahg :)
<cjwatson> I probably would have done one more autosync but the new autosync script had already caused enough chaos
<lazka> requestsync works nicely. I was impatient :)
<ahasenack> hi, can someone sponsor/review the python-tz upload for lucid, maverick, natty and oneiric? (SRU)
<broder> ahasenack: i can't review them now, but i don't see anything on the sponsorship queue
<ahasenack> broder: would that be https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= ? What did I forget to do?
<broder> ahasenack: oh, they've already been uploaded then
<broder> you're waiting for someone from ubuntu-sru to review them now
<broder> might be sluggish since they're all rallying
<ahasenack> broder: ah, ok
<RoAkSoAx> ea/win 3
<tormod> patch pilot or not, can some dev please confirm and subscribe u-a on this sync request: bug 908711
<ubottu> Launchpad bug 908711 in s3switch (Ubuntu) "Please sync s3switch 0.1-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/908711
<Laney> did it
<Laney> but I forgot to sponsor it. oops.
#ubuntu-devel 2012-01-11
<stahlie> I'm a beginner in c/c++ programming.... I'd like to be part of ubuntu development.  where would you recommend I start with?
<bmahe> stahlie, try to scratch one of your itch
<jbicha> stahlie: Ubuntu development is mostly packaging and fixing bugs, so I'd recommend you find something that interests you and try making it better
<bmahe> pick a project you use and like, and either fix/improve something
<jbicha> for packaging, see http://developer.ubuntu.com/resources/tools/packaging/
<lifeless> skaet: hey, we were meant to catch up this week I think, but I have no idea when/where the meeting is
<skaet> lifeless,  it was on monday,  but we'll be having the follow on today.   Will add you to today's invite.
<lifeless> skaet: cool
<ogra_> could someone bump the buildscore on https://launchpad.net/ubuntu/+source/linux-ac100/3.0.8-4.3/+build/3084606 please ?
<wgrant_> ogra: Done
<ogra_> gracias !
<pitti> Good morning
<micahg> Mirv: for mozvoikko, does that affect 1.10 as well or just 2.0?
<Mirv> micahg: excellent question
<Mirv> micahg: I was just wondering the same, ie. whether then lucid/maverick should get 2.0.1 together with newer firefoxes or not
<micahg> Mirv: well, those are easier to fix, I'm more concerned about natty/oneiric that I pushed with 1.10 and Firefox 9
<ogasawara> pitti: would you have any free time today? the kernel team wanted to chat about getting our burn down charts updated.
<pitti> ogasawara: in meeting right now, can we do that right after lunch? I'll come to your room
<micahg> Mirv: we're planning on pushing 2.0.x with Firefox 10
<Mirv> micahg: I'll install a virtual machine and check around a bit
<micahg> Mirv: thanks
<ogasawara> pitti: yes, that would be great.
<Mirv> micahg: ok, everywhere? then I'll just check out natty/oneiric
<pitti> ogasawara: (note that I'm not the primary WI tracker dev any more, but I can probably still help you to tweak the charts)
<micahg> Mirv: yeah, 2.0.x with go with 10 everywhere (hopefully)
<smoser> jdstrand, where was that archive tool you mentioned?
<smoser> in security tools for grabbing /checking packages.gz and such
<smoser> mdeslaur, or sbeattie ?
<mdeslaur> smoser: huh?
<micahg> smoser: are you referring to scripts/packages-mirror in ubuntu-cve-tracker?
<smoser> there is something (i think in lp:ubuntu-security-tools) that downloads the Packages.gz and Releases files and checks that they're in sync
<smoser> jamie mentioned it to me last night
<mdeslaur> smoser: yeah, that would be what micahg mentioned
<mdeslaur> smoser: it's a script that locally mirrors the archive without the binary packages
<smoser> loking
<mdeslaur> smoser: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/scripts/packages-mirror
<jdstrand> smoser: run-debmirror
<mdeslaur> oh, wait, jdstrand says that's not the tool he was referring to
<jdstrand> smoser: in utils
<jdstrand> smoser: we are talking about the md5 checking code, right?
<jdstrand> I didn't phrase that well
<jdstrand> anyhoo :)
<smoser> thank you to all security team for help
<mdeslaur> smoser: dude, we'd do anything for you, you know that, right? :)
<soren> rmadison is breaking records today.
<soren> "rmadison python-django python-libvirt" took 3m12s. Gosh.
<soren> This is going to be a long day :)
<cjwatson> hm
<cjwatson>  12:37:35 up 4 days, 19:39,  5 users,  load average: 14.84, 14.81, 9.52
<soren> I swear that's not my doing :)
<soren> this is the first call I made :)
<soren> Second time, same query: 17s.
<soren> I guess I should just keep asking it the same question.
<cjwatson> It has to recompute stuff each time the archive changes
<cjwatson> Different queries should be fast for a while
<cjwatson> Well, "fast"
<soren> Heh :)
<cjwatson> I think this is mostly lillypilly being everyone's punchbag
<lamont> when did dpkg grow the annoyance at blank lines in package descriptions?
<soren> hasn't it always?
<lamont> I upgraded to precise from oneiric yesterday, and it faceplanted because of a bad printer driver package (from the manufacturer?), which was never an issue on oneiric
<lamont> lexmark-08z-series-driver_1.0-1 from lexmark's website
<lamont> http://support.lexmark.com/index?locale=en&productCode=LEXMARK_X7675&userlocale=EN_US&segment=DOWNLOAD&os=UBUNTU_10.04&page=downloadsList&oslocale=en_US
<lamont> I'll have to do a clean oneiric install, install their broken driver and do-release-upgrade again to make sure, but then I have a bug for both update-manager and for lexmark
<soren> lamont: Oh, you mean in binary packages?
<lamont> verily
<lamont> I don't remember when I ran into a lexmark printer, but i want to say it was pre-oneiric
<lifeless> skaet: btw if you use my <firstname at canonical dot com> you can see my calendar... and that I can't make 9am
<Ursinha> lifeless, are you here in budapest?
<Ursinha> I guess I saw you yesterday... or was your clone again?
<lifeless> Ursinha: Twas I; I was going to come over and say hi, but the hot food called me
<Ursinha> okay, changing that meeting was my fault, but not sure if you are required to be there, to be honest...
<Ursinha> lifeless, ah :)
<skaet> lifeless, come when your conflict is over,  we'll tweak the agenda a bit
 * skaet would like lifeless there so we don't come up with things that aren't even possible...
<Ursinha> skaet, I see :)
<lifeless> skaet: cool, will do
<dpm> hey skaet, do you have the release notes thanks page somewhere in the wiki? If so, I'll just stick the query to get the list of translators and the procedure in there
<skaet> dpm,  structure has to be created and will change from release to release, so we probably need some meta pages for this.   I'll set something up and bounce you a pointer later today.
<skaet> thanks.
<dpm> skaet, ok, cool. Whenever you've got anything set up, just ping me and I'll add the translators info
<skaet> dpm,  will do.  Thanks!
<lifeless> I believe this is undesirable:
<lifeless> Do you want to continue [Y/n]? y
<lifeless> Abort.
<slangasek> lifeless: I trust that it recorded your preference somewhere sensible though
<lifeless> slangasek: I have /no/ idea :)
<dross> moin
<Ursinha> pitti, hi, whenever you have a few minutes, let's talk :)
<ahasenack> hi guys, can someone from the sru team review my python-tz SRU for lucid, maverick, natty and oneiric? It's in the upload queue
<pitti> Ursinha: sorry, got (physically) pulled into two other discussions; want to come to desktop room, or shall I find you? where are you ATM?
<mdeslaur> barry: could you give me access to LP: #798405 please?
<barry> mdeslaur: i subscribed you, hopefully that does the trick ;)
<mdeslaur> barry: yes, thanks!
<Mirv> micahg: I got distracted but mozvoikko 1 works in oneiric with firefox 9 - although there is now the common problem that for new users it's disabled by default because of the firefox policy change and one needs to manually go to extension settings
<Mirv> micahg: same in precise - but it seems the Firefox language packs have some trick to be automatically enabled?
<micahg> Mirv: right, chrisccoulson could tell you more about why the langpacks work and the extensions don't, thanks for testing though
<Mirv> micahg: actually, in fresh oneiric with Firefox 9 also Ubuntu Firefox Modifications is disabled by default
<micahg> Mirv: oh?  that's bad
<micahg> that didn't occur when I tested
<Mirv> hmm, let's see, it says it's incompatible but seems there are some uninstalled updates still even though firefox 9 is in
<Mirv> micahg: yes, it looks like ubufox is marked as incompatible with Firefox 9 so that home page is not the Ubuntu about page but the Firefox's own about:home
<micahg> Mirv: do you have 1.0.2-0ubuntu0.11.10.1 installed?
<Ursinha> pitti, I am in the server room, brainstorming in the big paper chart
<Mirv> micahg: ah, never mind, now it actually upgraded it. somehow though the 11.10 installation together with "install also updates" installed Firefox 9 but not all of the other updates
<Ursinha> pitti, if you want to come over that would be nice
<smoser> mdeslaur, jdstrand micahg thanks for your help. i have http://paste.ubuntu.com/800646/ now. it only checks amd64 and i386 right now.
<micahg> smoser: those are the only archs on archive.ubuntu.com
<mdeslaur> smoser: cool
<smoser> micahg, well that would explain me not seeing others :)
<poolie> james_w, hi?
<james_w> hi poolie
<lifeless> can we stop ia32-libs-multiarch depending on libnss-ldap ?
<poolie> james_w, i'm just looking at bug https://bugs.launchpad.net/udd/+bug/877827 and find_unimported_versions
<ubottu> Ubuntu bug 877827 in Ubuntu Distributed Development "openldap fails with "marked but not imported" for an ancient package version" [High,Confirmed]
<lifeless> so folk can -not- have ldap-auth-config installed
<poolie> and i'm trying to understand the logic in
<poolie> # We'll never find old debian releases, so if there is a new one already
<poolie>             # imported then don't try and re-import the old ones.
<mvo> slangasek: if you can still reproduce the apt ubuntu branch issue with crda could you jump into #synaptic?
<james_w> poolie, the rationale for the code marked by that comment, or the logic flow around there?
<poolie> istm that if it's an ancient debian release, whether we've previously imported from debian or not, we should not queue it for importing
<poolie> ie the 'continue' just before the assertion should be one level further out
<james_w> poolie, what about the initial import of a package?
<poolie> then i guess it would keep reading forward until it finds a release in a non-ancient debian release?
<poolie> or no?
<slangasek> lifeless: yes, we absolutely can
<james_w> that would be better accomplished by just deleting all the code to get old versions of debian packages
<slangasek> lifeless: if you're keen to upload it, please drop the dependencies on all the libnss-* and libpam-* to suggests
<poolie> james_w, which code are you refering to?
<james_w> poolie, it takes care to find out what versions of the package were in old debian releases, so that there is more history there
<poolie> that seems to contradict the comment?
<james_w> poolie, this code is a protection against the fact that Launchpad doesn't know about Debian potato, so before adding that code it would try and import any potato versions every time
<james_w> poolie, so if you were to change the code to always ignore potato, you might as well just delete the code that finds out what is in potato and just use Launchpad, that way it won't ever learn about anything older than what LP knows about
<lifeless> slangasek: I can't upload to main.
<slangasek> lifeless: !
<lifeless> slangasek: since I am cleverly not core-dev; would you like me to prep the change :P
<slangasek> nah
<slangasek> i'll just follow my own instructions then :)
<lifeless> slangasek: if enough people nag me I will apply for acls :P
<james_w> poolie, see the second half of import_package.py:get_debian_versions
<micahg> lifeless: umm, isn't ia32-libs in universe?
<lifeless> it is ?
<lifeless> oh it is
<micahg> always has been AFAIK
<lifeless> slangasek: looks like I can futz with it
<micahg> and it's no longer an ISO download :)
<slangasek> lifeless: ohright, why would we put that in main ;)
<cjwatson> .oO( first, land LP branch to grant ~lifeless upload permissions ... )
<slangasek> lifeless: anyway, I'm halfway through now :)
<nigelb> cjwatson: haha
<lifeless> :( bzr+ssh://bazaar.launchpad.net/%2Bbranch/ubuntu/ia32-libs-multiarch/
<slangasek> lifeless: eh? source package == ia32-libs
<micahg> lifeless: umm, try the source (ia32-libs) :)
<slangasek> lifeless: anyway, don't worry about it, I'll just push it here
<james_w> poolie, does that make more sense?
<poolie> not really sorry
<lifeless> slangasek: libnss3 will s..blah ok
<poolie> so it's to do with handling packages that are still available from debian, but which launchpad doesn't know about
<lifeless> slangasek: I was just about finished :P
<cjwatson> james_w: what about not *yet* available from Launchpad?  People often merge Debian versions before gina gets round to importing them
<cjwatson> Particularly if they're the Debian maintainer too
<poolie> that seems like a reasonable thing to do
<cjwatson> Especially given how long it takes gina to get round to anything much
<slangasek> lifeless: yah, but I was already halfway finished before we remembered you could upload it :)
<poolie> i don't know how to reconcile that with # We'll never find old debian releases,
<slangasek> lifeless: uploaded
<lifeless> slangasek: :)
<james_w> poolie, archive.debian.org has old versions of packages and we take care to use that as a secondary source of versions of debian packages
<james_w> cjwatson, that should be fine, as this code usually runs when gina imports it in to LP
<cjwatson> Ah
<poolie> james_w, right, i've got that
<poolie> so the logic is
<poolie> if this is too old to be known to launchpad, then
<james_w> poolie, the find_unimported_versions function looks through the list of all versions of a package, including the old debian ones, and looks to see if they are in the corresponding branch on Launchpad
<james_w> if it is looking at debian potato then the answer will always be "it isn't" as Launchpad doesn't have a branch for debian potato
<james_w> so every time this code runs it would say that version is unimporter
<james_w> unimported
<james_w> if this is the first import of the package then that's what we want, so that the potato version is threaded in to the history
<james_w> however, if it's not the first import then we can skip potato
<james_w> the comment is not at all clear, so let's rephrase it to try and explain that better
<poolie> so this is running from the most recent versions to the oldest
<poolie> if it finds any imported version that comes from debian, have_imported_old_debian is true
<poolie> even if it's not necessarily 'old' old
<james_w> yes
<james_w> that's meant to mean "at some point in the past we've imported the old debian releases (like potato) so we don't need to do it again"
<poolie> ok, so if the branch has ever imported anything from debian, we won't try to import old versions
<poolie> s//versions from old debian releases
<poolie> that makes sense
<poolie> so in this case that is failing
<poolie> we've walked back to a version from an old debian release (woody)
<poolie> we have not observed any later versions that were imported from debian
<poolie> we don't have the version
<poolie> but, as the assertion says, it is marked in the revid db
<james_w> that sounds likely
<Mirv> chrisccoulson: is there some specific thing that workarounds the firefox's new disable-addons-by-default behavior? ubufox and langpacks seems to be enabled, but I cannot immediately see any specific thing why then xul-ext-mozvoikko is disabled by default for users
<chrisccoulson> Mirv, yes, that's intentional
<chrisccoulson> mozvoikko is installed in such a way that firefox considers it as third-party (which it is)
<Mirv> chrisccoulson: isn't ubufox as well? but is it a trademark related problem or something then? at least it means that people don't have spell-checking in Firefox unless each user happens to go to extensions manually and enable it
<Mirv> too bad mozilla chose hunspell instead of enchant at some point
<james_w> poolie, it looks like the list is sorted incorrectly, as it's looking at woody first
<james_w> poolie, it's because of the epoch
<slangasek> well
<james_w> slangasek, how did the epoch on openldap disappear?
<slangasek> james_w: yes, because the Debian archive *completely forgot about that version of the openldap source package* :)
<lynxman> cjwatson: ping
<poolie> so there is a revids entry for it
<cjwatson> lynxman: yes?
<lynxman> cjwatson: do you know if there's a way through a preseed to send the installer logs to a remote syslog?
<poolie> so this ordering should never happen but because of its convoluted history, its version does seem to have stepped backwards
<james_w> slangasek, as in it was uploaded but then purged?
<slangasek> james_w: the source package name disappeared for 3 releases, dak no longer knew anything about it, and as an openldap uploader I was completely unaware of that epoch until the importer found it :)
<cjwatson> lynxman: not by preseeding because syslogd starts before preseed files are processed, but you can put remote_host= and (if required) remote_port= parameters on the kernel command line
<james_w> slangasek, ok
<slangasek> james_w: the source package name went openldap -> openldap2 -> openldap2.1 -> openldap2.2 -> openldap2.3 -> openldap over the space of 10 years
<james_w> poolie, yeah
<lynxman> cjwatson: neat, thanks :)
<cjwatson> lynxman: sorry, make that log_host= and log_port=
<cjwatson> shouldn't have tried to answer entirely from memory ;-)
<james_w> it seems like we would have to blacklist openldap 2:1.2.12.1-1 from being considered at all
<poolie> so the consequence of this is that have_imported_old_debian is not set correctly
<james_w> yeah
<james_w> there's an implicit assumption that versions monotonically increase over time in Debian
<poolie> if we did a prior pass to look whether anything had been imported, that would avoid the issue
<lynxman> cjwatson: hehe, thank you again :D
<poolie> indeed
<james_w> yes, that would likely work as well
<poolie> i don't know if it's worth doing that for such an obscure case
<poolie> otoh it may make things cleaner
<james_w> yeah
<slangasek> cjwatson: your crda change from November is making the apt trunk unhappy
<poolie> james_w, do you have any advice or opinion which i should do?
<slangasek> cjwatson: mvo, DonKult are looking at it (there does seem to be a bit of an apt bug, a M-A: foreign package shouldn't be interpreted as conflicting with itself which seems to be what happens here - http://paste.ubuntu.com/800659/), but I'm thinking it would be good to work around this too
<james_w> poolie, I think either would work well, and I would guess that the two-pass solution would be slightly easier, with the added bonus of making that comment less obscure :-)
<poolie> i concur
<slangasek> cjwatson: do you recall the specifics of the provide/break/replace being added against a package that's still in the archive?
<cjwatson> slangasek: Is that bad?  We want wireless-crda to go away eventually ...
<cjwatson> Or is crda not being installed in its place?
<cjwatson> Let me dig up the relevant IRC conversations
<slangasek> cjwatson: well, it's mostly that I have to do an 'apt-get -f install' to get out of it :)
<cjwatson> http://irclogs.ubuntu.com/2011/11/28/%23ubuntu-kernel.html#t15:33
<poolie> ok we have a meeting now
<cjwatson> crda's Replaces/Breaks is on versions of wireless-crda from before it became a transitional package for crda
<cjwatson> IOW this is basically a rename but with wireless-crda kept around to (allegedly) make the upgrade path clearer
<cjwatson> This seems like a fairly standard rename to me; I'm surprised apt is having trouble with it
<andreas__> hi guys, someone around to take a look at my SRU for python-tz? for lucid, maverick, natty and oneiric, packages are in the upload queue awaiting review
<andreas__> the bug is #885163
<slangasek> cjwatson: dropping the provides: seems to be sufficient to make apt happy; would that be acceptable here now that the kernel knows/prefers crda?
<lifeless> slangasek: so you'll upload it too right ? :)
<cjwatson> slangasek: yes, it would
<slangasek> lifeless: hmmm?
<lifeless> slangasek: ia32-libs-multiarch :)
<cjwatson> It's actually the presence of a transitional package that makes the Provides redundant
<slangasek> cjwatson: ok, I'll do that then, thanks
<slangasek> lifeless: already uploaded
<lifeless> cool
<slangasek> lifeless: took two tries because I forgot to pull in pitti's last upload first, but it's accepted now
<cjwatson> yeah, I can see how that Provides might have confused it in multiarch-land, sorry about that
<l3on> hey guys I worked on merging zabbix 1.8.9, there is a new version 1.8.10 that fixes a CVE, should we adopt it ?
<l3on> s/a CVE/2 CVEs/
<infinity> bryceh: I assume you already know that xdiagnose is broken?
<slangasek> superseded by waylandiagnose
<infinity> slangasek: :P
<infinity> https://bugs.launchpad.net/ubuntu/+source/xdiagnose/+bug/914836
<ubottu> Ubuntu bug 914836 in xdiagnose (Ubuntu) "package xdiagnose 2.0 failed to install/upgrade: subprocess installed post-installation script returned error exit status 101" [Undecided,Confirmed]
<micahg> is waylandiagnose a package to see what's wrong with Mr Burns?
<bryceh> infinity, yeah already fixed
<infinity> bryceh: Though not uploaded?
<bryceh> infinity, not yet
<bryceh> infinity, up now
<infinity> bryceh: Danke.
<mdeslaur> mvo: ok, try again
<pitti> lamont, infinity: any chance to kill https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.0~beta2-2ubuntu1/+build/3082920 ? there's a new upload, and this one is just a waste
<dobey> is there a way to restrict the output of "apt-cache rdepends" to things only in main?
<shnatsel> hello
<shnatsel> I wonder if I can pass several mirrors to lb_config, e.g. Ubuntu mirror + PPAs
<shnatsel> http://manpages.ubuntu.com/manpages/precise/en/man1/lb_config.1.html has so many different mirror options
<shnatsel> it's not stated if I can use several mirrors at once or specify the same option several times or something like that
<tumbleweed> dobey: reverse-depends can
<dobey> tumbleweed: that's what i asked :)
<dobey> anyway, have an appointment. brb
<tumbleweed> dobey: I'm talking abut the tool in ubuntu-dev-tools
<dobey> oh
<dobey> tumbleweed: can it also only list things that are on the default install seed?
<tumbleweed> no
<dobey> since that's what i *really* want right now
<tumbleweed> I'd say calculate reverse deps, then filter by seed (you can use the json db that seeded-in-ubuntu grabs)
<ScottK> pitti, SpamapS, RAOF: I've just finished uploaded KDE SC 4.7.4 to oneiric-proposed - waiting for one of you to approve/accept (see bug 913928).
<ubottu> Launchpad bug 913928 in kde4libs (Ubuntu Oneiric) "Tracking bug for KDE updates for 4.7.4" [Medium,In progress] https://launchpad.net/bugs/913928
<ScottK> If one of you approves, it would be nice if you'd let me do the actual accepts so I can do it in the order that will require the fewest retries.
<lifeless> wheee rmadison is slow atm
<psusi> hrm... was libc-bin recently converted to multiarch?
<psusi> post alpha 1?
<psusi> I'm seeing several bugs installing alpha 1 that look like it's because the auto update removes libc-bin and everything goes to hell before it gets around to installing libc-bin:i386
<psusi> like in this log: https://launchpadlibrarian.net/89463970/UbiquitySyslog.txt
<cjwatson> known to happen when eglibc builds happen out of sync across architectures
<cjwatson> libc-bin was converted eons ago; the occurrence of this bug depends on the timing of install
<cjwatson> it's bug 850264
<ubottu> Launchpad bug 850264 in apt (Ubuntu Precise) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix committed] https://launchpad.net/bugs/850264
<Sarvatt> thats a major pain in the rear with ppa's with daily mesa updates in it, amd64 builds before i386 almost always so there's always a period of time where :i386 gets uninstaled because its out of sync
#ubuntu-devel 2012-01-12
<pitti> Good morning
 * bryceh waves
<smoser> where does rc.local come from?
<smoser> initscripts postinst.
<dholbach> barry, what do you think about having a quick UDW session about UDD? we still have open slots: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable :)
<rbasak> doko: have you been working on openmpi?
<doko> rbasak, no
<barry> dholbach: sure!  how about feb1 1900-2000 utc?
<dholbach> barry, that sounds perfect to my ears!
 * dholbach hugs barry
<barry> dholbach: :)  wiki is warning you have a lock on the page
<rbasak> doko: ok, np
<dholbach> barry, updated the timetable :)
<barry> dholbach: beauty!
<zyga> mvo, hi
<zyga> mvo, quick question
<zyga> mvo, if I wanted to add some dependencies to c-n-f would you rather see me bundling them with the code or packaging as separate entities?
<hrw> do someone has working "Ctrl-a a" (switch window) or "Ctrl-a A" (rename window) in byobu under precise?
<hallyn> hrw: yes
<hrw> hallyn: with tmux backend?
<mvo> zyga: hi, depends on the dependency, if its just used in c-n-f I guess bundling is fine, but generally it should be its own package
<hallyn> hrw: maybe you need to hit f9 to turn on screen emulation?
<hallyn> yup
<hallyn> the only glitches i have are: need ctrl-a [ (not ctrl-a ctrl-[ or ctrl-a esc) to turn on copy mode,
<zyga> mvo, right now it's just for cnf but I have a module cooking that will be used in more things
<hallyn> and need to hit return (can't hit space) in copy mode to finish a copy
<zyga> mvo, ok, thanks for the answer then
<hrw> hallyn: F9 is byobu configuration
<hrw> and first thing which I did was Shift-F12 to get my Fkeys back ;D
<cking> pitti, if I find any more battery sucking bugs what's the best way to get it flagged up for some attention?
<pitti> cking: from my POV, tagging with battery-power-consumption will do
<cking> pitti, cool, works for me too
<pitti> Good morninghttps://bugs.launchpad.net/ubuntu-power-consumption the other day
<pitti> cking: i. e. the project; you can mark the bugs as "also affects u-p-c", then some more interested people will be notified
<cking> cool :-)
<dholbach> I'm organising Ubuntu Developer Week right now - could anyone imagine giving a session about NBS and fixing stuff in there?
<dholbach> this time we offer 30m session as well
<cjwatson> I'm not sure that would make an interesting topic?
<cjwatson> "Sometimes you need to rebuild stuff against new library versions.  This page lists the problems.  On occasion you may have to fix build failures too."
<dholbach> cjwatson, ok, I was just wondering if this was something where we wanted to get people to help out
<cjwatson> It's easy if you're already a developer, and the fixes tend to be adding a changelog entry and uploading so not very interesting to go through the sponsorship process for
<YokoZar> Hmm, Ubiquity is crashing in vmware....is there a virtual machine player that currently works with 12.04?
<dholbach> cjwatson, I guess you're right
<ahasenack> hi guys, someone around to take a look at my SRU for python-tz? for lucid, maverick, natty and oneiric, packages are in the upload queue awaiting review
<ahasenack> the bug is #885163
<tumbleweed> ahasenack: usually the SRU upload queue is reviewed every morning
<tumbleweed> I'm assuming this hasn't happened because of the sprint
<ahasenack> tumbleweed: right, I'm pinging here a few times a day, every day, in the hopes of catching someone :)
<hrw> someone know where chromium 16 or newer for precise can be fetched by apt?
<pitti> hrw: frankly, I'd download it from upstream; chromium has been unmaintained for quite a while now
<pitti> you are better off with installing/upgrading from upstream
<hrw> pitti: thx
<cjwatson> Are we going to get a new (installable) libreoffice-l10n shortly?
<pitti> cjwatson: yes, Sweetshark is working on it
<cjwatson> good, thanks
<semiosis> soren: ping?
<Sweetshark> cjwatson: no libreoffice-l10n, but a libreoffice source including l10n binaries
<Sweetshark> cjwatson: hopefully soon, Im looking into it.
<hallyn> tyhicks: bzr branch lp:~serge-hallyn/ubuntu/precise/util-linux/fix-getty-on-pts; cd fix-getty-on-pts; bzr bd; then install the resulting util-linux .deb in the guest, and see if virsh console works.
<cjwatson> Sweetshark: OK
<tyhicks> hallyn: I'm pretty sure that we determined the problem was *not* in the guest, right?
<tyhicks> hallyn: Either way, I'm in the process of building/testing
<hallyn> tyhicks: no, if libvirt-qemu consoles are on /dev/pts, then there is no doubt htat getty will fail in the guest.
<soren> semiosis: Yes?
<semiosis> soren: greetings.  i've been working on the debian package of glusterfs and i saw your name on the ubuntu launchpad page for the package, so wanted to ask you a couple things
<semiosis> soren: i updated the debian package so the newest version, 3.2.5, builds ok.  i put in a sync request to pull it from debian unstable into precise
<semiosis> soren: wondering if there's anything else needed to help that along
<semiosis> soren: another thing, once precise gets the latest version, i'd like to set up a merge to replace the debian initscript (debian/glusterfs-server.init) with an ubuntu upstart job (debian/glusterfs-server.upstart)
<semiosis> soren: just curious if you have any input on these issues
<semiosis> that initscript/upstart switch fixes an ubuntu bug which is due to how upstart/mountall/fstab works
<semiosis> i have a bug open for that in ubuntu & maintain packages with the upstart job in a ppa & have contributed it upstream
<semiosis> people have been using it & feedback is positive
<tyhicks> hallyn: That didn't fix the problem :/
<tyhicks> hallyn: I just realized there's no possible way that it is an issue in the guest
<tyhicks> hallyn: I should be able to see the grub serial output
<tyhicks> hallyn: That would be way before getty kicks in
<hallyn> tyhicks: ok can you file a bug and attach your guest .xml?
<tyhicks> hallyn: Yes - thanks for taking a look
<soren> semiosis: Sorry, family arrived home, got distracted :)
<ScottK> pitti: Did you get my ping re the KDE SC 4.7.4 SRU (understand if you don't have time to deal with it right away)?
<soren> semiosis: Do you have the bug number for that sync request?
<pitti> ScottK: I got the ping, but kinda busy here :/
<ScottK> pitti: Sure thing.
 * ScottK waits ....
<soren> semiosis: Never mind, found it.
<soren> semiosis: And ACKed it.
<semiosis> thanks!
<soren> semiosis: You can ping me (or someone else on the server team) when you have the upstart-job-adding patch that needs sponsoring. You don't sound like you need any help besides sponsorship, correct?
<semiosis> soren: i think that is correct.  i'm going to make a branch of the package in launchpad with the modification, then not sure what to do next
<semiosis> i'm following http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
<semiosis> i guess just "propose for merging" like it says at the end
<soren> semiosis: Sounds about right :)
<semiosis> soren: great! thanks again for your help.
<beuno> pitti, o/
<beuno> what does this mean?
<beuno> No apport report written because MaxReports is reached already
<pitti> beuno: that the same program already crashed 3 times today, and it's refusing to spam you more
<ogra_> why doesnt it say that ?
<beuno> pitti, interestingly, it hasn't
 * ogra_ was wondering the same thing in the past, would be nice if the message would be less cryptic
<beuno> (crashed before today)
<beuno> pitti, this is on upgrading packages: http://paste.ubuntu.com/801862/
<pitti> beuno: ah, during package updates
<pitti> beuno: I think apt only creates a report for the first breakage, to avoid filing bugs for everything that fails on the broken dependency
<beuno> pitti, right. In my case, it hasn't created any reports for any breakages. Unless it talks to the interwebs and sees if other people had the same problem
<pitti> beuno: no, it doesn't
<pitti> beuno: what's the contents of /var/crash/ ?
<dobey> report as in thing in /var/crash, yeah, not filed on bugs.lp
<beuno> pitti, https://pastebin.canonical.com/58036/
<pitti> hmm
<pitti> beuno: seems mvo is not online, he should know the details (that string is from apt)
<ahasenack> hi guys, someone around to take a look at my SRU for python-tz? for lucid, maverick, natty and oneiric, packages are in the upload queue awaiting review
<ahasenack> the bug is #885163
<cjwatson> ahasenack: I'm looking at it now
<ahasenack> cjwatson: thanks!
<cjwatson> (actually had been for a little while before you asked, coincidentally)
<ScottK> Laney: requestsync should probably be modified to raise an error if a sync request that is not an FFe nor needs sponsoring needs filing.
<Laney> ScottK: it prints a warning ATM
<ScottK> OK.
<roadmr> cjwatson: hi! I'm seeing a huge slowdown in germinate, rev376 took ~2 minutes to germinate oneiric ubuntu-desktop, whereas the latest version takes over one hour. I thought I'd ask you first to see if this is a known issue.
<cjwatson> roadmr: no, quite the opposite in general
<cjwatson> roadmr: the new germinate was one of the major things that got Ubuntu publisher runtime down to under 30 minutes; although that was in a particular mode and I expected a very slight slowdown in general, but I've been timing it all along on my system and I don't see anything like that kind of slowdown
<cjwatson> roadmr: perhaps I could have a bug report with details?
<roadmr> cjwatson: certainly! I tried to file here but couldn't (https://bugs.launchpad.net/germinate)
<cjwatson> roadmr: use the Ubuntu package, please
<roadmr> cjwatson: ok, my dumb self should have thought of that :) I'll file a bug shortly. Thanks!
<jtaylor> doko: python and python2.7 now provide python-argparse, that causes build issues when one b-depends on python-argparse
<jtaylor> shouldn't only one of them provide it?
<ScottK> lamont: Could we have postfix 2.8.7 in precise so I can push it to natty/oneiric updates before we get 2.9.0 here shortly?
<bdrung> cjwatson, Laney, tumbleweed: nice syncpackage announcement
<tumbleweed> bdrung: can't say I added much to it :)
<cjwatson> barry: just reading https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-python-versions, I hope the "kill it off" against python-debian doesn't actually mean killing it but rather making update-manager not use it, or something?  it's a very useful set of packages
<cjwatson> (and e.g. Launchpad uses it a fair bit)
<barry> cjwatson: yep, exactly
<cjwatson> phew
<barry> :)
#ubuntu-devel 2012-01-13
<lamont> ScottK: I'll work on that this weekend
 * nonix4 ponders whether debug symbols for precise grub2 exist somewhere; debugging grub-install segfault without such is PITA
<cjwatson> barry: Would you like me to take the python-debian work item?  Not if you've already started or anything, but I wouldn't mind getting a bit of porting practice here
<psusi> so unity is a shell and it is normally run with compiz as the wm... but gnome-shell is both a shell, and a clutter based wm in one... do I have that right?
<psusi> why the hell is there no bzr branch for mdadm?
<ScottK> lamont: Great.  Thanks.
<maxolasersquad> I am working on packaging a game an have three remaining lintian errors being thrown.
<maxolasersquad> http://paste.ubuntu.com/802571/
<maxolasersquad> This is not an app I wrote, I'm packaging it for ARB.
<maxolasersquad> Specifically I'm trying to resovle the invalid category in the .desktop file.
<maxolasersquad> The file is being created automatically when I run debuild, but I'm not exactly sure where it is getting Qt;Game;Memory;
<maxolasersquad> The code is at http://bazaar.launchpad.net/~maxolasersquad/+junk/qml-memory-game/files
<vibhav> While compiling wxGTK I get this error : http://paste.ubuntu.com/802665/
<slangasek> barry: bug #915843
<ubottu> Launchpad bug 915843 in linux (Ubuntu) "ThinkPad X201: intermittently powers off instead of suspending when closing the lid" [High,Incomplete] https://launchpad.net/bugs/915843
<geser> Sweetshark: are you already aware of bug #915271? it breaks upgrades on precise
<ubottu> Launchpad bug 915271 in libreoffice (Ubuntu) "package libreoffice-core 1:3.4.4-0ubuntu2 failed to install/upgrade: rmdir: failed to remove `usr/lib/libreoffice/basis3.4/program/': Directory not empty" [Critical,Triaged] https://launchpad.net/bugs/915271
<mvo> slangasek: I am on the apt issue again this morning and would love to get the error message you have. I created a testcase for what I get (Internal Error, Could not early remove crda) http://paste.ubuntu.com/802717/ and would love to hear what kind of error you see
<pitti> infinity: you can get your netbook back, I can reproduce on my machine by explicitly calling it
<pitti> ogra_, infinity: FYI, it's bug 913085 if you want to follow
<ubottu> Launchpad bug 913085 in pkgbinarymangler (Ubuntu) "Translation domain detection from config.h is broken" [Critical,Triaged] https://launchpad.net/bugs/913085
<stgraber> slangasek: bug 24061
<ubottu> Launchpad bug 24061 in apt (Ubuntu Precise) "GPG error with apt-get/aptitude/update-manager behind proxy (BADSIG 40976EAF437D05B5)" [High,In progress] https://launchpad.net/bugs/24061
<infinity> pitti: Err.  That's special.
<slangasek> mvo: hi; so at this point I'm manually dist-upgraded to the new wireless-crda+crda and no longer see the issue myself :/
<slangasek> stgraber: yep - thanks :)
<sagaci> pitti: regarding ubuntu-defaults-image, is there any configuration to specify a mirror?
<pitti> sagaci: not right now
<mvo> thanks slangasek - no worries, the testcase definitely catches one more instance of the bug, I was mostly wondering if there is yet another corner case for it
<infinity> pitti: Thanks for the pointer; removing the double-quotes fixed it locally.
<ogra_> same here
<pitti> right, I tested that here
<pitti> funny bug
<infinity> Certainly an unusual symptom for the problem.
<slangasek> mvo: ah, ok
<hallyn> poolie: http://package-import.ubuntu.com/status/libvirt.html#2011-05-26%2020:07:23.558315   'bzr import-dsc' by hand works fine, package importer fails.
<mvo> slangasek: fwiw, I proposed removing debian/ from trunk for command-not-found and have it only in a packaging branch to avoid confusion again (confusion caused by absent minded people like me)
<pitti> cjwatson: I think we should remove the current libo 3.5 binaries to make upgrades a little less broken; does that sound ok to you
<pitti> ?
<cjwatson> pitti: The NBS ones?
<pitti> cjwatson: no, all binaries
<pitti> bdmurray says the upgrade bug alrady has 130-something dupes
<pitti> cjwatson: but building the fix will take at least 10 hours on the buildds
<cjwatson> So effectively no LibO in precise for a while?
<cjwatson> That will break image builds
<infinity> This sounds like a good long-term solution.
<cjwatson> infinity: :-P
<pitti> cjwatson: they are already broken
<pitti> it doesn't make it any less urgent to unbreak LibO
<cjwatson> Well, if I can blame the desktop team for it :-P
<pitti> but it might ease upgrades a little bit
<pitti> cjwatson: well, you can blame us either way :)
<pitti> ah, bug 915271
<ubottu> Launchpad bug 915271 in libreoffice (Ubuntu) "package libreoffice-core 1:3.4.4-0ubuntu2 failed to install/upgrade: rmdir: failed to remove `usr/lib/libreoffice/basis3.4/program/': Directory not empty" [Critical,Triaged] https://launchpad.net/bugs/915271
<cjwatson> If we remove it, people who upgrade to precise in the relevant interval will be prompted by update-manager to remove LibO, I think
<cjwatson> Maybe we can tolerate that but I thought it should be mentioned
<pitti> ah, so it's not -l10n, but due to the broken postinst
<cjwatson> pitti: Well, I'm a bit nervous of the removal, but if you think it's a good idea, I can't actually think of solid arguments against
<pitti> it's only a recommends of u-desktop, so if u-m removes it, nothing would pull it back in
<pitti> cjwatson: bdmurray, Sweetshark and I are currently discussing reuploading 1:3.5.0~beta2+really3.4.4-0ubuntu1
<cjwatson> That sounds intrusive
<pitti> it "only" takes ~ 2.5 hours to build instead of 10
<cjwatson> Despite the low build time, I think I like that even less
<cjwatson> Why the massive build time spike in 3.5?
<pitti> we still have the corresponding -l10n source in the archive
<pitti> cjwatson: unknown yet; on Sweetshark's machine it builds in 2
<cjwatson> It might be different on different builders?
<pitti> possibly
<pitti> cjwatson: beta3 is already released, so we wouldn't have to carry the +really version number for long
<pitti> so it seems both binary removal and the status quo breaks upgrades quite badly
<pitti> cjwatson: OOI, why do you think a reversion is worse?
<pitti> hm, it'd need a libo-l10n upload as well, as libreoffice-l10n-XX Depends: libreoffice-common (<< 1:3.5~)
<geser> what about fixing the broken preinst?
<pitti> that needs to happen, of course; currently discussing with Bjoern
<pitti> if it's faster to fix 3. with -l10n (that already is confirmed to work) and the human theme (that still causes problems), or revert to 3.4
<pitti> "fix 3.5"
<slangasek> cjwatson: per bdmurray's suggestion, I'm going to mark ubuntu-foundations-team as restricted rather than moderated so I don't have to tell people "no" anymore... we'll just have to invite people instead when we want them in :)
<cjwatson> slangasek: good idea!
<cjwatson> pitti: I guess it's not so terrible if there's no risk of us releasing with it; LibO is sufficiently high-profile that I do think people might actually vaguely care about the version number
<pitti> in the worst case we'll release alpha-2 with it, but this should land next week
<pitti> but at this point it gets dangerously close to the weekend for my taste
<cjwatson> I agree we need to fix this before the weekend ...
<cjwatson> barry: did you see my offer last night to take the python-debian port?
<geser> and on monday you can't open that bug anymore as LP times out due to the amount of duplicates
<pitti> this is an apport generated bug
<pitti> I'll create a bug pattern
<pitti> committed
<cyphermox> jodh: stgraber: re the upstart jobs for bluez I was talking about earlier -- bluetooth-daemon.conf: http://paste.ubuntu.com/802774/   -- bluetooth-device.conf: http://paste.ubuntu.com/802775/
<cyphermox> if you could take a look that would be great.
<jodh> cyphermox: will do, thanks.
<cyphermox> thanks to you -- the initial code was great help
<cyphermox> fwiw: if you want to test you'll need to obviously remove /etc/init.d/bluetooth, but less obviously get /lib/udev/rules.d/97-bluetooth.rules out of the way
<pitti> so, 3.4 took 6:40 hours to build, seems it's really buildd dependent
<pitti> i386 takes 2.5 hours
<pitti> but most of the dupes are in fact on amd64
<pitti> (not surprisingly, given the target audience of current precise)
<bdmurray> pitti: the pattern doesn't match may of the duplicates
<pitti> ah, e. g. bug 915455
<ubottu> Launchpad bug 915271 in libreoffice (Ubuntu Precise) "duplicate for #915455 package libreoffice-core 1:3.4.4-0ubuntu2 failed to install/upgrade: rmdir: failed to remove `usr/lib/libreoffice/basis3.4/program/': Directory not empty" [Critical,Triaged] https://launchpad.net/bugs/915271
<pitti> bdmurray: I'll check the logs instead
<barry> cjwatson: i missed that, but that would be awesome
<barry> cjwatson: btw, i'm going to go hang out with the bzr guys now.  do you have a package w/quilt that you'd like us to try to merge?
<cjwatson> barry: not off the top of my head that I'm not already handling adequately, sorry :)
<cjwatson> pitti: if you can find a builder that does a decent job, we can stick the farm on manual just before the uploa
<cjwatson> d
<barry> cjwatson: okay ;)  we'll hunt around for a fun one to hammer on
<pitti> cjwatson: *nod*
<pitti> bdmurray: added another pattern, matches a lot more now
<bdmurray> pitti: great, thanks
<hrw> eglibc failed to crosscompile for me: http://paste.ubuntu.com/802791/
<slangasek> hrw: is that the current precise version of the package?
<hrw> slangasek: yes and fail is during cross toolchain bootstrap
<hrw> slangasek: I am doing test now with older version to check when it started to fail
<slangasek> hrw: ok, thanks
<slangasek> barry: hem, have to reject this python-dbus upload - E: python3-dbus-dbg: non-standard-toplevel-dir debian/
<slangasek> barry: there are several other lintian errors to be fixed at the same time
<tjaalton> let's try here; any DD's in budapest willing to sign my gpg key?
<tjaalton> one is enough :)
<infinity> tjaalton: Depends on how nicely you ask.
<tjaalton> infinity: pleeease.. ? :)
<tjaalton> infinity: no rush with the actual signing, but I can drop you a paper with the fingerprint and stuff..
<infinity> tjaalton: Bring extravagant gifts to the ARM room.
<tjaalton> salmiakki that is then :)
<hrw> salmiakki aka 'what is wrong with Finnish people' :D
<nigelb> lol.
<nigelb> "extravagant gits to ARM room."
<nigelb> I can almost imagine some kind of primitive initiation ceremony happening near infinity :P
<tjaalton> hrw: the same :)
<cjwatson> Riddell: In kdeplasma-addons 4:4.7.90-0ubuntu1, did you mean to also drop plasma-widget-kimpanel's dependency on plasma-widget-kimpanel-backend-ibus while dropping the latter package?
<Riddell> cjwatson: hmm there's a whole spec to sorting that out which involves finding and evaluating an update to kimpanel.  I'll take a quick look at kdeplasma-addons today to answer your question
<cjwatson> Riddell: OK, I just noticed because it shows up in NBS.  Thanks
<slangasek> tjaalton: one is never enough
<slangasek> tjaalton: I'm sure you want to give me salmiakki in exchange for signatures as well
<tjaalton> slangasek: hehe, well I got Mirv to sign it earlier, but another one wouldn't hurt I guess
<tjaalton> let me "print" the key first
<tjaalton> er, fingerprint
<slangasek> oh, I forgot that Mirv is also a DD; clearly both of us failed at having our fingerprints displayed prominently on the outside of our jackets
<pitti> cjwatson: just FYI, we discussed reversion, and it seems it's not any less risky or less work than fixing 3.5 (it's building for an hour already)
<pitti> we have the preinst fixed, and -l10n* are generated properly
<tjaalton> slangasek: ok, where are you atm?
<slangasek> tjaalton: foundations room (across from ARM)
<tjaalton> ok
<infinity> tjaalton: Sent to pgpkeys.mit.edu
<tjaalton> infinity: excellent, thanks
<pitti> infinity: which of the amd64 builders is the fastest we have?
<cjwatson> pitti: *nod* thanks
<slangasek> infinity: without validating the email addresses! <gasp>
<doko> pitti: allspice
<pitti> doko: danke
<bdmurray> pitti: /msg pitti do you have any plans to upload apport in the near future?
<pitti> bdmurray: there are a few fixes in trunk, but nothing urgent; but I can do an upload on Monday or so if you want to get in the kerneloops stuff
<Mirv> tjaalton: :P
<bdmurray> pitti: that and the ubiquity package hook change would be nice
<barry> cjwatson: you might want to give lp:bzr and lp:bzr-builddeb a try.  i got a demo of `bzr merge` in the presence of quilts.  *really* nice
<cjwatson> cool, ok, will have a look next time I have occasion
<barry> cjwatson: i think it will land in precise in a few days
<infinity> slangasek: I already knew his IDs were his.  All I would have been validating is the lack of an MITM.
<slangasek> pshaw
<infinity> ;)
<slangasek> you only knew that they belonged to some person calling himself tjaalton
<slangasek> there are apparently 8 million of those in finland
<infinity> No, I knew they were his, or belonging to someone who pretends to be him on a regular basis.
<infinity> And quite convincingly.
<infinity> If that's true, that guy can have the sig.
<infinity> He's earned it.
<tjaalton> :)
<slangasek> hallyn: waah, why did you break virt-manager
<hallyn> i did what?
<slangasek> hallyn: Error starting domain: internal error no assigned pty for device charconsole0
<slangasek> regression since Wednesday-ish
<hallyn> slangasek: does 'virsh console <domain' work?
<slangasek> hallyn: I don't know what I'm meant to specify as 'domain', this is why I use virt-manager ;)
<hallyn> slangasek: zul says he's going to merge 0.9.8-2, hopefully that will pull in the *full* set of fixes.
<slangasek> hallyn: "error: The domain is not running
<slangasek> "?
<slangasek> hallyn: 'virsh start' gives me the same 'Failed to start' error
<hallyn> strgraber: the 'libvirt not showing running domains' - can you reproduce that at will right now?
<stgraber> hallyn: no, that was yesterday, I then completely killed libvirt, manually killed anything that was still running and restarted it, worked fine after that.
 * om26er misses the patch pilots :/
<ScottK> They were on holiday break, they'll be back.
<hallyn> cyphermox: should netcf be depending on libnl3 (if src pkg depends on libnl-3-dev)?
<cyphermox> hallyn: if you're using symbols from libnl3, you'd get a depends on libnl-3-200 or libnl-genl-3-200.
<cyphermox> hallyn: depends mostly if it #includes netlink/netlink.h or netlink/genl.h (or any such thing)
<hallyn> cyphermox: guess i'm just confused as to why it wasn't in there to begin with.  (or why it worked without it)
<cyphermox> not sure, let me look
<cyphermox> hallyn: right now it seems to me like it's there, in libnetcf1
<hallyn> cyphermox: well i'm pretty sure i just messed up originally (and got away with it bc of spurious other pkgs)
<hallyn> hm, i don't see it
<cyphermox> Depends: libaugeas0 (>= 0.6.0), libc6 (>= 2.8), libnl-3-200 (>= 3.2.3), libnl-route-3-200, libxml2 (>= 2.7.4), libxslt1.1 (>= 1.1.25), augeas-lenses
<cyphermox> that's from apt-cache show libnetcf1
<hallyn> weird.
<cyphermox> hallyn: coming
 * pitti shepherds a new libreoffice in and crosses fingers
<lifeless> why is 'for purchase' empty in software centre in precise ?
<Laney> AFAIK stuff has to be manually rolled over and this has not happened yet. iamfuzz ^^^?
<cjwatson> iamfuzz isn't responsible for it any more afaik, not sure who is
<james_w> correct
<pitti> bdmurray: found the bug, uploading fix now
<iamfuzz> cjwatson, I think Scott Ritchie is still helping out with that part time
<andrejz> hello! can anyone point me in the direction of checkbox developers ?
<pitti> andrejz: cr3 ?
<andrejz> ok, thanks pitti
<cr3> andrejz: hi there, what's up?
<andrejz> hello, i have some concern about the string to be translated. they require substantially more translator work then they could. I briefly explained it here - https://bugs.launchpad.net/checkbox/+bug/916096
<ubottu> Ubuntu bug 916096 in checkbox "Checkbox requires a lot of translator work" [Undecided,New]
<andrejz> do you think something can be done about it?
<cr3> andrejz: I'm not sure, those strings are taken from the equivalent to rfc822 deb files
<cr3> andrejz: however, you raise an extra good point that "PURPOSE" should not be translated but that's our fault, it's really not clear :(
<cr3> andrejz: I'm really not happy with the pseudo-markup format which PURPOSE/STEPS/VERIFICATION are intended to be
<andrejz> it's kind of annoying i need to translate some strings over and over again (PURPOSE, STEPS and VERIFICATION are most prominent, but there are others too)
<cr3> andrejz: I'll raise this with the rest of the team for sure but I can't make any promises for Precise since we're approaching FF quickly. however, there are talks for a major refactoring in P+1
<andrejz> ok, thanks
<cr3> andrejz: there will be a blueprint for the refactoring listing some of the problems with the current implementation, so I'll make sure to raise your concern
<andrejz> cool, i hope something nice comes out of it :)
<cr3> andrejz: me too, I can appreciate the annoyance you have to deal with. thanks for taking the time to get in touch with me though, very nice!
<pitti> cjwatson: (CC: RAOF) oneiric unapproved has some syncs, presumably from (failed?) experiments from you?
<andrejz> well at first i started translating but then i got increasingly annoyed and then realised i am surely not the only one with this issue and decided to report it :)
<pitti> cjwatson: we can't do anything but reject them, but not sure what the intent was?
<pitti> cjwatson: qemu-kvm and compiz-plugins-main
<cjwatson> hmm
<cjwatson> oh!  I wondered where those had gone, that explains a certain amount
<cjwatson> yes, reject them
<pitti> rejecting all five dupes :)
<cjwatson> those were actually copies from oneiric-proposed - I did them a different way in the end after being unable to figure out what was going wrong
<cjwatson> but if they landed in unapproved, that makes a kind of sense
<hikenboot> anyone interested in seeing (besides me) Proxmox 2.0 kvm/openvz/ISCSI/ZFS working on the next version of Ubuntu? Here I have it working on DEBIAN see the last 4 articles posted at wanfuse.blogspot.com...should be easy enough to translate to ubuntu...problem is that most of it is touchy about kernel versions? I think with some help it would be a great inclusion in the next ubuntu release!
<cjwatson> pitti: just so you know, you can now pass multiple -s arguments to sru-accept.py so that it only leaves one comment
<hikenboot> or should i post that on #ubuntu-app-devel?
<hikenboot> In order to get it working with ISCSI and able for the iscsi to run Microsoft clusters I needed to use IET ISCSTARGET instead of openiscsi target..
<hikenboot> and had to get a patch for ZFS to work with ISCS since in its current form in the normal tree it does not
<pitti> cjwatson: useful, thanks!
#ubuntu-devel 2012-01-15
<ScottK> lamont (or anyone else that can do it): Would you please kill the armel pykde4 build (3091719) on crabapple.  It's been stuck on "Unpacking chroot for build" for 12 hours.
#ubuntu-devel 2013-01-07
<pitti> Good morning
<pitti> OdyX, tkamppeter__: indeed, a config file doesn't belong into a library
<OdyX> pitti: that's fixed in master, I just pushed, but the job control files issue, well, meh.
<Adri2000> hi
<Adri2000> bug #1048634 has been waiting for ~ubuntu-sru action since 12/19. did I miss something...?
<ubottu> bug 1048634 in ejabberd (Ubuntu Precise) "Login issue with Pidgin using SRV records" [Medium,In progress] https://launchpad.net/bugs/1048634
<hadess> pitti, hey
<hadess> pitti, you're not on #gnome-hackers :)
<hadess> pitti, reckon that the power test suite is ready to merge?
<pitti> re
<pitti> hadess: hey! argh, indeed; my autojoin is just for #python and #introspection
<hadess> pitti, #control-center is good as well
<pitti> hadess: yes, I think it's good now; all tests succeed
<hadess> pitti, i'll try to install the necessary deps on fedora now
<pitti> hadess: I asked Matej about updating the Fedora package of dbusmock
<pitti> hadess: let's see how far they get on current rawhide
<hadess> pitti, doesn't look like the packages are in fedora to start with
<pitti> hadess: oh, I only saw http://pkgs.fedoraproject.org/cgit/python-dbusmock.git/, and Matej saying that he submitted 0.3
<hadess> pitti, hasn't hit the mirrors yet, let me test all this
<pitti> hadess: for now you can also just download and extract the tarball, and run the test with setting PYTHONPATH to the extracted tarball
<pitti> (no need to install anything, etc.)
<hadess> pitti, it's fine, it's built, and available
<hadess> pitti, make check is the way to run the test suite, right?
<pitti> hadess: right
<pitti> hadess: you can also run a single test with e. g. "plugins/power/test.py PowerPluginTest.test_action_multiple_batteries"
<pitti> but "make check" will run them all
<hadess> pitti, should we get an error message instead of import failure when a python module isn't present?
<hadess> builddir = os.environ.get('BUILDDIR', os.path.dirname(__file__)) <- shouldn't that be srcdir instead?
<pitti> hadess: oh, what's missing? I thought I alrady covered dbusmock and GI
<hadess> pitti, for me, dbus
<pitti> hadess: ah, I can add that
<pitti> hadess: no, that's indeed meant to get the builddir; it's for calling the xtest helper
<pitti> hadess: the fallback is when you call the script manually instead of through the Makefiles (which do export BUILDDIR and TOP_BUILDDIR)
<hadess> pitti, i think it might be that plugins/power/test.py is getting run first
<hadess> pitti, ha, ok
<pitti> hadess: oh, I see; I had assumed that "import dbusmock" will run first, but indeed it doesn't; I'll add the check and error message
<hadess> ta
<pitti> or rather, move the gsdtestcase import up, then it'll also cover the Gio import
<hadess> pitti, ideas about that? http://fpaste.org/yTxF/
<pitti> hadess: oh yes, it's not supposed to be python 2.7, but python 3
<pitti> odd, how does it end up being called through 2.7?
<pitti> #!/usr/bin/env python3
<hadess> dbusmock was built against python2...
<hadess> let's try again
<pitti> hadess: oh wait, is that jhbuild?
<hadess> yeah, though i'm using the system python
<hadess> not mad enough to do it by hand
<pitti> hadess: could be https://bugzilla.gnome.org/show_bug.cgi?id=688353
<ubottu> Gnome bug 688353 in general "PYTHONPATH wrong when using python 3" [Normal,New]
<pitti> hadess: can you try again with PYTHON=python3 jhbuild run make check ?
<hadess> pitti, python-dbus and dbusmock are built against python2
<pitti> hadess: you don't have a python dbus package for python3?
<hadess> pygobject3 as well...
<pitti> hadess: dbusmock works with both
<hadess> nope
<pitti> hadess: so, we could change the test suite to also work with py2, I just wanted to avoid introducing more py2 stuff
<pitti> hadess: but anyway, this fails in a plain "import dbus", so something is wrong there
<pitti> hadess: jhbuild run python -c 'import dbus'
<pitti> hadess: does that fail with the same error?
<hadess> pitti, there's no py3 dbus module on my system
<hadess> works with python2, not python3
<hadess> would it be a big job to make it work with python2 as well?
<pitti> hadess: no, not a big job, but we need to put one or the other into the hashbang
<hadess> "python 3 requires using gdbus through introspection."
<hadess> apparently there won't be a dbus python for python 3
<pitti> hadess: so, I'm still confused how it ends up importing the py2.7 bits when you call it through py3
<pitti> hadess: there is
<hadess> you ported it? :)
<pitti> barry did
<hadess> it was my PYTHONPATH override which caused problems
<pitti> in 1.0 already, or at least 1.1
<hadess> in any case, no dbus or pygobject for python3 = won't work for now
<pitti> hadess: give me some minutes, there are a few py3-isms right now which need fixing to also work with 2.7
<pitti> hadess: pygobject is in jhbuild, and built for py3 by default now (and there's a pygobject-python2 jhbuild project for py2)
<pitti> hadess: I attached updated patches to the bug which now work with both 2 and 3
<pitti> hadess: just update the hashbang
<hadess> pitti, thanks
<hadess> pitti, much better :)
<hadess> pitti, i have that though: http://fpaste.org/LQ0F/
<pitti> hadess: yep, that's the bit that's fixed in dbusmock 0.3.1
<pitti> hadess: i. e. download, unpack, set PYTHONPATH to it
<hadess> ha, ok
<pitti> (sorry about that)
<jibel> pitti, could you review the branch attached to bug 1096788? it fixes a regression introduced by 2.2.3ubuntu2
<ubottu> bug 1096788 in autopkgtest (Ubuntu) "Capitalize field names read from control file" [High,Fix committed] https://launchpad.net/bugs/1096788
<pitti> jibel: bien sÃ»r
<jibel> pitti, thanks
<hadess> pitti, where does it create the tmp files?
<hadess> pitti, i've updated it in fedora now
<pitti> hadess: standard mkdtemp(), i. e. /tmp or $TMPDIR
<pitti> hadess: cheers
<hadess> pitti, can you use a description template for the mkdtemp call?
<pitti> sure
<hadess> thanks
<pitti> hadess: http://paste.ubuntu.com/1506203/, I'll update the patch when we are done with discussing
<hadess> -shiftkey_CFLAGS = $(XTEST_CFLAGS)
<hadess> +shiftkey_CFLAGS = -I$(top_builddir) $(XTEST_CFLAGS)
<hadess> otherwise it couldn't find config.h
<pitti> oh, I didn't see that
<hadess> pitti, tests pass
<pitti> applied locally
<hadess> only other change i have here is for s/python3/python/
<pitti> hadess: ok, I guess "2 or 3" is your call
<hadess> do we have a better way to configure that, rather than require local changes
<hadess> well, i won't be able to do a clean make distcheck if there's "python3" being called
<pitti> hadess: Makefile could call ${PYTHON:-python3} ./test.py
<pitti> or default to python2
<pitti> right, it shoudl be something that works for you, of course
<pitti> hadess: I have dbus-python and pygobject from jhbuild, and these seem to work
<hadess> pitti, let me test with those then
<pitti> oh wait, do I have dbus-python? /me checks
<pitti> hadess: ah no, I'm using dbus-python system packages
<hadess> looks like it builds python2 bindings by default
<pitti> hadess: but either way, as long as the code also works with py3, it's trivial to switch to py3 later
<pitti> so defaulting to py2 WFM
<hadess> pitti, let's go for python2, and we can work on getting a py3 setup working before 3.8
<pitti> hadess: http://paste.ubuntu.com/1506215/
<pitti> hadess: this defaults to py2, but if I run it with PYTHON=python3 it will use py3; WDYT?
<hadess> pitti, looks good, i'll commit all that in a sec
<pitti> hadess: ok, I'll update the patch attachments with that then
<hadess> pitti, done locally already
<pitti> ah, ok; was going to rebase, etc.
<pitti> jibel: can you please also send the updated patch to the Debian bug?
<jibel> pitti, sure
<tseliot> cjwatson: by passing debuild the "-v" parameter, did you mean to say that I should pass it together with the latest version of fglrx-updates?
<cjwatson> tseliot: I forget the package names.  In general when you are uploading to <stable>-proposed and there's already a version in -proposed not yet promoted to -updates, you need to build the .changes file with -v<most recent version in release or updates pocket>
<cjwatson> so that all the changes not yet in updates appear in the .changes file
<tseliot> cjwatson: ok, I've learnt a new thing. Thanks
<cjwatson> tseliot: it's kind of awkward that uploaders need to do this by hand; maybe we'll fix it some day ...
<maxb> ooi, what is actually affected by the changelog fragment in the changes? The email to the <codename>-changes list and descriptive fields in the LP UI I suppose?
<cjwatson> maxb: I think the e-mail changes are actually auto-calculated properly nowadays, but I'm told that it confuses sru-report (pending-sru.html)
<cjwatson> i.e. omitting -v can cause us to lose track of bugs not yet fixed in -updates
<cjwatson> I've not looked into it myself
<bdrung> coolbhavi: are there enough people interested in becoming an ARB member?
<coolbhavi> bdrung, received 2 applications till date
<coolbhavi> so sent a remainder
<bdrung> coolbhavi: i am too busy with other stuff already.
<coolbhavi> no issues bdrung
<cjwatson> tseliot: the jockey .changes file still doesn't include the changes from ubuntu7.6 :-(
<cjwatson> tseliot: (bug 1080588 comment #33)
<ubottu> bug 1080588 in jockey (Ubuntu Precise) "jockey suggests not installable packages on renamed stack" [High,In progress] https://launchpad.net/bugs/1080588
<tseliot> cjwatson: can you reject it again, please? I'll reupload it
<tseliot> cjwatson: ah, thanks
<cjwatson> done
<cjwatson> tseliot: Looks like you need to use -v0.9.7-0ubuntu7.4
<cjwatson> I suggest checking the .changes file manually before upload
<tseliot> cjwatson: it looks good to me
<achiang> pitti: hi, i keep getting unity-2d crashers and it seems apport-retrace can't get a good trace out of it, cf: https://bugs.launchpad.net/bugs/1096285 - is there something on my end that needs to be updated or is it on the retracer side?
<ubottu> Ubuntu bug 1096285 in unity-2d (Ubuntu) "unity-2d-shell crashed with SIGSEGV" [Undecided,Invalid]
<pitti> achiang: it seems missing ddebs
<pitti> achiang: what you could try is to install all the libqt*-dbg stuff yourself and see whether you can get a better trace out of it?
<bdcomp> Hello world!
<pitti> achiang: the retracer is supposed to try and install those as well, but that doesn't seem to work for some reason (need deeper investigation to find out why)
<pitti> achiang: but there's no core dump on that bug any more
<bdcomp> I am trying to backport LibreOffice and have some questions about dput.
<achiang> pitti: ok, i'll try and manually install the libqt*-dbg packages locally. i pinged you precisely because i thought the backend wasn't working properly and might want someone to dig into it
<bdcomp> dpkg-buildpackage -sa dput -f ppa:bdcomp/backports libreoffice_3.6.4-0ubuntu1~precise2_source.changes it still uploaded not all source files: Uploading to ppa (via ftp to ppa.launchpad.net):   Uploading libreoffice_3.6.4-0ubuntu1~precise2.dsc: done.    Uploading libreoffice_3.6.4-0ubuntu1~precise2.debian.tar.gz: done.        Uploading libreoffice_3.6.4-0ubuntu1~precise2_source.changes: done.  Successfully uploaded packages.
<pitti> achiang: what it says is basically true -- http://ddebs.ubuntu.com/pool/main/q/qt4-x11/ doesn't have version 4.3
<pitti> argh ddebs argh
<bdcomp> The dput command should upload all the tar.xz files, but it doesn't. Please advise.
<achiang> pitti: how do those ddebs get built?
<pitti> achiang: the building is not the problem; it's the ridiculous and unreliable hack that we need to use to get them from the buildds to ddebs.u.c.
<OdyX> .oO(Wish there was a polished ddeb policy on the Debian side)
<pitti> achiang: which often fail because of macquarie going out of space (as it is right now), or buildds' apaches timing out, etc.
<pitti> achiang: the long-term solution is to store them in the LP librarian, FYI
<mterry> zul, I'll try and look at stevedore and testrepository later today or tomorrow.  Have to do some SRU work firt
<zul> mterry: okies
<achiang> pitti: got it. so the problem is understood and there's a plan in place. :)
<pitti> achiang: apport tries -dbg as well, but there is no libqtcore4-dbg
<pitti> so we'd need to add some more heuristics, such as installing all -dbg from the source package of the binary it's currently looking at
<pitti> so if you need an actual bt, it's probably easier to install them manually
<achiang> pitti: yeah, the actual BT is what i care about, because unity-2d keeps crashing on me. :-/
<ogra_> ogra@nexus7:~$ grep CONFIG_BLK_DEV_IO_TRACE /boot/config-3.1.10-8-nexus7
<ogra_> # CONFIG_BLK_DEV_IO_TRACE is not set
<ogra_> GRMBL
<ogra_> doesnt help to dig into ureadahead code if our kernel doesnt support it at all :P
<Sweetshark> bdcomp: dput uploads the files enumerated in the *.changes/*.dsc file. Have a look at them there.
<Sweetshark> bdcomp: -sa should include all files in the upload.
<bdcomp> Sweetshark: well, the *.dsc list all files but *.changes only 2 files.
<tumbleweed> bdcomp: correct. dput uploads things listed in .changes
<tumbleweed> bdcomp: the idea being, if a .orig.tar file that our source package (.dsc) contains was already uploaded, we don't need to upload it again
<bdcomp> tumbleweed: after the last dput command I received this error email: Rejected: Unable to find libreoffice_3.6.4.orig-binfilter.tar.xz in upload or distribution. Unable to find libreoffice_3.6.4.orig-dictionaries.tar.xz in upload or distribution. Unable to find libreoffice_3.6.4.orig-helpcontent2.tar.xz in upload or distribution. Unable to find libreoffice_3.6.4.orig-src.tar.xz in upload or distribution. Unable to find libreoffice
<tumbleweed> bdcomp: build the source package with -sa to include all orig tarballs
<Sweetshark> bdcomp: and maybe remove the *.dsc/*.changes files before, just the be sure ...
<tumbleweed> that seems pretty unecessary
<bdcomp> tumbleweed: just to be sure, the "dpkg-buildpackage -sa" command is instead "dpkg-buildpackage -S"?
<tumbleweed> no
<tumbleweed> dpkg-buildpackage -S -sa
<cjwatson> Sweetshark: Removing .dsc and .changes is entirely unnecessary
<tumbleweed> without -S, you'll build a binary package (.deb)
<Sweetshark> cjwatson: see? for cases like that ^^ it helps ;)
<bdcomp> from the start, my steps should be "dpkg-source -x *.dsc", "cd libreoffice-*", "dpkg-buildpackage -S -sa" and "dput ppa:... *.changes"?
<tumbleweed> bdcomp: sounds about right
<Sweetshark> bdcomp: looks good
<cjwatson> Sweetshark: Not really, because the .changes would be clearly wrong in that case
<tumbleweed> although, there's no point in extracting a package, and then just building it again
<tumbleweed> presumably you make some changes in between...
<bdcomp> Great! Gonna try now - the results probably tommorow morning :)
<tumbleweed> bdcomp: if you're just backporting, have you seen the backportpackage command?
<bdcomp> tumbleweed: no. I am following this tutorial: https://wiki.ubuntu.com/LibreOfficePackaging#Backporting
<bdcomp> And Sweetshark advices :)
<Sweetshark> tumbleweed: i guess backportpackage is helping only in exceptional cases with libreoffice (when you depend on a third of main, chances are you need some tweaking anyway).
<tumbleweed> yeah, it just automates no-change backporting
<hallyn> SpamapS: are you still on SRU team?  re bug 1027987, the underlying cause seems to be (perhaps temporarily) solved in another pkg.  Can we either accept the pkg (as it seems verified to not make things worse) or reject it (so we can push a new libvirt precise-proposed SRU) ?
<ubottu> bug 1027987 in libvirt (Ubuntu Precise) "Starting libvirtd takes too long because of "udevadm settle" timeout" [Medium,Fix committed] https://launchpad.net/bugs/1027987
<hallyn> bug 1092826 would like a turn
<ubottu> bug 1092826 in libvirt (Ubuntu Precise) "libvirt client doesn't handle EINTR signal properly" [Undecided,New] https://launchpad.net/bugs/1092826
<SpamapS> hallyn: I am, and will try to look at that later today
<doko> seb128, are you familiar with the dbus package? looks like the tests are disabled by default. so it should be fine to drop the build dependencies for the tests as well?
<doko> jodh, ping
<jodh> doko: libnih? xnox is on it! :)
<doko> jodh, yes, this was my question =)
<xnox> doko: I have a question for you. New shadow adds depends on ustr, cunit & libsemanage - shall I make a DEB_STAGE=1 build of shadow ~ which drops libselinux, libsemanage, ustr, cunit out of min-chroot ?
<hallyn> SpamapS: great, thanks
<ogra_> cjwatson, /etc/init/console-font.conf talks about a udev rule in the comment at the top, where would that rule be ? i cant find it
<doko> xnox, hmm, how about building these packages instead? didn't I touch libselinux recently?
<xnox> doko: ok. I can do that. I think cunit need a tiny fix & libsemanage needs to ignore gem2deb the same way libselinux does.
 * ogra_ tries to fix a plymouth vs console-font race on the nexus7
<seb128> doko, hey, not so much, but I think we should get the test to run if we can, meanwhile I don't see an issue dropping the build-depends if it's creating issues
<ogra_> cjwatson, nevermind, found it
<cjwatson> ogra_: /lib/udev/rules.d/85-keyboard-configuration.rules
<ogra_> yeah
<doko> seb128, ok, as a first step, I'll drop the b-d's to let ir cross build
<doko> xnox, libselinux already had support for DEB_STAGE
<xnox> doko: yeah. I want to copy it's support into libsemanage package.
<xnox> cause on the surface it looks similar.
<cjwatson> is libsemanage actually part of a loop?
<xnox> cjwatson: thanks to justed MIRed shadow, yes.
<xnox> r-deps that is.
<arges> anybody have experience with nvidia+xinerama with 6 monitors?
<smb> arges, Ok, so it seems python-dev used to pull in libssl-dev but not anymore. Just FYI. And no to previous question
<Guest74799> Hello!
<Guest74799> Is this the developer channel?
<sil2100> Guest74799: hi, yes
<Guest74799> sil2100: Are you a developer of Ubuntu?
<Guest74799> sil2100: Hi!
<Guest74799> sil2100: Because I have technical problems with ubuntu.
<mhall119> didrocks: ping
<didrocks> hey mhall119
<Guest74799> didrocks: Hi!
<didrocks> hey Guest74799. FYI, this is not a support channel, but a developer one see the topic :)
<sil2100> Guest74799: yes, I'm an Ubuntu developer, but from the integration team ;) But best if you send your question to #ubuntu , someone should answer for sure
<Guest74799> Meet here about the developers of Ubuntu.
<Guest74799> sil2100: Exactly! Something I need.
<Guest74799> sil2100: Sorry for my english! I mean: Exactly! So a developer I need.
<xnox> doko: I need libdbus-1-dev to be Multiarch:same =) there no clashing paths. I guess i'll just upload on top of your upload ;-)
<doko> xnox, sure
<doko> xnox, btw ustr is a pain ... any way not to use it in libsemanage?
<xnox> oh I wanted to look at that. As "upstream" is not helpful at all either.
<xnox> I am not sure. I am guessing that newer versions of compiler libraries should provide similarish functionality.
<cjwatson> Guest74799: it's generally better to just ask your question, rather than looking for somebody to ask
<cjwatson> (this is not me volunteering to answer your question; since I don't know what it is, I have no idea whether I'll be able to answer it)
<xnox> Can I use :native dependencies?
<xnox> build-deps that is.
<infinity>         # For the moment, we treat multiarch-annotated build-dependencies as
<infinity>         # the same as any others because we're not implementing a
<infinity>         # cross-buildd.
<infinity>         $deps =~ s/:any//g;
<infinity>         $deps =~ s/:native//g;
<infinity> xnox: ^-- The official buildds just strip it off, which is a sane thing to do, so they should work in the archive.  But, on the other hand, any time you add a :* to a build-dep, you probably need to think really hard about why and if you need it.
<xnox> infinity: me needs to build a tool for the build-arch, to execute on the build-host when crossbuilding to host-arch
<xnox> hence I need two libs both for $build-arch (x86) and $target-arch (armhf)
<xnox> alternatively I can do a circular dependency back on inself, which would be ugly.
<xnox> and totally not work in the archive.
<infinity> xnox: Oh, ew.  Yeah, I had that in a package and "fixed" it via marginal fluke of my native build-dep already being on the system. :P
<xnox> that is another posibility, let me check if it's available.
<infinity> xnox: In theory, though, "Build-Depends: libfoo, libfoo:native" should just compress down to "libfoo" on a non-cross build, so should work fine in the archive.
<xnox> infinity: yeah, but that won't be nice if the src package in question is "libfoo"
<infinity> xnox: That might not be true on Debian's buildd's, though.  Not awake enough to dig through the new sbuild's handling of that.
<infinity> xnox: Hrm?  It shouldn't be build-depending on itself at all, it should just be using the libs it built during the build.
<infinity> xnox: That advice doesn't change for a cross, it just means it might need to built itself twice.
<xnox> infinity: nih-dbus-tool is executed to generate some code to build further.
<infinity> s/built/build/
<xnox> yeah. hence the question about :native dependencies =)
<cjwatson> xnox: :native breaks the current version of sbuild in raring; you need a patch I got committed upstream on Thursday.
<cjwatson> So I'd hold off on them for a little while yet.
<cjwatson> xnox: And it broke Debian's buildds last I heard (as does :any), making it hard to forward.
<xnox> ok. cjwatson, can nih-dbus-tool (M-A: foreign) package be available in chroot which does cross builds?
<cjwatson> Definitely the wrong answer.
<cjwatson> :native is long-term the right approach; it'll just take a little while to sort out.  We don't need evil workarounds in the meantime.
<infinity> xnox: If it's MA:foreign, a regular build-dep will prefer the BUILD_ARCH version, not the HOST_ARCH one.
<infinity> (Unless sbuild's or apt is getting this wrong right now and not following spec)
<xnox> yeah. but that introduces a circular build-dependency on itself for non-cross case.
<cjwatson> No, it absolutely doesn't
<xnox> src package libnih builds nih-dbus-tool binary package and uses it during it's build.
<cjwatson> :native build-dependencies on the things you need to build the native nih-dbus-tool in libnih, and do two build passes if cross-building
<infinity> xnox: Right, and circular build-deps are wrong, going back to my "you might just need to build it twice".  Why is that not doable?
<cjwatson> In the cross pass, use /path/to/nih-dbus-tool/you/just/built
<cjwatson> No circularity
<cjwatson> I made it work in Chromium OS ages ago (albeit pre-multiarch)
<xnox> yeah. So my original solution to use :native build-deps needed to build /path/to/nih-dbus-tool/you/just/built is the right one. Apart from we don't have :native support in sbuild just yet.
<cjwatson> It's the right answer, we just need to hold off a bit before implementing it.
<infinity> Well, we could pull your sbuild patches back from git.
<xnox> so I'll create a branch with :native build-dep. but I will not be uploading it, just will stick in a branch for wookey/doko =)
<infinity> Which reminds me, I need to commit mine too.
<cjwatson> infinity: Probably won't be that long 'til the next release
<xnox> ok, thank you all =)
<infinity> cjwatson: No, probably not.  I really want my patch to get into wheezy (if we can manage), so there's not some weird chroot-finding behaviour change between wheezy and jessie, so I'll be pushing to release our bits.
<cjwatson> infinity: Incidentally do you know how to figure out what code the Debian buildds run?
<infinity> They run a different branch entirely... Hosted on... I don't remember where.
<infinity> Ask Roger. ;)
<infinity> (It is, at least, a branch now, not an unmaintained fork, so life's a bit better than it used tobe)
<cjwatson> Fair enough.  There are a bunch of buildd-* branches in sbuild.git, but I have no idea which of them are used
<dobey> can i bug a sponsor to poke at bug #1047606 please? i've attached new files for the package, and it would be nice to get it into raring now. thanks
<ubottu> bug 1047606 in Ubuntu Raring "[needs-packaging] ubuntuone-client-data" [Wishlist,New] https://launchpad.net/bugs/1047606
<fbond> Hi. Where is the right place to ask about broken package branches in LP? Branch in question is lp:ubuntu/precise/ifupdown.
<cjwatson> bugs.launchpad.net/udd
<fbond> cjwatson: Thanks.
<stokachu> o/
<stokachu> bdrung: i gotta go pick my daughter up from school but ill be back in about an hour to continue if you like
<bdrung> Sweetshark: which upload broke in raring? what's the big difference between quantal and raring for libreoffice?
<bdrung> stokachu: do you want to know which packages to merge/sync or how to do it?
<Sweetshark> bdrung: in this case there was some additional quoting needed for scripting in the rules file. doko did that when bootstrapping raring but never commited the change to the packaging repo. I checked the quotes to be there in the 4.0 branch and they were. Then someone indesrimiately and uncoordinated forwardported 3.6.4 from quantal to raring without the fix causing major pain. (Because breaking a package that takes a day to build is always maj
<Sweetshark> bdrung: but the specific stuff that broke is irrelevant. when you depend on a third of main, there always will be something that breaks.
<bdrung> Sweetshark: okay. the SRU policy requires that the fix is in the devel release.
<bdrung> so an upload to raring was required.
<Sweetshark> bdrung: not for libreoffice, never was, ask seb128. I dont know if that is formalized anywhere. And it is nonsense anyway: Do I need to upload 3.5.7 to raring too for an precise SRU? ;)
<micahg> Sweetshark: always has been the policy (dev release is usually a release ahead though)
<Sweetshark> bdrung: 3.6.4 is tested in the LibreOffice ppa for that reason.
<Sweetshark> micahg: always has been an exception for libreoffice.
<micahg> Sweetshark: not that I'm aware of
<bdrung> Sweetshark: 3.5.7 is lower than 3.6.2, which is in raring
<micahg> the assumption is that the fixes from 3.5.7 are in 3.6.2 in this case
<bdrung> Sweetshark: if 3.5.7 fixes bug that are in 3.6.2 too, you will have to update the package in raring too (by uploading 3.6.x with the fix or 4.0.x)
<bdrung> s/bug/bugs/
<Sweetshark> micahg: which is broadly true, but practically naive for a package as complex as libreoffice. essentially each major is a different product.
<micahg> Sweetshark: you've said yourself there are issues that affect multiple series
<bdrung> Sweetshark: 3.6.4 needs to be uploaded to raring (or a 4.0 version) if you want to upload 3.6.4 to quantal-proposed
<micahg> Sweetshark: with 10M+ lines of code, you can't tell me it's a total rewrite every 6 months
<Sweetshark> micahg: enough of a rewrite that the assumption that applying the same patch at different series is riskfree is nonsense.
<bdrung> Sweetshark: libreoffice in precise has a security issue. have to contacted the security team to get libreoffice 3.5.7 into precise-security instead of precise-proposed?
<micahg> bdrung: the security team decided it wasn't worth an upload to -security
<bdrung> okay
<Sweetshark> bdrung: https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.4-0ubuntu1.1 you mean the issue in this changelog entry?
<psusi> could I get a release manager to add a quantal task to bug #1093918
<ubottu> bug 1093918 in multipath-tools (Ubuntu) "grub-probe auto-detection fails on raid" [Undecided,New] https://launchpad.net/bugs/1093918
<Sweetshark> bdrung: I kinda think it is fixed in libreoffice, yeah. the security says so. so which issue are you talking about?
<bdrung> Sweetshark: sorry. i oversaw that upload.
<Sweetshark> uhuh
<bdrung> i just saw the CVE link in bug #1037111
<ubottu> bug 1037111 in libreoffice (Ubuntu Precise) "[SRU] LibreOffice 3.5.7 for precise" [High,In progress] https://launchpad.net/bugs/1037111
<Sweetshark> yeah, security went to bypass that with a patch-only upload for that issue.
 * bdrung nods.
<Sweetshark> 3.5.7 is EOL upstream. still 3.5.7 upstream has regressions against 3.5.4. I just searched for post-EOL vendor patches to backport upon 3.5. Unfortunately thats some 15 patches alone.
<bdrung> wow
<kdub> hello all, using pbuilder, I can't tell it to use my gpg key during a pbuild... how to work around?
<bdrung> libreoffice is not a simple package
<hallyn> infinity: for qemu for raring, I've broken the debian->ubuntu delta up into smaller git commits at github.com/hallyn/qemu #de.oct.ubuntu2 (https://github.com/hallyn/qemu/tree/de.oct.ubuntu2)
<bdrung> kdub: i sign the stuff afterwards with debsign
<kdub> bdrung, one of my dependencies is not trusted with whatever keyring the chroot is using, and the setup fails
<Sweetshark> ... and thats just sticking to the most urgent crashers (dataloss) and regressions -- leaving out other annoyances. That this isnt noticed in general can be attributed to its hugeness (somewhere between gnome and the kernel). If I had a team like the kernel or the GNOME guys, we could talk about different stuff. As is? no.
<bdrung> kdub: tried an update?
<Sweetshark> anyway.
 * Sweetshark gone
<kdub> yep, everything's all updated. my host system has this key in its trusted.db, but the chroot does not pick up that keyring during pbuild
<bdrung> kdub: login into the pbuilder instance and check the trusted.db there
<kdub> bdrung, the chroot trusted.gpg and the host's trusted.gpg is different. how can you tell the chroot to use the host system's keyring?
<bdrung> kdub: you can edit the file in pbuilder (but make sure that you save the result)
<hallyn> infinity: i'll email mtokarev about the chances of some of those going into the debian pkg
<n00bie> can someone give me a hint where the color of the software-updater progress bars would be defined? I tried modifying the Ambiance gtk3 theme but that seems to have no effect on those progress bars.
<Sweetshark> from the off -- bdrung: just to give you another example what I mean with "depends on the third of main": LibreOffice was broken once by a stable update of kdelibs really close to ff: It introduced a new SETTINGS_MOUSE choice in an enum in a kde header and SETTINGS_MOUSE was a define in LibreOffice code. Thats the stuff you are dealing with: trivial, highly annoying, still breaking your 1 day build.
<n00bie> same problem with the ubuntu-software-center progressbars
<bdrung> Sweetshark: i experience the same with the daily build of vlc in a smaller scale than libreoffice
<bdrung> Sweetshark: do you think that libreoffice 4.0 beta2 is ready for wider testing of raring users?
<bdrung> uploading beta versions of applications to the development release is often a good idea
<soren> mdz, kees, stgraber: TB meeting?
<infinity> bdrung: Assuming the final release is slated for on or around feature freeze, I agree with you.
<bdrung> infinity: libreoffice 4.0 is planned to be the version in 13.04
<infinity> bdrung: In that case, yeah, fully agree that we should be getting betas in.
 * hallyn out for a bit, bbl
<doko> $ cat autoconf_64b.c
<doko> #include <stdlib.h>
<doko> #include <stdio.h>
<doko> int main(void)
<doko> { /* output a "1" is it's a 64 bit platform. Major hack. */
<doko>         size_t val = -1;
<doko>         puts((val == 0xFFFFFFFF) ? "0" : "1");
<doko>         return 0;
<doko> }
<cjwatson> AC_CHECK_SIZEOF([size_t])
<cjwatson> ...
<infinity> doko: Do I want to know what that's from?
<doko> yep, this is ustr's hown grown configure system
<infinity> Oh, ick.
<doko> the package that you did promote ..
<infinity> I blame Jamie.
<doko> jdstrand, ^^^ ;-P
<Sweetshark> bdrung: the product is, the package is not. well, it might be, but it isnt sufficiently tested -- so by definition, it is not.
<infinity> Maybe "is it multiarched" needs to make it on our MIR checklist.
<infinity> Which then extends to "is it multiarchable?"
<cjwatson> Does it multiblend?
<Sweetshark> bdrung: as for testing: http://blog.documentfoundation.org/2012/12/08/the-libreoffice-community-organises-a-6-day-test-marathon-to-help-preparing-the-new-4-0-version-of-libreoffice/ and http://skyfromme.wordpress.com/2012/12/12/libreoffice-test-marathon-bibisect-4-0-and-ubuntu-packages/ give you a much broader test base as it runs on the release that is out.
<kdub> newbie question here, but when packaging how does one specify build system flags? eg, if my cmake project needs --disable-feature, where can I put that when making a debian package?
<bdrung> kdub: in debian/rules. if you are using dh, you specify a override_dh_auto_configure and run "dh_auto_configure -- --disable-feature1 --enable-bar"
<bdrung> there
<kdub> hmm, i will try... thanks bdrung!
<paultag> Anyone seen Mr. jbicha?
<paultag> Ach, wait, nickserv knows, disregard. Thanks.
<hallyn> ok here's a question.  libcgroup in precise had initscripts.  in q they were pulled.  in r I want to replace them with dummies to make someone upgrading from p gets the old scripts removed.
<hallyn> but does that mean someone upgrading from q is going to have a prompt about the replacement?
<hallyn> i gues si'll just test it
<infinity> hallyn: The only prompt in that scenario would be from P to R+, if the user edited the init script.  But why replace them instead of removing them?
<infinity> hallyn: dpkg-maintscript-helper(1) -- rm_conffile
<infinity> hallyn: If they should be gonem they should be gone, not replaced with stubs.
<infinity> s/gonem/gone,/
<hallyn> infinity: oh, right.
<hallyn> which reminds me, i *was* using that in qemu-system, where did those calls go?
<hallyn> infinity: thanks
<hallyn> oh i guess i seemed ot not need to do any dpkg-maintscript-helper so long as i kept the script by the same name, but moved it to another pkg
<infinity> hallyn: Assuming the contents don't change either, yeah.
<infinity> hallyn: Otherwise, things get a bit funny.
<infinity> If I recall.
<hallyn> infinity: hm, the contents do change, but my tests didn't show any funkiness.
<infinity> Maybe dpkg got smarter about conffile Replaces than it used to be.
<hallyn> hopefully it's that, and not bad testing
<infinity> Since it would have to compare the hash from the old package with the current on-disk, then do the Replaces.
<infinity> It certainly could have gotten smarter.  I just know it used to suck at it.
<infinity> Oh, maybe the situation it sucks in is if it's modified.
<infinity> Cause that logic gets even weirder.
<infinity> But if the contents changed, and yours was modified, you want a prompt anyway, and I hope that's what you'd get.
<infinity> Anyhow, you can test a few scenarios if you're paranoid.  I really don't remember the current state of all of that.
<infinity> Generally, moving conffiles between packages is just a bad idea.  But sometimes you don't have much choice.
<hallyn> hm, maybe i need to test the case where it's been modified.
<stokachu> bdrung: if i could be pointed in the direction of where there is some documentation on merging/syncing packages from debian to ubuntu and yes a list of packages that may need that
<stokachu> i assume there is not much to it as long as there are no ubuntu specific alterations
<bdrung> stokachu: for sync we have requestsync/syncpackage
<infinity> stokachu: If there are no Ubuntu modifications, autosync takes care of it.
<bdrung> stokachu: merging the UDD way: http://developer.ubuntu.com/packaging/html/udd-merging.html
<infinity> (With two exceptions: after the Debian Import Freeze (and you shouldn't just become a human autosync after freeze, it's there for a reason), and if we sync from experimental, we don't auto those)
<bdrung> stokachu: http://developer.ubuntu.com/packaging/html/traditional-packaging.html
<bdrung> stokachu: for open merges: https://merges.ubuntu.com/
<infinity> stokachu: Merging the old skool way is vaguely self-explanatory if you read the REPORT for a MoM merge, random example: https://merges.ubuntu.com/e/efilinux/
<bdrung> stokachu: bonus points for getting the ubuntu changes upstream and then be able to sync (if no remaining change is left)
<stokachu> ok cool thanks guys ill look over these links
<stokachu> so do i just go through the packages and read the report file to see if any conflicts were found?
<stokachu> like for bash i saw where it failed to do the merge completely
<stokachu>  oh i see a generated report for the archives
<stokachu> cool i think i understand what to do, ill ask here if i get stuck
<bdrung> great. good night!
<infinity> stokachu: You may also want to see if you're stealing merges from other people.
<infinity> stokachu: grep-merges 'Adam Stokes' is a good starting point, since you have one outstanding merge of your own. :P
<infinity> stokachu: "grep-merges bash" will show you that bash is Colin's, and he may or may not care about keeping TIL on that.
<bdmurray> pitti: Should we enable apport sending crashes to Launchpad in Raring?
<infinity> bdmurray: You mean LP bug reports, as opposed to whoopsie?  (the former seems to be be working...)
<infinity> bdmurray: I'm personally kinda happy with just whoopsie going forward, even for devel releases.  That may be an area of contention, though.
<infinity> Err, s/former/latter/
<bdmurray> infinity: I mean LP bug reports in addition to errors going to the crash database
<infinity> bdmurray: Yeah.  I'm wondering if we really need that, but I'm not a defect analyst, I'll bow to your experience here.
<infinity> bdmurray: My take, though, is that we should be watching errors like hawks for spikes, and we need a nice "tell us what broke" bit in the whoopsie/apport submission hidden under the "more info" bit that lets "power users" add free-form comments, and lets everyone else ignore the option.
<infinity> (I discussed this with Evan when I was in London last)
<infinity> There's nothing even remotely friendly or pleasant about the whole auto-filing of bugs.
#ubuntu-devel 2013-01-08
<doko> infinity, cjwatson: for cross build db, I'm hit by debian bug #625484. this now fails on amd64 as a native build
<ubottu> Debian bug 625484 in libdb4.8 "libdb4.8: 'Build signature doesn't match environment' in 4.8.30-6" [Critical,Fixed] http://bugs.debian.org/625484
<bdmurray> I think we need the bug reporting in Launchpad as it provides a way for developers / reporters to communicate at least until we have server side hooks implemented in the crash database.
<infinity> doko: Weird.  That claims to have been fixed long before any DB version we have in the archive...
<doko> ahh, typo
<bkerensa> sabdfl: how is Las Vegas?
<bkerensa> :)
<sabdfl> just getting the stand ready, big opening is tomorrow, press event tonight
<bkerensa> very nice
<sabdfl> show looks to be as huge as ever
<sabdfl> we've already had folks taking photos of the stand as "i was there" keepsakes
<sabdfl> which is nice :)
<bkerensa> sabdfl: well good thing you have something really big to show those attendees :)
<lifeless> sabdfl: price of fame :)
<psusi> can anyone jog my memory on the bash syntax for matching part of a string?  It think it involved a #... like I want a for loop on *.patch, but I want to reference only the part before the .patch?
<sarnold> psusi: ${filename%.patch} -- http://tldp.org/LDP/abs/html/refcards.html
<psusi> ahh... heh, I could have sworn it was a #... thanks...
<infinity> psusi: # cuts in the other direction.
<sarnold> psusi: # is the front :)
<psusi> aha
<psusi> would be nice if I could have found that under brace substitution in the bash info page... heh...
<pitti> Good morning
<pitti> bdmurray: yes, I already enabled it in the packaging branch
<pitti> bdmurray: I'll release 2.8 today and then upload
<pitti> infinity: just keeping errors.u.c. for crashes is indeed the plan, but we are missing the extra developer hooks for those still
<pitti> and/or the request "the next person who experiences this, please file a LP bug"
<pitti> both are planned, we discussed it on the London sprint
<infinity> pitti: Minor nitpick you should fix in apport upstream before it hits Debian, that libc6-dbg dependency should be libc-dbg (all the libcN-dbg packages provide it).
<infinity> pitti: Accepting anyway, though, since it's fine for Ubuntu, where all our arches are libc6.
<pitti> infinity: ah, thanks; so in the spirit of "real dep first", libc6-dbg | libc-dbg ?
<infinity> pitti: That's not a real package on all arches.  If you really wanted to do that, you'd want "libc6-dbg | libc6.1-dbg | libc0.1-dbg | libc-dbg"
<infinity> (I feel like I might be missing one...)
<pitti> I don't want to pull in e. g. libc6-dbg-arm64-cross
<infinity> Ahh, 0.3 on hurd, that's the one I was missing.
<pitti> ok, I don't think I'm interested in those for Ubuntu
<infinity> So, yeah, if you want to do real|virt, "libc6-dbg | libc6.1-dbg | libc0.3-dbg | libc0.1-dbg | libc-dbg" for Debian.
<pitti> infinity: http://paste.ubuntu.com/1508926/ enough for ubuntu?
<infinity> For us, sure, libc6-dbg | libc-dbg is fine (or even what you have there is fine).
<infinity> Just pointing it out if the generic Debian packaging is upstream.
<pitti> no, trunk has no packaging
<infinity> (And, really, it doesn't hurt to have the extra deps in the Ubuntu package to keep the delta lower)
<pitti> *nod*
<pitti> I'm not sure how often the Debian maintainer syncs his packaging with our's, but I'll commit that for now
<pitti> thanks for pointing out!
<infinity> He's at 2.7-2 right now, uploaded on New Year's Eve.
<infinity> So, I'm guessing reasonably often.
<infinity> Oh, packaging, not upstream versions.  Yeah, no idea how out of sync the packaging is.
<infinity> Someone might want to look at that some day before we end up with an unreconcilable mess.
<pitti> http://anonscm.debian.org/gitweb/?p=collab-maint/apport.git;a=tree;f=debian; looks reasonably close to our's
<infinity> If they can be brought pretty close to in sync, we might want to just switch to a "maintain in experimental/sid, merge to Ubuntu" model.
<infinity> Personally, I find that helps keep the world lett fragmented, but YMMV.
<infinity> s/lett/less/
<pitti> yeah, and it's collab-maint anyway
<pitti> one of these days I'll walk through our remaining delta and see how it can be minimized
<infinity> Anyhow, that heads-up was mostly just cause Debian ftpmaster will (or should) have the same nitpick.  If you don't do the Debian packaging anyway, meh.
<infinity> s/do/have anything to do with/
<OdyX> â¦ just get the person maintaining the thing for Debian in the discussion loop and get the diff to zero. There; a better world.
<pitti> that shouldn't be a problem, Ritesh contacts me rather often to fix things upstream in the debian backend, etc.
<mdeslaur> cjwatson: sure, I'll merge mcrypt today
<mdeslaur> s/mcrypt/m2crypto/
<davmor2> who is responsible for failsafe mode in R?
<cjwatson> foundations
<davmor2> cjwatson: thanks networking mode dpkg mode and others don't work :(
<cjwatson> zul,adam_g: openstackx has been removed from Debian because it's no longer needed (Debian bug #679077); do you agree with this and can I remove it from Ubuntu too?
<ubottu> Debian bug 679077 in ftp.debian.org "RM: openstackx -- ROM; now useless" [Normal,Open] http://bugs.debian.org/679077
<zul> cjwatson: be my guest
<cjwatson> done, thanks
<cjwatson> stgraber: Do you still care about qtnx?  It's been removed from Debian (Debian bug #652377).
<ubottu> Debian bug 652377 in ftp.debian.org "RM: qtnx -- RoQA; unmaintained, dead upstream" [Normal,Open] http://bugs.debian.org/652377
<tjaalton> doko: the mesa/llvm issue should fix itself once we prepare the next mesa version for raring, since it got rid of the llvm-backend that caused trouble (moved to the llvm branch by tstellar, targeted for 3.3)
<doko> tjaalton, does this mean, that you need a 3.3 snapshot?
<tjaalton> doko: not necessarily, they said that the radeonsi driver isn't that useful yet anyway, so we could just disable it until 3.3 is released
<doko> ahh, good to know. I don't want to have a snapshot in main
<tjaalton> right
<tjaalton> we could also ship a version just for mesa
<tjaalton> but too much work for little benefit, I think
<stgraber> cjwatson: I think it can go now. It used to be handy to reproduce bugs for older versions of WebLive, but the last of those was natty, so I no longer care :)
<roadmr> cyphermox: hey! got a minute? I'm preparing a checkbox upload and wanted to ask about the actual uploading process (http://developer.ubuntu.com/packaging/html/udd-uploading.html)
<roadmr> cyphermox: basically I'd push from my branch to ubuntu:checkbox, then dput the source.changes, and that's it?
 * xnox thought lp:checkbox is now used `as if it's lp:ubuntu/checkbox`
<cyphermox> roadmr: depends what your branch is
<cyphermox> if lp:checkbox is still different than ubuntu:checkbox you'll still want to apply a debdiff
<cyphermox> while it needed sponsoring it was easier, but now for your own sanity I'd figure out a way to bring the two branches in sync ;)
<cyphermox> but otherwise, yes, you do the changes on then push to ubuntu:checkbox, and dput the changes file
<roadmr> cyphermox, xnox : that's my next question, we want to ensure the branches at least have common ancestry, does bzr push --overwrite lp:ubuntu/checkbox sound good? (I'd then port the Ubuntu changelog to ensure that doesn't get lost)
<roadmr> cyphermox, xnox : having a common ancestor will greatly simplify post-FF merging
<cyphermox> roadmr: doesn't sound like the right way to achieve that
<roadmr> cyphermox: would going the other way do it?
<cyphermox> maybe
<cyphermox> currently looking at something entirely different. maybe try to see how well you can merge ubuntu:checkbox back into lp:checkbox?
<cyphermox> if lp:checkbox already has everything you need I'm not sure you need to worry too much about the rest though; if everything for upload goes through lp:checkbox, you can make your changes there, and build source packages from that branch with no issues
<roadmr> cyphermox: the problem is post-FF, when we have to be selective about which changes in lp:checkbox go into the lp:ubuntu/checkbox (and from there to the package)
<cyphermox> oh, right
<zyga> cjwatson: hey, do you know if there's been any change on the UEFI netboot story
<cjwatson> zyga: No
<roadmr> cyphermox: being selective using patch (because no common ancestry) is very error-prone since patch/diff is  dumber than bzr merge
<zyga> cjwatson: we've been following https://wiki.ubuntu.com/UEFI/PXE-netboot-install
<cjwatson> zyga: Somebody needs to give me a reproducible test case for the GRUB bug I've heard about
<cyphermox> roadmr: could you simply use branches to do that? e.g. branch for a new release and selectively merge from trunk?
<zyga> cjwatson: and got to a point where we have "error: variable `prefix' isn't set"
<cjwatson> One that I can follow using KVM
<zyga> cjwatson: well, if that's the stuff we're seeing we can certainly arrange something for you
<cjwatson> Something that I can run locally
<cjwatson> I'm not going to do this in the lab
<zyga> cjwatson: I see
<roadmr> cyphermox: hm, so branches of lp:checkbox for each release? what happens to lp:ubuntu/checkbox then?
<cjwatson> I need to compile test GRUB binaries and that sort of thing that's a right pain to arrange remotely
<cjwatson> zyga: have you tried using the pre-built secure boot UEFI images?
<zyga> cjwatson: no, do they support netbooting in any way?
<cyphermox> roadmr: it would just keep track of all the uploads. if you see something different there you'd just want to merge it back in, either via a merge of by taking the diff
<cjwatson> probably won't work either but might at least fail differently :-)
<cjwatson> zyga: in theory
<cjwatson> zyga: I'm not aware of any positive reports
<zyga> cjwatson: ok, we are willing to try that, what should we do?
<cjwatson> /ubuntu/dists/raring/main/uefi/grub2-amd64/current/gcdx64.efi rather than building your own with grub-mkimage
<cjwatson> or possibly grubx64.efi, not quite sure
<zyga> cjwatson: right, we'll find that
<lewis__> Will mobile be develop in a open model? Where is the git repository?
<cjwatson> zyga: hmm, actually maybe this is a waste of time
<cjwatson> zyga: I wonder if I can reproduce this problem in kvm based on that wiki page
<zyga> cjwatson: so if we give you access to some hardware remotely
<zyga> cjwatson: could you help us with that a little?
<cjwatson> zyga: my experiences with remote hardware access in Canonical have been excruciatingly painful
<cjwatson> zyga: I'm willing to go to some effort to avoid having to do that
<zyga> hmm
<zyga> maybe we can ship you one
<cjwatson> no thanks
<cjwatson> no space
<cjwatson> zyga: can you send me the test image you're currently using - the one you built with grub-mkimage?
<zyga> yeah
<zyga> roadmr: ^^
<cjwatson> zyga: the one I built just now based on raring produces that same error message, but it's just noise and it works
<zyga> ah
<cjwatson> so that error message is probably not actually the root cause of your problem
<zyga> roadmr: could we push the image to people.c.c?
<roadmr> cjwatson: mine uses quantal, I can certainly build a new one with raring, let me try that
<roadmr> zyga: we can
<cjwatson> given the way this method works, it should be reproducible without actually netbooting
<zyga> cjwatson: what do you mean by that?
<zyga> cjwatson: you mean that it's actually just booting an ISO that was copied over the network?
<cjwatson> the firmware is acquiring the entire thing, grub and the iso, in one giant blob
<zyga> right
<cjwatson> so given that you've got into grub, it shouldn't require any more magic to get as far as the iso
<cjwatson> I mean nothing environment-dependent
<roadmr> cjwatson: this is what we were trying to use
<zyga> yeah, you are right
<roadmr> http://people.canonical.com/~roadmr/bootx64-quantal.efi
<cjwatson> therefore, should reproduce in kvm
<cjwatson> put it in an otherwise empty directory, kvm -L /path/to/built/ovmf/firmware -monitor stdio -m 1024 -hda fat:/path/to/that/directory, and execute the .efi binary from the efi shell
<cjwatson> roadmr: thanks, downloading
<cjwatson> zyga: do you have an OVMF build?
<zyga> cjwatson: yes
<zyga> well, a release actually, I didn't go to build it myself
<cjwatson> zyga: it would be worth trying with the method above to see if you get the same results that way, then
<cjwatson> I built one for SB support, but a release should od
<cjwatson> *do
<zyga> trying
<zyga> ok
 * zyga is rusty on his efi shell
<zyga> so what do I do after getting to uefi shell
<cjwatson> fs0:
<cjwatson> then 'dir' and you should see the name of the .efi file - you can then just type that in
<zyga> ah
<zyga> yeah
<zyga> man, like DOS
<zyga> volumes with names
<cjwatson> nostalgia, right
<zyga> yeah
<zyga> works
<cjwatson> remember, this is MODERN FIRMWARE
<zyga> LOL :D
<zyga> I saw that error
<zyga> but now I'm in grub menu
<cjwatson> likewise
<zyga> so install hangs for me, how do I switch to kvm serial console?
<zyga> ok
<zyga> in the KVM window, alt-ctrl-3
<zyga> actually 2
<zyga> hmm
<zyga> so I see the same error as we reported before ('error: variable `prefix isn't set.')
<roadmr> then ' error: no device connected. ' (repeated 8 times)
<zyga> I don't see that message
<zyga> what exactly is on the mini iso
<zyga> what should we be seeing after grub?
<cjwatson> well, you should get to the menu
<cjwatson> "no device connected" is a message from GRUB's PATA driver
<zyga> I tried it a number of times
<zyga> and I cannot even see the kernel booting
<cjwatson> hmm, this may be because you're (unwisely) building in every possible module rather than just the ones you need
<zyga> I just tried the rescue stuff
<cjwatson> so if one of GRUB's drivers gets stuck trying to operate some bit of hardware, it could hang
<zyga> ah
<zyga> that makes sense
<zyga> so for the sake of exercise, which drivers should I be loading for OVMF?
<cjwatson> let's see what minimal set would work
<zyga> and which for random real hardware
<cjwatson> give me a few minutes to experiment here
<cjwatson> shouldn't be hardware-dependent at all
<zyga> thanks, sure
<cjwatson> I mean, the minimal set you need
<cjwatson> after all it's loading the iso from its own image
<cjwatson> zyga: so, for raring, instead of that `...` expression, try:  all_video boot cat echo font gfxterm gzio iso9660 linux memdisk minicmd normal test video
<cjwatson> zyga: for precise/quantal, you'd probably want to replace "all_video" with "efi_gop efi_uga"
<zyga> cjwatson: ok, let me try this and get back to you
 * zyga has local family/kids interrupt
<cjwatson> stgraber: thanks, removed now
<xnox> doko: a cross-buildable libnih is uploaded, but it does _not_ declare two ":native" build-deps. One can work around that by manually running: apt-get build-dep libnih; apt-get build-dep libnih -aarmhf. Wiki updated to yellow/DEP status for sbuild :native support.
<xnox> jodh, libnih crossbuild fixes uploaded ^
<ev> mpt: bdmurray has pointed out that the rank of different problems on errors.u.c can swap quite often
<jodh> xnox: thanks!
<ev> we're wondering if there's a better way to handle this. Maybe a short hash of the problem instead of a ranking?
<roadmr> cyphermox: sorry for the delay, so say I prepare a branch of lp:checkbox with changes I want in ubuntu, how would I integrate them into lp:ubuntu/checkbox ?
<ev> so "9c3d" instead of "#10"
<ev> but you filed the original bug, so I want to make sure it covers your use cases
<bdmurray> ev: and what would that be used for?
<ev> bdmurray: identifying issues over the phone
<cyphermox> roadmr: you can apply the changes on the branch with a diff and upload/push, or just upload and let the importer do it
<cjwatson> ev: would a sequence number be workable?  it has the nice property that you can get a feel for how old an issue is
<roadmr> cyphermox: so you'd prefer to continue doing it the old way (with diff/patch) ?
<cjwatson> (perhaps it's too late to establish that, though)
<ev> we could always back populate them
<cyphermox> roadmr:  it would be much easier if it was branches you could work with directly
<mpt> ev, I suggest fixing bug 1033813 then seeing if that problem persists.
<ubottu> bug 1033813 in Errors "report of most common crashes "today" tracks calendar days, becomes useless when the clock rolls over" [High,Triaged] https://launchpad.net/bugs/1033813
<mpt> ev, because of that bug, early in any day, the rankings will take a while to settle.
<ev> mpt: yeah, you're absolutely right
<bdmurray> is it still early in the day now?
<roadmr> cyphermox: well "internally" that's the way I do it, I branch ubuntu/checkbox and patch my changes into that, but that gap where diff has to be used is the painful part :/
<doko> xnox, fixed ustr
<bdmurray> because the frequency difference between many crashes is quite small
<cyphermox> roadmr: right, but you can do away with this by using release branches and merging just the change you want when you're actually cherry-picking changes post-FF
<mpt> bdmurray, yeah, there are a lot of ties, even.
<mpt> bdmurray, for that reason, in bug 1068060 I suggested making "the past week" the default choice.
<ubottu> bug 1068060 in Errors ""the past week" is missing from table period menu" [Medium,Confirmed] https://launchpad.net/bugs/1068060
<bdmurray> so if that bug (default view of a week) were fixed then having the rank be a unique number would be more useful?
<mpt> I think so, yes.
<mpt> (Though it's hard to tell for sure, not being able to see those counts.)
<smoser> RAOF, around ?
<bdmurray> ev: would it be very challenging to see those counts?
<ev> bdmurray: when you say unique number do you mean the rank as we have it implemented or cjwatson's suggestion of using a sequence number?
<bdmurray> ev: I meant rank as it is currently implemented (without ties)
<seb128> bdrung, micahg, stgraber: hey ... I'm quite disappointed by the libreoffice ppu hostage situation, that's getting ridiculous that our maintainer who is handling for over 1.5 years and got strong endorsement from 3 coredev sponsors get rejected
<ev> so you're asking if making the week view the default is going to be challenging?
<zyga> roadmr: so you tell me it still hangs, after building just few modules in
<ev> yes - we'd first need to track a rolling 7 days and implement TPUT
<zyga> roadmr: can you confirm that it hangs in kvm with ovmf
<ev> we should do this though, definitely
<roadmr> zyga: yes, just the list cjwatson gave earlier, I get the very same error (variable 'prefix' isn't set). Sounds like a grub error to me
<bdmurray> ev: no, how hard would it be to use pycassa to figure out the frequency values for the top 50 for a week to see if there variance in frequency would be greater than now
<seb128> bdrung, micahg: what's this "lack of devel release uploads" btw? since when uploading devel release is a criterious to get upload rights?
<roadmr> zyga: sure, I don't have kvm with ovmf set up though so it'll take a bit
<zyga> roadmr: install kvm, I'll give you the stuff to download for ovmf
<bdmurray> because if the difference isn't greater we should move away from rank
<ev> oh, not terribly difficult. The date range selection lets us do something like that already.
<bdmurray> oh right! ;-)
<cjwatson> roadmr: the bit about prefix is a red herring
<zyga> roadmr: people.canonical.com/~zyga/ovmf.tar.gz -- careful the tarball has no directory inside
<cjwatson> it's basically just a minor misconfiguration such that grub tries to load something or other before it's got all its variables set up properly - but it continues on anyway
<roadmr> cjwatson: ok so we should focus on the next error then? error: no device connected. /me looks it up
<cjwatson> roadmr: you sure you removed pata?  what was your full grub-mkimage line?
<roadmr> cjwatson: http://paste.ubuntu.com/1509967/
<cjwatson> roadmr: please triple-check that that image is really the one you're booting, then, since it shouldn't be possible to get the message you're reporting with that configuration
<cjwatson> i.e. the code should simply not be present
<roadmr> cjwatson: you're right, I dumbly forgot to move it to the proper tftpboot location :/ fixing...
<roadmr> \o/
<cjwatson> better?
<roadmr> zyga, cjwatson : thanks! I got a grub menu now with several install options
<zyga> roadmr: try any
<cjwatson> great
<roadmr> yep, trying the first one, it put me in a d-i environment, install is proceeding now
<zyga> cool
<zyga> roadmr: is that on the desktop that failed before?
<roadmr> zyga: yep, the very same
<zyga> roadmr: so, what's it like?
<roadmr> zyga: it's like... heaven X-D
<roadmr> zyga: hehe install is progressing, no problems so far
<zyga> cool
<zyga> did you do that out of the existing certification infrastructure
<roadmr> zyga: yep, all I really had to change was the file that's sent to the client (in the dhcp server config)
<roadmr> zyga: that'd be quite easy to do with checkbox-satellite, with either a new plugin or a hack of an existing one
<zyga> that's very promising
<zyga> roadmr: we may need to differentiate systems
<zyga> roadmr: we don't have a 'boot via efi' flag, do we?
<roadmr> zyga: nope, that'd be one way to do it (in c3 for instance)
<zyga> roadmr: I'm not that familiar with that part of the system, how else could we do it?
<roadmr> zyga: for experimentation purposes we could add a parameter to launch_testrun to force efi boot for a batch of systems
<zyga> roadmr: dding a flag is not easy, that involves generating message files and those come from the cert site which we don't control
<roadmr> zyga: I think configuring it in one place, per-system, and not worrying about it anywhere else, would be the way to go
<zyga> roadmr: yeah
<kdub> hey all, say I have to have different build rules for different architectures (eg, armhf and amd64)... what is the best way to do this in debian/rules?
<zyga> kdub: I'd use ifeq sections
<zyga> with a bunch of tests on DPKG_ARCHITECTURE (right?) althought I'm not recent on the cross building foo that was added everywhere
<kdub> zyga, its enough to start googling though, thanks, I just wanted to make sure I'm not totally barking up the wrong tree
<zyga> wookey: ^^
<roadmr> cyphermox: apologies for pestering you incessantly :) I'm not too clear on how your release branches idea would ease our lives, maybe an example?
<cjwatson> kdub,zyga: DEB_HOST_ARCH would be the variable to conditionalise on
<roadmr> zyga, cjwatson : install was successful, system is up and running now :D
<zyga> cjwatson: thanks, I need to do some native development once in a while
<zyga> roadmr: excellent
<zyga> roadmr: so
<cjwatson> (and isn't new - there's never been a DPKG_ARCHITECTURE that you might use in debian/rules, although some people might mistakenly have used DEB_BUILD_ARCH I suppose which would break under cross-building)
<cjwatson> roadmr: oh good
<zyga> roadmr: update the taskboard with the cool success story :)
<roadmr> zyga: yes!
<cjwatson> and update the wiki page if you'd be so kind, too
<zyga> cjwatson: ah, I was confused with dpkg-architecture that spits them out :)
<zyga> cjwatson: good point
<kdub> thanks cjwatson
<doko> cjwatson, xnox: uploaded build-essential to b-d on python3:any. but looking at your libnih upload, python3:native might be more appropriate? just want to make sure that the interpreter can be executed
 * xnox ponders if it's possible to cross-compile when the current machine arch != DEB_BUILD_ARCH. If that is possible, :any will work yet :native might not be executable.
<cjwatson> DEB_BUILD_ARCH must be of an arch you can execute
<cjwatson> and yes, it's possible, I do it all the time
<cjwatson> doko: I'm not sure it makes a practical difference, THB
<cjwatson> TBH
<xnox> interesting.
<cjwatson> xnox: (specifically, i386 host system, amd64->armhf cross-build chroot)
<cjwatson> (though amd64 kernel)
<cjwatson> amd64 kernel and host system with i386->armhf cross-build chroot would work equally well
<infinity> cjwatson: Remind me of the location of your sbuild-cross wiki cheat sheet?  I'm redoing my whole setup, and that's falling off my stack since I last did it.
<cjwatson> infinity: https://wiki.ubuntu.com/CrossBuilding
<infinity> cjwatson: How am I ever supposed to find wiki pages with such clear, simple, and obvious naming schemes?
<kdub> when I'm making my chroot with pcreate, I can't seem to get it to take my keyring from the host's /etc/apt/trusted.db, the chroot always has the default keyring. any suggestions?
<infinity> tkamppeter: I assume there's already a cups upload in the works that will rm_conffile /etc/logrotate.d/cups from cups?
<infinity> tkamppeter: (Or some other way of avoiding the duplicate conffile between cups and cups-daemon that's making logrotate sad)
<soren> Where can I find information about the tests that are run before packages move from proposed to release?
<infinity> soren: Nowhere, because none are run currently.
<soren> infinity: Oh, the autopkgtest stuff never happened?
<infinity> soren: It's in progress, but it's not plugged into proposed-migration/britney yet.
<soren> Hm. Ok. I must have misinterpreted some conversations then.
<soren> infinity: Alright, cool. Thanks!
<cjwatson> soren: Yeah, I meant to finish that integration last month but ran out of year
<soren> cjwatson: There was a lot of that going around a couple of weeks ago.
<soren> I don't even know... Are we running the auto-pkg-tests at all yet?
<infinity> soren: We are, yeah.  Just not tied into migration.
<soren> Cool.
<soren> Where can I see the output from those tests?
<cjwatson> jenkins.qa.ubuntu.com
<dkessel> https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/
<infinity> https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/
<dkessel> :)
<dkessel> hello. i wrote one or two of those tests in december
<soren> Oh, each package with autopkgtest tets get a corresponding Jenkins job?
<jtaylor> yes
 * infinity needs to sort out what to do about glibc's testsuite and kvm not getting along.
<infinity> I assume it's probably actually qemu bugs, but finding and fixing those sounds like serious effort.
<soren> One thing about these tests that I haven't really worked out... Why not run the tests during the package builds so that the build can be rejected earlier? I undertand some tests will have lots more dependencies, but some of the example use cases are simply the unit tests.
<infinity> soren: This isn't an either/or thing.  Packages that have build-time testsuites SHOULD be running them, and absolutely SHOULD fail the build if the test fails.
<infinity> soren: But autopkgtest is meant to test a slightly different thing, which is how the actual debs themselves work when installed.
<soren> infinity: So what's the benefit of adding an extra run of those same tests?
<cjwatson> there's stuff in the autopkgtest docs about rationale
<cjwatson> but aside from that, running them this way lets us rerun tests of reverse-dependencies when their dependencies change
<infinity> soren: Running the same tests against a build tree doesn't often make sense (unless it's an rdep rebuild test, as the toolchain does), but tearing out tests and running them against installed binaries can be quite enlightening.
<cjwatson> lets us catch the "somebody changed pygobject and it broke ubiquity" case
<cjwatson> (say)
<soren> That makes sense.
<soren> We've been doing that in Ubuntu-server for a while, actually.
<tumbleweed> and it lets you test that the installed package is functional (that you didn't miss out a vital file)
<Chipzz> infinity: I'ld say that a lot of software isn't designed with that in mind
<infinity> Chipzz: Yes, but that's fixable. :P
<soren> We had a cron job that would take a bunch of packages, bump the version and push it to a ppa to see if the test suites still passed.
<soren> I think it has caught a few things that were introduced by changes to a library the the package in question depended on.
<soren> It's been rare, though.
<Chipzz> infinity: it should also be documented how to run these tests. A couple of weeks ago I wanted to run a python test against my installed python, but it took me a bit to figure out how
<Chipzz> (wasn't on ubuntu though)
<infinity> Chipzz: In the later years of Maemo, Nokia QA was requiring that every single package that was part of the official published API also build a testsuite package (foo-tests depended on test-harness and foo), so their test harness could test debs on the fly.  It took some wrangling to decouple tests from builds, but when coverage increased, it became obviously useful.
<Chipzz> right. but there the tests are written with the intention of being able to run them outside the source tree
<cjwatson> If they're fixable, we fix them.  If they're not, (a) why wouldn't they be, this is free software, (b) it isn't actually mandatory to have autopkgtests
<infinity> Chipzz: Usually not.  The tests were often us tearing build-tree unit tests out and fixing them to not make in-tree assumptions (and skipping ones that obviously only make sense at build-time)
<Chipzz> I have no proof for this, but I would say that the majority of tests a) isn't designed to be run that way and b) isn't even tested outside the build tree at all
<cjwatson> Chipzz: This doesn't matter.
<cjwatson> It's a distraction.
<infinity> Anyhow, unlike Nokia, we're not mandating anything.
<infinity> So, if you don't want an autopkgtest suite, don't have one.  And wait for some clever fellow to come along and contribute fixes.
<cjwatson> So, sure, it might take some work.  Whatever.
<cjwatson> It's still better than nothing.
<Chipzz> cjwatson: not 100% sure how to interpret your statement. If you mean I'm derailing the discussion, I'll gladly shut up
<cjwatson> I don't see what useful thing it contributes to say that some tests aren't designed for this
<cjwatson> Yes, we know, but it's not relevant because either we fix them or we don't have autopkgtests for that package
<cjwatson> It manifestly hasn't stopped us from having quite a number of autopkgtests already
<cjwatson> And IME it in fact turns out that plenty of test suites already find it convenient for their own purposes to parameterise the locations of the things they're testing
<cjwatson> Sure, not all, and there are often lots of little glitches
<cjwatson> But it's not a doomed endeavour
<cjwatson> autopkgtest has an option to require a built tree to be present, which lets you not have to solve the whole problem at once: you get the feature of retesting things automatically when their dependencies change, without having to fully parameterise the test suite
<Chipzz> cjwatson: anyway my apologies. I tried to join a discussion when I was lacking some of the context I think
<jtaylor> python testsuites are usually very well suited for autopkgtest
<jtaylor> many run from installed locations out of the box
<jtaylor> if the package installs them
<jtaylor> on the otherhand many are not written for integration tests and are not particulary useful
<glesiak> Hi guys. I am planning to buy laptop and I wanted to ask ubuntu dev community if you have some exp with ulv cpus. Can ultrabook be a good machine for software developer ?
<zul> mterry: ping for some reason i cant get the testsuite to run for testrepository
<lifeless> zul: hi
<zul> lifeless: hey so i tried using make check and it doesnt work
<zul> at all
<lifeless> zul: make check 2>&1 | pastebinit
<lifeless> http://paste.ubuntu.com/1510422/
<lifeless> zul: thats what you should see from a source tree.
<mterry> zul, hyeo
<mterry> zul, I'm in a bit of a fire-fighting mode over here, my hard drive may have died
<zul> mterry: ok ill check back later
<zul> lifeless: http://paste.ubuntu.com/1510427/
<lifeless> zul: you're not running it from source?
<lifeless> zul: bzr branch lp:testrepository
<zul> no from the archive
<lifeless> oh, its not setup to dist all the ancilliary files
<lifeless> a quick look though suggests that that may be all thats missing, I'll add it to MANIFEST.in
<lifeless> theres no other inventory right now - trunk is 0.0.11 exactly.
<lifeless> zul: I'll roll another release after work today
<lifeless> zul: for now, you can get the .testr.conf from bzr and drop it in as a debian/patches patch
<zul> lifeless: ok cool
<lifeless> hmm, I really need to update this stack in debian
<lifeless> and/or hand over to the PPT
<carif> I just read https://help.ubuntu.com/community/SbuildLVMHowto to learn how to sbuild, but I still have a very basic question. What does the logical volume management provide? A fast way to make an initial copy of the chroot before a build?
<jtaylor> yes, via writable snapshots
<jtaylor> cowbuilder provides something similar and may be much simpler
<arges> tyhicks: hey
<tkamppeter> infinity, I have fixed the conffile problems of CUPS in Raring yesterday, as -0ubuntu15.
<tkamppeter> infinity, for Debian CUPS is fixed in the GIT repo, so 1.6.1-1 will come out correctly.
<tyhicks> arges: hi
<arges> tyhicks: hope you had a good new years
<tyhicks> arges: I did. Hope yours went well, too.
<arges> tyhicks: yea pretty good. spent some time away from the computer so that helps : )
<tyhicks> same here :)
<arges> tyhicks: i was looking at bug 1052038
<ubottu> bug 1052038 in eCryptfs "ecryptfs_fnek_sig missing when login at the same time on cron session close" [Medium,In progress] https://launchpad.net/bugs/1052038
<arges> tyhicks: did you have any updates with that? i know there was something blocking it
<tyhicks> arges: I put a halt on it because hallyn had thought he found a regression. Turns out that there was no regression and the SRU should still be in the queue.
<tyhicks> arges: Let me review the wiki and make sure that I have the bug in all of the correct states and the correct teams sponsored
<arges> tyhicks: ok cool I appreciate it
<RAOF> smoser: Not at 3am
<tyhicks> arges: everything looks good, according to https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<tyhicks> arges: I think we're just waiting on someone from ubuntu-sru to start processing it
<arges> tyhicks: ok. I was just doing the rounds and I didn't see any updates on it.
<arges> cool
<marrusl> hey.  how is the "Supported" field generated generated?  I gather it's in Packages.gz, but I'm not sure how it gets there.
<marrusl> (IOW, how can end users generate them for their own repos)
<marrusl> there must be a better way than editing Packages.gz directly.  though I guess that would do the trick.
#ubuntu-devel 2013-01-09
<vsingh165> anyone here know why I can't branch or checkout the lp:df-libreoffice branch?  it always seems to get stuck at 10639 kB
<vsingh165> when I bzr branch lp:df-libreoffice in terminal, I get "Write failed: broken pipe" errors
<sladen> vsingh165: report a bug
<infinity> doko_: Why do crossbuild-essential-* depend on pkgbinarymangler?  That's pretty buildd-specific, and regular build-essential doesn't depend on it.
<infinity> doko_: (And, sure, you need pkgbinarymangler if your non-cross arches also use it, but conversely, if not, you need to not have it, so it should be something installed/enabled in the chroots by end users, not forced by dependencies, no?)
<tkamppeter> infinity, did you see my answer about CUPS?
<infinity> tkamppeter: Yeahp, thanks.  Noticed the upgrade removed the obsolete file here, and cron should shut up now, thanks.
<pitti> Good morning
<doko> infinity, just did take that from wookey. didn't know if cjwatson's test build adds it explicitly
<doko> xnox:
<doko> checking for pkg-config... /usr/bin/pkg-config
<doko> checking pkg-config is at least version 0.22... yes
<doko> checking for DBUS... no
<doko> configure: error: Package requirements (dbus-1 >= 1.2.16) were not met:
<doko> No package 'dbus-1' found
<doko> looks like libnih still uses the wrong pkg-config binary
<infinity> $crossbuild_core_depends = { armhf => ['build-essential', 'gcc-arm-linux-gnueabihf', 'g++-arm-linux-gnueabihf', 'pkg-config-arm-linux-gnueabihf', 'dpkg-cross']
<infinity> doko: ^-- What Colin and I use (and, I assume, his testbuilds)
<StevenK> 'gnueabihf' sounds like the noise you can make while sneezing.
<infinity> doko: The extra interesting thing there is that your crossbuild-essential has a cross-arch libc6-dev:crossarch dep, while we're just relying on gcc-arm-linux-gnueabihf to get it right, I guess?
<doko> infinity, yes, you have to install the runtime target libs "twice", or else the shlibs files won't be found
<infinity> doko: That's... Special.
<infinity> doko: Anyhow, I have no opinion on the libc6-dev:armhf thing (and just caught up on the discussion in the Debian bug), but we should drop the pkgbinarymangler bit and leave that to the discretion of people building/managing their chroots.
<infinity> (As in, mk-sbuild will do it for you by default with --distro=ubuntu, but it shouldn't be a hard dep, for people who prefer not to mangle)
<cody-somerville> seb128: Hey. I run into LP #930563 in case you need help debugging the issue.
<ubottu> Launchpad bug 930563 in libdbusmenu (Ubuntu) "NM Applet menu entries not responding" [Low,Confirmed] https://launchpad.net/bugs/930563
<seb128> cody-somerville, hey, it would rather be something for larsu/charles/cyphermox
<cody-somerville> kk.
<cody-somerville> cyphermox: I'm quite certain that LP #985028, LP #933300, and LP #930563 are the same.
<ubottu> Launchpad bug 985028 in network-manager-applet (Ubuntu) "nm-applet stops displaying VPN connections" [Medium,Confirmed] https://launchpad.net/bugs/985028
<ubottu> Launchpad bug 933300 in network-manager-applet (Ubuntu) "nm-applet needs restart after resume" [Medium,Confirmed] https://launchpad.net/bugs/933300
<ubottu> Launchpad bug 930563 in libdbusmenu (Ubuntu) "NM Applet menu entries not responding" [Low,Confirmed] https://launchpad.net/bugs/930563
<cody-somerville> cyphermox: https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/930563/comments/8 is the key I think.
<ubottu> Ubuntu bug 930563 in libdbusmenu (Ubuntu) "NM Applet menu entries not responding" [Low,Confirmed]
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<cjwatson> doko: My chroots are made with mk-sbuild, which adds pkgbinarymangler by default, so I don't need crossbuild-essential-* to add it as well
<doko> ok, will remove it with the next upload
<xnox> doko: well when doing cross it does two builds: native and then cross. Do you have full log? (my cross-chroot is not very minimal, maybe I should reset it up)
<xnox> doko: and did that build install both native&cross build-deps? (I didn't add :native build-deps since that is not supported just yet by sbuild)
<cjwatson> I'm surprised that it works to do one build in a subdirectory and another in the source tree itself
<cjwatson> I thought automake complained about that
<cjwatson> usually when I need to do one build in a subdirectory I convert all the builds to do that
<doko> xnox, http://people.canonical.com/~cjwatson/cross/armhf/raring/
<cjwatson> doko: that's the native build pass
<cjwatson> doko: so it's correct for it to use /usr/bin/pkg-config
<xnox> cjwatson: hm. I was dubious about how the configure cache is handled. I think native build cache leaks into cross =/ but didn't look deeper into it.
<cjwatson> doko: the problem is the known one that we don't yet have a way to declare the native build-dependency
<doko> ahh, ok
<xnox> (unless it's not leaking but using the preload)
<cjwatson> xnox: config.cache is in the build directory, so shouldn't leak; but the one preset by dpkg-cross might
<cjwatson> xnox: you could unset CONFIG_SITE for the native build pass, perhaps, although that seems like quite a big hammer
<doko> well, isn't CONFIG_SITE plain wrong for the native build?
<cjwatson> when it's been set by dpkg-cross, yes
<cjwatson> or rather to the dpkg-cross config
<cjwatson> I can imagine somebody using it for other purposes, although we don't
<cjwatson> but that's probably not worth worrying about - sounds best to unset it
 * cjwatson applies http://paste.ubuntu.com/1512288/ to groff, for comparison
<doko> https://wiki.ubuntu.com/CrossBuilding/BuilddChroot looks pretty complete now, besides perl and linux
<xnox> doko: I just uploaded DEB_STAGE=stage1 build variant for libsemanage. So we should be mostly done now =)))))
<didrocks> pitti: mind rejecting https://code.launchpad.net/~jelmer/ubuntu/raring/etckeeper/merge-debian/+merge/141431?
<pitti> didrocks: done
 * cjwatson looks at kmod
<didrocks> thanks pitti :)
<cjwatson> oh, sorry jelmer, I didn't notice that MP
<cjwatson> I kept the change of default to bzr in my merge
<cjwatson> so if you still want to revert that, then propose another MP with just that, I think
<doko> barry`, maybe ask the debian maintainer before starting packaging the pil fork. I already have it packaged
<bdrung> Laney: re bug #954352, do you have the prepared package at hand? i haven't prepared anything yet. so it could take more time for me than for you.
<ubottu> bug 954352 in gtk+3.0 (Ubuntu Raring) "Enable wayland backend" [Wishlist,Triaged] https://launchpad.net/bugs/954352
<Laney> bdrung: yeah, let me get the debdiff
<Laney> bdrung: http://paste.debian.net/223087
<didrocks> doko: hey, I'm wondering why https://launchpadlibrarian.net/127995793/buildlog_ubuntu-raring-i386.efilinux_1.0-3ubuntu1_FAILEDTOBUILD.txt.gz is only failing on i386 and amd64. I'm not really motivated to add -fno-stack-protector. Any help?
<didrocks> and *not* on amd64
<bdrung> Laney: shouldn't have the symbols version a trailing ~ (for backport reasons)?
<Laney> yep
<Laney> i didn't upload it yet :-)
<bdrung> Laney: as you wrote, we need to get a MIR for libxkbcommon first
<cjwatson> didrocks: the other question is why you uploaded a merge from somebody who didn't touch it last and hadn't talked to the previous uploader, who might have had a merge in progress ...
<doko> didrocks, well, should be clear if build with -nostdlib
<Laney> bdrung: I'm not massively interested in working on it, so feel free to check with #ubuntu-x
<Laney> I get the feeling that it's experimental so won't be allowed in
<didrocks> cjwatson: I was just doing my patch pilot sponsoring and waiting to help clean the queue. The merger from debian seemed straightforward enough to be handle and builds fine on my amd64
<cjwatson> didrocks: that doesn't answer my complaint, at all
<cjwatson> sponsoring is not an excuse for doing it wrong
<bdrung> Laney: it's relatively new. there were no release, when the ubuntu package was created, but now there is a 0.2.0 tarball:  http://cgit.freedesktop.org/xorg/lib/libxkbcommon/log/
<didrocks> ok, I'll keep that in mind for the next sponsoring shift and only touch my area
<cjwatson> no, that isn't what I said
<didrocks> doko: let me have a look
<cjwatson> People being sponsored need to be educated how not to step on people's toes
<cjwatson> That doesn't mean exaggerating to "only touch my area"
<didrocks> cjwatson: well, in that case, it's easier to wait that the other people is doing his shift (if they do itâ¦)
<bdrung> Laney: i will ask in #ubuntu-x . can you attach your debdiff to the bug report?
<cjwatson> didrocks: sure, because those other people are off relaxing on the beach rather than doing other useful work, I'm sure
<cjwatson> (I'm quite tired of the insinuations about sponsoring)
<didrocks> for things that seems easy people directly uploads them, like when people multiarched the unity stack, and didn't use the right branches, I didn't scream at "you are stepping on my toes"
<cjwatson> didrocks: We've had a notice on merges.ubuntu.com for eight years that people should check with the previous uploader before merging
<cjwatson> It's not like it's news
<didrocks> cjwatson: oh, it's not about you, TBH, I even don't know who is doing their shift and who doesn't, I just see a lot of complain from dholbach that a lot are not doing
<cjwatson> Yes, dholbach isn't fixing cross-builds either
<cjwatson> We all do things
<didrocks> I agree, that's why I didn't complain and try to help getting things clean
<didrocks> for things that seemed straightforward and builds fine, I didn't think about that would bother others, sorry for that
<cjwatson> (Actually, Logan did say to me in private mail that he was going to do better about contacting the previous uploader in future - so that's OK until the next person :-) )
<cjwatson> What I want is for this to be a check in the sponsorship process; I agree that in this case it was fairly untroublesome, but in other cases it has caused me problems
<cjwatson> I don't know how to achieve this efficiently
<didrocks> the issue is that we have too many ways to get things in, but that's just IMHO
<cjwatson> (For instance something that's deliberately not being merged for one reason or another)
<didrocks> but I agree with your remark
<cjwatson> didrocks: And very few efficient ways to say "no" in a way that sticks :-/
<didrocks> right
<cjwatson> didrocks: So sorry, I was too harsh on you, I need coffee :-)
<didrocks> cjwatson: no worry, I can understand the feeling, I hope I didn't sponsor anything you didn't want in :)
<Laney> bdrung: done
<bdrung> thanks
<cjwatson> I guess what I'd really like is a more reliable way to notify interested people about things pending sponsorship
<cjwatson> Right now, if somebody proposes a merge to a package I touched recently, I only find out if they explicitly ask for my review, or if I watch the whole sponsorship queue
<bdrung> cjwatson: good ideas are welcome. maybe we could add some information the the sponsoring queue?
<infinity> cjwatson: Yeah, if I could more easily subscribe to these things, I wouldn't care about losing TIL on all my merges (which happens all the time)
<cjwatson> bdrung: The problem with approaches that involve more information on the sponsoring queue is that you still have to watch the queue to see them
<cjwatson> bdrung: I think I want LP's default who-gets-asked-for-review to be smarter
<infinity> It really irks me to lose TIL on merges (which reminds me, I need to steal dpkg back from you), cause then they go off my radar.
<cjwatson> infinity: And for some reason we advertise merges as a good thing for people to do when they're learning
<cjwatson> I've *never* understood that
<infinity> Probably because many of them (like the eflinux one above) are really trivial.  But the knock-on effects of "stealing" trivial merges from other people are pretty irritating.
<cjwatson> Merges tend to be either trivial or REALLY REALLY HARD
<infinity> Yup.
<cjwatson> And if you aren't experienced you can't tell which in advance
<cjwatson> didrocks: So, I can solve the losing-TIL problem for efilinux by fixing up that build failure for you, if you like ;-)
<didrocks> cjwatson: indeed, that's a way to do it. I don't like cleaning what broke under me, but if there is a benefit for you, sure, please do :)
<didrocks> grrr
<didrocks> I don't like *not* cleaning
<didrocks> 2 *not* missing in less than 30 minutes, need coffee as well :)
<cjwatson> doko: Shouldn't -ffreestanding inhibit use of the stack-protector?  I'm sure it used to
<cjwatson> Oh, wait, the problem might be in gnu-efi
<cjwatson> Hah, and slangasek dropped the -fno-stack-protector bit there saying that it was no longer needed
<cjwatson> LIES
<didrocks> :)
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> didrocks: OK, fix on its way now, although it won't involve reuploading efilinux
<cjwatson> Them's the breaks
<didrocks> cjwatson: just a rebuild once gnu-efi rebuilt from what I saw. Well, if someone contacts me for this package, I'll redirect it to you
<cjwatson> Yeah, no worries
<cjwatson> xnox: I've sorted out the gluegen2/armhf horribleness, I think
<cjwatson> So we should be able to crawl up that stack shortly and get opencv promoted
<xnox> \o/
<pitti> didrocks: nice progress on the sponsoring queue!
<didrocks> pitti: thanks :)
<pitti> hm, ubuntu-drivers-common just started failing, bcmwl doesn't compile any more
<pitti> and testing locally confirms it
<pitti> tseliot: ^ seems the "support 3.8" broke 3.7?
<pitti> Fehler: Â»struct cfg80211_ibss_paramsÂ« hat kein Element namens Â»chandefÂ«
<pitti> tseliot: filed as bug 1097729; should we revert the change for now, or do you think it could be made to work with both kernels/
<ubottu> bug 1097729 in bcmwl (Ubuntu Raring) "6.20.155.1+bdcom-0ubuntu3 stops building on current raring" [High,Triaged] https://launchpad.net/bugs/1097729
<pitti> ?
<wookey> where do I go to ask questions when apt is apparently doing daft things?
<wookey> Currently in a raring chroot if I try to install libgcc1:arm64 apt wants to remove all of essential. I don;t understand why...
<wookey> is there an apt irc channel or debugging info somewhere?
<cjwatson> wookey: #debian-apt on OFTC
<cjwatson> wookey: Also -oDebug::pkgProblemResolver=true
<infinity> wookey: Is that the same version of libgcc1 that you have on your other arch (or is it otherwise causing a version skew that would break the world)?
<infinity> wookey: That's the only obvious thing I can think of.
<wookey> aha. 4.7.2-17ubuntu2 vs 1:4.7.2-17ubuntu2. I bet that's bloody it!
<wookey> mutter
<wookey> the annoying hting is that the error message you get from apt about this is 'libc6:arm64 depends on debconf:arm64' which is just wrong, and thoroughly misdirectful
<wookey> I guess multiarch is going to produce more of this sort of mysteriousness
<cjwatson> that's particularly curious since debconf is M-A: foreign
<wookey> exactly
<wookey> I was thoroughly nonplussed
<barry> doko: where is it?  i looked didn't find it.  it's a different source package
<wookey> I'm not sure what to do with this sort of problem. take it to the deity list?
<cjwatson> perhaps, yeah
<infinity> wookey: Which problem?  The unhelpful error message, or you asking apt to do something you shouldn't?
<wookey> analysis with libdose can be helpful but that said everything was OK.
<wookey> apt giving unhelpful meessages when I ask it to do womthing it shouldn't :-)
<infinity> Heh.
<cjwatson> the problem with analysing with some other tool is that half the time you find yourself analysing why they differ
<cjwatson> hello, yak-shaving
<tseliot> pitti: let me check. I'm pretty sure there's a check which applies only to 3.8
<wookey> cjwatson: indeed. but I don't know how to get more detailed info out of apt about why it thinks what it things. I recall there is some, but I failed to find info on it yesterday
<cjwatson> generally you get more detailed info by adding more of the packages it complains about to your apt-get install line until it gives you a real error
<cjwatson> and as I say -oDebug::pkgProblemResolver=true can be helpful although it takes practice to read
<wookey> searching for apt debug on google gets you some astronomical windows tool apt.exe
<cjwatson> between them those two strategies are usually enough
<pitti> tseliot: a mere "sudo apt-get install bcmwl-kernel-source" on current raring reproduces it
<wookey> right. I knew the 1st but not the second.
<tseliot> pitti: true, I can reproduce it here. I'll fix it
<pitti> tseliot: thank you!
<Chipzz> wookey: while U agree that apt's error messages could sometimes be improved upon, I'm not sure how simple that would be
<Chipzz> *I
<wookey> Chipzz: Yes. That may well be the b3est that it can do, but I'd like to be assured of that by someone :-)
<Chipzz> the solver probably is quite complex
<cjwatson> wookey: BTW have you seen https://wiki.ubuntu.com/CrossBuilding/BuildChroot?
<wookey> Really I thinbk we just need some easy-to-find docs on how to debug
<wookey> no such page?
<cjwatson> wookey: Sorry, https://wiki.ubuntu.com/CrossBuilding/BuilddChroot
<bdrung> mdeslaur: see bug #1084054
<ubottu> bug 1084054 in vlc (Ubuntu Precise) "Denial of service via crafted PNG file" [Undecided,Confirmed] https://launchpad.net/bugs/1084054
<wookey> nice
<barry> didrocks: any chance you could take a look at https://code.launchpad.net/~barry/oneconf/py2py3/+merge/141001 ?
<didrocks> barry: not today, but it's on my list :)
<wookey> we need to agree on our DEB_STAGE/BUILD_PROFILE bootstrap/stage1 terminology before we do too much more of this...
<mdeslaur> bdrung: sarnold is on community this week, he should be picking it up. thanks!
<barry> didrocks: okay, thanks!
<bdrung> mdeslaur: i saw your comments on bug #1095434 and bug #1096193
<ubottu> bug 1084054 in vlc (Ubuntu Precise) "duplicate for #1095434 Denial of service via crafted PNG file" [Undecided,Confirmed] https://launchpad.net/bugs/1084054
<ubottu> bug 1084054 in vlc (Ubuntu Precise) "duplicate for #1096193 Denial of service via crafted PNG file" [Undecided,Confirmed] https://launchpad.net/bugs/1084054
<bdrung> sarnold: time to sponsor vlc?
<micahg> didrocks: thanks for working on the sponsorship queue, could you please try to remember to check the .changes file for the appropriate changelog entries when sponsoring merges (I know UDD makes this more difficult than grab-merge)
<wookey> OK. fixing the epoch on libgcc1 means it gives a much more sensible message:  libgcc1:arm64 : Conflicts: libgcc1 but 1:4.7.2-17ubuntu2 is to be installed
<wookey> aha. yes. I've failed to push my equivs patch to enable Multi-Arch: foo upstream
<wookey> yee-ha. only taken 3 days to get that package installed :-) Now I should be able to do sbuild raring arm64 cross-builds
<tumbleweed> didrocks: looks like you forget to use -v a few times when sponsoring merges today. And I'm noticing too late to make any difference...
<micahg> tumbleweed: and I mentioned it 13 minutes ago :)
<micahg> err...13 minutes previous to you
<tumbleweed> ah, I lastlogged for -v, you didn't match :)
<micahg> yeah, I figured people keep asking what it is (which I guess is a problem in and of itself, but, meh)
<micahg> and syncpackage seems to not be doing it properly either ATM...
<micahg> ah, maybe that's for the first sync into the series
<tumbleweed> syncpackage is only responsible for the changes it shows you and closes bugs with
<micahg> it does that part properly ;)
<micahg> it's the LP side that seems broke
<micahg> I"ll have to make sure a bug is logged later
<zul> mterry:  ping
<mterry> zul, heyo
<mterry> zul, I'm mostly back up and running, I can take a look at the mirs again
<zul> mterry: cool they should be ok now
<stokachu> chrisccoulson: Was there a email or any documentation relating to acroread not being built after Precise?
<cjwatson> The partner maintainers asked for packages in partner not to be automatically carried over to the next release
<cjwatson> So if it hasn't been published in later series then that's because none of the partner maintainers saw fit / remembered to reupload it
<stokachu> should i ping one of them about it?
<cjwatson> I gather this was something to do with contracts not necessarily covering all series
<cjwatson> Yes
<stokachu> ok
<stokachu> thanks :)
<mterry> zul, your testrepository upload ftbfs
<zul> mterry:  ubuntu3?
<mterry> zul, yeah
<zul> mterry: i just uploaded ubuntu4
<didrocks> tumbleweed: micahg: sorry not enough sleep and yeah, I noticed it once I sent my report :/
<mterry> zul, ah cool
<zul> mterry:  when i run it locally it runs fine
<mterry> zul, this was in a pbuilder
<mterry> zul, maybe a missing depend?
<zul> mterry: ubuntu4?
<mterry> zul, yeah
<zul> dont think so
<mterry> zul, it finishes the build.  And I didn't test it actually running
<mterry> zul, this is just output from the build
<mterry> zul, looks like it tried to run some tests, failed, but didn't fail the build
<zul> mterry: it runs just fine when its used in the nova build
<doko> cjwatson, infinity, pitti: udev b-d's on usbutils. should this be m-a foreign?
<pitti> doko: usbutils M-A: foreign sounds right to me
<cjwatson> Yeah, agreed
<doko> ok
<psusi> cjwatson: I'm going to apply to become a debian maintainer and was wondering if you would mind signing my gpg key? A70FB705
<cjwatson> psusi: We'd need to exchange key material in person
<cjwatson> I would hope that nobody here would sign a key on the strength of an IRC conversation :-)
<psusi> really?  years of irc conversations, being registered with lp, used to sign many emails, my ppa, all not enough? ;)
<cjwatson> Sorry, pretty standard practice
<psusi> wish I had remembered that last time uds was here
<cjwatson> I'm happy to sign a key at the next conference when we meet
<psusi> heh, when will UDS be back in Orlando? ;)
<cjwatson> Well, it's been twice now so presumably the odds aren't awful
<xnox> look up on db.debian.org for DDs near you & meet in person.
<psusi> hrm...
<Laney> argh
<Laney> I got a keysigning request ages ago and forgot to set up a meeting
<psusi> xnox: doesn't seem to show where they live...
<xnox> there is also a keysigning page on debian wiki
<xnox> that has locations.
<Laney> http://wiki.debian.org/Keysigning/Offers
<hrw> psusi: conferences are one of best ways to get key signed.
<hrw> at last Linaro Connect I hunted down Linaro kernel hackers for example
<psusi> yea.. damnit, I should have done that.. seems signatures just aren't needed in the Ubuntu community though so I guess I was a bit lazy
<hrw> psusi: fosdem in 3 weeks?
<hrw> probably too soon
<psusi> yea, I can't fly half way around the world ;)
<psusi> ahh, damn.. next uds is in copenhagen
<Laney> what makes you think that?
<cjwatson> uh, wasn't that the last one?
<Laney> the /previous/ one was
<roadmr> psusi: hmm I don't think so, that was in November and I doubt it would repeat
<roadmr> psusi: probably an outdated page
<pitti> psusi: I heard rumours about Oakland
<psusi> ohh, you're right.. guess the page hasn't been update
<pitti> psusi: FWIW, you could have spent five years as "psusi" and your name could still be Eduard Frankenstein -- IRC personality vs. official authority document :)
<psusi> when you sign the key in person do you authenticate my birth certificate? ;)
<pitti> (and it is totally okay to call yourself anything you like in the interwebs, that's not uncommon)
<pitti> psusi: well, passport, ID card, something like that
<pitti> at least you need to meet someone in person, preferrably more than once
<psusi> ohh... so this is... what's it now... that high level of trust type signature they talk about in the manual, not just normal?
<pitti> it is certainly conceivable to generate a GPG key with an identification of "https://launchpad.net/~psusi"
<pitti> but ordinarily you create GPG keys with your real name/email
<pitti> I don't need to sign your key to trust that lp.net/~psusi can control /~psusi/+gpgkeys
<pitti> but if I want to ensure that those key bits are controlled by a person called "Phillip Susi", I need to see an official ID with your photo and your name
<cjwatson> I *have* signed the odd person's key in the past based on an IRC conversation, but only people I know very well so that I can e.g. have some way to satisfy myself that they're the same person that I know offline
<cjwatson> And sometimes I do say that if somebody is impersonating so-and-so then they've been doing a good enough job of it for long enough that they deserve to win
<pitti> if I have met someone personally once, I would be comfortable having her/him read out the fingerprint over the phone, and tell me how/when we met if I can't recognize the voice reliably
<psusi> sure.. but sending an encrypted email and verifying I can read it verifies the pairing of email address and key... and the fact that I've been signing email with that key for years is pretty good indication that someone didn't just make it up and hack my email.. about the only possibility is that I've been lieing about my real name all these years, and well... that just seems a little paranoid
<cjwatson> But I have to know them personally for that; I don't have a good enough social brain to convince myself that a person I'm talking to on IRC now is the same person I've been talking to before
<cjwatson> Basically, diverging from the standard safe procedure means that I have to think really hard about whether this might be a social-engineering attack
<pitti> psusi: there are quite a number of community members who prefer working under a pseudonym
<cjwatson> And that's difficut
<cjwatson> +l
<pitti> psusi: i. e. you can trust the work of someone with a pseudonym without having to trust his real name
<cjwatson> Ubuntu is quite plausibly a high-value target of attack; I don't think it's paranoid to be careful
<psusi> right, so would it even matter if I had been using a false name this whole time?
<cjwatson> as is Debian
<pitti> tseliot: thanks!
<cjwatson> I don't think it would matter if you'd been using a false name, but I'm not willing to give up the "exchange key material in person" step
<pitti> psusi: not in terms of how other people regard your work
<cjwatson> Other people might feel it matters
<pitti> psusi: I would sign a key ID saying "https://launchpad.net/~psusi is an Ubuntu community member", if that would make any sense; but I couldn't sign an ID saying "Philip Susi", as I cannot verify that
<tseliot> pitti: thanks for reporting
<Daviey> pitti: So, you have seen my online identify of Dave Walker (Daviey) for a number of years now.. Would you consider that enough to sign my key, remotely.. without seeing supporting ID?
<Daviey> identity*
<pitti> Daviey: I know you in person and would trust myself to recognize your voice; so if I were to sign a key for you, I'd be content with calling your phone number and you reading me your fingerprint
<cjwatson> Likewise.  But if I *only* knew you online then I wouldn't sign a key base on that
<cjwatson> *based
<sabdfl> cjwatson, Daviey: I'm doubling your salary
<sabdfl> that's the problem with IRC identities :)
<cjwatson> rawk
<ogra_> LOL
<chrisccoulson> hah
 * xnox doesn't sign people's keys with documents I don't recognise. e.g. us driving license is meaningless to me. I've signed on us driving license only once, but that person was already in my web of trust.
<Daviey> hah.  Works for me.
<psusi> Daviey: depends on the type of signature... gpg defines different levels and one of them is to signify that yes, you are attesting that the persons' name is correct... but there are others that just mean you are sure that someone else is not impersonating the person you know
<maxb> Unfortunately those levels of signature aren't nearly well defined or publicised enough
<Daviey> Well, people use them very differently
<cjwatson> psusi: the uses of the web of trust in Debian generally consider any signature to be sufficient, 
<cjwatson> in any case, this is all very long-established stuff; you're swimming upstream by trying to persuade people to make exceptions for you, and it might well be easier to just arrange a meeting in person
<psusi> I guess what I'm saying is that the bar of "verified identity with gov't documents" is the highest level of trust, and seems a tad much for getting recognized as a dm
<psusi> I fired off an email to the one dd listed as living in FL, see what happens
<xnox> psusi: levels of trust != attestation. You attest for everyone, levels of trust are set locally. E.g. i might attest somebody, but mark in my keyring to not trust that persons attestations cause said person publically tried to get a key signed without checking ID.
<maco> i dont think i'd need my mom's drivers license to believe she's my mom
<cjwatson> a DM very likely has root on lots of people's machines
<cjwatson> it's worth fairly carefully establishing that they are who you think they are
<maco> well any more than i already have trouble believing we're related ;)
<cjwatson> if nothing else so that you have some chance of having some recoure
<cjwatson> *recourse
<Daviey> well, a key parties you tend to look and validate a whole chunk of people.  If i validate someone called "John Smith", i'm not going to remember the contact details to support recourse.  I just know that it is *A* John Smith.
<psusi> that's the thing... trusting someone, and verifying their identity are different things entirely... how does verifying my legal name help with the trust part?  it doesn't seem to...
<pitti> psusi: that's right, these are totally different concepts
<maxb> It does seem a bit incongruous that a decision on whether to give uploader privileges is pretty much wholly based on behaviour of an online persona, yet there's no agreed on way to set up cryptographic trust based on that. But that's the situation that seems to have evolved.
<cjwatson> if you thought you trusted somebody and then they screwed you over (actionably), then if you can't verify they were who they said they were you have absolutely no recourse
<pitti> maxb: actually, that's pretty much how LP's upload privileges work
<psusi> if you trust the guy who has been going by the name Phillip Susi and using the email address psusi@ubuntu.com and submitting patches for a while enough to give him a ppu status, what difference does it make whether that's the name that's on his birth certificate?
<cjwatson> if you've verified a binding with real-world identity then you at least have *some* chance
<Daviey> 2 people on my team go by different names to what their legal name was.  When i turned up to a hotel and asked if they had checked in, i was told nobody with those names were staying at the hotel.  I then got worried i was at the wrong hotel :)
<cjwatson> it's not likely to be sufficient, but it seems necessary
<pitti> psusi: we hand out developer/upload privileges based on that "online identity" indeed
<pitti> I'm not actually sure whether we require someone's GPG key to be in the WoT still; we did in the past
<pitti> does anybody know?
<maco> we do have one developer who went by an alias because he was under 18 and his parents wouldn't let his birth-certificate-name be used online. the key he has under the alias was signed by several ubuntu an debian folks
<maco> pitti: debian does, dont think ubuntu does
<pitti> maco: that's what I thought, too
<stgraber> pitti: I can't remember the DMB ever checking that before granting upload rights to Ubuntu, but maybe it's some part of the procedure that got forgotten over time
<pitti> stgraber: I think it makes sense that way
<ogra_> we used to have an awful process that involved an attoney and a fax machine in the beginning
<pitti> stgraber: we started with WoT before Launchpad
<psusi> that reminds me, there was someone working for canonical that lived around here and wanted to meet, and darnit I forgot who
<cjwatson> gah, fantasy on the brain, I keep reading that as "Wheel of Time"
<psusi> lol, me too ;)
<ogra_> better than Wheel of Fortune at least ...
<ogra_> (in the light of granting upload rights)
 * Laney glares
<psusi> is there a list of canonical employees with where they live?
<xnox> ogra_: ppu/motu/core-dev should be in the web of trust (the set of debian & ubuntu devs)
<xnox> psusi: you want a Debian Developer if you want to become a Debian Maintainer.
<xnox> and employment information is private & sensitive information pretty much everywhere in the world.
<psusi> yea, I know... I'm just bothered now because I had a convo with a canonical developer a while back and he lived nearby and wanted to meet for a beer some time, and I can't recall who it was now and we never did
<arges> tseliot: hi i noticed an ftbfs for nvidia-graphics-drivers. looks like a missing common in the control file. should I create a patch or is somebody else looking at this already?
<tseliot> arges: which revision?
<arges> tseliot: looks like nvidia-graphics-drivers-310
<tseliot> arges: I can see the log now. Weird, let me check
<rbasak> Is there an example of dep3 as applied to dpatch somewhere?
<xnox> rbasak: dpatch uses it's op DP: description fields and predates dep3 by a long time.
<cjwatson> Yeah, I usually just stick them in DP: and don't worry too much about it
<xnox> convert to quilt & use dep3, or stay with dpatch + write a bit of text in the description.
<xnox> s/op/own/
<cjwatson> dpatch is deprecated anyway so the problem should go away over time
<rbasak> OK so it's vague and if I just make it human readable it'll be sufficient?
<rbasak> I guess I'll just prepend dep3 stuff with ## DP: then
<rbasak> Thanks!
<cjwatson> rbasak: I normally find prepending DEP-3 headers with DP: is too awkward - I just do free-form text
<cjwatson> But whatever
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bdrung> sarnold: re bug #1084054 - vlc has a preliminary MRE. the SRU still needs to get build through -security
<ubottu> bug 1084054 in vlc (Ubuntu Precise) "Denial of service via crafted PNG file" [Undecided,Confirmed] https://launchpad.net/bugs/1084054
<sarnold> bdrung: hrm, that does sound familiar but now I can't find the documentation that would explain it further
<bdrung> sarnold: -proposed will build with -updates, which is not allowed for packages going to -security
<sarnold> bdrung: oh, I overlooked the "preliminary MRE" the first read-through, do you have a link handy?
<sarnold> (I didn't see it on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions )
<bdrung> that's how i got 2.0.3 in. let me digt out the TB meeting
<bdrung> sarnold: http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-23-21.14.html
<sarnold> bdrung: thanks
<xnox> pitti: your @debian.org email doesn't work =(
#ubuntu-devel 2013-01-10
<xnox> bdrung: waf upstream was never hostile to packaging waf in distros. they did accept debian-specific patches into upstream which debian maintainer claimed to mean "hostile". And while ftp-masters didn't accept waf into debian, i disagree with their resolution.
<xnox> configure, which is generated using out-of-the-archive autoconf & possibly hand crafted aclocal with missing m4 files is a far bigger FTBFS / DFSG / build reproducibility problem them. Then a handful of python files compressed with bzip2 and uuencoded.
<xnox> So I would not block packages on having waf in them.
<xnox> http://lintian.ubuntuwire.org/quantal/tags/source-contains-waf-binary.html
 * xnox goes to ping ubuntuwire about setting up raring lab
<geofft> xnox: btw, you got my email about apt-mirror, right? Did you ever play with setting that up?
<xnox> geofft: yes, I did. I did play around with it a little. Changing a few things around. But nothing published, nor running publically yet.
<xnox> trying to find time for this project =))))
<xnox> geofft: thank you though, a lot!
<geofft> xnox: Sure (and thank broder, really). Just wanted to make sure I didn't fail to get you something you needed.
<Bluefoxicy> hang on, there's been no power drop here
<Bluefoxicy> why did my computer reboot
<xnox> did you kick it to hard & it wiggled a power cable?
<Bluefoxicy> don't know, someone says I timed out.
<slangasek> cjwatson: hmm :/ why is -fno-stack-protector still needed?  I didn't find much explanation in the changelog for it, and it wasn't needed for gnu-efi's /own/ build
<Bluefoxicy> my bios isn't set to turn power back on if I experience power loss, but I came back to a log-in screen on a fresh reboot.
<Bluefoxicy> since I timed out, I assume unclean means of system run termination rather than update-manager deciding I should reboot without my input.
<xnox> slangasek: it came up in the context of causing efilinux FTBFS, if gnu-efi is build without -fno-stack-protector. And cjwatson added comments in the gnu-efi explaining this now.
<xnox> gnu-efi doesn't need it, but rdeps do =)
<bdrung> xnox: a binary blob is not the preferred form of modification (in which the source code should be)
<micahg> xnox: why shouldn't waf blobs be problematic in Ubuntu? aside from semantik, all of the packages are from Debian and should be fixed there, I think most are already, but since we don't have a raring lintian lab yet, we can't be sure
 * micahg goes and repacks symantik
<hyperair> symantik?
<hyperair> hmm, mindmapping tool. interesting.
<pitti> xnox: err, how so? I'm getting mails to it all the time
<pitti> Good morning
<pitti> xnox: ah, it's not pitti@debian.org, but mpitt@d.o.
<pitti> xnox: https://launchpad.net/~pitti has the correct address, too
<gdane> hello
<gdane> i am interest in some pxa270 ubuntu project
<gdane> is someone work on it?
<gdane> where i can find any info about?
<sarnold> gdane: I haven't seen anything about that board specifically, but hopefully you'll find something useful here: https://wiki.ubuntu.com/ARM
<gdane> Yes i use, thanks
<gdane> ive read this
<gdane> i mean may be someone worked with it before me
<gdane> and did working kernel and rootfs
<gdane> i have several debian dootfses and kernels for my pxa270 intel xscale
<gdane> so i am wonder if someone did ubuntu project with it
<pitti> doko, infinity: :any build deps don't work in Debian yet; do you happen to know when/whether that's planned?
<xnox> bdrung: in that case snapshot upstream VCS, as packed waf binary only has some of the plugins & is processed to remove whitespace & uses tabs instead of space and has comments stripped.
<xnox> micahg: the point I am trying to say that waf is not a blob but bz2 compressed source code, where as configure is obfuscated pre-generated code, which many packages do not regenerate.
<xnox> configure is "plain-text" and is a bigger blob, imho.
<xnox> pitti: ha =) my error.
<cjwatson> slangasek: right, as xnox said - the problem is that gnu-efi builds a library which is linked into freestanding code in other packages, so ssp blows up at that later stage
<infinity> pitti: Not sure, though in most cases, they really shouldn't be needed anyway.
<cjwatson> pitti,doko,infinity: I was working just yesterday on sorting out Debian buildds to support :any, as it happens
<cjwatson> I'm not quite there yet, since I haven't figured out enough of the relevant bits of wanna-build
<cjwatson> I have sbuild working AFAICT
<bdrung> xnox: we can regenerate the autotools files and we can manually modify them. i can't modify bz2 compressed stuff without extracting it. a problem arise if i want to patch that bz2 compressed code!
<infinity> cjwatson: Until such a time as people think they actually want to allow multiarch buildds (which I'm still wary of as an "official" solution to anything), wouldn't it just be easier to strip :* and let 'er rip?
<cjwatson> That's more or less what I plan to do in wanna-build, yes
<cjwatson> For sbuild, well, I've already done the work - it was easier to backport the relevant dpkg patches to forked code
<xnox> bdrung: autoreconf does not work on many packages. I have been bitten by that many times. /me dislikes how one build system is favoured over the other when exactly the same argument can be applied.
<infinity> cjwatson: Oh, for sbuild, it may as well DTRT, sure.
<infinity> xnox: Do we have ways to regen the waffy stuff with in-archive source?
<infinity> xnox: What form it takes is vaguely irrelevant if we're shipping stuff we can't even pretend to be able to regenerate (and thus modify).
<bdrung> xnox: autoreconf is not favoured over waf in point of getting it packaged. we just require to ship the  waf script in extracted form (so we could create patches against it)
<xnox> infinity: there is no need to regen anything. but you can set WAFLIB= variable and point it to a dir where you can override any bit, as it will be prepented pythonpath.
<infinity> xnox: Err, "no need to" is a meaningless statement when we're talking about software freedom.
<diwic> pitti, hi, do you know why there is a "jockey" (and "meta-kde-telepathy") in https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-daily/+packages ?
<infinity> xnox: You have no need to modify your kernel either, we'll stop shipping the source.
<bdrung> why isn't there one build system that suites all needs?
 * cjwatson contemplates a Debian release goal of having every autotoolsy package use dh-autoreconf
<pitti> diwic: presumably a wrong manual build
<xnox> infinity: waf script is bzip2 compressed python files, if you want to unpack & modify. It's a binary that produces it's own source code. If that's not DFSG-free, I'm not sure what is.
<diwic> pitti, ok, I'll remove it then
<pitti> diwic: for some reason, the "request build" page on +recipe pages always default to the alphabetically first PPA I can upload to, instead of the one I configured for autobuilds
<infinity> Hrm, if this glibc 2.17 builds and passes the testsuite first try after I rebased about 100 patches, I'm going to be very shocked.
<pitti> diwic: in most cases I change it, but I guess a manual build slipped through, sorry
<diwic> pitti, so we should rename "alsa" to "qalsa" or so :-)
<cjwatson> That said I wonder if it's bootstrappily sane for base-passwd to use dh-autoreconf.
<infinity> xnox: Is there a reason it needs to be compressed, other than someone thinks that's cool?
<diwic> pitti, although that would just put another ppa in the same spot
<cjwatson> Maybe I can rationalise heavier build-deps for base packages now that we can cross-build packages sanely
<bdrung> xnox: it not a DFSG problem, it's a "preferred form of modification" problem
<infinity> cjwatson: I think packages lower down the stack get a pass.  There are still a couple that don't use debhelper at all, and I'm fine with that.
<bdrung> s/it/it's/
<cjwatson> Yeah, base-passwd doesn't use debhelper at the moment (in fact that was sort of a condition of me taking it over :-) ).  But I wonder if worrying about that for port bootstraps still makes sense given that all this stuff is Architecture: all.
<cjwatson> Or at least Multi-Arch: foreign.
<xnox> infinity: it's not necessory nor mandatory, is there a reason to decompress & repackage orig tarball, other that someone thinks they may need to modify it sometime in the future?
<xnox> infinity: i can see how one thinks waf is similar to tarball-inside-tarball, but it's not.
<OdyX> xnox: for Debian it's clear: http://wiki.debian.org/UnpackWaf FTP-masters ruled, sooo
<infinity> cjwatson: Well, it still takes us one step further away from being able to do a scorched-earth make world.  Not that Debian has been able to do that for over a decade, but I still think it might be shiny if it was sort of possible.  Some day.
<cjwatson> Seeing as dpkg uses debhelper it seems a bit pointless to worry about it
<infinity> xnox: Well, there you go.  If Debian ftpmasters ruled, I'm happy to just follow suit.
<xnox> OdyX: I respect ftp-masters decision for Debian. That does not mean I agree with it.
<infinity> cjwatson: That could be fixed. :P
<OdyX> xnox: the core of the issue is that you have to execute an untrusted blob to get the source.
<pitti> cjwatson, infinity: :any> I committed doko's glib change to Debian's svn, but reverted the :any bit as current dpkg doesn't seem to like them
<infinity> cjwatson: But yeah, I'm not sure it's worth worrying about either.
<OdyX> you don't know what this blob could do.
<cjwatson> pitti: Current dpkg is fine.  It's sbuild/etc. that breaks.
<pitti> hm, /me upgrades his sid chroot then, it's already two days old
<cjwatson> pitti: Build-depending on python:any, *specifically*, won't be possible in Debian until python is multiarched there
<infinity> pitti: Our dpkg and Debian's don't have any divergence in this area (and haven't for months).
<pitti> aah, so I guess that's the reason why dpkg failed
<cjwatson> pitti: Build-depending on X:any is only permitted if X is Multi-Arch: allowed.
<pitti> not because of :any, but because "python:any" is indeed not installed
<pitti> thanks
<infinity> pitti: python should be multiarched in experimental, if you want to upload there.
<cjwatson> That's defined in MultiarchSpec, and there's a clearer table in MultiarchCross.
<infinity> (At least, I think doko landed all of that)
<xnox> OdyX: not really, the header of was script is plain text and uses python stdlib bz2 to decompress a stream, which is a folder with python files. I can write a C implementation that does it, if you wish and then further inspect the code.
<cjwatson> You could upload but wanna-build will kick it out.
<xnox> s/was/waf/
<cjwatson> So I still wouldn't recommend it.
<infinity> cjwatson: Oh, right. :P
<pitti> infinity: indeed I do (experimental), thanks
<infinity> xnox: I'm not sure what the point in arguing the point is.
<pitti> cjwatson: *nod*, thanks; so I keep it reverted for now
<cjwatson> pitti: You can test it locally against experimental with a reasonably current version of sbuild, but not yet upload it.
<xnox> infinity: ack. i'll shut up.
<pitti> Laney: ^ FYI
<infinity> xnox: Our general goal is to always upstream as much of our stuff to Debian as we can, so doing things that Debian ftpmaster specifically doesn't allow is silly.
<pitti> Laney: so it seems we won't have to carry that delta for very long at least
<Laney> right; we will just need to remember to bump the BD version to get the experimental python
<Laney> depending on when the buildd side gets deployed, of course
 * cjwatson sends off the first half of the buildd side now
<cjwatson> infinity: Hmm.  Having just tried to dh-autoreconf binfmt-support, it feels pretty weird on native packages.  Maybe I should turn that into non-native ...
<infinity> cjwatson: It doesn't even make sense on native packages...
<cjwatson> Well, it sort of does; you still want to keep current on the generated code
<cjwatson> As it stands I reautotool before every upload, but it's a bit manual
<infinity> Sure, but that should be in your clean target then, or some other pre-upload task.
<cjwatson> I dunno.  I do like the consistency of having all my packages work kind of the same way as far as the autotools are concerned.
<cjwatson> And all my non-native packages are now dh-autoreconfed, including the one that was 2.13 only until I beat on it
<infinity> Just build-dep on dh-autoreconf and call it in clean with a hard failure if it's not there?
<infinity> So it forces it to be called on source package generation? :P
<cjwatson> There are some good reasons to call it at build time; it means that you get upstream autotools improvements even if you haven't uploaded for a while
<cjwatson> Particularly relevant for config.guess/sub, but it's occasionally useful elsewhere
<infinity> Yeah, true.
<bdrung> cjwatson: for native package, you could just remove all the auto-generated files.
<cjwatson> bdrung: I could.  The reason I decided I was uncomfortable with that for binfmt-support is that it means that anyone using that on other distributions will have to sort out the autotools stuff manually; and the fact that that is a concern for me is a good indication that it shouldn't actually be native in the first place.
<infinity> cjwatson: Oh, see, yeah, that argument makes perfect sense.
<infinity> (I do wonder if apt and dpkg should go non-native for similar reasons)
<bdrung> cjwatson: yes (too many packages are native despite the fact that i could be used elsewhere)
<infinity> ricotz: I have a few packaging changes to make to glibc 2.17 as well before I upload, but you should expect it in experimental tomorrow (or later today, I guess, but after I've slept), and raring in a few days, after the test rebuilt dust settles.
<ricotz> infinity, alright, i am hoping to see it soon :)
<ogra_> jodh`, hmm, just thinking about that serial stuff, what if someone has a serial tty that isnt used for console= at all ?
<ogra_> i.e. i dont need kernel and boot messages but want a login via serial
<doko> Laney, pitti, only python2.7 is multiarched, not 2.6
<pitti> doko: that's fine, python is 2.7 in sid/exp anyway
<ebischoff>  Hello people and happy New Year. Is it normal that libselinux1 libsemanage and libsemanage-common got installed on Raring? I thought Ubuntu was using AppArmor. I don't have these packages on Quantal.
<cjwatson> ebischoff: Yes, because shadow is compiled with support for them in any case (from Debian).
<cjwatson> The libraries in themselves don't hurt.
<ebischoff> Sure they don't hurt. They are just losing space on the system and not needed. Couldn't "shadow" be compiled without that dependancy?
<cjwatson> It could, but it doesn't seem worth the divergence.
<pitti> there's two handfuls of other packages which also depend on libselinux1 anyway
<ebischoff> OK. I disagree, but OK. Thanks for the answer and thanks also for all the great work.
<cjwatson> (And it would mean that people wouldn't be able to take Ubuntu and drop in a kernel that uses the SE Linux security module instead.)
<ebischoff> Good point. Although one could wonder why a kernel would depends on libraries :-).
<cjwatson> It doesn't.
<cjwatson> Indeed, as pitti says, libselinux1 was already in minimal Ubuntu chroots in Quantal.
<jdstrand> actually, selinux is available via kernel boot parameter
<cjwatson> You've made a mistake somewhere if you believe that it wasn't there before.
<cjwatson> libsemanage1 and libsemanage-common are new.
<ebischoff> ah, correct, I compared only libsemanage ones
<ebischoff> # dpkg -l | grep libsel
<ebischoff> ii  libselinux1:amd64                     2.1.9-5ubuntu1                           amd64        SELinux runtime shared libraries
<pitti> Size: 6202 (-common) -> hardly worth the effort again, I guess
<ebischoff> I learned something, thanks.
<tjaalton> ~150kB all three combined
<cjwatson> Given upstream changes in shadow, IIRC, disabling libsemanage in shadow was going to effectively require ripping out selinux support entirely when it was previously present
<cjwatson> And I wasn't wild about possible regressions for people in doing that
<cjwatson> jdstrand: thanks
<jdstrand> fwiw, that is my resollection
<jdstrand> recollection
<tjaalton> it should be, yes
<jdstrand> that had one way of doing selinux in shadow, then ripped it out and did it with libsemanage
<ebischoff> OK, thanks for the detailed answer everyone. And thanks again for the great work.
<jdstrand> it wouldn't be trivial to revert to the old way
 * cjwatson completes the stuff he meant to do yesterday evening and ran out of time for, and now wonders what he was actually going to do today ... sigh
<ebischoff> best && goodbye
<tjaalton> cjwatson: the change to precise livecd-rootfs to pull xorg backport? :)
<cjwatson> tjaalton: mm, yeah, I seem to have been putting that off ...
<tjaalton> cjwatson: should I push this to bzr? http://pastebin.com/b3gzhpnf
<jdstrand> cjwatson: that is an interesting problem you have :)
<tjaalton> don't mind if you do it the way you prefr
<tjaalton> +e
<cjwatson> tjaalton: that doesn't look right
<cjwatson> it'll end up with both stacks
<cjwatson> I don't see a reason to put this in the "live" phase
<cjwatson> "install" should work better, but needs testing
<tjaalton> cjwatson: no, the package will replace the old stack
<tjaalton> can't have both installed
<cjwatson> tjaalton: But it will go horribly wrong if you do it in the live phase, trust me
<tjaalton> ok :)
<cjwatson> Ubiquity will get very confused
<cjwatson> This is intended to be part of the installed system; it does not belong in the live phase, which is for things that will generally be removed after copying the livefs to the target
<tjaalton> but this is for hw enablement..
<cjwatson> Why does that mean you'd want it to be removed after copying to the target system? :)
<cjwatson> The live phase just makes no sense heree
<cjwatson> *here
<tjaalton> ok ok
<tjaalton> maybe I got it backwards
<cjwatson> live contains stuff like the installer, language packs most of which are going to be removed, casper which we don't want on the target system, etc.
<mdeslaur> seb128: mind if I merge gnupg2?
<seb128> mdeslaur, hey, did I touch that last? please go for it, I hate the TIL concept (more often that not you touch something for a random reason and gets sticky) ;-)
<mdeslaur> seb128: yep, you did :) thanks.
<cjwatson> tjaalton: you might have been misled by the signed kernel being in live - it's there because there are many systems for which we don't want it installed.  Things that we conditionally install are often easiest to have in live.  But it's there because it's the signed kernel, not because it's an enablement kernel
<seb128> mdeslaur, thank *you* ;-)
<mdeslaur> seb128: yeah, now I've caught the TIL disease :)
<tjaalton> cjwatson: yeah, it's the mention of the backport kernel.. so wrong package to touch?
<cjwatson> tjaalton: Wrong package to use as a model for this
<cjwatson> tjaalton: I'm testing a build with http://paste.ubuntu.com/1516802/ now - will probably take an hour or two
<tjaalton> cjwatson: ah, now I get it :)
<tjaalton> sheesh
<tjaalton> things you forget in a week
<Laney> d
<cjwatson> tjaalton: Hmm, nope, this installs xserver-xorg-lts-quantal and then installs xserver-xorg and removes the former ... I thought xorg had been fixed not to do that
<cjwatson> Oh, blah, it's probably got something to do with the task
<cjwatson> This will be painful
<tjaalton> :/
<tjaalton> but renames are great! :)
<cjwatson> hate you all
<tjaalton> hehe
<Myrtti> â¥
<mlankhorst> :/
<cjwatson> I think I will have to expand the task by hand and hope that that doesn't cause anything else to blow up
<mlankhorst> wasn't me who decided on the rename route!
<mlankhorst> anyhow installing xserver-xorg will remove -lts-quantal, which is correct :-) xserver-xorg-lts-precise is just a convenience alias since otherwise input-all and video-all don't get pulled in
<cjwatson> Sure, but it's not what you actually want for this image
<cjwatson> I'm not arguing about the correctness of the package metadata heree
<cjwatson> Although I still hate you all
<mlankhorst> well that's your job, I know you don't mean it :-)
<caribou> what is the process to get a package (kdump-tools) in main when its source package (makedumpfile) is already in main ?
<caribou> the MIR wiki page says that a MIR is not required for those
<seb128> caribou, get something in main to (build-)depends on or recommends it
<pitti> caribou: by and large, upload something to main which depends on it
<cjwatson> or get a core-dev to seed it somewhere if it should be a top-level item
<caribou> seb128: pitti cjwatson thanks for the tips
<micahg> caribou: you also want to make sure that it wasn't left out of main for a reason, the original MIR usually mentions these things if that's the case
<caribou> micahg: I think it's not in main because it's not systematically being used
<caribou> micahg: but thanks for the detail
<ogra_> pitti, ev, is anything in whoopsie or apport using gksudo ? bug 1098235 is the third one i see around this issue and i thought everything uses pkexec
<ubottu> bug 1098235 in ubuntu-nexus7 "Keybord non responsive for "Report problem"" [Undecided,New] https://launchpad.net/bugs/1098235
<pitti> ogra_: I ported apport from gksudo to polkit (pkexec) in quantal
<ogra_> pitti, right, i also see the changelog, pkexec doesnt have any issues with onboard (and definitely doesnt blacken the screen), so i'm a bit confused
<pitti> ogra_: I don't see a package hook with gksu either (at least not on my amd64 system)
<ogra_> we dont have anything like bug buddy anymore, right ? it must be apport they are seeing there
<ogra_> i guess i'll just sit down tomorrow and try to reproduce it
<pitti> no, no bug buddy; KDE has its own crash handler, and Firefox does
<pitti> but neither grab the keyboard
<pitti> and even for apport, you rarely will see hooks needing root privs
<ogra_> no, the keyboard (well, focus) grabbing is clearly gksu
<ogra_> it is known to be broken with onscreen kbd
<ogra_> but something seems to trigger it nontheless when "report this problem" is selected
<pitti> ogra_: the three things which are still knowingly using it are xdiagnose, update-notifier, and ubuntu-nexus7-installer
<ogra_> yeah, i wonder if any hook calls xdiagnose or some such
<ogra_> ubuntu-nexus7-installer isnt in the archive
<pitti> *mumble* gksu must die *mumble*
<ogra_> ++
<ogra_> quickly ...
<ogra_> well, not die but be shot into the universe
<ogra_> i was actually hoping we could do that this release
<bdmurray> pitti, ev: bug 1098250
<ubottu> bug 1098250 in Apport "unable to send suspend resume crash from raring" [Undecided,New] https://launchpad.net/bugs/1098250
<ogra_> anyeway, thaks pitti, i'll go on researching that part
<pitti> and with that, bonne nuit tout le monde!
<ev> nice spot
<bdmurray> ogra_: is there anything in /var/crash?
<bdmurray> ev: I sometimes wish whoopsie had a log file...
<pitti> hm, what should we use as a dupe signature?
<ogra_> bdmurray, no idea, i'll ask the reporter ...
<pitti> machine vendor/product or so? but even that isn't guaranteed to be the same problem
<ev> hmm
<ev> maybe the kernel guys would have a better idea?
<ev> my naive thought would be concatenation of the various SMBIOS and PCI IDs that are relevant here
<ev> that it would be more useful if it underrepresented the number of systems affected equally than if it lumped every Dell together
<pitti> I subscribed apw to the bug with a question
<rbasak> barry: re bug 1097783, thanks. That was quick!
<ubottu> bug 1097783 in genshi (Ubuntu) "re module apis return longs now" [High,Triaged] https://launchpad.net/bugs/1097783
<ev> bdmurray: doesn't it log to /var/log/upstart/whoopsie.log?
<ev> pitti: cheers
<apw> pitti, bug # ?
<bdmurray> ev: not with communication details
<bdmurray> apw: bug 1098250
<ubottu> bug 1098250 in Apport "unable to send suspend resume crash from raring" [High,Incomplete] https://launchpad.net/bugs/1098250
<ev> bdmurray: oh, consider that a bug :)
<ev> it's probably sending to stdout instead of stderr, or whichever upstart cares about
<apw> ev, what symptoms does the error here actually detect?
<smb> apw, Good question. One might guess dmesg....
<bdmurray> apw: its /usr/share/apport/apportcheckresume
<apw> ok so this is one of those where we suspended and then had to reboot
<apw> so there is no stack ... tricky
<apw> ev, so we are looking for something to identify the machine, so perhaps the list of devices and machinetype
<Laney> ogra_: Pretty sure that bug refers to update-notifier.
<Laney>       invoke_with_gksu(CRASHREPORT_REPORT_APP,
<Laney>                               _("<span weight=\"bold\" size=\"larger\">Please enter your password to access problem reports of system programs</span>"),
<ev> apw: will that not be too wide a match?
<ev> that is, can you do anything with "Dell XPS whatever machines failed to suspend 343028 times in Quantal"
<apw> ev, right thats why i am saying 'dell XXX with these 10 devices'
<ev> ah right
<apw> as most likely it has to be related to wahts in the machine
<cjwatson> tjaalton: well, this at least builds now, and includes the enablement stack and not the precise one; I still want to do a bit more comparison with a stock image though, as switching to metapackages is a fairly considerable change
<dkessel> hello guys. when would you think would be a good time to submit an apport crash report for signon-ui ? i have tried two times now, but apport always refuses/fails to retrace the stacktraces and closes the bugs automatically...
<dkessel> i don't want to submit a bug the third time only to see apport retracing fail a third time...
<tjaalton> cjwatson: nice :)
<bdmurray> mterry: there are 2 uploads of duplicity in the quantal -proposed queue, yours is the newer of the two.  the other upload fixes bug 1013446
<ubottu> bug 1013446 in duplicity (Ubuntu Quantal) "Uncached grp and pwd calls make duplicity slow with large group and passwd maps" [Medium,In progress] https://launchpad.net/bugs/1013446
<mterry> bdmurray, oh, that was SRU'd?  I didn't notice.
<mterry> bdmurray, you know what, hold up on mine, and let that one through.  I want to triple-confirm the fix I put in for corruption
<bdmurray> mterry: well it hasn't been approved for quantal yet and there seems to be an issue with the precise upload so it could use reuploading
<mterry> bdmurray, which one could use re-uploading?
<bdmurray> the fix for bug 1013446 to precise
<ubottu> bug 1013446 in duplicity (Ubuntu Quantal) "Uncached grp and pwd calls make duplicity slow with large group and passwd maps" [Medium,In progress] https://launchpad.net/bugs/1013446
<smoser> slangasek, https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/643289 is 'triaged' for precise. my test just now seems to agree with that (it seems not fixed in precise).
<ubottu> Ubuntu bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged]
<smoser> were you planning on fixing that in precise?
<bdmurray> mterry: so I'll reject your upload of duplicity to quantal and review / approve the one fixing bug 1013446 and if you upload the new precise debdiff to the queue I'd be happy to look at it too
<ubottu> bug 1013446 in duplicity (Ubuntu Quantal) "Uncached grp and pwd calls make duplicity slow with large group and passwd maps" [Medium,In progress] https://launchpad.net/bugs/1013446
<mterry> bdmurray, OK
<slangasek> cjwatson, xnox: ok, thanks for the clarification.  FWIW the gnu-efi in raring is still broken in some manner I haven't yet identified, as it makes shim unusable (but not unbuildable).
<cjwatson> slangasek: was that something I broke?
<slangasek> cjwatson: no, it's my doing
<slangasek> I was vaguely hoping that the -fno-stack-protector issue would fix shim (even though I had already tested reintroducing -fno-stack-protector)
<slangasek> I'll get it sorted this week
<psusi> smoser: had a chance to try out kpartx -u yet?
<smoser> psusi, no. sorry.
<smoser> i've not played or thought any more about that.
<truexfan81> is this the right place to make a suggestion for a program to be included in ubuntu?
<truexfan81> in this case the program is inxi, this would greatly help the guys in the forums and #ubuntu to get the info they need to help people
<cjwatson> slangasek: might be worth trying -ffreestanding if that isn't there already ...
<Laney> whyever does screen -ls return 1 in all cases?
<cody-somerville> Ubuntu package dependency graph is pretty: http://tinyurl.com/a23nzp2
<cielak> cody-somerville: any details on that picture? how was it generated, is there a hi-res version available anywhere, can I generate one myself?
<sarnold> cielak: http://tech-foo.blogspot.com
<cielak> sarnold: thanks!
<cody-somerville> sarnold: thanks!
<RAOF> cody-somerville: That's pretty awesome!
<slangasek> smoser: yes, planning to fix bug #643289 in precise, but the mountall part of it needed to settle first
<ubottu> bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289
<micahg> cjwatson: maybe one of the causes of the TIL breakdown is the lack of mention of it on the UDD packaging guide
#ubuntu-devel 2013-01-11
<jamin> I'm somewhat surprised that this bug is still effectively ignored over a year later: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/825897
<ubottu> Ubuntu bug 825897 in network-manager-applet (Ubuntu) "network-manager becomes unresponsive, requiring a service restart" [Undecided,Confirmed]
<micahg> cyphermox: ^^
<pitti> Good morning
<sarnold> hey pitti :)
<tjaalton> infinity: https://bugs.freedesktop.org/show_bug.cgi?id=54226
<ubottu> Freedesktop bug 54226 in DRM/Intel "[snb 3.5] stale semaphore sync seqno (typically as seen on bcs->rcs)" [Normal,New]
<tjaalton> dunno why I'm not hit by it more often
<infinity> tjaalton: I got it like ten times yesterday. :/
<tjaalton> infinity: well there's things to try on that bug
<infinity> tjaalton: With a nasty performance and power draw hit, apparently.  I'm not sure it's worth the effort.  I can live with the lockups.
<infinity> tjaalton: I just don't think we can live with them for release.
<tjaalton> infinity: are you running 3.8 already, btw?
<infinity> tjaalton: No, I will be after a reboot, but can't reboot just now.
<tjaalton> infinity: ok, it should be better.. i'll be in touch with upstream after you've tried
<mitya57> Does anybody have problems with logging in to errors.u.c?
<mitya57> I "The site has requested some personal information. Please choose what you would like to share:" page,
<mitya57> press "yes, log in" there, and after some five seconds the same page loads
<mitya57> I'm getting this in Chromium and Firefox (resetting cookies & cache doesn't help)
<infinity> mitya57: Works for me.  Are you actually in the group(s) it wants?
<mitya57> infinity: I'm in ubuntu-bug-control
<mitya57> and I was able to access that site in the past
<infinity> mitya57: I think it was further locked down, pending review of data privacy laws and other such madness.
<infinity> mitya57: When you log in, is there a more info expander or something that shows you that it's looking for a group you're not in?
<mitya57> no, nothing like that
<infinity> If I could remember how to log OUT of an SSO service...
<infinity> I guess I could just log out of login.launchpad.net entirely.
<mitya57> IIRC there was a "log out" link at the page bottom
<infinity> Oh, which doesn't do anything. :P
<infinity> No log out links on errors once logged in, no.
<mitya57> https://login.ubuntu.com/+logout ?
<infinity> That didn't actually log me out of errors.
 * infinity gives up and uses an incognito browser.
<infinity> Team membership: canonical-ubuntu-platform
<infinity> ^-- Yeah, it's looking for that right now.
<infinity> We're hoping to be able to open it up a bit more in the future, AFAIK, but it's a bit messy.
<infinity> mitya57: ev might know more about progress on that front.
 * mitya57 hopes it's possible to open it at least for ~ubuntu-dev
<infinity> I'd probably be happy even with just core-dev, but anything that isn't "just the company" gives lawyers heart attacks when it comes to users sending us data that could be, well, anything.
<infinity> (And rightfully so, I suppose)
<mitya57> ok, can you (or anybody else) show me a couple of tracebacks?
<mitya57> https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Funity-mail%2Funity-mail%3Aimaplib.abort%3A_command_complete%3A_get_tagged_response%3A_get_response%3A_get_line%3Aon_mm_item_clicked%3Amark_message_as_read%3Aselect%3A_simple_command%3A_command_complete
<mitya57> and https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Funity-mail%2Funity-mail%3Aemail.errors.HeaderParseError%3Astart_loop%3Astart_loop%3Adecode_header%3Adecode%3Aupdate%3Aupdate_single%3Aget_header_wrapper%3Adecode_wrapper%3Adecode_header
<infinity> mitya57: http://paste.ubuntu.com/1519349/ and http://paste.ubuntu.com/1519350/
<mitya57> thanks infinity!
<infinity> ev: So, apparently community developers do use errors.u.c (or, try to)
<mlankhorst> can some ubuntu sru admin look at the mesa I uploaded this morning?
<ogra_> Laney, wow, thanks !!! what i dont get though is why would that be invoked if someone sends an error report
<Laney> ogra_: I'm not sure how it's all hooked up (pitti probably would know), but it seems like that's what invokes apport
<ogra_> oh
<Laney> it's probably something which can be converted to pkexec in any case
<pitti> ogra_: update-notifier gets invoked when a non-user crash happens, not when someone sends an error report
<pitti> Laney: nope, update-notifier still uses gksu
<ogra_> yeah, i thought about it the other way round ... didnt think that IT coudl eb invoking apport :)
<pitti> that's one of the two places which still need to be fixed
<ogra_> whats the other ? xdiagnose ?
<Laney> yeah I know it still does - was confirming that it was the source of ogra_'s bug from yesterday
<pitti> ogra_: yes
<ogra_> great
<ev> infinity: and we want them to be able to access the data. But we're waiting for an NDA to be written up.
<xnox> pitti: Program received signal SIGSEGV, Segmentation fault.  _dbus_watch_invalidate (watch=0x0) at ../../dbus/dbus-watch.c:171
<xnox> usb-creator-gtk in certain combinations often triggers that. bug #915626. In the past there were also bug #1043887 and bug #852342
<ubottu> bug 915626 in usb-creator (Ubuntu) "usb-creator-gtk crashed with SIGSEGV in _dbus_watch_invalidate" [High,In progress] https://launchpad.net/bugs/915626
<ubottu> Error: Bug #1043887 is a duplicate of bug #1036183, but it is private (https://launchpad.net/bugs/1036183)
<ubottu> bug 847578 in evolution-data-server "duplicate for #852342 e-calendar-factory crashed with SIGSEGV while importing ics data" [Critical,Fix released] https://launchpad.net/bugs/847578
 * xnox will try to sanitise that function in dbus & see if I can still trigger the bug.
<xnox> bdmurray: you are a rock star @ finding the right set of options that trigger above more often than others.
<pitti> xnox: I haven't seen this, but it's obviously passing a NULL argument to that function?
<xnox> yeap. the function accepts dbuswatch pointer, it's passed NULL and it tries to do two simple assignments NULL->fd=-1 and something else. which causes SIGSEGV
<xnox> I don't see how in high level python/dbus it could be causing this deliberately. the clean up looks racy to me.
 * xnox also notes that python3-dbg tracebacks are verbose and seem to hide stuff =)
<xnox> here is the full gdb log: https://launchpadlibrarian.net/128192354/gdb-dbus.txt
<ogra_> pitti, bug 871662 looks like it can be closed in favour of an update-notifier bug
<ubottu> bug 871662 in apport (Ubuntu) "Drop gksu dependency" [Low,Triaged] https://launchpad.net/bugs/871662
<pitti> ogra_: or just reassigned; apport lost its dependency a while ago already
<pitti> ah, there is one already, right
<ogra_> yes, thats what i wrote in my last comment, but i didnt want to close without asking
<pitti> ogra_: done, thanks for pointing out!
<ogra_> (the focus grabbing makes it nastier on tablets than it used to be due to onboard )
<zul> mterry:  hi..
<zul> mterry:  i disabled the failing test for testrepository although it runs fine not in a buildd
<mterry> zul, disabled the test?  :(
<mterry> zul, I got the failure locally
<zul> mterry:  if i just run make check then it runs fine
<dbarth> hey, i have an apparmor, pam and lightdm question
<xnox> go on =) sounds interesting so far.
<dbarth> setuid is failing in a lightdm child process and i'm not sure if that's really not normal, or if it's just an apparmor file that is missing
<mdeslaur> dbarth: do you have an apparmor denial in dmesg?
<dbarth> mdeslaur: not that i can see though
<mdeslaur> dbarth: then it's unlikely to be apparmor the problem
<dbarth> does it go in auth.log or syslog by default?
<mdeslaur> dbarth: syslog unless you have the "audit" package installed
<dbarth> hmm, let me check that maybe first
<mdeslaur> s/audit/auditd/
<mdeslaur> if you have that package installed, it goes to /var/log/audit* somewhere
<mdeslaur> (can't recall off-hand)
<dbarth> no audit here
<dbarth> and nothing from the lightdm process in syslog
<dbarth> i will go through lightdm.log again
<mterry> bdmurray, remember you talked to me a bit ago about the two duplicity SRUs in quantal?  you haven't accepted the other duplicity yet.  Would it be wasting your review cycles to upload another duplicity to quantal that combined both uploads?
<dbarth> mdeslaur: i can see some old denial messages for the freerdp session though (in kern.log)
<dbarth> but that was fixed once the config. file for the wrapper executable was installed
<dbarth> (for the 12.10 release)
<mdeslaur> dbarth: ok, but if there's nothing newer, then your issue is probably elsewhere
<mdeslaur> all denials should be logged
<jdstrand> it goes to kern.log
<jdstrand> lightdm itself is not confined
<jdstrand> the guest session is
<ogra_> if lightdm already habnded over to the session manager if your issue happens, the errors would be in ~/.xsession-errors of teh user btw
<mdeslaur> oh, whoops, yes, kern.log
<dbarth> mdeslaur: ok, i'll dig deeper; thanks for pushing me further at least
<jdstrand> we don't have any explicit denials that would block setuid
<jdstrand> (even in the guest session)
<mdeslaur> dbarth: check kern.log first though
<dbarth> ogra_: the session opens fine if i make the pam session layer optional
<hallyn> zul: infinity: is the raring qemu upload still waiting for review, or is it hanging on something else I forgot?  (it was waiting on ipxe-qemu for awhile...)
<dbarth> the issue is when i re-enable the pam session part, to inject creds in the session
<hallyn> i'm just confused bc i still don't see it on the uploads page for qemu
<dbarth> jdstrand: ok, noted
<hallyn> (oh, i do see it in the NEW queue)
<zul> mterry:  can we get alembic looked at today as well please?
<mterry> zul, oh that is part of nova too?  I hadn't looked at that MIR yet
<mterry> zul, sure
<zul> mterry:  its apart of quantum actually :)
<cjwatson> bdrung: Are you planning to finish the libibmad/libibumad transition, having sponsored syncs of a soname change from experimental last month?
<cjwatson> bdrung: It's been sitting in -proposed unmigrated since then.
<cjwatson> bdrung: srptools was an easy rebuild so I did that; ibsim and qlvnictools FTBFS
<mterry> zul, all approved I believe
<zul> mterry: cool thanks
<bdmurray> mterry: come to find out there was a 3rd upload of duplicity - https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=duplicity
<bdmurray> that one fixes bug 1080423
<ubottu> bug 1080423 in duplicity (Ubuntu Quantal) "UnicodeDecodeError when backing up to Ubuntu One in some locales" [Undecided,Confirmed] https://launchpad.net/bugs/1080423
<mterry> bdmurray, yeah, I had done that one a long time ago, and when I made my second upload, I included that fix, obsoleting that guy
<mterry> bdmurray, so 2 of the uploads were mine, one was this 07caching.dpatch fix
<bdmurray> mterry: okay, so one with all three seems fine to me
<mterry> bdmurray, will do
<bdmurray> mterry: thanks, just let me know and I'll review it
<mterry> bdmurray, k
<dbarth> i found my issue; it's a segfault, but visible on the host system, not in the lxc-container!
<jamespage> mterry, thanks for the approval of alembic - I just subscribed ubuntu-server team to bug mail
<mterry> jamespage, awesome
<xnox> ev: is there a way to run  /usr/share/usb-creator/usb-creator-helper under debugger? everytime i start usb-creator-gtk it seems to spawn it's own helper.
<ev> xnox: it wont spawn it if there's one already running on the system bus
<ev> so just tack a sudo in front of that
<xnox> hmm...
<roadmr> Hey folks! So I netbooted a uefi installation with a few kernel parameters to boot to a desktop installer over nfs, but once installed, the grub menu entry "inherits" those parameters and won't boot out-of-the box; requires some editing :/
<roadmr> is there a way to tell the installer not to "inherit" those grub parameters? it properly ignored e.g. automatic-ubiquity but kept e.g. url, initrd, nfsroot and log_host
<xnox> ev: thanks, seems to work. I may have had a stale one already. =))))
<mterry> bdmurray, duplicity 0.6.19-0ubuntu2.1 uploaded to quantal-proposed, when you're ready.  I'm preparing a new precise upload too (that combines the two patches uploaded separately there)
<mterry> bdmurray, I'll be more careful about checking the queue next time
<ev> xnox: yay
<xnox> if only dbus.so would stop segfaulting.....
<bdmurray> mterry: okay, thanks
<cjwatson> roadmr: There's normally a "--" as a boot parameter (certainly is by default), which acts as a separator.  Parameters after that may be copied into the target system; parameters before that won't be.
<roadmr> cjwatson: oh, you're absolutely right, I'm putting them *after* the --, I'll try your suggestion, thanks as usual :)
<bdrung> cjwatson: i will contact the sponsoree if he is willing to do it (otherwise i probably have to do it)
<mterry> bdmurray, and now duplicity 0.6.18-0ubuntu3.1 uploaded to precise-proposed
<iBelieve> I just branched apport to work on a bug fix, and am getting the message "OUT-OF-DATE". What does this mean and how does this affect me?
<seb128> iBelieve, usually it means the vcs you checked out doesn't have the current version ... what vcs did you branch?
<iBelieve> seb128: I ran "bzr branch ubuntu:apport".
<seb128> iBelieve, you should probably make your patch against lp:apport
<seb128> but dunno why the ubuntu: one is out-of-date
<seb128> maybe pitti knows (if he's still around)
<iBelieve> seb128: Don't the developer docs (http://developer.ubuntu.com/packaging/html/udd-getting-the-source.html#branching) say to use "ubuntu:"? What is the difference?
<seb128> iBelieve, ubuntu: is the packaging branch
<seb128> lp:apport is the upstream project branch
<seb128> that's less obvious when upstream is on launchpad
<iBelieve> seb128: So I can use "lp:apport" instead, and that will work fine for working on a bug fix (LP #657275)?
<ubottu> Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275
<seb128> iBelieve, yes
<iBelieve> seb128: Great, thanks for your help!
<seb128> yw
 * Laney cries as he abandons trying to work with a SRU bzr branch
<Laney> an
<xnox> Laney: branch the sponsoree branch, generate source package, generate debdiff against the base, work with that =)
<Laney> I got some inexplicable error about .pc
<Laney> download diff of the (thankfully single) commit + apply to source package :-)
<Laney> branching sponsoree branch + generating diff from that would have also worked
<infinity> Which is much simpler anyway. :P
<infinity> pitti: You around?
<Aeyoun>  Regarding updating a upstream package. I have successfully followed[1] for version 1.0. Now I want to update to 1.1. But there seems to be a step missing regarding using bzr and launchpad on[2]. Is there another document that explains it all? [1] http://developer.ubuntu.com/packaging/singlehtml/index.html#document-ubuntu-packaging-guide/packaging-new-software [2] https://wiki.ubuntu.com/PackagingGuide/Complete#Creating_and_Using_a_deb
<Aeyoun> ian.2BAC8-watch_File
<Aeyoun> I end up with one packagename/ that is the bzr repo, and one packagename-1.1/ which is not a repo.
<infinity> Aeyoun: http://developer.ubuntu.com/packaging/singlehtml/index.html#merging-a-new-upstream-version
<Aeyoun> infinity, that would be exactly it. again: thank you so much. :-)
<tjaalton> so on raring I have four separate dnsmasq's running, one of which should enable virbr0 for libvirt, but it can't create the socket for it
<tjaalton> this was supposed to be fixed ages ago, I think
<slangasek> I haven't had any problems with multiple dnsmasqs running
<slangasek> the nm one should be bound to a different interface than the virbr0 one
<tjaalton> so there's one for lxc, libvirt, nm, and one system-wide?
<tjaalton> seems as if it's running one extra
<tjaalton> eh, I had both dnsmasq and dnsmasq-base installed for some reason
<tjaalton> now it should work, but virtbr0 still doesn't have an address
<tjaalton> stopping libvirt-bin probably should stop it's dnsmasq too
#ubuntu-devel 2013-01-12
<toabctl> how can I close a launchpad bug report with requestsync? Should I edit the changelog which is shown in a editor?
<mitya57> toabctl: I think it's better to not touch the changelog if the package is in sync with Debian, and the person who is actually syncing may use syncpackage -b to close the bug
<mitya57> 11:40 <mitya57> toabctl: I think it's better to not touch the changelog if the package is in sync with Debian, and the person who is actually syncing may use syncpackage -b to close the bug
<toabctl> mitya57, ok. thanks
<OdyX> pitti, tkamppeter: mike found the control files purge problem and released a patch; I hope to upload cups to experimental later today.
<Esokrates_> I was trying to compile unity today, but I got the following output:
<Esokrates_> http://ubuntuone.com/6hsVC0HWDdWT2ky9Sux0vE  (Cmake output)
<Esokrates_> what i wrong with my zeigeist package?
<mitya57_> Esokrates_: hm, is libzeitgeist-dev installed?
<Esokrates_> no seems not to be installed, thanks I seemed to missed that
<Esokrates_> I also thought of zeitgeist packages I have missed, and ineed installed a few additional, but I missed that one, I will install them and try to compile again, thanks
<mitya57_> you could just use `sudo apt-get build-dep unity` :)
<Esokrates_> thank you :-)
<Esokrates> I got the following output while compiling unity:
<Esokrates> http://ubuntuone.com/7PVTGqxRfyhqrJGYfIMiw8
<Esokrates> mitya57, do you have an idea?
<mitya57_> Esokrates: if that's unity from raring/lp:unity, it may need a newer nux
<Esokrates> yeah it is
<mitya57_> (I think the version was bumped, but maybe you are using a snapshot where it wasn't yet)
<Esokrates> https://code.launchpad.net/~smspillaz/unity/unity.fix_1091600
<Esokrates> I want to test a fix included there
<Esokrates> this instruction did not work:
<Esokrates> http://askubuntu.com/questions/28470/how-do-i-build-unity-from-source/28472#28472
<mitya57_> If I were you, I would just grab the diff from https://bazaar.launchpad.net/~smspillaz/unity/unity.fix_1091600/diff/2999 and apply it to the quantal-proposed package
<Esokrates> mitya57, could you link me an instrution how to do that? I have never done this
<mitya57_> Esokrates: something like this (not tested):
<mitya57_> dget https://launchpad.net/ubuntu/+archive/primary/+files/unity_6.12.0-0ubuntu0.2.dsc
<mitya57_> or, better (so that it would extract it):
<mitya57_> DGET_VERIFY=no dget https://launchpad.net/ubuntu/+archive/primary/+files/unity_6.12.0-0ubuntu0.2.dsc
<mitya57_> cd unity-6.12.0-0ubuntu0.2
<mitya57_> wget https://bazaar.launchpad.net/~smspillaz/unity/unity.fix_1091600/diff/2999 -O lp1091600.diff
<mitya57_> patch -p0 lp1091600.diff
<mitya57_> debuild -us -uc
<mitya57_> (that's all)
<tumbleweed> mitya57_: you may find pull-lp-source useful, in future
<tumbleweed> presumably you meant patch -p0 < lp1091600.diff
<mitya57_> of course
<mitya57_> tumbleweed: thanks for suggestion :)
<Esokrates> mitya57, I sucessfully compiled compiz and unity to my home directory
<Esokrates> mitya57, but if I start compiz unity does not get loaded, I only see windows, no launcher no panel etc.
<Esokrates> used the following in a VT: env DISPLAY=:0 LD_LIBRARY_PATH=./lib ./bin/compiz --replace composite opengl move resize decor compiztoolbox mousepoll wall expo animation switcher
<Esokrates> when I run unity, the old compiz gets started
<Rcart> hello. Where can I contact notify-osd maintainers? I want to nominate a SRU (bug 949077) but I cannot fill the [Regresion potential] field
<ubottu> bug 949077 in notify-osd (Ubuntu) "Black border on notifications when running with no compositing" [Undecided,Fix released] https://launchpad.net/bugs/949077
<mitya57> Rcart: try asking directly mterry on monday :)
<mitya57> I can nominate the bug for you if you want
<Rcart> mitya57: yeah, do it please (:
<Rcart> mitya57: I was just about to mail the list of dx-team, but it'd be  better if you nominate it now
<mitya57> Rcart: done
<Rcart> mitya57: the SRU should be for precise, and you nominated it for quantal where is already fixed
<mitya57> Rcart: oops, added precise
<Rcart> mitya57: thank you (:
<OdyX> pitti, tkampetter: yay, cups 1.6.1 is already out of NEW.
<Squarism> how can i report a bug on that annoyment of not beeing able to reassign Ctrl+Super+Left/Right in 12.04, 12.10 in unity?
<Squarism> FUUUUCK.. .after reading walls of text i cant even find where to file a damn unity bug
<Squarism> my patiance with the unprossionalism of ubuntu/unity is falling fast
<jtaylor> at launchpad?
<mitya57> Squarism: https://bugs.launchpad.net/unity/+filebug, and please respect Ubuntu code of conduct :)
<jtaylor> ubuntu-bug unity
<Squarism> thanx
<code_6> hey I am new and I want to contribute to ubuntu can anyone help me with this ?
<code_6> any one active here ?
<penguin42> code_6: http://www.ubuntu.com/community/get-involved is a good start
<code_6> i checked that out but what to do next they say you can get a mentor but nothing about how to find one
<penguin42> was that under the bug stuff or elsewhere?
<code_6> under the link you mentioned
<mitya57> OdyX: impressive changelog, you people are heroes!
<mitya57> code_6: if you want a mentor, just make sure your package shows in the sponsoring queue
<mitya57> http://reqorts.qa.ubuntu.com/reports/sponsoring/
<mitya57> it'll be shown there if you filed a merge proposal or subscribed ~ubuntu-sponsors to a bug
<OdyX> mitya57: cups ?
<mitya57> OdyX: yeah (and the number of patches is also impressive)
<OdyX> mitya57: praise tkamppeter , but there was a huge job in making 1.6.1 happen and have the test-suite run.
<code_6> mitya57: thanks
<AbsintheSyringe> maybe a weird question, but what's the preferred way of updating raring?
<Laney> updating to or updating within?
<AbsintheSyringe> on my debian sid I don't even have software updater installed, I do them all via "dist-upgrade", sometimes "safe-upgrade"
<AbsintheSyringe> Laney, (long time no see) just doing system upgrade, should I rely more on software updater or sticking to terminal is ok?
<Laney> yo!
<AbsintheSyringe> Laney, hey hey :)
<AbsintheSyringe> someones trying to move over to Ubuntu :P
<Laney> I usually use apt-get but update-manager is the recommended way
<Laney> ++
<AbsintheSyringe> heh, ok I said it's a weird question because it doesn't seem that unstable to be honest
<Laney> that's a bad thing? :P
<AbsintheSyringe> on Sid if you're not careful enough you could do a lot of damage when updating
<AbsintheSyringe> no, I just can't get used to it
<AbsintheSyringe> Laney, pity you never made it to Debconf :)
<AbsintheSyringe> "that" debconf
<Laney> or any other - yeah, it is
<AbsintheSyringe> going to fosdem?
<Laney> sadly not
<Laney> shouldn't be that hard to get to debconf this year though
<AbsintheSyringe> yea, we'll see each other around
<AbsintheSyringe> it shouldn't sponsorships should be open soonish
<AbsintheSyringe> maybe in Feb
<cjwatson> AbsintheSyringe: raring has a kind of partial equivalent of Debian unstable->testing migration applied to it these days
<cjwatson> AbsintheSyringe: I tend to use dist-upgrade personally
<cjwatson> if you're familiar with it it's fine; it's certainly not *unsupported*, any recommendation of update-manager is more to do with it being a more integrated user experience or whatever than actually having importantly different semantics
<AbsintheSyringe> cjwatson, ah great, in that case I'll just stick to dist-upgrade
<AbsintheSyringe> cjwatson, tnx (another long time no see) :)
<cjwatson> aye :)
<AbsintheSyringe> cjwatson, are you going to fosdem?
#ubuntu-devel 2013-01-13
<penguin42> hmm libssl-dev:i386 won't install alongside libssl-dev
<cjwatson> penguin42: I've been working on that - see Debian bug #689093
<ubottu> Debian bug 689093 in libssl-dev "libssl-dev is not Multi-Arch compatible" [Normal,Open] http://bugs.debian.org/689093
<penguin42> cjwatson: Ah nice
<micahg> infinity: what's blocking the build-dep on backports fix for backports now?
<infinity> micahg: Me landing a fix.  Is there something in that situation again?
<micahg> infinity: oh, Bug #1099003 if a backport is desired
<ubottu> bug 1099003 in vlc (Ubuntu) "VLC 2.0.5 won't work with Opus. Please include libopus0 from n-muench PPA" [Undecided,Won't fix] https://launchpad.net/bugs/1099003
<infinity> micahg: Given vlc's sercurity history, would we really want it in backports anyway?
<infinity> (Backporting things that may need frequent updates seems suboptimal)
<micahg> infinity: well, since vlc in precise and quantal is the same version, it seems like something easy to approve with just the binaries tested (I'd try to get someone to commit to at least that)
<micahg> (well, after I review the packaging diff for any weirdness)
<infinity> micahg: Sure, the initial backport is simple (and not really much of a backport at all, per se), I just meant that it's likely it would need frequent updates.
<micahg> infinity: well, if it's actually needed and someone commits to the testing, I don't mind pushing the buttons to make it happen to prevent someone from needing a PPA
<infinity> Fair enough.  I'm not using the above as an argument for me to not fix the build-dep situation.
<infinity> Unrelated things. :P
<infinity> It just seems, in general, that backporting stuff with shoddy security histories ends up creating more work (cause, if you're being responsible about the whole affair, you have to keep re-backporting)
<micahg> it's true, we discussed a slightly streamlined process for those at a previous UDS at the discretion of the backports team (where we're confident that not doing full testing won't break the world)
<infinity> And, eventually, there will be a point where the backport's a bit of a pain to maintain, as Q, R, and S go out of maintenance, but we're still trying to backport to P.
<infinity> Right now, it's obviously easy, just backport from quantal-security, done.
<infinity> (And probably with 0 source changes, too)
<micahg> infinity: right, as time goes on, this will get harder, if it comes to it, we can always just switch to a feature enablement backport if it gets too hard
<infinity> Anyhow.  I'm hip-deep in glibc 2.17 right now, but remind me politely during the week about this, I have some other lp-buildd bugs I need to look at this week too.
<infinity> And I tend to like to do them in batches.
<micahg> infinity: sure, thanks
<infinity> To save the pain of rolling out lp-buildd to a bazillion builders over and over.
<infinity> tjaalton: Thanks for backporting my dkms fix to precise.  Next time, remember to fill our the SRU template for the bug too. :P
<infinity> tjaalton: (I did it for you this time, cause I really wanted the fix after realising it was bloating /pool/ on our precise.2 CDs)
<tjaalton> infinity: ah, indeed
<tumbleweed> doko: grumble, your python3 porting of devscripts broke ubuntu-dev-tools
<tumbleweed> (I suppose we should be using stdlib's logging module)
<bdrung> tumbleweed: patches are welcome (if stdlib can produce the same output on the terminal)
<bdrung> tumbleweed: or do you have other solutions?
<bdrung> tumbleweed: adding python2 support back to devscripts would pull python 2 (which is probably unwanted)
<bdrung> creating a separate library is too much for such a simple module
<tumbleweed> we can get fairly similar output from logging, fairly easily
<bdrung> define "fairly"
<tumbleweed> I'll have a look, this evening
<bdrung> back when i tried to use a logging module, i wasn't satisfied with the output format (and failed to configure it to my preference)
<doko> tumbleweed, bdrung: yes, seen. I'll add a python2.7 module, but without depending on python2
<doko> but feel free to convert ubuntu-dev-tools, where python-launchpadlib isn't needed
<bdrung> doko: does someone port python-launchpadlib to python 3?
<bdrung> doko: can you forward the python 3 changes for file to the debian bug report, please?
<rsajdok> Any suggestion on this question? https://code.launchpad.net/~ris/loco-team-portal/fix-552762/+merge/142553/comments/308685
<micahg> rsajdok: that has nothing to do with Ubuntu Development, you probably want #ubuntu-loco or the equivalent channel
<rsajdok> micahg: this is problem in bzr merging
<micahg> rsajdok: that's a support question then , see #ubuntu
<micahg> or #bzr
<cjwatson> bdrung: there've been multiple attempts to porting the launchpadlib stack (it's more than just python-launchpadlib) - so far, at best people have only got part-way before giving up.  I think barry was the last to try, and he ran into differing ideas about bytes/text in different parts of the stack
<bdrung> thanks
<MrWGW-> you know I think I'd be more interested in doing a Cinammon-based Ubuntu derivative, versus a MATE based system
<MrWGW-> I'v
<MrWGW-> I've been using Cinammon on Linux Mint, and IMO this system is a revelation; its clean, simple and elegant
<MrWGW-> it feels to me like what Unity ought to have been in terms of representing a cleanup of GNOME 2
<MrWGW-> however from my last conversation in here I gathered that while there would be acceptance of a MATE desktop environment for Ubuntu, a Cinammon environment might be somewhat more controversial
<MrWGW-> but I'd love to see, and for that matter, implement, such a Cinammon system
<MrWGW-> basically, Cinammon, but with the beautiful Ubuntu font and artwork, and also in a form small enough to fit on a single CD, like the classic Ubuntu releases of yore
<MrWGW-> and perhaps with other concessions to modern Ubuntu design, like icons on the left side of the window decorator
<MrWGW-> and there are packaging quality problems in Mint also which this could sidestep
<MrWGW-> also as an added plus if a Cinammon based Ubuntu took off, it might give Clement more time to focus on refining Cinammon since he'd no longer have the need to maintain a full distro
<bdrung> MrWGW-: I think it's the other way around. having cinnamon in the archive is uncontroversial (which is the case for raring), but having MATE is (because it bring many deprecated libraries back).
<MrWGW-> note that the MATE devs including Clem are working on fixing that
<MrWGW-> I suspect that MATE and Cinammon will eventually merge
<MrWGW-> but yes indeed, GNOME 2 was a nightmare from an architectural standpoint
<MrWGW-> and one reason why I feel inclined to do a Cinammon variant of Ubuntu more so than a MATE one
<MrWGW-> is I really do not relish the thought of having to respond to unpleasant bug reports involving Bonobo and other GNOME 2 legacy crap
<MrWGW-> what I suspect, and hope, will happen, over the next few years: Mate and Cinammon will merge, so Cinammon will just be a UI style for MATE, with the classic two panel look also being an availble style, and so on
<MrWGW-> and then meanwhile, if we're really lucky, this combined Cinammon/Mate venture will displace GNOME 3
<MrWGW-> and hopefully also at the very least some strong cooperation between Cinammon/Mate and Unity development could occur
<MrWGW-> imagine if all three of these simply became user-selectable UI preferences
<MrWGW-> note that I don't blame Ubuntu for going with Unity, although I neither care for or use it myself
<MrWGW-> it was very popular on netbooks, and Ubuntu's hand was forced by GNOME 3 anyway
<MrWGW-> although I think in the cold light of day, at some point, the core Ubuntu project is going to have to come to terms with the fact that Unity has been wildly unpopular with a large segment of previously loyal Ubuntu users for various reasons
<MrWGW-> I personally am of the opinion that what works well on a tablet or a netbook does not neccessarily work well on a laptop or a desktop workstation
<MrWGW-> consider Windows 8: on a tablet, I find it provides an amazing experience, from a pure UI standpoint, its even better than iOS, and its beats Android hands down
<MrWGW-> but its utterly unusable on a conventional keyboard/mouse system; I haven't upgraded a single one of my Windows 7 boxes
<MrWGW-> now when I look at Cinammon, I see a UI that implements fully the classical desktop paradigm that dates back to Windows 95
<MrWGW-> it has a start menu in the bottom left, a clock in the bottom right, a taskbar,
<MrWGW-> and yet its clean, modern in appearance and rather beautiful
<MrWGW-> I think such a UI is what most users want
<MrWGW-> and some people are using KDE, but KDE is as we all know its own can of worms
<MrWGW-> its kind of slow, its kind of weird
<MrWGW-> then there's LXDE, which is quite nice, quite modern but not as visually stunning as a more featureful system like Cinammon, or Unity for that matter
<MrWGW-> now I haven't had a chance to play with Unity on a tablet or a TV, but I suspect on those interfaces, it will really shine
<MrWGW-> and I really hope that an Ubuntu phone sees the light of day, this year
<MrWGW-> if one goes on the market I'll buy it, in a heartbeat
<Riddell> MrWGW-: can I suggest you stop your rant and don't call our software weird
<MrWGW-> Riddell: Ubuntu isn't weird
<MrWGW-> I was only referring to KDE
<MrWGW-> what I'd like to do, if the interest exists, is do a Cinammon package for Ubuntu
<Riddell> MrWGW-: hi.  I make Kubuntu.  Please stop calling my software weird.  Or go to slashdot if you want to do that sort of disrespectful attitude
<MrWGW-> and maybe that can become a full desktop environment in the manner of Kubuntu or Lubuntu or Xubuntu
<MrWGW-> Riddell: my apologies, no offense was intended
<MrWGW-> I should add, I personally use and enjoy several obscure OSes which I would be the first to admit are weird, for example, Haiku and Plan9, for recreational purposes
<MrWGW-> I was merely commenting on the benefits of cinammon and why it might be nice to have an official cinnamon flavor of Ubuntu
<micahg> MrWGW-: https://wiki.ubuntu.com/RecognizedFlavors
<MrWGW-> micahg: indeed
<MrWGW-> I'm proposing to volunteer to maintain a cinnamon package for Ubuntu
<MrWGW-> and if that becomes viable, then do a flavor based on it
<MrWGW-> which could hopefully then become recognized if the quality was sufficient
<micahg> MrWGW-: it's maintained in Debian ATM (that would be the best place to maintain the package), you can still do a flavor if you like though
<MrWGW-> oh well heck, that's even better
<MrWGW-> whereas MATE isn't in Debian, which creates more headaches
<MrWGW-> so my development skills are as follows: I have strong general UNIX skills, reasonable Debian skills (most of my Linux boxes are either Ubuntu LTS or RHEL systems), some C skills, although I'm not a great C programmer, strong skills with Python and Ruby
<MrWGW-> I haven't personally authored a .deb package so I don't know what's involved in that, but I'm sure I could pick that up quickly enough
<MrWGW-> and I'm also very willing to field and respond to complaints from users and fix problems of that sort
<MrWGW-> based on the above, do you think I would have what it would take to roll an Ubuntu flavor with Cinammon as the desktop environment?
<infinity> Dear apt-cacher-ng.  Why have you decided that it's suddenly a problem for you that ports.ubuntu.com doesn't have x86?  No love, Me.
<micahg> MrWGW-: sure, it's also not expected for one person to possess all the skills necessary to make a flavor work (in fact, if it's one person doing everything, you're probably doing something wrong)
<stgraber> infinity: hmm, I thought you had a real mirror or a real proxy server, not some kind of incomplete implementation of the two ;)
<infinity> stgraber: I had a real mirror until the disk backing it died.  Haven't gotten around to replacing it.
<infinity> (Besides, apt-cacher on the laptop is still nice for travel)
<micahg> MrWGW-: you might want to chat with the lubuntu folk (latest new official flavor) or ubuntu-gnome folk (flavor in progress)
<micahg> s/new//
<MrWGW-> micahg: I'll talk to both groups
<MrWGW-> although I'd be afraid of hostility from the ubuntu-gnome people :/
<micahg> MrW.GW-: there shouldn't be any..
<MrWGW-> but yes I would need a few people onboard
<MrWGW-> a friend of mine is also a sysadmin, and he's historically been a Fedora user, but he is disgruntled and has talked about doing a distro with me
<MrWGW-> we talked about forking Fedora to remove systemd and have MATE be the default desktop
<MrWGW-> but I'm thinking I should propose to him doing a Cinammon based Ubuntu instead
<MrWGW-> since Ubuntu has upstart, which we both love, and there'd be less work involved
<MrWGW-> since the core Ubuntu system is good, its much easier to put our preferred UI on it
<MrWGW-> than it is to take an OS like Fedora, which actually as of 18 will include MATE, but which has internals we disagree with
<MrWGW-> of course going the other way would be more glamrous, but its a lot more work
<MrWGW-> and the quality of Ubuntu Server is really quite darn good
<MrWGW-> as a long time Fedora/RHEL/CentOS guy (most of my RPM servers are running Scientific Linux), I have to say I now honestly prefer Ubuntu Server for most applications
<MrWGW-> for these reasons, by the way, in case any of you care: Ubuntu Server now has similiar cli admin tools to the Red Hat stuff, i.e. the service command, Ubuntu Server allows you more choices in terms of filesystems, for example, you can install to a JFS root or an XFS root or whatever, you're not forced into an ext3 or 4 root
<MrWGW-> and Ubuntu Server's more frequent release cycle vs. RedHat  and longer support vs. Fedora is a win
<MrWGW-> the stability of each successive Ubuntu release tends to be greater than that of Fedora, so its just a nice platform
<MrWGW-> also I've made good use in my lab of the built in UEC features
<MrWGW-> in the lab I used to run a VMware system but I replaced it recently with UEC running on 10.04 LTS and its quite a bit nicer
<MrWGW-> and I'm planning on upgrading that soon
<MrWGW-> so basically, all that really has to happen here to create a killer desktop IMO would be an Ubuntu flavor using Cinammon, sized to fit on a single CD ROM image, providing an experience very similiar to that of the Ubuntu of yore
<MrWGW-> ideally with the same artwork and theming as the equivalent Ubuntu Unity release
<MrWGW-> basically my goal would be for it to look like the Unity release, except with the traditional taskbar at the bottom instead of the dock et cetra
<MrWGW-> and I would propose branding this Ubuntu Classic Edition or Ubuntu Retro Edition, depending on your preferences
<MrWGW-> if I were to do this, I'd aim to release for 13.10 (since its obviously too late for 13.04) and then if the quality were deemed acceptable, hopefully be in a position to be classifeid as an officially sanctioned flavor for 14.04
<infinity> MrWGW-: You're not likely to get approval to call it "Ubuntu (anything)"
<MrWGW-> so what about calling it cinbuntu?
<MrWGW-> cinnabuntu
<MrWGW-> hah
<MrWGW-> like a cinnamon bun
<MrWGW-> but there is Ubuntu Studio btw
<infinity> Yes, there is.  Still saying you'd be fighting an uphill trademark battle.
<infinity> Besides, cinnamon buns are tasty.
<MrWGW-> indeed
<MrWGW-> cinnabuntu works for me
<astraljava> I'm not versed in legalese, but does it count that Studio is an official flavor?
#ubuntu-devel 2014-01-06
<coderanger> Anyone around that knows the first magic to put in the Sources file to make it functionally empty? Trying to make a repo that has deb-src be a noop.
<infinity> coderanger: Just make it empty?
<infinity> coderanger: Of course, if you're distributing binaries built from copyleft (like, GPL) source, you really don't want your Sources to be empty. :P
<coderanger> infinity: "Encountered a section with no Package: header"
<coderanger> infinity: These aren't packages built from normal debian-style sources, so deb-src is meaningless
<coderanger> but easier to make it a noop than to explain to users why apt-add-repo is wrong :-0
<infinity> coderanger: So just don't have a Sources.gz at all if you don't intend to serve deb-src...
<infinity> coderanger: apt-add-repository only turns on matching deb-src if people call it with -s/--enable-source
<coderanger> No
<coderanger> Its the default
<coderanger> (unless apt-add-repo was changed since 12.04)
<infinity> Anyhow, I don't get the error you do with a zero-length Sources file.
<infinity> (Just tested)
<coderanger> Hmm, what about with a single newline in it
<coderanger> S3 was grumping about 0-byte files
<infinity> That would confuse apt, yes.  The first line of Packages/Sources shouldn't be a newline.
<coderanger> Okay, hmm
<infinity> If you're doing this in a storage scenario that hates zero-byte files:
<infinity> (base)adconrad@cthulhu:~/source-test$ : > Sources && gzip -c Sources > Sources.gz
<infinity> (base)adconrad@cthulhu:~/source-test$ ls -l
<infinity> total 4
<infinity> -rw-rw-r-- 1 adconrad adconrad  0 Jan  5 17:13 Sources
<infinity> And then upload Sources.gz, but not Sources.  Problem solved.
<infinity> -rw-rw-r-- 1 adconrad adconrad 28 Jan  5 17:13 Sources.gz
<coderanger> Hah, fair enough
<infinity> Most real Debian/Ubuntu mirrors never publish the non-compressed versions anyway.
<coderanger> Yeah, I just have the tool generate them for the hell of it
 * mwhudson has to laugh at this
<coderanger> Hmm, the zero-byte error might be libcloud instead of S3, sigh
<coderanger> mwhudson: Hmm?
<mwhudson> coderanger: the battle between different unhelpful technologies and the solution of compressing a 0-byte file into a larger thing
<coderanger> mwhudson: lolcomputers
<mwhudson> yeah
<infinity> Well, given the HTTP overhead in requesting and returning a 0-length file, making it 28 bytes isn't really making the problem much worse. :P
<RAOF> Hm. Why isn't upstart-dbus-bridge started on the system init?
<mwhudson> RAOF: hey, can i bug you about my x problem quickly?
<RAOF> mwhudson: Sure
<mwhudson> RAOF: every so often i get a short freeze, something restarts
<mwhudson> and then some font render buffer is corrupted and i get this sort of thing:
<mwhudson> RAOF: http://people.canonical.com/~mwh/mangled.png
<mwhudson> (x220 so sandybridge graphics)
<mwhudson> RAOF: is this a known problem?
<infinity> I get that sometimes with my i915 lockups.
<infinity> And sometimes not.
<RAOF> Whee! I love font cache corruption.
<infinity> (The corruption, that is)
<mwhudson> yeah, it's not every time
<mwhudson> the lockups themselves seem to happen a lot more when spotify is running, but that might just be anecdata
<RAOF> I'm not aware of that problem, but I'm less involved in the X bug triage than I once was :)
<infinity> mwhudson: Say, since you're another poor Sandy user, maybe you've seen the weird bug that no one else has ever seen...
<mwhudson> RAOF: heh, fair enough
<mwhudson> is there some way to dump the cache at least?
<infinity> mwhudson: When you open new windows (a new Firefox, a new gnome-terminal, whatever), do they sometimes seem to lose the ability to repaint themselves except when being moved?
<mwhudson> infinity: not seen that one
<infinity> Weirdst bug ever, cause I seem to be the only one who sees it. :/
<mwhudson> infinity: you got lucky with hardware?
<infinity> I guess, but it's hardly obscure hardware.
<infinity> T420s
<infinity> Basically identical to your X220 under the hood.
<mwhudson> i mean, you have slightly broken hardware
<mwhudson> ?
<mwhudson> it's not like i'm the only person in the company with an x220 either :)
<infinity> Also possible, but I'd expect broken hardware to behave in more obviously broken ways, not in ways that look like software bugs. :P
<infinity> Whereas the Sandy lockups and font cache corruption are things everyone experiences, AFAIK, to varying degrees.
<infinity> But my weird "new windows don't know how to window correctly" thing seems unique.
<infinity> Or other people just have never sorted out how to describe it and close their non-responsive (not actually, but not painting sure LOOKS unresponsive) windows out of frustration...
<alkisg> dpkg: error processing /var/cache/apt/archives/gstreamer1.0-plugins-ugly_1.2.2-1ubuntu2_i386.deb (--unpack):
<alkisg>  trying to overwrite '/usr/share/locale/id/LC_MESSAGES/.mo', which is also in package gstreamer0.10-plugins-ugly:i386 0.10.19-2ubuntu2
<RAOF> alkisg: Yeah, join the club :)
 * alkisg removed gstreamer 0.10 ugly to work around that...
<RAOF> You're looking at bug #1266141
<ubottu> bug 1266141 in gst-plugins-ugly1.0 (Ubuntu Trusty) "package gstreamer1.0-plugins-ugly 1.2.2-1ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/locale/sl/LC_MESSAGES/.mo', which is also in package gstreamer0.10-plugins-ugly:amd64 0.10.19-2ubuntu2" [High,Triaged] https://launchpad.net/bugs/1266141
<alkisg> Thanks, as long as it's reported... :)
 * RAOF just --force-overwrite'd it
<Logan_> slangasek: Hey, are you around?
<Noskcaj> Logan_, Any chance you could look at some stuff on the sponsoring queue? I've got 20+ packages, some of which we really need for xubuntu.
<Noskcaj> Also some lubuntu and ubuntu-gnome stuff
<Logan_> Noskcaj: Shit, that's a huge backlog. I'm dealing with Bug 1266141 right now (look at how many people affected, ugh), but I'll take a look ASAP.
<ubottu> bug 1266141 in gst-plugins-ugly1.0 (Ubuntu Trusty) "package gstreamer1.0-plugins-ugly 1.2.2-1ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/locale/sl/LC_MESSAGES/.mo', which is also in package gstreamer0.10-plugins-ugly:amd64 0.10.19-2ubuntu2" [High,Triaged] https://launchpad.net/bugs/1266141
<Noskcaj> thanks. I'm one of the people affected by that bug, so a fix would be great
<Logan_> Oh wonderful. More pressure. :P
<Logan_> I managed to delete my entire home directory, so working on that first.
<Noskcaj> Logan_, nice work ;)
<Logan_> Oh, believe me, I'm killing it today.
<Logan_> rm -rf gst* != rm -rf gst *
<Logan_> Obviously.
<Logan_> I don't know why I did that.
<Logan_> I think I might have to back out all of the changes to the gstreamer packages if the fix I'm thinking of doesn't work.
<Logan_> debdiff. The moment of truth.
<Logan_> Oh thank god. It worked.
 * Logan_ hugs Noskcaj.
 * Noskcaj hugs Logan_ 
<Logan_> Happiness everywhere. Alright. Lemme upload.
<Noskcaj> Hopefully my PC will update again now
<Fudge> it effects me too but just force installed it as suggested
<Fudge> Logan_:  the pressure you must feel :D
<Logan_> Tell me about it.
<Fudge> she'll be good mate, look at all those 'effected people' cheering you on...
<Logan_> Uploaded. Phew.
<Logan_> Noskcaj: Now, onto the sponsorship queue.
<Noskcaj> Logan_, Could https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-session/light-locker/+merge/196436 be one of the ones you look at? It's a two month old merge and we still need it in xubuntu
 * Logan_ looks.
<Logan_> Noskcaj: https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1254366/comments/5
<ubottu> Ubuntu bug 1254366 in xfce4-session (Ubuntu) "Add support for light-locker in xflock4" [Undecided,Confirmed]
<Noskcaj> We're wanting to fix this a a basic, no regression way now. Then get it all working fully in upstream for the next release
<Logan_> Noskcaj: The patch looks alright. So Jarno is just concerned that it's running a lock command for every possible one, without considering whether or not they are running?
<Logan_> Does this cause any error?
<Logan_> I guess not, since it's going to /dev/null...
<Noskcaj> Logan_, no errors, we've been calling two commands for ages
<Logan_> Have you tested it with and without light-locker?
<Noskcaj> I haven't personally, but some of the other xubuntu guys have
<Logan_> And it's all good?
<Logan_> Noskcaj: ^, and you didn't credit Sean.
<Logan_> And can I have an upstream bug where this patch was forwarded?
<Logan_> Sorry I'm being such a stickler. It's just the process. :)
<Noskcaj> I'll try and find one. I think sean might have fixed it upstream already
<Logan_> Okay. Try to find a commit.
<Logan_> I'll look into the gnome-tweak-tool merge now.
<Logan_> Noskcaj: Shouldn't we wait for Debian?
<Logan_> At least report it, and maybe forward the patch. We can merge if we approach feature freeze with no response.
<Logan_> Another sponsor may disagree, but that's my opinion on new upstream versions.
<Noskcaj> Logan_, Request of darkxst, the gnome dev lead. It's been in their testing PPA for ages. Plus pkg-gnome is understaffed, i've got stuff there needing sponsorship for 6 months
<Logan_> Fine. Then at least report a bug in Debian requesting a new upstream release.
<Logan_> I'll test the merge.
<Logan_> I got two conflicts. Please fix.
<Noskcaj> Will do. This is why PPA merging is a pain
<Noskcaj> I'll redo the merge, since i probably broke something
<Noskcaj> Logan_, For some reason that merge error comes up even with just bzr merge-upstream and a dropped patch
<Logan_> Noskcaj: That's odd.
<Noskcaj> yeah
<Noskcaj> I might leave this one till debian update it
<xnox> RAOF: hm, dbus-bridge has been changed to run on session-init only these days I think?! Do you have /etc/init/upstart-dbus-bridge.conf that is RC ?
<RAOF> xnox: I did not have an /etc/init/upstart-dbus-bridge.conf until I modified the one from it out of /usr/share/upstart/sessions
<RAOF> I was just playing with watching NetworkManager events and autogenerating apt-cacher-ng's mirror substitution file from mirrors.ubuntu.com when I change networks, and realised the reason that my job wasn't triggering is that the system init isn't watching dbus :)
<xnox> RAOF: i see, so you are the rare case where you _do_ want it on the system-init =)
<RAOF> I just wondered if there was some reason why the system-init no longer watched dbus :)
<xnox> RAOF: well, in session-init (were most dbus events are used at the moment) it was that "session dbus" events were naked, yet "system dbus" events would arrive with "sys:" prefix. So we moved system-init system-dbus-bridge to session-init only.
<xnox> if we ever get dbus-bridge using jobs in default / system-init, then we can look into having sys:dbus events filtered out on the session-init size.
<xnox> (side)
<Noskcaj> Logan_, On the xfce-session stuff, there's no upstream bug, but the upstream devs also work on light locker, so it will be done soon. please approve the branch
<Logan_> Noskcaj: Please file a bug. :)
<Noskcaj> I'll do that tomorrow, need sleep now.
<tester56> what does apport-noui do exactly? (it is stated that it automatically submit bugreports, but does it do so when "sumbit bug reports to canonical" is disabled?)
<doko> jamespage, why is this golang patch not applied in debian?
<jamespage> doko, differences in the way dpkg detects shared library deps (I think)
<jamespage> doko, I can probable persuade the debian maintainer to take that patch
<jamespage> I think it should not effect the debian builds negatively
<doko> wgrant, your pykde4 upload now lets python3-pyqt4 depend on both libpython3.3 and libpython3.4. it should not directly link the extension against the shared library
<doko> I do love embedded waflib copies everywhere ...
<ogra_> can't have enough of them :)
<jtaylor> can someone reproduce the skimage adt failure?
<jtaylor> I can't in a chroot or adt-run
<jtaylor> (ignore the 3.4 failure, adt chokes on py3.3 which I can'T reproduce)
<doko> jtaylor, https://launchpadlibrarian.net/161710633/buildlog_ubuntu-trusty-arm64.fftw3_3.3.3-7ubuntu1_FAILEDTOBUILD.txt.gz
<doko> did you introduce this?
<doko>   * enable runtime detected neon support for arm64
<jtaylor> yes
<jtaylor> I was told (here) arm64 has neon
<jtaylor> so why doesnt it work? no hardware or gcc does not support it?
<xnox> jtaylor: neon is uncoditional on arm64 and it's supperset of armhf, so one doesn't need to specify neon build flags
<jtaylor> interesting, gcc could ignore the flag then ...
<jtaylor> fix requires a change the the build system
<xnox> jtaylor: it's wrong to set it. cause you might be forcing an armv7 build instead of armv8.
<jtaylor> dropping --enable-neon will disable neon altogether even if its auto-on
<xnox> jtaylor: remember that arm64 can execute armv7/32bit binaries with neon.
<jtaylor> patches accepted, I don't have the hardware to test it
<xnox> jtaylor: mk-sbuild --arch arm64?
<xnox> jtaylor: mk-sbuild --arch arm64 trusty?
<jtaylor> that works now?
<jtaylor> nice
<xnox> jtaylor: it worked since trusty opening, saucy release had small bug in qemu-debootstrap however.
<jtaylor> but I don't use sbuild
<xnox> jtaylor: use whatever you use, there is qemu-user-static binary for arm64.
<xnox> so you can execute native arm64 chroots.
<jtaylor> meh I don't have time for that now, patch it out, I'll fix it when it gets a problem in debian
<jtaylor> fftw needs merging anyway
<xnox> jtaylor: yeah back it out in ubuntu or debian or both.
<xnox> cause otherwise fftw will be stuck in -proposed.
<jtaylor> its main so nothing I can do
<jtaylor> or better its more time efficient for someone else to drop the two lines
<xnox> jtaylor: i think you should do it =)))) you could have pastebined patch "enabling neon arm64" asking anybody here to test it.
<jtaylor> I did
<jtaylor> was told it works, so I did it to save an extra upload
<xnox> jtaylor: and there was a non-ftbfs build log?
<jtaylor> at the time it was said qemu arm64 does not work yet
<xnox> jtaylor: yes, neon works on arm64. that build FTBFS however.
<jtaylor> asier to just do it on real hardware and see then
<jtaylor> which is what I did
<jtaylor> now we have the result :)
<jtaylor> and can fix it
<jtaylor> I'm happy to take any patches and forward them upstream
<jtaylor> if you don't want to bother creating one drop the two lines in debian/rules and disable it altogether
<jtaylor> I may have time to look into it myself but not today
<jtaylor> sorry for abusing ubuntu as my testing platform, should have asked for a buildlog when I did this
<jtaylor> information needed for a proper patch is how to detect arm64 in configure.ac
<jtaylor> hm a debian specific one is simpler as we can assume gcc supports fpu=neon
<cjwatson> jtaylor: aarch64*
<jtaylor> just dropt he gcc check
<cjwatson> (in case "${host_cpu}" etc.)
<jtaylor> do you know an example of the top of your head?
<cjwatson> I was basing that on the "dnl configure options" block near the top of configure.ac
<cjwatson> the arm64 triplet starts with "aarch64" so you can use that
<cjwatson> cf. "dpkg-architecture -aarm64 -qDEB_HOST_GNU_TYPE" (ignore stderr)
<mitya57> jtaylor: If you prefer pbuilder over sbuild, then 'pbuilder-dist trusty arm64 create' should do the thing
<jtaylor> mitya57: not in saucy :/
<jtaylor> not running trusty yet
<jtaylor> oh no
<jtaylor> I'm just dumb and mixed upt he ordering
<jtaylor> k then I can give it a try today
<mitya57> You can always backport ubuntu-dev-tools & qemu-debootstrap
<jtaylor> qemu backport requires more backports :/
<xnox> jtaylor: yeah, for host_cpu aarch64 it should define have_neon & not mangle gcc flags. But do get that test-built before uploaded.
<xnox> jtaylor: qemu-user-static are statically linked binaries... so just download the deb & unpack arm64 static binary out of it.
<xnox> (or install trusty qemu-user-static)
<jtaylor> nice thx
<xnox> jtaylor: or run nested chroots.... =) chroot into trusty, then create arm64 pbuilder/sbuild/whatever chroot there for arm64.
<jtaylor> why must arm64 look like amd64 :( I always click the wrong linkg when downloading debs
<jtaylor>  /usr/sbin/qemu-debootstrap --arch arm64; E: Sorry, I don't know how to support arch
<jtaylor> version 1.7.0
 * xnox votes to rename all arches using UUIDs
<xnox> jtaylor: yeah that's the other bit i've fixed in trusty. it's a shell script with hard-coded names of arches it knows about....
<xnox> (or maybe it wasn't shell, it's just a script...)
<jtaylor> I installed the trusty versiion
<jtaylor> 1.7.0+dfsg-2ubuntu5
<jtaylor> xnox: ^
 * xnox wonders if it got broke again.
<xnox> hallyn: looks like 1.7.0+dfsg-2ubuntu1 merge reverted/dropped changes I've applied in 1.6.0+dfsg-2ubuntu4
<xnox> hallyn: where/how should they be done, to not get lost? as qemu-debootstrap for arm64 is now broken again...
<xnox> debian/binfmts/qemu-arm64 possibly also reverted, not sure.
<didrocks> stgraber (or other lxc gurus): do you know if you can mount /proc in a lxc container? My debootstrap is failing me on that one: W: Failure trying to run: chroot /var/cache/pbuilder/trusty-amd64/base.cow/. mount -t proc proc /proc
<asac> didrocks: not sure if its relevant, but i see something about lxc config to mount proc/sys here: http://l3net.wordpress.com/2013/11/03/debian-virtualization-lxc-debootstrap-filesystem/
<asac> lxc.mount.entry=proc /proc proc nodev,noexec,nosuid 0 0
<asac> lxc.mount.entry=tmpfs /dev/shm tmpfs  defaults 0 0
<didrocks> asac: I guess this is to mount /proc into the container, let me look/have a try
<didrocks> asac: yep, that didn't do it from what I tried
<jtaylor> xnox: ping me when its fixed and I'll have a look (bin/qemu-arm64-static also does not exist)
<jtaylor> that its in proposed doesn't matter, the only really relevant change is arm64 support
<asac> ogra_: xnox: do you know about lxc (see didrocks question above)? if not, anyone besides stgraber who might know?
<jtaylor> actually is arm64 build now required for proposed migration?
<ogra_> there shouldnt be anything blocking you from mounting /proc
<didrocks> ogra_: weird, I used the ubuntu template to create my container though
<xnox> didrocks: i think by default you cannot mount / remount proc from inside the lxc container. You should either specify it in the template on the host side, or grant the container to do so (note it's a security risk and apparmor will block from doing so as well)
<xnox> didrocks: what's your use-case / what are you trying to achieve?
<ogra_> xnox, better ask what is pbuilders use-case :)
<didrocks> xnox: I'm just trying to test locally my new ci system (pbuilder/cowbuilder are used to create source package) and I didn't want to install jenkins on my desktop, so lxc container ;)
<xnox> jtaylor: the requirement is imposed by britney and it's same as it always been, the built architectures should not regress - since there if fftw3/3.3.3-5ubuntu1 built on arm64, it should continue to be built on arm64.
<xnox> jtaylor: and enforced by release & archive teams =)
<didrocks> (and the jenkins CI job is using then the pbuilder/cowbuilder, that's why I'm trying to create one inside the container)
<xnox> didrocks: right, i think we do apparmor confinment on the lxc containers by default, but there was a  key / config to disable apparmor confinment for a given lxc container.
 * asac lunch
<xnox> didrocks: (reboot of the host may be required)
<xnox> didrocks: alternatively $ juju bootstrap lcy01 / lcy02 and have disposable things to install jenkins on ;-)
<didrocks> xnox: interesting, ok, let me have a look :)
<cjwatson> xnox: not so much enforced as we generally decline to overrule the automation :)
<cjwatson> jtaylor: full docs: https://wiki.ubuntu.com/ProposedMigration
<didrocks> xnox: right, the thing will be jujuifed, but right now, local development :)
<jtaylor> thx
<xnox> didrocks: i at times launch throwaway instances in couple of click through dashboard.cs.c.c  to install things like jenkins to not trash my host, nor sufficate from my small VM sizes / lxc container restrictions.
<caribou> xnox: I gave a shot to merging backuppc following Logan's confirmation that he would not work on it
<tester56> will qt 4.8.5 land in trusty?
<mitya57> tester56: yes, it's almost ready
<mitya57> Waiting for Rohan to do some final testing & upload
<ogra_> pfft ... 4.8 ... use 5.x !
<ogra_> :)
<mitya57> ++ogra_
<tester56> would resolve a few crashes: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1200523
<ubottu> Ubuntu bug 1200523 in qt4-x11 (Ubuntu Saucy) "Some of the kubuntu patches break plasma" [Undecided,Fix released]
<tester56> see also https://bugs.kde.org/show_bug.cgi?id=302931
<ubottu> KDE bug 302931 in general "changed a value in system settings and clicked APPLY [@ Plasma::FrameSvgItem::~FrameSvgItem]" [Crash,Resolved: downstream]
<tester56> just experienced one crash yesterday with trusty
<mitya57> the first bug is marked as already fixed
<caribou> xnox: I Have a bzr branch ready if you want to have a look
<mitya57> the second one looks like the same issue
<xnox> caribou: make a merge proposal against lp:ubuntu/$package
<xnox> caribou: leave the default reviewers.
<xnox> caribou: and request a second review from me (~xnox)
<xnox> (that way i get notified, and it will also land in the sponsorship queue report)
<caribou> xnox: I used lp:ubuntu/backuppc/trusty-proposed as a reference branch, is that correct ?
<tester56> mitya57: yeah is the same issue, but according to the bug report it is only resolved using 4.8.5 ...
<xnox> caribou: lp:ubuntu/backuppc
<caribou> xnox: the source branch ?
<xnox> caribou: if trusty-proposed was ahead of ubuntu/backupppc, you'd add your changes on top of lp:ubuntu/trusty-proposed/backuppc but still make merge proposal into lp:ubuntu/backuppc
<caribou> xnox: ok, I'll check both & rebuild if needed
<xnox> caribou: it doesn't matter in this case as both lp:ubuntu/backupppc and lp:ubuntu/trusty-proposed/backuppc are the same, 3.2.1-4ubuntu2 is last version in either of the branches.
<caribou> xnox: k
<knocte> is medibuntu down? I can't access http://packages.medibuntu.org/
<ogra_> knocte, support is in #ubuntu
<knocte> sorry
<ogra_> (and i think medibuntu stopped a while ago)
<stgraber> didrocks: you can but not with the default apparmor profile as doing so is a security risk.
<didrocks> stgraber: ok, that confirms then, I'll fetch your documentation as well on what needs to be disabled then
<xnox> stgraber: as alternative, i've directed didrocks to use beefy canonistack instances, instead of local lxc containers.
<stgraber> didrocks: let me grab you my sbuild LXC apparmor profile, that should do the trick for you.
<didrocks> stgraber: ah, excellent, that should unblock me for the short term (like today) and I'll then look at canonistack within the week
<stgraber> didrocks: set lxc.aa_profile to lxc-container-default-builder for your container
<stgraber> didrocks: then create /etc/apparmor.d/lxc/lxc-default-builder containing: http://paste.ubuntu.com/6703385/
<stgraber> didrocks: after that, do "sudo /etc/init.d/apparmor reload" and restart your container
<stgraber> didrocks: those rules are enough for me to run sbuild here (used for LXC's own CI environment), I'm only guessing they should work with pbuilder too. If something still fails, let me know (with a copy of the dmesg output) and I'll tell you what to add.
<mitya57> Funny MP: https://code.launchpad.net/~chris.gagnon/kubuntu-packaging/enable-unit-tests-qtbase-opensource-src/+merge/200535 - states that DFSG is not mandatory in Ubuntu
<mitya57> I believe it is, at least in main/universe
<mitya57> Thoughts?
<cjwatson> mitya57: He's sort of correct; for non-code elements the Ubuntu licensing policy states that we'll consider them case-by-case
<cjwatson> Though it's still good practice to do things in a Debian-mergeable way where possible
<cjwatson> mitya57: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-ulp
<mitya57> Yes, will ask if we can skip tests that need such data
<cjwatson> (last para of that section)
<didrocks> stgraber: worked perfectly! Thanks a lot :)
<stgraber> didrocks: good to hear! np
<hallyn> xnox: hm.  well i keep the source at github.com/hallyn/qemu, but I looked at all the debdiffs in the archive so shouldn't have lost any changes.  i'll look at 1.6.0+dfsg-2ubuntu4 again - though my internet is dead so i'm on ip-over-pigeon right now.
<mlankhorst> erm
<mlankhorst> is it just me or is the toolchain messed up ?
<mlankhorst> checking if gcc -std=gnu99 static flag -static works... *** Error in `/usr/bin/ld': corrupted double-linked list: 0x091a6558 ***
<mlankhorst> on i386
<mlankhorst> gcc -std=gnu99 -o conftest -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -DPRE_RELEASE=0 -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-Bsymbolic -static conftest.c
<mlankhorst> $ cat conftest.c
<mlankhorst> int main(){return 0;}
<mlankhorst> /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail ../../bfd/elflink.c:13053
<dholbach> xnox, seb128: do you know what might cause this: http://paste.ubuntu.com/6703638/ ?
<mlankhorst> bleh
<dholbach> it happens when running http://paste.ubuntu.com/6703644/
<mlankhorst> anyone wants to look at that toolchain failure?
<seb128> dholbach, I don't
<dholbach> seb128, should I file a bug for it?
<xnox> dholbach: arch mis-match? what's your "host" / main arch, and which foreign arches are enabled?
<xnox> dholbach: you shouldn't need to install "ubuntu-sdk-libs-dev:armhf" that's already installed (abeit partially)
<mlankhorst> bleh
<mlankhorst> does gcc -fPIE -pie make sense on a static binary?
<xnox> mlankhorst: on some arches =)))))))
<mlankhorst> xnox: -static -fPIE -pie ?
<dholbach> xnox, I just wanted to make sure that everything's installed, to make sure it works as part of instructions for folks to compile their QML extensions
<mlankhorst> well I guess it might
<xnox> mlankhorst: oh pie, not pic. hm.... not sure.
<seb128> dholbach, I guess you can, though I'm not the best person to ping about multiarch issues, let's see if xnox manages to help you ;-)
<mlankhorst> still staticaly linked and movable
<cjwatson> dholbach: no, you shouldn't put that in instructions.  anything that click chroot create doesn't already install that's needed would be a bug in click
<xnox> dholbach: the instructions should be - click create, cmake compile.
<cjwatson> please don't work around software bugs in instructions ...
<cjwatson> (if it is a bug)
<xnox> cjwatson: should i seed cmake:native somewhere, or can you install one, btw?
<dholbach> cjwatson, no, I didn't want to work around software bugs - I just assumed that ubuntu-sdk-libs-dev would give people everything they potentially need to compile their QML extensions
<xnox> dholbach: where are these instructions you are talking about?
<cjwatson> dholbach: click chroot is already meant to install everything they need
<dholbach> xnox, there are none right now
<dholbach> cjwatson, ok, thanks
<cjwatson> xnox: send me an MP with a suitable change to click/chroot.py?
<xnox> cjwatson: ack.
<dholbach> (and this was just for playing around locally)
<dholbach> tedg, who could nudge https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194 along? :)
<tedg> dholbach, charles_ has been doing most of those reviews, considering the weather, sending hot chocolate is probably your best bet :-)
<dholbach> tedg, thanks
<dholbach> charles_, if you have a bit of time, it'd be fantastic if you could review the MP mentioned above :)
<charles_> dholbach: I'll review it asap, it's third on my list right now
 * dholbach hugs charles_
<dholbach> thanks a bunch!
<charles_> hm, when did I pick up an _ on my nick
<xnox> tedg: that would be Ice Frapuchinno on arrival ;-)
<tedg> xnox, You clearly don't believe in the magic that is dholbach ;-)
<tedg> It is freaky cold though.  Staying inside today.
<xnox> tedg: very cold here as well, i've put on socks today with my flip-flops. =))))))
<ogra_> tedg, just come over to europe ... we are stuck in eternal fall/spring here
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1266492 causes a FTBFS when attempting to rebuild existing xorg-server too
<ubottu> Ubuntu bug 1266492 in binutils (Ubuntu) "ld:i386 crashes with -static -fPIE -pie" [High,New]
<xnox> tedg: is it just me or click app launcher can block until the app is started? e.g. like with normal upstart job one has $ start foo; and $ start --no-wait foo. First one will block, until foo is started. The second one, will return immediately.
<xnox> tedg: i'm asking because starting click apps in the  emulator, on underclock CPUs of cloud instances take forever wall-clock time, and autopilot currently timesout within "10 seconds" (actually 10x1s sleeps, which are subject to poor clock resolution)
<tedg> xnox, I think that should work, but the cascading may break it.  I haven't tested.  But that changes a lot in the proposed MRs, so I wouldn't test on trunk today.
<dholbach> tedg, I could ask the XKCD guy to find out how hot a hot chocolate would need to be to survive 8200km and still be nice and warm ;-)
<xnox> tedg: i'm testing as it is on the current system-images (stock, no ppas enabled etc.)
<tedg> dholbach, Wonder if you could get one of those containers they store liquid nitrogen in... they're very insulated.
<xnox> dholbach: isn't that same as http://what-if.xkcd.com/1/ ?
<tedg> xnox, That's old :-)  You might see if the behavior is different if you call "application-click" directly.
<xnox> tedg: right, let me compare with what autopilot code actually calls....
<dholbach> xnox, if the hot hot chocolate experiment resulted in http://what-if.xkcd.com/imgs/a/1/05.png I'd probably try tedg's approach first :-)
<xnox> tedg: autopilot does "$ start application APP_ID=$(app_id)" that doesn't block does it?
<xnox> (can it be optionally made to block?)
<tedg> xnox, It calls "start" for the sub-jobs, which should block, no?
<tedg> xnox, But, again, that's going to change a lot, so I'd not want to fix it for trunk today.
<xnox> tedg: right, i'll work around that in my juju charm then.
<xnox> (for now)
 * xnox needs proof of concept anyway.
<bdmurray> xnox: bug 1022815, which you commented on at one point in time has had a patch added
<ubottu> bug 1022815 in cryptsetup (Ubuntu) "initramfs should try password against other devices" [Undecided,Confirmed] https://launchpad.net/bugs/1022815
<charles> dholbach, ted: https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194 approved
<hallyn> jdstrand: regarding test-libvirt.py in qrt;  it does a device-detach then checks whether the device was removed from apparmor profile.  However, libvirt now waits for qemu to say the device is removed before actually removing the device, and since the guest image doesn't do acpi that never happens
<hallyn> jdstrand: so do you prefer to (a) add acpi to the guest image, (b) check that the device is in the vm's xml and skip the apparmor check if so, or (c) skip the test on new libvirt?
<smagoun> cyphermox: Hi, do you know if anyone is looking at the nm-applet bug that results in multiple "Authetication Required" dialogs onscreen? It's lp:#1224040; the bug is still present in 14.04.
<cyphermox> smagoun: it was supposed to have been fixed long ago, I'm going to ask upstream. I certainly haven't seen it happen in a long while here and I used to get that to show up pretty easily
<smagoun> cyphermox: It's easy enough for me to reproduce. I came back to a machine that was idle for 2 weeks, if my math is right there were 3196 dialogs onscreen. :/ nm-applet was using 2.4GB of ram
<cyphermox> oh, I believe you :)
<smagoun> cyphermox: anyway, thanks  for checking with upstream. Let me know if there is anything I can do to help debug/test!
<cyphermox> sure
<cyphermox> I discussed this with dcbw a few times already, I'll just remind him and let him know it's still broken
<sarnold> oooof, 3196 dialogs? did you grab a screenshot?
<roadmr> sarnold: I think all the dialogs are superimposed, so they look like a single dialog (but with an evil thick black border)
<sarnold> roadmr: heh, those must be some very menacing pixels indeed :)
<roadmr> sarnold: haha :) yes, it's just the merged drop shadows from all the dialog but it looks weird somehow
<smagoun> sarnold: no screenshot no, but I have a witness (pmcgowan, who is not in this room right now) . You can see all the dialogs using super-w in unity, which is sloooooooooooow with that many dialogs
<sarnold> smagoun: oh well, it sounds less impressive than I hoped for. :)
<smagoun> :)
<nashant> Hi guys. Can anyone tell me where to find the python indicator api docs? Every link I go to says it's gone. I'm fed up with the rubbish power indicator with no brightness control
<Noskcaj> cjwatson, bug 1266516
<ubottu> bug 1266516 in console-setup (Ubuntu) "New version available upstream: 1.104" [Undecided,New] https://launchpad.net/bugs/1266516
<jdstrand> hallyn: ok, I'm here (and still trying to climb out of holiday backlog)
<jdstrand> hallyn: I think ideally we would adjust the vm to have acpi, since the code is all still there to do this in libvirt and we should be testing for it
<jdstrand> hallyn: iirc, the libvrt vm is dapper. if there were other reasons to update the vm that would be helpful for adding tests, then I would go that route. otherwise, skip the test until such time as you want to regenerate the vm?
<hallyn> jdstrand: how did you generate the vm?  wonder if i coudl just update sources.list and have it work :)
<jdstrand> hallyn: see QRT/scripts/libvirt/README.qatest
<hallyn> k
<jdstrand> hallyn: basically, that should work. it is just ubuntu-minimal + ssh
<cjwatson> Noskcaj: ack, will try to look this week; it generally takes some time
<hallyn> built using vmbuilder, which is being dropped :)
<nashant> Hi guys. Can anyone tell me where to find the python indicator api docs? Every link I go to says it's gone. I'm fed up with the rubbish power indicator with no brightness control
<cyphermox> smagoun: I think I may have just made sense of it now... going to test a patch
<smagoun> cyphermox: NIce! I'd be happy to test too
<stgraber> cjwatson: I've got an e-mail in the u-d-a queue when you have a minute
<infinity> stgraber: Accepted.
#ubuntu-devel 2014-01-07
<nashant> Hi guys. Can anyone tell me where to find the python indicator api docs? Every link I go to gives me a 404
<cyphermox> smagoun: there will be a package in my PPA for you to test. I'd like to get your input on it before I upload to the archive, just in case what I'm reproducing isn't quite the same issue as you're seeing on your system.
<cyphermox> I updated bug 1224040 with the explanation and the link
<ubottu> bug 1224040 in network-manager (Ubuntu) "13.10: Multiple network manager authentication dialogs for saved network" [Medium,In progress] https://launchpad.net/bugs/1224040
<cyphermox> the fix is for trusty, since you mentioned testing on it, but you should be able to safely install the package on saucy as well
<GunnarHj> robert_ancell: ping?
<robert_ancell> GunnarHj, hi
<GunnarHj> robert_ancell: Hello
<GunnarHj> robert_ancell: Does lightdm check gsettings to determine if the guest session feature shall be disabled? I'm asking because of this change I just proposed to the desktop guide description of guest session: http://bazaar.launchpad.net/~gunnarhj/ubuntu-docs/addremove/revision/325
<robert_ancell> GunnarHj, lightdm only checks it's own config, not gsettings
<GunnarHj> robert_ancell: Thanks, that's what I thought.
<robert_ancell> GunnarHj, btw I just moved that file a few hours ago to /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf
<robert_ancell> You should get the user to edit /etc/lightdm/lightdm.conf with custom settings - that will override the other settings
<robert_ancell> or create a new file, e.g. /etc/lightdm/lightdm.conf.d/50-disable-guest.conf
<robert_ancell> I'd prefer the latter
<GunnarHj> robert_ancell: Ok... I thought you had deprecated lightdm.conf. Which would you recommend?
<GunnarHj> robert_ancell: Saw your answer.
<robert_ancell> LightDM loads files from /usr/share/lightdm/lightdm.conf.d first, then /etc/lightdm/lightdm.conf.d then /etc/lightdm/lightdm.conf
<robert_ancell> /usr/share contains package configuration (not editable) and /etc sysadmin config
<GunnarHj> robert_ancell: Is one line enough, or must [SeatDefaults] be there?
<robert_ancell> must have a seat defaults
<robert_ancell> all config is in a section
<GunnarHj> robert_ancell: I see.
<robert_ancell> GunnarHj, I'd like to split out the guest sessions into separate .desktop files, then it will just become "sudo apt-get remove unity-guest-session"
<robert_ancell> It's on my list of nice-to-haves to implement for 14.04
<robert_ancell> because this is such a common case and a pita to currently configure
<robert_ancell> automatic logins is the next pita
<GunnarHj> robert_ancell: Thanks for letting me know. (suppose you mean separate .deb files)
<robert_ancell> GunnarHj, I'd love feedback on things that are hard to document - good cases for improving lightdm
<robert_ancell> yes
<GunnarHj> robert_ancell: Since you are there, and I'm still awake, are you waiting for Jonathan's review of https://code.launchpad.net/~gunnarhj/lightdm/guest-dialog-kubuntu/+merge/199490 ?
<robert_ancell> GunnarHj, yes, does he know about it?
<GunnarHj> robert_ancell: I have sent him a couple of emails too, but no response.
<robert_ancell> I just don't want to land something and break kubuntu
<robert_ancell> other than that I'm happy
<GunnarHj> robert_ancell: Actually, I did test on Kubuntu, so the review request was more to be polite.
<GunnarHj> robert_ancell: It wouldn't break anything.
<robert_ancell> GunnarHj, I think we've given him sufficient time, are you happy to land without a formal review?
<GunnarHj> robert_ancell: Yes.
<GunnarHj> robert_ancell: But before merging you'd better take a look at the /media/guest-XXXXXX code I added.
<robert_ancell> I did look, it seemed fine
<GunnarHj> Ok, great!
<robert_ancell> btw, you should really make multiple MPs for different fixes like that
<robert_ancell> makes it easier to diagnose if problems later
<GunnarHj> robert_ancell: Ok, noted.
<Fudge> thanks robert_ancell  for the lightdm unity-greeter back button work
<robert_ancell> Fudge, np, thanks for finding it!
<Fudge> my pleasure, very glad to find little bugs like that to increase the user experience :D
<smagoun> cyphermox: that is great news about 1224040. I will test that out tomorrow when I'm back at the office with the misbehaving machine
<cyphermox> sure
<cyphermox> so far it seems to work here, but I only tested pretty quickly considering... it was only left unattended two hours
<smagoun> cyphermox: I can usually reproduce 2-3 times/day, so we should know for sure this week
<cyphermox> but it definitely should have popped up multiple dialogs during that time, and there was only one as the patch should be doing
<Mirv> mitya57: did you get an confirmation from doko yet on whether hrw is right in that the aarch64 atomics patches can be dropped with Qt 5.2?
<Mirv> mitya57: the latest news is what I wrote before Christmas - everything needs to build against the new Qt, and the dependency chain is currently stopped at gsettings-qt (while dbusmock was now fixed)
<mitya57> Mirv: no, still waiting for doko's response on that
<pitti> Good morning, happy new year everyone!
<darkxst> doko, would you have any idea about Bug 1266605
<ubottu> bug 1266605 in matplotlib (Ubuntu) "matplotlib crashes after recent tcl/tk update" [Undecided,New] https://launchpad.net/bugs/1266605
<darkxst> it seemed to break the other day when tcl8.5-lib got removed
<pitti> infinity: so 12.04.4 is on Feb 6th; should I already do a langpack refresh now? it's been a while since precise got new langpacks (we forgot it for .3), so they can get some more testing time (just in case)
<pitti> I just got a full export in LP
<infinity> pitti: Sounds like a plan.
<Fudge> is the context menu in the launcher called a lense?
<dholbach> good morning
<pitti> infinity: uploading, looking good (they'll land in unapproved)
<pitti> infinity: can self-accept, if you don't mind; buildds are rather calm ATM
<infinity> pitti: Go nuts.
<tseliot> davmor2: I probably forgot to tell you that nvidia-persistenced is now part nvidia-331 in 14.04. So you can enable persistence mode from the configuration file
<pitti> hey tseliot, happy new year!
<tseliot> pitti: happy new year to you :)
<pitti> tseliot: wrt. bug 1126234, ISTR that there was some work going on to support intel+nvidia at the same time
<ubottu> bug 1126234 in ubuntu-drivers-common (Ubuntu) "Does not show nvidia driver if intel card is active" [High,Triaged] https://launchpad.net/bugs/1126234
<pitti> tseliot: do we need to change that special case in ubuntu-drivers to hide the nivida driver if intel is active?
<pitti> tseliot: or does hybrid graphics still only work with the free drivers?
<tseliot> pitti: we can enable the nvidia drivers on some systems (not desktops) with new nvidia drivers and intel. The same can be done with amd
<smb> Looking at bug 1244176 I am wondering... I know respinning Saucy images is really really unlikely. Not sure about the netboot mini isos. Alternatively is there a simple replace kernel in iso howto we could point to?
<ubottu> bug 1244176 in linux (Ubuntu Trusty) "Server 13.10 Install Fails with USB Keyboard (Appears to Hang)" [High,Fix released] https://launchpad.net/bugs/1244176
<pitti> tseliot: ah, so in general that behaviour is still adequate?
<tseliot> pitti: yes, kind of. I need to make sure that we do that only when we really need it, and otherwise enable nvidia. Feel free to assign that bug report to me
<pitti> tseliot: thanks for the heads-up; so it's still mostly correct
<pitti> tseliot: well, I set the bug to triaged, but I don't see that we can do much about it until the nvidia driver changes fundamentally?
<tseliot> pitti: yes, but, in most cases, if you install the nvidia driver manually, it just works (whether you have hybrid graphics or not), as I added some logics in the nvidia-prime package
<pitti> tseliot: right, but I guess that disables the intel card then, right?
<tseliot> pitti: not really, it keeps using the intel card (using the modesetting driver) to drive the monitors and offloads rendering to nvidia. So it uses both GPUs
<tseliot> pitti: then, thanks to my work, you can also choose to switch off the nvidia GPU from the nvidia-settings panel
<tseliot> (to save power)
<pitti> oh, amazing!
<tseliot> :)
<pitti> tseliot: that actually sounds like we should drop that explicit hiding?
<pitti> or at least refine it to only apply to older driver versions which don't support that yet?
<tseliot> pitti: yes, I'd like to implement the same logic from the nvidia-prime package
<tseliot> it will be mostly a matter of clever copying and pasting ;)
<pitti> tseliot: great; I assigned the bug to you then, but I'm happy to help with the implementation if you tell me what needs to be checked
<tseliot> pitti: this is something I also need to refine in Jockey for 12.04.4, so I was planning to work on both implementations. I'll let you know if I have any doubts or if I need help. Also, I'll show you the final commit when it's ready.
<pitti> tseliot: thanks
<doko> mlankhorst, mesa question. by simply including GL/GLwMDrawA.h, how is GLAPI supposed to become defined?
<mlankhorst> doko: erm no idea :)
<doko> ... says the mesa packager ;p
<mlankhorst> glapi is internal, why?
<doko> mlankhorst, hacked around it: http://launchpadlibrarian.net/161786200/arb_5.5-5_5.5-5ubuntu1.diff.gz
<mlankhorst> doko: that's even more terrible than the ld -static -fPIE -pie hack I had to do..
<mlankhorst> bug #1266492
<ubottu> bug 1266492 in binutils (Ubuntu) "ld:i386 crashes with -static -fPIE -pie" [High,Confirmed] https://launchpad.net/bugs/1266492
<pitti> roaksoax: hey Andres, happy new year!
<pitti> roaksoax: do you have some time estimate for bug 1254053?
<ubottu> bug 1254053 in MAAS "Installing MAAS on trusty gives a big warning about deprecated postgresql 9.1" [High,Triaged] https://launchpad.net/bugs/1254053
<infinity> pitti: Hey, speaking of postgres and osolescence, can you prod upstream about that oom_adj thing that stalled?  I read through the mailing list debate on how to fix it a few years ago, and then people just stopped talking about it.
<infinity> pitti: Seems a bit silly for it to *still* be tripping that ringbuffer spam after all these years.
<pitti> infinity: indeed; will do
<pitti> infinity: debian bug 646245, I'll fix that in Debian and send the patch upstreamwards
<ubottu> Debian bug 646245 in postgresql-9.3 "postgresql-9.1: Writes obsolete /proc/pid/oom_adj instead of /proc/pid/oom_score_adj" [Minor,Open] http://bugs.debian.org/646245
<infinity> pitti: Oh, you had a patch you liked for it?
<infinity> pitti: Upstream's longwinded mailing list thread on the topic seemed to cover a lot of ground. :P
<pitti> infinity: not yet; that's the "will" part
<pitti> infinity: ah, I need to read that then
<pitti> it seems rather simple, if oom_score_adj exists, that should be used, otherwise fall back to oom_adjj
<infinity> pitti: Linked from https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/991725
<ubottu> Ubuntu bug 991725 in postgresql-9.1 (Ubuntu) "postgres is using deprecated /proc/PID/oom_adj" [Low,Triaged]
<infinity> http://www.postgresql.org/message-id/29121.1316185073@sss.pgh.pa.us
<infinity> pitti: It's pointed out that the two files mean different things.  But if you're always setting to 0, that means the same tihng for both.
<pitti> infinity: right, in postgresql-common I use -900 for oom_score_adj and -16 for oom_adj
<infinity> http://www.postgresql.org/message-id/CAEik5nPuNBHZgOGX3-baU=WKD353Hrw5qnWrw8dr6iViQ6553A@mail.gmail.com has a patch (and a fix) to just dupe the Linux adjust calculations, so you can have just the one value in postgres.
<infinity> But that, as rightfully pointed out, is duplicating kernel code that could change.
<infinity> Then again, if it changed, your values are wrong regardless, and I suspect it *won't* change.
<infinity> pitti: I think I personally like that patch, and find the "duplicating kernel interfaces" argument to be silly, given that it's one simple arithmetic transformation from one range to another range that is almost certainly not going to change without a third interface being added to the kernel.
<infinity> pitti: As pointed out in the thread before it died, this might just be a "he who does the work wins" thing, so maybe just committing that would end the suffering. :P
<pitti> infinity: right, just stumbled over that; for a Debian-only patch it can even become simpler, as we know we don't change the value in our package
<pitti> but the scale change seems simple enough, it's not going to change
<mlankhorst> hm, am I going to need a MIR for libxshmfence and x11proto-dri3?
<pitti> hallyn: hey Serge, how are you? happy new year!
<pitti> hallyn: latest qemu dropped pci_add; do you know how to translate "pci_add auto storage file=$PATH,if=virtio,index=2,readonly" to current qemu?
<pitti> hallyn: there is just about zero documentation for device_add, and the ",help" output doesn't help much either :(
<pitti> hallyn: i. e. I want to do the equivalent of "-drive file=..." at hotplug time (through the monitor)
<davmor2> tseliot: how do I enable persistence in the conf?
<trijntje> ping cjwatson: can I draw your attention to bug 1265297
<ubottu> bug 1265297 in syslinux-themes-ubuntu (Ubuntu) "Please release package for trusty" [Undecided,New] https://launchpad.net/bugs/1265297
<cjwatson> trijntje: sure
<trijntje> cool, I was hoping to create localised Dutch iso's  for trusty using ubuntu-defaults-builder, but the build process requires syslinux-themes-ubuntu-trusty
<cjwatson> trijntje: uploaded, but the build will need manual processing by an archive admin since it introduces a new package.  shouldn't take too long and the bug will be closed once it happens
<trijntje> cjwatson: awesome, thanks a lot!
<tseliot> davmor2: in /etc/init/nvidia-persistenced.conf you should simply replace "/usr/bin/nvidia-persistenced --user nvidia-persistenced" with "/usr/bin/nvidia-persistenced --user nvidia-persistenced --persistence-mode"
<roaksoax> pitti: Hi Martin... i tought i had fixed that already. i'll double check and close the bug! thabk you for noticing!
<pitti> roaksoax: oh, indeed; it was still there in December; thanks!
<pitti> roaksoax: indeed http://launchpadlibrarian.net/160048328/maas_1.4%2Bbzr1693%2Bdfsg-0ubuntu3_1.4%2Bbzr1789%2Bdfsg-0ubuntu1.diff.gz drops the postgresql-9.1 dep
<pitti> roaksoax: bug updated, thanks!
<roaksoax> pitti: sorry about that then (not closing the bug report). thanks though!
<davmor2> tseliot: will do
<knocte> Cimi: ping
<hallyn> pitti: hey.  My patch to qrt to deal with that change is http://people.canonical.com/~serge/qrt-qemu.diff.  So it would look like:
<hallyn> drive_add 0 file=$PATH,if=none,id=disk1
<hallyn> device_add virtio-scsi-pci,id=disk1
<hallyn> pitti: I really wish pci_add would stay around
<pitti> hallyn: ah, jibel tried something like that in http://paste.ubuntu.com/6709139/ but said that it would fail for virtio with an error, it just works for a scsi disk
<pitti> hallyn: thanks for the pointer!
<Cimi> knocte, pong
<knocte> Cimi: hello, happy new year!, can you review/merge https://code.launchpad.net/~knocte/ubuntu-themes/bring-back-zebra-striping/+merge/200429 when you got a chance?
<Cimi> knocte, happy new year, thanks!
<Cimi> done
<knocte> merci!
<hallyn> pitti: np - happy new year to you too :)
<pitti> jamespage: FYI, I uploaded http://launchpadlibrarian.net/161802756/waitress_0.8.8-1ubuntu2_0.8.8-1ubuntu3.diff.gz to complete dropping the autopkgtest (your upload is stuck in -proposed due to that)
<jamespage> pitti, indeed it did - I move the autopkg tests into the actual package build
<jamespage> they did not really need to be DEP-8 tests IMHO
<jamespage> pitti, so it was just the missed header holding it up?
<pitti> jamespage: yes, when trying to run adt-run on a package without tests you get errors
<pitti> jamespage: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-waitress/14/ARCH=i386,label=adt/console
<jamespage> pitti, well that makes sense :- )
<jamespage> pitti, I'd spotted the error - but missed what was causing the problem
<pitti> jamespage: FTR, running upstream tests against the build tree is certainly wrong in autopkgtest; but having some smoke-test in autopkgtest against the installed binaries is valuable to ensure newer dependencies don't break your package
<pitti> jamespage: and also to ensure that your packaging didn't break and forget a library, dependency, some other file, etc.
<jamespage> pitti, agreed - have alot of packages that do that already
<pitti> jamespage: I'll let that build/publish and remove the jenkins job, so it should promote later today
 * pitti bbl
<jamespage> pitti, thanks
<robotfuel> Mirv: ping
<barry> doko, xnox python-apt rebuild for 3.4 is stuck in proposed due to autopkgtest failures.  looks shallow (missing test dependency probably) and i can fix it if you guys aren't already working on it.  don't want to step on your toes here: https://jenkins.qa.ubuntu.com/view/Releases/view/Trusty/job/trusty-adt-python-apt/30/ARCH=amd64,label=adt/console
<pitti> /tmp/adt-run.dSXkJy/dsc0-build/python-apt-0.9.1build2/debian/tests/run-tests: 7: /tmp/adt-run.dSXkJy/dsc0-build/python-apt-0.9.1build2/debian/tests/run-tests: python3.4: not found
<xnox> barry: i thought i fixed that...
<pitti> needs to test-dep on python-all?
<barry> and python3-all
<xnox> pitti: oh python3-all, yeah that is probably indeed the piece that i missed.
<pitti> if it runs its tests against all python versions, instead of just the default one, that si
<pitti> s/si/is/
<barry> xnox, pitti yep.  i'll fix
 * barry will test it locally first :)
<pitti> FTR, I'm looking at apport's failures
 * xnox only did the local test, in an unclean environment.....
<xnox> pitti: oh, yeah. thanks a lot.
<barry> pitti: dholbach's build failure pointed me here
<pitti> the 3.4 change causes a lot of python* packages to break (which is reflected in their autopkgtest failures)
 * ogra_ hands xnox a mop and a bottle of mr.clean
<pitti> so we have some work cut out :)
<xnox> ogra_: if only scrubbing dishes, would solve all autopackage test failures..... =)
<ogra_> :)
<pitti> ah, that might explain the FileNotFoundError: [Errno 2] No such file or directory: 'crash-digger'
<pitti> i. e. it probably wants to tell me "python 3.4 not found" or so
<barry> pitti: sometimes these are caused by failing imports in tests, ultimately caused because a library wasn't built for 3.4 and thus can't be imported.  this was dholbach's problem
<pitti> hm, is that only me? I suddenly get Debian bug email like 10 times, a new copy every few hours
<cjwatson> somebody decided to bounce old stuff
<cjwatson> look for mcafee.int in the headers?
<cjwatson> I assume it's some crazy misconfigured gateway
<pitti> To: 725951@mcafee.int, [...]
<pitti> ah
<pitti> I got a lot from systemd bug reports, as well as from entirely unrelated stuff like debian bug 711831
<ubottu> Debian bug 711831 in wnpp "RFA: libgphoto2 -- gphoto2 digital camera library" [Normal,Open] http://bugs.debian.org/711831
<pitti> cjwatson: thanks
<pitti> barry: ah, I know; I iterate over for python in $(shell py3versions -r); for building/installing
<pitti> barry: so 3.4 gets last, which changes the hashbangs into the non-default version
<pitti> (just in case this hits some other packages, too)
<xnox> tedg: re:app-launching i'm monkey patching autopilot to bump timeouts from 10s to 30s, because underclocked CPUs make emulator's llvmpipe/GL run really slow =) as, e.g. the case of the openstack cloud instances ;-)
<pitti> barry: the hashbangs shouldn't be /usr/bin/python3.4, but just /usr/bin/python3, right?
<barry> pitti: this is essentially what pyapt runs: (/usr/bin/pyversions "$@"; /usr/bin/py3versions "$@"; ) | tr '\n' ' '
<barry> pitti: right.  but then pyapt runs this: +for python in $(utils/pyversions -r); do
<barry>      $python tests/test_all.py -q
<barry>  done
<barry>  
<pitti> barry: that's the autopkgtest?
<barry> so it does run tests/test_all.py over all supported pythons (explicitly, ignoring shebangs)
<barry> pitti: essentially yep
<pitti> barry: ack, then test-depending on python3-all sounds like it'd do the trick
<pitti> (and would be correct)
<barry> pitti: yep.  but i'm also going to add an explicit python-all for py2
<tedg> xnox, Oh, wow.  The cloud, the future is slow.  :-)
<barry> pitti, xnox, doko and i'm going to label this 0.9.1ubuntu1 and send a patch to debian
<dholbach> barry, that's for python-apt?
<barry> that is, if my autopkgtest vm ever starts :/
<xnox> tedg: =)))) well, emulator is single-threaded/sigle-core, and without a GPU it does depend  on a single core clock-speed... one can have 30x core cloud instance but that won't help =)))))
<barry> dholbach: yep
<dholbach> mvo, barry has a patch for python-apt for you ^ :)
<pitti> barry: hm, my setup.py already sets hashbangs like "python3" -- could it be that dh_python3 is overzealous and changes them to python3.4?
<xnox> tedg: yeah future does seem to be slow, slow cloud IO, slow cpu-core clock-speed...
<barry> mvo!  http://paste.ubuntu.com/6709877/  (not yet tested)
<xnox> tedg: 3 minutes for first boot to run click hooks.....
<pitti> for python in $(utils/pyversions -r); do
<pitti> xnox, mvo: ^ why utils/? shouldn't this use the official pyversions and py3versions?
<barry> pitti: it could be.  there are still some outstanding issues with py3.4 and the build tools, but i haven't had time since break to fully catch up on them
<pitti> i. e. for python in `pyversions -s` `py3versions -s`; ?
<xnox> pitti: i'm not involved in that =)
<barry> pitti: here's utils/pyversions: http://paste.ubuntu.com/6709884/
<barry> so, yeah, i'm not sure why the maintainers are doing it that way ;)
<pitti> barry: ah, heh; the tr seems unnecessary, but it does use the official py[3]versions then, thanks
<barry> pitti, xnox, dholbach hmm, my local run-adt-test seems quite unhappy today (it just hangs).  if the pastebin i provided above looks good to you, i can just go ahead and upload it.  can't be any worse than the current situation ;)
<pitti> barry: hang on, that's due to a removed feature in qemu
<pitti> barry: please apply http://paste.ubuntu.com/6709951/ to your bin/run-adt-test
<pitti> barry: (i. e. comment out the "Making pristine VM available" stanza)
<pitti> barry: I need to find out how to replace that functionality with device_add; hallyn gave me some hints, but I didn't get to test them yet
<barry> pitti: cool, will do.  will you be applying that to the trunk branch soon?
 * barry nods
<pitti> barry: well, I hope I can actually fix it
<barry> pitti: ;)  cool, thanks!  testing...
<pitti> barry: unfortunately qemu removed pci_add without any documented replacement :(
<barry> lovely
<pitti> sorry for the trouble
<barry> pitti: happy again!  thanks
<pitti> jamespage: ok, waitress is in
<jamespage> pitti, excellent - thanks
<mvo> barry: ohh, thanks! if it works I can upload in a bit - you mentioned you are testing it?
<xnox> pitti: there is documented replacement on the mailing list, i think it had the patch to remove pci_add as well.
<barry> mvo: hi!  yep, works locally, just uploaded to ubuntu.  see debian bug 734500 -- i can syncpackage it if you upload the fix to debian (but might want to wait to see if it clears jenkins first)
<ubottu> Debian bug 734500 in python-apt "python-apt: DEP-8 debian/tests/control dependencies missing" [Normal,Open] http://bugs.debian.org/734500
<xnox> hallyn: what was the "proper" way of doing pci_add ? device_add ? pitti  is asking about it.
<mvo> barry: sounds good, thanks! I will merge, there is more good stuff happening in python-apt currently test-wise, so +1 for this one
<pitti> xnox: hallyn responded some 2.5 hours ago here
<xnox> pitti: oh, i see.
<mvo> barry: merged
<mvo> ta
<barry> mvo: thanks!
<mvo> barry: well, thank *you* :)
<pitti> Jenkins Fixed - trusty-adt-python-apt 31
<pitti> barry, xnox, mvo: ^ joy!
<pitti> I just uploaded a fixed apport, too
<pitti> jibel: ah, the recent python-apt upload is another example of disappearing tests in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, in case it's useful
<pitti> only the two FAILed ones remained, but it's actually triggering some 10
<pitti> it's doing that again right now
<mapreri> Hi. licenseutils fail to build in the ubuntu buildd (and PPAs), but build simple fine in pbuilder, sbuild or a local system. Even in debian (the package is synced) build fine.
<mapreri> https://launchpad.net/ubuntu/+source/licenseutils/0.0.7-2      https://buildd.debian.org/status/package.php?p=licenseutils
<mapreri> Have some of you an idea of what happened in these ftbfs??
<mapreri> s/an/any/
<cjwatson> mapreri: Perhaps it would be a good idea to arrange to cat the test-suite.log files on failure?
<xnox> mapreri: cjwatson: If the variable âVERBOSEâ is set, test-suite.log file is output after the summary upon failure.
 * xnox guesses I should propose that change to debhelper.
<mapreri> cjwatson: good idea, I'll try it. I had not thought this.... perhaps also catting the diff could be helpful. Thanks
<cjwatson> mapreri: My first guess was that you were tripping over not having a valid $HOME, but your package seems to handle that.  It's probably quickest to just set VERBOSE=1, reupload, and see what the next build gives you
<mapreri> cjwatson: I'll try too, I'm going to upload to a ppa, since it file also there
<cjwatson> Lack of external networking is another standard reason but that presumably doesn't apply here
<mapreri> yes, the $HOME is set by the script
<mapreri> there is no network activity while building that package
<cjwatson> And it doesn't look as though it'd care much about not having a UTF-8 locale
<cjwatson> So you presumably have an interesting problem :-)
<mapreri> cjwatson: this package already rose a lot of problem, look at http://bugs.debian.org/733314 (https://buildd.debian.org/status/logs.php?pkg=licenseutils&ver=0.0.7-1&suite=sid) for the worst, for example... :)
<ubottu> Debian bug 733314 in licenseutils "licenseutils: Please fix symbols file for powerpcspe (and other arches)" [Wishlist,Fixed]
<cjwatson> Symbols files have nothing to do with this problem though
<mapreri> cjwatson: yes, they are totally unrelated, but this is a reply "So you presumably have an interesting problem", since this package already gave me interesting issues
<dobey> mapreri: the failing test suite isn't obvious enough?
<cjwatson> Hm.  umockdev fails on ppc64el in a way that looks rather like its scary ioctl wrapping kludge is corrupting the stack
<mapreri> dobey: I (and others already tried to) can't understand why that test fail, only in ubuntu buildd, that's the issue
<dobey> well, i don't know that code, but my guess would be network or something common, as already suggested. you'll have to debug
<cjwatson> pitti: You probably want to pull umockdev 0.4.7-1ubuntu2.  Let me know if you need it forwarded more formally.
<cjwatson> pitti: It's possible that the preloaded wrapper ideally ought to be declared with varargs as well, though as you note in the comment you can't make it work with full generality
<cjwatson> But you could at least pull one arg with va_arg
<doko> directhex, Laney: what's the merge status of mono?
<directhex> i'd... like a newer upstream release when 14.04 ships. but i think the current debian experimental package is worth having over what's currently in the archive
<directhex> i've been bugging upstream for about 2 months for a newer stable release
<directhex> i'm reasonably sure the merge can be replaced with a sync. Laney?
<xnox> directhex: if it builds in trusty, it should fine. I'd recommend you to create a ppa, sync from experimental into ppa & copy all reverse-dependencies to check how bad the fallout is.
<xnox> directhex: is it compatiblish or an ABI/API transition?
<directhex> that's not a bad idea
<directhex> xnox, there's a technical ABI transition (shouldn't really matter, apps are executed against the new ABI even if the dependencies imply it was built against the old one - just a minor space concern which is irrelevant now we're not on the CD)
<directhex> oh, the default GC has changed in this release. a few apps might break, but we should have time to catch & patch (or worst case, make the app force the old GC)
<directhex> xnox, this release adds armhf by the way
<xnox> directhex: i don't want a pile of packages be stuck in -proposed, or indroduce a gazzilion FTBFS. =) do you want me to quickly run rebuild tests against mono from experimental?
<xnox> directhex: which packages do i need to take?
<directhex> oh, there's the dbus#2 stuff too to worry about. grr. do we have an easy way to track this stuff?
<directhex> xnox, basically there'd be value in testing all packages which the mono maintainers have delegated upload rights for against mono in debian experimental, which i just sent to a PPA
<directhex> there'd also be value in me remembering which url is a handy reference for "version in debian" against "version in ubuntu"
<xnox> directhex: so the way i do things is compare versions with: rmadison -u ubuntu -S package; vs rmadison -u debian -S package
<xnox> directhex: (source package names gives results for all arches & binary packages)
<xnox> directhex: and in ubuntu-archive-tools there is script copy-package which let's me copy source packages (without binaries) from any distributions/suits into my ppa. So i typically copy or upload "base things", e.g. mono in this case.
<xnox> directhex: wait for it build & publish, then mass copy-package of all $ reverse-depend --list -b src:mono
<directhex> huh, never heard of copy-package. sounds sorta pointless vs. syncpackage
<directhex> xnox, can you manipulate build score?
<xnox> directhex: (baring PPA size limits / number of packages, so at times not _all_ but a useful set of packages)
<xnox> directhex: and then watch how much of it builds in a PPA.
<xnox> directhex: copy-package and syncpackage are two different things =)))))
<xnox> directhex: syncpackage is for: debian -> ubuntu-archive.
<xnox> directhex: copy-package can be: ppa -> ubuntu, ubuntu -> ppa, debian -> ppa, or whatever you want, just source (to trigger rebuilds) or with binaries (to simply republish, e.g. to different series)
<directhex> yeah, i just mean syncpackage could be "exec copy-package --foo --bar" by the sound of it. never mind, getting off topic
<directhex> when my ppa build of mono finishes (hopefully before i go to bed) i can throw a bunch of packages at it
<xnox> directhex: well, syncpackage uses the same api on the back of things, copy-package just exposes more of the raw api. syncpackage has convenient wrappers to close bugs, force-override ubuntu delta, sponsor-for somebody else, sanity-checking, etc.
<directhex> although i've been waiting about a month for a build on debian armhf/experimental...
<directhex> which is insanity. a month! how am i supposed to get a reasonable iteration on fixes going if builds take a month?
<xnox> directhex: i can build some things on fast arm box, but not like all of mono reverse depends.
<directhex> xnox, i'm told the mono experimental package is Fine(tm), it's been pushed out on raspbian to replace earlier monos in all versions
<directhex> but mono's been broken in armhf for years. long story.
<Laney> directhex: I don't really remember what the ubuntu changes are
<Laney> oh that armv6 thing - I guess that's already fixed upstream
<directhex> yeah, the arm fixes katamari which fixed armhf
<directhex> hmph, ben ignoring --archs flag
<smaresca> ddebs.ubuntu.com  - is there a recommended/supported means of mirroring the repository --- rsync or apt-mirror or similar?
<xnox> smaresca: i use apt-cacher-ng to ondemand mirror things for me...
<mdeslaur> +1 apt-cacher-ng
<smaresca> xnox, i do too typically for normal things like local PXE installes, etc
<smaresca> here, I have a bit of an unusual case: I have some research requiring debug symbols, and I'd like to crunch *all* available packages not just lazy-caching them as needed
<xnox> smaresca: well, apt-cacher-ng has options to mirror things ahead of time, one just needs to configure which repositories / suits / arches / etc.
<directhex> gah, builds pushed back by an hour
<directhex> unlikely to get anything done today, in that case
<xnox> directhex: lp estimates are a bit dubious. leave it over night.
<xnox> directhex: (41 builders are actually across both i386/amd64 of all jobs together these days, and some of the jobs are recipes that generate new build-records)
<directhex> xnox, i was hoping src:mono would build before bed so i could push a bunch of packages to build up there ovbernight
<stgraber> directhex: link to the build?
<directhex> um... https://launchpad.net/~directhex/+archive/mono-rebuild/+build/5421967 and https://launchpad.net/~directhex/+archive/mono-rebuild/+build/5421968
<directhex> i guess i386 is the important one, since it's always the preferred arch for arch:all packages
<stgraber> looks like they're building
<directhex> ... huh. i swear it just said 1 hour!
<RAOF> A non-ancient Mono in Trusty? Yay!
<RAOF> directhex: FWIW, I've been running a locally-built copy of mono from experimental in Trusty for some time; nothing I use has broken.
<directhex>  *** 3.0.6+dfsg-1~exp1~pre1 0
<directhex>         100 /var/lib/dpkg/status
<directhex> :D
<doko> directhex, worth a testbuild on the other archs too?
<RAOF> 3.0.6? Not 3.2.7?
<directhex> 3.2.7 is another PCL-only update
<directhex> doko, i don't think it'd tell me anything new. i mean, an armhf build would be great, but i'm reasonably sure that works, given the raspberry pi case
<directhex> unless you have decent mipsel builders :p
<Snow-Man> so, uhm, what's the deal w/ CVE-2013-4353 â¦ ?
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4353)
<Snow-Man> it's published, you dingle-bat bot
<Snow-Man> or rather, there's a fixed for it release by Debian, heh.
<jdstrand> Snow-Man: it's being tracked. we should have an update soon
<Snow-Man> k, thanks.
<knocte> directhex: I guess you meant 3.2.6, as 3.2.7 hasn't been tagged yet
<directhex> there's a 3.2.7 in xamarin's QA pipeline. it might be a mac-only installer update, which wouldn't get a corresponding git tag
<directhex> either way, urgh]
<mterry_> pitti, do you know much about getting debug output from systemd?  I'm trying to look into why the phone's logind doesn't apply acl's to sound devices when a user logs in
<directhex> ok i've managed to get ben working, and got a few rebuilds going
<directhex> if these are fine, i'm inclined to just throw it at the archive. will see tomorrow
#ubuntu-devel 2014-01-08
<Snow-Man> jdstrand: I don't suppose you have any idea when it'll drop...?
<sarnold> Snow-Man: I'd suspect early next week at the soonest; openssl updates have had unwanted regressions in the past, we might do some wider testing of it before pushing.
<Snow-Man> oh.
<Snow-Man> hrmpf.
<sarnold> imho, it's not likely the kind of update you want to push towards the end of a week unless there's active exploitation. admins need a fighting chance of not working on weekends. :)
<Snow-Man> heh..
 * Snow-Man already upgraded all of the PG infrastructure
<Snow-Man> The DSA looked like an exploit would probably not be far off...
<doko> bdrung, do you want to join the pythoneers team?
<jtaylor> whats wrong here: checking whether the gcc -std=gnu99 linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no
<jtaylor> package uses autotools_dev
<jtaylor> so config.* should be fine?
<mwhudson> apologies if this is a stupid question, but should a debdiff show changes in the rules file?
<rbasak> mwhudson: yes, it should.
<mwhudson> hmm
<mwhudson> rbasak: what on earth are you doing online btw? :)
<mwhudson> oh feck i just ran scons -c in the wrong directory :/
<rbasak> What, you mean that I shouldn't be online at 1am?
<mwhudson> yes
<mwhudson> that
<rbasak> Better go then :)
<rbasak> o/
<mwhudson> g'night
<GunnarHj> robert_ancell: Hi Robert!
<robert_ancell> GunnarHj, hi
<GunnarHj> robert_ancell: http://people.ubuntu.com/~gunnarhj/shell-guest-session.html#disable is about to make it to Ubuntu Help. Yesterday you mentioned your plan to break out guest session to a separate binary package. I just wanted to point out that doing so would not make much of a difference with respect to how easy/difficult it is to disable guest session. But maybe you have other reasons.
<cjwatson> jtaylor: that's out-of-date libtool.m4 (or libtool macros embedded in aclocal.m4 or similar) - needs dh_autoreconf rather than dh_autotools-dev_*
<cjwatson> jtaylor: cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726404
<ubottu> Debian bug 726404 in libtool "libtool: Backport a new architecture (ppc64le) to Debian" [Wishlist,Fixed]
<GunnarHj> robert_ancell: You disappeared...
<robert_ancell> ?
<GunnarHj> robert_ancell: Posting again:
<GunnarHj> http://people.ubuntu.com/~gunnarhj/shell-guest-session.html#disable is about to make it to Ubuntu Help. Yesterday you mentioned your plan to break out guest session to a separate binary package. I just wanted to point out that doing so would not make much of a difference with respect to how easy/difficult it is to disable guest session. But maybe you have other reasons.
<robert_ancell> GunnarHj, looks good
<GunnarHj> robert_ancell: Tnx.
<GunnarHj> robert_ancell: Are there other reasons for breaking out e.g. unity-guest-session.deb?
<robert_ancell> GunnarHj, you might only want to have a unity guest session, and not a GNOME/KDE one. Each session might require different apparmor rules
<GunnarHj> robert_ancell: Ok, I see. Just wanted to point it out, since you mentioned it in the context of how to disable the feature.
<robert_ancell> RAOF, can I get you to move unity-control-center out of the new queue?
<RAOF> robert_ancell: I've got the LP permissions required to do that, but I'm not an archive admin. Is it in the NEW queue because it's a new package, needing AA attention?
<infinity> Sure looks like it.
<robert_ancell> RAOF, yeah it's a new package. Are you not an AA anymore?
<infinity> robert_ancell: Which version of g-c-c is this forked from, so I can do a lazy review?
<robert_ancell> infinity, 3.6
<RAOF> robert_ancell: I've never been an AA; I got the launchpad permissions so that SRUs weren't hugely annoying.
<robert_ancell> it's basically 3.6.3-0ubuntu49 with all the patches applied
<robert_ancell> RAOF, oh, you're a fake ~ubuntu-archive member :)
<infinity> ... with all the patches applied?  You mean you've changed the source format, so I can't diff it? :P
<RAOF> robert_ancell: Correct. My membership of ~ubuntu-archive just a technical workaround :)
<robert_ancell> I also branched from the 3.6 upstream branch, so it has a few small bug fixes
<robert_ancell> and then a bunch-o-renaming
<infinity> RAOF: You shoudn't need to be in ~ubuntu-archive to do SRUs.
<RAOF> infinity: I do if I want to accept SRUs from the NEW queue, right?
<RAOF> (These exist, particularly in X land)
<infinity> RAOF: Oh, possibly, yes.  Silly LTS backports.
<infinity> robert_ancell: Well, congrats on making this much harder to audit. :P
<robert_ancell> infinity, yeah, it wont be trivial :)
<infinity> (It could have been trivial if you'd just taken the g-c-c package and done the renames and pulled the upstream fixes you wanted...)
<robert_ancell> infinity, then it would have been harder to merge from upstream though right?
<infinity> Dunno.  That depends on how you work, I guess.  The desktop team clearly wasn't having issues with the package as it was.
<infinity> Anyhow, you also ditched the entire changelog, which is a bit silly.
<robert_ancell> Does it matter?
<infinity> I suppose someone might have wanted to know the history of all the patches that you pre-applied...
<robert_ancell> I added the info from the changelog to the commit messages
<infinity> robert_ancell: I guess there are Reasons(tm) why we can't use g-c-c 3.8/3.10/whatever?
<robert_ancell> infinity, yes, the newer versions have quite major changes that would take a lot of work for us to integrate and may not contain things we want. Since we're working on a Unity 8 replacement it's best to just hold with what we have and unblock the Ubuntu GNOME people to use the newer versions
<infinity> robert_ancell: Fair enough.  Accepted it.
<robert_ancell> thanks!
<Mirv> robotfuel: pong
<pitti> Good morning
<pitti> cjwatson: ah, many thanks for the varargs umockdev fix! nice that everything else works
<pitti> cjwatson: I'll fix it upstream and in Debian, too
<pitti> dobey: hm, last night the ubuntuone autopkgtest stack started failing, all on this weird "Failed to parse argument: ['order', 'o', None, 'Specify..." error; does that ring a bell?
<RAOF> Huh. Why does libc6-armhf-cross install all its files in /usr/arm-linux-gnueabihf/lib/*.so, rather than /usr/lib/arm-linux-gnueabihf/*.so?
<mlankhorst> RAOF: I'm guessing because you should install libc6:armhf if you want the latter
<RAOF> mlankhorst: I guess
<doko_> the guess is correct
<RAOF> Um... this is a new and shiny one on me: â/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/arm-linux-gnueabihf/libpthread.so.0 insideâ
<RAOF> Oh, that's moderately terrible.
<dholbach> good morning
<mlankhorst> RAOF: should use the multiarch -dev packages I think :P
<RAOF> mlankhorst: No; in this case what I need to not do is correctly specify the library link paths.
<mlankhorst> ah
<mlankhorst> bad raof :P
<doko> RAOF, what are you trying to do?
<RAOF> Because if I correctly specify the library link paths, then it picks up a broken ld script.
<RAOF> doko: Link against libudev for the Mir android cross-compile.
<doko> and libc:armhf is installed?
<doko> libc6-dev:armhf
<PublicStaticVoid> Devided to test 14.04 since 13.10 was giving me so many issues
<PublicStaticVoid> Because of newer hardware
<RAOF> doko: What's happening is that we unpack a bunch of debs into a kinda-sorta-but-not-really armhf chroot; if the build correctly specifies the linker paths, then the unpacked libc.so linker script gets used, which embeds an incorrect path.
<RAOF> doko: This could be sorted much more simply by using an *actual* chroot.
<mlankhorst> or no chroot, and using the multiarch dev packages..
<PublicStaticVoid> 13.10 didnt have cideo or udio working out of the box for me but so fat 14.04 has been perfect
<RAOF> doko: Also, installing libc6-dev:armhf seems to want to remove such minor packages as g++, gcc, and multiarch-support
<mlankhorst> who needs that, anyway
<RAOF> mlankhorst: That would also work, but I'm pretty sure that at least some of our dependencies don't have multiarched dev packages.
<RAOF> Anyway, it's dinner time here, and I've found what's wrong.
<doko> RAOF, the installation works fine here
<doko> is -proposed enabled?
<PublicStaticVoid> Guys are really working hard on tablet support huh?
<infinity> RAOF: If installing libc6-dev:armhf wants to remove multiarch-support:amd64, you have version skew between armhf and amd64.
<infinity> RAOF: Or you're not actually using multiarch correctly...
<PublicStaticVoid> Tell me what will be a good Tablet to purchase for Ubuntu early?
<PublicStaticVoid> You guys testing on anything specific?
<infinity> PublicStaticVoid: You probably want #ubuntu-touch
<mlankhorst> doko: it recommends installing gcc:armhf
<infinity> mlankhorst: apt-get --no-install-recommends?
<mlankhorst> linux-libc-dev:armhf fails
<doko> mlankhorst, you should disable installation of recommends for this kind of thing
<mlankhorst> Replaces: dvb-dev (<< 1.0.1-6), libc6-dev (<< 2.3.2.ds1-6), libc6.1-dev (<< 2.3.2.ds1-6), libdrm-dev, linux-kernel-headers
<mlankhorst> Provides: linux-kernel-headers
<mlankhorst> Conflicts: amd64-libs-dev (<= 1.1), dvb-dev (<< 1.0.1-6), libc6-dev (<< 2.3.2.ds1-6), libc6.1-dev (<< 2.3.2.ds1-6), linux-kernel-headers
<doko> mlankhorst, please start with a fresh chroot
<PublicStaticVoid> infinity: I thought 14.04 was geared twrds x86/amd64 and armhf?
<mlankhorst> doko: it attempts to uninstall a whole bunch of -dev packages anyway if I force linux-libc-dev:armhf
<infinity> mlankhorst: It's multi-arch:same, the provides/conflicts don't matter, you can have both installed.
<infinity> mlankhorst: Just like any library.
<doko> mlankhorst, that's expected
<infinity> (Again, unless you have version skew)
<mlankhorst> hm *tries in a pbuilder chroot*
<PublicStaticVoid> Touch isnt even close to desktp implmentations..
<infinity> PublicStaticVoid: 6 architectures, even, but you were asking about tablets, hence you want #-touch.
<pitti> doko: wrt. https://launchpad.net/ubuntu/+source/libtool/2.4.2-1.6ubuntu1, this breaks package builds which b-dep on libtool
<mlankhorst> fine I'll try in a pbuilder..
<pitti> doko: I think libtool needs to Depends: on libtool-bin, not just recommends
<PublicStaticVoid> armhf is a tablet/phone arch lol but okay
<PublicStaticVoid> I know where touch i at
<PublicStaticVoid> is
<infinity> pitti: The whole point was that most packages that build-dep on libtool do so for the aclocal bits, not the libtool binary.
<doko> pitti, expected
<PublicStaticVoid> Not what I am interested in
<doko> pitti, if you see some, please tell me
<pitti> infinity: eh? "libtool" is not libtool any more?
<pitti> doko: I just ran into glom's
<doko> pitti, libtoolize is used
<infinity> pitti: Personally, I think the package split is pointless, and there's no reason for people to expect libtool to be cross-happy, but whatever.
<mlankhorst> The following packages will be REMOVED:
<mlankhorst>   build-essential g++ g++-4.8 libc6-dev libstdc++-4.8-dev linux-libc-dev
<mlankhorst> The following NEW packages will be installed:
<mlankhorst>   gcc-4.8-base:armhf libc6:armhf libc6-dev:armhf libgcc1:armhf linux-libc-dev:armhf
<mlankhorst> in a fresh pbuilder chroot :p
<pitti> doko, infinity: so can we fix libtool properly, or hunt down the FTBFS? for the latter, should they now b-dep on libtool-bin?
<pitti> I'd really want to avoid that as that's not in Debian
<infinity> I think the proper fix is just marking it M-A:allowed and undoing the split.
<PublicStaticVoid> You guys are developing 14.04 right?
<pitti> nor is a libtool-bin b-dep backportable
<mlankhorst> doko: so should linux-libc-dev:armhf be coinstallable between amd64 and armhf?
<mlankhorst> hm seems to not remove linux-libc-dev:amd64 at least
<mlankhorst> weird
<doko> pitti, was talking with Q_ about that, I'll look at glom what it is trying to do
<doko> mlankhorst, yes
<infinity> mlankhorst: They're all coinstallable for me just fine.
<pitti> config.status: executing po/stamp-it commands
<pitti> if [ -e ./libtool ]; then cp -f /usr/bin/libtool ./libtool; fi
<pitti> cp: cannot stat '/usr/bin/libtool': No such file or directory
<infinity> mlankhorst: http://paste.ubuntu.com/6713641/
<mlankhorst> infinity: I did pbuilder-dist trusty update; pbuilder-dist trusty login; http://paste.debian.net/74936/
<PublicStaticVoid> Just really wanted to tell you guys when I installed 14.04 the partitioner did not see anything but free space.. read the partition table incorrectly...
<mlankhorst> dpkg --add-architecture armhf; apt-get update; apt-get install libc6-dev:armhf :s
<doko> pitti, looking at it
<infinity> mlankhorst: Ahh, you hadn't added the arch?
<infinity> doko: I still think we should just back this out.  No one's convinced me of the sanity of the split.
<mlankhorst> infinity: that is the corect way to add the arch right?
<mlankhorst> and my sources.list is correct too?
<pitti> doko: I can't actually find that code ([ -e ./libtool ] etc.) in glom's source package, I suppose that's run from some intermediate program; investigating
<doko> infinity, well, it is doing the wrong things for cross builds. not that I would care about glom
<infinity> doko: People having bugs in cross-builds isn't a reason to do this.
<infinity> doko: Packages with CC=gcc also cross incorrectly.  That's a packaging bug, not a toolchain bug.
<mlankhorst> odd, wonder how the version got skewed
<mlankhorst> nm I have -proposed in trusty
<pitti> doko: ah, it's from /usr/share/cdbs/1/class/autotools.mk
<mlankhorst> false alarm
<infinity> doko: It would DTRT if you made it Multi-Arch:allowed instead of foreign.
<infinity> doko: See the table at https://wiki.ubuntu.com/MultiarchCross
<pitti> glom does "DEB_AUTO_UPDATE_LIBTOOL := post"
<mlankhorst> RAOF: downgrade linux-libc-dev to 3.12.0-7.15 :P
<pitti> doko: (no idea whether that makes sense, but it's the way it is in the package ATM)
<infinity> doko: That would get you exactly the behaviour you're after.  Default to libtool:HOST_ARCH for regular build-deps, and get you libtool:BUILD_ARCH if you demand :native
<infinity> mlankhorst: Erm, if you have proposed for both arches, it shouldn't be skewed.
<mlankhorst> infinity: yeah but i disabled proposed for testing :s
<mlankhorst> ok i guess it works just fine
<mlankhorst> as long as i don't try to coinstall gstreamer0.10-plugins
<infinity> doko: Sent a followup to the Debian bug on the matter.  Will you be annoyed if I undo the split and switch the M-A header in Ubuntu?
<infinity> I see zero point in creating fallout from this, or in adding new build-deps that we didn't have before.
<doko> infinity, well, then please upload first a version to ubuntu-toolchain-r/test which supersedes your reversion
<infinity> doko: Err, what?
<infinity> doko: Why?  Why would you care what fails to build without /usr/bin/libtool if we're not removing it?  That'll just create a bunch of false positives that people will go "fixing" when they shouldn't.
<seb128> hum
<zyga> hey
<seb128> virtualbox stopped working for me in trusty (was working before holidays)
 * zyga wonders how to understand adt failures by looking at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-plainbox/
<seb128> "
<seb128> The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. "
<seb128> is that a known issue?
<pitti> zyga: what in particular?
<pitti> zyga: it seems the test doesn't output anything useful on failure, that ought to be fixed
<pitti> zyga: i. e. printing an useful error message
<zyga> pitti: the way DEP8 tests are defined I don't know how to provide any useful log file where I see what failed
<pitti> zyga: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-plainbox/7/ARCH=i386,label=adt/console is the full output
<zyga> pitti: how can I do that if all output must be RFC822?
<pitti> zyga: not sure what you mean with RFC822, but it doesn't matter to autopkgtest
<pitti> zyga: success == exit code 0 and no stderr (unless you define "Restrictions: allow-stderr")
<zyga> pitti: ohhh/
<seb128> apw, hey, any idea about my virtualbox issue? (I see you update it on monday)
<zyga> pitti: I need to re-read dep8 testing spec, I read a guide that claimed otherwise
<zyga> pitti: this is how my tests look like now http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/tests/unit-tests?view=markup
<pitti> zyga: ah, I guess you really want to drop the >/dev/null at least
<pitti> zyga: if your test is *expected* to have stderr output, the "allow-stderr" is usually cleaner/easier, but 2>&1 works as well
<zyga> pitti: so basically, can I drop the /dev/nul redirects and redirect stderr to stdout (logs sometimes go to stderr), as long as the exit code is okay, everything will work?
<zyga> pitti: allow-stderr should go into control?
<zyga> http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/tests/control?view=markup
<zyga> pitti: like 'allow-stderr: yes'
<pitti> zyga: no, "Restrictions: allow-stderr"
<zyga> ah, ok
<zyga> pitti: and that applies to all tests?
<pitti> zyga: only to the tests in that particular Tests: stanza
<pitti> zyga: btw, "Depends: @" is the default, so if you don't need any additional deps you can just drop the Depends: line (just FYI, it's fine if you keep it)
<pitti> zyga:  @ expands to "all binaries from my source package"
<zyga> pitti: yeah but I cannot use @
<zyga> http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/tests/control?r1=26961&view=log
<zyga> pitti: some packages conflict with each other
<pitti> zyga: ah, I see
<pitti> zyga: nevermind then
<apw> seb128, hmmm no, the change i made was a simple V > 3.13 ignore this line of code jobbie, for the 3.13 kernel dropping in now
<apw> i can't say i have ever tested it with 3.12 at all
<seb128> apw, do you have any idea how to debug that?
<apw> is that with 3.12?  if so i would try 3.13 first
<apw> as it did load there for me i think
<zyga> pitti: is there a way to subscribe to adt failures
<zyga> pitti: or file bugs on an upstream project / packaging?
<pitti> zyga: adt failures are mailed to the last uploader
<zyga> pitti: I haven't see any emails, that package is synced from debian where it was uploaded by my sponsor
<zyga> pitti: does that qualify?
<seb128> apw, 3.11.0-13 is what I'm running it seems, seems like I cleaned out "linux" when remove the few Gbs of old kernels I had around ...getting a newer kernel now, let's see
<seb128> though it's 3.12 ... is 3.13 supposed to be in trusty?
<infinity> seb128: 3.13 *just* got published to trusty-release, should hit mirrors in about 2 minutes.
<seb128> infinity, thanks
<xnox> jtaylor: "supports shared libraries... no" means you want dh-autoreconf (manual, it's dh addon, or cdbs snippet) to perform full autoreconf, with a goal to have "libtoolize" executed to uploade libtool with ppc64el support.
<xnox> jtaylor: oh, colin replied to you =)
<zyga> pitti: auto-package-testing seems to use x86_64 even if you ask it to build i368 vm
<zyga> pitti: is there a way to fix that easily? I'm on i386 machine
<pitti> zyga: hm, it should default to the host arch, it doesn't?
<pitti> jodh: did you see that test_conf_preload.sh
<pitti> jodh: ... started failing in upstart's autopkgtest?
<jodh> pitti: hmm - that code hasn't changed for a long time and the problem is not recreatable locally. Has the jenkins env changed somehow recently do you know?
<pitti> jodh: the host might have gotten upgraded to saucy
 * pitti tries locally
<zyga> I've patched adt-prepare-testbed to support i386
<pitti> zyga: what did you change?
<pitti> jodh: I get exactly the same failure locally (trusty host, trusty VM, amd64)
<diwic> seb128, hi!
<seb128> diwic, hey, happy new year!
<zyga> pitti: http://paste.ubuntu.com/6714054/
<zyga> pitti: not sure if that's fully working yet, i386 boxes are slooow
<diwic> seb128, same to you! Do you have time for a chat about the what-did-you-plug-in dialog?
<pitti> zyga: you probably still need the -enable-kvm for i386, too
<seb128> diwic, yes
<pitti> zyga: otherwise it'll be slow indeed
<pitti> zyga: those were the days when "kvm" just DTRT.. :/
<zyga> hehe :)
<diwic> seb128, so, the progress is that after a few rounds with upstream PulseAudio, I ended up redoing the implementation as a separate program.
<diwic> seb128, my ambition is still to try to upstream it into 14.04 somehow, maybe into gnome-settings-deamon? (Or has that forked into ubuntu-settings-daemon?)
<seb128> diwic, maybe we should discuss that on #ubuntu-desktop (I think larsu was following last time we discussed it)
<zyga> pitti: with a few more changes it seems to be on a course for success, I'll send you patches for adt once I'm done
<pitti> zyga: thanks
<pitti> jodh: I get the same failure in a plain schroot during package build
<pitti> jodh: (sbuild -d trusty -A upstart_1.11-0ubuntu1.dsc)
<jodh> pitti: I'm trying again with a fresh local env.
<pitti> jodh: so, no VM required
<pitti> hallyn: I tried your recipe; if=none succeeds (but doesn't actually give me a drive), but with if=virtio (as in people.canonical.com/~serge/qrt-qemu.diff) I get "Can't hot-add drive to type 7"
<pitti> hallyn: so with if=none I get a lot of dmesg, but no new block device
<pitti> hallyn, jibel: ah, seems I got it:
<pitti> drive_add auto file=/home/martin-scratch/adt/disks/pristine-trusty-amd64-20140108_073545.img,if=none,id=pristinevm
<pitti> device_add virtio-blk-pci,id=pristinevm,drive=pristinevm
<seb128> hum
<seb128> who should be pinged if somebody "vandalize" bugs on launchpad?
<seb128> e.g https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/1238266
<ubottu> Ubuntu bug 1238266 in file-roller (Ubuntu Saucy) ""Error setting owner: Operation not permitted" when extracting Eclipse in saucy" [High,Fix released]
<seb128> see the description
<cjwatson> seb128: revert it and notify https://answers.launchpad.net/launchpad
<cjwatson> (esp if you happen to have the description diff to hand)
<seb128> cjwatson, I've the diff in my launchpad emails yes
<seb128> cjwatson, thanks
<directhex> xnox, Laney, ok. i don't think the archive will be made significantly worse by pushing 3.2.3 into trusty. there might be a few FTBFSes - those can be fixed in debian & synced (mostly due to a re-renamed pcfile)
<jodh> pitti: the env now seems to use overlayfs, leading to => bug 882147. Upstart do have a "pre-test" which checks for overlayfs, but the decision was taken to not error message, we just display a waring... except that that message isn't being output, I think due to recent nih changes.
<ubottu> bug 882147 in coreutils (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,In progress] https://launchpad.net/bugs/882147
<pitti> jodh: how does overlayfs come into play when running "make check" during build?
<xnox> pitti: badly.
<xnox> pitti: ditto eatmydata
<jodh> pitti: the test in question needs to test that upstart can detect file changes using inotify... but inotify doesn't work with overlayfs.
<pitti> I don't use overlayfs with my trusty schroot, it's a tarball
<pitti> nor does run-adt-test
<Laney> directhex: alright then
<pitti> I have overlayfs with my precise/sid schroots (as I use them more often), all others are tarball
<Laney> I think there's an archive rebuild coming up which should catch stuff
<Laney> also we should finish dbus#2 at some point *cough*
<jodh> pitti: auto-package-testing no longer works for me - unable to login to the kvm instance. Can you get any more details from that failing test in your env whilst I try to recreate with a modified schroot then?
<pitti> jodh: does it hang on "making pristine VM available"? I just fixed that, please pull (recent qemu changes)
<xnox> Laney: as long as mono makes it into -release before archive rebuild is kicked off.
<pitti> jodh: but I think it's faster to debug in schroot or plain trusty
<jodh> pitti: yes, love that bleeding edge :)
<directhex> Laney, i also figured out how to make Ben work against Ubuntu, so i can keep an eye on things. it still totally fucks up the dependency ordering for mono stuff, mind you.
<jodh> pitti: plain trusty works fine for me as originally noted :)
<Laney> directhex: we already have ben
<Laney> http://people.canonical.com/~ubuntu-archive/transitions/
<directhex> Laney, i mean locally, not needing coordination with ubuntu-archive
<Laney> I can commit a .ben file if you want
<xnox> Laney: yes please!
<pitti> jodh: trying to build directly on my trusty now
<Laney> what needs tracking here?
<directhex> Laney, depending on corlib 4.5 is a measure of "was it definitely built using the new mono", i.e. it guarantees that the package doesn't ftbfs
<directhex> Laney, strictly that's a transition. it's not a problem if packages aren't rebuilt (they're executed with 4.5 corlib regardless of the dependency)
<Laney> ah, you mean like that - ok
<directhex> i've done a handful of test rebuilds in a ppa
<pitti> jodh: same thing on my plain trusty workstation
<Laney> we should get much the same data from the archive rebuild then
<xnox> jamespage: i only approve scons usage with clotted cream, honey & jam. all other usage of scons, is confusing and should be banned =)
<Laney> feel free to go ahead if your initial tests look good
<pitti> jodh: it doesn't seem to care much about VM, schroot, overlays, etc.; it consistently fails the same way everywhere I run it
<jamespage> xnox, +1
<pitti> jodh: ah, hang on, that was a different failure (due to my non-English locale)
<cjwatson> doko: sqlite build failure - given that you've merged tcl8.5 from experimental, could you please also look into tcltk-defaults/experimental?  Having one but not the other means we don't have tclsh, which is kind of bad
<cjwatson> doko: (sqlite's build-deps may still need to be tweaked, but I'd like to see tcltk-defaults updated first
<cjwatson> )
<doko> cjohnston, ohh, I have  a tclsh ...
<doko> cjwatson even
<cjwatson> doko: tcl8.5 and tcltk-defaults now have different ideas about whether it's supposed to be managed by alternatives or symlinks
<doko> the merge wasn't very appealing :-/
<cjwatson> doko: this seems unlikely to end well - I think they need to be in sync
<doko> yeah, will have to look ...
<cjwatson> directhex: the ben package in trusty is basically what we use
<pitti> jodh: ok, a local build succeeds; so it fails in schroot during package build and in run-adt-test
<cjwatson> directhex: together with lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs
<directhex> cjwatson, yeah, had to train myself on the syntax to run it on my desktop. seems the package in saucy uses sid sources by default
<cjwatson> directhex: yeah, the package in saucy won't be very easy to get to work.  I did the big merge with our previous fork in trusty
<cjwatson> so it now has an Ubuntu template there
<cjwatson> (not a big bag of fun since I don't speak ocaml)
<jodh> pitti: no error in a current trusty schroot sans overlayfs.
<pitti> jodh: hm, I wonder what's different on mine then; are you running trusty or saucy on your workstation?
<pitti> jodh: (perhaps newer kernel or so?)
<jodh> pitti: workstation is trusty. One difference is that I'm running 32-bit.
<xnox> Laney: sudo didn't make a difference.... and adb launches bash as a login shell, so i'd expect it to have proper environment, but it doesn't =(
<jodh> pitti: kernel=3.12.0-7-generic
<Laney> xnox: I don't really know what controls whether pam is run or not :(
<Laney> Maybe you can get away with sourcing the file ...
<pitti> jodh: same here, so maybe i386 vs. amd64?
<pitti> jodh: I built in an i386 schroot, but on amd64 host
<jodh> pitti: hmm - but jenkins shows the failure on 32+64-bit.
<cjwatson> jodh: 32-bit or 64-bit kernel?
<cjwatson> jodh: jenkins might well be running everything on a 64-bit kernel even in the case of 32-bit tests
<zyga> pitti: is there a way to control the timout of prepare-testbed without patching packages installed within the VM?
<xnox> cjwatson: can click-user-hooks be racy? ocassionally emulator first boot get stuck with click-user-hooks not terminating and thus unity8 not starting with the following in the log http://paste.ubuntu.com/6714604/
<cjwatson> xnox: not afaik
<cjwatson> xnox: I'm pretty sure this is the fault of some particular hook, not of the system in general
<xnox> cjwatson: I see. How would I go debugging which hooks are running / failing / getting stuck ? Well I guess i should just follow the exec trails.
<cjwatson> xnox: when I last looked at this there was one hook that really stood out as running for ages, easily visible using ps
<cjwatson> I forget what it was called
<cjwatson> or you could hack click hook to be chatty on stderr
<pitti> cjwatson, jodh: the VMs have the "right" kernel, but qemu runs on an amd64 host
<pitti> jodh: but, I get the failure in an i386 schroot and success on plain amd64 trusty, i. e. the other way round
<pitti> zyga: not that I know of; why is it so slow for you, not using kvm?
<zyga> pitti: i386 on atom
<zyga> pitti: it's also too slow when you are on a particularly slow link
<zyga> pitti: I'd vote for making it a parameter just like apt proxy
<pitti> zyga: oh, atom doesn't do kvm either
<zyga> pitti: I also bet it's too slow on armhf on small boards
<zyga> pitti: IIRC some models do but mine does not
<pitti> yeah, we don't run qemu on arm, way too slow
<zyga> pitti: lxc I presume?
<pitti> zyga: we don't run autopkgtests at all for arm ATM; we had done so for a while (on real iron, with reinstalling every time), but way too brittle
<pitti> zyga: on such hardware (atom/arm) you are probably better off with the schroot or lxc runners rather than using run-adt-test
<zyga> pitti: yeah, I know how hard that is from my LAVA days
<pitti> but schroot/lxc don't provide sufficient virtualization for many tests
<zyga> pitti: really?
<rbasak> KVM on ARM isn't too far away now.
<zyga> pitti: did you run into problems?
<rbasak> It basically already works, AIUI - we just haven't got it fully upstreamed and in distro.
<zyga> pitti: isn't it ready yet? on A15?
<pitti> zyga: for things like upstart, udisks, gvfs, network-manager, etc.
<pitti> zyga: i. e. everything which fiddles with devices or other low-level things
<zyga> pitti: ah, I see
<zyga> pitti: I thought lxc could run upstart tests
<pitti> rbasak: would that work on the G4? or only on the big calxeda boxes?
<rbasak> What's a G4?
<zyga> pitti: on the other hand, I wonder if it's right for stuff like udisks to require full vms to run their testing
<rbasak> It should in theory work on any A15.
<pitti> zyga: perhaps; I'm not sure with upstart
<pitti> rbasak: google nexus 4, sorry
<pitti> (i. e. the phone that we support)
 * zyga thougth about ppc g4
<zyga> pitti: I just got my hands on oldish ppc with g4 and 1GB ddr, I'll slap server on it and see if I can run anything
<pitti> zyga: for most tests they are just fine; I run a lot of them in the schroot runner, which make things really fast
<rbasak> I'm not sure. /proc/cpuinfo might tell you, but I don't recall what the flag is right now.
<zyga> pitti: ohh, schroot runner? where is it?
<zyga> pitti: I only see run.lxc
<pitti> zyga: it's part of autopkgtest
<zyga> pitti: the project or the package?
<pitti> $ adt-run -B python-boto_2.20.1-2.dsc --- adt-virt-schroot sid
<pitti> something like that
<pitti> zyga: in the package
<zyga> pitti: thanks
<pitti> zyga: for CI we use adt-virt-null in a VM (as we don't yet have an adt-virt-qemu, which would arguably be better)
<zyga> pitti: I tried to run tests of a bunch of locally built packages but I kept hitting errors
<pitti> zyga: you can use -null on your workstation for tests that don't damage your system, or -schroot or rbasak's nice -lxc runner
<zyga> pitti: which works not that great if you try to test a fix yourself
<zyga> pitti: is that all packaged or should I keep using source of lp:auto-package-testing?
<pitti> but most often I just use run-adt-test with "-sU", as it's very fast on my system (I have apt-cacher-ng configured)
<pitti> zyga: adt-run and adt-virt-* are from the autopkgtest package (which we  use in production)
 * zyga tries
<pitti> zyga: lp:a-p-t just has the prepare-testbed and run-adt-test wrappers, which basically start a VM, run adt-run adt-virt-null in that VM, and copy back the results
<pitti> kind of inside out, but that's what it is right now
<zyga> pitti: ok, so with adt-run itself, how do I test a *.deb I just built?
<zyga> pitti: or with a source tree
<zyga> pitti: that I did with something like svn-buildpackage --svn-export
<pitti> zyga: do you want to test the binaries from the archive, or actually your locally built debs?
<zyga> pitti: my locally built fixes
<zyga> pitti: specifically I want to fix something that is in the archive, broken, stuck in -proposed
<pitti> zyga: adt-run --built-tree=. --binary foo1.deb --binary foo2.deb ... --- adt-virt-null
<pitti> (for a built source tree),  or
<pitti> adt-run foo_*.dsc --binary foo1.deb --binary foo2.deb ... --- adt-virt-null
<pitti> for a source package
<zyga> pitti: thanks, let me try that
<pitti> or use adt-virt-schroot <schroot name>, or adt-virt-lxc --ephemeral <container>
<zyga> pitti: you should really blog about that more often, I keep finding useless docs when I google for adt help
<zyga> pitti: basically blogging this log is probably best docs on adt that I found
<pitti> well, the man page is supposed to explain all that
<jibel> ev, there have been several crashes of ubiquity (libautopilot-gtk actually) uploaded to errors.ubuntu.com but they are not retraced. Would you know why?
<jibel> ev, https://errors.ubuntu.com/problem/8ff8c9bfa3317b35d4a1af984e0e4208acd7af42 is the crash
<pitti> ev: did errors get an update to its apt sources for the trusty ddebs?
<ev> jibel: that's strange - that page indicates a retraced crash, but isn't showing the stack trace for it
<ev> looks like a bug
<ev> can you open one against lp:errors pointing at that?
<jibel> ev, sure
<ev> pitti: yes - lp:daisy retracer/config
<ev> just confirming that revno is deployed
<ev> yes, it is (r396 is deployed)
<jibel> ev, bug 1267112
<ubottu> bug 1267112 in Errors "errors indicates a retraced crash but isn't showing a stack trace" [Undecided,New] https://launchpad.net/bugs/1267112
<zyga> re
<zyga> pitti: the problem I found is that I didn't even install autopkgtests as a package, I followed earlier google hits and used the branch
<pitti> zyga: you can do that as well; I added a "run-from-checkout" script recently for that
<pitti> (that's what I use for autopkgtest development, and the test suite calls that)
<ev> thanks
<xnox> slangasek: I'd like to see your thoughts on bug #1267117
<ubottu> bug 1267117 in android-tools (Ubuntu) "adbd does not use pam_env" [High,Confirmed] https://launchpad.net/bugs/1267117
<infinity> doko: Why do you intentionally want more build failures in the rebuild test than you'd get in the archive? :P
<hallyn> pitti: ah, i originally had the drive=, but had gotten an error msg from it.  thanks.
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<hallyn> pitti: so the two changes are 'drive_add auto" and add "drive=" to end of device_add right?
<pitti> hallyn: I think the "auto" doesn't mean anything actually; I never saw a difference, you can put 0 or 2 or "dummy" there
<pitti> hallyn: and drive=, yes
<hallyn> and you're using virtio-blk-pci instead of virtio-scsi-pci
<pitti> *nod*
<pitti> hallyn: http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/revision/269 is the final commit
<pitti> hallyn: the id= is probably optional for device_add, but it's useful if you want to remove it again (drive_del pristinevm / device_del pristinevm)
<hallyn> pitti: you needed the drive_del before device_del?
<hallyn> hm, http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01381.html suggests the virtio-blk-pci and virtio-scsi-pci should be close.  <shrug>
<hallyn> this all needs documentation!
<pitti> hallyn: I don't need it in the branch, I just used it for interactive experimentation until I figured out an invocation that works (so that I don't need to keep relaunching qemu)
<hallyn> rharper: ^ is all this documented somewhere?
<hallyn> pitti: thanks :)  I never use this myself, just want to make sure this isn't forgotten before qa-regression-tests gets updated
<pitti> I didn't find any documentation for it, just outdated docs for pci_add
<hallyn> pitti: did you have any errors using virtio-scsi-pci?
<tseliot> cjwatson, infinity: if I wanted to make a boot option from live-installer permanent (as in to be applied on the installed system) would I have to modify the grub package? Or would I have other options?
<pitti> hallyn: well, not in dmesg, but that didn't create any block device
<pitti> hallyn: or I didn't shuffle the options hard enough to make it work
<hallyn> pitti: maybe that needed a cache= option.
<hallyn> thanks pitti
<cjwatson> tseliot: you don't have to touch grub.  just put the option after the "--" argument on the command line used when booting the installer and it should be copied to the target system
<pitti> hallyn: perhaps; TBH I don't understand what these two are doing, or what the difference is; I was quite happy that I found a working solution at last
<tseliot> cjwatson: that's great news, thanks!
<rharper> hallyn: reading...
<dobey> pitti: no, it doesn't sound familiar. will have a look at the logs
<zul> doko:  ping kombu is ftbfs because python-beanstalkc is not in main https://launchpad.net/ubuntu/+source/kombu/3.0.7-1ubuntu1/+build/5421716 (MIR for python-beanstalkchttps://bugs.launchpad.net/ubuntu/+source/beanstalkc/+bug/1252372)
<rharper> hallyn: what's the quesiton on usage of virtio-blk vs. virtio-scsi ?
<ubottu> Ubuntu bug 1252372 in beanstalkc (Ubuntu) "[MIR] beanstalkc" [Undecided,Fix committed]
<doko> zul, https://bugs.launchpad.net/ubuntu/+source/beanstalkd/+bug/1252374
<ubottu> Ubuntu bug 1252374 in beanstalkd (Ubuntu) "[MIR] beanstalkd" [Undecided,New]
<dobey> pitti: was there a new twisted upload yesterday? that would have caused the tests to be run, and could result in the failure
<pitti> dobey: yes, there was: https://launchpad.net/ubuntu/+source/twisted/13.2.0-1ubuntu1
<dobey> pitti: all i got was failure e-mails. it didn't tell me what upload caused the tests to run in the first place
<pitti> dobey: yes, indeed; the notification emails don't say that; jibel, is there some way to put the reason in there? (i. e. "triggered by dependency libfoo")
<zul> doko:  cool
<pitti> dobey: usually how it's supposed to work is that the new twisted (assuming that's what caused the regression) is held in proposed until the failures are fixed
<dobey> pitti, jibel: i thought the errors were supposed to go to the person that uploaded the package that caused the tests to run, anyway?
<pitti> dobey: but the ubuntuone packages don't directly depend on twisted, so this didn't happen
<dobey> pitti: well, at least a couple of them depend directly on twisted
<pitti> dobey: ideally, yes (they should go to both IMHO), but it's not quite that clever yet
<dobey> pitti: hrmm, why wasn't twisted held in proposed? :-/
<hallyn> rharper: oh my main question is whether the drive_add+device_add is meticulously documented somewhere so someone can make sane decisions about arguments to pass
<hallyn> (as opposed to looking for random examples and trying random combinations)
<robotfuel> Mirv: ping
<hallyn> i assume not, but also assumed that if there were you'd know
<pitti> dobey: that's what I ask myself
<rharper> hallyn: best place to see usage is in libvirt
<hallyn> lol
<hallyn> rharper: thanks.
<rharper> hallyn: iirc, you need both, you want to define a new device (pci for virtio-blk) and then apply a drive on top of the device
<rharper> qemu separates the guest visibile (pci device) from the drive (qemu side)
<hallyn> rharper: yes, i mean things like the first arg to drive_add,
<rharper> the id= parameter is used to tie the two together
<hallyn> which pitti found can be any random string and *seems* to do nothing
<hallyn> (0, auto, dummy, )
<rharper> hallyn: should be documented in hmp file
<rharper> I assume you're still using hmp instead of qmp ?
<rharper> akak human monitor
<rharper> *aka*
<hallyn> for my purposes yeah
<pitti> I used -monitor and nc -U /path/to/.monitor
<rharper> hallyn: qemu.git/hmp-commands.hx
<hallyn> at least that *enumerates* the options,
<rharper> lemme find my notes on the pci address format
<hallyn> rharper: that would rock - would those be apporpriate for a wiki page?
<rharper> possibly
<rharper> hmp adding of drives is pretty odd
<rharper> other than testing
<rharper> hallyn: all of my notes are too old (aka, pci_add)  but I'm seeing more documentation in qemu.git/doc/qdev-device-use.txt  -- which explains the parameter formats ... next step would be to document some examples of those usages via hmp/qmp
<jodh> pitti: still unable to recreate that test_conf_preload failure in adt/local 64-bit (2 different systems). Please can you send me logs or get me access to a system?
<jodh> pitti: (to clarify, that's 32-bit adt btw :)
<barry> pitti: hi, did the autopkgtest fix land on trunk?
<smoser> stgraber, ping
<smoser> wrt https://launchpad.net/bugs/1262951
<ubottu> Ubuntu bug 1262951 in Ubuntu "cloud-images /etc/network/interfaces shoud source-directory interfaces.d" [Medium,Triaged]
<smoser> i'm interested in knowing if you would
<smoser> a.) recommend putting the configuration for 'auto eth0' 'iface eth0 inet dhcp' in /etc/network/interfaces or in /etc/network/interfaces.d/
<smoser> and if in the interfaces.d directory, what would you recommend naming that file ?
<smoser> i can see reasons why you'd want it named by mac address or pci location (which aren't known at the time of image build).
<smoser> or simply  just 'eth0'
<pitti> jodh: just tried on the porter box, doesn't fail there (but they also run older kernel)
<jodh> pitti: yeah, I'd already tried on a porter box.
<stgraber> smoser: currently in a meeting, will reply in 30min or so
<smoser> stgraber, you can just reply in the bug.
<smoser> thanks.
<slangasek> xnox: bug #1267117> I thought the phonedations team wanted us to move to using ssh for reasons like this?
<ubottu> bug 1267117 in android-tools (Ubuntu) "adbd does not use pam_env" [High,Confirmed] https://launchpad.net/bugs/1267117
<xnox> slangasek: https://lists.ubuntu.com/archives/ubuntu-devel/2013-September/037674.html ?
<xnox> slangasek: "we shall use adb"
<xnox> slangasek: all current testing is done via adb, and it's most reliable one - e.g. ssh on emulator implies going via emulated 3G / qemu_pipe networking for which port-forwarding to  the host machine is flacky.
<xnox> slangasek: exec su - -c adb, does unblock me without getting entagled into ssh/adbd debates.
<xnox> slangasek: don't we want correct pam_env, regardless? =)
<directhex> what's the ubuntuish way to request package removal? it's so long since i've had to do it i've forgotten
<xnox> directhex: file RM bug against the package and subscribe ubuntu-archive team. But one doesn't need to do that for packages that have been / or will be removed in Debian.
<slangasek> xnox: ok.  So it seems to me that each connection to adbd would ideally be its own PAM session, but as that would be an annoying patch to maintain, I'm ok with the su - -c adbd in the job
<slangasek> xnox: you know that the autopilot test runners are all calling su - for us, right?
<slangasek> xnox: and you should be using that test runner for any of your testing
<xnox> slangasek: not consistently, and there are multiple test-runners at the moment (unrelated bug, tracked by qa/ci)
<xnox> slangasek: not sure, why it was implemented on add hock basis in test-runner, instead of solving it for all $ adb shell, invocations.
<slangasek> xnox: because the people solving the problem were not on the phonedations team ;)
<slangasek> xnox: what are the multiple test runners?
<xnox> slangasek: unity8, click, deb
<xnox> and a special jenkins one.
<slangasek> xnox: erm.  why is phablet-test-run not the only one used for all of these?
<xnox> one sets are recommended for app-dev, another for unity8 dev, and third one is actually used by jenkins....
<xnox> slangasek: i'm not sure. but there is a bug tracking & resolving this.
<rharper> hallyn: pitti: I've applied a decoder ring to drive_add/device_add for qemu-1.5.0   -- not sure which version you have, but this should still work on the newer releases as well (http://paste.ubuntu.com/6715428/)
<rharper> hallyn: pitti: the TL;DR for virtio-blk devices is drive_add 0 if=none,<drive options>,id=myid  ; device_add virtio-blk-pci,drive=myid
<pitti> rharper: indeed, that looks very close to what I used in http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/revision/269 to replace pci_add
<pitti> (but figuring that out was nontrivial)
<rharper> indeed
<slangasek> xnox: ok, well as far as I'm concerned phablet-test-run is the only one :-P
<rharper> pitti: ideally, instead of dummy, you want the pci bus -- it works because there's only one pci bus by default, but someone could construct a machine with multiple, and the device-id on the virtio-blk-pci device should be separate from the drive-id  , this allows querying via QMP for devices/drive etc.
<hallyn> rharper: thanks.  Can we put that into wiki.ubuntu.com/QemuDriveAddHmp or something?
<pitti> rharper: ah; I wasn't sure about what these mean (instead of the "dummy" you can use just about anything without any noticeable difference); thans for the explanation
<rharper> hallyn: yeah, it'd be worth walking through the scsi adapter version
<rharper> hallyn: we should call is QemuDriveAdd and do both HMP and QMP version
<rharper> lemme work up the qmp steps
<rharper> should be the same, just all json'ed up
<smoser> can someone nplease fix this!
<smoser> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1240977
<ubottu> Ubuntu bug 1240977 in unity (Ubuntu) "some modal dialog windows such as chromium-browser get stuck/lost/do not raise if on different desktop" [Undecided,New]
 * smoser lost that chromium dialog window again
<xnox> slangasek: phablet-test-run, executes the tests, but doesn't do any preparation / rollback / gathering test results back to the host / making the output in .xml for jenkins etc. There are a lot more wrapper scripts on top of phablet-test-run.
<slangasek> xnox: wrappers on top of phablet-test-run> ok, that's fine (well, ish); just wanted to make sure we are all actually using the central tool for environment setup
<xnox> slangasek: i've based all my changes on top of lp:ubuntu-test-cases/touch, which is used by ci.ubuntu.com. With patches to adjust for emulator provisioning. However, I may not be hitting the same code-path =(
<slangasek> xnox: does that mean lp:ubuntu-test-cases/touch is not using phablet-test-run?
<ogra_> dholbach, heh, i didnt even remember that you are an admin of canonical-arm-dev :) i was the one suggesting to chrisccoulson to use that PPA for builds :)
<xnox> slangasek: from https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-friends-app-autopilot/107/console , jenkins.sh is used which eventually calls into utah testsuites, which invokes controlled settling of the device, runs tests, runs clean up.
<xnox> slangasek: or in other words, things are different since e.g. phablet-test-run alone does not produce the same artifacts one can see on ci.ubuntu.com.
<slangasek> xnox: hum.  so where's the bug report for this and who's working on it?
<ogra_> dholbach, (for the oxide stuff that is)
<xnox> slangasek: and i think at the moment i'm using more of a phablet-test-run based path, cause I do invoke phablet-test-run (via 2 wrappers)
<xnox> slangasek: one sec.
<xnox> slangasek: oh, and little did I know about otto in the mix =) https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1262879
<ubottu> Ubuntu bug 1262879 in Ubuntu CI Services "There should only be one, documented, way to run tests on devices" [Undecided,Confirmed]
<slangasek> "otto"?
<ogra_> we dont use otto
<ogra_> we use utah
<ogra_> (for the image testing at least)
<ogra_> and utah uses phablet-test-run everywhere
<xnox> ogra_: not as far as I could trace.
<ogra_> (but it also sets up the environment, sudos to the phablet user in advance etc)
<ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/ ... all tests you see there are done by utah and use phablet-test-run
<ogra_> talk to plars for details, he knows that bit of infra pretty well
<dholbach> ogra_, I'm not, you are
<dholbach> ogra_, but it's taken care of, Victor did it - thanks
<ogra_> dholbach, oh, why did you get that mail then
<xnox> ogra_: I'm executing commands from https://wiki.ubuntu.com/Touch/Testing#Running_Deb_tests and https://wiki.ubuntu.com/Touch/Testing#Running_Click_tests and i get failures, that are pass on ci.ubuntu.com =)
<ogra_> ah
<ogra_> xnox, do you "sudo -u phablet -i" in advance ?
<ogra_> you need to be inside the upstart and dbus sessions of the user
<barry> xnox: i think there's a problem with your emulator test script if i also have a device plugged in via usb: "error: more than one device and emulator"
<barry>  
<ogra_> *and* some tests require that the screen is unlocked and powerd is set top "always on" ... utah takes care of such stuff
<barry> xnox: the fix *might* be Hey, just unplug the device, but it would be nice to fail fast in that case
<xnox> ogra_: investigating the utah control lists it does: prepare-autopilot-test.sh, which installs packages, then there is unlock-screen.py executed with unlocks the screen & turns off power / screen shutdown, and then  "autopilot-run address_book_app.tests.{}" is executed.
<xnox> ogra_: there is no places where phablet-test-run is executed by utah that I can find.
<rharper> hallyn: it appears that it'll be some time before drive_add appears in QMP; for now the only drive_add mechanism is via the HMP (which libvirt uses to do block hotplug as well)
<xnox> ogra_: i don't execute "sudo -u phablet -i" I actually execute phablet-test-run, and that is doing all adb commands for me.
<xnox> ogra_: and collects logs.
<pitti> doko, infinity: heh, fun: libtool not being libtool any more also broke the upstart tests (thanks jodh for debugging)
<xnox> barry: yeah, popey noticed that as well. For now, I can only recommend to unplug the phone, or export an environemnt variable.
<hallyn> rharper: oh yeah, i remember noticing that when trying to debug device_remove's new behavior
<xnox> barry: export ANDROID_SERIAL=emulator-5554, but not sure if that would make everything work.
<xnox> pitti: ah, quite we use libtool directly.
<xnox> pitti: i guess libtool-bin dependency is needed.
<xnox> jodh: infinity: doko: ^
<pitti> xnox: no, that got dropped again; it's fixed again
<pitti> (same with glom)
<xnox> pitti: i'm so out of date =))))
<pitti> xnox: so is my schroot, which is why I got that upstart failure, but jodh didn't :)
<xnox> clearly i'm not down with the kids =)
<plars> doanac: iirc, the code is basically identical but we don't actually start using phablet-test-run until we enable the latest changes you were working on correct?
<pitti> (i. e. my schroot updated this morning, before the reversion of libtool-bin)
<doanac> plars: correct
<plars> xnox: ^
<plars> xnox: is this about setting the testability config in preparation for running tests?
<plars> xnox: if so, I was thinking something in phablet-config might be useful to do it if you are setting up for autopilot tests
<plars> xnox: in fact, there's already an autopilot option for that script, that sets the click apparmor rules, might make sense to do it there
<xnox> plars: it's about: test_results.xml being different, envrionment differences, screen-unlock & settle sequences different, also that -testability shouldn't be set.
<xnox> plars: so at the moment the environment as is during the test under utah, is very different then under "just" phablet-test-run.
<xnox> plars: and if you switch to phablet-test-run now, you will see regressions that I am seeing.
<xnox> plars: i'll work on using jenkins.sh instead of phablet-test-run to match ci.ubuntu.com. But either get some things wrong.
<xnox> plars: and a lot of people not aware of the differences.
<plars> xnox: I'm trying to trace back through your lastlog but not sure I have the full context. if it's about the click-user-hooks, we are just using phablet-config  autopilot --dbus-probe enable I think for that, which does aa-clickhook -f --include=/usr/share/autopilot-touch/apparmor/click.rules
<plars> xnox: no matter what you are running, even phablet-test-run, this is required to run beforehand
<xnox> plars: i know. but for example, under phablet-test-run - ubuntu-system-settings tests are executed without Locale set, under ci.ubuntu.com however there is locale set when ubuntu-system-settings tests are run.
<xnox> plars: and instead of wrapping even more commands with "su - -c", I'm proposing to fix adbd across the board, to properly start/use a PAM session such that we can drop all "su - -c" hacks everywhere else.
<plars> xnox: that sounds useful
<xnox> plars: note that developers are adviced to use "just phablet-conf" and "phablet-test-run" and "manually unlock and turn the screen on", which is not what happens on ci.ubuntu.com and thus results are different between the two methods.
<plars> xnox: yeah, it's that "manually unlock and turn the screen on" which isn't too nice for automation :)
<xnox> plars: can you inject this onto the image: sudo sh -c "echo exec su - -c adbd > /etc/init/android-tools-adbd.override"
<xnox> plars: reboot the phone and execute representitive set of utah tests as done on ci.ubuntu.com? e.g. unity8 and a couple of core-apps?
<xnox> plars: if that doesn't break anything, I'll land that change.
<plars> xnox: sure, I'll try it locally in just a bit
<ogra_> xnox, hmm, sudo -u phablet -i should process ~/.pam_environment and set the locale
<xnox> plars: thanks a lot.
<ogra_> i thought all our utah tests used that sudo prefix nowadays
<ogra_> hmm, in fact i think it is even inside phablet-test-run, not in utah
<xnox> ogra_: $ adb shell locale; should work. And that's not just about locale, it's about LD_PRELOAD, QT_* variables, and everything else set in /etc/environment.
<ogra_> xnox, well, that should be hard set to C or en_GB/US
<ogra_> we dont really set system locales on the phone images iirc
<ogra_> only per user ones in ~/.pam_environment
<xnox> ogra_: it is set in both /etc/environment & in /etc/default/locale, but not sourced in any way. Along with many other things.
<ogra_> right
<ogra_> because adbd calls bash directly
<ogra_> because it pretends to be a serial console
<xnox> ogra_: serial tty, runs login, which has pam support. So serial tty is fine. adb simply runs "bash in login shell mode" which doesn't setup PAM session. (Not sure if that's a bash bug)
<xnox> slangasek: should "bash --login" setup a PAM session?
<ogra_> xnox, serial *console*
<ogra_> :)
<slangasek> xnox: no
<xnox> slangasek: ok.
<slangasek> for one thing, setting up a session may require privileges
<xnox> ogra_: here is the diff between "adb shell" environment and a "su -" environment: http://paste.ubuntu.com/6715828/
<ogra_> xnox, i would love to drop adb today, but there was mgmt concern that it needs to stay 100% android compatible for OEM tools to work etc
<cjwatson> doko: I had to cancel an arm64 test build in order to get ofono-phonesim building, which is urgent to get through -proposed for touch - I've retried it
<ogra_> xnox, so i wouldnt add any login there since this will  break exactly this assumption
<cjwatson> (sorry for any inconvenience)
<xnox> ogra_: there are many things that adb does that ssh doesn't, and nice versa. However having environment between "ssh" and "adb shell" is a carefully planted trap one can easily walk into, and is easily fixable.
<xnox> s/nice versa/vice versa/
<ogra_> xnox, right, i'm all for processing pam, but the behavior of the shell needs to stay the same
<ogra_> so that OEMs can use their exiting flash tools for android flashing etc
<xnox> ogra_: at the moment "$ adb shell" has environment, as scrubbed by upstart. So pretty much nothing & UPSTART_* variables. Not even HOME set.
<ogra_> xnox, btw, i personally dont see any benefit of adb ... i would drop it, switch on rndis networking over USB and attach a ssh login ;)
<xnox> ogra_: so i don't understand what needs to stay the same.
<ogra_> but i was denied because of the android compatibility
<ogra_> xnox, behavior, so if an OEM has mass flash tools that they use on android these work on our system too
<xnox> ogra_: adb into the emulator is the only way to speak to emulator, and it does not rely on neither networking, usb networking, nor 3g emulated networking =)
<ogra_> yeah, thats the emulator :P
<xnox> ogra_: flashing portions of adb, have nothing to do with "adb shell" portion of the tool set.
<ogra_> the discussion i had about this predates the emulator by months :)
<xnox> ogra_: whilst personally you might not see any benefit of adb, ssh is not a superset of features that adb provides and never will be.
<ogra_> xnox, well, i was told we even need to run adbd as shell user (so that adb root is needed and work as expected) etc
<ogra_> xnox, no, i would have liked to replace adb shell with ssh
<ogra_> and have a login etc
<ogra_> but as i said, i wasnt allowed to for the above reasons
<ogra_> xnox, i meant to only disable the awful serial shell and replace it by an ssh login
<ogra_> anyway, thats long put to rest
<ogra_> xnox, making the shell user thing work and hook that somehow into pam might be of more benefit
<ogra_> (since thats pÃ¼lanned for this cycle anyway)
<xnox> ogra_: ... that's completely out of scope, and orthogonal to my current task.
<ogra_> why ?
<ogra_> it would be the phablet user in our case
<ogra_> that would even save you the sudoing
<xnox> ogra_: i need root.
<ogra_> and enable you to *just run* the tests
<xnox> ogra_: not user.
<ogra_> for running tests in the user env ?
<ogra_> (all our tests run in the user session)
<ogra_> s/run/need to run/
<plars> yeah, the tests need to run as phablet user
<ogra_> which is why we jump through awful hackish sudo loops atm in phablet-test-run and utah
<xnox> ogra_: they do, but all the provisioning, setup, tear down, and log collection needs root to control hardware and system level things.
<xnox> ogra_: my task at hand is to parallelise and run tests in the emulator, with as high pass / parity rate to the real devices as possible. And I'm on vacation from saturday.
<xnox> ogra_: i have nothing to do with re-engineering our adb, user-sessions, and test frameworks ;-)
<ogra_> xnox, well, adbd will change to default to the shell user ... that will likely break your stuff if you dont add adb root to your code
<ogra_> for now, why cant you just source /etc/profile and /etc/environment after login ?
<ogra_> given the whole setup will change anyway
<ogra_> that should give you all you need
<xnox> ogra_: no it will not give me all i need. at the moment it's not possible to run tests without root and without RW image. As one needs to install system-wide debs & disable apparmor.
<xnox> ogra_: there is no "my stuff" only phablet-test-run, etc. and they do call "adb root" abeilt being pointless for the current setup.
 * ogra_ doesnt get that "run tests with root" 
<ogra_> i understand that you need root to install the autopilot pieces ... but the tests are still run under sudo -u phablet -i
<xnox> ogra_: provision a read-only phone and trying running click test-suit without using root, nor switching image to RW.
<ogra_> xnox, hmm, sergiusens worked on stuff there ... i know i can test all click packages without ever becoming root
<ogra_> but i suspect thats not what you mean when saying "click test suite" ?
<ogra_> xnox, we should probably consider just seeding what you need if it is not to intrusive, that would save the whole root/non-root stuff
<xnox> ogra_: exec_with_adb_user() {
<xnox>     adb -s $ANDROID_SERIAL shell sudo -u $USER -i sh -lc \'"$@"\'
<xnox> }
<ogra_> yeah
<ogra_> sudo loops :)
<xnox> ogra_: http://paste.ubuntu.com/6715926/ which is missing half of the stuff from /etc/environment.
<xnox> ogra_: so the problem with adb not sourcing /etc/environment is affecting phablet-test-run, which i'm using, which is causing build-failures not seen with ci.ubuntu.com because that is using utah, different setup/tear-down, and not using phablet-test-run.
<ogra_> utah definitely uses phablet-test-run
<ogra_> this is a requirement we made about 1 year ago
<xnox> ogra_: =))))))
<ogra_> and i see it called in all test logs
<xnox> ogra_: which log?
<ogra_> (on the image tests)
<ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/
<ogra_> clickj one of the build numbers and click through to a test
<xnox> ogra_: check again. e.g. the click apps test and deb tests.
<xnox> console output.
<xnox> and compare the outputs with locally running phablet-test-run for the same click app / deb.
<ogra_> plars, ^^^ can you clearify ? i'm sure we use phablet-test-run everywhere in utah
<ogra_> would be quite a policy breach if we didnt anymore
<ogra_> or doanac ^^^^
<xnox> ogra_: it doesn't matter what is used, apart from adbd having bad environment, which is the default one available to external users and it doesn't match the running environmnet from within the phone.
<plars> ogra_: I believe we never have, but we've done quite a bit to make sure that what we're running is basically identical. This was due to a requirement to run tests individually at the time.  However, the latest stuff doanac has been pushing in will get us to where we are really running with purely phablet-test-run, and most of it has already landed
<ogra_> plars, hmm, didnt we work heavily with asac back a few months to make sure phablet-test-run is used on utah too ?
<doanac> ogra_: we've made strides to get to that point. we still have a little work left though and got preempted
<ogra_> oh sigh
<plars> ogra_: that's what all this stuff has been about - it wasn't just a simple change though
<ogra_> xnox, ignore my noise then, i was convinced that was long done
<xnox> ogra_: no worries. we are on the same page now =)
<ogra_> xnox, though sh -l *should* process the environment theoretically, no ?
<plars> ogra_: a lot of the setup things needed were moved into phablet-config in phablet-tools though, and we use that, as does anyone running locally with phablet-test-run
<seb128> slangasek, mdeslaur, pitti: I'm not subscribed to the technical-board list to reply, but following the hibernate discussion, it would be useful to get https://code.launchpad.net/~jefferyto/ubuntu-docs/lp1232814/+merge/197782 merged (if somebody wants to point it, it was mentioned in some of the emails that we don't have instructions for user who want to re-enable it)
<ogra_> plars, yeah
<ogra_> xnox, i wonder what happens if you make that "bash -lc" instead, might be a limitation of dash here
<ogra_> (in exec_with_adb_user)
<asac> doanac: what is left? :)
<xnox> ogra_: well, i want to put one hack in one place in /etc/init/*adb.conf, without iterrating across correct options in every single script / framework / harness used for the ubuntu-touch today.
<xnox> ogra_: or re-writtes of thereoff.
<doanac> asac: the output of phablet-test-run is junit xml. we need to able to convert that to utah.yaml so that the dashboard will be able to report results
<xnox> ogra_: plus aren't all tools rewritten in go anyway? thus making current incornation of phablet-* obsolete.
<ogra_> xnox, lol ... yes, some rewriting has started
<ogra_> i doubt all will be moved in trusty
<asac> note that "every single framework" in this case means "two frameworks" and not hundreds :)...
<ogra_> that smells like a rather long process
<asac> so if its really causing us pain, implementing it temporarily in two places should be a worthwhile option to consider
<xnox> asac: well depends at which level of wrapper scripts one counts. "two matryoshka dolls" =)))
<asac> yeah... :)
<ogra_> xnox, so looking at your bug, why do you want to use an override instead of modifying the exec line in the package
<asac> but for me thats all just one tiny thing :)
<ogra_> xnox, seems we would simply benefit from having it set everywhere
<asac> i think its a tradeoff of pain
<xnox> ogra_:  which bug? the unity8 override is only shipped in unity8-autopilot package and not in unity8. That override is specific to running unity under test, not under general operating conditions.
<ogra_> xnox, bug 1267117
<ubottu> bug 1267117 in android-tools (Ubuntu) "adbd does not use pam_env" [High,Confirmed] https://launchpad.net/bugs/1267117
<ogra_> i would just fix the exec line in the package
<asac> doanac: thats the only thing left?
<ogra_> we're out of sync with debian here anyway
<xnox> ogra_: read carefully, i'm using .override now locally, but yeah i do intend to just change .conf if we agree to ship that by default.
<ogra_> xnox, if it is provenb to fix the issue, go for it
<xnox> ogra_: i've requested for plars to execute tests under utah, before I "go for it".
<xnox> ogra_: we test thing before landing.
<ogra_> good
<doanac> asac: i think. we've been looking at getting autopilot to produce subunit for phablet-test-run. so we'd really write a filter to convert subunit to utah.yaml
<ogra_> pfft ... yeah. yeah, thats what you tell asac so he pays you drinks at the sprint :P
<doanac> asac: the test-execution-service job i wrote actually uses phablet-test-run
<doanac> we just don't have a qa-dashboard that can handle it yet
<ogra_> xnox, if you need someone to nod it off after testing feel free to ping
<asac> doanac: why do we hook the fate of this up to the subunit conversion?
<ogra_> :)
<asac> i would prefer to see it decoupled
<xnox> ogra_: hm, not sure that's quite right. slangasek knows my preferences in bribes, but i don't think asac knows that yet ;-)
<asac> whats the price?
<asac> beer?
<asac> :)
<doanac> asac: we don't have to. you can deprioritize subunit. it was a request from the QA team. so if i'm writing a filter i just wanted to write it once and be done
<ogra_> xnox, we'll tech him :)
<plars> xnox: I've been through 1 run of unity locally and saw a maliit-server crash and 2 failures which were not expected. I'm trying it without the .override now though, as it's been some time since I've tried this locally. So it could be something stupid on my host, but just want to check as that's certainly different from what we see in the lab
<xnox> asac: i'm not gonna tell you that easy =)
<ogra_> asac, coctails
<ogra_> fancy ones even i guess :)
<xnox> asac: it is on irclogs.ubuntu.com, in 2011-2013 years.
<asac> xnox: you can send a gpg encrypted /msg :)
<asac> lol
<asac> my key is in my launchpad profile i believe
<ogra_> *giggle*
<Laney> shakira greatest hits
<Laney> or maybe shania
<asac> hehe
<xnox> asac: .... or bribe slangasek to tell you =))))
<asac> doanac: yeah, but when is subunit coming?
<slangasek> seb128: well, "we don't have instructions" was only one of the concerns.... the other was "there should be a straightforward way to re-enable it"
<slangasek> xnox, asac: heh
<doanac> asac: it requires landing in distro for autopilot (its in trunk). landing a change to phablet-tools (not done). and fixing some proof-of-concept code i wrote
<doanac> so its work.
<asac> doanac: i mean, we have so much distraction because of this that there is almost no timeline that can justify not writing a throwaway filter.
<doanac> asac: i can do junit->utah conversion.
<asac> let me check something
<doanac> we'll have to explain to QA why
<doanac> and they might have subunit ready before I can write this filter
<seb128> slangasek, still, having the instructions updated (which that mp is doing) would be a step in the right direction ;-) (do we still have active people in the documentation team to review/approve it?)
<slangasek> seb128: it does seem strange to me to have hibernate support blocked at the policykit layer, though
<asac> doanac: ok after checking i highly recommend to not hook your fate up to autopilot
<asac> doanac: autopilot hasnt landed for ages
<asac> and afair has a bunch of big issues pending
<doanac> asac: okay. we need to loop in ev and decide how to allocate my time towards this.
<sergiusens> ogra_, xnox no need for root or rw for click
<ogra_> yeah, as i thought
<ogra_> only for non click tests
<asac> doanac: sure, thats clear
<asac> doanac: do you know if qmltest also produces subunit?
<asac> or junit?
<seb128> slangasek, why? that makes the UI do the right thing (e.g hide the entry by default, show it if the permissions are granted/enabled)
<asac> doanac: anyway. i think its best to kick a quick mail with you/ev/me/fginter/didrocks on this
<asac> let me know if you send it
<slangasek> seb128: because I don't think it's logical to treat this as an access constraint, it's not that the user isn't /allowed/, it's that it's broken and we want to hide it
<seb128> slangasek, I guess we could define a new gsettings key "show-hibernate-ui" and make the different clients use it
<seb128> slangasek, patches are welcome ;-)
<slangasek> seb128: well, first I'd like to establish whether the design would be acceptable :)
<seb128> slangasek, the current solution was more "what's the easiest way to get the UI for hibernate hidden from the different components" I guess
<arges> jamespage: hi. have some updates on the ovs 1.4.6 issues I've been seeing
<arges> bug 1219788
<ubottu> bug 1219788 in openvswitch (Ubuntu Quantal) "[SRU] Update openvswitch to 1.4.6 stable release" [Medium,Fix committed] https://launchpad.net/bugs/1219788
<arges> Not exactly sure how to proceed, should the fix go on top of your 1.4.6 SRU?
<arges> i'll update the bug
<jdstrand> Snow-Man: fyi, mdeslaur is working on the openssl update now
<Snow-Man> ok, thanks!
<plars> xnox: I'm having trouble sorting much out locally, because unity keeps crashing on me, both with and without the override. I'm running it the same way as in the lab (albeit my host environment could be different since I'm running it off a desktop box here at my house)
<plars> xnox: I did manage to make it through unity with no problems and the override was in place though
<plars> xnox: and I just saw notes-app pass 100% with the override in place (and no crash this time)
<PublicStaticVoid> Is it okay to report and discuss weird behavious in 14.04 here? I understand it is beta.. so didnt wanna ask in #Ubuntu
<PublicStaticVoid> I just have one issue so far
<rharper> hallyn: here's my first pass... https://wiki.ubuntu.com/QemuDiskHotplug   I want to add the guest side output for these operations, but I need to install different ubuntu levels on a few systems before I can create the output.
<PublicStaticVoid> Where the UI Unity or Xorg freezes and if I click it goes bloack for a about 10 to 15 seconds then returns to normal..
<PublicStaticVoid> I can post logs or dmesg or anything that may help, dunno if it is a bug, known issue, or my actual system..
<arges> PublicStaticVoid: your best bet would be to file a bug using 'ubuntu-bug'. You can read up more about how to do it here: https://help.ubuntu.com/community/ReportingBugs
<PublicStaticVoid> Okay, I have filed a bug before, not sure if I was supposed to for 14.04 since it is a rc
<PublicStaticVoid> Was hoping yu guys had heard of it and there was a quick fix or something haha
<PublicStaticVoid> Is it true we are going Rolling release?
<PublicStaticVoid> Also, when running 14.04 am I supposed to run apt-get distro-upgrade often?
<hallyn> rharper: that's awesome, thanks.  fwiw lp:qa-regression-testing scripts/test-qemu is where i'll need that.  as it's our regression testsuite for qemu, you might be interestedin taking a look
<hallyn> (and scripts/test-libvirt.py is the analogous libvirt testsuite)
<jamespage> arges, i should think so yes
<rharper> hallyn: cool, I'll take a good
<smoser> wonder if anyone has thoughts on where this would come from
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1267225
<arges> jamespage: ok creating the branch now
<ubottu> Ubuntu bug 1267225 in cloud-initramfs-tools (Ubuntu) "initramfs in cloud-images does not contain crypt modules" [High,Confirmed]
<smoser> utlemming, ^. something (either bug in build process or mkinitramfs) is making us miss crypto modules in the cloud images as they're shipped.
<smoser> but running 'update-initramfs -u' gets them.
<utlemming> smoser: interesting....I'm not sure what is happening there, but I'll take a look
<arges> jamespage: would you prefer I dput the changes to ovs?
<smoser> slangasek, you have thoughts on what we could be doing wrong there? how could an initramfs get generated without those modules ?
<infinity> smoser: Generated without cryptsetup being installed?
<infinity> Though, I guess that would fail a bit differently on boot.
<smoser> right. the initramfs got generated without those modules.
<smoser> but i'm not sure how. its not like there is code that says "maybe include crypto"
<smoser> there is stuff in /usr/share/initramfs-tools/hook-functions for 'hidden_dep_add_modules' that specifically comments on crypt.
<smoser> but that doesn't seem variable
<Peace-> hello could someone test firefox here ? https://palava.tv/mio
<Peace-> because firefox 26 on ubuntu doesn't work here on fedora seems it does
<Peace-> i will log out and login
<jcastro> stgraber, I am finding I need to sudo to use lxc-ls in trusty, is this normal or a bug?
<jcastro> in saucy I didn't need sudo
<stgraber> jcastro: normal. For two completely separate reasons. 1) We changed the permissions of /var/lib/lxc and /var/cache/lxc to 700 to avoid a security issue involving calling outdated setuid binaries. 2) Starting next week lxc-ls will list your user's containers unless it's run as root.
<jcastro> thanks!
<rharper> hallyn: the test-qemu could use some updating ... from my initial glance, it appears to be a host-side (qemu monitor) validation only -- is there any guest-side validation to go along with it ?
<hallyn> rharper: I don't think so.  it was written by security team, with host security and correctness as primary goal.
<rharper> interesting
<hallyn> it does install acpi, which is more than test-libvirt does
<hallyn> rharper: certainly the pci-add tests need to be updated since pci_add is gone;  oterh patches certainly will be welcome.  do you know how to do merge requests in lp?
<rharper> there's a huge hole in the device_add area  -- I see exactly one (device_add usb-storage) -- when there are over 140 qemu devices that can be added -- I already had two segfaults testing today (qemu 1.5.0) with just simpel device_add driver=XXXX
<rharper> hallyn: not yet
<rharper> hallyn: % qemu -device ? 2>&1 | wc -l
<rharper> 140
<rharper> s/over/exactly
<hallyn> rharper: well, do keep in mind that any test we add, if the underlying support gets pulled out later then we have to deal with it
<hallyn> so i would NOT want all 140 device types to be tested :)
<rharper> it's not a support question
<rharper> it's a does-it-segfault
<rharper> even if the device doesn't work, trying to add it should segfault qemu
<rharper> *shouldn't*
 * Logan_ pokes cjwatson. Around?
<rharper> at least, I'm assuming that's what this sort of host-side testing would want to catch ?
<bdrung> doko: yes.
<rharper> hallyn: I can take a stab at replacing the hotplug bugs (s/pci_{add.del}/device_{add,del})
<hallyn> rharper: great, thanks.  (I've been holding off on my version at http://people.canonical.com/~serge/qrt-qemu.diff bc i was taking guesses at the right way))
<rharper> hallyn: np, should be able to fix up the nic hotplug too
<hallyn> awesome
<rharper> hallyn: I should get this working  in a trusty vm, right?
<hallyn> rharper: yup
<hallyn> rharper: before running it, check README under scripts/qemu
<rharper> k
<smoser> xnox, ping
<slangasek> smoser: looks to me like /usr/share/initramfs-tools/hooks/overlayroot makes the aes support conditional on: egrep -qswo "aes" /proc/cpuinfo && manual_add_modules aesni_intel || true
<slangasek> smoser: so that looks like a wrong assumption that the initramfs will be built in an env where aes is supported
<Netsnipe> hi everyone
<Netsnipe> I'm a Cloud Support Engineer with Amazon Web Services these days
<Netsnipe> does anyone anyone know who might be responsible for the AMIs?
<stgraber> smoser, utlemming: ^
<Netsnipe> s/anyone//
<utlemming> Netsnipe: that would be me
<utlemming> Netsnipe: interesting to see an AWS person in a public place :)
<Netsnipe> I used to be in #debian-devel about 10 years ago = P
<Netsnipe> utlemming: is there an official process for us to engage with you guys?
<Netsnipe> or would you prefer going through launchpad?
<Netsnipe> we have customers requesting instance store backed HVM AMIs
<utlemming> interesting request....do you know what releases?
<utlemming> Netsnipe: a launchpad bug would be helpful
<jtaylor> is pygtk working in trusty?
<jtaylor> gtk3 via gi bindings
<cjwatson> Logan_: briefly
#ubuntu-devel 2014-01-09
<pitti> Good morning
<Logan_> Why are the build queues so clogged? Did someone do a mass rebuild?
<Logan_> Ah, I see.
 * Logan_ eyes dojo.
<Logan_> And doko.
<pitti> Logan_: they have a low build score, so any "regular" upload trumps them
<Logan_> Gotcha.
<dholbach> good morning
<mitya57> Good morning dholbach!
<dholbach> hi mitya57
<dholbach> mitya57, what do you think about getting a new ubuntu-packaging-guide into Debian?
<mitya57> dholbach: I don't have upload rights for it, so ask Andrew
<dholbach> mitya57, sure... just wanted to ask if you generally agreed ;-)
<mitya57> dholbach: I generally agree :)
<directhex> <directhex> Laney, ok, i'm only working a half day today. what can i usefully do?
<directhex> sorry, i have flaky wifi
<dholbach> mitya57, cool :)
<Laney> directhex: If you want to work on migration, the issues are at the end of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> # su -c whoami nobody
<pitti> This account is currently not available.
<pitti> cjwatson: ^ ah, shell was changed for "nobody" as well?
 * pitti goes to fix postgresql for that
<seb128> hum
<seb128> doko, is that known?
<seb128> " Preparing to replace tcl-dev:i386 8.6.0-0ubuntu1 (using .../tcl-dev_8.6.0+6_i386.deb) ...
<seb128>  Unpacking replacement tcl-dev:i386 ...
<seb128>  dpkg: error processing /var/cache/apt/archives/tcl-dev_8.6.0+6_i386.deb (--unpack):
<seb128>   trying to overwrite '/usr/lib/i386-linux-gnu/libtcl.so', which is also in package tcl-lib:i386 8.6.0-0ubuntu1
<seb128> "
<pitti> cjwatson: that change came quite surprisingly, I'm sure it breaks more stuff than just phonesim and postgresql
<doko> seb128, ahh, my bad ... will fix
<seb128> doko, thanks
<directhex> "dput ubuntu foo.changes" will go into -proposed by default nowadays, right? i don't need to pass any special parameters?
<Laney> yep
<Laney> with Distribution: trusty in your changes file for example
<directhex> ok, cool
<Smit-Tay__> Can anyone please explain why attempting to install 32 bit development libraries should result in this:  http://pastebin.com/QbqZuCZR
<Smit-Tay__> I am trying to target both x86 and x86_64 from Ubuntu 12.04 x86_64
<directhex> oh for the love of... can someone with adequate special snowflake designation please merge libgpod from debian experimental? it's just adding armhf to the supported mono arches list. which could feasibly be done in experimental now too but i don't want to poke that without hyperair's say so
<directhex> (it's blocking banshee build)
<hyperair> directhex: i did
<hyperair> it's been sitting in the sponsoring queue for god knows how long now
<hyperair> i should probably apply for ppu access
<directhex> hyperair, gnome team sponsoring queue?
<hyperair> um ubuntu-sponsors i think
<hyperair> but uh, i didn't know it could be done in experimental
<hyperair> but if it can be, that makes things a lot easier
<hyperair> when did it start working in exp?
<directhex> experimental has armhf mono. well, it will do when it actually gets around to building (a month in the buildd queue so far! a month!)
<directhex> but the experimental mono source package has working armhf binaries in trusty-proposed and raspbian so i'm quite confident
<Laney> hyperair: I'll look at that
<Laney> god knows how long is since the first btw ;-)
<Smit-Tay__> Has anyone here got time to explain something to me ?
<seb128> directhex, what is "gnome team sponsoring queue"? for sure the GNOME team should look at their set it the normal queue rather than creating a new system?
<Laney> they mean the ubuntu desktop team
<directhex> seb128, i thought hyperair was talking about a delay in sponsoring on debian's side
<Laney> o rly
<seb128> directhex, oh, ok
<directhex> seb128, (since the change necessitating a merge can go into debian in experimental)
<directhex> Laney, i'll merge tasque
<seb128> directhex, ok, I just saw that there was a libgpod in the ubuntu sponsoring queue
<seb128> but if we can sync that would be even better
<directhex> hyperair's vanished, so the timing sucks :/
<directhex> seb128, can we accept the merge for now, with a view to syncing in future?
<seb128> directhex, sure
<seb128> I'm going to have a look later, if nobody beats me to it
<seb128> I want to finish what I'm doing atm first though
<Laney> I'm looking now
<seb128> Laney, thanks
<Laney> np
<Laney> directhex: done
<directhex> yay
<Laney> it already had armhf in the arch lists so I don't know which fix was important :P
<cjwatson> pitti: I guess; I've been putting it off for ten years, but then Russ came along with a patch to make base-passwd support debconf prompting
<doko> cjwatson, xnox: do you remember why tcl-lib had a .so symlink in the package (and not tcl-dev)?
<cjwatson> no ...
<cjwatson> pitti: trying to grep via codesearch now
<directhex> oh hamburgers. MIR for gtk#3 needed -_-
<directhex> (blocking libgpod build)
<directhex> i assume i can't just recycle https://wiki.ubuntu.com/MainInclusionReportGtkSharp2 from 2005
<Laney> I'd hope it wouldn't need a report as it's a new series of code already in main
<cjwatson> pitti: http://ubuntu-codesearch.surgut.co.uk/search?weighted=1&q=su+.*nobody doesn't look too bad, but I'm collecting bug reports in http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=base-passwd@packages.debian.org;tag=shell-fallout
<pitti> cjwatson: ah, thanks; I uploaded a fixed postgresql-common to sid, should autosync soon
<rbasak> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<rbasak> bug 1267385
<ubottu> bug 1267385 in puppet (Ubuntu) "Default file mode now 0600 instead of 0644 (regression in CVE-2013-4969 fix)" [Undecided,New] https://launchpad.net/bugs/1267385
<rbasak> I've verified this.
<rbasak> Specifically that 2.7.11-1ubuntu2.6 regresses 2.7.11-1ubuntu2 in a way that I think is quite serious.
<rbasak> mdeslaur: ^^^
<rbasak> I think this will regress puppet-based redeploys to cloud instances.
<SpamapS> rbasak: I happen to be awake ATM. What do you think should happen? Ram a fix through, or remove the offending package until a better fix can be done?
<rbasak> SpamapS: good question. I was hoping to leave the security team to answer that question.
<rbasak> I think this almost certainly will regress a !small group of people. Better to hold the fix back a day, I think.
<rbasak> Then again, the proposed fix does seem quite trivial.
 * rbasak doesn't know
<SpamapS> rbasak: yeah security team will likely have somebody on it quicker than I can figure out what we should do :)
<apachelogger> who's responsible for getting new translation templates accepted from the import queue?
<mitya57> dpm: looks like it's you ^^
<mdeslaur> rbasak: ok, taking care of it now, I'll push emergency updates
<mdeslaur> rbasak: thanks!
<seb128> apachelogger, not sure we have anyone atm in charge of that, dpm has the access to do it if needed though so you can ping him I gues
<apachelogger> seb128: mh, thanks
<apachelogger> dpm: would be great if you could get the following through https://translations.launchpad.net/ubuntu/trusty/+source/kdesudo/+imports and https://translations.launchpad.net/ubuntu/trusty/+source/kde-config-whoopsie/+imports
<rbasak> Thanks!
<xnox> doko: i think i had "default" versions of tcl-lib / tk-lib, but debian decided it was redundant to have "defaults" versions off those packages, thus "naked/versionless" .so symlinks are provided in the tk-dev / tcl-dev defaults packages in debian.
<doko> xnox, ok, so I'll drop these then, and add a replaces
<hyperair> directhex: lol a month in buildd queue?!
<hyperair> directhex: surely one could make it go faster by using an armhf VM on an i386 machine?
<directhex> https://buildd.debian.org/status/architecture.php?a=armhf&suite=experimental
<hyperair> wtf.
<hyperair> is the queue broken?
<hyperair> i mean are all the buildd's broken?
<hyperair> no wait i see a lot of installed stuff
<hyperair> recently even
<hyperair> oh dear, i see webkit building. that's gonna take a while
<mitya57> hyperair: both armel and armhf are sloowly catching up
<hyperair> slowly eh
<mitya57> Yes, the Qt stack was waiting for about three weeks, and only now it's building
<jamespage> doko, do you have a list of gccgo fixes that have been backported to the 4.8.x version we have in trusty?
<cjwatson> directhex: have you checked with #debian-buildd about that?  More recent stuff has built; that looks like configuration error rather than giant queue to me
<cjwatson> I suspect maybe it's just not properly configured to build experimental, since I see grub2 in Needs-Build too
<directhex> cjwatson, there was a multi-week backlog in sid which has only just cleared
<directhex> sid always takes precedence over experimental afaik
<cjwatson> I see
<doko> jamespage, not an explicit list, just see the README.Debian for the list of patches applied
<pitti> cjwatson: considering the rather large list (http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=base-passwd@packages.debian.org&tag=shell-fallout), would it be suitable to keep that change in unstable for longer than just 5 days?
<robotfuel> Mirv: ping
<cjwatson> pitti: I dunno, I think I've got everything in the archive now
 * pitti grabs debian bug 734740  then
<ubottu> Debian bug 734740 in autopkgtest "test_tmpdir_for_other_users fails because of the base-passwd shell change" [Serious,Open] http://bugs.debian.org/734740
<cjwatson> though I did apparently read past autopkgtest in the codesearch output
 * cjwatson rechecks
<cjwatson> I missed nvi too, fixing that now
<cjwatson> pitti: feel free to ask the release team if you want.  With the exception of autopkgtest, the new RC bugs are in quite minor packages, so I'm not panicking
<cjwatson> ah, nvi is QA-owned, I'll just upload that directly
<pitti> cjwatson: ah, ok; I haven't checked all the bugs for how serious they actually are
<cjwatson> pitti: I tried to triage as I was filing them, so the severities should generally be about right
<pitti> (I guess "medium" importance was not actually intended, just due to the new default :) )
<cjwatson> Right, I probably would've gone for low if I'd thought about it; I'm not used to the new default yet
<pitti> yeah, me neither
<pitti> fortunately I mostly seem to fall into that trap in test suites, so it's not such a biggie
<cjwatson> There were a couple of test suites I didn't report bugs on, but they were in code that wasn't actually run in Debian builds
<cjwatson> I also QA-uploaded gnats
<cjwatson> And I guess I might have missed a few due to line-wrapping, though I think that's relatively unlikely in this case
<ogra_> jodh, i remember at some point seeing a graphical dependency map for upstart jobs, googling doesnt really get me much, do you know of any vizualization tool ?
<jodh> ogra_: man initctl2dot
<ogra_> jodh, perfect ... bad google ... didnt give even a hint
<cjwatson> barry,zul: There's a new python-passlib source in unstable which appears to mostly supersede passlib, although the package in Debian doesn't include Python 3 support.  At least plinth is stuck in trusty-proposed because it needs the new upstream version.  Do you think you could merge all this, preferably switching to Debian's choice of source package name?
<zul> cjwatson:  sure
<cjwatson> thanks
<barry> zul: thanks.  i'm around if you want a review
<zul> barry:  coolio
<barry> zul, cjwatson looks like debian is a minor version behind pypi too
<barry> zul: if you want, after you merge, i can submit patches to deb maintainer for any ubuntu deltas
<barry> (including python3-passlib)
<zul> barry:  ill forward them off
<barry> zul: awesome, thanks
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #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: do you need somebody to sort out the gcc-4.8-arm64-cross build failures?
<doko> cjwatson, that had low prio for me. didn't look at it yet
<cjwatson> I guess I can work around it by forcibly installing the trusty (not -proposed) versions
<leighman> getting Packaging branch status: OUT-OF-DATE for xserver-xorg-intel-package - what should I do?
<infinity> leighman: pull-lp-source xserver-xorg-intel-package
<leighman> infinity: is it likely to be a while before it's fixed?
<infinity> Erm, that would be xserver-xorg-intel, of course, not xserver-xorg-intel-package -
<infinity>                   what should I do?
<infinity> Whee, cut and paste fail.
<infinity> Oh, not even xserver-xorg-intel... Well, whatever you were trying to branch, get the source from the archive instead was my point. :P
<infinity> leighman: Branches can wedge and get out of date.  xnox sometimes looks at that when he's told about it, but the archive is always the authoritative source.
<leighman> yeh, xserver-xorg-video-intel sorry
<infinity> leighman: Looks like that branch hasn't been used since raring.  So, yeah, I'd recommend just using the archive source.
<leighman> infinity: how can you tell that?
<infinity> xnox: lp:ubuntu/xserver-xorg-video-intel seems to have been in a fancy wedged state since ~raring (or early saucy).  Care to work some magic to wipe it out and reimport clean?
<infinity> leighman: Well, the branch has 2:2.21.9-0ubuntu2 in it, the archive has 2:2.99.907-0ubuntu1 ...
<xnox> infinity: i could, if i learn the right amount of magic. as per slangasek i was using too big of a hammer which shattered everything to pieces, beyond repair.
<infinity> xnox: Oh, fun.  Was this in regards to the eglibc hammer you applied for me that didn't actually DTRT according to people who care (ie: not me)?
<xnox> infinity: correct.
<slangasek> xnox, infinity: yeah, requeue-package --full doesn't keep the tag database in sync with the branches, which ensures the next import will fail again
<xnox> slangasek: so what should be done instead?
<infinity> slangasek: What's the correct way to just wipe out a branch history and reset to sane, then?  (I suspect this is often what we want for horribly out-of-date and broken branches)
<infinity> Expecially for ones where it's obvious that the source isn't actually maintained in said branch, just imported on upload.
<hallyn> so where is the best place to find a list of currently valid architectures for ubuntu?  (i.e. powerpcspe)
<infinity> hallyn: powerpcspe isn't an Ubuntu arch.
<infinity> hallyn: Or do you mean valid dpkg arches?
<infinity> hallyn: Current trusty arches are listed at https://launchpad.net/ubuntu/trusty/
<hallyn> oh i'm sorry, i was looking at a *debian* bug.  i thought it was an ubuntu one.  sorry.
<hallyn> infinity: cool, useful, thanks.
<slangasek> infinity, xnox: for that particular import error, I don't know the answer... it's not one of the import failures I know how to fix.  xnox, do you know what that failure actually means?
<infinity> hallyn: For Debian, the answer is muddier, cause you could say "I only care about arches that are in unstable" or "I only care about arches that are in testing" or "I'm not a jerk, and I'll accept patches for any arch that dpkg supports".
<infinity> hallyn: I suspect my wording of those three options highlights my preference. :)
<hallyn> infinity: i'd probably go with the latter, but I suspect mjt will chime in anyway
<infinity> hallyn: For the record, though, powerpcspe is in neither unstable or testing, only on debian-ports, so pretty much every bug regarding it is wishlist.  That said, non-disruptive patches for ports arches are what allows them to eventually get to be primary ones, so I prefer to be nice where I can.
<hallyn> what the heck *is* powerpcspe :)  /me googles
<hallyn> holy cow.  ps3.
<infinity> hallyn: It's a (sadly, ABI-incompatible) PPC subarch for certain SOCs that don't play nicely with standard PPC/POWER.
<hallyn> i had figured it was something new, not something old :)
<infinity> hallyn: And yes, the ps3 is in that list. :P
<hallyn> i remember cell was a  hot thing at ibm 5 years ago or so
<hallyn> or 8
<infinity> hallyn: There are some newer Freescale SOCs that fall in that list too, though the latest and shiniest from them can run standard powerpc/ppc64.
<doko> err, the ps3 runs ppc64 fine. at least it still does on my ps3
<leighman> infinity: basically want an easy way to do a .906 package but looks like that is not to be :)
<infinity> doko: The main core is a standard ppc64 core, Cell is not.  If you want to run on cell instead of the main core, you need ppcspe.
<infinity> Well, I guess the whole thing is called "Cell", but that's a single ppc64 core, and 8 SPE cores.
<infinity> leighman: Take the 907 package in the archive and roll back? :P
<leighman> infinity: yerrrr
<cjwatson> infinity: libtool M-A: allowed - hmm.  This seems to mean we have to change everything that build-depends: libtool to build-depend on libtool:any instead, not too sure what will happen with dh-autoreconf build-dependencies, and we can't reasonably do that until Debian has made the same change because it'd involve a zillion Ubuntu deltas.
<cjwatson> infinity: I can't help thinking that this was totally the wrong trade-off in order to avoid having to fix a tiny handful of packages that care about /usr/bin/libtool.
<infinity> cjwatson: Direct build-deps wouldn't need to change.  I can't see why they would.
<infinity> cjwatson: Some indirect ones might need to, but I'm not actually sure if there'd be many of those, if any.
<cjwatson> infinity: They totally do because otherwise they default to libtool:<foreign> when cross-compiling.
<cjwatson> infinity: http://people.canonical.com/~cjwatson/cross/arm64/trusty/acl_2.2.52-1_arm64-20140109-1652
<cjwatson> And, I expect, a buttload of others in that cross-build run
<infinity> cjwatson: Erm, wha?
<cjwatson> So I fear that this has massively regressed our cross-building
<infinity> cjwatson: build-dep: foo will default to HOST_ARCH.
<infinity> cjwatson: build-dep: foo:any will default to BUILD_ARCH
<cjwatson> Right.  Which is arm64 here, because I'm cross-building from amd64 to arm64.
<infinity> cjwatson: I'd contend that 99% of libtool build-deps want HOST_ARCH.
<cjwatson> Er, hmm, but what are we going to do about the cpp dep then
<cjwatson> We don't want cpp:host
<cjwatson> I'm actually a bit confused about why cpp is M-A: allowed.  Because you might want to find out defines of some other arch?
<cjwatson> Debian #630853
<ubottu> Debian bug 630853 in cpp "cpp: multi-arch: foreign or multi-arch: allowed?" [Wishlist,Fixed] http://bugs.debian.org/630853
<infinity> cjwatson: Oh, I hadn't thought of libtool's deps.  Hrm.
<infinity> cjwatson: Maybe the right answer really is to just drop /usr/bin/libtool entirely.
<cjwatson> The libtool-bin solution avoided this
<infinity> cjwatson: I was just undoing the split in the way that seemed to make most sense, since the split itself is a bit pointless.
<infinity> The libtool-bin solution doesn't really solve anything, does it?  Things that build-dep on libtool-bin still have the same issues (foreign or allowed, whichever one does, each appears to be wrong).  People who install libtool to get /usr/bin/libtool don't.
<infinity> It just moves the problem to another package, it doesn't solve it.
<cjwatson> Another package that hardly anything has to care about, though
<cjwatson> Why does libtool depend directly on cpp, anyway?
<infinity> Well, how is it any different than having libtool itself just be what it was a month ago?
<cjwatson> It doesn't seem to use it ...
<infinity> And fixing things that fail to cross because they incorrectly assume /usr/bin/libtool is for HOST_ARCH.
<cjwatson> libtool was M-A: foreign a month ago, so most things just worked fine because they didn't use /usr/bin/libtool and generated their own one the way you're supposed to.
<cjwatson> If you do what you're supposed to do then you don't care what arch the libtool package is.
<infinity> Sure.  So, we could go back to that.  I actually think "allowed" looked more correct, but I hadn't thought to look at the deps it pulled in.
<cjwatson> libtool-bin could've been M-A: allowed, maybe
<infinity> The MultiArchCross spec certainly implied that allowed would give me the sane behaviour.
<cjwatson> Or even M-A: none
<cjwatson> Dropping the cpp dep alone probably won't help, anyway, since there's still the gcc dep.
<cjwatson> doko: ^- opinions on the above?
<cjwatson> infinity: In fact, doko's split libtool-bin was M-A: none
<cjwatson> infinity: So it didn't have this problem - if you needed /usr/bin/libtool you could b-d on that and you'd get the host version
<cjwatson> infinity: I think the split version was better in every way apart from being "ugly" and meaning that a few packages have to adapt
<cjwatson> infinity: It certainly seems clearly better for cross-building
<cjwatson> infinity: I'm sorry I didn't notice this problem when you were talking about reverting it ...
<infinity> cjwatson: And people.  But meh.  If you want to reintroduce the split, go nuts.  It just seems entirely wrong to install libtool and not get libtool out of the deal.
<cjwatson> Well, the long-term goal AIUI is to drop /usr/bin/libtool
<cjwatson> But having *some* way you can get it is a bit friendlier than that
<infinity> cjwatson: I don't mind a bit of a revert war here.  But following up to the Debian bug with the current state of affairs in Ubuntu and reasoning would also be helpful.
<cjwatson> Yeah, I was just starting that
<infinity> cjwatson: Other than the dependency on cpp, the M-A:allowed thing looked like exactly what the MACross spec would want me to do with a package like this. :/
<doko> cjwatson, for trusty maybe revert the split, and make it foreign again. there are too many build failures for now. I'll summarize these once the main rebuild is finished. but probably not the right time to start fixing all these now
<cjwatson> This is very reminiscent of the abortive M-A: allowed -ing of gettext
<cjwatson> doko: Failures due to missing /usr/bin/libtool?
<doko> yes, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140108-trusty.html is still running with the split package, will try to summarize tomorrow
<cjwatson> doko: Ugh, OK.  That sounds like (as Kurt suggested) we want a targeted test rebuild of just this change.
<cjwatson> doko: The test rebuild of main has 13 hours to go on i386 - how about we revert the split tomorrow?  I can wait until then
<doko> cjwatson, K
<doko> ok
<infinity> Well, the split's already reverted in the archive, it's just allowed instead of foriegn.
<infinity> So, if you revert that too, we're back to square 1.
<infinity> But doko's building against a split PPA version, that's all.
<infinity> (And that would need a revision bump to keep ahead of an archive upload)
<doko> ohh, ppc64el did finish first, even armhf is still running
<cjwatson> Well, not if we decide the split is too much trouble and want to ditch it for the copy archive too
<cjwatson> doko: failures are quick :)
<doko> heh, there aren't that many more
<cjwatson> (Also, as Kurt says, with the split, the libtool package itself could be Architecture: all.)
<cjwatson> infinity: heh, working through the analysis here is interesting
<cjwatson> infinity: it turns out, AFAICT, that if you try to do the "obvious" thing with the split where you make libtool depend on libtool-bin, there's no way to arrange the multiarch annotations so that you actually gain anything useful
<infinity> cjwatson: Indeed.
<sbeattie> doko: FYI, the apparmor libtool failure is bogus, is fixed upstream, and will be fixed in the archive soon.
<xnox> cjwatson: i did not anticipate such libtool fallout. Indeed i have a very "Depends:" centric view of it rather, "Build-Depends:" one as required here.
<doko> infinity, please have a look at the gdb build on toyol. builds since yesterday
<infinity> doko: I assume something's spinning in the background.
 * infinity finds someone to look.
<doko> ok, will ask launchpad operators next time
<directhex> Laney, so we should be able to sync enough stuff to get dbus# to transition in trusty - except for the gtk#3 main issue
<infinity> doko: Just to be confusing, it's lp-ops for x86/armhf/powerpc, and me for arm64/ppc64el (until we get those machines in a sane enough state to hand them over)
<infinity> doko: s/lp-ops/webops/
<Noskcaj> kirkland, Any chance of a testdrive release soonish, since Vbox 4.3 is now in trusty
<kirkland> Noskcaj: yeah, perhaps...have you tested trunk?  are you happy with it?  are there any outstanding merges still waiting?
<bdmurray> arges: just to be clear the openvswitch SRU is meant to supercede the current one in -proposed correct?
<arges> bdmurray: hi. No it fixes the previous 1.4.6 upload
<Noskcaj> kirkland, I'll branch now and do some testing. I think the only other branch is the gtk3 stuff, and really i need you or andres to help with that, since my glade has never worked
<Noskcaj> And gtk3 is a requirement for python3
<arges> bdmurray: sorry yes, it does superceede it
<kirkland> Noskcaj: cool -- let me know if current trunk is good for you, and sure, I'll cut/upload a release
<kirkland> Noskcaj: and we can work the gtk3 stuff after
<Noskcaj> And this release should probably go to debian, if you can set me as the maintainer.
<bdmurray> arges: got it, thanks
<smagoun> cyphermox: hey, just as heads-up that I'm still running your network-manager and I still haven't seen a single 'authentication failed' dialog. By now I would expect to have seen 3 or 4 of them
<Noskcaj> kirkland, testdrive-gtk won't launch locally, but i think that's something i broke by using the setup.py and part of the .deb. If it launches for you, we should be good to go.
<cyphermox> smagoun: cool!
<smagoun> cyphermox: I'll keep this running over the weekend (things always break on weekends - right?) and post an update in the bug on Monday. Does that work for you?
<cyphermox> sure
<cyphermox> I already updated the bug, note that I marked it as a duplicate of another
<cyphermox> I pushed the patch over to upstream, some people started to look at it
<kirkland> Noskcaj: hmm, odd, I'd be very interested to know exactly what's wrong then
<Noskcaj> kirkland, I went normal repo version, testdrive.deb, setup.py, so i've broken a lot of stuff. http://paste.ubuntu.com/6723364/ was my error
<Aaron> wow how sexy it's the python error
<Aaron> hey to who do i speak about a channel?
#ubuntu-devel 2014-01-10
<pitti> Good morning
<pitti> stgraber: still awake by any chance?
<dholbach> good morning
<mlankhorst> xnox: that unity upgrade bug is weird.. what happens when you apt-get install libxi6?
<xnox> mlankhorst: it's all fine actually. and upgrade / install ubuntu-desktop works in a precise chroot.
<xnox> mlankhorst: the user however, doesn't have default priorities - apt-cache policy shows -security pocket at 990, and -updates pocket at 900. By default all should be 900. Thus libxi from "-security" pocket is enforced, breaking the upgrade.
<xnox> mlankhorst: none of the other packages have things in -security for that upgrade =/
<xnox> mlankhorst: i did panic a bit with bug statuses, but now it's all set to incomplete/invalid states.
<mlankhorst> ah
<mlankhorst> xnox: yeah I did test the default case, had a feeling it was something like that ;-)
<xnox> mlankhorst: yeah, it did look suspicious that the bug reporter, knew, and included, apt-cache policy. And it did turn out to look fishy =)
<Laney> directhex: what issue is that?
<Laney> oh
<Laney> I misunderstood the use of 'main' ;-)
<Laney> Can we have gtk-sharp3 promoted please? It's the gtk3 version of gtk-sharp2 which is already in main so I hope we can avoid the MIR.
<Laney> per http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<seb128> Laney, let me have a look
<seb128> why is gnome-panel&co wanting to go to main?
<seb128> oh, indicator-datetime recommends indicator-applet
<seb128> hum, what about lightdm recommending lightdm-gtk-greeter?
<seb128> Recommends: xserver-xorg, unity-greeter | lightdm-greeter | lightdm-kde-greeter
 * seb128 wonders what's happening there
<Laney> seems to be expanding the provides strangely
<doko> mlankhorst, about 1266492, did you see this in a specific package?
<mlankhorst> bug 1266492
<ubottu> bug 1266492 in binutils (Ubuntu) "ld:i386 crashes with -static -fPIE -pie" [High,Confirmed] https://launchpad.net/bugs/1266492
<mlankhorst> doko: xorg-server
<mlankhorst> and the duplicate was a ftbfs for another bug
<doko> mlankhorst, why doesn't these b-d on hardening-wrapper?
<doko> mlankhorst, ^^^
<doko> mlankhorst, looks like xorg-server has some hardening settings, but these are useless because of the missing b-d
<mlankhorst> no idea, it's same as debian
<Laney> directhex: looks like it got promoted
<Laney> thanks seb128 (assuming it was you)
<seb128> Laney, it was, yw
<directhex> so banshee should build, and we can work on the rest of that little tangle
<directhex> Finished 3 minutes ago (took 5 minutes, 32.4 seconds)
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<xnox> seb128: is that's all because of ppc64el/arm64 build-scew. As in on amd64, gnome-palen doesn't want to go in =)
<xnox> s/gnome-palen/gnome-panel/
<seb128> xnox, oh, ok, I didn't even think that could be arch specific ... thanks ;-)
<xnox> seb128: yeah, components-mismatches doesn't tell you that. E.g. I think if unity-greeter would build on ppc64el, it would be all fine.
<seb128> xnox, I see, makes sense now that you say it ;-)
<xnox> seb128: https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1263436
<ubottu> Ubuntu bug 1263436 in unity-greeter (Ubuntu) "unity-greeter fails to build from source on all arches" [High,New]
<stgraber> pitti: nope, but I am now
<pitti> stgraber: bonjour
<pitti> stgraber: apport with your container changes is in; I also fixed the init.d/upstart script for containers, but I'd appreciate a review of the changes from you
<pitti> stgraber: I left some questions/comments in the MP, and filed bug 1267728 for SRUing
<ubottu> bug 1267728 in apport (Ubuntu Precise) "starts/stops in containers" [Medium,In progress] https://launchpad.net/bugs/1267728
<stgraber> pitti: I believe that bug is invalid
<stgraber> pitti: I noticed that behaviour when testing but it's only happening because our current 3.13 kernel is buggy
<pitti> stgraber: oh, you mean containers aren't supposed to be able to change core_pattern?
<stgraber> pitti: once the kernel team fixes our 3.13 kernel to actually apply the apparmor profile as it should, the container won't be able to write core_pattern anymore
<pitti> stgraber: ah, that would do it as well
<pitti> stgraber: oh, it's only apparmor which prevents that, not the kernel itself?
<pitti> stgraber: then I believe the upstream init.d check should stay
<pitti> and we might just revert it from our upstart job
<pitti> but if we don't need to SRU this, so much the better
<pitti> jamespage: ah, openvswitch autopkgtest failure is because our version doesn't support kernel 3.13
<stgraber> pitti: I guess it probably doesn't hurt having the check in the upstart job anyway (in case someone runs their container with lxc.aa_profile = unconfined)
<stgraber> pitti: though on Ubuntu, you really want to use running-in-container rather than a direct check of pid 1's environment
<pitti> stgraber: ah, ok
<pitti> stgraber: right, I thought of that after I hit dput..
 * pitti commits that change to avoid forgetting it
<jamespage> pitti, indeed
<jamespage> apw and I already discussed - I've reported that upstream; I've got inflight patches being reviewed upstream for 3.12; once those have landed, can look at 3.13 :-)
<jamespage> for now we can drop the dkms package; they don't add much with 3.13
<pitti> stgraber: (done)
<apw> stgraber, a new 3.13.0-2 is building in the CKT ppa which should have the reguiste AA bits
<pitti> jamespage: ah, we ship the driver in our kernel now?
<jamespage> pitti, feature parity between the in-tree ovs module and the dkms module is almost 100% now
<jamespage> the in-tree lack LISP tunnelling support (but that's pretty experimental)
<stgraber> apw: cool, thanks!
<apw> stgraber, if you are able to test all the better
<stgraber> pitti: thanks for reviewing/merging that change, it took around a year longer than I anticipated to land this but it's great to finally have it :) (my kernel patch took quite a while to get merged upstream...)
<stgraber> apw: sure, I'll grab it from the PPA and do a quick test here
<apw> the signed bits are still pending publication
<apw> oh notg that they are any use :)  being signed with the wrong key
<stgraber> right, if they were signed they wouldn't boot here, thankfully our grub is still happy to boot unsigned kernels
<pitti> oh, is it?
<pitti> that means, if I alter the kernel image and grub would refuse it, the only thing I'd need to do is to remove the .signature file?
<pitti> err, .signed
<stgraber> yeah, grub will let you boot unsigned kernels on EFI but in that case will call ExitBootServices() before entering the kernel
<stgraber> however if a kernel is signed with an invalid key, it won't boot
<pitti> ah, I was hoping that once I turn that on, no unsigned/wrongly signed kernel would ever boot any more
<cjwatson> I'll probably stop allowing unsigned kernels once all the MOK stuff is properly integrated
<stgraber> it's not a standalone signature file, it's inline, but yes, you can use sbattach to remove the signature
<cjwatson> so that it's easy for users to authorise their own kernels
<pitti> it's inline? what is /boot/vmlinuz-3.13.0-1-generic.efi.signed then, just an informational copy?
<cjwatson> pitti: the unsigned kernel won't be allowed *to execute code in boot-services context* - important distinction
<pitti> oh, I see, it's big enough to *be* a kernel
<pitti> I thought it was just a tiny file a few months ago, apparently I mislooked
<pitti> thanks for the heads-up
<stgraber> and yeah, MOK + disallowing unsigned binaries is the right way forward, once we have all the tools needed to easily generate a new signing key and having it added in the nvram variable
<apw> pitti, the signature is carried as a tiny file in the binary package and added to a copy of the kernel on installatin
<stgraber> apw: based on my 30s test, your new kernel looks good
<stgraber> apw: boots fine, apparmor reload no longer complains and I can't trivially destroy my host from a container
<pitti> apw: ah, thanks; so back then I was probalby looking at /usr/lib/linux/vmlinuz-3.13.0-1-generic.efi.signature
<apw> stgraber, great, i'll get the security tests run on it,then let it out
<pitti> stgraber, apw: cheers, closing the precise task in bug 1267728 then
<ubottu> bug 1267728 in apport (Ubuntu Precise) "starts/stops in containers" [Medium,In progress] https://launchpad.net/bugs/1267728
<pitti> and I made such a nice SRU test case/info..
<pitti> but it's pretty much the same test case for verifying that kernel :)
<stgraber> pitti: ah yeah, I also checked core_pattern
<stgraber> root@p1:~# echo 1 > /proc/sys/kernel/core_pattern
<stgraber> -bash: /proc/sys/kernel/core_pattern: Permission denied
<pitti> nice
<stgraber> (my original test was writing to the uevent handler which if not blocked lets you run code as root on the host)
<pitti> stgraber: I didn't think of that at first, that gave me a big "WTF??" this mornign when testing your branch :)
<pitti> (because apport didn't behave as I expected it to, as the container startup ate the new %P)
<stgraber> haha, yeah, I had the same happen to me a couple of times when working on the branch :) I guess I should have mentioned it in the MP
<directhex> can the ubuntu archive manglers delete a package from trusty to help a transition, whilst keeping the source package in place, such that the source package can be fixed at a later date? like deletion from testing in debian?
<kentb> how long does it normally take for a package to move out of the Trusty upload queue?  Namely, I'm waiting for sblim-sfc-common.
<cjwatson> directhex: there are a few different tactics for that.  the nearest analogue is demoting it to trusty-proposed
<cjwatson> kentb: new packages need manual review, expected time would be days
<cjwatson> (I can't promise to look today, sorry)
<kentb> cjwatson: ok. np.
<directhex> cjwatson, basically i don't expect to fix monodevelop-monogame for a month or two (due to upstream release schedule), and it's apparently a blocker on mono transition
<cjwatson> directhex: I can only do this at a source package level.  Can you confirm that it's OK to demote all of monogame?  If so could you give me a brief log message I can use for the demotion?
<cjwatson> directhex: also, if you could please file a bug against monogame in Ubuntu with the "block-proposed" tag, that'll stop it immediately going back in after I demote it
<directhex> cjwatson, demoting the whole source package is fine. can i file a bug against cjohnston for overloading my cj<tab> irc usage?
<cjohnston> 1, 2, 3<tab>
<Laney> YEAH
<directhex> ok, bug 1267892 filed
<ubottu> bug 1267892 in monogame (Ubuntu) "Does not build against MonoDevelop 4" [Undecided,New] https://launchpad.net/bugs/1267892
<cjwatson> directhex: if I could, I would
<cjwatson> directhex: ok, demoted
<cjwatson> (https://launchpad.net/ubuntu/+source/monogame/+publishinghistory)
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mdeslaur> mpt: think we could reconsider not having a close button in the window title on this dialog: http://i.imgur.com/qlScVX7.png
<mdeslaur> mpt: seems to be a common complaint from users
<mpt> mdeslaur, that would be temporary, because Mir+Unity8 will never have close buttons on dialogs. However, that particular dialog is missing a âRestart Laterâ button (bug 1033226).
<ubottu> bug 1033226 in update-manager (Ubuntu) "No close option, only restart" [Medium,Triaged] https://launchpad.net/bugs/1033226
<mdeslaur> mpt: ah! cool...I'll read through that and will poke at this this weekend. Thanks!
<jdrab> mdeslaur: btw you can close that "restart to finnish" window from software updater
<mdeslaur> from software updater6
<mdeslaur> ?
<jdrab> yes
<jdrab> :D
<jdrab> i don't know how it's called that compis effect but if you "display all windows"
<jdrab> there is that little ugly close button there
<jdrab> on that window
<mdeslaur> well, you can also simply right click the launcher too
<jdrab> 2 clicks. vs one :P
<mdeslaur> ok, unassigning myself, too much work to implement
<wadechandler> Has anyone here ever done any dev work with unity (assuming at some point certainly that answer is yes)? i.e. ever took your reg dev box, built it, replace your running version with the one you are deving, then reverted back when done? I just want to provide a patch which I think should be fairly simple to sort out on multiple displays, but have yet to work on it nor much anything else in Ubuntu land. I'm wondering if th
<sarnold> wadechandler: you were cut off at "wondering if th"
<dobey> wadechandler: btw, #ubuntu-unity is a channel specific to unity development
<wadechandler> I'm wondering if there are any tutorials on the topic: 1) I can get the source (easy enough) 2) how to take a built set of outputs and install them, and then 3) how to revert all that back. I know I can use a VM and do that, but seems like over kill for a few things; yes I know I can kill my current OS by being an idiot :-)
<wadechandler> silly client didn't chop it for me...must need a new client other than pidgin
<wadechandler> thanks dobey
<sarnold> wadechandler: there's nothing that gaurantees package downgrades will work; in my experience they usually do work, but some things are just easier done in a VM first :)
<wadechandler> thanks sarnold; for some things I would totally think that, but in the case of multi monitors it can be tricky because of vid cards etc, but I should give it a shot that way anyways :-( I'm just lazy :-P
<wadechandler> thanks
<sarnold> wadechandler: cool :) have fun
<brainwash> doko: hey, so the new bash upstream version is now available in debian experimental (4.3~rc1-1). would it be possible to setup a PPA for ubuntu to provide this new version? I assume that some changes are needed to make it work properly in ubuntu, right? if no, I could try the debian package
<dobey> did the required patch level (-p option to patch) change for quilt packages in dpkg in trusty?
<slangasek> quilt patches are always -p1 by default unless otherwise specified in the series
<dobey> that's what i thought, but the patch i just created, won't apply, :-/
<dobey> http://pastebin.ubuntu.com/6729042/ is what i'm getting
<slangasek> is ubuntuone/devtools/testcases/tests/test_squid_testcase.py present in the upstream source?
<slangasek> dpkg doesn't appear to be objecting to the patch, the patch simply doesn't apply
<dobey> hrmm, it seems to not be in the bzr tree for some reason
<dobey> and indeed is not in the tarball
<dobey> wtf
<infinity> dobey: bzr add? :P
<dobey> infinity: no. none of the tests are in the tarball it seems. not sure why or when they stopped getting picked up by python during sdist. will have to figure it out later :-/
#ubuntu-devel 2014-01-11
<Fudge> is gnome-session responsible for the session-manager logout screen?
<directhex> Laney, tomboy in trusty > in debian - can you handle dbus#2 on it?
<directhex> baby getting in the eay today
<dufa> join #ubuntu-on-air
<dufa> uups
<juliank> Logan_: I see that you are mass bug filing over in the Debian BTS, (about to) ignore developers reference 7.1.1
<Logan_> maintonly?
<juliank> Yes, it says you should write to maintonly, at least if you're continuing at that rate, otherwise bug mailing list ends up with many emails from you.
<juliank> I don't know how many bugs you are about to report, but if they are more than ten, I'd have expected a mail to debian-devel first.
<juliank> If a really large number of packages is affected, it might have made more sense to add a lintian check or something similar first, and wait before reporting the bugs.
<Logan_> Hmm, okay. I'm submitting Ubuntu deltas using submittodebian for fixing FTBFSes on ppc64el.
<Logan_> I tend to fix a good amount, maybe ten, and then I submit them all to Debian.
<Logan_> I don't think submittodebian lets me write to maintonly... :/
 * Logan_ pokes bdrung and xnox ^
<juliank> Logan_: You could add "maintonly" to your reportbugrc before using it, and remove it when you're done with the batch
<Logan_> I'm wondering if there's a way for me to pass options to reportbug with submittodebian.
<Logan_> Something like $ submittodebian -- --maintonly
<bdrung> you probably have to look at the source code (if the man page does not tell you)
<Logan_> Okay, I'll take a look. I'll do what Julian suggested otherwise.
<Logan_> juliank: Thanks for the heads up!
<Noskcaj> Could someone take a look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/libgweather/3.10.1/+merge/200210 ?
<Logan_> Looking.
<Logan_> Oh, that's in main.
<Logan_> Can't do that. :P
<Noskcaj> Logan_, Since you always seem so willing to put up with my requests, xubuntu needs a new terminal version. https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-terminal/0.6.3/+merge/200151
<Logan_> Well, I did merge your last xfce4-terminal.
<Logan_> So it only seems right.
<Noskcaj> ty
<Logan_> Noskcaj: dpkg-source: info: local changes detected, the modified files are:
<Logan_>  xfce4-terminal-0.6.3/terminal/terminal-encoding-action.c
<Noskcaj> Stange. I looks like that somehow got deleted. One second
<Logan_> cjwatson: I know I'm not supposed to file bugs for removing Ubuntu packages without deltas that were removed from unstable, but I was going through the list, and there are a number of packages for which I can't figure out why they haven't been removed yet. Mind if I prod you about them?
<Noskcaj> correct, one hour. stupid, slow internet
<Noskcaj> Logan_, That file is here locally. I think bzr merge might have deleted it for you
<Logan_> No, it wasn't deleted. There were changes to it.
<Noskcaj> Also, meld says it's identical. Try just getting my branch and building from it
<Logan_> Noskcaj: Okay, I'll try that.
<Noskcaj> ty
<cjwatson> Logan_: process-removals checks for seededness and reverse dependencies, and I'll often defer removals in those cases.  feel free to prod me and I can look into whether it's some kind of systemic problem or what
<Logan_> cjwatson: Okay, so, automake1.7 for example. Removed from unstable back in August 2012, no rdeps or rbdeps, and not seeded.
<cjwatson> Logan_: oh, that's probably just that it took ages for all the rbdeps to go away and I only very occasionally retry it for removals that far back
 * cjwatson runs "process-removals -d 2012-01-01"
<cjwatson> also I tend to think a bit harder about anything with Ubuntu modifications (not that that applies in this case), since that might imply specific interest by somebody in Ubuntu
<Logan_> Gotcha.
<Logan_> ant1.7 is another one on my list that I've been compiling. Has two rbdeps, but they're both alternates.
<cjwatson> Yeah, I just got to that.
<cjwatson> About to remove it
<cjwatson> Logan_: Anyone can run process-removals from lp:ubuntu-archive-tools to see the logic it uses, even if only AAs can do the actual removal; so if you fancy making it less slow and unreliable, and maybe figuring out how we could track the delta better ...
<cjwatson> (ant1.7 and automake1.7 removed now)
<Logan_> I will look into that. :)
<cjwatson> Possibly better than you writing your own thing :)
<cjwatson> process-removals really hasn't had more than, um, emergency love
<Logan_> cjwatson: Wait so...
<Logan_> process-removals goes through all removals from all time?
<cjwatson> Logan_: I generally pass -d
<cjwatson> for something vaguely recent
<Logan_> Yes, but I feel like there are so much more efficient ways to do this.
 * Logan_ ponders.
<cjwatson> It's not very satisfactory
<cjwatson> I've never had the effort to rewrite it
<Logan_> I might make this a project for myself.
<cjwatson> It'd certainly be great for somebody to improve this; I think I would call it the piece of the archive tools that needs most attention
<Logan_> I think it could benefit from some kind of joining of Ubuntu and Debian's removals.
<cjwatson> IIRC Scott mostly wrote it while avoiding a team-building event, and then everyone else has just hacked it as they went :-)
<Logan_> Also, I feel like Debian has to improve whatever script is generating that list.
<cjwatson> Ubuntu's aren't exposed as a stream in the same way
<cjwatson> I think Debian actually publishes deb822 removal files nowadays
<cjwatson> But I haven't checked whether the data matches up and converted process-removals to it
<cjwatson> That alone would be an improvement if possible
<Logan_> Okay. I'll look into maybe converting the script to look at those.
<Logan_> I have a good amount of Python knowledge, and this would be good practice. :P
<cjwatson> It also has a problem where it tries to read the removals files incrementally, but sometimes this means that it times out in the middle of a giant run
<cjwatson> It's all rather frustrating
<cjwatson> Anyway, must go
<Logan_> Alright, have a good one!
<Logan_> Or maybe it could hook into MultiDistroTools.... Hm.
<Logan_> Because the only removals we really care about are the ones that are currently in Ubuntu and not in Sid.
<Logan_> That's something maybe you and wgrant could discuss.
<wgrant> My mdt stuff used to do removal checking, but I think that's broken nowadays.
<wgrant> Or we're up to date on Debian removals, but that seems unlikely.
<stgraber> win 42
<infinity> Logan_ / juliank: FWIW, I don't consider bugs with patches attached to be "mass bug filings", even if there are lots of bugs with similar topics.
<Logan_> Yeah, that's the way I felt as well. But I'm not sure.
<infinity> Logan_ / juliank: A muss bug filing is things like "we ran an automated checker on the archive and found 259 packages to be buggy, yours is one of them".
<Logan_> So I shouldn't write to maintonly, right?
<infinity> Logan_: IMO, no.  You're just filing bugs rapidly because you're fixing bugs rapidly, that't not the same as reporting en masse without fixes.
<infinity> Logan_: And people who watch bugs-dist for patches they could sponsor or NMU might be interested in seeing your bugs, while they probably don't care about seeing 300 identical bugs with no patches.
<Logan_> Good point.
<juliank> infinity: Well, if he reports let's say 250 bugs in batches of 10 each, I'd consider that a mass bug filing, or at least close too, and I would ask before doing it.
<juliank> But I don't really care that much (I only noticed it, because I my IRC client notifies me whenever someone mentions dh-autoreconf somewhere, and the bugs do, and I see them in #debian-devel-changes).
<juliank> I'd like to know before someone introduces support for a new architecture in packages.
<juliank> At least a short notice would be nice. I also don't see anything on debian-powerpc@l.d.o, and I think it would be reasonable to write something to them before doing this.
<Logan_> juliank: I'm afraid I don't understand. Am I supposed to get permission before fixing FTBFSes on new architectures?
<infinity> juliank: debian-powerpc has nothing to do with this, really.
<infinity> And, yeah, I don't see why anyone would need notice before including support for a new arch.
<infinity> (And, in the case of most of these, it's just generic future-proofing, not necessarily just for one arch)
<infinity> Logan_: Wow, that dsc-statistics failure is... Weird.
<Logan_> Tell me about it.
<Logan_> That's the "changed too much" one, right?
<infinity> Yeah.
 * Logan_ shrugs.
<Logan_> I personally would never use wdiff to determine whether or not a package will fail to build. :P
<infinity> Seen on m68k too.
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699917
<ubottu> Debian bug 699917 in src:dsc-statistics "dsc-statistics: FTBFS: too many changes in docs since release, .orig.tar.gz repackaging needed" [Important,Open]
<infinity> Bizarre.
<infinity> I might look at that one later out of sheer curiosity.
<juliank> Well, for one thing, it is a bit uncoordinated this way. Now you have multiple bugs adding ppc64el support, and no way to find them. That's why I proposed contacting someone before, so that amongst other thing maybe the bugs can get a proper usertag saying that they are ppc64el bugs.
<Logan_> Okay, I see where you're coming from on that side of things.
<infinity> juliank: The way to coordinate them would be with usertags.
<juliank> That's what I wrote.
<infinity> No need to contact anyone in advance to create a tag.
<juliank> Right, but clearly nobody thought of this yet...
<infinity> But, like I said, most of these are actually generic.
<infinity> At least, the autotools-dev and autoreconf ones are.
<infinity> It's just generic "please future-proof your packaging" not "please add support for an arch".
 * infinity shrugs.
<Logan_> For the config.{sub,guess} ones, I just say "please use autotools-dev to update config.{sub,guess} for new arches"
<juliank> infinity: Most packages explicitely do not use dh-autoreconf by default, they only use it, when they change files.
<Logan_> Because it's not limited to ppc64el and arm64 support. Future rebuilds will allow support for more arches.
<infinity> juliank: I know that.  I also tend to agree with Colin on this point that that's wrong.
<infinity> juliank: autoreconf on build is a *good* thing.  It makes sure the source actually works.
<infinity> (Even outside the new arches argument)
<Logan_> infinity: Have you seen the bug in Debian about doing autotools-dev and/or autoreconf by default?
<infinity> Logan_: No, but I'd disagree with that.
<Logan_> Same here. It creates too much overhead for package maintainers, especially if the package doesn't need libtool and/or config.{sub,guess} updates.
<Logan_> But...
<infinity> Logan_: Well, not sure I'd disagree with autotools-dev by default, but autoreconf needs fiddling too much to do it without testing.
<Logan_> I think that it's not harmful to do autoreconf if it fixes an FTBFS on new arches.
<Logan_> And to continue using it into the future until upstream updates its own files.
<Logan_> But it should be done on a case-by-case basis.
<Logan_> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733045 if you want to jump in. A Debian maintainer sent it to me.
<ubottu> Debian bug 733045 in debhelper "debhelper: Can debhelper make autotools-dev updating default behaviour?" [Wishlist,Open]
<infinity> Logan_: Nah, that report's just about autotools-dev, not autoreconf (despite a short derailing in the conversation), I'm totally fine with that.
<infinity> Updating config.{sub,guess} automagically has pretty much proven to be 100% harmless.
<infinity> Maintainers should, however, be invovled in choosing to autoreconf, and testing that it works when they do.
<Logan_> Especially as new autotools versions come out.
<infinity> Well, that too, but I was thinking the part where you might need --foreign, or to feed it a subdir argument, etc.  It's not easily detectable how to do it right automatically without some fiddling.
<juliank> Anyway, I'm leaving now.
<juliank> I don't want to spend my night discussing things
<Logan_> I've clearly wasted every night of my life.
<Logan_> I wish the FTBFS report sorted by dependency level. As in, the packages that are most depwaited show up at the top.
<Logan_> It would make it easier to clear out this ppc64el mess.
<infinity> Logan_: That might be a handy thing to try to create.  Could also be a nightmare. :)
<infinity> Logan_: I assume there are still some arm64 dep chains to unwind too (though, most of your fixes are probably getting both at once).
<Logan_> I'm targeting all of the lib* packages first because I figure those will be the most depwaited.
<Logan_> Although a number of shared libraries don't have source packages that start with "lib." :(
#ubuntu-devel 2014-01-12
<Noskcaj> I'm trying to merge xchat-gnome, do i really have to list all of the ubuntu delta?
<slangasek> you should detail what changes you're dropping as part of the merge and what changes you're keeping, yes
<Noskcaj> There goes the next hour of my life
<Logan_> Noskcaj: Yes. As unfortunate and annoying as it is.
<Noskcaj> The changelog takes up my entire screen just for the remaining changes
<jtaylor> you don't need to keep the rebuild lines :)
<Noskcaj> jtaylor, that's without the rebuild lines
<Noskcaj> now if this FTBFSes, i'm going to cry
<jtaylor> updating the changelog is usually the faster part of merging
<jtaylor> build it first, then update the changelog
<Logan_> Yeah. I usually just write "Merge," then build, and then do the changelog if it works.
<Logan_> And, yes, I have accidentally uploaded merges with just "Merge" in the changelog in the past due to this. :P
<jtaylor> often its just copy paste the old message, add new ones and then drop what you dropped during the merge
<jtaylor> make sure its complete
<jtaylor> future mergers will thank you
<Noskcaj> Is anyone here a DD? Could you review http://mentors.debian.net/package/testdrive ? It's an ubuntu program, but i'm sure someone in debian would like to use it.
<Logan_> Noskcaj: I'm pretty sure it shouldn't be native.
<Logan_> Unless the team is planning on maintaining it in Debian...
<Noskcaj> Logan_, Yes, i'm part of the team. it should be.
<Logan_> Okay.
<Noskcaj> How would i fix http://paste.ubuntu.com/6735963/ ?
<Logan_> Noskcaj: Which package is that?
<Noskcaj> Logan_, xchat-gnome
<doko> directhex, when do you plan for mono to migrate to trusty?
<brainwash> doko: hey, do you consider setting up a PPA for bash 4.3 rc1? or is it possible to install the debian package on a ubuntu system without running into trouble?
<doko> brainwash, did you check https://launchpad.net/ubuntu/+source/bash, other versions?
<brainwash> doko: oh, I did not =S
<brainwash> thanks :)
<brainwash> doko: sadly the i386 package failed to build
<doko> infinity, https://launchpadlibrarian.net/162258611/buildlog_ubuntu-trusty-ppc64el.python2.7_2.7.6-5_FAILEDTOBUILD.txt.gz
<doko> dh_shlibdeps -a
<doko> dpkg-shlibdeps: error: no dependency information found for /lib/powerpc64le-linux-gnu/libpthread.so.0 (used by debian/libpython2.7-stdlib/usr/lib/python2.7/lib-dynload/future_builtins.powerpc64le-linux-gnu.so)
<directhex> doko, have been trying to work through the migration blockers
<directhex> as & when my schedule allows
<directhex> the problems report is a little difficult to parse, mind you
<cjwatson> looks like basically banshee and tomboy now
<directhex> yeah, banshee is going to be a problem. banshee itself is migrate-able, and it's beta for the new gtk3 version. but the banshee-community-extensions package has not been updated to gtk3 yet, so right now a) it ftbfs and b) the binaries are useless
<directhex> i'll do tomboy though
<directhex> a hyperair would be handy at this point
<doko> directhex, banshee-community-extensions doesn't have any reverse dependencies, so we could demote it to -proposed
<directhex> doko, huh, i thought the amazon/u1ms plugins were in b-c-e. apparently not
<directhex> i'm test building a patched tomboy in a ppa, will upload it if it works
<directhex> build would have failed by now if it was going to
<hyperair> directhex: uh yeah i'll get to it.
<hyperair> hang on, a gtk3 bce hasn't been released
<directhex> hyperair, nope. mass porting effort needed upstream, i think :/
<hyperair> yeah
 * hyperair groans
<hyperair> that'll take a while
<hyperair> how about the dbus# stuff? is that all taken care of?
<directhex> yeah, transition complete in sid
<directhex> and in theory in trusty-proposed now
<hyperair> oh cool nice
<directhex> cjwatson, doko, ok, tomboy all built. if b-c-e gets demoted, that *should* be everything?
<directhex> YMMV. IANAL. IDDQD.
<doko> directhex, what about tangerine?
<doko> and libapache2-mod-mono?
<directhex> doko, i don't see why those are blocked from transition
<cjwatson> doko: you're looking at the wrong update_output block, I suspect.
<doko> meh
<cjwatson> doko: Look at the *first* one mentioning mono after the initial one-by-one pass.
<cjwatson> Which looks like b-c-e, tomboy, and rdeps.
<doko>     * amd64: banshee-extension-lastfmfingerprint, banshee-extension-lirc, banshee-extension-mirage, tomboy
<doko>     * armhf: banshee-extension-lastfmfingerprint, banshee-extension-lirc, banshee-extension-mirage, tomboy
<doko>     * powerpc: banshee-extension-lastfmfingerprint, banshee-extension-lirc, banshee-extension-mirage, tomboy
<doko> FAILED
<doko> right
<doko> and what do the following ones describe?
<cjwatson> That's p-m trying different subsets
<cjwatson> Sometimes that succeeds where the biggest set doesn't, e.g. if it pulls in fewer transitions
<cjwatson> I haven't bothered inhaling the full algorithm since I don't usually need to care
<directhex> cjwatson, like i said, fixed tomboy should be built & waiting in -proposed, and b-c-e can be demoted to ease transition
<directhex> if that fixes it, hooray
<xubuntu928> while installing i've noticed that i get a notice concratulations you have chosen to install xubuntu 13.10 however it's the 14 alpha language is dutch
<xubuntu928> not sure if this is an known issue, it's ofcourse a minor issue
<xubuntu928> however where can i findout or report such things
<Ofloo> joy, .. i can see it's installing english help files however i've chosen the language to be dutch
<Ofloo> nevermind my earlier remark
<Ofloo> now it's downloading the dutch help files
<Ofloo> man i hope this is going to work my r9 card driver only support up to kernel 3.12 i see it's installing 3.13
<cjwatson> directhex: looks like doko did that
<cjwatson> directhex: and mono is transitioned, yay
<cjwatson> thanks for your work
<directhex> oof, that was painful
<directhex> hooray though
<directhex> would have been hella embarrassing to ship 2.10 in *another* release
<stgraber> xnox, hallyn: FYI I'm just making sure I handle upgrades properly and will upload http://paste.ubuntu.com/6739735/
<stgraber> I noticed that one because I monitor "debsums -sa" on my servers and just noticed that 14.04 boxes report subuid and subgid as modified conffiles...
<hallyn> stgraber: thanks - i guess that should go up to the debian pkg as well
<stgraber> hallyn: I don't think Debian has support for it yet, it looks like an Ubuntu change at the moment.
<stgraber> alright, got some transition code working to clear the conffile flag on existing installs, we should only have to carry that bit until 13.10 goes EOL so not too painful. Uploaded
<infinity> doko: I see that succeded on a retry.  Did something else get changed to "fix" it, or was it a weird transient error?
<infinity> jibel: What's going on with the linux autopkgtests?  That looks like testbed explosion, not test failures.
<Ofloo> hi, .. installed xubuntu 14 but wen i run compiz i get compiz (core) - Error: Plugin 'opengl' not loaded.
<Ofloo> i did downgrade the kernel to 3.12 due to videocard driver issues
<Ofloo> an other thing i've noticed is that when plug in an usb stick it doesn't automount
<Ofloo> i had the same issue in 13.10
<Noskcaj> Ofloo, Try #ubuntu or #xubuntu
<infinity> doko: Ahh, looks like the system somehow got wedged and dpkg/dpkg-query were segfaulting.  Weird.  Cleared up now.
<YOURBESTFRIEND> shit guys
<YOURBESTFRIEND> I'm trying to fix some bug
<YOURBESTFRIEND> but I can't
<YOURBESTFRIEND> where can I get help
<TJ-> YOURBESTFRIEND: In #ubuntu where we were already helping you
<Noskcaj> Can someone try and work out what's causing https://code.launchpad.net/~noskcaj/ubuntu/trusty/xchat-gnome/merge to ftbfs?
<Laney> directhex: it needs applying to exp
<directhex> what does?
<YOURBESTFRIEND> isn't there like some menthoring program for newbies?
<Laney> tomboy
<Laney> new upstream, dbus#2 patch
<Laney> unless it's already in that version, in which case nothing to do
<directhex> Laney, i didn't think to look in exp, since trusty package is 0ubuntu1
<directhex> yeah, you're right
#ubuntu-devel 2015-01-05
<pitti> Good morning, and happy new year!
<didrocks> thanks for the grub upload cjwatson :)
<pitti> didrocks: very nice!
<cjwatson> didrocks: yw
<dholbach> good morning
<MacSlow> dholbach, hey there... happy new year btw :)
<MacSlow> dbarth, ^ :)
<dholbach> hi MacSlow - and the same to you too :)
<dbarth> MacSlow: thanks Mirco :)
<dbarth> good morning, and best wishes for 2015 everyone
<MacSlow> dito
<zyga> good morning :)
<mlankhorst> morning
<mardy> seb128: hi! Could you please have a look at bug 1406571?
<ubottu> bug 1406571 in shotwell (Ubuntu) "Shotwell FTBFS in vivid" [Undecided,New] https://launchpad.net/bugs/1406571
<seb128> mardy, sure
<darkxst> Laney, your piloting later today? can you look at bug 1399047
<ubottu> bug 1399047 in gnome-themes-standard (Ubuntu) "Update gnome core packages to 3.14" [Wishlist,In progress] https://launchpad.net/bugs/1399047
<Laney> ok
<Laney> can't you upload shell?
<darkxst> Laney, I can upload shell and mutter, but they will just be dep-wait
<Laney> well if you've already reviewed them :-)
<darkxst> ok, will upload now
<Laney> seb128: did you look at that shotwell bug yet? I just came across it & started
<Laney> then saw that ping ;-)
<seb128> Laney, https://launchpad.net/ubuntu/+source/shotwell/0.20.2-0ubuntu2
<Laney> nice!
<seb128> Laney, seems like I forgot to dput before holidays
<Laney> how convenient
<seb128> I meant to upload when I did the SRU
<seb128> yeah...
<dholbach> 98 requests on http://reqorts.qa.ubuntu.com/reports/sponsoring/ - please help sponsoring/reviewing!
<seb128> dholbach, nice to see some contributors have been busy during holidays ;-)
<dholbach> yeah :)
<dholbach> After I got my inbox under control again I'm going to help out with some reviews as well. :)
<seb128> dholbach, same here
 * dholbach hugs seb128
<cyphermox> good morning!
<LocutusOfBorg1> thanks again pitti :)
<LocutusOfBorg1> good morning and happy new year developerz!
<Laney> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
 * Laney straight away finds a transition and screams
 * rbasak syncs bind9
<rbasak> "syncpackage: Please wait for the sync to be successful before closing bugs."
<rbasak> Define "successful". Migrated to vivid?
<dobey> anyone else having problems writing a live image to usb on 14.04 (or 14.10) with 3.16 kernel? dd exits real quick and the device seems to keep writing for some time after that, but i'm having trouble booting from the usb
<pitti> rbasak: appears on Launchpad, i. e. "last upload:" on its +source page
<pitti> who does SRU these days? https://launchpad.net/ubuntu/utopic/+queue?queue_state=1 hasn't been processed since start of December
<rbasak> pitti: thanks. That's much quicker then :)
<pitti> rbasak: yeah, it should be almost instantaneous
<dobey> i guess not :(
<hallyn> xnox: happy new year!  when you get a chance, could yo ulook at http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.6-1.dsc ?
<xnox> hallyn: upload missing changelog entries for 1:0.2.4-3, 1:0.2.4-2, 1:0.2.4-1 from experimental, they should be included if you are including those changes (looks like you are)
<xnox> there is spurious reorder of build-depends (not sure if that is intentional)
<xnox> spurious diff in debian/rules.
<xnox> hallyn: overall seems fine for upload.
<xnox> and can be claimed that all of the above was intentional.
<hallyn> xnox: hm, i'll have to re-check.  i don't recall doing thos eon purpose.  thanks.
<xnox> hallyn: note, i did debdiff of latest experimental and your upload, rather than latest sid vs your upload.
<bdmurray> seb128: FYI, the amd64 retracing queue is only a few hours behind now and has been for the past couple of weeks.
<seb128> bdmurray, hey, happy new year!
<seb128> bdmurray, great ;-)
<bdmurray> roaksoax: in bugs 1382632 and bug 1386275 what release did you test with? was it utopic, trusty, or both?
<ubottu> bug 1382632 in curtin (Ubuntu Trusty) "Insecure key file permissions" [High,Fix committed] https://launchpad.net/bugs/1382632
<ubottu> bug 1386275 in curtin "failure with utopic level lsblk. should use --output, not --out." [High,Confirmed] https://launchpad.net/bugs/1386275
<roaksoax> bdmurray: both!
<bdmurray> roaksoax: it'd help the SRU team if that was specified.
<Laney> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Noskcaj> Could someone please fix bug 1129409 for amd, even if it's only a PPA?
<ubottu> bug 1129409 in fglrx-installer (Ubuntu) "Nvidia and AMD graphics drivers should indicate whether they provide libcuda.so.1, libOpenCL.so.1, etc." [Medium,In progress] https://launchpad.net/bugs/1129409
<hallyn> xnox: pushed a new version.  not sure why the experimental version never moved to unstable (and/or why they diverged)
<kirkland> I'm doing an apt-get update on a 14.04 system, and strangely it looks like I'm trying to talk IPv6, which is not what I expected....
<kirkland> 57% [Connecting to archive.ubuntu.com (2001:67c:1360:8c01::19)] [Connecting to
<stgraber> kirkland: pastebin "ip -6 addr show" and "ip -6 route show" ?
<kirkland> stgraber: http://paste.ubuntu.com/9678555/
<kirkland> stgraber: http://paste.ubuntu.com/9678559/
<stgraber> are you with time warner cable?
<stgraber> if so, looks like they're giving you some native IPv6 which is quite nice if it worked :)
<kirkland> stgraber: yep, that's my home provider
<hallyn> heh, yes, quite nice if it worked :)
<amayra> hellp
<amayra> i mean hello
<sladen> hallo
<amayra> i love you work thanks for being so kind to offer ubuntu for free and open source
<amayra> i just come here to ask about were can give some suggestion for you
<shadeslayer_> pitti: hi there, when running autopkgtests, do you reckon it would make sense to export some standard variables like HOME, XDG_* , etc so that tests that write files to those locations can proceed without issues? In a whole bunch of KF5 and Plasma 5 tests, I've had to manually export dirs in each of the tests which is super annoying ...
<bdmurray> stgraber: bug 1355664 has a patch fwiw
<ubottu> bug 1355664 in ltsp (Ubuntu) "ltsp-build client fails for armhf (linux-image-omap4)" [Undecided,Confirmed] https://launchpad.net/bugs/1355664
<jtaylor> doko: do you remember why distutils-sysconfig.diff in python2.7 handles the OPT variable but python3.4 does not?
#ubuntu-devel 2015-01-06
<pitti> Good morning
<pitti> shadeslayer_: $HOME and $XDG_SESSION_ID and $XDG_RUNTIME_DIR should be there, and the others should be implied (we don't explicitly set XDG_CACHE_DIR etc. in a real desktop)
<pitti> shadeslayer_: what's missing there? bug reports appreciated
<jda2000> If I were to build an app for distribution in the Ubuntu Software Center and that app was linked to BDB 5.3 Would I have to write a check to Oracle?
<Noskcaj> jda2000, np
<Noskcaj> *no
<jda2000> Noskcaj: Thanks!
<Noskcaj> You can see that info in https://sources.debian.net/src/db5.3/5.3.28-9/debian/copyright/
<jda2000> If I were to find an orphaned FLOSS app and fixed and packaged it to run on Ubuntu, could I offer it in the for-pay section of the Software Center and could the user's still download the improved source from the Ubuntu repository?
<Noskcaj> jda2000, payed would depend on the license of the previous package, and no, they couldn't download the source, only the binary
<jda2000> Noskcaj: But what if I wanted them to be able to download the source since it still has to be Open Source?
<Noskcaj> You could still make it open source on your website but i THINK that payed means you can't download the source through ubuntu's repository
<jda2000> Noskcaj: Oh.
<Noskcaj> if you could, why pay for the app?
<jda2000> Noskcaj: Redhat has paid-for open source.
<Noskcaj> They give better support though don't they if you pay?
<jda2000> Noskcaj: For the convienience of not having to build it yourself.
<Noskcaj> good point
<Noskcaj> Someone more experienced in the area needs to comment.
<darkxst> jda2000, it will depend very much on the terms and conditions of the ubuntu app store
<darkxst> I've never looked, but I know the apple store is incompatibly with GPL code
<Unit193> Noskcaj: It
<jda2000> Thanks darkxst !
<Unit193> It's like synergy, source on gh, but binary builds are paid for.
<Unit193> s/paid for/behind a paywall/
<darkxst> Its certainly legit to sell GPL binaries, provided you provide the source on request also
<jda2000> darkxst: That was something I could google:  http://developer.ubuntu.com/en/publish/apps/other-forms-of-submitting-apps/commercial-software-faqs/
<Noskcaj> Unit193, ?
<jda2000> darkxst: (Thanks for the hint)
<jda2000> The minimum price for applications is 2.99 USD.   Hmmm...  Not happy about that.
<jda2000> I guess that's where price - 20% - cc charge-back == 0
<dholbach> good morning
<pitti> good morning dholbach, gesundes Neues!
<dholbach> hi pitti - and the same to you
<shadeslayer_> pitti: last I checked the tests were failing because of missing HOME and other XDG things, startkde manually exports  things like XDG_DATA_DIRS and XDG_CONFIG_DIR
<shadeslayer_> but this was well over 6 months ago
<pitti> shadeslayer_: $HOME is definitively there now; I did fix some $HOME issues in the past few months indeed
<pitti> shadeslayer_: and tests now also always get a proper logind+PAM session; before, tests running as root didn't
<pitti> but that's also only a month or so ago
<shadeslayer_> pitti: oh, how do I use that? I'd rather not have tests running as root
<pitti> shadeslayer_: use what? it just happens
<shadeslayer_> oh I misunderstood :)
<pitti> shadeslayer_: so perhaps try a local test run with current autopkgtest and without all the workarounds, and tell me (or preferably, LP bugs :) ) what's still wrong?
<shadeslayer_> will do
<shadeslayer_> pitti: btw this is all implemented in adt right? Not a Ubuntu specific thing?
<pitti> shadeslayer_: right, autopkgtest has been in sync forever
<pitti> shadeslayer_: and our CI lab just calls that (http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test)
<shadeslayer_> cool, I'm doing a Debian CI for Plasma 5, and was going to add autopkgtests to my Jenkins soon
<pitti> nice
<xnox> hallyn: experimental never migrates by itself, one needs to upload into unstable. from unstable onwards there is a waterfall unstable->testing->stable->old_stable
<Unit193> xnox: Hello.  Hate to bother, but will you be able to merge cryptsetup this release?  It's had a lot of the delta cut down, and seems to have better systemd integration.
<xnox> Unit193: yes, when I have time. Why is it urgent for you?
<Unit193> xnox: Sure, thanks.  It's not urgent, better systemd and tcrypt support are what I'm looking at though.
<jamespage> do we have any best-practice around MIR's for python modules that build pypy-* packages?
<mdeslaur> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<seb128> cjwatson, hey, do you think you could review https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222 or maybe suggest somebody who could? that's a one line and is in the sponsoring queue since august
<cjwatson> seb128: It needs to go into a branch based on lp:~ubuntu-core-dev/grub-installer/ubuntu (except branched for trusty), rather than using the unused UDD branch.  But I'm not doing d-i stuff now in general; maybe slangasek can suggest somebody.
<cjwatson> (Oh and it should use head -n1 not head -1 on general principles)
<seb128> cjwatson, ok, thanks
<seb128> slangasek, ^
<seb128> cjwatson, maybe you can write some small review comments on the mp? ;-)
<xnox> seb128: you are pushing it..... =)
<seb128> xnox, "it"?
<cjwatson> copied and pasted
<seb128> cjwatson, thanks
<seb128> xnox, you think I should just have copied that myself? fair enough...
<xnox> seb128: never mind me.
<seb128> xnox, cjwatson, happy new year btw ;-)
<cjwatson> thanks :)
<xnox> seb128: merci
<stgraber> bdmurray: thanks. I believe Vagrant looked into that stuff in Debian already (and quite possibly removed armhf support entirely since it only ever barely worked) so hopefully next time I sync/merge from Debian that bug will go away.
<xnox> ev: "Ability to time shift as required to overlap with US and UK timezones simultaneously." - Ideal candidates would be located in Greenland =)))))) *giggle*
<Riddell> uploads failing from launchpad? https://launchpad.net/ubuntu/+source/kwayland/5.1.2-0ubuntu1/+build/6692459  https://launchpadlibrarian.net/194161777/upload_6692459_log.txt
<xnox> ev: https://ldd.tbe.taleo.net/ldd01/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=925
<ev> xnox: ha! Or on a barge.
<cjwatson> Riddell: urgh, will look
<cjwatson> They would appear to all be failing.  Please don't retry, I'll ask for them to be reprocessed in bulk once I've figured out what's going on
<cjwatson> Started 15 minutes ago
<cjwatson> Odd_Bloke: ^- that affects the upload you mentioned you were waiting for, FYI
<cjwatson> (I think)
<xnox> ev: to be honest, if one get's the tide right, one can be efficiently arriving on the right side of the atlantic on the right periodic schedule for sprints etc.
<xnox> ev: latency of satellite internet is bad for hangouts though.
<cjwatson> Damnit, LP, a traceback would be nice
<xnox> cjwatson: couple more days and you'll be back in foundations?! =))))))))
<cjwatson> ... nope
 * xnox kidding
<Odd_Bloke> cjwatson: Yep, it did.
<ev> xnox: watch it, you. You're not going to ruin this for me.
<lool> doko: heya
<lool> doko: (and happy new year!)
<lool> doko: in vivid, when trying to install the location-service cross build-deps for armhf, I get:
<lool>  gcc-4.9:armhf : Depends: binutils:armhf (>= 2.25) but it is not going to be installed
<lool> I suspect this shouldn't be an :arch dependency here, correct?
<cjwatson> Riddell: Fixed, retried.
<bdmurray> jodh: There've been some interesting updates to bug 1300235.
<ubottu> bug 1300235 in upstart (Ubuntu) "init crashed with SIGSEGV" [High,Triaged] https://launchpad.net/bugs/1300235
<Riddell> cjwatson: lovely, thanks
<jodh> bdmurray: can you establish what 'cmd' is set to in the call to RunAsSudoUserCommand() ?
<bdmurray> jodh: isn't it GetBrowserCommand(...)?
<jodh> bdmurray: yes - that's what I mean - what does that function return exactly that is then run as root and triggers the crash.
<bdmurray> jodh: ah, I don't know. mvo?
<mvo> bdmurray: let me read the bug, does that mean running synaptic triggers a crash in init?!?
<jodh> bdmurray: can we strace or something? If it's returning ("kill", "-SEGV", "1") we have our answer :)
<mvo> jodh: -^
<mvo> jodh: I doubt its doing just that ;)
<jodh> mvo: agreed, unlikely, but would be useful to see an actual trace of what is happening.
<mvo> bdmurray: hm, in the settings chromium tells me that it can not be set as the default browser
<bdmurray> mvo: in chromium's settings?
<mvo> bdmurray: yes, it says "chromium cannot determine or set the default browser."
<dobey> mvo: btw, i saw yesterday that you were going to discuss the chromium/oxide issue with mirv. did you happen to do that? any news there?
<mdeslaur> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bdmurray> mvo: I've updated the bug some
<dobey> i wonder if we should ping qengho about that
<bdmurray> mvo: and I was able to change browsers using update-alternatives
<mvo> dobey: uh, I am in a meeting right now, I think I missed this :/
<mvo> bdmurray: nice, thanks, let me try that
<mvo> bdmurray: \o/ can reproduce
<dobey> 15:23 < mvo> Mirv: re oxide, lets talk tomorrow, I would love to hear what the issues are and we might revert and add a workaround in click and maybe add  "priority plugin directories" later to avoid the conflicts
<dobey> mvo: ^^ that. i don't know if click needs any workaround though. but maybe that's a different issue
<dobey> anyway, no rush. i'm just curious because the bug has unity-scope-click added on it
<mvo> dobey: yeah, my suggestion would be to revert for now and I will add a workaround in click
<mvo> dobey: I don't think the scope is affected here, not sure why this was added
<dobey> mvo: the scope has a depends on ubuntu-sdk-libs for the frmaeworks files
<dobey> and ubuntu-sdk-libs was uninstallable because of oxide codecs
<mvo> dobey: aha, so a revert would fix that, right?
<dobey> it seems to me like the chromium/oxide packages just need to be fixed properly to not conflict with each other
<dobey> mvo: maybe. i think the proper fix is to fix the packages to not conflict though. i see no reason why the packages should conflict (and i have no idea why they do exactly)
<dobey> to me, a package named foo-extras should extend foo, not conflict with foo :)
<mvo> dobey: yes, I agree, this is the right fix
<pitti> infinity, kees, mdeslaur, slangasek, stgraber: TB meeting in 4 mins
<mdeslaur> pitti: ack, thanks!
<infinity> pitti: Erm, yes.  Waking up.
<slangasek> seb128: for d-i reviews, stgraber or infinity could help
<seb128> slangasek, thanks
<infinity> What am I reviewing?
<seb128> https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222
<infinity> seb128: Looks like Colin's non-review was already a fair review.
<seb128> yeah
<seb128> it's a one liner than is waiting since august
<seb128> would be nice to see if off the review list one way or another
<seb128> it's trivial enough that it could be applied without asking the submitter to update
<cjwatson> right the submitter probably can't create the base branch anyway
<cjwatson> should be easy enough for a d-i committer to migrate over
<infinity> Yeah, I agree, no need to force them through the branch dance.
<infinity> I'm more interested in if it's the right fix, and if it breaks anything unrelated.
<infinity> So, I'll need to look at more than 3 lines of context.
<seb128> right, which is where the "needs a reviewer" comes in the equation
<infinity> Cause it's entirely sensible for rootfs to be multiple devices, and for grub to install to all of them, so it depends on what context this code runs in.
<matschaffer> Hi, a few days ago I was attempting to rebuild nginx to include nginx-auth-ldap. I came up with this: https://gist.github.com/matschaffer/97764148967fe17e5349 which seems to at least get the build process working but it ends up downloading an orig.tar.gz and ignoring my attempt at picking up the new module. Am I pretty close or should I plan to just read https://www.debian.org/doc/manuals/maint-guide/start.en.html in
<matschaffer> its entirety? (apologies for repost from ubuntu-server, still looking for the right audience for this question)
<mdeslaur> cjwatson: mind if I merge mime-support?
<cjwatson> mdeslaur: Go for it.
<mdeslaur> thanks
<Noskcaj> lol
#ubuntu-devel 2015-01-07
<dholbach> good morning
<LocutusOfBorg1> hi dholbach
<LocutusOfBorg1> :)
<dholbach> hi LocutusOfBorg1
<seb128> lamont`, hey, could you review the changes on https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/583216 ?
<ubottu> Launchpad bug 583216 in postfix (Ubuntu) "inet_protocols can't be preseeded" [Medium,In progress]
<seb128> mvo, hey, is https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1274466 something you still plan to work on? apparently your previous sru has been supperseeded by a security update
<ubottu> Launchpad bug 1274466 in apt (Ubuntu Trusty) "apt-ftparchive on-disk cache format changed between lucid and precise, results in Packages files with silently corrupted checksums fields" [High,In progress]
<seb128> mvo, (it's in the sponsoring queue)
<mvo> seb128: yeah, I need to look at this, but not right now, snappy is taking precedence
<seb128> mvo, does it need sponsors or is that on your list?
<mvo> seb128: its on my list, I don't know why its on the sponsoring queue
<seb128> mvo, ok, unsubscribing sponsors then, danke ;-)
<seb128> mvo, oh and happy new year! :-)
<mvo> seb128: thanks, happy new year to you as well :)
<seb128> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<Odd_Bloke> I'm looking at making changes to live-build for CPC; is the source for Ubuntu's version kept in version control anywhere?
<cjwatson> Odd_Bloke: not afaik
<cjwatson> just use the source package
<Odd_Bloke> Ack.
<Odd_Bloke> Thanks.
<seb128> is errors.ubuntu.com working for others?
<seb128> oh, it works, the "loading..." just takes a while
<seb128> ignore that
<lamont`> seb128: in my pre-awake state, that patch looks beautiful. (583216)
<seb128> lamont`, hey, happy new year ;-)
<lamont`> seb128: I'll look again in more detail after I wake up, but it does seem to clearly be an oversight with a trivial fix
<seb128> lamont, great, thanks
<flexiondotorg> Does anyone know if multilib gir support is planned for 15.04?
<cjwatson> flexiondotorg: It's already there
<flexiondotorg> cjwatson, Excellent! When did it land?
<cjwatson> flexiondotorg: 2014-10-28
<flexiondotorg> cjwatson, Thanks for the info. Brilliant.
<xnox> infinity: sysdeps/*/multiarch/* in glibc source code have nothing to do with Debian-multiarch term, right?
 * xnox is slowly going mad here
<highvoltage> someone please take some cheesecake to xnox
<xnox> hhhmmmm cheesecake
<tedg> jodh, Yesterday seb128 was pinging me about using UAL with systemd as PID 1, specifically replacing cgmanager calls.
<tedg> jodh, How is session upstart making cgroups in that case?
<tedg> jodh, I don't see any generic cgroups functionality in systemd interfaces.
<jodh> tedg: upstart calls cgmanager directly for cgroup handling.
<tedg> jodh, So then if we're using Upstart sessions we still need cgmanager running?
<jodh> tedg: if we want cgroup support for those sessions, yes.
<tedg> jodh, Does that work? Or do cgmanager and systemd fight?
<jodh> tedg: I thought hallyn made them tolerate each other, but best to check with him on the specifics.
<hallyn> so far they tolerate each other.  cgmanager is disabled under systemd by default though, you have to enable it
<tedg> They each sit in the corner and stare angrily at each other. :-)
<hallyn> well mor elike they try to give each other the cold shoulder :)
<tedg> Okay, so I guess the next question is whether we expect for 15.04 to have a systemd session for Unity8.
<tedg> If we expect it to be Upstart, there's no UAL changes, but if we want to be systemd, we need *all* the changes.
<tedg> seb128, ^
<hallyn> I think we expect systemd and cgmanager both in 14.04
<hallyn> uh, 15.04
<hallyn> by 16.04 hopefully well have cgroupns in the kernel and maybe not need cgmanager.
<seb128> tedg, systemd is going to be pid1 in vivid, I don't think we should ask users to change init system to try unity8 desktop
<tjaalton> there's no partner repo for vivid? my adobe-flashplugin is out-of-date because of that..
<tedg> seb128, I don't think they need to change init systems, just start the cgmanager unit.
<tedg> seb128, Are you guys migrating the Unity7 session management to systemd?
<seb128> tedg, you expect normal users to have to deal with command line to be able to log into a working unity8 session?
<seb128> tedg, there is session management migration planned for this cycle
<tedg> seb128, No, I expect us to make it work :-)
<tedg> Don't we need cgmanager for things like lxc as well? Why is it off by default?
<seb128> tedg, it's written in the bug I pointed you at yesterday
<seb128> tedg, https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1400394/comments/8
<ubottu> Launchpad bug 1400394 in ubuntu-app-launch (Ubuntu) "Unity8 fails to start applications under systemd init (cgmanager issue?)" [Undecided,New]
<tedg> Hmm, so if we can't have cgmanager, then Upstart needs to be able to create cgroups with systemd.
<tedg> UAL only queries the groups, Upstart creates them.
<tedg> seb128, Is there a reason we're not just migrating all the sessions?
<tedg> I hate flag days, but I kinda feel like supporting both is going to be tricky.
<seb128> tedg, needs resources
<seb128> no other reason than "1 step at the time"
<seb128> if we have people wanting to do it properly this cycle sure
<seb128> but I'm unsure we do have anyone with slots to work on that, the pid1 transition is already going to require shared efforts
<seb128> didrocks, pitti, ^ opinion?
<tedg> To be clear, I don't *want* to, but it might be the path of least resistance.
<seb128> tedg, it feels like we are going to need to make u-a-l talk to systemd's cgroup manager anyway, so we have to write that code
<seb128> shouldn't be that much work to have new code/old code in if blocks depending on the cgmanager running?
<seb128> rather than replacing one by the other
<tedg> seb128, UAL I don't think is as much the issue as we'd need to port Upstart as well.
<seb128> tedg, how so?
<tedg> seb128, Upstart creates the cgroups, so it's the one that does all the initial cgmanager work there. UAL only queries them once created.
<tedg> seb128, Upstart can't create them without cgmanager.
<Riddell> procps broken in vivid launchpad builds? https://launchpad.net/ubuntu/+source/kbookmarks/5.6.0-0ubuntu1
<seb128> Riddell, it's likely the sysvinit upload from didrocks earlier, I'm deleting it from proposed
<seb128> Laney found a typo in it
<arges> hallyn: hey! heads up, i see a couple of uploads from you of libvirt in trusty queue, I'm going to have to reject one since they have different changes but are the same version
<xnox> infinity: doh - enable single DSO with optimizations for multiple architectures
<didrocks> seb128: tedg: sessions were never used in prod in any distro yet, I think we would need to devote a whole cycle just for this
<didrocks> so not coupling the 2 transitions at the same time IMHO
<seb128> +1
<tedg> didrocks, ? Upstart session were used in 14.04.
<didrocks> tedg: systemd session
<tedg> Oh, yes. But if systemd and cgmanager don't get along...
<tedg> We either need to port Upstart to systemd or switch.
<didrocks> not sure what it will take to have upstart session working properly on systemd
<didrocks> but seems a saner approach to me
<hallyn> arges: grrr.
<tedg> jodh, Thoughts? ^
<didrocks> tedg: I guess we don't see that on the desktop because we don't use cgmanager there?
<tedg> didrocks, It feels to me like pushing Upstart in a direction that isn't truly useful.
<jodh> tedg: the point of upstart using cgmanager was to abstract the cgroup handling to a 3rd party, so maybe cgmanager could detect if systemd is running and proxy the calls to pid 1? hallyn?
<didrocks> tedg: right, but having both transitions at the same time seems risky as well
<tedg> didrocks, Well, apparently with systemd as PID 1 we don't end up being able to use cgmanager. Read pitti's comment on the bug above.
<tedg> You think of it wrong. It's just one transition from upstart to systemd, just two instances of it. ;-)
<hallyn> arges: trying to grab the sources before they get deleted so i can combine them
<arges> hallyn: yup that's why i pinged you first : )
<tedg> I don't disagree, just not sure that supporting the Upstart user sessions is worth it.
<didrocks> tedg: well, we don't already have the ressources in migrating all upstart services (system) to systemd
<didrocks> tedg: so, not that I disagree, but as seb128 told, "it's work" :)
<didrocks> and flag days, wellâ¦
<hallyn> arges: got them, thanks
<xnox> seb128: didrocks: systemd user sessions where used on MeeGo 1.3 I believe.... but that was a while back and not the current state of affairs.
<xnox> tedg: we have working cgmanager under systemd.
<didrocks> xnox: yeah, I wouldn't call that "production" though :p
<xnox> didrocks: true.
<arges> hallyn: ok i'll reject the later upload for (1403648/8), and you can rebase off that then?
<didrocks> xnox: see https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1400394/comments/8 for what tedg is refering to
<ubottu> Launchpad bug 1400394 in ubuntu-app-launch (Ubuntu) "Unity8 fails to start applications under systemd init (cgmanager issue?)" [Undecided,New]
<xnox> didrocks: ah, bugs. ok =)
<xnox> didrocks: converting desktop to systemd-usersession should be easy.
<xnox> didrocks: converting phone is not that easy, however I have good thought on how to implement it.
<didrocks> xnox: we already don't have the resources the migrate all system services (look at the progress we got), and seb128 was talking about the unity8 session on desktop, so basically converting phone
<didrocks> xnox: clearly not achievable this cycle looking at the remaining WI
<xnox> didrocks: wrt. to the bug report -> ubuntu-app-launch should be converted to use systemd. Isn't snappy using systemd to launch things?!
<xnox> didrocks: and the bug is with click app launching, rather than unity8.
<didrocks> xnox: that would be for mvo, but I guess it's only system service, so easy ;)
<didrocks> xnox: under an unity8 session on the unity8 preview desktop
<xnox> didrocks: we have a big chunk on the phone of "things in the container, exported to upstart, jobs launched on the system"
<didrocks> xnox: we don't use click on the unity7 session
<xnox> didrocks: i have a thought of generating units for those, and having the bridge start & stop those units, and everything else binding to them.
<xnox> pitti: ogra_ ^
<xnox> jodh: ^
<xnox> it should be simple enough to implement inside the current upstart socket bridge.
<didrocks> interesting
<xnox> xnox: well the socket bridge may need a rename as it's: upstart-events or systemd-generator
<hallyn> arges: I pushed a new one that combines the two
<arges> hallyn: even better.
<hallyn> arges: thanks, ttyl :)
<arges> later
<arges> hallyn: for bug 1403648 chiluk says the current patch is not acceptable for SRU
<ubottu> bug 1403648 in libvirt (Ubuntu Utopic) "Apparmor denies qemu access to a number of important directories." [High,New] https://launchpad.net/bugs/1403648
<arges> hallyn: so we may  need another upload for just the one fix instead of combining them
<arges> chiluk: can you update the bug so that its clear the fix as it stands isn't ready and why?
<chiluk> arges basically I wanted to investigate why qemu needs access to /tmp....
<chiluk> as security doesn't like giving access to /tmp for security reasons.
<chiluk> arges it might be better solved by patching libvirt to use something like /tmp/qemu or /tmp/libvirt for tmp files and giving it write access to that.
<arges> chiluk: ok makes sense, i'll reject it. sorry hallyn ...
<chiluk> arges also one of the permitted directories will likely need to be added to the ceph charm.
<hallyn> i'll just wait for chiluk's patch
<hallyn> chiluk: i was going based on jdstrand's comments
<hallyn> note that for vivid libvirt simply denys the access
<arges> hallyn: ok to reject? (haven't done it yet)
<chiluk> hallyn... I haven't reviewed your patch.
<hallyn> only for SRU does it allow it, to prevent breakges
<chiluk> I'm currently in a meeting.
<hallyn> arges: yeah i have the source.  i'll re-upload without that particular fix
<chiluk> I'll take a look right after this.
<hallyn> \o
<arges> hallyn: ok cool. what a fun morning
<lamont> seb128: after more review, yeah, +1.  adding a comment to the bug
<seb128> lamont, hey, thanks!
<seb128> lamont, do you plan to handle uploads as well?
<hallyn> arges: oh, so you should reject the utopic libvirt one for the same reason
<chiluk> hallyn arges, really the question should be why does libvirt /qemu try to access /tmp... And if it really shouldn't be accessing /tmp why not patch libvirt/qemu to not do so in the first place.
<arges> hallyn: ok done
<hallyn> chiluk: i don't believe libvirt is doing it
<hallyn> chiluk: i believe that's on your end.  we're jsut trying to accomodate what you want.  i could be wrong...
<chiluk> yeah I'm pretty sure it's just qemu
<hallyn> ok
<chiluk> silencing the messages is pretty important... as it's filling up logs for anyone running even a moderately sized cloud
<lamont> seb128: it's committed for 2.11.3-2.  There's even a chance that I'll upload it within 7-10 days... :(
<hallyn> chiluk: for vivid those are now silenced
<hallyn> arges: ok, new trusty upload without the /tmp junk pushed
<seb128> lamont, ok, I guess we can unsubscribe the sponsors at least, it's going to make it in one way or another ;-)
<chiluk> hallyn I was hoping to get feedback from the customer on this before proceeding with the SRU as well.
<lamont> seb128: when I upload it to debian, it will be merged with ubuntu (hopefully with no -1s...), to make the merge easier
<hallyn> FEH
<chiluk> crap you guys are working too fast..
<chiluk> ok I'm out of my meeting now.
<hallyn> arges: please delete them all, i should have kept the cpeh.conf perms
<hallyn> chiluk: it's a context switch thing, i want this put aside before i lose data
<seb128> lamont, k, anyway I unsubscribe the sponsors, you are in charge of it now ;-)
<lamont> seb128: ack
<arges> hallyn: ok
<hallyn> arges: sorry.
<hallyn> chiluk: i think we should have a separate bug about the /tmp access stuff
<arges> hallyn: its no problem
<didrocks> jamespage: hey! small question on radosgw-agent: nothing (no UI/web) is changing ENABLED=yes/no in /etc/default/radosgw-agent right? I can replace that with an upstart override on upgrade?
<hallyn> chiluk: unless you think i should put the 'deny /tmp/** r" stuff in SRU, to silcence the denials?
<hallyn> chiluk: and then we fix any resulting breakages in anew bug?
<chiluk> hallyn I'm not following... so a bug for libvirt apparmor profile , and for one to patch qemu accessing /tmp?
<hallyn> chiluk: right the current bug is  mostly about /**/ceph.conf denial right?  and /tmp is a secondary issue
<chiluk> well it's really more about silencing apparmor than anything else.
<chiluk> or it should be.
<hallyn> so you're ok with SRU for now deniying the /tmp access silently?
<chiluk> hallyn according to jdstrand comment #12   the SRU should be permissive of those directories..
<chiluk> if I'm reading it correctly.
<jamespage> didrocks, I'd need to refresh my memory
<hallyn> chiluk: that's what my original sru did
<chiluk> hallyn... I never said to reject the sru... nor did anyone give me a chance to review it.
<hallyn> so if you're ok with that i can re-upload :)
<didrocks> jamespage: the upstart service is disabled by default and you control the enablement state thanks to this setting. As we try to get read of those ENABLED=yes/no when switching to systemd, I want to ensure I'm not going to break you :)
<chiluk> yeah I'm ok with permissive for the sru to silence apparmor ... I think that's what jdstrand intended...
<hallyn> right
<chiluk> so yeah go ahead and re-upload.
<chiluk> hallyn .. I'll write the SRU template
<hallyn> thx
<hallyn> left hand is holding a phone, right a coffee;  i'll upload it in a bit
<chiluk> hallyn am I correct in my apparmor understanding that without an explicit rule apparmor is permissive ?
<hallyn> no
<hallyn> it by default denies, noisily
<chiluk> hmm so we are changing the original behavior
<hallyn> yes
<jamespage> didrocks, ah right
<hallyn> that's why jdstrand was hesitant
<chiluk> hallyn that makes me wonder why jdstrand suggested making it permissive then.
<jamespage> didrocks, the problem there is that there is no good default configuration
<hallyn> chiluk: bc not breaking users is important
<didrocks> jamespage: that's fine, I can ship an .override by default to disable the job
<hallyn> (for sru)
<jamespage> didrocks, awesome
<didrocks> jamespage: and handling upgrade with removing it if the previous version was "yes"
<didrocks> ok, doing that then, thanks!
<jamespage> didrocks, right
<hallyn> chiluk: so i'd appreciate you running your workloads on vivid so we can track down what failures the denials cause :)
<chiluk> hallyn, but if apparmor denies by default, then the /tmp has always been getting denied.
<hallyn> yes, it's just noisy
<chiluk> so why not make it an explicit denial for the SRU?
<chiluk> I'm not arguing one way or the other.
<chiluk> hallyn just a little confused.
<hallyn> let's see if jdstrand has a comment on that.  maybe he thought you were having to work around it by adding the permission?
<chiluk> maybe..
<jdstrand> what is the bug number?
<smoser> anyone else use chromium on vivid? once i do a hangout i lose keyboard input entirely to chromium.
<chiluk> jdstrand, 1403648
<jdstrand> "However I also don't want to break existing setups by adding an explicit deny rule that would block all access to /tmp and /var/tmp if the user updated policy for that or is putting disks in /tmp for testing environments"
<jdstrand> yes, it was denied before
<jdstrand> but, if the user adjusted their policy to allow it, I was saying I didn't want to break that
<hallyn> i see
<chiluk> wouldn't dpkg resolve user updated policys?
<smoser> it sounds like https://code.google.com/p/chromium/issues/detail?id=360388 or http://askubuntu.com/questions/457541/unable-to-type-anything-on-chromium
<jdstrand> it would show the difference, yes
<arges> smoser: i've had that happen to me on chromium, but not on chrome. could be 1307648 resurfacing?
<chiluk> hallyn jdstrand, so wouldn't it be better to keep the behavior as it is then, and let the user resolve the config difference on upgrade?
<jdstrand> it is a very tricky thing modifying config files in SRUs
<jdstrand> people sometimes do the wrong thing
<smoser> right.l thats the other link.
<smoser> arges, you just run 'ibus exit' ?
<smoser> that does seem to fix it, but i'm not sure what other fallout there would be.
<jdstrand> note that the access I granted was very small-- read on the directory, not on the files in the directory
<arges> smoser: yea seems like there should be a better solution. branded chrome works fine, so maybe there is a patch that hasn't made it to chromium to fix this
<jdstrand> it is just enough access to remove confusion as opposed to adding something that could potentially break people
<jdstrand> imo, that is a reasonable SRU compromise
<chiluk> arges hallyn ^^^^ ... how do you guys feel about that.
<jdstrand> it weighs the confusion caused by the bug against the slight additional access of VMs being able to ls /tmp and /var/tmp
<jdstrand> without adding a possibility for regression
<arges> I think if jdstrand is happy with any security implications then it seems reasonable.
<chiluk> ok.. so the original upload sounds good to me then http://launchpadlibrarian.net/194182873/libvirt_1.2.2-0ubuntu13.1.8_1.2.2-0ubuntu13.1.9.diff.gz
<chiluk> hallyn arges jdstrand I'll do some testing today on this... hopefully I don't find anything interesting.
<jdstrand> I am. I don't like the access, but the denial leads to confusion. the access is very limited and guarantees no chance of regression. with what is in vivid, all future releases properly deny it
 * smoser installs chrome
<hallyn> arges: so do you magically have what you need to accept the right one? :)
 * hallyn waves his hands  "magic"
<chiluk> hah.
<arges> hallyn: well since i went on a rejection rampage, there isn't anything in teh queue, can you re-upload the version that chiluk requests?
<chiluk> arges... too fast..
<jdstrand> hallyn: actually, before you upload
<jdstrand> hallyn: can you add a comment above the accesses that it only allows read access to the directory to workaround the bug (and reference the bug number)?
<hallyn> arges: https://launchpad.net/ubuntu/trusty/+queue?queue_state=4&queue_text=libvirt  ?
<hallyn> jdstrand: i did reference the bug#
<hallyn> " # avoid spurious denials (see lp#1403648)"
<jdstrand> hallyn: eg: # workaround LP: #1403648 by allowing read access to the directory. This will be removed in future releases
<ubottu> Launchpad bug 1403648 in libvirt (Ubuntu Utopic) "Apparmor denies qemu access to a number of important directories." [High,New] https://launchpad.net/bugs/1403648
<hallyn> ok
<jdstrand> hallyn: well, something like that. whatever you think
<hallyn> i'm taking your text and pushing
<hallyn> (in a few mins)
<jdstrand> hallyn: thanks. I think that will make things clearer for 14.10 to 15.04 and LTS to LTS upgrades too
<jdstrand> (for people who did modify the poolicy and are seeing the diff)
<arges> i'll check it in a bit... brb
<infinity> xnox: multiarch in the glibc world means GNU IFUNC.
<hallyn> jdstrand: chiluk: arges: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=libvirt  and https://launchpad.net/ubuntu/utopic/+queue?queue_state=1&queue_text=libvirt . hopefully those do what you guys wanted
<jdstrand> the apparmor changes lgtm
<hallyn> thanks!  ttyl
<jdstrand> thank you! :)
#ubuntu-devel 2015-01-08
<kirkland> so unity --reset is deprecated as is ctrl-alt-backspace;  so how do I unfsck unity when it's fscked?
<Mirv> is anyone else seeing what camako is seeing at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-017/+packages - that the publisher run(s) seems broken?
<pitti> Good morning
<pitti> tedg, didrocks: FTR, sessions are running in a cgroup writable (i. e. "subgroupable") to the user, so in principle session upstart or UAL or whatever could do this by itself
<pitti> once we move the session to systemd-user as well, this will be moot of course
<didrocks> good morning pitti!
<Mirv> good morning pitti, didrocks
<pitti> hey didrocks, hello Mirv
<didrocks> hey Mirv!
<pitti> didrocks, tedg: btw, in principle cgmangager does run under systemd, they are just potentially clashing by doing things differently
<pitti> but we'll need it for the "fake" cgroup fs for session LXC in any case
<didrocks> ah, so it's not an orthogonal discussion
<pitti> Riddell: FYI, yesterday's KDE uploads are mostly stuck on uninstallability on i386: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<pitti> (email notifications still don't work, arhg)
<pitti> Riddell: perhaps related to the depwait of https://launchpad.net/ubuntu/+source/plasma-framework/5.6.0-0ubuntu1
<pitti> Riddell: ah, it got retried three times yesterday, but now it works again, so I guess some archive admin did whatever was necessary
<sitter> wgrant, cjwatson: as observed by Mirv, launchpad publisher seems to have severe problems .... e.g. https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/+sourcepub/4653416/+listing-archive-extra <= built 7 hours ago, still pending publication
<dholbach> good morning
 * Mirv filed RT ticket about publisher
<wgrant> Looking.
<seb128> hey there
<seb128> is anybody else having issue booting with yesterday's kernel update?
<seb128> I see the plymouth logo and screen empty screen
<seb128> boots fine if use recovery or boot an old kernel
<seb128> that's on a dell e6410 i5 with intel video
<pitti> I haven't rebooted yet after dist-upgrade, will try
<stevenm> Hey anyone about?  I'm trying to figure out a bug with the packaging of libqt5core5
<seb128> apw, ^ do you know about my kernel issue maybe?
<Mirv> I seem to be running the latest kernel, no problems. i5-2557m era machine.
<cjwatson> sitter: That's published now.
<Laney> Need help analysing this: https://jenkins.qa.ubuntu.com/job/vivid-adt-floodlight/lastBuild/ARCH=amd64,label=adt/console
<Laney> The problem is that the java alternates aren't in place when the floodlight job is started
<Laney> But AFAICS they should be, because floodlight Depends: default-jre-headless, which Depends: openjdk-7-jre-headless, but that is configured after default-jre-headless is, as you can see in the log.
<svenx> starting around Trusty, i386 is not added as a multiarch on amd64 systems by default. it definitely was on Precise. What's the rationale, if any?
<cjwatson> svenx: It's still supposed to be enabled.  Perhaps you aren't installing via a standard method?
<svenx> cjwatson: i'm using debootstrap, indeed
<svenx> perhaps the mechanism to enable it was moved
<svenx> for example if the package 'multiarch-support' made the modifications before, but not any longer
<cjwatson> No.
<cjwatson> dpkg used to force it in a different way.
<svenx> aha
<cjwatson> But the whole multiarch config mechanism changed in precise.
<cjwatson>         if dpkg --compare-versions "$2" lt 1.16.0.3ubuntu4; then
<cjwatson>             new_installs_multiarch
<cjwatson>         fi
<svenx> this could explain it.
<cjwatson> infinity: ^- I suspect this doesn't work right with debootstrap, perhaps, because it's extracted the first time through and the status file faked up.  I think.
<cjwatson> Anyway, debootstrapped installs aren't guaranteed to have the fully standard config in all ways.
<cjwatson> s/changed in precise/changed in quantal/ above
<svenx> that's okay. i was merely digging into the details to figure out the difference in behaviour, so i can document it in the configuration for my FAI-based installer
<svenx> thanks for the quick pointer
<cjwatson> No problem.  I think this is probably a slight bug.
<Laney> well then
<Laney> Seems to be a bug in dpkg
<syockit> Referring to http://packaging.ubuntu.com/html/security-and-stable-release-updates.html#stable-release-updates, it says that "We also allow updates â¦ such as a severe regression â¦ or a bug which could cause data loss."
<syockit> Does this mean paper cuts like LP #1322925 are likely to not be accepted for an "updates" channel release?
<ubottu> Launchpad bug 1322925 in nautilus (Ubuntu) "Copy, paste stops working randomly in Ubuntu 14.04 nautilus" [Undecided,Confirmed] https://launchpad.net/bugs/1322925
<rbasak> syockit: given how many are affected by the bug, an SRU for that may be reasonable. I can't speak for the SRU team though.
<rbasak> It also depends on the fix, since that affects regression risk.
<rbasak> syockit: I wouldn't rule it out for an SRU, anyway.
<rbasak> syockit: see https://wiki.ubuntu.com/StableReleaseUpdates if you haven't read that page.
<syockit> rbasak: I haven't. Thanks for the link!
<syockit> What's the channel for SRU discussion?
<rbasak> syockit: here and #ubuntu-release are both appropriate.
<pitti> stgraber: wrt. "bond/vlan/bridges interfaces do not work because they're fully virtual and do not have udev events" -- do you have some details about those?
<pitti> stgraber: we call ifup -a, so I assume it's more complicated than just putting those into /etc/network/interfaces
<pitti> infinity, smoser: does wolfe need to be powered back on after the move or so? allegedly IPs didn't change
<smoser> let me chekc
<aquarius> stgraber, ping if you're around about unprivileged lxc failing to attach
<smoser> pitti, i think you're up now
<stgraber> aquarius: hi. I'm around though mostly stuck in meetings today. What kernel, LXC and what kind of error are you getting?
<pitti> smoser: yay, all except wolfe-06
<smoser> wolfe-06 thinks its up
<aquarius> stgraber, Ubuntu 14.04 amd64 3.13.0-43-generic. lxc-start works and gives a login prompt, but I can't log in because I've set no user. lxc-attach fails with: lxc_container: call to cgmanager_move_pid_abs_sync failed: invalid request  // lxc_container: Failed to enter group /aquarius/rnr  //  lxc_container: error communicating with child process
<aquarius> stgraber, lxc-start --version says 1.0.6.
<pitti> ssh_exchange_identification: Connection closed by remote host
<pitti> smoser: ^ hmm, no luck here
<smoser> rebooted him
<pitti> smoser: thanks for prodding, works now!
<rbasak> pitti: is it Testsuite: autopkgtest now? No XS- any more?
<smoser> i had fat-fingered' the bringup of 07
<pitti> rbasak: right; XS- still works of course, but it's an official field
<smoser> and that resulted in 06's tun device getting whacked
<pitti> rbasak: moreover, you don't need to explicitly set it at all
<pitti> rbasak: if there's a debian/tests/control, dpkg-source will add it automatically
<rbasak> pitti: great, thanks. So is that best practice now? Not setting it at all?
<rbasak> pitti: what about backports to Trusty?
<rbasak> I'm still using dpkg-source on Trusty, so I guess I'll leave it XS- for now.
<rbasak> pitti: one more question. I'm writing a test that needs "sudo" to work. So not quite needs-root, but almost. Will this work in the current environment (Ubuntu-only)? If not, I presume I need to write a wrapper and use needs-root?
<rbasak> pitti: this is isolation-machine as it will create LXC containers.
<stgraber> aquarius: hmm, sounds like a bug that we had a while back but I thought hallyn resolved that
<hallyn> aquarius: what is /proc/self/cgroup before you do lxc-attach?
<hallyn> say, is there a way to add comments to reports on errors.ubuntu.com?
<aquarius> hallyn, http://pastebin.ubuntu.com/9693666/ -- it did at one point not have my username in it but I fixed that after reading a github issue report
<hallyn> (https://errors.ubuntu.com/problem/9d8b1bc865eba0604b89ca1f7a24f0a1a0186290 should be fixed in 0.34)
<didrocks> jpds: hey, any reason apart from "nobody got the time for this" for strongswan to not having been merged with debian and moved to 5.2.1? I see we diverged a long time ago from debian (dec 2013) and I was thinking merging back to bring the systemd service as part of this
<pitti> rbasak: ah, for backports you have to use XS-* still, if you actually care for having the tag there
<pitti> rbasak: back in 30 mins, sorry
<hallyn> aquarius: you did an unprivileged container, or privileged?  Can you pastebin the full set of commands?
<stgraber> aquarius: how are you logging into that system? cgmanager combined with systemd-logind on 14.04 should set everything up for you
<hallyn> stgraber: yes, but in 14.04 you have to restart systemd-logind after installing cgmanager and the nlog back in
<stgraber> aquarius: and if you just installed LXC, you need to completely logout and login again (or better, reboot) to have it properly setup
<stgraber> hallyn: right, was getting there :)
<aquarius> hallyn, unprivileged container. stgraber, erm, I don't understand the question about how I log in; it's a desktop Ubuntu machine so I log in with lightdm, presumavly.
<hallyn> stgraber: :)
<aquarius> Oh! I have to log out and in?
<aquarius> right, that'll be the problem then :)
<stgraber> if you just installed LXC, reboot and try again, that should make systemd-logind less stupid
<hallyn> i cringe at 'reboot' :)
<aquarius> right, fantastic, I'll do that next time I don't have anything I need open :)
<hallyn> aquarius: you can do it manually,
<hallyn> 'sudo restart systemd-logind', then ssh localhost and work from the ssh shell
<stgraber> hallyn: yeah, I don't like it either but that's what I put in my blog posts because well, that's foolproof :)
<hallyn> true
<aquarius> hallyn, restarted systemd-logind; sshed localhost; lxc-attach -n rnr; same error that I got before
<jpds> didrocks: Mostly time, and I'm still thinking about how all the plugins should be handled in future.
<hallyn> aquarius: is /proc/self/cgroup still showing / for most controllers?
<aquarius> hallyn, nope; it now has /user/1000.user/1.session for all of them
<jpds> didrocks: I play to revamp it all soon.
<didrocks> jpds: do we have a huge diff? Maybe I should just try to insert 5.2.0-2 for not diverging on the system service if you think it's safer (I'm not really sure how to test it)
<jpds> didrocks: Huge diff.
<didrocks> jpds: ah ok, so better for me to only stick in 5.2.0-2 meanwhile
<didrocks> thanks for your feedback, doing that!
<hallyn> aquarius: and you stopped and restarted the container?
<aquarius> hallyn, I hadn't, hang on
<aquarius> ahaha!
<aquarius> I have to start it in the ssh session. And now it works. hallyn, you rock.
<aquarius> I'll reboot at some point.
<aquarius> superb.
<hallyn> aquarius: great.  wish that hadn't been necessary, but later releases do fix it (or at least aresupposed to) - ttyl
<rbasak> stgraber, hallyn: lxc-templates only recommends cloud-image-utils, so the ubuntu-cloud template doesn't work out of the box with --no-install-recommends. Do you consider this expected behaviour, or should it be a hard dependency?
<rbasak> (if it's expected, then I need juju-local to depend on cloud-image-utils I guess)
<stgraber> rbasak: looking at the other Recommends, I think that's expected and fine, assuming that the template in question gives you a clear error message in that case
<hallyn> yeah, that's basically what '--no-install-recommends' means...
<rbasak> stgraber: the error tells me that ubuntu-cloudimg-query doesn't exist, which was good enough for me. OK - I'll add it to juju-local - thanks.
<hallyn> and yeah if error msg isn't clear then we need to fix that
<hallyn> ok
<infinity> cjwatson: I'd be inclined to consider that a bug in how debootstrap works if it can't guarantee that maintscript snippets with a null comparison don't trigger.
<infinity> cjwatson: But maybe it's a bug for essential packages to have such a condition.  Could go either way.
<cjwatson> Hard to say
<infinity> cjwatson: Although, there's got to be more to this than just debootatrap sucking.
<infinity> cjwatson: Cause debootstrap is how we install our livefses, and they're configured right.
<infinity> cjwatson: Unless they really aren't, and ubiquity/d-i are fixing it.
 * infinity grabs an ISO.
<pitti> rbasak: if you only care about our ubuntu CI ones, they can use (passwordless) sudo
<pitti> rbasak: it would be nice if the test would skip itself if "sudo -n true" fails, instead of hanging forever
<pitti> rbasak: I mean images run on the standard adt-release-arch-cloud.img QEMU ones
<rbasak> pitti: OK, thanks. I can test with "sudo -n true" easily enough. Is there an exit status code for a test skip?
<pitti> rbasak: no, just echo an appropriate message and exit 0
<pitti> rbasak: tests skipped due to unsatisfiable restrictions have a particular code, but that's one level down; once your test runs, it must succeed
<pitti> rbasak: it's not that important anyway, mostly for manual runs on arbitrary targets
<pitti> rbasak: in our CI, QEMU should work and LXC (armhf, ppc64el) will skip the test due to isolation-machine
<rbasak> pitti: I don't like to exit 0 here. Then if I've made a mistake, my problem will silently succeed. Can I exit 1 instead?
<pitti> rbasak: sure; cf. the above "not that important'
<rbasak> OK
<rbasak> Thanks for your help.
<pitti> rbasak: just print something sensible like "this test needs passwordless sudo to be available"
<pitti> ?
<rbasak> ack
<pitti> rbasak: ok, great
<cjwatson> infinity: apt-setup fixes it
<cjwatson> infinity: (and should continue to do so, since it has configuration knobs for this)
<infinity> cjwatson: Indeed, `dpkg --print-foreign-architectures` in a trusty squashfs returns nothing.
<infinity> cjwatson: I wonder how noboy noticed or cared before.
<infinity> nobody, too.
<infinity> cjwatson: Given that we no longer care about that upgrade path, I wonder if it wouldn't be best to just remove that block entirely from our dpkg delta now, and say (rightly, IMO) that setting up extra arches is up to the installer.
<infinity> cjwatson: All our installers must DTRT here anyway, since it's obvious that debootstrap alone doesn't. :P
<cjwatson> infinity: Yeah, I don't mind hugely
<staylor> Wanted to clarify that if I follow the method defined at https://wiki.ubuntu.com/KernelTeam/GitKernelBuild for generating kernel deb packages that these will work fine for distribution using apt-get for various boards?
<infinity> cjwatson: Excellent.  Always good to have concensus from Launchpad people.
<infinity> cjwatson: PS: traitor.
<infinity> staylor: Should do, just remember to also distribute the source packages that match, for legal reasons.
<infinity> staylor: Also, if you're not altering the upstream source, but rather just adding CONFIG options to enable new boards for the -generic kernel, it might be nice to file bugs to get that fixed in the Ubuntu kernel, rather than distributing your own fork.
<staylor> infinity: it's a separate fork from what's in Ubuntu, basically our fork of the Freescale fork for i.MX6 ARM support.  A bit of a mess thanks to Freescale ;-)
<staylor> infinity: so what I'm hoping to do is distribute our kernel deb packages in a way that most closely resembles the way Ubuntu does it, linux-image, linux-headers, etc, along with modules and of course the source package.
<infinity> staylor: Hrm.  Kay.  The Ubuntu kernel is known to work on at least some i.MX6 devices, so I'd be curious what we (and upstream) are missing.
<staylor> infinity: though the Ubuntu kernel works on i.MX6 to get the GPU binary blob drivers working correctly we need to use the Freescale kernel unfortunately.
<infinity> staylor: Oh, right.  Yay blobs. :(
<infinity> staylor: In that case, I would make sure that your forked kernel package is also a different flavour, since you might be maintaining it for a while and don't want upgrade hassles.
<infinity> staylor: ie: instead of linux-image-generic, it should be linux-image-imx6-nonfree or something, so it's (a) obvious what it's for, and (b) won't confuse apt and users if we release a newer version of -generic that threatens to upgrade.
<staylor> infinity: yes, I think that's the part that I'm missing as I'm not really clear on these details.  Ubuntu support is newer to us we've in the past just used very specific "distros" and yocto.
<infinity> staylor: Not sure how well the kernel team has out-of-tree flavours documented, but if you ask apw nicely, he can talk you through it.
<infinity> apw: ^--- If you're feeling helpful.
<staylor> infinity: so I could define say linux-image-companyname-imx6 for example?
<infinity> staylor: Yeah.
<infinity> staylor: Like in trusty, you'll see that we have -generic and -generic-lpae from the mainline "linux" source, but we also have -keystone from an out-of-tree build, for a specific system that isn't entirely upstreamed.
<infinity> staylor: Ideally, you'd want to maintain your stuff the same way that keystone kernel is.
<staylor> infinity: yeah, that's sort of what I was originally thinking but pulling the apt-source of the kernel packages seems to be very different from other "standard" packages so I'm curious the correct way to build my own effectively.
<apw> staylor, yeah waht keystone or lowlatency are doing are pretty good delta kernels which can be soimply rebased on to each release the main kernel takes
<apw> rather than trying to understand the packaging to much, looking at the debdiff from the main kernel to one of those
<infinity> staylor: To be fair, for one-off builds, pretty much anything works, but if you want to actually rebase with our kernel updates and keep your kernel maintainable and supportable in some fashion, doing it the way keystone is done will help you a lot.
<apw> concur
<apw> staylor, feel free to bring questions to #ubuntu-kernel
<staylor> alright thanks I'll take a look at that, we'll be tracking Freescale's linux-imx git going forward with this package as well as our additional patches for drivers specific to this processor so we'd be maintaining it (as we do today for our yocto based BSP).
<cjwatson> infinity: you're welcome ;-)
<bdmurray> tkamppeter: the fix for bug 1400232 was included in your upload to Utopic, but not to Trusty. Was this an accident?
<ubottu> bug 1400232 in system-config-printer (Ubuntu Trusty) "system-config-printer crash UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 1441: invalid continuation byte (only UTF-8-encoded PPD files can be used)" [Undecided,In progress] https://launchpad.net/bugs/1400232
<bdmurray> tjaalton: could you respond to the comment in bug 1401788 regarding the SRU of xserver-xorg-video-intel?
<ubottu> bug 1401788 in xserver-xorg-video-intel (Ubuntu Utopic) "backport BDW/CHV sna BLT fix" [Undecided,New] https://launchpad.net/bugs/1401788
<tjaalton> bdmurray: hmm yeah I forgot to add the header before holidays..
<tjaalton> I'll add it tomorrow
<bdmurray> tjaalton: alright, thanks
<tkamppeter> bdmurray, seems that I have simply forgotten it in the package uploaded to trusty-proposed.  Can you reject the uploaded package and I will upload a new one with the patch added. Thanks.
<bdmurray> tkamppeter: rejected, let me know when the new one is ready for review.
<tkamppeter> bdmurray, new package uploaded.
<chiluk> lamont, I'm looking at bug 583216 and noticed that there wasn't a track for trusty... do you intend to upload the fix into trusty as well?
<ubottu> bug 583216 in postfix (Ubuntu) "inet_protocols can't be preseeded" [Medium,In progress] https://launchpad.net/bugs/583216
<lamont> chiluk: I might be talked into that
<lamont> chiluk: tell you what.  I'll upload it to trusty-proposed, you deal with the SRU?
<chiluk> lamont the SRU template is already kinda -filled out.
<chiluk> I can clean it up though.
<chiluk> and twist arges' arm to push the SRU button.
<lamont> I guess this means I'll have to do the uploads this weekend, he/
<lamont> eh?
<chiluk> lamont yeah probably.
<chiluk> lamont if you don't have time I can push it through the process
#ubuntu-devel 2015-01-09
<pitti> Good morning
<pitti> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti, seb128
<LocutusOfBorg1> wow pitti thanks!
<LocutusOfBorg1> I'm still setting up my lucid VM :p
<pitti> LocutusOfBorg1: lucid?
<LocutusOfBorg1> s/lucid/precise
<LocutusOfBorg1> :)
<pitti> LocutusOfBorg1: ah, I just tested in a schroot
<LocutusOfBorg1> I can't test in my pbuilder-dist chroot because it grabs the host kernel
<pitti> infinity: are you going to handle the eglibc precise SRU in bug 1020210 or want me to sponsor? (merging to current precise-security, of course)
<ubottu> bug 1020210 in eglibc (Ubuntu Precise) "Race condition using ATOMIC_FASTBINS in _int_free causes crash or heap corruption" [Undecided,In progress] https://launchpad.net/bugs/1020210
<LocutusOfBorg1> pitti, it fails with another error
<LocutusOfBorg1> please let me fix this one too
<pitti> LocutusOfBorg1: i. e. do you want me to remove the previous upload?
<LocutusOfBorg1> yes if possible
<LocutusOfBorg1> I need to test with the exact kernel version, to avoid further uploads...
<LocutusOfBorg1> chroot seems to be not enough
<pitti> LocutusOfBorg1: rejected, and bug updated (you can re-use the same version number)
<pitti> LocutusOfBorg1: yeah, I was wondering why it still failed against 3.13, even though .7 claimed to fix that
<pitti> but that bug is for 3.5
<LocutusOfBorg1> pitti, virtualbox always make me sad
<LocutusOfBorg1> :)
<LocutusOfBorg1> kernel folks do their best to screw up virtualbox everytime :p
<LocutusOfBorg1> and virtualbox folks to their best to make low low low low kernel modules everytime ;)
<rbasak> pitti: so my dep8 test failed with: juju-quickstart: error: bad API response: cannot upload charm to provider storage: 504 504 Gateway Time-out
<rbasak> pitti: I suspect an interaction with a proxy. Does this seem likely to you?
<rbasak> pitti: I don't remember the details of what happens with the proxy in the test environment. Is this documented anywhere?
<pitti> rbasak: right, we don't have a direct network connection in the DC; http_proxy and https_proxy are set, but maybe the upload doesn't work through the proxy
 * pitti bbl
<didrocks> jodh: pitti: added some validity unit checking for systemd reference to the wiki page (https://wiki.ubuntu.com/SystemdForUpstartUsers?action=diff&rev2=66&rev1=65)
<jodh> didrocks: nice! thanks!
<didrocks> jodh: yw, it's a handy tool I'm using before my uploads, especially for the server stuff when I don't always have the whole setup to test :)
<jodh> didrocks: ack. would be great if we could find a way to auto-check all packages containg units before they hit the archive. I always wanted that for upstart as it would have saved a few problems :)
<seb128> wgrant, hey, launchpad is supposed to share strings from a same component between different series, right?
<seb128> do you know why
<seb128> https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/535/+translate
<seb128> is untranslated
<didrocks> jodh: agreed, it seems this can work offline, I need to test it though and maybe we can put it in dh-systemd
<seb128> while https://translations.launchpad.net/ubuntu/vivid/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/485/+translate
<seb128> is
<didrocks> jodh: will handle that
<seb128> cjwatson, ^ your work on launchpad now, right? ;-)
<pitti> didrocks: oh nice, I didn't know about that yet either
<seb128> is that because ubuntu-rtm != ubuntu
<pitti> jodh, didrocks: wiki FTW :)
<didrocks> indeed! ;)
<cjwatson> seb128: I don't know Translations at all well, but I don't believe that there is any sharing between templates in different distributions, only templates in the same distribution source package and across upstream packaging relationships.
<cjwatson> seb128: That said, I've just linked the ubuntu-system-settings sources in both ubuntu and ubuntu-rtm to the corresponding upstream project, which may help (possibly).
<seb128> cjwatson, ok, thanks, did that enable upstream/downstream sharing? because I think we desactivated that to get the packaging template used instead of the trunk one (the packaging one is updated on upload, the trunk one needs to be manually updated and we keep forgetting)
<wgrant> It's complicated.
<wgrant> I didn't fix it all completely, let me see what the edge cases are.
<wgrant> Right, so there is currently no sharing between packages of the same name in related distributions, except via links to products.
<wgrant> So if the package isn't connected to upstream, it won't be shared between the distros.
<wgrant> cjwatson: POTemplateSharingSubset, fwiw
<cjwatson> Right, found that with the big block comment listing the rules.
<cjwatson> seb128: OK, if you need to deactivate it again then go for it, but it seemed like the obvious thing to do ...
<wgrant> It is reasonably possible to share through DistroSeriesParent directly, if we really need that. http://pastebin.ubuntu.com/8166797/ is the terrifying query.
<wgrant> But we've generally gotten away without it so far
 * cjwatson hides
<didrocks> jodh: I can either add a note or remove EnvironmentFile in "Do not run service if no daemon configuration file created" case, as the upstart job doesn't source the environment file
<didrocks> jodh: so the equivalent is the already present ConditionPathExists
<didrocks> jodh: I can maybe add a note to precise that EnvironmentFile is doing a sourcing
<didrocks> jodh: oh sorry, didn't see the env config=
<didrocks> jodh: so ConditionPathExists= isn't necessary actually, EnvironmentFile will fail if the file isn't present and the job will fail
<andreas__> hi, is there a way other than inspecting /usr/share/doc/*/copyright to get all the licenses that make up the installed system?
<andreas__> I didn't find some sort of metadata key for licenses in the control file of a source package, or in "apt-cache show"'s output
<svenx> woo, nice. i just managed to pull off a full reinstall without rebooting the system, by way of a tmpfs ramdisk and pivot_root
<svenx> reboot to get a newer kernel in the end, though. but worked smoothly without involving any installation media. only debootstrap
<didrocks> andreas__: you have to rely on /usr/share/doc/*/copyright, a lot of them now are following DEP5 (http://dep.debian.net/deps/dep5/) and so, is machine-parsable
<andreas__> didrocks: but I have to have the packages installed then, I can't get the licenses of the dependencies without installing the dependencies
<andreas__> right>?
<didrocks> andreas__: you can apt-get source <package> and look at <package_dir>/debian/control if you enable the source, or download the deb manually and dpkg-deb -x to extract it in a directory
<pitti> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<seb128> wgrant, cjwatson, with the change to link to the project it means the template from trunk is going to be used instead of the ubuntu build one, right?
<cjwatson> seb128: I don't know for sure, so if you think there's a risk of problems then undo it.
<pitti> oh, that'd be wrong
<pitti> as upstream regularly forgets to push POT updates
<pitti> e. g. recently vrruiz asked me about a recently changed string ("Orientation" -> "Rotation") which didn't appear in the upstream translations, but in rtm only
<seb128> pitti, right, cjwatson did that to try to get translations shared between ubuntu and ubuntu-rtm packages
<pitti> ah, sharing the translations should be fine
<seb128> pitti, that's the same issue that brought that discussion
<pitti> as long as ubuntu, rtm, and trunk all keep their own POTs
<cjwatson> I've undone it then.
<seb128> pitti, well you can't share between different distros, out by linking to the same project
<seb128> cjwatson, thanks
<seb128> pitti, which leads to the trunk template to be used
<seb128> so I guess we need to redo translations in rtm
<cjwatson> Maybe you can push them in bulk?
<seb128> or at least revalidate the suggestions that are made from the ubuntu translations
<pitti> seb128: ok, that would *definitively* be wrong; but that's not how I understood message sharing
<pitti> I thought each upstraem and release would always have their own template
<pitti> and then message sharing merely copies matching translations back and forth
<pitti> but not force a different pot?
<pitti> yes, they can be pushed in bulk, it just needs to happen
<pitti> also, so far message sharing actually does seem to work fine
<pitti> at least between trunk and rtm
<pitti> back then, I only translated trunk, and the translations appeared in RTM
<pitti> (those which match the older RTM versions, at least)
<pitti> so "PO sharing" â yes please; "forced POT sharing" â OMGno; that is never ever a correct thing to do
<seb128> pitti, what you describe works accross different series of Ubuntu
<seb128> but rtm is a different distro
<pitti> seb128: message sharing (i. e. po sync) also generally works between upstream and distro
<pitti> I don't know about direct distro to distro, I suppose that doesn't work
<pitti> but rtm <-> trunk and trunk <-> ubuntu should certainly both work, and thus sync that way?
<seb128> pitti, can we enable message sharing without template sharing? if you know how to do so please do it for ubuntu-system-settings ;-)
<pitti> seb128: as I said, until now I thought that message sharing always just synced the po files, and never the pots
<pitti> seb128: i. e. it's the only way of message sharing which I'm aware of
<seb128> hum, k
<seb128> I think it shares template
<pitti> but now I'm very confused
<seb128> because before we had that one before and the list of strings was the one from trunk
<seb128> and not the one from the package build pot
<wgrant> It doesn't share the templates.
<wgrant> However, I think I remember that it won't import Ubuntu *translations*.
<wgrant> Or something like that.
<seb128> wgrant, it was not important the ubuntu build .pot when that setting was on
<seb128> importing*
<wgrant> So if they wildly diverge, you can be missing a lot of translations from Ubuntu.
<seb128> oh, maybe it was only the .pot
<seb128> I guess we can enable the setting again and see what happens on next upload
<pitti> hm, could it be that whatever cjwatson did destroyed the correct translations in RTM?
<pitti> https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/rtm-14.09_rotation_lock_string/+merge/240511 was the MP
<pitti> Orientation -> Rotation
<pitti> https://translations.launchpad.net/ubuntu-system-settings/trunk/+pots/ubuntu-system-settings/es/+translate?batch=10&show=all&search=tion+Lock
<pitti> trunk is missing a POT update, so that one still has "Orientation"
<pitti> yesterday, RTM's translations were correct: https://translations.launchpad.net/ubuntu-system-settings/rtm-14.09/+pots/ubuntu-system-settings/es/+translate?batch=10&show=all&search=tion+Lock
<pitti> i. e. that one had "Rotation Lock" yesterday
<pitti> now it has "Orientation Lock" again
<wgrant> It couldn't have changed the template.
<wgrant> It could have altered some of the translations, but not the msgids.
<wgrant> (translation splitting is dreadfully buggy and should be avoided whereever possible, but it cannot corrupt the actual template)
<pitti> wgrant: ah ok, so POTs are never ever copied between project and distros, with or without message sharing?
<wgrant> Unless I gravely misunderstand it.
<pitti> wgrant: that's how I understand it as well; copying POTs around would be just wrong
<pitti> wgrant: ok, at least we believe the same thing :)
<pitti> I just wonder how the RTM translations regressed since yesterday
<seb128> pitti, how regressed?
<pitti> seb128: RTM translations had "Rotation Lock" yesterday
<seb128> pitti, it still has, https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/535/+translate
<seb128> pitti, https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/es/535/+translate
<wgrant> https://launchpad.net/ubuntu-rtm/14.09/+queue?queue_state=3&queue_text=ubuntu-system-settings
<pitti> seb128: hm, curious -- https://translations.launchpad.net/ubuntu-system-settings/rtm-14.09/+pots/ubuntu-system-settings/es/+translate?batch=10&show=all&search=tion+Lock doesn't
<pitti> oh, wrong URL then I suppose (that one is in my firefox history)
<pitti> seb128: ok, then I just looked at the wrong URL today, it seems
<seb128> good
<seb128> so things should be sorted out
<seb128> wgrant, cjwatson, pitti: thanks
<jamespage> didrocks, hey - can you steer clear on systemd enablement for the openstack core packages - or follow the pattern that we have for nova, cinder and keystone already
<didrocks> jamespage: hum, unsure about what's not clear, I tried to follow the pattern that were used in the upstart jobs
<jamespage> didrocks, so we are adopting the openstack-pkg-tools tooling to generate upstart, init and service files from a single configuration template
<jamespage> didrocks, eg - https://launchpadlibrarian.net/194321367/keystone_1%3A2015.1~b1-0ubuntu1_1%3A2015.1~b1-0ubuntu2.diff.gz
<didrocks> jamespage: ah, wasn't aware about that, sounds weird that openstack would have their own pkg integration, but in that case, I'll let handle your package transitions I guess
<jamespage> didrocks, zigo has done a good job on this in Debian so its mostly cherry picking the init.in files and enabling the bits for rules and control
<jamespage> didrocks, the reality is that pretty much every service/upstart/init file is much the same apart from the daemon, config-file and log-file names
<didrocks> jamespage: I'm always checking what debian did and eventually merge, but AFAIK, I did only touch here some ubuntu-only packages
<didrocks> ok, hence the generation, makes sense then
<jamespage> didrocks, happy for you to leave it to my team - coreycb will be working on this
<didrocks> jamespage: great, clock is ticking though if we want to do the switch ;)
<jamespage> didrocks, I know
<jamespage> didrocks, it should all be done in the next few working days
<coreycb> jamespage, agreed should be done soon
<didrocks> jamespage: nice :)
<infinity> pitti: I can pull it in.
<pitti> infinity: ack, then I unsub'ed ubuntu-sponsors, to avoid someone else uploading the whole thing
<pitti> stgraber: you might have missed my question from yesterday, or I missed your response -- what is the problem with virtual network interface bringup?
<pitti> stgraber: "bond interfaces do not work because they're fully virtual and do not have udev events"
<pitti> "same for vlans and bridges"
<pitti> stgraber: if they are defined in /etc/network/interfaces, they should just work? or don't they?
<pitti> stgraber: or do we have some upstart job which creates those from some different config files, which we need an equivalent unit for?
<stgraber> pitti: if everything's defined in /etc/network/interfaces and all devices exist at the time ifup -a is called, it all works fine
<stgraber> pitti: the problem is that you don't have to specify them all and some may show up later
<pitti> stgraber: well, virtual devices don't "exist" before you ifup them?
<stgraber> pitti: for example you can specify a bridge interface with bridge-ports set to eth5.1000
<pitti> stgraber: if you don't specify them in /e/n/i, then where else?
<stgraber> neither eth5 nor eth5.1000 have to be defined in /e/n/i
<pitti> stgraber: ok, so problem 1 is that if /e/n/i has a bridge to eth5.1000, and eth5.1000 comes up later, at that point we need to bring up the bridge
<stgraber> the current code is simply that when eth5 does show up a udev rule will trigger, will check existing interfaces in /e/n/i, find the bridge, fine the interface in the bridge-ports and create the vlan on it
<stgraber> right
<pitti> stgraber: but it sounds like there is another case for "they are not defined in /e/n/i"?
<stgraber> a good chunk of this is done through udev hooks today and they may actually be working fine regardless of the init system so long as systemd will always call ifup --allow=auto $INTERFACE whenever a udev net-device-up event is received AND call ifup -a at some point in the boot sequence
<pitti> stgraber: net-device-up is an upstart event, not udev :)
<pitti> (obviously we won't get them under systemd)
<pitti> stgraber: at the moment we call ifup -a (through /etc/init.d/networking) during boot, and ifup <iface> through ifup@.service (udev triggered) for a hotplugged card
<pitti> stgraber: so I guess the problem is that ifup <iface> only ups that iface, but not its "reverse depenencies"?
<stgraber> pitti: net-device-added, sorry
<stgraber> pitti: so if we want to mimick the upstart world, we need:
<pitti> stgraber: never heard that, but I suppose this is just ACTION==add|remove, SUBSYSTEM="net"
<stgraber>  - call ifup --allow=auto <interface> whenever we get a net-device-added from udev (or the systemd name of it)
<stgraber>  - call ifup -a in the boot sequence
<pitti> stgraber: that's what currently calls ifup@.service
<pitti> stgraber: ok, understood
<stgraber>  - possibly update the ifupdown hook to get something like our existing static-network-up event in systemd (so services can know that we're done briging everything up)
<pitti> stgraber: net-dedvice-added is still upstart, not udev, but I think I know what you mean
<pitti> stgraber: anyway, I think I understand the problem now, thanks for explaining!
<stgraber> pitti: right, it's the name of the upstart event as pushed by the udev <-> upstart bridge
<pitti> stgraber: and I have a reasonably good idea how to automate a test for this
<LocutusOfBorg1> pitti can you please loook again at #1408939 ?
<LocutusOfBorg1> I tested both patches successfully
<stgraber> static-network-up may be treaky-ish to implement with systemd. The idea behind it is that it's something jobs can depend on which is only triggered when all defined (auto) interfaces are up OR after a 2 minutes timeout.
<stgraber> the way this is done is that we have an ifupdown up.d hook which has the logic to figure out whether everything was brought up and if that's the case, the event is emitted through upstart
<pitti> stgraber: I updated the whiteboard to: virtual interfaces (bond, vlan, bridges) in /etc/network/interfaces do not work. E. g. /e/n/i might define a bridge for "eth1.5000" which only appears later on during runtime, thus isn't covered by "ifup -a". Thus ifup@.service needs to bring up not just the hotplugged interface but all of its reverse dependencies.
<pitti> stgraber: does that sound like a correct summary?
<stgraber> on the upstart side we have a job which is triggered at boot and has a 2 minute wait loop. That job is stopped when static-network-up is emitted (cancelling the wait loop). If it's not emitted within 2 minutes, then that job emits it and unblocks the boot sequence.
<stgraber> pitti: no. I think the rdepends logic should basically just work with systemd since (and I just re-checked), it's currently mostly done through udev hooks directly and not custom upstart jobs
<pitti> stgraber: so that's like "Depends=networking" with an additional timeout?
<pitti> stgraber: ah, even better
<pitti> stgraber: well, then at least the "write an autopkgtest for this" part should hold, and we have a written down explanation what that problem is :)
<stgraber> pitti: I'm not very familiar with systemd, but that sounds about right, networking there being the equivalent of our current static-network-up, that is, something becoming true when all interfaces have been brought up OR a 2min timeout has been reached
<pitti> LocutusOfBorg1: queued, but probably not today any more; Monday morning?
<pitti> stgraber: "networking" is just /etc/init.d/networking, nothing magic
<pitti> stgraber: we don't currently have a timeout for that; if ifup -a fails, the unit fails, and everything depending on it won't be started
<pitti> FWIW, I'm not saying that Depends=networking is a good idea -- it's a bad one
<stgraber> pitti: ok, so I guess an equivalent would be to define a unit called static-network-up (if we want to make the names match, I don't know) which does the check we've got in /etc/network/if-up.d/upstart every second or so with a 2min timeout
<slangasek> stgraber, pitti, hallyn: so regarding cgmanager, it seems that we have a rough agreement that we do want cgmanager to be running and UAL to use it when pid1=systemd, correct?
<stgraber> that'd give us the same functionality but in a systemd world and /etc/network/if-up.d/upstart simply wouldn't do anything with systemd
<pitti> stgraber: if we need that as a dependency for upstart jobs to convert, we can do that, yes
<pitti> stgraber: just to be sure -- that's totally unrelated to the virtual iface problem, right?
<slangasek> if so, can we just make that change now for Ubuntu, and deal with any fallout later, unblocking the unity8 desktop?
<pitti> slangasek: from my POV, yes
<stgraber> pitti: we need that to keep providing some reliability to server, yes. Currently services depending on network to be ready will simply be racy under systemd and that's not acceptable.
<pitti> slangasek: the main point I'd like to clarify is what cgmanager does at startup, i. e. whether it mounts /sys/fs/cgroups differently or alters the layout in a relevant way
<stgraber> pitti: (when thinking of servers that can take minutes before all network cards are done showing up at boot)
<LocutusOfBorg1> pitti, I don't get the "queued", means "uploaded/waiting for accept?" or queued in your personal todolist? ;)
<pitti> slangasek: but I tested it on a spare laptop, and that seemed to work reasonably well
<LocutusOfBorg1> I subscribed again -sponsors
<LocutusOfBorg1> :)
<pitti> stgraber: well, a two minute timeout is racy :)
<pitti> stgraber: services which make that assumption are broken by design; it's just a workaround
<pitti> stgraber: but if we need it, we can provide something similar for sure
<pitti> LocutusOfBorg1: into my personal todo list, I meant; sorry
<stgraber> pitti: services which allow you to set the IP address that you want to bind and are fine starting up before the IP is configured are very very rare :)
<LocutusOfBorg1> ok wonderful
<LocutusOfBorg1> so I'll wait for you ;)
<LocutusOfBorg1> have a nice weekend, and feel free to ping me by mail
<LocutusOfBorg1> if needed
<pitti> LocutusOfBorg1: please do re-subscribe sponsors, though; no need to block on me particularly
<LocutusOfBorg1> already done ;)
<pitti> stgraber: so, I'll add another work item for that then
<pitti> stgraber: I still don't understand how static-networking-up prevents races rather than introducing them, but *shrug*, I'll just look into mimicking the current behaviour then :)
<LocutusOfBorg1> bye folks!
<pitti> LocutusOfBorg1: bye!
<stgraber> pitti: it solves the case where the main networking job is run before all the hardware showed up by allowing an extra 2min window for everything to be up
<pitti> stgraber: ah, so that way around; thanks!
<pitti> stgraber: OOI, where is the 2 minutes timeout in the upstart jobs or the ifupdown hook?
<seb128> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> /etc/init/networking.conf doesn't have that, and neither /etc/network/if-up.d/upstart
<stgraber> pitti: upstart (/etc/init/failsafe.conf)
<stgraber> pitti: we wait 20s, show a message, wait 40 more seconds, show another message, then wait a whole more minute and give up
<pitti> stgraber: ok, but how does that emit static-networking-up after 2 mins?
<stgraber> pitti: hmm, very good question :)
<pitti> stgraber: I thought s-n-u would be emitted after "all interfaces present" or "two minutes gone"; failsafe.conf looks more like an interactive boot question
<pitti> err, not question, just message
<stgraber> pitti: so apparently we don't (I was sure we did!) instead things are apparently supposed to depend on "static-netowrk-up or failsafe-boot"
<pitti> ah, rc-sysinit.conf
<stgraber> pitti: I guess the design was that for things simply starting on a runlevel, it'd all be fine
<pitti> that has "start on (filesystem and static-network-up) or failsafe-boot"
<stgraber> because we only process the regular runlevel jobs on static-network-up or failsafe-boot
<stgraber> right, that
<pitti> (which is the only consumer of failsafe-boot)
<pitti> but that only runs rcS, not rc2 or others
<stgraber> sorry, implemented all that stuff in oneiric, been a while :)
<pitti> ok, enough for this week; have a good weekend everyone!
<pitti> stgraber: heh, no worries; thanks for the heads-up!
<stgraber> pitti: I don't think it's only rcS, the last line calls telinit which will trigger the other rcX, no ?
<pitti> stgraber: possibly, yes
<pitti> stgraber: it still leaves the question that other upstart jobs that expect static-network-up will never get it
<pitti> that might or might not be intended
<pitti> anyway, timeout, my wife is complaining rather loudly now :)
 * pitti waves
<stgraber> yeah, not sure how many cases we have of people using static-network-up only
<stgraber> I sure have been doing it for local jobs in the past and now understand why some of those were still racy (and shall fix them) :)
<hallyn> pitti: slangasek: stgraber: on, cgmanager makes no changes to the cgroups it mounts.  well, it makes no changes if they were pre-mounted.
<hallyn> If they were not pre-mounted, then it sets a release-agent
<hallyn> but that means systemd was not running on the host
<hallyn> I suppose actually we could similarly only act on name=systemd if we find that controller was pre-mounted
<hallyn> hm, no, that'll produce more differnet cases to debug, forget that
<bu5hm4n> hello, can someone point me to a correct appIndicator Spec. ? :)
<bu5hm4n> or Documentation
<bu5hm4n> https://unity.ubuntu.com/projects/appindicators/ those links are bringing me to a 404
#ubuntu-devel 2015-01-10
<israel> hi, I am looking into building a custom JWM based distro and wanted to know what needs to be installed, and configured to use oem-config properly.  jwm does not use openbox or metacity, etc... (the oem-config recommends includes these in OR statements).  Is there something for my xsession (or other) that I need to check, or disable?  I can post a link to my xsession code located on launchpad
<sarnold> israel: just bsaed on the package names, it looks like you could pick a gtk based or a qt based frontend, whichever one would feel most appropriate..
<sarnold> israel: I've never run it before but I suspect if it depended upon a specific window manager, the deps would indicate that, so probably whatever window manager you use should work
<israel> sarnold thanks, but it does not run correctly.  on reboot (after preparing) it boots to a black screen.  The gtk theme is also messed up if I run it from a working session
<sarnold> israel: aha; anything in the logs or xsession-errors?
<sarnold> israel: can you ssh -X -Y in to the host and run it that way? maybe it'll report errors differently in that case
<israel> I have my own custom xsession, so is there something I need to be loading (or give permissions to) in order for things to run correctly?
<israel> sarnold I have my own custom xsession, so is there something I need to be loading (or give permissions to) in order for things to run correctly?
<sarnold> israel: sorry, I don't know. Does oem-config need to run as root?
<israel> sarnold thanks for helping... the oem-config starts up at reboot automatically... and I do not think you need to run it as root, but it may need some permissions provided by a display manager like lightDM that I do not have using something else.
<sarnold> israel: oh, interesting. hrmm. Sorry, I wish I could offer something better :)
<israel> sarnold, yeah no problem... I am not sure who to ask, or where to start looking... as Ubuntu is so well integrated, I am not sure what I am supposed to look for :)
#ubuntu-devel 2015-01-11
<xnox> ev: CI Train Bot <${CITRAIN_USER}@canonical.com> =)))) lol
<xnox> no idea where to report this.
<xnox> https://code.launchpad.net/~phablet-team/location-service/trunk
<xnox> also no idea where to contribute to location service now.
<mitya57> that <${CITRAIN_USER}@canonical.com> shows up in many branches
<mitya57> Mirv, hi, can you please subscribe ~ubuntu-qt-packagers to qtwebsockets and qtenginio (and add them to the package list in team description)?
<Mirv> mitya57: done
<rlaager> Any idea why the PPA build bots can't find libmessaging-menu-dev? https://launchpadlibrarian.net/194570994/buildlog_ubuntu-trusty-amd64.pidgin_1%3A2.10.11-1ubuntu0%2Bpidgin1.14.04_FAILEDTOBUILD.txt.gz
<cjwatson> rlaager: That's not the error message you're getting.
<rlaager> cjwatson: Hmm. I swear it was in one of my builds. But yeah, I see your point.
<cjwatson> "missing" there just means "not installed yet".  The relevant bit is from "The following packages have unmet dependencies:" on, which indicates that there's some problem with installing libgadu-dev (possibly only in combination with other packages there).
<cjwatson> Could be that for trusty you need libgadu-dev to be built against gnutls26 rather than gnutls28.
<cjwatson> (I forget the details.  Maybe libgnutls-dev.)
<cjwatson> There've been various gnutls26->gnutls28 transitions along the way and they need to be at least partially coordinated.
<rlaager> Well, I'm only building on trusty because I couldn't get utopic to go. Utopic is not failing because of a gnutls issue. It gets to ./configure stage if I remove libmessaging-menu-dev from the Build-Depends.
<rlaager> I think it's building now, so maybe I'm just confused. I should've kept the old buildlogs.
<rlaager> cjwatson: I have an up-to-date Trusty system here. If I run the apt-get install line from the buildlog, it is perfectly willing to install libgnutls28-dev.
#ubuntu-devel 2016-01-11
<infinity> LocutusOfBorg: Ahh, lovely, builds *everywhere*, it seems: https://buildd.debian.org/status/package.php?p=arrayfire&suite=unstable
<pitti> Good morning
<dholbach> good morning
<seb128> pitti, bug #1532722 seems new from the ifupdown 0.8.5+ update
<ubottu> bug 1532722 in ifupdown (Ubuntu) "/sbin/ifup:11:__GI_strncpy:strncpy:do_interface:main" [Undecided,New] https://launchpad.net/bugs/1532722
<seb128> though e.u.c has no backtrace for some reason, just the signature one
<pitti> seb128: hm, that function has six strncpy() calls; I wish we had at least an unretraced one
<seb128> unsure why there are no backtrace on the error page
<seb128> bdmurray might be able to help there?
<rbasak> Pharaoh_Atem: o/
<LocutusOfBorg> hi, can anybody retry gnuradio build on arm64 on a real hw?
<rbasak> Pharaoh_Atem: I'm just replying to your email now.
<LocutusOfBorg> pitti, ^^^ (thanks for arrayfire fix)
<rbasak> LocutusOfBorg: you want me to press the rebuild button?
<rbasak> "virtual memory exhausted: Cannot allocate memory"
<rbasak> It might be worth trying I guess. Or is the buildd never going to be able to manage it?
<rbasak> (as currently configured)
<pitti> cjwatson, smoser: do you know some background about why open-iscsi does that "tell ifupdown that the interface is already up" dance? it seems wrong to have an ifupdown config for the iscsi interface, as the latter is handled by the initramfs
<pitti> and "ifdown eth0" should never work in that case
<pitti> Debian does not do anything like this either
 * pitti finds bug 457767, but it seems this got already fixed in partman-iscsi?
<ubottu> bug 457767 in partman-iscsi (Ubuntu Karmic) "karmic: iSCSI root: boot hangs on starting iscsid" [High,Fix released] https://launchpad.net/bugs/457767
<pitti> having a "manual" stanza should work as well, but then we also don't need this ugly hack
<pitti> i. e. I wonder if we really still need this in open-iscsi
<LocutusOfBorg> quick question, how can I test an s390x and powerpc fix? does Ubuntu have an developer machine?
<LocutusOfBorg> doko, https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.7/+bug/1532716/comments/1
<ubottu> Launchpad bug 1532716 in llvm-toolchain-3.7 (Ubuntu) " llvm-toolchain-3.7 FTBFS on powerpc and s390x [SRU]" [Undecided,New]
<LocutusOfBorg> it should be ok, but I don't like to blindly upload
<xnox> LocutusOfBorg, i can test things for you.
<xnox> LocutusOfBorg, there is no community access to ubuntu porter boxes for those architectures at the moment.
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+files/llvm-toolchain-3.7_3.7.1-1ubuntu3.dsc
<LocutusOfBorg> xnox, ^^^ :)
<LocutusOfBorg> or in the bug #1532716
<ubottu> bug 1532716 in llvm-toolchain-3.7 (Ubuntu) " llvm-toolchain-3.7 FTBFS on powerpc and s390x [SRU]" [High,Confirmed] https://launchpad.net/bugs/1532716
<LocutusOfBorg> I think we can also SRU to wily
 * LocutusOfBorg if it works lol
<xnox> LocutusOfBorg, urls to a librarian are not helpful. =)
<xnox> LocutusOfBorg, url to the ppa would be better.
<xnox> found it.
<xnox> LocutusOfBorg, will build here - https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages
<LocutusOfBorg> thanks!
<pitti> doko, smoser: FTR, I forwarded most of our open-isci changes to Debian, but debian bug 797112 lists some issues which should get fixed before we merge
<ubottu> Debian bug 797112 in open-iscsi "open-iscsi: Prevent testing migration" [Serious,Open] http://bugs.debian.org/797112
<pitti> and I think we should drop the above ifupdown state hack and (if still necessary) fix our installer instead
<LocutusOfBorg> thanks xnox
<pitti> smoser: then our remaining delta would be the open-iscsi-utils transitional package (can go after xenial), and the extra autopkgtest
<LocutusOfBorg> rbasak, unfortunately retrying the build doesn't help, unless you can force it on a real arm64 hardware
<rbasak> LocutusOfBorg: ah, OK. I can't do that, sorry. This may need help from #launchpad people.
<LocutusOfBorg> I can retry builds, but not in different machines
<LocutusOfBorg> infinity, did it for another package ^^^ :)
<LocutusOfBorg> maybe fixing the configuration might help even better ;)
<xnox> what other packages are you talking about?
<LocutusOfBorg> gnuradio
<LocutusOfBorg> arrayfire is fixed (but it has the same issue each time I upload a new debian version)
<cjwatson> pitti: I'm assuming it was to do with booting a live image off iSCSI or something, but I'm afraid I really don't remember
<cjwatson> LocutusOfBorg: the bare-metal arm64 builders are going away in the nearish future.  is there no other workaround at all, perhaps reducing concurrency?
<LocutusOfBorg> cjwatson, how can I reduce concurrency? I just have --parallel set, you choose the parallel concurrency I think
<LocutusOfBorg> I think with DEB_BUILD_OPTIONS=parallel=2 it might work
<cjwatson> LocutusOfBorg: there's a --max-parallel option
<cjwatson> LocutusOfBorg: but I haven't looked closely at this case, it's just that "please retry on bare metal" is a very limited strategy and won't work for long
<LocutusOfBorg> the problem is that many packages have this issue
<cjwatson> LocutusOfBorg: Uh, no, this is very rare
<LocutusOfBorg> well, so gnuradio and arrayfire are the only two? :) nice then
<LocutusOfBorg> xnox,  thanks you can drop the build!
<LocutusOfBorg> it is fine now
<LocutusOfBorg> not sure if the message has been received but xnox thanks, you can drop the build of llvm
<ricotz> Laney, https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1532799
<ubottu> Launchpad bug 1532799 in gettext (Ubuntu) "[Merge] gettext 0.19.7-2 from debian unstable" [Undecided,New]
 * Laney teleports
<Laney> thanks!
<cyphermox> good morning!
<ricotz> doko, hi, do you have any plans to update libtool to its recent release?
<ricotz> Laney, whoa, did you confirm that there is going to be a gstreamer 1.8 release in time for xenial?
<Laney> there will be
<Laney> upstream asked for it too
<ricotz> ah good :)
<smoser> pitti, "I think we should drop the above ifupdown state hack and (if still necessary) fix our installer instead"
<doko> ricotz, it's in sync
<smoser> the point of that is really to prevent bouncing the network interface over which / was mounted in the initramfs.
<smoser> unless we're convinced that systemd somehow makes it unnecessary to do that.
<ricotz> doko, I am more speaking of upstream releases
<ricotz> and yeah, of course in debian ( where only you dared to touch it in the last 2 years ;-) )
<doko> ricotz, package it and put it in a ppa
<ricotz> doko, so there is no actual known breakage which is holding this back?
<doko> ricotz, look at the build log for that answer
<ricotz> not quite an answer, but I assume you tried it then, I just ran into it due a libtool.m4 version mismatch, so I didnt look at the package itself yet
<doko> ricotz, no, I did not. so if you want to know it, you have to package it
<ricotz> alright, that is more clear
<pitti> smoser: this is between d-i, open-iscsi, and ifupdown, doesn't involve init
<pitti> smoser: why would it bounce the network interface?
<pitti> smoser: it would do that if ifupdown had a config stanza for it, but it really really shouldn't
<pitti> smoser: or a "manual" one at least, but certainly not "dhcp" or something
<smoser> pitti, that is a good point. however, it is tricky in something like a cloud or a maas image.
<smoser> where the goal is to distribute an image that can be booted with iscsi root without modification of the image in any way.
<smoser> the image has 'auto eth0'
<smoser> but the user booted the kernel/initramfs with iscsi root and ip=
<smoser> having *no* network configuration in /etc/network/interfaces would make the image useless for many other purposes.
<pitti> smoser: ah, so this isn't a d-i issue, but to counteract static configuration in our cloud images?
<pitti> smoser: that's the kind of background I was missing :) (it's not documented in the changelog)
<pitti> hardcoding an eth0 config in the cloud image itself is bad for other reasons, though
<smoser> well... cjwatson added that code long before i was around (or the cloud images)
<pitti> but at least if we did that in the past, i. e. we have existing installs which have a "dhcp eth0" with open-iscsi we mustn't break that on upgrades
<smoser> there is a more general issue that could be solved though, and then open-iscsi woudln't have to solve it itself.
<smoser> if the intiramfs brings up a network devcie (and intends for that device to be left up), then it should be able to signal that to the init system in some way.
<pitti> s/init system/ifupdown/
<smoser> well, they're kind of one and the same from one perspective.
<smoser> i have to convince *something* to not unconfigure it.
<smoser> and also, in the use case we have, resolvconf also needs keeping
<pitti> well, I think we should have done this by not telling ifupdown to configure eth0 in the first place then
<pitti> configuring ifupdown one way and then adding a hack to not do it after all was what I was wondering about
<smoser> pitti, well how would you do that ?
<smoser> we want to have one image that supports iscsi root booting and also booting in cloud environment with metadata coming from a network.
<smoser> i'd much rather not distribute 2 images that have something ont he order of 32 bytes of delta in one file in /etc
<pitti> smoser: no, of course not
<smoser> i have work to do in this area, and i'd love for your input on it.
<pitti> smoser: IMHO network config (or iscsi, depending on how you configure it) should be set up by cloud-init or some installer dynamically, not hardcoded in an image
<smoser> right.
<pitti> smoser: e. g. when you boot it in QEMU with some custom options, eth0 doesn't even exist
<smoser> pitti, i agree. i'd really like your help/input on getting this right.
<pitti> smoser: oh, since IRC has so little bandwidth: this wasn't meant as an assault or anything, I was just wondering about the history of it and whether we could improve thisi
<smoser> :)
<smoser> i have it on my list of things to improve
<smoser> and i owe jgrimm a doc on what we plan to do too.
<pitti> smoser: so, for sure we need to deal with existing systems that have a dhcp config + iscsi on eth0
<smoser> so how about i get that together and share it with you... attempt to list what things we're hoping to acommplish.
<pitti> thinking aloud -- we could do that in a postinst snippet by replacing /etc/network/interfaces.d/eth0.cfg  if eth0 is the iscsi root mount
<pitti> (if/once we have a solution to not set up newly installed systems that way)
<pitti> (replace it with "manual eth0")
<pitti> err, "iface eth0 inet manual" I think is what I meant
<pitti> smoser: how does the current image "know" that it should configure itself for an iscsi boot?
<pitti> smoser: I thought in that case you don't even boot the actual cloud image, but you get the root fs served over PXE boot, no?
<smoser> hm..
<smoser> so actually right now, we have cloud image, which does not really expose the external kernel/initramfs/kernel-command line.
<smoser> so iscsi root is not *really* an option there.
<smoser> it has a hard coded eth0 in e/tc/network/interfaces
<smoser> that is a pain for reasons you're aware of (systemd device naming)
<smoser> then we have the maas image... which largely *is* the iscsi root with 32 bytes of delta in /etc :)
<smoser> in the maas image, currently, we have /etc/network/interfaces as a symlink to /run/network/dyn-netconf-interfaces (or some such)
<smoser> that target of that link is managed by cloud-initramfs-dyn-netconf
<smoser> that initramfs package basically writes a /etc/network/interface file there that has the interface that was brought up in the initramfs as the only one.
<pitti> smoser: that sounds useful for non-MaaS use cases as well, like using it in qemu, LXC, or snappy?
<smoser> pitti, can i spend today trying to write some of this in a well formed manner and then have you read it and we discuss ?
<pitti> smoser: sounds great
<smoser> pitti, i *really* appreciate your input here.
<pitti> smoser: in the meantime, let's see what Christian says about adopting the other two changes; I suppose merging open-iscsi isn't really urgent?
<smoser> ah. yeah... i've had some interaction with Christian
<smoser> with the goal of getting rid of our delta
<pitti> I think doko just stumbled over it when he reviewed the "not merged in ages" list, it's not an OMGweneeditnow
<smoser> and he is open to carrying ubuntu specific and non-intrusive patches
<smoser> ie, as long as they're not negatively affecting debian, he's ok to have code that is only going to run on ubuntu.
<pitti> smoser: if we could replace the ifupdown messing with a postinst snippet and drop that post-16.04, that'd be nice indeed
<smoser> Christian was very helpful when i chatted with him.
<pitti> smoser: I think that this ifupdown state file nudging might have broken with the new ifupdown, the native networking.service does not do that "is the root fs a network mount" check any more
<pitti> smoser: oh yes, he's great; I met him at debconf
<pitti> I'm sure we can massage the extra autopkgtest in a form that doesn't require testlib.py, then he'll surely take this too
<smoser> can you determine inside an autopkg test if you're ubuntu ?
<smoser> ie:
<smoser>  #ifdef UBUNTU
<smoser>    run these tests with testlib.py
<smoser>  #endif
<smoser> then we'd run them when we synced and he'd not be bothered unless intentionally
<cjwatson> you could have the test depend on dpkg-dev and use 'dpkg-vendor --derives-from Ubuntu'
<pitti> smoser: no, Christian's issue was not that the test wouldn't apply to Debian, but he dislikes the testlib.py thing
<pitti> smoser: i. e. he doesn't want to maintain this
<Saviq> pitti, hey, you know your way around our buildd hosts, any idea where they take sbuild 0.65.2 from? wanted to use it in our Jenkaas
<pitti> Saviq: I actually don't, but that sounds like vivid or wily
<pitti> Saviq: ISTR that Colin said something about "vivid based" the other day
<pitti> but don't take this for granted
<cjwatson> Saviq: https://launchpad.net/~launchpad/+archive/ubuntu/buildd-staging/+packages is current
<cjwatson> Saviq: (for xenial-based buildds, we just use the one in the archive)
<Saviq> cjwatson, oh great, thanks
<cjwatson> np
<Odd_Bloke> xnox: Do you know if the s390x images we're producing ATM would work in lxc?
<Odd_Bloke> xnox: (AIUI, the missing parts are all bootloader-y, which obviously isn't an issue for lxc :)
<xnox> Odd_Bloke, i know that lxc and lxd work, cause autopackage tests use them. I guess i can import the tarballs to validate that lxc off that tarball works.
<xnox> Odd_Bloke, i'm in the middle of doing surgery on the disk1.img, please bare with me =)
<Odd_Bloke> xnox: Sure; just asking so I can clear out my inbox, no rush. :)
<xnox> Odd_Bloke, do cloud images need root= parameter or some such?
<xnox> Odd_Bloke, e.g. how do uefi images on x86_64 boot?
<xnox> i presume just by magic ;-)
<Odd_Bloke> xnox: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-cpc/hooks/033-disk-image-uefi.binary is where we generate the UEFI images.
<xnox> Odd_Bloke, what's CLOUD_IMG_STR ?
<xnox> wait... C
<xnox> sed -i "s,root=.* ,root=LABEL=cloudimg-rootfs ,g" mountpoint/boot/grub/grub.cfg
<xnox> is nice.
<xnox> so i should do the same
<Odd_Bloke> xnox: It's just "# This has been modified by the cloud image build process" or something to that effect.
<xnox> cool.
<rharper> ubuntu-bug linux  on my xenial 64-bit desktop says that linux-image-4.3.0-2-generic isn't an official Ubuntu package
<xnox> Odd_Bloke, /sbin/plymouthd: not found =)
 * xnox ponders why we have plymouth thingies in the initramfs, without plymouth.
<xnox> also RAID arrawys are incrementatlly started =/
<ogra_> how else would we get it bloated to tens of megabytes !
<smoser> barry, are you about ?
<smoser> tox.ini with:
<barry> smoser: yppers
<smoser> http://paste.ubuntu.com/14470834/
<barry> *yeppers
<smoser> tox -e py34-pylint
<smoser> creates a .tox/py34-pylint/bin/python
<smoser> that is python2.7
<smoser> when run on trusty.
<smoser> i thougth/hopwed that because it had 'py34-' in its name there was magic that picked the right python
<barry> smoser: you probably need to set basepython in that toxenv.  iirc trusty's tox does not yet support generated environments, so you have to handle the basepython switch yourself.  in xenial we have a newer tox that supports the generated environments, which is a *really* nice feature
<smoser> oh. ok. that makes sense.
<smoser> so how do i set it ? doc was confusing to me.
<barry> smoser: i think, in the [testenv:py34-pylint] section just add:
<barry> basepython = python3.4
<smoser> ok. the dictionaries shown at http://tox.readthedocs.org/en/latest/config.html were confusing to me.
<smoser> but ... i think you're right. thank you
<barry> smoser: np.  fwiw, i absolutely love http://tox.readthedocs.org/en/latest/config.html#generating-environments-conditional-settings :)
<smoser> barry, but for the base 'py27' and 'py34', it does do the right thing, right?
<smoser> yeah, it seems to.
<smoser> thanks again
<barry> smoser: right, because those envs are built-in
<barry> smoser: also iirc, trusty's tox doesn't know about py35 so you'd have to add a stanza for that explicitly if you want it
<smoser> barry, fudge.
<smoser> so then on trusty, where there is no python3.5
<smoser> what woudl i do to not run the test there ?
<barry> smoser: i'm not aware of a way to have tox conditionally avoid an environment if the basepython is missing, though i think there's been discussion about that upstream.  the best you can do right now i think is either not include py35 in the default set of envs, run tox without -e py35 explicitly, or just ignore the error that tox will give if you do run with -e py35
<smoser> thanks.
<mdeslaur> Laney: whoops, thanks for fixing libosinfo
<Laney> mdeslaur: np!
<nacc> is rmadison an (the?) appropriate tool for determining if a package is in universe or main?
<xnox> nacc, there is $ check-mir, tool too
<xnox> nacc, rmadison queries things differently, but will give accurate info too.
<nacc> xnox: thanks!
<nacc> xnox: yeah, just trying to educate myself on various tools
<Pharaoh_Atem> rbasak: yo
<rbasak> Pharaoh_Atem: hello!
<LocutusOfBorg> is the auto-import from debian broken?
<cjwatson> LocutusOfBorg: No, looks fine to me.
<cjwatson> (You may want to give more details of what you think should have been imported ...)
<LocutusOfBorg> liquidsoap
<LocutusOfBorg> it isn't picked up since 12 h or so
<cjwatson> LocutusOfBorg: That's the upload time; it still needs dinstall to run before we can pick it up, and I suspect it was at a near-worst-case for that.
<cjwatson> LocutusOfBorg: I'd expect to see it in the next sync.
<LocutusOfBorg> mmm strange
<LocutusOfBorg> [11:57:23] <mapreri> LocutusOfBorg: non Ã¨ che fra qualche ora dai un `syncpackage -s mapreri -V 1.1.1-7.1 -f liquidsoap` ? :)
<LocutusOfBorg> at that time it was uploaded
<LocutusOfBorg> the run has been at 14 or so
<LocutusOfBorg> finished at 16 or so
<LocutusOfBorg> and now we are 8 ours later, and debian unstable has it
<cjwatson> LocutusOfBorg: Right, but our mirror updates every six hours.  That "or so" is pretty important.
<cjwatson> We last synced our mirror at 16:05 UTC.
<LocutusOfBorg> cjwatson, damn, I remembered it was around each 30 minutes
<cjwatson> Goodness me, no.
<cjwatson> Never has been.
 * LocutusOfBorg lacks of a sane memory
<LocutusOfBorg> thanks then :)
<LocutusOfBorg> cjwatson, with dinstall going slower each time I guess running the script half an hour later will make many packages picked up early
<cjwatson> I'll check the dinstall logs next time I get a chance.
<LocutusOfBorg> one dinstall already started a few seconds ago, I'll monitor and give you the finish time :)
 * LocutusOfBorg if I don't fall asleep
<cjwatson> LocutusOfBorg: No, don't bother.
<cjwatson> LocutusOfBorg: I'm going to want to check historical logs anyway, not just have a single data point.
<cjwatson> LocutusOfBorg: And don't waste your time monitoring - I'm pretty sure the logs are timestamped.
<LocutusOfBorg> sure, it depends on many factors I guess, specially with many european developers I expect the first one to be slower
<cjwatson> I've been meaning to have it do "check more frequently and run import if Release timestamp changes" for ages anyway, which would obviate the need for that sort of log analysis.
<Pharaoh_Atem> rbasak: did you get my reply to your email earlier today?
<mahmoh1> ping uiteam
<Pharaoh_Atem> does anyone know where I can grab nightly builds of ubuntu xenial?
<Pharaoh_Atem> or at least a netinstaller that lets me install nightly code from the archive
<maswan> alpha1 images and apply updates?
<tarpman> Pharaoh_Atem: http://cdimage.ubuntu.com/daily-live/ and not sure about the latter
<bdmurray> seb128, pitti: that ifupdown crash, bug 1532722, really failed to retrace and several crashes are missing an initial StacktraceAddressSignature
<ubottu> bug 1532722 in ifupdown (Ubuntu) "/sbin/ifup:11:__GI_strncpy:strncpy:do_interface:main" [Undecided,New] https://launchpad.net/bugs/1532722
<Pharaoh_Atem> tarpman: thanks
<rbasak> Pharaoh_Atem: yes. Sorry, the need to sync with nacc and the timezone difference is making things a little awkward. I only got ten minutes with nacc today and that wasn't enough to plan ahead.
<rbasak> Pharaoh_Atem: for testing things with Xenial I suggest using lxc, lxd or uvtool, though I don't know your environment. They make it really quick to manually test things.
<rbasak> Pharaoh_Atem: there are also published daily EC2 images, etc.
<rbasak> Pharaoh_Atem: uvtool uses the published daily cloud images and throws them at libvirt/kvm, or you can use the images directly with something else.
<rbasak> Pharaoh_Atem: we could attempt a Google Hangout or similar to plan things tomorrow maybe? Perhaps with ondrej too?
<rbasak> (and nacc of course)
<Pharaoh_Atem> rbasak: yeah, a Hangout sounds good
<Pharaoh_Atem> My personal system is a Fedora 23 system
<Pharaoh_Atem> so I can build VMs or containers or whatever as I need
<Pharaoh_Atem> and I have access to a personal virtualization server for whatever I need to do
<Pharaoh_Atem> so as long as your images work with KVM, I'm solid
<rbasak> Pharaoh_Atem: http://cloud-images.ubuntu.com/xenial/current/ should be all you need.
<Pharaoh_Atem> are this cloud-init ones or do I need to do anything special?
<rbasak> Pharaoh_Atem: those images use cloud-init though. You'll need to supply cloud-init metadata and userdata to boot a usable system.
<Pharaoh_Atem> hmm
<Pharaoh_Atem> I'm not too good with setting up things with cloud-init :/
<Pharaoh_Atem> I don't suppose you guys spin netinstall ISOs yet?
<rbasak> uvtool does this all automatically, but as I don't use Fedora I have no idea how well uvtool will work on it.
#ubuntu-devel 2016-01-12
<rbasak> I see http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<rbasak> That's full ISOs though, not netboot.
<rbasak> Though not deprecated, we moved on from that stuff for development purposes years ago.
<rbasak> uvtool gives you pretty much instant VM boot. No need to run an installer first.
<cjwatson> http://cdimage.ubuntu.com/netboot/ should have links, let me fix that
<sarnold> uvtool does cloud-init tihngs automatically?
<rbasak> Yes
<rbasak> It just glues cloud images through simplestreams to cloud-init to libvirt.
<sarnold> neat. I've never looked into doing cloud-init by hand but it always seemed a bit of work, hehe
<sarnold> I wanted a "hey stupid type these commands to make it work" sort of guide to cloud-init, and never found one..
<rbasak> sarnold: https://help.ubuntu.com/lts/serverguide/cloud-images-and-uvtool.html
<cjwatson> http://cdimage.ubuntu.com/netboot/ has links for xenial netboot images now
<cjwatson> Pharaoh_Atem: ^-
<sarnold> cjwatson: \o/
<rbasak> sarnold: the uvtool CLI could do with some polish, but the basic functionality has been there a while. I hope the docs haven't rotted.
<rbasak> Thanks cjwatson!
<sarnold> rbasak: thanks :) looks nice and easy
<rbasak> sarnold: np. Looking now, one thing undocumented is how to get a xenial daily image. This involves a wart. You need to run uvt-simplestreams-libvirt with --source to point to http://cloud-images.ubuntu.com/daily (IIRC)
<rbasak> Otherwise you only see "released", which are alphas and betas during development, which is normally not what you want.
<sarnold> it's not necessarily a bad thing to aim users to released releases :)
<sarnold> but a simple --include-devel might be kind
<sarnold> and defaulting to most-recent-LTS is very polite :)
<rbasak> Yeah I'd like a --daily option to the sync command. But sync shouldn't even be necessary. It should pull images on demand.
<rbasak> (sync only exists because I thought Juju would want to use it. But it doesn't)
<rbasak> (Juju uses uvtool internally to provision its KVM submachines)
<sarnold> not having used it myself.. I'm inclined to think a sync is better; it manages expectations of which operations will take two seconds vs two minutes, and helps manage storage..
<bdmurray> seb128, pitti: I manually retraced one and updated bug 1532722 with the Stacktrace let me know if you need more.
<ubottu> bug 1532722 in ifupdown (Ubuntu) "/sbin/ifup:11:__GI_strncpy:strncpy:do_interface:main" [Undecided,New] https://launchpad.net/bugs/1532722
<rbasak> sarnold: that's what I thought originally, but I've changed my mind. While I think I need to be careful to avoid user surprise, I find myself always syncing immediately before firing up a VM. So on demand would save me keystrokes.
<hallyn> pitti: stgraber: so for pam-cgm.  we do not support xenial/systemd container without writeable cgroups (i.e. lxcfs);  i dont' want to complicate pam-cgm;
<rbasak> The entire point of the tool is to save keystrokes, so I think that's an important consideration.
<hallyn> pitti: stgraber: so my thought is i'll write a new pam_lxcfs.so, which conflicts: pam-cgm, and only does lxcfs.   keep the two cleanly separated
<sarnold> rbasak: heh, well, I can see that then :) if you're always running sync beforehand, that might be a logical conclusion to draw
<Pharaoh_Atem> rbasak: it doesn't look like uvtool is packaged for Fedora, so I guess I might as well do that too while I'm at it :P
<Pharaoh_Atem> rbasak: can you point me to the sources for it?
<Pharaoh_Atem> actually, nvm
<Pharaoh_Atem> looks like it's never had a release, and it's a bzr snapshot
<momken> Hello
<momken> I am making the package of GNU Hello for myself to learn how to build a package from scratch
<momken> I followed up to section 6.3 of this tutorial: http://packaging.ubuntu.com/html/packaging-new-software.html
<momken> but after running "$ bzr builddeb -- -us -uc" I get these errors: http://dpaste.com/3K91XEJ
<momken> Please help
<momken> Ooops. the debian/rules file is very tricky. It's making me nuts, especially that I have no idea what to do
<pitti> Good morning
<pitti> bdmurray: thanks for the stacktrace, this is helpful! that pinpoints the strncpy() call and shows that its second argument current_state = 0x1 is bogus
<pitti> hallyn: would it help if systemd itself chowns its own name=systemd controller,  i. e. downsize the current patch? and the other controllers are then handled by pam-cgm?
<pitti> bdmurray: I think I see it
<pitti> bdmurray: nailed it
<hallyn> pitti: that would take care of one case, but it's still possible (right?) that systemd config tell is to create, say, a memory cgroup for the logged-in user
<hallyn> pitti: if that's not something we need to support, then heck yeah thta simplifies it a lot
<pitti> hallyn: I wouldn't know how this would be configured
<pitti> hallyn: and either way, if it would be possible our current patch completely stomps over it, so there's little to regress
<hallyn> pitti: ok, cool.  seems like a plan then
<hallyn> ok, pushed some untested uncompiled test pkgs to ppa:serge-hallyn/systemd to test that out.  (it's late here :)
<seb128> bdmurray, thanks for retracing that ifupdown bug manually, do you know why the retracers didn't work on it?
<seb128> pitti, thanks for fixing it
<dholbach> good morning
<stgraber> hallyn: sounds good. With us getting rid of cgmanager, that's needed anyway.
<dgadomski> hey pitti, thanks for updating bug 1337873
<ubottu> bug 1337873 in ifupdown (Debian) "Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition" [Unknown,New] https://launchpad.net/bugs/1337873
<pitti> dgadomski: I have the fix now, should be trivial to backport
<dgadomski> pitti: do you want me to wait with updating the SRUs until it gets to xenial?
<pitti> dgadomski: no, please go ahead
<dgadomski> pitti: alright, thanks
<pitti> Noskcaj_: hey, how are you?
<pitti> Noskcaj_: backuppc needs a merge to unblock perl; I was looking into it, but there are a loooot of direct changes to the code which aren't documented in the changelog :/
<pitti> Noskcaj_: do you know what's up with them?
<dgadomski> pitti: uploaded new debdiffs to bug 1337873
<ubottu> bug 1337873 in ifupdown (Debian) "Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition" [Unknown,New] https://launchpad.net/bugs/1337873
<pitti> dgadomski: can you please attach debdiffs to what's currently in -proposed? the debdiffs you did are against -release/-updates, i. e. they contain the already uploaded changes
<dgadomski> pitti: oh, got it, I will fix that soon
<dgadomski> pitti: done
<LocutusOfBorg> good morning people!
<rbasak> mvo: around? I think apt's HTTP pipelining support is buggy.
<rbasak> mvo: and that is causing my failure.
<rbasak> I have a pcap of apt fetching stuff, complete with its console output of Hash Sum mismatch.
<rbasak> For one, it is pipelining on the first request, and apt cannot know that the server supports HTTP/1.1
<rbasak> And the requests all respond with 1.0 only, so that's probably why it's broken.
<mvo> rbasak: oh? that sounds like its a very likely cause indeed
<rbasak> mvo: I'm writing up a bug. I don't think I can really attach my pcap publicly, but I can share with you if needed.
<rbasak> mvo: oh, and disabling pipelining worked around the issue.
<pitti> dgadomski: uploaded, thanks
<mvo> rbasak: cool, I think we don't need the pcap file, your description sounds good
<sil2100> Hey guys! Does anyone know where the ppp-modules package comes from?
<LocutusOfBorg> sil2100, http://packages.ubuntu.com/xenial/ppp-modules
<LocutusOfBorg> I looked at that yesterday
<LocutusOfBorg> ppp is stuck :(
<rbasak> mvo: FYI, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810796. The workaround is to disable pipelining.
<ubottu> Debian bug 810796 in apt "HTTP pipelining is broken and causes download failures" [Normal,Open]
<ricotz> doko, hi, I hope you like to take a look at this -- https://launchpad.net/~ricotz/+archive/ubuntu/red/+sourcepub/5955037/+listing-archive-extra -- (the upstream maintainer might do a 2.4.7 in one or two weeks)
<rbasak> tdaitx, kickinz1: looks like the freeipmi upload triggered a mini transition of libfreeipmi12 -> libfreeipmi16. Can you decide between you which of you will drive this, please?
<mvo> thanks rbasak!
<rbasak> mvo: not a problem. "HTTP pipelining is used against HTTP/1.0 servers where it is not permitted, causing download failures" might be a better title.
<rbasak> tdaitx: also, what's the status of the squid3 merge? It's been months!
<rbasak> kickinz1: I guess tdaitx hasn't started his day yet? Can you make sure to check up with him on who will drive the transition please?
<kickinz1> rbasak, yes, I will
<tdaitx> kickinz1, feel free to tackle that, I'm working on a openjdk update right now
<kickinz1> tdaitx; OK
<kickinz1> rbasak, it will be me.
<dgadomski> hi, a user is experiencing crashes while trying to launch Unity in rather unusual configuration: in a VM under PowerKVM on ppc64le. I'm guessing the problem is lack of graphics acceleration. Is Unity supported in such configuration? Is it possible to launch Unity without acceleration?
<xnox> dgadomski, i would expect such users to contact ubuntu advantage support =)
<xnox> dgadomski, unity is launchable without acceleration on some architectures. I cannot comment about ppc64le on powerkvm however.
<xnox> it does launch on e.g. Ubuntu KVM on x86_64 without acceleration.
<xnox> dgadomski, oh, unless you are ubuntu advantage support yourself....
<xnox> =)
<dgadomski> xnox: ;) I was hoping somebody here is able to give an official statement
<kickinz1> rbasak, what has to be done to 'drive a mini transition of libfreeipmi12 -> libfreeipmi16' ?
<kickinz1> rbasak, just asking some pointers while finishing some work before tackling this.
<rbasak> kickinz1: follow http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, documentation in https://wiki.ubuntu.com/ProposedMigration. Right now that says that the following packages become uninstallable: ceilometer-agent-ipmi, ipmitool, nut-ipmi, slurm-client, slurm-client-dbg, slurm-llnl, slurm-llnl-slurmdbd, slurm-wlm, slurm-wlm-basic-plugins, slurm-wlm-basic-plugins-dbg, sl
<rbasak> urm-wlm-basic-plugins-dev, slurm-wlm-torque, slurmctld, slurmctld-dbg, slurmd, slurmd-dbg, slurmdbd, slurmdbd-dbg, sview
<kickinz1> rbasak: thanks!
<rbasak> kickinz1: so find the sources for those binary packages, and see what you need to do to get them to build and depend on libfreeipmi16 instead of libfreeipmi12.
<rbasak> kickinz1: in many cases just rebuilding will suffice.
<kickinz1> rbasak, OK, thanks.
<rbasak> (since it'll build-depend on libfreeipmi-dev or something, and end up linking to the new soname)
<rbasak> kickinz1: to generate a source package for a rebuild, the version number gets bumped. You can use "dch -R" to help with that, including to help script it if needed. Probably this one is small enough that it isn't necessary.
<rbasak> kickinz1: then in the end you should end up with some debdiffs or source packages to sponsor. Perhaps just plain rebuilds, or perhaps with some other changes necessary to make the build work. This may include sending patches to upstream or Debian etc, but in this case Debian have probably done all the necessary bits so you just need to find it.
<rbasak> nacc: ^^ this might be useful for you to follow too, since it'll soon be needed for PHP.
<rbasak> Pharaoh_Atem: ^^ you too, maybe?
<rbasak> Except with PHP it is 800 source packages or something :-/
<gQuigs> is a reverse-recommends enough to keep a package from being autoremoved?   specifically looking at gnome-media package
<cjwatson> gQuigs: what kind of autoremoval?
<gQuigs> cjwatson: it was removed from debian,  the only previous package that was holding it via depends was gnome, but that's fixed now
<cjwatson> gQuigs: it's enough to make us go and look, not necessarily enough to stop us removing it
<cjwatson> let's see what process-removals thinks
<gQuigs> also curious if swac-get comes up on that list
<gQuigs> thanks!
<cjwatson> gQuigs: for autoremoval?  it's still in unstable ...
<gQuigs> well.. oops
<gQuigs> nvm on that
<ondrej> rbasak: I uploaded a share of PECL extensions updated to PHP 7.0 to Debian unstable; but I guess they'll sit in NEW now since I changed s/php5/php/ in binary package names
<ondrej> rbasak: git repos for those should have been updated as well, if you want to start poking before NEW is processed
<rbasak> ondrej: thanks!
<rbasak> nacc: ^^
<rbasak> ondrej: I'm struggling to coordinate with nacc and Pharaoh_Atem a little.
<rbasak> ondrej: but we have able and willing people to help now. Just need to help them along.
<Son_Goku> rbasak & ondrej: hopefully the list from Remi Collet should help some in identifying upgrades to most extensions for php7 compliance
<seb128> cyphermox, did you see bug  #1531779?
<ubottu> bug 1531779 in ubiquity (Ubuntu) "/usr/lib/ubiquity/bin/ubiquity:ValueError:<lambda>:start:prepare:is_secure_boot" [High,New] https://launchpad.net/bugs/1531779
<cyphermox> oops
<hallyn> stgraber: could everyone stop celebrating getting rid of cgmanager? :)  you're going to miss 'cgm create'
<cjwatson> gQuigs: ok, it's gone now, thanks for the heads-up
<gQuigs> cjwatson: thanks!
<nacc> rbasak: ondrej: thanks!
<seb128> Laney, do you know how to debug things like https://errors.ubuntu.com/problem/a3dac922f46ca43928d3a96970531c1678cdf316 ?
<seb128> "Setting up libxrandr2 (amd64 (2) 1.5.0-1) ... dpkg â dependency problems prevent configuration of libgtk-3-bin â libgtk-3-bin depends on libgtk-3-0 (>= 3.18.6-1ubuntu1); however â Package libgtk-3-0 â amd64 is not configured yet. libgtk-3-bin depends on libgtk-3-common (>= 3.18.6-1ubuntu1); however â Package libgtk-3-common is not configured yet. dpkg â error processing package libgtk-3-bin (--configure) â dependency
<seb128>  problems - leaving unconfigured"
<nacc> rbasak: have time to chat today?
<Laney> seb128: more log would be better
<seb128> Laney, unsure how to get those :/
<Laney> turn launchpad apport bugs back on and wait for one :/
<Laney> otherwise it seems to happen in a dist-upgrade so maybe try that
<seb128> https://errors.ubuntu.com/problem/477ffe82ea6059aa20b022e13890b6e0abea7d94 is another similar one on adwaita/h-i-t
<rbasak> nacc: yes please. How about after the IRC meeting?
<Son_Goku> rbasak: are we going to have a hangout sometime today?
<bdmurray> seb128: I'll look into that today.
<nacc> rbasak: sounds good
<seb128> bdmurray, thanks
<rbasak> Son_Goku: yes, we should try to do that today.
<rbasak> Son_Goku: what happened to Pharaoh_Atem?
 * rbasak is confused
<rbasak> Are you the same person?
<Son_Goku> yes
<Son_Goku> Iâm on my laptop atm
<Son_Goku> c.f.: https://launchpad.net/~ngompa13
<dobey> rbasak: he went sayan
<Son_Goku> :)
<Son_Goku> Pharaoh_Atem is my workstation at my office
<Son_Goku> Son_Goku is my personal laptop
<rbasak> Ah, OK
<Son_Goku> all of my nicks are listed on my launchpad profile
<Son_Goku> so, youâll always know who I am :)
<LocutusOfBorg> Son_Goku, I want to see your karma increase, and then say "it is over 9000!!!"
<Son_Goku> haha
<Son_Goku> I tried to make it go up years and years ago
<Son_Goku> but it stubbornly stuck at 5
<Son_Goku> so I gave up on it
<Son_Goku> I suppose it doesnât help that most of my work involved actually working in upstream projects
<Son_Goku> those donât count in launchpad karma :(
<Son_Goku> even if you add references to things like rhbz, etc.
<LocutusOfBorg> hi, anybody there for a qt question?
<LocutusOfBorg> I think we have a big problem on emulated powerpc machines
<cjwatson> emulated in what way?
<LocutusOfBorg> http://paste.ubuntu.com/14478746/
<LocutusOfBorg> this was a mail private
<LocutusOfBorg> the package is dspdfviewer
<cjwatson> is that qemu-user or qemu-system?
<LocutusOfBorg> maybe trying the powerpc build in a real machine might help
<LocutusOfBorg> cjwatson, it is also the powerpc ubuntu build
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/dspdfviewer/1.14-1/+build/8407197
<cjwatson> fisher* and denneed* are qemu-based, yes.  I'm pretty sceptical, but I'll try it on sagari just in case
<cjwatson> It seems more likely to be due to being POWER7-based, though
<cjwatson> sagari is err POWER5 or POWER6?  I forget
<LocutusOfBorg> what does it matter? I mean, why qt4-demos are showing bad colours?
<LocutusOfBorg> isn't this an endianess issue? and how can endianess change on powerpc?
 * LocutusOfBorg has always headaches when it comes to understand endianness
<cjwatson> powerpc is always big-endian
<LocutusOfBorg> exactly, so how it can be a problem in ubuntu and not in debian?
<cjwatson> you have not proven that it is an endianness issue though
<LocutusOfBorg> "ff000000 (as in, opaque black) becomes 000000ff (as in, transparent"
<cjwatson> sure, it certainly looks like it
<LocutusOfBorg> quoting the email
<cjwatson> but until you've actually done a root cause analysis you don't know
<LocutusOfBorg> and also the qt4-demos issue, at least I can say the end user application seems to be correct
<cjwatson> it could be for instance that Ubuntu's Qt has an endianness bug that Debian's doesn't
<cjwatson> or all kinds of things like that
<LocutusOfBorg> exactly, I was thinking something like that
<LocutusOfBorg> for sure seems that the testsuite was correct at the end
<LocutusOfBorg> now I'm setting up some pbuilder powerpc environment
<cjwatson> I wouldn't waste your time trying with something based on qemu-user-static
<LocutusOfBorg> oh ok
<cjwatson> qemu-user can't deal with threads at all reliably so it tends to be a hopeless pile of failure with anything Qt-related
<cjwatson> (fisher* and denneed* are qemu-system on POWER7 hardware)
<cjwatson> LocutusOfBorg: I'm assuming that the pbuilder business from the email you quoted was running on x86; in that case there's necessarily an endian-flip going on with qemu-user, and certainly room for error there.  But we're not emulating powerpc on x86
<cjwatson> This is why I was asking whether you were talking about qemu-user or qemu-system
<cjwatson> LocutusOfBorg: Anyway, it fails on sagari (bare metal) too: https://launchpad.net/ubuntu/+source/dspdfviewer/1.14-1/+build/8407197
<cjwatson> Or indeed https://launchpadlibrarian.net/233933347/buildlog_ubuntu-xenial-powerpc.dspdfviewer_1.14-1_BUILDING.txt.gz
<cjwatson> LocutusOfBorg: So that rules out qemu IMO
<LocutusOfBorg> ok it leaves a qt4 issue?
<cjwatson> LocutusOfBorg: Or anything else in the build-dependency chain (perhaps even including the kernel).
<rbasak> Son_Goku, nacc: shall we try for a Hangout in about twenty minutes (on the hour, 1700 UTC)?
<cjwatson> LocutusOfBorg: Needs direct debugging, I expect.
<Son_Goku> rbasak: sure
<rbasak> Son_Goku: shall I send an invite to your work address?
<rbasak> ondrej: would you like to join us?
<cjwatson> LocutusOfBorg: That said, now that I've noticed that the person you were talking to said they could reproduce it in pbuilder, maybe this particular case doesn't run into the usual qemu-user threading bugs and you can attack it that way after all.
<Son_Goku> Iâm about to head to work, so I should be available as Pharaoh_Atem by then
<Son_Goku> Iâll ping you when I get there
<Son_Goku> send to my personal one
<rbasak> OK
<rbasak> Son_Goku: uh,
<rbasak> Son_Goku: which is your personal one?
<Son_Goku> rbasak: ngompa13@gmail.com
<rbasak> OK
<nacc> rbasak: sounds good
<rbasak> Son_Goku, ondrej: invites sent. You should have an email with a link.
<LocutusOfBorg> thanks cjwatson we will continue investigating
<rbasak> (nacc too but I assume he knows the drill)
<Son_Goku> rbasak: https://git.launchpad.net/~nacc/+git/php7tracking/tree/package-list.rdepends.src.split.working
<rbasak> Son_Goku: http://packages.ubuntu.com/wily/mythtv
<rbasak> Son_Goku: https://launchpad.net/ubuntu/+source/php-pecl-http
<rbasak> https://sources.debian.net/src/php-pecl-http/2.0.4-1/
<rbasak> https://sources.debian.net/src/php-pecl-http/2.0.4-1/debian/control/
<smoser> jibel, https://code.launchpad.net/~canonical-platform-qa/ubuntu-test-cases/server-preseed/+merge/282346
<smoser> did you test the change? does it actually fix ?
<bdmurray> seb128, pitti: it was considered failed b/c the retraced report had no SAS.
<seb128> bdmurray, because not enough functions in the bt?
<bdmurray> seb128: it has more than 2 lines in the StacktraceTop ... still digging
<seb128> k
<jibel> smoser, Max tested it and said it fixed the issue. But reading your comment and bug 1355845, I'll ask him to confirm.
<ubottu> bug 1355845 in partman-base (Ubuntu) "partman/unmount_active is not preseedable" [Undecided,Confirmed] https://launchpad.net/bugs/1355845
<smoser> we should open a bug on d-i too
<smoser> that is a questionable behavior.
<jibel> smoser, I opened bug 1533243, not sure if the behaviour is expected or not
<ubottu> bug 1533243 in debian-installer (Ubuntu) "preseeded installation fails on critical question: partman/unmount_active DISKS /dev/vda" [High,Confirmed] https://launchpad.net/bugs/1533243
<cjwatson> smoser: partman-base is a d-i component; it's not necessary or helpful to open additional bugs against d-i itself
<rbasak> ondrej: do you know if we need to care about swig at all? Is there anything packaged in the PHP world that uses swig?
<smoser> thanks.
<cjwatson> (at least assuming that 1355845 describes the same behaviour)
<smoser> so move https://launchpad.net/bugs/1533243 to partman ?
<ubottu> Launchpad bug 1533243 in debian-installer (Ubuntu) "preseeded installation fails on critical question: partman/unmount_active DISKS /dev/vda" [High,Confirmed]
<rbasak> Son_Goku: nacc: http://pad.ubuntu.com/php-transition
<cjwatson> reassigned
<rbasak> Son_Goku: https://launchpad.net/~ubuntu-etherpad
<infinity> cjwatson: I'd say the dspdfviewer thing is almost certainly an endian bug, given identical test failures on s390x.
<infinity> (Where the bug lies is an entirely different question)
<Son_Goku> rbasak: https://github.com/swig/swig/issues/571
<infinity> Well, could also be ibm long double, I suppose.  But they're definitely some Bad Math at play.
<infinity> s/they're/there's/ ...
 * infinity stares at his fingers.
<cjwatson> infinity: Yeah, doesn't really help establish where it is given that Debian apparently doesn't do it, but I guess just a bug in some dep
 * infinity nods.
<seb128> Noskcaj_, could you look at the blueman issues on top of e.u.c/xenial since you did the update?
<ondrej> rbasak: don't remember anything that uses swig (but my memory is limited to children night time stories these days...)
<rbasak> ondrej: we found owfs, but nothing else. We haven't looked exhausively.
<rbasak> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810084
<ubottu> Debian bug 810084 in ftp.debian.org "RM: websvn (RoQA; unmaintained, rc-buggy, inactive upstream, alternatives exist)" [Serious,Open]
<Unit193> Pity.
<ondrej> rbasak: I guess a lot of unmaintained software will habe to go
<rbasak> ondrej: yes, I think so.
<rbasak> ondrej: what's your timezone? Europe?
<rbasak> ondrej: nacc is in UTC-8, so what's the latest you'd be happy to do a hangout?
<rbasak> I think it would be useful to coordinate. We've more or less understood each other now I think, but would like some input from the Debian perspective so we don't end up just duplicating everything in Ubuntu instead of getting things into Debian and syncing.
<nacc> ondrej: would appreciate your guidance on what all is changing (or already changed) in pkg-php-tools in Debian to be php7.0 compatible; and if/how I can help
<rbasak> Son_Goku: http://anonscm.debian.org/cgit/pkg-php/php.git/tree/tests
<rbasak> Son_Goku: http://anonscm.debian.org/cgit/pkg-php/php.git/tree/debian/tests?h=master-7.0
<rbasak> https://wiki.debian.org/PackageTransition
<sarnold> that's awesome
<sarnold> that kind of distilled knowledge used to take hours of policy reading before getting started and even then it was too easy to make mistakes :)
<nacc> sarnold: that's what we're discussing currently on our hangout
<sarnold> heya nacc :)
<nacc> sarnold: hey :)
<infinity> rbasak: As for swig and php, I see a lot more than just one package...
<nacc> infinity: we found one so far that actually lists the dep in the control file ... but not done exhaustively searching
<rbasak> infinity: how are you seeing? We haven't really looked yet.
<nacc> infinity: which ones did you find/how did you search?
<infinity> http://paste.ubuntu.com/14480022/
<infinity> rbasak, nacc: ^
<nacc> infinity: thanks, will look into those/append to our php7 list
<jtaylor> infinity: do you know if glibc 2.22 will still make it into xenial?
<infinity> jtaylor: Yes, it'll be in this week, probably, and 2.23 a month or so later.
<jtaylor> ah great :D
<infinity> pitti: Thanks for the ifquery crash fix!
<infinity> pitti: I was seeing that on the s390x buildds on boot and couldn't decide if it was s390-specific or what (and didn't have time to investigate).
<infinity> stgraber: You know what's up with lxc adt tests?  Need an RT to poke some firewall holes?
<infinity> stgraber: (or some proxy magic)
<bdrung> cjwatson, can you merge the new devscripts version?
#ubuntu-devel 2016-01-13
<mapreri> I see https://launchpad.net/ubuntu/+source/scribus-doc/1.4.5-1 is in universe, but shouldn't it be in multiverse instead?
<meercat> why doesn't ubuntu 15.10 support uefi boots on macbooks
<mapreri> in debian it's in non-free 'cause OPL
<meercat> in virtualbox
<mapreri> meercat: that doesn't sound a question for #ubuntu-devel, you might have better chances in #ubuntu instead (that's user support channel)
<meercat> they don't  have an answer because its unsupported
<mapreri> makes sense too
<meercat> all of the other major distros support uefi boots in virtualbox on the mac
<meercat> even mint, which is based on ubuntu, which leads me to believe this may be a bug in installation
<meercat> there needs to be a startup.nsh script saved in /mnt
<meercat> sudo sh -c "echo '\EFI\ubuntu\grubx64.efi' > startup.nsh"
<meercat> this apparently goes back to 14.10
<meercat> enough time has elapsed for this to take priority efibootmgr may create a duplicated boot entry, "breaking" UEFI boot.  Critical. 2014-08-31  https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1363719
<ubottu> Launchpad bug 1363719 in efibootmgr (Ubuntu Utopic) "efibootmgr may create a duplicated boot entry, "breaking" UEFI boot." [Critical,Fix released]
<meercat> fix is not working
<meercat> xubuntu installs fine, then unity can be installed, so the workaround is to install xubuntu instead of ubuntu
<hallyn> pitti: http://people.canonical.com/~serge/systemd.debdiff  and http://people.canonical.com/~serge/cgmanager.debdiff , considering those for xenial.
<hallyn> (i'll also need a tweak to the lxc package - cherrypicked from upstream)
<hallyn> pls let me know if you see anything bad there
<nacc> rbasak: (or anyone else), let's say I've got a package (e.g., libgv-php5) that depends on (what appears to be) a symbol (e.g., phpapi-20131226) ... how do I look up reverse-depends on that symbol (which seems to be something generated by debian/rules in the php5 package). I think that's how we'll figure out all the packages that need to be updated that are PEAR/PECL/SWIG ... although as I type this, I r
<nacc> ealize I might just be able to search for php5 and find them too :)
<RAOF> nacc: That would probably be a virtual package to make ABI explicit; âapt-cache rdepends phpapi-20131226â would probably be your winner.
<pitti> infinity: I looked at that last night
<pitti> infinity, apw, stgraber: ah, I removed cloud-images.u.c. from $no_proxy, apparently there were some changes there; lxc tests now succeed again (on scalingstack anyway, i. e. not yet in LXC)
 * pitti re-runs for the older ubuntu releases too
<slangasek> pitti: hi, why do the ganeti autopkgtest failures get reported as a regression under http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#simplejson when basically every test with the version of ganeti in xenial has failed?
<slangasek> maybe a problem with how we're calculating "regression" now that we record triggers?
<pitti> slangasek: not every version, you see on http://autopkgtest.ubuntu.com/packages/g/ganeti/xenial/amd64/ that it did pass until the end of October and then started getting really flaky
<slangasek> pitti: no, what I said is every test with this version of ganeti has failed
<pitti> ah, we already have a force-badtest for it, excuses.html says that
<slangasek> ah, and indeed you have a force-badtest hint in place, so this won't actually block
<pitti> pitti:force-badtest ganeti/2.15.2-1
<slangasek> it should be possible to determine automatically that this is not a regression vs. the package currently in xenial
<slangasek> so maybe I'll file a wishlist bug
<pitti> ah, I see what you mean
<pitti> slangasek: right now it is like that because force-badtest was originally designed to "let your recently broken test not block other packages, but in your  next upload you have to fix them again"
<pitti> slangasek: which is basically what we want for stuff we develop; but we are now also using it as a list of "broken tests we import from Debian and nobody cares about in Ubuntu"
<pitti> slangasek: if we change it to what you have in mind, we'd allow more and more uncontrolled regressions
<pitti> maybe that's what we'll have to do if the force-badtest lists grow too long; just explaining the current behaviour
<slangasek> pitti: I see your point.  I guess since these packages had force-badtest to reach xenial in the first place, we don't need any added cleverness for labeling these "not-a-regression"
<slangasek> I just need to read to the bottom of the excuses stanza ;)
<pitti> slangasek: I guess what might be useful is to put the "ignored" lines right below the corresponding package
<slangasek> could be
<pitti> (which is surprisingly hard to do given how britney currently works, though)
<pitti> but certainly possible
<slangasek> pitti: btw, the semantics of the linux autopkgtest are a bit weird, have you noticed this?  it fails complaining about a "kernel version mismatch" if a newer version of the kernel is available in -proposed
<slangasek> e.g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#audit
<slangasek> not urgent, audit can stay in -proposed and the tests can be rerun once 4.3.0-6.17 is promoted; but it's a wart
<pitti> slangasek: yes, but I thought I fixed that yesterday
<slangasek> oh :)
<nacc> RAOF: ok, thanks!
<pitti> slangasek: I just didn't re-run all affected tests I suppose
<pitti> although I did a mass-retry last night, odd
<pitti> slangasek: I'll look
<slangasek> pitti: this test was triggered after your "yesterday"
<slangasek> (new upload by me this afternoon)
<nacc> RAOF: just returns "<phpapi-20131226>"
<nacc> that's what i was hitting before
<pitti> slangasek: oh, this is actually the inverse -- yesterday we had tests which used the kernel from -proposed but the source  from -release
<slangasek> pitti: the kernel version it says it's triggering is the -proposed version; for most packages it's normally the release version, right?
<nacc> RAOF: in this case, phpapi-20131226 is a "provides" value from php5 (generated by debian/rules)
<pitti> slangasek: the running kernel there is right -- we expect to run audit against -release
<nacc> RAOF: so not a proper package dependency, it's more like a command or something (I think I've seen packages depend on some command being available?)
<pitti> slangasek: but there it should use the linux source from -release too
<slangasek> pitti: right
<nacc> RAOF: may not respond right away, sort of afk, but appreciate any insight you can provide
<pitti> slangasek: this is a horrible piece of heuristics right now :/ http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/runner/adt-run#n343
<RAOF> nacc: Yeah, it's what's called a virtual package. But it seems that the php5 package in xenial at least does not provide that package.
<pitti> hallyn: hm, the patch still retains cg_create_everywhere_uid(), I suppose this should be dropped in favor of just cg_create_uid()?
<pitti> hallyn: but I can do that (and update the patch header etc.), it should work like this already; but note that with your patch it will already grab some other controllers soo
<pitti> hallyn: thanks!
<pitti> infinity: ah, great; it now got uploaded to Debian too, I'll merge ifupdown again to mop up some more fixes
<slangasek> pitti: I guess the issue is that 'apt-cache showsrc --only-source linux' will show both xenial and xenial-proposed binaries, which have different names
<pitti> slangasek: yes, that was the problem yesterday too; this heuristic isn't strong enough for "linux", need to think about this
<hallyn> pitti: oh i shouldve renamed it, but it's actually only creating name=systemd.  isn't it?  /me checks
<slangasek> pitti: will also fail funny for soname transitions
<pitti> hallyn: oh, I see -- you dropped the loop in cg_create_everywhere_uid(), it's essentially just an alias for cg_create_uid() now; I missed that
<pitti> hallyn: so yes, it should work as you intend now (and I'll trim it down)
<hallyn> yeah i left it bc we need to create the dir at that point (if i didn't, it didnt 'work)
<hallyn> pitti: -awesome, thx
<pitti> hallyn: eventually I think we can get the remaining bit into pam-cgm as well, it just needs to chown() the name= controller but otherwise don't touch it
<hallyn> i'll push the cgmangaer and lxc patches probably tonight, the systemd can come whenever
<hallyn> pitti: yeah, happy to move that over once we figureout how -
<hallyn> would like to first convert to pam-lxcfs though
<pitti> hallyn: yes, but not urgent
<hallyn> pitti: thx - ttyl
<pitti> hallyn: i. e. let's do that in these stages, easier
<nacc> RAOF: ah it's provided in xenial by php5-common
<nacc> RAOF: and a number of other packages -- is there handy command to search what provides a given virtual package?
<RAOF> I knew one at some point, but can't seem to remember it.
<pitti> apt-cache search isn't too bad, but it gets more hits than just the Provides:
<dholbach> good morning
<pitti> apw, stgraber: yay, green is back on http://autopkgtest.ubuntu.com/packages/l/lxc/ :)
<apw> pitti, yay indeed :)
<stgraber> pitti: great and I didn't even have to do anything about it :)
<pitti> PSA: no autopkgtests for the next half hour or so, I need to re-deploy the env
<apw> Unpacking fonts-tlwg-typo-ttf (1:0.6.2-2) ...
<apw> dpkg: error processing archive /var/cache/apt/archives/fonts-tlwg-typo-ttf_1%3a0.6.2-2_all.deb (--unpack):
<apw>  trying to overwrite '/usr/share/fonts/truetype/tlwg/TlwgTypo-Bold.ttf', which is also in package fonts-tlwg-typo 1:0.6.2-1
<apw> is this known ^
<cking> me too on that one
<dholbach> I had the same issue earlier and reported it
<apw> dholbach, cool thanks
<dholbach> the usual  ... sudo apt install -f; sudo dpkg configure -a; ... dance fixed it for me
<dholbach> "fixed"
<cking> yep, that's what I did too :-)
<cking> w/o the dancing
<Laney> one of you going to fix it? :)
<ginggs> Laney: hi, you renamed library packages for g++5 transition for package normaliz in Ubuntu, but Debian didn't (the only thing depending on it is itself). What is the best way to drop the Ubuntu delta and get back into sync?
<Laney> ginggs: Add Breaks and Replaces until the next abi break
<Laney> if you know or are the Debian maintainer you could add those there :)
<ginggs> Laney: so just add breaks and replaces to the debian package, then sync?
<Laney> ginggs: I think so, check it upgrades properly
<ginggs> Laney: will do, thanks
<Laney> thank you!
<seb128> ginggs, Laney, have a Provides as well I think
<seb128> C/R/P
<Odd_Bloke> cjwatson: If you have a minute: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/s390x_cloud_images/+merge/282413 :)
<Odd_Bloke> (xnox: ^)
<pitti> wohoo!
<cjwatson> Odd_Bloke: mostly LGTM, maybe lose the pointless bashism in 999-cpc-fixes?
<Odd_Bloke> cjwatson: Ah, yep, copy-pasta fail.  Fixed and pushed.
<cjwatson> Odd_Bloke: merged and uploaded
<Odd_Bloke> cjwatson: Thanks!
<cjwatson> bdrung: devscripts merged
<ginggs> Laney: normaliz maintainer buttoned up things rather tight; libnormaliz0 already Provides and Conflicts libnormaliz, libnormaliz0-dbg  already Provides and Conflicts libnormaliz-dbg and it doesn't want to upgrade like that
<Laney> ginggs: Doesn't want to how? Can't you add the v5 packages in there too?
<ginggs> The v5 packages also Provide and Conflict with libnormaliz and  libnormaliz-dbg.  It is normaliz-bin that is getting kept back.  I'm trying something now that might help it along.
<xnox> pitti, on s390x i need to set vm.allocate_pgste = 1 via sysctl. Where is it best to have this thing set? systemd package shipping such a snippet? or somewhere else?
<pitti> xnox: /etc/sysctl.d/
<pitti> xnox: oh, you mean not locally, but in a package?
<xnox> pitti, =)
<xnox> pitti, yeah, cause everyone who wants to run qemu will need it ;-)
<pitti> xnox: /usr/lib/sysctl.d/ then, in whavever package that sounds suitable
<xnox> pitti, i see on redhat they ship it in initscripts package such a snippet.
<pitti> that looks a bit like an "unbreak my setup" option, this can't just be set in the kernel?
<xnox> dunno, i can ask kernel people.
<pitti> our procps package ships a ton of those already
<pitti> so I guess for now it coudl go there as well
<pitti> unfortunately it ships all of them in /etc/sysctl.d/, we should move to /usr/lib/sysctl.d/ for stuff shipped by packages
<pitti> (man sysctl.d)
<xnox> apw, can vm.allocate_pgste = 1 be the default? we seem to boot into =0, and qemu-system barks at me saying it must be =1 to boot vms.
<pitti> xnox: so, changing the default in the kernel seems prudent, until then procps could ship that as an override?
<mvo__> doko: quick question - will there be an update for gccgo before the 16.04 release? I have some build failures in snappy right now because we use some go 1.5 feature but apparently that is not supported in our gccgo yet. if there is a plan to update i will just wait, otherwise I need to think about a plan b :)
<pitti> doko: FYI, new python3.5 has two regressions in test.test_csv.TestDialectRegistry: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python3.5/20160113_011050@/log.gz
<ginggs> Laney: Now normaliz-bin and normaliz are getting kept back. :( I also don't see how libnormaliz0v5-dbg will get upgraded without a transitional package, there's nothing else that depends/recommends/suggests it.  I did something similar with xmpi in LP: #1245149 some time ago, this might be the only way.
<ubottu> Launchpad bug 1245149 in xmpi (Ubuntu) "Please merge xmpi 2.2.3b8-13.1 from Debian testing (main)" [Undecided,Fix released] https://launchpad.net/bugs/1245149
<Laney> ginggs: if it helps AFAIK you can drop -dbg packages now that Debian has automatic ones
<Laney> Not sure if you'd get file conflicts with that one though
<Laney> (I guess not)
<Odd_Bloke> cjwatson: Another livecd-rootfs MP: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/i386_ovas/+merge/282427
<Odd_Bloke> cjwatson: Sorry I didn't roll this in above, we discovered the omission as you were releasing my previous fix. :(
<bdrung_work> cjwatson, thanks
<cjwatson> Odd_Bloke: merged/uploaded
<Odd_Bloke> cjwatson: Thanks again!
<doko> mvo__, yes, I'll see to that
<mvo__> doko: \o/
<mvo__> doko: is there anything I could help with?
<doko> mvo__, would be nice if somebody could figure out autopkg testing for golang packages
<mvo__> doko: what kind of tests do you have in mind? the unit tests are running as part of the build by default afaik which is already quite nice
<d0lph1n98> is it a good practice to have self-documented code for kernel space drivers?
<doko> mvo__, the thing what is currently done for all ruby and perl packages
 * mvo__ checks what is done there
<ricotz> doko, hi
<ricotz> doko, I hope you didnt miss my message about libtool
<apw> xnox, and that cannot be changed after boot ?
<doko> ricotz, no time yet
<ricotz> doko, alright, just wanted to make sure it is on your list -- can you copy it to a non-virtualized ppa which builds it on all archs?
<cjwatson> mvo__: I'm pretty confused about how the "architectures" field in a snapcraft.yaml is meant to work.  It seems to override the architectures of the generated snap package, not specify which architectures the snap might be built for - is that right?
<doko> pitti_, apport's gcc 6 detection could be better: No such file or directory: '/usr/bin/gcc-6-20160109-1ubuntu1
<apw> xnox, it may be changable after boot, i wonder why its off, it seems to take some locks, so i odn't know if there is a performance hit in there
<apw> xnox, anyhow, would you file a bug against linux for tracking pls
<pitti_> doko: which test is that? I remember having to do some adjustments for gcc-4.9 -> gcc-5
<doko> pitti: see https://launchpad.net/ubuntu/+archive/test-rebuild-20151218.1-gcc6/+build/8639224
<pitti_> doko: what does "gcc --version" say?
<doko> $ gcc --version
<doko> gcc (Ubuntu 6-20160109-1ubuntu1) 6.0.0 20160109 (experimental) [trunk revision 232188]
<pitti_> doko: thanks; I'll adjust it to cope with that
<pitti_> i. e. 5.3 vs 6-something
<pitti_> or perhaps better, take the third field isntaed of the second
<pitti_> doko: fixed in trunk
<doko> pitti_, you should just rely on the number which is not in the (...)
<pitti_> right, that's what I did now
<rbasak> cjwatson, infinity: I'd appreciate your comments on bug 1533639.
<ubottu> bug 1533639 in livecd-rootfs (Ubuntu) "[ubuntu-cpc] please make /tmp a tmpfs in RAM" [High,Triaged] https://launchpad.net/bugs/1533639
<rbasak> pitti: also.
<cjwatson> rbasak: I'm afraid I'm unlikely to have time to get into this.  It was a rat-hole even when I was working on installer stuff routinely
<rbasak> cjwatson: OK, np.
<mvo__> cjwatson: uh, thats a sergiusens question
<cjwatson> sergiusens: I'm pretty confused about how the "architectures" field in a snapcraft.yaml is meant to work.  It seems to override the architectures of the generated snap package, not specify which architectures the snap might be built for - is that right?
<cjwatson> :-)
<happyaron> how to let things like src:trafficserver migrate from -proposed? (ftbfs on archs previously can successfully build)
<cjwatson> happyaron: Why can't the build failures be fixed?
<happyaron> cjwatson: upstream is in the process of dropping 32 bit support
<xnox> happyaron, s390x and ppc64el are 64-bit.
<happyaron> but not actually removing existing stuff atm
<cjwatson> happyaron: The arm64 case looks like incorrect link order, probably.  The ppc64el case seems to be something to do with passing -mcx16 when it's not recognised.
<cjwatson> happyaron: And indeed, 32-bit support has nothing whatsoever to do with this.
<cjwatson> s390x is not involved.
<cjwatson> (I mean, it fails, but it's not a regression.)
<happyaron> these (ppc64el/s390x) are known and being worked on, but probably no armhf
<cjwatson> happyaron: armhf is not relevant, since it's not a regression.
<happyaron> ok
<cjwatson> happyaron: You need to fix the ones that are regressions (arm64, ppc64el).
<cjwatson> I expect that not passing -mcx16 on non-x86 would help.
<happyaron> arm64 does build...
<cjwatson> Oh, I can't read.
<cjwatson> Misread armhf as arm64.
<happyaron> :)
<cjwatson> We can remove existing binaries from architectures if they're definitely being dropped, but there has to actually be a decent argument for that.
<happyaron> (upstream believes nobody is using the software on non-x86 platforms, though not a good claim
<cjwatson> Looks like the ppc64el case would be fixed by not assuming that has_128bit_cas=1 in configure.ac always implies "we got there by passing -mcx16".
<cjwatson> Just bad logic.
<cjwatson> Yeah, upstreams always say that.  Sometimes they're right ...
<cjwatson> Sometimes we care even if they don't
<cjwatson> Anyway, if you can get ppc64el fixed, then we can look at armhf
<happyaron> ok
<doko> barry: cython tests still fail with the updated python3.5
<doko> barry, and looks like the test_csv tests need adjustment too (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python3.5/20160113_011050@/log.gz)
<barry> doko: i'm pretty sure i fixed the csv failure in a following commit
<doko> barry, can't currently look. mercurial times out for me
<barry> doko: yay ;)
<doko> barry, but for 3.5 I took the branch, so it should be included
<barry> doko: interesting.  okay, let me try here from upstream
<barry> doko: xnox reported the asyncio failure in the cython build.  fairly sure that's unrelated: LP: #1526613 (but still worth tracking down)
<ubottu> Launchpad bug 1526613 in python3.5 (Ubuntu) "ftbfs asyncio test failure with 3.5.1-2, used to pass with 3.5.0-2" [Undecided,New] https://launchpad.net/bugs/1526613
<barry> doko: hg is okay here
<xnox> barry, i've emailed cypthon mailing list, no response.
<xnox> barry, filed github issue against asyncio, and guido said "talk to cypthon people, it's their tests that are failing"
<barry> xnox: yeah, i think i saw that.  :(  i'll see if i can bisect the commit
<xnox> and asyncio generators is beyond me, to work out what cypthon is doing and why it's failing.
<Saviq> pitti, can you please rerun the unity-scope-click failures http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#gsettings-qt :|
<Saviq> I've already filed bug #1532358, will put heat on it
<ubottu> bug 1532358 in unity-scope-click (Ubuntu) "flaky autopkgtests cause migration issues" [Undecided,New] https://launchpad.net/bugs/1532358
<Saviq> alecu, hey, can you please put â on the table somewhere
<pitti> Saviq: kicked
<sergiusens> cjwatson, architectures in snapcraft.yaml should probably just go away; it is only there since people wanted it on special request (using prebuilt binaries and manually constructing a fat package).
<sergiusens> but yes, it is an override, not a "built this for" :-/
<sergiusens> I guess the docs could make that clear, and yeah, it is backwards when comparted to debs
<cjwatson> sergiusens: Have you put any thought into metadata that describes the architectures that the source code for a snap can be built for?  It would be useful for the LP/store interaction.
<cjwatson> sergiusens: debs have this for a reason ;-)
<barry> doko: upstream 3.5 head only fails for me on the ssl tests.  test_csv passes
<barry> (ssl tests always fail)
<barry> also interesting that test_asyncio doesn't fail for me
<sergiusens> cjwatson, can you log a bug, I agree, but I'll forget https://bugs.launchpad.net/snapcraft :-)
<cjwatson> sergiusens: OK, https://bugs.launchpad.net/snapcraft/+bug/1533713
<ubottu> Launchpad bug 1533713 in Snapcraft "Add metadata describing the architectures that a snap can be built for" [Undecided,New]
<sergiusens> thank you
<xnox> pitti, why is nova missing tests on xenial? http://autopkgtest.ubuntu.com/packages/n/nova/
<xnox> pitti, or has it lost its brains? http://autopkgtest.ubuntu.com/status/ looks a bit empty
<jcastro> hi everyone, what's the process for removing a package from universe? We have an old unmaintained package for juju-jitsu that has been dead for years and shouldn't be in xenial
<rbasak> jcastro: ask an archive admin to remove with that explanation, usually via a bug and subscribing ~ubuntu-archive
<seb128> jcastro, open a removal bug and subscribe ubuntu-archive
<jcastro> does it matter which package the bug is filed under? I am assuming under the package I want removed is fine?
<cjwatson> jcastro: yes, that's best
<jcastro> thanks folks!
<smoser> hey. i'm trying to do this:
<smoser> http://paste.ubuntu.com/14488062/
<smoser> cjwatson, is there an easy way to tell grub-pc not to attempt grub-probe and such as I dont care about functional grub ?
<cjwatson> smoser: no.  when I've had to do things like this in the past I've diverted grub-probe and replaced it with a simple script that output just the information I need (IIRC I had something like that in lp:lupin)
<smoser> hm.. looks like if i can get running-in-container to exit 0 (true), then maybe
<cjwatson> oh, no, that was grub-{install,mkimage}
<cjwatson> ah, it's true that running-in-container might help
<smoser> so replacing running-in-container with /bin/true seems to work.
<smoser> wonder how far back that goes.
<smoser> looks like that should work on trusty. and even precise!
<cjwatson> yeah, looks like it
<cjwatson> it was a precise SRU
<pitti> xnox: I had to redeploy the entire thing today due to some juju troubles; it's still catching up with re-downloading all logs
<xnox> pitti, cool =)
<pitti> xnox: it downloads precise to xenial, currently at xenial/i386
<pitti> xnox: so they should be there
<pitti> xnox: if it's something on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, that has direct links to the logs (and they always work indepenently of autopkgtest.u.c.)
<Saviq> pitti, looks like unity-scope-click failed again http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsettings-qt :/
<nemo> So, due to the missing backport from upstream opensc detailed in https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770  which I've been a little too verbose in, I keep getting nagged to "upgrade" the .deb of opensc I built to the exact same version # - this happens every time I run an upgrade - in graphical client I can upcheck it, but I sometimes forget, and that's not as easy on co
<ubottu> Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed]
<nemo> mmandline
<nemo> I don't know if the opensc fix will be backported, is probably considered low priority, but is there any way to get ubuntu to stop trying to upgrade the .deb ?
<nemo> the weird thing is they really are an identical version
<cjwatson> put it on hold?
<nemo> cjwatson: ooh. how?
<cjwatson> if apt is trying to upgrade it then the checksum probably differs
<nemo> cjwatson: well, that's very likely since I did build it locally and added the missing exports âº
<cjwatson> anyway, there's a dpkg-hold in the dlocate package (for some reason), or:   echo NAME-OF-PACKAGE hold | sudo dpkg --set-selections
<nemo> cjwatson: is that maybe "Lock Version" in synaptic?
<cjwatson> probably does the same
<nemo> kk
<cjwatson> can't say for certain, I don't use synaptic
<nemo> it's my goto tool for getting anything done w/ apt - probably for same reason anyone uses a gui, lack of familiarity w/ cli
<nemo> hm. stll wants to upgrade it :/
<cjwatson> try the version I gave then
<nemo> aight
<nemo> echo opensc hold | sudo dpkg --set-selections
<nemo> still wants to upgrade :/
<nemo> oh wait
<nemo> I'm a moron
<nemo> that did work. awesome. thanks.
<cjwatson> cool
<nemo> I guess I'll be manually upgrading this for the forseeable future, but if I ever want to release the hold?
<cjwatson> same but with unhold
<nemo> Maybe I'll add your hint to my bug comments, since I've been trying to detail there how to get this vmware to work under ubuntu
<cjwatson> wait, no, same but with install
<nemo> ok
<cjwatson> in general though, if you're doing this kind of thing it's better to change the version number
<nemo> ah...
<nemo> well, I'm not very savvy WRT building either âº
<cjwatson> and then you could e.g. put it in a PPA and either the version you choose is higher, or you could tell apt to pin the PPA such that it prefers that even if the version from the primary archive is higher
<nemo> yeah, that sounds way too sophisticated for my simple needs âº
<nemo> but thanks
<cjwatson> I mean, if you're intending to tell other people how to get it to work, a PPA is better then them all having to build it themselves
<nemo> true. still don't wanna be responsible for it tho âº
<nemo> and maybe the upstream fix will be pulled into LTS someday
<cjwatson> fair enough
<bdmurray> pitti: Could you have a look at bug 1533349?
<ubottu> bug 1533349 in Apport "StacktraceAddressSignature is generated using suboptimal function" [Undecided,New] https://launchpad.net/bugs/1533349
<doko> barry, the upload only had your first commit, now uploaded again
<ginggs> infinity: do you mind if I go ahead and merge pcre3?  You touched it last.
<barry> doko: thanks
<doko> ginggs, just do it
<ginggs> doko said i can :)
<infinity> ginggs: Go nuts.  Better yet, forward the changes to Debian, nothing in there is Ubuntu-specific.
<doko> ricotz, why do you just remove the demos instead of adjusting for the changes?
<ricotz> doko, do you think shipping those plain *.at files makes sense?
<doko> so why not shipping the expanded/built ones?
<ricotz> please add them then
<doko> ricotz, patch please
<ricotz> doko, if you say me how
<doko> find out
<ricotz> are they actually kept around after "make check"
<ricotz> doko, you know how, but not saying?
<doko> no, I'm trying to understand your changes, why they are necessary, why they are undocumented, and why you didn't try to fix these correctly
<ricotz> doko, I don't see those demos expanded in a useful manner
<ricotz> doko, all the removals in clean broke things, reverting the source tree to itself original state seems quite impossible
<ricotz> reverting the "sed version" of libtoolize.in is broken too and doesnt seem to be fixable
<ricotz> make those VERSION tweaks a proper patch would be cleaner
<ricotz> making ...
<Pharaoh_Atem> nacc: is it just me, or is php7.0-* not installable for you too?
<Pharaoh_Atem> it's throwing an error for me saying that everything depends on php-common but it is not going to be installed
<Pharaoh_Atem> nacc: nvm, it seems to be okay now...
<nacc> Pharaoh_Atem: it worked in my first test, but Ill try it again
<hallyn> pitti: i've pushed the other related packages, so if you get the systemd package to where you're happy please let me know - ican test first or you can just push and i'll test from archive
<barry> smoser: can you confirm, cloud-image-utils is now python3 only?  re: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
<smoser> barry, let me see.
<smoser> barry, cloud-utils is good, but it depends on euca2ools, which is still
<smoser>  Depends: python (>= 2.7), python (<< 2.8), python-lxml, python-requestbuilder, python-requests, python-six, python-setuptools
<barry> smoser: can i update the blueprint and assign that to you?
<smoser> um.. yeah.
<gQuigs> any suggestions on how to approach this bug - https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1515446   I'm currently going service by service trying to determine what's different between desktop (has issue) and server (works) in a restart testing loop
<ubottu> Launchpad bug 1515446 in systemd (Ubuntu) "NFS shares in FSTAB no longer mount at boot" [Medium,Confirmed]
<gQuigs> (network-manager doesn't appear to be the obvious culprit)
<barry> smoser: thanks ;)
<nacc> why would a package's source be in multiverse but the binary be in universe?
<nacc> (php-doc)
<hallyn> pitti: hey, having a problem with the systemd job 'libvirt-guests.service' in wily's libvirt.  bug 1533839 .  it should only be stopped on shutdown, should be started after libvirt-bin.  but on pkg upgrades it's being stopped and restarted
<ubottu> bug 1533839 in libvirt (Ubuntu) "vms shutting down on libvirt upgrade" [Critical,Triaged] https://launchpad.net/bugs/1533839
<chiluk> mterry are you on the SRU team?
<chiluk> mterry if you are can I get SRU approval for apache2 from pad.lv/1484696 ?
<JayF> I'm working on building a cloud-style Ubuntu 14.04 image that can work on both RAID(md) and non-RAID hosts. I have everything working except /dev/disk/by-label/root is pointing to sda1 (a member of the raid) as opposed to md126p1 (the actual raid partition that should be root). When/what populates /dev/disk/by-label/ during boot? udev?
<ari-tczew> coreycb: could you remerge amavisd-new, please? or eventually leave a meesage on bug 1357424 that you're not interested anymore
<ubottu> bug 1357424 in amavisd-new (Ubuntu) "Please merge amavisd-new_2.9.0-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1357424
#ubuntu-devel 2016-01-14
<nacc> rbasak: one of the big transitions is from php-config5 to php-config ... and i just realized that command-not-found would also need updating for all the php5 commands
<nacc> rbasak: for those, would we be leaving in php7.0 (replacing php5) or just putting in php as appropriate?
<nacc> rbasak: also, haven't seen any invite for a hangout tmrw; even if ondrej isn't available, could we do a quick sync on some questions I have?
<sarnold> does anyone why know apparmor-dbgsym doesn't appear in http://ddebs.ubuntu.com/dists/trusty/main/binary-i386/Packages ? the packages appear to exist just fine: http://ddebs.ubuntu.com/pool/main/a/apparmor/
<sarnold> (also not in binary-amd64/, the first place I looked)
<sarnold> how odd, there's apparmor-2.8.98 packages there, but no apparmor-2.8.95~... versions
<nacc> ondrej: where does php-pear come from in php7? I see that in php5 it's created by the php5 src pkg. But not in PHP7 -- and so when I try to build, e.g., php-pkg-tools from your git tree, it fails to find a2~2~2~
<nacc> err, ignore the tail of that, clearly ... fails to find php-pear
<nacc> it == sbuild
<nacc> ondrej: i also noticed in my xenial VM, after install php7.0, that I can't install php-pear (it depends on php5-common and php5-cli). I saw in your e-mail that you mentioned "php-pear is not built from independent source package", which made me think it came from php7.0?
<nacc> ondrej: oh! was that a typo, perhaps .. i found http://anonscm.debian.org/cgit/pkg-php/php-pear.git/
<nacc> ondrej: and i'm guessing, since it's so new, it might not yet be packaged?
<pitti> Good morning
<didrocks> good morning pitti, Ã§a va ?
<pitti> didrocks: j'ai des muscles dolores de basketball, mais je vais bien, merci ! et toi ?
<didrocks> pitti: Ã§a va bien :)
<pitti> Saviq: I forced it now
<pitti> bdmurray: I saw the MP, will do, thanks!
<pitti> hallyn: will respond in the bug; this should probably get told to not restart the service on package upgrade then (dh_installinit --no-restart-on-upgrade), but I'll read the details and confirm
<pitti> hallyn: pam-cgm> ah, did the other changes land in xenial? or do I still need the PPA for testing?
<hallyn> pitti: everything should now be in xenial except the systemd change
<hallyn> note, libvirt-guests.service is already installed in debian/rules with --no-restart-on-upgrade
<hallyn> that's why i'm confused
<pitti> hallyn: great, thanks; I'll merge some fixes from Debian while I'm at it, and trim the patch
<hallyn> it appears libvirt-bin's restart is forcing libvirt-guest's restart.  which i assume is due to an error in how i relate them,
<hallyn> though i swear when i did this back in october of something it worked,
<pitti> jamespage: hey, how are you?
<pitti> jamespage: can you please have a look at debian bug 810702? They have a question about our Ubuntu delta, and I'm afraid I can't answer that
<ubottu> Debian bug 810702 in open-iscsi "Generate initiator name on install, not first boot" [Normal,Open] http://bugs.debian.org/810702
<pitti> hallyn: hm, I see that you now have two patches in scope.c, both of which do a chown
<pitti> hallyn: oh, nevermind, the other patch is commented out
<hallyn> thought i removed the other before my final debdiff
<pitti> hallyn: still, core-Chown-systemd-cgroup-to-users.patch looks a lot nicer and smaller, didn't that one work?
<hallyn> pitti: it did not.
<hallyn> i didn't dig very deep;  don't know if i needed to mkdir it first or of something else was going on
<pitti> hallyn: ack; anyway, I'll work on that, and also adjust the autopkgtest (as that will now fail with the reduced patch)
<hallyn> pitti: thanks
<pitti> hallyn: thanks to you! nice to get this into xenial, so that the CPU hotplugging people get happy again :)
<ondrej> nacc: php-pear is src:php-pear now
<ondrej> nacc: Matthieu probably didn't upload it yet to Debian unstable, I'll poke him
<pitti> hallyn: oh yes -- "chown(u->cgroup_path," doesn't work, that's not the full path, just something like /user/user-1000.slice
<pitti> hallyn: with libpam-cgm installed, is it normal that this only does stuff for "freezer", not for any other cgroup?
<pitti> sessionoptionalpam_cgm.so -c freezer
<pitti> hallyn: ^ I suppose it is (that's from /etc/pam.d/common-session, sorry about the broken tabs)
<pitti> ah, changing it to "freezer,memory" does work
<pitti> hallyn: works nicely, I tested in a fresh VM, lxc-start works, and cgroups look good; nice work!
 * pitti goes to adjust the autopkgtest, will upload then
<pitti> caribou-: hm, I found a crash with xenial's rsyslog; installing juju-local triggers that (reproducer is in the bug); bug 1534106
<ubottu> bug 1534106 in juju-core (Ubuntu) "rsyslogd crashed with SIGSEGV with juju-local configuration" [Medium,New] https://launchpad.net/bugs/1534106
<pitti> caribou-: mind having a look?
<pitti> reproduces perfectly in a VM
<caribou> pitti: sure, will look at it
<kickinz1> Is there someone working on ntp merge already?
<pitti> odd, why isn't that on merges.u.c.
<pitti> kickinz1: anyway, Laney is TIL, so it just needs to be cleared with him
 * pitti would assume Laney is fine with losing that
<Laney> he already emailed me and I said okay
<kickinz1> Laney, thanks again. Just to be sure noone else is working on it here (as I already had a pb wrt previous merge work)
<rbasak> nacc: are you happy for me to upload your logwatch merge or did you want to check with Debian/upstream on the snapshot question first?
<smb> pitti, Darn. Sorry it seems the more I look at plumbing the more I get confused. Is it intentional that in Xenial the numbers to "dh_installinit ... -- defaults SS KK" seem to be ignored. Maybe I should just close my eyes and move ahead to units/services...
<pitti> smb: SS and KK have been history for many many years, since insserv came along :)
<pitti> smb: they should not be used any more (and are ignored), instead insserv will compute dependencies from the LSB headers in init.d scripts
<smb> pitti, *sigh* I am too old for that sh.. :-P Just glad that I think with "Before=" I have a better chance of modelling a "if thats there then start before" condition
<pitti> smb: right, the equivalent of that is X-Start-Before:  in the LSB header
<smb> pitti, ah ok... that was never used. looks like pure luck this ever worked
<ginggs> Laney: would you be able to apply the patch from Debian bug #808842 to glib2.0 in experimental please?  otherwise I can apply it to Ubuntu for now
<ubottu> Debian bug 808842 in src:glib2.0 "glib2.0: FTBFS with PCRE 8.38: regex (?(?<ab)) produces different error" [Serious,Open] http://bugs.debian.org/808842
<Laney> ginggs: Don't diverge.
<Laney> I'll fix it.
<ginggs> Laney: thanks!
<doko> pitti, python3.5 tests pass, now blocked on postgresql-multicorn
<pitti> doko: no, multicorn has an override
<jamespage> pitti, blimey I had to go re-read the original bug report for that one
<pitti> doko: ah, it's the pyqt5/s390x regression, I'll look/retry
<jamespage> (iscsi patch/debian bug)
<pitti> jamespage: yeah, that delta is pretty old, and the logic changed in Debian several times; I'm not even sure if it's still needed, but when building an image in a chroot with policy-rc. the init script wouldn't run and generate the id
<xnox> barry, yeah - fedora people got FTBFS in cython too now, and came out about it on my cython devel thread =)
<rbasak> ondrej: around? Can we arrange a time to sync with nacc, Pharaoh_Atem and myself please?
<kickinz1> rbasak, di dyou get a chance to look at amavisd-new merge ?
<rbasak> kickinz1: not yet, sorry. I intend to review caribou's merge next, and then yours. Hopefully this afternoon.
<kickinz1> rbasak, ok I understand.
<pitti> doko: ah, it landed now
<kickinz1> I've splitted the ntp delta to my git repo on launchpad. If you want to look at it (there is a 'space' typo in debian/apparmor-profile, which appear at all diffs :( ).
<kickinz1> rbasak, ^this typo would imply 2 rebase and 9 re-tags, and the new merge will be on a major version bump; tell me if you think it is better to remove it.
<ioanm> hi, i'd like to pay back to ubuntu by becoming a dev :) I know it says anyone can contribute, but i would like to be part of the main team
<ioanm> i'm familiar with C/C++ and Assembly
<ioanm> where should i start?
<pitti> rbasak: hey Robbie, how are you?
<pitti> rbasak: not sure who/whether someone cares in the server team, but I'm currently moving xenial to postgresql-9.5 (only)
<pitti> rbasak: for an LTS we are pretty much required to ship the latest major upstream release
<rbasak> pitti: o/
<rbasak> pitti: postgres has been pretty painless for us. Go ahead!
<nacc> ondrej: ah ok! thanks -- yes, that'll get autosync'd and I can verify it in ubuntu that way, at least, too
<rharper> rbasak: on the git merge stuff, I want to import the new/debian dsc; does the state of the repo matter (should I be at reconstruct/xxx ) ?
<rbasak> rharper: I would be at old/debian when importing new/debian. Then the history makes sense.
<rharper> ok
<rbasak> I'm not sure how much this matters though.
<rbasak> It seems wrong to be anywhere else.
<rharper> agreed
<Odd_Bloke> pitti: Do you use the armhf cloud images for autopkgtest stuff?
<pitti> Odd_Bloke: not at the moment, no; I use the "ubuntu" template with debootstrap
<pitti> Odd_Bloke: I was going to use them by moving to lxd, but we have some problems on arm64 which currently prevent that
<Odd_Bloke> pitti: Would you be comfortable with us dropping them for xenial?
<Odd_Bloke> pitti: (We're not really seeing any downloads for them ATM)
<pitti> Odd_Bloke: fine with me, as long as we keep LXC/LXD images
<pitti> Odd_Bloke: well, hang on; there is a chance that we can soon boot armhf images in Scalingstack
<pitti> (wgrant was looking into some blockers there)
<Odd_Bloke> pitti: Right, I'm waiting to hear back from wgrant on that.
<Odd_Bloke> pitti: (But I asked that in
<Odd_Bloke> #launchpad, just to make following the conversation harder :p)
<pitti> Odd_Bloke: if/once that works, having images would be nice, but I think that an lxd image would suffice for that as we need to specify kernel and initrd separately anyway
<cjwatson> pitti: for Launchpad, our plan is to boot arm64 images with a kernel option apw added to make them emulate armhf more accurately
<cjwatson> pitti: mostly because that fits better into the way we do multi-architecture-capable builders
<pitti> cjwatson: ah, ok; with that appraoch I'm currently blocked by bug 1531768 :/
<ubottu> bug 1531768 in linux (Ubuntu) "arm64 kernel and multiple CPUs is unusably slow" [Medium,Confirmed] https://launchpad.net/bugs/1531768
<Saviq> pitti, hey, I'm working on adding autopkgtest runs to our Jenkaas, got a few minutes for questions?
<pitti> Saviq: we have team meeting in 2 mins, but just ask
<Saviq> pitti, I've used autopkgtest from trusty-backports (was it a good idea? maybe there's a better source?), any idea why artifacts would not get copied over from the testbed? I can see the tests writing to ADT_ARTIFACTS but they didn't show up in --output-dir https://unity8-jenkins.ubuntu.com/job/run-commands/376/
<pitti> Saviq: trsuty-backports is fine (I shoudl update it, though)
<Saviq> pitti, a different question is now how to restrict tests to a certain testbed (I'd like to put autopilot tests, meant to run on a phone, into a autopkgtest)
<pitti> Saviq: perhaps your didn't tell your jenkins job to copy the artifacts/ subdir?
<Saviq> I know I could just pass --testname, but maybe there's a better way, one that would work/not break britney, too?
<Saviq> pitti, d'oh, **
<Saviq> most likel
<Saviq> y
<pitti> Saviq: why can't the autopilot tests run with britney tests? we have quite a number of packages who do that
<pitti> Saviq: there's some autopilot-sandbox-run convenience script to set up Xvfb, dbus etc.
<pitti> Saviq: otherwise, make the test check for an expected environment and exit with 0 and some message like "SKIP: not on an ubuntu phone"
<Saviq> pitti, they need a phone, a full Unity8/Mir session, at least until we get virtual output from Mir
<Saviq> pitti, ack, that works, thanks
<doko> barry, just gave back cython, still ftbfs
<barry> :(
<Saviq> pitti, ah, last thing, parallelizing builds, that's fixed in latest adt-run, right? probably just not in the trusty-backports one?
<pitti> Saviq: should be in trusty-backports, hang on
<barry> doko: there's been a little more discussion on that cython thread xnox started.  maybe the cython devs will fix that bug
<pitti> Saviq: that was in 3.17.3
<doko> barry, xnox: reference?
<Saviq> pitti, hmm if I didn't pass DEB_BUILD_OPTIONS="parallel=4" it went and built on a single core
<pitti> DEB_BUILD_OPTIONS=parallel=$(grep -c ^processor /proc/cpuinfo | sed 's/^0$/1/');
<barry> doko: https://mail.python.org/pipermail/cython-devel/2016-January/004639.html
<pitti> Saviq: it uses that; what target are you running this on? perhaps /proc/cpuinfo is wedged there?
<xnox> doko, barry: https://github.com/python/asyncio/issues/308 https://mail.python.org/pipermail/cython-devel/2015-December/004630.html https://mail.python.org/pipermail/cython-devel/2016-January/004639.html
<Saviq> pitti, looks fine, gave out "4"
<Saviq> as "nproc" does
<pitti> Saviq: oh, nproc, I learned something new!
<Saviq> :)
<pitti> that uses sched_getaffinity()
<pitti> Saviq: but either way, it works locally, so I'm afraid I need some more info to reproduce; can you please file a bug for that?
<Saviq> pitti, will do when I confirm
<doko> xnox, but no real feedback from the cython side?
<xnox> doko, radio silence
<kickinz1> rbasak, so I did some rework on my ubuntu delta for ntp, but now it doesn't get pushed correctly to launchpad
<nacc> kickinz1: what happens?
<kickinz1> my current local git is: http://paste.ubuntu.com/14496958/
<nacc> rbasak: rharper: it will matter a bit, for the current branch you are on, but in theory that can be fixed later with rebases/renames
<kickinz1> and in my launchpad tree it is like I have a duplicate master branch instead of the deltas: https://git.launchpad.net/~kick-d/ubuntu/+source/ntp/log/?h=reconstruct/4.2.6.p5%2bdfsg-3ubuntu9
<nacc> kickinz1: what branches do you have locally and how are you pushing?
<nacc> kickinz1: so it looks like you pushed your local master (or reconstruct) to the remote's master
<kickinz1> I pushed both of them.
<nacc> if you look at your local tree, it seems like tag: new/debian, tag: 1_4.2.8p4+dfsg-3, reconstruct/4.2.6.p5+dfsg-3ubuntu9, master are all 04b751c
<kickinz1> nacc, thanks.
<nacc> kickinz1: on what branch is e.g., cfdd2ee
<nacc> you want to push that to the remote, so that it updates ... remotely :)
<nacc> rbasak: Pharaoh_Atem: either of you around?
<kickinz1> nacc, thanks again
<nacc> kickinz1: np, i actually find the 'pretty' log you pastebin'd much harder to parse than it needs to be ... but that's because I want the names (tags, brances) to be first in my head ... would have been a lot more obvious what was going on if that was the case (rather than a parenthized suffix)
<kickinz1> nacc, OK, I'll rewrite my gitconfig, thanks for the tip.
<nacc> kickinz1: yeah, whatever works best for you, though, for sure. I also use git enough that I would rather call the commands how I want rather than change the defaults :)
<kickinz1> nacc :)
<rbasak> nacc: o/
<nacc> rbasak: heya! do you have a few minutes to chat? I know it's getting late for you
<Pharaoh_Atem> nacc: just got in
<nacc> Pharaoh_Atem: cool, let's see if rbasak is also free, and if not, maybe we can chat a bit
<Pharaoh_Atem> nacc: cool
<nacc> ondrej: how are you dealing with SWIG breakage with PHP7? Seems not yet fixed upstream, so certain src packages that use SWIG to rebuild simply won't work with PHP7.0?
<rbasak> nacc: yes I'm free.
<rbasak> I don't be tomorrow evening, but today is OK-ish. I have some bits to do but am around and can rearrange to find whatever time.
<nacc> rbasak: great, thanks -- i'll set up a hangout, if that's ok with you and Pharaoh_Atem?
<rbasak> nacc: sure. How soon? Now is fine, I just need to reboot into Chrome OS etc.
<rbasak> Pharaoh_Atem might want more notice though!
<rbasak> Not heard from ondrej yet.
<nacc> rbasak: I got a couple responses from ondrej ... tbh, let me just ask my questions here, and we'll see how far that gets us
<Pharaoh_Atem> rbasak: I mean, I'm here
<Pharaoh_Atem> nacc: I can certainly do the hangout thing
<Pharaoh_Atem> just let me know when and I'll find somewhere to go do this
<nacc> so it looks like swig isn't getting fixed necessarily anytime soon; I have the build in my PPA to disable the PHP bindings
<nacc> but that will break e.g., graphviz for a while
<rbasak> Only graphviz's PHP bindings?
<nacc> well, any package that tries to use swig
<rbasak> Or do we need to add a graphviz delta for that?
<nacc> graphviz happens to be in main
<nacc> so I was considering it first :)
<nacc> rbasak: right, so i figured we'd modify graphviz ... but wanted to understand how best to do that? just disable the binary package that contains the php bindings?
<rbasak> Good question. That would certainly work.
<rbasak> I think we might be best getting wider consensus on this.
<rbasak> Good job on identifying graphviz. Do you have a way of generating a complete list?
<nacc> rbasak: i think the pad is now pretty current
<nacc> i've not yet broken it down by swig/pear/pecl
<nacc> that was going to be my next step
<rbasak> Can we publish that and see who objects to disabling those bindings? It'll come down to either doing that or not shipping PHP 7.0 I think, so I assume it'll be OK to do that, but I want to make sure other devs are happy with that.
<rbasak> Before we go mass uploading those disablements.
<nacc> rbasak: yeah, where's a good place to publish it? I can clean it up a bit and put it somewhere "official"
<rbasak> nacc: ubuntu-devel ML please.
<Pharaoh_Atem> I guess I should be on that ml, shouldn't I?
<xnox> given the two are coninstallalbe, surely a bunch of swig based bindings can stay at 5.0...
<nacc> rbasak: also, i noticed that the package in graphviz is 'libgv-php5' ... so would we create a libgv-php? or libgv-php7.0
<nacc> xnox: they won't be coinstallable :)
<rbasak> xnox: except that swig is in main.
<xnox> or for example, build everything for both.
<rbasak> Also, I want php 5.6 gone. Not in main, not in universe.
<Pharaoh_Atem> kill it with FIRE! :D
<rbasak> I think we agreed on that previously, although we can always change that based on new information of course.
<xnox> rbasak, we should just have archive reorg and thus have everything able to build-dep on anything =) no more package splits \o/
<rbasak> xnox: yeah, how are you progressing with that? :-)
<xnox> rbasak, we moved cjwatson into launchpad for exactly that reason!
<rbasak> Anyway, it won't matter if we're losing 5.6 entirely.
<xnox> rbasak, when will swig be 7.0 ready?
<nacc> rbasak: ok, i'll send an e-mail by EOD
<nacc> xnox: no ETA
<xnox> =/
<rbasak> xnox: not imminently, if ever.
<nacc> xnox: as in no upstream progress yet in that regard
<rbasak> xnox: https://github.com/swig/swig/issues/571
<rbasak> nacc: thanks!
<rbasak> nacc: I suggest that you propose to drop the bindings, point out that not doing so blocks php 7.0, and invite objections.
<rbasak> (with a list of affected packages)
<nacc> rbasak: yep, that makes sense
 * xnox ponders if porting swig is easier than disable all the things
<rbasak> Pharaoh_Atem: join the ML if you like. Though posts are moderated for non-uploaders anyway, and an archive is available, so it probably makes little difference. You can participate the same either way :)
<rbasak> (I'm sure the moderators will pass all your emails regarding this transition through)
<nacc> xnox: i was going to look at what was needed, but that was a lower priority for me in the short-term
<nacc> rbasak: ok, next question, I noticed with the move of some commands, tools, the API version is now obtained by php-config --phpapi rather than php5-config --phpapi ... and I noticed that if you run `php-config` from a Xenial prompt
<nacc> c-n-f doesn't know where to find it :)
<rbasak> I think c-n-f is autogenerated periodically
<nacc> rbasak: so ... does c-n-f need updating manually? or is there some voodoo to make it look up new packages?
<rbasak> I'm not really familiar with how it works.
<nacc> rbasak: yeah, i started looking at doing it manually (as we'd want to remove references to the php5 commands in the PPA) ... it didn't seem to like my changes, but it was late when i was doing that
<hallyn> pitti: yup, freezer only by default.  i suppose we could have systemd do that one and Lennart may even be ok with it - but we need pam-cgm for users who want memory cgroup etc - this makes it trivial to add that
<rbasak> mvo knows I think.
<nacc> rbasak: also, the php-pear move is going to be annoying until debian merges it
<nacc> rbasak: that is, w/ PHP5.0, php-pear was generated by the php5 src pkg
<nacc> err, PHP5
 * xnox ponders if i confused php5+7 coninstallability with perl5+6 coinstallability
<nacc> with PHP7.0, it is its own src pkg, which doesn't seem to exist anywhere yet
<nacc> xnox: i think Debian will have coinstallability, but it's kinda messy
<nacc> xnox: and they will move to 7.0 only in the next release, I think
<xnox> and we want 7.0 because....?
 * rbasak wonders why php-pear didn't autosync
<nacc> rbasak: it hasn't been pushed to debian either yet, i don't think
<nacc> rbasak: based upon ondrej's comment earlier
<xnox> i'd say until things in main are fixed to work with php7 we don't want it, as default, or only php. (and that includes swig)
<Pharaoh_Atem> rbasak: I've subscribed regardless
<nacc> rbasak: but we're kind of stuck on pear fixes until that happens, it seems like
<xnox> usually that's the criteria for every other major upgrade.
<cjwatson> rbasak: $ rmadison -udebian -asource php-pear
<cjwatson> php-pear   | 1:1.10.1+submodules+notgz-1 | new        | source
<nacc> right, so i think this is a workflow I didn't understand (and applies to a few other packages that are getting updated to 7.0) -- "new" means that debian is aware of a new revision, but hasn't actually packaged them yet?
<rbasak> cjwatson: ah, thanks.
<rbasak> nacc: ondrej can give us a copy of what he uploaded to Debian NEW if necessary, and we can upload that to Ubuntu in the meantime if necessary. We'll need an Ubuntu Archive Admin to review it if we do that, but it can be done if we're blocked on a Debian ftpmaster processing it at the Debian end.
<rbasak> In fact ondrej's upload is probably in git.
<nacc> rbasak: ok, there was at least one other package that i hit that with in my review
<nacc> rbasak: yes it is
<nacc> rbasak: so i was going to ask that next
<nacc> rbasak: as i go through these pacakges
<nacc> some have been up dated in git with the master-7.0 branches
<xnox> nacc, new means there are brand new binaries intoroduced, and are awaiting manual review before being included. But e.g. maintainer did package and upload it. It's just being held up.
<cjwatson> binaries or sources
<xnox> nacc, mostly legal review.
<cjwatson> where "brand new" == "a binary/source name not currently in the archive", not new version
<nacc> is it appropriate for me to merge them in the ubuntu git tree i'm using to build out a new dsc with an appropriate changelog (referring to the SHA1) entry?
<nacc> xnox: cjwatson: ah ok, thanks!
<Pharaoh_Atem> rbasak: so it looks like the debian package doesn't include working fpm configs
<Pharaoh_Atem> so I'm working on that for the tests and stuff
<nacc> rbasak: the package i was most considering that for was pkg-php-tools, which does have some changes in git that i can merge into my local tree and build out a new package from, i think ... but since it's not yet in a debian package, i wasn't sure if that made sense, or how to changelog it properly (I guess it's a one-off for testing still, so that doesn't matter too much) but basically without the right
<nacc>  phpapi-YYYYMMDD value at build time, the rebuilds don't trigger properly, etc.
<rbasak> nacc: if it's going into Debian as version foo, you can upload to a PPA foo~ppa1. Then foo is higher, so it will supersede it when it appears.
<nacc> xnox: i think the rationale, also, was that if you needed SWIG, then you can stay on 14.04 LTS ... similar to if you needed PHP5 at all. I'm not saying it's perfect, but I think that was the reasoning. Also, PHP5.6 support ends aug. 2017, which is prompting some of the consideration of how to support that package in the LTS, I think
<nacc> rbasak: ah interesting! more nuance, thanks!
<xnox> nacc, and rhel will support 5.4 into 2024
<nacc> xnox: not sure rhel should be anyone's model citizen :-P
<nacc> xnox: but yes, there is that
<xnox> i think pulling off php7 now, will make it a crap 16.04, for the two years that it matters, vs having a good 5.6 for two years.
<nacc> xnox: i'm really not trying to argue the point, sorry -- i agree with you, we should not break *anything* in main, and otherwise not do it
<nacc> xnox: do you mean crap because too much will break? or because PHP7.0 is bad?
<xnox> nacc, not enough critical mass. E.g. not everyone needs it, not everyone can use it, not all dependencies available.
<xnox> people who want php7.0 will be able to use e.g. 16.10
<nacc> xnox: fair points -- I think rbasak was getting quite a bit of PR-work from people that disagree (based upon twitter)
<xnox> but well, it's up to rbasak and server team to decide what they want to have. but e.g. security support for 5.6 over the next 5 years, is easy, given that everyone else is stuck on 5.x series.
<nacc> rbasak: ok, another practical question, just for my own edification. in PHP5, php-json src pkg provides php-json and php5-json bin packages. Now php7.0-json is generated by php7.0 src pkg. So do we remove php-json src pkg and have php7.0-json produce a php-json bin package? Or remove php5-json bin package from the php-json package and have it refer/depend on php7.0-json for now? I guess the latter is mo
<nacc> re sensible
<nacc> xnox: yeah, i'm on that team :) trying to help figure it out as best I can
<rbasak> nacc: we'll need to check the php-json situation. In 5 we (Debian, Ubuntu, Fedora, maybe others) had to diverge from upstream because the bundled json module wasn't Free Software. I don't know if that has changed now.
<rbasak> As a result we had a third party external source (which I think Remi from Fedora put together).
<rbasak> That built php5-json instead of src:php5
<rbasak> It did lead to a circular build dependency that needed to be resolved manually to break the loop.
<nacc> rbasak: ah i see
<rbasak> Now if the licensing is now resolved upstream and we can ship it, then src:php7.0 can build php7.0-json and maybe a php-json alias and we should be fine.
<nacc> rbasak: right, that makes sense; and if not, we'd need a php7.0-json or something?
<rbasak> nacc: if you mean a src:php7.0-json if not, then yes that's right. I suspect it probably is resolved though as I presume that's why ondrej didn't create one?
<nacc> rbasak: do you have a reference I can read as to the prior licensing concern?
<nacc> rbasak: right, sorry, yes that's what i meant
<rbasak> nacc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692613 and also https://bugs.launchpad.net/ubuntu/+source/php-json/+bug/1287726 is relevant.
<ubottu> Debian bug 692613 in src:php5 "php5: non-free files in upstream tarball ("The Software shall be used for Good, not Evil")" [Serious,Fixed]
<ubottu> Launchpad bug 1287726 in php-json (Ubuntu) "Wrong evaluation whether json is valid or not" [Medium,Triaged]
<nacc> rbasak: right, looks like src:php7.0's php-json is under the PHP 3.01 license
<rbasak> Lovely!
<rbasak> I'm glad they fixed that.
<nacc> hrm, i wonder if something didn't get updated, though, README.REDIST.BINS still referes to the JSON license for ext/json/json_parser, but the files in taht directory refer to the PHP 3.01 license
<nacc> rbasak: cjwatson: xnox: thanks for your patience and helpful education! learning a lot quickly...
<roadmr> hey folks! so lp:ubuntu/checkbox is at a point where we can transition it to being a non-native package. The branch would only contain the ubuntu-specific debian/ directory. It will build a single ubuntu-specific package since all its deps are now pulled from Debian.
<roadmr> we're wondering if it's bad practice to "reset" the branch for xenial. The (long and colorful) history for older releases would still be kept in the per-release branches...
<LocutusOfBorg> Pici, , mbiebl_ nice talk
<LocutusOfBorg> pitti, ^^^
 * LocutusOfBorg wrt debugging and dissecting systemd boot issues :)
<LocutusOfBorg> thanks!
<xnox> doko, barry - i wonder if those tests should be skipped for now, to get us going... However i think there is now more test failures, than before.
<xnox> it used to be just the generator on s390x.
<barry> xnox: more failures w/3.5.1?
<xnox> one sec, fiddling with logs.
<barry> xnox: don't forget, i fixed the pickling issue and doko cherry picked that
<xnox> barry, ah, right. so right, wonderful =) so it's just the generator error.
<xnox> anybody using asyncio, with generators, on python3.5.1, on xenial, and can figure out what's wrong are welcome to complain upstream =)
<barry> well, "fixed" maybe :)  in any case, reverted the regression for stable releases
<xnox> cause asyncio changes do look cryptic, and have a bug report attached.
<barry> xnox: i'm not asyncio expert, but i've done some projects using it.  e.g. aiosmtpd still passes all its tests
<barry> i can't judge those asyncio changes tho
<xnox> barry, well, it's not just 3.5.1 but with a co-routie too
<Laney> ginggs: uploaded to exp, feel free to test/sync when it becomes available
<Laney> ginggs: could be up to 8 hours though, so I'll look tomorrow if necessary
 * Laney waves
<mvo> rbasak: cnf unfortuntaely does need manual updating, its pretty trivial, there is a cron job collecting the update and a bzr-buildpackage hook to get it. I can do an update now
<smoser> anyone know if in a buildd (for livefs build) i'd be able to do overlayfs mount ?
<xnox> smoser, i think Odd_Bloke does do loop mount / losetup. i would think overlayfs would be allowed too.
<xnox> ubuntu-desktop is overlayfs, but i guess on boot only.
<smoser> right. i know that loop mounts work.
<smoser> and even asked cjwatson for nbd to work
<rharper> nacc: when I'm done with my logical branch, Im somewhat confused (though it may be because strongswan is special in that we never really had an old/debian that was debian's, rather we have an older ubuntu we're using as old/debian);  when I'm replaying my logical branch onto the new/debian; there's not much overlap since the new/debian is a lot different;  that is, I don't see much of any of the logical changes being
<rharper> able to apply to a new/debian tag because they're so divergent
<smoser> rharper, well, they may not apply, but the logical intent you need to maintain. or decide if you can drop.
<rharper> right
<hallyn> pitti: doh, should have checked the bug earlier - when you're back and have some time, i would very much appreciate some guidance in bug 1533839
<ubottu> bug 1533839 in libvirt (Ubuntu) "vms shutting down on libvirt upgrade" [Critical,Triaged] https://launchpad.net/bugs/1533839
<hallyn> mbiebl_: ^ actually i suspect you can guide me there.  basically, i need help figuring what in libvirt's debian/rules, debian/libvirt-bin.preinst, or debian/libvirt-bin.libvirt-bin.service and debian/libvirt-bin.libvirt-guests.service is causing libvirt-guests.service restart on pkg upgrade
<nacc> rharper: yeah, i think if the underlying source changes a lot the rebase may lead to very different commits (in terms of the code), but the changelog should be applicable still (with the new code) -- or the changes are no longer needed
<rharper> yeah, I'm just going to grind through a rebase and see what I end up with;
<rharper> nacc: there are something like 50 changes I've got in my logical;  it wasn't clear to me that I could drop any of these as we've diverged quite a bit w.r.t how things are packaged (subpackage per plugin versus two packages with all plugins) and aa profiles and other things we're bringing along
<nacc> rharper: yeah, that's probably the simplest thing to do ... it's trivial to roll stuff back, now that you've got tags for the old/new stuff, etc. and you can make throwaway branches of course
<rharper> nacc: also, wasn't quite clear to me how much to drop from the logical branch or whether it should be dropped during the rebase
<rharper> yeah, doing this rebase on a branch
<nacc> rharper: yeah, i think you want to drop as little as possible ... or as you said, do it as late as possible
<rharper> yeah
<nacc> rharper: so will new/ubuntu follow new/debian's system (subpackages etc.) or will you maintain old/ubuntu's  (two packages with all plugins?) (or v.v., depending on which way you meant it)?
<nacc> rharper: i guess those are the decisions you kind of have to make in the rebase/merge :)
<rharper> not sure yet
<rharper> I've neen discussing this with one of our users
<rharper> I'll probably write up an email to ubuntu-devel to discuss
<rharper> it certainly would be nice for merging to not have to keep 40 odd plugin install files; but that's a change from current ubuntu meaning we need to handle upgrades in a sane way
<nacc> yeah, that seems tricky
<nacc> rharper: would something like that be specified in the debian/ dir somewhere? that is, if a certain conf file is here in now, when you upgrade to this version, it goes *here* now?
<rharper> there are two things
<rharper> not really
<nacc> rharper: how is that handled then? i mean, generally speaking when a program changes where it looks for config files, or the structure of its runtime loaded data? symlinks?
<rharper> the new "plugin-standard" and plugin-extras packages would obsolete (I think) the per-plugin packages; so on upgrade, we'd know that if you had plugin-foo, then to install plugins-standard package
<rharper> depends
<rharper> in some cases if enough movement happens, then new versions of the package conflict and break old packages
<rharper> othertimes, configs can be migrated in pre/post scripts;  I'm weak on they policy, so we'd need to read the guides for sure
<nacc> rharper: interesting -- yeah, rbasak pointed me at some docs yesterday, i'm sure it's covered in there somewhere
<nacc> rharper: i'm going to be biking downtown and then i'll be back online -- good luck, let me know if i can help at all
<rbasak> rharper: my intent for the logical tag was to eliminate any churn in old/ubuntu. That is, make old/ubuntu exactly what was intended before in the cleanest and most minimal way. However, retain mistakes, since that helps with verification. Then the logical tag should still be identical to old/ubuntu, but "git log -p" should also be very clear and make sense.
<rbasak> rharper: so quite heavy rebasing, but without actually changing any code.
<rbasak> rharper: then you're in the best possible position to decide how to apply that to new/debian, and you can do it one commit at a time, and not worry about losing anything.
<rbasak> And you can have confidence that there are no mistakes up to that stage, since "git diff old/ubuntu" should be empty except for meta changes.
<rharper> rbasak: I probably need to suffer this rebase and get to the end before I'll really understand this
<rharper> rbasak: that said, I do think strongswan is unique at this point given the large delta between ubuntu strongswan and debian strongswan w.r.t debian/*
<rharper> as an example, I have a conflict during rebase now because new/debian has a subpackage called strongswan-charon, and we don't have that package name at all (rather we package that in a different subpackage)
<Pharaoh_Atem> rbasak: am I doing something wrong here? I can't seem to get the php-fpm config to work: http://fpaste.org/310968/14528042/
<rbasak> rharper: yeah sorry, the strongswan merge turned out to be even more painful than I expected, and you've ended up stuck with it. I think this git workflow shines when it comes to this complexity though. I don't know how I could manage it any other way.
<Pharaoh_Atem> rbasak: err, php-fpm apache config
<rharper> rbasak: no worries;  I figured if I can get this one to work then the rest will be easy (ha! tomcat is next I'm told)
<rbasak> Pharaoh_Atem: I'm not sure. This an area I don't know off the top of my head. I'd have to wade through the Apache config docs to understand, sorry.
<Pharaoh_Atem> it's fine
<Pharaoh_Atem> oh, geez
<Pharaoh_Atem> I think I know why now
<Pharaoh_Atem> :/
<rbasak> Great! Glad to have helped :-P
<Pharaoh_Atem> the socket path for php-fpm in deb/ubuntu doesn't match what the upstream doc said it would be at
<Pharaoh_Atem> so... a tweak here should do it
<Pharaoh_Atem> X_X
<Pharaoh_Atem> nope
<Pharaoh_Atem> hmm
<rharper> rbasak: so, given the divergence, would you expect that after I've rebased old/debian onto new/debian that I'd need to apply some new patches ?  for example, in debian/control debian has different packages (plugin-standard, plugin-extras)
<rbasak> rharper: absolutely. Rebasing old/ubuntu onto new/debian is just the start. That's the automatic way of doing it, and then you have to fix up as needed to make the delta apply correctly, drop unneeded bits, etc.
<rharper> rbasak: Ok
<bdmurray> mterry: I forget did you have some experience with software-center?
<rharper> that helps me make some sense
<rbasak> rharper: you don't even need to rebase if it's too complicated. You could cherry-pick each one instead, fixing up as you go, and just not cherry-pick where not relevant (or write yourself instead of cherry-pick)
<mterry> bdmurray, no not really
<rbasak> rharper: the importance of logical is to make sure that you understand the previous delta, and do the appropriate thing for each item. Even if that's re-write, or drop.
<rharper> rbasak: right, that makes sense
<rharper> rbasak: so, strongswan-5.3.5 % ls debian/*.install | wc -l
<rharper> 9
<rharper> % ls debian/*.install | wc -l
<rharper> 67
<rharper> in general, debian puts all plugins into two packages;  we've got them split out package per plugin;
<rharper> so, using anything from debian w.r.t packaging is *hard*
<rharper> unless, we want to go down the path of switching back to fewer packages
<rbasak> rharper: any path of reducing our delta against Debian is a good one.
<rbasak> rharper: I'm not sure it's worth maintaining a delta to do otherwise here, unless it's because of the main/universe split.
<rbasak> Maybe jpds could explain why it is this way? ^^
<rharper> rbasak: agreed, so, couple of thoughts:  1) I don't know why we split them up  2) existing ubuntu users may have subset of plugins installed so upgrading would require some care to handle not enabling all of the new plugins in the combined plugin packages
<rharper> rbasak: but I do think it would help tremendously to drop the nearly 60 package split w.r.t simplifying delta between ubuntu and debian
<rbasak> rharper: +1, but I guess we do need to trade off the time available with time you could spend on other packages.
<rharper> the other major changes are apparmor policies for packages, but those are trivial in comparision
<rharper> rbasak: indeed, and with jgrimm asking us to look at tomcat next, we're definitely short on time
<rbasak> rharper: also, another advantage of doing it for Xenial is that any transitional delta can be dropped at Xenial+1, so we don't need to carry it as long.
<rbasak> (by transitional delta I mean any Ubuntu delta against Debian that we need to keep only for user upgrade paths from previous Ubuntu releases)
<rharper> right
<rbasak> But if it's marked out and flagged as such, which is easier to do and keep separate with git, then it's not so bad I guess.
<rbasak> I wouldn't compromise other things over it. It would just be nice, that's all.
<nacc_> cjwatson: so as you pointed out earlier, php-pear has a source in debian that's in new ... how do I go find that source? the debian pages all redirect back to php5 as that's the src: for php-pear right now
<rbasak> nacc_: the Debian NEW queue is private, on the basis that it hasn't been reviewed from a licensing perspective yet (that's in part what NEW is for)
<nacc_> rbasak: ah i found it anyways
<rbasak> nacc_: so you have to ask the uploader, or fetch it from VCS or some combination.
<nacc_> http://anonscm.debian.org/cgit/pkg-php/php-pear.git
<Unit193> Or mentors.
<nacc_> rbasak: just not immediately obvious how to find a link to the above URL, but that's ok
<nacc_> rbasak: makes sense
<rbasak> nacc_: the standard is to link to the Vcs from the debian/control file to which you don't have access :)
<rbasak> The PTS gets its link from that field
<nacc_> rbasak: ok, new question, so since pkg-php-tools depends on an appropriate php-pear (which i also need to build), how do I tie them together for sbuild/test purposes?
<rbasak> You can use a PPA
<rbasak> Or sbuild has some options
<nacc_> rbasak: ok, so if i just push php-pear first then pkg-php-tools, it will dtrt?
<rbasak> --extra-package and --extra-repository maybe? They're new-ish options and I did it the old way.
<rbasak> nacc_: yes, provided that the version of php-pear's binaries on which pkg-php-tools build-depends are higher than the ones in the archive, so yours are preferred.
<nacc_> rbasak: got it
<nacc_> rbasak: ok, new question, related (also, isn't it late for you??)
<nacc_> rbasak: but in any case, php-pear only exists in a git-tree so far (no debian package). so there's no tarball to use for dpkg-buildpackage, etc.
<nacc_> rbasak: do i just need to wait?
<rbasak> nacc_: you can take ondrej's upstream branch and use "git archive" to make a tarball out of it, then use that as your orig tarball.
<rbasak> We would prefer to upload to Ubuntu a binary-identical tarball to what ondrej uploaded to Debian since that makes life easier for us, but in a PPA or for local testing using your own constructed tarball should be fine.
<rbasak> Yes it is late for me :)
<rbasak> So much coordination happens in this window though, sometimes I just extend my working hours if I'm around, and adjust some other day in lieu.
<nacc_> rbasak: ok, don't feel any need to stay on my account! i'm sorry to hold you up
<rbasak> nacc_: don't worry, if I had to do something else, I'd be doing it :)
 * rbasak does need to go now though!
<rbasak> See you tomorrow.
#ubuntu-devel 2016-01-15
<theweirdn8> so i have a general question about devving for ubuntu.  If im on Arch Linux Distro, if i compile something there does it work on ubuntu?? Or do  I need ubuntu for ubuntu dev?
<sarnold> It's Complicated
<sarnold> by far the easiest approach is to have an ubuntu system, whether via kvm or lxc or hardware or whatever
<theweirdn8> sarnold: can you elaborate
<theweirdn8> So, assuming im just using C++ and SDL 2.0.x it still wont work easily on Ubuntu?
<sarnold> but there's usually pretty good binary compatibility even between distributions, so long as you stick to the big things, like either using gcc 5.x on both or gcc 4.x on both..
<theweirdn8> Ok, thats interesting to hear
<sarnold> c++ is infact one of the areas where gcc 5.x broke ABI compatibility. your code could probably be compiled on arch and then run on whichever versions of ubuntu shared that same version of gcc...
<theweirdn8> i hope i can get my IDE working on at least Ubuntu and Debian and Raspberry pis
<sarnold> you probably don't need the whole IDE though; just enough build environment needs to exist on the other systems..
<theweirdn8> Working on this
<theweirdn8> http://create.pawbyte.com/
<theweirdn8> im making na IDE
<sarnold> and in fact you can use ubuntu servers to do the actual building, which sidesteps most of the difficulties: https://help.launchpad.net/Packaging/PPA
<sarnold> fwiw, there's also https://build.opensuse.org/ which has been on my "to investigate" list for a few years.. they claim to be able to build debs and rpms from single sources, which would likely save you loads of time
<sarnold> by and large whatever -source- you work on would work fine, but binary compatibility is where things get awkward.
<theweirdn8> oh mkay
<theweirdn8> i will look at it later
<nacc> Pharaoh_Atem: i can try to help you out in the AM
<nacc> AM
<Pharaoh_Atem> nacc: cool
<Pharaoh_Atem> that'd be great
<Pharaoh_Atem> sarnold: it works
<Pharaoh_Atem> I've been using the openSUSE Build Service for years
<Pharaoh_Atem> it's fully binary compatible because it builds Ubuntu VMs to build things on the fly
<Pharaoh_Atem> the only problem (for Ubuntu users) is that the build of osc and zypper is badly broken
<Pharaoh_Atem> as in, it segfaults on some operations due to a bad zypper/libsolv build
<slangasek> cjwatson: did you happen to see that devscripts is dep-wait?
<mvo> rbasak: hi, just fyi (you asked/mentioned this yesterday) - I uploaded a new command-not-found with the xenail data now
<pitti> Good morning!
<pitti> hallyn: the updated systemd is in xenial now
<mvo> mwhudson: hi, I wonder if you can help me? I try to find out what the plan for gccgo and golang 1.5 library support is. I looked at gcc trunk and AFAICS the 1.5 runtime (libgo) go merged ~3 month ago. snappy is using (some) 1.5 library bits and our 5.3 fails right now. now it seems that the gcc5_3 branch does not have 1.5 support and the next gcc is gcc6 - is that correct? no 1.5 support for gcc5.3?
<ondrej> nacc: re swig - ignoring the problem in hope somebody else will solve it?
<mwhudson> mvo: yeah, it's a bit of a mess between go and gcc release schedules
<mwhudson> mvo: however!
<mwhudson> mvo: we shouldn't have to care about gccgo for x
<mwhudson> oh, except for powerpc (32 bit)
<mwhudson> i recommend not caring about powerpc :)
<mwhudson> 1.6 everywhere, with ibm's port to s390x as a distro patch
<cjwatson> slangasek: I hadn't, thanks.  I guess that's a MIR job, will see about that later today
<mwhudson> mvo: there's a 1.6beta2 package in https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages if you want to try that
 * mwhudson goes to bed
<rbasak> mvo: thanks!
<mvo> mwhudson: thanks a bunch!
<mvo> rbasak: yw
<ginggs> Laney: I saw you sync'd glib2.0, thanks!
<Laney> ginggs: np!
<pitti> hallyn: I followed up on #1533839 with an initial diagnosis
<doko> mitya57, dh_sphinxdoc: error: unknown JavaScript code: debian/python-pygraphviz-doc/usr/share/doc/python-pygraphviz-doc/html/_static/jquery.js
<doko> any idea why I see this in xenial?
<ginggs> pitti: in case you are still around, glib2.0 seems to be running its tests against pcre3 8.35, can it be convinced to run them against pcre3 8.38 in -proposed instead?
<pitti> ginggs: it can, but shouldn't it Depends: on the -proposed libpcre3 then if it needs that?
<ginggs> pitti: let me check on that. iirc, the patch for glib2.0 to work with new pcre3 should be conditional
<Laney> It checks the build version
<Laney> I suppose if available we could make it look at the runtime version instead
<nacc> ondrej: :) fair enough -- i've pinged upstream to see if i can help
<nacc> ondrej: but i meant for packages that depend on the swig bindings ... will they just be broken in debian if you try to install php7.0?
<nacc> mvo_: thanks for the cnf data! i'll see what it says today
<pitti> ginggs, Laney: I suppose we are talking about both http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pcre3 and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glib2.0, right?
<Laney> indeed
<Laney> It's more correct to move the check in question to a runtime one
<pitti> $ run-autopkgtest -s xenial --trigger=glib2.0/2.47.4-1 --trigger=pcre3/2:8.38-1ubuntu1 glib2.0
<pitti> started
<pitti> (this will install the -proposed versions of both)
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128, mterry
<mvo_> nacc: sure, your welcome. what in particular was missing there?
<nacc> mvo_: what i noticed was that php-config wasn't showing up as a known command
<nacc> mvo_: php5-config still was but php-config is provided by a package in universe (php7.0-dev, iirc)
<nacc> mvo_: hrm, after update/upgrade, still don't see it ... is there some latency before it will be in the repos?
<nacc> mvo_: or might this be something that needs manual intervention?
<mvo_> nacc: let me check
<nacc> mvo_: thanks!
<mvo_> nacc: oh, is php-config using the update-alternatives system maybe? thats notoriously tricky for the c-n-f parser to parse
<mvo_> nacc: as those are shell constructs etc
<nacc> mvo_: yes, it is
<nacc> mvo_: so in that case, is it better to provide a manual update? I can try and spin something up ... not sure what the best way is
<mvo_> nacc: I guess the parser is just confused, it gets it right for emacs and vi but its fragile by nature as it tries to understand what the shell code is doing without executing it
<mvo_> nacc: I guess I need to look at php7.0-dev to see what it is doing?
<nacc> mvo_: probably :) I'd have to look at the emacs code to understand how cnf parses the file. For src:php7.0, you'll want to look at debian/php-dev.postinst, I think
<mvo_> nacc: thanks, looking now
<nacc> mvo_: also applies to phpize, I think, fyi. This is going to be one of the painful parts of the PHP7.0 transition. They've changed the names of all the binaries away from php<version>-... whatever to php-... whatever. So that's good, but means there might be a lot of churn in the meanwhile. I know those two commands are issues, I'll keep looking for others as I go
<mvo_> nacc: thanks! I think its the quotes that confuse it, I wonder if ${i} would be easier to grok for the c-n-f extractor
<nacc> mvo_: oh good point ... I don't know why they did it that way; these loops are pretty generic to all the php scripts, so could just be c&p
<nacc> mvo_: actuall, i lied, the other scripts use ${var}
<nacc> mvo_: i can push something to debian if that will help?
<mvo_> nacc: thanks, it will definitely not do any harm :)
<nacc> mvo_: ok -- and if we do that, will it get autosyncd and regenerated with cnf in the future? or should i ping you once/if debian updates?
<mvo_> nacc: I will need to a bit more time to build a test case to see if it really fixes it, but emacs is using this and there it works
<nacc> mvo_: sure, np
<mvo_> nacc: once its in ubuntu feel free to ping me, then I will check, the extractor runs daily
<nacc> mvo_: ah got it, thanks!
<mvo_> nacc: cool, thanks a lot!
<hallyn> pitti: thx
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<nacc> hrm, so let's say there's a package that generates a file ... shouldn't apt-file indicate that? or is there something that generates apt-file's contents? In particular, I was looking for the php.h generated by php7.0-dev
<nacc> ondrej: is there a reason php7.0-dev generates /usr/include/php/20151012 (the phpapi) rather than, say /usr/include/php/7.0/ ?
<Pharaoh_Atem> nacc: afaik, that's upstream design
<nacc> Pharaoh_Atem: /usr is quite messy ... e.g., /usr/lib/php/7.0 and /usr/lib/php/20151012
<nacc> Pharaoh_Atem: but yeah, might just be how it is
<nacc> Pharaoh_Atem: means that, e.g., grahviz's swig bindings not only need updating (probably) but also that graphviz's configure does as the paths aren't defined for it search for, e.g. php.h
<Pharaoh_Atem> yeah
<Pharaoh_Atem> upstream likes making things inconsistent
<TJ-> nacc: does "apt-file search -x 'php\.h$' " find the file?
<TJ-> nacc: it uses the packages .list files
<nacc> TJ-: no, it also says that only php5-dev provides it, which is weird
<nacc> TJ-: do I need to do something special, perhaps, to search in universe?
<nacc> that might be the thinko on my part
<nacc> hrm, on my reading, since universe is in my sources.list, it should work?
<TJ-> nacc: well, might be worth doing apt-file update
<nacc> TJ-: yeah, just did -- no difference yet, but i'll check again
<Pharaoh_Atem> nacc: can you help me with this? http://fpaste.org/311344/52885297/
<TJ-> nacc: strange. it puts the content list under "/var/cache/apt/apt-file/"
<nacc> TJ-: ok, will look there next, thanks!
<Pharaoh_Atem> I've been trying to get a working php-fpm conf, and for whatever reason, it's not working :(
<TJ-> nacc: nacc find the package's list and check it. "ls /var/lib/dpkg/info/php7.0-dev.list"
<Pharaoh_Atem> I forked it from the php7.0 config and merged in the conf settings used in Fedora's php-fpm package to make it work
<Pharaoh_Atem> but it doesn't work :(
<Pharaoh_Atem> even accounting for the packaging differences
<nacc> TJ-: ok, php.h is present in /var/lib/dpkg/info/php7.0-dev.list
<nacc> TJ-: but apt-file still doesn't show it
<nacc> TJ-: weird! `apt-file list php7.0-dev` is empty?
<TJ-> nacc: have you configured the repo line in /etc/apt/sources.list or in a file under /etc/apt/sources.list.d/ ?
<nacc> the former, TJ-, unaltered Xenial cloud image
<TJ-> a literal reading of 'man 1 apt-file' suggests it only reads the former
<nacc> TJ-: to be clear, my /etc/apt/sources.list.d/ is empty, and since there are *some* results, it must be using /etc/apt/sources.list ...
<TJ-> Yes; you may have found a bugette :)
<nacc> TJ-: hrm, it seems that php7.0 doesn't even show up in the Contents.gz file(s)?
<nacc> i'm looking /var/cache/apt-file...
<TJ-> nacc: try this: "zgrep 'php\.h[[:space:]]' /var/cache/apt/apt-file/*.gz"
<nacc> TJ-: just shows php5-dev
<nacc> TJ-: so it's like the universe entries aren't there?
<nacc> heh, zless keeps getting killed while trying to page the 32M Contents.gz file :)
<TJ-> nacc: that suggests something wrong with the 'update', or the deb line in sources.list. are there any "universe/<section>/<package> entries?
<nacc> TJ-: hrm, there are, actually, you're right
<TJ-> nacc: I'm running "zgrep '[[:space:]]universe/' /var/cache/apt/apt-file/*.gz | wc -l" to get an idea of how many
<nacc> actually, less was getting OOM killed .... interesting ... probably a bad implementation for memory? does it try to keep the entire file in memory?
<nacc> oh bah, it's because i'm in a tiny VM by default :)
<nacc> TJ-: i get: 4222502
<TJ-> On 15.10 I got 3978947 so you win :)
<nacc> heh
<nacc> Pharaoh_Atem: i'll look, not sure how much help i'll be! what's the symptom of it "not working"?
<nacc> TJ-: ok, so dpkg (perhaps obviously) does know what provides the file I was looking for (but is obviously only look at what's installed) ... ah well, should I file a bug?
<TJ-> nacc: it looks like something is out of sync with the files apt-file fetches, compared to the package .list files. I'm not clear right now how/why that would be
<Pharaoh_Atem> nacc: my hello.php containing "<?php echo "Hello, world!\n"; ?>" doesn't output "Hello, world!" and instead outputs the plain file
<nacc> Pharaoh_Atem: hrm...
<nacc> Pharaoh_Atem: what port is php-fpm listening on?
<Pharaoh_Atem> it's listening on a unix socket
<Pharaoh_Atem> starting with httpd 2.4.12, it can talk to things like fpm with a unix socket, just like nginx can
<nacc> Pharaoh_Atem: ah duh
<nacc> Pharaoh_Atem: shouldn't those be /var/run?
<Pharaoh_Atem> nacc: it seems /var/run is symlinked to /run
<nacc> Pharaoh_Atem: fact :)
<nacc> ah ok
<nacc> and the socket in question does indeed exist, etc?
<Pharaoh_Atem> nacc: yep
<Pharaoh_Atem> the corresponding pid file is there too
#ubuntu-devel 2016-01-16
<hallyn> pitti: bug 1533839 trivial debdiff seems to work;  assume you're out for the weekend but if you get a moment to review that would be great
<ubottu> bug 1533839 in libvirt (Ubuntu) "vms shutting down on libvirt upgrade" [Critical,Triaged] https://launchpad.net/bugs/1533839
<sarnold> hallyn: nice find
<hallyn> sarnold: really pitti found it :)
<sarnold> hallyn: aha :)
<sarnold> pitti: nice find :)
<nacc> Pharaoh_Atem: nothing else sticking out to me yet, but I'll think about it over the weekend
<Pharaoh_Atem> nacc: okay cool
<Mechtilde> https://bugs.launchpad.net/ubuntu/+source/calendar-exchange-provider/+bug/1203433
<ubottu> Launchpad bug 1203433 in calendar-exchange-provider (Ubuntu) "Please remove and blacklist calendar-exchange-provider" [Wishlist,Fix released]
<Mechtilde> what can I also do, to  push on?
<LocutusOfBorg> good morning people, can anybody please sync when possible tcl and tk 8.6 in main?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/tcl8.6/+bug/1417563/comments/10 has the rationale
<ubottu> Launchpad bug 1417563 in tk8.6 (Ubuntu) "please merge t{cl,tk} 8.{5,6} from debian" [Undecided,Fix released]
<Mechtilde> https://bugs.launchpad.net/ubuntu/+source/calendar-exchange-provider/+bug/1203433
<ubottu> Launchpad bug 1203433 in calendar-exchange-provider (Ubuntu) "Please remove and blacklist calendar-exchange-provider" [Wishlist,Fix released]
<Mechtilde> what can I also do, to  push on?
<cjwatson> Mechtilde: it's not about whether it's active upstream or not - there's an archive-wide policy to not include Mozilla extensions because of the lack of time to ensure that extensions still work properly when doing aggressive updates to new versions of Mozilla
<cjwatson> one of my own packages suffers from this too *shrug*
<Mechtilde> also it is maintained in Debian?
<Mechtilde> can you give me a link to this policy?
<cjwatson> Debian> same answer
<Mechtilde> can you give me a link to this policy?
<Mechtilde> s/this/that
<cjwatson> just digging it out
<cjwatson> https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel
<cjwatson> (yeah, I know calendar != firefox, I think that's more a badly-named page)
<cjwatson> you can of course talk to the mozilla packaging people if there's a specific problem with this, e.g. Chris Coulson
<Mechtilde> but in PPA it is allowed?
<cjwatson> sure
<LocutusOfBorg> cjwatson, I sync'd cmtk :)
<LocutusOfBorg> mapreri, cherry-picked in debian all the stuff
<mapreri> LocutusOfBorg: now if you want you can take care of the dcmtk transition in ubuntu (in debian just migrated :P)
<LocutusOfBorg> mapreri, guarda che cjwatson ha giÃ  fatto cmtk aveva giÃ  una ubuntu2 no change rebuild
<mapreri> erm
<LocutusOfBorg> oops, sorry!
<LocutusOfBorg> ELANGUAGE
<LocutusOfBorg> I mean, cmtk had already an ubuntu2 no change rebuild from cjwatson, so I presume he already took care of the transition
 * LocutusOfBorg is sorry for the confusion
<mapreri> LocutusOfBorg: yeah, I read the changelog :P  btw, no the transition is stalled in ubuntu atm, dcmtk is stuck in proposed due to old binaries
<mapreri> also, ubuntu doesn't seem to have something like the auto-transitioner, so there is no transition tracker,  uh
<LocutusOfBorg> cjwatson, https://launchpadlibrarian.net/232931972/buildlog_ubuntu-xenial-arm64.grub2_2.02~beta2-33_BUILDING.txt.gz
<LocutusOfBorg> isn't this a problem because of virtualizated builders?
<LocutusOfBorg> also dcmtk, is missing build on arm64, (I retried the build)
<darkxst> mapreri, there are, but they need to be manually setup (or copied from debian)
<darkxst> mapreri, i.e if you want one, just ask (not me though, I don't have access)
<darkxst> https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/ben
<darkxst> maybe that branch is old though
<mapreri> darkxst: yeah, I know that branch, but I was talking about a thing that generetes ben packages automatically, as it's done in debian.  anyway, I'm already busy enough without taking care of ubuntu's transitions atm...
<LocutusOfBorg> dcmtk is built on arm64
<NikTh> Hello, where can I find the linux_4.3.0.orig.tar.gz file ? I can find linux_4.2.0.orig.tar.gz but not 4.3.0 . Thanks.
<rbasak> NikTh: looking at https://launchpad.net/ubuntu/+source/linux/4.3.0-5.16, I'm not sure why there isn't an orig there, but that is the source I believe. I don't know if linux is somehow special in a way that I'm not aware, or if it's just a native package (which would be odd).
<NikTh> rbasak: I'm not sure either. If I download linux_4.3.0-5.16.tar.gz and rename it, will it work ? I want to avoid uploading the whole source every time I build a new package (in Launchpad). It worked before, but I need the orig.tar.gz file.
<infinity> NikTh: Tim tends to operate without an orig until just before a stable release, but if you want one for a PPA, just use Linus's.
<infinity> https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.3.tar.gz
<NikTh> infinity: I think this will be rejected from Launchpad. Because it's not exist (in Launchpad). Also "debuild" wants a specific form (orig.tar.gz ...etc) in order to work. Am I correct ? Will rename it work ?
<infinity> NikTh: LP doesn't enforce consistency between PPAs and the archive.
<infinity> NikTh: And yes, the name needs to be correct.  linux_4.3.0.orig.tar.gz
<NikTh> infinity: OK, thanks for the info. I will try. :-)
<infinity> NikTh: Basically, unpack Tim's native source, plunk new orig in parent dir, run debuild -S, voila, you should have an orig/diff/dsc setup now.
<infinity> There will be a lot of noise if you debdiff old and new (files in the orig that can't be deleted by that source format), but that's expected.  It'll still build fine.
<NikTh> infinity: Yes I have done this before but it only worked with orig.tar.gz in parent dir and orig.tar.gz downloaded from Launchpad.
<infinity> NikTh: The orig.tar.gz used by the kernel team (when they use one) *is* Linus's tar.gz renamed, it should work fine. ;)
<NikTh> infinity: I didn't know this info. Thanks again. :-)
<infinity> NikTh: Oh, and on your first upload to the PPA with the new orig, you'll need "debuild -S -sa" to include the orig in .changes
<infinity> NikTh: Since you need to upload the orig once. :P
<NikTh> infinity: Yes, actually the command I'm running is " debuild -S -sa -I.git -I.gitignore...blah..blah :)
<NikTh> Then, and after I upload the orig.tar.gz, the same command but with -sd at the end.
<NikTh> infinity: Yes ! It seems it's working correctly. Just a simple rename :-) From dput: "Uploading linux_4.4.0.orig.tar.gz"
<NikTh> infinity: Thank you :)
<Unit193> Why's everyone so eager for 4.3?
<NikTh> infinity: After I upload this orig.tar.gz I will try without it and see if I reach my goal. I cannot think why could fail, but until uploading only the diff.gz .changes...etc , I cannot be 100% sure.
<NikTh> Unit193: I'm not. Actually skipped this version completely. I'm testing 4.4 right now and using 4.1.15 LTS for production :)
<ari-tczew> does someone have any docs about fixing FTBFS like "undefined reference to" ?
<juliank> ari-tczew: Wha
<juliank> What's there to document? Some library must be missing
<juliank> Figure out which and add it to LDFLAGS
<juliank> (Assuming C/C++ and friends)
<ari-tczew> juliank: see buildlog: http://paste.ubuntu.com/14531712/
<ari-tczew> I just added -lacl to the +libgnu_a_LIBADD = $(gl_LIBOBJS) -lacl
<ari-tczew> but seems to be not working
<juliank> I think that only works for static libraries
<juliank> That is, you need to add an LDADD target to the rrep target or something
<juliank> No wait, it's there
<ari-tczew> juliank: could you take a look on https://sources.debian.net/src/rrep/1.3.6-1/ ?
<juliank> I did not know a static library was involved in it.
<ari-tczew> juliank: your feedback/help would be really appreciated
<juliank> With autotools and static libraries involved, that's harder than I thought
<juliank> But if you're using libtool, I think "libgnu_a_LIBADD" should be "libgnu_la_LIBADD"
<juliank> with the extra l between _ and a
<ari-tczew> juliank: I don't know, I just based on the source
<juliank> Ah OK, no libtool
<ari-tczew> maybe that line I choose might be wrong?
<juliank> Nah
<cjwatson> LocutusOfBorg: no, the grub2/arm64 problem has nothing whatsoever to do with virtualised builders.  Please don't blame virt builders for everything!
<juliank> ari-tczew: Did you also add it to libgnu_a_DEPENDENCIES?
<cjwatson> LocutusOfBorg: I've already passed it upstream
<LocutusOfBorg> thanks :)
<LocutusOfBorg> it is trivial to blame the virtualization :D
<ari-tczew> juliank: no, I didn't. should do I? If so, should -lacl be the first or the last?
<cjwatson> LocutusOfBorg: No wonder you thought virt builders were to blame for lots of problems if you're blaming everything on virt. :-P
<juliank> ari-tczew: All the other libraries are there too
<juliank> Example being "libgnu_a_LIBADD += @ALLOCA@" "libgnu_a_DEPENDENCIES += @ALLOCA@"
<juliank> Not sure if that changes anything, but it seems to be the more correct thing to do
<juliank> ari-tczew: But AFAICT it should already be in LDADD:
<juliank> "LDADD = $(LIB_ACL) $(LIBICONV) $(LIBINTL) ../lib/libgnu.a"
<juliank> I'd just move the libgnu.a to the front of it
<cjwatson> LocutusOfBorg: synced tcl8.6 and tk8.6 for you
<juliank> That's in src/Makefile.am
<ari-tczew> juliank: OK, I'll try it without my first own change
<ari-tczew> juliank: pbuilder seems to be happy with change suggested by you. thanks!!!!
<ari-tczew> I'll build it now on PPA.
<juliank> ari-tczew: Yeah, it's a matter of specifying the -l options *after* the objects needing them (here: the libgnu.a)
<ari-tczew> juliank: It's odd, that the same package in Debian builds fine there, though.
<juliank> Different linker settings.
<juliank> Maybe bsymbolic-functions, I don't know
<cjwatson> --as-needed, I expect
<cjwatson> (which isn't on by default in Debian, but is in Ubuntu since natty)
<cjwatson> https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
<ari-tczew> juliank: Also, there is no _missing_ library. The another just should be moved. (conclusion)
<juliank> cjwatson: Yeah, makes sense
 * cjwatson pokes Leif about grub2/arm64 to see if he got anywhere with relocation improvements
<bdrung> cjwatson, vlc daily builds fail: https://launchpad.net/~videolan/+archive/ubuntu/stable-daily/+build/8859183
<bdrung> cjwatson, configure: error: "You cannot build VLC with Qt-5.5.0. You need to backport I78ef29975181ee22429c9bd4b11d96d9e68b7a9c"
<bdrung> cjwatson, can you backport that fix to xenial's qt version?
#ubuntu-devel 2016-01-17
<mapreri> ari-tczew: umh, you're welcome, but what did I do this time? :)  I don't recall giving out pbuilder suggestions in the last hours/days, umhâ¦
<ari-tczew> mapreri: what are you talking about?
<mapreri> oh
<mapreri> ooops
<mapreri> ari-tczew: sorry, I misread the highlight
<ari-tczew> mapreri: no problem, have a nice weekend anyway
<mapreri> ari-tczew: since I became maintaining pbuilder I added an highlight on the 'pbuilder' word, and didn't notice your message at 07:37:10pm was not directed to me, sorry :(
<ari-tczew> lol, something happens
<LocutusOfBorg> thanks a lot cjwatson
<LocutusOfBorg> I closed the sync bug
<cjwatson> bdrung: I can't, no.  Try Mirv
<doko> xnox, looks like the giflib autopkg test fails on s390x. can you re-enable tracker support on s390x, or do I misunderstand something?
* ari-tczew changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Mirv> bdrung: file a bug against qtbase-opensource-src please and I'll see to it
<ari-tczew> mapreri: are you going to merge liferea this cycle?
<mapreri> if somebody would it would be awesome.  I don't like being the person keeping it broken on non-unity DE, and I don't have the skills to fix it.  (talking about #1186801)
<mapreri> ari-tczew: that should be the only package left to merge with my name, isn't it?
<ari-tczew> mapreri: on universe yes
<ari-tczew> mapreri: hmm I need to take a look on that bug 1186801
<ubottu> bug 1186801 in liferea (Ubuntu) "liferea is completely invisible when running on xubuntu" [Medium,Triaged] https://launchpad.net/bugs/1186801
<mapreri> ari-tczew: recently I started to do merge the other way (ubuntu â debian) instead, I like them some more.  but I can't really incorporate that liferea diff :)
<ari-tczew> mapreri: I'm not going to fix that patch, rather disable it or we could even ask the author => xnox
<ari-tczew> mapreri: one tip: if you won't do a merge, it's appreciated to leave a comment on merge-o-matic like "feel free to take" or something
<mapreri> ari-tczew: yeah, sorry.  please add it if indeed.
<nn2> hi. both mpv and sflphone are missing (useful) features due to packaging (missing build-depends and probably depends).
<nn2> could maybe someone have a quick look to get this fixed for xenial if possible?
<nn2> (the relevant bugs are #1502533 and #1533840)
<cjwatson> xnox: please could you merge guilt?  new findutils Breaks the current version
<theweirdn8> Helllo, would u pay for a cross-breed between Unity and Game Maker that works on Linux?
<ari-tczew> if a package has got debian/tests/*, should be there in debian/control "XS-Testsuite: autopkgtest" added to enable tests?
<tumbleweed> not any more
<ari-tczew> thanks tumbleweed
<GunnarHj> doko: My latest attempt to upload the language-selector package resulted in a build failure:
<GunnarHj> https://launchpad.net/ubuntu/+source/language-selector/0.155/+build/8861822
<GunnarHj> It looks like it has something to do with version 3.5.1-1ubuntu1 of python3-defaults. What needs to be done to make l-s buildable again?
<ari-tczew> could anyone point me, what's the actual path of /usr/lib/python2.7/dist-packages/lockfile.py ? I've got FTBFS like this: http://paste.ubuntu.com/14559509/
<theweirdn8> Are these pices outrageous? http://gamepencil.pawbyte.com/game-pencil-engine-comparison-chart/
<infinity> ari-tczew: Lots of different lockfile.py I suppose it depends on which one taskcoach is looking for.  And why it's copying it instead of depending on it.
<infinity> http://packages.ubuntu.com/search?searchon=contents&keywords=lockfile.py&mode=exactfilename&suite=xenial&arch=any
<infinity> ari-tczew: This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788974
<ubottu> Debian bug 788974 in taskcoach "FTBFS: cp: â/usr/share/pyshared/lockfile.pyâ: No such file or directory" [Serious,Open]
<teward> so, i made a bug requesting a package to be removed and blacklisted; do I have to subscribe ubuntu-archive to that?
<teward> s/a package/two packages and corresponding binaries and source/
<ari-tczew> infinity: thanks for looking up. however, there is already a one fix made by doko to get another path for lockfile.py. seems to be outdated :-(
<mwhudson> why would sbuild be spamming call to get_tasks_recursive failed: Invalid arguments received in reply
<mwhudson>  all over the place?
<mwhudson> it seems to work still, mind
#ubuntu-devel 2017-01-09
<pitti> Laney: hmm, http://autopkgtest.ubuntu.com/statistics is just "internal server error" .. what happened there?
<Laney> hey pitti
<Laney> never seen that page before!
<pitti> Laney: I don't look at it often either, but I wanted to for preparing my fosdem talk
<Laney> jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'numpkgs'
<pitti> Laney: hm, any line number? browse.cgi only sets it if there are > 1 results, to avoid showing bogus data for vivid
<pitti> but this seemed to work the last time I looked at it, maybe it got confused by some new releases/pockets/
<Laney> pitti: https://paste.ubuntu.com/23769432/
<pitti> urgh, so numpkgspass exists, but not numpkgs
<pitti> Laney: does http://paste.ubuntu.com/23769438/ help? otherwise it should test for both
<Laney> pitti: I cowboyed it in, seems to
<Laney> oho
<Laney> because of arm64/zesty?
<pitti> Laney: that sounds like a plausible trigger for this crash indeed
<pitti> I covered the "entire release only has one result" case (dummy result for vivid), but not "one architecture only has one"
<pitti> Laney: pushed
<pitti> ... or not
<pitti> $ git push
<pitti> fatal: remote error: Permission denied.
<Laney> didn't you leave the team?
<Laney> :(
<pitti> Laney: http://paste.ubuntu.com/23769462/
<pitti> erk, and "o missing" â "on missing"
 * Laney grumbles for the n+1th time about downloading code from paste.u.c
<Laney> :)
<Laney> ok, pushed, happy talk writing!
<pitti> thanks!
<pitti> Laney: I mostly finished it yesterday already, FWIW
<Laney> looking forward to seeing it IRL
<pitti> Laney: won't have much surprise for you, I'm afraid :)
<Laney> pitti: apart from the slide at the end where you reveal the evil backdoor you left in and activate the world-ending virus?
<pitti> shhht!
<Laney> oh crap, this isn't our encrypted private message
<Mirv> is there a page with amount of hardware for running autopkgtests? if I counted correctly during the weekend, when just huge items (linux kernels) are being executed, there are 10 parallel x86 runs going on.
<pitti> Mirv: we should have a magnitude of 60 parallel x86 runs, 25 ppc64el, and 32 armhf
<pitti> (x86 shares amd64 and i386)
<Mirv> that's why I was wondering last week if they are all alright
<Mirv> so slow, still
<pitti> Mirv: right, that's the "should have"; I can't check any more the actual status, that would be Laney now
<Laney> There's been a lot of parallel linux runs
<pitti> ah, they would take 4 instances each; does linux/i386 still serial-kill workers?
<pitti> in December I regularly had to kill/filter the linux/i386 jobs
<pitti> and run the maintenance cron often
<Laney> Yep, I just pinged apw about that, going to run one in the foreground now
<Laney> then get the console-log when it dies
<doko> stgraber: about https://bugs.launchpad.net/ubuntu/+source/golang-github-coreos-go-systemd/+bug/1520680 ... this needs seeding, it's again in universe, see component-mismatches
<ubottu> Launchpad bug 1520680 in golang-github-coreos-go-systemd (Ubuntu) "[MIR] golang-github-coreos-go-systemd-dev" [High,Fix released]
<Mirv> I wonder anyone ever thanked for the nice performance there is nowadays with publisher runs
<Mirv> if
<cjwatson> that was all wgrant's doing
<Mirv> thanks to him, then
<stgraber> doko: nah, it doesn't. We were using it for LXD, we don't anymore, fine to have it fall out of main.
<stgraber> unless someone else cares about it, but then they should have a dependency to keep it in main
<caribou> rbasak: I think I've found how to reproduce LP: #1342580
<ubottu> Launchpad bug 1342580 in tftp-hpa (Ubuntu) "tftpd-hpa doesn't start on boot" [High,New] https://launchpad.net/bugs/1342580
<caribou> rbasak: since you looked at it a while back, you may want to review my comment that explains the reproducer, the root cause & the potential fix
<ackk> Hi, I'm seeing a strange issue with python-apt, both on xenial and trusty, it seems package descriptionsk that contain non-ascii chars are not decoded correctly:
<ackk> $ python -c 'import apt; print(apt.Cache()["touchegg"].versions[0].description)'
<ackk> Touch?gg is a cross-platform multitouch gesture recognizer that allows associating actions to each gesture.
<ackk> am I doing something wrong?
<dobey> try python3 instead
<dobey> if you're developing new code, you should use python3 not python, generally
<ackk> dobey, python3 works on both trusty and xenial, but I'm seeing an issue in exising code, and python3 is not an option for now
<ackk> dobey, fwiw I also noticed that python-apt in trusty (0.9.3) always returns unicode for package descriptions, but the new 1.1.0 in xenial returns either str or unicode, based on the package
<dobey> so print() decodes to ascii i presume and so non-ascii characters get replaced with ?
<ackk> dobey, even a repr shows the '?'
<ackk> dobey, u'Touch?gg is a cross-platform multitouch gesture recognizer that allows associating actions to each gesture.'
<ackk> dobey, also description[5] == "?" returns True
<dobey> well i don't know the details of your environment
<ackk> dobey, wdym?
<rbasak> caribou: so it'll continue listening on IPv4 and IPv6 as it does right now, but without the race? Sounds good to me, thanks!
<dobey> i mean environment is one thing that may affect stirng handling wrt unicode.
<rbasak> caribou: I'm not sure an SRU is appropriate though. It'll create conffile prompts, no? Anyone affected could just fix the conffile prompt locally.
<ackk> dobey, it wouldn't affect that comparison, though
<rbasak> caribou: I'm not completely opposed to it though.
<caribou> rbasak: indeed, this is something that can be somewhat annoying
<caribou> rbasak: what's better ? a package that may potentially fail to start or a one shot conffile question ?
<dobey> ackk: well i don't know what else to tell you if you can't use python3. in python2 you're almost certainly handling unicode wrong (or some library you're using is), because unicode in python2 is inherently broken.
<rbasak> caribou: if "[::]:69" is *exactly* equivalent to ":69" except for that bug, and there cannot exist a single user who wouldn't want the change, then perhaps we can do some seddery in preinst to avoid the conffile prompt. "may potentially fail" -> depends on the likelyhood, I think.
<rbasak> caribou: this is the kind of case I usually refer to infinity, and do what he says :-)
<rbasak> some seddery in preinst to avoid the conffile prompt> I'm not sure that would work, thinking about it.
<caribou> rbasak: I don't have the IPv6 expertise to claim that they're both totally identical but I can get confirmation fo that
<caribou> rbasak: this is an Ubuntu delta that we introduced. I suppose that if it has been changed, then the seddery would not touch it, otherwise we override our own change
<caribou> rbasak: I'll get clarification about the [::]:69 being the same as :69
<cjwatson> I think this is just a bug in python-apt regardless of the 2/3 issue; it's returning a unicode object, it clearly ought to be able to manage to have it contain unicode without '?' flattening
<ackk> cjwatson, right that's what I thought too. as mentioned I also noticed that in some cases decription is a str, in others unicode. it was always a unicode in trusty
<rbasak> caribou: it might be worth asking stgraber about that too.
<caribou> rbasak: good idea, I'll add him to the query
<cjwatson> ackk: ah, no, it's because apt decodes the description to whatever nl_langinfo(CODESET) says, so you have to have set the locale first
<cjwatson> $ python -c 'import locale; import apt; locale.setlocale(locale.LC_ALL, ""); print(apt.Cache()["touchegg"].versions[0].description)'
<cjwatson> TouchÃ©gg is a cross-platform multitouch gesture recognizer that allows associating actions to each gesture.
<cjwatson> can't be bothered working out why it works in python3 anyway :-)
<juliank> cjwatson: In python3 the low-level C++ module already decodes all files using utf-8 and passes unicode strings back to Python
<juliank> So, there is a slight chance we can get working architecture restrictions lists (stuff like any-arm) for zesty.
<juliank> Currently apt and dpkg disagree on some details, like apt accepts any-armel whereas dpkg does not know that and considers armel to match any-arm
<juliank> dpkg switched from triplets to quadruplets in 1.18.11 - zesty is still at 1.18.10 (see bug 1654905). My current branch can parse either triplet and quadruplet tables at runtime, but it's a bit hacky.
<ubottu> bug 1654905 in dpkg (Ubuntu) "Update dpkg to 1.18.18" [Medium,Triaged] https://launchpad.net/bugs/1654905
<ackk> cjwatson, OIC. that's weird, I have LC_ALL set to empty in my env
<juliank> If anyone has an opinion on any of that, let me know :)
<cjwatson> ackk: setlocale(LC_ALL, "") is a special thing that is not actually about what LC_ALL is set to in your environment
<ackk> cjwatson, oh ok
<cjwatson> ackk: it basically means "import locale information from environment variables into the state of my program", i.e. "activate localisation"
 * juliank recommends switching to python3 ASAP
<juliank> At some point, python-apt will go away and only python3-apt will remain
<juliank> (I'd say not before 18.10, though)
<juliank> And only if python-apt work picks up again. It's kind of stagnant
<juliank> Oh, if someone wants to look at weird stuff: It looks like lsb_release reports Debian in https://launchpad.net/~deity/+archive/ubuntu/sid/+build/10938767 instead of Ubuntu, despite it even being passed a special in-package lsb-release file that explicitly says ubuntu too.
<ignacio> Somehow the lock screen in Lubuntu is not working that good ;-; When I unlock my system (looks like lightdm??) I have to kill lxsession
<ignacio> because I see a black screen saying something about it's still locked
<bdmurray> flexiondotorg: Were you working on a better fix for bug 1623856?
<ubottu> bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856
<fossfreedom> cjwatson: hi - just a bit of advice about our (ubuntu budgie) "fix" to ubiquity.  I think the reason why the changes we made work was because I installed the package first before running ubiquity - I presume it somehow remembered the "sudo" to install the package.  Unfortunately the new package still appears to crash in the same place.  Unfortunately I'm rather out of ideas of how to further debug this.  Any thoughts?
<fossfreedom> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1655119
<ubottu> Launchpad bug 1655119 in ubiquity (Ubuntu) "ubuntu budgie zesty ubiquity crash when installing locales" [Undecided,New]
<debootstrapQuest> Hello there I am wondering if someone can point me in a good direction for creating a iso.  Either with live-build or however Ubuntu iso are created.  Maybe there are some scripts somewhere ?
#ubuntu-devel 2017-01-10
<Mirv> Qt 5.7.1 published, autopkgtest infra might be busy again for a day or two
<mantiena-baltix> Hi seb128
<seb128> hey mantiena-baltix
<mantiena-baltix> seb128: please tell me who could help accept 1 patch from Debian LibreOffice packages to fix bug #1635847
<ubottu> bug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Low,Confirmed] https://launchpad.net/bugs/1635847
<seb128> mantiena-baltix, try sweetshark on #ubuntu-desktop
<mantiena-baltix> seb128: thanks
<seb128> yw
<mantiena-baltix> seb128: Sweet5hark ?
<seb128> yes
<mabkenar> Hi everybody. I have just sent my first pull request to Ubuntu. It is a typo-fix to ubuntu-system-settings (just getting ready for my next substantial merge request).
<mabkenar> Do you know if I have to sign a CLA before it gets merged?
<mabkenar> PR is here: https://code.launchpad.net/~mabkenar/ubuntu-system-settings/typo-fix/+merge/314416
<ackk> cjwatson, hi, I hit another strange behavior between the python-apt lib in trusty and xenial. If I load trusty lists with the xenial version, some packages don't get a description. it seems those are the ones that don't appear in the translations file. but with the python-apt version in trusty it works
<ackk> cjwatson, do you know if there has been some backwards-incompatible change?
<cjwatson> ackk: I don't, sorry
<ginggs> does anyone know why completed builds are stuck showing 'uploading build'? e.g. https://launchpad.net/ubuntu/+source/sagemath/7.4-6ubuntu1 amd64
<ackk> cjwatson, notably with that same package:
<ackk> >>> cache['touchegg'].versions[0].description
<ackk>     ''
<ackk> cjwatson, is there anyone else that might have insight on this?
<cjwatson> ackk: juliank might know when they're around
<ackk> cjwatson, thanks
<cjwatson> ginggs: ouch - https://bugs.launchpad.net/launchpad/+bug/1655334
<ubottu> Launchpad bug 1655334 in Launchpad itself "process-upload oopses if snap was deleted after build completed" [Critical,Triaged]
<cjwatson> ginggs: let me see if we can work around this
<ginggs> cjwatson: thanks
<pete-woods> hi guys
<pete-woods> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2339/+packages
<pete-woods> in that PPA, my packages have been stuck "uploading" for at least an hour
<pete-woods> never seen that happen before
<pete-woods> could it be related to the snappy builds that are stuck, that you're talking about, above?
<ginggs> pete-woods: looks the same to me
<pete-woods> cjwatson: asac
<pete-woods> whoops
<pete-woods> cjwatson: ^ thought that above PPA was showing the same symptoms
<pete-woods> (IRC client went mad there)
<pete-woods> (sorry for the wrong ping)
<cjwatson> pete-woods: same problem, gradually working on clearing it out
<cjwatson> no need for further reports at this time, thanks
<pete-woods> okay, will let you guys fix it up then :-)
<cjwatson> ginggs,pete-woods: still catching up a bit, but it's mostly better now
<pete-woods> cjwatson: cool, thanks for the update :)
<ginggs> cjwatson: thanks!
<gQuigs> was looking at some bugs for evolution and noticed that there is a -proposed package in xenial without an associated bug - https://launchpad.net/ubuntu/+source/evolution/3.18.5.2-0ubuntu3.1 - http://people.canonical.com/~ubuntu-archive/pending-sru.html
<gQuigs> seb128: ^is that revert still needed?
<seb128> gQuigs, yes, we should go back to use the langpack .mo since the bug were those were missing has been fixed
<seb128> which is what this update is doing
<elopio> barry: ping. Are you now in charge of the autopkgtest infrastructure?
<barry> elopio: we're still splitting up the pitti horcruxes.  i don't have access to the infra yet, but Laney does.  i'm working on the software for right now
<ackk> juliank, hi, around?
<juliank> ackk: Yep
<ackk> juliank, do you know if there was some backwards-incompatible change in python-apt in xenial wrt "Description" parsing? I'm using the python-apt from xenial with lists from trusty, and some packages report an empty description
<juliank> ackk: I don't think so.
<ackk> juliank, http://paste.ubuntu.com/23776610/ is an example
<juliank> ackk: Well, what does apt-cache -o Dir=/home/ack/Desktop/apt show touchegg tell you (and showpkg)
<ackk> juliank, that doesn't show the full description, though?
<juliank> Maybe also add -o Dir::State::status=/home/ack/Desktop/apt/var/lib/dpkg/status
<juliank> ackk: hmm?
<ackk> juliank, the full description is in the Translations file, not in the Description field
<juliank> and?
<juliank> I'm not sure what you're trying to say. show will lookup a translated description, and showpkg shows all files containing descriptions
<ackk> juliank, version.description should show the full description, and it does on trusty
<juliank> And it does.
<ackk> juliank, https://pastebin.canonical.com/175488/
<ackk> juliank, or rather http://paste.ubuntu.com/23776635/
 * ogra_ recommends using a public pastebin instead :)
<ogra_> heh, *snap*
<ackk> heh
<juliank> ackk: Right, you do not have the translations
<juliank> showpkg should tell you that
<ackk> juliank, I do have them
<juliank> ackk: Apparently not.
<juliank> Please look at showpkg output
<ackk> juliank, it doesn't report them
<ackk> juliank, but I do have /home/ack/Desktop/apt/var/lib/apt/lists/it.archive.ubuntu.com_ubuntu_dists_trusty-proposed_universe_i18n_Translation-en
<ackk> juliank, uhm, wait you're right. I don't have them for the release pocket
<ackk> juliank, not sure why apt didn't download them
<ackk> juliank, are there any tweaks to tell apt to download or not translation files?
<juliank> ackk: Tons
<juliank> But by default it should download them
<juliank> ackk: maybe retry downloading?
<elopio> barry: I'm asking because I would like to help, with the software. If you have any simple tasks to help me getting started, feel free to assign them to me.
<sladen> elopio: a good place, is you find a piece of software you already use
<barry> elopio: cool.  i'm also advocating a (virtual or irl) sprint to work on both the s/w and infra so we can get better timezone coverage, etc.  would you like to be involved in that if it happens?
<sladen> elopio: and look for something really simple, (like a spelling mistake)
<ackk> juliank, fwiw I was downloading them with passing a config file to apt with just the "Dir" option set
<juliank> ackk: If you use apt with a chroot style without using the hosts settings, you need to specify a config file via APT_CONFIG and set Dir in that one. Otherwise it first loads all configuration from the host and then applies the settings from your file.
<juliank> Because command-line parsing happens after configuration initialization.
 * juliank just had the same issue, wondering why his "chroot" was downloading contents files...
<ackk> juliank, right, that's what I did, basically
<ackk> juliank, oh you mean using an actual chroot?
<juliank> Nah
<juliank> That's why I put quotes around it :D
<ackk> juliank, I mean, if I pass -c it still loads stuff from /etc ?
<juliank> Yes
<ackk> I see
<juliank> In fact, if you pass -c Dir=<foo>, it will not load any configuration from <foo>
<juliank> because config file loading is done before that
<ackk> juliank, )
<ackk> juliank, I'm not passing any -o fwiw, just "apt -c apt.conf" where apt.conf contains Dir "/my/dir"
<juliank> Yes
<ackk> juliank, is there a way to properly isolate it from the system?
<juliank> fIle loading happens before argument parsing.
<juliank> With the APT_CONFIG variable
<juliank> Set APT_CONFIG to the name of the file containing your "Dir" setting
<juliank> apt first loads defaults, then APT_CONFIG, and then Dir::Etc::parts and Dir::Etc::main; and then parses arguments
<barry> elopio: one thing that's hitting me right now is that autopkgtest-buildvm-ubuntu-cloud is timing out pulling down and running a zesty image.  i think it's not that script so much as it is cloud-init.  i haven't had time to dig into that in detail, but that's the next thing on my list when i clear some backlog (and yes, this is yak shaving because i'm trying to see why network-manager won't promote due to systemd autopkgtest regressions)
<nacc> rbasak: fyi, using d/s/f as a fallback for `dpkg-source --print-format` works for util-linux, at leat
<nacc> *least
<ackk> juliank, it seems they're only downloaded for trusty-updates, not trusty: https://pastebin.canonical.com/175493/
<juliank> ackk: pastebin!
<ackk> aah, crap
<ackk> sorry
<ackk> juliank, http://paste.ubuntu.com/23776767/
<juliank> ackk: that's no really useful to look at, we know that stuff already
<juliank> how about update --print-uris
<juliank> (this tells us if it is even trying to fetch it - I think)
<ackk> juliank, http://paste.ubuntu.com/23776774/
<juliank> Then look at the real update output and check if it mentions anything about that
<ackk> juliank, (I also switched to the main mirror, just to be sure)
<ackk> juliank, it does not: http://paste.ubuntu.com/23776780/
<juliank> ackk: I can definitely reporduce this
<ackk> juliank, apparently this is only happening with trusty on xenial, it seems to work with  precise and xenial repos
<ackk> (always from xenial)
<juliank> ackk: Right. I believe apt now requires Translation-en to be listed in the Release file - which it is not on trusty
<ackk> juliank, I see. this seems like a regression though?
<juliank> It's a feature!
<ackk> lol
<ackk> no more annoying trusty!
<juliank> No seriously. It avoids one GET for the i18n/Index on systems that don't have other languages configured
<juliank> In fact, I don't think we use the translation index at all
<juliank> I just special cased -en in my description because that's the only one in trusty-updates AFAICT
<ackk> juliank, is there a way to force it?
<juliank> Not sure
<juliank> I'd just use an older apt to download it...
<juliank> In fact, Debian does not have an i18n/Index
<ackk> juliank, so the problem is that we have one script that we use to build a package db dump for all supported releases, using python-apt. so on xenial I get empty descriptions for packages in trusty
<juliank> You can download the translation file manually and place it at the correct spot to work around this
<ackk> juliank, yeah I guess I'll have to do something like that.
<ackk> juliank, thanks a lot for the help
<juliank> ackk: BTW requiring files to be in the Release file happened because (1) it's more secure (2) we can be relatively sure how much we'll download [progress] (3) less load on servers by useless queries
<ackk> juliank, yeah I understand, it totally makes sense. it's just unfortunate that it leaves the trusty case unconvered
<juliank> Maybe someone could update the Release file there to include those things (and do a manual diff to ensure it's sane)? It's a bit weird thing to do, but it'd help prevent further problems like that.
<juliank> That said, missing descriptions is not a huge issue normally.
<juliank> So it might not be worth it
<cjwatson> unfortunately updating the Release file for trusty causes huge load
<cjwatson> we can in theory do it but we have to be very selective indeed about timing
<juliank> cjwatson: Hmm - why does it cause huge load?
<cjwatson> ddos from ubuntu clients
<cjwatson> effectively
<cjwatson> a few million machines wake up in cron and go "ooh, I have stuff to update"
<juliank> Well, they do already with -updates and stuff
<juliank> not sure how that would be different
<cjwatson> I think there may be a bug somewhere where they redownload too much
<elopio> barry: I have zesty! Let me give it a try.
<cjwatson> and the trusty Packages file is much bigger
<juliank> Right. But they shouldn't (TM) redownload Packages files and stuff if all you change is the Release file (not sure if that's feasible)
<juliank> :D
<cjwatson> I don't have fully accurate information here because any time we try something like this it causes sysadmins to run around with heads on fire
<juliank> That said, might be a bug
<barry> elopio: cool thanks.  note that it will still try to download a zesty image by default on yakkety (i have one machine on zesty and another on yakkety).  but i'd love confirmation -or not- of the problem
<cjwatson> (it's also possible I'm conflating trusty with an older release)
<juliank> trusty is **old** so anything is possible
<juliank> Heck, ld segfaults there on arm64
<cjwatson> juliank: so, slightly more detail, this happened to us on 2015-10-07 when we tried to add InRelease files to precise and trusty
<cjwatson> that appeared to force a redownload
<juliank> cjwatson: Oh well, Release -> InRelease is (or was) a slightly more nasty transition
<cjwatson> in fact it seemed to do so as far up as wily, at least
<juliank> Right, it should be fixed in xenial when that crap was reworked.
<cjwatson> so it may be that it was only due to Release -> InRelease, but I'm still wary because that pegged our bandwidth for quite some time
<elopio> barry: http://paste.ubuntu.com/23777013/
<barry> elopio: huh.  okay, thanks
<nacc> infinity: so i got a request for php-gearman to be made available to 16.04 (it's in 16.10 and on); which we had removed at the time because src:php5-gearman was the only available and upstream had no php7 support. Given that we are sync'ing the package from debian currently, couple of questions: 1) is it best to SRU the 16.10 version back (also means that 16.04 <= 16.10 that way, for upgrades); 2) can
<nacc> we simply sync the debian version in 16.10 to 16.04? Or do I need to submit a proper ubuntu-ized version for SRU purposes?
<elopio> barry: running the command with -v, it worked. The bug doesn't want to be seen.
<elopio> I'll keep running it a few more times. Do you have a bug reported that I can follow?
<barry> elopio: i haven't filed a bug report yet.  just got back from lunch and now i'm trying it on a zesty host
<barry> it's also possible there's a new cloud-init or image or some such today
<jbicha> nacc: I suggest
<barry> elopio: worked beautifully on zesty host.  trying again on yakkety host
<jbicha> backportpackage -s yakkety -d xenial -r -u ubuntu -c 1556460 php-gearman
<jbicha> that's if you want it in xenial-updates, otherwise you can leave out the "-r"
<jbicha> replace 1556460 with the real bug number
<barry> elopio: interesting.  hangs on yakkety host
<barry> elopio: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783202
<ubottu> Debian bug 783202 in autopkgtest "[adt-buildvm-ubuntu-cloud] timeout nearly after display "Net device info"" [Normal,Open]
<infinity> nacc: We can't "sync" it, since the version can't be the same as yakkety.
<infinity> nacc: But I have no issues with you SRUing a no-change backport.  Hard to regress a package that isn't there.
<tzero> is there a convention for naming PPAs? like username/package and username/package-testing ?
<pdeee> rbasak, gentle ping :)
<nacc> infinity: ack, thanks!
<nacc> jbicha: thanks!
<tarpman> hi all. I guess package imports into bzr aren't really happening any more - is there a new place I can browse package contents online? does ubuntu have a debsources instance or anything like that?
<nacc> tarpman: i am working on the server team's git importer, I can import a package for you (or you can od it yourself), but it just reflects the launchpad publishing information.
<nacc> tarpman: do you need the most recnet version, or do you want history?
<tarpman> nacc: basically I'd like to be able to paste links to lines in the openldap source in xenial
<tarpman> not worried about history, I have git for that
<nacc> tarpman: ah, there's not anything generic for that, you're right. The git importer (when pushed to a lp git tree), does let you browse the source
<tarpman> nacc: ok, thanks. we have the upstream source in git.lp.net, but not the packaging. I'll take some time later and try to figure that out
<nacc> tarpman: ah ok, you can also run the importer against your own git tree just to see what it will produce (or --no-push and examine locally)
<tarpman> nacc: "the importer" being https://code.launchpad.net/+code-imports/ or something to that effect, is that right?
<nacc> tarpman: err, no
<nacc> tarpman: that was the old thing, i think
<nacc> or noe of them
<nacc> *one
<nacc> let me get you a link
<nacc> https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer
<nacc> that creates trees that are 'rich history', like https://code.launchpad.net/~usd-import-team/ubuntu/+source/whois/+git/whois
<tarpman> ooh. this looks nifty
<nacc> tarpman: i'm starting to run it autamated in testing for server packages, but we're still working on a few things (like dgit compatibility), etc
<nacc> tarpman: but, generally, it should never fail and can be used completely independent of any 'official' tree
<tarpman> nacc: cool, I'll play with that later. thanks a lot!
<nacc> tarpman: np, if you find issues, feel free to file bugs!
<tarpman> oh, I will >:)
<cjwatson> +code-imports is not "the old thing"
<cjwatson> that's a separate thing - it's Launchpad's system for importing VCS trees from external sources into Launchpad, not specifically about packaging
<elopio> cjwatson: hey, it seems the armhf machines for autopkgtest are returning again armv8l instead of armv7l. Any idea what might be going on there?
<cjwatson> elopio: check the command line and see if compat_uts_machine=armv7l or whatever it is is still there
<cjwatson> elopio: (I have no access to autopkgtest stuff)
<elopio> cjwatson: ok, I will see how to check that. Laney you are hanlding the autopkgtest machines, right?
<ginggs> elopio: the autopkgtest machines are autonomous now
<juliank> Bah, now we're getting multiple duplicates per day for the whole  ttf-mscorefonts-installer faisl to install thingy.
<juliank> That is so seriously annoying.
<dobey> that's what happens when the files disappear from the server for things that have to pull stuff off a server
<juliank> No.
<juliank> It's a redirect with a space in it, apt decoding the URI in the redirect response, and not reencoding it before sending it to the next server.
<dobey> oh? for me i saw it getting 404s from sourceforge
<dobey> oh
<juliank> And this might go on for a few months once fixed, given the speed at which SRUs are accepted.
<juliank> * a few months after a fix was rolled out for zesty, that is
<dobey> well, spin it as a denial of service attack performed by sourceforge on debian/ubuntu users :)
<juliank> dobey: "https://netcologne.dl.sourceforge.net/project/corefonts/the fonts/final/andale32.exe" is a really stupid url
<juliank> github is worse, though
<juliank> It has some weird script thingy with parameters "; filename=" (notice the space after ;)
<dobey> could be worse
<juliank> dobey: AWS which hosts the github downloads responds with "505 HTTP Version not supported" because it things that ;filename=.... is the HTTP version string
<juliank> The others give more sensible errors...
<juliank> Anyone knows if I should quote user and password too?
<juliank> I think host is not to be quoted
<elopio> ginggs: that's the dream :)
<juliank> I fear this might also affect trusty, but not sure.
<juliank> The workaround now only URL-encodes the path of the URL and is currently running test suite.
<juliank> If someone feels like we need to URL encode the rest too, let me know
<juliank> Eww, I accidentally uploaded apt 1.4~beta3ubuntu1 without a copyright file. I should really fix that once and for all (it's a symlink to COPYING which syncs fine, but you can't do direct uploads because Launchpad rejects symlinks there)
<juliank> Oh well, it's going to be fixed next week with 1.4~rc1
<nacc> tarpman: fyi, src:openldap is on the server list, so i'm importing it :)
<tarpman> nacc: excellent, so in a while it'll show up under ~usd-import-team's repositories?
<nacc> tarpman: yep, should be at https://code.launchpad.net/~usd-import-team/ubuntu/+source/openldap/+git/openldap, once it's done importing
<nacc> tarpman: do you need any of the other versions (openldap2, openldap2.3)?
<tarpman> nacc: just openldap, thanks
<nacc> tarpman: np!
<jbicha> I looked at bug 1607535 but the Ubuntu merge looked more complicated than I wanted to work with so I hoped someone that had worked on it before would do it
<ubottu> bug 1607535 in msttcorefonts (Ubuntu) "ttf-mscorefonts-installer 3.4+nmu1ubuntu2 fails to install core fonts and should be updated to version 3.6 from Debian" [Medium,Confirmed] https://launchpad.net/bugs/1607535
<tzero> is anyone familiar with dh_python3? I think it's screwing with dependencies when I add install_requires=[] to setuptools
<juliank> jbicha: Not that problematic. I think there is a redirect for the old URI but that fails due to bug 1651923
<ubottu> bug 1651923 in apt (Ubuntu Yakkety) "apt https method decodes redirect locations and sends them to the destination undecoded." [Undecided,Triaged] https://launchpad.net/bugs/1651923
<juliank> (Fix for that one is in -proposed waiting for autopkgtests)
<bdmurray> nacc: what additional testing did you do in bug 1645431?
<ubottu> bug 1645431 in php7.0 (Ubuntu Yakkety) "[SRU] microrelease exception for src:php7.0 (7.0.13)" [Medium,Fix committed] https://launchpad.net/bugs/1645431
#ubuntu-devel 2017-01-11
<rbasak> pdeee: sorry, I have a big backlog of outstanding things to do for people from before Christmas. Still working my way through (as well as regular work). It's my SRU day today (Wednesday) though, so I'll see if I can review it as part of that.
<jbicha> tzero: you could also try #debian-python on OFTC
<tzero> jbicha: cool, I'll try that, thanks
<tzero> I severely underestimated how much time and effort it would take to create a PPA for a project :/
<pdeee> rbasak, thanks!
<nacc> bdmurray: sorry, I'll clarify in the bug!
<nacc> tarpman: openldap import should be done now
<Laney> elopio: I needed to restart one of the machines - all the others seemed okay
<Saviq> wgrant, hey, another builder kernel update? arm64 fails to build again https://bileto.ubuntu.com/#/ticket/2272
<Saviq> better link https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2272/+build/11841438
<sil2100> Yeah, I published a new kernel to -updates/-security yesterday, so maybe the builders go those automatically
<Saviq> oSoMoN, do you know of an oxide throw of "'std::out_of_range'   what():  map::at"?
<oSoMoN> Saviq, could it be https://bugs.launchpad.net/oxide/+bug/1643976 ?
<ubottu> Error: launchpad bug 1643976 not found
<oSoMoN> huh, why is this bug private?
<oSoMoN> bug #1643976
<ubottu> bug 1643976 in Oxide "webbrowser-app crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Medium,New] https://launchpad.net/bugs/1643976
<Saviq> oSoMoN, yup, looks like it
<oSoMoN> Saviq, can you please confirm (and add details if relevant)
<Saviq> ack
<gabmus> hello people. I am making a graphical application to install GPU drivers on linux, and I'd need some help. I use arch but I'd want to make this application compatible with any (or most) distro. Could you please tell me the packages you need to install on ubuntu 16.04 and 16.10 to get the drivers working respectively for nvidia, nvidia+intel (optimus), intel, amd, amd+nvidia and intel+amd (primus)?
<gabmus> thank you
<rbasak> gabmus: Ubuntu already does this in System Settings->Software & Updates->Additional Drivers. If you still want to write an alternative app, perhaps look at the source of the existing one?
<rbasak> I'm not sure if my knowledge is current. Maybe try #ubuntu-desktop.
<gabmus> rbasak: It's much easier to just get a list of packages from users. If there was a good wiki page about this it'd be better. Don't worry if your knowledge is a bit dated, it's still more than I have right now :)
<rbasak> gabmus: the list of packages will fall out of date though.
<gabmus> rbasak: and I will update it. it's not possible to make this kind of application without updating it.
<wgrant> Saviq: argh, new one uploaded.
<wgrant> Will take a couple of hours to build.
<LocutusOfBorg> nacc, imagemagick uppdate/merge?
<Saviq> wgrant, thanks
<juliank> On a partial request for https://netix.dl.sourceforge.net/project/corefonts/the%20fonts/final/andale32.exe, the sourceforge redirector responds with 302 Found Location: http://downloads.sourceforge.net/mirrorproblem?failedmirror=netix.dl.sourceforge.net
<juliank> - that thing is madness
<ginggs> I'm seeing a few packages coming from Debian that have recently added 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' and now FTBFS in Ubuntu.  Is it sane to change that to 'hardening=+all,-pie' ?
<cjwatson> hardening=+all in Debian is a deliberate request to opt into PIE
<cjwatson> so that sounds like a peculiar approach to fixing the build failures
<ginggs> compare a build log: https://buildd.debian.org/status/fetch.php?pkg=flint&arch=amd64&ver=2.5.2-14&stamp=1482283514
<ginggs> https://launchpadlibrarian.net/299303934/buildlog_ubuntu-zesty-amd64.flint_2.5.2-14_BUILDING.txt.gz
<ginggs> look for the './configure' line
<ginggs> on the Ubuntu build log has -fPIE
<ginggs> *only
<juliank> Both should do -fPIE according to man, wonder what changed
<cjwatson> Debian's dpkg-buildflags doesn't emit -fPIE nowadays since it's the default in the toolchain
<cjwatson> AIUI
<cjwatson> see Debian #835149
<ubottu> Debian bug 835149 in dpkg "dpkg: please adapt setting the default pie hardening flag to gcc's new defaults" [Wishlist,Fixed] http://bugs.debian.org/835149
<ginggs> in this case we are building a library, so we don't actually want PIE, right?
<juliank> Don't we really want the newer dpkg with that change?
<cjwatson> that would seem better than hacking about with individual packages
<LocutusOfBorg> I agree, I had to patch libpng, gdal and many more for this pie stuff
<LocutusOfBorg> not sure why doko didn't switch it yet
<LocutusOfBorg> and I'm also waiting for the new dpkg to merge sbuild
<slangasek> kenvandine: did you mean to edit the TB calendar event,
<slangasek> kenvandine: or was that an Ubuntu Phone playing havoc with sync?
<LocutusOfBorg> gdcm patched too
<kenvandine> slangasek, no... i didn't... it must have been my phone
<kenvandine> damn!
<kenvandine> sigh
 * kenvandine disables canonical account on all devices
<elopio> thanks Laney. Testing again.
<caribou> I'm doing an SRU of a fix in Zesty that brought in two new values to a conffile. Those values are not required to be present in the conffile and can be added later to alter some timings. Would it be sufficient to add a mention in the README to avoid a conffile prompt ?
<RFleming> Greetings and other salutations...
<RFleming> Is there a way to change the mount options for gvfsd-fuse to allow root access to /run/user/x/gvfs... or is it hardcoded somewhere?
<nacc> RFleming: did you perhaps want #ubuntu for that question?
<nacc> tarpman: were you able to look at the openldap import? did it provide what you needed?
<tarpman> nacc: sorry for the delay, import looks great, thanks a lot!
<nacc> tarpman: np! just wanted to check in
<RFleming> nacc: I did ask #ubuntu and in #gnome as well.  I thought to ask here as GVfs is a fundamental part of GNOME and Unity and if anyone knew how to modify how gvfs-fuse-daemon started, it would be developers.
<RFleming> nacc: I'm also aware this really is a fuse issue (in that root can't stat the gvfs folder)
<RFleming> nacc: that's why I was hoping someone would have an idea on passing further options to gvfs-fuse-daemon that would allow root to at least stat the gvfsd-fuse mount
<nacc> RFleming: ok, i just meant topically
<nacc> RFleming: note that it seems root can ls it with gvfs-ls
<RFleming> nacc: Yes, that is true... but the problem is with backup software which doesn't know.
<RFleming> instead it tries to stat it (even though it is ignored ... same with the fstype) and fails to generate a list of files it can backup because it errors out.
<RFleming> I have to manually unmount the gvfsd-fuse mount for backups to function.
<RFleming> It truly is a GNOME only thing
<RFleming> FYI: the backup software is Veritas Backup Exec
<nacc> RFleming: why are you backing up /run?
<RFleming> I'm not, but the agent has to scan the filesystem
<RFleming> ... /run is ignored, so is the gvfsd-fuse filesystem type.
<RFleming> but it still stats every directory
<RFleming> It's frustrating
<nacc> that sounds like broken software
<nacc> why woudl it need to stat directories it is going to ignore?
<RFleming> my guess is "Because it's easier".
<RFleming> it appears to use the ignore lists to not put those items in the selectable list, not in ignoring what to stat
<dobey> so it sounds like you should complain to veritas then
<RFleming> they don't particularly care
<dobey> their software is broken
<RFleming> their answer is... you shouldn't be using GNOME in a server environment, unmount it
<RFleming> but this deviates from the question on how to pass additional options gvfs-fuse-daemon that would let root stat it (without using gvfs commands)
<dobey> so it works with other fuse mounts?
<RFleming> if it isn't possible, then that's that.
<RFleming> I don't have other fuse mounts
<dobey> and does "sudo stat" work on the mount point?
<RFleming> no
<smoser> anyone know how to make this new-fangled ipython work in vi mode ?
<smoser> with the old link to readline i used to hit ctrl-alt-j
<RFleming> dobey: as root /run/user/x/gvfs says permission denied
<smoser> i think i'm supposed to be able to do:
<smoser>  %config TerminalInteractiveShell.editing_mode = 'emacs'
<smoser> per http://ipython.readthedocs.io/en/stable/config/options/terminal.html
<smoser> (err... = 'vi') but that doesnt seem to work for m
<smoser> me
<dobey> RFleming: the problem has nothing to do with gvfs
<dobey> hmm
<nacc> rbasak: ok, i might have found a problem with our -devel pointers
<dobey> RFleming: well maybe it's a bug in gvfs-fuse then
<dobey> RFleming: you could just uninstall gvfs-fuse perhaps
<RFleming> how would that impact Unity?
<dobey> it wouldn't
<dobey> gvfs-fuse is just a magic thing to expose gvfs "mounts" as traditional filesystem mounts so you can access with things that don't support gvfs
<RFleming> ok
<RFleming> It might be better to disable it first
<RFleming> dobey: thanks.
<dobey> sure
<nacc> jbicha: for the pacemaker merge, i see you kept a delta in the yakkety merge, but it only applies if upgrading from 14.04 -- it seems like that could have been dropped post x release?
<jbicha> nacc: I don't know much about the package
<jbicha> I think the changelog is confusing though, I think it's intent is "to maintain compatability with how that package used to work, keep these packages as recommends"
<nacc> jbicha: yeah, i might update in the updated merge to make that clear
<jbicha> I
<jbicha> 've no idea how important those packages are
<nacc> jbicha: ack, thanks!
<nacc> jamespage: --^ i think you actually originated this in the first xenial merge; am I right in thinking we can drop that delta at this point? new installers don't need it (afaict), and upgraders will have it from x release?
<nacc> rbasak: in your branch, `usd import` fails, because import_patches_unapplied_tree refers to oldcwd which no longer is defined?
<nacc> slangasek: since we are not syncing from debian on src:ilohamail (fakesync), but debian has deleted that package, do I need to manually (via bug subscribing ~ubuntu-archive) request its deletion from Ubuntu?
<rbasak> nacc: sorry, I'll take a look.
<nacc> rbasak: np! i was just doing an import and hadn't switched my branch back :)
<rbasak> nacc: I think the easiest way to fix that is to 1) not change the current directory; and 2) use dpkg-source -x ... dsc_path extract_dir.
<rbasak> nacc: I'm not sure if you know that dpkg-source -x takes "output_directory" as an optional second positional argument. Do you see any other issue with that?
<rbasak> We could do that in most places, actually.
#ubuntu-devel 2017-01-12
<nacc> rbasak: iirc, it didn't work the way it seems like it should
<nacc> rbasak: let me see if i have notes
<rbasak> We'd need to drop the extracted_dir os.listdir search thing too. Maybe hardcode it to "$extract_dir/x" or similar.
<nacc> right, but like i said, i think that's what i had before and it didn't do what you expected
<nacc> :)
<nacc> rbasak: ah, it's because the output directory must not already exist
<nacc> and there's no way to make it a temp directory then, without our own managment
<rbasak> That's what I meant by "$extract_dir/x".
<nacc> rbasak: i guess we could racily do a tempname() or whatever, but then... racy
<rbasak> Let me show you what I mean.
<nacc> rbasak: ok
<rbasak> nacc: roughly rewritten dsc_to_tree_hash: http://paste.ubuntu.com/23784442/ (untested, diff not helpful)
<nacc> rbasak: won't, line 59 create the temp directory?
<nacc> rbasak: per `man dpkg-source` the output dir cannot already exist
<nacc> that's what i was trying to say above
<rbasak> nacc: 59 will create temp_dir, yes. But dpkg-source will run on $temp_dir/x, not $temp_dir.
<nacc> rbasak: oh i see what you're doing
<rbasak> So then I don't have to search to find out what it called it, and I get to use $temp_dir for $temp_dir/index later on as well.
<nacc> if you can test it, then sure, that's fine
<nacc> it seems reasonable, i mean
<rbasak> OK, thanks. I'll clean up and rebase.
<nacc> i'd like a comment or something, maybe? it's basically a sneaky way to workaround dpkg-source behavior
<nacc> and easy to miss, imo :)
<rbasak> Sure
<nacc> rbasak: otherwise, in general, the changes for unapproved look good
<nacc> rbasak: how hard was it for you to spin up the changes? just wondering how non-pythonic i'm being
<rbasak> nacc: your code is pretty nice and Pythonic IMHO. The only pain was in shoring up some leaky abstractions, but I think that's to be expected. The number of times the code has been adjusted, and not knowing where we were going in the first place meant that it was inevitable. And I think it's fine to clean up as we go along, so anything I touch I'm cleaning up.
<rbasak> nacc: maybe a few missing context managers (cleaning up stuff by hand instead of using "with" blocks). But nothing major.
<nacc> rbasak: yeah i think i didn't/don't know enough about the pythonic way at the start, so it's probably more imperative and LBYL than it should be. I've been cleaning that up as I go as well
<rbasak> As we're talking about it:
<rbasak>             raise SourceExtractionException
<rbasak> That raises the class object. Should be SourceExtractionException() really - an instance of an exception rather than the definition of one itself.
<nacc> ah of course, makes sense
<rbasak> But this stuff is minor really. Doesn't matter much!
<rbasak> I intend to extend the unapproved stuff and call it "queue" BTW. Since I realised today I want NEW handling too.
<rbasak> Since in SRUs, stuff that hits NEW is often backported from the dev release, and I want to diff against those and they can be imported.
<nacc> rbasak: yep, makes sense to me
<nacc> rbasak: would 'unapproved' be a flag to queue then for that specific case?
<rbasak> My plan is that "usd queue" will update all queue/{new,unapproved}/<release> tags as necessary.
<nacc> ah ok
<rbasak> Assuming you run that from something you have already done "usd clone" on.
<nacc> right, this is all 'detached' from the usd side, right? local-only, i mean?
<rbasak> One catch is that I need some way to know what package name to operate on. I'm not sure we store that currently. So I might ask for that to be added with "git config" at "usd clone" time or something.
<nacc> usd git side, i meant
<rbasak> Correct. All local only.
<nacc> yeah, it's probably not a bad idea to stuff that somewhere
<rbasak> Then, later, I might add something that pulls the entire queue for a release, or all stable releases, or all releases, clones them all, makes sure they're all up-to-date (rerunning "usd import") and then runs "usd queue" in all.
<rbasak> Also perhaps "usd queue approve" or something to accept from the queue a given tag.
<rbasak> As I'm storing the Launchpad queue object API URI in the tag, that should be reliable.
<nacc> ah ok
<rbasak> (or reject)
<rbasak> I need to think about the CLI a little.
<nacc> yeah that seems tricky
<nacc> we can always mark that part as 'alpha' :)
<rbasak> It's only a small set of people who can usefully use it, so I think that's feasible :)
<nacc> and, presuming deps are installed, tab complete works now, so maybe that will help with the options too
<rbasak> I saw that commit. Neat!
<nacc> it's a bit slow, which i think is because of my ordering decisions, which can be fixed
<nacc> but it does work, so little steps :)
<rbasak> nacc: I've updated my branch (fast-forward) so it works but will rebase and squash later to tidy it up.
<nacc> rbasak: ack, just ping me when you're ready for me to merge it in (even if just hte cleanup stack)
<rbasak> Will do
<nacc> rbasak: thanks!
<nacc> rbasak: ah, so nice to remerge something i've merged before, it's already broken up (so `git fetch lpusip; usd merge lpusip/ubuntu/devel lpusip/debian/sid; git rebase -i [to drop the empty merge commits]`, puts me at a fully deconsructed state already
<Mirv> mitya57: retrying pyqt5 i386 as lack of it is blocking Qt 5.7.1 transition and it seems qtwebengine is however now built for i386
<Mirv> mitya57: nope, still failed with "Depends: qtwebengine5-dev (>= 5.7.1+dfsg-3~) but it is not going to be installed", maybe it's unistallable for some reason
<Mirv> mitya57: ah, pyqt5 amd64 binaries are in new queue
<tsdgeos> Mirv: what's holding Qt 5.7.1 landing?
<tsdgeos> i see it marked as "Valid candidate" in the excuses page
<Mirv> tsdgeos: did you read the lines below which you wrote? :)
<tsdgeos> reading which kind of crazyness is this?
<tsdgeos> i see, tx
<acheronuk> Mirv: i386 still did not build, or did you prod it too soon for the amd64 indep packages to have published and be available?
<acheronuk> E: Package 'libqt5webengine-data' has no installation candidate
<acheronuk> so I guess needs to wait a bit
<rbasak> pdeee: can you tell me the relationship between the python-letsencrypt, python-acme and python-certbot source packages please? Which replaced which?
<rbasak> Is it that acme remains unchanged as the backend protocol library, and letsencrypt->certbot?
<rbasak> pdeee: I don't understand why I don't see a python-letsencrypt transitional package in src:python-certbot in the Xenial new queue.
<rbasak> Only one for letsencrypt with no prefix.
<rbasak> pdeee: I commented in the bug.
<LocutusOfBorg> slangasek, FYI I syncd "libdfp"
<Mirv> acheronuk: seems like that, now it's building
<acheronuk> Mirv: so is my staging ppa stuff that was waiting on it :)
<pete-woods> xnox: hi. just looking back at your change in indicator-network at this revision: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-network/trunk/revision/660
<pete-woods> in the maintscript you do etc/.../ instead of /etc/.../
<pete-woods> i.e. without the leading /
<pete-woods> is that intentional, or a mistake?
<pete-woods> cause it looks like the scripts are not successfully removing the old XDG files
<pete-woods> just wanted to double-check before I blunder in and naÃ¯vely stuff a / in
<cjwatson> looks like a clear mistake to me.  lots of debhelper files don't need the leading / (and it's conventional to avoid it since the paths are really relative to the installation hierarchy), but .maintscript is just passed through to dpkg-maintscript-helper which does need the leading /.
<pete-woods> cjwatson: thanks for having a look :) - will put a MR together to fix it, then
<cjwatson> also IMO that should have a version in it somewhere
<xnox> pete-woods, mistake.
<pete-woods> Removing obsolete conffile /etc/xdg/autostart/indicator-network.desktop ...
<pete-woods> woot, looks like it's behaving again now
<xnox> pete-woods, but fixed seperately
<xnox> pete-woods, https://launchpad.net/ubuntu/+source/indicator-network/0.9.0+17.04.20161223.3-0ubuntu2
<xnox> i think that needs remerging, and relanding.
<xnox> cjwatson, there should be a version, but i did not know how to do it properly with substitution of magic version numbers in the silo.
<cjwatson> doesn't have to be a version that exists, as long as it's comparable :-)
<pete-woods> oh, did you land that without going through CI train?
<cjwatson> (also I think bileto supports some kind of poorly-named hack along the lines of 0replaceme
<cjwatson> )
<pete-woods> anyway
<pete-woods> will try and make the same change again
<pete-woods> cjwatson: would 0.9.0+17.04.20161223.3-0ubuntu1~ work as the version to compare?
<pete-woods> (that's the revision that the conf file was removed from)
<pete-woods> there are so many special characters in the bileto versions, I don't know what is greater or less than anything else
<xnox> pete-woods, it should be the version that successfully removes it so 0.9.0+17.04.20161223.3-0ubuntu2~ and whatever new for xenial.
<xnox> i'll try to find the docs for the replaceme stuff.
<pete-woods> xnox: so I need to know the replaceme thing then, okay
<pete-woods> also, a link to those docs would be great
<pete-woods> I don't see, e.g. 0replaceme, in https://wiki.ubuntu.com/Bileto
<dobey> grrrr
<dobey> pete-woods: well apparently now you have to manually merge the changes from zesty, and then do a no change rebuild
<pete-woods> dobey: indeed. always a bit annoying when this happens
<dobey> or change the version in the maintscript to be @replaceme
<pete-woods> dobey: i'm happy enough with 0replaceme, if I can find the correct string
<cjwatson> pete-woods: use dpkg --compare-versions to test things out
<cjwatson> (badly-named> the design basically assumes there's only ever one thing that might want to be replaced, and it isn't self-documenting)
<cjwatson> pete-woods: https://wiki.ubuntu.com/DailyRelease/FAQ documents 0replaceme
<dobey> pete-woods: it's "0replaceme"
<cjwatson> albeit in stuff about symbols files, but same idea
<dobey>  (c++)"UbuntuOne::Token::addOAuthTimestamp(QString) const@Base" 0replaceme
<cjwatson> in this case it should be 0replaceme~ though, I think
<dobey> from a previous branch i landed
<dobey> cjwatson: maybe, but i think the ~ might break it?
<cjwatson> break it how?
<dobey> 0replaceme~ != 0replaceme
<cjwatson> scripts/vcs.sh:    find debian/ -type f -print0 | xargs -0 perl -p -i -e "s/0replaceme/$VERSION/g"
<dobey> oh ok
<cjwatson> so I shouldn't think so
<dobey> yeah if the regex is that dumb it's fine. i just didn't know how clever it was trying to be :)
<dobey> pete-woods: ^^ so 0replaceme~ is what you want in the maintscript for the version
<pete-woods> Cool, will stuff that in
<LocutusOfBorg> hello, how do I fix this bug? https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1557675
<ubottu> Launchpad bug 1557675 in xpdf (Ubuntu) "AppStream icon for xpdf.desktop" [Undecided,Fix released]
<LocutusOfBorg> sorry https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1649660
<ubottu> Launchpad bug 1649660 in hedgewars (Ubuntu) "Gnome Software catalog entry missing for Hedgewars" [Undecided,Confirmed]
<LocutusOfBorg> this one
<Laney> LocutusOfBorg: http://appstream.ubuntu.com/zesty/universe/issues/hedgewars.html
<Laney> same @ debian
<LocutusOfBorg> thanks
<LocutusOfBorg> so no icon is missing
<LocutusOfBorg> wonderful
<LocutusOfBorg> so adding a Comment section is enough
<LocutusOfBorg> ta!
<caribou> infinity: I had a question about silently changing a conffile for tftpd-hpa on Trusty
<caribou> infinity: that's a discussion we had with rbasak recently
<infinity> caribou: What's the question, and can I answer it with "don't do that"?
<caribou> infinity: right now, tftpd-hpa will fail to start if the NIC is not available because it is listening on [::]:69
<caribou> infinity: the fix is to change it to :69 in the conffile. rbasak had worries about that triggering a conffile prompt upon update
<infinity> Oh.  Triggering a conffile prompt because a conffile was updated is exactly why the prompts exist.
<caribou> infinity: and thought that we might sed it in the postinst, since :69 encompass the [::]:69 value and will work in every situation
<infinity> No.  Changing it in postinst is wrong.
<caribou> infinity: I know, but it seemed to bother rbasak
<caribou> rbasak: got a comment on this ?
<rbasak> I said preinst, but I also decided that may not work.
<caribou> rbasak: yes, sorry preinst
<rbasak> I wondered if there was some way to work around a conffile prompt since the two are exactly equivalent, so we may be able to sed in all cases.
<rbasak> But I'm not sure there is.
<rbasak> Anyway. Someone wants a conffile change? Automatic referral to infinity :-P
<infinity> Changing it in preinst is also wrong. :)
<ogra_> nah, just to a boit that says "don't do that !"
<ogra_> *bot
<infinity> If they've customized their config, we assume they like the one they have, hence the prompt.
<infinity> If they haven't touched it, they get the new one silently.
<ogra_> unless an insane developer mangled it from a maintainer script before :)
<infinity> The default may be "bad", but we have to assume that if they've touched the file, they audited and decided they liked the bad default.
<infinity> ogra_: And that developer will be flogged later.
<ogra_> :D
<caribou> rbasak: infinity: I had a similar query regarding a conffile mod for a makedumpfile SRU
<caribou> rbasak: infinity: I'm doing an SRU of a fix in Zesty that brought in two new values to a conffile. Those values are not required to be present in the conffile and can be added later to alter some timings. Would it be sufficient to add a mention in the README to avoid a conffile prompt ?
<infinity> Now, that said, I don't see a conffile in tftpd-hpa...
<LocutusOfBorg> Laney, how long will it take to regenerate that info on software catalog once hedgewars is uploaded?
<Laney> LocutusOfBorg: Not long, few hours at most
<LocutusOfBorg> ok I uploaded it a few seconds ago
<LocutusOfBorg> so, do I need to apt update  or is something automatic?
<infinity> rbasak, caribou: /etc/default/tftpd-hpa is *not* a dpkg conffile, it's created by postinst.
<rbasak> Oh
<infinity> rbasak, caribou: And that throws all your concerns about dpkg conffile prompts out the window.  It's managed by debconf.
<rbasak> caribou: sorry!
<caribou> infinity: sorry!
<caribou> :)
<ogra_> heh
<Laney> LocutusOfBorg: Did you run desktop-file-validate?
<Laney> I think that you made a syntax error
<rbasak> Well then we can just sed it. Though policy does still require that we preserve user changes.
<infinity> Well, "managed".  It seems to be a broken setup that doesn't allow debconf to reconfigure. :P
<rbasak> And do we also need to manipulate the debconf db?
<LocutusOfBorg> Laney, I did run it
<caribou> rbasak: the sed would only change it if it was set to the previous default ([::]:69]
<infinity> rbasak: debconf is not a registry, you should never need to touch the db.
<caribou> ([::]:69)
<Laney> LocutusOfBorg: share/hedgewars/Data/misc/hedgewars.desktop: error: file contains line "Comment: Funny turn-based artillery game, featuring fighting hedgehogs!", which is not a comment, a group or an entry
<infinity> rbasak: If maintainer scripts aren't written to prefer the config file over the DB, that's a bug.
<LocutusOfBorg> DAMN
<LocutusOfBorg> you are right
<LocutusOfBorg> I didn't quilt push
<rbasak> infinity: what if debconf suggested the previous default to the user, and then stored it?
<LocutusOfBorg> :/
<LocutusOfBorg> dpkg-buildpackage unapplies patches
<rbasak> rbasak: then a future dpkg-reconfigure would restore the old default, no?
<infinity> rbasak: See above.  The authoritative version is always the config file, never the debconf DB, per policy.
<rbasak> Ah, so the config script should read the config file over the DB when prompting for future defaults? That makes sense, thanks.
<LocutusOfBorg> ta
<infinity> rbasak: And, indeed, the tftpd-hpa package does that correctly (sources the config file, stores the values, then asks questions).
<cjwatson> picking the current state out of the config file and stuffing it into debconf as the default value before asking a question is OK though
<cjwatson> yeah, that
<infinity> rbasak: What I don't see it doing is actually rewriting the config file on reconfigure. :)
<infinity> But hey, minor oops.
<Laney> LocutusOfBorg: Might want to cancel the builds to save the environment a bit. :)
<LocutusOfBorg> indeed
<infinity> caribou: As to your makedumpfile thing, you can either ship a new conffile with the new keys or not.  Your call as the maintainer.
<infinity> caribou: If it behave correctly without the keys specified, mentions of them in changelog, READMEs, or manpages are all fine.  *shrug*
<caribou> infinity: the new keys are only comments for reference
<caribou> infinity: k, I started to have second thoughts after rbasak's comments about tftpd-hpa
<infinity> caribou: To be fair, people will see that conffile prompt on 16.04->18.04 upgrades anyway, so you can't avoid it forever.
<infinity> caribou: (Well, they'll see it if they changed their local copy)
<infinity> conffile prompts aren't evil, what's evil is when packages alter conffiles outside the proper dpkg mechanism and create *spurious* prompts.
<infinity> Users being prompted because *they* changes the file and then you shipped a new one is working as designed.
<infinity> s/changes/changed/
<caribou> infinity: yeah,never worried too much about it as I saw it as expected behavior
<rbasak> One problem though is that some people never see conffile prompts (unattended upgrades, etc). So then default conffile handling behaviour takes over, which I think may be confold? And then that defeats some of the point of fixing it, if the goal is to get those users as well.
<rbasak> This applies to server stuff quite a bit, where a commonly conffiles have to be edited for their packages to be useful.
<infinity> Default should be confold, yeah.  I'd like to think people who run unattended-upgrades on critical infrastructure also go looking for .dpkg-new in /etc occasionally.
<infinity> But I bet they don't.
<infinity> I wonder if we could motd snippet that or something.
<cjwatson> I've gone through all the stages of grief on this and eventually decided that conffile prompts (or ucf) are still the least painful thing.
<infinity> "A recent upgrade resulted in N unmerged conffiles in /etc"
<rbasak> That's a good idea.
<cjwatson> After having years of accretion of weird sshd_config editing runes in openssh-server.postinst.
<cjwatson> infinity: Very Gentoo :-)
<caribou> yeah, I like the fact of being told about things that should be looked at
<cjwatson> (It has something very similar IIRC)
<infinity> cjwatson: Oh, I thought you were punning about emerge.
<infinity> cjwatson: But yeah, if they have something like this, they might be doing something right.  rbasak's not wrong that there's a general conflict between silent upgrades and conffile updates.  Post-facto notification seems not entirely bad.
<cjwatson> Gentoo doesn't have any automatic conffile merging, so it *has* to have a prompt at the end to tell you to apply changes.  But that's not to say it's a bad idea.
<infinity> I wish we'd done etckeeper-by-defalt long ago, so we could just say "/etc has unresolved conflicts, fix plz".
<infinity> Well, and hook it into dpkg, so a conffile update is actually a merge attempt that vomits to conffile.rej on failure, etc.
<infinity> Woulda shoulda coulda.
<infinity> I suppose we still could some day.
<infinity> Though, I guess working toward the new world oder of "defaults in /usr, overrides in /etc" is a better use of time.
<infinity> Maybe we can actually have an empty /etc by 2038.
<infinity> Well, empty except for /etc/rmt, because that bit of backward compatibility is super important to someone from 1972.
<philroche> Hi guys, I'm hoping someone can steer me in the right direction. Earlier today gce-compute-image-packages was accepted in to xenial-proposed pocket but the binaries are not being published to the repository. The amd64 build is stuck "Pending publication" (See https://launchpad.net/ubuntu/+source/gce-compute-image-packages) Is there anything I need to do to get past that stage or is it just a matter of waiting?
<nacc> philroche: i'm guessing here, but it's a new src and binary, so it will need approval by an AA to migrate to -proposed.
<seb128> could somebody from the SRU team copy https://launchpad.net/ubuntu/+source/evolution/3.18.5.2-0ubuntu3.1 over from xenial-proposed to updates? the update was accepted without a bug reference and is probably stucked because of that but the change is fine and has been tested
<seb128> bdmurray, ^ you maybe?
<bdmurray> seb128: looking
<seb128> bdmurray, thanks
<cjwatson> nacc is correct; the binaries are new in that suite so it's in the NEW queue for approval.
<nacc> philroche: --^
<bdmurray> seb128: released it
<philroche> cjwatson: nacc: Thanks
<seb128> bdmurray, thanks!
<nacc> philroche: note that you can also see that from https://launchpad.net/ubuntu/+source/gce-compute-image-packages/20160930-0ubuntu3~16.04.0 (the '(New)') next to the build
<philroche> nacc: Ah. I see thanks
<nacc> philroche: and you can also see it here: https://launchpad.net/ubuntu/xenial/+queue
<philroche> nacc: This process is new to me so thanks for that.
<nacc> philroche: np, I often forget about it too :)
<nacc> philroche: / it's new to me as well
<sil2100> Laney: hey! Would you mind if I re-upload the dbus package with just the ssh/logind workaround?
<Laney> sil2100: If you take over the other fix too
<sil2100> Laney: what do you mean?
<sil2100> Laney: I see it's marked as verification-failed right now and causing some issues, right?
<sil2100> We just want to get the ssh fix released as soon as possible as many users are waiting for it
<Laney> sil2100: Yes, but it's not buggy itself. If you want to revert it to get your other fix in, then I would appreciate you taking care of putting it back when it is safe to do so.
<sil2100> Laney: ah, like this
<sil2100> Ok
<sil2100> Laney: I can do that sure
<Laney> Cheers
<nacc> rbasak: still around?
<mitya57> Mirv, it looks like pyqt5 built everywhere now.
<Mirv> mitya57: yes. if you or someone has time, look at the qtquickcontrols examples installability issue on excuses page (I'm going to sleep now already)
<Mirv> qtquickcontrols5-examples/amd64 unsatisfiable Depends: qml-module-qtquick-extras etc
<Mirv> acheronuk: ^ note, at least that found from excuses page, no need yet to decipher update_output more
<bdmurray> Laney: Do you know what Code 20 means in autopkgtest results?
<davmor2> bdmurray: it's a countdown to total global annihilation you really need to stop it before it gets to 0 ;)
<mitya57> Mirv, qtquickcontrols5-examples is installable in my amd64 chroot.
<mitya57> Though, qml-module-qtquick-extras is the only dependency that is in universe, so probably that is the issue.
<mitya57> Maybe someone can promote it to main? (It comes from qtquickcontrols-opensource-src source which is in main.)
<pdeee> rbasak, hlieberman and RAOF may be better equipped to answer your questions, but
<pdeee> AFAICT python-certbot Replaces: python-letsencrypt
<pdeee> python-acme is a dependency of either of those
<pdeee> not sure how that relates to source packages, though
<bdmurray> jbicha: How was bug 1649995 fixed in zesty? Just setting it to Fix Released doesn't help me from an SRU perspective.
<ubottu> bug 1649995 in gnome-online-accounts (Ubuntu Yakkety) "Replace Google API key used by GNOME services" [High,In progress] https://launchpad.net/bugs/1649995
<bdmurray> zul: The existing nova-lxd SRU hasn't been verified (bug 1642274). Do you want the new upload to supersede it?
<ubottu> bug 1642274 in nova-lxd (Ubuntu Yakkety) "[SRU] newton nova-lxd 14.0.1 point release " [High,Fix committed] https://launchpad.net/bugs/1642274
<zul> bdmurray: lemme check around
<bdmurray> zul: okay
<smoser> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html <-- why is cloud-initramfs-tools there ?
<smoser> 'missing build' seems relevant, but there is a build
<hlieberman> rbasak: Hiya.  Debian maintainer of the certbot stuff here.
<hlieberman> rbasak: So, yes, you're correct: python-acme stays the same, python-letsencrypt => python-certbot, letsencrypt => certbot, python-letsencrypt-apache => python-certbot-apache
<hlieberman> Generally, users wouldn't have installed python-letsencrypt directly, so there's no transitional package there.
<cjwatson> mitya57: done
<hlieberman> If they did, they could be using plugins that wouldn't work in the new namespace.
<jbicha> bdmurray: it was fixed in gnome-online-acccounts 3.22.3-1, I've added that to Other Info on the bug now
<jbicha> we have to figure out how to get evolution through phased-updates thoughâ¦
<bdmurray> jbicha: Do you know anything about this new crash?
<jbicha> no, it does look new; I can ping the evolution maintainers about it
<jbicha> actually it was evolution-data-server that needed to be updated first but that's fully phased so we don't need to let that stop us from updating g-o-a now
<bdmurray> looking at the error tracker I don't see any other crashes with webkit_editor
<jbicha> right and it was in yakkety that evolution switched from webkit1 to webkit2 so it's probably new to yakkety
<jbicha> bdmurray: thanks. Could you look into the libicns yakkety SRU? it's needed for hdhomerun-config-gui to build there
<nacc> juliank: do you know what's going on with LP: #1522675? seen an uptick lately in people hitting it on #ubuntu
<ubottu> Launchpad bug 1522675 in update-notifier (Ubuntu) "Warning messages about unsandboxed downloads" [Medium,Confirmed] https://launchpad.net/bugs/1522675
<juliank> nacc: More users upgrading to >= xenial?
<juliank> Someone may want to play with update-notifier's use of apt-helper and have it download stuff into a directory writeable by the _apt user
<nacc> juliank: checking on the current user who brought it up
<juliank> Same for synaptic apparently.
<juliank> Funny how ubottu  says bug in update-notifier (Ubuntu)  but the link it gives redirects to https://bugs.launchpad.net/debian/+source/synaptic/+bug/1522675
<ubottu> Launchpad bug 1522675 in update-notifier (Ubuntu) "Warning messages about unsandboxed downloads" [Medium,Confirmed]
<nacc> juliank: in this case, user already ahd fonts package installed, and a regular update failed, it seems (on 16.04). Not dist-upgrading.
<nacc> juliank: multiple tasks in same bug
<juliank> Well, nothing is failing there
<nacc> juliank: can be referred to by multiple src pkgs (therefore)
<juliank> nacc: I think you really meant bug 1651923
<ubottu> bug 1651923 in apt (Ubuntu Yakkety) "apt https method decodes redirect locations and sends them to the destination undecoded." [Medium,Triaged] https://launchpad.net/bugs/1651923
<nacc> juliank: ah that's the underlying spaces issue?
<juliank> There's a workaround in zesty, and I'll backport this shortly to yakkety and xenial, but I first want to write a regression test case and optimally do the whole thing in an upstream release (scheduled in 4-5 days)
<nacc> juliank: ack, just trying to get context so I can provide the best answer(s) in #ubuntu
<nacc> juliank: right now, folks are manually installing the .deb from unstable
<nacc> for the fonts package
<juliank> That works too as it skips the redirector or something
<nacc> yeah, i think the fonts package (debian) has changed that as well
<nacc> so it's like there are two fixes :) (for that particular package)
<juliank> Yeah, but there's others mentioned in the bug log
<nacc> yep, presumably any of the ones that are downloading something during the install could be affected
<jbicha> I'm guessing bug 1607535 is the same issue
<ubottu> bug 1607535 in msttcorefonts (Ubuntu) "ttf-mscorefonts-installer 3.4+nmu1ubuntu2 fails to install core fonts and should be updated to version 3.6 from Debian" [Medium,Confirmed] https://launchpad.net/bugs/1607535
<nacc> juliank: thanks for the bug link and clarification!
<nacc> jbicha: ack, that's the one i saw yesterday
<juliank> If anyone is an http expert: I only urlencoded the path component of URLs we give to curl. I wonder if I should also urlencode some more parts - but I'm not sure.
<nacc> jbicha: dunno if you want to update with references to the other two bugs
<jbicha> if 1651923 is the main bug, we can duplicate the other bugs to there
<juliank> jbicha: Keep one open for the package update request?
<juliank> It's the same underlying issue of course, but a package update obviously also entails other things and is good to have in either case.
<jbicha> oh for ttf-mscorefonts? I'll open a different bug requesting that be updated
<juliank> Yes. I remember someone tried merging that yesterday, but it was a bit complicated.
<rbasak> hlieberman: hi
<rbasak> hlieberman: still, it makes python-letsencrypt un-updateable, so I think we do need an update for it bundled with this SRU.
<hlieberman> rbasak: A dummy?
<rbasak> hlieberman: we could drop letsencrypt from src:python-letsencrypt, and the same for apache if that works the same way.
<rbasak> hlieberman: since src:python-certbot is taking the package over.
<hlieberman> src: python-letsencrypt can be RMed.
<hlieberman> It's completely replaced.
<rbasak> hlieberman: not from a stable release, unfortunately.
<rbasak> We could replace it with an empty package, but users may still theoretically be using python-letsencrypt ("import letsencrypt"), and I don't think there's any need to drop that from a stable release here.
<hlieberman> python-certbot Break's python-letsencrypt.
<rbasak> Oh.
<rbasak> Well, that's something that should be discussed in the bug then.
<rbasak> Because it's a use case that could exist that we definitely are breaking.
<hlieberman> Because it ships a symlink for /usr/bin/letsencrypt and Provides: letsencrypt.
<rbasak> Surely that's letsencrypt, not python-letsencrypt?
<rbasak> Uh, sorry.
<rbasak> Surely that's certbot, not python-certbot?
<hlieberman> Oh, yeah. Sure. I suppose someone could theoretically want python-letsencrypt but not letsencrypt, though it would be very strange.
<rbasak> Why aren't they the same package?
<hlieberman> The library isn't really meant to stand alone, like python-acme is.
<hlieberman> They're the same source package.
<rbasak> Why aren't they the same binary package?
<hlieberman> Sorry; I'm on my cell phone, so I might not be explaining this very well.
<rbasak> If it's not meant to stand alone, shouldn't it be in /usr/lib/certbot?
<rbasak> https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs "4.2.1 Programs Shipping Private Modules
<rbasak> "
<hlieberman> It's can't be private in that sense, since a third package does depend on it. python-certbot-apache.
<rbasak> I see, OK.
<rbasak> Why must python-certbot Breaks: python-letsencrypt?
<hlieberman> And python-certbot-nginx, though that's not relevant.
<rbasak> AFAICT, they provide different files.
<hlieberman> It doesn't. I'm sorry, I meant s/python-// before.
<hlieberman> That's my fault.
<hlieberman> certbot breaks letsencrypt.
<rbasak> Actually it looks like it does.
<rbasak> In queue/xenial/new
<rbasak> Package: python-certbot
<rbasak> Breaks:...python-letsencrypt (<= 0.6.0)
<rbasak> Replaces: python-letsencrypt
<hlieberman> Ah -- are you going to be around in a bit? This really should wait until I'm actually in front of my computer.
<rbasak> I appreciate that's fine for ongoing development.
<rbasak> But for the SRU, maybe we could drop that?
<rbasak> I'll be going to bed soon, sorry. We can chat another time though, just ping me.
<hlieberman> Since I am clearly not word-ing very well.
<hlieberman> Sure thing. I'll put something in the bug and try and catch you tomorrow.
<rbasak> OK. I appreciate you getting in touch. Thank you for helping with this.
<hlieberman> Of course! Sorry for the confusion
<rbasak> No problem. It's confusing by its nature. I don't mind working through it, just want to get to the bottom of it and reach an agreement and get it done :)
<hlieberman> Yeah. The differences between Debian and Ubuntu is just slight enough to really trip me up, too.
<hlieberman> Like with Maintainer. I know I knew that, once upon a time.
#ubuntu-devel 2017-01-13
<joed_> soooo
<RogueOmega7> anyone here wanna bs about ubuntu / unity convergence?
<cpaelzer> add "ipv6.address: none" in the edit "lxc network edit lxdbr0" gives you
<Laney> bdmurray: see man autopkgtest, could be lots of things
<pete-woods> can anyone with more debian-packaging-fu than me understand what's wrong in this autopkgtest log? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-ci-train-ppa-service-2362/zesty/amd64/u/unity8/20170113_095859_4ba42@/log.gz
<Mirv> pete-woods: you need to ask for retrying the tests with all-proposed=1 until Qt 5.7.1 transition is over (which is currently waiting for archive admin action)
<Mirv> pete-woods: ...retried both
<pete-woods> Mirv: thanks! hopefully that works
<coreycb> doko, i have a fix for cinder (well kombu) re: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20161216-updates-python2712-trusty.html
<coreycb> doko, i'm not sure how best to provide it to you though
<coreycb> doko, it might fix up glance too
<coreycb> doko, here's the debdiff: http://paste.ubuntu.com/23792290/
<doko> coreycb: does it work with the old python 2.7 as well?
<doko> if yes, then maybe SRU it?
<coreycb> doko, good question, I'll try it out
<tjaalton> mdeslaur: hi, sudo needs a merge.. 1.8.16 is buggy with freeipa/sssd, fixed in .17 (#1607666). do you have plans to merge 1.8.19 for zesty?
<mdeslaur> tjaalton: 1.8.19 has a syslog regression I believe
<mdeslaur> we need 1.8.19p1
<tjaalton> ok
<mdeslaur> tjaalton: looks like mvo touched it last, would have to ask him what his plans are
<barry> stgraber: we're seeing some new regressions on ubuntu-image promotion in zesty on armhf.  are you aware of or can think of any changes that might have broken devmapper?  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/u/ubuntu-image/20170111_171929_431b1@/log.gz
<mvo> tjaalton: take it if you have the time
<tjaalton> we'll see :)
<smoser> nacc, do we expect to get upstream tags on usd imported things now ?
<tjaalton> might just fix that bug so that sru is possible
<smoser> nacc, and, when you're about... is there a way to do a clean import even if the thing has already been imported?
<smoser> this seems to work...but wondering if there was a more direct way
<smoser>  usd import -v --director=cloud-utils --lp-user=smoser --lp-owner=NONE cloud-utils
<rbasak> smoser: I discussed that with nacc yesterday. He's being doing what you did. I have a branch I've added --no-fetch to, but it's not ready yet.
<rbasak> *been
<smoser> rbasak, for this specific need, i just deleted the branch :)
<smoser> on lpusp
<smoser> i know i shoudlnt do that generally, but i think it was fine here and i wanted the newly imported thing with tags and such.
<rbasak> ddstreet: can you help me with reviewing bug 1642903 please? I haven't yet figured out what the specification of udev_event_apply_format is supposed to be :-/
<ubottu> bug 1642903 in systemd (Ubuntu Trusty) "introduce disk/by-id (model_serial) symlinks for NVMe drives" [Wishlist,Fix committed] https://launchpad.net/bugs/1642903
<rbasak> And trying to follow string manipulation in raw C makes my head hurt :-(
<rbasak> So reverse engineering its intention is difficult.
<rbasak> I understand that SUBST_* seems to match udev rule syntax roughly.
<rbasak> I mean bug 1647485, sorry.
<ubottu> bug 1647485 in systemd (Ubuntu Zesty) "NVMe symlinks broken by devices with spaces in model or serial strings" [High,Confirmed] https://launchpad.net/bugs/1647485
<sladen> rbasak:
<sladen> rbasak: doesn't appear to be any C involved in that at all.  Just adding some udev rules (https://launchpad.net/bugs/1642903)
<ubottu> Launchpad bug 1642903 in systemd (Ubuntu Trusty) "introduce disk/by-id (model_serial) symlinks for NVMe drives" [Wishlist,Fix committed]
<rbasak> sladen: sorry, wrong bug. I meant bug 1647485
<ubottu> bug 1647485 in systemd (Ubuntu Zesty) "NVMe symlinks broken by devices with spaces in model or serial strings" [High,Confirmed] https://launchpad.net/bugs/1647485
<coreycb> doko, kombu tested and uploaded to trusty review queue
<rbasak> ddstreet: never mind. I think I've figured it out.
<ddstreet> rbasak sorry, just saw this, let me know if i can help
<ddstreet> and yeah, that udev tangle is not easy to follow
<sladen> ddstreet: reading that patch, I [think] it is possible to reach the end of  udev_event_apply_format() with an uninitialised sbuf[]
<ddstreet> sladen sbuf should only ever be used if replace_ws is true
<ddstreet> where are you seeing a problem?
<sladen> ddstreet: https://git.launchpad.net/~ddstreet/+git/systemd/tree/src/udev/udev-event.c?id=a135967a#n216
<sladen> ddstreet: followed by eg.  https://git.launchpad.net/~ddstreet/+git/systemd/tree/src/udev/udev-event.c?id=a135967a#n228
<sladen> ddstreet: meaning that the for(;;) loop is would be exited with nothing written into sbuf
<rbasak> I'm still on udev-rules.c. Not dived deep into the changes in udev_event_apply_format yet.
<sladen> ddstreet: then finally  https://git.launchpad.net/~ddstreet/+git/systemd/tree/src/udev/udev-event.c?id=a135967a#n410
<sladen> ddstreet:
<sladen> oops
<ddstreet> sladen those break; commands don't break out of the for loop, they break out of the switch statement
<ddstreet> is that what you're talking about?
<sladen> ddstreet: correct
<ddstreet> sladen i'm not quite following where the bug happens?
<ddstreet> line 216, s = &sbuf, then it enters the switch(), then eventually exits the switch(), and restores s after replacing whitespace...
<ddstreet> the switch ends at line 399
<ddstreet> the if statement at line 402 is outside, after, the switch
<ddstreet> sladen is there something i'm missing?
<sladen> ddstreet: minimal example is  char sbuf[UTIL_PATH_SIZE]; s = &sbuf; switch(SUBST_RESULT) { case SUBST_RESULT: if (event->program_result == NULL) break; tmplen = util_replace_whitespace(sbuf, s, MIN(tmplen, l));
<nacc> smoser: right, we don't (can't in the current algorithm) go back and add history (e.g., upstream data) for already imported stuff
<nacc> smoser: that could be a reasonable feature, but the alternative, presuming no one is yet using your repository, is to delete and re-import
<ddstreet> sladen that util_replace_whitespace is called with length 0
<ddstreet> as tmplen will be 0 if sbuf isn't used
<smoser> nacc, so i did that
<smoser> why is there only one upstream/
<Henning_> I am planning to file an "upgrade-software-version" bug for xkeyboard-config and maybe freetype. But I am confused. xkeyboard-config has the string ubuntu1 at the end of the version string. So it's not automatically imported until DebianImportFreeze. So if I want to get the version bumped to the version that's in debian sid/unstable I have to file a bug with the tag "upgrade-software-version", probably at least two or three we
<nacc> smoser: which src package?
<smoser> https://git.launchpad.net/~usd-import-team/ubuntu/+source/cloud-utils/refs/tags?h=debian/jessie
<nacc> smoser: wait you deleted a branch or a repository?
<smoser> i deleted the lusd-import and then re-imported
<smoser> at least i thought i9 did.
<nacc> smoser: hrm, the newest objects in the repo are just 3 tags
<smoser> yeah, that is confusing
<smoser> i think i try again
<nacc> smoser: seems reasonable
<smoser> so i'm going to 'delete repository' at https://code.launchpad.net/~usd-import-team/ubuntu/+source/cloud-utils/+git/cloud-utils
<smoser> right ?
<smoser> nacc, hm... why do we not default to patches-applied?
<smoser> that was going to be my next question, "where are my patches-applied" branches
<smoser> then i see that it doesnt have them by default. i suspect due to possible failure of applying due to lack of a tool ?
<sladen> ddstreet: where is 'l' (saved to '_l') initialised?
<nacc> smoser: see the git commits
<rbasak> sladen: "l = size;"
<nacc> smoser: disabled becasue it doesn't always work (for certain src packages) and the importer can't fail (yet)
<nacc> smoser: you can pass --patches-applied
<ddstreet> sladen line 131
<ddstreet> sladen but if replace_ws, then l is set to UTIL_PATH_SIZE which is the size of sbuf
<smoser> nacc, yeah, but that wont be "sticky"
<rbasak> This code is horrible :-(
<ddstreet> then tmplen is UTIL_PATH_SIZE - l, so if the switch statement doesn't do anything tmplen is 0 and nothing is copied
<smoser> rbasak, you're in a friend-making mood :)
<nacc> smoser: that is true, but nothing is 'sticky' in the importer (there's no config stored in the repository)
<rbasak> It might as well be in assembly!
<ddstreet> rbasak i agree
<smoser> nacc, and thats fine... i'm just saying that i can do it , you're right, but then as the importer goes on i dont have it.
<rbasak> ddstreet: yeah, not your fault :)
<smoser> so its not terribly helpfu.
<smoser> i wonder if we could --patches-applied=attempt
<smoser> and that be the default
<nacc> smoser: this is mostly temporary while we wait for debian to tell me what policy they want for dgit
<smoser> and if it failed, then warn and skip
<rbasak> smoser: I hope that eventually --patches-applied will not break and be the default.
<nacc> smoser: for the cases where it fails
<rbasak> smoser: so in the meantime, it's just a feature flag awaiting feature specification finialization really.
<nacc> smoser: because we have to do something withe branch pointers
<rbasak> ddstreet: I think I'd have preferred you to have modified the destination in-place instead of temporarily redirecting everything else.
<rbasak> Though then I suppose that util_replace_whitespace couldn't be called directly. Hmm.
 * sladen just reading util_replace_whitespace()
<ddstreet> and util_replace_whitespace strips leading/trailing whitespace
<ddstreet> hmm i supppose util_replace_whitespace could operate on the same memory as src and dest...
<ddstreet> but that's a bit more clever than is safe for this code i think
<sladen> ddstreet: I (think) this code (probably) works.  It has taken 45 minutes to understand the implications of the patch.  The UTIL_PATH_SIZE - UTIL_PATH_SIZE == 0 step is quite fragile if another patch gets added later.  There may well be a much simpler way to implement it.
<rbasak> The entire switch statement should be in its own ******* function :-/
<ddstreet> rbasak +1000
<smoser> nacc, so you're saying you would not want --patches-applied right now if it always worked ?
<sladen> ddstreet: if it's purely a post-processing step, it should be possible to do it all at the end, with (probably) no additional variables being added before
<smoser> as in you're not sure if the implementation is right here ?
<rbasak> sladen: I appreciate your additional review. Thanks.
<ddstreet> sladen i'm not sure how it's fragile, it calculates the amount of chars added
<ddstreet> sladen what *really* should be done is for strpcpy() to return the number of chars copied, not the new length remaining!
<ddstreet> strpcpy is a function that udev didn't need to re-invent
<ddstreet> but i digress.  my patch was done with minimal changes to the existing code in udev, which is why it looks weird.
<ddstreet> udev's existing code is already weird.
<sladen> ddstreet: bool replace_whitespace, could probably be const to aid readability, and then could be referenced directly, which would be easier than the 'replws' abbreviation
<nacc> smoser: the implementation is correct. The need for the flag is temporary
<nacc> smoser: hopefully
<rbasak> ddstreet: to be fair, you could have refactored it in your upstream patchset.
<ddstreet> sladen it's not possible to do all at the end, because only the variable substitution whitespace should be removed - not any whitespace that was already in the string
<ddstreet> (that isn't my requirement, see the pull req for details)
<ddstreet> rbasak fixing strpcpy? it's used all over udev
<rbasak> ddstreet: the redirection around the switch statement is pretty hacky and fragile. Better to pull the switch into a separate function. Then you can give the switch statement different pointers.
<smoser> nacc, http://paste.ubuntu.com/23793031/
<rbasak> ddstreet: that would also ensure that nothing in the switch statement can reach out to other variables in the scope of udev_event_apply_format that might impact the redirection.
<smoser> that is what i'm suggesting, that way we get it imported for everything that *does* work, and for stuff that doesnt we warn rather htan fail
<ddstreet> rbasak yeah but i think a separate func is gonna need a lot of params passed in
<nacc> smoser: that will break those packages where it doesn't work
<smoser> ?
<nacc> smoser: in a way that is not fixable later
<smoser> i dont follow
<rbasak> ddstreet: perhaps, but I have to review each of those parameters individually for unintended interactions this way anyway.
<smoser> it will just not create those commits
<smoser> which is what you're doing now
<nacc> no, it will break the historical import algorithm
<nacc> for that series
<rbasak> ddstreet: to check the redirection for correctness, I have to know what other variables the contents of the switch reaches out to.
<smoser> how is that different than not doing it?
<ddstreet> rbasak sure i can create a new patch to pull that function out, but the upstream bug is already closed
<nacc> smoser: yes.
<rbasak> ddstreet: understood. This is a passing comment really. I haven't come to a conclusion with my SRU hat yet.
<nacc> smoser: because if it's not done, i can go back and 'catch-up' the applied branches
<nacc> smoser: if history is *wrong*, I can't.
<ddstreet> rbasak yep, i understand, i'll see what i can do upstream to pull the function out
<smoser> i'm missing something. if the patch application fails, you dont create the history, so its just as if you ran without patches-applied
<smoser> are you just saying that the commit_patches_applied has side affects ?
<smoser> nacc, ? what would be un-correctable ?
<smoser> i think you're suggesting that you could potentially import incorrect state and succeed. i'm not sure. if thats the concern then you can never be sure that running of tools provided the same code they did a decade ago.
<smoser> ie, samba's failure.  although, as i understand it , that was a fialure to apply the patch, and thus my suggestion would just go on.
<rbasak> ddstreet: I think you should use sizeof(x)/sizeof(x[0]) instead of UTIL_PATH_SIZE, etc. Again, maybe not important for this SRU.
<nacc> smoser: i don't understand what you mean by 'commit_patches_applied has side effects'? it creates/moves branch pointers
<ddstreet> rbasak yeah i thought of that, but was concerned if sbuf is changed from stack array to a * the sizeof would silently break
<smoser> nacc, it does that only if it succeeds to apply a patch
<rbasak> OTOH, if the size of sbuf is changed, then we'll silently break.
<nacc> smoser: no, i'm saying that if make patch-application non-fatal by default, which (you by default are doing), then historical patches-applied imports will 'succeed' but will not be imported anywhere (potentially)
<rbasak> IMHO, I'd expect someone changing a variable's type to check how something is used.
<rbasak> More so than the the length of an array.
<nacc> smoser: i think you misunderstand what your new 'commit_patches_applied' does
<nacc> smoser: it loops over the patches applying each
<nacc> smoser: that can fail anywhere in the queue
<smoser> nacc, right. so yeah,j it has side affects.
<smoser> we'd have to revert the branch
<smoser> which honestly woudl not be that hard
<smoser> just take the head before attempt and then reset it on fail
<smoser> right ?
<nacc> what do you do with the *next* one?
<nacc> this is not some trivial problem :)
<smoser> i dont know. i understand your point.
<nacc> smoser: as in, fine, you fail to apply patches, so you leave the current pointer at the prior
<nacc> but then FF branches get messy
<nacc> and you're dropping state without tagging or anything else
<smoser> FF ?
<nacc> fast-forward
<smoser> right, then the next version tries and succeeds
<nacc> and determining its 'parents' are where we're currently undecided
<nacc> and that decision is policy, so rather than fake it, i'm avoding the choice
<smoser> it really doesnt matter all that much.
<nacc> at some point, when we swtich the default for patched-applied, i'll switch the algorithm to also do historical applied-patches imports separate from unapplied
<smoser> you do lose some history in taht you dont have those in the middle, but it is history that could not be created.
<smoser> and woudlnt be used anyway
<smoser> really..
<smoser> because people are only really going to use the tip for applied branches
<smoser> well.. that might not be the case, but missing a historic commit doenst matter that much
<nacc> it breaks some of our assertions
<nacc> that every publish in launchpad is imported, e.g.
<nacc> smoser: i agree there are solutions out there for this problem. But they all imply a policy, which once done, needs to become stable and supported.
<nacc> smoser: if what you are asserting is true, then i would suggest a *better* choice is a usd sub-command (perhaps a checkout) which takes a series (+pocket?) and checks out the latest publish in that series (+pocket?) and applies the patches to it.
<nacc> smoser: the patches-applied state is always deriviable and if users don't care about history, let's not provide history
<nacc> smoser: but for dgit, they *do* care about history, and so we have to do the right thing in the importer
<smoser> nah. thats not what i was saying
<rbasak> ddstreet: how feasible would it be to add a test case for this particular bug?
<smoser> even in dgit
<smoser> they're only really primarily interested in the tip
<smoser> its for development, to make changes.
<smoser> if a historical point was unable to be created, that is what it is.
<smoser> same as if there was no download available for a thing in launchpad or something
<smoser> its less than perfect for sure and obnoxious, and i'd probably complain about it later
<smoser> :)
<nacc> heh
<nacc> note that a failure to find a download in launchpad is fatal to the importer
<smoser> right. the difference i see is only in that the next import would possibly succeed and then go stopmping on the history.
<smoser> in my suggested solution
<ddstreet> rbasak i can do that, there's a big test case perl script built into systemd/udev that's run on compile, i'll add some test cases
<smoser> nacc, if i wanted to pull in a new upstraeam release
<smoser> when working with this branch... ie, to upload.
<ddstreet> test/udev-test.pl
<smoser> what would you do to do that ?
<smoser> ie, i'm on ubuntu-devel
<smoser> and i want a new upstream tarball
<nacc> smoser: does uupdate/uscan work?
<nacc> note this might be the same question as the bug cyphermox filed :)
<nacc> smoser: LP: #1649940
<ubottu> Launchpad bug 1649940 in usd-importer "can't prepare new upstream releases using gbp" [Medium,New] https://launchpad.net/bugs/1649940
<nacc> that's one 'answer', in that we don't actually use the upstream data we have
<nacc> smoser: but if you have uupdate/uscan working, what i would suggest (and it's gross) is to do a uupdate/uscan, and then overwrite the working tree to be exactly what is in the new upstream
<smoser> nacc, yeah, that is basically what i was asking
<nacc> smoser: i think this is where we hit the bodge that is you asking for imported orig tarballs :)
<nacc> smoser: in that, we don't really import them -- they exist, but are off to the side
<smoser> nacc, so... this is what actually brought me here..
<nacc> heh
<smoser> i was tying to use the lpusp branch to do development on cloud-utils now
<smoser> my plan is to leave upstream in bzr for now
<smoser> and do the usd for working with git
<nacc> right
<smoser> but then wanted to upll in a new 0.30 that is really the same as what was in ubuntu due to the applied patches
<smoser> but i wanted git to tell me that
<smoser> and so i wanted to diff against lpusip/applied/0.27-0ubuntu9
<smoser> to see that that was the case
<nacc> and that didn't exist
<smoser> yeah.
<smoser> so that is a non-dgit use of the applied branches
<nacc> right
<nacc> but my prior point of a catch-up mode for the applied branches would have solved your problem
<smoser> correct
<nacc> smoser: i can probably get that coded up today, honestly -- we'll need it anyways at some point, probably
<nacc> that allows us to continue using the current importer for now and then we can catchup all the repos at some point, change the default on the flag, and then restart the importer with patches-applied?
<smoser> sure. one other thing you coulddo....
<smoser> so, i'm concerned that reality will be that we never get to the point that we have these applied branches
<smoser> because discussion or whatever policy will drag on and on
<smoser> for now we could do as i suggested, and then correctly reset the branch to the last good state.
<smoser> and then add a commit "APPLIED_PATCHES_FAILED"
<smoser> and then if that was ever seen, dont go on.
<nacc> LP: #1649832
<ubottu> Launchpad bug 1649832 in usd-importer "Problems in applied patches imports cause import failures which are not ignored" [Wishlist,Confirmed] https://launchpad.net/bugs/1649832
<nacc> smoser: --^
<barry> stgraber: re-ping
<smoser> is eatmydata broken ?
<smoser> $ grep LD_LIBRARY_PATH /usr/bin/eatmydata
<smoser>    LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+"$LD_LIBRARY_PATH:"}/usr/lib/libeatmydata
<smoser>    export LD_LIBRARY_PATH LD_PRELOAD
<smoser> $ ls -l /usr/lib/libeatmydata
<smoser> ls: cannot access '/usr/lib/libeatmydata': No such file or directory
<stgraber> barry: hey there, sorry, in South Africa this week so not the most compatible timezone
<stgraber> barry: so that's running inside a LXC container and is attempting to mknod /dev/mapper/control. If the container is unprivileged, then that sure won't be allowed by the kernel. If the kernel is privileged, then it'd depend on the lxc.cgroup.devices configuration.
<stgraber> barry: I'm not aware of any change we made that would explain a change in behavior there, so a change in the adt container configuration seems more likely to be. Or something was at /dev/mapper/control before which has since disappeared and triggers the mknod?
<barry> stgraber: is that something that changed recently?  i'm fairly positive that worked original in ubuntu-image dated 10-oct
<barry> stgraber: yeah, *something* has changed, just not sure what.  do you know, does autopkgtest.u.c run priv'd or unpriv'd containers?
<stgraber> barry: I don't know about our adt test environment's config. We haven't changed anything on our side that'd explain that. mknod has always failed in unprivileged containers and always succeeded or failed in privileged containers based on lxc.cgroup.devices config
<stgraber> barry: no idea
<stgraber> barry: and unfortunately autopkgtest doesn't log what it used to create the lxd container (like it does for nova)
<barry> stgraber: let me poke around in the apt source and see if i can find something, otherwise i'll email ubuntu-devel@ and see if anybody else has an idea.  thanks, this is starting to narrow it down
<stgraber> barry: note that devmapper itself isn't namespaced, so if the adt container is allowed to interact with it, you may well conflict with another container and run into surprises
<barry> stgraber: i wonder if the apt infra used to run priv'd containers and now runs unpriv'd containers?
<barry> stgraber: that's good to know.  maybe the right answer is to skip the mount test if `dmsetup ls` fails.  i should at least set isolation-machine restriction in d/tests/control for that test
<barry> that might do it in a more principled way
<stgraber> barry: I know that the lxc adt backend was using privileged containers with barely any security restriction applied to the container. I suspect the lxd adt backend attempts to be somewhat more secure and may run unprivileged.
<cjwatson> It certainly can run unprivilege.
<cjwatson> d
<cjwatson> I forget whether it does in production.
<barry> cjwatson: maybe Laney knows if he's still online
<stgraber> barry: yeah and if you set isolation-machine for that test, then adt will just skip it for you when running on lxc/lxd
<cjwatson> But it's what adt-build-lxd(1) and adt-virt-lxd(1) will set up unless you muck about.
<barry> stgraber: given that devmapper isn't namespaced, that's probably the right thing to do anyway, even if it doesn't explain what's changed
<barry> cjwatson: ack
<barry> ok, testing and if it works, yay!  but i may still send the email cause i'm still curious
<barry> cjwatson, stgraber: oh, but isolation-machine will prevent the test from running on amd64 too, so then i'm not so sure what the use of the test is ;/
<cjwatson> Yeah, dunno, my use of lxd is (a) openssh autopkgtests and (b) Launchpad/OLS stuff at the moment :-)
<barry> :D
<stgraber> barry: no it won't
 * stgraber triple checks
<stgraber> barry: right, isolation-machine is satisfied by VMs
<stgraber> barry: we set it for the lxc/lxd/lxcfs/... packages and we do see our tests running on everything but armhf and s390x
<barry> stgraber: then a test that kpartx's and mounts the partitions in a built image is never going to be *safely* tested on current apt infra.  would you agree?
<stgraber> barry: ? I'm saying that if you set isolation-machine, your test will run on amd64, i386 and ppc64el
<barry> stgraber: oh, yes, i see what you're saying.
<barry> stgraber: unfortunately, i usually use schroot for local tests because qemu and until recently lxd wasn't working locally for me.  qemu still doesn't for some reason (a crash in kvm.c iirc)
<xnox> barry, there is isolation-vm and isolation-container too i think
<xnox> to be more specific than just "machine"
<barry> xnox: isolation-container yes, that's to isolate services and tcp ports.  isolation-machine looks to be more appropriate for kernel interactions (e.g. devmapper).  no isolation-vm restriction that i can see
<nacc> smoser: still around?
#ubuntu-devel 2017-01-14
<nacc> smoser: i'm not sure i'll be able to solve your original request by the EOD :/
<nacc> smoser: only because there is a trick to the algorithm right now that i need to think of how to efficiently solve
<nacc> smoser: we could either a) disconnect hte applied and unapplied branches (very fast and very easy) going forward
<nacc> this is what i think slangasek technically wants for his own sake -_^
<nacc> err, --^, no emoticon intened
<nacc> or b) we'd have to investigate adding an algorithm that can walk a branch backwards (git rev-list) until it found a treeish that matches the unapplied version of the patches-applied we are about to import, and then use that as the unapplied parent
<nacc> that will be *very* slow to do every time, though
<nacc> rbasak: --^ i'm not sure how else to do 'fixup's of repositories where --patches-applied may or may not be passed
<smoser> nacc, here now. i'm guessing you're not.
<sarnold> seven seconds, what timing :)
<xnox> infinity, was libc kernel version requirement bumped in xenial-updates? i get a debconf notice that 3.2 kernel is now required
<xnox> (note I'm on a container OpenVZ bs or some such)
<xnox> i guess nothing was changed, it's just the first time i'm upgrading libc.
<Mirv> anyone has ideas on the python scandir problem at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/y/yade/20170114_125802_e636e@/log.gz ? I can't see how it could be pyqt5 change related, but yet http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pyqt5
<Mirv> kind of guessing it would be related to some other python related recent upload, but zesty-changes doesn't enlighten me - nothing from stacktrace like ipython, pathlib there
<ScottK> Mirv: What package provides scandir?
<ScottK> Mirv: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711388
<ubottu> Debian bug 711388 in wnpp "ITP: scandir -- Better directory iterator that" [Wishlist,Open]
<ScottK> Mirv: python-pathlib2 needs it and python-ipython depends on python-pathlib2.
<ScottK> Which is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851137
<ubottu> Debian bug 851137 in python-pathlib2 "Requires a dependency on missing 'scandir' module" [Grave,Open]
<ScottK> Mirv: Syncing 2.2.0+really2.1.0-1 when it's available should solve that.
#ubuntu-devel 2017-01-15
<Mirv> ScottK: thanks for the find! I was also puzzled where the scandir would be - it turns out it's nowhere.
<Mirv> and I was looking at only src:python-pathlib, not 2
<infinity> xnox: Indeed, nothing has changed, it's always required 3.2 on xenial.
<infinity> xnox: It's a miracle if it's working.
<infinity> xnox: Oh.  Except I have it set to 2.6.32 on x86, specifically for briandead OpenVZ.  So the preinst is lying.
<infinity> xnox: Bother.
<infinity> xnox: Err, nevermind.  I see what aurelien did here, and I support him 100%. :P
<infinity> xnox: It didn't bomb out, right, it just told you that it might suck?
<infinity> xnox: For versions between 2.6.32 and 3.2, we tell you that you're pretty much doing things at your own risk.  3.2 and up is supported.  Less than 2.6.32 and we'll refuse to work at all.
<Mirv> I think we have transition completion happening!
<Mirv> the downside is that I broke my promise to try to relax on the weekend
<acheronuk> Mirv: great :)
<acheronuk> + you can relax better later knowing Qt has moved ;)
<Mirv> yeah, that's the plus side :)
<acheronuk> Mirv: and this zesty box now sees the new Qt in release and can upgrade
<mwhudson> is anyone planning to do a /usr merge for ubuntu?
<jbicha> mwhudson: did you see the first bullet point at https://lists.debian.org/debian-devel-announce/2017/01/msg00004.html
<mwhudson> jbicha: oh heh, no i didn not
<jbicha> that doesn't directly answer your question but Debian is hesitating a bit
<mwhudson> jbicha: it is super related to what i am actually doing though
<mwhudson> the /usr merge breaks snapd on debian (if apparmor is enabled)
<mwhudson> or at least that's what this bug report says
<Son_Goku> mwhudson, really? why?
<Son_Goku> SUSE has UsrMerge with AppArmor and it's fine
<Son_Goku> is there that great of a policy difference?
<mwhudson> Son_Goku: and snapd works there?
<mwhudson> i don't know, i'm just saying what the bug report says :)
<Son_Goku> well, in both SUSE and Arch, when we manually swap the kernel with Ubuntu ones, it's fine
<mwhudson> hm
<mwhudson> it may be something about the apparmor in debian's kernel i guess
<Son_Goku> as much as I don't like AppArmor, I really doubt it's AppArmor's fault
<Son_Goku> I know that snapd does not work on Debian AppArmor because the AppArmor in upstream kernels does not match what snapd expects
<Son_Goku> it does not work in SUSE either
<Son_Goku> unfortunately, I've not seen much progress on the Ubuntu AppArmor team in upstreaming their changes to the mainline kernels that all other distros use
<Son_Goku> mwhudson, if anything, it's most likely a break in Ubuntu's contributed AppArmor profiles
<Son_Goku> despite Ubuntu having thought about doing UsrMerge years ago, I doubt anyone really thought about it when the profiles were being written and upstreamed into Debian
<mbiebl> you have to update the  individual apparmor profiles to support a merged usr system
<mbiebl> I assume suse has done that
<Son_Goku> they did it a long time ago, yes
<mbiebl> bugs.debian.org/846966 is such an example
<Son_Goku> and Arch's AppArmor profiles are derived from SUSE's
<Son_Goku> and if Mageia decides to implement AppArmor, I will be importing SUSE's profiles
<Son_Goku> just like I import Fedora's for SELinux
<Son_Goku> I don't know if you guys talk to the SUSE security team, but you might want to get in touch with them about synchronizing work on the profiles
<Son_Goku> mbiebl: I'm disappointed that the latest release of d-i disabled usrmerge by default :(
<Son_Goku> I was really looking forward to default usrmerge
<mbiebl> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843073 was the reason why it was reverted
<ubottu> Debian bug 843073 in dpkg-dev "dpkg-shlibdeps: broken on i386 with merged /usr" [Important,Fixed]
<Son_Goku> but it's fixed...?
<Son_Goku> so if it's fixed, it can be unreverted?
#ubuntu-devel 2018-01-08
<cpaelzer> Is there a process in place to whitelist ppa's and/or proposed builds while the maintenance is going on?
<hloeung> cpaelzer: speak to wgrant and/or cjwatson
<rbasak> I filed https://bugs.launchpad.net/bugs/1579695 a while ago, but I think there might be a similar/duplicate bug on this too. Does anyone know anything about it?
<ubottu> Launchpad bug 1579695 in systemd (Ubuntu) "apport hook does not show the status of failed services" [Undecided,New]
<rbasak> We're looking at trying to make the UX better for the gazillion MySQL/MariaDB maintainer script failures we get reported.
<rbasak> We also noticed that "systemctl start <service>" doesn't seem to complain on service start failure and exits zero.
<rbasak> On otto_'s 17.04 system at least.
<rbasak> Which surprises me.
<xnox> lolz
<xnox> rbasak, you do know, that I am a PostgreSQL person =) and come from an ex-PortgreSQL consultancy =)
<xnox> most of my MySQL experience is from .... migration to PostgreSQL =)
<xnox> for all the things
<rbasak> Don't worry about the MySQL-specific bits :)
<otto_> here: https://paste.debian.net/1003968/
<otto_> I mangled the cups service to start my custom failing script test.sh
<rbasak> If you fancy fixing bug 1579695 then that's definitely nothing to do with MySQL specifically :)
<ubottu> bug 1579695 in systemd (Ubuntu) "apport hook does not show the status of failed services" [Undecided,New] https://launchpad.net/bugs/1579695
<otto_> service fails to start now bud systemctl start does not complain anything
<xnox> otto_, you seem to be mistaken, in thinking that `systemctl start` reports success of starting the service. It reports the sucess of talking to private systemd socket, and submitting a job to systemd. Such that e.g. systemctl list-jobs -> shows that mysql is starting, and later fails to start.
 * xnox welcomes otto_ to my world
<xnox> you can catch list-jobs stuff, if you crank systemd debugging and watch journal.
<xnox> or like have a /bin/sleep infinity as an ExecStartPre= and check systemctl list-jobs
<rbasak> How does invoke-rc.d detect service start failure?
<xnox> rbasak, good question.
<xnox> rbasak, note that we do not use invoke-rc.d in package maintainer scripts.
<xnox> rbasak, is mysql stuff native units or init.d scripts autogenerated into systemd units and then managed by systemd?
<xnox> i believe invoke-rc.d invokes systemctl, and tells lies.
<xnox> so systemctl start does report some failures - e.g. if that new unit does not exist, or is conflicting, or doesn't mean start conditions -> all that will fail to submit the job, and thus such invocations should report failures from systemctl start
<rbasak> "note that we do not use invoke-rc.d in package maintainer scripts"
<otto_> traditional init scripts wait for the process to come up and yield and exit code. servicectl apparenlty does not wait for the service to come up
<rbasak> I thought we did? Or is that different with dh_installinit or dh_systemd or whatever it is?
<xnox> rbasak, yes, that.
<rbasak> mysql-server-5.7.postinst is currently using invoke-rc.d, but we're planning to move away from that.
<cjwatson> To be fair systemctl(1) says "If [--no-block] is not specified, the job will be verified, enqueued and systemctl will wait until the unit's start-up is completed."
<xnox> true.
<cjwatson> which seems to disagree with observed behaviour here
<xnox> but for simple ExecStart the mere exec is successful start, unless there is pid / notify / dbus stanzas.
<xnox> arguably it should not be....
<rbasak> We did use invoke-rc.d because we needed to start the server temporarily for schema updates, but we're planning to change that to fix bug 1592669
<ubottu> bug 1592669 in mysql-5.7 (Ubuntu) "postinst fails when daemon is not running (or is disabled by policy-rc.d)" [High,In progress] https://launchpad.net/bugs/1592669
<cjwatson> ah yeah of course
<otto_> maybe cups is just a bad example to test this as the .service file is so simple
 * xnox observes that mysql-5.7 debian/ is 963k
<rbasak> po is 224k
<rbasak> changelog 240k
<rbasak> copyright 32k
<rbasak> Welcome to my world :)
<xnox> rbasak, looking at the service file..... there is no notifications w.r.t. when the service is ready
<xnox> rbasak, is there no systemd notify mysqld api?
<Skuggen> xnox: Not currently. We use forking upstream (running mysqld with --daemonize)
<rbasak> Not currently. I'm told (by Lars, sitting opposite) that currently forking is the only type
<rbasak> Right :)
<rbasak> But looks like we're using plain ExecStart at the moment.
<xnox> Skuggen, i like upstream.
<xnox> rbasak, i think we should fix our service file to be better and inlcude --daemonize and Type=forking and the PIDFile stanza
<xnox> as per https://mysqlserverteam.com/mysql-5-7-native-systemd-support/
<xnox> all of that looks sane
<xnox> and missing in our units.
<rbasak> Sounds like a task for Skuggen this week :)
<xnox> at the very least; --daemonize; type=forking; PIDFile stanza (ideally /run, not /var/run ;-))
<Skuggen> One of the issues we have with forking upstream is that we use RestartPreventExitStatus=1, and that doesn't seem to work
 * xnox yells /var/run is dead, long live /run
<rbasak> Actually /run is short-lived :-P
<xnox> Skuggen, if that does not work, please open a bug against systemd and give me an example and the bug number i can look into fixing that.
<xnox> rbasak, har har har har
<Skuggen> xnox: Will do
<Skuggen> Does anyone know how debconf prompt priorities are affected by doing a release upgrade (if at all)?
<Skuggen> e.g. does it only show critical?
<jamespage> Skuggen, rbasak: how long are you all working out of London for? the whole of the week?
<rbasak> jamespage: yes, whole week. Maybe early finish on Friday depending on Otto's and Lars' travel plans
<didrocks> slangasek: FYI: https://bugs.launchpad.net/ubuntu/+source/gnome-characters/+bug/1713176/comments/6
<ubottu> Launchpad bug 1713176 in gnome-characters (Ubuntu) "[MIR] gnome-characters" [Undecided,Incomplete]
<slangasek> didrocks: the expected subscriber for MIRs is desktop-packages
<slangasek> if this is supposed to be a desktop package, I can add that subscription
<didrocks> slangasek: maybe I'm wrong but I thought we were using ubuntu desktop bugs now
<slangasek> didrocks: I heard someone express a preference for this, but no one has migrated the subscriptions to ubuntu desktop bugs for all the packages in main that desktop team is responsible for, and the tooling hasn't been updated to track that team
<slangasek> didrocks: we're not going to just switch it and have an increase in the 'unsubscribed' count on http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html
<didrocks> slangasek: just note that some are probably wrong (like gdm3)
<didrocks> but yeah, we should put some consistency over it
<didrocks> I think subscribing desktop-packages for now is fine
#ubuntu-devel 2018-01-09
<hallyn> jjohansen1: stgraber: if i'm running an artful container on an artful host with aa namespaces, i should be able to load the lxc policies right?
<hallyn> bc /lib/apparmor/profile-load skips that part when running in a container
<hallyn> aa-status shows 0 policies
<hallyn> and i'mw ondering whether that's expected
<stgraber> you should be, yes, do you have the apparmor namespace and stacking setup?
<stgraber> is that lxd or lxc?
<hallyn> lxd
<hallyn> hm, is my lxd way out of date?
<hallyn> 2.18
<stgraber> that should be fine
<hallyn> but that shouldn't matter
<hallyn> it's lxc in the container,
<hallyn> and that's built from the source in ubuntu-lxc ppa
<hallyn> oh, but that's not the problem either :)
<stgraber> hallyn: what's /proc/<PID>/atttr/current for pid1 of the lxd container?
<hallyn> /lib/apparmor/profile-load is the probem
<hallyn> when I edit /lib/apparmor/profile-load to remove the contaienr check, then policies load
<stgraber> hallyn: hmm, you're right that something's off with artful...
<hallyn> lxd-alxc1_</var/lib/lxd>//&:lxd-alxc1_<var-lib-lxd>:unconfined (enforce)
<stgraber> hallyn: no apparmor profiles loaded in there...
<stgraber> hallyn: does a xenial container work?
<hallyn> is that a case where artful is behind zesty
<hallyn> uh, i'll check
<hallyn> aa-status shows 0 policies there as well
<stgraber> yeah, same here
<stgraber> wth is going on
<stgraber> we used to be getting profiles loading at some point
<hallyn> nothing obvious in changelog
<hallyn> i'm surprised no testcase barfed, if this is a regression
<hallyn> what is is_container_with_internal_policy
<stgraber> yeah, me too. I'm pretty sure I used to run into issues with tcpdump in containers, which meant that the tcpdump profile was loaded back then
<stgraber> hallyn: hmm, I have another xenial system where I do have apparmor profiles loaded properly
<hallyn> i'm guess /lib/apparmor/functions:is_container_with_internal_policy() regressed
<hallyn> or rather, maybe apparmorfs in kernel regressed wrt to it
<stgraber> yeah, that's what I'm wondering, I seem to remember us having pretty advanced logic not to trigger on kernels that shipped busted apparmor nesting
<stgraber> I wonder if newer kernels changed that part and now we're not triggering when we should
<hallyn> /sys/kernel/security/apparmor/.ns_name is empty
<hallyn> that i believe is the problem,
<hallyn> it expects to find the policy name in there
<stgraber> stgraber@shell01:~$ cat /sys/kernel/security/apparmor/.ns_name
<stgraber> lxd-shell01_<var-snap-lxd-common-lxd>
<stgraber> on xenial 4.4 kernel
<stgraber> and confirmed to be an empty string in bionic
<stgraber> so yeah, that's the issue
<stgraber> jjohansen1: ^
<hallyn> dude!   stgraber: this is the first time i saw 'bionic' and realized you mean the release, not the android libc
<hallyn> every single time someone has said "<...> bionic" i thought "why do they care so much about bionic now?"
<stgraber> :)
<stgraber> empty string rather than expected value would be something that bionic the C library would do too though ;)
<hallyn> *sigh* so now..  i don't really wanna reinstall the lxd hosts with xenial just for this, wonder what the easiest short term remedy is :)
<hallyn> heh :)
<stgraber> installing the xenial 4.4 kernel on that host should work fine
<stgraber> regardless of what the Ubuntu version on it actually is :)
<hallyn> yeah - that's probably easiest.
<hallyn> ok, thanks for the debug help :)  \o   (/me goes to sneak another girardelli chocolata)
<jjohansen1> stgraber: yeah, bionic is a mess that I need to fix
<stgraber> jjohansen1: hallyn was reporting this on artful though, is that known to be broken too?
<jjohansen1> stgraber: no, I'll look into it
<hallyn> cool, thanks guys.
<rbasak> xnox: fancy tackling bug 1579695 for us? :)
<ubottu> bug 1579695 in systemd (Ubuntu) "apport hook does not show the status of failed services" [Undecided,New] https://launchpad.net/bugs/1579695
<xnox> rbasak, i will add it to the team backlog.
<rbasak> Thanks!
<andyrock> bdmurray: hey I need some help reviewing a software-properties MP
<andyrock> https://code.launchpad.net/~azzar1/software-properties/canonical-livepatch/+merge/335219
<Zahovay> Hello, I am a new programmer just about to join the ubuntu development team, may I ask here a few things? or this is not the chat room
<sil2100> Zahovay: sure, ask away
<Zahovay> sil2100: I was told that ubuntu makes no changes to the kernel. Other said they do make changes. I was wondering if laptop-mode-tools still exist and what is the purpose of that tools. Does it makes changes to the kernel? is it a laptop package of ubuntu?
<sil2100> Zahovay: from what I see laptop-mode-tools still exists but it's in universe, so I don't have much knowledge about that tool - maybe someone else here would know
<sil2100> Zahovay: as for the kernel, Ubuntu mostly ships what's upstream + some patches, so it's not completely vanilla
<sil2100> You can check what Ubuntu changes are put on top of the kernel tree by fetching the Ubuntu linux source packages
<Zahovay> Yes I know that it ships the upstream mainly, thou I think the upstream does not have a laptop specific project..
<Zahovay> sil2100: do you happen to know who would be able to help me on this topic?
<TJ-> sil2100: Zahovay told us yesterday in #ubuntu they want to get involved in improving power management on laptops. Had a long conversation with nacc and myself about it. We recommended finding a bug and working on it.
<sil2100> I guess the best people to ask about this would be the kernel guys, but they're all *very* busy because of obvious reasons
<sil2100> So I'd recommend just writing questions here and waiting for someone with the right knowledge set to see it and answer in his free time
<Zahovay> Actually I think I need to find someone who manages the projects of ubuntu, since he can answer the question whether ubuntu plans laptop package or do not want to deal with that at all since the basics still have some troubles
<rbasak> Ubuntu isn't developed that way.
<rbasak> Nobody "manages" projects of Ubuntu.
<TJ-> Zahovay: power control is mainly around the ACPI sub-system and is done in the mainline kernel
<rbasak> Most of the time projects don't clash with each other. If you want to work on making power management better, you're welcome to do so.
<TJ-> Zahovay: power management tools for adjusting power profiles are done mostly by desktop tooling in userspace
<rbasak> In the rare case that there's some potential downside to your work and a decision needs to be made about the default, then we resolve that by speaking to each other, or deferring to the technical board if we cannot reach consensus.
<Zahovay> Still I think the power management for desktops makes no sense since you have unlimited power. So I would only apply changes for laptops which means I should have a different package, shoudnt I?
<rbasak> We try to not distinguish between the two.
<rbasak> For example, what happens if I dock my laptop? :)
<rbasak> Better to adjust power management behaviour based on power status, which I think tools already do?
<Zahovay> well I think we could kill processes for laptops that do not need to run all the time. This is actually a kernel level implementation of longer battery life. Also hibernation on laptops differ from desktop hibernation (atleast I think, I may be wrong) am I wrong about these?
<TJ-> Yes, and most DEs have power profile configuration for AC vs Battery too
<TJ-> Zahovay: kill processes? that doesn't sound very user friendly. User's should choose to terminate processes if that is really necessary
<TJ-> Zahovay: hibernation is identical; a swap partition or file large enough to store the RAM content
<Zahovay> So what is the cause of shorter battery life on ubuntu compared to .. so called windows/macos ? as far as I read ubuntu misses power management implementations thats why forums suggets powertop. Are they wrong about it? or has it changed and I am out of date on this topic?
<Zahovay> or is it hardware related problem?
<TJ-> Zahovay: Sometimes it is related to the system firmware ACPI DSDT implementation. It is responsible for configuring devices and managing power. Many firmware's are tailored to Windows and do not activate all features when Linux is the OS.
<Zahovay> TJ-: can we help this, or is it hardware manufacturers decision?
<TJ-> Zahovay: there are always ways to hack around restrictions
<Zahovay> I mean in a legal form
<jibel> bdmurray, do you have the upgrade logs of the upgrade to bionic you mention in bug 1512322 ?
<ubottu> bug 1512322 in dpkg (Ubuntu) "dpkg assert failure: dpkg: ../../src/packages.c:245: process_queue:" [High,Confirmed] https://launchpad.net/bugs/1512322
<jibel> bdmurray, I added a test case to bug 1742147
<ubottu> bug 1742147 in ubuntu-release-upgrader (Ubuntu) "upgrade from 17.10 to 18.04 fails with triggers looping" [High,Confirmed] https://launchpad.net/bugs/1742147
<bdmurray> jibel: I added some more log info to bug 1512322
<ubottu> bug 1512322 in dpkg (Ubuntu) "dpkg assert failure: dpkg: ../../src/packages.c:245: process_queue:" [High,Confirmed] https://launchpad.net/bugs/1512322
<bdmurray> jibel: ah, that bug is helpful thanks
<jibel> bdmurray, I'm trying to narrow down the packages involved but it seems the 3 additional pacakges are required to trigger the bug
#ubuntu-devel 2018-01-10
<Sargun> Is Bionic going to get Systemd v236?
<infinity> Sargun: Almost certainly.
<sarnold> hey infinity :D
<tsimonq2> Oh hey infinity :D
<JackFrost> sarnold: Heh, what's up?
<sarnold> JackFrost: my pandaboard (irc host) kicked the bucket .. so this is me trying to get a five-year-old configuration updated
<sarnold> JackFrost: .. and of course I can't remember how to run irssi well enough to make changes live, so I edit the config and restart.
<JackFrost> Ouch...  Mainly just saw 'sigh I hate irssi'
<JackFrost> 1. They prefer you use commands as editing config is very picky.  2. /reload
<sarnold> if you looked up "technical debt" you'll surely see a screenshot of my irssi configuration.
<sarnold> no kidding
<sarnold> I've screwed that up before too :)
<sarnold> but I don't know how to change the port of a network on the fly. heh.
<Odd_Bloke> sarnold: Take this opportunity to move to weechat.
<JackFrost> /SERVER MODIFY -network Freenode -port 6697
<JackFrost> Likely needs the server name, buuut. PD
<sarnold> JackFrost: heh, I thought /server was deprecated a decade back
<sarnold> Odd_Bloke: you know, a teeny tiny small part of me wanted it busted bad enough that I'd have to
<JackFrost> sarnold: You don't use /server to connect to a new network, just /connect for that.  But you do use it to add/modify/delete.
<Odd_Bloke> sarnold: KSSHT FFT SORRY WHAT WAS THAT KSSHT YOUR IRC CLIENT MUST BE MALFUNCFUNCFUNC BAD ENOUGH TO USE WEWEWEE-KSHHT-CHAT
<sarnold> Odd_Bloke: rofl
<JackFrost> I don't think I could break irssi enough to switch to weechat. :>
<sarnold> JackFrost: this is part of the problem :D  I used to use /server for those kinds of things but then they added /network to manage networks separate from servers and then *years happened* and now I'm hopeless.
<JackFrost> Ah yes, I'm a much more recent convert to Irssi.  Sometime in 2010 or 2011.
<JackFrost> ...Which isn't exactly recent anymore, but is in IRC time!
<Odd_Bloke> I can't remember when I started using irssi, but that really only means it was more than two weeks ago.
<sarnold> the conversion from bitchx didn't go painlessly. but it was worth it.
<JackFrost> I uh...Converted from finch. >_>
<sarnold> the conversion *to* bitchx didn't go painlessly either, but that too was worth it.
<sarnold> heh, I can kinda see how you might have used finch .. and why you'd move :)
<JackFrost> Yeah seriously, pidgin â finch â irssi. >_>
<sarnold> anyway, dinner time ;) thanks
<tsimonq2> I was straight from Pidgin to Irssi very quickly and haven't looked back :D
<tsimonq2> o/ sarnold
<JackFrost> Eat well, sarnold.
<sarnold> :D
<valorie> konversation is <3
<JackFrost> tsimonq2: finch is ncurses pidgin, fyi.
<tsimonq2> valorie: I bet you use KMail too ;)
 * tsimonq2 runs
<valorie> worse
<valorie> gmail
<tsimonq2> JackFrost: Ahh ok, this is the first time I've heard of it
<valorie> on the web
<tsimonq2> valorie: There is nothing worse than KMail >_>
<valorie> rofl
<Odd_Bloke> What is this, #kubuntu-devel? ;)
<tsimonq2> hahahaha
<valorie> used to be my favorite KDE application
<valorie> before I discovered IRC
<valorie> Odd_Bloke: you too can use konvi!
<valorie> 'tis in the Archive
<Odd_Bloke> valorie: Given the way I use my desktop, I'm not sure I'd notice if I switched to KDE.  You know, once I'd learned the shortcut to type in a command, and the name of the KDE terminal program. :p
<tsimonq2> Odd_Bloke: orrrr you could just install QTerminal ;)
<valorie> yakuake!
<valorie> just f12 and you're there
<JackFrost> ...Dinner at 10pm?
<valorie> in Spain, that's how they do it
<valorie> finding dinner before 8 is nearly impossible
<TJ-> Would you consider it a bug if, with root FS on LVM, having done an "lvrename VG LV LV_new", update-grub has no way to figure out the new name (since /proc/mounts doesn't update).
<tkamppeter> xnox, slangasek, hi
<jbicha> doko: can we demote idle to universe? I think it's the only thing keeping tcl and tk in main
<doko> jbicha: hmm, it's the only supported Python IDE. Is there a request to demote Tcl/Tk?
<jbicha> yes, I'm requesting it ;)
<jbicha> why do we need a supported Python IDE in main? where's the supported IDE for every other programming language?
<jbicha> I think most Ubuntu developers use something other than idle when writing Python code
<tkamppeter> xnox, slangasek, can you have a look at bug 1721839? It is a severe regression which we should not have in LTS and upstream is not answering.
<ubottu> bug 1721839 in systemd (Ubuntu) "[REGRESSION] Services asked for by UDEV do not get triggered" [Critical,Confirmed] https://launchpad.net/bugs/1721839
<jbicha> doko: one more reason is mentioned at LP: #1740926, it looks like we would need to have tk8.6 recommend "gnome-terminal | xterm" in order to demote xterm to universe
<ubottu> Launchpad bug 1740926 in ubuntu-meta (Ubuntu) "Demote gitk to universe" [Undecided,New] https://launchpad.net/bugs/1740926
<doko> jbicha: hmm, that might be a request from edubuntu at some time ...
<jbicha> doko: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.bionic/revision/404
<doko> blame the comitter for not giving a rationale ...
<jbicha> Wikipedia says Ubuntu Education Edition had its first release shortly after that, so your theory might be right
<doko> ogra: what's the status of edubuntu?
<jbicha> https://lists.ubuntu.com/archives/ubuntu-devel/2016-March/039281.html
<jbicha> but Edubuntu included universe anyway in recent releases
<ginggs> doko: https://lists.ubuntu.com/archives/ubuntu-devel/2016-March/039281.html
<ginggs> woops jbicha already did that
<ogra> doqdead since 14.04 i think ( i havent touched it since 2012, better ask the edubuntu-council)
<ogra> doko, ^^
#ubuntu-devel 2018-01-11
<joelkraehemann> hi all
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer
<joelkraehemann> ^^ does proposed mean, it is going to be synced?
* wgrant changed the topic of #ubuntu-devel to: Launchpad build farm capacity limited, and non-x86 builds suspended | Artful Released + taken down LP#1734147 | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<ginggs> joelkraehemann: has been auto-sync'd, not yet built though
<joelkraehemann> ginggs: thank you.
<joelkraehemann> I can strongly recommend this version
<joelkraehemann> since it brings some real improvements
<TDO|Aquina> Hello! I saw linux-generic linux-headers-generic linux-image-generic linux-tools-generic with linux-meta (3.13.0.139.148) trusty; urgency=medium // * Bump ABI 3.13.0-139. Ubuntu wesite tells me https://launchpad.net/ubuntu/+source/linux/3.13.0-139.188 its KAISER / KPTI patches for Linux.
<TDO|Aquina> My question is the sage as stated in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1741609/comments/4
<ubottu> Launchpad bug 1741609 in Kernel SRU Workflow security-signoff "linux: 3.13.0-139.188 -proposed tracker" [Medium,Fix released]
<TDO|Aquina> Can someone please tell me if thats feasible?
<TDO|Aquina> Ah I found an answer to the KAISER problem (https://askubuntu.com/questions/991874/how-to-disable-page-table-isolation-to-regain-performance-lost-due-to-intel-cpu). Thanks anyways! :-)
<seb128> rbalint, hey, is https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1663157 still on your list? we would like to re-enable guest session for the LTS but the apparmor/systemd user issue needs to be sorted out ... and it seems Steve pinged you about that? (it has been a while though so not sure if that's still current)
<ubottu> Launchpad bug 1663157 in Light Display Manager "Guest session processes are not confined in 16.10 and newer releases" [Undecided,New]
<bdrung_work> slangasek, will you merge klbic from Debian unstable?
<rbalint> seb128: it is still on my list but had higher priority issues :-(
<seb128> rbalint, ok, and do you have any idea if/when you might get to that item?
<cjwatson> seb128: speaking of still on people's list, I made some progress on debconf gtk3; just trying to sort out some complexity regarding the startup sequence
<cjwatson> it mostly works but is producing weird warnings at the moment, so I want to clear that up
<tkamppeter> xnox, slangasek, can you have a look at bug 1721839? It is a severe regression which we should not have in LTS and upstream is not answering.
<ubottu> bug 1721839 in systemd (Ubuntu) "[REGRESSION] Services asked for by UDEV do not get triggered" [Critical,Confirmed] https://launchpad.net/bugs/1721839
<rbalint> seb128: i need to discuss that with slangasek, we did not talk about that recently
<rbalint> seb128: but i agree that we should enable it
<seb128> cjwatson, ah, that's good new, thanks
<seb128> rbalint, can you bring the topic with Steve and come back to me then, we need to know what to do on our side and the feature is sort of blocked on that item to be resolved
<rbalint> seb128: sure
<seb128> rbalint, thanks
<xnox> didrocks, slangasek - i want new plymouth, and i want initramfs hooks to correctly set force-scale, and i want high-dpi plymouth themes by default.
<xnox> didrocks, slangasek - are you planning on merging plymouth, or shall i?
<didrocks> xnox: please go ahead ;) I won't really have time for handling it
<tkamppeter> xnox, slangasek, can you have a look at bug 1721839? It is a severe regression which we should not have in LTS and upstream is not answering.
<ubottu> bug 1721839 in systemd (Ubuntu) "[REGRESSION] Services asked for by UDEV do not get triggered" [Critical,Confirmed] https://launchpad.net/bugs/1721839
 * juliank feels like freenode is being ddos'ed or something - everything is really slow
<Odd_Bloke> 30% slower, you say?
<juliank> Seems I hit a bug in znc-clientbuffer
<cpaelzer> It might sound stupid, but searches weren't kind to me - is there a Ubuntu specific counterpart to README.Debian?
<cpaelzer> I mostly see us adding to it which is fine
<cpaelzer> just thought to ask for once to be sure there is no hidden "if ubuntu only add to X instead"
<mdeslaur> cpaelzer: not that I'm aware of
<xnox> Odd_Bloke, hahahahahaha
<xnox> i'm bouncing too
<rbasak> cpaelzer: if README.Debian is misleading (because of an Ubuntu delta), I may patch README.Debian rather than create a separate file. Being careful to avoid misattributing the change to Debian.
<rbasak> As I see README.Debian as more of a README.packaging as opposed to a README which I'd normally attribute to upstream.
<rbasak> That's just IMHO. I'm not sure what other Ubuntu devs do.
<cpaelzer> thanks rbasak / mdeslaur
<cpaelzer> I know what I want to write and have no fear to be misleading
<cpaelzer> just wanted to make sure to not miss something all the time
<Laney> is this a valid C program? https://paste.debian.net/1004679/
<Laney> on i386 it prints 42123455, which is not what I would expect
<slangasek> is it a valid C program? sure.  Are you right to expect it to give you the obvious number as an answer? not without some compiler flags
<slangasek> Laney: unfortunately I don't remember what the flags are or have a good way to look them up without highlighting doko
<slangasek> Laney: it might be -ffloat-store
<sladen> Laney: welcome to the world of floating point.  You can play with  #include <fenv.h>  fesetround(FE_UPWARD);   etc
<greyback> Laney: https://godbolt.org/g/E8d6sH might help you figure it out
<greyback> 64 has a jump happening in the multiplication somehow, is curious
<Laney> It's interesting because if I multiply and then truncate in separate steps I get the "right" answer
<Laney> but if I annotate the intermediate double as a register variable it "works"
<Laney> and ffloat-store indeed "fixes" it
<Laney> s/works/breaks/ sorry(!)
<sladen> Laney: add to that, that Intel has internal 80-bit float registers, but only 64-bit when written back to memory
<Laney> bloop
<sladen> Laney: if you more carefully pick your example numbers to be ones that are accurately representable in floating point (ie. power-two integer fractions), you should be able to get "accurate" answers
<Laney> sladen: I would understand it more if the intermediate multiplication were wrong (https://paste.debian.net/1004686/)
<sladen> Laney: one has to first swallow the blue pill and accept that it is _not wrong_
<Laney> It seems wrong for it to differ based on whether I do it in one or two steps
<sladen> Laney: you're trying to view a decimal (base-10) approximation of mulitplying two binary fractions (1/N) * (1/N), which have been created from representable approximations of decimal (base-10) inputs
<Laney> The link I just pasted shows the expected answer
<sladen> in one case the printf() routine is rendering a base-10 approximation of a floating point value.  In the other case the printf routinue is rendering a precise representation of an integer value
<sladen> ...but that integer value is a truncated approximation of multiplying two approximations of base-10 numbers together, in 1/base-2 space
<sladen> Laney: did you try  long double  and  __float128   to get the full menu of outputs:  https://stackoverflow.com/questions/13516476/long-double-gcc-specific-and-float128
#ubuntu-devel 2018-01-12
<RAOF> Urgh! What happened to ppa:ubuntu-lxc/lxd-stable ?
<joelkrahemann> hi all
<joelkrahemann> how long does a proposed package until accepted?
<joelkrahemann> ^^ need
<cjwatson> that depends!
<cjwatson> the purpose of -proposed is to ensure consistency
<cjwatson> if something isn't consistent then it will delay indefinitely
<cjwatson> so you need to be specific
<joelkrahemann> https://launchpad.net/ubuntu/+source/gsequencer
<joelkrahemann> the current package has inconsistency but the proposed actually solves it
<cjwatson> joelkrahemann: it'll have to wait until we get the build farm back up on all architectures
<joelkrahemann> great! thank you
<cjwatson> https://lists.ubuntu.com/archives/launchpad-announce/2018-January/thread.html
<cjwatson> see also https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
<cjwatson> (which says the same thing)
<joelkrahemann> well, 1.1.4 is not affected by the issues of 1.2.1
<joelkrahemann> I have done a refactoring and did temporaly break things
<joelkrahemann> but everything is fine, now
<sil2100> cjwatson: question! Do you know if merge-o-matic gets automatically updated in production as per what's in bzr?
<cjwatson> reason doesn't matter, pretty much everything will stall for this
<sil2100> cjwatson: or is there a manual step of bzr pull required?
<cjwatson> sil2100: manual.  currently at r300
<cjwatson> sil2100: updated to r301 now
<sil2100> cjwatson: can I ask for a bzr pull? 301 has a stats change I wanted to have deployed for Pat and Steve next week
<sil2100> cjwatson: thank you!
 * sil2100 hopes nothing explodes
<mdeslaur> xnox: could you please merge open-iscsi to fix CVE-2017-17840 pleeze?
<ubottu> An issue was discovered in Open-iSCSI through 2.0.875. A local attacker can cause the iscsiuio server to abort or potentially execute code by sending messages with incorrect lengths, which (due to lack of checking) can lead to buffer overflows, and result in aborts (with overflow checking enabled) or code execution. The process_iscsid_broadcast function in iscsiuio/src/unix/isc... (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17840)
<xnox> mdeslaur, sure!
<xnox> nacc, cpaelzer, smoser - do you have strong opinions on who should be merging open-iscsi and how?
<xnox> I do see https://code.launchpad.net/~usd-import-team/ubuntu/+source/open-iscsi/+git/open-iscsi around
<cpaelzer> no strong opinion either way
<mdeslaur> thanks xnox
<cjwatson> sil2100: https://paste.ubuntu.com/26371997/
<smoser> xnox: The tests that are inplace i'm pretty happy with.
<smoser> they do have false negatives due to timeouts and a few other bugs, but do a good job of ensuring what we need to work works.
<xnox> yeah, and the update is small
<xnox> mdeslaur, uploaded
<mdeslaur> thanks xnox
<cjwatson> sil2100: fixed now
<bbear> hello
<bbear> I would like to know if you can tell me how to build my package only on python3 (not python2). dpkg-buildpkg is failing because it tries to launch the tests for python2 (which is not supported at the moment).
<nacc> xnox: i can do it
<nacc> xnox: ah i see you already did :)
<xnox> nacc, well, i uploaded it already.
<xnox> nacc, started trying out git-ubuntu.... and gave up, plus this merge was trivial, as grab-merge merged it right anyway.
<nacc> xnox: ok
<nacc> xnox: did you hit a bug with git-ubuntu?
<xnox> nacc, nah... i just gave up half way through the tutorial on the merge
<nacc> xnox: :)
<nacc> xnox: fair enough
<nacc> xnox: yeah, it takes a bit of work the first time (and is annoying, admittedly for trivial merges). But makes complex merges much faster once they are done once
<xnox> yeah
<Laney> git rerere is good for merges
<xnox> yeah
<nacc> Laney: yeah, it can be. Our workflow doesn't require it, but in the general Git case it could. We don't have too many Git-merges anymore in the latest import algorithm.
<jbicha> bbear: you might want to try #debian-python on the OFTC IRC network since there may be more people to help you there
<pedrocr> any chance this can get resolved? https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1736116
<ubottu> Launchpad bug 1736116 in virtualbox (Ubuntu) "Host with kernel 4.13 freezes when starting a VM with VirtualBox" [High,Confirmed]
<pedrocr> the 4.13 HWE kernel breaks virtualbox in 16.04 LTS
<pedrocr> since that's now needed to fix meltdown/spectre it would be nice if virtualbox was just upgraded to 5.1 or 5.2 as well
<pedrocr> also, shouldn't the intel-microcode update be pulled? seems to be broken in some severe ways
<sarnold> I believe we've decided to not pull the update since we haven't had many reports directly to us of problems; but we have scaled back plans on how widely to distribute them
<sunweaver> jbicha: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1737834
<ubottu> Launchpad bug 1737834 in indicator-sound (Ubuntu) "indicator-sound fails to build, test failures" [High,New]
<sunweaver> I see you have the same issues as I have...
<sunweaver> https://jenkins.arctica-project.org/job/ayatana-indicator-sound.deb+nightly/target=bionic/28/console
<sunweaver> jbicha: have you had time to look into it more deeply?
<jbicha> no
<pedrocr> sarnold: as far as I know the kernel that could use the updated hasn't been shipped yet to there's no point in taking the risk with the microcode
<sunweaver> the issue is, I don't see it locally. Neither on a system nor in sbuild builds.
<pedrocr> sarnold: I've just uninstalled intel-microcode completely to avoid it
<sunweaver> but on my build host, I get those failures.
<pedrocr> (for the HT issue I have an upgraded BIOS already doing the microcode update)
<sunweaver> jbicha: nice, I can reproduce...
<sunweaver> if I sbuild on my notebook, the build works.
<sunweaver> if I ssh into localhost and then run the same sbuild command, I get the failure...
<sunweaver> running sbuild with --purge=successful and re-visiting /tmp/pulse-daemon.log in the chroot.
<sunweaver> http://paste.debian.net/1004906/
#ubuntu-devel 2018-01-13
<sunweaver> jbicha: here is a patch you might be interested for indicator-sound: https://github.com/AyatanaIndicators/ayatana-indicator-sound/commit/73262741e8480f6161659275c9d9239e6351d011
<sunweaver> this does not bring back successful builds for ayatana-indicator-sound, but it may fix https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1737834
<ubottu> Launchpad bug 1737834 in indicator-sound (Ubuntu) "indicator-sound fails to build, test failures" [High,New]
<rfleming> Greetings.  Is there an 18.04 mini iso?
<rfleming> please disregard, I shall go ask in #ubuntu like I should have.
<krytarik> More like in #ubuntu+1 though.
<rfleming> good point
<krytarik> (Also, I didn't find any either.)
<rfleming> yeah... I only see the desktop.  I'd like to try it out with vanilla gnome
<rfleming> (and since ubuntu-gnome doesn't exist, there is no alpha
<krytarik> Click through here: http://iso.qa.ubuntu.com/qatracker/milestones/384/builds
<rfleming> that's awesome!
<rfleming> is that sharable?  oeherks in #ubuntu answered there and I wanted to share.
<krytarik> Of course.
<rfleming> but don't want to add fud to everyone else
<rfleming> OK
<krytarik> Testing is always appreciated! :P
<rfleming> the site looks like greek, but if I read that correctly, it has yet to have any QA tests performed?
<rfleming> unlike, say, lubuntu
<krytarik> rfleming: Yeah, no one has done any testing on them this cycle yet it seems: http://iso.qa.ubuntu.com/qatracker/milestones/384/history
<rfleming> mini.iso doesn't work :(  Says all mirrors are bad as there's no release data for bionic on them
<rfleming> live by the sword... die by the sword :)
<krytarik> lol
<rfleming> it also says it could be I have a crappy connection... but I have my doubts :)
<rfleming> out of curiosity, what is ubuntu-base?
<rfleming> ahh, create custom images for rootfs environments, like for docker, or LXC
<rfleming> okie
<krytarik> Yup!
<rfleming> TIL
<krytarik> The mirrors should work though.
#ubuntu-devel 2019-01-07
<volty> After hours of trying, I came with the idea of googling for ubuntu bios corrupt after installation, and found that it happens with some computers since version 17.
<volty> sorry, previous is by error
<volty> (pasting)
<volty> So, now a question for you, since nobody in the user-level #ubuntu, is going to know this --- does the bios get touched only during the installation? Can I now use the installed kubuntu-18.04 without fear (with normal use, no distro upgrade) that it is going to touch the bios again ?
<cjwatson> doko: Is your FTBFS report generation not cronned?
<cjwatson> doko: I fixed a bunch of failures last night (casualties of some kind of infrastructure glitch over the holidays) but the effects aren't visible yet
<doko> cjwatson: no, I was traveling, and the report takes a few hours. I should move it to some machine like p.c.c
<cjwatson> if you do then make sure the cron job has appropriate locking (maybe obvious but people.c.c often has problems with people who've written cron jobs assuming that they can get away without locking and then ending up with multiple copies running)
<cjwatson> mwhudson: Would you mind re-reviewing https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/361172 ?  You reviewed an earlier version
<zyga> kissiel: hey,
<zyga> kissiel: can you please look at https://forum.snapcraft.io/t/stage-package-not-able-to-pull-latest-source-for-checkbox-ng/9106
<kissiel> zyga: ack
<zyga> thank you
<cyphermox> LocutusOfBorg: probably fine to upload, IIRC they don't have update-secureboot-policy.
<cek> Not sure whether it's a dev question... I'm wondering why every document I find on uefi SecureBoot says signing certs should be installed into databases and at the same time they are mentioning PKI. So, should the `db` contain the signing cert or should/can it contain the CA cert that issued the signing cert?
<cpaelzer> doko: the massive kopanocore issues breaking it badly were removed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907396
<ubottu> Debian bug 907396 in kopano-server "kopano-server: Tools all fail with: MAPI error 80040111 (MAPI_E_LOGON_FAILED)" [Serious,Fixed]
<cpaelzer> doko: also all my former Delta is accepted
<cpaelzer> the only thing left as Delta are the two fixes you added recently "Build-depend on libsystemd-dev" and "Fix the kopano-spamd install file."
<cpaelzer> IMHO your two fixes are nice but not super important atm, it builds and works sort of ok as-is
<cpaelzer> we also don't need the php7.1mapi rename as we are post 18.04
<cpaelzer> I'm tempted to suggest making it a sync, especially given that it is "universe only"
<cpaelzer> doko: what do you think?
<cyphermox> cek: it's a proper PKI -- you need to have a proper chain of trust though
<cyphermox> ie. we ship shim with a certificate that is the issuer for what actually signs kernels.
<doko> cpaelzer: up to you. iirc, I removed it from the release pocket, so no current migratons are affected
<LocutusOfBorg> cyphermox, can you please add -v?
<LocutusOfBorg> I already uploaded in debian...
<LocutusOfBorg> but not all the delta
<cyphermox> what?
<cpaelzer> doko: right you removed it, let me build latest Debian in a PPA and decide then
<LocutusOfBorg> [16:01:54] <cyphermox> LocutusOfBorg: probably fine to upload, IIRC they don't have update-secureboot-policy.
<LocutusOfBorg> "to upload" <-- what and where?
<LocutusOfBorg> I forgot the exact question :
<LocutusOfBorg> :p
<cyphermox> dkms
<LocutusOfBorg> cyphermox, to debian, the very same delta?
<cek> there's proper chain of trust, it just seems that secureboot requires the pubkey/certificate that was directly used to sign the binary, not the CA that issued the cert.
<cyphermox> LocutusOfBorg: yeah, should just work, I guard against doing anything if the script isn't there.
<LocutusOfBorg> ack
<ricotz> mwhudson, hello :), could you update rustc to 1.31.1 (firefox trunk already requires it)
<ahasenack> hi, I added a block-proposed tag to https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1806035 a while back, and now I uploaded a new samba package which has a fix for that bug
<ubottu> Launchpad bug 1806035 in samba (Ubuntu) "smbd fails to start in default config if winbind is running" [High,In progress]
<ahasenack> should I remove the tag, or will things happen automagically?
<ahasenack> I have a feeling this is a chicken-and-egg problem
<ahasenack> and that I should remove the tag manually
<infinity> ahasenack: Remove the tag, yes.
<ahasenack> thx
<infinity> ahasenack: To understand the chicken and egg issue, the bug won't auto-close until it migrates, and it can't migrate with the tag. :)
<ahasenack> exactly :)
<infinity> ahasenack: I've tossed around the idea of making britney smart enough to detect that the current version closes the blocking bug, BUT that breaks a useful workflow people have developed where they close the blocking bug in the changelog, but rely on the block to keep it there until they've done manual testing.
<mwhudson> ricotz: um maybe, pings on irc aren't how i do work scheduling though :)
<ricotz> mwhudson, I see, so I am hoping it is already on your schedule ;)
<mwhudson> ricotz: heh it probably should be but christmas and all that
<ricotz> mwhudson, heh, thank you
<mwhudson> ricotz: blargh, someone(tm) should update https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox
<tomreyn> are you saying the "rust update policy for firefox" is rusty?
<mwhudson> the part of my brain responsible for puns is still on leave
<tomreyn> doing employed work wouldn't be possible for me without this.
#ubuntu-devel 2019-01-08
<cpaelzer> sil2100: hiho, you might know - is bileto down for a reason or juts by accident?
<cpaelzer> I get connection timeouts when browsing to it
<sil2100> cpaelzer: hmmm
<sil2100> cpaelzer: it works here for me, probably was just some temporary failure?
<cpaelzer> sil2100: yeah working now
<cpaelzer> odd
<cpaelzer> hey, I look for some packaging magic guidance
<cpaelzer> Debian did a change that is useful in moving a blob (rom file) generated from an arch sepcific package to a "Architecture: all" package
<cpaelzer> so far so good
<cpaelzer> but we built two such roms (so far arch specific on s390x), and the second rom can ONLY build on s390x
<cpaelzer> it can easily be reused on other architectures
<cpaelzer> furthermore debian did it ina hackish way which will miss if any changes/fixes for those roms are done to the makefile upstream
<cpaelzer> so I wonder if I could build things on s390x the "upstream intended way" but then still make them part of an "Architecture: all" package (preferably the one I already have containing other roms as well)
<cpaelzer> I realized my knowledge on build-indep is lower than it should be so any help is welcome
<cjwatson> Sounds like you want "XB-Build-Indep-Architecture: s390x" in the first stanza of debian/control
<cjwatson> may be LP-specific - there was debate about it and I'm not sure we ever got that into Debian
<cpaelzer> cjwatson: interesting, let me read about that flag
<cpaelzer> cjwatson: it is possible (not sure yet) that there are also roms that only build on x86 (the current executor of build-indep)
<cpaelzer> cjwatson: is there any chance that I can get both or is this an "either this or that" decision?
<cpaelzer> also search endinges don't give me useful links for XB-Build-Indep-Architecture is there any reference you could share?
<cpaelzer> yeah it has x86 only bits as well
<cpaelzer> so the question really is can I have one deb package that has content built on two different builders, and I assume the answer is no
<cpaelzer> am I allowed to split an extra (new) package for that being architecture:all but built on s390x
<cpaelzer> I could only move the two roms I want there and have all I want right?
<cpaelzer> the roms built the upstream intended way ending up in a arch:all package
<cpaelzer> I'll try that - let me know if that is in vain :-)
<cjwatson> cpaelzer: I mean ... you can't simultaneously build a package on more than one arch
<cjwatson> cpaelzer: you'll have to split it up or else work out some way to get everything to build on a single arch
<cpaelzer> cjwatson: yep, I decided to split the package
<cpaelzer> thanks for confirming my assumptions
<cpaelzer> are there known limitations on building architecture: all content NOT in build-indep
<cjwatson> can't recall I'm afraid
<cpaelzer> as that is what I need to build one on x86 (that will be in build-indep) and one on s390x (that will be in buld-arch)
<cpaelzer> ok, I'll give it a try
<cpaelzer> thank you already cjwatson
<cjwatson> I'm not totally sure how what you're saying makes sense
<cjwatson> But I need to catch a train
<cpaelzer> have a good ride
<LocutusOfBorg> Odd_Bloke, hello, if you want to do some hg-git fixup, http://debomatic-amd64.debian.net/distribution#disco/hg-git/0.8.12-0ubuntu1/autopkgtest
<LocutusOfBorg> the test requiring ssh should be disabled in my opinion
<LocutusOfBorg> :)
<ginggs> LocutusOfBorg: do you plan to upload hg-git 0.8.12 to debian?
<LocutusOfBorg> ginggs, for some reasons the same version fails there...
<LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#unstable/hg-git/0.8.12-0.1/buildlog
<LocutusOfBorg> I couldn't figure out why... maybe new git version
<ginggs> i saw some fixes in hg-git gitlab that are not released yet
<ginggs> but i want to know if you are planning to upload hg-git to debian, so we don't duplicate work
<ginggs> s/gitlab/bitbucket/
<LocutusOfBorg> ginggs, no please, I plan to do something else, more important :D
<LocutusOfBorg> go go go, you can start from my DOM upload :D
<tjaalton> jbicha: hi, what's still missing from lm-sensors migration?
<rbasak> Skuggen: from juliank: https://paste.ubuntu.com/p/HK3p28KNkz/
<rbasak> Skuggen: he said in #ubuntu-release it's fixed upstream in 5.7.26 but has no release yet.
<rbasak> Do we need to upload this patch or is the upstream release imminent?
<Skuggen> 5.7.26 or 5.7.25?
<juliank> I need this patched for lz4 (but it's also blocked by systemd, and ros-ros-comm on some archs)
<juliank> Skuggen: https://bugs.mysql.com/bug.php?id=93778 says "Fixed in 5.6.44, 5.7.26, 8.0.15."
<rbasak> Enough time to fix in Debian and autosync over?
<juliank> sure, it's not _super_ urgent
<juliank> I think we'll have to fix systemd too, and that'll take longer
<rbasak> OK I'll knock up a MR for Salsa.
<Skuggen> 5.7.26 is some ways off (5.7.24 is the current release, and 5.7.25 will be out soon)
<rbasak> juliank: shall I hack your changelog for version/release to leave you attributed?
<juliank> I'd just dch -r it so I'd end up in [ ] inside the changelog
<rbasak> OK
<juliank> Skuggen: So, 5.7.25 will be released with a failing test suite? That's fun
<juliank> time based tests are fun in any case
<juliank> "oh 2018 is a long way off, let's use that"
<juliank> "oh no, it's 2019, the test testing 2018 stopped working"
<rbasak> I suspect it might be fixed "properly"
<juliank> hopefully
 * juliank looks at ros-ros-comm, that's scarier
<ahasenack> hi, bileto.ubuntu.com is timing out after authentication with sso (proxy error 502), is that something that is usually addressed with a service restart of some sort?
<ahasenack> or something more serious is going on?
<ahasenack> #is can restart services, but don't really know the layout of that machine
<Skuggen> juliank: Yeah, hopefully. I'
<Skuggen> I've seen some such tests fixed properly, while others are just +10 years :P
<juliank> Skuggen: I think the problem is that we are running out of years on 32-bit
<juliank> s/the/a/
<ahasenack> sil2100: around?
<ahasenack> bileto.u.c seems to have lost some launchpad authentication token and it's filling the logs with messages like " Waiting to hear from Launchpad about your decision..."
<ahasenack> apparently waiting for someone to hit that url
<ahasenack> do you know what that is about? #is can restart things, but it looks like this is something else
<sil2100> hmmm
<sil2100> ahasenack: let me look at that
<jbicha> tjaalton: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says that gkrelmmm is blocked by gnutls28
<tjaalton> jbicha: gotcha
<coreycb> doko: by any chance can you rebuild the openstack packages in your test rebuilds? i think most are fixed.
<coreycb> fyi jamespage ^
<jamespage> coreycb: what was the issue?
<coreycb> jamespage: several were hitting the sqlite issue but i've built a few more that were hitting other issues successfully.
<ahasenack> teward: hi, do you know where nginx stands with lua 5.x support? Does it still only support lua5.1?
<ahasenack> https://github.com/openresty/lua-nginx-module/issues/204 seems to indicate they don't want to go beyond 5.1
<ahasenack> ...and found the issue you reported :) https://github.com/openresty/lua-nginx-module/issues/343
<doko> coreycb, jamespage: given back, currently running
<coreycb> doko: thanks
<juliank> ahasenack: lua is a real mess
<ahasenack> juliank: looks like it, we have 5.1, 5.2 and 5.3 in disco
<juliank> ahasenack: I mean, luajit only supports 5.1 syntax (+ some 5.2), and 5.2 had a huge ABI break, so code is split in luajit vs lua>=5.2
<juliank> and that sucks
<ahasenack> I saw that nginx switched to jit at some point
<rbasak> Laney: network-manager dep8 fix++, based on your changelog message
<rbasak> Thank you for sorting that
#ubuntu-devel 2019-01-09
<doko> tsimonq2: https://bugzilla.opensuse.org/show_bug.cgi?id=1121214 seen in libqt
<ubottu> bugzilla.opensuse.org bug 1121214 in Basesystem "GCC 9: libqt4 build fails" [Normal,New]
<doko> jamespage: murano-agent fails autopkg tests (with python 3.7.2)
<rbasak> juliank: why the dnsmasq upload? I thought Laney was sorting it in the network-manager autopkgtests?
<juliank> rbasak: i don't know, Laney asked me if I'd upload it
<Laney> The dnsmasq upload was the failure; my changes to n-m fixed some other ones, but not those which were failing on autopkgtest.u.c
<rbasak> I feel that this just kicks the can down the road, and I'm not keen on having to maintain this patch :-/
<rbasak> (based on my current and rather incomplete knowledge of the actual problem; but I suspect that's the case with everyone else involved too)
<Laney> Second best approach that I could see given that we don't know how to fix it
<Laney> Changing the tests in network-manager to work around a bug in dnsmasq would not have been right, IMO
<Laney> and I *did* do some analysis and post on the upstream list, which I still hope/expect to result in a proper fix
<rbasak> I agree with the general principle of not having to change the tests in N-M to work around a bug in dnsmasq.
<rbasak> But it seemed to me that n-m tests weren't actually testing the right thing?
<rbasak> In that the failure couldn't identify a specific buggy use case in dnsmasq?
<rbasak> In that case narrowing down the n-m tests seems like a good idea.
<Laney> what do you mean?
<Laney> It was always a specific few tests that were failing in the same way
<rbasak> But AIUI we haven't been able to say to dnsmasq upstream "here's a bug: when we do <valid use case> it results in <incorrect behaviour> instead of <expected behaviour>"
<Laney> I think my thread was fine in that sense
<Laney> Upstream attempted to come up with a patch but it didn't work
<rbasak> I appreciate your work in analysis and talking to upstream btw. Hopefully that'll lead to a proper fix and we'll be able to drop the patch. I'm just concerned in case that doesn't happen, we'll end up stuck.
<Laney> If someone else wants to help out and create a more minimal reproducer, that would be welcome. I was suffering from a lack of knowledge.
<rbasak> I got the impression that upstream haven't identified a specific bug either. We only have your successful bisection, and we're all still blind to the underlying cause.
<rbasak> (and blind to even what the bug actually is)
<Laney> That's... why you post a bug report?
<rbasak> We know that an upstream commit caused a change in behaviour that broke us.
<rbasak> We don't know that there's actually a bug in upstream dnsmasq...do we?
<Laney> I'm confident enough.
<Laney> But if you're unhappy with my call, it's your team's package.
<rbasak> I'm not sure I agree. But anyway, I appreciate your time on this. It's probably not worth us spending more time on discussing this more unless something further happens.
<Laney> Put the change back in, it'll get blocked in proposed because of breaking network-manager's tests.
<Laney> And then, well, we can argue about who gets to debug it.
<juliank> That seems reasonable
<juliank> We really need to have a convention for changes we made that we do not want to stop syncing. So something between ubuntu and build
<juliank> So that I could have uploaded that hack with that version, and then a later sync would still happen and we'd see it being broken again (or it's fixed and migrates)
<rbasak> Something that starts with 'l' or 'm' then :-P
<juliank> Well, it could be any string lower than ubuntu
<juliank> like buntu
<juliank> 1.0-1buntu1
<juliank> that was my silly string
<Laney> I should mail the person who wrote the patch in question in the first place and see what they think
<juliank> 1.0-1ubuntmp1
<juliank> ubuntmp sorts well, but is not entirely obvious
<Amnesia> question, I'm trying to create a cosmic chroot, but debootstrap is stating that the InRelease file has expired: E: InRelease file http://archive.ubuntu.com/ubuntu/dists/cosmic/InRelease is expired since (Wed, 09 Jan 2019 00:00:00 +0100)
<Amnesia> does anyone have a clue what's goin on?
<juliank> So, haproxy and wget are stuck in proposed as they built against pcre2. I patched wget to use pcre3 again
<juliank> Not sure about haproxy
<juliank> Amnesia: What do you see when you open http://archive.ubuntu.com/ubuntu/dists/cosmic/InRelease (wget, curl, or browser, whatever)
<Amnesia> juliank: Date: Thu, 18 Oct 2018 15:17:19 UTC
<juliank> Amnesia: Right, but no valid-until line, right?
<Amnesia> correct
<juliank> Amnesia: so, it works for me in disco, which release are you trying that on? Also, I think you can check in the target directory you specified and look at release files there
<Amnesia> I'm trying it on arch..
<juliank> Amnesia: ok, that's trickier
<juliank> Amnesia: that's debootstrap 1.0.113?
<Amnesia> yep
<Amnesia> https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/debootstrap&id=03584f10a9edb8de54c6417f133ecea5862f4ff3
<juliank> Amnesia: So, I don't see how this happens
<juliank> Amnesia: I think you can run debootstrap as sh -x <path to>/debootstrap
<juliank> that should give you a verbose log
<Amnesia> yep, going through it atm..
<juliank> Amnesia: No, I see how this happens
<Amnesia> you do?
<juliank> Amnesia: Passing --no-check-valid-until should make it work
<juliank> The code assumes that Valid-Until is in the release file, which it is not for ubuntu
<Amnesia> hm seems to work indeed
<Amnesia> https://github.com/felixonmars/debootstrap/blob/4f6c6c0ccfd15145bae94b204056be3f78b08670/functions#L632
<Amnesia> looks like you're right yes
<juliank> That's https://bugs.debian.org/918722
<ubottu> Debian bug 918722 in debootstrap "debootstrap: says InRelease file expired" [Normal,Open]
 * Amnesia facepalms
<Amnesia> I should've checked the bug tracker
<Amnesia> sorry for the hassle juliank
<seb128> bdmurray, hey. Could you help with https://launchpad.net/ubuntu/+source/gvfs/1.38.1-0ubuntu1.1 ? It includes 3 fixes, 2 have been verified and the 3rd one isn't working because it's relying on a samba change which we don't have in our version. The non-verified one is basically equivalent of no-change, can we validate the SRU as it? or do you want another upload with that change removed? (but then we need to revalidate the other fix/delay?)
<seb128> vorlon, how did you manage to get a SRU in without bug reference? ;) (https://launchpad.net/ubuntu/+source/livecd-rootfs/2.542.1)
<seb128> bdmurray, https://launchpad.net/ubuntu/+source/fontconfig/2.12.6-0ubuntu2.3 should also probably be deleted from bionic-proposed, it failed verification and it was decided that SRU was not needed after all so no fixed version has been uploaded
<vorlon> seb128: well, I didn't accept it, ask whoever did :)
<vorlon> seb128: (livecd-rootfs is a special case, but having an SRU with no linked bugs at all risks foundering on the process)
<seb128> vorlon, right, unsure if the "who accepted" info is available somewhere? anyway, I mentioned it in case that was an overlook because it looks like the sort of isse that could lead the SRU to be stucked because ti's never marked as green/verified on the report page
<vorlon> seb128: nope, we record that information in comments on the linked bugs ;-)
<seb128> k, well that usually doesn't work for me :p
<vorlon> well in this case there's no linked bug, hence the ';-)'
<seb128> right
<seb128> anyway
<seb128> thx for the reply :)
<vorlon> bdmurray: ^^ does that happen to have been your accept?
<bdmurray> vorlon: Yeah, it was I who accepted the package. I imagine you or Cody will nag about getting it released.
<vorlon> bdmurray: ok :)
<bdmurray> although I guess I misremembered what you'd added to the SRU page about it.
<bdmurray> I blame Santa for that.
<bdmurray> seb128: fontconfig will require an AA which I am not
<bdmurray> seb128: I'm fine with letting gvfs into cosmic-updates.
<seb128> bdmurray, thx, I can do fontconfig, I was just unsure if that needed some sort of SRU team ack first
<bdmurray> seb128: Well I'll ack it just in case
#ubuntu-devel 2019-01-10
<cpaelzer> FYI the architecture:all issue we discussed a few days ago still persists - the workaround does not work, let me explain again - maybe there are other hints
<cpaelzer> initial problem: I have some bits that are (once built) architecture neutral and can be used everywhere - so they should be architecture:all
<cpaelzer> but I have some of them which only build on x86 and others which only build on s390x
<cpaelzer> the x86 bits are ok as they build in build-indep
<cpaelzer> but the s390x bits are missing there obviously
<cpaelzer> I tried to create an extra architecture:all for the s390x bits and build them on s390x - they build, but due to architecture:all it uses the x86 build of the package to crate a ..._all.deb which does contain nothing
<cpaelzer> cjwatson: suggested XB-Build-Indep-Architecture but explained that it is global (not per package) so I can only decide to have either x86 or s390x bits build correctly
<cpaelzer> I'd want XB-Build-Indep-Architecture but not at the first stanza but per binary package
<cpaelzer> unfortunately documentation on it is very thin (I found none)
<cpaelzer> TL;DR: any hints if I could control to build two architetcure:all from one src, but one on x86 and one on s390x?
<cpaelzer> rbasak: ^^ this is the build-indep *fun* that I mentioned briefly
<cpaelzer> maybe a deeper understanding of foreign as an alternative would help, reading more docs ...
<infinity> cpaelzer: You can't do what you want.
<infinity> cpaelzer: You'll have to think slightly outside the box.
<infinity> cpaelzer: Options like:
<infinity> cpaelzer: 1) Have source A produce a foo-source binary package, then source B build-deps on that and builds the s390x arch all bits.
<infinity> cpaelzer: Or:
<infinity> cpaelzer: 2) Have source A build the s390x bits as an s390x deb, then source B build-deps on that deb and spits out an arch all.
<cpaelzer> thanks infinity, that confirms what I was afraid of
<infinity> cpaelzer: Option 2 seems a not entirely unreasonable workaround, at least.  So, foo produces foo-native_s390x.deb, then foo-repack is Build-Indep-Architecture:s390x, build-deps on foo-native, and spits out foo_all.deb
<cpaelzer> for now I've started to try cross building it properly
<cpaelzer> I think it is unlikely, but if that would work it woudl resolve all of that as I could build it on x86 into the arch:all
<infinity> cpaelzer: Oh, crossing is also valid if it doesn't have a bunch of external deps.
<infinity> cpaelzer: What is the theoretical thing in question?
<cpaelzer> varios qemu FW roms
<infinity> cpaelzer: Oh!  Crossing is totally a valid option, then.
<infinity> cpaelzer: firmware pretty much by definition has no external deps, so a working toolchain should be all you need.
<cpaelzer> yeah should be, if it would not fall apart all the time :-)
<infinity> Fall apart, how?
<cpaelzer> last time I looked at it (long ago) and recently when the Debian maintainer looked at it it failed to cross build
<infinity> I mean, barring really bad makefiles, CC=s390x-linux-gnu-gcc should be enough.
<cpaelzer> I just threw away all old stuff we had and started all over again to take a fresh look
<infinity> I've definitely taken this route in the past for PPC stuff.
<cpaelzer> just setting CC=arch-cc-string and give it another chance
<infinity> And, indeed, since we dropped the 32-bit PPC port, we HAVE to cross some FW bits for ppc64el.
<infinity> Because reasons.
<cpaelzer> hehe
<cpaelzer> I might ping later for some silly cross-build issue - but that certainly seems the way to go if I can make it work
<cpaelzer> thanks infinity
<infinity> cpaelzer: Our cross toolchains are pretty mature, so any failure is going to be in the build system in question.  Happy to help look if you stumble.
<infinity> cpaelzer: If it's autotools, you sometimes have to preseed some values it can't determine, if it's pure Make, you just have to scrub it of any hardcoded stupid, etc.
<cpaelzer> it should be pure Make in this case
<infinity> cpaelzer: For bonus points, I'd make all the x86 stuff crossable too, so the arch-indep arch legit stops being meaningful. :P
<cpaelzer> it's not even looking like the worst case to cross compile, it is just an area I have only touched slightly in the past
<infinity> And fixes to make that work should probably be very upstreamable.
<infinity> cpaelzer: As in, a solid goal would be to build the package on s390x and amd64 and have both the s390x and amd64 firmware come out byte-identical.
<infinity> Or, at least, disassembly-identical, if they're not reproducible-friendly.
<cpaelzer> yeah that would be a great cross-check thanks for the hint
<infinity> cpaelzer: Note that you'll need gcc-multilib (which also has a cross-equivalent meta) if it builds any -m31 crap.
<cpaelzer> I needed gcc-multilib-s390x-linux-gnu and also pkg-config-s390x-linux-gnu , but it still seems to me that the configure I need to run tries way to mcuh link/execute to check capabilties
<cpaelzer> I don't need to make the build env like multi-arch or so right?
<cpaelzer> what is the trick to usually get around all the linking issues to the libs of the foreign arch?
<cpaelzer> infinity: in case you are still around ^^
<cjwatson> cpaelzer: As infinity said, "If it's autotools, you sometimes have to preseed some values it can't determine"
<cjwatson> cpaelzer: Find the cache variable name that it's setting and set it on the configure command line
<cjwatson> Assuming that it can be expected to have a reasonably constant value in an Ubuntu environment, anyway
<cpaelzer> it's missing various libraries - essentially ...-dev as I only have e.g. libglib2.0-dev:amd64
<cpaelzer> but not the same :s390x
<cpaelzer> that is where I wonder if I need an multiarch env here
<cpaelzer> no configure.ac or similar here
<cpaelzer> so I doubt it autotools vars are a reason here
<cpaelzer> I'd mostly want a) probably all my build-deps also as :s390x or b) better understand what I want :-)
<cpaelzer> for the record - I can add "deb [arch=s390x] http://ports.ubuntu.com/ubuntu-ports/ disco main universe" run apt update and then install  libglib2.0-dev:s390x which gets it going
<cjwatson> You can't have a multiarch env.
<cjwatson> Find another answer :)
<cpaelzer> cjwatson: another answer than "installing the dependencies I need" :-)
<cpaelzer> that sounds like it will make it even more complex :-/
<cjwatson> If you can only build this thing by linking against libglib, then it's not just a matter of configure capability checks as you said above, right?
<cpaelzer> What I eventually want to build will be fine without all those deps
<cpaelzer> just the configure wants to check for all of it
<cjwatson> Then override the configure checks somehow
<cpaelzer> I might need to check if this congirue has (or add it) any way of don't check for all the stuff I don't need in this case
<cpaelzer> cjwatson: yeah overrides like that are what I'm leaning to atm
<cjwatson> vorlon: How likely are the various livecd-rootfs SRUs to land in the nearish future?  I'd like to explore getting my various buildd image production changes into xenial and bionic
<rbasak> xnox: around? Any opinion on bug 1717014 please? Given it affects ping, it presumably affects "getent hosts" so isn't bind9-specific. I suspect you might immediately know where the bug belongs?
<ubottu> bug 1717014 in bind9 (Ubuntu) "host stops searching domains when it gets back NSEC record" [Undecided,New] https://launchpad.net/bugs/1717014
<rbasak> I'm not current with the DNS stack involving resolved nowadays :-/
<brainwash> can one of the ubuntu devs take a look at bug 1801629 please?
<ubottu> bug 1801629 in xubuntu-meta (Ubuntu) "xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove' will make a LUKS+LVM encrypted root partition non-bootable" [Undecided,Confirmed] https://launchpad.net/bugs/1801629
<brainwash> it's a critical bug I'd think, and I assume that it needs to be fixed for every ubuntu flavour either separately or via a shared dependency list
<brainwash> bug appeared in 18.10
<rbasak> brainwash: does it affect the Ubuntu (default) flavor?
<rbasak> Thank you for bringing it up. I just don't know who to ping!
<brainwash> rbasak: I guess it does not, otherwise there would be more buzz around this bug
<brainwash> and kubuntu is the only flavour that explicitly depends on cryptsetup and lvm2
<rbasak> brainwash: perhaps we need to bring it to the attention of the flavor leads then?
<brainwash> rbasak: xubuntu and ubuntu mate are tagged via the bug report already, and the xubuntu lead is subscribed to the report
<brainwash> it would help to know what has changed from 18.04 to 18.10
<brainwash> instead of just adding these packages as dependencies
<rbasak> brainwash: something changed about what gets marked automatically installed I think.
<rbasak> I don't remember the details.
<rbasak> Maybe juliank knows?
<juliank> yes, what's up?
<juliank> Oh, that seems unfortunate.
<rbasak> juliank: bug 1801629 - I think brainwash is looking for some background on the underlying change
<ubottu> bug 1801629 in xubuntu-meta (Ubuntu) "xubuntu-core needs to depend on cryptsetup and lvm2 or 'apt autoremove' will make a LUKS+LVM encrypted root partition non-bootable" [Undecided,Confirmed] https://launchpad.net/bugs/1801629
<juliank> It might be related to the work I did - it traversed the dpeendencies of all metapackages and marked them as automatically installed
<juliank> So it _should_ be safe, but it might be missing corner cases where a metapackage was removed in ubiquity during install
<rbasak> I guess we need to ensure that when the installer is done cryptsetup et al are marked as manually installed?
<juliank> We can look at the log file and see what marked them automatic in the first place
<rbasak> That ought to be a test case for encrypted installs now I guess.
<juliank> at the image build log
<juliank> We just need to get the build log for xubuntu 18.10, amd64 image
<juliank> I think I found logs once, but I don't remember where
<juliank> maybe vorlon or cjwatson know where to find the image build log?
<cjwatson> Start from https://people.canonical.com/~ubuntu-archive/cd-build-logs/
<juliank> cjwatson: the livecd-rootfs logs, actually
<juliank> I think those are  debian-cd logs?
<cjwatson> juliank: if you look at the appropriate cd-build-logs log you'll find a link to the corresponding livefs build on LP
<cjwatson> and you'll find a livefs build log there
<juliank> Ah I see, thanks
<seb128> juliank, hey, I would like to have your input on https://code.launchpad.net/~silhusk/software-properties/lp1656100-remove-signing-keys/+merge/361160 , I did a review because it was sitting in the sponsoring queue but you probably know better than me about the apt-key questions I asked there and maybe you can help?
 * cjwatson fixes cd-build-logs to be served as text/plain
<juliank> rbasak, brainwash So I've been looking at the xubuntu build log for 20181017, which seems to be the release build or closes to it, and I don't see cryptsetup in there. I do see lvm2 being marked
<juliank> I did not add the reason into the log, though
<juliank> so it's hard to follow the trail
 * juliank made the algorithm iterative rather than recursive and did not keep a stack
<juliank> so, one of these depends on dmsetup which depends on lvm2: https://paste.ubuntu.com/p/ydGwDMckhm/
<juliank> (or recommends it)
<juliank> that is libdevmapper1.02.1
<juliank> So ubuntu-minimal -> eject -> libdevmapper1.02.1 -> dmsetup -> lvm2 (where -> is Depends or Recommends)
<juliank> so lvm2 should not be possible to autoremove
<juliank> hmm, seems I have a bug in my procedure
<juliank> ah, ubiquity -> dmeventd -> lvm2
<juliank> that's why it's marked as auto
<juliank> but not sure how we got to ubiquity as auto
<juliank> Gotta extend the log with some tracing info I guess
<juliank> in any case, we might want get a list of all autoremovable stuff at the end of the ubiquity run and then mark those as manually installed
<juliank> seb128: see, I don't like this whole thing, it does not even handle trusted.gpg.d properly IIRC
<seb128> juliank, right, it could use a maintainer and fixes, but working and suboptimal is still better than not working :)
<brainwash> juliank: thanks for looking into this
<juliank> I think we should have a simple PPA management tool instead for some PPA things
<juliank> They now follow better conventions so you can easily add/remove ppas
<juliank> brainwash: will do some more digging tomorrow
<brainwash> okay
<seb128> juliank, still do you think it makes sense to display 16 chars key ids in the UI or should we do like the apt-key list command and have 8?
<rbasak> juliank: add-apt-repository seems to have evolved into the CLI version of such a tool. It does removals as well, and component enablement/disablement. Perhaps there's scope for some code sharing there.
<juliank> seb128: I'll think about it tomorrow
<juliank> rbasak: Its part of software- properties-common
<seb128> juliank, thx
<rbasak> juliank: yes, though I imagine some refactoring would be needed
<ahasenack> do we have a pattern for services which require configuration before they start, but can't have one supplied by default in the package?
<ahasenack> sysv services usually define a RUN variable in /etc/default/<service>, that defaults to "no"
<ahasenack> but with systemd, how to accomplish the same thing?
<ahasenack> the job sources /etc/default/<service>, but how to treat this RUN variable?
<ahasenack> case in point: https://git.launchpad.net/ubuntu/+source/freeipmi/tree/debian/freeipmi-ipmidetect.ipmidetectd.init#n70
<ahasenack> how to make https://git.launchpad.net/ubuntu/+source/freeipmi/tree/debian/freeipmi-ipmidetect.ipmidetectd.service respect that RUN variable? Or should it be installed masked by default?
<juliank> stgraber: FYI: I forwarded your autopkgtest changes for lxd upstream 4 hours ago, they got merged 2.5 hours ago. Woohoo
<juliank> Now we can sync that beast once the next version is out
<stgraber> yay!
<juliank> This will also fix qemu backend which is broken in disco right now due to python 3.7 incompatibilities
<stgraber> I thought I sent it to Martin back then but maybe I forgot
<juliank> or maybe he was too busy with other stuff, who knows
<juliank> in any case, it's merged now
#ubuntu-devel 2019-01-11
<vorlon> cjwatson: sorry, just now had a chance to look in on the livecd-rootfs SRU status and just had to mark one of the bugs v-failed.  I defer further questions to sil2100 (for the arm rpi bug) and platonical (for the snap manifests), as I'm on sprint travel from tomorrow
<Raboo> Any ubuntu dev eager to do a good friday deed of the day?
<Raboo> this bug https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1535045 have a solution since January 2016. But it's still not applied. Could a friendly soul perhaps apply the fix and resolve the bug?
<ubottu> Launchpad bug 1535045 in biosdevname (Ubuntu) "Biosdevname does not provide interface naming information for ConnecX4 Devices" [Medium,In progress]
<Raboo> or perhaps just push a newer release of biosdevname to the repositories as the bug is also fixed there.
<Laney> anyone looked into emacs/ppc64el ftbfs?
<Raboo> or would that be something I could do somehow?
<gQuigs> does anyone have any scripts to find the least recently uploaded Ubuntu packages (bonus if it only considers actual source changes).  I'm curious if anyone is auditing the old packages we don't import for Debian - and happy to do some work to that end.
<mdeslaur> gQuigs: merges.u.c has a "days old" column
<superm1> bdmurray, regarding SRU bug 1785165, before the holiday it was rejected due to the changelog missing a # in the fixes by.  can you re-review it when you get a chance?  I uploaded again a few weeks ago
<ubottu> bug 1785165 in fwupdate-signed (Ubuntu Bionic) "firmware update on fwupdate version 10-3 not work on some AMI's firmwares" [Medium,In progress] https://launchpad.net/bugs/1785165
<gQuigs> mdeslaur: that's just for packages that exist in Debian though right?  how about packages uploaded only to Ubuntu - example elastichosts-utils (uploaded last in 2019)
<jbicha> nobody's auditing that :(
<jbicha> there are some interesting links in the Derived from Buster section of https://launchpad.net/ubuntu/disco ("only in Disco" is part of what you wantâ¦
<jbicha> but it's noisy: some packages we want are removed from Testing but are still in Unstable)
<jbicha> https://wiki.debian.org/UltimateDebianDatabase is really powerful but it's a bit awkward to use
<jbicha> I personally would really appreciate it if you're able to build a report for packages unique to Ubuntu
<jbicha> Some of those packages should be uploaded to Debian. Some are unmaintained and we should just remove them.
<Laney> http://qa.ubuntuwire.org/neglected/
 * Laney attempts to tab complete gQuigs and fails
<jbicha> thanks, I wonder why it doesn't pick up https://launchpad.net/ubuntu/+source/system-integrity-check (2007)
<Laney> code's in the footer
<sivang> hi all
<sivang> are snaps what's used to install the bare gui-less, console providing parts of Ubuntu now days?
 * sivang tries to understand if snaps are either mendatory or optional part of the distro nowdays.
<JackFrost> sivang: Optional.
<sivang> JackFrost: cool, so no part of i.e. ubuntu 18.10 core requires it?
<JackFrost> sivang: A minimal install doesn't need it, though generally has it installed.  I have a desktop system, I don't have snapd.
<sivang> JackFrost: are there any parts that may require it for a non-minial / GUI install?
<gQuigs> sivang: key services that need snaps are LXD (included by default) and livepatch.  on the desktop a few GUI apps were switched but still provided as debs (for now)
<JackFrost> sivang: I believe chromium, but I could be wrong on that.
<JackFrost> (I use lxc because it's the only one in the repos.)
<valorie> JackFrost: are you anti-snap?
<JackFrost> valorie: Yes.
<valorie> so's tsimonq2
<valorie> or was at least
<sivang> gQuigs: so development effort indeed goes to eventually replace libapt?
<valorie> I see no reason not to see how it goes over time
<tsimonq2> valorie: Somewhat.
<tsimonq2> Cool idea.
<valorie> might beat out flatpack/appimage
<tsimonq2> I refuse to ship any in the default installation of Lubuntu though, but I also refuse to ship flatpaks and appimages.
<gQuigs> sivang: there's no timeframe that I know of / or more plans that I've seen to switch over more (except chromium as mentioned)
<tsimonq2> gQuigs: Well, and LXD.
<sivang> gQuigs: I see, thanks for the info
<tsimonq2> Oh.
<valorie> I see no reason for Kub. to ship them, but people can enable all of them in Discover
<valorie> if they want
<tsimonq2> Yeah, you commented above. :)
<tsimonq2> valorie: +1
<tsimonq2> If people want to install them, I won't stop them.
<tsimonq2> But I also don't want to stop them from installing any other "universal" formar.
<tsimonq2> *format
<valorie> competition can be healthy
<tsimonq2> Nothing against the snap guys, they're great, but several things need to be solved first.
<tsimonq2> (and gals)
<sivang> so livepatch is like Mac updates nowdays? (disclaimer: I've been away from the -devel community for a long while now)
<gQuigs> sivang: no idea...  it's just for kernel - https://auth.livepatch.canonical.com/
<tsimonq2> On a related note, I wish Ubuntu Members could get access to ESM, but I doubt that will ever happen.
<gQuigs> Firefox as a snap is almost there that I'd want to see it as the default..  just a few more snap fixes... Shameless plug: https://bryanquigley.com/posts/mindshare/snap-firefox-initial.html
<tsimonq2> gQuigs: Are file downloads working?
<tsimonq2> Last I used it you couldn't download files, which was a dealbreaker.
<gQuigs> tsimonq2: why ESM?  you want to run 12.04 (non-desktop)?
<tsimonq2> gQuigs: Yes.
<tsimonq2> I may or may not still have a 12.04 server somewhere, I won't say for sure. :P
<tsimonq2> ESM's a bit on the expensive side for me.
<JackFrost> Would firefox be offered as a snap alongside firefox in normal repos?
<tsimonq2> JackFrost: Seeing what they did with Chromium, probably not.
<JackFrost> tsimonq2: Yeah I still backport $pkg for a friend to precise, and it has about ~100 downloads according to PPA stats.  Right, then that's when I either hold an old firefox, grab Debian's, or move to Debian. :P
<gQuigs> tsimonq2: honestly, I don't think anyone though Ubuntu Members would be interested..  if you can convince the right people to add it as a membership benefit (likely 3 machine limit or some such), I'll volunteer to provision it
<gQuigs> Firefox and Chromium are both offered in both apt/snaps right now ... right?
<tsimonq2> gQuigs: Who would need convincing?
<sivang> so apps runs as a complete seperate cgroup'd virtual appliance through snaps?
<tsimonq2> I also happen to be on the Ubuntu Membership Board, I could pitch it to the board. :)
<JackFrost> gQuigs: Yes to the former, looks like it to the later.
<gQuigs> tsimonq2: that sounds like a start
<tsimonq2> gQuigs: Cool, mind if I carbon-copy you on the email?
<gQuigs> tsimonq2: sure
<sivang> JackFrost: why are you anti-snap btw? My own concerns are that those self contained volumes tend to get scattered with different users of a large server machines in an academic setup , or maybe I'm missing something. Clearly the IoT use case is indeed well defined.
<tsimonq2> They're hard to package.
<gQuigs> tsimonq2: as for downloading it works, with caveats:  seperates.. the Downloads folder for the snap to a snap specific one at ~/snap/firefox/common/Downloads
<tsimonq2> gQuigs: Uff.
<JackFrost> sivang: There's a few reasons, I never actually wrote them down though.
<gQuigs> and it won't let you open most apps directly from Firefox - have to open the folder first, I'm guessing that's part of the sandboxing..
<sivang> JackFrost: I just feel they're well suited for embedded development (which I have extensive experience in) and not too much further, under the assumption that having entire system comprised out of them won't be a burden on the process containerment Kerlen mechanism (e.g. core system components, trusted and delivered as a bundle should probably not be concenred with being sandboxed / contained)
<sivang> *Kernel
<gQuigs> sivang: " self contained volumes tend to get scattered with different users"  I don't understand that.   more users shouldn't mean more snap "volumes", just more snaps would do that
<sivang> gQuigs: so with Mac administration at a university, people downloaded duplicates of MacOS's .img volumes for the same apps (incl. academic software servers and cmd line utils) at different accounts, can this happen with snaps?
<sivang> s/.img/.dmg/
<gQuigs> sivang: I don't believe so;  give them a try - they don't bite - promise.  And if you really don't like them you can always purge snapd
<sivang> gQuigs: are they easier to create to distribute your own software than deb packages?
<tsimonq2> I personally say "no" but YMMV.
<sarnold> the last time I put a snap together I had it built from scratch in about ten minutes; I haven't been brave enough to try packaging a deb from scratch yet :)
<sivang> tsimonq2: can provide specific example?
<tsimonq2> sarnold: Takes about the same time. :)
<tsimonq2> :P
<tsimonq2> sivang: Confinement was tricky last time I tried it.
<sarnold> tsimonq2: heh :)
<tsimonq2> I would encourage you to try it yourself.
<gQuigs> sivang: depends on what you are trying to snap..
<sivang> sarnold: well, with debhelper things can be just as quick, and that old what-you-call it system that does 10kg of magic with just a few .mk includes.. CDBS?
<tsimonq2> gQuigs: +1
<tsimonq2> sivang: Eew.
<sarnold> sivang: I think modern debhelper does much the same with less cursing :)
<sivang> python software, services and Qt/QML apps?
<sivang> sarnold: I had hope it to become so one day last time I've visited this channel as a `main` uploader :)
<sivang> *hoped
<sarnold> hehe
<gQuigs> I snapped a python program almost instantly (cause it was written right for pip)..  and one I wrote myself that does more complicated things - I'm still working on
<JackFrost> sarnold: And less breaking with dh compat 11+
<tsimonq2> Speaking of that, Disco users can enjoy debhelper 12 as of today. :)
<sivang> gQuigs: can evaulate something like https://github.com/sivang/laten-fw ?
<gQuigs> sivang: https://docs.snapcraft.io/creating-a-snap/6799
<JackFrost> I'm not sure about snap, but thanks to aptly, reprepro, mini-dinstall you can have your own private repo for the packages you create too.
<sivang> JackFrost: reprepo FTW!
<sivang> tsimonq2: wawo debhelper 12.. It's been too much time since I created a package for Ubuntu :p
<gQuigs> sivang: worth a shot - https://docs.snapcraft.io/python-apps/6741  I'm far far far from  snap packaging expert..
<gQuigs> #snapcraft might be of more help
<sivang> k, cool, thanks guys (or gals if any are around)
<sivang> Oh my, 20 minutes are a lot these days :p
#ubuntu-devel 2019-01-12
<JackFrost> sarnold: Hope I didn't throw y'all off on CVE-2019-5882.
<ubottu> Irssi 1.1.x before 1.1.2 has a use after free when hidden lines are expired from the scroll buffer. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5882)
<sivang> re all
<JackFrost> Howdy.
<sivang> hey JackFrost , I watched some videos from Canonical regarding snappy further, do you happen to know what's the offering about snappy in the cloud about?
<JackFrost> Nope, sorry.
 * sivang wonders, if he's using Ubuntu 18.10 or Digital Ocean or AWS, is he using snappy Ubuntu Core?
 * sivang is also concerend that if there's no central authority to distribute apps and packages (is there a qa process of any sorts?) the malware issue as is with other similar democratic software distribution platforms; https://www.omgubuntu.co.uk/2018/05/ubuntu-snap-malware
<mymedia> During the past year, only three bugs against Ubuntu backports project were closed. Any idea why so few?
<mymedia> https://bugs.launchpad.net/ubp/+bugs?field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&orderby=-date_last_updated&start=0
<tsimonq2> teward: ^
<teward> Laney: ^ you're best equipped to answer htat
<teward> tsimonq2: Laney's probably the better PoC for Backports related questions right now
#ubuntu-devel 2019-01-13
<Laney> teward: You could have done. :-)
<Laney> mymedia: Nobody's really working on it at the minute, but there's some moves to get it going again
<JackFrost> Would most certainly be nice to get official backports for things I backport anyway, debhelper (compat 12) is one that comes to mind.
<mymedia> Laney, I'm glad to hear that the practice of backports will be resumed. :-)
<mymedia> (if this is really so)
<JackFrost> mymedia: Thanks for maintaining telegram.
<rcm888> hi! What tool to use for linux cloning to dissim hardware? (no proprietary drivers installed)
<Faux> It'll probably just work. Run the rescue stuff after you've installed if you don't know how to use update-grub and update-initramfs. Also, wrong channel, ask #ubuntu.
<teward> Laney: yeah, I could have, except, by that point I was, well, *drinking*
<teward> 'twas beer o'clock :p
#ubuntu-devel 2020-01-06
<danboid> Is Ubuntu Server 20.04 going to support installing to ZFS RAID-Z2?
<doko> https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20191220-focal-focal.html
<doko> ginggs, tumbleweed: some more unexpected py2-removals
<cjwatson> brlin: glibc's libraries specifically support being executed for various reasons - you can execute that particular one and get things like feature information
<brlin> cjwatson: Thanks for the info.
<cpaelzer> jamespage: hiho, about openvsiwtch I wanted to ask how we should order uploads
<cpaelzer> as we discussed in december DPDK 19.11 needs OVS 2.13
<jamespage> cpaelzer: morning
<cpaelzer> and happy new year!
<cpaelzer> you said you'd be ok to carve a 2.13 from git into focal
<cpaelzer> which would allow me to get DPDK 19.11 in as-is
<cpaelzer> and we can later on move to 2.13 final once available
<cpaelzer> I was now wondering how we'd want to order things
<cpaelzer> should I get DPDK 19.11 into focal-proposed first
<jamespage> cpaelzer: right I remember
<jamespage> I can work on that today/this week
<cpaelzer> or would you prefer trying to build the new OVS against the former 18.11 first
<jamespage> let me generate a new snapshot
<cpaelzer> ok, thanks for looking into it jamespage
<cpaelzer> once from your testing you know if you prefer OVS or DPDK to hit focal-proposed first let me know
<jamespage> I suspect I'll have to deal with the OVN/OVS splitout at the same time
<cpaelzer> ok, so you'll need some more time than "update & upload" with it anyway
<cpaelzer> jamespage: I'll leave it with you then and you let me know when you want the new DODK synced then ok?
<jamespage> yep fine with me
<cpaelzer> rather DPDK
<cpaelzer> great thank you jamespage
<jamespage> cpaelzer: might need the DPDK upload first - can you drop a 19.11 release into https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3694/+packages for me?
<cpaelzer> yes jamespage
<jamespage> ta
<cpaelzer> jamespage: uploaded - last build was ~3 weeks ago, lets see if it still works fine
<jamespage> cpaelzer: needs a new dep - libbpf-dev
<cpaelzer> oh yeah the kernel team still didn't get that one resolved
<cpaelzer> :-/
<cpaelzer> easily done ...
<cpaelzer> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836708 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826410 if you are interested
<ubottu> Launchpad bug 1836708 in linux (Ubuntu Focal) "Please package libbpf (which is done out of the kernel src) in Debian [for 19.10]" [High,Triaged]
<ubottu> Launchpad bug 1836708 in linux (Ubuntu Focal) "duplicate for #1826410 Please package libbpf (which is done out of the kernel src) in Debian [for 19.10]" [High,Triaged]
<ginggs> i just uploaded https://launchpad.net/ubuntu/+source/file/1:5.37-6ubuntu1 to prevent autosync of 1:5.38-2
<ginggs> see debian bug #948269
<ubottu> Debian bug 948269 in file "file: misdetection of shared libraries as statically linked - breaks dh_shlibdeps" [Grave,Open] http://bugs.debian.org/948269
<cpaelzer> jamespage: new version uploaded
<jamespage> ta
<cpaelzer> jamespage: IIRC there was something else that we needed to disable but I fail to remember which exactly
<cpaelzer> but if it FTBFS again it should be another easy one
 * cpaelzer checks his stale branches to remember
<cpaelzer> jamespage: it failed again sorry, I'm rather sure to have something working shortly ...
<cpaelzer> the one now is more interesting, reported around texlive-latex-extra but not showing up in a sbuild focal-proposed build of today
<Laney> ginggs: nice one
<Laney> fun place for a bug
<jamespage> fnordahl: hey - did you pickup any information at OVN/OVS con about alignment of versioning between OVS and OVN
<jamespage> the OVN build requires a build OVS source tree to compile/test
<jamespage> and I'm just considering the best way todo that
<jamespage> thinking about and openvswitch-src:all package that provides the OVS source code in distro, that the OVN build can use to build itself
<jamespage> but I don't understand the versioning just yet
<fnordahl> jamespage: they are planning on a year+month release naming for OVN with a three month release cadence, the first probably being 20.03.  There was also talk about supporting building OVN against multiple versions of OVS and making it pussible to build against a -dev type package instead of a whole source tree.
<fnordahl> jamespage: I'll try to get a pulse on how it's progressing
<danboid> Hi didrocks! Does the 20.04 installer have any more ZFS options yet eg RAID Z2?
<didrocks> danboid: hey! No, it has a slightly different partitionning scheme, but nothing like this nor planned to. We will work more on the automated snapshots, rollbacks side of thing for this cycle + command line options
<danboid> didrocks, So are you saying that 20.04 (server) will still only support using one whole disk for ZFS installs?
<didrocks> danboid: I don't think the server will have the ZFS option yet, we only added it as experimental on the ubiquity (desktop) installer for now
<danboid> Oh that's a shame. I was expecting ZFS support in Ubuntu server 20.04
<didrocks> post-install, people can add mirrors (manually) for now though, I think RAID Z2 is the same but haven't tried
<didrocks> better to have thing strongly tested before pushing experimental things that are not tested. And this is even more true for a LTS
<danboid> Sounds like proxmox ve gets another year or two ruling the Linux ZFS roost then
<cpaelzer> coreycb: I saw you update 1770295 have you seen reproduce this issue?
<coreycb> cpaelzer: no, I haven't. I was mainly just keeping the cloud archive triage in line with the ubuntu triage.
<cpaelzer> ok, I ahve asked if "openstack people have seen or reproduced that" on the bug in comment #5
<cpaelzer> coreycb: if you have the minute to do so even a "no we haven't" documented on the bug would be useful
<cpaelzer> as it would confirm my "this is odd, prio low" triage
<ahasenack> roaksoax: hi, good morning/afternoon. Just saw this commit to debian's bind9 package fly past: https://salsa.debian.org/dns-team/bind9/commit/e6e079c0fa9689aff6eb373ddd997adf3e22e849
<ahasenack> they removed the apport hook which has you as the author, because it's gpl
<ahasenack> roaksoax: I'm wondering how it could be relicensed. If it was writte while you were working for canonical, then we could change the copyright I think, but if it was done on your spare time, then it's different
<cpaelzer> rafaeldtinoco: if you give the ipxe change a review and if possible a test and chime in on the debian MR that would be great
<rafaeldtinoco> ok
<cpaelzer> I wanted to take the change (if it was proven to be ok) for us on this cycles merge if debian hasn't done so in time
<cpaelzer> so whatever the outcome is updating both MRs is probably a good thing (jsut copy and paste will do)
<rafaeldtinoco> makes sense
<rafaeldtinoco> ok
<rafaeldtinoco> tks
<cpaelzer> your ping on the debain MR might revive that
<cpaelzer> and the one on our side helps me to trust the change on the qemu merge
<cpaelzer> on that topci, I know that the maintainer hasn't seen my Mrs so I'll ping him
<ahasenack> cpaelzer: hm, I think the python transition might have bitten me just now
<ahasenack> haproxy won't build anymore
<ahasenack> sbuild-build-depends-haproxy-dummy : Depends: python but it is not going to be installed
<ahasenack>                                       Depends: python-mako but it is not going to be installed
<ahasenack> yeah, "python" is uninstallable
<cpaelzer> ahasenack: yes doko sent a mail a few hours ago
<doko> s/python/python2/g
<cpaelzer> jamespage: I forgot to ping you - you have dpdk - 19.11-2~ubuntu1~ppa3 in your PPA
<doko> ahasenack: please fix, or I'll look at that specific one as a priority
<cpaelzer> it was blocked by the python2->3 transition and for now I worked around that by disabling docs as that was the only tihng it was needed for
<cpaelzer> doko: while being at the topic, let me ask for a python2/3 best practise
<cpaelzer> doko: texlive-latex-extra has a Dependency line containing this "python, python3"
<cpaelzer> which makes it fail to install
<cpaelzer> => https://paste.ubuntu.com/p/mynQxT2Hh2/
<doko> the debian maintainer said that it's not completely ported, so that should be python2, python3 instead
<cpaelzer> yeah I have read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938656
<ubottu> Debian bug 938656 in src:texlive-extra "texlive-extra: Python2 removal in sid/bullseye" [Normal,Open]
<cpaelzer> doko: so "python2, python3" is what you'd expect to be in this Dependency line then?
<doko> yes
<cpaelzer> thank you
<doko> and make sure that you have the python2 shebangs as well
<cpaelzer> not sure I'll do a change, but I'll take a look and ping the bug for sure to keep it alive
<cpaelzer> chances are the shebang changes would have to be an all the reverse-deps of texlive-extra
<jamespage> cpaelzer: ta
<jamespage> just working on some OVN bits in the OVS package for the split out
<cpaelzer> rafaeldtinoco: 1809682 1733889 came up on triage as "not touched for 180 days"
<cpaelzer> rafaeldtinoco: are those two ok with you or do we need to do anything from a team perspective?
<rafaeldtinoco> cpaelzer: checking
<rafaeldtinoco> cpaelzer: they're part of the cleanup phase after merges are finished. I got them.. hopefully I can start cleaning up and documenting this week, after all HA merges are finished (at least this 1st phase)
<roaksoax> ahasenack: howdy! I have no claim over the license, feel free to relicensed if needed
<ahasenack> roaksoax: can I email you at that address in the header? Is that still you?
<roaksoax> ahasenack: that should still be me indeed
<doko> juliank: any idea why that fails now? https://launchpadlibrarian.net/459395331/buildlog_ubuntu-focal-s390x.protobuf_3.6.1.3-2ubuntu2_BUILDING.txt.gz
<juliank> heh, what's protobuf doing with apt-file?
<juliank> doko: oh, that's ruby gem2deb
<doko> cpaelzer: texlive-extra uploaded
<juliank> I'm not sure what's going on but this seems like a bug in gem2deb or dh_ruby<
<roaksoax> 3xit
<deadrom> hi. where is the place for hwe bugs?
<ahasenack> deadrom: https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+filebug I believe
<ahasenack> deadrom: or do you mean "hardware" bugs?
<ahasenack> the link I pasted is for bugs against the hwe (hardware enablement) kernel
<deadrom> HardWare Enablement
<deadrom> why couldn't I get there myself? I went in circles in Launchpad
<deadrom> told all sorts of how to report a bug, but never actually how
<gQuigs> deadrom: usually recommended to use apport to file a bug,  apport (generally) will be able to get it to the right package given what you have installed
<doko> coreycb: please could you have a look at networkx/python-networkx? currently creates a lot of componet mismatches, and you're the last uploader, sorry ;p
<coreycb> doko: sure I'll take a look
<rafajafar> heyyy is there a problem is 18.04.3-74 because I just updated and now my computer freezes. If I go to 18.04.3-72 everything works again.
#ubuntu-devel 2020-01-07
<JackFrost> doko: Hi!  FWIW, apt-offline seems to no longer be seeded, re: LP 1848755.  Looks like it got removed from Debian testing.
<ubottu> Launchpad bug 1848755 in apt-offline (Debian) "xubuntu and ubuntustudio should not depend on apt-offline (or fix it)" [Unknown,Confirmed] https://launchpad.net/bugs/1848755
<valorie> interesting
<JackFrost> Hmm?
<valorie> that it was removed, yet still is depended upon
<JackFrost> As noted, Xubuntu and Ubuntu Studio removed it from their seeds a while ago.  In Debian it was dropped from testing due to it..not working at all! :P
<JackFrost> Interestingly, a couple of the bugs are fixed in git.
<valorie> I should have read the bug report before responding
<Eickmeyer> valorie: bluesabre and I took care of it a couple months ago.
<valorie> :-)
<doko> systemd stopped building libudev-dev,however libpci-dev still depends on it. what is the replacement?
<doko> xnox: ^^^
<seb128> doko, do you know if that's something that needs fixing or to be badtested?
<seb128> Depends: python3-all:i386 but it is not going to be installed
<seb128> (http://autopkgtest.ubuntu.com/packages/b/brotli/focal/i386)
<seb128> vorlon, ^
<doko> I don't know, that's python3
<doko> there are currently a lot of unistallable packages because python got dropped, but that's python2
<doko> looks like systemd 244.1-0ubuntu1 was removed in proposed
<cpaelzer> kanashiro: you merged smartmontools last and the only delta we had left was one to let the service run even on diskless systems
<cpaelzer> kanashiro: this came up in Debian as well later in the form of bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862908
<ubottu> Debian bug 862908 in smartmontools "smartd fails to start when no disks are present" [Normal,Fixed]
<cpaelzer> Their solution is to change the default to an option of the daemon that won't quit without disks
<cpaelzer> See https://salsa.debian.org/debian/smartmontools/blob/master/debian/patches/default_never-quit.patch
<cpaelzer> that seems even better than the systemd change we carry
<cpaelzer> kanashiro: I came to look at it for https://salsa.debian.org/debian/smartmontools/blob/master/debian/patches/default_never-quit.patch
<cpaelzer> kanashiro: I'd ask you to check as well if you agree that this could be a sync
<cpaelzer> kanashiro: if so let me know and state so on the bug
<santa_> ddstreet: hi, since some time ago I have been suffering a bug in network-manager and I have a patch for it, so I'm wondering if you would sponsor the upload (because you did the last n-m upload)
<santa_> https://launchpad.net/~panfaust/+archive/ubuntu/vpn-pass/+packages
<santa_> â as you can see I have a modified package for focal, but I believe this bug also affects eoan (at least)
<santa_> so maybe we could get the patch into focal ann then SRU it for affected stable versions? what do you think?
<santa_> s/ann/and/
<ddstreet> santa_ is there a lp bug for that?  if it needs to go into eoan too, it'll need a bug to track that
<santa_> ddstreet: I haven't checked yet, if there isn't we can always open one, let me check...
<santa_> ddstreet: yep: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1858092
<ubottu> Launchpad bug 1858092 in network-manager (Ubuntu) "Network Manager not saving OpenVPN password" [Undecided,New]
<doko> mitya57: please could you have a look at https://launchpad.net/ubuntu/+source/python-docutils/0.15.2+dfsg-1build1 ?
<ddstreet> santa_ great!  can you attach your debdiff to that bug, i'll review/upload from that
<santa_> ddstreet: ack, thank you for your time
<xnox> doko:  que?! libudev-dev            | 244-3ubuntu1       | focal                                 | amd64, arm64, armhf, i386, ppc64el, s390x
<xnox> doko:  and yes, 244.1 was removed due to bugs. You upgraded with proposed, and now must downgrade?
<xnox> doko:  i wish my chroots would have -proposed enabled; but when i refresh the chroots they'd only use -release/-updates/-security to "dist-upgrade"
<cpaelzer> doko: your fix to texlive-latex-extra worked for the package itself
<cpaelzer> but it still depends on texlive-pictures
<cpaelzer> which then has the python dependency
<cpaelzer> so one down, one (many) more to go
<cpaelzer> src:texlive-base that would be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938655 then I guess
<ubottu> Debian bug 938655 in src:texlive-base "texlive-base: Python2 removal in sid/bullseye" [Normal,Open]
<cpaelzer> on that one there was no reply
<cpaelzer> And the old depends line is not py2/py3 as on the -extra package - it is "Depends: tex-common (>= 6), python, texlive-base (>= 2017.20170628), texlive-binaries (>= 2017.20170524.44437), texlive-latex-recommended (>= 2017.20170628)"
<cpaelzer> ahasenack: ^^ FYI
<cpaelzer> since you asked about texlive
<kanashiro> cpaelzer, re smartmontools: I tried the Debian's patch here and it worked fine, agreed that we can sync it now on
<cpaelzer> thank you kanashiro
<cpaelzer> just say the same on the bug
<cpaelzer> I'll do trigger the sync
<cpaelzer> thanks for the second pair of eyes on this
<kanashiro> cpaelzer, do you mean the Debian bug?
<cpaelzer> kanashiro: no on https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1858121
<ubottu> Launchpad bug 1858121 in smartmontools (Ubuntu) "Please re-add update-smart-drivedb" [Undecided,Confirmed]
<kanashiro> ah ok :)
<cpaelzer> sorry, I still need to fully surface from my big endian debugging - I might appear more confused than usual
<cpaelzer> "even more" :-)
<gpiccoli> o/ xnox, sorry to annoy. Can you help getting a force-badtest merged , in order to get a pkg released?
<gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu/+merge/377160
<gpiccoli> lukasz helped me last time, but seems he's out. Or if you can point another person to help, also pretty useful. Tnx in advance!
<kanashiro> cpaelzer, re nut: do you think we should try to forward this to Debian? https://git.launchpad.net/ubuntu/+source/nut/commit/?id=eae756c108e276023be2c714c630ea27854f51da
 * cpaelzer reading
<cpaelzer> kanashiro: Debian doesn't use -O3 so they won't need it
<cpaelzer> kanashiro: this is one of the cases that can't hurt to forward, but not have too much expectations on
<cpaelzer> as it depends lot on the mood of the receiving maintainer
<kanashiro> cpaelzer, hum, good catch. Since this is just part of our delta I'll keep it as is for now
<cpaelzer> kanashiro: if you think it was unclear up to now maybe modify the commit message to avoid the same thoughts next time?
<cpaelzer> jamespage: thanks to doko dpdk 19.11 would now build fine in Focal (even with docs) - how is openvswitch doing?
<cpaelzer> jamespage: have you decided if you want DPDK 19.11 in focal first - since you wanted it in the PPA first I'd assume so
<jamespage> cpaelzer: getting there - just working on the new ovn package as the openvswitch update drops all of the ovn binaries
<jamespage> cpaelzer: DPDK can go to focal first please
<cpaelzer> ok, I'll have a call with Debian DPDK on Thu to check if we need anything else before - then I'll most likely upload to f-proposed
<cpaelzer> jamespage: let me know if you need any other timing
<kanashiro> cpaelzer, good idea, I'll just add this clarification regarding the build flag and Debian
<seb128> doko, do you plan to forward those python diffs you are uploading to Debian?
<doko> once the testing frameworks work again
<seb128> testing frameworks? what is that?
<doko> pytest & co
<seb128> well, that's not in the path of sending those ' Depend on python2-dbg instead of python-dbg.' changes back, is it?
<doko> seb128: please could you stop harassing me? If I don't fix the testing frameworks, I get complaints from you about that instead. just stop.
<seb128> doko, sorry you feel harassed, I was just asking a question but I will stop there
<seb128> doko, those deltas you are adding have a maintainance cost and I'm trying to avoid that, which was why I asked the question
<seb128> doko, who would you recommend I ask those questions to instead of you?
<doko> seb128: I said I will forward them. why do you continue?
<seb128> continue?
<doko> <seb128> well, that's not in the path of sending those ' Depend on python2-dbg instead of python-dbg.' changes back, is it?
<seb128> I failed to understand how pytest block the dbg depends forwarding
<doko> it's on my list. you don't define the priority on that list. if you want, please escalate
<doko> time, just time
<seb128> but maybe I just overlook something
<seb128> k, fair
<seb128> thx
<Laney> LocutusOfBorg: did you look into pcsc-lite stuck in proposed yet?
<xnox> gpiccoli:  i'm not release-team / sru-team so cannot help you with merging hints. Sorry.
<xnox> gpiccoli:  lukasz is still on holidays at the moment
<gpiccoli> no problem xnox, thanks for the information! Anybody else that can help me besides Lukasz?
<cpaelzer> james_page: my argus-eyes have spotted OVN building - hehe
<cousin_luigi> Greetings.
<cousin_luigi> What's the ubuntu equivalent of https://sources.debian.org ?
<mitya57> doko: I will fix it.
<rbasak> cousin_luigi: launchpad.net has the sources available. The ability to browse the source tree without downloading is limited to a subset of packages via code.launchpad.net. That's a work in progress.
<cousin_luigi> rbasak: I see. Is this perchance a consequence of importing packages from debian?
<rbasak> cousin_luigi: I'm not sure what you mean. Is what a consequence of importing packages from Debian?
<cousin_luigi> rbasak: I understand that some (many?) packages come from debian. Are the two things related somehow?
<cousin_luigi> But then, I'm no longer up to date with these matters.
<rbasak> I still don't follow, sorry.
<cousin_luigi> nm, it's not important.
<cousin_luigi> Anyway I have my answer. Thanks & bbl.
<rbasak> I mean Ubuntu being a derivative of Debian, almost everything in Ubuntu is related to Debian somehow :)
<rbasak> sources.debian.net is a separate service that derives from the Debian source package publication machinery
<rbasak> Ubuntu has its own machinery (Launchpad) so an equivalent of sources.debian.net would need to be separately implemented, and nobody has ever done this.
<vorlon> seb128, doko: brotli's autopkgtest tests a python3 module, which means it won't be cross-installable or cross-testable; I'll add it to the permanent blacklist
<seb128> vorlon, thx
<LocutusOfBorg> Laney, fixing
<Laney> â¥
<seb128> vorlon, what do you do exactly to trigger those emails without content on focal-changes@lists? is that package copies to rescure i386 binaries in some way?
<LocutusOfBorg> fixed btw
<seb128> santa_, hey, I updated n-m to 2.20.8 in focal, I think that includes the fix you mentioned earlier, still could be good to SRU to 19.10 if someone is interested in that and want to do the SRU paperwork and prepare an upload
<santa_> seb128: that's great, thanks! I think that should have the fix, I will re-test once the package reaches the mirrors. I could prepare a package for eoan SRU as soon as I have time
<seb128> santa_, thx
<vorlon> seb128: yes, when I do a copy with binaries to the same archive (to resuscitate i386 binaries where needed), that's how it shows on focal-changes
<seb128> vorlon, ok, I guessed so but wanted to make sure, thanks :-)
<Bluefoxicy> I see the Blueprints feature is no longer active on launchpad
<Bluefoxicy> I had wanted to suggest an Ubuntu VDI blueprint, as mentioned in bug #1654864 concerning the Weston RDP compositor backend
<ubottu> bug 1654864 in weston (Debian) "weston build with rdp backend" [Unknown,New] https://launchpad.net/bugs/1654864
<Bluefoxicy> Current display managers will recognize a user logging in and switch to their session on the console
<Bluefoxicy> as Weston can switch back-ends and keep the same session open (e.g. display -> compositor -> session -> client application), it's possible for a server on port 3339 to expose a display manager over RDP, which then when logged into switches the compositor to connect to the user's existing session
<Bluefoxicy> thus remote access
<Bluefoxicy> Likewise, rather than 250 desktops drawing 100 watts (65-200 watts when idle, 200W or more when in use), i.e. 25kW, a single 1,000 watt server can support 250 user sessions.
<Bluefoxicy> That means cutting costs, but also the environmental footprint
<Bluefoxicy> Thin clients are often built from Raspberry Pi boards, idling at under 5 watts, and reaching 15W in use.
<Bluefoxicy> That does add 3.75kW, so this hypothetically converts 25kW to around 5kW, a 5:1 energy savings; and those small board thin-clients are less manufacturing, shipping, and eventual waste.
<JanC> why not just use the RPi as desktops instead?  :P
<JanC> (or similar)
<ahasenack> rafaeldtinoco: testsuite-python passed on an unprivileged lxd
<ahasenack> rafaeldtinoco: https://pastebin.ubuntu.com/p/tbsWWZdbMg/
 * ahasenack comments on the mp
<rafaeldtinoco> tks ahasenack
<ahasenack> rafaeldtinoco: that being said, I had a few odd (random?) errors that I can't explain, like a missing dep when running the test once, which now resolved. Maybe related to the python churn going on
<rafaeldtinoco> weird.. I had with the python tests
<rafaeldtinoco> but not during build time
<ahasenack> it was during the tests
<ahasenack> I didn't rebuild it (I used autopkgtest with -B)
<Bluefoxicy> @JanC:  Slower storage, less RAM, more management (a default, minimal installation image can be wiped at any time), lower access (you can access your VDI desktop from anywhere)
<udevbot> Error: "JanC:" is not a valid command.
<Bluefoxicy> JanC: I tried running an Ubuntu VM from LiveCD in 1GB RAM.  It kept giving me a black screen as the OOM kicked in. <_<
<Bluefoxicy> New RPI is $40 1GB, $86 4GB.
<JanC> Live-CD needs lots of RAM for decompressing the image
<JanC> I'm running an older version of Ubuntu (still with Compiz/Unity) on an actual system with 1GiB RAM...
 * ogra points to #ltsp .. 
<JanC> and it could be some other hardware than RPi
<ogra> https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi
<JanC> LTSP & similar tin client solutions are sometimes useful for central management & such, but I really doubt you do 5:1 energy savings if you take all the hardware used into account
<ogra> well, he was talking about thin clients aboe ... but yeah, i agree that you just move the power usage into the server room with it
<ogra> (and into the various high speed switches that you need if having a bigger setup)
<JanC> not to mention most systems used as thin clients could be used as a low-end desktop on their own
<rafaeldtinoco> ahasenack: replied to your review with a comment, will act based on your reply (fyio)
<JanC> so you actually increase the energy usage
<mitya57> doko: https://tracker.debian.org/news/1092153/accepted-python-docutils-0152dfsg-2-source-into-unstable/
<gpiccoli> vorlon, sorry to annoy, but given Lukasz is out, can you help getting a force-badtest merged? https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu/+merge/377160
<vorlon> gpiccoli: looks like the mp has the wrong target
<gpiccoli> vorlon, or I messed up...it shows a giant diff, but what we need is a single line, a force-badtest to makedumpfile
<gpiccoli> basically this thing vorlon : https://bazaar.launchpad.net/~gpiccoli/britney/hints-ubuntu/revision/4319
<vorlon> gpiccoli: merged (with adjustment - we shouldn't drop the hint for the version currently in the release pocket)
<gpiccoli> oh, I wasn't aware of that, thanks a lot vorlon! I'll follow this procedure in the future
<gpiccoli> now vorlon, abusing your kindness, what's the next step getting this released to -updates?
<gpiccoli> *for getting
<gpiccoli> we have another set of relevant fixes to makedumpfile, so I'd like to move this to submit another package version to -proposed the sooner I can
<doko> mitya57: thanks, but the rules file still calls python, not python2
<mitya57> doko: Oh. Can you fix this with Ubuntu delta for now?
<doko> sure, merging
<mitya57> I can't do another Debian upload right now but I will apply this in git for the next one.
<doko> mitya57: https://launchpadlibrarian.net/459588980/buildlog_ubuntu-focal-amd64.python-docutils_0.15.2+dfsg-2ubuntu1_BUILDING.txt.gz
<Bluefoxicy> ogra: a thousand watt server can handle around 250 moderate-use users at once. PCs idle at 65W-200W and generally consume 200W during use.
<Bluefoxicy> JanC:  the savings is about 10kg/hr of CO2 if you assume the RPI is running at 15W consumption the whole way.
<Bluefoxicy> ogra: as to high-speed switches, running fairly-intensive use over RDP at 32 bits is 120kbit/s peak, under 100kbit/s typical, 250 = 25 Mbit/s
<Bluefoxicy> and modern, low-power switches with 10 microsecond switching can run on 48V PoE at a few dozen watts at most.
<Bluefoxicy> Those switches can carry 10GbE
<Bluefoxicy> JanC:  BTW I can put about 800MB into a tmpfs and the livecd can run just fine. With no tmpfs it still crashed.
<JanC> Bluefoxicy: 250 RPis will always use less than 250 RPis + 1 (or more) servers
<JanC> (or whatever else you use as a low-power desktop instead)
<Bluefoxicy> JanC: that's true.  The problem is 250 desktops on 1 server will have more resources and burst processing power than 1 RPi
<JanC> in reality, I've never seen a system like that being usable for anything but basic use
<Bluefoxicy> At my job, I spend all day with powerpoint, word, chrome, Microsoft Teams, outlook, a file explorer, and ssh clients.
<Bluefoxicy> Few office workers are actually compiling code and rendering 3D video all day.
<JanC> sure, which is why they could just run a browser on any low-power machine
<Bluefoxicy> JanC: you're basically discounting that burst resource usage is high (e.g. RPi can drag on for 30-40 seconds trying to open Chrome, then take a long time to render a Web page) while ongoing resource usage is low
<Bluefoxicy> yet the hardware to handle high burst usage consumes 10-20 times as much power AT IDLE than a thin client
<Odd_Bloke> Bluefoxicy: JanC: This could probably migrate to #ubuntu-offtopic at this point. :)
<mitya57> doko: weird. I will look tomorrow.
<doko> ta
#ubuntu-devel 2020-01-08
<seb128> vorlon, network-manager is blocked in proposed due to missing wpasupplicant on i386, do you have an opinion on what's the best resolution for that one?
<seb128> vorlon, also that depends isn't new, did we delete binaries that had rdepends in the release pocket?
<seb128> and do we have a report of things that in a such buggy state today?
<Laney> xnox: have you seen the livefs build failures?
<xnox> Laney:  not yet... which ones? desktop?
<Laney> yup
<Laney> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/focal/ubuntu/
<xnox> No kernel output for oem! ?!
<xnox> aha
<xnox> Laney:  Wimpress: apw: seems like we don't have a real linux-oem in focal any more, replaced by dummy transitional package pointing at ga kernel.
<xnox> Description: Depends on the generic kernel image and headers (dummy transitional packages)
<xnox> apw:  what should I be installing in the focal builds to get a real linux-oem kernel? or does that not exist yet for v5.4?
<xnox> ah
<xnox> i think i need linux-oem-20.04 but it's not in focal-release yet
<xnox> Laney:  i guess i should drop installing oem kernel for now?!
<tjaalton> right, should be in proposed still
<jibel> xnox, there is a similar problem on flavors too with signed kernel
<jibel> E: Unable to locate package linux-signed-generic
<xnox> tjaalton:  are all autopkgtests need retrying? i've retried just the linux-oem-5.4 itself, to see if it will work or not.
<Laney> yeah maybe we can get it to move out to the release and then use that
<xnox> tjaalton:  or does the kernel team adt matrix / triggers need to learn about new metapackages -> flavour mappings?
<xnox> Laney:  but it is sad that images are broken.
<Laney> it is
<xnox> tjaalton:  apw: in the autopkgtests, setup commands are trying to install --setup-commands 'apt-get install -y linux-image-oem-5.4 linux-headers-oem-5.4 || apt-get install -y linux-image-generic-oem-5.4 linux-headers-generic-oem-5.4'
<xnox> which is wrong, as it should be linux-image-oem-20.04
<xnox> however i am guessing that autopkgtest code is not smart enough to do that.
<tjaalton> xnox: there's something wrong with the seed
<tjaalton> teething problems
<xnox> tjaalton:  we do have something special in autopkgtest code when "linux-meta*" is a trigger
<Laney> it comes from here https://git.launchpad.net/autopkgtest-cloud/tree/worker/worker#n460
<xnox> ooh oooh
<xnox> Laney:  we want the same ubuntu_versions treatment for -oem just like for -hwe
<tjaalton> yes
<Laney> usually someone (one specific someone) from the kernel team gives merge requests to make that block do the right thing :-)
<tjaalton> nick starts with an a, ends with a w? :P
<Laney> yes indeed
<Laney> but anyone who understands it could do it I guess, and I will review that
<tjaalton> I wonder if the focal master kernel needs some adjustment as well
<tjaalton> at least adt test matrix isn't happy
<tjaalton> though the binary names haven't changed there aiui
<tjaalton> so maybe not
<tjaalton> anyway, how to send a merge req?
<tjaalton> or just a diff?
<Laney> https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+ref/master
<xnox> tjaalton:  it's autopkgtest-cloud project, git clone lp:autopkgtest-cloud & submit lp pr?
<Laney> should be MRable as normal
<tjaalton> or just copy the block about hwe and replace hwe/oem
<tjaalton> though it can't break the earlier oem kernel testing, mmh..
<tjaalton> seems I've never done a merge req on lp
<tjaalton> pushed mine to lp, now what?
<Laney> haha
<Laney> just give me a link to the branch, I'll have a look
<tjaalton> https://code.launchpad.net/~tjaalton/+git/autopkgtest-cloud/+ref/fix-oem
<tjaalton> selecting propose for merging there and giving the master info it just says they can't be merged
<tjaalton> the doc says the ui is rough, that's all..
<Laney> don't worry about it
<Laney> tjaalton: do we have to worry about oem-osp1?
<tjaalton> gah :)
<tjaalton> flavor.startswith('-oem-5'): :P
<tjaalton> osp1 is dead in 6mo
<Laney> also wait
<Laney> this is going to result in linux-image-oem-20.04-5.4 isn't it?
<tjaalton> how?
<Laney> flavor is '-oem-5.4'
<tjaalton> yes
<tjaalton> oh
<Laney> In [1]: '-oem-5.4'.replace('-oem-', '-oem-' + '20.04', 1)
<Laney> Out[1]: '-oem-20.045.4'
<tjaalton> right..
<Laney> wouldn't "flavor = '-oem-{}'.format(ubuntu_release)" be right? (I'm not completely sure on the naming scheme, so take that with a pinch of salt)
<tjaalton> how did you try it the last time?
<Laney> I've not, was just reading the code
<Laney> sadly there is no testsuite
<tjaalton> the in/out thing? wrote it by hand? :P
<Laney> that is ipython
<tjaalton> ah
<Laney> but yes I wrote the first line myself :(
<tjaalton> anyway, your suggestion should be right
<tjaalton> Laney: pushed a new version
 * Laney looks
<tjaalton> Laney: what's the verdict?
<Laney> tjaalton: Had to fix up startwith() since it doesn't accept a regex, but it's running there now
<Laney> just doing a test run
<tjaalton> oh cool
<Laney> http://autopkgtest.ubuntu.com/running#pkg-adv-17v35x
<Laney> that seemed to work
<Laney> I will retry the rest of them now
<tjaalton> great
<Laney> after these tests results, what else is needed to migrate this kernel?
<tjaalton> I think that's it
<tjaalton> but not sure
<Laney> it's really only the block from ap_w
<Laney> and the tag on bug #1858633
<ubottu> bug 1858633 in Kernel SRU Workflow regression-testing "focal/linux-oem-5.4: 5.4.0-1001.2 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1858633
<Laney> so some workflow stuff I guess
<tjaalton> yeah
<Laney> well, if it could go in, we could unbreak desktop isos which would be nice
<tjaalton> sure thing
<doko> LocutusOfBorg: do you remember why the python-ddt binary package had to be kept?
<doko> coreycb: could you have a look at https://launchpad.net/ubuntu/+source/python-formencode/1.3.0-3ubuntu2/+build/18265750 ? Debian has dropped that b-d
<cpaelzer> kanashiro: nut MP is good, can you upload it already or should I?
<coreycb> doko: sure, will do. sorry been side tracked on non distro things but hopefully can look today.
<LocutusOfBorg> doko reverse-depends -b python-ddt -r eoan
<LocutusOfBorg> would say, not anymore
 * LocutusOfBorg uploads
<LocutusOfBorg> thanks
<ahasenack> cpaelzer: are you aware of "prior art" in amending an apparmor profile just for a test suite? dep8
<cpaelzer> you mean at test time?
<ahasenack> the test is run in a temporary directory, so I'm thinking in adding a rule to /etc/apparmor.d/local/<profile> at test time
<cpaelzer> start test, change + reload profile, test
<ahasenack> yeah
<ahasenack> in this case, as soon as I know the tmpdir name
<cpaelzer> ahasenack: does the package in question even include a local override?
<ahasenack> no
<cpaelzer> ha :-)
<ahasenack> the profile is for another package
<cpaelzer> but does that one have a local include
<cpaelzer> that isn't always the case, hence I'm asking
<ahasenack> it's a package that uses openldap, and runs an openldap server elsewhere where apparmor doesn't like it, just for the test
<cpaelzer> I know of no prior art in dep8 tests
<ahasenack> so the openldap profile doesn't like to have the openldap daemon storing its database and config files in /tmp/tmpXXXX
<cpaelzer> but I've done that manually often for testing
<ahasenack> the other option is to disable apparmor
<cpaelzer> check out https://help.ubuntu.com/community/AppArmor#Reload_one_profile
<ahasenack> for the test
<cpaelzer> and modify the profile as needed wither via a /etc/apparmor.d/local/<profile> if it has an include or just the main profile (it is an ephemeral test env after all)
<Laney> you probably want Restrictions: breaks-testbed for that though :-)
<ahasenack> I would create the local override, it's meant for things like these after all (local customizations)
<ahasenack> the include for local/<profile> is always there
<cpaelzer> ahasenack: ok if it has the include do it and add the Restriction Laney mentioned
<ahasenack> noted
<Laney> (and needs-root if you want to write to /etc)
<ahasenack> indeed
<ahasenack> <cpaelzer> ahasenack: does the package in question even include a local override?
<ahasenack> I thought you meant if a local override file was already shipped with the package
<cpaelzer> ahasenack: that would be done by dh-apparmor in most cases
<ahasenack> our profiles all seem to end with an include, "just in casE"
<cpaelzer> ahasenack: but the main profile needs to have the include statement
<ahasenack>   # Site-specific additions and overrides. See local/README for details.
<ahasenack>   #include <local/usr.sbin.slapd>
<ahasenack> }
<cpaelzer> ahasenack: yeah then this is fine, but not true for all packages
<ahasenack> ok
<ahasenack> it's confusing that # can also indicate a comment :/
<ahasenack> sometimes people have weird ideas about configuration file syntax
<kanashiro> cpaelzer, I still do not have upload rights, could you please sponsor nut for me? I'll follow its migration towards the release pocket
<cpaelzer> kanashiro: done
<ahasenack> weird that only the amd64 build complained about  sbuild-build-depends-krb5-dummy : Depends: python but it is not going to be installed (https://launchpad.net/ubuntu/+source/krb5/1.17-6ubuntu1)
<ahasenack> anyway, I was able to switch that to py3
<cpaelzer> ahasenack: could it have been the arch-indep portion - that usually runs only on amd64
<ahasenack> ah, yes, it's arch-indep
<doko> jamespage: ubuntu-only, packaged by yourself: https://launchpad.net/ubuntu/+source/radosgw-agent/1.2.7-0ubuntu2/+build/18265504
<seb128> rbasak, hey, could you review the pulseaudio/eoan SRU? it's a simple fix for a problem that got quite some users heat (sound output often switching to the hdmi output when not wanted)
<rbasak> Looking
<kanashiro> cpaelzer, thanks!
<doko> xnox: https://launchpadlibrarian.net/456873774/buildlog_ubuntu-focal-amd64.regina-normal_5.1-6build1_BUILDING.txt.gz  some boost/python2 fallout
<rbasak> seb128: is there any possibility of upsetting users relying on the current behaviour?
 * rbasak continues reading
<seb128> rbasak, that's always an option, but the behaviour only changed in 19.10 and is the main complain we get about 19.10 atm
<seb128> we might piss off a few users but the ration should be in favor of the fix
<seb128> option->possibility
<rbasak> seb128: OK that sounds reasonable. But could you document that in Regression Potential please? I've just finished reading the bug, reviewing the patch now.
<seb128> rbasak, description updated
<rbasak> Looks good, thanks!
<rbasak> Accepted
<seb128> rbasak, thanks!
<vorlon> seb128: we should drop the network-manager binary package on i386, since we only really want the libraries and no one will ever install network-manager/i386.  This is reported as an uninstallable in the release pocket here: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt and it was on my list to look at today, but if Desktop wanted to get to it first, I'd refer to
<vorlon> libkate as the best reference implementation
<seb128> vorlon, I plan to merge/update n-m tomorrow, I can look at dropping the i386 binary while I'm at it
<mitya57> doko: https://launchpad.net/ubuntu/+source/python-docutils/0.15.2+dfsg-2ubuntu2
<mitya57> In Debian I will replace python with python3 rather than python2, but I want to wait for the next release first (which is expected soon).
<doko> ta
<doko> xnox: https://launchpad.net/ubuntu/+source/android-tools/5.1.1.r38-1.1ubuntu1   you seem to be involved in Debian too. what's the way forward?
<ahasenack> rbasak: is this something you still want to drive for 20.04? https://bugs.launchpad.net/ubuntu/+source/squid/+bug/1780341
<ubottu> Launchpad bug 1780341 in squid (Ubuntu) "squid should default to more human friendly timestamps" [Undecided,In progress]
<rbasak> ahasenack: I would like it to happen, but it fell down the list :(
<rbasak> I should unassign myself
<ahasenack> yeah, I just saw it because I was about to open a new bug in squid, and saw the list of open bugs
<xnox> doko:  urgh
<jamespage> doko: that can be RM'ed as well - its superceeded by functionality in ceph radosgw
<doko> jamespage: to make sure, you're talking about radosgw-agent?
#ubuntu-devel 2020-01-09
<rlaager> I've prepared an SRU. The procedure says that you need to make sure it's fixed in the development release (which it is) and that the bug status is Fix Released. So I changed it to that. But then later, it says to use In Progress. Apparently I could change it to Fix Released, but now can't change it back to In Progress.
<rlaager> I also can't add distro-version-specific tasks. Can someone set this to In Progress and/or add a Bionic task that's In Progress: https://bugs.launchpad.net/ubuntu/+source/icingaweb2/+bug/1769890
<ubottu> Launchpad bug 1769890 in icingaweb2 (Ubuntu) "Icingaweb2 does not work with PHP 7.2" [Undecided,Fix released]
<cjwatson> rlaager: I've added a bionic task, which you should be able to manipulate
<cjwatson> (I just did the minimal thing and left it with the default status of New)
<rlaager> cjwatson: Thanks, done. I think we're in the desired state now... i.e. waiting for my debdiff to be reviewed by ubuntu-sponsors.
<cjwatson> rlaager: You might want to assign that task to yourself too
<cjwatson> and possibly note that the thing in your last comment is done :)
<rlaager> I hid the comment.
<cjwatson> ack
<tjaalton> xnox: you filed RM on dogtag without any discussion?
<tjaalton> xnox: the reason why it's not in testing or stable is because openjdk-8 will never migrate. and it works just fine with current nss, and supports tls 1.3 via jss
<tarzeau> is there some ubuntu-devel people that are also dd who would be interested getting some interesting software into 20.04 LTS? (i've got breseq, cadabra2, coreboot(-utils), memtestcl, mimalloc, mlv-app, octopus, redasm, shotcut, speed-dreams, tiatracker, zytrax, hpx) waiting for review+sponsoring
<JackFrost> That's more than a couple! :)
<tarzeau> i got a few more like fricas and protrekkr, but i doubt anyone is interested in those, but yes, it's a bunch
<tarzeau> pick one :)
<tarzeau> i also have a working fontmatrix qt5 version, but the d/copyright sucks because of CC licenses and jquery embedded (lintian stuff)
<seb128> pitti, hey Martin, happy new year! do you think you could backport https://github.com/martinpitt/python-dbusmock/commit/bd51d910 to Debian? I saw there is probably another problem but it sounds like that commit would be required in any case?
<jamespage> doko: yep - RM radosgw-agent
<pitti> seb128: bonjour, et bonne annÃ©e !
<pitti> seb128: yes, I was planning to just do a new upstream release and upload that
<seb128> vorlon, hey, do you understand why half of the desktop world if failing on i386 due to installability issues today?
<pitti> seb128: unfortunately my sid schroot has been broken since yesterday, the gnupg upload seems to have messed up something -- there's no gnupg in the archive right now
<seb128> pitti, ah ok, good to read, I wanted to merge the n-m update for focal, I'm going to wait for that update, good luck with gnupg missing!
<pitti> seb128: but mbiebl found more errors with unstable's NM, I don't think that commit is enough
<seb128> pitti, I read that bug but you said that it work on fedora, maybe it does work also on Ubuntu :-)
 * pitti grabs the test result dice and rolls it
<seb128> but yeah, the other issue is going to need to be looked at/resolved eventually
<seb128> the known one/git commit is needed for sure in any case
<pitti> right
<sunweaver> Hi all! Has anyone in the Ubuntu world seen the upstream developer(s) of the onboard on-screen keyboard, recently?
<sunweaver> I am the Debian maintainer of onboard and I pinged them via mail some weeks ago and haven't received an answer, yet.
<sunweaver> Is there anyone around that has a clue about the maintenance status of Onboard?
<seb128> sunweaver, upstream or the Ubuntu package?
<JackFrost> You missed:[05:06:32] < sunweaver> Hi all! Has anyone in the Ubuntu world seen the upstream developer(s) of the onboard on-screen keyboard, recently?
<JackFrost> [05:06:58] < sunweaver> I am the Debian maintainer of onboard and I pinged them via mail some weeks ago and haven't received an answer, yet.
<seb128> k, I don't then, sorry
<sunweaver> seb128: thanks.
<sunweaver> I just cherry-pick rbalint's fixes on onboard in Ubuntu over to Debian.
<sunweaver> But we might become read to remove it from the archives.
<sunweaver> unless someone else steps up as upstream maintainer.
<enyc> sunweaver: i wonder in the bigger-picture of things about  importance of accesibility features in general
<xnox> tjaalton:  merged new nss doesn't seem to work with it at all, as it requires tls v1.2 minimum. If it doesn't have a champion in Debian, it must have one in Ubuntu, as it is in universe. Is kernel-team going to subscribe to it and fix autopkgtests?
<enyc> sunweaver: have noticed  dragon input system,  colour changing tools,  magnifiers,  screen readers,  and so-on ...  just not-so-available for gnu/linux/ubuntu/etc
<xnox> tjaalton:  and are we keeping openjdk-8 in focal? i guess we are, in that case someone or me needs to check what's going on with current nss then.
<xnox> cjwatson:  does openssh have any magic tests around 2020 date. Seems like it started to fail since new year http://autopkgtest.ubuntu.com/packages/openssh/focal/amd64 https://ci.debian.net/packages/o/openssh/unstable/amd64/ debian timings w.r.t. new year are a lot closer. I am not sure if i am reading regress errors right, but it fails tests to do with expiration of things.
<tjaalton> xnox: dogtag-pki autopkgtests pass fine on debian, so it's not nss to blame then?
<cjwatson> regress/cert-hostkey.sh:test_one "cert not yet valid"   failure "-h -V20200101:20300101"
<cjwatson> regress/cert-userkey.sh:test_one "cert not yet valid"   failure "-n ${USER} -V20200101:20300101"
<enyc> cjwatson: o dear =)  should this not use a hardcoded test 'date in future' at all, rather calculate something at time of build?
<cjwatson> https://anongit.mindrot.org/openssh.git/commit/?id=ff31f15773ee173502eec4d7861ec56f26bba381
<xnox> tjaalton:  debian doesn't set tlsv1.2 min in nss; but we do.
<cjwatson> enyc: no doubt, but I'll just cherry-pick the upstream change.  Take it up with upstream
<enyc> I wonder at what point trying to colcucate over 2038 etc. will fail ;p
<enyc> unix time 32-bit and all that =)
<xnox> cjwatson:  i like that they make it still 1st of Jan. I'll ask them to move it at least to Jan 14th because holidays.
<tjaalton> xnox: so there were autopkgtests showing that it failed? have they been removed now as well?
<cjwatson> Not on 64-bit systems it isn't, and people are working on the 32-bit case
<xnox> tjaalton:  should be still there => one sec.
<xnox> cjwatson:  thank you for pointing it out!
<xnox> tjaalton:  fails to initialize https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/d/dogtag-pki/20200108_202654_c8684@/log.gz ?
<tjaalton> so after ~5h it got removed, nice
<tjaalton> CA worked, so ipa server still works too
<tjaalton> /usr/lib/python3.7/getpass.py:91: GetPassWarning: Can not control echo on the terminal.
<tjaalton> I don't think it's related to nss but maybe something else
<xnox> tjaalton:  there are other errors about something else deprecated in the logs about passwords / pin.
<xnox> tjaalton:  if the autopkgtest is fixed in debian, we can sync both of them back in, and readd them.
<cjwatson> xnox: thanks for noticing, since I hadn't yet; fix uploaded to unstable
<tjaalton> xnox: well I can drop the uninstall test..
<tjaalton> it's pretty pointless anyway
<xnox> tjaalton:  it's just there is nobody to gate it (no gating in debian, and no owner in ubuntu)
<xnox> tjaalton:  true.
<xnox> tjaalton:  propose it to debian, and sync from there?
<tjaalton> I'm the maintainer there
<xnox> cjwatson:  i wonder if we need to SRU it across all the releases & ESM now too =/
<xnox> tjaalton:  oh, ok =)
<xnox> did not realize / check that, sorry.
<tjaalton> np, this did prompt me to ask the fedora jdk maintainer about their plans, and jdk11 might finally make it on their schedule..
<cjwatson> xnox: Can ride along with any other fix that's required I imagine
<tjaalton> which in turn means it's a priority to port everything over
<ahasenack> cpaelzer: this is weird: https://pastebin.ubuntu.com/p/CKJYg6wqXs/
<ahasenack> cpaelzer: line 3 creates the local/usr.sbin.slapd local override
<ahasenack> then line 4 loads it, all is fine
<ahasenack> test runs, succeeds
<ahasenack> then at the end I remove the override 40
<ahasenack> but apparmor_parser -r fails weirdly
<ahasenack> -T and -W are to handle the cache, which I thought was the problem
<ahasenack> ahhhh
<ahasenack> found it
<ahasenack> thanks :)
<jamespage> cpaelzer: I'm ready to go on openvswitch and ovn updates post 19.11 dpdk upload
<jamespage> will need some archive-admin time for the split out and new source package for ovn
<cpaelzer> jamespage: I ahve a call about DPDK in 1.5h after that I intend to upload
<cpaelzer> jamespage: will hit new queue as well
<jamespage> great
<cpaelzer> so you have some time to sort out AA needs :-)
<cpaelzer> I'll keep you posted on it
<seb128> LocutusOfBorg, hey there, what do you think about splitting the remmina-gnome-session entry in a different deb (which we would install by default)?
<seb128> Laney, ^
<Laney> I just asked mfv about that in #debian-gnome
<Laney> :>
<seb128> ah, for some reason I though locusofborg was also maintaining it in debian
<Laney> maybe LocutusOfBorg will want to do the work anyway ;-)
<Laney> also I think you mean "would *not* install by default"!
<seb128> shrug, I need to stop doing those thinkos, indeed
<seb128> LocutusOfBorg, bug #1851007 also I think is still not resolved which makes the session not working
<ubottu> bug 1851007 in remmina (Ubuntu) "Login option 'GNOME + Remmina' not working" [Low,Confirmed] https://launchpad.net/bugs/1851007
<LocutusOfBorg> I would like to avoid doing debian work for remmina :p
<seb128> LocutusOfBorg, sorry, for some reason I though you were maintaining it there :)
<LocutusOfBorg> no problem :)
<LocutusOfBorg> I just do the merges, because both upstream and Debian are italian, and they ask directly to me!
<Laney> heh
<ahasenack> xnox: hi, I have an MP up for krb5 to switch it to use py3
<ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/krb5/+git/krb5/+merge/377326
<ahasenack> I just missed to link it with the bug :/
<RikMills> is anyone looking at merging pulseaudio? that has the equaliser ported with patches to python3 I think?
<RikMills> doko ^ ?
<seb128> RikMills, pulseaudio is maintained by the desktop team, don't bother doko with it :)
<RikMills> seb128: right
<seb128> RikMills, is there a concrete problem with it as of today?
<seb128> we will merge that/get an update before ff for sure, but I do an upload sooner rather than later if there is need for the change to land in focal now
<RikMills> seb128: new pyqt5 synced that autosynced from debian dropped the Python2 dbus.mainloop.pyqt5 packages that the equaliser currently depends on, so pyqt5 will not migrate until pulseaudio is merged
<seb128> RikMills, k, sounds lIke a good reason, let me merge that change, and thanks for the ping!
<RikMills> not urgent, but would be nice to fix
<RikMills> thanks! :)
<LocutusOfBorg> seb128, what about asking debian to bump epoch so MoM does some little job on it?
<seb128> LocutusOfBorg, you can ask them if you feel like, I personally don't use that service for pulseaudio since we have git packaging
<LocutusOfBorg> I did a debdiff between debian and ubuntu
<LocutusOfBorg> there is something that should probably go away, like upstart stuff
<LocutusOfBorg> MoM does a good job in that
<LocutusOfBorg> but yeah, a git diff does it even better
<seb128> thanks for pointing it out, I will have a look at the delta we can drop while I'm at it
<LocutusOfBorg> while I asked you to do, I remembered that pidgin has the same issue, and it is collaborate maintenance in Debian
<LocutusOfBorg> so I'll just commit the bump epoch there :p
<seb128> :)
<LocutusOfBorg> they acked it a while ago, but they forgot to commit
<doko> RikMills: yep, just wanted to get that installable again. Could you do the merge?
<doko> seb128: ^^^
<seb128> doko, yes, I'm on it
<seb128> doko, feel free to ping about any desktop owner source that needs merged/fixing, we are happy to help
<xnox> ahasenack:  nice!
<xnox> ahasenack:  does it work? =)
<ahasenack> xnox: sure
<xnox> tjaalton:  why would we keep openjdk-8 if like only three things are left that depend on it
<xnox> tjaalton:  actually they all have alternatives
<tjaalton> doko: ^
<xnox> doko:  vorlon: please remove openjdk-8 from focal https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1859037
<ubottu> Launchpad bug 1859037 in openjdk-8 (Ubuntu) "RM: openjdk-8 obsolete, unused in the archive" [Undecided,Triaged]
<doko> xnox, vorlon: please no. we said will will keep it until the support for 16.04 LTS ends
<doko> so maybe what we might want to do is to ship it only in -updates
<xnox> doko:  which support? until 2026 then?
<xnox> doko:  in that case i'd love to drop alternative depends, such that nothing has alternative depends on openjdk8 in the archive.
<doko> xnox: apparently, yes. as long as we need to update the package, that's ok
<xnox> doko:  ack.
<doko> xnox: could you have a look at the z3 ftbfs on s390x?
<doko> seb128: we need to coordinate the pygtk2 removal with jbicha. I'd like to avoid rebuilding all that old stuff ...
<seb128> doko, yes, do we have a bug report to track that atm?
<seb128> doko, also feel free to give us a list of desktop things to fix, you don't have to fix everything yourself
<xnox> doko:  urgh that is ugly
<doko> seb128: I don't have such a list, but you could scan python-defaults in output_notest
<seb128> doko, k, well in any case when you hit a desktop package that you want to see fixed feel free to ping
<vorlon> seb128: half of the world> which half?  link to some log?
<seb128> vorlon, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/c/clutter-1.0/20200108_155337_4f951@/log.gz
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/f/firefox/20200108_211625_61bf5@/log.gz
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/f/ffmpeg/20200108_172908_8962e@/log.gz
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/libs/libssh/20200108_211244_b9663@/log.gz
<vorlon> seb128: ok looking
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/p/poppler/20200108_201209_55428@/log.gz
<seb128> vorlon, it might be they are ending up to a common lib not installable or something but unsure how to properly figure that out...
<seb128> vorlon, thx
<vorlon> seb128: it's expected that firefox tests won't pass on i386 and it's a bug in britney that they're run
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/g/gtk+2.0/20200108_230517_cbb33@/log.gz
<vorlon> the others though, I've just noticed and will dig in now, thanks
<seb128> thx
<vorlon> https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt doesn't show uninstallabilities fwiw
<seb128> also if you have hints on how to poke to those issues I might be able to figure things out myself instead of bothering you next time :)
<seb128> oh, I didn't know about that report
<seb128> nice
<vorlon> oh it's probably hitting the autopkgtest bug where if a library in the amd64 base system is in -proposed, the pin doesn't get set to cover both archs
<vorlon> but that doesn't explain why it's uninstallable on the second run with all of proposed
<vorlon> so I'd guess it was: couldn't cherry-pick the specific package from -proposed because of wrong pin; couldn't install from -proposed because some build was behind
<vorlon> I'll see if I can reproduce it now and maybe these'll just need to be retries
<seb128> k, thanks
<rafaeldtinoco> rbasak: SO, when you're packaging mysql-server-8, did u make sure for all the build tests to pass ? just checking cause I think there are 2 of those failing currently for focal, wanted to know if you faced failing tests during build time (nocheck doesn't change attempt of running the tests).
<rbasak> rafaeldtinoco: it's quite common for us to see test failures. They fail the build.
<rbasak> (though we don't run the _entire_ test suite, just a subset)
<rbasak> Also more (different) tests are run during dep8
<rbasak> So if it made proposed migration, I assume they were passing at the time
<rafaeldtinoco> rbasak: awesome.
<rafaeldtinoco> tks.. ill work in current failures then.
<rafaeldtinoco> its for the mysql-router MIR (security team asking)
<Skuggen> rafaeldtinoco:I think we only enforce all tests passing for i386 and amd64, for MySQL
<rafaeldtinoco> Skuggen: hum
<cpaelzer> jamespage: https://launchpad.net/ubuntu/+source/dpdk/19.11-2ubuntu1 is in focal-proposed - but it will have to pass new queue after build before you can use it I guess
<cpaelzer> all but arm64 are built for now, we can check tomorrow in which state it is to upload dependent packages
<rafaeldtinoco> rbasak: CREATE EVENT e1 ON SCHEDULE AT '2020-01-01 00:00:00' DO SET @a = 1;
<rafaeldtinoco> lol
<rafaeldtinoco> we are at 2020 and the test is broken now
<rafaeldtinoco> omg
<rafaeldtinoco> i'll do a fix for those tests and do a MP for mysql-server
<rafaeldtinoco> fixing the FTBS
<rbasak> rafaeldtinoco: coordinate with Skuggen please - we should have an upstream bug for that
<rbasak> rafaeldtinoco: and thank you for sorting it :)
<rafaeldtinoco> rbasak: I think there is one already
<rafaeldtinoco> I'll sync with him
<rbasak> rafaeldtinoco: MP against the salsa branch please
<rafaeldtinoco> definitely!
#ubuntu-devel 2020-01-10
<Skuggen> rafaeldtinoco: Oh lord. We've had test bugs like that before, too :D
<rafaeldtinoco> Skuggen: lol
<Skuggen> Thanks for looking into it!
<rafaeldtinoco> it was written since 2007 =)
<rafaeldtinoco> sure! , im investigating other bug and will propose a merge
<Skuggen> Thanks. We've fixed bugs like that by setting the event to be something like now()+1day instead of a set date, though I don't remember the exact syntax
<rafaeldtinoco> ah, yep its not in github yet
<rafaeldtinoco> i made a delta to 2025 until 8.0.20 is released
<rafaeldtinoco> i mean, not yet, made it locally to pass the test =)
<rafaeldtinoco> just added you to the LP bug
<Skuggen> Yeah, that's fine. We can add that as a patch in salsa, since it's just until it's fixed upstream, anyway
<cpaelzer> a build taking 13h looks wrong
<cpaelzer> even if it would have taken so long timeouts would have kicked in right?
<cpaelzer> https://launchpad.net/ubuntu/+source/dpdk/19.11-2ubuntu1/+build/18539704
<cpaelzer> I could cancel and start again - but in the current state it might be debuggable ... ?
<cpaelzer> the same in a ppa buid multiple times without that https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3881/+build/18538702
<cpaelzer> can't find anything useful, restarting to get things moving again :-/
<cpaelzer> hmm, cancelling this seems just as stuck as formerly completing it was ...
<cpaelzer> still hanging on "cancelling build" after 20 minutes ...
<cpaelzer> cjwatson: wgrant: Laney: anything comes to your mind to get this unstuck ^^ ?
<cpaelzer> cjwatson: that might also be related to the autopkgtest you mentioned in #ubuntu-release
<cpaelzer> fyi dpdk arm64 build still stuck at cancelling
<cpaelzer> and as I'd assume withotu all builds it is not yet showing up in the new queue
<cpaelzer> jamespage: ^^ FYI why things take a while ... sorry
<jamespage> cpaelzer: np - I have a ceph resync/merge I'm working on until that's all cleared
<jamespage> doko: once cpaelzer's DPDK uploads have cleared the new queue for focal I have a source project split openvswitch -> openvswitch + ovn to upload - would you have cycles to look at the new source package and binaries for ovn?
<cjwatson> cpaelzer: don't cancel builds in that sort of situation please
<cjwatson> if anything it makes things worse
<cpaelzer> cjwatson: how should I have known that the cancel hangs as much as the build
<cpaelzer> cjwatson: and as you see between starting to look at it (discuss here) and the cancel was about an hour
<cpaelzer> so I wasn't trigger-happy on cancel, but I found nothing else that could help and was here in the wrong time where everyone else was still asleep :-)
<cpaelzer> but I can clearly remember this particular case and not cancel it next time
<cpaelzer> I see it was resolved now and became a correctly-cancelled build that I was able to retry
<cpaelzer> lets see how it behaves this time
<cpaelzer> ok, it was half an hour in IRC log - but also I looked at it before I asked here ... :-)
<cjwatson> cpaelzer: if you see a "buildlog" link (not the build log tail, but literally a "buildlog" link), then the build has already completed on the builder side and cancelling it will do nothing useful
<cjwatson> if you leave it alone then it will finish eventually (possibly via buildd-manager restarts).  if you cancel it then you might have to run the whole build again
<tseliot> xnox, hi, any thoughts on this? https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/1854985
<ubottu> Launchpad bug 1854985 in pm-utils (Ubuntu) "pm-utils overrides runtime power management mode for audio devices" [High,Triaged]
<doko> jamespage: ok, I'll try
<jamespage> doko: thanks
<seb128> vorlon, hey, so I'm unsure what to do about network-manager/i386, network-manager-config-connectivity-ubuntu (and -debian) which is arch all depends on network-manager, changing to be architecture any sounds wrong, wdyt?
<cpaelzer> cjwatson: that hint with the buildlog is great, that seems like a clear "if A, then B" thanks!
<doko> jbicha, seb128: pygtk2 removal ... please could you summarize what should be kept, and what still needs porting?
<seb128> doko, I will have a look yes
<doko> yes, was first a question for jbicha, he wasn't here yesterday
<seb128> doko, I'm unsure he's having much time from Debian/Ubuntu nowadays...
<doko> seb128: https://lists.debian.org/debian-gtk-gnome/2019/10/msg00001.html  do you know about that cocinelle status?
<doko> any anything on that list in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937452 which you want to keep/port?
<ubottu> Debian bug 937452 in src:pygtk "pygtk: Python2 removal in sid/bullseye" [Serious,Open]
<seb128> doko, activity-log-manager might still be useful to the unity remix, unsure about the others
<doko> that seems to be fixed already. run reverse-depends -l src:pygtk for a current list
<doko> ogra: do you know if we still care about edu/sugar?
<ogra> doko, no idea, but i gues not particulary ... also, there seems to be a sugarizer snap
<doko> ok
<cpaelzer> jamespage: dpdk is ready in focal proposed, collectd built against it and ready for proposed as well
<cpaelzer> jamespage: I saww ovs and ovn in the new queue and your ping to doko
<cpaelzer> I'll come back to this checking proposed migration of all of these on monday then when tests ran
<doko> seb128: so coccinelle has one rdep (caml-crush), which can be removed as well. remove?
<seb128> doko, +1 from me
<xnox> tseliot:  commented
<tseliot> xnox, thanks
<seb128> vorlon, I think your libsdl2 autopkgtest changes have a problem, it fails now with 'CMake Error: The source directory "/tmp/tmp.v3CMlzU4jv/build" does not appear to contain CMakeLists.txt.'
<vorlon> seb128: network-manager: arch-all packages that are uninstallable on i386 are fine, since we're not actually using it as a host arch and those deps will be satisfied by the amd64 version of the packages.  Only the binaries listed on https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt need excluding
<xnox> doko:  heya, i think this will fix python test-suites with stronger openssl in both debian and ubuntu https://paste.ubuntu.com/p/2fNYsDbGJM/ but i'm not sure how to test this best..... shall i just upload it into focal-proposed?
<seb128> vorlon, k, it feels wrong but I can close my eyes if that's the decided way :)
<xnox> doko:  or do you have a quicker way to re-run just the missing/skipped tests, which i'm now re-enabling?
<vorlon> seb128: the reports don't complain, and it doesn't adversely impact users of amd64 hosts + i386 compat, it's fine ;)
<seb128> alright!
<vorlon> seb128: libsdl2: yeah I guess I should look into that further
<xnox> seb128:  i have the same feelings, and my self-help answer is that "uninstallable arch;all packages should not be published into Packages_i386 but such is life, and fixing soyuz to do that is pain"
<seb128> vorlon, I fixed the e-d-s build just as fyi
<doko> xnox: please do
<xnox> doko:  i thought of reruning just the autopkgtests locally with the build from focal-proposed first. As a mini-partial smoke test.
<xnox> doko:  if any pass, will upload that into focal-proposed
<xnox> doko:  i'm now running just the "failing-tests" autopkgtest, with just the subset of the blacklisted tests, which appear to have "progressed" all by themselves in debian. Even when openssl package is installed with evil openssl.cnf
<bdmurray> seb128: is there somebody who can look at bug 1841646? It receives quite a lot of activity.
<ubottu> bug 1841646 in evolution (Ubuntu) "White text on white background for HTML e-mail" [Undecided,Confirmed] https://launchpad.net/bugs/1841646
<seb128> bdmurray, I will look thx for the ping
<santa_> hi everybody
<santa_> seb128 vorlon: I've seen above you mentioned something about network-manager, but I sill don't get why it doesn't migrate from -proposed. btw the version in -proposed fixes a bug I've been suffering with VPN passwords (it doesn't remember it with 1.20.4)
<santa_> s/sill/still/
<vorlon> santa_: because i386 is a partial arch, and some cleanup needs to happen at the source level to not build binaries that are now uninstallable on this arch
<vorlon> (even though this is not a regression in -proposed vs the release pocket, proposed-migration doesn't calculate that and considers the uninstallability a blocker)
<santa_> ah, I see network-manager is still being built for i386
<santa_> vorlon: thanks for the explanation
<santa_> and seb128 thanks for the new package
<vorlon> yes, because nm builds libraries that are needed somewhere along the line on i386
<santa_> aha, I guess building a limited set of packages for i386 leads to complicated situations
<xnox> vorlon:  doko: it seems to me that the old gcc-9 in focal-proposed was busted, and like generates binaries that fail with SIGILL illegal instruction; and hence the compiler in focal-proposed/sid cannot build new gcc-9 either. The compiler in focal-release looks fine. Does it make sense to purge gcc-9 from -proposed, to reattempt rebuilding new gcc-9 with compiler from release?
<xnox> i cannot tell if binutils or gcc-9 is at fault, cause had to revert both and couldn't revert just one of them.
<doko> xnox: build log?
<xnox> https://launchpadlibrarian.net/460019735/buildlog_ubuntu-focal-arm64.gnutls28_3.6.11.1-2ubuntu1_BUILDING.txt.gz
<xnox> i also have this build on an arm64 box too, which has everything from focal-proposed
<xnox> and the fact that it builds fine in focal-release chroot
<xnox> (also rebuild the gnutls28 from focal-release with focal-release & focal-proposed toolchains => fails with -proposed, rebuilds fine with -release)
<xnox> doko:  and well, also gcc-9 is ftbfs in sid & focal-proposed too => but can't really tell why, xgcc fails?
 * xnox tries to quickly rebuild focal-proposed gcc-9 in focal-release chroot
<xnox> https://buildd.debian.org/status/fetch.php?pkg=gcc-9&arch=arm64&ver=9.2.1-23&stamp=1578668809&raw=0
<doko> xnox: I'll look tomorrow. I see that only arm* is failing
<xnox> https://launchpad.net/ubuntu/+source/gcc-9/9.2.1-23ubuntu1/+build/18543838
<xnox> doko:  yes, i am experiencing this on arm64
<xnox> and i have baremetal arm64 instance up as well, if you want
<seb128> pitti, python-dbusmock autopkgtests are unhappy on focal, maybe a glib 2.63 issue?
<seb128> pitti, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/g/glib2.0/20200110_064132_d9716@/log.gz
<seb128> pitti, AttributeError: 'gi.repository.Gio' object has no attribute 'MemoryMonitor'
#ubuntu-devel 2020-01-11
<LocutusOfBorg> enyc, which "hardware virtualization" you mean? vtx?
<enyc> LocutusOfBorg: i wonder,  https://www.virtualbox.org/wiki/Changelog-6.1#v0  says "Virtualization core: Drop recompiler, i.e. running VMs now needs a CPU supporting hardware virtualization"
<infinity> enyc: And you use a CPU from 15+ years ago that makes this a cause for concern?
<infinity> enyc: Also, the argument that you'd like a stable release with lots of updates, "like 5.2" is a non-starter.  5.2 is special and got extended support because it was the last release with 32-bit host support.  It's not the norm.
<enyc> infinity: i uspsect, a common problem is  virtualization disabled!  ive seen it often  ,  may well be the case that its' largerly a non-issue now but i don't have enough sample to be sure
<enyc> nonetheless is reasonable ponit of note/discussion
<enyc> I know LocutusOfBorg dealt with virtualbox package backport, and so-on!
<infinity> enyc: Indeed, some people disable virt in their BIOS.  I think those people get to keep both pieces (but also, most virt manager UIs, including vbox, will hint a that solution, I believe)
<enyc> infinity: hrrm, or -.-  is it ofetn "not enabled by default" in first-place?  i've always wondered why it was an "option" at all!!
<infinity> If you really need non-virt virt, qemu exists.
<infinity> enyc: There's no standard that mandates it be on or off, so it seems to be at the manufacturer's discretion, and I've seen it ship both ways.
<infinity> enyc: Sadly, if you want it always on, the best bet would be to ask Microsoft to mandate it for Win10 cert. :P
<infinity> That was the only way we got BIOSes to uniformly ship in non-Legacy EFI mode by default after years of not.
<infinity> Anyhow, the solution to "the BIOS setting is wrong" isn't "set your CPU on fire doing x86 emulation instead of passthrough", it's "tell the user to change the BIOS setting".
<enyc> infinity: hrrm, i didn't ever find  virtualbox was doing full emulation,  ... just not the  nested paging and other accelerated processes....  i though it always tries to set up all the equivalent pagetables to run ring3 code natively.
<enyc> anyhow, no matter!
<infinity> I might not grok what level of "hardware support" it's decided it now needs.
<infinity> I try to avoid vbox except when asked to debug something that fails exclusively in vbox. :P
<enyc> infinity: Xen has always been ablet o run userspace code  natively, even in 386 on 386!
<xnox> doko:  so rebuild of gcc from proposed in release builds. so gcc&binutils in focal release must be ok.
<enyc> infinity: using 80386/486 features only!
<xnox> on arm64
<enyc> infinity: come to think of it, i *think* virtualbox has never supported 64bit-guests with without hardware-virt-support,  so you have 64bit systems where yo ucan only run 32bit vms!!
<infinity> enyc: True, but Xen's also a pretty special snowflake in the Linux hyp world in that it's the only "real" thin hypervisor, rather than a kernel bodge with userspace VMs on top.
<enyc> LocutusOfBorg, infinity : nonetheless, 2 points remain,  (a) does virtualbox 6.1 now include sufficient help for  "your virtualization support is not turned on, see <HERE-wiki-link?> for help,examples on fixing this"
<enyc> LocutusOfBorg, infinity : secondly, remains to be seen how stable vbox 6.1 becomes by the time 20.04.1 ish comes out!   we will see.
<enyc> thankyou
 * enyc -> out for bit
<LocutusOfBorg> enyc, 6.1 will gain minor releases even after 20.04 is out :)
<LocutusOfBorg> and 5.2 is a real no-go
<LocutusOfBorg> xnox, can you please add verbosity to the arm64 issues you mention above?
<infinity> 5.2 dies upstream in July anyway.
<LocutusOfBorg> I'm struggling with llvm-* build failures in proposed pocket
<xnox> LocutusOfBorg:  everything is in this chat yesterday as well.
<LocutusOfBorg> mmm thanks, I'll grab logs, my BNC died
<xnox> LocutusOfBorg:  i'll start a rebuild in bileto ppa, and retest that gnutls28 builds.
<LocutusOfBorg> enyc, btw finding a cpu that has no vt-x is mostly impossible today
<LocutusOfBorg> I remember back 10 years ago, I had a non vtx cpu and could only virtualize 32bits
<LocutusOfBorg> but meh, its 2020 now
<infinity> xnox: Oh, is this the SIGILL thing you asked me about and didn't respond to my response? :)
<infinity> xnox: If in doubt, blame the new binutils snapshot.
<infinity> xnox: For bonus points, if the new binutils *is* generating bad code, we might need to scrape all arm64 builds since that binutils landed and queue them up for no-change rebuilds after it's fixed. :/
<xnox> infinity:  yeap, that
<infinity> xnox: It could be that someone OOPSed upstream and decided all armv8 is now armv8.1 or 8.2 or something.
<LocutusOfBorg> infinity, so the llvm-* sadness is probably due to it
<infinity> xnox: And luckily (?) for us, our arm64 buildds are literally the very first generation of armv8.0 that existed, so they'd catch that nicely. :P
<LocutusOfBorg> but why debian unstable is not experiencing the same on arm64?
<LocutusOfBorg> DAMN, that...
<LocutusOfBorg> so Debian has "better" arm64 cpus?
<LocutusOfBorg> (newer, whatever)
<infinity> LocutusOfBorg: According to xnox, sid's busted too.
<xnox> infinity:  so, i am re-uploading gcc-9 into bileto ppa which is set to release pocket only. That should give me latest gcc build without new binutils. Will retry that, just upgrade binutils, to see if that's the one.
<infinity> At least, gcc-9 fails to bootstrap in sid.
<xnox> infinity:  i kind of want to block-proposed-focal binutils and gcc-9 for now.
<xnox> well gcc-9 ftbfs so won't migrate
<LocutusOfBorg> but llvm-toolchain-9 rebuilds on arm64 didn't fail because the "SIGILL" are not experienced on the machine that built it?
<infinity> xnox: I mean, it *could* be gcc (and that would be preferable, as the gcc delta is small and readable), but it's almost certainly the jump from binutils 2.33.1 to 2.33.50 (ie: 2.34-pre)
<xnox> LocutusOfBorg:  i see that on arm64 gcc ftbfs; and gnutls28 ftbfs when built by old gcc from focal-proposed.
<xnox> infinity:  we didn't chnage to 64k pages did we?
<infinity> LocutusOfBorg: You're the one who decided the llvm thing is the same bug, not us. :)
<infinity> LocutusOfBorg: It might not be.
<xnox> â	
<xnox> #1520162 compiled binaries don't work on arm64 64k pages kernel due to alignment
<xnox> Fix Released (11 comments) last updated 2017-08-21 view this bug
<xnox> Some binaries in 15.10 for aarch64 seem to be compiled with maxpagesize=4K which triggers issues when run on 64K pages
<infinity> xnox: We friggin' better not have.
<xnox> arm64 kernels (tested on all kernels back to 4.0). I spotted this while trying to boot an arm64 kernel with 64K pages enabled on 15.10 Ubuntu filesystem.
<xnox> launchpad suggested this as a bug report
<xnox> ââ	
<xnox> #1520162 compiled binaries don't work on arm64 64k pages kernel due to alignment
<xnox> Fix Released (11 comments) last updated 2017-08-21 view this bug
<xnox> bah bad paste
<xnox> infinity:  doko: rebuilding gcc-9 alone in release pocket at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3891/+packages
<LocutusOfBorg> infinity, since both Debian and Ubuntu had the same binutils snapshot, and debian was ok, and gcc didn't change in the meanwhile ( xnox ) because with llvm we still use gcc-8, I assumed it wasn't binutils fault
<infinity> xnox: You can block-proposed binutils and gcc-9 if you like, but it won't really change anything, since everything in the archive is biult against proposed ANYWAY.
<LocutusOfBorg> now, if new binutils generates wrong code, and arm-conova-02 can understand it, that would explain why we hit the bug in ubuntu
<infinity> xnox: Regardless of where binutils and gcc live, we'll need to audit all the binaries that were build by the bad version(s) once we've determined the issue.
<xnox> infinity:  true
<LocutusOfBorg> btw blaming my python3 clang move was also a possible thing
<infinity> LocutusOfBorg: Anyhow, to answer your question (sort of), I don't know what hardware Debian is using for arm64, but if it's anything other than APM X-Gene, it's newer and "better" than ours.
<infinity> The only other arm64 core as old as X-Gene is the first 64-bit iPhone core, whose name escapes me at the moment.
<LocutusOfBorg> time to ask santa to send us new arm64 cores?
<LocutusOfBorg> :)
<infinity> Both are equally pure 8.0, both are about the same (lack of) speed, both look suspiciously similar under a microscope, but Apple swears up and down they did their all by themselves, honest.
<LocutusOfBorg> :)
<infinity> LocutusOfBorg: New cores isn't the problem, it's new servers around them that are.  We're long past the point where we're cool with just stacking weird whitebox stuff on shelves and rigging up dev board with zip ties, so we've been shopping for Real Servers for a while.  I believe we found some, but lead time and all that.
<doko> xnox: when did that start? because new binutils was only added on Thu
<xnox> doko:  i'm trying to establish what it is that is bad. My first observation is Friday 10th Jan 4:27am gnutls28 ftbfs.
<xnox> doko:  new binutils published on 8th of January on arm64 no?
<xnox> https://launchpad.net/ubuntu/+source/binutils/2.33.50.20200107-1ubuntu1/+build/18529927
<LocutusOfBorg> btw doko your binutils probably dropped stuff from Steve, -  * Fix autopkgtest failure when not cross. and Make autopkgtests cross-test-friendly.
<doko> I'll have a look. not forwarded to Debian ;p
<LocutusOfBorg> so, if the current llvm-toolchain-7 and llvm-toolchain-9 build on focal-proposed, it means that llvm broke itself and it is now fixed
<LocutusOfBorg> otherwise, blaming binutils
<LocutusOfBorg> (since I use gcc-8)
<cpaelzer> jamespage: OVS is good in excuses, collectd already migrated (not version dependent)
<cpaelzer> dpdk itself seems blocked on some lib depends - the binaries that depend on them are not in main, so there should be no component mismatch - and the libs itself are in focal as new enough versions
<cpaelzer> I'll have to look more in detail about why it complains about unsatisfiable Depends: libipsec-mb0 and unsatisfiable Depends: libisal2
<cpaelzer> maybe the enw queue handling for these binaries moved them to main
<cpaelzer> anyway ... on monday ...
<xnox> infinity:  focal-release + binutils from focal-proposed = sigill during gnutls28 builds
<xnox> doko:  ^
<xnox> infinity:  can we purge binutils from focal-proposed (or like move it to a ppa?!) and what should I / we do next?
<xnox> infinity:  git bisect of binutils?
<xnox> infinity:  i see weird aarch64 reverts in binutils 23h ago. I'll play volleyball, and then will try a new binutils snapshot to see if it is unbroken.
<xnox> doko:  ^
<doko> xnox: I'll look at removing it. Need to remove gcc-9 as well for that
 * enyc meows and reads scrollback
<enyc> LocutusOfBorg: fwiw my bugbear is that virtualbox discard/nonrotational  is buggy/locks-up-VMs !  you have to manually zerofill and manually vboxmanage modifyhd --compact etc etc ;-(  anyhow  thats more avbox than ubuntu discussion!
<LocutusOfBorg> enyc, there is the vbox-dev channel here :)
<xnox> doko:  new binutils snapshot seems good. gnutls28 built =)
<xnox> doko:  thank you
<juliank> /usr/bin/deb-systemd-helper: error: systemctl preset failed on samba-ad-dc.service: No such file or directory
<juliank> who broke samba?
<juliank> and why is it configured now, hmm
<juliank> hmm no must be something else, something was broken
<juliank> The following packages have unmet dependencies:
<juliank>  libltdl-dev : Depends: automake-1.16
<juliank> I can't figure out what went wrong, the logs all seem fine
<juliank> There's nothing in the log installing that -dev, or removing automake
<juliank> or any dep error
<juliank> so the samba error message was misleading :D
#ubuntu-devel 2020-01-12
<Bluefoxicy> is it appropriate to report "use LVM for root filesystem in Raspberry Pi images" as an Ubuntu bug?
<Bluefoxicy> (it would be extremely useful to be able to snapshot the root fs, such as for Bacula backups)
<rbasak> Bluefoxicy: it's a perfectly valid request, though I'm not sure that filing a bug for that would result in it happening in any way
<rbasak> It would seem like quite an impactful change to me
<rbasak> What about Ubuntu cloud images for other platforms, for example? Should those change to LVM too?
<rbasak> Anyway, feel free to file a bug. I just wanted to set expectations that you might not see anything happen as a result unless you're volunteering to do most of the work, at which point it becomes a valid technical question as to whether it's an appropriate change to make.
<GrimSleepless> Hello guys, I am making an implementation of apt-add-repository for a project in python. I don't know if I am at the right place to ask that... If I am wrong don't be shy to point me in the right direction. Is there documentation out there on how to retrieve the gpg key of a new repository you are adding to your distribution?
<cjwatson> apt-add-repository is already implemented in Python, so you might just use it ...
<GrimSleepless> I guess I could since I am working on an Open Source project
<GrimSleepless> cjwatson: The source code is on launchpad, isn't it?
<cjwatson> You could also look at softwareproperties.ppa (which is where the relevant bit of apt-add-repository is implemented); start from AddPPASigningKey
<cjwatson> https://git.launchpad.net/ubuntu/+source/software-properties/tree/softwareproperties/ppa.py
<GrimSleepless> cjwatson: cool thank you! I will have a look!
<cjwatson> (There's a little bit of cruft in there - it still makes reference to keyserver.ubuntu.com, but no longer actually uses that, it calls a webservice API method on Launchpad instead)
<cjwatson> That's specific to PPAs though.  If your repository is somewhere else then there's no standard for how to do this
<cjwatson> You either need to be able to ship some kind of root of trust with your program or you need to be able to get hold of the signing key via some kind of HTTPS API (which is effectively delegating the root of trust to the global CA system)
<cjwatson> Or some combination of those
<GrimSleepless> cjwatson: Yes, indeed. This is the reason why I have created my own implementation. so it can be possible to add docker or other software that have their own repository and keys.
<cjwatson> Right, but regardless, there is no single documentation or standard for how to do this that you can refer to
<cjwatson> We can point you (and I have) for how to do it for PPAs, which cover quite a lot of repositories, but for anything else it's case by case
<GrimSleepless> cjwatson: I understand. Thank you so much for helping me out!
<cjwatson> np.  good luck
<GrimSleepless> thanks!
