[12:39] <lamont> BenC_: with luck, I'll have -9.20 abi and module files for you shortly
[12:39] <lamont> as in, within an hour or 2
[12:39] <lamont> :(
[12:41] <lamont> then comes lots of figuring out with hppa64 kernels, following which I'll need  an ABI bump because we finally fixed that kernel (and can turn SMP on...)
[01:09] <LaserJock> soren: I don't know that you want to do that. It might bite back ;-)
[01:12] <soren> LaserJock: It's been biting my ass for just about three hours now. I say the curse is well deserved.
[01:15] <LaserJock> soren: working on ebox?
[01:15] <soren> LaserJock: Sure am.
[01:16] <soren> Going on holiday next week for a few week (honeymoon on Bali, no less), so I'm in a bit of a hurry to get it done by this week (ff is while I'm away).
[01:16] <LaserJock> soren: I had a look at the screenshots at the ebox website,  very nice looking
[01:17] <ajmitch> soren: honeymoon?
[01:17] <soren> LaserJock: Yeah, it does look shiny, doesn't it? :)
[01:17] <LaserJock> soren: honeymoon?!? congrats
[01:17] <soren> ajmitch: Indeed.
[01:17] <soren> Wedding on Saturday.
[01:17] <ajmitch> I never knew, I presume congrats are in order
[01:17] <soren> LaserJock: Thank you very much.
[01:18] <ajmitch> soren: since you've travelling all the way to bali, you may as well visit NZ as well
[01:19] <LaserJock> heh
[01:19] <LaserJock> ajmitch: how far is it from you?
[01:20] <ajmitch> probably 7-8 hours or so by plane, I guess :)
[01:20] <LaserJock> hmm, that's not *too* bad
[01:20] <ajmitch> not for this area of the world :)
[01:20] <LaserJock> considering darn near everything is a long flight away from NZ
[01:21] <ajmitch> ah, looks like it's closer to 10, since you have to stop in australia
[01:21] <soren> LaserJock: Nah, I keep quiet about it, too. :)
[01:21] <soren> ajmitch: When I've made it to Bali, I don't think I want to sit on a plane much more.
[01:21] <soren> ajmitch: :p
[01:22] <ajmitch> soren: 30+ hours isn't too much of a problem, is it?
[01:22] <soren> ajmitch: AAAAAAAAAAAAAAARGH!
[01:23] <bhale> hi ajmitch
[01:23] <ajmitch> hello bhale
[01:24] <ajmitch> ah, another server team meeting at an insane time
[01:25] <soren> ajmitch: Sorry dude, but I really hope there's not going to be another UDS in Australia or NZ anytime soon. I'd go sitting on a plane that long.
[01:25] <soren> ajmitch: I've only got about 12 hours of battery power on my laptop. That's 18 hours of staring into the back of the chair in front of me.
[01:25] <ajmitch> boston should be fairly close for you then
[01:26] <LaserJock> I read a while ago about some Australian researchers working on quantum teleportation, now I know why ...
[01:26] <soren> ajmitch: I don't really know how long it'll take to get there. 7-8 hours, I think.
[01:26] <LaserJock> probably
[01:26] <soren> LaserJock: Yeah. To get the fsck away from there, right now! :)
[01:27] <LaserJock> it took me about 9-10 to get to Paris/Sevilla
[01:27] <LaserJock> me neither
[01:28] <ajmitch> busy with the phd?
[01:28] <LaserJock> yeah
[01:28] <soren> LaserJock: That bad?
[01:28] <LaserJock> if I can sneak off for a couple days from UES I might
[01:28] <LaserJock> soren: umm... yeah
[01:28] <soren> LaserJock: Oh, you are doing UES at least?
[01:28] <LaserJock> I might
[01:29] <LaserJock> if it's short
[01:29] <LaserJock> in Sevilla it was just 2 days
[01:29] <LaserJock> that wouldn't be bad
[01:29] <soren> LaserJock: Well, if all the time you've put into Ubuntu was time you should have spent on your ph.d.... Yes, then I can definitely understand you've got some catching up to do. :)
[01:29] <zul> hey
[01:29] <ajmitch> soren: how's the server stuff looking now?
[01:29] <ajmitch> hello zul
[01:29] <zul> hey ajmitch
[01:31] <LaserJock> soren: yes, plus UDS is where I get sucked into implementing all kinds of crazy fun things
[01:32] <zul> heh evil
[01:32] <soren> LaserJock: Good point, but I don't suspect UES is much better in that respect.
[01:33] <LaserJock> soren: actually it is more corporate/marketing
[01:34] <soren> ajmitch: We're trying to get everyone up to speed. For Gutsy we're mostly polishing the existing stuff, we've got and adding a few extra things (eBox and AppArmour), but gutsy+1 is going to rock, I think.
[01:34] <soren> LaserJock: Oh, I thought it was a development thing, just for edubuntu. Go figure.
[01:35] <LaserJock> soren: no, it's more about educators and "decision makers"
[01:35] <LaserJock> we still do all the hardcore development stuff at UDS
[01:36] <ajmitch> great, I haven't been following it closely
[01:48] <soren> ajmitch: The server team meetings are all going to be at that time, by the way.
[01:48] <ajmitch> soren: I was about to ask you if they could ever be shifted by 8 hours either way
[01:48] <ajmitch> otherwise I'll never turn up
[01:49] <ajmitch> 3AM just isn't possible when i've got to be at work at 8:30AM :)
[01:49] <soren> ajmitch: We put it there as that was the only option it it were to be within mine, kees', mathiaz' and rick's core hours.
[01:49] <soren> ajmitch: Noone has made a fuss over it yet.. (hint)
[01:50] <soren> ajmitch: Bah.. It's almost 2 am here, too, and I've got work at 8.
[01:50] <zul> ajmitch: its all about priorities ;)
[01:50] <zul> soren: yeah but you probably work from home right?
[01:50] <soren> ajmitch: Although, getting to work in my case means rolling out of bed an wandering over to my laptop.
[01:50] <ajmitch> zul: right, and the server team slips far down the list with meeting times like that :)
[01:50] <soren> zul: Indeed.
[01:51] <ajmitch> I'm not going to make much of a fuss, since I hardly do anything lately
[01:52] <ajmitch> it's hardly fair on others to shift a meeting just because 1 person is semi-interested :)
[01:52] <soren> ajmitch: There might be other geographically challenged people. :)
[01:53] <zul> australians? ;)
[01:53] <soren> Those are the ones.
[01:53] <soren> And kiwis.
[01:53] <soren> True. If only geography was their only issue. :)
[02:09] <keescook> ajmitch: I'll bring it up tomorrow.  there was brief discussion about meeting weekly (and having it shift around).
[03:05] <ajmitch> keescook: ok, thanks
[03:31] <mjg59> calc: Could you build the package from http://www.codon.org.uk/~mjg59/tmp/x86_debug , install it on your laptop and then do
[03:31] <mjg59> vbetool post 2>output
[03:31] <mjg59> and compress the output then stick it somewhere?
[03:31] <mjg59> It may take a couple of minutes to fail
[03:31] <mjg59> And you'll probably end up with a blank screen at the end of it
[03:31] <mjg59> So just ctrl+alt+del
[04:36] <calc> mjg59: i need to run that on amd64 right?
[04:49] <mjg59> calc: Yes
[04:57] <calc> mjg59: ok
[05:59] <calc> mjg59: about to do the test, be back in a few minutes
[06:02] <calc> mjg59: is there a way to force it to sync immediately to disk?
[06:02] <calc> mjg59: the log ended up being 0 bytes
[06:02] <calc> should i just mount the fs in sync mode?
[06:07] <mjg59> calc: How did you reboot?
[06:27] <calc> mjg59: back now
[06:27] <calc> mjg59: hmm oh yea i probably did it wrong :\
[06:28] <calc> mjg59: i did magic sysrq s u b
[06:28] <calc> mjg59: i got a 1.6MB log using mount sync though
[06:28] <calc> mjg59: i can retry using ctl-alt-del if that will sync out the disk properly without needing mount sync
[06:28] <calc> mount sync seem to cause it to write very slowly
[06:30] <calc> mjg59: http://cheney.ws/debug/vbetool.debug.output.bz2 <- what i have so far, i'll try ctrl-alt-del without sync mount
[06:30] <calc> mjg59: brb
[06:39] <calc> back
[06:40] <calc> mjg59: ah by doing ctl-alt-del i got a much larger log file
[06:40] <calc> -rw-r--r--   1 root root 678732584 2007-07-30 18:38 vbetool.debug.output
[06:40] <calc> hopefully that log file will have what you need ;)
[06:41] <calc> mjg59: ping
[06:44] <calc> ah 5.9MB
[06:51] <calc> hmm its not actually done yet
[06:55] <calc> 7z was faster than bzip2, weird
[07:03] <calc> mjg59: i replaced the file on my server with the compressed 678MB one
[07:22] <pitti> Good morning
[07:23] <ajmitch> morning pitti
[07:23] <pitti> hey ajmitch!
[07:39] <StevenK> Morning pitti
[07:39] <pitti> hey StevenK
[07:43] <StevenK> pitti: Both libgtkdatabox-0.7.0-0{,-dev} can be NBS'd out. Best of all, I didn't have to do anything.
[07:45] <pitti> cool :)
[07:46] <pitti> StevenK: done, merci
[07:47] <StevenK> pitti: Thanks.
[07:47] <StevenK> infinity: Ping! I bet you even know what about. :-P
[07:55] <StevenK> pitti: It looks like most of non-kernel NBS stuff will be dealt with when sear actually gets fixed.
[07:59] <mjg59> calc: Thanks!
[07:59] <mjg59> I probably won't have time to look at it until later in the week
[08:28] <calc> mjg59: ok no problem, there is quite a lot of logging there, heh
[08:37] <pitti> StevenK: ah, cool, BenC fixed lrm, so it only takes a d-i rebuild now to get rid of the old kernel
[08:58] <pitti> cjwatson_: -9 kernel is the default now (just NEWed); can we have a d-i rebuild against that?
[09:04] <Hobbsee> morning pitti
[09:04] <pitti> hey Hobbsee!
[09:05] <Hobbsee> :)
[09:07] <Burgundavia> hey pitti, Hobbsee
[09:07] <Hobbsee> hiya Burgundavia!
[09:18] <LaserJock> pitti: do you think you might have time to look at the edubuntu-addon-meta MIR today or tomorrow?
[09:18] <superm1> hi Hobbsee. sometime back we were chatting about building mythbuntu isos in the datacentre and the discussion moved over to about meta packages.  Do you think the mythbuntu meta packages should be destined directly to universe or to main?
[09:18] <pitti> LaserJock: yeah, I think so; that should be trivial
[09:19] <superm1> or do they have to enter into universe and then move to main?
[09:19] <Hobbsee> superm1: well, any metapackages will need all it's deps in main too
[09:19] <Hobbsee> exactly
[09:19] <Hobbsee> with main inclusion reports, etc
[09:19] <superm1> well there is no way that it can have all its deps moved into main
[09:19] <superm1> that's for sure
[09:19] <LaserJock> pitti: I'd really appreciate it if you have time. I know you're a busy man
[09:19] <Hobbsee> superm1: then it goes to univeres.
[09:19] <Hobbsee> superm1: but you can use recommends for tha tnow, and they get auto-installed
[09:20] <superm1> Hobbsee, would you have a few moments to look it over by chance?
[09:20] <LaserJock> superm1: basically all apps start in Universe and get promoted to Main
[09:20] <seb128_> re
[09:20] <Hobbsee> infinity: why?
[09:20] <Hobbsee> seb128_!
[09:20] <seb128_> did anybody replied to my question about who uploaded gdm during the night? ;)
[09:20] <Hobbsee> superm1: look which over, sorry?
[09:20] <infinity> Hobbsee: https://wiki.ubuntu.com/MobileAndEmbedded/Bootstrap?action=diff
[09:20] <pitti> LaserJock: np; please do keep pinging me about MIRs that block your work
[09:20] <Hobbsee> seb128_: Changed-By: Mario Limonciello <superm1@ubuntu.com>
[09:20] <superm1> Hobbsee, the meta package that i've got put together thus far: http://revu.tauware.de/details.py?upid=6251
[09:21] <pitti> LaserJock: with the multitude of existing MIRs, with many of them being low priority or entirely forgotten about, this is sometimes necessary :)
[09:21] <infinity> Hobbsee: Just realised that procps didn't include /bin/kill because of that. :(  (doesn't install kill on non-linux systems)
[09:21] <Hobbsee> seb128_:
[09:21] <Hobbsee>    * debian/gdm.templates:
[09:21] <Hobbsee>      - Fix template to point to /usr/sbin/gdm not /usr/bin. (LP: #129017)
[09:21] <seb128_> Hobbsee: that's I've noticed, but he doesn't have main upload right, does he?
[09:21] <superm1> No i dont :)
[09:21] <Hobbsee> seb128_: i'm presuming there was a sponsor involved.
[09:21] <LaserJock> pitti: ok thanks.
[09:21] <seb128_> Hobbsee: thanks, but I was able to read the changelog as well ;)
[09:21] <Hobbsee> seb128_: well, i was wondering :P
[09:21] <superm1> keescook uploaded it earlier today
[09:21] <seb128_> Hobbsee: yeah, that's what I'm asking, who uploaded
[09:21] <superm1> seb128_, was there something wrong with that being done?
[09:22] <seb128_> superm1: yes, desktop updates should be coordinate with the desktop team
[09:22] <seb128_> especially when the DesktopTeam TODO wiki page mention that somebody is working on the new version
[09:22] <superm1> sorry seb128_ .  Was a small fix that appeared to be an oversight
[09:22] <seb128_> yeah, there is a bunch of them
[09:22] <seb128_> and I'm going to fix them with the new version upload
[09:23] <seb128_> no problem, thanks for the work ;)
[09:23] <superm1> i'll check with you in the future if i catch small things like that first :)
[09:23] <seb128_> still, we need coordination for desktop uploads
[09:23] <seb128_> do you know who sponsored your upload?
[09:23] <seb128_> superm1: no need, the bug and patch were welcome ;)
[09:23] <Hobbsee> superm1: http://revu.tauware.de/revu1-incoming/mythbuntu-meta-0707301215/mythbuntu-meta-0.1/update.cfg looks incorrect - does that give you ubuntu seeds, or mythbuntu seeds?
[09:24] <superm1> Hobbsee, it gives mythbuntu seeds overlaid on ubuntu ones
[09:24] <superm1> ( is my understanding at least )
[09:24] <Hobbsee> ....er....
[09:24] <superm1> that's why i ask someone who works with seeds to look :)
[09:25] <pitti> LaserJock: approved and promoted, thanks
[09:25] <seb128_> pitti: speaking about MIR, do you plan to look at tracker soon? ;)
[09:25] <LaserJock> pitti: way cool, thank you very much
[09:25] <Hobbsee> superm1: right.
[09:25] <pitti> LaserJock: btw, for simple things like that we don't really need an MIR, but thanks for filing one
[09:26] <pitti> seb128_: depends on the urgency; what's the plan for it?
[09:26] <pitti> hi mvo
[09:26] <seb128_> pitti: getting it on the desktop for next tribe
[09:26] <LaserJock> pitti: ok, well I was just trying to do it properly ;-)
[09:26] <infinity> G'morning, mvo.
[09:26] <Hobbsee> superm1: okay, there are multiple errors in this.
[09:26] <pitti> seb128: oh, I see
[09:27] <superm1> Hobbsee, directly in that package, or within the mythbuntu.gutsy seed branch?
[09:27] <pitti> seb128: will beagle be dropped?
[09:27] <LaserJock> pitti: do package automatically get moved to Main or does it take a new upload?
[09:27] <mdke> LaserJock: hi
[09:27] <Hobbsee> superm1: in that package.  didnt look at the seed branch
[09:27] <seb128> pitti: beagle has never been on the desktop ;)
[09:27] <LaserJock> mdke: hi!
[09:27] <pitti> LaserJock: not automatically, I do that with a soyuz command
[09:27] <superm1> er Hobbsee do you want to carry this over to #ubuntu-mythtv or #ubuntu-motu to not clutter -devel
[09:27] <pitti> LaserJock: it'll be in main after next publisher run (in 1:10 hours)
[09:27] <mdke> LaserJock: digame
[09:27] <pitti> seb128: right, I meant main
[09:27] <mvo> hey pitti, infinity
[09:27] <Hobbsee> superm1: yeah, i was about to say that.  figured i'd check exactly what was wrong first
[09:28] <seb128> pitti: I don't plan to, no
[09:28] <pitti> seb128: does tracker have some reasonable g-p-m integration, like stopping grinding the disk when you are on battery and such?
[09:28] <seb128> pitti: yes
[09:28] <pitti> goood
[09:28] <pitti> seb128: *hug*
[09:29] <seb128> ideally we should have installed it earlier in the cycle
[09:29] <seb128> but upstream took some time to roll the new 0.6
[09:29] <seb128> that's why I want to hurry now and get it for next tribe
[09:29] <seb128> so it can get testing
[09:30] <LaserJock> cjwatson_: pitti has approved/promoted edubuntu-addon-meta , in a few hours the debian-cd patch I sent should work
[09:30] <pitti> seb128: ok, looking now
[09:30] <seb128> pitti: thanks
[09:47] <pitti> seb128: does tracker use the sqlite3 backend by default?
[09:47] <pitti> seb128: it also supports qdbm, but I'd rather not have it in main, too
[09:50] <seb128> pitti: yeah, I think it uses sqlite
[09:51] <seb128> pitti: you want to build it without qdbm?
[09:51] <seb128> should be fine
[09:51] <pitti> seb128: as I said, qdbm is in universe, and I'd rather leave it there
[09:51] <seb128> works for me
[09:51] <pitti> seb128: I figure one backend is enough, and sqlite3 is nice and fast
[09:51] <seb128> right
[09:52] <pitti> seb128: so it requires a change before we can promote it
[09:52] <pitti> "Dependencies: all in main"
[09:52] <StevenK> pitti: Or worse, not checking ... ?
[09:53] <seb128> pitti: I think the wiki page has been made before 0.6 which has been uploaded yesterday
[09:53] <pitti> yeah, possible
[09:53] <Hobbsee> ooh, penalty cards!
[09:53] <seb128> pitti: same for libunac1-dev
[09:54] <Hobbsee> ('bad card, my rule!')
[09:54] <pitti> seb128: I guess it boils down to removing the b-deps
[09:54] <seb128> yes
[09:54] <pitti> seb128: still doing some security review (I just verified all those nasty sprintf() with %s)
[09:55] <seb128> ok
[09:56] <pitti> StevenK: forget about ia64; it's hopelessly out of date
[09:57] <pitti> StevenK: if there are only rdepends on ia64 I don't hesitate to remove NBS packages
[09:58] <RAOF> M,tcm.M!
[09:58] <pitti> seb128: the qdbm backend also has a lot of sprintfs and unchecked mallocs, but I didn't bother to look at them
[09:58] <pitti> RAOF: bless you
[09:58] <seb128> ok
[09:59] <StevenK> pitti: In which case, [17:54]  < seb128> pitti: I think the wiki page has been made before 0.6 which
[09:59] <StevenK> Blah.
[09:59] <StevenK> pitti: In which case, you can kill libjasper-1.701-1.
[09:59] <pitti> \o/
[10:00] <pitti> StevenK: *flush*
[10:00] <StevenK> pitti: Yay
[10:00] <Hobbsee> StevenK: er, why?
[10:00] <Hobbsee> StevenK: wasnt that in main for a while, too?
[10:00] <StevenK> Because it doesn't build and I hate it. :-)
[10:01] <StevenK> And nope, pdftk has always been in universe.
[10:01] <Hobbsee> no, the libjasper*
[10:01] <StevenK> Ah
[10:02] <RAOF> Aww, crap.
[10:02] <RAOF> Password changing time!
[10:02] <StevenK> Hobbsee: Yeah. libjasper-1.701-1 is old, and no longer built by the jasper source package.
[10:02] <Hobbsee> StevenK: ah right.  i thought that was the most recent, for some reason
[10:03] <pitti> RAOF: ugh, poor you
[10:03] <pitti> RAOF: file a critical bug
[10:03] <RAOF> It's already there, I think
[10:03] <RAOF> But I'll check, after the movie :)
[10:03] <StevenK> Hobbsee: Ah. Nope, 1.900 is the most recent
[10:04] <Hobbsee> cool
[10:07] <Amaranth> RAOF: it's there
[10:07] <Amaranth> gnome-screensaver doesn't lock the screen in the right way, iirc
[10:07] <Amaranth> haven't really looked into it much yet
[10:07] <pitti> seb128: https://wiki.ubuntu.com/MainInclusionReportTracker?action=diff
[10:09] <seb128> pitti: thanks
[10:34] <Greg__> hi where can i get ubuntu keys
[10:35] <soren> Greg__: Ubuntu keys?
[10:35] <Greg__> for sources
[10:35] <soren> I not with you... Keys?
[10:35] <Greg__> i wanna switch drom debian to ubuntu by changing source list
[10:35] <Hobbsee> gpg keys, probably
[10:36] <Hobbsee> Greg__: any reputable keyserver will have the ubuntu ftpmaster public key on it...
[10:36] <cjwatson_> pitti: sure, I'll do d-i nowish
[10:37] <pitti> cjwatson_: good morning; thanks
[10:37] <Greg__> Hobbsee, can you name one?
[10:37] <Hobbsee> Greg__: keyserver.ubuntu.com, iirc
[10:38] <cjwatson_> Greg__: it's in the ubuntu-keyring package on archive.ubuntu.com, or which you can extract from CD images
[10:40] <Hobbsee> ah, neat.   now, if my brain was actually working, i probably would have realised that
[10:40] <cjwatson_> hmm, I suppose I should sign the archive signing key, in order that an active archive admin has signed it
[10:41] <cjwatson_> Greg__: (it's 437D05B5, although whether you trust a random person telling you that on IRC is up to you ;-))
[10:41] <infinity> cjwatson: Have none of us signed it?
[10:41] <cjwatson> infinity: elmo has
[10:41] <infinity> Oh, well, that works for me.
[10:42] <infinity> He may not be an ftpmaster, but he does have root on all the machines, which is good enough for me.
[10:42] <cjwatson> indeed
[10:42] <StevenK> infinity: Do you have time now ... ? :-)
[10:42] <infinity> StevenK: I never have time, but sure, I'll look at it now.
[10:43] <StevenK> infinity: Thanks
[10:43] <infinity> It'll be a break from the pain of lpia. :
[10:43] <infinity> :)
[10:45] <cjwatson> infinity: well, I've pushed up a signature for it now
[10:46] <infinity> cjwatson: The sources that you've checked for lpia happiness, have you been paying attention to the GNU_TYPE linux-gnu/linux-gnulp confusion?
[10:47] <infinity> (I kinda misplaced /bin/kill due to that... *cough*)
[10:47] <infinity> (procps doesn't install /bin/kill if GNU_TYPE != linux-gnu)
[10:51] <cjwatson> infinity: I hadn't, but I've rechecked them and they're all good.
[10:51] <infinity> cjwatson: Good, good.  Thanks.
[10:51] <cjwatson> infinity: anything I've touched in the last couple of years has got rid of checks for linux-gnu in favour of DEB_*_ARCH_OS=linux anyway
[10:51] <infinity> cjwatson: Sadly, that doesn't seem to be the case everywhere.
[10:52] <infinity> (And procps and sysvinit aren't exactly "unused packages")
[10:53] <alesan> re
[10:53] <alesan> I am looking for info how to build the isolinux for the livecd
[10:53] <cjwatson> infinity: a mere 2.5 years or so isn't anywhere near enough for everyone to migrate :P
[10:54] <alesan> I intend to write out a different menu logo etc...
[10:54] <cjwatson> alesan: it's been a while, but I generally build them using instructions similar to one of the *README files in debian-installer/build/boot/x86/pics/
[10:55] <cjwatson> alesan: basically convert to 4-bit bmp then 'bmptoppm < foo.bmp | ppmtolss16 #FFFFFF=7 > foo.rle', although you'd have to look up the appropriate colour to use in place of #FFFFFF - generally the nearest one in the image to white
[10:56] <alesan> cjwatson, yes I know the issue
[10:56] <alesan> but do you have an idea how to start from the current splashscreen
[10:57] <alesan> I do not want to rebuild everything, just modify a menu entry and add a detasil in the logo
[10:57] <infinity> cjwatson: The problem seems to be that rather than migrating to ARCH_OS, people just worked around the GNU_TYPE changing, by doing icky things like [ "$GNU_TYPE" = "linux" ]  && GNU_TYPE=linux-gnu, and then testing for linux-gnu.
[10:58] <alesan> where do I find "debian-installer" and so on?
[10:59] <cjwatson> alesan: apt-get source debian-installer
[11:00] <cjwatson> alesan: there's an lss16toppm program that should let you convert back to something you can edit
[11:00] <alesan> cjwatson, I tried to find something like that yesterday night but I gave up
[11:00] <alesan> I'll see if I'm luckier this morning :)
[11:00] <cjwatson> infinity: yeah, we did that in Ubuntu for about ten minutes or so before Keybuk pointed out we were wrong, and I wrote a chunk of sample code which ended up in dpkg-architecture(1)
[11:05] <StevenK> infinity: Any news?
[11:09] <seb128> ogra: new gnome-screensaver available
[11:09] <infinity> StevenK: Yes, "doko is distracting".
[11:10] <StevenK> Heh
[11:19] <alesan> where the hell can I find lss16toppm
[11:20] <cjwatson> alesan: syslinux, and keep the frustration down please
[11:21] <alesan> I'm no frustarted maybe as I am not a native english speaker I didn't measure the "weight" of such expression
[11:21] <alesan> sorry for that :)
[11:21] <cjwatson> ok, s/ the hell// then ;-)
[11:32] <Riddell> pitti: do I remember you had a bash routine to upload to the correct dput location based on version number?
[11:32] <pitti> Riddell: not on version number, on Distribution: target
[11:33] <pitti> Riddell: http://people.ubuntu.com/~pitti/scripts/uup FYI
[11:33] <pitti> Riddell: FTP doesn't work with my ISP, so the script scp's it to chinstrap and dputs it there
[11:34] <pitti> Riddell: it's trivial to add a grep -v which sets $QUEUE to ppa if version has ~ppa in it, or so
[11:34] <Riddell> I can adapt it, thanks.  am finding myself dangerously close to uploading ppa packages to ubuntu
[11:42] <ogra> seb128, tx
[11:52] <StevenK> pitti: Ewww, you need a better ISP.
[11:52] <pitti> StevenK: I'd give much for such one
[11:54] <Keybuk> the quality of service has gone down *so much* since the old days
[11:55] <pitti> without DSL being available here, my choice is quite limited anyway
[11:55] <pitti> 'take that one with the crackful and unreliable WLAN and 5 km beam, or leave it'
[11:55] <ogra> pitti, http://www.teles-skydsl.de/
[11:56] <pitti> ogra: hm, maybe, yes
[11:56] <ogra> needs a separate return channel though
[11:56] <Keybuk> satellite latency is teh suck
[11:56] <StevenK> Oh yes
[11:56] <ogra> i was pondering it when we lived in the eifel
[11:56] <pitti> and the separate return channel would be ISDN, which is both slow and amounts to quite a lot of costs, too
[11:57] <StevenK> $WORK specialises in two way satellite - the latency is roughly on the order of 1 second.
[11:57] <ogra> they offer a flatrate if you can proof they cant offer you DSL now
[11:57] <pitti> StevenK: that sounds next to unusable for ssh...
[11:57] <ogra> pitti, ^^^
[11:57] <pitti> ogra: oh? cool
[11:57] <StevenK> pitti: It takes some getting used to.
[11:57] <pitti> ogra: (not that I'd actually want to use ISDN permanently...)
[11:58] <ogra> pitti, well, i would prefer 10 trunced isdn lines over DSL if the price wouldnt matter ;)
[11:58] <pitti> ogra: I think the better solution is: get fiancee to get a job somewhere, and move to a place with DSL :)
[11:58] <StevenK> Heh
[11:58] <StevenK> ogra: Ten D channels? At only 640kbit?
[11:59] <StevenK> Hell, $WORK has 2Mbit SHDSL
[11:59] <ogra> StevenK, but symmetric and incredibly reliable ;)
[12:00] <ogra> i rarely use my 2MBit here
[12:00] <StevenK> I'm the network admin, and I think that SHDSL service has dropped twice since it's been connected.
[12:00] <Keybuk> I'm resigned to the fact that after moving I may not be able to find a decent broadband connection, and certainly won't be able to have static IP, etc.
[12:01] <StevenK> However, like you get anything close to that in reality.
[12:01] <StevenK> Keybuk: I didn't think the broadband situation in .uk was that bad?
[12:02] <thom> StevenK: depends on location
[12:02] <Kano> hi, i am still missing fuse 2.7.0 in ubuntu and none of my bug reports have been processed...
[12:02] <Keybuk> StevenK: all DSL is BT, with an ISP supplying the IP connection over top
[12:02] <StevenK> thom: Ah. Much like here, then. :-)
[12:03] <Keybuk> StevenK: speeds vary depending where you are; and most ISPs have headed down the "download limit" path for their service
[12:03] <Spads> Keybuk: even LLU?
[12:03] <Keybuk> Spads: LLU is still BT lines, BT exchanges and BT equipment
[12:03] <Keybuk> it was a BT engineer who came round last week to fix it
[12:04] <thom> bt equipment for last mile, yeah
[12:04] <Ng> it's a BT line, but the equipment it connects to at the exchange is owned by your ISP
[12:04] <Spads> yeah, that was what I thought
[12:04] <Spads> the way covad operated in the US
[12:04] <Keybuk> and LLU is incredibly expensive
[12:04] <seb128> Kano: hi, we receive load of bugs, it might take some time before somebody looks at yours
[12:04] <Spads> eh, switching to BT was more expensive for me
[12:04] <Keybuk> and entirely unavailable outside of major cities
[12:05] <Spads> they wanted like 145 just to take us off whatever the previous tenants had
[12:05] <StevenK> Spads: Nice! You didn't make the choice, but you get to reap the benefits.
[12:05] <Spads> StevenK: yeah, so I stuck with the LLU they had, because it turned out to be a good service
[12:05] <alesan> cjwatson, it seems the bootlogo in /isolinux in the latest livecd is not in lss16 format
[12:05] <cjwatson> alesan: of course bootlogo isn't
[12:05] <Keybuk> Spads: heh; sadly the old trick doesn't work
[12:06] <cjwatson> alesan: that's not actually a logo (the name sucks a bit), it's an archive of stuff generated by gfxboot-theme-ubuntu
[12:06] <Keybuk> you used to always be able to force the issue with BT by wiring a 9V battery into the phone socket
[12:06] <Kano> seb128: updateing fuse cant be that hard... for a beginning
[12:06] <infinity> StevenK: ADSL2+ reality can be pretty decent if you're close to the CO.  I get about 18/1
[12:06] <cjwatson> alesan: I didn't know you were talking about /isolinux/bootlogo, or I'd have told you that from the start :)
[12:06] <alesan> cjwatson, well I guess I'll have to read doc of gfxboot-theme-ubuntu to modify such things right?
[12:06] <Spads> Keybuk: er, how did that help?
[12:06] <cjwatson> read the source, anyway ...
[12:06] <wereHamster> what do I have to choose as type if my package is both a library and has multiple binaries, too?
[12:06] <Kopfgeldjaeeger> hey. do you have an idea how to delete the last line of a file? sure, i could wc -l ist, show the last line with awk's "if (NR==x)" and then delete it with sed, but that's too dirty
[12:07] <infinity> StevenK: Of course, then we're connected to the rest of the planet via string and tin cans, so it doesn't really matter.
[12:07] <alesan> cjwatson, what other logo is there around :) ?
[12:07] <Keybuk> Spads: put the line on the fritz, so they had to send an engineer out - and since you didn't have a contract with them, they couldn't force you to remove it
[12:07] <StevenK> infinity: Indeed.
[12:07] <seb128> Kano: you are free to work on it, attach a debdiff and subscribe the sponsor team if you want to speed it
[12:07] <pitti> Kopfgeldjaeeger: head -n -1 file > newfile
[12:07] <Spads> Kopfgeldjaeeger: try head -n -1
[12:07] <Spads> d'oh
[12:07] <Spads> too slow
[12:07] <Kano> why? debian has already fuse 2.7.0. just take it from there...
[12:08] <seb128> Kano: there is thousand of packages, updating one is not hard but it takes time and people are busy actually
[12:08] <StevenK> infinity: Did libnss-db fall off your list again? :-)
[12:08] <Kopfgeldjaeeger> thank you both.
[12:08] <cjwatson> alesan: /isolinux/splash.rle (used by syslinux), /isolinux/splash.pcx (used by gfxboot)
[12:08] <StevenK> Kano: Because we have Ubuntu modifications to fuse.
[12:08] <seb128> Kano: there is Ubuntu changes to the current version, it needs to be merge or somebody needs to confirm changes can be dropped
[12:08] <Keybuk> sed -i -e '$d' file
[12:08] <Keybuk> ^ in-place last-line-delete :p
[12:08] <pitti> ogra (CC: kano, seb128): do you have some time to give fuse 2.7 a test on your LTSP setup?
[12:09] <ogra> pitti, later in the evening ... i'm doing some compilcated merges of the new ldm atm
[12:09] <pitti> ogra: sure, no hurry; I just meant, would you consider updating at this time, or do you want to go with 2.6?
[12:09] <Kano> ogra: do you have got a howto to transfer audio via network?
[12:09] <infinity> StevenK: Yes. :(
[12:09] <pitti> Kano: you want to look at pulseaudio
[12:10] <infinity> StevenK: Blame doko.  He's a demanding mistress.
[12:10] <ogra> Kano, no, but feel free to pick my brain :)
[12:10] <StevenK> Heh
[12:10] <alesan> cjwatson, let me check
[12:10] <ogra> Kano, pittis suggestion is a good start :)
[12:10] <Kano> does it work with kde apps too?
[12:10] <StevenK> infinity: You know, it's becoming tempting to fly down to Melbourne and stand over you until you look. :-P
[12:11] <infinity> StevenK: I could use the company.
[12:11] <StevenK> Heh
[12:11] <infinity> StevenK: Bring burgers and Coke, kthx.
[12:12] <StevenK> Which would be a proper bitch to get to from anywhere else in Melbourne, the office being in Tullamarine.
[12:12] <infinity> Eww.
[12:12] <infinity> Without a car, there's no reasonable way to get to Tulla.
[12:12] <infinity> And with a car, it still sucks.
[12:13] <alesan> cjwatson, ok now everything's much clearer
[12:13] <StevenK> I've done it once, but it was a day trip, and getting from the airport to Tullamarine is trivial.
[12:13] <alesan> cjwatson, I only have to change those images to use a new bootlogo right?
[12:13] <StevenK> And then there was the 2.5 hour drive to Bendigo.
[12:13] <infinity> Well, yes, the airport is *in* Tullamarine.
[12:13] <cjwatson> alesan: please stop using the word "bootlogo" unless you mean that file
[12:13] <infinity> You went.. To... Bendigo?
[12:14] <cjwatson> alesan: it's very confusing
[12:14] <thom> must be daniels' fault
[12:14] <infinity> Was Daniel somehow involved?
[12:14] <StevenK> Certainly not.
[12:14] <StevenK> It was for $WORK
[12:14] <infinity> Get a new job.
[12:14] <cjwatson> alesan: yes, you should only need to change splash.rle and splash.pcx to change the splash screen image
[12:14] <infinity> Seriously.
[12:14] <alesan> cjwatson, let's define a term, then
[12:14] <infinity> Being sent to Bendigo is a fate worse than death.
[12:14] <cjwatson> alesan: "splash screen image"
[12:14] <alesan> ok splash screen image
[12:14] <alesan> agreed
[12:16] <infinity> Fujitsu: And I suppose you also think "Goon of Fortune" is a perfectly sane and reasonable way to spend a Saturday evening?
[12:17] <Fujitsu> ... Goon of Fortune?
[12:17] <Fujitsu> Wow, it's rather more windy than normal here.
[12:18] <infinity> Bag of goon, rotating clothes line, do the math.
[12:18] <cjwatson> infinity: can I delete the python-apt lpia failure from my inbox (i.e. is somebody already dealing with it)?
[12:18] <infinity> Not being from Bendi, I'v eonly ever had the game described to me.
[12:18] <infinity> cjwatson: We're looking into it.
[12:18] <Fujitsu> infinity: That sounds a little odd.
[12:18] <cjwatson> ok
[12:18] <infinity> cjwatson: Don't know if we're resolving it, but we're pretending to.
[12:19] <Fujitsu> How much do you have to bootstrap manually before the rest of the world pulls itself together?
[12:19] <Keybuk> woo, PCLinuxOS is no longer #1 on the DistroWatch 7 days chart
[12:20] <infinity> Fujitsu: I wouldn't be doing any of it manually, except that we have to review the sources to make sure they won't do Very Strange Things based on our dpkg architecture and GNU triplet.
[12:20] <Kopfgeldjaeeger> its sabayon... interesting
[12:20] <infinity> Fujitsu: If it wasn't for that, we'd build a toolchain, throw it all on auto, close our eyes, and scream "LA LA LA, I CAN'T SEE YOU" until it was done.  Ish.
[12:21] <Fujitsu> infinity: That's what I thought would have happened, so I was quite surprised it was taking so long.
[12:21] <infinity> Fujitsu: Note the number of source uploads in the last 2 days by me, doko, and kamion.
[12:21] <cjwatson> (vanishingly few by me)
[12:21] <infinity> Fujitsu: The potential for breakage here has been... Annoyingly high. :)
[12:22] <infinity> cjwatson: Enough to count. :)
[12:22] <cjwatson> that reminds me, openssh sync
[12:22] <doko> Fujitsu: care to help?
[12:22] <cjwatson> oh, apparently I did it already
[12:22] <infinity> cjwatson: Besides, I gave you an out by referring to you as "kamion", had you just kept quiet, no one would be the wiser.
[12:22] <cjwatson> hah
[12:22] <Fujitsu> infinity: Why so much breakage? Because it's completely new and not really been done before?
[12:23] <infinity> Fujitsu: New dpkg arch, new gnu triplet, lots of debian/{rules,control,random-junk} doesn't know how to cope.
[12:24] <infinity> Fujitsu: As a ferinstance, procps decided it didn't want to install /bin/kill... Which I was a bit nonplussed about, not because I care overly about killing things, but because half the world build-deps on procps specifically because Debian maintainers seem to be incapable of turning off autoconf's /bin/kill test.
[12:24] <Fujitsu> Hah, rather odd breakage.
[12:25] <cjwatson> I take it it's been removed upstream since then or something
[12:25] <lore_> hi all
[12:26] <infinity> cjwatson: Oh, I imagine it's a stub test used only by packages looking for a path to the kill binary.  Which still seems to be a fair few.
[12:26] <infinity> cjwatson: But telling maintainers that you can preseed autoconf variables and don't actually need to build-dep on every single one of your runtime deps doesn't seem to sink in.
[12:26] <infinity> (tests for ping are another classic example)
[12:26] <doko> ifeq (,$(DEB_BUILD_GNU_TYPE))
[12:26] <doko>  include /usr/share/dbs/dpkg-arch.mk
[12:26] <doko> endif
[12:26] <lore_> i'm trying to statically link a program, but i get this error "sing 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking"
[12:26] <doko> \o/
[12:27] <lore_> and i didn't find any glibc-static package for ubuntu
[12:28] <infinity> doko: Surely the dbs make snippet won't be too crackful, though...
[12:28] <doko> infinity: no, look at dpkg-arch.mk ...
[12:28] <infinity> (exercise to the reader to decide if that was ironic sarcasm)
[12:29] <doko> ifeq ($(DEB_BUILD_ARCH_OS),)
[12:29] <doko>   DEB_BUILD_ARCH_OS := $(subst -gnu,,$(DEB_BUILD_GNU_SYSTEM))
[12:29] <doko>   ifeq ($(DEB_BUILD_ARCH_OS),gnu)
[12:29] <doko>     DEB_BUILD_ARCH_OS := hurd
[12:29] <doko>   endif
[12:29] <doko> endif
[12:29] <cjwatson> doko: what's wrong with that?
[12:29] <cjwatson> oh, you'll get linuxlp
[12:29] <cjwatson> argh
[12:29] <doko> :-)
[12:29] <cjwatson> guess who wasn't expecting the existence of linux-gnulp when he wrote that code ...
[12:30] <infinity> I blame that Kamion fellow.
[12:30] <cjwatson> so copies of that are probably littered all over the place since they're in dpkg-architecture(1)
[12:30] <infinity> Wherever's he's gone to.
[12:30] <cjwatson> $(patsubst -gnu%,,$(DEB_BUILD_GNU_SYSTEM)) # ?
[12:31] <cjwatson> or for that matter $(DEB_BUILD_GNU_SYSTEM:-gnu%=)
[12:31] <cjwatson> (test that)
[12:31] <Kopfgeldjaeeger> cool... pidgin 2.1.0  compiles under daooer :d
[12:33] <doko> iwj: ^^^ please could you update dpkg-architecture(1) ?
[12:35] <infinity> More pressingly, it needs updating in Debian, and -devel-announce might even need telling about it... If we can manage to do so without it being an "Ubuntu needs you to fix this bug for an architecture you don't ship" post. :)
[12:37] <cjwatson> infinity: yeah
[12:37] <cjwatson> it only actually *matters* if you then test the result against "linux"
[12:37] <cjwatson> rather than just "not gnu"
[12:39] <infinity> Which people will surely do.
[12:41] <Keybuk> Backwards compatibility has so much to answer for
[12:42] <Keybuk> why do you need that horrendous snippet anyway?
[12:42] <Keybuk> can't you just test DEB_BUILD_ARCH_OS etc. directly?
[12:43] <infinity> Keybuk: Note that it starts with ifeq ($(DEB_BUILD_ARCH_OS),)
[12:44] <Keybuk> yes, but why would that ever be "" ?
[12:45] <infinity> Because it didn't used to exist, did it?
[12:45] <infinity> So, rather than dealing with "I may or may not be able to query this variable", the above hack was born.
[12:46] <iwj> Urgh.
[12:48] <iwj> This is all a bit of a swamp, really.  Is it even written down anywhere ?  I'm sure it wasn't this bad last time I understood it.
[12:48] <infinity> iwj: It's not so bad, really.
[12:49] <infinity> iwj: The output of dpkg-architecture is sane and reasonably useful now.
[12:49] <infinity> iwj: But maintainers use it in hideously evil and broken ways.
[12:49] <Keybuk> infinity: build-essential depends on the version of dpkg-dev where it's always existed
[12:49] <infinity> iwj: And our introduction of a triplet ending in "-gnulp" has made it all go south.
[12:49] <infinity> Keybuk: Yes, but people like their packages to be backportable.
[12:49] <Keybuk> like I said
 Backwards compatibility has so much to answer for
[12:50] <Fujitsu> What was wrong with -gnu?
[12:50] <infinity> Fujitsu: Because "i686-linux-gnu" would imply a straight i686 rebuild of "i386-linux-gnu", which lpia isn't.
[12:51] <infinity> Or, rather, it won't be.
[12:51] <iwj> So err anyway, is someone on the case wrt doko's problem ?
[12:51] <Fujitsu> Ah, so lpia is just x86 with some extra optimisations or some such?
[12:51] <infinity> iwj: doko's problem is already solved on doko's laptop, I assume. :)
[12:52] <infinity> iwj: The dpkg manpage needs updating to not break, though.
[12:52] <infinity> iwj: And someone might want to politely inform Debianites that this code snippet being littered all over isn't actually quite right.
[12:54] <cjwatson> at the time, it was extremely common to want to be able to build source packages from unstable on stable where DEB_BUILD_ARCH_OS was not available.
[12:54] <iwj> Dozen-line cargo cult crack in dpkg-dev!
[12:54] <cjwatson> and that was about the best option available
[12:55] <cjwatson> we can probably remove it now
[12:55] <infinity> It's perhaps saner at this point to remove the backward compat thing completely, now that Debian's had a stable release with the new dpkg...
[12:55] <cjwatson> indeed. it was better to have cargo cult crack in dpkg-dev than to have everyone get it wrong in subtly different ways
[12:56] <infinity> I just got it wrong in the "I don't care at all about non-linux ports" way.
[12:56] <iwj> Um.
[12:56] <infinity> Which was fine by me.
[12:56] <infinity> Cause I didn't.
[12:56] <iwj> What is this, Extreme Programming ?
[12:56] <iwj> Sorry, I should be less catty.
[12:56] <infinity> Then you wouldn't be you.
[12:58] <cjwatson> doko: surely none of this matters, anyway
[12:58] <cjwatson> doko: on modern dpkg-dev, the variable will be set, and the backward-compatibility snippet won't be used
[12:58] <doko> hmm, ok
[12:59] <cjwatson> we should just be able to ignore that entirely and trust to DEB_*_ARCH_OS being set
[12:59] <infinity> cjwatson: It's only set if someone sets it.
[12:59] <infinity> cjwatson: If they only ever query GNU_TYPE, because they don't need ARCH_OS (due to the snippet taking care of that for them)....
[01:00] <cjwatson> infinity: both /usr/share/dbs/dpkg-arch.mk and dpkg-architecture(1) do so
[01:00] <infinity> Oh, fair point, I was only looking at the second half of the cargo cult in question.
[01:00] <cjwatson> and if they only query GNU_TYPE, it doesn't matter
[01:00] <Kopfgeldjaeeger> Could someone please test if this pidgin package works with edgy or feisty? it doesnt create a menu entry, so it must be started via alt+f2 or terminal: http://xeve.de/down/pidgin-2.1.0_i386.deb
[01:01] <infinity> Err, GNU_SYSTEM, even.
[01:01] <doko> mvo: any idea about http://launchpadlibrarian.net/8620520/buildlog_ubuntu-gutsy-lpia.python-apt_0.7.2ubuntu3_FAILEDTOBUILD.txt.gz
[01:01] <cjwatson> if they only query GNU_SYSTEM, it doesn't matter either :)
[01:02] <infinity> Wait, what was I driving at here?
[01:02] <Amaranth> doko: odd, it installed python-distutils-extra
[01:02] <infinity> Oh, right.  That someone could use the second half of that snippet to set DEB_HOST_ARCH_OS, without querying jack.
[01:03] <mvo> doko: yes, the fix will go in after lunch
[01:03] <infinity> And then test DEB_HOST_ARCH_OS
[01:03] <doko> mvo: please before lunch (and before infinity goes to bed ...)
[01:03] <cjwatson> infinity: I *guess*. Does anybody actually do that?
[01:03] <infinity> cjwatson: I haven't seen that exact thing, no.  Not yet. :)
[01:03] <pygi> hello everyone
[01:04] <infinity> doko: My going to bed isn't the end of the world, I can build things tomorrow. :P
[01:05] <mvo> doko: I'm sure that it can wait 30 min
[01:05] <doko> mvo: I didn't know that you eat that quick ;-P
[01:07] <pygi> mvo, wake up, wake up =)
[01:08] <cjwatson> infinity: we want libc6-i686 on lpia, right?
[01:08] <infinity> cjwatson: Why would we?
[01:09] <cjwatson> infinity: I thought lpia was i686-optimised
[01:09] <infinity> cjwatson: libc6 itself is i686 optimised.
[01:09] <cjwatson> ah
[01:09] <infinity> Which reminds me, we should drop the extra hwcap copies of libssl too.
[01:09] <cjwatson> wow, I think that means the seeds don't need any changes
[01:09] <pitti> if that is true, why do we need -686 then?
[01:09] <infinity> That's just bloat.
[01:10] <infinity> pitti: On lpia, libc6 is i686 optimised.  We need -686 on i386...
[01:10] <pitti> infinity: aah
[01:11] <infinity> Anyone feel like volunteering to hack all the libssl* packages to drop all the << i686 copies of the libraries on lpia?
[01:11] <cjwatson> doko: any particular reason you put an arch specifier on g++-4.2-multilib in the seeds? it's only built on the listed architectures anyway
[01:12] <cjwatson> hm, well, I guess it suppresses some germinate warnings
[01:12] <doko> cjwatson: hmm, no thought that was needed ...
[01:13] <StevenK> infinity: I'll look at it after I bend pdftk to my will, or give up in disgust.
[01:13] <doko> cjwatson: I'd like to upload a preliminary ubuntu-meta package supporting lpia. ok?
[01:13] <StevenK> infinity: Then I can bribe you with that until you look at libnss-db. :-P
[01:13] <infinity> StevenK: Hah.
[01:13] <cjwatson> doko: I'll leave the arch specifiers there, thinking about it it's reasonable to suppress the warnings even though it's not strictly needed
[01:13] <cjwatson> doko: ubuntu-meta> sure
[01:14] <infinity> StevenK: If you can recall off the top of your head any other libraries that do the hwcap trick, hack 'em all. :)
[01:14] <StevenK> Not that I can recall.
[01:15] <StevenK> infinity: Both openssl and openssl097 will need to be touched, or you don't care about openssl097?
[01:16] <cjwatson> 097's universe, I doubt it matters for lpia
[01:16] <infinity> StevenK: openssl097's universe, so likely don't care much.
[01:17] <elmo> (mesa?)
[01:21] <wereHamster> I have unpacked teh source and created the debian directory inside it. Let's suppose I can now create the deb package. What happens if upstream releases a new version? Do I have to recreate the debian directory again? I can't simply copy it because the files in there have teh version of the old release
[01:22] <cjwatson> wereHamster: uupdate (in devscripts) is one common method, or just copy it and update any versions necessary
[01:22] <cjwatson> you shouldn't generally have *lots* of files with hardcoded versions
[01:24] <Hobbsee> assuming it doesnt fall over, of course.
[01:29] <alesan> cjwatson, you help has been most welcome
[01:30] <alesan> thank you very much cjwatson.
[01:41] <cjwatson> alesan: you're welcome
[01:42] <Kmos> yesterday someone forgot to do the syncs/backports :-)
[01:42] <Kmos> Mithrandir: :-(
[01:47] <mvo> infinity, doko: new python-apt uploaded
[01:47] <infinity> mvo: Danke.
[01:47] <doko> \o/
[01:50] <pygi> StevenK, doesn't sound too good?
[01:51] <StevenK> pygi: It's been failing to build all night - I'm working through the errors
[01:51] <wereHamster> what's a 'files list file' ?
[01:51] <mvo> cheers :)
[01:52] <StevenK> It doesn't help that gcj want to throw a warning on nearly every line into encounters.
[01:52] <cjwatson> wereHamster: debian/files, usually generated by dpkg-gencontrol (maybe via dh_gencontrol) called from debian/rules
[01:55] <infinity> StevenK: That's gcj's way of letting you know it cares.   Like that girl you just met who SMSes you every 30 minutes for a week.
[01:56] <Hobbsee> Kmos: forgot?  more likely were doing more important things.
[01:56] <Hobbsee> Kmos: have you fixed all the ones of yours that were on crack yet?
[01:56] <StevenK> infinity: In that case, how do I break up with gcj? :-P
[01:56] <infinity> StevenK: I've been trying to do that for years...
[01:58] <Kmos> Hobbsee: yes :)
[01:58] <pygi> siretart, poke?
[01:59] <Hobbsee> Kmos: did you subscribe u-u-s to all the unapproved ones?
[02:00] <Kmos> Hobbsee: I don't touch in that part
[02:00] <Hobbsee> Kmos: why not?  you're not a MOTU, so you need sponsorship.
[02:01] <Kmos> Hobbsee: i can't remove ubuntu-archive
[02:01] <Hobbsee> Kmos: even if they *had* gone and done syncs yesterday, they wouldnt have touched your bugs, as they hadnt fulfilled the requirements.  we discussed this days ago, i'm sure.
[02:01] <Hobbsee> Kmos: indeed.  but have people gone to every one of your bugs and gone "yes, this is OK" or "no, this is on crack?"
[02:02] <Kmos> Hobbsee: i think not for all
[02:02] <Hobbsee> Kmos: the fact that you've gone and subscribed u-a to all of them does not suddenly negate you from needing someone to check all of your bugs, for crack.
[02:02] <asac> Riddell: ... can you look at lightning-sunbird in source NEW?
[02:02] <Hobbsee> especially with past history...
[02:03] <Riddell> asac: yep, will be doing New processing a bit later today
[02:04] <asac> Riddell: if you have questions ... ;)
[02:07] <StevenK> infinity: Test building openssl
[02:22] <infinity> iwj: Your latest dpkg merge broke dpkg on lpia... I didn't notice until just now because I have an older build on hold in the buildd chroots.
[02:22] <infinity> iwj: during a debootstrap, I get:
[02:22] <infinity> dpkg: error processing var/cache/apt/archives/base-files_4.0.0ubuntu3_lpia.deb (--install): package architecture (lpia) does not match system ()
[02:23] <iwj> infinity: Hrm.
[02:23] <iwj> I thought I'd caught all of those.
[02:24] <iwj> What does  dpkg --print-architecture  say ?
[02:25] <infinity> adconrad@cthulhu:~$ sudo chroot lpia/ dpkg --print-architecture
[02:25] <infinity> adconrad@cthulhu:~$ sudo chroot lpia/ dpkg --print-installation-architecture
[02:25] <iwj> Yers, lovely.
[02:25] <infinity> (Those were blank lines following each)
[02:25] <ogra> mvo, i see bug 122459 on my thin clients as well now
[02:25] <ubotu> Launchpad bug 122459 in compiz "[gutsy]  cannot log in on edubuntu DesktopCD" [Undecided,Incomplete]  https://launchpad.net/bugs/122459
[02:26] <iwj> Is there a way I can reproduce this to debug it ?  I don't currently have any lpia things.
[02:26] <Amaranth> mvo: the wrapper doesn't check for LTSP_CLIENT?
[02:26] <infinity> iwj: sudo debootstrap --variant=buildd --arch lpia gutsy lpia http://ports.ubuntu.com/ubuntu-ports
[02:27] <ogra> Amaranth, i want compiz where available
[02:27] <cjwatson> iwj: (you should be able to run that on i386)
[02:27] <infinity> iwj: Where the second "lpia" in there is the directory.
[02:27] <Amaranth> ogra: well, that's different
[02:27] <infinity> iwj: Or just grab the lpia binary and run it on i386.
[02:27] <ogra> Amaranth, and apparently there is a deeper cause for it ....
[02:27] <Amaranth> in mountain view i was told we should not even try to start on thin clients
[02:28] <ogra> Amaranth, in seville you tought us differently ;)
[02:28] <Amaranth> hehe
[02:28] <Amaranth> seen dave_largo's blog?
[02:28] <ogra> so on intel based clients i indeed want compiz
[02:28] <cjwatson> infinity: you shouldn't need to say ports.u.c explicitly
[02:28] <ogra> (we dont ship restricted modules, so the others are fiddly anyway)
[02:28] <cjwatson> new debootstrap works it out
[02:29] <Amaranth> ogra: that reminds me, what ever happened to the classmate pc?
[02:29] <mvo> Amaranth: no, currently not
[02:29] <mvo> ogra: looking
[02:29] <infinity> cjwatson: Habit.  I always specify the mirror, because it's usually a local one.
[02:29] <ogra> Amaranth, sitting on my desk
[02:29] <alesan> cjwatson, actually, the spalsh.rle is not being used in my experiments. still, it's there on the isolinux directory, why? maybe for compatibility with older systems?
[02:29] <infinity> cjwatson: Well, either a local one, or ftpmaster.internal. :P
[02:29] <mvo> ogra: can you append the output of lspci to the report please?
[02:29] <cjwatson> alesan: it's used if gfxboot fails or is disabled (by holding down shift at boot time)
[02:29] <alesan> I see
[02:29] <ogra> mvo, trying ... need to get that off the client somehow :)
[02:30] <alesan> thank you
[02:32] <StevenK> infinity: The debdiff for openssl looks sane, and it builds fine on i386. Do you want to see the debdiff?
[02:32] <alesan> cjwatson, what about the next stage of the boot process, when the kernel has been loaded. I guess the "splash screen image" is contained in the initrd.gz file on /casper
[02:33] <cjwatson> alesan: yes, that's in usplash-theme-ubuntu and built into that initrd.gz
[02:33] <cjwatson> the initrd's produced by installing all the usual initramfs-ish stuff (initramfs-tools, whatever else is in everything up to ubuntu-desktop) plus casper
[02:33] <cjwatson> and running update-initramfs -u
[02:34] <Kmos> latest notification-daemon (0.3.7-1ubuntu2) on gutsy is crashing
[02:34] <pygi> Kmos, agreed =)
[02:35] <Amaranth> Kmos: I blame gtk ;)
[02:37] <Kmos> Amaranth: the debug report shows something about nvidia
[02:37] <Amaranth> it says you're tainted. probably
[02:37] <infinity> StevenK: email?  Too many thought processes at once right now.
[02:41] <iwj> FFS.  I wish this DSL migration would actually happy.
[02:41] <StevenK> infinity: Oh, and that worked so well for libnss-db. :-P
[02:42] <iwj> infinity: I didn't see any answer to my last question, I'm afraid.
[02:42] <iwj> s/happy/happen
[02:43] <infinity> iwj: You can debootstrap an lpia chroot on i386 with --arch lpia, or you can just unpack the dpkg_lpia.deb and run it on i386.
[02:43] <infinity> iwj: It's an i686 binary.
[02:44] <iwj> Right.  But the bug is in the build process of the dpkg_lpia.deb so I need to rebuild it.
[02:44] <iwj> I thought you said debootstrap didn't work ? :-)
[02:44] <infinity> iwj: Oh, fair point.
[02:44] <StevenK> infinity: E-mail sent for what's its worth
[02:44] <infinity> iwj: chinstrap:~adconrad/chroot-ubuntu-gutsy-lpia.tar.bz2
[02:44] <iwj> Fabulous.
[02:44] <infinity> iwj: Should be able to grab that, install build-deps, and play to your heart's content.
[02:44] <iwj> I'll look at that after lunch.
[02:45] <iwj> Are you blocked on this ?
[02:45] <infinity> iwj: Just need to change sources.list to point to ports.u.c/ubuntu-ports.
[02:45] <infinity> iwj: I'm not blocked on it, the chroots have dpkg on hold.
[02:45] <iwj> Right, good.
[02:49] <ogra> mvo, both added
[02:51] <mvo> ogra: thanks!
[02:51] <ogra> do you maintain a blacklist ?
[02:58] <ogra> pitti, ping
[02:58] <pitti> hi ogra
[02:58] <ogra> pitti, i heard you hinted mkelfimage into ubuntu ?
[02:58] <pitti> ogra: yeah
[02:58] <pitti> ogra: Q-FUNK was proposing that, after talking to you
[02:58] <ogra> great, do you think there is a chance we can replace mknbi with it ?
[02:59] <wereHamster> debian directory seems ok, dpkg-buildpackage built the *.deb package, what now? What/how shoudl I submit it?
[02:59] <ogra> i still have to do some testing, but it seems desirable since it supports LiuxBIOS
[02:59] <pitti> ogra: that I don't know; I don't have the slightest idea about what either of those programs are
[02:59] <pitti> ogra: hm, was it FTBFS? it's not in binary NEW
[02:59] <ogra> create etherboot capable kernel images to serve via tftp
[02:59] <ogra> i havent looked yet, just got a mail from Q-Funk
[03:00] <pitti> http://launchpadlibrarian.net/8629441/buildlog_ubuntu-gutsy-i386.mkelfimage_2.7-1_FAILEDTOBUILD.txt.gz
[03:00] <pitti> ogra: ^ argh, needs --f-no-stack-protector
[03:00] <pitti> s/--/-/
[03:00] <ogra> mumble
[03:01] <pitti> ogra: ltsp-client-core is the only package that needs mknbi (*at all* throughout universe)
[03:01] <pitti> ogra: so the decision is fully your's
[03:01] <ogra> yep
[03:01] <ogra> ah, ok :)
[03:02] <alesan> cjwatson, I don't find a way to create my own slpash.so image to be included in the initram image
[03:02] <pitti> StevenK: ah, d-i got built everywhere, time for kernel NBS slaughtery :)
[03:02] <StevenK> pitti: Yay!
[03:02] <infinity> pitti: Might want to wait on linux-meta...
[03:03] <alesan> I read somewhere I should be using a program called pngtobogl but... I'm not sure and it seems it only works with 16 colors images
[03:03] <pitti> infinity: ? I NEWed it this morning
[03:03] <infinity> pitti: Oh.  My feed reader is messing with me, I just saw it as new to -changes an hour ago.
[03:04] <infinity> pitti: Quite right, though, it's been in for ages.  Liferea and I will have a chat later.
[03:05] <cjwatson> alesan: the usplash-theme-ubuntu source package should help. See the Ubuntu wiki for further details on usplash customisation
[03:05] <alesan> mh
[03:05] <alesan> right now I'm testing with 4bit color
[03:06] <alesan> let's see what happens
[03:06] <alesan> :)
[03:06] <cjwatson> usplash images don't need to be at such a constrained bit depth
[03:06] <cjwatson> again, see the wiki which I think documents this
[03:06] <cjwatson> search for usplash :)
[03:07] <wereHamster> does anyone maintain a package for more than one distribution? What's the best way to do it? any suggestions?
[03:07] <alesan> https://help.ubuntu.com/community/USplashCustomizationHowto
[03:08] <infinity> wereHamster: Revision control, branches, and lots of merging.
[03:08] <pitti> wereHamster: I try to keep mine in sync with Debian, and where this is not possible, I have two bzr branches
[03:08] <alesan> it is updated to edgy, it says there are no such constraints but still, the pngtobogl won't work with such colorful images :)
[03:08] <pitti> hey BenC
[03:09] <wereHamster> since nobody wants to make a package for ubuntu, I'll have to do it myself, and a rpm package for redhat/suse would be nice, too (I'm a gentoo user)
[03:10] <cjwatson> wereHamster: most of the experience people here have is Debian/Ubuntu, not a lot outside the Debianish world
[03:10] <cjwatson> wereHamster: I think at that point the packaging is usually just completely independent for each distribution
[03:10] <infinity> wereHamster: Ahh, maintaining a debian directory, a spec file, and an ebuild is a bit more challenging, but yeah, way off-topic here.
[03:11] <Amaranth> wereHamster: what are you packaging?
[03:11] <wereHamster> https://bugs.launchpad.net/ubuntu/+bug/117236
[03:11] <ubotu> Launchpad bug 117236 in Ubuntu "[needs-packaging]  seom" [Wishlist,Confirmed] 
[03:11] <Amaranth> i should have known :)
[03:12] <wereHamster> why?
[03:12] <Amaranth> because that's your project
[03:14] <wereHamster> ubuntu users usually have less experience with compiling a package (compared to gentoo users) and it's also more complicated in most cases. I'm sich of all teh bug reports '.. it doesn't work on ubuntu' when it's only a configuration issue or missing packages
[03:15] <wereHamster> also, cross-compiling on ubuntu seems complicated, and a big userbase I'm targetting are those running a 64bit OS and need 32bit versions of my software
[03:16] <infinity> Building 32-bit binaries on amd64 is simple.
[03:16] <infinity> (And vice-versa)
[03:16] <wereHamster> for you, but explain that to someone who doesn't even know what a toolchain is
[03:17] <BenC> pitti: hey
[03:37] <Kmos> what's the new address of http://wiki.launchpad.canonical.com
[03:37] <Kmos> ?
[03:38] <Kmos> wiki.ubuntu.com ?
[03:38] <Kmos> https://wiki.ubuntu.com/FeatureSpecifications
[03:38] <Kmos> that's her
[03:38] <Kmos> here
[03:39] <pitti> Kmos: it's for LP-internal development, so you cannot access that anyway
[03:39] <pitti> Kmos: it's not wiki.u.c.
[03:40] <Kmos> but the address is wiki.canonical.com
[03:40] <Kmos> not wiki.launchpad.canonical.com
[03:41] <Hobbsee> Kmos: you cant address it anyway.
[03:42] <Hobbsee> sorry, you cant get to it anyway
[03:42] <Kmos> Hobbsee: i know, but it's on FeatureSpecifications
[03:42] <Kmos> so fixed it address
[03:42] <Kmos> :)
[03:43] <Hobbsee> Kmos: stupid question alert - but how do you know the address you changed it to is correct?
[03:44] <Kmos> wiki.launchpad.canonical.com resolves for you ?
[03:44] <Kmos> ** server can't find wiki.launchpad.canonical.com: NXDOMAIN
[03:44] <Hobbsee> http://www.wiki.launchpad.canonical.com/
[03:44] <Hobbsee> server not found
[03:45] <Kmos> pitti: can you clarify this ?
[03:45] <Hobbsee> but i'm still unsure as to how you think it's appropriate to change something that you have *no* access to, and so therefore have no idea if the content is correct or not
[03:45] <pitti> wiki.lp.c.c. does not exist any more, it has been renamed (I don't know what to)
[03:45] <pitti> but it's not really important anyway
[03:45] <pitti> the reference should just be removed from wiki.u.c.
[03:45] <Hobbsee> Kmos: also, the people who *do* will not be looking at that page, so the point is moot - ie, it'll 403 whatever link you use
[03:46] <Kmos> pitti: you've your answer from pitti
[03:46] <Hobbsee> ...
[03:46] <Hobbsee> reading before typing is a useful skill!
[03:46] <Hobbsee> so is before hitting enter!
[03:46] <Kmos> :)
[03:47] <Kmos> and click on submit
[03:47] <Kmos> pitti: so remove the "Write your specification in the wiki" ?
[03:47] <Kmos> and have only "Register your specification in Launchpad" ?
[03:48] <pitti> Kmos: you currently have a wiki lock, so I cannot edit
[03:48] <pitti> Kmos: please just remove the sentence "There are currently separate wikis for Launchpad [WWW]  here and Ubuntu (you are in it now :-))."
[03:49] <Kmos> pitti: try it now
[03:49] <Kmos> ah ok
[03:49] <Kmos> pitti: done
[03:50] <pitti> better
[03:52] <TheMuso> Because it isn't possible? :p
[03:52] <StevenK> You give up your rights to a physical existance when you sign the CoC, didn't you know?
[03:53] <Hobbsee> norsetto: for irc, you usually dont need it.  they havent invented stab-people-over-irc
[03:53] <evand> ...someday
[03:54] <Hobbsee> evand: yes.  may that day come soon!
[03:57] <Hobbsee> norsetto: no, i wont stab kmos today.
[03:57] <StevenK> ... today
[03:57] <norsetto> today ....
[03:57] <Hobbsee> norsetto: probably when he files the next huge lot of bugs which are almost all wrong, and therefore constitutes abuse of launchpad.
[03:57] <Hobbsee> bear in mind though...today only lasts for 3 more mins...
[03:58] <Hobbsee> 2
[03:58] <Kmos> I'm notice..
[03:58] <Kmos> I will try not to abuse launchpad anymore
[04:00] <Kmos> Hobbsee: I know i'm not welcome
[04:00] <ogra> Keybuk, bug 126437, what creates that udev entry and can i prevent it in a chroot ?
[04:00] <ubotu> Launchpad bug 126437 in ltsp "[gutsy-tribe2]  ltsp chroot gets udev rules corresponding to the server's network card" [Undecided,New]  https://launchpad.net/bugs/126437
[04:00] <Kmos> Hobbsee: don't see to say it every 5 minutes
[04:00] <Kmos> *need
[04:00] <Hobbsee> Kmos: on the contrary.  if the bugs are correct, you're very welcome :)
[04:00] <Keybuk> ogra: the udev postinst
[04:00] <Hobbsee> Kmos: i hope to see the day when they are
[04:00] <Keybuk> ogra: (in tribe2 )
[04:00] <Keybuk> ogra: it's since been fixed
[04:01] <ogra> Keybuk, only there ?
[04:01] <ogra> ah
[04:01] <ogra> cool
[04:01] <ogra> i'm to solw with my bugs :P
[04:01] <Kmos> Hobbsee: I try to got better.. yesterday i reported an sync request and it's ok.. junior-games-net
[04:02] <Hobbsee> Kmos: actually, my last comment was generic - seeing as there are multiple people doing that, just in different ways
[04:03] <Kmos> Hobbsee: but it affects me, because I know I've done a lot of *shit*
[04:03] <Kmos> Hobbsee: https://wiki.ubuntu.com/MemoryTest -> check if it's ok for you.. not changed since 2006
[04:04] <Hobbsee> Kmos: looks fine
[04:04] <Hobbsee> Kmos: some information on why memory tests are good might be useful, though
[04:04] <Kmos> nice
[04:04] <Kmos> Hobbsee: you can edit it :)
[04:05] <Hobbsee> Kmos: of course i can.  just giving a suggestion
[04:05] <Kmos> Hobbsee: yep =)
[04:05] <Kmos> i really don't know what to put there, so I told you to edit
[04:06] <iwj> infinity: Is this expected ?
[04:06] <iwj> dpkg-architecture: warning: Unknown gcc system type i686-linux-gnulp, falling back to default (native compilation)
[04:08] <alesan> cjwatson, I am finally able to build my own splash screen even for usplash.
[04:09] <alesan> anyway, I have to ask: can I use the initrd.gz from a regular system for the livecd? it seems not...
[04:10] <infinity> iwj: Yeah, we discussed that in London, remember?
[04:10] <infinity> iwj: It's not fatal, just noisy.
[04:13] <iwj> I don't remember the details but fine.  I've reproduced your bug btw.
[04:14] <iwj> That is to say, my bug :-).
[04:18] <alesan> what is the package that creates the initramfs for the livecd? casper maybe?
[04:18] <Kmos> Hobbsee: "If your system crashes at random intervals, perform a MemoryTest first before filing any bug reports or support requests"
[04:18] <Kmos> Hobbsee: how about that ?
[04:18] <seb128> iwj: any news about consolekit to main? I would like to start building gdm with it
[04:19] <soren> alesan: livecd-rootfs - construction script for the livecd rootfs
[04:19] <soren> alesan: Sounds like what you're looking for.
[04:20] <alesan> soren, well right now I'm stuck at the initramfs
[04:20] <iwj> seb128: I'm just fixing up a couple of bugs (err, before I got distracted by lpia).
[04:20] <alesan> I could change the splash image, but if I use my own initramfs from my system on the live cd it won't complete the boot
[04:21] <iwj> I want to get it all more or less sane before turning it on by default.  Does that sound sensible ?
[04:21] <alesan> the rootfs should come later
[04:21] <seb128> iwj: are those bugs bad enough to delay using it?
[04:21] <iwj> The one where gdm goes `plunkplunk plunkplunk plunkplunk plunkplunk' continuously is :-).
[04:21] <seb128> iwj: your call, I don't know what the bugs are about, but there are not likely to make the user experience worst than the current one?
[04:21] <seb128> ah, k
[04:22] <iwj> Also, I think it will be an easier testing sell to say `it should all be fixed now' rather than `yes there is a bug where if you do X and Y and then X again and then Z then symptom P appears but Q is supposed to be fixed'.
[04:22] <infinity> iwj: Does "reproduced" mean "found the cause of", or are we not quite there yet? :)
[04:22] <seb128> no hurry anyway, would just be nice to have it for next tribe
[04:22] <iwj> infinity: I'm homing in on it.  Fix RSN.
[04:22] <seb128> right
[04:22] <iwj> seb128: Oh, absolutely.
[04:22] <infinity> iwj: Spiff.
[04:23] <seb128> iwj: ok, thanks for the status update, good luck with it ;)
[04:23] <iwj> seb128: NP.  I'll keep you posted.
[04:28] <StevenK> infinity: Any news about openssl?
[04:53] <iwj> buildd@anarres:~/build/dpkg-1.14.5ubuntu1$ build-tree/src/dpkg --print-architecture
[04:53] <iwj> lpia
[04:53] <iwj> Yay.
[04:54] <cjwatson> alesan: like I said earlier - you can only use the initramfs from a regular system if you have the casper package installed there
[04:54] <iwj> infinity: dpkg-1.14.5ubuntu2 should fix your bug; currently uploading.
[04:55] <infinity> iwj: \o/
[04:55] <infinity> iwj: That's the last piece of the puzzle for a debootstrappable lpia, I think.  We just built the last of required/important/standard, and cprov just fixed an arch:all publishing bug.
[04:55] <infinity> cjwatson: ^^
[04:56] <cjwatson> excellent
[04:56] <Kmos> cjwatson: bug 129432
[04:56] <ubotu> Launchpad bug 129432 in Ubuntu "warn on LiveCD/installer startup about low screen resolution" [Undecided,New]  https://launchpad.net/bugs/129432
[04:56] <cjwatson> so after the next-but-one publisher run?
[04:56] <Kmos> i told him to send a specification
[04:56] <cjwatson> Kmos: specs are often overkill and don't replace wishlist bugs
[04:57] <infinity> cjwatson: After "the one after I build dpkg", whenever that is. :)
[04:57] <Kmos> cjwatson: hmm..
[04:57] <cjwatson> Kmos: in any case, surely that will be superseded by the displayconfig-gtk work in progress in gutsy
[04:58] <Kmos> so I can link the blueprint to this bug ? and set it as confirmed ?
[04:58] <cjwatson> in any case, asking submitters to write specifications is a bad idea
[04:58] <cjwatson> I wish whatever thing it was that asks bug triagers to do that would just die
[04:59] <cjwatson> bdmurray: ^--
[04:59] <Kmos> lol
[04:59] <Kmos> :)
[04:59] <Hobbsee> cjwatson: it's listed on !responses
[04:59] <Hobbsee> !responses
[04:59] <ubotu> response is https://wiki.ubuntu.com/Bugs/Responses
[04:59] <cjwatson> Kmos: feel free, it's not an installer matter so it's nothing really to do with me ...
[05:00] <Hobbsee> A non-trivial feature request
[05:00] <Hobbsee> For work that needs planning:
[05:00] <cjwatson> thanks, I'd prefer Brian's signoff before just changing it though
[05:00] <Hobbsee> cjwatson: seems its' mroe being used incorrectly, rather than being wrong.
[05:00] <Kmos> cjwatson: i can mark that bug a duplicate of bug 86262 ?
[05:00] <ubotu> Launchpad bug 86262 in xorg "UI for changing X configuration is rather hidden" [Medium,Confirmed]  https://launchpad.net/bugs/86262
[05:00] <cjwatson> Kmos: don't ask me
[05:00] <Hobbsee> cjwatson: email to the bugsquad may be a better option
[05:00] <Kmos> that has the blueprint of displayconfig-gtk
[05:01] <cjwatson> Hobbsee: it's very difficult for the bugsquad (or any non-developer) to tell whether a feature request needs planning
[05:01] <cjwatson> thus that is a foolish criterion to apply
[05:01] <Hobbsee> cjwatson: good point.  at least an "err on the side of caution"
[05:02] <Hobbsee> cjwatson: although, i'd imagine that's designed for bugs like "why dont you integrate portage in with dpkg?" or "why cant you make this act more like OSX" or something.
[05:02] <Hobbsee> doesnt make it used correctly, of course
[05:03] <cjwatson> Hobbsee: indeed, but in any case a feature specification written by an inexperienced person is unlikely to be a good start
[05:03] <Hobbsee> this is true.
[05:03] <Hobbsee> cjwatson: i dont suppose you've got any idea if we've got a spec-duper, or something?
[05:04] <Hobbsee> cjwatson: the specs are getting almost as bad as bugs.
[05:04] <cjwatson> spec-duper?
[05:04] <Hobbsee> something that will let us mark spec A as a dupe of spec B.
[05:04] <cjwatson> Hobbsee: yes, "superseded by other specification" or something like that
[05:04] <Hobbsee> oh neat :)
[05:05] <cjwatson> "Mark superseded", that's it
[05:05] <Hobbsee> very neat
[05:05] <Hobbsee> i'll look into that at around the same time i write up the now-implemented kubuntu council spec.
[05:06] <Hobbsee> or just mark it as done
[05:10] <bddebian> Heya folks
[05:11] <Riddell> Hobbsee: kubuntu-council is informational, it doesn't need to be implemented
[05:12] <Hobbsee> Riddell: even better.
[05:12] <Hobbsee> Riddell: i thought it had to be marked as "this has been discussed, and does not need rediscussion" or something
[05:24] <ScottK> pitti: Do you have a moment to discuss your backport of the Gutsy HAL to feisty?
[05:26] <Hobbsee> night all
[05:27] <pygi> good night Hobbsee
[05:28] <mvo> ogra: re bug #122459, what driver is used there (from the clients X)?
[05:28] <ubotu> Launchpad bug 122459 in compiz "[gutsy]  cannot log in on edubuntu DesktopCD" [Undecided,Incomplete]  https://launchpad.net/bugs/122459
[05:29] <ogra> mvo, via and sis
[05:29] <mvo> ogra: and both explode?
[05:32] <ogra> mvo, yes, apparently
[05:32] <mvo> ogra: do you have clients where one of them works?
[05:32] <mvo> ogra: or does it explode for any client that uses via or sis drivers?
[05:32] <ogra> on the one i have wih trident card it works
[05:32] <ogra> no idea
[05:33] <ogra> i only have one of each
[05:33] <ogra> i have another via but that doesnt work with the via driver (vesa only)
[05:34] <mvo> ogra: what driver does the trident card use?
[05:34] <ogra> i know elkbuntu had probs with her via card during tribe testing
[05:34] <ogra> trident
[05:34] <mvo> ogra: yeah, I know that too - we may just blacklist them, especially when they do not survive a glxinfo call
[05:35] <ogra> let me boot it ... 30 sec
[05:35] <ogra> right
[05:35] <ogra> i tested with a bare xterm, glxinfo killed them all
[05:35] <ogra> but i think the cause lies deeper in X somewhere
[05:35] <ogra> it didnt crash before
[05:36] <mvo> ogra: I talk with bryce earlier about a similar problem, the crash happens when vesa is used and glxinfo is run. but I do not think we have a solution yet, so blacklisting may be the only choice
[05:36] <ogra> that will be a huge blacklist then :/
[05:37] <kylem> mozilla locked up under vesa for me :/
[05:38] <ogra> the trident is a CyberBlade/i1 and uses the trident driver
[05:39] <ogra> and it works properly ... even if i click on desktop-effects it properly shows the note that it cant enable
[05:42] <doko> StevenK: bad guy, did you see the empty python-sip4-dbg package?
[05:47] <seb128> doko: $ python-dbg -c 'import gnome-applet'
[05:47] <seb128> ...
[05:47] <seb128> ImportError: /usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so: undefined symbol: Py_InitModule4
[05:47] <seb128> 
[05:47] <seb128> doko: do you think you could have a look at some point on what is creating that?
[05:47] <doko> seb128: is python-xml-dbg installed?
[05:47] <seb128> gnome-applet is shipped with python-gnome-desktop
[05:48] <seb128> doko: no, thanks
[05:48] <seb128> ImportError: /usr/lib/python2.5/site-packages/apt_pkg.so: undefined symbol: Py_InitModule4
[05:48] <seb128> now
[05:48] <seb128> lacks of Depends
[05:48] <seb128> doko: thanks ;)
[05:48] <doko> seb128: np
[05:49] <doko> seb128: but maybe in another package, which python-gnome-desktop-dbg should depend on?
[05:51] <seb128> doko: I'm not sure, I doubt python-gnome2-desktop uses apt for example, looking at it
[05:51] <seb128> Error in sys.excepthook:
[05:51] <seb128> Traceback (most recent call last):
[05:51] <seb128>   File "/var/lib/python-support/python2.5/apport_python_hook.py", line 38, in apport_excepthook
[05:53] <seb128> python-dbg -c 'import gnome' -> "ImportError: /var/lib/python-support/python2.5/gtk-2.0/gnome/_gnome_d.so: undefined symbol: Py_InitModule4"
[05:53] <seb128> bah, I don't get those python-dbg bugs :/
[05:57] <infinity> 01:03 < cjwatson> Hobbsee: indeed, but in any case a feature specification written by an  inexperienced person is unlikely to be a good start
[05:57] <infinity> cjwatson: I read that as "written by an innebriated person"...
[05:58] <infinity> cjwatson: Which doesn't drastically alter the truth of the statement, I suppose.
[06:12] <seb128> doko: when you have some time could you have a look at why "python-dbg -c 'import gnome" breaks? dbg packages breakages are blocking some desktop updates and I've no clue of to fix it :/
[06:13] <doko> seb128: ok, but please remind me tomorrow
[06:13] <seb128> doko: will do, thanks
[06:23] <Kmos> there is any possibilitie to backport devscripts from gutsy to feisty ?
[06:26] <cjwatson> hmm, I've been meaning to update the debootstrap backport
[06:26] <Kmos> i like to have new requestsync on feisty =)
[06:44] <Riddell> asac: presumably lightning-sunbird just uses much the same tar as the other mozilla apps?
[06:49] <siretart> pygi: huh?
[06:49] <pygi> siretart, you have a tiny minute?
[06:49] <siretart> what's up?
[06:50] <pygi> siretart, http://mailman-mail1.python-hosting.com/pipermail/libburn-announcements/2007-July/000018.html
[06:51] <siretart> pygi: congrats!
[06:52] <pygi> siretart, thanks!!!
[06:53] <asac> Riddell: yes
[06:53] <asac> Riddell: its closest to thunderbird ... all it has more is the calendar/ directory
[06:53] <pygi> siretart, anyway, sorry for bugging
[06:54] <siretart> no problem
[06:54] <pygi> do what you were doing
[06:54] <siretart> I just came home, I'm reading my mail and will look for something to dinner ;)
[06:54] <pygi> coming home is good :p
[06:54] <pygi> I'm tired and sick
[06:54] <pygi> made three libburnia releases today, and working on preparing fama for release
[06:54] <pygi> not good =)
[06:57] <siretart> Get well soon!
[06:57] <pygi> I will ... I hope :p
[06:59] <Riddell> asac: there's no mention of anything in other-licences in debian/copyright
[06:59] <keescook> bryce: I'm making a list of things that I want to force a rebuild of (to make sure they have stack-protector enabled).  I noticed a bunch are older x client apps.  Are there any sync or updates planned for these: http://people.ubuntu.com/~kees/needs-stackprotector-build.txt
[07:00] <asac> Riddell: hmm
[07:01] <Riddell> asac: could you upload a version that documents the licenses which apply to other-licences?
[07:02] <bryce> iceauth and ico are due for a sync, but all of the others have already received their updates
[07:02] <asac> Riddell: well ... look at other-licenses/branding/firefox/LICENSE
[07:03] <asac> Riddell: do you want that in copyright?
[07:03] <bryce> keescook: I could knock out ico and iceauth today if you'd like to get them uploaded?
[07:03] <keescook> bryce: ah, cool; they have updates pending?
[07:04] <bryce> no, but they're just basic x apps that I think shouldn't take more than half an hour to review and process
[07:05] <Riddell> asac: yep
[07:05] <Riddell> asac: you don't need every copyright holder in debian/copyright, but in my opinion it should have every licence
[07:06] <asac> Riddell: ok ... i can do that tomorrow or later tonight ... I will ping you when its ready
[07:07] <keescook> bryce: er, I guess I meant, "cool, those need version updates?"  Excellent; that makes things easy.  :)
[07:07] <bryce> yup, that's correct
[07:08] <Riddell> asac: is the file other-licenses/7zstub/firefox/7zSD.sfx derived from the sources in other-licenses/7zstub/src ?
[07:08] <asac> most likely
[07:08] <bryce> both got new releases within the last week and a half, after I'd already passed through that section of the alphabet
[07:08] <asac> Riddell: i cannot guarantee that they are in sync ... but I think thats the idea
[07:09] <asac> Riddell: but we have a tracking bug for binary files for all mozilla applications open
[07:13] <Riddell> asac: that's fine then
[07:18] <Riddell> asac: yep, all looks fine, just the other-licences stuff needs documented
[07:27] <wolfe> :)
[07:27] <wolfe> can't wait for a release with CFS
[07:27] <wolfe> =] 
[07:33] <keescook> Mithrandir: FYI, lpia apxs seems broken (and is causing apparmor builds to fail)
[07:45] <infinity> keescook: I'll fix it when I wake up.
[07:45] <infinity> keescook: It's already on my TODO.
[07:46] <keescook> infinity: okay, cool, thanks.
[07:47] <siretart> Mithrandir: can you please give back gxine on all archs? (all but lpia, where it is in needs build)
[07:48] <Riddell> siretart: in xine-plugins, is there any source for test.ogg, or is that the preferred modifyable form?
[07:49] <cjwatson> I wouldn't consider small test files to be a problem
[07:49] <siretart> xine-plugins? do you mean xine-lib?
[07:50] <Riddell> siretart: xine-plugin
[07:50] <siretart> if it has been recorded with e.g. audacity, what would you accept as preferred modifyable form? the uncompressed wav file?
[07:50] <Riddell> siretart: for which you're the uploader?
[07:50] <pitti> siretart: given back
[07:50] <siretart> pitti: thanks
[07:50] <siretart> Riddell: ah right
[07:51] <Riddell> siretart: it's a theora video, it could be the preferred modifyable form if you have something that can edit ogg theora files
[07:52] <siretart> yes, I remember now
[07:53] <Riddell> siretart: remember which?
[07:53] <siretart> about the package
[07:53] <Riddell> that's a relief :)
[07:53] <siretart> I'm checking the upstream VCS, but I don't see any other sources
[07:53] <siretart> so I'd say it is already in the preferred modifyable form
[07:54] <Riddell> ok, good with me (especially since it's already gone through Debian)
[07:54] <siretart> it is just a small testvideo for, well, testing purposes
[08:00] <geser> is it normal that the mail for NEWly accepted packages mentions 'main' as component instead of universe?
[08:02] <pitti> geser: no, it's not; maybe Riddell forgot to override it?
[08:04] <Riddell> geser: yes, that'll be my mistake, I later overrode it while in the accepted queue for xine-plugin and centerim
[08:04] <geser> ok and thanks
[08:07] <Kopfgeldjaeeger> using sed, awk or grep/egrep, how to show each line that contains x AND y anywhere? sed -n '/x.*y/p;/y.*x/p' works but is dirty
[08:10] <pitti> Kopfgeldjaeeger: egrep '(x.*y|y.*x)'  is the shortest thing I can think of, and probably even reasonably efficient
[08:11] <pitti> Kopfgeldjaeeger: you can drop the (), of course
[08:12] <Kopfgeldjaeeger> pitti, yeah.. OK. really seems like you can't make it shorter :/... thanks
[08:13] <stdin> Kopfgeldjaeeger: umm, "grep x | grep y" ?
[08:13] <pitti> Kopfgeldjaeeger: my initial idea was egrep '(x|y){2}', but that doesn't work
[08:13] <stdin> not as nice, but works :)
[08:14] <pitti> stdin: I doubt that this is more efficient, though (two processes and state machines and such)
[08:14] <Kopfgeldjaeeger> stdin, hehe.. sure. this is used in a script (not mine), but because it is not that nice, im looking for something else :d
[08:19] <stdin> anyone else realise firefox 2.0.0.6 is out?
[08:19] <ScottK> Yes.
[08:19] <stdin> hmm, I only just realised :p
[08:20] <cjwatson> Kopfgeldjaeeger: sed -n '/x/ { /y/p }' is another option
[08:21] <keescook> hm, is there a tech board meeting in 40 min?  fridge says yes, wiki doesn't really say...
[08:25] <tkamppeter> pitti, ping
[08:25] <Skiessi> Why SDL 1.2.12 hasn't been packaged?
[08:26] <Kopfgeldjaeeger> and what do you think you should use if you have more keywords? for instance, 5? the pitti-command(tm) would look a bit... strange ;).  cjwatson, could you tell me the syntax of this command?
[08:27] <pitti> hi tkamppeter
[08:34] <tkamppeter> pitti, I have uploaded new hal-cups-utils and new s-c-p now. With these ones Plug'n'Print works really well now: HP printers with PostScript PPDs, fax queues, and ...
[08:34] <tkamppeter> ... Samsung ML-1610 with SpliX.
[08:34] <pitti> \o/
[08:35] <pitti> tkamppeter: what determines the priority of printer drivers?
[08:35] <pitti> tkamppeter: i. e. what makes splix to become the default when it is installed?
[08:35] <tkamppeter> pitti, /usr/share/system-config-printer/ppds.py
[08:36] <tkamppeter> pitti, this file contains all the algorithms and rules.
[08:36] <agoliveira> tkamppeter: tkamppeter, I don't know if this is relevant but my Samsung ML-2010 is no longer recognized on Gutsy. In Feisty works perfectly.
[08:36] <pitti> oh, erk
[08:36] <tkamppeter> I have prioritized SpliX now. Se my e-mail with the ChangeLogs.
[08:37] <tkamppeter> agoliveira, check whether the printer appears in lsusb and in /proc/bus/usb/devices. If it is not there -> kernel
[08:39] <tkamppeter> pitti, seb128, what is missing now is some GUI improvement: When hal_lpadmin creates a queue, it sends two notifications into the DBUS, one before creating the new queue and one after, the one after with make, model, ... as attributes.
[08:40] <agoliveira> tkamppeter: Hmmm... something very weird happens. At the first moment, it does show up but one second later the usblp0 module is removed
[08:42] <tkamppeter> pitti, seb128: Currently, there appears only a magnifying glass on the gnome-cups-icon during the auto-setup. It would be nice to have some bubble at the tray telling "Printer found" in the beginning and "Samsung ML-1610 set up and ready to use" in the end.
[08:43] <tkamppeter> agoliveira, can you retry after "sudo /etc/init.d/hplip stop; sudo rmmod usblp; sudo modprobe usblp"?
[08:43] <pitti> tkamppeter: notification-daemon was broken until today, mvo's new upload made it work again today, so maybe it's already working again
[08:45] <tkamppeter> pitti, running auto-update an that box ...
[08:45] <agoliveira> tkamppeter: all the same
[08:46] <tkamppeter> agoliveira, can you look for messages in /var/log/syslog and /var/log/messages? For me it is a problem in kernel, UDEV, and/or HAL (but not hal-cups-utils).
[08:46] <Riddell> gpocentek: in kitsune, do you know which files make kitsune.icns ?
[08:47] <tkamppeter> pitti, I had some crashers when playing around with hal_lpadmin ...
[08:47] <tkamppeter> Any kernel, UDEV, and/or HAL Guru here?
[08:48] <agoliveira> tkamppeter: I know next to nothing abotu hal but it does show some weird messages after a plug the printer.
[08:49] <tkamppeter> You should get messages from NetworkManager and from hal_lpadmin. hal_lpadmin DOES NOT load or unload any kernel modules. It only talks with CUPS.
[08:50] <gpocentek> Riddell: the .pro file on mac I guess
[08:50] <agoliveira> NetworkManager indeed show some messages like:
[08:50] <agoliveira> Jul 31 15:38:19 cartman kernel: [22604.652000]  usb 1-1: new full speed USB device using uhci_hcd and address 3
[08:50] <agoliveira> Jul 31 15:38:19 cartman kernel: [22604.880000]  usb 1-1: configuration #1 chosen from 1 choice
[08:50] <agoliveira> Jul 31 15:38:19 cartman kernel: [22604.888000]  /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/class/usblp.c:
[08:50] <agoliveira> usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04E8 pid 0x326C
[08:50] <agoliveira> Jul 31 15:38:19 cartman NetworkManager: <debug> [1185907099.530071]  nm_hal_device_added(): New device added (hal ud
[08:50] <agoliveira> i is '/org/freedesktop/Hal/devices/usb_device_4e8_326c_3A99BKCL509345N_').
[08:50] <agoliveira> Jul 31 15:38:19 cartman NetworkManager: <debug> [1185907099.605333]  nm_hal_device_added(): New device added (hal ud
[08:50] <agoliveira> i is '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial').
[08:50] <agoliveira> Jul 31 15:38:19 cartman NetworkManager: <debug> [1185907099.626718]  nm_hal_device_added(): New device added (hal ud
[08:50] <agoliveira> i is '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial_printer_noserial').
[08:50] <agoliveira> Jul 31 15:38:19 cartman NetworkManager: <debug> [1185907099.632468]  nm_hal_device_added(): New device added (hal ud
[08:50] <agoliveira> i is '/org/freedesktop/Hal/devices/usb_device_4e8_326c_3A99BKCL509345N__usbraw').
[08:50] <agoliveira> Jul 31 15:38:57 cartman kernel: [22642.492000]  usb 1-1: USB disconnect, address 3
[08:50] <agoliveira> Jul 31 15:38:57 cartman kernel: [22642.492000]  /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/class/usblp.c:
[08:50] <agoliveira> usblp0: removed
[08:51] <tkamppeter> Seems that you do not have hal-cups-utils installed (installing the package will not fix your problem).
[08:53] <tkamppeter> Did you unplug or turn off your printer? Both HAL (NetworkManager) and the kernel show messages typical for disconnecting the device.
[08:53] <tkamppeter> Looks like kernel bug, kernel does disconnecting procedure while device still connected.
[08:54] <tkamppeter> Or your USB cable is broken.
[08:56] <agoliveira> tkamppeter: The same setup works perfectly on my macbook running feisty. Looks like a kernel bug indeed.
[08:57] <tkamppeter> agoliveira, can you report it on Launchpad? Thanks.
[08:57] <agoliveira> tkamppeter: Sure do.
[09:09] <tkamppeter> On the Launchpad upstream Ghostscript nug tracker is called gs-afpl-bugzilla (see bug 129389). Can it get renamed into gs-bugzilla, now after the Ghostscript merger?
[09:09] <ubotu> Launchpad bug 129389 in gs-gpl "[apport]  gs-gpl crashed with SIGSEGV in _IO_vfscanf()" [Medium,Incomplete]  https://launchpad.net/bugs/129389
[09:16] <geser> doko: is it ok for a package which build-depends on libgcj-dev to set CC=gcc-4.2 in debian/rules to let configure find jni.h?
[09:16] <doko> geser: sure
[09:17] <geser> thanks
[09:30] <tkamppeter> pitti, I have done a second auto-update now and this has pulled the new notification daemon now. I have logged out and looged in again, removed the print queue and replugged the printer. Nothing more than the magnifyier on the screen ...
[09:31] <pitti> tkamppeter: hm, so it doesn't seem to actually generate notifications
[09:32] <tkamppeter> pitti, and what does
[09:32] <tkamppeter>             bus = dbus.SystemBus()
[09:32] <tkamppeter>             try:
[09:32] <tkamppeter>                 syslog (LOG_DEBUG, "Calling GetReady")
[09:32] <tkamppeter>                 obj = bus.get_object("com.redhat.NewPrinterNotification",
[09:32] <tkamppeter>                                      "/com/redhat/NewPrinterNotification")
[09:32] <tkamppeter>                 notification = dbus.Interface(obj,
[09:32] <tkamppeter>                                               "com.redhat.NewPrinterNotification")
[09:32] <tkamppeter>                 notification.GetReady ()
[09:32] <tkamppeter> do?
[09:33] <tkamppeter> and
[09:33] <tkamppeter>                    notification.NewPrinter (status, self.name,
[09:33] <tkamppeter>                                              self.make, self.model,
[09:33] <tkamppeter>                                              self.description,
[09:33] <tkamppeter>                                              reduce(lambda x, y: x + ',' + y,
[09:33] <tkamppeter>                                                     self.commandsets))
[09:33] <tkamppeter> 
[09:34] <tkamppeter> code is from /usr/lib/hal/scripts/hal_lpadmin, before and after setting up a new print queue.
[09:34] <pitti> tkamppeter: this seems to be something RedHat specific; I doubt that we have something listening on that
[09:34] <pitti> tkamppeter: unless it's the default printer status icon
[09:42] <pitti> ogra: FYI, Martin-Eric fixed mkelfimage FTBFS, I currently sponsor it to Debian now; we can sync it tomorrow
[09:50] <Kopfgeldjaeeger> how do i check if i have a broadcom 43xx card,? with ndiswrapper drivers installed on feisty it shows: "hardware present", but because that damn card does not work (even after installing firmware with gutsy, on harddisk!) im not sure anymore....
[09:51] <Windkracht8> Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) from the title
[09:51] <pitti> Kopfgeldjaeeger: NB that there is a LInux driver for bcm43xx, and gutsy's restricted manager even offers you a three-click firmware installation
[09:52] <Kopfgeldjaeeger> pitty, youre right. but it doesnt work with this three-click installation (firmware installed, but cannot scan for networks and so, cant set it ip with "ifconfig interface up" (KSICOsomething error)...
[09:53] <Kopfgeldjaeeger> s/it ip/it up/g
[09:53] <pitti> hm
[09:53] <pitti> Kopfgeldjaeeger: it does for me for my Airport Extreme card
[09:53] <Chipzz> Kopfgeldjaeeger: how do i check if i have a broadcom 43xx card,? >> lspci ?
[09:53] <pitti> Chipzz: that'd work
[09:54] <tkamppeter> pitti, the magnifying glass is showing up exactly when the stup of the new queue begins and it disappears when the new queue is ready. No magnifier if now queue is needed and only enabling and disabling of queues is done. So it seems the code shown above triggers the magnifier.
[09:54] <Kopfgeldjaeeger> lspci shows "Dell 13somewhat Broadcom somewhat card"
[09:55] <Kopfgeldjaeeger> and its not a dell ;)
[09:56] <Kopfgeldjaeeger> Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01), a suse wiki entry says
[10:04] <pitti> finally! this damn apport thing works again, now better than ever
[10:05] <Kopfgeldjaeeger> lets say, i have a new gutsy (no driver with restricted mngr) and installed ndiswrapper, installed the bcmwl5 driver into ndiswrapper, executed "ndiswrapper -m" - and a open wlan network. what to do now? 2 seconds ago i did "ndiswrapper -m". no reboot at the moment.
[10:12] <pygi> laters pitti, good work =)
[10:19] <Kopfgeldjaeeger> how can i set a link from a device to the other? like "ln -s" does with files.. is this possible? typing "wlan0" and "speaking" with interface eth3 for instance?
[10:46] <keescook> Keybuk: seems the fixes we worked on in london don't fix my lvm-on-md boot issues.  :(  lvm is started, but nothing seems to notice.
[10:58] <sivang> does anyone know if jbailey is at a conference or afk lately ?
[10:59] <pygi> hey sivang
[10:59] <sivang> hey dude
[11:02] <pygi> sivang, pm
[11:15] <munckfish> asac: got a minute?
[11:15] <asac> well :/
[11:15] <asac> munckfish: whats up?
[11:15] <munckfish> Regarding ...
[11:15] <munckfish> LP bug ... sorry one sec
[11:16] <munckfish> LP #125662
[11:16] <ubotu> Launchpad bug 125662 in network-manager "Loss of DNS shortly after startup because /etc/init.d/networks isn't ignoring interfaces marked as roaming" [Medium,Triaged]  https://launchpad.net/bugs/125662
[11:16] <munckfish> I have managed to recreate the problem on Gutsy herd 3
[11:17] <munckfish> are you aware if a lot has changed in nm / ifupdown since then?
[11:17] <munckfish> ok np
[11:17] <munckfish> take your time
[11:17] <asac> munckfish: can you please summarize?
[11:17] <munckfish> sure
[11:17] <munckfish> long bug desc - I know
[11:17] <munckfish> DNS gets lost when
[11:18] <munckfish> a dhclient process that has been run for the IF I'm not using
[11:18] <munckfish> finally times out
[11:18] <munckfish> it then picks up on an old but not yet invalid lease
[11:18] <munckfish> but this lease is for a network I'm not on
[11:18] <munckfish> so it pulls in the DNS server entries
[11:19] <munckfish> and splats them into
[11:19] <munckfish> resolv.conf
[11:19] <munckfish> causing me to lose DNS
[11:19] <munckfish> you up to speed or shall on cont.?
[11:20] <ion_> It wasnt that long, only one or two lines worth. Of course, splitting something arbitrarily to ten lines makes it long. :-)
[11:21] <asac> munckfish: so what is the real problem?
[11:21] <asac> munckfish: why is that network-manager fault?
[11:21] <munckfish> well,
[11:21] <munckfish> I'm not sure it's nm's fault now
[11:22] <munckfish> I was advised to stick on NM because this was something that affected desktop operation rather than server
[11:22] <munckfish> anyway I'm beginning to think it's a problem with ifupdown
[11:22] <munckfish> I'm just not sure how development is coordinated
[11:23] <munckfish> between all these interrelated packages
[11:23] <munckfish> should I reassign it under ifupdown?
[11:23] <asac> so why does dhclient time out in the first place?
[11:24] <munckfish> not sure
[11:24] <munckfish> I looked up the docs and found the dhclient-script page desc best
[11:24] <munckfish> TIMEOUT occurs when it can't reach a dhcp server
[11:24] <munckfish> but an existing lease is available
[11:25] <munckfish> because the interface is not being used of course it can't reach dhcp
[11:25] <asac> munckfish: is that a regression?
[11:26] <asac> munckfish: nevermind ... reporter says that its been since feisty
[11:26] <munckfish> well, I moved from Dapper to Feisty
[11:26] <munckfish> wasn't in Dapper
[11:26] <asac> munckfish: ok ... for me it sounds like this issue is fixed in gutsy
[11:26] <munckfish> really?
[11:26] <munckfish> ok
[11:26] <asac> now network-manager will not restart interfaces upped by ifup
[11:26] <munckfish> what in particular has changed?
[11:27] <asac> i am not 100% if it fixes this issue ... but sounds like it might help
[11:27] <munckfish> hmmm, well, I managed to get the same behaviour today with herd 3
[11:27] <munckfish> but because I can't install to my hd
[11:27] <munckfish> I have to fake things a little
[11:28] <asac> herd?
[11:28] <munckfish> sorry
[11:28] <munckfish> tribe :S
[11:28] <asac> i still don't understand what the bug is
[11:28] <asac> i mean ... when dhclient times out ... what should be done instead?
[11:28] <munckfish> ok
[11:29] <munckfish> well it seems to me that dhclient (started by ifupdown / networks init script)
[11:29] <munckfish> should not be run on that interface
[11:29] <munckfish> because it is supposed to be marked as
[11:29] <munckfish> roaming
[11:29] <munckfish> and therefore only NM should be looking after that
[11:30] <johanbr> The new nm/ifupdown changes seem pretty buggy generally to me. Hopefully there's still time to iron out the bugs.
[11:31] <munckfish> is there a slim chance this is a bug in the config parsing code in ifupdown?
[11:32] <munckfish> should ifupdown really be considering interfaces if they are marked as roaming?
[11:34] <munckfish> well anyway, I'm happy to keep picking at this until I understand it, and I'd love to be able to submit a patch to fix it
[11:35] <johanbr> It used to be that it (ifupdown) didn't. I'm not sure if this new behaviour is intentional.
[11:36] <munckfish> I guess the most useful thing for me would be to know what is driving the integration of these components right now, e.g. a particular blueprint
[11:38] <johanbr> munckfish: Have you looked at the changelog for network-manager 0.6.5-0ubuntu7 ? There are some comments there that look relevant.
[11:39] <munckfish> ok I'll take a look
[11:40] <munckfish> btw, if I'm on feisty, what's the quickest way to get a source package for gutys? at the moment I'm looking for the .dsc on archive.ubuntu.com and dget-ing it from there
[11:41] <ScottK> munckfish: I just set my deb-src lines to gutsy since I almost never want Feisty source anymore.
[11:41] <munckfish> ScottK: ok I'll try that
[11:41] <munckfish> thx
[11:42] <ScottK> Don't for get apt-get update after you change it.
[12:11] <asac> munckfish: how exactly are they marked for roaming?