[12:16] <xnix> is this where i should ask a feisty question?, wasnt sure if feisty questions were right for just #ubuntu
[12:16] <xnix> since its dev/beta
[12:18] <bdmurray>  #ubuntu is more appropriate
[12:18] <HrdwrBoB> #ubuntu+1
[03:12] <bddebian> Heya
[03:45] <Burgundavia> anybody got an rsync script?
[04:03] <jsgotangco> Burgundavia: hello Mr. Burger
[04:03] <Burgundavia> hey jsgotangco
[04:04] <jsgotangco> whats up bud
[04:10] <wasabi_> http://wiki.freespire.org/index.php/Linspire_Canonical_Partnership_FAQ  <--- what's all that about?
[04:10] <jsgotangco> linspire will now be basing on ubuntu and ubuntu users the option to use cnr or something like that
[04:11] <wasabi_> Yeah, mostly I wnat to know about the 2)
[04:11] <wasabi_> 2) Canonical will utilize Linspire's CNR technology for aspects of Ubuntu's software delivery system.
[04:11] <LaserJock> sounds like some sort of CNR plugin or something
[04:12] <wasabi_> Is CNR .deb files?
[04:12] <LaserJock> I doubt it
[04:12] <Burgundavia> wasabi_: no, cnr is a frontend to apt/dpkg
[04:13] <wasabi_> Oh. So it's just the thirdpartyapt thing I built and never finished?
[04:13] <Burgundavia> likely the default ubuntu install we be able to be pointed at cnr.com
[04:13] <Burgundavia> well, I don't think so
[04:13] <Burgundavia> I just hope it will not displace the existing methods
[04:13] <LaserJock> it works for rpms too I think
[04:13] <jsgotangco> yuck
[04:13] <wasabi_> Oh, so it's Just Another Repos?
[04:13] <Burgundavia> basically
[04:13] <wasabi_> Useless.
[04:13] <Burgundavia> plus it is going to be another frontend to the ubuntu repos, from what I understand
[04:13] <wasabi_> We need ThirdPartyAPt. ;)
[04:13] <Burgundavia> plus a massive QA nightmare
[04:13] <wasabi_> great.
[04:13] <jsgotangco> nice way to start up a big business hype
[04:13] <wasabi_> http://wiki.ubuntu.com/ThirdPartyApt
[04:14] <wasabi_> Sounds like the end of linspire to me.
[04:14] <wasabi_> and no real change in ubuntu
[04:14] <Burgundavia> basically linspire is dead
[04:14] <Burgundavia> I would expect them to last about another year or so and then just become Ubuntu
[04:14] <Burgundavia> much like MEPIS is now basically dead
[04:15] <jsgotangco> one disc to rule them all
[04:15] <wasabi_> Yeah. Looks like a way to save face.
[04:15] <Burgundavia> as the Ubuntu beast consumes another distro
[04:15] <wasabi_> Eh. Ubuntu is just better. That's what happens when people can't compete on merit.
[04:15] <wasabi_> No reason to look at it negatively.
[04:15] <bhale> yeah, i never bought into the theory that some day ubuntu itself would be eclipsed by a plethora of derived distros
[04:16] <Burgundavia> and it looks like Canonical has solved the QA problem
[04:16] <Burgundavia> which was the one thing that could kill us
[04:16] <wasabi_> Looks like it's just we're "integrating concepts of CNR into our existing tools'
[04:16] <wasabi_> Which is what would basically happen with or without cnr.
[04:16] <Burgundavia> LP was supposed to gain CNR stuff at some point
[04:16] <Burgundavia> nor CNR, but CNR-like
[04:17] <bhale> the one thing that wouldve killed us is SLED being built on Debian or Ubuntu instead of SuSE
[04:17] <bhale> too bad for them they have a stinker of a base
[04:17] <Burgundavia> you think so?
[04:17] <wasabi_> Heh. Yeah.
[04:17] <bhale> yes
[04:17] <Burgundavia> hmm, zmd...
[04:17] <wasabi_> Suse has managed market penetration.
[04:17] <wasabi_> Yeah. Directory stuff.
[04:17] <bhale> zmd has nothing to do with directory
[04:18] <wasabi_> zmd = zen something something?
[04:18] <bhale> and its a key reason why sled is crap
[04:18] <Burgundavia> no, zmd is part of their "stinker of a base"
[04:18] <wasabi_> oh.
[04:18] <bhale> its a daemon for package dependency resolution
[04:18] <Burgundavia> zmd is part of their package system
[04:18] <bhale> written in mono
[04:18] <wasabi_> oh.
[04:18] <Burgundavia> and it is crap
[04:18] <bhale> think that over for a second
[04:18] <jsgotangco> ohh
[04:18] <bhale> and get back to me :)
[04:18] <wasabi_> a) why a daemon
[04:18] <Burgundavia> even the Novell guys disown it
[04:18] <wasabi_> b) i don't care if it's mono.... except it's bigger and won't fit on small things.... but why a daemon?
[04:18] <bhale> its always hung
[04:18] <bhale> sometimes more fatally than others
[04:19] <bhale> and surrounding ui is horrific
[04:19] <Burgundavia> rpm has some nasty issues with killing dbs as well
[04:19] <bhale> for all the wanking they will give you about their usability lab
[04:19] <wasabi_> federico made a good pgo post about our software upgrade screen though. =0
[04:19] <Burgundavia> like the famous one where Jeff Johnson told the person they were an idiot for trying to run it with a read only /usr
[04:19] <bhale> "dude you totally missed the point, package menagement is not a real use case"
[04:19] <bhale> ....ok dude
[04:19] <Burgundavia> even Novell employees parents run Ubuntu
[04:19] <Burgundavia> I loved that
[04:20] <wasabi_> It's important that those things matter zero when it comes to the bottom line.
[04:20] <wasabi_> RedHat and Novell have customers. Paying customers.
[04:20] <Burgundavia> so does canonical
[04:20] <wasabi_> Uh. Huh. What, 4?
[04:20] <bhale> haha
[04:21] <wasabi_> Don't take that the wrong way. I'm in this channel for a reason. ;)
[04:21] <Burgundavia> they wouldn't have at least 4 or 5 paid support staff if they didn't have customers
[04:21] <wasabi_> 4 or 5. Heh.
[04:21] <wasabi_> Hobbsee: Doesnt look like anything has been "done"
[04:22] <Burgundavia> Hobbsee: before doing what? the cnr deal?
[04:22] <Hobbsee> Burgundavia: yeah
[04:22] <Burgundavia> I am certain at least mdz knew about it before it was signed
[04:22] <bhale> linspire has been based on ubuntu for years
[04:22] <bhale> they stole daniels X fu from warty
[04:22] <Burgundavia> they have been borrowing bits for years
[04:22] <Hobbsee> Burgundavia: true
[04:22] <Burgundavia> back when we actually had an X worth talking about
[04:22] <wasabi_> It's not called "stole"
[04:23] <Burgundavia> funny how mark wanted a shiny X with no X maintainer
[04:23] <bhale> i give it a slightly harsher term when said package was never meant to be released onto the world
[04:23] <bhale> Burgundavia: what is wrong with our X?
[04:23] <wasabi_> What ever happened to teh X auto config stuff?
[04:23] <Burgundavia> bhale: it is old
[04:23] <wasabi_> Like config-less?
[04:23] <Burgundavia> we are lacking 7.2
[04:23] <Burgundavia> 7.2 has about half the config-less stuff, 7.3 will have the rest
[04:23] <wasabi_> Neato. ;)
[04:24] <wasabi_> I want display hotplug.
[04:24] <Burgundavia> that is 7.3
[04:24] <bhale> 7.2 Release 
[04:24] <bhale> December 11, 2006 
[04:24] <Burgundavia> 7.2.1 will have input hotplug
[04:24] <bhale> hm.
[04:24] <ajmitch> and display hotplug requires driver support
[04:24] <wasabi_> Specifically the ability to randomlly add a new local display, which is in fact a proxy to a remote display.
[04:24] <Burgundavia> X guys haven't quite figured out the whole "releasing" bit
[04:25] <Burgundavia> bhale: if you follow the Xorg mailing list, server 1.2, which is 7.2, has been released
[04:25] <Burgundavia> I don't know what the final bits that are needed for the 7.2 release
[04:34] <Hobbsee> tfheen: ping @ libmtp2?
[07:25] <\sh> moins
[08:10] <tepsipakki> I'll post a progress report about xorg-7.2 to u-d when I get to work
[08:11] <tepsipakki> I've built all the libs up to mesa, which needs to be merged next :I
[08:12] <pitti> Good morning
[08:12] <tepsipakki> morning pitti
[08:12] <pitti> hey Mr. X :)
[08:13] <tepsipakki> heh :)
[08:13] <tepsipakki> just before you joined I wrote about it
[08:13] <tepsipakki> but more on u-d when I get to work ->
[08:20] <tfheen> cjwatson: shouldn't the usplash task on 83878 be closed?
[08:21] <TheMuso> cjwatson: You may be interested in this bug. https://launchpad.net/bugs/84139 it seems udev related, and I think you guys know more about udev than I do. :)
[08:21] <Ubugtu> Malone bug 84139 in brltty "Arduino detected as braille device" [Undecided,Unconfirmed]  
[08:59] <dholbach> good morning
[09:14] <ajmitch> is that the one with a big target on it?
[09:15] <pitti> workload-wise, yes :)
[09:18] <LaserJock> pitti: so you aren't doing MIR approvals anymore?
[09:18] <pitti> carlos: FYI, I'll release the dapper -base langpacks to -updates now
[09:18] <carlos> pitti: cool
[09:18] <pitti> LaserJock: I'll still do some today
[09:18] <carlos> pitti: the database already has the right timestamp
[09:19] <pitti> LaserJock: do you have a particular urgent one in mind?
[09:19] <carlos> so once we finish with Feisty testing updates will be relative to that one
[09:19] <pitti> carlos: I'll release the edgy-proposed ones to -updates as well, they got a fair amount of testing now
[09:19] <LaserJock> pitti: I actually have about 15 for Edubuntu that I want to do, but the aren't ready :/
[09:19] <pitti> 15? holy s***
[09:20] <mdke> morning dholbach_ 
[09:20] <LaserJock> pitti: do I need to do a separate MIR for each dep that needs promoted?
[09:20] <dholbach_> hey mdke
[09:20] <pitti> LaserJock: unless they are all alike, yes
[09:20] <mdke> dholbach_: can you do an ubuntu-docs upload today? I'm just checking it builds ok
[09:20] <pitti> LaserJock: doko had a special case yesterday: about 15 dict-$LANG source packages which looked all alike, just for different languages; for those one report was sufficient
[09:20] <LaserJock> pitti: we have a 2nd cd now for Edubuntu
[09:20] <dholbach> mdke: sure, give me a ping once you succeeded
[09:21] <pitti> LaserJock: also, just to make sure, you know that MIRs are per source pacakge, not binary?
[09:21] <LaserJock> right
[09:21] <LaserJock> total I want to get like 20-30 in
[09:21] <LaserJock> but I know I can't get it done for Feisty
[09:22] <LaserJock> the problem is that a fair amount of the ones I want pull in 5+ in deps
[09:22] <mdke> dholbach: ready to go :)
[09:23] <dholbach> mdke: rock on
[09:23] <LaserJock> pitti: what's the general feeling about packages that seem to be pretty bug free and secure, but aren't being actively maintained anymore?
[09:26] <mdke> dholbach: do you know why ekiga depends on yelp? it's a bit weird that it's the only Gnome app that does that
[09:27] <dholbach> mdke: ugh - I didn't know that - it probably shouldn't
[09:27] <mdke> I opened a bug on it a while back, but didn't get a reply
[09:28] <mdke> small fix I guess
[09:30] <pitti> dholbach: does UVF apply to universe already, too?
[09:30] <pitti> dholbach: i. e. what to do with universe sync requests that bring in new upstream versions?
[09:31] <Fujitsu> Shouldn't syncs filed pre-UVF be exempt from the freeze?
[09:33] <LaserJock> pitti: Universe UVF was same as Main, Universe FF was shifted to 22nd
[09:33] <LaserJock> but it would be nice if stuff already in the queue got processed, IMO
[09:33] <pitti> LaserJock: ok, so I'll set them to NEEDSINFO and wait for approval of who?
[09:34] <pitti> LaserJock: ok, can do, it's not that many anyway
[09:34] <ajmitch> pitti: approval will be by someone in motu-uvf
[09:34] <pitti> ah, ok
[09:37] <dholbach> mdke: done
[09:38] <mdke> rock
[09:38] <mdke> thanks dholbach 
[09:38] <dholbach> mdke: i'll drop yelp as a depends in one of the next uploads
[09:38] <mdke> for ekiga I hope, not ubuntu-docs :)
[09:38] <dholbach> i'd be happy if somebody else updated ekiga :)
[09:38] <dholbach> :)
[09:41] <Sp4rKy> hi
[09:41] <Sp4rKy> i need some information about gdm in the live
[09:42] <Sp4rKy> when i start the live, gdm login me with the user "ubuntu" in the auto-login way
[09:42] <Sp4rKy> but, in the squashfs, the etc/gdm/*conf set auto-login to false
[09:42] <tfheen> Sp4rKy: look at the casper package.
[09:43] <Sp4rKy> ok :)
[09:46] <Sp4rKy> hmm, i don't find where casper set auto login
[09:46] <tfheen> look in the scripts in /usr/share/initramfs-tools/scripts/casper-bottom
[09:47] <Sp4rKy> hehe
[09:47] <Sp4rKy> thx a lot :)
[09:47] <Sp4rKy> is there some good doc about casper ? (other than man of course :p)
[10:14] <cjwatson> tfheen: not unless it's been fixed. see the second paragraph of the description
[10:18] <cjwatson> TheMuso: followed up to the bug, thanks
[10:43] <tkamppeter> Is there any problem with the archives? pitti and doko have uploaded new foomatic-db and foomatic-db-hpijs packages and they did not appear on the server yet.
[10:43] <pitti> tkamppeter: I'm just NEWing it as we speak
[10:44] <tkamppeter> Can it be that the processing queue is very long due to the upcoming UVF?
[10:44] <pitti> tkamppeter: I had 86 entries in NEW when I started, I'm down to 70
[10:45] <pitti> tkamppeter: s/upcoming//
[10:45] <tkamppeter> UVF and FF are active now? I do not see anything about that in the Topic.
[10:46] <pitti> tkamppeter: https://wiki.ubuntu.com/FeistyReleaseSchedule
[10:46] <pitti> tkamppeter: and it was mentioned several times in yesterday's meeting, too
[10:46] <tkamppeter> Yes, I have seen, but the missing info in the topic made the impression to me that it got delayed.
[10:47] <tfheen> tkamppeter: why on earth would it be delayed?
[10:47] <tkamppeter> tfheen, thanks for updating the Topic.
[10:48] <tfheen> especially given that I explicitly told people that it was in effect at the end of yesterday's meeting.
[10:55] <cjwatson> tkamppeter: The major freezes don't get delayed. Sometimes (very rarely) the releases at the end of them get delayed slightly, but we don't delay the major freezes because (a) there's basically never a good reason to and (b) it just makes it more likely that the release at the end of them will slip
[10:55] <Fujitsu> Am I to presume the 5D5D in front of launchpad.net in the URL in the topic was accidentally inserted?
[10:55] <tfheen> and We Release On Time.
[10:55] <Treenaks> tfheen: *cough*dapper*cough* ;)
[10:56] <tfheen> Treenaks: pft, that was delayed long before release.
[10:56] <tfheen> Fujitsu: thanks, fixed.
[10:56] <Treenaks> true
[10:56] <Fujitsu> Treenaks, heheh.
[10:56] <visit0r> hello, is this known (edgy upgrade fails as of today): Depends: linux-image-2.6.17-11-386 but it is not installable
[10:56] <cjwatson> visit0r: /topic
[10:56] <Fujitsu> Can't we delay Feisty by a couple of months on the day before the current release date?
[10:56] <tfheen> Fujitsu: no.
[10:57] <Fujitsu> Aw... How boring.
[10:57] <cjwatson> Treenaks: obviously /me != sabdfl, but I don't think we'll do that again - the consequences were too painful
[10:57] <Fujitsu> No excitement.
[10:57] <Treenaks> cjwatson: yeah.. I've heard lots of people complain about Edgy..
[10:57] <LaserJock> Fujitsu: maybe we should do it earlier :-)
[10:57] <Treenaks> cjwatson: (especially compared to dapper's polishedness :))
[10:57] <tfheen> Treenaks: edgy was a four-month cycle.  It was insanity.
[10:57] <LaserJock> Fujitsu: like April 1
[10:58] <Fujitsu> Edgy was shocking.
[10:58] <Treenaks> tfheen: I know, I agree :)
[10:58] <Fujitsu> LaserJock: Sounds good :P
[10:58] <LaserJock> I vote for monthly snapshot releases ;-)
[10:58] <Fujitsu> I wonder how things would have turned out if we had made Edgy and Feisty 5-month cycles.
[10:58] <tfheen> LaserJock: we have bi- and thri-weekly ones.
[10:59] <LaserJock> tfheen: well, I was thinking s/snapshot/stable/ but it's 2:00am here
[10:59] <Fujitsu> So, LaserJock... written the 30 or so MIRs yet? :P
[11:01] <LaserJock> ummm
[11:02] <LaserJock> trying to figure out what has a chance of making it
[11:03] <LaserJock> Fujitsu: something about 5 year old apps and unmantained packages ;-)
[11:03] <Fujitsu> Which is/are in the former category?
[11:04] <LaserJock> well, I found a cool "Learn Chinese" app called hanzim
[11:04] <LaserJock> and then drgeo
[11:04] <tkamppeter> Thanks cjwatson, much better organization than with Mandriva.
[11:07] <cjwatson> you can only really do this if you start out being strict about time-based releases
[11:08] <cjwatson> it's incredibly difficult to convert an established organisation to it
[11:08] <cjwatson> GNOME did, but that's highly unusual
[11:09] <tfheen> and it was a huge pain, AIUI.  At least at first.
[11:17] <pitti> tepsipakki: just read your latest 7.2 reply, you rock :)
[11:19] <seb128> Treenaks: to be honest edgy was not that good, feisty will probably be better
[11:20] <tepsipakki> pitti: oh, thanks
[11:21] <Fujitsu> seb128: I can't really see how Feisty couldn't be better. We've got a lot of QA time, and Edgy was terrible.
[11:21] <tepsipakki> some of the drivers are syncable from unstable
[11:22] <pitti> tepsipakki: if you can get a general X.org UVF exception from tfheen and the rest of the upgrade plan is settled and backed up by distro team leaders, we can do the syncs in a big batch; just send me a list
[11:23] <tepsipakki> pitti: well, maybe they should be tested IRL as well :)
[11:23] <pitti> tepsipakki: i. e. don't bother with filing 30 sync requests, if they either get completely denied or accepted
[11:23] <tepsipakki> ah, right
[11:23] <tepsipakki> mesa is the blocker now
[11:24] <pitti> good luck!
[11:24] <tepsipakki> without that I can't test xorg-server, which was a lot of work to put together
[11:24] <tepsipakki> the mesa diff is like 1MB :I
[11:25] <tepsipakki> sorry, 2.5MB
[11:25] <Fujitsu> tepsipakki, sounds good, especially without a patch system.
[11:25] <tepsipakki> yes
[11:25] <tepsipakki> :)
[11:26] <tepsipakki> it's tempting to make it use quilt
[11:26] <tfheen> tepsipakki: have you talked with the Debian people about making it use quilt or something?
[11:26] <tepsipakki> tfheen: not yet, I could do that
[11:27] <tfheen> tepsipakki: I'd like to not end up using one patch system and they another.
[11:27] <tepsipakki> it could just import the xsfbs-stuff from the x-packages
[11:28] <tepsipakki> ok, I'll contact them to get moving
[11:29] <pitti> carlos: would it be possible and reasonably easy for Rosetta to not include new languages into update tarballs?
[11:30] <carlos> pitti: new languages since distrorelease?
[11:30] <pitti> carlos: right
[11:30] <carlos> pitti: new languages since distro release?
[11:30] <carlos> hmmm
[11:30] <pitti> carlos: right again :)
[11:30] <carlos> I could figure a way to do it
[11:30] <carlos> pitti: does it include -base package updates?
[11:30] <pitti> carlos: I could filter them out on rookery as well, but it'd be pretty hackish
[11:31] <pitti> carlos: yes; as soon as we release a distro, we don't want NEW language packs
[11:31] <pitti> carlos: in fact, it particularly affects -base updates
[11:31] <carlos> pitti: I wonder whether is not technically possible to add new languages...
[11:31] <pitti> carlos: since langpack-o-matic already ignores new languages for the 'delta' updates
[11:31] <pitti> carlos: it is technically possible, but NEW packagages in stable releases are generally frowned upon
[11:32] <carlos> pitti: one of the idea of moving to belocales was to be able to add new languages quite easy, isn't it?
[11:32] <pitti> carlos: well, maybe this should be discussed by TB
[11:32] <carlos> TB?
[11:32] <pitti> tech board
[11:33] <carlos> oh, right
[11:33] <tepsipakki> hmm, pkg-mesa-devel equals Marcelo Magallon
[11:33] <carlos> ok, in the mean time, I will see how to add that feature
[11:33] <pitti> carlos: don't bother if it's too complicated
[11:33] <pitti> carlos: would just be nice
[11:33] <carlos> It's just a matter of find the right query ;-)
[11:34] <carlos> like, give me the list of languages that got all pofiles after X date
[11:34] <carlos> pitti: could you file a bug asking for it?
[11:34] <pitti> carlos: sure
[11:34] <carlos> thanks
[11:37] <pitti> carlos: bug 84167
[11:37] <Ubugtu> Malone bug 84167 in rosetta "Please do not export new languages after distro release for langpack-o-matic" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84167
[11:38] <carlos> pitti: thank you
[11:42] <tfheen> ogra: if you're planning on shipping school* for feisty, you should work on getting them fixed and back into your seeds.
[11:43] <Fujitsu> tfheen: That's really non-trivial, especially due to Zope 3 being inoperable :(
[11:43] <tfheen> Fujitsu: that means it can't be shipped for feisty in which case demoting it sounds like a plan.
[11:44] <ajmitch> Fujitsu: did you test out zope3 with a snapshot of the offending package?
[11:44] <Fujitsu> Probably. It's uninstallable in Edgy as well.
[11:48] <tepsipakki> oooh, mesa-6.5.2 _does_ have a patch-system.. and none other than quilt :)
[11:49] <tepsipakki> glad I checked before sending the email
[11:49] <tepsipakki> that version is in experimental, so I skipped it first
[11:50] <pitti> tepsipakki: yay :)
[11:50] <tepsipakki> that makes merging _so_ much easier
[11:50] <pitti> tepsipakki: Debian is in freeze, so experimental is often what we actually want
[11:50] <tepsipakki> yeah
[11:50] <tepsipakki> there were also some drivers, like i810
[11:54] <elkbuntu> ogra, ping?
[12:15] <pitti> hi asac
[12:15] <asac> hello
[12:17] <Tonio_> seb128: I saw you removed my beagled fix for kde
[12:17] <seb128> Tonio_: hi
[12:17] <seb128> Tonio_: right, I removed your breakage :p
[12:17] <Tonio_> seb128: we don't want to patch to get the same autostart than kde for a good reason
[12:18] <seb128> Tonio_: what good reason? that's an xdg spec ...
[12:18] <Tonio_> seb128: the breakage isn't due to the patch :) the current package also ftbfs
[12:18] <seb128> and there is flags to use something only for KDE or GNOME
[12:18] <Tonio_> seb128: yes but do you want people that sue both gnome and kde to have everything autostarting everytime they boot a DE ?
[12:18] <seb128> Tonio_: oh, I didn't look to the build, shipping the autostart twice is the breakage
[12:18] <Tonio_> seb128: yes but that means to patch 50 apps for us... ;)
[12:19] <seb128> Tonio_: and?
[12:19] <Tonio_> seb128: are you sure ?
[12:19] <Tonio_> seb128: I tried to build locally before uploading and it worked ;)
[12:19] <seb128> still doesn't mean that shipping and autostart to /etc and one to /usr is right
[12:19] <seb128> what worked?
[12:19] <seb128> GNOME does look to /etc/xdg/autostart and /usr/share/autostart
[12:19] <Tonio_> seb128: my package :)
[12:20] <seb128> I'm not sure to understand where you want to go
[12:20] <seb128> I'm just saying that shipping a duplicate autostart is wrong
[12:20] <bhale> i dont see why Tonio_ added back the kde autostart files
[12:20] <pitti> Riddell: apport-qt is in the archive; I only tested it under gnome, and there are allegedly some UI bugs due to that; I'd appreciate some feedback about it
[12:20] <bhale> to beagle
[12:20] <bhale> does it not respect the ones beagle creates now?
[12:20] <bhale> upstream
[12:20] <Riddell> thanks pitti, I'll try and look at it today
[12:20] <pitti> Riddell: ping me, then I'll walk you through
[12:21] <Tonio_> Riddell: what should we do on that point concerning kde ?
[12:21] <ajmitch> bhale: looks like there could be more issues with mono 1.2.3
[12:22] <Tonio_> well concerning the build failed, that's not packaging issue, the previous package also fails now
[12:22] <bhale> ajmitch: exciting
[12:22] <Tonio_> seb128: but okay we have to define what to do on that point, I'll discuss this with Riddell
[12:23] <seb128> Tonio_: ok
[12:23] <Riddell> Tonio_: if putting it in /usr/share/autostart means it would start twice in gnome, that's not something we can really do
[12:23] <tfheen> mjg59: is it on purpose that usplash-dev doesn't depend on usplash and that usplash ships the .so symlink?
[12:23] <ajmitch> bhale: quite
[12:23] <Tonio_> seb128: but I already know his feeling on that point as I already proposed to do what you want :)
[12:23] <seb128> Tonio_: if you don't want to use /etc/xdg and need specific .desktop for KDE I suggest creating an /usr/share/kde/autostart or something like that
[12:23] <mjg59> tfheen: Probably not
[12:24] <Tonio_> seb128: riddell is right, I didn't know gnome looked at both.... that means 2 starts for you right ?
[12:24] <Riddell> Tonio_, seb128: but it needs a gnome person to put lots of OnlyShowIn=GNOME; for their autostart files that we wouldn't want in other desktops (which is what I did for KDE)
[12:24] <Riddell> unless they're already there?
[12:24] <seb128> Tonio_: I've not tried if beagle is clever enough to run only one instance, but yes, GNOME looks to /etc/xdg/autostart and /usr/share/autostart
[12:25] <seb128> Riddell: we don't have that many autostarts ;) 
[12:25] <seb128> /etc/xdg/autostart/beagled.desktop:OnlyShowIn=GNOME;
[12:25] <seb128> /etc/xdg/autostart/gnome-power-manager.desktop:OnlyShowIn=GNOME;XFCE;
[12:25] <seb128> /etc/xdg/autostart/gnome-volume-manager.desktop:OnlyShowIn=GNOME;XFCE;
[12:25] <seb128> /etc/xdg/autostart/nm-applet.desktop:OnlyShowIn=GNOME;
[12:25] <seb128> /etc/xdg/autostart/update-notifier.desktop:OnlyShowIn=GNOME;XFCE;
[12:25] <seb128> Riddell: and they use it
[12:25] <Riddell> oh, perfect
[12:26] <Riddell> then someone needs to look at patching KDE for the patch, /me bats eyelids at Tonio_ 
[12:26] <Tonio_> seb128: then patching kde looks a good option, you're right
[12:26] <Tonio_> Riddell: yup, will do that then :)
[12:27] <Tonio_> seb128: sorry for the inconvenience, is I had known gnome lookedat both.... I wouldn't do that that way :)
[12:27] <seb128> Tonio_: np, that was a quick change to do and revert and created no problem
[12:28] <Tonio_> seb128: yup, did you let the change concerning beagle-settings ? the patch didn't apply without it ;)
[12:29] <Tonio_> aka, bad file patched, need to patch the .in.in file
[12:29] <seb128> Tonio_: hum, no, I just dropped the copy from debian/rules
[12:30] <Tonio_> seb128: good, thanks, that's okay then ;)
[12:30] <seb128> np
[12:32] <tfheen> mjg59: 'k; would you mind if I made the soname of usplash actually be libusplash.so.0 and not libusplash.so too?
[12:40] <jwendell> dholbach, good morning
[12:41] <dholbach> hey jwendell - how's it going?
[12:41] <mjg59> tfheen: Go for it
[12:41] <jwendell> dholbach, fine
[12:41] <jwendell> dholbach, can you help me?
[12:41] <dholbach> jwendell: I can try
[12:41] <tfheen> mjg59: cheers.
[12:42] <jwendell> dholbach, in a debian build, where is defined $(DEB_BUILD_OPTIONS) ?
[12:42] <jwendell> dholbach, i have found in rules file something like that:
[12:42] <jwendell> ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
[12:42] <jwendell>   confflags += --enable-debug
[12:42] <jwendell> else
[12:42] <jwendell>   confflags += --disable-debug
[12:43] <dholbach> jwendell: you can set it as an environment variable
[12:43] <jwendell> ah
[12:44] <jwendell> dholbach, thanks
[12:44] <dholbach> jwendell: noopt nostring nocheck debug  are values that I know of
[12:45] <tfheen> s/nostring/nostrip/
[12:45] <dholbach> lalala, yes :)
[12:46] <tfheen> mjg59: also, what's up with the crazy version number?  Any reason to not just use 0.5, 0.6, etc?
[12:51] <mjg59> The numbering is entirely arbitrary
[01:06] <cjwatson> tfheen: I think usplash-dev shouldn't depend on usplash - build-deps shouldn't really pull in stuff that modifies the initramfs
[01:06] <cjwatson> tfheen: if it were repackaged that way, it should be libusplash0, usplash, usplash-dev (or libusplash-dev)
[01:10] <Tonio_> seb128: fyi https://launchpad.net/ubuntu/+source/beagle/0.2.16-0ubuntu3 ftbfs too...
[01:11] <tfheen> cjwatson: hmm
[01:11] <tfheen> cjwatson: I guess I could change that too
[01:14] <jwendell> dholbach, i'm getting this error while running 'debuild' for the second time: any idea how to fix it?
[01:15] <jwendell> Patch 031_x264_link_against_pic.diff does not remove cleanly (refresh it or enforce with -f)
[01:15] <jwendell> make: ** [clean]  Erro 1
[01:15] <jwendell> debuild: fatal error at line 1228:
[01:15] <jwendell> fakeroot debian/rules clean failed
[01:15] <bhale> Tonio_: seb128 this is a classic problem, novell releases new mono compilers without testing against any of their own apps
[01:16] <bhale> Fix a syntax error in the OOo filter that only catches on Mono 1.2.3.  Fixes
[01:16] <bhale> bgo #398303
[01:16] <bhale> this is in svn
[01:17] <bhale> i cant work on it atm
[01:17] <dholbach> jwendell: can you put the package online somewhere so I can have a look?
[01:17] <jwendell> dholbach, it's ffmpeg. I'm just rebuilding it with many codecs support
[01:18] <jwendell> dholbach, i did an apt-get source, added some changelog entry, set env var $(DEB_BUILD_OPTIONS) and ran debuild
[01:18] <jwendell> dholbach, in the first time it builds correctly, or if i run debuild -nc
[01:19] <jwendell> dholbach, but just 'debuild' it fails on  debian/rules clean 
[01:19] <dholbach> jwendell: maybe the clean target is broken if it builds the 1st time, but not the 2nd time
[01:19] <dholbach> jwendell: I think that slomo and siretart know best about that package
[01:20] <jwendell> dholbach, or there is something wrong with that patch in special...
[01:20] <jwendell>  Patch 031_x264_link_against_pic.diff does not remove cleanly (refresh it or enforce with -f)
[01:21] <dholbach> jwendell: I don't know the package - I'd need to download and check myself
[01:21] <jwendell> dholbach, np, don't worry
[01:22] <cjwatson> tfheen: change what?
[01:26] <siretart> jwendell: look at it right now
[01:26] <tfheen> cjwatson: make it into a proper library package.
[01:26] <jwendell> siretart, what did you do?
[01:27] <siretart> IIRC I applied a patch from jdong
[01:27] <cjwatson> tfheen: ah, right
[01:28] <cjwatson> tfheen: dunno whether it's worth it since themes don't link to libusplash anyway
[01:28] <siretart> jwendell: I cannot reproduce your problem
[01:29] <tfheen> cjwatson: true, but other pieces of software does, or could.
[01:29] <tfheen> (casper, uswsusp)
[01:29] <jwendell> siretart, before run debuild, i did this:
[01:29] <jwendell> export DEB_BUILD_OPTIONS=risky
[01:29] <jwendell> siretart, new package is on repository already?
[01:30] <siretart> I'm talking about libx264-dev_0.cvs20070117-0ubuntu3
[01:31] <siretart> jwendell: and that version doesn't check any DEB_BUILD_OPTIONs
[01:31] <jwendell> siretart, i'm already using this package
[01:31] <jwendell> siretart, i'm talking about ffmpeg
[01:32] <siretart> jwendell: oh. I thought you were talking about x264
[01:34] <jwendell> siretart, dholbach, according with changelog, jdong is the guy i need to talk:
[01:34] <jwendell> Make DEB_BUILD_OPTIONS=risky enable more codecs (closes: Ubuntu #76354)
[01:35] <siretart> jwendell: I'd guess so, yes
[01:36] <dholbach> jwendell: good luck with that!
[01:36] <jwendell> hehe
[01:37] <siretart> he does irc from time to time..
[01:38] <dholbach> pitti: nice apport icon :)
[02:14] <Hobbsee> infinity: any plans to fix bug 24741?  it appears to be assigned to you
[02:14] <Ubugtu> Malone bug 24741 in samba "samba account_policy_get fails on install" [Medium,Needs info]  https://launchpad.net/bugs/24741
[02:16] <pitti> BenC: FYI, d-tree-compiler is out of binary new now
[02:18] <tepsipakki> hmm, I wonder if the lesstif build-dep on mesa was dropped because lesstif is in universe?
[02:19] <Riddell> mvo: did you get my e-mail about the packaging fix needed for kubuntu upgrade tool?
[02:20] <mvo> Riddell: yes, I have a plan for this, I will answer in a bit
[02:20] <Riddell> groovy
[02:25] <Hobbsee> pitti: for sync requests filed before UVF - why are you marking these as needing a UVF exception?
[02:25] <pitti> Hobbsee: because we are in UVF since yesterday
[02:26] <Hobbsee> pitti: which is why i ack'd the basket sync last night (before your yesterday)
[02:26] <Hobbsee> with still a few hours to go before the freeze
[02:26] <pitti> well, but we cannot process syncs 24/7...
[02:27] <Hobbsee> of course
[02:27] <pitti> (queue was empty at Wednesday)
[02:27] <Hobbsee> hence my question is "for those filed before the freeze date, shouldnt you be doing them, before UVF?"
[02:27] <tfheen> Hobbsee: if we had infinite resources, we would.
[02:27] <pitti> not really, AFAICS
[02:27] <Hobbsee> seeing as there would be a fair few in the ~12 hours, or whatever it was, presumably
[02:27] <pitti> Hobbsee: it only affected two or three syncs 
[02:28] <Hobbsee> pitti: just one that i wanted :P
[02:28] <pitti> Hobbsee: just get ack from motu-uvf :)
[02:28] <Hobbsee> tfheen: of course.  hence the comment times
[02:28] <tfheen> pitti: I'm not really fuzzed about sneaking them in under the wire for the ones filed yesterday, but your call.
[02:28] <pitti> right, neither am I, I'm just strict about main packages
[02:28] <Hobbsee> pitti: if they're as bad as the whole sru process, or anywhere near it, then it'll be feisty by the time it got into the archive
[02:29] <pitti> Hobbsee: what was the one you need?
[02:29] <Hobbsee> pitti: basket - it's a major kde app
[02:29] <Hobbsee> and utterly unacceptable
[02:29] <Riddell> Hobbsee: basket is universe, it can be approved by motu-sru team

[02:30] <tfheen> Hobbsee: I'm sure the universe-sru team accepts new members. :-)
[02:30] <pitti> Hobbsee: I'm not talking about an SRU
[02:30] <Hobbsee> tfheen: i'm not sure that it's the members that are the problem - it seems the process
[02:30] <Hobbsee> pitti: i know.  i'm comparing, and not doing it well.
[02:30] <pitti> Hobbsee: but motu-uvf -- i. e. just get their approval, that's quick
[02:30] <pitti>  /msg Hobbsee I'll sync it in 'oops' mode now, don't tell anyone
[02:30] <Riddell> two
[02:31] <Hobbsee> pitti: thanks mate :)
[02:31] <Hobbsee> Riddell: ahh
[02:35] <sts> infinity: hey!
[02:35] <sts> infinity: how is it going with mysql-server?
[02:36] <cjwatson> pitti,Riddell: are the bits required to start up apport-qt in place yet?
[02:36] <cjwatson> pitti,Riddell: I get a crash dump output here, but nothing responds to itt
[02:38] <pitti> cjwatson: apport-qt is in the archive
[02:39] <cjwatson> yeah, I've installed it already
[02:39] <pitti> cjwatson: but calling it will be adept-notifier's job
[02:39] <pitti> cjwatson: similar to update-notifier
[02:39] <cjwatson> calling it does not seem to do anything
[02:39] <pitti> cjwatson: thus, if you start /usr/share/apport/apport-qt, you should see the crash
[02:39] <pitti> it's just this glue that is missing
[02:39] <pitti> cjwatson: hm
[02:39] <pitti> cjwatson: /usr/share/apport/apport-checkreports exits with 0?
[02:39] <cjwatson> my crash was from ubiquity, so I need to run it with sudo, but even so
[02:40] <cjwatson> exits 1
[02:40] <pitti> cjwatson: hm, did you open it before calling apport-qt?
[02:40] <pitti> if so, you need to touch it
[02:41] <cjwatson> ah, ok, if I run it as root, it works
[02:41] <pitti> ah, great
[02:41] <cjwatson> is that necessary with apport-gtk? I didn't realise it ran with elevated permissions
[02:41] <sts> infinity: ping?
[02:41] <cjwatson> but I suppose it has to in order to get at crash dumps from stuff running as root
[02:41] <pitti> cjwatson: yes, it is, otherwise you cannot access the reports
[02:41] <pitti> right
[02:42] <pitti> cjwatson: and making the reports world-readable potentially exposes sensitive information
[02:42] <cjwatson> surely they are exposed by virtue of the fact that you can run apport on them :)
[02:42] <cjwatson> exposed via Launchpad ...
[02:44] <pitti> cjwatson: right, that's why we say 'if you did not do anything confidential, you can send a report' 
[02:44] <pitti> although I'm fully aware that this is pretty weak
[02:45] <pitti> the original solution to that was a crash db with restricted access
[02:45] <cjwatson> I meant that some other user might have done something confidential but then you get to send a report and thereby find out what it was
[02:45] <cjwatson> another option would be to attempt to store crash dumps with dropped privileges (via SUDO_UID) but I don't know whether that's possible
[02:45] <pitti> cjwatson: you mean you get him to send it? right
[02:46] <pitti> cjwatson: yes, it would, we can access the process' environment
[02:46] <cjwatson> what I'm wondering is how ubiquity crash dumps get reported, really
[02:46] <cjwatson> I know they do, I'm just wondering how :)
[02:46] <cjwatson> does update-notifier run apport-gtk as root?
[02:46] <pitti> cjwatson: gksudo doesn't ask for a password on the live system
[02:46] <pitti> cjwatson: it does, through gksudo
[02:46] <cjwatson> ok
[02:47] <Riddell> pitti: so how do I run this thing?  /usr/share/apport/apport-qt just exits
[02:47] <Riddell> do I have to crash something first?
[02:47] <pitti> Riddell: yes, you have
[02:47] <pitti> Riddell: 'bash', and then 'kill -SEGV $$'
[02:47] <pitti> Riddell: or just kill -SEGV whatever else you want :)
[02:48] <pitti> Riddell: alternatively, you can call it with '-f -p konqueror' to file a package bug
[02:48] <pitti> Riddell: or with -f -P <pid> to file a bug for a running program
[02:48] <pitti> Riddell: (--help)
[02:50] <Riddell> pitti: that all seems to work except that the bug report doesn't have a body
[02:50] <pitti> Riddell: 'body'?
[02:51] <pitti> Riddell: btw, the UI is still missing a lot of the GTK one's functionality
[02:51] <pitti> mainly due to the lack of an expander etc.
[02:52] <Riddell> we use buttons
[02:53] <Riddell> ooh, it works, it attaches all the files
[02:53] <pitti> Riddell: right, that's the new magic
[02:54] <pitti> Riddell: so, Michael will continue to work on it for the finer aspects, but I urged him to get it principally working for FF :)
[02:55] <seb128> pitti: mvo?
[02:55] <pitti> seb128: no, Michael Hofmann, a friend of mine
[02:55] <seb128> ah ok
[02:55] <seb128> pitti: your friends use KDE? no cookie for you :p
[02:55] <pitti> seb128: no, he uses gnome
[02:55] <seb128> ah
[02:55] <ogra> cjwatson, did anything in the metapackages change i'm not aware of ? my edubuntu-meta suddenly adds ubuntu1 to the version
[02:56] <pitti> seb128: he just needs to program Qt/C++ at work
[02:56] <Riddell> pitti: does the gtk one not catch crashes immediately or does it only wait on update-notifier to find them?
[02:56] <pitti> seb128: and he just likes apport and my new abstract UI design, so he wanted to write a Qt port :)
[02:56] <seb128> you rock ;)
[02:56] <seb128> heh
[02:56] <seb128> ok, fair enough :p
[02:57] <seb128> and I like playing in the snow anyway ;)
[02:57] <pitti> Riddell: update-notifier has an inotify watch on /var/crash; u-n then checks apport-checkreports if there are actually reports for the current user and if so, calls apport-gtk
[02:57] <seb128> pitti: do you know if the new linux upload fixes apport?
[02:57] <pitti> Riddell: or, if apport-checkreports --system is true, calls gksudo apport-gtk
[02:57] <pitti> seb128: not sure, didn't try yet
[02:57] <ogra> tfheen, i'd love to get school* in but that would mean i'd need to port it to the zope we ship. a task which apprently a multi headed upstream team did manage yet ...
[02:57] <pitti> seb128: I saw the changelog for the size limit
[02:57] <pitti> seb128: but not for the stdin flushing
[02:58] <seb128> ok
[02:58] <tfheen> ogra: ok, so you're fine with demoting them for now?
[02:58] <seb128> pitti: if it doesn't I think we should turn apport off by some way until that's fixed
[02:58] <ogra> tfheen, not before i discussed it with them ... do they break anything ? 
[02:58] <pitti> seb128: right
[02:58] <pitti> seb128: I newed new kernels and lrm, so they should actually be in the archive and testable now
[02:59] <pitti> seb128: just no -meta yet
[02:59] <seb128> ok, let me try
[02:59] <tfheen> ogra: they clutter the uninstallability reports and if it's not installable, it's not supportable.
[02:59] <pitti> seb128: can we both test them now?
[02:59] <seb128> trying
[02:59] <seb128> and mvo broke apt :p
[02:59] <Riddell> pitti: sounds not too hard
[02:59] <seb128> elmo: Problem with MergeList /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_feisty_main_i18n_Translation-fr
[02:59] <seb128> elmo: sorry, autocompletion
[02:59] <ogra> tfheen, right, but i dont want to spend days waiting for them to enter main again, please leave them in for now, i'll demote them completely if i know enough from upstream
[03:00] <ogra> (oor get the fixed ones in)
[03:00] <pitti> Riddell: right, and you can essentially use the existing u-n code
[03:00] <pitti> Riddell: it's in a separate .c file
[03:00] <pitti> Riddell: the thing we need to port is the tray icon, the rest should be fine
[03:00] <pitti> Riddell: i. e.:
[03:01] <pitti> Riddell: if notifier is running while a crash happens, it calls the apport UI immediately
[03:01] <Keybuk> why does vim always write a file called 4913 into the working directory?
[03:01] <pitti> Riddell: if the notifier starts and there are already pending crash reports, it just displays a tray icon
[03:01] <pitti> Riddell: likewise for system crash reports, so that people do not unexpectedly get a gksudo slammed into their face
[03:01] <tepsipakki> right, mesa wasn't that bad afterall
[03:02] <pitti> Keybuk: not for me...
[03:02] <Keybuk> pitti: strace it :p
[03:02] <Keybuk> bet you it does
[03:02] <kwwii> Keybuk: doesn't here either
[03:02] <pitti> $ strace -o /tmp/x vim test.txt
[03:02] <pitti> [ typing stuff] 
[03:02] <pitti> [saving}
[03:03] <pitti> $ grep 4913 /tmp/x
[03:03] <pitti> $
[03:03] <pitti> *shrug*
[03:03] <pitti> Keybuk: grep -r the code for id -un == scott ?
[03:03] <Keybuk> pitti: do it as root
[03:03] <Keybuk> quest scott# grep 4913 /tmp/x
[03:03] <Keybuk> lstat("4913", 0x7fffbda19470)           = -1 ENOENT (No such file or directory)
[03:03] <Keybuk> open("4913", O_WRONLY|O_CREAT|O_EXCL, 0100644) = 4
[03:03] <Keybuk> stat("4913", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[03:03] <Keybuk> unlink("4913")    
[03:04] <pitti> Keybuk: nope
[03:04] <mjg59> Keybuk: Can't reproduce here either
[03:04] <mjg59> Got a vimrc anywhere?
[03:04] <kwwii> lol, it is a vim virus
[03:04] <pitti> Keybuk: it's not April 1 yet...
[03:05] <Keybuk> pitti: how did you run it as root?
[03:05] <Keybuk> ah
[03:05] <Keybuk> the file has to already exist
[03:05] <Keybuk> try echo > test.txt
[03:05] <Keybuk> then strace -o /tmp/x vim test.txt
[03:06] <Keybuk> (writing something into the file)
[03:06] <mjg59> Keybuk: Nope
[03:06] <seb128> $ grep 4913 /tmp/x
[03:06] <seb128> lstat64("4913", 0xbfb4ea90)             = -1 ENOENT (No such file or directory)
[03:06] <seb128> open("4913", O_WRONLY|O_CREAT|O_EXCL, 0100644) = 4
[03:06] <seb128> stat64("4913", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[03:06] <seb128> unlink("4913")    
[03:06] <seb128> 
[03:06] <mjg59> Oh, hm.
[03:06] <mjg59> Wait, I've got vim-tiny rather than vim
[03:06] <seb128> does it on my feisty desktop
[03:07] <Keybuk> I have vim-bloaty
[03:07] <pitti> Keybuk: just sudo vim test.txt
[03:07] <Keybuk> pitti: ?
[03:08] <mjg59> Keybuk: vim-full?
[03:08] <Keybuk> yeah
[03:08] <mjg59> vim doesn't seem to do it either
[03:08] <seb128> I've vim-tiny
[03:08] <pitti> Keybuk: vim, vim-common, vim-gnome, vim-gui-common, vim-runtime, vim-tiny
[03:08] <Keybuk> actually, just vim
[03:08] <cjwatson> ogra: that was a semantic change in dch
[03:08] <pitti> Keybuk: and I use the standard text vim (no gnome stuff)
[03:08] <ogra> hmm
[03:08] <Keybuk> ii  vim            7.0-035+1ubuntu5 Vi IMproved - enhanced vi editor
[03:08] <Keybuk> ii  vim-common     7.0-035+1ubuntu5 Vi IMproved - Common files
[03:08] <Keybuk> ii  vim-gnome      7.0-035+1ubuntu5 Vi IMproved - enhanced vi editor - with GNOM
[03:08] <Keybuk> ii  vim-gui-common 7.0-035+1ubuntu5 Vi IMproved - Common GUI files
[03:08] <Keybuk> ii  vim-runtime    7.0-035+1ubuntu5 Vi IMproved - Runtime files
[03:08] <Keybuk> ii  vim-tiny       7.0-035+1ubuntu5 Vi IMproved - enhanced vi editor - compact v
[03:08] <mjg59> No, I still can't reproduce it
[03:09] <cjwatson> ogra: I think you should override it for now by hand to not use ubuntu1, and we can figure out how to deal with it properly lateer
[03:09] <cjwatson> later
[03:09] <Keybuk> quest scott% update-alternatives --display vim
[03:09] <Keybuk> vim - status is auto.
[03:09] <Keybuk>  link currently points to /usr/bin/vim.gnome
[03:09] <Keybuk> /usr/bin/vim.basic - priority 30
[03:09] <Keybuk> /usr/bin/vim.tiny - priority 10
[03:09] <pitti> Keybuk: I have 7.0-164+1ubuntu3
[03:09] <Keybuk> /usr/bin/vim.gnome - priority 40
[03:09] <Keybuk> Current `best' version is /usr/bin/vim.gnome.
[03:09] <ogra> cjwatson, ok
[03:09] <mjg59> Maybe it's a vim-gnome thing, then?
[03:09] <Keybuk> pitti: that does it for me too
[03:09] <pitti> Keybuk: likewise
[03:09] <seb128> vim -> /usr/bin/vim.gnome
[03:09] <seb128> on my box
[03:09] <pitti> Keybuk: vi -> vim.gnome
[03:10] <pitti> Keybuk: much less likely, but I'm on amd64
[03:10] <pitti> you and seb on i386?
[03:10] <Keybuk> pitti: both my amd64 and i386 boxes do it
[03:10] <Keybuk> as do both my edgy and feisty boxes
[03:10] <seb128> I'm on i386
[03:11] <Keybuk> src/fileio.c:3303 onwards
[03:11] <Keybuk> it seems to be how vim decides whether it can write a backup copy
[03:11] <pitti> hah
[03:12] <pitti> Keybuk: why it doesn't just try? that's strange
[03:12] <Keybuk> yeah
[03:12] <Keybuk> and why doesn't it pick a frickin swap/temporary filename?
[03:12] <Keybuk> Feb  9 13:47:30 wing-commander init: /etc/event.d/4913: unable to read: No such 
[03:12] <Keybuk> file or directory
[03:12] <Keybuk> is how I've been noticing it
[03:12] <Keybuk> many people have seen that
[03:12] <pitti> I wonder whether Bram used complex statistical methods to determine that 4913 was the least likely number ever for a file name :-P
[03:13] <pitti> locate 4913 doesn't have any hits here, FWIW
[03:16] <dholbach> does anybody else have problems with network-manager on wired machines?
[03:16] <cjwatson> Keybuk: wow, that's crazy
[03:16] <simira> dholbach: herd3? I'll check
[03:17] <tfheen> dholbach: what kind of problem?
[03:17] <dholbach> tfheen: it says "no wireless devices found", which is fine
[03:17] <dholbach> tfheen: it just doesn't handle eth0
[03:17] <tfheen> dholbach: and restarting it doesn't help?
[03:17] <dholbach> tfheen: no :-/
[03:17] <dholbach> sudo ifconfig eth0 up && sudo dhclient      works
[03:17] <tfheen> dholbach: hmm.  Is this after a suspend/resume or just on boot?
[03:18] <dholbach> no suspend/resume - it's my desktop machine
[03:18] <dholbach> after boot
[03:18] <dholbach> (after bringing up eth0 manually, nm still doesn't see it)
[03:18] <tfheen> hmm
[03:18] <simira> dholbach: ok, so testing on a laptop is not really useful
[03:18] <ivoks> dholbach: b44?
[03:18] <dholbach> i got this since I reboote with the new kernel - but I don't know how this could be related
[03:18] <dholbach> ivoks: b44?
[03:19] <ivoks> dholbach: broadcom ethernet?
[03:19] <dholbach> ivoks: no - once it booted, I'll look up what chip it is
[03:20] <ivoks> dholbach: this happend couple of times to me too, but i had to rmmod b44 and modprobe it again
[03:20] <dholbach> ivoks: which kernel was that?
[03:20] <ivoks> dholbach: dapper's
[03:20] <dholbach> ah
[03:20] <Riddell> pitti: apport-qt seems to work well apart from problems me and colin have reported, shall I add it to the seeds?
[03:21] <pitti> Riddell: which problems in particular?
[03:21] <pitti> Riddell: (apart from the missing adept-notifier glue, of course)
[03:21] <Riddell> pitti: bug 84196 and bug 84202
[03:21] <Ubugtu> Malone bug 84196 in apport "apport-qt crashes while processing crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84196
[03:21] <Ubugtu> Malone bug 84202 in apport "qt restart button broken" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84202
[03:21] <pitti> Riddell: ah, I see; thanks
[03:21] <Keybuk> pitti: it does unlink it before it closes it
[03:22] <elkbuntu> ogra, still around?
[03:22] <cjwatson> Riddell: I just added apport-qt detection to ubiquity, but that isn't so good if adept_notifier hasn't been changed yet
[03:22] <Keybuk> heh
[03:22] <cjwatson> Riddell: should I back that out for now?
[03:22] <Keybuk> you could have fun with vim
[03:22] <Keybuk> create files called 4913, 5036, ...
[03:23] <Riddell> cjwatson: yeah, for now, I doubt adept stuff will get in this week
[03:23] <pitti> cjwatson: maybe yes, until we actually get that working
[03:23] <Keybuk> following the loop at the end of the size of int, until no possible files exist
[03:23] <Keybuk> then try and write a file
[03:23] <Keybuk> vim will lock up in an infinite loop :p
[03:23] <simira> pitti: where is apport-reports filed?
[03:24] <pitti> simira: apport-reports?
[03:24] <cjwatson> Riddell: ok
[03:25] <pitti> Keybuk: I still don't get why vim doesn't just try to use <filename>.bak with O_CREAT|O_EXCL or so...
[03:25] <pitti> Keybuk: ah, O_EXCL is not really portable, I figure
[03:25] <Keybuk> I guess because there might be a backup already there
[03:26] <dholbach> ivoks: skge
[03:26] <ivoks> :/
[03:26] <dholbach> the module was loaded, but it seems the kernel does not automatically enable it (???) - could that be?
[03:27] <simira> pitti: apport is the thing that makes bug report out of crashes, right?
[03:27] <Keybuk> (it's also somewhat interesting that if you start at 4913, and add 123 each time, you exhaust the entire 32-bit integer number space before you reach 4913 again)
[03:28] <pitti> simira: right
[03:29] <simira> pitti: it closed, because it couldn't send the report to launchpad (I wasn't connected to The Internet), and now I want to find the report again...
[03:29] <dholbach> hmmm, -6 works
[03:30] <pitti> simira: ah; touch /var/crash/*
[03:30] <simira> pitti: thanksalot!
[03:31] <tepsipakki> hah, seems that Debian XSF is uploading xorg-7.2 to experimental since yesterday
[03:31] <pitti> tepsipakki: are you in touch with them to avoid duplicate work?
[03:31] <cjwatson> Keybuk: any odd number in place of 123 has that property, due to any odd number and 2^32 being relatively prime
[03:32] <tepsipakki> pitti: I will be
[03:32] <pitti> cool
[03:34] <tepsipakki> most of the libraries seem to be uploaded to experimental already, but they were easy so no effort lost there
[03:40] <jsgotangco> greetings earthlings
[03:40] <pitti> jsgotangco: Qapla'
[03:40] <Hobbsee> ahem.  hey jsgotangco!
[03:40] <jsgotangco> heh
[03:42] <bddebian> Heya
[03:46] <pitti> cjwatson: oh, do you already use pacakge hooks in ubiquity?
[03:47] <pitti> cjwatson: I just noticed that I currently use /usr/share/apport as hook directory, but that is already taken by apport itself; I fixed bzr head to use /usr/share/apport/package-hooks/
[03:47] <Keybuk> cjwatson: oh, of course
[03:51] <zakame> pardon a dumb q, but do we have a working xen on feisty?  all I can find in the available docs are for edgy atm
[03:55] <Nafallo> zakame: zul said no to me last evening
[03:56] <zakame> Nafallo: ah... thanks
[03:56] <zul> zakame: yeah we do...
[03:56] <zakame> zul: er?
[03:56] <Nafallo> zul: haha. I checked /lastlog xen in -kernel and you told me no :-P
[03:58] <Amaranth> it's in universe, no?
[03:58] <Amaranth> build-deps on the regular kernel source, patches it, and rolls a xen kernel, right?
[03:58] <Nafallo> Amaranth: not to my understanding
[03:59] <Amaranth> i thought that was the plan decided in november
[03:59] <zul> zakame: the packages are in universe
[04:00] <zul> its 2.6.19 though
[04:00] <zul> ill write the instructions in the wiki tonight
[04:02] <zakame> zul: rocking! :D
[04:03] <zul> meh..
[04:03] <BenC> pitti: Thanks
[04:03] <Nafallo> haha
[04:05] <dholbach> tfheen, ivoks: it really seems to be a kernel problem - thanks for bearing with me
[04:06] <tfheen> dholbach: oh, np.
[04:12] <pitti> BenC: should the new kernel fix the stdin flushing for core dump? I didn't find that in the changelog?
[04:13] <BenC> pitti: No, I need to build you a test kernel still...been fighting to get all of the kernels building with dtc and lrm and such
[04:13] <BenC> soon as that passes, I'll get back to apport fixes for you
[04:13] <pitti> BenC: ah, ok, just curious; thanks!
[04:14] <pitti> seb128: ^ so maybe I should just disable core dumps for now?
[04:14] <seb128> pitti: yes please do
[04:14] <seb128> we are flooded of useless bugs for a week now
[04:23] <BenC> cjwatson: whenever you get a few minutes, I'm ready for casper testing tips
[04:29] <BenC> pitti: I need device-tree-compiler in main...I filed a MIR for it
[04:29] <pitti> BenC: doing now
[04:29] <BenC> pitti: Thanks!
[04:30] <pitti> BenC: hm, it's not in the queue? nevermind, I'll add it
[04:34] <pitti> BenC: promoted
[05:03] <cjwatson> pitti: oh, ok, wanna change that in ubiquity when you're ready to upload the corresponding version of apport, and I'll upload it?
[05:03] <cjwatson> pitti: I don't think Breaks or anything is necessary in this case
[05:03] <pitti> cjwatson: I agree
[05:03] <pitti> cjwatson: ah, you want me to do the change in ubiquity bzr? sure
[05:03] <cjwatson> pitti: yeah, if you could
[05:03] <pitti> cjwatson: I wanted to upload a new apport today to fix some bugs
[05:03] <dholbach> tfheen: hum, maybe not a kernel problem :-/
[05:04] <pitti> cjwatson: breaking that over the weekend is not terribly bad, WDYT?
[05:04] <cjwatson> BenC: have two more phone calls this afternoon, starting shortly - maybe about an hour?
[05:04] <cjwatson> pitti: I can upload tonight, it's not a problem
[05:04] <pitti> ah, great; I'll commit the change
[05:04] <cjwatson> there's nothing complex in ubiquity head
[05:07] <lfittl> hmm, hard disk encryption using debian-installer or ubiquity will not be possible with feisty, right?
[05:07] <pitti> $ bzr pull
[05:07] <pitti> Using saved location: /media/root/home/cjwatson/src/ubuntu/ubiquity/kde-merge
[05:08] <pitti> bah, bzr shuold be a bit more clever with this
[05:08] <dholbach> tfheen: I reassigned the bug to nm: bug 84218
[05:08] <Ubugtu> Malone bug 84218 in network-manager "skge eth0 does not get enabled automatically on boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84218
[05:09] <dholbach> if there's anything I can do about it, let me know
[05:09] <tfheen> dholbach: what does /etc/network/interfaces look like?
[05:10] <dholbach> tfheen: it just has the 'lo' device
[05:10] <dholbach> tfheen: it works with -6-generic
[05:10] <dholbach> but I can attach it, if you like
[05:10] <tfheen> dholbach: please.
[05:10] <tfheen> dholbach: I'm tempted to say it's a kernel bug if it works with an older kernel
[05:11] <pkl_> tfheen: we've had that discussion on #ubuntu-kernel :-)
[05:11] <dholbach> tfheen: they say that if the device is shown by    ifconfig -a    the kernel has done its deed
[05:12] <tfheen> dholbach: well, I guess.  This is after you have logged in or before?
[05:12] <dholbach> it just doesn't get configured and the nm UI doesn't seem to know that eth0 exists
[05:12] <pkl_> the device is being recognised, but, it is not being automatically configured.
[05:12] <tfheen> hm
[05:12] <tfheen> dholbach: please attach the relevant bit of daemon.log too
[05:12] <dholbach> that's why I attached the  lshal  logs - maybe hal and the new kernel are not happy with each other
[05:12] <tfheen> it's probably a race condition somewhere.
[05:13] <dholbach> tfheen: dameon.log with the new kernel, right? or for both kernels?
[05:13] <tfheen> at least the new would be good, thanks.
[05:13] <dholbach> ok
[05:16] <cjwatson> lfittl: certainly not with ubiquity; I don't think so for d-i, sorrry
[05:16] <cjwatson> but I need to check the current state
[05:18] <pitti> cjwatson: ubiquity apport change committed
[05:18] <lfittl> cjwatson, ok, and what are the chances for feisty+1, at least debian-installer should be possible, as debian has that working already
[05:19] <cjwatson> pitti: thanks
[05:20] <cjwatson> lfittl: it needs cryptsetup to be brought to the point where we're happy with it in main, really
[05:20] <cjwatson> lfittl: the last main inclusion attempt for it was rejected - see http://wiki.ubuntu.com/UbuntuMainInclusionQueue somewhere
[05:20] <lfittl> cjwatson, ok, thanks
[05:21] <dholbach> . o O { reboot-o-mania }
[05:22] <BenC> cjwatson: Sure, just ping me when you get time
[05:24] <dholbach> tfheen: done
[05:24] <tfheen> cheers
[05:37] <pitti> BenC: could you have a 5-second look at bug 83600? is it reasonable to fix this in the kernel itself?
[05:37] <Ubugtu> Malone bug 83600 in linux-source-2.6.20 "Apport fails to pipe core dump" [Undecided,Confirmed]  https://launchpad.net/bugs/83600
[05:38] <BenC> pitti: Checking...
[05:39] <kylem> pitti, makes most sense to put it in the kernel.
[05:40] <BenC> pitti: I think apport needs to check the sanity of the core stuff...I can work around it, but it just makes sense to me that apport assure it is running in a sane environment if possible
[05:40] <pitti> BenC: i. e. apport's init script shuold just disable core_uses_pid?
[05:40] <BenC> Yeah, but then you have to contend with when sysctl init script runs
[05:40] <BenC> I suspect apport comes up after that
[05:41] <BenC> At the same time, core_uses_pid doesn't make any sense for pipes
[05:41] <pitti> right, that's why I'm asking you
[05:41] <pitti> if some init script enables c_u_pid later, I can't do something about it
[05:42] <BenC> but then neither does the % replacement, and the kernel still allows that with pipes
[05:42] <BenC> pitti: I'll work around it be disabling it, and printing a one-time warning about it
[05:42] <BenC> s/be/by/
[05:43] <pitti> BenC: hm, s/disabling/ignoring it for pipes/?
[05:43] <BenC> it will only print the warning first time it happens
[05:43] <BenC> pitti: well, I wont change the sysctl value, I'll just ignore it for pattern expansion
[05:43] <pitti> right
[05:43] <pitti> BenC: great, thanks
[05:56] <pitti> hey AlinuxOS 
[05:56] <AlinuxOS> pitti, ;)
[06:02] <Adri2000> tfheen: only "LP: #bug" will work for ClosingBugsFromChangelog?
[06:09] <pitti> hm, I use 'Closes: LP#84196', but my .changes file doesn't have the magic Launchpad-.. line
[06:09] <pitti> ah, LP: #123
[06:11] <pitti> ah, works fine
[06:13] <mantiena> hi all
[06:14] <mantiena> pitti: hi, do you have some time to talk about gnome-mount backporting to edgy ?
[06:14] <pitti> mantiena: TBH not right now, I'm in deep firefighting mode (see topic)
[06:17] <mantiena> pitti: you are fixing edgy-security kernels problems ?
[06:17] <pitti> mantiena: rather, beating them onto the mirrors
[06:18] <mantiena> pitti: please, tell me when you will have time to talk
[06:18] <pitti> hm, Monday next week? 0700 to 1830 UTC
[06:19] <keescook> seb128: for gnome bug 378454, did Meeks just ask me to commit?  I'd need access for that.  :)
[06:19] <Ubugtu> Gnome bug 378454 in general "crash to ORBit_handle_request function" [Critical,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=378454
[06:20] <seb128> keescook: yeah, I can commit for you if you want
[06:20] <pitti> hey keescook 
[06:20] <keescook> seb128: sure yeah
[06:20] <keescook> hiya pitti
[06:21] <seb128> keescook: we can also try to get you a SVN account if you want
[06:21] <keescook> seb128: sure, why not.  :)  I'm always up for more svn accounts.  :)
[06:22] <siretart> seb128: I've read you are doing archive administration now as well? could you please give back gxine_0.5.11-1ubuntu2 on sparc?
[06:22] <seb128> siretart: hi, I do archive admin (syncs, backports, NEW, ...), not buildd admin ... ;)
[06:23] <siretart> seb128: oh. sorry then. whom to poke?
[06:23] <seb128> np
[06:23] <Adri2000> simira: Tollef
[06:23] <cjwatson> siretart: a member of the launchpad-buildd-admins team
[06:23] <Adri2000> sorry, siretart ^
[06:24] <seb128> siretart: you can usually try to ping tfheen if he's around
[06:24] <siretart> k
[06:33] <ogra> seb128, is it a wanted fact that TimedLoginDelay in gdm isnt able to take values below 30 ?
[06:34] <seb128> ogra: no, and that would be new, I used something like 8 seconds when I played with it some weeks ago and that was working
[06:34] <ogra> hmm
[06:34] <seb128> open a bug, I'll have a look later
[06:34] <ogra> i have a kiosk setup for ltsp running here
[06:34] <ogra> with 
[06:34] <ogra> AutomaticLoginEnable=true
[06:34] <ogra> AutomaticLogin=kiosk
[06:34] <ogra> TimedLoginEnable=true
[06:34] <ogra> TimedLogin=kiosk
[06:34] <ogra> TimedLoginDelay=10
[06:35] <mantiena> pitti: can you allocate few minutes for me today ?
[06:35] <ogra> the initial login is fine, but killing the session, the second login always takes 30 secs
[06:35] <pitti> mantiena: mail pls
[06:36] <seb128> ogra: ah, ok, weird ... open a bug please so we keep track of it
[06:37] <Adri2000> seb128: can you tell me where is my mozplugger upload? uploaded 15 min ago and still no accepted mail...
[06:40] <seb128> Adri2000: what version was that?
[06:41] <Adri2000> 1.7.3-6ubuntu2
[06:41] <Adri2000> Successfully uploaded mozplugger_1.7.3-6ubuntu2_source.changes to upload.ubuntu.com.
[06:42] <ogra> seb128, bug 84239
[06:42] <Ubugtu> Malone bug 84239 in gdm "TimedLoginDelay seems to fail to take smaller values then 30" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84239
[06:42] <ogra> eek ... 
[06:42] <seb128> ogra: danke
[06:42] <ogra> :)
[06:43] <Adri2000> seb128: I've just received the mail
[06:44] <seb128> Adri2000: ok, good
[06:45] <kylem> pitti, ping? do i have to worry about this?
[06:45] <kylem> Rejected:
[06:45] <kylem> UploadError escaped upload.process: File linux-source-2.6.17_2.6.17.1-11.35.dsc
[06:45] <kylem> as mentioned in the changes file was not found.
[06:45] <pitti> kylem: no, you don't
[06:45] <kylem> thanks.
[06:45] <pitti> kylem: cprov and I have monkey-shoved the security updates through soyuz
[06:45] <pitti> kylem: due to the bug mentioned in the topic
[06:46] <kylem> ok.
[06:46] <pitti> kylem: after breaking apt-get dist-upgrade in stables, it's high time to break people's kernels on a Friday evening
[07:04] <pochu> pitti: could you take a look at bug 84231?
[07:04] <Ubugtu> Malone bug 84231 in apport "Feisty - Report problem have a problem" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84231
[07:05] <pitti> pochu: that's a dup of bug 83974
[07:05] <Ubugtu> Malone bug 83974 in apport "[feisty]  apport-gtk is opening a wrong URL" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83974
[07:05] <pitti> pochu: really curious
[07:06] <pochu> pitti: ok, marking it :)
[07:06] <pochu> thaks
[07:06] <pochu> thanks*
[07:06] <pochu> pitti: this one says that he is using firefox 3
[07:06] <pochu> pitti: maybe that is useful
[07:06] <pitti> hm, might be
[07:07] <pitti> pochu: but in the other bug the submitter uses the standard browser
[07:07] <pochu> pitti: would be useful to launch apport from the terminal?
[07:07] <pitti> pochu: not really, that's apport-gtk, and does not have debug output
[07:08] <pochu> oh
[07:11] <pitti> pochu: hm, I don't have the slightest idea about this, I'll add some debugging to the UI
[07:12] <pochu> pitti: ok, do you think 2 reports are enough to confirm this? I say it because I can't reproduce it :)
[07:12] <pitti> pochu: definitively enough; I can't reproduce it either, though
[07:13] <pochu> ok
[07:13] <ogra> seb128, is there a way to disable "fullscreen on f11" ? seems its not set in any metacity gconf keys
[07:13] <pochu> pitti: medium or low?
[07:13] <pochu> I think low :)
[07:13] <pitti> pochu: hm, maybe there's something wrong with that guy's 'prefered applications' gconf keys?
[07:14] <pochu> pitti: maybe :)
[07:14] <seb128> ogra: what app?
[07:15] <ogra> seb128, firefox 
[07:15] <pitti> pochu: I consider it high prio
[07:15] <pochu> pitti: I'll ask them to try to reproduce this in a Feisty clean install
[07:15] <pochu> pitti: ok
[07:15] <ogra> i'm running: devilspie& metacity& firefox
[07:15] <ogra> from .xsession
[07:15] <pitti> pochu: this doesn't sound like deliberate breakage
[07:15] <ogra> seb128, but it was there with ff and metacity alone as well .. looks hardcoded to me 
[07:15] <pochu> pitti: maybe the gconf, as you said
[07:16] <seb128> ogra: there is a "full screen" key to the keybindings capplet
[07:16] <seb128> you can change it
[07:16] <seb128> otherwise that's often a an accelerator for a menu item
[07:16] <mantiena> pitti: to which your email address I should write about  backporting gnome-mount to edgy ?
[07:16] <ogra> seb128, i know .... but its not set to f11
[07:16] <mantiena> martin.pitt@ubuntu.com ?
[07:17] <ogra> seb128, if i set it to "disabled" f11 still works
[07:17] <seb128> ogra: firefox, view, full screen has F11 written
[07:17] <seb128> ogra: then your app declare it as a menu accelerator
[07:17] <ogra> seb128, aaaah , thanks !!!!
[07:17] <seb128> for GNOME apps you can changes them
[07:17] <seb128> for firefox dunno
[07:17] <ogra> i didnt think about ff doing its own thing :)
[07:17] <seb128> use epiphany :p
[07:17] <ogra> well
[07:17] <ogra> depends how many deps that pulls in
[07:17] <ogra> its a kiosk setup for low level thin clients
[07:18] <seb128> the epiphany remark was rather a joke, I know you try keeping depends low
[07:18] <ogra> i would even go withut wm if ff would be able to get the screen geometry right
[07:18] <seb128> anyway, blame firefox ;)
[07:18] <ogra> yeah
[07:18] <ogra> :)
[07:19] <cjwatson> can't see anything for that in about:config, but asac might know
[07:19] <ogra> i think you can set it somehow with a prefs.js setting ... not sure they are all in about:config
[07:20] <ogra> there are some ff howtos for kiosk ...
[07:21] <cjwatson> pitti: when should I upload that version of ubiquity?
[07:21] <pitti> cjwatson: whenever you want, apport is uploaded
[07:21] <cjwatson> pitti: you missed the symlinks, btw - fixing
[07:21] <pitti> symlinks?
[07:21] <pitti> cjwatson: hm, sorry
[07:21] <cjwatson> pitti: are those still needed? I have symlinks for ubiquity-frontend-{gtk,kde}.py
[07:21] <pitti> cjwatson: oh, indeed they are
[07:22] <pitti> cjwatson: I'm terribly sorry, must have missed it in the grep
[07:22] <cjwatson> no worries, easy to fix
[07:22] <pitti> 'k, stables are happy again, gotta run now
[07:22] <cjwatson> just thought I'd mention in case you need to change them in the future
[07:22] <pitti> have a nice weekend everyone!
[07:22] <pitti> cjwatson: right, will remember
[07:22] <cjwatson> have fun
[07:24] <pochu> bye pitti :)
[07:28] <mantiena> pitti: bye
[07:38] <mvo> cjwatson: do you know of a way to generate the multi-line description for a debconf note dynamically 
[07:39] <mvo> cjwatson: ucf is (ab)using debconf to ask questions, but for displaying the diff it falls back to a terminal. that can be rather confusing when the gnome-debconf frontend is used. I was wondering if I could make it generate a note instead and show that
[07:43] <cjwatson> mvo: yeah, see the documentation of the 'escape' capability in debconf-devel(7)
[07:43] <seb128> tfheen: you forgot to make libusplash0 Replaces usplash
[07:43] <cjwatson> hmm, I'm not convinced that pitti did actually upload apport_0.52
[07:44] <seb128> cjwatson: feisty-changes had it mentioned already
[07:44] <seb128> or you mean 0.52 is not 0.52 code actually?
[07:44] <cjwatson> oh, ok, I'm just stupid then
[07:44] <cjwatson> no, it's ok, I was just stupidly thinking that locate(1) output would be current, which is obviously not true
[07:45] <seb128> k
[07:45] <asac> ogra: only some key settings are available through prefs mechanism in ffox (if that is what you asked about) ... look http://www.mozilla.org/unix/customizing.html#keys
[07:46] <ogra> asac, yep, already read that one ...
[07:46] <asac> :)
[07:47] <ogra> apparently i could tweak platformHTMLBindings.xml and add an empty keybinding for VK_F11 ...
[07:47] <asac> don't know what your primary goal is :)
[07:48] <ogra> disable f11
[07:48] <asac> of course ... but why?
[07:48] <ogra> for an kiosk mode
[07:49] <ogra> in ltsp i install a minimal kiosk system thin clients can netboot ... 
[07:49] <asac> now I get it :)
[07:49] <ogra> it contains only the kernel, X, gdm metacity and firefox booting from a readonly nfs export and mounting allwriteable pieces to a tmpfs
[07:51] <ogra> on boot t starts gdm and runs an autologin that executes ~/.xsession ... which contains metacity, devilspie and ff ... devilspie forces the ff wint to fullscreen now if a user presses f11 twice he gets into windowed mode
[07:52] <asac> just curious ... only local mounts writable or remote ones too?
[07:52] <ogra> only tmpfs mounts writeable
[07:52] <ogra> i.e. the data is gone after reboot ...
[07:53] <ogra> the kiosk accounts home dir for example is a tmpfs ...
[07:53] <hile> fyi, 1st boot  with  cleaned up cryptsetup script (no lvm or evmps stuff) - the cleanup was really trivial anyway
[07:54] <ogra> hile, did you csee the main inclusion report ? 
[07:55] <mvo> cjwatson: rock!  that was the mising bit I needed!
[07:55] <hile> still should clean up hook side, but  I didn't promise to do that ;)
[07:55] <hile> og, yeah
[07:55] <ogra> hile, feel free to abuse me as upload bith if you have a proper patch ...
[07:56] <ogra> *upload bitch indeed
[07:56] <cjwatson> mvo: you need Depends: debconf (>= 1.4.72)
[07:56] <hile> ack
[07:57] <hile> took me like 5min to do this cleanup, I've been just busy with studio stuff ;)
[07:57] <mvo> cjwatson: thanks, updated
[07:57] <ogra> heh
[07:57] <hile> got a new mixer ... but that's quite off-topic ;)
[08:08] <vdepizzol> Hello. I'm creating a ubuntu-Brazil website layout. Would it be useful for ubuntu.com? http://img174.imageshack.us/img174/1219/ubuntuhomejn0.png
[08:10] <_ion> I thought ubuntu.com already had one. :-)
[08:12] <sfllaw> tfheen: Bug 83818 and bug 84241 are getting lots of hits.  It looks like gnome-panel is crashing awfully often, and apport isn't getting useful info.
[08:12] <Ubugtu> Malone bug 83818 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV" [Medium,Needs info]  https://launchpad.net/bugs/83818
[08:12] <Ubugtu> Malone bug 84241 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84241
[08:41] <tfheen> sfllaw: I'd guess it's the size limitation in the kernel hitting us; ask pitti about it.
[08:47] <tepsipakki> XSF will upload xorg-server-1.2.0 to experimental later tonight :)
[08:47] <sfllaw> tfheen: Still, it looks like gnome-panel got a lot of bugs filed against it recently...
[08:47] <sfllaw> pitti: ^^^ ?
[08:48] <tfheen> sfllaw: pitti's not here.
[09:15] <mvo_> cjwatson: if you have a moment, could you please check http://librarian.launchpad.net/6383644/ucf_2.0017ubuntu1.debdiff for any potential problem? if it loosk good I will submit it to debian
[09:17] <mvo_> other shell wizards are welcome to have a look too of course :)
[09:19] <cjwatson> mvo_: | debconf-2.0 is unfortunately wrong now because cdebconf doesn't support the escape capability yet
[09:20] <cjwatson> mvo_: the Description should be "Differences in ${FILE}" with an extra subst, or similar
[09:20] <mvo_> cjwatson: I see. do you think this could be a major hurdle for accepting the patch? I would like to get it at lest into ubntu because the current way is not UI friendly
[09:21] <mvo_> cjwatson: good point, I fix the ${FILE} thing now
[09:21] <cjwatson> mvo_: you should unset the capb escape (db_capb, no arguments) when you're finished with it, and only bracket the db_subst with the db_capb change, not the whole thin
[09:21] <cjwatson> g
[09:21] <cjwatson> mvo_: does ucf use db_capb backup?
[09:21] <cjwatson> because note that db_capb replaces the current client capability list, it doesn't add to it
[09:21] <roico> hi... is universe freezed too? or packages can still be added there?
[09:21] <cjwatson> mvo_: you definitely need to quote the $(...) in the db_subst command
[09:22] <mvo_> cjwatson: db_capb is only called in my patch, nowhere else
[09:22] <cjwatson> mvo_: ok, but the db_capb changes I suggested should be made anyway
[09:22] <cjwatson> mvo_: don't use echo -e, that's a bashism and wrong here anyway; use printf %s "$DIFF" | debconf-escape -e
[09:22] <cjwatson> otherwise you'll double-escape things
[09:23] <Adri2000> roico: no, universe is not frozen, except for new upstream releases
[09:23] <mvo_> thanks a lot! good that I asked you :)
[09:23] <cjwatson> mvo_: you don't need to do fset seen false; reset does that for you
[09:23] <cjwatson> mvo_: same quoting goes for all the DIFF=$(...), should be DIFF="$(...)"
[09:23] <roico> Adri2000, what do you mean "new upstream releases"?
[09:24] <Adri2000> new versions
[09:24] <cjwatson> (basically, in shell, you should never type $ without putting quotes around it, unless you know that it's one of the cases where you shouldn't
[09:24] <cjwatson> )
[09:25] <cjwatson> mvo_: the error message if show_diff doesn't get passed an argument seems a bit wrong
[09:25] <cjwatson> mvo_: the rest looks fine
[09:26] <cjwatson> mvo_: I'd test with a diff that involves backslashes, tabs, and literal stuff like \\t\\\t\n\\n
[09:26] <cjwatson> make sure it all gets preserved properly
[09:26] <mvo_> *nod*
[09:28] <mvo_> cjwatson: rock, thanks! that was a great help
[09:28] <cjwatson> good luck, hope it works :)
[09:28] <cjwatson> one of these days I'll fix base-passwd to use debconf, but that's harder because it needs to be more structured
[09:38] <mvo> cjwatson: everything seems to work, I will will see if manoj likes the diff now :)